> Brett, I agree with what you say about applying > a "local policy" in these situations. > > Just to strengthen the argument that the "local policy" > may be required, assume another case where the primary > is down for a while... Now, if the UAC applies RFC 3263 > procedure then based on the expiry of NONCE at the > secondary (short expiry time); the UAC may never get > authenticated. > > However, shouldn't the "local policy" or as my > colleague calls "non-standard" be documented > (identifying scenarios leading to the use of > local policy).
Some policies eventually get standardized such as the outbound and reuse drafts. If I recall correctly, availability/stateful type rules were part of the algorithm within some of the drafts prior to RFC3261 and RFC3263. And I think that the text was removed (or made generic) so that the draft could proceed and the various alternatives could be discussed and presented within other RFCs. RFC 3263 section 2 mentions some benefits and complexities related to applying server availability rules within the algorithm. However it basically leaves it to the user or another document to define such solutions. RFC 3263 section 2: "The identity of the available server would ideally be cached for some amount of time in order to reduce call setup delays of subsequent calls. The client cannot query a failed server continuously to determine when it becomes available again, since this does not scale. Furthermore, the availability state must eventually be flushed in order to redistribute load to recovered elements when they come back online." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
