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:lb@loadbalancer;lr;received=sip:1.2.3.4:5067%3Btransport%3Dtcp or via tcp sip:lb@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.
On 16 Aug 2016, at 11:41, Daniel Tryba d.tryba@pocos.nl wrote:
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
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:lb@loadbalancer;lr;received=sip:1.2.3.4:5067%3Btransport%3Dtcp or via tcp sip:lb@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.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Tue, Aug 16, 2016 at 04:14:15PM +0200, Olle E. Johansson wrote:
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
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.
-
Daniel Tryba -
Olle E. Johansson