[要約] RFC 5898は、SDPメディアストリームの接続前提条件に関する規格であり、SDPセッションの正常な動作を保証するための接続要件を定義しています。このRFCの目的は、SDPメディアストリームの接続性を確保し、セッションの品質を向上させることです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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）[RFC4566]セッション開始プロトコル（SIP）[RFC3261]の前提条件は、RFC 3312 [RFC3312]で定義されています（RFC 4032 [RFC4032]）。前提条件とは、セッションの確立または修正が進むために、特定のメディアストリームに対して満たされなければならない条件です。前提条件が満たされない場合、前提条件が満たされるか、セッションの確立が失敗するまでセッションの進行が遅れます。たとえば、RFC 3312 [RFC3312]は、セッションを確立する前にネットワークリソースの可用性を確保するために使用されるサービス品質の前提条件を定義します（つまり、Calleeを警告し始める前）。
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.
このドキュメントで定義されている接続前の前提条件タイプは、RFC 4032 [RFC4032]で提供されるガイドラインに従って、SIP Preconditionsフレームワークを拡張します。
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
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]によると、新しい前処理タイプを定義するドキュメントでは、これらの前提条件が満たされたときに再開されるまで、一連の前提条件のためにUAS（ユーザーエージェント）の動作を説明する必要があります。メディアストリーム接続が確立されるまでセッションの確立または変更を遅らせたいエンティティは、この前提条件タイプをオファーに使用します。義務的な接続の前提条件がオファーで受け取られた場合、セッションの確立または変更は、接続の前提条件が満たされるまで遅れます（つまり、メディアストリームの接続が望ましい方向または方向に確立されるまで）。ここで定義されているセッション施設の遅延は、前提条件が満たされるまで、呼び出された当事者の警告が起こらないことを意味します。
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]は、FEC（フォワードエラー補正）情報を別のストリームとして送信する方法を指定します（FECストリームのアドレスは「A = FMTP」行で提供されます）。メディアストリームが複数の宛先アドレスで構成されている場合、前提条件を満たすためには、それらすべてへの接続を検証する必要があります。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]は、2種類のステータスタイプのサポートを定義します。つまり、セグメント化されたエンドツーエンドです。ここで定義されている接続の前処理タイプは、エンドツーエンドステータスタイプで使用する必要があります。セグメント化されたステータスタイプの使用は未定義です。
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 送信：セッションの説明を生成したパーティーは、メディアストリームのパケットを相手に送信しており、他の当事者は少なくとも1つのパケットを受け取りました。つまり、フォワード（送信）方向に接続性があります。
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：相手は、セッションの説明を生成したパーティーにメディアストリーム上のパケットを送信しており、このパーティーは少なくとも1つのパケットを受け取りました。つまり、後方（受信）方向に接続性があります。
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の「必要」ヘッダーがオプションタグ「Precondition」を使用して存在する必要があることに注意してください。必須の前提条件をサポートしていない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:
REINVITEまたは更新の接続性の前提条件を備えたオファーは、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.
o 明示的な接続検証メカニズム（ICEなど）が交渉された場合、メカニズムが接続性を正常に検証すると、前提条件が満たされます。
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.
Interactive Connectivity Indecivity Indecivity（ICE）[RFC5245]は、オファーと応募者との間のシグナリングに1つ以上の候補アドレスを提供し、Stun（NATを介したUDPプロトコルの単純なトラバーサル）バインディングリクエストを使用して、候補アドレスのどのペアが接続されているかを決定します。各スタンバインディングリクエストには、SDPでも通信されるパスワードが含まれています。これにより、特定のメディアストリームのスタンバインディングリクエストと候補アドレスとの相関が可能になります。また、特定の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実装はそれらにのみ応答します。氷の場合、片側は制御剤であり、もう一方は制御されたエージェントです。完全な実装はいずれかの役割を引き受けることができますが、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 完全な実装では、スタンクライアントとして動作し、スタンバインディングリクエストを送信したときに「送信」と「RECV」接続の両方を確認し、メディアストリームのすべてのコンポーネントのチェックが成功しました（ICEでさらに定義されています）。
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).
o フルまたはライトの実装では、スタンサーバーとして動作し、メディアストリームのすべてのコンポーネント（ICEでさらに定義されているように）の応答が成功するスタンバインディングリクエストを受信した場合、「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の両方で接続を確認する必要があります。最後に、接続性が確認されているが、メディアが流れる前に新しいオファー/回答の交換が必要になる場合があることに注意する必要があります。
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.
接続指向の輸送プロトコルは、一般に、暗黙的な接続検証メカニズムを提供します。接続確立には、トラフィックを両方向に送信すると、輸送プロトコルレベルでの接続性が検証されます。接続確立のための3方向（またはそれ以上）の握手が成功すると、双方向通信が確認され、「送信」と「RECV」の両方の前提条件が要求されているかどうかにかかわらず満たされます。たとえば、TCPの場合、TCPの3方向握手が完了すると（Syn、Syn-ack、ACK）、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]で定義されている「SEC」の前提条件を使用することで対処できます。
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との接続前の前提条件を使用します。両方のUASは、ラジオベアラーが接続のためにセットアップされるまで（TCP Synでもない）データを送信できないラジオアクセスネットワークを使用します。図1は、この例のメッセージフローを示しています（必要なプラックトランザクションは明確に省略されています - 詳細については[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は、接続確立の前提条件を要求する招待状を送信します。オファーのセットアップ属性は、接続用のラジオベアラーをセットアップする前にデータを送信または受信できないため、HoldConn [RFC4145]に設定されています。
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（セッションの進行状況）応答を送信することにより、接続の前提条件を使用することに同意します。Aのように、Bが接続用のラジオベアラーを設定する前にデータを送信または受信できないため、回答のセットアップ属性も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は接続を開始するものになることを選択し、アクティブの値を持つセットアップ属性でこれを示します。後の時点で、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はセッションで進行し（つまり、Calleeにアラート）、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.
2番目の例は、SDP接続の前提条件とICEを使用した基本的なSIPセッションの確立を示しています（必要なプラックトランザクションといくつかのSDPの詳細は明確に省略されています）。Offerer（a）は完全な氷の実装であり、Answerer（b）はLite 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：氷の接続性チェックによる接続の前提条件
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
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はライトアイスの実装であるため、bは（bの観点から）の「recv」接続性のみを確認できます。したがって、Bは、Aが他の方向の接続性について通知したい（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
Since the "send" and the "recv" connectivity precondition (from B's point of view) are still not satisfied, session establishment remains suspended.
「送信」と「RECV」接続の前提条件（Bの観点から）はまだ満足していないため、セッションの確立は停止されたままです。
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を受信すると、BはLite Iceの実装であり、Bの「送信」接続前の前提条件の確認が要求されたことに注意してください。Aは、氷の接続性チェックをBに送信し、対応する応答を受信することにより、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」接続性についての確認を求めたため、AはAからBへの接続を確認するために更新（5）を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
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は、この時点でRECV接続（ICEおよびAのアップデートで検証されている）があることを知っており、接続（Aの更新で確認された）を送信します。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セッションの説明に適用することを強くお勧めします。ユーザーエージェントが（プロキシサーバーではなく）IDサービスを提供する場合、RFC 4474 [RFC4474]で指定されたSIP IDメカニズムは、代替エンドツーエンドの完全性保護を提供します。さらに、次のセキュリティの問題は、特に接続の前提条件に関連しています。
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 [RFC0793]接続確立または氷の接続性チェック[RFC5245]など、SDPを超えたメカニズムに依存して、提供者と応答者間の接続を確立および検証します。これらのメカニズムが成功するのを防ぐ攻撃者（たとえば、氷の接続性チェックが目的地に到着しないようにすることにより）は、メディアセッションの確立を防ぐことができます。この攻撃は接続の前提条件に関連していますが、実際にはエンドポイントで使用される接続確立メカニズムに対する攻撃です。この攻撃は、接続性の前提条件がない場合、または存在下で実行できます。彼らの存在下では、セッション全体のセットアップが破壊されます。彼らの不在では、攻撃下の特定のストリームの確立のみが破壊されます。この仕様は、このような攻撃者が常に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では、メッセージの整合性とデータオリジン認証が氷の接続チェックでどのように実装されるかについて説明します。
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 Subregistryで使用されるPrecondition Typeの下で新しい前処理タイプを登録しました。これは、セッション開始プロトコル（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[RFC3853] Peterson、J。、「S/MIME Advanced暗号化標準（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] Camarillo、G。およびP. Kyzivat、「セッション開始プロトコル（SIP）Preconditions Frameworkの更新」、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Andreasen、F。およびD. Wing、「セッション説明プロトコル（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] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、RFC 5245、2010年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、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.、Frederick、R。、およびV. Jacobson、「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] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、RFC 4145、2005年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109] Li、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] Perreault、S.、ed。J. Rosenberg、「Interactive Connectivity Indecivity（ICE）を持つTCP候補」、2009年10月、進行中の作業。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, NJ 08837 USA
Flemming Andreasen Cisco Systems、Inc。499 Thornall Street、8th Floor Edison、NJ 08837 USA
EMail: fandreas@cisco.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
David Oran Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA 01720 USA
David Oran Cisco Systems、Inc。7 Ladyslipper Lane Acton、MA 01720 USA
EMail: oran@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USA
EMail: dwing@cisco.com