sr-users May 2024

sr-users@lists.kamailio.org

50 participants
60 discussions

by tfayomi＠untangledtechnology.com

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

6 months, 1 week

Prefix match in htable

by Antonio Reale

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

6 months, 1 week

Kamailio and RTPengine and no voice on calls

by palany

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.

6 months, 2 weeks

base64 decoding issue

by Sergio Charrua

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*

6 months, 2 weeks

Failover with dialog dmq while dialog state 2

by Björn Klasen

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

6 months, 2 weeks

How to set "set_dialog_profile" value for Leg-a and leg-b.

by satyaprakash ch

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.

6 months, 2 weeks

Is there any way to modify the Refer-To header username?

by Shah Hussain Khattak

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; ..... ; .... ; ...> I could not find any solution in the mailing list, the only way was to remove the header and then re-add it. Thank you! Regards, Shah Hussain

6 months, 2 weeks

rtpengine timestamp jumps

by Jeff Brower

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

6 months, 2 weeks

Kamailio v5.7.5 Released

by Daniel-Constantin Mierla

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 from GIT repository), visit: * https://www.kamailio.org/w/2024/05/kamailio-v5-7-5-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note that 5.7.x is currently the previous stable release series, the latest is 5.8.x and v5.8.1 was released on April 3, 2024. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

6 months, 2 weeks

Releasing v5.7.5

by Daniel-Constantin Mierla

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

6 months, 2 weeks

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