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: 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: 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: References: 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 > -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 list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <3e6df22e-3ab8-4a44-a7fe-a24621b6f43c@opensips.org> Message-ID: Thank you 🙂 Pete On 2 May 2025 at 07:37:48, Bogdan-Andrei Iancu 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: 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: References: <3e6df22e-3ab8-4a44-a7fe-a24621b6f43c@opensips.org> 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 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 > > 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 >>> apt.opensips.org:443> -servername apt.opensips.org >>> 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 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: <3e6df22e-3ab8-4a44-a7fe-a24621b6f43c@opensips.org> <7c2ed047-f8ea-47d3-81d1-555f4c095a36@opensips.org> Message-ID: Thank you! Pete Sent from Gmail Mobile On Fri, 2 May 2025 at 10:08, Răzvan Crainea 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 > 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 >> > 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 >>>> apt.opensips.org:443> -servername apt.opensips.org >>>> 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 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: 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: 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: 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: 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: 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: References: Message-ID: <8930eb42-642b-cd7c-dae5-948c7fd93c18@opensips.org> Hi! Fun question -- and a perfect use-case for the benchmark 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: 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: 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: 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: References: Message-ID: 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: 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: 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 : > 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: 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: References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr> Message-ID: +1 Regards, David Villasmil email: david.villasmil.work at gmail.com On Thu, May 8, 2025 at 3:38 PM Johan De Clercq 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 : > >> 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: 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: References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr> 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 Sent: Πέμπτη, 8 Μαΐου 2025 16:35 To: apsaras at microbase.gr; OpenSIPS users mailling list 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 >: 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: 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> <3b5401dbc023$85cc7900$91656b00$@microbase.gr> Message-ID: 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 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 > *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 : > > 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: 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: References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr> <3b5401dbc023$85cc7900$91656b00$@microbase.gr> Message-ID: 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: References: <38f301dbc017$4adfbfc0$e09f3f40$@microbase.gr> <3b5401dbc023$85cc7900$91656b00$@microbase.gr> 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 On Behalf Of Alexey Sent: Παρασκευή, 9 Μαΐου 2025 09:54 To: OpenSIPS users mailling list 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: References: Message-ID: 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 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: