Thanks for the response. > I think your interpretation is correct, but I can > see how these statements tend to leave the door > open for a spoiled client (if thats indeed what > you're concerned about):
I mainly just wanted to ensure my interpretation was correct. I want the "forking" (rfc3263 location advancing) benefit of returning a 503. And I don't want the 503 to impact other requests; thus I should not include a retry-after. > My interpretation of the first statement is that > the client should leave the server alone for the > time being. The question is what this "time being" > is going to be. The second statement is letting the > server express its opinion on what the "time being" > SHOULD be. The server does so by including the > Retry-After header and hopes that the client will > honor it. If the server does not include Retry-After, > the client has complete freedom to decide what > the "time being" is going to be. If there is a > lack of alternate servers, the client may keep > hitting the same server without any back off. Unfortunately the Retry-After within a 503 SHOULD impact all requests; and a 500 response does not trigger rfc3263 location advancing. I agree that not sending a retry-after header can leave the UAS susceptible to UAC delay decisions. And if all the resolved locations return a 503 without retry-after, hopefully the UAC will temporarily give up or delay "several seconds" before trying again as mentioned within rfc3261 section 21.5.1. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
