- sr-users - kamailio.org

Routing dialogs (INVITE) from Lua
by Emilio Panighetti 18 Oct '21

18 Oct '21

Hello, Based on kamailio-basic-kemi.cfg and kamailio-basic-kemi-lua.lua, I’m trying to get a simple test to go through using SIPp built-in UAC and UAS scenarios, using LUA config: Commented out all the registration blocks and trying to run a simple proxy for now, but I can’t seem able to change the URI. SIPp UAC: 192.168.1.12:5060 SIPp UAS: 192.168.1.12:5062 Kamailio 5.5.2: 192.168.15.:5060 Part of the Kamailio.lua config: -- wrapper around tm relay function function ksr_route_relay() -- enable additional event routes for forwarded requests -- - serial forking, RTP relaying handling, a.s.o. if KSR.is_method_in("IBSU") then if KSR.tm.t_is_set("branch_route")<0 then KSR.dbg("EP: ksr_route_relay Set for branch_route\n"); KSR.tm.t_on_branch("ksr_branch_manage"); end end if KSR.is_method_in("ISU") then if KSR.tm.t_is_set("onreply_route")<0 then KSR.dbg("EP: ksr_route_relay Set for onreply_route\n"); KSR.tm.t_on_reply("ksr_onreply_manage"); end end if KSR.is_INVITE() then if KSR.tm.t_is_set("failure_route")<0 then KSR.dbg("EP: ksr_route_relay Set for failure\n"); KSR.tm.t_on_failure("ksr_failure_manage"); end end if KSR.tm.t_relay()<0 then KSR.dbg("EP: ksr_route_relay Set for reply_error\n"); KSR.sl.sl_reply_error(); end -- EP: Base route KSR.dbg("EP: ksr_route_relay Check for Base Route\n"); if KSR.is_INVITE() then KSR.dbg("EP: ksr_route_relay Base Route (DU)\n"); --KSR.sl.send_reply("503", "Debug"); KSR.setdsturi("sip:192.168.1.12:5062"); KSR.pv.sets("$du", "sip:192.168.1.12:5062"); end KSR.dbg("EP: ksr_route_relay exit\n"); KSR.x.exit(); end What’s happening here is that instead of forwarding the INVITE to the SIPp UAC, it creates a loop. Tried KSR.setdsturi() only (KSR.pv.sets commented out) and it’s still the same. If I comment out the 503 reply, then that’s what the UAC gets back. Here’s the log when calling ksr_route_relay: Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/msg_translator.c:162]: check_via_address(): (192.168.1.12, 192.168.1.12, 0) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:489]: sr_lua_reload_script(): No need to reload [/etc/kamailio/kamaili o.lua] is version 0 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:673]: app_lua_run_ex(): executing Lua function: [[ksr_onsend_route]] Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:675]: app_lua_run_ex(): lua top index is: 0 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: tm [t_funcs.c:376]: t_relay_to(): new transaction forwarded Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_r oute_relay Check for Base Route Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_relay Check for Base Route Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_r oute_relay Base Route (DU) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_relay Base Route (DU) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: setdsturi is str: sip :192.168.1.12:5062 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: sets is str: $du Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[1] for: sets is str: sip:192. 168.1.12:5062 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/kemi.c:2906]: sr_kemi_pv_sets(): pv set: $du Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/pvapi.c:371]: pv_cache_add(): pvar [$du] added in cache Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_r oute_relay exit Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_relay exit Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1837]: sr_kemi_lua_exit(): script exit call Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:729]: app_lua_run_ex(): ksr error call from Lua: ~~ksr~exit~~ Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_mod.c:167]: sr_kemi_config_engine_lua(): execution of route type 1 with no n ame returned 1 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) INFO: LUA {INVITE}: <core> [core/receive.c:515]: receive_msg(): request-route executed in: 1335 usec Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/receive.c:606]: receive_msg(): cleaning up Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: <core> [core/udp_server.c:493]: udp_rcv_loop(): received on udp socket: (112/100/661) [[INVITE sip:service@ 192.168.1.15:5060 SIP/2.0 0D 0A Record-Route: <sip:192.168.1.15;lr=on> 0D 0A Via: SIP/2.0/U]] Any idea how we can route this message? Thanks!

2 1

dmq_usrloc writes to database on other nodes too
by Maarten Ureel 17 Oct '21

17 Oct '21

I have the idea that if you enable dmq_usrloc, the other nodes that receive the usrloc info, also try to write to database. We see this by a lot of errors indicating the index violation on postgres. What is the easiest way to tell Kamailio that it does not need to store the usrloc in database if the data came through a DMQ message? Currently I have in my config: # DMQ processing if(is_method("KDMQ") && $Rp == 5090) { dmq_handle_message(); } I have understood that no further processing happens then. So is my assumption correct that my other handling of REGISTER will not be used then? As in, can you handle this in code that it will only store the register information in memory? Like this? # Registration handling route[REGISTRAR] { # If coming from DMQ, don't save to database if(dmq_is_from_node()) { save("location", "0x01") } }

2 4

kamailio SipTrace Module
by Андрей Зюзенков 17 Oct '21

17 Oct '21

Good afternoon, I apologize for disturbing you. I have a question that I cannot find in the documentation https://www.kamailio.org/docs/modules/devel/modules/siptrace.html#siptrace.… 3.3. trace_flag parameter has some values. And what values can be and what do they mean pls, help

2 1

http_async_client "route_name" is considered a failure route?
by Brooks Bridges 16 Oct '21

16 Oct '21

So I've been working on this for a while, and I cannot seem to find a way around this. When using the http_async_client to request data from an external API, the returned data in the "route_name" target is being treated as a failure route, so most of the subsequent processing and messaging that I want to do is not working, either because the function can't be used in a failure route, or because I have to create a transaction prior to doing the request, which then throws an error by immediately triggering a 500 after I return the response I want (via 302 to the requesting client). Am I using http_async_client incorrectly somehow that's causing this behavior or is it expected that the response route is treated as a failure route? Confidentiality Notice: This e-mail, and any attachment to it, contains privileged and confidential information intended only for the use of the individual(s) or entity named on the e-mail. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that reading this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system.

2 1

Call to MS Teams
by Володимир Іванець 15 Oct '21

15 Oct '21

Hello all! I'm trying to make a call from the system with Kamailio to a MS Teams. I can answer in the Teams client, system will receive response 200 OK and audio streams will be started. The problem I have is that after a short period of time Teams sends BYE with the reason "An acknowledgement was not received for the call acceptance in the allotted time". If I try to hangup from the system side, Teams will receive BYE and respond with "481 Call Leg/Transaction Does Not Exist" - "Call leg unavailable". It looks like Teams can not match and accept ACK request to finish establishing the call and the following requests have the same problem. I was wondering if someone had this problem before or can share a SIP packet capture (of course with hidden addresses and domain names) of a correctly established and completed call to Teams? Thanks a lot! Regards, Volodymyr Ivanets

1 1

unable to receive UDP
by dem＠htsweb.com 13 Oct '21

13 Oct '21

After 4 (long) days of trying to receive any UDP SIP, I'm hoping someone can point out what I'm doing wrong. I've looked at the kamailio code. I'm beginning to think it's the 'polling' code, but it looks fine. It could be Centos or a Dell network driver, but not seeing any errors anywhere. - stock build/compile... Version: kamailio 5.5.2 (x86_64/linux) 0d53d9 Compile 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 MAX_RECV_BUFFER_SIZE=262144 MAX_URI_SIZE=1024 BUF_SIZE=65535 DEFAULT PKG_SIZE=8MB DEFAULT SHM_SIZE=64MB ADAPTIVE_WAIT_LOOPS=1024 TCP poll methods: poll, epoll_lt, epoll_et, sigio_rt, select Source code revision ID: 0d53d9 Compiled with: gcc 4.8.5 Compiled architecture: x86_64 Compiled on: 08:44:19 Oct 11 2021 Running Centos 7 all updated. Dell R630. # sestatus SELinux status: disabled # firewall-cmd --list-all ports: 5666/tcp 873/tcp 873/udp 80/tcp 443/tcp 5060/tcp 5060/udp 5061/tcp 5061/udp - Just trying to send SIP INVITE from trunk provider to R630 kamailio... (SIP trunk) UDP 172.200.200.202:5060 -> (firewall) UDP 172.250.250.162:5060 -> 1:1 NAT -> (R630) UDP 10.102.88.81:5060 - I can 'see' the packet hit the em3 network... # tcpdump -i em3 -e -vv -n port 5060 11:53:33.260892 99:99:ef:3e:69:c1 > 99:99:1c:48:4e:e3, ethertype IPv4 (0x0800), length 1366: (tos 0x0, ttl 54, id 20430, offset 0, flags [none], proto UDP (17), length 1352) 172.200.200.202.sip > 10.102.88.81.sip: [udp sum ok] SIP, length: 1324 INVITE sip:+18005551234@172.250.250.162:5060 SIP/2.0 ... At this point, I just need to see a SIP INVITE received. Then I can go back to working on a real config. I've tried with TCP on/off, listening on all networks, alias on/off, strace and everything else I could think of.Truly appreciate any guidance. Tried every sample config possible, but I just need to test receiving the SIP UDP packet, so this 'should' be minimum config... #!KAMAILIO debug=9 log_stderror=no log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " children=2 disable_tcp=yes udp4_raw=on auto_aliases=no alias="sbc01.mysite.com" listen=udp:10.102.88.81:5060 loadmodule "debugger.so" loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" modparam("debugger", "cfgtrace", 1) request_route { xlog("SIP received xxxxxxxxxxxxxxxxxxx\n"); } # kamcmd ps 11578 main process - attendant 11579 udp receiver child=0 sock=10.102.88.81:5060 11580 udp receiver child=1 sock=10.102.88.81:5060 11581 slow timer 11583 timer 11584 secondary timer 11585 JSONRPCS FIFO 11586 JSONRPCS DATAGRAM 11587 ctl handler - I get plenty of logging, but the logging just waits here... Oct 12 11:38:04 sbc01 /usr/local/sbin/kamailio[10060]: INFO: ctl [io_listener.c:210]: io_listen_loop(): io_listen_loop: using epoll_lt as the io watch method (auto detected) Oct 12 11:38:04 sbc01 /usr/local/sbin/kamailio[10060]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fd2a8bae010, 4800) called from core: core/io_wait.c: init_io_wait(469) Oct 12 11:38:04 sbc01 /usr/local/sbin/kamailio[10059]: DEBUG: <core> [core/mem/q_malloc.c:419]: qm_malloc(): qm_malloc(0x7fd2a8bae010, 65456) returns address 0x7fd2a8c652d8 frag. 0x7fd2a8c652a0 (size=65456) on 1 -th hit Oct 12 11:38:04 sbc01 /usr/local/sbin/kamailio[10060]: DEBUG: <core> [core/mem/q_malloc.c:419]: qm_malloc(): qm_malloc(0x7fd2a8bae010, 4800) returns address 0x7fd2a8c652d8 frag. 0x7fd2a8c652a0 (size=4800) on 1 -th hit Oct 12 11:38:04 sbc01 /usr/local/sbin/kamailio[10060]: DEBUG: <core> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fd2a8bae010, 2400) called from core: core/io_wait.c: init_io_wait(516) Oct 12 11:38:04 sbc01 /usr/local/sbin/kamailio[10060]: DEBUG: <core> [core/mem/q_malloc.c:419]: qm_malloc(): qm_malloc(0x7fd2a8bae010, 2400) returns address 0x7fd2a8c66600 frag. 0x7fd2a8c665c8 (size=2400) on 1 -th hit Oct 12 11:38:04 sbc01 /usr/local/sbin/kamailio[10060]: DEBUG: ctl [io_listener.c:246]: io_listen_loop(): io_listen_loop: adding socket 8, type 2, transport 3 (/var/run/kamailio//kamailio_ctl) Oct 12 11:38:04 sbc01 /usr/local/sbin/kamailio[10060]: DEBUG: ctl [../../core/io_wait.h:375]: io_watch_add(): DBG: io_watch_add(0x7fd2a70a5360, 8, 2, 0x2439960), fd_no=0 - The only other thing that I see is transport 3. Isn't that a UNIXS_SOCK?

5 9

Kamailio Inbound proxy to Asterisk - ACL Filtering
by Mihai Cezar 13 Oct '21

13 Oct '21

Hello, I have an issue with filtering on the asterisk side, my requests are: UsersPhones(bria) -> Kamailio -> Asterisk -> Sip Trunk Out. The goal is to manage a new layer of protection ( IP filtering / Whitelisting ). When I try to compile a list of Whitelisted IP in sip.conf I get this error: NOTICE[205]: acl.c:748 ast_apply_acl: SIP contact ACL: Rejecting '145.72.23.45' due to a failure to pass ACL '(BASELINE)' WARNING[205]: chan_sip.c:17061 parse_register_contact: Domain '5.12.16.2:48669' disallowed by contact ACL (violating IP 145.72.23.45) WARNING[205]: chan_sip.c:17933 register_verify: Registration denied because of contact ACL The IP 145.72.23.45, is the proxy kamailio and if I added it to sip.conf it works, but so does every ip afterwards. I tried with contactpermit also with permit, the result is the same as long as I permit the proxy ip it works. Is there something that I can do on the asterisk side to activate this filtering Or there is something that I can do in Kamailio so it will forward the realip ? contactdeny=0.0.0.0/0.0.0.0 contactpermit=145.72.23.45/32 contactpermit=5.12.16.2/32 Thanks in advance,

4 7

Compile kamailio-5.4 against openssl1.1.1
by Antony Russell 13 Oct '21

13 Oct '21

Hello I see that support for compiling kamailio against openssl1.1.1 was recently added (https://github.com/kamailio/kamailio/pull/2779) and I see that this can be done in kamailio-5.5.2. Will this ability be made available in kamilio-5.4? I see it is not in the most recent 5.4 release (5.4.7) -- *Antony Russell* Chief Technical Officer Tel 087 820 8113 antony.russell(a)telviva.co.za www.telviva.co.za *Telviva (Pty) Ltd - formerly Connection Telecom (Pty) Ltd* -- https://www.telviva.co.za/legal/email-disclaimer <https://www.telviva.co.za/legal/email-disclaimer>

1 0

Fail Call from Webrct to PSTN SIP Trunk
by Abdul Rahman Reza 11 Oct '21

11 Oct '21

Hi Everyone There some log kamailio Warning: 399 03077.08860.B.005.422.228.0.15.01039.00000000.00000 "SDP body length beyond limit" how to increase maximum length sdp in kamailio, because i don't see any configuration related to sizing max length SDP on kamailio documentation please help me Thank you very much

3 3

Let's Encrypt DST Root CA X3 cert CA expiration 30th/Sept - Any issues?
by Joel Serrano 11 Oct '21

11 Oct '21

Hello, I'm wondering if anyone had any issues yesterday with the expiration of the DST Root CA X3 cert? Out of all the servers I manage, only a couple were affected (debian 8). They were production servers so we replaced the cert with a different one to solve the issue while we find the root cause. Anyone out there had any issues yesterday because of this? I'm just curious! Joel.

10 12

upgrade kamailio 4.4.x-to-5.0.0 - PostgreSQL migrations
by Giovanni Tommasini - timenet srl 11 Oct '21

11 Oct '21

Hi Dears, I'm working on upgrading Kamailio from 4.4.6 to 5.4.0 in an installation where I use PostgreSQL I understand that I have to upgrade in steps by following these links: - http://www.kamailio.org/wiki/install/upgrade/4.4.x-to-5.0.0 - http://www.kamailio.org/wiki/install/upgrade/5.0.x-to-5.1.0 - https://www.kamailio.org/wiki/install/upgrade/5.1.x-to-5.2.0 - https://www.kamailio.org/wiki/install/upgrade/5.2.x-to-5.3.0 - https://www.kamailio.org/wiki/install/upgrade/5.3.x-to-5.4.0 in most of these links, in the section "Database", I find only the subsection "MySQL Database Structure", but I don't find the indications for DB migrations for PostgreSQL Database. Only here https://www.kamailio.org/wiki/install/upgrade/5.2.x-to-5.3.0 I found both the subsection "MySQL Database Structure" and "PostgreSQL Database Structure". What does this mean? - that I'm getting lost in a glass of water? - or that I don't have to make any changes to PostgreSQL? - or that the queries to be launched on PostgreSQL are the same as those for MySQL? I would discard this hypothesis - or that the wiki sections for PostgreSQL are missing? If this were the case, I could proceed with the update and then share the queries I launched to update the wiki. thanks a lot Giovanni Tommasini

3 5

Critical log when $mbu pseudovariable is accessed
by Alberto Izquierdo 11 Oct '21

11 Oct '21

Hi, I'm getting some CRITICAL logs when accessing the content of the $mbu pseudovariable in a "onsend_route" function. The log lines look like this: ``` CRITICAL core 35847:core/msg_translator.c:493 null send socket CRITICAL core 35847:core/msg_translator.c:893 FIXME: null send_sock CRITICAL core 35847:core/msg_translator.c:493 null send socket CRITICAL core 35847:core/msg_translator.c:493 null send socket CRITICAL core 35847:core/msg_translator.c:493 null send socket CRITICAL core 35847:core/msg_translator.c:493 null send socket CRITICAL core 35847:core/msg_translator.c:1479 FIXME: null bind_address CRITICAL core 35847:core/msg_translator.c:493 null send socket CRITICAL core 35847:core/msg_translator.c:493 null send socket CRITICAL core 35847:core/msg_translator.c:493 null send socket ``` I've checked the msg_translator.c source file and there are many of `LM_CRIT("FIXME: {message}\n");` calls, and I wonder if the "FIXME" tag relates to the location of the error: a Kamailio error or there is an issue in the user code. Could I have more information about the "FIXME" tag? Thanks in advance!

2 7

rtpengine module dependencies
by Juha Heinanen 10 Oct '21

10 Oct '21

rtpengine module README tells this about module dependencies: 3.1. Kamailio Modules The following modules must be loaded before this module: tm module - (optional) if you want to have rtpengine_manage() fully functional Looks like this is not correct. If Kamailio connects to rtpengine over websocket protocol, then there is dependency on lwsc module. I haven't checked if lwsc module works without tls module when wss is used. -- Juha

1 0

Kamailio Inbound proxy to Asterisk - ACL Filtering
by Mihai 09 Oct '21

09 Oct '21

Hello, I have an issue with filtering on the asterisk side, my requests are: UsersPhones(bria) -> Kamailio -> Asterisk -> Sip Trunk Out. The goal is to manage a new layer of protection ( IP filtering / Whitelisting ). When I try to compile a list of Whitelisted IP in sip.conf I get this error: NOTICE[205]: acl.c:748 ast_apply_acl: SIP contact ACL: Rejecting '145.72.23.45' due to a failure to pass ACL '(BASELINE)' WARNING[205]: chan_sip.c:17061 parse_register_contact: Domain '5.12.16.2:48669' disallowed by contact ACL (violating IP 145.72.23.45) WARNING[205]: chan_sip.c:17933 register_verify: Registration denied because of contact ACL The IP 145.72.23.45, is the proxy kamailio and if I added it to sip.conf it works, but so does every ip afterwards. I tried with contactpermit also with permit, the result is the same as long as I permit the proxy ip it works. Is there something that I can do on the asterisk side to activate this filtering Or there is something that I can do in Kamailio so it will forward the realip ? contactdeny=0.0.0.0/0.0.0.0 contactpermit=145.72.23.45/32 contactpermit=5.12.16.2/32 Thanks in advance,

1 0

Nagios NRPE Plugin for Kamailio 5.x
by Angelo Sipper 08 Oct '21

08 Oct '21

Hi, I would like to monitor kamailio via our nagios. Is there any working plugin available for nagios nrpe to monitor shared memory and some other config variables for kamailio 5.x that someone has used and could suggest? Kind regards, Angelo

2 1

update max_while_loops in config
by Juha Heinanen 08 Oct '21

08 Oct '21

It is possible to update value of max_while_loops dynamically in config file? For example, there could be a need to increase the max in some while loop, but after the loop is done, decrease it again for other loops. There exists an rpc command to do that, but I haven't found how to do it in config file. I tried @cfg_seti.core.max_while_loops = 200; but got syntax error. -- Juha

3 6

Suspend INVITE between ip4 and ip6 users
by Péter Barabás 08 Oct '21

08 Oct '21

Hi, I try to modify the kamailio configuration to work between ipv4 and ipv6 clients. Clients are mobile sofphones, so they are mostly in background without registration. 1. When an INVITE arrives from IPV4 address, transaction is suspended and a push notification is sent to callee. 2. Callee gets push notification and registers to kamailio. 3. INVITE transaction continues. My kamailio config is based on this article: https://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6 using rtpengine. If clients are in foreground it works fine. But, when a client is in background, kamailio knows nothing about the callee’s IP address (ipv4 or ipv6). The problematic case is the call from IPV4 to IPV6. In this case the FLB_V4V6 flag is missing at continue, since in IPV4V6 route it cannot be set and the rtpengine tries the IPV4->IPV4 case. From the other side IPV6->IPV6. It is understandable, since FLB_V4V6 flag is missing in this case. My question is: where and when should I set this flag? Thanks. Peter

1 0

Missing line in line.count transformation
by Daniel Donoghue 08 Oct '21

08 Oct '21

I think I’ve found an edge case with the string transformations for line.count: In pv_trans.c, the following code does not appear to consider the last line if there are multiple lines and the last one is not terminated with \n. case TR_LINE_COUNT: n=0; for(i=0; i<val->rs.len; i++) if(val->rs.s[i]=='\n') n++; if(n==0 && val->rs.len>0) n = 1; val->flags = PV_TYPE_INT|PV_VAL_INT|PV_VAL_STR; val->ri = n; val->rs.s = int2str(val->ri, &val->rs.len); break; This means that my count is always one off unless I force a blank line at the end of my string. Also, this code does not cater for cases where there is a different line terminator, such as CR or CRLF as is the case when the string comes from a Mac or windows system, respectively; it might be useful to have a transformation for doing that as I’ve had to hack it using s.replace with hexadecimal escape codes (\r and \n do not work) in a variable. With every blessing, — Daniel Donoghue

4 5

Parsing Error in Timer Module of kamailio
by Surabhi Garg 07 Oct '21

07 Oct '21

Hi Team, Greetings! I am trying to use Timer Module of Kamailio to keep calling particular route at particular time interval. Here is the snippet of my config: loadmodule "timer.so" modparam("timer", "declare_timer", "MYTIMER=SHUTDOWN,5000,slow,enable"); route[SHUTDOWN] { xlog("system shutdown: $sht(graceful_shutdown=>shutdown)\n"); } But after restarting the Kamailio, I keep on getting parsing errors in every 5 sec and my route "SHUTDOWN" never get called. Which means timer is getting called in every 5 sec but not able to call the route. Could you please help me with this why these parsing errors coming? am I missing some arguments here? Kamailio Version: 5.5.X. Errors: Sep 23 15:29:31 N1VL-PA-SIP01 /usr/local/kamailio-5.5/sbin/kamailio[9907]: ERROR: <core> [core/parser/msg_parser.c:748]: parse_msg(): ERROR: parse_msg: message=<GET /timer HTTP/0.9#012#012> Sep 23 15:29:31 N1VL-PA-SIP01 /usr/local/kamailio-5.5/sbin/kamailio[9907]: ERROR: timer [timer.c:204]: timer_handler(): parse msg failed Sep 23 15:29:36 N1VL-PA-SIP01 /usr/local/kamailio-5.5/sbin/kamailio[9907]: ERROR: <core> [core/parser/msg_parser.c:748]: parse_msg(): ERROR: parse_msg: message=<GET /timer HTTP/0.9#012#012> Sep 23 15:29:36 N1VL-PA-SIP01 /usr/local/kamailio-5.5/sbin/kamailio[9907]: ERROR: timer [timer.c:204]: timer_handler(): parse msg failed Also, in place of timer module I tried using rtimer module as well which is also giving me similar results as per my requirement. But Could you please help me with the pros and cons of both the modules timer and rtimer. Any thoughts on this would be appreciated Surabhi Garg Mobile - 91 783 888 7523

2 2

[kamailio/kamailio] SIP Preconditions Settings?
by Luis Joel Borrego Soto 07 Oct '21

07 Oct '21

Hi Team, According with the RFC3312 (https://datatracker.ietf.org/doc/html/rfc3312) The SDP parameters are the following We define the following media level SDP attributes: current-status = "a=curr:" precondition-type SP status-type SP direction-tag desired-status = "a=des:" precondition-type SP strength-tag SP status-type SP direction-tag confirm-status = "a=conf:" precondition-type SP status-type SP direction-tag **precondition-type = "qos" | token strength-tag = ("mandatory" | "optional" | "none" = | "failure" | "unknown")** status-type = ("e2e" | "local" | "remote") direction-tag = ("none" | "send" | "recv" | "sendrecv") Which one should be the equivalent in the Kamailio?, is the a specific module? Br, Joel Borrego (joel.borrego)

3 3

Need kamailio to use advertise public IP only in cases of SIP communication over internet.
by Voip support 06 Oct '21

06 Oct '21

Dear Community, I have a need of communicating with other servers using private IP with private IP in Via and SDP connection information but at same time sometime need connect to public IP SIP server and on outgoing INVITE's i need advertise public IP in Record-Route and SDP Connection information. Currently if i work on listen=udp:privateip:5060 i get working the LAN part but cannot work over internet (no audio) but when i add advertise i get SDP public IP also over local network. Is it possible to solve this case using one NIC adapter? I am using RTPProxy. Please help me out. I tried to add second network adapter with advertise and mhomed=1 something started to work but i think i would need work on the call direction and different rtpproxy_manage handling on outside INVITEs and incoming 200 OK responses. I am not sure if this is the right way to do it - maybe there is some easier method of achieving what i need using one interface ? Best regards, Tom

4 3

Understanding regex format for subst_hf
by Joel Serrano 06 Oct '21

06 Oct '21

Hey guys, I'm trying to do a replacement regex using subst_hf but I can't seem to get the format right and the docs are confusing. *subst_hf: *docs say it uses perl-like regex (as I understand it, that would mean PCRE). Docs also say in the 'subexp' param that it uses the same format as *subst.* *subst: *at the beginning it says it uses perl or sed format, but in the '/re/repl/flags' param it says that sed format. https://www.kamailio.org/docs/modules/devel/modules/textops.html#textops.f.… 4.20. subst_hf(hf, subexp, flags) Perl-like substitutions in the body of a header field. Meaning of the parameters is as follows: - *hf* - header field name. - *subexp* - substitution expression in the same format as of the 'subst' function parameter. - *flags* - control flags - it has to be one of: a - all headers matching the name; f - only first header matching the name; l - only the last header matching the name. 4.16. subst('/re/repl/flags') Replaces re with repl (sed or perl like). Meaning of the parameters is as follows: - *'/re/repl/flags'* - sed like regular expression. flags can be a combination of i (case insensitive), g (global) or s (match newline don't treat it as end of line). 're' - is regular expression 'repl' - is replacement string - may contain pseudo-variables 'flags' - substitution flags (i - ignore case, g - global) I'm trying to use this: subst_hf("X-myheader", "/^(?!string1 |example2-|text3 )(.*)/myprefix \1/", "a") In an online tester using PCRE, the format is correct, but Kamailio doesn't like it: Oct 4 09:29:16 cops-n1 cops[15957]: ERROR: <core> [core/re.c:285]: subst_parser(): bad regular expression ^(?!string1 |example2-|text3 )(.*) in /^(?!string1 |example2-|text3 )(.*)/myprefix \1/ If I remove the negative lookahead chars (?!) then kamailio doesn't complain but the regex doesn't do what I want. Does this mean that Kamailio won't support negative lookahead for subst regex replacements? What I'm trying to achieve is something along: "If the value of the header Myheader doesn't start with ABC, DEF or HIJ, then prefix it with XYZ" Any suggestions/ideas on how to achieve this? Thanks, Joel.

3 7

seas module
by Daniel Paape 05 Oct '21

05 Oct '21

I am having some difficulties with the seas module under Kam 5.5.2. If my application server is not connected then the config file script below never returns if (!as_relay_t ("myserver")) { Xlog ("LM_NOTICE", "myserver not connected\n"); } A diagnostic in the "seas.c" file does report that the app server is not connected, but the one above is never printed. Any help here would be appreciated. This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer.

2 5

Kamailio/RTPengine as a proxy for FreePBX/Asterisk...
by Micah Quinn 03 Oct '21

03 Oct '21

Hello all, I'm new to Kamailio, so bear with me as I stumble through this. First, I'll describe what I'm trying to achieve at a high level and then perhaps somebody can advise me on whether Kamailio is a good fit for this solution or not. I'd like to be able to deploy a small appliance type server to our customer's sites that just runs Kamailio and a VPN connection back to our datacenter. At our datacenter, we run virtualized instances of Asterisk for each of our customers. The idea is that Kamailio would act as a transparent proxy through to the Asterisk instance under nominal conditions and as a basic SIP router in the case that the Asterisk instance is unavailable. This degraded functionality would then at least allow extension to extension calling even if the Internet or Asterisk instance is down. I'm currently using dispatcher with a single entry in preparation for a time when we might want to failover to another Asterisk instance. I'm forwarding all REGISTER and INVITE messages to the server chosen from ds_select_dst. Initially this all seems to work as I can register with a softphone and pjsip show endpoints shows my softphone connected. However, when I attempt to call any extension (my own or another) Asterisk responds to the INVITE message with a "401 Unauthorized" message and the typical "The person at extension XXXX is unavailable...". I know that more details might be necessary to troubleshoot this, but I didn't want to include everything in one post and risk cluttering it up with unnecessary information. If anyone can confirm that this is a reasonable way to approach the problem, I can then provide whatever relevant data is necessary to get deeper into it. (I've used sngrep, logging, asterisk cli, etc.) Thanks in advance for any help.

6 22

Kamailio 4.4 + rtpproxy behind the NAT (debian stretch 9.13)
by Youssef Boujraf 02 Oct '21

02 Oct '21

Dear, I am testing the kakamilio 4.4 with rtpproxy on Debian stretch 9.13 I have installed the packages - apt-get install kamailio and rtpproxy. - kamailio 4.4 - rtpproxy Basic version: 20040107 *My version of RTPPROXY doesn't have the -A parameter so that means without advertising there is no way to work behind NAT? That is what I have understood after spending one week on forums. Thanks if somebody could confirm otherwise, which way I need to go to figure out my issue?* # rtpproxy -v > Basic version: 20040107 > Extension 20050322: Support for multiple RTP streams and MOH > Extension 20060704: Support for extra parameter in the V command > Extension 20071116: Support for RTP re-packetization > Extension 20071218: Support for forking (copying) RTP stream > Extension 20080403: Support for RTP statistics querying > Extension 20081102: Support for setting codecs in the update/lookup command > Extension 20081224: Support for session timeout notifications > > # rtpproxy -help > rtpproxy: invalid option -- 'h' > usage: rtpproxy [-2fvFiPa] [-l addr1[/addr2]] [-6 addr1[/addr2]] [-s path] > [-t tos] [-r rdir [-S sdir]] [-T ttl] [-L nfiles] [-m port_min] > [-M port_max] [-u uname[:gname]] [-n timeout_socket] [-d > log_level[:log_facility]] > # > /etc/hosts 127.0.0.1 localhost > 127.0.1.1 sip.dom.xx sip > 192.168.1.19 sip.dom.xx sip > PUBLIC_IP sip.dom.xx sip > # The following lines are desirable for IPv6 capable hosts > ::1 localhost ip6-localhost ip6-loopback > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > */etc/kamailio/kamailio.cfg* kamailio.config > #!define PUBLIC_IP "xxx.xxx.xxx.xxx" > #!define PRIVATE_IP "192.168.1.19" > #!define PRIVATE_NET "192.168.1.0/24“ > listen=udp:PRIVATE_IP:5060 advertise PUBLIC_IP:5060 > > #!ifdef WITH_NAT > > # ----- rtpproxy params ----- > > modparam("rtpproxy", "rtpproxy_sock", "udp:PRIVATE_IP:7722") > > > # ----- nathelper params ----- > > modparam("nathelper", "natping_interval", 30) > > modparam("nathelper", "ping_nated_only", 1) > > modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) > > modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") > *Etc/default/rtpproxy* PRIVATE_IP=192.168.1.19 > > PUBLIC_IP=xxx.xxx.xxx.xxx > > rtpport_min= 10000 > > rtpport_max=20000 > > syslog=DBUG:LOG_LOCAL5 > > #Defaults for rtpproxy > #The control socket. > #CONTROL_SOCK="unix:/var/run/rtpproxy/rtpproxy.sock" > #To listen on an UDP socket, uncomment this line: > #CONTROL_SOCK=udp:127.0.0.1:7722 > #Additional options that are passed to the daemon. > EXTRA_OPTS="-l $PRIVATE_IP/$PUBLIC_IP ="-s $PRIVATE_IP:7222 -m $ > rtpport_min -M $rtpport_max -d $syslog"` > Thanks if you could route me to the right way. Best regards Yboujraf Email: yboujraf(a)gmail.com

3 6

Fail call from Webrct to PSTN SIP trunk
by Abdul Rahman Reza 01 Oct '21

01 Oct '21

Hi, good morning there is something I want to ask, I'm really stuck looking for a solution, haven't found it yet, So I want to make Webrct able to call SIP and PSTN numbers via SIP trunk, but it keeps failing For testing as follows: webrct => SIP OK webrct => PSTN NOK webrct => webrct OK SIP => webrct OK SIP => PSTN OK SIP => SIP OK Thank you very much in advance this is error log from kamailio webrct => PSTN gagal dan error muncul seperti ini : Aug 16 11:25:16 esbdev01 /usr/sbin/kamailio[28300]: INFO: : START WEBSOCKET : INVITE from sip:500@domain.name (IP:127.0.0.1:43402) websocket id 12 Aug 16 11:25:16 esbdev01 /usr/sbin/kamailio[28300]: INFO: : MANAGE_BRANCH: New branch [0] to sip:+6282311XXXXXX@IP_SIP_TRUNK:5060 Aug 16 11:25:16 esbdev01 /usr/sbin/kamailio[28300]: INFO: : NATMANAGE branch_id:0 ruri: sip:+6282311XXXXXX@IP_SIP_TRUNK:5060, method:INVITE, status:, extra_id: z9hG4bK46635730, rtpengine_manage: replace-origin replace-session-connection via-branch=extra rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP Aug 16 11:25:16 esbdev01 rtpengine[16670]: INFO: [eq07esfe0a3mcjvpait6]: [control] Received command ‘offer’ from 127.0.0.1:38616 Aug 16 11:25:16 esbdev01 rtpengine[16670]: NOTICE: [eq07esfe0a3mcjvpait6]: [core] Creating new call Aug 16 11:25:16 esbdev01 rtpengine[16670]: WARNING: [eq07esfe0a3mcjvpait6]: [core] Ignoring updated remote endpoint as the local socket is IPv4 Aug 16 11:25:16 esbdev01 rtpengine[16670]: WARNING: [eq07esfe0a3mcjvpait6]: [core] Ignoring updated remote endpoint as the local socket is IPv4 Aug 16 11:25:16 esbdev01 rtpengine[16670]: INFO: [eq07esfe0a3mcjvpait6]: [control] Replying to ‘offer’ from 127.0.0.1:38616 (elapsed time 0.005891 sec) Aug 16 11:25:16 esbdev01 /usr/sbin/kamailio[28280]: INFO: : BRANCH FAILED: z9hG4bK4663573 + 0 Aug 16 11:25:16 esbdev01 rtpengine[16670]: INFO: [eq07esfe0a3mcjvpait6]: [control] Received command ‘delete’ from 127.0.0.1:44664 Aug 16 11:25:16 esbdev01 rtpengine[16670]: INFO: [eq07esfe0a3mcjvpait6]: [core] Scheduling deletion of call branch ‘’ (via-branch ‘z9hG4bK46635730’) in 30 seconds Aug 16 11:25:16 esbdev01 rtpengine[16670]: INFO: [eq07esfe0a3mcjvpait6]: [control] Replying to ‘delete’ from 127.0.0.1:44664 (elapsed time 0.000210 sec) Aug 16 11:25:16 esbdev01 /usr/sbin/kamailio[28280]: INFO: : Failure: and this is log from webrct browser using jssip LoggerFactory.js:100 Mon Aug 16 2021 10:42:54 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | SessionDescriptionHandlerOptions: {"peerConnectionOptions":{"rtcConfiguration":{"iceServers":[{"urls":"turn:domain_name:443?transport=tcp","username":"websip","credential":"websip"},{"urls":"turns:domain_name:80?transport=tcp","username":"websip","credential":"websip"}]},"iceCheckingTimeout":5000}} LoggerFactory.js:100 Mon Aug 16 2021 10:42:54 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | initPeerConnection LoggerFactory.js:100 Mon Aug 16 2021 10:42:54 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | New peer connection created LoggerFactory.js:100 Mon Aug 16 2021 10:42:54 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | acquiring local media LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | acquired local media streams LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | createOffer LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | resetIceGatheringComplete LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | Setting local sdp. LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | sdp is v=0 o=- 5499752371154858348 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 1 a=extmap-allow-mixed a=msid-semantic: WMS 2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:c/YU a=ice-pwd:7VB8/SEvBOYMyPpKgYKzOpPK a=ice-options:trickle a=fingerprint:sha-256 92:73:F2:E2:70:7C:43:BD:59:3A:6C:F3:7D:B9:9F:75:19:81:4C:40:0E:DA:63:D9:FF:90:60:41:49:E6:B0:9C a=setup:actpass a=mid:0 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=sendrecv a=msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w f8941c64-0252-4ab7-b1c5-3731f47c9fd7 a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtcp-fb:111 transport-cc a=fmtp:111 minptime=10;useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:110 telephone-event/48000 a=rtpmap:112 telephone-event/32000 a=rtpmap:113 telephone-event/16000 a=rtpmap:126 telephone-event/8000 a=ssrc:3068753223 cname:vdFflh5e6U+kdnYw a=ssrc:3068753223 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w f8941c64-0252-4ab7-b1c5-3731f47c9fd7 a=ssrc:3068753223 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:3068753223 label:f8941c64-0252-4ab7-b1c5-3731f47c9fd7 m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:c/YU a=ice-pwd:7VB8/SEvBOYMyPpKgYKzOpPK a=ice-options:trickle a=fingerprint:sha-256 92:73:F2:E2:70:7C:43:BD:59:3A:6C:F3:7D:B9:9F:75:19:81:4C:40:0E:DA:63:D9:FF:90:60:41:49:E6:B0:9C a=setup:actpass a=mid:1 a=extmap:14 urn:ietf:params:rtp-hdrext:toffset a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:13 urn:3gpp:video-orientation a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=sendrecv a=msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=rtcp-mux a=rtcp-rsize a=rtpmap:96 VP8/90000 a=rtcp-fb:96 goog-remb a=rtcp-fb:96 transport-cc a=rtcp-fb:96 ccm fir a=rtcp-fb:96 nack a=rtcp-fb:96 nack pli a=rtpmap:97 rtx/90000 a=fmtp:97 apt=96 a=rtpmap:98 VP9/90000 a=rtcp-fb:98 goog-remb a=rtcp-fb:98 transport-cc a=rtcp-fb:98 ccm fir a=rtcp-fb:98 nack a=rtcp-fb:98 nack pli a=fmtp:98 profile-id=0 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=98 a=rtpmap:100 VP9/90000 a=rtcp-fb:100 goog-remb a=rtcp-fb:100 transport-cc a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=fmtp:100 profile-id=2 a=rtpmap:101 rtx/90000 a=fmtp:101 apt=100 a=rtpmap:102 H264/90000 a=rtcp-fb:102 goog-remb a=rtcp-fb:102 transport-cc a=rtcp-fb:102 ccm fir a=rtcp-fb:102 nack a=rtcp-fb:102 nack pli a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f a=rtpmap:121 rtx/90000 a=fmtp:121 apt=102 a=rtpmap:127 H264/90000 a=rtcp-fb:127 goog-remb a=rtcp-fb:127 transport-cc a=rtcp-fb:127 ccm fir a=rtcp-fb:127 nack a=rtcp-fb:127 nack pli a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f a=rtpmap:120 rtx/90000 a=fmtp:120 apt=127 a=rtpmap:125 H264/90000 a=rtcp-fb:125 goog-remb a=rtcp-fb:125 transport-cc a=rtcp-fb:125 ccm fir a=rtcp-fb:125 nack a=rtcp-fb:125 nack pli a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f a=rtpmap:107 rtx/90000 a=fmtp:107 apt=125 a=rtpmap:108 H264/90000 a=rtcp-fb:108 goog-remb a=rtcp-fb:108 transport-cc a=rtcp-fb:108 ccm fir a=rtcp-fb:108 nack a=rtcp-fb:108 nack pli a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f a=rtpmap:109 rtx/90000 a=fmtp:109 apt=108 a=rtpmap:35 AV1X/90000 a=rtcp-fb:35 goog-remb a=rtcp-fb:35 transport-cc a=rtcp-fb:35 ccm fir a=rtcp-fb:35 nack a=rtcp-fb:35 nack pli a=rtpmap:36 rtx/90000 a=fmtp:36 apt=35 a=rtpmap:124 H264/90000 a=rtcp-fb:124 goog-remb a=rtcp-fb:124 transport-cc a=rtcp-fb:124 ccm fir a=rtcp-fb:124 nack a=rtcp-fb:124 nack pli a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032 a=rtpmap:119 rtx/90000 a=fmtp:119 apt=124 a=rtpmap:123 H264/90000 a=rtcp-fb:123 goog-remb a=rtcp-fb:123 transport-cc a=rtcp-fb:123 ccm fir a=rtcp-fb:123 nack a=rtcp-fb:123 nack pli a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032 a=rtpmap:118 rtx/90000 a=fmtp:118 apt=123 a=rtpmap:114 red/90000 a=rtpmap:115 rtx/90000 a=fmtp:115 apt=114 a=rtpmap:116 ulpfec/90000 a=ssrc-group:FID 1593038176 4012956172 a=ssrc:1593038176 cname:vdFflh5e6U+kdnYw a=ssrc:1593038176 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:1593038176 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:1593038176 label:1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:4012956172 cname:vdFflh5e6U+kdnYw a=ssrc:4012956172 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:4012956172 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:4012956172 label:1e978692-178f-46cb-8c18-8f130343f637 LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | waitForIceGatheringComplete LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE is not complete. Returning promise LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | RTCIceGatheringState changed: gathering LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate received: candidate:3250795810 1 udp 2122260223 10.XX.XX.XX 63469 typ host generation 0 ufrag c/YU network-id 2 network-cost 50 LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate received: candidate:211156821 1 udp 2122194687 192.XXX.X.X 50637 typ host generation 0 ufrag c/YU network-id 1 network-cost 10 LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate received: candidate:3250795810 1 udp 2122260223 10.XX.XX.XX 55429 typ host generation 0 ufrag c/YU network-id 2 network-cost 50 LoggerFactory.js:100 Mon Aug 16 2021 10:42:55 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate received: candidate:211156821 1 udp 2122194687 192.XXX.X.X 50147 typ host generation 0 ufrag c/YU network-id 1 network-cost 10 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate received: candidate:2403387858 1 tcp 1518280447 10.XX.XX.XX 9 typ host tcptype active generation 0 ufrag c/YU network-id 2 network-cost 50 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate received: candidate:1108738981 1 tcp 1518214911 192.XXX.X.X 9 typ host tcptype active generation 0 ufrag c/YU network-id 1 network-cost 10 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate received: candidate:2403387858 1 tcp 1518280447 10.XX.XX.XX 9 typ host tcptype active generation 0 ufrag c/YU network-id 2 network-cost 50 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate received: candidate:1108738981 1 tcp 1518214911 192.XXX.X.X 9 typ host tcptype active generation 0 ufrag c/YU network-id 1 network-cost 10 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | RTCIceGatheringState changed: complete LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.transport | sending WebSocket message: INVITE sip:+6282311XXXXXX@domain_name SIP/2.0 Via: SIP/2.0/WSS asv5il0mh6sc.invalid;branch=z9hG4bK4035596 Max-Forwards: 70 To: <sip:+6282311XXXXXX@domain_name> From: "webrtc" <sip:500@domain_name>;tag=t9cuh03rp3 Call-ID: eq07e6in98hmjs1uulas CSeq: 8516 INVITE Contact: <sip:tfqbf6kb@asv5il0mh6sc.invalid;transport=ws;ob> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound User-Agent: SIP.js/0.13.6 Content-Type: application/sdp Content-Length: 6891 v=0 o=- 5499752371154858348 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 1 a=extmap-allow-mixed a=msid-semantic: WMS 2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w m=audio 63469 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 c=IN IP4 10.XX.XX.XX a=rtcp:9 IN IP4 0.0.0.0 a=candidate:3250795810 1 udp 2122260223 10.XX.XX.XX 63469 typ host generation 0 network-id 2 network-cost 50 a=candidate:211156821 1 udp 2122194687 192.XXX.X.X 50637 typ host generation 0 network-id 1 network-cost 10 a=candidate:2403387858 1 tcp 1518280447 10.XX.XX.XX 9 typ host tcptype active generation 0 network-id 2 network-cost 50 a=candidate:1108738981 1 tcp 1518214911 192.XXX.X.X 9 typ host tcptype active generation 0 network-id 1 network-cost 10 a=ice-ufrag:c/YU a=ice-pwd:7VB8/SEvBOYMyPpKgYKzOpPK a=ice-options:trickle a=fingerprint:sha-256 92:73:F2:E2:70:7C:43:BD:59:3A:6C:F3:7D:B9:9F:75:19:81:4C:40:0E:DA:63:D9:FF:90:60:41:49:E6:B0:9C a=setup:actpass a=mid:0 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=sendrecv a=msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w f8941c64-0252-4ab7-b1c5-3731f47c9fd7 a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtcp-fb:111 transport-cc a=fmtp:111 minptime=10;useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:110 telephone-event/48000 a=rtpmap:112 telephone-event/32000 a=rtpmap:113 telephone-event/16000 a=rtpmap:126 telephone-event/8000 a=ssrc:3068753223 cname:vdFflh5e6U+kdnYw a=ssrc:3068753223 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w f8941c64-0252-4ab7-b1c5-3731f47c9fd7 a=ssrc:3068753223 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:3068753223 label:f8941c64-0252-4ab7-b1c5-3731f47c9fd7 m=video 55429 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116 c=IN IP4 10.XX.XX.XX a=rtcp:9 IN IP4 0.0.0.0 a=candidate:3250795810 1 udp 2122260223 10.XX.XX.XX 55429 typ host generation 0 network-id 2 network-cost 50 a=candidate:211156821 1 udp 2122194687 192.XXX.X.X 50147 typ host generation 0 network-id 1 network-cost 10 a=candidate:2403387858 1 tcp 1518280447 10.XX.XX.XX 9 typ host tcptype active generation 0 network-id 2 network-cost 50 a=candidate:1108738981 1 tcp 1518214911 192.XXX.X.X 9 typ host tcptype active generation 0 network-id 1 network-cost 10 a=ice-ufrag:c/YU a=ice-pwd:7VB8/SEvBOYMyPpKgYKzOpPK a=ice-options:trickle a=fingerprint:sha-256 92:73:F2:E2:70:7C:43:BD:59:3A:6C:F3:7D:B9:9F:75:19:81:4C:40:0E:DA:63:D9:FF:90:60:41:49:E6:B0:9C a=setup:actpass a=mid:1 a=extmap:14 urn:ietf:params:rtp-hdrext:toffset a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:13 urn:3gpp:video-orientation a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=sendrecv a=msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=rtcp-mux a=rtcp-rsize a=rtpmap:96 VP8/90000 a=rtcp-fb:96 goog-remb a=rtcp-fb:96 transport-cc a=rtcp-fb:96 ccm fir a=rtcp-fb:96 nack a=rtcp-fb:96 nack pli a=rtpmap:97 rtx/90000 a=fmtp:97 apt=96 a=rtpmap:98 VP9/90000 a=rtcp-fb:98 goog-remb a=rtcp-fb:98 transport-cc a=rtcp-fb:98 ccm fir a=rtcp-fb:98 nack a=rtcp-fb:98 nack pli a=fmtp:98 profile-id=0 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=98 a=rtpmap:100 VP9/90000 a=rtcp-fb:100 goog-remb a=rtcp-fb:100 transport-cc a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=fmtp:100 profile-id=2 a=rtpmap:101 rtx/90000 a=fmtp:101 apt=100 a=rtpmap:102 H264/90000 a=rtcp-fb:102 goog-remb a=rtcp-fb:102 transport-cc a=rtcp-fb:102 ccm fir a=rtcp-fb:102 nack a=rtcp-fb:102 nack pli a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f a=rtpmap:121 rtx/90000 a=fmtp:121 apt=102 a=rtpmap:127 H264/90000 a=rtcp-fb:127 goog-remb a=rtcp-fb:127 transport-cc a=rtcp-fb:127 ccm fir a=rtcp-fb:127 nack a=rtcp-fb:127 nack pli a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f a=rtpmap:120 rtx/90000 a=fmtp:120 apt=127 a=rtpmap:125 H264/90000 a=rtcp-fb:125 goog-remb a=rtcp-fb:125 transport-cc a=rtcp-fb:125 ccm fir a=rtcp-fb:125 nack a=rtcp-fb:125 nack pli a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f a=rtpmap:107 rtx/90000 a=fmtp:107 apt=125 a=rtpmap:108 H264/90000 a=rtcp-fb:108 goog-remb a=rtcp-fb:108 transport-cc a=rtcp-fb:108 ccm fir a=rtcp-fb:108 nack a=rtcp-fb:108 nack pli a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f a=rtpmap:109 rtx/90000 a=fmtp:109 apt=108 a=rtpmap:35 AV1X/90000 a=rtcp-fb:35 goog-remb a=rtcp-fb:35 transport-cc a=rtcp-fb:35 ccm fir a=rtcp-fb:35 nack a=rtcp-fb:35 nack pli a=rtpmap:36 rtx/90000 a=fmtp:36 apt=35 a=rtpmap:124 H264/90000 a=rtcp-fb:124 goog-remb a=rtcp-fb:124 transport-cc a=rtcp-fb:124 ccm fir a=rtcp-fb:124 nack a=rtcp-fb:124 nack pli a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032 a=rtpmap:119 rtx/90000 a=fmtp:119 apt=124 a=rtpmap:123 H264/90000 a=rtcp-fb:123 goog-remb a=rtcp-fb:123 transport-cc a=rtcp-fb:123 ccm fir a=rtcp-fb:123 nack a=rtcp-fb:123 nack pli a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032 a=rtpmap:118 rtx/90000 a=fmtp:118 apt=123 a=rtpmap:114 red/90000 a=rtpmap:115 rtx/90000 a=fmtp:115 apt=114 a=rtpmap:116 ulpfec/90000 a=ssrc-group:FID 1593038176 4012956172 a=ssrc:1593038176 cname:vdFflh5e6U+kdnYw a=ssrc:1593038176 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:1593038176 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:1593038176 label:1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:4012956172 cname:vdFflh5e6U+kdnYw a=ssrc:4012956172 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:4012956172 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:4012956172 label:1e978692-178f-46cb-8c18-8f130343f637 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE candidate gathering complete LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.transport | received WebSocket text message: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/WSS asv5il0mh6sc.invalid;branch=z9hG4bK4035596;rport=43402;received=127.0.0.1 To: <sip:+6282311XXXXXX@domain_name >;tag=a2d3384ccaf3d0890b1d994026562a34.429c0000 From: "webrtc" <sip:500@domain_name>;tag=t9cuh03rp3 Call-ID: eq07e6in98hmjs1uulas CSeq: 8516 INVITE Proxy-Authenticate: Digest realm="domain_name", nonce="YRnf9GEZ3shCY5HMSWfzE6ctJ5ig1Kd7" Server: kamailio (5.5.0 (x86_64/linux)) Content-Length: 0 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.transport | sending WebSocket message: ACK sip:+6282311XXXXXX@domain_name SIP/2.0 Via: SIP/2.0/WSS asv5il0mh6sc.invalid;branch=z9hG4bK7163476 Max-Forwards: 70 To: <sip:+6282311XXXXXX@domain_name >;tag=a2d3384ccaf3d0890b1d994026562a34.429c0000 From: "webrtc" <sip:500@domain_name>;tag=t9cuh03rp3 Call-ID: eq07e6in98hmjs1uulas CSeq: 8516 ACK Supported: outbound User-Agent: SIP.js/0.13.6 Content-Length: 0 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.transport | sending WebSocket message: INVITE sip:+6282311XXXXXX@domain_name SIP/2.0 Via: SIP/2.0/WSS asv5il0mh6sc.invalid;branch=z9hG4bK6711062 Max-Forwards: 70 To: <sip:+6282311XXXXXX@domain_name> From: "webrtc" <sip:500@domain_name>;tag=t9cuh03rp3 Call-ID: eq07e6in98hmjs1uulas CSeq: 8517 INVITE Proxy-Authorization: Digest algorithm=MD5, username="500", realm="domain_name", nonce="YRnf9GEZ3shCY5HMSWfzE6ctJ5ig1Kd7", uri="sip:+6282311XXXXXX@domain_name", response="da7c3cf9c21d8aa85f72c5e723f8d42c" Contact: <sip:tfqbf6kb@asv5il0mh6sc.invalid;transport=ws;ob> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound User-Agent: SIP.js/0.13.6 Content-Type: application/sdp Content-Length: 6891 v=0 o=- 5499752371154858348 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 1 a=extmap-allow-mixed a=msid-semantic: WMS 2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w m=audio 63469 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 c=IN IP4 10.XX.XX.XX a=rtcp:9 IN IP4 0.0.0.0 a=candidate:3250795810 1 udp 2122260223 10.XX.XX.XX 63469 typ host generation 0 network-id 2 network-cost 50 a=candidate:211156821 1 udp 2122194687 192.XXX.X.X 50637 typ host generation 0 network-id 1 network-cost 10 a=candidate:2403387858 1 tcp 1518280447 10.XX.XX.XX 9 typ host tcptype active generation 0 network-id 2 network-cost 50 a=candidate:1108738981 1 tcp 1518214911 192.XXX.X.X 9 typ host tcptype active generation 0 network-id 1 network-cost 10 a=ice-ufrag:c/YU a=ice-pwd:7VB8/SEvBOYMyPpKgYKzOpPK a=ice-options:trickle a=fingerprint:sha-256 92:73:F2:E2:70:7C:43:BD:59:3A:6C:F3:7D:B9:9F:75:19:81:4C:40:0E:DA:63:D9:FF:90:60:41:49:E6:B0:9C a=setup:actpass a=mid:0 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=sendrecv a=msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w f8941c64-0252-4ab7-b1c5-3731f47c9fd7 a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtcp-fb:111 transport-cc a=fmtp:111 minptime=10;useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:110 telephone-event/48000 a=rtpmap:112 telephone-event/32000 a=rtpmap:113 telephone-event/16000 a=rtpmap:126 telephone-event/8000 a=ssrc:3068753223 cname:vdFflh5e6U+kdnYw a=ssrc:3068753223 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w f8941c64-0252-4ab7-b1c5-3731f47c9fd7 a=ssrc:3068753223 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:3068753223 label:f8941c64-0252-4ab7-b1c5-3731f47c9fd7 m=video 55429 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116 c=IN IP4 10.XX.XX.XX a=rtcp:9 IN IP4 0.0.0.0 a=candidate:3250795810 1 udp 2122260223 10.XX.XX.XX 55429 typ host generation 0 network-id 2 network-cost 50 a=candidate:211156821 1 udp 2122194687 192.XXX.X.X 50147 typ host generation 0 network-id 1 network-cost 10 a=candidate:2403387858 1 tcp 1518280447 10.XX.XX.XX 9 typ host tcptype active generation 0 network-id 2 network-cost 50 a=candidate:1108738981 1 tcp 1518214911 192.XXX.X.X 9 typ host tcptype active generation 0 network-id 1 network-cost 10 a=ice-ufrag:c/YU a=ice-pwd:7VB8/SEvBOYMyPpKgYKzOpPK a=ice-options:trickle a=fingerprint:sha-256 92:73:F2:E2:70:7C:43:BD:59:3A:6C:F3:7D:B9:9F:75:19:81:4C:40:0E:DA:63:D9:FF:90:60:41:49:E6:B0:9C a=setup:actpass a=mid:1 a=extmap:14 urn:ietf:params:rtp-hdrext:toffset a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:13 urn:3gpp:video-orientation a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=sendrecv a=msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=rtcp-mux a=rtcp-rsize a=rtpmap:96 VP8/90000 a=rtcp-fb:96 goog-remb a=rtcp-fb:96 transport-cc a=rtcp-fb:96 ccm fir a=rtcp-fb:96 nack a=rtcp-fb:96 nack pli a=rtpmap:97 rtx/90000 a=fmtp:97 apt=96 a=rtpmap:98 VP9/90000 a=rtcp-fb:98 goog-remb a=rtcp-fb:98 transport-cc a=rtcp-fb:98 ccm fir a=rtcp-fb:98 nack a=rtcp-fb:98 nack pli a=fmtp:98 profile-id=0 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=98 a=rtpmap:100 VP9/90000 a=rtcp-fb:100 goog-remb a=rtcp-fb:100 transport-cc a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=fmtp:100 profile-id=2 a=rtpmap:101 rtx/90000 a=fmtp:101 apt=100 a=rtpmap:102 H264/90000 a=rtcp-fb:102 goog-remb a=rtcp-fb:102 transport-cc a=rtcp-fb:102 ccm fir a=rtcp-fb:102 nack a=rtcp-fb:102 nack pli a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f a=rtpmap:121 rtx/90000 a=fmtp:121 apt=102 a=rtpmap:127 H264/90000 a=rtcp-fb:127 goog-remb a=rtcp-fb:127 transport-cc a=rtcp-fb:127 ccm fir a=rtcp-fb:127 nack a=rtcp-fb:127 nack pli a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f a=rtpmap:120 rtx/90000 a=fmtp:120 apt=127 a=rtpmap:125 H264/90000 a=rtcp-fb:125 goog-remb a=rtcp-fb:125 transport-cc a=rtcp-fb:125 ccm fir a=rtcp-fb:125 nack a=rtcp-fb:125 nack pli a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f a=rtpmap:107 rtx/90000 a=fmtp:107 apt=125 a=rtpmap:108 H264/90000 a=rtcp-fb:108 goog-remb a=rtcp-fb:108 transport-cc a=rtcp-fb:108 ccm fir a=rtcp-fb:108 nack a=rtcp-fb:108 nack pli a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f a=rtpmap:109 rtx/90000 a=fmtp:109 apt=108 a=rtpmap:35 AV1X/90000 a=rtcp-fb:35 goog-remb a=rtcp-fb:35 transport-cc a=rtcp-fb:35 ccm fir a=rtcp-fb:35 nack a=rtcp-fb:35 nack pli a=rtpmap:36 rtx/90000 a=fmtp:36 apt=35 a=rtpmap:124 H264/90000 a=rtcp-fb:124 goog-remb a=rtcp-fb:124 transport-cc a=rtcp-fb:124 ccm fir a=rtcp-fb:124 nack a=rtcp-fb:124 nack pli a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032 a=rtpmap:119 rtx/90000 a=fmtp:119 apt=124 a=rtpmap:123 H264/90000 a=rtcp-fb:123 goog-remb a=rtcp-fb:123 transport-cc a=rtcp-fb:123 ccm fir a=rtcp-fb:123 nack a=rtcp-fb:123 nack pli a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032 a=rtpmap:118 rtx/90000 a=fmtp:118 apt=123 a=rtpmap:114 red/90000 a=rtpmap:115 rtx/90000 a=fmtp:115 apt=114 a=rtpmap:116 ulpfec/90000 a=ssrc-group:FID 1593038176 4012956172 a=ssrc:1593038176 cname:vdFflh5e6U+kdnYw a=ssrc:1593038176 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:1593038176 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:1593038176 label:1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:4012956172 cname:vdFflh5e6U+kdnYw a=ssrc:4012956172 msid:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w 1e978692-178f-46cb-8c18-8f130343f637 a=ssrc:4012956172 mslabel:2yMfiToO0B0g0rBtLDd7vEaYmQ9PrZ0QUC9w a=ssrc:4012956172 label:1e978692-178f-46cb-8c18-8f130343f637 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.transport | received WebSocket text message: SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/WSS asv5il0mh6sc.invalid;branch=z9hG4bK6711062;rport=43402;received=127.0.0.1 To: <sip:+6282311XXXXXX@domain_name> From: "webrtc" <sip:500@domain_name>;tag=t9cuh03rp3 Call-ID: eq07e6in98hmjs1uulas CSeq: 8517 INVITE Server: kamailio (5.5.0 (x86_64/linux)) Content-Length: 0 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | ICE Connection State changed to iceConnectionChecking LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.transport | received WebSocket text message: SIP/2.0 500 Server Internal Error Via: SIP/2.0/WSS asv5il0mh6sc.invalid;branch=z9hG4bK6711062;received=127.0.0.1;rport=43402 Call-ID: eq07e6in98hmjs1uulas From: "webrtc"<sip:500@domain_name>;tag=t9cuh03rp3 To: <sip:+6282311XXXXXX@domain_name>;tag=23r36zzp CSeq: 8517 INVITE Warning: 399 03077.08860.B.005.422.228.0.15.01039.00000000.00000 "SDP body length beyond limit" Content-Length: 0 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.transport | sending WebSocket message: ACK sip:+6282311XXXXXX@domain_name SIP/2.0 Via: SIP/2.0/WSS asv5il0mh6sc.invalid;branch=z9hG4bK2860365 Max-Forwards: 70 To: <sip:+6282311XXXXXX@domain_name>;tag=23r36zzp From: "webrtc" <sip:500@domain_name>;tag=t9cuh03rp3 Call-ID: eq07e6in98hmjs1uulas CSeq: 8517 ACK Supported: outbound User-Agent: SIP.js/0.13.6 Content-Length: 0 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.inviteclientcontext | closing INVITE session eq07e6in98hmjs1uulast9cuh03rp3 LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | closing PeerConnection LoggerFactory.js:100 Mon Aug 16 2021 10:42:56 GMT+0700 (Western Indonesia Time) | sip.invitecontext.sessionDescriptionHandler | resetIceGatheringComplete and this is config of kamailio.cfg #!KAMAILIO # #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB #!define WITH_TLS #!define WITH_HOMER #!define WITH_WEBSOCKETS #!define WITH_ANTIFLOOD ##!define WITH_IPV6 ##!define WITH_BRIDGE_ON_FAIL #!define WITH_LOCALHOST_WS ##!define WITH_LOCALHOST_SIP #!define WITH_PSTN #!substdef "!MY_SIP_PORT!5060!g" #!substdef "!MY_SIPS_PORT!5061!g" #!substdef "!MY_WS_PORT!8080!g" #!substdef "!MY_WSS_PORT!4443!g" #!substdef "!MY_IP4_ADDR!IP-SERVER!g" #!substdef "!IP4_LOCALHOST!127.0.0.1!g" #!substdef "!MY_WS4_ADDR!tcp:MY_IP4_ADDR:MY_WS_PORT!g" #!substdef "!MY_WSS4_ADDR!tls:MY_IP4_ADDR:MY_WSS_PORT!g" #!substdef "!LOCALHOST_WS4_ADDR!tcp:IP4_LOCALHOST:MY_WS_PORT!g" #!substdef "!LOCALHOST_WSS4_ADDR!tls:IP4_LOCALHOST:MY_WSS_PORT!g" #!ifdef WITH_IPV6 #!substdef "!MY_IP6_ADDR![IPv6-SERVER]!g" #!substdef "!IP6_LOCALHOST![::1]!g" #!substdef "!MY_WS6_ADDR!tcp:MY_IP6_ADDR:MY_WS_PORT!g" #!substdef "!MY_WSS6_ADDR!tls:MY_IP6_ADDR:MY_WSS_PORT!g" #!substdef "!LOCALHOST_WS6_ADDR!tcp:IP6_LOCALHOST:MY_WS_PORT!g" #!substdef "!LOCALHOST_WSS6_ADDR!tls:IP6_LOCALHOST:MY_WSS_PORT!g" #!endif #!substdef "!MY_DOMAIN!DOMAIN-NAME!g" # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!ifndef DBURL #!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio" #!endif #!endif # - flags # FLT_ - per transaction (message) flags # FLB_ - per branch flags #!define FLT_NATS 5 #!define FLB_NATB 6 #!define FLB_NATSIPPING 7 #!define FLB_RTPWS 8 #!define FLB_IPV6 9 #!define FLB_V4V6 10 #!define FLB_BRIDGE 11 ####### Global Parameters ######### ### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR #!ifdef WITH_DEBUG debug=4 log_stderror=no #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 port=MY_SIP_PORT tls_port_no=MY_SIPS_PORT #!ifdef WITH_TLS enable_tls=yes #!endif listen=MY_IP4_ADDR #!ifdef WITH_LOCALHOST_SIP listen=IP4_LOCALHOST #!endif #!ifdef WITH_IPV6 listen=MY_IP6_ADDR #!ifdef WITH_LOCALHOST_SIP listen=IP6_LOCALHOST #!endif #!endif #!ifdef WITH_WEBSOCKETS listen=MY_WS4_ADDR #!ifdef WITH_LOCALHOST_WS listen=LOCALHOST_WS4_ADDR #!endif #!ifdef WITH_IPV6 listen=MY_WS6_ADDR #!ifdef WITH_LOCALHOST_WS listen=LOCALHOST_WS6_ADDR #!endif #!endif #!ifdef WITH_TLS listen=MY_WSS4_ADDR #!ifdef WITH_LOCALHOST_WS listen=LOCALHOST_WSS4_ADDR #!endif #!ifdef WITH_IPV6 listen=MY_WSS6_ADDR #!ifdef WITH_LOCALHOST_WS listen=LOCALHOST_WSS6_ADDR #!endif #!endif #!endif #!endif use_dns_cache = on # Use KAMAILIO internal DNS cache use_dns_failover = on # Depends on KAMAILIO internal DNS cache dns_srv_loadbalancing = on # dns_try_naptr = on # dns_retr_time=1 # Time in seconds before retrying a DNS request dns_retr_no=3 # Number of DNS retransmissions before giving up # Set protocol preference order - ignore target priority dns_naptr_ignore_rfc= yes # Ignore target NAPTR priority dns_tls_pref=50 # First priority: TLS dns_tcp_pref=30 # Second priority: TCP dns_udp_pref=10 # Third priority: UDP tcp_connection_lifetime=3604 tcp_accept_no_cl=yes tcp_rd_buf_size=16384 #!ifdef WITH_PSTN /* PSTN GW Routing * * - pstn.gw_ip: valid IP or hostname as string value, example: * pstn.gw_ip = "10.0.0.101" desc "My PSTN GW Address" * * - by default is empty to avoid misrouting */ pstn.gw_ip = "IP-SIP-TRUNK-SERVER" pstn.gw_port = "5060" #!endif # set paths to location of modules (to sources or installation folders) #!ifdef WITH_SRCPATH mpath="modules/" #!else mpath="/usr/lib64/kamailio/modules/" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "sdpops.so" loadmodule "textopsx.so" #!ifdef WITH_AUTH loadmodule "auth.so" loadmodule "auth_db.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!endif #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_HOMER loadmodule "siptrace.so" #!endif #!ifdef WITH_WEBSOCKETS loadmodule "xhttp.so" loadmodule "websocket.so" loadmodule "nathelper.so" loadmodule "rtpengine.so" #!endif #!ifdef WITH_ANTIFLOOD loadmodule "htable.so" loadmodule "pike.so" #!endif #!ifdef WITH_DEBUG loadmodule "debugger.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- registrar params ----- modparam("registrar", "method_filtering", 1) # max value for expires of registrations modparam("registrar", "max_expires", 3600) # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 2) #!endif # ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("auth_db", "load_credentials", "") #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", DBURL) # ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) #!endif ##!ifdef WITH_NAT # ----- rtpproxy params ----- modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:22222") modparam("rtpengine", "extra_id_pv", "$avp(extra_id)") # ----- nathelper params ----- modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@DOMAIN-NAME") modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") modparam("usrloc", "nat_bflag", FLB_NATB) ##!endif # ----- corex params ----- modparam("corex", "alias_subdomains", "MY_DOMAIN") #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/etc/kamailio/tls.cfg") modparam("tls", "tls_force_run", 1) #!endif #!ifdef WITH_WEBSOCKETS modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") #!endif #!ifdef WITH_HOMER #Siptrace modparam("siptrace", "duplicate_uri", "sip:127.0.0.1:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_flag", 22) modparam("siptrace", "trace_on", 1) #!endif #!ifdef WITH_ANTIFLOOD # ----- pike params ----- modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 16) modparam("pike", "remove_latency", 4) # ----- htable params ----- # ip ban htable with autoexpire after 5 minutes modparam("htable", "htable", "ipban=>size=8;autoexpire=300;") #!endif #!ifdef WITH_DEBUG # ----- debugger params ----- modparam("debugger", "cfgtrace", 1) #!endif ####### Routing Logic ######## request_route { #!ifdef WITH_HOMER # start duplicate the SIP message here sip_trace(); setflag(22); #!endif # per request initial checks route(REQINIT); xlog("L_INFO", "START: $rm from $fu (IP:$si:$sp)\n"); #!ifdef WITH_WEBSOCKETS if ($proto =~ "ws") { xlog("L_INFO", "START WEBSOCKET : $rm from $fu (IP:$si:$sp) websocket id $ws_conid\n"); } if (nat_uac_test(64)) { # Do NAT traversal stuff for requests from a WebSocket # connection - even if it is not behind a NAT! # This won't be needed in the future if Kamailio and the # WebSocket client support Outbound and Path. force_rport(); if (is_method("REGISTER")) { fix_nated_register(); } else if (!add_contact_alias()) { xlog("L_ERR", "Error aliasing contact <$ct>\n"); sl_send_reply("400", "Bad Request"); exit; } } #!endif # NAT detection route(NATDETECT); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) t_check_trans(); # authentication route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { record_route(); } # dispatch requests to foreign domains route(SIPOUT); ### requests for my local domains # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU == $null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations to PSTN route(PSTN); # user location service route(LOCATION); } # Wrapper for relaying requests route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if (!t_is_set("branch_route")) { t_on_branch("MANAGE_BRANCH"); } } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if (!t_is_set("onreply_route")) { t_on_reply("MANAGE_REPLY"); } } if (is_method("INVITE")) { if (!t_is_set("failure_route")) { t_on_failure("MANAGE_FAILURE"); } } if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { #!ifdef WITH_ANTIFLOOD # flood dection from same IP and traffic ban for a while # be sure you exclude checking trusted peers, such as pstn gateways # - local host excluded (e.g., loop to self) if (src_ip != myself) { if ($sht(ipban=>$si) != $null) { # ip is already blocked xdbg("request from blocked IP - $rm from $fu (IP:$si:$sp)\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); $sht(ipban=>$si) = 1; exit; } } #!endif if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if (!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { #!ifdef WITH_WEBSOCKETS if ($du == "") { if (!handle_ruri_alias()) { xlog("L_ERR", "Bad alias <$ru>\n"); sl_send_reply("400", "Bad Request"); exit; } } #!endif route(DLGURI); if (is_method("ACK")) { # ACK is forwarded statelessy route(NATMANAGE); } else if (is_method("NOTIFY")) { # Add Record-Route for in-dialog NOTIFY as per RFC 6665. record_route(); } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if (is_method("ACK")) { if (t_check_trans()) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server route(RELAY); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; } } # Handle SIP registrations route[REGISTRAR] { if (is_method("REGISTER")) { if (isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging ## setbflag(FLB_NATSIPPING); } #!ifdef WITH_IPV6 if (af == INET6) { setbflag(FLB_IPV6); } #!endif if (!save("location")) { sl_reply_error(); } exit; } } # USER location service route[LOCATION] { if (!lookup("location")) { $var(rc) = $rc; t_newtran(); switch ($var(rc)) { case -1: case -3: send_reply("404", "Not Found"); exit; case -2: send_reply("405", "Method Not Allowed"); exit; } } route(RELAY); exit; } # Presence server route route[PRESENCE] { if (!is_method("PUBLISH|SUBSCRIBE")) { return; } if (is_method("SUBSCRIBE") && $hdr(Event) == "message-summary") { # returns here if no voicemail server is configured sl_send_reply("404", "No voicemail service"); exit; } #!ifdef WITH_PRESENCE if (!t_newtran()) { sl_reply_error(); exit; } if (is_method("PUBLISH")) { handle_publish(); t_release(); } else if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU == $null) { sl_send_reply("404", "Not here"); exit; } return; } # Authentication route route[AUTH] { #!ifdef WITH_AUTH if (is_method("REGISTER") || from_uri == myself) { # authenticate requests if (!auth_check("$fd", "subscriber", "1")) { auth_challenge("$fd", "0"); exit; } # user authenticated - remove auth header if (!is_method("REGISTER|PUBLISH")) { consume_credentials(); } } # if caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (from_uri != myself && uri != myself) { sl_send_reply("403","Not relaying"); exit; } #!endif return; } # Caller NAT detection route route[NATDETECT] { #!ifdef WITH_IPV6 if(af==INET6) { return; } #!endif force_rport(); if (nat_uac_test("19")) { if (is_method("REGISTER")) { fix_nated_register(); } else if (is_first_hop()) { set_contact_alias(); } setflag(FLT_NATS); } return; } # NAT handling route[NATMANAGE] { if (is_request()) { if (has_totag()) { if (check_route_param("nat=yes")) { setbflag(FLB_NATB); } if (check_route_param("rtp=bridge")) { setbflag(FLB_BRIDGE); } if (check_route_param("rtp=ws")) { setbflag(FLB_RTPWS); } #!ifdef WITH_IPV6 if (check_route_param("rtp=v46")) { setbflag(FLB_V4V6); } #!endif } } if (!isbflagset(FLB_BRIDGE)) { return; } if ( !(isflagset(FLT_NATS) || isbflagset(FLB_NATB) || isbflagset(FLB_RTPWS) #!ifdef WITH_IPV6 || isbflagset(FLB_V4V6) #!endif )) { return; } $xavp(r=>$T_branch_idx) = "replace-origin replace-session-connection"; if (!nat_uac_test("8")) { $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " trust-address"; } if (is_request()) { if (!has_totag()) { if (!t_is_failure_route()) { $avp(extra_id) = @via[1].branch + $T_branch_idx; $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " via-branch=extra"; } } } if (is_reply()) { $avp(extra_id) = @via[2].branch + $T_branch_idx; $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " via-branch=extra"; } #!ifdef WITH_IPV6 if (af == INET && isbflagset(FLB_IPV6)) { # IPv4 --> IPv6 $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " address-family=IP6"; } else if (af == INET6 && !isbflagset(FLB_IPV6)) { # IPv6 --> IPv4 $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " address-family=IP4"; } #!endif if (isbflagset(FLB_RTPWS)) { if ($proto =~ "ws") { # web --> SIP $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP"; } else { # SIP --> web $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-offer generate-mid DTLS=passive SDES-off ICE=force RTP/SAVPF"; } } else { if ($proto =~ "ws") { # web --> web $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " generate-mid DTLS=passive SDES-off ICE=force"; } # else { # $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + ""; # } } xlog("L_INFO", "NATMANAGE branch_id:$T_branch_idx ruri: $ru, method:$rm, status:$rs, extra_id: $avp(extra_id), rtpengine_manage: $xavp(r=>$T_branch_idx)\n"); rtpengine_manage($xavp(r=>$T_branch_idx)); if (is_request()) { if (!has_totag()) { if (t_is_branch_route()) { if (isbflagset(FLB_NATB)) { add_rr_param(";nat=yes"); } if (isbflagset(FLB_BRIDGE)) { add_rr_param(";rtp=bridge"); } if (isbflagset(FLB_RTPWS)) { add_rr_param(";rtp=ws"); } #!ifdef WITH_IPV6 if (isbflagset(FLB_V4V6)) { add_rr_param(";rtp=v46"); } #!endif } } } if (is_reply()) { if (isbflagset(FLB_NATB)) { if (is_first_hop()) { if (af == INET) { set_contact_alias(); } } } } return; } # URI update for dialog requests route[DLGURI] { if (!isdsturiset()) { handle_ruri_alias(); } return; } # Routing to foreign domains route[SIPOUT] { if (!uri == myself) { append_hf("P-hint: outbound\r\n"); route(RELAY); } } route[BRIDGING] { if (!has_totag()) { if ($proto =~ "ws" && !($ru =~ "transport=ws")) { # Coming from WS, NOT to WS setbflag(FLB_RTPWS); # Need bridging } else if (!($proto =~ "ws") && $ru =~ "transport=ws") { # Coming from NOT WS, going to WS setbflag(FLB_RTPWS); # Need bridging } #!ifdef WITH_IPV6 if (af == INET6 && !isbflagset(FLB_IPV6)) { setbflag(FLB_V4V6); } else if(af == INET && isbflagset(FLB_IPV6)) { setbflag(FLB_V4V6); } #!endif } } # manage outgoing branches branch_route[MANAGE_BRANCH] { xlog("L_INFO", "MANAGE_BRANCH: New branch [$T_branch_idx] to $ru\n"); t_on_branch_failure("rtpengine"); #!ifndef WITH_BRIDGE_ON_FAIL setbflag(FLB_BRIDGE); #!endif route(BRIDGING); route(NATMANAGE); } # manage incoming replies onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if (status =~ "[12][0-9][0-9]") { route(NATMANAGE); } } # manage failure routing cases failure_route[MANAGE_FAILURE] { xlog("L_INFO", "Failure: $rs"); } #!ifdef WITH_WEBSOCKETS onreply_route { if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT) && !(proto == WS || proto == WSS))) { xlog("L_WARN", "SIP response received on $Rp\n"); drop; } if (nat_uac_test(64)) { # Do NAT traversal stuff for replies to a WebSocket connection # - even if it is not behind a NAT! # This won't be needed in the future if Kamailio and the # WebSocket client support Outbound and Path. add_contact_alias(); } } event_route[tm:branch-failure:rtpengine] { xlog("L_INFO", "BRANCH FAILED: $sel(via[1].branch) + $T_branch_idx"); #!ifdef WITH_BRIDGE_ON_FAIL if (!isbflagset(FLB_BRIDGE) && t_check_status("415|488")) { t_reuse_branch(); setbflag(FLB_BRIDGE); xlog("L_INFO", "event_route[branch-failure:rtpengine]: trying again\n"); route(RELAY); } else { $avp(extra_id) = @via[1].branch + $T_branch_idx; rtpengine_delete("via-branch=extra"); xlog("L_INFO", "event_route[branch-failure:rtpengine]: failed\n"); } #!else $avp(extra_id) = @via[1].branch + $T_branch_idx; rtpengine_delete("via-branch=extra"); #!endif } event_route[xhttp:request] { set_reply_close(); set_reply_no_connect(); if ($Rp != MY_WS_PORT #!ifdef WITH_TLS && $Rp != MY_WSS_PORT #!endif ) { xlog("L_WARN", "HTTP request received on $Rp\n"); xhttp_reply("403", "Forbidden", "", ""); exit; } xlog("L_INFO", "HTTP Request Received\n"); if ($hdr(Upgrade) =~ "websocket" && $hdr(Connection) =~ "Upgrade" && $rm =~ "GET" ) { # Validate Host - make sure the client is using the correct # alias for WebSockets if ($hdr(Host) == $null || !is_myself("sip:" + $hdr(Host))) { xlog("L_WARN", "Bad host $hdr(Host)\n"); xhttp_reply("403", "Forbidden", "", ""); exit; } # Optional... validate Origin - make sure the client is from an # authorised website. For example, # # if ($hdr(Origin) != "https://example.com" # && $hdr(Origin) != "https://example.com") { # xlog("L_WARN", "Unauthorised client $hdr(Origin)\n"); # xhttp_reply("403", "Forbidden", "", ""); # exit; # } # Optional... perform HTTP authentication # ws_handle_handshake() exits (no further configuration file # processing of the request) when complete. if (ws_handle_handshake()) { # Optional... cache some information about the # successful connection exit; } } xhttp_reply("404", "Not Found", "", ""); } event_route[websocket:closed] { xlog("L_INFO", "WebSocket connection from $si:$sp has closed\n"); } #!endif # PSTN GW routing route[PSTN] { #!ifdef WITH_PSTN # check if PSTN GW IP is defined if (strempty($sel(cfg_get.pstn.gw_ip))) { xlog("SCRIPT: PSTN routing enabled but pstn.gw_ip not defined\n"); return; } # route to PSTN dialed numbers starting with '+' or '00' # (international format) # - update the condition to match your dialing rules for PSTN routing if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return; # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } # normalize target number for pstn gateway # - convert leading 00 to + if (starts_with("$rU", "00")) { strip(2); prefix("+"); } if (strempty($sel(cfg_get.pstn.gw_port))) { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); } else { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ":" + $sel(cfg_get.pstn.gw_port); } route(RELAY); exit; #!endif return; }

2 2

ACK not accepted
by Angelo Sipper 01 Oct '21

01 Oct '21

Hi, I am having a problem with some inbound calls that all have the below behavior. My setup has: Carrier(UDP) -> (UDP)Kamailio1(UDP) -> (UDP)Kamailio2(TLS) -> (TLS)UAC Kamailio1 has Topos Module. UAC is behind NAT with LAN IP 192.168.1.105 and Public 200.200.200.30 Carrier IP 50.50.50.19, Kamailio1 IP 100.100.100.243, Kamailio2 IP 100.100.100.210 The Carrier sends in a new call and the call is answered from the UAC with 200 OK SDP. Carrier sends ACK and it looks like it reaches the UAC but, UAC still resends several times 200 OK and carrier sends server ACK that arrives or not ??? to UAC until finally UAC sends a BYE. On the SIP flow you can see that Kamailio2 sends the ACK to 192.168.1.105 and not to 200.200.200.30. Is this ok?? Another thing to mention is that Kamailio2 that has the UAC connected via TLS, can be used fine from the UAC to make an outbound call following the reverse path, but on the inbound we have the below. Any help will be much appreciated, ACK from Kamailio2 100.100.100.210 to UAC Session Initiation Protocol (ACK) Request-Line: ACK sip:btpsh-f3-6153392a-5fa-5@192.168.1.105:5061;transport=TLS SIP/2.0 Message Header Via: SIP/2.0/TLS 100.100.100.210:5061 ;branch=z9hG4bKfc5f.67a77810bcdafe811ea3672a027450d8.0 Via: SIP/2.0/UDP 100.100.100.243;rport=5060;branch=z9hG4bKfc5f.e2b515e9c8c33d2bd05682f26df24e39.0 Call-ID: isbcaqhye0rozjgeghorzav1vtytoqztkheq(a)B.5.108.ims.forthnet.gr [Generated Call-ID: isbcaqhye0rozjgeghorzav1vtytoqztkheq(a)B.5.108.ims.incarrier.com] From: <sip:987654321@ims.carrier.com ;user=phone>;tag=ZZ58CDf_CZ.Yj2U5 To: <sip:23456789@ims.carrier.com ;user=phone>;tag=0120779a-edf4-464a-9c43-2ddf54459083 CSeq: 1 ACK Max-Forwards: 64 Request-Disposition: no-fork Content-Length: 0 Contact: <sip:btpsh-f3-6153392a-5fa-5@100.100.100.243> |Time | 50.50.50.19 | 100.100.100.210 | 192.168.1.105 | | | | 100.100.100.243 | | 200.200.200.30 | |0.000000 | INVITE SDP (g711A te | | | |SIP INVITE From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> Call-ID:isbcaqhye0rozjgeghorzav1vtytoqztkheq@B.5.108.ims.incarrier.gr CSeq:1 | |(5060) ------------------> (5060) | | | | |0.001737 | 100 trying -- your c | | | |SIP Status 100 trying -- your call is important to us | |(5060) <------------------ (5060) | | | | |0.074622 | | INVITE SDP (g711A te | | |SIP INVITE From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |0.074797 | | INVITE SDP (g711A te | | |SIP INVITE From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |0.081110 | | 100 trying -- your c | | |SIP Status 100 trying -- your call is important to us | | |(5060) <------------------ (5060) | | | |0.082070 | | 100 trying -- your c | | |SIP Status 100 trying -- your call is important to us | | |(5060) <------------------ (5060) | | | |0.082833 | | | INVITE SDP (g711A te | |SIP INVITE From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) ------------------> (37275) | | |0.163871 | | | 100 Trying| | |SIP Status 100 Trying | | | |(5061) <------------------ (37275) | | |0.447621 | | | 180 Ringing | |SIP Status 180 Ringing | | | |(5061) <------------------ (37275) | | |0.448004 | | 180 Ringing | | |SIP Status 180 Ringing | | |(5060) <------------------ (5060) | | | |0.448765 | | 180 Ringing | | |SIP Status 180 Ringing | | |(5060) <------------------ (5060) | | | |0.465033 | 180 Ringing | | | |SIP Status 180 Ringing | |(5060) <------------------ (5060) | | | | |2.529599 | | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |2.733556 | | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |2.734596 | | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |2.864311 | 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |3.024789 | | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |3.025005 | | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |3.025854 | | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |3.034979 | 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |3.106784 | ACK | | | | |SIP Request INVITE ACK 200 CSeq:1 | |(5060) ------------------> (5060) | | | | |3.126287 | | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |3.126542 | | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |3.145821 | | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |4.025449 | | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |4.025743 | | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |4.026548 | | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |4.033198 | 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |4.094832 | ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |4.102992 | | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |4.103316 | | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |4.106301 | | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |6.025167 | | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |6.025543 | | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |6.026377 | | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |6.034778 | 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |6.096896 | ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |6.104675 | | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |6.104910 | | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |6.108907 | | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |10.024538| | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |10.024866| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |10.025750| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |10.033461| 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |10.095387| ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |10.102265| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |10.102449| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |10.105760| | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |14.025310| | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |14.025585| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |14.026528| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |14.037027| 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |14.099479| ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |14.111540| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |14.111708| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |14.116089| | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |18.025311| | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |18.025659| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |18.026572| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |18.034736| 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |18.096101| ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |18.106560| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |18.106687| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |18.111007| | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |22.024673| | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |22.024953| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |22.026120| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |22.033514| 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |22.095104| ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |22.105921| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |22.106043| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |22.110298| | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |26.031501| | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |26.031903| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |26.033136| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |26.040343| 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |26.101967| ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |26.111938| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |26.112432| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |26.118306| | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |30.035446| | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |30.035693| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |30.036501| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |30.044170| 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |30.106395| ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |30.116960| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |30.117412| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |30.129913| | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |34.026492| | | 200 OK SDP (g711A) | |SIP Status 200 OK | | | |(5061) <------------------ (37275) | | |34.026807| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |34.027775| | 200 OK SDP (g711A) | | |SIP Status 200 OK | | |(5060) <------------------ (5060) | | | |34.035453| 200 OK SDP (g711A) | | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | | | |34.097385| ACK | | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | |(5060) ------------------> (5060) | | | | |34.106319| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |34.106681| | ACK | | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | |(5060) ------------------> (5060) | | | |34.110714| | | ACK | | |SIP ACK From: < sip:987654321@ims.carrier.com;user=phone> To:<sip:123456789@ims.carrier.com;user=phone> CSeq:1 | | | |(5061) --------------------------------------> (5061) | |34.526688| | | BYE | | |SIP Request BYE CSeq:15322 | | | |(5061) <------------------ (37275) | | |34.528722| | BYE | | | |SIP Request BYE CSeq:15322 | | |(5060) <------------------ (5060) | | | |34.529704| | BYE | | | |SIP Request BYE CSeq:15322 | | |(5060) <------------------ (5060) | | | |34.668418| BYE | | | | |SIP Request BYE CSeq:15322 | |(5060) <------------------ (5060) | | | | |34.788963| 200 OK | | | | |SIP Status 200 OK | |(5060) ------------------> (5060) | | | | |34.796051| | 200 OK | | | |SIP Status 200 OK | | |(5060) ------------------> (5060) | | | |34.796205| | 200 OK | | | |SIP Status 200 OK | | |(5060) ------------------> (5060) | | | |34.796604| | | 200 OK | | |SIP Status 200 OK | | | |(5061) ------------------> (37275) | | Kind regards, Angelo

1 3

Querying presence state from config file
by Igor Olhovskiy 01 Oct '21

01 Oct '21

Hello! Is there any method of querying presence (dialog) state for particular endpoint from config file other than that direct query to presence tables in database? Idea is to reflect server-side DND state as "confirmed" (talking) , so I need to skip certain PUBLISH messages not to reset this state. -- Best regards, Igor

2 2

kamailio 4.4 + RTPPROXY - virtualbox - setup - callee or caller sends INVITE during the conversation and at REGISTER EXPIRES stop the connection
by Youssef Boujraf 01 Oct '21

01 Oct '21

Dear Thanks for your quick reply and sorry for spamming your mailbox. I am very confused about the setup of kamailio.cfg and rtpproxy. I have an existing kamailio 4.4 - rtpproxy running and I get the config files from both and setup the new vm. Just private connection works but the idea is to have connection from outside too. I am sure there is a mismatch with public ip, natting and/or setup of the vm hosts file. - architecture: *- 1x virtualbox* + 1x vm with bridge mode for network (get private ip address from the router). I suppose this is the PRIVATE_IP *+ 1x desktop (windows)* hosting a sipphone here Microsip ( https://www.microsip.org/) *- 1x modem/router* from the telecom provider - bbox-3V+ from PROXIMUS + forced in DMZ host the Kamailio server PRIVATE_IP [image: 211001 - kamailio architecture and settings.png] - the hosts file from Kamailio + rtpproxy is ( Maybe something is wrong or missing) /etc/hosts 127.0.0.1 localhost > 127.0.1.1 sipsecure.by-systems.be sipsecure > 192.168.1.19 sipsecure.by-systems.be sipsecure > xxx.XXX.xxx.XXX sipsecure.by-systems.be sipsecure > # The following lines are desirable for IPv6 capable hosts > ::1 localhost ip6-localhost ip6-loopback > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > */etc/kamailio/kamailio.cfg* kamailio.config > #!define PUBLIC_IP "xxx.xxx.xxx.xxx" > #!define PRIVATE_IP "192.168.1.19" > #!define PRIVATE_NET "192.168.1.0/24“ > > #!ifdef WITH_NAT > > # ----- rtpproxy params ----- > > modparam("rtpproxy", "rtpproxy_sock", "udp:PRIVATE_IP:7722") > > > # ----- nathelper params ----- > > modparam("nathelper", "natping_interval", 30) > > modparam("nathelper", "ping_nated_only", 1) > > modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) > > modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") > *Etc/default/rtpproxy* PRIVATE_IP=192.168.1.19 > > PUBLIC_IP=xxx.xxx.xxx.xxx > > rtpport_min= 10000 > > rtpport_max=20000 > > syslog=DBUG:LOG_LOCAL5 > > #Defaults for rtpproxy > #The control socket. > #CONTROL_SOCK="unix:/var/run/rtpproxy/rtpproxy.sock" > #To listen on an UDP socket, uncomment this line: > #CONTROL_SOCK=udp:127.0.0.1:7722 > #Additional options that are passed to the daemon. > EXTRA_OPTS="-l $PRIVATE_IP/$PUBLIC_IP ="-s $PRIVATE_IP:7222 -m $ > rtpport_min -M $rtpport_max -d $syslog"` > - *Misconfiguring the VM* That means do I need to use setup 1 or 2 or another 1. 2x NIC interfaces (one with private ip, second from dmz ip + NAT1:1 public ip) 2. 1x NIC interface (one private ip and natted 1:1 with public address) - *test* 1. *use case 1 : *connect two (2x) sipphone from private network (included kamailio) = OK 2. *use case 2 :* connect one (1x) codec from private ip and one (1x) codec from public network (like mobile) = = issue - disconnect after 30 s (register expires) start a conversation with audio but the caller or the callee continues to send and INVITE message. 3. *use case 3 :* connect two (2x) sipphone from public network = issue - disconnect after 30 s (register expires) start a conversation with audio but the caller or the callee continue to send an INVITE message. Best Regards, Youssef BOUJRAF

1 0

RTPEngine + Kamailio state question
by Alex Balashov 30 Sep '21

30 Sep '21

Hi, Sorry if I missed any developments on this, but: Kamailio does keep a runtime association of Call-ID+Ftag => RTPEngine instance, which is significant if an RTPEngine set with multiple members is used, or if a non-default set is used for a given call. When Kamailio is restarted, this runtime association goes away, so any subsequent offer/answer cycles or any other commands will (maybe) go to the wrong RTPEngine and/or the wrong set. Last time I checked a few years ago, there was no way to persist this association across restarts. Has this changed? Thanks! — Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

3 6

Sipwise SEMS
by David Villasmil 30 Sep '21

30 Sep '21

Hello guys, I know SEMS can provide conference, voicemail, and other services. In theory it’s also a B2BUA. Could I use a python script to provide a simple routing service? I.e.: receive an invite and send it somewhere else based on some routing logic? Thanks all David -- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

10 22

using LDAP as database ?
by Volker Denneberg 28 Sep '21

28 Sep '21

Hi, I am searching for a setup where phones register at a central kamailio and kamailio shares these contact infos with multiple asterisks. So they all need to share a database. For redundancy reasons, the database should work across 2 datacenters. As far as 1 understood there are some options * use mysql - good chances to find example code, Siremis API, seems to be the standard solution * use redis - more performant than mysql * use ldap - good chances to integrate with existing IT management but most difficult to configure Maybe I missed a better approach? Kamailio's ldap driver (http://www.kamailio.net/docs/modules/5.3.x/modules/db2_ldap.html) seems to be from 2008 - is it still recommended ? Kind regards, Volker

2 1

siptrace & topos modules on 5.3
by Angelo Sipper 24 Sep '21

24 Sep '21

Hi, We are using kamailio 5.3 latest version with the topos module. We have added Homer 7 latest version to consolidate traces from all kamailios and we have enabled siptrace module on kamailio to send data to homer. What we have seen up today is that traces on homer have sip headers before topos changes. So if I look at the same call on sngrep on the kamailio machine, I see the correct topos changed headers. If I check the same call on Homer I see headers without topos changes. Also we get duplicate headers on ACKs on homer. I was wondering what we have done wrong in the config and we have these results on homer. Any help will be much appreciated! Our config has: ===========- #!substdef "!MY_HOMER_CAPTURE!sip:MY_HOMER_IP_ADDR:MY_HOMER_PORT!g" #!substdef "!MY_LOCAL_SENDSOCK!sip:MY_KAMAILIO_IP:MY_LOCAL_SEND_PORT!g" loadmodule "topos.so" loadmodule "siptrace.so" modparam("siptrace", "force_send_sock", "MY_LOCAL_SENDSOCK") modparam("siptrace", "duplicate_uri", "MY_HOMER_CAPTURE") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_mode", 0) modparam("siptrace", "hep_capture_id", NODE_ID) modparam("topos", "db_url", DBURL) modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 130) # 3 Min modparam("topos", "dialog_expire", 10800) # 3 Hours modparam("topos", "clean_interval", 60) modparam("topos", "event_mode", 3) request_route { sip_trace_mode("t"); ........ } onsend_route { if (is_method("ACK")) { sip_trace(); } } ============== Thank you! Kind regards, Angelo

3 5

Info: APT Debian/Ubuntu Packages Archive
by Daniel-Constantin Mierla 24 Sep '21

24 Sep '21

Hello, a new server is available to offer APT repositories for each released version of Kamailio: * https://deb-archive.kamailio.org/ It aims to offer a way to downgrade to an older version, if someone wants it for various reasons. At this moment it offers dedicated APT repositories for Kamailio 5.3.8, 5.4.6, 5.4.7, 5.5.1 and 5.5.2. More details were posted in a news article at: * https://www.kamailio.org/w/2021/09/apt-debian-packages-archive/ Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online Nov 08-11, 2021 (Europe Timezone) - Nov 22-25, 2021 (America Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/

1 0

PRACK with UDP to TCP translation send over wrong protocol
by Angelo Sipper 24 Sep '21

24 Sep '21

Hello, We have the following setup and I am having trouble passing the PRACK with correct protocol to the provider. UAC (OverTLS) ->(UDP)Kamailio1 (UDP)-> (UDP)Kamailio2 (TCP)-> (TCP)Provider UAC : 10.2.1.160 NATED to 100.100.100.61 <http://50.50.50.50:5065/> (TLS) Kamailio1 Sockets: 50.50.50.210:5061 <http://170.170.170.210:5061/> (TLS), 50.50.50.210:5060 <http://170.170.170.210:5060/> (UDP) Kamailio2 Sockets: 50.50.50.182:5060 <http://170.170.170.170:5060/> (UDP) 50.50.50.182:5080 <http://170.170.170.170:5060/> (TCP) Provider: 200.200.200.209:5060 <http://200.200.200.193:5060/> (TCP) We use dispatcher on Kamailio1 & Kamailio2 The invite goes fine from UCA up to the provider and the provider responses arrive to UAC fine. The PRACK from UAC to kamailio1 goes fine to Kamaili02 but, Kamailio2 uses the UDP socket to send to the provider so the PRACK does not arrive to the provider and the call is canceled. If the provider is on UDP everything works fine. Below I have the trace. What should I look for in the config to resolve this wrong protocol/socket on the PRACK? Kamailio2 Details: Sockets ====== listen=udp:50.50.50.182:5060 listen=tcp: 50.50.50.182:5080 On the rr module I have ================== modparam("rr", "enable_double_rr", 1) modparam("rr", "append_fromtag", 1) modparam("rr", "enable_full_lr", 1) CONFIG REQINIT & WITHINDLG PARTS ================================ route[REQINIT] { set_reply_no_connect(); force_rport(); if (!mf_process_maxfwd_header("10")) { xlog("L_ERROR","Too Many Hops Rejecting!"); sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS") && uri==myself && $rU==$null) { sl_send_reply("200","Keepalive"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp sanity 1511\n"); exit; } if(!sanity_check("17895", "7")) { xlog("Malformed SIP request from $si:$sp sanity 17895\n"); exit; } } route[WITHINDLG] { if (!has_totag()) return; if (loose_route()) { if (is_method("BYE")) { rtpengine_query(); rtpengine_delete(); } route(RELAY_OUT); } if ( is_method("ACK") ) { #if (t_lookup_request()) { if (t_check_trans()) { route(RELAY_OUT); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not Allowed"); exit; } TRACE ====== 50.50.50.210:5060 50.50.50.182:5060 50.50.50.182:32818 200.200.200.209:5060 qqqqqqqqqqwqqqqqqq qqqqqqqqqqwqqqqqqq qqqqqqqqqqwqqqqqqqq qqqqqqqqqqqwqqqqqqqqq a 15:31:11.787490 x INVITE (SDP) x x x a +0.003099 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x x a 15:31:11.790589 x 100 trying -- your call is x x x a +0.002220 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x x a 15:31:11.792809 x x x INVITE (SDP) x a +0.020725 x x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x a 15:31:11.813534 x x x 100 Trying x a +2.628884 x x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x a 15:31:14.442418 x x x 183 Session Progress (SDP) x a +0.001572 x x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x a 15:31:14.443990 x 183 Session Progress (SDP) x x x a +0.299221 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x x a 15:31:14.743211 x PRACK x x x a +0.043114 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x x a 15:31:14.786325 x x PRACK x a +0.448104 x x qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq> x a 15:31:15.234429 x PRACK x x x a +0.045697 x qqqqqqqqqqqqqqqqqqqqqqqq>>> x x x a 15:31:15.280126 x x PRACK x a +0.954153 x x qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq>>> x a 15:31:16.234279 x PRACK x x x a +0.045832 x qqqqqqqqqqqqqqqqqqqqqqqq>>> x x x a 15:31:16.280111 x x PRACK x a +1.954170 x x qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq>>> x a 15:31:18.234281 x PRACK x x x a +0.045839 x qqqqqqqqqqqqqqqqqqqqqqqq>>> x x x a 15:31:18.280120 x x PRACK x a +1.829676 x x qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq>>> x a 15:31:20.109796 x x x 183 Session Progress (SDP) x a +0.001460 x x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x a 15:31:20.111256 x 183 Session Progress (SDP) x x x a +2.123075 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x x a 15:31:22.234331 x PRACK x x x a +0.045825 x qqqqqqqqqqqqqqqqqqqqqqqq>>> x x x a 15:31:22.280156 x x PRACK x a +2.239640 x x qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq>>> x a 15:31:24.519796 x x x 486 Busy Here x a +0.000555 x x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x a 15:31:24.520351 x x x ACK x a +0.008965 x x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x a 15:31:24.529316 x 486 Busy Here x x x a +0.000835 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x x a 15:31:24.530151 x ACK x x x a +1.704184 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x x a 15:31:26.234335 x PRACK x x x a +0.045856 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x x a 15:31:26.280191 x x PRACK x a +3.954734 x x qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq>>> x a 15:31:30.234925 x PRACK x x x x +0.045279 x qqqqqqqqqqqqqqqqqqqqqqqq>>> x x x x 15:31:30.280204 x x PRACK x x +3.954116 x x qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq>>> x x 15:31:34.234320 x PRACK x x x 2021/09/21 15:31:11.787490 50.50.50.210:5060 -> 50.50.50.182:5060 INVITE sip:123456789@sip.mydomain.com:5060 SIP/2.0 Record-Route: <sip:50.50.50.210;r2=on;lr;ftag=73622588a6084d8ba1bca54781e5094d;vsf=AAAAAFpUAgECBwAABnEBB3ZdWEIAQkVFS0BHX2ljZS5ldQ--;vst=AAAAAAAAAAAKCQ8ABAkHCAYKAgdxQFpGbkJCRktDREFYU1AAV0Qw;did=e8e.bb7;nat=yes> Record-Route: <sip:50.50.50.210:5061 ;transport=tls;r2=on;lr;ftag=73622588a6084d8ba1bca54781e5094d;vsf=AAAAAFpUAgECBwAABnEBB3ZdWEIAQkVFS0BHX2ljZS5ldQ--;vst=AAAAAAAAAAAKCQ8ABAkHCAYKAgdxQFpGbkJCRktDREFYU1AAV0Qw;did=e8e.bb7;nat=yes> Via: SIP/2.0/UDP 50.50.50.210;branch=z9hG4bK37fe.f05cee0feff15d488a12d3758cece7ae.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj472f07568b924214ada83ddfb0fb12b6;alias Max-Forwards: 69 From: 987654321 <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com> Contact: "MyUserNAme" <sip:mycustomerid@10.2.1.160:58568 ;transport=TLS;ob;alias=100.100.100.61~48572~3> Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14320 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.20.5 Content-Type: application/sdp Content-Length: 326 P-Asserted-Identity: <sip:987654321@sip.mydomain.com> v=0 o=- 3841227071 3841227071 IN IP4 50.50.50.215 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 36448 RTP/AVP 8 0 101 c=IN IP4 50.50.50.215 b=TIAS:64000 a=ssrc:2024148033 cname:4f2468fd611910fa a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv a=rtcp:36449 2021/09/21 15:31:11.790589 50.50.50.182:5060 -> 50.50.50.210:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 50.50.50.210;branch=z9hG4bK37fe.f05cee0feff15d488a12d3758cece7ae.0;i=baa3;rport=5060 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj472f07568b924214ada83ddfb0fb12b6;alias From: 987654321 <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com> Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14320 INVITE Server: myserver Content-Length: 0 2021/09/21 15:31:11.792809 50.50.50.182:32818 -> 200.200.200.209:5060 INVITE sip:123456789@sip.mydomain.com:5060 SIP/2.0 Record-Route: <sip:50.50.50.182:5080 ;transport=tcp;r2=on;lr=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Record-Route: <sip:50.50.50.182;r2=on;lr=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Record-Route: <sip:50.50.50.210;r2=on;lr;ftag=73622588a6084d8ba1bca54781e5094d;vsf=AAAAAFpUAgECBwAABnEBB3ZdWEIAQkVFS0BHX2ljZS5ldQ--;vst=AAAAAAAAAAAKCQ8ABAkHCAYKAgdxQFpGbkJCRktDREFYU1AAV0Qw;did=e8e.bb7;nat=yes> Record-Route: <sip:50.50.50.210:5061 ;transport=tls;r2=on;lr;ftag=73622588a6084d8ba1bca54781e5094d;vsf=AAAAAFpUAgECBwAABnEBB3ZdWEIAQkVFS0BHX2ljZS5ldQ--;vst=AAAAAAAAAAAKCQ8ABAkHCAYKAgdxQFpGbkJCRktDREFYU1AAV0Qw;did=e8e.bb7;nat=yes> Via: SIP/2.0/TCP 50.50.50.182:5080 ;branch=z9hG4bK37fe.254ecab744d678154779037580c59731.0 Via: SIP/2.0/UDP 50.50.50.210;rport=5060;branch=z9hG4bK37fe.f05cee0feff15d488a12d3758cece7ae.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj472f07568b924214ada83ddfb0fb12b6;alias Max-Forwards: 68 From: 987654321 <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com> Contact: "MyUserNAme" <sip:mycustomerid@10.2.1.160:58568 ;transport=TLS;ob;alias=100.100.100.61~48572~3> Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14320 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 Content-Type: application/sdp Content-Length: 326 P-Asserted-Identity: <sip:987654321@sip.mydomain.com> v=0 o=- 3841227071 3841227071 IN IP4 50.50.50.183 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 29308 RTP/AVP 8 0 101 c=IN IP4 50.50.50.183 b=TIAS:64000 a=ssrc:2024148033 cname:4f2468fd611910fa a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv a=rtcp:29309 2021/09/21 15:31:11.813534 200.200.200.209:5060 -> 50.50.50.182:32818 SIP/2.0 100 Trying Via: SIP/2.0/TCP 50.50.50.182:5080 ;branch=z9hG4bK37fe.254ecab744d678154779037580c59731.0 Via: SIP/2.0/UDP 50.50.50.210;rport=5060;branch=z9hG4bK37fe.f05cee0feff15d488a12d3758cece7ae.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj472f07568b924214ada83ddfb0fb12b6;alias From: 987654321 <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14320 INVITE Content-Length: 0 2021/09/21 15:31:14.442418 200.200.200.209:5060 -> 50.50.50.182:32818 SIP/2.0 183 Session Progress Via: SIP/2.0/TCP 50.50.50.182:5080 ;branch=z9hG4bK37fe.254ecab744d678154779037580c59731.0 Via: SIP/2.0/UDP 50.50.50.210;rport=5060;branch=z9hG4bK37fe.f05cee0feff15d488a12d3758cece7ae.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj472f07568b924214ada83ddfb0fb12b6;alias From: 987654321 <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14320 INVITE Record-Route: <sip:50.50.50.182:5080 ;transport=tcp;r2=on;lr=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Record-Route: <sip:50.50.50.182:5060 ;r2=on;lr=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Record-Route: <sip:50.50.50.210:5060 ;r2=on;lr;ftag=73622588a6084d8ba1bca54781e5094d;vsf=AAAAAFpUAgECBwAABnEBB3ZdWEIAQkVFS0BHX2ljZS5ldQ--;vst=AAAAAAAAAAAKCQ8ABAkHCAYKAgdxQFpGbkJCRktDREFYU1AAV0Qw;did=e8e.bb7;nat=yes> Record-Route: <sip:50.50.50.210:5061 ;transport=tls;r2=on;lr;ftag=73622588a6084d8ba1bca54781e5094d;vsf=AAAAAFpUAgECBwAABnEBB3ZdWEIAQkVFS0BHX2ljZS5ldQ--;vst=AAAAAAAAAAAKCQ8ABAkHCAYKAgdxQFpGbkJCRktDREFYU1AAV0Qw;did=e8e.bb7;nat=yes> Contact: <sip:123456789@200.200.200.209:5060> Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Require: 100rel RSeq: 1509 Content-Length: 241 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 12038 7929 IN IP4 200.200.200.209 s=SIP Media Capabilities c=IN IP4 200.200.200.212 t=0 0 m=audio 17366 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 2021/09/21 15:31:14.443990 50.50.50.182:5060 -> 50.50.50.210:5060 SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 50.50.50.210;rport=5060;branch=z9hG4bK37fe.f05cee0feff15d488a12d3758cece7ae.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj472f07568b924214ada83ddfb0fb12b6;alias From: 987654321 <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14320 INVITE Record-Route: <sip:50.50.50.182:5080 ;transport=tcp;r2=on;lr=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Record-Route: <sip:50.50.50.182:5060 ;r2=on;lr=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Record-Route: <sip:50.50.50.210:5060 ;r2=on;lr;ftag=73622588a6084d8ba1bca54781e5094d;vsf=AAAAAFpUAgECBwAABnEBB3ZdWEIAQkVFS0BHX2ljZS5ldQ--;vst=AAAAAAAAAAAKCQ8ABAkHCAYKAgdxQFpGbkJCRktDREFYU1AAV0Qw;did=e8e.bb7;nat=yes> Record-Route: <sip:50.50.50.210:5061 ;transport=tls;r2=on;lr;ftag=73622588a6084d8ba1bca54781e5094d;vsf=AAAAAFpUAgECBwAABnEBB3ZdWEIAQkVFS0BHX2ljZS5ldQ--;vst=AAAAAAAAAAAKCQ8ABAkHCAYKAgdxQFpGbkJCRktDREFYU1AAV0Qw;did=e8e.bb7;nat=yes> Contact: <sip:123456789@200.200.200.209:5060> Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Require: 100rel RSeq: 1509 Content-Length: 253 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 12038 7929 IN IP4 50.50.50.183 s=SIP Media Capabilities c=IN IP4 50.50.50.183 t=0 0 m=audio 29320 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:29321 2021/09/21 15:31:14.743211 50.50.50.210:5060 -> 50.50.50.182:5060 PRACK sip:123456789@200.200.200.209:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.210;branch=z9hG4bK47fe.067d9577e9ab3e30e01745a2cf73b7a4.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj9ab94c339144428bb7ada63b133f2c12;alias Max-Forwards: 69 From: "MyUserNAme" <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14321 PRACK Route: <sip:50.50.50.182:5060 ;lr;r2=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Route: <sip:50.50.50.182:5080 ;transport=tcp;lr;r2=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> RAck: 1509 14320 INVITE Content-Length: 0 2021/09/21 15:31:14.786325 50.50.50.182:5060 -> 200.200.200.209:5060 PRACK sip:123456789transport=tcp@200.200.200.209:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.182;branch=z9hG4bK47fe.3406fe45bb75c3e955b6aa67e53aff58.0 Via: SIP/2.0/UDP 50.50.50.210;rport=5060;branch=z9hG4bK47fe.067d9577e9ab3e30e01745a2cf73b7a4.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj9ab94c339144428bb7ada63b133f2c12;alias Max-Forwards: 68 From: "MyUserNAme" <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14321 PRACK RAck: 1509 14320 INVITE Content-Length: 0 2021/09/21 15:31:15.234429 50.50.50.210:5060 -> 50.50.50.182:5060 PRACK sip:123456789@200.200.200.209:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.210;branch=z9hG4bK47fe.067d9577e9ab3e30e01745a2cf73b7a4.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj9ab94c339144428bb7ada63b133f2c12;alias Max-Forwards: 69 From: "MyUserNAme" <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14321 PRACK Route: <sip:50.50.50.182:5060 ;lr;r2=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Route: <sip:50.50.50.182:5080 ;transport=tcp;lr;r2=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> RAck: 1509 14320 INVITE Content-Length: 0 2021/09/21 15:31:15.280126 50.50.50.182:5060 -> 200.200.200.209:5060 PRACK sip:123456789transport=tcp@200.200.200.209:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.182;branch=z9hG4bK47fe.3406fe45bb75c3e955b6aa67e53aff58.0 Via: SIP/2.0/UDP 50.50.50.210;rport=5060;branch=z9hG4bK47fe.067d9577e9ab3e30e01745a2cf73b7a4.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj9ab94c339144428bb7ada63b133f2c12;alias Max-Forwards: 68 From: "MyUserNAme" <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14321 PRACK RAck: 1509 14320 INVITE Content-Length: 0 2021/09/21 15:31:16.234279 50.50.50.210:5060 -> 50.50.50.182:5060 PRACK sip:123456789@200.200.200.209:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.210;branch=z9hG4bK47fe.067d9577e9ab3e30e01745a2cf73b7a4.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj9ab94c339144428bb7ada63b133f2c12;alias Max-Forwards: 69 From: "MyUserNAme" <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14321 PRACK Route: <sip:50.50.50.182:5060 ;lr;r2=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Route: <sip:50.50.50.182:5080 ;transport=tcp;lr;r2=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> RAck: 1509 14320 INVITE Content-Length: 0 2021/09/21 15:31:16.280111 50.50.50.182:5060 -> 200.200.200.209:5060 PRACK sip:123456789transport=tcp@200.200.200.209:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.182;branch=z9hG4bK47fe.3406fe45bb75c3e955b6aa67e53aff58.0 Via: SIP/2.0/UDP 50.50.50.210;rport=5060;branch=z9hG4bK47fe.067d9577e9ab3e30e01745a2cf73b7a4.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj9ab94c339144428bb7ada63b133f2c12;alias Max-Forwards: 68 From: "MyUserNAme" <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14321 PRACK RAck: 1509 14320 INVITE Content-Length: 0 2021/09/21 15:31:18.234281 50.50.50.210:5060 -> 50.50.50.182:5060 PRACK sip:123456789@200.200.200.209:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.210;branch=z9hG4bK47fe.067d9577e9ab3e30e01745a2cf73b7a4.0;i=baa3 Via: SIP/2.0/TLS 10.2.1.160:58568 ;received=100.100.100.61;rport=48572;branch=z9hG4bKPj9ab94c339144428bb7ada63b133f2c12;alias Max-Forwards: 69 From: "MyUserNAme" <sip:987654321@sip.mydomain.com >;tag=73622588a6084d8ba1bca54781e5094d To: <sip:123456789@sip.mydomain.com>;tag=gK0d8c9073 Call-ID: 846ffb2f076848c5b8edc876fa1c0d9b CSeq: 14321 PRACK Route: <sip:50.50.50.182:5060 ;lr;r2=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> Route: <sip:50.50.50.182:5080 ;transport=tcp;lr;r2=on;ftag=73622588a6084d8ba1bca54781e5094d;did=e8e.c4d1> RAck: 1509 14320 INVITE Content-Length: 0 Any help will be much appreciated. Kind regards, Angelo

2 7

Releasing Kamailio 5.3.9
by Henning Westerholt 23 Sep '21

23 Sep '21

Hello, I am planning to release in two weeks (likely on Wednesday 7th October) the next minor version out of branch 5.3, version 5.3.9. Backports of fixed issues from other stable branches will be integrated as usual. If you are aware of new issues which were not yet reported on the issue tracker or are missing back-ports, report them. Please note that this will be the last minor release created from the 5.3.x stable branch. The stable branches are usually maintained from the Kamailio development team for a period of two years. The other two stable branches of Kamailio will still be maintained (5.4.x and 5.5.x). Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

1 0

Kamailio v5.4.7 Released
by Daniel-Constantin Mierla 22 Sep '21

22 Sep '21

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

1 0

Add a new trunk
by sondes boughdiri 22 Sep '21

22 Sep '21

Good morning , I have a question , how to add a trunk from operators in kamailio. Best regards .

1 0

Re: [SR-Users] How to get $fU and $tU from MSRP module?
by Henning Westerholt 22 Sep '21

22 Sep '21

(please keep the list in CC) Hello, I see – its kind of pseudo-SIP message that is presented in the cfg in this route. And it seems that you want to access the cpim body. You already checked that the $msrp(crhop), $msrp(nexthop) and $msrp(prevop) etc.. are not working for you? It’s probably not the best way, but what about using $msrp(body) to get the body and then using a regular expression (like a transformation) on this to get the From/To? Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: BOEINGNG <lihang567890(a)126.com> Sent: Wednesday, September 22, 2021 2:41 AM To: Henning Westerholt <hw(a)skalatan.de> Subject: Re: [SR-Users] How to get $fU and $tU from MSRP module? Yes, I logged, but only got <null> for both $fU and $tU. 2021年9月20日下午4:03，Henning Westerholt <hw(a)skalatan.de<mailto:hw@skalatan.de>> 写道： Hello, I am not that familiar with the MSRP module, but have you tried to just log/access the $fU and $tU in the event_route[msrp:frame-in]? Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of BOEINGNG Sent: Friday, September 17, 2021 10:57 AM To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] How to get $fU and $tU from MSRP module? Hello! I want to get $fU and $tU from event_route[msrp:frame-in] in order to filter out MSRP messages sent by a specific sender and received by a specific receiver, I know I can get message content from $msrp(buf), the message content is like this: MSRP 7a57f552155926c0 SEND To-Path: msrp://172.18.0.14:6060/9d8da4a34dc2102959e7;tcp msrp://172.18.0.12:5060/msrp-6142fc2b-84-1;tcp msrp://172.18.0.2:34862/2a67b54ae0750b7d82aa;tcp From-Path: msrp://172.18.0.14:6060/c71ae3675e114d08216b;tcp msrp://172.18.0.12:5060/msrp-6142fc2b-83-1;tcp msrp://172.18.0.2:34858/8baea7c52ba8755322fd;tcp Byte-Range: 1-197/197 Failure-Report: yes Success-Report: yes Message-ID: c792c94039b8a969 Content-Type: message/cpim From: sip:alice@ims.mnc001.mcc001.3gppnetwork.org To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org DateTime: 2021-09-16T09:23:49.339805+00:00 MIME-Version: 1.0 Content-Type: text/plain hello -------7a57f552155926c0$ I want to get alice and bob from the content below： From: sip:alice@ims.mnc001.mcc001.3gppnetwork.org To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org DateTime: 2021-09-16T09:23:49.339805+00:00 someone can suggest some method. In other route like request_route we can use $fU and $tU to access them. Regrads HANG LI

1 0

Unable to pull enviornment variables
by Adarsh Chauhan 22 Sep '21

22 Sep '21

Hi Team, Need some help here. Want to pull environment variable however kamailio just doesnt pick it. I exported the environment variable *export STAGE="dev"* Then i tried following 1) *#!defenv DEVSTAGE* gives error 0(3809) ERROR: <core> [core/cfg.lex:2085]: pp_define_env(): env variable not defined [DEVSTAGE] 2) *#!substdef "/DEVSTAGE/$env(DEVSTAGE)/";* 0(3962) DEBUG: <core> [core/ppcfg.c:87]: pp_subst_add(): ### added subst expression: [/DEVSTAGE/$env(DEVSTAGE)/] 0(3962) DEBUG: <core> [core/cfg.lex:1964]: pp_define(): defining id: DEVSTAGE 0(3962) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 0(3962) DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: 0(3962) DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): method: <OPTIONS> 0(3962) DEBUG: <core> [core/parser/msg_parser.c:681]: parse_msg(): uri: <sip:you@kamailio.org> 0(3962) DEBUG: <core> [core/parser/msg_parser.c:683]: parse_msg(): version: <SIP/2.0> 0(3962) DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Via] type 1 0(3962) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=2 0(3962) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 0(3962) DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via 0(3962) DEBUG: <core> [core/pvapi.c:497]: pv_spec_lookup(): PV <$env(DEVSTAGE)> is not in cache 0(3962) DEBUG: <core> [core/pvapi.c:335]: pv_cache_add(): PV cache not initialized, doing it now 0(3962) DEBUG: <core> [core/pvapi.c:371]: pv_cache_add(): pvar [$env(DEVSTAGE)] added in cache 0(3962) DEBUG: <core> [core/cfg.lex:2053]: pp_define_set(): ### setting define ID [DEVSTAGE] value [<null>] (mode: 1) 0(3962) DEBUG: <core> [core/ppcfg.c:188]: pp_substdef_add(): ### added substdef: [DEVSTAGE]=[<null>] (0) 0(3962) DEBUG: <core> [core/re.c:436]: subst_run(): running. r=1 0(3962) DEBUG: <core> [core/re.c:504]: subst_str(): no match 0(3962) DEBUG: <core> [core/re.c:436]: subst_run(): running. r=1 0(3962) DEBUG: <core> [core/re.c:504]: subst_str(): no match my end goal is to compare the directive and load modules accordingly. *#!ifdef DEVSTAGE == "dev"*

3 4

Releasing Kamailio v.5.4.7
by Daniel-Constantin Mierla 22 Sep '21

22 Sep '21

Hello, I am planning to release a new version from branch 5.4, respectively 5.4.7, sometime next week, likely on Wednesday, Sep 22, 2021. If anyone is aware of issues not yet reported to bug tracker or missing backports, report them in order to try to get the fixes in this release. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 1

JSONRPC ERROR in siremis GUI.
by 岩間理佐 22 Sep '21

22 Sep '21

Hi, I have a question regarding the jsonRPC commands in the siremis GUI. 【Environment】・Centos7 ・Kamailio 5.5.2 ・siremis 5.3 (installed by git clone https://github.com/asipto/siremis siremis-5.3.x) ・php php-mysqlnd-7.1.33-16.el7.remi.x86_64 php-json-7.1.33-16.el7.remi.x86_64 php-mbstring-7.1.33-16.el7.remi.x86_64 php-pdo-7.1.33-16.el7.remi.x86_64 php-gd-7.1.33-16.el7.remi.x86_64 php-xml-7.1.33-16.el7.remi.x86_64 php-pecl-zip-1.19.4-1.el7.remi.7.1.x86_64 php-xmlrpc-7.1.33-16.el7.remi.x86_64 php-cli-7.1.33-16.el7.remi.x86_64 php-process-7.1.33-16.el7.remi.x86_64 php-pear-1.10.13-1.el7.remi.noarch php-common-7.1.33-16.el7.remi.x86_64 php-7.1.33-16.el7.remi.x86_64 When I execute commands in command service →JSONRPC commands from siremis GUI, it always shows error page. I tried some approaches <https://eow.alc.co.jp/search?q=approaches&ref=awlj> referring to this page, https://github.com/asipto/siremis/issues/26 but I still have this error message in /var/log/httpd/error_log > [Tue Sep 21 16:43:26.396967 2021] [php7:warn] [pid 6181] [client > 152.165.116.138:55822] PHP Warning: strstr() expects parameter 1 to be > string, resource given in > /var/www/siremis-5.3.x/openbiz/bin/ErrorHandler.php on line 158, referer: > http://kamailio.xcallyjp.com/siremis/sipadmin/jrcmds > [Tue Sep 21 16:43:26.401139 2021] [php7:notice] [pid 6181] [client > 152.165.116.138:55822] u socket send failed: Permission denied, referer: > http://kamailio.xcallyjp.com/siremis/sipadmin/jrcmds I have tried my best to do some researches about it, but still stuck. Any help is appreciated. Thank you! Lisa Iwama

2 1

Question regarding parser error for REGISTER request
by Floimair Florian 20 Sep '21

20 Sep '21

Hello List! We have a certain user agent that somehow triggers a parser error log entry, everytime this type of user agent registers. Sep 20 12:03:49 kamailio-dev-1 /usr/sbin/kamailio[1803]: ERROR: <core> [core/parser/parse_param.c:517]: parse_param2(): Invalid character, ; expected The odd thing now is that this register still succeeds. And we do not see that error for other methods like e.g. INVITE. The user agent in question is an Android app based on linphone which we develop inhouse. We also use the same for iOS where the error does not occur. The REGISTER request contains a push-token in the Contact header and I think this is where the parser somehow generates this error. Since this is the only line apart from the User-Agent header where the content of the two is different. We did have a look and diffed the differences between our iOS and Android app variants and didn’t see any obvious problem or invalid character (compared even with hex editor). So my questions regarding this I hope that someone of you can help me with: * Is there any way to make the parser error more verbose (e.g. which character in which header it is complaining about)? Right now it only says that there was an error and that it expected ‘;’ but not where and what character was found instead. * Why does the parser throw the error but the registration still succeeds? It does not quite make sense to me. Best Regards FLORIAN FLOIMAIR Development Commend International GmbH Saalachstrasse 51 5020 Salzburg, Austria Phone: +43 662 85 62 25 Mail: f.floimair(a)commend.com<mailto:f.floimair@commend.com> [signature_1687123261] commend.com LG Salzburg / FN 178618z

2 1

Question on the SL Module
by Alessio Garzi 20 Sep '21

20 Sep '21

Hello Kama ML, today I stumbled on function "update_sl_stats()" inside sl_stats.c and noticed that some response codes are treated differently. For example here: https://github.com/kamailio/kamailio/blob/a9ef78b7f43616f2ceaa26df97eff68eb… since we have a "break;" statement, when a 500 code is received, the 5XX counter is not incremented even if a 500 code belongs to the 5XX family. We have the same behaviour for other response codes and it really seems that it's not a bug and the author really wanted it. The docs are not so helpful and they don't explain much in detail how counters are built. I just want to have confirmation this is how it must work and I wonder if it's the case to write something about it into the docs. Thanks Alessio

2 1

Kamilio Presence
by Jerry Kendall 20 Sep '21

20 Sep '21

Hey Bill, Just checking to see if you managed to get the BLFs to work on the Yealinks... I've Grandstream/Yealink/Polycom devices and can't get BLFs to work - the NOTIFY is not being sent. regards, Jerry __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users(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: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

2 2

Kamailio - FreeSWITCH - RTPproxy
by Jerry Kendall 20 Sep '21

20 Sep '21

Hello all, I am new to the list but have been reading plenty. Loads of good tips and help. I am playing with Freeswitch and would like to put Kamailio/RTPProxy in front for the user endpoints. Freeswitch will talk directly with the service provider. I am wondering *if* i can do this... 1) have the endpoints register with kamailio 2) have the media proxy via RTPProxy as it is needed for NAT 3) have the actual work (voicemail/ring groups/ivr/conference/etc...) done on Freeswitch 4) have all the SUBSCRIBE/PUBLISH/PRESENCE done on Kamailio Is this doable? Are there any guides to setting this sort of thing up? regards, Jerry

3 3

How to get $fU and $tU from MSRP module?
by BOEINGNG 20 Sep '21

20 Sep '21

Hello! I want to get $fU and $tU from event_route[msrp:frame-in] in order to filter out MSRP messages sent by a specific sender and received by a specific receiver, I know I can get message content from $msrp(buf), the message content is like this: MSRP 7a57f552155926c0 SEND To-Path: msrp://172.18.0.14:6060/9d8da4a34dc2102959e7;tcp msrp://172.18.0.12:5060/msrp-6142fc2b-84-1;tcp msrp://172.18.0.2:34862/2a67b54ae0750b7d82aa;tcp From-Path: msrp://172.18.0.14:6060/c71ae3675e114d08216b;tcp msrp://172.18.0.12:5060/msrp-6142fc2b-83-1;tcp msrp://172.18.0.2:34858/8baea7c52ba8755322fd;tcp Byte-Range: 1-197/197 Failure-Report: yes Success-Report: yes Message-ID: c792c94039b8a969 Content-Type: message/cpim From: sip:alice@ims.mnc001.mcc001.3gppnetwork.org To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org DateTime: 2021-09-16T09:23:49.339805+00:00 MIME-Version: 1.0 Content-Type: text/plain hello -------7a57f552155926c0$ I want to get alice and bob from the content below： From: sip:alice@ims.mnc001.mcc001.3gppnetwork.org To: sip:bob@ims.mnc001.mcc001.3gppnetwork.org DateTime: 2021-09-16T09:23:49.339805+00:00 someone can suggest some method. In other route like request_route we can use $fU and $tU to access them. Regrads HANG LI

2 1

Reinite breaks the call
by Angelo Sipper 20 Sep '21

20 Sep '21

Hello, I am trying to understand a problem we have with reinvites. When there is a reinvite on the call our provider refuses to receive the reinvite and the call is dropped. The setup is the bellow: UA-> Kamailio1 -> Kamailio2 -> Provider On Kamailio2 we have Topos enabled. Looking on the trace I can see that on the second invite, Kamailio does send out the original contact and not the one that was originally send out to the provider. Is this correct? Is this breaking the call? Bellow the trace and the flow from Kamailio2 until the second reinvite. All reinvites are the same as per the last Thank you for your help! 2021/09/15 16:29:59.420162 50.50.50.181:5060 -> 200.200.200.193:5060 INVITE sip:1234567890@sip.mydomain.com:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.181;branch=z9hG4bK3db6.b5141bfea33b57c5223aff14ab3b5466.0 Max-Forwards: 67 From: 987654321 <sip:987654321@sip.mydomain.com>;tag=2QK2mpeH5Sy4g To: <sip:1234567890@sip.mydomain.com> Call-ID: dfb297d1-90cb-123a-d4a1-00155d01bf11 CSeq: 41302510 INVITE Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 481 Contact: <sip:btpsh-b5-6141f513-11f69-4@50.50.50.181> v=0 o=FreeSWITCH 1631683257 1631683258 IN IP4 50.50.50.183 s=FreeSWITCH c=IN IP4 50.50.50.183 t=0 0 m=audio 26472 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:101 0-16 a=sendrecv a=rtcp:26473 a=ptime:20 m=video 26510 RTP/AVP 103 b=AS:1024 a=rtpmap:103 H264/90000 a=rtcp-fb:103 ccm fir a=rtcp-fb:103 ccm tmmbr a=rtcp-fb:103 nack a=rtcp-fb:103 nack pli a=sendrecv a=rtcp:26511 ====================================================================================== 2021/09/15 16:29:59.439009 200.200.200.193:5060 -> 50.50.50.181:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 50.50.50.181;branch=z9hG4bK3db6.b5141bfea33b57c5223aff14ab3b5466.0 From: 987654321 <sip:987654321@sip.mydomain.com>;tag=2QK2mpeH5Sy4g To: <sip:1234567890@sip.mydomain.com>;tag=gK0dc15c15 Call-ID: dfb297d1-90cb-123a-d4a1-00155d01bf11 CSeq: 41302510 INVITE Content-Length: 0 ====================================================================================== 2021/09/15 16:30:02.596613 200.200.200.193:5060 -> 50.50.50.181:5060 SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 50.50.50.181;branch=z9hG4bK3db6.b5141bfea33b57c5223aff14ab3b5466.0 From: 987654321 <sip:987654321@sip.mydomain.com>;tag=2QK2mpeH5Sy4g To: <sip:1234567890@sip.mydomain.com>;tag=gK0dc15c15 Call-ID: dfb297d1-90cb-123a-d4a1-00155d01bf11 CSeq: 41302510 INVITE Contact: <sip:1234567890@200.200.200.193:5060> Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Content-Length: 313 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 27823 25478 IN IP4 200.200.200.193 s=SIP Media Capabilities c=IN IP4 200.200.200.196 t=0 0 m=audio 19958 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 m=video 0 RTP/AVP 103 b=AS:1024 a=rtpmap:103 H264/90000 a=inactive ====================================================================================== 2021/09/15 16:30:06.163783 200.200.200.193:5060 -> 50.50.50.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 50.50.50.181;branch=z9hG4bK3db6.b5141bfea33b57c5223aff14ab3b5466.0 From: 987654321 <sip:987654321@sip.mydomain.com>;tag=2QK2mpeH5Sy4g To: <sip:1234567890@sip.mydomain.com>;tag=gK0dc15c15 Call-ID: dfb297d1-90cb-123a-d4a1-00155d01bf11 CSeq: 41302510 INVITE Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: <sip:1234567890@200.200.200.193:5060> Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS P-Asserted-Identity: <sip:6979111336@MOBILE.MOBILEPROVIDER.COM;user=phone> Require: timer Supported: timer Session-Expires: 300;refresher=uac Content-Length: 313 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 27823 25478 IN IP4 200.200.200.193 s=SIP Media Capabilities c=IN IP4 200.200.200.196 t=0 0 m=audio 19958 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 m=video 0 RTP/AVP 103 b=AS:1024 a=rtpmap:103 H264/90000 a=inactive ====================================================================================== 2021/09/15 16:30:06.405147 50.50.50.181:5060 -> 200.200.200.193:5060 ACK sip:1234567890@200.200.200.193:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.181;branch=z9hG4bK3db6.58e9d8820221b191b49fe0c91299e56f.0 Max-Forwards: 68 From: "987654321" <sip:987654321@sip.mydomain.com>;tag=2QK2mpeH5Sy4g To: <sip:1234567890@sip.mydomain.com>;tag=gK0dc15c15 Call-ID: dfb297d1-90cb-123a-d4a1-00155d01bf11 CSeq: 41302510 ACK Proxy-Authorization: Digest username="mycustomerid", realm=" sbc1.mydomain.com", nonce="YUH2g2FB9VcCxZ3l2WSvJCj7aUokLhAKksYQ1zfOfyQRWm90h2vJgH8I/B+A", algorithm=MD5, uri="sip:1234567890@sbc1.mydomain.com", response="dc4d3d7e9281c04ecc3e3 63ea162fb" Content-Length: 0 Contact: <sip:btpsh-b5-6141f513-11f69-4@50.50.50.181> ============================================= 2021/09/15 16:32:37.685497 50.50.50.181:5060 -> 200.200.200.193:5060 INVITE sip:1234567890@200.200.200.193:5060 SIP/2.0 Via: SIP/2.0/UDP 50.50.50.181;branch=z9hG4bK4db6.691137b194a14953af928c339e03d60e.0 Via: SIP/2.0/UDP 50.50.50.210;rport=5060;branch=z9hG4bK4db6.4619cd1b550ba7e45a3fbd0321a5c0b0.0 Via: SIP/2.0/UDP 62.1.2.62;received=62.1.2.62;rport=5060;branch=z9hG4bKXDZQF19XUj3QB Max-Forwards: 67 From: "987654321" <sip:987654321@sip.mydomain.com>;tag=2QK2mpeH5Sy4g To: <sip:1234567890@sip.mydomain.com>;tag=gK0dc15c15 Call-ID: dfb297d1-90cb-123a-d4a1-00155d01bf11 CSeq: 41302511 INVITE Contact: <sip:mycustomerid@62.1.2.62:5060 ;transport=udp;gw=1606bb6a-6563-43be-b4dd-4890d524d0e9> User-Agent: Supervoice VPBX Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Proxy-Authorization: Digest username="mycustomerid", realm=" sbc1.mydomain.com", nonce="YUH2g2FB9VcCxZ3l2WSvJCj7aUokLhAKksYQ1zfOfyQRWm90h2vJgH8I/B+A", algorithm=MD5, uri="sip:atpsh-b5-6141f513-11f69-4@50.50.50.181", response="50ed75ca9002 ca76fbfa306fb8a599" Session-Expires: 300;refresher=uac Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 348 Remote-Party-ID: "987654321" <sip:987654321@sbc1.mydomain.com >;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1631683257 1631683258 IN IP4 50.50.50.183 s=FreeSWITCH c=IN IP4 50.50.50.183 t=0 0 m=audio 26472 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:101 0-16 a=sendrecv a=rtcp:26473 a=ptime:20 m=video 0 RTP/AVP 103 a=rtpmap:103 H264/90000 |Time | 50.50.50.210 | 200.200.200.193 | | | | 50.50.50.181 | |0.000024 | INVITE SDP (g711A g7 | |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> Call-ID:dfb297d1-90cb-123a-d4a1-00155d01bf11 CSeq:41302510 | |(5060) ------------------> (5060) | | |0.001523 | 100 trying -- your c | |SIP Status 100 trying -- your call is important to us | |(5060) <------------------ (5060) | | |0.011760 | | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302510 | | |(5060) ------------------> (5060) | |0.030607 | | 100 Trying| |SIP Status 100 Trying | | |(5060) <------------------ (5060) | |2.690501 | | 183 Session Progress |SIP Status 183 Session Progress | | |(5060) <------------------ (5060) | |2.708868 | 183 Session Progress | |SIP Status 183 Session Progress | |(5060) <------------------ (5060) | | |3.188211 | | 183 Session Progress |SIP Status 183 Session Progress | | |(5060) <------------------ (5060) | |3.199099 | 183 Session Progress | |SIP Status 183 Session Progress | |(5060) <------------------ (5060) | | |6.755381 | | 200 OK SDP (g711A te |SIP Status 200 OK | | |(5060) <------------------ (5060) | |6.819017 | 200 OK SDP (g711A te | |SIP Status 200 OK | |(5060) <------------------ (5060) | | |6.973845 | ACK | | |SIP Request INVITE ACK 200 CSeq:41302510 | |(5060) ------------------> (5060) | | |6.996745 | | ACK | |SIP ACK From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302510 | | |(5060) ------------------> (5060) | |158.269723| INVITE SDP (g711A g7 | |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> Call-ID:dfb297d1-90cb-123a-d4a1-00155d01bf11 CSeq:41302511 | |(5060) ------------------> (5060) | | |158.275396| 100 trying -- your c | |SIP Status 100 trying -- your call is important to us | |(5060) <------------------ (5060) | | |158.277105| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |158.753781| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |159.753493| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |161.753502| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |165.753630| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |169.754980| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |173.753719| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |177.753676| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |181.753657| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |185.753503| | INVITE SDP (g711A g7 |SIP INVITE From: 1234567890 <sip:1234567890@sip.mydomain.com> To:< sip:987654321@sip.mydomain.com> CSeq:41302511 | | |(5060) ------------------> (5060) | |188.254337| 503 Service not avai | |SIP Status 503 Service not available | |(5060) <------------------ (5060) | | |188.255085| ACK | | |SIP Request INVITE ACK 200 CSeq:41302511 | |(5060) ------------------> (5060) | | |188.326552| BYE | | |SIP Request BYE CSeq:41302512 | |(5060) ------------------> (5060) | | |188.342106| | BYE | |SIP Request BYE CSeq:41302512 | | |(5060) ------------------> (5060) | |188.373697| | 200 OK | |SIP Status 200 OK | | |(5060) <------------------ (5060) | |188.379670| 200 OK | | |SIP Status 200 OK | |(5060) <------------------ (5060) | | Kind Regards, Angelo

4 4

Re: [SR-Users] Error in ul_insert_ucontact() function of usrloc module
by hamed r 20 Sep '21

20 Sep '21

hello Ben I was using development functions and the C code of this function did not exist. I needed to manually add a contact to kamailio but this does not work and I used the HTable module to solve the problem. Thanks for the tips

1 0

Slack channel
by Sergio Carvalho 20 Sep '21

20 Sep '21

Hi everyone, How can I join the Kamailio slack channel? Is it open to the community? Best regards, Sergio Carvalho

3 2

Error in ul_insert_ucontact() function of usrloc module
by hamed r 18 Sep '21

18 Sep '21

The user is not added using the ul_insert_ucontact() function : ul_insert_ucontact("sip:900@192.168.51.138:1234", "< sip:900@192.168.51.138:1234>", "303", -1, "a2ecd821d4464d75851b73c35442b6ad", 2222, "0", "1", "MicroSIP/3.20.6", "udp: 192.168.51.106:5060"); And the following error is displayed in the syslog: Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3686]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 148: Too many arguments#012 Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3686]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 148: '('')' expected (function call) Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3686]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 148: bad command: missing ';'? Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3683]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 150-152: bad command Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3686]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 153: bad command Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3683]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 155-171: bad command Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3686]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 172: bad command Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3683]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 174-198: bad command Sep 18 14:36:48 srv139937 kamailio: CRITICAL: <core> [core/cfg.y:3686]: yyerror_at(): parse error in config file /usr/local/etc/kamailio//kamailio.cfg, line 838, column 199: bad command Sep 18 14:36:48 srv139937 kamailio: ERROR: <core> [core/cfg.y:3532]: yyparse(): function used inside params of another function: is_method what shoud i do?

2 1

Re: [SR-Users] problem with LRKProxy module
by hamed r 18 Sep '21

18 Sep '21

Thanks Mojtaba, problem was solved. I performed LRKProxy first, then Kamailio.

1 0

BLF when phone boots up
by Jerry Kendall 17 Sep '21

17 Sep '21

Hi, I have looked at lots of postings but can't seem to find the answer I seek. I have 6 phones (Grandstream GXP2170, etc) connected to Kamailio 5.2.1 running default config file with changes per https://kb.asipto.com/kamailio:presence:k43-blf On x301, I have the 3 BLFs setup to monitor x302, x303 and x304. If I dial 303 from 301, the BLFs work (flash, red, then green) as expected. But, when the phone initially boots up, the BLFs are all dead - until the first PUBLISH event. So, the question is, how do I get the BLFs to become valid and with the correct status when the phone boots up??? regards, Jerry

1 0

listen directive during runtime
by Tihomir Culjaga 17 Sep '21

17 Sep '21

Hi, is it possible to add a listen directive during kamailio runtime ? The reason I'm asking this is in a situation when I add a new peering trunk (from a different network segment), I need to add a network interface to the kamailio server and then add a specific listen directive for that interface to reference the socket by name. listen=udp:10.1.1.11 name "mySN1" so i can further reference to a specific socket name when routing SIP messages. Please advise, Regards, Tihomir.

2 1

Re: [SR-Users] DMQ module issues
by Zé Santos 17 Sep '21

17 Sep '21

I don't think you understood. The issue is in v5.2.5, and I tried to update kamailio but it still remains. I honestly think this is a machine problem, since I can't even send the notifications to 0.0.0.0:5090. It is very weird. Best Regards, José Santos

2 3

xmlrpc always returns NO RESULT
by 岩間理佐 17 Sep '21

17 Sep '21

Hi, I have a question regarding the XMLRPC commands in the siremis GUI. 【Environment】・Centos7 ・kamailio 5.5.2 ・siremis 5.3 （installed by git clone https://github.com/asipto/siremis siremis-5.3.x）・php: $ rpm -qa | grep php php-process-5.4.16-48.el7.x86_64 php-common-5.4.16-48.el7.x86_64 php-mysqlnd-5.4.16-48.el7.x86_64 php-pdo-5.4.16-48.el7.x86_64 php-xml-5.4.16-48.el7.x86_64 php-cli-5.4.16-48.el7.x86_64 php-5.4.16-48.el7.x86_64 php-pear-1.9.4-22.el7.noarch ・apache 2.4.6 When I execute commands in command service → XMLPRC from siremis GUI, it always shows no result. It looks like the command is not being executed. I also executed these commands on server, and there are no problem. There is no error in apache log and kamailio is also working. This is what I have in /etc/kamailio/kamailio.cfg #!KAMAILIO #!define WITH_XMLRPC #!define WITH_DEBUG #!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio" # - flags #FLT_ - per transaction (message) flags #FLB_ - per branch flags #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define WITH_MYSQL #!define WITH_NAT ####### Global Parameters ######### #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif #!ifdef WITH_NAT loadmodule "nathelper.so" #!ifdef WITH_RTPENGINE loadmodule "rtpengine.so" #!else loadmodule "rtpproxy.so" #!endif #!endif #!ifdef WITH_JSONRPC loadmodule "xhttp.so" #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 disable_tcp=yes auto_aliases=no port=5060 listen=udp:172.23.0.246:5060 advertise 52.69.75.254:5060 sip_warning=no ####### Modules Section ######## # set module path #mpath="/usr/local/lib/kamailio/modules/" #loadmodule "db_mysql.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "acc.so" loadmodule "dispatcher.so" loadmodule "uac.so" loadmodule "sqlops" loadmodule "rtimer" loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" # ----- jsonrpcs params ----- modparam("jsonrpcs", "pretty_format", 1) modparam("jsonrpcs", "dgram_socket", "/var/run/kamailio/kamailio_rpc.sock") modparam("jsonrpcs", "dgram_mode", 0666) modparam("jsonrpcs", "dgram_user", "kamailio") modparam("jsonrpcs", "dgram_group", "kamailio") modparam("jsonrpcs", "transport", 0) # ----- xmlrpc params ----- #modparam("xmlrpc", "route", "XMLRPC") #modparam("xmlrpc", "url_match", "^/RPC") # ----- rr params ----- modparam("rr", "append_fromtag", 1) # ----- R Timer ----- modparam("rtimer", "timer", "name=cdr;interval=300;mode=1;") modparam("rtimer", "exec", "timer=cdr;route=CDRS") # ----- acc params ----- modparam("acc", "log_flag", FLT_ACC) modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si") # ----- tm params ----- modparam("tm", "fr_timer", 2000) modparam("tm", "fr_inv_timer", 40000) modparam("tm", "auto_inv_100_reason", "Trying") # ----- dispatcher params ----- modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "flags", 2) modparam("dispatcher", "xavp_dst", "_dsdst_") modparam("dispatcher", "xavp_ctx", "_dsctx_") modparam("dispatcher", "ds_ping_from", "sip:proxy@52.69.75.254") modparam("dispatcher", "ds_ping_interval", 60) modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_timer_mode", 1) modparam("dispatcher", "xavp_dst_mode", 0) modparam("dispatcher", "ds_ping_latency_stats", 1) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_probing_threshold", 10) modparam("dispatcher", "ds_inactive_threshold", 10) modparam("dispatcher", "ds_ping_reply_codes","class=2;code=403;code=404;code=484;class=3") # ----- uac params ----- modparam("uac", "reg_db_url", DBURL) modparam("uac", "reg_contact_addr", "52.69.75.254") modparam("uac", "reg_db_table", "uacreg") # ----- mysql ----- modparam("sqlops", "sqlcon","cb=>mysql://kamailio:kamailiorw@localhost/kamailio") ####### Routing Logic ######## # main request routing logic request_route { # per request initial checks route(REQINIT); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle retransmissions if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { record_route(); } # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations route(DISPATCH); } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (!has_totag()) { return; } # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } route(RELAY); } if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); } if ( is_method("ACK") ) { if ( t_check_trans() ) { t_relay(); exit; } else { exit; } } sl_send_reply("404","Not here"); exit; } # Handle SIP registrations route[REGISTRAR] { if(!is_method("REGISTER")) return; sl_send_reply("404", "No registrar"); exit; } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; sl_send_reply("404", "Not here"); exit; } # Dispatch requests route[DISPATCH] { # round robin dispatching on gateways group '1' if(!ds_select_dst("1", "11")) { send_reply("404", "No destination"); exit; } xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } # Try next destionations in failure route failure_route[RTF_DISPATCH] { if (t_is_canceled()) { exit; } # next DST - only for 500 or local timeout if (t_check_status("500|486") or (t_branch_timeout() and !t_branch_replied())) { if(ds_next_dst()) { xdbg("--- SCRIPT: retrying to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } } } I have tried my best to do some researches about it, but still stuck. Any help is appreciated. Thank you!

2 1

problem with LRKProxy module
by hamed r 16 Sep '21

16 Sep '21

Hello I have problem with lrkproxy module. First, I installed the packages from the link below : https://github.com/mojtabaesfandiari/pylrkproxy And the service was properly listened to the local ip (192.168.51.106:22333 ). In the next step, the parameters were added to the kamalio.cfg file : loadmodule "lrkproxy.so" modparam("lrkproxy", "lrkproxy_sock", "udp:192.168.51.106:22333") I also changed the /etc/pylrkproxy/pylrkproxy.ini to set local ip. But when I make a call, the ip inside the sdp not change. And the following error is displayed in the syslog: Sep 4 07:18:05 debian /usr/local/sbin/kamailio[1724]: INFO: {1 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1507]: lrkproxy_force(): Here is SIP_REQUEST & METHOD_INVITE Sep 4 07:18:05 debian /usr/local/sbin/kamailio[1724]: ERROR: {1 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1084]: select_lrkp_node(): script error -no valid set selected Sep 4 07:18:05 debian /usr/local/sbin/kamailio[1724]: ERROR: {1 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1513]: lrkproxy_force(): can't ping any lrk proxy right now. Sep 4 07:18:07 debian /usr/local/sbin/kamailio[1723]: INFO: {2 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1625]: lrkproxy_force(): Here is SIP_REPLY of METHOD_INVITE Sep 4 07:18:07 debian /usr/local/sbin/kamailio[1723]: ERROR: {2 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1630]: lrkproxy_force(): No found entry in hash table

2 1

DMQ module issues
by Zé Santos 16 Sep '21

16 Sep '21

Hi guys, I am currently using kamailio v5.2.5 and running it inside a container. I already attempted to upgrade the kamailio to the latest version however the problem persists. This is the core dump that I got from using gdb: Core was generated by `/usr/sbin/kamailio -f > /etc/kazoo/kamailio/kamailio.cfg -m 512 -M 64 -x tlsf -w'. > Program terminated with signal 11, Segmentation fault. > #0 0x000000000071c63c in select_cfg_var (res=0x7ffd57d49b10, > s=0x7f2649395040, msg=0x7ffd57d4c340) at core/cfg/cfg_select.c:211 > 211 i = *(int *)p; It seems that the problem is with this line: modparam("dmq", "notification_address", "sip:DMQ_NOTIFY_ADDRESS") > Also, I only have this issue while running on an AWS instance, I have the same setup on my local computer, however kamailio is able to start correctly. While kamailio is starting, I have this line #!substdef "!DMQ_NOTIFY_ADDRESS!10.10.10.10:5090!g" It seems that after DMQ is able to obtain the IP address, when it comes to actually sending the message, it is interpreting the ip address of the DMQ_NOTIFY_ADDRESS as an integer and then it gives out a segmentation fault and the module stops. Another interesting thing is that if the DMQ_NOTIFY_ADDRESS is the MY_IP_ADDRESS variable instead of the 10.10.10.10, it seems to work properly. #!substdef "!DMQ_NOTIFY_ADDRESS!MY_IP_ADDRESS:5090!g" It also doesn't seem related to the ip being in a variable, since I already tried using a DNS record, and once again, it is able to obtain the IPs from the DNS record, and the same issue applies. Has anyone ever seen anything like this? I can't find any evidence of this actually happening. Thank you kindly for your time. Best Regards, José Santos

3 3

Best practice for Kamailio "cluster" front for many TLS connections
by Angelo Sipper 15 Sep '21

15 Sep '21

Hello, We are thinking to use kamailio to fully support our current voip service. I would like to know what is the best practice to use kamailio for several thousands for clients that connect to us via TLS. We would like to have a front "cluster" to be able to handle all these connections in balanced way. All clients register to us and the do calls that we statefully forward to the provider. On our test we have already created a single kamailio that successfully accepts and handles registration, do the control and routing to next provider with dispatcher and also do the accounting with cdrs. We want to separate this controlling, routing, accounting and dispatching from the front end and create a front "cluster" to offload the TLS and also be redundant to as many connections by adding more kamailio's. What would be the best kamailio module and topology as solution to this requirement? Thank you in advance. Kind Regards, Angelo

7 12

Fwd: Catching an overall timeout after dropping replies
by Marrold 15 Sep '21

15 Sep '21

Hi, This is partially related to a previous thread - https://lists.kamailio.org/pipermail/sr-users/2021-August/113128.html We are using the TSILO module to suspend transactions whilst we wait for mobile app users to register after receiving a push notification. In the time we are waiting for the app to register, other UAs might reject the call (DND, Busy, etc). To avoid this failure response being relayed to the caller, we use t_drop_replies in the failure_route. Eventually if all devices have rejected the call Kamailio times out and sends a 408 Request Timeout. Is there any way we can catch this error, and replace it with the last response we got from an actual UA? t_is_expired() and t_branch_timeout() don't seem to apply as they're on the *called* side. Is there another option to catch this overall timeout? As a side note, failure_route is quite limited in the actions that can take place there. Is it safe to access variables and update a htable? Thanks Matthew

1 0

Re: [SR-Users] Empty Subnets in Permissions Module
by Henning Westerholt 14 Sep '21

14 Sep '21

Hello, please keep the list in CC. Let’s look into the two issues one by one: 1) I had to explicitly configure the parameter: modparam("permissions", "mask_col", "mask") Although the documentation suggests "mask" is the default - the JSON output from "kamctl address dump" did not output this value on K5.5. (On K5.3 it outputted properly) Do you get an error if you do not specify the mask_col like this, or something else? From the source code the default should be “mask”. When I run the "kamcmd permissions.subnetDump" on Kamailio 5.3, it returns everything as expected - including the 0.0.0.0/0<http://0.0.0.0/0> subnets. However, when running the same commands on Kamailio 5.5, it only returns a small subset (of only 20) subnets/groups - and the selection does not appear to follow a logical selection criteria. Additionally, it does not return any groups with a 0.0.0.0/0<http://0.0.0.0/0> subnet either. It seems that the behaviour has changed regarding the “0” subnet, checkout the docs: https://kamailio.org/docs/modules/devel/modules/permissions.html#permission… It will convert them to 32/128 respectively. Can you see a 0.0.0./32 in your dump? This was changed in commit f376c82a9f8 during an extension for text files. Maybe Daniel can comment here if this was done by purpose. Otherwise, you can open an issue on our tracker about it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Tom Dworakowski <dworakowski.tom(a)gmail.com> Sent: Tuesday, September 14, 2021 5:00 PM To: Henning Westerholt <hw(a)skalatan.de> Subject: Re: [SR-Users] Empty Subnets in Permissions Module Hello Henning, Thank you for looking into this for me. I made two interesting discoveries this morning: 1) I had to explicitly configure the parameter: modparam("permissions", "mask_col", "mask") Although the documentation suggests "mask" is the default - the JSON output from "kamctl address dump" did not output this value on K5.5. (On K5.3 it outputted properly) 2) When I run the "kamcmd permissions.subnetDump" on Kamailio 5.3, it returns everything as expected - including the 0.0.0.0/0<http://0.0.0.0/0> subnets. However, when running the same commands on Kamailio 5.5, it only returns a small subset (of only 20) subnets/groups - and the selection does not appear to follow a logical selection criteria. Additionally, it does not return any groups with a 0.0.0.0/0<http://0.0.0.0/0> subnet either. From my logs - I have noted this: Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4353, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <3769, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4355, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4359, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <1955, 84.XX.XX.66, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.231, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.33, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.34, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 80.X.X.25, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 85.X.X.124, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 212.X.X.19, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4365, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4367, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4371, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <3991, 0.0.0.0, 0> inserted into address hash table At the moment of querying group id 3983 (where there is only 0.0.0.0/0<http://0.0.0.0/0>), the function returns false: DEBUG: permissions [address.c:671]: allow_source_address(): looking for <3983, [IPv4 in hex, reversed octet order], 62281> However, None of those addresses appear in the "kamcmd permissions.subnetDump" output. Moreover, if "my" group has the address 0.0.0.0/0<http://0.0.0.0/0> listed as an approved address - it will fail the test; but if I register 0.0.0.0/1<http://0.0.0.0/1> it will let me through (as my IP is < 128.0.0.0), kamcmd permissions.subnetDump will display this address. My thoughts are that there might be another table that is not being populated - or there is a filter during the import that either drops 0.0.0.0/0<http://0.0.0.0/0> or filters it out completely? Regards, Tom On Tue, Sep 14, 2021 at 4:10 AM Henning Westerholt <hw(a)skalatan.de<mailto:hw@skalatan.de>> wrote: Hello Tom, I’ve done a quick comparison of the main function and the called function. On a first view it looked identically, but I looked only a few levels deep. Do you have maybe some means to reproduce this on a test system? Then it would be probably interesting to look to the DEBUG logging of this cases. Maybe you can compare if you spot some obvious differences from the logic. Cheers, Henning From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of Tom Dworakowski Sent: Tuesday, September 14, 2021 4:10 AM To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Empty Subnets in Permissions Module Greetings all! I have two deployments of Kamailio: one running version 5.3 and one 5.5 with practically identical configurations, same (MySQL and REDIS) data sources. We have customers that we assign an ACL "group" to, where the ID of this group resolves to records in the "address" table in our MySQL database - using the "grp" field. On the box running Kamailio 5.5, we have noticed that if a group has ip_addr=0.0.0.0, mask=0, port=0 - and we try to run the allow_source_address() - it will return false, thus failing this phase of the authentication process. However, on Kamailio 5.3 we are not seeing this issue, i.e. if a customer is assigned a group where the ACL is 0.0.0.0/0<http://0.0.0.0/0> - it will let him through. Has something changed that I'm not aware of? Any suggestions on how to resolve this? My best, Tom

2 1

Capturing response from uac_reg module
by Ross McKillop 14 Sep '21

14 Sep '21

Hi, What's the best way to capture the response from REGISTER requests automatically initiated by the uac_reg module? I was looking to use event_route[uac:reply] {} but that is only triggered if the evroute flag is set on the initial call made to uac_req_send() Is there a way to set this globally so that uac:reply is called for all requests initiated for peers in the uacreg table or a better way to capture the response? Best, Ross

3 4

Kamailio 5.4.3 crash at SSL error
by Igor Olhovskiy 14 Sep '21

14 Sep '21

Hello. Kamailio 5.4.3 crashes at CentOS 7 with following error logs Sep 13 13:15:11 /usr/local/sbin/kamailio[44592]: ERROR: <core> [core/tcp_read.c:1500]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f3b93734cf8 r: 0x7f3b93734e20 (-1) Sep 13 13:15:12 /usr/local/sbin/kamailio[44594]: NOTICE: tls [tls_domain.c:747]: sr_ssl_ctx_info_callback(): SSL handshake started Sep 13 13:15:12 kernel: traps: kamailio[44594] general protection ip:7f3ba8fb3c09 sp:7ffe2c3aff70 error:0 in libssl.so.1.0.2k[7f3ba8f87000+67000] Sep 13 13:15:12 /usr/local/sbin/kamailio[44597]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 38 Sep 13 13:15:12 /usr/local/sbin/kamailio[44597]: CRITICAL: <core> [core/pass_fd.c:85]: recv_all(): 1st recv on 41 failed: Connection reset by peer Sep 13 13:15:12/usr/local/sbin/kamailio[44597]: CRITICAL: <core> [core/tcp_main.c:3543]: handle_tcp_child(): read from tcp child 2 (pid 44594, no 19) Connection reset by peer [104] Sep 13 13:15:12/usr/local/sbin/kamailio[44561]: ALERT: <core> [main.c:777]: handle_sigs(): child process 44594 exited by a signal 11 Sep 13 13:15:12/usr/local/sbin/kamailio[44561]: ALERT: <core> [main.c:780]: handle_sigs(): core was generated Sep 13 13:15:12 /usr/local/sbin/kamailio[44561]: INFO: <core> [main.c:802]: handle_sigs(): terminating due to SIGCHLD I'm pretty sure these logs are mostly not usable, but maybe they will point to some bugs. To add, this happened just occasionally and I can't reproduce it at the moment. -- Regards, Igor

2 3

Manage blacklisting on network errors
by Marat Gareev 14 Sep '21

14 Sep '21

Hello! I have a simple config for routing requests with failover and blacklisting on 408, 480 and 503 codes from servers. This is a part of config: # Wrapper for relaying requests route[RELAY] { # the base event routes t_on_branch("MANAGE_BRANCH"); t_on_reply("MANAGE_REPLY"); t_on_failure("MANAGE_FAILURE"); if (!t_relay()) { sl_reply_error(); } exit; } # Manage incoming replies onreply_route[MANAGE_REPLY] { xlog("L_NOTICE", "$rr ($rs) [$cs] ($ci) $si:$sp - $ua\n"); if ( t_check_status("(503)|(408)|(480)") ) { xlog("L_WARN", "Server will be blacklisted: $si:$sp ($rs)\n"); } } # Manage failure routing cases failure_route[MANAGE_FAILURE] { if ( !t_check_status("(503)|(408)|(480)") ) { exit; } ds_mark_dst("IP"); # blacklist if (t_is_canceled()) exit; if (!ds_next_domain()) { send_reply("503", "Service Unavailable"); exit; } route(RELAY); } If there is a timeout or network error on the server side, it is blacklisted. How can such cases be managed and how can they be logged? I didn't find this on the module page: https://www.kamailio.org/docs/modules/stable/modules/tm.html

2 2

Question about suspected memory leak presence module
by Albert Petit 14 Sep '21

14 Sep '21

Hi, I am suspecitng presence module might be having a memory leak on a production server used by an end user (not have access to it). The output of command kamcmd mod.stats presence shm is Module: presence { mem_copy_subs(148): 25720 mem_copy_subs_noc(214): 1672201904 mem_copy_subs_noc(251): 678406560 add_event(181): 88 shm_copy_event(57): 40 shm_copy_event(50): 312 add_event(156): 40 add_event(149): 456 new_shtable(66): 5767168 new_shtable(53): 262144 init_evlist(289): 16 Total: -1938302848 } I am not sure what mem_copy_subs_noc is meaning. And final output is negative, SHM is incfreasing all the time but not sure of the root cause is this a reasonable hint that a memory leak is related to presence?

2 3

Empty Subnets in Permissions Module
by Tom Dworakowski 14 Sep '21

14 Sep '21

Greetings all! I have two deployments of Kamailio: one running version 5.3 and one 5.5 with practically identical configurations, same (MySQL and REDIS) data sources. We have customers that we assign an ACL "group" to, where the ID of this group resolves to records in the "address" table in our MySQL database - using the "grp" field. On the box running Kamailio 5.5, we have noticed that if a group has ip_addr=0.0.0.0, mask=0, port=0 - and we try to run the allow_source_address() - it will return false, thus failing this phase of the authentication process. However, on Kamailio 5.3 we are not seeing this issue, i.e. if a customer is assigned a group where the ACL is 0.0.0.0/0 - it will let him through. Has something changed that I'm not aware of? Any suggestions on how to resolve this? My best, Tom

2 1

Kamailio dispatcher -> FreeSWITCH transfers handling.
by Тимур Ситдиков 11 Sep '21

11 Sep '21

Hi list! :-) I'm a total newbie in Kamailio. Trying to study) Sorry for lots of text, I'm simply don't know how to explain my questions shorter :-D I want to configure Kamailio as dispatcher, registrar and NAT traversal in front of FS farm. I've managed to set up Kamailio and Fswitches. Now I need to handle "special cases" with confs, REFER transfers etc Giovanni Maruzzelli once presented solution for this, with following logic: ------------------------------------------------------------------------------------------------------- 1) Kamailio by default distribute calls to various FSs - dispatch or load_balance 2) Each time Kamailio sends a call to a FS, it writes down which destination "number" is going to which FS server and from which UserID 3) if another call comes for the same (or related) destination, or is originated from the same UserID then Kamailio sends the call to that same FS server, bypassing default distribution algorithm ------------------------------------------------------------------------------------------------------- Sounds good and helpful, but I'm stuck :-( *Can someone please share an example or point me how and in what form should I write down call info,and how can I control it (delete on BYE or CANCEL)?* Actually there are 2 questions It seems to me that recordings can be made using HTABLEs but here's a problem: ===================================================================================== ============================================================================================= 1) PROBLEM WITH WRITING TO HTABLE ON ATT TRANSFER After the dispatcher sets $du - I write an htable entry $sht(fsdest=>$fU:$rU) = $du; Existing entries are removed on catching 'BYE' for normal clearing, and with failure_route for all failures. BYE logic is: IN WITHINNDLG route if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { if (sht_match_name("fsdest", "eq", "$fU:$rU")) { $sht(fsdest=>$fU:$rU) = $null; //BYE A->B } else { $sht(fsdest=>$rU:$fU) = $null; //BYE A<-B } } handle_ruri_alias(); route(RELAY); } } Another entry is setting up if blind transfer is made. If INVITE is coming from one of FSs, and have 'Referred-By' field. IN DIALOG route: if (is_present_hf("Referred-By")) { $sht(fsdest=>$fU:$rU) = $si; } For now it's working. Entries are written and deleted properly. *Problem with Attended transfer.* 1) A --> B = htable entry A:B=xxxx 2) A --> C = htable entry A:C=xxxx(checked and set same FS addr because $fU is present (If only it's worked as it should)) 3) Att transfer (Refer $rU B, referred-by - A. Refer-To - C) B --> C = all related entries deleted from table over BYE logic. 4) No entry B --> C (no INVITE was sent, bridged by REFER) So, logic for check active calls in htable is broken now, because we don't have entry B-->C *How can I handle writing to htable in Attended transfer case?* If another Invite will come FROM or TO B or C = there will be no htable entry. I'm not sure this is even a correct way. Surely missing something. ============================================================================================= ============================================================================================= 2) PROBLEM WITH IDENTIFYING TABLE ENTRIES Anyway, the main problem is with identifying those htables to set proper $du. If INVITE is coming TO FSs I need to check if caller ID ($fU) or dest ($rU) is present in htables. Form I need to write to hash must be like $fU:$rU Entry must be unique or it will be: 1) rewrited anytime a new invite is going to the same dest. 2) deleted anytime BYE or failure will come eg: If $sht(fsdest=>$rU) = $dd 1) 1000 --> 3200 = htable entry 3200 = xxxx 2) 1005 --> 3200 = htable entry rewriten to the same 3200 = xxxx When 1000 or 1005 leaving conf, it sends BYE and removes entry. So, next call to 3200 may be sent to the wrong FS. Ok, we have a unique entry ($fU:$rU). Checking for active destination: if (sht_match_name("fsdest", "re", ":$rU")) {} If there's an htable with $rU in key - we got a match. Now we need to assign a value from htable to $du. But, I don't know how to get the name of this entry. There's always different $fU: (or $rU if we check for the same caller ID ($fU)). eg: 1000 --> 3200 = htbale 1000 --> 3200 New call 1005 --> 3200 Check sht_match name ":3200" - got match We need to set: $du = $sht(fsdest=>$fU:$rU) But it will be $sht(fsdest=>1005:3200) and we don't have this entry. We need (fsdest=>1003:3200) But i don't see any way to get needed $fU. *Is there any way to search or identify these tables?* ============================================================================================= ============================================================================================= Can someone help me with this, please? :-) Or maybe there is a better way to do this? *My kamailio.cfg routing block in pastebin, if neededhttps://pastebin.com/1PZ0QSDW <https://pastebin.com/1PZ0QSDW>* Thank you! Regards, Tim

4 5

Info: Kamailio World 2021 starting soon - live stream
by Daniel-Constantin Mierla 10 Sep '21

10 Sep '21

Hello, to sync better on time, Kamailio World 2021 online edition is starting in about 2 hours from now (12:50 UTC Welcome and 13:00UTC the first session) - the agenda is available at: * https://kamailioworld.com/k09-online/ In short: participation is free, no registration is needed. The sessions are live streamed to YouTube KamailioWorld channel: * https://www.youtube.com/c/KamailioWorld/ YouTube chat next to the live stream can be used for addressing questions to speakers -- we will monitor it and ask the speaker inside the video conferencing room. For community interaction via text chatting, you can join the Matrix room #kamailio:matrix.kamailio.dev : * https://riot.kamailio.dev/#/room/#kamailio:matrix.kamailio.dev Questions for speakers can also be addressed in this chat room. If anyone wants to participate in the live video conferencing room, the URL is: * https://meet.kamailioworld.com/live Just note that we may have to limit the number of participants in the live session in order to ensure proper streaming quality. See you soon online! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

5 9

RPC usrloc ul.add problem
by Pepelux 09 Sep '21

09 Sep '21

Hi all I have problems adding a new location by RPC command. *# kamailio -v* version: kamailio 5.5.0 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 8.3.0 A simple example, adding an AOR which expires in 1 hour: *# date ; kamcmd ul.add kam_location 1002-test1(a)sipserver.com <1002-test1(a)sipserver.com> sip:1002-test1@192.168.89.82 <sip%3A1002-test1(a)192.168.89.82> 3600 0.0 . 0 0 0 .* Wed 08 Sep 2021 01:58:00 PM CEST Location record has been inserted correctly: *# date ; kamcmd ul.dump | grep test -A24* Wed 08 Sep 2021 01:58:02 PM CEST AoR: 1002-test1(a)sipserver.com HashID: -597689288 Contacts: { Contact: { Address: sip:1002-test1@192.168.89.82 Expires: 3598 Q: 0.000000 Call-ID: dfjrewr12386fd6-343(a)kamailio.rpc CSeq: 1 User-Agent: kamailio SIP Router - RPC Server Received: [not set] Path: [not set] State: CS_SYNC Flags: 0 CFlags: 0 Socket: [not set] Methods: 0 Ruid: ulcx-61389f47-2e44-01 Instance: [not set] Reg-Id: 0 Server-Id: 0 Tcpconn-Id: 0 Keepalive: 0 Last-Keepalive: 1631102280 KA-Roundtrip: 0 Last-Modified: 0 } } } But a few seconds later, the location record has gone: * # date ; kamcmd ul.dump | grep test -A24* Wed 08 Sep 2021 01:58:26 PM CEST In kamailio logs I can see that: * Sep 8 13:58:00 sipserver /usr/sbin/kamailio[11844]: DEBUG: usrloc [ul_rpc.c:637]: ul_rpc_add(): path == 0 -> unset Sep 8 13:58:00 sipserver /usr/sbin/kamailio[11844]: DEBUG: usrloc [ul_rpc.c:652]: ul_rpc_add(): ret: 10 table:kam_location aor:1002-test1@sipserver.com <aor%3A1002-test1(a)sipserver.com> contact:sip:1002-test1@192.168.89.82 <contact%3Asip%3A1002-test1(a)192.168.89.82> expires:3600 dtemp:0.000000 path: flags:0 bflags:0 methods:0 Sep 8 13:58:00 sipserver /usr/sbin/kamailio[11844]: DEBUG: usrloc [ul_rpc.c:660]: ul_rpc_add(): q:0 Sep 8 13:58:00 sipserver /usr/sbin/kamailio[11844]: DEBUG: usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:00 sipserver /usr/sbin/kamailio[11844]: DEBUG: usrloc [ucontact.c:1868]: uldb_insert_attrs(): no location attributes* Sep 8 13:58:03 sipserver /usr/sbin/kamailio[11827]: DEBUG: {1 81337 REGISTER 1955770655-18357-1(a)BJC.BGI.B.BBF REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:03 sipserver /usr/sbin/kamailio[11827]: DEBUG: {1 81337 REGISTER 1955770655-18357-1(a)BJC.BGI.B.BBF REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:03 sipserver /usr/sbin/kamailio[11827]: DEBUG: {1 81337 REGISTER 1955770655-18357-1(a)BJC.BGI.B.BBF REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:04 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 141 REGISTER 1aa357700bd0696702c40340595d89e7(a)185.99.186.215 REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:04 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 141 REGISTER 1aa357700bd0696702c40340595d89e7(a)185.99.186.215 REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:04 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 141 REGISTER 1aa357700bd0696702c40340595d89e7(a)185.99.186.215 REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:06 sipserver /usr/sbin/kamailio[11852]: DEBUG: {1 114 REGISTER 5ne5ebv674tptk0p1uj4gg REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:06 sipserver /usr/sbin/kamailio[11852]: DEBUG: {1 114 REGISTER 5ne5ebv674tptk0p1uj4gg REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:06 sipserver /usr/sbin/kamailio[11852]: DEBUG: {1 114 REGISTER 5ne5ebv674tptk0p1uj4gg REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:23 sipserver /usr/sbin/kamailio[11828]: DEBUG: {1 12484 REGISTER 1382185578-19234-1(a)BJC.BGI.B.BGC REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:23 sipserver /usr/sbin/kamailio[11828]: DEBUG: {1 12484 REGISTER 1382185578-19234-1(a)BJC.BGI.B.BGC REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:23 sipserver /usr/sbin/kamailio[11828]: DEBUG: {1 12484 REGISTER 1382185578-19234-1(a)BJC.BGI.B.BGC REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes * Sep 8 13:58:23 sipserver /usr/sbin/kamailio[11835]: DEBUG: usrloc [urecord.c:377]: wb_timer(): tcp connection has been lost, expiring contact sip:1002-test1@192.168.89.82 <sip%3A1002-test1(a)192.168.89.82> Sep 8 13:58:23 sipserver /usr/sbin/kamailio[11835]: DEBUG: usrloc [urecord.c:387]: wb_timer(): Binding '1002-test1(a)sipserver.com <1002-test1(a)sipserver.com>','sip:1002-test1@192.168.89.82 <sip%3A1002-test1(a)192.168.89.82>' has expired Sep 8 13:58:23 sipserver /usr/sbin/kamailio[11835]: DEBUG: usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes* Sep 8 13:58:25 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 185389 REGISTER 1487655759-19321-1(a)BJC.BGI.B.BBB REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:25 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 185389 REGISTER 1487655759-19321-1(a)BJC.BGI.B.BBB REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:25 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 185389 REGISTER 1487655759-19321-1(a)BJC.BGI.B.BBB REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:33 sipserver /usr/sbin/kamailio[11853]: DEBUG: {1 3360 REGISTER pgmirc5oirbekeaj3tmrf7 REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:33 sipserver /usr/sbin/kamailio[11853]: DEBUG: {1 3360 REGISTER pgmirc5oirbekeaj3tmrf7 REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:33 sipserver /usr/sbin/kamailio[11853]: DEBUG: {1 3360 REGISTER pgmirc5oirbekeaj3tmrf7 REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:44 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 5645 REGISTER 89744034-6071-1(a)BJC.BGI.A.BJ REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:44 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 5645 REGISTER 89744034-6071-1(a)BJC.BGI.A.BJ REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:44 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 5645 REGISTER 89744034-6071-1(a)BJC.BGI.A.BJ REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:44 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 5683 REGISTER 1974024198-16543-1(a)BJC.BGI.B.BDE REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:44 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 5683 REGISTER 1974024198-16543-1(a)BJC.BGI.B.BDE REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:44 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 5683 REGISTER 1974024198-16543-1(a)BJC.BGI.B.BDE REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:50 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 144820 REGISTER 381139623-5062-1(a)BJC.BGI.B.BAD REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:50 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 144820 REGISTER 381139623-5062-1(a)BJC.BGI.B.BAD REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:50 sipserver /usr/sbin/kamailio[11829]: DEBUG: {1 144820 REGISTER 381139623-5062-1(a)BJC.BGI.B.BAD REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:58:59 sipserver /usr/sbin/kamailio[11828]: DEBUG: {1 84973 REGISTER 467700456-5060-1(a)BJC.BGI.B.BCI REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:58:59 sipserver /usr/sbin/kamailio[11828]: DEBUG: {1 84973 REGISTER 467700456-5060-1(a)BJC.BGI.B.BCI REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:58:59 sipserver /usr/sbin/kamailio[11828]: DEBUG: {1 84973 REGISTER 467700456-5060-1(a)BJC.BGI.B.BCI REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:59:01 sipserver /usr/sbin/kamailio[11854]: DEBUG: {1 116 REGISTER 5ne5ebv674tptk0p1uj4gg REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:59:01 sipserver /usr/sbin/kamailio[11854]: DEBUG: {1 116 REGISTER 5ne5ebv674tptk0p1uj4gg REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:59:01 sipserver /usr/sbin/kamailio[11854]: DEBUG: {1 116 REGISTER 5ne5ebv674tptk0p1uj4gg REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes Sep 8 13:59:04 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 81338 REGISTER 1955770655-18357-1(a)BJC.BGI.B.BBF REGISTER} usrloc [ucontact.c:1801]: uldb_delete_attrs_ruid(): trying to delete location attributes Sep 8 13:59:04 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 81338 REGISTER 1955770655-18357-1(a)BJC.BGI.B.BBF REGISTER} usrloc [ucontact.c:72]: ucontact_xavp_store(): trying to clone per contact xavps Sep 8 13:59:04 sipserver /usr/sbin/kamailio[11830]: DEBUG: {1 81338 REGISTER 1955770655-18357-1(a)BJC.BGI.B.BBF REGISTER} usrloc [ucontact.c:1857]: uldb_insert_attrs(): trying to insert location attributes What am I doing wrong? It is supposed that the connection is by UDP. I also tried to insert the socket value as UDP, but it had the same problem. Thanks!

3 6

Topos does not add record-route on invite
by Angelo Sipper 09 Sep '21

09 Sep '21

Hello, We have the following setup on Kamailio 5.3.7 (x86_64/linux) and I am trying to use topos module on Kamailio2 in order to hide our topology but, mostly to reduce the invite size as most of the times we have fragmentation on invites from Kamailio1 as Kamailio1 it adds 2 record-routes and two via as it handles TLS from one side and UDP on the other side and we have found no wat to avoid all this info even with topos enabled on Kamailio1 there is no change on this. UA (OverTLS) -> Kamailio1 (Over UDP)-> Kamailio2 (Over UDP)-> Provider UA :50.50.50.50:5065 (TLS) Kamailio1: 170.170.170.210:5061 (TLS),170.170.170.210:5060 (UDP) Kamailio2: 170.170.170.170:5060 (UDP) Provider: 200.200.200.193:5060 (UDP) Kamailio1 does not run topos. Kamailio2 does run topos and rr with bellow settings: # ------ topos ------ modparam("topos", "db_url", DBURL) modparam("topos", "mask_callid", 0) modparam("topos", "sanity_checks", 0) modparam("topos", "branch_expire", 130) # 3 Min modparam("topos", "dialog_expire", 10800) # 3 Hours modparam("topos", "clean_interval", 60) modparam("topos", "event_mode", 3) modparam("topos", "contact_host", " sbc181.myserver.com") # ----- rr params ----- # set next param to 1 to add value to ;lr param (helps with some UAs) modparam("rr", "enable_full_lr", 0) modparam("rr", "ignore_sips", 1) # 0 = do not append from tag to the RR, 0 = append from tag to the RR modparam("rr", "append_fromtag", 0) # dual RR 0 = No, 1 = Yes when needed 2 = Always modparam("rr", "enable_double_rr", 0) The problem is that on the invite from Kamailio2 to provider, topos adds only VIA kai new contact. No record route at all. So the provider sends multiple 200 ok SDPs to wrong IPs. If I disable topos module on kamailio2 everything works fine except that we have huge invite as another VIA and another record route is added having now three of each and fragmentation is present. *Invite from Kamailio1 to Kamailio2* ------------------------------------------------- 2021/09/08 21:41:57.698823 170.170.170.210:5060 -> 170.170.170.181:5060 INVITE sip:1234567890@sip.myserver.com:5060 SIP/2.0 Record-Route: <sip:170.170.170.210;r2=on;lr;ftag=1b973153-4034-4480-89d3-c47b411bd81e;vsf=AAAAAFpUAgEBBwEAAXABAG5BR0EAQUBCZXJ2b2ljZS5ldQ--;vst=AAAAAAoMDgsBBQcGAgIAdENbQG4AFxNUXAUaGQYXWAocY2UuZXU-;did=ff2.96a;nat=yes> Record-Route: <sip:170.170.170.210:5061 ;transport=tls;r2=on;lr;ftag=1b973153-4034-4480-89d3-c47b411bd81e;vsf=AAAAAFpUAgEBBwEAAXABAG5BR0EAQUBCZXJ2b2ljZS5ldQ--;vst=AAAAAAoMDgsBBQcGAgIAdENbQG4AFxNUXAUaGQYXWAocY2UuZXU-;did=ff2.96a;nat=yes> Via: SIP/2.0/UDP 170.170.170.210;branch=z9hG4bKd703.e095cdba1da1a4b1599119c9135b7838.0;i=8eb41 Via: SIP/2.0/TLS 50.50.50.50:5065 ;received=50.50.50.50;rport=31090;branch=z9hG4bKPj9196e5f9-977c-4a53-a4c0-c0ab82b095da;alias From: 987654321 <sip: 987654321(a)sip.myserver.com >;tag=1b973153-4034-4480-89d3-c47b411bd81e To: <sip: 1234567890(a)sip.myserver.com> Contact: <sip:customer1@50.50.50.50:5065 ;transport=TLS;alias=50.50.50.50~31090~3> Call-ID: cd64414e-77d5-45b4-a52d-74ec7fb5c7ef CSeq: 15776 INVITE Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 69 Content-Type: application/sdp Content-Length: 231 P-Asserted-Identity: <sip: 987654321(a)sip.myserver.com> v=0 o=- 391641952 391641952 IN IP4 170.170.170.216 s=Asterisk c=IN IP4 170.170.170.216 t=0 0 m=audio 29478 RTP/AVP 8 0 18 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=sendrecv a=rtcp:29479 a=ptime:20 *Invite from Kamailio2 to Provider* ------------------------------------------------- 2021/09/08 21:41:57.715881 170.170.170.181:5060 -> 200.200.200.193:5060 INVITE sip: 1234567890@sbc181.myserver.com:5060 SIP/2.0 Via: SIP/2.0/UDP 170.170.170.181;branch=z9hG4bKd703.d45db1fd910c43c5e7c4f8711a5fca92.0 From: 987654321 <sip: 987654321(a)sip.myserver.com >;tag=1b973153-4034-4480-89d3-c47b411bd81e To: <sip:1234567890@sip.myserver.com> Call-ID: cd64414e-77d5-45b4-a52d-74ec7fb5c7ef CSeq: 15776 INVITE Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 68 Content-Type: application/sdp Content-Length: 231 P-Asserted-Identity: <sip: 987654321(a)sip.myserver.com> Contact: <sip:btpsh-c9-613903ef-21d75-1@sbc181.myserver.com> v=0 o=- 391641952 391641952 IN IP4 170.170.170.184 s=Asterisk c=IN IP4 170.170.170.184 t=0 0 m=audio 11450 RTP/AVP 8 0 18 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=sendrecv a=rtcp:11451 a=ptime:20 *Bellow you can see the flow* ---------------------------------------- 170.170.170.210:5060 170.170.170.170:5060 200.200.200.193:5060 qqqqqqqqqqwqqqqqqqqq qqqqqqqqqqwqqqqqqqqq qqqqqqqqqqwqqqqqqqqq 21:41:57.698823 x INVITE (SDP) x x +0.003788 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x 21:41:57.702611 x 100 trying -- your call is x x +0.013270 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:41:57.715881 x x INVITE (SDP) x +0.018529 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:41:57.734410 x x 100 Trying x +0.804083 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:41:58.538493 x x 183 Session Progress (SDP) x +0.014557 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:41:58.553050 x 183 Session Progress (SDP) x x +0.483907 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:41:59.036957 x x 183 Session Progress (SDP) x +0.012009 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:41:59.048966 x 183 Session Progress (SDP) x x +0.988036 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:00.037002 x x 183 Session Progress (SDP) x +0.010960 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:00.047962 x 183 Session Progress (SDP) x x +1.989085 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:02.037047 x x 183 Session Progress (SDP) x +0.010947 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:02.047994 x 183 Session Progress (SDP) x x +3.989064 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:06.037058 x x 183 Session Progress (SDP) x +0.008860 x x <<<qqqqqqqqqqqqqqqqqqqqqqqq x 21:42:06.045918 x 183 Session Progress (SDP) x x +1.178240 x <<<qqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.224158 x CANCEL x x +0.002725 x qqqqqqqqqqqqqqqqqqqqqqqqqq> x x 21:42:07.226883 x x CANCEL x +0.000372 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:42:07.227255 x 200 canceling x x +0.016902 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.244157 x x 200 OK x +0.004590 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:42:07.248747 x x 487 Request Terminated x +0.003547 x x <qqqqqqqqqqqqqqqqqqqqqqqqqq x 21:42:07.252294 x x ACK x +0.003737 x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x 21:42:07.256031 x 487 Request Terminated x x +0.001161 x <qqqqqqqqqqqqqqqqqqqqqqqqqq x x 21:42:07.257192 x ACK x x x qqqqqqqqqqqqqqqqqqqqqqqqqq> x TCP is out of question from the provider. Any help to use topos or any other module to reduce the size of our invites to avoid fragmentation will be much appreciated! Regards, Angelo

2 1

manually append_branch to lookup result
by David Villasmil 07 Sep '21

07 Sep '21

Hello guys, I'm trying to dynamically add a branch after doing lookup. The user is found, but in some cases I need to add a branch and do parallel forking. So i'm basically doing: route[LOCATION] { if (!lookup("location")) { .... } if (something) { route(BRANCH_TO_EXTRA); } route(RELAY); } route[BRANCH_TO_EXTRA] { $fs = MY_SOCKET; append_branch("sip:$tU@" + $sel(cfg_get.pstn.gw_ip) + ":" + $sel(cfg_get.pstn.gw_port)); return; } For some reason only the branch appended is being used (I have append_branches=1) Ideas? David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 5

via header not removed wit hremove_hf()
by Richard Robson 07 Sep '21

07 Sep '21

during testing I need to remove a Via header This is the code snippet route[REPLACE_VIA] { xlog ("L_INFO", "[REPLACE_VIA] Start of block\n"); xlog ("L_INFO", "[REPLACE_VIA] $hdrc(Via) Via headers\n"); if(remove_hf("Via")) { xlog ("L_INFO", "[REPLACE_VIA] removed Via\n"); } else { xlog ("L_INFO", "[REPLACE_VIA] did not remove Via\n"); } xlog ("L_INFO", "[REPLACE_VIA] $hdrc(Via) Via headers\n"); and this is the logs output Sep 7 08:00:00 INFO: _LOG: 3a547f956d65fe985ba189916047fc320ae150ad: [REPLACE_RURI] Start of block Sep 7 08:00:00 INFO: _LOG: 3a547f956d65fe985ba189916047fc320ae150ad: [REPLACE_VIA] Start of block Sep 7 08:00:00 INFO: _LOG: 3a547f956d65fe985ba189916047fc320ae150ad: [REPLACE_VIA] 1 Via headers Sep 7 08:00:00 INFO: _LOG: 3a547f956d65fe985ba189916047fc320ae150ad: [REPLACE_VIA] removed Via Sep 7 08:00:00 INFO: _LOG: 3a547f956d65fe985ba189916047fc320ae150ad: [REPLACE_VIA] 1 Via headers From the logs it looks like the remove_hf returns true and we have the header removed, but its still counting the Via header and the Via Header is still present when the INVIE is releyed on Regards, Richard

2 4

Kamailio and robotics repo
by Yuriy Gorlichenko 07 Sep '21

07 Sep '21

Following the promise during the Kamailio world 2021 I share the source code of the Kamailoi and robotics repo: https://github.com/arigativa/robolive

2 1

Manage multiple RTP streams with different TO-tags (forking)
by B. Tietz 07 Sep '21

07 Sep '21

Hello, following situation. I have a Kamailio (5.4) using rtpengine to loadbalance calls. If a call from Alice comes in, Kamailio decides to send the call to Carrier B from Bob. Bobs Phone is ringing and the carrier B send a 183 Session Progress with SDP and To-tag=abcd. The SDP has G722 as codec and port 1234. A few moments later carrier B send a second 183 Session Progress with SDP and TO-tag=fghi. The SDP has G711 as codec and port 5678. This is done, to play some funky music as ringtone -.- If Bob answers the call, carrier B sends a 200 OK WITHOUT SDP and TO-tag=abcd. So this should instruct our Kamailio to switch to the first G722 and port 1234. But sadly, this is just not working as expected. We tried to set the flags media-handover and port-latching for the rtpengine options and additionally set a to-tag when using rtpenging_manage. But this doesn't solve the codec change, so we have only audio when Bob answers the call, but no ringtone-music. If we allow G711 only in the outgoing INVITE to Bob, we have also tha ringtone-muisic, because there is no codec-change. Carrier B tells us, they are using a fork-mechanism. Is there something we can do, to support the codec change in 183? Or enforce carrier B to send SDP in 200 OK? Or anything else? Carrier B can not change anything in the ringtone-music-backend. They are stuck on G711. Thanks!

5 4

Re: [SR-Users] t_drop_replies not working with t_suspend in failure route
by Huber Andreas 03 Sep '21

03 Sep '21

Hi, We’re still using kamailio 4.4 but we’ll be migrating to 5.0 soon. Cool so it will be fixed when we migrate ! Thanks, Andreas From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Federico Cabiddu Sent: vendredi 12 mai 2017 11:56 To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] t_drop_replies not working with t_suspend in failure route Hi, which version are you using? A similar case had been reported some months ago and it should be fixed in 5.0. Regards, Federico On Fri, May 12, 2017 at 11:44 AM, Huber Andreas <andreas.huber(a)nagra.com<mailto:andreas.huber@nagra.com>> wrote: Hello, We have a use case where we suspend a transaction in a failure_route to give UEs that might be woken by a push notification more time to REGISTER and join the INVITE. We’d like to drop the previous branches in this case. I tried using t_drop_replies() but it has no effect. The doc states that t_drop_replies() is only working if a new branch is added. And from my understanding t_suspend() adds a new branch. But is it possible that t_drop_replies() cannot be used with t_suspend()? Or am I missing something? Kind Regards, Andreas _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

2 1

How to drop negative final response and send ACK
by Koray Vatansever 02 Sep '21

02 Sep '21

Hi, I have a problem with the following scenario: I have web and mobile sip clients for the same username. If both clients are idle, INVITE is forked and both clients ring. If web client is busy and mobile client is online and registered, the mobile client rings and the caller hears ringback tone. If web client is busy and mobile client is offline, before the mobile client receives push notification and registers, web client sends 486 busy response and caller hears busy tone. In this last scenario, I want to wait some time for the mobile client to register and ring. I tried to drop 486 response in onreply_route[x], but I found that final responses cannot be dropped in this route. I dropped 486 in reply_route, but I couldn't send an ACK for this transaction. Is there a way to implement this scenario? I would appreciate if you have any suggestions. Thanks, Koray

2 2

dns_srv_lb on or yes
by Juha Heinanen 01 Sep '21

01 Sep '21

Wiki tells: dns_srv_lb = yes | no (default no) and doc/tutorials/dns.txt tells: dns_srv_lb = on | off Which one is correct or does it matter? -- Juha

2 3

Info: Tomorrow Live - Kamailio World 2021 - Online
by Daniel-Constantin Mierla 31 Aug '21

31 Aug '21

Hello, couple of details for those that want to watch live or even participate to Kamailio World Online Conference, Sep 1-2, 2021 - the schedule is available at: * https://www.kamailioworld.com/k09-online/ There is no registration required, participation is completely free. You can watch live the presentations starting with 13:00UTC (14:00 London, 15:00 Berlin/Paris/Rome/Madrid, 09:00 New York) via KamailioWorld youtube channel: * https://www.youtube.com/c/KamailioWorld If you want to participate to the live video conferencing room, the link is: * https://meet.kamailioworld.com/live It is recommended to do it only if you want to address questions and interact with the speakers, otherwise the capacity of the video conferencing system may be filled and we will have to restrict the access in order to ensure good quality for presentations. You can also address questions via youtube chat that will be available next to the live stream or Matrix room: * #kamailio:matrix.kamailio.dev * https://riot.kamailio.dev/#/room/#kamailio:matrix.kamailio.dev To interact with other community member, join the Matrix chat room. No registration is required for Matrix to join the room, however the web client at the link above does not support the guests feature, you will have to use another client application that supports it or make an account with any federated Matrix server, like the one from element.io: * https://app.element.io/#/welcome Looking forward to chatting with many of you during the next two days! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

Add PIDF-LO object to INVITE
by Adarsh Chauhan 31 Aug '21

31 Aug '21

Hi All, I am trying to add PIDF-LO XML to INVITE, however i have had little success so far. My end goal is to create an invite like mentioned in https://docs.microsoft.com/en-us/openspecs/office_protocols/ms-sipre/4010da… I have the following config: request_route{ xlog("L_DBG","REQUEST RECEIVED \n ($mb) \n"); if (is_method("INVITE")) { xinfo("$ua\n"); regex_substring("$ua", "([a-f0-9]{12})",0, 1, "$var(asd)"); if($var(asd)!="") { http_client_query("http://127.0.0.1/location/$var(asd)","$var(result)"); xdbg("$rc ,[$var(result)]\n"); if(!has_body("application/pidf+xml")) { set_body_multipart("$rb", "application/sdp", "delimiter"); msg_apply_changes(); append_body_part($(var(result){s.unquote}), "application/pidf+xml"); msg_apply_changes(); } }else { xerr("NO MAC ADDRESS FOUND\n"); } } route("forward"); } which achieves the following but doesn't have the xml in the correct format. I have explored most of the modules but couldnt find a handy function for this. INVITE sip:service@10.0.1.133:5060 SIP/2.0 Via: SIP/2.0/TCP 169.254.172.2;branch=z9hG4bK3de6.d3b4cddbcbdba59a3e190c41b06ada15.0;i=1 From: sipp <sip:sipp@1.1.1.1:45907>;tag=21113SIPpTag001 To: service <sip:service@10.0.1.133:5060> Call-ID: 1-21113(a)1.1.1.1 CSeq: 1 INVITE Contact: sip:sipp@1.1.1.1:45907 Max-Forwards: 70 Subject: Performance Test Content-Length: 937 Content-Type: multipart/mixed;boundary="delimiter" Mime-Version: 1.0 --delimiter Content-Type: application/sdp v=0 o=user1 53655765 2353687637 IN IP4 172.31.87.143 s=- c=IN IP4 1.1.1.1 t=0 0 m=audio 6000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --delimiter Content-Type: application/pidf+xml <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<presence xmlns:xsd=\"http:/ /www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/ XMLSchema-instance\" entity=\"sip:U SER9(a)SBSBVR00Test0m.ABC.com\" xmlns=\"urn:ietf:params:xml:ns:pidf\">\n<tuple id=\"tuple0\">\n<status>\n<geopriv xmlns=\"urn:ietf:params:xml:ns:pidf:geopriv10\">\n<civicAddre ss xmlns=\"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr\">\n['<STS>Ave</STS>\\n', '<A1>WA</A1>\\n', '<A3>Redmond</A3>\\n', '<RD>163rd</RD>\\n', '<PC>98052</PC>\\n', '<POD >NE</POD>\\n', '<NAM>Contoso Corporation </NAM>\\n', '<HNO>3910</HNO>\\n', '<country>US</country>\\n']\n</civicAddress>\n</geopriv>\n</status>\n</tuple>\n</presence> --delimiter-- Regards, Adarsh Chauhan

1 0

What does "tls.reload" actually do?
by Sebastian Damm 30 Aug '21

30 Aug '21

Hi, I noticed a strange behavior on some of our proxy servers, all running Kamailio 5.3.8. After running for some time (weeks), our monitoring system sporadically starts reporting errors. The check connects via tls and registers to an Asterisk behind the proxy server. When this happens, the Kamailio log shows the following line: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1409441B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error When restarting Kamailio, the problem goes away only to come back after some weeks uptime again. On one host, I tried to find something using kamcmd, and I don't know why but I also issued "tls.reload". And from that point, the monitoring system has not reported the system as faulty anymore. I repeated the same thing on other hosts when the problem occured there, all with the same result. "tls.reload" helps. But from the documentation, I don't know why. Does anybody have an explanation for it? Regards, Sebastian

4 8

Slack Group
by Daniel Donoghue 26 Aug '21

26 Aug '21

Hello everyone Does anybody know if the Slack workspace at kamailio.slack.com (as mentioned on https://www.kamailio.org/w/contact-us/) is still active? If it is, who should we contact for access? With every blessing, — Daniel Donoghue

2 1

pua dialogindo doesn't not generate PUBLISH when routes is written on kemi framework(python)
by Zhan Bazarov 26 Aug '21

26 Aug '21

Hi everyone. I have an issue, when I loaded the kemi python engine - module pua_dialoginfo stopped sending publishes... Has anyone faced the same issue? kamailio version is 5.4.5

1 0

no transaction found so that cant step into route-block
by fran.interpla.56906 26 Aug '21

26 Aug '21

1 0

no transaction found so that cant step into route-block
by fran.interpla.56906 26 Aug '21

26 Aug '21

1 0

Kamailio v5.5.2 Released
by Daniel-Constantin Mierla 25 Aug '21

25 Aug '21

Hello, Kamailio SIP Server v5.5.2 stable release is out. This is a maintenance release of the latest stable branch, 5.5, that includes fixes since the release of v5.5.1. 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.2. For more details about version 5.5.2 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2021/08/kamailio-v5-5-2-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

3 2

MS Teams outbound calls. Called number normalization
by Володимир Іванець 25 Aug '21

25 Aug '21

Hello all! I'm testing integration with MS Teams. I treat calls from Teams to the phone system the same way as calls from phones. And would like to ask if someone has already dealt with this. My test account location is set to the United States. When I make a call to "200", an INVITE request from Teams to Kamailio will have "+1200" in the To URI user. I could just strip "+1" but when I make a call to "100", Teams sends "+100". So in this case I need to strip only one character. The problem is that I don't know when I need to remove one or two characters. And it gets more complicated when I change my test account location. For some countries, Teams prepend 3 characters. What do to make sure phone numbers are consistent? I thought this behavior could be disabled in Teams but could not find anything related yet. Thank you! Regards, Volodymyr Ivanets

1 0

Releasing Kamailio v5.5.2
by Daniel-Constantin Mierla 25 Aug '21

25 Aug '21

Hello, I am considering to release Kamailio v5.5.2 sometime next week, likely on Wednesday (August 25, 2021). 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

2 2

[VoLTE] 401 unauthorized error
by 오택경 24 Aug '21

24 Aug '21

Hi. I am implementing the VoLTE setup with the dockerized project (https://github.com/herlesupreeth/docker_open5gs https://github.com/herlesupreeth/docker_open5gs). I have almost done to run the VoLTE service, but 401 unauthorized error in sip and auth-pending error in fhoss have occured. How can I fix this problem? I will share the discussion note in which I tried to solve some problems including the above one. : https://github.com/herlesupreeth/docker_open5gs/issues/55 https://github.com/herlesupreeth/docker_open5gs/issues/55 Very thanks, Taekkyung Oh.

3 7

Race conditions upon quick reinvite
by David VILLAUME 24 Aug '21

24 Aug '21

Hello, We encounter sometimes reinvite from some provider really quickly after 200 OK ACK so sometime there a race conditions where the re-invite exits Kamailio before the ACK leading to some Freeswitch “500 Overlapping Requests”. [cid:image001.png@01D798FA.6F5B9D80] I tried to catch the 500 on failure-route unsuccessfully as transaction is already established. Do you have any idea on how I could deal with this behavour ? Running 5.3.6 with 8 childs modules used :(tm + dialog) No costly action performed on ack that can explain slowliness. Regards, David

3 3

kazoo error
by 崔群 24 Aug '21

24 Aug '21

Dear sir: I have some problems。the kamailio version is 5.3.0. My linux version is centos 7. the kamailio log: ERROR: kazoo [kz_amqp.c:2238]: kz_amqp_send_ex(): Failed to publish -9 : a socket error occurred ERROR: kazoo [kz_amqp.c:2707]: kz_amqp_publisher_send(): error sending publish to zone : local , connection id : 1, uri : amqp://admin The connection between kamailio and rabbitmq was interrupted, which caused the queue of MQ to be blocked and the message could not be consumed。

2 1

Some questions about drouting module
by Андрей Яри н 23 Aug '21

23 Aug '21

Hello! I test module on Centos 7, kamailio version 5.5 and found some strange things: 1) Definition of table dr_gateways at https://kamailio.org/docs/modules/5.5.x/modules/drouting.html#idm98 - in DB there is field 'attrs' and only notice about it is module param 3.8. attrs_avp but it doesnt describe table field. In OpenSIPS docs i found description * attributes (not used by DR engine, but only pushed to script level when routing to this GW) In kamailio this field is deprecated or its only docs misses param? 2) Previous moment was found when i try to resolve: WARNING: drouting [dr_load.c:529]: dr_load_routing_info(): route <1> does not exist "Definition of dr_rules table" says that field has type of integer, but realy in database its varchar and i think its old docs. But i use KEMI question is - how i can tell module that it must be called in KEMI, not in native? 3) Every time when i call 'kamcmd drouting.reload' i get message CRITICAL: <core> [core/mem/q_malloc.c:502]: qm_free(): BUG: bad pointer 0x7f3e4cea04c0 (out of memory block!) called from core: core/utils/tmrec.c: tmrec_free(393) - ignoring I rollback to 5.4 and still get this error. As i understand its old module and its can be internal error - how critical this error can be? 4) Also planned commands like drouting.dump gws|gw_lists|rules? -- С уважением, Ярин Андрей Анатольевич инженер, группы управления телефонией Группа компаний «Интерсвязь» e-mail: yarin-aa(a)intersvyaz.net

2 3

Kamailio as basic dispatcher for load balancing
by Philipp Trenz 23 Aug '21

23 Aug '21

Hey there, I’m Philipp, an IT Systems Engineer from Potsdam, Germany and want to deepen my knowledge in SIP communication on scale. Currently, my setup is quite simple: A single stateless Asterisk instance, fully managed via ARI, which registers to multiple VoIP providers, only processes incoming calls to play audio files (no outgoing or conference calls). Now, with growing load on the single Asterisk instance, I would like to have one or two Kamailio instances, which will balance the load of incoming calls to multiple Asterisk instances. On which Asterisk instance they end up is irrelevant for me, as the calls can be processed on every instance. I looked into some Kamailio and Astricon conference speeches and checked out some tutorials. But still I’m not quite sure where to start. So here are some basic questions which would really help me out to get going: As I don’t want to have registrations of all my Asterisk instances at the VoIP providers, I should use the UAC module to let Kamailio do the registering to the VoIP providers and register my Asterisk instances to Kamailio, right? Will Kamailio automatically apply new outbound registrations when added to the database or do I have to trigger that manually? Should I use one or two instances of Kamailio, how hard is it to configure them fail-safe? For writing my first config file, should I start blank or from the standard config, what’s best practice? Thanks in advance, looking forward to your replies! Philipp

3 5

How tell if rtp packets are being relayed through rtpengine in kamailio
by Faiz Fazaluddin 23 Aug '21

23 Aug '21

Hi, I want to see if rtp packets are being relayed through kamailio. I am attmepting to connect rtpengine with kamailio, but am not sure if it is working, how can I tell? I have the kamailio server on a different VM than the clients. In wireshark, no rtp packets show on the server VM and rtp packets only seem to be going directly through the client VM. Rtp engine mentions being unable to find hashtables when attempting to implement a delete_node command. Thank you very much for your help, Faiz

3 2

Register Forwarding
by Thomas Grande 21 Aug '21

21 Aug '21

Hi there! I bumped into this post to perform forwarding of REGISTER requests and then saving a local cache on 2xx replies from main Registrar: https://lists.kamailio.org/pipermail/sr-users/2020-October/110779.html I think I understand all the steps described, but some features I need are missing: - How to change the Via headers to perform topology hiding? I understand TOPOS and TOPOH do not work on these types of messages. - Change contact header so that registrar responses traverse the Kamailio box. (Use textops I suppose?) - Besides, is this approach still the best in comparison to OpenSIPs mid-registrar module? Thanks in advance, -- *Thomás Alimena Del Grande* Engenharia - Aligera Tel. 51 3500-0121

3 2

record_route() from websocket UA to tls UA
by Juha Heinanen 20 Aug '21

20 Aug '21

I noticed that when jsSIP UA that has registered over wss calls another SIP UA that has registered over tls, record_route() adds only one Route URI to outgoing INVITE (example below). This causes BYE to fail. This issue may be caused by the fact that both UAs register over the same Kamailio tls listening socket. Still two Route URIs should be added in the same way as is done when one UA registers over tcp and the other over udp. -- Juha --------------------------------------------------------------------- 09:25:43.639833 wss:87.95.73.155:19458 wss:192.27.134.1:5061 INVITE sip:foo@test.tutpro.com SIP/2.0 Via: SIP/2.0/WSS jovobf9n4svm.invalid;branch=z9hG4bK2639638 Max-Forwards: 69 To: <sip:foo@test.tutpro.com> From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb Call-ID: ovhd9fu1fl1a66nec011 CSeq: 1387 INVITE Contact: <sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5> ... 09:25:43.649462 tls:192.27.134.1:5061 tls:87.95.73.155:19461 INVITE sip:foo-0x793ee87a90@10.158.141.103:38378;transport=tls SIP/2.0 Record-Route: <sip:192.27.134.1:5061;transport=ws;sn=ext_tls;lr;n2;dtlsf=avp;pm=0;ice> Via: SIP/2.0/TLS 192.27.134.1:5061;branch=z9hG4bK637c.7e15ef5b84ea054cfc8ea3d4e860521f.0 Via: SIP/2.0/WSS jovobf9n4svm.invalid;rport=19458;received=87.95.73.155;branch=z9hG4bK2639638 Max-Forwards: 68 To: <sip:foo@test.tutpro.com> From: " Test" <sip:test@test.tutpro.com>;tag=f7lpsuo7cb Call-ID: ovhd9fu1fl1a66nec011 CSeq: 1387 INVITE Contact: <sip:test@test.tutpro.com;gr=urn:uuid:e7f92a54-2295-4772-abc8-504be07e94c5>

2 11

install latest sems-server on debian 10 buster
by Mojtaba 18 Aug '21

18 Aug '21

Hello there, Does anybody have experience installing the latest SEMS-Server (1.6.0) on debian 10 buster? I tried to install both 1.6.0. and 1.7-dev and some issues are occurred, but i installed the version 1.3.1 on debian 8 before. Any help would be appreciated. Thanks with best regards -- --Mojtaba Esfandiari.S

4 11

How to insert user=phone header INVITE TO FROM
by César Matheus 18 Aug '21

18 Aug '21

Hi list. mY provider asks me to insert user = phone in my header. because it requires to receive my INVITE with user = phone in TO and FROM However, I add the user = phone in my configuration like this: $ ru = "sip:" + $ rU + "@" + $ sel (cfg_get.pstn1.gw_ip) + ":" + $ sel (cfg_get.pstn1.gw_port) + "; user = phone"; but only the INVITE appears, not in the TO or FROM. INVITE sip: 09872323232(a)X.Y.X.K: 5060; user = phone SIP / 2.0 From: <sip: XXXXYYYYY(a)172.20.12.4: 5060>; tag = 15552444533876 To: <sip: 09872323232(a)172.20.12.2: 5060> You can help me solve it. Thanks. -- César Matheus

3 2

crash in timer
by Juha Heinanen 17 Aug '21

17 Aug '21

Any idea what could cause the crash shown in the bt below? This is with Kamailio 5.5. -- Juha [New LWP 12061] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". bt Core was generated by `/usr/bin/sip-proxy -f /etc/sip-proxy/sip-proxy.cfg -P /run/sip-proxy/sip-proxy.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000563d3b390c5d in timer_list_expire (t=1584008014, h=0x7f7a1e76bb40, slow_l=0x7f7a1e76d680, slow_mark=63909) at core/timer.c:846 846 core/timer.c: No such file or directory. (gdb) bt full #0 0x0000563d3b390c5d in timer_list_expire (t=1584008014, h=0x7f7a1e76bb40, slow_l=0x7f7a1e76d680, slow_mark=63909) at core/timer.c:846 tl = 0x7f7a226ecbd8 ret = 0 #1 0x0000563d3b391219 in timer_handler () at core/timer.c:922 saved_ticks = 1584008014 run_slow_timer = 0 i = 421 __func__ = "timer_handler" #2 0x0000563d3b391742 in timer_main () at core/timer.c:961 No locals. #3 0x0000563d3b2c94de in main_loop () at main.c:1839 i = 8 pid = 0 si = 0x0 si_desc = "udp receiver child=7 sock=46.182.160.20:5060\000\000\000\000\003\000\000\000 \000\000\000\000\071CU\356xL\375\000\000\000\000\000\000\000\000\210\300m;=V\000\000\000\000\000\000\000\000\000\000\260\334\371Jz\177\000\000\263\331r;=V\000\000\000\000\000 \000\000\000\000\340\b3;\374\177\000\000\t\365U;=V\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #4 0x0000563d3b2d44aa in main (argc=17, argv=0x7ffc3b330e28) at main.c:3053 cfg_stream = 0x563d3b9ea290 c = -1 r = 0 tmp = 0x7ffc3b331f3f "" tmp_len = 1260628273 port = 32634 proto = 0 ahost = 0x0 aport = 0 --Type <RET> for more, q to quit, c to continue without paging--c options = 0x563d3b6dece0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 1970794883 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0xffff00001f80 <error: Cannot access memory at address 0xffff00001f80> st = {st_dev = 21, st_ino = 21649, st_nlink = 2, st_mode = 16832, st_uid = 109, st_gid = 115, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1620846563, tv_nsec = 71986646}, st_mtim = {tv_sec = 1628122861, tv_nsec = 116913769}, st_ctim = {tv_sec = 1628122861, tv_nsec = 616909103}, __glibc_reserved = {0, 0, 0}} tbuf = "\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\060\067&Kz\177\000\000\000\000\000\000\000\000\000\000\240\241>;\374\177\000\000\364:$Kz\177\000\000\b\000\000\000\000\000\000\000\230\242>;\374\177\000\000\060\067&Kz\177\000\000\310\v3;\374\177\000\000\304\v3;\374\177", '\000' <repeats 18 times>, "\230\242>;\374\177\000\000\250\241>;\374\177\000\000'\256\002Kz\177\000\000&\260be\000\000\000\000\060\r3;\374\177\000\000\300\212\225\001\000\000\000\000\220\f3;\374\177\000\000\200\f3;\374\177\000\000\310\v3;\374\177\000\000X7&Kz\177\000\000\001", '\000' <repeats 31 times>... option_index = 0 long_options = {{name = 0x563d3b6e0f3f "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x563d3b6dc4e1 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x563d3b6e0f44 "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x563d3b6e0f4a "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x563d3b6e0f50 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x563d3b6e0f59 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x563d3b6e0f63 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x563d3b6e0f6d "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x563d3b6e0f78 "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x563d3b6e0f81 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x563d3b6e0f8c "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x563d3b6e0f92 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x563d3b6e0f9c "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main"

1 0

Info: First group of presentations at Kamailio World Online 2021
by Daniel-Constantin Mierla 17 Aug '21

17 Aug '21

Hello, the first group of presentations selected for the next Kamailio World Online, September 1-2, 2021, has been published, aiming to provide a good knowledge base of using Kamailio for different deployment types: segregation of networks with an SBC-like role, controlling robots, RTP streams management with RTPEngine, configuration variables or transformations, SIP attacks handling and asynchronous SIP routing. You can find more details at: * https://kamailioworld.com/k09-online/ The schedule will be completed during the next days, with another group of interesting sessions and open discussion panels. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

No docker hub automated builds
by Sergey Safarov 14 Aug '21

14 Aug '21

I found that not more automated builds available on docker hub https://www.docker.com/blog/changes-to-docker-hub-autobuilds/ Looks like we need to make some changes for the alpine docker image. Maybe use github actions for this task? https://docs.docker.com/ci-cd/github-actions/ Sergey

1 0

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