draft-ietf-payload-melpe-01.txt   draft-ietf-payload-melpe-02.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: August 11, 2016 February 8, 2016 Expires: December 24, 2016 June 22, 2016
RTP Payload Format for MELPe Codec RTP Payload Format for MELPe Codec
draft-ietf-payload-melpe-01 draft-ietf-payload-melpe-02
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 3, line 20 skipping to change at page 3, line 20
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,
bandwidth restriction, delay requirements and packet-loss tolerance. bandwidth restriction, delay requirements and packet-loss tolerance.
1.1 Conventions, Definitions and Acronyms 1.1 Conventions, Definitions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Best current practices for writing RTP payload format [RFC2736] were
followed.
2 Background 2 Background
The MELP speech coder was developed by the US military as an upgrade The MELP speech coder was developed by the US military as an upgrade
from LPC-based CELP standard vocoder for low bit-rate communications from LPC-based CELP standard vocoder for low bit-rate communications
[MELP]. MELP was further enhanced and subsequently adopted by NATO [MELP]. MELP was further enhanced and subsequently adopted by NATO
as MELPe for use by its members and Partnership for Peace countries as MELPe for use by its members and Partnership for Peace countries
for military and other governmental communications [MELPE]. The MELP for military and other governmental communications [MELPE]. The MELP
speech coder algorithm developed by Atlanta Signal Processing (ASPI), speech coder algorithm developed by Atlanta Signal Processing (ASPI),
Texas Instruments (TI), SignalCom (now Microsoft) and Thales Texas Instruments (TI), SignalCom (now Microsoft) and Thales
skipping to change at page 20, line 39 skipping to change at page 20, line 43
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 MIME 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)
[RFC2327], 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 MIME type ("audio") goes in SDP "m=" as the media name.
o The MIME subtype (payload format name) goes in SDP "a=rtpmap" as o The MIME subtype (payload format name) goes in SDP "a=rtpmap"
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 MIME media type string as
"bitrate=value" or "bitrate=value1,value2" or "bitrate=value" 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 MIME 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".
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 [RFC4585], RTP/SAVP [RFC3711] or RTP/ RTP/AVP [RFC3551], RTP/AVPF [RFC4855], RTP/SAVP [RFC3711] or RTP/
SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework:
Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]
discusses, it is not an RTP payload format's responsibility to discusses, it is not an RTP payload format's responsibility to
discuss or mandate what solutions are used to meet the basic security discuss or mandate what solutions are used to meet the basic security
goals like confidentiality, integrity and source authenticity for RTP goals like confidentiality, integrity and source authenticity for RTP
in general. This responsibility lays on anyone using RTP in an in general. This responsibility lays on anyone using RTP in an
application. They can find guidance on available security mechanisms application. They can find guidance on available security mechanisms
and important considerations in Options for Securing RTP Sessions and important considerations in Options for Securing RTP Sessions
[RFC7201]. Applications SHOULD use one or more appropriate strong [RFC7201]. Applications SHOULD use one or more appropriate strong
security mechanisms. The rest of this security consideration section security mechanisms. The rest of this security consideration section
skipping to change at page 24, line 48 skipping to change at page 24, line 48
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.
10 References 10 References
10.1 Normative References 10.1 Normative References
[I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh,
"Multimedia Congestion Control: Circuit Breakers for Unicast RTP "Multimedia Congestion Control: Circuit Breakers for Unicast RTP
Sessions", draft-ietf-avtcore-rtp-circuit-breakers-10 (work in Sessions", draft-ietf-avtcore-rtp-circuit-breakers-16 (work in
progress), March 2015. progress), June 2016.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
requirement Levels", BCP 14, RFC 2119, March 1997. requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2327] M. Handley and V. Jacobson, "SDP: Session Description [RFC4566] Handley, M., Jacobson, V. and Perkins, C., "SDP: Session
Protocol", IETF RFC 2327, April 1998 Description Protocol", IETF RFC RFC4566, July 2006.
[RFC2736] M. Handley and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and Perkins, C., "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, December 1999. Payload Format Specifications", BCP 36, RFC 2736, December 1999.
[RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with [RFC3264] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model
the Session Description Protocol (SDP)" IETF RFC 3264, June 2002. with the Session Description Protocol (SDP)" IETF RFC 3264, June
2002.
[RFC3550] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", IETF RFC V., "RTP: A Transport Protocol for Real-Time Applications", IETF RFC
3550, July 2003. 3550, July 2003.
[RFC3551] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video [RFC3551] Schulzrinne, H., and Casner, S., "RTP Profile for Audio and
Conferences with Minimal Control" IETF RFC 3551, July 2003. Video Conferences with Minimal Control" IETF RFC 3551, July 2003.
[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 E. Carrara, "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.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "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.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Security
Solution", RFC 7202, April 2014.
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.
[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.
[RFC7201] Westerlund, M. and Perkins, C., "Options for Securing RTP
Sessions", RFC 7201, April 2014.
[RFC7202] Perkins, C. and Westerlund, M., "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Security
Solution", RFC 7202, April 2014.
Authors' Addresses Authors' Addresses
Victor Demjanenko, Ph.D. Victor Demjanenko, Ph.D.
VOCAL Technologies, Ltd. VOCAL Technologies, Ltd.
520 Lee Entrance, Suite 202 520 Lee Entrance, Suite 202
Buffalo, NY 14228 Buffalo, NY 14228
USA USA
Phone: +1 716 688 4675 Phone: +1 716 688 4675
Email: victor.demjanenko@vocal.com Email: victor.demjanenko@vocal.com
 End of changes. 17 change blocks. 
29 lines changed or deleted 32 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/