[SR-Users] CANCEL before INVITE

[Klaus Darilion]

Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
> On Jul 06, 2010 at 14:06, Klaus Darilion<klaus.mailinglists at pernau.at>  wrote:
>> Obiously the device is buggy.
>>
>> But there is also on strange thing at Kamailio: it retransmits the
>> CANCEL although it has already received 481 response on the CANCEL
>> request.
>
> The first 481 stops the CANCEL retransmissions, however each additional
> provisional reply received after that will trigger a one-time CANCEL
> retransmission. That's why you see another retransmission after the 481,
> it's the "response" to the 180...

Cool, nice feature.

Unfortunately it doesn't help with David's problem, as the phone 
obviously does not see the additional CANCEL - probably the phone's 
transaction layer responds again with 481.

regards
Klaus

>
> Andrei
>>
>> regards
>> klaus
>>
>> Am 06.07.2010 00:06, schrieb David:
>>> Hello,
>>>
>>> Here are the corrected attachments, I sent the email from Window's
>>> wordpad which set it to RTF by default.
>>>
>>> Here are proper txt logs.
>>>
>>> David
>>>
>>> On 2010-07-05 17:47, David wrote:
>>>> Hello,
>>>>
>>>> I upgraded to Kamailio 3.0 and the CANCEL is being sent after it
>>>> receives a 100 Trying, as mentioned in RFC3261 section 9.
>>>>
>>>> I stripped down the config file to the bare minimum so that it is
>>>> easier to debug ( see attached kamailio.cfg )
>>>>
>>>> I have included my config file as well as a packet sniff that was done
>>>> with ngrep.
>>>>
>>>> As you can see, the packets are in the correct order, but the Linksys
>>>> is crying "Call leg Transaction does not exist" despite the fact that
>>>> the CANCEL has ( as far as I can tell ) responded according to
>>>> RFC3261. I compared the headers that are required by RFC ( The
>>>> Request-URI, Call-ID, To, the numeric part of CSeq, and From header
>>>> fields in the CANCEL request MUST be identical to those in the request
>>>> being cancelled, including tags. ) but it still says Call Leg
>>>> Transaction does not exist. ( see ngrep-sip-wip-310.log ).
>>>>
>>>> If I send the CANCEL once the device is ringing, it works fine ( see
>>>> sip-trace-good.log ).
>>>>
>>>> If I send the CANCEL after the 100 Trying but before the 180 Ringing (
>>>> which is acceptable according to RFC3261 ), the device returns call
>>>> leg incorrect.
>>>>
>>>> This looks suspiciously like a bug in the WIP310, but I am not sure.
>>>>
>>>> Can someone please shed some light on my situation?
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>>> On 2010-06-17 16:59, Andrei Pelinescu-Onciul wrote:
>>>>> On Jun 17, 2010 at 16:39, David<kamailio.org at spam.lublink.net>   wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I had a look at RFC 3261, section 9.1. The trouble is that Kamailio
>>>>>> is answering "100 Trying" to the caller, so the it is ok for the
>>>>>> caller to send back a CANCEL request. Trouble is Kamailio forwards
>>>>>> the request to the called user even though the called user never
>>>>>> sent a provisional response.
>>>>>>
>>>>>> Since the Kamailio server never received a provisional request, it
>>>>>> is therefore incorrect for it to forward the CANCEL request to the
>>>>>> called user. ( correct me if I am wrong ).
>>>>>>
>>>>> Try 3.0 (kamailio or sip-router). You can control how unreplied branches
>>>>> are canceled, see
>>>>> http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#cancel_b_method
>>>>>
>>>>>
>>>>> Andrei
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users