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
