Timer values must be the same on both ends of any given transaction. So
choosing different values is only an implementation option if you know
you will be implementing both ends. So it isn't a good answer to the
question Dale is raising.
Thanks,
Paul
Neelakantan Balasubramanian wrote:
> See below.
>
> Thanks,
> Neel.
>
>> -----Original Message-----
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Dale Worley
>> Sent: Wednesday, December 31, 2008 5:40 PM
>> To: sip-implementors
>> Subject: [Sip-implementors] Retry intervals
>>
>> How should we handle retry intervals for resending SIP requests which
>> have received no response? RFC 3261 prescribes doubling the retry
>> interval each time, starting with an interval (T1) which is an estimate
>> of the round-trip time of the network, and ending with 32 times that,
>> for 6 retries total.
>>
>> The exponential-backoff strategy seems fine, but the initial interval
>> is
>> troublesome. In the usual enterprise network, RTT will be 10 or 20
>> msec. In the greater Internet, I can go through my consumer-grade
>> cable
>> modem and to our partner company in India in less than 100 msec. But
>> satellite links can have RTTs of maybe 500 msec.
>>
>> The problem arises because we want a small T1 so that attempts to reach
>> a nonexistant or non-responding device will time out quickly. With T1
>> of 20 msec, the final timeout is 1.28 sec, which is a reasonable time
>> for a failover. But if T1 is 500 msec, the final timeout is 32 sec,
>> which is far too long for practical uses.
>>
> [Neelakantan Bala]
>
> Looks like an implementation issue. When the initial value of T1 is made
> very small, the number of retries should be allowed to go until the 32
> seconds. Alternatively one can implement to have the first few retries to be
> very aggressive, and later on fall back to 4 seconds interval.
>
>> Ideally, the SIP element should have telepathic knowledge of what the
>> RTT to device would be (if it was responding), but I don't see how to
>> implement that.
>>
>> Comments?
>>
>> Dale
>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
