TURN
これに対し、ChannelBindによる手法は軽量であり、ヘッダは4バイトのみであるしかし、チャネルを確保しておく必要があり、そのために定期的にリフレッシュが必要である。
SendまたはChannelBindのどちらの手法を使うにせよ、TURNサーバはクライアントからデータを受け取り、UDPデータグラムを使って宛先に転送する。データの中にはソースアドレスとして、割り当てられた転送用トランスポートアドレスが含まれている。宛先はデータを受け取り、再びUDPデータグラムを転送プロトコルとして用いてTURNサーバのリレー用アドレスに送る。
TURNサーバは宛先からUDPデータグラムを受け取り、認証をチェックしもし正当であれば、これをクライアントに送る。
この方法により、対称型NATの問題を回避することができる。クライアントと宛先の双方とも転送用に割り当てたIPアドレスを持つTURNサーバに対してだけ通信を行えばよいためである。
様々なNATを超えた通信ができるという意味で、TURNはSTUNよりも堅牢であるがTURNでは全通信がTURNサーバを経由するため、STUNプロトコルよりもサーバに必要なバンド幅が大きい。そのため、ICEプロトコルにおいては、まず最初にSTUNを採用することが必須条件であり、TURNは対称型NATやその他のSTUNでは解決できない状況を解決するために用いられる。
データ転送のためにクライアントコンピュータが宛先のコンピュータに通信するとき、クライアントと宛先の双方がそれぞれNATの背後にいて、通信ができないという状況が始まりである。対称型NAT(STUNと互換性のないNATタイプ)の場合、TURNを用いなければならない。
最初、クライアントはTURNサーバに「割り当て (Allocate)」要求を出す。割り当て要求とは、クライアントが宛先に通信するためにTURNサーバにリソースを割り当てることを依頼するものである。もし割り当てが可能ならば、TURNサーバはリレー用のアドレスを割り当てたうえで、クライアントに対し「Allocation Successful」レスポンスを返す。このレスポンスの中にはリレー用にTURNサーバに割り当てたトランスポートアドレスが入っている。
次に、クライアントはTURNサーバに対し、CreatePermission要求を出し、宛先とTURNサーバ間の通信のための認証システムを作ることを要求する。このチェックシステムは、サーバが宛先に通信し、宛先からリレーのためにTURNサーバに送り返してきた情報が、正当な通信であることを確認するために用いる。
通信が許可された後、クライアントには実際のデータを送るにあたって、2つの選択肢がある。
Send機構を使う。
ChannelBind要求を出し、チャネルを確保する。
Send機構は直接的な方法であるが、36バイトと大きなヘッダを必要とし、TURNによるリレー通信のためのバンド幅を無視できない程度に増加させてしまう。
NAT (Network Address Translators) には多くのメリットがある一方で、多くの欠点も持っている。一番厄介な欠点は、多くの現存するIPアプリケーションに弊害をもたらし、また新しいIPアプリケーションの普及に障害となることである。どのようにすればNATの下でも機能するプロトコルが作れるかを記述したガイドラインが数多く開発されてきた。しかし、多くのプロトコルがそれらのガイドラインに沿って作ることができなかった。構築できなかったプロトコルの例としては、マルチメディアアプリケーションやファイル共有関連のプロトコルがある。
STUN (Session Traversal Utilities for NAT) は、アプリケーションがNATを越えるための1つの方法を提供する。STUNはクライアントがピアからのパケットを受信するために利用するトランスポートアドレス(IPアドレスとポート)を入手することを可能にする。しかしながら、STUNによって入手されたアドレスはすべてのピアに対して利用可能ではないかもしれない。