NAT設定に関して-1.まず基本的な動作

AKIHIRO | 2014年7月1日 | HDX, NAT, Network, Polycom, VSX | コメントはまだありません

うちの場合、ビデオ会議の接続は基本LAN内（VPN内）で接続を行っています、が・・・
ときどき取引先とIP（インターネット経由）で接続する必要があり、ルーターやF/Wの設定に四苦八苦したことがあります。
使用するF/Wによって、端末側のNAT設定を何もしなくても接続できたり、多地点を行ったときだけ不具合が起きたり、1回目の接続はうまくいかないのに続けて2回目の接続はうまくいったり、相手に音声/映像は行くのにこちらにはこなかったり・・・
まぁいろいろな現象がでるので、経路のパケットをキャプチャ―したりして結構本気で調べました。
忘れないうちに備忘録しておこうと思います。

まず、H.323通信の基本的な動作。
最初の理解としてはここから始まります。

上図の様なシンプルなネットワーク構成で、ポリコム端末同士が接続されるまでを見てみます。
①接続
「ポリコム端末A」から「ポリコム端末B」へ接続する時、まず「ポリコム端末A」から「ポリコム端末B」に対し、接続の要求をします。
具体的には　IPアドレス192.168.2.100のTCPポート：1720番に対して接続に行きます。
このTCP:1720番は決まったポート番号で、どのメーカーのビデオ会議システムも、H.323で通信を行う場合はこのポートを使用します。
TCP/IPレベルでSYN/ACKされるとすぐに②H.225.0の処理が始まります

②H.225.0呼制御
H.225.0で呼の制御（接続可能かどうかなど）のやりとりが行われます。（端末をゲートキーパーに登録している環境では、H.225.0でRAS制御（ゲートキーパへの登録（Registration）/通信許可（Admission）/通信状態（Status））が行われますが、今回はゲートキーパーの無い環境で、NATの理解をするためのメモに留めます）
接続可能かどうか？。
一例として「話中でないか？」などはここのやり取りで行われます。
下図は話中の時、着信側から送られてくるH.225.0のAlertingです。

Alerting　reason：inconf（in conference）ということで話中処理されてますね。
③H.245処理
H.225.0での呼制御が問題なく完了すると、H.245の処理に入ります。
この処理内で、端末間での能力交換が行われ、お互いに「映像はどの圧縮にするか？、音声はどのプロトコルを使うか？」などの情報交換が行われます。
そして、NAT超えを非常にややこししくしている「メディアデータの待ちうけIPとポート」もここで通知し合います。
H.323のNAT超えの問題は、もうほとんどここに集約しているという感じです、具体的な情報は下図の様な感じです。

上図のように、H.245の処理の中で「Open Logical Channel」という処理が行われ、端末間で論理チャネルが形成されます。
この時、相手側に「私がデータを待ちうけるのは　IPアドレス：192.168.2.100（例図の環境）　ポート番号：3231」ですよ、ということを伝えます。

音声、映像、カメラコントロールなど、必要な数だけ論理チャネルが形成されます。

ポート3231（UDP）

ポート3233（UDP）

ポート3235（UDP）

ポート3237（UDP）

ようは通信相手に対して、自分のIPアドレスとポート番号を伝えているのですが、この「相手に通知するポート番号」はデフォルトではランダムに決定されます。
しかし、HDXの設定で「固定ポート」のチェックを付けると、設定画面で設定したポートの範囲を使用するようになります。
（上図の場合だと、ポート固定設定がされていて、3230～　のポートを使用するように設定されています）
ポート固定の設定をしていない場合、結構 High Port（49209（ランダムです））が使用されたりします。

ちなみに、Payload Type欄の数字をみると、「何のデータか？」がわかります（PT=2はG.721/PT=9はG.722など）が、Payload Typeの96～127は動的割り当てということで自由に定義してよいようです。
（RFC1890にて定義　http://www.ietf.org/rfc/rfc1890.txt）

G.711＆H.261の時はWireSharkでもデータのタイプが表示されますね。

④RTP/RTCPデータの送受信
ここまでの処理が完了すると、H.245で指定されたIPアドレスとポート番号宛に、UDPデータ（RTP）データを送信し始めます。
どの映像圧縮を使用するか、どの音声プロトコルを使用するかなどもH.245で打ち合わせ済みです。
ここで注目すべきは、映像/音声のRTPデータは、上記H.245セッション内で打ち合わせを行ったIP/ポート番号にいきなり投げつけられるというところです。
通常TCPの通信であれば、まず行きのデータの戻りデータという「行って帰って」の処理があるため、NATなんかもすぐに超えて「戻って」これますが、H.323の映像/音声データは「戻り」データでは無いということです。
さらに、データを「投げてきてほしいIP/ポート」を、H.245のセッション内で通信相手に伝えているんですね。
H.245の処理終了後、RTPデータがすぐに送受信されます。

映像/音声/コンテンツ/ファーエンドカメラコントロールのデータはRTP（UDP）で送信され、定期的にRTCPでレポートのやり取りが行われます。
このRTCPのレポートデータに、送信済みのRTPデータはいくつですよ、などの通知が入っている為、相手側は実際に受け取ったRTPデータと、このレポートの数値の差分を見てパケットロスのカウントが行える仕組みです。
ここまでが、H.323のまずは基本的な接続動作になります。
さて、ここまでを理解したうえで、NATの場合どういう動作をするのかみてみましょう。
「NAT設定に関して-2.NATの場合どうなるか」へ続く。

Related Posts