sr-users March 2023

sr-users@lists.kamailio.org

47 participants
69 discussions

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

17 Mar '23

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

4 4

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

17 Mar '23

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

2 1

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

16 Mar '23

Hi We have two registrars. Today I observed a CPE doing this: CPE REGISTER (no auth) => Registrar 1 => 407 Challenge NONCE A CPE REGISTER (auth to NONCE A => Registrar 2 => 407 Challenge NONCE B CPE REGISTER (auth to NONCE B => Registrar 1 => 407 Challenge NONCE A and so on. Time on both registrars is in sync (I tought NONCE was based on time) Is there a way to sync the NONCE so that both would accept authentication based on the same NONCE? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 1

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

16 Mar '23

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

1 0

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

16 Mar '23

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

3 8

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

16 Mar '23

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

2 1

webrtc audio issue
by Arun K R 15 Mar '23

15 Mar '23

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

2 1

Dispatcher behavior
by Jawaid Bazyar 15 Mar '23

15 Mar '23

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

5 14

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

15 Mar '23

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

1 0

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

15 Mar '23

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

2 1

2026

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 March 2023