From voransoy at gmail.com Wed Jul 2 10:50:14 2025 From: voransoy at gmail.com (Volkan Oransoy) Date: Wed, 2 Jul 2025 11:50:14 +0100 Subject: [OpenSIPS-Users] Random auth realms Message-ID: Hi all I store user authentication data on a subscriber table with precalculated hashes for obvious reasons. Lately we are having issues with these new AI conversations services. They send requests with random realms, especially with IP addresses. What I understand, if I store the plain text password and calculate ha1 at request time, I can accept these requests even if the realm is different. But I don't want to do that. I tried to tweak auth_db, when I set `use_domain` to 0, Opensips does not add the realm to the query but still use is on ha1 challenge since the RFC requires I think. Is there a best practice to handle this issue? Best regards -- Volkan Oransoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From joao.coucelo at celfocus.com Thu Jul 3 15:13:39 2025 From: joao.coucelo at celfocus.com (=?utf-8?B?Sm/Do28gQ291Y2Vsbw==?=) Date: Thu, 3 Jul 2025 15:13:39 +0000 Subject: [OpenSIPS-Users] b2b_logic bridge with no-late-sdp unable to get bentity1->to_uri Message-ID: Hi all, I successfully run the prepaid b2b_bridge scenario from https://opensips.org/Documentation/Tutorials-B2BUA-3-2 However, I cannot use the SDP less INVITE to initiate the connection with the "callee". Hence I was trying to use the "no-late-sdp", but I get an error when the SDPless 200 OK response from the "caller" is received. On the b2b_logic_request route I simply added two extra args: b2b_bridge("caller", "callee", "", "no-late-sdp"); The SPDless Re-INVITE 200 OK is received on process_bridge_200OK(), but it fails to get the bentity1->to_uri       DBG:b2b_logic:process_bridge_200OK: Send invite to [] Proxy [] When initiating the bridge, I can confirm that the new client entity is added correctly with the to_uri       DBG:b2b_logic:b2bl_entity_new: First new entity [callee] saved in context       opensips_1 | Jul 3 13:25:55 [10] DBG:b2b_logic:b2bl_bridge: New entity, dest = [sip:+351940026774 at 172.16.254.101:5060]       opensips_1 | Jul 3 13:25:55 [10] DBG:b2b_logic:b2bl_bridge: New entity, dest = [sip:+351940026774 at 172.16.254.101:5060]       opensips_1 | Jul 3 13:25:55 [10] DBG:b2b_logic:b2bl_create_new_entity: new entity type [1] [0x7f74039c9308]->[]       opensips_1 | Jul 3 13:25:55 [10] DBG:b2b_logic:bridging_start_old_ent: Send reInvite to old entity       opensips_1 | Jul 3 13:25:55 [10] DBG:b2b_logic:b2bl_create_new_entity: new entity type [1] [0x7f74039cb620]->[] Looking at the code, it appears to me the new_br_ent[1]->dest_uri is properly filled when preparing the bridge, and so the b2bl_create_new_entity() should be filling the to_uri and the returned entity properly stored on the tuple->bridge_entities[1] However, when receiving the 200 OK, there the same tuple->bridge_entities[1] returns no to_uri..       opensips_1 | Jul 3 13:25:55 [12] DBG:core:MD5StringArray: MD5 calculated: 38b99f724da7821223927ccebf7b95d6       opensips_1 | Jul 3 13:25:55 [12] DBG:b2b_entities:generate_tag: from_tag = 38b99f724da7821223927ccebf7b95d6-0668       opensips_1 | Jul 3 13:25:55 [12] DBG:core:parse_headers_aux: flags=ffffffffffffffff       opensips_1 | Jul 3 13:25:55 [12] DBG:tm:t_uac: next_hop=<>       opensips_1 | Jul 3 13:25:55 [12] ERROR:core:parse_uri: uri too short: <> (0)       opensips_1 | Jul 3 13:25:55 [12] ERROR:tm:uri2proxy: bad_uri:       opensips_1 | Jul 3 13:25:55 [12] ERROR:b2b_entities:_client_new: while sending request with t_request       opensips_1 | Jul 3 13:25:55 [12] ERROR:b2b_logic:b2bl_new_client: Failed to create client id       opensips_1 | Jul 3 13:25:55 [12] ERROR:b2b_logic:bridging_new_client: Failed to generate new client       opensips_1 | Jul 3 13:25:55 [12] ERROR:b2b_logic:_b2b_handle_reply: Failed to process bridging 200OK for Invite If there is an issue with the code, I cannot find it. Maybe I'm simply misusing this feature. Any thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Fri Jul 4 05:06:50 2025 From: spanda at 3clogic.com (Sasmita Panda) Date: Fri, 4 Jul 2025 10:36:50 +0530 Subject: [OpenSIPS-Users] Need some inforamtion on opensips change logs . Message-ID: I am using opensips 3.4 right now . I have the DB at aws RDS . If someone logged into the DB and made some changes to the table I am not getting that information stored anywhere . If I will talk about dynamic routing only (this module only can hamper my calls ) , any changes in the table at runtime , when my service get restarted Can I get the latest table information on the logs itself ? So that I can check from the logs what changes made in the DB before restart . If this is not possible , then what is the other way to do so ? Please suggest . I am stuck on soothing here before production live . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Fri Jul 4 12:52:30 2025 From: david.villasmil.work at gmail.com (David Villasmil) Date: Fri, 4 Jul 2025 14:52:30 +0200 Subject: [OpenSIPS-Users] Need some inforamtion on opensips change logs . In-Reply-To: References: Message-ID: Hello, 1. If you suspect someone can mess up your routing tables without authorization, you have a much bigger problem that just what you’re asking about. This is the number one thing that shouldn’t happen. 2. If by some security hole in your infrastructure, it does happen, you can restore the latest backup. You should always have backups made automatically by AWS. 3. Make sure that can’t happen by implementing proper security measures like using only private RDS instead of public, narrow down security groups, use a read only user in Kamailio if possible, etc. Hope that helps Regards, David Villasmil email: david.villasmil.work at gmail.com On Fri, Jul 4, 2025 at 7:10 AM Sasmita Panda wrote: > I am using opensips 3.4 right now . I have the DB at aws RDS . > > If someone logged into the DB and made some changes to the table I am not > getting that information stored anywhere . > > If I will talk about dynamic routing only (this module only can hamper my > calls ) , any changes in the table at runtime , when my service get > restarted Can I get the latest table information on the logs itself ? So > that I can check from the logs what changes made in the DB before restart . > > If this is not possible , then what is the other way to do so ? Please > suggest . I am stuck on soothing here before production live . > > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > _______________________________________________ > 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 Fri Jul 4 12:55:49 2025 From: david.villasmil.work at gmail.com (David Villasmil) Date: Fri, 4 Jul 2025 14:55:49 +0200 Subject: [OpenSIPS-Users] Need some inforamtion on opensips change logs . In-Reply-To: References: Message-ID: One last thing: opensips is a proxy, not a tool to monitor AWS/RDS audit logs. There are other ways in AWS to do that, such as cloudtrail, cloudwatch log monitor and filters, RDS logging facilities, etc. you can raise alerts based on that. I said “Kamailio” but always meant OpenSIPS. Regards, David Villasmil email: david.villasmil.work at gmail.com On Fri, Jul 4, 2025 at 2:52 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > Hello, > > 1. If you suspect someone can mess up your routing tables without > authorization, you have a much bigger problem that just what you’re asking > about. This is the number one thing that shouldn’t happen. > 2. If by some security hole in your infrastructure, it does happen, you > can restore the latest backup. You should always have backups made > automatically by AWS. > 3. Make sure that can’t happen by implementing proper security measures > like using only private RDS instead of public, narrow down security groups, > use a read only user in Kamailio if possible, etc. > > Hope that helps > > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > > > > On Fri, Jul 4, 2025 at 7:10 AM Sasmita Panda wrote: > >> I am using opensips 3.4 right now . I have the DB at aws RDS . >> >> If someone logged into the DB and made some changes to the table I am not >> getting that information stored anywhere . >> >> If I will talk about dynamic routing only (this module only can hamper my >> calls ) , any changes in the table at runtime , when my service get >> restarted Can I get the latest table information on the logs itself ? So >> that I can check from the logs what changes made in the DB before restart . >> >> If this is not possible , then what is the other way to do so ? Please >> suggest . I am stuck on soothing here before production live . >> >> >> *Thanks & Regards* >> *Sasmita Panda* >> *Senior Network Testing and Software Engineer* >> *3CLogic , ph:07827611765* >> _______________________________________________ >> 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 mayamatakeshi at gmail.com Sun Jul 6 05:36:20 2025 From: mayamatakeshi at gmail.com (mayamatakeshi) Date: Sun, 6 Jul 2025 14:36:20 +0900 Subject: [OpenSIPS-Users] node module to help writing SIP functional/integration tests Message-ID: Over the years I have been slowly writing a node module to help me write SIP functional/integration tests: https://github.com/MayamaTakeshi/sip-lab I have been adding new features as I needed for new kinds of test but didn't have time to document it. But now I need to mentor some newcomers to the company I work for and had to do it. I asked gemini to do it for me and got: https://github.com/MayamaTakeshi/sip-lab/blob/master/DOC.md It might be of help for other people so I am sharing it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Mon Jul 7 05:53:21 2025 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 7 Jul 2025 11:23:21 +0530 Subject: [OpenSIPS-Users] Need some inforamtion on opensips change logs . In-Reply-To: <9da46058-fe3b-4e85-9215-f58d099a1ff2@voipplus.net> References: <9da46058-fe3b-4e85-9215-f58d099a1ff2@voipplus.net> Message-ID: Thanks for the information . I have the backup enabled in RDS and also the RDS is private inside my VPC and has a minimal security group to block the access . And also I used to reload the module rather than restarting opensips on every change . In-addition to this , I have created an audit table for my tables which has manual changes . So that whenever there is any change to these tables there will be an entry in the audit table . So later on I can validate the audit table if needed . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* On Fri, Jul 4, 2025 at 6:43 PM Marcin Groszek wrote: > You may reload d-routing module using cli after changes and without > restarting opensips: > opensips-cli -x mi dr_reload > > > On 7/4/25 00:06, Sasmita Panda wrote: > > I am using opensips 3.4 right now . I have the DB at aws RDS . > > If someone logged into the DB and made some changes to the table I am not > getting that information stored anywhere . > > If I will talk about dynamic routing only (this module only can hamper my > calls ) , any changes in the table at runtime , when my service get > restarted Can I get the latest table information on the logs itself ? So > that I can check from the logs what changes made in the DB before restart . > > If this is not possible , then what is the other way to do so ? Please > suggest . I am stuck on soothing here before production live . > > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > Best Regards: > Marcin Groszek > Business Voip Resource.http://www.voipplus.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Mon Jul 7 06:34:55 2025 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 7 Jul 2025 12:04:55 +0530 Subject: [OpenSIPS-Users] Need some information around opensips logging . Message-ID: HI . I am using opensips 3.4 and my application is running on eks cluster . I want opensips to do console logging and also logging to a file on syslog . Is this possible ? *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Mon Jul 7 10:30:37 2025 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 7 Jul 2025 12:30:37 +0200 Subject: [OpenSIPS-Users] Need some inforamtion on opensips change logs . In-Reply-To: References: <9da46058-fe3b-4e85-9215-f58d099a1ff2@voipplus.net> Message-ID: Hello Samsita, That's all great to read! My point was a proxy is not the right tool to do everything. There are better tools to audit your db access and manipulation. Regards, David Villasmil email: david.villasmil.work at gmail.com On Mon, Jul 7, 2025 at 7:56 AM Sasmita Panda wrote: > Thanks for the information . > > I have the backup enabled in RDS and also the RDS is private inside my VPC > and has a minimal security group to block the access . > > And also I used to reload the module rather than restarting opensips on > every change . > > In-addition to this , I have created an audit table for my tables which > has manual changes . So that whenever there is any change to these tables > there will be an entry in the audit table . > So later on I can validate the audit table if needed . > > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > > > On Fri, Jul 4, 2025 at 6:43 PM Marcin Groszek wrote: > >> You may reload d-routing module using cli after changes and without >> restarting opensips: >> opensips-cli -x mi dr_reload >> >> >> On 7/4/25 00:06, Sasmita Panda wrote: >> >> I am using opensips 3.4 right now . I have the DB at aws RDS . >> >> If someone logged into the DB and made some changes to the table I am not >> getting that information stored anywhere . >> >> If I will talk about dynamic routing only (this module only can hamper my >> calls ) , any changes in the table at runtime , when my service get >> restarted Can I get the latest table information on the logs itself ? So >> that I can check from the logs what changes made in the DB before restart . >> >> If this is not possible , then what is the other way to do so ? Please >> suggest . I am stuck on soothing here before production live . >> >> >> *Thanks & Regards* >> *Sasmita Panda* >> *Senior Network Testing and Software Engineer* >> *3CLogic , ph:07827611765* >> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> -- >> Best Regards: >> Marcin Groszek >> Business Voip Resource.http://www.voipplus.net >> >> _______________________________________________ > 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 Mon Jul 7 10:42:13 2025 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 7 Jul 2025 12:42:13 +0200 Subject: [OpenSIPS-Users] Need some information around opensips logging . In-Reply-To: References: Message-ID: Hello OpenSIPS can log to both if you have rsyslog on the container by adding to /etc/rsyslog.d/opensips.conf something like `local0.* /var/log/opensips.log` Also take a look at fluentd. You can easily use fluentd to capture the console output and log it to a local file or ship it to a logging backend. Regards, David Villasmil email: david.villasmil.work at gmail.com On Mon, Jul 7, 2025 at 8:39 AM Sasmita Panda wrote: > HI . > > I am using opensips 3.4 and my application is running on eks cluster . > I want opensips to do console logging and also logging to a file on syslog > . > Is this possible ? > > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > _______________________________________________ > 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 simon at softnet.si Mon Jul 7 14:41:25 2025 From: simon at softnet.si (Simon Gajski) Date: Mon, 7 Jul 2025 16:41:25 +0200 Subject: [OpenSIPS-Users] Additional accounting while using append_branch Message-ID: Hi to all Is there a way to add additional accounting info for each append_branch? append_branch("sip:$avp(forking_num)@1.2.3.4:5060"); I am using opensips 3.5 My problem here is that I am doing parallel forking with opensips subscriber number and mobile number. I get ringing on both numbers, calls are working fine no matter which side answers. But I would need additional info in accounting table that my subscriber sent forking call to pstn gateway. So far only first cdr is stored to my acc table of a call comming to my opensips subscriber number. Thanks for all help BR Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From joao.coucelo at celfocus.com Tue Jul 8 11:07:12 2025 From: joao.coucelo at celfocus.com (=?Windows-1252?Q?Jo=E3o_Coucelo?=) Date: Tue, 8 Jul 2025 11:07:12 +0000 Subject: [OpenSIPS-Users] cannot bridge_retry when bridge established with prov_media_uri Message-ID: Hi all, I'm validating the different supported b2b_bridge scenarios. I noticed something that I was not expecting in the b2b_bridge_retry scenario; i could not do a bridge_retry when the b2b_bridge is established with prov_media_uri. The bridge retry is done for entity 1, and in this case that is the media entity; however the retry should be done for the "callee" entity, and not for the media. I've added to my b2b_logic_reply logic to run b2b_client_new() and b2b_bridge_retry() upon a 4xx error response. This works when the b2b_bridge is established with two entites, e.g. b2b_bridge("caller", "callee"); NOTICE:b2b_logic_reply: SIP Reply Code=183, Reason=Session In Progress, Entity=callee, Key=B2B.251.4266553.1751971857.746992624, Call Context ID= NOTICE:b2b_logic_reply: SIP Reply Code=486, Reason=Busy Here, Entity=callee, Key=B2B.251.4266553.1751971857.746992624, Call Context ID= INFO:b2b_logic:b2bl_add_client: adding entity [0x7fc8f07da818]->[B2B.250.2854263.1751971857.1521299734] to tuple [0x7fc8f07caf08]->[254.0] NOTICE:b2b_logic_reply: SIP Reply Code=183, Reason=Session In Progress, Entity=, Key=B2B.250.2854263.1751971857.1521299734, Call Context ID= NOTICE:b2b_logic_reply: SIP Reply Code=200, Reason=OK, Entity=, Key=B2B.250.2854263.1751971857.1521299734, Call Context ID= However, if I add the media_url to the b2b_bridge, the b2b_logic_reply route is not able to associate the incoming 4xx error response to the callee entity. NOTICE:b2b_logic_reply: SIP Reply Code=183, Reason=Session In Progress, Entity=, Key=, Call Context ID= NOTICE:b2b_logic_reply: SIP Reply Code=486, Reason=Busy Here, Entity=, Key=, Call Context ID= If I remove the if condition that checks that the error was received for the “callee” entity and do the b2b_bridge_retry anyway, I get ERROR:b2b_logic:b2b_script_bridge_retry: The 'b2b_bridge_retry' function can only be used fornegative replies from the second entity [Picture] João Coucelo UC Specialist m: (+351) 916 312 940 celfocus.com [Picture] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Outlook-Picture.png Type: image/png Size: 16883 bytes Desc: Outlook-Picture.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Outlook-Picture.png Type: image/png Size: 2519 bytes Desc: Outlook-Picture.png URL: From Ben.Laing at dals.co.uk Wed Jul 9 10:11:48 2025 From: Ben.Laing at dals.co.uk (Ben Laing) Date: Wed, 9 Jul 2025 10:11:48 +0000 Subject: [OpenSIPS-Users] Re-homing a large number of subscribers Message-ID: Hi folks, I’m using OpenSIPs as a load balancer in an active/active setup. I’m trying to set up call re-homing when a node in the cluster goes down, largely following https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/ . I’ve got separate shtags lb1 and lb2 for each node. When the cluster down is detected, I am running a python script that sets the remaining node as active then aims to rehome the calls in progress. Currently, that works by getting dlg_list_ctx, then running dlg_send_sequential for each dialog with a shtag matching the down node (dialog[‘context’][‘values’][‘dlgX_shtag’]. That’s fine for a few calls, but fails when we get to a few hundred because the dlg_list_ctx throws an error: Jul 9 09:47:00 ip-10-4-40-11 /usr/sbin/opensips[83438]: ERROR:core:print_mi_response: Failed to print JSON Jul 9 09:47:00 ip-10-4-40-11 /usr/sbin/opensips[83438]: ERROR:mi_http:mi_json_answer_to_connection: failed to print json response Any ideas recommendations on how to tackle this? I could use dlg_list_ctx specifying an index/counter to complete in batches, but I’m not quite sure how the indexing works so there’s a worry we’d miss calls. E.g. we do calls 0-40 then 41-80 but if call 0 ends while processing 0-40, does that mean call 41 becomes call 40 so it’s missed from the 41-80 batch. Probably the best solution I have at the moment is to query the DB directly to get the definitively list of call ids, then run dlg_list_ctx specifying and iID then dlg_send_sequential if appropriate. Or just don’t bother checking and run dlg_send_sequential on them all. Any thoughts / suggestions? Best, ‑‑‑‑‑ Ben Laing He/Him Senior Software Developer Email: ben.laing at dals.co.uk Website: www.dals.co.uk Dals, Statham House, Talbot Rd, Stretford, Manchester, M32 0FP Classified - General -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Jul 9 12:14:17 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 9 Jul 2025 15:14:17 +0300 Subject: [OpenSIPS-Users] OpenSIPS 3.6.0 major release, beta version In-Reply-To: References: Message-ID: <2de159dc-2d83-479f-9a01-ae0e9845cad6@opensips.org> We have news on the topics: the date for the stable OpenSIPS 3.6 release is set for 23rd of July, stay tune! https://opensips.org/About/Version-Overview-3-6-0 Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 21.05.2025 17:57, Bogdan-Andrei Iancu wrote: > 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 > 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 > or the GIT repo > . > > Enjoy it, > -- > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > https://www.siphub.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From alidogan at plan.com Tue Jul 15 13:23:20 2025 From: alidogan at plan.com (Ali Dogan) Date: Tue, 15 Jul 2025 13:23:20 +0000 Subject: [OpenSIPS-Users] RTPEngine module triggering play media for all parties. Message-ID: Hello All, I'm trying to trigger media for every participant of the call. So, my config snippet for playing media as it's below; $var(media_args) = "file=/usr/local/etc/opensips/.mp3 "; rtpengine_play_media("call-id=$ci all", $var(media_args)); But I'm getting error logs as below; ERROR:rtpengine:rtpe_function_call: proxy replied with error: No participant party specified ERROR:rtpengine:rtpengine_playmedia_f: could not start media! I'm using opensips 3.5.2 and would love to know what is the correct syntax for this need. Best Regards, Ali Ali Dogan +44(0)3300 88 18 18 alidogan at plan.com plan.com is the trading name of Plan Communications Limited, registered in the Isle of Man with company number 010273V and Registered Office at No.5 Victoria Street, Douglas, Isle of Man, IM1 2LR. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Plan. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From slackway2me at gmail.com Wed Jul 16 06:33:47 2025 From: slackway2me at gmail.com (Alexey) Date: Wed, 16 Jul 2025 11:33:47 +0500 Subject: [OpenSIPS-Users] maximum number of branches exceeded Message-ID: Hi list, do these errors mean the same, as described here [1] ? ERROR:tm:add_uac: maximum number of branches exceeded ERROR:tm:t_forward_nonack: failure to add branches ERROR:tm:w_t_relay: t_forward_nonack failed [1] https://lists.opensips.org/pipermail/users/2024-May/048127.html Errors appear not always, only sometimes. OpenSIPS v. 3.2.18. -- best regards, Alexey https://alexeyka.zantsev.com/ From gmaruzz at gmail.com Wed Jul 16 07:38:46 2025 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Wed, 16 Jul 2025 09:38:46 +0200 Subject: [OpenSIPS-Users] maximum number of branches exceeded In-Reply-To: References: Message-ID: On Wed, Jul 16, 2025 at 8:37 AM Alexey wrote: > Hi list, > do these errors mean the same, as described here [1] ? > > ERROR:tm:add_uac: maximum number of branches exceeded > ERROR:tm:t_forward_nonack: failure to add branches > ERROR:tm:w_t_relay: t_forward_nonack failed > > [1] https://lists.opensips.org/pipermail/users/2024-May/048127.html > > OpenSIPS supports 12 branches for a call, eg: 12 times you go into a failure route and resend out the INVITE So, you probably are trying too many gateways one after another (like you have more than 12 gw in a drouting rule) or you simply retry more than 12 times to send out an INVITE, but each time you get an error back For managing more than 12 branches, you must recompile OpenSIPS after changing an include file -giovanni -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From slackway2me at gmail.com Wed Jul 16 13:38:55 2025 From: slackway2me at gmail.com (Alexey) Date: Wed, 16 Jul 2025 18:38:55 +0500 Subject: [OpenSIPS-Users] maximum number of branches exceeded In-Reply-To: References: Message-ID: Hi, Giovanni ! Thank you for the answer. I examined logs and dumps, the config file and logic is OK. There is a failure_route containing some logic to do authentication when calling out via VoIP provider (401 and/or 407 reply codes handling and constructing re-INVITEs with Authorization header). For some reason, this VoIP provider sends us 401 reply again and again, even after we have constructed and sent them our re-INVITE with Authorization header already. And after 12 attempts the ERROR in log appears. So, the problem is neither in OpenSIPS, nor in its config/logic but in VoIP provider. -- best regards, Alexey https://alexeyka.zantsev.com/ From bogdan at opensips.org Thu Jul 17 14:41:31 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Jul 2025 17:41:31 +0300 Subject: [OpenSIPS-Users] clusterer_shtag_set_INactive In-Reply-To: References: Message-ID: Hi, We avoided on purpose an unset command, as in such case it will be impossible to decide which remaining node should take over the tag - keep in mind that the fundamental idea is that a sharing tag MUST be active on some node. By allowing only setting the tag as active, we (1) are sure we have an active node all the time and (b) we are sure that only one is active (as all other will step down upon broadcast). Of course, if you have some scenarios which do not fit with this philosophy, I am open to discussions and patches. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 20.06.2025 16:01, Wadii wrote: > hello > I had a similar setup, you can avoid the split brain issue by not > hardcoding the sharing_tag active state in clusterer module config > Either set both servers to start with 'backup' state / 'none' by > removing the param entirely, then few seconds after startup via > startup_route each server checks if it actually has the VIP and only > then sets itself active if needed. > > startup_route { > launch(exec("sleep 10 && /path/check_vip.py",, $var(out), $var(err)), > vip_check_route); > } > > This way reality determines who's active, not config files > > Le ven. 20 juin 2025 à 13:48, Alexey a écrit : > > Hi list, hi Team, > > I would like to know if it is possible to add one more > MI command for the clusterer module, which will be > the opposite for the 'clusterer_shtag_set_active' command. > > E.g. 'clusterer_shtag_set_inactive'. > It could be very useful in some scenarios. > > We have an active/standby cluster based on Keepalived. > And Keepalived is configured with the ability to be switched > manually from active to standby. I mean that the keepalived.conf > on both nodes has these two not default options: > >     state BACKUP        # both must be BACKUP for nopreempt to work >     nopreempt > > And keepalived is configured to execute the script when the node > becomes active (or 'master' in keepalived terminology): > >     ... >     vrrp_instance voip { > >         notify_master "/etc/keepalived/master-backup.sh MASTER" >         notify_backup "/etc/keepalived/master-backup.sh BACKUP" >         notify_stop "/etc/keepalived/master-backup.sh STOP" >         notify_fault "/etc/keepalived/master-backup.sh FAULT" >     ... > > > And this script runs MI command: > >     ... >     /usr/bin/opensips-cli -x mi clusterer_shtag_set_active vip/1 >     ... > > Keepalived works well. > > One OpenSIPS node has the following configuration > of the clusterer module and sharing_tags: > > ... > modparam("clusterer", "sharing_tag", "vip/1=active") > ... > > > The other one - the following: > ... > modparam("clusterer", "sharing_tag", "vip/1=backup") > ... > > > So, if the state of nodes changes, we can run MI command > 'clusterer_shtag_set_active' triggered by Keepalived state change, > and we do it. > > But if the first node is rebooted, OpenSIPS starts with the > configured options - > modparam("clusterer", "sharing_tag", "vip/1=active") . > > But because of 'nopreempt' option in keepalived.conf the state > of the nodes remains unchanged (I configured it on purpose, > it's convenient for me to be able to switch nodes manually and > to decide which one will be active - I copied the behavior of > AcmePacket SBC > with these options). > > So, in some cases the situation bacomes as follows: > the second node became active (either manually or because of some > problems on the first node) and remains in active state. > > But after rebooting the first node OpenSIPS on it starts with > modparam("clusterer", "sharing_tag", "vip/1=active") parameters. > > So, since that, both nodes are sure that each of them should have > active sharing_tags. > At the same time, keepalived on the first node enters backup state, > because it sees that the second node is already in master state > (nopreempt option works). > > If such a command existed, I could use it in keepalived config/script > and run it during switching to backup, something like - > >      /usr/bin/opensips-cli -x mi clusterer_shtag_set_INactive vip/1 > > > -- > best regards, Alexey > https://alexeyka.zantsev.com/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > 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 bogdan at opensips.org Thu Jul 17 14:45:12 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Jul 2025 17:45:12 +0300 Subject: [OpenSIPS-Users] Registrant & LB with SRV In-Reply-To: <3b6401dbe41a$31755fa0$94601ee0$@microbase.gr> References: <32f101dbe1c5$1f2cd3c0$5d867b40$@microbase.gr> <3b6401dbe41a$31755fa0$94601ee0$@microbase.gr> Message-ID: <12a0980c-41aa-4ab4-b2f5-285516a420e4@opensips.org> Hi Antonios, why not, as Walter suggested, grabbing the A records behind the SRV record and register and balance explicitly to them.... Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 23.06.2025 11:38, Antonios Psaras wrote: > > Thank you Walter for your reply. > > Unfortunately there is no way to change Carrier’s configuration so we > need to find a way to tackle the issue on our side. > > Thanks again. > > Regards > > *From:* Walter Schober > *Sent:* Δευτέρα, 23 Ιουνίου 2025 10:37 > *To:* OpenSIPS users mailling list > *Cc:* apsaras at microbase.gr > *Subject:* AW: [OpenSIPS-Users] Registrant & LB with SRV > > Hello Antonis! > > IMHO the carrier cannot expect Register and Invite going to the same > destination if the SRV for _/the/_ service is load-balanced. > > We do offer such a service as carrier also but encountered the issue > with LB on nearly every device, incl. phones. Since we also need the > call to be established across the same service endpoint selected in > the Register process we set priorities on each SRV for each datacenter. > > For such cases we do additionally name two A records where the > endpoint must register on both and then can do LB calls to each. > Otherwise the carriers service must allow registers and invites going > different ways. It is **one** service based on the SRV entry! > > Br > > Walter > > *Von:*Users *Im Auftrag von > *Antonios Psaras > *Gesendet:* Freitag, 20. Juni 2025 11:24 > *An:* 'OpenSIPS users mailling list' > *Betreff:* [OpenSIPS-Users] Registrant & LB with SRV > > Hello Team > > I have the following situation. > > A telecom carrier requires SIP Registration prior to Dial out using > SIP Domain and SRV Lookup. > > To achieve that I am using registrant module and load balancing module. > > The problem I have, is that in some cases registrant registers on > different SBC of the Carrier than the one resolved by Load Balancer > Module so my outbound calls are failing with 407. > > I have two thoughts but I do not know how to implement any of those. > > 1. Instead of using LB Modules, I will some how get the registrar IP > from registrant module and statically route the calls through > that. Is there a way to get that information from registrant module? > 2. DNS lookup is done automatically only in case of 503 or timeout. > Is there a way to force DNS lookup with in OpenSIP Script? If yes > I can handle 407, force DNS Lookup, create a new branch and > re-send the call. > > Any other thoughts are welcome > > Best regards > > Antonis Psaras > > > _______________________________________________ > 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 bogdan at opensips.org Thu Jul 17 14:47:46 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Jul 2025 17:47:46 +0300 Subject: [OpenSIPS-Users] Cluster Neighbour status in script In-Reply-To: <8115da3a65c7d5e90ab312929d72f5e6c510549b.camel@webon.co.za> References: <8115da3a65c7d5e90ab312929d72f5e6c510549b.camel@webon.co.za> Message-ID: <3fa300f8-c28c-4404-bb8a-b72322597a7b@opensips.org> Hi Trevor, no nicer way than doing MI (via mi_script module) from script for the cluster_list cmd. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 26.06.2025 23:26, trevor at webon.co.za wrote: > Hi All, > > Is there a simple way to check to cluster neighbour status up/down > from script? > > I cant seem to find anything I have a workaround using > E_CLUSTERER_NODE_STATE_CHANGED and  localcache to write status into > cache just wondering if there is a cleaner way to do this from inside > script. > > Thanks > > Regards > Trevor Steyn > > _______________________________________________ > 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 bogdan at opensips.org Thu Jul 17 14:53:38 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Jul 2025 17:53:38 +0300 Subject: [OpenSIPS-Users] Topology_hiding took down my carrier's switch In-Reply-To: References: Message-ID: Hi, The only thing you can do is (1) ask the carrier for an example of such bogus dialog and (2) investigate the SIP traffic to be sure that the BYE exchange with the carrier was correctly done... Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 27.06.2025 00:57, Federico Alves wrote: > So far my engineers use topology_hiding(), and the CallID from the > client was passing forward to the carrrier. So we switched to > topology_hiding("C") and worked as expected but the carrier's switch > collapsed after a while. They say that we leave many dialogs open thar > never close. Other than that, th3 calls work fine for us. > What are my engineers doing wrong? > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Thu Jul 17 15:17:17 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Jul 2025 18:17:17 +0300 Subject: [OpenSIPS-Users] questions about WARNING:core:utimer_ticker In-Reply-To: References: Message-ID: Hi Richard, Those warning means that a certain timer is really busy, overlapping between executions - here is about the tm-utimer, responsible for performing the stateful retransmissions (upon missing replies). Such a timer may get slow due to TCP stuff, like trying to retransmit to disconnected connections. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 26.06.2025 01:24, Richard Revels via Users wrote: > > Ah, Thank You. Yes, I have come to the same conclusion that those > messages are after the problem rather than before.   I didn't take > enough time to really dig into the logs before send that message I reckon. > > > On Wed, Jun 25, 2025 at 1:20 PM Gregory Massel via Users > wrote: > > I get these on my most lightly loaded system, yet none at all on > my most heavily loaded system... > > Although the error is generic enough that, on its own, it doesn't > really help to determine what the problem is, on my system the > tm-utimer messages are often accompanied by TLS errors such as: > > ERROR:tls_wolfssl:_wolfssl_tls_conn_shutdown: no ssl data > > ERROR:tm:msg_send: send() to x.x.x.x:5061 for proto tls/3 failed > > (Note: While I'm currently using WolfSSL, I previously used > OpenSSL and experienced similar issues.) > > That's not to say that you're getting the error for the same > reason as me; just to point out that there should be related > errors before or after the tm-utimer warnings. It may be tricky to > find them on a system with your sorts of volumes as, in my case, > the TLS errors are typically just over 2 minutes AFTER the > tm-utimer warnings. On a busy system, a lot of unrelated log > entries are likely to generate in between. > > The low-load system with these issue has outbound TLS. The > high-load system without these issues does no outbound TLS; the > only TLS it handles are inbound WSS connections. > > With regard to your question about threads, take a look at: > https://www.opensips.org/Documentation/Script-CoreParameters-3-4#tcp_workers > https://www.opensips.org/Documentation/Script-CoreParameters-3-4#udp_workers > > --Greg > > On 2025-06-24 18:52, Richard Revels via Users wrote: >> Greetings, >> I have started having issues with some proxies running opensips >> 3.2.19 and some others running 3.4.12 >> With approximately 230 cps and 7300 dialogs the proxy starts >> emitting log messages like >> >> Jun 24 15:42:18 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 150 ms ago (now 3671145080 ms), delaying execution >> Jun 24 15:42:18 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 200 ms ago (now 3671145130 ms), delaying execution >> Jun 24 15:42:18 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 300 ms ago (now 3671145230 ms), delaying execution >> Jun 24 15:42:18 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 400 ms ago (now 3671145330 ms), delaying execution >> Jun 24 15:42:18 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 500 ms ago (now 3671145430 ms), delaying execution >> Jun 24 15:42:19 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 600 ms ago (now 3671145530 ms), delaying execution >> Jun 24 15:42:19 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 700 ms ago (now 3671145630 ms), delaying execution >> Jun 24 15:42:19 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 800 ms ago (now 3671145730 ms), delaying execution >> Jun 24 15:42:19 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:utimer_ticker: utimer task already >> scheduled 900 ms ago (now 3671145830 ms), delaying execution >> Jun 24 15:42:19 sip-proxy.local >> /usr/local/opensips/sbin/opensips[190328]: >> WARNING:core:timer_ticker: timer task already >> scheduled 1000 ms ago (now 3671145830 ms), delaying execution >> >> >> The cpu usage on the threads goes from 3% - 11% depending on >> thread to 30% across the board. >> >> I have been running these versions of opensips for some time now >> (months for 3.4 and years for 3.2) and do see occasional latency >> in db or rest connection responses but only recently have started >> having this issue. >> >> So, >> >> How are SIP calls distributed across the processing threads?  I >> was thinking it would be round robin w/ attention given to busy >> or not.  but it seems like the lower pid threads do a lot more >> work on these proxies >> >> What are possible causes of the timers having trouble completing >> tasks?  is it cpu use, waiting on some other task to finish, >> combination or more? >> >> Is there tuning that can be done to have more timer handling >> threads?  i tried this with modparam("tm", "timer_partitions") >> which seemed to make the problem worse >> >> Thank you in advance for any guidance you can give me on >> troubleshooting this issue. >> Richard Revels >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ > 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 bogdan at opensips.org Thu Jul 17 15:31:44 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Jul 2025 18:31:44 +0300 Subject: [OpenSIPS-Users] Random auth realms In-Reply-To: References: Message-ID: Hi Volkan, Normally, in the auth reply, you need to use the realm received in the challenge. So, if you want to be 100% RFC compliant, you should not keep the HA1, but calculate it each time, with the received realm. If you still want to use pre-computed HA1 and go around the variable realms, you may simply load the HA1 via sql_ops and feed into pv_auth function - no need for auth_db Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 02.07.2025 13:50, Volkan Oransoy wrote: > Hi all > > I store user authentication data on a subscriber table with > precalculated hashes for obvious reasons.  Lately we are having issues > with these new AI conversations services. They send requests with > random realms, especially with IP addresses. What I understand, if I > store the plain text password and calculate ha1 at request time, I can > accept these requests even if the realm is different. But I don't want > to do that. I tried to tweak auth_db, when I set `use_domain` to 0, > Opensips does not add the realm to the query but still use is on ha1 > challenge since the RFC requires I think. > Is there a best practice to handle this issue? > > Best regards > > -- > Volkan Oransoy > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Jul 17 15:44:21 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Jul 2025 18:44:21 +0300 Subject: [OpenSIPS-Users] Additional accounting while using append_branch In-Reply-To: References: Message-ID: <47a872c6-eeed-48f8-a03e-c6a70fd5946d@opensips.org> Hi Simon, This is one of the things addressed in 3.6, where you can attache various attributes to a branch, after creating it. But for older version, a quick dirty trick is to pack the info you need (per branch), do a base64 over it and added it as URI param when doing append_branch()...and you can retrieve it later in branch route, do revert base64 and unpack. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 07.07.2025 17:41, Simon Gajski via Users wrote: > > Hi to all > > Is there a way to add additional accounting info for each append_branch? > append_branch("sip:$avp(forking_num)@1.2.3.4:5060"); > I am using opensips 3.5 > > My problem here is that I am doing parallel forking with opensips > subscriber number and mobile number. > I get ringing on both numbers, calls are working fine no matter which > side answers. > > But I would need additional info in accounting table that my > subscriber sent forking call to pstn gateway. > So far only first cdr is stored to my acc table of a call comming to > my opensips subscriber number. > > Thanks for all help > > BR > Simon > > > > > > _______________________________________________ > 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 bogdan at opensips.org Thu Jul 17 15:48:14 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 17 Jul 2025 18:48:14 +0300 Subject: [OpenSIPS-Users] Re-homing a large number of subscribers In-Reply-To: References: Message-ID: <68465410-0f82-4896-baca-8abe8016bbd9@opensips.org> Hi Ben, Use paging (index and count) when fetching the dialgs: https://opensips.org/html/docs/modules/3.6.x/dialog.html#mi_dlg_list Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 09.07.2025 13:11, Ben Laing via Users wrote: > > Hi folks, > > I’m using OpenSIPs as a load balancer in an active/active setup. I’m > trying to set up call re-homing when a node in the cluster goes down, > largely following > https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/ > . I’ve got separate shtags lb1 and lb2 for each node. > > When the cluster down is detected, I am running a python script that > sets the remaining node as active then aims to rehome the calls in > progress. Currently, that works by getting dlg_list_ctx, then running > dlg_send_sequential for each dialog with a shtag matching the down > node (dialog[‘context’][‘values’][‘dlgX_shtag’]. > > That’s fine for a few calls, but fails when we get to a few hundred > because the dlg_list_ctx throws an error: > Jul9 09:47:00 ip-10-4-40-11 /usr/sbin/opensips[83438]: > ERROR:core:print_mi_response: Failed to print JSON > > Jul9 09:47:00 ip-10-4-40-11 /usr/sbin/opensips[83438]: > ERROR:mi_http:mi_json_answer_to_connection: failed to print json response > > Any ideas recommendations on how to tackle this? > > I could use dlg_list_ctx specifying an index/counter to complete in > batches, but I’m not quite sure how the indexing works so there’s a > worry we’d miss calls. E.g. we do calls 0-40 then 41-80 but if call 0 > ends while processing 0-40, does that mean call 41 becomes call 40 so > it’s missed from the 41-80 batch. > > > Probably the best solution I have at the moment is to query the DB > directly to get the definitively list of call ids, then run > dlg_list_ctx specifying and iID then dlg_send_sequential if > appropriate. Or just don’t bother checking and run dlg_send_sequential > on them all. > > Any thoughts / suggestions? > > Best, > > ‑‑‑‑‑ > > *Ben Laing*** > > > > > > He/Him > > Senior Software Developer > > > > Email: _ben.laing at dals.co.uk_ > > Website: www.dals.co.uk > > *Dals, Statham House, Talbot Rd, Stretford, Manchester, M32 0FP*** > > > Classified - General > > > _______________________________________________ > 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 venefax at gmail.com Thu Jul 17 16:53:30 2025 From: venefax at gmail.com (Federico Alves) Date: Thu, 17 Jul 2025 19:53:30 +0300 Subject: [OpenSIPS-Users] Topology_hiding took down my carrier's switch In-Reply-To: References: Message-ID: What happens is rhis: everybody uses the topplogy hiding module with the default encryption password. If found that 2 opensips boxes where the source does topology hiding, cannot talk to the second box if both boxes have the same encryption password. The second box will decode the call ID and respond using the first box client-side call ID. The whole SIP protocol breaks down. I took down the largest hosted switch provider in the US. Please let me know if you have any other questions, via private email. On Thu, Jul 17, 2025, 5:53 PM Bogdan-Andrei Iancu wrote: > Hi, > > The only thing you can do is (1) ask the carrier for an example of such > bogus dialog and (2) investigate the SIP traffic to be sure that the BYE > exchange with the carrier was correctly done... > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > https://www.siphub.com > > On 27.06.2025 00:57, Federico Alves wrote: > > So far my engineers use topology_hiding(), and the CallID from the > > client was passing forward to the carrrier. So we switched to > > topology_hiding("C") and worked as expected but the carrier's switch > > collapsed after a while. They say that we leave many dialogs open thar > > never close. Other than that, th3 calls work fine for us. > > What are my engineers doing wrong? > > > > _______________________________________________ > > 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 bogdan at opensips.org Fri Jul 18 09:42:35 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 18 Jul 2025 12:42:35 +0300 Subject: [OpenSIPS-Users] Topology_hiding took down my carrier's switch In-Reply-To: References: Message-ID: In such cases, just change the TH prefix, to avoid confusion between the instances: https://opensips.org/html/docs/modules/3.6.x/topology_hiding.html#param_th_callid_prefix Regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com https://www.siphub.com On 17.07.2025 19:53, Federico Alves wrote: > What happens is rhis: everybody uses the topplogy hiding module with > the default encryption password. If found that 2 opensips boxes where > the source does topology hiding, cannot talk to the second box if both > boxes have the same encryption password. The second box will decode > the call ID and respond using the first box client-side call ID.  The > whole SIP protocol breaks down. I took down the largest hosted switch > provider in the US. > Please let me know if you have any other questions,  via private email. > > On Thu, Jul 17, 2025, 5:53 PM Bogdan-Andrei Iancu > wrote: > > Hi, > > The only thing you can do is (1) ask the carrier for an example of > such > bogus dialog and (2) investigate the SIP traffic to be sure that > the BYE > exchange with the carrier was correctly done... > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > https://www.siphub.com > > On 27.06.2025 00:57, Federico Alves wrote: > > So far my engineers use topology_hiding(), and the CallID from the > > client was passing forward to the carrrier. So we switched to > > topology_hiding("C") and worked as expected but the carrier's > switch > > collapsed after a while. They say that we leave many dialogs > open thar > > never close. Other than that, th3 calls work fine for us. > > What are my engineers doing wrong? > > > > _______________________________________________ > > 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 apach at lviv-ua.com Tue Jul 22 19:51:46 2025 From: apach at lviv-ua.com (APach) Date: Tue, 22 Jul 2025 22:51:46 +0300 Subject: [OpenSIPS-Users] Transparent SIP inspection setup using OpenSIPS and FreeSWITCH over a bridged VLAN network. Message-ID: Dear team, Is it possible to implement a transparent SIP inspection and proxy setup using OpenSIPS and FreeSWITCH over a bridged VLAN network, running on the same host machine? Could someone please confirm if this setup would work as described? Network Layer Configuration eth0 and eth1 are connected as VLAN trunks. VLAN 150 is created on both interfaces (public subnet for FreeSWITCH). VLAN 250 is created on both interfaces (private subnet for OpenSIPS). Both VLANs are bridged into br150 and br250 respectively on the same host. br150 is assigned IP 45.45.45.45/24. br250 is assigned IP 10.10.10.45/24. Default gateway is set to 45.45.45.1 via br150. OpenSIPS and FreeSWITCH FreeSWITCH listens on the public VLAN interface (br150). OpenSIPS runs on the private VLAN interface (br250) and handles SIP filtering only. Thanks in advance. _______________________________ Best Regards Andriy Pachkovskyy Mob. tel. +48504122924 Mob. tel. +380679421834 Sip tel. 220000 at lviv-ua.com Email: apach at lviv-ua.com Jabber: apach at lviv-ua.com From bogdan at opensips.org Wed Jul 23 14:33:04 2025 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 23 Jul 2025 17:33:04 +0300 Subject: [OpenSIPS-Users] OpenSIPS 3.6.0 goes stable Message-ID: <4b5c7251-d4f2-4a79-8ff2-63d1f9582310@opensips.org>  OpenSIPS 3.6.0 goes from beta to stable *It got stable!* There were two full months of work, of testing, of reporting and of fixing, but we did it! The *OpenSIPS 3.6* release passed all the tests and exams and now it is labelled as a stable release, the new flagship of the OpenSIPS project. Note that 3.6 is the last release in the 3.x family, _next in line being 4.0 - see the blog post_! Read about 4.x *3.6 Philosophy* The OpenSIPS 3.6 release focused on /*operational improvement*/ - this translates into introducing and enhancing in OpenSIPS features / capabilities that (1) improve and (2) simplify the operational activities when comes to running and managing OpenSIPS. So key features : * Dynamic sockets * AWS and Janus integration * Structured SDP manipulation * Unified branching support Read more on 3.6 Any questions? do not hesitate to contact us ! ------------------------------------------------------------------------ -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com https://www.siphub.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmaruzz at gmail.com Wed Jul 23 14:45:39 2025 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Wed, 23 Jul 2025 16:45:39 +0200 Subject: [OpenSIPS-Users] [OpenSIPS-Business] OpenSIPS 3.6.0 goes stable In-Reply-To: <4b5c7251-d4f2-4a79-8ff2-63d1f9582310@opensips.org> References: <4b5c7251-d4f2-4a79-8ff2-63d1f9582310@opensips.org> Message-ID: Yayyyy!!!!!! On Wed, Jul 23, 2025 at 4:34 PM Bogdan-Andrei Iancu wrote: > > OpenSIPS 3.6.0 goes from beta to stable > > > *It got stable!* > There were two full months of work, of testing, of reporting and of > fixing, but we did it! The *OpenSIPS 3.6* release passed all the tests > and exams and now it is labelled as a stable release, the new flagship of > the OpenSIPS project. > Note that 3.6 is the last release in the 3.x family, *next in line being > 4.0 - see the blog post*! > > Read about 4.x > > > *3.6 Philosophy* > > The OpenSIPS 3.6 release focused on *operational improvement* - this > translates into introducing and enhancing in OpenSIPS features / > capabilities that (1) improve and (2) simplify the operational activities > when comes to running and managing OpenSIPS. > > So key features : > > - Dynamic sockets > - AWS and Janus integration > - Structured SDP manipulation > - Unified branching support > > Read more on 3.6 > > > > Any questions? do not hesitate to contact us ! > ------------------------------ > > -- > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > https://www.siphub.com > > _______________________________________________ > Business mailing list > Business at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/business > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eddie2072 at icloud.com Wed Jul 23 23:40:09 2025 From: eddie2072 at icloud.com (eddie2072) Date: Thu, 24 Jul 2025 07:40:09 +0800 Subject: [OpenSIPS-Users] How can I close an illegal WS/TCP/TLS/WSS connection within the opensips.cfg script? Message-ID: <2C784238-FF81-4B74-B2BA-98F64385ABD9@icloud.com> I want to close some illedgl tcp-base connections within opensips.cfg, but there is no one. I also use kamailio sometimes, i found that kamailio has tcpops module, the tcpops has tcp_close_conection() function, But I prefer to use OpenSIPS. From slackway2me at gmail.com Tue Jul 29 08:24:51 2025 From: slackway2me at gmail.com (Alexey) Date: Tue, 29 Jul 2025 13:24:51 +0500 Subject: [OpenSIPS-Users] YUM repo for Centos 8 and OpenSIPS 3.5 - certificate invalid Message-ID: Hi team, seems that the certificate is outdated. [root at dhcp-10-145-216-249 ~]# yum search opensips Failed to set locale, defaulting to C.UTF-8 OpenSIPS - Open Source SIP proxy/server for el8 - x86_64 0.0 B/s | 0 B 00:00 Errors during downloading metadata for repository 'opensips': - Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://yum.opensips.org/3.5/releases/st/8/x86_64/repodata/repomd.xml [SSL certificate problem: certificate is not yet valid] Error: Failed to download metadata for repo 'opensips': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried -- best regards, Alexey https://alexeyka.zantsev.com/ From slackway2me at gmail.com Tue Jul 29 09:16:20 2025 From: slackway2me at gmail.com (Alexey) Date: Tue, 29 Jul 2025 14:16:20 +0500 Subject: [OpenSIPS-Users] YUM repo for Centos 8 and OpenSIPS 3.5 - certificate invalid Message-ID: Excuse me, the reason was in unsyncronized time on the virtual machine. Now it's OK. -- best regards, Alexey https://alexeyka.zantsev.com/ From sandro at enablesecurity.com Thu Jul 31 05:03:07 2025 From: sandro at enablesecurity.com (Sandro Gauci) Date: Thu, 31 Jul 2025 05:03:07 -0000 Subject: [OpenSIPS-Users] Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical) Message-ID: <6950250b-ff0e-4364-8178-82fe72ec0f98@app.fastmail.com> Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical) - CVSS v4.0 - Exploitability: High - Complexity: Low - Vulnerable system: Medium - Subsequent system: Medium - Exploitation: High - Security requirements: High - Vector: https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:H/SI:H/SA:H - Other references: CVE-2025-53399 (https://www.cve.org/CVERecord?id=CVE-2025-53399) - Fixed versions: >= mr13.4.1.1 (https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1) - Enable Security Advisory: https://github.com/EnableSecurity/advisories/tree/master/ES2025-01-rtpengine-improper-behavior-bleed-inject - Tested vulnerable versions: mr13.3.1.4 and lower - Timeline: - First report: 2025-04-24 - Triaged: 2025-04-30 - Fix provided for testing: 2025-05-05 - Various back and forth and more fixes: 2025-05 / 2025-06 - Vendor applied all fixes satisfactorily to master branch: 2025-06-05 - Enable Security verified and confirmed fix: 2025-06-26 - Vendor release with fix (mr13.4.1.1): 2025-07-03 - Enable Security advisory: 2025-07-31 DESCRIPTION Media servers often support source address learning to dynamically adapt to network conditions and client behavior. This is especially useful in scenarios involving NAT where the source IP and port of incoming RTP packets may differ from what was initially signaled via SDP over SIP. However, this mechanism can be exploited for two types of attacks if malicious packets are accepted as legitimate: 1. RTP Bleed - when a victim's media (e.g., audio) can be redirected to an attacker-controlled host 2. RTP Inject – when attackers can insert arbitrary RTP packets into active calls Note: Neither of these attacks requires the attacker to act as a man-in-the-middle. Additionally, when rtpengine relays SRTP packets in vulnerable versions, it does not validate their authentication tag, also allowing RTP Bleed and RTP Inject despite the use of SRTP which should guarantee confidentiality and integrity. Instead of dropping packets with missing or invalid authentication tags, it forwards them for processing. The purpose of this advisory is to describe security fixes that aim to fully address or at least mitigate these RTP Bleed and RTP Inject attacks wherever possible. While complete elimination of these vulnerabilities may not always be achievable due to the inherent nature of RTP learning mechanisms, the fixes provide significant improvements in security posture. TECHNICAL DETAILS Rtpengine provides the following learning modes through the --endpoint-learning option: - delayed (default): waits 3 seconds before learning the source address from the first RTP packet received after the delay. - immediate: learns the address from the very first incoming packet, with no delay. - no-learning: disables learning entirely, which is the only mode that is not vulnerable but can break connectivity for clients behind NAT. - heuristic: combines a 3-second delay with a ranking system that prefers addresses matching the original SDP, falling back to partial matches or any observed address if necessary. Additionally, rtpengine supports an optional strict source flag that forces continued inspection of source addresses and ports of incoming RTP packets. It does this after the learning phase, enforcing what was previously learned. The strict source flag is meant to prevent RTP Inject but needs the learning mode to work as expected for it to also work correctly. The often recommended mitigation is to make use of SRTP, with the assumption that rtpengine would discard any RTP packets that fail the authentication tag check. However, in rtpengine mr13.3.1.4 and lower, this was not found to be the case when using SDES-SRTP. The following is a behavior matrix for rtpengine versions mr13.3.1.4 and lower showing different learning modes and flags. This table shows that none of the learning modes nor strict source mitigated the attacks described, except for the combination of strict source with no-learning: | Delayed | Heuristic | No learning | Immediate | no strict source | Inject, Bleed | Inject, Bleed | Inject only | Inject, Bleed | strict source | Inject, Bleed | Inject, Bleed | No Inject or Bleed | Inject, Bleed | The same behavior occurred whether rtpengine relayed plaintext RTP or SDES-SRTP. The heuristic flag did not prevent RTP Bleed or RTP Inject attacks, even when the correct IPs and ports are exchanged over SDP. With the updated version, rtpengine's heuristic behavior was changed so that the learning modes behave as expected, giving administrators the opportunity to mitigate these vulnerabilities while still handling NAT complexities. The following is the same behavior matrix, but with the fixed version: | Delayed | Heuristic | No learning | Immediate | no strict source | Inject, Bleed | Inject, <5 packets Bleed | Inject only | Inject, Bleed | strict source | Inject, Bleed | <5 packets Inject, <5 packets Bleed | No Inject or Bleed | Inject, Bleed | This means that with the updated version, the heuristic mode limits attacks to at most the first 5 packets for both injection and bleeding. We believe that in many live environments, the recommended setup would be to use heuristic learning with strict source, which keeps the flexibility of endpoint learning while significantly mitigating RTP inject and RTP bleed attacks. In the case of SDES-SRTP, we also recommend using heuristic learning mode with strict source, which keeps the flexibility of endpoint learning while mitigating RTP inject and RTP bleed. However, for complete protection with SRTP, a patch specific to SRTP was introduced by adding a new recrypt flag. This flag forces rtpengine to decrypt and then re-encrypt RTP packets, thus validating the authentication tag before any further processing. This ensures that unauthenticated packets are discarded. This new flag should be used in addition to the previously recommended learning mode and flag. Patched version behavior matrix for SDES-SRTP, with and without recrypt: | Delayed | Heuristic | No-learning | Immediate | Without recrypt | Inject, Bleed | Inject, <5 packets Bleed | Inject only | Inject, Bleed | With recrypt | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | There is the special case of DTLS-SRTP, typically used for WebRTC environments, which was found vulnerable to RTP Bleed but not RTP Inject. This was due to the logic applied in this case, where learning mode occurred before the RTP packets were properly validated. This has also received a security fix. IMPACT In the case of plaintext RTP, this vulnerability allows attackers to perform RTP Inject as well as RTP Bleed. RTP Inject affects the integrity of the media while RTP Bleed affects the confidentiality of calls. In cases where rtpengine is relaying plaintext RTP as well as when it relays SRTP (in vulnerable versions), the vulnerabilities will cause Denial of Service because the RTP packets will be sent to the attacker instead of the legitimate recipient. HOW TO REPRODUCE THE ISSUE To reproduce this issue in a reliable manner, a security tester needs three different parties each with their own IP address: 1. Vulnerable rtpengine server 2. An attacker node 3. A victim user node Steps: 1. Run tcpdump on the attacker node to monitor for incoming packets from the target: tcpdump -iany -w /tmp/rtpbleed.pcap src host and not icmp 2. Save the following Python script as sprayrtp.py: import socket, argparse parser = argparse.ArgumentParser(description="Spray simple RTP packets over a port range") parser.add_argument("target", help="Target IP address") parser.add_argument("start_port", type=int, help="First UDP port to spray") parser.add_argument("end_port", type=int, help="Last UDP port to spray") args = parser.parse_args() rtppacket=[0x80, 0x0, 0xee, 0x3c, 0x4, 0x42, 0xa2, 0xc1, 0xef, 0xa, 0x7, 0xde] rtppacket+=[0x0 for _ in range(160)] sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) while True: for port in range(args.start_port, args.end_port + 1): sock.sendto(bytes(rtppacket), (args.target, port)) 3. Run the script on the attacker node against the target: python3 sprayrtp.py 4. From the victim user node, place a number of calls that make use of SRTP. 5. Observe that tcpdump on the attacker node will show incoming packets from the vulnerable target. Note: a SIP signaling server such as Kamailio or OpenSIPS is usually part of the setup as well. SOLUTIONS AND RECOMMENDATIONS It is recommended to upgrade to a fixed version, and to either disable learning entirely or use the heuristic learning mode in conjunction with the strict source flag. When using SDES-SRTP, it is recommended to use both strict source and recrypt flags for complete protection. While fixes for the heuristic mode were backported to earlier versions, the new recrypt flag is only available in the latest version. In the case of DTLS-SRTP, a fix was made so that SRTP validation occurs before learning mode. We highly recommend upgrading to access these security features. The first version that includes the fixes is available at https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1. ABOUT ENABLE SECURITY Enable Security (https://www.enablesecurity.com) provides quality penetration testing to help protect your real-time communications systems against attack. DISCLAIMER The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. DISCLOSURE POLICY This report is subject to Enable Security's vulnerability disclosure policy which can be found at https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy. -------------- next part -------------- An HTML attachment was scrubbed... URL: