[SR-Users] CANCEL before INVITE

Klaus Darilion klaus.mailinglists at pernau.at
Tue Jul 6 14:06:29 CEST 2010


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.

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



More information about the sr-users mailing list