Thanks all for the comments, any chance this case is clearly specified in up-coming RFC?
Best regards, /Kaiduan ----- Original Message ---- From: Paul Kyzivat <[email protected]> To: [email protected] Sent: Thu, October 28, 2010 4:39:24 PM Subject: Re: [Sip-implementors] SIP Response code for codec mismatch at end On 10/28/2010 4:23 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: [email protected] >[[email protected]] On Behalf Of kaiduan xie >[[email protected]] > > Consider the following case, A sends an offer with codec G.729 only, and B does > not support it, what is the best response code? 415/488 is not for this case > from rfc3261. > > 21.4.13 415 Unsupported Media Type > > The server is refusing to service the request because the message > body of the request is in a format not supported by the server for > the requested method. The server MUST return a list of acceptable > formats using the Accept, Accept-Encoding, or Accept-Language header > field, depending on the specific problem with the content. UAC > processing of this response is described in Section 8.1 > > 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 > > And rfc3264 is not clear on this neither, > > An offered stream MAY be rejected in the answer, for any reason. If > a stream is rejected, the offerer and answerer MUST NOT generate > media (or RTCP packets) for that stream. To reject an offered > stream, the port number in the corresponding stream in the answer > MUST be set to zero. Any media formats listed are ignored. At least > one MUST be present, as specified by SDP. > _______________________________________________ > > You are correct. 415 is only used when the INVITE's body has a type that the >UAS cannot understand. Since the INVITE's body is always application/sdp, >this >is never the case. > > One alternative is to send a 488 response with a 305 warning code. (Provide >sample SDP showing all codecs the phone supports in the response.) Another >alternative is to send 200 OK but in the SDP reject all the media streams. >(But >to provide payload numbers for the codecs that the phone does support so that >someone trying to diagnose the problem can determine what the phone does >support.) After the 200 response, you could send a reINVITE offering whatever you are capable of doing. But I think the odds of the 200 response and followup doing anything useful are slim. Thanks, Paul _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
