Bug in 200 to CANCEL (wrong To_tag)

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&GROUP_ID=139143&ATID=743020

THANKS FOR ANY COMMENT.


-- 
IñAKI BAZ CASTILLO

_______________________________________________
USERS MAILING LIST
USERSOPENSER.ORG
HTTP://OPENSER.ORG/CGI-BIN/MAILMAN/LISTINFO/USERS

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://s
ourceforge.net/tracker/index.php?func=detail&aid=1818469
&group_id=139143&atid=743020
> 
> Thanks for any comment.
> 
> 

_______________________________________________
Users mailing list
Usersopenser.org
htt
p://openser.org/cgi-bin/mailman/listinfo/users

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

_______________________________________________
USERS MAILING LIST
USERSOPENSER.ORG
HTTP://OPENSER.ORG/CGI-BIN/MAILMAN/LISTINFO/USERS

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

_______________________________________________
Users mailing list
Usersopenser.org
htt
p://openser.org/cgi-bin/mailman/listinfo/users

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...
> 
> 
> 
> 
> 

_______________________________________________
Users mailing list
Usersopenser.org
htt
p://openser.org/cgi-bin/mailman/listinfo/users

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
Usersopenser.org
htt
p://openser.org/cgi-bin/mailman/listinfo/users

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://sa
vannah.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
> Usersopenser.org
> htt
p://openser.org/cgi-bin/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Usersopenser.org
htt
p://openser.org/cgi-bin/mailman/listinfo/users