Internet Engineering Task Force (IETF) F. Andreasen
Request for Comments: 5898 Cisco Systems
Category: Standards Track G. Camarillo
ISSN: 2070-1721 Ericsson
D. Oran
D. Wing
Cisco Systems
July 2010
Connectivity Preconditions for Session Description Protocol (SDP) Media Streams
セッション記述プロトコル（SDP）のメディアストリームの接続性の前提条件
Abstract
抽象
This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation.
この文書では、セッション記述プロトコル（SDP）の前提条件フレームワークの新しい接続前提条件を定義します。接続の前提条件は、メディアストリーム接続が正常に検証されるまで、セッション確立または修正を遅延させるために使用することができます。検証方法は、媒体に使用されるトランスポートの種類に応じて変えることができます。信頼性のないデータグラムがUDPのようなトランスポートのために、検証は、データまたは制御パケットを持つストリームをプロービングが含まれます。 TCPのような信頼性の高い接続指向のトランスポートのために、検証は、単に成功した接続の確立により、または状況に応じて、データまたは制御パケットとの接続をプロービングすることによって達成することができます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5898.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5898で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Connectivity Precondition Definition . . . . . . . . . . . . . 4
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operational Semantics . . . . . . . . . . . . . . . . . . 4
3.3. Status Type . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 5
4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 6
4.1. Correlation of Dialog to Media Stream . . . . . . . . . . 7
4.2. Explicit Connectivity Verification Mechanisms . . . . . . 7
4.3. Verifying Connectivity for Connection-Oriented
Transports . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Connectivity and Other Precondition Types . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
The concept of a Session Description Protocol (SDP) [RFC4566] precondition in the Session Initiation Protocol (SIP) [RFC3261] is defined in RFC 3312 [RFC3312] (updated by RFC 4032 [RFC4032]). A precondition is a condition that has to be satisfied for a given media stream in order for session establishment or modification to proceed. When the precondition is not met, session progress is delayed until the precondition is satisfied or the session establishment fails. For example, RFC 3312 [RFC3312] defines the Quality of Service precondition, which is used to ensure availability of network resources prior to establishing a session (i.e., prior to starting to alert the callee).
セッション記述プロトコル（SDP）は、セッション開始プロトコル（SIP）[RFC3261]の[RFC4566]前提条件の概念は、RFC 3312で定義されている[RFC3312]（RFC 4032によって[RFC4032]を更新）。前提条件は、セッション確立または進行する変形ために所与のメディア・ストリームのために満たさなければならない条件です。前提条件が満たされない場合には前提条件が成立しているか、セッション確立が失敗するまで、セッションの進行が遅れています。例えば、RFC 3312 [RFC3312]は（すなわち、前の呼び出し先に警告するために開始する）セッションを確立する前に、ネットワーク資源の可用性を確保するために使用されるサービスの前提条件、の品質を定義します。
SIP sessions are typically established in order to set up one or more media streams. Even though a media stream may be negotiated successfully through an SDP offer-answer exchange, the actual media stream itself may fail. For example, when there is one or more Network Address Translators (NATs) or firewalls in the media path, the media stream may not be received by the far end. In cases where the media is carried over a connection-oriented transport such as TCP [RFC0793], the connection-establishment procedures may fail. The connectivity precondition defined in this document ensures that session progress is delayed until media stream connectivity has been verified.
SIPセッションは、通常、1つのまたは複数のメディアストリームを設定するために確立されています。メディアストリームは、SDPオファーアンサー交換を通じて正常にネゴシエートすることができるにもかかわらず、実際のメディア・ストリーム自体が失敗することがあります。メディア経路内の1つまたは複数のネットワークアドレス変換（NAT）またはファイアウォールがある場合、例えば、メディア・ストリームが遠端によって受信されなくてもよいです。メディアは、TCP [RFC0793]などの接続指向のトランスポート上で実行される場合には、コネクション確立手順が失敗することがあります。この文書で定義された接続の前提条件は、メディアストリームの接続性が確認されるまでのセッションの進捗が遅れていることを保証します。
The connectivity precondition type defined in this document follows the guidelines provided in RFC 4032 [RFC4032] to extend the SIP preconditions framework.
この文書で定義された接続前提条件タイプは、SIP前提条件フレームワークを拡張するためにRFC 4032 [RFC4032]に提供されるガイドラインに従います。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The connectivity precondition type is defined by the string "conn", and hence we modify the grammar found in RFC 3312 [RFC3312] and RFC 5027 [RFC5027] as follows:
接続前提条件タイプは、文字列「connの」によって定義され、それゆえ我々は、RFC 3312 [RFC3312]及びRFC 5027 [RFC5027]以下のように見出される文法を修正されます。
precondition-type = "conn" / "sec" / "qos" / token
前提型= "CONN" / "秒" / "のQoS" /トークン
This precondition tag is registered with the IANA in Section 8.
この前提条件タグは、セクション8にIANAに登録されています。
According to RFC 4032 [RFC4032], documents defining new precondition types need to describe the behavior of UAs (User Agents) from the moment session establishment is suspended due to a set of preconditions, until it is resumed when these preconditions are met. An entity that wishes to delay session establishment or modification until media stream connectivity has been established uses this precondition-type in an offer. When a mandatory connectivity precondition is received in an offer, session establishment or modification is delayed until the connectivity precondition has been met (i.e., until media stream connectivity has been established in the desired direction or directions). The delay of session establishment defined here implies that alerting of the called party does not occur until the precondition has been satisfied.
RFC 4032 [RFC4032]によると、新しい前提条件タイプを定義する文書は、これらの前提条件が満たされたときに、それが再開されるまで、起因する前提条件のセットに中断された瞬間のセッション確立からのUAの行動（ユーザエージェント）を記述する必要があります。メディアストリーム接続が確立されるまでセッション確立または修正を遅らせることを望むエンティティが提供でこの前提条件タイプを使用しています。必須の接続前提条件を提供、セッション確立中に受信されるか、または接続前提条件が満たされるまで修正が遅れている場合（すなわち、メディア・ストリーム接続が所望の方向または方向に確立されるまで）。ここで定義されたセッション確立の遅れは、前提条件が満たされたまで、着信側の警告が発生しないことを意味します。
Packets may be both sent and received on the media streams in question. However, such packets SHOULD be limited to packets that are necessary to verify connectivity between the two endpoints involved on the media stream. That is, the underlying media stream SHOULD NOT be cut through. For example, Interactive Connectivity Establishment (ICE) connectivity checks [RFC5245] and TCP SYN, SYN-ACK, and ACK packets can be exchanged on media streams that support them as a way of verifying connectivity.
パケットは両方送信され、当該のメディアストリーム上で受信することができます。しかしながら、そのようなパケットは、メディアストリームに関与する2つのエンドポイント間の接続性を確認するために必要なパケットに限定されるべきです。これは、基礎となるメディア・ストリームがカットスルーされるべきではありません。例えば、インタラクティブ接続確立（ICE）接続性チェック[RFC5245]とTCP SYN、SYN-ACK、及びACKパケットは、接続を検証する方法として、それらをサポートするメディアストリーム上で交換することができます。
Some media streams are described by a single 'm' line but, nevertheless, involve multiple addresses. For example, RFC 5109 [RFC5109] specifies how to send FEC (Forward Error Correction) information as a separate stream (the address for the FEC stream is provided in an 'a=fmtp' line). When a media stream consists of multiple destination addresses, connectivity to all of them MUST be verified in order for the precondition to be met. In the case of RTP media streams [RFC3550] that use RTCP, connectivity MUST be verified for both RTP and RTCP; the RTCP transmission interval rules MUST still be adhered to.
一部のメディアストリームは、単一の「m」行で記述しかし、それにもかかわらず、複数のアドレスを含んでいます。例えば、RFC 5109 [RFC5109]は（A「=のfmtp」線に設けられたFECストリームのアドレス）を別のストリームとしてFEC（前方誤り訂正）情報を送信する方法を指定します。メディアストリームは、複数の宛先アドレスで構成されている場合前提条件が満たされるため、それらのすべてへの接続が順番に検証されなければなりません。 RTCPを使用するRTPメディアストリーム[RFC3550]の場合、接続はRTPとRTCPの両方のために検証されなければなりません。 RTCP送信間隔ルールは依然としてに接着しなければなりません。
RFC 3312 [RFC3312] defines support for two kinds of status types -- namely, segmented and end-to-end. The connectivity precondition-type defined here MUST be used with the end-to-end status type; use of the segmented status type is undefined.
すなわち、セグメントおよびエンドツーエンド - RFC 3312 [RFC3312]は、ステータスタイプの二種類のサポートを定義します。ここで定義された接続前提条件タイプは、エンドツーエンドのステータスタイプで使用されなければなりません。セグメント化されたステータスタイプの使用が定義されていません。
The direction attributes defined in RFC 3312 [RFC3312] are interpreted as follows:
次のようにRFC 3312 [RFC3312]で定義された方向属性が解釈されます。
o send: the party that generated the session description is sending packets on the media stream to the other party, and the other party has received at least one of those packets. That is, there is connectivity in the forward (sending) direction.
O送信：セッション記述を生成した当事者は、相手方にメディアストリームのパケットを送信され、他の当事者は、それらのパケットの少なくとも一つを受けています。つまり、接続が（送信）方向が順方向であり、です。
o recv: the other party is sending packets on the media stream to the party that generated the session description, and this party has received at least one of those packets. That is, there is connectivity in the backwards (receiving) direction.
Oのrecv：相手がセッション記述を生成したパーティにメディアストリーム上でパケットを送信していますが、このパーティーは、それらのパケットの少なくとも一つを受けています。すなわち、逆方向（受信）方向の接続性があるれています。
o sendrecv: both the send and recv conditions hold.
O SENDRECV：両方の送信とrecvの条件が成立します。
Note that a "send" connectivity precondition from the offerer's point of view corresponds to a "recv" connectivity precondition from the answerer's point of view, and vice versa. If media stream connectivity in both directions is required before session establishment or modification continues, the desired status needs to be set to "sendrecv".
ビューの提供者の視点から「送信」接続の前提条件は、ビューの回答の点から「RECV」接続前提条件に対応し、逆もまた同様であることに注意してください。両方向のメディアストリーム接続が必要な場合はセッション確立または修正を続行する前に、必要なステータスが「SENDRECV」に設定する必要があります。
Connectivity preconditions may have a strength-tag of either "mandatory" or "optional".
接続性の前提条件は、「必須」または「オプション」のいずれかの強タグを有することができます。
When a mandatory connectivity precondition is offered and the answerer cannot satisfy the connectivity precondition (e.g., because the offer does not include parameters that enable connectivity to be verified without media cut through) the offer MUST be rejected as described in RFC 3312 [RFC3312].
必須の接続前提条件が提供され、（メディアを介して切断することなく、オファーを検証する接続を可能なパラメータが含まれていないため、例えば）回答が接続前提条件を満たすことができない場合、RFC 3312 [RFC3312]に記載されているようにオファーが拒否されなければなりません。
When an optional connectivity precondition is offered, the answerer MUST generate its answer SDP as soon as possible. Since session progress is not delayed in this case, it is not known whether the associated media streams will have connectivity. If the answerer wants to delay session progress until connectivity has been verified, the answerer MUST increase the strength of the connectivity precondition by using a strength-tag of "mandatory" in the answer.
オプションの接続の前提条件が提供されている場合、回答はできるだけ早くその回答SDPを発生させなければなりません。セッションの進行状況が、この場合には遅延されないので、関連するメディアストリームが接続されていますかどうかは不明です。回答は、接続性が確認されるまでのセッションの進行を遅らせることを望む場合、回答は答えに「必須」の強さ・タグを使用して接続の前提条件の強度を増加させる必要があります。
Note that use of a mandatory precondition requires the presence of a SIP "Require" header with the option tag "precondition". Any SIP UA that does not support a mandatory precondition will reject such requests. To get around this issue, an optional connectivity precondition and the SIP "Supported" header with the option tag "precondition" can be used instead.
必須の前提条件の使用をSIPの存在を必要と注意オプションタグ「前提条件」のヘッダを「要求します」。必須前提条件をサポートしていない任意のSIP UAは、このような要求を拒否します。この問題を回避するには、オプションタグ「前提条件」で、オプションの接続を前提とSIP「サポート」ヘッダが代わりに使用することができます。
Offers with connectivity preconditions in re-INVITEs or UPDATEs follow the rules given in Section 6 of RFC 3312 [RFC3312]. That is:
再度のINVITEまたは更新に接続前提条件とオファーは、RFC 3312 [RFC3312]のセクション6で与えられた規則に従います。あれは：
Both user agents SHOULD continue using the old session parameters until all the mandatory preconditions are met. At that moment, the user agents can begin using the new session parameters.
すべての必須の前提条件が満たされるまで、両方のユーザエージェントは、古いセッションパラメータを使用し続けるべきです。その瞬間、ユーザエージェントは、新たなセッションパラメータを使用して始めることができます。
Media stream connectivity is ascertained by use of a connectivity verification mechanism between the media endpoints. A connectivity verification mechanism may be an explicit mechanism, such as ICE [RFC5245] or ICE TCP [ICE-TCP], or it may be an implicit mechanism, such as TCP. Explicit mechanisms provide specifications for when connectivity between two endpoints using an offer/answer exchange is ascertained, whereas implicit mechanisms do not. The verification mechanism is negotiated as part of the normal offer/answer exchange; however, it is not identified explicitly. More than one mechanism may be negotiated, but the offerer and answerer need not use the same. The following rules guide which connectivity verification mechanism to use:
メディアストリーム接続は、メディアエンドポイント間の接続性検証機構を使用することによって確認されます。接続性検証機構は、ICEのような明示的な機構、[RFC5245]またはICEのTCP [ICE-TCP]であってもよく、またはそれは、TCPなどの暗黙的なメカニズムであり得ます。暗黙のメカニズムがないのに対し、明示的なメカニズムは、オファー/アンサー交換を使用して2つのエンドポイント間の接続性が確認されたときの仕様を提供します。検証メカニズムは、通常のオファー/アンサー交換の一部として交渉されています。しかし、それが明示的に識別されていません。複数のメカニズムが交渉してもよいが、オファー側とアンサーは同じを使用する必要はありません。接続性検証メカニズムを使用するには、次のルールガイド：
o If an explicit connectivity verification mechanism (e.g., ICE) is negotiated, the precondition is met when the mechanism verifies connectivity successfully.
明示的な接続性検証機構（例えば、ICE）がネゴシエートされた場合機構が正常に接続性を検証する場合、前提条件が満たされ、O。
o Otherwise, if a connection-oriented transport (e.g., TCP) is negotiated, the precondition is met when the connection is established.
Oそうでない場合、接続指向のトランスポート（例えば、TCP）がネゴシエートされた場合に接続が確立されると、前提条件が満たされています。
o Otherwise, if an implicit verification mechanism is provided by the transport itself or the media stream data using the transport, the precondition is met when the mechanism verifies connectivity successfully.
暗黙的な検証機構は輸送自体またはトランスポートを使用してメディアストリームデータによって提供される場合機構が正常に接続を検証する際にOそうでなければ、前提条件が満たされています。
o Otherwise, connectivity cannot be verified reliably, and the connectivity precondition will never be satisfied if requested.
oはそうでない場合は、接続が確実に検証することができず、要求された場合の接続前提条件が満たされることはありません。
This document does not mandate any particular connectivity verification mechanism; however, in the following, we provide additional considerations for verification mechanisms.
この文書は、特定の接続性検証メカニズムを強制しません。しかし、以下では、我々は検証メカニズムのための追加の考慮事項を提供します。
SIP and SDP do not provide any inherent capabilities for associating an incoming media stream packet with a particular dialog. Thus, when an offerer is trying to ascertain connectivity, and an incoming media stream packet is received, the offerer may not know which dialog had its "recv" connectivity verified. Explicit connectivity verification mechanisms therefore typically provide a means to correlate the media stream, whose connectivity is being verified, with a particular SIP dialog. However, some connectivity verification mechanisms may not provide such a correlation. In the absence of a mechanism for the correlation of dialog to media stream (e.g., ICE), a UAS (User Agent Server) MUST NOT require the offerer to confirm a connectivity precondition.
SIPとSDPは、特定のダイアログに入ってくるメディアストリームパケットを関連付けるための任意の固有の機能を提供していません。オファー側は、接続性を確認しようとしている、と入ってくるメディアストリームパケットを受信したときにこのように、オファー側が検証その「RECV」接続性を持っていたダイアログ知らないかもしれません。明示的な接続性検証メカニズムは、従って、典型的には、接続特定のSIPダイアログで、検証されているメディアストリームを、相関させる手段を提供します。しかし、いくつかの接続性検証メカニズムは、そのような相関関係を提供することができません。メディアストリーム（例えば、ICE）のダイアログの相関のためのメカニズムが存在しない場合には、UAS（ユーザエージェントサーバ）が接続前提条件を確認するために、オファーを要求してはなりません。
Explicit connectivity verification mechanisms typically use probe traffic with some sort of feedback to inform the sender whether reception was successful. Below we provide two examples of such mechanisms, and how they are used with connectivity preconditions:
明示的な接続性検証メカニズムは、通常、受信が成功したかどうかを送信者に通知するために、フィードバックのいくつかの並べ替えでプローブトラフィックを使用しています。我々はそのようなメカニズムの2つの例を提供し、それらがどのように接続前提条件で使用されている下：
Interactive Connectivity Establishment (ICE) [RFC5245] provides one or more candidate addresses in signaling between the offerer and the answerer and then uses STUN (Simple Traversal of the UDP Protocol through NAT) Binding Requests to determine which pairs of candidate addresses have connectivity. Each STUN Binding Request contains a password that is communicated in the SDP as well; this enables correlation between STUN Binding Requests and candidate addresses for a particular media stream. It also provides correlation with a particular SIP dialog.
インタラクティブ接続確立（ICE）[RFC5245]は申出と回答との間のシグナリングの1つ以上の候補アドレスを提供した後、候補アドレスの対が接続性を有するかを決定する（NATを介してUDPプロトコルの簡易トラバーサル）バインディング要求をSTUNを使用します。各STUNバインディング要求も同様にSDPに伝達されたパスワードが含まれています。これは、特定のメディアストリームの要求と候補アドレスをバインドSTUNとの相関関係を可能にします。また、特定のSIPダイアログとの相関を提供します。
ICE implementations may be either full or lite (see [RFC5245]). Full implementations generate and respond to STUN Binding Requests, whereas lite implementations only respond to them. With ICE, one side is a controlling agent, and the other side is a controlled agent. A full implementation can take on either role, whereas a lite implementation can only be a controlled agent. The controlling agent decides which valid candidate to use and informs the controlled agent of it by identifying the pair as the nominated pair. This leads to the following connectivity precondition rules:
ICE実装が完全またはライトのいずれであってもよい（[RFC5245]を参照）。完全な実装が生成し、liteの実装がそれらだけに反応するのに対し、バインディングリクエストをSTUNに応答します。 ICEと、一の側は制御剤であり、そしてもう一方の側は制御剤です。 liteの実装は唯一の制御剤であり得るのに対し、完全な実装では、いずれかの役割を担うことができます。制御剤は、使用する有効な候補を決定し、ノミネートペアとしてペアを識別することによって、それの制御エージェントに通知します。これは、次の接続の前提条件ルールにつながります：
o A full implementation ascertains both "send" and "recv" connectivity when it operates as a STUN client and has sent a STUN Binding Request that resulted in a successful check for all the components of the media stream (as defined further in ICE).
O完全な実装は、「送信」し、それがSTUNクライアントとして動作し、（ICEでさらに定義される）メディア・ストリームのすべてのコンポーネントのために成功したチェックの結果STUNバインディング要求を送信した「RECV」接続の両方を確かめます。
o A full or a lite implementation ascertains "recv" connectivity when it operates as a STUN server and has received a STUN Binding Request that resulted in a successful response for all the components of the media stream (as defined further in ICE).
それはSTUNサーバとして動作し、メディアストリームのすべてのコンポーネントの成功応答（ICEでさらに定義される）をもたらしSTUNバインディング要求を受信したときに完全またはライト実装O「RECV」接続性を確認します。
o A lite implementation ascertains "send" and "recv" connectivity when the controlling agent has informed it of the nominated pair for all the components of the media stream.
O liteの実装は、「送信」および制御エージェントは、メディアストリームのすべてのコンポーネントにノミネートペアでそれを伝えている「RECV」の接続性を確かめます。
A simpler and slightly more delay-prone alternative to the above rules is for all ICE implementations to ascertain "send" and "recv" connectivity for a media stream when the ICE state for that media stream has moved to Completed.
そのメディアストリームのためのICE状態が完了に移動したときに上記の規則に単純でやや遅れがちな代替案は、すべてのICE実装が「送信」確認するためのものであり、メディア・ストリームの「RECV」接続。
Note that there is never a need for the answerer to request confirmation of the connectivity precondition when using ICE: the answerer can determine the status locally. Also note, that when ICE is used to verify connectivity preconditions, the precondition is not satisfied until connectivity has been verified for all the component transport addresses used by the media stream. For example, with an RTP-based media stream where RTCP is not suppressed, connectivity MUST be ascertained for both RTP and RTCP. Finally, it should be noted, that although connectivity has been ascertained, a new offer/ answer exchange may be required before media can flow (per ICE).
ICEを使用した場合の接続前提条件の確認を要求する回答の必要性が決してないことに注意してください：回答を局所的に状況を判断することができます。また、ICEを接続前提条件を確認するために使用されている場合、接続がメディアストリームで使用されるすべてのコンポーネントのトランスポートアドレスに対して検証されるまで、前提条件が満たされていないことに、注意してください。例えば、RTCPが抑制されていないRTPベースのメディアストリームと、接続はRTPとRTCPの両方のために確認しなければなりません。最後に、接続が確認されているが、メディアが（ICEごとに）流れることができる前に、新たなオファー/アンサー交換が必要なことに留意すべきです。
The above are merely examples of explicit connectivity verification mechanisms. Other techniques can be used as well. It is however RECOMMENDED that ICE be supported by entities that support connectivity preconditions. Use of ICE has the benefit of working for all media streams (not just RTP) as well as facilitating NAT and firewall traversal, which may otherwise interfere with connectivity. Furthermore, the ICE recommendation provides a baseline to ensure that all entities that require probe traffic to support the connectivity preconditions have a common way of ascertaining connectivity.
上記は、単に明示的な接続性検証メカニズムの例です。他の技術も同様に使用することができます。しかし、ICEが接続前提条件をサポートするエンティティによってサポートされることを推奨します。 ICEの使用は、すべてのメディアストリーム（だけでなく、RTP）のために働くだけでなく、それ以外の場合は、接続に干渉する可能性がある、NATやファイアウォール越えを容易にするという利点があります。さらに、ICEの勧告は、接続の前提条件をサポートするために、プローブトラフィックを必要とするすべてのエンティティが接続性を確認する一般的な方法を持っていることを確実にするためのベースラインを提供します。
Connection-oriented transport protocols generally provide an implicit connectivity verification mechanism. Connection establishment involves sending traffic in both directions thereby verifying connectivity at the transport-protocol level. When a three-way (or more) handshake for connection establishment succeeds, bi-directional communication is confirmed and both the "send" and "recv" preconditions are satisfied whether requested or not. In the case of TCP for example, once the TCP three-way handshake has completed (SYN, SYN-ACK, ACK), the TCP connection is established and data can be sent and received by either party (i.e., both a send and a receive connectivity precondition has been satisfied). SCTP (Stream Control Transmission Protocol) [RFC4960] connections have similar semantics as TCP and SHOULD be treated the same.
コネクション型トランスポートプロトコルは、一般的に、暗黙的な接続性検証メカニズムを提供します。接続の確立は、それによってトランスポートプロトコルレベルで接続性を検証する両方向のトラフィックを送信することを含みます。接続確立のための三元（またはそれ以上）のハンドシェイクが成功したとき、双方向通信が確認され、両方の「送信」および「RECV」前提条件は、要求されたか否かが満たされています。送信およびAの両方、すなわち（TCP 3ウェイハンドシェイクが（SYN、SYN-ACK、ACK）を完了すると例えばTCPの場合、TCP接続が確立され、データがいずれの当事者で送受信することができます受信接続の前提条件）が満たされています。 SCTP（ストリーム制御伝送プロトコル）[RFC4960]の接続がTCPと同様の意味を有し、同様に処理されるべきです。
When a connection-oriented transport is part of an offer, it may be passive, active, or active/passive [RFC4145]. When it is passive, the offerer expects the answerer to initiate the connection establishment, and when it is active, the offerer wants to initiate the connection establishment. When it is active/passive, the answerer decides. As noted earlier, lack of a media-stream-to-dialog correlation mechanism can make it difficult to guarantee with whom connectivity has been ascertained. When the offerer takes on the passive role, the offerer will not necessarily know which SIP dialog originated an incoming connection request. If the offerer instead is active, this problem is avoided.
接続指向の輸送がオファーの一部である場合、それは、パッシブ、アクティブ、またはアクティブ/パッシブ[RFC4145]であってもよいです。それは受動的である場合には、オファー側は、アンサー側は、接続の確立を開始する予定で、それがアクティブであるとき、オファー側は、接続の確立を開始することを望んでいます。それはパッシブ/アクティブの場合、回答が決定します。先に述べたように、メディア・ストリーム・ツー・ダイアログ相関メカニズムの欠如は、それが困難な接続性が確認されている誰と保証することができます。オファー側は受動的な役割を引き受けた場合、オファー側は必ずしも着信接続要求を発信したSIPダイアログを知ることができません。オファー側ではなく、アクティブな場合、この問題は回避されます。
The role of a connectivity precondition is to ascertain media stream connectivity before establishing or modifying a session. The underlying intent is for the two parties to be able to exchange media packets successfully. However, connectivity by itself may not fully satisfy this. Quality of Service, for example, may be required for the media stream; this can be addressed by use of the "qos" precondition defined in RFC 3312 [RFC3312]. Similarly, successful security parameter negotiation may be another prerequisite; this can be addressed by use of the "sec" precondition defined in RFC 5027 [RFC5027].
接続の前提条件の役割は、セッションを確立するか、変更する前に、メディアストリームの接続性を確認することです。 2人の当事者が成功したメディアパケットを交換できるようにするために根本的な意図があります。しかし、それだけで接続は完全にこれを満たさない場合があります。サービス品質は、例えば、メディアストリームのために必要な場合があります。これは、RFC 3312 [RFC3312]で定義された「QoSの」前提条件を使用することによって対処することができます。同様に、成功したセキュリティパラメータのネゴシエーションは別の前提条件であってもよく、これは、RFC 5027 [RFC5027]で定義された「秒」前提条件を使用することによって対処することができます。
The first example uses the connectivity precondition with TCP in the context of a session involving a wireless access medium. Both UAs use a radio access network that does not allow them to send any data (not even a TCP SYN) until a radio bearer has been set up for the connection. Figure 1 shows the message flow of this example (the required PRACK transaction has been omitted for clarity -- see [RFC3312] for details):
最初の例では、ワイヤレスアクセス媒体を含むセッションのコンテキストでTCPとの接続の前提条件を使用しています。どちらのUAは、無線ベアラは、接続用に設定されるまで、彼らがどのようなデータ（いなくてもTCP SYN）を送信することはできません無線アクセスネットワークを使用しています。図1は、（必要PRACKトランザクションは明確にするために省略された - 詳細については[RFC3312]を参照）は、この例のメッセージフローを示します。
A B
| INVITE |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:holdconn |
|----------------------------------->|
| |
| 183 Session Progress |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:holdconn |
|<-----------------------------------|
| |
| UPDATE |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
A's radio | a=setup:actpass |
bearer is +----------------------------------->|
up | |
| 200 OK |
| a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv |
| a=setup:active |
|<-----------------------------------|
| |
| |
| |
| | B's radio
|<---TCP Connection Establishment--->+ bearer is up
| | B sends TCP SYN
| |
| |
| 180 Ringing | TCP connection
|<-----------------------------------+ is up
| | B alerts the user
| |
Figure 1: Message Flow with Two Types of Preconditions
図1：前提条件の2種類のメッセージフロー
A sends an INVITE requesting connection-establishment preconditions. The setup attribute in the offer is set to holdconn [RFC4145] because A cannot send or receive any data before setting up a radio bearer for the connection.
Aは、接続確立の前提条件を要求するINVITEを送信します。 Aは、接続のための無線ベアラを設定する前にすべてのデータを送信または受信することはできませんのでごでセットアップ属性は[RFC4145]をholdconnするように設定されています。
B agrees to use the connectivity precondition by sending a 183 (Session Progress) response. The setup attribute in the answer is also set to holdconn because B, like A, cannot send or receive any data before setting up a radio bearer for the connection.
B 183（セッションプログレス）応答を送信することにより接続前提条件を使用することに同意します。 Bは、Aのように、接続用の無線ベアラを設定する前に、任意のデータを送信または受信できないので、答えでセットアップ属性もholdconnに設定されています。
When A's radio bearer is ready, A sends an UPDATE to B with a setup attribute with a value of actpass. This attribute indicates that A can perform an active or a passive TCP open. A is letting B choose which endpoint will initiate the connection.
Aの無線ベアラの準備が整うと、Aはactpassの値と設定属性でBへの更新を送信します。この属性は、AがアクティブまたはパッシブTCPのオープンを実行できることを示しています。 Aは、Bが接続を開始しますどのエンドポイントを選択させて頂いております。
Since B's radio bearer is not ready yet, B chooses to be the one initiating the connection and indicates this with a setup attribute with a value of active. At a later point, when B's radio bearer is ready, B initiates the TCP connection towards A.
Bの無線ベアラがまだ準備ができていないので、Bは1接続を開始することを選択し、アクティブの値と設定属性でこれを示します。 Bの無線ベアラが準備ができたときに、後の時点で、Bは、Aに向けたTCP接続を開始します
Once the TCP connection is established successfully, B knows the "sendrecv" precondition is satisfied, and B proceeds with the session (i.e., alerts the Callee), and sends a 180 (Ringing) response.
TCP接続が正常に確立されると、Bは知っている「のsendrecv」前提条件が満たされ、Bは、セッションで進行（すなわち、呼び出し先がアラート）、および180（リンギング）応答を送信します。
The second example shows a basic SIP session establishment using SDP connectivity preconditions and ICE (the required PRACK transaction and some SDP details have been omitted for clarity). The offerer (A) is a full ICE implementation whereas the answerer (B) is a lite ICE implementation. The message flow for this scenario is shown in Figure 2 below.
第二の例は、（明瞭にするために省略されている必要PRACKトランザクションおよびいくつかSDPの詳細）SDP接続前提条件とICEを使用して基本的なSIPセッション確立を示します。提供者（A）が回答（B）に対し、完全なICEの実装であるライトICEの実装です。このシナリオのメッセージフローは、以下の図2に示されています。
A B
B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| |
|~~~~~ Connectivity check to B ~~~~~~~~~~~~~>|
|<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~|
| |
|-------------(3) UPDATE SDP3--------------->|
| |
|<--------(4) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(5) 180 Ringing---------------|
| |
| |
Figure 2: Connectivity Precondition with ICE Connectivity Checks
図2：ICEの接続性チェックとの接続前提条件
SDP1: A includes a mandatory end-to-end connectivity precondition with a desired status of "sendrecv"; this will ensure media stream connectivity in both directions before continuing with the session setup. Since media stream connectivity in either direction is unknown at this point, the current status is set to "none". A's local status table (see [RFC3312]) for the connectivity precondition is as follows:
SDP1：Aは「のsendrecv」の所望の状況に必須のエンドツーエンド接続の前提条件を含みます。これは、セッションのセットアップを続行する前に、両方向のメディアストリームの接続性を保証します。いずれかの方向にメディアストリーム接続は、この時点では不明であるので、現在の状態が「なし」に設定されています。次のように接続前提条件のためのAのローカルステータステーブル（[RFC3312]を参照します）。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
and the resulting offer SDP is:
そして得られたオファーSDPは以下のとおりです。
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=rtcp:20001 a=curr:conn e2e none a=des:conn mandatory e2e sendrecv a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
=氷PWD：asd88fgpdd777uzjYhagZg A =氷ufrag：8hhY M =オーディオ20000 RTP / AVP 0 C = IN IP4 192.0.2.1 A = RTCP：20001 A = CURR：CONN E2EなしA = DES：CONN必須E2E SENDRECV A =候補：1 1 UDP 2130706431 192.0.2.1 20000標準ホスト
SDP2: When B receives the offer, B sees the mandatory sendrecv connectivity precondition. B is a lite ICE implementation and hence B can only ascertain "recv" connectivity (from B's point of view) from A; thus, B wants A to inform it about connectivity in the other direction ("send" from B's point of view). B's local status table therefore looks as follows:
SDP2：Bを提示申し出を受信した場合、Bは必須のsendrecv接続の前提条件を見ています。 BはライトICEの実装であり、したがって、Bのみから（図のBの視点から）「RECV」接続性を確認することができます。したがって、Bは、他の方向（ビューのBの時点から「送信」）での接続性について通知したいと考えています。次のようにBのローカルステータステーブルは、それゆえになります。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | no | mandatory | no
Since B is a lite ICE implementation and B wants to ask A for confirmation about the "send" (from B's point of view) connectivity precondition, the resulting answer SDP becomes:
BはliteのICEの実装であり、Bは、（ビューのBの視点から）「送信」接続の前提条件についての確認をお願いしたいと考え、結果の回答SDPになりますので：
a=ice-lite a=ice-pwd:qrCA8800133321zF9AIj98 a=ice-ufrag:H92p m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=rtcp:30001 a=curr:conn e2e none a=des:conn mandatory e2e sendrecv a=conf:conn e2e send a=candidate:1 1 UDP 2130706431 192.0.2.4 30000 typ host
=氷ライトA =氷PWD：qrCA8800133321zF9AIj98 A =氷ufrag：H92p M =オーディオ30000 RTP / AVP 0 C = IN IP4 192.0.2.4 A = RTCP：30001 A = CURR：CONN E2EなしA = DES： CONN必須E2Eのsendrecv A = CONF：1 1 UDP 2130706431 192.0.2.4 30000標準ホスト：CONN E2E =候補を送信
Since the "send" and the "recv" connectivity precondition (from B's point of view) are still not satisfied, session establishment remains suspended.
「送信」と（図のBの視点から）「RECV」接続前提条件がまだ満たされていないため、セッション確立が中断されたままです。
SDP3: When A receives the answer SDP, A notes that B is a lite ICE implementation and that confirmation was requested for B's "send" connectivity precondition, which is the "recv" precondition from A's point of view. A performs a successful send and recv connectivity check to B by sending an ICE connectivity check to B and receiving the corresponding response. A's local status table becomes:
SDP3：Aが回答SDPを受信した場合、AはBがライトICEの実装があることを指摘し、その確認がビューのAの時点から「RECV」の前提条件であるBの「送信」接続の前提条件、のために要求されました。 AはBにICE接続性チェックを送信し、対応する応答を受信することによってBに成功した送信及びRECV接続性チェックを行います。 Aのローカルステータステーブルは次のようになります。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | yes
whereas B's local status table becomes:
Bのローカルステータステーブルになるのに対し：
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | no | mandatory | no
recv | yes | mandatory | no
Since B asked for confirmation about the "recv" connectivity (from A's point of view), A now sends an UPDATE (5) to B to confirm the connectivity from A to B:
Bは、（ビューのAの観点から）「RECV」接続性に関する確認を求めているので、今UPDATEは（5）AからBへの接続性を確認するためにBに送信します。
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=rtcp:20001 a=curr:conn e2e sendrecv a=des:conn mandatory e2e sendrecv a=candidate:1 1 UDP 2130706431 192.0.2.1 20000 typ host
=氷PWD：asd88fgpdd777uzjYhagZg A =氷ufrag：8hhY M =オーディオ20000 RTP / AVP 0 C = IN IP4 192.0.2.1 A = RTCP：20001 A = CURR：CONN E2E SENDRECV A = DES：CONN必須E2E SENDRECV A =候補：1 1 UDP 2130706431 192.0.2.1 20000標準ホスト
B knows it has recv connectivity (verified by ICE as well as A's UPDATE) and send connectivity (confirmed by A's UPDATE) at this point. B's local status table becomes:
Bは、それが（ICEだけでなく、AさんUPDATEによって検証）のrecv接続性を持っており、この時点では（AさんUPDATEによって確認）接続を送信知っています。 Bのローカルステータステーブルは次のようになります。
Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+----------
send | yes | mandatory | no
recv | yes | mandatory | no
and the session can continue.
セッションが継続することができます。
General security considerations for preconditions are discussed in RFC 3312 [RFC3312] and RFC 4032 [RFC4032]. As discussed in RFC 4032 [RFC4032], it is strongly RECOMMENDED that S/MIME [RFC3853] integrity protection be applied to the SDP session descriptions. When the user agent provides identity services (rather than the proxy server), the SIP identity mechanism specified in RFC 4474 [RFC4474] provides an alternative end-to-end integrity protection. Additionally, the following security issues relate specifically to connectivity preconditions.
前提条件のための一般的なセキュリティ上の考慮事項は、RFC 3312 [RFC3312]およびRFC 4032 [RFC4032]で議論されています。 RFC 4032 [RFC4032]で説明したように、強く、S / MIME [RFC3853]完全性保護がSDPセッション記述に適用されることが推奨されます。ユーザエージェントは、（むしろプロキシ・サーバよりも）同一のサービスを提供する場合、RFC 4474で指定されたSIPアイデンティティ機構[RFC4474]は、代替エンドツーエンドの完全性保護を提供します。また、次のようなセキュリティ上の問題は、接続の前提条件に特異的に関連しています。
Connectivity preconditions rely on mechanisms beyond SDP, such as TCP [RFC0793] connection establishment or ICE connectivity checks [RFC5245], to establish and verify connectivity between an offerer and an answerer. An attacker that prevents those mechanisms from succeeding (e.g., by keeping ICE connectivity checks from arriving at their destination) can prevent media sessions from being established. While this attack relates to connectivity preconditions, it is actually an attack against the connection-establishment mechanisms used by the endpoints. This attack can be performed in the presence or in the absence of connectivity preconditions. In their presence, the whole session setup will be disrupted. In their absence, only the establishment of the particular stream under attack will be disrupted. This specification does not provide any mechanism against attackers able to block traffic between the endpoints involved in the session because such an attacker will always be able to launch DoS (Denial-of-Service) attacks.
接続の前提条件は、提供者と回答との間の接続を確立し、検証するTCPなどのSDPを超え機構、[RFC0793]の接続確立又はICE接続性チェック[RFC5245]に依存しています。 （目的地に到着からICE接続性チェックを維持することによって、例えば）後続からそれらのメカニズムを妨げる攻撃者が確立されるのメディアセッションを防止することができます。この攻撃は、接続の前提条件に関するが、それが実際にエンドポイントによって使用される接続確立メカニズムに対する攻撃です。この攻撃は、存在下でまたは接続前提条件の不存在下で行うことができます。彼らの存在下では、セッション全体のセットアップは中断されます。彼らの不在では、攻撃を受けて特定のストリームの唯一の確立が中断されます。そのような攻撃者は常にDoS攻撃（サービス拒否）攻撃を仕掛けることができるようになりますので、この仕様では、セッションに含まれるエンドポイント間のトラフィックをブロックすることが攻撃者に対して何らかのメカニズムを提供しません。
Instead of blocking the connectivity checks, the attacker can generate forged connectivity checks that would cause the endpoints to assume that there was connectivity when there was actually no connectivity. This attack would result in the user experience being poor because the session would be established without all the media streams being ready. The same attack can be used, regardless of whether or not connectivity preconditions are used, to attempt to hijack a connection. The forged connectivity checks would trick the endpoints into sending media to the wrong direction. To prevent these attacks, it is RECOMMENDED that the mechanisms used to check connectivity are adequately secured by message authentication and integrity protection. For example, Section 2.5 of [RFC5245] discusses how message integrity and data origin authentication are implemented in ICE connectivity checks.
代わりに、接続性チェックを遮断するのは、攻撃者がエンドポイントは実際には、接続がなかったときの接続があったと考えるのが原因となるフォージド接続性チェックを生成することができます。セッションは、すべてのメディアストリームが準備されずに確立されるため、この攻撃は、ユーザーエクスペリエンスが悪いということになります。同じ攻撃は、接続をハイジャックしようとするために、関係なく、接続前提条件が使用されているかどうかを、使用することができます。鍛造接続性チェックが間違った方向にメディアを送るにエンドポイントをだますでしょう。これらの攻撃を防ぐためには、接続を確認するために使用されるメカニズムが十分にメッセージ認証と完全性保護で保護することをお勧めします。例えば、[RFC5245]のセクション2.5は、メッセージの整合性とデータ発信元認証は、ICE接続性チェックで実装される方法について説明します。
IANA has registered a new precondition type under the Precondition Types used with SIP subregistry, which is located under the Session Initiation Protocol (SIP) Parameters registry.
IANAは、セッション開始プロトコル（SIP）パラメータレジストリの下に配置されたSIPの副登録、で使用される前提条件の種類]で[新しい前提条件タイプが登録されています。
Precondition-Type Description Reference
----------------- ----------------------------------- ---------
conn Connectivity precondition [RFC5898]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[RFC3853]ピーターソン、J.、 "S / MIMEのAdvanced Encryption Standard（AES）セッション開始プロトコル（SIP）のための要件"、RFC 3853、2004年7月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]キャマリロ、G.とP. Kyzivat、 "セッション開始プロトコル（SIP）前提条件フレームワークへの更新"、RFC 4032、2005年3月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.
[RFC5027]アンドレア、F.とD.ウィング、 "セキュリティの前提条件セッションの記述プロトコル（SDP）メディアストリーム"、RFC 5027、2007年10月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]ヨン、D.とG.カマリロ、 "TCPベースのセッション記述プロトコル（SDP）にメディアトランスポート"、RFC 4145、2005年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109]李、A.、 "一般的なフォワードエラー訂正のためのRTPペイロードフォーマット"、RFC 5109、2007年12月。
[ICE-TCP] Perreault, S., Ed. and J. Rosenberg, "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, October 2009.
[ICE-TCP]ペロー、S.、エド。およびJ.ローゼンバーグ、「インタラクティブ接続確立（ICE）とTCPの候補者は」、進歩、2009年10月に作業します。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, NJ 08837 USA
フレミングAndreasenのシスコシステムズ社499 Thornallストリート、8階エジソン、NJ 08837 USA
EMail: fandreas@cisco.com
メールアドレス：fandreas@cisco.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
David Oran Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA 01720 USA
デビッド・オランシスコシステムズ、株式会社7 Ladyslipperレーンアクトン、MA 01720 USA
EMail: oran@cisco.com
メールアドレス：oran@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
ダン・ウィングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: dwing@cisco.com
メールアドレス：dwing@cisco.com