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

[nz deals]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250603/24732d04/attachment.html>