sr-users May 2024

sr-users@lists.kamailio.org

32 participants
35 discussions

tm.t_uac_wait ACK does not have Max-Forwards header

by Juha Heinanen

Kamailio sends INVITE by tm.t_uac_wait RPC command: INVITE sip:test-0x55e7f1f78e70@192.168.187.215:5022 SIP/2.0 Via: SIP/2.0/UDP 192.168.187.215;branch=z9hG4bK6cf1.f1d087d6000000000000000000000000.0 To: <sip:test@test.tutpro.com> From: <sip:click2dial@test.tutpro.com>;tag=2dd3d4389fe3d66c5cb97dc370ab7d7b-9c5a2a58 CSeq: 1 INVITE Call-ID: 6649e78355ac2(a)test.tutpro.com Content-Length: 131 User-Agent: OpenSIPg SIP Proxy (5.9.0-0b01 (x86_64/linux)) Max-Forwards: 10 Contact: <sip:click2dial@192.168.187.215:5060> Content-Type: application/sdp .. sdp omitted UAS accepts the INVITE: SIP/2.0 200 Answering Via: SIP/2.0/UDP 192.168.187.215;branch=z9hG4bK6cf1.f1d087d6000000000000000000000000.0 To: <sip:test@test.tutpro.com>;tag=a3302e2a0898de3e From: <sip:click2dial@test.tutpro.com>;tag=2dd3d4389fe3d66c5cb97dc370ab7d7b-9c5a2a58 CSeq: 1 INVITE Call-ID: 6649e78355ac2(a)test.tutpro.com Server: baresip v3.12.0 (x86_64/Linux) Contact: <sip:test-0x55e7f1f78e70@192.168.187.215:5022> Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,UPDATE,REFER Supported: gruu,replaces,norefersub Content-Type: application/sdp Content-Length: 239 .. sdp omitted After receiving the response, Kamailio automatically sends ACK: ACK sip:test-0x55e7f1f78e70@192.168.187.215:5022 SIP/2.0 Via: SIP/2.0/UDP 192.168.187.215;branch=z9hG4bK6cf1.f1d087d6000000000000000000000000.0 From: <sip:click2dial@test.tutpro.com>;tag=2dd3d4389fe3d66c5cb97dc370ab7d7b-9c5a2a58 Call-ID: 6649e78355ac2(a)test.tutpro.com To: <sip:test@test.tutpro.com>;tag=a3302e2a0898de3e CSeq: 1 ACK User-Agent: OpenSIPg SIP Proxy (5.9.0-0b01 (x86_64/linux)) Content-Length: 0 The problem is that Max-Forwards header is missing from the ACK. Should I have something in config file to add it or is this a bug? -- Juha

3 hours, 44 minutes

Kamailio multidomain IMS

by Valentin Christoph

Dear IMS enthusiasts :-) Has anyone experience with Kamailio IMS (CSCF) setups, where users with different domain names can be registered at one and the same S-CSCF? Is this feasible at all? I mean one IMS for users <user>@ims1.example.com, <user>@ims2.example.com, <user>@ims3.example.com,........ in one and the same S-CSCF, I-CSCF, P-CSCF. Thanks, Christoph

15 hours, 2 minutes

A question about Db_flatstore Module in Kamailio

by فرزانه سلطان زاده

Hi, Hope to find you well, I have a question about the 'db_flatstore' module in Kamailio. Here's my script for log rotation: for f in acc_cdrs_*.log; do mv -- "$f" "${f%.log}.temp" done docker exec -it pcscf kamcmd flatstore.k_rotate rm *.temp I want to know if the kamcmd command is blocking and the files can be removed after that or if I should wait for it to be done before removing the renamed files. Regards, Farzaneh

20 hours, 53 minutes

Segfault on startup when using TLS in kamailio 5.7.4

by stefanr＠wave.com

Hi there, We are encountering consistent segfaults after rebooting our Kamailio instance with incoming traffic, specifically when using Kamailio 5.7.4. We think this issue did not occur with version 5.7.2, so it seems to have been introduced in either 5.7.3 or 5.7.4. Due to team bandwidth constraints and the potential impact on production traffic, we don't want to spend time on trying to reproduce the issue. So we have decided to downgrade to 5.6.4, which we confirmed to be stable. (Probably 5.7.2 would be too - but we didn't try). Unfortunately, our logging was only set to WARNING level, and we did not capture a core dump, so we cannot provide additional details beyond the following logs: This was with tcp_reuse_ports=yes: 2024-05-17T15:42:55.582475541Z Listening on 2024-05-17T15:42:55.582512370Z [redacted] 2024-05-17T15:42:55.582538161Z tls: 10.X.X.X:5061 advertise Y.Y.Y:5061 2024-05-17T15:42:55.582543750Z Aliases: 2024-05-17T15:42:55.582549081Z tls: [redacted]:5061 2024-05-17T15:42:55.582574890Z 2024-05-17T15:42:55.587876630Z 0(1) WARNING: tls [tls_init.c:978]: tls_h_mod_init_f(): openssl bug #1491 (crash/mem leaks on low memory) workaround enabled (on low memory tls operations will fail preemptively) with free memory thresholds 18874368 and 9437184 bytes 2024-05-17T15:42:55.703927049Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 23 2024-05-17T15:42:55.703972029Z 0(1) ALERT: <core> [main.c:791]: handle_sigs(): child process 15 exited by a signal 11 2024-05-17T15:42:55.703978409Z 0(1) ALERT: <core> [main.c:795]: handle_sigs(): core was generated 2024-05-17T15:42:55.705049839Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 17 2024-05-17T15:42:55.705074209Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 21 2024-05-17T15:42:55.705081209Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 22 2024-05-17T15:42:55.705085879Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 20 2024-05-17T15:42:55.705090319Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 18 2024-05-17T15:42:55.705094649Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 19 2024-05-17T15:42:55.705098879Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 16 2024-05-17T15:42:55.705207399Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 15 2024-05-17T15:42:55.705459439Z 35(41) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 27 Without tcp_reuse_ports=yes, the segfault was always preceded by the following line if any existing TLS connections were stuck in TIME_WAIT: 2024-05-16T19:18:51.654447639Z 9(14) WARNING: {1 1 INVITE XXX(a)0.0.0.0} <core> [core/tcp_main.c:1301]: find_listening_sock_info(): binding to source address 10.X.X>X:5061 failed: Address already in use [98] 2024-05-16T19:18:51.746994728Z 0(1) ALERT: <core> [main.c:791]: handle_sigs(): child process 14 exited by a signal 11 When the server wasn't handling any traffic, the issue didn't occur even in 5.7.4. Does anyone have any insights or suggestions on how to address this issue? Kind regards Stefan

2 days, 18 hours

Assistance Needed to Resolve Duplicate Contact Headers in 200 OK Response

by satyaprakash ch

Hi We are receiving 2 to 3 contact headers in the 200 OK response of the registration request. It appears that the `user_location` is updating multiple contact headers for the same extension due to network disconnections. Please suggest a solution to avoid duplicates in the `user_location` module, or how to ensure that only the latest single contact header is included in the 200 OK response. Your suggestion would be appreciated. Thanks and regards, Satyaprakash.

2 days, 18 hours

Fwd: rtpengine timestamp jumps

by Jeff Brower

Reposting this. If there is an issue with HTML format and/or wireshark screen cap and I need to upload that separately somewhere else, please let me know. Thanks. -Jeff ----- Forwarded message from Jeff Brower <jbrower(a)signalogic.com> ----- Date: Thu, 09 May 2024 05:32:27 +0000 From: Jeff Brower <jbrower(a)signalogic.com> Subject: [SR-Users] rtpengine timestamp jumps To: sr-users(a)lists.kamailio.org Hi rtpengine experts, We have some customers processing long multi-party call pcaps using mediaMin who are reporting large amounts of packets with timestamp jumps but no packet loss (for instance 10% of packets over a 1 hr 45 min call). For example, in the Wireshark excerpt shown below, packets 6 and 8 sent by rtpengine show a timestamp increment of 640, but sequence number increment of 1: In the mediaMin output packet log we typically see sections similar to: : : Seq num 98584 timestamp = 3902252372, rtp pyld len = 33 media-R Seq num 98585 timestamp = 3902252692, rtp pyld len = 33 media Seq num 98586 timestamp = 3902253012, rtp pyld len = 33 media-R Seq num 98587 timestamp = 3902253332, rtp pyld len = 33 media Seq num 98588 timestamp = 3902253652, rtp pyld len = 33 media-R Seq num 98589 timestamp = 3902253972, rtp pyld len = 33 media Seq num 98590 timestamp = 3902254292, rtp pyld len = 33 media Seq num 98591 timestamp = 3902254612, rtp pyld len = 33 media-R Seq num 98592 timestamp = 3902254932, rtp pyld len = 33 media Seq num 98593 timestamp = 3902255252, rtp pyld len = 33 media Seq num 98594 timestamp = 3902255572, rtp pyld len = 33 media-R Seq num 98595 timestamp = 3902255892, rtp pyld len = 33 media Seq num 98596 timestamp = 3902256212, rtp pyld len = 33 media Seq num 98597 timestamp = 3902256532, rtp pyld len = 33 media Seq num 98598 timestamp = 3902256852, rtp pyld len = 33 media-R Seq num 98599 timestamp = 3902257172, rtp pyld len = 33 media Seq num 98600 timestamp = 3902257492, rtp pyld len = 33 media-R Seq num 98601 timestamp = 3902257812, rtp pyld len = 33 media Seq num 98602 timestamp = 3902258132, rtp pyld len = 33 media Seq num 98603 timestamp = 3902258452, rtp pyld len = 33 media Seq num 98604 timestamp = 3902258772, rtp pyld len = 33 media-R Seq num 98605 timestamp = 3902259092, rtp pyld len = 33 media : : where media-R packets are timestamp gap repairs (i.e. frame loss concealment). The behavior tends to be bursty, but once it gets going it goes for a while and seems relatively consistent. Is this expected behavior for rtpengine ? If so is rptengine in turn dealing with some type of "slow packet rate" issue from a remote sender ? Thanks, Jeff ----- End forwarded message -----

2 days, 19 hours

$dlg_var() not implemented in ims_dialog module

by Valentin Christoph

Dear all, I would probably need to store some dialog scoped information in an IMS environment, but the ims_dialog module does not implement the $dlg_var() pseudo variable. Do you know other, maybe better, possibilities to store dialog scoped information in an IMS (CSCF) environment? Thank, Christoph

2 days, 19 hours

making HTTP Async request in stateless configuration

by Sergio Charrua

Hi all! Just wondering what would be you opinion on the following. We are integrating Kamailio as a stateless redirect server, using SIP 300 Multiple Choices response. The script requires that prior to the redirection, a HTTP request must be made. We thought about using HTTP Async Client to make the requests (POST of JSON content), which is our prefered way of sending HTTP requests, and depending on the response from the REST API, reply back to UAC a SIP 300 Multiple Choices message and terminate the call flow on Kamailio. From what I know, HTTP Async Client requires that the TM module be used, which (it is my understanding) will imply that the whole Kamailio script to be stateful, which I think is useless as the SIP flow will be really simple: INVITE -----> <------- 100 Trying <------- 300 Multiple Choices ACK ------> There is a catch, though, the CPS is very high, above 1000 CPS.... Could anyone share their thoughts on this? Should we go stateful and use the HTTP Async module? Should we go stateless and use the HTTP client module? What would be the best approach to implementing this? Thanks guys! *Sérgio Charrua*

3 days, 2 hours

Re: Failover with dialog dmq while dialog state 2

by Björn Klasen

Hi Henning, thank you for your reply. I did a lot testings during the past days and I think I found a solution that is working, although it's very dirty... I found out it is possible to send a manual KDMQ-Message to all Proxy-Nodes including the one that it sending die KDMQ-Message. So I create a dialog state 4 message on ACK and indeed the Dialog on all Peers are Updated correctly to state 4. I also tried this for state 3 on 200 OK, but this does not work. I haven't had a look into the code yet but my experiments shows, that there is never is state 3 update via DMQ, so I think it's not implemented. Interestingly the TM-Timer still times out after 300 seconds but in normal circumstances this doesn't bother, because either the failed Kamailio will not trigger this, because the Software or the Server crashed, or it tries to send a CANCEL that is denied because we are in dialog state 4. The only thing is your really have to be careful about your hash tables. You have to delete them at the correct point. I really need to test a lot at this point, but till now, billing seems to be OK even on failover scenarios. This is why I really like Kamailio :) BR, Björn Am 09.05.24 um 20:57 schrieb Henning Westerholt: Hello, thanks for the detailed e-mail. As also indicated in the module documentation, the dialog module DMQ replication will not replicate everything, its main use-case is for profile data sharing. https://kamailio.org/docs/modules/5.8.x/modules/dialog.html#dialog.p.enable… In the past months there have been some other discussions on the users lists about similar scenarios (I think related to billing/accounting) and dialog with DMQ, which might be interesting for you in this regard. If you find issues where the DMQ synchronisation is lacking some functionality in the dialog module, you can create a feature request in our issue tracker. There is of course no guarantee that this limitation is also timely addressed. Regarding the INVITE and CANCEL scenario, this is usually not related to dialog but to the tm module. As you also mentioned, there is no replication of transaction state in tm. Cheers, Henning -- Björn Klasen, Senior Specialist (VoIP) TNG Stadtnetz GmbH, TNG-Technik Gerhard-Fröhler-Straße 12 24106 Kiel・Deutschland T +49 431 7097-10 F +49 431 7097-555 bklasen(a)tng.de<mailto:bklasen@tng.de> https://www.tng.de Executive board (Geschäftsführer): Dr. Sven Willert (CEO/Vorsitz), Gunnar Peter, Sven Schade, Carsten Tolkmit, Bernd Sontheimer Amtsgericht Kiel HRB 6002 KI USt-ID: DE225201428 Die Information über die Verarbeitung Ihrer Daten gemäß Artikel 12 DSGVO können Sie unter https://www.tng.de/datenschutz/ abrufen. ______________________________________________________________________

3 days, 3 hours

Intercepting OPTIONS from nathelper

by Denys Pozniak

Hello! I need advice on how to intercept local SIP OPTIONS requests from the nathelper module for some adjustments? As far as I tested, it does not fall into the *event_route[tm:local-request]* Thanks in advance! # kamailio -v version: kamailio 5.7.1 (x86_64/linux) 1cf389-dirty -- BR, Denys Pozniak

3 days, 15 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 May 2024