Hi Folks,
I would like to ask how can I change the $rU (user part of uri) in multiple appended branches?
In my scenario I do lookup("location") and after this I try to modify an username using the $rU variable. This works fine until there are several records in the location table for the given user (registered from different locations). In this case only one branch is changed and unchanged uri is sent to an another location.
Is there a way to change it in all branches together?
Thanks for the answer.
Regards,
Efelin
Am 09.08.2011 12:55, schrieb Efelin Novak:
Hi Folks,
I would like to ask how can I change the $rU (user part of uri) in multiple appended branches?
In my scenario I do lookup("location") and after this I try to modify an username using the $rU variable. This works fine until there are several records in the location table for the given user (registered from different locations). In this case only one branch is changed and unchanged uri is sent to an another location.
Is there a way to change it in all branches together?
AFAIK no. But you can do it in a "branch route" for every branch separately.
regards Klaus
Thanks for the answer.
Regards,
Efelin
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2011/8/9 Klaus Darilion klaus.mailinglists@pernau.at:
AFAIK no. But you can do it in a "branch route" for every branch separately.
And isn't it a bug? why the RURI username is just changed in a single branch? Theorically operations over RURI made in a route block should affect to all the branches, am I wrong? it's the very same as giving value to a flag or AVP after doing loockup and fetching multiple contacts. If I inspect such flag or AVP in branch_route I should find it for every branches. Why should changing the RURI behave different?
IMHO it's a bug, or do I miss something?
Am 09.08.2011 16:40, schrieb Iñaki Baz Castillo:
2011/8/9 Klaus Darilion klaus.mailinglists@pernau.at:
AFAIK no. But you can do it in a "branch route" for every branch separately.
And isn't it a bug? why the RURI username is just changed in a single branch? Theorically operations over RURI made in a route block should affect to all the branches, am I wrong? it's the very same as giving value to a flag or AVP after doing loockup and fetching multiple contacts. If I inspect such flag or AVP in branch_route I should find it for every branches. Why should changing the RURI behave different?
IMHO it's a bug, or do I miss something?
I wouldn't call it a bug. It is a limitation of how sip-router works, probably a design decision from early SER days. To overcome this limitation and allow manipulation of all branches (not only the main branch), features like the branch route were added.
Any maybe I only want to manipulate a single branch. IMO manipulating all branches is as buggy as manipulating just a single branch - it depends on what the user needs.
regards Klaus
2011/8/9 Klaus Darilion klaus.mailinglists@pernau.at:
I wouldn't call it a bug. It is a limitation of how sip-router works, probably a design decision from early SER days. To overcome this limitation and allow manipulation of all branches (not only the main branch), features like the branch route were added.
Any maybe I only want to manipulate a single branch. IMO manipulating all branches is as buggy as manipulating just a single branch - it depends on what the user needs.
The behaviour is unexpected. Imagine you do lookup (which fetchs 2 contacts) and after that, still in route block, do setflag(1). Such flag is set in branch_route for both generated branches. Why setting the $rU in same circumstances should behave different?
On Tuesday 09 August 2011, Iñaki Baz Castillo wrote:
The behaviour is unexpected. Imagine you do lookup (which fetchs 2 contacts) and after that, still in route block, do setflag(1). Such flag is set in branch_route for both generated branches. Why setting the $rU in same circumstances should behave different?
Flags are related to the whole transaction, so being able to see them on all branches is expected. Use branch_flags if you want to set them per branch.
$rU is related to the 'main' branch in request_route. There is no way to set the request uri for all branches in a transaction.
No, but if you are manually creating them via append_branch(), you can set the RURI beforehand in, say, a failure route. It will apply to the current (failed, let's say) branch, but will be copied into the one as well, because that's how append_branch() works.
I would use that as a manual hack around needing a different RURI for every usrloc contact for an AOR.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Aug 9, 2011, at 10:41 AM, Alex Hermann alex@speakup.nl wrote:
On Tuesday 09 August 2011, Iñaki Baz Castillo wrote:
The behaviour is unexpected. Imagine you do lookup (which fetchs 2 contacts) and after that, still in route block, do setflag(1). Such flag is set in branch_route for both generated branches. Why setting the $rU in same circumstances should behave different?
Flags are related to the whole transaction, so being able to see them on all branches is expected. Use branch_flags if you want to set them per branch.
$rU is related to the 'main' branch in request_route. There is no way to set the request uri for all branches in a transaction. -- Greetings,
Alex Hermann
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2011/8/9 Alex Hermann alex@speakup.nl:
$rU is related to the 'main' branch in request_route.
Which is supposed to be the "main branch" when doing lookup() and fetching 2 or more contacts/branches?
The reply is: random, probably the first retrieved contact from the location table (or memory). Is it really an expected/correct/arguable behavior? I don't think so.
NOTE: Anyhow this is the way in which it works.
Regards.
-
Alex Balashov -
Alex Hermann -
Efelin Novak -
Iñaki Baz Castillo -
Klaus Darilion