sr-users March 2020

sr-users@lists.kamailio.org

64 participants
80 discussions

by Juha Heinanen

In kamailio/etc/kamailio.cfg NAT test is based on nat_uac_test("19"). 19 includes test 16: 16 - Test if the source port is different from the port in the “Via” header. If the “Via” header contains no port, it uses the default SIP port 5060 Based on a couple of tests using baresip, looks like that results in false positive when UA connects to SIP proxy via TCP. An example: T 2020/03/24 13:57:12.685441 192.26.134.10:38940 -> 192.26.134.1:5060 [AP] #127 REGISTER sip:test.tutpro.com SIP/2.0. Via: SIP/2.0/TCP 192.26.134.10:44717;branch=z9hG4bK5b6aa423104ef942;rport. Does someone know why test 16 is included? -- Juha

4 years, 8 months

Transformations - urlencode

by João Vitor Arruda

Hello, I was looking in the transformation documentation ( https://www.kamailio.org/wiki/cookbooks/devel/transformations) something to URL encode a pv or var for use in a HTTP query but was not able to find it. Digging a bit in the source code I found that "s.urlencode.param" actually exists and from my initial tests it works just fine. I'm wondering if there is any reason why this is not mentioned in the documentation of if it should not be used at all. Thanks, Joao Arruda

4 years, 8 months

Manipulating contacts header results in a malformed SIP packet

by Andrew White

Hi all, Hope everyone is well, and looking forward to seeing you all whenever Kamailio World ends up being! I’m currently dealing with an issue which I’m unsure if it’s due to my own implementation, or a bug. When attempting to manipulate the Contact header via app_ruby, the SIP message I send ends up being malformed. Here’s the code I’m using: def replace_contact_header(uri) #KSR::HDR.remove("Contact") if KSR::HDR.is_present('Contact') > 0 #KSR::HDR.append("Contact: #{uri}\r\n") KSR::HDR.rmappend("Contact", "Contact: #{uri}\r\n") end Note that I have tried both rmappend and the commented out functions too. I call this with a custom built URI, such as <61400123123(a)kamailio.test.uconnected.com.au <mailto:61400123123@kamailio.test.uconnected.com.au>>. This function is called just before a KSR::TM.t_relay(). Here’s the result I get watching from tshark (some info scrubbed for privacy): Record-Route: <sip:1.2.3.4;lr;ftag=e3p42efd3635HH;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVFHDQAAs83AEGwAAFgwCQA8QY3RlZC5jb20uYXU-;did=927.f0f2> … Call-ID: 3de29646-e423-1238-e712-023563fb337c CSeq: 17736747 INVITE sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Content-Type: application/sdp Content-Length: 483 Contact: <sip:61400123123@kamailio.test.uconnected.com.au> In this case, 4.5.6.7 is the PBX I made the call from (and the value of the original Contact header), and 1.2.3.4 is what kamailio.test.uconnected.com.au <http://kamailio.test.uconnected.com.au/> resolves to, and is this Kamailio instance. Here’s a copy of the same thing when I don’t call my replace_contact_header function and t_relay: Record-Route: <sip:1.2.3.4;lr;ftag=j6jebCSa5Qap6c;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVND38dTgwEGEAEGwAAFgwCQA8Fdn83lZC5jb20uYXU-;did=827.40b> ... Call-ID: 249571c5-e91a-ae91-6d8e-023563fb337c CSeq: 17735867 INVITE Contact: <sip:4.5.6.7:5060;alias=10.100.1.1~5060~1> Content-Type: application/sdp Content-Length: 483 Given the relative simplicity of the function, I have to assume this is an error with how the function is manipulating the existing Contact header? It seems that the “Contact: <“ part of the header is being removed as well as the “>\r\n", but the rest being left. I’m currently using commit 283e468401d809ca9b71368c32badf3a70d48b8b <https://github.com/kamailio/kamailio/commit/283e46> on Amazon Linux 2, which is CentOS/RHEL based. Thanks! Andrew

4 years, 8 months

Pike Module Clarification

by JR Richardson

Hi All, Please clarify the pike settings for SIP message count, the module Doc reports: ---- modparam("pike", "sampling_time_unit", 10) modparam("pike", "reqs_density_per_unit", 30) How many requests should be allowed per sampling_time_unit before blocking all the incoming request from that IP. Practically, the blocking limit is between ( let's have x=reqs_density_per_unit) x and 3*x for IPv4 addresses and between x and 8*x for IPv6 addresses. ----- So the example above the SIP message rate is 30 messages within 10 seconds triggers an pike alert? The description I'm confused on is "Practically, the blocking 'limit is between' (let's have x=reqs_density_per_unit) x and 3*x for IPv4" The way this reads to me is the Pike alert could be triggered anywhere between 30 and 90 (3*30) messages within 10 second period. Am I reading this correctly? What determines when the pike trigger actually happens, could the trigger happen at say 56 messages within 10 seconds? Thanks. JR Richardson Engineering for the Masses Chasing the Azeotrope JRx DistillCo 1'st Place Brisket 1'st Place Chili

4 years, 8 months

set_advertised_address not accepting vars

by Sergiu Pojoga

Hi there, The function doesn't appear to accept vars. For example, set_advertised_address("$var(someaddress)") results in a VIA of string $var(someaddress), instead of var's value. https://www.kamailio.org/wiki/cookbooks/5.3.x/core#set_advertised_address kamailio 5.3.2 (x86_64/linux) 0bed10 Cheers. --Sergiu

4 years, 8 months

pipelimit: inexistent pipe error logs

by Nuno Ferreira

Hi all, I'm using pipelimit with the "clean_unused" option to get rid of pipes that are not used for quite some time. At the same time we are monitoring pipelimit with a jsonrpc call similar to: # curl --header 'Content-Type: application/json' --data-binary '{"id": 1, "jsonrpc": "2.0", "method": "pl.list", "params": ["pipe_INVITE"]' http://127.0.0.1:8000/RPC Reply: { "jsonrpc": "2.0", "error": { "code": 400, "message": "Unknown pipe id pipe_INVITE" }, "id": 1 } The above reply is valid because the pipe_INVITE was not loaded yet, but the request makes kamailio to log the following log messages: Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: pipelimit [pl_ht.c:519]: rpc_pl_list(): no pipe: pipe_INVITE Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: <core> [core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad message (offset: 20) Jan 20 11:21:48 proxy1 kamailio[24474]: [466B blob data] Since the monitoring system does periodic requests, those log lines get a bit annoying and fill the log with ERROR messages that aren't really errors. IMHO the first log line should be converted to DEBUG instead of ERROR, but I have some doubts about the one from parse_fline.c:262. parse_first_line() is used to process both SIP and HTTP. It makes sense to log ERROR if SIP but not in the case of HTTP... Regarding the "[466B blob data]" I really don't know from where it's coming from. I can submit a PR, but I would like to have first some feedback from you. Thank you, Nuno -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

4 years, 8 months

is_gflag Always Returns FALSE

by Yufei Tao

Hi, I got some problems with is_gflags: 1. Set the gflag: # kamcmd cfgutils.set_gflag 1024 2. Check the gflags - fine: # kamcmd cfgutils.get_gflags 0x400 (1024) 3. Check using is_gflag - problem: # kamcmd cfgutils.is_gflag 1024 FALSE Seems is_gflag always returns FALSE somehow. Calling function is_gflag() from the cfg file seems to always return FALSE too. I tried this on Kamailio 5.3.2 and 5.3.3 and the behaviour is the same. Best regards, Yufei

4 years, 8 months

OPTIONS sent from the wrong IP

by David Villasmil

Hello, It seems kamailio is selecting the local ip wrongly when selecting the socket with which to send out OPTIONS. This is 5.2.3, and i have multiple IPs Listen=ip1 (private) Listen=ip2 (public) And when the options goes out, it goes via the first ip instead of the one through which it can reach the OPTIONS destination (public IP). I have mhomed=1 set This is using dispatcher. Has anyone seen this behaviour? Thanks all David -- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

4 years, 8 months

unknown error messages

by Juha Heinanen

It turned out that the unknown error messages were produced by process 32058 that was not in ctl ps list at all. So it must have survived alive from a previous restart of K. Question: how it is possible that a tcp worker that does not belong to the current running K instance gets to service a json rpc request? -- Juha

4 years, 8 months

raise of inuse_transactions after enabled dispatcher probing

by Michal Popovic

Hi, after I have enabled dispatcher probing with OPTIONS, tmx statistic inuse_transactions reports constantly multiple existing transactions per checked server. Is this normal behaviour or could it be any sign of potential issue? Thanks. Michal

4 years, 8 months

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