Hi,
If Asterisk CANCEL a call to OpenSer then Asterisk resends the CANCEL many times because it ignores the 200 OK from OpenSer.
I think this is an OpenSer bug because the 200 OK to the CANCEL contains a To_tag different of the To_tag in the 180 (RFC 3261 in 9.2 says they SHOULD be the same To tag).
I've reported the bug but sincerely I'd like you to read it since I'm sure many people work with Asterisk and OpenSer and could know something about this CANCEL issue:
http://sourceforge.net/tracker/index.php?func=detail&aid=1818469&gro...
Thanks for any comment.
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?
Further, what if the callee has not sent a response yet - then openser also does not know which to-tag to use.
I nave had such problems with Asterisk yet. Do you use Asterisk in pedantic mode?
regards klaus
Iñaki Baz Castillo schrieb:
Hi,
If Asterisk CANCEL a call to OpenSer then Asterisk resends the CANCEL many times because it ignores the 200 OK from OpenSer.
I think this is an OpenSer bug because the 200 OK to the CANCEL contains a To_tag different of the To_tag in the 180 (RFC 3261 in 9.2 says they SHOULD be the same To tag).
I've reported the bug but sincerely I'd like you to read it since I'm sure many people work with Asterisk and OpenSer and could know something about this CANCEL issue:
http://sourceforge.net/tracker/index.php?func=detail&aid=1818469&gro...
Thanks for any comment.
El Martes, 23 de Octubre de 2007, 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?
Good point!
So, what should I do? reportabug to RFC because what it says about CANCEL is not possible whith parallel forking? maybe report a bug to Asterisk to be **in this case** to much RFC compliant?
Further, what if the callee has not sent a response yet - then openser also does not know which to-tag to use.
RFC says: "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request."
But the question is: what about if the only response is a 100 Trying that doesn't include To tag?
I nave had such problems with Asterisk yet. Do you use Asterisk in pedantic mode?
Yes, I use it. If I take it off it seems to work "better" but...
Thanks for all.
Iñaki Baz Castillo schrieb:
I nave had such problems with Asterisk yet. Do you use Asterisk in pedantic mode?
Yes, I use it. If I take it off it seems to work "better" but...
Asterisk can't handle multiple early dialogs - that's bad. Thus Asterisk is buggy regardless if you use pedantic = yes or no. Because of this I hate Asterisk although I actually love Asterisk ;-)
I have a setup where I needed pedantic=yes. Thus I strip to-tag from 1xx responses in openser for calls coming from the Asterisk gateway.
regards klaus
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:
------------------------------------------------------------------------ 13.2.2.4 2xx Responses
Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier. ------------------------------------------------------------------------
Of course, I can't understand how a UAC could handle various 200-OK when establishing a dialog, RFC dreams I hope...
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.
regards klaus
13.2.2.4 2xx Responses
Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier.
Of course, I can't understand how a UAC could handle various 200-OK when establishing a dialog, RFC dreams I hope...
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.
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.
El Thursday 25 October 2007 14:27:06 Klaus Darilion escribió:
You could ask on the sip-implementors mailing list.
I've already posted the question. If you are interested it's here:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-October/017668...
Regards.
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
El Friday 26 October 2007 14:27:36 Aymeric Moizard escribió:
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.
Thanks, in Sip-implementators mailist I got a similar response:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-October/017685...
I thisnk all is clear :)
Thanks a lot.
-
Aymeric Moizard -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Klaus Darilion