From pkelly at gmail.com  Thu May  1 20:24:43 2025
From: pkelly at gmail.com (Pete Kelly)
Date: Thu, 1 May 2025 13:24:43 -0700
Subject: [OpenSIPS-Users] apt repo SSL cert expired
Message-ID: <CAEWH9M-yMkEz-Mdh2+YU7aKKYr==33qYdKEAqdZ+Y48d-_ovFw@mail.gmail.com>

echo | openssl s_client -connect apt.opensips.org:443 -servername
apt.opensips.org 2>/dev/null | openssl x509 -noout -dates -issuer -subject
notBefore=Jan 31 09:22:33 2025 GMT
notAfter=May  1 09:22:32 2025 GMT
issuer=C=US, O=Let's Encrypt, CN=R11
subject=CN=apt.opensips.org

Expired earlier today… 🙂

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

From bogdan at opensips.org  Fri May  2 06:37:48 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Fri, 2 May 2025 09:37:48 +0300
Subject: [OpenSIPS-Users] apt repo SSL cert expired
In-Reply-To: <CAEWH9M-yMkEz-Mdh2+YU7aKKYr==33qYdKEAqdZ+Y48d-_ovFw@mail.gmail.com>
References: <CAEWH9M-yMkEz-Mdh2+YU7aKKYr==33qYdKEAqdZ+Y48d-_ovFw@mail.gmail.com>
Message-ID: <3e6df22e-3ab8-4a44-a7fe-a24621b6f43c@opensips.org>

Hi Pete,

Thanks for the heads up, let us fix it asap.

Regards,

Bogdan-Andrei Iancu

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

On 01.05.2025 23:24, Pete Kelly wrote:
> echo | openssl s_client -connect apt.opensips.org:443 
> <http://apt.opensips.org:443> -servername apt.opensips.org 
> <http://apt.opensips.org> 2>/dev/null | openssl x509 -noout -dates 
> -issuer -subject
> notBefore=Jan 31 09:22:33 2025 GMT
> notAfter=May  1 09:22:32 2025 GMT
> issuer=C=US, O=Let's Encrypt, CN=R11
> subject=CN=apt.opensips.org <http://apt.opensips.org>
>
> Expired earlier today… 🙂
>
> 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/20250502/788f8882/attachment.html>

From pkelly at gmail.com  Fri May  2 08:30:41 2025
From: pkelly at gmail.com (Pete Kelly)
Date: Fri, 2 May 2025 04:30:41 -0400
Subject: [OpenSIPS-Users] apt repo SSL cert expired
In-Reply-To: <3e6df22e-3ab8-4a44-a7fe-a24621b6f43c@opensips.org>
References: <CAEWH9M-yMkEz-Mdh2+YU7aKKYr==33qYdKEAqdZ+Y48d-_ovFw@mail.gmail.com>
 <3e6df22e-3ab8-4a44-a7fe-a24621b6f43c@opensips.org>
Message-ID: <CAEWH9M8RdVzwZim_P0SS0Sr0X8h2=S8SpiW2Bf_czdcHAkO0EQ@mail.gmail.com>

 Thank you 🙂

Pete

On 2 May 2025 at 07:37:48, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:

> Hi Pete,
>
> Thanks for the heads up, let us fix it asap.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 01.05.2025 23:24, Pete Kelly wrote:
>
> echo | openssl s_client -connect apt.opensips.org:443 -servername
> apt.opensips.org 2>/dev/null | openssl x509 -noout -dates -issuer -subject
> notBefore=Jan 31 09:22:33 2025 GMT
> notAfter=May  1 09:22:32 2025 GMT
> issuer=C=US, O=Let's Encrypt, CN=R11
> subject=CN=apt.opensips.org
>
> Expired earlier today… 🙂
>
> Pete
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250502/98a59ff5/attachment.html>

From razvan at opensips.org  Fri May  2 09:05:32 2025
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Fri, 2 May 2025 12:05:32 +0300
Subject: [OpenSIPS-Users] apt repo SSL cert expired
In-Reply-To: <CAEWH9M8RdVzwZim_P0SS0Sr0X8h2=S8SpiW2Bf_czdcHAkO0EQ@mail.gmail.com>
References: <CAEWH9M-yMkEz-Mdh2+YU7aKKYr==33qYdKEAqdZ+Y48d-_ovFw@mail.gmail.com>
 <3e6df22e-3ab8-4a44-a7fe-a24621b6f43c@opensips.org>
 <CAEWH9M8RdVzwZim_P0SS0Sr0X8h2=S8SpiW2Bf_czdcHAkO0EQ@mail.gmail.com>
Message-ID: <7c2ed047-f8ea-47d3-81d1-555f4c095a36@opensips.org>

Hi, Pete!

Should be up now.

Best regards,

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

On 5/2/25 11:30 AM, Pete Kelly wrote:
>   Thank you 🙂
> 
> Pete
> 
> On 2 May 2025 at 07:37:48, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> 
>> Hi Pete,
>>
>> Thanks for the heads up, let us fix it asap.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>    https://www.opensips-solutions.com
>>    https://www.siphub.com
>>
>> On 01.05.2025 23:24, Pete Kelly wrote:
>>
>> echo | openssl s_client -connect apt.opensips.org:443 -servername
>> apt.opensips.org 2>/dev/null | openssl x509 -noout -dates -issuer -subject
>> notBefore=Jan 31 09:22:33 2025 GMT
>> notAfter=May  1 09:22:32 2025 GMT
>> issuer=C=US, O=Let's Encrypt, CN=R11
>> subject=CN=apt.opensips.org
>>
>> Expired earlier today… 🙂
>>
>> Pete
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> Thank you 🙂
>>
>> Pete
>>
>> On 2 May 2025 at 07:37:48, Bogdan-Andrei Iancu <bogdan at opensips.org 
>> <mailto:bogdan at opensips.org>> wrote:
>>> Hi Pete,
>>>
>>> Thanks for the heads up, let us fix it asap.
>>>
>>> Regards,
>>> Bogdan-Andrei Iancu
>>>
>>> OpenSIPS Founder and Developer
>>>    https://www.opensips-solutions.com
>>>    https://www.siphub.com
>>> On 01.05.2025 23:24, Pete Kelly wrote:
>>>> echo | openssl s_client -connect apt.opensips.org:443 <http:// 
>>>> apt.opensips.org:443> -servername apt.opensips.org <http:// 
>>>> apt.opensips.org> 2>/dev/null | openssl x509 -noout -dates -issuer - 
>>>> subject
>>>> notBefore=Jan 31 09:22:33 2025 GMT
>>>> notAfter=May  1 09:22:32 2025 GMT
>>>> issuer=C=US, O=Let's Encrypt, CN=R11
>>>> subject=CN=apt.opensips.org <http://apt.opensips.org>
>>>>
>>>> Expired earlier today… 🙂
>>>>
>>>> Pete
>>>>
>>>> _______________________________________________
>>>> 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 pkelly at gmail.com  Fri May  2 10:49:06 2025
From: pkelly at gmail.com (Pete Kelly)
Date: Fri, 2 May 2025 11:49:06 +0100
Subject: [OpenSIPS-Users] apt repo SSL cert expired
In-Reply-To: <7c2ed047-f8ea-47d3-81d1-555f4c095a36@opensips.org>
References: <CAEWH9M-yMkEz-Mdh2+YU7aKKYr==33qYdKEAqdZ+Y48d-_ovFw@mail.gmail.com>
 <3e6df22e-3ab8-4a44-a7fe-a24621b6f43c@opensips.org>
 <CAEWH9M8RdVzwZim_P0SS0Sr0X8h2=S8SpiW2Bf_czdcHAkO0EQ@mail.gmail.com>
 <7c2ed047-f8ea-47d3-81d1-555f4c095a36@opensips.org>
Message-ID: <CAEWH9M873ybytTO4HSRxR_T2H2ATOVN-EVFfRjF-=5NuB0NoAA@mail.gmail.com>

Thank you!

Pete

Sent from Gmail Mobile


On Fri, 2 May 2025 at 10:08, Răzvan Crainea <razvan at opensips.org> wrote:

> Hi, Pete!
>
> Should be up now.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer / SIPhub CTO
> http://www.opensips-solutions.com / https://www.siphub.com
>
> On 5/2/25 11:30 AM, Pete Kelly wrote:
> >   Thank you 🙂
> >
> > Pete
> >
> > On 2 May 2025 at 07:37:48, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
> >
> >> Hi Pete,
> >>
> >> Thanks for the heads up, let us fix it asap.
> >>
> >> Regards,
> >>
> >> Bogdan-Andrei Iancu
> >>
> >> OpenSIPS Founder and Developer
> >>    https://www.opensips-solutions.com
> >>    https://www.siphub.com
> >>
> >> On 01.05.2025 23:24, Pete Kelly wrote:
> >>
> >> echo | openssl s_client -connect apt.opensips.org:443 -servername
> >> apt.opensips.org 2>/dev/null | openssl x509 -noout -dates -issuer
> -subject
> >> notBefore=Jan 31 09:22:33 2025 GMT
> >> notAfter=May  1 09:22:32 2025 GMT
> >> issuer=C=US, O=Let's Encrypt, CN=R11
> >> subject=CN=apt.opensips.org
> >>
> >> Expired earlier today… 🙂
> >>
> >> Pete
> >>
> >> _______________________________________________
> >> Users mailing listUsers at lists.opensips.orghttp://
> lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >>
> >>
> >>
> >> Thank you 🙂
> >>
> >> Pete
> >>
> >> On 2 May 2025 at 07:37:48, Bogdan-Andrei Iancu <bogdan at opensips.org
> >> <mailto:bogdan at opensips.org>> wrote:
> >>> Hi Pete,
> >>>
> >>> Thanks for the heads up, let us fix it asap.
> >>>
> >>> Regards,
> >>> Bogdan-Andrei Iancu
> >>>
> >>> OpenSIPS Founder and Developer
> >>>    https://www.opensips-solutions.com
> >>>    https://www.siphub.com
> >>> On 01.05.2025 23:24, Pete Kelly wrote:
> >>>> echo | openssl s_client -connect apt.opensips.org:443 <http://
> >>>> apt.opensips.org:443> -servername apt.opensips.org <http://
> >>>> apt.opensips.org> 2>/dev/null | openssl x509 -noout -dates -issuer -
> >>>> subject
> >>>> notBefore=Jan 31 09:22:33 2025 GMT
> >>>> notAfter=May  1 09:22:32 2025 GMT
> >>>> issuer=C=US, O=Let's Encrypt, CN=R11
> >>>> subject=CN=apt.opensips.org <http://apt.opensips.org>
> >>>>
> >>>> Expired earlier today… 🙂
> >>>>
> >>>> Pete
> >>>>
> >>>> _______________________________________________
> >>>> 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/20250502/386d7c19/attachment-0001.html>

From medeanwz at gmail.com  Sat May  3 09:27:08 2025
From: medeanwz at gmail.com (M S)
Date: Sat, 3 May 2025 11:27:08 +0200
Subject: [OpenSIPS-Users] dp_translate performance
Message-ID: <CAEZrhoPNvGPFRydA2s=Vg0HcwQ=pYWEfHCarnoA-8v8RajHpFg@mail.gmail.com>

Hi guys,
Has anybody done any performance metrics for dp_translate? For example, to
check 1,000,000 numbers with dp_translate, how much delay is added?
How better is it to use a
for(i=0 to 1000000) {
  if($sql_cached_value(c_features:disabled:$fU)<>NULL
|| $sql_cached_value(c_features:disabled:$rU)) {
      send_reply(503);
  }
}

instead of just a:

if(dp_translate($fU) || dp_translate($rU)) {
  send_reply(503);
}

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250503/443447b7/attachment.html>

From bullehs at gmail.com  Sun May  4 21:26:51 2025
From: bullehs at gmail.com (HS)
Date: Mon, 5 May 2025 02:26:51 +0500
Subject: [OpenSIPS-Users] CGRates MaxUsage Disconnection
Message-ID: <CA+PgBoYaAUfuP2ytzGezoYPdmsg_QSzkF4Xs1T1nzLBX++avLw@mail.gmail.com>

Hi all,

I was wondering if anyone has any experience with CGRateS. I'm trying to
disconnect calls after MaxUsage expiry. All the examples I found show the
following snippet is enough and should work automagically to disconnect the
call, but doesn't seem to work for me.

Appreciate the help.

#### CGRateS module
loadmodule "dialog.so"
loadmodule "cgrates.so"
modparam("cgrates", "cgrates_engine", "127.0.0.1:2014")

route [resume_cgr_auth] {
$var(rc) = $rc;
# with GetMaxUsage == false, cgrates_auth() returns -2 on success
if ($var(rc) < 0 && ($cgr_ret(MaxUsage) != 0 || $var(rc) != -2)) {
xlog("L_NOTICE", "[$ci] CGRateS auth failed: rc=$var(rc), code=$cgr_ret\n");
send_reply(403, "Forbidden");
exit;
}

# Set the returned attributes from CGRateS as script pseudovariables
$var(idx) = 0;
while ($(cgr_ret(AttributesDigest){s.select,$var(idx),,}) != NULL) {
$avp($(cgr_ret(AttributesDigest){s.select,$var(idx),,}{s.select,0,:}))
= $(cgr_ret(AttributesDigest){s.select,$var(idx),,}{s.select,1,:});
$var(idx) = $var(idx) + 1;
}

# Enable CDRs being sent to CGRateS
cgrates_acc("cdr|missed", "$fU", "$rU");

if ( $cgr_ret(RoutesDigest)==NULL ) { # no routing requested
route(relay);
}

xlog("L_INFO", "[$ci] CGRateS auth OK, with routes:
<$cgr_ret(RoutesDigest)>\n");
$avp(carriers) := $cgr_ret(RoutesDigest);
$avp(carriers_idx) := 0;

route( to_carriers );
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250505/721cf397/attachment.html>

From liviu at opensips.org  Mon May  5 12:44:52 2025
From: liviu at opensips.org (Liviu Chircu)
Date: Mon, 5 May 2025 15:44:52 +0300
Subject: [OpenSIPS-Users] dp_translate performance
In-Reply-To: <CAEZrhoPNvGPFRydA2s=Vg0HcwQ=pYWEfHCarnoA-8v8RajHpFg@mail.gmail.com>
References: <CAEZrhoPNvGPFRydA2s=Vg0HcwQ=pYWEfHCarnoA-8v8RajHpFg@mail.gmail.com>
Message-ID: <8930eb42-642b-cd7c-dae5-948c7fd93c18@opensips.org>

Hi!

Fun question -- and a perfect use-case for the benchmark 
<https://opensips.org/docs/modules/3.6.x/benchmark.html> module, 
allowing you to find the precise answer to this question and also share 
it with us!

While the dialplan uses a hash table to store its string-based rules, 
unfortunately it seems to be hardcoded to *16* (???).  Which means on 1M 
records, you will get 62K on each bucket on average.  Now, imagine doing 
->next, ->next, ->next, etc. 62K times on each number lookup...  So I 
think performance will be decent since C lang is fast, but far from 
ideal.  The hash size should be /configurable/ /- /an excellent feature 
request for people getting into OpenSIPS development.

OTOH, the sql_cacher uses cachedb_local to store/pull its keys, which 
has a much wider hash size (IIRC, *1024* buckets).  So I think it will 
be visibly faster than dialplan when doing 1M lookups over 1M records.

Best regards,

On 03.05.2025 12:27, M S wrote:
> How better is it to use a
> for(i=0 to 1000000) {
>   if($sql_cached_value(c_features:disabled:$fU)<>NULL 
> || $sql_cached_value(c_features:disabled:$rU)) {
>       send_reply(503);
>   }
> }
>
> instead of just a:
>
> if(dp_translate($fU) || dp_translate($rU)) {
>   send_reply(503);
> }

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

From bullehs at gmail.com  Mon May  5 12:49:30 2025
From: bullehs at gmail.com (HS)
Date: Mon, 5 May 2025 17:49:30 +0500
Subject: [OpenSIPS-Users] CGRates MaxUsage Disconnection
In-Reply-To: <CA+PgBoYaAUfuP2ytzGezoYPdmsg_QSzkF4Xs1T1nzLBX++avLw@mail.gmail.com>
References: <CA+PgBoYaAUfuP2ytzGezoYPdmsg_QSzkF4Xs1T1nzLBX++avLw@mail.gmail.com>
Message-ID: <CA+PgBoY5NPWFoj6dOhght2JSwbquDU1vpLrbF-dgLyxjy=+ucA@mail.gmail.com>

Apologies,

I am using Opensips 3.0, and seem to have managed disconnecting calls by
adding:

        create_dialog("B");

Is that the correct way?

Thx.

On Mon, May 5, 2025 at 2:26 AM HS <bullehs at gmail.com> wrote:

> Hi all,
>
> I was wondering if anyone has any experience with CGRateS. I'm trying to
> disconnect calls after MaxUsage expiry. All the examples I found show the
> following snippet is enough and should work automagically to disconnect the
> call, but doesn't seem to work for me.
>
> Appreciate the help.
>
> #### CGRateS module
> loadmodule "dialog.so"
> loadmodule "cgrates.so"
> modparam("cgrates", "cgrates_engine", "127.0.0.1:2014")
>
> route [resume_cgr_auth] {
> $var(rc) = $rc;
> # with GetMaxUsage == false, cgrates_auth() returns -2 on success
> if ($var(rc) < 0 && ($cgr_ret(MaxUsage) != 0 || $var(rc) != -2)) {
> xlog("L_NOTICE", "[$ci] CGRateS auth failed: rc=$var(rc),
> code=$cgr_ret\n");
> send_reply(403, "Forbidden");
> exit;
> }
>
> # Set the returned attributes from CGRateS as script pseudovariables
> $var(idx) = 0;
> while ($(cgr_ret(AttributesDigest){s.select,$var(idx),,}) != NULL) {
> $avp($(cgr_ret(AttributesDigest){s.select,$var(idx),,}{s.select,0,:}))
> = $(cgr_ret(AttributesDigest){s.select,$var(idx),,}{s.select,1,:});
> $var(idx) = $var(idx) + 1;
> }
>
> # Enable CDRs being sent to CGRateS
> cgrates_acc("cdr|missed", "$fU", "$rU");
>
> if ( $cgr_ret(RoutesDigest)==NULL ) { # no routing requested
> route(relay);
> }
>
> xlog("L_INFO", "[$ci] CGRateS auth OK, with routes:
> <$cgr_ret(RoutesDigest)>\n");
> $avp(carriers) := $cgr_ret(RoutesDigest);
> $avp(carriers_idx) := 0;
>
> route( to_carriers );
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250505/55240ca1/attachment.html>

From bogdan at opensips.org  Mon May  5 13:04:20 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 5 May 2025 16:04:20 +0300
Subject: [OpenSIPS-Users] dp_translate performance
In-Reply-To: <CAEZrhoPNvGPFRydA2s=Vg0HcwQ=pYWEfHCarnoA-8v8RajHpFg@mail.gmail.com>
References: <CAEZrhoPNvGPFRydA2s=Vg0HcwQ=pYWEfHCarnoA-8v8RajHpFg@mail.gmail.com>
Message-ID: <e3e50e20-a9ca-4eef-b4a3-8a787338599b@opensips.org>

Hi,

It depends on what you are trying to do. IF you just want to do a 
DID/number matching (prefix or full len), better use the drouting module 
or, new in 3.6, the trie module. They are using search trees and the 
search speed does not depend on the overall number you have stored, but 
on the number len only.

Regards,

Bogdan-Andrei Iancu

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

On 03.05.2025 12:27, M S wrote:
> Hi guys,
> Has anybody done any performance metrics for dp_translate? For 
> example, to check 1,000,000 numbers with dp_translate, how much delay 
> is added?
> How better is it to use a
> for(i=0 to 1000000) {
> if($sql_cached_value(c_features:disabled:$fU)<>NULL 
> || $sql_cached_value(c_features:disabled:$rU)) {
>       send_reply(503);
>   }
> }
>
> instead of just a:
>
> if(dp_translate($fU) || dp_translate($rU)) {
>   send_reply(503);
> }
>
> Thanks!
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From bullehs at gmail.com  Wed May  7 15:22:17 2025
From: bullehs at gmail.com (HS)
Date: Wed, 7 May 2025 20:22:17 +0500
Subject: [OpenSIPS-Users] CGrates.so hang after auth - Opensips 3.0
Message-ID: <CA+PgBoawjkE_CjztfAd+7oKavee1i-QrOrF_tVUddv2aj9EZ+w@mail.gmail.com>

Hi all,

I've been having the exact same issue identified here:
https://github.com/OpenSIPS/opensips/issues/2271

I have made the changes in the 2 commits on the ticket in the cgrates_acc.c
file. But still have the same issue.

Any tips/workarounds pls? Really can't upgrade to the newer Opensips
versions.

Thanks for the help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250507/bec0deb3/attachment.html>

From bogdan at opensips.org  Thu May  8 06:04:27 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Thu, 8 May 2025 09:04:27 +0300
Subject: [OpenSIPS-Users] CGrates.so hang after auth - Opensips 3.0
In-Reply-To: <CA+PgBoawjkE_CjztfAd+7oKavee1i-QrOrF_tVUddv2aj9EZ+w@mail.gmail.com>
References: <CA+PgBoawjkE_CjztfAd+7oKavee1i-QrOrF_tVUddv2aj9EZ+w@mail.gmail.com>
Message-ID: <c5705d5e-1c1d-40ac-bdd4-9765a361a3ec@opensips.org>

Hi,

Please just open a new ticket with all the relevant information and we 
can guide you further with the troubleshooting.

Regards,

Bogdan-Andrei Iancu

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

On 07.05.2025 18:22, HS wrote:
> Hi all,
>
> I've been having the exact same issue identified here:
> https://github.com/OpenSIPS/opensips/issues/2271
>
> I have made the changes in the 2 commits on the ticket in the 
> cgrates_acc.c file. But still have the same issue.
>
> Any tips/workarounds pls? Really can't upgrade to the newer Opensips 
> versions.
>
> Thanks for the help.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



From apsaras at microbase.gr  Thu May  8 12:47:00 2025
From: apsaras at microbase.gr (Antonios Psaras)
Date: Thu, 8 May 2025 15:47:00 +0300
Subject: [OpenSIPS-Users] CallID shorting
Message-ID: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr>

Dear Team

 

We have a setup with multiple SBCs in line like

 

Access SBC -> Routing SBC -> Core SBC -> Interconnect SBC

 

On each level we apply topology hiding so the callid keeps increasing in length ending up with 200+ characters which is not manageable by all upstreams carriers. Some of those asking for max 40 char length callid.

 

Is there a way to keep topology hiding to all SBCs and decrease / minimize / control the callid length?

 

Best regards

 

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

From Johan at democon.be  Thu May  8 13:34:56 2025
From: Johan at democon.be (Johan De Clercq)
Date: Thu, 8 May 2025 15:34:56 +0200
Subject: [OpenSIPS-Users] CallID shorting
In-Reply-To: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr>
References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr>
Message-ID: <CAEVWGm9wQx=sFpKDT7gQwtHBhb8T2qPs6R_a9H1RLG_nt_uBpw@mail.gmail.com>

my 2 cents (at least that's what I do), use topology-hiding on acces and
interco.
doing it also on core and routing just makes your life overly complicated.

Br, Johan.

Op do 8 mei 2025 om 14:50 schreef Antonios Psaras <apsaras at microbase.gr>:

> Dear Team
>
>
>
> We have a setup with multiple SBCs in line like
>
>
>
> Access SBC -> Routing SBC -> Core SBC -> Interconnect SBC
>
>
>
> On each level we apply topology hiding so the callid keeps increasing in
> length ending up with 200+ characters which is not manageable by all
> upstreams carriers. Some of those asking for max 40 char length callid.
>
>
>
> Is there a way to keep topology hiding to all SBCs and decrease / minimize
> / control the callid length?
>
>
>
> Best regards
>
>
> _______________________________________________
> 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/20250508/8e8d1fd3/attachment.html>

From david.villasmil.work at gmail.com  Thu May  8 14:05:46 2025
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 8 May 2025 16:05:46 +0200
Subject: [OpenSIPS-Users] CallID shorting
In-Reply-To: <CAEVWGm9wQx=sFpKDT7gQwtHBhb8T2qPs6R_a9H1RLG_nt_uBpw@mail.gmail.com>
References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr>
 <CAEVWGm9wQx=sFpKDT7gQwtHBhb8T2qPs6R_a9H1RLG_nt_uBpw@mail.gmail.com>
Message-ID: <CAFGRPVq6=VROmLSd0Y=qH7MJYZdTzvFkC8nsP7cCeQmVh6oVWw@mail.gmail.com>

+1

Regards,

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



On Thu, May 8, 2025 at 3:38 PM Johan De Clercq <Johan at democon.be> wrote:

> my 2 cents (at least that's what I do), use topology-hiding on acces and
> interco.
> doing it also on core and routing just makes your life overly complicated.
>
> Br, Johan.
>
> Op do 8 mei 2025 om 14:50 schreef Antonios Psaras <apsaras at microbase.gr>:
>
>> Dear Team
>>
>>
>>
>> We have a setup with multiple SBCs in line like
>>
>>
>>
>> Access SBC -> Routing SBC -> Core SBC -> Interconnect SBC
>>
>>
>>
>> On each level we apply topology hiding so the callid keeps increasing in
>> length ending up with 200+ characters which is not manageable by all
>> upstreams carriers. Some of those asking for max 40 char length callid.
>>
>>
>>
>> Is there a way to keep topology hiding to all SBCs and decrease /
>> minimize / control the callid length?
>>
>>
>>
>> Best regards
>>
>>
>> _______________________________________________
>> 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/20250508/36efb537/attachment-0001.html>

From apsaras at microbase.gr  Thu May  8 14:14:33 2025
From: apsaras at microbase.gr (Antonios Psaras)
Date: Thu, 8 May 2025 17:14:33 +0300
Subject: [OpenSIPS-Users] CallID shorting
In-Reply-To: <CAEVWGm9wQx=sFpKDT7gQwtHBhb8T2qPs6R_a9H1RLG_nt_uBpw@mail.gmail.com>
References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr>
 <CAEVWGm9wQx=sFpKDT7gQwtHBhb8T2qPs6R_a9H1RLG_nt_uBpw@mail.gmail.com>
Message-ID: <3b5401dbc023$85cc7900$91656b00$@microbase.gr>

Hello Johan.

 

Thank you for your reply. That was my first thought as well. But in all steps I have cases with 3rd party systems connected so I need to have topology hiding at all steps or I must enable topology hiding per gateway which was my next thought but in that case reconciliation / cooking / billing will get complex.

 

In any case, if there is no other way to go I will consider it.

 

My opinion is that OpenSIPs should keep the information required internally in dialog level and generate a new fixed length callid which can be configurable to have specific length, prefix and suffix. 

 

But again… if there is any other option which can be implemented as is, I will be happy to consider.

 

Regards

 

 

From: Johan De Clercq <Johan at democon.be> 
Sent: Πέμπτη, 8 Μαΐου 2025 16:35
To: apsaras at microbase.gr; OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] CallID shorting

 

my 2 cents (at least that's what I do), use topology-hiding on acces and interco. 

doing it also on core and routing just makes your life overly complicated. 

 

Br, Johan. 

 

Op do 8 mei 2025 om 14:50 schreef Antonios Psaras <apsaras at microbase.gr <mailto:apsaras at microbase.gr> >:

Dear Team

 

We have a setup with multiple SBCs in line like

 

Access SBC -> Routing SBC -> Core SBC -> Interconnect SBC

 

On each level we apply topology hiding so the callid keeps increasing in length ending up with 200+ characters which is not manageable by all upstreams carriers. Some of those asking for max 40 char length callid.

 

Is there a way to keep topology hiding to all SBCs and decrease / minimize / control the callid length?

 

Best regards

 

_______________________________________________
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/20250508/867b2df6/attachment.html>

From david.villasmil.work at gmail.com  Thu May  8 15:33:01 2025
From: david.villasmil.work at gmail.com (David Villasmil)
Date: Thu, 8 May 2025 17:33:01 +0200
Subject: [OpenSIPS-Users] CallID shorting
In-Reply-To: <3b5401dbc023$85cc7900$91656b00$@microbase.gr>
References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr>
 <CAEVWGm9wQx=sFpKDT7gQwtHBhb8T2qPs6R_a9H1RLG_nt_uBpw@mail.gmail.com>
 <3b5401dbc023$85cc7900$91656b00$@microbase.gr>
Message-ID: <CAFGRPVq1dmxQu=ut8zBYyLDqmwZ5zquc=YaKLtsP+0TnV-CqEA@mail.gmail.com>

But when forwarding internally, don’t do topology hiding

Regards,

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



On Thu, May 8, 2025 at 4:17 PM Antonios Psaras <apsaras at microbase.gr> wrote:

> Hello Johan.
>
>
>
> Thank you for your reply. That was my first thought as well. But in all
> steps I have cases with 3rd party systems connected so I need to have
> topology hiding at all steps or I must enable topology hiding per gateway
> which was my next thought but in that case reconciliation / cooking /
> billing will get complex.
>
>
>
> In any case, if there is no other way to go I will consider it.
>
>
>
> My opinion is that OpenSIPs should keep the information required
> internally in dialog level and generate a new fixed length callid which can
> be configurable to have specific length, prefix and suffix.
>
>
>
> But again… if there is any other option which can be implemented as is, I
> will be happy to consider.
>
>
>
> Regards
>
>
>
>
>
> *From:* Johan De Clercq <Johan at democon.be>
> *Sent:* Πέμπτη, 8 Μαΐου 2025 16:35
> *To:* apsaras at microbase.gr; OpenSIPS users mailling list <
> users at lists.opensips.org>
> *Subject:* Re: [OpenSIPS-Users] CallID shorting
>
>
>
> my 2 cents (at least that's what I do), use topology-hiding on acces and
> interco.
>
> doing it also on core and routing just makes your life overly complicated.
>
>
>
> Br, Johan.
>
>
>
> Op do 8 mei 2025 om 14:50 schreef Antonios Psaras <apsaras at microbase.gr>:
>
> Dear Team
>
>
>
> We have a setup with multiple SBCs in line like
>
>
>
> Access SBC -> Routing SBC -> Core SBC -> Interconnect SBC
>
>
>
> On each level we apply topology hiding so the callid keeps increasing in
> length ending up with 200+ characters which is not manageable by all
> upstreams carriers. Some of those asking for max 40 char length callid.
>
>
>
> Is there a way to keep topology hiding to all SBCs and decrease / minimize
> / control the callid length?
>
>
>
> Best regards
>
>
>
> _______________________________________________
> 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/20250508/e98af891/attachment-0001.html>

From slackway2me at gmail.com  Fri May  9 06:54:04 2025
From: slackway2me at gmail.com (Alexey)
Date: Fri, 9 May 2025 11:54:04 +0500
Subject: [OpenSIPS-Users] CallID shorting
In-Reply-To: <CAFGRPVq1dmxQu=ut8zBYyLDqmwZ5zquc=YaKLtsP+0TnV-CqEA@mail.gmail.com>
References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr>
 <CAEVWGm9wQx=sFpKDT7gQwtHBhb8T2qPs6R_a9H1RLG_nt_uBpw@mail.gmail.com>
 <3b5401dbc023$85cc7900$91656b00$@microbase.gr>
 <CAFGRPVq1dmxQu=ut8zBYyLDqmwZ5zquc=YaKLtsP+0TnV-CqEA@mail.gmail.com>
Message-ID: <CAPc6LUFR=1W8x+yAOatbsW7K_5-s6DMc9noxjEOZr40rpXKUnw@mail.gmail.com>

Hi all,

maybe I'm mistaken, but what if just not to use the "C"
option of the "topology_hiding()" [1] function?

If it is optional - to encode the callid header - maybe you can skip this,
and the problem will be solved?

[1] https://opensips.org/docs/modules/3.5.x/topology_hiding.html#func_topology_hiding

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


From apsaras at microbase.gr  Fri May  9 07:06:24 2025
From: apsaras at microbase.gr (Antonios Psaras)
Date: Fri, 9 May 2025 10:06:24 +0300
Subject: [OpenSIPS-Users] CallID shorting
In-Reply-To: <CAPc6LUFR=1W8x+yAOatbsW7K_5-s6DMc9noxjEOZr40rpXKUnw@mail.gmail.com>
References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr>
 <CAEVWGm9wQx=sFpKDT7gQwtHBhb8T2qPs6R_a9H1RLG_nt_uBpw@mail.gmail.com>
 <3b5401dbc023$85cc7900$91656b00$@microbase.gr>
 <CAFGRPVq1dmxQu=ut8zBYyLDqmwZ5zquc=YaKLtsP+0TnV-CqEA@mail.gmail.com>
 <CAPc6LUFR=1W8x+yAOatbsW7K_5-s6DMc9noxjEOZr40rpXKUnw@mail.gmail.com>
Message-ID: <3e0901dbc0b0$e04b7420$a0e25c60$@microbase.gr>

Hello Alexey

You are right. I did that for the moment. So I do topology hiding with C option when a communication enters my infra and then just topology hiding without C until it exit.

Thank you for pointing this.

My suggestion is still on the table. 


Antonis Psaras

-----Original Message-----
From: Users <users-bounces at lists.opensips.org> On Behalf Of Alexey
Sent: Παρασκευή, 9 Μαΐου 2025 09:54
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] CallID shorting

Hi all,

maybe I'm mistaken, but what if just not to use the "C"
option of the "topology_hiding()" [1] function?

If it is optional - to encode the callid header - maybe you can skip this, and the problem will be solved?

[1] https://opensips.org/docs/modules/3.5.x/topology_hiding.html#func_topology_hiding

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

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



From bullehs at gmail.com  Fri May  9 07:34:17 2025
From: bullehs at gmail.com (HS)
Date: Fri, 9 May 2025 12:34:17 +0500
Subject: [OpenSIPS-Users] CGrates.so hang after auth - Opensips 3.0
In-Reply-To: <c5705d5e-1c1d-40ac-bdd4-9765a361a3ec@opensips.org>
References: <CA+PgBoawjkE_CjztfAd+7oKavee1i-QrOrF_tVUddv2aj9EZ+w@mail.gmail.com>
 <c5705d5e-1c1d-40ac-bdd4-9765a361a3ec@opensips.org>
Message-ID: <CA+PgBoZXKwXhD8vpi=4-G7t17vkThjYWBdE7ZN8+cSfMsVzMQA@mail.gmail.com>

Hi Bogdan-Andrei,

Thanks. I did open a ticket:
https://github.com/OpenSIPS/opensips/issues/3641 - however, just been
closed. Possible to relook please?


On Thu, May 8, 2025 at 11:04 AM Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi,
>
> Please just open a new ticket with all the relevant information and we
> can guide you further with the troubleshooting.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    https://www.opensips-solutions.com
>    https://www.siphub.com
>
> On 07.05.2025 18:22, HS wrote:
> > Hi all,
> >
> > I've been having the exact same issue identified here:
> > https://github.com/OpenSIPS/opensips/issues/2271
> >
> > I have made the changes in the 2 commits on the ticket in the
> > cgrates_acc.c file. But still have the same issue.
> >
> > Any tips/workarounds pls? Really can't upgrade to the newer Opensips
> > versions.
> >
> > Thanks for the help.
> >
> > _______________________________________________
> > 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/20250509/d3d27ce0/attachment.html>

From slackway2me at gmail.com  Sat May 10 10:30:28 2025
From: slackway2me at gmail.com (Alexey)
Date: Sat, 10 May 2025 15:30:28 +0500
Subject: [OpenSIPS-Users] Variable in param is not a string
Message-ID: <CAPc6LUH1DGaMnDGH1U4mTbKMbBgASjxBMkqC+E1f5mD9U0BkqA@mail.gmail.com>

Hi list,
what may be wrong?

------
Logs:

ERROR:core:do_action: Failed to get fixups for command
<set_dlg_profile> in /etc/opensips/opensips.cfg, line 262
ERROR:core:get_cmd_fixups: Variable in param [2] is not a string

ERROR:core:do_action: Failed to get fixups for command
<get_profile_size> in /etc/opensips/opensips.cfg, line 263
ERROR:core:get_cmd_fixups: Variable in param [2] is not a string

------
Config/route:

262                  set_dlg_profile("numbers",$var(fnumber));
263                  get_profile_size("numbers", $var(fnumber), $var(size));

------
Config/module params:

modparam("dialog", "profiles_with_value", "numbers/b;")

------
MI command for test:

voip-astclustergw01 ~ # opensips-cli -x mi profile_get_size numbers
{
    "Profile": {
        "name": "numbers",
        "value": null,
        "count": 241,
        "shared": "no",
        "replicated": "no"
    }
}


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


From slackway2me at gmail.com  Mon May 12 08:34:53 2025
From: slackway2me at gmail.com (Alexey)
Date: Mon, 12 May 2025 13:34:53 +0500
Subject: [OpenSIPS-Users] Variable in param is not a string
Message-ID: <CAPc6LUEP53MxwY8xV+o37HTR=gCC3cFyu2kDHqiuSzvsNMsF2g@mail.gmail.com>

Added some logging to check the 'fnumber' variable value:

    xlog("L_INFO", "[$ci] fnumber: $var(fnumber)");


In some calls it is empty, in these cases I get error I think.

    info  [30f8713c-a9ae-123e-fe98-005056a97073] fnumber: <null>
    info  [2F44DBB5-2E4211F0-8E08A2C6-A7AC8E91 at 10.1.31.1] fnumber: <null>
    info  [79c4e65b089ffb570fb480821f4542eb at u.r46.ru] fnumber: 74712444444
    info  [SD44-XJwMYbQpm2on at 10.243.214.142] fnumber: 73022333333


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


From razvan at opensips.org  Tue May 13 10:07:38 2025
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Tue, 13 May 2025 13:07:38 +0300
Subject: [OpenSIPS-Users] [BLOG] SIP Sockets Management at runtime in
	OpenSIPS 3.6
Message-ID: <bcfd371f-990d-4ea4-aa92-6e1cb2570133@opensips.org>

Hi, Everyone!

Check out our latest blog[1] presenting the new dynamic Sockets 
Management module[2] in OpenSIPS that allows you to create SIP sockets 
dynamically at runtime.

[1] 
https://blog.opensips.org/2025/05/13/sip-sockets-management-at-runtime-in-opensips-3-6/
[2] https://opensips.org/docs/modules/3.6.x/sockets_mgm

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



From liviu at opensips.org  Thu May 15 13:41:28 2025
From: liviu at opensips.org (Liviu Chircu)
Date: Thu, 15 May 2025 16:41:28 +0300
Subject: [OpenSIPS-Users] [BLOG] Structured SDP Manipulation Support in
	OpenSIPS 3.6
Message-ID: <2e0df0ce-18bb-c8be-3f08-d5a42d6d2f5b@opensips.org>

Hi, all!

Please find below a quick peek into the upcoming Structured SDP 
Manipulation support in OpenSIPS 3.6:

Blog:
https://blog.opensips.org/2025/05/15/structured-real-time-sdp-manipulation-in-opensips-3-6/

Documentation (via wiki):
https://www.opensips.org/Documentation/Script-CoreVar-3-6#sdp

Enjoy!

-- 
Liviu Chircu
www.opensips-solutions.com | www.siphub.com



From greg at switchtel.co.za  Thu May 15 16:05:44 2025
From: greg at switchtel.co.za (Gregory Massel)
Date: Thu, 15 May 2025 18:05:44 +0200
Subject: [OpenSIPS-Users] rtp_relay module and SIP+RTP/WSS+SRTP example
Message-ID: <6c6343f1-b3c7-41d5-ac3b-98c84e2e7c00@switchtel.co.za>

Hello all,

If anyone is willing to share a practical example opensips.cfg that uses 
the rtp_relay module to mediate between SIP+RTP and WSS+SRTP endpoints, 
I would greatly appreciate it.

I am currently using the rtpengine module calling rtpengine_offer, 
rtpengine_answer and rtpengine_delete at different stages with different 
flags and it's working well, however, am looking to migrate the 
configuration to rtp_relay so as to facilitate re-anchoring.

The mechanism with rtp_relay is quite different as it only gets engaged 
at the outset, tracks everything and takes care of it. Ironically, in 
simplifying everything, it's confused me in terms of what I need to pass 
to it!

Thanks

Regards

Greg



From bogdan at opensips.org  Mon May 19 15:05:05 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Mon, 19 May 2025 18:05:05 +0300
Subject: [OpenSIPS-Users] [BLOG] Unified branches,
 or SIP branches before and after SIP relaying
Message-ID: <5f8aae74-681e-4693-8b94-fd08481c5281@opensips.org>


SIP forking is complex by itself - and trying to correlated branches 
before and after the SIP signalling, to attach custom data to branches 
or to do inter-branch data access, all these make script handling more 
challenging.

And OpenSIPS 3.6 took the challenge:

https://blog.opensips.org/2025/05/19/unified-branches-or-sip-branches-before-and-after-sip-relaying/

Enjoy,

-- 
Bogdan-Andrei Iancu

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



From razvan at opensips.org  Tue May 20 09:18:52 2025
From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=)
Date: Tue, 20 May 2025 12:18:52 +0300
Subject: [OpenSIPS-Users] [BLOG] Dynamic Runtime Configuration using
 OpenSIPS 3.6 - continuation
Message-ID: <55e6923d-018f-4439-9614-33a294453b31@opensips.org>

Hello, everyone!

Check out the latest blog post[1] presenting the new Config module [2], 
presenting how you can dynamically tune OpenSIPS configuration at runtime.

[1] 
https://blog.opensips.org/2025/05/16/dynamic-runtime-configuration-using-opensips-3-6-continuation/
[2] https://opensips.org/docs/modules/3.6.x/config.html

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



From bogdan at opensips.org  Wed May 21 14:57:06 2025
From: bogdan at opensips.org (Bogdan-Andrei Iancu)
Date: Wed, 21 May 2025 17:57:06 +0300
Subject: [OpenSIPS-Users] OpenSIPS 3.6.0 major release, beta version
Message-ID: <d1b02b97-c84f-4bf3-8928-556bf08a558c@opensips.org>

Hello there !!

It is that time of the year to do our iteration - one more year, one 
more evolution step, one more OpenSIPS major release.

So, we are all happy to announce the beta release of *OpenSIPS 3.6.0 
major version* - and this 3.6 version is all about /operational 
improvements/, about _Dynamic SIP sockets_ support, about the 
_Structured SDP manipulation_, about _Unified branches_, about 
_Integrated RTP relay_ and more. A special set of improvements are 
integration oriented, like the _Janus_ integration, the _AWS (SQS and 
DynamoDB)_ integration or the _REDIS Cluster_ integration.

But here is the shortest possible description 
<https://www.opensips.org/About/Version-Overview-3-6-0> of this release; 
and be aware that it's actually not so short as nothing is short about 
3.6 and what it can do !

Please keep in mind that 3.6.0 is still a beta release, targeting mid 
July to become fully stable. So, we still have some testing ahead of us :).

Many thanks to our awesome community for contributing with ideas, code, 
patches, tests and reports!

Looking for downloading it? See the tarball 
<http://opensips.org/pub/opensips/3.6.x> or the GIT repo 
<https://github.com/OpenSIPS/opensips/tree/3.6>.

Enjoy it,

-- 
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/20250521/9015ba23/attachment.html>

From greg at switchtel.co.za  Wed May 21 15:05:05 2025
From: greg at switchtel.co.za (Gregory Massel)
Date: Wed, 21 May 2025 17:05:05 +0200
Subject: [OpenSIPS-Users] Understanding aliases core parameter versus domain
	module
Message-ID: <4e288c86-463e-482f-83ea-f53c9e352afa@switchtel.co.za>

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



From spce at lard.at  Thu May 22 16:14:53 2025
From: spce at lard.at (spce at lard.at)
Date: Thu, 22 May 2025 18:14:53 +0200
Subject: [OpenSIPS-Users] SBC Routing
Message-ID: <43735145-215d-4293-a220-c2ca71f55f74@lard.at>

Dear people,

about module drouting:

Is regexp inside the dr_groups possible? The type of field "username" 
and "domain" in db-schema is "string". When trying regexp for username 
and domain (for example ".*") and calling the do_routing function 
without a parameter this is the result:

May 22 17:42:28 opensips-test /usr/sbin/opensips[11119]: 
ERROR:drouting:get_group_id: no group for user "xxx"@"xxx"

I'm asking because under 
https://www.opensips.org/Documentation/Tutorials no. 10 theres a 
tutorial where regexp is used.


Best Regards,

Malte



From brett at nemeroff.com  Thu May 22 16:39:29 2025
From: brett at nemeroff.com (Brett Nemeroff)
Date: Thu, 22 May 2025 11:39:29 -0500
Subject: [OpenSIPS-Users] SBC Routing
In-Reply-To: <43735145-215d-4293-a220-c2ca71f55f74@lard.at>
References: <43735145-215d-4293-a220-c2ca71f55f74@lard.at>
Message-ID: <CAPwC5wwLmsXQaAD0JDuMna6gUry=_wP+QsS6YWdXarptOPWyOA@mail.gmail.com>

I do not believe this is supported. I would use a different module to regex
the domain and associate that to a drouting groupid. Then pass that to your
do_routing().
-Brett


On Thu, May 22, 2025 at 11:16 AM spce at lard.at <spce at lard.at> wrote:

> Dear people,
>
> about module drouting:
>
> Is regexp inside the dr_groups possible? The type of field "username"
> and "domain" in db-schema is "string". When trying regexp for username
> and domain (for example ".*") and calling the do_routing function
> without a parameter this is the result:
>
> May 22 17:42:28 opensips-test /usr/sbin/opensips[11119]:
> ERROR:drouting:get_group_id: no group for user "xxx"@"xxx"
>
> I'm asking because under
> https://www.opensips.org/Documentation/Tutorials no. 10 theres a
> tutorial where regexp is used.
>
>
> Best Regards,
>
> Malte
>
>
> _______________________________________________
> 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/20250522/8766468f/attachment.html>

From Johan at democon.be  Thu May 22 17:12:25 2025
From: Johan at democon.be (Johan De Clercq)
Date: Thu, 22 May 2025 19:12:25 +0200
Subject: [OpenSIPS-Users] SBC Routing
In-Reply-To: <CAPwC5wwLmsXQaAD0JDuMna6gUry=_wP+QsS6YWdXarptOPWyOA@mail.gmail.com>
References: <43735145-215d-4293-a220-c2ca71f55f74@lard.at>
 <CAPwC5wwLmsXQaAD0JDuMna6gUry=_wP+QsS6YWdXarptOPWyOA@mail.gmail.com>
Message-ID: <CAEVWGm9RsTMSU44o0hyeKR4nbwM=OC9EQspiw28jOdy3X_4c+Q@mail.gmail.com>

+1

On Thu, 22 May 2025, 18:43 Brett Nemeroff, <brett at nemeroff.com> wrote:

> I do not believe this is supported. I would use a different module to
> regex the domain and associate that to a drouting groupid. Then pass that
> to your do_routing().
> -Brett
>
>
> On Thu, May 22, 2025 at 11:16 AM spce at lard.at <spce at lard.at> wrote:
>
>> Dear people,
>>
>> about module drouting:
>>
>> Is regexp inside the dr_groups possible? The type of field "username"
>> and "domain" in db-schema is "string". When trying regexp for username
>> and domain (for example ".*") and calling the do_routing function
>> without a parameter this is the result:
>>
>> May 22 17:42:28 opensips-test /usr/sbin/opensips[11119]:
>> ERROR:drouting:get_group_id: no group for user "xxx"@"xxx"
>>
>> I'm asking because under
>> https://www.opensips.org/Documentation/Tutorials no. 10 theres a
>> tutorial where regexp is used.
>>
>>
>> Best Regards,
>>
>> Malte
>>
>>
>> _______________________________________________
>> 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/20250522/12d4a494/attachment.html>

From spce at lard.at  Thu May 22 17:35:38 2025
From: spce at lard.at (spce at lard.at)
Date: Thu, 22 May 2025 19:35:38 +0200
Subject: [OpenSIPS-Users] SBC Routing
In-Reply-To: <CAEVWGm9RsTMSU44o0hyeKR4nbwM=OC9EQspiw28jOdy3X_4c+Q@mail.gmail.com>
References: <43735145-215d-4293-a220-c2ca71f55f74@lard.at>
 <CAPwC5wwLmsXQaAD0JDuMna6gUry=_wP+QsS6YWdXarptOPWyOA@mail.gmail.com>
 <CAEVWGm9RsTMSU44o0hyeKR4nbwM=OC9EQspiw28jOdy3X_4c+Q@mail.gmail.com>
Message-ID: <0a1f544b-cf8b-4dc5-8589-78076492566e@lard.at>

Hi,

thanks for your replies.

When I call do_routing with an groupid inside the routing script, the 
function then is looking inside the dr_rules table for routes sharing 
the specified groupid. For this case you don't need the dr_groups at 
all, except for single numbers from specific domains. Is this really 
intended?

Best Regards,

Malte

On 22/05/2025 19.12, Johan De Clercq wrote:
> +1
>
> On Thu, 22 May 2025, 18:43 Brett Nemeroff, <brett at nemeroff.com> wrote:
>
>     I do not believe this is supported. I would use a different module
>     to regex the domain and associate that to a drouting groupid. Then
>     pass that to your do_routing().
>     -Brett
>
>
>     On Thu, May 22, 2025 at 11:16 AM spce at lard.at <spce at lard.at> wrote:
>
>         Dear people,
>
>         about module drouting:
>
>         Is regexp inside the dr_groups possible? The type of field
>         "username"
>         and "domain" in db-schema is "string". When trying regexp for
>         username
>         and domain (for example ".*") and calling the do_routing function
>         without a parameter this is the result:
>
>         May 22 17:42:28 opensips-test /usr/sbin/opensips[11119]:
>         ERROR:drouting:get_group_id: no group for user "xxx"@"xxx"
>
>         I'm asking because under
>         https://www.opensips.org/Documentation/Tutorials no. 10 theres a
>         tutorial where regexp is used.
>
>
>         Best Regards,
>
>         Malte
>
>
>         _______________________________________________
>         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/20250522/b231cb12/attachment-0001.html>

From osas at voipembedded.com  Fri May 23 16:32:02 2025
From: osas at voipembedded.com (Ovidiu Sas)
Date: Fri, 23 May 2025 12:32:02 -0400
Subject: [OpenSIPS-Users] Domain module documentation for 3.6
Message-ID: <CAND0LkuuP=jAveAkCXVaGeqf40273G_iXct8B6NxKJEu3Kz4KA@mail.gmail.com>

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


From greg at switchtel.co.za  Tue May 27 10:15:24 2025
From: greg at switchtel.co.za (Gregory Massel)
Date: Tue, 27 May 2025 12:15:24 +0200
Subject: [OpenSIPS-Users] Potential feature request: OpenSIPS security and
 concept of tainted variables
Message-ID: <58d13f1c-da96-4b37-a536-dd54202743f0@switchtel.co.za>

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

From nzdealshelp at gmail.com  Thu May 29 07:29:20 2025
From: nzdealshelp at gmail.com (nz deals)
Date: Thu, 29 May 2025 19:29:20 +1200
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
Message-ID: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>

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

From sandro at enablesecurity.com  Thu May 29 12:28:53 2025
From: sandro at enablesecurity.com (Sandro Gauci)
Date: Thu, 29 May 2025 14:28:53 +0200
Subject: [OpenSIPS-Users] Potential feature request: OpenSIPS security
 and concept of tainted variables
In-Reply-To: <58d13f1c-da96-4b37-a536-dd54202743f0@switchtel.co.za>
References: <58d13f1c-da96-4b37-a536-dd54202743f0@switchtel.co.za>
Message-ID: <a7984a4d-f103-43c0-be49-def3d96941b5@app.fastmail.com>

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

From Ben.Newlin at genesys.com  Fri May 30 15:49:01 2025
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Fri, 30 May 2025 15:49:01 +0000
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
In-Reply-To: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>
References: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>
Message-ID: <DS7PR10MB52140D9783A974A0F09EACAB9561A@DS7PR10MB5214.namprd10.prod.outlook.com>

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

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

From nzdealshelp at gmail.com  Sat May 31 02:47:09 2025
From: nzdealshelp at gmail.com (nz deals)
Date: Sat, 31 May 2025 14:47:09 +1200
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
In-Reply-To: <DS7PR10MB52140D9783A974A0F09EACAB9561A@DS7PR10MB5214.namprd10.prod.outlook.com>
References: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>
 <DS7PR10MB52140D9783A974A0F09EACAB9561A@DS7PR10MB5214.namprd10.prod.outlook.com>
Message-ID: <CALOQYisEZSk5+fBaZC39fO69Yrt1-fVXZ7jj=VC_CCZ2pgb6dw@mail.gmail.com>

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

From voransoy at gmail.com  Sat May 31 08:07:52 2025
From: voransoy at gmail.com (Volkan Oransoy)
Date: Sat, 31 May 2025 09:07:52 +0100
Subject: [OpenSIPS-Users] ACK request uri issue
Message-ID: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>

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

From ag at ag-projects.com  Sat May 31 09:16:52 2025
From: ag at ag-projects.com (Adrian Georgescu)
Date: Sat, 31 May 2025 11:16:52 +0200
Subject: [OpenSIPS-Users] ACK request uri issue
In-Reply-To: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>
References: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>
Message-ID: <15E989C1-F11C-45A3-8C03-78225D250C91@ag-projects.com>

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



From voransoy at gmail.com  Sat May 31 09:58:13 2025
From: voransoy at gmail.com (Volkan Oransoy)
Date: Sat, 31 May 2025 10:58:13 +0100
Subject: [OpenSIPS-Users] ACK request uri issue
In-Reply-To: <15E989C1-F11C-45A3-8C03-78225D250C91@ag-projects.com>
References: <CAM_EGOEGsf_YGVXHcmcDm-1XDW-QXmgp4ktOsMq9m01ScakpsQ@mail.gmail.com>
 <15E989C1-F11C-45A3-8C03-78225D250C91@ag-projects.com>
Message-ID: <CAM_EGOHy46xMvo8PN_6c1uoPQMtogfmMPwaWGrPFpf7jZAM6Qg@mail.gmail.com>

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

From ag at ag-projects.com  Sat May 31 14:50:04 2025
From: ag at ag-projects.com (Adrian Georgescu)
Date: Sat, 31 May 2025 16:50:04 +0200
Subject: [OpenSIPS-Users] ACK request uri issue
In-Reply-To: <CAM_EGOHy46xMvo8PN_6c1uoPQMtogfmMPwaWGrPFpf7jZAM6Qg@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>
Message-ID: <34831A66-D744-4313-88E5-B5194E3813C8@ag-projects.com>

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



From Ben.Newlin at genesys.com  Sat May 31 18:03:20 2025
From: Ben.Newlin at genesys.com (Ben Newlin)
Date: Sat, 31 May 2025 18:03:20 +0000
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
In-Reply-To: <CALOQYisEZSk5+fBaZC39fO69Yrt1-fVXZ7jj=VC_CCZ2pgb6dw@mail.gmail.com>
References: <CALOQYitmdrzo4adkWd0iGGJa9ZEqj9G7mqMXNEk6pRXjMWz-iQ@mail.gmail.com>
 <DS7PR10MB52140D9783A974A0F09EACAB9561A@DS7PR10MB5214.namprd10.prod.outlook.com>
 <CALOQYisEZSk5+fBaZC39fO69Yrt1-fVXZ7jj=VC_CCZ2pgb6dw@mail.gmail.com>
Message-ID: <BN0PR10MB5208F255BFB83215EF3312159560A@BN0PR10MB5208.namprd10.prod.outlook.com>

Oh sorry I missed that in your email. I thought you were trying to avoid the failover.

Dropping the auth info on the DNS failover I don’t think is expected, since a DNS failover doesn’t trigger failure_route so you can’t add it back.

I’d recommend opening a bug for this on the Github, but maybe someone else has ideas.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of nz deals <nzdealshelp at gmail.com>
Date: Friday, May 30, 2025 at 10:49 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
 EXTERNAL EMAIL - Please use caution with links and attachments

________________________________
Thank you for your response.
The problem is, opensips sends the INVITE to secondary srv (failed over) without Authorization. It makes sense that the dns failover is not managed by opensips but atleast the same INVITE should be failover to the secondary. Why the Authorization is removed when it goes to the secondary.

Thanks

On Sat, 31 May 2025 at 03:52, Ben Newlin <Ben.Newlin at genesys.com<mailto:Ben.Newlin at genesys.com>> wrote:
The issue here is not really with the uac_auth module, as that module isn’t sending the message only updating it with the correct authentication info.

This is normal and correct behavior. When you send the message the second time using the same DNS, it will follow the same process as the first, trying A then timing out and failing over to B. Standard DNS SRV doesn’t include any behavior to try to avoid non-responding nodes.

Ultimately what you need is to know the actual IP that elicited the 401 so the next INVITE with the authentication can be sent to the same one, using $du or $dd(:$dp). Have you tried to get the remote IP in onreply_route and store it is an AVP using $si [1] or $socket_in [2]? I don’t think I’ve ever used one of these in a reply route. The documentation doesn’t specify whether it is valid and they will contain the source of the reply, not the request.

[1] - https://www.opensips.org/Documentation/Script-CoreVar-3-6#si<https://www.opensips.org/Documentation/Script-CoreVar-3-6#si>
[2] - https://www.opensips.org/Documentation/Script-CoreVar-3-6#socket_in<https://www.opensips.org/Documentation/Script-CoreVar-3-6#socket_in>

Ben Newlin

From: Users <users-bounces at lists.opensips.org<mailto:users-bounces at lists.opensips.org>> on behalf of nz deals <nzdealshelp at gmail.com<mailto:nzdealshelp at gmail.com>>
Date: Thursday, May 29, 2025 at 9:32 AM
To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
Subject: [OpenSIPS-Users] Issue with proxy failover and uac_auth()
 EXTERNAL EMAIL - Please use caution with links and attachments

________________________________
Hi All,

I'm using OpenSIPS 3.4 and managing carrier trunks via the registrant table. In the table, I'm using a proxy value like sips:mysip.xx.x

When the primary carrier A sbc SRV record becomes unreachable, OpenSIPS correctly times out INVITE and attempts to fail over to the secondary A record (via SRV).

The secondary endpoint responds with a 401 Unauthorized and includes a WWW-Authenticate header. At this point, I assume that opensips should not try on the primary carrier A SRV record otherwise it will also timeout. but it is trying to send another INVITE with Authorization to the primary. this timeout because primary A SRV record is not responding. opensips sends another INVITE to secondary and this time its without Authorization.

Is there any way to fix this or work around it? Has anyone faced a similar problem when using uac_auth() in combination with failover and the same proxy domain?

Any advice or suggestions would be greatly appreciated.



Thank you

Regards,
Jason

_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250531/e6323b93/attachment-0001.html>