From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4612.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc4612.txt (limited to 'doc/rfc/rfc4612.txt') diff --git a/doc/rfc/rfc4612.txt b/doc/rfc/rfc4612.txt new file mode 100644 index 0000000..b842c78 --- /dev/null +++ b/doc/rfc/rfc4612.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group P. Jones +Request for Comments: 4612 Cisco Systems, Inc. +Category: Historic H. Tamura + Ricoh Company, LTD. + August 2006 + + Real-Time Facsimile (T.38) - audio/t38 + MIME Sub-type Registration + +Status of This Memo + + This memo defines a Historic Document for the Internet community. It + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines the MIME sub-type audio/t38. The usage of this + MIME type, which is intended for use within Session Description + Protocol (SDP), is specified within ITU-T Recommendation T.38. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions Used in This Document ...............................2 + 3. Mechanisms for Transporting T.38 over an IP Network .............2 + 4. IANA Considerations .............................................3 + 5. SDP Mapping of MIME Parameters ..................................5 + 6. Security Considerations .........................................6 + 7. Normative References ............................................6 + 8. Informative References ..........................................6 + + + + + + + + + + + + + + + + +Jones & Tamura Historic [Page 1] + +RFC 4612 Real-time Facsimile (T.38) - audio /t38 August 2006 + + +1. Introduction + + ITU-T Recommendation T.38 [1] defines the Internet Facsimile Protocol + (IFP) for carriage of facsimile data over IP networks. As one + option, IFP packets may be carried within an RTP [3] stream, either + as the only content within the media stream or switched with other + audio payload types. + + This memo provides rationale for using RTP as a transport for fax + signaling and specifies the MIME type associated with said signaling. + +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 [4]. + +3. Mechanisms for Transporting T.38 over an IP Network + + When T.38 was first approved in 1998, it allowed for the transport of + T.38 via UDP (using UDP Transport Layer (UDPTL), rather than RTP) or + TCP. As of the time of this publication, UDPTL is the predominant + means for transporting T.38 data over an IP network. In support of + that, RFC 3362 [11] was published in order to allow devices to signal + their desire to use UDPTL to transport T.38. + + A number of issues were raised with respect to the usage of UDPTL for + the long-term, though. Specifically, there were concerns over the + fact that UDPTL does not provide the same kind of statistics + reporting as RTP Control Protocol (RTCP). Further, there are no + procedures in place for encrypting and protecting the integrity of + the UDPTL stream. While the latter could be addressed in UDPTL, + doing so would require a lot of effort and would largely be a + duplication of the security work already completed within the IETF; + e.g., Secure RTP (SRTP) [10]. + + There are clear advantages in using RTP for T.38 today. For example, + using RTP allows one to take advantage of the redundancy [12], header + compression [13][14], and other RTP-related work within the IETF. + Using RTP, as opposed to UDPTL, for transport provides better + interoperability with a wider range of devices that know and + understand RTP. This includes applications such as firewalls, + Network Address Translation (NAT) devices, and gateways that bridge + two IP networks, which generally support RTP before most other real- + time media. + + + + + + +Jones & Tamura Historic [Page 2] + +RFC 4612 Real-time Facsimile (T.38) - audio /t38 August 2006 + + + Lastly, since today most T.38 data is generated by gateways that + bridge two Public Switched Telephone Network (PSTN) networks, it is + quite natural to expect that the transition from audio to fax should + happen within the same media stream. The reason is that the T.38 + data is simply an alternative representation of information received + on the PSTN circuit. If the T.38 data is encapsulated in RTP, the + gateways can easily transition from audio to fax and back again and + can simply use the payload type to indicate the type of media that it + is currently transmitting. + + With these considerations in mind, the ITU-T amended T.38 [1] to + allow RTP to be used to transport T.38. With that, a new MIME + registration (audio/t38) is needed to allow for T.38 to be switched + along with audio within the same RTP session. + +4. IANA Considerations + + One new MIME type and associated RTP payload format has been + registered, by the IANA as described below. + + To: ietf-types@iana.org Subject: Registration of Standard MIME media + type audio/t38 + + MIME media type name: audio + + MIME subtype name: t38 + + Required parameters: + + rate: The RTP timestamp clock rate, which SHOULD be 8000Hz. The + clock frequency MAY be set to any value, but it SHOULD be set to + the same value as that for any audio packets in the same RTP + stream in order to avoid RTP timestamp rate switching. + + T38FaxRateManagement: Indicates the fax rate management model as + defined in T.38. Values may be "localTCF" or "transferredTCF". + This parameter is defined in ITU-T Recommendation T.38. + + Optional parameters: + + T38FaxFillBitRemoval: Indicates the capability to remove and + insert fill bits in Phase C (refer to [6]), non-ECM data to reduce + bandwidth. This is a boolean parameter (inclusion = true, + exclusion = false). This parameter is defined in ITU-T + Recommendation T.38. + + + + + + +Jones & Tamura Historic [Page 3] + +RFC 4612 Real-time Facsimile (T.38) - audio /t38 August 2006 + + + T38FaxTranscodingMMR: Indicates the ability to convert to/from MMR + from/to the line format for increasing the compression of the data + and reducing the bandwidth in the packet network. This is a + boolean parameter (inclusion = true, exclusion = false). This + parameter is defined in ITU-T Recommendation T.38. + + T38FaxTranscodingJBIG: Indicates the ability to convert to/from + JBIG to reduce bandwidth. This is a boolean parameter (inclusion + = true, exclusion = false). This parameter is defined in ITU-T + Recommendation T.38. + + T38FaxVersion: This is the version number of ITU-T Rec. T.38. New + versions shall be compatible with previous versions. Absence of + this parameter indicates version 0. The version is expressed as + an integer value. This parameter is defined in ITU-T + Recommendation T.38. + + T38FaxMaxBuffer: Indicates the maximum number of octets that can + be stored on the remote device before an overflow condition + occurs. It is the responsibility of the transmitting application + to limit the transfer rate to prevent an overflow. The negotiated + data rate should be used to determine the rate at which data is + being removed from the buffer. Value is an integer. This + parameter is defined in ITU-T Recommendation T.38. + + T38FaxMaxDatagram: The maximum size of the payload within an RTP + packet that can be accepted by the remote device. This is an + integer value. This parameter is defined in ITU-T Recommendation + T.38. + + Encoding considerations: + + The encoding of the IFP RTP packets is defined in ITU-T + Recommendation T.38. This sub-type is not intended for use with + e-mail. + + Security considerations: + + See Section 6 of RFC 4612. + + Interoperability considerations: + + ITU-T Recommendation T.38 defines the procedures, syntax, and + parameters for the carriage of T.38 over RTP within the context of + H.323 [8], SIP [9], and H.248 [7] systems. + + + + + + +Jones & Tamura Historic [Page 4] + +RFC 4612 Real-time Facsimile (T.38) - audio /t38 August 2006 + + + Published specification: + + ITU-T Recommendation T.38, "Procedures for real-time Group 3 + facsimile communication over IP networks", September 2005 + + Applications which use this media type: + + Real-time facsimile (fax) + + Additional information: + + Magic number(s): File extension(s): Macintosh File Type Code(s): + + Person & email address to contact for further information: + + Paul E. Jones paulej@packetizer.com + + Intended usage: COMMON + + Author/Change controller: Paul E. Jones + +5. SDP Mapping of MIME Parameters + + The MIME information described in Section 4 is utilized in SDP in + order to establish T.38 media streams. Specifically: + + o The MIME type ("audio") goes in SDP "m=" as the media name. + + o The MIME subtype ("t38") goes in SDP "a=rtpmap" as the encoding + name. + + o The parameter "rate" also goes in "a=rtpmap" as clock rate. + + The MIME type defines several required and optional parameters to + qualify the operation of T.38; these are to be used as defined in RFC + 3555 [5], Section 2. The parameters are provided as a semi-colon + separated list of "parameter" or "parameter=value" pairs using the + "a=fmtp" parameter defined in SDP [2]; the "parameter" form is used + for boolean values, where presence equals "true" and absence "false". + + Consider the following example, which describes a media stream that + allows the transport of G.711 audio and T.38 fax information: + + m=audio 6800 RTP/AVP 0 98 a=rtpmap:98 t38/8000 a=fmtp:98 + T38FaxVersion=2;T38FaxRateManagement=transferredTCF + + + + + + +Jones & Tamura Historic [Page 5] + +RFC 4612 Real-time Facsimile (T.38) - audio /t38 August 2006 + + +6. Security Considerations + + T.38 is vulnerable to attacks that are common to other types of RTP + and SRTP payloads. However, unlike audio, T.38 data may be + manipulated in ways that are more obtrusive than audio. For example, + rogue packets may cause transmission failure, and manipulated packets + may alter terminal identity. + + The security considerations discussed in the RTP specification and + any applicable RTP profile (for example, [10]) are applicable to + T.38. Regarding SRTP configuration, fax payloads SHOULD NOT use an + HMAC-SHA1 authentication tag that is shorter than 80 bits. + +7. Normative References + + [1] ITU-T Recommendation T.38, "Procedures for real-time Group 3 + facsimile communication over IP networks", September 2005. + + [2] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", STD 64, + RFC 3550, July 2003. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Casner, S. and P. Hoschka, "MIME Type Registration of RTP + Payload Formats", RFC 3555, July 2003. + + [6] ITU-T Recommendation T.30, "Procedures for document facsimile + transmission in the general switched telephone network", July + 2003. + +8. Informative References + + [7] ITU-T Recommendation H.248, "Gateway Control Protocol", May + 2002. + + [8] ITU-T Recommendation H.323, "Packet-based multimedia + communications systems", May 2003. + + [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + + + + +Jones & Tamura Historic [Page 6] + +RFC 4612 Real-time Facsimile (T.38) - audio /t38 August 2006 + + + [10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC + 3711, March 2004. + + [11] Parsons, G., "Real-time Facsimile (T.38) - image/t38 MIME Sub- + type Registration", RFC 3362, August 2002. + + [12] Perkins, C., et al., "RTP Payload for Redundant Audio Data", RFC + 2198, September 1997. + + [13] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for + Low-Speed Serial Links", RFC 2508, February 1999. + + [14] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. + Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High + Delay, Packet Loss and Reordering", RFC 3545, July 2003. + +Authors' Addresses + + Paul E. Jones + Cisco Systems, Inc. + 7025 Kit Creek Rd. + Research Triangle Park, NC 27709, USA + + Phone: +1 919 392 6948 + EMail: paulej@packetizer.com + + + Hiroshi Tamura + Ricoh Company, LTD. + 1-3-6 Nakamagome, Ohta-ku, + Tokyo 143-8555 Japan + + Phone: +81-3-3777-8124 + Fax: +81-3-5742-8859 + EMail: tamura@cs.ricoh.co.jp + + + + + + + + + + + + + + + +Jones & Tamura Historic [Page 7] + +RFC 4612 Real-time Facsimile (T.38) - audio /t38 August 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Jones & Tamura Historic [Page 8] + -- cgit v1.2.3