As far as I can tell, a 406 is returned when the UAS on the other side cannot 
formulate a response with content-type acceptable to the sender (as indicated in the 
Accept-header it sent). A 488 is returned when the UAS can satisfy the Accept-header 
but the session description in the request is not acceptable. There is also a 606 
which tells that ALL UASs for that user don't accept the session description (a 488 
only rejects the request to that particular R-URI).

There might be a bug in bis-09 (Jonathan, we need your comments here). More comments 
below.

Regards,
Hisham

> -----Original Message-----
> From: ext Feldman, Michael [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 21, 2002 6:45 PM
> To: [EMAIL PROTECTED]
> Subject: [Sip-implementors] 406 vs 488 responses
> 
> 
> When should a 406 (Not Acceptable) be sent verse a 488 (Not Acceptable
> Here)?
> 
> 
> the UPDATE draft mentions 
>       an update could be reject a codec change with a 488, 
> the bis9 draft mentions
>       a Re-INVITE codec change is rejected with a 406 or a 488?
> 
> thanks,
> mike feldman
> [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> bis9 page 18, section 4:
> 
> This is accomplished by sending a re-INVITE containing a new media
> description. This
> re-INVITE references the existing dialog so that the other 
> party knows that
> it is to
> modify an existing session instead of establishing a new 
> session.  The other
> party 
> sends a 200 (OK) to accept the change. The requestor responds 
> to the 200
> (OK) with an 
> ACK. If the other party does not accept the change, he sends an error
> response such as
> 406 (Not Acceptable), which also receives an ACK.


This is a bug, it should be 488.


> 
> but bis 9 in section 14.2 page 90:
> If the new session description is not acceptable, the UAS can 
> reject it by
> returning a 488 (Not Acceptable Here) response to the re-invite.
> 
> 
> draft-ietf-sip-update-02,  section 5.2:
> 
> If the new session description is not acceptable, the UAS can 
> reject it by
> returning a 
> 488 (Not Acceptable Here) response for the UPDATE. 

This is correct.

> 
> 
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to