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

[Flemming Andreasen <[e-mail]>]

Greetings

The chairs have reviewed this thread carefully and also discussed it 
with our AD. To conclude, we believe we have concensus to proceed with 
the document as follows:
- The document does not formally update RFC 4856 (or any other RFC) and 
hence the front page and abstract will be updated accordingly.
- The document will remain Standards Track.
- Since the "annexa" and "annexb" parameters are defined in RFC 4856, it 
makes sense to keep the reference to RFC 4856 in the introductory text, 
along the lines of Muthu's suggested "New Introduction" text in the 
previous message in this thread.

If anybody disagrees with this conclusion, please let the chairs know.

Thanks

     Ari & Flemming (MMUSIC co-chairs)




On 12/4/13, 11:54 PM, SM wrote:
> 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
> .
>