[Freeswitch-users] SIP 500 overlapping requests due to race condition

[Michael Jerris]

Can you open a jira with all this information so we can dig on this a bit more.

Thanks
Mike

On Jun 21, 2014, at 12:26 PM, Phil Quesinberry <philq at qsystemsengineering.com> wrote:

> Digging into this further, I found the following document detailing best
> current practices for handling this condition.  Here is a clip of the
> relevant section from RFC 5407 - Example Call Flows of Race Conditions in
> the
>                   Session Initiation Protocol (SIP)
> 
> http://tools.ietf.org/html/rfc5407
> 
> 
> 
> Hasebe, et al.           Best Current Practice                 [Page 16]
> 
> 
> RFC 5407         Example Call Flows of Race Conditions     December 2008
> 
> 
> 3.1.4.  Callee Receives re-INVITE (Established State)  While in the
>        Moratorium State (Case 1)
> 
>   State  Alice                          Bob  State
>          |                                |
>          |    ini-INVITE w/offer1 F1      |
>          |------------------------------->|
>     Pre  |             180 F2             |  Pre
>          |<-------------------------------|
>     Ear  |                                |  Ear
>          |   200(ini-INV) w/answer1 F3    |
>          |<-------------------------------|
>    Mora  |       ACK F4(packet loss)      |  Mora
>          |-------------------->x          |
>     Est  |                                |
>          | re-INVITE F6      200 F5(=F3)  |
>          |   w/offer2         w/answer1   |
>          |-------------     --------------|
>          |              \ /               |
>          |               X                |
>          |              / \               |
>          |<------------     ------------->|  *race*
>          |                  200(re-INV) F8|
>          | ACK F7(=F4)        w/answer2   |
>          |-------------     --------------|
>          |              \ /               |
>          |               X                |
>          |              / \               |
>          |<------------     ------------->|
>          |         ACK (re-INV) F9        |  Est
>          |------------------------------->|
>          |                                |
>          |                                |
> 
>   This scenario illustrates the race condition that occurs when a UAS
>   in the Moratorium state receives a re-INVITE sent by a UAC in the
>   Established state.
> 
>   The UAS receives a re-INVITE (with offer2) before receiving an ACK
>   for the ini-INVITE (with offer1).  The UAS sends a 200 OK (with
>   answer2) to the re-INVITE (F8) because it has sent a 200 OK (with
>   answer1) to the ini-INVITE (F3, F5) and the dialog has already been
>   established.  (Because F5 is a retransmission of F3, SDP negotiation
>   is not performed here.)
> 
>   As can be seen in Section 3.3.2 below, the 491 response seems to be
>   closely related to session establishment, even in cases other than
>   INVITE crossover.  This example recommends that 200 be sent instead
> 
> 
> 
> Hasebe, et al.           Best Current Practice                 [Page 17]
> 
> 
> RFC 5407         Example Call Flows of Race Conditions     December 2008
> 
> 
>   of 491 because it does not have an influence on the session.
>   However, a 491 response can also lead to the same outcome, so either
>   response can be used.
> 
>   Moreover, if the UAS doesn't receive an ACK for a long time, it
>   should send a BYE and terminate the dialog.  Note that ACK F7 has the
>   same CSeq number as ini-INVITE F1 (see Section 13.2.2.4 of RFC 3261
>   [1]).  The UA should not reject or drop the ACK on grounds of the
>   CSeq number.
> 
> 
> _____________________________________________
> From: Phil Quesinberry 
> Sent: Friday, June 20, 2014 3:49 PM
> To: 'freeswitch-users at lists.freeswitch.org'
> Subject: RE: SIP 500 overlapping requests
> 
> 
> Correction: I meant to say "if FreeSWITCH could be configured to either wait
> up to x milliseconds for an ACKNOWLEDGEMENT to arrive."
> ___________________________________
> From: Phil Quesinberry 
> Sent: Friday, June 20, 2014 3:36 PM
> To: 'freeswitch-users at lists.freeswitch.org'
> Subject: RE: SIP 500 overlapping requests
> 
> 
> As it turns out, my assumption was correct.  We were not receiving an
> acknowledge before the second invite from the carrier.  One of their support
> engineers determined that they had recently enabled acknowledgement logging
> on their proxy/SBC, which apparently delayed transmission of the
> acknowledgement by a millisecond or two, which was enough to cause the
> invite from the server handling the media/call to arrive just slightly
> before the acknowledgement, so FreeSWITCH would tear down the call.  The
> problem was intermittent since the acknowledgement would sometimes arrive
> first.  They disabled acknowledgement logging and the problem went away.
> 
> With this and UDP in mind, it would likely reduce the incidence of dropped
> calls if FreeSWITCH could be configured to either wait up to x milliseconds
> for an invite to arrive, or allow x number of overlapping requests before
> throwing an error.  I saw a post where Tony mentioned that a patch had
> already been crafted to allow overlapping requests in the past, so it seems
> that most of the work has been done.
> 
> __________________________________
> From: Phil Quesinberry 
> Sent: Thursday, June 19, 2014 11:08 AM
> To: 'freeswitch-users at lists.freeswitch.org'
> Subject: SIP 500 overlappting requests
> 
> 
> We're having intermittent problems receiving calls from a particular DID.
> The basic scenario is as follows:
> Carrier sends invite w/SDP
> We respond w/OK and SDP when call is answered
> Carrier sends another invite with incremented sequence number and updated
> SDP (aren't they supposed to ACK/respond before doing this?)
> We send SIP 500 - overlapping requests
> Carrier sends BYE - terminating the call
> 
> Sometimes (rarely) the call completes, most of the time FS sends a 500 and
> doesn't get the call.  This just started happening recently and does not
> occur with any other DIDs, including other DIDs from the same carrier.  I
> updated to the latest stable GIT to see if that might solve the problem but
> I'm pretty sure this is on the carrier's end.  They're trying to blame it on
> us since we're sending the 500 and suggested that we allow overlapping
> requests.
> 
> I'm assuming that their end needs to acknowledge our answer OK/SDP before
> sending their own but if that's the problem then it raises another question
> in my mind: since the SIP transport is generally UDP, what if we don't
> receive their ACK before receiving their subsequent invite/SDP?  This could
> certainly happen and would cause the call to be rejected if the above is
> true.
> 
> I updated to the latest stable GIT last night to rule that out as a possible
> cause of the problem.  Is there a way to get FS to allow a limited number of
> overlapping requests as a possible workaround?
> 
> If someone thinks this looks like it could be an FS bug, I'll file a Jira.
> 
> Here is a trace which shows this happening:
> http://pastebin.freeswitch.org/22769
> 
> Thanks,
> 
> Phil Quesinberry
> Q Systems Engineering, Inc.
> Embedded Hardware/Software Development
> (410) 969-8002
> http://www.qsystemsengineering.com
> 
>