[Home]

Summary:ASTERISK-14020: 200 OK is not accepted when SIP INFO in early dialog
Reporter:atca_pres (atca_pres)Labels:
Date Opened:2009-04-27 10:16:08Date Closed:2009-07-22 15:02:33
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) INFO-between183And200.pcap
( 1) verbosedebug.txt
Description:Scenario :
Extension 6789 calls 1234
1234 points to aa_3 (IVR) in the context
When aa_3 is playing, 6789 press 1234 (Extension)
* then sends an INVITE to a PSTN Gateway (Mediatrix 3532)
Because of PSTN, the Mediatrix 3532 sends a 183 with SDP to *
6789 now hears an IVR on the PSTN and press 1 and 2 (choices in PSTN IVR)
The two SIP INFO messages are sent to *
The PSTN finally connect and the Mediatrix 3532 sends the 200 OK to the *

Asterisk never answers this 200 OK and the call gets drop.

Attached is the SIP debug + core and verbose 5 (asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt) and an ethereal capture (Call ID between Asterisk and Mediatrix 3532) for easy reading.

****** ADDITIONAL INFORMATION ******

My guess is that Asterisk has "lost" the branch of the 183 or has replaced it by the SIP INFO and can no longuer match the 200 OK to the 183.

For information: I originally thought this was linked to "0013381: Wrong branch on CANCEL after SIP INFO in early dialog", but this is also present in 1.4.21.1

Also please note that in my testing environment, the call on the PSTN actually goes back to the 3532 itself (T1 side) which sends it to extension 5678 afterward.
Comments:By: Leif Madsen (lmadsen) 2009-06-24 13:01:35

Due to the number of changes in chan_sip between 1.4.24 and the latest 1.4 branch, could you try updating your test environment to determine if this is still an issue? Thanks!

By: atca_pres (atca_pres) 2009-06-25 09:34:49

Dear Imadsen,

This behavior has been reproduce with Revision 203036.

By: Mark Michelson (mmichelson) 2009-07-22 10:00:55

I think that revision 204243 of the 1.4 branch will fix this issue.

Asterisk had a long-standing problem that if it tried to send multiple requests, Asterisk would "forget" about the earlier requests it sent and only pay attention to the response(s) received for the latest request sent. Revision 204243 fixed that problem in Asterisk.

In your case, the problem is that Asterisk would send an INVITE request and then before receiving a 200 OK would send an INFO request. At this point, Asterisk, since the INFO was the latest request sent, would ignore any responses received for the INVITE. Please try revision 204243 and see if the same behavior occurs.

By: atca_pres (atca_pres) 2009-07-22 14:53:57

Dear mmichelson,

It appears the problem has effectivly been solved. I just tested with rev 208082 and the problem did not appear.

Thank you very much !

By: Mark Michelson (mmichelson) 2009-07-22 15:02:32

Excellent! I'm glad to hear the issue is solved. I will close this issue since it has been fixed.