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