[SR-Users] Combining lookup_branches() and t_(next|load)_contacts()

Nathan Ward kamailio-sr-users at daork.net
Fri May 4 14:51:01 CEST 2018


About a year ago I posted this, but haven’t had much chance to follow up on it:

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 at domain") which I have aliased to two or more different numbers (let’s say “B at domain” and “C at 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 at domain');
append_branch('sip:b at domain');
xlog("L_DBG", "1 ds: [$ds]\n");
xlog("L_DBG", "2 ds: [$ds]\n");
xlog("L_DBG", "3 ds: [$ds]\n");
xlog("L_DBG", "4 ds: [$ds]\n");

Nathan Ward

More information about the sr-users mailing list