sr-users July 2025

sr-users@lists.kamailio.org

44 participants
33 discussions

Are there any mistakes in the document?
by 13715209697＠139.com 17 Jul '25

17 Jul '25

Hi, team https://www.kamailio.org/wikidocs/cookbooks/6.0.x/pseudovariables/#timename… mday - return the day of month (int 0-59) Are there any mistakes in the document? 1-31? By the way, adding nanoseconds would be even better. Han

1 0

SDP Issue on NAT environment
by Nathan C 16 Jul '25

16 Jul '25

Hello, I have a kamailio on SITE A using a public IP. I'm trying to setup another kamailio on SITE B with NAT. When I try to make a call from SITE B to SITE A, the call is initiated but when comes the SDP my equipment on SITE B does not reply to SDP sent by kamailio on SITE A. I made some test and use only Public IP between the 2 sites and it works properly. So I think that I have a problem on my NAT configuration or maybe I'm missing something. Can someone help me one this problem ? Do you have an idea on what could be blocking. Thank in advance for your help. Regards, Nathan

2 2

Re: event_route[tcp:closed] and event_route[websocket:closed] not triggered on sudden WebSocket connection loss
by Kouadio Stéphane Fabien Brou 15 Jul '25

15 Jul '25

Thank for your reply, this is the pcap file

3 2

event_route[tcp:closed] and event_route[websocket:closed] not triggered on sudden WebSocket connection loss
by fabienbrou＠alcall.net 14 Jul '25

14 Jul '25

Hello Kamailio community, I'm running Kamailio 5.8 with websocket and tcpops modules loaded. My setup: - websocket module configured with keepalive enabled: modparam("websocket", "keepalive_mechanism", 1) modparam("websocket", "keepalive_interval", 10) modparam("websocket", "keepalive_timeout", 5) modparam("websocket", "keepalive_processes", 2) modparam("websocket", "timer_interval", 5) - tcpops module loaded with closed_event enabled: loadmodule "tcpops.so" modparam("tcpops", "closed_event", 1) - event_route[tcp:closed] implemented to catch socket closure and clean dialogs - dialog module loaded with dlg_flag = 4, and dialog tracking active on INVITE requests What works: - When I manually kill the WebSocket client, the event_route[tcp:closed] is triggered immediately. What doesn't work: - When the client loses network connectivity abruptly (e.g. mobile device loses 4G signal or Wi-Fi disconnects), the event_route[tcp:closed] is NOT triggered for several minutes (likely until TCP timeout). - I've tried reducing websocket keepalive_timeout to 5 seconds, but it does not speed up detection of lost connections. - I have confirmed that TCP keepalive settings on the OS are at default values and have not yet been tuned. My questions: 1. Is there any known limitation or delay in Kamailio's tcpops or websocket modules that could cause delayed detection of abrupt WebSocket disconnects? 2. Are there any best practices or additional mechanisms recommended to handle abrupt WebSocket disconnections faster, especially for SIP dialog cleanup? 3. Would adding SIP OPTIONS ping help detect dead clients sooner, and how would you recommend implementing this in Kamailio? 4. Any other suggestions to improve detection and cleanup of dead WebSocket SIP clients? Thanks in advance for your help and advice. Best regards, Fabien Brou

2 2

Kamailio WSS to Asterisk (UDP) MESSAGE Handling Issue
by Fernando Lopes 14 Jul '25

14 Jul '25

Hello everyone, I'm running into a problem with SIP traffic coming in over WSS to Kamailio. As far as I know, Kamailio can't forward traffic to Asterisk over TLS, so I'm currently using UDP to send traffic from Kamailio to Asterisk via the dispatcher module. The main SIP methods involved are REGISTER and MESSAGE. Kamailio successfully receives and forwards both methods to Asterisk, though I’m not entirely sure how the message routing is working behind the scenes — but somehow, it works. The problem arises when Asterisk sends a response to a MESSAGE. In my Asterisk logs, I can see that the response is being generated, but it seems to get lost or mishandled when Kamailio tries to process or forward it. To clarify the setup: ->Kamailio is listening on 10.5.0.8:5001 (WSS) ->It forwards traffic to Asterisk at 10.5.0.2:5060 (UDP) ->The issue specifically happens with MESSAGE replies, not REGISTER I suspect this might have something to do with mismatched transport protocols (WSS vs. UDP) or incorrect handling of routing headers in Kamailio. Any insights on how to debug or fix this properly would be greatly appreciated! Thanks in advance. My Code: https://docs.google.com/document/d/e/2PACX-1vSpRQmgZv1CTJW4IJ86a3SoSgPqmThM… Logs: <--- Transmitting SIP request (560 bytes) to UDP:10.5.0.8:5001 ---> MESSAGE sip:User1@10.5.0.8:5001;transport=ws;x-ast SIP/2.0 Via: SIP/2.0/UDP 10.5.0.2:5060;rport;branch=z9hG4bKPj8d3db1ed-d98e-4c87-ad71-ef43f47b1801 From: "Max" <sip:1@172.31.217.74>;tag=ae0b9d4d-89b9-489a-b5ef-3fb04fe6dd97 To: "ChatApp Max" <sip:User1@10.5.0.8;x-ast> Contact: <sip:User1@10.5.0.2:5060> Call-ID: 0ea7b15e-f176-452a-813d-684b01923c87 CSeq: 24741 MESSAGE Max-Forwards: 70 User-Agent: Asterisk PBX 18.24.3 Content-Type: text/plain Content-Length: 74 Compreendo, por favor, avança com a tua pergunta. Estou aqui para ajudar. <--- Received SIP response (480 bytes) from UDP:10.5.0.8:5001 ---> SIP/2.0 500 I'm terribly sorry, server error occurred (1/SL) Via: SIP/2.0/UDP 10.5.0.2:5060;rport=5060;branch=z9hG4bKPj8d3db1ed-d98e-4c87-ad71-ef43f47b1801;received=10.5.0.2 From: "Max" <sip:1@172.31.217.74>;tag=ae0b9d4d-89b9-489a-b5ef-3fb04fe6dd97 To: "ChatApp Max" <sip:User1@10.5.0.8;x-ast>;tag=19162a7003f0e5d10acb0ff84f0e52ca.d3fdd014 Call-ID: 0ea7b15e-f176-452a-813d-684b01923c87 CSeq: 24741 MESSAGE Server: kamailio (5.7.6 (x86_64/linux)) Content-Length: 0 <--- Received SIP response (463 bytes) from UDP:10.5.0.8:5001 ---> SIP/2.0 500 Message processing error (2/TM) Via: SIP/2.0/UDP 10.5.0.2:5060;rport=5060;branch=z9hG4bKPj8d3db1ed-d98e-4c87-ad71-ef43f47b1801;received=10.5.0.2 From: "Max" <sip:1@172.31.217.74>;tag=ae0b9d4d-89b9-489a-b5ef-3fb04fe6dd97 To: "ChatApp Max" <sip:User1@10.5.0.8;x-ast>;tag=0e4dcc88f47817a0f29d34cc60c5db67-d3fdd014 Call-ID: 0ea7b15e-f176-452a-813d-684b01923c87 CSeq: 24741 MESSAGE Server: kamailio (5.7.6 (x86_64/linux)) Content-Length: 0

4 6

TLS/SRTP bridging
by Jeremy Weibert 12 Jul '25

12 Jul '25

I'm new to Kamailio, and looking for some guidance. I have a very large global PBX network (NEC). I have mobile users, that for many years we have had connecting through VPN. This has worked fine for us until recently, various circumstances have made this unreliable. In searching for a better way to handle this, I came across Kamailio. I want the mobile users using TLS/SRTP, the NEC has various limitations on that, but more importantly, I'm not putting my PBXes on the internet. I've been at this for a few days now, learning and trying to see how I can do this with Kamailio, when I eventually came across this: https://www.fredposner.com/2309/kamailio-simple-tls-gateway/#:~:text=One%20…. Seems this is exactly what I need. The only difference really is that I have an additional firewall between the internet and the Kamailio server, with the external IP being NATed. In the famous last words of all users "it didn't work". Specifically, registrations seem to work just fine (the NEC acts as the registrar). However, when making a call: - The original INVITE from the mobile user (port 5061, TLS) reaches Kamailio and is then proxied via UDP to the PBX. - The PBX behaves appears to behave as a B2BUA, creating a completely new INVITE with a different Call-ID and sending it back to Kamailio. - Kamailio, seeing this as a completely new INVITE coming in on UDP (not TLS), rejects it (403 Accepting TLS Only). - Likewise, if a call originates from the PBX side, same thing. I figure, if the INVITE is coming from the PBX, I can just skip the TLS check, as it's coming from a trusted IP. However, the INVITE looks like: INFO: {1 udp 1 INVITE 7776d675@PBXIP} <script>: {R-MAIN] Incoming request from PRIVATEIP using udp In other words, the INVITE is showing as coming from Kamailio. I can't use the alias tag that Kamailio sets initially as the PBX strips it with the new INVITE. I figure to just explicitly send it to registered client over TLS by just rewriting the destination URI, and then it goes into an infinite loop. I got a bit lost at this point and if someone could help point me in the right direction, I would be eternally grateful.

3 4

ReINVITE on outbound edge proxy
by Sergey Safarov 11 Jul '25

11 Jul '25

We used Kamailio as an edge proxy described rfc5626. Here is the present section "9.3. Incoming Call and Proxy Crash" which describes the failover scenario when a call comes from the server towards the client device (WebRTC client). https://datatracker.ietf.org/doc/html/rfc5626#section-9.3 But also a possible case when the client device wants to place a call on hold, send a ReINVITE message. For some reason, websocket connections can be reestablished during a call, and now the old flow token does not match the new client connection and is handled as an incoming request and cannot be forwarded to a nonexistent client connection. And the client hold/unhold request fails. Example in the attached PCAP file (downloaded from Homer). Here message in frame 32 comes from source port 9184, and the next ReINVITE message from frame 36 comes from source port 9189. Could you point me to the RFC documents describes failover for outbound client requests (hold/unhold). Sergey

2 1

rtpengine error: no rtpp_set_list->rset_first
by disa_369＠msn.com 11 Jul '25

11 Jul '25

Hello to everyone. I deployed Kamailio on Debian system. Install was successfull. I have the task to use Kamailio as proxy between Avaya PBX and Videoconference System. Outgoing calls only from IPPhone ----- Avaya PBX ---sip----> Kamailio -----sip----> Video System-IVR Now Im trying setup rtpengine for proxy media . Kamailio has some errors by starting service. ERROR: rtpengine [rtpengine.c:3131]: select_rtpp_set(): no rtpp_set_list->rset_first Jun 06 12:07:00 zaks-sbc01-op /usr/sbin/kamailio[635658]: NOTICE: rtpengine [rtpengine.c:1815]: mod_init(): Default rtpp set 0 NOT found Missed out on something in config?

3 6

t_set_fr() sensitivity to timing when used in onreply_route
by Gianluca Merlo 10 Jul '25

10 Jul '25

Hello everyone, I am racking my brain on a peculiar behaviour with TM timers which I managed to narrow down after some trial and error, but the full implications and causes of which I still have to understand, and I am curious if anyone among the devs or other users with more knowledge than me has any clarification or suggestion to make about it. My scenario is the following, running Kamailio 5.8.5 on Debian bookworm packages 1. An INVITE for a local user is received 2. Preferences for the local user are read. The user has a certain timeout after which call forwarding should trigger. My setup aims to engage this timeout only if the user has provided a "proper" progress indication (180 or 183), and use a default value of 30 s if no progress is received. For this example, we assume this customized timeout is 10 s. 3. Standard usrloc lookup. A single location is found, behind an edge proxy (registered with Path). 4. INVITE gets sent (statefully) to the user through the edge proxy, UDP transport only. Before routing, the fr_inv_timer is set to the default value mentioned above using t_set_fr(30000). 5. The user replies with a 180. In the onreply_route, since this is the first proper progress indication, the fr_inv_timer is changed to the customized value calling t_set_fr(10000) At this point, I would expect the INVITE transaction to fail for timeout and go into call forwarding from the failure_route after the 10 s set in the onreply_route, but I am getting feedback from users that this does not always happen, and instead sometimes this happens in the 30 s set initially. I tried to reproduce the issue in a controlled setup, and the reliability of the t_set_fr() in onreply_route seems to be affected by the delay with which the 180 is received. Introducing pauses in a simulated client with sipp - With 400ms the call forwarding always triggers as expected (10s) - With 440ms I see 1/10 failures (call forwarding triggers in 30s) - With 450ms I see 5/10 failures - With >500ms I seem to get 10/10 failures So it seems like using t_set_fr() in onreply_route is sensitive to timing. Regarding this sensitivity, I noticed that 500 ms is the default retr_timer1 I am using, and changing that affects the effectiveness of the t_set_fr() call on onreply, i.e. t_set_retr(1000) allows t_set_fr() in onreply_route to be effective up to delays of 1000 ms in the 180 reception. Is this known and/or is there any workaround to get the behaviour I hoped to implement? If the limitation cannot be worked around, could it be useful to mention it in the t_set_fr() documentation? Thanks in advance for your help!

1 0

Off topic - FreeSWITCH and opus
by Calvin E. 09 Jul '25

09 Jul '25

For those who wanted to use opus but gave up due to transcoding or call recording issues, a new pull request should resolve them. This allows FreeSWITCH to properly match things like AMR-WB with 16kHz Opus, and fixes an issue with timestamp increments. https://github.com/signalwire/freeswitch/pull/2832 -Calvin E.

1 0

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