1. Introduction (はじめに)
NAT の背後にあるホストは、他のホストとパケットを交換したい場合があります。これらのホストの一部も NAT の背後にある可能性があります。これを実現するために、関係するホストは「ホールパンチング (Hole Punching)」技術 ([RFC5128] を参照) を使用して、直接通信パス (Direct Communication Path) の発見を試みることができます。つまり、1つ以上の NAT とルーターを通過するが、リレーを経由しない、あるホストから別のホストへの通信パスです。
[RFC5128] と [RFC4787] で説明されているように、両方のホストが適切に動作しない NAT の背後にある場合、ホールパンチング技術は失敗します。例えば、両方のホストがマッピング動作として「アドレス依存マッピング (Address-Dependent Mapping)」または「アドレスとポート依存マッピング (Address and Port-Dependent Mapping)」を持つ NAT の背後にある場合、ホールパンチング技術は通常失敗します。
直接通信パスが見つからない場合、パケットリレーとして機能する中間ホストのサービスを使用する必要があります。このリレーは通常、パブリックインターネット上に存在し、NAT の背後にある両方のホスト間でパケットをリレーします。
本仕様は、TURN と呼ばれるプロトコルを定義します。このプロトコルにより、NAT の背後にあるホスト (TURN クライアント (TURN Client) と呼ばれる) は、別のホスト (TURN サーバー (TURN Server) と呼ばれる) にリレーとして機能するよう要求できます。クライアントは、サーバーが特定の他のホスト (ピア (Peers) と呼ばれる) との間でパケットをリレーするように手配し、リレーの実行方法を制御できます。クライアントは、サーバー上で IP アドレスとポートを取得することによってこれを実現します。これは中継トランスポートアドレス (Relayed Transport Address) と呼ばれます。ピアが中継トランスポートアドレスにパケットを送信すると、サーバーはパケットをクライアントにリレーします。クライアントがサーバーにパケットを送信すると、サーバーは中継トランスポートアドレスを送信元として使用して、適切なピアにリレーします。
TURN を使用するクライアントは、中継トランスポートアドレスをピアに伝達し、各ピアの IP アドレスとポート (より正確には、各ピアのサーバー反射トランスポートアドレス (Server-Reflexive Transport Address)、セクション2を参照) を知る何らかの方法を持っている必要があります (しなければなりません)。これをどのように行うかは、TURN プロトコルの範囲外です。これを行う1つの方法は、クライアントとピアが電子メールメッセージを交換することです。別の方法は、クライアントとそのピアが特別な目的の「導入 (Introduction)」または「ランデブー (Rendezvous)」プロトコルを使用することです (詳細については [RFC5128] を参照)。
TURN が ICE [RFC5245] と共に使用される場合、中継トランスポートアドレスとピアの IP アドレスおよびポートは、ランデブープロトコルが運ばなければならない候補情報に含まれます。例えば、TURN と ICE が SIP [RFC3261] を使用するマルチメディアソリューションの一部として使用されている場合、SIP がランデブープロトコルの役割を果たし、SIP メッセージ本文内に候補情報を運びます。TURN と ICE が別のランデブープロトコルと共に使用される場合、[MMUSIC-ICE-NONSIP] がランデブープロトコルが実行しなければならないサービスに関するガイダンスを提供します。
NAT の背後にある2つのホスト間の通信を実現するために TURN サーバーを使用することは非常に成功する可能性が高いですが、サーバーは通常インターネットへの高帯域幅接続を必要とするため、TURN サーバープロバイダーには金銭と労力の両方がかかります。したがって、直接通信パスが見つからない場合にのみ TURN サーバーを使用することが望ましいです。クライアントとピアが ICE を使用して通信パスを決定する場合、ICE はまずホールパンチング技術を使用して直接パスを検索し、直接パスが見つからない場合にのみ TURN サーバーを使用します。
TURN は、SIP を使用してシグナリングされるマルチメディアセッションをサポートするために元々発明されました。SIP がフォーキング (Forking) をサポートしているため、TURN は中継トランスポートアドレスごとに複数のピアをサポートします。これは、SOCKS [RFC1928] などの他のアプローチではサポートされていない機能です。ただし、TURN が他のタイプのアプリケーションにも適していることを保証するよう注意が払われています。
TURN は、より大きな ICE NAT トラバーサルソリューションの1つのコンポーネントとして設計されています。TURN の実装者は、ICE を調査し、アプリケーションでの使用を真剣に検討することを強く推奨します。ただし、ICE なしで TURN を使用することも可能です。
TURN は、STUN (Session Traversal Utilities for NAT) プロトコル [RFC5389] の拡張です。ほとんど (ただしすべてではない) の TURN メッセージは、STUN 形式のメッセージです。本文書の読者は、STUN に精通していることが求められます。