sr-users May 2022

sr-users@lists.kamailio.org

49 participants
54 discussions

by David Villasmil

Hello guys, Is it possible to call a failure_route like a normal route? i.e.: { t_on_failure("myroute"); } ... route("myroute"); failure_route[myroute] { ... } Let me explain: I have this scenario where a DNS name may get deleted and a dns resolution will fail. There's no pinging to that gateway so i need to: - skip that gateway when dispatching to the setid - detect whether the domain is up and available And failover to the next gateway. I don't know of any other way so on the DISPATCH route, I'm doing: route[DISPATCH] { # round robin dispatching on gateways group '1' if(!ds_select_dst("1", "4")) { send_reply("404", "No destination"); exit; } xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n"); if(dns_query("$du", "xyz")) { t_on_failure("RTF_DISPATCH"); route(RELAY); } else { route(RTF_DISPATCH); } exit; } to try to resolve and if it fails, it will just go to the failover route. makes sense? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

1 year, 11 months

BYE is being sent using the Dialog ID (did)

by mack＠dopensource.com

I configured the dialog module to match routing based on SIP elements versus the (Dialog ID) did. It looks like it’s using the callid SIP element, but it’s still looking it up using the dialog module. I was hoping it would route on the RURI of the BYE. But, it looks like it’s using the dialog lookup table, which has the wrong RURI because that was the original server we sent the request to. How can I get Kamailio to route based on the RURI within the BYE. May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: rr [rr_cb.c:94]: run_rr_callbacks(): callback id 0 entered with <lr> May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:887]: internal_get_dlg(): ref dlg 0x7f6d97faf200 with 1 -> 3 May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:891]: internal_get_dlg(): dialog callid='oeIojv5OA59S9FYCCu7BcQ..' found on entry 777, dir=2 to-tag='sip+3+f36a00a5+44b60208' May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_profile.c:536]: set_current_dialog(): setting current dialog [777:1428] May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:1290]: next_state_dlg(): dialog 0x7f6d97faf200 changed from state 4 to state 5, due event 7 (ref 3) May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:1071]: dlg_ref_helper(): ref op on 0x7f6d97faf200 with 1 from dlg_handlers.c:1441 May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:1075]: dlg_ref_helper(): ref dlg 0x7f6d97faf200 with 1 -> 4 May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_handlers.c:1452]: dlg_onroute(): BYE successfully processed May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:1091]: dlg_unref_helper(): unref op on 0x7f6d97faf200 with 2 from dlg_handlers.c:1476 May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:1095]: dlg_unref_helper(): unref dlg 0x7f6d97faf200 with 2 -> 2 May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:1091]: dlg_unref_helper(): unref op on 0x7f6d97faf200 with 1 from dlg_hash.c:1109 May 5 06:28:13 sbc-atlanta /usr/sbin/kamailio[27066]: DEBUG: dialog [dlg_hash.c:1095]: dlg_unref_helper(): unref dlg 0x7f6d97faf200 with 1 -> 1 Thanks in advance

1 year, 11 months

Tips on picking random element from a list

by Joel Serrano

Hi Everyone, I have to implement a flow where outbound calls get their caller-id set with a random number from a pool. I've been looking around and, as most of the time, there are tons of ways to implement something like this... This is a simple implementation, the number pool is fixed and will not change (so I could have it hard-coded in the config if required). My initial approach was: 1- Try to keep it simple, with no dependencies, and all done in the config script. 2- If #1 is "ugly", then I'd probably go with some inline code using python/lua/etc 3- If #2 is "ugly", then I'd go with having the info in a DB and just run a query I think #2 and #3 might be overkill for something so "simple" but I haven't had to work too much with randomness in Kamailio, so any tips/suggestions on where to store the number list and how to pick one randomly would be awesome! Thanks!! Joel.

1 year, 11 months

failover on dns resolve error

by David Villasmil

Hello guys, I have a scenario where a dns name I've added as a dispatcher endpoint may get removed completely, i.e.: dns resolution fails completely. How would you recommend implementing failover in this case? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

1 year, 11 months

iterating over htable with lua

by David Villasmil

Hello guys, I'm trying to iterate over an htable in lus, this is what i have: =================================== loadmodule "app_lua.so" modparam("app_lua", "load", "/etc/kamailio/myscript.lua") modparam("htable", "htable", "mydata=>size=16;autoexpire=0;dbtable=mydata;dbmode=0;") route { lua_run("match_mydata"); } ... function match_mydata() KSR.htable.sht_iterator_start("i1", "mydata") while KSR.htable.sht_iterator_next("i1") do KSR.log("err","WHILE: iterating on: " .. KSR.htable.sht_get("mydata", "i1")) end KSR.htable.sht_iterator_end("i1"); end But i keep getting: 0(1255) DEBUG: app_lua [app_lua_api.c:666]: app_lua_run_ex(): executing Lua function: [[match_mydata]] 0(1255) DEBUG: app_lua [app_lua_api.c:668]: app_lua_run_ex(): lua top index is: 12 0(1255) ERROR: app_lua [app_lua_api.c:719]: app_lua_run_ex(): error from Lua: /etc/kamailio/myscript.lua:11: attempt to call field 'sht_iterator_start' (a nil value) 0(1255) ERROR: app_lua [app_lua_api.c:734]: app_lua_run_ex(): error executing: match_mydata (err: 2) This almost exact same thing works on the cfg: sht_iterator_start("i1", "msrn"); while(sht_iterator_next("i1")) { xlog("data: $shtitkey(i1)\n"); } sht_iterator_end("i1"); Anyone know what I could be doing wrong? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

1 year, 11 months

Development is open for future release of v5.7.x series

by Daniel-Constantin Mierla

Hello, the branch 5.6 was created, therefore the master branch is open for adding new features, to be part of future release series v5.7.x (or whatever version is decided for next series). Any bug fix committed to master that applies to 5.6.x or older stable branches should be backported as usual with "git cherry-pick -x ..." to appropriate branches like 5.6 or 5.5. Expect that v5.6.0 will be released in a few weeks from now. Based on the workflow used during the past years, the next future release v5.7.0 should be out after another 6-10 months of development, plus 1-2 months of testing, so sometime by end of 2022 or in the first part of 2023. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online * https://www.asipto.com/sw/kamailio-advanced-training-online/

1 year, 11 months

Branch 5.6 has been created

by Daniel-Constantin Mierla

Hello, the branch 5.6 has been created, to be used for releasing v5.6.x series. To check out this branch, the following commands can be used: git clone https://github.com/kamailio/kamailio kamailio-5.6 cd kamailio-5.6 git checkout -b 5.6 origin/5.6 Pushing commits in this branch: git push origin 5.6:5.6 Note that 5.6 is an official stable branch, so only bug fixes, missing kemi exports (discuss on sr-dev if not sure) or improvements to documentation or helper tools can be pushed to this branch. As usual, if there is a bug fixed, commit and push first to master branch and then cherry pick to 5.5 branch: git cherry-pick -x COMMITID In few weeks, the first release from branch 5.6 will be out, respectively Kamailio v5.6.0. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online * https://www.asipto.com/sw/kamailio-advanced-training-online/

1 year, 11 months

Development for v5.6.x is frozen

by Daniel-Constantin Mierla

Hello, the formal notification that the development for the next major version 5.6.0 is now frozen. The focus has to be on testing the master branch. Also, the master branch should not get commits with new features till the branch 5.6 is created, expected to happen in 2-4 weeks, a matter of how testing goes on. Meanwhile, the commits with new features in the C code can be pushed to personal branches, new pull requests can still be done, but they will be merged after branching 5.6. Can still be done commits with documentation improvements, enhancements to related tools (e.g., kamctl, kamcmd), merging exiting pull requests at this moment, exporting missing KEMI functions and completing the functionality of the new modules added for 5.6. Once the branch 5.6 is created, new features can be pushed again to master branch as usual. From that moment, the v5.6.0 should be out very soon, time used for further testing but also preparing the release of packages. If someone is not sure if a commit brings a new feature, just make a pull request and it can be discussed there on github portal or via sr-dev mailing list. A summary of what is new in upcoming 5.6 is going to be built at: * https://www.kamailio.org/wiki/features/new-in-5.6.x Upgrade guidelines will be collected at: * https://www.kamailio.org/wiki/install/upgrade/5.5.x-to-5.6.0 Everyone is more than welcome to contribute to the above wiki pages, especially to the upgrade guidelines, to help everyone else during the migration process from v5.5.x to 5.6.x. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 year, 11 months

unexpected error log when KSR.xhttp.xhttp_reply(404...)

by hanxiaofang

Hello Kamailio community kamailio v5.5.4 debian10 Lua Scripting Routing: listen=tcp:127.0.0.1:5060 tcp_accept_no_cl=yes loadmodule "xhttp.so" loadmodule "app_lua.so" modparam("app_lua", "load", "/etc/kamailio/kamailio.lua") cfgengine "lua" function ksr_xhttp_event() KSR.set_reply_no_connect() KSR.set_reply_close() KSR.xhttp.xhttp_reply(404, "Not Found", "text/plain", "Not Found") end curl http://127.0.0.1:5060 -vvv * Expire in 0 ms for 6 (transfer 0x555d93fd9fb0) * Trying 127.0.0.1... * TCP_NODELAY set * Expire in 200 ms for 4 (transfer 0x555d93fd9fb0) * Connected to 127.0.0.1 (127.0.0.1) port 5060 (#0) > GET / HTTP/1.1 > Host: 127.0.0.1:5060 > User-Agent: curl/7.64.0 > Accept: */* > < HTTP/1.1 404 Not Found < Sia: SIP/2.0/TCP 127.0.0.1:54944 < Content-Type: text/plain < Server: kamailio (5.4.4 (x86_64/linux)) < Content-Length: 9 < * Connection #0 to host 127.0.0.1 left intact The output of curl is OK, but have some unexpected error in kamailio.log ERROR: <core> [core/parser/parse_fline.c:271]: parse_first_line(): parse_first_line: bad message (offset: 16) ERROR: <core> [core/parser/msg_parser.c:681]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 404 Not Found#015#012Sia: SIP/2.0/TCP 127.0.0.1:54946#015#012Content-Type: text/plain#015#012Server: kamailio (5.4.4 (x86_64/linux))#015#012Content-Length: 9#015#012#015#012Not Found> ERROR: <core> [core/msg_translator.c:3235]: build_sip_msg_from_buf(): parsing failed now change to Native Scripting Routing: listen=tcp:127.0.0.1:5060 tcp_accept_no_cl=yes loadmodule "xhttp.so" event_route[xhttp:request] { set_reply_close(); set_reply_no_connect(); xhttp_reply("404", "Not Found", "text/plain", "Not Found"); exit; } curl http://127.0.0.1:5060 -vvv everything is ok. here is the Navite config file: http://220.231.180.131:12296/kam/native/ here is the Lua config file: http://220.231.180.131:12296/kam/kemi/ hanxiaofang

1 year, 11 months

sanity_reply not available from sanity module

by Patrick Karton

Hello , the sanity_reply function from sanity is not available in kamailio script so i get an error when i want to use it. in the module source i see this static cmd_export_t cmds[] = { {"sanity_check", (cmd_function)w_sanity_check, 0, 0, 0, REQUEST_ROUTE|ONREPLY_ROUTE}, {"sanity_check", (cmd_function)w_sanity_check, 1, fixup_igp_null, 0, REQUEST_ROUTE|ONREPLY_ROUTE}, {"sanity_check", (cmd_function)w_sanity_check, 2, fixup_igp_igp, 0, REQUEST_ROUTE|ONREPLY_ROUTE}, {"sanity_check", (cmd_function)w_sanity_reply, 0, 0, 0, REQUEST_ROUTE|ONREPLY_ROUTE}, {"bind_sanity", (cmd_function)bind_sanity, 0, 0, 0, 0 }, {0, 0, 0, 0, 0, 0} }; why is sanity_check linked again in w_sanity_reply ? is this an error ? i want to setup specific responses for some errors and let the default ones from module work as usual. Thanks.

1 year, 11 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 2022