sr-users May 2020

sr-users@lists.kamailio.org

66 participants
84 discussions

congestion control priority for priority based dispatching
by Julien Chavanton 28 May '20

28 May '20

Hi Folks, Just found another simple use case of the dispatcher latency stats. Just shraing this idea of a feature I want to contribute. When using dispatcher algorithm 8: “8” - select destination sorted by priority attribute value (serial forking ordered by priority). If the gateway as the attribute, the priority becomes the estimated latency. cc-priority - The dispatcher would automatically prioritize the closest one. - If a gateway is becoming unresponsive it will automatically become de prioritize. Consider this real life scenario where you have gateways in East and West Coast Example URI: sip:28.71.19.140 FLAGS: AP PRIORITY: 10 ATTRS: { BODY: cc_priority=1 } LATENCY: { AVG: 84.001000 STD: 0.062000 EST: 84.001000 (high == low priority) MAX: 93 TIMEOUT: 0 URI: sip:28.71.16.140 FLAGS: AP PRIORITY: 10 ATTRS: { BODY: cc_priority=1 } LATENCY: { AVG: 29.110000 STD: 2.383000 EST: 31.999000 (low == high priority) MAX: 1499 TIMEOUT: 1 Another major improvement to all of this would be to gather stats on INVITE <> 100 to have a very accurate latency estimation even if the gateway does not support SIP OPTIONS pings

3 3

Kamailio not using system resolver for hostname resolution (DMQ)?
by George Diamantopoulos 28 May '20

28 May '20

Hello all, I've come across this today when trying to setup DMQ replication: root@sbcpub0-stage-lhe0-cn1:/root# systemctl restart kamailio root@sbcpub0-stage-lhe0-cn1:/root# kamcmd dmq.list_nodes { host: 172.30.154.189 port: 5090 resolved_ip: 172.30.154.189 status: active last_notification: 0 local: 1 } root@sbcpub0-stage-lhe0-cn1:/root# getent hosts dmq-ng.services.domain.com 172.30.154.189 dmq-ng.services.domain.com 172.17.130.13 dmq-ng.services.domain.com root@sbcpub0-stage-lhe0-cn1:/root# grep dmq-ng /etc/kamailio/* /etc/kamailio/kamailio-module-params.cfg:modparam("dmq", "notification_address", "sip:dmq-ng.services.domain.com:5090") In another case, where the resolving IPs for the DMQ service hostname were listed as A records in DNS, this worked as expected. In this case, the second host of the DMQ group is not listed in dmq.list_nodes, despite its being set in /etc/hosts, as shown by the getent command. Doesn't kamailio use nss for hostname resolution? Am I missing something else? Thanks! BR, George

5 10

Fwd: Kamailio--Sipcapture--Homer
by Uttam Giri 27 May '20

27 May '20

Hi,i did setup homer server and wanted to send my sipcapture from Kamailio to homer.however in the Kamailio log I am seeing these errors. Could you please guide how I can fix these errors kamailio log: 2(25) ERROR: <core> [core/udp_server.c:594]: udp_send(): sendto(sock, buf: 0x7f390dc5d438, len: 1525, 0, dst: (10.0.1.59:9060), tolen: 16) - err: Message too long (90) 2(25) ERROR: siptrace [../../core/forward.h:228]: msg_send_buffer(): udp_send failed 2(25) ERROR: siptrace [siptrace_hep.c:215]: trace_send_hep3_duplicate(): cannot send hep duplicate message Configuration:- loadmodule "siptrace" #Siptrace modparam("siptrace", "duplicate_uri", "sip:10.0.1.59:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_flag", 22) modparam("siptrace", "trace_on", 1) modparam("siptrace", "hep_version", 3) Thanks, Uttam

1 0

27 May '20

Hi; I have to control the login attempts, but blocking the user until I unlock him from web site. To do that I have to save the paramter on database. There is any table and column where I can save that parameter? I'm using the htable module to count the Authentification attempts. There's is any module that do that easily? Thank you.

2 4

CRITICAL: <core> [core/data_lump.c:292]: del_lump(): offset exceeds message size (1436 > 1432) aborting...
by Denys Pozniak 27 May '20

27 May '20

Hello! Could you please check the reason of crash below? syslog: kamailio[31738]: CRITICAL: |RGFLAFL63U|<core> [core/data_lump.c:292]: del_lump(): offset exceeds message size (1436 > 1432) aborting... gdb ( uri and IP were modified ): Core was generated by `/usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.'. Program terminated with signal 6, Aborted. #0 0x00007f5d8556d4f5 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64 glibc-2.12-1.212.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-65.el6.x86_64 libcom_err-1.41.12-24.el6.x86_64 libcurl-7.19.7-53.el6_9.x86_64 libidn-1.18-2.el6.x86_64 libselinux-2.0.94-7.el6.x86_64 libssh2-1.4.2-2.el6_7.1.x86_64 mysql-libs-5.1.73-8.el6_8.x86_64 nspr-4.19.0-1.el6.x86_64 nss-3.36.0-9.el6_10.x86_64 nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64 nss-util-3.36.0-1.el6.x86_64 openldap-2.4.40-16.el6.x86_64 openssl-1.0.1e-58.el6_10.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt #0 0x00007f5d8556d4f5 in raise () from /lib64/libc.so.6 #1 0x00007f5d8556ecd5 in abort () from /lib64/libc.so.6 #2 0x000000000046a4a6 in del_lump (msg=0x7f5d846cd798, offset=1436, len=29, type=HDR_OTHER_T) at core/data_lump.c:293 #3 0x00007f5d7e6fd7f5 in alter_rtcp (msg=0x7f5d846cd798, body=0x7fffc60c8600, oldport=0x7f5d84715500, newport=0x7fffc60c8550) at rtpproxy.c:1229 #4 0x00007f5d7e70ec5d in force_rtp_proxy (msg=0x7f5d846cd798, str1=0x7f5d846af190 "co", str2=0x7fffc60c87f0 "162.221.21.250", offer=1, forcedIP=0) at rtpproxy.c:2669 #5 0x00007f5d7e705f64 in rtpproxy_manage (msg=0x7f5d846cd798, flags=0x7f5d846af190 "co", ip=0x0) at rtpproxy.c:1862 #6 0x00007f5d7e7064c6 in rtpproxy_manage1 (msg=0x7f5d846cd798, flags=0x7f5d846907f0 "\220\361j\204]\177", ip=0x0) at rtpproxy.c:1904 #7 0x0000000000434f19 in do_action (h=0x7fffc60cae70, a=0x7f5d846b16d8, msg=0x7f5d846cd798) at core/action.c:1073 #8 0x0000000000441a94 in run_actions (h=0x7fffc60cae70, a=0x7f5d846b16d8, msg=0x7f5d846cd798) at core/action.c:1564 #9 0x0000000000431663 in do_action (h=0x7fffc60cae70, a=0x7f5d8468ae40, msg=0x7f5d846cd798) at core/action.c:691 #10 0x0000000000441a94 in run_actions (h=0x7fffc60cae70, a=0x7f5d846848a0, msg=0x7f5d846cd798) at core/action.c:1564 #11 0x0000000000431663 in do_action (h=0x7fffc60cae70, a=0x7f5d846abca0, msg=0x7f5d846cd798) at core/action.c:691 #12 0x0000000000441a94 in run_actions (h=0x7fffc60cae70, a=0x7f5d846abca0, msg=0x7f5d846cd798) at core/action.c:1564 #13 0x0000000000434df4 in do_action (h=0x7fffc60cae70, a=0x7f5d846abdf0, msg=0x7f5d846cd798) at core/action.c:1058 #14 0x0000000000441a94 in run_actions (h=0x7fffc60cae70, a=0x7f5d846a45f8, msg=0x7f5d846cd798) at core/action.c:1564 #15 0x0000000000442190 in run_top_route (a=0x7f5d846a45f8, msg=0x7f5d846cd798, c=0x0) at core/action.c:1646 #16 0x0000000000546d87 in receive_msg ( buf=0x29463b0 "INVITE sip:999@18.12.188.108 SIP/2.0\r\nVia: SIP/2.0/TCP 10.0.0.33:49631;branch=z9hG4bK.9XHFYH0zF;rport\r\nFrom: < sip:RGFLAFL63U@proxy.company.com>;tag=DcTh-~6~M\r\nTo: \"Liz - Home Office\" <s"..., len=1432, rcv_info=0x7f5d5e3ae778) at core/receive.c:340 #17 0x000000000064807d in receive_tcp_msg ( tcpbuf=0x7f5d5e3aea58 "INVITE sip:999@18.12.188.108 SIP/2.0\r\nVia: SIP/2.0/TCP 10.0.0.33:49631;branch=z9hG4bK.9XHFYH0zF;rport\r\nFrom: < sip:RGFLAFL63U@proxy.company.com>;tag=DcTh-~6~M\r\nTo: \"Liz - Home Office\" <s"..., len=1432, rcv_info=0x7f5d5e3ae778, con=0x7f5d5e3ae760) at core/tcp_read.c:1448 #18 0x000000000064a0fd in tcp_read_req (con=0x7f5d5e3ae760, bytes_read=0x7fffc60cb8ac, read_flags=0x7fffc60cb8a4) at core/tcp_read.c:1631 #19 0x000000000064dcd3 in handle_io (fm=0x7f5d846ecda0, events=1, idx=-1) at core/tcp_read.c:1862 #20 0x000000000063b7c4 in io_wait_loop_epoll (h=0xacd340, t=2, repeat=0) at core/io_wait.h:1065 #21 0x000000000064f133 in tcp_receive_loop (unix_sock=51) at core/tcp_read.c:1974 #22 0x00000000006318c8 in tcp_init_children () at core/tcp_main.c:4853 #23 0x0000000000425db5 in main_loop () at main.c:1745 #24 0x000000000042c45e in main (argc=13, argv=0x7fffc60cc0e8) at main.c:2696 (gdb) CentOS release 6.10 (Final) version: kamailio 5.2.2 (x86_64/linux) 67f967 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_BLACKLIST, HAVE_RESOLV_RES 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: 67f967 compiled on 11:39:47 Mar 11 2019 with gcc 4.4.7 -- BR, Denys Pozniak

2 1

CANCEL relayed to broadcast 255.255.255.255
by Sergiu Pojoga 27 May '20

27 May '20

Hi gents, Got this weird "problem", where CANCEL request is relayed to both the right destination as well as the 255.255.255.255 broadcast address!? I have no such logic in my script, that's for sure. I doesn't do anything harmful (as far as I can tell), but I'm just curious why it's doing that. Any ideas? version: kamailio 5.3.4 *SIP Trace:* U 2020/05/26 08:40:10.941722 PBXIP:5060 -> KAMAILIO_IP:5060 CANCEL sip:2383@DOWNSTREAM_IP:10533;transport=TLS SIP/2.0 Via: SIP/2.0/UDP PBXIP:5060;branch=z9hG4bK450689d6 Max-Forwards: 69 From: "some callerid" <sip:18001111111@mypbx.mydomain.com>;tag=as4d223616 To: <sip:2383@DOWNSTREAM_IP:10533;transport=TLS> Call-ID: 1511475b69f6379b08f04d110f534da1(a)mypbx.mydomain.com CSeq: 102 CANCEL User-Agent: B2B Content-Length: 0 U 2020/05/26 08:40:10.941799 KAMAILIO_IP:5060 -> 255.255.255.255:5060 CANCEL sip:2383@DOWNSTREAM_IP:10533;transport=TLS SIP/2.0 Via: SIP/2.0/UDP PBXIP:5060;branch=z9hG4bK450689d6 Max-Forwards: 69 From: "some callerid" <sip:18001111111@mypbx.mydomain.com>;tag=as4d223616 To: <sip:2383@DOWNSTREAM_IP:10533;transport=TLS> Call-ID: 1511475b69f6379b08f04d110f534da1(a)mypbx.mydomain.com CSeq: 102 CANCEL User-Agent: B2B Content-Length: 0 T 2020/05/26 08:40:10.941899 KAMAILIO_IP:5061 -> DOWNSTREAM_IP:10533 CANCEL sip:2383@DOWNSTREAM_IP:10533;transport=TLS SIP/2.0 Via: SIP/2.0/TLS proxy.mydomain.com:5061;branch=z9hG4bK3cbb.4c6a526982fa1fb93ca1ba73afd8484f.0 Max-Forwards: 69 From: "some callerid" <sip:18001111111@mypbx.mydomain.com>;tag=as4d223616 To: <sip:2383@DOWNSTREAM_IP:10533;transport=TLS> Call-ID: 1511475b69f6379b08f04d110f534da1(a)mypbx.mydomain.com CSeq: 102 CANCEL Content-Length: 0 U 2020/05/26 08:40:10.941935 KAMAILIO_IP:5060 -> PBXIP:5060 SIP/2.0 200 canceling Via: SIP/2.0/UDP PBXIP:5060;branch=z9hG4bK450689d6 From: "some callerid" <sip:18001111111@mypbx.mydomain.com>;tag=as4d223616 To: <sip:2383@DOWNSTREAM_IP :10533;transport=TLS>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-612a1516 Call-ID: 1511475b69f6379b08f04d110f534da1(a)mypbx.mydomain.com CSeq: 102 CANCEL Server: Edge Content-Length: 0 Thanks, --Sergiu

2 2

Blind call forwarding with kamailio
by Son Vu 27 May '20

27 May '20

Dear all, I follow tutorial to setup blind call forwarding with kamailio but it seems outdate https://kamailio.org/docs/ser-getting-started/SER-GettingStarted.pdf https://www.kamailio.org/wiki/tutorials/mini-howto-admin/call_forwarding?s%… Is anyone setup it with kamailio? Could you please help me some guidance on this? Best regards, Son -- ================== Best regards, Son Vu

1 0

Using variables in remove_hf
by Cinthia Leung 27 May '20

27 May '20

Hi, I'm trying to use this textops function with a variable, ie remove_hf($var(x)). I know the documentation does not explicitly say that variables are allowed, but it works. However, it's throwing the following error: textops [textops.c:3431]: hname_fixup(): using hdr type name <P-Top-Secret> <core> [core/mem/q_malloc.c:487]: qm_free(): WARNING: free(0) called from core: core/action.c: do_action(1132) Is it something you'd highly recommend against doing? Thanks. Cindy

2 1

High load average
by Володимир Іванець 26 May '20

26 May '20

Hello everyone! I'm running Kamailio version 5.3.3 on a CentOS 6. I started noticing that "load average" value increases rapidly with the start of Kamailio: # uptime 17:47:52 up 4 days, 17:47, 3 users, load average: 7.02, 7.01, 6.02 It will start to decrease immediately after Kamailio is stopped. Does anyone know what could cause this and how to troubleshoot it? Thank you!

4 11

RTPEngine call associations
by Alex Balashov 25 May '20

25 May '20

Hi, When using a single RTPEngine, or a single RTPEngine per set, it is possible to make stateless RTPEngine calls from Kamailio, since everything is keyed by Call-ID + tag. In other words, one can set up a call, answer it, restart Kamailio, and still send a 'delete' to RTPEngine successfully because there's no runtime state that needs to persist within Kamailio. How does this work with multiple RTPEngines in a set? There is clearly some runtime state being kept to map (Call-ID, tag) => <RTPEngine instance within a set>, otherwise successive stream management commands would be round-robined within the set just like initial 'offer' commands. I take it this association is lost across Kamailio restarts, since I see no mechanism to persist it. Does that mean that subsequent stream management commands (e.g. updated 'offer' / 'answer' on re-INVITE, 'delete' on BYE) are blasted out to all instances within a set prophylactically? Or is the recipient instance chosen at random as it would be with an initial 'offer' command? 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/

2 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 May 2020