Hello guys,
I'm trying to use:
if(dns_query("$du", "xyz"))
And all I get is
dns_update_pv(): container not found: xyz
Any ideas? I'm not really sure what that means. I know there's supposed to
be a $dns(xyz) but it looks like it's not there? I'm using 5.0 BTW.
Thanks all & Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
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
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
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.
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
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
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.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
* https://www.asipto.com/sw/kamailio-advanced-training-online/
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.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
* https://www.asipto.com/sw/kamailio-advanced-training-online/
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.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda