[SR-Users] CANCEL before INVITE

[Alex Balashov]

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


-- 
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/