- sr-users - kamailio.org

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

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

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

Best approach for 2-node active-active Kamailio setup
by Asma BOUDDYACH 09 Jul '26

09 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, -- 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 8

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

6.0.5 Teams Direct Routing SBC: inbound 400 cause=95 + outbound 2xx ACK not completing (dual-transport TLS/UDP record_route_preset)
by George Hanousek 08 Jul '26

08 Jul '26

Hello, Kamailio 6.0.5 (distro packages) on Ubuntu 26.04 as an SBC between Microsoft Teams Direct Routing (TLS/5061) and Twilio Elastic SIP Trunking (UDP/5060), RTPEngine 13.5.1 bridging SRTP<->RTP (userspace, table=-1). Outbound (Teams->Twilio) negotiates fully and rings; two symptoms remain that I suspect share a Record-Route / dual-transport root. ENVIRONMENT - SBC FQDN sbc.ms-teams-dev.intiveo.com - Public IP 108.132.63.71 (UDP/TCP 5060 to Twilio) - Private IP 10.0.0.164 (TLS 5061 to Teams, advertised as FQDN) - TLS 1.2, LetsEncrypt cert + custom CA bundle (outbound TLS to sip.pstnhub.microsoft.com validates fine; calls reach Teams) - listen=udp:10.0.0.164:5060 advertise 108.132.63.71:5060 - listen=tcp:10.0.0.164:5060 advertise 108.132.63.71:5060 - listen=tls:10.0.0.164:5061 advertise sbc.ms-teams-dev.intiveo.com:5061 SYMPTOM 1 - OUTBOUND (Teams->Twilio): rings, cannot be answered. On answer, Twilio's 200 OK retransmits every 4s and is never confirmed; the ACK from Teams does not complete back to Twilio. The outbound INVITE to Twilio leaves over UDP from the public IP, but the first inserted Record-Route is transport=tls: Record-Route: <sip:sbc.ms-teams-dev.intiveo.com:5061 ;transport=tls;ftag=...;lr=on> Record-Route: <sip:10.0.0.164:5060;ftag=...;lr=on> sngrep of the outbound call (Teams answered ~09:19:48): INVITE (SDP) 10.0.0.164:5060 -> 54.172.60.3:5060 100 trying <- 183 Session prog. <- (rings) 200 OK (SDP) <- (answered) INVITE (SDP) -> (re-INVITE/ACK path) 200 OK <- 100 trying <- 200 OK (SDP) <- 183 Session prog. <- 200 OK (SDP) <- } 200 OK repeats every ~4s, never ACKed 200 OK (SDP) <- } CANCEL -> 200 canceling <- 487 Request Term. <- ACK -> SYMPTOM 2 - INBOUND (Twilio->Teams): the forwarded INVITE reaches Teams over TLS, and Teams returns: SIP/2.0 400 Bad Request Reason: Q.850;cause=95;text="Invalid unknown header: Cannot add a parameter known to SipUri as a generic parameter" The Teams client never rings. I have tried removing a hand-built Contact header and setting uac restore_mode=none; neither changed the cause=95. QUESTIONS 1. With one UDP listen (public IP) and one TLS listen (private IP, advertised FQDN), is record_route_preset() the correct approach, or does the dual-transport case need record_route() with per-leg handling so the 2xx ACK bridges TLS->UDP? Is the transport=tls on the first RR entry causing the ACK to come back on the wrong leg? 2. For the inbound cause=95, which header/parameter is Teams objecting to with this config? FULL kamailio.cfg BELOW: #!KAMAILIO #!define WITH_TLS #!substdef "!MY_PUB_IP!108.132.63.71!g" #!substdef "!MY_PRIV_IP!10.0.0.164!g" #!substdef "!MY_FQDN!sbc.ms-teams-dev.intiveo.com!g" #!substdef "!TWILIO_TRUNK!intiveo-ms-teams-dev.pstn.twilio.com!g" debug=2 log_stderror=no fork=yes children=2 auto_aliases=no listen=udp:MY_PRIV_IP:5060 advertise MY_PUB_IP:5060 listen=tcp:MY_PRIV_IP:5060 advertise MY_PUB_IP:5060 listen=tls:MY_PRIV_IP:5061 advertise MY_FQDN:5061 enable_tls=yes tcp_connection_lifetime=3605 tls_max_connections=2048 loadmodule "tm.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "textopsx.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "tls.so" loadmodule "rtpengine.so" loadmodule "uac.so" loadmodule "dispatcher.so" modparam("tls", "config", "/etc/kamailio/tls.cfg") modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223") modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 1) modparam("uac", "restore_mode", "none") modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_probing_threshold", 3) modparam("dispatcher", "ds_inactive_threshold", 3) modparam("dispatcher", "ds_probing_mode", 1) request_route { if (!($si=="54.172.60.0" || $si=="54.172.60.1" || $si=="54.172.60.2" || $si=="54.172.60.3" || $si =~ "^52\.11[2-5]\." || $si =~ "^52\.12[0-3]\.")) { xlog("L_WARN","Drop SIP from untrusted $si\n"); sl_send_reply("403","Forbidden"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if (has_totag()) { if (loose_route()) { route(RELAY); exit; } sl_send_reply("404","Not Here"); exit; } if (is_method("ACK")) { if (t_check_trans()) { route(RELAY); } exit; } if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } if (is_method("OPTIONS")) { sl_send_reply("200","OK"); exit; } if (!is_method("INVITE")) { sl_send_reply("405","Method Not Allowed"); exit; } record_route_preset("sbc.ms-teams-dev.intiveo.com:5061;transport=tls", " 10.0.0.164:5060"); if ($si =~ "^52\.11[2-5]\." || $si =~ "^52\.12[0-3]\.") { route(TO_TWILIO); } else { route(TO_TEAMS); } exit; } route[TO_TWILIO] { rtpengine_manage("replace-origin replace-session-connection RTP"); sethostport("intiveo-ms-teams-dev.pstn.twilio.com:5060"); $du = "sip:TWILIO_TRUNK:5060;transport=udp"; route(RELAY); } route[TO_TEAMS] { rtpengine_manage("replace-origin replace-session-connection SRTP"); sethostport("sip.pstnhub.microsoft.com:5061"); uac_replace_from("sip:$fU@MY_FQDN"); $du = "sip:sip.pstnhub.microsoft.com:5061;transport=tls"; t_on_failure("TEAMS_FAILOVER"); route(RELAY); } route[RELAY] { if (is_method("INVITE")) { t_on_reply("MANAGE_REPLY"); } if (!t_relay()) { sl_reply_error(); } exit; } failure_route[TEAMS_FAILOVER] { if (t_is_canceled()) { exit; } if (t_check_status("503|408") || t_branch_timeout()) { if ($avp(tdc) == $null) { $avp(tdc) = 1; $du = "sip:sip2.pstnhub.microsoft.com:5061;transport=tls"; t_on_failure("TEAMS_FAILOVER"); t_relay(); exit; } else if ($avp(tdc) == 1) { $avp(tdc) = 2; $du = "sip:sip3.pstnhub.microsoft.com:5061;transport=tls"; t_relay(); exit; } } } onreply_route[MANAGE_REPLY] { if (status =~ "[12][0-9][0-9]") { rtpengine_manage(); } } event_route[tm:local-request] { if (is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com") { append_hf("Contact: <sip:sbc.ms-teams-dev.intiveo.com:5061 ;transport=tls>\r\n"); } } (tls.cfg uses method=TLSv1.2, server+client sections both with the LetsEncrypt cert/key and a custom CA bundle including DigiCert Global Root CA. dispatcher.list has the three pstnhub proxies, setid 1, with socket=tls:10.0.0.164:5061;ping_from=sip:sbc.ms-teams-dev.intiveo.com.) Thanks for any pointers. George

3 5

Multihomed server not handling dialog's BYE
by agiftel＠gmail.com 03 Jul '26

03 Jul '26

Hi all, trying to understand what is not working on my conf, without luck. Can you help me? Issue: as title says, incoming BYE of a dialog are not processed because "loose_route()" function always fails (FALSE). So server always reply with 404 Not Here. I cannot understand why loose_route fails. Kam server has 2 NICs: LAN: 192.168.1.3 that see Asterisk (192.168.1.200) DMZ: 10.0.1.3 advertised public_ip Incoming BYE has Route: header. See below 2026/07/01 10:28:16.935119 52.114.75.24:12229 -> 10.0.1.3:5061 BYE sip:sbc-kam-teams.domain.eu:5061;transport=tls SIP/2.0 From: <sip:+390313527380@sip.pstnhub.microsoft.com:5061;user=phone>;tag=9e168a8cac924f5395732f051b56231c To: <sip:101@sbc-kam-teams.domain.eu>;user=phone;tag=633e9a76-b8c2-4869-96a8-c1ab18bf5bea Via: SIP/2.0/TLS 52.114.75.24;branch=z9hG4bK4778a595 CSeq: 2 BYE Call-ID: c04608351d6d5b98bd8b11e94070721b Max-Forwards: 70 Route: <sip:sbc-kam-teams.domain.eu:5061;lr;r2=on;ftag=9e168a8cac924f5395732f051b56231c;did=1db.ba12;transport=Tls>,<sip:192.168.1.3;lr;r2=on;ftag=9e168a8cac924f5395732f051b562 31c;did=1db.ba12> Reason: Q.850;cause=16;text="d4c62fdd-5df8-4791-9bf8-76bfd638e2bf;CallEndReasonLocalUserInitiated" Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS Contact: <sip:api-du-b-euwe.pstnhub.microsoft.com:443;x-i=d4c62fdd-5df8-4791-9bf8-76bfd638e2bf;x-c=c04608351d6d5b98bd8b11e94070721b/d/8/aeb7a7f3b4114b1e82f8ca7efdaa7581> Content-Length: 0 User-Agent: Microsoft.PSTNHub.SIPProxy v.2026.6.29.3 i.EUWE.10 Here last 200 Ok sent from kamailio to Teams: 2026/07/01 10:28:15.288945 10.0.1.3:5061 -> 52.114.75.24:12228 SIP/2.0 200 OK Via: SIP/2.0/TLS 52.114.75.24;rport=12228;branch=z9hG4bKb419a3e8 Record-Route: <sip:192.168.1.3;lr;r2=on;ftag=9e168a8cac924f5395732f051b56231c;did=1db.ba12> Record-Route: <sip:sbc-kam-teams.acscloud.eu:5061;transport=tls;lr;r2=on;ftag=9e168a8cac924f5395732f051b56231c;did=1db.ba12> Record-Route: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr> Call-ID: c04608351d6d5b98bd8b11e94070721b From: <sip:+390313527380@sip.pstnhub.microsoft.com;user=phone>;tag=9e168a8cac924f5395732f051b56231c Contact: <sip:sbc-kam-teams.acscloud.eu:5061;transport=tls> Server: SBC-Montefato To: <sip:101@sbc-kam-teams.acscloud.eu;user=phone>;tag=633e9a76-b8c2-4869-96a8-c1ab18bf5bea CSeq: 1 INVITE Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, INFO, REFER Supported: 100rel, timer, replaces, norefersub Session-Expires: 3600;refresher=uac Require: timer Content-Type: application/sdp Content-Length: 279 v=0 o=- 29979 2 IN IP4 128.116.144.30 s=Asterisk t=0 0 m=audio 32902 RTP/SAVP 8 c=IN IP4 128.116.144.30 a=mid:1 a=rtpmap:8 PCMA/8000 a=sendrecv a=rtcp:32903 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LX+X3mOVOEA1ceqba0xNXAEINQ7C7E/ro8Qxjt8g a=ptime:20 a=maxptime:140 Here you can find my entire conf: https://pastebin.com/Bz7cRiv0

5 7

Best Practice for Real-Time Media Forking/SIPREC in an Inline B2BUA Hairpin Setup (KEMI/Python)
by Kidas Developer 02 Jul '26

02 Jul '26

Hello Kamailio Community, I am looking for the best practice or native method to implement real-time media forking/forwarding directly from our proxy/media layer to an external Python/FastAPI service, keeping the architecture completely clear of any intermediary PBX engines. Our Environment - *OS:* Ubuntu 24.04 LTS - *Kamailio Version:* 6.1.3 (x86_64/Linux) running the Python KEMI engine ( kamailio.py) - *RTPEngine Version:* 26.2.0.0+0~mr26.2.0.0 Our Scenario We have a fully working signaling hairpin configuration handled inside kamailio.py. A call arrives from our carrier gateway, loops through our proxy framework, and terminates to the customer gateway, with media successfully anchored via RTPEngine. The Objective We need to passively replicate/fork a twin stream of the live full-duplex voice packets directly over the network via UDP or TCP to an asynchronous socket listener on our backend Python application. We want this to happen completely in real-time, with zero disk-spooling/file-writing dependencies. Our Questions: 1. *RTPEngine Network Replication:* Given that we are on RTPEngine 26.2, is there a native control flag or parameter inside the daemon protocol to replicate and push live UDP streams straight to an external network target ( IP:Port)? 2. *Kamailio Native Alternatives:* If RTPEngine cannot forward packets directly over the network to a raw socket, are there specific Kamailio 6.1.3 modules or KEMI-exported functions we should utilize to capture and mirror the live RTP streams down to our Python service? We are trying to keep this pipeline as lightweight and bare-metal as possible (Kamailio + RTPEngine + Python). Any guidance, architectural patterns, or module recommendations to achieve this clean proxy-to-application streaming would be immensely appreciated. Thank you for your time!

4 3