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-ヘッダ）拡張
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-ヘッダ）を記述するメディアは、第三世代パートナーシッププロジェクト（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.
この文書では、ネットワークのアーリーメディアポリシーで許可されたときに[1]特定のSIPネットワーク内のメッセージは、逆方向および/または順方向アーリーメディアのカットスルーを承認するためにSIP内で使用するためのP-アーリーメディアヘッダーフィールドの使用を定義します関与。以下の特徴を有するP-アーリーメディアヘッダフィールドは、例えば、3GPP IMSなどのSIPネットワークでの使用のために意図されている[13] [14]：その初期メディアポリシーは、エンドユーザとの間のアーリーメディアの交換を禁止しています。それは、初期メディアに関して、不明な信頼できない、または異なるポリシーを持っている他の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-アーリーメディアヘッダーフィールドは、ネットワーク内の他のノードにこの初期メディアポリシー決定を通信するために、この境界ノードのための手段を提供します。
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]。こうした信頼ドメイン内のノードは、明示的に信頼ドメイン内の早期メディアポリシーで許可された場合にのみ、初期のメディア要求を認可するために自社のユーザーおよびエンドシステムから信頼されています。
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.
この拡張は、パラレルフォーキングと一緒に使用することができるが、RFC 3960に記載されているように一つは対称RTPの使用を想定することができない限り、それは、[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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
3GPP - 第三世代パートナーシッププロジェクトABNF - 増補バッカス記法[5] DTMF - デュアルトーン多重周波数のETSI - 欧州電気通信標準化協会IMS - インターネット・プロトコル・マルチメディア・サブシステム[13] [14] MIME - 多目的インターネットメール拡張NAT - ネットワークアドレス変換のPSTN - 公衆交換電話網
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]
SDP - セッション記述プロトコル[7] SIP - セッション開始プロトコル[1] TISPAN - 通信と高度なネットワークUAのためのインターネット収束サービスおよびプロトコル - ユーザエージェント[1] UAC - ユーザエージェントクライアント[1] UAS - ユーザエージェントサーバ[ 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ネットワークでは、後方の初期メディアは、ユーザエージェントクライアント（UAC）に向けてユーザエージェントサーバ（UAS）から流出します。フォワード初期メディアは、UASの方にUACから流れ。デフォルトでは、SIPネットワークは、メディアパスが確立されると、ユーザデータを運ぶことができる初期メディアの両方の形式を、許可します。アーリーメディアはなく、UASとしてSIPユーザ機器と、典型的にUASとしてPSTNゲートウェイを有することが望ましいです。
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エンド装置と初期メディア「の」UAS、ゲートとして機能する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ネットワークが相互接続されたネットワークは、このように、いくつかの状況下でアーリーメディア内のユーザデータの交換を可能にする、互換性のアーリーメディアポリシーを実装していることを保証する手段を持たなくてもよいです。ネットワーク「は、」ユーザUACなどの機器と相互接続されたネットワークを持つすべてのアーリーメディアを許可する場合、例えば、「B」は、UAS、「A」でUACとしてユーザ機器との間で確立された任意のセッションとユーザ装置とユーザ装置とのすべてのアーリーメディアを可能にします「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ネットワークへの境界上のサーバは、許可後方アーリーメディアの兆候は、ネットワーク内のUACの外部にUASから通過しないことを保証することができます。これにより、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のための順方向アーリーメディアフローをゲーティングネットワーク機器は、ネットワークの外側前方にアーリーメディアを受信するために認可され、終端エンドポイント、および他のSIPデバイスを区別しなければなりませんユーザー・データを含む前方早期メディアを受信する権限がありません。この権限は、着信側が前方にアーリーメディアを受信するために認可されていることを識別する後方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-アーリーメディアヘッダーフィールド内の情報の種類せず、それは不可能です。
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.
したがって、この文書のプライベートヘッダ拡張[4]それは推移的な信頼ドメイン内で適用可能であるRFC 3960のゲートウェイモデルの自然な拡張です。
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-早期メディアヘッダフィールドを定義します。 P-アーリーメディアヘッダーフィールドを認識することができるUACはINVITE要求のヘッダフィールドを含んでもよいです。 INVITE要求におけるP-早期メディアヘッダフィールドは、「サポート」のパラメータが含まれています。
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.
信頼ドメインのメンバーとして、INVITEリクエストを受信する各プロキシは、転送前にP-アーリーメディアヘッダーフィールドを挿入または削除するかどうかを決定しなければなりません。
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.
リクエストにP-早期メディアヘッダフィールドの存在を使用することができINVITEリクエストを受信するUASは、UACへのその後のメッセージで初期メディアの承認を要求するかどうかを決定します。各メディア・ラインにするための特定方向パラメータ（単数または複数）を含む、着信INVITE要求を受信した後、UASは、後方要求および/またはダイアログ内UACに向かってメッセージにP-アーリーメディアヘッダーフィールドが含まれるアーリーメディアを転送しますセッションアーリーメディアリクエストが後方メディア、前方メディア、両方、またはどちらなのか。 UASは、ダイアログ内のUACに向かって後続のメッセージ中の変性P-アーリーメディアヘッダーフィールドを含むことにより、アーリーメディアのためにその要求を変更することができます。
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-早期メディアヘッダフィールドを受け、ネットワーク内の各プロキシには、アーリーメディアリクエストが正規のソースから来ていることを確実にする責任があります。 P-早期メディアヘッダーフィールドはどちらか信頼できないソース、後方初期メディアを送信することを許可されていないソース、またはソースから到着した場合、プロキシはP-早期メディアヘッダフィールドを削除することができ、前方の早期メディアを受信することはできませんまたはローカルポリシーに基づいて、メッセージを転送する前に、P-アーリーメディアヘッダーフィールドの方向パラメータ（複数可）を変えます。
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-アーリーメディアヘッダーフィールドを受けていないネットワーク内のプロキシはローカルポリシーに基づいていずれかを挿入することができます。
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.
プロキシはまた、アーリーメディアのゲーティングを行った場合、それは、UASの間に前後アーリーメディアフロー（S）のためのゲートを開閉するかどうかを決定するためにP-アーリーメディアヘッダーフィールドのパラメータ（複数も可）を使用します。初期メディアの代理を行うゲーティングはまた、パス内の他のゲーティングプロキシはそれらのゲートを開く残すことを選択できるように、メッセージを転送する前に、P-早期メディアヘッダフィールドに「ゲーティング」パラメータを追加することもできます。
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-アーリーメディアヘッダーフィールドのパラメータ（複数も可）を使用することができますゲーティングやカットスルーと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は、ユーザ機器に関連付けられている場合P-アーリーメディアヘッダーフィールドは、UACで受信のパラメータ（複数可）ことを必要としないように、ネットワークは、プロキシに初期メディアゲーティングを行うタスクを割り当てられているであろうUAC警察早期メディアフロー（S）が、彼らは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-アーリーメディアヘッダーフィールドを変更しますが、この方法で使用されるヘッダフィールドの解釈があるかもしれローカルポリシーの問題で、ここで定義されていません。このヘッダフィールドの方向パラメータ（単数または複数）の使用は、最終的なアーリーメディア認証ステータスのUASに知らせるために使用することができます。
The P-Early-Media header field does not apply to any SDP with Content-Disposition: early-session [3].
初期セッション[3]：P-早期メディアヘッダフィールドには、Content-処分で任意のSDPには適用されません。
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].
並列フォークが発生した場合、1は対称RTPの使用を想定することができない限り、SDPメッセージは、任意のメディアストリームのRTP送信元アドレスを特定していないので、対応するエンドポイントからのメディアとの対話の早期メディアの認可を相関させる信頼できる方法はありません。 UACまたはプロキシが複数の早期ダイアログを受信して、正確に各メディアストリームのソースを識別することができない場合は、それが受信したすべてのメディアの方に適用するポリシーを決定するためのダイアログのいずれかを受けた最も限定的な初期メディアの許可を使用すべきです。アーリーメディアの使用が何らかの理由のために所望され、1つは、対称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-アーリーメディアヘッダーフィールドは、UACまたはパス上のプロキシはヘッダフィールドを認識することを示すために、INVITE要求に含まれるかもしれません。
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.
ネットワークエンティティは、初期メディアの許可を要求したり、INVITEリクエストの送信者に向けて、ダイアログ内の表1で許可されているすべてのメッセージにP-早期メディアヘッダフィールドを含めることによって、初期メディアの許可の要求を変更することがあります。セッション記述プロトコル（SDP）のために使用される規則以下「のsendrecv」、「sendonlyの」、「recvonlyで」、または「非アクティブ」：P-アーリーメディアヘッダーフィールドは、それぞれの値のいずれかを有し、一つ以上の方向パラメータを含みます[7] [8]のストリーム指向。各パラメータには、セッションのメディアを確立し、対応するSDPメッセージ内のメディアラインに順番に適用されます。認識できないパラメータは静かに捨てられるものとします。非方向パラメータは、初期メディアの許可の目的のために無視されます。メディア・ラインよりも方向パラメータが存在する場合、過剰は静かに捨てられるもの。メディアラインよりも少ない方向パラメータがある場合は、最後の方向パラメータの値は、残りのすべてのメディアラインに適用しなければなりません。 UACがない認識方向パラメータでP-アーリーメディアヘッダーフィールドを含むに向けられたメッセージは、アーリーメディア認証要求として解釈されるべきではありません。
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」はUACに向かっUASからUACとUASに向かって（後方及び前方アーリーメディアの両方）の両方から、対応するメディア・ラインに関連する初期メディアの認可のための要求を示します。値は「sendonlyで」UAC（後方初期メディア）へのUASからではなく、他の方向における初期メディアの承認のための要求を示します。値は「recvonlyで」UAS（前方初期メディア）へのUACから初期メディアの承認のための要求を示す、とされていない他の方向に。値が「非アクティブ」は、対応するメディア・ラインに関連付けられている初期のメディアが許可しないことが要求、または以前に認可初期メディアの許可の取消しの要求のいずれかを示します。
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-早期メディアヘッダフィールドINVITEリクエストの送信者に向けたダイアログ内の任意のメッセージでもUASへのパス上のネットワークエンティティは、すでに初期メディアをゲート制御していることを示すために、「ゲーテッド」非方向パラメータを含んでもよい（MAY） 、方向パラメータ（複数可）に係ります。 P-早期メディアヘッダフィールドに含まれる場合、「ゲーティング」パラメータは、パラメータリスト内のすべての方向パラメータの後に来るものとします。
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-アーリーメディアヘッダーフィールドと以前のアーリーメディア許可要求なしUACに向けられたメッセージを受信したときにダイアログ内で受信された、デフォルトの初期メディアの認証は、ローカルポリシーに依存し、ヘッダフィールドが含まれていたかどうかに依存してもよいですINVITEリクエストインチ初期メディア認証要求をダイアログ内に受信された、およびそれに続くメッセージはP-早期メディアヘッダフィールドなしに受信された後、以前の初期メディアの許可は変更されません。
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-アーリーメディアヘッダーフィールドは、ローカルポリシーに従って無視されるか、または解釈することができます。
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-早期メディアヘッダフィールドは、どのような方法でSDPオファー/アンサー手続きと相互作用しません。早期メディア許可が（前提条件と方向性を含む）SDPオファー/アンサー手続きの状態に影響されず、SDPオファー/アンサー手続きの状態に影響を与えません。 P-アーリーメディアヘッダーフィールドは、またはSDPを含むメッセージ中に存在してもしなくてもよいです。最も最近受信初期メディアの認可は、セッション内のすべてのメディアラインが暗黙的に許可されている時点で、INVITE要求、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は、RFC 3261で、表2の拡張及び3である[1] P-アーリーメディアヘッダーフィールドのため。カラム「PRA」とは、PRACK方法[12]のためのものです。カラム「UPD」は、UPDATEメソッド[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-早期メディアヘッダーフィールド
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.
ユーザエージェントクライアントは、それがヘッダフィールドを認識していることを示すために、INVITEリクエストで「サポート」パラメータでP-早期メディアヘッダフィールドを含んでいてもよいです。
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.
ゲートまたはカットスルー初期メディアにヘッダフィールドのパラメータ（複数も可）を使用することができる、と優先してUACにUASから初期メディアをレンダリングするかどうかを決定するためにP-アーリーメディアヘッダーフィールドを受信するユーザエージェントクライアント任意のローカルリングバック180リンギング応答によってトリガ生成。プロキシはユーザエージェントクライアントのための初期メディアゲーティング機能を提供している場合は、[4]初期メディアのレンダリングのためのRFC 3960の後、ゲートウェイモデルが適用されます。ヘッダフィールドのパラメータ（複数も可）に従うアーリーメディアのスルーカットゲーティングを実行するか、またはべきであるP-アーリーメディアヘッダーフィールドを受信アーリーメディア・ゲーティングを行うネットワーク内のプロキシなしのユーザエージェントクライアント。
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.
初期メディアを送信または受信するための許可を要求しているユーザエージェントサーバは、ダイアログ内UACに向けて表1で許可されたメッセージで適切なパラメータ（S）とP-早期メディアヘッダフィールドを挿入することができます。ユーザエージェントサーバは、ダイアログ内のUACに向かって表1で許可任意の後続のメッセージにおいて適切なパラメータ（単数または複数）とP-アーリーメディアヘッダーフィールドを挿入することにより、アーリーメディア許可の変更を要求することができます。
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-早期メディアヘッダーフィールドはINVITEリクエストに存在しない場合、ユーザエージェントサーバは、初期メディア認証要求を抑制することを選択するかもしれないと代替早期メディアプロシージャを実行することを選択するかもしれません。
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.
INVITEリクエストを転送するとき、プロキシはローカルポリシーと要求の送信者及び/又は受信機との信頼関係に応じて、P-アーリーメディアヘッダーフィールドを追加、保持、または削除することができます。
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.
UACに向けて、表1で許可メッセージを転送するとき、プロキシはローカルポリシーと、メッセージの送信者及び/又は受信機との信頼関係に応じて、P-アーリーメディアヘッダーフィールドを、追加、変更、または削除することができます。プロキシはユーザエージェントクライアントのための初期メディアのゲートを制御する場合、また、それは句で定義されたヘッダフィールドのパラメータの定義によると、ゲート初期メディアをするP-早期メディアヘッダフィールドの内容を使用すべきです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-アーリーメディアヘッダフィールドの構文は、RFC 3261でSIPのためのABNFへの拡張[1]として、[5] RFC 4234によれば、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-早期メディアのヘッダフィールドに関連した機密性の懸念はありません。初期メディアの不正使用の可能性を避けるために、サーバ間の各ホップ間のヘッダーフィールドの方向パラメータの整合性を維持することが望ましいです。 P-アーリーメディアヘッダーフィールドはペアワイズセキュリティアソシエーションを維持するSIPサーバの集合からなる、3GPP IMS信頼ドメインまたは同様の信頼ドメインのコンテキスト内で使用されているものとします。
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-早期メディアのヘッダフィールドの使用を取り締まることだけが必要です。それがネットワークの外部の任意の可能なサーバーとの間で送受信されるように、ネットワークの信頼ドメイン内の境界のサーバーはP-早期メディアヘッダフィールドの治療のためのローカルポリシーを持っていることが想定されます。境界のサーバーが境界を越えて転送されたSIPメッセージ内の任意のP-早期メディアヘッダーフィールドを変更または削除するのは自由ですので、P-早期メディアヘッダフィールドの整合性は、外部のサーバへの接続が確保される程度に検証することができます。 P-早期メディアヘッダフィールドの信憑性は、唯一の外部サーバーは、ヘッダフィールドの信憑性を取り締まるために信頼されている程度に確保することができます。
Name of Header field: P-Early-Media
ヘッダフィールド名：P-早期メディア
Short form: none
短い形式：なし
Registrant: Richard Ejzak ejzak@alcatel-lucent.com
登録者：リチャード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.
著者はミゲル・ガルシア・マーティン、ヤン・ホルム、セバスチャンGarcin、明黒川、エリック佐々木、ジェームズCALME、グレッグTevonian、アキニエミ、ポールKyzivat、ゴンサロ・カマリロ、ブレット・テイト、ジョンピーターソン、アルフレッドHoenes、そしてデヴィッド・ブラックに感謝したいと思いますこのドキュメントの執筆や見直しを通じて作られた彼らの重要な貢献のために。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[3]カマリロ、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]カマリロ、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]クロッカー、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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼されたネットワーク内でアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[9]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3841 "セッション開始プロトコル（SIP）のための発呼側プリファレンス"、2004年8月。
[10] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[10]ローゼンバーグ、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]カマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[12] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
、RFC 3262、2002年6月[12]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[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に基づくIPマルチメディア呼制御プロトコル;ステージ3（リリース7）"、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.
Authors Address
著者の住所
Richard Ejzak Alcatel-Lucent 1960 Lucent Lane Naperville, IL 60566 USA
リチャードEjzakアルカテル・ルーセント1960ルーセントレーンネーパーヴィル、IL 60566 USA
Phone: +1 630 979 7036 EMail: ejzak@alcatel-lucent.com
電話：+1 630 979 7036 Eメール：ejzak@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。