Re: [payload] I-D Action: draft-ietf-payload-melpe-05.txt

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

Hi Everyone,

We have reviewed and made a few more changes for RFC 2119 language.  The
note of our changes are below.  Please let us know if any other NITs or
changes are necessary.

Victor and 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 (value shall be -> values are) (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 values are 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.)

10.	Section 2 Second to Last Paragraph (is recommended to follow ->
follows the procedures in)

	(was)
	Comfort noise handling for MELPe is recommended to follow SCIP-210
Appendix B
	[SCIP210].  After VAD no longer indicates the presence of
speech/voice, a grace
	period of a minimum of two comfort noise vocoder fames are to be
transmitted.
	The contents of the comfort noise frames is described in the next
section.

	(now)
	Comfort noise handling for MELPe follows the procedures in SCIP-210
Appendix B
	[SCIP210].  After VAD no longer indicates the presence of
speech/voice, a grace
	period of a minimum of two comfort noise vocoder fames are to be
transmitted.
	The contents of the comfort noise frames is described in the next
section.

11.	Section 3 Second Paragraph (required -> needed)

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

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

12.	Text after Table 3.4 (required -> needed)

	(was)
	Since only msvq[0] (also known as LSF1x or the first LSP) and
gain[1] (also
	known as g2x or the second gain) are required, the following bit
order is used
	for comfort noise frames.

	(now)
	Since only msvq[0] (also known as LSF1x or the first LSP) and
gain[1] (also
	known as g2x or the second gain) are needed, the following bit order
is used
	for comfort noise frames.

13.	Section 3.3 First Paragraph (may -> MAY) (may be required -> is
used)

	(was)
	A MELPe RTP packet may consist of zero or more MELPe coder frames,
followed by
	zero or one MELPe Comfort Noise frames.  The presence of a comfort
noise frame
	can be deduced from the length of the RTP payload.  The default
packetization
	interval is one coder frame (22.5, 67.5 or 90 ms) according to the
coder bit rate
	(2400, 1200 or 600 bps).  For some applications, a longer
packetization
	interval may be required to reduce the packet rate.

	(now)
	A MELPe RTP packet MAY consist of zero or more MELPe coder frames,
followed by
	zero or one MELPe Comfort Noise frames.  The presence of a comfort
noise frame
	can be deduced from the length of the RTP payload.  The default
packetization
	interval is one coder frame (22.5, 67.5 or 90 ms) according to the
coder bit rate
	(2400, 1200 or 600 bps).  For some applications, a longer
packetization
	interval is used to reduce the packet rate.

14.	Section 3.3 Second Paragraph (may -> MAY)

	(was)
	A MELPe RTP packet comprised of no coder frame and no comfort noise
frame may be
	used periodically by an end point to indicate connectivity by an
otherwise idle
	receiver.

	(now)
	A MELPe RTP packet comprised of no coder frame and no comfort noise
frame MAY be
	used periodically by an end point to indicate connectivity by an
otherwise idle
	receiver.

15.	Section 3.3 Second to Last Paragraph (may -> can)

	(was)
	Information describing the number of frames contained in an RTP
packet is not
	transmitted as part of the RTP payload.  The way to determine the
number of
	MELPe frames is to count the total number of octets within the RTP
packet, and
	divide the octet count by the number of expected octets per frame
(7/11/7 per
	frame).  Keep in mind the last frame may be a 2 octet comfort noise
frame.   

	(now)
	Information describing the number of frames contained in an RTP
packet is not
	transmitted as part of the RTP payload.  The way to determine the
number of
	MELPe frames is to count the total number of octets within the RTP
packet, and
	divide the octet count by the number of expected octets per frame
(7/11/7 per
	frame).  Keep in mind the last frame can be a 2 octet comfort noise
frame.   

16.	Section 4.2 Last Paragraph (may -> can)

	(was)
	The value for "packet time" and "maximum packet time" parameters of
the "ptime"
	and "maxptime" SDP attributes respectively, SHALL use the nearest
rounded-up ms
	integer packet duration.  For MELPe, this corresponds to the values:
23, 45,
	68, 90, 112, 135, 156, and 180.  Larger values may be used as long
as they are
	properly rounded.

	(now)
	The value for "packet time" and "maximum packet time" parameters of
the "ptime"
	and "maxptime" SDP attributes respectively, SHALL use the nearest
rounded-up ms
	integer packet duration.  For MELPe, this corresponds to the values:
23, 45,
	68, 90, 112, 135, 156, and 180.  Larger values can be used as long
as they are
	properly rounded.

17.	Section 4.3 First Paragraph (may -> MAY)

	(was)
	For declarative media, the "bitrate" parameter specifes the possible
bit rates
	used by the sender.  Multiple MELPe rtpmap values (such as 97, 98,
and 99 as
	used below) may be used to convey MELPe coded voice at different bit
rates.
	The receiver can then select an appropriate MELPe codec by using 97,
98, or 99.

	(now)
	For declarative media, the "bitrate" parameter specifes the possible
bit rates
	used by the sender.  Multiple MELPe rtpmap values (such as 97, 98,
and 99 as
	used below) MAY be used to convey MELPe coded voice at different bit
rates.
	The receiver can then select an appropriate MELPe codec by using 97,
98, or 99.

18. Section 4.4 First Two Paragraphs (may -> MAY) (may -> MAY) (may -> MAY)

	(was)
	In an Offer/Answer mode [RFC3264], "bitrate" is a bi-directional
parameter.
	Both sides MUST use a common "bitrate" value or values.  The offer
contains the
	bit rates supported by the offerer listed in its preferred order.
The answerer
	may agree to any bit rate by listing the bit rate first in the
answerer
	response.  Additionally the answerer may indicate any secondary bit
rate or bit
	rates that it supports.  The initial bit rate used by both parties
SHALL be the
	first bit rate specified in the answerer response. 

	For example if offerer bit rates are "2400,600", and answer bit
rates are "600,2400",
	the initial bit rate is 600.  If other bit rates are provided by the
answerer, any
	common bit rate between offer and answer may be used at any time in
the future.  
	Activation of these other common bit rates is beyond the scope of
this document.

	(now)
	In an Offer/Answer mode [RFC3264], "bitrate" is a bi-directional
parameter.
	Both sides MUST use a common "bitrate" value or values.  The offer
contains the
	bit rates supported by the offerer listed in its preferred order.
The answerer
	MAY agree to any bit rate by listing the bit rate first in the
answerer
	response.  Additionally the answerer MAY indicate any secondary bit
rate or bit
	rates that it supports.  The initial bit rate used by both parties
SHALL be the
	first bit rate specified in the answerer response. 

	For example if offerer bit rates are "2400,600", and answer bit
rates are "600,2400",
	the initial bit rate is 600.  If other bit rates are provided by the
answerer, any
	common bit rate between offer and answer MAY be used at any time in
the future.  
	Activation of these other common bit rates is beyond the scope of
this document.

19.	Section 5 (review)

	(is)
	A primary application of MELPe is for radio communications of voice
	conversations and discontinuous transmissions are normal.  When
MELPe is used
	in an IP network, MELPe RTP packet transmissions may cease and
resume
	frequently.  RTP SSRC sequence number gaps indicate lost packets to
be filled 
	by PLC while abrupt loss of RTP packets indicate intended
discontinuous 
	transmission.

	If a MELPe coder so desires, it may send a comfort noise frame as
per SCIP-210
	Appendix B [SCIP210] prior to ceasing transmission.  A receiver may
optionally
	use comfort noise during its silence periods. No SDP negotiations
are
	required.

	(review)
	This uses "may" three times and "required" and "optionally" one
each.  Should any
	be capitalized or changed to a different word?



-----Original Message-----
From: payload [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Friday, January 20, 2017 4:35 PM
To: [e-mail]
Cc: [e-mail]
Subject: [payload] I-D Action: draft-ietf-payload-melpe-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Audio/Video Transport Payloads of the IETF.

        Title           : RTP Payload Format for MELPe Codec
        Authors         : Victor Demjanenko
                          David Satterlee
	Filename        : draft-ietf-payload-melpe-05.txt
	Pages           : 28
	Date            : 2017-01-20

Abstract:
   This document describes the RTP payload format for the Mixed
   Excitation Linear Prediction Enhanced (MELPe) speech coder.  MELPe's
   three different speech encoding rates and sample frames sizes are
   supported.  Comfort noise procedures and packet loss concealment are
   detailed.

INTERNET DRAFT   RTP Payload Format for the MELPe Codec January 20, 2017



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-payload-melpe-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-melpe-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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