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

[Ben Newlin]

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<mailto: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<https://www.opensips.org/Documentation/Script-CoreVar-3-6#si>
[2] - https://www.opensips.org/Documentation/Script-CoreVar-3-6#socket_in<https://www.opensips.org/Documentation/Script-CoreVar-3-6#socket_in>

Ben Newlin

From: Users <users-bounces at lists.opensips.org<mailto:users-bounces at lists.opensips.org>> on behalf of nz deals <nzdealshelp at gmail.com<mailto:nzdealshelp at gmail.com>>
Date: Thursday, May 29, 2025 at 9:32 AM
To: OpenSIPS users mailling list <users at lists.opensips.org<mailto: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<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250531/e6323b93/attachment-0001.html>