[要約] RFC 6135は、MSRPの代替接続モデルに関するものであり、MSRPセッションの信頼性と効率性を向上させることを目的としています。
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)
メッセージセッションリレープロトコル（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トランスポート接続を作成するために、接続指向のメディア（コメディア）メカニズムを使用します。このモデルにより、MSRPメッセージがNATをトラバースするために、ネットワークアドレス翻訳者（NAT）の背後にあるMSRP UASが交渉するエンドポイントを交渉することができます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ライセンステキストを含める必要があります。
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トランスポート接続の作成を作成する責任があることを示しています。新しい接続が必要な場合。コア仕様は、MSRP UASがMSRP輸送接続を作成するための代替メカニズムも許可しますが、定義しません。
[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 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）の背後にある場合に特に役立ちます。エンドポイントはメカニズムを使用して、メディアがリレーを使用せずに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）定義された「単純な」[OMA-SIMPLE]を使用した「インスタントメッセージ」[インスタントメッセージ]です。ここで、すべてのMSRPトランスポート接続の1つのMSRP UAは、常にキャリアネットワークにあるメディアサーバーを表します。メディアサーバーには、グローバルに到達可能なIPアドレスがあり、アプリケーション固有のポリシーコントロールとNATトラバーサルを処理します。OMA IM（Instant Messenger）は、Nat Traversalに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がComediaを使用して、どのUAが他のUAに向かってMSRPトランスポートTCP接続を作成するかを交渉する方法を定義します。このドキュメントでは、Comediaを使用するMSRP UAが、ComediaをサポートしていないリモートUAとのMSRP輸送接続をどのように確立できるかを定義しています。
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 UASに対してオプションです。NATを使用してネットワークに展開される可能性が高いUASは、この仕様をサポートする必要があります。TCP接続の確立を開始するためにNATの背後にあるUASをリクエストできるため、TCP接続を正常にNATを横断することができる可能性が向上します。
This section defines how an MSRP UA that supports this specification uses the COMEDIA SDP attributes defined in [RFC4145].
このセクションでは、この仕様をサポートするMSRP UAが[RFC4145]で定義されているComedia SDP属性をどのように使用するかを定義します。
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は、SDP A = Setup属性[RFC4145]を使用して、どのエンドポイントが他のUAに向かってMSRP輸送接続を作成するかをネゴシエートします。
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.
MSRP UAには、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 = setup "active"、 "actPass"、および「パッシブ」属性値をサポートする必要があります。MSRP UAは、「HoldConn」属性値を送信してはなりません。MSRP UAが「HoldConn」属性値を受信する場合、A = setup属性が含まれていないかのようにメッセージを無視して処理する必要があります。
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 = setup属性値が「actpass」または「パッシブ」の場合、SDPのMSRP URIのIPアドレスとポート値A = PATH属性には、UAがTCP接続を受信できる実際のアドレスとポート値を含める必要がありますMSRP輸送接続用。
In accordance with [RFC4145], if the a=setup attribute value is "active", the port number value should be 9.
[RFC4145]に従って、a = setup属性値が「アクティブ」の場合、ポート番号値は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でA =セットアップ「ActPass」属性値を使用する必要があります。これは、リモートUAがUAがNATの背後にある場合、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 = setup "passive"属性値を使用してはなりません。
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
o UAは、リレーを介してMSRP輸送接続をリレーします（例：リレーNAT（ターン）サーバーを使用した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].
o UAは、NAT（STUN）[RFC5389]シグナリングのセッショントラバーサルユーティリティを使用して、最終的な輸送接続に使用されるローカルポートを介してNATアドレスとポートを取得し、NATにエンドポイントに依存しないマッピングとフィルタリングがあると判断しました。行動[RFC5382]、たとえば、[RFC5780]で定義されたメカニズムを使用しています。
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.
一部のUASは、SIP [RFC3261]シグナル伝達が、最初のSIPレジスタリクエストに対する200（OK）応答でヘッダーフィールドを介してSIPを検査し、Via Sent-Byと受信したIPアドレスを比較することにより、NATを横断したかどうかを判断できます。ヘッダーフィールドパラメーター。IPアドレスが同じでない場合、UAはパスにNATがあると判断できます。メディアの輸送はNATを横断しないかもしれませんが、それがそうなると仮定するのは安全です。ただし、この比較メカニズムは、すべてのシナリオでは機能しません。たとえば、NATを越える前にSIP Aリクエストが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オファーにA =セットアップ「ActPass」属性値が含まれている場合、SDP回答者にはSDP回答にA =セットアップ「アクティブ」属性値を含めることができますが、A = Setup "Passive"属性値を含める必要があります。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トランスポート接続を確立すると、UAは[RFC4975]で定義されているように、すぐにMSRP送信要求を送信する必要があります。
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）を使用している場合、[RFC4975]および[RFC4976]で定義されたTLSメカニズムを使用する必要があります。
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が自己署名TLS証明書を使用してMSRPピアに認証する場合、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.
MSRPリレー[RFC4976]は、指紋属性を含むSDPペイロードを受け取らないため、指紋はピアツーピア通信でのみ交換できることに注意してください。
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 UASは、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 = Setup属性でクライアントが提供している値に関係なく、常にリレーに向かって輸送接続を開始する必要があります。
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はComediaの交渉に基づいてUAがアクティブな場合にのみ送信要求を送信します。
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]をサポートしている場合、またはネットワークがTCPのセッションボーダーコントローラー（SBC）支援NATトラバーサルをサポートしている場合にのみ達成できます。
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.
コメディアを使用すると、送信者またはSDPオファーの受信者のいずれかがアクティブパーティーになります。[RFC4975]接続が確立されたら、アクティブパーティがすぐにMSRP送信要求を発行することを要求します。これにより、パッシブパーティは、MSRP URIのセッションID部分によって識別されたメッセージセッションにインバウンドTCP接続を結合できます。コメディアの使用はこの要件を変更するものではありませんが、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クライアントの役割も取得します。ただし、SDPオファーの受信者がTLSクライアントの役割を果たし、TLSが提供するセキュリティのレベルが影響を受けない場合に壊れる[RFC4975]には手順はありません。
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.
ベン・キャンベル、レミ・デニス・コールモント、ナンシー・グリーン、ハドリエル・カプラン、アダム・ローチ、ロバート・スパークス、サルヴァトーレ・ロレト、シダ・シューベルトに感謝し、この文書の作成における指導と情報を提供してくれました。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、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] Campbell、B.、ed。、Mahy、R.、ed。、およびC. Jennings、ed。、「The Message Session Relay Protocol（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] Jennings、C.、Mahy、R。、およびA. Roach、「メッセージセッションリレープロトコル（MSRP）のリレー拡張機能」、RFC 4976、2007年9月。
[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月。
[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] Guha、S.、Ed。、Biswas、K.、Ford、B.、Sivakumar、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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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] MacDonald、D。およびB. Lowekamp、「NAT（STUN）のセッショントラバーサルユーティリティを使用したNAT行動発見」、RFC 5780、2010年5月。
[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] Rosenberg、J.、Keranen、A.、Lowekamp、B。、およびA. Roach、「Interactive Connectivity Indecivity Indecivitive（ICE）のTCP候補」、2011年2月の作業。
[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
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: christer.holmberg@ericsson.com
Staffan Blau Ericsson AB PO Box 407 Sweden
スタッフのブラウエリクソンAB PO Box 407スウェーデン
EMail: staffan.blau@ericsson.com