On May 17, 2010 at 18:47, Juha Heinanen jh@tutpro.com wrote:
Juha Heinanen writes:
any pointer on how to do the same from lcr module? i guess i need to load tm api and call some tm function?
i think i was able to figure this out. the corresponding tm api function is t_gett().
so i went and changed next_gw() implementation so that if no transaction exists, it rewrites request uri and if it exists, it clears possible old branches and appends a new one.
Note that if you call next_gw() after t_relay() and no transaction exists, it means that no transaction could be created (out of mem, parse error, bad via) and it makes no sense to re-try with a different uri or branch.
The easiest way to check for this is to look at T (t_gett() ) after t_relay(). If is T_UNDEFINED or 0 => no transaction could be created.
From the script you can use t_lookup_request()
(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