Re: [payload] WGLC on draft-ietf-payload-melpe-02

["Victor Demjanenko, Ph.D." <[e-mail]>]

To Payload Members:

 

We have addressed all of Roni's comments with the exception of item 2.
Comments on all other items are below in the original list.

 

In response to item 2, we recommend leaving sections 3.1 and 3.2 the way
they are.  Each of the three MELP speech coder rates were developed by
different groups.  The notation that each one used is similar but different.


 

1.      One group presented their bits in LSB to MSB order.  This was a
potential confusion that our draft cleared up with at least one party
implementing a MELP RTP payload.  (They did not notice the inconsistency
between speech coder rates until reading our draft.)

2.      The MS Word typesetting nomenclature used non-simple ASCII
parameter/field names/bit numbering which is addressed by the normalized
tables we present in these sections.  

3.      Comfort noise is described in yet some other document (SCIP I
believe) and is only done verbally.

 

While we do understand the desire for removing unnecessary redundancy, we do
believe our normalized tables in 3.1 and 3.2 do help in ensuring an
interoperable implementation.  As such, they are not an exact copy of
reference tables and we recommend leaving these sections as we have written.

 

Regards,

 

Victor Demjanenko

David Satterlee

 

 

From: Roni Even [mailto:[e-mail]] 
Sent: Monday, August 8, 2016 5:40 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: WGLC on draft-ietf-payload-melpe-02

 

Hi,

I reviewed the document and have some comments

 

1.      In the abstract you can delete the last sentence "Also, within the
document there are included necessary details for the use of MELP with SDP."


v-> Done

2.      I assume that sections 3.1.1, 3.1.2, 3.1.3, 3.2 are copied from
STANAG 4591 in which case you can just provide a reference to the relevant
sections

v-> We recommend leaving the normalized tables to clear up potential
confusion

3.      In section 3.3 it looks like a MELPE packet can be of zero coded
frame and zero comfort noise frame?

v-> We added a sentence to clarify and permit such use.  This could be used
for encoder connectivity confirmation and not specifically as an RTP
keep-alive (which is specifically different and outside this recommended
purpose.)

4.      For section 3.4 look at RFC7587 section 5 for text suggestions

v-> Section 3.4 replaced by recommended text from RFC7587.

5.      In section 4.1 the type name is audio while the subtype names are
MELP,.

v-> The name and subtype name have been corrected.

6.      In section 4.1 published specification "RFCXXXX" to be replaced by
the RFC Editor

v-> RFCXXXX was replaced with RFC6562.

7.      In section 4.2 we do not use MIME but "media type" (audio) and
"media subtype " (MELPE,.)

v-> The word MIME has been removed and "media" added where needed.

8.      The following text is not clear "A remote MELPe encoder SHALL
receive "bitrate" parameter in the SDP "a=fmtp" attribute by copying them
directly from the MIME media type string as a semicolon separated with
parameter=value, where parameter is "bitrate", and value can be one or more
of 2400, 1200, and 600 separated by commas (where each bit-rate value
indicates the corresponding MELPe coder). Is this for the an offer?

v-> The language has been changed to "The optional media type parameter,
"bitrate", when present, MUST be included in the "a=fmtp" attribute in the
SDP, expressed as a media type string in the form of a semicolon-separated
list of parameter=value pairs.  The string, "value", can be one or more of
2400, 1200, and 600 separated by commas (where each bit-rate value indicates
the corresponding MELPe coder)."

v-> The bitrate parameter can be used by both offerer and answerer as the
example suggests in a later example (now in a new section 4.4

9.      We use "For declarative SDP" and not "For streaming media". It also
better to have a sub section for SDP offer answer considerations and
Declarative SDP considerations

v-> Sections 4.3 and 4.4 have been added for declarative SDP and
offer/answer SDP.  Paragraphs that originally followed offer/answer SDP have
been moved up as they apply to all SDP.

10.   In section 8 "its media decoder" use "the MELPe encoder"

v-> Text now uses "the MELPe decoder".

 

Roni Even

 

From: Roni Even [mailto:[e-mail]] 
Sent: Tuesday, July 26, 2016 9:24 AM
To: '[e-mail]' ([e-mail])
Cc: '[e-mail]'
Subject: WGLC on draft-ietf-payload-melpe-02

 

Hi,

I would like to start a WGLC on
https://tools.ietf.org/html/draft-ietf-payload-melpe-02  , RTP Payload
Format for MELPe Codec
 
 
 

The WGLC will end on August 9th , 2016

 

Please review the draft and send comments to the list.

 

For the draft authors;  Are you aware of any IPR that applies to
draft-ietf-payload-melpe-02? 

If so, has this IPR been disclosed in compliance with IETF IPR rules?

The above question is needed for the document write-up when sent to
publication.
 
 

Thanks

 

Roni Even

Payload  co-chair