[OpenSIPS-Users] Issue with proxy failover and uac_auth()

Wed Jun 4 01:24:46 UTC 2025

Thanks @Bogdan-Andrei Iancu <bogdan at 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.Newlin at 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-bounces at lists.opensips.org> on behalf of
> Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date: *Tuesday, June 3, 2025 at 10:33 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>, nz deals <
> nzdealshelp at 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.Newlin at 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-bounces at lists.opensips.org> on behalf of nz deals <
> nzdealshelp at gmail.com>
> *Date: *Friday, May 30, 2025 at 10:49 PM
> *To: *OpenSIPS users mailling list <users at 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.Newlin at 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-bounces at lists.opensips.org> on behalf of nz deals <
> nzdealshelp at gmail.com>
> *Date: *Thursday, May 29, 2025 at 9:32 AM
> *To: *OpenSIPS users mailling list <users at 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 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/20250604/3415189b/attachment-0001.html>