>Hello, > >What if the values of the timers are absolute relative >to the first INVITE sent ?
draft-ietf-sip-rfc2543bis-09 says 17.1.1.2 Formal Description [skip] If an unreliable transport is being used, the client transaction MUST start timer A with a value of T1. If a reliable transport is being used, the client transaction SHOULD NOT start timer A (Timer A controls request retransmissions). For any transport, the client transaction MUST start timer B with a value of 64*T1 seconds (Timer B controls transaction timeouts). When timer A fires, the client transaction MUST retransmit the request by passing it to the transport layer, and MUST reset the timer with a value of 2*T1. The formal definition of retransmit within the context of the transaction layer is to take the message previously sent to the transport layer and pass it to the transport layer once more. When timer A fires 2*T1 seconds later, the request MUST be retransmitted again (assuming the client transaction is still in this state). This process MUST continue so that the request is retransmitted with intervals that double after each transmission. SS> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ These retransmissions SHOULD only be done while the client transaction is in the "calling" state. Looks like Your proposal is going to work. But it is against the RFC. Sergey. >Time > >0 INVITE1 (retransmit after 500) (t0) >500 INVITE2 (retransmit after 1000) (relative to t0) >1000 INVITE3 (retransmit after 2000) (relative to t0) >2000 INVITE4 (retransmit after 4000) (relative to t0) >4000 INVITE5 (retransmit after 8000) (relative to t0) >8000 INVITE6 (retransmit after 16000) (relative to t0) >16000 INVITE7 (retransmit after 32000, but this is equal >to transaction timeout, so no retransmit) (relative to t0) >32000 Would send INVITE8, but transaction timed out. >In that case, the respective delays for response are 0.5, >0.5, 1, 2, 4, 8, and 16 seconds, with no odd delay at the end. >This seems to make more sense. >-Robin Lavall�e _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
