sr-users February 2024

sr-users@lists.kamailio.org

49 participants
40 discussions

by Arsen Semenov

Hello! I have an issue with kamailio 5.6.5 after some time of flying there are errors in logs: <core> [core/mem/q_malloc.c:297]: qm_find_free(): > qm_find_free(0x7fc79c286010, 536); Free fragment not found! mem_join=1 by default, but it seems that MEM_JOIN_FREE flag is not defined in this build kamailio -I > Print out of kamailio internals > Version: kamailio 5.6.5 (x86_64/linux) > Default config: /etc/kamailio/kamailio.cfg > Default paths to modules: /usr/lib/x86_64-linux-gnu/kamailio/modules > 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, TLS_PTHREAD_MUTEX_SHARED > 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: unknown > Compiled with: gcc 10.2.1 > Compiled architecture: x86_64 > Compiled on: > OS Debian 11 bullseye However I noticed the flag exists in 5.7 installed from deb Print out of kamailio internals > Version: kamailio 5.7.4 (x86_64/linux) > Default config: /etc/kamailio/kamailio.cfg > Default paths to modules: /usr/lib/x86_64-linux-gnu/kamailio/modules > Compile flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, > DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, > *MEM_JOIN_FREE*, 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 > 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: unknown > Compiled with: gcc 10.2.1 > Compiled architecture: x86_64 > Compiled on: OS Debian 11 bullseye and now, what got me bit confused is that when I build 5.6.5 from source "make printcdefs" gives me this flag, alongside with other flags which I do not see later in "kamailio -v" output. So I am not sure whether this flag was defined during 5.6.5 deb build time or it has been somehow lost? So I need your advice. Regards, Arsen

6 months, 4 weeks

How to query, if callid is handled by rtpengine module already?

by Benoît Panizzon

Hi I have come across this challenge: Initial invite (no to_tag) has is authenticated and has credentials. So a lookup for the username is made to determine if the customer needs backhauling, thus rtpengine needs to be engaged. On a subsequent invite (re-invite to change codec or to refresh session timer) there is a to_tag so it is being routed without sending a challenge and has no auth username. I don't use dialog on the registrar. This is another transaction. So I don't know, if I need to engage rtpengine on that DSP or not. What is the best way to find out, if rtpengine is already handling that callid? if(rtpengine_query_v("j", "$var(dummy)")) { rtpengine_manage(); } basically works, but generates a couple of ugly error messages in the log as rtpengine_query_v does not find the call. Is there a nicer way? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

6 months, 4 weeks

TCP timeout occurs when the uac_req_send sets $ouri = Received (sip:10.11.40.XX:57646;transport=tls) but The Received connection normal

by riffs＠sina.cn

The connection registered by the client is normal, and the client can send messages and renew the registration normally, but the push message to the client using uac_req_send() from kamailio fails. Location information after the client is registered: ]#kamcmd ul.lookup location test01 Received: sip:10.11.40.XX:57646;transport=tls ]#netstat -anp | grep 57646 "tcp 0 0 10.11.55.xx:5061 10.11.40.XX:57646 ESTABLISHED 3467/kamailio" kamailio.lua KSR.pv.sets("$uac_req(ouri)", rows.received) In this way, most users can receive messages normally, but occasionally some users cannot receive messages but can renew their registration and send messages normally. Once this is the case for this user, the use of uac_req_send() will continue to fail until the client establishes a new connection. If a problem occurs, the following logs are displayed on the server: 2024-02-20T10:01:25.329595+08:00 10.11.55.XX (72819) ERROR: <core> [core/tcp_main.c:4692]: tcpconn_main_timeout(): connect 10.11.40.XX:57646 failed (timeout) The connection already exists and should be normal, why does "tcpconn_main_timeout(): connect 10.11.40.XX:57646 failed (timeout)" occur.

7 months

Dispatcher ping: "binding to source address X.X.X.X:XXXX failed: Address already in use" for TCP and TLS destinations

by Jardar Leira

We have recently upgraded from 5.6.4 to 5.7.4. No change in the KAMAILIO configuration. On all upgraded servers we are now getting this message in the logs for every destination when the dispatcher sends out OPTIONS to destinations listed in the dispatcher list: WARNING: <core> [core/tcp_main.c:1301]: find_listening_sock_info(): binding to source address X.X.X.X:YYYY failed: Address already in use [98] The X.X.X.X being the servers IP address and YYYY being the servers listening port for tcp and/or tls. It's not consistent. For some servers it's every time OPTIONS is sent. For others it's just now and then. udp destinations have no issues. There are no other processes occupying these ports. Changing the listening port on the KAMAILIO also results in the new port reported as in use. Dispatcher OPTIONS still seems to work for both tcp and tls. Unsurprisingly using a dynamic, unprivileged port > 1023 and not the server port as the source port, as it shouldn't. The packages are sendt and a reply is registered. Inbound OPTIONS are processed as expected by KAMAILIO on the listening port. Have I missed something transitioning from 5.6 -> 5.7, or is this a bug? Relevant config: modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_probing_threshold", 2) modparam("dispatcher", "ds_ping_interval", 120) modparam("dispatcher", "ds_ping_from", "sip:ping@xxxxxx.xxx") modparam("dispatcher", "ds_ping_latency_stats", 1) OS: Debian Bullseye Kamailio installed from https://deb.kamailio.org/kamailio57 bullseye Best regards, Jardar Leira

7 months

Forward subscriber username via dispatcher

by s.czech＠nowatel.com

Hi, I'm trying to forward the original username of the peer via Kamailio dispatcher to the Asterisk and I can't get it working. The scenario looks like this: Client Phone (username 1) -> Asterisk Client ---trunk(test-trunk)--> Kamailio Dispatcher/RTPEngine --trunk--> Asterisk Final Client is dialing via Asterisk Client with a simple extension: exten => _X.,1,Set(CALLERID(all)= 587555611 <587555611>) exten => _X.,n,Dial(SIP/${EXTEN}@test-trunk) Asterisk Client is registering to the Kamailio with its own credentials and Kamailio is registering in the Asterisk Final The problem is that I can't find a way to extract the original trunk username (like test-trunk) in the outgoing connection to the Asterisk Final (via Kamailio): Since i'm using the CALLERID on the Asterisk Client all I can see on the Asterisk Final is: INVITE sip:587322591@192.168.20.74 SIP/2.0 Record-Route: <sip:587322591@192.168.20.74;lr;ftag=as52b874a1;nat=yes> Via: SIP/2.0/UDP 192.168.20.74;branch=z9hG4bKc6e3.a77db1f002191ae3ee1a414b63d34a72.0 Via: SIP/2.0/UDP 192.168.21.228:5060;received=192.168.21.228;branch=z9hG4bK705ec94a;rport=5060 Max-Forwards: 69 From: "587555611" <sip:587555611@192.168.21.228>;tag=as52b874a1 To: <sip:587322591@192.168.20.74> Contact: <sip:587555611@192.168.21.228:5060;alias=192.168.21.228~5060~1> Call-ID: 433f9ff84cdb437f0d383797003c232f@192.168.21.228:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 16.29.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer P-Asserted-Identity: "587555611" <sip:587555611@192.168.21.228> Content-Type: application/sdp Content-Length: 268 There is no way I can forward the 'test-trunk' in the SIP header. I tried to add append_hf to ROUTE[relay] like append_hf("X-Trunk $au r\n"); but if the trunk is already registered then $au is null or the CALLERID value. How to extract the original username (test-trunk) on the Asterisk Final? Do you have any ideas? Thank you in advance ;)

7 months

Latest point releases seem to break early dialog UPDATEs from B-side when using topos (again)

by George Diamantopoulos

Hello all, I've noticed that there seems to be a regression with the topos module, more specifically the redis flavour, but I'm assuming the storage backend shouldn't make a difference. I have confirmed this affects both 5.6.5 and 5.7-nightly, so I'm assuming some backported commit is to blame. Kamailio 5.6.4 used previously, to the best of my memory, was not affected. Early dialog UPDATEs sent from the callee seem to be somehow malformed, since the 200 OK the UAS produces goes directly to the UAC despite having executed record_route() for the original INVITE. I can't imagine how this is possible, I thought responses always honour the Via header and record route shouldn't play a role in this case, right? Simply turning topos off restores the intended behaviour, however, so I can't help but think this is somehow related. Here's two call flows demonstrating the behaviour: * Topos on, 200 OK to UPDATE missing: https://pastebin.com/raw/J0zQeM5g * Topos off, 200 OK to UPDATE routed correctly: https://pastebin.com/raw/49yErezb I was wondering if anyone is aware of any commits that might be responsible for this. Additionally, is there an archive of debian packages with previous point releases so that I can confirm this regression with the latest versions? Thank you! Best regards, George

7 months

Reject TCP SYN

by David Villasmil

Hello all, Is there any way of actually rejecting (RST) NEW tcp connection attempts, while allowing the ongoing ones to finish naturally? I’m thinking maybe we can add this feature? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

7 months

uacreg - memory vs database

by Aymeric Moizard

Hi! I would like to add/remove/update entries in uacreg database. The easiest way I found is to add data using mysql and then call kamcmd uac.reg_reload. I end up reloading too often: uac_reg_ht_shift(): shifting in-memory table is not possible in less than 150 secs I would like to optimize it and I tried to use sudo kamcmd uac.reg_add Unfortunately, the data is not persistent and seems to be only in memory. Does it means my only choice is to follow this procedure: Add a user: 1/ sudo kamcmd uac.reg_add 2/ add the equivalent mysql entry Remove a user 1/ sudo kamcmd uac.reg_remove 2/ remove the equivalent mysql entry Let me know if an alternative exists! Regards Aymeric -- Antisip - http://www.antisip.com

7 months

Kamailio as a Presence server only

by djcsalvador＠gmail.com

I all, I'm looking into Kamailio as a solution to replace our current Presence Server in our IMS Network, but feeling a bit overwhelmed by the feature size and complexity of Kamailio. I have a few questions (some might be dumb), if you guys could help me I would appreciate. 1. As I only need Kamailio as a Presence Server (with XCAP and SIP Interface), is there a way to install only the necessary components and/or modules? Our security team would probably raise some questions if we need to install unused code on the network. For what I could investigate, the modules i would need are: * Presence * Presence_XML * Xcap_server * xhttp * RLS * Pua * database * sl * tm Am I missing something? 2- As refered on point 1, our server will need a xcap and sip interface. Some presence updates will come through XCAP, others from SIP Publish. My question is, whenever a presence update is made through XCAP interface, will the kamailio server trigger the necessary SIP Notify to notify all Subscribed users ? I ask this because this was a problem with our current supplier. 3 - our client is a bit "peeky" with performance. I found here (https://www.kamailio.org/wikidocs/kemi/performance-tests/5.2.x/#results) some performance tests, but for what i can see the test primary goal was to test the response time. Is there any resource on "requests per second"? Thanks in advance for all the help David Salvador

7 months

Kamailio - handover between LTE and Wifi

by Christian Hahn

Hi all, While researching for Open Source IMS Services I’v found the presentation “What’s up with IMS & VoLTE?” at KamailioWorld 2018. There is a quote that raises a question: “Things, you shouldn’t expect (at least initially): ● Seamless handover between LTE and Wifi, as this requires some integration with the PGW of the LTE” My question is: Has the VoLTE <-> VoWiFi Handover been implemented in the meantime? BR Christian

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 February 2024