Network Working Group P. Jones
Request for Comments: 4612 Cisco Systems, Inc.
Category: Historic H. Tamura
Ricoh Company, LTD.
August 2006
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
实时传真（T.38）-音频/t38 MIME子类型注册
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).
版权所有（C）互联网协会（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.
本文档定义了MIME子类型audio/t38。ITU-T建议T.38中规定了拟在会话描述协议（SDP）中使用的这种MIME类型的用法。
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
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
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.
ITU-T建议T.38[1]定义了通过IP网络传输传真数据的互联网传真协议（IFP）。作为一个选项，IFP分组可以在RTP[3]流中携带，作为媒体流中的唯一内容，或者与其他音频有效负载类型交换。
This memo provides rationale for using RTP as a transport for fax signaling and specifies the MIME type associated with said signaling.
本备忘录提供了将RTP用作传真信令传输的基本原理，并指定了与所述信令相关的MIME类型。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
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.
当T.38于1998年首次获得批准时，它允许通过UDP（使用UDP传输层（UDPTL），而不是RTP）或TCP传输T.38。截至本出版物出版时，UDPTL是通过IP网络传输T.38数据的主要方式。为了支持这一点，发布了RFC 3362[11]，以允许设备发出使用UDPTL传输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].
但是，就UDPTL的长期使用提出了一些问题。具体而言，UDPTL不能提供与RTP控制协议（RTCP）相同的统计报告，这一事实引起了人们的关注。此外，没有用于加密和保护UDPTL流完整性的程序。虽然后者可以在UDPTL中解决，但这样做需要大量的努力，并且在很大程度上是IETF中已经完成的安全工作的重复；e、 例如，安全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.
在今天的T.38中使用RTP有明显的优势。例如，使用RTP允许利用IETF中的冗余[12]、报头压缩[13][14]和其他RTP相关工作。与UDPTL相反，使用RTP进行传输可以更好地与更多了解RTP的设备进行互操作。这包括防火墙、网络地址转换（NAT）设备和桥接两个IP网络的网关等应用程序，它们通常比大多数其他实时媒体更支持RTP。
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.
最后，由于目前大多数T.38数据是由桥接两个公共交换电话网络（PSTN）网络的网关生成的，因此很自然地，从音频到传真的转换应该发生在同一媒体流中。原因是T.38数据只是在PSTN电路上接收的信息的替代表示。如果将T.38数据封装在RTP中，网关可以很容易地从音频转换到传真再转换回来，并且可以简单地使用有效负载类型来指示当前正在传输的媒体类型。
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.
考虑到这些因素，ITU-T修改了T.38[1]，允许使用RTP传输T.38。因此，需要一个新的MIME注册（audio/t38），以允许T.38在同一RTP会话中与音频一起切换。
One new MIME type and associated RTP payload format has been registered, by the IANA as described below.
IANA已经注册了一种新的MIME类型和相关的RTP有效负载格式，如下所述。
To: ietf-types@iana.org Subject: Registration of Standard MIME media
type audio/t38
To: ietf-types@iana.org Subject: Registration of Standard MIME media
type audio/t38
MIME media type name: audio
MIME媒体类型名称：音频
MIME subtype name: t38
MIME子类型名称：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.
速率：RTP时间戳时钟速率，应为8000Hz。时钟频率可以设置为任何值，但是它应该设置为与相同RTP流中的任何音频分组相同的值，以避免RTP时间戳速率切换。
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.
T38FaxRateManagement：表示T.38中定义的传真速率管理模型。值可以是“localTCF”或“transferredTCF”。该参数在ITU-T建议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.
T38FaxFillBitRemoving：表示在阶段C（参考[6]）、非ECM数据中删除和插入填充位以减少带宽的能力。这是一个布尔参数（包含=真，排除=假）。该参数在ITU-T建议T.38中定义。
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.
T38FaxTranscodingMMR：表示能够将MMR从行格式转换为行格式，以增加数据压缩并减少分组网络中的带宽。这是一个布尔参数（包含=真，排除=假）。该参数在ITU-T建议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.
T38FaxTranscodingJBIG：表示与JBIG进行转换以减少带宽的能力。这是一个布尔参数（包含=真，排除=假）。该参数在ITU-T建议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.
T38FaxVersion：这是ITU-T Rec.T.38的版本号。新版本应与以前的版本兼容。缺少此参数表示版本0。版本以整数值表示。该参数在ITU-T建议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.
T38FaxMaxBuffer：表示在发生溢出情况之前，远程设备上可存储的最大八位字节数。传输应用程序负责限制传输速率以防止溢出。协商数据速率应用于确定从缓冲区中删除数据的速率。值是一个整数。该参数在ITU-T建议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.
T38FaxMaxDatagram：远程设备可以接受的RTP数据包内有效负载的最大大小。这是一个整数值。该参数在ITU-T建议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.
IFP RTP包的编码在ITU-T建议T.38中定义。此子类型不适用于电子邮件。
Security considerations:
安全考虑：
See Section 6 of RFC 4612.
参见RFC 4612第6节。
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.
ITU-T建议T.38定义了在H.323[8]、SIP[9]和H.248[7]系统中通过RTP传输T.38的程序、语法和参数。
Published specification:
已发布的规范：
ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", September 2005
ITU-T建议T.38，“通过IP网络进行实时第3组传真通信的程序”，2005年9月
Applications which use this media type:
使用此媒体类型的应用程序：
Real-time facsimile (fax)
实时传真（传真）
Additional information:
其他信息：
Magic number(s): File extension(s): Macintosh File Type Code(s):
幻数：文件扩展名：Macintosh文件类型代码：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Paul E. Jones paulej@packetizer.com
保罗·E·琼斯paulej@packetizer.com
Intended usage: COMMON
预期用途：普通
Author/Change controller: Paul E. Jones
作者/变更控制人：Paul E.Jones
The MIME information described in Section 4 is utilized in SDP in order to establish T.38 media streams. Specifically:
为了建立T.38媒体流，SDP中使用了第4节中描述的MIME信息。明确地：
o The MIME type ("audio") goes in SDP "m=" as the media name.
o MIME类型（“音频”）以SDP“m=”作为媒体名称。
o The MIME subtype ("t38") goes in SDP "a=rtpmap" as the encoding name.
o MIME子类型（“t38”）以SDP“a=rtpmap”作为编码名称。
o The parameter "rate" also goes in "a=rtpmap" as clock rate.
o 参数“rate”也作为时钟速率进入“a=rtpmap”。
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".
MIME类型定义了几个必需的和可选的参数，以限定T.38的操作；按照RFC 3555[5]第2节的规定使用。使用SDP[2]中定义的“a=fmtp”参数，以分号分隔的“参数”或“参数=值”对列表形式提供参数；“参数”形式用于布尔值，其中存在等于“真”，不存在等于“假”。
Consider the following example, which describes a media stream that allows the transport of G.711 audio and T.38 fax information:
考虑下面的例子，它描述了允许G.711音频和T.38传真信息传输的媒体流：
m=audio 6800 RTP/AVP 0 98 a=rtpmap:98 t38/8000 a=fmtp:98
T38FaxVersion=2;T38FaxRateManagement=transferredTCF
m=audio 6800 RTP/AVP 0 98 a=rtpmap:98 t38/8000 a=fmtp:98
T38FaxVersion=2;T38FaxRateManagement=transferredTCF
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.
T.38易受其他类型RTP和SRTP有效负载常见的攻击。然而，与音频不同，T.38数据的处理方式可能比音频更为突兀。例如，恶意数据包可能导致传输失败，而被操纵的数据包可能改变终端身份。
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.
RTP规范和任何适用的RTP配置文件（例如，[10]）中讨论的安全注意事项适用于T.38。关于SRTP配置，传真有效负载不应使用短于80位的HMAC-SHA1身份验证标签。
[1] ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", September 2005.
[1] ITU-T建议T.38，“通过IP网络进行实时第3组传真通信的程序”，2005年9月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[5] Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 3555，2003年7月。
[6] ITU-T Recommendation T.30, "Procedures for document facsimile transmission in the general switched telephone network", July 2003.
[6] ITU-T建议T.30，“通用交换电话网络中文件传真传输程序”，2003年7月。
[7] ITU-T Recommendation H.248, "Gateway Control Protocol", May 2002.
[7] ITU-T建议H.248，“网关控制协议”，2002年5月。
[8] ITU-T Recommendation H.323, "Packet-based multimedia communications systems", May 2003.
[8] ITU-T建议H.323，“基于分组的多媒体通信系统”，2003年5月。
[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.
[9] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[10] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[11] Parsons, G., "Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration", RFC 3362, August 2002.
[11] Parsons，G.，“实时传真（T.38）-图像/t38 MIME子类型注册”，RFC 3362，2002年8月。
[12] Perkins, C., et al., "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[12] Perkins，C.等人，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[13] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[13] Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[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.
[14] Koren，T.，Casner，S.，Geevarghese，J.，Thompson，B.，和P.Ruddy，“具有高延迟、数据包丢失和重新排序的链路的增强压缩RTP（CRTP）”，RFC 35452003年7月。
Authors' Addresses
作者地址
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709, USA
Paul E.Jones Cisco Systems，Inc.美国北卡罗来纳州三角研究公园Kit Creek路7025号，邮编27709
Phone: +1 919 392 6948
EMail: paulej@packetizer.com
Phone: +1 919 392 6948
EMail: paulej@packetizer.com
Hiroshi Tamura Ricoh Company, LTD. 1-3-6 Nakamagome, Ohta-ku, Tokyo 143-8555 Japan
Hiroshi Tamura Ricoh有限公司，日本东京大田区中谷国美1-3-6号，143-8555
Phone: +81-3-3777-8124
Fax: +81-3-5742-8859
EMail: tamura@cs.ricoh.co.jp
Phone: +81-3-3777-8124
Fax: +81-3-5742-8859
EMail: tamura@cs.ricoh.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。