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

[Ken Rice]

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