[asterisk-bugs] [Asterisk 0011536]: With "pedantic=yes" Asterisk shouldn't match To tag if the dialog is not established

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11536 
====================================================================== 
Reported By:                ibc
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   11536
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.15  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2007-12-13 06:58 CST
Last Modified:              2008-08-08 15:58 CDT
====================================================================== 
Summary:                    With "pedantic=yes" Asterisk shouldn't match To tag
if the dialog is not established
Description: 
Asterisk in SIP pedantic mode.

- Asterisk calls to an external SIP user in OpenSer proxy.
- After "Ringing" Asterisk sends CANCEL.
- OpenSer replies with "200 canceling" but Asterisk doesn't recognize it
so resends the CANCEL.

I've a theory of why it fails:

The "180 Ringing" contains a "To" tag:
  To: <sip:ibc at aliax.net>;tag=veuje

When Asterisk sends CANCEL OpenSer replies with:
  SIP/2.0 200 canceling
  To: <sip:ibc at aliax.net>;tag=373b8885156114ecb2c4bd665f9faf0b-f9aa

So Asterisk asumes wrong To tag (because it's different as the received
one) and discards it.

Of course, OpenSer proxy behaviour is correct: there could be many "180
Ringing" each one with different To tag in case of forking scenario, so the
To tag in the "200 canceling" from OpenSer *shouldn't* match any previous
"To" tag received in any provisional response.

About it I opened a thread in Sip-implementators mailist in which this
issue is explained:
 
https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-October/017668.html


IMHO the solution would be:
Asterisk shouldn't try to match a To tag if the dialog is not yet
established. And Asterisk should assume that it can receive multiples To
tag in provisional responses in case of forking scenarios (there are more
SIP in the world than just single phones registered in Asterisk XD).
====================================================================== 

---------------------------------------------------------------------- 
 (0091245) putnopvut (administrator) - 2008-08-08 15:58
 http://bugs.digium.com/view.php?id=11536#c91245 
---------------------------------------------------------------------- 
I have uploaded a patch which addresses this issue.

The way it works is that sip_pvt structures now have a new flag which
tells if a dialog has been established. A dialog is determined to be
established if it has reached the "confirmed" state as defined by RFC3261
(as opposed to the "early" state).

Using this patch, Aterisk will set the flag as a UAC when
- It receives a 200 OK in response to an INVITE
- It receives a 200 OK in response to a SUBSCRIBE

Asterisk will set the flag as a UAS when
- It sends a 200 OK in response to an INVITE
- It sends a 200 OK in response to a SUBSCRIBE

Asterisk will clear the flag as a UAC when
- It receives a 200 OK in response to a BYE
- It sends a BYE request

Asterisk will only compare its local tag to the remote tag of the far-end
UA if the dialog has been established.

Please test this out. It worked for me in my small test setup, but as with
all things SIP-related, I feel it's best for it to receive some wider
testing before committing the patch. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-08 15:58 putnopvut      Note Added: 0091245                          
======================================================================