(57)【要約】【課題】トラフィック効率を向上して音声や画像の劣化を防止することができる音声画像伝送方法を提供することを目的とする。【解決手段】ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのＲＴＰパケット１３のＲＴＰデータ１７のサイズを可変にし、ＩＰパケット１１の順番を決定するデータとしてサイズをＲＴＰヘッダ１６のシーケンス番号に代えて用いることにより、ＲＴＰヘッダのシーケンス番号を削除することができ、データ量を削減し、結果として通話トラフィックの効率が改善されて音声や画像の品質劣化が防止される。【選択図】図１
2005167458.tif 000002
【特許請求の範囲】
【請求項１】
ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
リアルタイム伝送のためのＲＴＰパケットのＲＴＰデータのサイズを可変にし、ＩＰパケットの順番を決定するデータとして前記サイズをＲＴＰヘッダのシーケンス番号に代えて用いることを特徴とする音声画像伝送方法。
【請求項２】
ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
ＩＰパケットの順番を決定するデータとしてＵＤＰパケットのＵＤＰヘッダのポート番号データをＲＴＰヘッダのシーケンス番号に代えて用いることを特徴とする音声画像伝送方法。
【請求項３】
ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
イーサネット（登録商標）のタイプフィールドにおいて普段使用しない値を予約し、前記予約した値をＲＴＰヘッダのシーケンス番号に代えて用いることを特徴とする音声画像伝送方法。
【請求項４】
ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
ＵＤＰパケットのＵＤＰヘッダにおいて予約されたポート番号の短縮化を行うことを特徴とする音声画像伝送方法。
【請求項５】
ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
ＵＤＰパケットのＵＤＰヘッダにおいて所定のデータを削除して独自のトランスポート層を作ることを特徴とする音声画像伝送方法。
【請求項６】
ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
ＩＰパケット中のＩＰヘッダのパディングに音声データを入れてトラフィックの効率を向上させることを特徴とする音声画像伝送方法。
【請求項７】
ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
ＲＴＣＰやＳＮＭＰ、トラフィック制御パラメータ等によって検知されたトラフィックの状況に応じて、ＵＤＰパケットのＵＤＰヘッダやＲＴＰパケットのＲＴＰヘッダの圧縮の可否を自動的に変更することを特徴とする音声画像伝送方法。
【請求項８】
ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
ＵＤＰパケットのＵＤＰヘッダの宛先ポート番号から同じ送信方向の音声データをまとめて送り、送信先のルーターで個々の送り先に音声データを分けＵＤＰヘッダの削除を行うことを特徴とする音声画像伝送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＶｏＩＰ技術を利用して音声データや画像データをリアルタイムで伝送する音声画像伝送方法に関するものである。
【背景技術】
【０００２】
ＶｏＩＰ技術を利用したＩＰ電話の通話のしくみについて、また音声データを符号化しＩＰパケット化してデータ伝送する場合のＩＰパケットのフォーマットについて、図２、図８を用いて説明する。図２（ａ）、（ｂ）、（ｃ）はＶｏＩＰパケットのフォーマットを示すフォーマット図であり、図８はＩＰ電話の基本的な通話のしくみを示す説明図である。
【０００３】
図２において、２はＶｏＩＰパケット（単に、「ＩＰパケット」ともいう）フォーマット、３はＲＴＰヘッダフォーマット、４はＵＤＰパケットフォーマット、４１は発信元ポート番号、４２は宛先ポート番号、４３はＵＤＰデータ長、４４はＵＤＰチェックサム、４５はデータである。また、図８において、１０１はマイク、１０２は符号器、１０３は無音圧縮器、１０４は音声圧縮器、１０５はパケット生成器、１０６はＩＰネットワーク、１０７は揺らぎ吸収バッファ、１０８はパケット分解器、１０９は音声無音伸長器、１１０は音声補間器、１１１は復号器、１１２はスピーカである。
【０００４】
ＩＰ電話の通話のプロセスは、まず、送話側の音声（アナログ）情報を符号器１０２でデジタルデータに変換する。このままではデータ量が大きいためデジタルデータの圧縮を無音圧縮器１０３および音声圧縮器１０４で行う。その圧縮方式では、ＩＴＵ−Ｔ勧告により電話網を仮定した音声圧縮・伸張技術を規定している。現在最も一般的に使用されている音声圧縮・伸張方式は、Ｇ．７１１１，Ｇ．７２９（無音圧縮内蔵），Ｇ．７２３．１の３種類である。そして、次に、圧縮されたデジタルデータをＩＰネットワーク６に送り出す為にパケット生成器１０５でＶｏＩＰパケット（単に、「ＩＰパケット」ともいう）化しなければならない。
【０００５】
図２に示すように、通常のＩＰパケットのフォーマットは、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ、音声データで構成される。個々の機能を簡単に説明する。ＩＰヘッダにはＩＰパケットの宛先ＩＰアドレスや優先制御の情報等が含まれ、ＵＤＰヘッダは再送のないトランスポート機能を提供する。ＲＴＰヘッダにはリアルタイム転送の為の時間情報等が含まれ、最後の音声データは、音声圧縮により符号化された１０バイトのいくつかの音声フレームが前記の各ヘッダとともにパケット化される。
【０００６】
このようにＩＰパケット化されたデータは、ＩＰネットワーク６上で他のＩＰパケットと同様に宛先ＩＰアドレスを見て転送される。転送された受話側では、ＩＰネットワーク６上で発生したジッタ（遅延揺らぎ、送信側で一定間隔で送出したＩＰパケットが受信側では等間隔には到着しない現象）が発生し、音声の到着間隔が長くなると、通話中に音声がブツブツと途切れる状態が発生する。このジッタを吸収して円滑に再生されるように揺らぎ吸収バッファ１０７を設けている。この揺らぎ吸収バッファ１０７でＩＰネットワーク６内で発生したジッタを抑えると、あとは送話側の処理と逆の処理を行う。まず、ＩＰネットワーク６上に送り出す為にパケット化したデータをパケット分解器１０８でパケット分解する。次に、圧縮された音声データを音声無音伸長器１０９で伸長する。そして、一部音声データで欠落した部分は音声補間器１１０で音声補間を行い、復号器１１１でデジタルデータからアナログデータに戻して、スピーカ１１２より送話側からの音声を聞くことができ、通話することができる。
【０００７】
しかし、ＶｏＩＰ技術を利用したＩＰ電話におけるデータ転送においては、送信側の符号化時間やＩＰパケット化時間、受信側の揺らぎ吸収バッファ時間や復号化時間、ＩＰネットワーク遅延時間等により相手の返事が遅くなると言った遅延の問題や、パケットの欠落による音声の途切れ、上記に記載したジッタ（遅延揺らぎ）により通話中の音声がブツブツと途切れると言った問題が発生する。これらの音声のリアルタイム性や音声品質（通話品質）は従来のアナログ電話では問題にならないもので、ＩＰ電話においてこれらの問題が発生する。その大きな要因としてはＩＰネットワークのトラフィックの増加が挙げられる（例えば特許文献１参照）。
【特許文献１】特開２００１−２９８４７９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
このように、従来の音声伝送方法では、ＩＰネットワークのトラフィックが増加すると、送信側の符号化時間や、ＩＰパケット化時間、受信側の揺らぎ吸収バッファ時間、復号化時間、ＩＰネットワーク遅延時間等により相手の返事が遅くなると言った遅延の問題や、パケットの欠落による音声の途切れ、ジッタにより通話中の音声がブツブツと途切れると言った問題点を有していた。
【０００９】
この音声画像伝送方法では、トラフィック効率を向上して音声や画像の劣化を防止することが要求されている。
【００１０】
本発明は、この要求を満たすため、トラフィック効率を向上して音声や画像の劣化を防止することができる音声画像伝送方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するために本発明の音声画像伝送方法は、ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのＲＴＰパケットのＲＴＰデータのサイズを可変にし、ＩＰパケットの順番を決定するデータとしてサイズをＲＴＰヘッダのシーケンス番号に代えて用いる構成を備えている。
【００１２】
これにより、トラフィック効率を向上して音声や画像の劣化を防止することができる音声画像伝送方法が得られる。
【発明の効果】
【００１３】
本発明の音声画像伝送方法は、ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのＲＴＰパケットのＲＴＰデータのサイズを可変にし、ＩＰパケットの順番を決定するデータとしてサイズをＲＴＰヘッダのシーケンス番号に代えて用いることにより、ＲＴＰヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削除する事ができ、従って、通話トラフィックの効率が向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
【００１４】
さらに、ＩＰパケットの順番を決定するデータとしてＵＤＰパケットのＵＤＰヘッダのポート番号データをＲＴＰヘッダのシーケンス番号に代えて用いることにより、ＲＴＰヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
【００１５】
さらに、イーサネット（登録商標）のタイプフィールドにおいて普段使用しない値を予
約し、予約した値をＲＴＰヘッダのシーケンス番号に代えて用いることにより、ＲＴＰヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
【００１６】
さらに、ＵＤＰパケットのＵＤＰヘッダにおいて予約されたポート番号の短縮化を行うことにより、全体のデータ量を削減する事ができるので、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
【００１７】
さらに、ＵＤＰパケットのＵＤＰヘッダにおいて所定のデータを削除して独自のトランスポート層を作ることにより、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
【００１８】
さらに、ＩＰパケット中のＩＰヘッダのパディングに音声データを入れてトラフィックの効率を向上させることにより、音声や画像の品質劣化を防止することができるという有利な効果が得られる。
【００１９】
さらに、ＲＴＣＰやＳＮＭＰ、トラフィック制御パラメータ等によって検知されたトラフィックの状況に応じて、ＵＤＰパケットのＵＤＰヘッダやＲＴＰパケットのＲＴＰヘッダの圧縮の可否を自動的に変更することにより、通話トラフィックの効率を最適にすることができるので、音声や画像の品質劣化を防止することができるという有利な効果が得られる。
【００２０】
さらに、ＵＤＰパケットのＵＤＰヘッダの宛先ポート番号から同じ送信方向の音声データをまとめて送り、送信先のルーターで個々の送り先に音声データを分けＵＤＰヘッダの削除を行うことにより、同じ送信方向の音声データをまとめて送ることができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
【発明を実施するための最良の形態】
【００２１】
本発明は、通話トラフィックの効率を向上して音声や画像の品質劣化を防止するという目的を、ＲＴＰヘッダのシーケンス番号や所定のデータの削除、データの短縮化などにより実現した。
【００２２】
上記課題を解決するためになされた第１の発明は、ＶｏＩＰ技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのＲＴＰパケットのＲＴＰデータのサイズを可変にし、ＩＰパケットの順番を決定するデータとしてサイズをＲＴＰヘッダのシーケンス番号に代えて用いることとしたものであり、ＲＴＰヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削除する事ができ、従って、通話トラフィックの効率が向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
【００２３】
上記課題を解決するためになされた第２の発明は、ＩＰパケットの順番を決定するデータとしてＵＤＰパケットのＵＤＰヘッダのポート番号データをＲＴＰヘッダのシーケンス番号に代えて用いることとしたものであり、ＲＴＰヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
【００２４】
上記課題を解決するためになされた第３の発明は、イーサネット（登録商標）のタイプ
フィールドにおいて普段使用しない値を予約し、予約した値をＲＴＰヘッダのシーケンス番号に代えて用いることとしたものであり、ＲＴＰヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
【００２５】
上記課題を解決するためになされた第４の発明は、ＵＤＰパケットのＵＤＰヘッダにおいて予約されたポート番号の短縮化を行うこととしたものであり、全体のデータ量を削減する事ができるので、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
【００２６】
上記課題を解決するためになされた第５の発明は、ＵＤＰパケットのＵＤＰヘッダにおいて所定のデータを削除して独自のトランスポート層を作ることとしたものであり、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
【００２７】
上記課題を解決するためになされた第６の発明は、ＩＰパケット中のＩＰヘッダのパディングに音声データを入れてトラフィックの効率を向上させることとしたものであり、音声や画像の品質劣化を防止することができるという作用・効果を有する。
【００２８】
上記課題を解決するためになされた第７の発明は、ＲＴＣＰやＳＮＭＰ、トラフィック制御パラメータ等によって検知されたトラフィックの状況に応じて、ＵＤＰパケットのＵＤＰヘッダやＲＴＰパケットのＲＴＰヘッダの圧縮の可否を自動的に変更することとしたものであり、通話トラフィックの効率を最適にすることができるので、音声や画像の品質劣化を防止することができるという作用・効果を有する。
【００２９】
上記課題を解決するためになされた第８の発明は、ＵＤＰパケットのＵＤＰヘッダの宛先ポート番号から同じ送信方向の音声データをまとめて送り、送信先のルーターで個々の送り先に音声データを分けＵＤＰヘッダの削除を行うこととしたものであり、同じ送信方向の音声データをまとめて送ることができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
【００３０】
（実施の形態１）
本発明の実施の形態１による音声画像伝送方法について、図１、図２を用いて説明する。図１は、本発明の実施の形態１による音声画像伝送方法を説明するためのＶｏＩＰパケットのフォーマットを示すフォーマット図である。
【００３１】
図１において、１１はＩＰパケット、１２はＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）パケット、１３はＲＴＰ（Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）パケット、１４はＩＰヘッダ、１５はＵＤＰヘッダ、１６はＲＴＰヘッダ、１７はＲＴＰデータである。
【００３２】
図１に示すように、ＩＰパケット１１はＩＰヘッダ１４とＵＤＰパケット１２とから成り、ＵＤＰパケット１２はＵＤＰヘッダ１５とＲＴＰパケット１３とから成り、ＲＴＰパケット１３はＲＴＰヘッダ１６とＲＴＰデータ１７とから成る。
【００３３】
図２（ａ）に音声４フレームの場合のＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）パケットフォーマット２を示し、図２（ｂ）にＲＴＰヘッダフォーマット３を、図２（ｃ）にＵＤＰパケットフォーマット４を示す。
【００３４】
本実施の形態においては、ＲＴＰデータ１７のデータサイズを１〜１０の１０段階に可変できる。例えば、データサイズ１のものをシーケンス番号１とし、データサイズ２のものをシーケンス番号２とする。以下、データサイズ３はシーケンス番号３、データサイズ４はシーケンス番号４とし、データサイズ１０でシーケンス番号１０まで行くと再びデータサイズ１となり、このデータサイズ１１のものをシーケンス番号１１とする。このように、データサイズを可変することで、パケットのシーケンス番号に代用することができる。つまり、可変データサイズをシーケンス番号に代えて用いる。これにより、ＲＴＰヘッダフォーマット３の中のシーケンス番号を削除する事が可能となる。
【００３５】
以上のように本実施の形態によれば、シーケンス番号を削除することができるので、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
【００３６】
（実施の形態２）
本発明の実施の形態２による音声画像伝送方法について、図２を用いて説明する。
【００３７】
図２（ｃ）にＵＤＰパケットフォーマット４を示す。その構成は、発信元ポート番号４１、宛先ポート番号４２、ＵＤＰデータ長４３、ＵＤＰチェックサム４４、データ４５となる。（表１）に予約されたポート番号（０〜７７）を示す。ポート番号については以下に説明する。
【００３８】
【表１】
2005167458.tif 000003
【００３９】
ポート番号は１６ビットの多重化識別子で、アプリケーション層からトランスポート層への接続口を意味しており、特定の上位プロトコル（アプリケーション・プロトコル）を識別する為に番号が予約されている。これは、ノード（接続ポイント）における処理の効率化の為に予約されており、０〜１０２３番まではウェルノウン（予約された）ポート番号となっている。例えば（表１）で２５番のポート番号は、ｓｍｔｐ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を指定することになる。このように、ポ
ート番号はノード間でのデータ通信において、同時に複数のデータ流を並列的に転送する為の多重化識別子として使用される。ポート番号０〜１０２３は予約されているが、１０２４以上のポート番号は予約されていない為、各アプリケーションが自由に使用する事が可能である。また、１０２４〜４９１５１の番号はレジスタード・ポート番号で、番号とアプリケーションの関係をＩＡＮＡ（アイアナ、Ｉｎｔｅｒｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ  Ａｕｔｈｏｒｉｔｙ：インターネットにおける番号（ＩＰアドレスなど）およびパラメータなどの管理を行う組織）に登録する事が可能である。更に、４９１５２〜６５５３５の番号はダイナミック／プライベート・ポート番号で、ユーザーが自由に利用する事が可能である。
【００４０】
本実施の形態では、ユーザーが自由に利用できるポート番号をＲＴＰヘッダフォーマット３のシーケンス番号に代用させてＲＴＰヘッダのシーケンス番号を削除する。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
【００４１】
（実施の形態３）
本発明の実施の形態３による音声画像伝送方法について、図２、図３を用いて説明する。図３（ａ）、（ｂ）、（ｃ）はイーサネット（登録商標）のフレーム構造を示すデータ図である。
【００４２】
図３において、５ａ、５ｂ、５ｃはイーサネット（登録商標）フレームで、イーサネット（登録商標）フレームにはＤＩＸイーサネット（登録商標）とＩＥＥＥ  ８０２．３とがあり、更に後者の方は、オプションでＶＬＡＮ（Ｖｉｒｔｕａｌ  ＬＡＮ）タグヘッダを利用す場合とに分けられる。前者のＤＩＸイーサネット（登録商標）とは、ＤＥＣ（現在のコンパック）、Ｉｎｔｅｌ、Ｘｅｒｏｘの３社が商用に開発した「Ｅｔｈｅｒｎｅｔ（登録商標）」（１０Ｍｂｐｓ）のことを言う。後者の方は、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ、アメリカ電気電子技術者協会）が標準化した規格を言う。ＤＩＸイーサネット（登録商標）とＩＥＥＥ  ８０２．３のフレーム・フォーマットは、ＤＩＸイーサネット（登録商標）の「タイプ」フィールドがＩＥＥＥ  ８０２．３の「長さ／タイプ」フィールドとして使われている点と、図３（ｃ）のＩＥＥＥ  ８０２．３にオプション・フィールドが追加された点以外は基本的には同じである。
【００４３】
フレームの構造は、ＬＡＮに接続しているインターフェイスにフレーム送信の開始を認識させ、同期をとるタイミングを与える為の信号でＤＩＸでは８オクテット（１オクテットは８ビットで、８オクテットは６４ビット）、ＩＥＥＥ  ８０２．３では７オクテット（５６ビット）のプリアンブル５１と、サイズが６オクテット（４８ビット）のフィールドで、宛先となるステーションのインターフェイスのＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ
Ｃｏｎｔｒｏｌ：媒体アクセス制御）アドレスを設定する宛先アドレス５２と、サイズが６オクテット（４８ビット）のフィールドで、フレームを送信したインターフェイスのＭＡＣアドレスを設定する送信元アドレス５３と、ＤＩＸイーサネット（登録商標）では「タイプ」、ＩＥＥＥ  ８０２．３では「長さ／タイプ」と定義され、サイズが２オクテット（１６ビット）のフィールドであるタイプ（長さ／タイプ）５４とを有し、ＤＩＸイーサネット（登録商標）とＩＥＥＥ  ８０２．３のフレーム・フォーマットとで実質的に違うのはタイプ、長さ／タイプのフィールドだけである。このタイプフィールドは多重化／多重分離のために、次に続く「データ」フィールドに格納する上位層プロトコルを示すＩＤを設定する。データ５５には、最小４６オクテットから最大１５００オクテットまでのデータを格納することができ、もしデータが４６オクテット未満の場合にはパディングデータを付加し４６オクテットにする。ＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ）５６はフレームのエラーを検出するための４オクテットのフィールドで、宛先アド
レス、送信元アドレス、長さ／タイプ、データの各フィールドから計算したＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）値を設定する。ＳＦＤ（Ｓｔａｒｔ  Ｆｒａｍｅ  Ｄｅｌｉｍｉｔｅｒ）５７は１オクテットのフィールドで、ＳＦＤは「１０１０１０１１」というパターンでありＤＩＸと同じである。プリアンブル５１を受信中に、その最後が「１０１０１０１１」となっていることを検出すると、その次のビットから宛先アドレス部が始まると解釈される。そしてＯＰ（オプション）フィールド５８はサイズが４オクテット（３２ビット）のフィールドで、ＶＬＡＮ用のタグヘッダを指定することができる。イーサネット（登録商標）フレームは以上で構成されます。
【００４４】
本実施の形態では、タイプ５４のデータをＲＴＰヘッダフォーマット３のシーケンス番号に代用させる。「長さ／タイプ」フィールドはその値が１５００以下の場合はデータのサイズと判断し、１５３６（０ｘ０６００）以上の場合はタイプと判断する。１５０１〜１５３５については未定義となっている。つまり、この１５３６以上のタイプの値で普段使用していないものや１５０１〜１５３５の未定義の値をＲＴＰヘッダフォーマット３のシーケンス番号に代用させてＲＴＰヘッダフォーマット３のシーケンス番号のデータを削除する。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
【００４５】
（実施の形態４）
本発明の実施の形態４による音声画像伝送方法について、図２、図４を用いて説明する。図４（ａ）、（ｂ）はＵＤＰヘッダを示すデータ図である。
【００４６】
図２（ｃ）にＵＤＰパケットフォーマット４を示す。その構成は、発信元ポート番号４１、宛先ポート番号４２、ＵＤＰデータ長４３、ＵＤＰチェックサム４４、データ４５となる。（表１）に予約されたポート番号（０〜７７）を示す。ポート番号については、実施の形態２で説明したので省略する。
【００４７】
本実施の形態では、ＵＤＰヘッダは上記のように発信元ポート番号４１、宛先ポート番号４２、ＵＤＰデータ長４３、ＵＤＰチェックサム４４で構成されるが、図４でポート番号は１６ビットの多重化識別子で、予め特定の上位プロトコル（アプリケーション・プロトコル）を識別する為に番号が予約（０〜１０２３番まで）されている。つまり１０ビットが予約されたビットとなり、残りの６ビットは例えば全てゼロを入れてポート番号の短縮化を行い、図４（ｂ）に示すような短縮データを事前に登録しておく。このようにしてＵＤＰヘッダのデータ量を削減する。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
【００４８】
（実施の形態５）
本発明の実施の形態５による音声画像伝送方法について、図２、図５を用いて説明する。図５はＵＤＰヘッダを示すデータ図である。
【００４９】
実施の形態４で説明したように、ＵＤＰパケットフォーマット４の構成は、発信元ポート番号４１、宛先ポート番号４２、ＵＤＰデータ長４３、ＵＤＰチェックサム４４、データ４５となる。
【００５０】
本実施の形態では、ＵＤＰパケットフォーマット４として独自の音声用のパケットフォーマット、つまり独自のトランスポート層を作成する。これは、従来６４ビットのＵＤＰヘッダを例えば図５のように大した情報でないＵＤＰデータ長４３やＵＤＰチェックサム４４を削除して発信元及び宛先のポート番号のみで構成して独自のトランスポート層を作
ることである。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
【００５１】
（実施の形態６）
本発明の実施の形態６による音声画像伝送方法について、図６を用いて説明する。図６はＩＰヘッダのフォーマットを示すフォーマット図である。（表２）に、各フィールドの名称とビット数を示す。
【００５２】
【表２】
2005167458.tif 000004
【００５３】
図６において、ＩＰヘッダフォーマット６の構成は、ＩＰのバージョンを表すＶｅｒｓｉｏｎ（バージョン）６１と、インターネットのヘッダ長を表すＩＨＬ（ヘッダ長）６２と、優先度や最低限の遅延で送ることや最大限のスループットで送ること等のＩＰパケットの品質を表すＴｙｐｅ  ｏｆ  Ｓｅｒｖｉｃｅ（サービスタイプ）６３と、パケット長を表すＴｏｔａｌ  Ｌｅｎｇｔｈ（パケット長）６４と、分割されたパケットの組立てを補助する為に送信者によって割当てられる識別値を表すＩｄｅｎｔｉｆｉｃａｔｉｏｎ（識別子）６５と、ＩＰパケットを分割する際に使用するＦｌａｇｓ（フラグ）６６と、分割されたパケットが元のデータのどこに位置するかを表すＦｒａｇｍｅｎｔ  Ｏｆｆｓｅｔ（フラグメントオフセット）６７と、パケットがインターネット上で生存できる事が許される最大時間を示すＴｉｍｅ  ｔｏ  Ｌｉｖｅ（生存時間）６８と、ＩＰパケットで使用される上位のレベルのプロトコルを示すＰｒｏｔｏｃｏｌ（プロトコル）６９と、ヘッダだけのチェックサムを表すＨｅａｄｅｒ  Ｃｈｅｃｋｓｕｍ（ヘッダチェックサム）７０と、送信元のＩＰアドレスを示すＳｏｕｒｃｅ  Ａｄｄｒｅｓｓ（送信元ＩＰアドレス）７１と、宛先のＩＰアドレスを示すＤｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ（宛先ＩＰアドレス）７２と、セキュリティー等の昨日を付加する為のＯｐｔｉｏｎ（オプション）７３と、ＩＰヘッダが３２ビット境界で終了する事を保証する為に使用されるＰａｄｄｉｎｇ（パディング）７４とで構成される。
【００５４】
本実施の形態では、普段ほとんど使用されないＯｐｔｉｏｎ（オプション）７３と、通常０の値が入れてあるＰａｄｄｉｎｇ（パディング）７４とに音声データを入れることができるものとする。これにより、ＩＰパケットの未使用領域を有効に活用することで、通話トラフィックの効率が向上して音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
【００５５】
（実施の形態７）
本発明の実施の形態７による音声画像伝送方法について説明する。
【００５６】
ＲＴＰは、リアルタイム伝送のために映像や音声のデータを運搬するパケットに時間的な情報を付加して転送するプロトコルであるが、データを転送するだけのプロトコルで通信の状況を伝える仕組みは持っていない。ネットワークが十分空いている時はこれでも問題ないが、ネットワークが混雑している場合は、通信状況を検知し、データの転送速度や転送量を減少させて、ネットワークの混雑がさらに悪化することを避ける必要がある。また、受信側の受信速度が転送速度に追いつかない時にも同様に、検知した状況によって転送側でデータ転送速度の調節を行う必要が出てくる。このように、ネットワークの通信状態を検知する機能として、ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ（ＲＴＣＰ）や、Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）、ＰＩＮＧといったものがある。ＲＴＣＰはＲＴＰとペアで用いられ、ＲＴＰが持たない通信状態を伝える機能がある。ＳＮＭＰは簡易ネットワーク管理プロトコルで、ネットワーク機器を管理する為の標準的なものである。ＰＩＮＧは、ネットワーク層の通信が可能かどうかを確認し、かつ送信元では相手側とのパケットの往復時間を計算する事ができる。
【００５７】
本実施の形態では、上記のＲＴＣＰやＳＮＭＰ、ＰＩＮＧ等でネットワークの通信状態を常にモニターして検知する。その検知した通信状態でネットワークが混雑してきた場合、その状況に応じてＵＤＰヘッダやＲＴＰヘッダのヘッダ圧縮を自動的に制御できるようにしておく。このようにすることにより、データの転送量を減少させてネットワークの混雑がさらに悪化することが避けられ、通話トラフィックの効率が悪化せず音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
【００５８】
（実施の形態８）
本発明の実施の形態による音声画像伝送方法について、図７を用いて説明する。図７はＩＰ電話のしくみを示す説明図である。
【００５９】
図７において、８はＩＰネットワーク、８１〜８４、８９〜９２はＩＰ電話機、８５〜８７はルーター、８８はサーバーである。
【００６０】
ＩＰ電話機８１〜８４はルーター８５に接続されている。また、ＩＰ電話機８９〜９２はルーター８６に接続されている。
【００６１】
ＩＰ電話機８１とＩＰ電話機８９が通話する場合、ＩＰ電話機８１でＩＰパケット化されたデータがルーター８５に送られる。ルーター８５では通信相手を見つけたり、相手呼出中の情報伝達などの制御データのＩＰパケットをサーバー８８とやり取りする。そこで通話相手がＩＰ電話機８９であることを確認できると、ＩＰ電話機８９が接続されているルーター８６にＩＰパケット（音声データ）が送られ、ＩＰ電話機８９と通話することができる。
【００６２】
ここで、ＩＰ電話機８１から８４まで発信されたとする。ルーター８５では、各ＩＰ電話機がどのＩＰ電話機と通話したいのかをサーバー８８と制御データのやり取りを行い確認する。今回すべてルーター８６に接続されたＩＰ電話機８９から９２だったとすると、ルーター８５ではルーター８６への同一方向の音声データと言うことで、一つのＩＰパケットにまとめてルーター８６へＩＰパケットを送る。ルーター８６では受けたデータを再び個々のＩＰ電話機へのＩＰパケットに変換して通話ができるようにする。このようにＩＰネットワーク８上では、同一送信方向の音声データをまとめることでネットワークの混
雑が悪化することが避けられ、通話トラフィックの効率が悪化せず、音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
【産業上の利用可能性】
【００６３】
本発明は、ＶｏＩＰ技術を利用して音声データや画像データをリアルタイムで伝送する音声画像伝送方法に関し、トラフィック効率を向上して音声や画像の劣化を防止することができる。
【図面の簡単な説明】
【００６４】
【図１】本発明の実施の形態１による音声画像伝送方法を説明するためのＶｏＩＰパケットのフォーマットを示すフォーマット図
【図２】（ａ）ＶｏＩＰパケットのフォーマットを示すフォーマット図、（ｂ）ＶｏＩＰパケットのフォーマットを示すフォーマット図、（ｃ）ＶｏＩＰパケットのフォーマットを示すフォーマット図
【図３】（ａ）イーサネット（登録商標）のフレーム構造を示すデータ図、（ｂ）イーサネット（登録商標）のフレーム構造を示すデータ図、（ｃ）イーサネット（登録商標）のフレーム構造を示すデータ図
【図４】（ａ）ＵＤＰヘッダを示すデータ図、（ｂ）ＵＤＰヘッダを示すデータ図
【図５】ＵＤＰヘッダを示すデータ図
【図６】ＩＰヘッダのフォーマットを示すフォーマット図
【図７】ＩＰ電話のしくみを示す説明図
【図８】ＩＰ電話の基本的な通話のしくみを示す説明図
【符号の説明】
【００６５】
２    ＶｏＩＰパケットフォーマット
３    ＲＴＰヘッダフォーマット
４    ＵＤＰパケットフォーマット
５    イーサネット（登録商標）フレーム
６    ＩＰヘッダフォーマット
８    ＩＰネットワーク
１１    ＩＰパケット
１２    ＵＤＰパケット
１３    ＲＴＰパケット
１４    ＩＰヘッダ
１５    ＵＤＰヘッダ
１６    ＲＴＰヘッダ
１７    ＲＴＰデータ
４１    発信元ポート番号
４２    宛先ポート番号
４３    ＵＤＰデータ長
４４    ＵＤＰチェックサム
４５    データ
５１    プリアンブル
５２    宛先アドレス
５３    送信元アドレス
５４    タイプ
５５    データ／ＬＬＣ
５６    ＦＣＳ
５７    ＳＦＤ
５８    ＯＰフィールド
６１    Ｖｅｒｓｉｏｎ（バージョン）
６２    ＩＨＬ（ヘッダ長）
６３    Ｔｙｐｅ  ｏｆ  Ｓｅｒｖｉｃｅ（サービスタイプ）
６４    Ｔｏｔａｌ  Ｌｅｎｇｔｈ（パケット長）
６５    Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（識別子）
６６    Ｆｌａｇｓ（フラグ）
６７    Ｆｒａｇｍｅｎｔ  Ｏｆｆｓｅｔ（フラグメントオフセット）
６８    Ｔｉｍｅ  ｔｏ  Ｌｉｖｅ（生存時間）
６９    Ｐｒｏｔｏｃｏｌ（プロトコル）
７０    Ｈｅａｄｅｒ  Ｃｈｅｃｋｓｕｍ（ヘッダチェックサム）
７１    Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ（送信元ＩＰアドレス）
７２    Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ（宛先ＩＰアドレス）
７３    Ｏｐｔｉｏｎ（オプション）
７４    Ｐａｄｄｉｎｇ（パディング）
８１、８２、８３、８４、８９、９０、９１、９２    ＩＰ電話機
８５、８６、８７    ルーター
８８    サーバー
【図１】
2005167458.tif 000005
【図２】
2005167458.tif 000006
【図３】
2005167458.tif 000007
【図４】
2005167458.tif 000008
【図５】
2005167458.tif 000009
【図６】
2005167458.tif 000010
【図７】
2005167458.tif 000011
【図８】
2005167458.tif 000012