at end
On 10/28/2010 4:23 PM, Worley, Dale R (Dale) wrote:
> ________________________________________
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of kaiduan xie
> [kaidu...@yahoo.ca]
>
> 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
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
