2009/4/29 Taisto Qvist XX <[email protected]>: > =========== > Question 3. > =========== > The annoying 503 Response and "Retry-After:"... > I have read the archive and the fairly new RFC on congestion-handling, > but neither seems to clarify, or even mention that the text in 3261, > (that is referred to in rfc5390) is completely self-contradicting, > to me at least... > The discussion is always on how long you should blacklist, and wether > to use this for overload protection or not.. > > 3261: > If no Retry-After is given, the client MUST act as if it had >> received a 500 (Server Internal Error) response. > > A client (proxy or UAC) receiving a 503 (Service Unavailable) > SHOULD attempt to forward the request to an alternate server. > It SHOULD NOT forward any other requests to that server for the >> duration specified in the Retry-After header field, if present. > > To me, this says that any 503 response without R-A, is NOT a 503.
This is an unfortunate description in RFC 3261 which creates lot of confussion. A 503 with no RA *is* a 503, so the client must perform failover based on RFC 3263 (DNS SRV and so). For how long? No idea, not specified (since no RA present in the 503). The client could try the same server after "some" time. No rules for it. > So how can the text in the next paragraph, say that if you receive any > kind > of 503(even without Retry-After, since it says "if present") you SHOULD > retry somewhere else?? Yes. > And then we have 3263, which generically says "if you receive a 503, you > > should retry the next dns-rr". But since I always see 3261 as the > master-of-all-rules, I intepret this as you should ONLY perform this > retry, > IF the 503 you just got, HAD a Retry-After. No, it's a bad explanation in RFC 3261. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
