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

Tue Feb 12 03:57:16 CST 2008

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:                     acknowledged
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:              02-12-2008 03:57 CST
====================================================================== 
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 - 02-12-08 03:57  
---------------------------------------------------------------------- 
Oej, I've set now debug to 6 (I inspected the code and level 6 is requiered
for some logging). I think the issue cause could be cleared with the
following capture:

** Asterisk:
INVITE
From: tag=as6dd87ea3

** Openser:
180 Ringing
From: tag=as6dd87ea3
To:  tag=fcpfa

** Asterisk:
CANCEL
From: tag=as6dd87ea3
To:  tag=<none>

** OpenSer:
200 canceling
From: tag=as6dd87ea3
To: tag=373b8885156114ecb2c4bd665f9faf0b-6802
(this To_tag is completely correct according to RFC3261, read the link to
sip-implementators maillist in the original report).

** OpenSer:
487 Request Terminated
From: tag=as6dd87ea3
To:  tag=fcpfa

** Asterisk:
ACK
From: tag=as6dd87ea3
To:  tag=fcpfa

--CANCEL again--

** Asterisk:
CANCEL
From: tag=as6dd87ea3
To:  tag=<none>

** OpenSer:
200 canceling
From: tag=as6dd87ea3
To: tag=373b8885156114ecb2c4bd665f9faf0b-6802

** Asterisk:
CANCEL
From: tag=as6dd87ea3
To:  tag=<none>

** OpenSer:
200 canceling
From: tag=as6dd87ea3
To: tag=373b8885156114ecb2c4bd665f9faf0b-6802

...

And this is the bug of Asterisk:

------------------------------------------------------------------------
DEBUG[3691] chan_sip.c: = Looking for  Call ID:
1fd718815516a0a635618ebd747aa53a at 88.99.0.111 (Checking To) --From tag
as6dd87ea3 --To-tag 373b8885156114ecb2c4bd665f9faf0b-6802  

DEBUG[3691] chan_sip.c: = No match Their Call ID:
1fd718815516a0a635618ebd747aa53a at 88.99.0.111 Their Tag fcpfa Our tag:
as6dd87ea3

DEBUG[3691] chan_sip.c: That's odd...  Got a response on a call we dont
know about. Callid 1fd718815516a0a635618ebd747aa53a at 88.99.0.111

DEBUG[3691] chan_sip.c: Invalid SIP message - rejected , no callid, len
351
------------------------------------------------------------------------

I see in the code:

line 5707:
---------------------------------------------------------------------
for (p = dialoglist; p; p = p->next) {
	/* In pedantic, we do not want packets with bad syntax to be connected to
a PVT */
	int found = FALSE;
	if (ast_strlen_zero(p->callid))
			continue;
	if (req->method == SIP_REGISTER)
			found = (!strcmp(p->callid, callid));
	else
			found = (!strcmp(p->callid, callid) &&
			(!pedanticsipchecking || !tag || ast_strlen_zero(p->theirtag) ||
!strcmp(p->theirtag, tag))) ;

	ast_debug(5, "= %s Their Call ID: %s Their Tag %s Our tag: %s\n", found ?
"Found" : "No match", p->callid, p->theirtag, p->tag);
---------------------------------------------------------------------

line 5871:
---------------------------------------------------------------------
/* We do not respond to responses for dialogs that we don't know about,
   we just drop the session quickly */
	if (intended_method == SIP_RESPONSE)
		ast_debug(2, "That's odd...  Got a response on a call we dont know
about. Callid %s\n", callid ? callid : "<unknown>");

	return p;  <-- "p" is initialized NULL
--------------------------------------------------------------------- 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-12-08 03:57  ibc            Note Added: 0082071                          
======================================================================