draft-ietf-payload-melpe-04.txt   draft-ietf-payload-melpe-05.txt 
Payload Working Group Victor Demjanenko Payload Working Group Victor Demjanenko
Internet-Draft David Satterlee Internet-Draft David Satterlee
Intended Status: Standards Track VOCAL Technologies, Ltd. Intended Status: Standards Track VOCAL Technologies, Ltd.
Expires: June 16, 2017 December 13, 2016 Expires: July 24, 2017 January 20, 2017
RTP Payload Format for MELPe Codec RTP Payload Format for MELPe Codec
draft-ietf-payload-melpe-04 draft-ietf-payload-melpe-05
Status of this Memo Status of this Memo
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3.1 MELPe Bitstream Definition . . . . . . . . . . . . . . . . 5 3.1 MELPe Bitstream Definition . . . . . . . . . . . . . . . . 5
3.1.1 2400 bps Bitstream Structure . . . . . . . . . . . . . . 6 3.1.1 2400 bps Bitstream Structure . . . . . . . . . . . . . . 6
3.1.2 1200 bps Bitstream Structure . . . . . . . . . . . . . . 8 3.1.2 1200 bps Bitstream Structure . . . . . . . . . . . . . . 8
3.1.3 600 bps Bitstream Structure . . . . . . . . . . . . . . 11 3.1.3 600 bps Bitstream Structure . . . . . . . . . . . . . . 11
3.2 MELPe Comfort Noise Bitstream Definition . . . . . . . . . 15 3.2 MELPe Comfort Noise Bitstream Definition . . . . . . . . . 15
3.3 Multiple MELPe frames in a RTP packet . . . . . . . . . . . 17 3.3 Multiple MELPe frames in a RTP packet . . . . . . . . . . . 17
3.4 Congestion Control Considerations . . . . . . . . . . . . . 19 3.4 Congestion Control Considerations . . . . . . . . . . . . . 19
4 Payload Format Parameters . . . . . . . . . . . . . . . . . . . 19 4 Payload Format Parameters . . . . . . . . . . . . . . . . . . . 19
4.1 Media Type Definition . . . . . . . . . . . . . . . . . . . 20 4.1 Media Type Definition . . . . . . . . . . . . . . . . . . . 20
4.2 Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 22 4.2 Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Declaritive SDP Considerations . . . . . . . . . . . . . . 23 4.3 Declarative SDP Considerations . . . . . . . . . . . . . . 23
4.4 Offer/Answer SDP Considerations . . . . . . . . . . . . . . 24 4.4 Offer/Answer SDP Considerations . . . . . . . . . . . . . . 24
5 Discontinious Transmission . . . . . . . . . . . . . . . . . . 24 5 Discontinious Transmission . . . . . . . . . . . . . . . . . . 24
6 Packet Loss Concealment . . . . . . . . . . . . . . . . . . . . 24 6 Packet Loss Concealment . . . . . . . . . . . . . . . . . . . . 24
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 26
9 RFC Editor Considerations . . . . . . . . . . . . . . . . . . . 26 9 RFC Editor Considerations . . . . . . . . . . . . . . . . . . . 26
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1 Normative References . . . . . . . . . . . . . . . . . . . 26 10.1 Normative References . . . . . . . . . . . . . . . . . . . 26
10.2 Informative References . . . . . . . . . . . . . . . . . . 27 10.2 Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1 Introduction 1 Introduction
This document describes how compressed MELPe speech as produced by This document describes how compressed MELPe speech as produced by
the MELPe codec may be formatted for use as an RTP payload. Details the MELPe codec may be formatted for use as an RTP payload. Details
are provided to packetize the three different codec bit-rate data are provided to packetize the three different codec bit-rate data
frames (2400, 1200, and 600) into RTP packets. The sender may send frames (2400, 1200, and 600) into RTP packets. The sender may send
one or more codec data frames per packet, depending on the one or more codec data frames per packet, depending on the
application scenario or based on the transport network condition, application scenario or based on the transport network condition,
skipping to change at page 4, line 18 skipping to change at page 4, line 18
The MELPe algorithm distinguishes between voiced and un-voiced speech The MELPe algorithm distinguishes between voiced and un-voiced speech
and encodes each differently. Unvoiced speech can be coded with and encodes each differently. Unvoiced speech can be coded with
fewer information bits for the same quality. Forward error fewer information bits for the same quality. Forward error
correction (FEC) is applied to the 2400 bps codec unvoiced speech for correction (FEC) is applied to the 2400 bps codec unvoiced speech for
better protection of the subtle differences in signal reconstruction. better protection of the subtle differences in signal reconstruction.
The lower bit-rate coders do not allocate any bits for FEC and rely The lower bit-rate coders do not allocate any bits for FEC and rely
on strong error protection and correction in the communications on strong error protection and correction in the communications
channel. channel.
Comfort noise handling for MELPe is recommended to follow SCIP-210 Comfort noise handling for MELPe follows the procedures in SCIP-210
Appendix B [SCIP210]. After VAD no longer indicates the presence of Appendix B [SCIP210]. After VAD no longer indicates the presence of
speech/voice, a grace period of a minimum of two comfort noise speech/voice, a grace period of a minimum of two comfort noise
vocoder fames are to be transmitted. The contents of the comfort vocoder fames are to be transmitted. The contents of the comfort
noise frames is described in the next section. noise frames is described in the next section.
Packet loss concealment (PLC) exploits the FEC (and more precisely, Packet loss concealment (PLC) exploits the FEC (and more precisely,
any combination of two set bits in the pitch/voicing parameter) of any combination of two set bits in the pitch/voicing parameter) of
the 2400 bps speech coder. The pitch/voicing parameter has a sparse the 2400 bps speech coder. The pitch/voicing parameter has a sparse
set of permitted values. A value of zero indicates a non-voiced set of permitted values. A value of zero indicates a non-voiced
frame. At least three bits are set for all valid pitch parameters. frame. At least three bits are set for all valid pitch parameters.
The PLC erasure indication utilizes any of the two bit set The PLC erasure indication utilizes any of the two bit set
errored/erasure encodings of a non-voiced frame as will be described errored/erasure encodings of a non-voiced frame as will be described
infra. infra.
3 Payload Format 3 Payload Format
The MELPe codec uses 22.5, 67.5 or 90 ms frames with a sampling rate The MELPe codec uses 22.5, 67.5 or 90 ms frames with a sampling rate
clock of 8 kHz, so the RTP timestamp MUST be in units of 1/8000 of a clock of 8 kHz, so the RTP timestamp MUST be in units of 1/8000 of a
second. second.
The RTP payload for MELPe has the format shown in the figure below. The RTP payload for MELPe has the format shown in Figure 1. No
No additional header specific to this payload format is required. additional header specific to this payload format is needed. This
format is intended for the situations where the sender and the
This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet.
receiver send one or more codec data frames per packet. The RTP
packet looks as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | |
+ one or more frames of MELPe | + one or more frames of MELPe |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 38 skipping to change at page 5, line 38
It is expected that the RTP profile for a particular class of It is expected that the RTP profile for a particular class of
applications will assign a payload type for this encoding, or if that applications will assign a payload type for this encoding, or if that
is not done, then a payload type in the dynamic range shall be chosen is not done, then a payload type in the dynamic range shall be chosen
by the sender. by the sender.
3.1 MELPe Bitstream Definition 3.1 MELPe Bitstream Definition
The total number of bits used to describe one frame of 2400 bps 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 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 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 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 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 bits). Unused bits, shown below as RSVA, RSVB, etc., are coded as
dynamic bit-rate switching. described in 3.3 in support of dynamic bit-rate switching.
In the MELPe bitstream definition, the most significant bits are In the MELPe bitstream definition, the most significant bits are
considered priority bits. The intention was that these bits receive considered priority bits. The intention was that these bits receive
greater protection in the underlying communications channel. For IP greater protection in the underlying communications channel. For IP
networks, such additional protection is irrelevant. However, for networks, such additional protection is irrelevant. However, for
convenience of interoperable gateway devices, the bitstreams will be convenience of interoperable gateway devices, the bitstreams will be
presented identically in IP networks. presented identically in IP networks.
3.1.1 2400 bps Bitstream Structure 3.1.1 2400 bps Bitstream Structure
skipping to change at page 16, line 31 skipping to change at page 16, line 31
+-------------------------------------+----------------+ +-------------------------------------+----------------+
| pitch (pitch - overall voicing) | Set to 0 | | pitch (pitch - overall voicing) | Set to 0 |
+-------------------------------------+----------------+ +-------------------------------------+----------------+
| bp (bandpass voicing) | Set to 0 | | bp (bandpass voicing) | Set to 0 |
+-------------------------------------+----------------+ +-------------------------------------+----------------+
| af (aperiodic flag/jitter index) | Set to 0 | | af (aperiodic flag/jitter index) | Set to 0 |
+-------------------------------------+----------------+ +-------------------------------------+----------------+
| sync (sync bit) | Alternations | | sync (sync bit) | Alternations |
+-------------------------------------+----------------+ +-------------------------------------+----------------+
Note: The default value shall be the respective parameters Note: The default values are the respective parameters from
from the vocoder frame. It is recommended that msvq[0] and the vocoder frame. It is preferred that msvq[0] and gain[1]
gain[1] values be derived by averaging the respective values be derived by averaging the respective parameter from
parameter from some number of previous vocoder frames. some number of previous vocoder frames.
Table 3.4 - MELPe Comfort Noise Parameters Table 3.4 - MELPe Comfort Noise Parameters
Since only msvq[0] (also known as LSF1x or the first LSP) and gain[1] 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 (also known as g2x or the second gain) are needed, the following bit
bit order is used for comfort noise frames. order is used for comfort noise frames.
+--------+-------------+ +--------+-------------+
| Bit | Comfort | | Bit | Comfort |
| | Noise | | | Noise |
+--------+-------------+ +--------+-------------+
| B_01 | LSF10 | | B_01 | LSF10 |
| B_02 | LSF11 | | B_02 | LSF11 |
| B_03 | LSF12 | | B_03 | LSF12 |
| B_04 | LSF13 | | B_04 | LSF13 |
| B_05 | LSF14 | | B_05 | LSF14 |
skipping to change at page 17, line 49 skipping to change at page 17, line 49
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 | | B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| RSVA | RSVB | RSVC | B_13 | B_12 | B_11 | B_10 | B_09 | | RSVA | RSVB | RSVC | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
Figure 5 - Packed MELPe Comfort Noise payload octets. Figure 5 - Packed MELPe Comfort Noise payload octets.
3.3 Multiple MELPe frames in a RTP packet 3.3 Multiple MELPe frames in a RTP packet
A MELPe RTP packet may consist of zero or more MELPe coder frames, 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 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 a comfort noise frame can be deduced from the length of the RTP
payload. The default packetization interval is one coder frame 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 (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 600 bps). For some applications, a longer packetization interval is
be required to reduce the packet rate. used to reduce the packet rate.
A MELPe RTP packet comprised of no coder frame and no comfort noise A MELPe RTP packet comprised of no coder frame and no comfort noise
frame may be used periodically by an end point to indicate frame MAY be used periodically by an end point to indicate
connectivity by an otherwise idle receiver. connectivity by an otherwise idle receiver.
All MELPe frames in a single RTP packet MUST be of the same coder bit All MELPe frames in a single RTP packet MUST be of the same coder bit
rate. Dynamic switching between frame rates within an RTP stream may rate. Dynamic switching between frame rates within an RTP stream may
be permitted (if supported by both ends) provided that reserved bits, be permitted (if supported by both ends) provided that reserved bits,
RSVA, RSVB, and RSVC are filled in as per Table 3.6. If bit-rate RSVA, RSVB, and RSVC are filled in as per Table 3.6. If bit-rate
switching is not used, all reserved bits are encoded as 0 by the switching is not used, all reserved bits are encoded as 0 by the
sender and ignored by the receiver. (RSV0 is always coded as 0). sender and ignored by the receiver. (RSV0 is always coded as 0).
+-------------------+------+------+------+ +-------------------+------+------+------+
skipping to change at page 19, line 13 skipping to change at page 19, line 13
then the fewer frames per packet the lower the delay, whereas for then the fewer frames per packet the lower the delay, whereas for
bandwidth constrained links or delay insensitive streaming messaging bandwidth constrained links or delay insensitive streaming messaging
application, more than one or many frames per packet would be application, more than one or many frames per packet would be
acceptable. acceptable.
Information describing the number of frames contained in an RTP Information describing the number of frames contained in an RTP
packet is not transmitted as part of the RTP payload. The way to 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 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 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 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. the last frame can be a 2 octet comfort noise frame.
When dynamic bit-rate switching is used and more than one frame is 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 contained in a RTP packet, it is RECOMMENDED to inspect the coder
rate bits contained in the last octet. If the coder bit rate rate bits contained in the last octet. If the coder bit rate
indicates a Comfort Noise frame, then inspect the third last octet indicates a Comfort Noise frame, then inspect the third last octet
for the coder bit rate. All MELPe speech frames in the RTP packet for the coder bit rate. All MELPe speech frames in the RTP packet
will be of this same coder bit rate. will be of this same coder bit rate.
3.4 Congestion Control Considerations 3.4 Congestion Control Considerations
The target bitrate of MELPe can be adjusted at any point in time, The target bitrate of MELPe can be adjusted at any point in time,
thus allowing efficient congestion control. Furthermore, the amount thus allowing congestion management. Furthermore, the amount of
of encoded speech or audio data encoded in a single packet can be encoded speech or audio data encoded in a single packet can be used
used for congestion control, since the transmission rate is inversely for congestion control, since packet rate is inversely proportional
proportional to the packet duration. A lower packet transmission to the packet duration. A lower packet transmission rate reduces the
rate reduces the amount of header overhead, but at the same time amount of header overhead, but at the same time increases latency and
increases latency and loss sensitivity, so it ought to be used with loss sensitivity, so it ought to be used with care.
care.
Since UDP does not provide congestion control, applications that use Since UDP does not provide congestion control, applications that use
RTP over UDP SHOULD implement their own congestion control above the RTP over UDP SHOULD implement their own congestion control above the
UDP layer [RFC5405]. Work in the RMCAT working group [rmcat] UDP layer [RFC5405]. Work in the RMCAT working group [rmcat]
describes the interactions and conceptual interfaces necessary describes the interactions and conceptual interfaces necessary
between the application components that relate to congestion control, between the application components that relate to congestion control,
including the RTP layer, the higher-level media codec control layer, including the RTP layer, the higher-level media codec control layer,
and the lower-level transport interface, as well as components and the lower-level transport interface, as well as components
dedicated to congestion control functions. dedicated to congestion control functions.
skipping to change at page 22, line 26 skipping to change at page 22, line 26
o The media type ("audio") goes in SDP "m=" as the media name. o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype (payload format name) goes in SDP "a=rtpmap" o The media subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. as the encoding name.
o The parameter "bitrate" goes in the SDP "a=fmtp" attribute by o The parameter "bitrate" goes in the SDP "a=fmtp" attribute by
copying it directly from the media type string as "bitrate=value" or copying it directly from the media type string as "bitrate=value" or
"bitrate=value1,value2" or "bitrate=value1,value2,value3". "bitrate=value1,value2" or "bitrate=value1,value2,value3".
When conveying information by SDP, the encoding name SHALL be "MELP" When conveying information by SDP, the encoding name SHALL be "MELP"
(the same as the media subtype). Alternative encoding name types, (the same as the media subtype). Alternative encoding name types,
"MELP2400", "MELP1200", and "MELP600", may be used in SDP to convey "MELP2400", "MELP1200", and "MELP600", MAY be used in SDP to convey
fixed bit-rate configurations. These names have been observed in fixed bit-rate configurations. These names have been observed in
systems that do not support dynamic frame rate switching as specified systems that do not support dynamic frame rate switching as specified
by the parameter, "bitrate". by the parameter, "bitrate".
An example of the media representation in SDP for describing MELPe An example of the media representation in SDP for describing MELPe
might be: might be:
m=audio 49120 RTP/AVP 97 m=audio 49120 RTP/AVP 97
a=rtpmap:97 MELP/8000 a=rtpmap:97 MELP/8000
skipping to change at page 23, line 32 skipping to change at page 23, line 32
Note that the payload format (encoding) names are commonly shown in Note that the payload format (encoding) names are commonly shown in
upper case. Media subtypes are commonly shown in lower case. These upper case. Media subtypes are commonly shown in lower case. These
names are case-insensitive in both places. Similarly, parameter names are case-insensitive in both places. Similarly, parameter
names are case-insensitive both in media subtype name and in the names are case-insensitive both in media subtype name and in the
default mapping to the SDP a=fmtp attribute default mapping to the SDP a=fmtp attribute
The value for "packet time" and "maximum packet time" parameters of The value for "packet time" and "maximum packet time" parameters of
the "ptime" and "maxptime" SDP attributes respectively, SHALL use the the "ptime" and "maxptime" SDP attributes respectively, SHALL use the
nearest rounded-up ms integer packet duration. For MELPe, this nearest rounded-up ms integer packet duration. For MELPe, this
corresponds to the values: 23, 45, 68, 90, 112, 135, 156, and 180. 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. Larger values can be used as long as they are properly rounded.
4.3 Declaritive SDP Considerations 4.3 Declarative SDP Considerations
For declaritive media, the "bitrate" parameter specifes the possible For declarative media, the "bitrate" parameter specifes the possible
bit rates used by the sender. Multiple MELPe rtpmap values (such as 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 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 at different bit rates. The receiver can then select an appropriate
MELPe codec by using 97, 98, or 99. MELPe codec by using 97, 98, or 99.
m=audio 49120 RTP/AVP 97 98 99 m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 MELP/8000 a=rtpmap:97 MELP/8000
a=fmtp:97 bitrate=2400 a=fmtp:97 bitrate=2400
a=rtpmap:98 MELP/8000 a=rtpmap:98 MELP/8000
a=fmtp:98 bitrate=1200 a=fmtp:98 bitrate=1200
a=rtpmap:99 MELP/8000 a=rtpmap:99 MELP/8000
a=fmtp:99 bitrate=600 a=fmtp:99 bitrate=600
4.4 Offer/Answer SDP Considerations 4.4 Offer/Answer SDP Considerations
In an Offer/Answer mode [RFC3264], "bitrate" is a bi-directional In an Offer/Answer mode [RFC3264], "bitrate" is a bi-directional
parameter. Both sides MUST use a common "bitrate" value or values. parameter. Both sides MUST use a common "bitrate" value or values.
The offer contains the bit rates supported by the offerer listed in The offer contains the bit rates supported by the offerer listed in
its preferred order. The answerer may agree to any bit rate by its preferred order. The answerer MAY agree to any bit rate by
listing the bit rate first in the answerer response. Additionally listing the bit rate first in the answerer response. Additionally
the answerer may indicate any secondary bit rate or bit rates that it 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 supports. The initial bit rate used by both parties SHALL be the
first bit rate specified in the answerer response. first bit rate specified in the answerer response.
For example if offerer bit rates are "2400,600", and answer bit rates 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 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 provided by the answerer, any common bit rate between offer and
answer may be used at any time in the future. Activation of these answer MAY be used at any time in the future. Activation of these
other common bit rates is beyond the scope of this document. other common bit rates is beyond the scope of this document.
The use of a lower bit rate is often important for a case such as The use of a lower bit rate is often important for a case such as
when one end point utilizes a bandwidth constrained link (e.g. 1200 when one end point utilizes a bandwidth constrained link (e.g. 1200
bps radio link or slower), where only the lower coder bit rate will bps radio link or slower), where only the lower coder bit rate will
work. work.
5 Discontinious Transmission 5 Discontinious Transmission
A primary application of MELPe is for radio communications of voice A primary application of MELPe is for radio communications of voice
skipping to change at page 24, line 45 skipping to change at page 24, line 45
If a MELPe coder so desires, it may send a comfort noise frame as per 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 SCIP-210 Appendix B [SCIP210] prior to ceasing transmission. A
receiver may optionally use comfort noise during its silence periods. receiver may optionally use comfort noise during its silence periods.
No SDP negotiations are required. No SDP negotiations are required.
6 Packet Loss Concealment 6 Packet Loss Concealment
MELPe packet loss concealment (PLC) uses the special properties and MELPe packet loss concealment (PLC) uses the special properties and
coding for the pitch/voicing parameter of the MELPe 2400 bps coder. coding for the pitch/voicing parameter of the MELPe 2400 bps coder.
The PLC erasure indication may utilize any of the errored encodings The PLC erasure indication utilizes any of the errored encodings of a
of a non-voiced frame as identified in Table 1 of [MELPE]. For the non-voiced frame as identified in Table 1 of [MELPE]. For the sake
sake of simplicity it is recommended to use a code value of 3 for the 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 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 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and
P6 to zero. P6 to zero.
When using PLC in a 1200 bps or 600 bps mode, the MELPe 2400 bps When using PLC in a 1200 bps or 600 bps mode, the MELPe 2400 bps
decoder is called three or four times respectively to cover the loss decoder is called three or four times respectively to cover the loss
of a MELPe frame. of a MELPe frame.
7 IANA Considerations 7 IANA Considerations
skipping to change at page 27, line 43 skipping to change at page 27, line 43
[RFC5405] Westerlund, M. and Johansson, I., "RTP Payload Format for [RFC5405] Westerlund, M. and Johansson, I., "RTP Payload Format for
G.719", RFC 5405, January 2009. G.719", RFC 5405, January 2009.
[RFC6562] Perkins, C. and Valin, J. M., "Guidelines for the Use of [RFC6562] Perkins, C. and Valin, J. M., "Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012. Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[RFC6838] Freed, N., Klensin, J. and Hansen, T., "Media Type [RFC6838] Freed, N., Klensin, J. and Hansen, T., "Media Type
Specifications and Registration Procedures", BCP 13, RFC 6838, Specifications and Registration Procedures", BCP 13, RFC 6838,
January 2013. January 2013.
10.2 Informative References
[MELP] Department of Defense Telecommunications Standard, "Analog-to- [MELP] Department of Defense Telecommunications Standard, "Analog-to-
Digital Conversion of Voice by 2,400 Bit/Second Mixed Excitation Digital Conversion of Voice by 2,400 Bit/Second Mixed Excitation
Linear Prediction (MELP)", MIL-STD-3005, December 1999. Linear Prediction (MELP)", MIL-STD-3005, December 1999.
[MELPE] North Atlantic Treaty Organization (NATO), "The 600 Bit/S, [MELPE] North Atlantic Treaty Organization (NATO), "The 600 Bit/S,
1200 Bit/S and 2400 Bit/S NATO Interoperable Narrow Band Voice 1200 Bit/S and 2400 Bit/S NATO Interoperable Narrow Band Voice
Coder", STANAG No. 4591, January 2006. Coder", STANAG No. 4591, January 2006.
[SCIP210] National Security Agency, "SCIP Signaling Plan", SCIP-210, [SCIP210] National Security Agency, "SCIP Signaling Plan", SCIP-210,
December 2007. December 2007.
10.2 Informative References
[RFC7201] Westerlund, M. and Perkins, C., "Options for Securing RTP [RFC7201] Westerlund, M. and Perkins, C., "Options for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, April 2014.
[RFC7202] Perkins, C. and Westerlund, M., "Securing the RTP [RFC7202] Perkins, C. and Westerlund, M., "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Security Framework: Why RTP Does Not Mandate a Single Media Security
Solution", RFC 7202, April 2014. Solution", RFC 7202, April 2014.
Authors' Addresses Authors' Addresses
Victor Demjanenko, Ph.D. Victor Demjanenko, Ph.D.
 End of changes. 28 change blocks. 
47 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/