<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello,<br>
<br>
Here are the corrected attachments, I sent the email from Window's
wordpad which set it to RTF by default.<br>
<br>
Here are proper txt logs.<br>
<br>
David<br>
<br>
On 2010-07-05 17:47, David wrote:
<blockquote cite="mid:4C3252D9.2040206@spam.lublink.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hello,<br>
<br>
I upgraded to Kamailio 3.0 and the CANCEL is being sent after it
receives a 100 Trying, as mentioned in RFC3261 section 9.<br>
<br>
I stripped down the config file to the bare minimum so that it is
easier to debug ( see attached kamailio.cfg )<br>
<br>
I have included my config file as well as a packet sniff that was done
with ngrep.<br>
<br>
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 ).<br>
<br>
If I send the CANCEL once the device is ringing, it works fine ( see
sip-trace-good.log ).<br>
<br>
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.<br>
<br>
This looks suspiciously like a bug in the WIP310, but I am not sure.<br>
<br>
Can someone please shed some light on my situation?<br>
<br>
Thanks,<br>
<br>
David<br>
<br>
On 2010-06-17 16:59, Andrei Pelinescu-Onciul wrote:
<blockquote cite="mid:20100617205943.GB22857@ape.fokus.gmd.de"
type="cite">
<pre wrap="">On Jun 17, 2010 at 16:39, David <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:kamailio.org@spam.lublink.net"><kamailio.org@spam.lublink.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 ).
</pre>
</blockquote>
<pre wrap="">Try 3.0 (kamailio or sip-router). You can control how unreplied branches
are canceled, see
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#cancel_b_method">http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#cancel_b_method</a>
Andrei
</pre>
</blockquote>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>