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@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@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@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@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 <j...@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 <raz...@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 <j...@ugnd.org >> > <mailto:j...@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 <li...@opensips.org >> > <mailto:li...@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@lists.opensips.org <mailto:Users@lists.opensips.org> >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users@lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users