Internet Engineering Task Force (IETF) D. Hanes
Request for Comments: 6913 G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 K. Fleming
Digium, Inc.
March 2013
Internet Engineering Task Force (IETF) D. Hanes
Request for Comments: 6913 G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 K. Fleming
Digium, Inc.
March 2013
Indicating Fax over IP Capability in the Session Initiation Protocol (SIP)
指示会话启动协议（SIP）中的IP传真功能
Abstract
摘要
This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP). Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.
本文档定义并向IANA注册新的“传真”媒体功能标签，以用于会话启动协议（SIP）。目前，传真呼叫与通话开始时的语音呼叫无法区分。因此，传真呼叫可以路由到不支持传真的SIP用户代理。“传真”媒体功能标签与呼叫者首选项结合使用，可实现更准确的传真呼叫路由。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6913.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6913.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Usage of the "sip.fax" Parameter . . . . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Usage of the "sip.fax" Parameter . . . . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Fax communications in the Session Initiation Protocol (SIP) [RFC3261] are handled in a "voice first" manner. Indications that a user desires to use a fax transport protocol, such as ITU-T T.38 [T38], to send a fax are not known when the initial INVITE message is sent. The call is set up as a voice call first, and then, only after it is connected, does a switchover to the T.38 [T38] protocol occur. This is problematic in that fax calls can be routed inadvertently to SIP user agents (UAs) that are not fax capable.
会话发起协议（SIP）[RFC3261]中的传真通信以“语音优先”的方式处理。当发送初始INVITE消息时，不知道用户希望使用传真传输协议（例如ITU-T T.38[T38]）来发送传真的指示。首先将呼叫设置为语音呼叫，然后，只有在连接后，才会切换到T.38[T38]协议。这是有问题的，因为传真呼叫可能会无意中路由到不支持传真的SIP用户代理（UAs）。
To ensure that fax calls are routed to fax-capable SIP UAs, an implementation of caller preferences defined in RFC 3841 [RFC3841] can be used. Feature preferences are a part of RFC 3841 [RFC3841] that would allow UAs to express their preference for receiving fax communications. Subsequently, SIP servers take these preferences into account to increase the likelihood that fax calls are routed to fax-capable SIP UAs.
为了确保传真呼叫路由到具有传真功能的SIP UAs，可以使用RFC 3841[RFC3841]中定义的呼叫者首选项的实现。功能首选项是RFC 3841[RFC3841]的一部分，它允许UAs表达其接收传真通信的偏好。随后，SIP服务器将这些首选项考虑在内，以增加将传真呼叫路由到具有传真功能的SIP UAs的可能性。
This document defines the "fax" media feature tag for use in the SIP tree, as per Section 12.1 of RFC 3840 [RFC3840]. This feature tag will be applied per RFC 3841 [RFC3841] as a feature preference for fax-capable UAs.
根据RFC 3840[RFC3840]第12.1节，本文件定义了SIP树中使用的“传真”媒体功能标签。此功能标签将根据RFC 3841[RFC3841]应用，作为支持传真的UAs的功能首选项。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In the majority of circumstances, it is preferred that capabilities be handled in the Session Description Protocol (SDP) portion of the SIP [RFC3261] communication. However, fax is somewhat unique in that the ultimate intention of the call is not accurately signaled in the initial SDP exchange. Specifically, indications of T.38 [T38] or any other fax transport protocol in the call are not known when the call is initiated by an INVITE message. Fax calls are always considered voice calls until after they are connected. This results in the possibility of fax calls being received by SIP UAs that are not capable of handling fax transmissions.
在大多数情况下，优选在SIP[RFC3261]通信的会话描述协议（SDP）部分中处理能力。然而，传真在某种程度上是独特的，因为在最初的SDP交换中，呼叫的最终意图没有准确地发出信号。具体地说，当通过INVITE消息发起呼叫时，不知道呼叫中的T.38[T38]或任何其他传真传输协议的指示。传真呼叫在连接之前始终被视为语音呼叫。这导致SIP UAs可能接收到无法处理传真传输的传真呼叫。
For example, Alice wants to send a fax to Bob. Bob has registered two SIP UAs. The first SIP UA is not fax capable, but the second one supports the T.38 [T38] fax protocol. Currently, SIP servers are unable to know at the time that the call starts that Alice prefers a fax-capable SIP UA to handle her call. Additionally, the SIP servers are also not aware of which of Bob's SIP UAs are fax capable.
例如，爱丽丝想给鲍勃发一份传真。Bob注册了两个SIP UAs。第一个SIP UA不支持传真，但第二个支持T.38[T38]传真协议。目前，SIP服务器无法在呼叫开始时知道Alice更喜欢使用具有传真功能的SIP UA来处理她的呼叫。此外，SIP服务器也不知道Bob的哪些SIP UAs支持传真。
To resolve this issue of calls not arriving at a UA that supports fax, this document defines a new media feature tag specific to fax, per RFC 3840 [RFC3840]. Caller preferences, as defined in RFC 3841 [RFC3841], can then be used for registering UAs that support fax and for routing fax calls to these UAs. Thus, Alice can express up front that she prefers a T.38 [T38] fax-capable SIP UA for this call. At the same time, Bob's SIP UAs have expressed their fax capabilities as well during registration. Now, when Alice places a fax call to Bob, the call is appropriately routed to Bob's fax-capable SIP UA.
为了解决呼叫未到达支持传真的UA的问题，本文档根据RFC 3840[RFC3840]定义了传真专用的新媒体功能标签。然后，可以使用RFC 3841[RFC3841]中定义的呼叫者首选项注册支持传真的UAs，并将传真呼叫路由到这些UAs。因此，Alice可以提前表示，她更喜欢使用支持T.38[T38]传真的SIP UA进行此呼叫。同时，Bob的SIP UAs也在注册期间展示了其传真功能。现在，当Alice向Bob发出传真呼叫时，该呼叫将被适当地路由到Bob的具有传真功能的SIP UA。
The "sip.fax" media feature tag is a new string parameter, defined in this document, that allows a call to indicate a fax preference. A receiving UA includes the "sip.fax" media feature tag in the Contact header field of REGISTER messages to indicate that it is fax capable, and a SIP Registrar includes this tag in the Contact header field of its 200 OK response to confirm the registration of this preference, all as per RFC 3840 [RFC3840].
“sip.fax”媒体功能标签是本文档中定义的一个新字符串参数，它允许调用来指示传真首选项。接收UA在注册消息的联系人报头字段中包括“sip.fax”媒体特征标签，以指示其能够传真，并且sip注册器在其200 OK响应的联系人报头字段中包括该标签，以确认该首选项的注册，所有这些都符合RFC 3840[RFC3840]。
A calling UA SHOULD include the "sip.fax" media feature tag in the Accept-Contact header of an INVITE request in order to express its desire for a call to be routed to a fax-capable UA. Otherwise, without this tag, fax call determination is not possible until after the call is connected. If a calling UA includes the "sip.fax" tag and the SIP network elements that process the call (including the called UAs) implement the procedures of RFC 3840 and RFC 3841, the call will be preferentially routed to UAs that have advertised their support for this feature (by including it in the Contact header of their REGISTER requests, as documented above).
主叫UA应在INVITE请求的Accept Contact标头中包含“sip.fax”媒体功能标签，以表示其希望将呼叫路由到具有传真功能的UA。否则，如果没有此标签，则在连接呼叫之前无法确定传真呼叫。如果主叫UA包括“sip.fax”标签，并且处理呼叫的sip网元（包括被叫UAs）实现RFC 3840和RFC 3841的过程，则呼叫将优先路由到已公布其对该功能的支持的UAs（如上所述，将其包含在注册请求的联系人标题中）。
It is possible for the calling UA to utilize additional procedures defined in RFC 3840 and RFC 3841 to express a requirement (instead of a preference) that its call be delivered to fax-capable UAs. However, the calling UA SHOULD NOT require the "sip.fax" media type. Doing so could result in call failure for a number of reasons, not only because there may not be any receiving UAs registered that have advertised their support for this feature, but also because one or more SIP network elements that process the call may not support the processing defined in RFC 3840 and RFC 3841. A calling UA that wishes to express this requirement should be prepared to relax it to a preference if it receives a failure response indicating that the requirement mechanism itself is not supported by the called UAs, their proxies, or other SIP network elements.
主叫UA可以利用RFC 3840和RFC 3841中定义的附加程序来表示将其呼叫发送给具有传真功能的UA的要求（而不是偏好）。但是，呼叫UA不应要求“sip.fax”媒体类型。这样做可能会由于多种原因导致呼叫失败，这不仅是因为可能没有注册的任何接收UAs公布其对该功能的支持，还因为处理呼叫的一个或多个SIP网元可能不支持RFC 3840和RFC 3841中定义的处理。如果希望表达此需求的呼叫UA接收到故障响应，表明被呼叫UA、其代理或其他SIP网络元件不支持需求机制本身，则应准备将其放宽为首选项。
When calls do connect through the use of "sip.fax" either as a preference or a requirement, UAs should follow standard fax negotiation procedures documented in ITU-T T.38 [T38] for T.38 fax calls and ITU-T G.711 [G711] and ITU-T V.152 [V152], Sections 6 and 6.1, for fax passthrough calls. Subsequently, the "sip.fax" feature tag has two allowed values: "t38" and "passthrough". The "t38" value indicates that the impending call will utilize the ITU-T T.38 [T38] protocol for the fax transmission. The "passthrough" value indicates that the ITU-T G.711 [G711] codec will be used to transport the fax call.
当呼叫通过使用“sip.fax”进行连接时，无论是作为首选还是作为要求，UAs都应遵循ITU-T T.38[T38]中记录的标准传真协商程序（T.38传真呼叫）以及ITU-T G.711[G711]和ITU-T V.152[V152]第6节和第6.1节中记录的传真直通呼叫。随后，“sip.fax”特性标记有两个允许的值：“t38”和“passthrough”。“t38”值表示即将到来的呼叫将利用ITU-T T.38[t38]协议进行传真传输。“passthrough”值表示将使用ITU-T G.711[G711]编解码器传输传真呼叫。
Bob registers with the fax media feature tag. The message flow is shown in Figure 1:
Bob使用传真媒体功能标签注册。消息流如图1所示：
SIP Registrar Bob's SIP UA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| REGISTER F1 |
|<------------------------------|
| |
| 200 OK F2 |
|------------------------------>|
| |
SIP Registrar Bob's SIP UA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| REGISTER F1 |
|<------------------------------|
| |
| 200 OK F2 |
|------------------------------>|
| |
Figure 1: Fax Media Feature Tag SIP Registration Example
图1：传真媒体功能标签SIP注册示例
F1 REGISTER Bob -> Registrar
F1注册Bob->REGISTER
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP bob-TP.example.com:5060;branch=z9hG4bK309475a2
From: <sip:bob-tp@example.com>;tag=a6c85cf
To: <sip:bob-tp@pexample.com>
Call-ID: a84b4c76e66710
Max-Forwards: 70
CSeq: 116 REGISTER
Contact: <sip:bob-tp@pc33.example.com;transport=tcp>;+sip.fax="t38"
Expires: 3600
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP bob-TP.example.com:5060;branch=z9hG4bK309475a2
From: <sip:bob-tp@example.com>;tag=a6c85cf
To: <sip:bob-tp@pexample.com>
Call-ID: a84b4c76e66710
Max-Forwards: 70
CSeq: 116 REGISTER
Contact: <sip:bob-tp@pc33.example.com;transport=tcp>;+sip.fax="t38"
Expires: 3600
The registrar responds with a 200 OK:
注册器以200 OK响应：
F2 200 OK Registrar -> Bob
F2 200正常注册器->鲍勃
SIP/2.0 200 OK
From: <sip:bob-tp@example.com>;tag=a6c85cf
To: <sip:bob-tp@example.com>;tag=1263390604
Contact: <sip:bob-tp@example.com;transport=tcp>;+sip.fax="t38"
Expires: 120
Call-ID: a84b4c76e66710
Via: SIP/2.0/TCP bob-TP.example.com:5060;branch=z9hG4bK309475a2
CSeq: 116 REGISTER
Expires: 3600
SIP/2.0 200 OK
From: <sip:bob-tp@example.com>;tag=a6c85cf
To: <sip:bob-tp@example.com>;tag=1263390604
Contact: <sip:bob-tp@example.com;transport=tcp>;+sip.fax="t38"
Expires: 120
Call-ID: a84b4c76e66710
Via: SIP/2.0/TCP bob-TP.example.com:5060;branch=z9hG4bK309475a2
CSeq: 116 REGISTER
Expires: 3600
Callers desiring to express a preference for fax will include the "sip.fax" media feature tag in the Accept-Contact header of their INVITE.
希望表达传真偏好的呼叫者将在其邀请的Accept Contact标头中包含“sip.fax”媒体功能标签。
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Accept-Contact: *;+sip.fax="t38"
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 151
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Accept-Contact: *;+sip.fax="t38"
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 151
The security considerations related to the use of media feature tags from Section 11.1 of RFC 3840 [RFC3840] apply.
与使用RFC 3840[RFC3840]第11.1节中的媒体功能标签相关的安全注意事项适用。
This specification adds a new media feature tag to the SIP Media Feature Tag Registration Tree per the procedures defined in RFC 2506 [RFC2506] and RFC 3840 [RFC3840].
本规范按照RFC 2506[RFC2506]和RFC 3840[RFC3840]中定义的过程，向SIP媒体功能标签注册树添加新的媒体功能标签。
Media feature tag name: sip.fax
媒体功能标签名称：sip.fax
ASN.1 Identifier: 1.3.6.1.8.4.25
ASN.1标识符：1.3.6.1.8.4.25
Summary of the media feature indicated by this tag: This feature tag indicates whether a communications device supports the ITU-T T.38 [T38] fax protocol ("t38") or the passthrough method of fax transmission using the ITU-T G.711 [G711] audio codec ("passthrough").
此标签指示的媒体功能概述：此功能标签指示通信设备是否支持ITU-T T.38[T38]传真协议（“T38”）或使用ITU-T G.711[G711]音频编解码器的传真传输直通方法（“直通”）。
Values appropriate for use with this feature tag: Token with an equality relationship. Values are:
适用于此功能标记的值：具有相等关系的标记。价值观是：
t38: The device supports the "image/t38" media type [RFC3326] and implements ITU-T T.38 [T38] for transporting the ITU-T T.30 [T30] and ITU-T T.4 [T4] fax data over IP.
t38：设备支持“图像/t38”媒体类型[RFC3326]，并实现ITU-T T.38[t38]，用于通过IP传输ITU-T T.30[T30]和ITU-T T.4[T4]传真数据。
passthrough: The device supports the "audio/pcmu" and "audio/ pcma" media types [RFC4856] for transporting ITU-T T.30 [T30] and ITU-T T.4 [T4] fax data using the ITU-T G.711 [G711] audio codec. Additional implementation recommendations are in ITU-T V.152 [V152], Sections 6 and 6.1.
直通：设备支持“音频/pcmu”和“音频/pcma”媒体类型[RFC4856]，用于使用ITU-T G.711[G711]音频编解码器传输ITU-T T.30[T30]和ITU-T T.4[T4]传真数据。其他实施建议见ITU-T V.152[V152]，第6节和第6.1节。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for the early identification of a Fax over IP (FoIP) call.
功能标签主要用于以下应用、协议、服务或协商机制：此功能标签在通信应用中最有用，用于早期识别IP传真（FoIP）呼叫。
Examples of typical use: Ensuring a fax call is routed to a fax capable SIP UA.
典型用途示例：确保传真呼叫路由到具有传真功能的SIP UA。
Related standards or documents: RFC 6913
相关标准或文件：RFC 6913
Security Considerations: The security considerations related to the use of media feature tags from Section 11.1 of RFC 3840 [RFC3840] apply.
安全注意事项：与使用RFC 3840[RFC3840]第11.1节中的媒体功能标签相关的安全注意事项适用。
This document is a result of the unique cooperation between the SIP Forum and the i3 Forum, who embarked on a groundbreaking international test program for FoIP to improve the interoperability and reliability of fax communications over IP networks, especially tandem networks. The authors would like to acknowledge the effort and dedication of all the members of the Fax-over-IP (FoIP) Task Group in the SIP Forum and the communications carriers of the I3 Forum who contributed to this global effort.
本文件是SIP论坛和i3论坛之间独特合作的结果，他们启动了一项开创性的FoIP国际测试计划，以提高IP网络（特别是串联网络）上传真通信的互操作性和可靠性。作者要感谢SIP论坛IP传真（FoIP）工作组的所有成员以及I3论坛的通信运营商为这一全球努力做出的贡献和奉献。
This memo has benefited from the discussion and review of the DISPATCH working group, especially the detailed and thoughtful comments and corrections of Dan Wing, Paul Kyzivat, Christer Holmberg, Charles Eckel, Hadriel Kaplan, Tom Yu, Dale Worley, Adrian Farrel, and Pete Resnick.
本备忘录得益于派遣工作组的讨论和审查，特别是Dan Wing、Paul Kyzivat、Christer Holmberg、Charles Eckel、Hadriel Kaplan、Tom Yu、Dale Worley、Adrian Farrel和Pete Resnick的详细和深思熟虑的评论和更正。
The authors also thank Gonzalo Camarillo for his review and AD sponsorship of this draft and DISPATCH WG chair, Mary Barnes, for her review and support.
作者还感谢Gonzalo Camarillo对该草案的审查和广告赞助，并感谢工作组主席Mary Barnes的审查和支持。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[T38] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP Networks", ITU-T Recommendation T.38, October 2010.
[T38]国际电信联盟，“IP网络实时第3组传真通信程序”，ITU-T建议T.38，2010年10月。
[G711] International Telephone and Telegraph Consultative Committee, "Pulse Code Modulation (PCM) of Voice Frequencies", CCITT Recommendation G.711, 1972.
[G711]国际电话电报咨询委员会，“语音频率的脉冲编码调制（PCM）”，CCITT建议G.7111972。
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC2506]Holtman，K.，Mutz，A.，和T.Hardie，“媒体功能标签注册程序”，BCP 31，RFC 2506，1999年3月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，2002年12月。
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007.
[RFC4856]Casner，S.，“音频和视频会议RTP配置文件中有效负载格式的媒体类型注册”，RFC 4856，2007年2月。
[T30] International Telecommunication Union, "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, September 2005.
[T30]国际电信联盟，“通用交换电话网络中文件传真传输程序”，ITU-T建议T.30，2005年9月。
[T4] International Telecommunication Union, "Standardization of Group 3 facsimile terminals for document transmission", ITU-T Recommendation T.4, July 2003.
[T4]国际电信联盟，“文件传输用第3组传真终端的标准化”，ITU-T建议T.4，2003年7月。
[V152] International Telecommunication Union, "Procedures for supporting voice-band data over IP networks", ITU-T Recommendation V.152, September 2010.
[V152]国际电信联盟，“支持IP网络上语音带数据的程序”，ITU-T建议V.152，2010年9月。
Authors' Addresses
作者地址
David Hanes Cisco Systems 7200-10 Kit Creek Road Research Triangle Park, NC 27709 US
David Hanes Cisco Systems 7200-10美国北卡罗来纳州Kit Creek Road研究三角公园，邮编27709
EMail: dhanes@cisco.com
EMail: dhanes@cisco.com
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Gonzalo Salgueiro思科系统7200-12美国北卡罗来纳州Kit Creek Road研究三角公园，邮编27709
EMail: gsalguei@cisco.com
EMail: gsalguei@cisco.com
Kevin P. Fleming Digium, Inc. 445 Jan Davis Drive NW Huntsville, AL 35806 US
Kevin P.Fleming Digium，Inc.美国阿拉巴马州亨茨维尔市西北詹戴维斯大道445号，邮编35806
EMail: kevin@kpfleming.us
EMail: kevin@kpfleming.us