Daler Worley wrote: > 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.
I believe you are using the wrong tool to implement the required functionality. You should really use application level timeouts to do failover (i.e. cancel call in one UAC and make a new UAC instance to alternative destination) instead of tweaking SIP protocol parameters. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sa...@sippysoft.com Skype: SippySoft _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
