23 maj 2012 kl. 14:21 skrev Kevin P. Fleming: > While this behavior is technically not RFC3261 compliant (and I've had > discussions about it with at least one of the RFC's authors), it's quite > useful in making decisions about whether a peer has become unavailable more > quickly than would normally be possible. For a local peer that responds to > OPTIONS requests in 100ms or less, if that peer stops responding, Asterisk > will be able to make that determination in approximately 6 seconds, instead > of the 32 seconds that would normally be required.
Form the RFC: "T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms." "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." I can't see how this is not RFC 3261 compliant. We have a good estimate of the RTT and use it. /O -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
