- sr-users - kamailio.org

extreme dildoes
by feigelwang＠uusextoy.com 26 Aug '23

26 Aug '23

So, when you still are alone, buying a huge dildo is worth it. Enjoy sex with the huge realistic dildo anytime and anywhere. Not only that, the big dildo brings completely different sexual stimulation. Maybe you want to enjoy full sex, should try some other sex toys.https://www.hugedildo.com/

1 0

rtpengine large number used RTP ports
by marek 25 Aug '23

25 Aug '23

hi, i have open around ~8000 rtp ports for around ~200calls (in peak) with this statistic (current data, not from peak) rtpengine_closed_sessions_total{reason="rejected"} 0 rtpengine_closed_sessions_total{reason="timeout"} 237405 rtpengine_closed_sessions_total{reason="silent_timeout"} 103 rtpengine_closed_sessions_total{reason="final_timeout"} 0 rtpengine_closed_sessions_total{reason="offer_timeout"} 0 rtpengine_closed_sessions_total{reason="terminated"} 0 rtpengine_request_seconds_total{proxy="127.0.0.1",request="offer"} 539.270967 rtpengine_request_seconds_total{proxy="127.0.0.1",request="answer"} 367.237641 rtpengine_request_seconds_total{proxy="127.0.0.1",request="delete"} 0.000000 is it normal? (large number of timeouts, "zero" terminated) or i have missing rtpengine_manage (rtpengine_delete) somewhere? (os rocky 9.2, kamailio 5.6.4, rtpengine 11.3.1) thanks Marek

2 3

excessive CANCELs
by James Lipski 23 Aug '23

23 Aug '23

Hello, I've already suppressed this via routing logic, however I was wondering if there is a dedicated parameter that handles this. I'm currently running version 5.6.4. Scenario: UA-1 registered towards kamailio, calls UA-2 which is registered towards a different platform (non kamailio); so there are 2 proxys involved. kamailio is set to fork the call to voicemail if there is either no response completely from the other end, or the call goes unanswered. So the initial leg is: UA-1 <-----> kamailio <-----> second proxy <-----> UA-2 Issue: I'm trying to catch a case where the second proxy does issue a "100 Trying" for the initial INVITE; and then timesout. The call does fork to voicemail; however 14000+ SIP packets are generated between kamailio and the second proxy of CANCEL and "100 Trying" (the 100 Trying has a CSeq for INVITE still). Is there a way to suppress the amount of CANCELs that is transmitted in this situation? I'm using the following as my "tm" parameters: modparam("tm", "failure_reply_mode", 3) modparam("tm", "fr_timer", 30000) modparam("tm", "fr_inv_timer", 300000) modparam("tm", "auto_inv_100_reason", "Trying") Thanks. Example SIP trace: (UA-1 --> kamailio) 72.255.255.255 --> 10.64.52.110 INVITE sip:131@sip-example.com SIP/2.0 v: SIP/2.0/UDP 10.0.0.102:51519;branch=z9hG4bK-xfelmyyjzne5;rport f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Max-Forwards: 70 User-Agent: snomD785/10.1.152.12 m: <sip:133@10.0.0.102:51519;line=6dv00d6r>;reg-id=1 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, replaces, from-change Session-Expires: 3600 Min-SE: 90 Proxy-Authorization: Digest username="133",realm="sip-example.com",nonce="ZOTEBGTkwtiM22ZE8IJsn/esiW3CZrt0"[,uri="sip:131@sip-example.com](mailto:,uri=)",response="fb44b4fe0f8fb17de13f043cf1248e14",algorithm=MD5 c: application/sdp l: 309 v=0 o=root 481174289 481174289 IN IP4 10.0.0.102 s=call c=IN IP4 10.0.0.102 t=0 0 m=audio 50864 RTP/AVP 9 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv -------------------------------------------- (UA-1 <-- kamailio) 72.255.255.255 <-- 10.64.52.110 SIP/2.0 100 Trying v: SIP/2.0/UDP 10.0.0.102:51519;branch=z9hG4bK-xfelmyyjzne5;rport=51519;received=72.255.255.255 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Content-Length: 0 -------------------------------------------- (kamailio --> second proxy) 10.64.52.110 --> 10.64.52.100 INVITE sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7 SIP/2.0 Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Max-Forwards: 15 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, replaces, from-change Session-Expires: 3600 Min-SE: 90 c: application/sdp l: 313 Contact: <sip:leg_1@sip-example.com;ccr=btpsh-64e387e0-ee528-2> v=0 o=root 481174289 481174289 IN IP4 10.64.52.111 s=call c=IN IP4 10.64.52.111 t=0 0 m=audio 34084 RTP/AVP 9 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv -------------------------------------------- (kamailio <-- second proxy) 10.64.52.110 <-- 10.64.52.100 SIP/2.0 100 Trying v: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE l: 0 -------------------------------------------- After 10 seconds of no further response from second proxy, call is forked to voicemail (kamailio --> voicemail) 10.64.52.110 --> 10.64.56.10 INVITE sip:voicemail@voicemail-example.com SIP/2.0 Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.1 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Max-Forwards: 15 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, replaces, from-change Session-Expires: 3600 Min-SE: 90 c: application/sdp l: 313 Contact: <sip:leg_1@sip-example.com;ccr=btpsh-64e387e0-ee533-3> v=0 o=root 481174289 481174289 IN IP4 10.64.52.111 s=call c=IN IP4 10.64.52.111 t=0 0 m=audio 38722 RTP/AVP 9 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv -------------------------------------------- At roughly the same time, CANCEL is issued towards the second proxy (kamailio --> second proxy) 10.64.52.110 --> 10.64.52.100 CANCEL sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7 SIP/2.0 Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com> i: 95c3e4642670-rx28v46dte4p CSeq: 1 CANCEL Max-Forwards: 15 l: 0 -------------------------------------------- (kamailio <-- voicemail) 10.64.52.110 <-- 10.64.56.10 SIP/2.0 200 Ok Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.1 From: <sip:133@sip-example.com>;tag=i4mlq4jr0y To: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>;tag=vzx5x3mlbd Call-ID: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Contact: <sip:voicemail@10.64.56.10:5078> Require: timer Session-Expires: 3600;refresher=uac Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Supported: timer, 100rel, replaces Content-Type: application/sdp Content-Length: 264 v=0 o=root 1084843702 1084843703 IN IP4 10.64.56.10 s=call c=IN IP4 10.64.56.10 t=0 0 m=audio 31908 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=alt:1 0.9 : user 9kksj== 10.64.56.10 31908 a=sendrecv -------------------------------------------- (UA-1 <-- kamailio) 72.255.255.255 <-- 10.64.52.110 SIP/2.0 200 Ok From: <sip:133@sip-example.com>;tag=i4mlq4jr0y To: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>;tag=vzx5x3mlbd Call-ID: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Require: timer Session-Expires: 3600;refresher=uac Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Supported: timer, 100rel, replaces Content-Type: application/sdp Content-Length: 270 Via: SIP/2.0/UDP 10.0.0.102:51519;received=72.255.255.255;branch=z9hG4bK-xfelmyyjzne5;rport=51519 Contact: <sip:leg_2@sip-example.com;ccr=atpsh-64e387e0-ee533-3> v=0 o=root 1084843702 1084843703 IN IP4 10.64.52.110 s=call c=IN IP4 10.64.52.110 t=0 0 m=audio 33552 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=alt:1 0.9 : user 9kksj== 10.64.56.10 31908 a=sendrecv =============================================== These next 2 SIP packets repeat, generating 14000+ CANCEL <--> 100 Trying transactions between kamailio, and the second proxy. (kamailio --> second proxy) 10.64.52.110 --> 10.64.52.100 CANCEL sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7 SIP/2.0 Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com> i: 95c3e4642670-rx28v46dte4p CSeq: 1 CANCEL Max-Forwards: 15 l: 0 -------------------------------------------- (kamailio <-- second proxy) 10.64.52.110 <-- 10.64.52.100 SIP/2.0 100 Trying v: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE l: 0

2 2

Force communications for I-CSCF and S-CSCF to be TCP only
by hvanhelmondt＠peratonlabs.com 23 Aug '23

23 Aug '23

Hi, I would like to force the transport protocol between the I-CSCF and S-CSCF to be TCP only. How would I do that exactly? I'm using an older Kamailio release 5.0.8. Regards,

2 2

use_dns_failover default value
by Silvan Nagl 23 Aug '23

23 Aug '23

Hi, I would like to know the reason for having "off" as default value for use_dns_failover. https://github.com/kamailio/kamailio/issues/3547 Greetings, Silvan

5 4

Kamailio 5.5.4 pua module memory leak
by Vladyslav Korniiaka 20 Aug '23

20 Aug '23

Hello! We are facing a Kamailio memory leak with the pua module, pua module consumes about 2GBs: kamcmd mod.stats all shm Module: pua { add_pua_event(72): 648 init_pua_evlist(36): 56 new_htable(79): 8192 init_puacb_list(35): 16 new_htable(64): 8 publ_cback_func(409): 12451504 publ_cback_func(363): 1658482848 update_htable(203): 210590960 new_htable(93): 131512 Total: 1881665744 } Module: pua_dialoginfo { get_str_list(463): 344 get_dialog_data(500): 1744 Total: 2088 } PUA Module parameters: loadmodule "pua.so" loadmodule "pua_dialoginfo" # ----- pua params ----- modparam("pua", "db_url", DBURL) modparam("pua", "db_mode", 0) modparam("pua", "outbound_proxy", PUA_PROXY) modparam("pua", "db_table_lock_write", 0) modparam("pua", "update_period", 0) modparam("pua", "dlginfo_increase_version", 0) modparam("pua", "reginfo_increase_version", 0) modparam("pua", "check_remote_contact", 0) modparam("pua", "fetch_rows", 1000) modparam("pua", "default_expires", 30) # ----- pua_dialoginfo params ----- modparam("pua_dialoginfo", "include_callid", 1) modparam("pua_dialoginfo", "send_publish_flag", FLT_PUBLISH) modparam("pua_dialoginfo", "caller_confirmed", 1) modparam("pua_dialoginfo", "include_tags", 1) modparam("pua_dialoginfo", "include_localremote", 0) modparam("pua_dialoginfo", "use_pubruri_avps", 1) modparam("pua_dialoginfo", "pubruri_caller_avp", "$avp(s:puburis_caller)") modparam("pua_dialoginfo", "pubruri_callee_avp", "$avp(s:puburis_callee)") *- Kamailio 5.5.4 (x86_64/linux), installed from .deb packages:* kamailio --version version: kamailio 5.5.4 (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, 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_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 *- Kamailio is runned in Docker:* docker --version Docker version 20.10.21, build baeda1f *- With “Debian GNU/Linux 10” docker image:* cat /etc/issue Debian GNU/Linux 10 \n \l *- Host OS is “Ubuntu 18.04.6 LTS”:* cat /etc/issue Ubuntu 18.04.6 LTS \n \l *- Server is AWS EC2 with CPU:* lscpu: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 46 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz Stepping: 7 CPU MHz: 3599.769 BogoMIPS: 5999.98 Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 36608K NUMA node0 CPU(s): 0-7 Please tell me if you need any additional information about this issue. Thanks for helping me with this! -- Regards, Vladyslav Korniiaka vladyslav.korniiaka(a)net2phone.com

2 1

Kamailio 5.5.4 pua module memory leak
by vladyslav.korniiaka＠idt.net 20 Aug '23

20 Aug '23

Hello! We are facing a Kamailio memory leak with the pua module, pua module consumes about 2GBs: kamcmd mod.stats all shm Module: pua { add_pua_event(72): 648 init_pua_evlist(36): 56 new_htable(79): 8192 init_puacb_list(35): 16 new_htable(64): 8 publ_cback_func(409): 12451504 publ_cback_func(363): 1658482848 update_htable(203): 210590960 new_htable(93): 131512 Total: 1881665744 } Module: pua_dialoginfo { get_str_list(463): 344 get_dialog_data(500): 1744 Total: 2088 } PUA Module parameters: loadmodule "pua.so" loadmodule "pua_dialoginfo" # ----- pua params ----- modparam("pua", "db_url", DBURL) modparam("pua", "db_mode", 0) modparam("pua", "outbound_proxy", PUA_PROXY) modparam("pua", "db_table_lock_write", 0) modparam("pua", "update_period", 0) modparam("pua", "dlginfo_increase_version", 0) modparam("pua", "reginfo_increase_version", 0) modparam("pua", "check_remote_contact", 0) modparam("pua", "fetch_rows", 1000) modparam("pua", "default_expires", 30) # ----- pua_dialoginfo params ----- modparam("pua_dialoginfo", "include_callid", 1) modparam("pua_dialoginfo", "send_publish_flag", FLT_PUBLISH) modparam("pua_dialoginfo", "caller_confirmed", 1) modparam("pua_dialoginfo", "include_tags", 1) modparam("pua_dialoginfo", "include_localremote", 0) modparam("pua_dialoginfo", "use_pubruri_avps", 1) modparam("pua_dialoginfo", "pubruri_caller_avp", "$avp(s:puburis_caller)") modparam("pua_dialoginfo", "pubruri_callee_avp", "$avp(s:puburis_callee)") - Kamailio 5.5.4 (x86_64/linux), installed from .deb packages: - Kamailio 5.5.4 (x86_64/linux), installed from .deb packages: kamailio --version version: kamailio 5.5.4 (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, 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_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 - Kamailio is runned in Docker: docker --version Docker version 20.10.21, build baeda1f - With “Debian GNU/Linux 10” docker image: cat /etc/issue Debian GNU/Linux 10 \n \l - Host OS is “Ubuntu 18.04.6 LTS”: cat /etc/issue Ubuntu 18.04.6 LTS \n \l - Server is AWS EC2 with CPU: lscpu: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 46 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz Stepping: 7 CPU MHz: 3599.769 BogoMIPS: 5999.98 Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 36608K NUMA node0 CPU(s): 0-7 Please tell me if you need any additional information about this issue. Thanks for helping me with this! -- Regards, Vladyslav Korniiaka vladyslav.korniiaka(a)net2phone.com

1 0

Check refer-to number
by David Cunningham 17 Aug '23

17 Aug '23

Hello, We want to check if the number in a REFER's Refer-To header begins with 011, and if so reject the request as not allowed. What would be the most effective way to do that? Thanks in advance, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

4 4

Unable to get avp value in response
by peter＠alienzombie.co.uk 17 Aug '23

17 Aug '23

I am trying to set a value to an avp on the request route, but when I try to read the avp on the reply route I always get nil. On the route I have this: KSR.xlog.xinfo("invite_request: ********** Setting avp test\n") KSR.pv.seti("$avp(test)", 1) KSR.xlog.xinfo("invite_request: **** " .. tostring(KSR.pv.get("$avp(test)")).."\n") On the reply route I have this: KSR.xlog.xinfo("response_invite: **** " .. tostring(KSR.pv.get("$avp(test)")).."\n") In the logs I see on the INVITE: Aug 8 13:49:15 test /usr/sbin/kamailio[1927947]: INFO: [a0748d39-3f17-4080-b5ed-0a6b7019cb95 INVITE 1]invite_request: ********** Setting avp test Aug 8 13:49:15 test /usr/sbin/kamailio[1927947]: INFO: [a0748d39-3f17-4080-b5ed-0a6b7019cb95 INVITE 1]invite_request: **** 1 ... ... Aug 8 13:49:15 test /usr/sbin/kamailio[1927968]: INFO: [a0748d39-3f17-4080-b5ed-0a6b7019cb95 INVITE 2]response_invite: **** nil Do avp not cover the transaction?

2 2

Kamailio behind TLS-TCP load balancer
by David Villasmil 17 Aug '23

17 Aug '23

Hello all, I’m having lots of problems when trying to configure Kamailio behind an AWS tls load balancer to offload tls and receive on tcp on Kamailio. Everything else inside is UDP. I found I need to manually add record-route presets every time and invite comes in. And when trying to forward an ACK to the client via tls/tcp load balancer Kamailio complaint the socket is not TLS so it fails. Is there a simpler way of doing this via some parameters I don’t know? Thanks for helping me with this! David -- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

5 9

kamailio-postgres on RHEL 9
by Ali Taher 17 Aug '23

17 Aug '23

Hello, I'm trying to install latest Kamailio version on RHEL 9.2. All is good, but I couldn't find kamailio-postgres package related to postgres module, knowing that I have installed Postgresql 15. Is there a rpm file that I can download to install kamailio-postgres ? Regards,

3 2

siremis Config.xml
by Maryam Baghdadi 15 Aug '23

15 Aug '23

Hello every one, How to set Remote Mysql database login ssl-mode in Config.xml file for siremis ???

1 0

Kamailio dns-failover / dns-loadbalancing with slow responding client.
by Mattis Lind 14 Aug '23

14 Aug '23

Hello! I am looking into a problem where we have Kamailio forwarding calls to two or more "recording-clients". I will try my best to describe the problem and would appreciate it if someone has an idea what to do. Please feel free to ask if you think I have forgotten to describe something that might be important or something is unclear in what I have written. We use use_dns_failover=yes and dns_srv_lb=yes so calls get load balancing to the "recording-clients". There is also the t_set_fr(60000,1000) parameter set so that if there is no response within 1 second it would try the next recording-client. The SRV record points to two or more recording clients. It now happens that the recording-clients sometimes have some kind of temporary problem so it will respond with a 503 after 5 seconds. What happens is that after the 1 second timeout trying to get the INVITE through to the first recording-client Kamailio will internally generate a 408. This will cause it to failover to another recording-client which happily takes care of the INVITE and responds properly with a 200 OK. Everything would have been just fine except for the fact that the first recording-client is just slow and finally responds with a 503. This 503 is not relayed backwards since a 200 has already been forwarded back to the caller. But when receiving the 503 Kamailio will initiate a new INVITE which is trying to set up a new call to a recording client. It looks like it is doing a new failover regardless if it already has done a failover for this failed transaction. I don't want Kamailio to send that last INVITE when receiving the 503. How can I configure Kamailio to disregard the last 503 (except for responding with an ACK) and not initiate a new INVITE? I have tried a lot of different changes to the configuration but failed to achieve this, unfortunately. Do I need to use the dispatcher module to achieve this? /Mattis

4 6

Modify To URI in Multiple Choices
by Ali Taher 11 Aug '23

11 Aug '23

Hello, I'm using Kamailio as SIP redirect where SBC sends INVITE packet to kamailio and "302","Multiple Choices" is sent back to SBC. What I want is to modify the URI part in the To header of the Multiple Choices packet sent from kamailio. I tried to use uac_replace_to("","sip:$var(cdpn)@$td") where $var(cdpn) is already defined in the routing logic, but it's not reflected and the original TO URI is sent instead. Any help to handle this issue is much appreciated. Regards,

2 2

how to get value of next hop
by Sergey Safarov 10 Aug '23

10 Aug '23

I receiving INVITE with two Route header (no to tag). First Route header is my Kamailio host. Second Route header is next hop after Kamailio. I need to get value of next hop. I tried to use "$route_uri" after "loose_route" but his deos works. "$route_uri" always use top Route header. But in the INVITE first Route header is Kamailio host. Is any change to get top Route header after "loose_route"?

3 2

Kamailio-asterisk BYE
by Dr. Barabás Péter 09 Aug '23

09 Aug '23

Hello, we work on a mobile softphone which connects to asterisk through kamailio. Almost everything is fine except one thing. Asterisk allows only one registration to an AOR. In mobile environment network can change, register/unregister can be called frequently in foreground/background cases. Kamailio forwards every request to asterisk. Until I have only one connection between kamailio – asterisk, everything is fine. The next situation is problematic: 1. Client A and client B register to asterisk through kamailio. –> there will be one connection between kamailio and asterisk 2. Client A calls client B. • one connection exist still 3. If client A terminates the call -> one connection remains. It is okay. 4. If client B terminates the call -> a new connection appears (kamailio IP with new port) After case 4 If I try to register again, I got 403 from asterisk, since the setting of asterisk does not allowed to register from different IP:port for the same AOR. (this behaviour cannot be changed now). The question: is there any setting/config exist in kamailio not to create new connection for a BYE in above case. Thanks in advance for your reply. Peter

1 0

Htable question
by Stefan-Cristian Mititelu 09 Aug '23

09 Aug '23

Hello, Can one kama process iterate a htable using sht_iterator_start(), sht_iterator_next(), sht_iterator_rm(), sht_iterator_end() while some other kama process call sht_rm(htable, item) ? I've looked into code and to me it looks like slots are locked ok. The entire linked list(specific to a slot) where the item might be, is locked, so this means there should be no problems, right? Thank you, Stefan

1 0

problem relay re-INVITE
by beer Ll 09 Aug '23

09 Aug '23

Hi I have a kamailio 5.7.1 running as TLS gateway for PBXs in private LAN network: UAC-WAN(sip-tls) <--> kamailio-WAN(sip-tls) - kamailio-LAN(sip) <--> PBX-LAN(sip) 80.0.0.1 <--> 80.0.0.2 - 10.0.0.1 <--> 10.0.0.2 All communications tested works well except for re-INVITE like when UAC put the call on hold . The re-INVITE packet is managed like a new call and the tm module doesn't match transaction : matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-524287-1---5e900485d5ad0faf] t_lookup_request(): no transaction found build_cell(): created new cell t_relay_to(): new INVITE I try to send the interesting logs and config call logs and pcap : https://filebin.net/vdezuhyn7wdy3lqc kamailio config : ... request_route { if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } route(WITHINDLG); if ($si=="PBXIP0" || $si=="PBXIP1" || $si=="PBXIP2" || $si=="PBXIP3" ) { if (!loose_route()) { switch($rc) { case -2: sl_send_reply("403", "Forbidden"); exit; } } remove_hf("Route"); force_rport(); record_route(); $fs = "tls:WANIP:5061"; } if (is_method("INVITE|SUBSCRIBE")){ record_route(); } t_on_failure("MANAGE_FAILURE"); $fs = "udp:LANIP:5060"; } route(RELAY); exit; } route[WITHINDLG] { if (!has_totag()) return; if ($si=="PBXIP0" || $si=="PBXIP1" || $si=="PBXIP2" || $si=="PBXIP3") { route(RTPMANAGE); route(RELAY); exit; } if (loose_route()) { if ( is_method("NOTIFY") ) { record_route(); } route(RTPMANAGE); route(RELAY); exit; } if ( is_method("ACK|BYE") ) { route(RTPMANAGE); route(RELAY); } sl_send_reply("404","Not here"); exit; } How can I solve this ? Best Regards Leo

1 0

No
by Sergey Safarov 09 Aug '23

09 Aug '23

I catched issue with In the Kamailio logs i see ssl bug #1491 workaround: not enough memory for safe operation: shm=10219080 threshold2=11796480 Current stat about shared memory [root@sbc-a1 ~]# kamctl stats shmem { "jsonrpc": "2.0", "result": [ "shmem:fragments = 528", "shmem:free_size = 11343104", "shmem:max_used_size = 124449952", "shmem:real_used_size = 122874624", "shmem:total_size = 134217728", "shmem:used_size = 58728144" ], "id": 703182 } But when kamailio started [root@sbc-a1 ~]# kamctl stats shmem { "jsonrpc": "2.0", "result": [ "shmem:fragments = 122", "shmem:free_size = 112534264", "shmem:max_used_size = 22372528", "shmem:real_used_size = 21683464", "shmem:total_size = 134217728", "shmem:used_size = 12833888" ], "id": 703670 } What is stange a lot of fragments. How it can be troubleshooted? Can memory manager show info about each fragment like when fragment are created an and which module requested fragment?

2 3

Problem connecting to Redis DB using DB_REDIS module with a Password
by Nick Digalakis 08 Aug '23

08 Aug '23

Hello everyone! I had a Kamailio 5.6.4 server using the DB_REDIS module for quite some time without a password on the Redis DB working just fine. A few days ago I decided to add a password to Redis and modify the Kamailio config file with the following line per the documentation to be able to authenticate: modparam("db_redis", "db_pass", "r3d1sPass") Since that moment, I see the following errors in the Kamailio logs: ...... kamailio: ERROR: <core> [core/modparam.c:175]: set_mod_param_regex(): parameter <db_pass> of type <1:string> not found in module <db_redis> kamailio: CRITICAL: <core> [core/cfg.y:3790]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 556, column 49: Can't set module parameter ...... The documentation I am reading is here: https://www.kamailio.org/docs/modules/devel/modules/db_redis.html#db_redis.… Could someone help me figure out what I am doing wrong? Many thanks, Nick

2 2

pua_json mwi minimal json
by David VILLAUME 08 Aug '23

08 Aug '23

Hello, On 5.6.4, i’m trying to perform mwi pua_json, but cannot get it working. I have a doubt about my json and spent some time to make variations on json without success. Does one of you played with it and can tell me if something is wrong about this json ? { "Event-Package":"message-summary", "Event-Name":"update" "expires":3600, "From":sip:ccoca@dff.com, "To":sip:ccoca@dff.com, "Message-Account":sip:ccoca@dff.com, "Messages-Waiting":"yes", "MWI-Voice-Message":"2/8 (0/0)", "Messages-New":"2", "Messages-Saved":"8", "Messages-Urgent":"0", "Messages-Urgent-Saved":"0", "From-Realm":"dff.com", "From-User":"ccoca", "Call-ID":0_845806535@10.22.22.22<mailto:0_845806535@10.22.22.22>, } Regards, David

3 3

Subscribers and peers handling
by Kiss Zoltán 08 Aug '23

08 Aug '23

Hello, We are trying to build a lightweight SBC solution for some external peers, but currently there is a mixed environment which is handled by Asterisk. We have some "peers" with IP based auth, and also some "subscribers" with register. We have succeded with the subscribers, because we can handle the numbers for those type of users with aliases in Kamailio. So basically we have a subscriber, lets call it "test", and we can add aliases for the subscriber like "3612345678@localhost", then if we are calling the number the routing goes to the contact of "test" subscriber. Currently the problem is that we dont have any idea about the IP based peers, because those peers not registering, so we cannot create aliases for them as far as i know. How do you solve this type of problem? Maybe im overcomplicating the situation, but i havent got any solutions in my mind currently. Thanks for your help and ideas. With kind regards, Zoltan

1 0

Connection to AWS services (e.g DynamoDB)
by Lewis Hutchinson 07 Aug '23

07 Aug '23

Hi Jakub Although no direct experience with this exactly as you have described I have used HTTP API out of Kamailio quite a bit and into other services. Which yes some ultimatly end in AWS> Having done our's in KEMI there is some difference however from our experience we did notice some of this didn't fair well under a loads test scenario. We tested Kafka vs Kamailio HTTP API Modules vs Aiohttp (Python in Kemi) and Kafka significantly out perfomed in terms of the load test. We then had to rejig things to account for this instead of HTTP API. If this is ever going to be under intense load. Maybe make sure you do the load testing early on before you ratify your design. Also make sure all your error habndling is in place and working to prevent issues in Kamailio if something API side goes wrong. Mission Labs Limited is registered in England, company number 10040088. Trading Office: The Old Milk Depot, Bacup Rd, Rossendale, BB4 7FE. Registered office: The Scalpel, 18th Floor 52 Lime Street, London, EC3M 7AF. Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Please consider the environment before you print this email.

1 0

Setting up rtpengine to relay RTP
by Alvaro Escobar 05 Aug '23

05 Aug '23

Hello I have debian 11 with kamailio 5.6.4 (x86_64/linux). The kamailio is working fine. Now I need to setup rtprngine to relay RTP. I have installed the rtpengine using this guide: https://dfx.at/rtpengine/ Version: 10.5.4.3-1+b1 When I run: systemctl status rtpengine-daemon I got: ● rtpengine-daemon.service - RTP/media Proxy Daemon Loaded: loaded (/lib/systemd/system/rtpengine-daemon.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2023-08-01 20:58:23 -05; 51min ago Docs: man:rtpengine(8) Process: 468 ExecStartPre=/usr/sbin/rtpengine-iptables-setup start (code=exited, status=0/SUCCESS) Main PID: 535 (rtpengine) Tasks: 22 (limit: 2323) Memory: 42.1M CPU: 720ms CGroup: /system.slice/rtpengine-daemon.service └─535 /usr/bin/rtpengine -f -E --no-log-timestamps --pidfile /run/rtpengine/rtpengine-daemon.pid --config-file /etc/rtpengine/rtpengine.conf Aug 01 20:58:22 debian systemd[1]: Starting RTP/media Proxy Daemon... Aug 01 20:58:23 debian rtpengine[535]: INFO: [crypto] Generating new DTLS certificate Aug 01 20:58:23 debian rtpengine[535]: INFO: [core] Startup complete, version 10.5.4.3-1+b1 Aug 01 20:58:23 debian systemd[1]: Started RTP/media Proxy Daemon. Aug 01 20:58:23 debian rtpengine[535]: INFO: [http] Websocket listener thread running I edited /etc/kamailio/kamailo.cfg with: #!define WITH_RTPENGINE #!ifdef WITH_RTPENGINE loadmodule "rtpengine.so" modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223") systemctl restart kamilio To check if the rtpengine module is running: kamcmd core.modules I got: permissions auth_db auth counters acc cfg_rpc ctl sanity xlog siputils textopsx textops registrar usrloc maxfwd pv rr sl tmx tm corex kex jsonrpcs db_mysql The point is that I don't see the rtpengine module. There is another way to check if the rtpengine module is running ? Regards

2 2

Connection to AWS services (e.g DynamoDB)
by jakub.smadis＠cloudtalk.io 04 Aug '23

04 Aug '23

Hello, I am researching how I could communicate from Kamailio (which runs on an AWS EC2 instance) with AWS services (e.g. DynamoDB) using HTTP API. My Kamailio logic is written in Kamailio configuration files. I would like to ask you if anyone has some experience with such a setup and if so how did you manage to connect it? My current options are: * HTTP connection to DynamoDB API with HTTP module I would create a Python script that would generate signature headers for the [AWS API request](https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-req…. Then I would use the headers in the HTTP request. (I am using the Kamailio module to keep the connection open to DynamoDB). * Middleman service Small service that provides HTTP API to Kamailio and manages the communication with DynamoDB. Easiest solution but it's harder to maintain it in high availability mode. * API gateway with VPC endpoint attached to the EC2 API gateway would be a proxy to DynamoDB and we would call the VPC endpoint from the Kamailio. We would use resource policies to allow requests without auth through the VPC endpoint. Any help or feedback would be valuable to me. Thank you very much! Regards, Jakub

1 0

change A number using a pool of numbers
by Ali Taher 03 Aug '23

03 Aug '23

Hello, I'm looking to change the A number (from number) to a number selected randomly from a pool of existing numbers (hundreds) and then relay the call to a certain gateway. What is the best and more efficient way to do it in kamailio? Thanks in advance

2 3

advertise transport
by David Villasmil 02 Aug '23

02 Aug '23

Hello guys, I have kamailio behind a TLS->TCP Load Balancer. I'm having problems because the outgoing packets have a record has the correct advertise BUT kamailio is assuming that because the outgoing socket is TCP, it adds ";transport=tcp"... is it possible to set that parameter to tls? Thanks! David Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

1 1

Saving credentials in yaml/txt format
by max＠telemessage.com 01 Aug '23

01 Aug '23

Hello all, I want to save some credentials for different users I have that are being used in a digest authorization (INVITE), with different realms (I don't want the credentials to be hardcoded). I tried to look at how can I read into my kamalio.cfg from yaml/txt file, but haven't found the right module for this. Thanks in advance, Max

4 3

Help
by Shravan Kumar 28 Jul '23

28 Jul '23

Hello, How can I configure my Kamalio server to work as multihoming for sctp testing... Please ASAP!!

2 1

Re: RTPENGINE - RTP Proxy
by Duarte Rocha 27 Jul '23

27 Jul '23

Hello Alex, Thank you for your answer, I still don't have sound but the behaviour is now different. Is it possible to configure this behaviour on a call by call basis with flags on the rtpengine_manage() function? Or in alternative having it consume the "direction=" attribute on the SDP? Cheers

1 0

Re: RTPENGINE - RTP Proxy
by Duarte Rocha 27 Jul '23

27 Jul '23

Hello Alex, Thank you for your answer, I still don't have sound but the behaviour is now different. Is it possible to configure this behaviour on a call by call basis with flags on the rtpengine_manage() function? Or in alternative having it consume the "direction=" attribute on the SDP? Cheers

1 0

RTPENGINE - RTP Proxy
by Duarte Rocha 26 Jul '23

26 Jul '23

Hello all, I'm currently doing some experiments with RTPENGINE and I need some help configuring it. First scenario i'm under NAT and Kamailio receives an INVITE with a private address, rewrites (c) line on SDP with it's own IP address and relays the message to the destination endpoint. After that the originator receives the 183 Session Progress with kamailio's IP as (c) parameter. After receiving the first RTP packet from the originator the media streams flow normally and I have sound on both sides including ringing. Second scenario I use different equipment that is not under NAT, but the remaining scenario is the same, except the originator doesn't send an RTP packet after the 183 Session Progress. However, in this case, no RTP stream is relayed to the originator and as a consequence it doesn't hear a ring or voice when the call is answered. As i see it, it looks like Kamailio is on passive mode to the A-Leg of the call and waits for a RTP packet to establish its stream. Is this correct? If so, how do i change this behaviour? Cheers

2 1

Re: Kamailio as SIP proxy for an Asterisk with Private IP Address
by Lewis Hutchinson 25 Jul '23

25 Jul '23

This is always a good place to start https://www.fredposner.com/1457/kamailio-behind-nat/ Lewis Mission Labs Limited is registered in England, company number 10040088. Trading Office: The Old Milk Depot, Bacup Rd, Rossendale, BB4 7FE. Registered office: The Scalpel, 18th Floor 52 Lime Street, London, EC3M 7AF. Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Please consider the environment before you print this email.

5 6

tcpops: Variable conid on tcp-closed event
by Michal Hajek 24 Jul '23

24 Jul '23

Hi, I have problem with the conid variable, when I use in an event when closing a tcp connection. Simple kamailio.cfg: debug=3 log_stderror=no loadpath "/usr/lib64/kamailio/modules" memdbg=5 memlog=5 log_facility=LOG_LOCAL3 listen=udp:10.10.8.94:5060 listen=tcp:10.10.8.94:5060 loadmodule "sl.so" loadmodule "xlog.so" loadmodule "pv.so" loadmodule "tcpops.so" request_route { xlog("L_INFO", "Welcome TCP conn $conid\n"); exit; } event_route[tcp:closed] { xlog("L_INFO", "Close TCP conn $conid\n"); } Log: kamailio DEBUG: <core> [core/ip_addr.c:577]: print_ip(): tcpconn_new: new tcp connection: 10.10.9.64 kamailio DEBUG: <core> [core/tcp_main.c:1216]: tcpconn_new(): on port 38124, type 2, socket 34 kamailio DEBUG: <core> [core/tcp_main.c:1549]: tcpconn_add(): hashes: 3487:2267:2872, 19 kamailio DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): processing io_watch_add(0xb39c40, 34, 2, 0x14c2479867f0) - fd_no=28 kamailio DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0xb39c40, 34, -1, 0x0) fd_no=29 called kamailio DEBUG: <core> [core/tcp_main.c:4557]: handle_tcpconn_ev(): sending to child, events 2001 kamailio DEBUG: <core> [core/tcp_main.c:4227]: send2child(): selected tcp worker idx:2 proc:14 pid:1203550 for activity on [tcp:10.10.8.94:5060], 0x14c2479867f0 kamailio DEBUG: <core> [core/tcp_read.c:1735]: handle_io(): received n=8 con=0x14c2479867f0, fd=6 kamailio DEBUG: <core> [core/tcp_read.c:284]: tcp_read_data(): EOF on connection 0x14c2479867f0 (state: 3, flags: 4118) - FD 6, bytes 218, rd-flags 10000 ([10.10.9.64]:38124 -> [10.10.9.64]:5060) kamailio DEBUG: <core> [core/tcp_read.c:1533]: tcp_read_req(): content-length=0 kamailio DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 kamailio DEBUG: <core> [core/parser/msg_parser.c:678]: parse_msg(): SIP Request: kamailio DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): method: <OPTIONS> kamailio DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): uri: <sip:100@localhost> kamailio DEBUG: <core> [core/parser/msg_parser.c:684]: parse_msg(): version: <SIP/2.0> kamailio DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 kamailio DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKhjhs8ass877>; state=15 kamailio DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 kamailio DEBUG: <core> [core/parser/msg_parser.c:554]: parse_headers(): Via found, flags=2 kamailio DEBUG: <core> [core/parser/msg_parser.c:556]: parse_headers(): this is the first via kamailio DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6 kamailio DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4 kamailio DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3 kamailio DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=10 kamailio DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [20]; uri=[sip:100@localhost] kamailio DEBUG: <core> [core/parser/msg_parser.c:175]: get_hdr_field(): to body (20)[<sip:100@localhost> ], to tag (0)[] kamailio DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Content-Length] type 12 kamailio DEBUG: <core> [core/parser/msg_parser.c:186]: get_hdr_field(): content_length=0 kamailio DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5 kamailio DEBUG: <core> [core/parser/msg_parser.c:153]: get_hdr_field(): cseq <CSeq>: <63104> <OPTIONS> kamailio DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message - request - call-id: [ahoj423432432] - cseq: [63104 OPTIONS] kamailio DEBUG: {1 ahoj423432432} <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route core:pre-routing not defined kamailio DEBUG: {1 ahoj423432432} <core> [core/receive.c:471]: receive_msg(): preparing to run routing scripts... kamailio DEBUG: {1 ahoj423432432} <core> [core/tcp_main.c:1645]: _tcpconn_find(): found connection by id: 19 kamailio INFO: {1 ahoj423432432} <script>: Welcome TCP conn 19 kamailio DEBUG: {1 ahoj423432432} <core> [core/receive.c:529]: receive_msg(): request-route executed in: 47 usec kamailio DEBUG: {1 ahoj423432432} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/xavp.c:640]: xavp_destroy_list(): destroying xavp list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/xavp.c:640]: xavp_destroy_list(): destroying xavp list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/xavp.c:640]: xavp_destroy_list(): destroying xavp list (nil) kamailio DEBUG: {1 ahoj423432432} <core> [core/receive.c:628]: receive_msg(): cleaning up kamailio DEBUG: <core> [core/tcp_read.c:1634]: tcp_read_req(): EOF after reading complete request ([10.10.9.64]:38124 -> [10.10.9.64]:5060) kamailio DEBUG: <core> [core/tcp_read.c:1653]: release_tcpconn(): releasing con 0x14c2479867f0, state -1, fd=6, id=19 ([10.10.9.64]:38124 -> [10.10.9.64]:5060) kamailio DEBUG: <core> [core/tcp_read.c:1657]: release_tcpconn(): extra_data (nil) kamailio DEBUG: <core> [core/tcp_main.c:3653]: handle_tcp_child(): reader response= 14c2479867f0, -1 from 2 kamailio DEBUG: <core> [core/tcp_main.c:3578]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) kamailio DEBUG: tcpops [tcpops.c:295]: tcpops_handle_tcp_closed(): received TCP closed event kamailio DEBUG: tcpops [tcpops.c:249]: tcpops_tcp_closed_run_route(): event reason id: 0 rt: 1 kamailio INFO: <script>: Close TCP conn <null> Can you help me, where is issue?

1 0

Kamailio as SIP proxy for an Asterisk with Private IP Address
by John shuku 24 Jul '23

24 Jul '23

Dear Kamailio users, Im new to kamailio so excuse me if the question doesnt make sense. I have an asterisk server with private IP address behind the NAT . Is it possible to have a Kamailio Server with Public IP Address as a proxy server for my asterisk ? What I want to achieve is that remote users should be able to call internal users who are registered in the Asterisk . The problem here is that Asterisk does not have public IP address and I want the remote users to be registered in my asterisk . Best WishesJ. sh

3 4

Re: Add a digest authorization with password and username (INVITE)
by Max Kemel 20 Jul '23

20 Jul '23

Thank you very much Barry, that was it 🙂 Max Kemel

1 0

Add a digest authorization with password and username (INVITE)
by Max Kemel 20 Jul '23

20 Jul '23

Hello, I would appreciate any help you can provide on this matter, I would like to make an outgoing INVITE request which will have a digest authorization with password and username. I was wandering around the Auth module to find the most fit method to build this header but hadn't found anything. Maybe I am missing something really obvious here, thanks for the help in advance Best regards, Max.

2 1

Kamailio v5.5.7 Released
by Daniel-Constantin Mierla 19 Jul '23

19 Jul '23

Hello, Kamailio SIP Server v5.5.7 stable release is out. This is a maintenance release of the stable branch 5.5 that includes fixes since the release of v5.5.6. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.5.x. Deployments running previous v5.5.x versions are strongly recommended to be upgraded to v5.5.7. Note that 5.5 is now the third last stable branch, v5.5.7 being the last planned released in 5.5.x series. The latest two stable branch are 5.6 and 5.7, with v5.7.1 being released a while ago. For more details about version 5.5.7 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/07/kamailio-v5-5-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 -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - www.kamailioworld.com

1 0

Releasing Kamailio v5.5.7
by Daniel-Constantin Mierla 19 Jul '23

19 Jul '23

Hello, I am planning to release v5.5.7 our of branch 5.5 this week, most likely on Wednesday, July 19, 2023. It will mark the end of official packaging for release series 5.5.x, currently the latest two stable branches are 5.6 and 5.7. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - www.kamailioworld.com

1 1

Re: WebRTC proxy with rtpengine - How to change from RTP to SRTP on 488 response
by Alex Balashov 18 Jul '23

18 Jul '23

I wouldn't do a delete in that situation; it might be simpler to just do another rtpengine_offer() on a <Call-ID, From-tag> tuple that RTPEngine already knows about, just as one would in a reinvite. I believe rtpengine_manage() would cover this situation as well. And yes, then just t_relay() anew! > On Jul 18, 2023, at 11:41 AM, Barry Flanagan <barry(a)flantel.com> wrote: > > On 18/07/2023 16:33, Alex Balashov wrote: >> Barry, >> >> Might it not be simpler to follow Richard's first suggestion in that thread, and simply catch the 488 response in a failure_route and re-issue a non-SRTP offer on another branch? > > hi Alex, > > Might be. I am just unsure about how to instruct rtpengine to re-send the plain RTP invite. Do I do a rtpengine_delete and then restart with rtpengine_manage() then relay again? > > Thanks. > > -Barry > > >> >> -- Alex >> >>> On Jul 18, 2023, at 11:05 AM, Barry Flanagan <barry(a)flantel.com> wrote: >>> >>> Hi, >>> >>> I have implemented a WebRTC proxy using Kamailio and rtpengine, in front >>> of Asterisk servers. I have an issue where I do not know in advance >>> whether the Asterisk client is set to use RTP or SRTP. >>> >>> My implementation expects the web side to be SRTP and the Asterisk side >>> plain RTP. However, if the asterisk side requires SRTP I receive a 488 >>> Not Acceptable here. The same is true when an SRTP client from the >>> Asterisk side dials out to the webrtc client, I need to catch whether >>> the request is SRTP or RTP and generate rtpengine offer accordingly. >>> >>> This was discussed in github, with a description of a solution here: >>> https://github.com/sipwise/rtpengine/issues/435#issuecomment-391937398 - >>> however I am unsure how to implement this. >>> >>> Does anyone have an example of how I can change the rtpengine SDP in >>> such a case? >>> >>> Thanks >>> -- >>> -Barry >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> 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! >>> Edit mailing list options or unsubscribe: > > -- > -Barry > -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

1 0

WebRTC proxy with rtpengine - How to change from RTP to SRTP on 488 response
by Barry Flanagan 18 Jul '23

18 Jul '23

Hi, I have implemented a WebRTC proxy using Kamailio and rtpengine, in front of Asterisk servers. I have an issue where I do not know in advance whether the Asterisk client is set to use RTP or SRTP. My implementation expects the web side to be SRTP and the Asterisk side plain RTP. However, if the asterisk side requires SRTP I receive a 488 Not Acceptable here. The same is true when an SRTP client from the Asterisk side dials out to the webrtc client, I need to catch whether the request is SRTP or RTP and generate rtpengine offer accordingly. This was discussed in github, with a description of a solution here: https://github.com/sipwise/rtpengine/issues/435#issuecomment-391937398 <https://github.com/sipwise/rtpengine/issues/435#issuecomment-391937398>- however I am unsure how to implement this. Does anyone have an example of how I can change the rtpengine SDP in such a case? Thanks -- -Barry

2 1

Kamailio 5.6.4 and htable dbmode=1
by Bernd Krueger-Knauber 18 Jul '23

18 Jul '23

Hi Daniel, thank you for your response. As you can see in the provided debug output: kamailio[]: DEBUG: htable [ht_api.c:1046]: ht_table_spec(): htable [callpush] - dbmode [1] kamailio[]: DEBUG: htable [ht_api.c:1027]: ht_table_spec(): htable [callpush] - dbtable [userpush] kamailio[]: DEBUG: htable [ht_api.c:1036]: ht_table_spec(): htable [callpush] - expire [86400] kamailio[]: DEBUG: htable [ht_api.c:1041]: ht_table_spec(): htable [callpush] - size [10] dbmode is set to 1 in the config: modparam("htable", "db_url", "sqlite:////etc/kamailio/htable.sqlite") ... modparam("htable", "htable", "userpush=>size=3;autoexpire=600;dbtable=userpush;dbmode=1") If I execute kamcmd htable.store userpush I get Ok. Htable successfully stored to DB. But the table is still empty!!! In the log I found: ERROR: db_sqlite [dbase.c:528]: db_sqlite_commit(): sqlite commit failed: attempt to write a readonly database ERROR: db_sqlite [dbase.c:177]: db_sqlite_cleanup_query(): finalize failed: attempt to write a readonly database ERROR: htable [ht_db.c:668]: ht_db_delete_records(): failed to delete db records in [userpush] ERROR: db_sqlite [dbase.c:528]: db_sqlite_commit(): sqlite commit failed: attempt to write a readonly database Ok. But I can not see this entries if I shutdown kamailio. And: -rw-rw-rw- 1 kamailio root 16384 Jul 13 16:14 htable.sqlite I never used: modparam("db_sqlite","db_set_readonly" ... I also restarted kamailio. no difference. Now more errors then before: It is not written at shutdown. (no messages) It is not written (live) (with error messages, but why it is readonly?) The message of kamcmd is wrong (says Ok but it failed) Best regards, Bernd Am 17.07.2023 um 08:48 schrieb Daniel-Constantin Mierla: > Hello, > > is dbmode=1 in htable definition? > > If you run rpc command htable.store for the htable, are the records > saved to database? > > Cheers, > Daniel > > On 13.07.23 17:45, Bernd Krueger-Knauber wrote: >> Hi, >> >> I just tried to use sqlite and htable to load and save the values. >> At start I can see in the log, that all parameters are correct and >> that htable want to load the values from the table. >> No errors. >> >> But if I stop kamailio, nothing is written to the tables. >> >> At start I can see: >> >> kamailio[]: DEBUG: <core> [core/modparam.c:112]: >> set_mod_param_regex(): 'htable' matches module 'htable' >> kamailio[]: DEBUG: <core> [core/sr_module.c:814]: find_param_export(): >> found <htable> in module htable >> [/usr/lib/x86_64-linux-gnu/kamailio/modules/htable.so] >> kamailio[]: DEBUG: <core> [core/modparam.c:128]: >> set_mod_param_regex(): found <htable> in module htable >> [/usr/lib/x86_64-linux-gnu/kamailio/modules/htable.so] >> kamailio[]: DEBUG: htable [ht_api.c:1046]: ht_table_spec(): htable >> [callpush] - dbmode [1] >> kamailio[]: DEBUG: htable [ht_api.c:1027]: ht_table_spec(): htable >> [callpush] - dbtable [userpush] >> kamailio[]: DEBUG: htable [ht_api.c:1036]: ht_table_spec(): htable >> [callpush] - expire [86400] >> kamailio[]: DEBUG: htable [ht_api.c:1041]: ht_table_spec(): htable >> [callpush] - size [10] >> >> >> >> kamailio[]: DEBUG: htable [ht_api.c:1084]: ht_db_load_tables(): >> loading db table [userpush] in ht [userpush] >> kamailio[]: DEBUG: htable [ht_db.c:232]: ht_db_load_table(): >> =============== loading hash table [userpush] from database [userpush] >> kamailio[]: DEBUG: db_sqlite [dbase.c:223]: db_sqlite_submit_query(): >> submit_query: select key_name,key_type,value_type,key_value from >> userpush order by key_name >> kamailio[]: DEBUG: <core> [db_query.c:72]: db_do_submit_query(): >> submitted query: select key_name,key_type,value_type,key_value from >> userpush order by key_name, result 0 >> kamailio[]: DEBUG: <core> [db_res.c:119]: db_new_result(): allocate 56 >> bytes for result set at 0x7f4882107938 >> kamailio[]: DEBUG: <core> [db_res.c:79]: db_free_columns(): freeing 0 >> columns >> kamailio[]: DEBUG: <core> [db_res.c:138]: db_free_result(): freeing >> result set at 0x7f4882107938 >> >> Ok, the file is empty, but it tries to load the data from the table. >> >> The table looks like: >> >> sqlite> .schema userpush >> CREATE TABLE userpush ( >> key_name TEXT, >> "key_type" INTEGER, >> value_type INTEGER, >> key_value TEXT >> ); >> >> >> I checked the source code and I saw that destroy() should be called. >> Inside is ht_db_open_con() called before ht_db_sync_tables(), were it >> happens. >> But I can even not see the debug message from ht_db_open_con() : >> >> LM_DBG("database connection opened successfully\n") >> and also not >> LM_ERR("failed to connect to the database\n"); >> >> For me it looks like, that the destroy() function is not called. >> >> Even with debug=3, I can only see: >> >> >> systemd[]: Stopping kamailio.service - Kamailio - the Open Source SIP >> Server... >> kamailio[]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received >> systemd[]: kamailio.service: Deactivated successfully. >> systemd[]: Stopped kamailio.service - Kamailio - the Open Source SIP >> Server. >> >> I stopped kamailio with >> >> systemctl stop kamailio >> >> I'm sure that something was inside the htable before I stoped kamailio: >> >> { >> entry: 0 >> size: 1 >> slot: { >> { >> name: >> 07db580a6c13e798a5acc0d123d6e957897c8650b43f99d6d5cb9c2cb5ba4fa4 >> value: >> 3a28dcb73eb65722df5a261983b7692cecdca482bf8725032e46a0c6b89fb355 >> type: str >> } >> } >> } >> >> Any further ideas? >> >> Best regards, >> >> Bernd >> >> >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> To unsubscribe send an email tosr-users-leave(a)lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only >> to the sender! >> Edit mailing list options or unsubscribe: -- EDNT GmbH Werner-von-Siemens-Strasse 7 64625 Bensheim www.ednt.de Registergericht: Darmstadt Registernummer: 24972 Geschäftsführer: Karlheinz Knapp

6 8

Fwd: Kamailio 5.6.4 and htable dbmode=1
by Bernd Krueger-Knauber 17 Jul '23

17 Jul '23

-------- Weitergeleitete Nachricht -------- Betreff: Re: [SR-Users] Kamailio 5.6.4 and htable dbmode=1 Datum: Mon, 17 Jul 2023 09:50:37 +0200 Von: Bernd Krueger-Knauber <bkk(a)ednt.de> An: miconda(a)gmail.com Hi Daniel, thank you for your response. As you can see in the provided debug output: kamailio[]: DEBUG: htable [ht_api.c:1046]: ht_table_spec(): htable [callpush] - dbmode [1] kamailio[]: DEBUG: htable [ht_api.c:1027]: ht_table_spec(): htable [callpush] - dbtable [userpush] kamailio[]: DEBUG: htable [ht_api.c:1036]: ht_table_spec(): htable [callpush] - expire [86400] kamailio[]: DEBUG: htable [ht_api.c:1041]: ht_table_spec(): htable [callpush] - size [10] dbmode is set to 1 in the config: modparam("htable", "db_url", "sqlite:////etc/kamailio/htable.sqlite") ... modparam("htable", "htable", "userpush=>size=3;autoexpire=600;dbtable=userpush;dbmode=1") If I execute kamcmd htable.store userpush I get Ok. Htable successfully stored to DB. But the table is still empty!!! In the log I found: ERROR: db_sqlite [dbase.c:528]: db_sqlite_commit(): sqlite commit failed: attempt to write a readonly database ERROR: db_sqlite [dbase.c:177]: db_sqlite_cleanup_query(): finalize failed: attempt to write a readonly database ERROR: htable [ht_db.c:668]: ht_db_delete_records(): failed to delete db records in [userpush] ERROR: db_sqlite [dbase.c:528]: db_sqlite_commit(): sqlite commit failed: attempt to write a readonly database Ok. But I can not see this entries if I shutdown kamailio. And: -rw-rw-rw- 1 kamailio root 16384 Jul 13 16:14 htable.sqlite I never used: modparam("db_sqlite","db_set_readonly" ... I also restarted kamailio. no difference. No more errors then before: It is not written at shutdown. (no messages) It is not written (live) (with error messages, but why it is readonly?) The message of kamcmd is wrong (says Ok but it failed) Best regards, Bernd Am 17.07.2023 um 08:48 schrieb Daniel-Constantin Mierla: > Hello, > > is dbmode=1 in htable definition? > > If you run rpc command htable.store for the htable, are the records > saved to database? > > Cheers, > Daniel > > On 13.07.23 17:45, Bernd Krueger-Knauber wrote: >> Hi, >> >> I just tried to use sqlite and htable to load and save the values. >> At start I can see in the log, that all parameters are correct and >> that htable want to load the values from the table. >> No errors. >> >> But if I stop kamailio, nothing is written to the tables. >> >> At start I can see: >> >> kamailio[]: DEBUG: <core> [core/modparam.c:112]: >> set_mod_param_regex(): 'htable' matches module 'htable' >> kamailio[]: DEBUG: <core> [core/sr_module.c:814]: find_param_export(): >> found <htable> in module htable >> [/usr/lib/x86_64-linux-gnu/kamailio/modules/htable.so] >> kamailio[]: DEBUG: <core> [core/modparam.c:128]: >> set_mod_param_regex(): found <htable> in module htable >> [/usr/lib/x86_64-linux-gnu/kamailio/modules/htable.so] >> kamailio[]: DEBUG: htable [ht_api.c:1046]: ht_table_spec(): htable >> [callpush] - dbmode [1] >> kamailio[]: DEBUG: htable [ht_api.c:1027]: ht_table_spec(): htable >> [callpush] - dbtable [userpush] >> kamailio[]: DEBUG: htable [ht_api.c:1036]: ht_table_spec(): htable >> [callpush] - expire [86400] >> kamailio[]: DEBUG: htable [ht_api.c:1041]: ht_table_spec(): htable >> [callpush] - size [10] >> >> >> >> kamailio[]: DEBUG: htable [ht_api.c:1084]: ht_db_load_tables(): >> loading db table [userpush] in ht [userpush] >> kamailio[]: DEBUG: htable [ht_db.c:232]: ht_db_load_table(): >> =============== loading hash table [userpush] from database [userpush] >> kamailio[]: DEBUG: db_sqlite [dbase.c:223]: db_sqlite_submit_query(): >> submit_query: select key_name,key_type,value_type,key_value from >> userpush order by key_name >> kamailio[]: DEBUG: <core> [db_query.c:72]: db_do_submit_query(): >> submitted query: select key_name,key_type,value_type,key_value from >> userpush order by key_name, result 0 >> kamailio[]: DEBUG: <core> [db_res.c:119]: db_new_result(): allocate 56 >> bytes for result set at 0x7f4882107938 >> kamailio[]: DEBUG: <core> [db_res.c:79]: db_free_columns(): freeing 0 >> columns >> kamailio[]: DEBUG: <core> [db_res.c:138]: db_free_result(): freeing >> result set at 0x7f4882107938 >> >> Ok, the file is empty, but it tries to load the data from the table. >> >> The table looks like: >> >> sqlite> .schema userpush >> CREATE TABLE userpush ( >> key_name TEXT, >> "key_type" INTEGER, >> value_type INTEGER, >> key_value TEXT >> ); >> >> >> I checked the source code and I saw that destroy() should be called. >> Inside is ht_db_open_con() called before ht_db_sync_tables(), were it >> happens. >> But I can even not see the debug message from ht_db_open_con() : >> >> LM_DBG("database connection opened successfully\n") >> and also not >> LM_ERR("failed to connect to the database\n"); >> >> For me it looks like, that the destroy() function is not called. >> >> Even with debug=3, I can only see: >> >> >> systemd[]: Stopping kamailio.service - Kamailio - the Open Source SIP >> Server... >> kamailio[]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received >> systemd[]: kamailio.service: Deactivated successfully. >> systemd[]: Stopped kamailio.service - Kamailio - the Open Source SIP >> Server. >> >> I stopped kamailio with >> >> systemctl stop kamailio >> >> I'm sure that something was inside the htable before I stoped kamailio: >> >> { >> entry: 0 >> size: 1 >> slot: { >> { >> name: >> 07db580a6c13e798a5acc0d123d6e957897c8650b43f99d6d5cb9c2cb5ba4fa4 >> value: >> 3a28dcb73eb65722df5a261983b7692cecdca482bf8725032e46a0c6b89fb355 >> type: str >> } >> } >> } >> >> Any further ideas? >> >> Best regards, >> >> Bernd >> >> >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> To unsubscribe send an email tosr-users-leave(a)lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only >> to the sender! >> Edit mailing list options or unsubscribe: -- EDNT GmbH Werner-von-Siemens-Strasse 7 64625 Bensheim www.ednt.de Registergericht: Darmstadt Registernummer: 24972 Geschäftsführer: Karlheinz Knapp

1 0

Kamailio 5.6.4 and htable dbmode=1
by Bernd Krueger-Knauber 17 Jul '23

17 Jul '23

Hi, I just tried to use sqlite and htable to load and save the values. At start I can see in the log, that all parameters are correct and that htable want to load the values from the table. No errors. But if I stop kamailio, nothing is written to the tables. At start I can see: kamailio[]: DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'htable' matches module 'htable' kamailio[]: DEBUG: <core> [core/sr_module.c:814]: find_param_export(): found <htable> in module htable [/usr/lib/x86_64-linux-gnu/kamailio/modules/htable.so] kamailio[]: DEBUG: <core> [core/modparam.c:128]: set_mod_param_regex(): found <htable> in module htable [/usr/lib/x86_64-linux-gnu/kamailio/modules/htable.so] kamailio[]: DEBUG: htable [ht_api.c:1046]: ht_table_spec(): htable [callpush] - dbmode [1] kamailio[]: DEBUG: htable [ht_api.c:1027]: ht_table_spec(): htable [callpush] - dbtable [userpush] kamailio[]: DEBUG: htable [ht_api.c:1036]: ht_table_spec(): htable [callpush] - expire [86400] kamailio[]: DEBUG: htable [ht_api.c:1041]: ht_table_spec(): htable [callpush] - size [10] kamailio[]: DEBUG: htable [ht_api.c:1084]: ht_db_load_tables(): loading db table [userpush] in ht [userpush] kamailio[]: DEBUG: htable [ht_db.c:232]: ht_db_load_table(): =============== loading hash table [userpush] from database [userpush] kamailio[]: DEBUG: db_sqlite [dbase.c:223]: db_sqlite_submit_query(): submit_query: select key_name,key_type,value_type,key_value from userpush order by key_name kamailio[]: DEBUG: <core> [db_query.c:72]: db_do_submit_query(): submitted query: select key_name,key_type,value_type,key_value from userpush order by key_name, result 0 kamailio[]: DEBUG: <core> [db_res.c:119]: db_new_result(): allocate 56 bytes for result set at 0x7f4882107938 kamailio[]: DEBUG: <core> [db_res.c:79]: db_free_columns(): freeing 0 columns kamailio[]: DEBUG: <core> [db_res.c:138]: db_free_result(): freeing result set at 0x7f4882107938 Ok, the file is empty, but it tries to load the data from the table. The table looks like: sqlite> .schema userpush CREATE TABLE userpush ( key_name TEXT, "key_type" INTEGER, value_type INTEGER, key_value TEXT ); I checked the source code and I saw that destroy() should be called. Inside is ht_db_open_con() called before ht_db_sync_tables(), were it happens. But I can even not see the debug message from ht_db_open_con() : LM_DBG("database connection opened successfully\n") and also not LM_ERR("failed to connect to the database\n"); For me it looks like, that the destroy() function is not called. Even with debug=3, I can only see: systemd[]: Stopping kamailio.service - Kamailio - the Open Source SIP Server... kamailio[]: INFO: <core> [main.c:854]: sig_usr(): signal 15 received systemd[]: kamailio.service: Deactivated successfully. systemd[]: Stopped kamailio.service - Kamailio - the Open Source SIP Server. I stopped kamailio with systemctl stop kamailio I'm sure that something was inside the htable before I stoped kamailio: { entry: 0 size: 1 slot: { { name: 07db580a6c13e798a5acc0d123d6e957897c8650b43f99d6d5cb9c2cb5ba4fa4 value: 3a28dcb73eb65722df5a261983b7692cecdca482bf8725032e46a0c6b89fb355 type: str } } } Any further ideas? Best regards, Bernd

2 1

Using Kamailio in front of Freeswitch for load balancing REG and Calls
by Shah Hussain Khattak 12 Jul '23

12 Jul '23

Hello Awesome people, I have configured Kamailio in front of two Freeswitch servers. I am using the dispatcher module to load and balance the traffic between the two FS boxes. My dispatcher is configured in a round-robin fashion. If I send a register to my FS servers, the re-register post-challenge (401) message is routed to the second FS server and the registration fails. I want to check with you guys how are you handling this in your setups. I am sure a lot of companies are using Kamailio to load balance traffic toward the FS and Asterisk servers. UAC --- > Kamailio --- > FS1 REG ---- > REG ---- > REG 401 <---- 401 < ---- 401 re-register with authorization data: UAC --- > Kamailio --- > FS2 REG --- > REG ---- > REG 401 <---- 401 < ---- 401 it just create this loop and register fails. Ideally, I want Kamailio to send the re-register (with auth data) to the same FS server that challenged it. Any ideas or pointers to fix this issue would be highly appreciated, maybe I am missing some very basic configuration. Or maybe there is another simpler way instead of using a dispatcher module. Thank you! Regards, Shah Hussain

2 4

Re: sr-users Digest, Vol 218, Issue 16
by satyaprakash ch 11 Jul '23

11 Jul '23

Hi Please find some more before and after, Ip address and number is masked FYI. INFO: <script>: TIME : TEST - Rewriting To header with Request line so that vendor prefix is present INFO: <script>: TIME : TEST2 - tu is sip:+123456789@10.0.77.88 and ru is sip:10.0.1.47:5060 INFO: <script>: TIME : TEST3 - tu is sip:+123456789@10.0.77.88 and ru is sip:10.0.1.47:5060 ERROR: tm [tm.c:1752]: _w_t_relay_to(): t_forward_noack failed ERROR: tm [t_reply.c:1081]: run_failure_handlers(): error running run_top_route for failure handler INFO: <script>: TIME : [Mon Jul 10 12:24:14 2023] CALL ID : [31bca077-99fa-123c-eb84-00219b9e3ef4] [WITHINDIALOG] The request is [ACK] INFO: <script>: TIME : [Mon Jul 10 12:24:14 2023] CALL ID : [31bca077-99fa-123c-eb84-00219b9e3ef4] [PROXY_OUTBOUND_HANDLE] [ACK] INFO: <script>: TIME : [Mon Jul 10 12:24:14 2023] CALL ID : [ 205526695_49743609(a)206.147.84.20] [WITHINDIALOG] The request is [ACK] Here is the code i suspect, Let me know if you can find some thing why the error usually gets, *failure_route["serial"] { if (!t_next_contacts()) { exit; } t_on_failure("serial"); xlog("L_INFO","TIME : [$Tf] CALL ID : [$ci] [serial]The altered ruri is [$ru] \n"); xlog("L_INFO", "TIME : TEST - Rewriting To header with Request line so that vendor prefix is present"); xlog("L_INFO","TIME : TEST2 - tu is $tu and ru is $ru \n"); $tu = $ru; xlog("L_INFO","TIME : TEST3 - tu is $tu and ru is $ru \n"); t_relay();}event_route[tm:branch-failure:REMOVE_OLD_REGISTER] { if (t_check_status("(404)|(410)")) { xlog("L_INFO","TIME : Received code [$T(reply_code)] from SBC, need to remove registration \n"); xlog("L_INFO","TIME : [$Tf] CALL ID : [$ci] [REMOVE_OLD_REGISTER] contact is [$ct]Unregister section is entered [$ru] \n"); unregister("location", "$tu", "$T_reply_ruid"); }}* Thank you. On Tue, Jul 11, 2023 at 3:46 PM <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. Need an error description (satyaprakash ch) > 2. Re: Need an error description (Alex Balashov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Jul 2023 22:25:31 +0530 > From: satyaprakash ch <chiramchetty.satyaprakash(a)gmail.com> > Subject: [SR-Users] Need an error description > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.kamailio.org> > Message-ID: > < > CAO-xAtGhcDMiPtoGdBeb6qvhOg8u7hxKt-w-5oU4KuOkdRHuqg(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="0000000000005a4339060024dadd" > > Hi, > > Can anyone help me with the error why can we get this? > > ERROR: tm [tm.c:1752]: _w_t_relay_to(): t_forward_noack failed ERROR: tm > [t_reply.c:1081]: run_failure_handlers(): error running run_top_route for > failure handler > > Thank you. >

2 1

Need an error description
by satyaprakash ch 10 Jul '23

10 Jul '23

Hi, Can anyone help me with the error why can we get this? ERROR: tm [tm.c:1752]: _w_t_relay_to(): t_forward_noack failed ERROR: tm [t_reply.c:1081]: run_failure_handlers(): error running run_top_route for failure handler Thank you.

2 1

event_route[tm:local-response] only executes a few times
by Kaufman 10 Jul '23

10 Jul '23

Hello, I'm writing a 302 redirect server and wanting to capture some events on all replies, so I'm trying to do this in event_route[tm:local-response], but I noticed that the event route is only called a few times for the first few requests, and then never gets executed again. This is the simplest case in which I can reproduce the issue: #!KAMAILIO loadmodule "pv" loadmodule "tm" loadmodule "xlog" route { xinfo("[$rm $ci-$cs] Src:[$si:$sp] RURI:[$ru] To:[$tu] From:[$fu]\n"); t_send_reply("404", "Not Found"); exit; } event_route[tm:local-response] { xcrit("[$rm $ci-$cs] tm:local-response replied locally\n"); } If I start Kamailio with kamailio -ddDDeE it has 8 children. If I use sipp to send 10 requests, this is what I see in the kamailio logs. The critical line in the event route is only printed four times. This is tested on 5.7.0 and 5.6.4 9(66) INFO: <script>: [INVITE 1-14(a)172.26.0.3-1<mailto:1-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 9(66) CRITICAL: <script>: [INVITE 1-14(a)172.26.0.3-1<mailto:1-14@172.26.0.3-1>] tm:local-response replied locally 10(67) INFO: <script>: [ACK 1-14(a)172.26.0.3-1<mailto:1-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 11(68) INFO: <script>: [INVITE 2-14(a)172.26.0.3-1<mailto:2-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 11(68) CRITICAL: <script>: [INVITE 2-14(a)172.26.0.3-1<mailto:2-14@172.26.0.3-1>] tm:local-response replied locally 12(69) INFO: <script>: [ACK 2-14(a)172.26.0.3-1<mailto:2-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 13(70) INFO: <script>: [INVITE 3-14(a)172.26.0.3-1<mailto:3-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 13(70) CRITICAL: <script>: [INVITE 3-14(a)172.26.0.3-1<mailto:3-14@172.26.0.3-1>] tm:local-response replied locally 14(71) INFO: <script>: [ACK 3-14(a)172.26.0.3-1<mailto:3-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 15(72) INFO: <script>: [INVITE 4-14(a)172.26.0.3-1<mailto:4-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 15(72) CRITICAL: <script>: [INVITE 4-14(a)172.26.0.3-1<mailto:4-14@172.26.0.3-1>] tm:local-response replied locally 16(73) INFO: <script>: [ACK 4-14(a)172.26.0.3-1<mailto:4-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 9(66) INFO: <script>: [INVITE 5-14(a)172.26.0.3-1<mailto:5-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 10(67) INFO: <script>: [ACK 5-14(a)172.26.0.3-1<mailto:5-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 11(68) INFO: <script>: [INVITE 6-14(a)172.26.0.3-1<mailto:6-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 12(69) INFO: <script>: [ACK 6-14(a)172.26.0.3-1<mailto:6-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 13(70) INFO: <script>: [INVITE 7-14(a)172.26.0.3-1<mailto:7-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 14(71) INFO: <script>: [ACK 7-14(a)172.26.0.3-1<mailto:7-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 15(72) INFO: <script>: [INVITE 8-14(a)172.26.0.3-1<mailto:8-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 16(73) INFO: <script>: [ACK 8-14(a)172.26.0.3-1<mailto:8-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 9(66) INFO: <script>: [INVITE 9-14(a)172.26.0.3-1<mailto:9-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 10(67) INFO: <script>: [ACK 9-14(a)172.26.0.3-1<mailto:9-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 11(68) INFO: <script>: [INVITE 10-14(a)172.26.0.3-1<mailto:10-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 12(69) INFO: <script>: [ACK 10-14(a)172.26.0.3-1<mailto:10-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] Kaufman

2 2

Random number
by Ali Taher 07 Jul '23

07 Jul '23

Hello, As per Kamailio documentation, $RANDOM returns a random value from the [0 - 2^31) range. But when testing it it's always returning a random number of 9 or 10 digits. I'm not sure if it's always the case or if it can also returns numbers with 1 or 2 digits as well. Another question, how can I force it to return a number of specific digits starting with certain prefix. Regards,

2 1

Finding a way to gracefully restart kamailio with dialog module enabled and DMQ sync
by Benoît Panizzon 07 Jul '23

07 Jul '23

Hi Gang We are still having massive issues on how to safely reload kamailio after config changes when using the dialog module and DMQ. If there are active dialogues, kamailio corrupts them on a restart even when using MySQL as dialog backend. As we use two core nodes for redundancy, I am looking for a way to gracefully restart kamailio. I am considering adding some key in a hash table or anything else I can reload on runtime to indicate to kamailio not to accept any new calls (effectively rejecting Invites without To-Tag with 503 causing the registrar or IC peer to hopefully resend the invite to the other node). Then wait, until no more dialogues are active, so kamailio can safely be restarted. My Issue now: How can I find out, one specific node does not have any active dialogues? 'kamcmd dlg.stats_active' returns the count of all DMQ synced nodes, not of the local one. And suggestions or any other ideas how I can 'reload' the kamailio config without disrupting active dialogues? My last resort would be to look into the database: modparam("dialog", "h_id_start", -1) # Use server_id modparam("dialog", "h_id_step", 2) So odd/even H_ID should tell me the number per node. But I see a lot of orphan dialogues hanging around in the database not being cleaned so I guess that will not be reliable at all. Yes, I know I will get the question: 'Why do you need to restart kamailio that often'. We have started production on our kamailio based TSP platform. And of course, despite a LOT of testing beforehand, there is always some issue that pops up. At the moment, I have to implement a config change about once or twice a week to fix some new minor issues. I hope, somewhen in the future we will hopefully have a stable config which will last for several months, but at the moment this is the situation. -- 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 4

Randomize calling number
by Ali Taher 06 Jul '23

06 Jul '23

Hello, What is the best way to change the calling number to a random number (based on specific pattern, like number of digits for example) in an invite packet without using a database. So the scenario is : * receive an invite packet from certain source * change the calling number * send back the invite packet including the new calling number to the original source. Regards, Ali Taher

3 7

302 Handling issue in failure route
by Devang Dhandhalya 05 Jul '23

05 Jul '23

Hello All I am handling 302 response in the failure route and when receiving 302 response in kamailio, it's not going into the failure route , kamailio just executing the onreply route when 302 response are received. A few days ago the same code with failure route worked but now it does not. i dont know why kamailio is not executing a failure route from where we can redirect calls to another server. code snippet route[RELAY]{ t_on_reply("MANAGE_REPLY"); t_on_failure("MANAGE_FAILURE"); t_on_branch("MANAGE_BRANCH"); if (!t_relay()) { sl_reply_error(); } exit; } failure_route[MANAGE_FAILURE] { if (t_is_canceled()) { exit; } if (t_check_status("302")){ get_redirects("*"); $ru= $T_rpl($sel(contact.uri)); route(RELAY); } } kamailio version : 5.6.4 Please suggest if I am doing anything wrong. -- Regards, *Devang Dhandhalya* -- *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.

3 3

SL absorbed ACK is counted as dropped by core.drop_requests
by Kaufman 03 Jul '23

03 Jul '23

Just checking to see if this is the designed behavior. The SL module will attempt to match ACKs for stateless replies and handle them (absorb them?). The question I have is that it looks as though this ACK gets counted as dropped by the core.drop_requests from the KEX module. Tested using this config: #!KAMAILIO loadmodule "pv" loadmodule "sl" loadmodule "xlog" loadmodule "kex" loadmodule "corex" loadmodule "ctl" modparam("sl", "bind_tm", 0) route { xinfo("[$ci] $rm Request. Src:[$si:$sp] RURI:[$ru] To:[$tu] From:[$fu]\n"); sl_send_reply("404", "Not Found"); } event_route[sl:filtered-ack] { xnotice("sl:filtered-ack ACK [$ci] to local reply absorbed\n"); } Then validate by kamcmd stats.fetch core:drop_requests Is this the designed and "correct" behavior? Kaufman

3 4

Kamailio v5.7.1 Released
by Daniel-Constantin Mierla 28 Jun '23

28 Jun '23

Hello, Kamailio SIP Server v5.7.1 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.0. 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.1. For more details about version 5.7.1 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/06/kamailio-v5-7-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 -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - www.kamailioworld.com

1 0

Forward Registration
by nutxase 28 Jun '23

28 Jun '23

Hi All I have setup kamailio using websockets(wss) i am trying to forward any registration that comes to kamailio to go to asterisk, so in theory kamailio is a registration proxy i have set rewritehostport("xxx.xxx.xxx[:5080](http://node3.sipalto.com:5080)"); the registration forwards fine but the contact on asterisk side shows as sip:xxx:kamailioip.xxxx.invalid so therefore asterisk sees the sip peer as offline what am i missing :( Sent with [Proton Mail](https://proton.me/) secure email.

1 0

Releasing v5.7.1
by Daniel-Constantin Mierla 28 Jun '23

28 Jun '23

Hello, I am considering to release Kamailio v5.7.1 (out of branch 5.7) this week (likely on Wednesday or Thursday, Jun 28/29, 2023). 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 -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - www.kamailioworld.com

1 1

Matching the From Username in LCR rule table
by harneet singh 27 Jun '23

27 Jun '23

Hi Experts, We wished to used the LCR Module to be able to select the Gateway(s) to send the calls to based on the From(Caller) Username. Based on the LCR Documentation, the usage of other fields like request URI or prefix etc is pretty clear. But for the From Usename I am having certain trouble understanding the same. It refers to some mtree. Excerpt below: "A gateway matches a request if user part of Request-URI matches "prefix", caller URI matches "from_uri" pattern,* caller URI userpart matches mtree with "mt_value"*, and callee URI matches "request_uri" pattern in a tuple that is associated with the gateway." Can someone explain/ share a sample lcr_rule table entries for the From Username that can be matched against the incoming sip message for gw selection? Do we need to manually create an mtree by the name "*lcr*". Asking based on the below section in LCR documentation? Any pointers are highly appreciated. 3.35. mtree (string) Name of mtree to which load_gws() matches caller URI userpart. *Default value is "lcr".* Regards, Harneet Singh -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

2 3

uac_replace() and uac_restore debug help
by Duarte Rocha 24 Jun '23

24 Jun '23

Hello, I'm currently experiencing some odd behaviours when using these functions and I need some help debugging to find the root of the issue. I receive a call from a client and do some changes to the To and From header using auto mode with password. Encrypted info goes on the Record-Route header parameters (vsf\vst) normally. 1 - On subsequent requests sent by the originating client, domains on To and From header are different from the ones sent in the first INVITE. In this scenario, somehow the automatic modifying has errors on the end result. Can the different domains affect the end result of the automatic modifying or only the vsf\vst parameters and password are needed to the auto replace\restore? 2 - How can I decrypt the info on vsf and vst parameters in order to verify the info sent and the encryption? Cheers, Duarte Rocha

2 1

uac_restore behaviour question
by Duarte Rocha 22 Jun '23

22 Jun '23

Hello, I have some questions regarding uac_replace methods. When I receive the first INVITE from someone I change To and From using uac_replace_to() and uac_replace_from(). I do this only on first INVITES. In order to restore them I use the "auto" so the changes are restored automatically in replies or requests sent to the call originator.. In the case of subsequent requests from the originator kamailio still changes To and From without me using uac_replace functions. Is this caused by the auto restore? Does it work for both sides and is this is the intended behaviour? Cheers

1 1

How to handle 302 redirects
by Trey Ormsbee 22 Jun '23

22 Jun '23

Hello, Im having a hard time figuring out how to handle a 302 reidrect, the uac_redirect modules shows a simple configuration. However for me, what it is not doing is changing the 302 back to invite. It is sending the 302 as is on. if(!t_check_status("3[0-9][0-9]")) { exit; } get_redirects("3:1"); t_relay(); This code just relays the 302 for me. I should add I am using this with the DISPATCHER module so perhaps that has something to do with my issue. Setup is this, kamailio is sitting between to sip servers, so the flow goes like this, sip_server_a -> kamailio -> sip_server_b. sip_server_b only responds with 302 redirects, sip_server_a does not handle 302’s at all. Kamailio will only get invites from sip_server_a, and the redirects from sip_server_b will only have one contact. How can I get kamailio to reply to sip_server_a’s invite with the updated INVITE? My config is a mesh of the dispatcher example and uac_redirect example with this specific section handling the redirect: # Sample failure route failure_route[RTF_DISPATCH] { xlog("L_NOTICE", "RTF_DISPATCH: "); if (t_is_canceled()) { exit; } # next DST - only for 500 or local timeout if (t_check_status("500") or (t_branch_timeout() and !t_branch_replied())) { if(ds_next_dst()) { t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } } if (t_check_status("302")) { xlog("L_NOTICE", "RTF_DISPATCH: 302 "); if (!get_redirects("1:1")) { xlog("L_NOTICE", "RTF_DISPATCH: failed to get_redirects "); t_reply("480", "Temporarily Unavailable"); exit; } xlog("L_NOTICE", "RTF_DISPATCH: got redirects "); t_relay(“sip_server_a”,”5060”); } } Any ideas what I am doing wrong is this supported? Im expecting once I relay this message that it should be an INVITE not a 302 redirect. I cant find any examples of anyone else really doing this.

3 3

Missing posops module from 5.7 debian repo
by Patrick Karton 20 Jun '23

20 Jun '23

hello , i have installed kamailio 5.7 from debian repo http://deb.kamailio.org/kamailio57 bullseye main but i dont find the posops module in the directory modules. what is the exactly package where i can find it. Thanks.

2 5

KEMI
by iliusha.md＠gmail.com 19 Jun '23

19 Jun '23

Hello, I have the following statement: if KSR.is_method("INVITE") then KSR.log("info", "method not allowed " .. KSR.kx.get_method() .."\n"); KSR.x.exit(); end For some reason, it falls into this condition no matter which method I use, I tried OPTIONS, NOTIFY etc. log file: <core> [core/kemi.c:152]: sr_kemi_core_log(): method not allowed OPTIONS the same with this check: if KSR.is_method_in("I") then KSR.log("info", "method not allowed " .. KSR.kx.get_method() .."\n"); KSR.x.exit(); end this is the lua modparam settings: # ---- lua params ---- modparam("app_lua", "load", "/usr/local/etc/kamailio/main.lua") modparam("app_lua", "reload", 1) modparam("app_lua", "log_mode", 1) cfgengine "lua" version: kamailio 5.7.0 (x86_64/linux) 1c23c2 Any idea what I'm doing wrong?

2 1

Kamailio failover in aws/azure environment
by M Arqum CH 17 Jun '23

17 Jun '23

Hi members, I am setting up kamailio as loadbalcer for asterisk server farm with active-backup conf in Azure cloud using azure loadbalcer, for incoming it works fine external incoming traffic with nated external IP, can any one guide how to do active-backup configuration for internal traffic, as asterisk servers are running on local network. Thanks and regards Arqum

2 1

TLS errors
by nutxase 16 Jun '23

16 Jun '23

Hey All I have been setting up TLS and websocket for kamailio but i keep getting these errors in the log please can someone help me Jun 14 20:51:57 so-sbc-02 /usr/sbin/kamailio[25490]: ERROR: tls [tls_util.h:51]: tls_err_ret(): TLS accept:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (sni: [sip.domain.com](http://sip.sipalto.com)) Jun 14 20:51:57 so-sbc-02 /usr/sbin/kamailio[25490]: ERROR: tls [tls_server.c:1333]: tls_h_read_f(): src addr: 1.2.3.4.5:57265 Jun 14 20:51:57 so-sbc-02 /usr/sbin/kamailio[25490]: ERROR: tls [tls_server.c:1336]: tls_h_read_f(): dst addr: 5.4.3.2.1:8089Jun 14 20:51:57 so-sbc-02 /usr/sbin/kamailio[25490]: ERROR: <core> [core/tcp_read.c:1478]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f3c8fc16720 r: 0x7f3c8fc16848 (-1) my config is pretty standard so i am not sure what i am missing using letsencrypt certs #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "tls_method", "TLSv1.2+") modparam("tls", "certificate", "/etc/kamailio/tls/cert.pem") modparam("tls", "private_key", "/etc/kamailio/tls/ckey.pem") modparam("tls", "ca_list", "/etc/kamailio/tls/fullchain.pem")#!endif Sent with [Proton Mail](https://proton.me/) secure email.

3 5

impossible to modify $tU twice
by David VILLAUME 15 Jun '23

15 Jun '23

Hello, I’m in a scenario where i would apply different modification to $tU to User with KEMI, but I can’t achieve it. I managed to reproduce it with legacy config : Scenario 1 (both values concatenates): route[dbg] { $tU ="aaa"; $tU ="bbb"; } To: sip:aaabbb@5.5.5.5 Scenario 1 (both values concatenates and @ disapears): route[dbg] { $tU ="aaa"; $tU=$null; $tU ="bbb"; } To: sip:aaabbb5.5.5.5 --->without @ I tried different combination with [*] as for avps without success, does anyone have an idea about how to perform it ? Regards, David

3 2

Cannot achieve rtpengine HA
by Arsenijs Kabihno 13 Jun '23

13 Jun '23

Hello, We are trying to achieve rtpengine HA solely with kamailio and rtpengine module. In the following example call goes to rtpengine node 10.5.0.183:22222 and then we stop rtpengine service on this node to simulate failure. Client is triggering re-INVITE, but, apparently, kamailio sticks to initially selected rtpengine, producing the following errors: Jun 12 06:59:48 ap07stvp.xxxxxxx.xxx docker[9373]: 27(33) INFO: {2 2 INVITE jdl9kq6fv51jcv1agk2e} <script>: RTPENGINE branch_id:0 ruri: <null>, method:INVITE, status:200, extra_id: z9hG4bK55018600, rtpengine_answer: replace-origin replace-session-connection SIP-source-address direction=priv1 direction=pub1 SIP-source-address via-branch=extra rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF Jun 12 06:59:49 ap07stvp.xxxxxxx.xxx docker[9373]: 27(33) NOTICE: {2 2 INVITE jdl9kq6fv51jcv1agk2e} acc [acc.c:287]: acc_log_request(): ACC: transaction answered: timestamp=1686553189;method=INVITE;from_tag=fcn109nfe9;to_tag=01284cc8-bc58-4104-9629-8e6bb827d97f;call_id=jdl9kq6fv51jcv1agk2e;code=200;reason=OK;src_user=90362;src_domain=10.181.0.1;src_ip=10.5.0.145;dst_ouser=123;dst_user=123;dst_domain=10.181.0.1 Jun 12 06:59:49 ap07stvp.xxxxxxx.xxx docker[9373]: 31(37) INFO: {2 2 INVITE jdl9kq6fv51jcv1agk2e} <script>: RTPENGINE branch_id:0 ruri: <null>, method:INVITE, status:200, extra_id: z9hG4bK55018600, rtpengine_answer: replace-origin replace-session-connection SIP-source-address direction=priv1 direction=pub1 SIP-source-address via-branch=extra rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF Jun 12 06:59:49 ap07stvp.xxxxxxx.xxx docker[9373]: 51(57) INFO: {1 2 ACK jdl9kq6fv51jcv1agk2e} <script>: RTPENGINE branch_id:0 ruri: sip:10.5.2.192:5060, method:ACK, status:<null>, extra_id: <null>, rtpengine_offer: replace-origin replace-session-connection SIP-source-address direction=pub1 direction=priv1 SIP-source-address rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP Jun 12 06:59:49 ap07stvp.xxxxxxx.xxx docker[9373]: 51(57) INFO: {1 2 ACK jdl9kq6fv51jcv1agk2e} <script>: RTPENGINE branch_id:0 ruri: sip:10.5.2.192:5060, method:ACK, status:<null>, extra_id: <null>, rtpengine_offer: replace-origin replace-session-connection SIP-source-address direction=pub1 direction=priv1 SIP-source-address rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP Jun 12 07:01:26 ap07stvp.xxxxxxx.xxx docker[9373]: 27(33) INFO: {2 3 INVITE jdl9kq6fv51jcv1agk2e} <script>: RTPENGINE branch_id:0 ruri: <null>, method:INVITE, status:200, extra_id: z9hG4bK20888040, rtpengine_answer: replace-origin replace-session-connection SIP-source-address direction=priv1 direction=pub1 SIP-source-address via-branch=extra rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF Jun 12 07:01:26 ap07stvp.xxxxxxx.xxx docker[9373]: 27(33) ERROR: {2 3 INVITE jdl9kq6fv51jcv1agk2e} rtpengine [rtpengine.c:3070]: send_rtpp_command(): can't send command "offer" to RTPEngine <udp:10.5.0.183:22222> Jun 12 07:01:26 ap07stvp.xxxxxxx.xxx docker[9373]: 54(60) INFO: {1 3 ACK jdl9kq6fv51jcv1agk2e} <script>: RTPENGINE branch_id:0 ruri: sip:10.5.2.192:5060, method:ACK, status:<null>, extra_id: <null>, rtpengine_offer: replace-origin replace-session-connection SIP-source-address direction=pub1 direction=priv1 SIP-source-address rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP Jun 12 07:01:26 ap07stvp.xxxxxxx.xxx docker[9373]: 54(60) ERROR: {1 3 ACK jdl9kq6fv51jcv1agk2e} rtpengine [rtpengine.c:2706]: rtpp_function_call(): no available proxies We also found Daniel answer on similar issue here: https://github.com/kamailio/kamailio/issues/2713#issuecomment-823138302 Please advise how it can be solved. Kind regards, Arsenijs

4 5

Carrierroute Test API?
by sr.maillists＠gmail.com 13 Jun '23

13 Jun '23

Hi List Does someone know a function to test a number against the carrierroute module, to see which route it picked? My Idea: We have multiple Kamailio-Proxies and I would like to test a number against all hosts to see where it will be routed, without performing testcalls. Regards Stefan

2 1

Kamailio/MySQL Module compatibility with MySQL 8.0+
by Pedro Ulhoa 13 Jun '23

13 Jun '23

Hello friends. I didn't find about it in the documentation, but I will need to update my database version to MySQL 8.0.32 and I'm using Kamailio version 5.4. I did some quick tests, and I only needed to adjust the user due to the authentication mode, and with that, apparently I had no problems. I would like to know if you are using Kamailio with the latest version of MySQL, if you have had any problems in production, and if it really is safe to upgrade. -- Aviso Legal: Este documento pode conter informações confidenciais e/ou privilegiadas. Se você não for o destinatário ou a pessoa autorizada a receber este documento, não deve usar, copiar ou divulgar as informações nele contidas ou tomar qualquer ação baseada nessas informações. Disclaimer: The information contained in this document may be privileged and confidential and protected from disclosure. If the reader of this document is not the intended recipient, or an employee agent responsible for delivering this document to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

3 2

What is the best way to return a lot of data via JSONRPC and jansson?
by Benoit Panizzon 12 Jun '23

12 Jun '23

Hi Team To offer some diagnose functionality I created an API that returns the location list via JSONRPC But this creates huge variables. Jun 12 09:43:32 prod-cpereg02 kamailio[2174548]: ERROR: <core> [core/pvapi.c:1491]: pv_printf_mode(): no more space for spec value - printed:0 token:8599 buffer:8192 Jun 12 09:43:32 prod-cpereg02 kamailio[2174548]: ERROR: <core> [core/pvapi.c:1503]: pv_printf_mode(): buffer overflow -- increase the buffer size... Already hitting the default limit and not sure this is the right way to go as we will end up with thousands of registrations. What is the best way to return larger ammounts of data out of kamailio? Avoid using the JSONRPC and access the database externally? 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

Dialog DMQ state after restart
by Calvin E. 10 Jun '23

10 Jun '23

Does the dialog module do anything similar to the htable dmq_init_sync behavior? The scenario is restarting the offline member of an HA pair after modifying the script. We're unsure of the state of the replicated dialogs post-restart. Will the standby become aware of the dialogs prior to the restart? In other words, do we need to wait until the pre-restart calls end before we can safely failover? -Calvin E.

5 7

Kamailio - could not allocate private memory from pkg pool
by Muhammad Danish Moosa 09 Jun '23

09 Jun '23

Hi, I have been kamailio services working for few months and suddenly I got this error. ERROR: <core> [core/kemi.c:2923]: sr_kemi_pv_sets(): unable to set pv [$rp] ERROR: <core> [core/pvapi.c:352]: pv_cache_add(): could not allocate private memory from pkg pool ERROR: <core> [core/kemi.c:2914]: sr_kemi_pv_sets(): cannot get pv spec for [$dlg_var(BW0930526150606231188928742(a)10.10.16.100)] ERROR: <core> [core/data_lump.c:544]: dup_lump_list_r(): could not allocate private memory from pkg pool ERROR: <core> [core/data_lump.c:582]: dup_lump_list_r(): out of mem ERROR: tm [t_fwd.c:1759]: t_forward_nonack(): failure to add branches ERROR: <core> [core/msg_translator.c:2501]: build_res_buf_from_sip_req(): could not allocate private memory from pkg pool ERROR: sl [sl_funcs.c:414]: sl_reply_error(): stateless error reply used: I'm terribly sorry, server error occurred (1/SL) ERROR: <core> [core/msg_translator.c:2501]: build_res_buf_from_sip_req(): could not allocate private memory from pkg pool ERROR: tm [t_reply.c:475]: _reply_light(): response building failed WARNING: tm [t_lookup.c:1499]: t_unref(): generation of a delayed stateful reply failed Issue was fixed after the restart of kamailio. -- Muhammad Danish Moosa " The core of mans' spirit comes from new experiences. "___ Christopher McCandless

4 10

Kamailio World
by Fred Posner 05 Jun '23

05 Jun '23

1 0

Invalid Links
by Brandon Armstead 04 Jun '23

04 Jun '23

https://www.kamailio.org/w/kamailio-v5-7-0-release-notes/ article references math module and tls_wolfssl, 2 of the 4 modules mentioned link back to 5.6 (these two) instead of 5.7 resulting in a 404. Respective links should be as follows: math - https://www.kamailio.org/docs/modules/5.7.x/modules/math.html tls_wolfssl - https://www.kamailio.org/docs/modules/5.7.x/modules/tls_wolfssl.html Can we get a correction in the article on WP? Thanks - Brandon

1 0

header from failure_route
by David Villasmil 04 Jun '23

04 Jun '23

Hello guys, so i'm doing on a failure_route: $var(xgws_in_reply) = $T_rpl($hdr(X-GWs)); which when it’s present on the reply is cool… but when there is NO REPLY, then kamailio sets it to “0”… anyway over this? i only want to know whether it is present on the reply Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 2

Missing transformations for {val.*}?
by Kaufman 03 Jun '23

03 Jun '23

Beginning in 5.6 new {val.*} transformations are documented as being exported by the pv module, however if I try using it Kamailio fails to start. Wondering if maybe it's actually imported by another module and the documentation is wrong or something like that? This configuration in 5.6.3 on Alpine Linux installed from packages: #!KAMAILIO loadmodule "pv" loadmodule "xlog" request_route { xlog("Null val: $(avp(nothing){val.ne})\n"); exit; } Fails to start with the following: 0(114) INFO: <core> [main.c:3055]: main(): processes (at least): 29 - shm size: 67108864 - pkg size: 8388608 0(114) ERROR: <core> [core/pvapi.c:1774]: tr_lookup(): unknown transformation: [val] in [{val.ne}] 0(114) ERROR: <core> [core/pvapi.c:1799]: tr_lookup(): error parsing [{val.ne}] 0(114) ERROR: <core> [core/pvapi.c:1106]: pv_parse_spec2(): bad tr in pvar name "avp" 0(114) ERROR: <core> [core/pvapi.c:1131]: pv_parse_spec2(): invalid parsing in [$(avp(nothing){val.ne})] at (4) 0(114) ERROR: xlog [xlog.c:551]: xdbg_fixup_helper(): wrong format[Null val: $(avp(nothing){val.ne})] 0(114) ERROR: <core> [core/route.c:1169]: fix_actions(): fixing failed (code=-1) at cfg:/etc/kamailio/kamailio.cfg:7 Kaufman Sr. VoIP Engineer - BCM One +1.612.735.9309 bkaufman(a)bcmone.com<mailto:bkaufman@bcmone.com> 24 hour client support: +1.855.639.6300 [https://www.bcmone.com/files/bcmone-logo.png]<https://www.bcmone.com/> [https://www.bcmone.com/files/twitter-icon-circle.png] <https://www.facebook.com/bcmonenyc/> [https://www.bcmone.com/files/twitter-icon-circle.png] <https://twitter.com/bcm_one/> [https://www.bcmone.com/files/linkedin-icon-circle.png] <https://www.linkedin.com/company/business-communications-management/> 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 1

custom mid registrar using kamailio.
by Yuriy Nasida 01 Jun '23

01 Jun '23

Hello, https://lists.kamailio.org/pipermail/sr-users/2020-October/110792.html I read this thread very carefully and I think I managed to implement all the steps described by Daniel. Thank you so much for the detailed description. But it looks like I'm stuck on the last step. I can't delete records from htable when an incoming call cannot reach the registered device (e.g., no more internet access, power off at the device). I try to do this from failure route but looks like i kamailio has not access to htable from it. failure_route[INTERNAL_TO_EXTERNAL_FAILURE] { if (t_check_status("408")) { xlog("L_WARN", "$ci|log| hello \n"); xlog("L_WARN", "$ci|log| mid reg token - $sht(mid_reg_token=>$fU::$si::$sp) \n"); } } I do not see xlog message with mid reg token but i see 'hello'. Yes, htable record exists in case i check using: kamcmd htable.dump mid_reg_token Also I need a way to remove registration at the registrar (Freeswitch in my case). This means I need to send api request from kamailio or just run some script that will do this. What is the best way ? module exec ? Please advice, Thanks

2 3

Kamailio and MS Teams side by side present staus und chat function
by Hans-Jürgen Brand 31 May '23

31 May '23

2 1

Is Min-SE check broken?
by harneet singh 31 May '23

31 May '23

Hi All, I am facing an issue in understanding how the min_se should be working in kamailio. As per the SST documentation, it seems like if the min_se is configured as 500, then any value of Session-Expires OR MIN-SE if lower than 500, can be responded to by a 422. However, I strangely see the reverse happening. To investigate further, I looked in to the ki_sst_check_min() code in the master, and these seems like a potential issue. Ref Code: Inside ki_sst_check_min(), there is an if condition like below: if (sst_min_se < MIN(minse, se.interval)) { However, shouldn't it be the other way around? ie if (sst_min_se > MIN(minse, se.interval)) { because we need to send 422 if the received value(in INVITE etc) is smaller than the sst configure min_se value? I also found a different documentation, at https://git.sgu.ru/oldssu/ex-opensips/blob/cb9df8d59dbb254a9d862569fd5d11f6… where the check is as below? if (sst_min_se > MIN(minse, se.interval)) { Can someone confirm if this is broken, or my understanding is incorrect? Regards, Harneet -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

2 3

http_client using JWT?
by Benoît Panizzon 31 May '23

31 May '23

Hi The http_client module support the somehow old fashioned way to submit credentials as part of the URL. Our 'held' server developer would love to use either JWT or a Bearer Token in the Auth-Header or a 'cookie-jar' to authenticate the requests. Is this somehow possible? -- 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 2

Knowing about the uac module with primary and secondary proxy setting
by MUSLIH K 31 May '23

31 May '23

Hi, *sip_provider_proxy1[* uac module-register] ---> *kamailio* [dispatcher Module] ----> *Asterisk1* ----> *Asterisk 2* in my configuration kamailio register to the sip provider using *uac module*, sip information are stored in database (uacreg). when a incoming call(INVITE) come to kamailio it will dispatch call to Asterisk using* "dispatcher module".* Here i have couple of questions 1. If my SIP provider has a secondary proxy as a failover server (sip_provider_proxy2), can I configure Kamailio with the uac module to use the secondary proxy if the primary proxy fails? 2. Since my application is inbound-only, registration failure is only identified when the registration expires (3600 seconds = 1 hour). Can I use the dispatcher module to select the SIP proxy and switch the registration to the secondary proxy if the primary proxy is not reachable (using OPTIONS)?

2 2

DISABLE SDP MEDIA STREAMS
by Patrick Karton 29 May '23

29 May '23

Hello kamailio community, i know its an unusual query but i would like to know if there is a cleaner/proper.right way to disable some (or all) media streams in SDP. i have come with a solution by sdpops module with subst_body function like this. route[SDP_DISABLE_UNAUTHORIZED_MEDIA]{ # disable text,media and video media streams subst_body('#^m=(video|text|audio)[ ]+[0-9/]+(.*)$#m=\1 0 \2#ig'); # update originator ip address subst_body('#^o=([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)$#o=\1 \2 \3 \4 \5 7.7.7.7#ig'); # 1 2 2 4 5 6 # name sid snumber network net-type addr # update connection ip address subst_body('#^c=([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)$#c=\1 \2 7.7.7.7#ig'); # 1 2 3 # network net-type addr #remove all media attributes sdp_remove_line_by_prefix("a=fmtp"); sdp_remove_line_by_prefix("a=X-"); sdp_remove_line_by_prefix("a=rtcp"); sdp_remove_line_by_prefix("a=ssrc"); sdp_remove_line_by_prefix("a=sendrecv"); sdp_remove_line_by_prefix("a=sendonly"); sdp_remove_line_by_prefix("a=recvonly"); sdp_remove_line_by_prefix("a=inactive"); sdp_remove_line_by_prefix("b="); } is it the right way to do it. if not can someone provide me an alternative solution. Thanks :)

3 2

Re: [sr-dev] Troubles with outbound kamailio call to other server
by Henning Westerholt 26 May '23

26 May '23

Hello (added sr-users, as its probably more a usage question). The SIP message (the BYE) cannot be parsed apparently. From the log it looks that there is an invalid character in the first line. Do a network trace to analyse the packets that its actually send and try to get some more clues from that. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com > -----Original Message----- > From: aaron.soto(a)dialapplet.com <aaron.soto(a)dialapplet.com> > Sent: Freitag, 26. Mai 2023 10:44 > To: sr-dev(a)lists.kamailio.org > Subject: [sr-dev] Troubles with outbound kamailio call to other server > > Hi everyone, > I'm having the following errors in kamailio when i try to make an outbound call to > other server, I don't know what does it mean, if some one can help me > > 11(25) ERROR: <core> [core/receive.c:310]: receive_msg(): core parsing of SIP > message failed (XX.XX.XX.XX.5060/1) > 13(27) ERROR: <core> [core/parser/parse_fline.c:271]: parse_first_line(): > parse_first_line: bad message (offset: 65) > 13(27) ERROR: <core> [core/parser/msg_parser.c:681]: parse_msg(): ERROR: > parse_msg: message=<BY > sip:asterisk@10.0.5.158:4080;alias=10.0.5.158~44730~1 SIP/2.0 > Via: SIP/2.0/UDP 84.127.226.15:5060;branch=z9hG4bK3bc90b47;rport > Route: <sip:34.252.151.179:4060;r2=on;lr;ftag=5c7f862f-9692-4028-8af0- > ebc224ba0e2a;vsf=AAAAAAAAAAAAAAAAAAAJCQABGgUAAAMJLjE4ODo1MDYw; > nat=yes>,<sip:10.0.5.40:4070;r2=on;lr;ftag=5c7f862f-9692-4028-8af0- > ebc224ba0e2a;vsf=AAAAAAAAAAAAAAAAAAAJCQABGgUAAAMJLjE4ODo1MDYw; > nat=yes> > Max-Forwards: 70 > From: <sip:692598435@kamailio.voip.svc.cluster.local>;tag=as6f32aa26 > To: <sip:963441038@192.168.123.66:4060>;tag=5c7f862f-9692-4028-8af0- > ebc224ba0e2a > Call-ID: b9a49c52-7829-4cdf-a88c-0064cc5bb438 > CSeq: 102 BYE > User-Agent: Asterisk PBX 11.2-cert3 > X-Asterisk-HangupCause: No user responding > X-Asterisk-HangupCauseCode: 18 > Content-Length: 0 > > > > _______________________________________________ > Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev- > leave(a)lists.kamailio.org

1 0

Consistent huntable responses based on failure_route question
by John Hardiman 25 May '23

25 May '23

Hi Kamailio list, I hope you are all well? I am looking for some assistance on a specific error I am trying to work around. Kamailio 5.5.3 - Ubuntu 20.04 Kemi Python script (but I think this is more default failure_route behaviour) Dispatcher module which hunts to a group of FreeSWITCH that I have configured to send 503 responses on. My scenario is fairly simple, I am trying to respond back to a carrier for huntable responses (503 specifically) by calling a failure route below: def ksr_failure_manage(self, msg): if KSR.tm.t_any_timeout()>0 : self.ksr_send_reply_clear_rtpengine(msg, 503, "Timeout to destination") KSR.err("Timeout to Invite for %s from IP %s" % (KSR.pv.get("$ci"),KSR.pv.get("$si"))) return 1 else: self.ksr_send_reply_clear_rtpengine(msg, 503, "Unknown error failover to next node") KSR.err("Failed but not timeout for %s from IP %s" % (KSR.pv.get("$ci"),KSR.pv.get("$si"))) return 1 This works and a 503 with the correct message is sent if the invite doesn't get a response after 2 seconds. (My specific test case here) # Timers for call setup 2 minutes for any 1xx provisional response received # If no invite response received in 2 seconds end the call as per failure route. KSR.tm.t_set_fr(120000, 2000) self.ksr_route_relay(msg) KSR.tm.t_on_failure("ksr_failure_manage") return -255 The issue is after a few more milliseconds after my initial 503 a 408 is sent. Also after the failover if the carrier tries the same Kamailio again it gets a 500 rather than a 408. 408: [cid:image001.png@01D98F15.CD07DCB0] 500: [cid:image002.png@01D98F15.CD07DCB0] My steps to get around this have been to change the default tm code to 503 below, but this has not changed the default response and the above behaviour unfortunately: # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # setting default reason code and response for general errors to allow failover. modparam("tm", "default_code", 503) modparam("tm", "default_reason", "Unknown reason try next node") My question is: How can I make sure my failure route is the final response here. Or if I cannot make sure of this, how can I change the default mapped response to be a consistent SIP response (503 specifically) Many thanks in advance as I am scratching my head on this one a bit. John.

2 2

Override listen advertise address
by Calvin E. 25 May '23

25 May '23

Using 5.6.x, a scenario designed for a public IP now needs to support life in the cloud behind NAT. I'd like to avoid having two listeners to separate on-net from off-net traffic. In a HA scenario, it would be nice to have only one floating IP. Is it possible to use the same local address and port for external/public and internal/private traffic? Should set_advertised_address() override the listen advertise address? Initial testing did not produce the expected result. I want to make sure I'm following a sane pattern before going down a rabbit hole. The idea is to toggle the advertised address by checking if the sender or recipient is rfc1918(). For the dispatcher module, is it possible to use socket names like below? In testing it appeared that only one of the two names was valid. listen=udp:10.0.0.10:5060 name "onnet" listen=udp:10.0.0.10:5060 advertise 11.11.11.11:5060 name "offnet"

3 4

lost module: best practice handling delay caused by held / lis procedure?
by Benoit Panizzon 25 May '23

25 May '23

Hi gang In 2024, Switzerland will start using NG112 (NG911) procedures to transmit the caller location via Geolocation URL via LIS Server to a PSAP. So time to start testing this on my devel plattform. Kamailio ships with the lost module which looks promising. In short, the Procedure is as follows: Customer calls emergency number. Kamailio performs a http request to our inhouse HELD server with the identification of the calling customer. HELD server looks up the location of the caller and pushes a HELD XML object to the Swiss LIS Server, which then is queried by the emergency PSAP receiving the call. LIS server return and URL. HELD server returns the URL to Kamailio. Kamailio adds Geolocation Header with that URL and relays the call. This takes some time and as the call is not yet being relayed while waiting for the held request to complete, there is no 100 trying being sent and the emergency call is bound to time out. So, shall I call t_reply("100","Performing HELD lkup") before calling the lost module? Or is there a better way? 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 ______________________________________________________

3 7

cancel at first call after startup kamailio not relay
by Giuseppe Pandolfi 23 May '23

23 May '23

Hi, I have a problem with kamailio v 5.6.1 on mips architecture: version: kamailio 5.6.1 (mips/linux) flags: USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX-NOSMP, USE_PTHREAD_MUTEX, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES MAX_RECV_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 14:22:18 Apr 27 2023 Using default script for make a call from sip ua to PSTN system (#!define WITH_PSTN), the cancel sent for the first call after start kamailio doesn't relay to PSTN system and I have the trace error beelow: 2(3203) BUG: {1 27018 CANCEL 0tBgb95Z.0eE5VVrAkoP06nvunIknKNz} tm [t_cancel.c:318]: cancel_branch(): local_cancel buffer=(nil) != BUSY_BUFFER (trying to continue) 12(3203) ERROR: {1 27018 CANCEL 0tBgb95Z.0eE5VVrAkoP06nvunIknKNz} tm [t_fwd.c:1434]: e2e_cancel(): cancel error the next calls works fine. Does anyone have any suggestions? Beelow trace at debug level: 37(3695) INFO: <core> [core/cfg/cfg_ctx.c:602]: cfg_set_now(): core.debug has been changed to 3 37(3695) DEBUG: ctl [io_listener.c:518]: handle_stream_read(): bytes processed: 23 12(3670) DEBUG: <core> [core/parser/parse_fline.c:250]: parse_first_line(): first line type 1 (request) flags 1 12(3670) DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: 12(3670) DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): method: <CANCEL> 12(3670) DEBUG: <core> [core/parser/msg_parser.c:681]: parse_msg(): uri: <sip:100@192.168.2.238:5060> 12(3670) DEBUG: <core> [core/parser/msg_parser.c:683]: parse_msg(): version: <SIP/2.0> 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [Via] type 1 12(3670) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=6 12(3670) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKPjLBcUXshEKW2s9T0en9czTYAsciW1vV-W>; state=16 12(3670) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 12(3670) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 12(3670) DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [From] type 4 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [To] type 3 12(3670) DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=9 12(3670) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [23]; uri=[sip:100@192.168.2.238] 12(3670) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (23)[sip:100@192.168.2.238 ], to tag (0)[] 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [Call-ID] type 6 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [CSeq] type 5 12(3670) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <17038> <CANCEL> 12(3670) DEBUG: <core> [core/receive.c:394]: receive_msg(): --- received sip message - request - call-id: [CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU] - cseq: [17038 CANCEL] 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [User-Agent] type 28 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [Content-Length] type 12 12(3670) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0 12(3670) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/receive.c:471]: receive_msg(): preparing to run routing scripts... 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} maxfwd [mf_funcs.c:74]: is_maxfwd_present(): value = 70 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:247]: check_ruri_sip_version(): check_ruri_sip_version entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:270]: check_ruri_sip_version(): check_ruri_sip_version passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:297]: check_ruri_scheme(): check_ruri_scheme passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:318]: check_required_headers(): check_required_headers entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:340]: check_required_headers(): check_required_headers passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:348]: check_via1_header(): check via1 header 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:506]: check_cseq_method(): check_cseq_method entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:539]: check_cseq_method(): check_cseq_method passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:548]: check_cseq_value(): check_cseq_value entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:576]: check_cseq_value(): check_cseq_value passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:585]: check_cl(): check_cl entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:610]: check_cl(): check_cl passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:622]: check_expires_value(): check_expires_value entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:659]: check_expires_value(): no expires header found 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:758]: check_parse_uris(): check_parse_uris entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:762]: check_parse_uris(): parsing ruri 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:776]: check_parse_uris(): looking up From header 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=Jjj1QBeRxydZ5rq.-xKCfcJZhlPANj9N 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:791]: check_parse_uris(): looking up To header 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:837]: check_parse_uris(): check_parse_uris passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:727]: t_lookupOriginalT(): searching on hash entry 10182 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:440]: matching_3261(): RFC3261 transaction matched, tid=PjLBcUXshEKW2s9T0en9czTYAsciW1vV-W 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:823]: t_lookupOriginalT(): canceled transaction found (0x729bff78)! 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:826]: t_lookupOriginalT(): found - lookup completed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [tm.c:1232]: ki_t_lookup_cancel_flags(): lookup_original: t_lookupOriginalT returned: 0x729bff78 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:1348]: t_newtran(): msg (0x771181ec) id=1/3670 global id=0/0 T start=0xffffffff 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:498]: t_lookup_request(): start searching: hash=10182, isACK=0 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:456]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bKPjLBcUXshEKW2s9T0en9czTYAsciW1vV-W] 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:675]: t_lookup_request(): no transaction found 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/crypto/md5utils.c:67]: MD5StringArray(): MD5 calculated: dd71ad9d7511b02a5fc83c3c70ce307f 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:727]: t_lookupOriginalT(): searching on hash entry 10182 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:432]: matching_3261(): matched skip method - s:0x2 t:0x2 m:0x2 - continue searching 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:440]: matching_3261(): RFC3261 transaction matched, tid=PjLBcUXshEKW2s9T0en9czTYAsciW1vV-W 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:823]: t_lookupOriginalT(): canceled transaction found (0x729bff78)! 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:826]: t_lookupOriginalT(): found - lookup completed 12(3670) BUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_cancel.c:318]: cancel_branch(): local_cancel buffer=(nil) != BUSY_BUFFER (trying to continue) 12(3670) ERROR: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_fwd.c:1434]: e2e_cancel(): cancel error 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_reply.c:1763]: cleanup_uac_timers(): RETR/FR timers reset 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_reply.c:638]: _reply_light(): reply sent out - buf=0x77101e68: SIP/2.0 500 cancel e... shmem=0x729c5b60: SIP/2.0 500 cancel e 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_funcs.c:120]: put_on_wait(): put T [0x729c36d8] on wait 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_reply.c:648]: _reply_light(): finished 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_funcs.c:373]: t_relay_to(): new transaction forwarded 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/receive.c:529]: receive_msg(): request-route executed in: 9868 usec 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/receive.c:628]: receive_msg(): cleaning up 34(3692) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x729c36d8 (p:0x72866768/n:0x729bff78) 34(3692) DEBUG: tm [h_table.c:132]: free_cell_helper(): freeing transaction 0x729c36d8 from timer.c:650

1 0

mk_proxy(): could not resolve hostname
by ajosebar＠gmail.com 23 May '23

23 May '23

I have Kamailio 5.6 on Debian 11. I need to use the function forward within a routing block in my configuration file: forward("udp:192.168.28.51:5060"); But when I start the kamailio service I got: CRITICAL: [core/proxy.c:264]: mk_proxy(): could not resolve hostname: "udp:192.168.28.51:5060" The same occurs when I use the dns nane : forward("udp:raspberry3.emtelco.co:5060"); Any ideas ? Regards

2 1

DNS resolution with ipops
by harneet singh 22 May '23

22 May '23

Hi Experts, I am planning to use *dns_query*() API from the ipops module, which I understand from some documentation that it internally uses *getaddrinfo*(). I wanted to check if someone can comment on the DNS Cache mechanism in this case. * Does Kamailio retain any *dns cache* while using this API, or would it be actually doing the resolution for each call. * In light of the above, does Kamailio honour the *TTL value i*n response to the DNS Query? Regards, Harneet Singh -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

2 1

MySQL duplicate entry error on location after 5.5 => 5.6 upgrade
by Benoit Panizzon 22 May '23

22 May '23

Hi list Since updating 5.5 to 5.6 i often see this message in the logs: ERROR: db_mysql [km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Duplicate entry 'uloc-645ca178-f29e-1' for key 'location.ruid_idx' (1062) ERROR: <core> [db_query.c:244]: db_do_insert_cmd(): error while submitting query ERROR: usrloc [ucontact.c:687]: db_insert_ucontact(): inserting contact in db failed ****** (uloc-645ca178-f29e-1) ERROR: usrloc [urecord.c:420]: wb_timer(): inserting contact into database failed (aor: *******) usrloc is dmq synced between two nodes. Were there some changes which could have caused this issue? 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 v5.7.0 Released - new major version is out
by Daniel-Constantin Mierla 21 May '23

21 May '23

Kamailio v5.7.0 is out – it comes with 4 new modules and a large set of improvements touching again more than 60 existing modules. You can read a bit more detailed release notes at: * https://www.kamailio.org/w/kamailio-v5-7-0-release-notes/ Many thanks to all developers and community members that made possible this release. v5.7.0 brings more flexibility and optimizations across many components, new variables and transformations, expression-based preprocessor values and conditions, alternative TLS module using WolfSSL project, improvements to STIR/SHAKEN, IMS/VoLTE, more functions exported to KEMI interface, including a new KEMI Python3 interpreter. ... just to list only a few here. Enjoy Kamailio v5.7.0! Thank you for flying Kamailio! Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

2 1

db_redis and ursloc - problem after restarting kamailio
by Koldo Aingeru 18 May '23

18 May '23

Hi, I've encountered a problem using db_redis for location, we recently migrated to redis from mysql and just found out this yesterday. We are using the usrloc module with db_mode = 2, so the location info is written to redis every 60 seconds. When restarting, Kamailio reads all the contacts and loads them into memory, but for some contacts it loads the “methods” key with an incorrect value. If in the REGISTER there are no methods kamailio saves it with methods= -1: { "jsonrpc": "2.0", "result": { "AoR": “zzzzzzz", "Contacts": [{ "Contact": { "Address": "sip:1540305477794@W.X.Y.Z:5060", "Expires": 2752, "Q": -1, "Call-ID": "7d3965a85bfd0e88-32357(a)W.X.Y.Z", "CSeq": 11, "User-Agent": “xxxxxxx", "Received": "sip:W.X.Y.Z:5060", "Path": "<sip:A.B.C.D;lr;received=sip:W.X.Y.Z:5060>", "State": "CS_SYNC", "Flags": 0, "CFlags": 64, "Socket": “udp:A.B.C.D:5060", "Methods": -1, "Ruid": "uloc-644a176b-6472-4641", "Instance": "[not set]", "Reg-Id": 0, "Server-Id": 0, "Tcpconn-Id": -1, "Keepalive": 1, "Last-Keepalive": 1684246829, "Last-Modified": 1684246829 } }] }, "id": 19286 } But when restarting kamailio, the same contacts has a methods= 0 { "jsonrpc": "2.0", "result": { "AoR": “zzzzzzz", "Contacts": [{ "Contact": { "Address": "sip:1540305477794@W.X.Y.Z:5060", "Expires": 2697, "Q": -1, "Call-ID": "7d3965a85bfd0e88-32357(a)W.X.Y.Z", "CSeq": 11, "User-Agent": “xxxxxxx", "Received": "sip:W.X.Y.Z:5060", "Path": "<sip:A.B.C.D;lr;received=sip:W.X.Y.Z:5060>", "State": "CS_SYNC", "Flags": 0, "CFlags": 64, "Socket": “udp:A.B.C.D:5060", "Methods”: 0, "Ruid": "uloc-644a176b-6472-4641", "Instance": "[not set]", "Reg-Id": 0, "Server-Id": 0, "Tcpconn-Id": -1, "Keepalive": 1, "Last-Keepalive": 1684246829, "Last-Modified": 1684246829 } }] }, "id": 19286 } In the schema file for redis the key is correctly set as int and in redis I can see it saved as -1. So when a call comes in, the lookup() function returns a -2 as it doesn’t support the INVITE method and the call fails. This is happening in kamailio 5.2.8 and kamailio 5.2.1 (old versions, I know, we are working on updating it); with mysql as a backend it works perfectly after a restart. We do have the param method_filtering=1 , changing to 0 makes it works. We seem to have this since forever and for what I can see, is not unusual as is in the default kamailio.cfg provided (even the default value for it is 0). Has anyone else encountered this? Thanks! ======================================== Koldo Aingeru Marcos Fdez. Ingeniería de Sistemas Sarenet S.A.U. 944209470 Parque Tecnológico, Edificio 103 48170 Zamudio, Bizkaia www.sarenet.es ========================================

2 2

Contact changes, caller dialog attributes and NAT traversal
by Alex Balashov 17 May '23

17 May '23

Hi, When I modify INVITEs with set_contact_alias() / add_contact_alias(), this is not preserved in dialog data, and therefore not honoured in BYEs locally generated due to dialog timeout. For example, if the initial INVITE contained: Contact: sip:line1@192.168.1.100 and, after transit, became: Contact: <sip:line1@192.168.1.100>;alias=1.1.1.1~25844~1 There is no ;alias value stored in the caller dialog data, just the original URI + parameters. A related problem: I tried to work around this by storing an alias in dialog user variables, e.g. $dlg_var(alternate_ct) = $_s($si~$sp~$prid) and in fact, I am able to recover this value later: event_route[tm:local-request] { if($dlg_var(alternate_ct) ne $null) { $ru = $ru + ";alias=" + $dlg_var(alternate_ct); handle_ruri_alias(); } } And in fact, if I print the value of $du after calling handle_ruri_alias(), I can see that it is modified. However, this seems to have no effect on where the request actually goes at the network and transport level. I assume this is because the event_route does not actually allow one to overwrite elements of the spoofed request, and that its essential attributes have been pre-populated elsewhere. Nevertheless, the effect is that these BYEs do not reach NAT'd endpoints. Any suggestions are appreciated! Thanks in advance, -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

2 4

Re: Releasing Kamailio v5.7.0
by Daniel-Constantin Mierla 17 May '23

17 May '23

The header style was wrong for ctl, fixed, thanks. Daniel On 15.05.23 18:55, Дилян Палаузов wrote: > Off-list > > Hello, > > at > https://github.com/kamailio/kamailio-wiki/blob/main/docs/features/new-in-5.… there > is a horizonal line after ctl, which shall not be there. > > Greetings > Дилян > > > На 15 май 2023 г. 7:20:55 UTC, Daniel-Constantin Mierla > <miconda(a)gmail.com> написа: > > Hello, with a few public holidays coming soon around here, I am > considering to release 5.7.0 this week on Wednesday, May 17, 2023. > Rather short notice, but there were no major bug reports that need > to be tracked. The list of new features is being built in the > wiki: - > https://github.com/kamailio/kamailio-wiki/blob/main/docs/features/new-in-5.… > The other tutorials related to this major release should be ready > by then as well. Should anyone think more time is needed, then it > can be postponed, not a problem at all. Cheers, Daniel > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 0

Releasing Kamailio v5.7.0
by Daniel-Constantin Mierla 17 May '23

17 May '23

Hello, with a few public holidays coming soon around here, I am considering to release 5.7.0 this week on Wednesday, May 17, 2023. Rather short notice, but there were no major bug reports that need to be tracked. The list of new features is being built in the wiki: - https://github.com/kamailio/kamailio-wiki/blob/main/docs/features/new-in-5.… The other tutorials related to this major release should be ready by then as well. Should anyone think more time is needed, then it can be postponed, not a problem at all. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

2 3

Diameter_authorization_rejected (FHOSS)
by Wilmes, Matthias 16 May '23

16 May '23

Hello sr-users, i use the guide for "how to integrate an IMS using Kamailio with open5gs EPC" from Supreeth Herle. When my CotsUE(ONEPLUS8) try to Register. I get an 403 Forbidden HSS Authorization Rejected (see udp-stream.txt). The output of the fhoss looks like this. de.fhg.fokus.hss.cx.CxFinalResultException: Diameter_Authorization_Rejected at de.fhg.fokus.hss.cx.op.UAR.processRequest(UAR.java:134) at de.fhg.fokus.hss.main.Task.execute(Task.java:169) at de.fhg.fokus.hss.main.Worker.run(Worker.java:66) Insufficient access rights for the mysql hss_db? The user hss@localhost and hss@% have grant access. Maybe someone has had the error and has a hint and can help. Can't find the error. Many thanks in advance for an answer. -M.Wilmes

3 2

How to prevent run-away dialogues?
by Benoît Panizzon 15 May '23

15 May '23

Hi team Is there any way to get correct CDRS when using the dialog module and restarting kamailio? I have configured the dialog timeout to be 12 hours. But today while doing IC billing, we stumbled over a call that lasted for a week. Probably due to a stale entry in the database dialogue tables left over after a kamailio restart. Looking at the logs there definitely was something wrong: dialog [dlg_req_within.c:211]: bye_reply_cb(): inconsistent dlg timer data on dlg 0x7f153f503778 [956:2612] with clid '35BEFD13@7f33ff47' and tags '7f33ff47+1+75300082+dde85140' '3891401256-2097511021' acc [acc_cdr.c:229]: db_write_cdr(): fallback to dlg_only search because of message doesn't exist. -- 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 ______________________________________________________

2 1

[auth_radius.c:123]: mod_init(): failed to open configuration file
by Denys Pozniak 12 May '23

12 May '23

Hello! After a major upgrade of Kamailio (5.1 -> 5.6), an error appears that it is not possible to open configuration file (I think this is about /etc/radiusclient/radiusclient.conf), although it exists with the necessary access rights: *0(27075) DEBUG: <core> [core/sr_module.c:969]: init_mod(): auth_radius0(27075) ERROR: auth_radius [auth_radius.c:123]: mod_init(): failed to open configuration file0(27075) ERROR: <core> [core/sr_module.c:975]: init_mod(): Error while initializing module auth_radius (/usr/lib64/kamailio/modules/auth_radius.so)ERROR: error while initializing modules* For the test, I made Kamailio downgrade back to 5.1 and the problem went away. Shortened the Kamailio config to the minimum for reproducing the problem: *#!KAMAILIOmemdbg=5memlog=5children=1log_stderror=nolisten=udp:127.0.0.1:5060 <http://127.0.0.1:5060>loadmodule "kex.so"loadmodule "corex.so"loadmodule "tm.so"loadmodule "sl.so"loadmodule "rr.so"loadmodule "pv.so"loadmodule "maxfwd.so"loadmodule "auth.so"loadmodule "auth_radius.so"modparam("auth_radius", "radius_config", "/etc/radiusclient/radiusclient.conf")request_route { return;}* Could the commit below somehow affect the acceptance of the radius_config module parameter? https://github.com/kamailio/kamailio/commit/f33ba318b20cbd2b34d278a7e2c4e64… -- BR, Denys Pozniak

4 7

kamcmd ul.db_contacts how to specify table name?
by Benoît Panizzon 12 May '23

12 May '23

Good morning. I'm trying to get the number of registered contacts with kamcmd ul.db_contacts. The table has the default name 'location'. But no matter what I try: kamcmd ul.db_contacts location kamcmd ul.db_contacts s:location kamcmd ul.db_contacts database.location kamcmd ul.db_contacts s:database.location Kamcmd complains the table is not found. What would be the correct syntax to provide the table name? Attempted with Kamailio 5.5 and 5.6 -- 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 ______________________________________________________

1 1

ICMP Port Unreachable using loopback interface with ethernet IP
by Calvin E. 11 May '23

11 May '23

The scenario is Kamailio on Debian 11 talking to an external application server that returns a 302 with a Contact that contains Kamailio's own IP and a different port. Kamailio is listening on the correct port via at the given IP address. However, when Kamailio creates the packet to talk to itself, it it send over the loopback adapter "lo" and gets an ICMP port reply: listen=udp:KAMAILIO_INTERNAL_FLOATING_IP:8888 10.z.a.b.5000 > 10.z.x.y.5060: SIP, length: 849 SIP/2.0 302 Moved Temporarily Contact: <sip:44123456...@10.z.x.y:8888> 15:39:00.548722 lo In IP (tos 0x10, ttl 64, id 5431, offset 0, flags [none], proto UDP (17), length 949) 10.z.x.y.5060 > 10.z.x.y.8888: SIP, length: 921 15:39:00.548732 lo In IP (tos 0xd0, ttl 64, id 19038, offset 0, flags [none], proto ICMP (1), length 576) 10.z.x.y > 10.z.x.y: ICMP 10.44.7.136 udp port 8888 unreachable, length 556 Do I need to configure something in the OS or Kamailio to allow the ethernet IP to work via the loopback adapter? I haven't set up any special networking to cause this, it appears to be a Linux kernel behavior.

3 3

where add contact header to ack for fail messages
by mohsen khashei 11 May '23

11 May '23

Hi I want to know where kamailio sends ack messages to faiurel messages (status >=400) so that I I add Contact header to the ack. I tried WITHINDLG with no luck. thanks

5 6

GeoIP2 and KEMI
by Michal Hajek 11 May '23

11 May '23

Hello, why this commit is not in branch 5.6? https://github.com/kamailio/kamailio/commit/21817906853140322c701f8cbb82010… Without this, is KEMI and GeoIP2 incompatible. Thanks Michal

2 1

kamailio/kamailio-ci docker image
by Sergey Safarov 11 May '23

11 May '23

Hi Now "kamailio/kamailio-ci" docker image is pushed to GitHub packages <https://github.com/kamailio/kamailio-ci/pkgs/container/kamailio-ci> only. I have a question should we completely switch to using the GitHub docker repo and remove the "kamailio/kamailio-ci" docker image from Docker Hub <https://hub.docker.com/repository/docker/kamailio/kamailio-ci>? Or required to push the "kamailio/kamailio-ci" docker image to GitHub packages and Docker Hub repos? Sergey

2 1

Re: where add contact header to ack for fail messages
by Henning Westerholt 11 May '23

11 May '23

Understood. Thanks for sharing your final solution, added the list as well that others can benefit from it. Cheers, Henning From: mohsen khashei <mkhashei(a)gmail.com> Sent: Donnerstag, 11. Mai 2023 12:37 To: Henning Westerholt <hw(a)gilawa.com> Subject: Re: [SR-Users] Re: where add contact header to ack for fail messages I need it for an application server after kamailio. Finally I add contact to the message by ac_extra_hdrs of tm module with a p header. On Thu, May 11, 2023, 15:01 Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> wrote: Hello, why you actually need to add the Contact header to the ACK? According to the RFC 3261 is should be an optional header to that message. Cheers, Henning -----Original Message----- From: James Browne <james(a)frideo.com<mailto:james@frideo.com>> Sent: Mittwoch, 10. Mai 2023 14:08 To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Subject: [SR-Users] Re: where add contact header to ack for fail messages I made simple tests and it seems that this is a kamailio-TM-internal message being sent, not being processed by the cfg file. If this is simple enough and deterministic, you may consider using the corex module to edit the message as it's being sent "on the wire". I can't think of any other solution. https://kamailio.org/docs/modules/5.6.x/modules/corex.html#corex.evr.networ… You may be able to write some code that manipulates the message to manually add the Contact header. Maybe even the append_hf function may work here, but it seems unlikely. James On Mon, 8 May 2023 at 12:28, mohsen khashei <mkhashei(a)gmail.com<mailto:mkhashei@gmail.com>> wrote: > > thanks for the reply I tried it and it didn't work. also I tried onsend_route with no luck. > > On Sun, May 7, 2023 at 7:00 PM Yuriy G <ovoshlook(a)gmail.com<mailto:ovoshlook@gmail.com>> wrote: >> >> Try here >> https://www.kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.e.loca >> l-request >> >> However I would doubt first do I do something right by adding contact to ACK message wichbasicaly confirmation of the final transaction and contact here is meaningless. >> >> On Sun, 7 May 2023, 16:48 mohsen khashei, <mkhashei(a)gmail.com<mailto:mkhashei@gmail.com>> wrote: >>> >>> Hi I want to know where kamailio sends ack messages to faiurel messages (status >=400) so that I I add Contact header to the ack. >>> I tried WITHINDLG with no luck. >>> thanks >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions 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! >>> Edit mailing list options or unsubscribe: >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions 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! >> Edit mailing list options or unsubscribe: > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions 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! > Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:

1 0

using kamailio to send invite to webrtc clients (with freeswitch)
by shwetank singh 09 May '23

09 May '23

Hello experts I have a setup where webrtc client registrations (from behind a NAT / VPN) are on kamailio and the INVITE to begin a call is sent by freeswitch to kamailio which is then expected to relay it to the subscribed webrtc client. i understand, from documentation and general thinking, that kamailio cannot open a new connection to such a client and should reuse an open connection (a websocket in my case). i have setup kamailio as generic as it may sound and expect t_relay() to do the magic of forwarding the invite, however, from logs i don't see anything indicating kamailio is using any existing connection and hence my outgoing invite requests are stuck showing pointed towards a vpn gateway which was the registered "location" of client (which is the public ip of VPN gateway) please advise what relevant information can i produce here to make the query more readable and clear. headed here after trying just about all the resources available on the topic. e.g. if my location record looks like AoR: 1004(a)mydomain.com Contacts: - Contact: Address: sip:1004@11.22.33.44:49179 CFlags: 64 CSeq: 3087 Call-ID: 189jss21e24ntve1ggsuli Expires: 593 Flags: 0 Instance: <urn:uuid:8a936bbc-514f-4755-bed0-edc644dd4453> KA-Roundtrip: 0 Keepalive: 1 Last-Keepalive: 1683652755 Last-Modified: 1683652755 Methods: 7071 Path: <sip:10.10.6.196:3040;received=sip:mydomain.com ;lr;nat=yes> Q: -1 Received: sip:11.22.33.44:49179;transport=ws Reg-Id: 1 Ruid: uloc-645601c4-131220-3764 Server-Id: 0 Socket: tls:1.2.3.4:4443 State: CS_SYNC Tcpconn-Id: 3916 User-Agent: JsSIP 3.9.0 i try to lookup the location and find the address, and then route to that address by setting $ru in sngrep it does show that kamailio is trying to send INVITE to 11.22.33.44:port (which is the VPN gateway) but it isn't exactly clear from logs if this is being done over an existing connection. how does kamailio identify if a connection exists for a user (for each contact in AOR, if multiple contacts exist for a user -- i.e. different browser sessions?) if(reg_fetch_contacts("location", "$ru", "caller")) { $var(i) = 0; while($var(i) < $(ulc(caller=>count))) { $ru = $(ulc(caller=>addr)[$var(i)]); $var(i) = $var(i) + 1; setflag(FLT_DLGINFO); dlg_manage(); t_relay(); } } -- Shwetank

3 2

Performing async_http calls on stateless Loadbalancers
by Julius Flohr 09 May '23

09 May '23

Hi List, we are running several stateless SIP Loadbalancers using Kamaillio 5.1 and 5.6. Now we would like to perform an async_http request if an INVITE matches certain criteria. The request itself is performed very similar to how it's described here [1] This uses the transaction module in order to assure that the response can be mapped to the original request. However, this also means that the processing of the entire request becomes stateful which we would like to avoid. We tried to use t_release() in the callback route (in [1] this route is called "RELAY_API_RESPONSE"). However, documentation says that this is only allowed in the REQUEST_ROUTE. Is there an easy way to circumnavigate this issue? Cheers [1]: https://wazo-platform.org/blog/kamailio-routing-with-rtjson-and-http-async-… -- Julius Flohr - Voice Engineer - flohr(a)sipgate.de Telefon: +49 (0)211-63 55 55-0 Mobil: +49 (0)1579-000-0205 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.co.uk

3 3

Upgrade to 5.6.4 => [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer
by Benoît Panizzon 08 May '23

08 May '23

Hi team I upgraded our lab to 5.6.4 from the official repository for ubuntu Jammy. Now I get crashes related to TLS: May 5 14:58:40 dev-cpereg01 kamailio[36147]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f4fedbed4e8), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_f ree(323) - ignoring May 5 14:58:40 dev-cpereg01 kamailio[36147]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f4fedd72b88), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_f ree(323) - ignoring May 5 14:58:40 dev-cpereg01 kamailio[36177]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f4fedd9e4a0), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_f ree(323) - ignoring May 5 14:58:40 dev-cpereg01 kamailio[36157]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f4fedd9e428), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_f ree(323) - ignoring And a bit later on: May 5 14:58:46 dev-cpereg01 kamailio[36179]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 34 May 5 14:58:46 dev-cpereg01 kamailio[36143]: ALERT: <core> [main.c:774]: handle_sigs(): child process 36161 exited by a signal 11 May 5 14:58:46 dev-cpereg01 kamailio[36143]: ALERT: <core> [main.c:777]: handle_sigs(): core was generated May 5 14:58:46 dev-cpereg01 kamailio[36143]: INFO: <core> [main.c:799]: handle_sigs(): terminating due to SIGCHLD Has there been a fundamental change in TLS? Or did I miss something important to do on a 5.5 => 5.6 upgrade? -- 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 ______________________________________________________

4 5

TLS1.2 ciphers
by Sergiu Pojoga 05 May '23

05 May '23

Hi gang, Trying to figure out why Kamailio won't negotiate specific TLS1.2 ciphers, such as for example TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 i.e. *ECDHE-RSA-AES256-GCM-SHA384* OpenSSL lists the cipher as supported, however Kamailio won't negotiate it: # nmap --script ssl-enum-ciphers -p 5061 mysbc.domain.com PORT STATE SERVICE 5061/tcp open sip-tls | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | compressors: | NULL | cipher preference: server | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity |_ least strength: C OS: - outdated Debian 8 Jessie - OpenSSL 1.0.1t 3 May 2016 - openssl ciphers -v | grep '*ECDHE-RSA-AES256-GCM-SHA384*' - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD # kamailio -V version: kamailio 5.5.6 (x86_64/linux) ad1244 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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 ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_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. compiled on 21:08:20 Apr 13 2023 with gcc 4.9.2 modparam("tls", "cipher_list", "ALL") method = TLSv1.2+ Elliptic Curve Diffie-Hellman (EDCH) <https://kamailio.org/docs/modules/devel/modules/tls.html#tls.compile>-Ciphers are only supported in OpenSSL 1.0.0e and later. Any suggestions? Thanks.

5 5

Using a second Perl library
by David Cunningham 04 May '23

04 May '23

Hello, We are using a product which already uses the "app_perl" module and sets the "filename" parameter to its own Perl library. However, we want to add more Perl code without having to modify that product's library. Does anyone know of a way to do this? To have Kamailio use Perl code from two different places? I guess in the worst case scenario we could use "app_python3", and have some Python code call subprocess.run() on the Perl code. Thanks very much, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

1 0

Development is open for future release of v5.8.x series
by Daniel-Constantin Mierla 04 May '23

04 May '23

Hello, the branch 5.7 was created, therefore the master branch is open for adding new features, to be part of future release series v5.8.x (or whatever version is decided for next series). Any bug fix committed to master that applies to 5.7.x or older stable branches should be backported as usual with "git cherry-pick -x ..." to appropriate branches like 5.7 or 5.6. Expect that v5.7.0 will be released in a few weeks from now. Based on the workflow used during the past years, the next future release v5.8.0 should be out after another 8-10 months of development, plus 1-2 months of testing, so sometime during the first part of 2024. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 0

Branch 5.7 has been created
by Daniel-Constantin Mierla 04 May '23

04 May '23

Hello, the branch 5.7 has been created, to be used for releasing v5.7.x series. To check out this branch, the following commands can be used: git clone https://github.com/kamailio/kamailio kamailio-5.7 cd kamailio-5.7 git checkout -b 5.7 origin/5.7 Pushing commits in this branch: git push origin 5.7:5.7 Note that 5.7 is an official stable branch, so only bug fixes, missing kemi exports (discuss on sr-dev if not sure) or improvements to documentation or helper tools can be pushed to this branch. As usual, if there is a bug fixed, commit and push first to master branch and then cherry pick to 5.7 branch: git cherry-pick -x COMMITID In few weeks, the first release from branch 5.7 will be out, respectively Kamailio v5.7.0. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 0

send reply from branch route?
by Benoit Panizzon 04 May '23

04 May '23

Hello Is there a possibility to send a reply from within a branch route? Experimental case (yes, I know it's a non working set-up, but I just wonder if that would be possible). Two registrar nodes, location information shared between the two. CPE registers via TLS, therefore the existing connection shall be used towards the CPE and that only exists on one of the registrars. So in the Branch Route I would like to do something like: $var(socket) = $(ulc(aor=>socket)[$T_branch_idx]); if ($var(socket) == 0) { send_reply("503","no local socket"); } This would cause the core routing instance to select the next registrar from the dispatcher list which hopefully holds the active socket. But none of the 'send_reply' variants seem to be allowed within a branch route. Or is there a better solution? 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 ______________________________________________________

3 6

Branching 5.7 on git repo for 5.7.x releases
by Daniel-Constantin Mierla 04 May '23

04 May '23

Hello, I am planning to split 5.7.x series on its own git branch 5.7 on Thursday, May 4, 2023. After that, master branch will be open for new features (to become part of 5.8 or what ever version will be decided to be next). Usually testing should continue for branch 5.7 for another 1-2 weeks, then, if no relevant road blockers pop up, we should release 5.7.0 as first stable version in the 5.7.x series. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 1

uac.reg_add to database
by Jon Bonilla (Manwe) 04 May '23

04 May '23

Hi 5.6.4 I'm trying to add uacreg logic to my setup. When I add a new entry via rpc I see that the reg is stored in mem but not inserted in the database for persistency. My uac params are like this: modparam("uac", "reg_db_url",DBURL) modparam("uac", "reg_timer_interval", 900) modparam("uac", "reg_retry_interval", 10) modparam("uac", "reg_random_delay", 0) modparam("uac", "reg_hash_size", 12) ## 5.6 modparam("uac", "reg_db_table", "kam_uacreg") modparam("uac", "reg_contact_addr", "192.168.255.254:5060") #Won't be used #modparam("uac", "default_socket", "udp:192.168.0.125:5060") #Won't be used modparam("uac", "reg_keep_callid", 1) modparam("uac", "reg_active", 1) modparam("uac", "reg_gc_interval", 30) modparam("uac", "reg_use_domain", 0) I'm used to add via rpc and have db persistency. Like for exmaple using the domain module. Is this a bug in my config or does this module behave different? Should I insert in the db and call to enable via RPC? If so, what would be the best way to enable only the new inserted register instead of reloading all the regs? It's expected to have many changes and do not want to have full reloads all the time. cheers, Jon -- PekePBX, the multitenant PBX solution https://pekepbx.com

1 0

Kamailio - asterisk - ACK
by Péter Dr. Barabás 03 May '23

03 May '23

Hi all, we are developing a softphone mobile application which registers to asterisk through kamailio. Kamailo proxies the request to asterisk and replies from asterisk to the clients. Registration works fine with asterisk authentication. The problem appears in the following flow: 1. Mobile client A calls client B. 2. Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with credentials. 3. Asterisk sends invite to client B towards kamailio. 4. Kamailio forwards INVITE if client is registered or sends a push notification to client B. When client B registers, kamailio continue the suspended transaction and forwards INVITE. 5. Client B gets INVITE, sends a SIP OK. 6. Asterisk gets SIP OK through kamailio and sends an ACK to client B, which is OK. 7. Asterisk sends the SIP OK to client A through kamailio. 8. Kamailio forwards SIP OK to client A but the contact address contains the asterisk IP instead kamailio. 9. Clilent A try to send ACK but it does not arrive to asterisk, and the call will be hungup after 30 secs. So the question is what is missing, what is the correct solution? I try to use the provided configuration given in following link: https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb The difference is that kamailio has no access to asterisk database. Thanks for your help. With kind regards, Peter

3 3

RFC: selective backports to latest stable as a dedicated git branch
by Daniel-Constantin Mierla 03 May '23

03 May '23

Hello, during past on-site/online devel meetings as well as on mailing lists or tracker, there were various discussions around the idea or requests to make new features available quicker to stable branches. Of course, one can do local git cherry-picking, but I thought to bring this in discussion and see if makes sense to get something more coordinated between developers and community. Therefore I am cross-posting to sr-dev and sr-users to see if there is interest for it from both communities. Somehow inspired from Debian, my first idea would be to create a "x.y-backports" branch, where "x.y" is the branch for the stable release series. For example, with 5.6 release series built from branch "5.6", there could be "5.6-backports" branch which is kept in sync in "5.6" but also can get "selected" new features from devel (master branch) backported. The "selected" new features should be mostly a matter of the people willing to put effort in backporting, but I would consider a list recommendations not to end up with devel and backports branches being more or less the same. For example, in the "no-backporting" list: - no backporting of completely new modules - no backporting of significant changes to the config file language and native scripting interpreter In the "ok-to-backport": - updates to enable use with newer versions of external libraries - changes to make some functions/modules to cope better with the core infrastructure or end points Commits to the backports branch can be proposed via pull requests. The backports branch should be done only for latest stable version, picking from the development version. Right now it would be 5.6, but we can wait till 5.7 is released and then have it for it. No packaging and no official releases should be made from backports branch, only a git branch to be maintained as a community effort. Of course, if someone wants to put more resources into it, we can discuss about. Anyhow, the first questions would be if such branch sounds good to have and if there are people that think they can also contribute to maintain it. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

3 2

Clarification of 'return false' behaviour
by Patrick Wakano 03 May '23

03 May '23

Hi list, Hope you are all well! I'm using Kamailio version 5.6.4 (installed from the repo rpm.kamailio.org/centos/7) and noticed that every route that uses "return false" is exiting the script, instead of returning.... This was not the case on version 5.4.6 as the same script is running fine..... From this page https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-r…, I would think that when a route returns false, it would return -1 and not stop execution, since negative is equal to false, but it is actually stopping (same as return 0)... So, as an example, this test code doesn't work as expected. In case the source is a public IP, the script doesn't print the "SRC public" it just exits and then of course every other logic meant to be done is not executed.... route[is_src_private] { if (is_ip_rfc1918("$si")) { return true; } return false; #return is_ip_rfc1918("$si"); *# this doesn't work too in case the $si is a public IP* } request_route { ... if (route(is_src_private)) { xlog("L_NOTICE", "SRC private\n"); } else { xlog("L_NOTICE", "SRC public\n"); } ... } If is_src_private is changed to return -1 instead of false, then it all works fine. Also, I noticed that the following code will print "TEST: 0" in case the $si is public and then stop execution. So looks like false is really being converted to 0, but I guess that's unexpected... anyway apologies if I'm missing something obvious.... route[is_src_private] { $var(t) = false; if (is_ip_rfc1918("$si")) { $var(t) = true; } xlog("L_ERR", "TEST: $var(t)\n"); return $var(t); } I could not find a recent ticket or email related to this situation and I've already spent hours trying to understand what is the logic/problem here, so would anyone have been across a similar case that could provide some insight and clarify what is the expected behaviour of the *false* usage (and boolean in general if possible)? Thank you, Kind regards, Patrick Wakano

3 6

rtpengine module: sdp offer in message reply, ip protocol version not passed to rtpengine?
by Benoit Panizzon 02 May '23

02 May '23

Hi Team I think, I might have found something that was overseen in the rtpengine module. A (ipv6) <=> rtpengine <=> B (ipv4) Invite+SDP from B to A It looks like this works as expected. A SDP c= line is created containing an ipv6 address. Invite, no SDP from A to B Reply with SDP offer from B to A The information about A being reachable via ipv6 and therefore an ipv6 c= line being required, could be taken from the via header of the reply. But am I right to fear, that the rtpengine module does not do this at the moment? 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

Number if typical database connections
by Steve Wilkins 02 May '23

02 May '23

Hello, I moved the Kamailio database to RDS from a local instance and noticed that there were a large number of connections from the Kamailio user. What is the normal number of connection that can be expected? Thank you,

2 1

Rebooting kamailio.org server
by Daniel-Constantin Mierla 02 May '23

02 May '23

Hello, in about 1 hour the kamailio.org server will be rebooted for some system upgrades, it should be quickly back running, but if anyone accesses the web/wiki or mailing lists archives exactly during that time, they might not respond -- just wait for a minute and try again. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 0

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK
by Daniel Tryba 02 May '23

02 May '23

On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote: > Sure. Attached. Problem appears to be that the topos query can't find > callid-totag (from the response). > > I'll try the same scenario with the mysql backend to see if it behaves > different. Config works fine with mysql as topos backend. So the bug is restricted to topos-redis.

5 19

Loading the LCR Module Tables at startup/reload
by harneet singh 30 Apr '23

30 Apr '23

Hi All, Can someone point to a sample as to how we can *load the LCR Module tables* namely the following at startup from a csv file or any other mechanism. * lcr_gw_table * lcr_rule_table * lcr_rule_target_table The idea is to not need to manually feed in the entries into the table but instead add these in the beginning through either a *wrapper script *OR *through the kamailio cfg file* if possible. Any pointers are much appreciated. Thanks & Regards, Harneet Singh -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

2 3

Route Header based routing for initial INVITE
by harneet singh 28 Apr '23

28 Apr '23

Hi Experts, I believe the loose_route() in kamailio can be used for initial Out of the dialog INVITE processing as well. Is that the correct understanding? If so, the request will be forwarded ahead to the destination corresponding to the Route Header remaining (if any) after Kamailio has stripped off it's own Address(es) from the Route Header(s). Is that correct? Regards, Harneet Singh -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

3 3

Strange RTCP issue
by Kiss Zoltán 27 Apr '23

27 Apr '23

Hello, We have a transparent proxy in front of Asterisk boxes. The media is handled by rtpengine, and the "manage" work is done by Kamailio in the route[NATMANAGE] section like this: if(nat_uac_test("8")) { # Packet from backend server if(ds_is_from_list()){ if (rtpengine_manage("replace-origin replace-session-connection direction=internal direction=pub")) { xdbg("NATMANAGE --- Success rtpengine_manage() RTP from INTERNAL to EXTERNAL $ru"); } } else { if (rtpengine_manage("replace-origin replace-session-connection direction=pub direction=internal")) { xdbg("NATMANAGE --- Success rtpengine_manage() RTP from EXTERNAL to INTERNAL $ru"); } } } else { # Packet from backend server if(ds_is_from_list()){ if (rtpengine_manage("replace-origin replace-session-connection trust-address direction=internal direction=pub")) { xdbg("NATMANAGE --- Success rtpengine_manage() RTP from INTERNAL to EXTERNAL $ru"); } } else { if (rtpengine_manage("replace-origin replace-session-connection trust-address direction=pub direction=internal")) { xdbg("NATMANAGE --- Success rtpengine_manage() RTP from EXTERNAL to INTERNAL $ru"); } } } Everything is working fine, but with some clients (like Grandstream phone) the RTCP session wants to go tot he private address of the phone. Here is the log of one of these strange calls: Apr 27 16:54:38 rtp1 rtpengine[2273]: INFO: [312ed76c31f21b71452e91e5184ad25b@172.16.2.210:5060]: [core] --------- Port 178.238.213.14:11088 <> 81.183.216.3:5068 , SSRC 77c19488, 625 p, 107500 b, 0 e, 29 ts Apr 27 16:54:38 rtp1 rtpengine[2273]: INFO: [312ed76c31f21b71452e91e5184ad25b@172.16.2.210:5060]: [core] --------- Port 178.238.213.14:11089 <> 10.0.5.192:5069 (RTCP), SSRC 0, 0 p, 0 b, 0 e, 43 ts As you can see the RTP itself is okay, but the RTCP will somehow go to the private address. If we tracing the sdp messages in sngrep, then we can see that Kamailio transforming IP addresses for the backend servers to the public (and the private address of the rtpengine) addresses. We are missing something? Thank you! With kind regards, Zoltan

2 1

Sensible values for pike mudule?
by Benoit Panizzon 27 Apr '23

27 Apr '23

Hi Before I go too deep into try and error, I guess others have been there too. What are sensible value you use for the pike module to detect / mitigate abusive behavior, especially dictionary attacks? Are there better solutions that the pike module? 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

Fwd: Sensible values for pike mudule?
by Stefan 27 Apr '23

27 Apr '23

Hi Benoît We use pike in combination with fail2ban. Log a message -> create a fail2ban rule to block the ip for xxx time. example: if ($ua =~ "(friendly-scanner|sipvicious)") { sl_send_reply("488", "Go away."); xlog("L_INFO","$ci Blocking traffic from $si\n"); exit; } Cool thing is, you can write a log entry from every part in your kamailio-config, and then fail2ban does the rest. Regards Stefan Am 27.04.23 um 16:07 schrieb Benoit Panizzon: > Hi > > Before I go too deep into try and error, I guess others have been there > too. > > What are sensible value you use for the pike module to detect / > mitigate abusive behavior, especially dictionary attacks? > > Are there better solutions that the pike module? > > Mit freundlichen Grüssen > > -Benoît Panizzon-

1 0

hooking mechanism for routing blocks
by Valentin Christoph 27 Apr '23

27 Apr '23

Dear all, I am looking for some hooking mechanism for user defined routing blocks. Is something like this already available? 1) a common part of the routing configuration shall not (or only slightly) be changed, after some hooks have been implemented Something like a function "engage_hooks()" of some "hook_module"? : Routing config that should not be changed by application developers engage_hooks(HOOK_TYPE); Routing config that should not be changed by application developers : 2) one application developer may "hook" new parts of the routing configuration into this, by modparam("hook_module", "hook", "name=MY_RB;type=HOOK_TYPE;prio=50); : : Route [MY_RB] { Do something at hook HOOK_TYPE; } : : 3) another application developer might want to "hook" into the same HOOK_TYPE with a higher priority modparam("hook_module", "hook", "name=ANOTHER_RB;type=HOOK_TYPE;prio=20); : : Route [ANOTHER_RB] { Do another thing with higher priority at hook HOOK_TYPE } : : Kr, Christoph

2 2

Kamailio use case
by jdprsaga＠gmail.com 26 Apr '23

26 Apr '23

Hello All, new subscriber here. I've been reading kamailio documentation to check if kamailio has a use case on the architecture for the solution for my company's software, here an small architecture diagram of our solution. sipclient <----> [ Middleware ] <-----> SBC Our middle ware is both a sip proxy and media proxy. we have a large number of sip clients but a small calling number, our current bottleneck is that the middleware can't handle a high number of registration, i would like to deploy Kamailio as a load balancer for registrations, making sure it is statefull so registrations and calls are hashed into the same middleware server. sipclients < ----> [ kamailio ] <------> [ middleware1, middleware2,...,middleware N] <-----> SBC Any thoughts or pointers?

4 3

rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
by Benoît Panizzon 26 Apr '23

26 Apr '23

Hi all I wonder, if there is a documentation on what action is performed by rtpengine_manage() on which kind reply. Am I right, that rtpengine_manage(), on any 4XX reply causes a delete? So if there is a re-invite (for example to switch to T.38) and the other party replies with 488 which in turn is passed through rtpengine_manage() the existing RTP stream is deleted from rtpengine instead of being left running with the previously agreed codec? Has anyone already figured out a list of what reply codes should be exempt from calling rtpengine_manage()? -- 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 ______________________________________________________

8 12

Configuring dynamic Destination identification for Kamailio Routing
by harneet singh 25 Apr '23

25 Apr '23

Hi Experts, We have been using Kamailio as a sip proxy for a fair bit of time now(version 5.3.2 though) and do understand the native routing mechanism that can be instrumented through the kamailio cfg scripts. We initially had only two sides, where the traffic could come from into Kamailio and it just passed through to the other side(ie Traffic from A was routed to B and that from B was routed to A). Off late, a few more sip elements have been introduced in the deployment and now there is a need for a more formal/robust mechanism to select the intended destination to forward an initial SIP INVITE to. I believe that we could still keep all the logic in the native kamailio script and do the routing(for example, an incoming call where the *From URI* contains *sip.elementA.com <http://sip.elementA.com>* should be routed to destination *sip.elementB.com <http://sip.elementB.com>*, where as if the* To URI *contains *sip.elementC.com <http://sip.elementC.com>*, the request should be routed to *sip.elementC.com <http://sip.elementC.com>)**. *Since we have many sip elements like A,B.C,D,E etc where the requests might have to be routed to, based on certain different criteria, this logic would become cumbersome. *What would be the best way to accommodate this?* *Would it be possible to rewire this routing logic at runtime(*like in some csv file that can be reloaded*) without a Kamailio restart? * Regards, Harneet Singh -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

3 5

sips to sip with TLS proxy
by Kiss Zoltán 25 Apr '23

25 Apr '23

Hi all, We have a working Kamailio setup, lets call it a transparent proxy for Asterisk boxes. Its based on domain and dispatcher modules and everything is working as expected with the test clients (more or less microsip, softphone for ios, etc). We are tried to register with a Grandstream deskphone today, and we see that the phone sending sips:xxx in the Reg Contact field for example. Because the sips schema, the register is working, but we cannot initiate calls from this phone. If we are turning SIP scheme to sip from sips in the phone, then everything is working as expected. I think we can transform those requests from sips to sip with Kamailio, but currently we dont know where can we start. Has anybody a suggestion about this issue? I know that we can transform ruri, contact, etc with textops, nathelper and a lot of other modules, but what is the best for this sips->sip translation? Thanks for your help. With kind regards, Zoltan

4 10

TCP/TLS connection (id: 0) for WebSocket could not be found
by Joey Golan 22 Apr '23

22 Apr '23

Hello, I have 2 clients. 1 using websocket and 1 mobile using TLS. Both can call each other perfectly. After 24-48 hours calls from mobile to websocket failed with an error message: TCP/TLS connection (id: 0) for WebSocket could not be found. At the same time I can make calls from the websocket client to the mobile. I know that the search of the connection is done by target address so I printed the addresses + ports and they are matched to the ones that appear on the ul.dump and ws.dump. *kamcmd ul.dump output:* Info: { AoR: usrmt63ly_1040 HashID: 1830036546 Contacts: { Contact: { Address: sip:usrmt63ly_1040@example.com;transport=ws Expires: 283 Q: -1 Call-ID: tvne1pskgkm2a01pnqm677 CSeq: 1060 User-Agent: JsSIP 3.9.0 Received: sip:*10.218.51.86:24061 <http://10.218.51.86:24061>*;transport=ws Path: <sip:10.218.154.228:50443;transport=ws;received=sip:*10.218.51.86:24061 <http://10.218.51.86:24061>*;transport=ws;lr> State: CS_NEW Flags: 0 CFlags: 64 Socket: tls:10.218.154.228:50443 Methods: 7071 Ruid: uloc-61ebba84-64242101-89ba-1 Instance: <urn:uuid:7573726d-7436-116c-915f-313034304077> Reg-Id: 1 Server-Id: 1642838660 Tcpconn-Id: 100420 Keepalive: 1 Last-Keepalive: 1680417282 KA-Roundtrip: 0 Last-Modified: 1680417282 } } } *kamcmd ws.dump* { connections: { 100420: wss:*10.218.51.86:24061 <http://10.218.51.86:24061>* -> wss: 10.218.154.228:50443 (state: OPEN, last used 14s ago, sub-protocol: sip) } info: { wscounter: 1 truncated: no } } *Call from mobile (TLS) to websocket: Failed with error message: TCP/TLS connection (id: 0) for WebSocket could not be found* 30(35263) INFO: {1 2563 INVITE 4248c155-cd92-49b8-b68a-eef5f2cb3e88} <script>: request_route: method [INVITE] from [ sip:usrrcv4o4_1040@example.com] socket [sip:10.218.51.86:50909;transport=tls] to [sip:usrmt63ly_1040@example.com] 30(35263) INFO: {1 2563 INVITE 4248c155-cd92-49b8-b68a-eef5f2cb3e88} <script>: [RELAY]: method [INVITE] from [sip:usrrcv4o4_1040@example.com] socket [sip:10.218.51.86:50909;transport=tls] to [ sip:usrmt63ly_1040@example.com] socket [sip:*10.218.51.86:24061 <http://10.218.51.86:24061>*;transport=ws] 30(35263) WARNING: {1 2563 INVITE 4248c155-cd92-49b8-b68a-eef5f2cb3e88} <core> [core/msg_translator.c:2863]: *via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found* 30(35263) ERROR: {1 2563 INVITE 4248c155-cd92-49b8-b68a-eef5f2cb3e88} <core> [core/msg_translator.c:2040]: build_req_buf_from_sip_req(): could not create Via header 30(35263) ERROR: {1 2563 INVITE 4248c155-cd92-49b8-b68a-eef5f2cb3e88} tm [t_fwd.c:479]: prepare_new_uac(): could not build request 30(35263) ERROR: {1 2563 INVITE 4248c155-cd92-49b8-b68a-eef5f2cb3e88} tm [t_fwd.c:1759]: t_forward_nonack(): failure to add branches 30(35263) ERROR: {1 2563 INVITE 4248c155-cd92-49b8-b68a-eef5f2cb3e88} sl [sl_funcs.c:418]: sl_reply_error(): stateless error reply used: No error (2/SL) 30(35263) NOTICE: {1 2563 INVITE 4248c155-cd92-49b8-b68a-eef5f2cb3e88} acc [acc.c:287]: acc_log_request(): ACC: call missed: timestamp=1680417920;method=INVITE;from_tag=e168ffa6-e577-48ec-b9c9-a73f5be318e8;to_tag=0c3e625e9f223a7ee2b093e8e31b2526-b7165bcb;call_id=4248c155-cd92-49b8-b68a-eef5f2cb3e88;code=500;reason=Server Internal Error;src_user=usrrcv4o4_1040;src_domain=example.com ;src_ip=10.218.51.86;dst_ouser=usrmt63ly_1040;dst_user=usrmt63ly_1040;dst_domain= example.com *Call from websocket to mobile (TLS):* 38(35271) INFO: {1 7488 INVITE urcnete8r71dpkhmngd8} <script>: request_route: method [INVITE] from [sip:usrmt63ly_1040@example.com] socket [sip:*10.218.51.86:24061 <http://10.218.51.86:24061>*;transport=ws] to [ sip:usrrcv4o4_1040@example.com] 38(35271) INFO: {1 7488 INVITE urcnete8r71dpkhmngd8} <script>: [RELAY]: method [INVITE] from [sip:usrmt63ly_1040@example.com] socket [sip:*10.218.51.86:24061 <http://10.218.51.86:24061>*;transport=ws] to [ sip:usrrcv4o4_1040@example.com] socket [sip:10.218.51.86:20674 ;transport=tls] 39(35272) INFO: {2 7488 INVITE urcnete8r71dpkhmngd8} <script>: onreply_route[MANAGE_REPLY] method [INVITE] code [100] from [ sip:usrmt63ly_1040@example.com] to [sip:usrrcv4o4_1040@example.com] 39(35272) INFO: {2 7488 INVITE urcnete8r71dpkhmngd8} <script>: onreply_route[MANAGE_REPLY] method [INVITE] code [200] from [ sip:usrmt63ly_1040@example.com] to [sip:usrrcv4o4_1040@example.com] 39(35272) NOTICE: {2 7488 INVITE urcnete8r71dpkhmngd8} acc [acc.c:287]: acc_log_request(): ACC: transaction answered: timestamp=1680417926;method=INVITE;from_tag=18q0p37nfo;to_tag=a88272a0-25ca-43c2-8ce9-8615831b7e9a;call_id=urcnete8r71dpkhmngd8;code=200;reason=OK;src_user=usrmt63ly_1040;src_domain= example.com ;src_ip=10.218.51.86;dst_ouser=usrrcv4o4_1040;dst_user=usrrcv4o4_1040;dst_domain=10.218.51.86 38(35271) INFO: {1 7488 ACK urcnete8r71dpkhmngd8} <script>: request_route: method [ACK] from [sip:usrmt63ly_1040@example.com] socket [sip:*10.218.51.86:24061 <http://10.218.51.86:24061>*;transport=ws] to [ sip:usrrcv4o4_1040@example.com] 38(35271) INFO: {1 7488 ACK urcnete8r71dpkhmngd8} <script>: [RELAY]: method [ACK] from [sip:usrmt63ly_1040@example.com] socket [sip:*10.218.51.86:24061 <http://10.218.51.86:24061>*;transport=ws] to [ sip:usrrcv4o4_1040@example.com] socket [sip:10.218.51.86:20674 ;transport=tls] *Version: kamailio 5.6.2 (x86_64/linux)* What could be the reason for that? Your help would be much appreciated. Thanks, Joey.

3 4

How to log expiring dialogue?
by Benoît Panizzon 21 Apr '23

21 Apr '23

Hi alle I think I have an issue with the dialogue and session timer module with Kamailio 5.4 I sync the Session Expire Timer with the dialogue timeout via a common AVP. When I check a dialogue via kamcmd dlg.list start_ts: 1682066352 init_ts: 1682066346 end_ts: 0 timeout: 1682066952 lifetime: 600 Timeout is increased on the first session refreshing re-invite, as expected (in this case after 300 seconds). But it looks like the dialogue just disappears (from kamcmd dlg.list, not from the backing database) when the lifetime ist reached, leaving an orphan database entry. I would like to digg deeper into this. Is there a way to log more details from the dialogue module like when it triggers dialogue expiry? -- 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 ______________________________________________________

2 2

Roadmap to next major release series v5.7.x
by Daniel-Constantin Mierla 20 Apr '23

20 Apr '23

Hello, it is time to make the roadmap to the next major release series v5.7.x. In my opinion, I would try to freeze the development during the first part of April 2023, tentatively proposing April 14 as freezing date, being like 4 weeks from now. Then testing phase and first release (v5.7.0) sometime during May 2023. Alternative timelines can be proposed, of course. If anyone wants to add new features/modules, they have to be published till freezing date, either pushed in the git repository or proposed as pull request. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

3 5

Rtpengine: no audio after kernelization.
by Michel Pelletier 17 Apr '23

17 Apr '23

Hello, I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good. Here is a description of my environment: # cat os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" # kamailio -v version: kamailio 5.6.2 (x86_64/linux) 54a9c1 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 54a9c1 compiled on 16:02:49 Dec 1 2022 with gcc 10.2.1 # rtpengine -v Version: 11.1.1.3-1~bpo11+1 Michel Pelletier

4 13

Docker repository removed
by Manel Villar 17 Apr '23

17 Apr '23

Hi, I was using the kamailio/kamailio docker repository in one of my projects, and now the image is not available as the repo has been removed. Is the "kamailio-ci" repo a replacement for it? Thanks! -- Manel Villar Steegerstr. 59 13359 Berlin Germany Tel: (+49) (0)162 6574604 skype: manel.villar manelvf(a)gmail.com *"Ars longa, vita brevis"*

4 5

Development for v5.7.x is frozen
by Daniel-Constantin Mierla 17 Apr '23

17 Apr '23

Hello, the formal notification that the development for the next major version 5.7.0 is now frozen. The focus has to be on testing the master branch. Also, the master branch should not get commits with new features till the branch 5.7 is created, expected to happen in 2-4 weeks, a matter of how testing goes on. Meanwhile, the commits with new features in the C code can be pushed to personal branches, new pull requests can still be done, but they will be merged after branching 5.7. Can still be done commits with documentation improvements, enhancements to related tools (e.g., kamctl, kamcmd), merging exiting pull requests at this moment, exporting missing KEMI functions and completing the functionality of the new modules added for 5.7. Once the branch 5.7 is created, new features can be pushed again to master branch as usual. From that moment, the v5.7.0 should be out very soon, time used for further testing but also preparing the release of packages. If someone is not sure if a commit brings a new feature, just make a pull request and it can be discussed there on github portal or via sr-dev mailing list. A summary of what is new in upcoming 5.7 is going to be built at: * https://www.kamailio.org/wikidocs/features/new-in-5.7.x/ Upgrade guidelines will be collected at: * https://www.kamailio.org/wikidocs/install/upgrade/5.6.x-to-5.7.0/ Everyone is more than welcome to contribute to the above wiki pages, especially to the upgrade guidelines, to help everyone else during the migration process from v5.6.x to 5.7.x. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

2 2

Assigning a new RTPEngine for a call for the sake of failover
by mehdithreem+kamailio＠gmail.com 15 Apr '23

15 Apr '23

Hello, I am trying to implement RTPEngine failover, where if a selected RTPEngine node fails in the middle of the call (and not responding NG requests), I want to select an alternative node. However, when I call rtpengine_manage(), it does not seem to select an alternative node in case of a failure. To address this, I have attempted to check if $avp(RTP_INSTANCE) is null after calling rtpengine_manage(), and then use rtpengine_delete() to forget the selected RTPEngine node for the specific call, with the expectation that Kamailio would assign a new RTPEngine node for subsequent SIP message retries. However, it appears that rtpengine_delete() does not have the desired effect in this regard. Here is an excerpt of my code for reference: ``` route[RTP] { #!ifdef WITH_RTPENGINE if (has_body("application/sdp")) { if ($avp(x_source) == "INTERNAL") { rtpengine_manage("replace-session-connection replace-origin direction=internal direction=external"); } else if ($avp(x_source) == "EXTERNAL") { rtpengine_manage("replace-session-connection replace-origin direction=external direction=internal"); } if ($avp(RTP_INSTANCE) == $null) { rtpengine_delete(); drop(); } } #!endif } ``` Can you please advise on how I can achieve the desired failover behavior? Is there another function similar to `rtpengine_reset_call` that can make Kamailio forget the RTPEngine node for a specific call? Thank you!

2 1

CLI & destination based LCR
by John Cahill 14 Apr '23

14 Apr '23

Hi, I'd like to build an LCR solution that routes on both CLI & destination e.g. CLI matches ^\+49*, destinations matches ^\+44* => route to gateway 5 for a large rule set (~ tens of thousands). Any recommendations for which modules to use? Can kamailio perform this particular task well or should I look at another solution? I'd be very grateful to hear about any experience of doing this. Many Thanks. Regards, John

5 5

Kamailio + PostgreSQL
by georgy.grigoryev＠snapcom.fr 14 Apr '23

14 Apr '23

Hello everyone, I'm trying to connect Kamailio 5.5.5 to my PostgreSQL 14. They are on two different servers. I have created the Kamailio DB on the Postgre with the help of the command "kamdbctl create" I'm able to connect to the database with no problem. The problem is in the kamailio.cfg file, i have added this so far: #!define WITH_PGSQL #!ifdef WITH_PGSQL #!define DBURL "postgres://USER:PASSWORD@IP:POPT/kamailio" #!endif #!ifdef WITH_PGSQL loadmodule "db_postgres.so" #!endif modparam("db_postgres", "retries", 3) modparam("db_postgres", "timeout", 10) modparam("db_postgres", "tcp_keepalive", 600) modparam("db_postgres", "lockset", 6) modparam("db_postgres", "bytea_output_escape", 0) But my kamailio doenst like this configuration, can someone help me find the problem? Thank you in advance! Best Regards!

3 2

manipulate Authentication header
by David Villasmil 13 Apr '23

13 Apr '23

Hello guys, I can't find a simple way of changing the username and recalculate the has in a REGISTER... do i have to use textops? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 1

How to correctly use the SST module?
by Benoît Panizzon 11 Apr '23

11 Apr '23

Hi I still have odd behaviour with the SST module: modparam("sst", "min_se", 300) if (sstCheckMin("1")) { xlog("L_ERR", "$cfg(route) Session Timer too small\n"); exit; } setflag(FLT_DLG); # set the dialog flag setflag(FLT_SST); # Set the sst flag if(is_present_hf("Session-Expires")) { $avp(dlgtimeout) = $(hdr(Session-Expires){s.int}); } On an INVITE containing those header: Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: 100rel,timer Expires: 330 Now Kamailio replies: SIP/2.0 422 Session Timer Too Small Min-SE: 300 What am I doing wrong? -- 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 ______________________________________________________

1 0

dlg_onroute(): unable to find dialog for INVITE with route param
by Benoît Panizzon 10 Apr '23

10 Apr '23

Happy Eastern Kamailio 5.4 used. On dialogues calls, I noticed this happening on the second re-invite to refresh the session from the B side. dlg_onroute(): unable to find dialog for INVITE with route param 'df9.da75' [2557:22445] and call-id '14148a68-f1b2-485d-b5a2-f9dd7773d2c0' The did df9.da75 is identical to the one in the route-header on the first re-invite from the B side, before this one. No CDR was (yet) generated, and the dialogues is still present and on-going according to the database: CallID [14148a68-f1b2-485d-b5a2-f9dd7773d2c0] H-Entry: 2557 H-ID: 22445 But most probably not in memory as kamcmd dlg.stat_active shows zero (this is on a development node, so no other calls running). There are no sip messages that end the call in between those two re-invites. I see no session timeouts or similar in the logs. Any hint what could cause Kamailio not to find the corresponding dialogue on this re-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 ______________________________________________________

1 2

Fwd: Kamailio + PostgreSQL
by Stefan 07 Apr '23

07 Apr '23

Hi Give it a try without modparams to see if it works, I have the same config but without modparams and it runs without problems. Else have a look into the kamailio logfile for errors. Or check config with "kamailio -c"? Regards Stefan Am 06.04.23 um 15:18 schrieb georgy.grigoryev(a)snapcom.fr: > Hello everyone, > > I'm trying to connect Kamailio 5.5.5 to my PostgreSQL 14. > They are on two different servers. > I have created the Kamailio DB on the Postgre with the help of the > command "kamdbctl create" > I'm able to connect to the database with no problem. > The problem is in the kamailio.cfg file, i have added this so far: > > #!define WITH_PGSQL > > #!ifdef WITH_PGSQL > #!define DBURL "postgres://USER:PASSWORD@IP:POPT/kamailio" > #!endif > > #!ifdef WITH_PGSQL > loadmodule "db_postgres.so" > #!endif > > modparam("db_postgres", "retries", 3) > modparam("db_postgres", "timeout", 10) > modparam("db_postgres", "tcp_keepalive", 600) > modparam("db_postgres", "lockset", 6) > modparam("db_postgres", "bytea_output_escape", 0) > > But my kamailio doenst like this configuration, can someone help me > find the problem? > > Thank you in advance! > > Best Regards! > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > 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! > Edit mailing list options or unsubscribe:

2 2

Malformed To Header
by Serdar GUCLUER 06 Apr '23

06 Apr '23

Hello all, In my situation, it is possible to call forwarding to registered users multiple times on same leg. For each forward i have to update To uri and i am using uac_replace_to to do that. But on second relaying, To uri was malformed. On below, Im attaching configuration to illustrate my problem. (version-5.4.9) First relay - /To: //sip:xyz@192.168.0.51/ Second relay - /To: sip:xyz@192.168.0.51sip:abc@192.168.0.51/ Thanks in advance. Serdar /loadmodule "uac.so"// //modparam("uac","restore_mode","auto")// // // //request_route {// // ...// // $avp(x) = "abc";// // $avp(x) = "xyz";// // $avp(myip) = "192.168.0.51";// // $avp(i) = 0;// // route(SERDAR);// // ...// //}// // //route[SERDAR] {// // if ($(avp(x)[$avp(i)])!=$null) {// // $avp(destination) = $(avp(x)[$avp(i)]);// // $avp(i) = $avp(i) + 1;// // $rU=$_s($avp(destination));// //uac_replace_to("$_s(sip:$avp(destination)@$avp(myip))");// // route(LOCATION);// // } else {// // send_reply("403", "Opps!");// // exit;// // }// //}// // //route[LOCATION] {// // $avp(oexten) = $rU;// // if (!lookup("location") ) {// // t_newtran();// // switch ($var(rc)) {// // case -1:// // case -3:// // send_reply("480", "Temporarily Unavailable");// // exit;// // case -2:// // send_reply("405", "Method Not Allowed");// // exit;// // }// // }// // t_on_failure("SERDAR_FAILURE");// // if(!t_relay()) sl_reply_error();// // exit;// //}// // //failure_route[SERDAR_FAILURE] {// // route(NATMANAGE);// // if (t_is_canceled()) //exit;// // route(SERDAR);// //}/

6 11

Presence module and privacy
by Ihor Olkhovskyi 06 Apr '23

06 Apr '23

Hello! Is there any possibility to control more-or-less privacy related parameters of pua_dialoginfo module (like include_localremote) per subscription? Main idea is I want to show some users full info on the call other user is making, for a different user - just show fact of the call without any details. For now I'm only seeing some manual manipulation over XML based on user who is receiving NOTIFY, but maybe I'm trying to invent a weel here. -- Best regards, Ihor (Igor)

2 2

Re: Repository for modules
by Henning Westerholt 06 Apr '23

06 Apr '23

(please keep the list in the communication) Hello, you can find the modules for example in the Debian package service: https://packages.debian.org/bullseye/amd64/kamailio-tls-modules/filelist Crypto is in TLS module package. Cheers, Henning From: Duarte Rocha <duarterocha91(a)gmail.com> Sent: Donnerstag, 6. April 2023 15:42 To: Henning Westerholt <hw(a)gilawa.com> Subject: Re: [SR-Users] Repository for modules Thanks for the quick answer. How can I see info regarding which modules are in the combined packages? One of the modules i'm looking into is the crypto module for example. Otherwise, where can I get a list of modules not included in Debian packages? Cheers, Duarte Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> escreveu no dia quinta, 6/04/2023 à(s) 13:17: Hello, the majority of modules should be packaged for Debian. What modules are missing for you? Keep in mind that some modules are combined in some packages. Some modules can not properly packaged due to missing dependencies, this needs to be installed from source, right. Cheers, Henning From: Duarte Rocha <duarterocha91(a)gmail.com<mailto:duarterocha91@gmail.com>> Sent: Donnerstag, 6. April 2023 13:55 To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Subject: [SR-Users] Repository for modules Hello, I'm currently testing Kamailio on a Debian 11 machine. In order to install it I used apt with repositories from Kamailio (https://deb.kamailio.org/). Now I'm trying to add modules and I'm wondering the best way to do it. Using apt install i don't have access to all the modules. Is there another repository for this? Is my only solution downloading and compiling the modules? Cheers

1 0

Repository for modules
by Duarte Rocha 06 Apr '23

06 Apr '23

Hello, I'm currently testing Kamailio on a Debian 11 machine. In order to install it I used apt with repositories from Kamailio (https://deb.kamailio.org/). Now I'm trying to add modules and I'm wondering the best way to do it. Using apt install i don't have access to all the modules. Is there another repository for this? Is my only solution downloading and compiling the modules? Cheers

2 2

issue in kamailio of udp
by satyaprakash ch 06 Apr '23

06 Apr '23

Hi, I had upgraded Kamailio from 5.4.7 to 5.5.5, Then I restarted the Kamailio service. After upgradation im getting the below error, /usr/local/sbin/kamailio[21754]: ERROR: <core> [core/udp_server.c:596]: udp_send(): sendto(sock, buf: 0x7f7502289200, len: 61012, 0, dst: ( 10.122.45.189:5080), tolen: 16) - err: No buffer space available (105) /usr/local/sbin/kamailio[21754]: ERROR: tm [../../core/forward.h:231]: msg_send_buffer(): udp_send failed /usr/local/sbin/kamailio[21754]: ERROR: tm [uac.c:678]: send_prepared_request_impl(): Attempt to send to precreated request failed ERROR: tm [../../core/forward.h:231]: msg_send_buffer(): udp_send failed ERROR: tm [uac.c:678]: send_prepared_request_impl(): Attempt to send to precreated request failed Anyone have any idea on this errors.

2 3

SCSCF hangs randomly
by solomon.thoobe＠smilecoms.com 05 Apr '23

05 Apr '23

Hi All, We currently experience issues where scscf hangs randomly throughout the day. It started hanging once in a month, the issue has gotten worse over time and now it can hang more than 5 times in a day. I have no prior kamailio experience or experience debugging c applications. Kamailio version: 4.4.0 Running ps shows scscf processes are running. Service status also shows scscf is running but it does not respond to sip requests. Testing with sipsack hangs and print timeout errors. root@NGVI-PCSCF2:/var/log # service scscf status * Status of Kamailio SIP Server: * scscf is running sipsak -vv -s sip:NGVI-PCSCF2:6060 received ICMP message received ICMP message** timeout after 500 ms** Below is the extract from log files Apr 5 12:04:46 NGVI-PCSCF2 /usr/sbin/kamailio[5102]: {1 1 ACK isbc505ramjjjr3g23cs02r53cms0uxbg2es(a)10.18.5.64} WARNING: tm [t_lookup.c:1476]: t_unref(): WARNING: script writer didn't release transaction Apr 5 12:04:46 NGVI-PCSCF2 /usr/sbin/kamailio[5104]: {1 3 REGISTER _A9LGREyW2miE7LhPJzv7g..} ERROR: ims_registrar_scscf [save.c:1034]: update_contacts(): Unable to remove contact <sip:+2347020246874@154.66.2.182:5060;rinstance=28bf37d2cce6e4a1;transport=udp> Apr 5 12:04:47 NGVI-PCSCF2 /usr/sbin/kamailio[5131]: ERROR: rr [rr_mod.c:300]: w_record_route(): Double attempt to record-route Apr 5 12:04:47 NGVI-PCSCF2 /usr/sbin/kamailio[5144]: ERROR: rr [rr_mod.c:300]: w_record_route(): Double attempt to record-route Apr 5 12:04:47 NGVI-PCSCF2 /usr/sbin/kamailio[5108]: {1 1 ACK r8ug398d118i8iaaunrouggisntkigkn(a)10.18.5.64} WARNING: tm [t_lookup.c:1476]: t_unref(): WARNING: script writer didn't release transaction Apr 5 12:04:48 NGVI-PCSCF2 /usr/sbin/kamailio[5190]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 23 Apr 5 12:04:48 NGVI-PCSCF2 /usr/sbin/kamailio[5062]: ALERT: <core> [main.c:741]: handle_sigs(): child process 5103 exited by a signal 11 Apr 5 12:04:48 NGVI-PCSCF2 /usr/sbin/kamailio[5062]: ALERT: <core> [main.c:744]: handle_sigs(): core was generated Apr 5 12:06:12 NGVI-PCSCF2 kamailio: WARNING: <core> [daemonize.c:348]: daemonize(): pid file contains old pid, replacing pid Apr 5 12:06:13 NGVI-PCSCF2 /usr/sbin/kamailio[15060]: WARNING: interconnectroute [ported_cache.c:113]: initPortedNumberCount(): Requested records[726049]: Total allocated[871258]: Fat 20% :Total MemUsed [26 MB divided between primary[0x7f22b8667d60] and secondary[0x7f22b93b3390]] pr 5 04:38:24 NGVI-PCSCF2 /usr/sbin/kamailio[14018]: message repeated 107 times: [ ERROR: ims_usrloc_scscf [subscribe.c:430]: free_subscriber(): record not found in hash table] Apr 5 12:50:38 NGVI-PCSCF2 /usr/sbin/kamailio[2604]: WARNING: interconnectroute [icncache_eventprocessor.c:76]: icnRefreshProcess(): total size 2147483648 qm_real_used 700707576 qm_used 387064680 1st_frag 0x7fd5f6d6a690 last_frag 0x7fd676d30fd0 Apr 5 13:00:25 NGVI-PCSCF2 /usr/sbin/kamailio[2437]: ERROR: ims_usrloc_scscf [subscribe.c:430]: free_subscriber(): record not found in hash table Apr 5 13:00:26 NGVI-PCSCF2 /usr/sbin/kamailio[2437]: message repeated 125 times: [ ERROR: ims_usrloc_scscf [subscribe.c:430]: free_subscriber(): record not found in hash table] Apr 5 13:01:25 NGVI-PCSCF2 /usr/sbin/kamailio[2437]: CRITICAL: <core> [main.c:650]: sig_alarm_abort(): shutdown timeout triggered, dying... Apr 5 13:02:30 NGVI-PCSCF2 kamailio: WARNING: <core> [daemonize.c:348]: daemonize(): pid file contains old pid, replacing pid Apr 5 13:02:30 NGVI-PCSCF2 /usr/sbin/kamailio[27629]: WARNING: interconnectroute [ported_cache.c:113]: initPortedNumberCount(): Requested records[726049]: Total allocated[871258]: Fat 20% :Total MemUsed [26 MB divided between primary[0x7f3093a3fd60] and secondary[0x7f309478b390]] Thank you in advance. Regards, Solly Thoobe

3 2

urn:emergency:service:sos as RURI
by a.izquierdo＠zaleos.net 05 Apr '23

05 Apr '23

Hello, I'm running a Kamailio instance with some routing logic in it. When a UA sends an INVITE with urn:emergency:service:sos as RURI, Kamailio responds with a 400 Bad Request URI. I have set debug log level and it looks like the problem is in the parse_uri.c when sanity_check("1511", "7") is called: parse_uri(): bad char ':' in state 3 parsed: <urn:emergency:service> (21) / <urn:emergency:service:sos> (25) According to RFC8141 (https://www.rfc-editor.org/rfc/rfc8141), this is a correct URN, but maybe I'm missing something. Is there a way to make Kamailio parse this RURI? Kamailio version used: 5.6.4 Thank you!

3 2

segfault during Identity verification (stirshaken)
by Yuriy Nasida 04 Apr '23

04 Apr '23

Hello, It's kamailio 5.6.4. I can say that there is no segfault in case Identity is OK but bad attempts sometimes are the reason for segfault. Not sure I can duplicate but it happens several times per day. Please look at logs. in messages: Apr 3 09:40:02 kam1 kernel: [6381565.762987] kamailio[9141]: segfault at 746c75616665 ip 00007f20c4cab6df sp 00007ffe7ec51470 error 4 in libcrypto.so.1.1[7f20c4c3b000+19e000] kamailio.log: Apr 3 09:40:02 kam1 kamailio[9141]: NOTICE: <script>: it is INVITE with Identity. Lets check Identity Apr 3 09:40:02 kam1 kamailio[9141]: CRITICAL: <core> [core/mem/q_malloc.c:501]: qm_free(): BUG: bad pointer 0x645f6d6574737973 (out of memory block!) called from tls: tls_init.c: ser_free(323) - ignoring Apr 3 09:40:02 kam1 kamailio[9182]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 53 Apr 3 09:40:02 kam1 kamailio[9100]: ALERT: <core> [main.c:774]: handle_sigs(): child process 9141 exited by a signal 11 Apr 3 09:40:02 kam1 kamailio[9100]: ALERT: <core> [main.c:777]: handle_sigs(): core was not generated Apr 3 09:40:02 kam1 kamailio[9100]: CRITICAL: <core> [core/mem/q_malloc.c:501]: qm_free(): BUG: bad pointer 0x645f6d6574737973 (out of memory block!) called from tls: tls_init.c: ser_free(323) - ignoring loadmodule "stirshaken.so" ####### STIRSHAKEN ###### modparam("stirshaken", "vs_verify_x509_cert_path", 1) modparam("stirshaken", "vs_ca_dir", "/etc/kamailio/stir_CA") #modparam("stirshaken", "vs_crl_dir", "/etc/kamailio/CRL") modparam("stirshaken", "as_default_key", "/etc/kamailio/key/private_key.pem") modparam("stirshaken", "vs_cache_certificates", 1) modparam("stirshaken", "vs_cache_dir", "/tmp/cert_cache") modparam("stirshaken", "vs_cache_expire_s", 100) if (is_method("INVITE") && is_present_hf("Identity")) { xlog("L_NOTICE", "it is INVITE with Identity. Lets check Identity\n"); if (1 == stirshaken_check_identity()) { xlog("L_NOTICE", "Shaken Identity is OK\n"); } else { xlog("L_NOTICE", "Shaken Identity is invalid\n"); } } Please give me some advice.

2 2

Handling stateless replies with kemi
by Ovidiu Sas 03 Apr '23

03 Apr '23

Hello all, How can we handle stateless replies with kemi? tm has the following param: modparam("tm", "on_sl_reply", "stateless_replies") What's the proper way to map the "stateless_reply" onreply_route to a kemi function. I'm playing with the app_jsdt module. Thanks, Ovidiu

5 7

How to check, if call is already handled by rtpengine module?
by Benoît Panizzon 02 Apr '23

02 Apr '23

Hi Running Kamailio Registrar Node + rtpengine without dialog module, only TRX module. Situation: Some customer are in ranges to which RTP can directly be routed, some are not. So rtpengine shall be engaged only when backhauling of the rtp stream is required. On a message from a CPE, this is done by checking $si and on a message to the CPE by checking $(ulc(aor=>addr)[$T_branch_idx]{uri.host}); On a BYE, rtpengine_delete() is called no matter if RTP was backhauled or not. If rtpengine does not find the call to delete, no harm happens. But now I struggle with Session Refresh Re-Invites TO the CPE as they are routed very early on and do not pass the whole location lookup stuff, therefore I have no access to the aor=>addr to determine if the destination needs backhauling or not. So the obvious solution which came to my mind is to call rtpengine_query() and see if it is finding the call and if so, call rtpengine_manage() to keep backhauling traffic on the Re-Invites refrreshing the session. Unfortunately, I found no way to check if rtpengine_query finds the call. Did I miss something? -- 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 ______________________________________________________

2 1

Germany unsure about whether Kamailio will survive next winter
by Alex Balashov 01 Apr '23

01 Apr '23

For immediate release: ATLANTA, GA (1 April 2023)--The Federal Ministry for Economic Affairs and Energy of Germany was forced to disclose today that it has been tasked with assessing whether Germany will be able to operate its Kamailio through the next winter. This initiative comes amidst considerable uncertainty, shared in some other EU member states, about whether the enormous fossil fuel energy footprint of Kamailio is sustainable after the Russian invasion of Ukraine in early 2022. Pioneering Atlanta energy market analysts Evariste Systems were tapped to assist with forecasting whether German strategic natural gas reserves and liquefied natural gas (LNG) imports could keep Kamailio's enormous turbines spinning under a variety of stress-test scenarios outlined by regulators, including SIPP and SIPVicious. Alex Balashov, Evariste's principal, said in a news conference earlier this week: "Simply put, the political leadership wanted a dispassionate, technocratic kind of analysis, data-driven and the rest, free of the inflection of ideological bias and tendentious policy angles in charged German domestic politics. Whether it's the centre-right or the Greens, there are strong ideas about what to do with energy-greedy megaprojects like Kamailio." Florida-based energy turnaround vet Fred Posner, parachuted in to assist with the fast-tracked study, agreed: "It's well-understood that the German GDP is almost a perfectly linear function of gross annual SIP packets routed. The Nord Stream 1 shut-off situation in September only exposed Germany to further Kamailio-related energy vulnerabilities." At issue are the basic physics of SIP message routing in Kamailio. Due to a fixed-size worker process pool, Kamailio routing consumes about 1500 BTUs per packet-kilometre travelled. While 1500 BTUs/packet-kilometre is efficient in distance terms as compared to a typical automobile, which consumes roughly 3800 BTUs of fossil fuel energy per passenger-kilometre travelled (at typical load factors), the dizzying number of SIP packets routed through German territory in a typical business day greatly outstrips passenger-kilometres travelled. Balashov noted that sometimes, the activation energy requirement can be higher than 1500 BTUs when INVITEs with large SDPs are launched toward the next hop, though this varies with the altitude of the destination above mean sea level, wind direction, weather and other factors involved in ballistics. "It's a bit of a fool's errand to play these guessing games with averages. The energy budget can vary enormously depending on whether there is DTLS, video codecs, PASSporTs and other stuff. I find it helpful to think in kilowatt-hour terms: sometimes it's less than half a kWh, so like US $0.20 if you're counting the beans, and sometimes it's more like $0.38, we just don't know. The Bundestag always wants these big, round numbers, but if you've ever looked at the TM module, you know that's not how this works." A milder-than-expected winter, a 9% year-over-year increase in US LNG exports (to about 300 million cubic metres per day) in 2022, dependable imports from Norway and the Netherlands, and other favourable factors gave German SIP regulators a reprieve. Despite energy market volatility, premium LNG spot prices, and occasional 408 Request Timed Out scenarios, the country dodged a widely-feared Kamailio energy crisis. However, it is difficult to say whether energy market conditions will be as propitious next year. "Then there's the whole climate change goals thing. Nobody even wants to talk about that, especially for the WebRTC gateway side," says Posner. "There's a persistent fantasy that we can just power Kamailio with solar or wind if we just had enough generating capacity. I think that's really missing the forest for the trees. The worker processes stay running whether you need them or not, it all depends on how many listeners you have set and what the children config value is. Either way, I've got two words for you: base load. Even if we completely ignore that the energy density is just not there per hectare of solar or wind installation, how do you provide the constant power to the child processes?" Past feasibility studies published jointly by Balashov and Posner support this assessment. One such study, initiated in 2018 and concluded during the COVID-19 global pandemic, found that an area equivalent to the size of the entire state of North Rhine-Westphalia would need to be devoted to batteries, even using the latest lithium ferrous phosphate (LFP) technology. "But wait, there's more!" says Posner: "Show me the amperage." "The packet forwarding mechanism is similar to a railgun, at least if you're doing stateful. Where are you going to get the millions of amps? It's either setting up huge banks of capacitors god-knows-where, or the pulsed power system that's undergirded by the original OpenSER turbines. I think we already know the answer to that." Balashov noted that, even beyond the political and economic challenges that Kamailio downtime would introduce, there are other tightropes to walk. As the most economically dynamic, export-oriented EU member state, Germany is prone to flirt with SIP proxy privatisation schemes in its national discourse, all while messaging a stronger Euro to the ECB. "There is a vocal minority," says Balashov, "who push for research into more modular, regionally sited SIP gateways. They're always talking about sclerotic, unresponsive federal regulations and listless, bumbling Brussels bureaucrats and making it all smaller and leaner. Listen, I'm all for the Invisible Hand, but setting the Request URI and adding custom headers requires a truly integrated, national-scale infrastructure. It's the stuff of public-private partnerships and megaprojects. Even if you're a market zealot who is not sold on basic INVITEs as a public good, think about Presence or IMS. You really need the full capacity of a nation-state on deck for that." If devolution to smaller, more numerous SIP routing sites is not feasible--at least, at the unit cost and reliability level demanded by advanced economies--then excessive complexity offers a cautionary tale from the opposite extreme. In a particularly notorious example of technical and policy failure, the Electric Reliability Council of Texas (ERCOT), following the guidance of northern Californian advisors Unicorn & Moonshot, attempted to scale down traditional Kamailio turbine blades into newer, so-called Kubernetes "Pod" chasses to increase exhaust recapture. This made for a much more intricate installation with an exponential growth of moving parts, telemetry and site support skill requirements. This proved unmanageable, and the now-famous explosion that followed the deterioration of the site led to unprecedented casualties in US history. Furthermore, it also resulted in the long-term humidification of large expanses of East Texas, Louisiana, Mississippi and southern Alabama, rendering most of these areas uninhabitable. These events discredited the Unicorn & Moonshot approach in the eyes of most industry analysts. While it will take some months for Evariste to reach a conclusion regarding the resilience of the German Kamailio through the winter and beyond, and it will take still longer to issue policy recommendations, one factor is universally agreed upon already: this prolonged test of Germany's resilience is part of a Russian strategic calculation. A conservative MP from the CDU/CSU faction of the Bundestag, speaking on condition of anonomity, offered this summary: "The Russians think they can wait this out. They are waiting for us to fold and switch to an OpenSIPS reactor, knowing full well this will keep us busy with troubleshooting and diminish our ability to support Ukraine militarily." -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

2 1

How to get top-most outbound via branch attribute from branched call?
by Benoît Panizzon 31 Mar '23

31 Mar '23

Hi all For rtpengine to correctly distinguish branched calls, the top-most via branch= parameter should be passed to it. I have attempted to use $via0 but that does not yet exist in Kamailio 5.4 So I did try to read $hdr(Via) which I guess returns an array and then access: but this returns the inbound via, not the one generated on the branched call. How can this be accomplished with kamailio 5.4? -- 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 ______________________________________________________

1 1

CANCEL timeout in branch route does not trigger any failure routes
by Richard Chan 31 Mar '23

31 Mar '23

Hi Kamailio users How can I get a failure route to trigger in timeout-to-CANCEL in a parallel forking scenario? Parallel forking test scenario 1. one(the main - 0) branch picks up the call 2. 2nd branch sends CANCEL (expecting 487 etc) - but the callee does not send any replies Result: No failure route handlers are called on timeout of this CANCEL - that is kamailio attempts the CANCEL 4 times but neither tm.t_on_failure_route, tm.t_on_branch_failure handlers are called. Any suggestions on how to resolve this? Regards Shih-Ping

3 2

Rancher, AWS, and Elastic IP
by Calvin E. 30 Mar '23

30 Mar '23

I'm looking for documentation//howto/advice/best practices for running Kamailio under Kubernetes on AWS via Rancher. Specifically, how to manage the public/Elastic IP. This is a load balancer (dispatcher) scenario with rtpengine for receiving inbound calls from a DID provider, but a similar configuration might be used for clients. I'm open to using an AWS load balancer, and would like to scale with multiple Kamailio pods behind a single public IP. I'd rather use Rancher-managed EC2 than pay extra for EKS, unless EKS can cancel out its own cost. This sounds like it should be a solved problem, just complex. I see blogs and videos out there, but it's not always obvious if their content is current. Anyone want to help me peel this onion? -Calvin

4 6

MongoDB query from Kamailio help needed
by Edo 28 Mar '23

28 Mar '23

Help is needed. I know I have seen a similar problem either via email or google search but for the life of me I cannot find it now. I am using: Ubuntu: 5.4.0-144-generic #161-Ubuntu SMP Fri Feb 3 14:49:04 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Kamailio: version: kamailio 5.3.9 (x86_64/linux) -- This is a dev platform and I can update kamailio if needed. I am trying to query a mongodb collection for the phone number stored under “did” as an integer and make a decision based on the returned result (boolean is sufficient for this decision). I don’t know what I am doing wrong here. Any help will be well appreciated ##### This is the insert statement into the telephone db from a linux script db.c$coll.insertOne({"did":parseInt($(cut -d_ -f 1 <<< $1)), "callDesc":$(cut -d_ -f 1 <<< $1)}))" >> $(cut -d_ -f 1 <<< $1).js did is stored as an integer and the callDesc is stored as presented by $rU { "_id" : ObjectId("641580b4863678d0ba38d69a"), "did" : 1XXXXXXXXXX, "callDesc" : 1XXXXXXXXXXXX } > db.c234.find() { "_id" : ObjectId("641580b4863678d0ba38d69a"), "did" : 2XXXXXXXXXXXX, "callDesc" : 2XXXXXXXXXXXX } > db.c234.find() { "_id" : ObjectId("641580b4863678d0ba38d69a"), "did" : 3XXXXXXXXXXXX, "callDesc" : 3XXXXXXXXXXXX } > Kamailio config: ..... ..... # --- mongodb module loaded 202201082322 loadmodule "ndb_mongodb.so" if (uri==myself) { sl_send_reply("100", "Trying to check if uri is myself $rU $ru"); #return; #Adding this to test connection to mongodb…. This worked and the reply was sent to the endpoint if(*mongodb_cmd_simple*("mongodbsrv1", "telephone", "cXXX”, "{ \"collStats\": \"cXXX\” }", "mgr1")) { sl_send_reply("183", "I got inside this message loop $rU found in mongodb"); xlog("response from mongodb is [[$mongodb(mgr1=>value)]]\n"); } # End of the test #This is to run the actual db query to test if the phone number is in the mongodb…. I am not successful at this query even when the number is known to be in the database if(*mongodb_find_one*("mongodbsrv1", "telephone", "cXXX”, "{\"did\" : \"$rU\" }", "mongoResponse1")) { # Route to confirmed route here -- 202302212032 sl_send_reply("183", "I got inside this mongodb message loop"); route(CONFIRMED_ROUTE); xlog("response from mongodb is [[$mongodb(mongoResponse1=>value)]]\n"); } else { route(UNCONFIRMED_ROUTE); } } #append_hf("P-hint: outbound\r\n"); route(RELAY); #exit; } Please help. -- ----- Ekunwe Tel: 601.497.3932

2 2

Three year old issue with a new CVE vulnerability report being reported
by Olle E. Johansson 28 Mar '23

28 Mar '23

Hi Kamailians! A new CVE with a critical severity level was published recently for an almost three year old bug, which was also fixed and released three years ago (CVE-2020-27507). The issue was fixed in Kamailio 5.4.2 and is not present in newer releases. The Kamailio project has unfortunately not been involved in the CVE process or been informed about this old issue being published at this time. We take vulnerability handling seriously and our process is documented at: https://www.kamailio.org/wikidocs/security/policy/ The latest stable branch is 5.6, with v5.6.4 released out of it. Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-27507 Best regards and thanks for flying Kamailio! The Kamailio dev team through /Olle

4 3

json RPC syntax
by Volker Denneberg 28 Mar '23

28 Mar '23

Hello, I am trying to get json RPCs running. simpleequests seem to work, but I can't figure out how to pass parameters. For example curl --header 'Content-Type: application/json' --data-binary '{"id": 1,"jsonrpc": "2.0", "method": "ul.db_users" }' http://localhost:8081/RPC/ { "jsonrpc": "2.0", "error": { "code": 500, "message": "Not enough parameters (table to lookup)" }, "id": 1 } According to http://www.kamailio.org/docs/docbooks/3.2.x/rpc_api/rpc_api.html#rpc.gettin… parameters dont have names and according to http://www.kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.r.db_… 1 parameter is required. I guessed adding "params":"location" => no error anymore, but still no result: curl --header 'Content-Type: application/json' --data-binary '{"id": 1,"jsonrpc": "2.0", "method": "ul.db_users", "params":"location"}' http://localhost:8081/RPC/ { "jsonrpc": "2.0", "result": { }, "id": 1 } Same result (no error) if I pass "params":"nonsense", so "params" seems to be kind of ignored ... What's the correct json syntax here or in general? Best regards, Volker

5 6

KEMI: app_jsdt_run_ex(): js loading state not initialized (call: ksr_htable_event)
by Ovidiu Sas 27 Mar '23

27 Mar '23

Hello all, While using KEMI with app_jsdt I noticed the following possible regression between 5.5 and 5.6. The following config is working ok on 5.5 but throws an error on 5.6: ERROR: app_jsdt [app_jsdt_api.c:555]: app_jsdt_run_ex(): js loading state not initialized (call: ksr_htable_event) kamailio.cfg: debug=2 children=1 log_facility=LOG_LOCAL0 log_name="k" mpath="/home/osas/src/kamailio/src/modules" loadmodule "htable/htable.so" modparam("htable", "event_callback", "ksr_htable_event") modparam("htable", "event_callback_mode", 1) loadmodule "kemix/kemix.so" loadmodule "app_jsdt/app_jsdt.so" modparam("app_jsdt", "load", "/usr/local/etc/kamailio/kamailio.js") cfgengine "jsdt" kamailio.js: function ksr_htable_event(evname) { KSR.info("ksr_htable_event(" + evname + ")\n"); } function ksr_request_route() { KSR.x.exit(); } If we load the htable module after app_jsdt, then the error is gone. Is there something new during init in 5.6 that requires specific module loading order? -ovidiu

2 2

Handling branch-level append_hf()
by Alex Balashov 27 Mar '23

27 Mar '23

Hi, I’ve got a situation where I catch a 302 redirect in a failure_route (branch #1), and use the Contact to set a custom header (append_hf()). This custom header is utilised on the subsequent branch (branch #2), but if that branch fails (e.g. due to 4xx-5xx response), the custom header is not preserved on subsequent branches (branch #3+). What’s the best way to preserve it across subsequent branches? The documentation for msg_apply_changes() says it cannot be used once the transaction is already created, and in any case, I have other branch-level changes in branch #2 that I _would_ like to revert on subsequent branch attempts (i.e. branch #3). I can certainly devise a transaction-persistent vehicle for this value which can be checked on every branch, but I wondered if there’s an easier and more best-practical way. Thanks! — Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

2 1

No voice for webrtc call
by Arun K R 25 Mar '23

25 Mar '23

Hello, I am using kamailio to register the webrtc client and routes the calls to asterisk using pjsip. I am having no voice on both ends. Logs are attached witht this email. Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [control] Received command 'offer' from 10.13.1.127:59841 Mar 24 13:06:58 debian rtpengine[7345]: NOTICE: [8asmubtpv46ac7nrfk57]: [core] Creating new call Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [control] Replying to 'offer' from 10.13.1.127:59841 (elapsed time 0.016067 sec) Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [control] Received command 'answer' from 10.13.1.127:52045 Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [control] Replying to 'answer' from 10.13.1.127:52045 (elapsed time 0.000997 sec) Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [ice] ICE negotiated: peer for component 1 is 10.13.1.170:15634 Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [ice] ICE negotiated: local interface 10.13.1.127 Mar 24 13:06:58 debian rtpengine[7345]: ERR: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [core] SRTP output wanted, but no crypto suite was negotiated Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [control] Received command 'answer' from 10.13.1.127:52045 Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [control] Replying to 'answer' from 10.13.1.127:52045 (elapsed time 0.000786 sec) Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [crypto] DTLS: Peer certificate accepted Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [crypto] DTLS-SRTP successfully negotiated using AES_CM_128_HMAC_SHA1_80 Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [crypto] DTLS-SRTP successfully negotiated using AES_CM_128_HMAC_SHA1_80 Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [ice] ICE negotiated: peer for component 1 is 10.13.1.170:15634 Mar 24 13:06:58 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [ice] ICE negotiated: local interface 10.13.1.127 Mar 24 13:07:02 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [core] Confirmed peer address as 10.13.1.170:15634 Mar 24 13:07:02 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [core] Kernelizing media stream: 10.13.1.170:15634 -> 10.13.1.127:10940 | 10.13.1.127:10960 -> 192.168.30.200:53489 Mar 24 13:07:02 debian rtpengine[7345]: WARNING: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [core] No support for kernel packet forwarding available (encryption cipher or HMAC not supported by kernel module) Mar 24 13:07:02 debian rtpengine[7345]: NOTICE: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [core] Setting 'non-forwarding' flag for kernel stream due to lack of sinks Mar 24 13:07:03 debian rtpengine[7345]: ERR: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [rtcp] SRTCP output wanted, but no crypto suite was negotiated Mar 24 13:07:03 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [core] Removing media stream from kernel: local 10.13.1.127:10940 Mar 24 13:07:03 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [core] Kernelizing media stream: 10.13.1.170:15634 -> 10.13.1.127:10940 | 10.13.1.127:10960 -> 192.168.30.200:53489 Mar 24 13:07:03 debian rtpengine[7345]: WARNING: [8asmubtpv46ac7nrfk57/223df8fa-8106-48af-844f-33f97530a0d8/1 port 10940]: [core] No support for kernel packet forwarding available (encryption cipher or HMAC not supported by kernel module) Mar 24 13:07:04 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [control] Received command 'delete' from 10.13.1.127:52045 Mar 24 13:07:04 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] Scheduling deletion of call branch '9693uq66f0' (via-branch '') in 30 seconds Mar 24 13:07:04 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] Scheduling deletion of call branch '223df8fa-8106-48af-844f-33f97530a0d8' (via-branch '') in 30 seconds Mar 24 13:07:04 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] Scheduling deletion of entire call in 30 seconds Mar 24 13:07:04 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [control] Replying to 'delete' from 10.13.1.127:52045 (elapsed time 0.001463 sec) Mar 24 13:07:17 debian /usr/local/sbin/kamailio[13362]: INFO: <script>: 10.13.1.170 authentication bypassed for sip:developer@10.13.1.127 Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] Final packet stats: Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] --- Tag '9693uq66f0', created 0:36 ago for branch '' Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] --- subscribed to '223df8fa-8106-48af-844f-33f97530a0d8' Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] --- subscription for '223df8fa-8106-48af-844f-33f97530a0d8' Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] ------ Media #1 (audio over UDP/TLS/RTP/SAVPF) using unknown codec Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] --------- Port 10.13.1.127:10960 <> 192.168.30.200:53489, SSRC 0, in 0 p, 0 b, 292 e, 36 ts, out 0 p, 0 b, 0 e Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] --- Tag '223df8fa-8106-48af-844f-33f97530a0d8', created 0:36 ago for branch '' Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] --- subscribed to '9693uq66f0' Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] --- subscription for '9693uq66f0' Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] ------ Media #1 (audio over UDP/TLS/RTP/SAVPF) using opus/48000/2 Mar 24 13:07:34 debian rtpengine[7345]: INFO: [8asmubtpv46ac7nrfk57]: [core] --------- Port 10.13.1.127:10940 <> 10.13.1.170:15634, SSRC 1ada0b2b, in 292 p, 40137 b, 1 e, 30 ts, out 2 p, 1449 b, 0 e

2 3

different sip response on database (mysql) timeout
by Leon de Rooij 24 Mar '23

24 Mar '23

Hi, I need to use a database that may sometimes timeout and I'd like to give a conditional sip response based on whether there was a timeout or not. I'm using sqlops with mysql modules. Does anyone know if that's possible ? Thanks, Leon

3 3

Route: comma separated HOP list
by Benoît Panizzon 24 Mar '23

24 Mar '23

Hi List Cisco-SPA112 does reply to an invite containing Record-Route header with one Route: Header containing a comma separated list of those hops. It looks like kamailio fails to parse them and correctly route for example an ACK to a 200 OK. Is this a known issue? Is there a solution? -- 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 ______________________________________________________

2 2

WebRTC "client did not present a certificate" error
by David Cunningham 23 Mar '23

23 Mar '23

Hello, We have a Kamailio 5.2.7 server with WebRTC enabled. However, a WebRTC client at https://tryit.jssip.net/ is unable to connect on either Chrome or Firefox. In the Kamailio log we see the lines below. In tls.cfg we have "verify_certificate = no" and "require_certificate = no" for both [server:default] and [client:default]. Would anyone be able to help us with this? Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_domain.c:1159]: tls_lookup_private_key(): Private key lookup for SSL_CTX-0x14baf1cbb090: (nil) Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_domain.c:749]: sr_ssl_ctx_info_callback(): SSL handshake done Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_domain.c:737]: sr_ssl_ctx_info_callback(): SSL handshake started Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_domain.c:741]: sr_ssl_ctx_info_callback(): SSL renegotiation initiated by client Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_domain.c:749]: sr_ssl_ctx_info_callback(): SSL handshake done Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_domain.c:737]: sr_ssl_ctx_info_callback(): SSL handshake started Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_domain.c:741]: sr_ssl_ctx_info_callback(): SSL renegotiation initiated by client Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_domain.c:749]: sr_ssl_ctx_info_callback(): SSL handshake done Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_server.c:424]: tls_accept(): TLS accept successful Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_server.c:431]: tls_accept(): tls_accept: new connection from xx.xx.xx.xx:39816 using TLSv1.3 TLS_AES_256_GCM_SHA384 256 Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_server.c:434]: tls_accept(): tls_accept: local socket: yy.yy.yy.yy:8443 Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_server.c:445]: tls_accept(): tls_accept: client did not present a certificate Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: tls [tls_server.c:1189]: tls_read_f(): Reading on a renegotiation of connection (n:532) (0) Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: <core> [core/tcp_read.c:1527]: tcp_read_req(): EOF Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x562ffde66d00, 17, -1, 0x10) fd_no=4 called Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: <core> [core/tcp_read.c:1680]: release_tcpconn(): releasing con 0x14baf4cc1ec8, state -1, fd=17, id=665 ([xx.xx.xx.xx]:39816 -> [xx.xx.xx.xx]:8443) Mar 22 01:25:28 br /sbin/kamailio[25259]: DEBUG: <core> [core/tcp_read.c:1684]: release_tcpconn(): extra_data 0x14baf289ea30 Mar 22 01:25:28 br /sbin/kamailio[25291]: DEBUG: <core> [core/tcp_main.c:3320]: handle_tcp_child(): reader response= 14baf4cc1ec8, -1 from 1 Mar 22 01:25:28 br /sbin/kamailio[25291]: DEBUG: tls [tls_server.c:683]: tls_h_close(): Closing SSL connection 0x14baf289ea30 Thanks very much, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

4 7

How to require session timer and set a max session timer value?
by Benoit Panizzon 23 Mar '23

23 Mar '23

Hi All I would like to avoid having run away calls as good as possible. For this, I would like to require timers and set the maximum expires timer to say 1800 I had a look at the sst module, but I see no way to require timers or to set a max timers value. Do my intentions make sense? How did others accomplish this task? Thanks for any hints! 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

With TOPOH module enabled, transferred call hangup from callee side does not hang up the call
by Arsenijs Kabihno 22 Mar '23

22 Mar '23

Hello, we have faced an issue which appears when TOPOH module is enabled, call is made from WebRTC client, then transferred by callee. We have WebRTC client behind load balancer. We make call to softphone from WebRTC, call from softphone is transferred to external number using Asterisk. When call is hanged up on external number side, it doesn't hangs up on WebRTC client side. If TOPOH is not enabled, this issue doesn't occur. We have the following TOPOH-related sections of kamailio.cfg: <...> #!ifdef WITH_TOPOH loadmodule "topoh.so" #!endif <...> <...> #!ifdef WITH_TOPOH modparam("topoh", "mask_key", "xxxxxxxxxxxxxxxx") modparam("topoh", "mask_ip", "10.0.0.1") modparam("topoh", "mask_callid", 0) modparam("topoh", "sanity_checks", 1) modparam("topoh", "uparam_prefix", "") modparam("topoh", "vparam_prefix", "") modparam("topoh", "callid_prefix", "1337") #!endif <...> <...> #!ifdef WITH_DIALOG modparam("dialog", "db_url", DBURL) modparam("dialog", "db_mode", 1) modparam("dialog", "db_fetch_rows", 800) modparam("dialog", "track_cseq_updates", 1) modparam("dialog", "ka_interval", 30) modparam("dialog", "ka_timer", 30) modparam("dialog", "send_bye", 0) modparam("dialog", "dlg_filter_mode", 1) #!ifdef WITH_TOPOH modparam("dialog", "lreq_callee_headers", "TH: dlh\r\n") #!endif #!endif <...> <...> #!ifdef WITH_DISPATCHER event_route[dispatcher:dst-up] { sql_query("ds_dburl", "select description from dispatcher where destination='$ru'", "ds_dbresult"); xlog("L_WARN", "Destination up: $ru, found name: $dbr(ds_dbresult=>[0,0])\n"); prom_gauge_set("trunk_reachability", "1", "$ru", "$dbr(ds_dbresult=>[0,0])"); } event_route[dispatcher:dst-down] { sql_query("ds_dburl", "select description from dispatcher where destination='$ru'", "ds_dbresult"); xlog("L_WARN", "Destination down: $ru, found name: $dbr(ds_dbresult=>[0,0])\n"); prom_gauge_set("trunk_reachability", "0", "$ru", "$dbr(ds_dbresult=>[0,0])"); } #!endif #!ifdef WITH_TOPOH event_route[topoh:msg-sending] { if(is_reply() and $rs=="302") { drop; } } #!endif (can provide the full config, if needed) We are receiving the following errors: On transfer: https://pastebin.com/H3FQ4Kpj On hangup from external number side: https://pastebin.com/wgfRzGbd On hangup from WebRTC client side: https://pastebin.com/sE0yhBae There are also differences in SIP traffic when TOPOH is disabled and when it is enabled. With TOPOH enabled, apparently, ACK from Asterisk is not reaching kamailio: asterisk INVITE -> kamailio -> WebRTC WebRTC 200 -> kamailio -> asterisk asterisk ACK -> kamailio -> -> -> (SIP flows attached - topoh_on.csv, topoh_off.csv) kamailio -v version: kamailio 5.6.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, 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_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 09:11:15 Nov 15 2022 with gcc 9.3.0 We have dockerized kamailio running on Ubuntu 16.04.3 LTS Docker version 18.03.1-ce, build 9ee9f40 Please advise where to start looking.

1 0

OT: path support fix for asterisk
by Henning Westerholt 21 Mar '23

21 Mar '23

Hello, It's off-topic, but it was several times discussed here on the list. It seems that the upcoming 18.17 and 20.2 asterisk version seems to properly support path headers. From the announcement: * [ASTERISK-30100<https://issues.asterisk.org/jira/browse/ASTERISK-30100>] - res_pjsip: Path is ignored on INVITE to endpoint (Reported by Yury Kirsanov) This bug has been many years open. have not tried it yet, but it looks promising. Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

7 8

Follow-up: Printing Global Parameter Values & Logging JSONRPC Requests over UDP
by sadik.oualla.mohamed＠gmail.com 18 Mar '23

18 Mar '23

Hello everyone, I am following up on my previous email regarding printing Global Parameter values and logging JSONRPC requests over UDP in Kamailio. I understand that everyone might be busy, but I would greatly appreciate any guidance or suggestions you can provide on these topics. To recap my questions: 1)Is there a way to print the Global Parameter values, such as debug, children, flags, etc., within the Kamailio configuration file, to ensure they have been changed? 2°How can I log in Kamailio that it has received a JSONRPC request over UDP? I have been successful in logging this information when using HTTP and JSONRPC but am unsure how to do it with UDP. Any input or advice would be truly valuable. Thank you in advance for your time and assistance. Best.

1 0

Issues/Vulnerabilities in OpenSipS that may affect Kamailio
by Dovid Bender 17 Mar '23

17 Mar '23

Hi All, OpenSipS just released an update to the audit that was done to OpenSips [1]. From my basic coding skills it seems like the changes that were done by the OpenSipS project were not implemented in Kamailio which means that Kamailio is potentially vulnerable? For example you can compare the changes made by OpenSips project here [2] and the Kamailio code here [3] I am not active much on the list so please don't roast me if I am completely wrong here. Regards, Dovid [1] http://lists.opensips.org/pipermail/users/2023-March/046849.html [2] https://github.com/OpenSIPS/opensips/commit/dd9141b6f67d7df4072f3430f628d4b… [3] https://github.com/kamailio/kamailio/blob/master/src/core/parser/digest/par…

4 4

RPC error: 500 - Failed to use table
by Volker Denneberg 17 Mar '23

17 Mar '23

Hi, what can be the reason why usrloc module sometimes can read from database, sometimes not? Normal operation looks ok, the location table is kept up to date. The problem seems to be related with RPC (kamcmd or jsonrpc). For example, kamcmd ul.dump # ok kamcmd ul.lookup location 6351*1 # ok kamcmd ul.db_users location # error: 500 - Failed to use table Error 500 correlates with syslog entry: ERROR: <core> [db.c:481]: db_use_table(): invalid connection parameter Who connects where? In my understanding usrloc via core to mysql. I suppose RPC calls do not fail if usrloc can operate on kamailio memory, does that make sense? If so, what usrloc parameter can I tweak to fix error 500 ? I don't find any usrloc parameter regarding db connection. (Opening another mysql session as user kamailio is no problem, so we re not running out of connections.) Thanks in advance! Volker [cid:fb71bb9b-ad4f-4110-824b-d6805406bf6a] Volker Denneberg Development Telefon: +49 241 980 986 41 Web: www.m3connect.de<https://mx.scientific.de/owa/redir.aspx?C=RW1TSCipXQC6K0Yw1m69CGqyTwJHXjiiN…> E-Mail: v.denneberg(a)m3connect.de<https://mx.scientific.de/owa/redir.aspx?C=BjBXIUrD2WCryLRZ2IrAAwEu0b0W0ciUY…> m3connect GmbH | Pascalstr.18 | 52076 Aachen | DE/Germany | Amtsgericht Aachen | HRB 8773 | USt.- ID: DE219 664 658 | Geschäftsführer/CEO: Emilio Dragas

2 1

Sync NONCE between registrars?
by Benoit Panizzon 16 Mar '23

16 Mar '23

Hi We have two registrars. Today I observed a CPE doing this: CPE REGISTER (no auth) => Registrar 1 => 407 Challenge NONCE A CPE REGISTER (auth to NONCE A => Registrar 2 => 407 Challenge NONCE B CPE REGISTER (auth to NONCE B => Registrar 1 => 407 Challenge NONCE A and so on. Time on both registrars is in sync (I tought NONCE was based on time) Is there a way to sync the NONCE so that both would accept authentication based on the same NONCE? 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

How to Print Global Parameter Values and Log JSONRPC Requests Received over UDP in Kamailio
by sadik.oualla.mohamed＠gmail.com 16 Mar '23

16 Mar '23

Dear everyone, I am wondering if there is a way to print the Global Parameter values such as debug, children, flags, etc. just to make sure that they have been changed. I am aware that I can use the `kamcmd cfg.get core debug` command to check the value of the debug parameter for example, but I am wondering if there is a way to do this in the configuration file of Kamailio. Additionally, I would like to know if there is a way to print in the log of Kamailio that it received a JSONRPC request over UDP. I have been able to print some logs when using HTTP and JSONRPC to know that the server has received a JSONRPC request, but I am unsure how to do this when using UDP. I would greatly appreciate it if someone could provide some guidance. Thank you in advance for your time and assistance. Best regards.

1 0

Increment in number of "200" responses while calling procedures over jsonrpc with http
by sadik.oualla.mohamed＠gmail.com 16 Mar '23

16 Mar '23

Hello, Thank you very much! I've used your suggestion to accomplish some amazing things. However, I'm having an issue when calling the procedures over jsonrpc with http. I've noticed that the number of "200" responses gets incremented by 2, which is not the case when using the `*kamcmd*` tool. I suspect that this may be due to jsonrpc using *http/https*, which iscausing Kamailio to treat it as a "200" http responses code as "200" SIP codes. Could you advise on how to avoid this issue? Is there any further configuration that needs to be done? Best regards.

3 8

Kamailio store call statistics
by georgy.grigoryev＠snapcom.fr 16 Mar '23

16 Mar '23

Hello everyone, I'm trying to store the call statistics in my Kamailio server. I'm using SQLite just to understand what type of information i can store. I'm using the dialog module with the classic parameters: enable_stats => 1 dlg_flag => 4 hash_size => 4096 db_url => sqlite:///usr/local/etc/kamailio/kamailio.sqlite db_mode => 1 I'm able to open the DB but everything is empty, am i using the wrong modules? or i didn't configure the server well? The goal is to store CALL CDR in the DB, so that i can see who called & how many times etc

2 1

webrtc audio issue
by Arun K R 15 Mar '23

15 Mar '23

Hello, I have installed Kamailio 5.6 in debian 11 and RTPengine 11.3 also in the same server. I have configured kamailio to work as webrtc server and it forwards the registration to asterisk. Now when I am trying call from jssip webrtc client it reaches kamailio and route it through private interface to asterisk server. Asterisk then route it to the provider server. When i make a call asterisk server recives rtp from the provider and convert the rtp to srtp and sending back to kamailio. but there is no sound for webrtc from public internet . Also i am getting warning (SRTCP /RTP output wanted, but no crypto suite was negotiated) webrtc from Local network works fine with VPN For normal udp call without webrtc works fine. Kamailio having two interfaces, interface1 is private 10.13.1.140 and interface 2 is publi ip 100.x.x.x webrtc client sends calls to the public ip interface 100.x.x.x and kamaiio routes the call to the asterisk via private interface 10.13.1.140. asterisk server sends the call to remote server and gets the rtp back from that Asterisk server ---converts RTP to SRTP and forward to ----> kamailio 10.13.1.140 but there is nothing happens after that, please help me on this i am new to kamailio and rtpengine. The issue is only for webrtc from public internet. But when using webrtc from LAN works fine below are the logs Mar 9 20:21:02 debian /usr/local/sbin/kamailio[11778]: INFO: <script>: from domain recived is 10.13.1.152 Mar 9 20:21:02 debian /usr/local/sbin/kamailio[11778]: INFO: <script>: 09496381412 has fromDomain recived is 10.13.1.152 Mar 9 20:21:02 debian /usr/local/sbin/kamailio[11778]: INFO: <script>: Request going to srtp customied arun Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [control] Adding a proxy for control ng stats:127.0.0.1 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Received command 'offer' from 127.0.0.1:53374 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Dump for 'offer' from 127.0.0.1:53374: { "supports": [ "load limit" ], "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 7377619262916888262 2 IN IP4 127.0.0.1 Mar 9 20:21:02 debian rtpengine[11823]: s=- Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=group:BUNDLE 0 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap-allow-mixed Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic: WMS mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB Mar 9 20:21:02 debian rtpengine[11823]: m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126 Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 0.0.0.0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp:9 IN IP4 0.0.0.0 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:NM2h Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:BF2WmB5sOZZWVIFppZ3YTiSH Mar 9 20:21:02 debian rtpengine[11823]: a=ice-options:trickle Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:sha-256 9F:FA:18:B0:8D:17:A5:14:FE:22:BA:1E:73:1E:3E:02:6F:17:EC:B5:FC:77:BD:E1:0B:51:DF:7F:61:B0:2F:55 Mar 9 20:21:02 debian rtpengine[11823]: a=setup:actpass Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=msid:mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB 6f36294e-5d92-4f0c-8ea2-ba415d0ec125 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:111 transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:111 minptime=10;useinbandfec=1 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:63 red/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:63 111/111 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:9 G722/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:0 PCMU/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:8 PCMA/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:13 CN/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:110 telephone-event/48000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=ssrc:2480159127 cname:FJAL1TGxCcnDMPXY Mar 9 20:21:02 debian rtpengine[11823]: a=ssrc:2480159127 msid:mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB 6f36294e-5d92-4f0c-8ea2-ba415d0ec125 Mar 9 20:21:02 debian rtpengine[11823]: ", "call-id": "ui7jc53b9lfbt9lf4nu7", "received-from": [ "IP4", "223.190.206.123" ], "from-tag": "7n38ig1acl", "command": "offer" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Using default bitrate of 32000 bps for 2-channel Opus Mar 9 20:21:02 debian rtpengine[11823]: NOTICE: [ui7jc53b9lfbt9lf4nu7]: [core] Creating new call Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Subscribing '7n38ig1acl' to '' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Subscribing '' to '7n38ig1acl' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating codecs for offerer 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec G722/8000 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec PCMU/8000 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec PCMA/8000 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec CN/8000 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/48000 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating codecs for answerer #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec G722/8000 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec PCMU/8000 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec PCMA/8000 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec CN/8000 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/48000 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for #1 <https://github.com/sipwise/rtpengine/issues/1> -> 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF 110, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] No codec support for red/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for red/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec G722/8000/1 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for G722/8000 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for G722/8000 is G722/8000/1 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec G722/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for G722/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec PCMU/8000/1 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for PCMU/8000 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for PCMU/8000 is PCMU/8000/1 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec PCMU/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for PCMU/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec PCMA/8000/1 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for PCMA/8000 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for PCMA/8000 is PCMA/8000/1 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec PCMA/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for PCMA/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec CN/8000/1 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for CN/8000 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for CN/8000 is CN/8000/1 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec CN/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for CN/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/48000/1 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for telephone-event/48000 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/48000 is telephone-event/48000/1 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/48000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/48000 with DTMF 110, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for #1 <https://github.com/sipwise/rtpengine/issues/1> -> 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF 110, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] No codec support for red/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for red/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec G722/8000/1 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for G722/8000 is G722/8000/1 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec G722/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for G722/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec PCMU/8000/1 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for PCMU/8000 is PCMU/8000/1 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec PCMU/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for PCMU/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec PCMA/8000/1 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for PCMA/8000 is PCMA/8000/1 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec PCMA/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for PCMA/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec CN/8000/1 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for CN/8000 is CN/8000/1 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec CN/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for CN/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/48000/1 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/48000 is telephone-event/48000/1 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/48000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/48000 with DTMF 110, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] set FILLED flag for stream, local 10.13.1.127:30020 remote 0.0.0.0:9 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] Creating active DTLS connection context Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] Creating active DTLS connection context Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] set FILLED flag for stream, local 10.13.1.127:30021 remote 0.0.0.0:9 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [10.13.1.127:30000] Initialized incoming SRTP with SDES crypto params: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [1] Initialized outgoing SRTP with SDES crypto params: suite AEAD_AES_256_GCM, tag 1, key czR43Q05Tlky5pj/m6BomEKXh+b5okz/iSUDQqgvHDI= salt Vov9BA7SKter2Ajj Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] Creating passive DTLS connection context Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] Creating passive DTLS connection context Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [10.13.1.127:30001] Initialized incoming SRTP with SDES crypto params: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [2] Initialized outgoing SRTP with SDES crypto params: suite AEAD_AES_256_GCM, tag 1, key czR43Q05Tlky5pj/m6BomEKXh+b5okz/iSUDQqgvHDI= salt Vov9BA7SKter2Ajj Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Replying to 'offer' from 127.0.0.1:53374 (elapsed time 0.022450 sec) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Response dump for 'offer' to 127.0.0.1:53374: { "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 7377619262916888262 2 IN IP4 127.0.0.1 Mar 9 20:21:02 debian rtpengine[11823]: s=- Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap-allow-mixed Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic: WMS mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB Mar 9 20:21:02 debian rtpengine[11823]: m=audio 30000 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126 Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid Mar 9 20:21:02 debian rtpengine[11823]: a=msid:mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB 6f36294e-5d92-4f0c-8ea2-ba415d0ec125 Mar 9 20:21:02 debian rtpengine[11823]: a=ssrc:2480159127 cname:FJAL1TGxCcnDMPXY Mar 9 20:21:02 debian rtpengine[11823]: a=ssrc:2480159127 msid:mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB 6f36294e-5d92-4f0c-8ea2-ba415d0ec125 Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:111 minptime=10;useinbandfec=1 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:111 transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:63 red/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:63 111/111 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:9 G722/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:0 PCMU/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:8 PCMA/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:13 CN/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:110 telephone-event/48000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp:30001 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:1 AEAD_AES_256_GCM inline:czR43Q05Tlky5pj/m6BomEKXh+b5okz/iSUDQqgvHDJWi/0EDtIq16vYCOM Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:2 AEAD_AES_128_GCM inline:5abyoU5PKLg1lNfmLg1aBLIqyNAgmKNEEo8J1w Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:i4O28fJjCyvBVQmwjCb7dySy5K20yeg5n1ky+uhPNSpbqkv8vxkcIaerkO9Gbg Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:OOydiBrJ9nMu23yaBP7JuYNddpbXX8sN/V9Ab/psnTZIBRZKXenHWVPvJSM9Fw Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:5 AES_192_CM_HMAC_SHA1_80 inline:UtkHFdpsaZSO0nwvmEotIoGN+paLt3LHt7yMG4MfDv5rueBsb80 Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:6 AES_192_CM_HMAC_SHA1_32 inline:hgFJ9vS9Roz1vAMhnrCyviKC/TwCPgrk5jeKbxHlIEKtqSvLdK4 Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:07Q9Z/8DguM0HJgDHv5HF3YDWHdp23hbz+TepHa8 Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:djpscuSL/05sVtFNocQpHmr1x+NTcLXKu8ePb0q+ Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:9 F8_128_HMAC_SHA1_80 inline:5FqC2VY+q3vqaju3JwroIJO/OlCM1i6TNRE/3Atj Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:10 F8_128_HMAC_SHA1_32 inline:kUfTs7OFD6ltRNpDi1dSG5ZjuQAFDeEQD5IvOwme Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:11 NULL_HMAC_SHA1_80 inline:JZ2ruS0914NL4mmS7jxg+ngz0IQaE6FBRlet8abd Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:12 NULL_HMAC_SHA1_32 inline:h21D+oGRkr1dDEoMm1+vEKmKsn+4GxNBwgIew2qA Mar 9 20:21:02 debian rtpengine[11823]: a=setup:actpass Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:sha-256 0C:67:09:6B:AE:6B:30:09:81:C5:9C:65:C6:EC:9E:CE:C2:6E:E2:EA:67:B4:B5:B3:40:C4:F1:0C:3E:05:96:79 Mar 9 20:21:02 debian rtpengine[11823]: a=tls-id:8100c85eb1c58be3580e8acd7f097000 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:hcqW22Sc Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:QjHJKT4qNsfZm80zrcyh8SfI76 Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:GtpEjl9r4IzNpiXr 1 UDP 2130706431 10.13.1.127 30000 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:GtpEjl9r4IzNpiXr 2 UDP 2130706430 10.13.1.127 30001 typ host Mar 9 20:21:02 debian rtpengine[11823]: ", "result": "ok" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7//1 port 30000]: [ice] Created candidate pair GtpEjl9r4IzNpiXr:6b1875839eb037b0:1 between 10.13.1.127 and 10.13.1.152:14450, type prflx Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7//1 port 30000]: [ice] Triggering check for GtpEjl9r4IzNpiXr:6b1875839eb037b0:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7//1 port 30000]: [core] Successful STUN binding request from 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Received command 'answer' from 127.0.0.1:60024 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Dump for 'answer' from 127.0.0.1:60024: { "supports": [ "load limit" ], "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 2654832326 4 IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: s=Asterisk Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic:WMS * Mar 9 20:21:02 debian rtpengine[11823]: m=audio 14450 UDP/TLS/RTP/SAVPF 111 126 Mar 9 20:21:02 debian rtpengine[11823]: a=connection:new Mar 9 20:21:02 debian rtpengine[11823]: a=setup:active Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:SHA-256 62:AD:7E:86:4D:FF:87:6B:44:5A:F0:62:A2:37:D6:56:5C:D4:F4:A8:03:88:A6:E1:DD:2A:15:69:75:1B:04:3C Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:7706bb5e0317151b5749cc8550354244 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:4af879c44cb99216424536fa5defd9d5 Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:Ha0d0198 1 UDP 2130706431 10.13.1.152 14450 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:H6719a439 1 UDP 2130706431 103.25.164.57 14450 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:126 0-16 Mar 9 20:21:02 debian rtpengine[11823]: a=ptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=maxptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=msid:d5be09fd-dce5-4d96-879e-f34f22f54ef1 a3f22c04-6988-4464-a458-5abc099e7bc0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:* transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: ", "call-id": "ui7jc53b9lfbt9lf4nu7", "received-from": [ "IP4", "10.13.1.152" ], "from-tag": "7n38ig1acl", "to-tag": "a5935482-3f00-4dd0-b98c-0b4726da777d", "command": "answer" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Using default bitrate of 32000 bps for 2-channel Opus Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unconfirming peer address for local 10.13.1.127:30000 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unconfirming peer address for local 10.13.1.127:30020 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unconfirming peer address for local 10.13.1.127:30001 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unconfirming peer address for local 10.13.1.127:30021 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unsubscribing '7n38ig1acl' from 'a5935482-3f00-4dd0-b98c-0b4726da777d' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unsubscribing 'a5935482-3f00-4dd0-b98c-0b4726da777d' from '7n38ig1acl' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Subscribing 'a5935482-3f00-4dd0-b98c-0b4726da777d' to '7n38ig1acl' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Subscribing '7n38ig1acl' to 'a5935482-3f00-4dd0-b98c-0b4726da777d' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating codecs for answerer a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> -> 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Codec answer for a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Reverse codec for opus/48000/2 (111) is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Reverse codec for telephone-event/8000 (126) is telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] telephone-event/8000/1 payload type 126 already present, skip Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> -> a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> -> a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> -> 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] set FILLED flag for stream, local 10.13.1.127:30000 remote 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] set FILLED flag for stream, local 10.13.1.127:30001 remote 10.13.1.152:14451 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [10.13.1.127:30001] Initialized incoming SRTP with SDES crypto params: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [2] Initialized outgoing SRTP with SDES crypto params: suite AEAD_AES_256_GCM, tag 1, key czR43Q05Tlky5pj/m6BomEKXh+b5okz/iSUDQqgvHDI= salt Vov9BA7SKter2Ajj Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Replacing previously learned prflx ICE candidate with Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Learning new ICE candidate H6719a439:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Created candidate pair GtpEjl9r4IzNpiXr:H6719a439:1 between 10.13.1.127 and 103.25.164.57:14450, type host Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Recalculating all ICE pair priorities Mar 9 20:21:02 debian rtpengine[11823]: WARNING: [ui7jc53b9lfbt9lf4nu7]: [ice] Priority collision between candidate pairs GtpEjl9r4IzNpiXr:H6719a439:1 and GtpEjl9r4IzNpiXr:Ha0d0198:1 - ICE will likely fail Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Sending ICE/STUN request for candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 from 10.13.1.127 to 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Shutting down ICE agent (nothing to do) Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Replying to 'answer' from 127.0.0.1:60024 (elapsed time 0.003226 sec) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Response dump for 'answer' to 127.0.0.1:60024: { "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 2654832326 4 IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: s=Asterisk Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic:WMS * Mar 9 20:21:02 debian rtpengine[11823]: m=audio 30020 UDP/TLS/RTP/SAVPF 111 126 Mar 9 20:21:02 debian rtpengine[11823]: a=connection:new Mar 9 20:21:02 debian rtpengine[11823]: a=maxptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=msid:d5be09fd-dce5-4d96-879e-f34f22f54ef1 a3f22c04-6988-4464-a458-5abc099e7bc0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:* transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:126 0-16 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp:30020 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=setup:active Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:sha-256 0C:67:09:6B:AE:6B:30:09:81:C5:9C:65:C6:EC:9E:CE:C2:6E:E2:EA:67:B4:B5:B3:40:C4:F1:0C:3E:05:96:79 Mar 9 20:21:02 debian rtpengine[11823]: a=tls-id:ac2907348568344c9743f21fa1383e08 Mar 9 20:21:02 debian rtpengine[11823]: a=ptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:4xVkmu6h Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:kc54UEYL25S4UjgSjVKJdcEiAR Mar 9 20:21:02 debian rtpengine[11823]: a=ice-options:trickle Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:GtpEjl9r4IzNpiXr 1 UDP 2130706431 10.13.1.127 30020 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=end-of-candidates Mar 9 20:21:02 debian rtpengine[11823]: ", "result": "ok" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Processing incoming DTLS packet Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Sending DTLS packet Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Received ICE/STUN response code 0 for candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 from 10.13.1.152:14450 to 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Setting ICE candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 as succeeded Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Best succeeded ICE pair with all components is GtpEjl9r4IzNpiXr:Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE not completed yet, but can use pair GtpEjl9r4IzNpiXr:Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE negotiated: peer for component 1 is 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE negotiated: local interface 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Processing incoming DTLS packet Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [crypto] DTLS: Peer certificate accepted Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [crypto] DTLS handshake successful Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [crypto] DTLS-SRTP successfully negotiated using AES_CM_128_HMAC_SHA1_80 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] SRTP keys, incoming: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] --- AES_CM_128_HMAC_SHA1_80 key AtAWESyBg5e6Ub3EPRQ5ag== salt rgwpYXp6KpHCmfjMxVA= Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] SRTP keys, outgoing: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] --- AES_CM_128_HMAC_SHA1_80 key 8+zHcQ5a1Bv5L0dv2AfKyg== salt 7YaPNc68d5ALtKKIOCQ= Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [crypto] DTLS-SRTP successfully negotiated using AES_CM_128_HMAC_SHA1_80 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] SRTP keys, incoming: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] --- AES_CM_128_HMAC_SHA1_80 key AtAWESyBg5e6Ub3EPRQ5ag== salt rgwpYXp6KpHCmfjMxVA= Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] SRTP keys, outgoing: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] --- AES_CM_128_HMAC_SHA1_80 key 8+zHcQ5a1Bv5L0dv2AfKyg== salt 7YaPNc68d5ALtKKIOCQ= Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Sending DTLS packet Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Successful STUN binding request from 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1]: [ice] Start nominating ICE pairs Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1]: [ice] Nominating ICE pair GtpEjl9r4IzNpiXr:Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1]: [ice] Sending nominating ICE/STUN request for candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 from 10.13.1.127 to 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Received ICE/STUN response code 0 for candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 from 10.13.1.152:14450 to 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Setting nominated ICE candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 as valid Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE completed, using pair GtpEjl9r4IzNpiXr:Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE negotiated: peer for component 1 is 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE negotiated: local interface 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Received command 'answer' from 127.0.0.1:60024 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Dump for 'answer' from 127.0.0.1:60024: { "supports": [ "load limit" ], "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 2654832326 4 IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: s=Asterisk Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic:WMS * Mar 9 20:21:02 debian rtpengine[11823]: m=audio 14450 UDP/TLS/RTP/SAVPF 111 126 Mar 9 20:21:02 debian rtpengine[11823]: a=connection:new Mar 9 20:21:02 debian rtpengine[11823]: a=setup:active Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:SHA-256 62:AD:7E:86:4D:FF:87:6B:44:5A:F0:62:A2:37:D6:56:5C:D4:F4:A8:03:88:A6:E1:DD:2A:15:69:75:1B:04:3C Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:7706bb5e0317151b5749cc8550354244 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:4af879c44cb99216424536fa5defd9d5 Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:Ha0d0198 1 UDP 2130706431 10.13.1.152 14450 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:H6719a439 1 UDP 2130706431 103.25.164.57 14450 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:126 0-16 Mar 9 20:21:02 debian rtpengine[11823]: a=ptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=maxptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=msid:d5be09fd-dce5-4d96-879e-f34f22f54ef1 a3f22c04-6988-4464-a458-5abc099e7bc0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:* transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: ", "call-id": "ui7jc53b9lfbt9lf4nu7", "received-from": [ "IP4", "10.13.1.152" ], "from-tag": "7n38ig1acl", "to-tag": "a5935482-3f00-4dd0-b98c-0b4726da777d", "command": "answer" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Using default bitrate of 32000 bps for 2-channel Opus Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating codecs for answerer a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> -> 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Codec answer for a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Reverse codec for opus/48000/2 (111) is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Reverse codec for telephone-event/8000 (126) is telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] telephone-event/8000/1 payload type 126 already present, skip Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> -> a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> -> a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for a5935482-3f00-4dd0-b98c-0b4726da777d #1 <https://github.com/sipwise/rtpengine/issues/1> -> 7n38ig1acl #1 <https://github.com/sipwise/rtpengine/issues/1> Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Dropping new ICE candidate Ha0d0198 in favour of Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Dropping new ICE candidate H6719a439 in favour of H6719a439:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Shutting down ICE agent (nothing to do) Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Replying to 'answer' from 127.0.0.1:60024 (elapsed time 0.002244 sec) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Response dump for 'answer' to 127.0.0.1:60024: { "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 2654832326 4 IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: s=Asterisk Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic:WMS * Mar 9 20:21:02 debian rtpengine[11823]: m=audio 30020 UDP/TLS/RTP/SAVPF 111 126 Mar 9 20:21:02 debian rtpengine[11823]: a=connection:new Mar 9 20:21:02 debian rtpengine[11823]: a=maxptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=msid:d5be09fd-dce5-4d96-879e-f34f22f54ef1 a3f22c04-6988-4464-a458-5abc099e7bc0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:* transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:126 0-16 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp:30020 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=setup:active Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:sha-256 0C:67:09:6B:AE:6B:30:09:81:C5:9C:65:C6:EC:9E:CE:C2:6E:E2:EA:67:B4:B5:B3:40:C4:F1:0C:3E:05:96:79 Mar 9 20:21:02 debian rtpengine[11823]: a=tls-id:ac2907348568344c9743f21fa1383e08 Mar 9 20:21:02 debian rtpengine[11823]: a=ptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:4xVkmu6h Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:kc54UEYL25S4UjgSjVKJdcEiAR Mar 9 20:21:02 debian rtpengine[11823]: a=ice-options:trickle Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:GtpEjl9r4IzNpiXr 1 UDP 2130706431 10.13.1.127 30020 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=end-of-candidates Mar 9 20:21:02 debian rtpengine[11823]: ", "result": "ok" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] New ingress SSRC for: 10.13.1.152:14450 SSRC: 46ca8abf Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected: 10.13.1.152:14450) -> local 10.13.1.127:30000 (RTP seq 31783 TS 528 SSRC 46ca8abf) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Generated session key: master key f3ecc771..., master salt ed868f35..., label 00, length 16, result 6806f5cc... Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Generated session key: master key f3ecc771..., master salt ed868f35..., label 01, length 20, result 044b0cce... Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Generated session key: master key f3ecc771..., master salt ed868f35..., label 02, length 14, result 4426c95d... Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] New egress (direct) SSRC for: 0.0.0.0:9 SSRC: 46ca8abf Mar 9 20:21:02 debian rtpengine[11823]: ERR: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] SRTP output wanted, but no crypto suite was negotiated Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Error when sending message. Error: Inappropriate ioctl for device Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected: 10.13.1.152:14450) -> local 10.13.1.127:30000 (RTP seq 31784 TS 1488 SSRC 46ca8abf) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected: 10.13.1.152:14450) -> local 10.13.1.127:30000 (RTP seq 31785 TS 2448 SSRC 46ca8abf) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected: 10.13.1.152:14450) -> local 10.13.1.127:30000 (RTP seq 31786 TS 3408 SSRC 46ca8abf) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected:

2 1

Dispatcher behavior
by Jawaid Bazyar 15 Mar '23

15 Mar '23

Hi, is this expected behavior? I have two target hosts in a dispatcher set, 10.20.20.118 (prio 5) and 10.20.20.252 (prio 10). When I have 10.20.20.252 turned off, dispatcher still tries to send packets to that host, even when the status flags are IP. root@vs-rs01:/etc/kamailio# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:10.20.20.252:5060 FLAGS: IP PRIORITY: 10 LATENCY: { AVG: 0.000000 STD: 0.000000 EST: 0.000000 MAX: 0 TIMEOUT: 62 } } DEST: { URI: sip:10.20.20.118:5060 FLAGS: AP PRIORITY: 5 LATENCY: { AVG: 3.876000 STD: 2.965000 EST: 5.058000 MAX: 14 TIMEOUT: 0 } } } } } }

5 14

Error on transfer when calling from WebRTC with TOPOH
by Arsenijs Kabihno 15 Mar '23

15 Mar '23

Hello, We have an issue which appears when TOPOH module is enabled, call is made from WebRTC, then transferred by calee: Mar 15 11:55:27 ap07stvp.xxxxxxx.xxx docker[2062]: 29(35) INFO: {2 2 INVITE g2rgvnioadg8m7l6i7k6} <script>: RTPENGINE branch_id:0 ruri: <null>, method:INVITE, status:200, extra_id: z9hG4bK66807520, rtpengine_answer: replace-origin replace-session-connection SIP-source-address direction=priv1 direction=pub1 SIP-source-address via-branch=extra rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF Mar 15 11:55:27 ap07stvp.xxxxxxx.xxx docker[2062]: 29(35) NOTICE: {2 2 INVITE g2rgvnioadg8m7l6i7k6} acc [acc.c:287]: acc_log_request(): ACC: transaction answered: timestamp=1678881327;method=INVITE;from_tag=p9qqi7hrua;to_tag=ea7d2850-3e76-4c11-821c-a0d1e3cbb011;call_id=g2rgvnioadg8m7l6i7k6;code=200;reason=OK;src_user=92010;src_domain=10.181.0.1;src_ip=10.5.0.145;dst_ouser=27221;dst_user=27221;dst_domain=10.181.0.1 Mar 15 11:55:38 ap07stvp.xxxxxxx.xxx docker[2062]: 31(37) INFO: {1 27689 BYE e034a187-0e4d-4c4e-ab4b-f2e5f1281330} <script>: RTPENGINE branch_id:0 ruri: sip:97093@10.128.150.67:46058;rinstance=d403efb922420649;transport=UDP, method:BYE, status:<null>, extra_id: <null>, rtpengine_delete Mar 15 11:55:38 ap07stvp.xxxxxxx.xxx docker[2062]: 28(34) NOTICE: {2 27689 BYE e034a187-0e4d-4c4e-ab4b-f2e5f1281330} acc [acc.c:287]: acc_log_request(): ACC: transaction answered: timestamp=1678881338;method=BYE;from_tag=0c29be45-6aff-4d4e-8503-650893a5a5ac;to_tag=b1a8a401;call_id=e034a187-0e4d-4c4e-ab4b-f2e5f1281330;code=200;reason=OK;src_user=22628;src_domain=10.5.2.192;src_ip=10.5.2.192;dst_ouser=97093;dst_user=97093;dst_domain=10.128.150.67 Mar 15 11:55:39 ap07stvp.xxxxxxx.net docker[2062]: 32(38) INFO: {1 27798 INVITE g2rgvnioadg8m7l6i7k6} <script>: RTPENGINE branch_id:0 ruri: sip:jgqtuev6@2idi5cucan2v.invalid;transport=ws;ob, method:INVITE, status:<null>, extra_id: <null>, rtpengine_offer: replace-origin replace-session-connection SIP-source-address direction=priv1 direction=pub1 SIP-source-address direction=priv1 direction=pub1 rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 27(33) INFO: {1 4728 INVITE 133ccd4c-031b-4d10-b073-745f35433132} <script>: RTPENGINE branch_id:0 ruri: sip:0037126048570@193.138.189.220, method:INVITE, status:<null>, extra_id: z9hG4bKPjedcf2d96-01cd-43fd-bed0-4e601e3e542f0, rtpengine_offer: replace-origin replace-session-connection SIP-source-address direction=priv1 direction=pub1 via-branch=extra Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 50(56) INFO: {2 27798 INVITE g2rgvnioadg8m7l6i7k6} <script>: RTPENGINE branch_id:0 ruri: <null>, method:INVITE, status:200, extra_id: z9hG4bKPj1cd87bda-7862-4ca9-8475-ac6b342c45ef0, rtpengine_answer: replace-origin replace-session-connection SIP-source-address direction=pub1 direction=priv1 SIP-source-address via-branch=extra rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 25(31) ERROR: {1 27798 ACK g2rgvnioadg8m7l6i7k6} <core> [core/resolve.c:1730]: sip_hostport2su(): could not resolve hostname: "2idi5cucan2v.invalid" Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 25(31) ERROR: {1 27798 ACK g2rgvnioadg8m7l6i7k6} <core> [core/forward.c:516]: forward_request(): bad host name 2idi5cucan2v.invalid, dropping packet Mar 15 11:55:39 ap07stvp.xxxxxxx.xxx docker[2062]: 25(31) ERROR: {1 27798 ACK g2rgvnioadg8m7l6i7k6} sl [sl_funcs.c:418]: sl_reply_error(): stateless error reply used: Unresolvable destination (478/SL) We have the following setup: WebRTC client behind load-balanser -> kamailio -> asterisk. When call is transferred, asterisk makes re-invite. If TOPOH is disabled, it happens this way and issue is not present: asterisk INVITE -> kamailio -> WebRTC WebRTC 200 -> kamailio -> asterisk asterisk ACK -> kamailio -> WebRTC ACK example: 03/09/2023 09:35:48.126 +02:00: 10.5.2.192:5060 -> 10.181.0.1:5060 ACK sip:98dn3met@0j62ln34srjn.invalid;transport=ws;ob;alias=10.5.0.145~27562~6 SIP/2.0 Via: SIP/2.0/UDP 10.5.2.192:5060;rport;branch=z9hG4bKPj1d11dae2-10bf-466e-9221-5710f801d725 From: <sip:27221@10.181.0.1>;tag=b6b73135-efe1-4d86-bbc8-bf4313130eb5 To: <sip:92010@10.181.0.1>;tag=namgu127j9 Call-ID: t0hmmk50h5i4ok88asjj CSeq: 28632 ACK Route: <sip:10.181.0.1:5060;lr;r2=on;ftag=namgu127j9;did=aaa.7b92;rtp=bridge;rtp=ws> Route: <sip:10.181.0.1:4444;transport=ws;lr;r2=on;ftag=namgu127j9;did=aaa.7b92;rtp=bridge;rtp=ws> Max-Forwards: 70 User-Agent: Asterisk PBX 18.16.0 Content-Length: 0 If TOPOH is enabled, kamailio doesn't pass this ACK to WebRTC: asterisk INVITE -> kamailio -> WebRTC WebRTC 200 -> kamailio -> asterisk asterisk ACK -> kamailio -> -> -> ACK example: 03/09/2023 09:33:03.544 +02:00: 10.5.2.192:5060 -> 10.181.0.1:5060 ACK sip:10.0.0.1;line=Bn7Ipzh8eb8DxMSFyk.rWzitxzVFBoirxRG5xYeOxb7hpoXTlMGDBbuTCk3oBDAqlH** SIP/2.0 Via: SIP/2.0/UDP 10.5.2.192:5060;rport;branch=z9hG4bKPjf00fc541-f011-4e52-b63a-2c569478ca39 From: <sip:27221@10.181.0.1>;tag=7d402872-7355-4269-b912-e52ee28ed415 To: <sip:92010@10.181.0.1>;tag=t0q4g9am9g Call-ID: t0hmmetickvlvn5k7nco CSeq: 25565 ACK Route: <sip:10.181.0.1:5060;lr;r2=on;ftag=t0q4g9am9g;did=4c8.a182;rtp=bridge;rtp=ws> Route: <sip:10.0.0.1;line=Bn7IpzdIwzd8Vf8Iwzd9WkyFWkAFBELJBo.qBYyuCoVgBz1uxn8gx61uxn8geYXOeD3FV6dFeD7Oxj7YpnX5ekFFlDHJljd8VzATC60ulYi5ebC7poiFBk3oBI**> Max-Forwards: 70 User-Agent: Asterisk PBX 18.16.0 Content-Length: 0 We have an assumption that issue might be related to the way how TOPOH handles alias in contact. Did someone have encountered something like this?

1 0

Advertise NAT IP address causing Multiple SIP INVITEs is that expected ?
by Adil Mafzool Zaka 15 Mar '23

15 Mar '23

Hi I am using advertise in the listen interface for our NATed setup within AWS. Using following listen statement in kamailio: - version: kamailio 5.5.1 listen=udp:10.0.1.4:5060 advertise 3X.1XX.1XX.2XX:5060 dispatcher.list 1 sip:10.0.4.23:5060 8 10 weight=11 #FreeSwitch 1 We are seeing that kamailio (10.0.1.4) is sending two SIP INVITEs via dispatcher to FreeSwitch at 10.0.4.23 which seems strange or is it expected behaviour? (As seen below) SIP INVITE Request: - WAN Address >> Kamailio AWS NATed address >> FreeSwitch 1 1X.2X.2X.2X >> 3X.1XX.1XX.2XX 10.0.1.4 >> 10.0.4.23 10.0.1.4 >> 10.0.4.23 Many thanks Regards Muhammad Zaka

2 1

Use Kamailio and RTPEngine to play wav file as early media to announce a server maintenance
by jhayhoe＠liquidweb.com 15 Mar '23

15 Mar '23

I am looking to configure Kamailio and RTPEngine to play a wav file for any new calls during a scheduled asterisk server maintenance. I have set up the following within route{} to send the call to a early_media route based on a variable that I can set on the server using kamcmd. route { ... if ($sht(config=>maint)=="1") { if (is_method("INVITE") && !has_totag()) { xlog ("L_INFO","Ongoing maintenance. Call-ID:$ci | Method: $rm"); route(early_media); } } ... } route[early_media] { xlog("Maintenance: handling early_media\n"); rtpengine_manage("direction=external direction=external"); $var(body) = $(rb{re.subst,/(IP4.).*/\1##server IP redacted##/g}); set_reply_body($var(body), "application/sdp"); t_send_reply("183", "Session Progress"); sleep(2); unblock_dtmf("all"); play_media("file=/etc/kamailio/media/maintenance.wav"); sleep(21); rtpengine_delete(); t_reply("480","Temporarily Unavailable"); } This mostly works as I hear the recorded message in place of the ringing tone when a call is processed by kamailio and then a busy signal is heard as part of the 480 reply at the end. The sleep's are in place to match the duration of the recorded message as otherwise the 480 is sent immediately following the start of the play_media. Feel free to let me know if there is a better solution to wait the duration of the media file and then proceed with processing instead of using sleep(). Is there a way to instead send a CANCEL or a BYE instead of a 480 after the wav file is played? I tried using t_cancel_callid("$ci", "$cs", "0") as well as a dlg_bye("all") at the end of the early_media route and neither seemed to send any headers out.

3 3

stuck with webrtc on kamailio
by Arun K R 14 Mar '23

14 Mar '23

hello, I have issue of no voice on kamailio configured for webrtc. I have configured rtpengine with public and private interface. My kamilio has two interface of pubic and private ip. Somebody has suggested me that there is no ice trickling happens. I am using jssip webrtc client. Kindly suggest me or help me with this. I have send another email for same issue to this group and didnt get any reply. Kindly help me

1 0

Re: Your message to sr-users@lists.kamailio.org awaits moderator approval
by Arun K R 14 Mar '23

14 Mar '23

I need a help on issue with rtpengine configuration and I didn't get any repy for it. Kindly check about it and help me. If i won't get any help kindly let me know, so I can stop waiting for your reply On Mon, Mar 13, 2023 at 12:50 PM <sr-users-bounces(a)lists.kamailio.org> wrote: > Your mail to 'sr-users(a)lists.kamailio.org' with the subject > > webrtc audio issue > > Is being held until the list moderator can review it for approval. > > The message is being held because: > > The message is larger than the 150 KB maximum size > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. >

1 0

send messages from source ip in Linux anyIP list
by mohsen khashei 14 Mar '23

14 Mar '23

1 0

Dispatcher Incoming
by nutxase 14 Mar '23

14 Mar '23

Hi All I have setup kamailio using dispatcher to proxy registrations from the UAC to asterisk but when asterisk sends an incoming call it does not seem to keep the path header and therefore kamailio sends 404 is there anyway around this? Thanks Sent with [Proton Mail](https://proton.me/) secure email.

5 18

Use MySQL connector instead of mariadb connector
by suchendra adiga 14 Mar '23

14 Mar '23

Hi, I have been working on setting up the database with the Kamailio server. But facing a problem when my db user has configured with SSL required. But I learnt that there is no support to enable the SSL in mariadb connector. So I am thinking of using the MySQL connector instead. Is there anyway I could configure the kamailio to use MySQL instead of Mariadb? Thanks and regards, Suchendra

2 7

Advertise NAT IP address causing Multiple SIP INVITEs is that expected ?
by Muhammad Zaka 13 Mar '23

13 Mar '23

Hi We are using advertise in the listen interface for our NATed setup within AWS. Using following listen statement in kamailio: - version: kamailio 5.5.1 listen=udp:10.0.1.4:5060 advertise 3X.1XX.1XX.2XX:5060 dispatcher.list 1 sip:10.0.4.23:5060 8 10 weight=11 #FreeSwitch 1 We are seeing that kamailio (10.0.1.4) is sending two SIP INVITEs via dispatcher to FreeSwitch at 10.0.4.23 which seems strange or is it expected behaviour? (As seen below) SIP INVITE Request: - WAN Address --> Kamailio AWS NATed address --> FreeSwitch 1 1X.2X.2X.2X --> 3X.1XX.1XX.2XX 10.0.1.4 --> 10.0.4.23 10.0.1.4 --> 10.0.4.23 [cid:image001.png@01D955CE.9F0C2EE0] Many Thanks Regards Muhammad Zaka Muhammad Zaka UCaaS Solutions Engineer Tel: 03330147908 Email: Muhammad.Zaka(a)gamma.co.uk This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster(a)gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at The Scalpel, 18th Floor, 52 Lime Street, London EC3M 7AF and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.

1 0

(no subject)
by gui 10 Mar '23

10 Mar '23

Hello I have an issue with Rx in my VolTE call Flow. Please refer to picture and pcap in annex. I am using same rtp engine at origination and termination. I am sending rtpmanage for invite and 183 session progress at both origination and termination. My issue is that Rx is not sending for the proper media flow component to PCRF. At origination it is considering a media flow between A 50034 and RTPEngine 49186 (instead of considering RTP Engine Port 49152) At Termination it is considering a media flow between B 50054 and RTPEngine 49132 (instead of considering RTP EnginePort 49170) Any idea why?

3 4

use_dns_failover and dispatcher
by Lars Jansson 10 Mar '23

10 Mar '23

Hi, I had the intention to route calls to some SRV destinations via dispatcher and to other SRV destinations via DNS lookup and 'use_dns_failover=on'. Currently in a route block using dispatcher two out of three targets within the SRV destination are unavailable (by intention). During my tests to the dispatcher destination I have found that: A) If I have 'use_dns_failover=on' this setting "overrules" the dispatcher routing and the unavailable targets are also tried before DNS failover finds the available target. B) If I have 'use_dns_failover=off' the dispatcher routing logic works as expected and the call is always routed to the only available target directly, making use of the result of the dispatcher OPTIONS pinging. -- So my conclusion is now that you have to choose: Either use dispatcher routing, or use DNS failover based routing. - I'm fine with this, but I just would like to know if my conclusion is correct, or if there is actually a way to use dispacther for some SRV destinations and DNS failover for other SRV destinations. Regards, Lars

1 0

New 'reverse' transaction not using correct transport protocol
by Benoit Panizzon 10 Mar '23

10 Mar '23

Hi CPE registering with TCP (or TLS). 2nd leg is UDP. Within one transaction (INVITE to OK including all ACK and PRACK) transport is kept as desired for both legs. But when the B side disconnects (sending BYE, new reverse transaction), this is sent via UDP to the A CPE which initially talked TCP and thus ignored. record_route() is called on each leg. What could I be missing? 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 ______________________________________________________

4 6

Silo extra_hdrs duplication
by Dr. Barabás Péter 10 Mar '23

10 Mar '23

Hi, I’m using kamailio’s silo module to store offline messages in it. I set extra_hdrs modparam to e.g. : ‘Resent-from-silo’ so the clients get information that the message has arrived directly (immediatelly) from the sender or it was stored offline and comes from silo. So the problem is the following: * if receiver’s socket is broken (e.g. airplane mode on mobile) and kamailio ‘thinks’ it is registered, server tries to send the message * message will be timed out and based on config it will be stored in silo. * the next step is to check if receiver is registered or not (since the client can re-register during 30sec until the message has timed out) * If client is registered, kamailio tries to send the message immediately with m_dump(). * If the receiver’s connection is still broken, the message will be timed out and store in silo. * In every store, a new ‘resent’ extra_hdrs value is appended. When extra_hdrs length reaches 1024 bytes, the m_dump will fail and it blocks the dumping of messages to the given receiver. Question: can extra_hdrs value be removed before store? Or what can be the solution not to duplicate the extra_hdrs value in some bad network situation? Peter

3 2

Re: [sr-dev] KEMI python 'KSR' has no attribute 'sanity'
by Henning Westerholt 10 Mar '23

10 Mar '23

(adding sr-users) Hello, maybe because you're spelling it wrong? Compare e.g., to here: https://kamailio.org/docs/tutorials/5.6.x/kamailio-kemi-framework/modules/#… Cheers, Henning -----Original Message----- From: agural5(a)gmail.com <agural5(a)gmail.com> Sent: Freitag, 10. März 2023 08:32 To: sr-dev(a)lists.kamailio.org Subject: [sr-dev] KEMI python 'KSR' has no attribute 'sanity' Hello, I am trying to use KEMI KSR.sanity in python but got error: AttributeError: module 'KSR' has no attribute 'sanity' appreciate your help for solve this. Thanks! _______________________________________________ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org

2 1

webrtc from public internet have no voice
by mail4arunkr＠gmail.com 10 Mar '23

10 Mar '23

Hello, I have installed Kamailio 5.6 in debian 11 and RTPengine 11.3 also in the same server. I have configured kamailio to work as webrtc server and it forwards the registration to asterisk. Now when I am trying call from jssip webrtc client it reaches kamailio and route it through private interface to asterisk server. Asterisk then route it to the provider server. When i make a call asterisk server recives rtp from the provider and convert the rtp to srtp and sending back to kamailio. but there is no sound for webrtc from public internet . Also i am getting warning (SRTCP /RTP output wanted, but no crypto suite was negotiated) webrtc from Local network works fine with VPN For normal udp call without webrtc works fine. Kamailio having two interfaces, interface1 is private 10.13.1.140 and interface 2 is publi ip 100.x.x.x webrtc client sends calls to the public ip interface 100.x.x.x and kamaiio routes the call to the asterisk via private interface 10.13.1.140. asterisk server sends the call to remote server and gets the rtp back from that Asterisk server ---converts RTP to SRTP and forward to ----> kamailio 10.13.1.140 but there is nothing happens after that, please help me on this i am new to kamailio and rtpengine. The issue is only for webrtc from public internet. But when using webrtc from LAN works fine below are the logs Mar 9 20:21:02 debian /usr/local/sbin/kamailio[11778]: INFO: <script>: from domain recived is 10.13.1.152 Mar 9 20:21:02 debian /usr/local/sbin/kamailio[11778]: INFO: <script>: 09496381412 has fromDomain recived is 10.13.1.152 Mar 9 20:21:02 debian /usr/local/sbin/kamailio[11778]: INFO: <script>: Request going to srtp customied arun Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [control] Adding a proxy for control ng stats:127.0.0.1 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Received command 'offer' from 127.0.0.1:53374 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Dump for 'offer' from 127.0.0.1:53374: { "supports": [ "load limit" ], "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 7377619262916888262 2 IN IP4 127.0.0.1 Mar 9 20:21:02 debian rtpengine[11823]: s=- Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=group:BUNDLE 0 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap-allow-mixed Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic: WMS mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB Mar 9 20:21:02 debian rtpengine[11823]: m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126 Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 0.0.0.0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp:9 IN IP4 0.0.0.0 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:NM2h Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:BF2WmB5sOZZWVIFppZ3YTiSH Mar 9 20:21:02 debian rtpengine[11823]: a=ice-options:trickle Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:sha-256 9F:FA:18:B0:8D:17:A5:14:FE:22:BA:1E:73:1E:3E:02:6F:17:EC:B5:FC:77:BD:E1:0B:51:DF:7F:61:B0:2F:55 Mar 9 20:21:02 debian rtpengine[11823]: a=setup:actpass Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=msid:mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB 6f36294e-5d92-4f0c-8ea2-ba415d0ec125 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:111 transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:111 minptime=10;useinbandfec=1 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:63 red/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:63 111/111 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:9 G722/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:0 PCMU/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:8 PCMA/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:13 CN/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:110 telephone-event/48000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=ssrc:2480159127 cname:FJAL1TGxCcnDMPXY Mar 9 20:21:02 debian rtpengine[11823]: a=ssrc:2480159127 msid:mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB 6f36294e-5d92-4f0c-8ea2-ba415d0ec125 Mar 9 20:21:02 debian rtpengine[11823]: ", "call-id": "ui7jc53b9lfbt9lf4nu7", "received-from": [ "IP4", "223.190.206.123" ], "from-tag": "7n38ig1acl", "command": "offer" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Using default bitrate of 32000 bps for 2-channel Opus Mar 9 20:21:02 debian rtpengine[11823]: NOTICE: [ui7jc53b9lfbt9lf4nu7]: [core] Creating new call Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Subscribing '7n38ig1acl' to '' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Subscribing '' to '7n38ig1acl' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating codecs for offerer 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec G722/8000 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec PCMU/8000 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec PCMA/8000 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec CN/8000 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/48000 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating codecs for answerer #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec G722/8000 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec PCMU/8000 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec PCMA/8000 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec CN/8000 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/48000 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for #1 -> 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF 110, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] No codec support for red/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for red/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec G722/8000/1 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for G722/8000 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for G722/8000 is G722/8000/1 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec G722/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for G722/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec PCMU/8000/1 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for PCMU/8000 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for PCMU/8000 is PCMU/8000/1 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec PCMU/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for PCMU/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec PCMA/8000/1 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for PCMA/8000 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for PCMA/8000 is PCMA/8000/1 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec PCMA/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for PCMA/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec CN/8000/1 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for CN/8000 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for CN/8000 is CN/8000/1 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec CN/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for CN/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/48000/1 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for telephone-event/48000 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/48000 is telephone-event/48000/1 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/48000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/48000 with DTMF 110, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for #1 -> 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF 110, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec red/48000/2 (63) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] No codec support for red/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for red/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec G722/8000/1 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for G722/8000 is G722/8000/1 (9) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec G722/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for G722/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec PCMU/8000/1 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for PCMU/8000 is PCMU/8000/1 (0) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec PCMU/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for PCMU/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec PCMA/8000/1 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for PCMA/8000 is PCMA/8000/1 (8) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec PCMA/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for PCMA/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec CN/8000/1 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for CN/8000 is CN/8000/1 (13) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec CN/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for CN/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/48000/1 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/48000 is telephone-event/48000/1 (110) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/48000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/48000 with DTMF 110, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN 13 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] set FILLED flag for stream, local 10.13.1.127:30020 remote 0.0.0.0:9 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] Creating active DTLS connection context Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] Creating active DTLS connection context Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] set FILLED flag for stream, local 10.13.1.127:30021 remote 0.0.0.0:9 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [10.13.1.127:30000] Initialized incoming SRTP with SDES crypto params: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [1] Initialized outgoing SRTP with SDES crypto params: suite AEAD_AES_256_GCM, tag 1, key czR43Q05Tlky5pj/m6BomEKXh+b5okz/iSUDQqgvHDI= salt Vov9BA7SKter2Ajj Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] Creating passive DTLS connection context Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] Creating passive DTLS connection context Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [10.13.1.127:30001] Initialized incoming SRTP with SDES crypto params: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [2] Initialized outgoing SRTP with SDES crypto params: suite AEAD_AES_256_GCM, tag 1, key czR43Q05Tlky5pj/m6BomEKXh+b5okz/iSUDQqgvHDI= salt Vov9BA7SKter2Ajj Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Replying to 'offer' from 127.0.0.1:53374 (elapsed time 0.022450 sec) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Response dump for 'offer' to 127.0.0.1:53374: { "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 7377619262916888262 2 IN IP4 127.0.0.1 Mar 9 20:21:02 debian rtpengine[11823]: s=- Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap-allow-mixed Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic: WMS mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB Mar 9 20:21:02 debian rtpengine[11823]: m=audio 30000 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126 Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 Mar 9 20:21:02 debian rtpengine[11823]: a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid Mar 9 20:21:02 debian rtpengine[11823]: a=msid:mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB 6f36294e-5d92-4f0c-8ea2-ba415d0ec125 Mar 9 20:21:02 debian rtpengine[11823]: a=ssrc:2480159127 cname:FJAL1TGxCcnDMPXY Mar 9 20:21:02 debian rtpengine[11823]: a=ssrc:2480159127 msid:mP5OKOsd0Yb5JQystk9oCQJVA8LOp4pWhuJB 6f36294e-5d92-4f0c-8ea2-ba415d0ec125 Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:111 minptime=10;useinbandfec=1 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:111 transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:63 red/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:63 111/111 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:9 G722/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:0 PCMU/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:8 PCMA/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:13 CN/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:110 telephone-event/48000 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp:30001 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:1 AEAD_AES_256_GCM inline:czR43Q05Tlky5pj/m6BomEKXh+b5okz/iSUDQqgvHDJWi/0EDtIq16vYCOM Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:2 AEAD_AES_128_GCM inline:5abyoU5PKLg1lNfmLg1aBLIqyNAgmKNEEo8J1w Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:i4O28fJjCyvBVQmwjCb7dySy5K20yeg5n1ky+uhPNSpbqkv8vxkcIaerkO9Gbg Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:OOydiBrJ9nMu23yaBP7JuYNddpbXX8sN/V9Ab/psnTZIBRZKXenHWVPvJSM9Fw Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:5 AES_192_CM_HMAC_SHA1_80 inline:UtkHFdpsaZSO0nwvmEotIoGN+paLt3LHt7yMG4MfDv5rueBsb80 Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:6 AES_192_CM_HMAC_SHA1_32 inline:hgFJ9vS9Roz1vAMhnrCyviKC/TwCPgrk5jeKbxHlIEKtqSvLdK4 Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:07Q9Z/8DguM0HJgDHv5HF3YDWHdp23hbz+TepHa8 Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:djpscuSL/05sVtFNocQpHmr1x+NTcLXKu8ePb0q+ Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:9 F8_128_HMAC_SHA1_80 inline:5FqC2VY+q3vqaju3JwroIJO/OlCM1i6TNRE/3Atj Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:10 F8_128_HMAC_SHA1_32 inline:kUfTs7OFD6ltRNpDi1dSG5ZjuQAFDeEQD5IvOwme Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:11 NULL_HMAC_SHA1_80 inline:JZ2ruS0914NL4mmS7jxg+ngz0IQaE6FBRlet8abd Mar 9 20:21:02 debian rtpengine[11823]: a=crypto:12 NULL_HMAC_SHA1_32 inline:h21D+oGRkr1dDEoMm1+vEKmKsn+4GxNBwgIew2qA Mar 9 20:21:02 debian rtpengine[11823]: a=setup:actpass Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:sha-256 0C:67:09:6B:AE:6B:30:09:81:C5:9C:65:C6:EC:9E:CE:C2:6E:E2:EA:67:B4:B5:B3:40:C4:F1:0C:3E:05:96:79 Mar 9 20:21:02 debian rtpengine[11823]: a=tls-id:8100c85eb1c58be3580e8acd7f097000 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:hcqW22Sc Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:QjHJKT4qNsfZm80zrcyh8SfI76 Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:GtpEjl9r4IzNpiXr 1 UDP 2130706431 10.13.1.127 30000 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:GtpEjl9r4IzNpiXr 2 UDP 2130706430 10.13.1.127 30001 typ host Mar 9 20:21:02 debian rtpengine[11823]: ", "result": "ok" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7//1 port 30000]: [ice] Created candidate pair GtpEjl9r4IzNpiXr:6b1875839eb037b0:1 between 10.13.1.127 and 10.13.1.152:14450, type prflx Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7//1 port 30000]: [ice] Triggering check for GtpEjl9r4IzNpiXr:6b1875839eb037b0:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7//1 port 30000]: [core] Successful STUN binding request from 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Received command 'answer' from 127.0.0.1:60024 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Dump for 'answer' from 127.0.0.1:60024: { "supports": [ "load limit" ], "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 2654832326 4 IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: s=Asterisk Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic:WMS * Mar 9 20:21:02 debian rtpengine[11823]: m=audio 14450 UDP/TLS/RTP/SAVPF 111 126 Mar 9 20:21:02 debian rtpengine[11823]: a=connection:new Mar 9 20:21:02 debian rtpengine[11823]: a=setup:active Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:SHA-256 62:AD:7E:86:4D:FF:87:6B:44:5A:F0:62:A2:37:D6:56:5C:D4:F4:A8:03:88:A6:E1:DD:2A:15:69:75:1B:04:3C Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:7706bb5e0317151b5749cc8550354244 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:4af879c44cb99216424536fa5defd9d5 Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:Ha0d0198 1 UDP 2130706431 10.13.1.152 14450 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:H6719a439 1 UDP 2130706431 103.25.164.57 14450 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:126 0-16 Mar 9 20:21:02 debian rtpengine[11823]: a=ptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=maxptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=msid:d5be09fd-dce5-4d96-879e-f34f22f54ef1 a3f22c04-6988-4464-a458-5abc099e7bc0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:* transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: ", "call-id": "ui7jc53b9lfbt9lf4nu7", "received-from": [ "IP4", "10.13.1.152" ], "from-tag": "7n38ig1acl", "to-tag": "a5935482-3f00-4dd0-b98c-0b4726da777d", "command": "answer" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Using default bitrate of 32000 bps for 2-channel Opus Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unconfirming peer address for local 10.13.1.127:30000 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unconfirming peer address for local 10.13.1.127:30020 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unconfirming peer address for local 10.13.1.127:30001 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unconfirming peer address for local 10.13.1.127:30021 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unsubscribing '7n38ig1acl' from 'a5935482-3f00-4dd0-b98c-0b4726da777d' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Unsubscribing 'a5935482-3f00-4dd0-b98c-0b4726da777d' from '7n38ig1acl' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Subscribing 'a5935482-3f00-4dd0-b98c-0b4726da777d' to '7n38ig1acl' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Subscribing '7n38ig1acl' to 'a5935482-3f00-4dd0-b98c-0b4726da777d' Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating codecs for answerer a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for a5935482-3f00-4dd0-b98c-0b4726da777d #1 -> 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Codec answer for a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Reverse codec for opus/48000/2 (111) is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Reverse codec for telephone-event/8000 (126) is telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] telephone-event/8000/1 payload type 126 already present, skip Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for 7n38ig1acl #1 -> a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Creating codec handler for telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for 7n38ig1acl #1 -> a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for a5935482-3f00-4dd0-b98c-0b4726da777d #1 -> 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] set FILLED flag for stream, local 10.13.1.127:30000 remote 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] set FILLED flag for stream, local 10.13.1.127:30001 remote 10.13.1.152:14451 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [10.13.1.127:30001] Initialized incoming SRTP with SDES crypto params: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [crypto] [2] Initialized outgoing SRTP with SDES crypto params: suite AEAD_AES_256_GCM, tag 1, key czR43Q05Tlky5pj/m6BomEKXh+b5okz/iSUDQqgvHDI= salt Vov9BA7SKter2Ajj Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Replacing previously learned prflx ICE candidate with Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Learning new ICE candidate H6719a439:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Created candidate pair GtpEjl9r4IzNpiXr:H6719a439:1 between 10.13.1.127 and 103.25.164.57:14450, type host Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Recalculating all ICE pair priorities Mar 9 20:21:02 debian rtpengine[11823]: WARNING: [ui7jc53b9lfbt9lf4nu7]: [ice] Priority collision between candidate pairs GtpEjl9r4IzNpiXr:H6719a439:1 and GtpEjl9r4IzNpiXr:Ha0d0198:1 - ICE will likely fail Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Sending ICE/STUN request for candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 from 10.13.1.127 to 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Shutting down ICE agent (nothing to do) Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Replying to 'answer' from 127.0.0.1:60024 (elapsed time 0.003226 sec) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Response dump for 'answer' to 127.0.0.1:60024: { "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 2654832326 4 IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: s=Asterisk Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic:WMS * Mar 9 20:21:02 debian rtpengine[11823]: m=audio 30020 UDP/TLS/RTP/SAVPF 111 126 Mar 9 20:21:02 debian rtpengine[11823]: a=connection:new Mar 9 20:21:02 debian rtpengine[11823]: a=maxptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=msid:d5be09fd-dce5-4d96-879e-f34f22f54ef1 a3f22c04-6988-4464-a458-5abc099e7bc0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:* transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:126 0-16 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp:30020 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=setup:active Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:sha-256 0C:67:09:6B:AE:6B:30:09:81:C5:9C:65:C6:EC:9E:CE:C2:6E:E2:EA:67:B4:B5:B3:40:C4:F1:0C:3E:05:96:79 Mar 9 20:21:02 debian rtpengine[11823]: a=tls-id:ac2907348568344c9743f21fa1383e08 Mar 9 20:21:02 debian rtpengine[11823]: a=ptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:4xVkmu6h Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:kc54UEYL25S4UjgSjVKJdcEiAR Mar 9 20:21:02 debian rtpengine[11823]: a=ice-options:trickle Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:GtpEjl9r4IzNpiXr 1 UDP 2130706431 10.13.1.127 30020 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=end-of-candidates Mar 9 20:21:02 debian rtpengine[11823]: ", "result": "ok" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Processing incoming DTLS packet Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Sending DTLS packet Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Received ICE/STUN response code 0 for candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 from 10.13.1.152:14450 to 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Setting ICE candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 as succeeded Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Best succeeded ICE pair with all components is GtpEjl9r4IzNpiXr:Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE not completed yet, but can use pair GtpEjl9r4IzNpiXr:Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE negotiated: peer for component 1 is 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE negotiated: local interface 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Processing incoming DTLS packet Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [crypto] DTLS: Peer certificate accepted Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [crypto] DTLS handshake successful Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [crypto] DTLS-SRTP successfully negotiated using AES_CM_128_HMAC_SHA1_80 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] SRTP keys, incoming: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] --- AES_CM_128_HMAC_SHA1_80 key AtAWESyBg5e6Ub3EPRQ5ag== salt rgwpYXp6KpHCmfjMxVA= Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] SRTP keys, outgoing: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] --- AES_CM_128_HMAC_SHA1_80 key 8+zHcQ5a1Bv5L0dv2AfKyg== salt 7YaPNc68d5ALtKKIOCQ= Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [crypto] DTLS-SRTP successfully negotiated using AES_CM_128_HMAC_SHA1_80 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] SRTP keys, incoming: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] --- AES_CM_128_HMAC_SHA1_80 key AtAWESyBg5e6Ub3EPRQ5ag== salt rgwpYXp6KpHCmfjMxVA= Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] SRTP keys, outgoing: Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] --- AES_CM_128_HMAC_SHA1_80 key 8+zHcQ5a1Bv5L0dv2AfKyg== salt 7YaPNc68d5ALtKKIOCQ= Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Sending DTLS packet Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Successful STUN binding request from 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1]: [ice] Start nominating ICE pairs Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1]: [ice] Nominating ICE pair GtpEjl9r4IzNpiXr:Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1]: [ice] Sending nominating ICE/STUN request for candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 from 10.13.1.127 to 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Received ICE/STUN response code 0 for candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 from 10.13.1.152:14450 to 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] Setting nominated ICE candidate pair GtpEjl9r4IzNpiXr:Ha0d0198:1 as valid Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE completed, using pair GtpEjl9r4IzNpiXr:Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE negotiated: peer for component 1 is 10.13.1.152:14450 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [ice] ICE negotiated: local interface 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Received command 'answer' from 127.0.0.1:60024 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Dump for 'answer' from 127.0.0.1:60024: { "supports": [ "load limit" ], "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 2654832326 4 IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: s=Asterisk Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic:WMS * Mar 9 20:21:02 debian rtpengine[11823]: m=audio 14450 UDP/TLS/RTP/SAVPF 111 126 Mar 9 20:21:02 debian rtpengine[11823]: a=connection:new Mar 9 20:21:02 debian rtpengine[11823]: a=setup:active Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:SHA-256 62:AD:7E:86:4D:FF:87:6B:44:5A:F0:62:A2:37:D6:56:5C:D4:F4:A8:03:88:A6:E1:DD:2A:15:69:75:1B:04:3C Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:7706bb5e0317151b5749cc8550354244 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:4af879c44cb99216424536fa5defd9d5 Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:Ha0d0198 1 UDP 2130706431 10.13.1.152 14450 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:H6719a439 1 UDP 2130706431 103.25.164.57 14450 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:126 0-16 Mar 9 20:21:02 debian rtpengine[11823]: a=ptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=maxptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=msid:d5be09fd-dce5-4d96-879e-f34f22f54ef1 a3f22c04-6988-4464-a458-5abc099e7bc0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:* transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: ", "call-id": "ui7jc53b9lfbt9lf4nu7", "received-from": [ "IP4", "10.13.1.152" ], "from-tag": "7n38ig1acl", "to-tag": "a5935482-3f00-4dd0-b98c-0b4726da777d", "command": "answer" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [core] Using default bitrate of 32000 bps for 2-channel Opus Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating codecs for answerer a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Adding codec telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for a5935482-3f00-4dd0-b98c-0b4726da777d #1 -> 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Codec answer for a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Reverse codec for opus/48000/2 (111) is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Reverse codec for telephone-event/8000 (126) is telephone-event/8000 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] telephone-event/8000/1 payload type 126 already present, skip Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for 7n38ig1acl #1 -> a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Updating supplemental codecs for a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for 7n38ig1acl #1 -> a5935482-3f00-4dd0-b98c-0b4726da777d #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Setting up codec handlers for a5935482-3f00-4dd0-b98c-0b4726da777d #1 -> 7n38ig1acl #1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Default sink codec is opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for opus/48000/2 is opus/48000/2 (111) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec opus/48000/2 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for opus/48000/2 with DTMF -1, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Checking receiver codec telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink codec for telephone-event/8000 is telephone-event/8000/1 (126) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Sink supports codec telephone-event/8000 for passthrough Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [codec] Using passthrough handler for telephone-event/8000 with DTMF 126, CN -1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Dropping new ICE candidate Ha0d0198 in favour of Ha0d0198:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Dropping new ICE candidate H6719a439 in favour of H6719a439:1 Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [ice] Shutting down ICE agent (nothing to do) Mar 9 20:21:02 debian rtpengine[11823]: INFO: [ui7jc53b9lfbt9lf4nu7]: [control] Replying to 'answer' from 127.0.0.1:60024 (elapsed time 0.002244 sec) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7]: [control] Response dump for 'answer' to 127.0.0.1:60024: { "sdp": "v=0 Mar 9 20:21:02 debian rtpengine[11823]: o=- 2654832326 4 IN IP4 10.13.1.152 Mar 9 20:21:02 debian rtpengine[11823]: s=Asterisk Mar 9 20:21:02 debian rtpengine[11823]: c=IN IP4 10.13.1.127 Mar 9 20:21:02 debian rtpengine[11823]: t=0 0 Mar 9 20:21:02 debian rtpengine[11823]: a=msid-semantic:WMS * Mar 9 20:21:02 debian rtpengine[11823]: m=audio 30020 UDP/TLS/RTP/SAVPF 111 126 Mar 9 20:21:02 debian rtpengine[11823]: a=connection:new Mar 9 20:21:02 debian rtpengine[11823]: a=maxptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=msid:d5be09fd-dce5-4d96-879e-f34f22f54ef1 a3f22c04-6988-4464-a458-5abc099e7bc0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-fb:* transport-cc Mar 9 20:21:02 debian rtpengine[11823]: a=mid:0 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:111 opus/48000/2 Mar 9 20:21:02 debian rtpengine[11823]: a=rtpmap:126 telephone-event/8000 Mar 9 20:21:02 debian rtpengine[11823]: a=fmtp:126 0-16 Mar 9 20:21:02 debian rtpengine[11823]: a=sendrecv Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp:30020 Mar 9 20:21:02 debian rtpengine[11823]: a=rtcp-mux Mar 9 20:21:02 debian rtpengine[11823]: a=setup:active Mar 9 20:21:02 debian rtpengine[11823]: a=fingerprint:sha-256 0C:67:09:6B:AE:6B:30:09:81:C5:9C:65:C6:EC:9E:CE:C2:6E:E2:EA:67:B4:B5:B3:40:C4:F1:0C:3E:05:96:79 Mar 9 20:21:02 debian rtpengine[11823]: a=tls-id:ac2907348568344c9743f21fa1383e08 Mar 9 20:21:02 debian rtpengine[11823]: a=ptime:20 Mar 9 20:21:02 debian rtpengine[11823]: a=ice-ufrag:4xVkmu6h Mar 9 20:21:02 debian rtpengine[11823]: a=ice-pwd:kc54UEYL25S4UjgSjVKJdcEiAR Mar 9 20:21:02 debian rtpengine[11823]: a=ice-options:trickle Mar 9 20:21:02 debian rtpengine[11823]: a=candidate:GtpEjl9r4IzNpiXr 1 UDP 2130706431 10.13.1.127 30020 typ host Mar 9 20:21:02 debian rtpengine[11823]: a=end-of-candidates Mar 9 20:21:02 debian rtpengine[11823]: ", "result": "ok" } Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] New ingress SSRC for: 10.13.1.152:14450 SSRC: 46ca8abf Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected: 10.13.1.152:14450) -> local 10.13.1.127:30000 (RTP seq 31783 TS 528 SSRC 46ca8abf) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Generated session key: master key f3ecc771..., master salt ed868f35..., label 00, length 16, result 6806f5cc... Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Generated session key: master key f3ecc771..., master salt ed868f35..., label 01, length 20, result 044b0cce... Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [srtp] Generated session key: master key f3ecc771..., master salt ed868f35..., label 02, length 14, result 4426c95d... Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] New egress (direct) SSRC for: 0.0.0.0:9 SSRC: 46ca8abf Mar 9 20:21:02 debian rtpengine[11823]: ERR: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] SRTP output wanted, but no crypto suite was negotiated Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Error when sending message. Error: Inappropriate ioctl for device Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected: 10.13.1.152:14450) -> local 10.13.1.127:30000 (RTP seq 31784 TS 1488 SSRC 46ca8abf) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected: 10.13.1.152:14450) -> local 10.13.1.127:30000 (RTP seq 31785 TS 2448 SSRC 46ca8abf) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected: 10.13.1.152:14450) -> local 10.13.1.127:30000 (RTP seq 31786 TS 3408 SSRC 46ca8abf) Mar 9 20:21:02 debian rtpengine[11823]: DEBUG: [ui7jc53b9lfbt9lf4nu7/a5935482-3f00-4dd0-b98c-0b4726da777d/1 port 30000]: [core] Handling packet: remote 10.13.1.152:14450 (expected:

2 1

Re: Kamailio stops processing the calls - restart fixes it.
by Henning Westerholt 10 Mar '23

10 Mar '23

Hello, please keep the list in the mail flow. Have you tried to set the acc_function modparam to an empty string, as commented in the linked issue? modparam("uac_redirect","acc_function","") If you don't need the acc function from the uac_redirect. Regarding the other warnings, they should be fixed - but different compilers can report different warnings, so it's sometimes happening. If they are just warnings, they should not create an issue. If you are using Debian/Ubuntu you can just use the prebuild packages from deb.kamailio.org - you don't need to build by yourself. Cheers, Henning -----Original Message----- From: Muhammad Danish Moosa <danishmoosa(a)gmail.com> Sent: Donnerstag, 2. März 2023 14:25 To: Henning Westerholt <hw(a)gilawa.com> Subject: Re: [SR-Users] Kamailio stops processing the calls - restart fixes it. Hi, I tried to install 5.6.4 (https://www.kamailio.org/pub/kamailio/5.6.4/src/) and get this error. Mar 3 00:05:39 lab-danish /usr/local/sbin/kamailio[24642]: INFO: rr [rr_mod.c:188]: mod_init(): outbound module not available Mar 3 00:05:39 lab-danish /usr/local/sbin/kamailio[24642]: ERROR: uac_redirect [../../modules/acc/acc_api.h:191]: acc_load_api(): cannot find bind_acc Mar 3 00:05:39 lab-danish /usr/local/sbin/kamailio[24642]: ERROR: uac_redirect [uac_redirect.c:259]: redirect_init(): cannot bind to ACC API Mar 3 00:05:39 lab-danish /usr/local/sbin/kamailio[24642]: ERROR: <core> [core/sr_module.c:975]: init_mod(): Error while initializing module uac_redirect (/usr/local/lib64/kamailio/modules/uac_redirect.so) It seems this issue was reported earlier and supposed to be fixed but apparently it's not. https://github.com/kamailio/kamailio/issues/3188 Besides that , I had seen warnings during compilation. What should be the most tested and supported version ? Example Warnings: dmq_funcs.c: In function ‘ki_dmq_send_message’: dmq_funcs.c:303:3: warning: missing braces around initializer [-Wmissing-braces] dmq_peer_t new_peer = {0}; ^ dmq_funcs.c:303:3: warning: (near initialization for ‘new_peer.peer_id’) [-Wmissing-braces] dmq_funcs.c: In function ‘ki_dmq_bcast_message’: dmq_funcs.c:373:3: warning: missing braces around initializer [-Wmissing-braces] dmq_peer_t new_peer = {0}; ^ dmq_funcs.c:373:3: warning: (near initialization for ‘new_peer.peer_id’) [-Wmissing-braces] CC (gcc) [M dmq.so] notification_peer.o CC (gcc) [M dmq.so] dmq.o dmq.c:61:1: warning: missing braces around initializer [-Wmissing-braces] sip_uri_t dmq_server_uri = {0}; On Wed, Mar 1, 2023 at 7:26 PM Henning Westerholt <hw(a)gilawa.com> wrote: > > Hello, > > better take the latest one, e.g. 5.6.4 released yesterday. Minor releases only contains bugfixes, documentation enhancements and similar. Only rarely regressions happen. But you should of course test it. > > Cheers, > > Henning > > -----Original Message----- > From: Muhammad Danish Moosa <danishmoosa(a)gmail.com> > Sent: Mittwoch, 1. März 2023 09:22 > To: Henning Westerholt <hw(a)gilawa.com> > Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > Subject: Re: [SR-Users] Kamailio stops processing the calls - restart fixes it. > > Thank you for your email. > > Is v5.6.1 (July 6, 2022) stable? > > obtained from > > https://www.kamailio.org/pub/kamailio/latest-stable-version-number > > > On Wed, Mar 1, 2023 at 5:50 PM Henning Westerholt <hw(a)gilawa.com> wrote: > > > > Hello, > > > > hard to say without more information, a backtrace etc... As I first step, I would suggest you to update the system to one of the supported releases, e.g. the latest 5.6.x or 5.5.x. > > > > Cheers, > > > > Henning > > > > -----Original Message----- > > From: Muhammad Danish Moosa <danishmoosa(a)gmail.com> > > Sent: Mittwoch, 1. März 2023 01:39 > > To: sr-users(a)lists.kamailio.org > > Subject: [SR-Users] Kamailio stops processing the calls - restart fixes it. > > > > Hi, > > > > I have a very simple proxy (stateful) where kamailio acts as a proxy between 2 endpoints. Everything works fine for weeks and suddenly I see kamailio stops responding. From pcap I can see kamailio is not proxying the session progress and bombarding invites to one endpoint without any reason. Even that invite was stripped on the Body part. > > > > Restarting kamailio fixes it immediately. Unfortunately I could not take bt full yet. > > > > Version is > > > > kamailio 5.5.3 (x86_64/linux) 473cef > > > > configuration is very simple , routing is based on tm.t_relay ( based on KEMI). > > > > Any help will be welcome. > > > > Danish > > > > > > > > -- > > Muhammad Danish Moosa > > __________________________________________________________ > > Kamailio - Users Mailing List - Non Commercial Discussions 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! > > Edit mailing list options or unsubscribe: > > > > -- > Muhammad Danish Moosa > > " The core of mans' spirit comes from new experiences. "___ > Christopher McCandless -- Muhammad Danish Moosa " The core of mans' spirit comes from new experiences. "___ Christopher McCandless

4 21

WebRTC Error
by Social Boh 09 Mar '23

09 Mar '23

Hello, I have this error when trying to register this softphone: https://github.com/InnovateAsterisk/Browser-Phone 61096#015#012Host: sip1.kamailio.xyz:8443#015#012Connection: Upgrade#015#012Pragma: no-cache#015#012Cache-Control: no-cache#015#012Upgrade: websocket#015#012Origin: https://campus.voztovoice.org#015#012Sec-WebSocket-Version: 13#015#012User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36#015#012Accept-Encoding: gzip, deflate, br#015#012Accept-Language: es-419,es;q=0.6#015#012sec-gpc: 1#015#012Sec-WebSocket-Key: uj5cXle8zzBFUzv4kWB2pg==#015#012Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits#015#012Sec-WebSocket-Protocol: sip#015#012#015#012> Mar 9 08:10:55 sip1 /sbin/kamailio[194807]: WARNING: <script>: HTTP request received on 8443 Mar 9 08:10:55 sip1 /sbin/kamailio[194807]: DEBUG: xhttp [xhttp_mod.c:426]: xhttp_send_reply(): sending out response: 403 Forbidden Any help is really apreciated -- --- I'm SoCIaL, MayBe

1 1

Location / Registrar, TCP: Use existing TCP connection
by Benoit Panizzon 09 Mar '23

09 Mar '23

Hi List CPE behind Firewall, registering to Kamailio via TCP (or TLS). When a call is sent to the CPE, kamailio attemts to open a new TCP connection and is blocked by Firewall. Is there an option to tell kamailio to use the existing registered TCP connection? 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

Call recovery for HA with sems
by Patrick Karton 09 Mar '23

09 Mar '23

1 0

TLS -> UDP ReInvite
by Social Boh 08 Mar '23

08 Mar '23

hello, I'm configuring Kamailio to permite calls like: UDP -> UDP TLS -> TLS UDP -> TLS TLS -> UDP Until now all is ok; the only problem is with Microsip SoftPhone. When make a call from Microsip TLS to another phone UDP, when the callee answer, Microsip send a new INVITE and Kamailio don't delete all references to SRTP so the call happens but without audio. I know I have to process the reINVITE where I do has_totag stuff but I don't know how. Regards -- --- I'm SoCIaL, MayBe

1 0

Re: sr-users Digest, Vol 213, Issue 52
by Mohamed SADIK 08 Mar '23

08 Mar '23

Hello, Thank you for your reply! I've used your suggestion to accomplish some amazing things. However, I'm having an issue when calling the *"sl.stats"* or any other procedures. I've noticed that the number of "200" responses gets incremented by 2, which is not the case when using the `*kamcmd*` tool. I suspect that this may be due to jsonrpc using *http/https*, which is causing Kamailio to treat it as a "200" response code. Could you advise on how to avoid this issue? Is there any further configuration that needs to be done? Best regards. On Sat, Feb 25, 2023 at 12:00 PM <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. Kamailio RPC configuration (sadik.oualla.mohamed(a)gmail.com) > 2. Re: Kamailio RPC configuration (Alex Balashov) > > > > ---------- Forwarded message ---------- > From: sadik.oualla.mohamed(a)gmail.com > To: sr-users(a)lists.kamailio.org > Cc: > Bcc: > Date: Fri, 24 Feb 2023 17:07:33 -0000 > Subject: [SR-Users] Kamailio RPC configuration > Dear Kamailio community, > > I am a newbie in Kamailio and I am currently working on a project that > involves communicating with Kamailio using Python. I have been exploring > the Kamailio documentation and I have come across RPC, JSONRPCS..., which I > believe can help me achieve my goal. > > However, I am not sure about the steps to follow in the Kamailio > configuration file to create my own script to communicate with Kamailio > using Python (the script is on an other machine on the same LAN). I would > be grateful if someone could guide me through the process. > > I have already set up Kamailio (builed it from the source code 5.5.5) and > Python on my machines and I have basic knowledge of Kamailio configuration. > I just need some guidance on how to set up the RPC module in Kamailio and > how to create a Python script to communicate with it. I found that I can > use RPyC library of python. > > I would appreciate any help or suggestions from the Kamailio community. > Thank you in advance for your time and assistance. > > Best regards, > Wild Coder. > > > > ---------- Forwarded message ---------- > From: Alex Balashov <abalashov(a)evaristesys.com> > To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> > Cc: > Bcc: > Date: Fri, 24 Feb 2023 13:22:16 -0500 > Subject: [SR-Users] Re: Kamailio RPC configuration > Hi, > > The easiest way to communicate with the JSONRPCS module is probably to use > HTTP, in the form of the `xhttp` module: > > https://kamailio.org/docs/modules/5.6.x/modules/xhttp.html > > You will need... > > 1) To enable the HTTP transport in the `jsonrpcs` module; > > 2) A TCP or TLS listener (listen= config directive) to accept the traffic; > > 3) An xhttp `event_route[xhttp:request]` route, as detailed in that > module's docs: > > > https://kamailio.org/docs/modules/5.6.x/modules/xhttp.html#xhttp.f.xhttp_re… > > 4) Probably some measure of security / authentication for #3. > > The example from jsonrpc_dispatch() is perfectly sufficient to get you > started: > > > https://kamailio.org/docs/modules/5.6.x/modules/jsonrpcs.html#jsonrpcs.f.js… > > You should then be able to do things like: > > # curl \ > -X POST \ > -d '{"jsonrpc": "2.0", "id": "abc123", "method": "ul.dump"}' \ > http://${KAMAILIO_IP}:5060/RPC <http://${kamailio_ip}:5060/RPC> > > -- Alex > > > On Feb 24, 2023, at 12:07 PM, sadik.oualla.mohamed(a)gmail.com wrote: > > > > Dear Kamailio community, > > > > I am a newbie in Kamailio and I am currently working on a project that > involves communicating with Kamailio using Python. I have been exploring > the Kamailio documentation and I have come across RPC, JSONRPCS..., which I > believe can help me achieve my goal. > > > > However, I am not sure about the steps to follow in the Kamailio > configuration file to create my own script to communicate with Kamailio > using Python (the script is on an other machine on the same LAN). I would > be grateful if someone could guide me through the process. > > > > I have already set up Kamailio (builed it from the source code 5.5.5) > and Python on my machines and I have basic knowledge of Kamailio > configuration. I just need some guidance on how to set up the RPC module in > Kamailio and how to create a Python script to communicate with it. I found > that I can use RPyC library of python. > > > > I would appreciate any help or suggestions from the Kamailio community. > Thank you in advance for your time and assistance. > > > > Best regards, > > Wild Coder. > > __________________________________________________________ > > Kamailio - Users Mailing List - Non Commercial Discussions > > 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! > > Edit mailing list options or unsubscribe: > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 e > > _______________________________________________ > sr-users mailing list -- sr-users(a)lists.kamailio.org > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org >

1 0

Using jsonrpc_dispatch in xhttp:request - is it possible to restrict the RPC that can be invoked ?
by Chaigneau, Nicolas 07 Mar '23

07 Mar '23

Hello, I'm using jsonrpc_dispatch in a "xhttp:request" section (with xhttp and jsonrpcs modules), e.g.: event_route[xhttp:request] { if ($hu =~ "^/RPC") { jsonrpc_dispatch(); exit; } xhttp_reply("404", "Not Found", "", ""); exit; } This works, but I would like to restrict the RPC functions that can be invoked this way. Any advice on how I could do that ? The xhttp module provides "url_skip" and "url_match" but this is not useful because in the URL I only have something like "RPC". And the method is in the JSON body. I could parse the JSON body before calling jsonrpc_dispatch, but it's a bit complicated (I don't know if it's feasible in Kamailio script ?), and seems redundant because jsonrpc_dispatch already does that... Maybe somehow this could be checked from the "void *" second argument passed to the RPC function ? Thanks. Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

2 4

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