[OpenSER-Users] Bug in 200 to CANCEL (wrong To_tag)

Aymeric Moizard jack at atosc.org
Fri Oct 26 14:27:36 CEST 2007


I just read this interesting compliance question. Here is my
*own* opinion:

First: from rfc: "the To tag of the response to the CANCEL and the To tag
    in the response to the original request SHOULD be the same"

-> Thus, there is no reason to send the tag from a provisionnal response
in the CANCEL answer. THIS IS ONLY FOR FINAL RESPONSE (the 487), never 
PROVISIONNAL (180 or 183). (However, the tag is always the same on 
endpoints, but still this is not true on proxy). That's how I understand
it.

-> SHOULD means that it's not mandatory. So if one application like 
asterisk tries to match the To tag of CANCEL answer and the to tag of a 
final response then this application is NOT compliant to rfc3261.

openser is not guilty there...
asterisk is certainly not "too much RFC compliant"...

Regards,
Aymeric MOIZARD / ANTISIP
amsip - http://www.antisip.com
osip2 - http://www.osip.org
eXosip2 - http://savannah.nongnu.org/projects/exosip/


On Thu, 25 Oct 2007, Klaus Darilion wrote:

> You could ask on the sip-implementors mailing list.
>
> regards
> klaus
>
> Iñaki Baz Castillo schrieb:
>> El Thursday 25 October 2007 11:15:41 Klaus Darilion escribió:
>>> Iñaki Baz Castillo schrieb:
>>>> El Tuesday 23 October 2007 14:31:23 Klaus Darilion escribió:
>>>>> And 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?
>>>> Hi again.
>>>> 
>>>> Note that RFC 3261 assumes parallel forking in a different way as OpenSer
>>>> does. OpenSer just replies **one** final response to UAC but notes what
>>>> RFC 3261 says:
>>> I think it does not assume a different way then Openser - this is just a
>>> race condition: proxy forwards to A and B. A sends 200. proxy sends 200
>>> to caller and CANCEL to B. If B picks up the phone and sends the 200 OK
>>> before the CANCEL arrives then the proxy should forward the 200 OK from
>>> B to the caller too and the caller has to deal to send a BYE to one of
>>> the calls.
>>> 
>>> Further this race condition is not related to you CANCEL problem as if
>>> there is already a 200 OK there will not be a CANCEL anymore, but a BYE.
>> 
>> Yes, it's different case.
>> In fact, I'm thinking about this CANCEL problem I can't find a solution 
>> compliant with that RFC expects, it's just impossible:
>> 
>> RFC says that when UAC sends a CANCEL (with no to_tag) it must receive a 
>> "200 cancelled" with the to_tag of previous 180 or 183 (where there is a 
>> to_tag).
>> But in the other hand, CANCEL is hop by hop related, so the SIP device that 
>> must reply to that CANCEL is the proxy and not the UAS. If the proxy 
>> generates various branchs because parallel forking there could be various 
>> 180 with different to_tag, so in case of CANCEL how could OpenSer reply a 
>> 200 with every to_tags the UAC knows? that's why OpenSer replies with a new 
>> to_tag.
>> 
>> If I'm right in the above explanation (could you confirm please?) then, 
>> what should we do? open a bug for RFC? XDD
>> It's clear that Asterisk in pedantic mode (this is: matching tags) it 
>> doesn't recognize the "200 cancelled" with new tag from OpenSer. Is it 
>> because being "too much" RFC compliant?
>> 
>> 
>> Best regards.
>> 
>> 
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>


More information about the Users mailing list