<div dir="ltr">It looks like I'm fighting two separate issues.  Here's what I know so far.<div><br></div><div>First, I lose the updated Contact from <font face="monospace" size="1">fix_nated_contact()</font> after a serial fork.  Is this expected?</div><div><br></div><div>Second, I've determined that if the Contact URI is not wrapped in <font face="monospace" size="1"><></font>, that's when I get the "second attempt to change URI Contact" error when running <font face="monospace" size="1">fix_nated_contact()</font> in the <font face="monospace" size="1">branch_route[]</font>.  This feels like a bug.</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div><div><br></div><div><br></div><div><br></div><div>- Jeff</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 27, 2020 at 8:31 PM Jeff Pyle <<a href="mailto:jeff@ugnd.org">jeff@ugnd.org</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"><div dir="ltr">Hello,<div><br></div><div>This is on OpenSIPS 2.4.8.  Early in the script:<br><br><font face="monospace" size="1">        if (nat_uac_test("34")) {               # 2, 32<br>                setflag(NAT_FLAG);<br>                fix_nated_contact();<br>                force_rport(); <br>        }</font><br></div><div><br></div><div>Later in the script I run <font face="monospace" size="1">topology_hiding("CD")</font>, and then <font size="1" face="monospace">t_relay()</font> an inbound initial INVITE upstream to another system that returns a 302 with Contacts.  I handle that in a <font size="1" face="monospace">failure_route[]</font> by serializing the branches and relaying to them one at a time.  I don't have to go around this <font face="monospace" size="1">t_relay()</font> -> <font size="1" face="monospace">failure_route[]</font> loop much because the first Contact usually handles the request.</div><div><br></div><div>The problem I notice is that the updated Contact from <font face="monospace" size="1">fix_nated_contact()</font> early in the script is lost after I do the initial <font face="monospace" size="1">t_relay()</font> to the redirector to get the 302.  To work around that, I've modified the script above to not <font face="monospace" size="1">fix_nated_contact()</font> there, but do it in the <font face="monospace" size="1">branch_route[]</font> relaying to the first Contact from the 302 and then only if NAT_FLAG is set.  That seems to be fine in most cases.</div><div><br></div><div>I one case from one phone system where OpenSIPS complains:</div><div><font face="monospace" size="1">  ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to change URI Contact</font></div><div><br></div><div>This happens when I run <font face="monospace" size="1">fix_nated_contact()</font> in the <font size="1" face="monospace">branch_route[]</font> for the first and only time.  I can't duplicate it with my own traffic in the lab and it's maddening; it only happens with this one system that's not mine to play with.  I've captured the messaging and don't see anything different in the INVITEs coming into OpenSIPS, just some cosmetic stuff like one system includes :5060 on the From domain and one doesn't.  Nothing that should affect OpenSIPS' behavior in any of this.  It'll be very difficult to get a full OpenSIPS debug in this case because it's on a production system but there's got to be <i>something</i>.  Anyway...</div><div><br></div><div>So, it appears I have some strange interaction between <font face="monospace" size="1">fix_nated_contact()</font>, <font face="monospace" size="1">topology_hiding()</font> and serial forking.  I mention <font face="monospace" size="1">topology_hiding()</font> because it's the only thing I can think of in my scenario that would update the Contact outside of <font size="1" face="monospace">fix_nated_contact()</font>.</div><div><br></div><div>I'm stumped.  Any thoughts?</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div></div>
</blockquote></div>