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
Hi all,
I’ve worked around this by walking through $branches() and removing entries where dst_uri is $null. This works OK, but feels like a hack:
# Walk through all the branches, and nuke any which have not resolved - i.e. they do not have a dst_uri set. $var(i) = 0; while($var(i)<$branch(count)) { xlog('L_DBG', "Looking at branch [$var(i)] with dst_uri [$(branch(dst_uri)[$var(i)])] and ru [$(branch(uri)[$var(i)])]\n"); if ($(branch(dst_uri)[$var(i)]) == $null) { xlog('L_DBG', "Branch [$var(i)] has a null dst_uri, so removing\n"); $(branch(uri)[$var(i)]) = $null; } else { $var(i) = $var(i) + 1; } }
I’d be keen to know if there’s any other ways to achieve this.
I also note that I’m getting a "BUG: freeing already freed pointer” message when the dialog is getting cleaned up. How can I debug this, or, what sort of information is useful to provide for something like this? I’m on 5.1.3.
On 4/05/2018, at 1:51 PM, Nathan Ward kamailio-sr-users@daork.net wrote:
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
-
Nathan Ward