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. 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
