It looks like I'm fighting two separate issues. Here's what I know so far.
First, I lose the updated Contact from fix_nated_contact() after a serial fork. Is this expected? Second, I've determined that if the Contact URI is not wrapped in <>, that's when I get the "second attempt to change URI Contact" error when running fix_nated_contact() in the branch_route[]. This feels like a bug. - Jeff - Jeff On Tue, Oct 27, 2020 at 8:31 PM Jeff Pyle <[email protected]> wrote: > Hello, > > This is on OpenSIPS 2.4.8. Early in the script: > > if (nat_uac_test("34")) { # 2, 32 > setflag(NAT_FLAG); > fix_nated_contact(); > force_rport(); > } > > Later in the script I run topology_hiding("CD"), and then t_relay() an > inbound initial INVITE upstream to another system that returns a 302 with > Contacts. I handle that in a failure_route[] by serializing the branches > and relaying to them one at a time. I don't have to go around this > t_relay() -> failure_route[] loop much because the first Contact usually > handles the request. > > The problem I notice is that the updated Contact from fix_nated_contact() > early in the script is lost after I do the initial t_relay() to the > redirector to get the 302. To work around that, I've modified the script > above to not fix_nated_contact() there, but do it in the branch_route[] > relaying to the first Contact from the 302 and then only if NAT_FLAG is > set. That seems to be fine in most cases. > > I one case from one phone system where OpenSIPS complains: > ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to > change URI Contact > > This happens when I run fix_nated_contact() in the branch_route[] 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 *something*. Anyway... > > So, it appears I have some strange interaction between fix_nated_contact(), > topology_hiding() and serial forking. I mention topology_hiding() > because it's the only thing I can think of in my scenario that would update > the Contact outside of fix_nated_contact(). > > I'm stumped. Any thoughts? > > > - Jeff > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
