doc: Add RFC documents

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]
+