From voransoy at gmail.com  Sun Jun  1 21:05:56 2025
From: voransoy at gmail.com (Volkan Oransoy)
Date: Sun, 1 Jun 2025 22:05:56 +0100
Subject: [OpenSIPS-Users] ACK request uri issue
In-Reply-To: <34831A66-D744-4313-88E5-B5194E3813C8@ag-projects.com>
References: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>
 <15E989C1-F11C-45A3-8C03-78225D250C91@ag-projects.com>
 <CAM_EGOHy46xMvo8PN_6c1uoPQMtogfmMPwaWGrPFpf7jZAM6Qg@mail.gmail.com>
 <34831A66-D744-4313-88E5-B5194E3813C8@ag-projects.com>
Message-ID: <CAM_EGOEPP4rR2=thPNj=sNzFgSauQzoUka50K6EKk92ObunCjg@mail.gmail.com>

Hi Adrian

It worked just as you described.

Thanks a lot.

On Sat, 31 May 2025 at 15:54, Adrian Georgescu <ag at ag-projects.com> wrote:

> You can use store_dlg_value() to save the values of parsed headers like
> Contact header $ct.fields(uri) and retrieve them later from $dlg_val
> variable
>
> If you have configured a stateful proxy and have the dialog module loaded
> the dialogs should be matched automatically.
>
>
> > On May 31, 2025, at 11:58, Volkan Oransoy <voransoy at gmail.com> wrote:
> >
> > Hi Adrian
> >
> > Thank you for your reply. I've had a look at the documentation. Can
> match_dialog function handle this case?
> >
> > Thanks
> >
> > On Sat, 31 May 2025 at 10:20, Adrian Georgescu <ag at ag-projects.com>
> wrote:
> > You can save using the dialog module, the Contact uri from the 200 OK,
> then when the ACK comes in, you replace the $ru with the previously saved
> value.
> >
> > > On May 31, 2025, at 10:07, Volkan Oransoy <voransoy at gmail.com> wrote:
> > >
> > > Hi all
> > >
> > > I am trying to integrate a 3rd party UAC with my Opensips box and have
> an issue.
> > > The UAC sends an INVITE with an initial request uri and my box replies
> with 200 OK.
> > > But the subsequent ACK sent by the UAC comes with the same request uri
> with the INVITE. My box expects the ACK request uri to be the Contact field
> of the 200 OK. So the ACK routing fails.
> > > How can I rectify this on my end?
> > >
> > > Best
> > >
> > > --
> > > Volkan Oransoy
> > > _______________________________________________
> > > 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
> >
> >
> > --
> > Volkan Oransoy
> > _______________________________________________
> > 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
>


-- 
Volkan Oransoy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250601/cc6f975c/attachment.html>

From nzdealshelp at gmail.com  Tue Jun  3 00:41:41 2025
From: nzdealshelp at gmail.com (nz deals)
Date: Tue, 3 Jun 2025 12:41:41 +1200
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
In-Reply-To: <BN0PR10MB5208F255BFB83215EF3312159560A@BN0PR10MB5208.namprd10.prod.outlook.com>
References: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>
 <DS7PR10MB52140D9783A974A0F09EACAB9561A@DS7PR10MB5214.namprd10.prod.outlook.com>
 <CALOQYisEZSk5+fBaZC39fO69Yrt1-fVXZ7jj=VC_CCZ2pgb6dw@mail.gmail.com>
 <BN0PR10MB5208F255BFB83215EF3312159560A@BN0PR10MB5208.namprd10.prod.outlook.com>
Message-ID: <CALOQYiu=ibBN2JpyZap0YusguG1Xq+Aauh0woaGtevS_U1+4Fg@mail.gmail.com>

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>

From walter.schober at neotel.at  Tue Jun  3 08:50:10 2025
From: walter.schober at neotel.at (Walter Schober)
Date: Tue, 3 Jun 2025 08:50:10 +0000
Subject: [OpenSIPS-Users] Siprec subscribe-answer rtpengine flags
Message-ID: <1AFD1281-CAED-4D0E-A0AA-51D5125054F2@neotel.eu>

Hi!

I’ve successfully managed to record a call via SIPREC module using OpenSIPS 3.6.0 and RTPEngine 13.2.

But I needed to do a trick to have the subscribe-answer to allow transcoding: I used a template „default“ in the rtpengine.conf to set

[templates]
default = allow-transcoding asymmetric

This is global unfortunately. I searched all the module documentations siprec, dialog, rtp_relay (I understood: rtpengine cannot be done directly in 3.6 with siprec). I looked even into source code.
I haven’t found any hint how to add RTPEngine flag „allow-transcoding“ to the „subscribe answer“ command in opensips.

Did I miss something or is this not possible?

Thanks for help me understanding this!
br
Walter


From bogdan at opensips.org  Tue Jun  3 12:39:38 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 3 Jun 2025 15:39:38 +0300
Subject: [OpenSIPS-Users] Domain module documentation for 3.6
In-Reply-To: <CAND0LkuuP=jAveAkCXVaGeqf40273G_iXct8B6NxKJEu3Kz4KA@mail.gmail.com>
References: <CAND0LkuuP=jAveAkCXVaGeqf40273G_iXct8B6NxKJEu3Kz4KA@mail.gmail.com>
Message-ID: <f943a9e4-6549-46c2-84f3-851c52b653c5@opensips.org>

Hi Ovidiu,

Thanks for pointing this up. I updated the docs, but the online html 
will be re-generated by tomorrow.

In terms of migration there is nothing to be mentioned IMHO - the 
"migrate" DB tool is taking care of that (by adding the new column). 
Also the presence of the column is backward compatible, you don;t even 
have to be aware of its existence. If you feel like something useful can 
be mentioned, please pass me the paragraph and I will copy it into the 
migration page.

Thanks and regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 23.05.2025 19:32, Ovidiu Sas wrote:
> The documentation for accept_subdomain column is missing from the README file.
> Also, some notes should be added to the migration web page:
> https://www.opensips.org/Documentation/Migration-3-5-0-to-3-6-0
>
> -ovidiu
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Tue Jun  3 12:42:55 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 3 Jun 2025 15:42:55 +0300
Subject: [OpenSIPS-Users] ACK request uri issue
In-Reply-To: <CAM_EGOEPP4rR2=thPNj=sNzFgSauQzoUka50K6EKk92ObunCjg@mail.gmail.com>
References: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>
 <15E989C1-F11C-45A3-8C03-78225D250C91@ag-projects.com>
 <CAM_EGOHy46xMvo8PN_6c1uoPQMtogfmMPwaWGrPFpf7jZAM6Qg@mail.gmail.com>
 <34831A66-D744-4313-88E5-B5194E3813C8@ag-projects.com>
 <CAM_EGOEPP4rR2=thPNj=sNzFgSauQzoUka50K6EKk92ObunCjg@mail.gmail.com>
Message-ID: <67de5026-ec6f-4d7f-9cbe-16c63eeda9fc@opensips.org>

Hi Volkan,

A simpler approach (with no manual storing) may be achieved via the 
fix_route_dialog() [1]. You can use this function after a match_dialog() 
on the ACK.

[1] 
https://opensips.org/html/docs/modules/3.5.x/dialog.html#func_fix_route_dialog

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 02.06.2025 00:05, Volkan Oransoy wrote:
> Hi Adrian
>
> It worked just as you described.
>
> Thanks a lot.
>
> On Sat, 31 May 2025 at 15:54, Adrian Georgescu <ag at ag-projects.com> wrote:
>
>     You can use store_dlg_value() to save the values of parsed headers
>     like Contact header $ct.fields(uri) and retrieve them later from
>     $dlg_val variable
>
>     If you have configured a stateful proxy and have the dialog module
>     loaded the dialogs should be matched automatically.
>
>
>     > On May 31, 2025, at 11:58, Volkan Oransoy <voransoy at gmail.com>
>     wrote:
>     >
>     > Hi Adrian
>     >
>     > Thank you for your reply. I've had a look at the documentation.
>     Can match_dialog function handle this case?
>     >
>     > Thanks
>     >
>     > On Sat, 31 May 2025 at 10:20, Adrian Georgescu
>     <ag at ag-projects.com> wrote:
>     > You can save using the dialog module, the Contact uri from the
>     200 OK, then when the ACK comes in, you replace the $ru with the
>     previously saved value.
>     >
>     > > On May 31, 2025, at 10:07, Volkan Oransoy <voransoy at gmail.com>
>     wrote:
>     > >
>     > > Hi all
>     > >
>     > > I am trying to integrate a 3rd party UAC with my Opensips box
>     and have an issue.
>     > > The UAC sends an INVITE with an initial request uri and my box
>     replies with 200 OK.
>     > > But the subsequent ACK sent by the UAC comes with the same
>     request uri with the INVITE. My box expects the ACK request uri to
>     be the Contact field of the 200 OK. So the ACK routing fails.
>     > > How can I rectify this on my end?
>     > >
>     > > Best
>     > >
>     > > --
>     > > Volkan Oransoy
>     > > _______________________________________________
>     > > 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
>     >
>     >
>     > --
>     > Volkan Oransoy
>     > _______________________________________________
>     > 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
>
>
>
> -- 
> Volkan Oransoy
>
> _______________________________________________
> 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/ec3a2421/attachment.html>

From wadii at evenmedia.fr  Tue Jun  3 12:59:05 2025
From: wadii at evenmedia.fr (Wadii ELMAJDI | Evenmedia)
Date: Tue, 3 Jun 2025 12:59:05 +0000
Subject: [OpenSIPS-Users] ACK request uri issue
In-Reply-To: <67de5026-ec6f-4d7f-9cbe-16c63eeda9fc@opensips.org>
References: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>
 <15E989C1-F11C-45A3-8C03-78225D250C91@ag-projects.com>
 <CAM_EGOHy46xMvo8PN_6c1uoPQMtogfmMPwaWGrPFpf7jZAM6Qg@mail.gmail.com>
 <34831A66-D744-4313-88E5-B5194E3813C8@ag-projects.com>
 <CAM_EGOEPP4rR2=thPNj=sNzFgSauQzoUka50K6EKk92ObunCjg@mail.gmail.com>
 <67de5026-ec6f-4d7f-9cbe-16c63eeda9fc@opensips.org>
Message-ID: <PAYP264MB34858B350DFF5E08BD6F412ECE6DA@PAYP264MB3485.FRAP264.PROD.OUTLOOK.COM>

[like]  Wadii ELMAJDI | Evenmedia reacted to your message:
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of Bogdan-Andrei Iancu <bogdan at opensips.org>
Sent: Tuesday, June 3, 2025 12:42:55 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>; Volkan Oransoy <voransoy at gmail.com>
Subject: Re: [OpenSIPS-Users] ACK request uri issue

Hi Volkan,

A simpler approach (with no manual storing) may be achieved via the fix_route_dialog() [1]. You can use this function after a match_dialog() on the ACK.

[1] https://opensips.org/html/docs/modules/3.5.x/dialog.html#func_fix_route_dialog

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 02.06.2025 00:05, Volkan Oransoy wrote:
Hi Adrian

It worked just as you described.

Thanks a lot.

On Sat, 31 May 2025 at 15:54, Adrian Georgescu <ag at ag-projects.com<mailto:ag at ag-projects.com>> wrote:
You can use store_dlg_value() to save the values of parsed headers like Contact header $ct.fields(uri) and retrieve them later from $dlg_val variable

If you have configured a stateful proxy and have the dialog module loaded the dialogs should be matched automatically.


> On May 31, 2025, at 11:58, Volkan Oransoy <voransoy at gmail.com<mailto:voransoy at gmail.com>> wrote:
>
> Hi Adrian
>
> Thank you for your reply. I've had a look at the documentation. Can match_dialog function handle this case?
>
> Thanks
>
> On Sat, 31 May 2025 at 10:20, Adrian Georgescu <ag at ag-projects.com<mailto:ag at ag-projects.com>> wrote:
> You can save using the dialog module, the Contact uri from the 200 OK, then when the ACK comes in, you replace the $ru with the previously saved value.
>
> > On May 31, 2025, at 10:07, Volkan Oransoy <voransoy at gmail.com<mailto:voransoy at gmail.com>> wrote:
> >
> > Hi all
> >
> > I am trying to integrate a 3rd party UAC with my Opensips box and have an issue.
> > The UAC sends an INVITE with an initial request uri and my box replies with 200 OK.
> > But the subsequent ACK sent by the UAC comes with the same request uri with the INVITE. My box expects the ACK request uri to be the Contact field of the 200 OK. So the ACK routing fails.
> > How can I rectify this on my end?
> >
> > Best
> >
> > --
> > Volkan Oransoy
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> --
> Volkan Oransoy
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Volkan Oransoy



_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto: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/dc4f3c13/attachment-0001.html>

From wadii at evenmedia.fr  Tue Jun  3 12:59:10 2025
From: wadii at evenmedia.fr (Wadii ELMAJDI | Evenmedia)
Date: Tue, 3 Jun 2025 12:59:10 +0000
Subject: [OpenSIPS-Users] ACK request uri issue
In-Reply-To: <67de5026-ec6f-4d7f-9cbe-16c63eeda9fc@opensips.org>
References: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>
 <15E989C1-F11C-45A3-8C03-78225D250C91@ag-projects.com>
 <CAM_EGOHy46xMvo8PN_6c1uoPQMtogfmMPwaWGrPFpf7jZAM6Qg@mail.gmail.com>
 <34831A66-D744-4313-88E5-B5194E3813C8@ag-projects.com>
 <CAM_EGOEPP4rR2=thPNj=sNzFgSauQzoUka50K6EKk92ObunCjg@mail.gmail.com>
 <67de5026-ec6f-4d7f-9cbe-16c63eeda9fc@opensips.org>
Message-ID: <PAYP264MB3485F6B82553C29F0B9D941FCE6DA@PAYP264MB3485.FRAP264.PROD.OUTLOOK.COM>

[0]     Wadii ELMAJDI | Evenmedia reacted to your message:
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of Bogdan-Andrei Iancu <bogdan at opensips.org>
Sent: Tuesday, June 3, 2025 12:42:55 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>; Volkan Oransoy <voransoy at gmail.com>
Subject: Re: [OpenSIPS-Users] ACK request uri issue

Hi Volkan,

A simpler approach (with no manual storing) may be achieved via the fix_route_dialog() [1]. You can use this function after a match_dialog() on the ACK.

[1] https://opensips.org/html/docs/modules/3.5.x/dialog.html#func_fix_route_dialog

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 02.06.2025 00:05, Volkan Oransoy wrote:
Hi Adrian

It worked just as you described.

Thanks a lot.

On Sat, 31 May 2025 at 15:54, Adrian Georgescu <ag at ag-projects.com<mailto:ag at ag-projects.com>> wrote:
You can use store_dlg_value() to save the values of parsed headers like Contact header $ct.fields(uri) and retrieve them later from $dlg_val variable

If you have configured a stateful proxy and have the dialog module loaded the dialogs should be matched automatically.


> On May 31, 2025, at 11:58, Volkan Oransoy <voransoy at gmail.com<mailto:voransoy at gmail.com>> wrote:
>
> Hi Adrian
>
> Thank you for your reply. I've had a look at the documentation. Can match_dialog function handle this case?
>
> Thanks
>
> On Sat, 31 May 2025 at 10:20, Adrian Georgescu <ag at ag-projects.com<mailto:ag at ag-projects.com>> wrote:
> You can save using the dialog module, the Contact uri from the 200 OK, then when the ACK comes in, you replace the $ru with the previously saved value.
>
> > On May 31, 2025, at 10:07, Volkan Oransoy <voransoy at gmail.com<mailto:voransoy at gmail.com>> wrote:
> >
> > Hi all
> >
> > I am trying to integrate a 3rd party UAC with my Opensips box and have an issue.
> > The UAC sends an INVITE with an initial request uri and my box replies with 200 OK.
> > But the subsequent ACK sent by the UAC comes with the same request uri with the INVITE. My box expects the ACK request uri to be the Contact field of the 200 OK. So the ACK routing fails.
> > How can I rectify this on my end?
> >
> > Best
> >
> > --
> > Volkan Oransoy
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> --
> Volkan Oransoy
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Volkan Oransoy



_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto: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/f383141f/attachment-0001.html>

From wadii at evenmedia.fr  Tue Jun  3 12:59:10 2025
From: wadii at evenmedia.fr (Wadii ELMAJDI | Evenmedia)
Date: Tue, 3 Jun 2025 12:59:10 +0000
Subject: [OpenSIPS-Users] ACK request uri issue
In-Reply-To: <67de5026-ec6f-4d7f-9cbe-16c63eeda9fc@opensips.org>
References: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>
 <15E989C1-F11C-45A3-8C03-78225D250C91@ag-projects.com>
 <CAM_EGOHy46xMvo8PN_6c1uoPQMtogfmMPwaWGrPFpf7jZAM6Qg@mail.gmail.com>
 <34831A66-D744-4313-88E5-B5194E3813C8@ag-projects.com>
 <CAM_EGOEPP4rR2=thPNj=sNzFgSauQzoUka50K6EKk92ObunCjg@mail.gmail.com>
 <67de5026-ec6f-4d7f-9cbe-16c63eeda9fc@opensips.org>
Message-ID: <PAYP264MB34850230973DF2A59D5F980ACE6DA@PAYP264MB3485.FRAP264.PROD.OUTLOOK.COM>

[like]  Wadii ELMAJDI | Evenmedia reacted to your message:
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of Bogdan-Andrei Iancu <bogdan at opensips.org>
Sent: Tuesday, June 3, 2025 12:42:55 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>; Volkan Oransoy <voransoy at gmail.com>
Subject: Re: [OpenSIPS-Users] ACK request uri issue

Hi Volkan,

A simpler approach (with no manual storing) may be achieved via the fix_route_dialog() [1]. You can use this function after a match_dialog() on the ACK.

[1] https://opensips.org/html/docs/modules/3.5.x/dialog.html#func_fix_route_dialog

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 02.06.2025 00:05, Volkan Oransoy wrote:
Hi Adrian

It worked just as you described.

Thanks a lot.

On Sat, 31 May 2025 at 15:54, Adrian Georgescu <ag at ag-projects.com<mailto:ag at ag-projects.com>> wrote:
You can use store_dlg_value() to save the values of parsed headers like Contact header $ct.fields(uri) and retrieve them later from $dlg_val variable

If you have configured a stateful proxy and have the dialog module loaded the dialogs should be matched automatically.


> On May 31, 2025, at 11:58, Volkan Oransoy <voransoy at gmail.com<mailto:voransoy at gmail.com>> wrote:
>
> Hi Adrian
>
> Thank you for your reply. I've had a look at the documentation. Can match_dialog function handle this case?
>
> Thanks
>
> On Sat, 31 May 2025 at 10:20, Adrian Georgescu <ag at ag-projects.com<mailto:ag at ag-projects.com>> wrote:
> You can save using the dialog module, the Contact uri from the 200 OK, then when the ACK comes in, you replace the $ru with the previously saved value.
>
> > On May 31, 2025, at 10:07, Volkan Oransoy <voransoy at gmail.com<mailto:voransoy at gmail.com>> wrote:
> >
> > Hi all
> >
> > I am trying to integrate a 3rd party UAC with my Opensips box and have an issue.
> > The UAC sends an INVITE with an initial request uri and my box replies with 200 OK.
> > But the subsequent ACK sent by the UAC comes with the same request uri with the INVITE. My box expects the ACK request uri to be the Contact field of the 200 OK. So the ACK routing fails.
> > How can I rectify this on my end?
> >
> > Best
> >
> > --
> > Volkan Oransoy
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> --
> Volkan Oransoy
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org<mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Volkan Oransoy



_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto: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/f0ce05be/attachment-0001.html>

From bogdan at opensips.org  Tue Jun  3 14:22:58 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 3 Jun 2025 17:22:58 +0300
Subject: [OpenSIPS-Users] Potential feature request: OpenSIPS security
 and concept of tainted variables
In-Reply-To: <a7984a4d-f103-43c0-be49-def3d96941b5@app.fastmail.com>
References: <58d13f1c-da96-4b37-a536-dd54202743f0@switchtel.co.za>
 <a7984a4d-f103-43c0-be49-def3d96941b5@app.fastmail.com>
Message-ID: <97ed186c-5d88-4d3e-bc6a-4d124485e534@opensips.org>

Hi all,

While the idea is great, let's me come back with the feedback:

1) not all the values you are handling at script level may be "risky" or 
tainted ... Some may be loaded from DBs or other external services, so 
"trustful". Only what comes from signaling may be risky.

2) the escaping may not be required in all DB op cases - the injection 
is typical for raw queries, but for mysql OpenSIPS does statements. Or 
there are DB backends which are only statement (API) driven, no raw 
queries, like the dbtext for example. So, depending on the DB backend, 
the injection may or not be a problem.

3) while the $unsafe_fU was mentioned as alternative, I do not see the 
difference to using the escape transformation, if really the case.

So whatever improvement we do consider, we need to take the above into 
consideration - there is no need to over complicate things ;)

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 29.05.2025 15:28, Sandro Gauci via Users wrote:
> Thanks for this feedback!
>
> So Gary proposed two potential solutions - tainting and automatic 
> escaping. Thought I'd write a few paragraphs on this approach.
>
> The concept of tainting is appealing, as it resembles how static code 
> analyzers track data flow. Under this approach, user-controlled 
> pseudo-variables would initially be 'tainted.' They would then need to 
> be 'untainted' - effectively marked as safe - but only after 
> undergoing proper validation or another protective mechanism.
>
> Automatically escaping can be problematic and may not fully resolve 
> vulnerabilities, as its effectiveness is highly dependent on the 
> 'sink.' The 'sink' refers to the specific format or language of the 
> dangerous function or data consumer, such as SQL, shell commands, 
> NoSQL, or JSON. While attractive, such 'magical' security solutions 
> are bound to fail in specific cases. This inherent unreliability poses 
> a risk, as OpenSIPS operators would over-rely on them.
>
> Conversely, the optimal approach for building security-sensitive 
> content from user input - content that is subsequently passed to 
> security-sensitive functions - is to employ programmatic techniques 
> (e.g., parameterized queries for SQL) instead of string concatenation. 
> This method offers a more robust programming pattern than relying on 
> tainting or 'magical' solutions.
>
> Cheers!
>
> --
>     Sandro Gauci, CEO at Enable Security GmbH
>
>     Register of Companies:       AG Charlottenburg HRB 173016 B
>     Company HQ: Neuburger Straße 101 b, 94036 Passau, Germany
>     RTCSec Newsletter: https://www.enablesecurity.com/subscribe/
>     Our blog: https://www.enablesecurity.com/blog/
>     Other points of contact: https://www.enablesecurity.com/contact/
>
>
> On Tue, 27 May 2025, at 12:15 PM, Gregory Massel via Users wrote:
>>
>> Hi all
>>
>> After listening to Sandro's presentation at OpenSIPS Summit, and 
>> further to posts I sent on 30 Nov 2023 and 5 Dec 2023 ("Help dropping 
>> SQL injection attacks"), it struck me that the OpenSIPS script allows 
>> for unsafe variable references by default.
>>
>> While extremely powerful, this makes configuration implementations 
>> susceptible to oversights that result in potential injection 
>> vulnerabilities.
>>
>> The Exim project addressed this with the concept of "tainted" 
>> variables. In essence, by default, it prevents you to passing 
>> potentially unsafe variables to dangerous functions without first 
>> filtering or escapting. This may be worth consideration as a security 
>> feature in future versions of OpenSIPS.
>>
>> It may also be worth considering escaping certain variables by 
>> default and aliasing the originals. E.g. Instead of having to 
>> explicitly check variables as follows:
>>
>> if ( $fU != $(fU{s.escape.common}) || $tU != $(tU{s.escape.common}) ) {
>> 	xlog ("Rejecting SQL injection attempt received from $socket_in(proto):$si:$sp (Method: $rm; From: $fu; To: $tu; Contact: $ct).");
>> 	send_reply (403,"Forbidden");
>> 	exit;
>> }
>> if ( $fU != $(fU{s.escape.user}) || $tU != $(tU{s.escape.user}) ) {
>> 	xlog ("Rejecting request with unusual characters received from $socket_in(proto):$si:$sp (Method: $rm; From: $fu; To: $tu; Contact: $ct).");
>> 	send_reply (403,"Forbidden");
>> 	exit;
>> }
>>
>> if ( $(ct.fields(uri){uri.user}) != $(ct.fields(uri){uri.user}{s.escape.common}) ) {
>> 	send_reply (403,"Forbidden");
>> 	exit;
>> }
>> There may be something to be said for having variables like $fU, $tU 
>> escaped by default and adding variables like $unsafe_fU, $unsafe_tU 
>> contain the original variables. Backwards compatibility could be 
>> achieved with a core configuration variable to disable this.
>>
>> Alternatively, as with Exim, if one tries to reference the variables 
>> within a database function or exec function, regard these variables 
>> as "tainted" and throw an error if the {s.escape.common} (or similar) 
>> isn't applied.
>>
>> Regards
>>
>> Greg
>>
>> _______________________________________________
>> 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/be60de5b/attachment.html>

From bogdan at opensips.org  Tue Jun  3 14:28:59 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 3 Jun 2025 17:28:59 +0300
Subject: [OpenSIPS-Users] Understanding aliases core parameter versus
 domain module
In-Reply-To: <4e288c86-463e-482f-83ea-f53c9e352afa@switchtel.co.za>
References: <4e288c86-463e-482f-83ea-f53c9e352afa@switchtel.co.za>
Message-ID: <3445ab9a-15ae-483c-802a-cbf9be00ddc6@opensips.org>

Hi Gregory,

in order to keep this simple. The "alias" parameter is the original, old 
and static way of configuring the SIP domains to be served by OpenSIPS. 
Later, the domain module took over that job, so you do not need the 
alias'ing anymore. We still keep it for simple setups where there is not 
DB support ;)

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 21.05.2025 18:05, Gregory Massel via Users wrote:
> Hello all
>
> I'm trying to understand whether it is necessary to have a core 
> "alias" parameter for every name by which the OpenSIPS server is known 
> or if it's adequate to simple list these in the table that the domain 
> module reads?
>
> At present I have something similar to:
>
> socket=udp:1.2.3.4:5060
>
> alias=udp:host1.domain.com:5060
> alias=udp:host2.domain2.com:5060
> alias=udp:host3.domain3.com:5060
>
> loadmodule "domain.so"
> modparam("domain", "db_url", 
> "mysql://opensips:password at localhost/opensips")
> modparam("domain", "db_mode", 1)
>
> With all three of the domains associated with the aliases (i.e. 
> excluding protocol and port) also included in the 'domain' table in 
> the database.
>
> An "opensips-cli -x mi domain_reload" is an extremely quick and 
> non-disruptive way to add an additional domain to a live system, 
> however, adding an alias to opensips.cfg and restarting OpenSIPS is, 
> by contrast, a relatively slow and disruptive process (at least on 
> versions < 3.6 where, to the best of my understanding, an 
> "opensips-cli -x mi reload_routes" won't reload the aliases.)
>
> When I add a domain to the domains table, all appears to work 
> correctly, so I'm not seeing any specific reason why I need the 
> aliases, however, don't want to find out abruptly when something breaks.
>
> Are there specific circumstances in which, if one only adds the domain 
> to the domains table, and doesn't add an "alias=" to the core 
> configuration, it will break? Is it necessary to have an alias for 
> every domain, or only the primary hostname?
>
> Thanks
>
> Greg
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bogdan at opensips.org  Tue Jun  3 14:32:18 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 3 Jun 2025 17:32:18 +0300
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
In-Reply-To: <CALOQYiu=ibBN2JpyZap0YusguG1Xq+Aauh0woaGtevS_U1+4Fg@mail.gmail.com>
References: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>
 <DS7PR10MB52140D9783A974A0F09EACAB9561A@DS7PR10MB5214.namprd10.prod.outlook.com>
 <CALOQYisEZSk5+fBaZC39fO69Yrt1-fVXZ7jj=VC_CCZ2pgb6dw@mail.gmail.com>
 <BN0PR10MB5208F255BFB83215EF3312159560A@BN0PR10MB5208.namprd10.prod.outlook.com>
 <CALOQYiu=ibBN2JpyZap0YusguG1Xq+Aauh0woaGtevS_U1+4Fg@mail.gmail.com>
Message-ID: <674e9c9d-8b87-4e61-9b8a-bf83feae2a64@opensips.org>

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/20250603/68043901/attachment-0001.html>

From Ben.Newlin at genesys.com  Tue Jun  3 15:32:56 2025
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Tue, 3 Jun 2025 15:32:56 +0000
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
In-Reply-To: <674e9c9d-8b87-4e61-9b8a-bf83feae2a64@opensips.org>
References: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>
 <DS7PR10MB52140D9783A974A0F09EACAB9561A@DS7PR10MB5214.namprd10.prod.outlook.com>
 <CALOQYisEZSk5+fBaZC39fO69Yrt1-fVXZ7jj=VC_CCZ2pgb6dw@mail.gmail.com>
 <BN0PR10MB5208F255BFB83215EF3312159560A@BN0PR10MB5208.namprd10.prod.outlook.com>
 <CALOQYiu=ibBN2JpyZap0YusguG1Xq+Aauh0woaGtevS_U1+4Fg@mail.gmail.com>
 <674e9c9d-8b87-4e61-9b8a-bf83feae2a64@opensips.org>
Message-ID: <BN0PR10MB5208C2573B3EFE97A0ADD430956DA@BN0PR10MB5208.namprd10.prod.outlook.com>

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.opensips-solutions.com>

  https://www.siphub.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<mailto: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<mailto:users-bounces at lists.opensips.org>> on behalf of nz deals <nzdealshelp at gmail.com<mailto:nzdealshelp at gmail.com>>
Date: Friday, May 30, 2025 at 10:49 PM
To: OpenSIPS users mailling list <users at lists.opensips.org<mailto: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>
_______________________________________________
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>


_______________________________________________

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/20250603/2cddee9d/attachment-0001.html>

From nzdealshelp at gmail.com  Wed Jun  4 01:24:46 2025
From: nzdealshelp at gmail.com (nz deals)
Date: Wed, 4 Jun 2025 13:24:46 +1200
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
In-Reply-To: <BN0PR10MB5208C2573B3EFE97A0ADD430956DA@BN0PR10MB5208.namprd10.prod.outlook.com>
References: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>
 <DS7PR10MB52140D9783A974A0F09EACAB9561A@DS7PR10MB5214.namprd10.prod.outlook.com>
 <CALOQYisEZSk5+fBaZC39fO69Yrt1-fVXZ7jj=VC_CCZ2pgb6dw@mail.gmail.com>
 <BN0PR10MB5208F255BFB83215EF3312159560A@BN0PR10MB5208.namprd10.prod.outlook.com>
 <CALOQYiu=ibBN2JpyZap0YusguG1Xq+Aauh0woaGtevS_U1+4Fg@mail.gmail.com>
 <674e9c9d-8b87-4e61-9b8a-bf83feae2a64@opensips.org>
 <BN0PR10MB5208C2573B3EFE97A0ADD430956DA@BN0PR10MB5208.namprd10.prod.outlook.com>
Message-ID: <CALOQYiuUHVuPgV5Q=givxp2E4D5aBso3unwhvVui2rMOc8F4sA@mail.gmail.com>

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>

From manuel.tausendfreund at dtms.de  Thu Jun  5 09:31:25 2025
From: manuel.tausendfreund at dtms.de (Manuel Tausendfreund)
Date: Thu, 5 Jun 2025 09:31:25 +0000
Subject: [OpenSIPS-Users] RTP Port missmatch
Message-ID: <c42873e1287546e8977de76737237ba9@dtms.de>

Hi ,

i have Playback part on my SBC (3.4.11 Opensips from The Debian Repo) rtpengine is 13.4.0.0


	ua_session_server_init($var(key_ini), "t$var(time)arhb");
	rtpengine_offer("in-iface=$var(interface) out-iface=$var(interface) ",$var(rtp_con),$var(sdp_data));
	ua_session_reply($var(key_ini), "INVITE", 200, "OK", $var(sdp_data));
	rtpengine_play_media("file=/net/audio/sound.wav from-tag=$ft ",$var(time),$var(rtp_con)); 

it works BUT when the other RTP Engine has a Strict Source active it is not working anymore.

Opensips sends in the "200 OK" of the SDP part from the Port from The UA-Agent instead off the port from the Caller

But the Sound is send from port of the Caller

How can I Change this behavior ?

Here look in my Log´s

<logs from RTP Engine>

Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] Final packet stats:
Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] --- Tag 'xx.xx.xx.xx', created 0:46 ago for branch ''
Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec
Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] --------- Port   10.250.56.103:65436 <>   10.249.152.95:28892
Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] --------- Port   10.250.56.103:65437 <>   10.249.152.95:28893 
Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] --- Tag '', created 0:46 ago for branch ''
Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] ------ Media #1 (audio over RTP/AVP) using G722/8000
Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] --------- Port   10.250.56.103:36098 <>                :0    
Jun 03 14:06:06 rtp-test-bln rtpengine[786225]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx]: [core] --------- Port   10.250.56.103:36099 <>                :0    
Jun 03 14:06:16 rtp-test-bln rtpengine[786225]: INFO: [a000e80f7f061fdcf69525ef9e7fd77f at xx.xx.xx.xx]: [core] Final packet stats:
</logs from RTP Engine>

<SDP from the 200 OK>

v=0
o=- 23915705085026 23915705085026 IN IP4 10.249.152.95
s=-
t=0 0
m=audio 36098 RTP/AVP 9 8 0 101
c=IN IP4 10.250.56.103
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=msi:mavodi-8-159-31-d-ffffffff-25cb306d- at 87.137.153.236
a=sendrecv
a=rtcp:36099
a=ptime:20
a=maxptime:60
</SDP from the 200 OK>



<logs from RTP Engine Other side>

Jun 03 14:05:20 rtp-out-hh3 rtpengine[1159]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx/xx.xx.xx.xx port 37868]: [core] Kernelizing media stream: yy.yy.yy.yy:65198 -> zz.zz.zz.zz:37868 | 10.249.152.95:28892 -> 10.250.56.103:36098
Jun 03 14:05:20 rtp-out-hh3 rtpengine[1159]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx/xx.xx.xx.xx port 37868]: [core] Kernelizing media stream: yy.yy.yy.yy:65198 -> zz.zz.zz.zz:37868 | 10.249.152.95:28893 -> 10.250.56.103:36099
Jun 03 14:05:20 rtp-out-hh3 rtpengine[1159]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx port 28892]: [core] Drop due to strict-source attribute; got 10.250.56.103:65436, expected 10.250.56.103:36098
Jun 03 14:05:20 rtp-out-hh3 rtpengine[1159]: INFO: [c16a0ad430a825c669e432f19b83e956 at xx.xx.xx.xx port 28893]: [core] Drop due to strict-source attribute; got 10.250.56.103:65437, expected 10.250.56.103:36099
</logs from RTP Engine Other side>

BR
Manuel


From Johan at democon.be  Thu Jun  5 10:00:21 2025
From: Johan at democon.be (Johan De Clercq)
Date: Thu, 5 Jun 2025 12:00:21 +0200
Subject: [OpenSIPS-Users] sip question.
Message-ID: <CAEVWGm-Z4a6-zg5_-b=jWu_65BSgrPQyjL1idU_dZxBx+M06JQ@mail.gmail.com>

in a bye message, is the contact header mandatory or not ?

BR, JOhan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250605/65ee843f/attachment.html>

From walter.schober at neotel.at  Thu Jun  5 10:49:16 2025
From: walter.schober at neotel.at (Walter Schober)
Date: Thu, 5 Jun 2025 10:49:16 +0000
Subject: [OpenSIPS-Users] sip question.
In-Reply-To: <CAEVWGm-Z4a6-zg5_-b=jWu_65BSgrPQyjL1idU_dZxBx+M06JQ@mail.gmail.com>
References: <CAEVWGm-Z4a6-zg5_-b=jWu_65BSgrPQyjL1idU_dZxBx+M06JQ@mail.gmail.com>
Message-ID: <D67973F0-E743-4A9B-8D82-C8B7E979FED7@neotel.at>

IMHO: No, it is not.

> Am 05.06.2025 um 12:01 schrieb Johan De Clercq <Johan at democon.be>:
> 
> 
> in a bye message, is the contact header mandatory or not ? 
> 

From bogdan at opensips.org  Thu Jun  5 11:54:32 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 5 Jun 2025 14:54:32 +0300
Subject: [OpenSIPS-Users] sip question.
In-Reply-To: <D67973F0-E743-4A9B-8D82-C8B7E979FED7@neotel.at>
References: <CAEVWGm-Z4a6-zg5_-b=jWu_65BSgrPQyjL1idU_dZxBx+M06JQ@mail.gmail.com>
 <D67973F0-E743-4A9B-8D82-C8B7E979FED7@neotel.at>
Message-ID: <5d40bba7-28e6-4611-86f0-05af554a1915@opensips.org>

:+1:

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 05.06.2025 13:49, Walter Schober wrote:
> IMHO: No, it is not.
>
>> Am 05.06.2025 um 12:01 schrieb Johan De Clercq <Johan at democon.be>:
>>
>> 
>> in a bye message, is the contact header mandatory or not ?
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From ag at ag-projects.com  Thu Jun  5 11:53:39 2025
From: ag at ag-projects.com (Adrian Georgescu)
Date: Thu, 5 Jun 2025 13:53:39 +0200
Subject: [OpenSIPS-Users] sip question.
In-Reply-To: <CAEVWGm-Z4a6-zg5_-b=jWu_65BSgrPQyjL1idU_dZxBx+M06JQ@mail.gmail.com>
References: <CAEVWGm-Z4a6-zg5_-b=jWu_65BSgrPQyjL1idU_dZxBx+M06JQ@mail.gmail.com>
Message-ID: <5BE5CD35-36B2-44C0-932E-C02C4F0185F2@ag-projects.com>

Yes.Without the correct URI learnt from the contact header of the INVITE or 200 OK respectively, it is not possible to match the call on the receiving device of the call. If there is a phone that supports one call at the time, perhaps it will handle it, but if the BYE is for an intermediate gateway, it needs a proper request URI to target the end device.

> On Jun 5, 2025, at 12:00, Johan De Clercq <Johan at democon.be> wrote:
> 
> in a bye message, is the contact header mandatory or not ? 
> 
> BR, JOhan. 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From walter.schober at neotel.at  Thu Jun  5 12:22:09 2025
From: walter.schober at neotel.at (Walter Schober)
Date: Thu, 5 Jun 2025 12:22:09 +0000
Subject: [OpenSIPS-Users] SIPREC start on 18x/SDP too early
Message-ID: <DB58740E-26B6-4A59-A4DA-CCBD8684059F@neotel.eu>

Hi!

Acc to the docs https://opensips.org/docs/modules/3.5.x/siprec.html#func_siprec_start_recording the INVITE to the SRS should start on connect 200 OK. 
But it starts as soon as a SDP body is replied in the recorded call. E.g. in the 183/SDP or 180/SDP.

Is this intensionally and the documentation is wrong?
Can this be tweaked somehow to start on 200 OK?

Unfortunately our SRS cannot handle the call that early since it hasn’t got all information to record the call at that moment.
Gladly the SIPREC Modul does another INVITE on 200 OK if the first one got rejected - but I’m afraid that leads to some race conditions in some scenarios.

I’m using 3.5.5. Script is straight forward:

                create_dialog();
                $siprec(group) = "webrtc-loop-out";
                $rtp_relay_ctx(callid) = "srs-o-"+$ci;
                route(do_rec);

route[do_rec] {
        # https://www.opensips.org/Documentation/Tutorials-SIPREC-2-4

# is not sent to „subscribe answer" anyway
#       $rtp_relay(flags) = "callid="+$ci+" allow-transcoding asymmetric";
#       $rtp_relay_peer(flags) = "callid="+$ci+" allow-transcoding asymmetric";

# is not sent to „subscribe answer" anyway
#       $rtp_relay_ctx(flags) = "allow-transcoding asymmetric";
#       $rtp_relay_ctx(flags) = "template=siprec"; # flags "siprec" only in subscribe request, not in subscribe answer
        rtp_relay_engage("rtpengine");

        # https://opensips.org/docs/modules/3.6.x/siprec.html#func_siprec_start_recording
        $siprec(headers) = "X-Call-ID: "+$ci+"\r\n";

        $xml(caller_xml) = "<nameID></nameID>";
        $xml(caller_xml/nameID.attr/aor) = $fU+"@"+$fd"; # Communi5 does not want any sip:, nor ports
        if ($(fn{s.len})) $xml(caller_xml/nameID) = "<name>"+$fn+"</name>";
        $siprec(caller) = $xml(caller_xml/nameID);

        $xml(callee_xml) = "<nameID></nameID>";
        $xml(callee_xml/nameID.attr/aor) = $tU+"@"+$td"; # Communi5 does not want any sip:, nor ports
        #$xml(callee_xml/nameID) = "<name></name>";
        $siprec(callee) = $xml(callee_xml/nameID);

        $siprec(from_uri) = $fu;
        $siprec(to_uri) = $tu;

        siprec_start_recording("sip:opensips-srs at 192.168.48.161:5060;x-system=$(ru{uri.param,x-system}), sip:opensips-srs at 192.168.48.162:5060;x-system=$(ru{uri.param,x-system})");
}


br
Walter

P.S:: tried 3.6.0-beta, too. But 3.6.0 crashes on BYE and other situations, yet.
P.P.S.: 3.6.0 got events. Can I do something in those event_routes? This is not clearly documented.

From david.villasmil.work at gmail.com  Thu Jun  5 18:36:14 2025
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 5 Jun 2025 20:36:14 +0200
Subject: [OpenSIPS-Users] sip question.
In-Reply-To: <5BE5CD35-36B2-44C0-932E-C02C4F0185F2@ag-projects.com>
References: <CAEVWGm-Z4a6-zg5_-b=jWu_65BSgrPQyjL1idU_dZxBx+M06JQ@mail.gmail.com>
 <5BE5CD35-36B2-44C0-932E-C02C4F0185F2@ag-projects.com>
Message-ID: <CAFGRPVrrm+M7afX_iDYstT7KFiKUQVa5JMkuVFCxT5=oay7Gdg@mail.gmail.com>

+1

The BYE request is constructed as would any other request within a dialog,
as described in Section 8.1.1.
[…]
The Request-URI, To, From, Call-ID, CSeq, Max-Forwards, and Via header
fields MUST be included in a BYE request.
A Contact header field MAY be included in a BYE request.


Regards,

David Villasmil
email: david.villasmil.work at gmail.com



On Thu, Jun 5, 2025 at 1:57 PM Adrian Georgescu <ag at ag-projects.com> wrote:

> Yes.Without the correct URI learnt from the contact header of the INVITE
> or 200 OK respectively, it is not possible to match the call on the
> receiving device of the call. If there is a phone that supports one call at
> the time, perhaps it will handle it, but if the BYE is for an intermediate
> gateway, it needs a proper request URI to target the end device.
>
> > On Jun 5, 2025, at 12:00, Johan De Clercq <Johan at democon.be> wrote:
> >
> > in a bye message, is the contact header mandatory or not ?
> >
> > BR, JOhan.
> > _______________________________________________
> > 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/20250605/d0e255b4/attachment.html>

From Ben.Laing at dals.co.uk  Fri Jun  6 13:25:11 2025
From: Ben.Laing at dals.co.uk (Ben Laing)
Date: Fri, 6 Jun 2025 13:25:11 +0000
Subject: [OpenSIPS-Users] Setting up dialog replication
Message-ID: <CWXP123MB6191421263B3DF439E2F8850D86EA@CWXP123MB6191.GBRP123.PROD.OUTLOOK.COM>

Hello!

I am trying to set up an active/active OpenSIPS pair in AWS.

The AWS set up is two OpenSIPs (V3.4.12) running on EC2 instances in two different availability zones. There is then a network load balancer (NLB) in each availability zone that distributes traffic to the two OpenSIPs nodes.

I am trying to set up dialog sharing between the two nodes. The cluster appears to be healthy:

  *   both nodes are in cluster 1 with flag set to `seed`.
  *   opensips-cli -x mi clusterer_list_cap  shows dialog-dlg-repl / state Ok / enabled Yes
  *   opensips-cli -x mi clusterer_list – shows other node with link_state up, state enabled.



My test to make a call through node 1, kill node 1, end the call with the BYE then going through node 2. When I try this, node 2 isn’t finding the dialog. If I run dlg_list during the call (before killing node 1) the dlg is present on node 1 but not node 2. So it looks like the dialog replication isn’t working.



The dialog clustering manual suggests reading https://blog.opensips.org/2018/03/23/clustering-ongoing-calls-with-opensips-2-4/ which references dlg_sharing_tag which has since been deprecated. I don’t think I need tags, though potentially that’s where I’m going wrong. I’ve been down a few rabbit holes looking at out of date manuals for some of the modules!



The relevant config for node 1 is as follows:



loadmodule "proto_udp.so"

socket = udp:10.4.60.11

# NLB 1

socket = udp:10.4.60.11 as 10.4.38.178

# NLB 2

socket = udp:10.4.60.11 as 10.4.63.19

#  Tried setting tag public here but didn’t help


#### DIALOG module
loadmodule "dialog.so"
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 600)  # 6 hours timeout
modparam("dialog", "db_mode", 2)
modparam("dialog", "db_url", "mysql://opensips:opensipsrw at 10.4.40.21/opensips")
modparam("dialog", "dialog_replication_cluster", 1)


### CLUSTERING
socket = bin:10.4.60.12:5566 # bin listener for OpenSIPS clustering
loadmodule "proto_bin.so"

loadmodule "clusterer.so"
modparam("clusterer", "db_mode", 1)
modparam("clusterer", "db_url", "mysql://opensips:opensipsrw at 10.4.40.21/opensips")
modparam("clusterer", "my_node_id", 2) # node_id for OpenSIPS 1



route  {

…
        # handle the initial INVITE to create a dialog
        if (is_method("INVITE")) {

                …

                if ( !create_dialog("B") ) {
                        send_reply(500,"Internal Server Error");
                        exit;
                }

}



Any suggestions on how to debug or glaring omissions would be very helpful.



Best,



Ben Laing


Classified - General

‑‑‑‑‑
Ben Laing
He/Him
Senior Software Developer
Email: Ben.Laing at dals.co.uk
Website: www.dals.co.uk<http://www.dals.co.uk/>
Dals, Statham House, Talbot Rd, Stretford, Manchester, M32 0FP



Classified - General
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250606/f11c1133/attachment-0001.html>

From Ben.Newlin at genesys.com  Fri Jun  6 14:37:26 2025
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Fri, 6 Jun 2025 14:37:26 +0000
Subject: [OpenSIPS-Users] Setting up dialog replication
In-Reply-To: <CWXP123MB6191421263B3DF439E2F8850D86EA@CWXP123MB6191.GBRP123.PROD.OUTLOOK.COM>
References: <CWXP123MB6191421263B3DF439E2F8850D86EA@CWXP123MB6191.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <BN0PR10MB520815471554A4BF67AAB957956EA@BN0PR10MB5208.namprd10.prod.outlook.com>

Have you checked the logs on node 2 from the time the call was placed? When we tried this we found that node 2 was refusing the dialog because the IP address of the socket for the dialog was not configured locally. There was a log printed indicating this. It seems the dialog replication assumes a VIP/anycast setup where in order to “take over” the dialog the node has to also have a socket with the same IP.

It was a while ago we tried this though so maybe that has changed.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Ben Laing via Users <users at lists.opensips.org>
Date: Friday, June 6, 2025 at 9:26 AM
To: users at lists.opensips.org <users at lists.opensips.org>
Subject: [OpenSIPS-Users] Setting up dialog replication
 EXTERNAL EMAIL - Please use caution with links and attachments

________________________________
Hello!

I am trying to set up an active/active OpenSIPS pair in AWS.

The AWS set up is two OpenSIPs (V3.4.12) running on EC2 instances in two different availability zones. There is then a network load balancer (NLB) in each availability zone that distributes traffic to the two OpenSIPs nodes.

I am trying to set up dialog sharing between the two nodes. The cluster appears to be healthy:

·         both nodes are in cluster 1 with flag set to `seed`.

  *   opensips-cli -x mi clusterer_list_cap  shows dialog-dlg-repl / state Ok / enabled Yes
  *   opensips-cli -x mi clusterer_list – shows other node with link_state up, state enabled.



My test to make a call through node 1, kill node 1, end the call with the BYE then going through node 2. When I try this, node 2 isn’t finding the dialog. If I run dlg_list during the call (before killing node 1) the dlg is present on node 1 but not node 2. So it looks like the dialog replication isn’t working.



The dialog clustering manual suggests reading https://blog.opensips.org/2018/03/23/clustering-ongoing-calls-with-opensips-2-4/<https://blog.opensips.org/2018/03/23/clustering-ongoing-calls-with-opensips-2-4/> which references dlg_sharing_tag which has since been deprecated. I don’t think I need tags, though potentially that’s where I’m going wrong. I’ve been down a few rabbit holes looking at out of date manuals for some of the modules!



The relevant config for node 1 is as follows:



loadmodule "proto_udp.so"

socket = udp:10.4.60.11

# NLB 1

socket = udp:10.4.60.11 as 10.4.38.178

# NLB 2

socket = udp:10.4.60.11 as 10.4.63.19

#  Tried setting tag public here but didn’t help


#### DIALOG module
loadmodule "dialog.so"
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 600)  # 6 hours timeout
modparam("dialog", "db_mode", 2)
modparam("dialog", "db_url", "mysql://opensips:opensipsrw at 10.4.40.21/opensips")
modparam("dialog", "dialog_replication_cluster", 1)


### CLUSTERING
socket = bin:10.4.60.12:5566 # bin listener for OpenSIPS clustering
loadmodule "proto_bin.so"

loadmodule "clusterer.so"
modparam("clusterer", "db_mode", 1)
modparam("clusterer", "db_url", "mysql://opensips:opensipsrw at 10.4.40.21/opensips")
modparam("clusterer", "my_node_id", 2) # node_id for OpenSIPS 1



route  {

…
        # handle the initial INVITE to create a dialog
        if (is_method("INVITE")) {

                …

                if ( !create_dialog("B") ) {
                        send_reply(500,"Internal Server Error");
                        exit;
                }

}



Any suggestions on how to debug or glaring omissions would be very helpful.



Best,



Ben Laing


Classified - General
‑‑‑‑‑
Ben Laing

He/Him
Senior Software Developer
Email: Ben.Laing at dals.co.uk
Website: www.dals.co.uk<http://www.dals.co.uk/>
Dals, Statham House, Talbot Rd, Stretford, Manchester, M32 0FP



Classified - General
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250606/46f69bfb/attachment-0001.html>

From tek1 at ottertelecom.io  Tue Jun 10 06:33:27 2025
From: tek1 at ottertelecom.io (GUILLAUME POUILLY)
Date: Tue, 10 Jun 2025 08:33:27 +0200
Subject: [OpenSIPS-Users] B2BUA
Message-ID: <624FC8C6-98D9-4EC4-8FF9-FF3CB5B4A59E@ottertelecom.io>

Hi all,

I’m working on a call flow using OpenSIPS with the B2B modules, aiming to analyze call progression on Leg B before allowing it to complete on Leg A.

Here’s the scenario:
OpenSIPS receives a call (Leg A)
OpenSIPS initiates a new call to the destination (Leg B)
While monitoring SIP replies from Leg B (e.g., 183, 180, 200), OpenSIPS may decide to terminate the call at any point and return a custom SIP response (e.g., 987 Voicemail Detected) to Leg A instead of forwarding the final reply.
The problem is:

I can’t prevent the 200 OK from Leg B from being relayed to Leg A.

I’ve tried using b2b_logic, but I can’t seem to intercept and block the final reply in time.

Has anyone successfully implemented a similar flow or knows how to stop the forwarding of 200 OK to Leg A within the B2BUA context?

Thanks in advance for any guidance.

 

OtterTek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250610/43a090e3/attachment.html>

From razvan at opensips.org  Tue Jun 10 07:52:40 2025
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Tue, 10 Jun 2025 10:52:40 +0300
Subject: [OpenSIPS-Users] SIPREC start on 18x/SDP too early
In-Reply-To: <DB58740E-26B6-4A59-A4DA-CCBD8684059F@neotel.eu>
References: <DB58740E-26B6-4A59-A4DA-CCBD8684059F@neotel.eu>
Message-ID: <59984b03-d61e-40dc-9e19-fb34767294bb@opensips.org>

Hi, Walter!

The answer is actually a mixed of both - initially, the module started 
recording only on 200 OK - later on, there was a request to allow it on 
183 as well, because it contains media too - this change has been made, 
but apparently docs were not updated (most likely my bad here, apologies).
I've updated the documentation[1] with the correct statement, thanks for 
pointing it out.
In order to start the recording only on 200 OK, you should only call 
siprec_start_recording() in the onreply route processing the 200 OK.

Best regards,

Răzvan Crainea
OpenSIPS Core Developer / SIPhub CTO
http://www.opensips-solutions.com / https://www.siphub.com

On 6/5/25 3:22 PM, Walter Schober wrote:
> Hi!
> 
> Acc to the docs https://opensips.org/docs/modules/3.5.x/siprec.html#func_siprec_start_recording the INVITE to the SRS should start on connect 200 OK.
> But it starts as soon as a SDP body is replied in the recorded call. E.g. in the 183/SDP or 180/SDP.
> 
> Is this intensionally and the documentation is wrong?
> Can this be tweaked somehow to start on 200 OK?
> 
> Unfortunately our SRS cannot handle the call that early since it hasn’t got all information to record the call at that moment.
> Gladly the SIPREC Modul does another INVITE on 200 OK if the first one got rejected - but I’m afraid that leads to some race conditions in some scenarios.
> 
> I’m using 3.5.5. Script is straight forward:
> 
>                  create_dialog();
>                  $siprec(group) = "webrtc-loop-out";
>                  $rtp_relay_ctx(callid) = "srs-o-"+$ci;
>                  route(do_rec);
> 
> route[do_rec] {
>          # https://www.opensips.org/Documentation/Tutorials-SIPREC-2-4
> 
> # is not sent to „subscribe answer" anyway
> #       $rtp_relay(flags) = "callid="+$ci+" allow-transcoding asymmetric";
> #       $rtp_relay_peer(flags) = "callid="+$ci+" allow-transcoding asymmetric";
> 
> # is not sent to „subscribe answer" anyway
> #       $rtp_relay_ctx(flags) = "allow-transcoding asymmetric";
> #       $rtp_relay_ctx(flags) = "template=siprec"; # flags "siprec" only in subscribe request, not in subscribe answer
>          rtp_relay_engage("rtpengine");
> 
>          # https://opensips.org/docs/modules/3.6.x/siprec.html#func_siprec_start_recording
>          $siprec(headers) = "X-Call-ID: "+$ci+"\r\n";
> 
>          $xml(caller_xml) = "<nameID></nameID>";
>          $xml(caller_xml/nameID.attr/aor) = $fU+"@"+$fd"; # Communi5 does not want any sip:, nor ports
>          if ($(fn{s.len})) $xml(caller_xml/nameID) = "<name>"+$fn+"</name>";
>          $siprec(caller) = $xml(caller_xml/nameID);
> 
>          $xml(callee_xml) = "<nameID></nameID>";
>          $xml(callee_xml/nameID.attr/aor) = $tU+"@"+$td"; # Communi5 does not want any sip:, nor ports
>          #$xml(callee_xml/nameID) = "<name></name>";
>          $siprec(callee) = $xml(callee_xml/nameID);
> 
>          $siprec(from_uri) = $fu;
>          $siprec(to_uri) = $tu;
> 
>          siprec_start_recording("sip:opensips-srs at 192.168.48.161:5060;x-system=$(ru{uri.param,x-system}), sip:opensips-srs at 192.168.48.162:5060;x-system=$(ru{uri.param,x-system})");
> }
> 
> 
> br
> Walter
> 
> P.S:: tried 3.6.0-beta, too. But 3.6.0 crashes on BYE and other situations, yet.
> P.P.S.: 3.6.0 got events. Can I do something in those event_routes? This is not clearly documented.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From razvan at opensips.org  Tue Jun 10 07:57:59 2025
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Tue, 10 Jun 2025 10:57:59 +0300
Subject: [OpenSIPS-Users] Siprec subscribe-answer rtpengine flags
In-Reply-To: <1AFD1281-CAED-4D0E-A0AA-51D5125054F2@neotel.eu>
References: <1AFD1281-CAED-4D0E-A0AA-51D5125054F2@neotel.eu>
Message-ID: <e8e1a281-ceb7-4d16-90b1-f21b2dce5c3b@opensips.org>

Hi, Walter!

You can pass the allow-transcoding flags in the $siprec(media) variable, 
before engaging recording:

$siprec(media) = "allow-transcoding";

Best regards,

Răzvan Crainea
OpenSIPS Core Developer / SIPhub CTO
http://www.opensips-solutions.com / https://www.siphub.com

On 6/3/25 11:50 AM, Walter Schober wrote:
> Hi!
> 
> I’ve successfully managed to record a call via SIPREC module using OpenSIPS 3.6.0 and RTPEngine 13.2.
> 
> But I needed to do a trick to have the subscribe-answer to allow transcoding: I used a template „default“ in the rtpengine.conf to set
> 
> [templates]
> default = allow-transcoding asymmetric
> 
> This is global unfortunately. I searched all the module documentations siprec, dialog, rtp_relay (I understood: rtpengine cannot be done directly in 3.6 with siprec). I looked even into source code.
> I haven’t found any hint how to add RTPEngine flag „allow-transcoding“ to the „subscribe answer“ command in opensips.
> 
> Did I miss something or is this not possible?
> 
> Thanks for help me understanding this!
> br
> Walter
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From liviu at opensips.org  Tue Jun 10 10:32:42 2025
From: liviu at opensips.org (Liviu Chircu)
Date: Tue, 10 Jun 2025 13:32:42 +0300
Subject: [OpenSIPS-Users] [Release Freeze] Upcoming OpenSIPS 3.5.6 and
	3.4.13 Minor Releases
Message-ID: <effdb0b8-f99a-4b87-84a0-c284319a9ab6@opensips.org>

Hi all,

The *3.5.6* and *3.4.13* OpenSIPS minor versions are scheduled for 
release next week, on Wednesday, *June 18th*.

In preparation for the releases, we impose the usual freeze on any 
significant fixes (as complexity) on the stable branches, in order to 
ensure a safe window for testing in the days ahead.

If there are any outstanding issues which have skipped our attention on 
the GitHub issue tracker that we could address in due time, please do 
point them out.  Thank you!

Happy testing,

-- 
Liviu Chircu
Sr. Software Developer
www.siphub.com  |www.opensips-solutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250610/a3600c87/attachment.html>

From bogdan at opensips.org  Tue Jun 10 11:45:13 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Tue, 10 Jun 2025 14:45:13 +0300
Subject: [OpenSIPS-Users] OpenSIPS Summit 2025 - post facts
Message-ID: <1d981984-ee9e-40f3-a873-2f090ae71d3c@opensips.org>

Hello all !!

I would like to thank you all for being part of the OpenSIPS Summit 2025 
in Amsterdam. It was an amazing set of speakers, sponsors and 
participants - I hope you all enjoyed the event, and even more, I hope 
you found it useful in terms of getting the updates and news from the 
VoIP and RTC words.

Now that the event is behind us, let me fill in here some post facts

  * the presentations and recordings were uploaded at attached to the
    schedule / linked to the web site
    <https://www.opensips.org/events/Summit-2025Amsterdam/#schedules>
  * the recordings are also available on the OpenSIPS YouTube channel
    <https://youtube.com/playlist?list=PLMMZA6ketvKpAodUmfhwUsHfderyswZjo>
  * photos from the event were uploaded on the OpenSIPS Summit 2025
    Album <https://photos.app.goo.gl/GsEBS6gr1AHCMABc9>


Enjoy !

Best regards,

-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250610/744d7fde/attachment-0001.html>

From walter.schober at neotel.at  Wed Jun 11 08:06:10 2025
From: walter.schober at neotel.at (Walter Schober)
Date: Wed, 11 Jun 2025 08:06:10 +0000
Subject: [OpenSIPS-Users] Siprec subscribe-answer rtpengine flags
In-Reply-To: <e8e1a281-ceb7-4d16-90b1-f21b2dce5c3b@opensips.org>
References: <1AFD1281-CAED-4D0E-A0AA-51D5125054F2@neotel.eu>
 <e8e1a281-ceb7-4d16-90b1-f21b2dce5c3b@opensips.org>
Message-ID: <AS2PR02MB99308674EF075882A6818F028D75A@AS2PR02MB9930.eurprd02.prod.outlook.com>

Hi Razvan!


Thanks for this information! Yes, it did the job indeed!

I would suggest to adopt the Doc https://opensips.org/docs/modules/3.6.x/siprec.html#pv_siprec accordingly:

"
media - the IP that RTPProxy will be streaming media from. If absent 127.0.0.1 will be used. NOTE:media_ip has been dropped.
"

to 

"media - RTPProxy: the IP that RTPProxy will be streaming media from. If absent 127.0.0.1 will be used.    <<<--- I don’t know RTPProxy behaviour here
         RTPEngine: flags to RTPEngine used for SRS Media Session. If absent the configured interface IP is used with no separate flags.
                    E.g. "allow-transcoding" for use of RTPEngine if SRS is not answering with exactly same codec list as offered.
         NOTE:media_ip has been dropped.
"


Br
Walter

-----Ursprüngliche Nachricht-----
Von: Users <users-bounces at lists.opensips.org> Im Auftrag von Răzvan Crainea
Gesendet: Dienstag, 10. Juni 2025 09:58
An: users at lists.opensips.org
Betreff: Re: [OpenSIPS-Users] Siprec subscribe-answer rtpengine flags

Hi, Walter!

You can pass the allow-transcoding flags in the $siprec(media) variable, 
before engaging recording:

$siprec(media) = "allow-transcoding";

Best regards,

Răzvan Crainea
OpenSIPS Core Developer / SIPhub CTO
http://www.opensips-solutions.com / https://www.siphub.com

On 6/3/25 11:50 AM, Walter Schober wrote:
> Hi!
> 
> I’ve successfully managed to record a call via SIPREC module using OpenSIPS 3.6.0 and RTPEngine 13.2.
> 
> But I needed to do a trick to have the subscribe-answer to allow transcoding: I used a template „default“ in the rtpengine.conf to set
> 
> [templates]
> default = allow-transcoding asymmetric
> 
> This is global unfortunately. I searched all the module documentations siprec, dialog, rtp_relay (I understood: rtpengine cannot be done directly in 3.6 with siprec). I looked even into source code.
> I haven’t found any hint how to add RTPEngine flag „allow-transcoding“ to the „subscribe answer“ command in opensips.
> 
> Did I miss something or is this not possible?
> 
> Thanks for help me understanding this!
> br
> Walter
> 
> _______________________________________________
> 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

From bogdan at opensips.org  Wed Jun 11 09:42:59 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 11 Jun 2025 12:42:59 +0300
Subject: [OpenSIPS-Users] TCP Performance profiling
In-Reply-To: <CAEWH9M-pFLTZL=Ah9Rqw7pgu-pHXpQbgOz7NQC57RoN0hrXGGQ@mail.gmail.com>
References: <CAEWH9M_Fz6jNN0HstsGSt1F_eTr4owGsmjA99x_OKc7LsoT4iw@mail.gmail.com>
 <dd6af39c-1c22-4602-8756-e2c50a91a54f@opensips.org>
 <CAEWH9M-pFLTZL=Ah9Rqw7pgu-pHXpQbgOz7NQC57RoN0hrXGGQ@mail.gmail.com>
Message-ID: <ea23bb3c-28d3-429e-91ec-2bc85eb89751@opensips.org>

HI Pete,

Sorry for the late reply on this - if this is still a hot topic, as a 
POC, try getting the rtpengine out of the picture and see how the 
numbers look for replies.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 15.04.2025 12:17, Pete Kelly wrote:
> I’ll give script trace a try…
>
> loadmodule "proto_tcp.so"
> modparam("proto_tcp", "tcp_parallel_handling", 1)
> modparam("proto_tcp", "tcp_async", 1)
>
> And
>
> tcp_connect_timeout=100
> tcp_connection_lifetime = 3600
> tcp_max_connections=512
> tcp_max_msg_time=2
> tcp_parallel_read_on_workers=yes
> tcp_socket_backlog=10
> tcp_keepcount=9
> tcp_keepidle=120
> tcp_keepinterval=60
>
> Although I think it must come from the TCP level as I have been doing 
> some profiling, and I see things like 180 and 200 taking 10+ seconds, 
> when there is nothing specified in the reply routes.
>
> It’s calling rtpengine_offer on the INVITE so I wonder if that is 
> causing backlogs - although the profiling never seems to raise any 
> issues on INVITE/BYE - it’s only on the replies. Maybe related to 
> transaction matching or something?
>
> Pete
>
> On 14 Apr 2025 at 10:03:38, Bogdan-Andrei Iancu <bogdan at opensips.org> 
> wrote:
>> Hi Pete,
>>
>> Try the script_trace() function, to see if the delay comes from the 
>> script level. If not, it means it comes from the TCP layer (maybe 
>> related to the dispatching of TCP cons between workers)
>> https://www.opensips.org/Documentation/Script-CoreFunctions-3-5#script_trace
>>
>> BTW, what are the TCP settings for:
>> https://www.opensips.org/Documentation/Script-CoreParameters-3-5#tcp_parallel_read_on_workers
>> https://opensips.org/html/docs/modules/3.5.x/proto_tcp.html#idp5528016
>>
>> Regards,
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>    https://www.opensips-solutions.com
>>    https://www.siphub.com
>> On 10.04.2025 23:42, Pete Kelly wrote:
>>> Hello all
>>>
>>> I am running some OpenSIPS proxies which are talking to each other 
>>> exclusively in TCP, however when performing some (mild) load tests I 
>>> am seeing some strange behaviour from time to time, which manifests 
>>> itself as what looks like OpenSIPS taking a long time to process SIP 
>>> requests.
>>>
>>> The most obvious issue I am seeing (and confirmed by tcpdump) is 
>>> when OpenSIPS receives an invite but may take anything from 2-8 
>>> second to even send the 100 Trying!
>>>
>>> e.g.
>>>
>>> T 2025/04/10 20:28:10.257283 10.3.0.4:48665 <http://10.3.0.4:48665> 
>>> -> 10.3.0.12:5080 <http://10.3.0.12:5080> [A] #4826
>>>
>>> INVITE sip:... SIP/2.0.
>>>
>>> T 2025/04/10 20:28:12.644355 10.3.0.12:5080 <http://10.3.0.12:5080> 
>>> -> 10.3.0.4:48665 <http://10.3.0.4:48665> [AP] #4955
>>>
>>> SIP/2.0 100 Giving it a try.
>>>
>>>
>>> Is there an obvious route for me to debug this behaviour to try and 
>>> see where the bottleneck may lie ? Can I see somewhere if all of the 
>>> tcp workers are in use for example and it is waiting for a worker?
>>>
>>> Pete
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20250611/8d85ffd8/attachment.html>

From razvan at opensips.org  Wed Jun 11 12:05:16 2025
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Wed, 11 Jun 2025 15:05:16 +0300
Subject: [OpenSIPS-Users] Siprec subscribe-answer rtpengine flags
In-Reply-To: <AS2PR02MB99308674EF075882A6818F028D75A@AS2PR02MB9930.eurprd02.prod.outlook.com>
References: <1AFD1281-CAED-4D0E-A0AA-51D5125054F2@neotel.eu>
 <e8e1a281-ceb7-4d16-90b1-f21b2dce5c3b@opensips.org>
 <AS2PR02MB99308674EF075882A6818F028D75A@AS2PR02MB9930.eurprd02.prod.outlook.com>
Message-ID: <d73ec17f-b418-4f7d-8108-b10d98208d7a@opensips.org>

Hey, Walter!

Thanks for your suggestion! A PR for this would be more than welcome :).

Best regards,

Răzvan Crainea
OpenSIPS Core Developer / SIPhub CTO
http://www.opensips-solutions.com / https://www.siphub.com

On 6/11/25 11:06 AM, Walter Schober wrote:
> Hi Razvan!
> 
> 
> Thanks for this information! Yes, it did the job indeed!
> 
> I would suggest to adopt the Doc https://opensips.org/docs/modules/3.6.x/siprec.html#pv_siprec accordingly:
> 
> "
> media - the IP that RTPProxy will be streaming media from. If absent 127.0.0.1 will be used. NOTE:media_ip has been dropped.
> "
> 
> to
> 
> "media - RTPProxy: the IP that RTPProxy will be streaming media from. If absent 127.0.0.1 will be used.    <<<--- I don’t know RTPProxy behaviour here
>           RTPEngine: flags to RTPEngine used for SRS Media Session. If absent the configured interface IP is used with no separate flags.
>                      E.g. "allow-transcoding" for use of RTPEngine if SRS is not answering with exactly same codec list as offered.
>           NOTE:media_ip has been dropped.
> "
> 
> 
> Br
> Walter
> 
> -----Ursprüngliche Nachricht-----
> Von: Users <users-bounces at lists.opensips.org> Im Auftrag von Răzvan Crainea
> Gesendet: Dienstag, 10. Juni 2025 09:58
> An: users at lists.opensips.org
> Betreff: Re: [OpenSIPS-Users] Siprec subscribe-answer rtpengine flags
> 
> Hi, Walter!
> 
> You can pass the allow-transcoding flags in the $siprec(media) variable,
> before engaging recording:
> 
> $siprec(media) = "allow-transcoding";
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer / SIPhub CTO
> http://www.opensips-solutions.com / https://www.siphub.com
> 
> On 6/3/25 11:50 AM, Walter Schober wrote:
>> Hi!
>>
>> I’ve successfully managed to record a call via SIPREC module using OpenSIPS 3.6.0 and RTPEngine 13.2.
>>
>> But I needed to do a trick to have the subscribe-answer to allow transcoding: I used a template „default“ in the rtpengine.conf to set
>>
>> [templates]
>> default = allow-transcoding asymmetric
>>
>> This is global unfortunately. I searched all the module documentations siprec, dialog, rtp_relay (I understood: rtpengine cannot be done directly in 3.6 with siprec). I looked even into source code.
>> I haven’t found any hint how to add RTPEngine flag „allow-transcoding“ to the „subscribe answer“ command in opensips.
>>
>> Did I miss something or is this not possible?
>>
>> Thanks for help me understanding this!
>> br
>> Walter
>>
>> _______________________________________________
>> 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



From inder.itpro at gmail.com  Wed Jun 11 13:12:40 2025
From: inder.itpro at gmail.com (inderjeet sharma)
Date: Wed, 11 Jun 2025 18:42:40 +0530
Subject: [OpenSIPS-Users] Subscribe events to http or https
Message-ID: <CAOAEC9FbgYni8r4j0+mbHSyK5-ZtDJZigs0DCcdv7+UGgTDcKg@mail.gmail.com>

Hi,

I want to send Opensips events directly to an https webhook url.
subscribe_event(“E_UL_CONTACT_INSERT”, “https://xyz.com:8089/webook”);
Is this supported? If not, what is the recommended way to send events to
http/https?

Version: opensips 3.4.10

Thanks
Inderjeet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250611/57f4e368/attachment.html>

From razvan at opensips.org  Thu Jun 12 09:35:38 2025
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Thu, 12 Jun 2025 12:35:38 +0300
Subject: [OpenSIPS-Users] Subscribe events to http or https
In-Reply-To: <CAOAEC9FbgYni8r4j0+mbHSyK5-ZtDJZigs0DCcdv7+UGgTDcKg@mail.gmail.com>
References: <CAOAEC9FbgYni8r4j0+mbHSyK5-ZtDJZigs0DCcdv7+UGgTDcKg@mail.gmail.com>
Message-ID: <6eec98ab-c166-4e36-890a-3a5146009e2d@opensips.org>

Hi, Inderjeet!

Unfortunately this is not natively supported - what you can do is catch 
this event in an event_route[E_UL_CONTACT_INSERT] and do a 
rest_post/rest_get request [1] from there.

[1] https://opensips.org/docs/modules/3.4.x/rest_client.html#func_rest_get

Best regards,

Răzvan Crainea
OpenSIPS Core Developer / SIPhub CTO
http://www.opensips-solutions.com / https://www.siphub.com

On 6/11/25 4:12 PM, inderjeet sharma wrote:
> Hi,
> 
> I want to send Opensips events directly to an https webhook url.
> subscribe_event(“E_UL_CONTACT_INSERT”, “https://xyz.com:8089/webook”);
> Is this supported? If not, what is the recommended way to send events to
> http/https?
> 
> Version: opensips 3.4.10
> 
> Thanks
> Inderjeet
> 
> 
> Hi,
> 
> I want to send Opensips events directly to an https webhook url.
> subscribe_event(“E_UL_CONTACT_INSERT”, “https://xyz.com:8089/webook 
> <https://xyz.com:8089/webook>”);
> Is this supported? If not, what is the recommended way to send events to 
> http/https?
> 
> Version: opensips 3.4.10
> 
> Thanks
> Inderjeet
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From inder.itpro at gmail.com  Fri Jun 13 05:57:51 2025
From: inder.itpro at gmail.com (inderjeet sharma)
Date: Fri, 13 Jun 2025 11:27:51 +0530
Subject: [OpenSIPS-Users] Subscribe events to http or https
In-Reply-To: <CAOAEC9FbgYni8r4j0+mbHSyK5-ZtDJZigs0DCcdv7+UGgTDcKg@mail.gmail.com>
References: <CAOAEC9FbgYni8r4j0+mbHSyK5-ZtDJZigs0DCcdv7+UGgTDcKg@mail.gmail.com>
Message-ID: <CAOAEC9H_fsP60+gyV9gDpfEpGPLvgjmsLt4Fwk1CGJT5A8cT0Q@mail.gmail.com>

Thanks Ražvan, rest_agent is working as expected.

On Wed, 11 Jun 2025 at 6:42 pm, inderjeet sharma <inder.itpro at gmail.com>
wrote:

> Hi,
>
> I want to send Opensips events directly to an https webhook url.
> subscribe_event(“E_UL_CONTACT_INSERT”, “https://xyz.com:8089/webook”);
> Is this supported? If not, what is the recommended way to send events to
> http/https?
>
> Version: opensips 3.4.10
>
> Thanks
> Inderjeet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250613/16589d80/attachment.html>

From andrey55555 at gmail.com  Wed Jun 18 13:19:14 2025
From: andrey55555 at gmail.com (Andrew)
Date: Wed, 18 Jun 2025 16:19:14 +0300
Subject: [OpenSIPS-Users] Nightly RPM builds are broken
Message-ID: <CA+B63qKS3OLxuTHSw4xhrgCJzLrq1H48C-nOqXL=FX7dfF1ijA@mail.gmail.com>

Hi
Nightly RPM builds are not published since 03.06

Best regards, Andrew.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250618/88cd5cf2/attachment.html>

From razvan at opensips.org  Wed Jun 18 13:38:37 2025
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Wed, 18 Jun 2025 16:38:37 +0300
Subject: [OpenSIPS-Users] Nightly RPM builds are broken
In-Reply-To: <CA+B63qKS3OLxuTHSw4xhrgCJzLrq1H48C-nOqXL=FX7dfF1ijA@mail.gmail.com>
References: <CA+B63qKS3OLxuTHSw4xhrgCJzLrq1H48C-nOqXL=FX7dfF1ijA@mail.gmail.com>
Message-ID: <0d354672-567a-4dcb-a426-ffe42b6b7676@opensips.org>

Hi, Andrew!

Thanks for pointing it out, i've just fixed them. However, it is going 
to take a few hours until all packages are re-generated. Please let me 
know if they do not appear by tomorrow.

Best regards,

Răzvan Crainea
OpenSIPS Core Developer / SIPhub CTO
http://www.opensips-solutions.com / https://www.siphub.com

On 6/18/25 4:19 PM, Andrew wrote:
> Hi
> Nightly RPM builds are not published since 03.06
> 
> Best regards, Andrew.
> 
> 
> Hi
> Nightly RPM builds are not published since 03.06
> 
> Best regards, Andrew.
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From apsaras at microbase.gr  Fri Jun 20 09:24:28 2025
From: apsaras at microbase.gr (Antonios Psaras)
Date: Fri, 20 Jun 2025 12:24:28 +0300
Subject: [OpenSIPS-Users] Registrant & LB with SRV
Message-ID: <32f101dbe1c5$1f2cd3c0$5d867b40$@microbase.gr>

Hello Team

 

I have the following situation.

 

A telecom carrier requires SIP Registration prior to Dial out using SIP
Domain and SRV Lookup.

 

To achieve that I am using registrant module and load balancing module.

 

The problem I have, is that in some cases registrant registers on different
SBC of the Carrier than the one resolved by Load Balancer Module so my
outbound calls are failing with 407.

 

I have two thoughts but I do not know how to implement any of those.

 

1.	Instead of using LB Modules, I will some how get the registrar IP
from registrant module and statically route the calls through that. Is there
a way to get that information from registrant module?
2.	DNS lookup is done automatically only in case of 503 or timeout. Is
there a way to force DNS lookup with in OpenSIP Script? If yes I can handle
407, force DNS Lookup, create a new branch and re-send the call.

 

Any other thoughts are welcome

 

Best regards

 

Antonis Psaras

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250620/60e474a9/attachment.html>

From slackway2me at gmail.com  Fri Jun 20 11:45:26 2025
From: slackway2me at gmail.com (Alexey)
Date: Fri, 20 Jun 2025 16:45:26 +0500
Subject: [OpenSIPS-Users] clusterer_shtag_set_INactive
Message-ID: <CAPc6LUEsTns7xMA7O9dO0aaSJFosFT0vDMXTPihyg7PiiLPdMA@mail.gmail.com>

Hi list, hi Team,

I would like to know if it is possible to add one more
MI command for the clusterer module, which will be
the opposite for the 'clusterer_shtag_set_active' command.

E.g. 'clusterer_shtag_set_inactive'.
It could be very useful in some scenarios.

We have an active/standby cluster based on Keepalived.
And Keepalived is configured with the ability to be switched
manually from active to standby. I mean that the keepalived.conf
on both nodes has these two not default options:

    state BACKUP        # both must be BACKUP for nopreempt to work
    nopreempt

And keepalived is configured to execute the script when the node
becomes active (or 'master' in keepalived terminology):

    ...
    vrrp_instance voip {

        notify_master "/etc/keepalived/master-backup.sh MASTER"
        notify_backup "/etc/keepalived/master-backup.sh BACKUP"
        notify_stop "/etc/keepalived/master-backup.sh STOP"
        notify_fault "/etc/keepalived/master-backup.sh FAULT"
    ...


And this script runs MI command:

    ...
    /usr/bin/opensips-cli -x mi clusterer_shtag_set_active vip/1
    ...

Keepalived works well.

One OpenSIPS node has the following configuration
of the clusterer module and sharing_tags:

...
modparam("clusterer", "sharing_tag", "vip/1=active")
...


The other one - the following:
...
modparam("clusterer", "sharing_tag", "vip/1=backup")
...


So, if the state of nodes changes, we can run MI command
'clusterer_shtag_set_active' triggered by Keepalived state change,
and we do it.

But if the first node is rebooted, OpenSIPS starts with the configured options -
modparam("clusterer", "sharing_tag", "vip/1=active") .

But because of 'nopreempt' option in keepalived.conf the state
of the nodes remains unchanged (I configured it on purpose,
it's convenient for me to be able to switch nodes manually and
to decide which one will be active - I copied the behavior of AcmePacket SBC
with these options).

So, in some cases the situation bacomes as follows:
the second node became active (either manually or because of some
problems on the first node) and remains in active state.

But after rebooting the first node OpenSIPS on it starts with
modparam("clusterer", "sharing_tag", "vip/1=active") parameters.

So, since that, both nodes are sure that each of them should have
active sharing_tags.
At the same time, keepalived on the first node enters backup state,
because it sees that the second node is already in master state
(nopreempt option works).

If such a command existed, I could use it in keepalived config/script
and run it during switching to backup, something like -

     /usr/bin/opensips-cli -x mi clusterer_shtag_set_INactive vip/1


-- 
best regards, Alexey
https://alexeyka.zantsev.com/


From wadii.elmajdi at gmail.com  Fri Jun 20 13:01:30 2025
From: wadii.elmajdi at gmail.com (Wadii)
Date: Fri, 20 Jun 2025 15:01:30 +0200
Subject: [OpenSIPS-Users] clusterer_shtag_set_INactive
In-Reply-To: <CAPc6LUEsTns7xMA7O9dO0aaSJFosFT0vDMXTPihyg7PiiLPdMA@mail.gmail.com>
References: <CAPc6LUEsTns7xMA7O9dO0aaSJFosFT0vDMXTPihyg7PiiLPdMA@mail.gmail.com>
Message-ID: <CAEeO=-HLXjhtSz-P9pFc4LcbUUtEQ_SE7VxYWj==d9Cw02mGRg@mail.gmail.com>

hello
I had a similar setup, you can avoid the split brain issue by not
hardcoding the sharing_tag active state in clusterer module config
Either set both servers to start with 'backup' state / 'none' by removing
the param entirely, then few seconds after startup via startup_route each
server checks if it actually has the VIP and only then sets itself active
if needed.

startup_route {
launch(exec("sleep 10 && /path/check_vip.py",, $var(out), $var(err)),
vip_check_route);
}

This way reality determines who's active, not config files

Le ven. 20 juin 2025 à 13:48, Alexey <slackway2me at gmail.com> a écrit :

> Hi list, hi Team,
>
> I would like to know if it is possible to add one more
> MI command for the clusterer module, which will be
> the opposite for the 'clusterer_shtag_set_active' command.
>
> E.g. 'clusterer_shtag_set_inactive'.
> It could be very useful in some scenarios.
>
> We have an active/standby cluster based on Keepalived.
> And Keepalived is configured with the ability to be switched
> manually from active to standby. I mean that the keepalived.conf
> on both nodes has these two not default options:
>
>     state BACKUP        # both must be BACKUP for nopreempt to work
>     nopreempt
>
> And keepalived is configured to execute the script when the node
> becomes active (or 'master' in keepalived terminology):
>
>     ...
>     vrrp_instance voip {
>
>         notify_master "/etc/keepalived/master-backup.sh MASTER"
>         notify_backup "/etc/keepalived/master-backup.sh BACKUP"
>         notify_stop "/etc/keepalived/master-backup.sh STOP"
>         notify_fault "/etc/keepalived/master-backup.sh FAULT"
>     ...
>
>
> And this script runs MI command:
>
>     ...
>     /usr/bin/opensips-cli -x mi clusterer_shtag_set_active vip/1
>     ...
>
> Keepalived works well.
>
> One OpenSIPS node has the following configuration
> of the clusterer module and sharing_tags:
>
> ...
> modparam("clusterer", "sharing_tag", "vip/1=active")
> ...
>
>
> The other one - the following:
> ...
> modparam("clusterer", "sharing_tag", "vip/1=backup")
> ...
>
>
> So, if the state of nodes changes, we can run MI command
> 'clusterer_shtag_set_active' triggered by Keepalived state change,
> and we do it.
>
> But if the first node is rebooted, OpenSIPS starts with the configured
> options -
> modparam("clusterer", "sharing_tag", "vip/1=active") .
>
> But because of 'nopreempt' option in keepalived.conf the state
> of the nodes remains unchanged (I configured it on purpose,
> it's convenient for me to be able to switch nodes manually and
> to decide which one will be active - I copied the behavior of AcmePacket
> SBC
> with these options).
>
> So, in some cases the situation bacomes as follows:
> the second node became active (either manually or because of some
> problems on the first node) and remains in active state.
>
> But after rebooting the first node OpenSIPS on it starts with
> modparam("clusterer", "sharing_tag", "vip/1=active") parameters.
>
> So, since that, both nodes are sure that each of them should have
> active sharing_tags.
> At the same time, keepalived on the first node enters backup state,
> because it sees that the second node is already in master state
> (nopreempt option works).
>
> If such a command existed, I could use it in keepalived config/script
> and run it during switching to backup, something like -
>
>      /usr/bin/opensips-cli -x mi clusterer_shtag_set_INactive vip/1
>
>
> --
> best regards, Alexey
> https://alexeyka.zantsev.com/
>
> _______________________________________________
> 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/20250620/c434e111/attachment.html>

From walter.schober at neotel.at  Mon Jun 23 07:37:27 2025
From: walter.schober at neotel.at (Walter Schober)
Date: Mon, 23 Jun 2025 07:37:27 +0000
Subject: [OpenSIPS-Users] Registrant & LB with SRV
In-Reply-To: <32f101dbe1c5$1f2cd3c0$5d867b40$@microbase.gr>
References: <32f101dbe1c5$1f2cd3c0$5d867b40$@microbase.gr>
Message-ID: <AS2PR02MB99301C21903A47BEDAB42C568D79A@AS2PR02MB9930.eurprd02.prod.outlook.com>

Hello Antonis!

IMHO the carrier cannot expect Register and Invite going to the same destination if the SRV for _the_ service is load-balanced.

We do offer such a service as carrier also but encountered the issue with LB on nearly every device, incl. phones. Since we also need the call to be established across the same service endpoint selected in the Register process we set priorities on each SRV for each datacenter.
For such cases we do additionally name two A records where the endpoint must register on both and then can do LB calls to each. Otherwise the carriers service must allow registers and invites going different ways. It is **one** service based on the SRV entry!

Br
Walter

Von: Users <users-bounces at lists.opensips.org> Im Auftrag von Antonios Psaras
Gesendet: Freitag, 20. Juni 2025 11:24
An: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Betreff: [OpenSIPS-Users] Registrant & LB with SRV

Hello Team

I have the following situation.

A telecom carrier requires SIP Registration prior to Dial out using SIP Domain and SRV Lookup.

To achieve that I am using registrant module and load balancing module.

The problem I have, is that in some cases registrant registers on different SBC of the Carrier than the one resolved by Load Balancer Module so my outbound calls are failing with 407.

I have two thoughts but I do not know how to implement any of those.


  1.  Instead of using LB Modules, I will some how get the registrar IP from registrant module and statically route the calls through that. Is there a way to get that information from registrant module?
  2.  DNS lookup is done automatically only in case of 503 or timeout. Is there a way to force DNS lookup with in OpenSIP Script? If yes I can handle 407, force DNS Lookup, create a new branch and re-send the call.

Any other thoughts are welcome

Best regards

Antonis Psaras

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250623/d77ec474/attachment.html>

From apsaras at microbase.gr  Mon Jun 23 08:38:28 2025
From: apsaras at microbase.gr (Antonios Psaras)
Date: Mon, 23 Jun 2025 11:38:28 +0300
Subject: [OpenSIPS-Users] Registrant & LB with SRV
In-Reply-To: <AS2PR02MB99301C21903A47BEDAB42C568D79A@AS2PR02MB9930.eurprd02.prod.outlook.com>
References: <32f101dbe1c5$1f2cd3c0$5d867b40$@microbase.gr>
 <AS2PR02MB99301C21903A47BEDAB42C568D79A@AS2PR02MB9930.eurprd02.prod.outlook.com>
Message-ID: <3b6401dbe41a$31755fa0$94601ee0$@microbase.gr>

Thank you Walter for your reply.

 

Unfortunately there is no way to change Carrier's configuration so we need
to find a way to tackle the issue on our side.

 

Thanks again.

 

Regards

 

From: Walter Schober <walter.schober at neotel.at> 
Sent: Δευτέρα, 23 Ιουνίου 2025 10:37
To: OpenSIPS users mailling list <users at lists.opensips.org>
Cc: apsaras at microbase.gr
Subject: AW: [OpenSIPS-Users] Registrant & LB with SRV

 

Hello Antonis!

 

IMHO the carrier cannot expect Register and Invite going to the same
destination if the SRV for _the_ service is load-balanced.

 

We do offer such a service as carrier also but encountered the issue with LB
on nearly every device, incl. phones. Since we also need the call to be
established across the same service endpoint selected in the Register
process we set priorities on each SRV for each datacenter.

For such cases we do additionally name two A records where the endpoint must
register on both and then can do LB calls to each. Otherwise the carriers
service must allow registers and invites going different ways. It is **one**
service based on the SRV entry!

 

Br

Walter

 

Von: Users <users-bounces at lists.opensips.org
<mailto:users-bounces at lists.opensips.org> > Im Auftrag von Antonios Psaras
Gesendet: Freitag, 20. Juni 2025 11:24
An: 'OpenSIPS users mailling list' <users at lists.opensips.org
<mailto:users at lists.opensips.org> >
Betreff: [OpenSIPS-Users] Registrant & LB with SRV

 

Hello Team

 

I have the following situation.

 

A telecom carrier requires SIP Registration prior to Dial out using SIP
Domain and SRV Lookup.

 

To achieve that I am using registrant module and load balancing module.

 

The problem I have, is that in some cases registrant registers on different
SBC of the Carrier than the one resolved by Load Balancer Module so my
outbound calls are failing with 407.

 

I have two thoughts but I do not know how to implement any of those.

 

1.	Instead of using LB Modules, I will some how get the registrar IP
from registrant module and statically route the calls through that. Is there
a way to get that information from registrant module?
2.	DNS lookup is done automatically only in case of 503 or timeout. Is
there a way to force DNS lookup with in OpenSIP Script? If yes I can handle
407, force DNS Lookup, create a new branch and re-send the call.

 

Any other thoughts are welcome

 

Best regards

 

Antonis Psaras

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250623/4a666bfd/attachment-0001.html>

From rrevels at bandwidth.com  Tue Jun 24 16:52:29 2025
From: rrevels at bandwidth.com (Richard Revels)
Date: Tue, 24 Jun 2025 12:52:29 -0400
Subject: [OpenSIPS-Users] questions about WARNING:core:utimer_ticker
Message-ID: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>

Greetings,
I have started having issues with some proxies running opensips 3.2.19 and
some others running 3.4.12
With approximately 230 cps and 7300 dialogs the proxy starts emitting log
messages like

Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 150
ms ago (now 3671145080 ms), delaying execution
Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 200
ms ago (now 3671145130 ms), delaying execution
Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 300
ms ago (now 3671145230 ms), delaying execution
Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 400
ms ago (now 3671145330 ms), delaying execution
Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 500
ms ago (now 3671145430 ms), delaying execution
Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 600
ms ago (now 3671145530 ms), delaying execution
Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 700
ms ago (now 3671145630 ms), delaying execution
Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 800
ms ago (now 3671145730 ms), delaying execution
Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 900
ms ago (now 3671145830 ms), delaying execution
Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 1000 ms
ago (now 3671145830 ms), delaying execution


The cpu usage on the threads goes from 3% - 11% depending on thread to 30%
across the board.

I have been running these versions of opensips for some time now (months
for 3.4 and years for 3.2) and do see occasional latency in db or rest
connection responses but only recently have started having this issue.

So,

How are SIP calls distributed across the processing threads?  I was
thinking it would be round robin w/ attention given to busy or not.  but it
seems like the lower pid threads do a lot more work on these proxies

What are possible causes of the timers having trouble completing tasks?  is
it cpu use, waiting on some other task to finish, combination or more?

Is there tuning that can be done to have more timer handling threads?  i
tried this with modparam("tm", "timer_partitions") which seemed to make the
problem worse

Thank you in advance for any guidance you can give me on troubleshooting
this issue.
Richard Revels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250624/60da4979/attachment.html>

From nilesh.apte at jampot.in  Tue Jun 24 19:31:13 2025
From: nilesh.apte at jampot.in (Nilesh Apte)
Date: Tue, 24 Jun 2025 21:31:13 +0200
Subject: [OpenSIPS-Users] questions about WARNING:core:utimer_ticker
In-Reply-To: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>
References: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>
Message-ID: <CACOoWtngy-ohnboQGLfu1nBw1OjshA6R=f=F+CCfhRxJ1MJjmA@mail.gmail.com>

Hello Opensips community,

I would like to know if anyone can help me create a SIP trunk between two
VoIP systems using an OpenSIPS server.

Thank you in advance for your help.

Best,
Nilesh

*Nilesh APTE*:

Jampot Technologies Pvt Ltd.

Cell:+91-9920104880 |Belgium:+32-474692366

Email: nilesh.apte at jampot.in
Addr: Office No.807 & 808, Skyline Wealthspace C, near SBI ATM, Vidyavihar
Scoiety, Vidyavihar, Mumbai, Maharastra, India.

Landline Number +91-22-2511 4500 |Support +91-9595901020 |Sales
+91-8600801010


On Tue, 24 Jun 2025 at 18:55, Richard Revels via Users <
users at lists.opensips.org> wrote:

> Greetings,
> I have started having issues with some proxies running opensips 3.2.19 and
> some others running 3.4.12
> With approximately 230 cps and 7300 dialogs the proxy starts emitting log
> messages like
>
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 150
> ms ago (now 3671145080 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 200
> ms ago (now 3671145130 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 300
> ms ago (now 3671145230 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 400
> ms ago (now 3671145330 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 500
> ms ago (now 3671145430 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 600
> ms ago (now 3671145530 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 700
> ms ago (now 3671145630 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 800
> ms ago (now 3671145730 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 900
> ms ago (now 3671145830 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 1000 ms
> ago (now 3671145830 ms), delaying execution
>
>
> The cpu usage on the threads goes from 3% - 11% depending on thread to 30%
> across the board.
>
> I have been running these versions of opensips for some time now (months
> for 3.4 and years for 3.2) and do see occasional latency in db or rest
> connection responses but only recently have started having this issue.
>
> So,
>
> How are SIP calls distributed across the processing threads?  I was
> thinking it would be round robin w/ attention given to busy or not.  but it
> seems like the lower pid threads do a lot more work on these proxies
>
> What are possible causes of the timers having trouble completing tasks?
> is it cpu use, waiting on some other task to finish, combination or more?
>
> Is there tuning that can be done to have more timer handling threads?  i
> tried this with modparam("tm", "timer_partitions") which seemed to make the
> problem worse
>
> Thank you in advance for any guidance you can give me on troubleshooting
> this issue.
> Richard Revels
>
>
> _______________________________________________
> 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/20250624/17abf9a3/attachment-0001.html>

From greg at switchtel.co.za  Wed Jun 25 17:17:38 2025
From: greg at switchtel.co.za (Gregory Massel)
Date: Wed, 25 Jun 2025 19:17:38 +0200
Subject: [OpenSIPS-Users] questions about WARNING:core:utimer_ticker
In-Reply-To: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>
References: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>
Message-ID: <ee39d509-d0e1-4f45-bf10-5ce5c08ba2e1@switchtel.co.za>

I get these on my most lightly loaded system, yet none at all on my most 
heavily loaded system...

Although the error is generic enough that, on its own, it doesn't really 
help to determine what the problem is, on my system the tm-utimer 
messages are often accompanied by TLS errors such as:

ERROR:tls_wolfssl:_wolfssl_tls_conn_shutdown: no ssl data

ERROR:tm:msg_send: send() to x.x.x.x:5061 for proto tls/3 failed

(Note: While I'm currently using WolfSSL, I previously used OpenSSL and 
experienced similar issues.)

That's not to say that you're getting the error for the same reason as 
me; just to point out that there should be related errors before or 
after the tm-utimer warnings. It may be tricky to find them on a system 
with your sorts of volumes as, in my case, the TLS errors are typically 
just over 2 minutes AFTER the tm-utimer warnings. On a busy system, a 
lot of unrelated log entries are likely to generate in between.

The low-load system with these issue has outbound TLS. The high-load 
system without these issues does no outbound TLS; the only TLS it 
handles are inbound WSS connections.

With regard to your question about threads, take a look at:
https://www.opensips.org/Documentation/Script-CoreParameters-3-4#tcp_workers
https://www.opensips.org/Documentation/Script-CoreParameters-3-4#udp_workers

--Greg

On 2025-06-24 18:52, Richard Revels via Users wrote:
> Greetings,
> I have started having issues with some proxies running opensips 3.2.19 
> and some others running 3.4.12
> With approximately 230 cps and 7300 dialogs the proxy starts emitting 
> log messages like
>
> Jun 24 15:42:18 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 150 ms ago (now 3671145080 
> ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 200 ms ago (now 3671145130 
> ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 300 ms ago (now 3671145230 
> ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 400 ms ago (now 3671145330 
> ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 500 ms ago (now 3671145430 
> ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 600 ms ago (now 3671145530 
> ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 700 ms ago (now 3671145630 
> ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 800 ms ago (now 3671145730 
> ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker: 
> utimer task <tm-utimer> already scheduled 900 ms ago (now 3671145830 
> ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local 
> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:timer_ticker: 
> timer task <tm-timer> already scheduled 1000 ms ago (now 3671145830 
> ms), delaying execution
>
>
> The cpu usage on the threads goes from 3% - 11% depending on thread to 
> 30% across the board.
>
> I have been running these versions of opensips for some time now 
> (months for 3.4 and years for 3.2) and do see occasional latency in db 
> or rest connection responses but only recently have started having 
> this issue.
>
> So,
>
> How are SIP calls distributed across the processing threads? I was 
> thinking it would be round robin w/ attention given to busy or not.  
> but it seems like the lower pid threads do a lot more work on these 
> proxies
>
> What are possible causes of the timers having trouble completing 
> tasks?  is it cpu use, waiting on some other task to finish, 
> combination or more?
>
> Is there tuning that can be done to have more timer handling threads?  
> i tried this with modparam("tm", "timer_partitions") which seemed to 
> make the problem worse
>
> Thank you in advance for any guidance you can give me on 
> troubleshooting this issue.
> Richard Revels
>
>
>
> _______________________________________________
> 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/20250625/e8e4b456/attachment.html>

From rrevels at bandwidth.com  Wed Jun 25 22:18:50 2025
From: rrevels at bandwidth.com (Richard Revels)
Date: Wed, 25 Jun 2025 18:18:50 -0400
Subject: [OpenSIPS-Users] questions about WARNING:core:utimer_ticker
In-Reply-To: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>
References: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>
Message-ID: <CAE-NtRfBJUb2SE47kQ80m=t5peB_EeAMz-eVDk9ORzFPyBGQKg@mail.gmail.com>

Okay, I'm starting to get a handle on what I'm looking at now and those
timer messages appear to be related to Opensips not shutting down cleanly
rather than the segfault itself.  My question around tm timer tuning should
have been in reference to this type of message:

NOTICE:tm:timer_routine: time spent: 0.780s now at 75%+ capacity,
inuse_transactions: 11070
NOTICE:tm:utimer_routine: time spent: 0.680s now at 75%+ capacity,
inuse_transactions: 11070

I'll come back to the core dumps if I ever get a clean core file.

Richard Revels


On Tue, Jun 24, 2025 at 12:52 PM Richard Revels <rrevels at bandwidth.com>
wrote:

> Greetings,
> I have started having issues with some proxies running opensips 3.2.19 and
> some others running 3.4.12
> With approximately 230 cps and 7300 dialogs the proxy starts emitting log
> messages like
>
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 150
> ms ago (now 3671145080 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 200
> ms ago (now 3671145130 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 300
> ms ago (now 3671145230 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 400
> ms ago (now 3671145330 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 500
> ms ago (now 3671145430 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 600
> ms ago (now 3671145530 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 700
> ms ago (now 3671145630 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 800
> ms ago (now 3671145730 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 900
> ms ago (now 3671145830 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 1000 ms
> ago (now 3671145830 ms), delaying execution
>
>
> The cpu usage on the threads goes from 3% - 11% depending on thread to 30%
> across the board.
>
> I have been running these versions of opensips for some time now (months
> for 3.4 and years for 3.2) and do see occasional latency in db or rest
> connection responses but only recently have started having this issue.
>
> So,
>
> How are SIP calls distributed across the processing threads?  I was
> thinking it would be round robin w/ attention given to busy or not.  but it
> seems like the lower pid threads do a lot more work on these proxies
>
> What are possible causes of the timers having trouble completing tasks?
> is it cpu use, waiting on some other task to finish, combination or more?
>
> Is there tuning that can be done to have more timer handling threads?  i
> tried this with modparam("tm", "timer_partitions") which seemed to make the
> problem worse
>
> Thank you in advance for any guidance you can give me on troubleshooting
> this issue.
> Richard Revels
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250625/154763bc/attachment-0001.html>

From rrevels at bandwidth.com  Wed Jun 25 22:24:08 2025
From: rrevels at bandwidth.com (Richard Revels)
Date: Wed, 25 Jun 2025 18:24:08 -0400
Subject: [OpenSIPS-Users] questions about WARNING:core:utimer_ticker
In-Reply-To: <ee39d509-d0e1-4f45-bf10-5ce5c08ba2e1@switchtel.co.za>
References: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>
 <ee39d509-d0e1-4f45-bf10-5ce5c08ba2e1@switchtel.co.za>
Message-ID: <CAE-NtRfWwiHEKk=upiJpe-Uh-R2YXxEJ3-06=CFr3e_hdv1U8w@mail.gmail.com>

Ah, Thank You.  Yes, I have come to the same conclusion that those messages
are after the problem rather than before.   I didn't take enough time to
really dig into the logs before send that message I reckon.


On Wed, Jun 25, 2025 at 1:20 PM Gregory Massel via Users <
users at lists.opensips.org> wrote:

> I get these on my most lightly loaded system, yet none at all on my most
> heavily loaded system...
>
> Although the error is generic enough that, on its own, it doesn't really
> help to determine what the problem is, on my system the tm-utimer messages
> are often accompanied by TLS errors such as:
>
> ERROR:tls_wolfssl:_wolfssl_tls_conn_shutdown: no ssl data
>
> ERROR:tm:msg_send: send() to x.x.x.x:5061 for proto tls/3 failed
>
> (Note: While I'm currently using WolfSSL, I previously used OpenSSL and
> experienced similar issues.)
> That's not to say that you're getting the error for the same reason as me;
> just to point out that there should be related errors before or after the
> tm-utimer warnings. It may be tricky to find them on a system with your
> sorts of volumes as, in my case, the TLS errors are typically just over 2
> minutes AFTER the tm-utimer warnings. On a busy system, a lot of unrelated
> log entries are likely to generate in between.
>
> The low-load system with these issue has outbound TLS. The high-load
> system without these issues does no outbound TLS; the only TLS it handles
> are inbound WSS connections.
>
> With regard to your question about threads, take a look at:
>
> https://www.opensips.org/Documentation/Script-CoreParameters-3-4#tcp_workers
>
> https://www.opensips.org/Documentation/Script-CoreParameters-3-4#udp_workers
>
> --Greg
>
> On 2025-06-24 18:52, Richard Revels via Users wrote:
>
> Greetings,
> I have started having issues with some proxies running opensips 3.2.19 and
> some others running 3.4.12
> With approximately 230 cps and 7300 dialogs the proxy starts emitting log
> messages like
>
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 150
> ms ago (now 3671145080 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 200
> ms ago (now 3671145130 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 300
> ms ago (now 3671145230 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 400
> ms ago (now 3671145330 ms), delaying execution
> Jun 24 15:42:18 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 500
> ms ago (now 3671145430 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 600
> ms ago (now 3671145530 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 700
> ms ago (now 3671145630 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 800
> ms ago (now 3671145730 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already scheduled 900
> ms ago (now 3671145830 ms), delaying execution
> Jun 24 15:42:19 sip-proxy.local /usr/local/opensips/sbin/opensips[190328]:
> WARNING:core:timer_ticker: timer task <tm-timer> already scheduled 1000 ms
> ago (now 3671145830 ms), delaying execution
>
>
> The cpu usage on the threads goes from 3% - 11% depending on thread to 30%
> across the board.
>
> I have been running these versions of opensips for some time now (months
> for 3.4 and years for 3.2) and do see occasional latency in db or rest
> connection responses but only recently have started having this issue.
>
> So,
>
> How are SIP calls distributed across the processing threads?  I was
> thinking it would be round robin w/ attention given to busy or not.  but it
> seems like the lower pid threads do a lot more work on these proxies
>
> What are possible causes of the timers having trouble completing tasks?
> is it cpu use, waiting on some other task to finish, combination or more?
>
> Is there tuning that can be done to have more timer handling threads?  i
> tried this with modparam("tm", "timer_partitions") which seemed to make the
> problem worse
>
> Thank you in advance for any guidance you can give me on troubleshooting
> this issue.
> Richard Revels
>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://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/20250625/8c5cfab6/attachment.html>

From liviu at opensips.org  Thu Jun 26 12:16:59 2025
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 26 Jun 2025 15:16:59 +0300
Subject: [OpenSIPS-Users] [Minor Release] OpenSIPS 3.5.6 and 3.4.13 Minor
	Releases
In-Reply-To: <effdb0b8-f99a-4b87-84a0-c284319a9ab6@opensips.org>
References: <effdb0b8-f99a-4b87-84a0-c284319a9ab6@opensips.org>
Message-ID: <53981b02-cdcb-cbdc-65dc-47d06e3d6470@opensips.org>

Hello!

It is my pleasure to announce the *3.5.6* and *3.4.13* minor releases, 
which include roughly 40 commits worth of fixes and improvements done in 
the past two months.

To name a few of the improved areas: STIR/SHAKEN stability, TLS 
improvements and bugfixes in at least: tm with SRV failover, 
sql_update(), dialog CSeq replication, dns_cache and dispatcher's 
/persistent_state/ and /pvar_algo_pattern/ features.

Do make sure to roll out an update as soon as possible -- it is highly 
recommended.

Full changelogs:
https://opensips.org/pub/opensips/3.5.6/ChangeLog
https://opensips.org/pub/opensips/3.4.13/ChangeLog

Packages are already available:
   DEBs: https://apt.opensips.org
   RPMs: https://yum.opensips.org

Please enjoy,
OpenSIPS Team

-- 
Liviu Chircu
www.opensips-solutions.com  |www.siphub.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250626/693ecbbb/attachment.html>

From trevor at webon.co.za  Thu Jun 26 20:26:03 2025
From: trevor at webon.co.za (trevor at webon.co.za)
Date: Thu, 26 Jun 2025 22:26:03 +0200
Subject: [OpenSIPS-Users] Cluster Neighbour status in script
Message-ID: <8115da3a65c7d5e90ab312929d72f5e6c510549b.camel@webon.co.za>

Hi All, 

Is there a simple way to check to cluster neighbour status up/down from
script?

I cant seem to find anything I have a workaround using
E_CLUSTERER_NODE_STATE_CHANGED and  localcache to write status into
cache just wondering if there is a cleaner way to do this from inside
script.

Thanks

Regards
Trevor Steyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250626/004afeff/attachment.html>

From venefax at gmail.com  Thu Jun 26 21:57:34 2025
From: venefax at gmail.com (Federico Alves)
Date: Thu, 26 Jun 2025 17:57:34 -0400
Subject: [OpenSIPS-Users] Topology_hiding took down my carrier's switch
Message-ID: <CAC9cSOCPLD5t0y5Mfnf=2R=ScWdKuykRwA+2AD7ZZ9y1Ukj1vQ@mail.gmail.com>

So far my engineers use topology_hiding(), and the CallID from the client
was passing forward to the carrrier. So we switched to topology_hiding("C")
and worked as expected but the carrier's switch collapsed after a while.
They say that we leave many dialogs open thar never close. Other than that,
th3 calls work fine for us.
What are my engineers doing wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250626/1392db22/attachment.html>

From nilesh.apte at jampot.in  Mon Jun 30 08:48:52 2025
From: nilesh.apte at jampot.in (Nilesh Apte)
Date: Mon, 30 Jun 2025 10:48:52 +0200
Subject: [OpenSIPS-Users] establish a SIP trunk connection between two
	distinct VoIP systems
In-Reply-To: <CACOoWtngy-ohnboQGLfu1nBw1OjshA6R=f=F+CCfhRxJ1MJjmA@mail.gmail.com>
References: <CAE-NtRedjL=PYmED=jL+XQXzL4zC3aWaOKD3z2QvZwFo82Db5A@mail.gmail.com>
 <CACOoWtngy-ohnboQGLfu1nBw1OjshA6R=f=F+CCfhRxJ1MJjmA@mail.gmail.com>
Message-ID: <CACOoWtkdcE-Tqafq=vU3FQS1DN4UkqWjWygjRckEXTeZFmnz8g@mail.gmail.com>

Hello OpenSIPS community,

I'm currently working on a project and would greatly appreciate some
assistance from anyone who might have experience in this area. My objective
is to establish a SIP trunk connection between two distinct VoIP systems,
with an OpenSIPS server acting as the intermediary.

If anyone has insights, guides, or examples on how to configure OpenSIPS
for this specific scenario, your help would be invaluable. I'm looking for
guidance on the necessary configuration steps and best practices to ensure
a stable and reliable connection.

Thank you in advance for your time and expertise.

Best regards,
Nilesh


On Tue, Jun 24, 2025 at 9:31 PM Nilesh Apte <nilesh.apte at jampot.in> wrote:

> Hello Opensips community,
>
> I would like to know if anyone can help me create a SIP trunk between two
> VoIP systems using an OpenSIPS server.
>
> Thank you in advance for your help.
>
> Best,
> Nilesh
>
> *Nilesh APTE*:
>
> Jampot Technologies Pvt Ltd.
>
> Cell:+91-9920104880 |Belgium:+32-474692366
>
> Email: nilesh.apte at jampot.in
> Addr: Office No.807 & 808, Skyline Wealthspace C, near SBI ATM,
> Vidyavihar Scoiety, Vidyavihar, Mumbai, Maharastra, India.
>
> Landline Number +91-22-2511 4500 |Support +91-9595901020 |Sales
> +91-8600801010
>
>
> On Tue, 24 Jun 2025 at 18:55, Richard Revels via Users <
> users at lists.opensips.org> wrote:
>
>> Greetings,
>> I have started having issues with some proxies running opensips 3.2.19
>> and some others running 3.4.12
>> With approximately 230 cps and 7300 dialogs the proxy starts emitting log
>> messages like
>>
>> Jun 24 15:42:18 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 150 ms ago (now 3671145080 ms),
>> delaying execution
>> Jun 24 15:42:18 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 200 ms ago (now 3671145130 ms),
>> delaying execution
>> Jun 24 15:42:18 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 300 ms ago (now 3671145230 ms),
>> delaying execution
>> Jun 24 15:42:18 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 400 ms ago (now 3671145330 ms),
>> delaying execution
>> Jun 24 15:42:18 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 500 ms ago (now 3671145430 ms),
>> delaying execution
>> Jun 24 15:42:19 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 600 ms ago (now 3671145530 ms),
>> delaying execution
>> Jun 24 15:42:19 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 700 ms ago (now 3671145630 ms),
>> delaying execution
>> Jun 24 15:42:19 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 800 ms ago (now 3671145730 ms),
>> delaying execution
>> Jun 24 15:42:19 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:utimer_ticker:
>> utimer task <tm-utimer> already scheduled 900 ms ago (now 3671145830 ms),
>> delaying execution
>> Jun 24 15:42:19 sip-proxy.local
>> /usr/local/opensips/sbin/opensips[190328]: WARNING:core:timer_ticker: timer
>> task <tm-timer> already scheduled 1000 ms ago (now 3671145830 ms), delaying
>> execution
>>
>>
>> The cpu usage on the threads goes from 3% - 11% depending on thread to
>> 30% across the board.
>>
>> I have been running these versions of opensips for some time now (months
>> for 3.4 and years for 3.2) and do see occasional latency in db or rest
>> connection responses but only recently have started having this issue.
>>
>> So,
>>
>> How are SIP calls distributed across the processing threads?  I was
>> thinking it would be round robin w/ attention given to busy or not.  but it
>> seems like the lower pid threads do a lot more work on these proxies
>>
>> What are possible causes of the timers having trouble completing tasks?
>> is it cpu use, waiting on some other task to finish, combination or more?
>>
>> Is there tuning that can be done to have more timer handling threads?  i
>> tried this with modparam("tm", "timer_partitions") which seemed to make the
>> problem worse
>>
>> Thank you in advance for any guidance you can give me on troubleshooting
>> this issue.
>> Richard Revels
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>

-- 

*Nilesh APTE*:

Jampot Technologies Pvt Ltd.

Cell:+91-9920104880 |Belgium:+32-474692366

Email: nilesh.apte at jampot.in
Addr: Office No.807 & 808, Skyline Wealthspace C, near SBI ATM, Vidyavihar
Scoiety, Vidyavihar, Mumbai, Maharastra, India.

Landline Number +91-22-2511 4500 |Support +91-9595901020 |Sales
+91-8600801010
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250630/da5861f8/attachment.html>