[要約] RFC 5009は、SIPのPヘッダー拡張を使用して早期メディアの認証を行うためのものです。目的は、SIPセッションの早期メディアに対して適切な認証を提供することです。
Network Working Group R. Ejzak
Request for Comments: 5009 Alcatel-Lucent
Category: Informational September 2007
Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media
初期メディアの承認のためのセッション開始プロトコル（SIP）へのプライベートヘッダー（P-Header）拡張
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state.
このドキュメントでは、欧州通信標準研究所（ETSI）通信およびインターネットコンバージドサービスおよび高度なネットワークのプロトコル（TISPAN）が使用するプライベートセッション開始プロトコル（SIP）ヘッダーフィールド（P-Header）について説明します。メディアは、第三世代のパートナーシッププロジェクト（3GPP）IPマルチメディアサブシステム（IMS）に流れます。このヘッダーフィールドは、他のSIPネットワークと相互接続されているSIPネットワークで役立ち、初期のダイアログ状態でメディアの流れを制御する必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Applicability Statement .........................................3
3. Conventions and Acronyms ........................................3
4. Background on Early Media Authorization .........................4
4.1. Backward Early Media .......................................5
4.2. Forward Early Media ........................................5
5. Applicability of RFC 3959 and RFC 3960 ..........................6
6. Overview of Operation ...........................................6
7. Limitations of the P-Early-Media Header Field ...................8
8. The P-Early-Media Header Field ..................................8
8.1. Procedures at the User Agent Client .......................10
8.2. Procedures at the User Agent Server .......................10
8.3. Procedures at the Proxy ...................................11
9. Formal Syntax ..................................................11
10. Security Considerations .......................................11
11. IANA Considerations ...........................................12
11.1. Registration of the "P-Early-Media" SIP Header Field .....12
12. Acknowledgements ..............................................12
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................13
This document defines the use of the P-Early-Media header field for use within SIP [1] messages in certain SIP networks to authorize the cut-through of backward and/or forward early media when permitted by the early media policies of the networks involved. The P-Early-Media header field is intended for use in a SIP network, such as a 3GPP IMS [13][14] that has the following characteristics: its early media policy prohibits the exchange of early media between end users; it is interconnected with other SIP networks that have unknown, untrusted, or different policies regarding early media; and it has the capability to "gate" (enable/disable) the flow of early media to/from user equipment.
このドキュメントでは、特定のSIPネットワークでSIP [1]メッセージ内で使用するためのP-hearly-mediaヘッダーフィールドの使用を定義して、ネットワークの初期メディアポリシーで許可された場合に、後方および/または前方のメディアのカットスルーを承認することを定義します。関与。P-hearly-mediaヘッダーフィールドは、次の特性を持つ3GPP IMS [13] [14]など、SIPネットワークで使用することを目的としています。初期のメディアポリシーは、エンドユーザー間の初期メディアの交換を禁止しています。初期のメディアに関する不明、信頼されていない、または異なるポリシーがある他のSIPネットワークと相互接続されています。また、ユーザー機器との間の初期メディアの流れを「ゲート」（有効化/無効にする）機能を備えています。
Within an isolated SIP network, it is possible to gate early media associated with all endpoints within the network to enforce a desired early media policy among network endpoints. However, when a SIP network is interconnected with other SIP networks, only the boundary node connected to the external network can determine which early media policy to apply to a session established between endpoints on different sides of the boundary. The P-Early-Media header field provides a means for this boundary node to communicate this early media policy decision to other nodes within the network.
孤立したSIPネットワーク内では、ネットワーク内のすべてのエンドポイントに関連付けられた初期メディアをゲート化して、ネットワークエンドポイント間で望ましい初期メディアポリシーを実施することができます。ただし、SIPネットワークが他のSIPネットワークと相互接続されている場合、外部ネットワークに接続された境界ノードのみが、境界の異なる側のエンドポイント間で確立されたセッションに適用する初期メディアポリシーを決定できます。P-hearly-mediaヘッダーフィールドは、この境界ノードがネットワーク内の他のノードにこの初期メディアポリシーの決定を伝える手段を提供します。
The use of this extension is only applicable inside a "Trust Domain" as defined in RFC 3325 [6]. Nodes in such a Trust Domain are explicitly trusted by its users and end-systems to authorize early media requests only when allowed by early media policy within the Trust Domain.
この拡張機能の使用は、RFC 3325 [6]で定義されている「信頼ドメイン」内でのみ適用されます。このような信頼ドメインのノードは、ユーザーと最終システムによって明示的に信頼されており、Trustドメイン内の初期メディアポリシーで許可された場合にのみ、早期メディアリクエストを承認します。
This document does NOT offer a general early media authorization model suitable for inter-domain use or use in the Internet at large. Furthermore, since the early media requests are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of the Trust Domain.
このドキュメントは、インターネット全体でのドメイン間の使用または使用に適した一般的な早期メディア認証モデルを提供しません。さらに、初期のメディアリクエストは暗号化された認定を受けていないため、トラストドメインの要件を満たさないアーキテクチャにおける偽造、リプレイ、および偽造の対象となります。
An early media request also lacks an indication of who specifically is making or modifying the request, and so it must be assumed that the Trust Domain is making the request. Therefore, the information is only meaningful when securely received from a node known to be a member of the Trust Domain.
早期のメディアリクエストには、誰が具体的にリクエストを作成または変更しているかの兆候も欠いているため、信頼ドメインがリクエストを行っていると想定する必要があります。したがって、情報は、信頼ドメインのメンバーであることが知られているノードから安全に受信された場合にのみ意味があります。
Although this extension can be used with parallel forking, it does not improve on the known problems with early media and parallel forking, as described in RFC 3960 [4], unless one can assume the use of symmetric RTP.
この拡張は並列フォーキングで使用できますが、対称RTPの使用を想定しない限り、RFC 3960 [4]で説明されているように、初期のメディアと並列フォーキングの既知の問題を改善しません。
Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant publication of this mechanism. An example deployment would be a closed network that emulates a traditional circuit switched telephone network.
これらの制限にもかかわらず、上記の仮定を満たす十分に有用な専門的な展開があり、このメカニズムの公開を保証するために結果の制限を受け入れることができます。展開の例は、従来の回路スイッチ付き電話ネットワークをエミュレートするクローズドネットワークです。
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]に記載されているように解釈される。
The following acronyms are used in this document:
このドキュメントでは、次の頭字語が使用されています。
3GPP - the Third Generation Partnership Project
ABNF - Augmented Backus-Naur Form [5]
DTMF - Dual Tone Multi-Frequency
ETSI - European Telecommunications Standards Institute
IMS - Internet Protocol Multimedia Subsystem [13][14]
MIME - Multipurpose Internet Mail Extensions
NAT - Network Address Translation
PSTN - Public Switched Telephone Network
SDP - Session Description Protocol [7]
SIP - Session Initiation Protocol [1]
TISPAN - Telecommunications and Internet-converged Services and
Protocols for Advanced Networks
UA - User Agent [1]
UAC - User Agent Client [1]
UAS - User Agent Server [1]
PSTN networks typically provide call progress information as backward early media from the terminating switch towards the calling party. PSTN networks also use forward early media from the calling party towards the terminating switch under some circumstances for applications, such as digit collection for secondary dialing. PSTN networks typically allow backward and/or forward early media since they are used for the purpose of progressing the call to the answer state and do not involve the exchange of data between endpoints.
PSTNネットワークは、通常、コールの進行状況情報を、終了スイッチから呼び出し当事者に向けた後方メディアとして提供します。PSTNネットワークは、セカンダリダイヤル用の桁コレクションなど、アプリケーションの場合は、いくつかの状況下で、呼び出し当事者から終了スイッチに向かって前方メディアを使用します。PSTNネットワークは、通常、回答状態への呼び出しを進める目的で使用され、エンドポイント間のデータの交換を伴わないため、後方および/または前方のメディアを許可します。
In a SIP network, backward early media flows from the User Agent Server (UAS) towards the User Agent Client (UAC). Forward early media flows from the UAC towards the UAS. SIP networks by default allow both forms of early media, which may carry user data, once the media path is established. Early media is typically desirable with a PSTN gateway as UAS, but not with SIP user equipment as UAS.
SIPネットワークでは、ユーザーエージェントサーバー（UAS）からユーザーエージェントクライアント（UAC）に後方の初期メディアが流れます。Forward Early Media FlowはUACからUASに向かいます。SIPネットワークは、デフォルトで、メディアパスが確立されると、ユーザーデータを運ぶ可能性のある初期メディアの両方の形式を使用できます。初期のメディアは通常、PSTNゲートウェイをUASとして望んでいますが、UASとしてのSIPユーザー機器ではありません。
To prevent the exchange of user data within early media while allowing early media via PSTN gateways, a SIP network may have a policy to prohibit backward early media from SIP user equipment and to prohibit forward media towards SIP user equipment, either of which may contain user data. A SIP network containing both PSTN gateways and SIP end devices, for example, can maintain such an early media policy by gating "off" any early media with a SIP end device acting as UAS, gating "on" early media with a SIP end device acting as UAC, and gating "on" early media at each PSTN gateway.
PSTNゲートウェイを介して初期のメディアを許可しながら初期のメディア内でユーザーデータの交換を防ぐために、SIPネットワークには、早期メディアがSIPユーザー機器を禁止し、SIPユーザー機器に対する前進メディアを禁止するポリシーがある場合があります。データ。たとえば、PSTNゲートウェイとSIPエンドデバイスの両方を含むSIPネットワークは、SIPエンドデバイスを使用して、SIPエンドデバイスとして機能するSIPエンドデバイスを使用して初期のメディアを「オフ」することにより、このような初期のメディアポリシーを維持できます。UACとして機能し、各PSTNゲートウェイで初期のメディアを「オン」にゲーティングします。
Unfortunately, a SIP network interconnected with another SIP network may have no means of assuring that the interconnected network is implementing a compatible early media policy, thus allowing the exchange of user data within early media under some circumstances. For example, if a network "A" allows all early media with user equipment as UAC and an interconnected network "B" allows all early media with user equipment as UAS, any session established between user equipment as UAC in "A" and user equipment as UAS in "B" will allow bidirectional user data exchange as early media. Other combinations of early media policies may also produce similar undesirable results.
残念ながら、別のSIPネットワークと相互接続されたSIPネットワークは、相互接続されたネットワークが互換性のある初期メディアポリシーを実装していることを保証する手段がない場合があります。たとえば、ネットワーク「A」がUACとしてユーザー機器を使用したすべての初期メディアと相互接続されたネットワーク「B」を使用すると、ユーザー機器のすべての初期メディアがUASとして許可されている場合、ユーザー機器の間で「A」とユーザー機器として確立されたセッションを許可します。「B」のUASは、初期のメディアとして双方向のユーザーデータ交換を許可するためです。初期のメディアポリシーの他の組み合わせも、同様の望ましくない結果をもたらす可能性があります。
The purpose of the extension is to allow a SIP network interconnected to other SIP networks with different early media policies to correctly identify and enable authorized early media according to its policies.
拡張機能の目的は、さまざまな初期メディアポリシーを備えた他のSIPネットワークと相互接続されたSIPネットワークが、そのポリシーに従って認可された初期メディアを正しく特定し、有効にできるようにすることです。
Backward early media in the PSTN typically comprises call progress information, such as ringing feedback ("ringback"), or announcements regarding special handling such as forwarding. It may also include requests for further information, such as a credit card number to be entered as forward early media in the form of Dual Tone Multi-Frequency (DTMF) tones or speech. Backward early media of this type provides information to the calling party strictly for the purpose of progressing the call and involves no exchange of data between end users. The usual PSTN charging policy assumes that no data is exchanged between users until the call has been answered.
PSTNの後方初期メディアは、通常、リンギングフィードバック（「リングバック」）などのコール進行情報、または転送などの特別な取り扱いに関する発表で構成されています。また、デュアルトーンマルチ周波数（DTMF）トーンやスピーチの形で、フォワードアーリーメディアとして入力されるクレジットカード番号など、詳細情報のリクエストを含める場合があります。このタイプの後方の初期メディアは、通話を進める目的で厳密に呼び出し当事者に情報を提供し、エンドユーザー間でデータの交換は含まれません。通常のPSTN充電ポリシーは、通話が回答されるまでユーザー間でデータが交換されないことを想定しています。
A terminating SIP User Agent (UA) outside of the SIP network, on the other hand, may provide any user data in a backward early media stream. Thus, if the network implements the usual early media policy, the network equipment gating the backward early media flow for the originating UA must distinguish between authorized early media from a terminating SIP endpoint and unauthorized early media from another SIP device outside of the network. Given the assumption of a transitive trust relationship between SIP servers in the network, this can be accomplished by including some information in a backward SIP message that identifies the presence of authorized backward early media. Since it is necessary to verify that this indication comes from a trusted source, it is necessary for each server on the path back to the originating UA to be able to verify the trust relationship with the previous server and to remove such an indication when it cannot do so. A server on the boundary to an untrusted SIP network can assure that no indication of authorized backward early media passes from an external UAS to a UAC within the network. Thus, the use of a private header field that can be modified by SIP proxies is to be preferred over the use of a Multipurpose Internet Mail Extensions (MIME) attachment that cannot be modified in this way.
一方、SIPネットワークの外側の終了SIPユーザーエージェント（UA）は、後方の初期メディアストリームでユーザーデータを提供する場合があります。したがって、ネットワークが通常の初期メディアポリシーを実装している場合、ネットワーク機器は、発信されるUAの後方メディアの流れを測定する必要があります。承認された初期メディアと、SIPエンドポイントの終了と、ネットワーク外の別のSIPデバイスから許可されていない初期メディアを区別する必要があります。ネットワーク内のSIPサーバー間の推移的な信頼関係の仮定を考えると、これは、承認された後方の初期メディアの存在を識別する後方SIPメッセージにいくつかの情報を含めることで実現できます。この表示が信頼できるソースからのものであることを確認する必要があるため、元のUAに戻るパス上の各サーバーが以前のサーバーとの信頼関係を検証し、できない場合にそのような表示を削除できるようにする必要がありますそうする。信頼されていないSIPネットワークへの境界上のサーバーは、認定された後方メディアの兆候が外部UASからネットワーク内のUACに渡されないことを保証できます。したがって、SIPプロキシによって変更できるプライベートヘッダーフィールドの使用は、この方法で変更できない多目的インターネットメールエクステンション（MIME）添付ファイルの使用よりも優先されます。
Forward early media is less common than backward early media in the PSTN. It is typically used to collect secondary dialed digits, to collect credit card numbers, or to collect other DTMF or speech responses for the purpose of further directing the call. Forward early media in the PSTN is always directed toward a network server for the purpose of progressing a call and involves no exchange of data between end users.
フォワードアーリーメディアは、PSTNの後方初期メディアよりも一般的ではありません。通常、セカンダリダイヤルされた数字を収集したり、クレジットカード番号を収集したり、コールをさらに指示する目的で他のDTMFまたは音声応答を収集するために使用されます。PSTNのフォワードアーリーメディアは、呼び出しを進める目的で常にネットワークサーバーに向けられ、エンドユーザー間でデータの交換は含まれません。
A terminating SIP UA outside of the SIP network, on the other hand, may receive any user data in a forward early media stream. Thus, if the network implements the usual early media policy, the network equipment gating the forward early media flow for the originating UA must distinguish between a terminating endpoint that is authorized to receive forward early media, and another SIP device outside of the network that is not authorized to receive forward early media containing user data. This authorization can be accomplished in the same manner as for backward early media by including some information in a backward SIP message that identifies that the terminating side is authorized to receive forward early media.
一方、SIPネットワークの外側の終了SIP UAは、フォワードの初期メディアストリームでユーザーデータを受信する場合があります。したがって、ネットワークが通常の早期メディアポリシーを実装している場合、ネットワーク機器は、元のUAの前進メディアフローをゲートする必要があります。ユーザーデータを含むForward Early Mediaを受信することは許可されていません。この承認は、後方メディアと同じ方法で達成できます。これは、終了側が前方の早期メディアを受け取ることが許可されていることを識別するいくつかの情報を後方SIPメッセージに含めることで実現できます。
The private header extension defined in this document is applicable to the gateway model defined in RFC 3960 [4], since the PSTN gateway is the primary requestor of early media in an IMS. For the same reason, neither the application server model of RFC 3960, nor the early-session disposition type defined in RFC 3959 [3] is applicable.
このドキュメントで定義されているプライベートヘッダー拡張機能は、PSTNゲートウェイがIMSの初期メディアの主要な要求者であるため、RFC 3960 [4]で定義されたゲートウェイモデルに適用できます。同じ理由で、RFC 3960のアプリケーションサーバーモデルも、RFC 3959 [3]で定義されている早期セッションの処分タイプも適用されません。
The gateway model of RFC 3960 [4] allows for individual networks to create local policy with respect to the handling of early media, but does not address the case where a network is interconnected with other networks with unknown, untrusted, or different early media policies. Without the kind of information in the P-Early-Media header field, it is not possible for the network to determine whether cut-through of early media could lead to the transfer of data between end-users during session establishment.
RFC 3960 [4]のゲートウェイモデルは、個々のネットワークが初期のメディアの処理に関してローカルポリシーを作成することを可能にしますが、ネットワークが不明、信頼できない、または異なる初期メディアポリシーを持つ他のネットワークと相互接続されている場合には対処しません。。P-hearly-mediaヘッダーフィールドに情報の種類がなければ、ネットワークがセッションの確立中にエンドユーザー間でデータの転送につながる可能性があるかどうかをネットワークが判断することはできません。
Thus, the private header extension in this document is a natural extension of the gateway model of RFC 3960 [4] that is applicable within a transitive trust domain.
したがって、このドキュメントのプライベートヘッダー拡張は、RFC 3960 [4]のゲートウェイモデルの自然な拡張であり、これは推移的な信頼ドメイン内で適用可能です。
This document defines a new P-Early-Media header field for the purpose of requesting and authorizing requests for backward and/or forward early media. A UAC capable of recognizing the P-Early-Media header field may include the header field in an INVITE request. The P-Early-Media header field in an INVITE request contains the "supported" parameter.
このドキュメントでは、後方および/またはフォワードアーリーメディアのリクエストを要求および承認する目的で、新しいP-hearly-mediaヘッダーフィールドを定義します。p-hearly-mediaヘッダーフィールドを認識できるUACには、招待状リクエストにヘッダーフィールドを含めることができます。招待リクエストのp-hearly-mediaヘッダーフィールドには、「サポートされている」パラメーターが含まれています。
As members of the Trust Domain, each proxy receiving an INVITE request must decide whether to insert or delete the P-Early-Media header field before forwarding.
Trust Domainのメンバーとして、招待リクエストを受信する各プロキシは、転送前にP-Early-Mediaヘッダーフィールドを挿入または削除するかどうかを決定する必要があります。
A UAS receiving an INVITE request can use the presence of the P-Early-Media header field in the request to decide whether to request early media authorization in subsequent messages towards the UAC. After receiving an incoming INVITE request, the UAS requesting backward and/or forward early media will include the P-Early-Media header field in a message towards the UAC within the dialog, including direction parameter(s) that identify for each media line in the session whether the early media request is for backward media, forward media, both, or neither. The UAS can change its request for early media by including a modified P-Early-Media header field in a subsequent message towards the UAC within the dialog.
招待リクエストを受信したUASは、リクエストでP-hearly-mediaヘッダーフィールドの存在を使用して、UACへの後続のメッセージで早期のメディア許可を要求するかどうかを決定することができます。着信招待リクエストを受け取った後、UASは後方および/またはフォワードアーリーメディアを要求した後、ダイアログ内のUACへのメッセージにp-hearly-mediaヘッダーフィールドを含めます。セッションは、早期メディアの要求が後方メディア、フォワードメディア、その両方、またはどちらでもないかどうかです。UASは、ダイアログ内のUACへの後続のメッセージに修正されたP-Eryly-Mediaヘッダーフィールドを含めることにより、初期メディアのリクエストを変更できます。
Each proxy in the network receiving the P-Early-Media header field in a message towards the UAC has the responsibility for assuring that the early media request comes from an authorized source. If a P-Early-Media header field arrives from either an untrusted source, a source not allowed to send backward early media, or a source not allowed to receive forward early media, then the proxy may remove the P-Early-Media header field or alter the direction parameter(s) of the P-Early-Media header field before forwarding the message, based on local policy.
UACへのメッセージでp-hearly-mediaヘッダーフィールドを受信するネットワーク内の各プロキシには、早期のメディアリクエストが承認されたソースからのものであることを保証する責任があります。P-hearly-mediaヘッダーフィールドが信頼できないソース、逆方向の早期メディアを送信することを許可されていないソース、またはフォワードの早期メディアの受信を許可されていないソースから到着した場合、プロキシはp-hearly-mediaヘッダーフィールドを削除する場合がありますまたは、ローカルポリシーに基づいて、メッセージを転送する前に、p-hearly-mediaヘッダーフィールドの方向パラメーターを変更します。
A proxy in the network not receiving the P-Early-Media header field in a message towards the UAC may insert one based on local policy.
UACへのメッセージでP-Early-Mediaヘッダーフィールドを受信していないネットワーク内のプロキシは、ローカルポリシーに基づいて1つを挿入する場合があります。
If the proxy also performs gating of early media, then it uses the parameter(s) of the P-Early-Media header field to decide whether to open or close the gates for backward and forward early media flow(s) between the UAs. The proxy performing gating of early media may also add a "gated" parameter to the P-Early-Media header field before forwarding the message so that other gating proxies in the path can choose to leave open their gates.
プロキシが初期のメディアのゲーティングを実行する場合、P-hearly-mediaヘッダーフィールドのパラメーターを使用して、UAS間の前後の早期メディアフローのためにゲートを開閉するか閉じるかを決定します。初期のメディアのゲーティングを実行するプロキシは、メッセージを転送する前にP-Early-Mediaヘッダーフィールドに「ゲート」パラメーターを追加して、パス内の他のゲーティングプロキシがゲートを開くことを選択できるようにすることもできます。
If the UAC is a trusted server within the network (e.g., a PSTN gateway), then the UAC may use the parameter(s) of the P-Early-Media header field in messages received from the UAS to decide whether to perform early media gating or cut-through and to decide whether or not to render backward early media in preference to generating ringback based on the receipt of a 180 Ringing response.
UACがネットワーク内の信頼できるサーバー（PSTNゲートウェイなど）である場合、UACはUASから受信したメッセージでP-hearly-mediaヘッダーフィールドのパラメーターを使用して、早期メディアを実行するかどうかを決定できます。ゲーティングまたはカットスルー、および180のリンギング応答の受領に基づいてリングバックを生成することを好むより後方への初期メディアをレンダリングするかどうかを決定します。
If the UAC is associated with user equipment, then the network will have assigned a proxy the task of performing early media gating, so that the parameter(s) of the P-Early-Media header field received at such a UAC do not require that the UAC police the early media flow(s), but they do provide additional information that the UAC may use to render media.
UACがユーザー機器に関連付けられている場合、ネットワークはプロキシに初期のメディアゲーティングを実行するタスクを割り当て、そのようなUACで受け取ったP-ALY-MEDIAヘッダーフィールドのパラメーターが必要ではないようにします。UACは初期のメディアの流れを警察しますが、UACがメディアをレンダリングするために使用する可能性のある追加情報を提供します。
The UAC and proxies in the network may also insert, delete, or modify the P-Early-Media header field in messages towards the UAS within the dialog according to local policy, but the interpretation of the header field when used in this way is a matter of local policy and not defined herein. The use of direction parameter(s) in this header field could be used to inform the UAS of the final early media authorization status.
ネットワーク内のUACおよびプロキシは、ローカルポリシーに従ってダイアログ内のUASに向けてメッセージのP-EARLY-MEDIAヘッダーフィールドを挿入、削除、または変更することもできますが、この方法で使用される場合のヘッダーフィールドの解釈は、ここで定義されていないローカルポリシーの問題。このヘッダーフィールドでの方向パラメーターの使用を使用して、UASに最終的な早期メディア認証ステータスを通知できます。
The P-Early-Media header field does not apply to any SDP with Content-Disposition: early-session [3].
P-hearly-mediaヘッダーフィールドは、コンテンツディスポジションのあるSDPには適用されません：早期セッション[3]。
When parallel forking occurs, there is no reliable way to correlate early media authorization in a dialog with the media from the corresponding endpoint unless one can assume the use of symmetric RTP, since the SDP messages do not identify the RTP source address of any media stream. When a UAC or proxy receives multiple early dialogs and cannot accurately identify the source of each media stream, it SHOULD use the most restrictive early media authorization it receives on any of the dialogs to decide the policy to apply towards all received media. When early media usage is desired for any reason and one cannot assume the use of symmetric RTP, it is advisable to disable parallel forking using callerprefs [9].
並列フォーキングが発生した場合、SDPメッセージはメディアストリームのRTPソースアドレスを識別しないため、対称RTPの使用を引き受けることができない限り、対応するエンドポイントからメディアとのダイアログ内の早期メディア許可を相関させる信頼できる方法はありません。UACまたはプロキシが複数の初期ダイアログを受信し、各メディアストリームのソースを正確に識別できない場合、対象のいずれかで受信する最も制限的な初期メディア認証を使用して、受信したすべてのメディアに適用するポリシーを決定する必要があります。何らかの理由で早期のメディアの使用が望まれ、対称RTPの使用を想定できない場合、CallerPrefsを使用して並列フォーキングを無効にすることをお勧めします[9]。
Although the implementation of media gating is outside the scope of this extension, note that media gating must be implemented carefully in the presence of NATs and protocols that aid in NAT traversal. Media gating may also introduce a potential for media clipping that is similar to that created during parallel forking or any other feature that may disable early media, such as custom ringback.
メディアゲーティングの実装はこの拡張機能の範囲外ですが、NATトラバーサルを支援するNATとプロトコルの存在下では、メディアゲーティングは慎重に実装する必要があることに注意してください。また、メディアゲーティングは、並列フォーキング中に作成されたものと類似したメディアクリッピングの可能性や、カスタムリングバックなどの初期のメディアを無効にする可能性のあるその他の機能に似ている可能性があります。
The P-Early-Media header field with the "supported" parameter MAY be included in an INVITE request to indicate that the UAC or a proxy on the path recognizes the header field.
「サポートされている」パラメーターを備えたP-hearly-mediaヘッダーフィールドは、パス上のUACまたはプロキシがヘッダーフィールドを認識することを示す招待リクエストに含まれる場合があります。
A network entity MAY request the authorization of early media or change a request for authorization of early media by including the P-Early-Media header field in any message allowed by Table 1 within the dialog towards the sender of the INVITE request. The P-Early-Media header field includes one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or "inactive", following the convention used for Session Description Protocol (SDP) [7][8] stream directionality. Each parameter applies, in order, to the media lines in the corresponding SDP messages establishing session media. Unrecognized parameters SHALL be silently discarded. Non-direction parameters are ignored for purposes of early media authorization. If there are more direction parameters than media lines, the excess SHALL be silently discarded. If there are fewer direction parameters than media lines, the value of the last direction parameter SHALL apply to all remaining media lines. A message directed towards the UAC containing a P-Early-Media header field with no recognized direction parameters SHALL NOT be interpreted as an early media authorization request.
ネットワークエンティティは、初期のメディアの承認を要求したり、招待状リクエストの送信者に向けてダイアログ内の表1で許可されているメッセージにP-hearly-mediaヘッダーフィールドを含めることにより、早期メディアの承認要求を変更することができます。P-hearly-mediaヘッダーフィールドには、セッション説明プロトコル（SDP）に使用された慣習に続いて、それぞれが「sendrecv」、「sendonly」、「recvonly」、または "inactive"、「sendrecv」、「sendonly」、「recvonly」、または "Inactive"の1つ以上の方向パラメーターが含まれています。[7] [8]ストリーム方向性。各パラメーターは、セッションメディアを確立する対応するSDPメッセージのメディアラインに適用されます。認識されていないパラメーターは静かに廃棄されなければならない。非向きのパラメーターは、初期のメディア許可の目的で無視されます。メディアラインよりも多くの方向パラメーターがある場合、過剰は静かに廃棄されます。メディアラインよりも方向パラメーターが少ない場合、最後の方向パラメーターの値は、残りのすべてのメディアラインに適用されます。認識された方向パラメーターのないP-hearly-mediaヘッダーフィールドを含むUACに向けられたメッセージは、早期のメディア許可要求として解釈されないものとします。
The parameter value "sendrecv" indicates a request for authorization of early media associated with the corresponding media line, both from the UAS towards the UAC and from the UAC towards the UAS (both backward and forward early media). The value "sendonly" indicates a request for authorization of early media from the UAS towards the UAC (backward early media), and not in the other direction. The value "recvonly" indicates a request for authorization of early media from the UAC towards the UAS (forward early media), and not in the other direction. The value "inactive" indicates either a request that no early media associated with the corresponding media line be authorized, or a request for revocation of authorization of previously authorized early media.
パラメーター値「sendrecv」は、UASに向けてUACに向けてUASに向かうUAS（後方および前方の両方の初期メディア）の両方から、対応するメディアラインに関連する初期メディアの承認の要求を示します。「sendonly」値は、UASからUACへの初期メディアの認可（後方初期メディア）への認可の要求を示しており、他の方向ではありません。値「recvonly」は、UACからUAS（Forward Early Media）への初期メディアの認可の要求を、他の方向ではないことを示します。値「非アクティブ」は、対応するメディアラインに関連する初期のメディアが許可されていないという要求か、以前に認可された初期メディアの承認の取り消し要求のいずれかを示します。
The P-Early-Media header field in any message within a dialog towards the sender of the INVITE request MAY also include the non-direction parameter "gated" to indicate that a network entity on the path towards the UAS is already gating the early media, according to the direction parameter(s). When included in the P-Early-Media header field, the "gated" parameter SHALL come after all direction parameters in the parameter list.
招待リクエストの送信者に向けてダイアログ内のメッセージ内のP-hearly-mediaヘッダーフィールドには、UASへのパス上のネットワークエンティティがすでに初期のメディアを獲得していることを示すために、非方向パラメーター「ゲート」を含めることもできます。、方向パラメーターに応じて。P-hearly-mediaヘッダーフィールドに含まれる場合、「ゲート」パラメーターは、パラメーターリストのすべての方向パラメーターの後に来るものとします。
When receiving a message directed toward the UAC without the P-Early-Media header field and no previous early media authorization request has been received within the dialog, the default early media authorization depends on local policy and may depend on whether the header field was included in the INVITE request. After an early media authorization request has been received within a dialog, and a subsequent message is received without the P-Early-Media header field, the previous early media authorization remains unchanged.
P-hearly-mediaヘッダーフィールドなしでUACに向けられたメッセージを受信し、ダイアログ内で以前の早期メディア認証リクエストを受け取っていない場合、デフォルトの早期メディア認証はローカルポリシーに依存し、ヘッダーフィールドが含まれているかどうかに依存する可能性があります。招待リクエスト。ダイアログ内で早期のメディア許可リクエストが受信され、その後のメッセージがp-hearly-mediaヘッダーフィールドなしで受信された後、以前の初期のメディア許可は変更されません。
The P-Early-Media header field in any message within a dialog towards the UAS MAY be ignored or interpreted according to local policy.
UASに向けてダイアログ内のメッセージ内のP-hearly-mediaヘッダーフィールドは、ローカルポリシーに従って無視または解釈される場合があります。
The P-Early-Media header field does not interact with SDP offer/answer procedures in any way. Early media authorization is not influenced by the state of the SDP offer/answer procedures (including preconditions and directionality) and does not influence the state of the SDP offer/answer procedures. The P-Early-Media header field may or may not be present in messages containing SDP. The most recently received early media authorization applies to the corresponding media line in the session established for the dialog until receipt of the 200 OK response to the INVITE request, at which point all media lines in the session are implicitly authorized. Early media flow in a particular direction requires that early media in that direction is authorized, that media flow in that direction is enabled by the SDP direction attribute for the stream, and that any applicable preconditions [11] are met. Early media authorization does not override the SDP direction attribute or preconditions state, and the SDP direction attribute does not override early media authorization.
P-hearly-mediaヘッダーフィールドは、SDPオファー/回答手順といかなる方法でも相互作用しません。初期のメディア認可は、SDPのオファー/回答手順（前提条件と方向性を含む）の状態に影響されず、SDPオファー/回答手順の状態に影響しません。P-hearly-mediaヘッダーフィールドは、SDPを含むメッセージに存在する場合と存在しない場合があります。最近受け取った初期のメディア認可は、招待要求に対する200 OK応答を受信するまで、ダイアログのために確立されたセッションの対応するメディアラインに適用されます。この時点で、セッションのすべてのメディアラインは暗黙的に許可されます。特定の方向への初期のメディアの流れでは、その方向の早期メディアが承認され、その方向のメディアの流れがストリームのSDP方向属性によって有効になること、および該当する前提条件[11]が満たされることが必要です。早期のメディア認可は、SDP方向属性または前提条件の状態を無効にしないため、SDP方向属性は早期のメディア許可を無効にしません。
Table 1 is an extension of Tables 2 and 3 in RFC 3261 [1] for the P-Early-Media header field. The column "PRA" is for the PRACK method [12]. The column "UPD" is for the UPDATE method [10].
表1は、p-hearly-mediaヘッダーフィールドのRFC 3261 [1]の表2および3の拡張です。列「PRA」はプラック法[12]用です。列「Upd」は、更新方法[10]用です。
Header field where proxy ACK BYE CAN INV OPT REG PRA UPD
________________________________________________________________
P-Early-Media R amr - - - o - - o o
P-Early-Media 18x amr - - - o - - - -
P-Early-Media 2xx amr - - - - - - o o
Table 1: P-Early-Media Header Field
表1：P-hearly-mediaヘッダーフィールド
A User Agent Client MAY include the P-Early-Media header field with the "supported" parameter in an INVITE request to indicate that it recognizes the header field.
ユーザーエージェントクライアントは、ヘッダーフィールドを認識することを示すために、招待リクエストに「サポートされている」パラメーターを備えたP-hearly-mediaヘッダーフィールドを含めることができます。
A User Agent Client receiving a P-Early-Media header field MAY use the parameter(s) of the header field to gate or cut-through early media, and to decide whether to render early media from the UAS to the UAC in preference to any locally generated ringback triggered by a 180 Ringing response. If a proxy is providing the early media gating function for the User Agent Client, then the gateway model of RFC 3960 [4] for rendering of early media is applicable. A User Agent Client without a proxy in the network performing early media gating that receives a P-Early-Media header field SHOULD perform gating or cut-through of early media according to the parameter(s) of the header field.
P-hearly-mediaヘッダーフィールドを受信したユーザーエージェントクライアントは、ヘッダーフィールドのパラメーターをゲートまたはカットスルーアーリーメディアに使用し、UASからUACに初期メディアをUACにレンダリングするかどうかを決定することができます。180のリンギング応答によってトリガーされたローカルで生成されたリングバック。プロキシがユーザーエージェントクライアントに初期のメディアゲーティング機能を提供している場合、初期メディアのレンダリングのためのRFC 3960 [4]のゲートウェイモデルが適用されます。P-hearly-mediaヘッダーフィールドを受信する初期メディアゲーティングを実行するネットワークにプロキシのないユーザーエージェントクライアントは、ヘッダーフィールドのパラメーターに従って初期メディアのゲーティングまたはカットスルーを実行する必要があります。
A User Agent Server that is requesting authorization to send or receive early media MAY insert a P-Early-Media header field with appropriate parameters(s) in any message allowed in table 1 towards the UAC within the dialog. A User Agent Server MAY request changes in early media authorization by inserting a P-Early-Media header field with appropriate parameter(s) in any subsequent message allowed in table 1 towards the UAC within the dialog.
早期メディアを送信または受信する許可を要求しているユーザーエージェントサーバーは、表1にダイアログ内のUACに向けて許可されているメッセージに適切なパラメーターを含むP-EARLY-MEDIAヘッダーフィールドを挿入する場合があります。ユーザーエージェントサーバーは、ダイアログ内のUACに向けて表1で許可されている後続のメッセージに適切なパラメーターを使用して、P-hearly-mediaヘッダーフィールドを挿入することにより、初期のメディア許可の変更を要求する場合があります。
If the P-Early-Media header field is not present in the INVITE request, the User Agent Server MAY choose to suppress early media authorization requests and MAY choose to execute alternate early media procedures.
招待リクエストにP-hearly-mediaヘッダーフィールドが存在しない場合、ユーザーエージェントサーバーは、早期のメディア認証リクエストを抑制することを選択し、代替の早期メディア手順を実行することを選択できます。
When forwarding an INVITE request, a proxy MAY add, retain, or delete the P-Early-Media header field, depending on local policy and the trust relationship with the sender and/or receiver of the request.
招待リクエストを転送する場合、プロキシは、ローカルポリシーとリクエストの送信者および/または受信者との信頼関係に応じて、P-EARLY-MEDIAヘッダーフィールドを追加、保持、または削除できます。
When forwarding a message allowed in Table 1 towards the UAC, a proxy MAY add, modify, or delete a P-Early-Media header field, depending on local policy and the trust relationship with the sender and/or receiver of the message. In addition, if the proxy controls the gating of early media for the User Agent Client, it SHOULD use the contents of the P-Early-Media header field to gate the early media, according to the definitions of the header field parameters defined in clause 8.
表1で許可されているメッセージをUACに転送する場合、プロキシは、ローカルポリシーとメッセージの送信者および/または受信者との信頼関係に応じて、P-hearly-mediaヘッダーフィールドを追加、変更、または削除することができます。さらに、プロキシがユーザーエージェントクライアントの初期メディアのゲーティングを制御する場合、句で定義されているヘッダーフィールドパラメーターの定義に従って、P-hearly-mediaヘッダーフィールドのコンテンツを初期メディアにゲートする必要があります。8。
The syntax of the P-Early-Media header field is described below in ABNF, according to RFC 4234 [5], as an extension to the ABNF for SIP in RFC 3261 [1]. Note that not all combinations of em-param elements are semantically valid.
P-hearly-mediaヘッダーフィールドの構文は、RFC 4234 [5]によると、RFC 3261 [1]のSIPのABNFの拡張として、ABNFで以下で説明されています。Em-Param要素のすべての組み合わせが意味的に有効ではないことに注意してください。
P-Early-Media = "P-Early-Media" HCOLON
[ em-param *(COMMA em-param) ]
em-param = "sendrecv" / "sendonly" / "recvonly"
/ "inactive" / "gated" / "supported" / token
The use of this extension is only applicable inside a "Trust Domain", as defined in RFC 3325 [6]. This document does NOT offer a general early media authorization model suitable for inter-domain use or use in the Internet at large.
この拡張機能の使用は、RFC 3325 [6]で定義されているように、「信頼ドメイン」内でのみ適用されます。このドキュメントは、インターネット全体でのドメイン間の使用または使用に適した一般的な早期メディア認証モデルを提供しません。
There are no confidentiality concerns associated with the P-Early-Media header field. It is desirable to maintain the integrity of the direction parameters in the header field across each hop between servers to avoid the potential for unauthorized use of early media. It is assumed that the P-Early-Media header field is used within the context of the 3GPP IMS trust domain or a similar trust domain, consisting of a collection of SIP servers maintaining pair wise security associations.
P-hearly-mediaヘッダーフィールドに関連する機密性の懸念はありません。初期のメディアの不正使用の可能性を回避するために、サーバー間の各ホップ全体のヘッダーフィールドの方向パラメーターの整合性を維持することが望ましいです。P-hearly-mediaヘッダーフィールドは、3GPP IMSトラストドメインまたは同様の信頼ドメインのコンテキスト内で使用され、ペアワイズセキュリティアソシエーションを維持するSIPサーバーのコレクションで構成されると想定されています。
Within the trust domain of a network it is only necessary to police the use of the P-Early-Media header field at the boundary to user equipment served by the network and at the boundary to peer networks. It is assumed that boundary servers in the trust domain of a network will have local policy for the treatment of the P-Early-Media header field as it is sent to or received from any possible server external to the network. Since boundary servers are free to modify or remove any P-Early-Media header field in SIP messages forwarded across the boundary, the integrity of the P-Early-Media header field can be verified to the extent that the connections to external servers are secured. The authenticity of the P-Early-Media header field can only be assured to the extent that the external servers are trusted to police the authenticity of the header field.
ネットワークの信頼ドメイン内では、ネットワークが提供するユーザー機器への境界およびピアネットワークへの境界での境界にあるP-hearly-mediaヘッダーフィールドの使用を警察することのみが必要です。ネットワークの信頼ドメイン内の境界サーバーには、ネットワークの外部の可能なサーバーに送信または受信されたP-EARLY-MEDIAヘッダーフィールドの処理のためのローカルポリシーがあると想定されています。境界サーバーは、境界を越えて転送されたSIPメッセージのP-hearly-mediaヘッダーフィールドを自由に変更または削除できるため、P-hearly-mediaヘッダーフィールドの整合性は、外部サーバーへの接続が保護されている程度まで検証できます。。P-hearly-mediaヘッダーフィールドの信ity性は、外部サーバーがヘッダーフィールドの信頼性を締結することを信頼している限りのみ保証できます。
Name of Header field: P-Early-Media
ヘッダーフィールドの名前：p-hearly-media
Short form: none
短いフォーム：なし
Registrant: Richard Ejzak ejzak@alcatel-lucent.com
登録者：Richard ejzak ejzak@alcatel-lucent.com
Normative description: Section 8 of this document
規範的説明：このドキュメントのセクション8
The author would like to thank Miguel Garcia-Martin, Jan Holm, Sebastien Garcin, Akira Kurokawa, Erick Sasaki, James Calme, Greg Tevonian, Aki Niemi, Paul Kyzivat, Gonzalo Camarillo, Brett Tate, Jon Peterson, Alfred Hoenes, and David Black for their significant contributions made throughout the writing and reviewing of this document.
著者は、ミゲル・ガルシア・マルティン、ヤン・ホルム、セバスチャン・ガルシン、黒川akira、エリック・ササキ、ジェームズ・カルム、グレッグ・テボニアン、アキ・ニエミ、ポール・キジバット、ゴンザロ・カマリロ、ブレット・テート、ジョン・ペットソン、アルフレッド・ヘネー、そしてデイヴィッド・ブラックに感謝したいと思います。この文書の執筆とレビューを通して行われた重要な貢献について。
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[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] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[3] Camarillo、G。、「セッション開始プロトコル（SIP）の初期セッション処分タイプ」、RFC 3959、2004年12月。
[4] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[4] Camarillo、G。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における初期のメディアとリンギングトーン生成」、RFC 3960、2004年12月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[5] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[6] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[9] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）に対する発信者の好み」、RFC 3841、2004年8月。
[10] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[10] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[11] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[11] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[12] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[12] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[13] 3GPP "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 (Release 7)", 3GPP 23.228, March 2007, ftp://ftp.3gpp.org/specs/archive/23_series/23.228/.
[13] 3GPP "TS 23.228：IPマルチメディアサブシステム（IMS）;ステージ2（リリース7）"、3GPP 23.228、2007年3月、ftp：//ftp.3gpp.org/specs/archive/23_series/23.228/。
[14] 3GPP "TS 24.229: IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 7)", 3GPP 24.229, March 2007, ftp://ftp.3gpp.org/specs/archive/24_series/24.229/.
[14] 3GPP "TS 24.229：SIPおよびSDP、ステージ3（リリース7）"に基づくIPマルチメディアコールコントロールプロトコル、3GPP 24.229、2007年3月、ftp：//ftp.3gpp.org/specs/archive/24_series/24.229/。
ETSI documents can be downloaded from the ETSI Web server, "http://www.etsi.org/". Any 3GPP document can be downloaded from the 3GPP Web server, "http://www.3gpp.org/". See specifications.
ETSIドキュメントは、ETSI Webサーバー「http://www.etsi.org/」からダウンロードできます。3GPPドキュメントは、3GPP Webサーバー「http://www.3gpp.org/」からダウンロードできます。仕様を参照してください。
Authors Address
著者の住所
Richard Ejzak Alcatel-Lucent 1960 Lucent Lane Naperville, IL 60566 USA
リチャード・エイザック・アルカテル・ルーセント1960ルーセント・レーン・ネーパービル、イリノイ州60566 USA
Phone: +1 630 979 7036
EMail: ejzak@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。