[Home]

Summary:ASTERISK-05030: Don't send BYE out of dialog
Reporter:hypherion (hypherion)Labels:
Date Opened:2005-09-08 17:05:28Date Closed:2008-01-15 15:48:00.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Asterisk183Bug.txt
( 1) vonage_call_with_pedantic.txt
( 2) vonage_call.txt
Description:Asterisk uses the To tag from a 183 Session Progress early media dialog when sending a BYE instead of the tag from the 200 OK sent by the callee.

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

This can be reproduced when using proxies that send 183 early media (such as Vonage) upon placing a call from Asterisk.  The 183 can have a different To tag that is not part of the main dialog.  The one that should be considered when sending a BYE to the initial dialog is the one that is in the 200 OK sent as the call is answered.  
When the caller hangs up, the BYE sent from Asterisk includes the To tag that was provided in 183, not the 200 OK.
See attached text file (IP's and phone #'s masked) for an Ethereal trace of the dialog that uses Vonage to call a landline.  Notice the 200 OK (packet 856) has a To tag of 1002151539 while Asterisk sends a BYE to 2067764114 (which is the one from the 183).  Vonage checks tags and replies with a 400 Bad Request and as a result the landline never gets the disconnect signal.
Comments:By: hypherion (hypherion) 2005-09-08 17:11:07

Pedantic option behaves the same.
By: Olle Johansson (oej) 2005-09-09 02:47:54

As per the bug guidelines, we need a SIP debug output, not an ethereal packet trace. SIP debug outputs tells us more about what is going on inside asterisk.
By: Olle Johansson (oej) 2005-09-09 02:48:39

I'll mark this related to 5125 since it involves tags...
By: Olle Johansson (oej) 2005-09-09 02:50:15

I wonder if it's allowed to have a different to tag in the 183. I'll go check the RFC, just to make sure. I wouldn't be surprised :-)
By: klaus3000 (klaus3000) 2005-09-09 03:09:58

A client is not allowed to respond with a different to-tag in 183 and 200. But for example if the call is forked the 183 may be received from another client than the 200 Ok. Thus, Asterisk should be aware that there are 2 dialogs. One early dialog established by the 183, and a second "confirmed" dialog, established by the 200 Ok.
Once one of the dialogs is confirmed (200 Ok), asterisk has to keep this dialog and store all dialog related data. This means: the to-tag, route information (Record-Route header), Via headers, Contact: URI and SDP

The early dialogs should be discarded once a confirmed dialog exists. Thus, the dialog information received with the 183 must be discarded.

Conclusion: Once a 200 is received, Asterisk has to use all dialog related adta from this 200 response and must not use ana data received by previous provisional responses.
By: Olle Johansson (oej) 2005-09-09 03:10:39

Well, the RFC says that if the 18x response contain an unknown to-tag, we need to create a dialog with that identifier - which is what we are doing. So basically, we should reject the 200 OK in pedantic mode since it is coming from an unknown dialog... See 13.2.2. This is due to the fact that we don't really support forking of our Invites. To be strict the 183 and the 200 OK is coming in different dialogs and it's propably bad behaviour of vonage...

After that, the 200 OK is our final response and the one we should take the call in and then wonder whatever happened to the other dialogue with the 183 early media. Discard that dialog and continue on happily with the 200 OK. Weird.

To summarize, I think that the default behaviour of Asterisk in non-pedantic mode should be as you say, to use the 200 OK to tag as the to-tag in the final response for our INVITE and continue with that.

Guess I have to reconstruct the tag handling after all. Tried to avoid that in 1.2...
By: klaus3000 (klaus3000) 2005-09-09 03:15:57

I loks like also the vonage equipment is not RFC conform:
1. Different to tag in 183 and 200, although it looks like the call is only be sent to one UAS (looks like a Cisco GW)

2. Vonage answers with 400, instead of 481.
By: klaus3000 (klaus3000) 2005-09-09 03:54:58

Handling responses with different totag should also work in pedantic mode. Thus, we have to modify find_call and pvt.

- We have to store if a dialog is in early state or confirmed state (eg. a flag)
- in find_call() we match to-tag only if a dialog is confirmed

 if (p->ast_test_flag(DIALOG_CONFIRMED))
     found = (p->callid==callid && p->tag==fromtag && p->theirtag==totag)
 else
     found = (p->callid==callid && p->tag==fromtag)


in handle_request()
 if responsecodeOfInvite == 200
      ast_set_flag(DIALOG_CONFIRMED)
By: Olle Johansson (oej) 2005-09-09 03:57:28

Klaus: Yes, I came to the same conclusion. But I don't know how many more changes we can do before 1.2... I'll look at it. But it seems like we agree that vonage is broken.
By: klaus3000 (klaus3000) 2005-09-09 04:55:50

I really would like a correct dialog matching in 1.2 (especially in pedantic mode) as stable should be stable :-)
By: Olle Johansson (oej) 2005-09-09 08:23:01

Well, we have to balance. I can continue to live with a broken pedantic, since it's been broken for a long time. Fixing it properly requires a lot of new code that I am trying to add to much of in the last minutes of the release cycle. I am upsetting enough people with all the code that I have to get in there any way ;-)

I'd rather create an ugly fix to keep vonage connections going without pedantic and then work on a proper solution for 1.3 - chan_sip3. Sorry to disappoint you, but we gotta release some time...
By: Olle Johansson (oej) 2005-09-09 10:48:06

Please check the latest patch in ASTERISK-4991 that addresses this issue to. Test as soon as possible and please confirm your findings.

If you have time, turn pedantic on and see what happens. Capture that in a log file and attach to this bug. I am curious and haven't got a vonage account to test with. With pedantic=yes we should not accept the 200 OK, which is a broken SIP dialog... Vonage should really fix this...  Tss tss.
By: hypherion (hypherion) 2005-09-09 14:10:15

I will test the patch later today and report back.  Also can you please change category for this bug to Interop, I forgot to specify it.
By: hypherion (hypherion) 2005-09-09 19:47:25

The patch pedantictags4.txt fixes the problem.  The BYE is now sent with the correct tag.  I have attached a sip debug of the call in vonage_call.txt.
By: hypherion (hypherion) 2005-09-09 19:54:42

Here is also the call with pedantic turned on.  In this case, the BYE is not even sent from Asterisk.  Later, when I hang up the landline, the BYE from Vonage is replied with 481.
By: Olle Johansson (oej) 2005-09-10 06:52:09

You should not even get a call with pedantic turned on... Thanks for testing!
By: klaus3000 (klaus3000) 2005-09-12 02:01:31

@olle: even with pedantic=yes Asterisk should work with Vonage as it maybe that the 183 is generated by another node than the 200 OK. If asterisk will be RFC conform it must handle this situation.
By: klaus3000 (klaus3000) 2005-09-12 04:26:28

I think asterisk has to differ between early dialogs and confirmed dialogs. Is there already such a handling in pvt?
By: Olle Johansson (oej) 2005-09-12 04:27:49

No, that is something that we really need to fix in the next release.
By: Olle Johansson (oej) 2005-09-12 10:13:52

Patch solves the problem that is reported.
By: Olle Johansson (oej) 2005-09-13 09:15:53

Actually the fix for this is worse if we *really* want to prepare for the worst. If there's a forking SIP proxy between us and the phones, and one phone send 183 early media and *another* phone sends 200 OK, we have to first listen to the 183 and then move the channel to the SDP in 200 OK.

To summarize, the tag in 200 OK should always be the tag we continue to work with, regardless of the pedantic setting. And we have to use the 200 OK SDP as a re-invite and stop talking based on the 183 sdp.
By: klaus3000 (klaus3000) 2005-09-13 11:51:49

I agree. This seems to be the correct behaviour.
By: Kevin P. Fleming (kpfleming) 2005-09-13 18:24:50

The patch in ASTERISK-5085125 will solve this problem as well, this issue does not need to stay open.
By: Mark Spencer (markster) 2005-09-13 20:44:50

Should be fixed in CVS head, reopen if not.
By: Digium Subversion (svnbot) 2008-01-15 15:48:00.000-0600

Repository: asterisk
Revision: 6576

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r6576 | markster | 2008-01-15 15:48:00 -0600 (Tue, 15 Jan 2008) | 2 lines

Handle dialog updates to to tag properly (bug ASTERISK-5030)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6576