Re: [MMUSIC] Last Call: <draft-ietf-mmusic-sdp-g723-g729-04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard

I see your point.

Our opinion was that an RFC that specifies the mapping of media type parameters with SDP and registers the media types with IANA should also describe its usage, especially with the offer/answer model (e.g, RFC435). In that sense we thought draft-ietf-mmusic-sdp-g723-g729 is an update to RFC4856.

Your opinion is that they should be delinked -- one RFC can register the media types and another RFC can describe the usage for the registered media types independently. I am fine with that. The abstract and introduction in draft-ietf-mmusic-sdp-g723-g729 can easily be changed to reflect it.

----------------------------------------------------------------------
Current Abstract:
   RFC4856 describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the Session Description
   protocol(SDP) offer and answer.  This document provides the offer/
   answer considerations for these parameters and updates RFC4856.

New Abstract:
   There are no specifications that describe the offerer and answerer 
   behavior when the value of the annexa parameter of G729 or the annexb 
   parameter of G729, G729D and G729E does not match in the Session 
   Description protocol(SDP) offer and answer. This document provides the 
   offer/answer considerations for these parameters.

Current Introduction:
   [RFC4856] describes the annexa parameter for G723 as follows:

      annexa: indicates that Annex A, voice activity detection, is used
      or preferred.  Permissible values are "yes" and "no" (without the
      quotes); "yes" is implied if this parameter is omitted.

   Also, [RFC4856] describes the annexb parameter for G729, G729D and
   G729E as follows:

      annexb: indicates that Annex B, voice activity detection, is used
      or preferred.  Permissible values are "yes" and "no" (without the
      quotes); "yes" is implied if this parameter is omitted.

   However, it does not have any normative statement for the case where
   the value of this parameter does not match in the SDP [RFC4566] offer
   and answer.  For example, if the offer has G729 with annexb=yes and
   the answer has G729 with annexb=no, it can be interpreted in two
   different ways:
   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=yes, or
   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=no.

   Since [RFC4856] does not state it clearly, various implementations
   have interpreted the offer/answer in their own ways, resulting in a
   different codec being chosen to call failure, when the parameter
   value does not match in the offer and answer.

   [RFC3264] requires SDP extensions that define new fmtp parameters to
   specify their proper interpretation in offer/answer.  But, [RFC4856]
   does not specify it for the Annex A flavor of G723 and the Annex B
   flavors of G729, G729D and G729E.

   This document describes the offer/answer considerations for these
   parameters and provides the necessary clarifications.

New Introduction:
   [RFC4856] describes the annexa parameter for G723 as follows:

      annexa: indicates that Annex A, voice activity detection, is used
      or preferred.  Permissible values are "yes" and "no" (without the
      quotes); "yes" is implied if this parameter is omitted.

   Also, [RFC4856] describes the annexb parameter for G729, G729D and
   G729E as follows:

      annexb: indicates that Annex B, voice activity detection, is used
      or preferred.  Permissible values are "yes" and "no" (without the
      quotes); "yes" is implied if this parameter is omitted.

   However, there is no specification describing the case where the value 
   of this parameter does not match in the SDP [RFC4566] offer and answer.  
   For example, if the offer has G729 with annexb=yes and the answer has 
   G729 with annexb=no, it can be interpreted in two different ways:
   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=yes, or
   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=no.

   Since this is not clearly stated, various implementations have interpreted 
   the offer/answer in their own ways, resulting in a different codec being 
   chosen to call failure, when the parameter value does not match in the 
   offer and answer.

   [RFC3264] requires SDP extensions that define new fmtp parameters to
   specify their proper interpretation in offer/answer. This document 
   describes the offer/answer considerations for these parameters and provides 
   the necessary clarifications.
----------------------------------------------------------------------

Do they address your concerns?

Muthu