- sr-users - kamailio.org

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

14 Apr '23

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

3 2

manipulate Authentication header
by David Villasmil 13 Apr '23

13 Apr '23

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

2 1

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

11 Apr '23

Hi I still have odd behaviour with the SST module: modparam("sst", "min_se", 300) if (sstCheckMin("1")) { xlog("L_ERR", "$cfg(route) Session Timer too small\n"); exit; } setflag(FLT_DLG); # set the dialog flag setflag(FLT_SST); # Set the sst flag if(is_present_hf("Session-Expires")) { $avp(dlgtimeout) = $(hdr(Session-Expires){s.int}); } On an INVITE containing those header: Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: 100rel,timer Expires: 330 Now Kamailio replies: SIP/2.0 422 Session Timer Too Small Min-SE: 300 What am I doing wrong? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

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

10 Apr '23

Happy Eastern Kamailio 5.4 used. On dialogues calls, I noticed this happening on the second re-invite to refresh the session from the B side. dlg_onroute(): unable to find dialog for INVITE with route param 'df9.da75' [2557:22445] and call-id '14148a68-f1b2-485d-b5a2-f9dd7773d2c0' The did df9.da75 is identical to the one in the route-header on the first re-invite from the B side, before this one. No CDR was (yet) generated, and the dialogues is still present and on-going according to the database: CallID [14148a68-f1b2-485d-b5a2-f9dd7773d2c0] H-Entry: 2557 H-ID: 22445 But most probably not in memory as kamcmd dlg.stat_active shows zero (this is on a development node, so no other calls running). There are no sip messages that end the call in between those two re-invites. I see no session timeouts or similar in the logs. Any hint what could cause Kamailio not to find the corresponding dialogue on this re-invite? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 2

Fwd: Kamailio + PostgreSQL
by Stefan 07 Apr '23

07 Apr '23

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

2 2

Malformed To Header
by Serdar GUCLUER 06 Apr '23

06 Apr '23

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

6 11

Presence module and privacy
by Ihor Olkhovskyi 06 Apr '23

06 Apr '23

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

2 2

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

06 Apr '23

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

1 0

Repository for modules
by Duarte Rocha 06 Apr '23

06 Apr '23

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

2 2

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

06 Apr '23

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

2 3

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

05 Apr '23

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

3 2

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

05 Apr '23

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

3 2

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

04 Apr '23

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

2 2

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

03 Apr '23

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

5 7

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

02 Apr '23

Hi Running Kamailio Registrar Node + rtpengine without dialog module, only TRX module. Situation: Some customer are in ranges to which RTP can directly be routed, some are not. So rtpengine shall be engaged only when backhauling of the rtp stream is required. On a message from a CPE, this is done by checking $si and on a message to the CPE by checking $(ulc(aor=>addr)[$T_branch_idx]{uri.host}); On a BYE, rtpengine_delete() is called no matter if RTP was backhauled or not. If rtpengine does not find the call to delete, no harm happens. But now I struggle with Session Refresh Re-Invites TO the CPE as they are routed very early on and do not pass the whole location lookup stuff, therefore I have no access to the aor=>addr to determine if the destination needs backhauling or not. So the obvious solution which came to my mind is to call rtpengine_query() and see if it is finding the call and if so, call rtpengine_manage() to keep backhauling traffic on the Re-Invites refrreshing the session. Unfortunately, I found no way to check if rtpengine_query finds the call. Did I miss something? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 1

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

01 Apr '23

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

2 1

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

31 Mar '23

Hi all For rtpengine to correctly distinguish branched calls, the top-most via branch= parameter should be passed to it. I have attempted to use $via0 but that does not yet exist in Kamailio 5.4 So I did try to read $hdr(Via) which I guess returns an array and then access: but this returns the inbound via, not the one generated on the branched call. How can this be accomplished with kamailio 5.4? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 1

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

31 Mar '23

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

3 2

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

30 Mar '23

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

4 6

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

28 Mar '23

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

2 2

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

28 Mar '23

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

4 3

json RPC syntax
by Volker Denneberg 28 Mar '23

28 Mar '23

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

5 6

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

27 Mar '23

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

2 2

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

27 Mar '23

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

2 1

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

25 Mar '23

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

2 3

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

24 Mar '23

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

3 3

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

24 Mar '23

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

2 2

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

23 Mar '23

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

4 7

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

23 Mar '23

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

1 0

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

22 Mar '23

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

1 0

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

21 Mar '23

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

7 8

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

18 Mar '23

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

1 0

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

17 Mar '23

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

4 4

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

17 Mar '23

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

2 1

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

16 Mar '23

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

2 1

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

16 Mar '23

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

1 0

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

16 Mar '23

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

3 8

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

16 Mar '23

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

2 1

webrtc audio issue
by Arun K R 15 Mar '23

15 Mar '23

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

2 1

Dispatcher behavior
by Jawaid Bazyar 15 Mar '23

15 Mar '23

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

5 14

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

15 Mar '23

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

1 0

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

15 Mar '23

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

2 1

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

15 Mar '23

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

3 3

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

14 Mar '23

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

1 0

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

14 Mar '23

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

1 0

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

14 Mar '23

1 0

Dispatcher Incoming
by nutxase 14 Mar '23

14 Mar '23

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

5 18

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

14 Mar '23

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

2 7

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

13 Mar '23

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

1 0

(no subject)
by gui 10 Mar '23

10 Mar '23

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

3 4

use_dns_failover and dispatcher
by Lars Jansson 10 Mar '23

10 Mar '23

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

1 0

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

10 Mar '23

Hi CPE registering with TCP (or TLS). 2nd leg is UDP. Within one transaction (INVITE to OK including all ACK and PRACK) transport is kept as desired for both legs. But when the B side disconnects (sending BYE, new reverse transaction), this is sent via UDP to the A CPE which initially talked TCP and thus ignored. record_route() is called on each leg. What could I be missing? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

4 6

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

10 Mar '23

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

3 2

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

10 Mar '23

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

2 1

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

10 Mar '23

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

2 1

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

10 Mar '23

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

4 21

WebRTC Error
by Social Boh 09 Mar '23

09 Mar '23

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

1 1

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

09 Mar '23

Hi List CPE behind Firewall, registering to Kamailio via TCP (or TLS). When a call is sent to the CPE, kamailio attemts to open a new TCP connection and is blocked by Firewall. Is there an option to tell kamailio to use the existing registered TCP connection? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 2

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

09 Mar '23

1 0

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

08 Mar '23

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

1 0

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

08 Mar '23

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

1 0

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

07 Mar '23

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

2 4

Info: Kamailio World 2023 - Announcing First Group Of Speakers
by Daniel-Constantin Mierla 06 Mar '23

06 Mar '23

Hello, it's now like 3 months till the start of the next Kamailio World Conference (taking place in Berlin, Germany, during June 5-8, 2023) and the first group of speakers has just been published, the details are available at: - https://www.kamailioworld.com/k2023/speakers/ Not all proposals were reviewed and Call for Speakers is still open, therefore if you want to share your interesting experiences or knowledge in the RTC space, submit it via: - https://www.kamailioworld.com/k2023/call-for-speakers/ All together, expect another edition of Kamailio World conference with great content covering topics such as RTC scalability, security, cloud-based deployments and elasticity, NG112/911, IoT, WebRTC, VoLTE and 4G/5G. Looking forward to meeting many of you in Berlin! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 0

Remove silo extra_hdrs before store
by Dr. Barabás Péter 06 Mar '23

06 Mar '23

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

1 0

How to access rtpengine rtcp-metrics?
by Benoit Panizzon 06 Mar '23

06 Mar '23

Hi all I'm trying to incorporate rtcp data from rtpengine into our CDRS. So trying with the first interesting value, the average mos. modparam("rtpengine", "mos_average_pv", "$avp(mos_average)") If I understood right, to get this variable set, I need to call rtpengine_manage() on the message that terminates the call. So on an established call, that is either BYE or the 200 OK to the BYE. Right? if ($rm == "BYE") { rtpengine_manage(); xlog("L_INFO", "$cfg(route): $rm: MOSS: $avp(mos_average)\n"); } onreply_route[MANAGE_REPLY] { [...] rtpengine_manage(); xlog("L_INFO", "$cfg(route): $rm reply MOS: $avp(mos_average)\n"); } Messages pass those blocks, $avp(mos_average) is 'null' no mater what. What am I missing? In the syslog output of rtpengine I see there is rtcp data. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 2

tcp_set_connection_lifetime => in respect to 'idle' connection?
by Benoit Panizzon 06 Mar '23

06 Mar '23

Hi List Digging further into my tcp/tls issues... Upon successful authentication I call: tcp_keepalive_enable("60", "5", "5"); tcp_set_connection_lifetime("120"); I tought, this would do to keep the connection alive. I noticed, despite keepalive packets being exchanged, kamailio is closing the connection after a bit more than 2 minutes. I am right at assuming, that tcp_set_connection_lifetime is not related to how long the connection is idle, but is counted from the SYN, no matter if keepalives were successfully exchanged? Does calling tcp_set_connection_lifetime() again restart the lifetime like for 2 more minutes like in this example? Or would I have to keep increase the value of the lifetime on each successful re-register to keep it open? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

Kamailio v5.6.3 Released
by Daniel-Constantin Mierla 05 Mar '23

05 Mar '23

Hello, Kamailio SIP Server v5.6.3 stable release is out. This is a maintenance release of the latest stable branch, 5.6, that includes fixes since the release of v5.6.2. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.6.x. Deployments running previous v5.6.x versions are strongly recommended to be upgraded to v5.6.3. For more details about version 5.6.3 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/01/kamailio-v5-6-3-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

5 10

Kamailio v5.5.6 Released
by Daniel-Constantin Mierla 02 Mar '23

02 Mar '23

Hello, Kamailio SIP Server v5.5.6 stable release is out. This is a maintenance release of the stable branch 5.5 that includes fixes since the release of v5.5.5. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.5.x. Deployments running previous v5.5.x versions are strongly recommended to be upgraded to v5.5.6. Note that 5.5 is the second last stable branch, still officially maintained by Kamailio development team. The latest stable branch is 5.6, with v5.6.4 being release out of it. For more details about version 5.5.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/03/kamailio-v5-5-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 0

Releasing Kamailio v5.5.6
by Daniel-Constantin Mierla 02 Mar '23

02 Mar '23

Hello, I am considering to release Kamailio v5.5.6 soon, branch on branch 5.5, likely on Thursday or Wednesday next week (Mar 2/3, 2023). This is the usual heads up notification to see if anyone is aware of issues not yet reported to bug tracker and if yes, do it as soon as possible to give them a chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 1

Websocket closing
by David Villasmil 01 Mar '23

01 Mar '23

Hello guys, We're seeing corner cases where the following happens: On proxy-ws - IP1:PORT1 connects via websocket from Client1 - Registration happens on an upstream kamailio - for any reason, the TCP socket closes or times out. - IP1:PORT1 (same IP:PORT combination) connects via websocket from Client2 - Registration happens on an upstream kamailio Now a call comes in to Client1. Because the first connection was never cleaned up, it is sent to the proxy-ws and the proxy will send it to the IP1:PORT1 where Client2 is connected. Short story, proxy-ws doesn't check the IP1:PORT1 where it is sending the INVITE is the actual client it is supposed to be sending... It seems that when a socket is closed, the mapping IP:PORT to Address (i.e.: sip:d4f27e34@994f31243be9.invalid;transport=ws) doesn't seem to be cleared... is this by design? Thanks! Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

3 6

Kamailio stops processing the calls - restart fixes it.
by Muhammad Danish Moosa 01 Mar '23

01 Mar '23

Hi, I have a very simple proxy (stateful) where kamailio acts as a proxy between 2 endpoints. Everything works fine for weeks and suddenly I see kamailio stops responding. From pcap I can see kamailio is not proxying the session progress and bombarding invites to one endpoint without any reason. Even that invite was stripped on the Body part. Restarting kamailio fixes it immediately. Unfortunately I could not take bt full yet. Version is kamailio 5.5.3 (x86_64/linux) 473cef configuration is very simple , routing is based on tm.t_relay ( based on KEMI). Any help will be welcome. Danish -- Muhammad Danish Moosa

3 5

Kamailio v5.6.4 Released
by Daniel-Constantin Mierla 27 Feb '23

27 Feb '23

Hello, Kamailio SIP Server v5.6.4 stable release is out. This is a maintenance release of the latest stable branch, 5.6, that includes fixes since the release of v5.6.3. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.6.x. Deployments running previous v5.6.x versions are strongly recommended to be upgraded to v5.6.4. For more details about version 5.6.4 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/02/kamailio-v5-6-4-released/ RPM, Debian/Ubuntu packages will be available soon as well. An additional note to say that call for speakers and registration for Kamailio World Conference 2023 are now open, more details at: * https://www.kamailioworld.com Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 0

Kamailio MS Teams TLS Issue
by iliusha.md＠gmail.com 27 Feb '23

27 Feb '23

Hello, We have one Kamailio Instance connected with MS Teams (based on this instruction: https://skalatan.de/en/blog/kamailio-sbc-teams), which worked fine for a while until recently we noticed that calls from teams are not working anymore. When I looked through the logs I found that Microsoft cannot establish a TLS connection to our server because of the cipher: TLS accept:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (sni: sbc.example.com - domain is obfuscated). Certificate is valid, the configuration is below: [server:default] method = TLSv1.2+ verify_certificate = no require_certificate = no private_key = /usr/local/etc/kamailio/certs/example.net/sbc1-teams_example_net.key certificate = /usr/local/etc/kamailio/certs/example.net/sbc1-teams_example_net.crt server_name = sbc1-teams.example.net ca_list = /usr/local/etc/kamailio/certs/sectigo_ca.pem #ca_list=/etc/ssl/certs/ca-bundle.crt [client:default] method = TLSv1.2+ verify_certificate = no require_certificate = no private_key = /usr/local/etc/kamailio/certs/example.net/sbc1-teams_example_net.key certificate = /usr/local/etc/kamailio/certs/example.net/sbc1-teams_example_net.crt ca_list = /usr/local/etc/kamailio/certs/sectigo_ca.pem #ca_list=/etc/ssl/certs/ca-bundle.crt We use a certificate from Sectigo, but I've tried with Let's Encrypt - and it's the same. Any idea what could be the reason?

5 7

Releasing v5.6.4
by Daniel-Constantin Mierla 27 Feb '23

27 Feb '23

Hello, I am considering to release Kamailio v5.6.4 (out of branch 5.6) next week (likely on Monday or Tuesday, Feb 27/28, 2023). If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

1 1

Kamailio RPC configuration
by sadik.oualla.mohamed＠gmail.com 24 Feb '23

24 Feb '23

Dear Kamailio community, I am a newbie in Kamailio and I am currently working on a project that involves communicating with Kamailio using Python. I have been exploring the Kamailio documentation and I have come across RPC, JSONRPCS..., which I believe can help me achieve my goal. However, I am not sure about the steps to follow in the Kamailio configuration file to create my own script to communicate with Kamailio using Python (the script is on an other machine on the same LAN). I would be grateful if someone could guide me through the process. I have already set up Kamailio (builed it from the source code 5.5.5) and Python on my machines and I have basic knowledge of Kamailio configuration. I just need some guidance on how to set up the RPC module in Kamailio and how to create a Python script to communicate with it. I found that I can use RPyC library of python. I would appreciate any help or suggestions from the Kamailio community. Thank you in advance for your time and assistance. Best regards, Wild Coder.

2 1

OT: MS Teams source IP address ranges
by Jon Bonilla (Manwe) 24 Feb '23

24 Feb '23

Hi Sorry for the OT but I think here's the place where I an find a lot of Ms teams integrations I've been working on MS teams direct routing integration for PekePBX. It works. I guess I've done it as everybody else, using Henning's guide as base and extending it for multitenant setup (thanks Henning!) What I've realized is that the source IP address of calls coming from MS are not always matching dispatcher hosts. Sometimes they come from another source IP and failover to the dispatcher hosts when they receive no response. That makes some of the calls to have an additional latency Searching in the MS doc I see that they document these nets as source of their signaling: 52.112.0.0/14 52.120.0.0/14 But I've seen IP addresses outside of this range as source. In this blog https://erwinbierens.com/microsoft-teams-direct-routing-ip-addresses/ The ranges are listed as 52.112.0.0/16 52.113.0.0/16 52.114.0.0/16 52.115.0.0/16 52.120.0.0/16 52.121.0.0/16 52.122.0.0/16 52.123.0.0/16 which looks better but scares me out. Having no auth is it secure to bind so many ranges to MS? Do you use anything else than certificate verification for these calls? cheers, Jon -- PekePBX, the multitenant PBX solution https://pekepbx.com

4 6

Dispatcher failover when SRV failover is on?
by Jon Bonilla (Manwe) 23 Feb '23

23 Feb '23

Hi Again, fighting with MS Teams but this time it's a kamailio question. I have MSteams hosts in the dispatcher for OPTIONS and for destination. Acording to MS you need to try sip.pstnhub.foo then sip2.pstnhub.foo and sip3.pstnhub.foo 2 | sip:sip.pstnhub.microsoft.com;transport=tls | 0 | 1 2 | sip:sip2.pstnhub.microsoft.com;transport=tls | 0 | 2 2 | sip:sip3.pstnhub.microsoft.com;transport=tls | 0 | 3 I was going to implement dispatcher failover as usual ds_select_domain (alg 8) with failure routes but checking the SRV of the first domain I see it already includes 4 hosts: host -t srv _sips._tcp.sip.pstnhub.microsoft.com _sips._tcp.sip.pstnhub.microsoft.com has SRV record 10 0 5061 sip.pstnhub.microsoft.com. _sips._tcp.sip.pstnhub.microsoft.com has SRV record 20 0 5061 sip2.pstnhub.microsoft.com. _sips._tcp.sip.pstnhub.microsoft.com has SRV record 30 0 5061 sip3.pstnhub.microsoft.com. _sips._tcp.sip.pstnhub.microsoft.com has SRV record 40 0 5061 sip4.pstnhub.microsoft.com. So... If I have dns srv failover enabled in kamailio... what would be the point of the dispatcher failover? In case I only want failover in case 408 or 5XX wouldn't the tm module do it for me? cheers, Jon -- PekePBX, the multitenant PBX solution https://pekepbx.com

3 2

What does l_username in UAC do?
by Дилян Палаузов 23 Feb '23

23 Feb '23

Hello, the uac module-registrations have the fields l_uuid - user for Contact: in REGISTER (before @). Described at https://kamailio.org/docs/db-tables/kamailio-db-5.6.x.html#idm9037 as “Local unique id used to build and match contact addresses.”. Described at https://www.kamailio.org/docs/modules/devel/modules/uac#idm700 as “local unique user id, e.g.,: 12345678” l_username - Described at https://kamailio.org/docs/db-tables/kamailio-db-5.6.x.html#idm9037 as “Local username”. Described at https://www.kamailio.org/docs/modules/devel/modules/uac#idm700 as “local user name, e.g.,: test ”. For me there is no difference between “local unique id” (as for l_uuid) and “local username“ (here). l_domain - used for Contact: in REGISTER (after @), described at https://kamailio.org/docs/db-tables/kamailio-db-5.6.x.html#idm9037 as “local domain” When is l_username used, what is it purpose? Does it solely serve as possible filter criterion for the RPC commands: uac.reg_info l_username abc uac.reg_enable l_username abc uac.reg_disable l_username abc, and uac.reg_unregister l_username abc Do I see correctly, that via UAC-RPC an unREGISTER can be triggered, but there is no way to trigger a REGISTER over UAC-RPC? Thanks for the clarifications Дилян

2 2

change default 477 response code per case
by Patrick Karton 22 Feb '23

22 Feb '23

Hello , i would like to know if there is a way to change the default 477 response code generated by kamailio in some cases. for example if kamalio generates 477 because its not able to reach a peer i would like to change it to another code before to forward it. Thanks.

2 1

Call History
by Anthony Wittig 21 Feb '23

21 Feb '23

Hello, I'd like to start tracking a call history/log as soon as I receive a call. I'd like the customer to be able to see that there's an incoming call to one of their numbers in real time. I'm thinking of using the RABBITMQ Module to manually emit an event from my main route when I receive an INVITE. Is that a bad idea? What if the broker isn't located on the same host (latency/availability)? I don't want to negatively affect the call processing. I was looking at the Dialog Module and it has three event routes: * event_route[dialog:start] * event_route[dialog:end] * event_route[dialog:failed] It's really close to what I want, but I'd like to capture the dialog before it starts (Unconfirmed or Early). Maybe another option is to scan the Dialog table with an external process and emit events from there. Has anyone had success in creating a realtime call history? Is there a better way to go about doing so? Thanks! -- Anthony Wittig Mango Voice Developer

7 7

Info: Registration to Kamailio World 2023 is open!
by Daniel-Constantin Mierla 21 Feb '23

21 Feb '23

Hello, a quick note to the community forums to announce that the registration for the next Kamailio World Conference (June 5-7, 2022, in Berlin, Germany) is now open! The event returns to an in-person conference format, at the same wonderful location in the city center of Berlin! More details are available at: * https://www.kamailioworld.com/k2023/registration/ Call for presentations is also open, there is already a group of very interesting submissions, we aim to publish details about them in the near future. Looking forward to meeting many of you in Berlin! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

2 2

topos breaking route set on hairpin calls?
by Benoît Panizzon 20 Feb '23

20 Feb '23

Hi Having this situation while elaborating topos in lab. * Kamailio Registration Instance with topos enabled where customers are registered. * Kamailio Core Instance with Dialogue enabled and handling interconnections. Calls in transit from customer to IC work flawlessly, topos does what it should, hides and restores headers needed on the core. But I have run into an issue with customer calling another customer on same registrar instance. To generate a CDR with diaglogue and for decision where to route the calls to (registrar is kept simple and only handles registrations and locations), those calls are also routed via core. This works as long as PRACK is disabled. When PRACK is enabled and CPE B is requesting 100rel, the PRACK send from CPE A has no route set (it was removed by topos). Therefore the PRACK only makes it to the core who then does not know where to route that PRACK. It looks like topos on the REG only restores ONE Route pointing to the core (maybe because the 2nd one pointed to itself?) header when restoring them. I have attempted to spam more record_route() here and there in the config of the core and the registrar to try to force creation of route headers, but failed. Is this a known limitation of using topos? -- 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 4

Re: OT: MS Teams source IP address ranges
by Henning Westerholt 20 Feb '23

20 Feb '23

Hi Jon, you could of course try to add some heuristic, in the end the used IPs are a smaller sub-set. But to just quote from the official docs, it seems to be pretty clear: "You need to open ports for all these IP address ranges in your firewall to allow incoming and outgoing traffic to and from the addresses for signaling." Cheers, Henning ________________________________ From: Jon Bonilla (Manwe) Sent: Monday, February 20, 2023 15:49 To: Henning Westerholt; Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] OT: MS Teams source IP address ranges El Mon, 20 Feb 2023 13:06:30 +0000 Henning Westerholt <hw(a)gilawa.com> escribió: > Hello, > > correct me if I am wrong, but the second group of addresses ("/16") is > included in the first group ("/14"), right? > > Regarding the large IP scope, this is the way Microsoft designed it, > unfortunately. There is not that much what you can do about. > > Right. Didn't check the masks. they all were 16 in my mind :) So, if I add those ranges in the permissions table my only way of avoiding spoofed calls is certificate validation? I'm already doing that and also checking the company domain and ms account email address. Just wanted to be sure that nothing "essential" was missing. -- PekePBX, the multitenant PBX solution https://pekepbx.com

1 0

sendig 4 byte udp nat pings
by Bernd Krueger-Knauber 18 Feb '23

18 Feb '23

Hi, maybe I'm stupid, but I can not find out how to send 4 byte UDP NAT packets to the sip server. loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 15) modparam("nathelper|registrar", "received_avp", "$avp(s:rcv)") I'm a absolute beginner with kamailio and the page about the nathelper Module is not really helpful. At the moment no pings are sendet. But I receive 4 byte packets from the sip server. After 15 minutes my calls are cancelled because of the missing pings. Without proxy, the phone send the pings directly to the sip server and the call stays alive. When I experiment with some other nathelper settings, kamailo start results in errors. Any help would be appreciated. Best regards, Bernd

3 11

enable topology hiding on one side or dynamic ip in topoh module Contact and Via Header
by Patrick Karton 17 Feb '23

17 Feb '23

Hello , im using kamailio with two interfaces external and internal. i need a way either to : * enable topoh hiding only when outgoing interface is external ( mask contact and Via ip only when ougoing interface is external * or if it is not possible to enable it only in one direction.i want to know how to configure dynamic(for example in xavp or avp) ip to put in Contact and Via when topoh is enabled. i see that the 'mask_ip' parameter of topoh module is a string. so we can not set a dynamic value here unfortunately. Thanks

4 8

Calling uac_replace multiple times?
by Benoît Panizzon 17 Feb '23

17 Feb '23

Hey all I have started using the uac module to be able to mirror username changes on both legs of a call. But now I found an issue: Assume this situation: Call IC => Customer IC is e164, Customer wants 'local' numbers. IC From: +41991234567 => Customer From: 0991234567 uac_replace_from("sip:" + $avp(from_local) + "@" + $(fu{uri.host})); Customer is absent, after timeout in failure_route call is dispatched to Voicemail Server, which is configured for e164 numbers: uac_replace_from("sip:" + $avp(from_e164) + "@" + $(fu{uri.host})); But then uac complains: replace_uri(): Already called uac_replace for this dialog Why isn't just the most from version kept and used? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 1

TLS version and cipher from WSS
by Michal Hajek 17 Feb '23

17 Feb '23

Hi, I can log incoming SIPS TLS version and cipher with PV $tls_version and $tls_cipher_info. How can I log these variables on incoming HTTP/WebSocket. Thanks Michal H.

2 2

Identify error in log
by Евгений Мастратов 16 Feb '23

16 Feb '23

Hello colleagues. I'm starting to use Kamailio for educational purposes, as an IMS test zone. Registration of subscribers, calls go successfully, but the following errors are constantly pouring into the log: Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:1378]: int_intop2(): rv div by 0 Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:1378]: int_intop2(): rv div by 0 Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:2381]: rval_expr_eval(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:2381]: rval_expr_eval(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/lvalue.c:386]: lval_assign(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/lvalue.c:386]: lval_assign(): rval expression evaluation failed (735,15-735,55) Apparently they don’t carry anything critical, but they clog the log, natively I can’t understand the meaning of the errors. Please tell me what they mean and how to eliminate their cause? If necessary, I will provide the pcscf config.

2 1

uac reg reload frequency
by Dmytro M 16 Feb '23

16 Feb '23

When you do "kamcmd uac.reg_reload" frequently enough, you'll get an error: # kamcmd uac.reg_reload error: 500 - Failed to shift records - check log messages Logs: ERROR: uac [uac_reg.c:416]: uac_reg_ht_shift(): shifting in-memory table is not possible in less than 150 secs What is the reason behind 150 sec limitation for how frequent reloads can be done? Is it configurable in any way? Use case: Remote app needs to disable uac registration. It deletes record in DB and calls kamcmd uac.reg_reload to activate the change. With 150 sec limit it can't apply DB changes immediately. Please advise. Thanks, Dmytro

2 2

ACK on RE-Invite is send to UAC NATed Internal port instead of public port
by Angelo Sipper 15 Feb '23

15 Feb '23

Hi, My setup has: (TLS)UAC 77.1.1.1 -> (TLS)Kamailio 17.17.17.211 (UDP) -> (UDP)Kamailio 17.17.17.181 (UDP) -> Carrier(UDP) Both Kamailio are 4.3 with minor modifications on default cfg, and Topoh and TLS modules are used. I am having an issue on some outbound calls from nated UACs. On these calls our SBC sometimes receives reverse invites from the carrier side within the call. When this happens, my SBC(17.17.17.211) sends the invite to UAC and the UAC sends back 200 OK (SDP). Unfortunately my SBC(17.17.17.211) sends back the ACK not to the correct UAC public port but instead to the UAC internal port making the call to crash with several retries from my SBC to send 200 OK as ACK was never received from UAC! If you look the below traces of reverse invite past within the call, the reinvite has port private 20125 and alias the public port 2314 of UAC but the ACK bellow is send to 20125 and not to 2314 2023/01/26 09:48:30.668634 17.17.17.181:5060 -> 17.17.17.211:5060 INVITE sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:30.679743 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0;rport=5060 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:30.740803 17.17.17.211:5060 -> 77.1.1.1:2314 INVITE sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 68 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.893512 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Content-Length: 0 2023/01/26 09:48:31.026742 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.093656 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 276 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 14.1.1.28 s=3cxPS Audio call c=IN IP4 14.1.1.28 t=0 0 m=audio 13278 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=sendrecv a=rtcp:13279 2023/01/26 09:48:31.254591 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.260901 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.e8fb34e79623843d516ae77257014e2d.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Any help will be much appreciated. Thank you! Regards, Angelo

2 5

SCA Presence : Record-Route Filed Not Update in sca_subscriptions Table
by Vinayak Makwana 14 Feb '23

14 Feb '23

Hello all, I am using the sca module in kamailio script.so when i subscribe with my ip phone for SCA Presence i get all the information in a sca_subscriptions table for the first time. When I reboot the device I get a new record-route header in trace but It does not update *record-route *Filed in sca_subscriptions table. Can anyone help me out with this issue ? *Here's modparam configuration * modparam("sca", "db_update_interval", 10 ) modparam("sca", "db_url", DBURL_LOCAL) modparam( "sca", "line_seize_max_expires", 30) modparam( "sca", "purge_expired_interval", 1800) -- -- * <https://www.ecosmob.com/itexpo/> * *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

3 8

SCA Feature:: Record-route query.
by satyaprakash ch 13 Feb '23

13 Feb '23

Hello I have a query regarding the record-route field update in DB for SCA SUBSCRIBE. Here are my test cases *Initial SCA subscription,* We got the below SUBSCRIBE packet in kamailio SUBSCRIBE sip:1234.xyz.com:5060 SIP/2.0 Via: SIP/2.0/UDP kam-ip:5060;branch=z9hG4bK2sansay1081381rdb66 *Record-Route* : <sip:sansay1081381rdb66spid17urcvjtr139807186744464nat0@kam-ip:5060;lr;transport=udp> To: <sip:372427@1234.xyz.com:6060> From: "708" <sip:372427@1234.xyz.com:6060>;tag=CFFBAF19-19A68CBC Call-ID: bd4b50d9384523c14ea05c532d895bf2 CSeq: 2 SUBSCRIBE Contact: < sip:372427@192.168.1.3> Expires: 3600 Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER Event: call-info User-Agent: PolycomVVX Accept-Language: en Max-Forwards: 69 Content-Length: 0 also in the sca_subscriptions table record-route header is updated as per Initial SUBSCRIBE record-route. *record_route: <sip:sansay1081381rdb66spid17urcvjtr139807186744464nat0@kam-ip:5060;lr;transport=udp> * But After rebooting the device, we got a new record-route in SUBSCRIBE Packet but in DB Record-route Field not updated after getting an updated record-route in Trace. *Kamailio Trace *SUBSCRIBE sip:1234.xyz.com:5060 SIP/2.0 Via: SIP/2.0/UDP kam-ip:5060;branch=z9hG4bK2sansay1081415rdb48 *Record-Route*: <sip:sansay1081415rdb48spid17urcvjtr139807186744464nat0@kam-ip:5060;lr;transport=udp> To: <sip:372427@1234.xyz.com:6060> From: "708" <sip:372427@1234.xyz.com:6060>;tag=35852031-CF749E20 Call-ID: 41fa031d79e35fae4a61c61984895bf2 CSeq: 2 SUBSCRIBE Contact: < sip:372427@192.168.1.3> Expires: 3600 Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER Event: call-info User-Agent: PolycomVVX Accept-Language: en Max-Forwards: 69 Content-Length: 0 as per logic it should update the record-route field in sca_subscriptions table . but it didn't update it : record_route: <sip:sansay1081381rdb66spid17urcvjtr139807186744464nat0@kam-ip:5060;lr;transport=udp> So can you suggest to us how we can update the record-route field as per SUBSCRIBE's packet new record-route ?

2 1

Issues matching regex
by Nathan Stratton 11 Feb '23

11 Feb '23

I am having an issue matching toll-free. I tested my regex on regex101.com, and it looks good, but it does not match my if statement. Am I doing something wrong? if (method=="INVITE") { xlog("L_INFO", "Checking Routes $rU"); if ($rU=~"^(\+?1)?(8(00|44|55|66|77|88)[2-9]\d{6})$") { xlog("L_INFO", "Tollfree call"); }; }; Logs show "<script>: Checking Routes +18002211212" so I don't get why it does not match. ><> Nathan Stratton Founder, CTO Vocinity, Inc. <https://www.vocinity.com/gabbi>

2 1

kemi equivalent config
by mohsen khashei 11 Feb '23

11 Feb '23

2 1

KEMI Equivalent of script
by mohsen khashei 10 Feb '23

10 Feb '23

Hi I have an existing kamailio config and I want to migrate to kemi. I want to know what is the equivalent of this code in kemi javascript ? $avp(s:contact) = $hdr(Contact); $avp(s:contact_fix) = $hdr(Contact); avp_subst("$avp(s:contact_fix)", "/@([0-9]+).([0-9]+).([0-9]+).([0-9]+)/@$sel(cfg_get.kamailio.ss_ip)/gi"); remove_hf("Contact"); append_hf("Contact: $avp(s:contact_fix)\r\n"); t_on_reply("REG_FIX"); thanks for your attention.

1 0

Return value from lua/python/js/bash/etc... function
by Dmytro M 10 Feb '23

10 Feb '23

What is the simplest way to return values from external application into Kamailio config and assign it to a variable? I'm looking for the most light weight mechanism to do it and to offload some logic to external app. Something like this would be ideal: $var(myVar), $var(err) = lua_run("lua_func1", "$rU"); OR $var(encString) = exec_cmd("echo 'abc $rU' | base64"); There is this method: http_client_query("http://...", "", "", "$var(result)"); but there is an overhead of networking and HTTP protocol. Please advise. Thanks, Dmytro

3 4

ACK on Reverse Invite is send to NATed Internal port instead of public port
by Angelo Sipper 09 Feb '23

09 Feb '23

Hi, I am having an issue on some outbound calls from nated UAC. On these calls our SBC receive reverse invites from the carrier side within the call. When this happens, my SBC(Kamailio1) sends the invite to UAC and the UAC sends 200 OK (SDP). Unfortunately my SBC(Kamailio1) sends back the ACK not to the correct UAC public port but instead to UAC internal port making the call to crash! My setup has: (TLS)UAC -> (UDP)Kamailio1(UDP) -> (UDP)Kamailio2(TLS) -> Carrier(UDP) Bellow you can find the trace and you can see the ACK send to wrong port on 2023/01/26 09:48:31.254591 Your help will be much appreciated! 2023/01/26 09:48:23.225326 77.1.1.1:2314 -> 17.17.17.211:5060 INVITE sip:300987654321@17.17.17.211:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport Max-Forwards: 70 Contact: <sip:301234567890@77.1.1.1:20125> To: <sip:300987654321@17.17.17.211:5060> From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Remote-Party-ID: <sip:301234567890>;party=called Content-Length: 283 v=0 o=3cxPS 792019937001472 2393157908037633 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:23.240310 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314;received=77.1.1.1 To: <sip:300987654321@17.17.17.211:5060> From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:23.301454 17.17.17.211:5060 -> 17.17.17.181:5060 INVITE sip:300987654321@sip.mydomain.com:5060 SIP/2.0 Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Max-Forwards: 69 Contact: <sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1> To: <sip:300987654321@sip.mydomain.com> From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 300 P-Asserted-Identity: <sip:301234567890@sip.mydomain.com> v=0 o=3cxPS 792019937001472 2393157908037633 IN IP4 14.1.1.28 s=3cxPS Audio call c=IN IP4 14.1.1.28 t=0 0 m=audio 13278 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=sendrecv a=rtcp:13279 2023/01/26 09:48:23.302899 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0;rport=5060 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 To: <sip:300987654321@sip.mydomain.com> From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:24.077941 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 183 Session Progress From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:24.138348 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 183 Session Progress From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:24.139050 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 183 Session Progress From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:24.200575 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 183 Session Progress From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.115324 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 200 OK From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Require: timer Supported: timer Session-Expires: 600;refresher=uac Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:30.336507 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 200 OK From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Require: timer Supported: timer Session-Expires: 600;refresher=uac Content-Length: 250 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.432457 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 200 OK From: 301234567890<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Require: timer Supported: timer Session-Expires: 600;refresher=uac Content-Length: 242 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bKc2d8.34fe87ef37b154d931766bddfd3da41d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 194.154.142.193 s=SIP Media Capabilities c=IN IP4 194.154.142.196 t=0 0 m=audio 10764 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=maxptime:20 2023/01/26 09:48:30.433017 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 200 OK From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Server: Voiceland SBC Require: timer Supported: timer Session-Expires: 600;refresher=uac Content-Length: 242 Content-Disposition: session; handling=required Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---9bbfa2727a1f3803;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Record-Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> v=0 o=Sonus_UAC 14218 13518 IN IP4 194.154.142.193 s=SIP Media Capabilities c=IN IP4 194.154.142.196 t=0 0 m=audio 10764 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=maxptime:20 2023/01/26 09:48:30.457268 77.1.1.1:2314 -> 17.17.17.211:5060 ACK sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---5ff61b7097f10965;rport Max-Forwards: 70 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:301234567890@77.1.1.1:20125> To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 ACK User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:48:30.481470 17.17.17.211:5060 -> 17.17.17.181:5060 ACK sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bKc2d8.44ee18452b274c8de283aa3c27549f4e.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---5ff61b7097f10965;rport=2314 Max-Forwards: 69 Contact: <sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1> To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 From: "My, User"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 ACK User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:48:30.555470 77.1.1.1:2314 -> 17.17.17.211:5060 ACK sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---5ff61b7097f10965;rport Max-Forwards: 70 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:301234567890@77.1.1.1:20125> To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 ACK User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:48:30.557824 17.17.17.211:5060 -> 17.17.17.181:5060 ACK sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bKc2d8.44ee18452b274c8de283aa3c27549f4e.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---5ff61b7097f10965;rport=2314 Max-Forwards: 69 Contact: <sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1> To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 From: "My, User"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 1 ACK User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:48:30.668634 17.17.17.181:5060 -> 17.17.17.211:5060 INVITE sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:30.679743 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0;rport=5060 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:30.740803 17.17.17.211:5060 -> 77.1.1.1:2314 INVITE sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 68 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.893512 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Content-Length: 0 2023/01/26 09:48:31.026742 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.093656 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 276 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 14.1.1.28 s=3cxPS Audio call c=IN IP4 14.1.1.28 t=0 0 m=audio 13278 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=sendrecv a=rtcp:13279 2023/01/26 09:48:31.254591 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.260901 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.e8fb34e79623843d516ae77257014e2d.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.530836 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.531333 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.609667 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.6cff4a8159c123f434b422c73e17a08c.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.612312 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.63edf375f6b899dfa9d2d9a2dcee4dfd.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.6cff4a8159c123f434b422c73e17a08c.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:32.536512 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:32.536839 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:32.623207 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.48a5467fc248682a755e70a672268f79.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:32.641928 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.745a55762e847bc3cf56d27926f7e62d.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.48a5467fc248682a755e70a672268f79.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:34.540735 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:34.541310 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:34.590013 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.6c3274e7b34c3b780cfbe9180a4d5eb1.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:34.595763 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.6c6654fa1c2f4b1991d5b6d792f2f081.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.6c3274e7b34c3b780cfbe9180a4d5eb1.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:38.561756 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:38.562039 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:38.599703 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.ef7afaa26d39ee76ce9000b1203574e7.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:38.603466 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.e022b4e31f8266525e62f213dc4dd8ae.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.ef7afaa26d39ee76ce9000b1203574e7.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:42.584025 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:42.584257 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:42.622809 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.03eec221779917d79f0daa500f7a0cc6.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:42.626545 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.0e211693731e67705c85dd4844e42ce8.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.03eec221779917d79f0daa500f7a0cc6.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:46.629501 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:46.629961 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:46.676968 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.701d02748c09dee63b88ca1e96a4e371.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:46.682458 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.cc80042ad9e1838346f4cf6d66a4c13f.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.701d02748c09dee63b88ca1e96a4e371.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:50.636998 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:50.637287 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:50.675272 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.041bbf55bf3941bfbd16df0f3ca92cf1.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:50.681861 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.be45a1f76f0fcd5ce85292397ff68acc.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.041bbf55bf3941bfbd16df0f3ca92cf1.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:54.677049 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:54.677633 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:54.721399 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.6ce35eaf9a5805bf47c868cd80c09478.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:54.729950 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.365607f0beb6e7e5dcb047c1ad6fcf5f.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.6ce35eaf9a5805bf47c868cd80c09478.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:58.681010 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:58.681307 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:58.723730 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.abb70cc570d323c867c112765ec50432.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:58.731143 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.12bbae879e42215b50512c04c4fc0214.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.abb70cc570d323c867c112765ec50432.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:49:02.684483 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:49:02.684985 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:49:02.727999 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.c2b81601667ffb2a688deba47abd85ef.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:49:02.732652 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.fb4ff819be250670479341711417a554.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.c2b81601667ffb2a688deba47abd85ef.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:49:03.028200 77.1.1.1:2314 -> 17.17.17.211:5060 BYE sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;branch=z9hG4bK-524287-1---7c113301b578bb42;rport Max-Forwards: 70 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:301234567890@77.1.1.1:20125> To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 2 BYE User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:49:03.090194 17.17.17.211:5060 -> 17.17.17.181:5060 BYE sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK92d8.6e9f4e9b390a591c1c54d79389ba087d.0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---7c113301b578bb42;rport=2314 Max-Forwards: 69 Contact: <sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1> To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 From: "My, User"<sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 2 BYE User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 0 2023/01/26 09:49:03.261453 17.17.17.181:5060 -> 17.17.17.211:5060 SIP/2.0 200 OK From: "My, User"<sip:301234567890@sip.mydomain.com>;tag=07ece97c To: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 2 BYE Content-Length: 0 Via: SIP/2.0/UDP 17.17.17.211;rport=5060;branch=z9hG4bK92d8.6e9f4e9b390a591c1c54d79389ba087d.0,SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---7c113301b578bb42;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:49:03.261941 17.17.17.211:5060 -> 77.1.1.1:2314 SIP/2.0 200 OK From: "My, User"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c To: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 2 BYE Content-Length: 0 Via: SIP/2.0/UDP 192.168.80.228:5060 ;received=77.1.1.1;branch=z9hG4bK-524287-1---7c113301b578bb42;rport=2314 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Thank you! Regards, Angelo

2 4

DB_CLUSTER failure with carrierroute (and others?)
by Kaufman 08 Feb '23

08 Feb '23

All, I've been trying to chase down an issue with db_cluster and permissions in combination with something else, where with my full configuration using the same cluster in multiple modules has failures. I've been trying to create a simplified configuration to consistently reproduce the problem without much success, however I did stumble upon THIS particular problem. The configuration here works fine as is - avpops uses the cluster URL, and carrierroute uses the direct SQLite URL. If I define WITH_DBCLUSTER, then carrierroute fails fetching rows using the cluster connection. Note that AVPOPS is only used as a general test to see if the cluster config works. If I remove references to avpops , carrierroute still fails loading from the cluster URL. Thoughts? #!KAMAILIO loadmodule "db_sqlite" loadmodule "pv" loadmodule "db_cluster" loadmodule "carrierroute" loadmodule "avpops" modparam("db_cluster", "connection", "db1=>sqlite:////etc/db.sqlite") modparam("db_cluster", "cluster", "cl1=>db1=9s9s") modparam("db_cluster", "inactive_interval", 30) #!ifdef WITH_DBCLUSTER modparam("carrierroute", "db_url", "cluster://cl1") #!else modparam("carrierroute", "db_url", "sqlite:////etc/db.sqlite") #!endif modparam("carrierroute", "config_source", "db") modparam("avpops", "db_url", "cluster://cl1") modparam("avpops", "avp_table", "usr_preferences") request_route { exit; } Failure log: 0(1) ERROR: carrierroute [cr_db.c:345]: load_route_data_db(): Fetching rows failed 0(1) ERROR: carrierroute [cr_data.c:179]: reload_route_data(): could not load routing data 0(1) ERROR: carrierroute [carrierroute.c:240]: mod_init(): could not prepare route data 0(1) ERROR: <core> [core/sr_module.c:942]: init_mod(): Error while initializing module carrierroute (/usr/lib/kamailio/modules/carrierroute.so) Kaufman

3 5

Drops on async_route with delay
by Alex Balashov 07 Feb '23

07 Feb '23

Hi, Some percentage of requests processed with async_route("REQ_PROCESS", "5") seem to end up with a resumed transaction, though most do. Not sure what the exact percentage is. The ones that don't Is this due to excessive requests? Is there a limit on internal IPC queue depth? Is it conceptually similar to a generic shared blocking queue internally, along the lines of 'mqueue'? Is there any reasonable way to troubleshoot this? Thanks! -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

3 3

Dispatcher + ENUM
by Jawaid Bazyar 07 Feb '23

07 Feb '23

Hi, Can DISPATCHER be used in conjunction with ENUM? E.g., to avoid sending requests to SIP destinations that are returned by ENUM, but, which DISPATCHER knows are down? Thanks, Jawaid

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