Internet Engineering Task Force (IETF) V. Hilt
Request for Comments: 6794 Bell Labs/Alcatel-Lucent
Category: Standards Track G. Camarillo
ISSN: 2070-1721 Ericsson
J. Rosenberg
jdrosen.net
December 2012
Internet Engineering Task Force (IETF) V. Hilt
Request for Comments: 6794 Bell Labs/Alcatel-Lucent
Category: Standards Track G. Camarillo
ISSN: 2070-1721 Ericsson
J. Rosenberg
jdrosen.net
December 2012
A Framework for Session Initiation Protocol (SIP) Session Policies
会话启动协议（SIP）会话策略框架
Abstract
摘要
Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies.
代理服务器在会话启动协议（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/rfc6794.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6794.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Session-Independent Policies ....................................5
3.1. Architecture and Overview ..................................5
3.2. Policy Subscription ........................................6
3.2.1. User Agent Client (UAC) Behavior ....................6
3.2.2. User Agent Server (UAS) Behavior ....................8
4. Session-Specific Policies .......................................8
4.1. Architecture ...............................................8
4.2. Overview ...................................................9
4.3. Examples ..................................................11
4.3.1. Offer in Request ...................................11
4.3.2. Offer in Response ..................................13
4.4. UA/Policy Server Rendezvous ...............................15
4.4.1. UAC Behavior .......................................15
4.4.2. Proxy Behavior .....................................17
4.4.3. UAS Behavior .......................................20
4.4.4. Caching the Local Policy Server URI ................21
4.4.5. Header Field Definition and Syntax .................22
4.5. Policy Channel ............................................23
4.5.1. Creation and Management ............................24
4.5.2. Contacting the Policy Server .......................25
4.5.3. Using Session Policies .............................26
5. Security Considerations ........................................27
6. IANA Considerations ............................................29
6.1. Registration of the "Policy-ID" Header Field ..............29
6.2. Registration of the "Policy-Contact" Header Field .........29
6.3. Registration of the "non-cacheable" Policy-Contact
Header Field Parameter ....................................29
6.4. Registration of the "policy" SIP Option Tag ...............29
7. References .....................................................30
7.1. Normative References ......................................30
7.2. Informative References ....................................31
Appendix A. Acknowledgements ......................................32
Appendix B. Session-Specific Policies - Call Flows ................32
B.1. Offer in Invite ...........................................32
B.2. Offer in Response .........................................34
B.3. Multiple Policy Servers for the UAS .......................35
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Session-Independent Policies ....................................5
3.1. Architecture and Overview ..................................5
3.2. Policy Subscription ........................................6
3.2.1. User Agent Client (UAC) Behavior ....................6
3.2.2. User Agent Server (UAS) Behavior ....................8
4. Session-Specific Policies .......................................8
4.1. Architecture ...............................................8
4.2. Overview ...................................................9
4.3. Examples ..................................................11
4.3.1. Offer in Request ...................................11
4.3.2. Offer in Response ..................................13
4.4. UA/Policy Server Rendezvous ...............................15
4.4.1. UAC Behavior .......................................15
4.4.2. Proxy Behavior .....................................17
4.4.3. UAS Behavior .......................................20
4.4.4. Caching the Local Policy Server URI ................21
4.4.5. Header Field Definition and Syntax .................22
4.5. Policy Channel ............................................23
4.5.1. Creation and Management ............................24
4.5.2. Contacting the Policy Server .......................25
4.5.3. Using Session Policies .............................26
5. Security Considerations ........................................27
6. IANA Considerations ............................................29
6.1. Registration of the "Policy-ID" Header Field ..............29
6.2. Registration of the "Policy-Contact" Header Field .........29
6.3. Registration of the "non-cacheable" Policy-Contact
Header Field Parameter ....................................29
6.4. Registration of the "policy" SIP Option Tag ...............29
7. References .....................................................30
7.1. Normative References ......................................30
7.2. Informative References ....................................31
Appendix A. Acknowledgements ......................................32
Appendix B. Session-Specific Policies - Call Flows ................32
B.1. Offer in Invite ...........................................32
B.2. Offer in Response .........................................34
B.3. Multiple Policy Servers for the UAS .......................35
The Session Initiation Protocol (SIP) [RFC3261] is a signaling protocol for creating, modifying and terminating multimedia sessions. A central element in SIP is the proxy server. Proxy servers are intermediaries that are responsible for request routing, rendezvous, authentication and authorization, mobility, and other signaling services. However, proxies are divorced from the actual sessions -- audio, video, and session-mode messaging -- that SIP establishes. Details of the sessions are carried in the payload of SIP messages, and are usually described with the Session Description Protocol (SDP) [RFC4566].
会话发起协议（SIP）[RFC3261]是用于创建、修改和终止多媒体会话的信令协议。SIP中的一个中心元素是代理服务器。代理服务器是负责请求路由、会合、身份验证和授权、移动性和其他信令服务的中介。然而，代理与SIP建立的实际会话（音频、视频和会话模式消息）是分离的。会话的详细信息载于SIP消息的有效负载中，通常使用会话描述协议（SDP）[RFC4566]进行描述。
Experience has shown that there is a need for SIP intermediaries to impact aspects of a session. For example, SIP can be used in a wireless network, which has limited resources for media traffic. During periods of high activity, the wireless network provider could want to restrict the amount of bandwidth available to each user. With session policies, an intermediary in the wireless network can inform the user agent (UA) about the bandwidth it has available. This information enables the user agent to make an informed decision about the number of streams, the media types, and the codecs it can successfully use in a session. Similarly, a network provider can have a service level agreement with a user that defines the set of media types the user can use. With session policies, the network can convey the current set of policies to user agents, enabling them to set up sessions without inadvertently violating any of the network policies.
经验表明，SIP中介需要影响会话的各个方面。例如，SIP可用于无线网络，该无线网络具有有限的媒体流量资源。在高活动期间，无线网络提供商可能希望限制每个用户可用的带宽量。通过会话策略，无线网络中的中介可以向用户代理（UA）通知其可用带宽。此信息使用户代理能够就其可以在会话中成功使用的流的数量、媒体类型和编解码器做出明智的决定。类似地，网络提供商可以与用户签订服务级别协议，定义用户可以使用的媒体类型集。通过会话策略，网络可以将当前策略集传送给用户代理，从而使他们能够在不无意中违反任何网络策略的情况下建立会话。
In another example, a SIP user agent is using a network that is connected to the public Internet through a firewall or a network border device. The network provider would like to tell the user agent that it needs to send its media streams to a specific IP address and port on the firewall or border device to reach the public Internet. Knowing this policy enables the user agent to set up sessions across the firewall or the network border. In contrast to other methods for inserting a media intermediary, the use of session policies does not require the inspection or modification of SIP message bodies.
在另一示例中，SIP用户代理正在使用通过防火墙或网络边界设备连接到公共因特网的网络。网络提供商希望告诉用户代理，它需要将其媒体流发送到防火墙或边界设备上的特定IP地址和端口，以到达公共Internet。了解此策略后，用户代理可以跨防火墙或网络边界设置会话。与插入媒体中介体的其他方法不同，会话策略的使用不需要检查或修改SIP消息体。
Domains often have the need to enforce the session policies they have in place. For example, a domain might have a policy that disallows the use of video and can have an enforcement mechanism that drops all packets containing a video encoding. Unfortunately, these enforcement mechanisms usually do not inform the user about the policies they are enforcing. Instead, they silently keep the user from doing anything against them. This can lead to a malfunctioning of devices that is incomprehensible to the user. With session
域通常需要强制实施它们已经到位的会话策略。例如，域可能具有不允许使用视频的策略，并且可以具有丢弃包含视频编码的所有数据包的强制机制。不幸的是，这些强制执行机制通常不会通知用户他们正在强制执行的策略。相反，它们默默地阻止用户对它们做任何事情。这可能导致用户无法理解的设备故障。会期
policies, the user knows about the current network policies and can set up policy-compliant sessions or simply connect to a domain with less stringent policies. Thus, session policies provide an important combination of consent coupled with enforcement. That is, the user becomes aware of the policy and needs to act on it, but the provider still retains the right to enforce the policy.
策略，用户了解当前的网络策略，可以设置符合策略的会话，也可以简单地连接到具有较不严格策略的域。因此，会话策略提供了同意与执行的重要组合。也就是说，用户意识到该策略并需要对其采取行动，但提供商仍保留强制执行该策略的权利。
Two types of session policies exist: session-specific policies and session-independent policies. Session-specific policies are policies that are created for one particular session, based on the session description of that session. They enable a network intermediary to examine the session description a UA is proposing and to return a policy specifically for that session description. For example, an intermediary could open pinholes in a firewall/NAT for each media stream in the proposed session description. It can then return a policy for the session description that replaces the IP addresses and ports of the UA with the ones opened in the firewall/NAT that are reachable from the exterior. Session-specific policies provide information about a specific session to a domain, which can be used to implement policies for opening pinholes on a firewall/NAT. Since session-specific policies are tailored to a session, they only apply to the session for which they are created. Session-specific policies are created on a session-by-session basis at the time the session is established.
存在两种类型的会话策略：特定于会话的策略和独立于会话的策略。特定于会话的策略是根据某个特定会话的会话描述为该会话创建的策略。它们使网络中介能够检查UA提议的会话描述，并返回专门用于该会话描述的策略。例如，中介可以在提议的会话描述中为每个媒体流在防火墙/NAT中打开针孔。然后，它可以返回会话描述的策略，该策略将UA的IP地址和端口替换为可从外部访问的防火墙/NAT中打开的IP地址和端口。特定于会话的策略提供有关到域的特定会话的信息，可用于实现在防火墙/NAT上打开针孔的策略。由于特定于会话的策略是针对会话定制的，因此它们仅适用于为其创建策略的会话。特定于会话的策略是在会话建立时逐会话创建的。
Session-independent policies, on the other hand, are policies that are created independent of a session and generally apply to all SIP sessions set up by a user agent. A session-independent policy can, for example, be used to inform user agents about an existing bandwidth limit or media type restrictions. Since these policies are not based on a specific session description, they can be created independent of an attempt to set up a session and only need to be conveyed to the user agent when it initializes (e.g., at the time the device is powered on) and when policies are changed.
另一方面，会话无关策略是独立于会话创建的策略，通常适用于由用户代理设置的所有SIP会话。例如，独立于会话的策略可用于通知用户代理现有带宽限制或媒体类型限制。由于这些策略不基于特定的会话描述，因此可以独立于设置会话的尝试来创建它们，并且只需要在用户代理初始化（例如，在设备通电时）和更改策略时将它们传送给用户代理。
This specification defines a framework for SIP session policies. It specifies a model, the overall architecture and new protocol mechanisms that are needed for session-independent and session-specific policies. Since session-specific and session-independent policies have different requirements, this specification defines two different mechanisms to deliver them to user agents. These mechanisms are independent of each other, and, depending on whether one or both types of session policies are needed, it is possible to use the session-specific or the session-independent mechanism or both to deliver policies to user agents.
本规范定义了SIP会话策略的框架。它指定了独立于会话和特定于会话的策略所需的模型、总体架构和新的协议机制。由于特定于会话和独立于会话的策略具有不同的需求，因此本规范定义了两种不同的机制来将它们交付给用户代理。这些机制彼此独立，并且，根据是否需要一种或两种类型的会话策略，可以使用特定于会话的或独立于会话的机制或两者来向用户代理交付策略。
It is RECOMMENDED that UAs and intermediaries use the mechanisms defined in this specification for signaling session policies to endpoints. To ensure backwards compatibility with UAs that do not support this specification, intermediaries may choose to resort to existing mechanisms such as rejecting sessions that are not policy compliant with a 488 response as a fallback solution if a UA does not indicate support for session policies. UAs that do not support session policies will receive the same user experience as they would today. As these techniques are known to have many drawbacks, it is RECOMMENDED that UAs and intermediaries use explicit signaling of policies using the mechanisms defined in this specification.
建议UAs和中介机构使用本规范中定义的机制向端点发送会话策略信号。为确保与不支持此规范的UAs向后兼容，如果UA未表示支持会话策略，中介机构可选择求助于现有机制，例如拒绝与488响应不符合策略的会话，作为回退解决方案。不支持会话策略的UAs将获得与今天相同的用户体验。由于已知这些技术有许多缺点，建议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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Session-independent policies are policies that are created independent of a session and generally apply to all sessions a user agent is setting up. They typically remain stable for a longer period of time and apply to any session set up while they are valid. However, it is possible for session-independent policies to change over time. For example, a policy that defines a bandwidth limit for a user can change during the day, defining a lower limit during peak hours and allow more bandwidth off-peak. The policy server informs a UA when session-independent policies change.
会话无关策略是独立于会话创建的策略，通常适用于用户代理正在设置的所有会话。它们通常在较长时间内保持稳定，并在有效时应用于任何会话设置。但是，独立于会话的策略可能会随着时间的推移而改变。例如，为用户定义带宽限制的策略可以在白天更改，在高峰时间定义较低的限制，并允许在非高峰时间使用更多带宽。当会话无关策略更改时，策略服务器通知UA。
+-------------+
/------| policy |
+----+ / | server 1 |
| |---/ +-------------+
| UA | ...
| |---\ +-------------+
+----+ \ | policy |
\------| server n |
+-------------+
+-------------+
/------| policy |
+----+ / | server 1 |
| |---/ +-------------+
| UA | ...
| |---\ +-------------+
+----+ \ | policy |
\------| server n |
+-------------+
Figure 1
图1
A SIP UA can receive session-independent policies from one or more policy servers. In a typical configuration, a UA receives session-independent policies from a policy server in the local network domain
SIP UA可以从一个或多个策略服务器接收与会话无关的策略。在典型配置中，UA从本地网络域中的策略服务器接收与会话无关的策略
(i.e., the domain from which the UA receives IP service) and possibly the SIP service provider domain (i.e., the domain at which the UA registers). The local network can have policies that support the access network infrastructure. For example, in a wireless network where bandwidth is scarce, a provider can restrict the bandwidth available to an individual user. The SIP service provider can have policies that are needed to support services or policies that reflect the service level agreement with the user. Thus, in most cases, a UA will receive session-independent policies from one or two policy servers.
（即UA从中接收IP服务的域）以及可能的SIP服务提供商域（即UA注册的域）。本地网络可以具有支持接入网络基础设施的策略。例如，在带宽稀缺的无线网络中，提供商可以限制单个用户可用的带宽。SIP服务提供商可以具有支持服务所需的策略或反映与用户的服务级别协议的策略。因此，在大多数情况下，UA将从一个或两个策略服务器接收与会话无关的策略。
Setting up session-independent policies involves the following steps:
设置独立于会话的策略包括以下步骤：
1. A user agent discovers session-independent policy servers in the local network and SIP service provider domain.
1. 用户代理在本地网络和SIP服务提供商域中发现与会话无关的策略服务器。
2. A user agent requests session-independent policies from the discovered policy servers. A user agent typically requests these policies when it starts up or connects to a new network domain.
2. 用户代理从发现的策略服务器请求与会话无关的策略。用户代理通常在启动或连接到新的网络域时请求这些策略。
3. The policy server selects the policies that apply to this user agent. The policy server can have general policies that apply to all users or maintain separate policies for each individual user. The selected policies are returned to the user agent.
3. 策略服务器选择应用于此用户代理的策略。策略服务器可以具有适用于所有用户的常规策略，也可以为每个用户维护单独的策略。所选策略将返回给用户代理。
4. The policy server can update the policies, for example, when network conditions change.
4. 策略服务器可以更新策略，例如，当网络条件发生变化时。
A UA that supports session-independent policies compliant to this specification MUST attempt to retrieve session-independent policies from the local network and the SIP service provider domain, unless the UA knows (e.g., through configuration) that a domain does not provide session-independent policies (in which case the UA SHOULD NOT retrieve session-independent policies from this specific domain).
支持符合本规范的会话无关策略的UA必须尝试从本地网络和SIP服务提供商域检索会话无关策略，除非UA知道（例如，通过配置）域不提供会话无关策略（在这种情况下，UA不应从该特定域检索会话独立策略）。
A UA that supports session-independent policies compliant to this specification MUST support the retrieval of session-independent policies from the local network and the SIP service provider domain using the "ua-profile" event package defined in "A Framework for Session Initiation Protocol User Agent Profile Delivery" [RFC6080]. The UA MAY support other methods of retrieving session-independent policies from the local network and the SIP service provider domains.
支持符合本规范的会话无关策略的UA必须支持使用“会话启动协议用户代理配置文件交付框架”中定义的“UA配置文件”事件包从本地网络和SIP服务提供商域检索会话无关策略[RFC6080]。UA可以支持从本地网络和SIP服务提供商域检索会话独立策略的其他方法。
The "ua-profile" event package [RFC6080] provides a mechanism to subscribe to session-independent policies. A UA subscribes to the policy server in the local network domain using the procedures defined for the "local-network" profile-type. The UA uses the procedures defined for the "user" profile type to subscribe to the policy server in the SIP service provider domain.
“ua概要文件”事件包[RFC6080]提供了一种订阅会话无关策略的机制。UA使用为“本地网络”配置文件类型定义的过程订阅本地网络域中的策略服务器。UA使用为“用户”配置文件类型定义的过程来订阅SIP服务提供商域中的策略服务器。
A UA (re-)subscribes to session-independent policies when the following events occur:
当发生以下事件时，UA（重新）订阅与会话无关的策略：
o The UA registers a new address-of-record (AoR) or removes an AoR from the set of AoRs it has registered. In these cases, the UA MUST establish subscriptions for each new AoR using the "user" and the "local-network" profile-types. The UA MUST terminate all subscriptions for AoRs it has removed.
o UA注册新的记录地址（AoR）或从其注册的AoR集中删除AoR。在这些情况下，UA必须使用“用户”和“本地网络”配置文件类型为每个新AoR建立订阅。UA必须终止其删除的AOR的所有订阅。
o The UA changes the domain to which it is connected. The UA MUST terminate all existing subscriptions for the "local-network" profile-type. The UA MUST then create a new subscription for each AoR it maintains using the "local-network" profile-type. This way, the UA stops receiving policies from the previous local domain and starts to receive the policies of the new local domain. The UA does not need to change the subscriptions for "user" profiles.
o UA更改其连接的域。UA必须终止“本地网络”配置文件类型的所有现有订阅。然后UA必须使用“本地网络”配置文件类型为其维护的每个AoR创建新订阅。这样，UA停止从以前的本地域接收策略，并开始接收新本地域的策略。UA不需要更改“用户”配置文件的订阅。
If a UA is unable to establish a subscription, the UA SHOULD NOT attempt to retry this subscription, unless one of the above events occurs again. This is to limit the number of SUBSCRIBE requests sent within domains that do not support session-independent policies. However, a UA SHOULD retry the subscription with a longer time interval (e.g., once every 24 hours). This enables UAs to detect new policies that are deployed in a network that previously did not have policies.
如果UA无法建立订阅，则UA不应尝试重试此订阅，除非再次发生上述事件之一。这是为了限制在不支持会话独立策略的域内发送的订阅请求数。但是，UA应以更长的时间间隔重试订阅（例如，每24小时重试一次）。这使UAs能够检测部署在以前没有策略的网络中的新策略。
A UA that supports session-independent policies compliant to this specification MUST support the User Agent Profile Data Set for Media Policy [RFC6796]. To indicate that the UA wants to receive session-independent policies, the UA includes the MIME type "application/ media-policy-dataset+xml" in the Accept header field of a SUBSCRIBE request.
支持符合本规范的会话无关策略的UA必须支持媒体策略[RFC6796]的用户代理配置文件数据集。为了指示UA希望接收与会话无关的策略，UA在订阅请求的Accept header字段中包含MIME类型“application/media policy dataset+xml”。
A UA MUST apply the session-independent policies it has received and use these policies in the session descriptions it creates. If the UA decides not to use the received policies, then the UA MUST NOT set up a session unless it changes the domain that provided these policies. A UA MAY try to connect to another local network and/or SIP service provider domain with a different set of policies.
UA必须应用其收到的与会话无关的策略，并在其创建的会话描述中使用这些策略。如果UA决定不使用收到的策略，则UA不得设置会话，除非其更改提供这些策略的域。UA可以尝试使用一组不同的策略连接到另一个本地网络和/或SIP服务提供商域。
If a UA receives both session-independent and session-specific policies, the UA MUST apply the session-independent policies to the session description before the session description is sent to the session-specific policy server (see Section 4). Thus, session-independent policies are always applied before session-specific policies are retrieved.
如果UA同时收到会话独立策略和会话特定策略，则UA必须在会话描述发送到会话特定策略服务器之前，将会话独立策略应用于会话描述（参见第4节）。因此，在检索特定于会话的策略之前，始终应用与会话无关的策略。
A policy server MAY send a notification to the UA every time the session-independent policies covered by the subscription change. The definition of what causes a policy to change is at the discretion of the administrator. A change in the policy can be triggered, for example, by a change in the network status, by the change in the time of day or by an update of the service level agreement with the customer.
每当订阅所涵盖的会话无关策略发生更改时，策略服务器可以向UA发送通知。导致策略更改的原因的定义由管理员自行决定。例如，可以通过网络状态的更改、时间的更改或与客户的服务级别协议的更新来触发策略的更改。
Session-specific policies are policies that are created specifically for one particular session of a UA. Thus, session-specific policies will typically be different for different sessions. The session-specific policies for a session can change during the course of the session. For example, a user can run out of credit during a session, which will cause the network to disallow the transmission all media streams from this point on.
特定于会话的策略是专门为UA的一个特定会话创建的策略。因此，对于不同的会话，特定于会话的策略通常是不同的。会话的特定于会话的策略可以在会话过程中更改。例如，用户在会话期间可能会耗尽信用，这将导致网络从此点开始禁止传输所有媒体流。
domain 1
+-----------+
/------| proxy |----...
+----+ / +-----------+
| |---/ +-----------+
| | | policy |
| UA |============| server |
| | +-----------+
| |**** +-----------+
+----+ * | policy |
*******|enforcement|****...
+-----------+
domain 1
+-----------+
/------| proxy |----...
+----+ / +-----------+
| |---/ +-----------+
| | | policy |
| UA |============| server |
| | +-----------+
| |**** +-----------+
+----+ * | policy |
*******|enforcement|****...
+-----------+
--- SIP Signaling
=== Policy Channel
*** Media
--- SIP Signaling
=== Policy Channel
*** Media
Figure 2
图2
The following entities are needed for session-specific policies (see Figure 2): a user agent (UA), a proxy, a policy server, and possibly a policy enforcement entity.
会话特定策略需要以下实体（见图2）：用户代理（UA）、代理、策略服务器，可能还有策略实施实体。
The role of the proxy is to provide a rendezvous mechanism for UAs and policy servers. It ensures that each UA has the URI [RFC3986] of the policy server in its domain and knows from where to retrieve policies. The proxy conveys the policy server URI to UAs in case they have not yet received it (e.g., in a previous call or through configuration). The proxy does not deliver the actual policies to UAs.
代理的作用是为UAs和策略服务器提供会合机制。它确保每个UA在其域中具有策略服务器的URI[RFC3986]，并知道从何处检索策略。如果UAs尚未收到策略服务器URI（例如，在以前的调用中或通过配置），则代理会将该URI传送给UAs。代理不会将实际策略交付给UAs。
The policy server is a separate logical entity that can be physically co-located with the proxy. The role of the policy server is to deliver session policies to UAs. The policy server receives session information from the UA, uses this information to determine the policies that apply to the session, and returns these policies to the UA. The mechanism for generating policies (i.e., making policy decisions) is outside of the scope of this specification. A policy server can, for example, query an external entity to get policies or it can directly incorporate a policy decision point and generate policies locally.
策略服务器是一个单独的逻辑实体，可以在物理上与代理共存。策略服务器的作用是向UAs传递会话策略。策略服务器从UA接收会话信息，使用此信息确定应用于会话的策略，并将这些策略返回给UA。生成策略（即做出策略决策）的机制不在本规范的范围内。例如，策略服务器可以查询外部实体以获取策略，也可以直接合并策略决策点并在本地生成策略。
A UA receives the URI of a policy server from a proxy. It uses this URI to contact the policy server. It provides information about the current session to the policy server and receives session policies in response. The UA can also receive policy updates from the policy server during the course of a session.
UA从代理接收策略服务器的URI。它使用此URI与策略服务器联系。它向策略服务器提供有关当前会话的信息，并接收会话策略作为响应。UA还可以在会话过程中从策略服务器接收策略更新。
A network can have a policy enforcement infrastructure in place. However, this specification does not make any assumptions about the enforcement of session policies and the mechanisms defined here are orthogonal to a policy enforcement infrastructure.
网络可以有策略实施基础设施。但是，本规范没有对会话策略的实施做出任何假设，此处定义的机制与策略实施基础设施正交。
In principle, each domain that is traversed by SIP signaling messages can define session-specific policies for a session. Each domain needs to run a policy server and a proxy that is able to rendezvous a UA with the policy server (as shown in Figure 2). However, it is expected that session-specific policies will often only be provided by the local domain of the user agent.
原则上，SIP信令消息所穿越的每个域都可以为会话定义特定于会话的策略。每个域都需要运行一个策略服务器和一个能够将UA与策略服务器会合的代理（如图2所示）。但是，预期特定于会话的策略通常仅由用户代理的本地域提供。
The protocol defined in this specification clearly separates SIP signaling and the exchange of policies. SIP signaling is only used to rendezvous the UA with the policy server. From this point on, UA and policy server communicate directly with each other over a separate policy channel. This is opposed to a piggyback model, where
本规范中定义的协议明确区分了SIP信令和策略交换。SIP信令仅用于使UA与策略服务器会合。从这一点开始，UA和策略服务器通过单独的策略通道直接相互通信。这与背驮模型相反，背驮模型
the exchange of policy information between endpoint and a policy server in the network is piggybacked onto the SIP signaling messages that are exchanged between endpoints.
端点和网络中的策略服务器之间的策略信息交换是通过端点之间交换的SIP信令消息进行的。
The main advantage of using a separate policy channel is that it decouples signaling between endpoints from the policy exchange between an endpoint and a policy server. This decoupling has a number of desirable properties. It enables the use of separate encryption mechanisms on the signaling path, to secure the communication between endpoints, and on the policy channel, to secure the communication between endpoint and policy server. Policies can be submitted directly from the policy server to the endpoint. They do not travel along the signaling path, which can potentially cross many domains. Endpoints set up a separate policy channel to each policy server and can disclose the information requested by the specific policy server (e.g., offer or offer/answer). Finally, policy servers do not need to rely on a SIP signaling message flowing by to send policies or policy updates to an endpoint. A policy server can use the policy channel at any time to update session policies as needed. A disadvantage of the separate channel model is that it requires additional messages for the exchange of policy information.
使用单独策略通道的主要优点是，它将端点之间的信令与端点和策略服务器之间的策略交换分离。这种解耦具有许多可取的特性。它允许在信令路径上使用单独的加密机制来保护端点之间的通信，并在策略通道上使用单独的加密机制来保护端点和策略服务器之间的通信。策略可以直接从策略服务器提交到端点。它们不会沿着信令路径移动，这可能会跨越许多域。端点为每个策略服务器设置单独的策略通道，并可以公开特定策略服务器请求的信息（例如，提供或提供/应答）。最后，策略服务器不需要依赖流经的SIP信令消息向端点发送策略或策略更新。策略服务器可以随时使用策略通道根据需要更新会话策略。独立通道模型的一个缺点是，它需要额外的消息来交换策略信息。
Following this model, signaling for session-specific policies involves the following two fundamental tasks:
按照此模型，特定于会话的策略的信令涉及以下两个基本任务：
1. UA/policy server rendezvous: a UA setting up a session needs to be able to discover the policy servers that are relevant to this session.
1. UA/策略服务器会合：设置会话的UA需要能够发现与此会话相关的策略服务器。
2. Policy channel: once the UA has discovered the relevant policy servers for a session, it needs to connect to these servers, disclose session information, and retrieve the policies that apply to this session.
2. 策略通道：一旦UA发现会话的相关策略服务器，它需要连接到这些服务器，公开会话信息，并检索应用于该会话的策略。
The communication between UA and policy server on the policy channel involves the following steps:
UA和策略通道上的策略服务器之间的通信包括以下步骤：
1. A user agent submits information about the session it is trying to establish to the policy server and asks whether a session using these parameters is permissible.
1. 用户代理向策略服务器提交有关其试图建立的会话的信息，并询问是否允许使用这些参数的会话。
2. The policy server generates a policy decision for this session and returns the decision to the user agent. Possible policy decisions are (1) to deny the session, (2) to propose changes to the session parameters with which the session would be acceptable, or (3) to accept the session as it was proposed.
2. 策略服务器为此会话生成策略决策，并将决策返回给用户代理。可能的政策决定包括（1）拒绝该会话，（2）建议对会话参数进行更改，以使会话可以接受，或（3）接受提议的会话。
3. The policy server can update the policy decision at a later time. A policy decision update can, for example, propose additional changes to the session (e.g., change the available bandwidth) or deny a previously accepted session (i.e., disallow the continuation of a session).
3. 策略服务器可以在以后更新策略决策。例如，策略决策更新可以建议对会话进行其他更改（例如，更改可用带宽）或拒绝先前接受的会话（例如，不允许继续会话）。
In many cases, the mechanism for session-specific policies will be used to disclose session information and return session policies. However, some scenarios only involve the disclosure of session information to a network intermediary. If an intermediary does not intend to return a policy, it can simply accept the session as it was proposed. Similarly, some session-specific policies only apply to the offer (and therefore only require the disclosure of the offer) whereas others apply to offer and answer. Both types of policies are supported by session-specific policy mechanism.
在许多情况下，特定于会话的策略机制将用于公开会话信息和返回会话策略。然而，有些场景只涉及向网络中介披露会话信息。如果中介机构不打算返回策略，它只需按照建议接受会话即可。类似地，某些特定于会话的策略仅适用于要约（因此仅要求披露要约），而其他策略则适用于要约和答复。这两种类型的策略都由特定于会话的策略机制支持。
This section provides two examples to illustrate the overall operation of session-specific policies. The call flows depict the rendezvous mechanism between UA and policy server and indicate the points at which the UA exchanges policy information with the policy server.
本节提供两个示例来说明特定于会话的策略的总体操作。调用流描述UA和策略服务器之间的会合机制，并指示UA与策略服务器交换策略信息的点。
The example is based on the following scenario: there are two domains (domain A and domain B), which both have session-specific policies for the UAs in their domain. Neither domain provides policies to the UAs outside of their own domain. The two domains have a proxy (Proxy A and Proxy B) and a policy server (PS A and PS B). The policies in both domains involve the session description offer and answer.
该示例基于以下场景：有两个域（域A和域B），它们在各自的域中都有针对UAs的特定于会话的策略。这两个域都不向其自己域之外的UAs提供策略。这两个域有一个代理（代理a和代理B）和一个策略服务器（PS a和PS B）。这两个域中的策略都涉及会话描述提供和应答。
The first call flow shown in Figure 3 depicts an INVITE transaction with the offer in the request. It is assumed that this is the first INVITE request the UAC creates in this domain and that it therefore does not have previous knowledge about the policy server URIs in this domain.
图3所示的第一个调用流描述了请求中带有要约的INVITE事务。假设这是UAC在此域中创建的第一个INVITE请求，因此它以前不知道此域中的策略服务器URI。
(1) UA A sends an INVITE request to Proxy A. Proxy A knows that policies apply to this session and (2) returns a 488 (Not Acceptable Here) response to UA A. Proxy A includes the URI of PS A in the 488 (Not Acceptable Here) response. This step is needed since the UAC has no prior knowledge about the URI of PS A. (3) UA A uses the URI to contact PS A, discloses the session description offer to PS A, and (4) receives policies for the offer. (5) UA A reformulates the INVITE request under consideration of the received policies and includes a Policy-ID header field to indicate that it has already contacted PS
(1) UA A向代理A发送INVITE请求。代理A知道策略适用于此会话，并且（2）向UA A返回488（此处不可接受）响应。代理A在488（此处不可接受）响应中包含PS A的URI。由于UAC事先不知道PS A的URI，因此需要此步骤。（3）UA A使用URI联系PS A，向PS A公开会话描述要约，以及（4）接收要约的策略。（5） UA A在考虑接收到的策略的情况下重新制定INVITE请求，并包括一个策略ID头字段，以指示其已联系PS
A. Proxy A does not reject the INVITE request this time and removes the Policy-ID header field when forwarding the INVITE request. Proxy B adds a Policy-Contact header field containing the URI of PS B. (6) UA B uses this URI to contact PS B and disclose the offer and the answer it is about to send. (7) UA B receives policies from PS B and applies them to the offer and answer, respectively. (8) UA B returns the updated answer in the 200 (OK) response. (9) UA A contacts PS A again with the current offer and answer and (10) retrieves the policies for both from PS A.
A.代理A这次不会拒绝邀请请求，并在转发邀请请求时删除策略ID头字段。代理B添加了一个包含PS B的URI的策略联系人标头字段。（6）UA B使用此URI联系PS B，并披露其将要发送的报价和答案。（7） UA B从PS B接收政策，并将其分别应用于报价和应答。（8） UA B在200（确定）响应中返回更新的答案。（9） UA A再次与PS A联系，提供当前的报价和答案，（10）从PS A检索这两个方面的策略。
UA A Proxy A Proxy B UA B
| | | |
| INVITE offer | | |
|---------------->| | | (1)
| 488 | | |
| + Policy-Contact| | |
|<----------------| | | (2)
| ACK | | |
|---------------->| | |
| | PS A | |
| | | |
| PolicyChannel | | |
| + InfoOffer | | |
|------------------->| | | (3)
| PolicyChannel | | |
| + PolicyOffer | | |
|<-------------------| | | (4)
| | | |
| | | |
| INVITE offer' | INVITE offer' | INVITE offer' |
| + Policy-ID | | + Policy-Contact|
|---------------->|--------------->|---------------->| (5)
| | | |
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer' |
| | | + InfoAnswer |
| | |<-------------------| (6)
| | | PolicyChannel |
| | | + PolicyOffer |
| | | + PolicyAnswer |
| | |------------------->| (7)
| | | |
UA A Proxy A Proxy B UA B
| | | |
| INVITE offer | | |
|---------------->| | | (1)
| 488 | | |
| + Policy-Contact| | |
|<----------------| | | (2)
| ACK | | |
|---------------->| | |
| | PS A | |
| | | |
| PolicyChannel | | |
| + InfoOffer | | |
|------------------->| | | (3)
| PolicyChannel | | |
| + PolicyOffer | | |
|<-------------------| | | (4)
| | | |
| | | |
| INVITE offer' | INVITE offer' | INVITE offer' |
| + Policy-ID | | + Policy-Contact|
|---------------->|--------------->|---------------->| (5)
| | | |
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer' |
| | | + InfoAnswer |
| | |<-------------------| (6)
| | | PolicyChannel |
| | | + PolicyOffer |
| | | + PolicyAnswer |
| | |------------------->| (7)
| | | |
| | | |
| OK answer' | OK answer' | OK answer' |
|<----------------|<---------------|<----------------| (8)
| ACK |
|--------------------------------------------------->|
| | | |
| | | |
| PolicyChannel | | |
| + InfoOffer' | | |
| + InfoAnswer' | | |
|------------------->| | | (9)
| PolicyChannel | | |
| + PolicyOffer | | |
| + PolicyAnswer | | |
|<-------------------| | | (10)
| | | |
| | | |
| OK answer' | OK answer' | OK answer' |
|<----------------|<---------------|<----------------| (8)
| ACK |
|--------------------------------------------------->|
| | | |
| | | |
| PolicyChannel | | |
| + InfoOffer' | | |
| + InfoAnswer' | | |
|------------------->| | | (9)
| PolicyChannel | | |
| + PolicyOffer | | |
| + PolicyAnswer | | |
|<-------------------| | | (10)
| | | |
Figure 3
图3
The call flow shown in Figure 4 depicts an INVITE transaction with the offer in the response.
图4所示的调用流描述了一个INVITE事务，该事务在响应中包含要约。
(1) UA A sends an INVITE request without an offer to Proxy A and (2) Proxy A returns a 488 (Not Acceptable Here) response containing the URI of PS A. (3),(4) UA A uses this policy server URI to set up the policy channel. At this time, UA A does not disclose a session description since it does not have the offer yet. (5) UA A re-sends the INVITE request and includes a Policy-ID header field to indicate that it has contacted PS A. Proxy A does not reject the INVITE request this time and removes the Policy-ID header field when forwarding the INVITE request. Proxy B adds a Policy-Contact header field containing the URI of PS B. (6) UA B uses this URI to discloses the offer to PS B. (7) UA B receives policies from PS B and applies them to the offer. (8) UA B returns the updated offer the 200 (OK) response. (9),(10) UA A contacts PS and discloses the offer and the answer it is about to send. An important difference to the flow in the previous example is that UA A performs steps (9) and (10) before returning the answer in step (11). This enables UA A to return the final answer in the ACK request, which includes all applicable policies. However, it requires that PS A immediately returns a policy to avoid a delay in the transmission of the ACK request. (12),(13) UA B again sends the current offer and answer to PS B and applies the policies it receives to both before using them.
(1) UA A向代理A发送一个INVITE请求，但不提供服务，（2）代理A返回一个488（此处不可接受）响应，其中包含PS A的URI。（3）、（4）UA A使用此策略服务器URI设置策略通道。目前，UA没有披露会话描述，因为它还没有报价。（5） UA A重新发送INVITE请求，并包含一个策略ID头字段，以指示其已联系PS A。代理A这次不会拒绝INVITE请求，并在转发INVITE请求时删除策略ID头字段。代理B添加包含PS B URI的策略联系人标头字段。（6）UA B使用此URI向PS B公开报价。（7）UA B从PS B接收策略并将其应用于报价。（8） UA B将更新后的报价返回200（正常）响应。（9） ，（10）UA A联系PS并披露报价及其即将发送的回复。与前一示例中的流程的一个重要区别是，UA A在步骤（11）中返回答案之前执行步骤（9）和（10）。这使UA能够在ACK请求中返回最终答案，其中包括所有适用的策略。然而，它要求PS A立即返回策略，以避免ACK请求的传输延迟。（12） ，（13）UA B再次将当前报价和应答发送给PS B，并在使用前将其收到的策略应用于两者。
UA A Proxy A Proxy B UA B
| | | |
| INVITE | | |
|---------------->| | | (1)
| 488 | | |
| + Policy-Contact| | |
|<----------------| | | (2)
| ACK | | |
|---------------->| | |
| | PS A | |
| | | |
| PolicyChannel | | |
|------------------->| | | (3)
| PolicyChannel | | |
|<-------------------| | | (4)
| | | |
| | | |
| INVITE | INVITE | INVITE |
| + Policy-ID | | + Policy-Contact|
|---------------->|--------------->|---------------->| (5)
| | | |
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer |
| | |<-------------------| (6)
| | | PolicyChannel |
| | | + PolicyOffer |
| | |------------------->| (7)
| | | |
| | | |
| OK offer' | OK offer' | OK offer' |
|<----------------|<---------------|<----------------| (8)
| | | |
| | | |
| PolicyChannel | | |
| + InfoOffer' | | |
| + InfoAnswer | | |
|------------------->| | | (9)
| PolicyChannel | | |
| + PolicyOffer | | |
| + PolicyAnswer | | |
|<-------------------| | | (10)
| | | |
| ACK answer' |
|--------------------------------------------------->| (11)
| | | |
| | | |
UA A Proxy A Proxy B UA B
| | | |
| INVITE | | |
|---------------->| | | (1)
| 488 | | |
| + Policy-Contact| | |
|<----------------| | | (2)
| ACK | | |
|---------------->| | |
| | PS A | |
| | | |
| PolicyChannel | | |
|------------------->| | | (3)
| PolicyChannel | | |
|<-------------------| | | (4)
| | | |
| | | |
| INVITE | INVITE | INVITE |
| + Policy-ID | | + Policy-Contact|
|---------------->|--------------->|---------------->| (5)
| | | |
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer |
| | |<-------------------| (6)
| | | PolicyChannel |
| | | + PolicyOffer |
| | |------------------->| (7)
| | | |
| | | |
| OK offer' | OK offer' | OK offer' |
|<----------------|<---------------|<----------------| (8)
| | | |
| | | |
| PolicyChannel | | |
| + InfoOffer' | | |
| + InfoAnswer | | |
|------------------->| | | (9)
| PolicyChannel | | |
| + PolicyOffer | | |
| + PolicyAnswer | | |
|<-------------------| | | (10)
| | | |
| ACK answer' |
|--------------------------------------------------->| (11)
| | | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer' |
| | | + InfoAnswer' |
| | |<-------------------| (12)
| | | PolicyChannel |
| | | + PolicyOffer |
| | | + PolicyAnswer |
| | |------------------->| (13)
| | | |
| | | PolicyChannel |
| | | + InfoOffer' |
| | | + InfoAnswer' |
| | |<-------------------| (12)
| | | PolicyChannel |
| | | + PolicyOffer |
| | | + PolicyAnswer |
| | |------------------->| (13)
| | | |
Figure 4
图4
The first step in setting up session-specific policies is to rendezvous the UAs with the relevant policy servers. This is achieved by providing the URIs of all policy servers relevant for a session to the UAs.
设置特定于会话的策略的第一步是将UAs与相关的策略服务器会合。这是通过向UAs提供与会话相关的所有策略服务器的URI来实现的。
A UAC compliant to this specification MUST include a Supported header field with the option tag "policy" into all requests that can initiate an offer/answer exchange [RFC3264] (e.g., INVITE, UPDATE [RFC3311], and PRACK [RFC3262] requests). The UAC MUST include the "policy" option tag into these requests even if the particular request does not contain an offer or answer (e.g., an INVITE request without an offer). A UAC MAY include the "policy" option tag into all requests.
符合本规范的UAC必须在所有可以发起要约/应答交换[RFC3264]（例如，邀请、更新[RFC3311]和PRACK[RFC3262]请求）的请求中包含一个支持的标题字段，该字段带有选项标记“policy”。UAC必须在这些请求中包含“策略”选项标签，即使特定请求不包含要约或答复（例如，不包含要约的邀请请求）。UAC可以在所有请求中包含“策略”选项标记。
A UAC can receive a 488 (Not Acceptable Here) response that contains a Policy-Contact header field. The Policy-Contact header field is a new header field defined in this specification. It contains one (or multiple alternative) URI(s) for a policy server. A 488 (Not Acceptable Here) response with this header field is generated by a proxy to convey a URI of the local policy server to the UAC. After receiving a 488 (Not Acceptable Here) response with a Policy-Contact header field, a UAC compliant to this specification needs to decide if it wants to continue with the session now knowing that there is a policy server. If the UAC decides to continue, the UAC MUST use one of the policy server URIs to contact the policy server using the mechanism defined in Section 4.5.
UAC可以接收包含策略联系人标头字段的488（此处不接受）响应。策略联系人标题字段是本规范中定义的新标题字段。它包含策略服务器的一个（或多个可选）URI。代理生成带有此头字段的488（此处不可接受）响应，以将本地策略服务器的URI传递给UAC。在收到带有策略联系人标头字段的488（此处不可接受）响应后，符合此规范的UAC需要决定是否希望在知道存在策略服务器的情况下继续会话。如果UAC决定继续，UAC必须使用其中一个策略服务器URI，使用第4.5节中定义的机制联系策略服务器。
The Policy-Contact header can contain multiple URIs each with a different URI scheme and containing an "alt-uri" parameter with identical values. These URIs represent alternative policy channel mechanisms for obtaining the same policy. The UAC chooses one of the alternative URIs to use to obtain the policy. The UAC MAY take as a
策略联系人标头可以包含多个URI，每个URI具有不同的URI方案，并且包含具有相同值的“alt URI”参数。这些URI表示用于获取相同策略的替代策略通道机制。UAC选择一个备选URI来获取策略。UAC可能会将其视为
hint the order of the alternative URIs as indicating a preference as to which URI to use. The topmost URI in the list might be more preferred by the domain of the proxy for use to obtain the policy.
提示可选URI的顺序，以指示使用哪个URI的首选项。代理的域可能更倾向于使用列表中最顶层的URI来获取策略。
After receiving policies from the policy server, the UAC decides whether or not it wants to accept these policies. If the UAC accepts these policies, the UAC MUST apply them to the current request and re-send the updated request. If no changes are required by policies or no policies have been received, the request can be re-sent without any policy-induced changes. If the UAC decides that the list of policy servers or the received session policies are unacceptable, then the UAC MUST NOT re-send the request.
从策略服务器接收策略后，UAC决定是否接受这些策略。如果UAC接受这些策略，UAC必须将其应用于当前请求并重新发送更新的请求。如果策略不需要更改或未收到任何策略，则可以重新发送请求，而无需任何策略引起的更改。如果UAC确定策略服务器列表或接收到的会话策略不可接受，则UAC不得重新发送请求。
To protect the integrity of the policy server URI in a Policy-Contact header field, the UAC SHOULD use a secured transport protocol such as Transport Layer Security (TLS) [RFC5246] between UAC and proxy.
为保护策略联系人标头字段中策略服务器URI的完整性，UAC应在UAC和代理之间使用安全传输协议，如传输层安全性（TLS）[RFC5246]。
The UAC MUST insert a Policy-ID header field into requests for which it has contacted a policy server and accepted the policies received. The Policy-ID header field is a new header field that is defined in this specification. The UA MUST create a Policy-ID header field value for each policy server it has contacted during the preparation of the request. A Policy-ID header field value contains two pieces of information: the policy server URI and an optional token. The policy server URI is the URI the UA has used to contact the policy server. The token is an opaque string the UAC can receive from the policy server. A token can, for example, be contained in the policy document [RFC6796]. If the UAC has received a token from the policy server, the UAC MUST include the token in the Policy-ID header field. The format of the Policy-ID header field is defined in Section 4.4.5.
UAC必须在其已联系策略服务器并接受所接收策略的请求中插入策略ID标头字段。策略ID标头字段是本规范中定义的新标头字段。UA必须为其在准备请求期间接触的每个策略服务器创建策略ID标头字段值。策略ID头字段值包含两条信息：策略服务器URI和可选令牌。策略服务器URI是UA用于联系策略服务器的URI。令牌是UAC可以从策略服务器接收的不透明字符串。例如，令牌可以包含在策略文档[RFC6796]中。如果UAC已从策略服务器接收到令牌，则UAC必须在策略ID标头字段中包含该令牌。第4.4.5节定义了策略ID标题字段的格式。
The main purpose of the Policy-ID header field is to enable a proxy to determine if the UAC already knows a URI of the local policy server. If the policy server URI is not yet known to the UAC, the proxy can convey this URI to the UAC by rejecting the request with a 488 (Not Acceptable Here) response.
策略ID头字段的主要用途是使代理能够确定UAC是否已经知道本地策略服务器的URI。如果UAC还不知道策略服务器URI，则代理可以通过使用488（此处不可接受）响应拒绝请求，将此URI传递给UAC。
In some cases, a request can traverse multiple domains with a session-policy server. Each of these domains can return a 488 (Not Acceptable Here) response containing a policy server URI. A UAC contacts a policy server after receiving a 488 (Not Acceptable Here) response from a domain and before re-sending the request. This creates an implicit order between the policy servers in multiple domains. That is, a UAC contacts the first policy server, re-sends the modified request, contacts the second policy server, re-sends the modified request, and so on. This way, session policies are always
在某些情况下，请求可以使用会话策略服务器跨多个域。每个域都可以返回包含策略服务器URI的488（此处不可接受）响应。UAC在收到来自域的488（此处不可接受）响应后以及在重新发送请求之前联系策略服务器。这将在多个域中的策略服务器之间创建隐式顺序。也就是说，UAC联系第一个策略服务器，重新发送修改后的请求，联系第二个策略服务器，重新发送修改后的请求，依此类推。这样，会话策略始终是有效的
applied to a request in the order in which the request traverses through the domains. The UAC MUST NOT change this implicit order among policy servers.
按请求遍历域的顺序应用于请求。UAC不得更改策略服务器之间的此隐式顺序。
A UAC frequently needs to contact the policy server in the local domain before setting up a session. To avoid the retransmission of the local policy server URI in a 488 (Not Acceptable Here) response for each new request, a UA SHOULD maintain a cache that contains the URI of the policy server in the local domain (see Section 4.4.4). The UAC SHOULD use the cached policy server URI to contact the local policy server before sending a request that initiates the offer/ answer exchange for a new session (e.g., an INVITE request). The UAC SHOULD NOT cache a policy server URI that is in a different domain than the UAC, even if it is the first policy server URI returned. The first policy server URI returned can be from another domain if the local domain does not have a policy server. Note that UACs perform exact domain comparisons. That is, foo.example.com and example.com are not considered equivalent.
UAC通常需要在设置会话之前联系本地域中的策略服务器。为避免在488（此处不可接受）响应中为每个新请求重新传输本地策略服务器URI，UA应在本地域中维护包含策略服务器URI的缓存（参见第4.4.4节）。UAC应使用缓存的策略服务器URI联系本地策略服务器，然后再发送启动新会话的提供/应答交换的请求（例如，INVITE请求）。UAC不应缓存与UAC位于不同域中的策略服务器URI，即使它是返回的第一个策略服务器URI。如果本地域没有策略服务器，则返回的第一个策略服务器URI可以来自另一个域。请注意，UAC执行精确的域比较。也就是说，foo.example.com和example.com并不等同。
UAs can renegotiate the session description during a session by initiating a subsequent offer/answer exchange, e.g., in an INVITE, UPDATE, or PRACK request. When creating such a mid-dialog request, a UA SHOULD contact all policy servers to which it has established a policy channel during the initial offer/answer exchange (see Section 4.5) before sending the request. This avoids the retransmission of all policy server URIs in 488 (Not Acceptable Here) responses for mid-dialog requests.
UAs可以在会话期间通过发起后续的要约/应答交换（例如，在邀请、更新或PRACK请求中）重新协商会话描述。创建此类mid对话请求时，UA应在发送请求之前，在初始报价/应答交换（见第4.5节）期间联系其已建立策略通道的所有策略服务器。这避免了在mid对话请求的488（此处不接受）响应中重新传输所有策略服务器URI。
A proxy provides rendezvous functionalities for UAs and policy server. This is achieved by conveying the URI of a policy server to the UAC or the UAS (or both) when processing INVITE, UPDATE, or PRACK requests (or any other request that can initiate an offer/answer exchange).
代理为UAs和策略服务器提供会合功能。这是通过在处理INVITE、UPDATE或PRACK请求（或可以发起要约/应答交换的任何其他请求）时将策略服务器的URI传递给UAC或UAS（或两者）来实现的。
If an offer/answer exchange initiating request contains a Supported header field with the option tag "policy", the proxy MAY reject the request with a 488 (Not Acceptable Here) response to provide the local policy server URI to the UAC. Before rejecting a request, the proxy MUST verify that the request does not contain a Policy-ID header field with the local policy server URI as a value. If the request does not contain such a header field or a local policy server URI is not present in this header field, then the proxy MAY reject the request with a 488 (Not Acceptable Here) response. The proxy MUST insert a Policy-Contact header field in the 488 (Not Acceptable Here) response that contains one (or multiple) URI(s) of its
如果提供/应答交换发起请求包含带有选项标记“policy”的受支持标头字段，则代理可以使用488（此处不可接受）响应拒绝该请求，以向UAC提供本地策略服务器URI。在拒绝请求之前，代理必须验证请求不包含以本地策略服务器URI为值的策略ID标头字段。如果请求不包含这样的头字段，或者本地策略服务器URI不存在于该头字段中，则代理可以使用488（此处不可接受）响应拒绝请求。代理必须在488（此处不可接受）响应中插入策略联系人标头字段，该响应包含其代理的一个（或多个）URI
associated policy server. The proxy MAY add the header field parameter "non-cacheable" to prevent the UAC from caching this policy server URI (see Section 4.4.4).
关联的策略服务器。代理可以添加标头字段参数“non cacheable”，以防止UAC缓存此策略服务器URI（请参阅第4.4.4节）。
More than one URI for the policy server using different URI schemes MAY be provided by the proxy as alternative URIs to contact the policy. If a proxy includes multiple URIs for the same policy, the proxy MUST include an "alt-uri" parameter for all policy server URIs that are alternatives for obtaining the same policy. The "alt-uri" parameter MUST contain either the domain name of the domain for which all the alternative policy server URIs relate to or a Fully Qualified Domain Name (FQDN) (e.g., the hostname of a policy server). All URIs that are alternatives for the same policy MUST have the same value for the "alt-uri" parameter. The value used for the "alt-uri" parameter MUST be such that the same value will not be included with other policy server URIs that a UA needs to contact by any other proxy within the same domain or another domain. A method to create a new unique "alt-uri" parameter value is to examine the value of existing "alt-uri" parameters and to make sure that the new value differs. A proxy MAY hint to a UA at a preference as to which URI to use by including the more preferred URI higher in the list than the other alternative URIs. URIs with the same "alt-uri" parameter MUST use different URI schemes. A SIP or SIPS URI MUST be included even if other URI schemes are defined and used in the future.
代理可以为使用不同URI方案的策略服务器提供多个URI，作为联系策略的备选URI。如果代理包含同一策略的多个uri，则该代理必须包含所有策略服务器uri的“alt uri”参数，这些uri是获取相同策略的备选方案。“alt uri”参数必须包含与所有备选策略服务器uri相关的域的域名或完全限定域名（FQDN）（例如，策略服务器的主机名）。作为同一策略的备选方案的所有uri的“alt uri”参数值必须相同。“alt uri”参数使用的值必须确保UA需要通过同一域或另一域内的任何其他代理联系的其他策略服务器uri中不包含相同的值。创建新的唯一“alt uri”参数值的方法是检查现有“alt uri”参数的值，并确保新值不同。代理可以通过在列表中包括比其他可选URI更高的更优选URI，以向UA提示关于使用哪个URI的偏好。具有相同“alt uri”参数的uri必须使用不同的uri方案。即使将来定义并使用了其他URI方案，也必须包含SIP或SIPS URI。
If a local policy server URI is present in a Policy-ID header field value of a request, then the proxy MUST NOT reject the request as described above (it can still reject the request for other reasons). The proxy SHOULD remove the Policy-ID header field value of its associated policy server from the Policy-ID header field before forwarding the request. Not removing the Policy-ID header field value will not cause harm; however, the value is not relevant to any other proxy on the path and only increases message size. It also would disclose the policy server URI to subsequent proxies.
如果请求的策略ID标头字段值中存在本地策略服务器URI，则代理不得如上所述拒绝该请求（它仍可以出于其他原因拒绝该请求）。在转发请求之前，代理应从策略ID标头字段中删除其关联策略服务器的策略ID标头字段值。不删除策略ID头字段值不会造成伤害；但是，该值与路径上的任何其他代理无关，只会增加消息大小。它还将向后续代理公开策略服务器URI。
The Policy-ID header field serves two main purposes: first and most important, it enables the proxy to determine if a UAC already knows the URI of the local policy server. The second purpose of the Policy-ID header field is to enable a domain to route all requests that belong to the same session (i.e., the initial request and requests a UA retransmits after contacting the policy server) to the same proxy and policy server. This is important if a domain has multiple proxy/policy server combinations (e.g., in a proxy/policy server farm that receives requests through a load balancer), which create per-session state in the network. An example for such a scenario is a policy server that is associated with a session border device. The policy server configures the session border device after receiving a session description from the UAC via the policy channel.
策略ID头字段有两个主要用途：第一个也是最重要的，它使代理能够确定UAC是否已经知道本地策略服务器的URI。策略ID头字段的第二个用途是使域能够将属于同一会话的所有请求（即，初始请求和请求UA在联系策略服务器后重新传输）路由到同一代理和策略服务器。如果域具有多个代理/策略服务器组合（例如，在通过负载平衡器接收请求的代理/策略服务器场中），并且这些组合在网络中创建每个会话状态，则这一点非常重要。此类场景的一个示例是与会话边界设备关联的策略服务器。策略服务器通过策略通道从UAC接收会话描述后，配置会话边界设备。
Retransmitted requests for such a session need to be routed to the same proxy/policy server as the initial request since this proxy/ policy server combination has configured the associated border device for the session.
此类会话的重传请求需要路由到与初始请求相同的代理/策略服务器，因为此代理/策略服务器组合已为会话配置了关联的边界设备。
Routing all requests that belong to the same session to the same proxy can be achieved by using the Policy-ID header field token. It requires that the policy server return a token to the UAC that uniquely identifies the specific proxy/policy server combination. The UAC includes this token in the Policy-ID header field, and it can be used (together with the policy server URI) by the proxies in this domain to route the request along the desired path. The format of this token does not require standardization. The only requirement is that the token provide sufficient information for proxies to route the message inside a domain to the desired proxy/policy server. The token can, for example, be a numeric identifier or an IP address.
可以使用策略ID头字段令牌将属于同一会话的所有请求路由到同一代理。它要求策略服务器向UAC返回唯一标识特定代理/策略服务器组合的令牌。UAC在策略ID头字段中包含该令牌，该域中的代理可以使用该令牌（与策略服务器URI一起）沿所需路径路由请求。此令牌的格式不需要标准化。唯一的要求是令牌为代理提供足够的信息，以便将域内的消息路由到所需的代理/策略服务器。例如，令牌可以是数字标识符或IP地址。
Note: it has been proposed to use the Policy-ID header field to provide a hint for a proxy that the UAC has actually contacted the policy server. This usage also requires the policy server to return a token to the UA. In addition, the policy server needs to share valid tokens with the proxy. After receiving a request with a Policy-ID header field, the proxy can determine if the token in the Policy-ID header field is valid. If it is valid, the proxy knows that the UA has contacted the policy server for this session. However, this token does not provide any proof that the UA has actually used the policies it has received from the policy server. A malicious UA can simply contact the policy server, discard all policies it receives, and still use the token in the Policy-ID header field.
注意：建议使用策略ID头字段为代理提供UAC实际已联系策略服务器的提示。这种用法还要求策略服务器向UA返回令牌。此外，策略服务器需要与代理共享有效令牌。在收到带有策略ID标头字段的请求后，代理可以确定策略ID标头字段中的令牌是否有效。如果有效，则代理知道UA已为此会话联系策略服务器。但是，此令牌不提供任何证据证明UA实际使用了从策略服务器收到的策略。恶意UA只需联系策略服务器，放弃它接收到的所有策略，然后仍然使用策略ID标头字段中的令牌即可。
The proxy MAY insert a Policy-Contact header field into INVITE, UPDATE, or PRACK requests (or any other request that can initiate an offer/answer exchange) in order to convey the policy server URI to the UAS. If the request already contains a Policy-Contact header field, the proxy MUST insert the URI after all existing values at the end of the list. A proxy MUST NOT change the order of existing Policy-Contact header field values.
代理可以在INVITE、UPDATE或PRACK请求（或可以发起要约/应答交换的任何其他请求）中插入策略联系人头字段，以便将策略服务器URI传递给UAS。如果请求已包含策略联系人标头字段，则代理必须在列表末尾的所有现有值之后插入URI。代理不得更改现有策略联系人标头字段值的顺序。
A proxy MUST use the Record-Route mechanism [RFC3261] if its associated policy server has session policies that apply to mid-dialog requests. The Record-Route header field enables a proxy to stay in the signaling path and resubmit the policy server URIs to UAs during mid-dialog requests that initiate an offer/answer exchange. Resubmitting the policy server URI to UAs ensures that UAs keep contacting the policy server for mid-dialog requests.
如果代理的关联策略服务器具有适用于mid对话请求的会话策略，则代理必须使用记录路由机制[RFC3261]。Record Route header（记录路由头）字段允许代理留在信令路径中，并在发起报价/应答交换的中间对话请求期间向UAs重新提交策略服务器URI。向UAs重新提交策略服务器URI可确保UAs不断联系策略服务器以获取mid对话请求。
A proxy can find out if the UAS supports this extension by examining the Supported header field of responses. The proxy knows that the UAS supports this extension if the Supported header field of a response contains the option tag "policy". A proxy can use this information to determine if the UAS has understood the Policy-Contact header field it has inserted into the request.
代理可以通过检查响应的Supported header字段来确定UAS是否支持此扩展。如果响应的受支持标头字段包含选项标记“policy”，则代理知道UAS支持此扩展。代理可以使用此信息来确定UAS是否理解其插入到请求中的策略联系人标头字段。
To protect the integrity of the policy server URI in a Policy-Contact header field, the proxy SHOULD use a secured transport protocol such as TLS [RFC5246] between proxy and UAs.
为保护策略联系人标头字段中策略服务器URI的完整性，代理应在代理和UAs之间使用安全传输协议，如TLS[RFC5246]。
A UAS can receive an INVITE, UPDATE, or PRACK request (or another request that can initiate offer/answer exchanges) that contains a Policy-Contact header field with a list of policy server URIs. A UAS that receives such a request needs to decide if it wants to accept the session knowing that there are policy servers involved. If the Policy-Contact header contains multiple URIs, each with a different URI scheme and containing an "alt-uri" parameter with identical values, these URI schemes represent alternative policy channel mechanisms for obtaining the same policy. If the UAS accepts the session, the UAS MUST contact one URI out of each group of URIs with identical "alt-uri" parameter values to obtain the policy. The UAS MAY take as a hint the order of the alternative URIs as indicating a preference as to which URI to use. The topmost URI in the list might be more preferred by the domain of the proxy for use to obtain the policy. The UAS MUST contact all policy server URIs in a Policy-Contact header field that are not part of a group of alternative URIs and MUST contact one URI in each group of alternative URIs. The UAS MUST contact these policy server URIs in the order in which they were contained in the Policy-Contact header field, starting with the topmost value (i.e., the value that was inserted first).
UAS可以接收一个INVITE、UPDATE或PRACK请求（或另一个可以启动提供/应答交换的请求），该请求包含一个策略联系人头字段和策略服务器URI列表。接收此类请求的UAS需要在知道涉及策略服务器的情况下决定是否接受会话。如果策略联系人标头包含多个URI，每个URI具有不同的URI方案，并且包含具有相同值的“alt URI”参数，则这些URI方案表示用于获取相同策略的替代策略通道机制。如果UAS接受会话，则UAS必须联系每组URI中具有相同“alt URI”参数值的一个URI以获取策略。UAS可以将备选URI的顺序作为提示，指示使用哪个URI的首选项。代理的域可能更倾向于使用列表中最顶层的URI来获取策略。UAS必须联系策略联系人标头字段中不属于一组备选URI的所有策略服务器URI，并且必须联系每组备选URI中的一个URI。UAS必须按照包含在策略联系人标头字段中的顺序联系这些策略服务器URI，从最顶端的值（即首先插入的值）开始。
If a UAS decides that it does not want to accept a session because there are policy servers involved or because one of the session policies received from a policy server is not acceptable, the UAS MUST reject the request with a 488 (Not Acceptable Here) response.
如果UAS因为涉及策略服务器或从策略服务器接收到的某个会话策略不可接受而决定不接受会话，则UAS必须以488（此处不可接受）响应拒绝该请求。
The UAS MAY accept a request and continue with setting up a session if it cannot set up a policy channel to the policy server, for example, because the policy server is unreachable or returns an error condition that cannot be resolved by the UAS (i.e., error conditions other than, for example, a 401 (Unauthorized) response). This is to avoid that the failure of a policy server prevents a UA from communicating. Since this session might not be policy compliant without the policy subscription, it can be blocked by policy enforcement mechanisms if they are in place.
如果UAS无法设置到策略服务器的策略通道，例如，因为策略服务器无法访问或返回UAS无法解决的错误条件（即，除401（未授权）响应之外的错误条件），UAS可以接受请求并继续设置会话。这是为了避免策略服务器的故障阻止UA通信。由于此会话在没有策略订阅的情况下可能不符合策略，因此如果策略实施机制已就位，则可能会阻止该会话。
A UAS can receive a token from a policy server via the policy channel. Since the UAS does not create a Policy-ID header field, it can simply ignore this token.
UAS可以通过策略通道从策略服务器接收令牌。由于UAS不创建策略ID头字段，因此它可以忽略此令牌。
A UAS compliant to this specification MUST include a Supported header field with the option tag "policy" into responses to requests that can initiate an offer/answer exchange. The UAS MAY include this option tag in all responses. This way, a proxy that has inserted the Policy-Contact header field can know that the header field was understood by the UAS.
符合本规范的UAS必须在响应可发起报价/应答交换的请求时包含带有选项标记“policy”的受支持标题字段。UAS可能会在所有响应中包含此选项标签。这样，插入了策略联系人标头字段的代理可以知道标头字段已被UAS理解。
A UAC frequently needs to contact the policy server in the local domain before setting up a session. To avoid the retransmission of the local policy server URI for each session, a UA SHOULD maintain a cache that contains the URI of the local policy server.
UAC通常需要在设置会话之前联系本地域中的策略服务器。为了避免为每个会话重新传输本地策略服务器URI，UA应该维护一个包含本地策略服务器URI的缓存。
A UA can receive this URI in a Policy-Contact header field of a request or a 488 (Not Acceptable Here) response. The UA can also receive the local policy server URI through configuration, for example, via the configuration framework [RFC6080]. If a UA has received a local policy server URI through configuration and receives another local policy server URI in a Policy-Contact header field, the UA SHOULD overwrite the configured URI with the most recent one received in a Policy-Contact header field. A policy server URI received in a Policy-Contact header field expires if it has not been refreshed before it reaches the maximum cached URI validity. The default maximum cached URI validity is 24 hours.
UA可以在请求或488（此处不可接受）响应的策略联系人标头字段中接收此URI。UA还可以通过配置（例如，通过配置框架[RFC6080]）接收本地策略服务器URI。如果UA通过配置接收到本地策略服务器URI，并在策略联系人标头字段中接收到另一个本地策略服务器URI，则UA应使用在策略联系人标头字段中接收到的最新URI覆盖配置的URI。如果在策略联系人标头字段中接收的策略服务器URI在达到最大缓存URI有效性之前未刷新，则该URI将过期。默认最大缓存URI有效性为24小时。
Domains can prevent a UA from caching the local policy server URI. This is useful, for example, if the policy server does not need to be involved in all sessions or the policy server URI changes from session to session. A proxy can mark the URI of such a policy server as "non-cacheable". A UA MUST NOT cache a non-cacheable policy server URI. The UA SHOULD remove the current URI from the cache when receiving a local policy server URI that is marked as "non-cacheable". This is to avoid the use of policy server URIs that are outdated.
域可以阻止UA缓存本地策略服务器URI。例如，如果策略服务器不需要参与所有会话，或者策略服务器URI在会话之间发生更改，则这非常有用。代理可以将此类策略服务器的URI标记为“不可缓存”。UA不得缓存不可缓存的策略服务器URI。UA在接收标记为“不可缓存”的本地策略服务器URI时，应从缓存中删除当前URI。这是为了避免使用过时的策略服务器URI。
The UA SHOULD NOT cache policy server URIs it has received from proxies outside of the local domain. These policy servers need not be relevant for subsequent sessions, which can go to a different destination, traversing different domains.
UA不应缓存从本地域之外的代理接收到的策略服务器URI。这些策略服务器不需要与后续会话相关，后续会话可以到达不同的目的地，穿越不同的域。
The UA MUST NOT cache tokens it has received from a policy server. A token is only valid for one request.
UA不得缓存从策略服务器收到的令牌。令牌仅对一个请求有效。
The Policy-ID header field is inserted by the UAC into INVITE, UPDATE, or PRACK requests (or any other request that can be used to initiate an offer/answer exchange). The Policy-ID header field identifies all policy servers the UAC has contacted for this request.
UAC将策略ID头字段插入到INVITE、UPDATE或PRACK请求（或可用于启动报价/应答交换的任何其他请求）中。策略ID标头字段标识UAC为此请求联系的所有策略服务器。
The value of a Policy-ID header field consists of a policy server URI and an optional token parameter. The token parameter contains a token the UA might have received from the policy server.
策略ID标头字段的值由策略服务器URI和可选令牌参数组成。token参数包含UA可能从策略服务器收到的令牌。
The syntax of the Policy-ID header field is described below in ABNF, according to [RFC5234], as an extension to the ABNF for SIP in [RFC3261]:
根据[RFC5234]，作为[RFC3261]中SIP ABNF的扩展，下面在ABNF中描述了策略ID头字段的语法：
Policy-ID = "Policy-ID" HCOLON policyURI
*(COMMA policyURI)
policyURI = ( SIP-URI / SIPS-URI / absoluteURI )
[ SEMI token-param ] *( SEMI generic-param )
token-param = "token=" token
Policy-ID = "Policy-ID" HCOLON policyURI
*(COMMA policyURI)
policyURI = ( SIP-URI / SIPS-URI / absoluteURI )
[ SEMI token-param ] *( SEMI generic-param )
token-param = "token=" token
The Policy-Contact header field can be inserted by a proxy into a 488 (Not Acceptable Here) response to INVITE, UPDATE, or PRACK requests (or other requests that initiate an offer/answer exchange). The value of a Policy-Contact header field consists of a policy server URI and an optional "non-cacheable" header field parameter. The policy server URI identifies the policy server that needs to be contacted by a UAC. The "non-cacheable" header field parameter indicates that the policy server URI is not intended to be cached by the UAC.
代理可以将策略联系人标头字段插入488（此处不接受）响应中，以邀请、更新或PRACK请求（或启动报价/应答交换的其他请求）。策略联系人标头字段的值由策略服务器URI和可选的“不可缓存”标头字段参数组成。策略服务器URI标识UAC需要联系的策略服务器。“non-cacheable”header字段参数表示UAC不打算缓存策略服务器URI。
The Policy-Contact header field can also be inserted by a proxy into INVITE, UPDATE, and PRACK requests (or other requests that can be used to initiate an offer/answer exchange). It contains an ordered list of policy server URIs that need to be contacted by the UAS. The topmost value of this list identifies the policy server that is contacted first. New header field values are inserted at the end. With this, the Policy-Contact header field effectively forms a fist-in-first-out queue.
代理还可以将策略联系人标头字段插入到邀请、更新和PRACK请求（或可用于启动报价/应答交换的其他请求）中。它包含UAS需要联系的策略服务器URI的有序列表。此列表最顶端的值标识首先联系的策略服务器。在末尾插入新的标题字段值。这样，策略联系人头字段有效地形成了先进先出队列。
The syntax of the Policy-Contact header field is described below in ABNF, according to [RFC5234], as an extension to the ABNF for SIP in [RFC3261]:
根据[RFC5234]，作为[RFC3261]中SIP ABNF的扩展，下面在ABNF中描述了策略联系人标头字段的语法：
Policy-Contact = "Policy-Contact" HCOLON policyContact-info *(COMMA policyContact-info)
Policy Contact=“Policy Contact”HCOLON Policy联系人信息*（逗号Policy联系人信息）
policyContact-info = LAQUOT policyContact-uri RAQUOT *( SEMI policyContact-param )
policyContact info=LAQUOT policyContact uri RAQUOT*（半policyContact参数）
policyContact-uri = ( SIP-URI / SIPS-URI / absoluteURI )
policyContact-uri = ( SIP-URI / SIPS-URI / absoluteURI )
policyContact-param = ( "non-cacheable" / policyContact-alt-uri
/ generic-param )
policyContact-param = ( "non-cacheable" / policyContact-alt-uri
/ generic-param )
policyContact-alt-uri = "alt-uri" EQUAL hostname
policyContact alt uri=“alt uri”等于主机名
Tables 1 and 2 are extensions of Tables 2 and 3 in [RFC3261]. The column "INF" is for the INFO method [RFC6086], "PRA" is for the PRACK method [RFC3262], "UPD" is for the UPDATE method [RFC3311], "SUB" is for the SUBSCRIBE method [RFC6665], "NOT" is for the NOTIFY method [RFC6665], "MSG" is for the MESSAGE method [RFC3428], "REF" is for the REFER method [RFC3515], and "PUB" is for the PUBLISH method [RFC3903].
表1和表2是[RFC3261]中表2和表3的扩展。列“INF”表示INFO方法[RFC6086]，“PRA”表示PRACK方法[RFC3262]，“UPD”表示更新方法[RFC3311]，“SUB”表示订阅方法[RFC6665]，“NOT”表示通知方法[RFC6665]，“MSG”表示消息方法[RFC3428]，“REF”表示参考方法[RFC3515]，“PUB”表示发布方法[RFC3903].
Header field where proxy ACK BYE CAN INV OPT REG UPD
_______________________________________________________________
Policy-ID R rd - - - c - - c
Policy-Contact R a - - - c - - c
Policy-Contact 488 a - - - c - - c
Table 1: Policy-ID and Policy-Contact Header Fields
Header field where proxy ACK BYE CAN INV OPT REG UPD
_______________________________________________________________
Policy-ID R rd - - - c - - c
Policy-Contact R a - - - c - - c
Policy-Contact 488 a - - - c - - c
Table 1: Policy-ID and Policy-Contact Header Fields
Header field where proxy PRA PUB SUB NOT INF MSG REF
_______________________________________________________________
Policy-ID R rd c - - - - - -
Policy-Contact R a c - - - - - -
Policy-Contact 488 a c - - - - - -
Table 2: Policy-ID and Policy-Contact Header Fields
Header field where proxy PRA PUB SUB NOT INF MSG REF
_______________________________________________________________
Policy-ID R rd c - - - - - -
Policy-Contact R a c - - - - - -
Policy-Contact 488 a c - - - - - -
Table 2: Policy-ID and Policy-Contact Header Fields
The main task of the policy channel is to enable a UA to submit information about the session it is trying to establish (i.e., the offer and the answer) to a policy server and to receive the resulting session-specific policies and possible updates to these policies in response.
策略通道的主要任务是使UA能够向策略服务器提交有关其试图建立的会话的信息（即，报价和答案），并接收生成的特定于会话的策略以及可能对这些策略的更新。
The Event Package for Session-Specific Policies [RFC6795] defines a SUBSCRIBE/NOTIFY-based [RFC6665] policy channel mechanism. A UA compliant to this specification MUST support the Event Package for Session-Specific Policies [RFC6795]. The UA MUST use this event
会话特定策略[RFC6795]的事件包定义了基于订阅/通知的[RFC6665]策略通道机制。符合本规范的UA必须支持会话特定策略的事件包[RFC6795]。UA必须使用此事件
package to contact a policy server if the policy server URI is a SIP-URI or SIPS-URI. A UA MAY support other policy channel mechanisms.
如果策略服务器URI是SIP-URI或SIPS-URI，则打包以联系策略服务器。UA可以支持其他策略通道机制。
A UA discovers the list of policy servers relevant for a session during the initial offer/answer exchange (see Section 4.4). A UA compliant to this specification MUST set up a policy channel to each of the discovered policy servers. If the UA does not want to set up a policy channel to one of the policy servers provided, the UA MUST cancel or reject a pending INVITE transaction for the session or terminate the session if it is already in progress.
UA在初始报价/应答交换期间发现与会话相关的策略服务器列表（参见第4.4节）。符合此规范的UA必须设置到每个发现的策略服务器的策略通道。如果UA不想设置到提供的其中一个策略服务器的策略通道，则UA必须取消或拒绝会话的挂起INVITE事务，或者在会话已在进行时终止会话。
A UA MUST maintain the policy channel to each discovered policy server during the lifetime of a session, unless the policy channel is closed by the policy server or the UA discovers that the policy server is no longer relevant for the session as described below.
UA必须在会话的生存期内维护到每个发现的策略服务器的策略通道，除非策略服务器关闭了策略通道，或者UA发现策略服务器不再与会话相关，如下所述。
A UAC can receive a 488 (Not Acceptable Here) response with a Policy-Contact header field containing a new policy server URI in response to a mid-dialog request. This indicates that the set of policy servers relevant for the current session has changed. If this occurs, the UAC MUST retry sending the request as if it were the first request in a dialog (i.e., without applying any policies except the policies from the local policy server). This way, the UAC will rediscover the list of policy servers for the current session. This is necessary since the UAC has no other way of knowing when to contact the newly discovered policy server relative to the existing policy servers and if any of the existing policy servers do not need to be contacted any more. The UAC MUST set up a policy channel to each new policy server. The UAC SHOULD close policy channels to policy server that are not listed any more. If the policy channel to these servers is not closed, the UAC can receive policies that do not apply to the session any more. The UAC MUST contact policy servers in the order in which they were discovered in the most recent request.
UAC可以接收488（此处不可接受）响应，该响应带有策略联系人标头字段，其中包含新的策略服务器URI，以响应mid对话请求。这表示与当前会话相关的策略服务器集已更改。如果出现这种情况，UAC必须重试发送请求，就像它是对话框中的第一个请求一样（即，不应用除本地策略服务器的策略之外的任何策略）。这样，UAC将重新发现当前会话的策略服务器列表。这是必要的，因为UAC没有其他方式知道何时联系新发现的相对于现有策略服务器的策略服务器，以及是否不再需要联系任何现有策略服务器。UAC必须为每个新策略服务器设置策略通道。UAC应该关闭到策略服务器的策略通道，这些通道不再列出。如果到这些服务器的策略通道未关闭，UAC可以接收不再应用于会话的策略。UAC必须按照在最新请求中发现策略服务器的顺序联系它们。
If a UAS receives a mid-dialog request with a Policy-Contact header field containing a list of policy server URIs that is different from the list of policy servers to which the UAS has currently established a policy channel, then the UAS MUST set up a policy channel to all new policy servers and contact them. The UAS SHOULD close policy channels to servers that are not listed any more. If the policy channel to these servers is not closed, the UAS can receive policies that do not apply to the session any more. The UAS MUST use policy servers in the order in which they were contained in the most recent Policy-Contact header field.
如果UAS收到一个mid对话框请求，其中包含一个包含策略服务器URI列表的策略联系人标头字段，该列表与UAS当前已建立策略通道的策略服务器列表不同，则UAS必须建立一个到所有新策略服务器的策略通道，并与它们联系。UAS应关闭与不再列出的服务器的策略通道。如果到这些服务器的策略通道未关闭，UAS可以接收不再应用于会话的策略。UAS必须按照策略服务器包含在最新策略联系人标头字段中的顺序使用策略服务器。
A UA MUST inform the policy server when a session is terminated (e.g., when the UA has either sent or received a BYE) via the policy channel, unless a policy server indicates via the policy channel that it does not need to be contacted at the end of the session. This enables a policy server to free all resources it has allocated for this session.
UA必须通过策略通道在会话终止时（例如，当UA发送或接收到BYE时）通知策略服务器，除非策略服务器通过策略通道指示不需要在会话结束时联系它。这使策略服务器能够释放为此会话分配的所有资源。
A UA MUST contact all policy servers to which it has established a policy channel before sending or after receiving a mid-dialog request. The UA MUST contact the policy servers in the order in which they were discovered most recently.
UA必须在发送mid对话请求之前或在接收mid对话请求之后联系其已建立策略通道的所有策略服务器。UA必须按照最近发现策略服务器的顺序与它们联系。
A UA that receives a SIP message containing an offer or answer SHOULD completely process the message (e.g., according to [RFC3261]) before contacting the policy server. The SIP processing of the message includes, for example, updating dialog state and timers as well as creating ACK or PRACK requests as necessary. This ensures that contacting a policy server does not interfere with SIP message processing and timing (e.g., by inadvertently causing timers to expire). This implies, for example, that a UAC that has received a response to an INVITE request would normally finish the processing of the response including transmitting the ACK request before it contacts the policy server. An important exception to this rule is discussed in the next paragraph.
收到包含要约或应答的SIP消息的UA应在联系策略服务器之前完全处理该消息（例如，根据[RFC3261]）。消息的SIP处理例如包括更新对话状态和定时器以及根据需要创建ACK或PRACK请求。这可确保联系策略服务器不会干扰SIP消息处理和计时（例如，无意中导致计时器过期）。这意味着，例如，已接收到对INVITE请求的响应的UAC通常会在联系策略服务器之前完成响应处理，包括发送ACK请求。下一段将讨论这一规则的一个重要例外。
In some cases, a UA needs to use the offer/answer it has received in a SIP message to create an ACK or PRACK request for this message; i.e., it needs to use the offer/answer before finishing the SIP machinery for this message. For example, a UAC that has received an offer in the response to an INVITE request needs to apply policies to the offer and the answer before it can send the answer in an ACK request. In these cases, a UA SHOULD contact the policy server even if this is during the processing of a SIP message. This implies that a UA, which has received an offer in the response of an INVITE request, would normally contact the policy server and apply session policies before sending the answer in the ACK request.
在某些情况下，UA需要使用其在SIP消息中接收到的提供/应答来为该消息创建ACK或PRACK请求；i、 例如，在完成此消息的SIP机制之前，它需要使用offer/answer。例如，在对INVITE请求的响应中收到要约的UAC需要将策略应用于要约和应答，然后才能在ACK请求中发送应答。在这些情况下，UA应该联系策略服务器，即使这是在处理SIP消息期间。这意味着在INVITE请求的响应中收到要约的UA通常会在ACK请求中发送应答之前联系策略服务器并应用会话策略。
Note: this assumes that the policy server can always respond immediately to a policy request and does not require manual intervention to create a policy. This will be the case for most policy servers. If, however, a policy server cannot respond with a policy right away, it can return a policy that temporarily denies the session and update this policy as the actual policy decision becomes available. A delay in the response from the
注意：这假定策略服务器始终可以立即响应策略请求，并且不需要手动干预来创建策略。大多数策略服务器都是这样。但是，如果策略服务器无法立即响应策略，它可以返回临时拒绝会话的策略，并在实际策略决策可用时更新此策略。来自服务器的响应延迟
policy server to the UA would delay the transmission of the ACK request and could trigger retransmissions of the INVITE response (also see the recommendations for Flow I in [RFC3725]).
到UA的策略服务器将延迟ACK请求的传输，并可能触发INVITE响应的重新传输（另请参阅[RFC3725]中关于流I的建议）。
The case of multiple policy servers providing policies to the same UA requires additional considerations. A policy returned by one policy server can contain information that needs to be shared with the other policy servers. For example, two policy servers can have the policy to insert a media intermediary by modifying the IP addresses and ports of media streams. In order for media streams to pass through both intermediaries, each intermediary needs to know the IP address and port on which the other media intermediary is expecting the stream to arrive. If media streams are flowing in both directions, this means that each intermediary needs to know IP addresses and ports of the other intermediary.
多个策略服务器向同一UA提供策略的情况需要额外考虑。一个策略服务器返回的策略可以包含需要与其他策略服务器共享的信息。例如，两个策略服务器可以具有通过修改媒体流的IP地址和端口来插入媒体中介的策略。为了让媒体流通过两个中介，每个中介都需要知道另一个媒体中介期望流到达的IP地址和端口。如果媒体流在两个方向上流动，这意味着每个中介体都需要知道另一个中介体的IP地址和端口。
UACs usually contact a policy server twice during an offer/answer exchange (unless a policy server indicates that it only needs to be contacted once). Therefore, the case of multiple policy servers providing policies to a single UAC does not require additional steps in most cases. However, a UAS usually contacts each policy server only once (see Figure 4). If a session policy returned by one of the policy servers requires that information be shared between multiple servers and the UAS receives policies from more than one policy server, then the UAS MUST contact all policy servers a second time after contacting all servers the first time. Whether or not a second round is required is determined by the type of information returned by the policy server. A data format for session policies (e.g., [RFC6796]) needs to explicitly state if a second round is needed for a particular data element. If a UA receives such an element, it knows that is expected to contact policy servers a second time. If such a data element is modified during a mid-call offer/answer exchange and multiple policy servers are providing policies to a UA, then all UAs MUST contact policy servers in a first and second round. An example call flow is shown in Appendix B.3.
UAC通常在提供/应答交换期间与策略服务器联系两次（除非策略服务器指示只需联系一次）。因此，在大多数情况下，多个策略服务器向单个UAC提供策略并不需要额外的步骤。但是，UAS通常只与每个策略服务器联系一次（参见图4）。如果其中一个策略服务器返回的会话策略要求在多个服务器之间共享信息，并且UAS从多个策略服务器接收到策略，则UAS必须在第一次联系所有服务器后第二次联系所有策略服务器。是否需要第二轮由策略服务器返回的信息类型决定。会话策略的数据格式（例如，[RFC6796]）需要明确说明特定数据元素是否需要第二轮。如果UA收到这样一个元素，它知道该元素将第二次与策略服务器联系。如果在通话中提供/应答交换期间修改了此类数据元素，并且多个策略服务器正在向UA提供策略，则所有UA必须在第一轮和第二轮中联系策略服务器。附录B.3中给出了一个调用流程示例。
A UA that supports session-specific policies compliant to this specification MUST support the User Agent Profile Data Set for Media Policy [RFC6796] as data format for session policies.
支持符合本规范的会话特定策略的UA必须支持媒体策略[RFC6796]的用户代理配置文件数据集作为会话策略的数据格式。
A UA MUST disclose the session description(s) for the current session to policy servers through the policy channel. The UA MUST apply session policies it receives to the offer and, if one is received, to the answer before using the offer/answer. If these policies are unacceptable, the UA MUST NOT continue with the session. This means that the UA MUST cancel or reject a pending INVITE transaction for
UA必须通过策略通道向策略服务器披露当前会话的会话描述。UA必须将收到的会话策略应用于要约，如果收到，则在使用要约/应答之前应用于应答。如果这些政策不可接受，UA不得继续进行会话。这意味着UA必须取消或拒绝挂起的INVITE事务
the session or terminate the session if it is already in progress. If the UA receives an unacceptable policy in an INVITE response, the UA MUST complete the INVITE transaction and then terminate the session.
会话或终止会话（如果会话已在进行中）。如果UA在INVITE响应中收到不可接受的策略，则UA必须完成INVITE事务，然后终止会话。
When a UA receives a notification about a change in the current policies, the UA MUST apply the updated policies to the current session or the UA MUST terminate the session. If the policy update causes a change in the session description of a session, then the UA needs to renegotiate the modified session description with its peer UA, for example, using a re-INVITE or UPDATE request. For example, if a policy update disallows the use of video and video is part of the current session description, then the UA will need to create an new session description offer without video. After receiving this offer, the peer UA knows that video can't be used any more and responds with the corresponding answer.
当UA收到关于当前策略更改的通知时，UA必须将更新的策略应用于当前会话，或者UA必须终止会话。如果策略更新导致会话的会话描述发生更改，则UA需要与其对等UA重新协商修改后的会话描述，例如，使用重新邀请或更新请求。例如，如果策略更新不允许使用视频，并且视频是当前会话描述的一部分，则UA将需要创建不带视频的新会话描述。收到此报价后，对等UA知道视频不能再使用，并给出相应的回答。
Policy enforcement mechanisms can prevent a UA from communicating with another UA if the UAs are not aware of the policies that are enforced. Policy enforcement mechanisms without policy signaling can therefore create a denial-of-service condition for UAs. This specification provides a mechanism for intermediaries to signal the policies that are enforced to UAs. It enables UAs to establish sessions that are conform and pass through policy enforcement.
如果UA不知道所实施的策略，则策略实施机制可以阻止UA与另一UA通信。因此，没有策略信令的策略实施机制可能会为UAs创建拒绝服务条件。该规范为中介机构提供了一种向UAs发送强制策略信号的机制。它使UAs能够建立符合和通过策略实施的会话。
Session policies can significantly change the behavior of a UA and can be used by an attacker to compromise a UA. For example, session policies can be used to prevent a UA from successfully establishing a session (e.g., by setting the available bandwidth to zero). Such a policy can be submitted to the UA during a session, which causes the UA to terminate the session.
会话策略可以显著改变UA的行为，攻击者可以利用会话策略危害UA。例如，会话策略可用于防止UA成功建立会话（例如，通过将可用带宽设置为零）。这样的策略可以在会话期间提交给UA，从而导致UA终止会话。
A UA transmits session information to a policy server for session-specific policies. This session information can contain sensitive data the user does not want an eavesdropper or an unauthorized policy server to see. Vice versa, session policies can contain sensitive information about the network or service level agreements the service provider does not want to disclose to an eavesdropper or an unauthorized UA.
UA将会话信息传输到特定于会话的策略的策略服务器。此会话信息可能包含用户不希望窃听者或未经授权的策略服务器看到的敏感数据。反之亦然，会话策略可能包含有关网络或服务级别协议的敏感信息，服务提供商不希望向窃听者或未经授权的UA披露这些信息。
It is important to secure the communication between the proxy and the UA (for session-specific policies) as well as the UA and the policy server. The following four discrete attributes need to be protected:
确保代理和UA（针对特定于会话的策略）以及UA和策略服务器之间的通信安全非常重要。需要保护以下四个离散属性：
1. integrity of the policy server URI (for session-specific policies),
1. 策略服务器URI的完整性（对于特定于会话的策略），
2. authentication of the policy server and, if needed, the user agent,
2. 策略服务器和用户代理（如果需要）的身份验证，
3. confidentiality of the messages exchanged between the user agent and the policy server and
3. 用户代理和策略服务器之间交换的消息的机密性，以及
4. ensuring that private information is not exchanged between the two parties, even over a confidentiality-assured and authenticated session.
4. 确保双方之间不交换私人信息，即使是在保密和认证的会话中。
To protect the integrity of the policy server URI, a UA SHOULD use a secured transport protocol such as TLS [RFC5246] between proxies and the UA. Protecting the integrity of the policy server URI is important since an attacker could intercept SIP messages between the UA and the proxy and remove the policy header fields needed for session-specific policies. This would impede the rendezvous between UA and policy server and, since the UA would not contact the policy server, can prevent a UA from setting up a session.
为了保护策略服务器URI的完整性，UA应该在代理和UA之间使用安全传输协议，如TLS[RFC5246]。保护策略服务器URI的完整性非常重要，因为攻击者可以截获UA和代理之间的SIP消息，并删除会话特定策略所需的策略头字段。这将阻碍UA和策略服务器之间的会合，并且由于UA不会联系策略服务器，因此可能会阻止UA设置会话。
Instead of removing a policy server URI, an attacker can also modify the policy server URI and point the UA to a compromised policy server. It is RECOMMENDED that a UA authenticate policy servers to prevent such an attack from being effective.
攻击者还可以修改策略服务器URI并将UA指向受损的策略服务器，而不是删除策略服务器URI。建议UA对策略服务器进行身份验证，以防止此类攻击生效。
It is RECOMMENDED that the UA only accept session-independent policies from trustworthy policy servers as these policies affect all sessions of a UA. A list of trustworthy session-independent policy servers can be provided to the UA through configuration. As SIP messages can be affected by any proxy on a path and session-specific policies only apply to a single session, a UA MAY choose to accept session-specific policies from other policy servers as well.
建议UA仅接受来自可靠策略服务器的会话无关策略，因为这些策略影响UA的所有会话。可通过配置向UA提供可靠的独立于会话的策略服务器列表。由于SIP消息可能受路径上任何代理的影响，并且特定于会话的策略仅适用于单个会话，UA也可以选择从其他策略服务器接受特定于会话的策略。
Policy servers SHOULD authenticate UAs to protect the information that is contained in a session policy. However, a policy server can also frequently encounter UAs it cannot authenticate. In these cases, the policy server MAY provide a generic policy that does not reveal sensitive information to these UAs.
策略服务器应该对UAs进行身份验证，以保护会话策略中包含的信息。但是，策略服务器也可能经常遇到无法进行身份验证的UAs。在这些情况下，策略服务器可以提供不向这些UAs透露敏感信息的通用策略。
It is RECOMMENDED that administrators use SIPS URIs as policy server URIs so that subscriptions to session policies are transmitted over TLS.
建议管理员将SIPS URI用作策略服务器URI，以便通过TLS传输对会话策略的订阅。
The above security attributes are important to protect the communication between the UA and policy server. This document does not define the protocol used for the communication between UA and policy server and merely refers to other specifications for this purpose. The security considerations of these specifications need to address the above security aspects.
上述安全属性对于保护UA和策略服务器之间的通信非常重要。本文件未定义UA和策略服务器之间通信所使用的协议，仅参考其他规范。这些规范的安全考虑需要解决上述安全方面。
Name of Header Field: Policy-ID
标题字段的名称：策略ID
Short form: none
简表：无
Normative description: Section 4.4.5 of this document
规范性说明：本文件第4.4.5节
Name of Header Field: Policy-Contact
标题字段名称：策略联系人
Short form: none
简表：无
Normative description: Section 4.4.5 of this document
规范性说明：本文件第4.4.5节
6.3. Registration of the "non-cacheable" Policy-Contact Header Field Parameter
6.3. “不可缓存”策略联系人标头字段参数的注册
Registry Name: Header Field Parameters and Parameter Values Reference: [RFC3968]
注册表名称：标题字段参数和参数值参考：[RFC3968]
Registry:
注册处：
Header Field Parameter Name Predefined Reference
Values
_____________________________________________________________________
Policy-Contact non-cacheable Yes this document
Header Field Parameter Name Predefined Reference
Values
_____________________________________________________________________
Policy-Contact non-cacheable Yes this document
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of [RFC3261].
根据[RFC3261]第27.1节中的指南，本规范注册了一个新的SIP选项标签。
This document defines the SIP option tag "policy".
本文档定义了SIP选项标签“策略”。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
以下行已添加到SIP参数注册表的“选项标记”部分：
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| policy | This option tag is used to indicate that | this |
| | a UA can process policy server URIs for | document |
| | and subscribe to session-specific | |
| | policies. | |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| policy | This option tag is used to indicate that | this |
| | a UA can process policy server URIs for | document |
| | and subscribe to session-specific | |
| | policies. | |
+------------+------------------------------------------+-----------+
Name of option: policy
选项名称：策略
Description: Support for the Policy-Contact and Policy-ID header fields.
描述：支持策略联系人和策略ID标题字段。
SIP header fields defined: Policy-Contact, Policy-ID
定义的SIP头字段：策略联系人、策略ID
Normative description: This document
规范性说明：本文件
[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月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，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月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", RFC 6080, March 2011.
[RFC6080]Petrie，D.和S.Channabasappa，“会话启动协议用户代理配置文件交付框架”，RFC 60802011年3月。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665]Roach，A.，“SIP特定事件通知”，RFC 66652012年7月。
[RFC6795] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies", RFC 6795, December 2012.
[RFC6795]Hilt，V.和G.Camarillo，“会话特定策略的会话启动协议（SIP）事件包”，RFC 67952012年12月。
[RFC6796] Hilt, V., Camarillo, G., Rosenberg, J., and D. Worley, "A User Agent Profile Data Set for Media Policy", RFC 6796, December 2012.
[RFC6796]Hilt，V.，Camarillo，G.，Rosenberg，J.，和D.Worley，“媒体策略的用户代理配置文件数据集”，RFC 67962012年12月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[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月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[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月。
[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月。
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011.
[RFC6086]Holmberg，C.，Burger，E.，和H.Kaplan，“会话初始化协议（SIP）信息方法和包框架”，RFC 6086，2011年1月。
Many thanks to Allison Mankin, Andrew Allen, Cullen Jennings and Vijay Gurbani for their contributions to this document. Many thanks to Roni Even, Bob Penfield, Mary Barnes, Shida Schubert, Keith Drage, Lisa Dusseault, Tim Polk and Pasi Eronen for their reviews and suggestions.
非常感谢Allison Mankin、Andrew Allen、Cullen Jennings和Vijay Gurbani对本文件的贡献。非常感谢Roni、Bob Penfield、Mary Barnes、Shida Schubert、Keith Drage、Lisa Dusseault、Tim Polk和Pasi Eronen的评论和建议。
The following call flows illustrate the overall operation of session-specific policies including the policy channel protocol as defined in "A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies" [RFC6795].
以下调用流说明了会话特定策略的总体操作，包括“会话特定策略的会话启动协议（SIP）事件包”[RFC6795]中定义的策略通道协议。
The following abbreviations are used:
使用以下缩写：
o: offer
o:报价
o': offer modified by a policy
o”：由策略修改的报价
po: offer policy
po：优惠政策
a: answer
答：回答
a': answer modified by a policy
答：被策略修改的答案
pa: answer policy
答：回答政策
ps uri: policy server URI (in Policy-Contact header field)
ps uri:策略服务器uri（在策略联系人标头字段中）
ps id: policy server id (in Policy-ID header field)
ps id：策略服务器id（在策略id标头字段中）
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE <o> | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY <po> | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id, o'>| | | |
|-------->| | | | |
| |(9) INV <o'> | | |
| |---------------------------->| |
| | | | |(10) INV <o', ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o', a>
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po, pa>
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <a'>
| | | | |<--------|
| |(16) 200 OK <a'> | | |
| |<----------------------------| |
|(17) 200 OK <a'> | | | |
|<--------| | | | |
|(18) ACK | | | | |
|------------------------------------------------>|
|(19) SUBSCRIBE <o', a'> | | |
|------------------>| | | |
|(20) 200 OK | | | |
|<------------------| | | |
|(21) NOTIFY <po, pa> | | |
|<------------------| | | |
|(22) 200 OK | | | |
|------------------>| | | |
| | | | | |
| | | | | |
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE <o> | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY <po> | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id, o'>| | | |
|-------->| | | | |
| |(9) INV <o'> | | |
| |---------------------------->| |
| | | | |(10) INV <o', ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o', a>
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po, pa>
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <a'>
| | | | |<--------|
| |(16) 200 OK <a'> | | |
| |<----------------------------| |
|(17) 200 OK <a'> | | | |
|<--------| | | | |
|(18) ACK | | | | |
|------------------------------------------------>|
|(19) SUBSCRIBE <o', a'> | | |
|------------------>| | | |
|(20) 200 OK | | | |
|<------------------| | | |
|(21) NOTIFY <po, pa> | | |
|<------------------| | | |
|(22) 200 OK | | | |
|------------------>| | | |
| | | | | |
| | | | | |
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV | | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id> | | | |
|-------->| | | | |
| |(9) INV | | | |
| |---------------------------->| |
| | | | |(10) INV <ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o> |
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po> |
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <o'>
| | | | |<--------|
| |(16) 200 OK <o'> | | |
| |<----------------------------| |
|(17) 200 OK <o'> | | | |
|<--------| | | | |
|(18) SUBSCRIBE <o', a> | | |
|------------------>| | | |
|(19) 200 OK | | | |
|<------------------| | | |
|(20) NOTIFY <po, pa> | | |
|<------------------| | | |
|(21) 200 OK | | | |
|------------------>| | | |
|(22) ACK <a'> | | | |
|------------------------------------------------>|
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV | | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id> | | | |
|-------->| | | | |
| |(9) INV | | | |
| |---------------------------->| |
| | | | |(10) INV <ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o> |
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po> |
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <o'>
| | | | |<--------|
| |(16) 200 OK <o'> | | |
| |<----------------------------| |
|(17) 200 OK <o'> | | | |
|<--------| | | | |
|(18) SUBSCRIBE <o', a> | | |
|------------------>| | | |
|(19) 200 OK | | | |
|<------------------| | | |
|(20) NOTIFY <po, pa> | | |
|<------------------| | | |
|(21) 200 OK | | | |
|------------------>| | | |
|(22) ACK <a'> | | | |
|------------------------------------------------>|
| | | |(23) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(24) 200 OK |
| | | |------------------>|
| | | |(25) NOTIFY <po, pa>
| | | |------------------>|
| | | |(26) 200 OK |
| | | |<------------------|
| | | | | |
| | | | | |
| | | |(23) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(24) 200 OK |
| | | |------------------>|
| | | |(25) NOTIFY <po, pa>
| | | |------------------>|
| | | |(26) 200 OK |
| | | |<------------------|
| | | | | |
| | | | | |
UA A P A PS A PS B P B UA B
| | | | | |
| | | | | |
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
| |(2) INV <o, uri PSA> | |
| |---------------------------->| |
| | | | |(3) INV <o, uri PSA, uri PSB>
| | | | |-------->|
| | |(4) SUBSCRIBE <o, a> |
| | |<----------------------------|
| | |(5) 200 OK | |
| | |---------------------------->|
| | |(6) NOTIFY <po, pa>| |
| | |---------------------------->|
| | |(7) 200 OK | |
| | |<----------------------------|
| | | |(8) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(9) 200 OK |
| | | |------------------>|
| | | |(10) NOTIFY <po, pa>
| | | |------------------>|
| | | |(11) 200 OK |
| | | |<------------------|
| | |(12) SUBSCRIBE <o", a"> |
| | |<----------------------------|
| | |(13) 200 OK | |
| | |---------------------------->|
| | |(14) NOTIFY <po, pa> |
| | |---------------------------->|
| | |(15) 200 OK | |
| | |<----------------------------|
| | | |(16) SUBSCRIBE <o", a">
UA A P A PS A PS B P B UA B
| | | | | |
| | | | | |
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
| |(2) INV <o, uri PSA> | |
| |---------------------------->| |
| | | | |(3) INV <o, uri PSA, uri PSB>
| | | | |-------->|
| | |(4) SUBSCRIBE <o, a> |
| | |<----------------------------|
| | |(5) 200 OK | |
| | |---------------------------->|
| | |(6) NOTIFY <po, pa>| |
| | |---------------------------->|
| | |(7) 200 OK | |
| | |<----------------------------|
| | | |(8) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(9) 200 OK |
| | | |------------------>|
| | | |(10) NOTIFY <po, pa>
| | | |------------------>|
| | | |(11) 200 OK |
| | | |<------------------|
| | |(12) SUBSCRIBE <o", a"> |
| | |<----------------------------|
| | |(13) 200 OK | |
| | |---------------------------->|
| | |(14) NOTIFY <po, pa> |
| | |---------------------------->|
| | |(15) 200 OK | |
| | |<----------------------------|
| | | |(16) SUBSCRIBE <o", a">
| | | |<------------------|
| | | |(17) 200 OK |
| | | |------------------>|
| | | |(18) NOTIFY <po, pa>
| | | |------------------>|
| | | |(19) 200 OK |
| | | |<------------------|
| | | | |(20) 200 OK <a">
| | | | |<--------|
| |(21) 200 OK <a"> | | |
| |<----------------------------| |
|(22) 200 OK <a"> | | | |
|<--------| | | | |
|(23) ACK | | | | |
|------------------------------------------------>|
| | | | | |
| | | | | |
| | | |<------------------|
| | | |(17) 200 OK |
| | | |------------------>|
| | | |(18) NOTIFY <po, pa>
| | | |------------------>|
| | | |(19) 200 OK |
| | | |<------------------|
| | | | |(20) 200 OK <a">
| | | | |<--------|
| |(21) 200 OK <a"> | | |
| |<----------------------------| |
|(22) 200 OK <a"> | | | |
|<--------| | | | |
|(23) ACK | | | | |
|------------------------------------------------>|
| | | | | |
| | | | | |
Authors' Addresses
作者地址
Volker Hilt Bell Labs/Alcatel-Lucent Lorenzstrasse 10 70435 Stuttgart Germany
沃尔克希尔特贝尔实验室/德国斯图加特阿尔卡特朗讯洛伦茨特拉斯10 70435
EMail: volker.hilt@bell-labs.com
EMail: volker.hilt@bell-labs.com
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
Jonathan Rosenberg jdrosen.net Monmouth, NJ USA
Jonathan Rosenberg jdrosen.net美国新泽西州蒙茅斯
EMail: jdrosen@jdrosen.net
EMail: jdrosen@jdrosen.net