Network Working Group G. Camarillo
Request for Comments: 5369 Ericsson
Category: Informational October 2008
Network Working Group G. Camarillo
Request for Comments: 5369 Ericsson
Category: Informational October 2008
Framework for Transcoding with the Session Initiation Protocol (SIP)
使用会话启动协议（SIP）进行代码转换的框架
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals.
本文档定义了一个使用SIP进行代码转换的框架。该框架包括如何发现会话中对代码转换服务的需求以及如何调用这些代码转换服务。讨论了代码转换服务调用的两种模型：会议桥模型和第三方呼叫控制模型。这两种模型都满足SIP关于转码服务调用的要求，以支持聋人、听力障碍者和言语障碍者。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Discovery of the Need for Transcoding Services . . . . . . . . 2
3. Transcoding Services Invocation . . . . . . . . . . . . . . . . 4
3.1. Third-Party Call Control Transcoding Model . . . . . . . . 4
3.2. Conference Bridge Transcoding Model . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Discovery of the Need for Transcoding Services . . . . . . . . 2
3. Transcoding Services Invocation . . . . . . . . . . . . . . . . 4
3.1. Third-Party Call Control Transcoding Model . . . . . . . . 4
3.2. Conference Bridge Transcoding Model . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Two user agents involved in a SIP [RFC3261] dialog may find it impossible to establish a media session due to a variety of incompatibilities. Assuming that both user agents understand the same session description format (e.g., SDP [RFC4566]), incompatibilities can be found at the user agent level and at the user level. At the user agent level, both terminals may not support any common codec or may not support common media types (e.g., a text-only terminal and an audio-only terminal). At the user level, a deaf person will not understand anything said over an audio stream.
SIP[RFC3261]对话框中涉及的两个用户代理可能会发现，由于各种不兼容，无法建立媒体会话。假设两个用户代理都理解相同的会话描述格式（例如SDP[RFC4566]），则可以在用户代理级别和用户级别发现不兼容。在用户代理级别，两个终端可能不支持任何公共编解码器，或者可能不支持公共媒体类型（例如，纯文本终端和纯音频终端）。在用户级别，聋人将无法理解音频流中所说的任何内容。
In order to make communications possible in the presence of incompatibilities, user agents need to introduce intermediaries that provide transcoding services to a session. From the SIP point of view, the introduction of a transcoder is done in the same way to resolve both user level and user agent level incompatibilities. So, the invocation mechanisms described in this document are generally applicable to any type of incompatibility related to how the information that needs to be communicated is encoded.
为了在存在不兼容的情况下实现通信，用户代理需要引入向会话提供转码服务的中介。从SIP的角度来看，转码器的引入与解决用户级和用户代理级不兼容的方式相同。因此，本文档中描述的调用机制通常适用于与需要通信的信息编码方式相关的任何类型的不兼容。
Furthermore, although this framework focuses on transcoding, the mechanisms described are applicable to media manipulation in general. It would be possible to use them, for example, to invoke a server that simply increases the volume of an audio stream.
此外，尽管该框架侧重于转码，但所描述的机制通常适用于媒体操纵。例如，可以使用它们来调用只增加音频流音量的服务器。
This document does not describe media server discovery. That is an orthogonal problem that one can address using user agent provisioning or other methods.
本文档不描述媒体服务器发现。这是一个正交问题，可以使用用户代理配置或其他方法来解决。
The remainder of this document is organized as follows. Section 2 deals with the discovery of the need for transcoding services for a particular session. Section 3 introduces the third-party call control and conference bridge transcoding invocation models, which are further described in Sections 3.1 and 3.2, respectively. Both models meet the requirements regarding transcoding services invocation in RFC 3351 [RFC3351], which support deaf, hard of hearing, and speech-impaired individuals.
本文件的其余部分组织如下。第2节涉及发现特定会话的转码服务需求。第3节介绍了第三方呼叫控制和会议网桥转码调用模型，分别在第3.1节和第3.2节中进行了进一步描述。这两种模型都满足RFC 3351[RFC3351]中关于代码转换服务调用的要求，RFC 3351[RFC3351]支持聋人、听力障碍者和言语障碍者。
According to the one-party consent model defined in RFC 3238 [RFC3238], services that involve media manipulation invocation are best invoked by one of the endpoints involved in the communication, as opposed to being invoked by an intermediary in the network. Following this principle, one of the endpoints should be the one detecting that transcoding is needed for a particular session.
根据RFC 3238[RFC3238]中定义的一方同意模型，涉及媒体操纵调用的服务最好由通信中涉及的端点之一调用，而不是由网络中的中介调用。根据这一原则，其中一个端点应该是检测特定会话需要转码的端点。
In order to decide whether or not transcoding is needed, a user agent needs to know the capabilities of the remote user agent. A user agent acting as an offerer [RFC3264] typically obtains this knowledge by downloading a presence document that includes media capabilities (e.g., Bob is available on a terminal that only supports audio) or by getting an SDP description of media capabilities as defined in RFC 3264 [RFC3264].
为了决定是否需要转码，用户代理需要了解远程用户代理的功能。作为报价人[RFC3264]的用户代理通常通过下载包含媒体能力的状态文档（例如，Bob在仅支持音频的终端上可用）或通过获取RFC 3264[RFC3264]中定义的媒体能力的SDP描述来获得该知识。
Presence documents are typically received in a NOTIFY request [RFC3265] as a result of a subscription. SDP media capabilities descriptions are typically received in a 200 (OK) response to an OPTIONS request or in a 488 (Not Acceptable Here) response to an INVITE.
作为订阅的结果，状态文档通常在通知请求[RFC3265]中接收。SDP媒体功能描述通常在对选项请求的200（确定）响应或对邀请的488（此处不接受）响应中接收。
In the absence of presence information, routing logic that involves parallel forking to several user agents may make it difficult (or impossible) for the caller to know which user agent will answer the next call attempt. For example, a call attempt may reach the user's voicemail while the next one may reach a SIP phone where the user is available. If both terminating user agents have different capabilities, the caller cannot know, even after the first call attempt, whether or not transcoding will be necessary for the session. This is a well-known SIP problem that is referred to as HERFP (Heterogeneous Error Response Forking Problem). Resolving HERFP is outside the scope of this document.
在缺少状态信息的情况下，涉及到并行分叉到多个用户代理的路由逻辑可能使调用者难以（或不可能）知道哪个用户代理将应答下一次呼叫尝试。例如，呼叫尝试可能到达用户的语音邮件，而下一次可能到达用户可用的SIP电话。如果两个终止用户代理具有不同的功能，则即使在第一次呼叫尝试之后，调用方也无法知道会话是否需要转码。这是一个众所周知的SIP问题，称为HERFP（异构错误响应分叉问题）。解决HERFP超出了本文档的范围。
It is recommended that an offerer does not invoke transcoding services before making sure that the answerer does not support the capabilities needed for the session. Making wrong assumptions about the answerer's capabilities can lead to situations where two transcoders are introduced (one by the offerer and one by the answerer) in a session that would not need any transcoding services at all.
建议报价人在确保应答人不支持会话所需的功能之前不要调用代码转换服务。对应答者的能力做出错误的假设可能会导致在会话中引入两个转码器（一个由报价人引入，另一个由应答人引入）的情况，而这些转码器根本不需要任何转码服务。
An example of the situation above is a call between two GSM (Global System for Mobile Communications) phones (without using transcoding-free operation). Both phones use a GSM codec, but the speech is converted from GSM to PCM (Pulse Code Modulation) by the originating MSC (Mobile Switching Center) and from PCM back to GSM by the terminating MSC.
上述情况的一个例子是两部GSM（全球移动通信系统）电话之间的通话（不使用无转码操作）。两部手机都使用GSM编解码器，但语音由发起MSC（移动交换中心）从GSM转换为PCM（脉冲编码调制），并由终端MSC从PCM转换回GSM。
Note that transcoding services can be symmetric (e.g., speech-to-text plus text-to-speech) or asymmetric (e.g., a one-way speech-to-text transcoding for a hearing-impaired user that can talk).
注意，转码服务可以是对称的（例如，语音到文本加上文本到语音）或非对称的（例如，对于可以说话的听力受损用户的单向语音到文本转码）。
Once the need for transcoding for a particular session has been identified as described in Section 2, one of the user agents needs to invoke transcoding services.
一旦如第2节所述确定了特定会话的转码需求，其中一个用户代理就需要调用转码服务。
As stated earlier, transcoder location is outside the scope of this document. So, we assume that the user agent invoking transcoding services knows the URI of a server that provides them.
如前所述，转码器位置不在本文件范围内。因此，我们假设调用代码转换服务的用户代理知道提供这些服务的服务器的URI。
Invoking transcoding services from a server (T) for a session between two user agents (A and B) involves establishing two media sessions; one between A and T and another between T and B. How to invoke T's services (i.e., how to establish both A-T and T-B sessions) depends on how we model the transcoding service. We have considered two models for invoking a transcoding service. The first is to use third-party call control [RFC3725], also referred to as 3pcc. The second is to use a (dial-in and dial-out) conference bridge that negotiates the appropriate media parameters on each individual leg (i.e., A-T and T-B).
为两个用户代理（a和B）之间的会话从服务器（T）调用转码服务涉及建立两个媒体会话；一个在A和T之间，另一个在T和B之间。如何调用T的服务（即，如何建立A-T和T-B会话）取决于我们如何对转码服务建模。我们考虑了两种调用代码转换服务的模型。第一种是使用第三方呼叫控制[RFC3725]，也称为3pcc。第二种方法是使用（拨入和拨出）会议桥，在每个分支（即a-T和T-B）上协商适当的媒体参数。
Section 3.1 analyzes the applicability of the third-party call control model, and Section 3.2 analyzes the applicability of the conference bridge transcoding invocation model.
第3.1节分析了第三方呼叫控制模型的适用性，第3.2节分析了会议桥转码调用模型的适用性。
In the 3pcc transcoding model, defined in [RFC4117], the user agent invoking the transcoding service has a signalling relationship with the transcoder and another signalling relationship with the remote user agent. There is no signalling relationship between the transcoder and the remote user agent, as shown in Figure 1.
在[RFC4117]中定义的3pcc转码模型中，调用转码服务的用户代理与转码器具有信令关系，与远程用户代理具有另一信令关系。代码转换器和远程用户代理之间没有信令关系，如图1所示。
+-------+
| |
| T |**
| | **
+-------+ **
^ * **
| * **
| * **
SIP * **
| * **
| * **
v * **
+-------+ +-------+
| | | |
| A |<-----SIP----->| B |
| | | |
+-------+ +-------+
+-------+
| |
| T |**
| | **
+-------+ **
^ * **
| * **
| * **
SIP * **
| * **
| * **
v * **
+-------+ +-------+
| | | |
| A |<-----SIP----->| B |
| | | |
+-------+ +-------+
<-SIP-> Signalling
******* Media
<-SIP-> Signalling
******* Media
Figure 1: Third-Party Call Control Model
图1：第三方呼叫控制模型
This model is suitable for advanced endpoints that are able to perform third party call control. It allows endpoints to invoke transcoding services on a stream basis. That is, the media streams that need transcoding are routed through the transcoder while the streams that do not need it are sent directly between the endpoints. This model also allows invoking one transcoder for the sending direction and a different one for the receiving direction of the same stream.
此模型适用于能够执行第三方呼叫控制的高级端点。它允许端点在流的基础上调用代码转换服务。也就是说，需要转码的媒体流通过转码器路由，而不需要转码的流直接在端点之间发送。该模型还允许为同一流的发送方向调用一个转码器，为接收方向调用另一个转码器。
Invoking a transcoder in the middle of an ongoing session is also quite simple. This is useful when session changes occur (e.g., an audio session is upgraded to an audio/video session) and the endpoints cannot cope with the changes (e.g., they had common audio codecs but no common video codecs).
在正在进行的会话中间调用代码转换器也是非常简单的。当发生会话更改（例如，音频会话升级为音频/视频会话）且端点无法应对更改（例如，它们具有通用音频编解码器，但没有通用视频编解码器）时，这非常有用。
The privacy level that is achieved using 3pcc is high, since the transcoder does not see the signalling between both endpoints. In this model, the transcoder only has access to the information that is strictly needed to perform its function.
使用3pcc实现的隐私级别很高，因为转码器看不到两个端点之间的信令。在此模型中，转码器只能访问执行其功能所需的信息。
In a centralized conference, there are a number of media streams between the conference server and each participant of a conference. For a given media type (e.g., audio) the conference server sends,
在集中式会议中，会议服务器和会议的每个参与者之间存在多个媒体流。对于会议服务器发送的给定媒体类型（例如音频），
over each individual stream, the media received over the rest of the streams, typically performing some mixing. If the capabilities of all the endpoints participating in the conference are not the same, the conference server may have to send audio to different participants using different audio codecs.
在每个单独流上，通过其余流接收的媒体，通常执行一些混合。如果参与会议的所有端点的功能不相同，则会议服务器可能必须使用不同的音频编解码器向不同的参与者发送音频。
Consequently, we can model a transcoding service as a two-party conference server that may change not only the codec in use, but also the format of the media (e.g., audio to text).
因此，我们可以将转码服务建模为一个两方会议服务器，该服务器不仅可以更改正在使用的编解码器，还可以更改媒体的格式（例如，音频到文本）。
Using this model, T behaves as a B2BUA (Back-to-Back User Agent) and the whole A-T-B session is established as described in [RFC5370]. Figure 2 shows the signalling relationships between the endpoints and the transcoder.
使用该模型，T表现为B2BUA（背对背用户代理），整个a-T-B会话如[RFC5370]所述建立。图2显示了端点和转码器之间的信令关系。
+-------+
| |**
| T | **
| |\ **
+-------+ \\ **
^ * \\ **
| * \\ **
| * SIP **
SIP * \\ **
| * \\ **
| * \\ **
v * \ **
+-------+ +-------+
| | | |
| A | | B |
| | | |
+-------+ +-------+
+-------+
| |**
| T | **
| |\ **
+-------+ \\ **
^ * \\ **
| * \\ **
| * SIP **
SIP * \\ **
| * \\ **
| * \\ **
v * \ **
+-------+ +-------+
| | | |
| A | | B |
| | | |
+-------+ +-------+
<-SIP-> Signalling
******* Media
<-SIP-> Signalling
******* Media
Figure 2: Conference Bridge Model
图2：会议桥模型
In the conferencing bridge model, the endpoint invoking the transcoder is generally involved in less signalling exchanges than in the 3pcc model. This may be an important feature for endpoints using low-bandwidth or high-delay access links (e.g., some wireless accesses).
在会议网桥模型中，调用转码器的端点所涉及的信令交换通常少于3pcc模型。这可能是使用低带宽或高延迟接入链路（例如，一些无线接入）的端点的一个重要特性。
On the other hand, this model is less flexible than the 3pcc model. It is not possible to use different transcoders for different streams or for different directions of a stream.
另一方面，该模型不如3pcc模型灵活。对于不同的流或流的不同方向，不可能使用不同的转码器。
Invoking a transcoder in the middle of an ongoing session or changing from one transcoder to another requires the remote endpoint to support the Replaces [RFC3891] extension. At present, not many user agents support it.
在正在进行的会话的中间调用代码转换器或从一个代码转换器转换到另一个代码转换器需要远程端点支持替换[RCFC991]扩展。目前，支持它的用户代理并不多。
Simple endpoints that cannot perform 3pcc and thus cannot use the 3pcc model, of course, need to use the conference bridge model.
当然，不能执行3pcc因而不能使用3pcc模型的简单端点需要使用会议网桥模型。
The specifications of the 3pcc and the conferencing transcoding models discuss security issues directly related to the implementation of those models. Additionally, there are some considerations that apply to transcoding in general.
3pcc和会议转码模型的规范讨论了与这些模型的实现直接相关的安全问题。此外，一般来说，转码还需要考虑一些因素。
In a session, a transcoder has access to at least some of the media exchanged between the endpoints. In order to avoid rogue transcoders getting access to those media, it is recommended that endpoints authenticate the transcoder. TLS [RFC5246] and S/MIME [RFC3850] can be used for this purpose.
在会话中，转码器可以访问端点之间交换的至少一些媒体。为了避免流氓转码器访问这些媒体，建议端点对转码器进行身份验证。TLS[RFC5246]和S/MIME[RFC3850]可用于此目的。
To achieve a higher degree of privacy, endpoints following the 3pcc transcoding model can use one transcoder in one direction and a different one in the other direction. This way, no single transcoder has access to all the media exchanged between the endpoints.
为了实现更高程度的隐私，遵循3pcc转码模型的端点可以在一个方向使用一个转码器，在另一个方向使用不同的转码器。这样，没有一个转码器可以访问端点之间交换的所有媒体。
The fact that transcoders need to access media exchanged between the endpoints implies that endpoints cannot use end-to-end media security mechanisms. Media encryption would not allow the transcoder to access the media, and media integrity protection would not allow the transcoder to modify the media (which is obviously necessary to perform the transcoding function). Nevertheless, endpoints can still use media security between the transcoder and themselves.
转码器需要访问端点之间交换的媒体这一事实意味着端点不能使用端到端媒体安全机制。媒体加密不允许转码器访问媒体，媒体完整性保护不允许转码器修改媒体（这显然是执行转码功能所必需的）。然而，端点仍然可以在转码器和自身之间使用媒体安全性。
This document is the result of discussions amongst the conferencing design team. The members of this team include Eric Burger, Henning Schulzrinne, and Arnoud van Wijk.
本文件是会议设计团队讨论的结果。这个团队的成员包括埃里克·伯格、亨宁·舒尔兹林内和阿诺德·范威克。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB体系结构和政策考虑”，RFC 3238，2002年1月。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3351] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.
[RFC3351]N.查尔顿、M.加斯森、G.吉贝尔斯、M.斯潘纳和A.范·威克，“支持聋人、听力障碍者和言语障碍者的会话启动协议（SIP）的用户需求”，RFC 3351，2002年8月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的当前最佳实践”，BCP 85，RFC 37252004年4月。
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3850]Ramsdell，B，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, "Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)", RFC 4117, June 2005.
[RFC4117]Camarillo，G.，Burger，E.，Schulzrinne，H.，和A.van Wijk，“使用第三方呼叫控制（3pcc）的会话启动协议（SIP）中的代码转换服务调用”，RFC 41172005年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5370] Camarillo, G., "The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model", RFC 5370, October 2008.
[RFC5370]Camarillo，G.“会话启动协议（SIP）会议桥转码模型”，RFC 5370，2008年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
Author's Address
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.