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

Juha Heinanen jh at tutpro.com
Fri May 21 13:23:50 CEST 2010


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.

> 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?

-- juha



More information about the sr-dev mailing list