MCU入門第9回　NAT/FW トラバーサル　4. テレビ会議通信の仕組み

MCU入門　第9回

NAT/FW トラバーサル
- 4. テレビ会議通信の仕組み

2011年9月掲載

MCU入門第9回　NAT/FW トラバーサル　目次

Web会議の場合

Web会議は、PC上のWebブラウザを使って、遠隔会議をする方法です。 Webブラウザを使うので、「Web会議」と称されることが多いです。

技術的にも、サーバーのポートは、TCPの80番と443番のみを使います。TCP80番ポートはHTTPとして、TCP443番ポートはHTTPS（HTTP over SSL)として、一般的に利用されるポートです。 Webサーバーが入っているDMZ*に設置してあるFirewallでは、この２つのポートは外部から接続できるように設定してあることがほとんどです。このため、通信がFirewallに邪魔されることはありません。

また、NAT/NAPTも問題ありません。ルーターのNAT/NAPT機能によって、IPアドレスないしはポート番号が書き換えられても、通信が阻害されることはありません。 NAT/FWを越えるためには、Web会議はとても優秀な手段と言えるでしょう。

*DeMilitarized Zone：非武装地帯を意味する。ICTの世界では、ローカルネットワークの外に位置しさらにその外側とはFirewallで守られたネットワーク領域をいう。

H.323の場合

H.323は、ITU-Tによって標準化された手順を使い、IP上で通信を行うテレビ会議システムのプロトコルです。もともとは、H.320というISDN上で行うテレビ会議の仕組みから発展させたものです。
実は、H.323が標準化された当初には、まだNATの仕様が固まりきっていませんでした。 NATの仕様が固まった後の2005年に、H.323システムのNAT/FW越えに対応するための規格「H.460.18/19」が標準化されました。
これは、DMZないしはグローバルIP上に、「トラバーサルサーバー」を設置し、これを仲介として、H.460.18/19搭載のH.323端末間通信を成り立たせるものです。

なぜ、トラバーサルサーバーという大げさな仕組みが必要なのでしょうか？それは、「返信宛先」の考え方がWebとは異なるためです。
Web会議の場合、IPパケットのヘッダにある「送受信宛先情報」をルーターのNAT/NAPT機能が書き換えることで、接続が成り立つというお話をしました。H.323の場合、返信宛先は、IPヘッダのものではなく、IPコンテナの部分に書いてある「送受信宛先情報」を利用します。IPコンテナ部分の情報を、ルーターは書き換えることが通常はできません。
このため、IPコンテナの情報を信じて、相手が返信をしようとしても、元のところまでパケットが戻っていかないのです。つまり、NAT越えができないのです。

また、NAPTでも問題があります。 UDPで送受信されるデータのポート番号が、ルーターのNAPT機能によって変換されたら、端末までデータが戻ってきても、受け取るべきポートとは異なるポートに届けられる可能性があります。異なるポートに届いたデータは、受け取ることができないため、捨てられてしまいます。映像音声を再生することができなくなります。

そして最後にFWでも問題があります。お互いにどのUDPポートを使って映像音声のデータを送受信しましょう、というやりとりは、TCPの上のH.245通信制御プロトコルで行うので、両端末の合意は問題ありません。しかし、UDPのポートはその場のやりとりで決まるので、通常は外部に公開されていないポート番号が設定されます。このため、映像音声のデータの送信をしてもFWで止められることがあります。

これらをまとめて解決するH.460.18/19が標準化され、トラバーサルサーバーが発売されるようになるまで、H.323でのNAT/FW透過は、けっこう大変だったのです。

大変だった理由の１つに、テレビ会議としてのポリシーの違いがあります。それは、TCPを利用するか、UDPを利用するか、という違いです。TCPを利用すれば、NAT/NAPTに対応するのは容易です。WebはTCPなので、Web会議はNAT/NAPTに対応することが容易ということになります。しかし、TCPは、パケットが消失したりネットワーク遅延を起こした場合、データの再送要求を行います。このため、データが届ききるまで再生を待つ必要があります。待つ必要がある、ということは、それだけ再生遅延が発生する可能性が高い、ということです。特に、高解像度の映像を利用するときは、それだけデータ量が多いことになりますので、待つ時間が長くなります。

UDPを利用すれば、再生遅延の発生の可能性はぐっと減ります。 UDPは、相手が受け取っているかどうかを確認せず、データを送り続けるというプロトコルだからです。しかし、先に述べたように、NAT/NAPTに対応することが大変です。

両者は、それぞれの特性を活かすために、NAT/FWを透過することを優先するWeb会議、低遅延・高解像度を優先するH.323会議、という住み分けができています。

また、今までは、TCPでしかNAT/NAPTトラバーサルを行うことは難しかったのですが、最近では、ICE/STUN/TURN**というUDPトラバーサルの仕組みも実装が進んできています。

** ICE (Interactive Connectivity Establishment)は、SIPのようにSDPオファー・アンサーモデルを用いるマルチメディア通信のためのNAT越えを規定する。 STUN (Session Traversal Utilities for NAT)はNATのアドレス変換を把握するプロトコル、TURN (Traversal Using Relays around NAT)はメディアの中継を可能にするプロトコルで、両者はICEに使われる。

ハイブリッド型の場合

この両者の特性を、同時に活かすことができたら、いいと思いませんか？たとえば、Avaya社の SCOPIA Desktop server （以下SDS）というユニークなアプローチがあります。これは、H.323-Web会議ゲートウェイともいうべきサーバーで、Webブラウザベースで利用します。

これは、H.323の世界では、端末同士がUDPで接続しあう、NAT/FWは基本的には越えない構成でかまいません。出張先からPCで接続したいという場合には、SDSを通じてH.323の世界と接続を行います。 SDSは、TCPないしUDPでの、NAT/NAPT/FWトラバーサル機能を備えているので、H.323端末がないところでも、PCからWebブラウザ越しに会議に参加できます。

さて、来月はMCU入門の最終章です。これまでは、MCUや関連機器の技術的説明をしてきました。しかし、どんなシステムを構成しても、運用するのは人間です。人が使いやすいシステムでないと、使い続ける意味がありません。その中でも、「不具合が起きてしまったときに、どのように対処するか」「接続拠点が増えたり、使い方を変えようと思ったときどうするか」という変化への対処が、実は運用でもっとも重要な点です。運用を改善していくための “攻めの保守” について、次号ではお話をしたいと思います。
2011年10月にアップロード予定ですので、お楽しみに！