<div dir="ltr">Thank you jiri,<div><br></div><div style>I totally agree, but I have a question that occured to me now and I cant find answer:</div><div style><br></div><div style>If Kamailio receives a CANCEL from a UAC after kamailio has responded with a 200 to the corresponding INVITE, what does t_relay_cancel() do in the following 2 cases:</div>
<div style><br></div><div style>1. CANCEL received before the ACK from UAC. This is legal from the side of the UAC, since the UAC may have sent the CANCEL before it receives the 200 to the INVITE that kamailio sent.</div>
<div style> </div><div style>2. CANCEL received after the ACK . This is illegal, but anyway, kamailio must do something. I can't find in the RFC if it should respond 200 to the CANCEL and drop it, or 481(<span style="color:rgb(0,0,0);font-size:1em">Call/Transaction Does Not Exist). Although 481 seems more resonable, 16.10 section of RFC says: "... </span><span style="color:rgb(0,0,0);font-size:1em">If a matching response context is found, the element MUST</span><span style="color:rgb(0,0,0);font-size:1em"> immediately return a 200 (OK) response to the CANCEL request.". It does not discriminate if the corresponding INVITE has been 200ed or not. Any insights?</span></div>
<div style><span style="font-size:1em;color:rgb(0,0,0)"><br></span></div><div style><span style="font-size:1em;color:rgb(0,0,0)">In the spirit of what you wrote in your reply, could</span> I configure it somehow, to take initiative and translate the CANCEL to a BYE downstream, no matter whether CANCEL is received before or after the ACK?<span style="font-size:1em;color:rgb(0,0,0)"><br>
</span></div><div style><br></div><div style>Bill</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 3, 2013 at 12:26 PM, Jiri Kuthan <span dir="ltr"><<a href="mailto:jiri@iptel.org" target="_blank">jiri@iptel.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 5/3/13 11:04 AM, Vassilis Radis wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hello all,<br>
<br>
In the documentation of the t_relay_cancel() (TM module) there is an example that reads:<br>
<br>
if (method == CANCEL) {<br>
if (!t_relay_cancel()) { # implicit drop if relaying was successful,<br>
# nothing to do<br>
<br>
# corresponding INVITE transaction found but error occurred<br>
sl_reply("500", "Internal Server Error");<br>
drop;<br>
}<br>
# bad luck, corresponding INVITE transaction is missing,<br>
# do the same as for INVITEs<br>
}<br>
<br></div><div class="im">
What bothers me is the phrase#do the same as or INVITEs, because in RFC(<a href="http://tools.ietf.org/html/rfc3261#section-16.10" target="_blank">http://tools.ietf.org/<u></u>html/rfc3261#section-16.10</a> ) it says:<br>
<br>
If a response context is not found, the element does not have any<br></div>
knowledge of the request to apply the CANCEL to. It MUST*statelessly*<div class="im"><br>
forward the CANCEL request (it may have statelessly forwarded the<br>
associated request previously).<br>
<br>
<br>
So aren't we supposed to immediately statelessly forward the CANCEL if t_relay_cancel() did not find the INVITE transaction, instead of doing the same as INVITEs, which could be t_relay() (not stateless)?. Like below:<br>
<br>
<br>
if (method == CANCEL) {<br>
if (!t_relay_cancel()) { # implicit drop if relaying was successful,<br>
<br>
# nothing to do<br>
<br>
# corresponding INVITE transaction found but error occurred<br>
sl_reply("500", "Internal Server Error");<br>
drop;<br>
<br>
}<br>
# bad luck, corresponding INVITE transaction is missing,<br>
<br>
forward();<br>
}<br>
<br>
Am I correct or am i missing something?<br>
</div></blockquote>
<br>
<br>
It could be even more standardized this way indeed. Aparts<br>
from standards, measured by common sense I cannot realize<br>
that either way would break something. The CANCEL should<br>
not be appearing there at all. Perhaps it would make a difference<br>
when SER is restarted and one after it went alive again,<br>
UAC sent a CANCEL. Then what you suggest would perform better.<br>
If you want to make sure you have captured this case, also make<br>
sure that branch ids are configured to be produced statelessly.<br>
Otherwise SER-proxied CANCEL won't match the previous INVITE anyhow.<br>
<br>
other than that, SER is much better than RFC3261. Its<br>
registrar is stateless (in departure from the RFC, otherwise<br>
it would be more vulnerable to DoS attacks), INVITE transaction<br>
is hold after a 200 passes through (otherwise it would not<br>
absorb retransmissions, create another transaction and<br>
cause interop issues), and probably more.<br>
<br>
I just wanted to say it is really important to look first<br>
at what interop issues one may have or not, as SER the<br>
way it is is likely to produce better interop than<br>
consequent standard compliance. In most cases you<br>
can achieve it by configuration changes, I just think<br>
you don't want to :)<br>
<br>
-jiri<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
Thank you in advance,<br>
Bill<br>
<br>
<br>
<br></div>
______________________________<u></u>_________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/<u></u>cgi-bin/mailman/listinfo/sr-<u></u>users</a><br>
<br>
</blockquote>
</blockquote></div><br></div>