sr-users December 2024

sr-users@lists.kamailio.org

27 participants
28 discussions

KAMI python3 and python3s not working / reloading

by trle.fuad＠gmail.com

Hello, I've started testing/learning KEMI and decide to use python3(s). I'm using default config with kamailio-basic-kemi-python3s.py (just deleted a couple of routes for simplicity). First thing I noticed is that reloading is not working. I've changed simple log line and did kamcmd app_python3s.reload. I'm compiling from source (inside Docker container, Debian bookworm as base), and have noticed it stopped working after thees commits for python3s: 62b4ee4a0d0b62b35c8bdf67e5daf9cbe9a28499 app_python3s: refactor GIL and thread state handling c81b2b3383c5900aba83672da024c812d8e6d89d app_python3s: initial support for free-threading Python And for python3 0ffe157bc13e7759ae1cee63a584fad4ac9eb38f app_python3: refactor GIL and thread state handling Am I missing some new parameter for module or compile flag? What I've noticed it's not only that it not reload, it also does not go through complete config file. While reloading, I see marking for reload. But nothing after that: 22(774) DEBUG: ctl [../../core/io_wait.h:368]: io_watch_add(): processing io_watch_add(0x748d1dfb83c0, 11, 3, 0x5f0adde454d0) - fd_no=1 22(774) DEBUG: ctl [io_listener.c:438]: handle_new_connect(): new connection (1) on /var/run/kamailio//kamailio_ctl 22(774) DEBUG: ctl [io_listener.c:499]: handle_stream_read(): bytes read: 29 22(774) INFO: app_python3s [apy3s_kemi.c:868]: app_python3s_rpc_reload(): marking for reload Python script file: /etc/kamailio/kamailio-basic-kemi-python3s.py (0 => 1) 22(774) DEBUG: ctl [io_listener.c:520]: handle_stream_read(): bytes processed: 29 22(774) DEBUG: ctl [io_listener.c:496]: handle_stream_read(): handle_stream read: eof on /var/run/kamailio//kamailio_ctl 22(774) DEBUG: ctl [../../core/io_wait.h:599]: io_watch_del(): DBG: io_watch_del (0x748d1dfb83c0, 11, -1, 0x10) fd_no=2 called

2 weeks, 3 days

nethelper module - need clarification on how to handle uri alias on location contacts.

by Benoît Panizzon

Hi Gang When a CPE behind nat registers, I have the alias added to the AOR contact. It has format ip~port~transport Let's say: bob@1.2.3.4:5060;alias=5.6.7.8~7777~1 On an invite to that CPE behind nat, the contact is retrieved from the location record and I assumed I could call handle_ruri_alias in the branch route to that CPE and this would sent the call to that ip port via transport in the alias. I observe that the port is not taken into account. The INVITE to bob is sent to ip 5.6.7.8 but to port 5060 instead of 7777 In the example config, handle_ruri_alias() is only used for in dialog requests (has_totag). Have I misunderstood how CPE behind NAT should be registered and that registration resolved? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 weeks, 3 days

Request for Feedback on an Installation Script for Kamailio (from Source)

by BROU STEPHANE FABIEN

Dear Kamailio Community, I hope this message finds you well. I have recently developed an install.sh script aimed at simplifying the process of installing Kamailio directly from source. My goal is to streamline the installation process while adhering to best practices for Kamailio deployment. I would greatly appreciate your feedback, suggestions, or any corrections to help improve the script’s robustness and ensure it aligns with the community’s standards. You can find the script in my GitHub repository: https://github.com/AL-CALL-LLC/KamailioBuilder.git Feel free to test it, share your thoughts, or open issues on GitHub for any recommendations or areas that need refinement. Thank you in advance for your time and valuable expertise. I am more than happy to provide further details or engage in discussions if needed. Best regards, Fabien Brou Developer

2 weeks, 4 days

[print_dset(): no r-uri or branches] when working with async worker

by elhar.mohamed＠gmail.com

Hello, I'm getting this warning WARNING: <core> [core/dset.c:690]: print_dset(): no r-uri or branches when working with async worker. here is below the code used: request_route { if (is_method("INVITE")) { append_to_reply("Contact: <sip:+1234;myparam=test@$si:$sp>\r\n"); send_reply("302", "Moved Temporarily"); exit; } } Can you please help?

2 weeks, 5 days

Multiple Branches and 3xx Status Codes

by Christian Berger

Hi, we have the following situation: Multiple UAs are subscribed to the proxy and get INVITEd via parallel forking. Now one of the UAs sends us a 302 status, we would like to handle this like a failure. So we'd like to CANCEL all the other branches, and forward the 302 status to the original INVITE. We have tried t_reply("302", "$T(reply_reason)") in the response, which almost solves this, however we cannot pass the required headers form the 302 response in it. BTW, could there have been a change in the default behavior of Kamailio? We think it used to "just work" in the past. Thank you very much Christian Berger -- Christian Berger - berger(a)sipgate.de Telefon: +49 (0)211-63 55 55-0 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.co.uk

2 weeks, 6 days

Development for v6.0.x is frozen

by Daniel-Constantin Mierla

Hello, the formal notification that the development for the next major version 6.0.0 is now frozen. The focus has to be on testing the master branch. Also, the master branch should not get commits with new features till the branch 6.0 is created, expected to happen in 2-4 weeks, a matter of how testing goes on. Meanwhile, the commits with new features in the C code can be pushed to personal branches, new pull requests can still be done, but they will be merged after branching 6.0. Can still be done commits with documentation improvements, enhancements to related tools (e.g., kamctl, kamcmd), merging exiting pull requests at this moment, exporting missing KEMI functions and completing the functionality of the new modules added for 6.0. Once the branch 6.0 is created, new features can be pushed again to master branch as usual. From that moment, the v6.0.0 should be out very soon, time used for further testing but also preparing the release of packages. If someone is not sure if a commit brings a new feature, just make a pull request and it can be discussed there on github portal or via sr-dev mailing list. A summary of what is new in upcoming 6.0 is going to be built at: * https://www.kamailio.org/wikidocs/features/new-in-6.0.x/ Upgrade guidelines will be collected at: * https://www.kamailio.org/wikidocs/install/upgrade/5.8.x-to-6.0.0/ Everyone is more than welcome to contribute to the above wiki pages, especially to the upgrade guidelines, to help everyone else during the migration process from v5.8.x to 6.0.x. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

2 weeks, 6 days

Freezing development for 6.0.x series

by Daniel-Constantin Mierla

Hello, I propose to aim freezing the development for 6.0.x series at the end of the 16th of December 2024 (Monday). New features that one wants to get in this release series have to be pushed to git repository or pull requests made for them. Afterwards usually follows a 4-6 weeks of testing till the first release 6.0.0. Unfreezing will happen earlier, after the first weeks of testing when the 6.0 branch will be created. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

3 weeks

ims_diameter_server: $diameter_response PV is null in the event_route[diameter:response]

by Grotti, Daniel

Hi list, I'm using kamailio 5.8 and playing with the ims_diameter_server module, by sending an async diameter request and trying to catch the reponse. Following the documentation, I'm sending the request with: route[SEND_ACR] { route(PREPARE_ACR); diameter_request_async("3", "271", "$var(json_acr)"); } route[PREPARE_ACR] { # here I build the AVP list in JSON $var(json_acr) = "[{"avpCode":277,"vendorId":0,"Flags":64,"int32":0},{...},{...}]"; } event_route[diameter:response] { xlog("Reply to diameter request is: '$diameter_response'\n"); } The ACR request is successfully sent and the the server is replying with ACA. The list of AVP are properly parsed, but when I enter the event_route to print the response, I get the $diameter_response = 'null': 2024-12-11T10:52:39.192951872+00:00 stderr F 11(19) DEBUG: cdp [worker.c:374]: worker_process(): worker_process(): [2] got task Q(2/2) 2024-12-11T10:52:39.193026280+00:00 stderr F 11(19) DEBUG: ims_diameter_server [avp_helper.c:60]: avp2json(): AVP((nil) < 0x7ff827633810 >0x7ff8276338c0);code=263,flags=40; 2024-12-11T10:52:39.193026280+00:00 stderr F DataType=1;VendorID=0;DataLen=52; 2024-12-11T10:52:39.193026280+00:00 stderr F 11(19) DEBUG: ims_diameter_server [avp_helper.c:60]: avp2json(): AVP(0x7ff827633810 < 0x7ff8276338c0 >0x7ff827633970);code=268,flags=40; 2024-12-11T10:52:39.193026280+00:00 stderr F DataType=3;VendorID=0;DataLen=4; 2024-12-11T10:52:39.193026280+00:00 stderr F 11(19) DEBUG: ims_diameter_server [avp_helper.c:60]: avp2json(): AVP(0x7ff8276338c0 < 0x7ff827633970 >0x7ff827633a20);code=264,flags=40; 2024-12-11T10:52:39.193026280+00:00 stderr F DataType=1;VendorID=0;DataLen=37; 2024-12-11T10:52:39.193026280+00:00 stderr F 11(19) DEBUG: ims_diameter_server [avp_helper.c:60]: avp2json(): AVP(0x7ff827633970 < 0x7ff827633a20 >0x7ff8276340b0);code=296,flags=40; 2024-12-11T10:52:39.193026280+00:00 stderr F DataType=1;VendorID=0;DataLen=33; 2024-12-11T10:52:39.193124627+00:00 stderr F 11(19) DEBUG: ims_diameter_server [avp_helper.c:60]: avp2json(): AVP(0x7ff827633a20 < 0x7ff8276340b0 >0x7ff827634160);code=259,flags=40; 2024-12-11T10:52:39.193124627+00:00 stderr F DataType=0;VendorID=0;DataLen=4; 2024-12-11T10:52:39.193286132+00:00 stderr F 11(19) DEBUG: ims_diameter_server [avp_helper.c:60]: avp2json(): AVP(0x7ff8276340b0 < 0x7ff827634160 >0x7ff827634210);code=480,flags=40; 2024-12-11T10:52:39.193286132+00:00 stderr F DataType=0;VendorID=0;DataLen=4; 2024-12-11T10:52:39.193286132+00:00 stderr F 11(19) DEBUG: ims_diameter_server [avp_helper.c:60]: avp2json(): AVP(0x7ff827634160 < 0x7ff827634210 >0x7ff8276342c0);code=485,flags=40; 2024-12-11T10:52:39.193286132+00:00 stderr F DataType=0;VendorID=0;DataLen=4; 2024-12-11T10:52:39.193286132+00:00 stderr F 11(19) DEBUG: ims_diameter_server [avp_helper.c:60]: avp2json(): AVP(0x7ff827634210 < 0x7ff8276342c0 >(nil));code=85,flags=40; 2024-12-11T10:52:39.193286132+00:00 stderr F DataType=0;VendorID=0;DataLen=4; 2024-12-11T10:52:39.193612877+00:00 stderr F 11(19) INFO: <script>: [event_route]: Reply to diameter request is: '<null>' Is there something I miss to set/configure? Thanks, Daniel Daniel Grotti Development Team Leader, Private 5G daniel.grotti(a)hpe.com<mailto:daniel.grotti@hpe.com> Hewlett Packard Enterprise HPE.com [cid:803b85f7-01fe-4c9c-a069-74d14a9ea122]

3 weeks, 1 day

Kamailio IMS, used with IPv6?

by Valentin Christoph

Anybody experiences with Kamailio IMS modules (ims_registrar_scscf, ims_usrloc_scscf, ims_isc, ........) and the use of IPv6 addresses? Any pitfalls? DNS issues? Thanks, Christoph

3 weeks, 2 days

How to remove rr param on a reply?

by Benoît Panizzon

Hi Is there a way to remove an param from the top most rr header? I add a rr param towards the B CPE to store some information which is sent back on the rr header of the reply from B. So far this is what is intended and I also get this param in subsequent route headers from messages created by B and as the route header are remove towards A, this works fine. Unfortunately, in a case of a reply, the parameter is passed to A which is then sending back the param in the route header which would make it somehow complicated to figure out which side sent that parameter. I'm only interested if sent from B. So I wonder, is there a way to delete a rr param on replies to make sure I don't get it back in the ACK to the reply? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 weeks, 3 days

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users December 2024