[SR-Users] t_set_fr() different behavior whether transport is udp or tcp

[Daniel Tryba]

I'm seeing a different behavior of t_set_fr depending on transports.
Scenario is that a endpoint has a failover defined in the registrat
after 10s (t_set_fr(10000) and handling the locally generated 408 to the
failover destination). This works fine when the request and response
where delivered over UDP. When the Path is TCP the failover happends
after 30s (even when using a different time t_set_fr(20000) so it is not
a factor 3 or something like that).

Setup:
OK, 10s:
Orig->UDP->loadbalancer->UDP->registrar->UDP->loadbalancer->TCP->Term
Fail, 30s:
Orig->UDP->loadbalancer->TCP->registrar->TCP->loadbalancer->TCP->Term

Loadbalancer and registrar are kamailio machines (4.3.6). Communication
between lb and registrar is based on dispatcher and path modules.
1 sip:registrar:5060;transport=udp 8 0
or via tcp:
1 sip:registrar:5060;transport=tcp 8 0

In the location database of the registrar the difference between the
cases is:
socket:
udp:registrar:5060
or via tcp
tcp:registrar:5060
path:
<sip:***@loadbalancer;lr;received=sip:1.2.3.4:5067%3Btransport%3Dtcp>
or via tcp
<sip:***@loadbalancer;transport=tcp;lr;received=sip:1.2.3.4:5067%3Btransport%3Dtcp>

Looking at debug(=3) nothing happens between the initial INVITE and the
local 408 as far as I can see.

[Olle E. Johansson]

Post by Daniel Tryba
I'm seeing a different behavior of t_set_fr depending on transports.

Which is correct. UDP is connectionless and thus SIP has timers for
retransmits and fails when there’s no response. With connection-oriented
protocols, the failure happens when the connection fails, which in many
cases is much faster and not based on any retransmission timers.

In fact - failures in TCP is quite operating system dependent if the URI
results in an IP address. There are some interesting papers on this topic
which for SIP lead to the development of solutions like SIP outbound.

/O

Post by Daniel Tryba
Scenario is that a endpoint has a failover defined in the registrat
after 10s (t_set_fr(10000) and handling the locally generated 408 to the
failover destination). This works fine when the request and response
where delivered over UDP. When the Path is TCP the failover happends
after 30s (even when using a different time t_set_fr(20000) so it is not
a factor 3 or something like that).
Orig->UDP->loadbalancer->UDP->registrar->UDP->loadbalancer->TCP->Term
Orig->UDP->loadbalancer->TCP->registrar->TCP->loadbalancer->TCP->Term
Loadbalancer and registrar are kamailio machines (4.3.6). Communication
between lb and registrar is based on dispatcher and path modules.
1 sip:registrar:5060;transport=udp 8 0
1 sip:registrar:5060;transport=tcp 8 0
In the location database of the registrar the difference between the
udp:registrar:5060
or via tcp
tcp:registrar:5060
or via tcp
Looking at debug(=3) nothing happens between the initial INVITE and the
local 408 as far as I can see.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Daniel Tryba]

Post by Olle E. Johansson

Post by Daniel Tryba
I'm seeing a different behavior of t_set_fr depending on transports.

Which is correct. UDP is connectionless and thus SIP has timers for
retransmits and fails when there’s no response. With connection-oriented
protocols, the failure happens when the connection fails, which in many
cases is much faster and not based on any retransmission timers.
In fact - failures in TCP is quite operating system dependent if the URI
results in an IP address. There are some interesting papers on this topic
which for SIP lead to the development of solutions like SIP outbound.

I understand what you are saying, but I'm interpreting the documentation
for the fr_inv_timer/t_set_fr totally different (on an other OSI layer
(7 instead of 4))

http://kamailio.org/docs/modules/4.3.x/modules/tm.html#tm.p.fr_timer

Post by Olle E. Johansson
4.2. fr_inv_timer (integer)
Timer which hits if no final reply for an INVITE arrives after a
provisional message was received (in milliseconds).
Note: This timer can be restarted when a provisional response is
received. For more details see restart_fr_on_each_reply.
Default value is 120000 ms (120 seconds).
See also: t_set_fr(), max_inv_lifetime.

The timer doesn't care about retransmits for the messages itself, it
cares about the max time between initial provisional response for the
INVITE and a final response (2/4/5/6xx). This reads as to be independent
of the transport layer.

Either way this isn't a big problem for me since I only used TCP to get
around a packetcapture problem with fragmented packets. But surely there
should be a way to to redirect/forward a call to another destination at
an arbitrary time regardless of transport protocol.