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

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

We just published the -05 version addressing these comments..

Muthu

|-----Original Message-----
|From: Flemming Andreasen (fandreas)
|Sent: Thursday, January 23, 2014 5:59 AM
|To: SM; Muthu Arul Mozhi Perumal (mperumal); DRAGE, Keith (Keith); Ari Keränen
|Cc: [e-mail]
|Subject: 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
|
|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
|> .
|>