idnits 2.17.1 draft-kreuter-avt-rtp-clearmode-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 43 looks like a reference -- Missing reference section? '5' on line 161 looks like a reference -- Missing reference section? '8' on line 73 looks like a reference -- Missing reference section? '4' on line 80 looks like a reference -- Missing reference section? '9' on line 96 looks like a reference -- Missing reference section? '7' on line 131 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport 3 Internet Draft R. Kreuter 4 Document: draft-kreuter-avt-rtp-clearmode-02.txt Siemens AG 5 Expires: August 2003 February 6 2003 8 RTP payload format for a 64 kbit/s transparent call 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes how to carry 64 kbit/s data streams 33 transparently in RTP packets, using a pseudo-codec called 34 "CLEARMODE". 35 It also serves as registration for a related MIME type called 36 "audio/CLEARMODE". 38 Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC-2119 [2]. 44 64kbit/s voice band data call February 2003 46 Table of Contents 48 1. Introduction..................................................2 49 2. 64 kbit/s data stream handling and RTP header parameters......2 50 3. Registration of audio/CLEARMODE...............................3 51 4. Security Considerations.......................................4 52 5. References....................................................4 53 6. Author's Address..............................................5 55 1. Introduction 57 Voice over IP media gateways need to carry all data streams generated 58 by analog TDM or ISDN terminals via an IP network. 59 ISDN wideband speech terminals do not rely on a voice data processing 60 (e.g. echo cancellation or DTMF detection) within a Voice over IP 61 media gateway. And ISDN data terminals e.g. will produce data streams 62 that are not compatible with a non-linear encoding as is used for 63 voice. 64 For such applications, there exists a necessity for a transparent 65 relay of 64 kbit/s data streams in RTP packets. This mode is often 66 referred to as "clear-channel data" or "64 kbit/s unrestricted". No 67 encoder/decoder is needed in that case, but a unique RTP [5] payload 68 type is necessary and a related MIME type is to be registered for 69 signaling purposes. 71 This payload format document describes a pseudo-codec called 72 "CLEARMODE", for sample-oriented 64 kbit/s data streams with 8 bits 73 per sample. It is in accordance with RFC 2736 [8], which provides a 74 guideline for the specification of new RTP payload formats. 76 Examples for the use of CLEARMODE in current VoIP media gateways are 77 the transfer of "ISDN 7 kHz voice" and "ISDN data". 79 This document also serves as the MIME type registration according RFC 80 2048 [4], which defines procedures for registration of new MIME types 81 within the IETF tree. 83 2. 64 kbit/s data stream handling and RTP header parameters 85 The profile specifies the use of RTP over unicast and multicast UDP 86 as well as TCP. 87 (This does not preclude the use of this definition when RTP is 88 carried by other lower-layer protocols.) 90 CLEARMODE does not use any encoding or decoding. It just provides 91 packetization. 93 64kbit/s voice band data call February 2003 95 The payload handling for CLEARMODE is similar to the PCMU or PCMA 96 handling described in [9]. Each CLEARMODE octet is octet-aligned in a 97 RTP packet. The sign bit of each CLEARMODE octet corresponds to the 98 most significant bit of the octet in the RTP packet (i.e., assuming 99 the CLEARMODE samples are handled as octets on the host machine, the 100 sign bit is the most significant bit of the octet as defined by the 101 host machine format). 103 A sample rate of 8000 Hz is used. 105 Note, that the payload format described here assumes that the data to 106 be handled is sample oriented with one octet (8bits) per sample. 107 Together with the 8000 Hz sample rate this calculates to a 64 kbit/s 108 transmission rate per channel. 110 The Timestamp SHALL be set according [5] 112 The marker bit is always zero. Silence suppression is not applicable 113 for CLEARMODE data streams. 115 The payload type is dynamically assigned by means outside the scope 116 of this document. 118 3. Registration of audio/CLEARMODE 120 To: ietf-types@iana.org 122 Subject: Registration of MIME media type audio/CLEARMODE 124 MIME media type name: audio 126 MIME subtype name: CLEARMODE 128 Required parameters: none 130 Optional parameters: ptime 131 This represents the packet length in milliseconds [7]. 133 Encoding considerations: This type is only defined for transfer via 134 RTP [5]. 136 Security considerations: Implementations using the profile defined in 137 this specification are subject to the security considerations 138 discussed in the RTP specification [5]. 140 Interoperability considerations: none 142 Published specification: This document 143 64kbit/s voice band data call February 2003 145 Applications which use this media type: Voice over IP Media Gateways, 146 transferring "ISDN 64 kb/s data" or "ISDN 7 kHz voice" or 147 other VoIP-related 64 kbit/s data streams via a RTP 148 connection. 150 Additional information: none 152 Intended usage: COMMON 154 Author/Change controller: This registration is part of the IETF 155 registration tree. 157 4. Security Considerations 159 Implementations using the profile defined in this specification are 160 subject to the security considerations discussed in the RTP 161 specification [5]. This profile does not specify any different 162 security services. The primary function of this profile is to add a 163 transparent transport for a 64 kbit/s data stream. 164 Confidentiality of the media streams is achieved by encryption. Since 165 there is no processing of the data stream other than packetization 166 and depacketization, there is no interference to an end-to-end 167 encryption mechanism. 169 5. References 171 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 172 9, RFC 2026, October 1996. 174 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 175 Levels", BCP 14, RFC 2119, March 1997 177 3 Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail 178 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 179 November 1996. 181 4 Casner, S. and P. Hoschka, "MIME type registration of RTP payload 182 formats", Work in Progress. 184 5 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 185 a transport protocol for real-time applications", RFC 1889, 186 January 1996. 188 64kbit/s voice band data call February 2003 190 6 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: 191 transport protocol for real-time applications", Work in Progress. 193 7 Handley, M. and V. Jacobson, "SDP: Session Description Protocol", 194 RFC 2327, April 1998. 196 8 Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload 197 Format Specifications", RFC 2736, December 1999 199 9 Schulzrinne, H., Casner, S., "RTP Profile for Audio and Video 200 Conferences with Minimal Control", Work in Progress 202 6. Author's Address 204 Ruediger Kreuter 205 Siemens AG 206 81359 Munich, Germany 207 Phone: +49 89 722 62553 208 Email: ruediger.kreuter@siemens.com