Re: [payload] Review of draft-ietf-payload-melpe-04

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

Hi Everyone,

I would like to thank everyone for their comments and specific improvements
to our document, draft-ietf-payload-melpe-04.  We will produce a full
document after any responses to this email are collected.  We have made the
suggested changes and have the following detailed notes.  If anyone can spot
other deficiencies or NITS we would be happy to correct them in hopefully
this last pass.

Regards,

Victor & Dave


1.	Corrected Spelling - (Declaritive -> Declarative)

	3 places (table of contents and section 4.3 twice)

2.	Section 3 Improvement (removed last sentence, combined paragraphs,
referenced 
	Figure 1 explicitly)

	(was)
	The RTP payload for MELPe has the format shown in the figure below.
No
	additional header specific to this payload format is required. 

	This format is intended for the situations where the sender and the
receiver
	send one or more codec data frames per packet. The RTP packet looks
as follows:

	(now)
	The RTP payload for MELPe has the format shown in Figure 1.  No
additional
	header specific to this payload format is required.  This format is
intended
	for the situations where the sender and the receiver send one or
more codec
	data frames per packet. 

3.	Section 3.1 Improvement (last sentence improved)

	(was)
	The total number of bits used to describe one frame of 2400 bps
speech is 54,
	which fits in 7 octets (with two unused bits). For the 1200 bps
speech the total
	number of bits used is 81, which fits in 11 octets (with seven
unused bits).
	For the 600 bps speech the total number of bits used is 54, which
fits in 7
	octets (with two unused bits).  Unused bits are coded as described
in 3.3 in
	support of dynamic bit-rate switching.

	(now)
	The total number of bits used to describe one frame of 2400 bps
speech is 54,
	which fits in 7 octets (with two unused bits). For the 1200 bps
speech the
	total number of bits used is 81, which fits in 11 octets (with seven
unused
	bits).  For the 600 bps speech the total number of bits used is 54,
which fits
	in 7 octets (with two unused bits).  Unused bits, shown below as
RSVA, RSVB,
	etc., are coded as described in 3.3 in support of dynamic bit-rate
switching.

4.	Table 3.4 Note (recommended -> preferred)

	(was)
	Note: The default value shall be the respective parameters from the
vocoder
	frame.  It is recommended that msvq[0] and gain[1] values be derived
by
	averaging the respective parameter from some number of previous
vocoder frames.

	(now)
	Note: The default value shall be the respective parameters from the
vocoder
	frame.  It is preferred that msvq[0] and gain[1] values be derived
by
	averaging the respective parameter from some number of previous
vocoder frames.

5.	Section 3.3 Last Paragraph (recommended -> RECOMMENDED)

	(was)
	When dynamic bit-rate switching is used and more than one frame is
contained in a
	RTP packet, it is recommended to inspect the coder rate bits
contained in the 
	last octet.  If the coder bit rate indicates a Comfort Noise frame,
then inspect 
	the third last octet for the coder bit rate.  All MELPe speech
frames in the RTP
	packet will be of this same coder bit rate.

	(now)
	When dynamic bit-rate switching is used and more than one frame is
contained in a
	RTP packet, it is RECOMMENDED to inspect the coder rate bits
contained in the 
	last octet.  If the coder bit rate indicates a Comfort Noise frame,
then inspect 
	the third last octet for the coder bit rate.  All MELPe speech
frames in the RTP
	packet will be of this same coder bit rate.

6.	Section 3.4 First Paragraph (efficient congestion control ->
congestion 
	management) and (the transmission rate -> packet rate)

	(was)
	The target bitrate of MELPe can be adjusted at any point in time,
thus allowing
	efficient congestion control.  Furthermore, the amount of encoded
speech or
	audio data encoded in a single packet can be used for congestion
control, since
	the transmission rate is inversely proportional to the packet
duration.  A
	lower packet transmission rate reduces the amount of header
overhead, but at
	the same time increases latency and loss sensitivity, so it ought to
be used
	with care.

	(now)
	The target bitrate of MELPe can be adjusted at any point in time,
thus allowing
	congestion management.  Furthermore, the amount of encoded speech or
	audio data encoded in a single packet can be used for congestion
control, since
	packet rate is inversely proportional to the packet duration.  A
	lower packet transmission rate reduces the amount of header
overhead, but at
	the same time increases latency and loss sensitivity, so it ought to
be used
	with care.

7.	Section 4.2 Third Paragraph (may -> MAY)

	(was)
	When conveying information by SDP, the encoding name SHALL be "MELP"

	(the same as the media subtype).  Alternative encoding name types,
"MELP2400", 
	"MELP1200", and "MELP600", may be used in SDP to convey fixed
bit-rate 
	configurations.  These names have been observed in systems that do
not 
	support dynamic frame rate switching as specified by the parameter,
"bitrate".

	(now)
	When conveying information by SDP, the encoding name SHALL be "MELP"

	(the same as the media subtype).  Alternative encoding name types,
"MELP2400", 
	"MELP1200", and "MELP600", MAY be used in SDP to convey fixed
bit-rate 
	configurations.  These names have been observed in systems that do
not 
	support dynamic frame rate switching as specified by the parameter,
"bitrate".

8.	Section 6 First Paragraph (may utilize -> utilizes) and (recommended
-> preferred)

	(was)
	MELPe packet loss concealment (PLC) uses the special properties and
coding for
	the pitch/voicing parameter of the MELPe 2400 bps coder.  The PLC
erasure
	indication may utilize any of the errored encodings of a non-voiced
frame as
	identified in Table 1 of [MELPE].  For the sake of simplicity it is
recommended
	to use a code value of 3 for the pitch/voicing parameter
(represented by the
	bits P6 to P0 in Table 3.1).  Hence, set bits P0 and P1 to one and
bits
	P2, P3, P4, P5, and P6 to zero.

	(now)
	MELPe packet loss concealment (PLC) uses the special properties and
coding for
	the pitch/voicing parameter of the MELPe 2400 bps coder.  The PLC
erasure
	indication utilizes any of the errored encodings of a non-voiced
frame as
	identified in Table 1 of [MELPE].  For the sake of simplicity it is
preferred
	to use a code value of 3 for the pitch/voicing parameter
(represented by the
	bits P6 to P0 in Table 3.1).  Hence, set bits P0 and P1 to one and
bits
	P2, P3, P4, P5, and P6 to zero.


9.	References (MELP, MELPE and SCIP210 are now normative)

	(I could not find meaningful URI for documents.  Available from
various search 
	pages.)


-----Original Message-----
From: Roni Even [mailto:[e-mail]] 
Sent: Monday, December 26, 2016 3:37 AM
To: 'Dave Satterlee (Vocal)'; [e-mail]
Cc: Ali C. Begen
Subject: FW: [payload] Review of draft-ietf-payload-melpe-04

Hi guys,
These comments make sense.
Please look at  using capital letters for RFC2119 language and if not meant
to be RFC2119 try using other words to replace.
As for the reference, I agree that they must be normative.
You can respond to the mail on the list but wait for the IETF last call to
finish before updating since there may be other comments

Thanks
Roni

-----Original Message-----
From: payload [mailto:[e-mail]] On Behalf Of Carlos
Pignataro
Sent: Monday, December 26, 2016 4:13 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [payload] Review of draft-ietf-payload-melpe-04

Reviewer: Carlos Pignataro
Review result: Has Nits

Hi,

This document is mostly ready but has some potential issues:

1. Normative statements -- there are a number of "recommended" and "shall"
among "RECOMMENDED" and "SHALL". It would not hurt to revise and confirm the
normative level of each of these.

Specifically, a couple of these relate to one operational aspect of Default
values:
E.g.:
          Note: The default value shall be the respective parameters
          from the vocoder frame.  It is recommended that msvq[0] and
          gain[1] values be derived by averaging the respective
          parameter from some number of previous vocoder frames.

Should thouse be normative / uppercase as per its operational implications?

2. References

It is not entirely clear to me that the references are adequately split in
Normative vs. Informative.

I understand these three for example are not produced by the IETF; but are
they necessary to understand the spec?

   [MELP] Department of Defense Telecommunications Standard,
"Analog-to-
   Digital Conversion of Voice by 2,400 Bit/Second Mixed Excitation
   Linear Prediction (MELP)", MIL-STD-3005, December 1999.

   [MELPE] North Atlantic Treaty Organization (NATO), "The 600 Bit/S,
   1200 Bit/S and 2400 Bit/S NATO Interoperable Narrow Band Voice
   Coder", STANAG No. 4591, January 2006.

   [SCIP210] National Security Agency, "SCIP Signaling Plan", SCIP-210,
   December 2007.

Also, sure, a google search can find them (I believe), but is there an
authoritative pointer (URI) where these can be normatively found?

Thanks,

-- Carlos.

_______________________________________________
payload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/payload