sr-users

sr-users@lists.kamailio.org

36 participants
37545 discussions

kamailio 5.8.6 sanity problem
by ale Gural 20 Jul '25

20 Jul '25

Hello, when kamailio 5.8.6 got the follow SIP message. INVITE sip:026774800@kamnet:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.25.206.73:5060;branch=z9hG4bK6204h710copg0h2s34a0.1 From: <sip:506555021@kamnet :5060;transport=UDP;user=phone>;tag=BN-1778920881-1-1752995491-343935404 To: <urn:service:sos.police@kamnet> Call-ID: 5f6d530-13f3cbf9-fb215-7f1546651f58-4d0f660a-13c4-764 CSeq: 1 INVITE X-SessionId: -1778920881 User-Agent: BN4000-3.9.2-706 Max-Forwards: 60 Supported: norefersub,timer,100rel,199 P-Asserted-Identity: <sip:506555021@hotmobile.co.il:5060 ;transport=UDP;user=phone> P-Asserted-Identity: <tel:506555021;phone-context=+972> Contact: <sip:10.25.206.73:5060;yop=00.00.84CE62D9.0000.7009;transport=udp> P-Early-Media: supported P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=425074efe02c6a01 Content-Disposition: session;handling=required Allow: INVITE,CANCEL,ACK,BYE,OPTIONS,INFO,PRACK,UPDATE,REFER,NOTIFY Content-Type: application/sdp Content-Length: 207 v=0 o=BN4000 0 0 IN IP4 10.9.21.56 s=- c=IN IP4 10.9.21.56 t=0 0 m=audio 54732 RTP/AVP 8 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=maxptime:20 a=ptime:20 the TO To: <urn:service:sos.police@kamnet>, the problem is kamailio 5.8.6 response with 400 bad to header but kamailio 5.7.5 continue with normal call. here you can see the sanity log for both kamailio: kamailio 5.8.6 Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:254]: check_ruri_sip_version(): check_ruri_sip_version entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:278]: check_ruri_sip_version(): check_ruri_sip_version passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:286]: check_ruri_scheme(): check_ruri_scheme entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:305]: check_ruri_scheme(): check_ruri_scheme passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:327]: check_required_headers(): check_required_headers entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:350]: check_required_headers(): check_required_headers passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:519]: check_cseq_method(): check_cseq_method entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:553]: check_cseq_method(): check_cseq_method passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:563]: check_cseq_value(): check_cseq_value entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:591]: check_cseq_value(): check_cseq_value passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:601]: check_cl(): check_cl entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:626]: check_cl(): check_cl passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:643]: check_expires_value(): check_expires_value entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:679]: check_expires_value(): no expires header found Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:776]: check_parse_uris(): check_parse_uris entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:780]: check_parse_uris(): parsing ruri Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:793]: check_parse_uris(): looking up From header Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:808]: check_parse_uris(): looking up To header Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: <core> [core/parser/parse_uri.c:1369]: parse_uri(): bad char '@' in state 5 parsed: <urn:service:sos.police> (22) / <urn:service:sos.police@kamnet> (29) Jul 20 17:08:15 vm-tkamprov-n 671587 ERROR: <core> [core/parser/parse_to.c:81]: parse_to_uri(): failed to parse To uri Jul 20 17:08:15 vm-tkamprov-n 671587 WARNING: sanity [sanity.c:810]: check_parse_uris(): invalid To header or uri kamailio 5.7.5 Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:253]: check_ruri_sip_version(): check_ruri_sip_version entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:277]: check_ruri_sip_version(): check_ruri_sip_version passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:285]: check_ruri_scheme(): check_ruri_scheme entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:304]: check_ruri_scheme(): check_ruri_scheme passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:326]: check_required_headers(): check_required_headers entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:349]: check_required_headers(): check_required_headers passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:518]: check_cseq_method(): check_cseq_method entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:552]: check_cseq_method(): check_cseq_method passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:562]: check_cseq_value(): check_cseq_value entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:590]: check_cseq_value(): check_cseq_value passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:600]: check_cl(): check_cl entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:625]: check_cl(): check_cl passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:638]: check_expires_value(): check_expires_value entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:674]: check_expires_value(): no expires header found Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:771]: check_parse_uris(): check_parse_uris entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:775]: check_parse_uris(): parsing ruri Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:788]: check_parse_uris(): looking up From header Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:803]: check_parse_uris(): looking up To header Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:853]: check_parse_uris(): check_parse_uris passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity_mod.c:252]: w_sanity_check(): sanity checks result: 1 Thanks

1 0

Kamailio as a Stateless Smart SIP Proxy
by Antonio 19 Jul '25

19 Jul '25

Hi everyone, Do we have a ready-to-use Kamailio role or configuration for: *“Kamailio as a Stateless Smart SIP Proxy”*, Specifically one that uses *Contact Header Encoding*? That is — a proxy where Kamailio does not store registration state, but encodes the client’s IP and port into the Contact header during REGISTER , and later decodes it from the INVITE to forward the call back to the client. Thanks in advance! -- *Antony* satskiy.a(a)gmail.com

4 7

TLS certificates kamailio & Asterisk
by Fernando Lopes 18 Jul '25

18 Jul '25

Hello everyone, I have a quick question. I'm working on a local project where Kamailio acts as a proxy and Asterisk handles the media. Both are running in separate Docker containers. For tls communication between the two, should I generate a separate TLS certificate for each container, or create only one certificate and use it for both? Thanks in advance!

2 1

cannot clone xavi from non existing parsed_pv_headers
by Mathias Schneuwly 18 Jul '25

18 Jul '25

Hi I'm getting the error "Jul 15 15:15:54 ttel /usr/sbin/kamailio[812316]: ERROR: {1 382 BYE 860005579-5060-39(a)BA.A.B.BCJ} pv_headers [pvh_xavp.c:485]: pvh_clone_branch_xavi(): cannot clone xavi from non existing parsed_pv_headers" on BYE messages. Interestingly, only on the first attempt to read the from user. I have the following snippet in my `ksr_branch_manage` KSR.log('notice', f'ksr_branch_manage: 1') KSR.log('notice', f'ksr_branch_manage: 2: {KSR.pv.get('$x_fU')}') KSR.log('notice', f'ksr_branch_manage: 3: {KSR.pv.get('$x_fU')}') The result in the log is Jul 15 15:25:03 ttel /usr/sbin/kamailio[816424]: NOTICE: {1 402 BYE 1640171511-5060-41(a)BA.A.B.BCJ} <core> [core/kemi.c:155]: sr_kemi_core_log(): ksr_branch_manage: 1 Jul 15 15:25:03 ttel /usr/sbin/kamailio[816424]: ERROR: {1 402 BYE 1640171511-5060-41(a)BA.A.B.BCJ} pv_headers [pvh_xavp.c:485]: pvh_clone_branch_xavi(): cannot clone xavi from non existing parsed_pv_headers Jul 15 15:25:03 ttel /usr/sbin/kamailio[816424]: NOTICE: {1 402 BYE 1640171511-5060-41(a)BA.A.B.BCJ} <core> [core/kemi.c:155]: sr_kemi_core_log(): ksr_branch_manage: 2: 200102 Jul 15 15:25:03 ttel /usr/sbin/kamailio[816424]: NOTICE: {1 402 BYE 1640171511-5060-41(a)BA.A.B.BCJ} <core> [core/kemi.c:155]: sr_kemi_core_log(): ksr_branch_manage: 3: 200102 Even if there is an ERROR, it seems to be able to read the from user from pv_headers. Is this error just informative and uses the wrong severity, or what does it mean? I have no modparam for pv_headers. It uses the default configuration and I'm on 5.8.6. Regards Mathias

1 1

TOPOS module routing loop with rogue Route headers
by David Tek 17 Jul '25

17 Jul '25

Hello, Setup: I activated the TOPOS module in my setup that looks something like this: SIP Device ---> Proxy1(w/ topos) ---> Proxy2(no topos) ---> ??? ---> Freeswitch. I am using Kamailio 6.0.1 (or 6.0.2, not sure). Both my proxies and the other nodes I don't control in ??? part all add Record-Route/Route headers for in-dialog requests. So an INVITE coming from the SIP Device will go through these proxies, on the 200 OK there are 3+ Record-Route headers which are consumed by TOPOS on Proxy1. With my baresip and Yealink phones, the phones send a 200 OK with NO Route headers and the Route headers are readded by the TOPOS module before it hits the routes in kamailio. Problem: Some SIP devices(I used an older Aastra device to reproduce the issue) like to add a Route header with the target proxy, and so Kamailio receives something like this(some headers stripped for brevity): ACK sip:atpsh-68769b30-2b-1@192.168.0.25 SIP/2.0 Via: SIP/2.0/UDP 192.168.34.122:5060;branch=z9hG4bKe3a6fe355f721ae5b Route: <sip:banana.mydomain.tld;lr> From: "12015550000" <sip:12015550000@banana.mydomain.tld>;tag=ba05cb9826 To: <sip:13105550000@banana.mydomain.tld:5060;user=phone>;tag=1SvNyXFeQjUaN Call-ID: 149a3a344dda2a1c CSeq: 12259 ACK With this, Kamailio receives the packet, internally somewhere runs the myself check and sees banana.mydomain.tld isn't a local domain. So it routes to that domain, which happens to resolve to this same Kamailio. So Kamailio routes the packet to itself until Max-Forwards hits 0 and fails. Solutions I tried: So I thought maybe alias_subdomains would help here: loadmodule "corex.so" modparam("corex", "alias_subdomains", "mydomain.tld") I ran this and found that it fixed the routing loop on the ACK, but then I got a routing loop on the BYE instead. So then I thought, maybe I can squeeze this out earlier: event_route[topos:msg-incoming] { if ( proto != TLS || !$tls_peer_verified || $Rp != "5061" ) { xlog("L_NOTICE", "=======> User packet this one $rm\n"); remove_hf("Route"); } else{ xlog("L_NOTICE", "=======> Server packet this one $rm\n"); } This didn't work, it only ever is invoked for SIP OPTIONS. So I tried with event_route[topos:msg-receiving] and saw messages like this: 16(1347) CRITICAL: <core> [core/ip_addr.c:234]: ip_addr2sbuf(): unknown address family 0 I guess $Rp isn't available in this event route. and $proto is always null. If I disable TOPOS completely, the Aastra phone will load the ACK with the Route headers defined by the Record-Route headers in the 200 OK and the call completes normally. I added this to the top of my request_route: xlog("L_NOTICE","$si - $rm - $hfl(Route) $hfl(Via)\n"); and the only route header that appeared for the ACK packet was the single route header. It would seem TOPOS can be 'defeated' by a rogue Route header. I started reading through the source code on this but could not pinpoint any code that would 'not restore TOPOS stripped headers when a rogue Route header appears because the Route header doesn't match the myself condition of Kamailio'. I even tried adding to topos:msg-sending: append_hf("Route: <sip:invalid.tld>\r\n"); To trick the phone into something that is predictable so I can strip it before TOPOS parses the headers. I'm not sure what to do next, I don't want to go back to TOPOH because I need the packet size savings(some users have issues with big packets ). I've seen other user-agents in the wild beyond these Aastras add Route headers in unexpected places, so this is not a single issue. I even went so far as to ask AI some help, but it just hallucinated the entire time. (AI says this should say 'I also explored AI assistance but didn't find relevant solutions for this specific scenario.' ). Any suggestions on what to do next ? Thanks, David

1 1

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

Jump to page:

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