No subject


Mon May 3 10:49:10 CEST 2010


(if (!t_lookup_request()) error; drop).

You could also look at the t_relay() return code, but there are some
codes which are used both when no transaction was created and when a
transaction was created but forwarding on some branch failed (e.g.
E_OUT_OF_MEM).


> 
> still next_gw() does not work as it should, i.e., second next_gw() call
> after failing t_relay() results in destination set with two sip uris
> (the first one and the second one).
> 
[...]
> 
> so even if t_relay() failed with result -478, transaction was created.
> as result, next_gw() thought that it must now append a new branch
> instead of rewriting request uri, which resulted in trying the first gw
> the second time.

Yes, this is a special case. If there are no parse errors or out-of-mem
 the transaction will always be created.
It can still fail at 2 points: when adding a branch (e.g. unresolvable
or bad uri,  to many branches, out-of-mem again) and when a message is
sent on the branch (e.g. out-of-mem, blacklisted destination,
destination denied via the on_send_route, dns failover failure,
immediate send error).
In the first case you'll get a return code of E_BAD_ADDRESS (-478),
 E_TOO_MANY_BRANCHES (-12), E_NO_SOCKET (-7) or E_OUT_OF_MEM (-2).
In the second case you'll always get E_SEND (-477).

Other return codes you should watch for are E_CANCELED (-487) and E_BUG
(-5).

> 
> 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, are you around?  perhaps you can shed some light on this or
> better yet implement opensips behavior about which i posted a request
> to the tracker, which would allow me always just to rewrite request uri
> and be done with it.

As far as I understood the osips behaviour was only for failure route.

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).

The change is modifying t_forward_non_ack():
t_fwd.c line 1323:
    if (first_branch==0) {
changed to:
    if (first_branch==0 || nr_branches==0) {

and t_fwd.c line 1326:
        if ((is_route_type(REQUEST_ROUTE)) &&
                    save_msg_lumps(t->uas.request, p_msg)) {
changed to:
        if (first_branch==0 && (is_route_type(REQUEST_ROUTE)) &&
                    save_msg_lumps(t->uas.request, p_msg)) {

If you make this changes then for serial forking it would be enough to
re-write the uri. If you test it and nobody has anything against it
(calling t_relay() multiple times without changing the uri or appending
branches would now result in multiple branches with the same uri & dst
instead of logged error messages) we can add it to master.


Andrei



More information about the sr-dev mailing list