JP2005167458A - 音声画像伝送方法 - Google Patents
音声画像伝送方法 Download PDFInfo
- Publication number
- JP2005167458A JP2005167458A JP2003401260A JP2003401260A JP2005167458A JP 2005167458 A JP2005167458 A JP 2005167458A JP 2003401260 A JP2003401260 A JP 2003401260A JP 2003401260 A JP2003401260 A JP 2003401260A JP 2005167458 A JP2005167458 A JP 2005167458A
- Authority
- JP
- Japan
- Prior art keywords
- data
- transmission method
- header
- audio
- voice
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
【課題】トラフィック効率を向上して音声や画像の劣化を防止することができる音声画像伝送方法を提供することを目的とする。
【解決手段】VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのRTPパケット13のRTPデータ17のサイズを可変にし、IPパケット11の順番を決定するデータとしてサイズをRTPヘッダ16のシーケンス番号に代えて用いることにより、RTPヘッダのシーケンス番号を削除することができ、データ量を削減し、結果として通話トラフィックの効率が改善されて音声や画像の品質劣化が防止される。
【選択図】図1
【解決手段】VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのRTPパケット13のRTPデータ17のサイズを可変にし、IPパケット11の順番を決定するデータとしてサイズをRTPヘッダ16のシーケンス番号に代えて用いることにより、RTPヘッダのシーケンス番号を削除することができ、データ量を削減し、結果として通話トラフィックの効率が改善されて音声や画像の品質劣化が防止される。
【選択図】図1
Description
本発明は、VoIP技術を利用して音声データや画像データをリアルタイムで伝送する音声画像伝送方法に関するものである。
VoIP技術を利用したIP電話の通話のしくみについて、また音声データを符号化しIPパケット化してデータ伝送する場合のIPパケットのフォーマットについて、図2、図8を用いて説明する。図2(a)、(b)、(c)はVoIPパケットのフォーマットを示すフォーマット図であり、図8はIP電話の基本的な通話のしくみを示す説明図である。
図2において、2はVoIPパケット(単に、「IPパケット」ともいう)フォーマット、3はRTPヘッダフォーマット、4はUDPパケットフォーマット、41は発信元ポート番号、42は宛先ポート番号、43はUDPデータ長、44はUDPチェックサム、45はデータである。また、図8において、101はマイク、102は符号器、103は無音圧縮器、104は音声圧縮器、105はパケット生成器、106はIPネットワーク、107は揺らぎ吸収バッファ、108はパケット分解器、109は音声無音伸長器、110は音声補間器、111は復号器、112はスピーカである。
IP電話の通話のプロセスは、まず、送話側の音声(アナログ)情報を符号器102でデジタルデータに変換する。このままではデータ量が大きいためデジタルデータの圧縮を無音圧縮器103および音声圧縮器104で行う。その圧縮方式では、ITU−T勧告により電話網を仮定した音声圧縮・伸張技術を規定している。現在最も一般的に使用されている音声圧縮・伸張方式は、G.7111,G.729(無音圧縮内蔵),G.723.1の3種類である。そして、次に、圧縮されたデジタルデータをIPネットワーク6に送り出す為にパケット生成器105でVoIPパケット(単に、「IPパケット」ともいう)化しなければならない。
図2に示すように、通常のIPパケットのフォーマットは、IPヘッダ、UDPヘッダ、RTPヘッダ、音声データで構成される。個々の機能を簡単に説明する。IPヘッダにはIPパケットの宛先IPアドレスや優先制御の情報等が含まれ、UDPヘッダは再送のないトランスポート機能を提供する。RTPヘッダにはリアルタイム転送の為の時間情報等が含まれ、最後の音声データは、音声圧縮により符号化された10バイトのいくつかの音声フレームが前記の各ヘッダとともにパケット化される。
このようにIPパケット化されたデータは、IPネットワーク6上で他のIPパケットと同様に宛先IPアドレスを見て転送される。転送された受話側では、IPネットワーク6上で発生したジッタ(遅延揺らぎ、送信側で一定間隔で送出したIPパケットが受信側では等間隔には到着しない現象)が発生し、音声の到着間隔が長くなると、通話中に音声がブツブツと途切れる状態が発生する。このジッタを吸収して円滑に再生されるように揺らぎ吸収バッファ107を設けている。この揺らぎ吸収バッファ107でIPネットワーク6内で発生したジッタを抑えると、あとは送話側の処理と逆の処理を行う。まず、IPネットワーク6上に送り出す為にパケット化したデータをパケット分解器108でパケット分解する。次に、圧縮された音声データを音声無音伸長器109で伸長する。そして、一部音声データで欠落した部分は音声補間器110で音声補間を行い、復号器111でデジタルデータからアナログデータに戻して、スピーカ112より送話側からの音声を聞くことができ、通話することができる。
しかし、VoIP技術を利用したIP電話におけるデータ転送においては、送信側の符号化時間やIPパケット化時間、受信側の揺らぎ吸収バッファ時間や復号化時間、IPネットワーク遅延時間等により相手の返事が遅くなると言った遅延の問題や、パケットの欠落による音声の途切れ、上記に記載したジッタ(遅延揺らぎ)により通話中の音声がブツブツと途切れると言った問題が発生する。これらの音声のリアルタイム性や音声品質(通話品質)は従来のアナログ電話では問題にならないもので、IP電話においてこれらの問題が発生する。その大きな要因としてはIPネットワークのトラフィックの増加が挙げられる(例えば特許文献1参照)。
特開2001−298479号公報
このように、従来の音声伝送方法では、IPネットワークのトラフィックが増加すると、送信側の符号化時間や、IPパケット化時間、受信側の揺らぎ吸収バッファ時間、復号化時間、IPネットワーク遅延時間等により相手の返事が遅くなると言った遅延の問題や、パケットの欠落による音声の途切れ、ジッタにより通話中の音声がブツブツと途切れると言った問題点を有していた。
この音声画像伝送方法では、トラフィック効率を向上して音声や画像の劣化を防止することが要求されている。
本発明は、この要求を満たすため、トラフィック効率を向上して音声や画像の劣化を防止することができる音声画像伝送方法を提供することを目的とする。
上記課題を解決するために本発明の音声画像伝送方法は、VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのRTPパケットのRTPデータのサイズを可変にし、IPパケットの順番を決定するデータとしてサイズをRTPヘッダのシーケンス番号に代えて用いる構成を備えている。
これにより、トラフィック効率を向上して音声や画像の劣化を防止することができる音声画像伝送方法が得られる。
本発明の音声画像伝送方法は、VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのRTPパケットのRTPデータのサイズを可変にし、IPパケットの順番を決定するデータとしてサイズをRTPヘッダのシーケンス番号に代えて用いることにより、RTPヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削除する事ができ、従って、通話トラフィックの効率が向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
さらに、IPパケットの順番を決定するデータとしてUDPパケットのUDPヘッダのポート番号データをRTPヘッダのシーケンス番号に代えて用いることにより、RTPヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
さらに、イーサネット(登録商標)のタイプフィールドにおいて普段使用しない値を予
約し、予約した値をRTPヘッダのシーケンス番号に代えて用いることにより、RTPヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
約し、予約した値をRTPヘッダのシーケンス番号に代えて用いることにより、RTPヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
さらに、UDPパケットのUDPヘッダにおいて予約されたポート番号の短縮化を行うことにより、全体のデータ量を削減する事ができるので、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
さらに、UDPパケットのUDPヘッダにおいて所定のデータを削除して独自のトランスポート層を作ることにより、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
さらに、IPパケット中のIPヘッダのパディングに音声データを入れてトラフィックの効率を向上させることにより、音声や画像の品質劣化を防止することができるという有利な効果が得られる。
さらに、RTCPやSNMP、トラフィック制御パラメータ等によって検知されたトラフィックの状況に応じて、UDPパケットのUDPヘッダやRTPパケットのRTPヘッダの圧縮の可否を自動的に変更することにより、通話トラフィックの効率を最適にすることができるので、音声や画像の品質劣化を防止することができるという有利な効果が得られる。
さらに、UDPパケットのUDPヘッダの宛先ポート番号から同じ送信方向の音声データをまとめて送り、送信先のルーターで個々の送り先に音声データを分けUDPヘッダの削除を行うことにより、同じ送信方向の音声データをまとめて送ることができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという有利な効果が得られる。
本発明は、通話トラフィックの効率を向上して音声や画像の品質劣化を防止するという目的を、RTPヘッダのシーケンス番号や所定のデータの削除、データの短縮化などにより実現した。
上記課題を解決するためになされた第1の発明は、VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、リアルタイム伝送のためのRTPパケットのRTPデータのサイズを可変にし、IPパケットの順番を決定するデータとしてサイズをRTPヘッダのシーケンス番号に代えて用いることとしたものであり、RTPヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削除する事ができ、従って、通話トラフィックの効率が向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
上記課題を解決するためになされた第2の発明は、IPパケットの順番を決定するデータとしてUDPパケットのUDPヘッダのポート番号データをRTPヘッダのシーケンス番号に代えて用いることとしたものであり、RTPヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
上記課題を解決するためになされた第3の発明は、イーサネット(登録商標)のタイプ
フィールドにおいて普段使用しない値を予約し、予約した値をRTPヘッダのシーケンス番号に代えて用いることとしたものであり、RTPヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
フィールドにおいて普段使用しない値を予約し、予約した値をRTPヘッダのシーケンス番号に代えて用いることとしたものであり、RTPヘッダのシーケンス番号のデータを削除することができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
上記課題を解決するためになされた第4の発明は、UDPパケットのUDPヘッダにおいて予約されたポート番号の短縮化を行うこととしたものであり、全体のデータ量を削減する事ができるので、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
上記課題を解決するためになされた第5の発明は、UDPパケットのUDPヘッダにおいて所定のデータを削除して独自のトランスポート層を作ることとしたものであり、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
上記課題を解決するためになされた第6の発明は、IPパケット中のIPヘッダのパディングに音声データを入れてトラフィックの効率を向上させることとしたものであり、音声や画像の品質劣化を防止することができるという作用・効果を有する。
上記課題を解決するためになされた第7の発明は、RTCPやSNMP、トラフィック制御パラメータ等によって検知されたトラフィックの状況に応じて、UDPパケットのUDPヘッダやRTPパケットのRTPヘッダの圧縮の可否を自動的に変更することとしたものであり、通話トラフィックの効率を最適にすることができるので、音声や画像の品質劣化を防止することができるという作用・効果を有する。
上記課題を解決するためになされた第8の発明は、UDPパケットのUDPヘッダの宛先ポート番号から同じ送信方向の音声データをまとめて送り、送信先のルーターで個々の送り先に音声データを分けUDPヘッダの削除を行うこととしたものであり、同じ送信方向の音声データをまとめて送ることができるので、全体のデータ量を削減する事ができ、通話トラフィックの効率を向上して音声や画像の品質劣化を防止することができるという作用・効果を有する。
(実施の形態1)
本発明の実施の形態1による音声画像伝送方法について、図1、図2を用いて説明する。図1は、本発明の実施の形態1による音声画像伝送方法を説明するためのVoIPパケットのフォーマットを示すフォーマット図である。
本発明の実施の形態1による音声画像伝送方法について、図1、図2を用いて説明する。図1は、本発明の実施の形態1による音声画像伝送方法を説明するためのVoIPパケットのフォーマットを示すフォーマット図である。
図1において、11はIPパケット、12はUDP(User Datagram Protocol)パケット、13はRTP(Realtime Transfer Protocol)パケット、14はIPヘッダ、15はUDPヘッダ、16はRTPヘッダ、17はRTPデータである。
図1に示すように、IPパケット11はIPヘッダ14とUDPパケット12とから成り、UDPパケット12はUDPヘッダ15とRTPパケット13とから成り、RTPパケット13はRTPヘッダ16とRTPデータ17とから成る。
図2(a)に音声4フレームの場合のVoIP(Voice over IP)パケットフォーマット2を示し、図2(b)にRTPヘッダフォーマット3を、図2(c)にUDPパケットフォーマット4を示す。
本実施の形態においては、RTPデータ17のデータサイズを1〜10の10段階に可変できる。例えば、データサイズ1のものをシーケンス番号1とし、データサイズ2のものをシーケンス番号2とする。以下、データサイズ3はシーケンス番号3、データサイズ4はシーケンス番号4とし、データサイズ10でシーケンス番号10まで行くと再びデータサイズ1となり、このデータサイズ11のものをシーケンス番号11とする。このように、データサイズを可変することで、パケットのシーケンス番号に代用することができる。つまり、可変データサイズをシーケンス番号に代えて用いる。これにより、RTPヘッダフォーマット3の中のシーケンス番号を削除する事が可能となる。
以上のように本実施の形態によれば、シーケンス番号を削除することができるので、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
(実施の形態2)
本発明の実施の形態2による音声画像伝送方法について、図2を用いて説明する。
本発明の実施の形態2による音声画像伝送方法について、図2を用いて説明する。
図2(c)にUDPパケットフォーマット4を示す。その構成は、発信元ポート番号41、宛先ポート番号42、UDPデータ長43、UDPチェックサム44、データ45となる。(表1)に予約されたポート番号(0〜77)を示す。ポート番号については以下に説明する。
ポート番号は16ビットの多重化識別子で、アプリケーション層からトランスポート層への接続口を意味しており、特定の上位プロトコル(アプリケーション・プロトコル)を識別する為に番号が予約されている。これは、ノード(接続ポイント)における処理の効率化の為に予約されており、0〜1023番まではウェルノウン(予約された)ポート番号となっている。例えば(表1)で25番のポート番号は、smtp(Simple Mail Transfer Protocol)を指定することになる。このように、ポ
ート番号はノード間でのデータ通信において、同時に複数のデータ流を並列的に転送する為の多重化識別子として使用される。ポート番号0〜1023は予約されているが、1024以上のポート番号は予約されていない為、各アプリケーションが自由に使用する事が可能である。また、1024〜49151の番号はレジスタード・ポート番号で、番号とアプリケーションの関係をIANA(アイアナ、Internet Assigned Numbers Authority:インターネットにおける番号(IPアドレスなど)およびパラメータなどの管理を行う組織)に登録する事が可能である。更に、49152〜65535の番号はダイナミック/プライベート・ポート番号で、ユーザーが自由に利用する事が可能である。
ート番号はノード間でのデータ通信において、同時に複数のデータ流を並列的に転送する為の多重化識別子として使用される。ポート番号0〜1023は予約されているが、1024以上のポート番号は予約されていない為、各アプリケーションが自由に使用する事が可能である。また、1024〜49151の番号はレジスタード・ポート番号で、番号とアプリケーションの関係をIANA(アイアナ、Internet Assigned Numbers Authority:インターネットにおける番号(IPアドレスなど)およびパラメータなどの管理を行う組織)に登録する事が可能である。更に、49152〜65535の番号はダイナミック/プライベート・ポート番号で、ユーザーが自由に利用する事が可能である。
本実施の形態では、ユーザーが自由に利用できるポート番号をRTPヘッダフォーマット3のシーケンス番号に代用させてRTPヘッダのシーケンス番号を削除する。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
(実施の形態3)
本発明の実施の形態3による音声画像伝送方法について、図2、図3を用いて説明する。図3(a)、(b)、(c)はイーサネット(登録商標)のフレーム構造を示すデータ図である。
本発明の実施の形態3による音声画像伝送方法について、図2、図3を用いて説明する。図3(a)、(b)、(c)はイーサネット(登録商標)のフレーム構造を示すデータ図である。
図3において、5a、5b、5cはイーサネット(登録商標)フレームで、イーサネット(登録商標)フレームにはDIXイーサネット(登録商標)とIEEE 802.3とがあり、更に後者の方は、オプションでVLAN(Virtual LAN)タグヘッダを利用す場合とに分けられる。前者のDIXイーサネット(登録商標)とは、DEC(現在のコンパック)、Intel、Xeroxの3社が商用に開発した「Ethernet(登録商標)」(10Mbps)のことを言う。後者の方は、IEEE(Institute of Electrical and Electronics Engineers、アメリカ電気電子技術者協会)が標準化した規格を言う。DIXイーサネット(登録商標)とIEEE 802.3のフレーム・フォーマットは、DIXイーサネット(登録商標)の「タイプ」フィールドがIEEE 802.3の「長さ/タイプ」フィールドとして使われている点と、図3(c)のIEEE 802.3にオプション・フィールドが追加された点以外は基本的には同じである。
フレームの構造は、LANに接続しているインターフェイスにフレーム送信の開始を認識させ、同期をとるタイミングを与える為の信号でDIXでは8オクテット(1オクテットは8ビットで、8オクテットは64ビット)、IEEE 802.3では7オクテット(56ビット)のプリアンブル51と、サイズが6オクテット(48ビット)のフィールドで、宛先となるステーションのインターフェイスのMAC(Media Access
Control:媒体アクセス制御)アドレスを設定する宛先アドレス52と、サイズが6オクテット(48ビット)のフィールドで、フレームを送信したインターフェイスのMACアドレスを設定する送信元アドレス53と、DIXイーサネット(登録商標)では「タイプ」、IEEE 802.3では「長さ/タイプ」と定義され、サイズが2オクテット(16ビット)のフィールドであるタイプ(長さ/タイプ)54とを有し、DIXイーサネット(登録商標)とIEEE 802.3のフレーム・フォーマットとで実質的に違うのはタイプ、長さ/タイプのフィールドだけである。このタイプフィールドは多重化/多重分離のために、次に続く「データ」フィールドに格納する上位層プロトコルを示すIDを設定する。データ55には、最小46オクテットから最大1500オクテットまでのデータを格納することができ、もしデータが46オクテット未満の場合にはパディングデータを付加し46オクテットにする。FCS(Frame Check Sequence)56はフレームのエラーを検出するための4オクテットのフィールドで、宛先アド
レス、送信元アドレス、長さ/タイプ、データの各フィールドから計算したCRC(Cyclic Redundancy Check)値を設定する。SFD(Start Frame Delimiter)57は1オクテットのフィールドで、SFDは「10101011」というパターンでありDIXと同じである。プリアンブル51を受信中に、その最後が「10101011」となっていることを検出すると、その次のビットから宛先アドレス部が始まると解釈される。そしてOP(オプション)フィールド58はサイズが4オクテット(32ビット)のフィールドで、VLAN用のタグヘッダを指定することができる。イーサネット(登録商標)フレームは以上で構成されます。
Control:媒体アクセス制御)アドレスを設定する宛先アドレス52と、サイズが6オクテット(48ビット)のフィールドで、フレームを送信したインターフェイスのMACアドレスを設定する送信元アドレス53と、DIXイーサネット(登録商標)では「タイプ」、IEEE 802.3では「長さ/タイプ」と定義され、サイズが2オクテット(16ビット)のフィールドであるタイプ(長さ/タイプ)54とを有し、DIXイーサネット(登録商標)とIEEE 802.3のフレーム・フォーマットとで実質的に違うのはタイプ、長さ/タイプのフィールドだけである。このタイプフィールドは多重化/多重分離のために、次に続く「データ」フィールドに格納する上位層プロトコルを示すIDを設定する。データ55には、最小46オクテットから最大1500オクテットまでのデータを格納することができ、もしデータが46オクテット未満の場合にはパディングデータを付加し46オクテットにする。FCS(Frame Check Sequence)56はフレームのエラーを検出するための4オクテットのフィールドで、宛先アド
レス、送信元アドレス、長さ/タイプ、データの各フィールドから計算したCRC(Cyclic Redundancy Check)値を設定する。SFD(Start Frame Delimiter)57は1オクテットのフィールドで、SFDは「10101011」というパターンでありDIXと同じである。プリアンブル51を受信中に、その最後が「10101011」となっていることを検出すると、その次のビットから宛先アドレス部が始まると解釈される。そしてOP(オプション)フィールド58はサイズが4オクテット(32ビット)のフィールドで、VLAN用のタグヘッダを指定することができる。イーサネット(登録商標)フレームは以上で構成されます。
本実施の形態では、タイプ54のデータをRTPヘッダフォーマット3のシーケンス番号に代用させる。「長さ/タイプ」フィールドはその値が1500以下の場合はデータのサイズと判断し、1536(0x0600)以上の場合はタイプと判断する。1501〜1535については未定義となっている。つまり、この1536以上のタイプの値で普段使用していないものや1501〜1535の未定義の値をRTPヘッダフォーマット3のシーケンス番号に代用させてRTPヘッダフォーマット3のシーケンス番号のデータを削除する。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
(実施の形態4)
本発明の実施の形態4による音声画像伝送方法について、図2、図4を用いて説明する。図4(a)、(b)はUDPヘッダを示すデータ図である。
本発明の実施の形態4による音声画像伝送方法について、図2、図4を用いて説明する。図4(a)、(b)はUDPヘッダを示すデータ図である。
図2(c)にUDPパケットフォーマット4を示す。その構成は、発信元ポート番号41、宛先ポート番号42、UDPデータ長43、UDPチェックサム44、データ45となる。(表1)に予約されたポート番号(0〜77)を示す。ポート番号については、実施の形態2で説明したので省略する。
本実施の形態では、UDPヘッダは上記のように発信元ポート番号41、宛先ポート番号42、UDPデータ長43、UDPチェックサム44で構成されるが、図4でポート番号は16ビットの多重化識別子で、予め特定の上位プロトコル(アプリケーション・プロトコル)を識別する為に番号が予約(0〜1023番まで)されている。つまり10ビットが予約されたビットとなり、残りの6ビットは例えば全てゼロを入れてポート番号の短縮化を行い、図4(b)に示すような短縮データを事前に登録しておく。このようにしてUDPヘッダのデータ量を削減する。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
(実施の形態5)
本発明の実施の形態5による音声画像伝送方法について、図2、図5を用いて説明する。図5はUDPヘッダを示すデータ図である。
本発明の実施の形態5による音声画像伝送方法について、図2、図5を用いて説明する。図5はUDPヘッダを示すデータ図である。
実施の形態4で説明したように、UDPパケットフォーマット4の構成は、発信元ポート番号41、宛先ポート番号42、UDPデータ長43、UDPチェックサム44、データ45となる。
本実施の形態では、UDPパケットフォーマット4として独自の音声用のパケットフォーマット、つまり独自のトランスポート層を作成する。これは、従来64ビットのUDPヘッダを例えば図5のように大した情報でないUDPデータ長43やUDPチェックサム44を削除して発信元及び宛先のポート番号のみで構成して独自のトランスポート層を作
ることである。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
ることである。これにより、全体のデータ量を削減することができ、通話トラフィックの効率が改善されて音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
(実施の形態6)
本発明の実施の形態6による音声画像伝送方法について、図6を用いて説明する。図6はIPヘッダのフォーマットを示すフォーマット図である。(表2)に、各フィールドの名称とビット数を示す。
本発明の実施の形態6による音声画像伝送方法について、図6を用いて説明する。図6はIPヘッダのフォーマットを示すフォーマット図である。(表2)に、各フィールドの名称とビット数を示す。
図6において、IPヘッダフォーマット6の構成は、IPのバージョンを表すVersion(バージョン)61と、インターネットのヘッダ長を表すIHL(ヘッダ長)62と、優先度や最低限の遅延で送ることや最大限のスループットで送ること等のIPパケットの品質を表すType of Service(サービスタイプ)63と、パケット長を表すTotal Length(パケット長)64と、分割されたパケットの組立てを補助する為に送信者によって割当てられる識別値を表すIdentification(識別子)65と、IPパケットを分割する際に使用するFlags(フラグ)66と、分割されたパケットが元のデータのどこに位置するかを表すFragment Offset(フラグメントオフセット)67と、パケットがインターネット上で生存できる事が許される最大時間を示すTime to Live(生存時間)68と、IPパケットで使用される上位のレベルのプロトコルを示すProtocol(プロトコル)69と、ヘッダだけのチェックサムを表すHeader Checksum(ヘッダチェックサム)70と、送信元のIPアドレスを示すSource Address(送信元IPアドレス)71と、宛先のIPアドレスを示すDestination Address(宛先IPアドレス)72と、セキュリティー等の昨日を付加する為のOption(オプション)73と、IPヘッダが32ビット境界で終了する事を保証する為に使用されるPadding(パディング)74とで構成される。
本実施の形態では、普段ほとんど使用されないOption(オプション)73と、通常0の値が入れてあるPadding(パディング)74とに音声データを入れることができるものとする。これにより、IPパケットの未使用領域を有効に活用することで、通話トラフィックの効率が向上して音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事を実現できる。
(実施の形態7)
本発明の実施の形態7による音声画像伝送方法について説明する。
本発明の実施の形態7による音声画像伝送方法について説明する。
RTPは、リアルタイム伝送のために映像や音声のデータを運搬するパケットに時間的な情報を付加して転送するプロトコルであるが、データを転送するだけのプロトコルで通信の状況を伝える仕組みは持っていない。ネットワークが十分空いている時はこれでも問題ないが、ネットワークが混雑している場合は、通信状況を検知し、データの転送速度や転送量を減少させて、ネットワークの混雑がさらに悪化することを避ける必要がある。また、受信側の受信速度が転送速度に追いつかない時にも同様に、検知した状況によって転送側でデータ転送速度の調節を行う必要が出てくる。このように、ネットワークの通信状態を検知する機能として、RTP Control Protocol(RTCP)や、Simple Network Management Protocol(SNMP)、PINGといったものがある。RTCPはRTPとペアで用いられ、RTPが持たない通信状態を伝える機能がある。SNMPは簡易ネットワーク管理プロトコルで、ネットワーク機器を管理する為の標準的なものである。PINGは、ネットワーク層の通信が可能かどうかを確認し、かつ送信元では相手側とのパケットの往復時間を計算する事ができる。
本実施の形態では、上記のRTCPやSNMP、PING等でネットワークの通信状態を常にモニターして検知する。その検知した通信状態でネットワークが混雑してきた場合、その状況に応じてUDPヘッダやRTPヘッダのヘッダ圧縮を自動的に制御できるようにしておく。このようにすることにより、データの転送量を減少させてネットワークの混雑がさらに悪化することが避けられ、通話トラフィックの効率が悪化せず音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
(実施の形態8)
本発明の実施の形態による音声画像伝送方法について、図7を用いて説明する。図7はIP電話のしくみを示す説明図である。
本発明の実施の形態による音声画像伝送方法について、図7を用いて説明する。図7はIP電話のしくみを示す説明図である。
図7において、8はIPネットワーク、81〜84、89〜92はIP電話機、85〜87はルーター、88はサーバーである。
IP電話機81〜84はルーター85に接続されている。また、IP電話機89〜92はルーター86に接続されている。
IP電話機81とIP電話機89が通話する場合、IP電話機81でIPパケット化されたデータがルーター85に送られる。ルーター85では通信相手を見つけたり、相手呼出中の情報伝達などの制御データのIPパケットをサーバー88とやり取りする。そこで通話相手がIP電話機89であることを確認できると、IP電話機89が接続されているルーター86にIPパケット(音声データ)が送られ、IP電話機89と通話することができる。
ここで、IP電話機81から84まで発信されたとする。ルーター85では、各IP電話機がどのIP電話機と通話したいのかをサーバー88と制御データのやり取りを行い確認する。今回すべてルーター86に接続されたIP電話機89から92だったとすると、ルーター85ではルーター86への同一方向の音声データと言うことで、一つのIPパケットにまとめてルーター86へIPパケットを送る。ルーター86では受けたデータを再び個々のIP電話機へのIPパケットに変換して通話ができるようにする。このようにIPネットワーク8上では、同一送信方向の音声データをまとめることでネットワークの混
雑が悪化することが避けられ、通話トラフィックの効率が悪化せず、音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
雑が悪化することが避けられ、通話トラフィックの効率が悪化せず、音声や画像の品質劣化が防止され、安定して音声や画像を伝送する事ができる。
本発明は、VoIP技術を利用して音声データや画像データをリアルタイムで伝送する音声画像伝送方法に関し、トラフィック効率を向上して音声や画像の劣化を防止することができる。
2 VoIPパケットフォーマット
3 RTPヘッダフォーマット
4 UDPパケットフォーマット
5 イーサネット(登録商標)フレーム
6 IPヘッダフォーマット
8 IPネットワーク
11 IPパケット
12 UDPパケット
13 RTPパケット
14 IPヘッダ
15 UDPヘッダ
16 RTPヘッダ
17 RTPデータ
41 発信元ポート番号
42 宛先ポート番号
43 UDPデータ長
44 UDPチェックサム
45 データ
51 プリアンブル
52 宛先アドレス
53 送信元アドレス
54 タイプ
55 データ/LLC
56 FCS
57 SFD
58 OPフィールド
61 Version(バージョン)
62 IHL(ヘッダ長)
63 Type of Service(サービスタイプ)
64 Total Length(パケット長)
65 Identification(識別子)
66 Flags(フラグ)
67 Fragment Offset(フラグメントオフセット)
68 Time to Live(生存時間)
69 Protocol(プロトコル)
70 Header Checksum(ヘッダチェックサム)
71 Source Address(送信元IPアドレス)
72 Destination Address(宛先IPアドレス)
73 Option(オプション)
74 Padding(パディング)
81、82、83、84、89、90、91、92 IP電話機
85、86、87 ルーター
88 サーバー
3 RTPヘッダフォーマット
4 UDPパケットフォーマット
5 イーサネット(登録商標)フレーム
6 IPヘッダフォーマット
8 IPネットワーク
11 IPパケット
12 UDPパケット
13 RTPパケット
14 IPヘッダ
15 UDPヘッダ
16 RTPヘッダ
17 RTPデータ
41 発信元ポート番号
42 宛先ポート番号
43 UDPデータ長
44 UDPチェックサム
45 データ
51 プリアンブル
52 宛先アドレス
53 送信元アドレス
54 タイプ
55 データ/LLC
56 FCS
57 SFD
58 OPフィールド
61 Version(バージョン)
62 IHL(ヘッダ長)
63 Type of Service(サービスタイプ)
64 Total Length(パケット長)
65 Identification(識別子)
66 Flags(フラグ)
67 Fragment Offset(フラグメントオフセット)
68 Time to Live(生存時間)
69 Protocol(プロトコル)
70 Header Checksum(ヘッダチェックサム)
71 Source Address(送信元IPアドレス)
72 Destination Address(宛先IPアドレス)
73 Option(オプション)
74 Padding(パディング)
81、82、83、84、89、90、91、92 IP電話機
85、86、87 ルーター
88 サーバー
Claims (8)
- VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
リアルタイム伝送のためのRTPパケットのRTPデータのサイズを可変にし、IPパケットの順番を決定するデータとして前記サイズをRTPヘッダのシーケンス番号に代えて用いることを特徴とする音声画像伝送方法。 - VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
IPパケットの順番を決定するデータとしてUDPパケットのUDPヘッダのポート番号データをRTPヘッダのシーケンス番号に代えて用いることを特徴とする音声画像伝送方法。 - VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
イーサネット(登録商標)のタイプフィールドにおいて普段使用しない値を予約し、前記予約した値をRTPヘッダのシーケンス番号に代えて用いることを特徴とする音声画像伝送方法。 - VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
UDPパケットのUDPヘッダにおいて予約されたポート番号の短縮化を行うことを特徴とする音声画像伝送方法。 - VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
UDPパケットのUDPヘッダにおいて所定のデータを削除して独自のトランスポート層を作ることを特徴とする音声画像伝送方法。 - VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
IPパケット中のIPヘッダのパディングに音声データを入れてトラフィックの効率を向上させることを特徴とする音声画像伝送方法。 - VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
RTCPやSNMP、トラフィック制御パラメータ等によって検知されたトラフィックの状況に応じて、UDPパケットのUDPヘッダやRTPパケットのRTPヘッダの圧縮の可否を自動的に変更することを特徴とする音声画像伝送方法。 - VoIP技術を利用して音声データ、画像データを伝送する音声画像伝送方法であって、
UDPパケットのUDPヘッダの宛先ポート番号から同じ送信方向の音声データをまとめて送り、送信先のルーターで個々の送り先に音声データを分けUDPヘッダの削除を行うことを特徴とする音声画像伝送方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003401260A JP2005167458A (ja) | 2003-12-01 | 2003-12-01 | 音声画像伝送方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003401260A JP2005167458A (ja) | 2003-12-01 | 2003-12-01 | 音声画像伝送方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005167458A true JP2005167458A (ja) | 2005-06-23 |
Family
ID=34725252
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003401260A Pending JP2005167458A (ja) | 2003-12-01 | 2003-12-01 | 音声画像伝送方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005167458A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012124689A (ja) * | 2010-12-08 | 2012-06-28 | Mitsubishi Electric Corp | 通信システム、送信側装置および受信側装置 |
JP2012185903A (ja) * | 2006-04-27 | 2012-09-27 | Mitsubishi Electric Corp | 記録媒体の再生装置 |
KR101487948B1 (ko) | 2013-10-31 | 2015-02-04 | 에스케이플래닛 주식회사 | 모바일 인터넷 전화 서비스 시스템, 모바일 인터넷 전화 서비스를 위한 디피아이 회피 방법 및 이를 위한 장치 |
JP2017060191A (ja) * | 2010-11-10 | 2017-03-23 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America | 通信端末及び通信方法 |
WO2018159204A1 (ja) * | 2017-02-28 | 2018-09-07 | 日本電気株式会社 | 通信装置、方法、プログラム、及び記録媒体 |
-
2003
- 2003-12-01 JP JP2003401260A patent/JP2005167458A/ja active Pending
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012185903A (ja) * | 2006-04-27 | 2012-09-27 | Mitsubishi Electric Corp | 記録媒体の再生装置 |
JP2017060191A (ja) * | 2010-11-10 | 2017-03-23 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America | 通信端末及び通信方法 |
JP2012124689A (ja) * | 2010-12-08 | 2012-06-28 | Mitsubishi Electric Corp | 通信システム、送信側装置および受信側装置 |
KR101487948B1 (ko) | 2013-10-31 | 2015-02-04 | 에스케이플래닛 주식회사 | 모바일 인터넷 전화 서비스 시스템, 모바일 인터넷 전화 서비스를 위한 디피아이 회피 방법 및 이를 위한 장치 |
WO2018159204A1 (ja) * | 2017-02-28 | 2018-09-07 | 日本電気株式会社 | 通信装置、方法、プログラム、及び記録媒体 |
US11381998B2 (en) | 2017-02-28 | 2022-07-05 | Nec Corporation | Communication apparatus, method, program, and recording medium |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3799326B2 (ja) | パケット送信方式及びパケット受信方式 | |
US6993021B1 (en) | Lightweight internet protocol encapsulation (LIPE) scheme for multimedia traffic transport | |
JP4893581B2 (ja) | 多重化通信システム、送信処理装置、受信処理装置、多重化通信方法、送信処理方法、および受信処理方法 | |
JP3690316B2 (ja) | データ伝送システム及びヘッダ情報付加装置とデータフォーマット変換装置並びにデータ伝送方法 | |
US8484331B2 (en) | Real time protocol packet tunneling | |
JP2009526426A (ja) | パケット伝送 | |
WO2007061786A1 (en) | Maximum transmission unit tuning mechanism for a real-time transport protocol stream | |
WO2008040203A1 (fr) | Procédé, système et routeur pour calcul de l'unité de transmission maximale de l'interface de sortie du routeur | |
US11165893B2 (en) | Techniques for packet data conversion | |
WO2000072532A9 (en) | System and method for network packet reduction | |
EP1576770A1 (en) | Tunnelling tdm traffic over mpls | |
JP3688525B2 (ja) | パケットフロー制御方法及びルータ装置 | |
US7995590B2 (en) | Method and system for communicating H.263 macroblock boundaries using H.221 BAS for RFC2190-compliant fragmentation | |
US20020085569A1 (en) | Communication control apparatus and method, and communication system using the communication control apparatus | |
JP4772053B2 (ja) | 送信装置および送信レート制御方法 | |
JP2005167458A (ja) | 音声画像伝送方法 | |
WO2006070542A1 (ja) | 通信装置、記憶媒体、集積回路および通信システム | |
JP2003264590A (ja) | パケット伝送システムとそのデータ送信装置及びデータ受信装置 | |
US20150016463A1 (en) | Media over ip performance enhancement | |
JP2005086496A (ja) | パケット伝送方法 | |
JP2007228081A (ja) | 無線通信装置、無線通信方法及び無線アクセス装置 | |
JP2005123985A (ja) | 通信装置及び通信方法 | |
JP2005252429A (ja) | Ipパケット化装置 | |
Sun | IP Networks | |
JP2008252263A (ja) | Ethernetフレームの送受信方式とその送受信変換装置 |