Thanks @Bogdan-Andrei Iancu <bog...@opensips.org> and @Ben I got the same question, if we disable the failover then what's the benefit of having multiple SRV records for the proxy.
Plus I think that the Authorization should not be dropped when it does the failover. Any recommendations to resolve this issue? Regards, Jason On Wed, 4 Jun 2025 at 03:33, Ben Newlin <ben.new...@genesys.com> wrote: > Bogdan, > > > > I’m not sure this completely solves the problem. Removing DNS failover > from the TM module would make the script responsible for the failover. > Given that they’ve indicated this is an SRV record, this would force them > to make some sort of external call to resolve the SRV themselves, as I > don’t think the ip.resolve transformation will handle SRV. > > > > That is a lot of work to solve the issue when compared to the question of > why the Authenticate would be dropped by the TM module on DNS failover to > begin with? Is there some use case for that which would make it not a bug? > I don’t think the TM module should ever be changing the SIP message on DNS > failover. > > > > Ben Newlin > > > > *From: *Users <users-boun...@lists.opensips.org> on behalf of > Bogdan-Andrei Iancu <bog...@opensips.org> > *Date: *Tuesday, June 3, 2025 at 10:33 AM > *To: *OpenSIPS users mailling list <users@lists.opensips.org>, nz deals < > nzdealsh...@gmail.com> > *Subject: *Re: [OpenSIPS-Users] Issue with proxy failover and uac_auth() > > * EXTERNAL EMAIL - Please use caution with links and attachments * > > > ------------------------------ > > Hi, > > I hope I managed to get your report here. If so, take a look at the > "no-dns-failover" option when doing the t_relay(). So you can instruct > OpenSIPS not to do the automatic DNS based failover and give you full > control via failure route. > > Regards, > > Bogdan-Andrei Iancu > > > > OpenSIPS Founder and Developer > > https://www.opensips-solutions.com > > https://www.siphub.com > > On 03.06.2025 03:41, nz deals wrote: > > Is there anyone who has seen this issue? Seems like a bug to me. > > > > Thanks. > > > > Regards, > > Jason > > > > > > On Sun, 1 Jun 2025 at 06:06, Ben Newlin <ben.new...@genesys.com> wrote: > > Oh sorry I missed that in your email. I thought you were trying to avoid > the failover. > > > > Dropping the auth info on the DNS failover I don’t think is expected, > since a DNS failover doesn’t trigger failure_route so you can’t add it back. > > > > I’d recommend opening a bug for this on the Github, but maybe someone else > has ideas. > > > > Ben Newlin > > > > *From: *Users <users-boun...@lists.opensips.org> on behalf of nz deals < > nzdealsh...@gmail.com> > *Date: *Friday, May 30, 2025 at 10:49 PM > *To: *OpenSIPS users mailling list <users@lists.opensips.org> > *Subject: *Re: [OpenSIPS-Users] Issue with proxy failover and uac_auth() > > * EXTERNAL EMAIL - Please use caution with links and attachments * > > > ------------------------------ > > Thank you for your response. > > The problem is, opensips sends the INVITE to secondary srv (failed over) > without Authorization. It makes sense that the dns failover is not managed > by opensips but atleast the same INVITE should be failover to the > secondary. Why the Authorization is removed when it goes to the secondary. > > > > Thanks > > > > On Sat, 31 May 2025 at 03:52, Ben Newlin <ben.new...@genesys.com> wrote: > > The issue here is not really with the uac_auth module, as that module > isn’t sending the message only updating it with the correct authentication > info. > > > > This is normal and correct behavior. When you send the message the second > time using the same DNS, it will follow the same process as the first, > trying A then timing out and failing over to B. Standard DNS SRV doesn’t > include any behavior to try to avoid non-responding nodes. > > > > Ultimately what you need is to know the actual IP that elicited the 401 so > the next INVITE with the authentication can be sent to the same one, using > $du or $dd(:$dp). Have you tried to get the remote IP in onreply_route and > store it is an AVP using $si [1] or $socket_in [2]? I don’t think I’ve ever > used one of these in a reply route. The documentation doesn’t specify > whether it is valid and they will contain the source of the reply, not the > request. > > > > [1] - https://www.opensips.org/Documentation/Script-CoreVar-3-6#si > > [2] - https://www.opensips.org/Documentation/Script-CoreVar-3-6#socket_in > > > > Ben Newlin > > > > *From: *Users <users-boun...@lists.opensips.org> on behalf of nz deals < > nzdealsh...@gmail.com> > *Date: *Thursday, May 29, 2025 at 9:32 AM > *To: *OpenSIPS users mailling list <users@lists.opensips.org> > *Subject: *[OpenSIPS-Users] Issue with proxy failover and uac_auth() > > * EXTERNAL EMAIL - Please use caution with links and attachments * > > > ------------------------------ > > Hi All, > > I'm using OpenSIPS 3.4 and managing carrier trunks via the registrant > table. In the table, I'm using a proxy value like sips:mysip.xx.x > > When the primary carrier A sbc SRV record becomes unreachable, OpenSIPS > correctly times out INVITE and attempts to fail over to the secondary A > record (via SRV). > > The secondary endpoint responds with a 401 Unauthorized and includes a > WWW-Authenticate header. At this point, I assume that opensips should not > try on the primary carrier A SRV record otherwise it will also timeout. but > it is trying to send another INVITE with Authorization to the primary. this > timeout because primary A SRV record is not responding. opensips sends > another INVITE to secondary and this time its without Authorization. > > Is there any way to fix this or work around it? Has anyone faced a similar > problem when using uac_auth() in combination with failover and the same > proxy domain? > > Any advice or suggestions would be greatly appreciated. > > > > > > > > Thank you > > > > Regards, > > Jason > > > > _______________________________________________ > 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
