sr-users September 2019

sr-users@lists.kamailio.org

57 participants
77 discussions

Problem restoring To and From (uac_replace)

by Duarte Rocha

Greetings, I'm getting some errors with the auto restore of From and To from UAC Module. After the restore, the URI has lots garbage and it's not like the original. I think the problem lies on the way the client sends the Route Header to me, but i'm not sure. When Kamailio sends the INVITE Record-Route are like this : Record-Route: <sip:xxx.xxx.xxx.xxx;................> Record-Route: <sip:aaa.bbb.aaa.bbb;................> However, when my client sends a BYE to finish the call, the Route are on this mode : Route: <sip:aaa.bbb.aaa.bbb;................>,<sip:xxx.xxx.xxx.xxx;................> The module's documentation says this : "One uses the rr module and appends to the Record-Route header a parameter containing some strings from which the original and new URI can be computed. The problem with this mode is that it relies on the fact the parties will send the Route exactly as it was received. In case there is a change, the resulting URIs will not be correct." Can this change by the client be the cause of this issue? Is there anything i can do to avoid this? Best Regards, Duarte Rocha

4 years, 7 months

Can I load balance Kamailio with Kamailio?

by Ne Mo

4 years, 7 months

Parsing json file on kamailio.cfg file

by Melek Oktay

Hi, I am trying to monitor *uac *channels status periodically in kamailio config file. I call uac.reg_dump rpc command and result will be inside in $var(uac_channel) variable jsonrpc_exec('{"jsonrpc": "2.0", "method": "uac.reg_dump"}'); $var(uac_channel) = $jsonrpl(body); it returns me json formatted result like below, it has a several channels info and their status *flags* {"jsonrpc":"2.0", "result":[ {"l_uuid":"YY","l_username":"YY","l_domain":"YY","r_username":"YY","., " *flags*":16 }, {"l_uuid":"XX","l_username":"XX","l_domain":"XX","r_username":"XX",,... " *flags*":1 }}]} I could not parse this result on kamailio.cfg file ! I want to learn channel that has a 16 value in flag attribute for example !! Would you help me to figure out how I am gonna parse this json file please ?

4 years, 7 months

qm_find_free() Free fragment not found, called from xcap_server, no more pkg

by Cody Herzog

Hello. Recently, for the first time, we experienced an apparent memory issue in our production environment. Here's an example of the relevant log messages: Sep 13 18:55:22 SIPCOMM /usr/local/sbin/kamailio[2302]: ERROR: <core> [core/mem/q_malloc.c:286]: qm_find_free(): qm_find_free(0x7fd8bbcfc010, 134648); Free fragment not found! Sep 13 18:55:22 SIPCOMM /usr/local/sbin/kamailio[2302]: ERROR: <core> [core/mem/q_malloc.c:419]: qm_malloc(): qm_malloc(0x7fd8bbcfc010, 134648) called from xcap_server: xcap_server.c: ki_xcaps_put(549), module: xcap_server; Free fragment not found! Sep 13 18:55:22 SIPCOMM /usr/local/sbin/kamailio[2302]: ERROR: xcap_server [xcap_server.c:552]: ki_xcaps_put(): no more pkg Sep 13 18:55:22 SIPCOMM /usr/local/sbin/kamailio[2252]: ERROR: app_perl [kamailioxs.xs:487]: XS_Kamailio_log(): 500 Server error The failed operation was the XCAP server module trying to generate a very large RLS contact list for a user. The issue only impacted users with very large lists, as though a large contiguous block of memory could not be found, whereas other smaller allocations continued to work fine. We believe the requested allocation was around 112 KB in size. The server had been up for 14 days. We were able to work around the issue temporarily by just restarting the Kamailio service. It's unusual, because our production server is often up for months, and we've never seen this issue before. The load on production is increasing slowly due to an increased concurrent user count, so that might be related. Before restarting the service on production, we captured the output of the following commands: kamctl stats shmem kamcmd mod.stats all shm kamcmd pkg.stats kamcmd mod.stats all pkg Here's the shared mem output: { "jsonrpc": "2.0", "result": [ "shmem:fragments = 27240", "shmem:free_size = 447203296", "shmem:max_used_size = 116175576", "shmem:real_used_size = 89667616", "shmem:total_size = 536870912", "shmem:used_size = 68824240" ], "id": 6934 } Here's the pkg output for the particular PID which was throwing the errors: { entry: 34 pid: 2302 rank: 14 used: 2415864 free: 4949688 real_used: 3438920 total_size: 8388608 total_frags: 1951 } We didn't see anything obvious in the stats output which explains the issue. We've been trying to reproduce the issue in a dev environment using simulated higher than production load running for many days, but so far we've had no luck. We've been monitoring memory stats over time, but we don't see any obvious leaks or issues. We've searched various past threads, but didn't find any obvious answers. Here are some of the documents and the threads we've been reading: https://www.kamailio.org/wiki/tutorials/troubleshooting/memory https://www.kamailio.org/wiki/cookbooks/3.3.x/core#mem_join https://sr-users.sip-router.narkive.com/3TEDs3ga/tcp-free-fragment-not-found https://lists.kamailio.org/pipermail/sr-users/2012-June/073552.html https://lists.kamailio.org/pipermail/sr-users/2017-February/096132.html https://lists.kamailio.org/pipermail/sr-users/2017-September/098607.html https://github.com/kamailio/kamailio/issues/1001 https://lists.kamailio.org/pipermail/sr-users/2016-April/092592.html https://lists.kamailio.org/pipermail/sr-users/2010-July/064832.html Regarding our Kamailio version and build options, here's the output of 'kamailio -v': ---- version: kamailio 5.1.0 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 20:07:31 Jan 4 2018 with gcc 5.4.0 ---- We are running on a 64-bit Ubuntu Server virtual machine. Any help would be greatly appreciated. Thanks very much.

4 years, 7 months

Using static entries with usrloc

by George Diamantopoulos

Hello, Normally I wouldn't be asking this but I was surprised to find no reference to anyone doing this online. I need to have a few AoRs with static entries in kami's location table, which will always be reachable at their contacts without ever having to register with Kamailio. Am I right in thinking that merely INSERTing respective rows in kamailio's location DB backend will do the trick? Is there anything I need to worry about, like contacts being periodically purged? If yes, how do I prevent that from happening? And will kamailio always query the DB when performing location lookup or do I need to restart upon inserting new records (to purge caches, for example)? Lastly, I'm not sure how to treat some fields present in usrloc tables like ruid, expires (can I set this to NULL?), callid and cseq (which is irrelevant since there's no REGISTER), flags, cflags and methods. Thanks, George

4 years, 7 months

xtrange error but those rules that already work, some bug?

by PICCORO McKAY Lenz

i have many xtrange errors in the log.. but the code seems as i guess completed each rule without error. In the kamailio i have that error by example: Sep 23 13:38:29 ser-server-02 kamailio[2847]: 4(2855) ERROR: *** cfgtrace:request_route=[REGISTRAR] c=[/etc/kamailio/kamailio-devel.cfg] l=692 a=25 n=save that line represents a supposed error in the following code, BUT that code seem work.. kamailio it’s working perfectly.. so i’m worry about it, what it happened? # Handle SIP registrations route[REGISTRAR] { if (!is_method("REGISTER")) return; if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); #!ifdef WITH_NATSIPPING # uncomment next line to do SIP NAT pinging setbflag(FLB_NATSIPPING); #!endif } if (!save("location")) sl_reply_error(); #!ifdef WITH_ASTERISK route(REGFWD); #!endif exit; } why that happened? Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com

4 years, 7 months

kamailio run in docker not working

by Gaurav Bmotra

hi i m trying to run kamailio in docker this kamailio/kamailio-ci:master-alpine but inside the container kamailio not running if i rung this / # /etc/init.d/kamailio status sh: /etc/init.d/kamailio: not found plz help me thanks -- *Regards:* Gaurav Kumar

4 years, 7 months

rate-limiting enabled on kamailio.org

by Henning Westerholt

Hello, just to inform you that rate-limiting on kamailio.org web server has been enabled. The motivation is to throttle robots and other automated services to not overload the server. If you notice any new errors in accessing the service (like page not found, or a 429 Too Many Requests) let us know. Cheers, Henning -- Kamailio Merchandising - https://skalatan.de/merchandising/ Kamailio services - https://skalatan.de/services Henning Westerholt - https://skalatan.de/blog/

4 years, 7 months

TLS in-dialog set_forward_no_connect()and upstream TLS LCR gateway

by Anthony Joseph Messina

In preparation for the 5.3 release, I've been testing the following configuration change for TCP/TLS connections: https://github.com/kamailio/kamailio/commit/ 8bba208fe6ae7ccb4c92362b8c33f1530b9f56da route[REQINIT] { # no connect for sending replies set_reply_no_connect(); if(has_totag()) { # no connect for requests within dialog set_forward_no_connect(); } This change creates issues when a UAC TLS INVITE routes to an upstream gateway using TLS to port 5061 (via the LCR module). Kamailio sends the initial outbound TLS connection from a local ephemeral port. The TCPOPS tcp_keepalive_enable function issues keepalives from the local ephemeral port to the gateway port 5061: https://kamailio.org/docs/modules/stable/modules/ tcpops#tcpops.f.tcp_keepalive_enable Even so, the TLS connection eventually times out, after which in-dialog requests from the UAC are no longer able to reach the upstream gateway. ERROR: tm [../../core/forward.h:293]: msg_send_buffer(): tcp_send failed WARNING: tm [t_fwd.c:1570]: t_send_branch(): sending request on branch 0 failed ERROR: sl [sl_funcs.c:372]: sl_reply_error(): stateless error reply used: Unfortunately error on sending to next hop occurred (477/SL) I figure I must be doing something wrong with my TCPOPS here. Is a TLS connection to an upstream gateway supposed to be maintained throughout the duration of a call? -- Anthony - https://messinet.com F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6

4 years, 7 months

Info: initialization of libssl 1.1.+ with PTHREAD_PROCESS_SHARED attribute for pthread mutex and rwlock

by Daniel-Constantin Mierla

Hello, after couple of months waiting for feedback about the workaround with the preloaded shared library to set the PTHREAD_PROCESS_SHARED attribute for pthread mutex/rwlock in order to avoid deadlocks and as it seems to be the solution, I just pushed a few commits to move that code in the core of kamailio. It this way the initialization with the PTHREAD_PROCESS_SHARED attribute is done by default when libssl v1.1 is detected at compile time, without the need of using the approach with a preloaded library. The shared library is still kept in the tls module: * https://github.com/kamailio/kamailio/tree/master/src/modules/tls/utils/open… Probably is going to be removed in the near future. I am asking the community members that use Kamailio on systems with libssl v1.1+ to test the master branch and give feedback. The master branch is anyhow in testing phase for preparing the next major release v5.3.0, so it will help for that as well. If no issue is going to be reported soon, the commits will be backported to stable branches, to re-enable smooth use of Kamailio with libssl v1.1+. When libssl v1.1+ is detected, the core links with pthread, but that was already present in the Makefiles.defs for different compile options. The pthread more or less a default library on linuxes/unixes, so this should not introduce any major dependency to the Kamailio core. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

4 years, 7 months

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 September 2019