July 2026 - sr-users - kamailio.org

Best approach for 2-node active-active Kamailio setup
by Asma BOUDDYACH 05 Aug '26

05 Aug '26

Hi , I am currently deploying a Kamailio SBC infrastructure with 2 nodes, one per datacenter, and I would like to set them up in active-active mode. I have no experience yet with multi-node Kamailio setups and I would like to ask: 1. What is the recommended approach for a 2-node active-active Kamailio deployment today? 2. What modules or mechanisms should I use to synchronize state between the two nodes (calls, registrations, etc.)? 3. Are there any known issues or limitations I should be aware of before starting the configuration? Any guidance or documentation pointers would be greatly appreciated. Best regards, -- This message and any of its attachments is intended solely for the addresses and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet cannot guarantee the integrity of this message. The INTELCIA Group shall (will) not therefore be liable for the message if modified. ——————————————— Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le détruire et d’en avertir immédiatement l’expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, même partielle, est interdite, sauf autorisation expresse. L’internet ne permettant pas d’assurer l’intégrité de ce message, le groupe INTELCIA décline toute responsabilité au titre de ce message, dans l’hypothèse où il aurait été modifié.

5 10

Getting started with Kamailio and Freeswitch
by Alex Lake 02 Aug '26

02 Aug '26

Hi all, I've been meaning to use this since it was called SER, but now is the time... I've tried to follow some guides on how to set it up. I created a user which seems to be able to REGISTER perfectly well. However, when I try to send a call, the 407 response seems to be replied to perfectly well, but it would appear that the lookup("location") function sets $rc to -3 and so Kamailio returns 404 to the INVITE. Any ideas about where to look for getting past this? Many thanks! Alex

5 9

Re: Getting started with Kamailio and Freeswitch
by airsay＠duck.com 31 Jul '26

31 Jul '26

I will just say I saw your post on Upwork On Thu, 30 Jul 2026 at 02:31, Alex Lake via sr-users < sr-users_at_lists.kamailio.org_airsay(a)duck.com> wrote: > ChatGPT suggested adding this, and it does seem to get around the problem > > if ($rU =~ "^[0-9]+$") { xlog("Routing number $rU to FreeSWITCH\n"); $du > = "sip:85.10.4.2:5090"; route(RELAY); exit; } > > So it seems that my Kamailio wasn't really setup for relaying calls > elsewhere (eg Freeswitch). Maybe some magic module missing? > > I should have said at the beginning that this was installed via a > package manager, not compiled from source. Perhaps relevant? > > > > On 29/07/2026 21:12, Alex Lake via sr-users wrote: > > Hi all, > > > > I've been meaning to use this since it was called SER, but now is the > > time... > > > > I've tried to follow some guides on how to set it up. > > > > I created a user which seems to be able to REGISTER perfectly well. > > > > However, when I try to send a call, the 407 response seems to be > > replied to perfectly well, but it would appear that the > > lookup("location") function sets $rc to -3 and so Kamailio returns 404 > > to the INVITE. > > > > Any ideas about where to look for getting past this? > > > > Many thanks! > > > > Alex > > __________________________________________________________ > > 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! > __________________________________________________________ > 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

DMQ issues and CRITICAL errors
by Sergio Charrua 31 Jul '26

31 Jul '26

Hi all, have a standard HA setup using 2 kamailio nodes (SIP 1 and SIP 2) and a VIP managed by Keepalid service. Both kamailio nodes use same configuration and while one is the Active node (where the VIP is present) the other is Backup node. Not rocket science. We use DMQ to share dialog data between nodes, using a second IP:Port address (Node 1 is .126:5062 , Node 2 is .125:5062) The VIP is .147 and SIP is listened on the VIP at .147:5060 Here is the test scenario: - SIP 1 (Active node) receives the initial INVITE, requests Routing Engine for a list of routes (uses EVAPI script who interacts with a REST service) - call is routed to egress endpoint according to the route list received - some SIP 183 is replied back and forwarded to ingress endpoint - a PRACK is received as a reply from the previous SIP 183 and kamailio forwards to egress side - *** Kamailio SIP 1 instance is stopped (service kamailio stop) **** - VIP switches to node SIP 2 - SIP 2 gets a reply SIP 200 OK from egress side (assuming a retransmission) - *** CRITICAL error is logged with : CRITICAL: {1783082372.409470 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 ACK}dialog [dlg_hash.c:1276]: next_state_dlg(): bogus event 6 in state 2 for dlg 0x7f4d7c886990 [193061:598258] with clid '48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209' and tags '*.*.12.209+2+32486fa4+25838f19' '' - *** there should be a call to EVAPI script to notify the call was answered (CALL_CONNECT notification) but there is none ----> Meanwhile i solved this, and CALL_CONNECT is sent event if there is a CRITICAL event - call seems to continue perfectly until BYE is received and a EVAPI script is notified with a CALL_FINISH request Here are the logs on SIP 1 who received the initial INVITE: Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930200]: INFO: {1783082368.672371 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: Processing INVITE from *.*.12.209:5242 to sip:+33100001209@ *.*.12.137:5242;user=phone Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930200]: INFO: {1783082368.673719 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: HANDLE_INVITE - suspended transaction for INVITE INVITE:::{"sip_invite":{"Via":"SIP/2.0/UDP *.*.12.209:5242;branch=z9hG4bK+bb3831916f972b133610a3eb7d60da343+sip+2+a65dede3","From":"\"+33000007\" <sip:+33000000012@ *.*.12.107;user=phone>;tag=*.*.12.209+2+32486fa4+25838f19","To":"<sip:+33100001209@*.*.12.137;user=phone>","CSeq":"1 INVITE","Content-Length":"175","Supported":"timer,histinfo,replaces, 100rel","P-Charging-Vector":"icid-value=1a18eec80dbf1bcaa957e9322967a9d7;orig-ioi=BICS","Contact":"<sip:+33000000012@ *.*.12.209:5242;transport=udp;user=phone>","Content-Type":"application/sdp","Call-ID":"48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209","Accept":"application/sdp, application/isup, application/dtmf,multipart/mixed","Max-Forwards":"68","Session-Expires":"1800","Min-SE":"90","P-Asserted-Identity":"\"+33000000012\" <sip:+33000000012@ *.*.12.107;user=phone>","X-REFERRED-BY":["<sip:+6436684385@sip.gcs.pstnhub.microsoft.com:5060 ;user=phone>","<sip:+6436684385@sip.gcs.pstnhub.microsoft.com:5060 ;user=phone>"],"X-tgrp":"CloudCom","X-Test":"CC_Outb_23","X-bababa-PID":"11283","X-History-Info":["<sip:+380930539504@ *.*.12.107;user=phone;cause=408>;index=1","<sip:380930539504@ *.*.12.107;user=phone;cause=486;transport=udp>;index=1.1","<sip:+3354806000999@ *.*.12.110:5060?reason=SIP%3Bcause%3D302>;index=1,<sip:+33969990333@ *.*.12.110:5060;user=phone>;index=1.1,<sip:380930539504@ *.*.12.107;user=phone;cause=481;transport=udp>;index=1.1.1,<sip:334444444444444@ *.*.12.107;user=phone;cause=481;transport=udp>;index=1.1.1.1"],"Diversion":"< sip:+3354806000@1.1.1.1 >","Allow":"INVITE,ACK,CANCEL,BYE,REGISTER,SUBSCRIBE,NOTIFY,UPDATE,OPTIONS,MESSAGE,PUBLISH","Privacy":"none","Method":"INVITE","Request-URI":"sip:+33100001209@ *.*.12.137:5242;user=phone"},"remote_ip_port":"*.*.12.209:5242","local_ip_port":" 10.242.17.147:5060 ","protocol":"udp","retry":0,"timestamp":"1783082368.672364"} Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930200]: INFO: {1783082368.673764 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: HANDLE_INVITE - suspended transaction for INVITE / CALL_ATTEMPT. Index: <null> - Label: <null> Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.749972 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: EVAPIRESPONSE - TRANSACTION 62044|1856782967 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750015 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: EVAPIRESPONSE - Resumed with RESPONSE {"action": "ROUTE", "routes": [{"tkg_eid": "101253", "crankback_profile": [{"sip_errors": ["403", "500", "503", "408", "cb_to_transit"], "next_tkg_eid": "101254"}], "dst_uri": "sip:*.*.12.209:5253", "uri": "sip:+33100001209@*.*.12.209:5253;user=phone", "headers": {"delete": null, "add": [{"P-Access-Network-Info": "GSTN;operator-specific-GI=\"011921212\";network-provided"}], "from": {"display": "+33000007", "uri": "sip:+33000000012@*.*.12.107;user=phone"}, "to": {"uri": "sip:+33100001209@*.*.12.209:5253;user=phone"}}, "max_call_duration": 43200}, {"tkg_eid": "101254", "crankback_profile": [], "dst_uri": "sip:*.*.199.167:5254", "uri": "sip:+33100001209@*.*.199.167:5254;user=phone", "headers": {"delete": null, "add": [{"P-Access-Network-Info": "GSTN;operator-specific-GI=\"011921212\";network-provided"}], "from": {"display": "+33000007", "uri": "sip:+33000000012@*.*.12.107;user=phone"}, "to": {"uri": "sip:+33100001209@*.*.199.167:5254;user=phone"}}, "max_call_duration": 43200}], "retry_on_failure": false, "max_number_of_crankbacks": 2, "version": "1.0", "method": "INVITE", "routing": "serial", "call_id": "48c1e14ce80dbdd6beacacda1aa8f79c@ *.*.12.209"} Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750121 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: EVAPIRESPONSE - ROUTE action Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750166 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: EVAPIRESPONSE - NO retry_on_failure FOUND or retry_on_failure = 0 ! Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750213 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: EVAPIRESPONSE - retry_on_failure = 0 max_number_of_crankbacks = 2 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750239 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: JSON_ROUTE_PROCESS - start retry=0 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750310 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: JSON_ROUTE_PROCESS - 2 route(s) available - max_crankbacks=2 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750419 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: APPLY_ROUTE_AND_RELAY - idx=0 - ru=sip:+33100001209@*.*.12.209:5253;user=phone du=sip:*.*.12.209:5253 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750617 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: RELAY - tkg_eid=101253 idx=0 ru=sip:+33100001209@*.*.12.209:5253;user=phone du=sip:*.*.12.209:5253 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750726 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<core> [core/kemi.c:155]: sr_kemi_core_log(): modify_invite_headers: rtjsonValue is empty, undefined or null, trying to get from $var(cur_route) Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.750974 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: PIN_SOCKET - socket is pinned 1 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.751036 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_BRANCH - initializing new branch [1] to sip:+33100001209@*.*.12.209:5253;user=phone Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930227]: INFO: {1783082368.751054 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_BRANCH - Starting monitoring counter for endpoint sip:*.*.12.209:5253 from *.*.17.147:5060 at 1783082368 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930196]: INFO: {1783082368.753932 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: onreply_route - 100 : INVITE replied from sip:*.*.12.209:5253 with SIP 100 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930196]: INFO: {1783082368.753994 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Incoming reply INVITE 100 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930196]: INFO: {1783082368.754012 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Starting monitoring counter for endpoint sip:*.*.12.209:5253 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930196]: INFO: {1783082368.754025 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Forwarding 100 Trying Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930196]: INFO: {1783082368.754033 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: RESET_FAILURE_COUNTER - resetting failure counter for sip:*.*.12.209:5253 to 0 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930195]: INFO: {1783082368.866708 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: onreply_route - 183 : INVITE replied from sip:*.*.12.209:5253 with SIP 183 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930195]: INFO: {1783082368.866815 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Incoming reply INVITE 183 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930195]: INFO: {1783082368.866835 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Starting monitoring counter for endpoint sip:*.*.12.209:5253 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930195]: INFO: {1783082368.866855 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Forwarding 180/183 Session Progress Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930195]: INFO: {1783082368.867114 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - setting Ringing Timestamp to 1783082368.866860 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930195]: INFO: {1783082368.867141 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: RESET_FAILURE_COUNTER - resetting failure counter for sip:*.*.12.209:5253 to 0 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930202]: INFO: {1783082368.876888 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 PRACK}<script>: PIN_SOCKET - socket is pinned 1 Jul 3 12:39:28 bl1649 /usr/local/sbin/kamailio[930201]: INFO: {1783082368.882525 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 PRACK}<script>: onreply_route - 200 : PRACK replied from sip:*.*.12.209:5253 with SIP 200 Jul 3 12:39:29 bl1649 /usr/local/sbin/kamailio[930202]: INFO: {1783082369.884679 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: onreply_route - 180 : INVITE replied from sip:*.*.12.209:5253 with SIP 180 Jul 3 12:39:29 bl1649 /usr/local/sbin/kamailio[930202]: INFO: {1783082369.884771 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Incoming reply INVITE 180 Jul 3 12:39:29 bl1649 /usr/local/sbin/kamailio[930202]: INFO: {1783082369.884790 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Starting monitoring counter for endpoint sip:*.*.12.209:5253 Jul 3 12:39:29 bl1649 /usr/local/sbin/kamailio[930202]: INFO: {1783082369.884815 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - Forwarding 180/183 Session Progress Jul 3 12:39:29 bl1649 /usr/local/sbin/kamailio[930202]: INFO: {1783082369.885326 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: MANAGE_REPLY - setting Ringing Timestamp to 1783082369.884822 Jul 3 12:39:29 bl1649 /usr/local/sbin/kamailio[930202]: INFO: {1783082369.885357 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: RESET_FAILURE_COUNTER - resetting failure counter for sip:*.*.12.209:5253 to 0 Jul 3 12:39:29 bl1649 /usr/local/sbin/kamailio[930201]: INFO: {1783082369.892923 930193 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 PRACK}<script>: PIN_SOCKET - socket is pinned 1 Jul 3 12:39:29 bl1649 /usr/local/sbin/kamailio[930199]: INFO: {1783082369.899687 930193 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 PRACK}<script>: onreply_route - 200 : PRACK replied from sip:*.*.12.209:5253 with SIP 200 These are the logs from SIP 2 after the VIP has switched: Jul 3 12:39:32 bl1650 /usr/local/sbin/kamailio[857997]: INFO: {1783082372.401717 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 INVITE}<script>: onreply_route - 200 : INVITE replied from sip:*.*.12.209:5253 with SIP 200 Jul 3 12:39:32 bl1650 /usr/local/sbin/kamailio[857996]: INFO: {1783082372.409421 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 ACK}<script>: TRACK_ACK - saving ACK timestamp 1783082372.409075 *Jul 3 12:39:32 bl1650 /usr/local/sbin/kamailio[857996]: CRITICAL: {1783082372.409470 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 ACK}dialog [dlg_hash.c:1276]: next_state_dlg(): bogus event 6 in state 2 for dlg 0x7f4d7c886990 [193061:598258] with clid '48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209' and tags '*.*.12.209+2+32486fa4+25838f19' ''* Jul 3 12:39:32 bl1650 /usr/local/sbin/kamailio[857996]: INFO: {1783082372.409553 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 ACK}<script>: PIN_SOCKET - stored dlg_sock=udp:10.242.17.147:5060 Jul 3 12:39:32 bl1650 /usr/local/sbin/kamailio[857996]: INFO: {1783082372.409604 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 ACK}<script>: PIN_SOCKET - forcing <udp:10.242.17.147:5060> (recv udp: 10.242.17.147:5060) Jul 3 12:39:32 bl1650 /usr/local/sbin/kamailio[857996]: INFO: {1783082372.409631 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 ACK}<script>: PIN_SOCKET - socket is pinned 0 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[858001]: INFO: {1783082382.429353 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: WITHINDLG - method is BYE - going to TRACK_BYE Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[858001]: INFO: {1783082382.429883 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: TRACK_BYE - CALLED side finished the call Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[858001]: INFO: {1783082382.429903 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: TRACK_BYE - setting ts_bye_usec 1783082382.429388 and bye_originator *.*.12.209 sent from CALLED Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[858001]: WARNING: {1783082382.429954 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: WITHINDLG - BYE detected Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[858001]: INFO: {1783082382.429982 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: PIN_SOCKET - socket is pinned 1 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[858001]: INFO: {1783082382.430041 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: MANAGE_BRANCH - initializing new branch [0] to sip:+33000000012@*.*.12.209:5242;transport=udp;user=phone Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[858001]: INFO: {1783082382.430081 857991 1 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: MANAGE_BRANCH - Starting monitoring counter for endpoint sip:*.*.12.209:5242 from 10.242.17.147:5060 at 1783082382 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.437745 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: onreply_route - 200 : BYE replied from sip:*.*.12.209:5242 with SIP 200 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: WARNING: {1783082382.437780 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: onreply_route - BYE detected Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.437800 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: onreply_route - BYE and response received Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438136 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: TRACK_BYE_200 - setting ts_bye_200ok_usec value 1783082382.437886 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438162 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: SEND_CALL_STATUS - checking call status t_check_status(200) = 200 ; method = BYE Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438392 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: SEND_CALL_STATUS - crankback_history set to [] Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438441 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: SEND_CALL_STATUS - processing BYE, checking if call was answered with t_check_status(200) = 200 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438503 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: SEND_CALL_STATUS - processing BYE, finished_by set to CALLED Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438549 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: SEND_CALL_STATUS - processing BYE, bye_time set to 1783082382.429388 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438597 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: SEND_CALL_STATUS - processing BYE, invite_ack_time set to 1783082372.409075 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438655 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: SEND_CALL_STATUS - processing BYE, bye_200_time set to 1783082382.437886 - $var(cached_ack_time)=0; Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438694 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: EV_MAKE_KEY - building event key for CALL_FINISH with hint BYE|-1 Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438924 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: EV_GUARD_ONCE - first time (CALL_FINISH) key=[48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209|CALL_FINISH] -> SEND Jul 3 12:39:42 bl1650 /usr/local/sbin/kamailio[857999]: INFO: {1783082382.438964 857991 2 48c1e14ce80dbdd6beacacda1aa8f79c(a)*.*.12.209 BYE}<script>: SEND_CALL_STATUS - sending CALL_FINISH:{"call_id":"48c1e14ce80dbdd6beacacda1aa8f79c@ *.*.12.209","from":"<sip:+33100001209@*.*.12.209:5253;user=phone>;tag=sip+2+b8f70030+683bf4af","to":"+33000007 <sip:+33000000012@ *.*.12.107;user=phone>;tag=*.*.12.209+2+32486fa4+25838f19","timestamp":"1783082382.438283","tkg_eid":"101253","remote_ip_port":"*.*.12.209:5242","local_ip_port":"*.*.17.147:5060","crankback_history":[],"finished_by":"CALLED","bye_time":"1783082382.429388","invite_ack_time":"1783082372.409075","bye_200_time":"1783082382.437886","type":"CALL_FINISH"} My question is related with the lines above that I prefixed with *** and to log lines marked with orange background and bold fonts: I understand the CRITICAL error on SIP 2 is due to the Finite State Machine (FSM) that does not expect a ACK/PRACK or 200 OK at this point, but I wonder if this is an issue for processing calls? We have been testing at 2 CAPS and this issue happens quite often. We are aiming to 2000 CAPS minimum, so the issue will be exponential and we can't go live like this, at least without knowing if there are any effects on calls. Thanks in advance. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua* *www.kahea.ai <http://www.kahea.ai> / www.voip.pt <http://www.voip.pt>* *OpenTelecom* - Consulting for Telecoms, Lda Tel.: +351 <callto:+351+91+104+12+66>91 631 11 44 Email : *sergio.charrua(a)voip.pt <sergio.charrua(a)voip.pt>* This message and any files or documents attached are strictly confidential or otherwise legally protected. It is intended only for the individual or entity named. If you are not the named addressee or have received this email in error, please inform the sender immediately, delete it from your system and do not copy or disclose it or its contents or use it for any purpose. Please also note that transmission cannot be guaranteed to be secure or error-free.

3 11

uac_replace_from not woring as expected
by Benoît Panizzon 17 Jul '26

17 Jul '26

Hi Team I seem not to quite understand, how uac_replace_from() works. Simplified what I do: loadmodule "uac.so" and restore URI username changes modparam("uac", "restore_dlg", 1) modparam("uac","restore_mode","auto") Very early in request_route: dlg_manage(); On the branch route towards the customer I do: if (is_privacy("id")) { uac_replace_from("\"Anonymous\"","sip:anonymous@anonymous.invalid"); } The INVITE ist correctly sent From: Anonymous. Destination ist ringing. Caller issues BYE before destination picks up. BYE contains the unaltered number instead of anonymous in the From: Header, thus the callerId would be revealed to a customer recording a sip trace. Isn't the From Username in the BYE supposed to get replaced by the UAC hook installed in the dialogue during the INVITE? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- 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 ______________________________________________________

3 10

Possible typo in topos dialog_expire documentation
by xf han 15 Jul '26

15 Jul '26

Hello, I noticed a possible typo in the documentation for the topos module: https://kamailio.org/docs/modules/6.1.x/modules/topos.html#topos.p.dialog_e… In the description of the dialog_expire parameter, it says: Default value is 10800 (3 hours). Could someone please confirm whether this value/text is correct? Thanks!

2 2

dialog module: log_write_cdr() creating duplicate entries
by Benoit Panizzon 10 Jul '26

10 Jul '26

Hi Team Kamailio 5.8 We notices, in rare occurences, we get duplicate, sometimes even trippe CDR entries for the same call generated by the dialog modules. When looking at kamailio.log there is no error, log_write_cdr() As we use those CDR for billing, it is very important for us to get correct CDRs. We us dbcluster functionality on MySQL and have a primary database and a local 'fallback' database. Is there anything known which may duplicate CDR? 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

Memory leak in xhttp (from commit 8da785b6)
by James Browne 08 Jul '26

08 Jul '26

Hi I see this commit from last month causing a small/slow memory leak in the worker(s) reserved for HTTP requests. - https://github.com/kamailio/kamailio/commit/8da785b61c6dd02e15790999aa342e2… This commit changed this line to this in xhttp_mod.c‎. - pkg_free(tbuf.s); + tbuf.s = NULL; I've tested kamailio built from this commit and from the previous one, and the leak happens only with this commit. It also happens with the latest commit from master branch (92114a6c30e0ba22a176c6cd762b99716c301cec). The problem is that, after some time, prometheus metrics over HTTP stop working due to the worker not being able to find a block of memory (of size 1/3 of the PKG mem) in which to work, and metrics fail with a HTTP-500 response. 2026-07-04T10:50:09.699744000Z 206(1331) ERROR: <core> [core/mem/f_malloc.c:435]: fm_search_defrag(): fm_search_defrag(0x755b29351010, 5592416); Free fragment not found! 2026-07-04T10:50:09.699910000Z 206(1331) ERROR: <core> [core/mem/f_malloc.c:528]: fm_malloc(): fm_malloc(0x755b29351010, 5592416) called from xhttp_prom: xhttp_prom.c: init_xhttp_prom_reply(442), module: xhttp_prom; Free fragment not found! 2026-07-04T10:50:09.700008000Z 206(1331) ERROR: xhttp_prom [xhttp_prom.c:444]: init_xhttp_prom_reply(): could not allocate private memory from pkg pool 2026-07-04T10:50:09.700061000Z 206(1331) ERROR: xhttp_prom [prom.c:81]: prom_body_printf(): Error body buffer overflow: 23 (0) 2026-07-04T10:50:09.700108000Z 206(1331) ERROR: xhttp_prom [prom_metric.c:2048]: prom_metric_list_print(): Fail to print 2026-07-04T10:50:09.700151000Z 206(1331) ERROR: xhttp_prom [prom.c:354]: prom_stats_get(): Fail to print user defined metrics I see the evidence with the kamcmd pkg.stats command, where I see the "used" and "real_used" memory creep up steadily as I make repeated (thousands of) HTTP requests for metrics. Here's a sample kamailio.cfg file that I used during testing. #!KAMAILIO loadmodule "sl" loadmodule "kex" loadmodule "xhttp" loadmodule "xhttp_prom" loadmodule "ctl" modparam("ctl", "binrpc", "unix:/var/run/kamailio/kamailio_ctl") tcp_accept_no_cl=yes socket_workers=2 listen=tcp:11.15.32.160:9090 event_route[xhttp:request] { prom_dispatch(); } For now, I build kamailio, so I can patch this as I build. I expect this is going to cause problems for other users, though. Should I open a github issue for this? I've never opened one before, so this might be good practice. James

2 2

Best approach for 2-node active-active Kamailio setup
by asma.bouddyach＠intelcia.com 08 Jul '26

08 Jul '26

Hi , I am currently deploying a Kamailio SBC infrastructure with 2 nodes, one per datacenter, and I would like to set them up in active-active mode. I have no experience yet with multi-node Kamailio setups and I would like to ask: 1. What is the recommended approach for a 2-node active-active Kamailio deployment today? 2. What modules or mechanisms should I use to synchronize state between the two nodes (calls, registrations, etc.)? 3. Are there any known issues or limitations I should be aware of before starting the configuration? Any guidance or documentation pointers would be greatly appreciated. Best regards,

1 0

Missing documentation for KSR.pv.geti("pvname") in KEMI KSR.pv module
by xf han 08 Jul '26

08 Jul '26

Hi, I found the documentation for the KSR.pv submodule here: https://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/core/#ksr… However, it seems that KSR.pv.geti(str "pvname") is missing from the documentation. Could this function be added to the documentation? Thanks!

1 0