RFC3313 日本語訳
3313 Private Session Initiation Protocol (SIP) Extensions for MediaAuthorization. W. Marshall, Ed.. January 2003. (Format: TXT=36866 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Marshall, Ed. Request for Comments: 3313 AT&T Category: Informational January 2003
ワーキンググループのW.マーシャル、エドをネットワークでつないでください。コメントのために以下を要求してください。 3313年のAT&Tカテゴリ: 情報の2003年1月
Private Session Initiation Protocol (SIP) Extensions
for Media Authorization
メディア認可のための個人的なセッション開始プロトコル(一口)拡大
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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入場コントロールを呼び出しシグナリングと統合して、サービス不能攻撃に対して警備を助けるために、Service(QoS)とメディア認可のQualityの必要性について説明して、使用できるSession Initiationプロトコル(SIP)拡張子を定義します。 この拡張子の使用が単に管理ドメインで適切であるか、または基本的なネットワークがQoSを提供して、QoSを認可するSIPプロキシと方針の両方が制御する方針が以前に同意している管理ドメインの連邦の中では、ドメインのその管理ドメインか連邦に属してください。
Marshall, Ed. Informational [Page 1] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[1ページ]のRFC3313一口拡張子
Table of Contents
目次
1. Scope of Applicability......................................... 2
2. Conventions Used in this Document.............................. 3
3. Background and Motivation...................................... 3
4. Overview....................................................... 4
5. Changes to SIP to Support Media Authorization.................. 4
5.1 SIP Header Extension....................................... 5
5.2 SIP Procedures............................................. 5
5.2.1 User Agent Client (UAC)................................ 6
5.2.2 User Agent Server (UAS)................................ 6
5.2.3 Originating Proxy (OP)................................. 7
5.2.4 Destination Proxy (DP)................................. 7
6. Examples....................................................... 8
6.1 Requesting Bandwidth via RSVP Messaging.................... 8
6.1.1 User Agent Client Side................................. 8
6.1.2 User Agent Server Side................................. 10
7. Advantages of the Proposed Approach............................ 12
8. Security Considerations........................................ 13
9. IANA Considerations............................................ 13
10. Notice Regarding Intellectual Property Rights................. 13
11. Normative References.......................................... 14
12. Informative References........................................ 14
13. Contributors.................................................. 15
14. Acknowledgments............................................... 15
15. Editor's Address.............................................. 15
16. Full Copyright Statement...................................... 16
1. 適用性の範囲… 2 2. このDocumentのコンベンションUsed… 3 3. バックグラウンドと動機… 3 4. 概観… 4 5. メディア認可を支持するためにちびちび飲む変化… 4 5.1 ヘッダー拡大をちびちび飲んでください… 5 5.2 手順をちびちび飲んでください… 5 5.2 .1 ユーザエージェントクライアント(UAC)… 6 5.2 .2 ユーザエージェントサーバ(UAS)… 6 5.2 .3 由来しているプロキシ(オプアート)… 7 5.2 .4 目的地プロキシ(DP)… 7 6. 例… 8 6.1 RSVP Messagingを通してBandwidthを要求します… 8 6.1 .1ユーザエージェントクライアント側… 8 6.1 .2ユーザエージェントサーバ側… 10 7. 提案の利点にアプローチします… 12 8. セキュリティ問題… 13 9. IANA問題… 13 10. 知的所有権に関して、注意してください… 13 11. 標準の参照… 14 12. 有益な参照… 14 13. 貢献者… 15 14. 承認… 15 15. エディタのアドレス… 15 16. 完全な著作権宣言文… 16
1. Scope of Applicability
1. 適用性の範囲
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拡張子を定義します。 この拡張子の使用が単に管理ドメインで適切であるか、または基本的なネットワークがQoSを提供して、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,
これは一般的なインターネット原則と比べています。原則はアプリケーションとデータ伝送を切り離します。 したがって、本書では説明された解決策は全体のインターネットに適切ではありません。 これらの制限にもかかわらず、このメカニズムの情報の公表を保証するために結果として生じる制限は、上で説明された仮定を満たす十分役に立つ専門化している展開であり、受け入れることができます。 例の展開は閉じているネットワークでしょう。
Marshall, Ed. Informational [Page 2] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[2ページ]のRFC3313一口拡張子
which emulates a traditional circuit switched telephone network. This document specifies a private header, facilitating use in these specialized configurations.
伝統的なサーキット切り換えられた電話網を見習います。 これらの専門化している構成における使用を容易にして、このドキュメントは個人的なヘッダーを指定します。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
3. Background and Motivation
3. バックグラウンドと動機
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電話技術システムは、無制限な量の帯域幅かService(QoS)のネットワーク層Qualityのどちらかがある理想の世界がどんな種類の方針コントロールなしでも提供されると仮定します。 しかしながら、現実は終わりから終わりへの帯域幅が無制限でなく、一般に、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:
本書では、Session Initiationプロトコル(SIP)で流れが[3]を設立したことをQoSをメディアに提供するのに私たちを心配させます。 私たちは以下の図で例証されるように呼び出しシグナリングをメディア認可と統合する構造を仮定します。 実線(AとB)はインタフェースを示していて、点線(C)は例証しましたが、QoSはメディア流動を可能にしました:
+---------+
| Proxy |
+--------->| |
| +---------+
| ^
A)| B) |
| { }
| |
| v
v +------+
+------+ C) | Edge |
| UA |........|router|......
+------+ +------+
+---------+ | プロキシ| +--------->|、|、| +---------+ | ^a)| B) | | { } | | | v対+------+ +------+ C) | 縁| | Ua|........|ルータ|...... +------+ +------+
Figure 1 - Basic Architecture
図1--基本的な構造
Marshall, Ed. Informational [Page 3] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[3ページ]のRFC3313一口拡張子
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.
この構造では、私たちは、縁のルータがPolicy Enforcement Point(PEP)[6]として機能する状態でQoSに接続されたSIP UAがネットワークを可能にしたと思います。 私たちは、QoSを入手したがっているSIP UAがプロキシを通したデータ網のための使用されるQoS方針制御装置に接続できるセッションを開始するとさらに思います。 QoSがプロキシを可能にしたので、私たちはそのようなプロキシを参照するつもりです。 私たちは、SIP UAが、Service(C)のQualityを入手するために認可象徴をネットワークに寄贈する必要であると思います。 SIP UAは本書では拡大SIPヘッダーによってプロキシを可能にして、定義されたQoSからのSIP(A)を通してこの認可象徴を入手します。 直接縁のルータかPolicy Decision Point(PDP--目立たない)でプロキシは、[6] 適当な認可象徴をUAに入手するために順番に交信します。
Examples of access data networks, where such a QoS enabled proxy could be used, include DOCSIS based cable networks and 3rd generation (3G) wireless networks.
アクセスデータ網に関する例であり、そのようなQoSがどこでプロキシを可能にしたか使用できて、DOCSISのベースのケーブルネットワークと3番目の世代(3G)ワイヤレス・ネットワークを含めてください。
4. Overview
4. 概観
A session that needs to obtain QoS for the media streams in accordance with our basic architecture described above goes through the following steps.
上で説明された私たちの基本的な構造に応じてメディアの流れにQoSを入手する必要があるセッションは以下の階段を通ります。
The SIP UA sends an INVITE to the QoS enabled proxy, which for each resulting dialog includes one or more media authorization tokens in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the dialog. When the UA requests QoS, it includes the media authorization tokens with the resource reservation.
SIP UAは対話のためのその信頼できる応答のすべての頼り無い暫定的な応答(100を除いた)か最初の信頼できる1xxか2xx応答と、すべての「再-トランスミッション」で可能にされたプロキシをQoSへのINVITEに送るか、または認可象徴をより多くのメディアに送ります。(それぞれの結果として起こる対話のために、プロキシは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はそうするかもしれません、また、QoSからINVITEを受けてください。1つ以上のメディア認可象徴を含んでいるプロキシを可能にしました。 UAがQoSを要求するとき、その場合、それは資源予約があるメディア認可象徴を含んでいます。 資源予約メカニズムは、SIPの一部でなく、またこのドキュメントの範囲の中で説明されません。
5. Changes to SIP to Support Media Authorization
5. メディア認可を支持するためにちびちび飲む変化
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はプロキシがQoS要求で使用されることになっている1つ以上の認可象徴でUAを供給するSIPを有効にしました。 定義された拡大は、ネットワークQoSリソースが認可されて、QoSがSIPプロキシを可能にしたということであることを許容します。
Marshall, Ed. Informational [Page 4] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[4ページ]のRFC3313一口拡張子
5.1 SIP Header Extension
5.1 一口ヘッダー拡大
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メディア認可一般的なヘッダーフィールドは定義されます。 Pメディア認可ヘッダーフィールドはここで指定されない独立している資源予約メカニズムにセッションに関連していて、すなわち、通っているメディア流れのその後の資源予約に含まれることになっている1つ以上のメディア認可象徴を含んでいます。 メディア認可象徴は、メディアの流れのためにQoSを認可するのに使用されます。 Pメディア認可ヘッダーフィールドは以下のABNF[4]によって説明されます:
P-Media-Authorization = "P-Media-Authorization" HCOLON
P-Media-Authorization-Token
*(COMMA P-Media-Authorization-Token)
Pメディア認可は「Pメディア認可」HCOLON Pメディア認可象徴*と等しいです。(コンマPメディア認可象徴)
P-Media-Authorization-Token = 1*HEXDIG
Pメディア認可象徴=1*HEXDIG
Table 1 below is an extension of tables 2 and 3 in [3] for the new header field defined here. For informational purposes, this table also includes relevant entries for standards track extension methods published at the time this document was published. The INFO, PRACK, UPDATE, and SUBSCRIBE and NOTIFY methods are defined respectively in [11], [9], [12], and [10].
テーブル1 以下に、ここで定義された新しいヘッダーフィールドのための[3]でのテーブル2と3の拡大があります。 また、情報の目的のために、このテーブルはこのドキュメントが発表されたとき発行された標準化過程拡大方法のための関連エントリーを含んでいます。 INFO、PRACK、UPDATE、登録、NOTIFY方法は[11]、[9]、[12]、および[10]でそれぞれ定義されます。
Where proxy ACK BYE CAN INV OPT REG
P-Media-Authorization R ad o - - o - -
P-Media-Authorization 2xx ad - - - o - -
P-Media-Authorization 101-199 ad - - - o - -
どこ、プロキシACK BYE CAN INV OPT REG Pメディア認可R広告o----o----Pメディア認可2xx広告------o----Pメディア認可101-199広告--、--、--o--、-
Where proxy INF PRA UPD SUB NOT
P-Media-Authorization R ad - o o - -
P-Media-Authorization 2xx ad - o o - -
どこ、プロキシINF PRA UPD SUB NOT Pメディア認可R広告(o o)--Pメディア認可2xx広告--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.
SIP申し出か答えを運ぶことができるSIP要求か応答だけにPメディア認可ヘッダーフィールドを使用できます。 これは自然にこのヘッダーフィールドの範囲を狭く保ちます。
5.2 SIP Procedures
5.2 一口手順
This section defines SIP [3] procedures for usage in media authorization compatible systems, from the point of view of the authorizing QoS.
このセクションはメディア認可コンパチブルシステムの用法のためにSIP[3]手順を定義します、認可しているQoSの観点から。
Marshall, Ed. Informational [Page 5] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[5ページ]のRFC3313一口拡張子
5.2.1 User Agent Client (UAC)
5.2.1 ユーザエージェントのクライアント(UAC)
The initial SIP INVITE message, mid-call messages that result in network QoS resource changes, and mid-call changes in call destination should be authorized. These SIP messages are sent through the QoS enabled proxies to receive this authorization. In order to authorize QoS, the QoS enabled SIP proxy MAY need to inspect message bodies that describe the media streams (e.g., SDP). Hence, it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that such message bodies not be encrypted end-to-end.
初期のSIP INVITEメッセージ、ネットワークQoSリソース変化をもたらす中間の呼び出しメッセージ、および呼び出しの目的地の中間の呼び出し変化は認可されるべきです。 SIPメッセージがQoSを通して送られるこれらは、プロキシがこの認可を受け取るのを可能にしました。 QoSを認可するために、QoSはメディアの流れ(例えば、SDP)について説明するメッセージ本体を点検するSIPプロキシ5月の必要性を可能にしました。 したがって、それはお勧めです。(適切であるかもしれないように、終わるために終わった状態でコード化されていなくて、このドキュメントのセクション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-メディア認可では、ヘッダーは含まれています。Pメディア認可象徴、全部で各対話のために、QoSによって送られた対話のためのその信頼できる応答の頼り無い暫定的な応答(100を除いた)か最初の信頼できる1xxか2xx応答と、すべての「再-トランスミッション」が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メディア認可ヘッダーを含んだ最新の要求/応答からすべてのPメディア認可象徴を使用するはずです。 これはともに初期でその後に適用されます。予約メッセージ(例えばRSVPベースの保留制で)をリフレッシュしてください。 UACの中の予約機能は、十六進法ケタの各ストリングをバイナリーに変換して、Policy-要素として各結果を利用するべきです、RFC2750[5](Lengthを除きますが、各象徴に含まれているP-タイプを含んでいる)で定義されるように。 これらのPolicy-要素は、認可実体と信任状を通常含んでいて、メディアデータ・ストリームQoSリソースにRSVP要求で使用されるでしょう。
5.2.2 User Agent Server (UAS)
5.2.2 ユーザエージェントサーバ(UAS)
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.
UserエージェントServerはQoSからのINVITE(何らかの)メッセージでのPメディア認可象徴の可能にされたSIPプロキシを受けます。 応答がUAがQoSを望んでいるメディアの流れについて説明するメッセージ本体を含んでいるなら、お勧めです。(適切であるかもしれないように、終わるために終わった状態でコード化されていなくて、このドキュメントのセクション1における適用性範囲) それの中では、これはボディーを通信させます。
The UAS should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorization header when requesting QoS for the associated media stream(s). This applies both to initial and subsequent refresh reservation messages (for example, in an RSVP-based reservation system). A reservation function within the UAS should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token). These Policy-Elements would typically
UASは関連メディアの流れのためにQoSを要求するときPメディア認可ヘッダーを含んだ最新の要求/応答からすべてのPメディア認可象徴を使用するはずです。 これは初期でその後に適用されます。予約メッセージ(例えばRSVPベースの保留制で)をリフレッシュしてください。 UASの中の予約機能は、十六進法ケタの各ストリングをバイナリーに変換して、Policy-要素として各結果を利用するべきです、RFC2750[5](Lengthを除きますが、各象徴に含まれているP-タイプを含んでいる)で定義されるように。 これらのPolicy-要素は通常そうするでしょう。
Marshall, Ed. Informational [Page 6] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[6ページ]のRFC3313一口拡張子
contain the authorizing entity and credentials, and be used in an RSVP request for media data stream QoS resources.
認可実体と信任状を含んでください、そして、メディアデータ・ストリームQoSリソースにRSVP要求で使用されてください。
5.2.3 Originating Proxy (OP)
5.2.3 由来しているプロキシ(オプアート)
When the originating QoS enabled proxy (OP) receives an INVITE (or other) message from the UAC, the proxy authenticates the caller, and verifies that the caller is authorized to receive QoS.
由来しているQoSがプロキシを可能にしたとき、(OP)がUACからINVITE(何らかの)メッセージを受け取って、プロキシは、訪問者を認証して、訪問者がQoSを受け取るのに権限を与えられることを確かめます。
In cooperation with an originating Policy Decision Point (PDP-o), the OP obtains and/or generates one or more media authorization tokens. These contain sufficient information for the UAC to get the authorized QoS for the media streams. Each media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token), and then converted to a string of hex digits to form a P- Media-Authorization-Token. The proxy's resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests and responses in order to decide what QoS to authorize.
由来しているPolicy Decision Point(PDP-o)と提携して、OPは1つ以上のメディア認可象徴を得る、そして/または、発生させます。 これらはUACがメディアの流れのために認可されたQoSを手に入れることができるくらいの情報を含んでいます。それぞれのメディア認可象徴はPolicy-要素としてフォーマットされます、RFC2750[5](Lengthを除きますが、各象徴に含まれているP-タイプを含んでいる)で定義されて、次に、Pメディア認可象徴を形成するために一連の十六進法ケタに変換されるように。 プロキシのリソース管理機能はどんな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から受け取られていて、由来しているプロキシがP-メディア認可を加えなければならないというINVITE(何らかの)メッセージから生じる各対話のために、その応答が最初のすべての頼り無い暫定的な応答(100を除いた)、信頼できる1xxまたは2xx応答におけるPメディア認可象徴、およびプロキシがUACに送るその信頼できる応答のすべての「再-トランスミッション」ネットワークQoSをもたらすかもしれないなら、ヘッダーは変化します。 SDPとの応答はそのような変化をもたらすかもしれません。
5.2.4 Destination Proxy (DP)
5.2.4 目的地プロキシ(DP)
The Destination QoS Enabled Proxy (DP) verifies that the called party is authorized to receive QoS.
Destination QoS Enabled Proxy(DP)は、被呼者がQoSを受け取るのに権限を与えられることを確かめます。
In cooperation with a terminating Policy Decision Point (PDP-t), the DP obtains and/or generates a media authorization token that contains sufficient information for the UAS to get the authorized QoS for the media streams. The media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy's resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests and responses in order to decide what QoS to authorize.
終わりPolicy Decision Point(PDP-t)と提携して、DPはUASがメディアの流れのために認可されたQoSを手に入れることができるくらいの情報を含むメディア認可象徴を、得る、そして/または、発生させます。メディア認可象徴はPolicy-要素としてフォーマットされます、RFC2750[5](Lengthを除きますが、各象徴に含まれているP-タイプを含んでいる)で定義されて、次に、Pメディア認可象徴を形成するために一連の十六進法ケタに変換されるように。 プロキシのリソース管理機能はどんなQoSを認可したらよいかを決めるために、要求と応答の両方でメディアの流れ(例えば、SDP)について説明するメッセージ本体を点検するかもしれません。
Marshall, Ed. Informational [Page 7] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[7ページ]のRFC3313一口拡張子
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.
Destination ProxyはそのメッセージがネットワークQoS変化をもたらすかもしれないならUASに発信するというINVITE(何らかの)要求におけるPメディア認可象徴でPメディア認可ヘッダーを加えなければなりません。 SDPボディーがあるメッセージはそのような変化をもたらすかもしれません。
6. Examples
6. 例
6.1 Requesting Bandwidth via RSVP Messaging
6.1 RSVP Messagingを通してBandwidthを要求すること。
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.
以下に、私たちはどうResource予約プロトコル(RSVP)[7]に関連してPメディア認可ヘッダーフィールドを使用できるかに関する例を提供します。 例は、申し出が初期のINVITEに到着すると仮定します、そして、答えは信頼できる暫定的な応答[9]に到達します。(それは、メディア流動のSDP記述を含みます)。
6.1.1 User Agent Client Side
6.1.1 ユーザエージェントクライアント側
Figure 2 presents a high-level overview of a basic call flow with media authorization from the viewpoint of the UAC. Some policy interactions have been omitted for brevity.
図2はUACの観点からメディア認可がある基本的な呼び出し流動のハイレベルの概観を提示します。 いくつかの方針相互作用が簡潔さのために省略されました。
When a user goes off-hook and dials a telephone number, the UAC collects the dialed digits and sends the initial (1)INVITE message to the originating SIP proxy.
ユーザがフックに行って、電話番号にダイヤルするとき、UACは由来しているSIPプロキシにダイヤルされたケタを集めて、初期の(1)INVITEメッセージを送ります。
The originating SIP proxy (OP) authenticates the user/UAC and forwards the (2)INVITE message to the proper SIP proxy.
由来しているSIPプロキシ(OP)は、ユーザ/UACを認証して、(2)INVITEメッセージを適切なSIPプロキシに転送します。
Assuming the call is not forwarded, the terminating end-point sends a (3)18x response to the initial INVITE via OP. Included in this response is an indication of the negotiated bandwidth requirement for the connection (in the form of an SDP description [8]).
呼び出しが進められないと仮定して、終わりエンドポイントはOPを通して(3)18x応答を初期のINVITEに送ります。 この応答に含まれているのは、接続のための交渉された帯域幅要件のしるしです。(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を受けるとき、それには、メディア交換のエンドポイント、帯域幅、および特性に関する十分な情報があります。 それはPolicy-セットアップメッセージを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)に認可象徴を返します。
Marshall, Ed. Informational [Page 8] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[8ページ]のRFC3313一口拡張子
UAC ER-o PDP-o OP |(1)INVITE | | | Client Authentication |------------------------------------------->| and Call Authoriz. | | | | (2)INVITE | | | |--------------> | | | | (3)18x | | |(4)AuthProfile |<-------------- | | |<--------------| | | |(5)AuthToken | | | |-------------->| Auth. Token put into | | | (6)18x | P-Media-Authorization |<-------------------------------------------| header extension. |---(7)PRACK-------------------------------->| | |--(8)PRACK----> | |<-(9)200 (PRACK) |<--(10)200 (PRACK)--------------------------| | | | | |Copies the RSVP policy object | |from the P-Media-Authorization | |(11)RSVP-PATH | | |----------->| (12)REQ | | | |-------------->| Using the Auth-Token and Authorized | | (13)DEC | Profile that is set by the SIP Proxy | |<--------------| the PDP makes the decision | | | |(14)RSVP-PATH | |------------------------------------------------> | | | |(15)RSVP-PATH |<-------------------------------------------------------------- |Copies the RSVP policy object | |from the P-Media-Authorization | |(16)RSVP-RESV | | |----------->| (17)REQ | | | |-------------->| Using the Auth-Token and Authorized | | (18)DEC | Profile that is set by the SIP Proxy | |<--------------| the PDP makes the decision | | | |(19)RSVP-RESV | |---------------------------------------------------> | | | |(20)RSVP-RESV |<---------------------------------------------------------------- | | | |
UAC、えー、-、o、PDP-oオプアート|(1)招待| | | クライアント認証|------------------------------------------->| そして、Authorizに電話をしてください。 | | | | (2)招待| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| (3)18x| | |(4)AuthProfile| <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(5)AuthToken| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| Auth。 象徴、投入| | | (6)18x| Pメディア認可|<-------------------------------------------| ヘッダー拡大。 |---(7)PRACK-------------------------------->|、| |--(8)PRACK---->| | <、-(9)200 (PRACK)| <--(10)200 (PRACK)--------------------------| | | | | |RSVP政策目的をコピーします。| |Pメディア認可から| |(11)RSVP-経路| | |、-、-、-、-、-、-、-、-、-、--、>| (12)REQ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| Auth-象徴を使用して、認可されます。| | (13)12月| SIP Proxyによって設定されるプロフィール| | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| PDPは決定をします。| | | |(14)RSVP-経路| |------------------------------------------------> | | | |(15)RSVP-経路|<-------------------------------------------------------------- |RSVP政策目的をコピーします。| |Pメディア認可から| |(16)RSVP-RESV| | |、-、-、-、-、-、-、-、-、-、--、>| (17)REQ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| Auth-象徴を使用して、認可されます。| | (18)12月| SIP Proxyによって設定されるプロフィール| | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| PDPは決定をします。| | | |(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メディア認可ヘッダー拡大で認可象徴を含んでいます。
Marshall, Ed. Informational [Page 9] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[9ページ]のRFC3313一口拡張子
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メディア認可ヘッダーでメディア認可象徴を格納します。 また、UACは、(7)PRACKメッセージを送ることによって、18xメッセージを承認します。(それは、(10)200で応じます)。
Before sending any media, the UAC requests QoS by sending an (11)RSVP-PATH message, which includes the previously stored P-Media- Authorization-Token as a Policy-Element.
どんなメディアも送る前にUACが(11)RSVP-PATHメッセージを送ることによってQoSを要求する、-、Policy-要素としての認可象徴。メッセージは以前に格納されたP-メディアを含んでいます。
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.
(11)RSVP-PATHメッセージを受け取り次第、ER-oはPDP-o COPS交換処理、(12)REQを通した認可をチェックします。 PDP-oは、それがOPに返した認可象徴にリンクされた格納された認可されたメディア記述を使用することで認可をチェックします。 認可がうまくいくなら、PDP-oは「インストールしてください」というDecision、(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は「インストールしてください」というDecision、(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メッセージを受け取ると、両方の方向へのネットワーク資源は予約されました。
6.1.2 User Agent Server Side
6.1.2 ユーザエージェントサーバ側
Figure 3 presents a high-level overview of a call flow with media authorization from the viewpoint of the UAS. Some policy interactions have been omitted for brevity.
図3はUASの観点からメディア認可がある呼び出し流動のハイレベルの概観を提示します。 いくつかの方針相互作用が簡潔さのために省略されました。
Since the destination SIP proxy (DP) has sufficient information regarding the endpoints, bandwidth, and characteristics of the media exchange, it initiates a Policy-Setup message to the terminating Policy Decision Point (PDP-t) on receipt of the (1)INVITE.
目的地SIPプロキシ(DP)にはメディア交換の終点、帯域幅、および特性に関する十分な情報があるので、それは(1)INVITEを受け取り次第終わりPolicy Decision Point(PDP-t)にPolicy-セットアップメッセージを開始します。
Marshall, Ed. Informational [Page 10] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[10ページ]のRFC3313一口拡張子
UAS ER-t PDP-t DP
| | | | (1)INVITE
| | | |<--------------
| | | | Proxy Authentication
| | | (2)AuthProfile| and Call Authoriz.
| | |<--------------|
| | | (3)AuthToken |
| | |-------------->| Auth. Token put into
| | | (4)INVITE | P-Media-Authorization
|<------------------------------------------| header extension
| (5)18x | | |
|------------------------------------------>| (6)18x
|Copies the RSVP policy object |-------------->
|from the P-Media-Authorization |
|(7)RSVP-PATH | |
|---------->| (8)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (9)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(10)RSVP-PATH
| |-------------------------------------------------->
| | | |(11)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
| (12)RSVP-RESV | |
|---------->| | |
| | (13)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (14)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(15)RSVP-RESV
| |--------------------------------------------------->
| | | |(16)RSVP-RESV
|<---------------------------------------------------------------
| | | |<-(17)PRACK---------
|<--(18)PRACK ------------------------------|
|---(19)200 (PRACK) ----------------------->|
| | | |--(20)200 (PRACK)-->
| | | |
UAS、えー、-、t、PDP-t DP| | | | (1)招待| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| プロキシ認証| | | (2)AuthProfile| そして、Authorizに電話をしてください。 | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| (3)AuthToken| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| Auth。 象徴、投入| | | (4)招待| Pメディア認可|<------------------------------------------| ヘッダー拡大| (5)18x| | | |------------------------------------------>| (6)18x|RSVP政策目的をコピーします。|-------------->| Pメディア認可から| |(7)RSVP-経路| | |、-、-、-、-、-、-、-、-、--、>| (8)REQ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| Auth-象徴を使用して、認可されます。| | (9)12月| SIP Proxyによって設定されるプロフィール| | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| PDPは決定をします。| | | |(10)RSVP-経路| |--------------------------------------------------> | | | |(11)RSVP-経路|<-------------------------------------------------------------- |RSVP政策目的をコピーします。| |Pメディア認可から| | (12)RSVP-RESV| | |、-、-、-、-、-、-、-、-、--、>|、|、|、|、| (13)REQ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| Auth-象徴を使用して、認可されます。| | (14)12月| SIP Proxyによって設定されるプロフィール| | <、-、-、-、-、-、-、-、-、-、-、-、-、--、| PDPは決定をします。| | | |(15)RSVP-RESV| |---------------------------------------------------> | | | |(16)RSVP-RESV|<--------------------------------------------------------------- | | | | <、-(17)PRACK--------- | <--(18)PRACK------------------------------| |---(19)200 (PRACK)----------------------->|、|、|、| |--(20)200(PRACK)-->。| | | |
Figure 3 - Media Authorization with RSVP (UAS)
図3--RSVPとのメディア認可(UAS)
PDP-t stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to DP. The token is placed in the (4)INVITE message and forwarded to the UAS.
PDP-tは、DPに地元の小売店に認可されたメディア記述を格納して、指す認可象徴をこの記述に発生させて、認可象徴を返します。 象徴を(4)INVITEメッセージに置いて、UASに送ります。
Marshall, Ed. Informational [Page 11] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[11ページ]のRFC3313一口拡張子
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は(5)18x応答を初期のINVITEメッセージに送ります。(それは、UACに転送して戻されます)。 同時に、UASはPolicy-要素として以前に格納されたPメディア認可象徴を含んでいる(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.
(7)RSVP-PATHメッセージを受け取るときのER-tはPDP-t COPS交換処理で認可をチェックします。 PDP-tは、それがDPに返した認可象徴にリンクされた格納された認可されたメディア記述を使用することで認可をチェックします。 認可がうまくいくなら、PDP-tは「インストールしてください」というDecision、(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.
(12)RSVP-RESVメッセージのレセプションでは、ER-tはPDP-t COPS交換処理で認可をチェックします。 PDP-tは、それがDPに返した認可象徴にリンクされた格納された認可されたメディア記述を使用することで認可をチェックします。 認可がうまくいくなら、PDP-tは「インストールしてください」というDecision、(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応答と結果になる(19)200応答への(17)PRACKメッセージがPRACKを承認するのを示します。
7. Advantages of the Proposed Approach
7. 提案されたアプローチの利点
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をサービス不能攻撃に対して、より強健なTelephonyにして、様々なサービスの種類を詐欺にします。 認可能力、流れの数、および予約されたネットワーク資源の量を使用することによって、制御できてください、その結果、IP Telephonyシステムを希少資源があるとき信頼できるようにします。
Marshall, Ed. Informational [Page 12] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[12ページ]のRFC3313一口拡張子
8. Security Considerations
8. セキュリティ問題
In order to control access to QoS, a QoS enabled proxy should authenticate the UA before providing it with a media authorization token. Both the method and policy associated with such authentication are outside the scope of this document, however it could, for example, be done by using standard SIP authentication mechanisms, as described in [3].
アクセスを制御するために、メディア認可象徴をそれに提供する前に、QoS、有効にされたQoSにプロキシはUAを認証するべきです。 このドキュメントの範囲の外にそのような認証に関連している方法と方針があります、しかしながら、例えば、標準のSIP認証機構を使用することによって、それができるでしょう、[3]で説明されるように。
Media authorization tokens sent in the P-Media-Authorization header from a QoS enabled proxy to a UA MUST be protected from eavesdropping and tampering. This can, for example, be done through a mechanism such as IPSec or TLS. However, this will only provide hop-by-hop security. If there is one or more intermediaries (e.g., proxies), between the UA and the QoS enabled proxy, these intermediaries will have access to the P-Media-Authorization header field value, thereby compromising confidentiality and integrity. This will enable both theft-of-service and denial-of-service attacks against the UA. Consequently, the P-Media-Authorization header field MUST NOT be available to any untrusted intermediary in the clear or without integrity protection. There is currently no mechanism defined in SIP that would satisfy these requirements. Until such a mechanism exists, proxies MUST NOT send P-Media-Authorization headers through untrusted intermediaries, which might reveal or modify the contents of this header. (Note that S/MIME-based encryption in SIP is not available to proxy servers, as proxies are not allowed to add message bodies.)
メディア認可象徴は、Uaの可能にされたプロキシがそうしなければならないQoSからのPメディア認可ヘッダーが雨垂れといじるのから保護されるのを送りました。 例えば、IPSecかTLSなどのメカニズムを通してこれができます。 しかしながら、これはホップごとのセキュリティを提供するだけでしょう。 1人以上の仲介者(例えば、プロキシ)がいれば、可能にされたプロキシ、これらの仲介者がそうするUAとQoSの間では、Pメディア認可ヘッダーフィールド価値に近づく手段を持ってください、その結果、秘密性と保全で妥協します。 これはUAに対してサービスの窃盗とサービス不能攻撃の両方を可能にするでしょう。 その結果、どんな信頼されていない仲介者にとっても、Pメディア認可ヘッダーフィールドは明確か保全保護なしで利用可能であるはずがありません。 現在、これらの要件を満たすSIPで定義されたメカニズムが全くありません。 そのようなメカニズムが存在するまで、プロキシは信頼されていない仲介者を通してPメディア認可ヘッダーを送ってはいけません。その仲介者は、このヘッダーのコンテンツを明らかにするか、または変更するかもしれません。 (SIPのMIME S/ベースの暗号化がプロキシサーバに利用可能でないことに注意してください、プロキシがメッセージ本体を加えることができないとき。)
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)を流します。 その結果、そのようなメッセージ本体をコード化するべきではありません。 順番に、これは前述のメッセージ本体の終わりから終わりへの秘密性を防ぐでしょう。(それは、可能な総合的なセキュリティを下げます)。
9. IANA Considerations
9. IANA問題
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.
このドキュメントはメディア認可、「Pメディア認可」のために新しい個人的なSIPヘッダーを定義します。 このヘッダーはSIPヘッダー登録のIANAによって登録されました、参照としてこのドキュメントのRFC番号を使用して。
10. Notice Regarding Intellectual Property Rights
10. 知的所有権に関する通知
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
Marshall, Ed. Informational [Page 13] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[13ページ]のRFC3313一口拡張子
11. Normative References
11. 引用規格
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[5] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
12. Informative References
12. 有益な参照
[6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.
[6]YavatkarとR.とPendarakisとD.とR.ゲラン、「方針ベースの入場コントロールのための枠組み」、RFC2753、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] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[8] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[9] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[10] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[11] ドノヴァン、S.、「一口インフォメーション方法」、RFC2976、2000年10月。
[12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002.
[12] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、2002年9月。
Marshall, Ed. Informational [Page 14] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[14ページ]のRFC3313一口拡張子
13. Contributors
13. 貢献者
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.Ramakrishnan(AT&T)、エド・ミラー(Terayon)、グレン・ラッセル(CableLabs)、Burcak Beser(杜松ネットワーク)、マイクMannette(3Com)、カートスタインブレナー(3Com)、デーヴ・オラン(シスコ)、フレミングAndreasen(シスコ)、ジョン・ピケンズ(Com21)、Poornima Lalwaney(ノキア)、ジョンFellows(カッパーマウンテンネットワーク)、Doc Evans(アリス)、およびキース・ケリー(NetSpeak)。
14. Acknowledgments
14. 承認
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プロジェクトにおけるDistributed Call Signaling仕事は多くの人々の仕事です、多くの異なった会社を代表して。 貢献者がそうしたい、認識して、感謝する、: ジョン・ウィーラー、モトローラ。 デヴィッドBoardman、ダニエル・ポール、アリスInteractive。 ビル・ブルーム、ジェイStrater、ジェフ・オリス、クライヴHolborow、モトローラ。 ダグ・ニューリン、グイド・シュスター、Ikhlaq Sidhu、3Com。 ジリマトウシェク、ベイネットワークス。 Farzi Khazai、ノーテル。 ジョン・チャップマン、ビルGuckel、マイケルRamalho、シスコ。 チャックKalmanek、ダグNortz、ジョンLawser、ジェームス・チェン、タン-Haiシャオ、Partho Mishra、AT&T。 Telcordia技術。 そして、透明な有線通信。 ディーン・ウィリスとRohanマーイはまた、有益なフィードバックを提供しました。
15. Editor's Address
15. エディタのアドレス
Bill Marshall AT&T Florham Park, NJ 07932
ビルマーシャルAT&T Florham Park、ニュージャージー 07932
EMail: wtm@research.att.com
メール: wtm@research.att.com
Marshall, Ed. Informational [Page 15] RFC 3313 SIP Extensions for Media Authorization January 2003
エドマーシャル、メディア認可2003年1月のための情報[15ページ]のRFC3313一口拡張子
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Marshall, Ed. Informational [Page 16]
マーシャル、エド、情報[16ページ]
一覧
スポンサーリンク
