sr-users

sr-users@lists.kamailio.org

36 participants
37510 discussions

Function sdp_get gets extra blank line (when MIME is used)
by James Browne 05 Nov '24

05 Nov '24

The sdp_get() function from sdpops returns an extra blank line sometimes, which looks like a bug to me. When I have an SDP that's in MIME, there's an extra newline at the end of the extracted SDP. Here's a sample config. I use 5.8.1 for testing. #################### #!KAMAILIO listen=udp:203.0.113.57:5060 debug=1 loadmodule "sdpops" loadmodule "pv" loadmodule "xlog" request_route{exit;} reply_route { sdp_get("$avp(sdp)"); xlog("L_NOTICE", "[$ci] The SDP is [$avp(sdp)].\n"); } #################### Here are two sample SIP-message bodies. #################### v=0 o=PCD 1730 1730 IN IP4 198.18.114.148 s=PCD c=IN IP4 198.18.114.148 t=0 0 m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 #################### #################### --e61e7a6a-16a2-46c0-adbb-a41ba86d32a2 Content-Type: application/sdp Content-Length: 130 v=0 o=PCD 1730 1730 IN IP4 198.18.114.148 s=PCD c=IN IP4 198.18.114.148 t=0 0 m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --e61e7a6a-16a2-46c0-adbb-a41ba86d32a2-- #################### When the first body is received, the xlog correctly ends with this. m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ] with length 130 When the second body is received, the xlog incorrectly ends with this, which has an extra newline in it. m=audio 29426 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ] with length 132 According to RFC2046, "The CRLF preceding the boundary delimiter line is conceptually attached to the boundary", but it looks like kamailio has a bug that incorrectly processes this. James

2 2

Simultaneous INVITE responses from multiple branches
by Anton Yabchinskiy 04 Nov '24

04 Nov '24

Hello, In our system we've encountered the following situation. There's a Kamailio proxy and a few REGISTER'ed devices behind the proxy. When there's an INVITE to these multiple devices, two of them simultaneously answer the call. Kamailio proxy accepts the first 200 OK from one of the devices and tries to CANCEL all other branches. But the second 200 OK device have already responded OK and doesn't acknowledge the CANCEL. So, there's now one established dialog with media, and another "established" one neither having media nor being correctly terminated. Looks like the similar scenario is described in section 3.1.2 of RFC 5407 (Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)). Is it possible to mitigate such scenarios in a Kamailio proxy? E.g., is it possible to send an additional BYE to these CANCEL'led branches? In current configuration, Kamailio proxy retrieves contacts with registrar:lookup() and does parallel forking with tm:t_relay().

2 2

Re: Dealing with flood of invalid SIP messages
by Juha Heinanen 04 Nov '24

04 Nov '24

I gave APIBAN a try. After a few days, no requests were banned by APIBAN, but during the same period, lots of request were banned by other checks in my config. That made me wonder if APIBAN really is effective. -- Juha

2 3

Error opening Kamailio's FIFO /run/kamailio/kamailio_rpc.fifo
by matilopi17＠gmail.com 01 Nov '24

01 Nov '24

Hello, This is kamailio version 5.8.2 and we`re having this issue every now and then. The error displayed is: ** ERROR: Error opening Kamailio's FIFO /run/kamailio/kamailio_rpc.fifo ** ERROR: Make sure you have loaded the jsonrpcs module and set FIFO transport parameters The problem is that the FIFO file /run/kamailio/kamailio_rpc.fifo doesn't exist, even though the "jsonrpc" module is in the Kamailio configuration, and the file is created when Kamailio service is restarted. But as mentioned, after few days the issue is repeated. I`ll appreciate any suggestion or advice of what I should check. Thank you!

4 5

Failed to parse the R-URI with topoh enabled
by Ale 29 Oct '24

29 Oct '24

Hi All, I think I have a problem with topoh, but I can't identify it. Kamailio 5.6.6, used as a stateless proxy, receives a 487 from a phone and propagates it correctly. Next comes the ack that should be forwarded back to the phone, but instead it doesn't forward it and produces the following error "pv_get_ruri(): failed to parse the R-URI" The error is generated by xlog("...$ru from $fu...\n"") as first line of request_route. If I disable topoh everything works perfectly.Topoh is only configured with mask_key only. Furthermore, not all phones generate this problem, at the moment there are some snoms. ACK sip:user@phone_ip:2048;line=kkqgarrj SIP/2.0 Via: SIP/2.0/UDP proxy_sip_ip;branch=z9hG4bK2ec.e7126a3134bef9d974f57dd43ebd4ea2.0 Route: <sip:kamailio_ip:5060;lr;received=sip:phone_ip:2048> Max-Forwards: 66 From: <sip:111111111@sip.example.com>;tag=pDc1BQ0B57Ujj To: <sip:user@sip.example.com>;tag=vslvowy4y2 Call-ID: 40a6c905-c0c8-4c20-b3f7-397b3fce58b6 CSeq: 90285584 ACK Content Length: 0 There is no difference between the ACK of the snom and other phones that work. The only difference I noticed is that the snom 487 contains Contact field in the header. Any suggestions? Thank you

3 5

How to handle e2e ACK with t_check_trans()
by Benoit Panizzon 28 Oct '24

28 Oct '24

Hi List To correctly route ACK belonging to a transaction (totag) the example code does: if ( is_method("ACK") ) { if ( t_check_trans() ) { route(RELAY); exit; } else { xlog("L_INFO", "$cfg(route): $rm NOT loose route NO transaction found DROP\n"); exit; } } Unfortunatels I fear that in a parallell forking scenario, the transaction is remove from memory as soon as the first 'negative' ACK is being processed so that the end 2 end ACK to the 200 OK of the branch that connected the call, never makes it through. I attempted to increase wt_timer to 10000 to have the transaction stay around 10 seconds but that does not solve the issue. I read that t_check_trans()'s result shall be considered more as a hint than as a confirmation of an existing transaction. Is there a clean / secure way to process e2e ACK and make sure they belong to a transaction? Or can I just safely remove the t_check_trans() call and route any ACK with a totag? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 3

Dealing with flood of invalid SIP messages
by mayamatakeshi 27 Oct '24

27 Oct '24

Hi, I was going through some old company tickets that I am assigned to and found a case when possibly an attacker flooded our kamailio server with invalid sip messages like this: 2019-04-27T20:14:05.533554+09:00 IPX051 /usr/local/src/git/sip-router/kamailio[1732]: ERROR: <core> [parser/msg_parser.c:714]: ERROR: parse_msg: message=<[F#016sD#026Z<8D>97<F8><B5>;<A9><E7>-<D2>(<E2><F6> v;/#021k\<CC>8<B1>λ<F4>#004M<B6><BE><EC>#035#003<94><E1>=<A0><FF><E3><AF>Kwzr<8B>A#036B<D7>#027#023cu<82>Y<D4>#037<FB><AC>S_<C4>Qg<AB><DE>F<88>I#006<8C><FA><F4>~#y3G<C7>H<80>b<BC><AD>#035<89>#002<DB><C8>#001U<9E>#007<CB><F9>nT<E5><EE><8E><F1>#0144> At that time we manually banned the IP. But it would be helpful to have this done automatically by fail2ban. So I was thinking this log should include the src IP address. I looked at the latest kamailio commit and core/parser/msg_parser.c does this log the same way so I was thinking in opening an issue for this. But maybe this should be dealt with differently. Any ideas?

4 6

Issue with Retrieving Kamailio Statistics: Missing FIFO File and Errors
by satyaprakash ch 25 Oct '24

25 Oct '24

Hi, I'm encountering an issue while trying to retrieve Kamailio statistics on the server using the command kamctl stats. Instead of the expected output, I am receiving the following errors: kamctl stats: -e \E[37;31mERROR: Error opening Kamailio's FIFO /run/kamailio/kamailio_rpc.fifo -e \E[37;31mERROR: Make sure you have loaded the jsonrpcs module and set FIFO transport parameters Additionally, the file /run/kamailio/kamailio_rpc.fifo does not exist. Could you please provide suggestions ?

3 4

Handeling error returned by rtpengine_manage(...)
by Wolter Eldering 23 Oct '24

23 Oct '24

Hello, I have a question about the rtpengine module and how to use it via KEMI/python. Will processing of the native script stop when rtpengine_manage returns with an error? Or will it continue and will the SDP be forwarded unchanged? #!ifdef WITH_RTPENGINE if(nat_uac_test("8")) { rtpengine_manage("SIP-source-address replace-origin replace-session-connection"); } else { rtpengine_manage("replace-origin replace-session-connection"); } #!else Regards, Wolter

3 4

Kamailio not deleteing rtp sessions
by Tihomir Culjaga 22 Oct '24

22 Oct '24

Hello, I'm using Kamailio + RTPEngine. Everything works well except one thing. I noticed rtp sessions are not being deleted after call termination. Instead, they remain lingering on RTPEngine waiting for a timeout. kamailio --version version: kamailio 5.5.2 (x86_64/linux) 55e232 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 55e232 compiled on 14:13:04 Aug 25 2021 with gcc 8.4.1 rtpengine --version Version: 9.5.1.1-1.el8 rtpengine-ctl list totals tells me every session went to timeout :) --- snip --- Total statistics (does not include current running sessions): Uptime of rtpengine :914 seconds Total managed sessions :51 Total rejected sessions :0 Total timed-out sessions via TIMEOUT :51 Total timed-out sessions via SILENT_TIMEOUT :0 Total timed-out sessions via FINAL_TIMEOUT :0 Total timed-out sessions via OFFER_TIMEOUT :0 Total regular terminated sessions :0 Total forced terminated sessions :0 --- snip --- I'm using rtpengine_manage in two routes "route[RELAY]" and onreply_route[MANAGE_REPLY] . Do I need to add a specific rtpengine_delete somewhere ? route[RELAY] { ... $xavp(r=>$T_branch_idx) = "replace-origin replace-session-connection"; if (!nat_uac_test("8")) { $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " trust-address"; } if (!has_totag()) { xlog("L_INFO", "NEXIOS: proto = [$proto], ru = [$ru]"); if ($proto =~ "ws" && !($ru =~ "transport=ws")) { xlog("L_INFO", "####################### FROM WS to any ########################\n"); $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP direction=external direction=internal"; } else if (!($proto =~ "ws") && $ru =~ "transport=ws") { xlog("L_INFO", "####################### FROM any to WS ########################\n"); setbflag(FLB_TOWEBRTC); $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-offer generate-mid DTLS=active SDES-off ICE=force RTP/SAVPF direction=internal direction=external"; } else if (($proto =~ "udp") && $ru =~ "transport=udp" && $fs =~ "MY_IP2_ADDR") { xlog("L_INFO", "####################### FROM ?? to ?? $ru ########################\n"); } } # we engage RTPEngine if (has_body("application/sdp")) { xlog("L_INFO", "NEXIOS: # $xavp(r=>$T_branch_idx) #\n"); rtpengine_manage($xavp(r=>$T_branch_idx)); } if (!t_relay()) { sl_reply_error(); } exit; } onreply_route[MANAGE_REPLY] { ... $xavp(r=>$T_branch_idx) = "replace-origin replace-session-connection"; if (!nat_uac_test("8")) { $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " trust-address"; } if (has_totag()) { xlog("L_INFO", "onreply_route proto = [$proto], ru = [$ru]"); if ($proto =~ "ws" && !($ru =~ "transport=ws")) { xlog("L_INFO", "onreply_route ####################### FROM WS to any ########################\n"); $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-demux DTLS=off SDES-off ICE=remove RTP/AVP direction=external direction=internal"; } else if (!($proto =~ "ws") && $ru =~ "transport=ws") { xlog("L_INFO", "onreply_route ####################### FROM any to WS ########################\n"); setbflag(FLB_TOWEBRTC); $xavp(r=>$T_branch_idx) = $xavp(r=>$T_branch_idx) + " rtcp-mux-offer generate-mid DTLS=active SDES-off ICE=force RTP/SAVPF direction=internal direction=external"; } else if (($proto =~ "udp") && $ru =~ "transport=udp" && $fs =~ "MY_IP2_ADDR") { xlog("L_INFO", "onreply_route ####################### FROM ?? to ?? $ru ########################\n"); } } if (has_body("application/sdp")) { xlog("L_INFO", "onreply_route # $xavp(r=>$T_branch_idx) #\n"); rtpengine_manage($xavp(r=>$T_branch_idx)); } } Any ideas are appreciated. Regards, Tihomir.

4 6

Jump to page:

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