JP2005051680A - マルチメディア通信装置またはマルチメディア通信方式またはビデオ配信システムおよびビデオ会議システム - Google Patents

Abstract

【課題】音声や映像をネットワークで伝送するマルチメディア通信においてデータ系で使用するＵＤＰ上のプロトコルは、アドレス変換機構を持つブロードバンドルータを介すると通信できないという問題を解決することを目的とする。
【解決手段】動画端末１０３がサーバ１０４側にＮＡＴテーブル作成パケットを送信する。また、ＲＴＳＰなどの制御系通信プロトコルでサーバが送るマルチメディアデータの送り先ポートを決めるという従来の方法を改め、サーバ１０４がコンテンツの配信を開始する前に、動画端末１０３からのＮＡＴテーブル作成パケットの受信を待ち、サーバ１０４が送るコンテンツ配信の宛先のＩＰアドレスおよびポート番号として、このパケットの発信元ＩＰアドレスおよび発信元ポート番号を使う。
【選択図】図４

Description

本発明は、グローバルネットワークであるインターネットあるいはイントラネットと、ローカルネットワークがアドレス変換機能を持ったルータによって接続されたネットワーク上に接続するコンテンツ配信サーバ、コンテンツ再生端末、ＩＰ電話、ビデオ会議用端末、ビデオ会議サーバなどの通信装置を用いるマルチメディア通信装置およびマルチメディア通信方式に関する。

近年、急速なインターネットの普及とともに、従来のWWWやメールなどパソコン向けのサービスに加えて、動画配信やＩＰ電話、ＴＶ会議などのマルチメディア通信への用途が広がりつつある。

一方、急速な普及によりインターネットのアドレス（グローバルアドレス）が不足しており、接続できる端末を増やすために、ローカルアドレスを用いたローカルネットワークを構築し、ローカルネットワークとインターネットをアドレス変換機能を持ったルータにより接続する例が増えてきている（例えば特許文献１参照）。

例えば、家庭内にはパソコンのほかに動画配信を視聴するための端末などをインターネットに接続する。パソコン、動画視聴端末はローカルネットワークに接続される。ローカルネットワークとインターネットを接続するのがアドレス変換機能を持つブロードバンドルータ（以下、単にルータと呼ぶ）である。ルータはＡＤＳＬ、ＦＴＴＨ、ＣＡＴＶ等のインターネットプロバイダを経由してインターネットに接続されている。通常インターネットプロバイダはＩＰアドレス（グローバルアドレス）を１つしか割り当てないので、ルータはアドレス変換機能を用いてローカルネットワークの複数のアドレスをグローバルアドレスに変換する。これにより複数のローカルアドレスの端末をあたかも１台の端末のようにみせて、インターネットに接続することが可能になる。

ルータのアドレス変換機能は、ＮＡＴとＩＰマスカレードという技術により実現されている。これはネットワーク接続の開始をローカルネットワークに接続した装置からグローバルネットワークへの装置に対して行なうという前提で成り立っている。この前提は、メールやWWWを使うには想定可能な前提である。アドレス変換を行なうため、ルータはＮＡＴテーブルという表を用いる。ＮＡＴテーブルは最初は空である。

図１はそのようなローカルネットワークとインターネットが接続されたネットワークの構成図、図２はＮＡＴテーブルを示す。図において、ローカルネットワークのパソコン１０１がインターネット上のコンテンツの配信サーバ（以下、単にサーバと呼ぶ）１０４と通信を行なう場合、パソコン１０１が送信したＩＰパケットは先ずルータ１０２に届く。ルータ１０２はパソコン１０１からのＩＰパケットの送信元アドレスをインターネットプロバイダから与えられたグローバルＩＰアドレスに変更し、ポート番号をルータ１０２がインターネット側で使用していないポート番号に変換する。この結果が変換後ポート番号である。なお、送信元のポート番号がインターネット側でも使用していない場合、送信元のポート番号と同じものを使ってもよい。ルータ１０２は変換後のＩＰパケットをインターネット側に送信する。

ＮＡＴテーブルは、少なくとも送信元ＩＰアドレス（以下Ｓ−ＩＰ）、送信元ポート番号（以下Ｓ−Ｐｏｒｔ）、変換後ポート番号（以下Ｔ−Ｐｏｒｔ）、グローバルネットワークに接続されている送信先ＩＰアドレス(以下Ｄ−ＩＰ)、送信先ポート番号（以下Ｄ−Ｐｏｒｔ）、タイムアウト（以下Ｔｉｍｅｏｕｔ）の要素を持つ。

例えば、パソコン１０１のＩＰアドレスがＳ−ＩＰ１、ポート番号がＳ−Ｐｏｒｔ１、送信先のＩＰアドレスがＤ−ＩＰ１、ポート番号がＤ−Ｐｏｒｔ１、ルータ１０２での変換後ポート番号をＴ−Ｐｏｒｔ１、ルータ１０２のインターネット側のＩＰアドレスをＲ−ＩＰとすると、図２で示すエントリがＮＡＴテーブルに登録される。

サーバ１０４からパソコン１０１に返されるＩＰパケットは、サーバ１０４が送信した時点では送信先ＩＰアドレスはルータ１０２のＩＰアドレス（以下Ｒ−ＩＰ）になっているので、ルータ１０２に届く。ルータ１０２はＮＡＴテーブルを調べ、届いたＩＰパケットの送信元ＩＰアドレスと送信元ポート番号、送信先ポート番号がそれぞれＮＡＴテーブルのＤ−ＩＰ、Ｄ−Ｐｏｒｔ、Ｔ−ｐｏｒｔと一致するエントリを探す。該当するものがあればＩＰパケットの送信先ＩＰアドレスをＳ−ＩＰ、送信先ポート番号をＳ−Ｐｏｒｔに変換し、ローカルネットワーク側に中継する。該当するものが無ければ受信したＩＰパケットを破棄する。

ＮＡＴテーブルのエントリは、一定期間条件を満たすＩＰパケットが無ければ破棄する。このため、Ｔｉｍｅｏｕｔのフィールドを定期的に減少させて行き、値が０になればエントリを破棄する。また、ＩＰパケットの変換に使われたエントリは使われるたびにタイムアウトの値を初期値に戻す。図２の例では３６００秒としている。

このように、パソコン１０１から最初ＩＰパケットを送信しその後受信する場合には通信は正しく行える。

しかし、最近のアプリケーションとして音声や映像をネットワークで伝送するマルチメディア通信がある。これらのアプリケーションでは従来のデータ通信と異なり、リアルタイム性が求められる。つまり、送信側で定期的に送信したデータは受信側でも同じタイミングで受信されることを求められる。ネットワーク障害のために送信あるいは受信されなかったデータは、遅延して送信あるいは受信するのではなく、データを破棄することが望ましいアプリケーションである。

この種類のアプリケーションでは、制御のための通信とデータ伝送の通信を分離するのが一般的である。制御プロトコルとして、コンテンツ配信サーバと動画再生端末との間の通信ではＲＴＳＰ等が用いられ、ビデオ会議、ＩＰ電話などではＨ．３２３、ＳＩＰなどが用いられている。これらは通信の信頼性を得るため、通常ＴＣＰを用いる。一方データ系はリアルタイム性を確保するため、ＲＴＰ、ＲＴＣＰやＵＤＰを用いるのが一般的である。
特開２００３−８６６０号公報

音声や映像をネットワークで伝送するマルチメディア通信においてデータ伝送で使用するＵＤＰ上のプロトコルは、アドレス変換機構を持つブロードバンドルータを介すると通信できないという問題がある。

この理由はデータ伝送の通信がローカルネットワークに接続した装置からグローバルネットワークに接続するという前提を満たさないために生じる。

また、制御プロトコルでは、端末がマルチメディアデータを受信するポート番号をサーバと折衝するが、そのポート番号がルータのアドレス変換機構により変更されてもそれを認識できないという問題がある。

以下に、制御プロトコルにＲＴＳＰ、データ系にＵＤＰを用いた通信が、上記図１において、ルータ１０２を経由した動画端末１０３とサーバ１０４の間で通信を行なう場合、何故通信できないかを図３を用いて説明する。この図で、例えば（Ｒ−ＩＰ,xxxx）←（Ｄ−ＩＰ１,yyyy）は通信のトランスポートデータのヘッダの内容を表す。送信先ＩＰアドレスがＲ−ＩＰ、送信先ポート番号がxxxx、送信元ＩＰアドレスがＤ−ＩＰ１、送信元ポート番号がyyyyである。

ＲＴＳＰでは、まず、図１における動画端末１０３がサーバ１０４と接続し、［３０１］〜［３０２］のシーケンスで配信すべきコンテンツ（映像データあるいは、オーディオデータ等のマルチメディアデータ）のＵＲＬを指定し、このコンテンツをどのポート番号を用いて通信するかの折衝を行なう。この例では動画端末１０３がxxxxのポートを使用するとサーバ１０４に伝え、サーバ１０４がyyyyのポート番号を使うと動画端末１０３に伝えている。［３０３］のＰＬＡＹによりサーバ１０４からコンテンツ配信［３０５］が開始される。このマルチメディアデータの送信先ＩＰは、通常ＲＴＳＰのコネクションの接続元のＩＰアドレスを用いる。従って送信先ＩＰはルータ１０２のＲ−ＩＰになる。

この結果、コンテンツの送信はルータ１０２に対して行なわれる。しかし、ルータ１０２のＮＡＴテーブルには該当のＤ−ＩＰ、Ｄ−Ｐｏｒｔ、Ｔ−Ｐｏｒｔは登録されていない。従ってルータ１０２はそのデータの転送先を決めることが出来ず破棄する。その結果通信が行なわれない。

本課題を解決する手段のポイントは２つである。１つ目のポイントは動画端末がサーバ側にＮＡＴテーブル作成パケットを送信することである。ＮＡＴテーブル作成パケットとはサーバがコンテンツ配信のために準備したＵＤＰポート番号に対して動画端末が送信する任意のＵＤＰパケットである。もう１つのポイントは、ＲＴＳＰなどの制御通信プロトコルでサーバが送るマルチメディアデータの送り先ポートを決めるという従来の方法を改め、サーバがコンテンツの配信を開始する前に、動画端末からのＮＡＴテーブル作成パケットの受信を待ち、サーバが送るコンテンツ配信の送信先のＩＰアドレスおよびポート番号として、このパケットの送信元ＩＰアドレスおよび送信元ポート番号を使うことである。

本発明によれば、コンテンツ配信サーバと動画端末の間にネットワークアドレス変換機能を有するルータが入っても正しく配信できる。また、ネットワークアドレス変換機能を有するルータがビデオ会議端末とサーバとの間にはいるネットワーク構成においても、正しくマルチメディア通信が可能となる。

以下、本発明の実施の形態を、図１および、図４から図１０を用いて詳細に説明する。

（実施の形態１）
図４は本発明の第１の実施の形態に係るマルチメディア通信装置のシーケンスを説明する図である。また、ネットワークの構成図として従来例で説明した図１を使用する。図において、例えば（Ｓ−ＩＰ１,xxxx）→（Ｄ−ＩＰ１,yyyy） は通信のトランスポートデータのヘッダの内容を表す。送信元ＩＰアドレスがＳ−ＩＰ１、送信元ポート番号がxxxx、送信先ＩＰアドレスがＤ−ＩＰ１、送信先ポート番号がyyyyであることを意味する。

シーケンスの［４０１］〜［４０４］は従来のシーケンスである［３０１］〜［３０４］と同一である。従来と異なるところは、動画端末１０３が［４０４］のパケットを受け取った後、ＮＡＴテーブル作成パケット［４０５］を送信する点である。また、サーバ１０４に関して述べれば、［４０４］のパケットを送信後、従来であればすぐにコンテンツ配信を開始していたが、本発明ではこれを行わず、動画端末１０３からのＮＡＴテーブル作成パケットの受信を待つ点である。さらに、従来と異なるところは、サーバ１０４がコンテンツを配信する配信先を、従来は動画端末１０３のＳＥＴＵＰメソッドにｃｌｉｅｎｔ＿ｐｏｒｔ＝xxxxの形で記載されたポート番号としていた点を改め、本発明では受信したＮＡＴテーブル作成パケットの送信元アドレスおよび送信元ポートとする点である。

以下その動作を説明する。

動画端末１０３が送信したＮＡＴテーブル作成パケットにより、ルータ１０２は図５のＮＡＴテーブルエントリを作成する。サーバ１０４が受け取ったＮＡＴテーブル作成パケットの送信元ＩＰはルータ１０２のインターネット側のＩＰドレスであるＲ−ＩＰ、送信元ポートはＴ−Ｐｏｒｔ１である。このＩＰアドレスおよびポート番号にサーバ１０４がコンテンツのパケットを配信すると、ルータ１０２はＮＡＴテーブルにそのエントリが登録されているため、そのパケットを動画端末１０３に転送する。

ＮＡＴテーブル作成パケットにより作成されたＮＡＴテーブルのエントリは一定時間経過すると破棄されるため、定期的に動画端末１０３からサーバ１０４に同様のパケットを送信することでエントリが破棄されないようにする。

（実施の形態２）
本発明の第２の実施の形態は、インターネット、あるいはイントラネット上に配置されたＭＰＥＧ２あるいはＭＰＥＧ４のコンテンツの配信サーバと、配信サーバから配信されたコンテンツを視聴する動画端末から構成される、ビデオオンデマンドシステムへの適応例である。

図６は本発明の第２の実施の形態に係るマルチメディア通信装置のシーケンスを説明する図である。また、ネットワークの構成図として従来例で説明した図１を使用する。

制御プロトコルとしてＲＴＳＰ、ビデオおよびオーディオデータを配信するプロトコルとしてＲＴＰおよびＲＴＣＰを用いる。なお、ビデオおよびオーディオデータを配信するプロトコルとしてＵＤＰを用いてもよい。この場合以下の説明において、ＲＴＰをＵＤＰと読み替え、ＲＴＣＰの記述を削除すれば同様に適応できる。

動画端末と配信サーバの間にルータが存在する場合と存在しない場合の両方で、本発明が適切に動作することを説明する。

図６の［６０４］までは図４の［４０４］までと同じであり、すでに説明した。

本方式では、［６０４］のシーケンスが終了後、ＮＡＴテーブル作成パケット［６０５］を動画端末１０３が送信する。ＲＴＰとＲＴＣＰの２つのプロトコルが存在するので、ＮＡＴテーブル作成パケットはＲＴＰポート用のものとＲＴＣＰポート用の２つのパケットが必要である。まず、パケットを送信するために動画端末１０３は自分のＲＴＰ用ポートとＲＴＣＰ用ポートを準備する。これらのポート番号は［６０１］のシーケンスのｃｌｉｅｎｔ＿ｐｏｒｔ＝で指定した値を用いる。例えば、ｃｌｉｅｎｔ＿ｐｏｒｔ＝4000でサーバ１０４に通知していれば、4000をＲＴＰ用、4001をＲＴＣＰ用とする。ＮＡＴテーブル作成パケットの送信先ポートは［６０２］のシーケンスで指定されたｓｅｒｖｅｒ＿ｐｏｒｔで決定する。例えば、サーバ１０４の応答の中にｓｅｒｖｅｒ＿ｐｏｒｔ＝8000と記載されていれば、ＲＴＰポート用としてはポート番号8000向けに送信し、ＲＴＣＰポート用としてはその次のポート番号であるポート番号8001に送信する。

従来の方式では、ＮＡＴテーブル作成パケットはなく、ＲＴＳＰのＰＬＡＹメソッドを受信するとすぐに配信を開始する。サーバ１０４はＲＴＳＰの接続元のＩＰアドレスを送信先のＩＰアドレスとし、ＳＥＴＵＰメソッドのｃｌｉｅｎｔ＿ｐｏｒｔで指定されたポート番号を送信先のポート番号とする。

本発明の方式でルータが存在しない場合、サーバ１０４が受け取るＲＴＰ用のＮＡＴテーブル作成パケットの送信元アドレスおよび送信元ポートは、動画端末１０３のＩＰアドレスおよびマルチメディアデータを受信すべきポートである。このポート番号は、動画端末１０３が送信するＲＴＳＰのＳＥＴＵＰメソッドに含まれるｃｌｉｅｎｔ＿ｐｏｒｔである4000の値と一致している。その結果、サーバ１０４は従来の方式と同じ送信先にＲＴＰパケットを送信することになり正しく送信が行われる。

ルータが存在する場合、従来の方法では通信が行なえないことを、「発明が解決しようとする課題」において説明した。

本発明の方式でルータが存在する場合、ＮＡＴテーブル作成パケットはルータ１０２を通過するときにその送信元ＩＰと送信元ポート番号が変更される。送信元ＩＰはルータ１０２のインターネット側ＩＰアドレスになる。送信元ポートはルータ１０２がインターネット側で未使用のポート番号を選択して割り当てる。その値を例えば１６３８４とする。この場合、ルータ１０２のＮＡＴテーブルには図７のステップ１のエントリが追加される。

ルータ１０２を通ったＮＡＴテーブル作成パケットはサーバ１０４に到着する。本発明を実施したサーバ１０４はその発信元アドレスと発信元ポートを取り出し、そのＩＰアドレスおよびポート（１６３８４）にマルチメディアデータであるＲＴＰデータを送信する。ＲＴＰデータはルータ１０２に到着し、変換後ポート番号１６３８４がＮＡＴテーブルに登録されているので、ＲＴＰパケットの送信先を動画端末１０３のＩＰアドレスであるＳ−ＩＰ１、ポート番号を4000に変更してローカルネットワーク側に転送する。その結果ＲＴＰデータが動画端末１０３に到着する。

なお、ＮＡＴテーブル作成パケットは、動画端末１０３からサーバ１０４に送信するパケットであれば、特別に準備したパケットである必要はない。この理由により、ＲＴＣＰに関しては特別なＮＡＴテーブル作成パケットを送信しなくとも、ＲＴＣＰパケット自身をＮＡＴテーブル作成パケットとして使うことが出来る。

ＲＴＣＰは動画端末１０３とサーバ１０４の間で通信状態を互いに報告するための機能を提供している。ＲＴＣＰパケットはサーバ１０４から動画端末１０３に送信するだけでなく、動画端末１０３からサーバ１０４にも送信する。従ってＲＴＣＰ用のＮＡＴテーブル作成パケットとして、例えばＲＴＣＰのＲｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ（RR）パケットを使うことが出来る。この場合、サーバ１０４は動画端末１０３からの最初のＲＴＣＰパケットを受信を待ち、その後ＲＴＣＰパケットの送信元ＩＰ、送信元ポートあてにサーバ１０４からのＲＴＣＰパケットを送信する。動画端末１０３はＲＴＣＰパケットを定期的に送信するため、ＮＡＴテーブルのエントリのタイムアウトによる破棄を防止する事が出来る。

例えば、図６の［６１１］は動画端末１０３からサーバ１０４へのＲＴＣＰパケットである。このパケットにより、ルータのＮＡＴテーブルは図７のステップ２になる。ここでルータ１０２の変換ポート番号は１６３８６が割り当てられたとする。

サーバ１０４が受信したＲＴＣＰパケットの送信元ＩＰと送信元ＰｏｒｔをサーバのＲＴＣＰパケットの送り先にして送信する［６１３］。

これにより、本発明の実施形態としてＲＴＰ用のＮＡＴ作成パケットを送信すればＲＴＣＰ用のＮＡＴ生成パケットはＲＴＣＰの従来のプロトコルをそのまま使うことでルータを経由した場合でも通信を行うことが出来る。

（実施の形態３）
本発明の第３の実施の形態は、インターネット、あるいはイントラネット上に配置された会議サーバ、ＭＣＵなどを経由してビデオ会議端末間でのビデオ会議システムへの適応例である。

図８は本発明の第３の実施の形態に係るビデオ会議システムにおけるネットワークの構成図、図９はシーケンスを説明する図である。図において、例えば（Ｒ１−ＩＰ，Ｔ１−Ｐｏｒｔ）の記載はＩＰアドレスがＲ１−ＩＰ、 ポートがＴ１−Ｐｏｒｔであることをあらわす。

ネットワークは、ビデオ会議を行うビデオ会議端末８０４、８０５、ビデオ会議端末８０４、８０５からの会議参加要求を受付、会議を設定する会議サーバ８０１、３人以上の会議において、音声や映像を合成するＭＣＵ８０６で構成される。図には含まれないが、ビデオ会議端末８０４、８０５にはカメラが接続され、自分の映像をキャプチャする。またビデオ会議端末８０４、８０５に接続したＴＶなどにより相手の映像を表示する。

会議サーバ８０１とビデオ会議端末８０４、８０５の間にはアドレス変換機能を持つルータ８０２、８０３がそれぞれのビデオ会議端末８０４、８０５ごとに存在する。この構成では従来の方法ではビデオ会議を行うことが出来なかった。

ビデオ会議システムの制御プロトコルとして、ＳＩＰを用いる。ビデオおよびオーディオというマルチメディアデータを送受信するプロトコルとしてＲＴＰ、ＲＴＣＰを用いる。

ビデオ会議のシーケンスを図９を用いて説明する。

ビデオ会議の開始時、ＳＩＰプロトコルにより会議セッションの確立が行われる。例えば、ビデオ会議端末８０４とビデオ会議端末８０５がビデオ会議を行う場合、まずビデオ会議端末８０４が会議室ＩＤを指定して会議のセッションを確立する（９０１）。次にビデオ会議端末８０５が同じ会議ＩＤの会議のセッションを確立する（９０３）。会議サーバ８０１は２つのセッションを接続し、ビデオ会議端末８０４からの映像データをビデオ会議端末８０５へ、ビデオ会議端末８０５のデータをビデオ会議端末８０４に転送する（９０５、９０６）。マルチメディアデータに関しては、ビデオ会議端末８０５が会議セッションを確立し、最初のマルチメディアデータを受信するまでのビデオ会議端末８０４からのデータは破棄する（９０２、９０４）。

ビデオ会議システムでは、ＲＴＰおよびＲＴＣＰの両方ともビデオ会議端末から送信を行うので、ＮＡＴテーブル作成パケットは、ビデオ会議端末からのＲＴＰパケットおよびＲＴＣＰパケットにより代用することが出来る。

本発明の実施形態である会議サーバは、各ビデオ会議端末から送信されてくるマルチメディアデータの送信元ＩＰアドレスおよび送信元ポートを取り出し、そのあて先にそのビデオ会議端末に送信すべきマルチメディアデータを送信する。図８においては、９０２のパケットによりビデオ会議端末８０４に送るときのＩＰアドレスとポート番号を決定する。９０２のパケットを受け取ったとき、ルータ８０２、ルータ８０３のＮＡＴテーブルの状態は図１０のステップ１のとおりである。ルータ８０２には９０２のパケットによるＮＡＴエントリが登録されている。

会議サーバは上記アルゴリズムにより、ビデオ会議端末８０４に送る時の送信先ＩＰアドレスはルータ８０２のＩＰアドレスＲ１−ＩＰ、送信先ポートはルータ８０２の変換後のポート番号であるＴ１−Ｐｏｒｔになる。

ビデオ会議端末８０５が会議セッションを確立（９０３）後、ビデオ会議端末８０５はマルチメディアデータを送信する（９０５）。このときのルータ８０３のＮＡＴテーブルの状態は図１０のステップ２のとおりである。このデータの送信元ＩＰアドレスはルータ８０３のＩＰアドレスＲ２−ＩＰ、送信元ポート番号はＴ２−Ｐｏｒｔになる。会議サーバ８０１はこのマルチメディアデータをビデオ会議端末８０４に送るため、受け取ったパケットの送信元ＩＰをＳＲＶ−ＩＰ、送信元ポート番号をＳＲＶ−Ｐｏｒｔ１、送信先ＩＰアドレスをＲ１−ＩＰ、送信先ポート番号をＴ１−Ｐｏｒｔにして送信する。一方、会議サーバ８０１は９０５以降に受け取ったビデオ会議端末８０４からのマルチメディアデータ（９０６）をビデオ会議端末８０５に送るため、受け取ったパケットの送信元ＩＰをＳＲＶ−ＩＰ、送信元ポート番号をＳＲＶ−Ｐｏｒｔ２、送信先ＩＰアドレスをＲ２−ＩＰ、送信先ポート番号をＴ２−Ｐｏｒｔにして送信する。

ビデオ会議端末８０４、ビデオ会議端末８０５に送信されたマルチメディアデータの送信先ＩＰ、送信先ポート番号、送信元ＩＰ、送信元ポート番号はＮＡＴテーブルに登録されたエントリと一致するので、各ルータによってビデオ会議端末８０４あるいはビデオ会議端末８０５のＩＰアドレスおよびポート番号に変換され送信される。その結果としてビデオ会議端末８０４とビデオ会議端末８０５のビデオ会議システムは正しく動作する。

なお、この実施形態はビデオ会議であったが、マルチメディアデータとして音声だけを扱えば、容易にＩＰ電話に適応できる。また、今回、ビデオ会議システムの制御プロトコルとしてＳＩＰプロトコルを用いたが、Ｈ．３２３を用いてもマルチメディアデータの転送方法はＳＩＰと同じであるため、本方式が適応できる。

本発明のマルチメディア通信装置またはマルチメディア通信方式は、コンテンツ配信サーバと動画端末の間にネットワークアドレス変換機能を有するルータが入っても正しく配信できる。また、ネットワークアドレス変換機能を有するルータがビデオ会議端末とサーバとの間にはいるネットワーク構成においても、正しくマルチメディア通信が可能となるという効果を有し、グローバルネットワークであるインターネットあるいはイントラネットと、ローカルネットワークがアドレス変換機能を持ったルータによって接続されたネットワーク上に接続するコンテンツ配信サーバ、コンテンツ再生端末、ＩＰ電話、ビデオ会議用端末、ビデオ会議サーバなどの通信装置を用いるマルチメディア通信装置等として有用である。

ローカルネットワークとインターネットが接続されたネットワーク構成図 従来の方式で通信を行ったときのルータのＮＡＴテーブルの内容を示す図 従来の通信方式におけるシーケンスの説明図 本発明の第１の実施の形態に係るマルチメディア通信装置におけるシーケンスの説明図 本発明の第１の実施の形態に係るマルチメディア通信装置におけるルータのＮＡＴテーブルの内容を示す図 本発明の第２の実施の形態に係るマルチメディア通信装置におけるシーケンスの説明図 本発明の第２の実施の形態に係るマルチメディア通信装置におけるルータのＮＡＴテーブルの内容を示す図 本発明の第３の実施の形態に係るビデオ会議システムにおけるネットワークの構成図 本発明の第３の実施の形態に係るビデオ会議システムにおけるシーケンスの説明図 本発明の第３の実施の形態に係るビデオ会議システムにおけるルータのＮＡＴテーブルを示す図

符号の説明

１０１ パソコン
１０２ ルータ
１０３ 動画端末
１０４ 配信サーバ
８０１ 会議サーバ
８０２、８０３ ルータ
８０４、８０５ ビデオ会議端末

Claims (8)

1. インターネットあるいはイントラネット上にあり、サーバ機能を有し、マルチメディアデータを送信する第１の通信装置と、ローカルネットワーク上にあり、クライアント機能を有し、前記マルチメディアデータを受信する第２の通信装置と、インターネットとローカルネットワークを接続するネットワークアドレス変換機能を有するルータとを備え、マルチメディアデータ伝送開始時、前記第２の通信装置のマルチメディアデータを受信すべきポートから、前記第１の通信装置のマルチメディアデータを送信するポートあてに任意のＵＤＰパケット（以下ＮＡＴテーブル作成パケットと呼ぶ）を送信することを特徴とするマルチメディア通信装置またはマルチメディア通信方式。
2. 第２の通信装置から、第１の通信装置あてにＮＡＴテーブル作成パケットを送信し、その後一定期間毎に同様のＮＡＴテーブル作成パケットを送信することを特徴とする請求項１記載のマルチメディア通信装置またはマルチメディア通信方式。
3. 第１の通信装置は、マルチメディアデータ伝送開始時、第２の通信装置からのＮＡＴテーブル作成パケットの受信を待ち、前記ＮＡＴテーブル作成パケットのＩＰパケットに含まれる送信元アドレスとポート番号をもとに、マルチメディアデータ送信先を決めることを特徴とする請求項１記載のマルチメディア通信装置またはマルチメディア通信方式。
4. マルチメディアデータの通信をコネクションレストランスポートプロトコルにて実施することを特徴とする請求項１乃至請求項３記載のマルチメディア通信装置またはマルチメディア通信方式。
5. コネクションレストランスポートプロトコルとしてＵＤＰを用いることを特徴とする請求項４記載のマルチメディア通信装置またはマルチメディア通信方式。
6. コネクションレストランスポートプロトコルとしてＵＤＰ上に実装されたＲＴＰプロトコルあるいは、ＲＴＰプロトコルとＲＴＣＰプロトコルの組合せを用いることを特徴とする請求項４記載のマルチメディア通信装置またはマルチメディア通信方式。
7. 請求項５または請求項６記載のマルチメディア通信装置において、第１の通信装置をコンテンツ配信装置、第２の通信装置をコンテンツ視聴端末とし、マルチメディアデータとしてＭＰＥＧなどの映像データを扱い、マルチメディアデータの配信開始、マルチメディアデータの配信終了などを制御するプロトコル（以下制御プロトコルと呼ぶ）としてＲＴＳＰを用い、マルチメディアデータを伝送するプロトコルとしてＵＤＰあるいはＵＤＰの上に実装されたＲＴＰあるいはＲＴＰとＲＴＣＰの組合せを用い、ＲＴＣＰの通信のためのＮＡＴテーブル作成パケットとしてＲＴＣＰパケット自身を用いることを特徴とするビデオ配信システム。
8. 請求項５または請求項６記載のマルチメディア通信装置において、第１の通信装置をビデオ会議サーバ、第２の通信装置をビデオ会議端末とし、マルチメディアデータとしてＭＰＥＧなどの映像データを扱い、制御プロトコルとしてＳＩＰあるいはＨ．３２３プロトコルを用い、マルチメディアデータを伝送するプロトコルとしてＵＤＰあるいはＵＤＰの上に実装されたＲＴＰあるいはＲＴＰとＲＴＣＰの組合せを用い、ＮＡＴテーブル作成パケットとして前記ビデオ会議端末から前記ビデオ会議サーバに送信する映像および音声のデータパケットおよびそれぞれのＲＴＣＰパケットを用いることを特徴とするビデオ会議システム。

Images