Re: [Freeswitch-users] freeswitch continously sending sip update-messages: why?
Hello, I'm testing freeswitch as an sbc (version 1.2.5.3). I think I discovered a bug, but I still have to verify it against git if I can find the time to compile it. Anyway, it all relates to session-timer according to me, but even if I disable session-timers, freeswitch still sends sip-update-messages to the sip-client. Freeswitch is dropping the calls after 30 seconds because of this. There is no problem with natting, firewalling, ... as far as I can tell as I'm tracing the packets on all ends. A packet from freeswitch to the sip-client (phone behind other B2B-server): UPDATE sip:10000@lab2.ddm.priv SIP/2.0 Via: SIP/2.0/UDP 172.16.105.14;rport;branch= z9hG4bKS2pQKQ7SrNgce Max-Forwards: 70 From: <sip:8888@172.16.105.17:5060>;tag=X5FKtKj9ZHaDc To: <sip:10000@lab2.ddm.priv
;tag=849E1A5B-6750-4EDE-B7CF-72DF979FD126-40026 Call-ID: 5AC29923-74EE-46B2-830A-9CB78B9DB47F-39541@172.16.105.17 CSeq: 38492344 UPDATE Contact: <sip:8888@172.16.105.14:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.2.5.3+git~20121206T050429Z~91eef34d5c Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY Supported: precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 249 P-Asserted-Identity: "Outbound Call" <0001>
v=0 o=FreeSWITCH 1357636566 1357636567 IN IP4 172.16.105.14 s=FreeSWITCH c=IN IP4 172.16.105.14 t=0 0 m=audio 20250 RTP/AVP 9 127 a=rtpmap:9 G722/8000 a=rtpmap:127 telephone-event/8000 a=fmtp:127 0-16 a=silenceSupp:off - - - - a=ptime:20 The other end of the sbc/client doesn't support session-timers or update (yate client), and it doesn't have this problem. So, the main question is: --> Why is freeswitch sending these update-messages while the codec, ... remains the same as far as I can tell. It isn't a session-timer, because it is enabled in the profile and it doesn't appear in the message too (which means the disable had some influence ...)? So, is there a way to: 1) fix the above? 2) force session-timers to use reinvite instead of update. As this case may be a way around the bug (freeswitch doing as it is the refresher while they agreed that the client is the session-timer-refresher). 3) (asked before, but not answered) Is there a way to disable sip-"update"-message-support in freeswitch? Thank you and kind regards, Michel
http://wiki.freeswitch.org/wiki/Variable_ignore_display_updates On Tue, Jan 8, 2013 at 10:22 AM, Michel Brabants <michel.brabants@gmail.com> wrote:
Hello,
I'm testing freeswitch as an sbc (version 1.2.5.3). I think I discovered a bug, but I still have to verify it against git if I can find the time to compile it. Anyway, it all relates to session-timer according to me, but even if I disable session-timers, freeswitch still sends sip-update-messages to the sip-client. Freeswitch is dropping the calls after 30 seconds because of this. There is no problem with natting, firewalling, ... as far as I can tell as I'm tracing the packets on all ends. A packet from freeswitch to the sip-client (phone behind other B2B-server):
UPDATE sip:10000@lab2.ddm.priv SIP/2.0 Via: SIP/2.0/UDP 172.16.105.14;rport;branch= z9hG4bKS2pQKQ7SrNgce Max-Forwards: 70 From: <sip:8888@172.16.105.17:5060>;tag=X5FKtKj9ZHaDc To: <sip:10000@lab2.ddm.priv>;tag=849E1A5B-6750-4EDE-B7CF-72DF979FD126-40026 Call-ID: 5AC29923-74EE-46B2-830A-9CB78B9DB47F-39541@172.16.105.17 CSeq: 38492344 UPDATE Contact: <sip:8888@172.16.105.14:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.2.5.3+git~20121206T050429Z~91eef34d5c Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY Supported: precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 249 P-Asserted-Identity: "Outbound Call" <0001>
v=0 o=FreeSWITCH 1357636566 1357636567 IN IP4 172.16.105.14 s=FreeSWITCH c=IN IP4 172.16.105.14 t=0 0 m=audio 20250 RTP/AVP 9 127 a=rtpmap:9 G722/8000 a=rtpmap:127 telephone-event/8000 a=fmtp:127 0-16 a=silenceSupp:off - - - - a=ptime:20
The other end of the sbc/client doesn't support session-timers or update (yate client), and it doesn't have this problem.
So, the main question is:
--> Why is freeswitch sending these update-messages while the codec, ... remains the same as far as I can tell. It isn't a session-timer, because it is enabled in the profile and it doesn't appear in the message too (which means the disable had some influence ...)?
So, is there a way to: 1) fix the above? 2) force session-timers to use reinvite instead of update. As this case may be a way around the bug (freeswitch doing as it is the refresher while they agreed that the client is the session-timer-refresher). 3) (asked before, but not answered) Is there a way to disable sip-"update"-message-support in freeswitch?
Thank you and kind regards,
Michel
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kristian Kielhofner
I think i already disabled this. This seems related to Sofia soa. Thanks. Op 8 jan. 2013 20:26 schreef "Kristian Kielhofner" <kris@kriskinc.com> het volgende:
http://wiki.freeswitch.org/wiki/Variable_ignore_display_updates
On Tue, Jan 8, 2013 at 10:22 AM, Michel Brabants <michel.brabants@gmail.com> wrote:
Hello,
I'm testing freeswitch as an sbc (version 1.2.5.3). I think I discovered a bug, but I still have to verify it against git if I can find the time to compile it. Anyway, it all relates to session-timer according to me, but even if I disable session-timers, freeswitch still sends sip-update-messages to the sip-client. Freeswitch is dropping the calls after 30 seconds because of this. There is no problem with natting, firewalling, ... as far as I can tell as I'm tracing the packets on all ends. A packet from freeswitch to the sip-client (phone behind other B2B-server):
UPDATE sip:10000@lab2.ddm.priv SIP/2.0 Via: SIP/2.0/UDP 172.16.105.14;rport;branch= z9hG4bKS2pQKQ7SrNgce Max-Forwards: 70 From: <sip:8888@172.16.105.17:5060>;tag=X5FKtKj9ZHaDc To: <sip:10000@lab2.ddm.priv>;tag=849E1A5B-6750-4EDE-B7CF-72DF979FD126-40026 Call-ID: 5AC29923-74EE-46B2-830A-9CB78B9DB47F-39541@172.16.105.17 CSeq: 38492344 UPDATE Contact: <sip:8888@172.16.105.14:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.2.5.3 +git~20121206T050429Z~91eef34d5c Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY Supported: precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 249 P-Asserted-Identity: "Outbound Call" <0001>
v=0 o=FreeSWITCH 1357636566 1357636567 IN IP4 172.16.105.14 s=FreeSWITCH c=IN IP4 172.16.105.14 t=0 0 m=audio 20250 RTP/AVP 9 127 a=rtpmap:9 G722/8000 a=rtpmap:127 telephone-event/8000 a=fmtp:127 0-16 a=silenceSupp:off - - - - a=ptime:20
The other end of the sbc/client doesn't support session-timers or update (yate client), and it doesn't have this problem.
So, the main question is:
--> Why is freeswitch sending these update-messages while the codec, ... remains the same as far as I can tell. It isn't a session-timer, because it is enabled in the profile and it doesn't appear in the message too (which means the disable had some influence ...)?
So, is there a way to: 1) fix the above? 2) force session-timers to use reinvite instead of update. As this case may be a way around the bug (freeswitch doing as it is the refresher while they agreed that the client is the session-timer-refresher). 3) (asked before, but not answered) Is there a way to disable sip-"update"-message-support in freeswitch?
Thank you and kind regards,
Michel
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Does the client send an ACK for the UPDATE? On 8 January 2013 15:22, Michel Brabants <michel.brabants@gmail.com> wrote:
Hello,
I'm testing freeswitch as an sbc (version 1.2.5.3). I think I discovered a bug, but I still have to verify it against git if I can find the time to compile it. Anyway, it all relates to session-timer according to me, but even if I disable session-timers, freeswitch still sends sip-update-messages to the sip-client. Freeswitch is dropping the calls after 30 seconds because of this. There is no problem with natting, firewalling, ... as far as I can tell as I'm tracing the packets on all ends. A packet from freeswitch to the sip-client (phone behind other B2B-server):
UPDATE sip:10000@lab2.ddm.priv SIP/2.0 Via: SIP/2.0/UDP 172.16.105.14;rport;branch= z9hG4bKS2pQKQ7SrNgce Max-Forwards: 70 From: <sip:8888@172.16.105.17:5060>;tag=X5FKtKj9ZHaDc To: <sip:10000@lab2.ddm.priv>;tag=849E1A5B-6750-4EDE-B7CF-72DF979FD126-40026 Call-ID: 5AC29923-74EE-46B2-830A-9CB78B9DB47F-39541@172.16.105.17 CSeq: 38492344 UPDATE Contact: <sip:8888@172.16.105.14:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.2.5.3+git~20121206T050429Z~91eef34d5c Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY Supported: precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 249 P-Asserted-Identity: "Outbound Call" <0001>
v=0 o=FreeSWITCH 1357636566 1357636567 IN IP4 172.16.105.14 s=FreeSWITCH c=IN IP4 172.16.105.14 t=0 0 m=audio 20250 RTP/AVP 9 127 a=rtpmap:9 G722/8000 a=rtpmap:127 telephone-event/8000 a=fmtp:127 0-16 a=silenceSupp:off - - - - a=ptime:20
The other end of the sbc/client doesn't support session-timers or update (yate client), and it doesn't have this problem.
So, the main question is:
--> Why is freeswitch sending these update-messages while the codec, ... remains the same as far as I can tell. It isn't a session-timer, because it is enabled in the profile and it doesn't appear in the message too (which means the disable had some influence ...)?
So, is there a way to: 1) fix the above? 2) force session-timers to use reinvite instead of update. As this case may be a way around the bug (freeswitch doing as it is the refresher while they agreed that the client is the session-timer-refresher). 3) (asked before, but not answered) Is there a way to disable sip-"update"-message-support in freeswitch?
Thank you and kind regards,
Michel
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
The correct positive response to an UPDATE would be a 200 that is then ACKd. See RFC 3311: http://tools.ietf.org/html/rfc3311 On Tue, Jan 8, 2013 at 2:40 PM, Steven Ayre <steveayre@gmail.com> wrote:
Does the client send an ACK for the UPDATE?
-- Kristian Kielhofner
Yep my mistake... rather I meant is FS getting a response? (Wondering if FS is retransmitting and/or timing out the call on no response since you say it hangs up 30s later) On 8 January 2013 20:46, Kristian Kielhofner <kris@kriskinc.com> wrote:
The correct positive response to an UPDATE would be a 200 that is then ACKd. See RFC 3311:
http://tools.ietf.org/html/rfc3311
On Tue, Jan 8, 2013 at 2:40 PM, Steven Ayre <steveayre@gmail.com> wrote:
Does the client send an ACK for the UPDATE?
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
No, freeswitch is not getting a response as the client (B2B sipserver) converts this to a reinvite with no sdp (which is incorrect of course). However, if I need to wait in the client-developers to fix this, I'll be a half year further... I was wondering however why freeswitch is sending these in the first place as it contains no differences from previous sdp's. It isn't also sending updates or reinvites to the other side. I don't see the purpose of these updates. If it was to change the code, ... it would be better in this case as freeswitch could send reinvites instead as these wouldn't be handled incorrectly normally by the client. Michel On Tue, Jan 8, 2013 at 10:11 PM, Steven Ayre <steveayre@gmail.com> wrote:
Yep my mistake... rather I meant is FS getting a response? (Wondering if FS is retransmitting and/or timing out the call on no response since you say it hangs up 30s later)
On 8 January 2013 20:46, Kristian Kielhofner <kris@kriskinc.com> wrote:
The correct positive response to an UPDATE would be a 200 that is then ACKd. See RFC 3311:
http://tools.ietf.org/html/rfc3311
On Tue, Jan 8, 2013 at 2:40 PM, Steven Ayre <steveayre@gmail.com> wrote:
Does the client send an ACK for the UPDATE?
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Its to update the caller id information. you can disable this: http://wiki.freeswitch.org/wiki/Sofia.conf.xml#send-display-update Mike On Jan 9, 2013, at 4:48 AM, Michel Brabants <michel.brabants@gmail.com> wrote:
No, freeswitch is not getting a response as the client (B2B sipserver) converts this to a reinvite with no sdp (which is incorrect of course). However, if I need to wait in the client-developers to fix this, I'll be a half year further...
I was wondering however why freeswitch is sending these in the first place as it contains no differences from previous sdp's. It isn't also sending updates or reinvites to the other side. I don't see the purpose of these updates. If it was to change the code, ... it would be better in this case as freeswitch could send reinvites instead as these wouldn't be handled incorrectly normally by the client.
Michel
On Tue, Jan 8, 2013 at 10:11 PM, Steven Ayre <steveayre@gmail.com> wrote: Yep my mistake... rather I meant is FS getting a response? (Wondering if FS is retransmitting and/or timing out the call on no response since you say it hangs up 30s later)
On 8 January 2013 20:46, Kristian Kielhofner <kris@kriskinc.com> wrote:
The correct positive response to an UPDATE would be a 200 that is then ACKd. See RFC 3311:
http://tools.ietf.org/html/rfc3311
On Tue, Jan 8, 2013 at 2:40 PM, Steven Ayre <steveayre@gmail.com> wrote:
Does the client send an ACK for the UPDATE?
Hello, this is disabled in all profiles, but freeswitch keeps sending updates. I'm adding my profile-config here. I even added it to the gateway that is associated with the endpoint, which may be important .... The endpoint is a B2B sipserver itself, so I was wondering if this could be the problem ... I made some progress: when adding the following to the gateway-declaration, calls are disconnected after a minute (bit more), because after about 30 seconds freeswitch starts sending updates now ... This is really strange. I added the following to the gateway-settings to make calls atleast reach 1 minute: <variables> <variable name="send-display-update" value="false" direction="inbound"/> </variables> Why isn't freeswitch taking the param from the ua/profile that is associated with the profile? Thanks, Michel On Wed, Jan 9, 2013 at 2:21 PM, Michael Jerris <mike@jerris.com> wrote:
Its to update the caller id information. you can disable this:
http://wiki.freeswitch.org/wiki/Sofia.conf.xml#send-display-update
Mike
On Jan 9, 2013, at 4:48 AM, Michel Brabants <michel.brabants@gmail.com> wrote:
No, freeswitch is not getting a response as the client (B2B sipserver) converts this to a reinvite with no sdp (which is incorrect of course). However, if I need to wait in the client-developers to fix this, I'll be a half year further...
I was wondering however why freeswitch is sending these in the first place as it contains no differences from previous sdp's. It isn't also sending updates or reinvites to the other side. I don't see the purpose of these updates. If it was to change the code, ... it would be better in this case as freeswitch could send reinvites instead as these wouldn't be handled incorrectly normally by the client.
Michel
On Tue, Jan 8, 2013 at 10:11 PM, Steven Ayre <steveayre@gmail.com> wrote:
Yep my mistake... rather I meant is FS getting a response? (Wondering if FS is retransmitting and/or timing out the call on no response since you say it hangs up 30s later)
On 8 January 2013 20:46, Kristian Kielhofner <kris@kriskinc.com> wrote:
The correct positive response to an UPDATE would be a 200 that is then ACKd. See RFC 3311:
http://tools.ietf.org/html/rfc3311
On Tue, Jan 8, 2013 at 2:40 PM, Steven Ayre <steveayre@gmail.com> wrote:
Does the client send an ACK for the UPDATE?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
8 jan 2013 kl. 21:46 skrev Kristian Kielhofner <kris@kriskinc.com>:
The correct positive response to an UPDATE would be a 200 that is then ACKd. See RFC 3311: The only transaction that needs an ACK is INVITE. RFC3311 does not mention an ACK as a response to UPDATE.
/O
http://tools.ietf.org/html/rfc3311
On Tue, Jan 8, 2013 at 2:40 PM, Steven Ayre <steveayre@gmail.com> wrote:
Does the client send an ACK for the UPDATE?
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
You are correct. I misread the call flow examples. The ACK was for the INVITE, not the update. With that being said the correct positive response to an UPDATE is still a 200, certainly not an ACK (even more so now). On Wed, Jan 9, 2013 at 3:29 AM, Olle E. Johansson <oej@edvina.net> wrote:
8 jan 2013 kl. 21:46 skrev Kristian Kielhofner <kris@kriskinc.com>:
The correct positive response to an UPDATE would be a 200 that is then ACKd. See RFC 3311: The only transaction that needs an ACK is INVITE. RFC3311 does not mention an ACK as a response to UPDATE.
/O
http://tools.ietf.org/html/rfc3311
On Tue, Jan 8, 2013 at 2:40 PM, Steven Ayre <steveayre@gmail.com> wrote:
Does the client send an ACK for the UPDATE?
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kristian Kielhofner
It indeed was the variable. I was setting it incorrectly ... On Wed, Jan 9, 2013 at 8:13 PM, Kristian Kielhofner <kris@kriskinc.com>wrote:
You are correct. I misread the call flow examples. The ACK was for the INVITE, not the update. With that being said the correct positive response to an UPDATE is still a 200, certainly not an ACK (even more so now).
On Wed, Jan 9, 2013 at 3:29 AM, Olle E. Johansson <oej@edvina.net> wrote:
8 jan 2013 kl. 21:46 skrev Kristian Kielhofner <kris@kriskinc.com>:
The correct positive response to an UPDATE would be a 200 that is then ACKd. See RFC 3311: The only transaction that needs an ACK is INVITE. RFC3311 does not mention an ACK as a response to UPDATE.
/O
http://tools.ietf.org/html/rfc3311
On Tue, Jan 8, 2013 at 2:40 PM, Steven Ayre <steveayre@gmail.com>
wrote:
Does the client send an ACK for the UPDATE?
-- Kristian Kielhofner
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kristian Kielhofner
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (5)
-
Kristian Kielhofner
-
Michael Jerris
-
Michel Brabants
-
Olle E. Johansson
-
Steven Ayre