sr-users October 2022

sr-users@lists.kamailio.org

48 participants
51 discussions

No REGISTER sent to third party AS from scscf
by Anthony Blandin 24 Oct '22

24 Oct '22

Hi Community, I am using scscf from Kamailio and I need that scscf sent a REGISTER to a third party AS during the registration phase. When scscf received a new registration, no REGISTER is sent to the AS. SAR-SAA is well processed but only 200 OK is sent for the REGISTER to the pcscf. REGISTER is well sent to the AS only for Re-Registration or De-registration. Do you have any idea to handle this case? Regards Anthony

2 3

Dialog Module: How to get two different dialogues if a call is looped through kamailo (call forwarding scenario)
by Benoit Panizzon 21 Oct '22

21 Oct '22

Hi Using the dialog module to generate CDR for billing. We have this situation: Kamailio 'routing' instance, where dialog is used and billing happens. Kamailio 'register' instance. IC is connected to the routing instance. Customers register to the register instance. Call originates from 'A' via IC through routing instance to register instance and rings customer 'B'. This times out and 'call forwarding' is engaged by sending the call back to the routing instance with a new RURI containing the call forwarding destination 'C'. An appropriate 'no-answer' Diversion Header is added. Now we need two different CDR for this scenario (add more CDR if the call is forwarded multiple times) One from the A to B leg to bill termination fee to the IC carrier. One from B to C to bill the forwarded call with destination 'C' to customer B. The issue I now face is that I only get the kamailio routing instance to generates one dialogue from B to C despite handling two separate connections. How could that challenge be solved? 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

relay sip-tls vs sips-tcp
by beer Ll 21 Oct '22

21 Oct '22

Hi everyone, I'm using Kamailio as TLS gateway/filter for an internal Asterisk server the network schema is : UAC (tls) --- INTERNET --- (tls) KAMAILIO (sip udp) --- LAN --- (sip udp) ASTERISK with kamailio in multi-homed mode WAN network interface for sip tls LAN network interface for sip udp to asterisk server UAC address 80.0.0.1 KAMAILIO Wan address 80.0.0.2 KAMAILIO Lan address 172.16.0.2 ASTERISK Lan address 172.16.0.3 SIP-TLS call example If the UAC use tls(sip) all works good [image: sip-ok-small.jpeg] SIPS call example If the same UAC use his default settings tls(sips) , there are problems with ACK and BYE packet [image: sip-ko-small.jpeg] the SIP OK SDP packet from kamailio to UAC is 2022/10/10 09:28:47.854721 80.0.0.2:5061 -> 80.0.0.1:49992 SIP/2.0 200 OK Via: SIP/2.0/TLS 192.168.0.1:49992 ;rport=49992;received=80.0.0.1;branch=z9hG4bKM01j360VrBdH5VSV Record-Route: <sip:172.16.0.1:5060 ;lr;r2=on;ftag=F798336AA08EF9FCFA89D3BDFE0C8C8F> Record-Route: <sip:80.0.0.2:5061 ;transport=tls;lr;r2=on;ftag=F798336AA08EF9FCFA89D3BDFE0C8C8F> Call-ID: 1EC2AB679C1EA1BAB60FD03B09F878020B12D3E7 From: <sips:200@pbx.voip.com>;tag=F798336AA08EF9FCFA89D3BDFE0C8C8F To: <sips:*43@pbx.voip.com>;tag=961d0e22-a4f0-453c-9870-6a41578afc96 CSeq: 2 INVITE Contact: <sip:172.16.0.2:5060> P-Asserted-Identity: "xxxxxxxxx" <sips:*43@pbx.voip.com> Content-Type: application/sdp and the UAC send the ACK and BYE from a different tcp port and to: sips:172.16.0.2:5060;transport=tcp 2022/10/10 09:28:48.495365 80.0.0.1:49996 -> 80.0.0.2:5061 ACK sips:172.16.0.2:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TLS 192.168.0.1:49996;branch=z9hG4bKppftdQze20lnwT41;rport Route: <sip:80.0.0.2:5061 ;transport=tls;lr;r2=on;ftag=F798336AA08EF9FCFA89D3BDFE0C8C8F> Route: <sip:172.16.0.1:5060;lr;r2=on;ftag=F798336AA08EF9FCFA89D3BDFE0C8C8F> Max-Forwards: 70 To: <sips:*43@pbx.voip.com>;tag=961d0e22-a4f0-453c-9870-6a41578afc96 From: <sips:200@pbx.voip.com>;tag=F798336AA08EF9FCFA89D3BDFE0C8C8F Call-ID: 1EC2AB679C1EA1BAB60FD03B09F878020B12D3E7 CSeq: 2 ACK kamailio error log WARNING: <core> [core/forward.c:229]: get_send_socket2(): protocol/port mismatch (forced udp:172.16.0.2:5060, to tls:172.16.0.3:5060) How can I solve this ? Best Regards Leo

3 4

After changing instance type for kamailio server in aws log file is corrupted
by Sammy Dominguez 19 Oct '22

19 Oct '22

Hello guys, after changing instance type from t2 to t3a for kamailio server in aws log(/var/log/kamailio.log) file and some other files are corrupted and I can not touch,delete,create or anything and when kamailio start receiving traffic it crashed. Is there any particular reason for this? Basically on t2, they are under /dev/sda1 and /dev/xvda. Under t3 they are nvme disks (biggest part of the speed increase), so they are under /dev/nvme1n1. Note: once I rollback to t2 everything is working as expected.

1 0

Issue with duplicite SIP messages in traffic loop
by Michal Popovič 19 Oct '22

19 Oct '22

Hello, I am trying to configure kamailio to use external antifraud protection using so called "traffic loop" when call is forwarded to external SIP proxy that would response even with same INVITE back or with error message if number is fraud. schema: PBX -> kamailio -> traffic loop -> kamailio -> carrier Kamailio in second and fourth step is the same. Issue is that if kamailio receives same INVITE back to I would like to forward to next carrier it is possible, but kamailio struggles with transaction handling. If ACK message come from PBX, kamailio will correctly forward it to traffic loop but when it comes back, function t_check_trans is failed and I cant relay it. Only workaround is to use send() message, but that causes deny of BYE message from carrier. My question is following: Is it possible to register two different transactions states for same message? If yes how? If no, would it help to send and receive messages on another network port or not? Thank you, Michal

2 1

Recommended openSSL version
by Igor Olhovskiy 19 Oct '22

19 Oct '22

Hello! Due to I still experience irregular Kamailio 5.4 crashes (like 1/month) related to SSL (using websockets and SIPS) I'm wondering, could openSSL upgrade change the situation? As of now in CentOS 7 I have 1.0.2k version. Does anyone have experience to fix crash-related to TLS problems with openSSL upgrade? Or maye some tuneup of TCP parameters can help here?My current setup is quite simple: children=4 enable_tls=yes tcp_accept_no_cl=yes tcp_connection_lifetime=600 tcp_max_connections=998976 # 1000000 - 1024, so we're leaving 1k for system reserve tls_max_connections=998976 Number of clients ~ 200 constantly connected to websocket. -- Best regards, Igor

5 7

IMC module
by Giovanni Iamonte 19 Oct '22

19 Oct '22

HI, I am facing a problem related to the IMC module. I have installed kamailio 5.2.x and I tried to list the members of a room-qsipchat. In my test environment the kamailio.cfg file it is very basic, the kamailio server listen on tcp=192.168.100.192:15006 the client run on a PC with IP address 192.168.100.156 the imc outbound_proxy is set modparam("imc", "db_url", DBURL) modparam("imc", "imc_cmd_start_char", "#") modparam("imc", "outbound_proxy", "sip:sip-test.quintetto.it:15006;transport=tcp") The client start by sending a #join message to kamailio and looking the log file I can see that the room-qsipchat has been create, and also I received the message 200 OK. By using the tcpdump I can see the join message from the Client to kamailio server and the reply from kamailio to the client. When I send the #list message to the room-qsipchat , I expecting to receive the message relate to room's members and the 200 OK message. When I tcp dumping I saw the following messages ******************************************************************** Request from client to list the members - from client to server ******************************************************************** TX 538 bytes Request msg MESSAGE/cseq=57652 (tdta0x77b26460a8) to TCP 192.168.100.192:15006: MESSAGE sip:room-qsipchat@sip-test.quintetto.it SIP/2.0 Via: SIP/2.0/TCP 192.168.100.156:48129;rport;branch=z9hG4bKPjRzgOBgY6vfKZ8Fh8GA4CWheCO840Xzud;alias Max-Forwards: 70 From: <sip:quintetto00@sip-test.quintetto.it>;tag=1is.Ng6ZKJmCT1uAJ9WuJhe3hiQysj9f To: <sip:room-qsipchat@sip-test.quintetto.it> Call-ID: GwOQMLFfIq7o7jvF4OQlJ-jBb2OBaAKY CSeq: 57652 MESSAGE Accept: text/plain, application/im-iscomposing+xml Route: <sip:sip-test.quintetto.it:15006;transport=tcp;lr> Content-Type: text/plain Content-Length: 5 #list ******************************************************************** The server ask for the authentication - from server to client ******************************************************************** 2022-10-17 15:45:25.837 4700-10610/it.quintetto.qsipchat D/pjlib(pjsua_1): RX 574 bytes Response msg 407/MESSAGE/cseq=57652 (rdata0x77b3337330) from TCP 192.168.100.192:15006: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/TCP 192.168.100.156:48129;rport=48129;branch=z9hG4bKPjRzgOBgY6vfKZ8Fh8GA4CWheCO840Xzud;alias;received=192.168.100.156 From: <sip:quintetto00@sip-test.quintetto.it>;tag=1is.Ng6ZKJmCT1uAJ9WuJhe3hiQysj9f To: <sip:room-qsipchat@sip-test.quintetto.it>;tag=1e5fbdd4b14eff95c400342f4634da91.e417 Call-ID: GwOQMLFfIq7o7jvF4OQlJ-jBb2OBaAKY CSeq: 57652 MESSAGE Proxy-Authenticate: Digest realm="sip-test.quintetto.it", nonce="Y01doWNNXHVEyRtiAyN28xJdMjNIG8Ju" Server: kamailio (5.2.8 (x86_64/linux)) Content-Length: 0 ********************************************************************* The client send the authenticated request - from client to server ******************************************************************** TX 755 bytes Request msg MESSAGE/cseq=57653 (tdta0x77b26460a8) to TCP 192.168.100.192:15006: MESSAGE sip:room-qsipchat@sip-test.quintetto.it SIP/2.0 Via: SIP/2.0/TCP 192.168.100.156:48129;rport;branch=z9hG4bKPjj6uuy25r0kKlnICHKQWEaIweOex-sNyq;alias Max-Forwards: 70 From: <sip:quintetto00@sip-test.quintetto.it>;tag=1is.Ng6ZKJmCT1uAJ9WuJhe3hiQysj9f To: <sip:room-qsipchat@sip-test.quintetto.it> Call-ID: GwOQMLFfIq7o7jvF4OQlJ-jBb2OBaAKY CSeq: 57653 MESSAGE Accept: text/plain, application/im-iscomposing+xml Route: <sip:sip-test.quintetto.it:15006;transport=tcp;lr> Proxy-Authorization: Digest username="quintetto00", realm="sip-test.quintetto.it", nonce="Y01doWNNXHVEyRtiAyN28xJdMjNIG8Ju", uri="sip:room-qsipchat@sip-test.quintetto.it", response="d495ec20cb1be8f1b605d4e5b1a4c357" Content-Type: text/plain Content-Length: 5 #list ************************************************************************** The server send the 200 OK message - from server to client ******************************************************************** RX 447 bytes Response msg 200/MESSAGE/cseq=57653 (rdata0x77b3337330) from TCP 192.168.100.192:15006: SIP/2.0 200 ok Via: SIP/2.0/TCP 192.168.100.156:48129;rport=48129;branch=z9hG4bKPjj6uuy25r0kKlnICHKQWEaIweOex-sNyq;alias;received=192.168.100.156 From: <sip:quintetto00@sip-test.quintetto.it>;tag=1is.Ng6ZKJmCT1uAJ9WuJhe3hiQysj9f To: <sip:room-qsipchat@sip-test.quintetto.it>;tag=1e5fbdd4b14eff95c400342f4634da91.365f Call-ID: GwOQMLFfIq7o7jvF4OQlJ-jBb2OBaAKY CSeq: 57653 MESSAGE Server: kamailio (5.2.8 (x86_64/linux)) Content-Length: 0 ********************************************************************************* Till here everything is OK. But regarding the members when a TCP dumping I saw a message with the room's members that go from the kamailio server to the kamailio server ********************************************************************************* MESSAGE sip:quintetto00@sip-test.quintetto.it SIP/2.0 Via: SIP/2.0/TCP 192.168.100.192:15006;branch=z9hG4bKf20a.be253b92000000000000000000000000.0 To: <sip:quintetto00@sip-test.quintetto.it> From: <sip:room-qsipchat@sip-test.quintetto.it>;tag=03e4c67b0f95c0aeb1f633479b4aa5cd-72f2 CSeq: 10 MESSAGE Call-ID: 37db44aa523ea24a-6567(a)192.168.100.192 Max-Forwards:.70 Content-Length: 47 User-Agent: kamailio (5.2.8 (x86_64/linux)) Content-Type: text/plain Members: *sip:quintetto00@sip-test.quintetto.it ************************************************************************************** a reply from the kamailio server to the kamailio server, with an authenticated request ************************************************************************************** SIP/2.0.407.Proxy Authentication.Required Via: SIP/2.0/TCP 192.168.100.192:15006;branch=z9hG4bKf20a.be253b92000000000000000000000000.0 To: <sip:quintetto00@sip-test.quintetto.it>;tag=1e5fbdd4b14eff95c400342f4634da91.cfc3 From: <sip:room-qsipchat@sip-test.quintetto.it>;tag=03e4c67b0f95c0aeb1f633479b4aa5cd-72f2 CSeq: 10 MESSAGE Call-ID: 37db44aa523ea24a-6567(a)192.168.100.192 Proxy-Authenticate: Digest realm="sip-test.quintetto.it", nonce="Y01fQmNNXhbsHdM1THmENyJn1MH/VD/8" Server: kamailio (5.2.8 (x86_64/linux)) Content-Length:.0 ************************************************************************************** bottom of line the outbound_proxy request for an authenticated request, but kamailio do not reply to this request. Could you please point me in the right direction? Thanks a lot for any help. Bye -- ------------------------------------------------------------------------ Ing. Giovanni Iamonte Developments and technologies area Quintetto Srl Via Monte Navale, 1 10015 - Ivrea (TO)  mobile: +39 393 9196310  tel: +39 0165 1845290  e-mail: giovanni.iamonte(a)quintetto.it  web: www.quintetto.it

2 4

ClueCon and ... FreeSWITCH 1.10.8/RHEL8 packages!
by Richard Chan 18 Oct '22

18 Oct '22

Hi sr-users, Since ClueCon is going on right now, and some Kamailio community members are involved I hope you will forgive a little promo here: I have a RHEL8 build of the just released 1.10.8 on Copr: https://copr.fedorainfracloud.org/coprs/beaveryoga/FreeSWITCH-1.10.8/ Hope you will find it useful in your kamailio + Class 5 scenarios! Cheers Shih-Ping

1 0

Testing dialog module (and acc with dialog cdrs)
by Daniel-Constantin Mierla 18 Oct '22

18 Oct '22

Hello, as I am not a user of dialog variables, I am turning to community to ask for help testing the current master branch with configurations that make use of dialog variables and acc dialog-based cdr generation. With a few reports of issues related to dialog modules and unexpected crashes, I looked over the code and noticed that the access of the value for dialog variables was not protected, making them vulnerable of invalid memory access in case of the variable was updated by another process or dialog was terminated. I introduced a couple of new functions to try to cover different use cases of getting the dlg variable values, dialog management code was not affected, but given that these commits need to be backported to stable branch (5.6), I want to get proper feedback from community that things work fine. A previous attempt of a simpler fix was not enough, having side effects to acc module for dialog-based cdr generation, because it was keeping referenced to many dlg variables at the same time. In short, it would be appreciated any feedback on testing dialog and acc with dialog-based cdr generation using git master branch. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online Nov 7-10, 2022 (Europe Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/

3 13

kamailio & rtpengine question
by Gerry Kernan 15 Oct '22

15 Oct '22

Hi Looking for advise if anyone could point out where im going wrong. My setup is Kamailio Ver 5.6.0 running in azure , rtpengine Version: git-master-dc395d5, behind kamailio I have asterisk ver 18.12.1 Kamailio conf I have interface set as below listen=udp:10.3.1.6:5060 advertise WANIP:5060 and rtpengine.conf set as below interface = eth0/10.3.1.5 but when I can make a call I don't get any audio, rtpengine.log extract below shows that rtp is going to the private IP rather that the Public IP of the phone that initiated the call, do I need to set rtpengine_manage() to fix this? Oct 7 09:38:58 kamailio-proxy rtpengine[8127]: INFO: [NmE0MjdhMzA4NjUzYWVjMmRjYzIxNGJjMTY4ZTc2MWE. port 30278]: [core] Confirmed peer address as 10.3.1.5:12890 Oct 7 09:38:58 kamailio-proxy rtpengine[8127]: INFO: [NmE0MjdhMzA4NjUzYWVjMmRjYzIxNGJjMTY4ZTc2MWE. port 30278]: [core] Kernelizing media stream: 10.3.1.5:12890 -> 10.3.1.6:30278 | 10.3.1.6:30298 -> 192.168.0.123:40042 Oct 7 09:39:00 kamailio-proxy rtpengine[8127]: INFO: [NmE0MjdhMzA4NjUzYWVjMmRjYzIxNGJjMTY4ZTc2MWE. port 30279]: [core] Confirmed peer address as 10.3.1.5:12891 Kind regards gerry Gerry Kernan | Technical Director Mobile: +353(0)86-170 9790 [Graphical user interface, website Description automatically generated]<https://www.infinityit.ie/> [A picture containing text, clipart Description automatically generated,Icon Description automatically generated]

3 8

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 October 2022