VoIP/WebRTC技術者のためのSTUN/TURN サーバー解説。その１. STUN/TURN サーバーとは？
今回から複数回にわたり、VoIPやWebRTCが抱える問題点とSTUN/TURNを利用したその解決方法について解説していきます。また具体的な説明にはオープンソースのSTUN/TURNサーバーである“COTURN”を使用します。
1.STUN/TURNサーバーとは？
ネット上ですぐに調べられますので概念の詳細については割愛します。ここでは以下のように覚えておいてもらえればOKです。
STUN (Session Traversal Utilities for NAT) ->外部 (NATの外側) にあり、NAT内部のノード(A)から問い合わせがあると、外部から見えたそのノード(A)のIPアドレスを返してあげるもの。そのため、ノード(A)は外部から見える自身のIPアドレスを相手ノード(B)に伝えることができ、その結果、これらのノード間で直接データのやり取りを行うことができる場合があります。
TURN (Traversal Using Relay around NAT) ->外部(NATの外側) にあり、ノード(A)とノード(B）の間に立ち、データをリレーしてあげるもの。そのため、ノード(A)とノード(B)がそれぞれ別のNAT内部にあり直接データのやり取りができなくともTURN経由で可能となります。
両プロトコルとも主にNATやファイアウォールを越えて通信することを目的としたインターネットプロトコルです。
2. NATを越えてP2P通信を行う際の問題点と解決策
2-1. P2P通信を行う際、NATを越えられない。-> STUNを使う。
2-2. STUNを使ってもまだNATを越えられない。 -> TURNを使う。
基本的に外部サーバが間に立ちデータをリレーする”TURN”の方が”STUN”よりNATを越える可能性が高くなります。
3. 通常のNAT越え以外の問題点
ipv4-ipv6ネットワークをまたいだP2P通信がうまくいかない。
実際の事例について詳細はこちらの記事参照(アメリカ発、IPv6専用モバイルネットワーク問題。あなたのVOIP機器は大丈夫?)
この事例では携帯電話キャリアが自社のipv6網からipv4インターネットへ接続できるよう、ゲートウェイ(トランスレータ)を提供しています。カスタマーは通常このゲートウェイ経由でipv4ネットワークに接続できます。
しかしながら、WebRTCなどにおいて、シグナリングがうまくいかない例が見られます。上図はシグナリングにSIPを用いた例ですが、キャリアの用意するゲートウェイでipv6<->ipv4は変換されますが、SDPレイヤーの記述までは更新されません。その結果、ipv4アドレスしか持たない相手UAや仲介するコミュニケーションサーバーは「SDP内にipv6アドレスのcandidateが書かれたINVITE」をipv4経由で受信することになってしまいます。これではデータは正しく送信できません。
この解決策として、前回の記事内では、１．CLAT(customer-side translator)の利用と２．各デバイスにおける両ipv4/v6への対応を紹介しました。
しかし今回、第3の解決方法として、TURNサーバにデータをリレーさせることにより、ipv6<->ipv4のコンバート、及びTCP<->UDP※1のコンバートをさせてしまおうというお話です。
こちら、この[解決策3]のデータフローについての模式図です。詳細と実際の構築は次回以降紹介します。
※1.実際のWebRTCではTURNサーバと相手側 (上の図ではcommunication server。サーバを介さず相手のピアクライアントの場合もある)はUDPで行うことが一般的になっています。詳細は次回詳しく説明します。
次回 その２．「さくらのVPS」でつくるSTUN/TURN サーバー(インストール編)＞＞
