May 2024 - sr-users - kamailio.org

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

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

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

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

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

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 challenge. My rtpengine seems to be working fine . Below is my Kamailio.cfg file link : https://docs.google.com/document/d/1MKZJGlQjxYbdtw6QcCm9_EmvVPOkMs-YXjlq1ZM2 mmY/edit?usp=drive_link PCAP file for the call: https://docs.google.com/document/d/12gofLYhN0-lYIZORngIeuaYxLudLjiNdZgY504Ei XFs/edit?usp=drive_link rtpengine.conf https://docs.google.com/document/d/1QPxey49UzuN3Wd8jp8jc0mFhh31rr1alIO-gl4gP JEI/edit?usp=drive_link Please help.

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

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 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. ______________________________________________________________________

2 1