sr-users

sr-users@lists.kamailio.org

42 participants
37453 discussions

Roadmap to v6.0.0 - the next major release
by Daniel-Constantin Mierla 07 Nov '24

07 Nov '24

Hello, about 8 months since the last major release v5.8.x, therefore it is the time to plan a bit the next steps for getting v6.0.0 out. The Kamailio Developers Meeting is schedule in Dusseldorf, Germany during November 19-20, 2024, where we expect to push out a consistent number of updates. Then maybe we can wait for another 2 weeks or so to settle down/finish those updates. After that, if no other new features are planned by developers in short term, we can enter the testing phase, so the new major version can be released during the second part of January 2025 or first part of February 2025. Therefore, if you have new features under development that might require more than 1-1.5 months from now, and you want to get them in v6.0.0, let us know to plan properly. Other time lines suggestions to get to v6.0.0 are also welcome! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

2 1

Kamailio 5.5.7 alias not added to ACK
by Mitesh Thakkar 06 Nov '24

06 Nov '24

Hi, I was using kamailio 5.2.5. I have recently upgraded to kamailio 5.5.7. After upgrade, the alias is stop being add to the ACK of reinvite from upstream. Before upgrade, it was working fine. I’ll appreciate any help on this. Thank you. Regards, Miteshkumar Thakkar

1 0

SNMP setup
by Sergio Charrua 05 Nov '24

05 Nov '24

Hi all! I am having difficulties setting up SNMP, and mostly to figure out if what I have setup is correctly configured. This is what I have on Kamailio (5.8.2), which is set as stateless and as a redirect server (simply put, it receives INVITE from SBC, gets a route from routing services, modifies Contact header, and replies to SBC with 300 Multi Choice with new contact header): loadmodule "db_mysql.so" loadmodule "db_cluster.so" loadmodule "http_client.so" loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "sl.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "jansson.so" loadmodule "snmpstats.so" loadmodule "file_out.so" loadmodule "ctl.so" loadmodule "permissions.so" loadmodule "xhttp.so" loadmodule "xhttp_rpc.so" # ---- SNMP Stats params ---- modparam("snmpstats", "sipEntityType", "proxyServer") modparam("snmpstats", "sipEntityType", "redirectServer") modparam("snmpstats", "sipEntityType", "other") modparam("snmpstats", "snmpgetPath", "/usr/bin/") modparam("snmpstats", "MsgQueueMinorThreshold", 1) modparam("snmpstats", "MsgQueueMajorThreshold", 1) modparam("snmpstats", "dlg_minor_threshold", 1) modparam("snmpstats", "dlg_major_threshold", 1) modparam("snmpstats", "snmpCommunity", "kamailio") I have set the *_minor_threshold values to bear minimum. Should I add anything else? The logs show the following messages: DEBUG: <core> [core/mem/q_malloc.c:402]: qm_malloc(): qm_malloc(0x7f03af1ff010, 60) called from snmpstats: snmp_statistics.c: get_socket_list_from_proto_and_family(185) DEBUG: <core> [core/mem/q_malloc.c:449]: qm_malloc(): qm_malloc(0x7f03af1ff010, 64) returns address 0x7f03af3bcc50 frag. 0x7f03af3bcc10 (size=64) on 1 -th hit DEBUG: <core> [core/mem/q_malloc.c:402]: qm_malloc(): qm_malloc(0x7f03af1ff010, 20) called from snmpstats: snmp_statistics.c: get_socket_list_from_proto_and_family(185) DEBUG: <core> [core/mem/q_malloc.c:449]: qm_malloc(): qm_malloc(0x7f03af1ff010, 32) returns address 0x7f03af3bcd00 frag. 0x7f03af3bccc0 (size=32) on 1 -th hit DEBUG: <core> [core/mem/q_malloc.c:515]: qm_free(): qm_free(0x7f03af1ff010, 0x7f03af3bcc50), called from snmpstats: snmp_statistics.c: get_total_bytes_waiting(464) DEBUG: <core> [core/mem/q_malloc.c:562]: qm_free(): freeing frag. 0x7f03af3bcc10 alloc'ed from snmpstats: snmp_statistics.c: get_socket_list_from_proto_and_family(185) DEBUG: <core> [core/mem/q_malloc.c:515]: qm_free(): qm_free(0x7f03af1ff010, 0x7f03af3bcd00), called from snmpstats: snmp_statistics.c: get_total_bytes_waiting(471) DEBUG: <core> [core/mem/q_malloc.c:562]: qm_free(): freeing frag. 0x7f03af3bccc0 alloc'ed from snmpstats: snmp_statistics.c: get_socket_list_from_proto_and_family(185) DEBUG: <core> [core/mem/q_malloc.c:402]: qm_malloc(): qm_malloc(0x7f03af1ff010, 60) called from snmpstats: snmp_statistics.c: get_socket_list_from_proto_and_family(185) DEBUG: <core> [core/mem/q_malloc.c:449]: qm_malloc(): qm_malloc(0x7f03af1ff010, 64) returns address 0x7f03af3bcc50 frag. 0x7f03af3bcc10 (size=64) on 1 -th hit DEBUG: <core> [core/mem/q_malloc.c:402]: qm_malloc(): qm_malloc(0x7f03af1ff010, 20) called from snmpstats: snmp_statistics.c: get_socket_list_from_proto_and_family(185) DEBUG: <core> [core/mem/q_malloc.c:449]: qm_malloc(): qm_malloc(0x7f03af1ff010, 32) returns address 0x7f03af3bcd00 frag. 0x7f03af3bccc0 (size=32) on 1 -th hit DEBUG: <core> [core/mem/q_malloc.c:515]: qm_free(): qm_free(0x7f03af1ff010, 0x7f03af3bcc50), called from snmpstats: snmp_statistics.c: get_total_bytes_waiting(464) DEBUG: <core> [core/mem/q_malloc.c:562]: qm_free(): freeing frag. 0x7f03af3bcc10 alloc'ed from snmpstats: snmp_statistics.c: get_socket_list_from_proto_and_family(185) DEBUG: <core> [core/mem/q_malloc.c:515]: qm_free(): qm_free(0x7f03af1ff010, 0x7f03af3bcd00), called from snmpstats: snmp_statistics.c: get_total_bytes_waiting(471) DEBUG: <core> [core/mem/q_malloc.c:562]: qm_free(): freeing frag. 0x7f03af3bccc0 alloc'ed from snmpstats: snmp_statistics.c: get_socket_list_from_proto_and_family(185) INFO: snmpstats [utilities.c:116]: get_statistic(): failed to retrieve statistics for active_dialogs INFO: snmpstats [utilities.c:116]: get_statistic(): failed to retrieve statistics for active_dialogs The SNMP daemon is set as follows: - /etc/snmp]$ cat snmptrapd.conf # Example configuration file for snmptrapd # # No traps are handled by default, you must edit this file! # # authCommunity log,execute,net public # traphandle SNMPv2-MIB::coldStart /usr/bin/bin/my_great_script cold and on /etc/snmp/snmpd.conf: ############################################################################### # Further Information # # See the snmpd.conf manual page, and the output of "snmpd -H". agentaddress udp:161 rocommunity kamailio master agentx agentXSocket tcp:localhost:705 trap2sink 10.X.Y.Z netcool 162 When running tcpdump and listening on port 162, no traffic is captured....it seems to me that Kamailio is not sending anything to SNMP Any clue, anyone? What am I doing wrong? Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

3 3

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

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