I think it is clear once you carefully read the descriptions in RFC3261. 415 relates to the format of the content in the SIP message body. So 415 is most commonly used where there is a Content-Type that the receiver cannot understand. I think it is mandatory that SIP implementations understand SDP. If I am right then a 415 should never be sent in response to a SIP INVITE with Content-Type: application/sdp.
488 is specifically for session descriptions (SDP's). So if you don't support any of the listed codecs then 488 is correct. Regards Attila -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of kaiduan xie Sent: 29 October 2010 00:25 To: Paul Kyzivat; [email protected] Subject: Re: [Sip-implementors] SIP Response code for codec mismatch 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
