> > If it fails during the REINVITE stage I have seen > > UAs send 500 Internal error. Is this correct or > > should it still be 488?
The answer depends upon why it is truly failing the request. For instance, the following rfc3261 section 14.2 snippet shows one of the many reasons why a device may send a 500 response. And even though 491 may be more appropriate in some instances, some devices still send 500 with Retry-After during some glare and other race condition situations. "A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds." > In a UAS 500 means "UAS internal error", so it's > never a proper response. The following RFC 3261 snippet provides what the 500 response means. And similar to proxies, a B2BUA may convert a received 503 to be a 500. "21.5.1 500 Server Internal Error The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds. If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field." > 488 is the correct choice. I agree that it is appropriate when 488 is the best response. If not opposed to 6xx responses, the 606 may be more accurate within some situations; however draft-ietf-sipping-sip-offeranswer-14 just mentions 488. "21.4.26 488 Not Acceptable Here The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
