[OpenSER-Devel] [ openser-Bugs-1818469 ] 200 for CANCEL contains wrong To_tag

[SourceForge.net]

Bugs item #1818469, was opened at 2007-10-23 12:26
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1818469&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver 1.2.x
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: 200 for CANCEL contains wrong To_tag

Initial Comment:
According to RFC 3261 "9.2 Server Behavior":

  "...the UAS answers the CANCEL request itself with
   a 200 (OK) response.  This response is constructed
   following the procedures described in Section
   8.2.6 noting that the *To tag* of the response to
   the CANCEL and the *To tag* in the response to the
   original request SHOULD be the *same*.  The
   response to CANCEL is passed to the server 
   transaction for transmission."

But OpenSer doesn't not it. OpenSer generates a new To tag for the 200 to the CANCEL different from the To tag received in the 180 Ringing.

I attach a trace in which Asterisk calls to a OpenSer user, this user rings but Asterisk sends a CANCEL. The 200 To_tag to this CANCEL is different of the To_tag in the 180:


# Phone -> OpenSer
SIP/2.0 180 Ringing 
Via: SIP/2.0/UDP 85.12.12.110;branch=z9hG4bK2bca.08cf2485.0
Via: SIP/2.0/UDP 85.12.12.111:5060;rport=5060;branch=z9hG4bK57feb524
To: <sip:ibc at sip.domain.org>;tag=bptnj
...

# OpenSer -> Asterisk
SIP/2.0 180 Ringing 
Via: SIP/2.0/UDP 85.12.12.111:5060;rport=5060;branch=z9hG4bK57feb524
To: <sip:ibc at sip.domain.org>;tag=bptnj

# Asterisk -> OpenSer
CANCEL sip:ibc at sip.domain.org SIP/2.0
Via: SIP/2.0/UDP 85.12.12.111:5060;branch=z9hG4bK57feb524;rport
From: "asterisk" <sip:asterisk at sip.domain.org>;tag=as2bf71219
To: <sip:ibc at sip.domain.org>

# Openser -> Asterisk
SIP/2.0 200 canceling 
Via: SIP/2.0/UDP 85.12.12.111:5060;branch=z9hG4bK57feb524;rport=5060
From: "asterisk" <sip:asterisk at sip.domain.org>;tag=as2bf71219
To: <sip:ibc at sip.domain.org>;tag=fa997f81440371de71ab448ebdb9af56-31d7
Call-ID: 7494f28219c


Because it Asterisk resends CANCEL again and again.

I've seen most devices "allow" it, but IMHO it's not RFC compliant, is it?

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

>Comment By: Iñaki Baz (ibc_sf)
Date: 2007-10-30 09:30

Message:
Logged In: YES 
user_id=1844020
Originator: YES

Yes, sorry, I forgot to close this issue.
The question was explained in two threads Bogdan points.
My error was confusing a UAS with a Proxy.

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

Comment By: Dan (dan_pascu)
Date: 2007-10-30 06:47

Message:
Logged In: YES 
user_id=1296758
Originator: NO

I think you have misread the RFC. As I understand that section it says
that the 200 OK for the CANCEL and the final response for the initial
INVITE should have the same to-tag. The final response for a canceled
INVITE is 487 Request canceled, not 180 Ringing, and it is sent to the
originator (upstream), not to the device that receives the CANCEL
(downstream). I do not see any reference to 180 Ringing in that section.


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

Comment By: Bogdan (bogdan_iancu)
Date: 2007-10-30 06:13

Message:
Logged In: YES 
user_id=1275325
Originator: NO

See 
http://lists.openser.org/pipermail/users/2007-October/013915.html
and 
https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-October/017668.html

Bogdan

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

Comment By: Iñaki Baz (ibc_sf)
Date: 2007-10-23 14:55

Message:
Logged In: YES 
user_id=1844020
Originator: YES

As Klaus Darilion sais in mail list:

"what says the RFC about a proxy which does parallel forking? Then there
may be multiple 180 ringing with multiple to tags. Which one should be
used?"

So then maybe RFC is buggy in this CANCELspecification not compliant with
proxies doing parallel forking?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1818469&group_id=139143