[Freeswitch-users] SIP 500 overlapping requests due to race condition
Phil Quesinberry
philq at qsystemsengineering.com
Sat Jun 21 20:26:00 MSD 2014
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
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list