[要約] RFC 6794は、SIPセッションポリシーのためのフレームワークであり、SIPセッションの制御と管理を目的としています。このRFCは、SIPベースの通信システムのセキュリティとパフォーマンスを向上させるためのガイドラインを提供します。
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.
プロキシサーバーは、コールルーティング、ランデブー、その他の通話機能に関するポリシーを定義して影響を与えるため、Session Initiation Protocol（SIP）の仲介者として中心的な役割を果たします。このドキュメントでは、使用するコーデックやメディアタイプなど、プロキシがセッションのポリシーを定義または影響できる標準メカニズムを提供するSIPセッションポリシーのフレームワークを指定します。セッションポリシーのモデル、全体的なアーキテクチャ、および新しいプロトコルメカニズムを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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アドレスとポートに送信する必要があることをユーザーエージェントに伝えたいと考えています。このポリシーを知っていると、ユーザーエージェントはファイアウォールまたはネットワーク境界を越えてセッションをセットアップできます。メディア仲介を挿入する他の方法とは異なり、セッションポリシーの使用では、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.
セッションポリシーには、セッション固有のポリシーとセッションに依存しないポリシーの2種類があります。セッション固有のポリシーは、そのセッションのセッション記述に基づいて、特定のセッション用に作成されるポリシーです。これにより、ネットワーク仲介者は、UAが提案しているセッションの説明を調べ、そのセッションの説明に特化したポリシーを返すことができます。たとえば、仲介者は、提案されたセッションの説明にある各メディアストリームのファイアウォール/ NATにピンホールを開く可能性があります。次に、UAのIPアドレスとポートをファイアウォール/ NATで開かれている外部から到達可能なものと置き換えるセッション記述のポリシーを返すことができます。セッション固有のポリシーは、ドメインへの特定のセッションに関する情報を提供します。これは、ファイアウォール/ 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セッションポリシーのフレームワークを定義します。これは、モデル、全体的なアーキテクチャ、およびセッションに依存しないポリシーとセッション固有のポリシーに必要な新しいプロトコルメカニズムを指定します。セッション固有のポリシーとセッション独立のポリシーには異なる要件があるため、この仕様では、ユーザーエージェントにポリシーを配信するための2つの異なるメカニズムを定義しています。これらのメカニズムは互いに独立しており、1つまたは両方のタイプのセッションポリシーが必要かどうかに応じて、セッション固有またはセッション非依存のメカニズム、あるいはその両方を使用して、ポリシーをユーザーエージェントに配信できます。
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.
エンドポイントにセッションポリシーをシグナリングするために、UAと仲介者がこの仕様で定義されたメカニズムを使用することをお勧めします。この仕様をサポートしないUAとの下位互換性を確保するために、仲介者は、UAがセッションポリシーのサポートを示さない場合、フォールバックソリューションとして488応答にポリシーに準拠しないセッションを拒否するなど、既存のメカニズムに頼ることを選択できます。セッションポリシーをサポートしていないUAは、現在と同じユーザーエクスペリエンスを受け取ります。これらの手法には多くの欠点があることが知られているため、UAと仲介者は、この仕様で定義されているメカニズムを使用して、ポリシーの明示的なシグナリングを使用することをお勧めします。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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 |
+-------------+
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 (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.
SIP UAは、1つ以上のポリシーサーバーからセッションに依存しないポリシーを受信できます。典型的な構成では、UAは、ローカルネットワークドメイン（つまり、UAがIPサービスを受信するドメイン）のポリシーサーバーからセッションに依存しないポリシーを受信し、場合によってはSIPサービスプロバイダードメイン（つまり、UAがアクセスするドメイン）を受信します。レジスタ）。ローカルネットワークには、アクセスネットワークインフラストラクチャをサポートするポリシーを設定できます。たとえば、帯域幅が不足しているワイヤレスネットワークでは、プロバイダーは個々のユーザーが使用できる帯域幅を制限できます。 SIPサービスプロバイダーは、サービスをサポートするために必要なポリシー、またはユーザーとのサービスレベル契約を反映するポリシーを持つことができます。したがって、ほとんどの場合、UAはセッションに依存しないポリシーを1つまたは2つのポリシーサーバーから受信します。
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は、ドメインがセッションに依存しないことをUAが（たとえば、構成を通じて）知らない限り、ローカルネットワークおよびSIPサービスプロバイダードメインからセッションに依存しないポリシーを取得しようとする必要があります。ポリシー（この場合、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-profile」イベントパッケージを使用して、ローカルネットワークおよび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-profile」イベントパッケージ[RFC6080]は、セッションに依存しないポリシーをサブスクライブするメカニズムを提供します。 UAは、「local-network」プロファイルタイプに定義された手順を使用して、ローカルネットワークドメインのポリシーサーバーにサブスクライブします。 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は、「local-network」プロファイルタイプのすべての既存のサブスクリプションを終了する必要があります。次に、UAは、 "local-network"プロファイルタイプを使用して、維持する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はこのサブスクリプションを再試行しないでください。これは、セッションに依存しないポリシーをサポートしないドメイン内で送信されるSUBSCRIBEリクエストの数を制限するためです。ただし、UAはサブスクリプションをより長い時間間隔で再試行する必要があります（たとえば、24時間ごとに1回）。これにより、UAは、以前はポリシーを持っていなかったネットワークに展開された新しいポリシーを検出できます。
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はSUBSCRIBEリクエストのAcceptヘッダーフィールドに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はこれらのポリシーを提供したドメインを変更しない限り、セッションをセットアップしてはなりません（MUST NOT）。 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に通知を送信できます（MAY）。ポリシーを変更する原因の定義は、管理者の裁量に委ねられています。ポリシーの変更は、たとえば、ネットワークステータスの変更、時刻の変更、または顧客とのサービスレベル契約の更新によってトリガーできます。
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の1つの特定のセッション用に特別に作成されたポリシーです。したがって、セッション固有のポリシーは通常、セッションごとに異なります。セッションのセッション固有のポリシーは、セッション中に変更される可能性があります。たとえば、ユーザーがセッション中にクレジットを使い果たす可能性があります。これにより、ネットワークはこの時点以降のすべてのメディアストリームの送信を許可しなくなります。
domain 1
+-----------+
/------| proxy |----...
+----+ / +-----------+
| |---/ +-----------+
| | | policy |
| UA |============| server |
| | +-----------+
| |**** +-----------+
+----+ * | policy |
*******|enforcement|****...
+-----------+
--- 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.
プロキシの役割は、UAとポリシーサーバーにランデブーメカニズムを提供することです。これにより、各UAがドメイン内のポリシーサーバーのURI [RFC3986]を持ち、どこからポリシーを取得するかを確実に把握できます。プロキシは、ポリシーサーバーのURIをまだ受け取っていない場合に備えて（たとえば、以前の呼び出しで、または構成を通じて）、UAに伝達します。プロキシは実際のポリシーをUAに配信しません。
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.
ポリシーサーバーは、プロキシと物理的に同じ場所に配置できる独立した論理エンティティです。ポリシーサーバーの役割は、セッションポリシーをUAに配信することです。ポリシーサーバーは、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 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シグナリングとポリシーの交換を明確に分離しています。 SIPシグナリングは、UAをポリシーサーバーとランデブーするためにのみ使用されます。この時点から、UAとポリシーサーバーは、個別のポリシーチャネルを介して相互に直接通信します。これは、ネットワーク内のエンドポイントとポリシーサーバー間のポリシー情報の交換が、エンドポイント間で交換される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:
このモデルに従って、セッション固有のポリシーのシグナリングには、次の2つの基本的なタスクが含まれます。
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.
このセクションでは、セッション固有のポリシーの全体的な動作を示す2つの例を示します。コールフローは、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.
この例は次のシナリオに基づいています。2つのドメイン（ドメインAとドメインB）があり、どちらのドメインにもUAのセッション固有のポリシーがあります。どちらのドメインも、自身のドメイン外のUAにポリシーを提供しません。 2つのドメインには、プロキシ（プロキシ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 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.
（1）UA AはINVITE要求をプロキシAに送信します。プロキシAはポリシーがこのセッションに適用されることを認識し、（2）488（Not Acceptable Here）応答をUA Aに返します。プロキシAはPS AのURIを488に含めます（ここでは受け入れられません）応答。 UACはPS AのURIを事前に認識していないため、この手順が必要です。（3）UA AはURIを使用してPS Aに連絡し、セッション記述オファーをPS Aに開示し、（4）オファーのポリシーを受信します。 （5）UA Aは、受信したポリシーを考慮してINVITE要求を再定式化し、PS-Aにすでに接続していることを示すPolicy-IDヘッダーフィールドを含めます。プロキシAは今回はINVITE要求を拒否せず、Policy-IDヘッダーを削除しますINVITEリクエストを転送するときのフィールド。プロキシBは、PS BのURIを含むPolicy-Contactヘッダーフィールドを追加します。（6）UA Bは、このURIを使用してPS Bにアクセスし、送信しようとしているオファーと回答を開示します。 （7）UA BはPS Bからポリシーを受け取り、それらをオファーとアンサーにそれぞれ適用します。 （8）UA Bは更新された回答を200（OK）応答で返します。 （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)
| | | |
| | | |
| 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がオファーなしでINVITE要求をプロキシAに送信し、（2）プロキシAがPS AのURIを含む488（Not Acceptable Here）応答を返します。（3）、（4）UA Aはこのポリシーサーバーを使用しますポリシーチャネルを設定するためのURI。現時点では、UA Aはまだオファーを提供していないため、セッションの説明を開示しません。 （5）UA AはINVITE要求を再送信し、PS Aに接続したことを示すためのPolicy-IDヘッダーフィールドを含めます。プロキシAは今回はINVITE要求を拒否せず、INVITEを転送するときにPolicy-IDヘッダーフィールドを削除しますリクエスト。プロキシBは、PS BのURIを含むPolicy-Contactヘッダーフィールドを追加します。（6）UA Bは、このURIを使用して、PS Bにオファーを開示します。 （8）UA Bは更新されたオファー200（OK）応答を返します。 （9）、（10）UA AはPSに連絡し、オファーおよび送信しようとしている回答を開示します。前の例のフローとの重要な違いは、UA Aがステップ（11）の回答を返す前にステップ（9）と（10）を実行することです。これにより、UA Aは、該当するすべてのポリシーを含むACKリクエストで最終的な回答を返すことができます。ただし、PS Aは、ACK要求の送信の遅延を回避するためにポリシーをすぐに返す必要があります。 （12）、（13）UA Bは現在のオファーとアンサーをPS 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)
| | | |
| | | |
| | | 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.
セッション固有のポリシーを設定する最初のステップは、UAを関連するポリシーサーバーとランデブーすることです。これは、セッションに関連するすべてのポリシーサーバーのURIをUAに提供することで実現されます。
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]を開始できるすべてのリクエスト（たとえば、INVITE、UPDATE [RFC3311]、およびPRACK [RFC3262]リクエスト）に、オプションタグ「policy」を持つサポートヘッダーフィールドを含める必要があります。 。特定のリクエストにオファーまたはアンサーが含まれていない場合でも（例：オファーのないINVITEリクエスト）、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は、Policy-Contactヘッダーフィールドを含む488（Not Acceptable Here）応答を受信できます。 Policy-Contactヘッダーフィールドは、この仕様で定義されている新しいヘッダーフィールドです。これには、ポリシーサーバーの1つ（または複数の代替）URIが含まれます。このヘッダーフィールドを持つ488（Not Acceptable Here）応答は、ローカルポリシーサーバーのURIをUACに伝えるためにプロキシによって生成されます。 Policy-Contactヘッダーフィールドを含む488（Not Acceptable Here）応答を受け取った後、この仕様に準拠するUACは、ポリシーサーバーが存在することを認識してセッションを続行するかどうかを決定する必要があります。 UACが続行することを決定した場合、UACは、ポリシーサーバーURIの1つを使用して、セクション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 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.
Policy-Contactヘッダーには、それぞれが異なるURIスキームを持ち、同一の値を持つ「alt-uri」パラメーターを含む複数のURIを含めることができます。これらのURIは、同じポリシーを取得するための代替ポリシーチャネルメカニズムを表します。 UACは、ポリシーの取得に使用する代替URIの1つを選択します。 UACは、どのURIを使用するかについての優先順位を示すものとして、代替URIの順序をヒントとして使用できます（MAY）。リストの最上位の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は要求を再送信してはなりません（MUST NOT）。
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.
Policy-ContactヘッダーフィールドのポリシーサーバーURIの整合性を保護するために、UACは、UACとプロキシの間でTransport Layer Security（TLS）[RFC5246]などのセキュアなトランスポートプロトコルを使用する必要があります（SHOULD）。
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は、ポリシーサーバーに接続し、受信したポリシーを受け入れた要求に、Policy-IDヘッダーフィールドを挿入する必要があります。 Policy-IDヘッダーフィールドは、この仕様で定義されている新しいヘッダーフィールドです。 UAは、リクエストの準備中に接続した各ポリシーサーバーのPolicy-IDヘッダーフィールド値を作成する必要があります。 Policy-IDヘッダーフィールドの値には、ポリシーサーバーURIとオプションのトークンの2つの情報が含まれています。ポリシーサーバーURIは、UAがポリシーサーバーに接続するために使用したURIです。トークンは、UACがポリシーサーバーから受信できる不透明な文字列です。トークンは、たとえば、ポリシードキュメント[RFC6796]に含めることができます。 UACがポリシーサーバーからトークンを受信した場合、UACはトークンをPolicy-IDヘッダーフィールドに含める必要があります。 Policy-IDヘッダーフィールドの形式は、セクション4.4.5で定義されています。
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.
Policy-IDヘッダーフィールドの主な目的は、UACがローカルポリシーサーバーのURIを既に認識しているかどうかをプロキシが判断できるようにすることです。ポリシーサーバーのURIがまだUACに認識されていない場合、プロキシは、488（Not Acceptable Here）応答で要求を拒否することにより、この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 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.
場合によっては、要求がセッションポリシーサーバーを使用して複数のドメインを通過することがあります。これらの各ドメインは、ポリシーサーバーURIを含む488（Not Acceptable Here）応答を返すことができます。 UACは、ドメインから488（Not Acceptable Here）応答を受信した後、要求を再送信する前に、ポリシーサーバーに接続します。これにより、複数のドメイン内のポリシーサーバー間に暗黙的な順序が作成されます。つまり、UACは最初のポリシーサーバーに接続し、変更された要求を再送信し、2番目のポリシーサーバーに接続し、変更された要求を再送信します。このように、セッションポリシーは常に、要求がドメインを通過する順序で要求に適用されます。 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（Not Acceptable Here）応答でローカルポリシーサーバーURIの再送信を回避するために、UAはローカルドメインのポリシーサーバーのURIを含むキャッシュを維持する必要があります（セクション4.4.4を参照）。 UACは、キャッシュされたポリシーサーバーURIを使用してローカルポリシーサーバーに接続してから、新しいセッションのオファー/アンサー交換を開始するリクエスト（INVITEリクエストなど）を送信する必要があります（SHOULD）。 UACは、最初に返されたポリシーサーバーURIであっても、UACとは異なるドメインにあるポリシーサーバーURIをキャッシュするべきではありません（SHOULD NOT）。ローカルドメインにポリシーサーバーがない場合、返される最初のポリシーサーバー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.
UAは、たとえばINVITE、UPDATE、またはPRACKリクエストで後続のオファー/アンサー交換を開始することにより、セッション中にセッションの説明を再ネゴシエートできます。そのようなダイアログ中のリクエストを作成するとき、UAはリクエストを送信する前に、最初のオファー/アンサー交換（セクション4.5を参照）中にポリシーチャネルを確立したすべてのポリシーサーバーに連絡する必要があります（SHOULD）。これにより、ダイアログ中の要求に対する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).
プロキシは、UAおよびポリシーサーバーにランデブー機能を提供します。これは、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 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).
オファー/アンサー交換開始リクエストにオプションタグ「policy」が付いたSupportedヘッダーフィールドが含まれている場合、プロキシは488（Not Acceptable Here）応答でリクエストを拒否して、UACにローカルポリシーサーバーURIを提供できます（MAY）。リクエストを拒否する前に、プロキシは、リクエストにローカルポリシーサーバーURIを値として持つPolicy-IDヘッダーフィールドが含まれていないことを確認する必要があります。リクエストにそのようなヘッダーフィールドが含まれていない場合、またはローカルポリシーサーバーURIがこのヘッダーフィールドに存在しない場合、プロキシは488（Not Acceptable Here）応答でリクエストを拒否できます（MAY）。プロキシは、関連付けられたポリシーサーバーの1つ（または複数）のURIを含む488（Not Acceptable Here）応答にPolicy-Contactヘッダーフィールドを挿入する必要があります。プロキシは、ヘッダーフィールドパラメータ「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」パラメータを含める必要があります。 「alt-uri」パラメータには、すべての代替ポリシーサーバーURIが関連するドメインのドメイン名または完全修飾ドメイン名（FQDN）（たとえば、ポリシーサーバーのホスト名）のいずれかを含める必要があります。同じポリシーの代替であるすべてのURIは、「alt-uri」パラメーターに同じ値を持っている必要があります。 「alt-uri」パラメーターに使用される値は、同じドメインまたは別のドメイン内の他のプロキシーがUAに連絡する必要がある他のポリシーサーバーURIに同じ値が含まれないようにする必要があります。新しい一意の「alt-uri」パラメータ値を作成する方法は、既存の「alt-uri」パラメータの値を調べて、新しい値が異なることを確認することです。プロキシは、他の代替URIよりもリストの上位にある優先URIを含めることにより、使用するURIに関する設定でUAにヒントを与えることができます（MAY）。同じ「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.
ローカルポリシーサーバーURIがリクエストのPolicy-IDヘッダーフィールド値に存在する場合、プロキシは上記のようにリクエストを拒否してはなりません（他の理由でリクエストを拒否する可能性があります）。プロキシは、リクエストを転送する前に、関連付けられたポリシーサーバーのPolicy-IDヘッダーフィールド値をPolicy-IDヘッダーフィールドから削除する必要があります（SHOULD）。 Policy-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.
Policy-IDヘッダーフィールドは2つの主な目的に使用されます。1つ目と最も重要なことは、UACがローカルポリシーサーバーのURIをUACがすでに知っているかどうかをプロキシが判断できるようにすることです。 Policy-IDヘッダーフィールドの2番目の目的は、ドメインが同じセッションに属するすべてのリクエスト（つまり、最初のリクエストと、ポリシーサーバーに接続した後に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.
同じセッションに属するすべてのリクエストを同じプロキシにルーティングするには、Policy-IDヘッダーフィールドトークンを使用します。ポリシーサーバーは、特定のプロキシ/ポリシーサーバーの組み合わせを一意に識別するトークンをUACに返す必要があります。 UACは、このトークンをPolicy-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.
注：UACが実際にポリシーサーバーに接続したことを示すプロキシのヒントを提供するために、Policy-IDヘッダーフィールドを使用することが提案されています。この使用方法では、ポリシーサーバーがトークンをUAに返すことも必要です。さらに、ポリシーサーバーは有効なトークンをプロキシと共有する必要があります。プロキシは、Policy-IDヘッダーフィールドを含むリクエストを受信した後、Policy-IDヘッダーフィールドのトークンが有効かどうかを判断できます。有効な場合、プロキシはUAがこのセッションのポリシーサーバーに接続したことを認識しています。ただし、このトークンは、UAがポリシーサーバーから受け取ったポリシーを実際に使用したことを証明するものではありません。悪意のあるUAは、単にポリシーサーバーに接続し、受け取ったすべてのポリシーを破棄し、Policy-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.
プロキシは、ポリシーサーバーのURIをUASに伝えるために、INVITE、UPDATE、またはPRACKリクエスト（またはオファー/アンサー交換を開始できるその他のリクエスト）にPolicy-Contactヘッダーフィールドを挿入してもよい（MAY）。リクエストにすでにPolicy-Contactヘッダーフィールドが含まれている場合、プロキシはリストの最後にあるすべての既存の値の後にURIを挿入する必要があります。プロキシは、既存のPolicy-Contactヘッダーフィールド値の順序を変更してはなりません（MUST NOT）。
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.
プロキシは、関連付けられたポリシーサーバーがダイアログ中のリクエストに適用されるセッションポリシーを持っている場合、レコードルートメカニズム[RFC3261]を使用する必要があります。 Record-Routeヘッダーフィールドにより、プロキシはシグナリングパスに留まり、オファー/アンサー交換を開始する中間ダイアログリクエスト中にポリシーサーバーURIをUAに再送信できます。ポリシーサーバーのURIをUAに再送信すると、UAがダイアログボックスの途中の要求についてポリシーサーバーに接続し続けることが保証されます。
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.
プロキシは、応答のサポートされているヘッダーフィールドを調べることにより、UASがこの拡張機能をサポートしているかどうかを確認できます。応答のSupportedヘッダーフィールドにオプションタグ「policy」が含まれている場合、プロキシはUASがこの拡張をサポートしていることを認識しています。プロキシはこの情報を使用して、UASがリクエストに挿入したPolicy-Contactヘッダーフィールドを理解しているかどうかを判断できます。
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.
Policy-ContactヘッダーフィールドのポリシーサーバーURIの整合性を保護するために、プロキシは、プロキシとUAの間でTLS [RFC5246]などのセキュアなトランスポートプロトコルを使用する必要があります（SHOULD）。
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は、ポリシーサーバーURIのリストを含むPolicy-Contactヘッダーフィールドを含むINVITE、UPDATE、またはPRACK要求（またはオファー/アンサー交換を開始できる別の要求）を受信できます。このような要求を受信したUASは、ポリシーサーバーが関与していることを認識して、セッションを受け入れるかどうかを決定する必要があります。 Policy-Contactヘッダーに複数のURIが含まれ、それぞれに異なるURIスキームがあり、同じ値の「alt-uri」パラメーターが含まれている場合、これらのURIスキームは、同じポリシーを取得するための代替ポリシーチャネルメカニズムを表します。 UASがセッションを受け入れる場合、UASは、ポリシーを取得するために、同一の「alt-uri」パラメーター値を持つ各URIグループから1つのURIに接続する必要があります。 UASは、どのURIを使用するかについての優先順位を示すものとして、代替URIの順序をヒントとして取る場合があります。リストの最上位のURIは、ポリシーを取得するために使用するプロキシのドメインにより優先される場合があります。 UASは、代替URIのグループの一部ではないPolicy-Contactヘッダーフィールド内のすべてのポリシーサーバーURIに接続する必要があり、代替URIの各グループ内の1つのURIに接続する必要があります。 UASは、最上位の値（つまり、最初に挿入された値）から始めて、Policy-Contactヘッダーフィールドに含まれている順序でこれらのポリシーサーバー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.
関係するポリシーサーバーが存在するため、またはポリシーサーバーから受信したセッションポリシーの1つが受け入れられないために、UASがセッションを受け入れたくないと判断した場合、UASは488（Not Acceptable Here）応答で要求を拒否する必要があります。
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で解決できないエラー条件（つまり、たとえば、401（無許可）応答以外のエラー条件）。これは、ポリシーサーバーの障害が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はPolicy-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は、すべての応答にこのオプションタグを含めることができます。このようにして、Policy-Contactヘッダーフィールドを挿入したプロキシは、ヘッダーフィールドが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を含むキャッシュを維持する必要があります（SHOULD）。
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は、要求のPolicy-Contactヘッダーフィールドまたは488（Not Acceptable Here）応答でこのURIを受信できます。 UAは、構成フレームワーク[RFC6080]などを介して、構成を通じてローカルポリシーサーバーURIを受信することもできます。 UAが構成を通じてローカルポリシーサーバーURIを受信し、Policy-Contactヘッダーフィールドで別のローカルポリシーサーバーURIを受信した場合、UAは、構成されたURIをPolicy-Contactヘッダーフィールドで受信した最新のもので上書きする必要があります（SHOULD）。キャッシュされたURIの最大有効期間に達する前に更新されていない場合、Policy-Contactヘッダーフィールドで受信したポリシーサーバー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をキャッシュしてはなりません（MUST NOT）。 UAは、「キャッシュ不可」とマークされているローカルポリシーサーバーURIを受信したときに、現在のURIをキャッシュから削除する必要があります（SHOULD）。これは、古いポリシーサーバー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をキャッシュしてはいけません（SHOULD NOT）。これらのポリシーサーバーは、異なるドメインを通過する別の宛先に移動できる後続のセッションに関連する必要はありません。
The UA MUST NOT cache tokens it has received from a policy server. A token is only valid for one request.
UAは、ポリシーサーバーから受信したトークンをキャッシュしてはなりません（MUST NOT）。トークンは1つのリクエストに対してのみ有効です。
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によって、Policy-IDヘッダーフィールドがINVITE、UPDATE、またはPRACKリクエスト（またはオファー/アンサー交換の開始に使用できるその他のリクエスト）に挿入されます。 Policy-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.
Policy-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]:
Policy-IDヘッダーフィールドの構文は、[RFC5234]に従って、[RFC3261]のSIPのABNFの拡張として、以下のABNFで説明されています。
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.
Policy-Contactヘッダーフィールドは、プロキシによって、INVITE、UPDATE、またはPRACKリクエスト（またはオファー/アンサー交換を開始する他のリクエスト）への488（Not Acceptable Here）応答に挿入できます。 Policy-Contactヘッダーフィールドの値は、ポリシーサーバーURIとオプションの「キャッシュ不可」ヘッダーフィールドパラメータで構成されます。ポリシーサーバーURIは、UACが接続する必要のあるポリシーサーバーを識別します。 「キャッシュ不可」ヘッダーフィールドパラメータは、ポリシーサーバーURIがUACによってキャッシュされることを意図していないことを示します。
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.
Policy-Contactヘッダーフィールドは、プロキシによってINVITE、UPDATE、およびPRACKリクエスト（またはオファー/アンサー交換の開始に使用できるその他のリクエスト）に挿入することもできます。 UASがアクセスする必要があるポリシーサーバーURIの順序付きリストが含まれています。このリストの一番上の値は、最初に接続されるポリシーサーバーを識別します。新しいヘッダーフィールド値が最後に挿入されます。これにより、Policy-Contactヘッダーフィールドは、フィストインファーストアウトキューを効果的に形成します。
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]: Policy-Contact = "Policy-Contact" HCOLON policyContact-info *(COMMA policyContact-info)
Policy-Contactヘッダーフィールドの構文は、[RFC5234]に従って、[RFC3261]のSIPのABNFの拡張として、以下のABNFで説明されています。Policy-Contact = "Policy-Contact" HCOLON policyContact-info *（COMMA policyContact-info）
policyContact-info = LAQUOT policyContact-uri RAQUOT *( SEMI policyContact-param )
policyContact-info = LAQUOT policyContact-uri RAQUOT *（SEMI policyContact-param）
policyContact-uri = ( SIP-URI / SIPS-URI / absoluteURI )
policyContact-param = ( "non-cacheable" / policyContact-alt-uri
/ generic-param )
policyContact-alt-uri = "alt-uri" EQUAL hostname
policyContact-alt-uri = "alt-uri" EQUALホスト名
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」はUPDATEメソッド[RFC3311]、「SUB」はSUBSCRIBEメソッド[RFC6665]、 「NOT」はNOTIFYメソッド[RFC6665]、「MSG」はMESSAGEメソッド[RFC3428]、「REF」はREFERメソッド[RFC3515]、「PUB」はPUBLISHメソッド[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 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 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.
セッション固有のポリシーのイベントパッケージ[RFC6795]は、SUBSCRIBE / NOTIFYベースの[RFC6665]ポリシーチャネルメカニズムを定義しています。この仕様に準拠するUAは、セッション固有のポリシーのイベントパッケージをサポートする必要があります[RFC6795]。ポリシーサーバーURIがSIP-URIまたはSIPS-URIである場合、UAはこのイベントパッケージを使用してポリシーサーバーに接続する必要があります。 UAは他のポリシーチャネルメカニズムをサポートしてもよい（MAY）。
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は、ダイアログ中の要求への応答として、新しいポリシーサーバーURIを含むPolicy-Contactヘッダーフィールドを含む488（Not Acceptable Here）応答を受信できます。これは、現在のセッションに関連するポリシーサーバーのセットが変更されたことを示しています。これが発生した場合、UACは、ダイアログの最初のリクエストであるかのように（つまり、ローカルポリシーサーバーからのポリシー以外のポリシーを適用せずに）リクエストの送信を再試行する必要があります。このようにして、UACは現在のセッションのポリシーサーバーのリストを再検出します。 UACは、新しく検出されたポリシーサーバーにいつ接続するか、および既存のポリシーサーバーと比較して、既存のポリシーサーバーのいずれにも接続する必要がないかどうかを知る方法がないため、これが必要です。 UACは、新しいポリシーサーバーごとにポリシーチャネルを設定する必要があります。 UACは、リストされなくなったポリシーサーバーへのポリシーチャネルを閉じる必要があります（SHOULD）。これらのサーバーへのポリシーチャネルが閉じられていない場合、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が、UASが現在ポリシーチャネルを確立しているポリシーサーバーのリストとは異なるポリシーサーバーURIのリストを含むPolicy-Contactヘッダーフィールドを含むダイアログ中のリクエストを受信した場合、UASは、すべての新しいポリシーサーバーへのポリシーチャネル。 UASは、リストされなくなったサーバーへのポリシーチャネルを閉じる必要があります（SHOULD）。これらのサーバーへのポリシーチャネルが閉じていない場合、UASはセッションに適用されなくなったポリシーを受信できます。 UASは、最新のPolicy-Contactヘッダーフィールドに含まれている順序でポリシーサーバーを使用する必要があります。
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は、ダイアログ中の要求を送信する前または受信した後に、ポリシーチャネルを確立したすべてのポリシーサーバーに接続する必要があります。 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]に従って）完全に処理する必要があります（SHOULD）。メッセージの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要求を作成する必要があります。つまり、このメッセージのSIP機構を完了する前に、オファー/アンサーを使用する必要があります。たとえば、INVITEリクエストへの応答でオファーを受け取ったUACは、ACKリクエストで回答を送信する前に、オファーと回答にポリシーを適用する必要があります。このような場合、UAは、SIPメッセージの処理中であっても、ポリシーサーバーに接続する必要があります（SHOULD）。これは、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にポリシーを提供する場合は、追加の考慮事項が必要です。 1つのポリシーサーバーによって返されるポリシーには、他のポリシーサーバーと共有する必要がある情報を含めることができます。たとえば、2つのポリシーサーバーは、メディアストリームの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は通常、オファー/アンサーの交換中にポリシーサーバーに2回接続します（ポリシーサーバーが1回のみ接続する必要があることを示さない限り）。したがって、単一のUACにポリシーを提供する複数のポリシーサーバーの場合、ほとんどの場合、追加の手順は必要ありません。ただし、UASは通常、各ポリシーサーバーに一度だけ接続します（図4を参照）。ポリシーサーバーの1つによって返されたセッションポリシーで複数のサーバー間で情報を共有する必要があり、UASが複数のポリシーサーバーからポリシーを受信する場合、UASはすべてのサーバーに最初に接続した後、もう一度すべてのポリシーサーバーに接続する必要があります。 2回目のラウンドが必要かどうかは、ポリシーサーバーから返される情報の種類によって決まります。セッションポリシーのデータ形式（[RFC6796]など）は、特定のデータ要素に2番目のラウンドが必要かどうかを明示的に示す必要があります。 UAがそのような要素を受信した場合、UAはポリシーサーバーに2度目にアクセスすることが予想されることを認識しています。そのようなデータ要素が通話中のオファー/アンサー交換中に変更され、複数のポリシーサーバーがUAにポリシーを提供している場合、すべてのUAは最初と2番目のラウンドでポリシーサーバーに接続する必要があります。コールフローの例を付録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 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は、ポリシーチャネルを通じて、現在のセッションのセッションの説明をポリシーサーバーに開示する必要があります。 UAは受信したセッションポリシーをオファーに適用する必要があります。オファーを受け取った場合は、オファー/アンサーを使用する前に回答に適用する必要があります。これらのポリシーが受け入れられない場合、UAはセッションを続行してはなりません（MUST NOT）。これは、UAがセッションの保留中のINVITEトランザクションをキャンセルまたは拒否するか、すでに進行中の場合はセッションを終了する必要があることを意味します。 UAがINVITE応答で受け入れられないポリシーを受信した場合、UAはINVITEトランザクションを完了してからセッションを終了しなければなりません（MUST）。
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は、例えばre-INVITEまたはUPDATE要求を使用して、変更されたセッション記述をピア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と通信するのを防ぐことができます。したがって、ポリシーシグナリングのないポリシー実施メカニズムは、UAのサービス拒否条件を作成する可能性があります。この仕様は、仲介人がUAに適用されるポリシーを通知するメカニズムを提供します。これにより、UAはポリシーに準拠し、ポリシー施行を通過するセッションを確立できます。
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とポリシーサーバーの間の通信をセキュリティで保護することが重要です。次の4つの個別の属性を保護する必要があります。
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. 機密性が保証され、認証されたセッションを介しても、2つの当事者間で個人情報が交換されないようにします。
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]などのセキュアなトランスポートプロトコルを使用する必要があります（SHOULD）。攻撃者はUAとプロキシ間のSIPメッセージを傍受し、セッション固有のポリシーに必要なポリシーヘッダーフィールドを削除する可能性があるため、ポリシーサーバーURIの整合性を保護することは重要です。これは、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を削除する代わりに、ポリシーサーバーURIを変更し、侵害されたポリシーサーバーをUAにポイントさせることもできます。 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は他のポリシーサーバーからのセッション固有のポリシーも受け入れることを選択できます（MAY）。
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.
ポリシーサーバーは、セッションポリシーに含まれる情報を保護するためにUAを認証する必要があります（SHOULD）。ただし、ポリシーサーバーは、認証できないUAに頻繁に遭遇することもあります。これらの場合、ポリシーサーバーは、これらのUAに機密情報を公開しない一般的なポリシーを提供する場合があります。
It is RECOMMENDED that administrators use SIPS URIs as policy server URIs so that subscriptions to session policies are transmitted over TLS.
セッションポリシーへのサブスクリプションがTLS経由で送信されるように、管理者がSIPS URIをポリシーサーバーURIとして使用することをお勧めします。
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
ヘッダーフィールドの名前：Policy-ID
Short form: none
短い形式：なし
Normative description: Section 4.4.5 of this document
規範的な説明：このドキュメントのセクション4.4.5
Name of Header Field: Policy-Contact
ヘッダーフィールドの名前：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. 「キャッシュ不可能な」Policy-Contactヘッダーフィールドパラメータの登録
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
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オプションタグ「policy」を定義しています。
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 of option: policy
オプションの名前：ポリシー
Description: Support for the Policy-Contact and Policy-ID header fields.
説明：Policy-ContactおよびPolicy-IDヘッダーフィールドのサポート。
SIP header fields defined: Policy-Contact, Policy-ID
定義されたSIPヘッダーフィールド：Policy-Contact、Policy-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：Session Initiation Protocol」 、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 3262、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）UPDATEメソッド」、RFC 3311、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）のインターネット割り当て番号機関（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 6080、2011年3月。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665] Roach、A。、「SIP固有のイベント通知」、RFC 6665、2012年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 6795、2012年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、「A Media Agent Profile Data Set for Media Policy」、RFC 6796、2012年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 3428、2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、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、「Session Initiation Protocol（SIP）でのサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、2004年4月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903] Niemi、A。、「Session State Initiation Protocol（SIP）Extension for Event State Publication」、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、「Uniform Resource Identifier（URI）：Generic Syntax」、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：Session Description Protocol」、RFC 4566、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、「The Transport Layer Security（TLS）Protocol Version 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.、Berger、E。、およびH. Kaplan、「Session Initiation Protocol（SIP）INFO Method and Package Framework」、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 Even、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：答え
a': answer modified by a policy
a '：ポリシーによって変更された回答
pa: answer policy
pa：回答ポリシー
ps uri: policy server URI (in Policy-Contact header field)
ps uri：ポリシーサーバーURI（Policy-Contactヘッダーフィールド内）
ps id: policy server id (in Policy-ID header field)
ps id：ポリシーサーバーID（Policy-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 | | | | |
|-------->| | | | |
|(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 |
| | | |<------------------|
| | | | | |
| | | | | |
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 | | | | |
|------------------------------------------------>|
| | | | | |
| | | | | |
Authors' Addresses
著者のアドレス
Volker Hilt Bell Labs/Alcatel-Lucent Lorenzstrasse 10 70435 Stuttgart Germany
Volker Hilt Bell Labs /アルカテルルーセントLorenzstrasse 10 70435シュトゥットガルトドイツ
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
Jonathan Rosenberg jdrosen.net Monmouth, NJ USA
ジョナサン・ローゼンバーグjdrosen.netニュージャージー州モンマス
EMail: jdrosen@jdrosen.net