(57)【要約】【課題】ＲＴＰ通話が可能かどうかをＩＰ端末が自動で判別し、音声データの送受信方式を選択するＩＰネットワークにおける音声データ送受信自動選択システムを提供する。【解決手段】音声入出力部１１において音声を入力する。次にデジタル・アナログ部１２において音声のアナログデータをデジタルデータへ変換する。さらにＲＴＰポート確認部１３において、ＲＴＰ通信が可能かどうかを判断する。ＲＴＰ通話が不可能な場合、履歴テーブル１４を参照して音声データ通信が可能なポートを決定する。デジタル化された音声を呼制御部１５へ渡し音声通話のための呼制御を行い、ＲＴＰ通話が可能な場合はＲＴＰ通信を行うため、音声データをＩＰ通信部１６へ渡しパケット化を行う。ＩＰパケット化された音声データはＬＡＮインタフェース部１７へ渡され、ネットワークへ出力される。【選択図】      図１
2004186748.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰ端末がファイアウォールを介して通話先端末と接続されたＩＰネットワークにおける音声データ送受信自動選択システムであって、
前記ＩＰ端末は、ＶｏＩＰの制御信号を処理する呼制御部と、音声や動画を入出力する音声入出力部と、入力した音声や動画をデジタル・アナログ変換処理するデジタル・アナログ処理部と、音声や動画データをＩＰで送信するＩＰ通信部と、ＲＴＰで通信可能か否か確認するＲＴＰポート確認部と、ファイアウォールを越えてデータ通信している通信を記録する履歴テーブルとを有し、
前記ＲＴＰポート確認部は、ＲＴＰ通信が可能か否か判断し、ＲＴＰ通話が可能な場合はそのＲＴＰポートを用い、ＲＴＰ通信のパケット化を行うため音声データを前記ＩＰ通信部へ渡し、ＲＴＰ通話が不可能な場合は、前記履歴テーブルを参照して音声データ通信が可能なポートを決定してから前記ＩＰ通信部へ音声データを渡すことを特徴とする音声データ送受信自動選択システム。
【請求項２】
前記ＲＴＰポート確認部は、所定のＲＴＰポートで通話することが可能か否か確認するためのサーチパケットを送出し、このサーチパケットに対するレスポンスを受けた場合に通話が可能と判断し、ＲＴＰによる音声データの送受信を行うことを特徴とする請求項１記載の音声データ送受信自動選択システム。
【請求項３】
前記ＲＴＰポート確認部は、サーチパケットを送出して、ポートの確認を行い、公知の通信ポートで通信可能な場合、そのポートを通信用ポートに割当てて履歴テーブルに記録し、
公知の通信ポートで通信できない場合、履歴テーブルの中で通話先の履歴が複数あるときには、一番最近に通信が成功したものについて１番目の通信路候補として選択し、そのポートで通信できない場合、過去の履歴の中から通信の成功例が多いものを通信路として選択することを特徴とする請求項２記載の音声データ送受信自動選択システム。
【請求項４】
前記ＩＰ端末は、自身と通話先のＩＰアドレスを確認するＩＰアドレス確認部を有し、
前記ＩＰ端末と通話先端末がプライベートＩＰアドレスを持つとき、同じネットワークにあることを確認して、ＲＴＰによる音声データの送受信を行うことを特徴とする請求項１〜３のいずれかに記載の音声データ送受信自動選択システム。
【請求項５】
ネットワーク上のニックネームとＩＰアドレス、通信可能なポートをアドレステーブルに記録するニックネーム・サーバをさらに備え、
前記ＩＰ端末は、自身のＩＰアドレスとニックネームをサーバに送信するアドレス送信部と、通話相手のニックネームを送信し、ＩＰアドレスを要求するアドレス要求部とを有し、
前記ＩＰ端末が、前記ニックネーム・サーバに通話相手のニックネームを送信してアドレスを要求すると、前記ニックネーム・サーバが通話先のＩＰアドレスと通話可能なポートを通知し、
前記ＩＰ端末は、この通話可能なポートを用いて音声データの送受信を行うことを特徴とする請求項１〜４のいずれかに記載の音声データ送受信自動選択システム。
【請求項６】
前記ＩＰ端末は、前記ニックネーム・サーバより通知される通話可能なポートを利用して通信を試み、通信が失敗した場合には自身の履歴テーブルを用いて通信路を決定し、再度音声データ通信を試みる手段を有し、
過去の通信履歴と前記ニックネーム・サーバからのポート情報を用いて音声データ通信可能なポートを自動で判断することを特徴とする請求項５記載の音声データ送受信自動選択システム。
【請求項７】
ＩＰネットワーク及びファイアウォールを介して通話先端末と接続されたＩＰ端末による音声データ送受信自動選択方法であって、
前記ＩＰ端末は、音声や動画データをＩＰで送信する際に、ＲＴＰ通信が可能か否か判断し、ＲＴＰ通話が可能な場合はそのＲＴＰポートを用い、ＲＴＰ通信を行うため音声データのパケット化を行い、
ＲＴＰ通話が不可能な場合は、ファイアウォールを越えて行われたデータ通信を記録した履歴テーブルによって音声データ通信が可能なポートを決定してから音声データのパケット化を行うことを特徴とする音声データ送受信自動選択方法。
【請求項８】
所定のＲＴＰポートで通話することが可能か否か確認するためのサーチパケットを送出し、このサーチパケットに対するレスポンスを受けた場合に通話が可能と判断し、ＲＴＰによる音声データの送受信を行うことを特徴とする請求項７記載の音声データ送受信自動選択方法。
【請求項９】
ＩＰネットワーク及びファイアウォールを介して通話先端末と接続された音声データ送受信自動選択ＩＰ端末であって、
前記ＩＰ端末は、ＶｏＩＰの制御信号を処理する呼制御部と、音声や動画を入出力する音声入出力部と、入力した音声や動画をデジタル・アナログ変換処理するデジタル・アナログ処理部と、音声や動画データをＩＰで送信するＩＰ通信部と、ＲＴＰで通信可能か否か確認するＲＴＰポート確認部と、ファイアウォールを越えてデータ通信している通信を記録する履歴テーブルとを有し、
前記ＲＴＰポート確認部は、ＲＴＰ通信が可能か否か判断し、ＲＴＰ通話が可能な場合はそのＲＴＰポートを用い、ＲＴＰ通信のパケット化を行うため音声データを前記ＩＰ通信部へ渡し、ＲＴＰ通話が不可能な場合は、前記履歴テーブルを参照して音声データ通信が可能なポートを決定してから前記ＩＰ通信部へ渡すことを特徴とする音声データ送受信自動選択ＩＰ端末。
【請求項１０】
前記ＲＴＰポート確認部は、所定のＲＴＰポートで通話することが可能か否か確認するためのサーチパケットを送出し、このサーチパケットに対するレスポンスを受けた場合に通話が可能と判断し、ＲＴＰによる音声データの送受信を行うことを特徴とする請求項９記載の音声データ送受信自動選択ＩＰ端末。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークにおいて、ネットワークの状況をユーザーが意識することなく音声データの送受信方式を切り替えて通話を行う音声データ送受信自動選択システムに関する。
【０００２】
【従来の技術】
従来、ＩＰネットワーク上で音声を送受信するためのＶｏＩＰシステムにおいて、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）を用いた通話がある。ＲＴＰは、特にネットワークを介したビデオ会議システムやインターネット電話等のリアルタイム・アプリケーションを実現するためのトランスポート層プロトコルとして用いられる。ＲＴＰでは、制御チャネル（例えば、ｓｉｐポート＝５０６０）でＲＴＰポートを指定して、リアルタイムで音声や動画を送受信する。
【０００３】
一般に、ＬＡＮとインターネット間にファイアウォールを設置したＩＰネットワークでは、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ等の特定のプロトコルで利用するＩＰポート番号のみの接続を許可し、その他のポート番号は接続禁止にしておくのが一般的である。
【０００４】
ここでＩＰポート番号は、２オクテットの正数即ち０〜６５５３５で表され、ＩＰネットワークを介したアプリケーションは、各々この内の１つのポートを介して通信を行う。通常の場合、各アプリケーションに対して以下のようにＩＰポート番号が割り付けられている。
【０００５】
ＷＥＬＬ  ＫＮＯＷＮ  ＰＯＲＴ  ＮＵＭＢＥＲＳ  ＝  ０〜１０２３
殆どのシステムのシステム（またはルート）プロセスや特権ユーザーのプログラムで使用できるポート番号である。代表例としてｆｔｐ＝２１，  ｈｔｔｐ＝８０  等がある。
【０００６】
ＲＥＧＩＳＴＥＲＥＤ  ＰＯＲＴ  ＮＵＭＢＥＲＳ  ＝  １０２４〜４９１５１
殆どのシステムにおける一般ユーザープロセスや一般ユーザーが実行するプログラムで使用できるポート番号である。代表例として、ｃａｌｌ−ｓｉｇ−ｔｒａｎｓ（Ｈ．３２３  ＡｎｎｅｘＥ）＝２５１７，  ｓｉｐ＝５０６０  等がある。
【０００７】
ＤＹＮＡＭＩＣ  ＡＮＤ／ＯＲ  ＰＲＩＶＡＴＥ  ＰＯＲＴＳ  ＝  ４９１５２〜６５５３５
ユーザーが自由に使用できるポート番号である。通常、Ｈ．３２３やＳＩＰなどのＶｏＩＰ制御プロトコルは、この範囲内にＲＴＰ用のポートを設けて通信パスを繋ぐ。
【０００８】
ファイアウォールは、外部からの有害なアタックを未然に防ぐため、これらの内の不要なＩＰポートをフィルタする。特に  ＤＹＮＡＭＩＣ  ＡＮＤ／ＯＲ  ＰＲＩＶＡＴＥ  ＰＯＲＴＳ  はフィルタされやすいポートである。逆に、ネットワークアクセスのため、少なくともｈｔｔｐポート（＝８０）だけは開けておくのが一般的である。
【０００９】
このようなシステムで任意のポート番号を用いてＩＰ音声通話を行うために、マルチメディアプロキシサーバを設置したシステム構成がある（例えば、特許文献１参照）。
【００１０】
また、無線ＬＡＮやＰＨＳデータ通信網を介してＩＰネットワークにアクセスし、ＩＰ音声通話を行うＩＰ携帯電話技術が開示されている（例えば、特許文献２参照）。
【００１１】
【特許文献１】
特開２００２−９８４６号公報
【特許文献２】
特開２００１−２２３７４８号公報
【００１２】
【発明が解決しようとする課題】
しかしながら、従来のＶｏＩＰシステムにおいてはＲＴＰを用いた通話あるいは他の音声データ送受信方法を予め設定しておく必要があり、自動ではＲＴＰでの音声データ通信が可能かどうかを判断し、適切な通信方式に切り替えることができなかった。
【００１３】
そこで本発明は、ＲＴＰ通話が可能かどうかをＩＰ端末が自動で判別し、ネットワークの状況に応じて音声データの送受信方式を選択するＩＰネットワークにおける音声データ送受信自動選択システム及び方法並びにＩＰ端末を提供することを目的とする。
【００１４】
【課題を解決するための手段】
上述の課題を解決するため、本発明は、ＩＰ端末がファイアウォールを介して通話先端末と接続されたＩＰネットワークにおける音声データ送受信自動選択システムであって、前記ＩＰ端末は、ＶｏＩＰの制御信号を処理する呼制御部と、音声や動画を入出力する音声入出力部と、入力した音声や動画をデジタル・アナログ変換処理するデジタル・アナログ処理部と、音声や動画データをＩＰで送信するＩＰ通信部と、ＲＴＰで通信可能か否か確認するＲＴＰポート確認部と、ファイアウォールを越えてデータ通信している通信を記録する履歴テーブルとを有し、前記ＲＴＰポート確認部は、ＲＴＰ通信が可能か否か判断し、ＲＴＰ通話が可能な場合はそのＲＴＰポートを用い、ＲＴＰ通信のパケット化を行うため音声データを前記ＩＰ通信部へ渡し、ＲＴＰ通話が不可能な場合は、前記履歴テーブルを参照して音声データ通信が可能なポートを決定してから前記ＩＰ通信部へ音声データを渡すことを特徴とする。
【００１５】
さらに、前記ＲＴＰポート確認部は、所定のＲＴＰポートで通話することが可能か否か確認するためのサーチパケットを送出し、このサーチパケットに対するレスポンスを受けた場合に通話が可能と判断し、ＲＴＰによる音声データの送受信を行うことを特徴とする。
【００１６】
以上の構成によって、ファイアウォールがあってもＲＴＰによる音声データの送受信が可能かどうかを自動的に判断できる。
【００１７】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００１８】
図１は、本発明の音声データ送受信自動選択システムの構成例を示す。ＩＰ端末１０とＩＰ端末２０がファイアウォール３０及びＩＰネットワーク４０を介して音声データ通信を行っているシステムにおいて、ＩＰ端末１０は、音声や動画を入出力する音声入出力部１１と、入力した音声や動画をデジタル・アナログ変換処理するデジタル・アナログ処理部１２と、ＲＴＰで通信可能か確認するＲＴＰポート確認部１３と、ファイアウォールを越えてデータ通信している通信を記録する履歴テーブル１４と、ＶｏＩＰの制御信号を処理する呼制御部１５と、音声や動画データをＩＰで送受信するＩＰ通信部１６と、ネットワークとの入出力を行うＬＡＮインタフェース部１７を有する。
【００１９】
次に、図２に示すフローチャートを参照して、本システムの動作について説明する。まず、音声入出力部１１において音声を入力する（Ｓ１）。次にデジタル・アナログ部１２において音声のアナログデータをデジタルデータへ変換する（Ｓ２）。さらにＲＴＰポート確認部１３において、ＲＴＰ通信が可能かどうかを判断する（Ｓ３）。ＲＴＰ通話が可能な場合はそのＲＴＰポートを用い、ＲＴＰ通話が不可能な場合は履歴テーブル１４を参照して音声データ通信が可能なポートを決定する（Ｓ４）。デジタル化された音声を呼制御部１５へ渡し音声通話のための呼制御を行い（Ｓ５）、さらに音声データをＩＰ通信部１６へ渡し、ＲＴＰ通話が可能な場合はＲＴＰ通信を行うためのパケット化を行い、ＲＴＰ通話が不可能な場合は履歴テーブルを参照して決めたポートに対応したプロトコル（例えば、ＨＴＴＰ等）によるパケット化を行う（Ｓ６）。ＩＰパケット化された音声データはＬＡＮインタフェース部１７へ渡され、ネットワークへ出力される（Ｓ７）。
【００２０】
図２の動作フローで、ＲＴＰ通信が可能かどうかを判断する際に（Ｓ３）、ＲＴＰポート確認部は、予め定めたＲＴＰポートで通話することが可能かどうかを確認するためサーチパケットを送出する。図３は、その場合の動作フローを示す。サーチパケットに対するレスポンスがあった場合に通話が可能と判断し（Ｓ１３）、ＲＴＰによる音声データの送受信が出来る。ステップ１３以外は、図２と同様である。
【００２１】
サーチパケットとしては、例えば、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）のｐｉｎｇを用いる。すなわちＩＰ端末は、Ｅｃｈｏ  Ｒｅｑｕｅｓｔを送り、受け取った相手側端末が、これに応答してＥｃｈｏ  Ｒｅｐｌｙを返送する。ＩＰ端末からのｐｉｎｇによる要求に対して応答がない場合、そのＲＴＰポートでの通話が不可と判断する。
【００２２】
公知のポートで通信できない場合に音声データの送受信が行えないため、本発明では、データ通信の履歴テーブル１４を用いて、通話先のデータ通信可能な通信路を自動的に選択して相手先とデータの送受信を可能にする。履歴テーブル１４には、通信の日時順にそのポート番号が記録され、さらにそのポート番号の通信成功回数が記録されている。その中から、通信の可能性のあるポートへ接続して、音声データの送受信を可能にしている。
【００２３】
図４は、履歴テーブルを用いた場合の動作を示すフローチャートである。サーチパケットを送出して、ポートの確認を行い（Ｓ２１）、公知の通信ポートで通信可能な場合（Ｓ２２）、そのポートを通信用ポートに割当てて履歴テーブルに記録する（Ｓ２６）。公知の通信ポートで通信できない場合、履歴テーブルの中で通話先の履歴が複数あるときには、まず一番最近に通信が成功したものについて１番目の通信路候補として選択する（Ｓ２３）。そのポートで通信できない場合、過去の履歴の中から通信の成功例が多いものを通信路として選択する（Ｓ２４）。それらの通信可能なポートを通信用ポートに割当てて履歴テーブルに記録する（Ｓ２６）。以上の順で通信の可能性のあるポートへ接続して音声データの送受信を可能にする。
【００２４】
図５は、図１の構成に対して、ＩＰ端末が、自身と通話先のＩＰアドレスを確認するＩＰアドレス確認部１８を有する場合の構成を示す。これは送信元のＩＰ端末と通話先端末がプライベートＩＰアドレスを持つとき、同じネットワークにあることを確認して、ＲＴＰによる適切な音声データの送受信を行う手段である。これによって、ユーザーがネットワークの状況を意識せずに、通信効率の良い音声データの送受信を行うことが可能となる。
【００２５】
図６は、送信元端末と通話先端末が、同じネットワーク内でプライベート（ローカル）ＩＰアドレスを持つときの構成例を示す。同一ネットワーク内ではローカルＩＰアドレスを用い、ファイアウォールを介して他のネットワークと通信を行う場合は、ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）サーバによって、グローバルＩＰアドレスとローカルＩＰアドレスの変換を行う。端末Ａと端末Ｂは同一ネットワークにあり、ファイアウォールを介さないため、ＲＴＰによる適切な音声データの送受信を行うことができる。
【００２６】
次に図７、図８、図９を参照して、第２の実施形態を説明する。
【００２７】
図７は、本実施形態のＩＰ端末の構成例を示し、公知のポートで通信が出来ない場合に、ＩＰ端末が自身のＩＰアドレスとニックネームをサーバに送信するアドレス送信部１９ａと、通話相手のニックネームを送信してＩＰアドレスと通話可能なポートを要求するアドレス要求部１９ｂを有する。なお、ニックネームとは、通常使用する通称名称であり、例えば、「ｍｏｎａｉ＠ｎｅｃ」等である。
【００２８】
図８は、ニックネーム・サーバの構成例を示し、ネットワーク上のニックネームとＩＰアドレス、通信可能なポートをアドレステーブル５１に記録する。ＩＰ端末１０がニックネーム・サーバ５０に通話相手のニックネームを送信すると、ニックネーム・サーバのアドレス解決部５２は通話先のＩＰアドレスと通話可能なポートを通知するルーティング機能を有する。これによりＩＰ端末がこの通話可能なポートを用いて音声データの送受信が可能となる。ニックネーム・サーバを利用することにより、電話番号やＵＲＬといった覚えにくい対象を指定することなく通信相手にアクセスすることが可能になる。
【００２９】
図９は、ニックネーム・サーバを用いた場合の通信図である。ＩＰ端末は、ニックネーム・サーバから通知された通話先のＩＰアドレスに対して、通話可能なポートを用いることによって、ファイアウォールを越えて通話相手と音声通話を行うことができる。
【００３０】
図１０は、ニックネーム・サーバと履歴テーブルを用いた場合の動作を示すフローチャートである。まず、音声入出力部１１において音声を入力する（Ｓ３１）。次にデジタル・アナログ部１２において音声のアナログデータをデジタルデータへ変換する（Ｓ３２）。そして、ニックネーム・サーバに通話相手のニックネームを送信してＩＰアドレスと通話可能なポートを要求し（Ｓ３３）、ニックネーム・サーバより通知される通話可能なポートを利用して通信を試みる（Ｓ３４）。この場合、サーチパケットを用いてＲＴＰ通信が可能かどうかを判断する。その通信が失敗した場合には自身の履歴テーブルを用いて通信路を決定し（Ｓ３５）、再度音声データ通信を試みる。過去の通信履歴とニックネーム・サーバからの通話可能なポートを用いて音声データ通信可能なポートを自動で判断する（Ｓ３６）。デジタル化された音声を呼制御部１５へ渡し音声通話のための呼制御を行い（Ｓ３７）、さらに音声データをＩＰ通信部１６へ渡し、ＲＴＰ通話が可能な場合はＲＴＰ通信を行うためのパケット化を行い、ＲＴＰ通話が不可能な場合は通信可能なポートに対応したプロトコルによるパケット化を行う、（Ｓ３８）。ＩＰパケット化された音声データはＬＡＮインタフェース部１７へ渡され、ネットワークへ出力される（Ｓ３９）。
【００３１】
【発明の効果】
以上説明したように、本発明による第１の効果は、ファイアウォールがあってもＲＴＰによる音声データの送受信が可能かどうかを自動的に判断できることである。その理由は、予め定めたＲＴＰポートで通信が可能かどうかを判断するサーチパケットを送出し、そのパケットに対するレスポンスによって通話が可能かどうかを判断するためである。
【００３２】
第２の効果は、公知の通信ポートで通信できない場合にも音声データの送受信が可能になるように自動的に判断することである。その理由は、ＩＰ端末が自身に備えた履歴テーブルを参照することにより、通話先とのデータ通信路を自動的に選択するためである。
【００３３】
第３の効果は、ニックネーム・サーバを利用することにより、通話相手のニックネームさえ覚えていれば、通信相手にアクセスすることが可能になることである。
【図面の簡単な説明】
【図１】本発明の音声データ送受信自動選択システムの構成図である。
【図２】本発明の動作説明フローチャートである。
【図３】サーチパケットを送出してポートを確認する場合の動作説明フローチャートである。
【図４】履歴テーブルを用いた場合の動作を示すフローチャートである。
【図５】ＩＰ端末がＩＰアドレス確認部を有する場合の構成図である。
【図６】送信元端末と通話先端末が、同じネットワーク内にあるときの構成図である。
【図７】ＩＰ端末がアドレス送信部とアドレス要求部を有する場合の構成図である。
【図８】ニックネーム・サーバの構成図である。
【図９】ニックネーム・サーバを用いた場合の通信図である。
【図１０】ニックネーム・サーバと履歴テーブルを用いた場合の動作を示すフローチャートである。
【符号の説明】
１０  ＩＰ端末
１１  音声入出力部
１２  デジタル・アナログ処理部
１３  ＲＴＰポート確認部
１４  履歴テーブル
１５  呼制御部
１６  ＩＰ通信部
１７  ＬＡＮインタフェース部
１８  ＩＰアドレス確認部
１９ａ  アドレス送信部
１９ｂ  アドレス要求部
２０  ＩＰ端末
３０  ファイアウォール
４０  ＩＰネットワーク
【図１】
2004186748.tif 000003
【図２】
2004186748.tif 000004
【図３】
2004186748.tif 000005
【図４】
2004186748.tif 000006
【図５】
2004186748.tif 000007
【図６】
2004186748.tif 000008
【図７】
2004186748.tif 000009
【図８】
2004186748.tif 000010
【図９】
2004186748.tif 000011
【図１０】
2004186748.tif 000012