Internet Engineering Task Force (IETF) C. Boulton
Request for Comments: 6314 NS-Technologies
Category: Informational J. Rosenberg
ISSN: 2070-1721 Skype
G. Camarillo
Ericsson
F. Audet
Skype
July 2011
NAT Traversal Practices for Client-Server SIP
Abstract
抽象
Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows.
セッション開始プロトコル（SIP）、それがネットワークアドレス変換（NAT）を介して確立したセッションのトラバーサルは複雑な問題です。現在、多くの導入シナリオとメディアトラフィックのためのトラバースメカニズムがあります。この文書では、具体的な提言やNATトラバーサルなどの流れを、対応する文書のための統一された方法を提供します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6314.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6314で取得することができます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution Technology Outline Description . . . . . . . . . . . 8
4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 8
4.1.2. Client-Initiated Connections . . . . . . . . . . . . . 9
4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 10
4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. STUN/TURN/ICE . . . . . . . . . . . . . . . . . . . . 11
5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 12
5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 12
5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 12
5.1.2. Registration(Registrar/Edge Proxy Not Co-Located) . . 16
5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 19
5.1.4. Receiving an Invitation to a Session . . . . . . . . . 22
5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 27
5.2.1. Endpoint-Independent NAT . . . . . . . . . . . . . . . 28
5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 48
6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 57
6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 57
7. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1. Normative References . . . . . . . . . . . . . . . . . . . 58
9.2. Informative References . . . . . . . . . . . . . . . . . . 59
NAT (Network Address Translator) traversal has long been identified as a complex problem when considered in the context of the Session Initiation Protocol (SIP) [RFC3261] and its associated media such as the Real-time Transport Protocol (RTP) [RFC3550]. The problem is exacerbated by the variety of NATs that are available in the marketplace today and the large number of potential deployment scenarios. Details of different NATs behavior can be found in "NAT Behavioral Requirements for Unicast UDP" [RFC4787].
NAT（ネットワークアドレス変換）トラバーサルは長い間、このようなリアルタイムトランスポートプロトコル（RTP）[RFC3550]としてセッション開始プロトコル（SIP）[RFC3261]及びそれに関連したメディアの文脈で考慮複雑な問題として同定されています。問題は、市場で今日と潜在的な展開シナリオが多数用意されていNATのさまざまなによって悪化します。異なるNATの動作の詳細については、[RFC4787]「ユニキャストUDPのNATの行動の要件」に記載されています。
The IETF has been active on many specifications for the traversal of NATs, including Session Traversal Utilities for NAT (STUN) [RFC5389], Interactive Connectivity Establishment (ICE) [RFC5245], symmetric response [RFC3581], symmetric RTP [RFC4961], Traversal Using Relay NAT (TURN) [RFC5766], SIP Outbound [RFC5626], the Session Description Protocol (SDP) attribute for RTP Control Protocol (RTCP) [RFC3605], "Multiplexing RTP Data and Control Packets on a Single Port" [RFC5761], and others. Each of these represents a part of the solution, but none of them gives the overall context for how the NAT traversal problem is decomposed and solved through this collection of specifications. This document serves to meet that need. It should be noted that this document intentionally does not invoke 'Best Current Practice' machinery as defined in RFC 2026 [RFC2026].
IETFは、[RFC5389]、インタラクティブ接続確立（ICE）[RFC5245]、対称的な応答[RFC3581]、対称RTP [RFC4961]、トラバーサルNAT用セッショントラバーサルユーティリティ（STUN）などのNATのトラバーサルのための多くの仕様に活動していますリレーNAT（TURN）[RFC5766]を使用して、SIPアウトバウンド[RFC5626]、RTP制御プロトコル（RTCP）[RFC3605]のためのセッション記述プロトコル（SDP）属性、[RFC5761] "シングルポートの多重化RTPデータおよび制御パケット" 、 その他。これらのそれぞれは、ソリューションの一部を表し、それらのどれもNAT越え問題を分解し、仕様のこのコレクションを解決する方法のための全体的な文脈を与えません。この文書では、そのニーズを満たすのに役立ちます。 RFC 2026 [RFC2026]で定義された、この文書は、意図的に「ベストプラクティス現在の」機械を起動していないことに留意すべきです。
The document is split into two distinct sections as follows:
次のように文書は、2つの異なるセクションに分割されます。
o Section 4 provides a definitive set of best common practices to demonstrate the traversal of SIP and its associated media through NAT devices.
O部4は、NATデバイスを介してSIPおよびそれに関連したメディアの横断を実証するための最良の共通プラクティスの決定的なセットを提供します。
o Section 5 provides non-normative examples representing interactions of SIP using various NAT type deployments.
O部5は、種々のNATタイプの展開を使用して、SIPの相互作用を示す非規範的な例を提供します。
The document does not propose any new functionality but does draw on existing solutions for both core SIP signaling and media traversal (as defined in Section 4).
文書は、どんな新しい機能を提案していないが、コアのSIPシグナリングおよびメディア・トラバーサル（セクション4で定義されている）の両方のために、既存のソリューションに描くありません。
The best practices described in this document are for traditional "client-server"-style SIP. This term refers to the traditional use of the SIP protocol where User Agents talk to a series of intermediaries on a path to connect to a remote User Agent. It seems likely that other groups using SIP, for example, peer-to-peer SIP (P2PSIP), will recommend these same practices between a P2PSIP client and a P2PSIP peer, but will recommend different practices for use between peers in a peer-to-peer network.
この文書で説明するベスト・プラクティスは、SIPスタイルの伝統的な「クライアント・サーバ」のためのものです。この用語は、ユーザーエージェントは、リモートユーザーエージェントに接続するには、パス上の仲介一連の話をSIPプロトコルの伝統的な使用を意味します。これは、他のグループは、例えば、SIPを使用している可能性が高いと思われるピア・ツー・ピアSIP（P2PSIP）、P2PSIPクライアントとP2PSIPピア間でこれらの同じプラクティスをお勧めしますが、ピア・ツーでピア間で使用するために異なるプラクティスをお勧めします-Peerネットワーク。
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]に記載されているように解釈されます。
It should be noted that the use of the term 'Endpoint-Independent NAT' in this document refers to a NAT that is both Endpoint-Independent Filtering and Endpoint-Independent Mapping per the definitions in RFC 4787 [RFC4787].
なお、本文書において、用語「エンドポイント非依存NAT」の使用は、エンドポイント非依存フィルタリングおよびRFC 4787 [RFC4787]で定義あたりのエンドポイント非依存マッピングの両方でNATを意味することに留意すべきです。
The traversal of SIP through NATs can be split into two categories that both require attention: the core SIP signaling and associated media traversal. This document assumes NATs that do not contain SIP-aware Application Layer Gateways (ALGs), which makes much of the issues discussed in the document not applicable. ALGs have limitations (as per RFC 4787 [RFC4787] Section 7, RFC 3424 [RFC3424], and [RFC5245] Section 18.6), and experience shows they can have an adverse impact on the functionality of SIP. This includes problems such as requiring the media and signaling to traverse the same device and not working with encrypted signaling and/or payload.
コアSIPシグナリングと関連付けられたメディアトラバーサル：NATを介してSIPのトラバーサルは、両方が注意を必要とする2つのカテゴリに分けることができます。この文書は適用されません文書で議論された問題の多くを作るSIP対応のアプリケーション層ゲートウェイ（のALG）が、含まれていないNATのを前提としています。 ALGは、（RFC 4787 [RFC4787]セクション7、RFC 3424 [RFC3424]及び[RFC5245]セクション18.6ごとに）制限があり、そして経験は、それらがSIPの機能に不利な影響を有することができる示しています。これは、メディアを必要と同じ装置を横断するシグナリングと暗号化されたシグナリングおよび/またはペイロードと動作しないなどの問題を含んでいます。
The use of non-TURN-based media intermediaries is not considered in this document. More information can be obtained from [RFC5853] and [MIDDLEBOXES].
非TURNベースのメディア仲介の使用は、この文書では考慮されていません。詳細は[RFC5853]と[中間装置]から得ることができます。
The core SIP signaling has a number of issues when traversing through NATs.
NATを介して通過するとき、コアSIPシグナリングは、多くの問題を有しています。
SIP response routing over UDP as defined in RFC 3261 [RFC3261] without extensions causes the response to be delivered to the source IP address specified in the topmost Via header, or the 'received' parameter of the topmost 'Via' header. The port is extracted from the SIP 'Via' header to complete the IP address/port combination for returning the SIP response. While the destination for the response is correct, the port contained in the SIP 'Via' header represents the listening port of the originating client and not the port representing the open pinhole on the NAT. This results in responses being sent back to the NAT but to a port that is likely not open for SIP traffic. The SIP response will then be dropped at the NAT. This is illustrated in Figure 1, which depicts a SIP response being returned to port 5060.
拡張せず、RFC 3261で定義されているUDP上SIP応答ルーティング[RFC3261]は、応答がViaヘッダー最上位に指定された送信元IPアドレス、または最上位「」を介してヘッダの「受信」パラメータに送達させます。ポートは、SIPレスポンスを返すためのIPアドレス/ポートの組み合わせを完了するために、SIP「」を介してヘッダから抽出されます。応答の宛先が正しいが、SIP「」を介してヘッダに含まれるポートが元のクライアントとNATに開いたピンホールを表していないポートのリスニングポートを表します。これは、バックNATになく、SIPトラフィック用にオープンされていない可能性があるポートに送信された応答になります。 SIP応答は、NATでドロップされます。これは、ポート5060に戻されるSIP応答を示す図1に示されています。
Private NAT Public
Network | Network
|
|
-------- SIP Request |open port 10923 --------
| |-------------------->--->-----------------------| |
| | | | |
| Client | |port 5060 SIP Response | Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
Figure 1: Failed Response
図1：失敗したレスポンス
Secondly, there are two cases where new requests reuse existing connections. The first is when using a reliable, connection-oriented transport protocol such as TCP, SIP has an inherent mechanism that results in SIP responses reusing the connection that was created/used for the corresponding transactional request. The SIP protocol does not provide a mechanism that allows new requests generated in the reverse direction of the originating client to use, for example, the existing TCP connection created between the client and the server during registration. This results in the registered contact address not being bound to the "connection" in the case of TCP. Requests are then blocked at the NAT, as illustrated in Figure 2. The second case is when using an unreliable transport protocol such as UDP where external NAT mappings need to be reused to reach a SIP entity on the private side of the network.
第二に、新しい要求が既存の接続を再利用する2つのケースがあります。 TCPのような信頼性の高いコネクション型トランスポートプロトコルを使用する場合最初は、SIPは、対応するトランザクション要求のために使用/作成された接続を再利用するSIP応答をもたらす固有の機構を有しています。 SIPプロトコルは、例えば、登録時にクライアントとサーバの間で作成した既存のTCP接続元のクライアントの逆方向に生成された新しい要求が使用することを可能にするメカニズムを提供しません。これは、TCPの場合は、「接続」に拘束されない登録連絡先になります。そのような外部のNATマッピングは、ネットワークのプライベート側のSIPエンティティに到達するために再利用する必要がUDPのような信頼性の低いトランスポートプロトコルを使用しているとき第二の場合である図2に示すように、要求は、その後、NATにブロックされます。
Private NAT Public
Network | Network
|
|
-------- (UAC 8023) REGISTER/Response (UAS 5060) --------
| |-------------------->---<-----------------------| |
| | | | |
| Client | |5060 INVITE (UAC 8015)| Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
Figure 2: Failed Request
図2：失敗した要求
In Figure 2, the original REGISTER request is sent from the client on port 8023 and received by the proxy on port 5060, establishing a connection and opening a pinhole in the NAT. The generation of a new request from the proxy results in a request destined for the registered entity (contact IP address) that is not reachable from the public network. This results in the new SIP request attempting to create a connection to a private network address. This problem would be solved if the original connection were reused. While this problem has been discussed in the context of connection-oriented protocols such as TCP, the problem exists for SIP signaling using any transport protocol. The impact of connection reuse of connection-oriented transports (TCP, TLS, etc.) is discussed in more detail in the connection reuse specification [RFC5923]. The approach proposed for this problem in Section 4 of this document is relevant for all SIP signaling in conjunction with connection reuse, regardless of the transport protocol.
図2では、元のREGISTER要求は接続を確立し、NATにピンホールを開け、ポート5060上のプロキシによって、ポート8023上でクライアントから送信され受信されます。パブリックネットワークから到達できない登録済みのエンティティ（連絡先IPアドレス）宛ての要求のプロキシ結果から新しい要求が発生。これは、プライベートネットワークアドレスへの接続を作成しようとする新しいSIPリクエストになります。元の接続が再利用された場合、この問題は解決されるだろう。この問題は、TCPのようなコネクション型のプロトコルの文脈で議論されてきたが、問題は、どのトランスポートプロトコルを使用してSIPシグナリングのために存在します。コネクション型トランスポート（TCP、TLSなど）の接続の再利用の影響は、接続の再利用仕様[RFC5923]でより詳細に議論されます。このドキュメントのセクション4で、この問題のために提案されたアプローチに関係なく、トランスポートプロトコルの、接続の再利用と併せてすべてのSIPシグナリングに関連します。
NAT policy can dictate that connections should be closed after a period of inactivity. This period of inactivity may vary from a number of seconds to hours. SIP signaling cannot be relied upon to keep connections alive for the following two reasons. Firstly, SIP entities can sometimes have no signaling traffic for long periods of time, which has the potential to exceed the inactivity timer, and this can lead to problems where endpoints are not available to receive incoming requests as the connection has been closed. Secondly, if a low inactivity timer is specified, SIP signaling is not appropriate as a keep-alive mechanism as it has the potential to add a large amount of traffic to the network, which uses up valuable resources and also requires processing at a SIP stack, which is also a waste of processing resources.
NATポリシーは、接続が非アクティブの期間後に閉じられなければならないことを指示することができます。非アクティブのこの期間は時間の秒数と異なる場合があります。 SIPシグナリングは、次の2つの理由のために生きているの接続を維持するために依拠することはできません。まず、SIPエンティティは、時々、非アクティブタイマーを超える可能性を秘めている時間の長い期間、のためのシグナリングトラフィックを持つことはできません、これはエンドポイントは、接続がクローズされているように着信要求を受信する利用できない問題につながることができます。低非アクティブタイマーが指定されている場合、それは貴重なリソースを使用して、ネットワークに大量のトラフィックを追加する可能性があり、また、SIPスタックでの処理を必要とする第二に、SIPシグナリングは、キープアライブメカニズムとしては適切ではありませんまた、処理リソースの浪費です。
Media associated with SIP calls also has problems traversing NAT. RTP [RFC3550] runs over UDP and is one of the most common media transport types used in SIP signaling. Negotiation of RTP occurs with a SIP session establishment using the Session Description Protocol (SDP) [RFC4566] and a SIP offer/answer exchange [RFC3264]. During a SIP offer/answer exchange, an IP address and port combination are specified by each client in a session as a means of receiving media such as RTP. The problem arises when a client advertises its address to receive media and it exists in a private network that is not accessible from outside the NAT. Figure 3 illustrates this problem.
SIPに関連したメディアは、NATを通過する問題を抱えているにも呼び出されます。 RTP [RFC3550]はUDP上で動作し、SIPシグナリングに使用される最も一般的なメディアトランスポート・タイプのいずれかです。 RTPのネゴシエーションは、セッション記述プロトコル（SDP）[RFC4566]及びSIPオファー/アンサー交換[RFC3264]を使用して、SIPセッション確立で起こります。 SIPオファー/アンサー交換時には、IPアドレスとポートの組み合わせは、RTPなどのメディアを受信する手段として、セッション内の各クライアントが指定されています。クライアントがメディアを受信するためにそのアドレスをアドバタイズし、それがNATの外部からアクセスできないプライベートネットワーク内に存在する場合に問題が発生します。図3は、この問題を示しています。
NAT Public Network NAT
| |
| |
| |
-------- | SIP Signaling Session | --------
| |---------------------->Proxy<-------------------| |
| | | | | |
| Client | | | | Client |
| A |>=====>RTP>==Unknown Address==>X | | B |
| | | X<==Unknown Address==<RTP<===<| |
-------- | | --------
| |
| |
| |
Figure 3: Failed Media
図3：失敗したメディア
The connection addresses of the clients behind the NATs will nominally contain a private IPv4 address that is not routable across the public Internet. Exacerbating matters even more would be the tendency of Client A to send media to a destination address it received in the signaling confirmation message -- an address that may actually correspond to a host within the private network who is suddenly faced with incoming RTP packets (likewise, Client B may send media to a host within its private network who did not solicit these packets). Finally, to complicate the problem even further, a number of different NAT topologies with different default behaviors increases the difficulty of arriving at a unified approach. This problem exists for all media transport protocols that might be NATted (e.g., TCP, UDP, the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP)).
NATの背後のクライアントの接続アドレスは、名目上、公共のインターネットを介してルーティングできないプライベートIPv4アドレスが含まれています。同様に（アドレス実際に突然入ってくるRTPパケットに直面しているプライベートネットワーク内のホストに対応していてもよい - さらに多くの問題を悪化させることは、それがシグナリング確認メッセージで受信した宛先アドレスにメディアを送信するために、クライアントAの傾向だろう、クライアントBは、これらのパケットを勧誘しませんでしたそのプライベートネットワーク内のホスト）にメディアを送信することができます。最後に、さらに問題を複雑にするために、さまざまなデフォルト動作と異なるNATトポロジーの数は、統一されたアプローチに到着することの難しさを増します。この問題はNATtedされる可能性があるすべてのメディアトランスポートプロトコル（例えば、TCP、UDP、ストリーム制御伝送プロトコル（SCTP）、データグラム輻輳制御プロトコル（DCCP））のために存在します。
In general, the problems associated with NAT traversal can be categorized as follows.
次のように一般的には、NATトラバーサルに関連する問題を分類することができます。
For signaling:
シグナリングの場合：
o Responses do not reuse the NAT mapping and filtering entries created by the request.
Oレスポンスが要求によって作成されたNATマッピングおよびフィルタリングのエントリを再利用しないでください。
o Inbound requests are filtered out by the NAT because there is no long-term connection between the client and the proxy.
クライアントとプロキシの間には、長期的な接続が存在しないので、Oインバウンド要求は、NATによってフィルタリングされています。
For media:
メディアの場合：
o Each endpoint has a variety of addresses that can be used to reach it (e.g., native interface address, public NATted address). In different situations, a different pair of (local endpoint, remote endpoint) addresses should be used, and it is not clear when to use which pair.
Oの各エンドポイントは、（例えば、ネイティブインタフェースアドレス、パブリックNATtedアドレス）に到達するために使用することができるアドレスの多様を有します。別の状況では、（ローカルエンドポイント、リモートエンドポイント）アドレスの異なる対が使用されるべきで、どのペアを使用する場合、それは明らかではありません。
o Many NATs filter inbound packets if the local endpoint has not recently sent an outbound packet to the sender.
ローカルエンドポイントは、最近、送信者に発信パケットを送信していない場合は、O、多くのNATは着信パケットをフィルタリングします。
o Classic RTCP usage is to run RTCP on the next highest port. However, NATs do not necessarily preserve port adjacency.
OクラシックRTCPの使用量は、次の最高のポートでRTCPを実行することです。しかし、NATは必ずしもポート隣接関係を保持しません。
o Classic RTP and RTCP usage is to use different 5-tuples for traffic in each direction. Though not really a problem, doing this through NATs is more work than using the same 5-tuple in both directions.
OクラシックRTPとRTCPの使用は、各方向のトラフィックに対して異なる5タプルを使用することです。本当に問題が、NATを介してこれを行うと、両方向に同じ5タプルを使用するよりもより多くの仕事です。
As mentioned previously, the traversal of SIP through existing NATs can be divided into two discrete problem areas: getting the SIP signaling across NATs and enabling media as specified by SDP in a SIP offer/answer exchange to flow between endpoints.
NATを横切ってSIPシグナリングを取得し、エンドポイント間で流れるようにSIPオファー/アンサー交換にSDPで指定されたメディアを可能にする：前述のように、既存のNATを介してSIPのトラバーサルは、2つの別個の問題領域に分割することができます。
SIP signaling has two areas that result in transactional failure when traversing through NATs, as described in Section 3 of this document. The remaining sub-sections describe appropriate solutions that result in SIP signaling traversal through NATs, regardless of transport protocol. It is advised that SIP-compliant entities follow the guidelines presented in this section to enable traversal of SIP signaling through NATs.
SIPシグナリングは、NATを介して通過するときに、このドキュメントのセクション3に記載されているように、トランザクションの失敗につながる二つの領域を有しています。残りのサブセクションにかかわらず、トランスポートプロトコル、NATを介してトラバーサルをSIPシグナリングをもたらす適切な解決策を記載しています。 SIPに準拠したエンティティがNATを介したシグナル伝達SIPのトラバーサルを有効にするには、このセクションで説明するガイドラインに従うことをお勧めします。
As described in Section 3 of this document, when using an unreliable transport protocol such as UDP, SIP responses are sent to the IP address and port combination contained in the SIP 'Via' header field (or default port for the appropriate transport protocol if not present). Figure 4 illustrates the response traversal through the open pinhole using Symmetric techniques defined in RFC 3581 [RFC3581].
このドキュメントのセクション3に記載されているようなUDPのような信頼性の低いトランスポートプロトコルを使用する場合、SIP応答は、適切なトランスポートプロトコルのSIP「」を介してヘッダフィールド（またはデフォルトのポートに含まれるIPアドレスとポートの組み合わせに送信されない場合存在）。図4は、RFC 3581 [RFC3581]で定義された対称的な技術を使用してオープンピンホールを介して応答トラバーサルを示します。
Private NAT Public
Network | Network
|
|
-------- | --------
| | | | |
| |send request---------------------------------->| |
| Client |<---------------------------------send response| SIP |
| A | | | Proxy |
| | | | |
-------- | --------
|
|
|
Figure 4: Symmetric Response
図4：対称応答
The outgoing request from Client A opens a pinhole in the NAT. The SIP Proxy would normally respond to the port available in the SIP 'Via' header, as illustrated in Figure 1. The SIP Proxy honors the 'rport' parameter in the SIP 'Via' header and routes the response to the port from which it was sent. The exact functionality for this method of response traversal is called 'Symmetric Response', and the details are documented in RFC 3581 [RFC3581]. Additional requirements are imposed on SIP entities in RFC 3581 [RFC3581] such as listening and sending SIP requests/responses from the same port.
クライアントAからの発信要求は、NATでピンホールを開きます。図1に示すように、SIPプロキシは、通常、SIPプロキシは、SIP「」を介してヘッダと経路のポートへの応答を「RPORT」パラメータを表彰、SIP「」を介してヘッダで利用可能なポートに応答するであろうから、それ送信されました。応答トラバーサルのこの方法の正確な機能は、「対称応答」と呼ばれ、その詳細は、RFC 3581 [RFC3581]に記載されています。追加要件は、リスニングなど[RFC3581] RFC 3581でのSIPエンティティに課せられたと同じポートからのSIPリクエスト/レスポンスを送信しています。
The second problem with SIP signaling, as defined in Section 3 and illustrated in Figure 2, is to allow incoming requests to be properly routed.
SIPシグナリングの第2の問題は、セクション3で定義され、図2に示すように、適切にルーティングする着信要求を許可することです。
Guidelines for devices such as User Agents that can only generate outbound connections through NATs are documented in "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)" [RFC5626]. The document provides techniques that use a unique User Agent instance identifier (instance-id) in association with a flow identifier (reg-id). The combination of the two identifiers provides a key to a particular connection (both UDP and TCP) that is stored in association with registration bindings. On receiving an incoming request to a SIP Address-Of-Record (AOR), a proxy/registrar routes to the associated flow created by the registration and thus a route through NATs. It also provides a keep-alive mechanism for clients to keep NAT bindings alive. This is achieved by multiplexing a ping-pong mechanism over the SIP signaling connection (STUN for UDP and
唯一のNATを介して発信接続を生成することができ、このようなユーザエージェントのようなデバイスのためのガイドラインは、[RFC5626]を「セッション開始プロトコル（SIP）のクライアントで開始された接続の管理」に記載されています。文書は、フロー識別子（REG-ID）に対応付けて、一意のユーザエージェントインスタンス識別子（インスタンスID）を使用する技術を提供します。二つの識別子の組み合わせが登録バインディングに関連付けて記憶されている特定の接続（UDPおよびTCPの両方）にキーを提供します。登録およびNATを介してこのような経路によって作成された関連するフローにSIPアドレス・オブ・レコード（AOR）、レジストラプロキシ/ルートに着信要求を受信します。また、クライアントが生きているNATバインディングを維持するためのキープアライブメカニズムを提供します。これは、多重化UDPのSIPシグナリング接続（STUNオーバーピンポン機構により達成されます
CRLF/operating system keepalive for reliable transports like TCP). Usage of [RFC5626] is RECOMMENDED. This mechanism is not transport specific and should be used for any transport protocol.
TCPのような信頼性の高いトランスポートのためのCRLF /オペレーティングシステムのキープアライブ）。 [RFC5626]の使用が推奨されます。このメカニズムは、特定のトランスポートされておらず、任意のトランスポートプロトコルを使用する必要があります。
Even if the SIP Outbound mechanism is not used, clients generating SIP requests SHOULD use the same IP address and port (i.e., socket) for both transmission and receipt of SIP messages. Doing so allows for the vast majority of industry provided solutions to properly function (e.g., NAT traversal that is Session Border Control (SBC) hosted). Deployments should also consider the mechanism described in the Connection Reuse [RFC5923] specification for routing bidirectional messages securely between trusted SIP Proxy servers.
SIPアウトバウンド機構が使用されていない場合でも、SIPリクエストを生成するクライアントは、SIPメッセージの送信と受信の両方に同じIPアドレスとポート（すなわち、ソケット）を使用してください。そうすることで、業界の大多数が正常に機能（セッションボーダーコントロール（SBC）がホストされている、例えば、NATトラバーサル）にソリューションを提供することができます。展開はまた、安全、信頼できるSIPプロキシサーバとの間で双方向のメッセージをルーティングするための接続再利用[RFC5923]明細書に説明されたメカニズムを検討すべきです。
The issues of media traversal through NATs is not straightforward and requires the combination of a number of traversal methodologies. The technologies outlined in the remainder of this section provide the required solution set.
NATを通じたメディア・トラバーサルの問題は簡単ではないとトラバーサル方法論の番号の組み合わせを必要とします。このセクションの残りの部分で概説した技術は、必要なソリューションセットを提供します。
The primary problem identified in Section 3 of this document is that internal IP address/port combinations cannot be reached from the public side of NATs. In the case of media such as RTP, this will result in no audio traversing NATs (as illustrated in Figure 3). To overcome this problem, a technique called 'Symmetric RTP/RTCP' [RFC4961] can be used. This involves a SIP endpoint both sending and receiving RTP/RTCP traffic from the same IP address/port combination. When operating behind a NAT and using the 'latching' technique described in [MIDDLEBOXES], SIP User Agents MUST implement Symmetric RTP/RTCP. This allows traversal of RTP across the NAT.
このドキュメントのセクション3で特定の主な問題は内部IPアドレス/ポートの組み合わせは、NATの公共の側から到達することができないということです。 （図3に示すように）、例えばRTPのようなメディアの場合には、これはオーディオ横断NATをもたらすであろう。この問題を克服するために、「対称RTP / RTCP」[RFC4961]と呼ばれる技術を使用することができます。これは、同じIPアドレス/ポートの組み合わせからRTP / RTCPトラフィックの送信と受信の両方のSIPエンドポイントを必要とします。 NATの背後に動作し、[中間装置]に記載の「ラッチ」技術を使用する場合は、SIPユーザエージェントは対称RTP / RTCPを実装しなければなりません。これは、NAT越えRTPの横断を可能にします。
Normal practice when selecting a port for defining RTP Control Protocol (RTCP) [RFC3550] is for consecutive-order numbering (i.e., select an incremented port for RTCP from that used for RTP). This assumption causes RTCP traffic to break when traversing certain types of NATs due to various reasons (e.g., already allocated port, randomized port allocation). To combat this problem, a specific address and port need to be specified in the SDP rather than relying on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute that is included to explicitly specify transport connection information for RTCP so a separate, explicit NAT binding can be set up for the purpose. The address details can be obtained using any appropriate method including those detailed in this section (e.g., STUN, TURN, ICE).
RTP制御プロトコル（RTCP）[RFC3550]を定義するためのポートを選択する通常の慣行が連続順序番号のためのものである（すなわち、RTPに使用されるものからRTCPのためにインクリメントポートを選択）。この仮定は、様々な理由（例えば、既に割り当てられたポート、無作為ポート割り当て）へのNATの特定のタイプを横断するときに破壊するRTCPトラフィックを引き起こします。この問題に対処するために、特定のアドレスとポートではなく、そのような仮定に頼るよりも、SDPで指定する必要があります。 RFC 3605 [RFC3605]は、明示的にRTCPのトランスポート接続情報そう別、明示的なNATは、目的のために設定することが可能な結合を指定するために含まれるSDP属性を定義します。アドレスの詳細は、このセクション（例えば、STUN、TURN、ICE）に詳述されるものを含む任意の適切な方法を用いて得ることができます。
A further enhancement to RFC 3605 [RFC3605] is defined in [RFC5761], which specifies 'muxing' both RTP and RTCP on the same IP/PORT combination.
RFC 3605 [RFC3605]にさらなる強化は、同じIP /ポートの組み合わせでRTPとRTCP双方「多重化」を指定する、[RFC5761]で定義されています。
ICE, STUN, and TURN are a suite of 3 inter-related protocols that combine to provide a complete media traversal solution for NATs. The following sections provide details of each component part.
ICE、STUN、及びTURNはNATのための完全なメディアトラバーサル・ソリューションを提供するために組み合わせる3相互に関連したプロトコルのスイートです。以下のセクションでは、各構成部品の詳細を提供します。
Session Traversal Utilities for NAT or STUN is defined in RFC 5389 [RFC5389]. STUN is a lightweight tool kit and protocol that provides details of the external IP address/port combination used by the NAT device to represent the internal entity on the public facing side of NATs. On learning of such an external representation, a client can use it accordingly as the connection address in SDP to provide NAT traversal. Using terminology defined in "NAT Behavioral Requirements for Unicast UDP" [RFC4787], STUN does work with Endpoint-Independent Mapping but does not work with either Address-Dependent Mapping or Address and Port-Dependent Mapping type NATs. Using STUN with either of the previous two NAT mappings to probe for the external IP address/port representation will provide a different result to that required for traversal by an alternative SIP entity. The IP address/ port combination deduced for the STUN server would be blocked for RTP packets from the remote SIP User Agent.
NATまたはSTUNのためのセッショントラバーサルユーティリティは、RFC 5389 [RFC5389]で定義されています。 STUNは、NATのパブリックの対向側の内部エンティティを表すために、NATデバイスによって使用される外部IPアドレス/ポートの組み合わせの詳細を提供する軽量のツールキットおよびプロトコルです。そのような外部表現の学習に、クライアントがNATトラバーサルを提供するために、SDPに接続アドレスとしてそれに応じて使用することができます。 「ユニキャストUDPのNATの行動の要件」[RFC4787]で定義された用語を使用して、STUNはエンドポイントに依存しないマッピングで作業を行いますが、アドレス依存マッピングまたはアドレスとポート依存マッピングタイプのNATのいずれかで動作しません。外部IPアドレス/ポートの表現を探索するために、前の2つのNATマッピングのいずれかでSTUNを使用する別のSIPエンティティによってトラバーサルのために必要とは異なる結果を提供するであろう。 STUNサーバー用に演繹IPアドレス/ポートの組み合わせは、リモートSIPユーザエージェントからのRTPパケットのためにブロックされます。
As mentioned in Section 4.1.2, STUN is also used as a client-to-server keep-alive mechanism to refresh NAT bindings.
4.1.2項で述べたように、STUNは、NATバインディングをリフレッシュするため、クライアントからサーバーへのキープアライブメカニズムとして使用されています。
As described in Section 4.2.3.1, the STUN protocol does not work for UDP traversal through certain identified NAT mappings. 'Traversal Using Relays around NAT' is a usage of the STUN protocol for deriving (from a TURN server) an address that will be used to relay packets towards a client. TURN provides an external address (globally routable) at a TURN server that will act as a media relay that attempts to allow traffic to reach the associated internal address. The full details of the TURN specification are defined in [RFC5766]. A TURN service will almost always provide media traffic to a SIP entity, but it is RECOMMENDED that this method would only be used as a last resort and not as a general mechanism for NAT traversal. This is because using TURN has high performance costs when relaying media traffic and can lead to unwanted latency.
セクション4.2.3.1で説明したように、STUNプロトコルは、特定の識別NATマッピングを通じてUDPトラバーサルのために動作しません。 「NATの周りにリレーを使用トラバーサル」は（TURNサーバから）クライアントに向けてパケットを中継するために使用されるアドレスを導出するためのSTUNプロトコルの使用です。 TURNは、トラフィックが関連する内部アドレスに到達することを可能にしようとするメディアリレーとして機能するTURNサーバーの外部アドレス（グローバルにルーティング可能）を提供します。 TURN仕様の詳細は、[RFC5766]で定義されています。 TURNサービスは、ほとんどの場合、SIPエンティティへのメディアトラフィックを提供しますが、この方法は最後の手段としてのみではなくNATトラバーサルのための一般的な機構として使用されることが推奨されます。 TURNを使用すると、メディアトラフィックを中継する際に、高いパフォーマンスコストがあり、不要なレイテンシーにつながることができるからです。
Interactive Connectivity Establishment (ICE) is the RECOMMENDED method for traversal of existing NATs if Symmetric RTP and media latching are not sufficient. ICE is a methodology for using existing technologies such as STUN, TURN, and any other protocol compliant with Unilateral Self-Address Fixing (NSAF) [RFC3424] to provide a unified solution. This is achieved by obtaining as many representative IP address/port combinations as possible using technologies such as STUN/TURN (note: an ICE endpoint can also use other mechanisms (e.g., the NAT Port Mapping Protocol [NAT-PMP], Universal Plug and Play Internet Gateway Device [UPnP-IGD]) to learn public IP addresses and ports, and populate a=candidate lines with that information). Once the addresses are accumulated, they are all included in the SDP exchange in a new media attribute called 'candidate'. Each candidate SDP attribute entry has detailed connection information including a media address, priority, and transport protocol. The appropriate IP address/port combinations are used in the order specified by the priority. A client compliant to the ICE specification will then locally run STUN servers on all addresses being advertised using ICE. Each instance will undertake connectivity checks to ensure that a client can successfully receive media on the advertised address. Only connections that pass the relevant connectivity checks are used for media exchange. The full details of the ICE methodology are in [RFC5245].
インタラクティブ接続確立（ICE）対称RTPメディアラッチが十分でない場合は、既存のNATトラバーサルのために推奨される方法です。 ICEは、STUN、TURN、および統合ソリューションを提供するために片側自アドレス固定（NSAF）[RFC3424]に準拠した他のプロトコルのような既存の技術を使用するための方法です。これは、（ノート等STUN / TURNなどの技術を使用して、できるだけ多くの代表IPアドレス/ポートの組み合わせを取得することによって達成される：ICEのエンドポイントは、他のメカニズム（例えば、NATポートマッピングプロトコル[NAT-PMP]、ユニバーサルプラグを使用することができますし、 ）パブリックIPアドレスとポートを学び、その情報を持つ=候補線を投入するためにインターネットゲートウェイデバイスを[UPnPの-IGD]）を再生。アドレスが蓄積されると、それらはすべての「候補」と呼ばれる新しいメディア属性でSDP交換に含まれています。各候補SDP属性エントリは、メディア・アドレス、優先順位、およびトランスポートプロトコルを含むコネクション情報を詳述しています。適切なIPアドレス/ポートの組み合わせは、優先順位によって指定された順序で使用されています。 ICE仕様に準拠したクライアントは、ローカルにICEを使用してアドバタイズされているすべてのアドレスにSTUNサーバーを実行します。各インスタンスは、クライアントが正常にアドバタイズされたアドレスにメディアを受信できることを保証するために、接続性チェックを実施します。関連の接続性チェックをパスのみの接続は、メディアの交換に使用されています。 ICEの方法論の詳細は[RFC5245]です。
This section of the document includes detailed NAT traversal scenarios for both SIP signaling and the associated media. Signaling NAT traversal is achieved using [RFC5626].
文書のこのセクションでは、SIPシグナリングと関連する媒体の両方のための詳細なNATトラバーサル・シナリオを含みます。シグナリングNATトラバーサルは、[RFC5626]を使用して達成されます。
The following sub-sections concentrate on SIP signaling traversal of NATs. The scenarios include traversal for both reliable and unreliable transport protocols.
以下のサブセクションでは、NATをトラバースのSIPシグナリングに集中します。シナリオは、信頼性と信頼性のないトランスポートプロトコルの両方のためのトラバーサルが含まれています。
The set of scenarios in this section document basic signaling traversal of a SIP REGISTER method through NATs.
NATを介してSIP REGISTERメソッドのこのセクションの文書の基本的なシグナリング・トラバーサルにおけるシナリオのセット。
Registrar/
Bob NAT Edge Proxy
| | |
|(1) REGISTER | |
|----------------->| |
| | |
| |(1) REGISTER |
| |----------------->|
| | |
|*************************************|
| Create Outbound Connection Tuple |
|*************************************|
| | |
| |(2) 200 OK |
| |<-----------------|
| | |
|(2) 200 OK | |
|<-----------------| |
| | |
Figure 5: UDP Registration
図5：UDP登録
In this example, the client sends a SIP REGISTER request through a NAT. The client will include an 'rport' parameter as described in Section 4.1.1 of this document for allowing traversal of UDP responses. The original request as illustrated in (1) in Figure 5 is a standard SIP REGISTER message:
この例では、クライアントは、NAT経由のSIP REGISTERリクエストを送信します。 UDP応答のトラバースを可能にするために、このドキュメントのセクション4.1.1で説明したように、クライアントは「RPORT」パラメータが含まれます。図5の（1）に示すように、元の要求は、標準のSIP REGISTERメッセージです。
Message 1:
メッセージ1：
REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sip:bob@example.com>;tag=7F94778B653B To: Bob <sip:bob@example.com> Call-ID: 16CB75F21C70 CSeq: 1 REGISTER Supported: path, outbound Contact: <sip:bob@192.168.1.2 >;reg-id=1 ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" Content-Length: 0
5,438：ボブexample.com SIP / 2.0経由：：;; RPORTブランチ= z9hG4bKnashds7マックス・フォワードSIP / 2.0 / UDP 192.168.1.2 SIPレジスタ<一口：bob@example.com>;タグ= 7F94778B653Bをするには：ボブ< SIP：bob@example.com>コール-IDを：16CB75F21C70のCSeq：1 REGISTERサポート：パス、アウトバウンド連絡先：<SIP：bob@192.168.1.2>; REG-ID = 1; + sip.instance = "<壷：UUID ：00000000-0000-1000-8000-AABBCCDDEEFF>」のContent-Length：0
This SIP transaction now generates a SIP 200 OK response, as depicted in (2) from Figure 5:
図5の（2）に示すように、このSIPトランザクションは、現在、SIP 200 OK応答を生成します。
Message 2:
メッセージ2：
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7; received=172.16.3.4 From: Bob <sip:bob@example.com>;tag=7F94778B653B To: Bob <sip:bob@example.com>;tag=6AF99445E44A Call-ID: 16CB75F21C70 CSeq: 1 REGISTER Supported: path, outbound Require: outbound Contact: <sip:bob@192.168.1.2 >;reg-id=1;expires=3600 ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" Content-Length: 0
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP 192.168.1.2; RPORT = 8050;ブランチ= z9hG4bKnashds7。受信= 172.16.3.4から：ボブ<SIP：bob@example.com>;タグ= 7F94778B653B：をボブ<SIP：bob@example.com>;タグ= 6AF99445E44Aコール-ID：16CB75F21C70のCSeq：1レジスタサポート：パス、アウトバウンド要求：アウトバウンドコンタクト：<SIP：bob@192.168.1.2>; REG-ID = 1; = 3600満了し; + sip.instance = "<URN：UUID：00000000-0000-1000-8000-AABBCCDDEEFF>" のContentを長さ：0
The response will be sent to the address appearing in the 'received' parameter of the SIP 'Via' header (address 172.16.3.4). The response will not be sent to the port deduced from the SIP 'Via' header, as per standard SIP operation but will be sent to the value that has been stamped in the 'rport' parameter of the SIP 'Via' header (port 8050). For the response to successfully traverse the NAT, all of the conventions defined in RFC 3581 [RFC3581] are to be obeyed. Make note of both the 'reg-id' and 'sip.instance' contact header parameters. They are used to establish an outbound connection tuple as defined in [RFC5626]. The connection tuple creation is clearly shown in Figure 5. This ensures that any inbound request that causes a registration lookup will result in the reuse of the connection path established by the registration. This removes the need to manipulate contact header URIs to represent a globally routable address as perceived on the public side of a NAT.
応答は、SIP「」を介してヘッダの「受信」パラメータ（アドレス172.16.3.4）に現れるアドレスに送信されます。反応は、標準的なSIP操作に従って、SIP「」を介してヘッダから推定ポートに送信されませんが、SIP「」を介してヘッダの「RPORT」パラメータ（ポート8050に刻印された値に送信されます）。応答が正常にNATを横断するためにRFC 3581 [RFC3581]で定義された規則のすべてが従わなければなりません。 「REG-ID」と「sip.instance」Contactヘッダパラメータの両方を書き留め。それらは[RFC5626]で定義されるようにアウトバウンド接続タプルを確立するために使用されます。接続タプルの作成は明らかこれは登録ルックアップを引き起こす任意の着信要求が登録によって確立された接続経路の再利用をもたらすであろうことを確実にする図5に示されています。これは、NATのパブリック側に知覚されるグローバルにルーティング可能なアドレスを表すために、コンタクトヘッダのURIを操作する必要がなくなります。
Registrar/
Bob NAT Edge Proxy
| | |
|(1) REGISTER | |
|----------------->| |
| | |
| |(1) REGISTER |
| |----------------->|
| | |
|*************************************|
| Create Outbound Connection Tuple |
|*************************************|
| | |
| |(2) 200 OK |
| |<-----------------|
| | |
|(2) 200 OK | |
|<-----------------| |
| | |
Figure 6
図6
Traversal of SIP REGISTER requests/responses using a reliable, connection-oriented protocol such as TCP does not require any additional core SIP signaling extensions, beyond the procedures defined in [RFC5626]. SIP responses will reuse the connection created for the initial REGISTER request, (1) from Figure 6:
TCPのような信頼性の高いコネクション型のプロトコルを使用してSIP REGISTERリクエスト/レスポンスのトラバーサルは、[RFC5626]で定義された手順を超え、拡張シグナリング追加のコアSIPを必要としません。 SIP応答は、図6（1）から、最初のREGISTERリクエスト用に作成された接続を再利用します。
Message 1:
メッセージ1：
REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sip:bob@example.com>;tag=7F94778B653B To: Bob <sip:bob@example.com> Call-ID: 16CB75F21C70 CSeq: 1 REGISTER Supported: path, outbound Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1 ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" Content-Length: 0
70：ボブ・ブランチ= z9hG4bKnashds7マックス・転送し、SIP / 2.0 / TCPの192.168.1.2：example.com SIP / 2.0経由：一口を登録<一口：bob@example.com>;タグ= 7F94778B653Bへ：ボブ<SIP： bob@example.com>コールID：16CB75F21C70のCSeq：1つのREGISTERサポート：パス、アウトバウンド連絡先：<SIP：bob@192.168.1.2;運輸= TCP>; REG-ID = 1; + sip.instance = "<壷：UUID：00000000-0000-1000-8000-AABBCCDDEEFF>」のContent-Length：0
Message 2:
メッセージ2：
SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 From: Bob <sip:bob@example.com>;tag=7F94778B653B To: Bob <sip:bob@example.com>;tag=6AF99445E44A Call-ID: 16CB75F21C70 CSeq: 1 REGISTER Supported: path, outbound Require: outbound Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600 ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" Content-Length: 0
SIP / 2.0 200 OK経由：SIP / 2.0 / TCPの192.168.1.2;ブランチ= z9hG4bKnashds7から：ボブ<SIP：bob@example.com>;タグ= 7F94778B653Bへ：ボブ<SIP：bob@example.com>;タグ= 6AF99445E44Aコール-ID：16CB75F21C70のCSeq：1つのREGISTERサポート：パス、アウトバウンドが必要：アウトバウンドコンタクトを：<SIP：bob@192.168.1.2;運輸= TCP>; REG-ID = 1; = 3600を満了し; + sip.instance =」 <URN：UUID：00000000-0000-1000-8000-AABBCCDDEEFF>」のContent-Length：0
This example was included to show the inclusion of the 'sip.instance' contact header parameter as defined in the SIP Outbound specification [RFC5626]. This creates an association tuple as described in the previous example for future inbound requests directed at the newly created registration binding with the only difference that the association is with a TCP connection, not a UDP pinhole binding.
この例では、SIPアウトバウンド仕様[RFC5626]で定義されるように「sip.instance」Contactヘッダパラメータを含むことを示すために含まれていました。これは、関連付けがTCP接続、結合しないUDPピンホールである唯一の違いと結合する新しく作成された登録に向け将来インバウンド要求のため、前の例で説明したように関連タプルを作成します。
This section demonstrates traversal mechanisms when the Registrar component is not co-located with the edge proxy element. The procedures described in this section are identical, regardless of transport protocol, so only one example will be documented in the form of TCP.
レジストラコンポーネントは、エッジプロキシ要素と同じ場所に配置されていない場合、このセクションでは、トラバース機構を示します。単なる一例では、TCPの形態に記載されるように、このセクションで説明する手順は、関係なく、トランスポートプロトコルの、同一です。
Bob NAT Edge Proxy Registrar
| | | |
|(1) REGISTER | | |
|----------------->| | |
| | | |
| |(1) REGISTER | |
| |----------------->| |
| | | |
| | |(2) REGISTER |
| | |----------------->|
| | | |
|*************************************| |
| Create Outbound Connection Tuple | |
|*************************************| |
| | | |
| | |(3) 200 OK |
| | |<-----------------|
| |(4)200 OK | |
| |<-----------------| |
| | | |
|(4)200 OK | | |
|<-----------------| | |
| | | |
Figure 7: Registration (Registrar/Proxy Not Co-Located)
図7：登録（レジストラ/プロキシすることはできません同じ場所に配置）
This scenario builds on the previous example in Section 5.1.1.2. The primary difference is that the REGISTER request is routed onwards from a proxy server to a separated Registrar. The important message to note is (1) in Figure 7. The edge proxy, on receiving a REGISTER request that contains a 'sip.instance' media feature tag, forms a unique flow identifier token as discussed in [RFC5626]. At this point, the proxy server routes the SIP REGISTER message to the Registrar. The proxy will create the connection tuple as described in SIP Outbound at the same moment as the co-located example, but for subsequent messages to arrive at the proxy, the proxy needs to indicate its need to remain in the SIP signaling path. To achieve this, the proxy inserts to REGISTER message (2) a SIP 'Path' extension header, as defined in RFC 3327 [RFC3327]. The previously created flow association token is inserted in a position within the Path header where it can easily be retrieved at a later point when receiving messages to be routed to the registration binding (in this case the user part of the SIP URI). The REGISTER message of (1) includes a SIP 'Route' header for the edge proxy.
このシナリオは、セクション5.1.1.2で、前の例に基づいています。主な違いは、REGISTERリクエストが分離レジストラにプロキシサーバから以降にルーティングされていることです。 [RFC5626]で説明したように、図7のエッジプロキシで注意すべき重要なメッセージ（1）は、「sip.instance」メディア特徴タグを含むレジスタリクエストを受信すると、一意のフロー識別子トークンを形成します。この時点で、プロキシサーバーのルートレジストラにSIP REGISTERメッセージ。共同設置例と同じ瞬間にSIPアウトバウンドで説明したように、プロキシは、接続タプルを作成しますが、後続のメッセージがプロキシに到達するために、プロキシは、SIPシグナリングパスに留まるため、その必要性を示す必要があります。これを達成するために、プロキシは、RFC 3327 [RFC3327]で定義されるように、（2）SIP「パス」拡張ヘッダメッセージを登録するために挿入します。以前に作成したフロー関連トークンは（この場合、SIP URIのユーザ部分に）バインディング登録にルーティングするメッセージを受信した場合、それが容易に後の時点で検索することができるPathヘッダ内の位置に挿入されます。 REGISTERメッセージは、（1）SIPエッジプロキシの「ルート」ヘッダを含みます。
Message 1:
メッセージ1：
REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sip:bob@example.com>;tag=7F94778B653B To: Bob <sip:bob@example.com> Call-ID: 16CB75F21C70 CSeq: 1 REGISTER Supported: path, outbound Route: <sip:ep1.example.com;lr> Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1 ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" Content-Length: 0
70：ボブ・ブランチ= z9hG4bKnashds7マックス・転送し、SIP / 2.0 / TCPの192.168.1.2：example.com SIP / 2.0経由：一口を登録<一口：bob@example.com>;タグ= 7F94778B653Bへ：ボブ<SIP： bob@example.com>コールID：16CB75F21C70のCSeq：1つのレジスタはサポートされている：パス、アウトバウンドルート：<SIP：ep1.example.com; LR>連絡先：<SIP：bob@192.168.1.2;運輸= TCP>; REG -id = 1; + sip.instance = "<URN：UUID：00000000-0000-1000-8000-AABBCCDDEEFF>" のContent-Length：0
When proxied in (2) looks as follows:
でプロキシする場合、以下のように（2）になります。
Message 2:
メッセージ2：
REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Max-Forwards: 69 From: Bob <sip:bob@example.com>;tag=7F94778B653B To: Bob <sip:bob@example.com> Call-ID: 16CB75F21C70 CSeq: 1 REGISTER Supported: path, outbound Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1 ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob> Content-Length: 0
example.com SIP / 2.0経由：SIP登録SIP / 2.0 / TCP ep1.example.com;ブランチ= z9hG4bKnuiqisi経由：SIP / 2.0 / TCPの192.168.1.2;ブランチ= z9hG4bKnashds7マックス・フォワード：ボブ<SIP：69： bob@example.com>;タグ= 7F94778B653Bへ：ボブ<SIP：bob@example.com>コール-IDを：16CB75F21C70のCSeq：1 REGISTERサポート：パス、アウトバウンド連絡先：<SIP：bob@192.168.1.2;輸送= TCP >; REG-ID = 1; + sip.instance = "<URN：UUID：00000000-0000-1000-8000-AABBCCDDEEFF>" パス：<SIP：VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com; LR; OB>コンテンツ-length：0
This REGISTER request results in the Path header being stored along with the AOR and its associated binding at the Registrar. The URI contained in the Path header will be inserted as a pre-loaded SIP 'Route' header into any request that arrives at the Registrar and is directed towards the associated AOR binding. This all but guarantees that all requests for the new registration will be forwarded to the edge proxy. In our example, the user part of the SIP 'Path' header URI that was inserted by the edge proxy contains the unique token identifying the flow to the client. On receiving subsequent requests, the edge proxy will examine the user part of the pre-loaded SIP 'Route' header and extract the unique flow token for use in its connection tuple comparison, as defined in the SIP Outbound specification [RFC5626]. An example that builds on this scenario (showing an inbound request to the AOR) is detailed in Section 5.1.4.2 of this document.
レジストラに結合AORとその関連と一緒に格納されているPathヘッダにおけるこのREGISTERリクエストをもたらします。 Pathヘッダに含まれるURIは、プリロードSIPレジストラに到着と結合関連AORに向けられているすべての要求への「ルート」ヘッダとして挿入されます。このすべてが、新規登録のためのすべての要求は、エッジプロキシに転送されることを保証します。この例では、エッジプロキシによって挿入されたSIP「パス」ヘッダURIのユーザ部分は、クライアントへの流れを識別する一意のトークンを含みます。後続の要求を受信すると、エッジプロキシは、プリロードSIP「ルート」ヘッダのユーザ部分を検討すると、SIPアウトバウンド仕様[RFC5626]で定義されるように、その接続タプルの比較において使用するためのユニークなフロートークンを抽出します。 （AORへの着信要求を示す）は、このシナリオに基づいて構築例は、この文書のセクション5.1.4.2に詳述されています。
This section covers basic SIP signaling when initiating a call from behind a NAT.
NATの後ろからのコールを開始するときに、このセクションでは、基本的なSIPシグナリングをカバーしています。
Initiating a call using UDP (the edge proxy and authoritative proxy functionality are co-located).
UDP（エッジプロキシと権限のプロキシ機能は同じ場所に配置されている）を使用してコールを開始します。
Edge Proxy/
Bob NAT Auth. Proxy Alice
| | | |
|(1) INVITE | | |
|----------------->| | |
| | | |
| |(1) INVITE | |
| |----------------->| |
| | | |
| | |(2) INVITE |
| | |---------------->|
| | | |
| | |(3)180 RINGING |
| | |<----------------|
| | | |
| |(4)180 RINGING | |
| |<-----------------| |
| | | |
|(4)180 RINGING | | |
|<-----------------| | |
| | | |
| | |(5)200 OK |
| | |<----------------|
| | | |
| |(6)200 OK | |
| |<-----------------| |
| | | |
|(6)200 OK | | |
|<-----------------| | |
| | | |
|(7)ACK | | |
|----------------->| | |
| | | |
| |(7)ACK | |
| |----------------->| |
| | | |
| | |(8) ACK |
| | |---------------->|
| | | |
Figure 8: Initiating a Session - UDP
図8：セッションの開始 - UDP
The initiating client generates an INVITE request that is to be sent through the NAT to a proxy server. The INVITE message is represented in Figure 8 by (1) and is as follows:
開始クライアントは、プロキシサーバにNATを介して送信されるINVITEリクエストを生成します。 INVITEメッセージは、（1）により、図8に示され、以下のようです。
Message 1:
メッセージ1：
INVITE sip:alice@a.example SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sip:bob@example.com>;tag=ldw22z To: Alice <sip:alice@a.example> Call-ID: 95KGsk2V/Eis9LcpBYy3 CSeq: 1 INVITE Supported: outbound Route: <sip:ep1.example.com;lr> Contact: <sip:bob@192.168.1.2;ob> Content-Type: application/sdp Content-Length: ...
SIPのINVITE：SIP / 2.0 / UDP 192.168.1.2; RPORT;ブランチ= z9hG4bKnashds7マックス・フォワード：SIP / 2.0を介してalice@a.example 70から：ボブ<SIP：bob@example.com>;タグ= ldw22zへ：アリス<SIP：alice@a.example>コール-IDを：95KGsk2V / Eis9LcpBYy3のCSeq：サポートされている1 INVITE：アウトバウンドルート：<SIP：ep1.example.com; LR>連絡先：<SIP：bob@192.168.1.2、OB>コンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：...
[SDP not shown]
[SDP示されていません]
There are a number of points to note with this message:
このメッセージに注意すべきポイントがいくつかあります：
1. Firstly, as with the registration example in Section 5.1.1.1, responses to this request will not automatically pass back through a NAT, so the SIP 'Via' header 'rport' is included as described in the Section 4.1.1 ("Symmetric Response") and defined in RFC 3581 [RFC3581].
まず1、セクション4.1.1（で説明したようにSIP「を介して」ヘッダ「RPORT」が」含まれているので、セクション5.1.1.1に登録例と同様に、この要求に対する応答を自動的に、NATを介して戻って通過しません対称応答」）およびRFC 3581 [RFC3581]で定義されています。
2. Secondly, the 'ob' parameter is added to the 'Contact' header to ensure that all subsequent requests are sent to the same flow; alternatively, a Globally Routable User Agent URI (GRUU) might have been used. See Section 4.3 of [RFC5626].
2.第二に、「OB」パラメータは、後続のすべての要求が同じフローに送信されることを保証するために、「連絡先」ヘッダに付加されます。代わりに、グローバルにルーティング可能なユーザエージェントURI（GRUU）が使用された可能性があります。 [RFC5626]のセクション4.3を参照してください。
In (2), the proxy inserts itself in the 'Via' header, adds the 'rport' port number and the 'received' parameter in the previous 'Via' header, removes the 'Route' header, and inserts a Record-Route with a token.
（2）において、プロキシが、「」を介してヘッダに自身を挿入する前「」を介してヘッダの「RPORT」ポート番号と「受信」パラメータを追加し、「ルート」ヘッダを削除し、レコードルートを挿入しますトークンを持ちます。
Message 2:
メッセージ2：
INVITE sip:alice@172.16.1.4 SIP/2.0 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7; received=172.16.3.4 Max-Forwards: 69 From: Bob <sip:bob@example.com>;tag=ldw22z To: Alice <sip:alice@a.example> Call-ID: 95KGsk2V/Eis9LcpBYy3 CSeq: 1 INVITE Supported: outbound Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr> Contact: <sip:bob@192.168.1.2;ob> Content-Type: application/sdp Content-Length: ...
INVITE SIP：alice@172.16.1.4のSIP / 2.0経由：SIP / 2.0 / UDP ep1.example.com;ブランチ= z9hG4bKnuiqisi経由：SIP / 2.0 / UDP 192.168.1.2; RPORT = 8050;ブランチ= z9hG4bKnashds7。 = 172.16.3.4マックス・フォワードを受け取っ：69から：ボブ<SIP：bob@example.com>;タグ= ldw22zへ：アリス<SIP：alice@a.example>コールID：95KGsk2V / Eis9LcpBYy3のCSeqは：サポートされている1 INVITE ：アウトバウンド録音-ルート：<SIP：3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com; LR>連絡先：<SIP：bob@192.168.1.2; OB>のContent-Type：アプリケーション/ SDPコンテンツの長さ：...
[SDP not shown]
[SDP示されていません]
When using a reliable transport such as TCP, the call flow and procedures for traversing a NAT are almost identical to those described in Section 5.1.3.1. The primary difference when using reliable transport protocols is that symmetric response [RFC3581] is not required for SIP responses to traverse a NAT. RFC 3261 [RFC3261] defines procedures for SIP response messages to be sent back on the same connection on which the request arrived. See Section 9.5 of [RFC5626] for an example flow of an outgoing call.
TCPのような信頼性の高いトランスポートを使用する場合は、NATを通過するためのコールフローと手順は、セクション5.1.3.1で説明したものとほぼ同じです。信頼性の高いトランスポートプロトコルを使用して、主な違いは、SIP応答がNATをトラバースするための対称応答[RFC3581]必要とされないことです。 RFC 3261 [RFC3261]は、要求が到着した同じ接続で返送するSIP応答メッセージのための手順を定義します。発信通話の流れの一例のために[RFC5626]の9.5節を参照してください。
This section details scenarios where a client behind a NAT receives an inbound request through a NAT. These scenarios build on the previous registration scenario from Sections 5.1.1 and 5.1.2 in this document.
このセクションでは、NATの背後にあるクライアントがNAT経由の着信要求を受信したシナリオの詳細を示します。これらのシナリオは、このドキュメントのセクション5.1.1と5.1.2から以前の登録シナリオに構築します。
The SIP signaling on the interior of the network (behind the user's proxy) is not impacted directly by the transport protocol, so only one example scenario is necessary. The example uses UDP and follows on from the registration installed in the example from Section 5.1.1.1.
（ユーザのプロキシの背後にある）ネットワークの内部にSIPシグナリングは、トランスポート・プロトコルによって直接影響を受けないので、あくまで一例のシナリオが必要です。例では、UDPを使用して、セクション5.1.1.1からの例ではインストールされ、登録に続くもの。
Edge Proxy
Bob NAT Auth. Proxy Alice
| | | |
|*******************************************************|
| Registration Binding Installed in |
| Section 5.1.1.1 |
|*******************************************************|
| | | |
| | |(1)INVITE |
| | |<----------------|
| | | |
| |(2)INVITE | |
| |<-----------------| |
| | | |
|(2)INVITE | | |
|<-----------------| | |
| | | |
| | | |
Figure 9: Receiving an Invitation to a Session
図9：セッションへの招待を受けます
An INVITE request arrives at the authoritative proxy with a destination pointing to the AOR of that inserted in Section 5.1.1.1. The message is illustrated by (1) in Figure 9 and looks as follows:
INVITE要求は、セクション5.1.1.1に挿入されたそのAORに対する宛先ポインティング権威プロキシに到達します。メッセージは、図9の（1）によって示されており、次のように見えています。
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Max-Forwards: 70 From: External Alice <sip:alice@example.com>;tag=02935 To: Bob <sip:bob@example.com> Call-ID: klmvCxVWGp6MxJp2T2mb CSeq: 1 INVITE Contact: <sip:alice@172.16.1.4> Content-Type: application/sdp Content-Length: ..
SIPのINVITE：bob@example.com SIP / 2.0経由：SIP / 2.0 / UDP 172.16.1.4;ブランチ= z9hG4bK74huHJ37dマックス・フォワード：から70：外部アリス<一口：alice@example.com>;タグ= 02935へ：ボブ<一口：bob@example.com>コール-IDを：klmvCxVWGp6MxJp2T2mbのCSeq：1連絡先をINVITE：<SIP：alice@172.16.1.4>のContent-Type：アプリケーション/ SDPコンテンツ長..
[SDP not shown]
[SDP示されていません]
The INVITE request matches the registration binding previously installed at the Registrar and the INVITE Request-URI is rewritten to the selected onward address. The proxy then examines the Request-URI of the INVITE and compares with its list of connection tuples. It uses the incoming AOR to commence the check for associated open connections/mappings. Once matched, the proxy checks to see if the unique instance identifier (+sip.instance) associated with the binding equals the same instance identifier associated with that connection tuple. The request is then dispatched on the appropriate binding. This is message (2) from Figure 9 and is as follows:
INVITE要求は、登録先にレジストラに設置結合し、INVITEのRequest-URIを選択以降のアドレスに書き換えられると一致します。プロキシは、INVITEの要求URIを調べ、接続タプルのリストと比較します。これは、関連するオープン接続/マッピングのチェックを開始するために、着信AORを使用しています。一度結合に関連付けられた一意のインスタンスID（+ sip.instance）はその接続タプルに関連付けられている同じインスタンス識別子に等しいかどうかを確認するために、プロキシチェックを一致。要求は、適切な結合に送出されます。これは、図9からのメッセージ（2）であり、以下の通りであります：
INVITE sip:bob@192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Max-Forwards: 69 From: Alice <sip:alice@example.com>;tag=02935 To: client bob <sip:bob@example.com> Call-ID: klmvCxVWGp6MxJp2T2mb CSeq: 1 INVITE Contact: <sip:alice@172.16.1.4> Content-Type: application/sdp Content-Length: ..
INVITE SIP：bob@192.168.1.2のSIP / 2.0経由：SIP / 2.0 / UDP ep1.example.com;ブランチ= z9hG4kmlds893jhsd経由：SIP / 2.0 / UDP 172.16.1.4;ブランチ= z9hG4bK74huHJ37dマックス・フォワード：69：アリス< SIP：alice@example.com>;タグ= 02935へ：クライアントボブ<SIP：bob@example.com>コールID：klmvCxVWGp6MxJp2T2mbのCSeq：1連絡先をINVITE：<SIP：alice@172.16.1.4>のContent-Type：アプリケーション/ SDPのContent-Length ..
[SDP not shown]
[SDP示されていません]
It is a standard SIP INVITE request with no additional functionality. The major difference is that this request will not be forwarded to the address specified in the Request-URI, as standard SIP rules would enforce, but will be sent on the flow associated with the registration binding (lookup procedures in RFC 3263 [RFC3263] are overridden by RFC 5626 [RFC5626]). This then allows the original connection/mapping from the initial registration process to be reused.
これは、付加的な機能を持たないINVITEリクエストを標準のSIPです。主な違いは、この要求は、標準SIP規則が施行になるように、リクエストURIで指定されたアドレスに転送されませんが、登録されているRFC 3263 [RFC3263]に（結合ルックアッププロシージャに関連付けられたフローに送信されることですRFC 5626 [RFC5626]）によって上書き。これは、初期登録プロセスからの元の接続/マッピングを再利用することを可能にします。
The core SIP signaling associated with this call flow is not impacted directly by the transport protocol, so only one example scenario is necessary. The example uses UDP and follows on from the registration installed in the example from Section 5.1.2.
このコール・フローに関連付けられたコアSIPシグナリングは、トランスポートプロトコルによって直接影響を受けないので、あくまで一例のシナリオが必要です。例では、UDPを使用して、セクション5.1.2からの例ではインストールされ、登録に続くもの。
Bob NAT Edge Proxy Auth. Proxy Alice
| | | | |
|***********************************************************|
| Registration Binding Installed in |
| Section 5.1.2 |
|***********************************************************|
| | | | |
| | | |(1)INVITE |
| | | |<-------------|
| | | | |
| | |(2)INVITE | |
| | |<-------------| |
| | | | |
| |(3)INVITE | | |
| |<-------------| | |
| | | | |
|(3)INVITE | | | |
|<-------------| | | |
| | | | |
| | | | |
Figure 10: Registrar/Proxy Not Co-located
図10：レジストラ/プロキシのない共同設置
An INVITE request arrives at the authoritative proxy with a destination pointing to the AOR of that inserted in Section 5.1.2. The message is illustrated by (1) in Figure 10 and looks as follows:
INVITE要求は、セクション5.1.2に挿入されたそのAORに対する宛先ポインティング権威プロキシに到達します。メッセージは、図10の（1）によって示されており、次のように見えています。
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Max-Forwards: 70 From: Alice <sip:alice@example.com>;tag=02935 To: Bob <sip:bob@example.com> Call-ID: klmvCxVWGp6MxJp2T2mb CSeq: 1 INVITE Contact: <sip:external@172.16.1.4> Content-Type: application/sdp Content-Length: ..
SIPのINVITE：bob@example.com SIP / 2.0経由：SIP / 2.0 / UDP 172.16.1.4;ブランチ= z9hG4bK74huHJ37dマックス・フォワード：から70：アリス<SIP：alice@example.com>;タグ= 02935へ：ボブ< SIP：bob@example.com>コールID：klmvCxVWGp6MxJp2T2mbのCSeq：1連絡先をINVITE：<SIP：external@172.16.1.4>のContent-Type：アプリケーション/ SDPコンテンツ長..
[SDP not shown]
[SDP示されていません]
The INVITE request matches the registration binding previously installed at the Registrar and the INVITE Request-URI is rewritten to the selected onward address. The Registrar also identifies that a SIP 'Path' header was associated with the registration and pushes it into the INVITE request in the form of a pre-loaded SIP Route header. It then forwards the request on to the proxy identified in the SIP Route header as shown in (2) from Figure 10:
INVITE要求は、登録先にレジストラに設置結合し、INVITEのRequest-URIを選択以降のアドレスに書き換えられると一致します。レジストラはまた、SIP「パス」ヘッダは、登録と関連していたことを識別し、事前ロードされたSIPルートヘッダの形でINVITE要求にそれを押し込みます。次に、図10の（2）に示すように、SIPルートヘッダで識別されたプロキシ上に要求を転送します。
INVITE sip:bob@client.example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob> Max-Forwards: 69 From: Alice <sip:alice@example.net>;tag=02935 To: Bob <sip:Bob@example.com> Call-ID: klmvCxVWGp6MxJp2T2mb CSeq: 1 INVITE Contact: <sip:alice@172.16.1.4> Content-Type: application/sdp Content-Length: ..
SIPのINVITE：SIP / 2.0 / UDP proxy.example.com;ブランチ= z9hG4bK74fmljnc経由：bob@client.example.com SIP / 2.0を介してSIP / 2.0 / UDP 172.16.1.4;ブランチ= z9hG4bK74huHJ37dルート：<SIP：VskztcQ / S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com; LR; OB>マックス・フォワード：69から：アリス<SIP：alice@example.net>;タグ= 02935へ：ボブ<SIP：Bob@example.com>コール-IDを：klmvCxVWGp6MxJp2T2mb CSeq：1連絡先をINVITE：<SIP：alice@172.16.1.4>のContent-Type：アプリケーション/ SDPコンテンツ長..
[SDP not shown]
[SDP示されていません]
The request then arrives at the outbound proxy for the client. The proxy examines the Request-URI of the INVITE in conjunction with the flow token that it previously inserted into the user part of the 'Path' header SIP URI (which now appears in the user part of the Route header in the incoming INVITE). The proxy locates the appropriate flow and sends the message to the client, as shown in (3) from Figure 10:
要求は、クライアントのためのアウトバウンドプロキシに到着します。プロキシは、それが以前に（今INVITE着信でRouteヘッダのユーザ部分に表示される）「パス」ヘッダのSIP URIのユーザ部分に挿入され、そのフロー・トークンに関連して、INVITEのリクエストURIを検査します。プロキシは、適切なフローを検索し、図10の（3）に示すように、クライアントにメッセージを送信します。
INVITE sip:bob@192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Record-Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr> Max-Forwards: 68 From: Alice <sip:Alice@example.net>;tag=02935 To: bob <sip:bob@example.com> Call-ID: klmvCxVWGp6MxJp2T2mb CSeq: 1 INVITE Contact: <sip:alice@172.16.1.4> Content-Type: application/sdp Content-Length: ..
INVITE SIP：bob@192.168.1.2のSIP / 2.0経由：SIP / 2.0 / UDP ep1.example.com;ブランチ= z9hG4nsi30dncmnl経由：SIP / 2.0 / UDP proxy.example.com;ブランチ= z9hG4bK74fmljnc経由：SIP / 2.0 / UDP 172.16.1.4;分岐= z9hG4bK74huHJ37dレコードルート<SIP：VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com; LR>最大フォワード：68から：アリス<SIP：Alice@example.net>;タグ= 02935：をボブ<一口：bob@example.com>コール-IDを：klmvCxVWGp6MxJp2T2mbのCSeq：1連絡先をINVITE：<SIP：alice@172.16.1.4>のContent-Type：アプリケーション/ SDPコンテンツ長..
[SDP not shown]
[SDP示されていません]
It is a standard SIP INVITE request with no additional functionality at the originator. The major difference is that this request will not follow the address specified in the Request-URI when it reaches the outbound proxy, as standard SIP rules would enforce, but will be sent on the flow associated with the registration binding as indicated in the Route header (lookup procedures in RFC 3263 [RFC3263] are overridden). This then allows the original connection/ mapping from the initial registration to the outbound proxy to be reused.
これは、発信元の付加的な機能を持たないINVITEリクエストを標準のSIPです。主な違いは、この要求が要求URI標準SIP規則が施行になるように、それは、アウトバウンドプロキシに到達するで指定されたアドレスに従わないことであるが、ルートヘッダに示されているようにバインディング登録に関連付けられたフロー上で送信されます（RFC 3263 [RFC3263]でルックアップ手順は、オーバーライドさ）。これは、アウトバウンドプロキシに初期登録から元の接続/マッピングを再利用することを可能にします。
This section provides example scenarios to demonstrate basic media traversal using the techniques outlined earlier in this document.
このセクションでは、このドキュメントで概説技術を使用して、基本的なメディアトラバーサルを実証する例のシナリオが用意されています。
In the flow diagrams, STUN messages have been annotated for simplicity as follows:
次のようにフロー図では、STUNメッセージを簡単にするために注釈を付けされています：
o The "Src" attribute represents the source transport address of the message.
O「SRC」属性は、メッセージの送信元トランスポートアドレスを表します。
o The "Dest" attribute represents the destination transport address of the message.
O「Destは」属性は、メッセージの宛先トランスポートアドレスを表します。
o The "Map" attribute represents the server reflexive (XOR-MAPPED-ADDRESS STUN attribute) transport address.
"マップ" 属性O再帰サーバー（XOR-MAPPED-ADDRESSのSTUN属性）トランスポートアドレスを表します。
o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN attribute) transport address.
O「のRel」属性は、中継（リレーアドレスSTUN属性）トランスポートアドレスを表します。
The meaning of each STUN attribute is extensively explained in the core STUN [RFC5389] and TURN [RFC5766] specifications.
各STUN属性の意味は広く、コアSTUN [RFC5389]で説明した[RFC5766]の仕様を回しています。
A number of ICE SDP attributes have also been included in some of the examples. Detailed information on individual attributes can be obtained from the core ICE specification [RFC5245].
ICEのSDP属性の数も例の一部に含まれています。個々の属性に関する詳細情報は、コアICE仕様[RFC5245]から得ることができます。
The examples also contain a mechanism for representing transport addresses. It would be confusing to include representations of network addresses in the call flows and would make them hard to follow. For this reason, network addresses will be represented using the following annotation. The first component will contain the representation of the client responsible for the address. For example, in the majority of the examples "L" (left client), "R" (right client), "NAT-PUB" (NAT public), "PRIV" (Private), and "STUN-PUB" (STUN public) are used. To allow for multiple addresses from the same network element, each representation can also be followed by a number. These can also be used in combination. For example, "L-NAT-PUB-1" would represent a public network address of the left-hand side NAT while "R-NAT-PUB-1" would represent a public network address of the right-hand side of the NAT. "L-PRIV-1" would represent a private network address of the left-hand side of the NAT while "R-PRIV-1" represents a private address of the right-hand side of the NAT.
実施例はまた、トランスポート・アドレスを表すための機構を含みます。コールフロー内のネットワークアドレスの表現を含むように混乱するだろうとフォローするためにそれらが困難になるだろう。このため、ネットワークアドレスは以下の注釈を使用して表現されます。最初のコンポーネントは、アドレスを担当するクライアントの表現が含まれています。例えば、例 "L"（左クライアント）の大部分において、 "R"（右クライアント）、 "NAT-PUB"（NATパブリック）、（プライベート） "PRIV"、および "STUN-PUB"（STUNパブリック）が使用されています。同じネットワークエレメントから複数のアドレスを可能にするために、各表現はまた、数字が続くことができます。これらを組み合わせて使用することもできます。例えば、「L-NAT-PUB-1」「R-NAT-PUB-1」は、NATの右側のパブリックネットワークアドレスを表すことになるながら左側NATのパブリックネットワークアドレスを表すであろう。 「R-PRIV-1」は、NATの右側のプライベートアドレスを表す「L-PRIV-1」は、NATの左側のプライベートネットワークアドレスを表すことになります。
It should also be noted that, during the examples, it might be appropriate to signify an explicit part of a transport address. This is achieved by adding either the '.address' or '.port' tag on the end of the representation -- for example, 'L-PRIV-1.address' and 'L-PRIV-1.port'.
また、例の間に、トランスポートアドレスの明示的な部分を意味することが適切であるかもしれないことに留意すべきです。例えば、 『L-PRIV-滞在先住所』と 『L-PRIV-1.port』 - これは「.address'または」.port」タグ表現の末尾のいずれかを添加することによって達成されます。
The use of '$' signifies variable parts in example SIP messages.
「$」の使用は、例えば、SIPメッセージ内の変数部分を意味します。
This section demonstrates an example of a client both initiating and receiving calls behind an Endpoint-Independent NAT. An example is included for both STUN and ICE with ICE being the RECOMMENDED mechanism for media traversal.
このセクションでは、開始とエンドポイントに依存しないNATの背後に呼び出しを受け、両方のクライアントの例を示しています。例は、ICEは、メディアトラバーサルのための推奨メカニズムであるとSTUN及びICEの両方に含まれています。
At this time, there is no reliable test to determine if a host is behind an Endpoint-Independent Filtering NAT or an Endpoint-Independent Mapping NAT [RFC5780], and the sort of failure that occurs in this situation is described in Section 5.2.2.1. For this reason, ICE is RECOMMENDED over the mechanism described in this section.
このとき、5.2.2.1項に記載されている。このような状況で発生したホストがエンドポイントに依存しないフィルタリングNATまたはエンドポイント非依存マッピングNAT [RFC5780]の後ろにあるかどうかを判断するために信頼できるテスト、障害の一種ではありません。このため、ICEは、このセクションで説明するメカニズムの上に推奨されます。
It is possible to traverse media through an Endpoint-Independent NAT using STUN. The remainder of this section provides simplified examples of the 'Binding Discovery' STUN as defined in [RFC5389]. The STUN messages have been simplified and do not include 'Shared Secret' requests used to obtain the temporary username and password.
STUNを使用してエンドポイントに依存しないNAT経由のメディアを横断することも可能です。このセクションの残りの部分では[RFC5389]で定義されるように「バインドディスカバリー」STUNの簡略化された例を提供します。 STUNメッセージが簡素化されていると、一時的なユーザ名とパスワードを取得するために使用される「共有秘密の要求が含まれていません。
The following example demonstrates media traversal through a NAT with Endpoint-Independent Mapping properties using the STUN 'Binding Discovery' usage. It is assumed in this example that the STUN client and SIP Client are co-located on the same physical machine. Note that some SIP signaling messages have been left out for simplicity.
次の例では、使用者らの発見バインディング」をSTUNを使用して、エンドポイント非依存性マッピングプロパティを持つNATを介してメディアトラバーサルを示しています。これは、STUNクライアントとSIPクライアントが同じ物理マシン上に共存していることを、この例で想定されます。いくつかのSIPシグナリングメッセージを簡単にするために取り残されていることに注意してください。
Client NAT STUN [..]
Server
| | | |
|(1) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(2) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(3) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5) BIND Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(6) BIND Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(7) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(8) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
|(9)SIP INVITE | | |
|----------------->| | |
| | | |
| |(10)SIP INVITE | |
| |------------------------------------>|
| | | |
| | |(11)SIP 200 OK |
| |<------------------------------------|
| | | |
|(12)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================|
| |
|========================================================|
|<<<<<<<<<<<<Incoming Media sent to NAT-PUB-1<<<<<<<<<<<<|
|========================================================|
| |
|========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================|
| |
|========================================================|
|<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<|
|========================================================|
| | | |
|(13)SIP ACK | | |
|----------------->| | |
| | | |
| |(14) SIP ACK | |
| |------------------------------------>|
| | | |
Figure 11: Endpoint-Independent NAT - Initiating
図11：エンドポイントに依存しないNAT - 開始
o On deciding to initiate a SIP voice session, the client starts a local STUN client on the interface and port that is to be used for media (send/receive). The STUN client generates a standard 'Binding Discovery' request as indicated in (1) from Figure 11 that also highlights the source address and port for which the client device wishes to obtain a mapping. The 'Binding Discovery' request is sent through the NAT towards the public Internet and STUN server.
O SIP音声セッションを開始することを決定する上で、クライアントは、（受信/送信）のメディアに使用するインターフェイスとポートのローカルSTUNクライアントを起動します。 STUNクライアントは、クライアントデバイスは、マッピングを取得することを望むのソースアドレスとポートを強調表示し、図11の（1）に示されるように、要求者らの発見バインディング」を標準を生成します。 「バインディングディスカバリーの要求は、公共のインターネットとSTUNサーバーへのNATを介して送信されます。
o Message (2) traverses the NAT and breaks out onto the public Internet towards the public STUN server. Note that the source address of the 'Binding Discovery' request now represents the public address and port from the public side of the NAT.
Oメッセージは、（2）NATを横断し、パブリックSTUNサーバーへのパブリックインターネット上に勃発します。 「バインディングディスカバリーの要求の送信元アドレスは現在NATのパブリック側からパブリックアドレスとポートを表していることに注意してください。
o The STUN server receives the request and processes it appropriately. This results in a successful 'Binding Discovery' response being generated and returned (3). The message contains details of the XOR-mapped public address (contained in the STUN XOR-MAPPED-ADDRESS attribute) that is to be used by the originating client to receive media (see 'Map=NAT-PUB-1' from (3)).
O STUNサーバは要求を受信し、適切に処理します。これは、生成され、（3）返される応答者らの発見バインディング」を成功になります。メッセージは、（（3から「地図= NAT-PUB-1」を参照）メディアを受信するために元のクライアントによって使用されることになる（STUN XOR-MAPPED-ADDRESS属性に含まれる）XORマッピングされたパブリックアドレスの詳細が含まれています）。
o The 'Binding Discovery' response traverses back through the NAT using the path created by the 'Binding Discovery' request and presents the new XOR-mapped address to the client (4). At this point, the process is repeated to obtain a second XOR-mapped address (as shown in (5)-(8)) for a second local address (the address has changed from "L-PRIV-1" to "L-PRIV-2") for an RTCP port.
O「バインディングディスカバリー」応答は「バインディングディスカバリーの要求によって作成されたパスを使用してNATを通じてバック横断し、クライアント（4）への新たなXOR-マッピングされたアドレスを提示します。第二のローカルアドレス（アドレスが「L-PRIV-1」〜「L-から変更された - この時点で、プロセスは、（（8）（5）に示されるように）第二のXORマッピングされたアドレスを取得するために繰り返されますRTCPポートのPRIV-2" ）。
o The client now constructs a SIP INVITE message (9). Note that traversal of SIP is not covered in this example and is discussed in Section 5.1. The INVITE request will use the addresses it has obtained in the previous STUN transactions to populate the SDP of the SIP INVITE as shown below:
OクライアントはSIPメッセージ（9）INVITE構築します。 SIPのトラバーサルは、この例ではカバーされていない、セクション5.1で議論されていることに留意されたいです。 INVITE要求は、以下に示すように、SIPのSDPは、INVITEを移入することが以前STUNトランザクションで得られたアドレスを使用します。
v=0 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address c=IN IP4 $NAT-PUB-1.address t=0 0 m=audio $NAT-PUB-1.port RTP/AVP 0 a=rtcp:$NAT-PUB-2.port
IP4 $ NAT-PUB-滞在先住所のT = 0、M = $オーディオのNAT-PUB-1.port RTP / AVP 0 A IN IP4する$ L-PRIV-滞在先住所cでV = 0 0 =試験2890844526 2890842807 = = RTCP：$ NAT-PUB-2.port
o Note that the XOR-mapped address obtained from the 'Binding Discovery' transactions are inserted as the connection address for the SDP (c=$NAT-PUB-1.address). The Primary port for RTP is also inserted in the SDP (m=audio $NAT-PUB-1.port RTP/AVP 0). Finally, the port gained from the additional 'Binding Discovery' is placed in the RTCP attribute (as discussed in Section 4.2.2) for traversal of RTCP (a=rtcp:$NAT-PUB-2.port).
O「結合ディスカバリー」取引から得られたXORマッピングされたアドレスは、SDP（C = $ NAT-PUB-滞在先住所）の接続アドレスとして挿入されることに留意されたいです。 RTPのためのプライマリポートはまた、SDP（M =オーディオ$のNAT-PUB-1.port RTP / AVP 0）に挿入されます。最後に、ポートが追加された「バインディングディスカバリー」がRTCPのトラバーサルのためのRTCP属性（セクション4.2.2で説明したように）（：$ NAT-PUB-2.port = RTCP）に配置されてから得られました。
o The SIP signaling then traverses the NAT and sets up the SIP session (9-12). Note that the left-hand client transmits media as soon as the 200 OK to the INVITE arrives at the client (12). Up until this point, the incoming media and RTCP to the left-hand client will not pass through the NAT as no outbound association has been created with the far-end client. Two-way media communication has now been established.
O次いでSIPシグナリングは、NATを横断し、SIPセッション（9-12）を設定します。左側のクライアントは、すぐにINVITEに対するOK 200などのメディアを送信し、クライアント（12）に到着することに注意してください。何のアウトバウンドアソシエーションが遠端のクライアントを使用して作成されていないとして、この時点までは、左側のクライアントへの着信メディアとRTCPは、NATを通過しません。双方向メディア通信は現在確立されています。
Receiving a session for an Endpoint-Independent NAT using the STUN 'Binding Discovery' usage is very similar to the example outlined in Section 5.2.1.1.1. Figure 12 illustrates the associated flow of messages.
用法「ディスカバリーバインディング」をSTUNを使用してエンドポイントに依存しないNATのためのセッションを受信すると、セクション5.2.1.1.1に概説された例と非常に似ています。図12は、メッセージの関連するフローを示す図です。
Client NAT STUN [..]
Server
| | | (1)SIP INVITE |
| |<------------------------------------|
| | | |
|(2) SIP INVITE | | |
|<-----------------| | |
| | | |
|(3) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(4) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(5) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(6) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(7) BIND Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(8) BIND Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(9) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(10) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
|(11)SIP 200 OK | | |
|----------------->| | |
| |(12)SIP 200 OK | |
| |------------------------------------>|
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================|
| | | |
|========================================================|
|<<<<<<<<<<<<<Incoming Media sent to L-PRIV-1<<<<<<<<<<<<|
|========================================================|
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================|
| | | |
|========================================================|
|<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<|
|========================================================|
| | | |
| | |(13)SIP ACK |
| |<------------------------------------|
| | | |
|(14)SIP ACK | | |
|<-----------------| | |
| | | |
Figure 12: Endpoint-Independent NAT - Receiving
図12：エンドポイントに依存しないNAT - 受信
o On receiving an invitation to a SIP voice session (SIP INVITE request), the User Agent starts a local STUN client on the appropriate port on which it is to receive media. The STUN client generates a standard 'Binding Discovery' request as indicated in (3) from Figure 12 that also highlights the source address and port for which the client device wishes to obtain a mapping. The 'Binding Discovery' request is sent through the NAT towards the public Internet and STUN server.
O（SIP INVITE要求）SIP音声セッションへの招待を受信すると、ユーザエージェントは、それがメディアを受信するためにされている適切なポート上のローカルSTUNクライアントを起動します。 STUNクライアントは、クライアントデバイスは、マッピングを取得することを望むのソースアドレスとポートを強調表示し、図12の（3）に示すように、要求者らの発見バインディング」を標準を生成します。 「バインディングディスカバリーの要求は、公共のインターネットとSTUNサーバーへのNATを介して送信されます。
o 'Binding Discovery' message (4) traverses the NAT and breaks out onto the public Internet towards the public STUN server. Note that the source address of the STUN requests now represents the public address and port from the public side of the NAT.
メッセージ「ディスカバリーバインディングの」O（4）NATを通過し、パブリックSTUNサーバーへのパブリックインターネット上に勃発。 STUN要求の送信元アドレスは現在NATのパブリック側からパブリックアドレスとポートを表していることに注意してください。
o The STUN server receives the request and processes it appropriately. This results in a successful 'Binding Discovery' response being generated and returned (5). The message contains details of the mapped public address (contained in the STUN XOR-MAPPED-ADDRESS attribute) that is to be used by the originating client to receive media (see 'Map=NAT-PUB-1' from (5)).
O STUNサーバは要求を受信し、適切に処理します。これは、応答生成および（5）返される「ディスカバリー結合」が成功になります。メッセージは、メディアを（（5）から「地図= NAT-PUB-1」を参照）を受信するように元のクライアントによって使用されることになる（STUN XOR-MAPPED-ADDRESS属性に含まれる）マッピングされたパブリックアドレスの詳細が含まれています。
o The 'Binding Discovery' response traverses back through the NAT using the path created by the outgoing 'Binding Discovery' request and presents the new XOR-mapped address to the client (6). At this point, the process is repeated to obtain a second XOR-mapped address (as shown in (7)-(10)) for a second local address (local port has now changed and is represented by L-PRIV-2 in (7)) for an RTCP port.
O「バインディングディスカバリー」応答が要求「ディスカバリーバインディング」を送信することによって作成されたパスを使用してNATを通じてバック横断し、クライアント（6）への新たなXOR-マッピングされたアドレスを提示します。この時点で、プロセスは、第二のXORマッピングされたアドレスを取得するために繰り返される（に示すように、（7） - （10））は、第2のローカルアドレス用の（ローカルポートにL-PRIV-2によって今変化したと表されています（ 7））RTCPポートの。
o The client now constructs a SIP 200 OK message (11) in response to the original SIP INVITE requests. Note that traversal of SIP is not covered in this example and is discussed in Section 5.1. SIP Provisional responses are also left out for simplicity. The 200 OK response will use the addresses it has obtained in the previous STUN transactions to populate the SDP of the SIP 200 OK as shown below:
OクライアントはINVITE要求元SIPに応答してSIP 200 OKメッセージ（11）を構成します。 SIPのトラバーサルは、この例ではカバーされていない、セクション5.1で議論されていることに留意されたいです。 SIP暫定応答はまた、簡単のために省略されています。 200 OK応答は、以下に示すように、SIP 200 OKのSDPを移入することが以前STUNトランザクションで得られたアドレスを使用します。
v=0 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address c=IN IP4 $NAT-PUB-1.address t=0 0 m=audio $NAT-PUB-1.port RTP/AVP 0 a=rtcp:$NAT-PUB-2.port
IP4 $ NAT-PUB-滞在先住所のT = 0、M = $オーディオのNAT-PUB-1.port RTP / AVP 0 A IN IP4する$ L-PRIV-滞在先住所cでV = 0 0 =試験2890844526 2890842807 = = RTCP：$ NAT-PUB-2.port
o Note that the XOR-mapped address obtained from the initial 'Binding Discovery' transaction is inserted as the connection address for the SDP (c=NAT-PUB-1.address). The Primary port for RTP is also inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP
Oトランザクション「ディスカバリーバインディング」を最初から得られたXORマッピングされたアドレスは、SDPの接続アドレス（C = NAT-PUB-滞在先住所）として挿入されることに注意してください。 RTPのプライマリポートは、SDP（M =オーディオNAT-PUB-1.port RTP / AVPに挿入されています
0). Finally, the port gained from the second 'Binding Discovery' is placed in the RTCP attribute (as discussed in Section 4.2.2) for traversal of RTCP (a=rtcp:NAT-PUB-2.port).
0）。最後に、ポートは、第「結合ディスカバリー」はRTCPのトラバーサルのためのRTCP属性（セクション4.2.2で説明したように）（：NAT-PUB-2.port = RTCP）に配置されているから得られます。
o The SIP signaling then traverses the NAT and sets up the SIP session (11-14). Note that the left-hand client transmits media as soon as the 200 OK to the INVITE is sent to the User Agent Client (UAC) (11). Up until this point, the incoming media from the right-hand client will not pass through the NAT as no outbound association has been created with the far-end client. Two-way media communication has now been established.
O次いでSIPシグナリングは、NATを横断し、SIPセッション（11-14）を設定します。 （11）左側のクライアントは、すぐにINVITEに対するOK 200は、ユーザエージェントクライアント（UAC）に送信されるように、メディアを送信することに注意してください。何のアウトバウンドアソシエーションが遠端のクライアントを使用して作成されていないとして、この時点までは、右のクライアントからの着信メディアがNATを通過しません。双方向メディア通信は現在確立されています。
The preferred solution for media traversal of NAT is using ICE, as described in Section 4.2.3.3, regardless of the NAT type. The following examples illustrate the traversal of an Endpoint-Independent NAT when initiating the session. The example only covers ICE in association with the 'Binding Discovery' and TURN. It is worth noting that the TURN server provides both STUN functions (to learn your public mapping) and TURN functions (media relaying). It is also worth noting that in the example described in Section 5.2.1.2.1, both SIP clients L and R are contacting the same TURN server. This is not necessary for ICE, STUN, TURN to function; all that is necessary is that the STUN and TURN server(s) be in the same addressing domain that is accessible on the Internet.
かかわらず、NATタイプの、セクション4.2.3.3に記載されるようにNATのメディアトラバーサルのための好ましい溶液は、ICEを使用しています。セッションを開始するときは、次の例は、エンドポイントに依存しないNATのトラバーサルを説明します。例では、唯一の「バインディングディスカバリー」とTURNに関連してICEをカバーしています。 （あなたの公開マッピングを学習する）と（メディア中継を）機能をオンにTURNサーバーは、両方のSTUN機能を提供していることは注目に値します。それはまた、セクション5.2.1.2.1に記載された例において、SIPクライアントのLとRの両方が同じTURNサーバに接触していることは注目に値します。これはICE、STUN、TURN機能には必要ありません。すべてのことは、STUNやTURNサーバー（s）は、インターネット上でアクセス可能である同じアドレッシングドメイン内にあることである必要があります。
The following example demonstrates an initiating traversal through an Endpoint-Independent NAT using ICE.
次の例では、ICEを使用してエンドポイントに依存しないNAT経由開始トラバーサルを示しています。
L NAT STUN NAT R
Server
| | | | |
|(1) Alloc Req | | | |
|Src=L-PRIV-1 | | | |
|Dest=TURN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(2) Alloc Req | | |
| |Src=L-NAT-PUB-1 | | |
| |Dest=TURN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(3) Alloc Resp | | |
| |<---------------| | |
| |Src=TURN-PUB-1 | | |
| |Dest=L-NAT-PUB-1| | |
| |Map=L-NAT-PUB-1 | | |
| |Rel=TURN-PUB-2 | | |
| | | | |
|(4) Alloc Resp | | | |
|<---------------| | | |
|Src=TURN-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
|Rel=TURN-PUB-2 | | | |
| | | | |
|(5) Alloc Req | | | |
|Src=L-PRIV-2 | | | |
|Dest=TURN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(6) Alloc Req | | |
| |Src=L-NAT-PUB-2 | | |
| |Dest=TURN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(7) Alloc Resp | | |
| |<---------------| | |
| |Src=TURN-PUB-1 | | |
| |Dest=NAT-PUB-2 | | |
| |Map=NAT-PUB-2 | | |
| |Rel=TURN-PUB-3 | | |
| | | | |
|(8) Alloc Resp | | | |
|<---------------| | | |
|Src=TURN-PUB-1 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
|Rel=TURN-PUB-3 | | | |
| | | | |
|(9) SIP INVITE | | | |
|------------------------------------------------->| |
| | | | |
| | | |(10) SIP INVITE |
| | | |--------------->|
| | | | |
| | | |(11) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=TURN-PUB-1 |
| | | | |
| | |(12) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=TURN-PUB-1 | |
| | | | |
| | |(13) Alloc Res | |
| | |--------------->| |
| | |Src=TURN-PUB-1 | |
| | |Dest=R-NAT-PUB-1| |
| | |Map=R-NAT-PUB-1 | |
| | |Rel=TURN-PUB-4 | |
| | | | |
| | | |(14) Alloc Res |
| | | |--------------->|
| | | |Src=TURN-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | |Rel=TURN-PUB-4 |
| | | | |
| | | |(15) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=TURN-PUB-1 |
| | | | |
| | |(16) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=TURN-PUB-1 | |
| | | | |
| | |(17) Alloc Res | |
| | |--------------->| |
| | |Src=TURN-PUB-1 | |
| | |Dest=R-NAT-PUB-2| |
| | |Map=R-NAT-PUB-2 | |
| | |Rel=TURN-PUB-5 | |
| | | | |
| | | |(18) Alloc Res |
| | | |--------------->|
| | | |Src=TURN-PUB-1 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | |Rel=TURN-PUB-5 |
| | | | |
| | | |(19) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(20) SIP 200 OK | | | |
|<---------------| | | |
| | | | |
|(21) SIP ACK | | | |
|------------------------------------------------->| |
| | | | |
| | | |(22) SIP ACK |
| | | |--------------->|
| | | | |
|(23) Bind Req | | | |
|------------------------>x | | |
|Src=L-PRIV-1 | | | |
|Dest=R-PRIV-1 | | | |
| | | | |
|(24) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
| | | | |
| |(25) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| | | | |
| | | |(26) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | | |
| | | |(27) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(28) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(29) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>Outgoing RTP sent from L-PRIV-1 >>>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(30) Bind Req |
| | | x<-----------------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-PRIV-1 |
| | | | |
| | | |(31) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | | |
| | |(32) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | | | |
|(33) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
| | | | |
|(34) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|Map=R-NAT-PUB-1 | | | |
| | | | |
| |(35) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |Map=R-NAT-PUB-1 | | |
| | | | |
| | | |(36) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<Outgoing RTP sent from R-PRIV-1 <<<<<<<<<<<<<<<<<|
|===================================================================|
|(37) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(38) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(39) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |USE-CANDIDATE |
| | | | |
| | | |(40) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(41) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(42) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|(43) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
| | | | |
| |(44) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| | | | |
| | | |(45) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | | |
| | | |(46) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(47) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(48) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2 >>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(49) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | | |
| | |(50) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | | | |
|(51) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
| | | | |
|(52) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|Map=R-NAT-PUB-2 | | | |
| | | | |
| |(53) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |Map=R-NAT-PUB-2 | | |
| | | | |
| | | |(54) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<Outgoing RTCP sent from R-PRIV-2<<<<<<<<<<<<<<<<<|
|===================================================================|
|(55) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(56) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(57) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |USE-CANDIDATE |
| | | | |
| | | |(58) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(59) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(60) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
| | | | |
|(61) SIP INVITE | | | |
|------------------------------------------------->| |
| | | | |
| | | |(62) SIP INVITE |
| | | |--------------->|
| | | | |
| | | |(63) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(64) SIP 200 OK | | | |
|<---------------| | | |
| | | | |
|(65) SIP ACK | | | |
|------------------------------------------------->| |
| | | | |
| | | |(66) SIP ACK |
| | | |--------------->|
| | | | |
Figure 13: Endpoint-Independent NAT with ICE
図13：ICEでのエンドポイントに依存しないNAT
o On deciding to initiate a SIP voice session, the SIP client L starts a local STUN client. The STUN client generates a TURN Allocate request as indicated in (1) from Figure 13 that also highlights the source address and port combination for which the client device wishes to obtain a mapping. The Allocate request is sent through the NAT towards the public Internet.
O SIP音声セッションを開始することを決定するには、SIPクライアントLは、ローカルSTUNクライアントを起動します。 STUNクライアントは、（1）に示すようにターンは、クライアントデバイスは、マッピングを取得することを望むのソースアドレスとポートの組み合わせを強調する図13からの要求を割り当て生成します。割り当て要求は、公衆インターネットへのNATを介して送信されます。
o The Allocate message (2) traverses the NAT to the public Internet towards the public TURN server. Note that the source address of the Allocate request now represents the public address and port from the public side of the NAT (L-NAT-PUB-1).
割り当てメッセージO（2）公共TURNサーバーへの公共のインターネットへのNATを通過します。割り当て要求の送信元アドレスは現在NAT（L-NAT-PUB-1）の公開側からパブリックアドレスおよびポートを表すことに留意されたいです。
o The TURN server receives the Allocate request and processes it appropriately. This results in a successful Allocate response being generated and returned (3). The message contains details of the server reflexive address that is to be used by the originating client to receive media (see 'Map=L-NAT-PUB-1') from (3)). It also contains an appropriate TURN-relayed address that can be used at the STUN server (see 'Rel=TURN-PUB-2').
O TURNサーバーが割り当て要求を受信し、適切に処理します。これは、生成された成功の割り当て応答をもたらすと（3）が返さ。メッセージは、メディアを受信するために元のクライアントが使用するサーバー再帰アドレスの詳細が含まれています（参照「地図= L-NAT-PUB-1」）から（3））。また、STUNサーバで使用することができる適切なターン中継アドレスを含み（参照「のRel = TURN-PUB-2」）。
o The Allocate response traverses back through the NAT using the binding created by the initial Allocate request and presents the new mapped address to the client (4). The process is repeated and a second STUN derived set of addresses is obtained, as illustrated in (5)-(8) in Figure 13. At this point, the User Agent behind the NAT has pairs of derived external server reflexive and relayed representations. The client can also gather IP addresses and ports via other mechanisms (e.g., NAT-PMP [NAT-PMP], UPnP IGD [UPnP-IGD]) or similar.
割り当て応答が戻っNAT経由の要求を割り当てて初期によって作成されたバインディングを使用して横断し、クライアントに新しいマッピングされたアドレスを提示O（4）。 （5）に示すように、得られた処理が繰り返され、第二STUNは、アドレスのセット導出 - （8）図13に、この時点では、NATの背後にあるユーザエージェントは、再帰由来外部サーバの対を有しており、表現を中継します。クライアントはまた、他の機構（例えば、NAT-PMP [NAT-PMP]のUPnP IGD〔のUPnP IGD]）または類似を介してIPアドレスとポートを収集することができます。
o The client now constructs a SIP INVITE message (9). The INVITE request will use the addresses it has obtained in the previous STUN/TURN interactions to populate the SDP of the SIP INVITE. This should be carried out in accordance with the semantics defined in the ICE specification [RFC5245], as shown below in Figure 14:
OクライアントはSIPメッセージ（9）INVITE構築します。 INVITE要求は、SIP INVITEのSDPを移入することが以前STUN / TURN相互作用で得られたアドレスを使用します。図14に、以下に示すように、これは、ICE仕様[RFC5245]で定義された意味論に従って行われるべきです。
v=0 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 c=IN IP4 $L-PRIV-1.address t=0 0 a=ice-pwd:$LPASS a=ice-ufrag:$LUNAME m=audio $L-PRIV-1.port RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtcp:$L-PRIV-2.port a=candidate:$L1 1 UDP 2130706431 $L-PRIV-1.address $L-PRIV-1.port typ host a=candidate:$L1 2 UDP 2130706430 $L-PRIV-2.address $L-PRIV-2.port typ host a=candidate:$L2 1 UDP 1694498815 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port a=candidate:$L2 2 UDP 1694498814 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-2.port typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-3.port typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port
V = 0 0 =試験IP4の$ L-PRIV-1 C = IN IP4の$ L-PRIV-滞在先住所のT = 0、A =氷PWD IN 2890844526 2890842807：$ LPASS =氷ufrag：$ LUNAME M = = rtpmapオーディオの$ L-PRIV-1.port RTP / AVP 0 A：0 PCMU / 8000 = RTCP：$ L-PRIV-2.portのA =候補：$ L1 1 UDP 2130706431 $のL-PRIV-滞在先住所$ L-PRIV-1.port TYPホストA =候補：$ L1 2 UDP 2130706430 $のL-PRIV-2.addressの$ L-PRIV-2.portの標準ホストAは=候補者：$ L2 1 UDP 1694498815 $のL-NAT -PUB-滞在先住所$ L-NAT-PUB-1.port TYP srflx RADDR $ L-PRIV-滞在先住所RPORTの$ L-PRIV-1.portのA =候補：$ L2 2 UDP 1694498814 $のL-NAT- PUB-2.address $ L-NAT-PUB-2.port TYP srflx RADDR $ L-PRIV-滞在先住所RPORTの$ L-PRIV-2.portのA =候補：$ L3 1 UDP 16777215 $のSTUN-PUB-2 .address $ STUN-PUB-2.port TYPリレーRADDR $ L-PRIV-滞在先住所のRPORT $ L-PRIV-1.portのA =候補：$ L3 2 UDP 16777214 $のSTUN-PUB-3.address $ STUN- PUB-3.port TYPリレーRADDRの$ L-PRIV-滞在先住所のRPORTの$ L-PRIV-2.port
Figure 14: ICE SDP Offer
図14：ICEのSDPオファー
o The SDP has been constructed to include all the available candidates that have been assembled. The first set of candidates (as identified by Foundation $L1) contains two local addresses that have the highest priority. They are also encoded into the connection (c=) and media (m=) lines of the SDP. The second set of candidates, as identified by Foundation $L2, contains the two server reflexive addresses obtained from the STUN server for both RTP and RTCP traffic (identified by candidate-id $L2). This entry has been given a priority lower than the pair $L1 by the client. The third and final set of candidates represents the relayed addresses (as identified by $L3) obtained from the STUN server. This pair has the lowest priority and will be used as a last resort if both $L1 and $L2 fail.
O SDPは、組み立てられた利用可能なすべての候補者を含むように構築されています。候補者の最初のセットは、（財$ L1によって識別される）、最も高い優先順位を持つ2つのローカルアドレスが含まれています。それらはまた、接続（C =）とSDPのメディア（M =）ラインに符号化されます。財団$ L2によって識別された候補の第2のセットは、RTP及び（候補のID $ L2によって識別される）RTCPトラフィックの両方のためにSTUNサーバから取得した2台のサーバー再帰アドレスを含みます。このエントリは、クライアントによるペア$ L1よりも低い優先順位を与えられています。候補の3番目と最後のセットは、STUNサーバから取得した中継アドレス（$ L3によって識別される）を表します。このペアは、最も低い優先度を持ち、$ L1とL2 $の両方が失敗した場合、最後の手段として使用されます。
o The SIP signaling then traverses the NAT and sets up the SIP session (9)-(10). On advertising a candidate address, the client should have a local STUN server running on each advertised candidate address. This is for the purpose of responding to incoming STUN connectivity checks.
O次いでSIPシグナリングは、NATを横断し、SIPセッションを設定（9） - （10）。候補アドレスを広告に、クライアントは、各広告を出して候補アドレス上で実行されているローカルSTUNサーバーを持つ必要があります。これは、着信STUNの接続性チェックへの対応のためです。
o On receiving the SIP INVITE request (10) client R also starts local STUN servers on appropriate address/port combinations and gathers potential candidate addresses to be encoded into the SDP (as the originating client did). Steps (11-18) involve client R carrying out the same steps as client L. This involves obtaining local, server reflexive, and relayed addresses. Client R is now ready to generate an appropriate answer in the SIP 200 OK message (19). The example answer follows in Figure 15:
（元のクライアントが行ったように）O SIP INVITE要求（10）クライアントRを受信すると、適切なアドレス/ポートの組み合わせのローカルSTUNサーバを起動し、SDPに符号化される可能性のある候補アドレスを収集します。ステップ（11-18）は、クライアントL.と同じ手順を実行するクライアントのRを伴うこれは、ローカル、サーバー再帰を得ることを含む、およびアドレスを中継します。クライアントRは現在、SIP 200 OKメッセージ（19）に適切な回答を生成する準備ができています。例の答えは、図15に、次のとおりです。
v=0 o=test 3890844516 3890842803 IN IP4 $R-PRIV-1 c=IN IP4 $R-PRIV-1.address t=0 0 a=ice-pwd:$RPASS m=audio $R-PRIV-1.port RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtcp:$R-PRIV-2.port a=candidate:$L1 1 UDP 2130706431 $R-PRIV-1.address $R-PRIV-1.port typ host a=candidate:$L1 2 UDP 2130706430 $R-PRIV-2.address $R-PRIV-2.port typ host a=candidate:$L2 1 UDP 1694498815 $R-NAT-PUB-1.address $R-NAT-PUB-1.port typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port a=candidate:$L2 2 UDP 1694498814 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-4.port typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-5.port typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
V = 0 0 = IP4 $ R-PRIV-1 C = IP4 $ R-PRIV-滞在先住所においてT = 0、A =氷PWD INテスト3890844516 3890842803：$ RPASS M =オーディオの$ R-PRIV-1。ポートRTP / AVP 0 A = rtpmap：0 PCMU / 8000 = RTCP：$のR-PRIV-2.port A =候補：$のL1 1 UDP 2130706431 $ R-PRIV-滞在先住所する$ R-PRIV-1.port TYPホストA =候補：$ L1 2 UDP 2130706430 $ R-PRIV-2.addressする$ R-PRIV-2.port TYPホストA =候補：$ L2 1 UDP 1694498815 $ R-NAT-PUB-滞在先住所$ R ：NAT-PUB-1.port TYP srflx RADDR $ R-PRIV-滞在先住所のRPORTする$ R-PRIV-1.port A =候補：$のL2 2 UDP 1694498814 $ R-NAT-PUB-2.address $ R- NAT-PUB-2.port TYP srflx RADDR $ R-PRIV-滞在先住所のRPORTの$ R-PRIV-1.portのA =候補：$ L3 1 UDP 16777215 $ STUN-PUB-2.address $のSTUN-PUB-4 .port TYP中継RADDR $ R-PRIV-滞在先住所のRPORT $のR-PRIV-1.portのA =候補：$ L3 2 UDP 16777214 $ STUN-PUB-3.addressの$ STUN-PUB-5.portのTYPリレーRADDR $ R-PRIV-滞在先住所RPORTする$ R-PRIV-1.port
Figure 15: ICE SDP Answer
図15：ICEのSDP回答
o The two clients have now exchanged SDP using offer/answer and can now continue with the ICE processing -- User Agent L assuming the role controlling agent, as specified by ICE. The clients are now required to form their Candidate check lists to determine which will be used for the media streams. In this example, User Agent L's Foundation 1 is paired with User Agent R's Foundation 1, User Agent L's Foundation 2 is paired with User Agent R's Foundation 2, and finally User Agent L's Foundation 3 is paired with User Agent R's Foundation 3. User Agents L and R now have a complete candidate checklist. Both clients now use the algorithm provided in ICE to determine candidate pair priorities and sort into a list of decreasing priorities. In this example, both User Agents L and R will have lists that firstly specify the host address (Foundation $L1), then the server reflexive address (Foundation $L2), and lastly the relayed address (Foundation $L3). All candidate pairs have an associate state as specified in ICE. At this stage, all of the candidate pairs for User Agents L and R are initialized to the 'Frozen' state. The User Agents then scan the list and move the candidates to the 'Waiting' state. At this point, both clients will periodically, starting with the highest candidate pair priority, work their way down the list issuing STUN checks from the local candidate to the remote candidate (of the candidate pair). As a STUN check is attempted from each local candidate in the list, the candidate pair state transitions to 'In-Progress'. As illustrated in (23), client L constructs a STUN connectivity check in an attempt to validate the remote candidate address received in the SDP of the 200 OK (20) for the highest priority in the checklist. As a private address was specified in the active address in the SDP, the STUN connectivity check fails to reach its destination causing a STUN failure. Client L transitions the state for this candidate pair to 'Failed'. In the meantime, client L is attempting a STUN connectivity check for the second candidate pair in the returned SDP with the second highest priority (24). As can be seen from messages (24) to (29), the STUN Bind request is successful and returns a positive outcome for the connectivity check. Client L is now free to send media to the peer using the candidate pair. Immediately after sending its 200 OK, client R also carries out the same set of binding requests. It firstly (in parallel) tries to contact the active address contained in the SDP (30) which results in failure.
O 2つのクライアントは現在、オファー/アンサーを使用してSDPを交換してきたし、今ICE処理を続行することができます - ユーザエージェントL制御剤的な役割を想定し、ICEによって指定されました。クライアントは、現在メディアストリームのために使用されるかを決定するために彼らの候補チェックリストを形成するために必要とされます。この例では、ユーザエージェントL'S財団1ユーザエージェントRの基礎1と対になっている、ユーザーエージェントL'S財団2は、ユーザエージェントRの基礎2と対にされ、そして最終的にユーザエージェントL'S財団3は、ユーザエージェントRの基礎3.ユーザエージェントと対になっていますLとRが完了しまし候補チェックリストを持っています。両方のクライアントは現在、候補ペアの優先順位を決定し、優先順位を下げるのリストにソートするためにICEで提供するアルゴリズムを使用します。この例では、ユーザエージェントLとRの両方が、最初にホストアドレス（財団$ L1）を指定するリストを持って、サーバ再帰アドレス（財団$ L2）、及び最後中継アドレス（財団$ L3）。 ICEに指定されているすべての候補ペアは、自由連合を持っています。この段階では、ユーザエージェントLとRの候補ペアの全てを「凍結」状態に初期化されています。ユーザエージェントは、リストをスキャンし、「待機」状態に候補者を移動します。この時点で、両方のクライアントは、定期的に、最高の候補ペアの優先順位で始まる、（候補ペアの）リモート候補者へのローカル候補からSTUNのチェックを発行し、リストの下の道を動作します。 STUNチェックとして候補ペア状態遷移は「進行中」に、リスト内の各ローカル候補から試みられています。 （23）に示すように、クライアント・Lは、チェックリストで最も高い優先度のための200 OK（20）のSDPで受信したリモート候補アドレスを検証しようとしてSTUN接続性チェックを構築します。プライベートアドレスはSDPでアクティブなアドレスで指定されたとおり、STUNの接続性チェックは、STUNの故障の原因とその宛先に到達するために失敗しました。クライアントL「は失敗しました」に、この候補ペアの状態を遷移します。一方、クライアントLは、次の優先順位（24）で返さSDPにおける第2の候補対に対するSTUN接続性チェックを試みています。 （29）にメッセージ（24）から分かるように、STUNバインド要求は成功し、接続性チェックのための肯定的な結果を返します。クライアントのLは現在、候補ペアを使用してピアにメディアを送信して自由です。すぐに200 OKを送信した後、クライアントのRは、結合要求の同じセットを行います。これは、最初に（並列に）障害をもたらすSDP（30）中に含まれる活性アドレスに連絡しようとします。
o In the meantime, a successful response to a STUN connectivity check by User Agent R (27) results in a tentative check in the reverse direction -- this is illustrated by messages (31) to (36). Once this check has succeeded, User Agent R can transition the state of the appropriate candidate to 'Succeeded', and media can be sent (RTP). The previously (31-36) described check confirm on both sides (User Agents L and R) that connectivity can be achieved using the appropriate candidate pair. User Agent L, as the controlling client now sends another connectivity check for the candidate pair, this time including the 'USE-CANDIDATE' attribute as specified in ICE to signal the chosen candidate. This exchange is illustrated in messages (37) to (42).
O一方、ユーザエージェントR逆方向に仮チェックイン（27）の結果によってSTUNの連結チェックに成功した応答 - これは（36）にメッセージ（31）によって示されています。このチェックが成功した後は、（RTP）をユーザエージェントRは、適切な候補者の状態が「成功」に移行することができ、そしてメディアが送信することができます。以前に（31-36）は、その接続が適切な候補ペアを使用して達成することができる両面（ユーザエージェントL及びR）のチェック確認をします。ユーザーエージェントL、制御クライアントは現在、候補ペアのための別の接続性チェック、選ばれた候補者を知らせるためにICEに指定されている「USE-CANDIDATE」属性を含め、この時間を送るよう。この交換は、メッセージ（42）乃至（37）に示されています。
o As part of the process in this example, both L and R will now complete the same connectivity checks for part 2 of the component named for the favored 'Foundation' selected for use with RTCP. The connectivity checks for part 2 of the candidate component are shown in L (43-48) and R (49-54). Once this has succeeded, User Agent L as the controlling client sends another connectivity check for the candidate pair. This time the 'USE-CANDIDATE' attribute is again specified to signal the chosen candidate for component 2.
oをこの例におけるプロセスの一部として、LとRの両方が今RTCPで使用するために選択された好ま「ファンデーション」の名前が付いた成分の一部2に同じ接続性チェックを完了します。対象部品の第2部のための接続性チェックはL（43-48）とR（49-54）に示されています。これが成功した後は、制御クライアントとしてユーザエージェントLは、候補ペアのための別の接続性チェックを送信します。この時間は、「USE候補」属性は、再び部品2のために選択された候補者を知らせるために指定されています。
o The candidates have now been fully verified (and selected), and as they are the highest priority, an updated offer (61-62) is now sent from the offerer (client L) to the answerer (client R) representing the new active candidates. The new offer would look as follows:
Oの候補者は今、完全に新しいアクティブを表す検証（と選択）、そして彼らが最優先されているとして、更新のオファー（61-62）について回答（クライアントR）へのオファー側（クライアントL）から送られてきました候補者。次のように新しいオファーになります。
v=0 o=test 2890844526 2890842808 IN IP4 $L-PRIV-1 c=IN IP4 $L-NAT-PUB-1.address t=0 0 a=ice-pwd:$LPASS a=ice-ufrag:$LUNAME m=audio $L-NAT-PUB-1.port RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtcp:$L-NAT-PUB-2.port a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port
V = 0 0 =テスト2890844526 2890842808 IP4ます$ L-PRIV-1は、C = IP4ます$ L-NAT-PUB-滞在先住所では、T = 0、A =氷-PWD：$ LPASSのA =アイスufrag：$ LUNAME M =オーディオの$ L-NAT-PUB-1.port RTP / AVP 0 A = rtpmap：0 PCMU / 8000 =のRTCP：$のL-NAT-PUB-2.portのA =候補：$のL2 1 UDP 2203948363 $ L ：NAT-PUB-滞在先住所$ L-NAT-PUB-1.port TYP srflx RADDR $ L-PRIV-滞在先住所のRPORT $ L-PRIV-1.portのA =候補：$ L2 2 UDP 2172635342 $ L- NAT-PUB-2.address $ L-NAT-PUB-2.port TYP srflx RADDR $ L-PRIV-滞在先住所RPORTます$ L-PRIV-2.port
Figure 16: ICE SDP Updated Offer
図16：ICEのSDPを更新オファー
o The resulting answer (63-64) for R would look as follows:
次のようにO Rの結果の答え（63〜64）は、になります。
v=0 o=test 3890844516 3890842804 IN IP4 $R-PRIV-1 c=IN IP4 $R-PRIV-1.address t=0 0 a=ice-pwd:$RPASS a=ice-ufrag:$RUNAME m=audio $R-PRIV-1.port RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtcp:$R-PRIV-2.port a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx raddr $R-PRIV-1.address rport $R-PRIV-2.port
V = 0 0 = IP4 $ R-PRIV-1 C = IP4 $ R-PRIV-滞在先住所においてT = 0、A =氷PWD INテスト3890844516 3890842804：$ RPASSのA =氷ufrag：$ RUNAME M =オーディオの$ R-PRIV-1.port RTP / AVP 0 A = rtpmap：0 PCMU / 8000、A = RTCP：$ R-PRIV-2.portのA =候補：$ L2 1 UDP 2984756463 $ R-NAT-PUB-1 .address $ R-NAT-PUB-1.port TYP srflx RADDR $ R-PRIV-滞在先住所RPORTする$ R-PRIV-1.portのA =候補：L2 2 UDP 2605968473 $ R-NAT-PUB-2 $。アドレス$ R-NAT-PUB-2.port TYP srflx RADDR $ R-PRIV-滞在先住所RPORTする$ R-PRIV-2.port
Figure 17: ICE SDP Updated Answer
図17：ICEのSDP更新しました回答
This section highlights that although using STUN techniques is the preferred mechanism for traversal of NAT, it does not solve every case. The use of basic STUN on its own will not guarantee traversal through every NAT type, hence the recommendation that ICE is the preferred option.
このセクションでは、STUN技術を使用してNATトラバーサルのに適したメカニズムですが、それはすべてのケースを解決しないことを強調しています。独自に基本的なSTUNを使用すると、すべてのNATタイプ、ICEが好ましい選択肢であるので、勧告を通じてトラバーサルを保証するものではありません。
Client ADDRESS/PORT-Dependent STUN [..]
NAT Server
| | | |
|(1) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| |(2) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(3) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5)SIP INVITE | | |
|------------------------------------------------------->|
| | | |
| | |(6)SIP 200 OK |
| |<------------------------------------|
| | | |
|(7)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>|
|========================================================|
| | | |
| x=====================================|
| xIncoming Media sent to L-PRIV-1<<<<<<|
| x=====================================|
| | | |
|(8)SIP ACK | | |
|----------------->| | |
| |(9) SIP ACK | |
| |------------------------------------>|
| | | |
Figure 18: Address/Port-Dependent NAT with STUN - Failure
図18：STUNとアドレス/ポート依存のNAT - 失敗
The example in Figure 18 is conveyed in the context of a client behind the Address/Port-Dependent NAT initiating a call. It should be noted that the same problem applies when a client receives a SIP invitation and is behind a Address/Port-Dependent NAT.
図18の例では、通話を開始するアドレス/ポート依存のNATの背後にあるクライアントのコンテキストで搬送されます。クライアントがSIP招待を受信して、アドレス/ポート依存のNATの背後にあるときに、同じ問題が適用されることに留意すべきです。
o In Figure 18, the client behind the NAT obtains a server reflexive representation using standard STUN mechanisms (1)-(4) that have been used in previous examples in this document (e.g., Section 5.2.1.1.1).
（4）本書で前の例で使用されてきた（例えば、セクション5.2.1.1.1） - O、図18では、NATの背後にあるクライアントは、（1）標準STUNメカニズムを使用して、サーバ再帰表現を取得します。
o The external mapped address (server reflexive) obtained is also used in the outgoing SDP contained in the SIP INVITE request (5).
外部マッピングアドレスO（サーバ反射的）を得もSIP INVITE要求に含まれる発信SDPで使用されている（5）。
o In this example, the client is still able to send media to the external client. The problem occurs when the client outside the NAT tries to use the reflexive address supplied in the outgoing INVITE request to traverse media back through the Address/ Port-Dependent NAT.
Oこの例では、クライアントが外部クライアントにメディアを送信することができます。 NAT外部のクライアントがバックアドレス/ポート依存のNAT経由のメディアを横断する発信INVITE要求で供給される再帰アドレスを使用しようとすると問題が発生します。
o A Address/Port-Dependent NAT has differing rules from the Endpoint-Independent type of NAT (as defined in RFC 4787 [RFC4787]). For any internal IP address and port combination, data sent to a different external destination does not provide the same public mapping at the NAT. In Figure 18, the STUN query produced a valid external mapping for receiving media. This mapping, however, can only be used in the context of the original STUN request that was sent to the STUN server. Any packets that attempt to use the mapped address and that do not originate from the STUN server IP address and optionally port will be dropped at the NAT. Figure 18 shows the media being dropped at the NAT after (7) and before (8). This then leads to one-way audio.
住所O /ポート依存NATは、NATのエンドポイント非依存型（RFC 4787で定義されるように[RFC4787]）から、ルールを異なるいます。任意の内部IPアドレスとポートの組み合わせの場合は、別の外部の宛先に送信されたデータは、NATで同じパブリック・マッピングを提供していません。図18に、STUNクエリは、メディアを受信するための有効な外部マッピングを生成しました。このマッピングは、しかし、唯一STUNサーバに送信された元のSTUN要求のコンテキストで使用することができます。マッピングされたアドレスを使用しようとすると、それはSTUNサーバーのIPアドレスと、必要に応じてポートから発信しないすべてのパケットはNATでドロップされます。図18は、メディアが後にNATでドロップされる示す（7）及び前（8）。そして、これは一方向のオーディオにつながります。
As identified in Section 5.2.2.1, STUN provides a useful tool for the traversal of the majority of NATs but fails with Address/ Port-Dependent NAT. The TURN extensions [RFC5766] address this scenario. TURN extends STUN to allow a client to request a relayed address at the TURN server rather than a reflexive representation. This then introduces a media relay in the path for NAT traversal (as described in Section 4.2.3.2). The following example explains how TURN solves the previous failure when using STUN to traverse a Address/Port-Dependent NAT. It should be noted that TURN works most effectively when used in conjunction with ICE. Using TURN on its own results in all media being relayed through a TURN server; this is not efficient.
5.2.2.1項で特定されたよう、STUNはNATの大多数のトラバーサルのための便利なツールを提供しますが、アドレス/ポート依存NATで失敗します。 TURN拡張[RFC5766]は、このシナリオに対処します。 TURNは、クライアントがTURNサーバーで中継されたアドレスではなく、反射的な表現を要求することを可能にするためにSTUNを拡張します。これは、次いで、NATトラバーサル（セクション4.2.3.2に記載されるように）のパスでメディアリレーを導入します。次の例では、アドレス/ポート依存NATを横断するSTUNを使用している場合TURNは、以前の失敗を解決する方法について説明します。 ICEと併用した場合TURNが最も効果的に働くことに留意すべきです。 TURNサーバーを介して中継されるすべてのメディアで独自の結果にTURNを使用します。これは効率的ではありません。
L Address/Port-Dependent TURN [..]
NAT Server
| | | |
|(1) Alloc Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | |
| | | |
| |(2) Alloc Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(3) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| |Rel=STUN-PUB-2 | |
| | | |
|(4) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
|Rel=STUN-PUB-2 | | |
| | | |
|(5) Alloc Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | |
| | | |
| |(6) Alloc Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(7) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| |Rel=STUN-PUB-3 | |
| | | |
|(8) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
|Rel=STUN-PUB-3 | | |
| | | |
|(9)SIP INVITE | | |
|----------------->| | |
| | | |
| |(10)SIP INVITE | |
| |------------------------------------>|
| | | |
| | |(11)SIP 200 OK |
| |<------------------------------------|
| | | |
|(12)SIP 200 OK | | |
|<-----------------| | |
| | | |
|========================================================|
|>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>|
|========================================================|
| | | |
| | |==================|
| | |<<<Media Sent to<<|
| | |<<<<STUN-PUB-2<<<<|
| | |==================|
| | | |
|=====================================| |
|<Incoming Media Relayed to L-PRIV-1<<| |
|=====================================| |
| | | |
| | |==================|
| | |<<<RTCP Sent to<<>|
| | |<<<<STUN-PUB-3<<<<|
| | |==================|
| | | |
|=====================================| |
|<<Incoming RTCP Relayed to L-PRIV-2<<| |
|=====================================| |
| | | |
|(13)SIP ACK | | |
|----------------->| | |
| | | |
| |(14) SIP ACK | |
| |------------------------------------>|
| | | |
Figure 19: Address/Port-Dependent NAT with TURN - Success
図19：TURNとアドレス/ポート依存のNAT - 成功
o In this example, client L issues a TURN allocate request (1) to obtained a relay address at the STUN server. The request traverses through the Address/Port-Dependent NAT and reaches the STUN server (2). The STUN server generates an Allocate response (3) that contains both a server reflexive address (Map=NAT-PUB-1) of the client and also a relayed address (Rel=STUN-PUB-2). The relayed address maps to an address mapping on the STUN server that is bound to the public pinhole that has been opened on the NAT by the Allocate request. This results in any traffic sent to the TURN server relayed address (Rel=STUN-PUB-2) being forwarded to the external representation of the pinhole created by the Allocate request (NAT-PUB-1).
Oこの例では、クライアント・Lは、TURNがSTUNサーバで得られたリレーアドレスに要求（1）を割り当てる発行します。リクエストは、アドレス/ポート依存NATを通じて横断し、STUNサーバ（2）に達します。 STUNサーバは、クライアントとも中継アドレス（相対= STUN-PUB-2）の両方のサーバ再帰アドレス（MAP = NAT-PUB-1）を含有割り当て応答（3）を生成します。中継されたアドレスは割り当て要求によってNATに開かれた公共のピンホールにバインドされているSTUNサーバー上のアドレスマッピングにマッピングされます。これは、割り当て要求（NAT-PUB-1）によって作成されたピンホールの外部表現に転送されるTURNサーバ中継アドレス（相対= STUN-PUB-2）に送信されたトラフィックをもたらします。
o The TURN derived address (STUN-PUB-2) arrives back at the originating client (4) in an Allocate response. This address can then be used in the SDP for the outgoing SIP INVITE request as shown in the following example (note that the example also includes client L obtaining a second relay address for use in the RTCP attribute (5-8)):
割り当て応答中のO TURN由来アドレス（STUN-PUB-2）元のクライアントに戻って到着する（4）。次の例に示すように、このアドレスは、INVITE要求を発信SIPためSDPで次に使用することができる（例はまた、RTCP属性（5-8）において使用するための第2のリレーアドレスを取得するクライアントLを含むことに注意してください）。
v=0 o=test 2890844342 2890842164 IN IP4 $L-PRIV-1 c=IN IP4 $STUN-PUB-2.address t=0 0 m=audio $STUN-PUB-2.port RTP/AVP 0 a=rtcp:$STUN-PUB-3.port
IP4 $ L-PRIV-1のC = IN V = 0 0 =試験2890844342 2890842164 IP4 $ STUN-PUB-2.address T = 0、M =オーディオの$ STUN-PUB-2.port RTP / AVP 0 A = RTCP IN ：$ STUN-PUB-3.port
o On receiving the INVITE request, the User Agent Server (UAS) is able to stream media and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the STUN server. As shown in Figure 19 (between messages (12) and (13), the media from the UAS is directed to the relayed address at the STUN server. The STUN server then forwards the traffic to the open pinholes in the Address/Port-Dependent NAT (NAT-PUB-1 and NAT-PUB-2). The media traffic is then able to traverse the Address/Port-Dependent NAT and arrives back at client L.
O INVITE要求を受信すると、ユーザエージェントサーバ（UAS）は、STUNサーバにリレーアドレス（STUN-PUB-2及びSTUN-PUB-3）へのメディア及びRTCPをストリーミングすることができます。図19に示すように（メッセージ（12）と（13）との間に、UASからメディアをSTUNサーバに中継されたアドレスに向けられている。STUNサーバは、/ポート依存アドレスで開いてピンホールにトラフィックを転送しますNAT（NAT-PUB-1およびNAT-PUB-2）。メディアトラフィックは、[アドレス/ポート依存NATを通過することができ、クライアントL.に戻って到着
o TURN on its own will work for Address/Port-Dependent and other types of NAT mentioned in this specification but should only be used as a last resort. The relaying of media through an external entity is not an efficient mechanism for NAT traversal and comes at a high processing cost.
Oアドレスのために働くだろう、独自の電源をオン/ NATのポート依存性および他のタイプは、本明細書で言及したが、最後の手段としてのみ使用する必要があります。外部エンティティによるメディアの中継は、NATトラバーサルのための効率的なメカニズムではなく、高い処理コストがかかります。
The previous two examples have highlighted the problem with using core STUN for all forms of NAT traversal and a solution using TURN for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism for traversing all varieties of NAT is using ICE, as detailed in Section 4.2.3.3. ICE makes use of core STUN, TURN and any other mechanism (e.g., NAT-PMP[NAT-PMP], UPnP IGD[UPnP-IGD]) to provide a list of prioritized addresses that can be used for media traffic. Detailed examples of ICE can be found in Section 5.2.1.2.1. These examples are associated with an Endpoint-Independent type NAT but can be applied to any NAT type variation, including Address/ Port-Dependent type NAT. The ICE procedures carried out are the same. For a list of candidate addresses, a client will choose where to send media dependent on the results of the STUN connectivity checks and associated priority (highest priority wins). It should be noted that the inclusion of a NAT displaying Address/Port-Dependent properties does not automatically result in relayed media. In fact, ICE processing will avoid use of media relay with the exception of two clients that both happen to be behind a NAT using Address/ Port-Dependent characteristics. The connectivity checks and associated selection algorithm enable traversal in this case. Figure 20 and the following description provide a guide as to how this is achieved using the ICE connectivity checks. This is an abbreviated example that assumes successful SIP offer/answer exchange and illustrates the connectivity check flow.
前の2つの例では、NATトラバーサルのすべてのフォームとアドレス/ポート依存NATの場合のTURNを使用してソリューションをコアSTUNを使用しての問題を強調しています。セクション4.2.3.3で詳述するようにNATのすべての品種を横断するための推奨メカニズムは、ICEを使用しています。 ICEは、コアSTUN、TURNおよびメディアトラフィックのために使用できる優先順位アドレスのリストを提供する任意の他の機構（例えば、NAT-PMP [NAT-PMP]のUPnP IGD〔のUPnP IGD]）を利用します。 ICEの詳細な例は、セクション5.2.1.2.1に記載されています。これらの例は、エンドポイントに依存しないタイプのNATに関連付けられているが、アドレス/ポート依存型のNATを含む任意のNATタイプのバリエーションにも適用することができます。行わICE手順は同じです。候補アドレスのリストについては、クライアントはSTUNの接続性チェックと関連する優先順位の結果に依存してメディアを（最高の優先度が勝つ）送信先を選択します。アドレス/ポート依存プロパティを表示するNATを含めることが自動的に中継されたメディアにはならないことに留意すべきです。実際には、ICEの処理は両方ともアドレス/ポート依存特性を使用してNATの背後に起こる2つのクライアントを除き、メディアリレーの使用を避けることができます。接続性チェックと関連する選択アルゴリズムは、この場合、トラバースを可能にします。図20および以下の説明では、これはICE接続性チェックを使用して達成される方法へのガイドを提供します。これが成功したSIPオファー/アンサー交換を想定し、接続性チェックの流れを示す簡略例です。
L Address/Port-Dependent Endpoint-Independent R
L-NAT R-NAT
|========================================================|
| SIP OFFER/ANSWER EXCHANGE |
|========================================================|
| | | |
| | |(1)Bind Req |
| | |<-----------------|
| | |Src=R=PRIV-1 |
| | |Dest=L-NAT-PUB-1 |
| | | |
| |(2)Bind Req | |
| x<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(3)Bind Req | | |
|----------------->| | |
|Src=L-PRIV-1 | | |
|Dest=R-NAT-PUB-1 | | |
| | | |
| |(4)Bind Req | |
| |----------------->| |
| |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | |
| | | |
| | |(5)Bind Req |
| | |----------------->|
| | |Src=L-NAT-PUB-1 |
| | |Dest=R-PRIV-1 |
| | | |
| | |(6)Bind Resp |
| | |<-----------------|
| | |Src=R-PRIV-1 |
| | |Dest=L-NAT-PUB-1 |
| | | |
| |(7)Bind Resp | |
| |<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(8)Bind Resp | | |
|<-----------------| | |
|Src=R-NAT-PUB-1 | | |
|Dest=L-PRIV-1 | | |
| | | |
| | |(9)Bind Req |
| | |<-----------------|
| | |Src=R-Priv-1 |
| | |Dest=L-NAT-PUB-1 |
| |(10)Bind Req | |
| |<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(11)Bind Req | | |
|<-----------------| | |
|Src=R-NAT-PUB-1 | | |
|Dest=L-PRIV-1 | | |
| | | |
|(12)Bind Resp | | |
|----------------->| | |
|Src=L-PRIV-1 | | |
|Dest=L-NAT-PUB-1 | | |
| | | |
| |(13)Bind Resp | |
| |----------------->| |
| |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | |
| | | |
| | |(14)Bind Resp |
| | |----------------->|
| | |Src=L-NAT-PUB-1 |
| | |Dest=R-PRIV-1 |
| | | |
Figure 20: Single Address/Port-Dependent NAT - Success
図20：シングルアドレス/ポート依存のNAT - 成功
In this abbreviated example, client R has already received a SIP INVITE request and is starting its connectivity checks with client L. Client R generates a connectivity check (1) and sends to client L's information as presented in the SDP offer. The request arrives at client L's Address/Port-Dependent NAT and fails to traverse as there is no NAT binding. This would then move the connectivity check to a failed state. In the meantime, client L has received the SDP answer in the SIP request and will also commence connectivity checks. A check is dispatched (3) to client R. The check is able to traverse the NAT due to the association set up in the previously failed check (1). The full Bind request/response is shown in steps (3)-(8). As part of a candidate pair, client R will now successfully be able to complete the checks, as illustrated in steps (9)-(14). The result is a successful pair of candidates that can be used without the need to relay any media.
この略記例では、クライアントRは既にSIP INVITE要求を受信したクライアントL.クライアントRは、接続性チェック（1）を生成し、SDPオファーに提示されるクライアントL'の情報を送信すると、その接続性チェックを開始します。要求は、クライアントL'sのアドレス/ポート依存のNATに到着し、何のNATバインディングがないと行き来することができません。そして、これは失敗した状態に接続性チェックを移動します。一方、クライアントLは、SIPリクエストにSDPの答えを受けており、また、接続性チェックを開始します。チェックが伴う関連するチェックがNATをトラバースすることができるクライアント・R.〜（3）に送出され、以前に失敗したチェックで設定（1）。完全なバインド要求/応答は、ステップ（3）に示されている - （8）。 （14） - 候補ペアの一部として、クライアントRは現在、正常ステップ（9）に示すように、検査を完了することができるであろう。結果は、任意のメディアを中継することなく使用することができます候補者の成功のペアです。
In conclusion, the only time media needs to be relayed is a result of clients both behind Address/Port-Dependent NATs. As you can see from the example in this section, neither side would be able to complete connectivity checks with the exception of the Relayed candidates.
結論として、メディアを中継する必要がある唯一の時間は、アドレス/ポート依存のNATの背後にあるクライアントの両方の結果です。あなたはこのセクションの例からもわかるように、どちらの側が中継された候補の例外との接続性チェックを完了することができるだろう。
This section describes how IPv6-only SIP User Agents can communicate with IPv4-only SIP User Agents. While the techniques discussed in this document primarily contain examples of traversing NATs to allow communications between hosts in private and public networks, they are by no means limited to such scenarios. The same NAT traversal techniques can also be used to establish communication in a heterogeneous network environment -- e.g., communication between an IPv4 host and an IPv6 host.
このセクションでは、IPv6のみのSIPユーザエージェントは、IPv4のみのSIPユーザエージェントと通信する方法について説明します。本書で説明する手法は、主にプライベートおよびパブリックネットワーク内のホスト間の通信を可能にするためのNATをトラバースの例を含むが、それらはこのようなシナリオに限定されるものではありません。 IPv4ホストとIPv6ホストとの間の、例えば、通信 - 同じNATトラバーサル技法はまた、異種ネットワーク環境での通信を確立するために使用することができます。
IPv4-IPv6 translations at the SIP level usually take place at dual-stack proxies that have both IPv4 and IPv6 DNS entries. Since these translations do not involve NATs that are placed in the middle of two SIP entities, they fall outside the scope of this document. A detailed description of this type of translation can be found in [RFC6157].
SIPレベルでのIPv4-IPv6の翻訳は通常、IPv4とIPv6のDNSの両方のエントリを持つデュアルスタックプロキシで開催します。これらの翻訳は、2つのSIPエンティティの中央に配置されているNATのを伴わないので、彼らはこの文書の範囲外。翻訳のこのタイプの詳細な説明は、[RFC6157]に見出すことができます。
There are no security considerations beyond the ones inherited by reference.
参照によって継承されたものを超えていないセキュリティ上の考慮事項はありません。
The authors would like to thank the members of the IETF SIPPING WG for their comments and suggestions. Expert review and detailed contribution including text was provided by Dan Wing, who was supportive throughout.
作者は彼らのコメントや提案をIETF SIPPING WGのメンバーに感謝したいと思います。テキストを含む専門家のレビューと詳細な寄与は全体で支えだったダン・ウィング、提供されました。
Detailed comments were provided by Vijay Gurbani, Kaiduan Xie, Remi Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins, and Hans Persson.
詳細なコメントはビジェイGurbani、Kaiduan謝、レミデニス・Courmont、Hadrielカプラン、フィリップ・マシューズ、スペンサードーキンスとハンス・パーションにより提供されました。
[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月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、J.とH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327]ウィリス、D.とB. Hoeneisen、 "セッション開始プロトコル非隣接コンタクトを登録するための（SIP）拡張ヘッダーフィールド"、RFC 3327、2002年12月。
[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月。
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.
[RFC3581]ローゼンバーグ、J.、およびH. Schulzrinneと、 "対称応答ルーティングのためのセッション開始プロトコル（SIP）への拡張"、RFC 3581、2003年8月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]のHuitema、C.、 "リアルタイム制御プロトコル（RTCP）セッション記述プロトコル（SDP）内の属性"、RFC 3605、2003年10月。
[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月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]ウイング、D.、 "対称RTP / RTP制御プロトコル（RTCP）"、BCP 131、RFC 4961、2007年7月。
[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月。
[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月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]パーキンス、C.とM.ウェスター、 "シングルポートの多重化RTPデータおよび制御パケット"、RFC 5761、2010年4月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサルNAT（TURN）の周りにリレーを使用してリレー拡張NAT（STUN）のセッショントラバーサルユーティリティに"、RFC 5766、2010年4月。
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010.
[RFC5923] Gurbani、V.、マーイ、R.、およびB.テート、 "セッション開始プロトコル（SIP）における接続の再利用"、RFC 5923、2010年6月。
[MIDDLEBOXES] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, July 2010.
[のMiddleboxes] Stucker、B.およびH. Tschofenig、「メディアの経路に沿ってシグナリングプロトコルの通信のためのミドル相互作用の分析」、進歩、2010年7月での作業。
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP]チェシャー、S.、 "NATポートマッピングプロトコル（NAT-PMP）"、進歩、2008年4月の作業。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[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挙動検出"。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、カマリロ、G.、ペンフィールド、R.、Hawrylyshen、A.、およびM. Bhatiaは、RFC 5853年4月 "セッション開始プロトコル（SIP）セッションボーダーコントロール（SBC）デプロイメントの要件" 2010。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157]キャマリロ、G.、エルMalki、K.、およびV. Gurbani、 "セッション開始プロトコルにおけるIPv6移行（SIP）"、RFC 6157、2011年4月。
[UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway Device v1.0", 2000, <http://www.upnp.org/specs/gw/igd1/>.
[UPnPの-IGD] UPnPフォーラム、 "ユニバーサルプラグアンドインターネットゲートウェイデバイスのv1.0の再生"、2000年、<http://www.upnp.org/specs/gw/igd1/>を。
Authors' Addresses
著者のアドレス
Chris Boulton NS-Technologies
クリスボールトンNSテクノロジーズ
EMail: chris@ns-technologies.com
メールアドレス：chris@ns-technologies.com
Jonathan Rosenberg Skype
ジョナサン・ローゼンバーグスカイプ
EMail: jdrosen@jdrosen.net
メールアドレス：jdrosen@jdrosen.net
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Francois Audet Skype
フランソワAudet、スカイプ
EMail: francois.audet@skype.net
メールアドレス：francois.audet@skype.net