26 Oct
2007
26 Oct
'07
12:27 p.m.
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ó:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Iñaki Baz Castillo schrieb:
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.
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.