- sr-users - kamailio.org

Theoritical Anycast Setup
by Daniel Oakes 14 May '19

14 May '19

Hi there, Long time user, 1st time poster - apologies if someone has posted this previously. We have a product from a vendor that utilizes Kamailio as a SIP router - but we're wanting to extend it a little bit by the use of anycast (we're a small ISP). Basically the scenario is that we want to utilize Quagga via BGP to anycast an address, which addresses a glaring load balancing issue with have with people who use only A records. Problem is anycast doesn't work so well in this scenario, just by adding the Anycast as a listen address on the proxy. What we'd want to do is rewrite the SIP so that all responses come back out saying to use the 'real ip'. So I have two variables - say REAL_IP_ADDRESS and ANYCAST_IP_ADDRESS - request will come in via ANYCAST, but I want all responses from then on to be via REAL_IP_ADDRESS. We have six Kamailio boxes in various geographical locations, so the idea is they hit one based on closest, and we rewrite it so they end up with the real ip address to talk to. Anyone done something similar? I'm guessing possibly, but I can't find anything specific enough for me to use. Help appreciated! Regards, Daniel

2 1

No audio after IP address change
by Chris Scheid 11 May '19

11 May '19

Hi, we are using rtpengine with Kamailio using DTLS-SRTP and SRTP making audio calls from two Android devices. Regular audio calls work fine but we have issues with the following scenario: 1. Device 1 (72.66.83.8, on WiFI) calls Device 2 (174.204.14.29). SIP server has IP 209.182.216.71. 2. Device 2 switches networks from WiFI to 3G (new IP: 97.47.70.223). Re-invite flow completes. 3. Any audio from Device 2 cannot be heard on Device 1. But audio from the Device1 can be heard on the Device 2. In the rtpengine stats I see that there were some packets sent from the SIP server to the Device 1 after network change: [1557513316.000308] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: ------ Media #1 (audio over UDP/TLS/RTP/SAVP) using iLBC/8000 [1557513316.000318] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: --------- Port 209.182.216.71:20052 <> 97.47.70.223:4667 , SSRC 77c38349, 55 p, 3410 b, 0 e, 32 ts [1557513316.000325] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: --------- Port 209.182.216.71:20053 <> 97.47.70.223:4640 (RTCP), SSRC 77c38349, 12 p, 1120 b, However, in my UDP trace, I don't see any communication between the SIP server and the Device 1 after network change (IP 97.47.70.223). This seems to be the reason why we don't get audio on Device 1. I'm looking for direction on how to troubleshoot this issue. I'm not so familiar with rtpengine. Any assistance greatly appreciated. Thanks! RTP Engine Config: [rtpengine] #####table = 0 listen-ng = 127.0.0.1:5050 timeout = 60 silent-timeout = 3600 tos = 184 port-min = 20000 port-max = 60000 interface = 209.182.216.71 log-level = 7 log-stderr = false log-facility = local0 START CALL --------------------------------------------------------------------------------------------------------------------- [1557513231.973294] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Received command 'offer' from 127.0.0.1:45431 [1557513231.973357] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Dump for 'offer' from 127.0.0.1:45431: { "sdp": "v=0 o=- 3766502030 3766502030 IN IP4 192.168.1.200 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 5095 UDP/TLS/RTP/SAVP 104 98 97 99 3 0 8 9 96 c=IN IP4 192.168.1.200 b=TIAS:64000 a=rtcp:5096 IN IP4 192.168.1.200 a=sendrecv a=rtpmap:104 iLBC/8000 a=fmtp:104 mode=30 a=rtpmap:98 speex/16000 a=rtpmap:97 speex/8000 a=rtpmap:99 speex/32000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=ssrc:2009301833 cname:32ababda5d2c847b a=setup:actpass a=fingerprint:SHA-256 4F:69:B6:89:51:98:6C:A4:63:CF:F7:CD:22:D2:BE:FD:6E:3F:F4:2A:8B:39:AD:E4:C0:8D:AE:BD:A3:70:12:49 ", "ICE": "remove", "DTLS": "passive", "replace": [ "origin", "session-connection" ], "transport-protocol": "UDP/TLS/RTP/SAVP", "call-id": "05c7dcfe-06f3-4630-9 799-0557b76cc340", "received-from": [ "IP4", "72.66.83.8" ], "from-tag": "2684eff8-3602-41ed-aca2-9f7938362462", "command": "offer" } [1557513231.973444] NOTICE: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating new call [1557513231.973496] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Default sink codec is speex/16000 [1557513231.973503] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for iLBC/8000 [1557513231.973508] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for speex/16000 [1557513231.973512] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec speex/16000 [1557513231.973515] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for speex/8000 [1557513231.973519] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec speex/8000 [1557513231.973523] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for speex/32000 [1557513231.973526] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec speex/32000 [1557513231.973530] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for GSM/8000 [1557513231.973534] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec GSM/8000 [1557513231.973538] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for PCMU/8000 [1557513231.973542] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec PCMU/8000 [1557513231.973545] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for PCMA/8000 [1557513231.973549] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec PCMA/8000 [1557513231.973545] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for PCMA/8000 [1557513231.973549] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec PCMA/8000 [1557513231.973552] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for G722/8000 [1557513231.973556] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec G722/8000 [1557513231.973560] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for telephone-event/8000 [1557513231.974291] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: set FILLED flag for stream 192.168.1.200:5095 [1557513231.974561] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: set FILLED flag for stream 192.168.1.200:5096 [1557513231.974874] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: offer time = 0.001488 sec [1557513231.974882] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Replying to 'offer' from 127.0.0.1:45431 [1557513231.974900] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Response dump for 'offer' to 127.0.0.1:45431: { "sdp": "v=0 o=- 3766502030 3766502030 IN IP4 209.182.216.71 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 20032 UDP/TLS/RTP/SAVP 104 98 97 99 3 0 8 9 96 c=IN IP4 209.182.216.71 b=TIAS:64000 a=ssrc:2009301833 cname:32ababda5d2c847b a=rtpmap:104 iLBC/8000 a=rtpmap:98 speex/16000 a=rtpmap:97 speex/8000 a=rtpmap:99 speex/32000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:104 mode=30 a=fmtp:96 0-16 a=sendrecv a=rtcp:20033 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:G9MvyRPBAVFsrMypvr1EAunZiX/vc04sXEq4mXvl a=setup:actpass a=fingerprint:sha-1 EE:4A:ED:7D:5A:94:A2:FF:F2:09:64:07:41:FC:15:80:D3:F9:C0:B4 ", "result": "ok" } [1557513232.077386] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: Processing incoming DTLS packet [1557513232.078219] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: Sending DTLS packet [1557513232.189220] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: Processing incoming DTLS packet [1557513232.189868] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: DTLS handshake successful [1557513232.189899] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: DTLS-SRTP successfully negotiated [1557513232.189905] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: SRTP keys, incoming: [1557513232.189914] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: --- AES_CM_128_HMAC_SHA1_80 key q67B3h3GP/dhbQeKsgBnvA== salt EcoNJ6Hqj0lRtvZ8Z+Y= [1557513232.189919] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: SRTP keys, outgoing: [1557513232.189923] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: --- AES_CM_128_HMAC_SHA1_80 key 0nTo2gy4XJ2GXlroyyH6nA== salt fbIfUIa4IPiYLvn5CkI= [1557513232.189929] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: Sending DTLS packet confirmed [1557513243.648460] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: SRTCP output wanted, but no crypto suite was negotiated [1557513243.648486] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 201 [1557513243.648496] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about 9fda818d: FL 205 TL 6486816 HSR 613804890 J 3100337071 LSR 1419186059 DLSR 531075031 [1557513243.648505] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513243.649142] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 201 [1557513243.649158] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about d4b1278d: FL 23 TL 2271802 HSR 278642673 J 2408385537 LSR 3 653820601 DLSR 1701759944 [1557513243.649169] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513243.777813] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Received command 'answer' from 127.0.0.1:47861 [1557513243.777860] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Dump for 'answer' from 127.0.0.1:47861: { "sdp": "v=0 o=- 3766502031 3766502032 IN IP4 100.81.62.76 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 5079 UDP/TLS/RTP/SAVP 104 96 c=IN IP4 100.81.62.76 b=TIAS:64000 a=rtcp:5080 IN IP4 100.81.62.76 a=sendrecv a=rtpmap:104 iLBC/8000 a=fmtp:104 mode=30 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=ssrc:2006816651 cname:1c0965113e9b1046 a=setup:active a=fingerprint:SHA-256 AD:2D:0F:A6:11:DD:75:CC:3C:50:3A:9A:F0:29:20:8D:95:BC:3E:2A:A0:34:F6:67:14:A7:87:EB:8D:66:77:B1 ", "ICE": "remove", "replace": [ "origin", "session-connection" ], "transport-protocol": "UDP/TLS/RTP/SAVP", "call-id": "05c7dcfe-06f3-4630-9799-0557b76cc340", "received-from": [ "IP4", "174.204.14.29" ], "from-tag": "2684eff8-3602-41ed-aca2-9f7938362462", "to-tag": "c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00", "command": "a nswer" } [1557513243.777998] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for iLBC/8000 [1557513243.778010] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Creating codec handler for telephone-event/8000 [1557513243.778088] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: set FILLED flag for stream 100.81.62.76:5079 [1557513243.778117] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: DTLS: Peer certificate accepted [1557513243.778123] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: set FILLED flag for stream 100.81.62.76:5080 [1557513243.778166] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: answer time = 0.000267 sec [1557513243.778175] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Replying to 'answer' from 127.0.0.1:47861 [1557513243.778187] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Response dump for 'answer' to 127.0.0.1:47861: { "sdp": "v=0 o=- 3766502031 3766502032 IN IP4 209.182.216.71 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 20052 UDP/TLS/RTP/SAVP 104 96 c=IN IP4 209.182.216.71 b=TIAS:64000 a=ssrc:2006816651 cname:1c0965113e9b1046 a=rtpmap:104 iLBC/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:104 mode=30 a=fmtp:96 0-16 a=sendrecv a=rtcp:20053 a=setup:passive a=fingerprint:sha-1 EE:4A:ED:7D:5A:94:A2:FF:F2:09:64:07:41:FC:15:80:D3:F9:C0:B4 ", "result": "ok" } [1557513243.864786] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Processing incoming DTLS packet [1557513243.865568] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Sending DTLS packet [1557513243.912858] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Processing incoming DTLS packet [1557513243.913111] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: DTLS: Peer certificate accepted [1557513243.913627] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: DTLS handshake successful [1557513243.913668] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: DTLS-SRTP successfully negotiated [1557513243.913675] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: SRTP keys, incoming: [1557513243.913682] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: --- AES_CM_128_HMAC_SHA1_80 key +C2ck1NPvsfHYoKflimqaA== salt xM4aFoL60/ePpmQJsT8= [1557513243.913686] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: SRTP keys, outgoing: [1557513243.913689] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: --- AES_CM_128_HMAC_SHA1_80 key VvTNUyescFh+vNj16/fePw== salt m3EuTJjAesJHaSXfqKU= [1557513243.913694] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Sending DTLS packet [1557513244.475362] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 200 [1557513244.475405] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: SR from 779d978b: RTP TS 3873048209 PC 2516599107 OC 673505029 NTP TS 1161195675/4 008032614=1161195675.933193 [1557513244.475412] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about bb94938e: FL 243 TL 11665253 HSR 1302964504 J 2830082235 LS R 1964993324 DLSR 1625750139 [1557513244.475422] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513244.492749] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SRTCP output wanted, but no crypto suite was negotiated [1557513244.492775] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513244.492791] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 2981125880 PC 4052113656 OC 2653921327 NTP TS 4076801750/ 1160081551=4076801750.270103 [1557513244.492797] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 3813d27e: FL 75 TL 11393233 HSR 1719559869 J 944495881 LSR 790240102 DLSR 447292567 [1557513244.492804] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513247.217290] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20032]: Confirmed peer address as 174.204.14.29:10523 [1557513248.958592] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 200 [1557513248.958638] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: SR from 779d978b: RTP TS 3148803183 PC 137367242 OC 1506652935 NTP TS 3606800652/1 621372750=3606800652.377505 [1557513248.958647] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about 468fa6ae: FL 57 TL 15596558 HSR 3764947872 J 3769875796 LSR 4259175195 DLSR 3903464346 [1557513248.958657] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513248.958667] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Confirmed peer address as 174.204.14.29:10496 i[1557513249.259063] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513249.259108] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 3424021083 PC 3823893658 OC 584056375 NTP TS 3244065141/3 391763074=3244065141.789706 [1557513249.259117] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about e7313af6: FL 98 TL 10263186 HSR 2762600672 J 838876573 LSR 3367219470 DLSR 50549698 [1557513249.259131] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513249.259142] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Confirmed peer address as 72.66.83.8:5096 t[1557513249.562239] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Confirmed peer address as 72.66.83.8:5095 SWITCH NETWORKS [1557513253.843937] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 200 [1557513253.844019] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: SR from 779d978b: RTP TS 1364757765 PC 1063357287 OC 2194907961 NTP TS 2472417766/ 1884000851=2472417766.438653 [1557513253.844029] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about 77b8933: FL 163 TL 2305413 HSR 2377964402 J 118139039 LSR 2 460485565 DLSR 3416921415 [1557513253.844040] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513254.590466] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513254.590508] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 2527484095 PC 1878948628 OC 3882176963 NTP TS 213338522/6 38146641=213338522.148580 [1557513254.590517] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about b7800717: FL 93 TL 16503124 HSR 338254320 J 1043490285 LSR 801212789 DLSR 2849120558 [1557513254.590530] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513258.679347] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: SRTCP output wanted, but no crypto suite was negotiated [1557513258.679385] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 200 [1557513258.679411] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: SR from 779d978b: RTP TS 1747525463 PC 239751946 OC 2859161225 NTP TS 3835334254/3 577221347=3835334254.832887 [1557513258.679418] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about e03bd142: FL 40 TL 11515285 HSR 3870936491 J 4150119236 LSR 2903910302 DLSR 700479064 [1557513258.679427] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513259.940740] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SRTCP output wanted, but no crypto suite was negotiated [1557513259.940770] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513259.940793] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 2745657868 PC 580822102 OC 4072320279 NTP TS 252333929/20 93935903=252333929.487532 [1557513259.940801] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 476ec510: FL 61 TL 5399464 HSR 3682903462 J 1600791504 LSR 497094189 DLSR 826539320 [1557513259.940814] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513263.532695] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 200 [1557513263.532722] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: SR from 779d978b: RTP TS 301750475 PC 2434799802 OC 863475295 NTP TS 3625503376/30 14095725=3625503376.701774 [1557513263.532729] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about 228989b7: FL 148 TL 10638176 HSR 2137788972 J 2678688015 LS R 2118438561 DLSR 1024262683 [1557513263.532738] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513264.051305] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513264.051352] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 1190725747 PC 3072491822 OC 537479863 NTP TS 817717026/42 82321058=817717026.997056 [1557513264.051359] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 920db8ff: FL 98 TL 6598240 HSR 2045142812 J 3171281598 LSR 2224002690 DLSR 2514604823 [1557513264.051369] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513264.058891] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 201 [1557513264.058920] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 5c8f2711: FL 24 TL 1700303 HSR 2993289918 J 618517078 LSR 1 835926259 DLSR 3106454771 [1557513264.058891] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 201 [1557513264.058920] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 5c8f2711: FL 24 TL 1700303 HSR 2993289918 J 618517078 LSR 1 835926259 DLSR 3106454771 [1557513264.058934] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513264.266612] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Received command 'offer' from 127.0.0.1:60736 [1557513264.266654] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Dump for 'offer' from 127.0.0.1:60736: { "sdp": "v=0 o=- 3766502030 3766502031 IN IP4 192.168.1.200 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 5097 UDP/TLS/RTP/SAVP 104 98 97 99 3 0 8 9 96 c=IN IP4 10.255.81.66 b=TIAS:64000 a=rtcp:5098 IN IP4 10.255.81.66 a=sendrecv a=rtpmap:104 iLBC/8000 a=fmtp:104 mode=30 a=rtpmap:98 speex/16000 a=rtpmap:97 speex/8000 a=rtpmap:99 speex/32000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=ssrc:2009301833 cname:32ababda5d2c847b a=setup:actpass a=fingerprint:SHA-256 4F:69:B6:89:51:98:6C:A4:63:CF:F7:CD:22:D2:BE:FD:6E:3F:F4:2A:8B:39:AD:E4:C0:8D:AE:BD:A3:70:12:49 ", "ICE": "remove", "DTLS": "passive", "replace": [ "origin", "session-connection" ], "transport-protocol": "UDP/TLS/RTP/SAVP", "call-id": "05c7dcfe-06f3-4630-9 799-0557b76cc340", "received-from": [ "IP4", "97.47.70.223" ], "from-tag": "2684eff8-3602-41ed-aca2-9f7938362462", "to-tag": "c71ac9de-9bf5-4f39-9fda-6bd3aaf97d 00", "command": "offer" } [1557513264.266814] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Default sink codec is speex/16000 [1557513264.266826] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec speex/16000 [1557513264.266831] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec speex/8000 [1557513264.266835] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec speex/32000 [1557513264.266838] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec GSM/8000 [1557513264.266842] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec PCMU/8000 [1557513264.266846] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec PCMA/8000 [1557513264.266850] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sink supports codec G722/8000 [1557513264.267614] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sending DTLS packet [1557513264.268089] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sending DTLS packet [1557513264.268146] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sending DTLS packet [1557513264.268220] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: set FILLED flag for stream 10.255.81.66:5097 [1557513264.268627] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: set FILLED flag for stream 10.255.81.66:5098 [1557513264.269072] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: offer time = 0.002384 sec [1557513264.269084] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Replying to 'offer' from 127.0.0.1:60736 [1557513264.269098] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Response dump for 'offer' to 127.0.0.1:60736: { "sdp": "v=0 o=- 3766502030 3766502031 IN IP4 209.182.216.71 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 20064 UDP/TLS/RTP/SAVP 104 98 97 99 3 0 8 9 96 c=IN IP4 209.182.216.71 b=TIAS:64000 a=ssrc:2009301833 cname:32ababda5d2c847b a=rtpmap:104 iLBC/8000 a=rtpmap:98 speex/16000 a=rtpmap:97 speex/8000 a=rtpmap:99 speex/32000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:104 mode=30 a=fmtp:96 0-16 a=sendrecv a=rtcp:20065 a=setup:actpass a=fingerprint:sha-1 EE:4A:ED:7D:5A:94:A2:FF:F2:09:64:07:41:FC:15:80:D3:F9:C0:B4 ", "result": "ok" } [1557513264.355109] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SRTCP output wanted, but no crypto suite was negotiated [1557513264.355140] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Calling handler for RTCP packet type 201 [1557513264.355150] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: RR from 779d978b about 511a36de: FL 144 TL 3729734 HSR 2556650506 J 4034165594 LSR 900570716 DLSR 3118967760 [1557513264.355166] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: No payload type known for RTCP RR, discarding [1557513264.355186] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 201 [1557513264.355193] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about aea81208: FL 180 TL 10378624 HSR 1586287909 J 2246375086 LS R 3231023203 DLSR 4073439206 [1557513264.355201] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513264.355210] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Switching local interface to 209.182.216.71:20033 [1557513264.358206] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: Calling handler for RTCP packet type 201 [1557513264.358229] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: RR from 779d978b about b59d47bc: FL 242 TL 13886413 HSR 3966401064 J 2679493971 LS R 3040876731 DLSR 2668321392 [1557513264.358239] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20033]: No payload type known for RTCP RR, discarding [1557513264.358262] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20064]: SRTP output wanted, but no crypto suite was negotiated [1557513264.425636] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Received command 'answer' from 127.0.0.1:45431 [1557513264.425679] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Dump for 'answer' from 127.0.0.1:45431: { "sdp": "v=0 o=- 3766502031 3766502033 IN IP4 100.81.62.76 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 5079 UDP/TLS/RTP/SAVP 104 96 c=IN IP4 100.81.62.76 b=TIAS:64000 a=rtcp:5080 IN IP4 100.81.62.76 a=sendrecv a=rtpmap:104 iLBC/8000 a=rtpmap:104 iLBC/8000 a=fmtp:104 mode=30 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=ssrc:2006816651 cname:1c0965113e9b1046 a=setup:active a=fingerprint:SHA-256 AD:2D:0F:A6:11:DD:75:CC:3C:50:3A:9A:F0:29:20:8D:95:BC:3E:2A:A0:34:F6:67:14:A7:87:EB:8D:66:77:B1 ", "ICE": "remove", "replace": [ "origin", "session-connection" ], "transport-protocol": "UDP/TLS/RTP/SAVP", "call-id": "05c7dcfe-06f3-4630-9799-0557b76cc340", "received-from": [ "IP4", "174.204.14.29" ], "from-tag": "2684eff8-3602-41ed-aca2-9f7938362462", "to-tag": "c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00", "command": "a nswer" } [1557513264.426806] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: answer time = 0.001099 sec [1557513264.426820] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Replying to 'answer' from 127.0.0.1:45431 [1557513264.426831] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Response dump for 'answer' to 127.0.0.1:45431: { "sdp": "v=0 o=- 3766502031 3766502033 IN IP4 209.182.216.71 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 20052 UDP/TLS/RTP/SAVP 104 96 c=IN IP4 209.182.216.71 b=TIAS:64000 a=ssrc:2006816651 cname:1c0965113e9b1046 a=rtpmap:104 iLBC/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:104 mode=30 a=fmtp:96 0-16 a=sendrecv a=rtcp:20053 a=setup:passive a=fingerprint:sha-1 EE:4A:ED:7D:5A:94:A2:FF:F2:09:64:07:41:FC:15:80:D3:F9:C0:B4 ", "result": "ok" } [1557513264.700442] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Processing incoming DTLS packet [1557513264.701235] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Sending DTLS packet [1557513264.892393] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Processing incoming DTLS packet [1557513264.893153] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: DTLS handshake successful [1557513264.893193] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: DTLS-SRTP successfully negotiated [1557513264.893202] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: SRTP keys, incoming: [1557513264.893211] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: --- AES_CM_128_HMAC_SHA1_80 key dob4sywpHJJ8qNgFzemlzQ== salt y7/1RgzeAtPkG+GfMLI= [1557513264.893216] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: SRTP keys, outgoing: [1557513264.893222] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: --- AES_CM_128_HMAC_SHA1_80 key ontM1nC56XojOkmzb8520g== salt Hom6TrHovUBUaF1g6Iw= [1557513264.893228] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Sending DTLS packet [1557513269.223923] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20052]: Confirmed peer address as 97.47.70.223:4667 [1557513269.337491] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513269.337543] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 402044265 PC 1976845075 OC 2962195809 NTP TS 1329245270/2 977782988=1329245270.693319 [1557513269.337552] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about c1e9445b: FL 196 TL 15740765 HSR 1231260891 J 3373413243 LS R 2989889476 DLSR 1721296716 [1557513269.337562] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513269.337571] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Confirmed peer address as 97.47.70.223:4640 [1557513269.355712] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Calling handler for RTCP packet type 200 [1557513269.355744] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SR from 779d978b: RTP TS 46888194 PC 1178262997 OC 1943197043 NTP TS 748304878/374 [1557513269.355749] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: RR from 779d978b about 4d78530a: FL 59 TL 15587360 HSR 641166863 J 455122196 LSR 2 981586141 DLSR 1538485973 [1557513269.355755] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: No payload type known for RTCP RR, discarding [1557513269.355763] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Confirmed peer address as 174.204.14.29:10496 [1557513269.355768] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Switching local interface to 209.182.216.71:20065 [1557513269.376119] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Calling handler for RTCP packet type 201 [1557513269.376149] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: RR from 779d978b about 60b442ee: FL 185 TL 2381849 HSR 1868471658 J 3454737373 LSR 3540730944 DLSR 753951698 [1557513269.376164] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: No payload type known for RTCP RR, discarding [1557513269.967467] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20064]: Confirmed peer address as 174.204.14.29:10523 s[1557513274.064040] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SRTCP output wanted, but no crypto suite was negotiated [1557513274.064063] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513274.064084] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 2043506601 PC 348629863 OC 1509649344 NTP TS 4002640369/1 330623176=4002640369.309810 [1557513274.064090] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 1b7ce7ec: FL 17 TL 10773844 HSR 2006802227 J 3496394774 LSR 1855863287 DLSR 207902258 [1557513274.064105] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SSRC hash table exceeded size limit (trying to add 1b7ce7ec) - deleting SSRC 9fda8 18d [1557513274.064114] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding w[1557513274.337285] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Calling handler for RTCP packet type 200 [1557513274.337341] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SR from 779d978b: RTP TS 3588538011 PC 4113250253 OC 3762757735 NTP TS 3675530209/ 2088363704=3675530209.486235 [1557513274.337352] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: RR from 779d978b about 1904c0d9: FL 190 TL 1277330 HSR 3700606795 J 2076634040 LSR 2826708796 DLSR 3084916091 [1557513274.337367] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SSRC hash table exceeded size limit (trying to add 1904c0d9) - deleting SSRC d4b12 78d [1557513274.337378] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: No payload type known for RTCP RR, discarding itch complete[1557513278.796840] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513278.796890] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 1179546147 PC 253436483 OC 401514196 NTP TS 591585900/307 4094117=591585900.715743 [1557513278.796900] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about f25fab39: FL 196 TL 1861219 HSR 1237831119 J 2726348211 LSR 3841137799 DLSR 843496811 [1557513278.796913] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SSRC hash table exceeded size limit (trying to add f25fab39) - deleting SSRC bb949 38e [1557513278.796921] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513279.310594] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SRTCP output wanted, but no crypto suite was negotiated [1557513279.310626] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Calling handler for RTCP packet type 200 [1557513279.310646] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SR from 779d978b: RTP TS 624630617 PC 1167418798 OC 2870042862 NTP TS 2807429790/9 64181525=2807429790.224491 [1557513279.310652] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: RR from 779d978b about bb84140b: FL 193 TL 5406510 HSR 1470777656 J 207786249 LSR 3684806947 DLSR 307709608 [1557513279.310669] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SSRC hash table exceeded size limit (trying to add bb84140b) - deleting SSRC 3813d 27e [1557513279.310679] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: No payload type known for RTCP RR, discarding [1557513279.678189] ERR: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20064]: SRTP output wanted, but no crypto suite was negotiated [1557513283.537471] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513283.537514] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 1085702245 PC 129819128 OC 1350967259 NTP TS 967851883/21 63508869=967851883.503731 [1557513283.537521] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 169e1507: FL 46 TL 3777017 HSR 3092777669 J 3495001522 LSR 3630093505 DLSR 120738828 [1557513283.537537] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SSRC hash table exceeded size limit (trying to add 169e1507) - deleting SSRC 468fa 6ae [1557513283.537546] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513284.300047] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Calling handler for RTCP packet type 200 [1557513284.300094] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SR from 779d978b: RTP TS 3660274611 PC 3339904092 OC 976632286 NTP TS 3250964209/2 354170892=3250964209.548123 [1557513284.300103] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: RR from 779d978b about a9cab1ac: FL 9 TL 7152183 HSR 1071025251 J 612018816 LSR 12 43749409 DLSR 721434160 [1557513284.300119] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SSRC hash table exceeded size limit (trying to add a9cab1ac) - deleting SSRC e7313 af6 [1557513284.300130] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: No payload type known for RTCP RR, discarding bye [1557513286.941239] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Received command 'delete' from 127.0.0.1:49479 [1557513286.941278] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Dump for 'delete' from 127.0.0.1:49479: { "call-id": "05c7dcfe-06f3-4630-9799-0557b76cc340", "received-from": [ "IP4", "174.204.14.29" ], "from-tag": "c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00", "command": "delete" } [1557513286.941434] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Scheduling deletion of call branch 'c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00' (via-branch '') in 3 0 seconds [1557513286.941444] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: delete time = 0.000152 sec [1557513286.941474] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Replying to 'delete' from 127.0.0.1:49479 [1557513286.941618] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Response dump for 'delete' to 127.0.0.1:49479: { "created": 1557513231, "created_us": 973175, "last signal": 1557513264, "SSRC": { "3046983612": { }, "2450372863": { }, "1622426350": { }, "2930250248": { }, "419741913": { }, "579439031": { }, "136 0672478": { }, "3145995275": { }, "125536563": { }, "2848633260": { }, "3762016578": { }, "379458823": { }, "1552885521": { }, "3078620951": { }, "12997 31210": { }, "461170668": { }, "2009301833": { }, "3253290075": { }, "1198441744": { }, "4066356025": { }, "2006816651": { } }, "tags": { "c71ac9de-9bf5- 4f39-9fda-6bd3aaf97d00": { "tag": "c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00", "created": 1557513231, "in dialogue with": "2684eff8-3602-41ed-aca2-9f7938362462", "me dias": [ { "index": 1, "type": "audio", "protocol": "UDP/TLS/RTP/SAVP", "streams": [ { "local port": 20064, "endpoint": { "family": "IPv4", "address": "174.204. 14.29", "port": 10523 }, "advertised endpoint": { "family": "IPv4", "address": "100.81.62.76", "port": 5079 }, "crypto suite": "AES_CM_128_HMAC_SHA1_80", "last packet": 1557513286, "flags": [ "RTP", "filled", "confirmed", "kernelized", "no kernel support", "DTLS fingerprint verified" ], "SSRC": 2006816651, "stats": { " packets": 595, "bytes": 40090, "errors": 0 } }, { "local port": 20065, "endpoint": { "family": "IPv4", "address": "174.204.14.29", "port": 10496 }, "advertised endpoint": { "family": "IPv4", "address": "100.81.62.76", "port": 5080 }, "crypto suite": "AES_CM_128_HMAC_SHA1_80", "last packet": 1557513284, "flags": [ "RTCP ", "filled", "confirmed", "kernelized", "no kernel support" ], "SSRC": 2006816651, "stats": { "packets": 15, "bytes": 1306, "errors": 0 } } ], "flags": [ "initi alized", "send", "recv", "DTLS-SRTP", "DTLS role passive", "ICE controlling" ] } ] }, "2684eff8-3602-41ed-aca2-9f7938362462": { "tag": "2684eff8-3602-41ed-aca2- 9f7938362462", "created": 1557513231, "in dialogue with": "c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00", "medias": [ { "index": 1, "type": "audio", "protocol": "UDP/TL S/RTP/SAVP", "streams": [ { "local port": 20052, "endpoint": { "family": "IPv4", "address": "97.47.70.223", "port": 4667 }, "advertised endpoint": { "family": " IPv4", "address": "10.255.81.66", "port": 5097 }, "crypto suite": "AES_CM_128_HMAC_SHA1_80", "last packet": 1557513284, "flags": [ "RTP", "filled", "confirmed", "kernelized", "no kernel support", "DTLS fingerprint verified" ], "SSRC": 2009301833, "stats": { "packets": 55, "bytes": 3410, "errors": 0 } }, { "local port": 20053, "endpoint": { "family": "IPv4", "address": "97.47.70.223", "port": 4640 }, "advertised endpoint": { "family": "IPv4", "address": "10.255.81.66", "port": 5098 }, "last packet": 1557513283, "flags": [ "RTCP", "filled", "confirmed", "kernelized", "no kernel support" ], "SSRC": 2009301833, "stats": { "packets": 10, "bytes": 936, "errors": 0 } } ], "flags": [ "initialized", "send", "recv", "DTLS-SRTP", "DTLS role passive" ] } ] } }, "totals": { "RTP": { "packets": 650, "bytes": 43500, "errors": 0 }, "RTCP": { "packets": 25, "bytes": 2242, "errors": 0 } }, "result": "ok" } [1557513287.087244] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513287.087244] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 200 [1557513287.087282] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SR from 77c38349: RTP TS 1725021880 PC 1560319321 OC 3364521432 NTP TS 1121433750/3398500622=1121433750.791275 [1557513287.087290] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 9ba3be3b: FL 18 TL 4080170 HSR 3714308681 J 2085763389 LSR 1453166610 DLSR 3867570679 [1557513287.087303] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SSRC hash table exceeded size limit (trying to add 9ba3be3b) - deleting SSRC 77b8933 [1557513287.087311] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513287.087324] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: Calling handler for RTCP packet type 201 [1557513287.087328] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: RR from 77c38349 about 477b6daa: FL 136 TL 7495912 HSR 3723043622 J 76729872 LSR 791112841 DLSR 2264873880 [1557513287.087332] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: SSRC hash table exceeded size limit (trying to add 477b6daa) - deleting SSRC b7800717 [1557513287.087338] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20053]: No payload type known for RTCP RR, discarding [1557513287.165301] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Calling handler for RTCP packet type 200 [1557513287.165344] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SR from 779d978b: RTP TS 4203649664 PC 1900914033 OC 1842228915 NTP TS 2577169143/1958584749=2577169143.456018 [1557513287.165355] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: RR from 779d978b about 643dc91f: FL 113 TL 8548413 HSR 913668020 J 2977588542 LSR 2353716277 DLSR 1468396047 [1557513287.165370] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SSRC hash table exceeded size limit (trying to add 643dc91f) - deleting SSRC e03bd142 [1557513287.165382] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: No payload type known for RTCP RR, discarding [1557513287.165396] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: Calling handler for RTCP packet type 201 [1557513287.165403] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: RR from 779d978b about 7d2457ab: FL 45 TL 2024736 HSR 174032952 J 3137856066 LSR 2564654212 DLSR 844577710 [1557513287.165410] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: SSRC hash table exceeded size limit (trying to add 7d2457ab) - deleting SSRC 476ec510 [1557513287.165418] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340 port 20065]: No payload type known for RTCP RR, discarding [1557513316.000248] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Call branch 'c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00' (via-branch '') deleted, no more branches remaining [1557513316.000290] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Final packet stats: [1557513316.000297] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: --- Tag '2684eff8-3602-41ed-aca2-9f7938362462', created 1:25 ago for branch '', in dialogue with 'c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00' [1557513316.000308] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: ------ Media #1 (audio over UDP/TLS/RTP/SAVP) using iLBC/8000 [1557513316.000318] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: --------- Port 209.182.216.71:20052 <> 97.47.70.223:4667 , SSRC 77c38349, 55 p, 3410 b, 0 e, 32 ts [1557513316.000325] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: --------- Port 209.182.216.71:20053 <> 97.47.70.223:4640 (RTCP), SSRC 77c38349, 12 p, 1120 b, 0 e, 29 ts [1557513316.000330] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: --- Tag 'c71ac9de-9bf5-4f39-9fda-6bd3aaf97d00', created 1:25 ago for branch '', in dialogue with '2684eff8-3602-41ed-aca2-9f7938362462' [1557513316.000339] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: ------ Media #1 (audio over UDP/TLS/RTP/SAVP) using iLBC/8000 [1557513316.000347] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: --------- Port 209.182.216.71:20064 <> 174.204.14.29:10523, SSRC 779d978b, 595 p, 40090 b, 0 e, 30 ts [1557513316.000355] INFO: [05c7dcfe-06f3-4630-9799-0557b76cc340]: --------- Port 209.182.216.71:20065 <> 174.204.14.29:10496 (RTCP), SSRC 779d978b, 17 p, 1490 b, 0 e, 29 ts [1557513316.000521] DEBUG: [05c7dcfe-06f3-4630-9799-0557b76cc340]: Sending DTLS packet

2 1

DMQ re-ordering concern
by Julien Chavanton 11 May '19

11 May '19

Yesterday at Kamailio World there was an interesting question, raising a concern about replication of user location and DMQ in general, we should track it in the mailing list and use it as a feature request and I can share my initial thoughts on the topic. The concern was about DMQ reordering transactions. With SIP registration this seems like a minor concern, high responsiveness at the cost of potential small inconsistency seems like a good option. Considering that, the state will automatically correct itself and that this can be controlled using the expiration timer. This will become even more insignificant when the replicas can only be used as primary server failover. (it becomes a very small concern only when the primary server fails) With other type of data re-ordering may result in more problematic use cases. My impression is that DMQ should try to be good only with volatile data, data that will expire anyway, like caching with expiration, registration, Dialogs, etc. I think it may be worth looking at adding support for ordering/queuing in DMQ. Performance and simplicity could be maintained by doing mainly transactions in parallel with a configurable re-ordering best effort to minimize the impact of the problem. For example : 1- trying to re-order for a configurable amount of time. (32 seconds to match the RFC for SIP re-transmissions) 2- adding tractability for failed transactions. 3- the possibility to trigger a re-sync. Another option is to look at preserving strict ordering but I can imagine this could add more problems in some cases ...

2 4

Question regarding NAPTR and RURI
by Schneuwly Mathias RUAG 10 May '19

10 May '19

Hi I've a question about NAPTR lockup and rewriting the RURI. Following a little example: - Alice at location A tries to call Bob at location B - location A uses the RURI naptr.locationB.com to reach location B - this NAPTR resolves to hostb.locationB.com and host B is listening on port 5070 hostb has the following alias defined: - udp:hostb.locationB.com:5070 The problem now is, that the incoming RURI is "sip:bob@naptr.locationB.com" and the check to myself is not True. Is there a possibility to rewrite the RURI to the result of the NAPTR query? If I would add a second alias like "udp:naptr.locationB.com:5070" a check to myself would still fail as the RURI does not contain a port. So I would have to add an alias like "udp:naptr.locationB.com" without port, then it would work.? Is this the way to go? Because the documentation says it is important to include the port, otherwise the loose_route() will not work as expected... Thanks for your replies! Mathias

1 0

Help identifying mem leaks
by Duarte Rocha 10 May '19

10 May '19

Greetings, Recently one of my Kamailio's started started answering with a lot of 500 replies to requests because of insufficient private memory. The service Kamailio had been running for 6 months now. In order to solve this i increased the private memory settings and restarted the Kamailio. Before that, when searching a bit about the issue i found an old thread where Daniel suggested using " kamcmd corex.pkg_summary idx 1" to check for pkg leaks in the sip worker process. I ran this before doing the restart in order to identify leaks and found the summary in the logs. However, i am having a hard time interpreting this summary and being able to know if i have or not a mem leak. What should i be looking for? This is the beggining of the summary : qm_status: (0x7ff3c8cef010): qm_status: heap size= 8388608 qm_status: used= 928576, used+overhead=1464080, free=6924528 qm_status: max used (+overhead)= 1488472 qm_status: dumping all alloc'ed. fragments: qm_status: 0. N address=0x7ff3c8d286d8 frag=0x7ff3c8d286a0 size=1024 used=1 qm_status: alloc'd from core: core/str_hash.h: str_hash_alloc(59) qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed qm_status: 1. N address=0x7ff3c8d28b40 frag=0x7ff3c8d28b08 size=256 used=1 qm_status: alloc'd from core: core/str_hash.h: str_hash_alloc(59) qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed qm_status: 2. N address=0x7ff3c8d28ca8 frag=0x7ff3c8d28c70 size=184 used=1 qm_status: alloc'd from core: core/counters.c: cnt_hash_add(332) qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed Any help? Best Regards, Duarte Rocha

1 0

How to configure Kamailio 5.1 with Asterisk pjsip
by przeqpiciel 10 May '19

10 May '19

Hi, There is any working examples how to configure dispatcher module of Kamailio? I have working registrations but working in half dialing function.Signalling are come to asterisk and rtp start sending to my IP but i cant hear anything. Asterisk are doing registrar job - i dont know if it is good idea, maybe not.

5 11

RTP multiplexing, batching and compression (KamailioWorld followup)
by Stefan Sayer 09 May '19

09 May '19

Hi, as a followup to the 5 min 5 slides talk on Tuesday at the Kamailio world conference, I wanted to send links to that implementation, as I did get some interest about this afterwards. This transparent RTP mux gateway implementation in SEMS is a multiplexing, batching and compression mechanism, which can save quite some bandwidth on low bitrate codecs - can be useful if you need to work with very low bitrate links, e.g. on satellite (I tested with 10 G729 calls instead of 5 on a 128kbit sat link). It's a bit like ROHC (RFC3095) but on application level, only for RTP, and by using configuration for IP addresses instead of negotiation. Or as osmux, but without separate negotiation (but in-band), and for all codecs, and SIP. Or iax2 trunking mode, but with normal SIP/RTP. https://github.com/sems-server/sems/blob/sayer/rtp-mux/doc/rtp_mux/rtp_mux_… https://github.com/sems-server/sems/blob/sayer/rtp-mux/doc/rtp_mux/rtp_mux.… For now it's in the sayer/rtp-mux branch, but it's planned to merge it to master, possibly with simplification of the configuration. On another note, many thanks to the organizers of the Kamailio World conference! It's both really nice to meet, and very useful, and I think as well individually as well as for the community as a whole. Best Regards, Stefan

1 0

CRM / Windows integration
by Mark Boyce 09 May '19

09 May '19

Hi All Does anyone have any pointers for integrating Kamailio with CRMs (Dynamics / Salesforce / Zoho) or native Windows? We’re looking for basic click to dial / screen pop. Thanks Mark -- Mark Boyce Dark Origins Ltd

4 5

RE-invite in case of SIP is Active
by Gaurav Bmotra 09 May '19

09 May '19

HI i m gaurav i have installed kamailio 5.1.x on Ubuntu server 18.4 How can i use Re-invite in kamailio if SIP is active so that call can reconnect in case of network loss plz help -- *Regards:* Gaurav Kumar

2 2

Call reconnect in case of loss network
by Gaurav Bmotra 09 May '19

09 May '19

HI i m gaurav i have installed kamailio 5.1.x on Ubuntu server 18.4 when i call from one to another extension , in case of loss network it disconnect the call or stuck there , how can i make it as re-connection when network loss , and it will try to reconnect for some seconds like 30 sec "Example for callingn skype it reconnectcall in case of lossnetwork " plz help -- *Regards:* Gaurav Kumar

1 0

Sending in-dialog requests from custom module's C code
by Ivan Ribakov 09 May '19

09 May '19

I’m working on a custom Kamailio module where I need to send new-dialog and in-dialog requests on timer (hence I’m being forced to generate new messages from C code). So far I’ve been using modules/tm/tm_load.h defined interface to generate messages and handle callbacks. New dialog messages are sent and processed normally. To do that I’m: 1. Calling set_uac_request() to define request parameters 2. Calling tmb.t_request_outside() to send it outside any existing dialog I was able to send in-dialog requests (or so I thought) in a similar fashion, but I soon realised that responses to those requests were dropped because they couldn’t be matched against any known existing transaction. I’m attaching log messages that I believe support this theory and I’ve also observed UDP retransmissions. tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 50576 label 0 branch 0 tm [t_lookup.c:990]: t_reply_matching(): no matching transaction exists tm [t_lookup.c:993]: t_reply_matching(): failure to match a transaction tm [t_lookup.c:1088]: t_check_msg(): msg (0x5abcb50) id=1 global id=1 T end=(nil) tm [t_reply.c:2195]: reply_received(): transaction not found - (branch -1) The way I’m currently generating in-dialog requests is very similar to what tmb.t_request_outside() does, the main difference being that I do the dialog setup manually, based on the call-ID, cseq and from/to tags (I’m tracking transaction identifiers separately) and then pass resulting uac_req_t to tmb.t_request_within() - https://gist.github.com/IvanRibakov/3302cb286b1f4b786d109b406f2435a2 <https://gist.github.com/IvanRibakov/3302cb286b1f4b786d109b406f2435a2> Now, the question part - does anyone know what I’m doing wrong/missing? As I mentioned, when looking at the generated message bodies, they look ok to me (left - initial request that started the dialog, right - first in-dialog request), so I’m guessing I’m missing some Kamailio internal steps needed to register new transaction. SIP flow (up to the point when first UDP retransmission happens) I apologise in advance for the bulky question and will be extremely thankful for any guidance. Regards, Ivan

2 2

GDB debugging Kamailio 5.2.2 IMS authorization failed by the SCSCF
by Woscek, Martin W. 08 May '19

08 May '19

Hi, Looking for some advice running the debugger and setting breakpoints in Kamailio modules such as the SCSCF. Example: We were trying to watch the authenticate() function: 714 int authenticate(struct sip_msg* msg, char* _realm, char* str2, int is_proxy_auth) { Our Kamailio 5.2.2 code was compiled and linked from source with the -g option already enabled by default. We also dropped our Workers to 1 from 16 in the scscf.xml file for the SCSCF to limit the thread count and get the following list of threads below: We tried the first cdp threads: 8462, 8463, and 8464 and while we could set a break point at line 714 for the authenticate() function, it didn't actually break there at all. Question: What pid will we use to catch the authenticate() called during an initial registration from a boghe client? Anything special we may be missing, gdb related or Kamailio settings? kamcmd -s /run/kamailio_scscf/kamailio_ctl kamcmd 1.5 Copyright 2006 iptelorg GmbH This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. kamcmd> ps 8456 main process - attendant 8457 udp receiver child=0 sock=10.0.20.1:6060 8458 slow timer 8459 timer 8460 secondary timer 8461 ctl handler 8462 cdp worker child=0 8463 cdp receiver peer unknown 8464 cdp_receiver_peer=hss522.irisims.org 8465 cdp_acceptor 8466 cdp_timer 8470 notification_worker 8471 notification_worker 8472 notification_worker 8473 notification_worker 8477 JSONRPCS FIFO 8478 JSONRPCS DATAGRAM Any advice appreciated. Thanks, Martin Woscek

2 1

http_client_query module?
by Andrew Chen 08 May '19

08 May '19

Hey guys, Need help here. What module besides tls.so I need to load in order to get http_client_query to work? The module doc says tls.so: #!ifdef WITH_TLS loadmodule "tls.so" #!endif but I keep getting this when doing config check: root@ashmaintpsg51:/etc/kamailio# kamailio -c kamailio.cfg 0(12971) ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <http_client> found 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 322, column 71: Can't set module parameter 0(12971) ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <http_client> found 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 323, column 45: Can't set module parameter 0(12971) ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <http_client> found 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 324, column 42: Can't set module parameter 0(12971) ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <http_client> found 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 325, column 48: Can't set module parameter 0(12971) ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <http_client> found 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 326, column 44: Can't set module parameter 0(12971) ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <http_client> found 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 327, column 71: Can't set module parameter 0(12971) ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <http_client> found 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 328, column 67: Can't set module parameter 0(12971) ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <http_client> found 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 329, column 41: Can't set module parameter 0(12971) ERROR: <core> [core/cfg.y:3309]: yyparse(): cfg. parser: failed to find command http_client_query (params 2) 0(12971) CRITICAL: <core> [core/cfg.y:3449]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 859, column 105: unknown command, missing loadmodule? and I have the package installed on my ubuntu 18.04: ii kamailio-*tls*-modules:amd64 5.1.2-1ubuntu2 amd64 TLS support for the Kamailio SIP server (authentication, transport) thoughts? -- Andy Chen Sr. Telephony Lead Engineer achen@ <achen(a)thinkingphones.com>fuze.com -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

2 3

Udp errors on High Availability Setup
by Duarte Rocha 08 May '19

08 May '19

Greetings, I have two Machines with Kamailio in a High Availability (HA) configuration. Both machines are active and processing calls and both have one HA IP that can jump to the other machine in case of failure. I also have probing for NAPs configured with each IP as the socket. So, in each machine i have this configuration : listen=udp:HA_Address1 listen=udp:HA_Address2 NAP 1 being probed from socket HA_Address1 NAP 1 being probed from socket HA_Address2 I also have /proc/sys/net/ipv4/ip_nonlocal_bind with value 1. Everything works correctly with this configuration. However when the probing is sent for the NAP' my logs get filled with the same error messages. udp_send(): sendto(sock, buf: 0x7f2d4c91fa18, len: 340, 0, dst: (xxx.xxx.xxx.xxx:xxx), tolen: 16) - err: Invalid argument (22) CRITICAL: <core> [core/udp_server.c:602]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net ERROR: tm [../../core/forward.h:219]: msg_send_buffer(): udp_send failed The error happens because it is trying to probe a NAP using a socket that isn't active at the moment in the machine. Is there a way for this error not to be logged or be disabled without reducing Log Level to suppress CRITICAL errors? I think this is a standard High Availability configuration. Is there some setting that can disable this kind of errors? Best Regards, Duarte Rocha

3 5

HELP ME
by khadime gaye 07 May '19

07 May '19

Good morning, How I can resolve this problem ? << ERROR: Could not load the script in /usr/local/lib64/kamailio//kamctl/kamdbctl.mysql for database engine MYSQL ERROR: database engine not loaded - tried 'MYSQL' >>

2 1

implementing custom authentication method
by Walter.Martín Villalba 03 May '19

03 May '19

Dear list, I'm implementing a custom method for user authentication and would like to kindly ask for some guidance regarding the server side changes that may be needed in order to keep things running smoothly. The idea is to replace the standard user/pass-based digest authentication with a custom one based on Open ID Connect (OIDC) access tokens. I already have some pieces working (receiving access token in REGISTER message, validating the token by calling custom python routine, etc.), but I'm missing the bits needed to keep track of users who have successfully authenticated. While looking at sipcomm.cfg I found calls to *www_authenticate* (defined in modules/auth_db/authorize.c), which in turn calls to *mark_authorized_cred*, *check_auth_hr* (or *auth_check_hdr_md5*), and *generate_avps*,. Some of these functions are indeed changing some values in the DB and/or in memory, and this is where I would like some guidance. Is there any documentation I could look at which hopefully explains what DB values and/or data structures in memory need to be updated in order to keep track of successfully authenticated users? I believe with this last piece I'd be able to wrap up my custom authentication implementation. Thanks in advance! Regards, Walter Martín.

1 0

Kamailio bypassing RTP media
by Ali Taher 03 May '19

03 May '19

Hi everyone, I'm new to kamailio. I plan to setup a sip server cluster, Does someone can give me some suggestions if I can use kamailio as front server, which handle sip message and bypass rtp media message to backendserver, this mean the kamailio handle only sip message, the rtp packets are sent directed to backend server. The sip sequences is 1.softswitch send invite to kamailio 2.kamailio send invite to backend server. 3.backend server return 200 ok to kamailio 4.kamailio return 200 ok to softswitch, the ip and port in sip is from the backend server's msg, this make the softswitch send rtp direct to backend server. 5.rtp packets are transfered between softswitch and backend server. .... 6.backend server send bye to kamailio 7.kamailio send bye to softswitch. Any help is appreciated. Regards, Ali Taher

4 5

forcing socket doesn't work for ACK
by David Villasmil 03 May '19

03 May '19

Hello guys, I have public and private IPs, and i need to force the sending socket replying to internal out externals endpoint, so i'm using this: function to check the destination (i tried using $sndto(ip) but it always returns NULL): route[CHECK_DEST_NET] { if ( $du=~"sip:172\..*" ) { setflag(FLAG_TO_PRIVATE); xlog("L_ERR", "[CHECK_SOURCE] Packet going to PRIVATE -> [$du]\n" ); } else { setflag(FLAG_TO_PUBLIC); xlog("L_ERR", "[CHECK_SOURCE] Packet going to PUBLIC -> [$du]\n" ); } return; } on my relay: route(CHECK_DEST_NET); if (isflagset(FLAG_TO_PRIVATE)) { xlog("L_ERR", "[RELAY] forcing socket to PRIVATE NET\n" ); force_send_socket(LISTEN_INSIDE_IF:LISTEN_INSIDE_PORT); } else { xlog("L_ERR", "[RELAY] forcing socket to PUBLIC NET\n" ); force_send_socket(LISTEN_OUTSIDE_IF:LISTEN_OUTSIDE_PORT); } This works nicely, except for ACKs and potentially other packets sent statelessly? Anyone knows how to fix this? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

6 26

run some extra things before relying message
by Mojtaba 02 May '19

02 May '19

Hello, I have encountered with problem in Kamailio. At first glance it looks simple. Considering the Data Lump feature in Kamailio, All changes in SIP body, does not apply quickly. So if we are using RTPEngine or RTPProxy, How we can get body message (Actually IP and port from SDP after rtpengine_manage function) before relaying message? Suppose i want get some information and run some extra things before relying message? I just added my extra things in t_on_reply block, but it's strange why it doesn't work before relaying! -Mojtaba Esfandiari.S

2 2

Problem with topoh
by Phillman25 Kyriacou 02 May '19

02 May '19

Dear List I have an issue with topoh module. Specifically for in-dialog requests, if the encoded uri is altered i.e. initial encoded contact uri is Contact: <sip:X.X.X.X;line=sr-huAWi7oPBYsF.cC0L2lWOUlPwbSWOUl6wURTw24W> and UAS sends an in-dialog INVITE like this adding tgrp and user=phone: INVITE sip:X.X.X.X;line=sr-huAWi7oPBYsF.cC0L2lWOUlPwbSWOUl6wURTw24W;tgrp=1069912311;user=phone Kamailio cant seem to match/decode this and responds "404 Not Found" I have also set: modparam("topoh", "uri_prefix_checks", 0) As specified here: https://www.kamailio.org/docs/modules/4.4.x/modules/topoh.html#idp37582868 But still doesn't work. Is there a bug with this module? # ==================================================== # ================ TOPOLOGY HIDING =================== # ==================================================== modparam("topoh", "mask_key", "secret") modparam("topoh", "mask_ip", "X.X.X.X") modparam("topoh", "mask_callid", 0) modparam("topoh", "uparam_name", "line") modparam("topoh", "uparam_prefix", "sr-") modparam("topoh", "vparam_name", "branch") modparam("topoh", "vparam_prefix", "z9hG4bKsr-") modparam("topoh", "uri_prefix_checks", 0) Thanks in advance for your support Phillip

2 4

Stack smash error when using auth_ephemeral with KEMI
by Grant Bagdasarian 02 May '19

02 May '19

Hello, I was trying out the auth_ephemeral module inside the xhttp event_route in Python KEMI, and discovered a possible bug. https://pastebin.com/4Ghumfis The following will result in the stack smash error. Whenever I leave out the unixtimestamp the module will complain about not being able to convert to an int, which make sense, but doesn't lead to a stack smash error and a complete crash of Kamailio. KSR.auth_ephemeral.autheph_authenticate("1576734089:grant", "1234"). According to the documentation this module can only be used in REQUEST_ROUTE, but I found a presentation online which also used this module and that particular function in event_route, which is what I need for WebSocket authentication. Hope this helps. Please let me know if you need more information. Regards, Grant

2 1

Kamailio 5.2.2 IMS authorization failed by the SCSCF
by Woscek, Martin W. 02 May '19

02 May '19

Hi, We are getting a SIP 401 Unauthorized -Challenging the UE error originating by the SCSCF. It looks to be related to the nonce/cnonce. Is there something we have misconfigured in our SCSCF module? Log output: May 1 14:01:45 imskamailio /usr/local/sbin/kamailio[18489]: DEBUG: ims_auth [authorize.c:786]: authenticate(): Nonce or response missing: nonce len [-108158976], response16 len[1873606560] May 1 14:01:45 imskamailio /usr/local/sbin/kamailio[18492]: DEBUG: ims_auth [utils.c:168]: get_nonce_response(): Calling find_credentials with realm [ims522.irisims.org] May 1 14:01:45 imskamailio /usr/local/sbin/kamailio[18492]: DEBUG: ims_auth [utils.c:195]: get_nonce_response(): Found nonce response May 1 14:01:45 imskamailio /usr/local/sbin/kamailio[18492]: INFO: ims_auth [authorize.c:827]: authenticate(): uri=sip:irisims.org nonce=9863c63855c8dd888c5c18e79fc61156 response=ce7ce73872b92aff2defa76dd1aff1ac qop=auth-int nc=00000001 cnonce=4fe4daacd69fa3d609c8b396d331eae6 hbody=d41d8cd98f00b204e9800998ecf8427e May 1 14:01:45 imskamailio /usr/local/sbin/kamailio[18492]: DEBUG: ims_auth [rfc2617.c:135]: calc_response(): calc_response(_ha1=7a1b479a0513914e71bcd6d005b3e17d, _nonce=9863c63855c8dd888c5c18e79fc61156, _nc=00000001,_cnonce=4fe4daacd69fa3d609c8b396d331eae6, _qop=auth-int, _auth_int=1,_method=REGISTER,_uri=sip:irisims.org,_hentity=d41d8cd98f00b204e9800998ecf8427e) Thanks, Martin

2 1

New voisonics.com - Kamailio related products and services
by David Cunningham 02 May '19

02 May '19

Hello, Usually it's our client's VoIP technology being updated. Fortunately we found a little spare time to completely revamp the Voisonics website as well! https://voisonics.com/ Voisonics provides products and services in the commercial VoIP and hosted PBX sector; in particular relating to Kamailio, Asterisk, and Enswitch. The business has been specialising in this area for almost 10 years. Please feel free to contact me off-list with any questions. Kind regards, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

1 0

Support for JWT token authentication?
by David Dean 01 May '19

01 May '19

I came across this thread from Jan 2015 discussing the addition of JWT token authentication to Kamailio: https://github.com/kamailio/kamailio/issues/29 Was JWT authentication ever added? Or has anyone else on this list got JWT working somehow?

1 0

CSeq not incrementing - app_ruby
by Andrew White 01 May '19

01 May '19

Hi all, I’m still building with app_ruby and loving it - for the most part! I’m having an issue with one of my providers responding with a 482 on auth invite. Researching, it appears that my CSeq isn’t incrementing and this is the reason for the issue. I already have the relevant flag set in my kamailio.cfg however: modparam("dialog", "track_cseq_updates", 1) During my uac_auth, I’ve tried manually setting the diff, as well as running msg_iflag_reset (as suggested by Daniel - https://github.com/kamailio/kamailio/issues/1359 <https://github.com/kamailio/kamailio/issues/1359> - unfortunately the function isn’t exported in KEMI): if KSR::UAC.uac_auth() then KSR.info("UAC authed, relaying") #KSR::COREX.msg_iflag_reset("UAC_AUTH") KSR::PV.sets("$dlg_var(cseq_diff)", "1") KSR.info("CSeq diff: #{KSR::PV.gete("$dlg_var(cseq_diff)")}") KSR::TM.t_relay() Unfortunately in both cases the actual CSeq doesn’t increment in the second INVITE: INVITE 1 (unauthenticated): > CSeq: 102 INVITE INVITE 2 (with Authorization header): > CSeq: 102 INVITE I’m unsure if I’ve missed something silly around the track_cseq_updates flag, or if app_ruby somehow isn’t interacting with the dialog module when running uac_auth to trigger the increment? Thanks! Kind regards, Andrew

3 6

listening at link local IPv6 address
by Juha Heinanen 01 May '19

01 May '19

My K host is behind a mobile WiFi hotspot and I tried to make K listen at the IPv6 address fe80::6e29:95ff:fe7d:37e6/64 that the host has received from the hotspot. Using that address on listen line gives error: Apr 21 08:55:18 salmon /usr/bin/sip-proxy[6887]: ERROR: <core> [core/udp_server.c:395]: udp_init(): bind(8, 0x7ff97dfb3fe4, 28) on FE80:0:0:0:6E29:95FF:FE7D:37E6: Invalid argument Apr 21 08:55:18 salmon /usr/bin/sip-proxy[6887]: ERROR: <core> [core/udp_server.c:401]: udp_init(): might be caused by using a link local address, try site local or global I can ping that address like this: $ ping6 fe80::6e29:95ff:fe7d:37e6%wlp1s0 PING fe80::6e29:95ff:fe7d:37e6%wlp1s0(fe80::6e29:95ff:fe7d:37e6%wlp1s0) 56 data bytes 64 bytes from fe80::6e29:95ff:fe7d:37e6%wlp1s0: icmp_seq=1 ttl=64 time=0.030 ms I then tried to add %wlp1s0 suffix to the listen address, but got error: Apr 21 09:10:35 salmon sip-proxy[7896]: 0(7948) CRITICAL: <core> [core/cfg.y:3510]: yyerror_at(): parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 408, column 34: ip address, interface name or hostname expected Did I do something wrong? If not, why is it that K cannot listen at a link local address? It is something that Linux networking stack does not support? -- Juha

6 33

Pipelimit with clean_unused
by Cinthia Leung 30 Apr '19

30 Apr '19

Hello, What is your recommendation on using clean_unused with db defined pipes? >>pl_check("systemwide"); If I leave the system idle, they are eventually "cleaned" as expected. In our use case, that means failed calls unfortunately. I am trying to see if I can mix both db/static pipes with dynamic/run-time pipes. Thanks Cindy

1 1

Next hop of reply, in onreply_route
by Alex Balashov 30 Apr '19

30 Apr '19

I am fairly sure it’s been asked a number of times, but is there a way to know the destination, and more especially the transport, of the next hop of a reply message, viewable from onreply_route? For requests, we have $nh and many other PVs which in some way evidence where it’s going. And yes, I’m aware that this can be previewed from the onsend_routes*, but I need to amalgamate that knowledge with some transaction-specific data. Thanks! — Sent from mobile, with due apologies for brevity and errors.

2 2

"ERROR: reply too big" and ctl binrpc size
by Karsten Horsmann 30 Apr '19

30 Apr '19

Hi all, i use kamailio 5.0.7 in production and i noticed that i cant listen the dialogs after a few days of traffic on this server. Then i got "kamcmd dlg.list_ctx " - "ERROR: reply too big". So now my question - i want to debug my "sleeping dialogs" with dlg.list - how big should it change the values of without knowing the size of the current filled up binrpc stuff? Or is there a better option to debug dialog-module? modparam("ctl", "binrpc_max_body_size", ??) modparam("ctl", "binrpc_struct_max_body_size", ?) -- Cheers and see you in Berlin *Karsten Horsmann*

2 1

Re: [SR-Users] SIP basic flow question: R-URI in ACK
by Yufei Tao 30 Apr '19

30 Apr '19

Hi Daniel, Thank you very much for clarifying! Cheers, Yufei On 30 Apr 2019 at 08:10, <Daniel-Constantin Mierla <miconda(a)gmail.com>> wrote: Hello, there is an errata for that RFC, but it refers only to the BYE, where it adds back the transport=tcp, but the ACK R-URI should follow the same rules, see: * https://www.rfc-editor.org/errata/eid5294 Cheers, Daniel On 28.04.19 22:54, Yufei Tao wrote: Hi, I have a question regarding basic SIP flow for establishing a call session, and wonder if anyone can help me clarify. For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s R-URI should be a copy of the Contact header of the OK message. However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed the parameters from the Contact header of the OK, e.g. In OK the Contact header is: Contact: <sip:bob@client.biloxi.example.com;transport=tcp> <sip:bob@client.biloxi.example.com;transport=tcp> And ACK the R-URI is: ACK sip:bob@client.biloxi.example.com SIP/2.0 Which has got the parameter ‘transport=tcp’ removed – why is this? In this case if the proxy connected to Bob handles ACK in the usual way as it would for all in-dialog requests, i.e. based on routing headers only and not extra processing, it’ll try to relay the ACK message to Bob using the default transport UDP which is not expected and will fail. Can anyone help explain why the parameters are removed in RFC3665 examples please? Have I missed anything? Thank you very much! Yufei _______________________________________________ Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com

1 0

docker image for non x86 arch
by Sergey Safarov 30 Apr '19

30 Apr '19

Is the community involved in kamailio docker image for ARM architecture and others not x86 platforms? ARM ARM 64 IBM POWER IBM Z PowerPC 64 LE

3 3

SIP basic flow question: R-URI in ACK
by Yufei Tao 30 Apr '19

30 Apr '19

Hi, I have a question regarding basic SIP flow for establishing a call session, and wonder if anyone can help me clarify. For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s R-URI should be a copy of the Contact header of the OK message. However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed the parameters from the Contact header of the OK, e.g. In OK the Contact header is: Contact: <sip:bob@client.biloxi.example.com;transport=tcp> And ACK the R-URI is: ACK sip:bob@client.biloxi.example.com SIP/2.0 Which has got the parameter ‘transport=tcp’ removed – why is this? In this case if the proxy connected to Bob handles ACK in the usual way as it would for all in-dialog requests, i.e. based on routing headers only and not extra processing, it’ll try to relay the ACK message to Bob using the default transport UDP which is not expected and will fail. Can anyone help explain why the parameters are removed in RFC3665 examples please? Have I missed anything? Thank you very much! Yufei

3 2

remove_record_route - bug?
by Sergiu Pojoga 29 Apr '19

29 Apr '19

Hi ppl, After a branch route fails, I need to re-evaluate the next destination and adjust RR parameters, if need be, like for example adjust the nat=yes|priv. failure_route[MANAGE_PSTN_FAILURE] { ... remove_record_route(); record_route(); route(NATMANAGE); ... route(RELAY); } The result is that the new branch is stripped of "Record-Route: <sip:MYIP>", but the params remained. Moreover, record_route hasn't been re-added as instructed in the failure route. Request headers of the initial branch that will eventually timeout and fail: 2019/04/27 18:29:18.034992 10.22.0.1:5060 -> 10.22.0.100:5060 INVITE sip:1514XXXXXXX@10.22.0.100 SIP/2.0 Record-Route: <sip:10.22.0.1;r2=on;lr=on;did=9e2.3dd2;nat=priv> Record-Route: <sip:65.XX.XX.1;r2=on;lr=on;did=9e2.3dd2;nat=priv> New request branch after failure: 2019/04/27 18:29:19.538292 65.XX.XXX.1:5060 -> 65.XX.XX.2:5060 INVITE sip:1514XXXXXXX@65.XX.XX.2 SIP/2.0 ;lr=on;did=9e2.3dd2;nat=priv> kamailio -v version: kamailio 5.1.6 (x86_64/linux) 7d1964 Much obliged. --Sergiu

4 5

Vide SIP conferencing kamailio with freeswitch
by Gaurav Bmotra 28 Apr '19

28 Apr '19

HI i m gaurav i have installed kamailio 5.1.x on Ubuntu server 18.4 i want a solution for video conferencing with kamailio as i am using freeswitch with it is there reference guide for that plz help -- *Regards:* Gaurav Kumar

2 1

Re: [SR-Users] [sr-dev] Vide SIP conferencing kamailio with freeswitch
by Henning Westerholt 28 Apr '19

28 Apr '19

Hello, please ask this usage related questions on our "sr-users" list. Kamailio is not doing much regarding the video calls. E.g. if your calls work for voice with kamailio, they should also work for video. All the setup needs to be done in freeswitch. I found a (outdated) howto with google: https://freeswitch.org/confluence/display/FREESWITCH/FreeSWITCH+1.6+Video Maybe this helps. Henning Am 27.04.19 um 13:22 schrieb Gaurav Bmotra: HI i m gaurav i have installed kamailio 5.1.x on Ubuntu server 18.4 i want a solution for video conferencing with kamailio as i am using freeswitch with it is there reference guide for that plz help _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services

1 0

How to configure ipv6 in kamailio
by Santosh Kumar Dash 28 Apr '19

28 Apr '19

Hi All, I have a kamailio installed in my setup which is working properly in IPV4 configuration. I want to perform IPV6 configuration, I don't have any idea how to configure it, I have tried few things by changing *kamailio.cfg* file but did not work. I am sharing my *kamailio.cfg *file which is working fine in ipv4 Kindly help me to configure for IPV6. lets say my Ipv6 address is : 2402:3a80:d1a:f45a:fe44:2e54:ed2b:9bb2 Thanks,

3 3

Can't set module parameter
by Tmbc 26 Apr '19

26 Apr '19

Hi all Having this issue with kamailio: Can't set module parameter Apr 25 09:57:10 kamailio: ERROR: <core> [core/modparam.c:141]: set_mod_param_regex(): parameter <dst_avp> of type <1> not found in module <dispatcher> Apr 25 09:57:10 kamailio: CRITICAL: <core> [core/cfg.y:3511]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 119, column 50: Can't set module parameter Apr 25 09:57:10 kamailio: ERROR: <core> [core/modparam.c:141]: set_mod_param_regex(): parameter <grp_avp> of type <1> not found in module <dispatcher> Apr 25 09:57:10 kamailio: CRITICAL: <core> [core/cfg.y:3511]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 120, column 50: Can't set module parameter Apr 25 09:57:10 kamailio: ERROR: <core> [core/modparam.c:141]: set_mod_param_regex(): parameter <cnt_avp> of type <1> not found in module <dispatcher> Apr 25 09:57:10 kamailio: CRITICAL: <core> [core/cfg.y:3511]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 121, column 50: Can't set module parameter here is full conf file: https://dpaste.de/bP3E OS: NAME="CentOS Linux" VERSION="7 (Core)" Software version: kamailio 5.2.2 (x86_64/linux) 67f967 Thanks in advance, tmbc

2 1

Re: [SR-Users] Config to control TCP connection reuse
by R, Rajkumar (Raj) 24 Apr '19

24 Apr '19

I think elaborating on the setup may help someone to provide inputs on this. Below is the setup. Client 1 --> Kamailio proxy --> Backend SIP server Client 2 --> Kamailio proxy --> Backend SIP server Client 3 --> Kamailio proxy --> Backend SIP server After I register all three clients, see only one TCP connection is being used between "Kamailio proxy - Backend SIP server". Is there a way to achieve separate TCP connection to Backend SIP server from kamailio. thanks, raj From: R, Rajkumar (Raj) Sent: Monday, April 22, 2019 3:45 PM To: sr-users(a)lists.kamailio.org Subject: Config to control TCP connection reuse Hi, In my setup(kamailio in stateless mode to a backend server), for any number of client registrations kamailio (in stateless mode) is reusing the TCP connection. Let's say if I register 3 different clients through kamailio to my backend server - see only one TCP connection is used, which I do not want. I have gone through the core modules to see if any TCP config param exists to control on this, but couldn't find one. Could anyone help how to achieve different TCP connections to same destination in kamailio? thanks, raj

2 1

DMQ_USRLOC
by Gholamreza Sabery 24 Apr '19

24 Apr '19

Hi, Recently, I started to use dmq_usrloc module. I successfully set it up. Unfortunately, the documentation does not specify the behavior of dmq_usrloc module with other Kamailio modules. For example, I see a bunch of KDMQ messages are exchanged between nodes, but how the lookup() function behaves with dmq_usrloc, or what is it's effect on a db_mode of 3! Regards

5 6

JSON error - control character 0xd
by David Dean 23 Apr '19

23 Apr '19

I'm trying to send an SDP from a SIP client to Janus using JSON over HTTP. The problem is that Janus is erroring on the SDP content with the following error: JANUS HTTP: Get SDP for echo plugin: {#012 "janus": "error",#012 "error": {#012 "code": 454,#012 "reason": "JSON error: on line 9: control character 0xd near '\"v=0'"#012 }#012} Result code 200 I tried using {s.escape.common} to escape any quotations, commas etc but it doesn't appear to replace the control characters with newlines. Any suggestions on how best to remove these control characters so that Janus will accept the SDP over JSON? Here is the relevant section of kamailio.cfg: # HTTP: Request SDP for echo test plugin sdp_get("$avp(sdp)"); $var(res) = http_connect("janus", "/janus/$var(JANUS-ID)/$var(ECHO-ID)", "application/json", "{ \"janus\" : \"message\", \"transaction\" : \"testtesttest99\", \"body\" : { \"audio\" : true }, \"jsep\" : { \"type\" : \"offer\", \"sdp\" : \"$(avp(sdp){s.escape.common})\" }}", "$avp(janus-pluginsession)"); xlog("L_INFO", "JANUS HTTP: Get SDP for echo plugin: $avp(janus-pluginsession) Result code $var(res)\n");

3 6

Direction of replies
by Duarte Rocha 23 Apr '19

23 Apr '19

Greetings, Is there a way to know in reply_route if a reply has direction downstream or upstream regarding the first INVITE? I know there are vars and methods for finding this out on requests, but i can't find anything for replies. Thanks in advance, Best Regards, Duarte Rocha

2 1

CDR start time of a canceled call
by Jan-Hendrik Dörner 23 Apr '19

23 Apr '19

Hello, I just noticed that the logged „start_time" as well as „end_time" of a canceled call is set to the „invite time“. If done this way, it is harder to calculate the „ringing time“. Is there an option to change this behaviour (i.e. to log the time of the received „bye“ instead)? (If done so, the ringing time would always be the time between start and invite …) Or is there a special reason for this behaviour? My CDR settings are as followed: modparam("acc", "cdr_enable", 1) modparam("acc", "cdr_expired_dlg_enable", 1) # log unanswered / open dialogs modparam("acc", "cdr_on_failed", 1) # log also not answered calls modparam("acc", "cdr_extra", "inviteTime=$dlg_var(inviteTime)" modparam("acc", "cdr_log_enable", 1) # activate write to syslog modparam("acc", "cdr_facility", "LOG_LOCAL6") # syslog modparam("acc", "cdr_start_on_confirmed", 1) modparam("acc", "time_mode", 0) #syslog timestamp modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) modparam("acc", "detect_direction", 0) modparam("acc", "log_flag", FLT_ACC) # needed for syslog modparam("acc", "log_missed_flag", FLT_ACCMISSED) # need for logging missed calls in syslog Regards Jan-Hendrik

1 0

Kamailio-5.2.1 - Issues in NDB_MONGODB module initialisation
by José Seabra 22 Apr '19

22 Apr '19

Hello there, I have NDB_MONGODB loaded in kamailio with following configurations: *loadmodule "ndb_mongodb"* *modparam("ndb_mongodb", "server", "name=mgs1;uri='mongodb://mongodbserver:27017/proxyregistrar'")* Kamailio breaks up on start up and prints the following messages: *Apr 18 13:16:10.464 proxy-registrar[-]: DEBUG: <core> [core/modparam.c:83]: set_mod_param_regex(): 'ndb_mongodb' matches module 'ndb_mongodb'* *Apr 18 13:16:10.464 proxy-registrar[-]: DEBUG: <core> [core/sr_module.c:711]: find_param_export(): found <server> in module ndb_mongodb [/usr/lib64/kamailio/modules/ndb_mongodb.so]* *Apr 18 13:16:10.464 proxy-registrar[-]: DEBUG: <core> [core/modparam.c:99]: set_mod_param_regex(): found <server> in module ndb_mongodb [/usr/lib64/kamailio/modules/ndb_mongodb.so]* *Apr 18 13:16:10.464 proxy-registrar[-]: DEBUG: ndb_mongodb [mongodb_client.c:155]: mongodbc_add_server(): added server[mgs1]=mongodb://10.225.121.12:27017/proxyregistrar <http://10.225.121.12:27017/proxyregistrar>* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: DEBUG: <core> [core/sr_module.c:942]: init_mod_child(): idx 21 rank 8: ndb_mongodb [tcp receiver (generic) child=3]* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 23* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: ALERT: <core> [main.c:739]: handle_sigs(): child process 3181 exited by a signal 11* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: ALERT: <core> [main.c:742]: handle_sigs(): core was generated* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: DEBUG: <core> [core/tcp_main.c:3513]: handle_ser_child(): dead child 16, pid 3181 (shutting down?)* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: INFO: <core> [main.c:764]: handle_sigs(): terminating due to SIGCHLD* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa6d0e0, 23, -1, 0x0) fd_no=23 called* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: DEBUG: <core> [main.c:766]: handle_sigs(): terminating due to SIGCHLD* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: INFO: <core> [main.c:819]: sig_usr(): signal 15 received* *123: INFO: <core> [main.c:819]: sig_usr(): signal 15 received* *123: INFO: <core> [main.c:819]: sig_usr(): signal 15 received* *123: INFO: <core> [main.c:819]: sig_usr(): signal 15 received* *123: INFO: <core> [main.c:819]: sig_usr(): signal 15 received* *1a7311e30a6793da-3165(a)10.225.121.93 <1a7311e30a6793da-3165(a)10.225.121.93>: DEBUG: ndb_mongodb [ndb_mongodb_mod.c:128]: mod_destroy(): cleaning up * Core dump back trace output: *(gdb) bt full* *#0 0x00007f3daa134f93 in _mongoc_client_new_from_uri () from /lib64/libmongoc-1.0.so.0* *No symbol table info available.* *#1 0x00007f3daa156553 in mongoc_uri_get_ssl () from /lib64/libmongoc-1.0.so.0* *No symbol table info available.* *#2 0x00007f3daa134f88 in _mongoc_client_new_from_uri () from /lib64/libmongoc-1.0.so.0* *No symbol table info available.* *#3 0x00007f3daa135029 in mongoc_client_new () from /lib64/libmongoc-1.0.so.0* *No symbol table info available.* *#4 0x00007f3daae6d75f in mongodbc_init () at mongodb_client.c:63* * rsrv = 0x7f3db0f86728* * __FUNCTION__ = "mongodbc_init"* *#5 0x00007f3daae73c46 in child_init (rank=3) at ndb_mongodb_mod.c:113* * __FUNCTION__ = "child_init"* *#6 0x00000000005470d7 in init_mod_child (m=0x7f3db0f85e88, rank=3) at core/sr_module.c:846* * __FUNCTION__ = "init_mod_child"* *#7 0x00000000005474b6 in init_child (rank=3) at core/sr_module.c:874* * ret = 32573* *#8 0x00000000004b3840 in fork_process (child_id=3, desc=0x7ffecc20c7f0 "udp receiver child=2 sock=10.225.121.93:5060 <http://10.225.121.93:5060>", make_sock=1) at core/pt.c:341* * pid = 0* * child_process_no = 3* * ret = -1* * new_seed1 = 1273263324* * new_seed2 = 1531871627* * sockfd = {14, 15}* * __FUNCTION__ = "fork_process"* *#9 0x0000000000424b9b in main_loop () at main.c:1631* * i = 2* * pid = 3807* * si = 0x7f3db123a988* * si_desc = "udp receiver child=2 sock=10.225.121.93:5060 <http://10.225.121.93:5060>\000\177\000\000P\310 \314\376\177\000\000\000e|\261=\177\000\000 \313 \314\376\177\000\000\063\225{\000\000\000\000\000\027\000\000\000\000\000\000\000\000\000\000 \000\000\000\000\000\000\200\000\000\000\000\000\217e|\261=\177\000\000`~x\000\000\000\000\000\230\304\022\261=\177\000"* * nrprocs = 4* * woneinit = 1* * __FUNCTION__ = "main_loop"* *#10 0x000000000042c4e9 in main (argc=11, argv=0x7ffecc20cc08) at main.c:2675* * cfg_stream = 0x2893010* * c = -1* * r = 0* * tmp = 0x7ffecc20e6fd ""* * tmp_len = 0* * port = 0* * proto = 2496* * options = 0x7697a0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"* * ret = -1* * seed = 173321635* * rfd = 4* * debug_save = 0* * debug_flag = 0* * dont_fork_cnt = 0* * n_lst = 0x7ffecc20cac0* * p = 0x7f3db177497d <intel_check_word+173> "H\205\300t\025\017\266P\003\017\266\312D9\371\017\204", <incomplete sequence \316>* * st = {st_dev = 19, st_ino = 21919, st_nlink = 2, st_mode = 16832, st_uid = 993, st_gid = 2, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1551179759, tv_nsec = 561093463}, st_mtim = {tv_sec = 1551179759,* *---Type <return> to continue, or q <return> to quit---* * tv_nsec = 561093463}, st_ctim = {tv_sec = 1551179759, tv_nsec = 561093463}, __unused = {0, 0, 0}}* * __FUNCTION__ = "main"* *(gdb)* NDB_MONGODB configuration is pretty simples and currently i'm not making any mongodb operations, i'm just loading the module and trying to connect against mongodb. Any thoughts on this issue? Thank you Best regards -- Cumprimentos José Seabra

2 1

rtpengine_offer() with ICE not updating o= and m= IP addresses
by David Dean 22 Apr '19

22 Apr '19

I'm using the following rtpengine_offer() to force the use of ICE relay and also replace o= and m= rtpengine_offer("replace-origin replace-session-connection ICE=force-relay RTP"); The SDP is being updated to include an ICE relay candidate, but the IP addresses in the o= and m= lines are not changing to the servers IP address (X.X.X.X). I also tried using the media-address parameter but that didn't change the behaviour. When I use rtpengine_answer() then it's not providing an ICE candidate nor changing o= or m=, which I imagine is expected. What am I missing? INVITE from the client (before rtpengine)------------------------------------------------------ INVITE sip:server.domain.com SIP/2.0Via: SIP/2.0/TCP 154.20.1.8:37520;branch=z9hG4bK-1710993570;rportFrom: <sip:username@server.domain.com>;tag=281751229To: <sip:server.domain.com>Contact: <sip:username@154.20.1.8:37520;transport=tcp>Call-ID: c715a8f9-4dd1-38d8-acbd-54153310f59fCSeq: 1756522847 INVITEContent-Type: multipart/mixed;boundary=7efec5a8-3311-0157-fc8b-9af106265507Content-Length: 1506Max-Forwards: 70Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK, UPDATE, REFERPrivacy: noneSupported: 100rel --7efec5a8-3311-0157-fc8b-9af106265507Content-Type: application/sdp v=0o=organization 1983 678901 IN IP4 154.20.1.8s=-c=IN IP4 154.20.1.8t=0 0a=tcap:1 RTP/AVPFm=audio 15418 RTP/AVP 114 115 0 101i=speecha=ptime:20a=minptime:1a=maxptime:255a=silenceSupp:off - - - -a=rtpmap:114 AMR-WB/16000/1a=imageattr:114 octet-align=0a=fmtp:114 octet-align=0a=rtpmap:115 AMR-WB/16000/1a=imageattr:115 octet-align=1a=fmtp:115 octet-align=1a=rtpmap:0 PCMU/8000/1a=rtpmap:101 telephone-event/8000/1a=fmtp:101 0-16a=pcfg:1 t=1a=sendrecva=rtcp-muxa=ssrc:2047236273 cname:e6dcab7948b70d52cd51b75e505c49eba=ssrc:2047236273 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2a=ssrc:2047236273 label:organization@audio INVITE from the server (after rtpengine)------------------------------------------------------ SIP/2.0 200 OKVia: SIP/2.0/TCP 154.20.1.8:37520;branch=z9hG4bK-1710993570;rport=37520;received=2.221.73.230From: <sip:username@server.domain.com>;tag=281751229To: <sip:server.domain.com>;tag=0ea7681ffd64b0ffcde1bff3393fd505.ae3aCall-ID: c715a8f9-4dd1-38d8-acbd-54153310f59fCSeq: 1756522847 INVITEContact: <sip:X.X.X.X:443;transport=tcp>Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK, UPDATE, REFERPrivacy: noneContent-Type: multipart/mixed;boundary=7efec5a8-3311-0157-fc8b-9af106265507Server: kamailio (5.2.2 (x86_64/linux))Content-Length: 1965 --7efec5a8-3311-0157-fc8b-9af106265507Content-Type: application/sdp v=0o=organization 1983 678901 IN IP4 154.20.1.8s=-c=IN IP4 154.20.1.8t=0 0a=tcap:1 RTP/AVPFm=audio 15418 RTP/AVP 114 115 0 101i=speecha=minptime:1a=maxptime:255a=silenceSupp:off - - - -a=imageattr:114 octet-align=0a=imageattr:115 octet-align=1a=pcfg:1 t=1a=rtcp-muxa=ssrc:2047236273 cname:e6dcab7948b70d52cd51b75e505c49eba=ssrc:2047236273 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2a=ssrc:2047236273 label:organization@audioa=rtpmap:114 AMR-WB/16000/1a=rtpmap:115 AMR-WB/16000/1a=rtpmap:0 PCMU/8000/1a=rtpmap:101 telephone-event/8000/1a=fmtp:114 octet-align=0a=fmtp:115 octet-align=1a=fmtp:101 0-16a=sendrecva=ptime:20a=ice-ufrag:kzgbFAnua=ice-pwd:hnEu9EwTrdIZnTWhYbxtmdugvra=candidate:dzkwmPcB28NPHfRA 1 UDP 16777215 X.X.X.X 30366 typ relay raddr X.X.X.X rport 30366a=candidate:dzkwmPcB28NPHfRA 2 UDP 16777214 X.X.X.X 30367 typ relay raddr X.X.X.X rport 30367a=sendrecva=ice-ufrag:uDE9wbvYa=ice-pwd:dx4CcIjqUNFfnRPJEF8GjatXdU

3 3

Config to control TCP connection reuse
by R, Rajkumar (Raj) 22 Apr '19

22 Apr '19

Hi, In my setup(kamailio in stateless mode to a backend server), for any number of client registrations kamailio (in stateless mode) is reusing the TCP connection. Let's say if I register 3 different clients through kamailio to my backend server - see only one TCP connection is used, which I do not want. I have gone through the core modules to see if any TCP config param exists to control on this, but couldn't find one. Could anyone help how to achieve different TCP connections to same destination in kamailio? thanks, raj

1 0

Best tutorial for beginners kamailio
by Gaurav Bmotra 22 Apr '19

22 Apr '19

Hi Plz sujjest best kamailio tutorial or any source where a beginner can start kamailio.. Thanks

2 1

push to talk over cellular application server and related media server implementation
by Thierry Luo 21 Apr '19

21 Apr '19

Hi All, I don't know if this is the appropriate place to ask the following questions: 1. Anyone please recommend open-source implementation of PoC (Push-to-talk Over Cellular) application server? Kamailio can do this? 2. Anyone please recommend open-source implementation of PoC related media server/replicator? Thierry Luo

3 2

Re: [SR-Users] authentication using auth_db
by arish haque 21 Apr '19

21 Apr '19

Hi David, This can solve the issue but depth(records) of that view would be too much. The architecture is like this: One kamailio fronting multiple asterisk. Each of asterisk boxes have their Specific users databases. Thus, I'm trying to create db connections inside request route or completely write my own authentication service if I get the user's Password. So, that would be great if I would be able to pass the db_url to auth_db module in request route. Let me know what you think. Thanks, Arish

2 1

Re: [SR-Users] authentication using auth_db
by arish haque 20 Apr '19

20 Apr '19

Hi David, Thanks for the reply. I checked out sqlops module, this will solve the problem only when I get the authentication password (secret) of the user inside request route. For this I tried checking kamailio pseudovars but haven't found one. Therefore, I am sticking with auth_db module.If this is possible by any other way do let me know. thanks, Arish

2 1

Kamailio, TLS, and LetsEncrypt
by Gaurav Bmotra 19 Apr '19

19 Apr '19

HI this is Gaurav im using kamailio 5.1.2 on ubuntu 18.4 i am trying to configure LetsEncrypt (tls) for kamailio sing following link https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/ but unable to start kamailio ,i m getting these error ------->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Apr 19 11:23:57 ubuntufresh systemd[1]: Starting Kamailio (OpenSER) - the Open Source SIP Server... Apr 19 11:23:58 ubuntufresh kamailio[5365]: INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Apr 19 11:23:58 ubuntufresh kamailio[5365]: INFO: <core> [core/tcp_main.c:4721]: init_tcp(): using epoll_lt as the io watch method (auto detected) Apr 19 11:23:58 ubuntufresh kamailio[5365]: Listening on Apr 19 11:23:58 ubuntufresh kamailio[5365]: Aliases: Apr 19 11:23:58 ubuntufresh kernel: kamailio[5378]: segfault at 0 ip 00007f8d6fdac646 sp 00007ffe8e2337f8 error 4 in libc-2.27.so [7f8d6fcfb000+1e7000] Apr 19 11:23:58 ubuntufresh kamailio[5365]: ERROR: <core> [core/daemonize.c:303]: daemonize(): Main process exited before writing to pipe Apr 19 11:23:58 ubuntufresh systemd[1]: kamailio.service: Control process exited, code=exited status=255 Apr 19 11:23:58 ubuntufresh systemd[1]: kamailio.service: Failed with result 'exit-code'. Apr 19 11:23:58 ubuntufresh systemd[1]: Failed to start Kamailio (OpenSER) - the Open Source SIP Server. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<------------------------------------ plz help -- *Regards:* Gaurav Kumar

3 5

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