sr-users September 2019

sr-users@lists.kamailio.org

57 participants
79 discussions

TLS in-dialog set_forward_no_connect()and upstream TLS LCR gateway
by Anthony Joseph Messina 21 Sep '19

21 Sep '19

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

2 6

Info: initialization of libssl 1.1.+ with PTHREAD_PROCESS_SHARED attribute for pthread mutex and rwlock
by Daniel-Constantin Mierla 21 Sep '19

21 Sep '19

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

6 21

Possible locking issue in usrloc module in file udomain.c
by Rupesh Kumar 18 Sep '19

18 Sep '19

Hi , Currently I am running kamailio 4.2 and now upgrading to kamailio 5.2 and was just going thru the changes. In the file modules/usrloc/udomain.c inside the function free_udomain( ) , it appears that we are not protecting via lock_ulslot and unlock_ulslot doing free. Could it cause some race condition ? May be its intentional but going thru the github history its there since day 1. I checked all branches in kamailio 4.x and we have the protection. In 4.x void free_udomain(udomain_t* _d) { int i; if (_d->table) { for(i = 0; i < _d->size; i++) { lock_ulslot(_d, i); deinit_slot(_d->table + i); unlock_ulslot(_d, i); } shm_free(_d->table); } shm_free(_d); } In 5.x void free_udomain(udomain_t* _d) { int i; if (_d->table) { for(i = 0; i < _d->size; i++) { deinit_slot(_d->table + i); } shm_free(_d->table); } shm_free(_d); }

2 2

How to distinguish is from Asterisk or from the client
by przeqpiciel 18 Sep '19

18 Sep '19

Hi, I looking information how to distinguish whether the packet is directed to the Astersik (my platform) or to the customer (softphone / sip client ).

5 5

NAT problem
by Arnout Van Den Kieboom 18 Sep '19

18 Sep '19

Hi, First of all, I'm really new to Kamailio. So sorry if I ask a stupid question, or perhaps a really weird one. I started using kamailio in a test environment about a week ago. for setup i have the situation for inbound calls: Carrier --> FW (NAT) --> Kamailio for outbound to an asterisk box i have: Kamailio --> FW (NAT) --> Asterisk for outbound to users i have: Kamailio --> FW (NAT) --> sip-phone (yealink) or grandstream During that time i was able to : Set up calls to users, Use the dispatcher module use the avpops module to do data lookups. Get calls from asterisk to kamailio user to work. Also calls between users (even though behind nat) are having good audio. I have installed rtpproxy and it works nicely. There is just one situation where it fails: Carrier --> FW (NAT) Kamailio --> asterisk There is only one way audio (from asterisk to carrier) but not from carrier to asterisk. I believe I need to do something with the rtp proxy module ... and tried different things (forcing the r flag, forcing the w flag) Any idea where I might need to start looking? It's been driving me crazy... Thanks Pemp

4 7

app_lua: invalid Lua environment attributes or parameters
by Yuriy Gorlichenko 18 Sep '19

18 Sep '19

Hi! Im using kamailio 5.1.8 with app_lua and getting this message during startup of kamailio. Looks like I forgot to add something at the module setup, but cant figure out what is wrong. My setup of app_lua is: modparam("app_lua", "load", "/etc/kamailio/extended/main.lua") modparam("app_lua","reload",1) modparam("app_lua","register","textops") app_lua [app_lua_sr.c:1599]: sr_kemi_lua_exec_func_ex(): invalid Lua environment attributes or parameters starting kamailio service with kamailio -f /etc/kamailio/extended/main.lua Also here is little bit confusing me that in case of use "KSR" everywhere I'm getting message about "sr"... Thx in advice

2 5

dedicated bearer - Kamailio settings
by Jack R 18 Sep '19

18 Sep '19

Hi, We have installed Kamailio as IMS setup pcscf icscf scscf - 3 instances running on Ubuntu. I have done the attached (image) settings to create dedicated bearer in nextepc as advised by this link: https://github.com/open5gs/nextepc/issues/180 Do I need to do some setting in Kamailio server side (maybe in pcscf cfg files etc.to take some information from PCRF) to make dedicated bearer work end to end or that is all (just configure the new apn in the phone) rest will be taken care itself? Thanks and Regards, Jack.

2 1

core dump if silo table > ~5000 records
by David Villasmil 18 Sep '19

18 Sep '19

Hello guys, i've got a kamailo: version: kamailio 5.0.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 19:50:58 Mar 28 2017 with gcc 4.9.2 which was core dumping every 20 seconds and we had no idea why. We emptied out the silo table, which had: mysql> select count(*) from silobackup; +----------+ | count(*) | +----------+ | 5240 | +----------+ records. Once we truncated it, kamailio started working again. Is there a limit to how many records msilo can handle? I will look into the data in the table, but in case there's a limit, i'd like to know. core available on request. Thanks Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

3 3

Kamailio+B2BUA on IPv4-only and NAT64 Apple app store tests
by Anthony Alba 17 Sep '19

17 Sep '19

Hi folks, I'm wondering what you do to pass Apple app store tests (IPv6-only NAT64/DNS64 scenario) with the iOS app likely to put IPv6 addresses in the SDP, when Kamailio and your B2BUA(Asterisk, FreeSWITCH,...) are IPv4-only endpoints. By "pass" I mean media flowing + SIP working - not sure the app store gatekeepers would actually test media, but it would be nice to have a robust solution. Strictly speaking, this is not a Kamailio's problem but a media SDP/<your-rtp-proxy-of-choice> problem. But since everything is so closely intertwined I'm wondering where you choose to the location the "solution". I have noticed that if Kamailio is IPv4-only and it "sees" IPv6-addresses(Contact, Via headers??) it will try to resolve the IPv6-address as a DNS name! The Wikipedia article on NAT64 mentions 464XLAT(RFC 6877) and Port Control Protocol (RFC 7225), but those seem to be deep rabbit-holes... Cheers Anthony Alba

4 5

Kamailio merchandising shop
by Henning Westerholt 16 Sep '19

16 Sep '19

Hello, there is now a Kamailio merchandising shop available: https://skalatan.de/merchandising/ You find there many options e.g. different Kamailio T-Shirts, Hoodies, Bags, Caps, Mugs, etc.. It provides shipping in many countries world-wide (based from Europe and also USA). Feedback via (direct) e-mail welcome. Best regards, Henning

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users September 2019