draft-ietf-payload-melpe-02.txt   draft-ietf-payload-melpe-03.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: December 24, 2016 June 22, 2016 Expires: Februrary 20, 2017 August 19, 2016
RTP Payload Format for MELPe Codec RTP Payload Format for MELPe Codec
draft-ietf-payload-melpe-02 draft-ietf-payload-melpe-03
Status of this Memo Status of this Memo
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
Abstract Abstract
This document describes the RTP payload format for the Mixed This document describes the RTP payload format for the Mixed
Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's
three different speech encoding rates and sample frames sizes are three different speech encoding rates and sample frames sizes are
supported. Comfort noise procedures and packet loss concealment are supported. Comfort noise procedures and packet loss concealment are
detailed. Also, within the document there are included necessary detailed.
details for the use of MELP with SDP.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions, Definitions and Acronyms . . . . . . . . . . . 3 1.1 Conventions, Definitions and Acronyms . . . . . . . . . . . 3
2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 MELPe Bitstream Definition . . . . . . . . . . . . . . . . 5 3.1 MELPe Bitstream Definition . . . . . . . . . . . . . . . . 5
3.1.1 2400 bps Bitstream Structure . . . . . . . . . . . . . . 5 3.1.1 2400 bps Bitstream Structure . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . 16 3.3 Multiple MELPe frames in a RTP packet . . . . . . . . . . . 16
3.4 Congestion Control Considerations . . . . . . . . . . . . . 18 3.4 Congestion Control Considerations . . . . . . . . . . . . . 18
4 Payload Format Parameters . . . . . . . . . . . . . . . . . . . 18 4 Payload Format Parameters . . . . . . . . . . . . . . . . . . . 18
4.1 Media Type Definition . . . . . . . . . . . . . . . . . . . 18 4.1 Media Type Definition . . . . . . . . . . . . . . . . . . . 18
4.2 Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 20 4.2 Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Declaritive SDP Considerations . . . . . . . . . . . . . . 22
4.4 Offer/Answer SDP Considerations . . . . . . . . . . . . . . 22
5 Discontinious Transmission . . . . . . . . . . . . . . . . . . 23 5 Discontinious Transmission . . . . . . . . . . . . . . . . . . 23
6 Packet Loss Concealment . . . . . . . . . . . . . . . . . . . . 23 6 Packet Loss Concealment . . . . . . . . . . . . . . . . . . . . 23
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 24 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 24
9 RFC Editor Considerations . . . . . . . . . . . . . . . . . . . 24 9 RFC Editor Considerations . . . . . . . . . . . . . . . . . . . 24
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1 Normative References . . . . . . . . . . . . . . . . . . . 24 10.1 Normative References . . . . . . . . . . . . . . . . . . . 24
10.2 Informative References . . . . . . . . . . . . . . . . . . 25 10.2 Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
skipping to change at page 17, line 11 skipping to change at page 17, line 11
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 may
be required to reduce the packet rate. be required to reduce the packet rate.
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.
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).
+-------------------+------+------+------+ +-------------------+------+------+------+
| Coder Bit Rate | RSVA | RSVB | RSVC | | Coder Bit Rate | RSVA | RSVB | RSVC |
+-------------------+------+------+------+ +-------------------+------+------+------+
skipping to change at page 18, line 19 skipping to change at page 18, line 23
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
Congestion control for RTP SHALL be used in accordance with RFC 3550 The target bitrate of MELPe can be adjusted at any point in time,
[RFC3550], and with any applicable RTP profile; e.g., RFC 3551 thus allowing efficient congestion control. Furthermore, the amount
[RFC3551]. An additional requirement if best-effort service is being of encoded speech or audio data encoded in a single packet can be
used is: users of this payload format MUST monitor packet loss to used for congestion control, since the transmission rate is inversely
ensure that the packet loss rate is within acceptable parameters. proportional to the packet duration. A lower packet transmission
Circuit Breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is an update rate reduces the amount of header overhead, but at the same time
to RTP [RFC3550] that defines criteria for when one is required to increases latency and loss sensitivity, so it ought to be used with
stop sending RTP Packet Streams. The circuit breakers is to be care.
implemented and followed.
Since UDP does not provide congestion control, applications that use
RTP over UDP SHOULD implement their own congestion control above the
UDP layer [RFC5405]. Work in the RMCAT working group [rmcat]
describes the interactions and conceptual interfaces necessary
between the application components that relate to congestion control,
including the RTP layer, the higher-level media codec control layer,
and the lower-level transport interface, as well as components
dedicated to congestion control functions.
4 Payload Format Parameters 4 Payload Format Parameters
This RTP payload format is identified using the MELP, MELP2400, This RTP payload format is identified using the MELP, MELP2400,
MELP1200, and MELP600 media types which is registered in accordance MELP1200, and MELP600 media types which is registered in accordance
with RFC 4855 [RFC4855] and using the template of RFC 6838 [RFC6838]. with RFC 4855 [RFC4855] and using the template of RFC 6838 [RFC6838].
4.1 Media Type Definition 4.1 Media Type Definition
Type names: Type names:
MELP, MELP2400, MELP1200, and MELP600 audio
Subtype name: Subtype name:
N/A MELP, MELP2400, MELP1200, and MELP600
Required parameters: Required parameters:
N/A N/A
Optional parameters: Optional parameters:
ptime, maxptime, bitrate ptime, maxptime, bitrate
Encoding considerations: Encoding considerations:
This media type is framed and binary, see section 4.8 in RFC6838 This media type is framed and binary, see section 4.8 in RFC6838
[RFC6838]. [RFC6838].
Security considerations: Security considerations:
Please see security consideration in RFCXXXX Please see security consideration in RFC6562 [RFC6562].
Interoperability considerations: Interoperability considerations:
Early implementations used MELP2400, MELP1200, and MELP600 to Early implementations used MELP2400, MELP1200, and MELP600 to
indicate both coder type and bit rate. These media type names indicate both coder type and bit rate. These media type names
should be preserved with this registration. should be preserved with this registration.
Published specification: Published specification:
N/A N/A
skipping to change at page 20, line 41 skipping to change at page 21, line 5
Provisional registration? (standards tree only): Provisional registration? (standards tree only):
No No
4.2 Mapping to SDP 4.2 Mapping to SDP
The mapping of the above defined payload format media type and its The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of RFC 4855 parameters SHALL be done according to Section 3 of RFC 4855
[RFC4855]. [RFC4855].
The information carried in the MIME media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[RFC4566], which is commonly used to describe RTP sessions. When SDP [RFC4566], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing the MELPe codec, the mapping is is used to specify sessions employing the MELPe codec, the mapping is
as follows: as follows:
o The MIME 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 MIME 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 MIME media type string as copying it directly from the media type string as "bitrate=value" or
"bitrate=value" or "bitrate=value1,value2" or "bitrate=value1,value2" or "bitrate=value1,value2,value3".
"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 MIME 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 21, line 35 skipping to change at page 21, line 46
a=rtpmap:100 MELP2400/8000 a=rtpmap:100 MELP2400/8000
a=rtpmap:101 MELP1200/8000 a=rtpmap:101 MELP1200/8000
a=rtpmap:102 MELP600/8000 a=rtpmap:102 MELP600/8000
If the encoding name "MELP" is received without a "bitrate" If the encoding name "MELP" is received without a "bitrate"
parameter, the fixed coder bit rate of 2400 MUST be used. The parameter, the fixed coder bit rate of 2400 MUST be used. The
alternate encoding names, "MELP2400", "MELP1200", and "MELP600" alternate encoding names, "MELP2400", "MELP1200", and "MELP600"
directly specify the MELPe coder bit rate of 2400, 1200, and 600 directly specify the MELPe coder bit rate of 2400, 1200, and 600
respectively and MUST NOT specify a "bitrate" parameter. respectively and MUST NOT specify a "bitrate" parameter.
A remote MELPe encoder SHALL receive "bitrate" parameter in the SDP The optional media type parameter, "bitrate", when present, MUST be
"a=fmtp" attribute by copying them directly from the MIME media type included in the "a=fmtp" attribute in the SDP, expressed as a media
string as a semicolon separated with parameter=value, where parameter type string in the form of a semicolon-separated list of
is "bitrate", and value can be one or more of 2400, 1200, and 600 parameter=value pairs. The string, "value", can be one or more of
separated by commas (where each bit-rate value indicates the 2400, 1200, and 600 separated by commas (where each bit-rate value
corresponding MELPe coder). An example of the media representation in indicates the corresponding MELPe coder). An example of the media
SDP for describing MELPe when all three coder bit rates are supported representation in SDP for describing MELPe when all three coder bit
might be: rates are supported might be:
m=audio 49120 RTP/AVP 97 m=audio 49120 RTP/AVP 97
a=rtpmap:97 MELP/8000 a=rtpmap:97 MELP/8000
a=fmtp:97 bitrate=2400,600,1200 a=fmtp:97 bitrate=2400,600,1200
For streaming media, the "bitrate" parameter specifes the possible Parameter ptime can not be used for the purpose of specifying MELPe
bit rates used by the sender. In an Offer/Answer mode [RFC3264], operating mode, due to fact that for the certain values it will be
"bitrate" is a bi-directional parameter. Both sides MUST use a impossible to distinguish which mode is about to be used (e.g. when
common "bitrate" value or values. ptime=68, it would be impossible to distinguish if packet is carrying
1 frames of 67.5 ms or 3 frames of 22.5 ms etc.).
Note that the payload format (encoding) names are commonly shown in
upper case. Media subtypes are commonly shown in lower case. These
names are case-insensitive in both places. Similarly, parameter
names are case-insensitive both in media subtype name and in the
default mapping to the SDP a=fmtp attribute
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.
4.3 Declaritive SDP Considerations
For declaritive 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.
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 MELP/8000
a=fmtp:97 bitrate=2400
a=rtpmap:98 MELP/8000
a=fmtp:98 bitrate=1200
a=rtpmap:99 MELP/8000
a=fmtp:99 bitrate=600
4.4 Offer/Answer SDP Considerations
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 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.
Parameter ptime can not be used for the purpose of specifying MELPe
operating mode, due to fact that for the certain values it will be
impossible to distinguish which mode is about to be used (e.g. when
ptime=68, it would be impossible to distinguish if packet is carrying
1 frames of 67.5 ms or 3 frames of 22.5 ms etc.).
When SDP is used for broadcast MELPe audio, 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.
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 MELP/8000
a=fmtp:97 bitrate=2400
a=rtpmap:98 MELP/8000
a=fmtp:98 bitrate=1200
a=rtpmap:99 MELP/8000
a=fmtp:99 bitrate=600
Note that the payload format (encoding) names are commonly shown in
upper case. MIME subtypes are commonly shown in lower case. These
names are case-insensitive in both places. Similarly, parameter
names are case-insensitive both in media subtype name and in the
default mapping to the SDP a=fmtp attribute
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.
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
conversations and discontinuous transmissions are normal. When MELPe conversations and discontinuous transmissions are normal. When MELPe
is used in an IP network, MELPe RTP packet transmissions may cease is used in an IP network, MELPe RTP packet transmissions may cease
and resume frequently. RTP SSRC sequence number gaps indicate lost and resume frequently. RTP SSRC sequence number gaps indicate lost
packets to be filled by PLC while abrupt loss of RTP packets indicate packets to be filled by PLC while abrupt loss of RTP packets indicate
intended discontinuous transmission. intended discontinuous transmission.
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
skipping to change at page 24, line 17 skipping to change at page 24, line 17
This memo requests that IANA registers MELP, MELP2400, MELP1200, and This memo requests that IANA registers MELP, MELP2400, MELP1200, and
MELP600 as specified in Section 4.1. The media type is also MELP600 as specified in Section 4.1. The media type is also
requested to be added to the IANA registry for "RTP Payload Format requested to be added to the IANA registry for "RTP Payload Format
MIME types" (http://www.iana.org/assignments/rtp-parameters). MIME types" (http://www.iana.org/assignments/rtp-parameters).
8 Security Considerations 8 Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550] , and in any applicable RTP profile such as specification [RFC3550] , and in any applicable RTP profile such as
RTP/AVP [RFC3551], RTP/AVPF [RFC4855], RTP/SAVP [RFC3711] or RTP/ RTP/AVP [RFC3551], RTP/AVPF [RFC4855], RTP/SAVP [RFC3711] or
SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: RTP/SAVPF [RFC5124]. However, as "Securing the RTP Protocol
Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] Framework: Why RTP Does Not Mandate a Single Media Security Solution"
discusses, it is not an RTP payload format's responsibility to [RFC7202] discusses, it is not an RTP payload format's responsibility
discuss or mandate what solutions are used to meet the basic security to discuss or mandate what solutions are used to meet the basic
goals like confidentiality, integrity and source authenticity for RTP security goals like confidentiality, integrity and source
in general. This responsibility lays on anyone using RTP in an authenticity for RTP in general. This responsibility lays on anyone
application. They can find guidance on available security mechanisms using RTP in an application. They can find guidance on available
and important considerations in Options for Securing RTP Sessions security mechanisms and important considerations in Options for
[RFC7201]. Applications SHOULD use one or more appropriate strong Securing RTP Sessions [RFC7201]. Applications SHOULD use one or more
security mechanisms. The rest of this security consideration section appropriate strong security mechanisms. The rest of this security
discusses the security impacting properties of the payload format consideration section discusses the security impacting properties of
itself. the payload format itself.
This RTP payload format and its media decoder do not exhibit any This RTP payload format and the MELPe decoder do not exhibit any
significant non-uniformity in the receiver-side computational significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus are unlikely to pose a complexity for packet processing, and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data. denial-of-service threat due to the receipt of pathological data.
Nor does the RTP payload format contain any active content. Nor does the RTP payload format contain any active content.
9 RFC Editor Considerations 9 RFC Editor Considerations
Note to RFC Editor: This section may be removed after carrying out Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section. all the instructions of this section.
skipping to change at page 25, line 35 skipping to change at page 25, line 35
[RFC3711] Baugher, et al., "The Secure Real Time Transport Protocol", [RFC3711] Baugher, et al., "The Secure Real Time Transport Protocol",
IETF RFC 3711, March 2004. IETF RFC 3711, March 2004.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC5124] Ott, J. and Carrara, E., "Extended Secure RTP Profile for [RFC5124] Ott, J. and Carrara, E., "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Real-time Transport Control Protocol (RTCP)-Based
Feedback(RTP/SAVPF)", RFC 5124, February 2008. Feedback(RTP/SAVPF)", RFC 5124, February 2008.
[RFC6562] Perkins, C. and Valin, J. M., "Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP", RFC 6563, 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 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.
 End of changes. 21 change blocks. 
81 lines changed or deleted 97 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/