sr-users May 2023

sr-users@lists.kamailio.org

40 participants
49 discussions

Branching 5.7 on git repo for 5.7.x releases

by Daniel-Constantin Mierla

Hello, I am planning to split 5.7.x series on its own git branch 5.7 on Thursday, May 4, 2023. After that, master branch will be open for new features (to become part of 5.8 or what ever version will be decided to be next). Usually testing should continue for branch 5.7 for another 1-2 weeks, then, if no relevant road blockers pop up, we should release 5.7.0 as first stable version in the 5.7.x series. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 year, 6 months

uac.reg_add to database

by Jon Bonilla (Manwe)

Hi 5.6.4 I'm trying to add uacreg logic to my setup. When I add a new entry via rpc I see that the reg is stored in mem but not inserted in the database for persistency. My uac params are like this: modparam("uac", "reg_db_url",DBURL) modparam("uac", "reg_timer_interval", 900) modparam("uac", "reg_retry_interval", 10) modparam("uac", "reg_random_delay", 0) modparam("uac", "reg_hash_size", 12) ## 5.6 modparam("uac", "reg_db_table", "kam_uacreg") modparam("uac", "reg_contact_addr", "192.168.255.254:5060") #Won't be used #modparam("uac", "default_socket", "udp:192.168.0.125:5060") #Won't be used modparam("uac", "reg_keep_callid", 1) modparam("uac", "reg_active", 1) modparam("uac", "reg_gc_interval", 30) modparam("uac", "reg_use_domain", 0) I'm used to add via rpc and have db persistency. Like for exmaple using the domain module. Is this a bug in my config or does this module behave different? Should I insert in the db and call to enable via RPC? If so, what would be the best way to enable only the new inserted register instead of reloading all the regs? It's expected to have many changes and do not want to have full reloads all the time. cheers, Jon -- PekePBX, the multitenant PBX solution https://pekepbx.com

1 year, 6 months

Kamailio - asterisk - ACK

by Péter Dr. Barabás

Hi all, we are developing a softphone mobile application which registers to asterisk through kamailio. Kamailo proxies the request to asterisk and replies from asterisk to the clients. Registration works fine with asterisk authentication. The problem appears in the following flow: 1. Mobile client A calls client B. 2. Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with credentials. 3. Asterisk sends invite to client B towards kamailio. 4. Kamailio forwards INVITE if client is registered or sends a push notification to client B. When client B registers, kamailio continue the suspended transaction and forwards INVITE. 5. Client B gets INVITE, sends a SIP OK. 6. Asterisk gets SIP OK through kamailio and sends an ACK to client B, which is OK. 7. Asterisk sends the SIP OK to client A through kamailio. 8. Kamailio forwards SIP OK to client A but the contact address contains the asterisk IP instead kamailio. 9. Clilent A try to send ACK but it does not arrive to asterisk, and the call will be hungup after 30 secs. So the question is what is missing, what is the correct solution? I try to use the provided configuration given in following link: https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb The difference is that kamailio has no access to asterisk database. Thanks for your help. With kind regards, Peter

1 year, 6 months

RFC: selective backports to latest stable as a dedicated git branch

by Daniel-Constantin Mierla

Hello, during past on-site/online devel meetings as well as on mailing lists or tracker, there were various discussions around the idea or requests to make new features available quicker to stable branches. Of course, one can do local git cherry-picking, but I thought to bring this in discussion and see if makes sense to get something more coordinated between developers and community. Therefore I am cross-posting to sr-dev and sr-users to see if there is interest for it from both communities. Somehow inspired from Debian, my first idea would be to create a "x.y-backports" branch, where "x.y" is the branch for the stable release series. For example, with 5.6 release series built from branch "5.6", there could be "5.6-backports" branch which is kept in sync in "5.6" but also can get "selected" new features from devel (master branch) backported. The "selected" new features should be mostly a matter of the people willing to put effort in backporting, but I would consider a list recommendations not to end up with devel and backports branches being more or less the same. For example, in the "no-backporting" list: - no backporting of completely new modules - no backporting of significant changes to the config file language and native scripting interpreter In the "ok-to-backport": - updates to enable use with newer versions of external libraries - changes to make some functions/modules to cope better with the core infrastructure or end points Commits to the backports branch can be proposed via pull requests. The backports branch should be done only for latest stable version, picking from the development version. Right now it would be 5.6, but we can wait till 5.7 is released and then have it for it. No packaging and no official releases should be made from backports branch, only a git branch to be maintained as a community effort. Of course, if someone wants to put more resources into it, we can discuss about. Anyhow, the first questions would be if such branch sounds good to have and if there are people that think they can also contribute to maintain it. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 year, 6 months

Clarification of 'return false' behaviour

by Patrick Wakano

Hi list, Hope you are all well! I'm using Kamailio version 5.6.4 (installed from the repo rpm.kamailio.org/centos/7) and noticed that every route that uses "return false" is exiting the script, instead of returning.... This was not the case on version 5.4.6 as the same script is running fine..... From this page https://www.kamailio.org/wikidocs/tutorials/faq/main/#how-is-the-function-r…, I would think that when a route returns false, it would return -1 and not stop execution, since negative is equal to false, but it is actually stopping (same as return 0)... So, as an example, this test code doesn't work as expected. In case the source is a public IP, the script doesn't print the "SRC public" it just exits and then of course every other logic meant to be done is not executed.... route[is_src_private] { if (is_ip_rfc1918("$si")) { return true; } return false; #return is_ip_rfc1918("$si"); *# this doesn't work too in case the $si is a public IP* } request_route { ... if (route(is_src_private)) { xlog("L_NOTICE", "SRC private\n"); } else { xlog("L_NOTICE", "SRC public\n"); } ... } If is_src_private is changed to return -1 instead of false, then it all works fine. Also, I noticed that the following code will print "TEST: 0" in case the $si is public and then stop execution. So looks like false is really being converted to 0, but I guess that's unexpected... anyway apologies if I'm missing something obvious.... route[is_src_private] { $var(t) = false; if (is_ip_rfc1918("$si")) { $var(t) = true; } xlog("L_ERR", "TEST: $var(t)\n"); return $var(t); } I could not find a recent ticket or email related to this situation and I've already spent hours trying to understand what is the logic/problem here, so would anyone have been across a similar case that could provide some insight and clarify what is the expected behaviour of the *false* usage (and boolean in general if possible)? Thank you, Kind regards, Patrick Wakano

1 year, 6 months

rtpengine module: sdp offer in message reply, ip protocol version not passed to rtpengine?

by Benoit Panizzon

Hi Team I think, I might have found something that was overseen in the rtpengine module. A (ipv6) <=> rtpengine <=> B (ipv4) Invite+SDP from B to A It looks like this works as expected. A SDP c= line is created containing an ipv6 address. Invite, no SDP from A to B Reply with SDP offer from B to A The information about A being reachable via ipv6 and therefore an ipv6 c= line being required, could be taken from the via header of the reply. But am I right to fear, that the rtpengine module does not do this at the moment? 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 ______________________________________________________

1 year, 6 months

Number if typical database connections

by Steve Wilkins

Hello, I moved the Kamailio database to RDS from a local instance and noticed that there were a large number of connections from the Kamailio user. What is the normal number of connection that can be expected? Thank you,

1 year, 6 months

Rebooting kamailio.org server

by Daniel-Constantin Mierla

Hello, in about 1 hour the kamailio.org server will be rebooted for some system upgrades, it should be quickly back running, but if anyone accesses the web/wiki or mailing lists archives exactly during that time, they might not respond -- just wait for a minute and try again. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 year, 6 months

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

by Daniel Tryba

On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote: > Sure. Attached. Problem appears to be that the topos query can't find > callid-totag (from the response). > > I'll try the same scenario with the mysql backend to see if it behaves > different. Config works fine with mysql as topos backend. So the bug is restricted to topos-redis.

1 year, 6 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 May 2023