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

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Aug 2016 00:40:28 +0300

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

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

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

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

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

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

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

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?

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

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

Roni Even

From: Roni Even [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2016 9:24 AM
To: [email-masked]' ([email-masked])
Cc: [email-masked]'
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

---

From: "Victor Demjanenko, Ph.D." <[email-masked]>
Date: Fri, 19 Aug 2016 10:30:13 -0400

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:[email-masked]] 
Sent: Monday, August 8, 2016 5:40 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: WGLC on draft-ietf-payload-melpe-02

Hi,

v-> Done

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

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

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

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

v-> RFCXXXX was replaced with RFC6562.

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

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

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.

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

Roni Even

Hi,

 

Thanks

Roni Even

Payload  co-chair