<div dir="ltr">Hi Daniel,<div><br></div><div>I see that call-id (and other dialog identifiers) matching are controlled by configuration but not IP:Port in via. It's hard-coded in via_matching() called from matching_3261().</div><div><br></div><div>Thanks,</div><div>-volkan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 5, 2015 at 9:49 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
<br>
the cancel is matched based on via branch value or the other tokens
in the request (callid, cseq, ...). If you want to restrict on
matching by source ip/port, you have to do it in the configuration
file.<br>
<br>
I guess that gives you what you need by default.<br>
<br>
Cheers,<br>
Daniel<div><div class="h5"><br>
<br>
<div>On 04/06/15 21:22, Volkan Hatem wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hi All,<br>
<br>
I searched list archives and have not seen a discussion on this
issue.<br>
<br>
According to 3261, CANCEL transaction matching follows the rules
listed in section 17.2.3:<br>
<br>
[...snip...]<br>
1. the branch parameter in the request is equal to the one
in the<br>
top Via header field of the request that created the<br>
transaction, and<br>
<br>
2. the sent-by value in the top Via of the request is
equal to the<br>
one in the request that created the transaction, and<br>
[...snip...]<br>
<br>
However, according to RFC 6141 (which I don't think kamailio
implemented yet) suggests generating a CANCEL request (UAC)
after losing contact (section 5.5):<br>
<br>
[...snip...]<br>
<br>
When a UAC moves to a new contact and loses its old contact,
it will<br>
not be able to receive responses to the re-INVITE.
Consequently, it<br>
will never generate an ACK request.<br>
<br>
Such a UAC SHOULD generate a CANCEL request to cancel the
re-INVITE<br>
and cause the INVITE client transaction corresponding to the<br>
re-INVITE to enter the "Terminated" state. The UAC SHOULD
also send<br>
a new re-INVITE in order to make sure that both UAs have a
common<br>
view of the state of the session.<br>
<div>[...snip...]</div>
<div><br>
</div>
<div>My interpretation is that sent-by comparison is ruled out
because clearly IP:PORT will not match anymore.</div>
<div><br>
</div>
<div>Do you think this is the right interpretation?</div>
<div><br>
</div>
<div>Is there a plan to implement RFC 6141?</div>
<div><br>
</div>
<div>Regards,</div>
<div>-volkan</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<pre cols="72">--
Daniel-Constantin Mierla
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Book: SIP Routing With Kamailio - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a></pre>
</font></span></div>
<br>_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br></blockquote></div><br></div>