sr-users March 2025

sr-users@lists.kamailio.org

44 participants
34 discussions

Server selecting TCP transport
by Jon Bonilla (Manwe) 13 Mar '25

13 Mar '25

Hi all Using 5.8.4 I have a trunk with a permanent registration created by rpc in the location table. It looks like this: kamcmd> ul.lookup location sbc.mydomain.com { AoR: sbc.mydomain.com Contacts: { Contact: { Address: sip:xxx@sbc.mydomain.com Expires: -102739 Q: 1 Call-ID: dfjrewr12386fd6-343(a)kamailio.rpc CSeq: 1 User-Agent: kamailio SIP Router - RPC Server Received: [not set] Path: <sip:192.168.255.202:5060;lr> State: CS_SYNC Flags: 0 CFlags: 0 Socket: [not set] Methods: 0 Ruid: ulcx-67c9e2ff-19f8-1 Instance: [not set] Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 0 Last-Keepalive: 1741899218 KA-Roundtrip: 0 Last-Modified: 0 } } } In this situation the proxy sends the request to 192.168.255.202 which is a kamailio load balancer which is responsible for sending the call to the customer. The problem is that kamailio, when relaying this request, first performs TCP srv lookup and tries to send the request via TCP. There's no transport=tcp in the address. The lb's dns settings are: dns_try_ipv6=no dns_retr_time=1 dns_retr_no=1 dns_use_search_list=no use_dns_cache=on use_dns_failover=on dns_srv_lb=on dns_try_naptr=no dns_sctp_pref=1 dns_tcp_pref=1 dns_tls_pref=1 dns_udp_pref=1 Seems like this kamailio tries TCP SRV first, and then TLS and then UDP if the previous doesn't bring results. But no NAPTR is enabled. I don't know why it will choose TCP over UDP in this case. -- PekePBX, the multitenant PBX solution https://pekepbx.com

1 0

SDP Truncation When Relaying from WebSocket to UDP – Expected Behavior?
by Pavan Kumar 13 Mar '25

13 Mar '25

Hello Kamailio Community, I recently encountered an interesting behavior when using Kamailio to relay SIP messages from a WebSocket client to FreeSWITCH over UDP. *Observed Behavior:* - The WebSocket client sends an *INVITE* with a large SDP. - Kamailio forwards this request over UDP to FreeSWITCH. - Upon inspection, the *SDP in the relayed message appears truncated*. (Probably MTU limit) - *Surprisingly, the call still establishes successfully*, and there are no noticeable issues with audio or call setup. *My Questions:* 1. *Is this expected behavior?* Should Kamailio automatically truncate SDP when relaying from WebSocket to UDP? 2. *Could this be working accidentally?* For example, is FreeSWITCH handling the partial SDP gracefully by default? 3. *Should I be concerned about potential failures in different scenarios?* (e.g., ICE candidate loss, missing codec negotiation) I would appreciate any insights from the community on whether this is a known or expected behavior in Kamailio, or if it might be a configuration issue. Thanks in advance for your help! Best regards, Pavan Kumar

4 5

Need help using Kamailio IMS and Open5GS for 5G core
by Pete Kay 13 Mar '25

13 Mar '25

Hi I am able to compile Kamailio IMS and Open5GS. The instruction in https://open5gs.org/open5gs/docs/tutorial/02-VoLTE-setup/ is for 4G using Diameter. For 5G, we need to use HTTP protocol. Does anyone know if there is any guide on how to configure Kamailio IMS and Open5GS on 5G core using HTTP protocol for PCRF ? Thanks for millions for all your help. Pete

2 1

Re: upgrading process
by Anthony Ford 12 Mar '25

12 Mar '25

Thanks Ben Really appreciate your response Tony From: Ben Kaufman via sr-users <sr-users(a)lists.kamailio.org> Reply to: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Date: Wednesday, 12 March 2025 at 16:20 To: "sr-users(a)lists.kamailio.org" <sr-users(a)lists.kamailio.org> Cc: Ben Kaufman <bkaufman(a)bcmone.com> Subject: [SR-Users] Re: upgrading process Luckily there usually aren't a lot of breaking changes in Kamailio updates, and config files are mostly back compatible. That doesn't mean that there are never changes, but it does mean that the number of issues to resolve is usually small. * wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc There shouldn't really be any changes needed to config for the patch/fix versions like that (third decimal place) so those should be fine (and is good practice if you're not able to quickly update to a supported version for any reason), but it shouldn't be necessary to touch every incremental version to upgrade Kamailio. Every major release has an upgrade guide from the pervious version, so in your case: * 5.6 to 5.7: https://www.kamailio.org/wikidocs/install/upgrade/5.6.x-to-5.7.0/ * 5.7 to 5.8: https://www.kamailio.org/wikidocs/install/upgrade/5.7.x-to-5.8.0/ * 5.8 to 6.0: https://www.kamailio.org/wikidocs/install/upgrade/5.8.x-to-6.0.0/ It still shouldn't be necessary to touch each individual version while upgrading. I'd recommend reading through these docs in order taking note of the following: * Look for potentially breaking changes in the core. I don't see any in those documents, but a good example would be if upgrading from 4.x to 5.x how fifo was deprecated. * Look for modules changes. Mostly you'll see things like new features which shouldn't be breaking. A few modules were deprecated/archived in 5.8 ( app_sqlang, and auth_identity). Sometimes modules have small breaking changes in them as well, for example in 6.0 the dialog module dropped support for the dlg_flag parameter. Check your kamailio configs to see if any of these listed changes will impact you. * Follow any DB upgrade changes. These are usually simple changes - things like adding an index to a column, or changing a varchar(n) datatype to be varchar(n+y) which won't break your existing config. Another reply correctly points out that you should watch for changes to the version table. This is possibly a situation where a conflict could arise: The version required for one table might be 1 in 5.6 and 2 in 6.0. It might be worth while to copy the existing version table to a new table (like version_60 for example), and use kamailio's version_table parameter to use the new version table on the updated config. (note: The upgrade guides don't show any table version changes, so you probably don't need to do this). Finally, as a recommendation, smoke test your config in docker. You might not have the container setup in a way to actually receive SIP messages, but "does the config file load correctly" is a nice thing to have resolved ahead of time. * Regards, Kaufman ________________________________ From: Anthony Ford via sr-users <sr-users(a)lists.kamailio.org> Sent: Wednesday, March 12, 2025 9:30 AM To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org> Cc: Anthony Ford <tony.ford(a)apalo.co.uk> Subject: [SR-Users] upgrading process CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi I need some help please. I am very inexperienced with Kamailio, and am trying to work out how to upgrade without rewriting any of the current config. I am going from 5.6.0 to 6.0.0 and wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc. until I need to make a bigger step, and may have to change tables etc. In the document for upgrading 5.6.x to 5.7.x it says make change to Watch table, but I have no watch table. Very confused. Thanks Tony

1 0

CANCEL suspension and forking
by Alex Balashov 12 Mar '25

12 Mar '25

Hi, When a CANCEL is received and matches a known INVITE transaction, it is forked to all existing branches of that INVITE transaction, at least with these settings: modparam("tm", "cancel_b_method", 2) modparam("tm", "failure_reply_mode", 3) I have a mobile endpoint that is slow to be pushed awake and reregister, tsilo-style, and by the time it finally appears on the scene, the underlying INVITE transaction has been terminated. Accordingly, that endpoint receives no CANCEL. You might ask why that's a problem, if it also didn't receive a forked INVITE. The problem is that Apple's CallKit requires interactive presentation of VoIP APNS notifications as though they are "calls", leading to the phenomenon of what might be called "ghost calls" extrinsically to the actual mobile application. Anyway, I am aware of numerous possible solutions to this problem in principle; most involve sending an out-of-band SIP message to signify an alternative cancellation of the call. However, wonder if I am missing some best-practical approach, perhaps through an overlooked TM facility, or some way of keeping the transaction alive longer than the CANCEL from the UAC would ordinarily require? I don't see how that would work, but thought better to ask. Thanks! -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

3 4

upgrading process
by Anthony Ford 12 Mar '25

12 Mar '25

Hi I need some help please. I am very inexperienced with Kamailio, and am trying to work out how to upgrade without rewriting any of the current config. I am going from 5.6.0 to 6.0.0 and wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc. until I need to make a bigger step, and may have to change tables etc. In the document for upgrading 5.6.x to 5.7.x it says make change to Watch table, but I have no watch table. Very confused. Thanks Tony

3 3

Set TTL for skipped NAPTR record due to all IPs are unreachable
by Mathias Schneuwly 11 Mar '25

11 Mar '25

Hi I've a question regarding skipped NAPTR records. In our setup, we are using quite big DNS TTLs (860400). If there is an issue on the target server, the NAPTR record is marked as skipped "Mark to skip _sips._tcp.... NAPTR record due to all IPs are unreachable" until the TTL is expired. Since our TTLs are so big, the destination is no longer reachable during this time, even if the server is reachable again. I've seen that I can set "dns_cache_max_ttl" to reduce the time, but this is of course for all cached DNS records. Is there a way to set how long a NAPTR record is skipped or disable the feature at all? Or maybe skip the NAPTR only for the current dialog or transaction? Thanks for your help Best regards Mathias

2 7

Kamailio v6.0.1 Released
by Daniel-Constantin Mierla 10 Mar '25

10 Mar '25

Hello, Kamailio SIP Server v6.0.1 stable release is out. This is a maintenance release of the latest stable branch, 6.0, that includes fixes since the release of v6.0.1. There is no change to database schema or configuration language structure that you have to do on previous installations of v6.0.x. Deployments running previous v6.0.x versions are strongly recommended to be upgraded to v6.0.1. For more details about version 6.0.1 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2025/03/kamailio-v6-0-1-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 0

Releasing v6.0.1
by Daniel-Constantin Mierla 10 Mar '25

10 Mar '25

Hello, I am considering to release Kamailio v6.0.1 (out of branch 60) on Monday, March 10, 2025. If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 1

Kamailio with Presence Module and Publishing by Asterisk
by Ludovic GRANGE 05 Mar '25

05 Mar '25

Hi, I'm having a problem managing the presence between Kamailio and Asterisk. I have configured Kamailio as a presence server. Asterisk sends presence information via publishing sip request. My softphone which uses Kamailio as a presence server and as a proxy has 2 BLFs configured. On a first call, the presence status is displayed on the 2 keys. But for the 2nd call, only the extension receiving the call has its status changed on the BLF. Via sngrep, the Publishing requests arrive on Kamailio but the DB is not updated because the e-tag does not match. If I wait until the end of the expiry period (60s for the test), the DB is flushed and the 1st call works again. Could you please help me? Thank you Translated with DeepL.com (free version) -- Bien cordialement, Bande verticale Prosoluce Ludovic Grange Administrateur systèmes & réseaux Picto mailludovic.grange(a)prosoluce.fr <mailto:ludovic.grange@prosoluce.fr> Picto tél 05 31 61 62 25 <tel:+33531616225> Picto webwww.prosoluce.fr <https://www.prosoluce.fr> Logo Prosoluce

3 5

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 March 2025