<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
I was looking at the 3261 again and have a question.<br>
<pre>
16.10 CANCEL Processing (Proxy Behavior)
... If a matching response context is found, the element MUST
immediately return a 200 (OK) response to the CANCEL request. In
this case, the element is acting as a user agent server as defined in
Section 8.2. ...
</pre>
So Kamailio is acting as a UAS when it receives a CANCEL<br>
We will assume for now that Asterisk properly constructed the
CANCEL.<br>
<pre>
9.2 Server Behavior (Canceling a Request)
...
Regardless of the method of the original request, as long as the
CANCEL matched an existing transaction, the UAS answers the CANCEL
request itself with a 200 (OK) response. This response is
constructed following the procedures described in Section 8.2.6
noting that <b>the To tag of the response to the CANCEL and the To tag
in the response to the original request SHOULD be the same.</b> ...
</pre>
By my reading of 9.2, the portion about the To tag, <br>
(In my case)<br>
1) The Original request is the INVITE.<br>
2) Response to the original request is a 180 Ringing<br>
3) Response to the CANCEL is a 200 OK<br>
Therefore the To tag in the 180 Ringing must match the To tag in the
200 OK?<br>
<br>
Is this right?<br>
When 3261 says "the response to the original request" is that the
last response?<br>
<br>
Relevant portions of the log:<br>
SIP/2.0 180 Ringing.
...<br>
To: <a class="moz-txt-link-rfc2396E"
href="sip:SIP_CalledPartyNumber@kamailio_IP"><sip:SIP_CalledPartyNumber@kamailio_IP></a>;tag=512af75a.
<br>
<br>
SIP/2.0 200 canceling.
...<br>
To: <a class="moz-txt-link-rfc2396E"
href="sip:SIP_CalledPartyNumber@kamailio_IP"><sip:SIP_CalledPartyNumber@kamailio_IP></a>;tag=4ed8ab9f3ed29a77613bb14b3431ff43-2f34.
<br>
<br>
Not sure how this work with forking.<br>
<br>
So to my eyes, this looks like a Kamailio bug?<br>
Please tell me where I went wrong.<br>
<br>
<br>
FYI in Asterisk it is dependent on the pedanticsipchecking being
enabled.<br>
This is set in sip.conf: pedantic=yes<br>
<br>
Thanks,<br>
Carl<br>
<pre></pre>
<br>
<br>
<br>
On 05/25/2011 01:01 PM, Iñaki Baz Castillo wrote:
<blockquote
cite="mid:BANLkTinyNHGbLpB7w=XxwFdicQ2nV9A=cw@mail.gmail.com"
type="cite">
<pre wrap="">2011/5/25 Carl Wagner <a class="moz-txt-link-rfc2396E" href="mailto:carl.wagner@verbalworld.com"><carl.wagner@verbalworld.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">I am sorry, you are right. I was looking at rfc3665 Page 71, F10 and it
did not have a To: tag in the 200 OK to the cancel.
(I know that rfc3665 is just examples, and when in doubt I should use
rfc3261)
The last paragraph of rfc3261, section 9.2 says to use section 8.2.6 to
construct the 200 (OK).
Not sure why Asterisk is not liking the 200 Canceling.
Does anyone see anything wrong with the Cancel or the 200 Canceling in the
log below?
</pre>
</blockquote>
<pre wrap="">
Because Asterisk is buggy and expects (wrongly) that the Totag of the
CANCEL must match the Totag of a previously received 1XX response.
This is of course a wrong assumption as there could be diferent 1XX
responses with different Totag (when forking).
I remember that it just occurs if you set Asterisk sip.conf with
pendantic-mode enabled.
Asterisk is buggy.
</pre>
</blockquote>
<br>
</body>
</html>