sr-users September 2024

sr-users@lists.kamailio.org

37 participants
51 discussions

Kamailio not listening to SIP despite setup OK
by Sergio Charrua 21 Sep '24

21 Sep '24

Hi all! got a client with 2 Kamailio servers using Pacemaker/Corosync with a VIP. Kamailio is setup with dispatcher, and has been working since 2018. This previous week, client migrated from a Cisco ASA firewall to a Fortinet F5 firewall. One of the Kamailio server is, apparently, working fine, receiving SIP invites and processing them correctly. When moving the VIP to the second Kamailio node, Kamailio is ignoring any SIP message that is not OPTIONS, despite configuration (kamailio.cfg) being exactly the same as in the node #1. Also, note that using SNGrep, we can see clearly that SIP messages are reaching the server, but Kamailio is just not processing any INVITE. In fact, I added an output to log file right at the very beginning of the main route and the line is added to log file ONLY if the SIP message is OPTIONS. When the SIP message is INVITE, nothing is processed on Kamailio's side. The listen parameter is set to 0.0.0.0 port 5060 and advertised IP set to the Public IP. Again, the main route is only : route{ xlog(. ......); } Kamailio version is 5.1.6 (old, I know....) but it has been working since Dec 2018! What could be the issue?! Why only OPTIONS are being , somehow, recognized by Kamailio and all other SIP messages just ignored? Also, to add some more weirdness to the mess, connecting an Asterisk server on the same network, and sending a call to Kamailio node #2, it works!! SIP messages of any kind are processed correctly by Kamailio on node #2. So, why doesn't it work with SIP messages received via Public IP address, even though the messages reach the server correctly (confirmed using SNGrep) ??? I spent 5h this afternoon trying to understand what is wrong, but I'm stuck .... and no clue so far, apart from suspecting of the new Gateway, which I have no access to configurations.... but if OPTIONS are received & processed OK, it wouldn't make sense that received INVITES would be ignored by Kamailio, right? Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

6 7

Handling SIP Contact Header Changes and ACK Routing Issues
by XPTO 21 Sep '24

21 Sep '24

Hello community! I would like to ask for your help in solving a case. I thank you in advance for any collaboration. I have the following setup: - *Asterisk (internal)* → *Kamailio (Proxy)* → *SIP Provider (PSTN)* Both Asterisk and Kamailio are under my responsibility. *Problem:* When I initiate a call from Asterisk, I use Kamailio as the *outbound proxy*. The *INVITE* is sent to the SIP provider, and the dialogue proceeds normally until the provider responds with a *200 OK*, indicating the call was answered. However, the *200 OK* received from the provider contains a modification in the *Contact* header, introducing a new IP address into the dialogue. Presumably, this new IP is where the subsequent *ACK* should be sent. The issue arises when Kamailio receives this *200 OK*: it overwrites the *Contact* field, replacing the received IP with its own LAN IP, used for communication with Asterisk. As a result, Asterisk sends the *ACK* back to Kamailio, which, instead of forwarding it to the new IP from the *Contact* in the *200 OK*, sends it to the SIP provider at the same address used for the initial *INVITE*. Since the *ACK* does not reach the IP expected by the provider (the new IP introduced in the *Contact*), the provider continues to send repeated *200 OK* responses, until the call is disconnected due to a timeout, as a valid *ACK* was never received. I looked for conceptual answers in *RFC 3261* to support my conclusions, but I couldn’t clearly relate the information there to the behavior observed in this scenario. *Key Questions:* 1. *Should Kamailio forward the ACK to the new IP provided in the Contact header of the 200 OK?* 2. *Is the SIP provider correct in expecting the ACK to be sent to a different address from the original one used in the INVITE?* 3. *How can I configure Kamailio to ensure the dialogue proceeds correctly and the ACK is sent to the correct IP?*

2 1

Active/Active Registrar Design
by Knserbrave 20 Sep '24

20 Sep '24

Hi Community, Is it a common experience for architects to encounter issues with active/active registrar designs? Specifically, when clients are the UAS of a dialog? Some user agents accept INVITEs from any source once registered while others are not as accepting. There are ways around this using 302 redirect, but there seem to also be ways per RFC to signal trusted nodes to clients. RFC 3608 seems to be an excellent way to address this issue by communicating trustworthy nodes to the client upon registration. However, the Service-Route header seems to give options to the client rather than communicate trust. No where in the RFC does trust seem to be mentioned in its design, however one could imply it should be deduced by the presence of a Service-Route header. Nonetheless, even if it should communicate trust, it doesn't seem to do so in all cases so the more logical approach to active/active is signal via a 302 redirect where the registration lives, handling INVITE transactions on the server-side instead of client-side. I'm curious to hear if there is any advice on from the community overcoming trust issues with user agents in an active/active registrar design.

3 3

sni:uknown error in logs
by Mahmood Alkhalil 20 Sep '24

20 Sep '24

Hello Kamailio! I'm etting up a kamailio server where it will receive STIP TLS connections from Zoom. kamailio is closing TLS connections with error stating "SSL routines::no shared cipher (sni: unknown)" as below Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: tls [tls_server.c:270]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7fbcd1e9dac8 ctx 0x7fbcd2229258 sn []) Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: tls [tls_domain.c:1018]: tls_server_name_cb(): SSL_get_servername returned NULL: return SSL_TLSEXT_ERR_NOACK Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: <core> [core/tcp_main.c:2845]: tcpconn_do_send(): sending... Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: <core> [core/tcp_main.c:2881]: tcpconn_do_send(): after real write: c= 0x7fbcd3cb85d0 n=7 fd=8 Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: <core> [core/tcp_main.c:2882]: tcpconn_do_send(): buf= Sep 18 13:28:02 dalia kamailio[18529]: [3B blob data] Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) ERROR: tls [tls_server.c:1312]: tls_h_read_f(): protocol level error Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) ERROR: tls [tls_util.h:49]: tls_err_ret(): TLS accept:error:0A0000C1:SSL routines::no shared cipher (sni: unknown) did a tcpdump trace to check the ciphers Zoom are using in the TLS client hello, and there are 4 and are supported by openssl on TLSv1.2, BUT the reis no server_name extension in the client hello. is this related to kamailio refusing the connection because there is no server_name in the client hello or something else?, if yes can it be forced to accept TLS connection without server_name specified ? my tls.cfg file is below [server:default] method = TLSv1.2 verify_certificate = no require_certificate = no private_key = /etc/kamailio/key.pem certificate = /etc/kamailio/certificate.pem ca_list = /etc/ssl/certs/ca-certificates.crt ca_path = /etc/ssl/certs [client:default] method = TLSv1.2+ verify_certificate = no require_certificate = no

2 3

Accessing User-Agent from usrloc at runtime.
by Knserbrave 19 Sep '24

19 Sep '24

Hi Kamailio community. There are a few fields in the usrloc cache I am interested in accessing at runtime to influence routing decisions. I can use SQLops to achieve the same functionality, however I'm interested in minimizing DB operations. I would like to know if there is a generally accepted approach to retrieving this information from the memory-hosted usrloc cache rather than dipping into the database.

3 6

Re: Handling SIP Contact Header Changes and ACK Routing Issues
by Knserbrave 19 Sep '24

19 Sep '24

2 1

String Transformation to evaluate first part of header as key=value parameter?
by Benoit Panizzon 19 Sep '24

19 Sep '24

Hi List I have to parse a customer header: P-CH-Origin: intl=example.com;foo=bar;boo=whatever I'm interested in the value of the intl parameter. Unfortunately $(hdr(P-CH-Origin){param.value,intl}) does not seem to work, if this is the first parameter. Is there a built in function to do this? Mit freundlichen Grüssen -Benoît Panizzon- -- 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 ______________________________________________________

2 2

How to remove my email from Mailing list
by me.projects＠yahoo.com 19 Sep '24

19 Sep '24

Hi, I want to remove my email from mailing list. Thanks, ForTheGuru

2 1

Being added to the email marketing database of a 'kamailio developing' company after posting to list?
by Benoit Panizzon 18 Sep '24

18 Sep '24

Hi Today I received two marketing emails inviting me to the UCX Expo in London from I company I was not aware having any business relationship with. After searching for that company name in my email archive, I stumbled over a post from them in this mailing list. Just out of curiosity, have others on this list also received this invitation and in the past more marketing emails from the same source? I guess posting to this list does not imply, I have given permission to reader of this list to store my personal data in a marketing database of their employer and use my data for marketing purposes, right? Mit freundlichen Grüssen -Benoît Panizzon- -- 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 ______________________________________________________

3 2

Handling SIP Contact Header Changes and ACK Routing Issues
by Josimar Rocha 17 Sep '24

17 Sep '24

Hello community! I would like to ask for your help in solving a case. I thank you in advance for any collaboration. I have the following setup: Asterisk (internal) → Kamailio (Proxy) → SIP Provider (PSTN) Both Asterisk and Kamailio are under my responsibility. Problem: When I initiate a call from Asterisk, I use Kamailio as the outbound proxy. The INVITE is sent to the SIP provider, and the dialogue proceeds normally until the provider responds with a 200 OK, indicating the call was answered. However, the 200 OK received from the provider contains a modification in the Contact header, introducing a new IP address into the dialogue. Presumably, this new IP is where the subsequent ACK should be sent. The issue arises when Kamailio receives this 200 OK: it overwrites the Contact field, replacing the received IP with its own LAN IP, used for communication with Asterisk. As a result, Asterisk sends the ACK back to Kamailio, which, instead of forwarding it to the new IP from the Contact in the 200 OK, sends it to the SIP provider at the same address used for the initial INVITE. Since the ACK does not reach the IP expected by the provider (the new IP introduced in the Contact), the provider continues to send repeated 200 OK responses, until the call is disconnected due to a timeout, as a valid ACK was never received. I looked for conceptual answers in RFC 3261 to support my conclusions, but I couldn’t clearly relate the information there to the behavior observed in this scenario. Key Questions: Should Kamailio forward the ACK to the new IP provided in the Contact header of the 200 OK? Is the SIP provider correct in expecting the ACK to be sent to a different address from the original one used in the INVITE? How can I configure Kamailio to ensure the dialogue proceeds correctly and the ACK is sent to the correct IP?

1 0

2026

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 2024