idnits 2.17.1 draft-jones-avt-audio-t38-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 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. ** 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. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 (June 2004) is 7217 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3555 (ref. '5') (Obsoleted by RFC 4855, RFC 4856) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft P. Jones 4 Cisco Systems, Inc. 5 Expires: December 2004 H. Tamura 6 Ricoh Company, Ltd. 7 June 2004 9 Real-Time Facsimile (T.38) - audio/t38 10 MIME Sub-type Registration 12 Status of this Memo 14 By submitting this Internet-Draft, we certify that any applicable 15 patent or other IPR claims of which we am aware have been disclosed 16 and any of which we become aware will be disclosed, in accordance 17 with RFC 3668 (BCP 79). 19 By submitting this Internet-Draft, we accept the provisions of 20 Section 3 of RFC 3667 (BCP 78). 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 [Note to RFC Editor: All references to RFC XXXX are to be replaced by 38 references to the RFC number of this memo, when published.] 40 Abstract 42 This document defines the MIME sub-type audio/t38. The usage of this 43 MIME type, which is intended for use within SDP, is specified within 44 ITU-T Recommendation T.38. 46 Table of Contents 48 1. Introduction...................................................2 49 2. Conventions used in this document..............................2 50 3. Mechanisms for Transporting T.38 over an IP Network............2 51 4. IANA Considerations............................................3 52 5. SDP Mapping of MIME Parameters.................................5 53 6. Security Considerations........................................5 54 7. Normative References...........................................6 55 8. Informative References.........................................6 56 9. Author's Address...............................................7 57 10. Full Copyright Statement......................................7 59 1. Introduction 61 ITU-T Recommendation T.38 [1] defines the Internet Facsimile Protocol 62 (IFP) for carriage of facsimile data over IP networks. As one 63 option, IFP packets may be carried within an RTP [3] stream, either 64 as the only content within the media stream or switched with other 65 audio payload types. 67 This memo provides rationale for using RTP as a transport for fax 68 signaling and specifies the MIME type associated with said signaling. 70 2. Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [4]. 76 3. Mechanisms for Transporting T.38 over an IP Network 78 When T.38 was first approved in 1998, it allowed for the transport of 79 T.38 via UDP (using UDPTL, rather than RTP) or TCP. As of the time 80 of this publication, UDPTL is the predominant means for transporting 81 T.38 data over an IP network. In support of that, RFC 3362 [11] was 82 published in order to allow devices to signal their desire to use 83 UDPTL to transport T.38. 85 A number of issues were raised with respect to the usage of UDPTL for 86 the long-term, though. Specifically, there were concerns over the 87 fact that UDPTL does not provide the same kind of statistics 88 reporting as RTCP. Further, there are no procedures in place for 89 encrypting and protecting the integrity of the UDPTL stream. While 90 the latter could be addressed in UDPTL, doing so would require a lot 91 of effort and would largely be a duplication of the security work 92 already completed within the IETF, e.g. Secure RTP (SRTP) [10]. 94 There are clear advantages in using RTP for T.38 today. For example, 95 using RTP allows one to take advantage of the redundancy [12], header 96 compression [13][14], and other RTP-related work within the IETF. 97 Using RTP, as opposed to UDPTL, for transport provides better 98 interoperability with a wider range of devices that know and 99 understand RTP. This includes applications such as firewalls, NAT 100 devices, and gateways that bridge two IP networks, which are 101 generally support RTP before most other real-time media. 103 Lastly, since most T.38 data today is generated by gateways that 104 bridge two PSTN networks, it is quite natural to expect the 105 transition from audio to fax should happen within the same media 106 stream. The reason is that the T.38 data is simply an alternative 107 representation of information received on the PSTN circuit. If the 108 T.38 data is encapsulated in RTP, the gateways can easily transition 109 from audio to fax and back again and can simply use the payload type 110 to indicate the type of media that it is currently transmitting. 112 With these considerations in mind, the ITU-T amended T.38 [1] to 113 allow RTP to be used to transport T.38. With that, a new MIME 114 registration (audio/t38) is needed to allow for T.38 to be switched 115 along with audio within the same RTP session. 117 4. IANA Considerations 119 One new MIME type and associated RTP payload format is to be 120 registered, as described below. 122 To: ietf-types@iana.org 123 Subject: Registration of Standard MIME media type audio/t38 125 MIME media type name: audio 127 MIME subtype name: t38 129 Require parameters: 130 rate: The RTP timestamp clock rate, which SHOULD be 8000Hz. The 131 clock frequency MAY be set to any value, but SHOULD be set to the 132 same value as for any audio packets in the same RTP stream in 133 order to avoid RTP timestamp rate switching. 135 T38FaxRateManagement: Indicates the fax rate management model 136 as defined in T.38. Values may be "localTCF" or "transferredTCF". 137 This parameter is defined in ITU-T Recommendation T.38. 139 Optional parameters: 140 T38FaxFillBitRemoval: Indicates the capability to remove and 141 insert fill bits in Phase C (refer to [6]), non-ECM data to 142 reduce bandwidth. This is a boolean parameter (inclusion = true, 143 exclusion = false). This parameter is defined in ITU-T 144 Recommendation T.38. 146 T38FaxTranscodingMMR: Indicates the ability to convert to/from MMR 147 from/to the line format for increasing the compression of the data 148 and reducing the bandwidth in the packet network. This is a 149 boolean parameter (inclusion = true, exclusion = false). 150 This parameter is defined in ITU-T Recommendation T.38. 152 T38FaxTranscodingJBIG: Indicates the ability to convert to/from 153 JBIG to reduce bandwidth. This is a boolean parameter 154 (inclusion = true, exclusion = false). This parameter is 155 defined 156 in ITU-T Recommendation T.38. 158 T38FaxVersion: This is the version number of ITU-T Rec. T.38. 159 New versions shall be compatible with previous versions. Absence 160 of this parameter indicates version 0. The version is expressed 161 as an integer value. This parameter is defined in ITU-T 162 Recommendation T.38. 164 T38FaxMaxBuffer: Indicates the maximum number of octets that can 165 be stored on the remote device before an overflow condition 166 occurs. It is the responsibility of the transmitting application 167 to limit the transfer rate to prevent an overflow. The negotiated 168 data rate should be used to determine the rate at which data is 169 being removed from the buffer. Value is an integer. This 170 parameter is defined in ITU-T Recommendation T.38. 172 T38FaxMaxDatagram: The maximum size of the payload within an RTP 173 packet that can be accepted by the remote device. This is an 174 integer value. This parameter is defined in ITU-T Recommendation 175 T.38. 177 Encoding considerations: 178 The encoding of the IFP RTP packets is defined in ITU-T 179 Recommendation T.38. This sub-type is not intended for 180 use with e-mail. 182 Security considerations: 184 See Section 6 of RFC XXXX. 186 Interoperability considerations: 188 ITU-T Recommendation T.38 defines the procedures, syntax, and 189 parameters for the carriage of T.38 over RTP within the context 190 of H.323 [8], SIP [9], and H.248 [7] systems. 192 Published specification: 194 ITU-T Recommendation T.38, "Procedures for real-time Group 3 195 facsimile communication over IP networks", (2002) with Amendment 196 2, January 2004. 198 Applications which use this media type: 200 Real-time facsimile (fax) 202 Additional information: 204 Magic number(s): 205 File extension(s): 206 Macintosh File Type Code(s): 208 Person & email address to contact for further information: 210 Paul E. Jones 211 paulej@packetizer.com 213 Intended usage: COMMON 215 Author/Change controller: Paul E. Jones 217 5. SDP Mapping of MIME Parameters 219 The MIME information described in section 4 is utilized in SDP in 220 order to establish T.38 media streams. Specifically: 222 o The MIME type ("audio") goes in SDP "m=" as the media name. 224 o The MIME subtype ("t38") goes in SDP "a=rtpmap" as the 225 encoding name. 227 o The parameter "rate" also goes in "a=rtpmap" as clock 228 rate. 230 The MIME type defines several required and optional parameters to 231 qualify the operation of T.38; these are to be used as defined in RFC 232 3555 [5], Section 2. The parameters are provided as a semi-colon 233 separated list of "parameter" or "parameter=value" pairs using the 234 "a=fmtp" parameter defined in SDP [2]; the "parameter" form is used 235 for boolean values, where presence equals "true" and absence "false". 237 Consider the following example, which describes a media stream that 238 allows the transport of G.711 audio and T.38 fax information: 240 m=audio 6800 RTP/AVP 0 98 241 a=rtpmap:98 t38/8000 242 a=fmtp:98 T38FaxVersion=2;T38FaxRateManagement=transferredTCF 244 6. Security Considerations 245 T.38 is vulnerable to attacks that are common to other types of RTP 246 and SRTP payloads. However, unlike audio, T.38 data may be 247 manipulated in ways that are more obtrusive than audio. As examples, 248 rogue packets may cause transmission failure and manipulated packets 249 may alter terminal identity. 251 The security considerations discussed in the RTP specification and 252 any applicable RTP profile (for example, [10]) are applicable to 253 T.38. Regarding SRTP configuration, fax payloads SHOULD NOT use an 254 HMAC-SHA1 authentication tag that is shorter than 80 bits. 256 7. Normative References 258 [1] ITU-T Recommendation T.38, "Procedures for real-time Group 3 259 facsimile communication over IP networks", 2002 with Amendment 260 2, January 2004. 262 [2] Handley, M. and V. Jacobson, "SDP: Session Description 263 Protocol", RFC 2327, April 1998. 265 [3] Schulzrinne, et al., "RTP: A Transport Protocol for Real-Time 266 Applications", RFC 3550, July 2003. 268 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 269 Levels", RFC 2119, March 1997. 271 [5] Casner, S., Hoschka, P., "MIME Type Registration of RTP Payload 272 Formats", RFC 3555, July 2003. 274 [6] ITU-T Recommendation T.30, "Procedures for document facsimile 275 transmission in the general switched telephone network", July 276 2003. 278 8. Informative References 280 [7] ITU-T Recommendation H.248, "Gateway Control Protocol", May 281 2002. 283 [8] ITU-T Recommendation H.323, "Packet-based multimedia 284 communications systems", May 2003. 286 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 287 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 288 Session Initiation Protocol", RFC 3261, June 2002. 290 [10] Baugher, et al., "The Secure Real-time Transport Protocol 291 (SRTP)", RFC 3711, March 2004. 293 [11] Parsons, G., "Real-time Facsimile (T.38) - image/t38 MIME Sub- 294 type Registration", RFC 3362, August 2002. 296 [12] Perkins, C., et al., "RTP Payload for Redundant Audio Data", RFC 297 2198, September 1997. 299 [13] Casner, S., Jacobson, V., "Compressing IP/UDP/RTP Headers for 300 Low-Speed Serial Links", RFC 2508, February 1999. 302 [14] Koren, T., et al, "Enhanced Compressed RTP (CRTP) for Links with 303 High Delay, Packet Loss and Reordering", RFC 3545, July 2003. 305 9. Author's Address 307 Paul E. Jones 308 Cisco Systems, Inc. 309 7025 Kit Creek Rd. 310 Research Triangle Park, NC 27709, USA 311 Phone: +1 919 392 6948 312 Email: paulej@packetizer.com 314 Hiroshi Tamura 315 Ricoh Company, Ltd. 316 1-3-6 Nakamagome, Ohta-ku, 317 Tokyo 143-8555 Japan 318 Phone: +81-3-3777-8124 319 Fax: +81-3-5742-8859 320 Email: tamura@toda.ricoh.co.jp 322 10. Full Copyright Statement 324 Copyright (C) The Internet Society (2004). 326 This document is subject to the rights, licenses and restrictions 327 contained in BCP 78, and except as set forth therein, the authors 328 retain all their rights. 330 Disclaimer 332 This document and the information contained herein are provided on an 333 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 334 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 335 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 336 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 337 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 338 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 340 Intellectual Property 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at ietf- 361 ipr@ietf.org. 363 Acknowledgement 365 Funding for the RFC Editor function is currently provided by the 366 Internet Society.