9 Mar
2010
9 Mar
'10
9:54 p.m.
2010/3/9 Andrei Pelinescu-Onciul <andrei(a)iptel.org>rg>:
On Mar 08, 2010 at 21:55, I?aki Baz Castillo
<ibc(a)aliax.net> wrote:
Great, thanks for the explanation. just a question: so in TCP async
mode, the first attemp to an unreachable TCP destination (cannot
establish connection) would mean an internal 408?
Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
You're partially right if tcp is used in non-async mode (when t_relay()
waits for the tcp connection to be established).
I said partially, because in all the cases the branch_route is _always_
executed before any send attempt (you can change the destination and
some send flags in the branch route so it cannot be executed after the
send).
The branch route execution is skipped only in special cases like out of
memory while trying to build the message, maximum number of branches
exceeded, transaction canceled (e.g. CANCEL arrives before the INVITE).
So for your TCP example, branch_route will always be executed. If tcp is
in async mode (default), t_relay() won't return an error if the tcp
connect/send failed (unless that destination was already in the
blacklist from a previous attempt). If tcp is in non-async mode,
t_relay() will wait for the connect/send to complete and will return a
possible error immediately (assuming that all the other branches failed
too). Alex Balashov writes:
I really though that t_relay() fails (return a negative code and doesn't
invoke a loaded branch_route) in case the TCP cannot be established. Am I
wrong? But when does t_relay() itself ever fail due to
endpoint reachability
issues? I think t_relay() only fails for formal reasons, like host
name lookup failure, invalid address format, etc? Otherwise, it
returns success; if the endpoint is not reachable, the transaction
simply times out. If this is the case, branch route does get called.
my understanding is that t_relay calls a branch route always if
t_on_branch is used to set it. then in that branch route, you should be
able to call set_forward_no_connect().