[Freeswitch-users] Responding to INVITE with 180 vs 183

Fri Feb 13 01:59:06 MSK 2015

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org