Network Working Group W. Marshall, Ed.
Request for Comments: 3313 AT&T
Category: Informational January 2003
Network Working Group W. Marshall, Ed.
Request for Comments: 3313 AT&T
Category: Informational January 2003
Private Session Initiation Protocol (SIP) Extensions for Media Authorization
用于媒体授权的专用会话启动协议（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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains.
本文档描述了对服务质量（QoS）和媒体授权的需求，并定义了会话启动协议（SIP）扩展，该扩展可用于将QoS准入控制与呼叫信令集成，并帮助防范拒绝服务攻击。此扩展的使用仅适用于管理域或具有先前约定策略的管理域联盟，其中授权QoS的SIP代理和提供QoS的基础网络的策略控制都属于该管理域或域联盟。
Table of Contents
目录
1. Scope of Applicability......................................... 2
2. Conventions Used in this Document.............................. 3
3. Background and Motivation...................................... 3
4. Overview....................................................... 4
5. Changes to SIP to Support Media Authorization.................. 4
5.1 SIP Header Extension....................................... 5
5.2 SIP Procedures............................................. 5
5.2.1 User Agent Client (UAC)................................ 6
5.2.2 User Agent Server (UAS)................................ 6
5.2.3 Originating Proxy (OP)................................. 7
5.2.4 Destination Proxy (DP)................................. 7
6. Examples....................................................... 8
6.1 Requesting Bandwidth via RSVP Messaging.................... 8
6.1.1 User Agent Client Side................................. 8
6.1.2 User Agent Server Side................................. 10
7. Advantages of the Proposed Approach............................ 12
8. Security Considerations........................................ 13
9. IANA Considerations............................................ 13
10. Notice Regarding Intellectual Property Rights................. 13
11. Normative References.......................................... 14
12. Informative References........................................ 14
13. Contributors.................................................. 15
14. Acknowledgments............................................... 15
15. Editor's Address.............................................. 15
16. Full Copyright Statement...................................... 16
1. Scope of Applicability......................................... 2
2. Conventions Used in this Document.............................. 3
3. Background and Motivation...................................... 3
4. Overview....................................................... 4
5. Changes to SIP to Support Media Authorization.................. 4
5.1 SIP Header Extension....................................... 5
5.2 SIP Procedures............................................. 5
5.2.1 User Agent Client (UAC)................................ 6
5.2.2 User Agent Server (UAS)................................ 6
5.2.3 Originating Proxy (OP)................................. 7
5.2.4 Destination Proxy (DP)................................. 7
6. Examples....................................................... 8
6.1 Requesting Bandwidth via RSVP Messaging.................... 8
6.1.1 User Agent Client Side................................. 8
6.1.2 User Agent Server Side................................. 10
7. Advantages of the Proposed Approach............................ 12
8. Security Considerations........................................ 13
9. IANA Considerations............................................ 13
10. Notice Regarding Intellectual Property Rights................. 13
11. Normative References.......................................... 14
12. Informative References........................................ 14
13. Contributors.................................................. 15
14. Acknowledgments............................................... 15
15. Editor's Address.............................................. 15
16. Full Copyright Statement...................................... 16
This document defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains. Furthermore, the mechanism is generally incompatible with end-to-end encryption of message bodies that describe media sessions.
本文档定义了一个SIP扩展，可用于将QoS准入控制与呼叫信令集成，并帮助防范拒绝服务攻击。此扩展的使用仅适用于管理域或具有先前约定策略的管理域联盟，其中授权QoS的SIP代理和提供QoS的基础网络的策略控制都属于该管理域或域联盟。此外，该机制通常与描述媒体会话的消息体的端到端加密不兼容。
This is in contrast with general Internet principles, which separate data transport from applications. Thus, the solution described in this document is not applicable to the Internet at large. Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network,
这与将数据传输与应用程序分离的一般互联网原则形成对比。因此，本文档中描述的解决方案不适用于整个互联网。尽管存在这些限制，但仍有足够有用的专门部署满足上述假设，并且可以接受由此产生的限制，以保证该机制的信息发布。一个示例部署是一个封闭的网络，
which emulates a traditional circuit switched telephone network. This document specifies a private header, facilitating use in these specialized configurations.
它模拟了传统的电路交换电话网络。本文档指定了一个专用头，便于在这些专用配置中使用。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
Current IP telephony systems assume a perfect world in which there is either an unlimited amount of bandwidth, or network layer Quality of Service (QoS) is provided without any kind of policy control. However, the reality is that end-to-end bandwidth is not unlimited and uncontrolled access to QoS, in general, is unlikely. The primary reason for this is that QoS provides preferential treatment of one flow, at the expense of another. Consequently, it is important to have policy control over whether a given flow should have access to QoS. This will not only enable fairness in general, but can also prevent denial of service attacks.
当前的IP电话系统假设一个完美的世界，在这个世界中，要么有无限的带宽，要么提供网络层服务质量（QoS），而无需任何策略控制。然而，现实情况是，端到端带宽不是无限的，一般来说，不可能不受控制地访问QoS。其主要原因是QoS提供了一个流的优先处理，而牺牲了另一个流。因此，对给定流是否应该访问QoS进行策略控制是很重要的。这不仅可以实现一般的公平性，还可以防止拒绝服务攻击。
In this document, we are concerned with providing QoS for media streams established via the Session Initiation Protocol (SIP) [3]. We assume an architecture that integrates call signaling with media authorization, as illustrated in the Figure below. The solid lines (A and B) show interfaces, whereas the dotted line (C) illustrates the QoS enabled media flow:
在本文档中，我们关注的是为通过会话发起协议（SIP）[3]建立的媒体流提供QoS。我们假设一个架构将呼叫信令与媒体授权集成在一起，如下图所示。实线（A和B）表示接口，而虚线（C）表示支持QoS的媒体流：
+---------+
| Proxy |
+--------->| |
| +---------+
| ^
A)| B) |
| { }
| |
| v
v +------+
+------+ C) | Edge |
| UA |........|router|......
+------+ +------+
+---------+
| Proxy |
+--------->| |
| +---------+
| ^
A)| B) |
| { }
| |
| v
v +------+
+------+ C) | Edge |
| UA |........|router|......
+------+ +------+
Figure 1 - Basic Architecture
图1-基本架构
In this architecture, we assume a SIP UA connected to a QoS enabled network with an edge router acting as a Policy Enforcement Point (PEP) [6]. We further assume that a SIP UA that wishes to obtain QoS initiates sessions through a proxy which can interface with the QoS policy control for the data network being used. We will refer to such a proxy as a QoS enabled proxy. We assume that the SIP UA needs to present an authorization token to the network in order to obtain Quality of Service (C). The SIP UA obtains this authorization token via SIP (A) from the QoS enabled proxy by means of an extension SIP header, defined in this document. The proxy, in turn, communicates either directly with the edge router or with a Policy Decision Point (PDP - not shown) [6] in order to obtain a suitable authorization token for the UA.
在此架构中，我们假设SIP UA连接到支持QoS的网络，边缘路由器充当策略实施点（PEP）[6]。我们进一步假设希望获得QoS的SIP UA通过代理发起会话，该代理可以与所使用的数据网络的QoS策略控制接口。我们将这种代理称为支持QoS的代理。我们假设SIP-UA需要向网络提供授权令牌以获得服务质量（C）。SIP UA通过本文档中定义的扩展SIP头，通过SIP（A）从启用QoS的代理获取该授权令牌。反过来，代理直接与边缘路由器或与策略决策点（PDP-未显示）[6]通信，以便为UA获得合适的授权令牌。
Examples of access data networks, where such a QoS enabled proxy could be used, include DOCSIS based cable networks and 3rd generation (3G) wireless networks.
接入数据网络的示例包括基于DOCSIS的有线网络和第三代（3G）无线网络，其中可以使用这种支持QoS的代理。
A session that needs to obtain QoS for the media streams in accordance with our basic architecture described above goes through the following steps.
根据上述基本架构，需要为媒体流获得QoS的会话将经历以下步骤。
The SIP UA sends an INVITE to the QoS enabled proxy, which for each resulting dialog includes one or more media authorization tokens in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the dialog. When the UA requests QoS, it includes the media authorization tokens with the resource reservation.
SIP UA向启用QoS的代理发送INVITE，对于每个生成的对话框，该代理在所有不可靠临时响应（100除外）中包括一个或多个媒体授权令牌，第一个可靠1x或2xx响应，以及该对话框的该可靠响应的所有重传。当UA请求QoS时，它包括媒体授权令牌和资源预留。
A SIP UA may also receive an INVITE from its QoS enabled proxy which includes one or more media authorization tokens. In that case, when the UA requests QoS, it includes the media authorization tokens with the resource reservation. The resource reservation mechanism is not part of SIP and is not described within the scope of this document.
SIP UA还可以从其支持QoS的代理接收邀请，该代理包括一个或多个媒体授权令牌。在这种情况下，当UA请求QoS时，它包括具有资源保留的媒体授权令牌。资源保留机制不是SIP的一部分，也不在本文档的范围内描述。
This document defines a private SIP header extension to support a media authorization scheme. In this architecture, a QoS enabled SIP proxy supplies the UA with one or more authorization tokens which are to be used in QoS requests. The extension defined allows network QoS resources to be authorized by the QoS enabled SIP proxy.
本文档定义了一个专用SIP头扩展，以支持媒体授权方案。在该体系结构中，支持QoS的SIP代理向UA提供一个或多个授权令牌，用于QoS请求。定义的扩展允许启用QoS的SIP代理授权网络QoS资源。
A new P-Media-Authorization general header field is defined. The P-Media-Authorization header field contains one or more media authorization tokens which are to be included in subsequent resource reservations for the media flows associated with the session, that is, passed to an independent resource reservation mechanism, which is not specified here. The media authorization tokens are used for authorizing QoS for the media stream(s). The P-Media-Authorization header field is described by the following ABNF [4]:
定义了一个新的P-Media-Authorization通用头字段。P-Media-Authorization标头字段包含一个或多个媒体授权令牌，这些令牌将包含在与会话相关联的媒体流的后续资源保留中，即传递给独立的资源保留机制，此处未指定。媒体授权令牌用于授权媒体流的QoS。P-Media-Authorization标头字段由以下ABNF[4]描述：
P-Media-Authorization = "P-Media-Authorization" HCOLON P-Media-Authorization-Token *(COMMA P-Media-Authorization-Token)
P-Media-Authorization=“P-Media-Authorization”HCOLON P-Media-Authorization-Token*（逗号P-Media-Authorization-Token）
P-Media-Authorization-Token = 1*HEXDIG
P-Media-Authorization-Token = 1*HEXDIG
Table 1 below is an extension of tables 2 and 3 in [3] for the new header field defined here. For informational purposes, this table also includes relevant entries for standards track extension methods published at the time this document was published. The INFO, PRACK, UPDATE, and SUBSCRIBE and NOTIFY methods are defined respectively in [11], [9], [12], and [10].
下面的表1是[3]中表2和表3对此处定义的新标题字段的扩展。出于参考目的，此表还包括发布本文档时发布的标准轨迹扩展方法的相关条目。INFO、PRACK、UPDATE以及SUBSCRIBE和NOTIFY方法分别在[11]、[9]、[12]和[10]中定义。
Where proxy ACK BYE CAN INV OPT REG
P-Media-Authorization R ad o - - o - -
P-Media-Authorization 2xx ad - - - o - -
P-Media-Authorization 101-199 ad - - - o - -
Where proxy ACK BYE CAN INV OPT REG
P-Media-Authorization R ad o - - o - -
P-Media-Authorization 2xx ad - - - o - -
P-Media-Authorization 101-199 ad - - - o - -
Where proxy INF PRA UPD SUB NOT
P-Media-Authorization R ad - o o - -
P-Media-Authorization 2xx ad - o o - -
Where proxy INF PRA UPD SUB NOT
P-Media-Authorization R ad - o o - -
P-Media-Authorization 2xx ad - o o - -
Table 1: Summary of header fields.
表1：标题字段摘要。
The P-Media-Authorization header field can be used only in SIP requests or responses that can carry a SIP offer or answer. This naturally keeps the scope of this header field narrow.
P-Media-Authorization标头字段只能用于可携带SIP提供或应答的SIP请求或响应。这自然会使标题字段的范围保持狭窄。
This section defines SIP [3] procedures for usage in media authorization compatible systems, from the point of view of the authorizing QoS.
本节从授权QoS的角度定义了在媒体授权兼容系统中使用的SIP[3]过程。
The initial SIP INVITE message, mid-call messages that result in network QoS resource changes, and mid-call changes in call destination should be authorized. These SIP messages are sent through the QoS enabled proxies to receive this authorization. In order to authorize QoS, the QoS enabled SIP proxy MAY need to inspect message bodies that describe the media streams (e.g., SDP). Hence, it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that such message bodies not be encrypted end-to-end.
应授权初始SIP INVITE消息、导致网络QoS资源更改的呼叫中消息以及呼叫目的地中的呼叫中更改。这些SIP消息通过支持QoS的代理发送以接收此授权。为了授权QoS，启用QoS的SIP代理可能需要检查描述媒体流（例如SDP）的消息体。因此，建议（在本文件第1节的适用范围内可能合适的情况下）不要对此类消息体进行端到端加密。
The P-Media-Authorization-Token, which is contained in the P-Media-Authorization header, is included for each dialog in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the dialog sent by the QoS enabled SIP proxy to the UAC.
P-Media-Authorization-Token包含在P-Media-Authorization报头中，用于所有不可靠的临时响应（100除外）、第一个可靠的1xx或2xx响应以及启用QoS的SIP代理发送到UAC的对话框的该可靠响应的所有重传。
The UAC should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorization header when requesting QoS for the associated media stream(s). This applies to both initial and subsequent refresh reservation messages (for example, in an RSVP-based reservation system). A reservation function within the UAC should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token). These Policy-Elements would typically contain the authorizing entity and credentials, and be used in an RSVP request for media data stream QoS resources.
UAC在请求相关媒体流的QoS时，应使用包含P-Media-Authorization标头的最新请求/响应中的所有P-Media-Authorization-Token。这适用于初始和后续刷新保留消息（例如，在基于RSVP的保留系统中）。UAC内的保留功能应将每个十六进制数字字符串转换为二进制，并将每个结果用作RFC 2750[5]中定义的策略元素（不包括长度，但包括每个令牌中包含的P-Type）。这些策略元素通常包含授权实体和凭证，并在媒体数据流QoS资源的RSVP请求中使用。
The User Agent Server receives the P-Media-Authorization-Token in an INVITE (or other) message from the QoS enabled SIP proxy. If the response contains a message body that describes media streams for which the UA desires QoS, it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that this message body not be encrypted end-to-end.
用户代理服务器从启用QoS的SIP代理接收INVITE（或其他）消息中的P-Media-Authorization-Token。如果响应包含描述UA期望QoS的媒体流的消息体，则建议（在本文件第1节的适用范围内可能是适当的）不对该消息体进行端到端加密。
The UAS should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorization header when requesting QoS for the associated media stream(s). This applies both to initial and subsequent refresh reservation messages (for example, in an RSVP-based reservation system). A reservation function within the UAS should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token). These Policy-Elements would typically
UAS在请求相关媒体流的QoS时，应使用包含P-Media-Authorization标头的最新请求/响应中的所有P-Media-Authorization-Token。这适用于初始和后续刷新保留消息（例如，在基于RSVP的保留系统中）。UAS内的保留功能应将每个十六进制数字字符串转换为二进制，并将每个结果用作RFC 2750[5]中定义的策略元素（不包括长度，但包括每个令牌中包含的P-Type）。这些政策要素通常是
contain the authorizing entity and credentials, and be used in an RSVP request for media data stream QoS resources.
包含授权实体和凭据，并在媒体数据流QoS资源的RSVP请求中使用。
When the originating QoS enabled proxy (OP) receives an INVITE (or other) message from the UAC, the proxy authenticates the caller, and verifies that the caller is authorized to receive QoS.
当发起的支持QoS的代理（OP）从UAC接收到INVITE（或其他）消息时，代理会对呼叫者进行身份验证，并验证呼叫者是否有权接收QoS。
In cooperation with an originating Policy Decision Point (PDP-o), the OP obtains and/or generates one or more media authorization tokens. These contain sufficient information for the UAC to get the authorized QoS for the media streams. Each media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy's resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests and responses in order to decide what QoS to authorize.
与发起策略决策点（PDP-o）合作，OP获得和/或生成一个或多个媒体授权令牌。这些包含足够的信息，UAC可以获得媒体流的授权QoS。按照RFC 2750[5]中的定义，将每个媒体授权令牌格式化为策略元素（不包括长度，但包括每个令牌中包含的P-Type），然后将其转换为十六进制数字字符串以形成P-media-authorization-token。代理的资源管理功能可以在请求和响应中检查描述媒体流（例如，SDP）的消息体，以决定授权什么QoS。
For each dialog that results from the INVITE (or other) message received from the UAC, the originating proxy must add a P-Media-Authorization header with the P-Media-Authorization-Token in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response the proxy sends to the UAC, if that response may result in network QoS changes. A response with an SDP may result in such changes.
对于从UAC接收到的INVITE（或其他）消息产生的每个对话框，发起代理必须在所有不可靠的临时响应（100除外）中添加带有P-Media-Authorization-Token的P-Media-Authorization标头，第一个可靠的1xx或2xx响应，以及代理向UAC发送的可靠响应的所有重传，如果该响应可能导致网络QoS变化。带有SDP的响应可能会导致此类更改。
The Destination QoS Enabled Proxy (DP) verifies that the called party is authorized to receive QoS.
目标QoS启用代理（DP）验证被叫方是否有权接收QoS。
In cooperation with a terminating Policy Decision Point (PDP-t), the DP obtains and/or generates a media authorization token that contains sufficient information for the UAS to get the authorized QoS for the media streams. The media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy's resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests and responses in order to decide what QoS to authorize.
与终止策略决策点（PDP-t）合作，DP获得和/或生成媒体授权令牌，该令牌包含足够的信息，供UAS获得媒体流的授权QoS。按照RFC 2750[5]中的定义，将媒体授权令牌格式化为策略元素（不包括长度，但包括每个令牌中包含的P-Type），然后将其转换为十六进制数字字符串，以形成P-media-authorization-token。代理的资源管理功能可以在请求和响应中检查描述媒体流（例如，SDP）的消息体，以决定授权什么QoS。
The Destination Proxy must add the P-Media-Authorization header with the P-Media-Authorization-Token in the INVITE (or other) request that it sends to the UAS if that message may result in network QoS changes. A message with an SDP body may result in such changes.
目标代理必须在向UAS发送的邀请（或其他）请求中添加带有P-Media-Authorization-Token的P-Media-Authorization标头（如果该消息可能导致网络QoS更改）。带有SDP正文的消息可能会导致此类更改。
Below we provide an example of how the P-Media-Authorization header field can be used in conjunction with the Resource Reservation Protocol (RSVP) [7]. The example assumes that an offer arrives in the initial INVITE and an answer arrives in a reliable provisional response [9], which contains an SDP description of the media flow.
下面我们提供了一个示例，说明如何将P-Media-Authorization头字段与资源预留协议（RSVP）[7]结合使用。该示例假设要约在初始邀请中到达，回答在可靠的临时响应中到达[9]，其中包含媒体流的SDP描述。
Figure 2 presents a high-level overview of a basic call flow with media authorization from the viewpoint of the UAC. Some policy interactions have been omitted for brevity.
图2从UAC的角度给出了具有媒体授权的基本呼叫流的高级概述。为了简洁起见，省略了一些政策互动。
When a user goes off-hook and dials a telephone number, the UAC collects the dialed digits and sends the initial (1)INVITE message to the originating SIP proxy.
当用户挂断电话并拨打电话号码时，UAC将收集所拨打的数字并向发起SIP代理发送初始（1）INVITE消息。
The originating SIP proxy (OP) authenticates the user/UAC and forwards the (2)INVITE message to the proper SIP proxy.
发起SIP代理（OP）对用户/UAC进行身份验证，并将（2）INVITE消息转发给适当的SIP代理。
Assuming the call is not forwarded, the terminating end-point sends a (3)18x response to the initial INVITE via OP. Included in this response is an indication of the negotiated bandwidth requirement for the connection (in the form of an SDP description [8]).
假设呼叫未被转发，终止端点通过OP向初始INVITE发送（3）18x响应。该响应中包括连接协商带宽要求的指示（以SDP描述[8]的形式）。
When OP receives the (3)18x, it has sufficient information regarding the end-points, bandwidth and characteristics of the media exchange. It initiates a Policy-Setup message to PDP-o, (4)AuthProfile.
当OP接收到（3）18x时，它具有关于媒体交换的端点、带宽和特性的足够信息。它向PDP-o（4）AuthProfile发起策略设置消息。
The PDP-o stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to the OP, (5)AuthToken.
PDP-o将授权媒体描述存储在其本地存储中，生成指向该描述的授权令牌，并将授权令牌返回给OP，（5）AuthToken。
UAC ER-o PDP-o OP
|(1)INVITE | | | Client Authentication
|------------------------------------------->| and Call Authoriz.
| | | | (2)INVITE
| | | |-------------->
| | | | (3)18x
| | |(4)AuthProfile |<--------------
| | |<--------------|
| | |(5)AuthToken |
| | |-------------->| Auth. Token put into
| | | (6)18x | P-Media-Authorization
|<-------------------------------------------| header extension.
|---(7)PRACK-------------------------------->|
| |--(8)PRACK---->
| |<-(9)200 (PRACK)
|<--(10)200 (PRACK)--------------------------|
| | | |
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(11)RSVP-PATH | |
|----------->| (12)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (13)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(14)RSVP-PATH
| |------------------------------------------------>
| | | |(15)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(16)RSVP-RESV | |
|----------->| (17)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (18)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(19)RSVP-RESV
| |--------------------------------------------------->
| | | |(20)RSVP-RESV
|<----------------------------------------------------------------
| | | |
UAC ER-o PDP-o OP
|(1)INVITE | | | Client Authentication
|------------------------------------------->| and Call Authoriz.
| | | | (2)INVITE
| | | |-------------->
| | | | (3)18x
| | |(4)AuthProfile |<--------------
| | |<--------------|
| | |(5)AuthToken |
| | |-------------->| Auth. Token put into
| | | (6)18x | P-Media-Authorization
|<-------------------------------------------| header extension.
|---(7)PRACK-------------------------------->|
| |--(8)PRACK---->
| |<-(9)200 (PRACK)
|<--(10)200 (PRACK)--------------------------|
| | | |
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(11)RSVP-PATH | |
|----------->| (12)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (13)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(14)RSVP-PATH
| |------------------------------------------------>
| | | |(15)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(16)RSVP-RESV | |
|----------->| (17)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (18)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(19)RSVP-RESV
| |--------------------------------------------------->
| | | |(20)RSVP-RESV
|<----------------------------------------------------------------
| | | |
Figure 2 - Media Authorization with RSVP (UAC)
图2-使用RSVP（UAC）的媒体授权
The OP includes the authorization token in the P-Media-Authorization header extension of the (6)18x message.
OP在（6）18x消息的P-Media-authorization报头扩展中包括授权令牌。
Upon receipt of the (6)18x message, the UAC stores the media authorization token from the P-Media-Authorization header. Also, the UAC acknowledges the 18x message by sending a (7)PRACK message, which is responded to with (10) 200.
收到（6）18x消息后，UAC存储来自P-media-authorization标头的媒体授权令牌。此外，UAC通过发送（7）条PRACK消息来确认18x消息，该消息以（10）200响应。
Before sending any media, the UAC requests QoS by sending an (11)RSVP-PATH message, which includes the previously stored P-Media-Authorization-Token as a Policy-Element.
在发送任何媒体之前，UAC通过发送（11）RSVP-PATH消息来请求QoS，该消息包括先前存储的P-media-Authorization-Token作为策略元素。
ER-o, upon receipt of the (11)RSVP-PATH message, checks the authorization through a PDP-o COPS message exchange, (12)REQ. PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install" Decision, (13)DEC.
ER-o在收到（11）RSVP-PATH消息后，通过PDP-o COPS消息交换（12）REQ检查授权。PDP-o使用存储的授权媒体描述检查授权，该描述链接到其返回给OP的授权令牌。如果授权成功，PDP-o将返回“安装”决定，（13）DEC。
ER-o checks the admissibility for the request, and if admission succeeds, it forwards the (14)RSVP-PATH message.
ER-o检查请求的可接纳性，如果接纳成功，它将转发（14）条RSVP-PATH消息。
Once UAC receives the (15)RSVP-PATH message from UAS, it sends the (16)RSVP-RESV message to reserve the network resources.
一旦UAC从UAS接收到（15）条RSVP-PATH消息，它将发送（16）条RSVP-RESV消息以保留网络资源。
ER-o, upon receiving the (16)RSVP-RESV message checks the authorization through a PDP-o COPS message exchange, (17)REQ. PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install" Decision, (18)DEC.
ER-o收到（16）RSVP-RESV消息后，通过PDP-o COPS消息交换（17）REQ检查授权。PDP-o使用存储的授权媒体描述检查授权，该描述链接到其返回给OP的授权令牌。如果授权成功，PDP-o将返回“安装”决定，（18）DEC。
ER-o checks the admissibility for the request, and if admission succeeds, it forwards the (19)RSVP-RESV message.
ER-o检查请求的可接受性，如果允许成功，则转发（19）条RSVP-RESV消息。
Upon receiving the (20)RSVP-RESV message, network resources have been reserved in both directions.
收到（20）RSVP-RESV消息后，网络资源已在两个方向上保留。
Figure 3 presents a high-level overview of a call flow with media authorization from the viewpoint of the UAS. Some policy interactions have been omitted for brevity.
图3从UAS的角度给出了具有媒体授权的呼叫流的高级概述。为了简洁起见，省略了一些政策互动。
Since the destination SIP proxy (DP) has sufficient information regarding the endpoints, bandwidth, and characteristics of the media exchange, it initiates a Policy-Setup message to the terminating Policy Decision Point (PDP-t) on receipt of the (1)INVITE.
由于目标SIP代理（DP）具有关于端点、带宽和媒体交换特性的足够信息，因此它在接收到（1）INVITE时向终止策略决策点（PDP-t）发起策略设置消息。
UAS ER-t PDP-t DP
| | | | (1)INVITE
| | | |<--------------
| | | | Proxy Authentication
| | | (2)AuthProfile| and Call Authoriz.
| | |<--------------|
| | | (3)AuthToken |
| | |-------------->| Auth. Token put into
| | | (4)INVITE | P-Media-Authorization
|<------------------------------------------| header extension
| (5)18x | | |
|------------------------------------------>| (6)18x
|Copies the RSVP policy object |-------------->
|from the P-Media-Authorization |
|(7)RSVP-PATH | |
|---------->| (8)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (9)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(10)RSVP-PATH
| |-------------------------------------------------->
| | | |(11)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
| (12)RSVP-RESV | |
|---------->| | |
| | (13)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (14)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(15)RSVP-RESV
| |--------------------------------------------------->
| | | |(16)RSVP-RESV
|<---------------------------------------------------------------
| | | |<-(17)PRACK---------
|<--(18)PRACK ------------------------------|
|---(19)200 (PRACK) ----------------------->|
| | | |--(20)200 (PRACK)-->
| | | |
UAS ER-t PDP-t DP
| | | | (1)INVITE
| | | |<--------------
| | | | Proxy Authentication
| | | (2)AuthProfile| and Call Authoriz.
| | |<--------------|
| | | (3)AuthToken |
| | |-------------->| Auth. Token put into
| | | (4)INVITE | P-Media-Authorization
|<------------------------------------------| header extension
| (5)18x | | |
|------------------------------------------>| (6)18x
|Copies the RSVP policy object |-------------->
|from the P-Media-Authorization |
|(7)RSVP-PATH | |
|---------->| (8)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (9)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(10)RSVP-PATH
| |-------------------------------------------------->
| | | |(11)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
| (12)RSVP-RESV | |
|---------->| | |
| | (13)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (14)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(15)RSVP-RESV
| |--------------------------------------------------->
| | | |(16)RSVP-RESV
|<---------------------------------------------------------------
| | | |<-(17)PRACK---------
|<--(18)PRACK ------------------------------|
|---(19)200 (PRACK) ----------------------->|
| | | |--(20)200 (PRACK)-->
| | | |
Figure 3 - Media Authorization with RSVP (UAS)
图3-使用RSVP（UAS）的媒体授权
PDP-t stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to DP. The token is placed in the (4)INVITE message and forwarded to the UAS.
PDP-t将授权媒体描述存储在其本地存储中，生成指向该描述的授权令牌，并将授权令牌返回给DP。令牌放置在（4）INVITE消息中，并转发到UAS。
Assuming that the call is not forwarded, the UAS sends a (5)18x response to the initial INVITE message, which is forwarded back to UAC. At the same time, the UAS sends a (7)RSVP-PATH message which includes the previously stored P-Media-Authorization-Token as a Policy-Element.
假设呼叫未被转发，UAS向初始INVITE消息发送（5）18x响应，该消息被转发回UAC。同时，UAS发送一（7）条RSVP-PATH消息，其中包括先前存储的P-Media-Authorization-Token作为策略元素。
ER-t, upon receiving the (7)RSVP-PATH message checks the authorization through a PDP-t COPS message exchange. PDP-t checks the authorization using the stored authorized media description that was linked to the authorization token it returned to DP. If authorization is successful, PDP-t returns an "install" Decision, (9)DEC.
ER-t收到（7）条RSVP-PATH消息后，通过PDP-t COPS消息交换检查授权。PDP-t使用存储的授权媒体描述检查授权，该描述链接到它返回给DP的授权令牌。如果授权成功，PDP-t将返回“安装”决定（12月9日）。
ER-t checks the admissibility for the request, and if admission succeeds, it forwards the (10)RSVP-PATH message.
ER-t检查请求的可接纳性，如果接纳成功，则转发（10）条RSVP-PATH消息。
Once the UAS receives the (11)RSVP-PATH message, it sends the (12)RSVP-RESV message to reserve the network resources.
一旦UAS收到（11）RSVP-PATH消息，它将发送（12）RSVP-RESV消息以保留网络资源。
ER-t, upon reception of the (12)RSVP-RESV message, checks the authorization through a PDP-t COPS message exchange. PDP-t checks the authorization using the stored authorized media description that was linked to the authorization token that it returned to DP. If authorization is successful, PDP-t returns an "install" Decision, (14)DEC.
ER-t在收到（12）条RSVP-RESV消息后，通过PDP-t COPS消息交换检查授权。PDP-t使用存储的授权媒体描述检查授权，该描述链接到其返回给DP的授权令牌。如果授权成功，PDP-t将返回“安装”决定（12月14日）。
ER-t checks the admissibility for the request and if admission succeeds, it forwards the (15)RSVP-RESV message.
ER-t检查请求的可接纳性，如果接纳成功，则转发（15）条RSVP-RESV消息。
Upon receiving the (16)RSVP-RESV message, network resources have been reserved in both directions.
收到（16）RSVP-RESV消息后，网络资源已在两个方向上保留。
For completeness, we show the (17)PRACK message for the (5) 18x response and the resulting (19) 200 response acknowledging the PRACK.
为完整起见，我们显示了（5）18x响应的（17）PRACK消息以及确认PRACK的（19）200响应。
The use of media authorization makes it possible to control the usage of network resources. In turn, this makes IP Telephony more robust against denial of service attacks and various kinds of service frauds. By using the authorization capability, the number of flows, and the amount of network resources reserved can be controlled, thereby making the IP Telephony system dependable in the presence of scarce resources.
使用媒体授权可以控制网络资源的使用。反过来，这使IP电话更能抵御拒绝服务攻击和各种服务欺诈。通过使用授权能力，可以控制流的数量和保留的网络资源量，从而使IP电话系统在资源稀缺的情况下可靠。
In order to control access to QoS, a QoS enabled proxy should authenticate the UA before providing it with a media authorization token. Both the method and policy associated with such authentication are outside the scope of this document, however it could, for example, be done by using standard SIP authentication mechanisms, as described in [3].
为了控制对QoS的访问，启用QoS的代理应该在向UA提供媒体授权令牌之前对其进行身份验证。与此类认证相关联的方法和策略都不在本文档的范围内，但是，例如，可以通过使用标准SIP认证机制来实现，如[3]中所述。
Media authorization tokens sent in the P-Media-Authorization header from a QoS enabled proxy to a UA MUST be protected from eavesdropping and tampering. This can, for example, be done through a mechanism such as IPSec or TLS. However, this will only provide hop-by-hop security. If there is one or more intermediaries (e.g., proxies), between the UA and the QoS enabled proxy, these intermediaries will have access to the P-Media-Authorization header field value, thereby compromising confidentiality and integrity. This will enable both theft-of-service and denial-of-service attacks against the UA. Consequently, the P-Media-Authorization header field MUST NOT be available to any untrusted intermediary in the clear or without integrity protection. There is currently no mechanism defined in SIP that would satisfy these requirements. Until such a mechanism exists, proxies MUST NOT send P-Media-Authorization headers through untrusted intermediaries, which might reveal or modify the contents of this header. (Note that S/MIME-based encryption in SIP is not available to proxy servers, as proxies are not allowed to add message bodies.)
必须保护P-Media-authorization标头中从启用QoS的代理发送到UA的媒体授权令牌免受窃听和篡改。例如，这可以通过IPSec或TLS等机制实现。但是，这将只提供逐跳安全性。如果UA和启用QoS的代理之间存在一个或多个中介（例如，代理），则这些中介将有权访问P-Media-Authorization头字段值，从而损害机密性和完整性。这将启用对UA的窃取服务和拒绝服务攻击。因此，P-Media-Authorization标头字段不得用于clear或without integrity protection中的任何不受信任的中介。目前，SIP中没有定义能够满足这些要求的机制。在这种机制存在之前，代理不得通过不受信任的中介发送P-Media-Authorization标头，这可能会泄露或修改此标头的内容。（请注意，SIP中基于S/MIME的加密对代理服务器不可用，因为不允许代理添加消息体。）
QoS enabled proxies may need to inspect message bodies describing media streams (e.g., SDP). Consequently, such message bodies should not be encrypted. In turn, this will prevent end-to-end confidentiality of the said message bodies, which lowers the overall security possible.
支持QoS的代理可能需要检查描述媒体流的消息体（例如SDP）。因此，此类消息体不应加密。反过来，这将防止所述消息体的端到端机密性，从而降低整体安全性。
This document defines a new private SIP header for media authorization, "P-Media-Authorization". This header has been registered by the IANA in the SIP header registry, using the RFC number of this document as its reference.
本文档为媒体授权定义了一个新的私有SIP头，“P-media-authorization”。IANA已使用本文档的RFC号作为其参考，在SIP标头注册表中注册了该标头。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] 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.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[5] Herzog，S.，“政策控制的RSVP扩展”，RFC 2750，2000年1月。
[6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[6] Yavatkar，R.，Pendarakis，D.和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[7] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[9] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[10] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[11] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.
[12] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年9月。
The following people contributed significantly and were co-authors on earlier versions of this document:
以下人员做出了重大贡献，是本文件早期版本的共同作者：
Bill Marshall (AT&T), K. K. Ramakrishnan (AT&T), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Juniper Networks), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (Arris), and Keith Kelly (NetSpeak).
比尔·马歇尔（AT&T）、K.K.罗摩克里希南（AT&T）、埃德·米勒（Terayon）、格伦·拉塞尔（CableLabs）、伯卡克·贝瑟（Juniper Networks）、迈克·曼内特（3Com）、库尔特·斯坦布雷纳（3Com）、戴夫·奥兰（Cisco）、弗莱明·安德雷森（Cisco）、约翰·皮肯斯（Com21）、普尼玛·拉尔瓦尼（诺基亚）、乔恩·费罗斯（铜山网络）、埃文斯博士（阿里斯）和基思·凯利（网语）。
The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The contributors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications. Dean Willis and Rohan Mahy provided valuable feedback as well.
PacketCable项目中的分布式呼叫信令工作是代表许多不同公司的大量人员的工作。贡献者要感谢并感谢以下人员的帮助：摩托罗拉的John Wheeler；大卫·博德曼、丹尼尔·保罗、阿里斯互动；比尔·布鲁姆、杰伊·斯特拉特、杰夫·奥利斯、克莱夫·霍尔博罗、摩托罗拉；Doug Newlin，Guido Schuster，Ikhlaq Sidhu，3Com；海湾网络公司Jiri Matousek；法尔齐·哈扎伊，北电；约翰·查普曼、比尔·古克尔、迈克尔·拉马霍、思科；Chuck Kalmanek，Doug Nortz，John Lawser，James Cheng，Tong Hai Xiao，Partho Mishra，AT&T；Telcordia技术公司；和朗讯有线通讯。迪安·威利斯和罗汉·马伊也提供了宝贵的反馈。
Bill Marshall AT&T Florham Park, NJ 07932
新泽西州弗罗勒姆公园比尔·马歇尔AT&T公司，邮编：07932
EMail: wtm@research.att.com
EMail: wtm@research.att.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。