<div dir="ltr"><div>Apologies, you're right that the lookup() would not apply in this case.<br><br></div>So what, if anything, should Kamailio do in the case where a SUA's address changes during a call?<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 August 2015 at 13:42, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<span class=""><br>
<br>
On 08/17/2015 11:22 PM, David Cunningham wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We have a scenario like this:<br>
<br>
SUA -> Kamailio with registrar module -> Asterisk<br>
<br>
A call from the SUA is set up with SIP timers, and after 15 minutes<br>
Asterisk sends a re-INVITE to Kamailio to forward on to the SUA. That<br>
re-INVITE has a RURI with the address and port of the SUA at the time<br>
the call started.<br>
<br>
Now if the SUA re-registers after the call starts and before the<br>
re-INVITE, and is on a new address or port number, then the re-INVITE<br>
never gets to the phone.<br>
<br>
Obviously Kamailio should send the re-INVITE to the new address/port,<br>
but is not. The re-INVITE is routed using the lookup() function.<br>
<br>
Can anyone suggest why this is happening?<br>
</blockquote>
<br></span>
Reinvites are just ordinary in-dialog requests, and thus should be routed as in-dialog requests, in the loose_route() section of the config file, i.e.<br>
<br>
if(has_totag()) {<br>
if(loose_route()) {<br>
if(!t_relay())<br>
sl_reply_error();<br>
<br>
exit;<br>
} else {<br>
if(is_method("ACK")) {<br>
if(t_check_trans())<br>
t_relay();<br>
<br>
exit;<br>
}<br>
<br>
sl_send_reply("403", "Forbidden");<br>
}<br>
<br>
exit;<br>
}<br>
<br>
In-dialog requests (including reinvites) should _never_ be routed dynamically, e.g. based on lookup(). For dialogs that are established through the proxy and where the proxy requests to remain in the path of in-dialog requests by adding a Record-Route header, the in-dialog requests follow a strictly predetermined path that was computed at the time of the establishment of the dialog. This is true of end-to-end ACKs (for 2xx replies), reinvites, BYEs, etc.<br>
<br>
Additionally, the Request URI of the in-dialog request should be equal to the Contact URI of the remote party to the dialog. This is known as the "remote target" in standards parlance. It is at the time of the initial dialog-forming request routing that all NAT-related considerations are computed, e.g. countermeasures for the difference between the outward representations made by a party's Contact URI and the actual network and transport-layer source from which the initial request or reply originated.<br>
<br>
So, in short, you shouldn't be doing anything other than the abovementioned logic to route a reinvite, notwithstanding RTP pivoting measures if using rtpproxy/rtpengine.<br>
<br>
-- Alex<br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
303 Perimeter Center North, Suite 300<br>
Atlanta, GA 30346<br>
United States<br>
<br>
Tel: <a href="tel:%2B1-800-250-5920" value="+18002505920" target="_blank">+1-800-250-5920</a> (toll-free) / <a href="tel:%2B1-678-954-0671" value="+16789540671" target="_blank">+1-678-954-0671</a> (direct)<br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
<br>
_______________________________________________<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" rel="noreferrer" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">David Cunningham, Voisonics<br><a href="http://voisonics.com/" target="_blank">http://voisonics.com/</a><br>USA: +1 213 221 1092<br>UK: +44 (0) 20 3298 1642<br>Australia: +61 (0) 2 8063 9019<br></div>
</div>