[要約] RFC 3313は、メディア認可のためのプライベートセッションイニシエーションプロトコル（SIP）の拡張に関するものです。このRFCの目的は、SIPセッション中のメディアリソースへのアクセスを制御するための仕組みを提供することです。
Network Working Group W. Marshall, Ed.
Request for Comments: 3313 AT&T
Category: Informational January 2003
Private Session Initiation Protocol (SIP) Extensions for Media Authorization
プライベートセッション開始プロトコル（SIP）メディア許可のための拡張機能
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains.
このドキュメントでは、サービス品質（QOS）とメディア認可の必要性について説明し、QoS入学制御をコールシグナリングと統合し、サービス拒否攻撃から守るために使用できるセッション開始プロトコル（SIP）拡張機能を定義します。この拡張機能の使用は、管理ドメイン、または以前に合意したポリシーを備えた管理ドメインの連合の間でのみ適用されます。ドメインまたはドメイン連合。
Table of Contents
目次
1. Scope of Applicability......................................... 2
2. Conventions Used in this Document.............................. 3
3. Background and Motivation...................................... 3
4. Overview....................................................... 4
5. Changes to SIP to Support Media Authorization.................. 4
5.1 SIP Header Extension....................................... 5
5.2 SIP Procedures............................................. 5
5.2.1 User Agent Client (UAC)................................ 6
5.2.2 User Agent Server (UAS)................................ 6
5.2.3 Originating Proxy (OP)................................. 7
5.2.4 Destination Proxy (DP)................................. 7
6. Examples....................................................... 8
6.1 Requesting Bandwidth via RSVP Messaging.................... 8
6.1.1 User Agent Client Side................................. 8
6.1.2 User Agent Server Side................................. 10
7. Advantages of the Proposed Approach............................ 12
8. Security Considerations........................................ 13
9. IANA Considerations............................................ 13
10. Notice Regarding Intellectual Property Rights................. 13
11. Normative References.......................................... 14
12. Informative References........................................ 14
13. Contributors.................................................. 15
14. Acknowledgments............................................... 15
15. Editor's Address.............................................. 15
16. Full Copyright Statement...................................... 16
This document defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains. Furthermore, the mechanism is generally incompatible with end-to-end encryption of message bodies that describe media sessions.
このドキュメントでは、QoS入学制御をコールシグナリングと統合し、サービス拒否攻撃から守るのに役立つSIP拡張機能を定義します。この拡張機能の使用は、管理ドメイン、または以前に合意したポリシーを備えた管理ドメインの連合の間でのみ適用されます。ドメインまたはドメイン連合。さらに、メカニズムは一般に、メディアセッションを記述するメッセージ本文のエンドツーエンドの暗号化と互換性がありません。
This is in contrast with general Internet principles, which separate data transport from applications. Thus, the solution described in this document is not applicable to the Internet at large. Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network, which emulates a traditional circuit switched telephone network. This document specifies a private header, facilitating use in these specialized configurations.
これは、一般的なインターネット原則とは対照的であり、アプリケーションからデータトランスポートを分離します。したがって、このドキュメントで説明されているソリューションは、インターネット全体に適用されません。これらの制限にもかかわらず、このメカニズムの情報公開を保証するために、上記の仮定を満たし、結果の制限を受け入れることができる十分に有用な専門的な展開があります。展開の例は、従来の回路スイッチ付き電話ネットワークをエミュレートするクローズドネットワークです。このドキュメントは、これらの特殊な構成での使用を促進するプライベートヘッダーを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [2]に記載されているように解釈される。
Current IP telephony systems assume a perfect world in which there is either an unlimited amount of bandwidth, or network layer Quality of Service (QoS) is provided without any kind of policy control. However, the reality is that end-to-end bandwidth is not unlimited and uncontrolled access to QoS, in general, is unlikely. The primary reason for this is that QoS provides preferential treatment of one flow, at the expense of another. Consequently, it is important to have policy control over whether a given flow should have access to QoS. This will not only enable fairness in general, but can also prevent denial of service attacks.
現在のIPテレフォニーシステムは、無制限の量の帯域幅、またはネットワークレイヤーサービスの品質（QOS）がいずれかのポリシー管理なしで提供される完璧な世界を想定しています。しかし、現実には、エンドツーエンドの帯域幅は無制限ではなく、QoSへの制御されていないアクセスは一般的にありません。これの主な理由は、QoSが別の流れを犠牲にして1つの流れの優先的な処理を提供することです。したがって、特定のフローがQoSにアクセスできるかどうかをポリシー制御することが重要です。これにより、一般的に公平性が可能になるだけでなく、サービス拒否攻撃を防ぐこともできます。
In this document, we are concerned with providing QoS for media streams established via the Session Initiation Protocol (SIP) [3]. We assume an architecture that integrates call signaling with media authorization, as illustrated in the Figure below. The solid lines (A and B) show interfaces, whereas the dotted line (C) illustrates the QoS enabled media flow:
このドキュメントでは、セッション開始プロトコル（SIP）[3]を介して確立されたメディアストリームのQoSを提供することに関心があります。下の図に示すように、コールシグナル伝達をメディア許可と統合するアーキテクチャを想定しています。実線（AおよびB）はインターフェイスを示しますが、点線（c）はQOS対応のメディアフローを示しています。
+---------+
| Proxy |
+--------->| |
| +---------+
| ^
A)| B) |
| { }
| |
| v
v +------+
+------+ C) | Edge |
| UA |........|router|......
+------+ +------+
Figure 1 - Basic Architecture
図1-基本アーキテクチャ
In this architecture, we assume a SIP UA connected to a QoS enabled network with an edge router acting as a Policy Enforcement Point (PEP) [6]. We further assume that a SIP UA that wishes to obtain QoS initiates sessions through a proxy which can interface with the QoS policy control for the data network being used. We will refer to such a proxy as a QoS enabled proxy. We assume that the SIP UA needs to present an authorization token to the network in order to obtain Quality of Service (C). The SIP UA obtains this authorization token via SIP (A) from the QoS enabled proxy by means of an extension SIP header, defined in this document. The proxy, in turn, communicates either directly with the edge router or with a Policy Decision Point (PDP - not shown) [6] in order to obtain a suitable authorization token for the UA.
このアーキテクチャでは、QoS対応ネットワークに接続されたSIP UAが、ポリシー執行ポイント（PEP）として機能するEdgeルーターを使用して想定しています[6]。さらに、使用されているデータネットワークのQOSポリシーコントロールとインターフェイスできるプロキシを介してQoS開始セッションを取得したいSIP UAが想定しています。このようなプロキシをQOS対応プロキシと呼びます。SIP UAは、サービスの品質を取得するために、ネットワークに承認トークンを提示する必要があると仮定します（c）。SIP UAは、このドキュメントで定義されている拡張機能SIPヘッダーを使用して、QoS対応プロキシからSIP（a）を介してこの承認トークンを取得します。次に、プロキシは、UAの適切な承認トークンを取得するために、Edgeルーターまたはポリシー決定ポイント（PDP-表示されていない）[6]と直接通信します。
Examples of access data networks, where such a QoS enabled proxy could be used, include DOCSIS based cable networks and 3rd generation (3G) wireless networks.
このようなQoS対応プロキシを使用できるアクセスデータネットワークの例には、DOCSISベースのケーブルネットワークと第3世代（3G）ワイヤレスネットワークが含まれます。
A session that needs to obtain QoS for the media streams in accordance with our basic architecture described above goes through the following steps.
上記の基本的なアーキテクチャに従ってメディアストリームのQOを取得する必要があるセッションは、次の手順を実行します。
The SIP UA sends an INVITE to the QoS enabled proxy, which for each resulting dialog includes one or more media authorization tokens in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the dialog. When the UA requests QoS, it includes the media authorization tokens with the resource reservation.
SIP UAは、QoS対応プロキシに招待を送信します。これには、結果として得られる各ダイアログが、すべての信頼性の低い暫定的な応答（100を除く）、最初の信頼できる1XXまたは2XX応答、およびその信頼できる応答のすべての再送信の1つ以上のメディア認証トークンが含まれます。ダイアログ。UAがQoSを要求する場合、リソース予約のあるメディア認証トークンが含まれます。
A SIP UA may also receive an INVITE from its QoS enabled proxy which includes one or more media authorization tokens. In that case, when the UA requests QoS, it includes the media authorization tokens with the resource reservation. The resource reservation mechanism is not part of SIP and is not described within the scope of this document.
SIP UAは、1つ以上のメディア認証トークンを含むQoS対応プロキシから招待状を受け取る場合があります。その場合、UAがQOSを要求する場合、リソース予約のあるメディア認証トークンが含まれます。リソース予約メカニズムはSIPの一部ではなく、このドキュメントの範囲内では説明されていません。
This document defines a private SIP header extension to support a media authorization scheme. In this architecture, a QoS enabled SIP proxy supplies the UA with one or more authorization tokens which are to be used in QoS requests. The extension defined allows network QoS resources to be authorized by the QoS enabled SIP proxy.
このドキュメントでは、メディア許可スキームをサポートするためのプライベートSIPヘッダー拡張機能を定義しています。このアーキテクチャでは、QoS対応のSIPプロキシにより、QoSリクエストで使用される1つ以上の承認トークンがUAに供給されます。拡張機能を定義することにより、ネットワークQoSリソースをQOS対応SIPプロキシによって承認できます。
A new P-Media-Authorization general header field is defined. The P-Media-Authorization header field contains one or more media authorization tokens which are to be included in subsequent resource reservations for the media flows associated with the session, that is, passed to an independent resource reservation mechanism, which is not specified here. The media authorization tokens are used for authorizing QoS for the media stream(s). The P-Media-Authorization header field is described by the following ABNF [4]:
新しいp-media-authorization generalヘッダーフィールドが定義されています。P-Media-authorizationヘッダーフィールドには、セッションに関連するメディアフローのその後のリソース予約に含まれる1つ以上のメディア認証トークン、つまり、ここでは指定されていない独立したリソース予約メカニズムに渡されることがあります。メディア認証トークンは、メディアストリームのQOを承認するために使用されます。P-Media-authorizationヘッダーフィールドは、次のABNF [4]で説明されています。
P-Media-Authorization = "P-Media-Authorization" HCOLON P-Media-Authorization-Token *(COMMA P-Media-Authorization-Token)
p-media-authorization = "p-media-authorization" hcolon p-media-authorization-token *（comma p-media-authorization-token）
P-Media-Authorization-Token = 1*HEXDIG
Table 1 below is an extension of tables 2 and 3 in [3] for the new header field defined here. For informational purposes, this table also includes relevant entries for standards track extension methods published at the time this document was published. The INFO, PRACK, UPDATE, and SUBSCRIBE and NOTIFY methods are defined respectively in [11], [9], [12], and [10].
以下の表1は、ここで定義されている新しいヘッダーフィールドの表2および3の拡張機能です。情報目的のために、この表には、このドキュメントが公開された時点で公開された標準追跡拡張メソッドの関連するエントリも含まれています。情報、プラック、更新、および購読および通知方法は、それぞれ[11]、[9]、[12]、および[10]で定義されています。
Where proxy ACK BYE CAN INV OPT REG
P-Media-Authorization R ad o - - o - -
P-Media-Authorization 2xx ad - - - o - -
P-Media-Authorization 101-199 ad - - - o - -
Where proxy INF PRA UPD SUB NOT
P-Media-Authorization R ad - o o - -
P-Media-Authorization 2xx ad - o o - -
Table 1: Summary of header fields.
表1：ヘッダーフィールドの概要。
The P-Media-Authorization header field can be used only in SIP requests or responses that can carry a SIP offer or answer. This naturally keeps the scope of this header field narrow.
P-Media-authorizationヘッダーフィールドは、SIPのリクエストまたは応答でのみ使用できます。これにより、当然、このヘッダーフィールドの範囲が狭くなります。
This section defines SIP [3] procedures for usage in media authorization compatible systems, from the point of view of the authorizing QoS.
このセクションでは、承認QoSの観点から、メディア認証互換システムでの使用に関するSIP [3]手順を定義します。
The initial SIP INVITE message, mid-call messages that result in network QoS resource changes, and mid-call changes in call destination should be authorized. These SIP messages are sent through the QoS enabled proxies to receive this authorization. In order to authorize QoS, the QoS enabled SIP proxy MAY need to inspect message bodies that describe the media streams (e.g., SDP). Hence, it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that such message bodies not be encrypted end-to-end.
最初のSIP招待メッセージ、ネットワークQoSリソースの変更をもたらすミッドコールメッセージ、およびコール宛先のミッドコールの変更は許可される必要があります。これらのSIPメッセージは、QoS対応プロキシを介して送信され、この承認を受けます。QOSを承認するために、QOS対応のSIPプロキシは、メディアストリーム（SDPなど）を説明するメッセージ本文を検査する必要がある場合があります。したがって、このようなメッセージ本文はエンドツーエンドで暗号化されていないことを（このドキュメントのセクション1の適用可能性の範囲内で適切な場合があるように）推奨されます。
The P-Media-Authorization-Token, which is contained in the P-Media-Authorization header, is included for each dialog in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the dialog sent by the QoS enabled SIP proxy to the UAC.
P-Media-Authorizationヘッダーに含まれるP-Media-authorization-Tokenは、すべての信頼性の低い暫定的な応答（100を除く）、最初の信頼性の高い1xxまたは2xx応答、およびその信頼できるすべての再送信のすべてのダイアログに含まれています。QOSによって送信されたダイアログの応答は、UACにSIPプロキシを有効にしました。
The UAC should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorization header when requesting QoS for the associated media stream(s). This applies to both initial and subsequent refresh reservation messages (for example, in an RSVP-based reservation system). A reservation function within the UAC should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token). These Policy-Elements would typically contain the authorizing entity and credentials, and be used in an RSVP request for media data stream QoS resources.
UACは、関連するメディアストリームのQoSを要求する際にP-Media-authorizationヘッダーを含む最新のリクエスト/応答からすべてのp-media-authorization-tokensを使用する必要があります。これは、初期およびその後の更新予約メッセージの両方に適用されます（たとえば、RSVPベースの予約システムなど）。UAC内の予約関数は、各ヘックス数字の文字列をバイナリに変換し、RFC 2750 [5]で定義されているように、各結果をポリシー要素として使用する必要があります（長さを除くが、各トークンに含まれるPタイプを含む）。これらのポリシー要素には、通常、承認エンティティと資格情報が含まれ、メディアデータストリームQoSリソースのRSVP要求に使用されます。
The User Agent Server receives the P-Media-Authorization-Token in an INVITE (or other) message from the QoS enabled SIP proxy. If the response contains a message body that describes media streams for which the UA desires QoS, it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that this message body not be encrypted end-to-end.
ユーザーエージェントサーバーは、QoS対応のSIPプロキシから招待（またはその他）メッセージでP-Media-authorization-tokenを受信します。応答に、UAがQoSを望むメディアストリームを記述するメッセージ本文が含まれている場合、このメッセージ本文がエンドツーエンドで暗号化されていないことが推奨されます（このドキュメントのセクション1の適用性範囲内で適切な場合があります）。
The UAS should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorization header when requesting QoS for the associated media stream(s). This applies both to initial and subsequent refresh reservation messages (for example, in an RSVP-based reservation system). A reservation function within the UAS should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token). These Policy-Elements would typically contain the authorizing entity and credentials, and be used in an RSVP request for media data stream QoS resources.
UASは、関連するメディアストリームのQoSを要求する際にP-Media-authorizationヘッダーを含む最新のリクエスト/応答からすべてのp-media-authorization-tokensを使用する必要があります。これは、初期およびその後の更新予約メッセージの両方に適用されます（たとえば、RSVPベースの予約システムなど）。UAS内の予約関数は、各ヘックス数字の文字列をバイナリに変換し、RFC 2750 [5]で定義されているように、各結果をポリシー要素として使用する必要があります（長さを除くが、各トークンに含まれるPタイプを含む）。これらのポリシー要素には、通常、承認エンティティと資格情報が含まれ、メディアデータストリームQoSリソースのRSVP要求に使用されます。
When the originating QoS enabled proxy (OP) receives an INVITE (or other) message from the UAC, the proxy authenticates the caller, and verifies that the caller is authorized to receive QoS.
発信中のQoS有効化プロキシ（OP）がUACから招待（またはその他の）メッセージを受信すると、プロキシは発信者を認証し、発信者がQOを受信することを許可されていることを確認します。
In cooperation with an originating Policy Decision Point (PDP-o), the OP obtains and/or generates one or more media authorization tokens. These contain sufficient information for the UAC to get the authorized QoS for the media streams. Each media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy's resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests and responses in order to decide what QoS to authorize.
発信元のポリシー決定点（PDP-O）と協力して、OPは1つ以上のメディア認証トークンを取得および/または生成します。これらには、UACがメディアストリームの承認されたQOを取得するのに十分な情報が含まれています。各メディア認証トークンは、RFC 2750 [5]（長さを除くが、各トークンに含まれるPタイプを含む）で定義されているように、ポリシー要素としてフォーマットされ、その後、16進数桁の文字列に変換してPを形成します。-media-authorization-token。プロキシのリソース管理関数は、QoSを決定するために、リクエストと応答の両方で、メディアストリーム（SDPなど）を記述するメッセージ本文を検査する場合があります。
For each dialog that results from the INVITE (or other) message received from the UAC, the originating proxy must add a P-Media-Authorization header with the P-Media-Authorization-Token in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response the proxy sends to the UAC, if that response may result in network QoS changes. A response with an SDP may result in such changes.
UACから受信した招待（または他の）メッセージに起因する各ダイアログについて、発信元のプロキシは、すべての信頼性の低い暫定的な回答（100を除く）でP-Media-authorization-tokenを使用してp-media-authorizationヘッダーを追加する必要があります。最初に信頼できる1XXまたは2XX応答、およびその応答がネットワークQOSの変更につながる可能性がある場合、プロキシがUACに送信する信頼できる応答のすべての再送信。SDPの応答は、そのような変更をもたらす可能性があります。
The Destination QoS Enabled Proxy (DP) verifies that the called party is authorized to receive QoS.
宛先QoS対応プロキシ（DP）は、呼び出された当事者がQOを受け取ることを許可されていることを確認します。
In cooperation with a terminating Policy Decision Point (PDP-t), the DP obtains and/or generates a media authorization token that contains sufficient information for the UAS to get the authorized QoS for the media streams. The media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy's resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests and responses in order to decide what QoS to authorize.
終了ポリシーの決定ポイント（PDP-T）と協力して、DPは、メディアストリームの承認されたQOを取得するためにUASが十分な情報を含むメディア認証トークンを取得および/または生成します。メディア認証トークンは、RFC 2750 [5]（長さを除くが、各トークンに含まれるPタイプを含む）で定義されているように、ポリシー要素としてフォーマットされ、その後、16進数桁の文字列に変換してPを形成します。-media-authorization-token。プロキシのリソース管理関数は、QoSを決定するために、リクエストと応答の両方で、メディアストリーム（SDPなど）を記述するメッセージ本文を検査する場合があります。
The Destination Proxy must add the P-Media-Authorization header with the P-Media-Authorization-Token in the INVITE (or other) request that it sends to the UAS if that message may result in network QoS changes. A message with an SDP body may result in such changes.
宛先プロキシは、そのメッセージがネットワークQoSの変更につながる可能性がある場合、招待（またはその他）リクエストでP-Media-authorization-tokenを使用してp-media-authorization-tokenを使用してp-media-authorizationヘッダーを追加する必要があります。SDP本体を持つメッセージは、そのような変更をもたらす可能性があります。
Below we provide an example of how the P-Media-Authorization header field can be used in conjunction with the Resource Reservation Protocol (RSVP) [7]. The example assumes that an offer arrives in the initial INVITE and an answer arrives in a reliable provisional response [9], which contains an SDP description of the media flow.
以下に、P-Media-authorizationヘッダーフィールドをリソース予約プロトコル（RSVP）と組み合わせて使用する方法の例を示します[7]。この例では、オファーが最初の招待状に到着し、回答がメディアフローのSDPの説明を含む信頼できる暫定的な対応[9]に到着することを前提としています。
Figure 2 presents a high-level overview of a basic call flow with media authorization from the viewpoint of the UAC. Some policy interactions have been omitted for brevity.
図2は、UACの観点からのメディア許可による基本的なコールフローの高レベルの概要を示しています。いくつかの政策相互作用は簡潔に省略されています。
When a user goes off-hook and dials a telephone number, the UAC collects the dialed digits and sends the initial (1)INVITE message to the originating SIP proxy.
ユーザーがオフフックになって電話番号をダイヤルすると、UACはダイヤルされた数字を収集し、最初の（1）招待メッセージを発信するSIPプロキシに送信します。
The originating SIP proxy (OP) authenticates the user/UAC and forwards the (2)INVITE message to the proper SIP proxy.
発生するSIPプロキシ（OP）は、ユーザー/UACを認証し、（2）招待メッセージを適切なSIPプロキシに転送します。
Assuming the call is not forwarded, the terminating end-point sends a (3)18x response to the initial INVITE via OP. Included in this response is an indication of the negotiated bandwidth requirement for the connection (in the form of an SDP description [8]).
コールが転送されていないと仮定すると、終了エンドポイントは、OPを介して最初の招待に（3）18x応答を送信します。この応答に含まれるのは、接続のネゴシエートされた帯域幅要件の兆候です（SDP説明[8]の形式）。
When OP receives the (3)18x, it has sufficient information regarding the end-points, bandwidth and characteristics of the media exchange. It initiates a Policy-Setup message to PDP-o, (4)AuthProfile.
OPが（3）18Xを受信すると、メディア交換のエンドポイント、帯域幅、特性に関する十分な情報があります。PDP-O（4）AuthProfileへのポリシーセットアップメッセージを開始します。
The PDP-o stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to the OP, (5)AuthToken.
PDP-Oは、ローカルストアに認可されたメディアの説明を保存し、この説明を指す承認トークンを生成し、承認トークンをOPに返します（5）AuthToken。
UAC ER-o PDP-o OP
|(1)INVITE | | | Client Authentication
|------------------------------------------->| and Call Authoriz.
| | | | (2)INVITE
| | | |-------------->
| | | | (3)18x
| | |(4)AuthProfile |<--------------
| | |<--------------|
| | |(5)AuthToken |
| | |-------------->| Auth. Token put into
| | | (6)18x | P-Media-Authorization
|<-------------------------------------------| header extension.
|---(7)PRACK-------------------------------->|
| |--(8)PRACK---->
| |<-(9)200 (PRACK)
|<--(10)200 (PRACK)--------------------------|
| | | |
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(11)RSVP-PATH | |
|----------->| (12)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (13)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(14)RSVP-PATH
| |------------------------------------------------>
| | | |(15)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(16)RSVP-RESV | |
|----------->| (17)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (18)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(19)RSVP-RESV
| |--------------------------------------------------->
| | | |(20)RSVP-RESV
|<----------------------------------------------------------------
| | | |
Figure 2 - Media Authorization with RSVP (UAC)
図2- RSVP（UAC）によるメディア認証
The OP includes the authorization token in the P-Media-Authorization header extension of the (6)18x message.
OPには、（6）18xメッセージのP-Media-authorizationヘッダー拡張における承認トークンが含まれています。
Upon receipt of the (6)18x message, the UAC stores the media authorization token from the P-Media-Authorization header. Also, the UAC acknowledges the 18x message by sending a (7)PRACK message, which is responded to with (10) 200.
（6）18xメッセージを受信すると、UACはP-Media-Authorizationヘッダーからメディア認証トークンを保存します。また、UACは（7）プラックメッセージを送信することにより18xメッセージを認めます。これは（10）200で応答されます。
Before sending any media, the UAC requests QoS by sending an (11)RSVP-PATH message, which includes the previously stored P-Media-Authorization-Token as a Policy-Element.
メディアを送信する前に、UACは（11）RSVP-Pathメッセージを送信してQoSを要求します。
ER-o, upon receipt of the (11)RSVP-PATH message, checks the authorization through a PDP-o COPS message exchange, (12)REQ. PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install" Decision, (13)DEC.
ER-Oは、（11）RSVP-PATHメッセージを受信すると、PDP-O CopsメッセージExchangeを通じて承認をチェックします（12）Req。PDP-Oは、OPに返された承認トークンにリンクされた保存された承認されたメディアの説明を使用して認証をチェックします。承認が成功した場合、PDP-Oは「インストール」決定を返します（13）12月。
ER-o checks the admissibility for the request, and if admission succeeds, it forwards the (14)RSVP-PATH message.
ER-Oは、リクエストの許容性をチェックし、入学が成功した場合、（14）RSVP-PATHメッセージを転送します。
Once UAC receives the (15)RSVP-PATH message from UAS, it sends the (16)RSVP-RESV message to reserve the network resources.
UACがUASから（15）RSVP-Pathメッセージを受信すると、ネットワークリソースを予約するために（16）RSVP-RESVメッセージを送信します。
ER-o, upon receiving the (16)RSVP-RESV message checks the authorization through a PDP-o COPS message exchange, (17)REQ. PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install" Decision, (18)DEC.
ER-O、（16）RSVP-RESVメッセージを受信すると、PDP-O COPSメッセージ交換を通じて認可をチェックします（17）Req。PDP-Oは、OPに返された承認トークンにリンクされた保存された承認されたメディアの説明を使用して認証をチェックします。許可が成功した場合、PDP-Oは「インストール」決定を返します（18）12月。
ER-o checks the admissibility for the request, and if admission succeeds, it forwards the (19)RSVP-RESV message.
ER-Oは、リクエストの許容性をチェックし、入場が成功した場合、（19）RSVP-RESVメッセージを転送します。
Upon receiving the (20)RSVP-RESV message, network resources have been reserved in both directions.
（20）RSVP-RESVメッセージを受信すると、ネットワークリソースは両方向に予約されています。
Figure 3 presents a high-level overview of a call flow with media authorization from the viewpoint of the UAS. Some policy interactions have been omitted for brevity.
図3は、UASの観点からのメディア許可によるコールフローの高レベルの概要を示しています。いくつかの政策相互作用は簡潔に省略されています。
Since the destination SIP proxy (DP) has sufficient information regarding the endpoints, bandwidth, and characteristics of the media exchange, it initiates a Policy-Setup message to the terminating Policy Decision Point (PDP-t) on receipt of the (1)INVITE.
宛先SIPプロキシ（DP）には、メディア交換のエンドポイント、帯域幅、および特性に関する十分な情報があるため、（1）招待の受領時に終了ポリシー決定ポイント（PDP-T）へのポリシーセットアップメッセージを開始します。。
UAS ER-t PDP-t DP
| | | | (1)INVITE
| | | |<--------------
| | | | Proxy Authentication
| | | (2)AuthProfile| and Call Authoriz.
| | |<--------------|
| | | (3)AuthToken |
| | |-------------->| Auth. Token put into
| | | (4)INVITE | P-Media-Authorization
|<------------------------------------------| header extension
| (5)18x | | |
|------------------------------------------>| (6)18x
|Copies the RSVP policy object |-------------->
|from the P-Media-Authorization |
|(7)RSVP-PATH | |
|---------->| (8)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (9)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(10)RSVP-PATH
| |-------------------------------------------------->
| | | |(11)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
| (12)RSVP-RESV | |
|---------->| | |
| | (13)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (14)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(15)RSVP-RESV
| |--------------------------------------------------->
| | | |(16)RSVP-RESV
|<---------------------------------------------------------------
| | | |<-(17)PRACK---------
|<--(18)PRACK ------------------------------|
|---(19)200 (PRACK) ----------------------->|
| | | |--(20)200 (PRACK)-->
| | | |
Figure 3 - Media Authorization with RSVP (UAS)
図3- RSVP（UAS）によるメディア認証
PDP-t stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to DP. The token is placed in the (4)INVITE message and forwarded to the UAS.
PDP-Tは、地元の店舗に認定メディアの説明を保存し、この説明を指す承認トークンを生成し、承認トークンをDPに返します。トークンは（4）招待メッセージに配置され、UASに転送されます。
Assuming that the call is not forwarded, the UAS sends a (5)18x response to the initial INVITE message, which is forwarded back to UAC. At the same time, the UAS sends a (7)RSVP-PATH message which includes the previously stored P-Media-Authorization-Token as a Policy-Element.
コールが転送されていないと仮定すると、UASはUACに転送される最初の招待メッセージに（5）18x応答を送信します。同時に、UASは、以前に保存されていたP-Media-Authorization-Tokenをポリシー要素として含む（7）RSVP-Pathメッセージを送信します。
ER-t, upon receiving the (7)RSVP-PATH message checks the authorization through a PDP-t COPS message exchange. PDP-t checks the authorization using the stored authorized media description that was linked to the authorization token it returned to DP. If authorization is successful, PDP-t returns an "install" Decision, (9)DEC.
ER-T、（7）RSVP-Pathメッセージを受信すると、PDP-T COPSメッセージ交換を通じて承認をチェックします。PDP-Tは、DPに返された承認トークンにリンクされた保存された承認されたメディアの説明を使用して認証をチェックします。許可が成功した場合、PDP-Tは「インストール」決定を返します（9）12月。
ER-t checks the admissibility for the request, and if admission succeeds, it forwards the (10)RSVP-PATH message.
ER-Tは、リクエストの許容性をチェックし、入場が成功した場合、（10）RSVP-PATHメッセージを転送します。
Once the UAS receives the (11)RSVP-PATH message, it sends the (12)RSVP-RESV message to reserve the network resources.
UASが（11）RSVP-Pathメッセージを受信すると、ネットワークリソースを予約するために（12）RSVP-RESVメッセージを送信します。
ER-t, upon reception of the (12)RSVP-RESV message, checks the authorization through a PDP-t COPS message exchange. PDP-t checks the authorization using the stored authorized media description that was linked to the authorization token that it returned to DP. If authorization is successful, PDP-t returns an "install" Decision, (14)DEC.
ER-Tは、（12）RSVP-RESVメッセージを受信すると、PDP-T COPSメッセージ交換を通じて承認をチェックします。PDP-Tは、DPに戻ったという認証トークンにリンクされた保存された承認されたメディアの説明を使用して認証をチェックします。許可が成功した場合、PDP-Tは「インストール」決定を返します（14）12月。
ER-t checks the admissibility for the request and if admission succeeds, it forwards the (15)RSVP-RESV message.
ER-Tはリクエストの許容性をチェックし、入場が成功した場合、（15）RSVP-RESVメッセージを転送します。
Upon receiving the (16)RSVP-RESV message, network resources have been reserved in both directions.
（16）RSVP-RESVメッセージを受信すると、ネットワークリソースは両方向に予約されています。
For completeness, we show the (17)PRACK message for the (5) 18x response and the resulting (19) 200 response acknowledging the PRACK.
完全性のために、（5）18x応答の（17）プラックメッセージと、結果として得られた（19）200の応答を表示します。
The use of media authorization makes it possible to control the usage of network resources. In turn, this makes IP Telephony more robust against denial of service attacks and various kinds of service frauds. By using the authorization capability, the number of flows, and the amount of network resources reserved can be controlled, thereby making the IP Telephony system dependable in the presence of scarce resources.
メディア認可を使用すると、ネットワークリソースの使用を制御できます。次に、これにより、IPテレフォニーがサービス拒否攻撃やさまざまな種類のサービス詐欺に対してより堅牢になります。許可機能、フローの数、および予約されたネットワークリソースの量を使用することにより、希少なリソースの存在下でIPテレフォニーシステムを信頼できるようにすることができます。
In order to control access to QoS, a QoS enabled proxy should authenticate the UA before providing it with a media authorization token. Both the method and policy associated with such authentication are outside the scope of this document, however it could, for example, be done by using standard SIP authentication mechanisms, as described in [3].
QOSへのアクセスを制御するために、QoS対応プロキシは、メディア認証トークンを提供する前にUAを認証する必要があります。このような認証に関連する方法とポリシーの両方は、このドキュメントの範囲外ですが、たとえば[3]で説明されているように、標準のSIP認証メカニズムを使用して実行できます。
Media authorization tokens sent in the P-Media-Authorization header from a QoS enabled proxy to a UA MUST be protected from eavesdropping and tampering. This can, for example, be done through a mechanism such as IPSec or TLS. However, this will only provide hop-by-hop security. If there is one or more intermediaries (e.g., proxies), between the UA and the QoS enabled proxy, these intermediaries will have access to the P-Media-Authorization header field value, thereby compromising confidentiality and integrity. This will enable both theft-of-service and denial-of-service attacks against the UA. Consequently, the P-Media-Authorization header field MUST NOT be available to any untrusted intermediary in the clear or without integrity protection. There is currently no mechanism defined in SIP that would satisfy these requirements. Until such a mechanism exists, proxies MUST NOT send P-Media-Authorization headers through untrusted intermediaries, which might reveal or modify the contents of this header. (Note that S/MIME-based encryption in SIP is not available to proxy servers, as proxies are not allowed to add message bodies.)
メディア認証トークンは、P-Media-authorizationヘッダーで送信され、QoS対応プロキシからUAに盗聴して改ざんから保護する必要があります。これは、たとえば、IPSECやTLSなどのメカニズムを介して実行できます。ただし、これはホップバイホップセキュリティのみを提供します。UAとQOS対応プロキシの間に1つ以上の仲介者（プロキシなど）がある場合、これらの仲介者はP-Media-Authorizationヘッダーフィールド値にアクセスし、それにより機密性と完全性を損ないます。これにより、UAに対するサービス盗難攻撃とサービス拒否攻撃の両方が可能になります。したがって、P-Media-authorizationヘッダーフィールドは、明確または整合性の保護なしに、信頼されていない仲介者が利用できないはずです。現在、これらの要件を満たすSIPで定義されているメカニズムはありません。そのようなメカニズムが存在するまで、プロキシは、信頼されていない仲介者を介してp-media-authorizationヘッダーを送信してはなりません。これは、このヘッダーの内容を明らかにまたは変更する可能性があります。（プロキシサーバーでは、SIPのS/MIMEベースの暗号化は、メッセージボディを追加できないため、プロキシサーバーが利用できないことに注意してください。）
QoS enabled proxies may need to inspect message bodies describing media streams (e.g., SDP). Consequently, such message bodies should not be encrypted. In turn, this will prevent end-to-end confidentiality of the said message bodies, which lowers the overall security possible.
QoS対応プロキシは、メディアストリーム（SDPなど）を説明するメッセージ本文を検査する必要がある場合があります。したがって、そのようなメッセージ本文を暗号化するべきではありません。次に、これにより、上記のメッセージ本文のエンドツーエンドの機密性が防止され、可能な限り全体的なセキュリティが低下します。
This document defines a new private SIP header for media authorization, "P-Media-Authorization". This header has been registered by the IANA in the SIP header registry, using the RFC number of this document as its reference.
このドキュメントでは、メディア承認のための新しいプライベートSIPヘッダー「P-Media-authorization」を定義しています。このヘッダーは、このドキュメントのRFC番号を参照として使用して、SIPヘッダーレジストリにIANAによって登録されています。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[5] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、2000年1月。
[6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[6] Yavatkar、R.、Pendarakis、D。and R. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[7] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[9] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[10] Roach、A。B.、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[11] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.
[12] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年9月。
The following people contributed significantly and were co-authors on earlier versions of this document:
次の人々は大きく貢献し、このドキュメントの以前のバージョンの共著者でした。
Bill Marshall (AT&T), K. K. Ramakrishnan (AT&T), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Juniper Networks), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (Arris), and Keith Kelly (NetSpeak).
ビル・マーシャル（AT＆T）、K。K。ラマクリシュナン（AT＆T）、エドミラー（テラヨン）、グレンラッセル（ケイブルラブ）、ブルカックベザー（ジュニパーネットワーク）、マイクマネット（3COM）、カートスタインブレンナー（3COM）、デイブまたはデイブまたはデイブオルアン（Cisco）、フレミメミングAndreasen（Cisco）、John Pickens（COM21）、Poornima Lalwaney（Nokia）、Jon Fellows（Copper Mountain Networks）、Doc Evans（Arris）、Keith Kelly（Netspeak）。
The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The contributors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications. Dean Willis and Rohan Mahy provided valuable feedback as well.
Packetcableプロジェクトでの分散コールシグナリング作業は、多くの人々の仕事であり、多くの異なる企業を代表しています。貢献者は、以下に支援を認識し、感謝したいと思います。ジョン・ウィーラー、モトローラ。デビッドボードマン、ダニエルポール、アリスインタラクティブ。ビル・ブルム、ジェイ・ストラター、ジェフ・オリス、クライヴ・ホルボロー、モトローラ。Doug Newlin、Guido Schuster、Ikhlaq Sidhu、3com;Jiri Matousek、ベイネットワーク。Farzi Khazai、ノルテル;ジョン・チャップマン、ビル・ガッケル、マイケル・ラマルホ、シスコ。Chuck Kalmanek、Doug Nortz、John Lawer、James Cheng、Tung-Hai Hsiao、Partho Mishra、AT＆T;Telcordia Technologies;そして、Lucent Cable Communications。ディーン・ウィリスとロハン・マヒーも貴重なフィードバックを提供しました。
Bill Marshall AT&T Florham Park, NJ 07932
ビルマーシャルAT＆Tフローハムパーク、ニュージャージー07932
EMail: wtm@research.att.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。