sr-users June 2021

sr-users@lists.kamailio.org

48 participants
60 discussions

Kamailio SBC+ Freeswitch as media server

by John Tuxies

in a Debian system i am running Kamailio 5.5 installed from repo and with the basic setup i have 2 users 101 & 102 to be able to call each other. So far so good. i added Freeswitch in the same system and tried to follow this guide http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc even though it is old and there are many changes. Freeswitch is installed from deb repo as well. after following the guide i tried to adapt to newer versions of kamailio and freeswitch, but i am getting errors. The problem is that the users now are able to register to Kamailio, but unable to call each other. I can see users being registered in Kamailio: *root@kamfs: ~ $ kamctl online101102root@kamfs: ~ $* while when 101 calls 102 i am getting: *2021-06-08 10:35:19.015670 [NOTICE] switch_channel.c:1118 New Channel sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> [f3b8f5a0-652a-4640-b2d3-9b7cc21d7f91]2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:585 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) Running State Change CS_NEW (Cur 1 Tot 5)2021-06-08 10:35:19.015670 [INFO] sofia.c:10362 sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> receiving invite from 192.168.1.15:5060 <http://192.168.1.15:5060> version: 1.10.6 -release-18-1ff9d0a60e 64bit call-id: ZDFiZWFkZmVmYjgxZDEwOTgyYTYxZjkxNzkwMzlmYmQ.2021-06-08 10:35:19.015670 [DEBUG] sofia.c:10456 verifying acl "domains" for ip/port 192.168.1.15:0 <http://192.168.1.15:0>.2021-06-08 10:35:19.015670 [WARNING] sofia.c:10569 IP 192.168.1.15 Rejected by acl "domains"2021-06-08 10:35:19.015670 [NOTICE] sofia.c:2445 Hangup sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> [CS_NEW] [CALL_REJECTED]2021-06-08 10:35:19.015670 [DEBUG] sofia.c:1549 Channel is already hungup.2021-06-08 10:35:19.015670 [DEBUG] sofia.c:1549 Channel is already hungup.2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:604 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State NEW2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:585 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) Running State Change CS_HANGUP (Cur 1 Tot 5)2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:848 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) Callstate Change DOWN -> HANGUP2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:850 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State HANGUP2021-06-08 10:35:19.015670 [DEBUG] mod_sofia.c:453 Channel sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> hanging up, cause: CALL_REJECTED2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:60 sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> Standard HANGUP, cause: CALL_REJECTED2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:850 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State HANGUP going to sleep2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:620 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State Change CS_HANGUP -> CS_REPORTING2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:585 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) Running State Change CS_REPORTING (Cur 1 Tot 5)2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:936 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State REPORTING2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:174 sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> Standard REPORTING, cause: CALL_REJECTED2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:936 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State REPORTING going to sleep2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:611 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State Change CS_REPORTING -> CS_DESTROY2021-06-08 10:35:19.015670 [DEBUG] switch_core_session.c:1736 Session 5 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) Locked, Waiting on external entities2021-06-08 10:35:19.015670 [NOTICE] switch_core_session.c:1754 Session 5 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) Ended2021-06-08 10:35:19.015670 [NOTICE] switch_core_session.c:1758 Close Channel sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> [CS_DESTROY]2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:739 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) Running State Change CS_DESTROY (Cur 0 Tot 5)2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:749 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State DESTROY2021-06-08 10:35:19.015670 [DEBUG] mod_sofia.c:364 sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> SOFIA DESTROY2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:181 sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15> Standard DESTROY2021-06-08 10:35:19.015670 [DEBUG] switch_core_state_machine.c:749 (sofia/internal/101(a)192.168.1.15 <101(a)192.168.1.15>) State DESTROY going to sleepfreeswitch@kamfs>* i am attaching the kamailio.cfg file and the whole /etc/freeswitch folder, if someone could help me to solve this issue, please. Kind regards, John

3 years, 5 months

Any way to force socket used to reach databases ?

by David VILLAUME

Hello, I’m trying to initiate a redis connection in ndb_redis for topos_redis on a keepalived slave host, but host tries to use the VIP instead of the second socket I defined. Is there a way to influence the ‘database source socket’ so the server can connect with a secondary address even if it does not own the keepalived VIP (tried mhomed options without improvment) ? Regards, David

3 years, 5 months

List of Header Names

by Evan Verma

hello! new to working with sip/kamailio. I am currently trying to get a list of all of the header names on the invite the SBC receives. I am having trouble finding a way to do this. Does anyone know of a good solution?

3 years, 5 months

Problem NOTIFY in Presence module

by hamed r

hello dears ,i am using presence module and NOTIFY message are working properly. but when i put the database on another server , NOTIFY message will not be sent to subscribers. what is problem?

3 years, 5 months

List of Header Names

by Evan Verma

3 years, 5 months

STIR/SHAKEN

by David Villasmil

Hello guys, So I'm testing secsipid with made up certificates, basically: [image: Untitled.png] The verification _always_ comes back OK, event if I create the Identity with different From numbers, should that fail? Thanks all, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

3 years, 5 months

Info: ClueCon Weekly about Kamailio 5.5 series - Jun 4, 2021, 10:00am CT

by Daniel-Constantin Mierla

Hello, short announcement to let everyone know that next Friday, Jun 4, 2021, at 10:00am CT (17:00 Berlin), I will join ClueCon Weekly to discuss about latest Kamailio 5.5 series. If you have questions about or just want to be part of the discussions, consider to join the live video conference session, more details at: * https://www.cluecon.com/cclive-6-4/ Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online - June 7-10, 2021 (America Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/

3 years, 5 months

About Kamailio ass authentication service

by Nael Silega

hi, i have a question, can i use Kamailio as a authentication service? i´m traing to set up STIR/SHAKEN framework and im looking for a server that work as authentication service

3 years, 5 months

Questions on http_async_query() in event_route[xhttp:request] and async best practices for Kamailio

by James Aylett

Hi, I am using Kamailio v5.2 as a WebRTC proxy for SIP clients, as part of my setup I call a REST API before calling ws_handle_handshake() in event_route[xhttp:request] using http_client_query() to authenticate and retrieve some user details (routing etc) for the user connected via WebSockets. This worked fine until increased load on the system meant API responses were slow, this caused a knock-on effect to existing connected users. Specifically, we saw mass WebSocket disconnects for existing connected users - believed to be due to using too aggressive proxy timeout settings on our reverse proxy in front of Kamailio. My understanding is that event_route[xhttp:request] uses the shared SIP TCP worker threads, so potentially could slow API requests over the network block all the handlers? Could this potentially impact the keepalive processes used by the WebSocket module to check existing WebSocket connections? We were using ping keepalives, again with pretty aggressive timers... To resolve this issue, I am looking at whether I can call API requests asynchronously so that TCP workers are not blocked, my first thought was to use http_async_query() in event_route[xhttp:request] and call ws_handle_handshake() in the HTTP_REPLY route when the API call had completed, but I get "ERROR: websocket [ws_handshake.c:143]: ws_handle_handshake(): retrieving connection". I presume then this approach is a deadend, looking at newer kamailio versions 5.5, there doesn't seem to be any way to do this, correct? Instead of using http_async_query() in event_route[xhttp:request], I presume I could set a short timeout in http_client_query(), but my concern is new WebSocket connections could still impact and block existing ones in this case... My other thought was to move my API call out from the event_route[xhttp:request] into my route handler for REGISTER requests, thinking I could offload new register requests to async workers and move the API call there so as to not block existing connections. Does this seem like a reasonable approach to the problem? Given my current script does not use any async workers, how would one go about optimising the number of plain SIP TCP workers to async workers, are there any guides for this? In general, for any potentially blocking "APIs" or calls over the network, is it best practice to offload them into async workers. For example, we run RTPEngine on separate hosts to Kamailio so should I be wrapping rtpengine_offer/answer calls into async workers in case of a slow network? Apologies for the long text, but I would really appreciate any help to understand these problems. Thank you

3 years, 5 months

Need help analyze crash

by Andrew Chen

Hi all, Today I upgraded Kamailio to 5.4.5 and a random crash was just reported in our crash monitoring script. Below is the output of the crash: #3 0x00007fa149ebe58d in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/tls.so #4 0x00007fa14989e277 in ERR_clear_error () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #5 0x00007fa149933d81 in X509_STORE_set_default_paths () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #6 0x00007fa10310d374 in ?? () from /usr/lib/x86_64-linux-gnu/libmysqlclient.so.20 #7 0x00007fa10310d9f3 in ?? () from /usr/lib/x86_64-linux-gnu/libmysqlclient.so.20 #8 0x00007fa1030e0427 in mysql_real_connect () from /usr/lib/x86_64-linux-gnu/libmysqlclient.so.20 #9 0x00007fa10368428c in db_mysql_new_connection () from /usr/lib/x86_64-linux-gnu/kamailio/modules/db_mysql.so #10 0x00007fa1501f96dc in db_do_init2 () from /usr/lib/x86_64-linux-gnu/kamailio/libsrdb1.so.1 #11 0x00007fa1501f83f9 in db_do_init () from /usr/lib/x86_64-linux-gnu/kamailio/libsrdb1.so.1 #12 0x00007fa103689710 in db_mysql_init () from /usr/lib/x86_64-linux-gnu/kamailio/modules/db_mysql.so #13 0x00007fa15062d35f in carrierroute_db_open () from /usr/lib/x86_64-linux-gnu/kamailio/modules/carrierroute.so #14 0x00007fa1506719c6 in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/carrierroute.so Is this crash due to libcrypto or mysql client? Currently I have the following mysql client installed on the kamailio instance: ii lib*mysql*client20:amd64 5.7.34-0ubuntu0.18.04.1 amd64 MySQL database client library ii *mysql*-client 5.7.34-0ubuntu0.18.04.1 all MySQL database client (metapackage depending on the latest version) ii *mysql*-client-5.7 5.7.34-0ubuntu0.18.04.1 amd64 MySQL database client binaries ii *mysql*-client-core-5.7 5.7.34-0ubuntu0.18.04.1 amd64 MySQL database core client binaries ii *mysql*-common 5.8+1.0.4 all MySQL database common files, e.g. /etc/*mysql*/my.cnf root@ashintgtpsg51:/var/lib/cores # apt-cache madison mysql-client mysql-client | 5.7.34-0ubuntu0.18.04.1 | http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages mysql-client | 5.7.34-0ubuntu0.18.04.1 | http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages mysql-client | 5.7.21-1ubuntu1 | http://us-east-1.ec2.archive.ubuntu.com/ubuntu bionic/main amd64 Packages root@ashintgtpsg51:/var/lib/cores # Any suggestions would be greatly appreciated. Thanks in advance. -- Andy Chen Sr. Telephony Lead Engineer achen@ <achen(a)thinkingphones.com>fuze.com -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

3 years, 5 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 June 2021