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@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@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@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@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