- sr-users - kamailio.org

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

31 Mar '23

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

3 2

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

30 Mar '23

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

4 6

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

28 Mar '23

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

2 2

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

28 Mar '23

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

4 3

json RPC syntax
by Volker Denneberg 28 Mar '23

28 Mar '23

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

5 6

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

27 Mar '23

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

2 2

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

27 Mar '23

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

2 1

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

25 Mar '23

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

2 3

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

24 Mar '23

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

3 3

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

24 Mar '23

Hi List Cisco-SPA112 does reply to an invite containing Record-Route header with one Route: Header containing a comma separated list of those hops. It looks like kamailio fails to parse them and correctly route for example an ACK to a 200 OK. Is this a known issue? Is there a solution? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 2

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

23 Mar '23

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

4 7

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

23 Mar '23

Hi All I would like to avoid having run away calls as good as possible. For this, I would like to require timers and set the maximum expires timer to say 1800 I had a look at the sst module, but I see no way to require timers or to set a max timers value. Do my intentions make sense? How did others accomplish this task? Thanks for any hints! Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

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

22 Mar '23

Hello, we have faced an issue which appears when TOPOH module is enabled, call is made from WebRTC client, then transferred by callee. We have WebRTC client behind load balancer. We make call to softphone from WebRTC, call from softphone is transferred to external number using Asterisk. When call is hanged up on external number side, it doesn't hangs up on WebRTC client side. If TOPOH is not enabled, this issue doesn't occur. We have the following TOPOH-related sections of kamailio.cfg: <...> #!ifdef WITH_TOPOH loadmodule "topoh.so" #!endif <...> <...> #!ifdef WITH_TOPOH modparam("topoh", "mask_key", "xxxxxxxxxxxxxxxx") modparam("topoh", "mask_ip", "10.0.0.1") modparam("topoh", "mask_callid", 0) modparam("topoh", "sanity_checks", 1) modparam("topoh", "uparam_prefix", "") modparam("topoh", "vparam_prefix", "") modparam("topoh", "callid_prefix", "1337") #!endif <...> <...> #!ifdef WITH_DIALOG modparam("dialog", "db_url", DBURL) modparam("dialog", "db_mode", 1) modparam("dialog", "db_fetch_rows", 800) modparam("dialog", "track_cseq_updates", 1) modparam("dialog", "ka_interval", 30) modparam("dialog", "ka_timer", 30) modparam("dialog", "send_bye", 0) modparam("dialog", "dlg_filter_mode", 1) #!ifdef WITH_TOPOH modparam("dialog", "lreq_callee_headers", "TH: dlh\r\n") #!endif #!endif <...> <...> #!ifdef WITH_DISPATCHER event_route[dispatcher:dst-up] { sql_query("ds_dburl", "select description from dispatcher where destination='$ru'", "ds_dbresult"); xlog("L_WARN", "Destination up: $ru, found name: $dbr(ds_dbresult=>[0,0])\n"); prom_gauge_set("trunk_reachability", "1", "$ru", "$dbr(ds_dbresult=>[0,0])"); } event_route[dispatcher:dst-down] { sql_query("ds_dburl", "select description from dispatcher where destination='$ru'", "ds_dbresult"); xlog("L_WARN", "Destination down: $ru, found name: $dbr(ds_dbresult=>[0,0])\n"); prom_gauge_set("trunk_reachability", "0", "$ru", "$dbr(ds_dbresult=>[0,0])"); } #!endif #!ifdef WITH_TOPOH event_route[topoh:msg-sending] { if(is_reply() and $rs=="302") { drop; } } #!endif (can provide the full config, if needed) We are receiving the following errors: On transfer: https://pastebin.com/H3FQ4Kpj On hangup from external number side: https://pastebin.com/wgfRzGbd On hangup from WebRTC client side: https://pastebin.com/sE0yhBae There are also differences in SIP traffic when TOPOH is disabled and when it is enabled. With TOPOH enabled, apparently, ACK from Asterisk is not reaching kamailio: asterisk INVITE -> kamailio -> WebRTC WebRTC 200 -> kamailio -> asterisk asterisk ACK -> kamailio -> -> -> (SIP flows attached - topoh_on.csv, topoh_off.csv) kamailio -v version: kamailio 5.6.1 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 09:11:15 Nov 15 2022 with gcc 9.3.0 We have dockerized kamailio running on Ubuntu 16.04.3 LTS Docker version 18.03.1-ce, build 9ee9f40 Please advise where to start looking.

1 0

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

21 Mar '23

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

7 8

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

18 Mar '23

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

1 0

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

17 Mar '23

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

4 4

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

17 Mar '23

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

2 1

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

16 Mar '23

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

2 1

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

16 Mar '23

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

1 0

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

16 Mar '23

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

3 8

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

16 Mar '23

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

2 1

webrtc audio issue
by Arun K R 15 Mar '23

15 Mar '23

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

2 1

Dispatcher behavior
by Jawaid Bazyar 15 Mar '23

15 Mar '23

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

5 14

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

15 Mar '23

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

1 0

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

15 Mar '23

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

2 1

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