<div dir="ltr">Thanks for the reply. I haven't used add_contact_alias/handle_ruri_alias before - how would I make use of them?<div><br></div><div>Should I call add_contact_alias() in the 200 reply route? And if so - when do I call handle_ruri_alias()?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2019 at 6:00 PM Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I may be mistaken, but my reading of 3261 is that a final dialog-forming response may update the remote target (Contact) previously sent by an early dialog-forming provisional reply.<br>
<br>
That having been said, apart from using nathelper techniques (add_contact_alias() and handle_ruri_alias()), I can’t see a good way to deal with this problem. In general, SIP doesn’t really contemplate situations where the network and transport-layer reachability information of an endpoint changes mid-dialog except as part of a target refresh request (UPDATE, re-INVITE).<br>
<br>
—<br>
Sent from mobile, with due apologies for brevity and errors.<br>
<br>
> On Oct 25, 2019, at 10:37 AM, Oded Arbel <<a href="mailto:odeda@cloudonix.io" target="_blank">odeda@cloudonix.io</a>> wrote:<br>
> <br>
> <br>
> Hi, we are having a problem with a network change use case. It goes on something like this:<br>
> <br>
> 1. Kamailio receives INVITE from caller.<br>
> 2. Kamailio sends INVITE to callee MUA.<br>
> 3. MUA response with 100, then 183.<br>
> 4. MUA then loses network connectivity and re-establishes access with another IP address.<br>
> 5. MUA sends 200 OK from the new IP address, but with `Contact` still set as the old address (which I think it should, because you aren't allowed to change contact in the middle of dialog?)<br>
> 6. Kamailio forwards 200 OK to caller and receives ACK.<br>
> 7. Kamailio sends ACK to old IP address of MUA.<br>
> <br>
> The last step is obviously a problem as the MUA will not be able to see the ACK.<br>
> <br>
> I'm trying to see how to resolve this issue. I can capture the "$si" and "$sp" of the new address in the reply route (I also tried to get the MUA to send OPTIONS immediately after reestablishing connectivity, and capture "$si"/"$sp" there, which also works), but I can't figure out how to update the destination of the ACK. I've tried running `fix_nated_contact()` as well as trying to write into various pseudo variables - in either the OPTIONS request handler or the 200 reply handler - which either errors or does nothing.<br>
> <br>
> Any suggestions?<br>
> -- <br>
> Oded Arbel<br>
> <br>
> _______________________________________________<br>
> Kamailio (SER) - Users Mailing List<br>
> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Oded Arbel<div>CTO, VP R&D</div><div>Cloudonix</div></div></div>