summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4612.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4612.txt')
-rw-r--r--doc/rfc/rfc4612.txt451
1 files changed, 451 insertions, 0 deletions
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]
+