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

[SM <[e-mail]>]

Hi Muthu,
At 20:13 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote:
>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.

Yes, but you can have both in one RFC.  The registration can be 
requested in the IANA Considerations section.

>---------------------------------------------------------------------
>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.

I suggest removing "there are no specifications ..." and explain what 
the document specifies.

>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.

The above starts with RFC 4856.  I suggest starting with the RFC 4566 
followed by the RFC 3264 text (I did not verify the reference).  You 
can then specify the fmtp parameters for Annex A, etc.  Once you have 
done that, verify whether there are some registry requirements and 
add text for that in a IANA Considerations section.

Regards,
-sm