summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4040.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4040.txt')
-rw-r--r--doc/rfc/rfc4040.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc4040.txt b/doc/rfc/rfc4040.txt
new file mode 100644
index 0000000..b36815e
--- /dev/null
+++ b/doc/rfc/rfc4040.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group R. Kreuter
+Request for Comments: 4040 Siemens AG
+Category: Standards Track April 2005
+
+
+ RTP Payload Format for a 64 kbit/s Transparent Call
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document describes how to carry 64 kbit/s channel data
+ transparently in RTP packets, using a pseudo-codec called
+ "Clearmode". It also serves as registration for a related MIME type
+ called "audio/clearmode".
+
+ "Clearmode" is a basic feature of VoIP Media Gateways.
+
+Table of Contents
+
+ 1. Introduction.................................................. 2
+ 2. Conventions Used in This Document............................. 2
+ 3. 64 kbit/s Data Stream Handling and RTP Header Parameters...... 3
+ 4. IANA Considerations........................................... 3
+ 5. Mapping to Session Description Protocol (SDP) Parameters...... 5
+ 6. Security Considerations....................................... 5
+ 7. References.................................................... 6
+ 7.1. Normative References..................................... 6
+ 7.2. Informative References................................... 6
+ 8. Acknowledgements.............................................. 7
+
+
+
+
+
+
+
+
+
+
+
+Kreuter Standards Track [Page 1]
+
+RFC 4040 64 kbit/s Voice Band Data Call April 2005
+
+
+1. Introduction
+
+ Voice over IP (VoIP) Media Gateways need to carry all possible data
+ streams generated by analog terminals or integrated services digital
+ network (ISDN) terminals via an IP network. Within this document a
+
+ VoIP Media Gateway is a device that converts a (digital or analog)
+ linear data stream to a digital packetized data stream or vice versa.
+ Refer to RFC 2719 [10] for an introduction into the basic
+ architecture of a Media Gateway based network.
+
+ Usually a VoIP Media Gateway does some processing on the data it
+ converts besides packetization or depacketization; i.e. echo
+ cancellation or dual tone multifrequency (DTMF) detection, and
+ especially a coding/decoding. But there is a class of data streams
+ that does not rely on or allow any data processing within the VoIP
+ Media Gateway except for packetization or depacketization. ISDN data
+ terminals i.e. will produce data streams that are not compatible with
+ a non-linear encoding as used for voice.
+
+ For such applications, there is a necessity for a transparent relay
+ of 64 kbit/s data streams in real-time transport protocol (RTP) [4]
+ packets. This mode is often referred to as "clear-channel data" or
+ "64 kbit/s unrestricted". No encoder/decoder is needed in that case,
+ but a unique RTP payload type is necessary and a related MIME type is
+ to be registered for signaling purposes.
+
+ Clearmode is not restricted to the examples described above. It can
+ be used by any application, that does not need a special
+ encoding/decoding for transfer via a RTP connection.
+
+ This payload format document describes a pseudo-codec called
+ "Clearmode", for sample oriented 64 kbit/s data streams with 8 bits
+ per sample. It is in accordance with RFC 2736 [1], which provides a
+ guideline for the specification of new RTP payload formats.
+
+ Examples for the current use of Clearmode are the transfer of "ISDN 7
+ kHz voice" and "ISDN data" in VoIP Media Gateways.
+
+ This document also serves as the MIME type registration according to
+ RFC 2045 [2] and RFC 2048 [3], which defines procedures for
+ registration of new MIME types within the IETF tree.
+
+2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [8].
+
+
+
+Kreuter Standards Track [Page 2]
+
+RFC 4040 64 kbit/s Voice Band Data Call April 2005
+
+
+3. 64 kbit/s Data Stream Handling and RTP Header Parameters
+
+ Clearmode does not use any encoding or decoding. It just provides
+ packetization.
+
+ Clearmode assumes that the data to be handled is sample oriented with
+ one octet (8bits) per sample. There is no restriction on the number
+ of samples per packet other than the 64 kbyte limit imposed by the IP
+ protocol. The number of samples SHOULD be less than the path maximum
+ transmission unit (MTU) minus combined packet header length. If the
+ environment is expected to have tunnels or security encapsulation as
+ part of operation, the number of samples SHOULD be reduced to allow
+ for the extra header space.
+
+
+ The payload packetization/depacketization for Clearmode is similar to
+ the Pulse Code Modulation (PCMU or PCMA) handling described in RFC
+ 3551 [5]. Each Clearmode octet SHALL be octet-aligned in an RTP
+ packet. The sign bit of each octet SHALL correspond to the most
+ significant bit of the octet in the RTP packet.
+
+ A sample rate of 8000 Hz MUST be used.
+ This calculates to a 64 kbit/s transmission rate per channel.
+
+ The Timestamp SHALL be set as described in RFC 3550 [4].
+
+ The marker bit is always zero. Silence suppression is not applicable
+ for Clearmode data streams.
+
+ The payload type is dynamically assigned and is not presented in this
+ document.
+
+ RTP header fields not mentioned here SHALL be used as specified in
+ RFC 3550 [4] and any applicable profile.
+
+ This document specifies the use of RTP over unicast and multicast UDP
+ as well as TCP. (This does not preclude the use of this definition
+ when RTP is carried by other lower-layer protocols.)
+
+4. IANA Considerations
+
+ This document registers the following MIME subtype: audio/clearmode.
+
+ To: ietf-types@iana.org
+
+ Subject: Registration of MIME media type audio/clearmode
+
+ MIME media type name: audio
+
+
+
+Kreuter Standards Track [Page 3]
+
+RFC 4040 64 kbit/s Voice Band Data Call April 2005
+
+
+ MIME subtype name: clearmode
+
+ Required parameters: none
+
+ Optional parameters: ptime, maxptime
+
+ "ptime" gives the length of time in milliseconds
+ represented by the media in a packet, as described in RFC
+ 2327 [6].
+
+ "maxptime" represents the maximum amount of media, which
+ can be encapsulated in each packet, expressed as time in
+ milliseconds, as described in RFC 3267 [9].
+
+ Encoding considerations:
+
+ This type is only defined for transfer via RTP [4].
+
+ Security considerations:
+
+ See Section 6 of RFC 4040
+
+ Interoperability considerations: none
+
+ Published specification: RFC 4040
+
+ Applications, which use this media type:
+
+ Voice over IP Media Gateways, transferring "ISDN 64 kb/s
+ data", "ISDN 7 kHz voice", or other 64 kbit/s data streams
+ via an RTP connection
+
+ Note: the choice of the "audio" top-level MIME type was
+ made because the dominant uses of this pseudo-codec are
+ expected to telephony and voice-gateway-related. The
+ "audio" type allows the use of sharing of the port in the
+ SDP "m=" line with codecs such as audio/g711 [6], [7], for
+ one example. This sharing is an important application and
+ would not be possible otherwise.
+
+ Additional information: none
+
+ Intended usage: COMMON
+
+ Author/Change controller:
+
+ IETF Audio/Video transport working group
+ delegated from the IESG
+
+
+
+Kreuter Standards Track [Page 4]
+
+RFC 4040 64 kbit/s Voice Band Data Call April 2005
+
+
+5. Mapping to Session Description Protocol (SDP) Parameters
+
+ Parameters are mapped to SDP [6] in a standard way.
+
+ o The MIME type (audio) goes in SDP "m=" as the media name.
+
+ o The MIME subtype (clearmode) goes in SDP "a=rtpmap" as the
+ encoding name.
+
+ o The optional parameters "ptime" and "maxptime" go in the SDP
+ "a=ptime" and "a=maxptime" attributes, respectively.
+
+ An example mapping is as follows:
+
+ audio/clearmode; ptime=10
+
+ m=audio 12345 RTP/AVP 97
+ a=rtpmap:97 CLEARMODE/8000
+ a=ptime:10
+
+ Note that the payload format (encoding) names defined in the RTP
+ Profile are commonly shown in upper case. MIME subtypes are commonly
+ shown in lower case. These names are case-insensitive in both
+ places.
+
+6. Security Considerations
+
+ Implementations using the payload format defined in this
+ specification are subject to the security considerations discussed in
+ the RFC 3550 [4]. The payload format described in this document does
+ not specify any different security services. The primary function of
+ this payload format is to add a transparent transport for a 64 kbit/s
+ data stream.
+
+ Confidentiality of the media streams is achieved by encryption, for
+ example by application of the Secure RTP profile [11].
+
+ As with any IP-based protocol, in some circumstances a receiver may
+ be overloaded simply by the receipt of too many packets, either
+ desired or undesired. Network-layer authentication MAY be used to
+ discard packets from undesired sources, but the processing cost of
+ the authentication itself may be too high. Overload can also occur,
+ if the sender chooses to use a smaller packetization period, than the
+ receiver can process. The ptime parameter can be used to negotiate
+ an appropriate packetization during session setup.
+
+
+
+
+
+
+Kreuter Standards Track [Page 5]
+
+RFC 4040 64 kbit/s Voice Band Data Call April 2005
+
+
+ In general RTP is not an appropriate transfer protocol for reliable
+ octet streams. TCP is better in those cases. Besides that, packet
+ loss due to congestion is as much an issue for clearmode, as for
+ other payload formats. Refer to RFC 3551 [5], section 2, for a
+ discussion of this issue.
+
+7. References
+
+7.1. Normative References
+
+ [1] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
+ Payload Format Specifications", BCP 36, RFC 2736, December 1999.
+
+ [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+ [3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
+ Mail Extensions (MIME) Part Four: Registration Procedures", BCP
+ 13, RFC 2048, November 1996.
+
+ [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+ RFC 3550, July 2003.
+
+ [5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+ Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
+
+ [6] Handley, M. and V. Jacobson, "SDP: Session Description
+ Protocol", RFC 2327, April 1998.
+
+ [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+ [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [9] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
+ Time Transport Protocol (RTP) Payload Format and File Storage
+ Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
+ Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
+
+7.2. Informative References
+
+ [10] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
+ Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework
+ Architecture for Signaling Transport", RFC 2719, October 1999.
+
+
+
+
+Kreuter Standards Track [Page 6]
+
+RFC 4040 64 kbit/s Voice Band Data Call April 2005
+
+
+ [11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
+ 3711, March 2004.
+
+8. Acknowledgements
+
+ The editor would like to acknowledge the help of the IETF AVT Working
+ Group and, in particular the help of Colin Perkins and Magnus
+ Westerlund for their intensive reviews and comments.
+
+Author's Address
+
+ Ruediger Kreuter
+ Siemens AG
+ 81730 Munich, Germany
+
+ EMail: ruediger.kreuter@siemens.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kreuter Standards Track [Page 7]
+
+RFC 4040 64 kbit/s Voice Band Data Call April 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Kreuter Standards Track [Page 8]
+