sr-users September 2024

sr-users@lists.kamailio.org

27 participants
30 discussions

String Transformation to evaluate first part of header as key=value parameter?

by Benoit Panizzon

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 ______________________________________________________

48 minutes

Kamailio not listening to SIP despite setup OK

by Sergio Charrua

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*

1 hour, 22 minutes

How to remove my email from Mailing list

by me.projects＠yahoo.com

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

4 hours, 59 minutes

sni:uknown error in logs

by Mahmood Alkhalil

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

1 day, 2 hours

Being added to the email marketing database of a 'kamailio developing' company after posting to list?

by Benoit Panizzon

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 ______________________________________________________

1 day, 3 hours

Handling SIP Contact Header Changes and ACK Routing Issues

by Josimar Rocha

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 day, 19 hours

Handling SIP Contact Header Changes and ACK Routing Issues

by XPTO

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?*

1 day, 19 hours

Handling SIP Contact Header Changes and ACK Routing Issues

by Josimar Rocha

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 day, 19 hours

Kamailio packages for 24.04.1 LTS (Noble Numbat)

by Leonid Fainshtein

Hello, Is it planned to release the Kamailio 5.8 deb packages for 24.04.1 LTS (Noble Numbat)? Best regards, Leonid

2 days, 3 hours

About error running PCSCF

by luis.ramost＠pucp.edu.pe

Hi community: I am trying to run the Kamailio IMS, but I have the next error in the module PCSCF I installed the Kamailio on a VM Machine, with UBuntu 18.04 Commands: $ sudo -i # mkdir -p /var/run/kamailio_pcscf #kamailio -f /etc/kamailio_pcscf/kamailio_pcscf.cfg -P /kamailio_pcscf.pid -DD -E -e Output: loading modules under config path: /usr/lib64/kamailio/modules_k/:/usr/lib64/kamailio/modules/:/usr/lib/kamailio/modules_k/:/usr/lib/kamailio/modules/:/usr/lib/x86_64-linux-gnu/kamailio/modules/:/usr/local/lib64/kamailio/modules 0(470) ERROR: <core> [core/modparam.c:164]: set_mod_param_regex(): parameter <delete_delay> of type <2:int> not found in module <ims_registrar_pcscf> 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/kamailio_pcscf.cfg, line 399, column 51: Can't set module parameter 0(470) ERROR: <core> [core/modparam.c:164]: set_mod_param_regex(): parameter <ipsec_preferred_ealg> of type <1:string> not found in module <ims_ipsec_pcscf> 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/kamailio_pcscf.cfg, line 417, column 59: Can't set module parameter 0(470) ERROR: <core> [core/modparam.c:164]: set_mod_param_regex(): parameter <recv_mode> of type <2:int> not found in module <ims_qos> 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/kamailio_pcscf.cfg, line 435, column 35: Can't set module parameter 0(470) ERROR: <core> [core/modparam.c:164]: set_mod_param_regex(): parameter <dialog_direction> of type <2:int> not found in module <ims_qos> 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/kamailio_pcscf.cfg, line 436, column 42: Can't set module parameter 0(470) INFO: pv [pv_shv.c:60]: shvar_init_locks(): locks array size 16 0(470) ERROR: <core> [core/cfg.y:3399]: yyparse(): cfg. parser: failed to find command ipsec_forward (params 2) 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/route/register.cfg, line 260, column 42: unknown command, missing loadmodule? 0(470) ERROR: <core> [core/cfg.y:3399]: yyparse(): cfg. parser: failed to find command ipsec_create (params 2) 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/route/register.cfg, line 264, column 77: unknown command, missing loadmodule? 0(470) ERROR: <core> [core/cfg.y:3399]: yyparse(): cfg. parser: failed to find command ipsec_forward (params 2) 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/route/mo.cfg, line 114, column 31: unknown command, missing loadmodule? 0(470) ERROR: <core> [core/cfg.y:3399]: yyparse(): cfg. parser: failed to find command ipsec_forward (params 2) 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/route/mo.cfg, line 180, column 33: unknown command, missing loadmodule? 0(470) ERROR: <core> [core/cfg.y:3399]: yyparse(): cfg. parser: failed to find command ipsec_forward (params 2) 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/route/mt.cfg, line 11, column 34: unknown command, missing loadmodule? 0(470) ERROR: <core> [core/cfg.y:3399]: yyparse(): cfg. parser: failed to find command ipsec_forward (params 2) 0(470) CRITICAL: <core> [core/cfg.y:3539]: yyerror_at(): parse error in config file /etc/kamailio_pcscf/route/mt.cfg, line 99, column 42: unknown command, missing loadmodule? ERROR: bad config file (10 errors) 0(470) WARNING: <core> [core/mem/q_malloc.c:487]: qm_free(): WARNING: free(0) called from cdp_avp: cdp_avp_mod.c: cdp_avp_destroy(226) 0(470) INFO: cdp [cdp_mod.c:255]: cdp_exit(): CDiameterPeer child stopping ... 0(470) INFO: cdp [cdp_mod.c:257]: cdp_exit(): ... CDiameterPeer child stopped 0(470) ERROR: ims_ipsec_pcscf [ims_ipsec_pcscf_mod.c:309]: mod_destroy(): Error destroying spi generator 0(470) ERROR: ims_ipsec_pcscf [ims_ipsec_pcscf_mod.c:313]: mod_destroy(): Error destroying port generator I guided form this tutorial: https://ryantheelder.github.io/blog/2023/VoLTE/ Please if somebody would help me, I appreciate it Finally my objective is to connect with srsRAN and open5GS to have VoLTE service. Best wishes, Luis

2 days, 23 hours

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