- sr-users - kamailio.org

$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

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 w_auth_algorithm(struct sip_msg *msg, char *alg, char* s2); static int pv_proxy_authenticate( struct sip_msg *msg, char *realm, char *passwd, char *flags); @@ -170,6 +174,8 @@ static cmd_export_t cmds[] = { REQUEST_ROUTE}, {"pv_auth_check", (cmd_function)w_pv_auth_check, 4, fixup_pv_auth_check, 0, REQUEST_ROUTE}, + {"auth_algorithm", w_auth_algorithm, 1, fixup_spve_null, 0, + REQUEST_ROUTE}, {"bind_auth_s", (cmd_function)bind_auth_s, 0, 0, 0}, {0, 0, 0, 0, 0, 0} @@ -475,6 +481,35 @@ int w_has_credentials(sip_msg_t *msg, char *realm, char *s2) return -1; } return ki_has_credentials(msg, &srealm); + +} +/** + * + */ +int w_auth_algorithm(sip_msg_t *msg, char* alg, char* s2) +{ + if (fixup_get_svalue(msg, (gparam_t*)alg, &auth_algorithm) < 0) { + LM_ERR("failed to get algorithm value\n"); + return -1; + } + + if (strcmp(auth_algorithm.s, "MD5") == 0) { + hash_hex_len = HASHHEXLEN; + calc_HA1 = calc_HA1_md5; + calc_response = calc_response_md5; + } + else if (strcmp(auth_algorithm.s, "SHA-256") == 0) { + hash_hex_len = HASHHEXLEN_SHA256; + calc_HA1 = calc_HA1_sha256; + calc_response = calc_response_sha256; + } + else { + LM_ERR("Invalid algorithm provided." + " Possible values are \"\", \"MD5\" or \"SHA-256\"\n"); + return -1; + } + + return 1; } #ifdef USE_NC

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

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

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

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

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 reconnect disabled 2024-05-07T11:30:14.785978+03:00 siika /usr/bin/sip-proxy[2848078]: ERROR: sqlops [sqlops.c:232]: sql_query(): invalid connection to database 2024-05-07T11:30:14.786013+03:00 siika /usr/bin/sip-proxy[2848078]: ERROR: sqlops [sqlops.c:237]: sql_query(): with query [DELETE FROM location WHERE server_id=0 AND connection_id=7] I added the last debug message in order to find out where the error comes from. The same query works fine when executed from regular route. Any ideas why the query fails from event_route? -- Juha

2 3

How to use environment variable
by Pavan Kumar 07 May '24

07 May '24

Hi everyone, I am trying to assign environment variable as follows listen=udp:0.0.0.0:5060 advertise $env(MY_IP):5060 Looks like using the environment variable as above is an invalid configuration. Is there a way to use IP from env var to advertise. Even better, is there a way to use result in a stun query as an advertised address? Thank you, Pavan Kumar

2 3

Retransmission behaviour after ACK
by Sergio Charrua 06 May '24

06 May '24

Hi all! I'm testing some redirect scenarios with Kamailio 5.7.4 and using Astterisk 13 and SIPp for unit testing. The kamailio's script is simple and uses TM, HTTP_ASYNC_MODULE, JSONRPC, JANSSON, RTJSON and XLog modules. Request route is simple: request_route { route(HANDLE_OPTIONS); route(HANDLE_RETRANS); route(HANDLE_CANCEL); route(REQINIT); route(HANDLE_INVITE); } where HANDLE_RETRANS is: route[HANDLE_RETRANS]{ # handle retransmissions xlog("L_INFO","HANDLE_RETRANS - message type is $mt for method $rm"); if (!is_method("ACK")) { if(t_precheck_trans()) { xlog("L_INFO","HANDLE_RETRANS - Precheck Trans"); t_check_trans(); xlog("L_INFO", "HANDLE_RETRANS - Exiting after Retransmission check - method $rm"); exit; } xlog("L_INFO","HANDLE_RETRANS - Check Trans"); t_check_trans(); } } and HANDLE INVITE is: route[HANDLE_INVITE]{ if (is_method("INVITE")) { xlog("L_INFO","MAIN - calling TO_CARRIER"); setflag(FLT_ACC); route(TO_CARRIER); exit; } } The HTTP requests call a REST API returning a JSON object, that is iterated and produces a CONTACT header containing multiple choices using the append_branch() command. The RELAY route is : route[RELAY] { # Sends a 300 Multiple Choices back to the proxy that requested the routing lookup xlog("L_INFO","REPLY_302 - send reply"); send_reply("300", "Multiple Choices"); xlog("L_INFO","REPLY_302 - exit"); exit; } Which returns indeed a Contact header with multiple contact choices. When using Asterisk to originate a call to Kamailio, the SIP call flow is as follows and terminates (SNGrep and TCPDump do not detect anything else): SRC DST INVITE (SDP) ──────────────────────────> 100 trying -- your call is <────────────────────────── 300 Multiple Choices <────────────────────────── ACK ──────────────────────────> However when using SIPp I get some retransmissions after the final ACK. SRC DST INVITE (SDP) ──────────────────────────> 100 trying -- your call is <────────────────────────── 300 Multiple Choices <────────────────────────── ACK ──────────────────────────> 300 Multiple Choices <<<──────────────────────── 300 Multiple Choices <<<──────────────────────── 300 Multiple Choices <<<──────────────────────── SIPp scenario is : <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE scenario SYSTEM "sipp.dtd"> <scenario name="Basic Sipstone UAC">   <send retrans="500" start_rtd="true" rrs="true"> <![CDATA[ INVITE sip:[call_number]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Max-Forwards: 70 From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: <sip:[call_number]@[remote_ip]:[remote_port]> Contact: sip:sipp@[local_ip]:[local_port];transport=[transport]> Call-ID: [call_id] CSeq: 102 INVITE User-Agent: SIPp Supported: replaces, timer Content-Type: application/sdp Subject: Performance Test Session-Expires: 3600;refresher=uas Content-Length: [len] v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=SIPp c=IN IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000 ]]> </send> <recv response="100" rss="true"> </recv> <recv response="300" rtd="true" rss="true"> <action> <ereg regexp="\<([a-zA-Z0-9@.=;]+)[^>]+" search_in="hdr" header="Contact: " assign_to="1"/> <log message="INFO: 300 Contact Header: [$1]" /> <exec command="echo [$1] >> ./300_ContactHeader.txt" /> </action> <action> <ereg regexp="sip:.*@([0-9A-Za-z\.]+):([0-9]+);transport=([A-Z]+)" search_in="hdr" header="Contact:" check_it="true" assign_to="dummy,host,port,transport" /> </action> </recv>   <send rrs="true"> <![CDATA[ ACK sip:[call_number]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Max-Forwards: 70 From: <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: <sip:[call_number]@[remote_ip]:[remote_port]>[peer_tag_param] Contact: <sip:sipp@[local_ip]:[local_port]> Call-ID: [call_id] CSeq: 102 ACK User-Agent: SIPp Content-Length: 0 ]]> </send>   </scenario> The question is : is there anything wrong with my kamailio script? or with SIPp scenario? why does kamailio have different behaviours between Asterisk and SIPp? Any option to disable retransmissions on Kamailio ? (using UDP) Thanks in advance, *Sérgio Charrua*

2 3

topos with mask_callid
by Marrold 05 May '24

05 May '24

Hi all, I am using Kamailio 5.8.1 on a Debian 12 machine with topos and topoh hiding the topology. I have observed with modparam("topos", "mask_callid", 1), in-dialog requests are relayed with the incorrect caller-id. In the scenario, A calls B. The call is set up and the call-id for the B-Leg is successfully masked. Then, when A sends a BYE, the BYE is incorrectly relayed to B with the call-id of the A leg, and B replies with a 481 If I disable masking the call-id, or disable topos/topoh entirely, everything looks and works as it should. I have tested with 5.7.4 and the behaviour is the same. Does anyone have any ideas for where I should start looking? Thanks Matthew

1 0

Re: IMS SCSCF redundancy
by Oleg Belousov 03 May '24

03 May '24

Hi. I have a question re: IMS SCSCF redundancy.:There are several SCSCF instances, registration happens via SCSCF1, it goes down after that. UE make MO call.. PCSCF resolves the common SCSCF fqdn and sends an invite to available SCSCF2 which does not have UE profile as well as AS address (which is received during registration SAR/SAA in iFC). There are 2 options here, either to release the call (as per 3gpp spec upon specific release code, eg 408/503 UE should perform re-registration - not happen in our case unfortunately), or to send request for iFC (suspend the call, fire SAR, receive SAA, check available services, etc) and upon success continue the call (to AS first)/ Lke IMS Registrar SCSCF save function, but for the invite. To continue the call without interaction with AS is not a good idea.. Any advice or workaround on how to achieve desired SCSCF redundancy ? -- obelousov.tel

1 0

http_async_client and sl_send_reply()
by Masud Muborakshohi 02 May '24

02 May '24

Hello! I have a problem when sending a response sl_send_reply("415", "The other party does not support video calling!"); in route[HTTP_REPLY]. When I make a request using http_async_query() to send a push notification to a mobile device, I need to process the response from the push server and respond with a SIP message to the client. Before sending the request I do $http_req(suspend) = 0; What am I doing wrong? Why are $fU and $ru equal to null ? #processing HTTP responses route[HTTP_REPLY] { if ($http_ok && $http_rs == 200) { xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n"); xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n"); } else if($http_rs == 415 || $http_rs == "415") { xlog("L_ERR", "route[HTTP_REPLY]: caller: $fU phone: $ru error: $http_err)\n"); send_reply("415", "The other party does not support video calling!"); } else { xlog("L_ALERT", "route[HTTP_REPLY]: error $http_err)\n"); } #exit; }

3 5

No ACK from Kamailio
by Arseniy Moskvich 02 May '24

02 May '24

Hi everyone. We are new to Kamailio and using Kamailio 5.8 with FreeSwitch. We have the issue with the incoming call from our provider. They are dropping after 30 seconds. The client doesn't receive ACK from Kamailio. But FreeSwitch sends ACK to Kamailio. The outbound call is working fine. At the moment flow is our provider -> FreeSwitch -> Kamailio -> our web client. Could someone give us some directions please? Please find attached Kemi.py. Thank you so much in advance

2 2

Kamailio works but voice is not present during the calls!
by christian.marinelli＠hotmail.it 02 May '24

02 May '24

Hi all, i have a problem with my Kamailio SIP Server. I set up a Kamailio SIP server in a virtual machine on a private network and i connect to this with a WireGuard VPN. The problem is that i can connect to the SIP server throught different clients and users and i can call the other users, the devices ring and i can answer to the calls but unfortunatly there is no audio during the call :( I can't understand why, it seems all si OK, a year ago i set up another SIP server with the same configuration and all works correctly with it. Can anyone help me to understand why? I can copy and paste here all the config files if you need it. Thank you so much in advance Christian

8 29

AEM Implementation Services,
by surekhatech.seo＠gmail.com 02 May '24

02 May '24

As an Official Adobe Bronze Solution Partner, we specialize in AEM development services, consulting, implementation, migration, and cloud services for your business.

1 0

Question: if SIP Timer L and Timer M from RFC6026 has been defined at Kamailio
by jennifer yang 02 May '24

02 May '24

Hello Can anyone help answer these questions: - if SIP Timer L and Timer M from RFC6026 has been defined at Kamailio (version v5.5.x)? Timer L: Wait time for accepted INVITE request retransmits Timer M: Wait time for retransmission of 2xx to INVITE or additional 2xx from other branches of a forked INVITE - if no specific Timer defined, which timer will be used instead? thanks br jenni

1 0

Issue with serial call forking to same destination
by Mathias 30 Apr '24

30 Apr '24

Hi I've an issue with serial call forking and I hope somebody can help me... What I'm trying to reach: We are using Kamailio in a dynamic network with multiple nodes. The dialplan is implemented using the KEMI interface. The call routing is completely dynamic. At the moment, we are having call groups, which may contain 1 or more recipients. If the number of this call group is called, Kamailio is doing a parallel forking to all group participants. Now I'm trying to extend the feature, that if nobody hooks up, the call is forwarded to another number. This has been implemented with serial forking. So the dialplan adds branches for all call group members with a q value of 1 and the last branch is the failover number with a lower q value. The branching and failure route works fine. The problem: * I have a call group (G Bob 900101), with one participant (Bob 200102). * The group has a fail over number (if Bob doesn't hook up), which points again to Bob. I know that this use case doesn't make much sense, but it has been simplified to show the problem. The failover number can be anything also another call group which may contain one or more recipients from the first group again. * Alice (200101) calls the call group * The first node (10.0.1.1/10.64.0.1) receives the call and forks it to branch 1 Bob (202102) with q value 1.0 and to a second branch Bob (202102) with q value 0.5. fr_timer is set to 10s * The call is forwarded to node 2 (10.0.2.1/10.64.0.2), where Bob is registered. * The call is forwarded to Bobs device (Grandstream GXV3350) and the phone is ringing. * After 10s, the first node detects the 408 Request Timeout and switches to the second branch * The invite is sent to node 2 and Bobs device again. * Node 1 also sends a CANCEL to node 2 and Bobs device for the first branch. * The call in Bobs device is terminated * Now the problem, the device does not react to the second INVITE. And after the fr_inv_timer expires, the call is terminated with a 408 Request Timeout. I can see that the second INVITE contains another branch ID <ID>.1 compared to the first INVITE, which had <ID>.0. The CANCEL is also sent with <ID>.0. I've also tried with a Cisco 8861 3PCC and it doesn't work either. Compared to the Grandstream, the Cisco device returns an error 500 upon the second INVITE. Since both devices do not accept what I'm trying, I guess I'm doing something wrong... At the moment I'm a bit lost, what the problem could be. Does somebody have an idea what it is and how I could solve it? Following two SIP dumps from node 1 and node 2: Node 1: |Time | 10.0.1.128 | 10.64.0.1 | | | | 10.0.1.1 | | 10.0.2.1 | |2024-01-31 14:17:07.792784| INVITE SDP (g711A g7 | | |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> Call-ID:2102072978-5060-296@BA.A.B.BCI CSeq:2950 | |(47276) ------------------> (5061) | | | |2024-01-31 14:17:07.793060| 407 Proxy Authentica | | |SIP Status 407 Proxy Authentication Required | |(47276) <------------------ (5061) | | | |2024-01-31 14:17:07.796613| ACK | | | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2950 | |(47276) ------------------> (5061) | | | |2024-01-31 14:17:07.799045| INVITE SDP (g711A g7 | | |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> Call-ID:2102072978-5060-296@BA.A.B.BCI CSeq:2951 | |(47276) ------------------> (5061) | | | |2024-01-31 14:17:07.836471| 100 trying -- your c | | |SIP Status 100 trying -- your call is important to us | |(47276) <------------------ (5061) | | | |2024-01-31 14:17:07.865219| | | INVITE SDP (g711A g7 |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:08.036334| | | 100 trying -- your c |SIP Status 100 trying -- your call is important to us | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:08.084421| | | 180 Ringing |SIP Status 180 Ringing | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:08.096834| 180 Ringing | | |SIP Status 180 Ringing | |(47276) <------------------ (5061) | | | |2024-01-31 14:17:18.099644| | | INVITE SDP (g711A g7 |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:18.100099| | | CANCEL | |SIP CANCEL From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:18.259375| | | 100 trying -- your c |SIP Status 100 trying -- your call is important to us | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:18.274841| | | 200 canceling |SIP Status 200 canceling | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:18.296942| | | 487 Request Terminat |SIP Status 487 Request Terminated | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:18.298630| | | ACK | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:20.281602| | | 408 Request Timeout |SIP Status 408 Request Timeout | | | |(5061) <------------------ (5061) | |2024-01-31 14:17:20.283433| | | ACK | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5061) | |2024-01-31 14:17:20.307343| 408 Request Timeout | | |SIP Status 408 Request Timeout | |(47276) <------------------ (5061) | | | |2024-01-31 14:17:20.309097| ACK | | | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:<sips:900101@10.0.1.1:5061> CSeq:2951 | |(47276) ------------------> (5061) | | | Node 2: |Time | 10.64.0.1 | 10.64.0.2 | | | | 10.0.2.1 | | 10.0.2.128 | |2024-01-31 14:17:07.869305| INVITE SDP (g711A g7 | | |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> Call-ID:2102072978-5060-296@BA.A.B.BCI CSeq:2951 | |(54454) ------------------> (5061) | | | |2024-01-31 14:17:08.036009| 100 trying -- your c | | |SIP Status 100 trying -- your call is important to us | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:08.050848| | | INVITE SDP (g711A g7 |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5060) | |2024-01-31 14:17:08.054357| | 100 Trying| | |SIP Status 100 Trying | | |(5061) <-------------------------------------- (5060) | |2024-01-31 14:17:08.075422| | 180 Ringing | |SIP Status 180 Ringing | | |(5061) <-------------------------------------- (5060) | |2024-01-31 14:17:08.083887| 180 Ringing | | |SIP Status 180 Ringing | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:18.100359| INVITE SDP (g711A g7 | | |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> Call-ID:2102072978-5060-296@BA.A.B.BCI CSeq:2951 | |(54454) ------------------> (5061) | | | |2024-01-31 14:17:18.258947| 100 trying -- your c | | |SIP Status 100 trying -- your call is important to us | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:18.273819| | | INVITE SDP (g711A g7 |SIP INVITE From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5060) | |2024-01-31 14:17:18.274460| CANCEL | | | |SIP Request CANCEL CSeq:2951 | |(54454) ------------------> (5061) | | | |2024-01-31 14:17:18.274550| | | CANCEL | |SIP CANCEL From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5060) | |2024-01-31 14:17:18.274615| 200 canceling | | |SIP Status 200 canceling | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:18.277438| | 200 OK | | |SIP Status 200 OK | | |(5061) <-------------------------------------- (5060) | |2024-01-31 14:17:18.279335| | 487 Request Terminated | |SIP Status 487 Request Terminated | | |(5061) <-------------------------------------- (5060) | |2024-01-31 14:17:18.280785| | | ACK | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | | | |(5061) ------------------> (5060) | |2024-01-31 14:17:18.296312| 487 Request Terminat | | |SIP Status 487 Request Terminated | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:18.298900| ACK | | | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | |(54454) ------------------> (5061) | | | |2024-01-31 14:17:20.280965| 408 Request Timeout | | |SIP Status 408 Request Timeout | |(5061) <------------------ (5061) | | | |2024-01-31 14:17:20.283730| ACK | | | |SIP ACK From: "Alice" < sips:200101@10.0.1.1:5061> To:"Bob" <sips:900101@10.0.1.1:5061> CSeq:2951 | |(54454) ------------------> (5061) | | | At the moment, I'm using Kamailio 5.5.4, but I also did a short try with a newer version (I guess it was 5.7.4). Both versions showed the same issue. Best regards Mathias

1 0

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