[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