4 May
2018
4 May
'18
8:51 a.m.
Hi,
About a year ago I posted this, but haven’t had much chance to follow up on it:
https://lists.kamailio.org/pipermail/sr-users/2017-March/096337.html
I’ve been doing some work on this issue (we worked around it until now), and have reduced
the config right down to see where things are going wonky.
The scenario I have, is inbound calls (to let’s say “A@domain") which I have aliased
to two or more different numbers (let’s say “B@domain” and “C@domain”). Both B and C are
registering, but are not always registered.
I resolve the aliases with alias_db_lookup() (in my sample below, I use seturi() and
append_branch() to avoid any confusion about where things may be going weird), then look
them up in the location table with lookup_branches().
I then need to do t_load_contacts() and t_next_contacts(), as in some call scenarios I add
a serial fork before or after the main call (pre-call announcements etc.).
Then, I call t_relay().
This works great most of the time - however, if for example B is registered, but C is not
registered, lookup_branches() notes that B is "Not found in usrloc”, and then
t_load_contacts() seems to not realise that this isn’t usable, and it attempts to do a DNS
lookup for the domain and so on, which I don’t really want it to be doing.
Should lookup_branches() be removing a branch it can’t resolve? I would expect it to
behave like that, anyway. Can I configure it to do that, or do I need to manually loop
through them or something to make sure they resolved, and remove the ones that didn’t?
I’ve tried swapping it around, so I call lookup_branches() after t_next_contacts() but the
behaviour is the same.
I imagine I can’t be the only person trying to do this - how have others made it work?
Config sample:
seturi('sip:a@domain');
append_branch('sip:b@domain');
xlog("L_DBG", "1 ds: [$ds]\n");
lookup_branches('location');
xlog("L_DBG", "2 ds: [$ds]\n");
t_load_contacts();
xlog("L_DBG", "3 ds: [$ds]\n");
t_next_contacts();
xlog("L_DBG", "4 ds: [$ds]\n");
--
Nathan Ward