Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To: <[email protected]>
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64493>
Message-ID: <[email protected]>
Joergen, again thank you for suggesting the Karoo solution.
I understand the issue with the redundant configuration and
user patience "timout", the question is if there is a way to
resolve
T1=500msec is indeed the default, but lowering it is "NOT
RECOMMENDED" (still I agree it's recommendation only). On
the other hand following the 7 exponential retransmit
guidance to reach 64*T1 is defined as "MUST be used". See
text below.
I understand the issue with the redundant configuration and
user patience "timout". The question is if there is a way
to resolve the conflicting needs, while be able to work on
high latency networks (as the RFC3261 stipulates).
Can we detect in some other way that a node is down, and
redirect all the traffic to a working node without relying
on no response to invite?
By the way the following excerpt from the SipXecs source
code defined RFC 3261 T1 default as 100msec and 10msec as
minimum T1 allowed. That's clearly not correct statement.
// DEFINES
#define SIP_DEFAULT_RTT 100 // Default T1 value (RFC
3261), in msec.
// Intended to be estimate of
RTT of network.
#define SIP_MINIMUM_RTT 10 // Minimum T1 value allowed,
in msec.
The relevant exact (including the capitalization)text of the
RFC3216 is here:
The default value for T1 is 500 ms. T1 is an estimate of
the RTT between the client and server transactions.
Elements MAY (though it is NOT RECOMMENDED) use smaller
values of T1 within closed, private networks that do not
permit general Internet connection. T1 MAY be chosen
larger, and this is RECOMMENDED if it is known in advance
(such as on high latency access links) that the RTT is
larger. Whatever the value of T1, the exponential backoffs
on retransmissions described in this section MUST be used.
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
