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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11536 
====================================================================== 
Reported By:                ibc
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11536
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
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:             12-13-2007 06:58 CST
Last Modified:              06-23-2008 07:22 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).
====================================================================== 

---------------------------------------------------------------------- 
 ibc - 06-23-08 07:22  
---------------------------------------------------------------------- 
Also note that "8.2 UAS Behavior" just talks about it, about the behaviour
of a UAS when receiving a request. But note that, in fact, a proxy becomes
a UAS when receives a CANCEL and also becomes a UAC when sending the CANCEL
to all the pending clients (forking scenario).

This is: a proxy does proxing for an INVITE and doesn't generate a
positive reply (2XX) for it. It must be the UAS (or UAS's) the responsible
SIP elements that create the 2XX and the proxy will forward it upstream to
the UAC.
But when a proxy receives a CANCEL for a previous INVITE it must generate
by itself the 200 reply and send it quickly to the UAC, and later send the
CANCEL to the pending called UAS's.

This is the RFC3261 behaviour, and this is the behaviour of the proxy I
use (OpenSer). The problem is that Asterisk acting as UAC doesn't recognize
the 200 reply from OpenSer after the CANCEL. And Asterisk doesn't recognize
it because it expects to match the To "tag" with the previous To "tag" in
1XX responses, but here Asterisk fails (as Oej has said above) since
Asterisk doesn't understand parallel forking and a 200 OK sent by a proxy. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-23-08 07:22  ibc            Note Added: 0089075                          
======================================================================