- sr-users - kamailio.org

S-CSCF SiFC support
by ruben.iniguez＠vodafone.com 22 May '24

22 May '24

Hello In the context of an IMS deployment, does anybody know if Shared iFC mechanism is supported in Kamailio? I don't see configuration options for it, and just wanted to confirm if only regular iFCs (residing on HSS) are supported. Thank you

1 0

Assistance Required for VoNR Setup with Version 5.8.1
by venkateshcoff＠gmail.com 22 May '24

22 May '24

Hi, I am trying to set up VoNR with version 5.8.1, but I cannot find the configuration information and documentation anywhere. Has anyone tested a VoNR call? Thanks.

1 0

usrloc: keepalives not being sent to UDP endpoints for a very long time
by luke＠primevox.net 21 May '24

21 May '24

We've noticed an issue with UDP endpoints and the usrloc module not sending keepalive packets to them for a long time. Eventually, usrloc will begin doing it, but sometimes it's anywhere between 10 minutes and multiple hours before the endpoint starts receiving an OPTIONS packet. TCP and TLS endpoints do not have this issue - they being receiving OPTIONS after registration + ka_timeout elapsed. Has anyone else seen this? It can be very easily seen with a pcap on a device registering via UDP.

1 0

A question about Db_flatstore Module in Kamailio
by فرزانه سلطان زاده 20 May '24

20 May '24

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

3 2

Kamailio multidomain IMS
by Valentin Christoph 20 May '24

20 May '24

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

2 1

q_malloc.c:520 WARNINGs
by Joel Serrano 20 May '24

20 May '24

Hi, Does anyone know what this WARNING means or how to fix it? 2024-03-09T00:39:15.406674-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.406823-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.406973-05:00 … [View More]

2 5

tm.t_uac_wait ACK does not have Max-Forwards header
by Juha Heinanen 20 May '24

20 May '24

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:… [View More]

1 3

Segfault on startup when using TLS in kamailio 5.7.4
by stefanr＠wave.com 17 May '24

17 May '24

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 … [View More]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 [View Less]

2 2

Assistance Needed to Resolve Duplicate Contact Headers in 200 OK Response
by satyaprakash ch 17 May '24

17 May '24

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 1

Fwd: rtpengine timestamp jumps
by Jeff Brower 17 May '24

17 May '24

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 … [View More]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 ----- [View Less]

1 0

$dlg_var() not implemented in ims_dialog module
by Valentin Christoph 17 May '24

17 May '24

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

3 2

making HTTP Async request in stateless configuration
by Sergio Charrua 17 May '24

17 May '24

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 … [View More]

1 0

WebRTC-UDP voicemail and call transfer
by Social Boh 16 May '24

16 May '24

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

1 0

dynamic selection of authentication algorithm
by Juha Heinanen 14 May '24

14 May '24

How about this new function that sets the algorithm? -- Juha iff --git a/src/modules/auth/auth_mod.c b/src/modules/auth/auth_mod.c index 534ad9e20f..4e3a584d22 100644 --- a/src/modules/auth/auth_mod.c +++ b/src/modules/auth/auth_mod.c @@ -74,6 +74,10 @@ int w_consume_credentials(struct sip_msg *msg, char *s1, char *s2); * Check for credentials with given realm */ int w_has_credentials(struct sip_msg *msg, char *s1, char *s2); +/* + * Set authentication algorithm + */ +int … [View More]

3 6

302 Message Handling
by tfayomi＠untangledtechnology.com 14 May '24

14 May '24

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 … [View More]

2 1

Prefix match in htable
by Antonio Reale 13 May '24

13 May '24

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 … [View More]

1 0

Kamailio and RTPengine and no voice on calls
by palany 10 May '24

10 May '24

I have an AWS ec2 instance with Kamailio and rtpengine configured. I am having a challenge of no voice on calls. I have sip client on my mobile phone and soft phone on my laptop and the two are on different networks behind nat. Signaling is working fine but there is no media and when I check on on the SDP the call logs are showing private ips instead of public ips : o=- 3 2 IN IP4 192.168.1.33 and c=IN IP4 172.31.36.50. I understand this is a NAT issue but I am failing to see where is the … [View More]

2 3

base64 decoding issue
by Sergio Charrua 10 May '24

10 May '24

Hi all! I have been dealing with STIR/SHAKEN for a few weeks now, and while doing some tests I have found an issue which I can't find the reason for. The script has the following route logic: route[HANDLE_STIRSHAKEN] { xlog("L_INFO", "HANDLE_STIRSHAKEN - STIR/SHAKEN Logic"); if ($hdrc(Identity) == 0 ){ xlog("L_INFO", "HANDLE_STIRSHAKEN - No Identity Header -> Skipping this logic"); return; } #Verify Call Identity xlog("L_INFO", "HANDLE_STIRSHAKEN - … [View More]Identity Header: $hdr(Identity)"); $var(header_1)= $(hdr(Identity){s.select,0,.}); $var(header_2)= $(hdr(Identity){s.select,1,.}); xlog("L_INFO", "HANDLE_STIRSHAKEN - Encoded Header 1: $var(header_1)"); xlog("L_INFO", "HANDLE_STIRSHAKEN - Encoded Header 2: $var(header_2)"); xlog("L_INFO", "HANDLE_STIRSHAKEN - Decoded Header 1: $(var(header_1){s.decode.base64})"); xlog("L_INFO", "HANDLE_STIRSHAKEN - Decoded Header 2: $(var(header_2){s.decode.base64})"); xlog("L_INFO", "HANDLE_STIRSHAKEN - Parsing!"); $var(hdr_1_json_payload) = $(var(header_1){s.decode.base64}); # Header 1 xlog("L_INFO", "HANDLE_STIRSHAKEN - Parsed!"); xlog("L_INFO", "HANDLE_STIRSHAKEN - Header 1 payload = $var(hdr_1_json_payload) "); $var(hdr_2_json_payload) = $(var(header_2){s.decode.base64}); # Header 2 jansson_get_field($var(hdr_2_json_payload), "attest", "$var(attest_value)"); jansson_get_field($var(hdr_2_json_payload), "ppt", "$var(ppt_value)"); jansson_get_field($var(hdr_2_json_payload), "typ", "$var(typ_value)"); jansson_get_field($var(hdr_2_json_payload), "x5u", "$var(x5u_value)"); xlog("L_INFO", "HANDLE_STIRSHAKEN - $var(attest_value) $var(ppt_value) $var(typ_value) $var(x5u_value) "); } All it does is parse the Identity header received on the initial INVITE, decodes it (it is encoded in base64) and writes some JSON values on log. Nothing serious.... As the Identity header is divided into multiple parts, separated by a ".", I get the first 2 parts in 2 private variables, as per lines: $var(header_1)= $(hdr(Identity){s.select,0,.}); $var(header_2)= $(hdr(Identity){s.select,1,.}); Logs show correctly that both variables are populated: May 10 09:09:42 kamailio1 kamailio[153201]: INFO: {1 10 INVITE 1-1966540(a)10.20.0.1} <script>: HANDLE_STIRSHAKEN - Encoded Header 1: eyJhbGciOiAiRVMyNTYiLCJwcHQiOiAic2hha2VuIiwidHlwIjogInBhc3Nwb3J0IiwieDV1IjogImh0dHBzOi8vY2VydGlmaWNh dGVzLmNsZWFyaXAuY29tL2IxNWQ3Y2M5LTBmMjYtNDZjMi04M2VhLWEzZTYzYTgyZWMzYS83Y2M0ZGI2OTVkMTNlZGFkYTRkMWY5ODYxYjliODBmZS5jcnQifQ May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 230 May 10 09:09:42 kamailio1 kamailio[153201]: INFO: {1 10 INVITE 1-1966540(a)10.20.0.1} <script>: HANDLE_STIRSHAKEN - Encoded Header 2: eyJhdHRlc3QiOiAiQSIsImRlc3QiOiB7InRuIjogWyIxNDA0NTI2NjA2MCJdfSwiaWF0IjogMTU0ODg1OTk4Miwib3JpZyI6IHsi dG4iOiAiMTgwMDEyMzQ1NjcifSwib3JpZ2lkIjogIjNhNDdjYTIzLWQ3YWItNDQ2Yi04MjFkLTMzZDVkZWVkYmVkNCJ9 However, when decoding both values: xlog("L_INFO", "HANDLE_STIRSHAKEN - Decoded Header 1: $(var(header_1){s.decode.base64})"); xlog("L_INFO", "HANDLE_STIRSHAKEN - Decoded Header 2: $(var(header_2){s.decode.base64})"); only $var(header_2) gets decoded: May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 38 May 10 09:09:42 kamailio1 kamailio[153201]: INFO: {1 10 INVITE 1-1966540(a)10.20.0.1} <script>: *HANDLE_STIRSHAKEN - Decoded Header 1:* May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 182 May 10 09:09:42 kamailio1 kamailio[153201]: INFO: {1 10 INVITE 1-1966540(a)10.20.0.1} <script>: *HANDLE_STIRSHAKEN - Decoded Header 2: {"attest": "A","dest": {"tn": ["14045266060"]},"iat": 1548859982,"orig": {"tn": "18001234567"},"origid": "3a47ca23-d7ab-446b-821d-33d5deedbed4"}* As you can veri And to ease debugging, I have isolated the line that generates the issue: May 10 09:09:42 kamailio1 kamailio[153201]: INFO: {1 10 INVITE 1-1966540(a)10.20.0.1} <script>: HANDLE_STIRSHAKEN - Parsing! May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 *May 10 09:09:42 kamailio1 kamailio[153201]: ERROR: {1 10 INVITE 1-1966540(a)10.20.0.1 <1-1966540(a)10.20.0.1>} <core> [core/lvalue.c:351]: lval_pvar_assign(): non existing right pvar* *May 10 09:09:42 kamailio1 kamailio[153201]: ERROR: {1 10 INVITE 1-1966540(a)10.20.0.1 <1-1966540(a)10.20.0.1>} <core> [core/lvalue.c:411]: lval_assign(): assignment failed at pos: (21,32-21,64)* May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/parser/msg_parser.c:324]: parse_headers(): flags=ffffffffffffffff May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 34 May 10 09:09:42 kamailio1 kamailio[153201]: DEBUG: {1 10 INVITE 1-1966540(a)10.20.0.1} <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 27 May 10 09:09:42 kamailio1 kamailio[153201]: INFO: {1 10 INVITE 1-1966540(a)10.20.0.1} <script>: HANDLE_STIRSHAKEN - Parsed! Even though the $var(header_1) contains a base64 encoded string, the decoder seems to fail. If I copy the value contained in $var(header_1) to an online decoder like https://www.base64decode.org/ the string gets decoded correctly. I have even modified the line : $var(header_1)= $(hdr(Identity){s.select,0,.}); to get the reverse index from the Identity string by doing $var(header_1)= $(hdr(Identity){s.select,-6,.}); It gets the same encoded string, same value (as expected), but the result is the same: Kamailio's s.decode.base64 fails with the same error. i'm not sure what assignment failed at pos: (21,32-21,64) could mean.... I don't think my code is wrong, as the same function is used on $var(header_2) value and it works, but maybe someone can correct me. Greatly appreciate your help. Cheers, *Sérgio Charrua* [View Less]

1 1

Failover with dialog dmq while dialog state 2
by Björn Klasen 09 May '24

09 May '24

Hello @all as we want to enhance our VoIP-Plattform with DMQ functionalities for replication of Userlocation, Dialog and Hash Tables I made a lot of tests durings the last week. For testing I use two Debian 12 Server with Kamailio 5.7.4 (latest git) Both server have their own floating IP so in case one server fails the floating changes to the working server. This is done via keepalived On both servers Kamailio is active and use ip_free_bind=1 so both Kamailio instances can listen to all … [View More]necessary IPs. So we have following network configuration: Server1: static IP: 192.168.253.201 floating IP: 192.168.253.200 Server2: static IP: 192.168.253.202 floating IP: 192.168.253.210 Now I test some calls while I trigger a failover, so Server1 takes over 192.168.253.10 Message Test Result CustomerA -> Proxy -> CustomerB Failover while Dialogstate 4 BYE is relayed correctly. Dialog is changing to state 5 CDR needs to be written manually -> no problem at all CustomerA -> Proxy -> CustomerB Failover while Dialogstate 2 200 OK is relayed correctly although no transaction exist an therefore no t_reply route is triggered. This is not a big deal because i can use default onreply_route so all necessary variables can be used via hash table. BUT Big Problem: Dialog state stays 2, so a following ACK is a bogus event and the dialog state is never changed to 4. Even worse: after 300 seconds the dialog is cleaned away by the timer, so I have no chance to do any kind of accounting. Test 2 is a real mess, because for me there is only one solution. I have to check after a failover on incoming replies to an INVITE that was handled on Server2 if these current dialog state is < 4 and cancel them. But I can't see how to do it? Are there other ways than using t_cancel? Or is it even some kind of a bug that a 200 OK does not trigger state 3 on dialog (although I have in mind that it has to be something to do with missing transaction data, that are not replicated because of missing replication capabilities of tm module)? If none of the above is possible I really asking myself of a real use case of dialog dmq replication. -- Björn Klasen, Teamleitung NGN VoIP-Backbone 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 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. ______________________________________________________________________ [View Less]

2 1

How to set "set_dialog_profile" value for Leg-a and leg-b.
by satyaprakash ch 09 May '24

09 May '24

Hi, We are using kamailio and freeswitch, So when we make a call from A to B the call is going via "kamailio -> freeswitch" and "freeswitch -> kamailio". Please suggest me how i can set "set_dialog_profile" for both legs with unique value in kamailio config file. Thanks.

1 0

Is there any way to modify the Refer-To header username?
by Shah Hussain Khattak 09 May '24

09 May '24

Hello Experts, I wanted to check, is there any way to modify the username part of the Refer-To header in Kamailio? For example, I am getting the following header: REFER-TO: <sip:sip.abc.domain.com:5061;transport=tls; ..... ; .... ; ...> the username part is missing. Can I add a username inside it? For example, change it to REFER-TO: <sip:123@sip.abc.domain.com:5061;transport=tls; ..... ; .... ; ...> REFER-TO: <sip:test-kam@sip.abc.domain.com:5061;transport=tls; ..... ; .... ;… [View More]

2 2

rtpengine timestamp jumps
by Jeff Brower 09 May '24

09 May '24

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: : … [View More] : 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 [View Less]

1 0

Kamailio v5.7.5 Released
by Daniel-Constantin Mierla 08 May '24

08 May '24

Hello, Kamailio SIP Server v5.7.5 stable release is out. This is a maintenance release of the latest stable branch, 5.7, that includes fixes since the release of v5.7.4. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.7.x. Deployments running previous v5.7.x versions are strongly recommended to be upgraded to v5.7.5. For more details about version 5.7.5 (including links and guidelines to download the tarball or … [View More]

1 0

Releasing v5.7.5
by Daniel-Constantin Mierla 08 May '24

08 May '24

Hello, I am considering to release Kamailio v5.7.5 (out of branch 5.7) on Wednesday, May 8, 2024. If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

1 1

sql_query fails from event_route
by Juha Heinanen 07 May '24

07 May '24

I noticed that sql_query does not (anymore) work when called from event route: event_route [tcp:closed] { # Handle TCP connection close # Delete possible leftover registration if ($conid) sql_query("sip_proxy_cache", "DELETE FROM location WHERE server_id=0 AND connection_id=$conid", "result"); } The query produces errors: 2024-05-07T11:30:14.785915+03:00 siika /usr/bin/sip-proxy[2848078]: CRITICAL: sqlops [sqlops.c:213]: sql_check_connection(): no database handle with … [View More]

2 3

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