9.6 H.323システムのNAT/Firewall越え
1) 問題の所在
H.323テレビ会議システムは，標準として成熟し，製品間の高い相互接続性を実現しています．しかし，端末がNAT（Network Address Translation）環境下にある場合，相手端末と接続自体ができなくなるのが普通です．NATはプライベート網とパブリック網の間にあってIPアドレス変換を行います．IP v4アドレスの総量が限られていて涸渇している事態を解決する手段であると同時に，プライベート網をパブリック網から隔離するセキュリティ対策としても機能します．このため，もう一つのセキュリティ対策，到来するパケットを検査して定められたもの以外は拒絶するファイアウォール（Firewall, FW -- 文字通りは防火壁の意）と共存するのが普通です．
一例として，筆者の家はフレッツ光でインターネットにつながっていますが，家の中はNATのもとにプライベート・アドレスを使用し，そこを経由してパブリック・ネットワークに出てゆきます．その際，外からはブロードバンドルータのグローバル・アドレスが見えるだけです．テレビ会議端末を家の中に持ち込んだとしても，そこからテレビ会議をすることはできません．回線容量的には最大100 Mbit/sまで使えるにもかかわらずです．
これはNAT越え（NAT traversal）問題，あるいはNAT/FW越え（NAT/FW traversal）問題と呼ばれています．H.323の接続プロトコルでは，図9-10で説明しましたように，ペイロードの中に次の接続アドレスが書かれています．NAT配下の端末ではプライベート・アドレスが書かれますが，外からこのアドレスに接続を試みても，つながりません．その様子を図9-15に示します．
一般的なプライベート・ネットワーク - パブリック・ネットワーク - プライベート・ネットワークの構成で，端末が置かれる場所によりNAT/FW越え問題が生じます．両端末ともプライベート・ネットワーク，あるいはパブリック・ネットワーク内の場合を除き，NAT/FW越え対策が必要になります．
そもそも，一般的な
EP (Endpoint) - Private Network - NAT - Public Network - NAT - Private Network - EP
のシステム構成でEP-EP間の通信を確立することは容易ではありません．通常の電話の場合でも，
内線電話 - 構内網 - PBX - 公衆電話網 - PBX - 構内網 - 内線電話
の構成で，相手内線電話を呼び出すには，相手PBX (Private Branch eXchange)のオペレータに頼る，あるいはそれと等価な自動接続手順（代表番号を呼んだ後，アナウンスに基づき相手内線電話番号を投入するなど）に頼ることになります．
電子メールやウェブページ閲覧のようなインターネットのサービスは，上記の一般的なシステム構成でも不都合ないではないか，との疑問が湧いてきます．この場合は，Private Network上のPC ClientとPublic Network上のServerとのTCP接続となり，NAT越えは「来た道を帰る」仕組みで可能になります．すなわち，NATの内側Clientから外のServerに出て行ったとき，そのTCP接続が保たれ，同じアドレスとポート番号にパケットを返すことでServerからClientに向かう通信が保たれます．
それでは，現在ではごく一般的なネットワーク環境でテレビ会議が接続できるように，何故H.323標準化は最初からNAT越え問題を考慮しなかったのでしょうか．
2) H.323標準初版発行時のネットワーク環境
H.323システムの検討は，1993年頃から始まりました．その当時の公衆ディジタルネットワークは64 kbit/sベースのISDNであり，広帯域ネットワークとしてATM技術によるB-ISDNが期待されていました．一方で，企業内のコンピュータ間を接続するパケットネットワークとしてEthernetが広まっていました．このEthernetは10 Mbit/sの速度を持ち，これをテレビ会議のようなオーディオビジュアル通信に使えないか，と考えたのがH.323システム標準化の発端です．企業内ネットワークはその後，Ethernetの上でIPパケット交換網として収束，発展してゆきました．
H.323システムの標準化は1995年に入って本格化し，最初の標準は1996年に承認されました．この当時，企業内のネットワーク環境はグローバル・アドレスの使用が一般的で，筆者自身が働いていたNTT研究所（1994年まで），GCL（1994-1998），早稲田大学（1999〜2012）でも，当初は社/学内ネットワークにグローバル・アドレスを使っていました[9-36]．従って，H.323初版発行時にNAT越えを考えていなかったのは自然な成り行きと言えます．
3) NAT，DHCP利用の一般化
企業内ネットワークで，NATやDHCP (Dynamic Host Configuration Protocol)によるプライベート・アドレスを利用し始めたのは1998年前後と推定されます[9-37]．勿論，研究開発はそれより前の1995-1996年頃と推定され，NATに関する最初のRFC 1631[9-38]は1994年5月に，DHCPに関する最初のRFC 1531[9-39]は1993年10月に発行されています．1996年2月にはRFC 1918 "Address Allocation for Private Internets"[9-40]が出て，これがその後のプライベート・ネットワーク実装に貢献しました．
この時点でH.323標準でもNAT越え問題を検討すべきだったとの反省はありますが，H.323の利用が主にLANの発展形である企業内ネットワークで，NATを越える必要性が少なかったことが，検討の遅れた一因です．
また，NATには，十分な標準化が行われなかったという問題があります．インターネットの設計思想には，グローバルIPアドレスだけで世界中どことでもつながる，との理想像があり，NATは一種必要悪のような存在と見なされていて標準化が行われず，多様なプライベート・アドレスとグローバル・アドレスの対応関係が実装される結果となりました[9-41][9-42]．このことがNAT越え問題を複雑にしたと言えます．
4) H.323の最大ユーザはVoIPサービス・プロバイダ
H.323システムはLAN上のオーディオビジュアル通信システムを実現することから標準化が始まりました．IPパケット網は，もともとe-mailのような非リアルタイムのコンピュータ間通信が起源で，電話のような呼接続の概念はありませんでした．H.323が呼接続プロトコルを用意したことで，IP網を電話サービスに適用するVoIPの産業界から関心を集め，標準化作業が盛り上がりました．
VoIPにおけるH.323の適用は，通信キャリアのバックボーン，企業内ネットワーク，新規参入キャリアのネットワーク（電話サービス提供者）で，これらはいずれも閉じたネットワークでNATは介在しません．従ってCisco社などのVoIP機器・ソフトウェア提供者にとって，NAT越え問題を考える必要はなかったと言えます[9-43]．このこともH.323標準でのNAT越え問題検討が遅れた要因の一つです．
5) H.323におけるNAT越え問題への取り組み
NAT越えがユーザの要望として切実になったのは，上記1)に述べたようなテレビ会議接続で，ITU-Tでは2003年9月，NAT/firewall越え問題に対する作業の開始が決まりました．最初は要求条件の収集とアーキテクチャの議論があり，当面する問題は次のように要約されます[9-41][9-42]．
- 一般にNATの外から内側に向けて接続することはできない．
- NATの振る舞いは標準化されていない．
- ネットワーク管理者は外に開くピンホール（プロトコル，自アドレス，自ポート番号，相手アドレス，相手ポート番号で設定）をできるだけ制限したい．
- 通信経路に含まれるNAT, FW, ALG (Application Level Gateway)の存在を探索し，トポロジーを把握しなければならない．ここでALGとは，アプリケーション（今の場合H.323）のパケット内容を見て，必要なフィールドを書き換えて通信を成立させるシステム構成要素です．
- H.323 ALGは，H.323標準で規定されていないのでその振る舞いは予測できない場合がある．
- H.323端末のトランスポート・アドレスは，IPアドレスとポート番号で構成され，通信の都度設定しうるダイナミック・ポート番号を用いる．このためファイアウォールを通過できない．
- H.323通信には，direct-routed/GK-routed，H.245メッセージのトンネリング有/無，H.225.0メッセージの伝送方法がTCP/H.323 Annex E (reliable UDP)など，数種類のモードがあり，それぞれにNAT/FWとの整合性がある．
2005年2月，Tandberg, Polycom, RADVISIONの3社合同でNAT越えソリューションの枠組みが提案されました．これは，パブリック・ネットワークにサーバ（TS: Traversal Server，SBC -- Session Border Controllerとも呼ばれる）を置いてNAT/firewall越えを行うソリューションです．
この提案の背景には，Tandberg社が2004年5月，英国のfirewall traversal技術を有するRidgeway Systems & Software Ltd.を買収したことがあり[9-44]，その技術をITU-Tに提案することにしたものと思われます．その後の詳細提案は英国Tandberg社のGiles Chamberlin氏（2012年からPexip社）が中心にまとめたことに，それが現れています．
ITU-T勧告としては，2005年7月の会合で，シグナリングのNAT/firewall越え制御がH.460.18[9-45]として，メディアのNAT/firewall越え制御がH.460.19[9-46]として完成し，所定の手続きを経て2005年9月に成立しました．
6) H.460.18, H.460.19 NAT/FW越えソリューション
このソリューションは，既存のNAT/ファイアウォールに手を加えず（ただしNATが外向きの接続を許すことが前提です），ネットワーク管理の特殊技術を要しないことを目標に，設計されました．また，端末装置にハードウェアの追加がなく，ソフトウェアに最小限の変更を行う，もしくはソフトウェア追加部分は端末側にプロクシ・サーバを設けて実装し，端末装置は既存のままとすることとしています．仕組みを図9-16に示します．
パブリック・ネットワークにTS (Traversal Server)を置き，全てのシグナリングとメディアがTSで中継されます．パブリック側からプライベート側に呼接続することは，一般に拒絶されますので，プライベート側とTS間に用意される持続的RASチャネルを用い，プライベート側からシグナリング用TCP接続することを促して行います．
ここで，遠隔エンドポイントBはパブリック・ネットワーク（外側ネットワーク）上に設置されていてもよいし，別のプライベート・ネットワーク（内側ネットワーク）上に設置されていても構いません．後者の場合はNATの後ろに端末装置があるという意味で「見かけ上の」と表記されています．また，シグナリング経路とメディア信号の経路が示しますように，エンドポイント間の全ての信号はTS経由で配送されます．TS (SBC)とゲートキーパは機能的に連携していますが，物理的には共存でも独立でも構いません．
H.460.18/19ソリューションによるH.323通信を図9-17に示します．
このNAT/FW越えソリューションでは，エンドポイントとTSにNAT/FW越えに必要なソフトウェアを追加して実現します．エンドポイント側の追加ソフトウェアはエンドポイント自身に追加することもできますし，プロクシを用意しここに追加してエンドポイントは従来のH.323エンドポイントをそのまま使うこともできます．
このソリューションでは，H.460.18エンドポイントとTSの間で持続的双方向コネクションを確立します．エンドポイントEPAから最初にゲートキーパに向け登録のためのH.225.0 RASメッセージGRQ (Gatekeeper Request)を送出します．そこに含まれる要素rasAddressがゲートキーパから登録受付可のGCF (Gatekeeper Confirm)を返すための宛先になります．このGRQとGCFの交換を通じNAT/FW越えのRASチャネル・ピンホール（ピンホールとは，NAT/FWの内側アドレスと外側アドレスの一時的な紐付けで，その間を双方向にパケットを通過させる）が開かれることになり，これを必要な期間だけkeep-alive（接続を続けるためだけの空パケット）を送るなどして維持します．EPBは通常の手順でゲートキーパに登録されているとします．
次にエンドポイントEPAからゲートキーパにRRQ (Registration Request)を送出して登録を要請し，ゲートキーパはRCF (Registration Confirm)を返します．
エンドポイントEPAが発呼する場合（すなわち内側から外側に向け発呼する場合），ゲートキーパに対し，RASメッセージARQ (Admission Request)を送り，この中に通信相手を指定するdestinationInfo要素が含まれます．ゲートキーパが通信許可を与えるとエンドポイントにACF (Admission Confirm)メッセージを返し，この中にH.225.0呼制御信号を送る宛先destCallSignalAddressの要素が含まれています．この宛先は今の場合ゲートキーパとなり，EPAはこのアドレスにH.225.0呼制御信号送受信のためのTCPコネクションを確立します．
TSは，通信相手EPBとその呼制御信号受信アドレスの情報を持っていますので，EPAからの呼制御信号SETUPがゲートキーパによりEPBに転送されます．同様にEPBからの呼制御信号CONNECTがゲートキーパに返され，その中に次のフェーズであるH.245メッセージ交換のアドレス，h245Address要素が含まれています．ゲートキーパはこのh245Address情報を変換してEPAに転送します．
この後は通常の手順と同様です．
エンドポイントEPBが発呼する場合（すなわち外側から内側に向け発呼する場合）少し複雑になり，新たな信号要素が加わります．
EPBからゲートキーパにEPA宛てのSETUPが送られると，TSはEPAとの持続しているRASチャネルを通じEPAにH.225.0 RAS SCI (Service Control Indication)メッセージを送ります．この中のgenericDataフィールドにIncomingCallIndication要素を含めます．このIncomingCallIndication要素は，EPAに対しTS向けのH.225.0呼制御のためのTCPコネクション確立を促す意味を持っています．これを受けたEPAはTSにH.225.0 RAS SCR (Service Control Response)メッセージで応答します．上記IncomingCallIndication要素にはcallSignallingAddressが含まれ，EPAはこのアドレスにH.225.0呼制御信号のためのTCPコネクションを確立します．EPAはここにH.225.0呼制御信号FACILITYを送り，その中に前述のSCIメッセージIncomingCallIndication要素のサブフィールドcallIdentifierを含め呼と通信相手を紐付けます．最後にTSはH.225.0呼制御メッセージSETUPをEPAに送り，後は通常通りの手順を踏みます．
ここまでは呼接続とH.245制御信号のNAT/FW越えでしたが，次にメディアのNAT/FW越えを規定したH.460.19の制御を説明します．具体的にはRTP，H.235[9-47]に従い暗号化されたRTP，SRTP (Secure RTP)[9-48]ストリームに対するNAT/FW越えの手順です．
システム構成は，図9-17のH.460.18をH.460.19に読み替えた構成です．メディアのNAT/FW越えには新たに二つの概念が導入されます．一つはメディアのためのKeep Alive Channelです．外側から内側へのパケットがNAT/FWを越えられるよう，内側のH.460.19クライアントからTSが指定するトランスポート・アドレス（IPアドレス + ポート番号）向けにkeep-aliveメディア・パケット（RTPヘッダのみでペイロードは空のパケット）を送り続けてピンホールを維持します．もう一つはRTPパケットを多重化する多重化メディアモードです．通常，異なるメディアは異なるトランスポート・アドレスに送られますが，NAT/FW越えにはピンホールの数を最小限にしたいことから，一つのトランスポート・アドレス対で全てのメディアのRTP/RTCPパケットを送ります．メディア情報を識別するため図9-18に示す4バイトのmultiplexIDをRTP/RTCPヘッダとUDPヘッダの間に挿入し，メディア情報の多重化分離を行います．multiplexIDは，一つの呼に属するメディア毎に（sessionID毎に）割り当てられるユニークな番号です．
H.460.18/19ソリューションでは，メディア・パケットが通過するピンホールを最小限にするため，一組のRTP/RTCPチャネルですべてのメディア・パケットを運びます．TS側でどの呼のどのメディアであるかを識別するIDがmultiplexIDです．
クライアントからサーバ方向へのメディア伝送は，通常の場合と同様で，クライアントからRTCPの宛先を付けて論理チャネル開設のH.245メッセージをサーバに送り，サーバはメディアの送り先とRTCPの送り先をつけてACKを返します．クライアントは指定のトランスポート・アドレスにメディアとRTCPのパケットを送ります．
サーバからクライアント方向へのメディア伝送は，サーバはRTCPを受け取る宛先のほかKeep Alive Channelの宛先を付けて，論理チャネル開設のH.245メッセージをクライアントに送ります．クライアントは，通常のようにRTCPとメディアの宛先を付けてACKを返します．次にクライアントはKeep Aliveパケットをサーバ指定のアドレスに送り，サーバはOLC (Open Logical Channel) ACKに記された宛先ではなく，クライアントのKeep Aliveパケットのトランスポート・アドレスにメディアのパケットを送ります．この点がH.460.19によるNAT/FW越え手順の特徴です．
最後に，H.460.18/19は2005年に導入された新たな機能ですから，その能力がどのように識別されるかを記します．H.460.18では，クライアントがH.225.0 RASメッセージGRQを送る際，featureSetフィールドのsupportedFeaturesにSignalling Traversalを入れ，これに応答するTSはGCFメッセージに同じくSignalling Traversalを入れることで，H.460.18のNAT/FW越え手順が利用できるようになります．クライアントはRRQを送る際も，同様にSignalling Traversalを表示します．H.460.19では，H.225.0呼制御メッセージのsupportedFeaturesにmediaNATFWTraversalが含まれていることが能力表示になります．クライアントからの発呼ではSETUPメッセージに，着呼ではCALL PROCEEDING，ALERTINGおよびCONNECTメッセージにmediaNATFWTraversalが含まれることで，H.460.19のNAT/FW越え手順が利用できるようになります．また多重化メディアモードの能力は，H.245メッセージOLC Request，OLC ResponseのTraversal Parametersに含まれるmultiplexIDフィールドで示されます．
7) H.460.23, H.460.24 NAT/FW越えソリューション
上記H.460.18/19 NAT/FW越えソリューションでは，メディアは常にH.460.19サーバで中継されますので，広帯域の情報を処理することからサーバの負担が大きくなります．そこで，これを避けるため特定タイプのNATではメディア情報を中継サーバ経由ではなく端末間で直接送ることができることに着目し，NATタイプを特定する手順を定めたH.460.23[9-49]，メディア情報をエンドポイント間で転送する手順を定めたH.460.24[9-50]が2009年12月に成立しました．
NATには，内部アドレス/ポート番号と外部アドレス/ポート番号のマッピング関係の違いによりいくつかのタイプがあります．NATの存在とこのマッピング情報を与えるのがSTUN (Simple Traversal UDP through NAT)サーバです．NATタイプの組み合わせにより，メディアが直接エンドポイント間で送受信できるか（この能力はP2Pnat media, peer-to-peer NAT mediaと呼ばれる），メディア送受信にH.460.19サーバの支援を必要とするか判断されます．
H.460.23/H.460.24がどのように動作するか，情報の流れが勧告H.460.24のFigure 1（図9-19）に例示されています．この例ではEPAはSTUNサーバとの通信でピンホールが開けられ，EPBはそこにメディア・パケットを送ることができます．さらにそれによりEPBのNAT/FWに開けられたピンホールに向けEPAはメディア・パケットを送ることができ，H.460.19サーバを経由することなくメディア情報がやりとりされます．
H.460.23/24のP2Pnat media能力表示には，第8.2.2項 4) で説明しましたGEFの能力表示が用いられます．具体的にはH.225.0 RASメッセージGRQ，GCF，RRQのsupportedFeaturesで示されます．
H.460.24に記載の通信例です．エンドポイントA，BはそれぞれSTUNサーバから事前にNATタイプ情報を得ています．エンドポイントAが自らのNATタイプ情報を含んだARQにより通信を開始すると，GK1はLRQ/LCFでNATタイプ情報を含めたエンドポイントBに関わる情報を獲得します．GK1は双方のNATタイプ情報から，適用できる通信形態を判断し，結果をACFでエンドポイントAに返します．エンドポイントAがSETUPで呼接続する際，NAT越えの方法（今の場合STUNの開けたピンホールを通じメディアをやりとりする）を含めます．この内容はGK2からエンドポイントBへSETUPで知らされます．エンドポイントBはSTUNサーバによりNAT/FW 1に開けられたピンホールにH.245論理チャネル開設メッセージを，ついでメディア・パケットを送ります．これによりNAT/FW 2にピンポールが開き，そこにエンドポイントAからのメディア・パケットが送られ双方向のメディア伝送が確立します．