THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened. Details are below.

User who did this - Sławomir Bocheński (lkslawek)

Attached to Project - sip-router Summary - CANCEL sent shortly after '100 trying' response to INVITE does not always end the call Task Type - Bug Report Category - Core Status - Unconfirmed Assigned To - Operating System - Linux Severity - Low Priority - Normal Reported Version - 4.1 Due in Version - Undecided Due Date - Undecided Details - This is the situation we have observed during some manual tests of SIP-enabled product when using Kamailio as registrar and proxy. When a client sends INVITE via Kamailio and then right after receiving '100 trying' provisional response it sends CANCEL, it happens that Kamailio replies instantly with '487 terminated' and yet it continues to forward the INVITE to the callee's end. So to put this in diagram:

<code>caller kamailio callee | | | |---------- INVITE -------->| | |<------- 100 trying -------| | |---------- CANCEL -------->| | |<-- 487 Request canceled --| | |<--- 200 ok -- no more ----| | | pending branches | | | |---------- INVITE -------->| |---------- ACK ----------->| | | |<------- 180 Ringing ------|</code>

It seems to me that another Kamailio process is processing the CANCEL before INVITE has been fully processed and it is yet unaware of the session existence.

The problem was originally observed on our Kamailio 4.0 instance with the routing script based on the default one, with NAT and authorisation enabled. Actually enabling NAT is one of the factors that makes this to occur more frequently, as anything that slows down INVITE processing. Even enabling debugging makes the probability rise. For simulation it's enough to e.g. insert sleep(1) at the top of the NATMANAGE block. I've also confirmed this on the latest release, that is 4.1.6, and on git master branch.

Attached logs were collected while using Kamailio development version compiled from git tree, branch master, using the default ./etc/kamailio.cfg modified to have full debug in syslog only, so defining WITH_DEBUG and setting log_stderr to 'no'. No other changes. Logs start with series of successful cancels, followed by one occurrence of the problem.

Both ends are running baresip 0.4.11. Callee is using TCP transport, listening on 5061 (but no TLS, so you may tune your dissector to decode 5061 as SIP), caller - UDP. Note that using UDP on both ends only slightly changes the reply sent on CANCEL, but the problem stays.

The tests for logs were mostly performed using caller's baresip with enabled module cons.so, thus accepting command over tcp port 5555, by running some flavour of:

<code>( echo -e 'dcallee'; sleep 0.01; echo -ne '\e' ) | nc localhost 5555</code>

In baresip console this is d for dial, destination and <RET> to confirm, then <ESC> to cancel/drop the call. Pasting 'dcalle\n\e' sequence from the X selection buffer directly to baresip console even without delay before cancellation also should do (although baresip more or less often will cancel the call before actually sending the INVITE itself).

One or more files have been attached.

More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=468

You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.