[OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking
Federico Edorna
fedorna at anura.com.ar
Thu Oct 29 18:34:47 EST 2020
Hello! I had a similar problem some time ago, when I moved from 2.2 to 2.4
version.
In my case Opensips is acting as a "register proxy", it validates
IP/port from the outside world using permissions module and it maps to a
username/password to a UAS in the internal network. I use it for UAC's that
cannot register (or cannot have credentials) but have a public fixed IP
address, in this way I simulate a registration from the enduser and
opensips responds to the INVITE challenge using uac_auth/uac modules as a
client.
So, an INVITE arrives to opensips, then opensips relays it to internal
Registrar Server. Registrar server replies a "SIP 407 Proxy
Authentication", opensips catch it in failure_route and generates the auth
response using uac_auth().
This was working fine in version 2.2 using fix_nated_contact()
and topology_hiding(). When I moved to 2.4, the fix_nated_contact() seems
to change contact twice: in the first INVITE relayed to de Registrar Server
(that's ok!), but also when it generates the self generated authenticated
INVITE.
I searched in my old emails and I founded some debug logs in the first
INVITE (contact changed from private to public)
18:15:22.245403-03:00 DBG:dialog:dlg_update_contact: Replacing old
contact <sip:3304 at 192.168.20.70:6060> for dialog 0x7f8ab6a8c808 on leg
018:15:22.245409-03:00 DBG:dialog:dlg_update_contact: Updated contact
to <sip:3304 at 143.208.44.38:6060> for dialog 0x7f8ab6a8c808 on leg 0
but on the self generated INVITE, contact is changed again (from public to
private)
18:15:22.252208-03:00 /home/gc/local/regproxy/sbin/opensips[335]:
DBG:dialog:dlg_update_contact: Replacing old contact
<sip:3304 at 143.208.44.38:6060> for dialog 0x7f8ab6a8c808 on leg
018:15:22.252212-03:00 /home/gc/local/regproxy/sbin/opensips[335]:
DBG:dialog:dlg_update_contact: Updated contact to
<sip:3304 at 192.168.20.70:6060> for dialog 0x7f8ab6a8c808 on leg 0
Turning off topology_hiding(), solves the issue and contact is only changed
once. I tried to look into the code following the dlg_update_contact
function, what I'd noticed comparing 2.2 and 2.4 version is that in 2.2
something is saved in th_sent_contact field, so that decided me to turn
topology_hiding off as a workaround.
https://github.com/OpenSIPS/opensips/blob/2.2/modules/dialog/dlg_handlers.c#L1148-L1164
https://github.com/OpenSIPS/opensips/blob/2.4/modules/dialog/dlg_handlers.c#L1177-L1188
Hope it helps, hope I didn't make you waste time :)
Federico
On Thu, Oct 29, 2020 at 10:43 AM Jeff Pyle <jeff at ugnd.org> wrote:
> Yes, and only when topology_hiding() is called later. No t_newtran().
>
> How can one see the fixed Contact in the script? I've tried xlog with
> $ct, but that always shows the original one. I know it's being lost (or
> not) only by looking at callee_contact from dlg_list. If I can see the
> updated one I can be more precise about where I'm losing it.
>
>
> - Jeff
>
>
>
>
> On Thu, Oct 29, 2020 at 5:45 AM Răzvan Crainea <razvan at opensips.org>
> wrote:
>
>> Hi, Jeff!
>>
>> So you're claiming that the updated contact is lost even if you call
>> fix_nated_contact() before topology_hiding(), but only for the second
>> branch? Are you calling t_newtran() anywhere in your script?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 10/28/20 8:30 PM, Jeff Pyle wrote:
>> > Liviu,
>> >
>> > It looks like the fixed/update contact is lost only when
>> > topology_hiding() is involved. Would you prefer a separate issue, or
>> > shall I append the issue you referenced before?
>> >
>> >
>> > - Jeff
>> >
>> >
>> > On Wed, Oct 28, 2020 at 2:15 PM Jeff Pyle <jeff at ugnd.org
>> > <mailto:jeff at ugnd.org>> wrote:
>> >
>> > Hey Liviu,
>> >
>> > fix_nated_contact() before topology_hiding(). Got it. As far as
>> > losing the fixed contact during a serial fork, I'll do more testing
>> > to localize exactly which combination of circumstances causes this
>> > to surface and open a bug report.
>> >
>> >
>> > - Jeff
>> >
>> >
>> > On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu <liviu at opensips.org
>> > <mailto:liviu at opensips.org>> wrote:
>> >
>> > Hi!
>> >
>> > On 28.10.2020 18:49, Jeff Pyle wrote:
>> >> First, I lose the updated Contact from fix_nated_contact()
>> >> after a serial fork. Is this expected?
>> > I would assume the `fix_nated_contact()` lump changes get backed
>> > up into shared memory, then made available during the
>> > failure_route. Anything else and IMHO it looks like a bug.
>> > Opinions welcome.
>> >>
>> >> 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.
>> >
>> > This one is a known, documented issue. Long story short: you
>> > should always call fix_nated_contact() _before_
>> > topology_hiding(). See this truth table for more info [1].
>> >
>> > [1]: https://github.com/OpenSIPS/opensips/issues/2172
>> >
>> > --
>> > Liviu Chircu
>> > www.twitter.com/liviuchircu <
>> http://www.twitter.com/liviuchircu> |www.opensips-solutions.com <
>> http://www.opensips-solutions.com>
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20201029/d414127e/attachment.html>
More information about the Users
mailing list