sr-users July 2025

sr-users@lists.kamailio.org

56 participants
51 discussions

No audio Over VPN
by Fernando Lopes 31 Jul '25

31 Jul '25

Hello everyone, I'm having some issues with SIP when the VPN is active. I'm running a Docker container inside WSL. My WSL IP is 172.31.217.74, and my machine's IP is 192.168.1.77. When I connect to the VPN, I get the IP 192.168.1.129. When I place a call, I see this log. I've tried disabling ICE, setting the public IP of the SIP server in MicroSIP, and manually specifying my local machine IP. This does change the c= and a= parameters in the SDP, but it still doesn't work. Everything works fine without the VPN. I need the VPN active to access certain endpoints, but SIP stops working once it's connected. INVITE sip:100@localhost;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.31.208.1:54367;rport;branch=z9hG4bKPjb591721e91454d2bae56a9edfc645ebe;alias Max-Forwards: 70 From: "6001" <sip:6001@localhost>;tag=daa078657d2949e68935f308beeb8b89 To: <sip:100@localhost> Contact: "6001" <sip:6001@172.31.208.1:54367;transport=TCP;ob>;+sip.ice Call-ID: 49c169a9e92d4b23ad70709636ccab4f CSeq: 13400 INVITE Route: <sip:172.31.217.74;transport=tcp;lr> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.21.6 Content-Type: application/sdp Content-Length: 1345 v=0 o=- 3962710251 3962710251 IN IP4 192.168.1.129 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4030 RTP/AVP 8 0 96 97 98 9 99 100 101 102 103 c=IN IP4 192.168.1.129 b=TIAS:64000 a=rtcp:4001 IN IP4 192.168.1.129 ... a=ice-ufrag:1d266809 a=ice-pwd:2f7e2ef6047a47d832ed0f55 a=candidate:Hc0a80181 1 UDP 2130706431 192.168.1.129 4030 typ host a=candidate:Hc0a8014d 1 UDP 2130706175 192.168.1.77 4030 typ host a=candidate:Hc0a83801 1 UDP 2130705919 192.168.56.1 4030 typ host a=candidate:Hac1fd001 1 UDP 2130705663 172.31.208.1 4030 typ host a=candidate:Hc0a80181 2 UDP 2130706430 192.168.1.129 4001 typ host a=candidate:Hc0a8014d 2 UDP 2130706174 192.168.1.77 4001 typ host a=candidate:Hc0a83801 2 UDP 2130705918 192.168.56.1 4001 typ host a=candidate:Hac1fd001 2 UDP 2130705662 172.31.208.1 4001 typ host Does anyone know where the problem may be?

4 5

kamailio 5.8.6 sanity problem
by ale Gural 31 Jul '25

31 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

4 8

Postgres connections optimization #4342
by Stephane Savonitto 30 Jul '25

30 Jul '25

Hello, On P-CSCF when running we have 200+ permanent connection to postgres db, even if there is no traffic. Is there a way to manage connections dynamically using a pool like using PgBouncer ? Regards, Stéphane

5 8

Kamailio DNS functions available for HTTP too?
by Sergio Charrua 29 Jul '25

29 Jul '25

Hi all, I was looking at the following document kamailio/doc/tutorials/dns.txt at master · kamailio/kamailio <https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt> and wondering if these functionalities are only available for SIP (as it mentions TM module) or can they be used also for HTTP Requests, using HTTP Async Client module. Can anyone clarify ? The final goal is to have HTTP Async Requests sent to a domain name that can resolve to the next available IP address of the HTTP server (for failover): if address #1 is down, send the http request to the next available server. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

1 0

reading out "response" and "integrity-protected" from "Authorization" header field
by Valentin Christoph 29 Jul '25

29 Jul '25

Hi all, Again an IMS question. The 3GPP TS 24.229 specifies some additional parameters for the "Authorization" header field in REGISTER requests, e.g. the "integrity-protected" parameter and the "response" parameter. Now the question: is it the only way to read out these parameters from the "Authorization" header field, by implementing new pseudo variables, e.g. $aip and $are, or is there an easy way using $hdr() from the configuration? I want to avoid sophisticated regular expressions. Thanks, Christoph

2 1

Unable to find MOH files
by 17603019528＠163.com 28 Jul '25

28 Jul '25

Hi everyone When I use the mohqueue module, I get the following error message: ``` 0(7901) ERROR: mohqueue [mohq_db.c:484]: update_mohq_lst(): Queue,Field (abc,mohdir): Unable to find MOH files (/var/kamailio/MOH//HeWillCall.8.*)! 0(7901) ERROR: mohqueue [mohqueue_mod.c:400]: mod_init(): Unable to load rtpproxy_answer! 0(7901) ERROR: <core> [core/sr_module.c:1039]: init_mod(): Error while initializing module mohqueue (/usr/local/lib64/kamailio/modules/mohqueue.so) ``` here is the audio file: ``` ll /var/kamailio/MOH/HeWillCall.8 -rwxrwxrwx. 1 root root 550080 Jul 28 13:53 /var/kamailio/MOH/HeWillCall.8 ``` kamailio version: kamailio 5.8.5 (x86_64/linux)

4 4

Re: Delivery Status Notification (Delay)
by palany 26 Jul '25

26 Jul '25

XxSent from my Galaxy -------- Original message --------From: David Villasmil via sr-users <sr-users(a)lists.kamailio.org> Date: 09/07/2025 18:09 (GMT+02:00) To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Cc: David Villasmil <david.villasmil.work(a)gmail.com> Subject: [SR-Users] Re: Delivery Status Notification (Delay) i'm seeing this for some reason, anyone knows why?Regards,David Villasmilemail: david.villasmil.work(a)gmail.comOn Wed, Jul 9, 2025 at 3:34 PM Mail Delivery Subsystem <mailer-daemon(a)googlemail.com> wrote: Delivery incomplete There was a temporary problem delivering your message to users(a)lists.openser.org. Gmail will retry for 21 more hours. You'll be notified if the delivery fails permanently. The response from the remote server was: 454 4.7.1 : Relay access denied ---------- Forwarded message ----------From: David Villasmil <david.villasmil.work(a)gmail.com>To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>, openser users <users(a)lists.openser.org>Cc: Bcc: Date: Mon, 7 Jul 2025 12:44:38 +0200Subject: Stir/ShakenHello,I've seen people wondering how to implement Stir/shaken on Kamailio and OpenSIPS. It occurred to me that making a docker image would help a lot of people so I did. You can find it in https://hub.docker.com/repository/docker/davidcsi/kamailio-stirshaken/gener… and in the description you can read how it works and how to use it.Hope it helps! David Villasmilemail: david.villasmil.work(a)gmail.com

1 0

Error: receive_fd(): EOF on 18
by Fernando Lopes 25 Jul '25

25 Jul '25

Hello everyone, I'm getting this during start up error and I can't figure out what it means. I've searched for a solution but haven't found anything relevant. Also I don't see any useful debug messages during to complement this error. 19(61) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 18 0(2) ALERT: <core> [main.c:792]: handle_sigs(): child process 49 exited by a signal 11 0(2) ALERT: <core> [main.c:796]: handle_sigs(): core was generated 0(2) INFO: <core> [main.c:819]: handle_sigs(): terminating due to SIGCHLD Any tips for debugging or finding the problem. Thank you.

3 4

Re: [sr-dev] git:master:79f6439f: tls: added support for tls keys log
by Sergei Safarov 24 Jul '25

24 Jul '25

I think exist is more elegant way to export encyptions keys to the file Need to start Kamailio with defined SSLKEYLOGFIL=/path/here/to/file environment variable This I have tested for TLS 1.2 and TLS 1.3. All works perfectly More details you can find at https://www.youtube.com/watch?v=Cq6yj9se9M4&t=1850s Probable this change do not required because allow secret keys to logs. On Thu, 2025-07-24 at 12:42 +0200, Daniel-Constantin Mierla via sr-dev wrote: > Module: kamailio > Branch: master > Commit: 79f6439f16f6b715858414689c7c04cf22164ace > URL: > https://github.com/kamailio/kamailio/commit/79f6439f16f6b715858414689c7c04c… > > Author: Daniel-Constantin Mierla <miconda(a)gmail.com> > Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> > Date: 2025-07-24T12:28:13+02:00 > > tls: added support for tls keys log > > - they can be printed to syslog (NOTICE level) or file > > --- > > Modified: src/modules/tls/tls_domain.c > Modified: src/modules/tls/tls_mod.c > Modified: src/modules/tls/tls_util.c > Modified: src/modules/tls/tls_util.h > > --- > > Diff: > https://github.com/kamailio/kamailio/commit/79f6439f16f6b715858414689c7c04c… > Patch: > https://github.com/kamailio/kamailio/commit/79f6439f16f6b715858414689c7c04c… > > _______________________________________________ > Kamailio - Development Mailing List -- sr-dev(a)lists.kamailio.org > To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only > to the sender!

1 0

Error: different number of preprocessor directives
by Fernando Lopes 24 Jul '25

24 Jul '25

Hello everyone, I'm having an issue with my Kamailio config where I'm getting the following error: ERROR: bad config file (0 errors) (parsing code: 0) 0(2) ERROR: <core> [core/ppcfg.c:276]: pp_ifdef_level_error(): different number of preprocessor directives: 1 more #!if[n]def as #!endif I've gone through the config up and down so many times and can't seem to find the problem. I have a definitions.cfg file where I define all the variables, and I’ve made sure that every #!ifdef WITH_SOMETHING has a corresponding definition. I also ran this command (recommended by GPT): grep -E '#!ifn?def|#!endif' /usr/local/etc/kamailio/kamailio.cfg It shows matching numbers of #!ifdef and #!endif, and I’ve checked it manually several times — everything looks fine. Any tips for debuging or finding the problem. #!ifdef WITH_CDRS #!endif #!ifdef WITH_DEBUG #!endif #!ifdef WITH_TLS #!endif #!ifdef WITH_NAT #!endif #!ifdef WITH_TLS #!endif #!ifdef WITH_FAIL2BAN #!ifdef WITH_ANTIFLOOD #!endif #!endif #!ifdef WITH_DISPATCHER #!endif #!ifdef WITH_RESPONSE_STATS #!endif #!ifdef WITH_HOMER #!endif #!ifdef WITH_CDRS #!endif #!ifdef WITH_RTPENGINE #!endif #!ifdef WITH_HTTP #!endif #!ifdef WITH_WEBSOCKETS #!endif #!ifdef WITH_NAT #!ifdef WITH_RTPENGINE #!endif #!endif #!ifdef WITH_TLS #!endif #!ifdef WITH_ANTIFLOOD #!endif #!ifdef WITH_FAIL2BAN #!endif #!ifdef WITH_DISPATCHER #!endif #!ifdef WITH_HOMER #!endif #!ifdef WITH_CDRS #!endif #!ifdef WITH_FAIL2BAN #!endif #!ifdef WITH_RTPENGINE #!endif #!ifdef WITH_HOMER #!endif #!ifdef WITH_RTPENGINE #!endif #!ifdef WITH_ANTIFLOOD #!endif #!ifdef WITH_NATSIPPING #!endif #!ifdef WITH_NOAUTH_PRIVATE_NET #!endif #!ifdef WITH_AUTH #!endif #!ifdef WITH_NAT #!endif #!ifdef WITH_NAT #!endif #!ifdef WITH_NAT #!endif #!ifdef WITH_RTPENGINE #!endif #!ifdef WITH_DISPATCHER #!endif #!ifdef WITH_WEBSOCKETS #!endif #!ifdef WITH_HTTP #!ifdef WITH_WEBSOCKETS #!endif #!endif #!ifdef WITH_RTPENGINE #!endif Thank you.

7 7

2026

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