[OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

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 <jeff at ugnd.org> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20201028/c8c1e053/attachment.html>