[要約] RFC 6314は、クライアントサーバーSIPにおけるNATトラバーサルの実践に関するガイドラインです。その目的は、SIP通信がNAT環境で正常に動作するためのベストプラクティスを提供することです。
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
クライアントサーバーSIPのNATトラバーサルプラクティス
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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（ネットワークアドレス翻訳者）トラバーサルは、セッション開始プロトコル（SIP）[RFC3261]およびリアルタイムトランスポートプロトコル（RTP）[RFC3550]などの関連メディアのコンテキストで考慮されると、複雑な問題として長い間特定されてきました。この問題は、今日の市場で利用可能なさまざまなNATと、多数の潜在的な展開シナリオによって悪化しています。さまざまなNATの動作の詳細は、「ユニキャストUDPのNAT行動要件」[RFC4787]に記載されています。
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は、NAT（STUN）[RFC5389]のセッショントラバーサルユーティリティ、インタラクティブな接続性確立（ICE）[RFC5245]、対称応答[RFC3581]、対称RTP [RFC4961]、トラバーサルなど、NATのトラバーサルの多くの仕様で活性化されています。リレーNAT（ターン）[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ピアの間でこれらの同じプラクティスを推奨する可能性がありますが、ピアツーのピア間で使用するための異なるプラクティスを推奨するでしょう。 - ピアネットワーク。
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.
NATを通るSIPのトラバーサルは、両方とも注意が必要な2つのカテゴリに分割できます。コアSIPシグナル伝達と関連するメディアトラバーサルです。このドキュメントでは、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].
この文書では、非ターンベースのメディア仲介業者の使用は考慮されていません。詳細については、[RFC5853]および[Middleboxes]から入手できます。
The core SIP signaling has a number of issues when traversing through NATs.
コアSIPシグナリングには、NATを通過する際に多くの問題があります。
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 [RFC3261]で定義されているUDPを介したSIP応答ルーティングにより、応答はヘッダーを介して最上部で指定されたソースIPアドレス、または最上部の「受信」パラメーターを「ヘッダー」で「受信」パラメーターに配信します。ポートは、SIP「Via」ヘッダーから抽出され、SIP応答を返すためにIPアドレス/ポートの組み合わせを完了します。応答の宛先は正しいですが、 'via'ヘッダーのSIPに含まれるポートは、NATの開いたピンホールを表すポートではなく、元のクライアントのリスニングポートを表します。これにより、応答はNATに送り返されますが、SIPトラフィックには開いていないポートに送り返されます。その後、SIP応答はNATでドロップされます。これを図1に示します。これは、ポート5060に返されるSIP応答を示しています。
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つのケースがあります。1つ目は、TCPなどの信頼できる接続指向のトランスポートプロトコルを使用する場合、SIPには、対応するトランザクションリクエストに作成/使用された接続を再利用するSIP応答をもたらす固有のメカニズムがあります。SIPプロトコルは、登録中にクライアントとサーバーの間に作成された既存のTCP接続など、発信元クライアントの逆方向に生成された新しいリクエストを可能にするメカニズムを提供しません。これにより、TCPの場合、登録された連絡先アドレスが「接続」にバインドされていません。図2に示すように、NATで要求がブロックされます。2番目のケースは、ネットワークのプライベート側のSIPエンティティに到達するために外部NATマッピングを再利用する必要があるUDPなどの信頼性の低いトランスポートプロトコルを使用する場合です。
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では、元のレジスタリクエストがポート8023のクライアントから送信され、ポート5060のプロキシによって受信され、接続を確立し、NATにピンホールを開きます。プロキシからの新しい要求の生成は、パブリックネットワークから到達できない登録エンティティ（連絡先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シグナリングで使用される最も一般的なメディアトランスポートタイプの1つです。RTPの交渉は、セッション説明プロトコル（SDP）[RFC4566]およびSIPオファー/回答交換[RFC3264]を使用して、SIPセッションの確立で発生します。SIPオファー/回答交換中、RTPなどのメディアを受信する手段として、セッションで各クライアントによってIPアドレスとポートの組み合わせが指定されます。問題は、クライアントがメディアを受信するためにアドレスを宣伝し、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)).
NATSの背後にあるクライアントの接続アドレスには、公開インターネット全体でルーティングできないプライベートIPv4アドレスが名目上に含まれます。さらに悪化する問題は、クライアントAが信号確認メッセージで受け取った宛先アドレスにメディアを送信する傾向です。実際には、rtpパケットの入っているプライベートネットワーク内のホスト内のホストに対応するアドレスです（同様に）、クライアントBは、これらのパケットを求めなかったプライベートネットワーク内のホストにメディアを送信する場合があります。最後に、問題をさらに複雑にするために、異なるデフォルトの動作を持つ多くの異なるNATトポロジーが、統一されたアプローチに到達することの難しさを高めます。この問題は、Nattedの可能性のあるすべてのメディアトランスポートプロトコル（TCP、UDP、Stream Control Transmission Protocol（SCTP）、Datagram混雑制御プロトコル（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 各エンドポイントには、到達するために使用できるさまざまなアドレスがあります（たとえば、ネイティブインターフェイスアドレス、パブリックナットアドレス）。さまざまな状況では、異なる（ローカルエンドポイント、リモートエンドポイント）アドレスのペアを使用する必要があり、いつどのペアを使用するかは明確ではありません。
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タプルを使用することです。実際には問題ではありませんが、NATSを通じてこれを行うことは、両方向で同じ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シグナリングをNATを介してSIPシグナリングを取得し、SIPオファー/回答のエンドポイント間の流れで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シグナル伝達には、このドキュメントのセクション3で説明されているように、NATを通過するときにトランザクション障害をもたらす2つの領域があります。残りのサブセクションは、輸送プロトコルに関係なく、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のピンホールを開きます。SIPプロキシは通常、図1に示すように、「ヘッダー」で「ヘッダー」でSIPで利用可能なポートに応答します。SIPプロキシは、 'ヘッダーを介してSIPの「rport」パラメーターを称え、それがあるポートへの応答をルーティングします。送信されました。この応答トラバーサルの正確な機能は「対称応答」と呼ばれ、詳細はRFC 3581 [RFC3581]に文書化されています。同じポートからのSIPリクエスト/応答のリスニングや送信など、RFC 3581 [RFC3581]の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.
セクション3で定義され、図2に示されているSIPシグナル伝達の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 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.
NATを介したアウトバウンド接続のみを生成できるユーザーエージェントなどのデバイスのガイドラインは、「セッション開始プロトコル（SIP）のクライアント開始接続の管理」[RFC5626]に文書化されています。このドキュメントは、フロー識別子（reg-id）に関連して、一意のユーザーエージェントインスタンス識別子（Instance-ID）を使用する手法を提供します。2つの識別子の組み合わせは、登録バインディングに関連して保存される特定の接続（UDPとTCPの両方）の鍵を提供します。SIPアドレスオブレコード（AOR）への着信要求を受信すると、登録によって作成された関連するフローへのプロキシ/レジストラルート、したがってNATを通るルート。また、クライアントがNATバインディングを生かし続けるためのキープアライブメカニズムを提供します。これは、SIPシグナリング接続（UDPおよびCRLF/オペレーティングシステムのSTUN KEEPALIVEでは、TCPのような信頼できる輸送のためにKeepAlive）を介してPing-Pongメカニズムを多重化することで達成されます。[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で特定された主な問題は、NATのパブリック側から内部IPアドレス/ポートの組み合わせに到達できないことです。RTPなどのメディアの場合、これはNATを通過するオーディオのトラバースが発生しません（図3に示すように）。この問題を克服するために、「対称RTP/RTCP」[RFC4961]と呼ばれる手法を使用できます。これには、同じIPアドレス/ポートの組み合わせからRTP/RTCPトラフィックの送信と受信の両方のSIPエンドポイントが含まれます。NATの後ろで操作し、[Middleboxes]で説明されている「ラッチ」手法を使用する場合、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のトランスポート接続情報を明示的に指定するために含まれるSDP属性を定義しているため、目的のために別の明示的なNAT結合を設定できます。アドレスの詳細は、このセクションで詳述されている方法を含む適切な方法を使用して取得できます（例：Stun、ターン、アイス）。
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]のさらなる強化は、[RFC5761]で定義されており、同じIP/ポートの組み合わせでRTPとRTCPの両方を「マクシング」しています。
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、スタン、およびターンは、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またはスタンのセッショントラバーサルユーティリティは、RFC 5389 [RFC5389]で定義されています。Stunは、NATのパブリック面の内部エンティティを表すためにNATデバイスが使用する外部IPアドレス/ポートの組み合わせの詳細を提供する軽量ツールキットとプロトコルです。このような外部表現を学習すると、クライアントはそれに応じてSDPの接続アドレスとして使用してNATトラバーサルを提供できます。「ユニキャストUDPのNAT行動要件」[RFC4787]で定義された用語を使用して、Stunはエンドポイントに依存しないマッピングで動作しますが、アドレス依存マッピングまたはアドレス依存マッピングタイプNATのいずれでも動作しません。以前の2つのNATマッピングのいずれかでStunを使用して、外部IPアドレス/ポート表現のプローブをプローブすると、代替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の周りのリレーを使用したトラバーサル」は、（ターンサーバーから）クライアントへのパケットを中継するために使用されるアドレスを導出するためのSTUNプロトコルの使用です。ターンは、トラフィックが関連する内部アドレスに到達できるようにするメディアリレーとして機能するターンサーバーで外部アドレス（グローバルにルータブル）を提供します。ターン仕様の詳細は[RFC5766]で定義されています。ターンサービスは、ほとんど常にSIPエンティティにメディアトラフィックを提供しますが、この方法は、NATトラバーサルの一般的なメカニズムとしてではなく、最後の手段としてのみ使用されることをお勧めします。これは、ターンを使用すると、メディアトラフィックを中継するときに高いパフォーマンスコストがあり、望ましくない遅延につながる可能性があるためです。
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].
対称RTPとメディアラッチングが十分ではない場合、インタラクティブな接続確立（ICE）は、既存のNATを横断するための推奨方法です。ICEは、Stun、Turn、およびその他のプロトコルなどの既存のテクノロジーを使用して、統一されたソリューションを提供するために一方的な自己アドレス固定（NSAF）[RFC3424]に準拠したその他のプロトコルを使用する方法です。これは、スタン/ターンなどのテクノロジーを使用してできるだけ多くの代表的なIPアドレス/ポートの組み合わせを取得することによって達成されます（注：ICEエンドポイントは他のメカニズムを使用できます（たとえば、NATポートマッピングプロトコル[NAT-PMP]、ユニバーサルプラグ、およびユニバーサルプラグ、およびインターネットゲートウェイデバイス[UPNP-IGD]）を再生して、パブリックIPアドレスとポートを学習し、A =候補の行をその情報に入力します）。アドレスが蓄積されると、それらはすべて「候補」と呼ばれる新しいメディア属性のSDP Exchangeに含まれます。各候補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トラバーサルシナリオが含まれています。[RFC5626]を使用して、シグナル伝達NATトラバーサルが達成されます。
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レジスタメソッドの基本的なシグナル伝達トラバーサルを文書化します。
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レジスタリクエストを送信します。クライアントには、UDP応答のトラバーサルを許可するために、このドキュメントのセクション4.1.1で説明されているように、「rport」パラメーターを含みます。図5の（1）に示されている元のリクエストは、標準のSIPレジスタメッセージです。
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 This SIP transaction now generates a SIP 200 OK response, as depicted in (2) from Figure 5:
登録SIP：Example.com SIP/2.0経由：SIP/2.0/UDP 192.168.1.2; rport; branch = z9hg4bknashds7 max-forwards：70 from：bob <sip：bob@example.com>; tag = 7f94778b653b to：bob <<<bob <<sip：bob@example.com> call-id：16cb75f21c70 cseq：1サポート：パス、アウトバウンド連絡先：<sip：bob@192.168.1.2>; reg-id = 1;sip.instance = "<urn：uuid：00000000-0000-1000-8000-aabbccddeeff>"コンテンツレングス：0このSIPトランザクションは、図5から（2）に示されているように、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
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.
応答は、 'ヘッダー（アドレス172.16.3.4）を介して、SIPの「受信」パラメーターに表示されるアドレスに送信されます。応答は、標準のSIP操作に従って、「ヘッダーを介して「ヘッダー」」から推定されるポートに送信されませんが、 'ヘッダーを介してSIPの「rport」パラメーターにスタンプされた値に送信されます（ポート8050）。NATを正常に通過するための応答のために、RFC 3581 [RFC3581]で定義されているすべての慣習は従うことです。「reg-id」と「sip.instance」の両方の連絡先パラメーターの両方に注意してください。[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レジスタリクエスト/応答のトラバーサルでは、[RFC5626]で定義された手順を超えて、追加のコアSIPシグナリング拡張機能は必要ありません。SIP応答は、（1）最初のレジスタリクエストのために作成された接続を再利用します。
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 Message 2:
登録SIP：Example.com SIP/2.0経由：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レジスタサポート：パス、アウトバウンド連絡先：<sip：bob@192.168.1.2; Transport = tcp>; reg-id = 1;sip.instance = "<urn：uuid：00000000-0000-1000-8000-aabbccddeeff>"コンテンツレングス：0メッセージ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
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」コンタクトヘッダーパラメーターを含めることを示すために含まれていました。これにより、将来のインバウンドリクエストの前の例で説明されているように、新しく作成された登録バインディングに向けられた将来のインバウンドリクエストの唯一の違いは、UDPピンホールバインディングではなくTCP接続との唯一の違いを作成します。
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の形式で文書化される例の1つの例のみが行われます。
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の前の例に基づいています。主な違いは、レジスタリクエストがプロキシサーバーから分離されたレジストラまで以降にルーティングされることです。注意すべき重要なメッセージは、図7の（1）です。「sip.instance」メディア機能タグを含むレジスタリクエストを受信すると、[RFC5626]で説明されている一意のフロー識別子トークンを形成します。この時点で、プロキシサーバーはSIPレジスタメッセージをレジストラにルーティングします。プロキシは、共同配置の例と同じ瞬間にSIPアウトバウンドで説明されているように接続タプルを作成しますが、後続のメッセージはプロキシに到達するためには、プロキシはSIPシグナリングパスにとどまる必要性を示す必要があります。これを実現するために、RFC 3327 [RFC3327]で定義されているように、プロキシはメッセージ（2）を登録してメッセージ（2）を登録します。以前に作成されたフローアソシエーショントークンは、パスヘッダー内の位置に挿入され、登録バインディングにルーティングされるメッセージを受信するときに後の時点で簡単に取得できます（この場合、SIP URIのユーザー部分）。（1）の登録メッセージには、Edgeプロキシ用の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
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
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とともにパスヘッダーが保存され、レジストラでそれに関連するバインディングが行われます。パスヘッダーに含まれるURIは、レジストラに到着し、関連するAORバインディングに向けられた任意の要求に、プリロードされたSIP「ルート」ヘッダーとして挿入されます。これにより、新しい登録のすべての要求がEDGEプロキシに転送されることが保証されます。この例では、Edgeプロキシによって挿入されたSIP「パス」ヘッダーURIのユーザー部分には、クライアントへのフローを識別する一意のトークンが含まれています。その後のリクエストを受信すると、Edgeプロキシは、SIPアウトバウンド仕様[RFC5626]で定義されているように、接続タプル比較で使用するために、ロードされたSIPルート 'ヘッダーのユーザー部分を調べ、ユニークなフロートークンを抽出します。このシナリオ（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を介してプロキシサーバーに送信される招待リクエストを生成します。招待メッセージは図8に（1）で表され、次のとおりです。
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: ...
[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. まず、セクション5.1.1.1の登録例と同様に、このリクエストへの回答は自動的にNATを通過しないため、セクション4.1.1（「対称応答」に記載されているように、「ヘッダー」 'ヘッダー' rport 'を介してsipが含まれています。"）および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）では、プロキシは「via」ヘッダーに挿入され、「rport」ポート番号を追加し、「以前の」via 'ヘッダーで「受信」パラメーターを追加し、「ルート」ヘッダーを削除し、レコードルーテを挿入します。トークン付き。
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: ...
[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応答をトラバースANATにするために対称応答[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シグナリングは、トランスポートプロトコルによって直接影響を受けないため、シナリオの例の1つだけが必要です。この例では、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:
招待状リクエストは、セクション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: ..
[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 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: ..
[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.
これは、追加の機能なしの標準的なSIP Inviteリクエストです。主な違いは、標準的なSIPルールが強制されるため、このリクエストはリクエスト-RIで指定されたアドレスに転送されないが、登録バインディングに関連するフローに送信されることです（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シグナルは、輸送プロトコルによって直接影響を受けることはないため、シナリオの例の1つの例のみが必要です。この例では、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:
招待状リクエストは、セクション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: ..
[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 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: ..
[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:
その後、リクエストはクライアントのアウトバウンドプロキシに到着します。プロキシは、「パス」ヘッダーSIP URIのユーザー部分に以前に挿入されたフロートークンと併せて招待状のリクエスト-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: ..
[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.
これは、オリジネーターに追加の機能がない標準的なSIP招待リクエストです。主な違いは、この要求は、標準的なSIPルールが強制されるため、アウトバウンドプロキシに到達したときにリクエスト-URIで指定されたアドレスに従わないことですが、ルートヘッダーに示されているように登録バインディングに関連するフローに送信されることです。（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:
フロー図では、次のように簡単にするためにスタンメッセージに注釈が付けられています。
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 「MAP」属性は、サーバー反射（XOR-Mapped-Address Stun属性）トランスポートアドレスを表します。
o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN attribute) transport address.
o 「Rel」属性は、リレー（リレーアドレススタン属性）輸送アドレスを表します。
The meaning of each STUN attribute is extensively explained in the core STUN [RFC5389] and TURN [RFC5766] specifications.
各スタン属性の意味は、コアスタン[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属性も含まれています。個々の属性に関する詳細情報は、コア氷の仕様[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 Public）、「Priv」（Private）、および「Stun-Pub」（Stun公開）が使用されます。同じネットワーク要素から複数のアドレスを許可するために、各表現に数字が続くこともあります。これらは組み合わせて使用することもできます。たとえば、「l-nat-pub-1」は左側NATのパブリックネットワークアドレスを表し、「r-nat-pub-1」はNATの右側のパブリックネットワークアドレスを表します。「L-PRIV-1」はNATの左側のプライベートネットワークアドレスを表し、「R-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'.
また、例の間に、輸送住所の明示的な部分を示すことが適切かもしれないことにも注意する必要があります。これは、表現の最後に「.address」または「.port」タグを追加することで達成されます。たとえば、「l-priv-1.address」および「l-priv-1.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の背後にあるコールを開始および受信した例を示しています。スタンと氷の両方に例が含まれており、氷は媒体トラバーサルの推奨メカニズムです。
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.
現時点では、ホストがエンドポイント非依存フィルタリングNATまたはエンドポイントに依存しないマッピングNAT [RFC5780]の背後にあるかどうかを判断する信頼できるテストはありません。。このため、このセクションで説明したメカニズムよりも氷が推奨されます。
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]で定義されているように、「結合発見」スタンの簡略化された例を提供します。スタンメッセージは簡素化されており、一時的なユーザー名とパスワードを取得するために使用される「共有秘密」リクエストは含まれていません。
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.
次の例は、スタン「結合発見」使用量を使用して、エンドポイントに依存しないマッピングプロパティを備えた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クライアントは、クライアントデバイスがマッピングを取得したいソースアドレスとポートを強調する（1）に示されている標準の「バインディングディスカバリー」要求を生成します。「バインディングディスカバリー」リクエストは、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を横断し、パブリックスタンサーバーに向かってパブリックインターネットに分割します。「バインディングディスカバリー」要求のソースアドレスは、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）。このメッセージには、XORマップされたパブリックアドレス（Stun Xor-Mapped-Address属性に含まれる）の詳細が含まれています。）。
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を通過し、新しいXORマップアドレスをクライアントに提示します（4）。この時点で、2番目のローカルアドレスの2番目のXORマップアドレス（（5） - （8）に示すように）を取得するためにプロセスが繰り返されます（アドレスは「L-PRIV-1」から「L-」に変更されました。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 Inviteメッセージ（9）を作成するようになりました。SIPのトラバーサルはこの例ではカバーされておらず、セクション5.1で説明していることに注意してください。招待リクエストは、以下のSIP招待の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
V = 0 O =テスト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
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-1.address）。RTPの主要なポートは、SDPにも挿入されています（M = Audio $ nat-pub-1.port RTP/AVP 0）。最後に、追加の「結合発見」から得られたポートは、RTCP（a = rtcp：$ nat-pub-2.port）のトラバーサルのためにRTCP属性（セクション4.2.2で説明されている）に配置されます。
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）をセットアップします。左手のクライアントは、招待への200 OKがクライアントに到着するとすぐにメディアを送信することに注意してください（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.
スタン「バインディングディスカバリー」使用法を使用してエンドポイント非依存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音声セッション（SIP Invite Request）への招待状を受信すると、ユーザーエージェントは、メディアを受け取る適切なポートでローカルスタンクライアントを起動します。Stunクライアントは、クライアントデバイスがマッピングを取得したいソースアドレスとポートを強調する（3）に示されている標準の「バインディングディスカバリー」要求を生成します。「バインディングディスカバリー」リクエストは、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リクエストのソースアドレスは、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）。このメッセージには、原始クライアントがメディアを受信するために使用するマッピングされたパブリックアドレス（Stun Xor-Mapped-Address属性に含まれる）の詳細が含まれています（（5）から「Map = Nat-Pub-1」を参照）。
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を通過し、クライアントに新しいXORマップアドレスを提示します（6）。この時点で、2番目のローカルアドレスの2番目のXORマップアドレス（（7） - （10）に示されているように）を取得するためにプロセスが繰り返されます（ローカルポートが変更され、L-PRIV-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 クライアントは、元のSIP Inviteリクエストに応じて、SIP 200 OKメッセージ（11）を作成するようになりました。SIPのトラバーサルはこの例ではカバーされておらず、セクション5.1で説明していることに注意してください。SIP暫定的な応答も簡単にするために除外されます。200 OK応答では、以前のSTUNトランザクションで取得したアドレスを使用して、以下に示すようにSIP 200 OKのSDPに入力します。
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
V = 0 O =テスト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
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 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).
o 最初の「バインディングディスカバリー」トランザクションから取得したXORマップアドレスは、SDPの接続アドレスとして挿入されていることに注意してください（C = NAT-PUB-1.Address）。RTPの主要なポートは、SDPにも挿入されています（M = Audio Nat-Pub-1.port RTP/AVP 0）。最後に、2番目の「結合発見」から得られたポートは、RTCP（A = RTCP：NAT-PUB-2.port）のトラバーサルのためにRTCP属性（セクション4.2.2で説明されている）に配置されます。
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）をセットアップします。左手クライアントは、200 OKが招待状がユーザーエージェントクライアント（UAC）（11）に送信されるとすぐにメディアを送信することに注意してください。この時点まで、右側のクライアントからの着信メディアは、ファーエンドクライアントとのアウトバウンドアソシエーションが作成されていないため、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のメディアトラバーサルの好ましいソリューションは、NATタイプに関係なくセクション4.2.3.3で説明されているように、ICEを使用しています。次の例は、セッションを開始する際のエンドポイントに依存しないNATのトラバーサルを示しています。この例は、「結合発見」とターンに関連して氷のみをカバーしています。ターンサーバーは、スタン機能（パブリックマッピングを学習するため）とターン機能（メディアリレー）の両方を提供することに注意する価値があります。また、セクション5.2.1.2.1で説明した例では、SIPクライアントLとRが同じターンサーバーに連絡していることも注目に値します。これは、氷、スタン、機能へのターンには必要ありません。必要なのは、スタンとターンサーバーがインターネット上でアクセス可能な同じアドレス指定ドメインにあることです。
The following example demonstrates an initiating traversal through an Endpoint-Independent NAT using 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：氷のあるエンドポイントに依存しない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クライアントは、クライアントデバイスがマッピングの取得を希望するソースアドレスとポートの組み合わせを強調する図13から（1）に示されているターンアラケートリクエストを生成します。割り当て要求は、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 Alocateメッセージ（2）は、パブリックターンサーバーに向かってパブリックインターネットに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 ターンサーバーは、割り当てリクエストを受信し、適切に処理します。これにより、割り当て応答が生成され、返されることが成功します（3）。このメッセージには、メディアを受信するために発信元クライアントが使用するサーバー反射アドレスの詳細（（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.
o Alocate Responseは、初期Alocateリクエストによって作成されたバインディングを使用してNATを通過し、新しいマッピングアドレスをクライアントに提示します（4）。図13の（5） - （8）に示されているように、プロセスが繰り返され、2番目のスタン導出アドレスセットが取得されます。この時点で、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 Inviteメッセージ（9）を作成するようになりました。Inviteリクエストは、SIP InviteのSDPに入力するために、以前のスタン/ターンインタラクションで取得したアドレスを使用します。これは、図14に示すように、氷の仕様[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
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は、組み立てられたすべての利用可能な候補を含めるように構築されています。候補者の最初のセット（Foundation $ L1で識別）には、最優先事項が最も高い2つのローカルアドレスが含まれています。また、SDPの接続（c =）およびメディア（m =）行にエンコードされます。Foundation $ L2で識別される2番目の候補セットには、RTPとRTCPトラフィックの両方でSTUNサーバーから得られた2つのサーバー反射アドレスが含まれています（候補ID $ L2によって識別）。このエントリには、クライアントがペア$ 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）をセットアップします。候補者のアドレスを広告する際に、クライアントは、広告された各候補者アドレスでローカルスタンサーバーを実行している必要があります。これは、着信スタン接続チェックに応答する目的です。
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 Request（10）クライアントRは、適切なアドレス/ポートの組み合わせでローカルSTUNサーバーを起動し、SDPにエンコードされる潜在的な候補アドレスを収集します（元のクライアントが行ったように）。手順（11-18）には、クライアントRと同じ手順を実行するクライアント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
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のFoundation 1はユーザーエージェントRのFoundation 1とペアになり、ユーザーエージェントLのFoundation 2はユーザーエージェントRのFoundation 2とペアになり、最終的にユーザーエージェントLのFoundation 3はユーザーエージェントRのFoundation 3とペアになります。LとRには、完全な候補チェックリストができました。両方のクライアントは、ICEで提供されるアルゴリズムを使用して、候補のペアの優先順位を決定し、優先順位の減少のリストに分類します。この例では、ユーザーエージェントLとRの両方に、最初にホストアドレス（Foundation $ L1）を指定し、次にサーバー反射アドレス（Foundation $ L2）、最後にリレーアドレス（Foundation $ L3）を指定するリストがあります。すべての候補ペアには、氷で指定されているような準州があります。この段階では、ユーザーエージェントLとRのすべての候補ペアが「凍結」状態に初期化されます。その後、ユーザーエージェントはリストをスキャンし、候補者を「待機」状態に移動します。この時点で、両方のクライアントは定期的に、最高候補のペアの優先順位から始めて、地元の候補者からリモート候補者（候補者のペア）にスタンチェックを発行するリストを下って作業します。リスト内の各ローカル候補者からスタンチェックが試行されると、候補者は「進行中」に移行します。（23）に示されているように、クライアントLは、チェックリストの最優先事項のために、200 OK（20）のSDPで受信したリモート候補アドレスを検証するために、スタン接続チェックを構築します。SDPのアクティブアドレスでプライベートアドレスが指定されていたため、スタン接続チェックは目的地に到達できず、スタン障害が発生します。クライアントLは、この候補ペアの状態を「失敗」に移行します。それまでの間、クライアントLは、2番目に高い優先度（24）で返されたSDPで2番目の候補ペアのスタン接続チェックを試みています。メッセージ（24）から（29）からわかるように、スタンバインドリクエストは成功し、接続チェックの肯定的な結果を返します。クライアント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）によるスタン接続チェックに対する応答が成功すると、逆方向に暫定的なチェックが行われます。これはメッセージ（31）から（36）によって示されています。このチェックが成功すると、ユーザーエージェントRは適切な候補者の状態を「成功」に移行でき、メディアを送信できます（RTP）。以前（31-36）は、適切な候補ペアを使用して接続性を達成できることを両側（ユーザーエージェントLおよびR）で確認するチェック確認を記述しました。ユーザーエージェントLは、制御クライアントが候補ペアの別の接続チェックを送信するようになりました。今回は、選択した候補を信号するためにICEで指定されている「ユースキャンディデート」属性を含む。この交換は、メッセージ（37）から（42）に示されています。
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で使用するために選択された「Foundation」の名前が付けられたコンポーネントのパート2の同じ接続チェックを完了します。候補コンポーネントのパート2の接続チェックは、L（43-48）およびR（49-54）に示されています。これが成功すると、コントロールクライアントが候補ペアの別の接続チェックを送信するため、ユーザーエージェントL。今回は、コンポーネント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）が提供者（クライアントL）から新しいアクティブな候補者を代表する応答者（クライアントR）に送信されます。。新しいオファーは次のように見えます：
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
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
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.
このセクションでは、スタンテクニックを使用することはNATの移動の好ましいメカニズムであるが、すべてのケースを解決しないことを強調しています。基本的なスタンを単独で使用することは、すべての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：スタンを備えたアドレス/ポート依存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).
o 図18では、NATの背後にあるクライアントは、このドキュメントの以前の例で使用されている標準的なスタンメカニズム（1） - （4）を使用してサーバー反射表現を取得します（例：セクション5.2.1.1.1）。
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リクエスト（5）に含まれる発信SDPでも使用されます。
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を介してメディアを通過するという発信招待リクエストで提供された反射アドレスを使用しようとするときに発生します。
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は、（7）および前（8）の後にNATでドロップされたメディアを示しています。これにより、一方向のオーディオが発生します。
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で失敗します。ターンエクステンション[RFC5766]は、このシナリオに対処します。ターンはスタンを拡張して、クライアントが再帰表現ではなく、ターンサーバーでリレーしたアドレスを要求できるようにします。これにより、NATトラバーサルのパスにメディアリレーが導入されます（セクション4.2.3.2で説明されています）。次の例では、Stunを使用してアドレス/ポート依存NATを通過するためにStunを使用した場合の以前の障害をターンする方法を説明しています。ICEと組み合わせて使用すると、ターンが最も効果的に機能することに注意する必要があります。すべてのメディアがターンサーバーを介して中継される場合、独自の結果を使用する。これは効率的ではありません。
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：ターンを伴うアドレス/ポート依存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は、STUNサーバーでリレーアドレスを取得するために、ターンを割り当てるリクエスト（1）を発行します。リクエストはアドレス/ポート依存NATを通過し、スタンサーバーに到達します（2）。STUNサーバーは、クライアントのサーバー反射アドレス（MAP = NAT-PUB-1）とリレーしたアドレス（REL = Stun-Pub-2）の両方を含む割り当て応答（3）を生成します。リレーしたアドレスは、割り当てリクエストによってNATで開かれたパブリックピンホールにバインドされているスタンサーバーのアドレスマッピングにマップされます。これにより、ターンサーバーに送信されたトラフィックが任意のトラフィックをリレーしたアドレス（rel = 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 ターン派生アドレス（Stun-Pub-2）は、割り当ての応答で発生するクライアント（4）に戻ってきます。このアドレスは、次の例に示すように、発信SIP Inviteリクエストのために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
V = 0 O =テスト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
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 招待リクエストを受信すると、ユーザーエージェントサーバー（UAS）は、STUNサーバーでメディアとRTCPをリレーアドレス（Stun-Pub-2およびStun-Pub-3）にストリーミングできます。図19（メッセージ（12）と（13）の間に示すように、UASのメディアはスタンサーバーの中継アドレスに向けられます。スタンサーバーは、アドレス/ポート依存のオープンピンホールにトラフィックを転送します。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ケースにターンを使用するソリューションを使用する問題を強調しています。セクション4.2.3.3で詳述されているように、NATのすべての品種を通過するための推奨メカニズムはICEを使用しています。ICEは、コアスタン、ターン、およびその他のメカニズム（たとえば、NAT-PMP [NAT-PMP]、UPNP IGD [UPNP-IGD]）を使用して、メディアトラフィックに使用できる優先順位のあるアドレスのリストを提供します。氷の詳細な例は、セクション5.2.1.2.1に記載されています。これらの例は、エンドポイントに依存しないタイプNATに関連付けられていますが、アドレス/ポート依存型NATを含むNATタイプのバリエーションに適用できます。実行される氷の手順は同じです。候補者アドレスのリストの場合、クライアントは、スタン接続チェックと関連する優先度（最高優先勝利）の結果に応じてメディアを送信する場所を選択します。NATを表示するアドレス/ポート依存性のプロパティを含めることは、自動的に中継されたメディアにつながっていないことに注意する必要があります。実際、氷の処理は、アドレス/ポート依存特性を使用して、両方ともたまたまNATの背後にいる2つのクライアントを除き、メディアリレーの使用を避けます。この場合、接続チェックと関連する選択アルゴリズムがトラバーサルを有効にします。図20および次の説明では、これが氷の接続性チェックを使用してどのように達成されるかについてのガイドを提供します。これは、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招待リクエストを受け取っており、クライアントLとの接続チェックを開始しています。クライアントRは接続チェック（1）を生成し、SDPオファーに提示されたクライアントLの情報に送信します。リクエストは、クライアントLのアドレス/ポート依存NATに到着し、NAT結合がないため、通過できません。これにより、接続チェックが故障状態に移動します。それまでの間、クライアントLはSIPリクエストでSDP回答を受け取り、接続性チェックも開始します。小切手がクライアントRに派遣されます（3）。チェックは、以前に失敗したチェック（1）に設定された関連付けにより、NATを通過できます。完全なバインドリクエスト/応答は、手順（3） - （8）に表示されます。候補ペアの一部として、クライアントRは、ステップ（9） - （14）に示されているように、チェックを正常に完了できるようになりました。その結果、メディアを中継する必要なく使用できる候補者の成功ができます。
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を横断する例が含まれており、プライベートネットワークとパブリックネットワークのホスト間の通信を可能にしますが、決してそのようなシナリオに限定されていません。同じNATトラバーサル技術を使用して、不均一なネットワーク環境で通信を確立することもできます。たとえば、IPv4ホストとIPv6ホストの間の通信。
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のメンバーがコメントと提案についてWGをすすりながら感謝したいと思います。テキストを含む専門家のレビューと詳細な貢献は、全体を通して支持的だったダン・ウィングによって提供されました。
Detailed comments were provided by Vijay Gurbani, Kaiduan Xie, Remi Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins, and Hans Persson.
詳細なコメントは、Vijay Gurbani、Kaiduan Xie、Remi Denis-Courmont、Hadriel Kaplan、Phillip Matthews、Spencer Dawkins、Hans Perssonによって提供されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327] Willis、D。およびB. Hoeneisen、「Addjacentコンタクトを登録するためのセッション開始プロトコル（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.、Frederick、R。、およびV. Jacobson、「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] Rosenberg、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。、「セッション説明プロトコル（SDP）のリアルタイムコントロールプロトコル（RTCP）属性」、RFC 3605、2003年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961] Wing、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] Rosenberg、J。、「Interactive Connectivity Indecivity（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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761] Perkins、C。およびM. Westerlund、「単一のポートの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] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NAT周辺のリレーを使用したトラバーサル：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.、Mahy、R。、およびB. Tate、「セッション開始プロトコル（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] Cheshire、S。、「NATポートマッピングプロトコル（NAT-PMP）」、2008年4月の作業。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010.
[RFC5780] MacDonald、D。およびB. Lowekamp、「NAT（STUN）のセッショントラバーサルユーティリティを使用したNAT行動発見」、RFC 5780、2010年5月。
[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.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「セッション開始プロトコル（SIP）セッション国境管理（SBC）の要件」、RFC 5853、4月2010年。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157] Camarillo、G.、El Malki、K。、およびV. Gurbani、「セッション開始プロトコル（SIP）におけるIPv6遷移」、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-Technologies
EMail: chris@ns-technologies.com
Jonathan Rosenberg Skype
ジョナサン・ローゼンバーグ・スカイプ
EMail: jdrosen@jdrosen.net
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Francois Audet Skype
フランソワ・オーデット・スカイプ
EMail: francois.audet@skype.net