Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6135 Ericsson
Category: Standards Track S. Blau
ISSN: 2070-1721 Ericsson AB
February 2011
An Alternative Connection Model for the
Message Session Relay Protocol (MSRP)
Abstract
抽象
This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT.
この文書では、メッセージセッションリレープロトコル（MSRP）ユーザエージェント（UAS）のための代替の接続モデルを定義します。このモデルは、MSRPトランスポート接続を作成するために接続指向のメディア（COMEDIA）メカニズムを使用します。このモデルは、ネットワークの背後にあるMSRP UAがNATを通過するMSRPメッセージのために、伝送制御プロトコル（TCP）接続の確立を開始するエンドポイント交渉する翻訳者（NATを）に対処できます。
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/rfc6135.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6135で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Applicability Statement .........................................3
4. COMEDIA for MSRP ................................................3
4.1. General ....................................................3
4.2. a=setup ....................................................3
4.2.1. General .............................................3
4.2.2. Attribute Usage .....................................4
4.3. TLS ........................................................5
4.4. a=connection ...............................................5
4.5. MSRP Relay Connection ......................................6
5. Interoperability with the Connection Model Defined in RFC 4975 ..6
6. Security Considerations .........................................6
7. Acknowledgements ................................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................7
The Message Session Relay Protocol (MSRP) core specification [RFC4975] states that the MSRP User Agent (UA) that sends the Session Description Protocol (SDP) offer is "active", and it is responsible for creating the MSRP transport connection towards the remote UA if a new connection is required. The core specification also allows, but does not define, alternate mechanisms for MSRP UAs to create MSRP transport connections.
メッセージセッションリレープロトコル（MSRP）コア仕様[RFC4975]はセッション記述プロトコル（SDP）のオファーを送りMSRPユーザエージェント（UA）は「アクティブ」であり、それは、リモートへのMSRPのトランスポート接続を作成するための責任があると述べていますUA新しい接続が要求される場合。コア仕様もできますが、MSRPトランスポート接続を作成するために、MSRPのUAのための代替メカニズムを定義していません。
[RFC4145] defines a connection-oriented media (COMEDIA) mechanism, which endpoints can use to negotiate the endpoint that initiates the creation of media transport connection.
[RFC4145]は、エンドポイントは、メディアトランスポート接続の作成を開始し、エンドポイントを交渉するために使用できる接続指向のメディア（COMEDIA）メカニズムを定義します。
COMEDIA is especially useful when one of the endpoints is located behind a Network Address Translator (NAT). The endpoint can use the mechanism to indicate that it will create the media transport connection, in order for the media to traverse the NAT without the usage of relays and without being required to support more complex mechanisms (e.g., "TCP Candidates with Interactive Connectivity Establishment (ICE)" [ICE-TCP]). In addition, COMEDIA allows the usage of identical procedures in establishing Transmission Control Protocol (TCP) [RFC0793] connections for different types of media.
エンドポイントの1つは、ネットワークアドレス変換（NAT）の背後に配置されたときにCOMEDIAは特に便利です。エンドポイントは、メディアは、リレーの使用せずにNATを通過するために、そしてインタラクティブ接続の確立と、より複雑なメカニズム（例えば、」TCP候補をサポートするために必要されることなく、それがメディアトランスポート接続を作成することを示すためのメカニズムを使用することができます（ICE）」[ICE-TCP]）。また、COMEDIAは、伝送制御プロトコル（TCP）メディアの種類ごとに[RFC0793]の接続を確立する際に同じ手順の使用を可能にします。
An example is the Open Mobile Alliance (OMA)-defined "Instant Message using SIMPLE" [OMA-SIMPLE], where one MSRP UA of every MSRP transport connection represents a media server, which is always located in the carrier network. The media server has a globally reachable IP address and handles application-specific policy control as well as NAT traversal. The OMA IM (Instant Messenger) uses COMEDIA for NAT traversal, and all OMA IM MSRP clients support COMEDIA.
例では、オープン・モバイル・アライアンス（OMA）は、「SIMPLE使用してインスタントメッセージを」-definedある[OMA-SIMPLE]、すべてのMSRPトランスポート接続のMSRP UAは常にキャリアネットワークに位置するメディアサーバを表します。メディアサーバーは、グローバルに到達可能なIPアドレスを持ち、アプリケーション固有のポリシー制御だけでなく、NATトラバーサルを処理します。 OMA IM（インスタントメッセンジャー）は、NATトラバーサルのためCOMEDIAを使用し、すべてのOMA IM MSRPクライアントはCOMEDIAをサポートしています。
This document defines how an MSRP UA uses COMEDIA in order to negotiate which UA will create the MSRP transport TCP connection towards the other UA. The document also defines how an MSRP UA that uses COMEDIA can establish an MSRP transport connection with a remote UA that does not support COMEDIA.
この文書では、MSRP UAは、UAは、他のUAへのMSRP輸送TCP接続を作成しますどの交渉するためにCOMEDIAをどのように使用するかを定義します。文書はまた、COMEDIAがCOMEDIAをサポートしていないリモートUAとのMSRPのトランスポート接続を確立することができます使用していることをどのようにMSRP UAを定義します。
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]に記載されているように解釈されます。
Support of this specification is OPTIONAL for MSRP UAs in general. UAs that are likely to be deployed in networks with NATs SHOULD support this specification. It will improve the odds of being able to make TCP connections successfully traverse NATs, since UAs behind NATs can be requested to initiate the establishment of the TCP connections.
この仕様のサポートは、一般的にはMSRPのUAのためのオプションです。 NATを持つネットワークで展開される可能性があるUAは、この仕様をサポートする必要があります。 NATの背後にあるUAはTCPコネクションの確立を開始するように要求することができますので、それは、TCP接続に成功トラバースNATのを作ることができるというのオッズを向上させます。
This section defines how an MSRP UA that supports this specification uses the COMEDIA SDP attributes defined in [RFC4145].
このセクションでは、この仕様は[RFC4145]で定義さCOMEDIA SDP属性を使用してサポートする方法MSRP UAを画定します。
An MSRP UA uses the SDP a=setup attribute [RFC4145] in order to negotiate which endpoint will create the MSRP transport connection towards the other UA.
MSRP UAは他のUAへのMSRPのトランスポート接続を作成しますどのエンドポイント交渉するために、SDPのA =セットアップ属性[RFC4145]を使用しています。
An MSRP UA MUST always include an explicit a=setup attribute in its SDP offers and answers, since it might be useful for the other endpoint, or for entities in the network, to know whether the UA supports COMEDIA or not.
それはUAがCOMEDIAをサポートするかどうかを知るために、他のエンドポイントについて、またはネットワーク内のエンティティのために有用であるかもしれないので、MSRP UAは常に、そのSDPオファーとアンサーに明示的にA =セットアップ属性を含まなければなりません。
An MSRP UA MUST support the a=setup "active", "actpass", and "passive" attribute values. An MSRP UA MUST NOT send the "holdconn" attribute value. If an MSRP UA receives the "holdconn" attribute value, it MUST ignore it and process the message as if it did not contain an a=setup attribute.
MSRP UAは、A =セットアップ「アクティブ」、「actpass」、および「受動的」属性値をサポートしなければなりません。 MSRP UAは「holdconn」属性値を送ってはいけません。 MSRP UAが「holdconn」属性の値を受信した場合、それはそれを無視し、それは、A =セットアップ属性が含まれていなかったかのようにメッセージを処理しなければなりません。
When the a=setup attribute value is "actpass" or "passive", the IP address and port values in the MSRP URI of the SDP a=path attribute MUST contain the actual address and port values on which the UA can receive a TCP connection for the MSRP transport connection.
A =設定属性値が「actpass」又は「受動的」である場合、SDPのMSRP URIにIPアドレスとポートの値は、= path属性は、UAは、TCP接続を受け入れることが可能な実際のアドレスとポートの値を含まなければなりませんMSRPのトランスポート接続のために。
In accordance with [RFC4145], if the a=setup attribute value is "active", the port number value should be 9.
A =設定属性値が「アクティブ」である場合、[RFC4145]に従って、ポート番号の値が9であるべきです。
If an MSRP UA can provide a globally reachable IP address that the other endpoint can use as a destination for a TCP connection, the UA MUST use the a=setup "actpass" attribute value in SDP offers. This is in order to allow the remote UA to send an SDP answer with an a=setup "active" attribute value if the UA is located behind a NAT, and in order to be compatible with UAs that do not support COMEDIA and thus always will act as passive endpoints. If an MSRP UA cannot provide the actual transport address, the UA MUST use the a=setup "active" attribute value.
MSRP UAは、他のエンドポイントはTCP接続の宛先として使用できることを世界的に到達可能なIPアドレスを提供することができた場合、UAは、SDP申し出における属性値「actpass」A =セットアップを使用しなければなりません。これは、UAがNATの背後に配置されている場合は、リモートUAは、A =セットアップ「アクティブ」属性値とSDP応答を送信することを可能にするためであり、そして順番にCOMEDIAをサポートしていないのUAと互換性があるので、常に意志しますパッシブエンドポイントとして機能します。 MSRP UAは、実際の転送アドレスを提供することができない場合、UAは、A =セットアップ「アクティブ」属性値を使用しなければなりません。
The UA MUST NOT use the a=setup "passive" attribute value in an SDP offer.
UAは、SDPのオファーで、A =セットアップ「受動的」属性値を使用してはなりません。
The MSRP UA can determine that it provides a globally reachable IP address in the following scenarios:
MSRP UAは、それが次のシナリオでは、グローバル到達可能なIPアドレスを提供することを決定することができます：
o the UA can determine that it is not located behind a NAT;
O UAは、それがNATの背後に配置されていないことを判断することができます。
o the UA relays its MSRP transport connections via a relay (e.g., an MSRP relay or Traversal Using Relay NAT (TURN) server); or
UAは、リレーを介してそのMSRP転送接続を中継O（例えば、リレーNAT（TURN）サーバを使用してMSRPリレーまたはトラバーサル）。または
o the UA has used Session Traversal Utilities for NAT (STUN) [RFC5389] signaling to retrieve the NAT address and port through the local port to be used for the eventual transport connection, while also having determined that the NAT has endpoint-independent mapping and filtering behavior [RFC5382], e.g., using the mechanism defined in [RFC5780].
また、NATがエンドポイント非依存マッピングを持っていると判断したしながらUAは、最終的なトランスポート接続に使用するローカル・ポートを介してNATアドレスとポートを取得するためのシグナリングNATのためのセッショントラバーサルユーティリティ（STUN）[RFC5389]を使用しているOおよび[RFC5780]で定義されたメカニズムを使用してフィルタリング挙動[RFC5382]、例えば、。
Some UAs can determine whether the SIP [RFC3261] signaling has traversed a NAT by inspecting the SIP Via header field in the 200 (OK) response to the initial SIP REGISTER request, and comparing the IP addresses in the Via sent-by and the received header field parameters. If the IP addresses are not the same, then the UA can determine that there is a NAT in the path. Even though the media transport might not traverse the NAT, it is safe to assume that it will. This comparing mechanism does not work in all scenarios, though. For example, if SIP a request crosses a SIP proxy before crossing a NAT, the UA will not be able to detect the NAT by comparing the IP addresses.
いくつかのUAは、最初のSIP REGISTERリクエストに対する200（OK）応答でSIP Viaヘッダーフィールドを検査し、バイ送受信を介してIPアドレスを比較することによって、SIP [RFC3261]シグナリングはNAT横断したか否かを判断することができますヘッダフィールドパラメータ。 IPアドレスが同じでない場合は、UAは、パスでNATがあることを判断することができます。メディアトランスポートがNATを通過しない場合がありますにもかかわらず、すると仮定しても安全です。この比較メカニズムは、しかし、すべてのシナリオでは動作しません。 SIPリクエストはNATを横断する前に、SIPプロキシを横切った場合、UAは、IPアドレスを比較することにより、NATを検出することができません。
If an SDP offer includes an a=setup "actpass" attribute value, the SDP answerer MAY include an a=setup "active" attribute value in the SDP answer, but SHOULD include an a=setup "passive" attribute value if it knows that it is not located behind a NAT.
SDPオファーは、属性値「actpass」A =セットアップが含まれている場合は、SDPの回答は、SDP応答で、A =セットアップ「アクティブ」属性の値を含んでいてもよいが、それがいることを知っていれば、A =セットアップ「受動的」属性値を含むべきですそれは、NATの背後に配置されていません。
Once the active UA has established the MSRP transport connection, the UA must immediately send an MSRP SEND request, as defined in [RFC4975].
アクティブUAはMSRPトランスポート接続を確立した後は[RFC4975]で定義されるように、UAは、直ちに、MSRP SEND要求を送信しなければなりません。
NOTE: According to [RFC4975], the initiating UA is always active, but when COMEDIA is used, the a=setup attribute is used to negotiate which UA becomes active.
注：[RFC4975]によると、開始UAは常にアクティブですが、COMEDIAを使用した場合、A =セットアップ属性は、UAがアクティブになる交渉するために使用されます。
If an MSRP UA conformant to this document uses Transport Layer Security (TLS), it MUST use the TLS mechanisms defined in [RFC4975] and [RFC4976].
このドキュメントへのMSRP UAの準拠は、トランスポート層セキュリティ（TLS）を使用している場合、それは、TLS [RFC4975]で定義されたメカニズムと[RFC4976]を使用しなければなりません。
According to [RFC4975], the connection can be established with or without TLS mutual authentication. In case mutual authentication is not used, the listening device waits until it receives a request on the connection, at which time it infers the identity of the connecting device from the associated session description. From the TLS authentication point of view, it is thus irrelevant whether an endpoint takes the active or passive role.
[RFC4975]によれば、接続またはTLSの相互認証なしで確立することができます。相互認証を使用しない場合には、それが関連付けられたセッション記述から、接続デバイスのアイデンティティを推測その時点で接続上で要求を受信するまで、リスニングデバイスは待機します。ビューのTLS認証ポイントから、エンドポイントは、能動的または受動的な役割を取るかどうか、したがって無関係です。
If an MSRP UA uses a self-signed TLS certificate to authenticate itself to MSRP peers, it also includes its certificate fingerprint in the SDP.
MSRP UAはピアをMSRPに自身を認証するために自己署名TLS証明書を使用している場合、それはまた、SDP内の証明書のフィンガープリントを含みます。
Note that fingerprints can only be exchanged in peer-to-peer communication, as MSRP relays [RFC4976] will not receive the SDP payloads containing the fingerprint attributes.
指紋のみ指紋属性を含むSDPペイロードを受信しないMSRPリレー[RFC4976]として、ピア・ツー・ピア通信で交換することができることに留意されたいです。
MSRP UAs MUST NOT use the SDP a=connection attribute. [RFC4975] defines connection reuse procedures for MSRP, and this document does not modify those procedures.
MSRP UAはSDPのA =接続属性を使用してはなりません。 [RFC4975]はMSRPのための接続再利用手順を定義しており、この文書は、これらの手順を変更しません。
If an MSRP UA receives an a=connection attribute, the UA MUST ignore it.
MSRP UAは、A =接続属性を受信した場合、UAはそれを無視しなければなりません。
If an MSRP UA is located behind an MSRP relay [RFC4976], the UA MUST always initiate a transport connection towards the relay, no matter what value the client has provided in the a=setup attribute.
MSRP UAはMSRPリレー[RFC4976]の後ろに配置されている場合は、UAは、常にクライアントは、A =セットアップ属性で提供してきたどのような値に関係なく、リレーへのトランスポート接続を開始してはなりません。
NOTE: Even if an MSRP UA initiates the TCP connection towards its relay, the UA will only send a SEND request if the UA is active, based on the COMEDIA negotiation.
注：MSRP UAはそのリレーへのTCP接続を開始した場合でも、UAがアクティブな場合、UAはCOMEDIA交渉に基づいて、SEND要求を送信します。
An MSRP UA conformant to this document can interoperate with a UA that follows the connection model defined in [RFC4975]. However, if an MSRP UA conformant to this document is located behind a NAT, does not proxy its MSRP communication via an MSRP relay, and receives an SDP offer from a remote UA that follows the connection model defined in [RFC4975], then NAT traversal can only be achieved if the MSRP UA supports ICE [ICE-TCP] or if the network supports Session Border Controller (SBC)-assisted NAT traversal for TCP.
このドキュメントへのMSRP UAの適合は、[RFC4975]で定義された接続モデルを以下UAと相互運用することができます。しかし、このドキュメントへのMSRP UAの適合がNATの背後に配置されている場合、MSRPリレーを介してそのMSRP通信プロキシない、と[RFC4975]で定義された接続モデルに従う遠隔UAからSDPオファーを受信し、その後、NATトラバーサルMSRP UAは、ICE [ICE-TCP]をサポートしている場合やネットワークがセッションボーダーコントローラー（SBC）はTCPのためのNATトラバーサルを-assistedサポートしている場合にのみ達成することができます。
According to the connection model defined in [RFC4975], the MSRP UA that sends the SDP offer becomes the active party, and it is responsible for creating the MSRP transport connection towards the remote UA if a new connection is required.
[RFC4975]で定義された接続モデルによれば、SDPオファーを送りMSRP UAは、アクティブパーティとなり、新たな接続が必要な場合は、リモートUAへのMSRPのトランスポート接続を作成する責任があります。
When COMEDIA is used, either the sender or the receiver of the SDP offer can become the active party. [RFC4975] requires that the active party immediately issue an MSRP SEND request once the connection has been established. This allows the passive party to bind the inbound TCP connection to the message session identified by the session id part of its MSRP URI. The use of COMEDIA does not change this requirement, but the sender of the SDP offer is no longer assumed to always become the active party.
COMEDIAを使用する場合は、送信者またはSDPオファーの受信機のいずれかがアクティブの当事者になることができます。 [RFC4975]は、接続が確立された後、アクティブパーティはすぐにMSRP SEND要求を発行することが必要です。これは、受動的な当事者がそのMSRP URIのセッションIDの一部で識別されるメッセージセッションへのインバウンドTCP接続をバインドすることができます。 COMEDIAの使用は、この要件を変更しませんが、SDPオファーの送信者は、もはや常にアクティブパーティになることを想定しています。
The active party also takes the role of the TLS client, if TLS is used to protect the MSRP messages. However, there are no procedures in [RFC4975] that would break in case the receiver of the SDP offer takes the role of the TLS client, and the level of security provided by TLS is not affected.
TLSは、MSRPメッセージを保護するために使用されている場合は、アクティブパーティはまた、TLSクライアントの役割を果たしています。しかし、場合に破る[RFC4975]には手順は、SDPオファーの受信機はTLSクライアントの役割を取り、TLSによって提供されるセキュリティのレベルは影響を受けませんありません。
Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, and Shida Schubert for their guidance and input in producing this document.
このドキュメントを製造する際の指導や入力のためのベン・キャンベル、レミデニス・Courmont、ナンシー・グリーン、Hadrielカプラン、アダムローチ、ロバート・スパークス、サルヴァトーレロレート、および志田シューベルトに感謝します。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[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月。
[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月。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、エド。、マーイ、R.、エド。、およびC.ジェニングス、エド。、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.
[RFC4976]ジェニングス、C.、マーイ、R.、およびA.ローチ、RFC 4976、2007年9月の "メッセージセッションリレープロトコル（MSRP）のためのリレー拡張機能"。
[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月。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]グハ、S.、エド。、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNATの行動の要件"、BCP 142、RFC 5382、2008年10月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010.
[RFC5780]マクドナルド、D.とB. Lowekamp、RFC 5780、2010年5月、 "NAT（STUN）のセッショントラバーサルユーティリティを使用してNAT挙動検出"。
[ICE-TCP] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, February 2011.
[ICE-TCP]、進歩、2011年2月作業ローゼンバーグ、J.、Keranen、A.、Lowekamp、B.、およびA.ローチ、 "インタラクティブ接続確立（ICE）とTCP候補"。
[OMA-SIMPLE] Open Mobile Alliance, "Instant Messaging using SIMPLE", OMA-TS-SIMPLE_IM-V1_0-20090901-D, September 2009.
[OMA-SIMPLE]オープン・モバイル・アライアンス、 "インスタントメッセージングSIMPLE使用"、OMA-TS-SIMPLE_IM-V1_0-20090901-D、2009年9月。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
クリステルHolmbergのエリクソンHirsalantie 11 02420 Jorvasフィンランド
EMail: christer.holmberg@ericsson.com
メールアドレス：christer.holmberg@ericsson.com
Staffan Blau Ericsson AB PO Box 407 Sweden
StaffanブラウエリクソンAB、私書箱407スウェーデン
EMail: staffan.blau@ericsson.com
メールアドレス：staffan.blau@ericsson.com