2011/6/23 Andrei Pelinescu-Onciul <andrei(a)iptel.org>rg>:
Yes, it's a known limitation. Basically when async
it's own, tm has no
way of knowing that a connect() has failed and would have to rely on sip
timeout.
Of course these could be changed, but it would have both performance and
memory usage impact and it would be very hard to integrate with tls.
I would rather not do it in the near future.
Ok, I understand. It would be great to have it however.
In the other side, this has an unexpected advantage:
It unifies both behaviours of UDP and TCP/TLS. In sync mode, if a TCP
connection fails t_relay returns an error and doesn't execute
on_failure_route block (I still this is a bug in the design as a TCP
connection error should trigger a local 503 so on_failure_route should
be called with such 503 as winning reply). Anyhow, in async mode, due
to the explained limitation, a TCP connection error would generate a
local timeout so on_failure_route would be called with 408 as winning
reply. This allows unifying code for UDP and TCP in the script.
The tcp_connect_timeout refers to how long the tcp
connect will be
attempted, but it's not linked to tm. The value is not 100% exact,
the tcp timers are executed on a best effort basis, at most at 5s
intervals and at minimum 1/16 seconds, so you should expect a 5s error
If it's too much for you, change TCP_MAIN_SELECT_TIMEOUT and
TCP_CHILD_SELECT_TIMEOUT in tcp_conn.h (btw. we don't use select()
anymore, the names where not updated when we switched to
epoll/kqueue/dev_poll).
Thanks, I don't need it to be less than 5 seconds, neither I care it
as anyway I must wait fr_timer seconds :)
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>