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

Daniel Tryba d.tryba at pocos.nl
Tue Aug 16 18:11:43 CEST 2016

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))

>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.

More information about the sr-users mailing list