sr-users

sr-users@lists.kamailio.org

18 participants
37398 discussions

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

multi-IP Kamailio
by christian (cx labs) 25 May '20

25 May '20

Hi, you guys helped out so quickly with my last question, so here's me again, with another issue. I need Kamailio to be a sip proxy between two other SIP servers. All trunks are static IP only, no Auth. The specialty is that the Kamailio proxy needs to manipulate different fields in the SIP flow, depending on which public IP is used. So, for example: Provider A, IP 1 -----> Kamailio,* IP A* "change From Header" -----> Provider B, IP 2 Provider A, IP 1 -----> Kamailio, *IP B* "change Request URI" -----> Provider B, IP 2 So Kamailio needs to behave differently, depending on which IP receives (and also forwards!) the call. What do you think? Cheers, Chris.

3 2

488 Not Acceptable Here when remove codecs with rtcp-fb
by José Lopes 25 May '20

25 May '20

Hello, I am using KSR.sdpops.keep_codecs_by_name to remove some codecs. When I make a call between two webrtc clients and I keep only VP8 video codec, the browser rejects the call with 488 Not Acceptable Here. I notice the attributes a=rtcp-fb: of codecs removed are kept. I removed that attributes with: KSR.textops.replace_body_atonce("a=rtcp-fb:1.*\n", ""); KSR.textops.replace_body_atonce("a=rtcp-fb:98.*\n", ""); And the call worked. There is another way to remove these attributes related to codec name? Or is it possible to get the ids of the codecs with dynamic payload type numbers from SDP? Thanks for your attention. Best regards, Jose Lopes

5 10

IPV6 header in IPV4 : ACK for 200 OK never received
by Abdoul Osséni 25 May '20

25 May '20

Hello, I encounter unexpected behavior. The call flow is: UAC --> Kamailio + Rtpengine (full ipv4) --> Asterisk (full IPV4). I configured the uac to use IPV4 but the SIP INVITES include IPV6 in headers and sdp messages. I think this is a bug on the UAC side. Example: 1. UAC INVITE *INVITE* sip:xxx@sip.xxx.com SIP/2.0 Via: SIP/2.0/TLS [2a04:cec0:101a:ebe2:9949:d81c:23a6:ae10]:42580;branch=*z9hG4bK.I8U1RQDbW* ;rport ..... ..... v=0 o=59130c8f7268a_2 2922 1557 IN IP6 2a04:cec0:101a:ebe2:9949:d81c:23a6:ae10 s=Talk c=IN IP6 2a04:cec0:101a:ebe2:9949:d81c:23a6:ae10 2. We sent 200 OK response like : Via: SIP/2.0/TLS [2a04:cec0:101a:ebe2:9949:d81c:23a6:ae10]:42580;received=80.214.78.1;branch= *z9hG4bK.I8U1RQDbW*;rport=1364 v=0 o=x 887503534 887503534 IN IP4 51.159.2.164 s=x c=IN IP4 51.159.2.164 3. We never receive the ACK message. Is there a Kamailio or Rtpengine solution to solve the problem? Any help will be very appreciate. Abdoul OSSENI https://www.africallshop.com/

2 1

Teams 404
by sip user 25 May '20

25 May '20

Hi, when I try to call Kamailio -> Teams.. this one always respònd to me with a 404 Q.850 cause=1 (Unallocated number). Could be this problem from Teams? Has anyone ever encountered this problem? Thanks

1 0

Jump to page:

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