16 Aug
2016
16 Aug
'16
12:41 p.m.
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.
16 Aug
16 Aug
5:14 p.m.
New subject: t_set_fr() different behavior whether transport is udp or tcp
On 16 Aug 2016, at 11:41, Daniel Tryba
<d.tryba(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:11 p.m.
New subject: t_set_fr() different behavior whether transport is udp or tcp
On Tue, Aug 16, 2016 at 04:14:15PM +0200, Olle E. Johansson wrote:
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
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. 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.
3020
days inactive
3020
days old
2 comments
2 participants
participants (2)
-
Daniel Tryba -
Olle E. Johansson