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
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.
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 -----
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
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*
Hello list,
I'm trying implementing a solution like:
https://github.com/havfo/WEBRTC-to-SIP/blob/master/etc/kamailio/kamailio.cfg
The 2 problems I have a this moment are:
Call from UDP phone to WebRTC phone, the WebRTC phone reject the call;
the call go to voicemail but in the SDP still have WebRTC SDP
During a SIP UDP - WebRTC Call tranfer the call using phone button...
the transfer don't work.
Any hint
Regards
--
---
I'm SoCIaL, MayBe
Hi All,
I'm having trouble understanding/finding resources on how to handle a 302 message I receive. I'm working on making an inbound sbc with kamailio with clearip integration. I'm successfully sending to kamailio, but am having trouble retrieving the response from clearip in kamailio.
For some background, the intended call flow should be this:
first it should send from caller to kamailio (caller > kamailio), then over tcp kamailio sends to clearip (kamailio > clearip) [This is what is working as expected]
Then I should be able to signal to kamailio to continue the call to the intended destination.
When clearip sends a code back (in this case 302), I want to be able to see that code and send the caller to the correct destination. The problem I keep running into is that I can't seem to see the 302 code in a reply, branch or failure root or checking the status. I'm just lost on what I am misunderstanding and would appreciate if anyone could point me in the right direction on how to approach retrieving the 302 message.
I'm using kamailio version 5.6.3 and debian 12.1
Thanks in advance,
Temi
Hello,
I'm testing Kamailio 5.x as a redirecting server based on calling number.
The calling numbers are stored on a DB and loaded in htable at runtime.
When the INVITE or REGISTER arrive Kamailio checks if there is a match
on $fU in htable (KEY_NAME) and if there is one, it replies with 302
adding the Contact HF with $fU@$sht(cli=>$fU)(with the domain part found
in KEY_VALUE):
append_to_reply("<Contact: sip:$fU@$sht(cli=>$fU)>\r\n");
If I use the full number as KEY_NAME it works as expected, but how can I
match on a prefix instead of the whole $fU?
For example, If I receive a call form 0655123456 I want to match it also
if I have the prefix 0655 in htable.
Do you have some advice to achieve this goal with htable or in a similar
way?
Thank you.
Best regards.
--
Antonio Reale