idnits 2.17.1 draft-ietf-avt-rtp-clearmode-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 342. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 40), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 84 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (April 2004) is 7315 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 270, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 273, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 279, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 294, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. '1') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 2048 (ref. '5') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 3555 (ref. '8') (Obsoleted by RFC 4855, RFC 4856) -- No information found for draft-ietf-mmusic-sdp-new-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 5 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-ietf-avt-rtp-clearmode-05.txt Siemens AG 5 Expires: October 2004 April 2004 7 RTP payload format for a 64 kbit/s transparent call 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware has been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, I accept the provisions of Section 17 3 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/lid-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This document is a submission of the IETF AVT WG. Comments should be 36 directed to the AVT WG mailing list, avt@ietf.org. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document describes how to carry 64 kbit/s channel data 45 transparently in RTP packets, using a pseudo-codec called 46 "Clearmode". It also serves as registration for a related MIME type 47 called "audio/clearmode". 49 "Clearmode" is a basic feature of VoIP media gateways. 51 Table of Contents 53 1. Introduction..................................................1 54 2. Conventions used in this document.............................2 55 3. 64 kbit/s data stream handling and RTP header parameters......2 56 4. IANA Considerations...........................................3 57 5. Mapping to Session Description Protocol (SDP) parameters......3 58 6. Security Considerations.......................................4 59 7. References....................................................4 60 8. Acknowledgements..............................................5 61 9. Author's Address..............................................5 62 10. Full Copyright Statement.....................................5 63 11. Disclaimer...................................................5 65 1. Introduction 67 [Note to the RFC Editor: This paragraph is to be deleted when this 68 draft is published as an RFC. All references to RFC yyyy in section 69 4 should be replaced by the RFC number of this draft, when published. 70 All references to RFC XXXX in sections 4 and 5 should be replaced by 71 the RFC number of the revision of RFC 2327, when published.] 73 Voice over IP (VoIP) media gateways need to carry all possible data 74 streams generated by analog terminals or integrated services digital 75 network (ISDN) terminals via an IP network. Within this document a 76 VoIP media gateway is a device that converts a (digital or analog) 77 linear data stream to a digital packetized data stream or vice versa. 78 Refer to RFC 2719 [12] for an introduction into the basic 79 architecture of a media gateway based network. 81 Usually a VoIP media gateway does some processing on the data it 82 converts besides packetization or depacketization; e.g. echo 83 cancellation or dual tone multifrequency (DTMF) detection, and 84 especially a coding/decoding. But there is a class of data streams 85 that does not rely or even does not allow any data processing within 86 the VoIP media gateway except for packetization or depacketization. 87 ISDN data terminals e.g. will produce data streams that are not 88 compatible with a non-linear encoding as is used for voice. 90 For such applications, there exists a necessity for a transparent 91 relay of 64 kbit/s data streams in real-time transport protocol (RTP) 92 [6] packets. This mode is often referred to as "clear-channel data" 93 or "64 kbit/s unrestricted". No encoder/decoder is needed in that 94 case, but a unique RTP payload type is necessary and a related MIME 95 type is to be registered for signaling purposes. 97 Clearmode is not restricted to the examples described above. It can 98 be used by any application, that does not need a special encoding / 99 decoding for transfer via a RTP connection. 101 This payload format document describes a pseudo-codec called 102 "Clearmode", for sample-oriented 64 kbit/s data streams with 8 bits 103 per sample. It is in accordance with RFC 2736 [3], which provides a 104 guideline for the specification of new RTP payload formats. 106 Examples for the current use of Clearmode are the transfer of "ISDN 7 107 kHz voice" and "ISDN data" in VoIP media gateways. 109 This document also serves as the MIME type registration according to 110 RFC 2048 [5], which defines procedures for registration of new MIME 111 types within the IETF tree. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [11]. 119 3. 64 kbit/s data stream handling and RTP header parameters 121 Clearmode does not use any encoding or decoding. It just provides 122 packetization. 124 Clearmode assumes that the data to be handled is sample oriented with 125 one octet (8bits) per sample. There is no restriction on the number 126 of samples per packet other than the 64 kbyte limit imposed by the IP 127 protocol. The number of samples SHOULD be less than the path maximum 128 transmission unit (MTU) minus combined packet header length. If the 129 environment is expected to have tunnels or security encapsulation as 130 part of operation, the number of samples SHOULD be reduced to allow 131 for the extra header space used for those. 133 The payload packetization/depacketization for Clearmode is similar to 134 the Pulse Code Modulation (PCMU or PCMA) handling described in RFC 135 3551 [7]. Each Clearmode octet SHALL be octet-aligned in a RTP 136 packet. The sign bit of each octet SHALL correspond to the most 137 significant bit of the octet in the RTP packet. 139 A sample rate of 8000 Hz MUST be used. 140 This calculates to a 64 kbit/s transmission rate per channel. 142 The Timestamp SHALL be set as described in RFC 3550 [6]. 144 The marker bit is always zero. Silence suppression is not applicable 145 for Clearmode data streams. 147 The payload type is dynamically assigned by means outside the scope 148 of this document. 150 RTP header fields not mentioned here SHALL be used as specified in 151 RFC 3550 [6] and any applicable profile. 153 This document specifies the use of RTP over unicast and multicast UDP 154 as well as TCP. (This does not preclude the use of this definition 155 when RTP is carried by other lower-layer protocols.) 157 4. IANA Considerations 159 This document registers the following MIME subtype: audio/clearmode. 161 To: ietf-types@iana.org 163 Subject: Registration of MIME media type audio/clearmode 165 MIME media type name: audio 167 MIME subtype name: clearmode 169 Required parameters: none 171 Optional parameters: ptime, maxptime 173 "ptime" gives the length of time in milliseconds represented 174 by the media in a packet, as described in RFC xxxx [9]. 176 "maxptime" represents the maximum amount of media, which can 177 be encapsulated in each packet, expressed as time in 178 milliseconds, as described in RFC xxxx [9]. 180 Encoding considerations: 182 This type is only defined for transfer via RTP [6]. 184 Security considerations: 186 See Section 6 of RFC yyyy 188 Interoperability considerations: none 190 Published specification: RFC yyyy 192 Applications, which use this media type: 194 Voice over IP Media Gateways, transferring "ISDN 64 kb/s 195 data", "ISDN 7 kHz voice", or other 64 kbit/s data streams via 196 an RTP connection 198 Note: the choice of the "audio" top-level MIME type was made 199 because the dominant uses of this pseudo-codec are expected to 200 telephony and voice-gateway-related. The "audio" type allows 201 the use of sharing of the port in the SDP "m=" line with 202 codecs such as audio/g711 [9], [10], for one example. This 203 sharing is an important application and would not be possible 204 otherwise. 206 Additional information: none 208 Intended usage: COMMON 210 Author/Change controller: 212 IETF Audio/Video transport working group 214 5. Mapping to Session Description Protocol (SDP) parameters 216 Parameters are mapped to SDP [9] in a standard way. 218 o The MIME type (audio) goes in SDP "m=" as the media name. 220 o The MIME subtype (clearmode) goes in SDP "a=rtpmap" as the 221 encoding name. 223 o The optional parameters "ptime" and "maxptime" go in the SDP 224 "a=ptime" and "a=maxptime" attributes, respectively. 226 An example mapping is as follows: 228 audio/clearmode; ptime=10 230 m=audio 12345 RTP/AVP 97 231 a=rtpmap:97 CLEARMODE/8000 232 a=ptime:10 234 Note that the payload format (encoding) names defined in the RTP 235 Profile are commonly shown in upper case. MIME subtypes are commonly 236 shown in lower case. These names are case-insensitive in both 237 places. 239 6. Security Considerations 241 Implementations using the payload format defined in this 242 specification are subject to the security considerations discussed in 243 the RFC 3550 [6]. The payload format described in this document does 244 not specify any different security services. The primary function of 245 this payload format is to add a transparent transport for a 64 kbit/s 246 data stream. 248 Confidentiality of the media streams is achieved by encryption, for 249 example by application of the Secure RTP profile [13]. 251 As with any IP-based protocol, in some circumstances a receiver may 252 be overloaded simply by the receipt of too many packets, either 253 desired or undesired. Network-layer authentication MAY be used to 254 discard packets from undesired sources, but the processing cost of 255 the authentication itself may be too high. Overload can also occur, 256 if the sender chooses to use a smaller packetization period, than the 257 receiver can process. The ptime parameter can be used to negotiate 258 an appropriate packetization during session setup. 260 In general RTP is not an appropriate transfer protocol for reliable 261 octet streams. TCP is better in those cases. Besides that, packet 262 loss due to congestion is as much an issue for clearmode, as for 263 other payload formats. Refer to RFC 3551 [7], section 2, for a 264 discussion of this issue. 266 7. References 268 Normative References 270 [1] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, 271 February 2004. 273 [2] Bradner, S., Ed., "Intellectual Property Rights in IETF 274 Technology", BCP 79, RFC 3668, February 2004. 276 [3] M. Handley and C. Perkins, "Guidelines for Writers of RTP 277 Payload Format Specifications", RFC 2736, December 1999 279 [4] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions 280 (MIME) Part One: Format of Internet Message Bodies ", RFC 2045, 281 November 1996. 283 [5] N. Freed, J. Klensin and J. Postel, "Multipurpose Internet Mail 284 Extensions (MIME) Part Four: Registration Procedures", BCP 13, 285 RFC 2048, November 1996. 287 [6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 288 "RTP: A Transport Protocol for Real-Time Applications", RFC 289 3550, July 2003. 291 [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 292 Conferences with Minimal Control", RFC 3551, July 2003. 294 [8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 295 Payload Types", RFC 3555, July 2003. 297 [9] M. Handley, V. Jacobson and C. Perkins, draft-ietf-mmusic-sdp- 298 new-xx.txt "SDP: Session Description Protocol", revision of 299 2327, work in progress. 301 [10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 302 SDP", RFC 3264, June 2002 304 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 305 Levels", BCP 14, RFC 2119, March 1997 307 Informational References 309 [12] L. Ong, et. al., "Framework Architecture for Signaling 310 Transport", RFC 2719, October 1999. 312 [13] Baugher, et al., "The Secure Real-time Transport Protocol 313 (SRTP)", RFC 3711, March 2004 315 8. Acknowledgements 317 The editor would like to acknowledge the help of the IETF AVT Working 318 Group and, in particular the help of Colin Perkins and Magnus 319 Westerlund for their intensive reviews and comments. 321 9. Author's Address 323 Ruediger Kreuter 324 Siemens AG 325 81730 Munich, Germany 326 Email: ruediger.kreuter@siemens.com 328 10. Full Copyright Statement 330 Copyright (C) The Internet Society (year). This document is subject 331 to the rights, licenses and restrictions contained in BCP 78, and 332 except as set forth therein, the authors retain all their rights. 334 11. Disclaimer 336 This document and the information contained herein are provided on an 337 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 338 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 339 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 340 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 341 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 342 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.