[sr-dev] appending a new branch in route block

[Andrei Pelinescu-Onciul]

On May 21, 2010 at 14:23, Juha Heinanen <jh at tutpro.com> wrote:
> Andrei Pelinescu-Onciul writes:
> 
> > > i don't understand, how it is possible that transaction was created, but
> > > request uri was not marked as used.  also, i don't understand how i can
> > > ever get this to work, because i don't have no way to know if i should
> > > rewrite request uri or append a branch.
> > 
> > This happens because the request uri was not really used (adding a
> > branch with it failed).
> > 
> > You could either check the return code and if
> >  1. $? is E_BAD_ADDRESS or E_NO_SOCKET rewrite the uri
> >  2. $? is E_SEND append a branch
> >  3. all other cases for $? <0 exit.
> > or see below.
> 
> andrei,
> 
> i want to do that inside next_gw()/next_contacts() functions, not in the
> script.  could it be somehow possible to check from the branch structure
> (dset.h/c) if request-uri is still unused?  would
> get_branch_iterator(void) and next_branch() or get_branch() work
> although they seem to be very heavy means.

No, they won't work. t_relay() will clear all the branches if it
creates a transaction (even if it fails). Even if this wouldn't be the
case it would still not possible to do the ruri check with the current
code.

The only way would be either to get the transaction number of branches
 (t->nr_of_outgoings) previous to calling t_relay() and compare with the
 same number after that (if different you need to use append_branch(),
 else set new uri), or relay on checking ser_error (this is $rc or $? in
 the code).
> 
> > As far as I understood the osips behaviour was only for failure route.
> 
> may be, but it would be simpler still if i could set request-uri in any
> block, i.e., setting of request-uri always clears possible existing
> request uri and possibly existing branches. after that, more branches
> can be added by append_branch() before calling t_relay(), which always
> operates on request-uri and the possible branches.
> 
> > Anyway there is a simple change that would allow rewriting only the
> > request uri and having t_relay() add new branches. However it will work
> > only if append_branch() is not used in the same time (if append_branch()
> > is used and this is not the first t_relay() call, only the branches added by
> > append_branch() will be used) and will hide mistakes like calling
> > t_relay() twice without changing anything (e.g. t_relay(); t_relay()
> > will result in 2 branches with the same uri and destination, instead of
> > the current behaviour which is 1 branch and an error logged).
> 
> that sounds too complicated and risky.  would the change that i suggest
> in above be more difficult to implement?

It would be slightly more difficult (definitely not only 1 changed
line). Basically we would need to remember if ruri is can be used for
branches or not. On new message set ruri_is_new=1 (ruri_is_new being a
new static var inside dset.c) and on clear_branches() set it to 0. Then
change t_forward_non_ack() and use ruri_is_new instead of
first_branch==0 for the first add_uac().
For failure route ruri_is_new should be set to 0.
Each time a new uri is set, ruri_is_new should also be set to 1.
Probably the same should be done if dst_uri is changed.


Andrei