2010/2/5 Brett Tate <[email protected]>: >> When I get a 503 response with retry-after for REGISTER, >> I start a timer for the time in retry-after header but >> would like to know whether there is any upper limit that >> I can have for this timer? > > The UAC is not required to honor all or even part of the Retry-After time. > RFC 3261 section 21.5.4 indicates a SHOULD NOT instead of a MUST NOT. > > "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."
It's very easy to dictate what RFC 3261 says. However, why don't we recognize at last that 503 mechanism *doesn't* work at all? Most of the PSTN gateways translate various ISUP error codes to 503, and it doesn't mean that the gateway is unavailable for calls to same or other destinations, not at all. 503 is used for *anything* so it's not valid to determine that the server/gateway is "unavailable". Please check RFC 5390: ----------------------------------- 5.4. Ambiguous Usages Unfortunately, the specific instances under which a server is to send a 503 are ambiguous. The result is that implementations generate 503 for many reasons, only some of which are related to actual overload. For example, RFC 3398 [RFC3398], which specifies interworking from SIP to ISDN User Part (ISUP), defines the usage of 503 when the gateway receives certain ISUP cause codes from downstream switches. In these cases, the gateway has ample capacity; it's just that this specific request could not be processed because of a downstream problem. All subsequent requests might succeed if they take a different route in the Public Switched Telephone Network (PSTN). ----------------------------------- So for me, all the text in RFC 3261/3263 about 503 doesn't exist as it designed to work in a happy universe so far from here. Let's be more down-to-earth, SIP doesn't work in 80 columns fixed papers, it must work in today real networks. Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
