[SR-Users] CANCEL before INVITE

David kamailio.org at spam.lublink.net
Thu Jun 17 22:46:07 CEST 2010


Hey,

With my Cisco WIP310, what is happening is it is replying 481 Call 
Leg/transaction unknown. After that it processes the INVITE 
retransmission at which point it rings for 240 seconds. Which is a wee 
bit annoying.

David

On 2010-06-17 16:43, Alex Balashov wrote:
> David,
>
> You can suppress forwarding 100 Trying to the caller with the 0x01 
> flag to t_relay().  The problem is that then the caller will never 
> receive 100 Trying, as it is a "hop-by-hop" message;  in other words, 
> when received from the callee, the proxy will not forward it. Instead, 
> the expectation is that every network element in the call path 
> originates its own.
>
> A transaction is not established by the receipt of a provisional 
> message.  It is created when the INVITE is received.  As a result, it 
> is acceptable for Kamailio to forward the CANCEL request as long as it 
> has received the INVITE beforehand, even if it never got a proximate 
> response.
>
> Why is it a problem for Kamailio to forward the CANCEL?  It will just 
> not be responded to, and the transaction will time out eventually.  No 
> harm.
>
> On 06/17/2010 04:39 PM, David 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 ).
>>
>> I added this code :
>>
>> if ( is_method("INVITE") )
>> {
>> t_newtran();
>> }
>>
>> The problem is gone. Is this the correct solution ?
>>
>> David
>>
>>
>> On 2010-06-17 15:49, David wrote:
>>> Hey,
>>>
>>> I am using a Cisco WIP310 wifi phone. Seeing as wifi is very battery
>>> demanding, the phone goes into a standby mode. When it's in the
>>> standby mode, it takes a few seconds to come back on.
>>>
>>> So I send an INVITE to the phone, statefully using TM, I send out a
>>> CANCEL before the phone returns the "180 ringing" message.
>>>
>>> Somehow the device is answering the CANCEL before the INVITE, so the
>>> result is that it responds to the CANCEL with "481 Call
>>> Leg/Transaction Does Not Exist.", after that it responds to the INVITE
>>> with a "180 Ringing", the phone than rings indefinitely because the
>>> CANCEL is not sent out again as the transaction is completed from the
>>> 481 SIP message.
>>>
>>> I had a look at the CANCEL, there is no Route: header or tag on the
>>> To, so it looks like it is part of a new dialog ( I believe that's
>>> what rfc3261 says.
>>>
>>> As far as I can tell, my Kamailio is working properly. It is
>>> retransmitting the messages at the proper intervals, and it is passing
>>> along the messages as it receives them.
>>>
>>> The trouble is that the device answers the initial CANCEL before it
>>> answers any of the retransmitted INVITEs.
>>>
>>> Is there something that I can do in Kamailio to resolve this issue ?
>>> Is there an option that I can set that will cause Kamailio to relay
>>> the CANCEL only to devices that have already returned a 100 Trying or
>>> 180 Trying ?
>>>
>>> What information do you need to know about my config? What parts of
>>> the SIP trace do you need ?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> _______________________________________________
>>> 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