Responding to INVITE with 180 vs 183
Hi all, I'm wondering what influences Freeswitch's signalling response when it responds to an INVITE. In some instances it appears to follow this sequence: Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 183 (SDP) <- FS Peer <- 200 (SDP) <- FS Peer -> ACK -> FS Which leads to a successful bridge between two legs. But in other instances it appears to follow the sequence: Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 180 (SDP) <- FS Peer <- 200 (SDP) <- FS (1st attempt) Peer <- 200 (SDP) <- FS (2nd attempt) .... Peer <- 200 (SDP) <- FS (nth attempt) ....timeout I'm not 100% sure whether the remote peer (itself a SIP trunk) doesn't like the 100/180/200 sequence (as opposed to 100/183/200), so I need to find that out for myself. But I am wondering what factors influence Freeswitch's decision of what sequence signals to send in response to an INVITE. Any pointers appreciated, Ben
I doubt it has anything to do with 180vs183. Check for nat issues in the trace that isn't working.
On Feb 10, 2015, at 2:55 PM, Ben Hood <0x6e6562@gmail.com> wrote:
Hi all,
I'm wondering what influences Freeswitch's signalling response when it responds to an INVITE.
In some instances it appears to follow this sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 183 (SDP) <- FS Peer <- 200 (SDP) <- FS Peer -> ACK -> FS
Which leads to a successful bridge between two legs.
But in other instances it appears to follow the sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 180 (SDP) <- FS Peer <- 200 (SDP) <- FS (1st attempt) Peer <- 200 (SDP) <- FS (2nd attempt) .... Peer <- 200 (SDP) <- FS (nth attempt) ....timeout
I'm not 100% sure whether the remote peer (itself a SIP trunk) doesn't like the 100/180/200 sequence (as opposed to 100/183/200), so I need to find that out for myself.
But I am wondering what factors influence Freeswitch's decision of what sequence signals to send in response to an INVITE.
Any pointers appreciated,
Ben
I think you may well have a point. I've spent days on this issue and I'm beginning to narrow it down by breaking the bridging down into the individual legs. I've also been able to establish RTP flow with the same originator by proxying the INVITE to a non-FS user agent (i.e. a phone registered with Kamailio). I didn't want to leave this post dangling without a some kind of closure, so I thought I'd just post this status update. On Tue, Feb 10, 2015 at 8:33 PM, Michael Jerris <mike@jerris.com> wrote:
I doubt it has anything to do with 180vs183. Check for nat issues in the trace that isn't working.
On Feb 10, 2015, at 2:55 PM, Ben Hood <0x6e6562@gmail.com> wrote:
Hi all,
I'm wondering what influences Freeswitch's signalling response when it responds to an INVITE.
In some instances it appears to follow this sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 183 (SDP) <- FS Peer <- 200 (SDP) <- FS Peer -> ACK -> FS
Which leads to a successful bridge between two legs.
But in other instances it appears to follow the sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 180 (SDP) <- FS Peer <- 200 (SDP) <- FS (1st attempt) Peer <- 200 (SDP) <- FS (2nd attempt) .... Peer <- 200 (SDP) <- FS (nth attempt) ....timeout
I'm not 100% sure whether the remote peer (itself a SIP trunk) doesn't like the 100/180/200 sequence (as opposed to 100/183/200), so I need to find that out for myself.
But I am wondering what factors influence Freeswitch's decision of what sequence signals to send in response to an INVITE.
Any pointers appreciated,
Ben
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
I could notice it is missing the ACK package from your PEER. Maybe its sending it to the wrong place, maybe its not sending it at all. FreeSWITCH will retry 200 OK over and over 'cause it expects an ACK in order to continue. here are some tips: Enable sip trace on the PEER side to check whether its sending ACK or not. Compare 200 OK (SDP) from FreeSWITCH in each scenario. Maybe there are differences between them. On Wed, Feb 11, 2015 at 5:05 PM, Ben Hood <0x6e6562@gmail.com> wrote:
I think you may well have a point.
I've spent days on this issue and I'm beginning to narrow it down by breaking the bridging down into the individual legs. I've also been able to establish RTP flow with the same originator by proxying the INVITE to a non-FS user agent (i.e. a phone registered with Kamailio).
I didn't want to leave this post dangling without a some kind of closure, so I thought I'd just post this status update.
On Tue, Feb 10, 2015 at 8:33 PM, Michael Jerris <mike@jerris.com> wrote:
I doubt it has anything to do with 180vs183. Check for nat issues in the trace that isn't working.
On Feb 10, 2015, at 2:55 PM, Ben Hood <0x6e6562@gmail.com> wrote:
Hi all,
I'm wondering what influences Freeswitch's signalling response when it responds to an INVITE.
In some instances it appears to follow this sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 183 (SDP) <- FS Peer <- 200 (SDP) <- FS Peer -> ACK -> FS
Which leads to a successful bridge between two legs.
But in other instances it appears to follow the sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 180 (SDP) <- FS Peer <- 200 (SDP) <- FS (1st attempt) Peer <- 200 (SDP) <- FS (2nd attempt) .... Peer <- 200 (SDP) <- FS (nth attempt) ....timeout
I'm not 100% sure whether the remote peer (itself a SIP trunk) doesn't like the 100/180/200 sequence (as opposed to 100/183/200), so I need to find that out for myself.
But I am wondering what factors influence Freeswitch's decision of what sequence signals to send in response to an INVITE.
Any pointers appreciated,
Ben
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Atenciosamente, Lucas Castro
Many thanks for your suggestions. Though I have not yet solved the end to end issue, I have broken the problem down into smaller parts that I have been successively debugging and verifying. Along the way I have discovered a number of signalling bugs in our setup. The most pertinent issue I have discovered is IP fragmentation problem in the firewall of the PEER. So after correcting the MTU on the link, I was able to get an INVITE to arrive at the remote PEER. So I think I might be on the way to discovering the underlying issue. On Thu, Feb 12, 2015 at 12:16 PM, Lucas Castro <lucasmcastro@gmail.com> wrote:
I could notice it is missing the ACK package from your PEER. Maybe its sending it to the wrong place, maybe its not sending it at all. FreeSWITCH will retry 200 OK over and over 'cause it expects an ACK in order to continue.
here are some tips:
Enable sip trace on the PEER side to check whether its sending ACK or not. Compare 200 OK (SDP) from FreeSWITCH in each scenario. Maybe there are differences between them.
On Wed, Feb 11, 2015 at 5:05 PM, Ben Hood <0x6e6562@gmail.com> wrote:
I think you may well have a point.
I've spent days on this issue and I'm beginning to narrow it down by breaking the bridging down into the individual legs. I've also been able to establish RTP flow with the same originator by proxying the INVITE to a non-FS user agent (i.e. a phone registered with Kamailio).
I didn't want to leave this post dangling without a some kind of closure, so I thought I'd just post this status update.
On Tue, Feb 10, 2015 at 8:33 PM, Michael Jerris <mike@jerris.com> wrote:
I doubt it has anything to do with 180vs183. Check for nat issues in the trace that isn't working.
On Feb 10, 2015, at 2:55 PM, Ben Hood <0x6e6562@gmail.com> wrote:
Hi all,
I'm wondering what influences Freeswitch's signalling response when it responds to an INVITE.
In some instances it appears to follow this sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 183 (SDP) <- FS Peer <- 200 (SDP) <- FS Peer -> ACK -> FS
Which leads to a successful bridge between two legs.
But in other instances it appears to follow the sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 180 (SDP) <- FS Peer <- 200 (SDP) <- FS (1st attempt) Peer <- 200 (SDP) <- FS (2nd attempt) .... Peer <- 200 (SDP) <- FS (nth attempt) ....timeout
I'm not 100% sure whether the remote peer (itself a SIP trunk) doesn't like the 100/180/200 sequence (as opposed to 100/183/200), so I need to find that out for myself.
But I am wondering what factors influence Freeswitch's decision of what sequence signals to send in response to an INVITE.
Any pointers appreciated,
Ben
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Atenciosamente, Lucas Castro
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Keep in mind that if you are exceeding MTU, UDP does not handle fragmentation well... The way around this is to reduce the size of your SIP packets (less codecs, X headers etc, or even compact headers) or just switch to TCP. This is why the RFCs require SIP endpoints to support both On 2/12/15, 2:00 PM, "Ben Hood" <0x6e6562@gmail.com> wrote:
Many thanks for your suggestions.
Though I have not yet solved the end to end issue, I have broken the problem down into smaller parts that I have been successively debugging and verifying. Along the way I have discovered a number of signalling bugs in our setup.
The most pertinent issue I have discovered is IP fragmentation problem in the firewall of the PEER. So after correcting the MTU on the link, I was able to get an INVITE to arrive at the remote PEER.
So I think I might be on the way to discovering the underlying issue.
On Thu, Feb 12, 2015 at 12:16 PM, Lucas Castro <lucasmcastro@gmail.com> wrote:
I could notice it is missing the ACK package from your PEER. Maybe its sending it to the wrong place, maybe its not sending it at all. FreeSWITCH will retry 200 OK over and over 'cause it expects an ACK in order to continue.
here are some tips:
Enable sip trace on the PEER side to check whether its sending ACK or not. Compare 200 OK (SDP) from FreeSWITCH in each scenario. Maybe there are differences between them.
On Wed, Feb 11, 2015 at 5:05 PM, Ben Hood <0x6e6562@gmail.com> wrote:
I think you may well have a point.
I've spent days on this issue and I'm beginning to narrow it down by breaking the bridging down into the individual legs. I've also been able to establish RTP flow with the same originator by proxying the INVITE to a non-FS user agent (i.e. a phone registered with Kamailio).
I didn't want to leave this post dangling without a some kind of closure, so I thought I'd just post this status update.
On Tue, Feb 10, 2015 at 8:33 PM, Michael Jerris <mike@jerris.com> wrote:
I doubt it has anything to do with 180vs183. Check for nat issues in the trace that isn't working.
On Feb 10, 2015, at 2:55 PM, Ben Hood <0x6e6562@gmail.com> wrote:
Hi all,
I'm wondering what influences Freeswitch's signalling response when it responds to an INVITE.
In some instances it appears to follow this sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 183 (SDP) <- FS Peer <- 200 (SDP) <- FS Peer -> ACK -> FS
Which leads to a successful bridge between two legs.
But in other instances it appears to follow the sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 180 (SDP) <- FS Peer <- 200 (SDP) <- FS (1st attempt) Peer <- 200 (SDP) <- FS (2nd attempt) .... Peer <- 200 (SDP) <- FS (nth attempt) ....timeout
I'm not 100% sure whether the remote peer (itself a SIP trunk) doesn't like the 100/180/200 sequence (as opposed to 100/183/200), so I need to find that out for myself.
But I am wondering what factors influence Freeswitch's decision of what sequence signals to send in response to an INVITE.
Any pointers appreciated,
Ben
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Atenciosamente, Lucas Castro
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH
This is a very good point to bear in mind. Is it general practice if you have to deal with external gateways that don't support TCP, and you can't harmonize the MTU on the relevant links, to trim the size of the SIP messages to stay below the fragmentation threshold?
On 12 Feb 2015, at 20:05, Ken Rice <krice@freeswitch.org> wrote:
Keep in mind that if you are exceeding MTU, UDP does not handle fragmentation well... The way around this is to reduce the size of your SIP packets (less codecs, X headers etc, or even compact headers) or just switch to TCP. This is why the RFCs require SIP endpoints to support both
On 2/12/15, 2:00 PM, "Ben Hood" <0x6e6562@gmail.com> wrote:
Many thanks for your suggestions.
Though I have not yet solved the end to end issue, I have broken the problem down into smaller parts that I have been successively debugging and verifying. Along the way I have discovered a number of signalling bugs in our setup.
The most pertinent issue I have discovered is IP fragmentation problem in the firewall of the PEER. So after correcting the MTU on the link, I was able to get an INVITE to arrive at the remote PEER.
So I think I might be on the way to discovering the underlying issue.
On Thu, Feb 12, 2015 at 12:16 PM, Lucas Castro <lucasmcastro@gmail.com> wrote: I could notice it is missing the ACK package from your PEER. Maybe its sending it to the wrong place, maybe its not sending it at all. FreeSWITCH will retry 200 OK over and over 'cause it expects an ACK in order to continue.
here are some tips:
Enable sip trace on the PEER side to check whether its sending ACK or not. Compare 200 OK (SDP) from FreeSWITCH in each scenario. Maybe there are differences between them.
On Wed, Feb 11, 2015 at 5:05 PM, Ben Hood <0x6e6562@gmail.com> wrote:
I think you may well have a point.
I've spent days on this issue and I'm beginning to narrow it down by breaking the bridging down into the individual legs. I've also been able to establish RTP flow with the same originator by proxying the INVITE to a non-FS user agent (i.e. a phone registered with Kamailio).
I didn't want to leave this post dangling without a some kind of closure, so I thought I'd just post this status update.
On Tue, Feb 10, 2015 at 8:33 PM, Michael Jerris <mike@jerris.com> wrote: I doubt it has anything to do with 180vs183. Check for nat issues in the trace that isn't working.
On Feb 10, 2015, at 2:55 PM, Ben Hood <0x6e6562@gmail.com> wrote:
Hi all,
I'm wondering what influences Freeswitch's signalling response when it responds to an INVITE.
In some instances it appears to follow this sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 183 (SDP) <- FS Peer <- 200 (SDP) <- FS Peer -> ACK -> FS
Which leads to a successful bridge between two legs.
But in other instances it appears to follow the sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 180 (SDP) <- FS Peer <- 200 (SDP) <- FS (1st attempt) Peer <- 200 (SDP) <- FS (2nd attempt) .... Peer <- 200 (SDP) <- FS (nth attempt) ....timeout
I'm not 100% sure whether the remote peer (itself a SIP trunk) doesn't like the 100/180/200 sequence (as opposed to 100/183/200), so I need to find that out for myself.
But I am wondering what factors influence Freeswitch's decision of what sequence signals to send in response to an INVITE.
Any pointers appreciated,
Ben
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Atenciosamente, Lucas Castro
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
On 02/12/2015 05:59 PM, Ben Hood wrote:
This is a very good point to bear in mind. Is it general practice if you have to deal with external gateways that don't support TCP, and you can't harmonize the MTU on the relevant links, to trim the size of the SIP messages to stay below the fragmentation threshold?
It is, I think, the inevitable widespread practice, which I suppose equates to "general". :-) -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
participants (5)
-
Alex Balashov
-
Ben Hood
-
Ken Rice
-
Lucas Castro
-
Michael Jerris