(57)【要約】【課題】騒音やセキュリティ上の問題が発生することがなく、且つ汎用性が高い方式によって音声データとアプリケーションデータとを送受信するためのＲＴＰパケット送信装置及びＲＴＰパケット受信装置を提供する。【解決手段】ペイロードにアプリケーションデータを含むＲＴＰパケットについては、送信側のＩＰ電話機１０のタイムスタンプ値付与部１３は、当該ＲＴＰパケットのＲＴＰヘッダに対して前回生成されたＲＴＰパケットと同じタイムスタンプ値を付与する。前回のタイムスタンプ値と重複していても、シーケンス番号は正確であるために当該ＲＴＰパケットが途中のＩＰ電話ルータやｐｒｏｘｙサーバにより破棄されない。一方、アプリケーションデータが含まれたＲＴＰパケットは、受信側でアプリケーションデータを抽出された後に破棄されるため、騒音やセキュリティ上の問題が発生することがない。【選択図】図３
2009147825.tif 000002
【特許請求の範囲】
【請求項１】
音声データをペイロードに含む第１のＲＴＰパケットを生成する第１のＲＴＰパケット生成手段と、
アプリケーションデータをペイロードに含む第２のＲＴＰパケットを生成する第２のＲＴＰパケット生成手段と、
前記第１のＲＴＰパケット生成手段及び前記第２のＲＴＰパケット生成手段が其々生成した前記第１のＲＴＰパケット及び前記第２のＲＴＰパケットをネットワークに送信するＲＴＰパケット送信手段と、
を備え、
前記第１のＲＴＰパケット生成手段は、前記第１のＲＴＰパケットのＲＴＰヘッダに対して、順次加算されるタイムスタンプ値を付与し、
前記第２のＲＴＰパケット生成手段は、前記第２のＲＴＰパケットのＲＴＰヘッダに対して、前回送信した前記第１のＲＴＰパケットと同じタイムスタンプ値を付与する、
ＲＴＰパケット送信装置。
【請求項２】
音声データをペイロードに含む第１のＲＴＰパケットを生成する第１のＲＴＰパケット生成手段と、
アプリケーションデータをペイロードに含む第２のＲＴＰパケットを生成する第２のＲＴＰパケット生成手段と、
前記第１のＲＴＰパケット生成手段及び前記第２のＲＴＰパケット生成手段が其々生成した前記第１のＲＴＰパケット及び前記第２のＲＴＰパケットをネットワークに送信するＲＴＰパケット送信手段と、
を備え、
前記第１のＲＴＰパケット生成手段は、前記第１のＲＴＰパケットのＲＴＰヘッダに対して、順次加算されるタイムスタンプ値を付与し、
前記第２のＲＴＰパケット生成手段は、前記第２のＲＴＰパケットのＲＴＰヘッダに対して、前回送信した前記第１のＲＴＰパケットのタイムスタンプ値よりも小さいタイムスタンプ値を付与する、ＲＴＰパケット送信装置。
【請求項３】
音声データをペイロードに含む第１のＲＴＰパケットを生成する第１のＲＴＰパケット生成手段と、
アプリケーションデータをペイロードに含む第２のＲＴＰパケットを生成する第２のＲＴＰパケット生成手段と、
前記第１のＲＴＰパケット生成手段及び前記第２のＲＴＰパケット生成手段が其々生成した前記第１のＲＴＰパケット及び前記第２のＲＴＰパケットをネットワークに送信するＲＴＰパケット送信手段と、
を備え、
前記第１のＲＴＰパケット生成手段は、前記第１のＲＴＰパケットのＲＴＰヘッダに対して、２以上の値が順次加算されるタイムスタンプ値を付与し、
前記第２のＲＴＰパケット生成手段は、前記第２のＲＴＰパケットのＲＴＰヘッダに対して、前回送信した前記第１のＲＴＰパケットのタイムスタンプ値よりも１大きいタイムスタンプ値を付与する、ＲＴＰパケット送信装置。
【請求項４】
前記第１のＲＴＰパケット生成手段は、前記第１のＲＴＰパケットのＲＴＰヘッダに対して第１のマーカービット値を付与し、
前記第２のＲＴＰパケット生成手段は、前記第２のＲＴＰパケットのＲＴＰヘッダに対して、第２のマーカービット値を付与する、請求項１〜３のいずれか１項に記載のＲＴＰパケット送信装置。
【請求項５】
ＲＴＰパケットをネットワークから受信するＲＴＰパケット受信手段と、
音声データを処理する音声データ処理手段と、
アプリケーションデータを処理するアプリケーションデータ処理手段と、
前記ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰヘッダのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値より大きい値である場合に、当該ＲＴＰパケットのペイロードに含まれるデータを前記音声データ処理手段に渡し、前記ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰヘッダのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値と同一である場合に、該ＲＴＰパケットのペイロードに含まれるデータを前記アプリケーションデータ処理手段に渡すＲＴＰパケッ解析手段と
を備える、ＲＴＰパケット受信装置。
【請求項６】
ＲＴＰパケットをネットワークから受信するＲＴＰパケット受信手段と、
音声データを処理する音声データ処理手段と、
アプリケーションデータを処理するアプリケーションデータ処理手段と、
前記ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰヘッダのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値以上の値である場合に、当該ＲＴＰパケットのペイロードに含まれるデータを前記音声データ処理手段に渡し、前記ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰパケットのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値よりも小さい場合に、当該ＲＴＰパケットのペイロードに含まれるデータを前記アプリケーションデータ処理手段に渡すＲＴＰパケット解析手段と
を備える、ＲＴＰパケット受信装置。
【請求項７】
ＲＴＰパケットをネットワークから受信するＲＴＰパケット受信手段と、
音声データを処理する音声データ処理手段と、
アプリケーションデータを処理するアプリケーションデータ処理手段と、
前記ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰヘッダのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値よりも２以上大きい場合に、当該ＲＴＰパケットのペイロードに含まれるデータを前記音声データ処理手段に渡し、前記ＲＴＰパケット受信手段が受信したＲＴＰパケットのタイムスタンプ値よりも１大きい場合に、当該ＲＴＰパケットのペイロードに含まれるデータを前記アプリケーションデータ処理手段に渡すＲＴＰパケット解析手段と
を備える、ＲＴＰパケット受信装置。
【請求項８】
前記ＲＴＰパケット解析手段は、前記ＲＴＰパケット受信手段で受信したＲＴＰパケットのＲＴＰヘッダに含まれるマーカービット値が第１の値である場合に当該ＲＴＰパケットのペイロードに含まれるデータを前記音声データ処理手段に渡し、前記ＲＴＰパケット受信手段で受信したＲＴＰパケットのＲＴＰヘッダに含まれるマーカービット値が第２の値である場合に当該ＲＴＰパケットのペイロードに含まれるデータを前記アプリケーションデータ処理手段に渡す、請求項１〜３のいずれか１項に記載のＲＴＰパケット受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＲＴＰパケット送信装置及びＲＴＰパケット受信装置に関し、特に、音声データとアプリケーションデータとを送受信するためのＲＴＰパケット送信装置及びＲＴＰパケット受信装置に関するものである。
【背景技術】
【０００２】
映像や音声データをリアルタイムに転送するためのプロトコルとしては、ＩＥＴＦ  ＲＦＣ１８８９で規定されているプロトコルであるＲＴＰ（Real-time  Transport  Protocol）が用いられている。例えば、特許文献１には、ビデオオンデマンドや遠隔テレビ会議のようなリアルタイム再生が望まれるシステムにおいて、ＲＴＰにより映像や音声データを転送する技術が開示されている。
【０００３】
この特許文献１のシステムにおいては、ＲＴＰパケット生成部は、符号化データをペイロードとしたパケットを生成する処理を実行する。ＲＴＰパケット生成部は、ペイロードデータに対してＲＴＰヘッダを付加しパケット化する。ＲＴＰヘッダには、バージョン番号（ｖ）、パディング（Ｐ）、拡張ヘッダ（Ｘ）の有無、送信元数（Ｃｏｕｎｔｅｒ）、マーカ情報（ｍａｒｋｅｒｂｉｔ）、ペイロードタイプ（Ｐａｙｌｏａｄ  ｔｙｐｅ）、シーケンス番号、タイムスタンプ、同期ソース（送信元）識別子（ＳＳＲＣ）および貢献ソース（送信元）識別子（ＣＳＲＣ）の各フィールドが設けられている。データ受信側において、ＲＴＰヘッダに付与されたタイムスタンプによりＲＴＰパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または音声の再生制御が可能となる。
【特許文献１】特開２００３−１７９５８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、ＲＴＰを用いたＩＰ電話機において、音声データの転送中に、他の電話番号等のアプリケーションデータを転送する方式としては、ｉｎｂａｎｄ方式とｏｕｔｂａｎｄ方式があり、ｉｎｂａｎｄ方式ではＤＴＭＦ（Dual-Tone  Multi-Frequency）、ｏｕｔｂａｎｄ方式ではＳＩＰ（Session  Initiation  Protocol）のＩＮＦＯメソッドがある。しかし、ＤＴＭＦは可聴音である為に、騒音やセキュリティ上の問題が発生することや、得られる通信性能が遅いという問題がある。また、ＳＩＰのＩＮＦＯメソッドはＩＳＰ（Internet  Service  Provider）によってはサポートしておらず利用できない場合があるという問題があった。
【０００５】
本発明は、かかる事情に鑑みてなされたものであり、その目的は、騒音やセキュリティ上の問題が発生することがなく、且つ汎用性が高い方式によって音声データとアプリケーションデータとを送受信することのできるＲＴＰパケット送信装置及びＲＴＰパケット受信装置を提供することにある。
【課題を解決するための手段】
【０００６】
本発明は、音声データをペイロードに含む第１のＲＴＰパケットを生成する第１のＲＴＰパケット生成手段と、アプリケーションデータをペイロードに含む第２のＲＴＰパケットを生成する第２のＲＴＰパケット生成手段と、第１のＲＴＰパケット生成手段及び第２のＲＴＰパケット生成手段が其々生成した第１のＲＴＰパケット及び第２のＲＴＰパケットをネットワークに送信するＲＴＰパケット送信手段と、を備え、第１のＲＴＰパケット生成手段は、第１のＲＴＰパケットのＲＴＰヘッダに対して、順次加算されるタイムスタンプ値を付与し、第２のＲＴＰパケット生成手段は、第２のＲＴＰパケットのＲＴＰヘッダに対して、前回送信した第１のＲＴＰパケットと同じタイムスタンプ値を付与する、ＲＴＰパケット送信装置である。
【０００７】
また、本発明は、音声データをペイロードに含む第１のＲＴＰパケットを生成する第１のＲＴＰパケット生成手段と、アプリケーションデータをペイロードに含む第２のＲＴＰパケットを生成する第２のＲＴＰパケット生成手段と、第１のＲＴＰパケット生成手段及び第２のＲＴＰパケット生成手段が其々生成した第１のＲＴＰパケット及び第２のＲＴＰパケットをネットワークに送信するＲＴＰパケット送信手段と、を備え、第１のＲＴＰパケット生成手段は、第１のＲＴＰパケットのＲＴＰヘッダに対して、順次加算されるタイムスタンプ値を付与し、第２のＲＴＰパケット生成手段は、第２のＲＴＰパケットのＲＴＰヘッダに対して、前回送信した第１のＲＴＰパケットのタイムスタンプ値よりも小さいタイムスタンプ値を付与する、ＲＴＰパケット送信装置である。
【０００８】
さらに、本発明は、音声データをペイロードに含む第１のＲＴＰパケットを生成する第１のＲＴＰパケット生成手段と、アプリケーションデータをペイロードに含む第２のＲＴＰパケットを生成する第２のＲＴＰパケット生成手段と、第１のＲＴＰパケット生成手段及び第２のＲＴＰパケット生成手段が其々生成した第１のＲＴＰパケット及び第２のＲＴＰパケットをネットワークに送信するＲＴＰパケット送信手段と、を備え、第１のＲＴＰパケット生成手段は、第１のＲＴＰパケットのＲＴＰヘッダに対して、２以上の値が順次加算されるタイムスタンプ値を付与し、第２のＲＴＰパケット生成手段は、第２のＲＴＰパケットのＲＴＰヘッダに対して、前回送信した第１のＲＴＰパケットのタイムスタンプ値よりも１大きいタイムスタンプ値を付与する、ＲＴＰパケット送信装置である。
【０００９】
一方、本発明は、ＲＴＰパケットをネットワークから受信するＲＴＰパケット受信手段と、音声データを処理する音声データ処理手段と、アプリケーションデータを処理するアプリケーションデータ処理手段と、ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰヘッダのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値より大きい値である場合に、当該ＲＴＰパケットのペイロードに含まれるデータを音声データ処理手段に渡し、ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰヘッダのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値と同一である場合に、該ＲＴＰパケットのペイロードに含まれるデータをアプリケーションデータ処理手段に渡すＲＴＰパケッ解析手段とを備える、ＲＴＰパケット受信装置である。
【００１０】
また、本発明は、ＲＴＰパケットをネットワークから受信するＲＴＰパケット受信手段と、音声データを処理する音声データ処理手段と、アプリケーションデータを処理するアプリケーションデータ処理手段と、ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰヘッダのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値以上の値である場合に、当該ＲＴＰパケットのペイロードに含まれるデータを音声データ処理手段に渡し、ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰパケットのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値よりも小さい場合に、当該ＲＴＰパケットのペイロードに含まれるデータをアプリケーションデータ処理手段に渡すＲＴＰパケット解析手段とを備える、ＲＴＰパケット受信装置である。
【００１１】
さらに、本発明は、ＲＴＰパケットをネットワークから受信するＲＴＰパケット受信手段と、音声データを処理する音声データ処理手段と、アプリケーションデータを処理するアプリケーションデータ処理手段と、ＲＴＰパケット受信手段が受信したＲＴＰパケットのＲＴＰヘッダのタイムスタンプ値が前回受信したＲＴＰパケットのタイムスタンプ値よりも２以上大きい場合に、当該ＲＴＰパケットのペイロードに含まれるデータを音声データ処理手段に渡し、ＲＴＰパケット受信手段が受信したＲＴＰパケットのタイムスタンプ値よりも１大きい場合に、当該ＲＴＰパケットのペイロードに含まれるデータをアプリケーションデータ処理手段に渡すＲＴＰパケット解析手段とを備える、ＲＴＰパケット受信装置である。
【発明の効果】
【００１２】
本発明のＲＴＰパケット送信装置及びＲＴＰパケット受信装置によれば、騒音やセキュリティ上の問題が発生することがなく、且つ汎用性が高い方式によって音声データとアプリケーションデータとを送受信することが可能となる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施の形態に係るＲＴＰパケット送信装置及びＲＴＰパケット受信装置について添付図面を参照して説明する。
【００１４】
図１は、第１実施形態に係るＩＰ電話機における通信システムの構成例を示す図である。本実施形態は、本発明に係るＲＴＰパケット送信装置及びＲＴＰパケット受信装置をＩＰ電話機における通信システムとして構成したものである。
【００１５】
図１に示すように、本実施形態のＩＰ電話機１０，２０はパーソナルコンピュータとして実装され、ＩＰ電話網４０とは、それぞれＩＰ電話ルータ３０，６０を経由して接続される。ＩＰ電話網４０内には、メディアごとのＳＩＰ／ｐｒｏｘｙサーバ５０の他、不図示のリダイレクトサーバなどが存在する。
【００１６】
図２は、第１実施形態に係るＩＰ電話機におけるＥｎｄ‐ｔｏ‐Ｅｎｄ方式によるコネクションを示す図である。なお、以下の説明では、ＩＰ電話機の標準的な構成を前提とする。つまり、シグナリングプロトコルはＳＩＰ（Session  Initiation  Protocol）であり、音声データの転送はＲＴＰを用い、音声データの制御プロトコルにはＲＴＣＰ（RTP  Control  Protocolを用い、音声ＣＯＤＥＣにはＧ．７１１（Pulse  code  modulation（PCM）  of  voice  frequencies）を利用する。それぞれの規格は以下の通りである。
ＳＩＰ…ＲＦＣ３２６１など
ＲＴＰ…ＲＦＣ３５５０など
ＲＴＣＰ…ＲＦＣ３５５０など
Ｇ．７１１…ＩＴＵ−Ｔ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ
【００１７】
図２に示すように、本実施形態のＩＰ電話機１０，２０は、ＳＩＰコネクションａ、音声ＲＴＰコネクションｂ、音声ＲＴＣＰコネクションｃを利用する。ＳＩＰコネクションａはＩＰ電話機の通信システムに１つ以上存在するＳＩＰサーバに接続されるが、音声ＲＴＰコネクションｂと音声ＲＴＣＰコネクションｃとは、ＩＰ電話１０，２０同士がメディアごとのｐｒｏｘｙサーバを経由せずに直接通信するコネクション方式であるＥｎｄ‐ｔｏ‐Ｅｎｄ方式により通信を行う。
【００１８】
図３は、第１実施形態に係る送信側のＩＰ電話機１０におけるソフトウェア上の構成を示す機能ブロック図である。なお、以下の説明では、便宜上、送信側のＩＰ電話機をＩＰ電話機１０とし、受信側のＩＰ電話機をＩＰ電話機２０とする。
【００１９】
図３に示すように、送信側のＩＰ電話機１０は、送信バッファ１１、ＲＴＰパケット生成部（第１のＲＴＰパケット生成手段、第２のＲＴＰパケット生成手段）１２及びＲＴＰポート（ＲＴＰパケット送信手段）１５を備えている。送信バッファ１１は、ＩＰ電話機１０の音声通話の音声データ、及び他の電話番号等のアプリケーションデータのバッファリングを行うためのものである。
【００２０】
ＲＴＰパケット生成部１２は、音声データ及びアプリケーションデータのいずれかをペイロードに含むＲＴＰパケットを順次生成するためのものである。ＲＴＰパケット生成部１２は、タイムスタンプ値付与部１３及びマーカービット値付与部１４を有している。
【００２１】
タイムスタンプ値付与部１３は、ＲＴＰパケットそれぞれのＲＴＰヘッダに対して、タイムスタンプ値を付与するためのものである。マーカービット値付与部１４は、ＲＴＰパケットのＲＴＰヘッダに対して、当該ＲＴＰパケットのペイロードにアプリケーションデータが含まれているか否かを示すマーカービット値を付与するためのものである。
【００２２】
ＲＴＰポート１５は、ＲＴＰパケット生成部１２が生成したＲＴＰパケットを、ＩＰ電話網４０に順次送信するためのものである。
【００２３】
図４は、第１実施形態に係る受信側のＩＰ電話機２０におけるソフトウェア上の構成を示す機能ブロック図である。図４に示すように、受信側のＩＰ電話機２０は、ＲＴＰポート（ＲＴＰパケット受信手段）２１、ＲＴＰパケット訂正処理部、受信バッファ２３、及びＲＴＰパケット解析部（ＲＴＰパケット解析手段、音声データ処理手段、アプリケーションデータ処理手段）２４を備えている。
【００２４】
ＲＴＰポート２１は、ＩＰ電話機１０が送信したＲＴＰパケットをＩＰ電話網４０から順次受信するためのものである。ＲＴＰパケット訂正処理部２２は、ＲＴＰパケット欠落等の訂正処理を行うためのものである。受信バッファ２３は、ＲＴＰパケット訂正処理部２２により訂正処理が行われたＲＴＰパケットのバッファリングを行うためのものである。
【００２５】
ＲＴＰパケット解析部２４は、受信したＲＴＰパケットを順次解析し、当該ＲＴＰパケットから音声データ及びアプリケーションのいずれかを順次抽出し、当該音声データ及びアプリケーションを処理するためのものである。ＲＴＰパケット解析部２４は、タイムスタンプ値解析部２５及びマーカービット値解析部２６を有している。
【００２６】
タイムスタンプ値解析部２５は、ＲＴＰパケットそれぞれのＲＴＰヘッダに含まれるタイムスタンプ値を解析するためのものである。マーカービット値解析部２６は、ＲＴＰパケットそれぞれのＲＴＰヘッダに含まれるマーカービット値を解析するためのものである。
【００２７】
図５は、ＲＴＰヘッダの構造を示す図である。図５中で、“Ｖ＝２”は、バージョン番号を表し（２ｂｉｔ）、通常は２が入る。“Ｐ”は、パディングを表す（１ｂｉｔ）。１を入れた場合、パケットの最後にペイロードがパディングされ、本来の長さよりも長くなっていることを示す。“Ｘ”は、ＲＴＰヘッダの直後に拡張ヘッダをもつ場合に設定されるフラグである（１ｂｉｔ）。“ＣＣ”は、ＣＳＲＣ（Contributing  Source）カウントであり（４ｂｉｔ）、後続する後続するＣＳＲＣ識別子の数が入る。
【００２８】
“Ｍ”は、マーカービットであり（１ｂｉｔ）、ＲＴＰパケットのペイロードに音声データが含まれている場合には０が入り（第１の値）、ＲＴＰパケットのペイロードにアプリケーションデータが含まれている場合には１が入る（第２の値）。
【００２９】
“ＰＴ”は、ペイロードタイプであり（７ｂｉｔ）、後続するペイロードのタイプを表す。“sequence  number”はシーケンス番号（順序番号）であり（１６ｂｉｔ）、１ずつ増加するＲＴＰパケットの通し番号である。初期値はセキュリティ確保のためランダム値が用いられる。
【００３０】
“timestamp”は、タイムスタンプ値であり（３２ｂｉｔ）、パケットに含まれる最も古いデータが発生した時刻を表す。タイムスタンプ値はメディアごとに異なる一定の周期で増加する。タイムスタンプ値の周期を決めるクロックの周波数はペイロードタイプ（ＰＴ）ごとに定義され，音声コーデックの場合はサンプリング周波数になる。たとえば８ｋＨｚサンプリングのＧ．７１１音声コーデックを２０ｍｓｅｃのパケット長で伝送する場合、１ＲＴＰパケットには１６０サンプル分の音声データが含まれており、タイムスタンプ値もＲＴＰパケットごとに１６０ずつ増加する。このように送信側は確実に１６０ずつカウントアップする為に、受信側では次のタイムスタンプ値を予測することが可能であり、この特性を用いて、ＲＴＰパケットのペイロードにアプリケーションデータが含まれているかを推測することが可能となる。
【００３１】
“Synchrozination  Source（SSRC）  identifier”は、ＲＴＰセッション内の参加者の識別子である（３２ｂｉｔ）。ＳＳＲＣは、セッションごとに変わる一時的な識別子であり、ＲＴＣＰによってＣＮＡＭＥ（Canonical  Name）に対応付けられる。“Contributing  Source（CSRC）  identifier”は、メッセージ内の各ストリーム要素を準備した送信元の識別子である（３２ｂｉｔ）。それぞれの値は各ＳＳＲＣと同じである。
【００３２】
図６は、第１実施形態に係るＥｎｄ‐ｔｏ‐Ｅｎｄ方式による音声データが含まれたＲＴＰパケット（第１のＲＴＰパケット）の転送を示すシーケンス図である。この図６の例では、アプリケーションデータは転送されておらず、シーケンス番号は１ずつ加算されながら、送信側のＩＰ電話機１０のタイムスタンプ付与部１３が付与するタイムスタンプ値は、基準クロック周波数８０００の時に１６０カウントであるために２０ｍｓ間隔で転送されていることを示す。ＩＰ電話機１０，２０の標準的な音声ＣＯＤＥＣ方式であるＧ．７１１では、一般的にこのようなＲＴＰパケットの転送が行われる。受信側のＩＰ電話機２０のタイムスタンプ値解析部２５が、ＲＴＰパケットのタイムスタンプ値について、前回解析されたＲＴＰパケットのタイムスタンプ値に比べて１６０カウントだけ加算されたタイムスタンプ値が含まれていることを解析したときは、受信側のＩＰ電話機２０のＲＴＰパケット解析部２４は、当該ＲＴＰパケットから音声データを抽出する。
【００３３】
図７は、第１実施形態に係るＥｎｄ‐ｔｏ‐Ｅｎｄ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケット（第２のＲＴＰパケット）の転送を示すシーケンス図である。この例では、音声データとともにアプリケーションデータを転送している。図７中において、ＲＴＰパケット（ｓｅｑ＝α＋４、ｔｉｍｅ＝ｖ＋４８０）、ＲＴＰパケット（ｓｅｑ＝α＋６、ｔｉｍｅ＝ｖ＋６４０）、ＲＴＰパケット（ｓｅｑ＝α＋８、ｔｉｍｅ＝ｖ＋８００）が、アプリケーションデータが含まれたＲＴＰパケットである。
【００３４】
これらのペイロードにアプリケーションデータを含むＲＴＰパケットについては、送信側のＩＰ電話機１０のタイムスタンプ値付与部１３は、アプリケーションデータをペイロードに含むＲＴＰパケットのＲＴＰヘッダに対して、前回生成されたＲＴＰパケットと同じタイムスタンプ値を付与する。
【００３５】
一方、受信側のＩＰ電話機２０のタイムスタンプ値解析部２５が、ＲＴＰパケットのタイムスタンプ値について、前回解析されたＲＴＰパケットのタイムスタンプ値と同じタイムスタンプ値が含まれていることを解析したときは、受信側のＩＰ電話機２０のＲＴＰパケット解析部２４は、当該ＲＴＰパケットからアプリケーションデータを抽出して、当該パケットを破棄する。
【００３６】
すなわち、本実施形態では、アプリケーションデータをペイロードに含むＲＴＰパケットのタイムスタンプ値は前回のＲＴＰパケットのタイムスタンプ値と重複しているが、途中にいかなるＩＰ電話ルータやメディアｐｒｏｘｙサーバが存在しようとも、これらのＲＴＰパケットのシーケンス番号は正確であるために、タイムスタンプ値が重複していることが不正であるとの理由で当該ＲＴＰパケットが破棄されることはない。そして、音声データが含まれたＲＴＰパケットは、タイムスタンプ値が示す周期で送信側から受信側に転送されて音声通話のために用いられる。一方、アプリケーションデータが含まれたＲＴＰパケットは、受信側でアプリケーションデータを抽出された後に破棄されるため、騒音により音声データによる音声通話に支障をきたすことやセキュリティ上の問題が発生することがない。したがって、本実施形態では、騒音やセキュリティ上の問題が発生することがなく、且つ汎用性が高い方式によって音声データとアプリケーションデータとを送受信することが可能となる。
【００３７】
図８は、第１実施形態に係るＩＰ電話機におけるＬｉｎｋ‐ｂｙ‐Ｌｉｎｋ方式によるコネクションを示す図である。この例では、ＳＩＰコネクションａはＩＰ電話機の通信システムに１つ以上存在するＳＩＰサーバに接続され、音声ＲＴＰコネクションｂと音声ＲＴＣＰコネクションｃとは、ＩＰ電話１０，２０同士がメディアごとのｐｒｏｘｙサーバをｇａｔｅｗａｙとして動作させて通信を行うコネクション方式であるＬｉｎｋ‐ｂｙ‐Ｌｉｎｋ方式により通信を行う。
【００３８】
図９は、第１実施形態に係るＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による音声データが含まれたＲＴＰパケットの転送を示すシーケンス図である。この図９の例では、アプリケーションデータは転送されておらず、シーケンス番号は１ずつ加算されながら、送信側のＩＰ電話機１０のタイムスタンプ付与部１３が付与するタイムスタンプ値は、基準クロック周波数８０００の時に１６０カウントであるために２０ｍｓ間隔で転送されていることを示す。ＩＰ電話ルータ３０，６０、ｐｒｏｘｙサーバなどでＲＴＰによるプロトコル処理がなされるが、シーケンス番号の初期値からの差分やタイムスタンプ値の初期値からの差分は変わらない。ＩＰ電話機１０，２０の標準的な音声ＣＯＤＥＣ方式であるＧ．７１１では、一般的にこのようなＲＴＰパケットの転送が行われる。受信側のＩＰ電話機２０のタイムスタンプ値解析部２５が、ＲＴＰパケットのタイムスタンプ値について、前回解析されたＲＴＰパケットのタイムスタンプ値に比べて１６０カウントだけ加算されたタイムスタンプ値が含まれていることを解析したときは、受信側のＩＰ電話機２０のＲＴＰパケット解析部２４は、当該ＲＴＰパケットから音声データを抽出する。
【００３９】
図１０は、第１実施形態に係るＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。この例では、音声データとともにアプリケーションデータを転送している。図７中において、ＲＴＰパケット（ｓｅｑ＝α＋４、ｔｉｍｅ＝ｖ＋４８０）、ＲＴＰパケット（ｓｅｑ＝α＋６、ｔｉｍｅ＝ｖ＋６４０）、ＲＴＰパケット（ｓｅｑ＝α＋８、ｔｉｍｅ＝ｖ＋８００）が、アプリケーションデータが含まれたＲＴＰパケットである。
【００４０】
これらのペイロードにアプリケーションデータを含むＲＴＰパケットについては、送信側のＩＰ電話機１０のタイムスタンプ値付与部１３は、アプリケーションデータをペイロードに含むＲＴＰパケットのＲＴＰヘッダに対して、前回生成されたＲＴＰパケットと同じタイムスタンプ値を付与する。
【００４１】
一方、受信側のＩＰ電話機２０のタイムスタンプ値解析部２５が、ＲＴＰパケットのタイムスタンプ値について、前回解析されたＲＴＰパケットのタイムスタンプ値と同じタイムスタンプ値が含まれていることを解析したときは、受信側のＩＰ電話機２０のＲＴＰパケット解析部２４は、当該ＲＴＰパケットからアプリケーションデータを抽出して、当該パケットを破棄する。
【００４２】
以上のように本実施形態では、Ｌｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による通信においても、騒音やセキュリティ上の問題が発生することがなく、且つ汎用性が高い方式によって音声データとアプリケーションデータとを送受信することが可能となる。
【００４３】
なお、本実施形態においては、ＲＴＰペイロードにアプリケーションデータが含まれていることを示すためにＲＴＰヘッダのマーカービット値を利用することも可能である。すなわち、送信側のＩＰ電話機１０のマーカービット値付与部１４は、ＲＴＰパケットのＲＴＰヘッダに対して、当該ＲＴＰパケットのペイロードにアプリケーションデータが含まれているか否かを示すマーカービット値Ｍ＝１を付与する。一方、受信側のＩＰ電話機２０のマーカービット値解析部２６が、ＲＴＰパケットのマーカービット値が当該ＲＴＰパケットのペイロードにアプリケーションデータが含まれていることを示すＭ＝１であると解析したときは、受信側のＩＰ電話機２０のＲＴＰパケット解析部２４は、当該ＲＴＰパケットからアプリケーションデータを抽出する。
【００４４】
本実施形態では、上記のようにマーカービット値を用いることにより、より確実にＲＴＰパケットのペイロードにアプリケーションデータが含まれているか否かを判別することができる。
【００４５】
以下、本発明の第２実施形態について説明する。図１１は、第２実施形態に係るＥｎｄ‐ｔｏ‐Ｅｎｄ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。本実施形態では、図１１中において、ＲＴＰパケット（ｓｅｑ＝α＋４、ｔｉｍｅ＝ｖ＋４７９）、ＲＴＰパケット（ｓｅｑ＝α＋６、ｔｉｍｅ＝ｖ＋６３９）、ＲＴＰパケット（ｓｅｑ＝α＋８、ｔｉｍｅ＝ｖ＋７９９）が、アプリケーションデータが含まれたＲＴＰパケットである。
【００４６】
これらのペイロードにアプリケーションデータを含むＲＴＰパケットについては、送信側のＩＰ電話機１０のタイムスタンプ値付与部１３は、アプリケーションデータをペイロードに含むＲＴＰパケットのＲＴＰヘッダに対して、前回生成されたＲＴＰパケットよりも１だけ少ないタイムスタンプ値を付与する。
【００４７】
一方、受信側のＩＰ電話機２０のタイムスタンプ値解析部２５が、ＲＴＰパケットのタイムスタンプ値について、前回解析されたＲＴＰパケットのタイムスタンプ値よりも１だけ少ないタイムスタンプ値が含まれていることを解析したときは、受信側のＩＰ電話機２０のＲＴＰパケット解析部２４は、当該ＲＴＰパケットからアプリケーションデータを抽出して、当該パケットを破棄する。
【００４８】
図１２に示すＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による通信においても、上記と同様にしてアプリケーションデータをペイロードに含むＲＴＰパケットの送受信を行うことができる。
【００４９】
本実施形態においては、アプリケーションデータをペイロードに含むＲＴＰパケットのタイムスタンプ値は前回のＲＴＰパケットのタイムスタンプ値によりも１少ないが、途中にいかなるＩＰ電話ルータやメディアｐｒｏｘｙサーバが存在しようとも、これらのＲＴＰパケットのシーケンス番号は正確であるために、タイムスタンプ値が１少ないことが不正であるとの理由で当該ＲＴＰパケットが破棄されることはない。一方、アプリケーションデータが含まれたＲＴＰパケットは、タイムスタンプ値が前回のＲＴＰパケットのタイムスタンプ値によりも１少ないため、受信側でアプリケーションデータを抽出された後に確実に破棄されることになり、騒音により音声データによる音声通話に支障をきたすことやセキュリティ上の問題が発生することをより確実に防止することができる。
【００５０】
以下、本発明の第３実施形態について説明する。図１３は、第２実施形態に係るＥｎｄ‐ｔｏ‐Ｅｎｄ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。本実施形態では、図１３中において、ＲＴＰパケット（ｓｅｑ＝α＋４、ｔｉｍｅ＝ｖ＋４８１）、ＲＴＰパケット（ｓｅｑ＝α＋６、ｔｉｍｅ＝ｖ＋６４１）、ＲＴＰパケット（ｓｅｑ＝α＋８、ｔｉｍｅ＝ｖ＋８０１）が、アプリケーションデータが含まれたＲＴＰパケットである。
【００５１】
これらのペイロードにアプリケーションデータを含むＲＴＰパケットについては、送信側のＩＰ電話機１０のタイムスタンプ値付与部１３は、アプリケーションデータをペイロードに含むＲＴＰパケットのＲＴＰヘッダに対して、前回生成されたＲＴＰパケットよりも１だけ多いタイムスタンプ値を付与する。
【００５２】
一方、受信側のＩＰ電話機２０のタイムスタンプ値解析部２５が、ＲＴＰパケットのタイムスタンプ値について、前回解析されたＲＴＰパケットのタイムスタンプ値よりも１だけ多いタイムスタンプ値が含まれていることを解析したときは、受信側のＩＰ電話機２０のＲＴＰパケット解析部２４は、当該ＲＴＰパケットからアプリケーションデータを抽出して、当該パケットを破棄する。
【００５３】
図１４に示すＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による通信においても、上記と同様にしてアプリケーションデータをペイロードに含むＲＴＰパケットの送受信を行うことができる。本実施形態においては、アプリケーションデータをペイロードに含むＲＴＰパケットのタイムスタンプ値は前回のＲＴＰパケットのタイムスタンプ値によりも１多いが、途中にいかなるＩＰ電話ルータやメディアｐｒｏｘｙサーバが存在しようとも、これらのＲＴＰパケットのシーケンス番号は正確であるために、タイムスタンプ値が１多いことが不正であるとの理由で当該ＲＴＰパケットが破棄されることはない。一方、アプリケーションデータが含まれたＲＴＰパケットは、タイムスタンプ値が前回のＲＴＰパケットのタイムスタンプ値によりも１多いため、受信側におけるＲＴＰの実装方式がタイムスタンプ値が前回小さいＲＴＰパケットについては破棄しないといったものであっても、受信側でアプリケーションデータを抽出された後に破棄されることになり、騒音により音声データによる音声通話に支障をきたすことやセキュリティ上の問題が発生することがない。したがって、本実施形態では、当該通信システムにおけるＲＴＰの実装方式に応じて、騒音やセキュリティ上の問題が発生することがなく、且つ汎用性が高い方式によって音声データとアプリケーションデータとを送受信することが可能となる。
【００５４】
以上、本発明の実施の形態について説明したが、本発明は、上記実施形態に限定されるものではなく種々の変形が可能である。
【００５５】
本発明によれば、ＩＰ電話機１０，２０による通話中に、ＩＰ電話機１０，２０のソフトウェア同士でＲＴＰパケットのペイロードを用いてデータ交換が可能になる。これにより、ＩＰ電話機１０，２０のソフトウェアが保持する構成情報やＩＰ電話機１０，２０の装置が保持する構成情報などを交換可能になる。このような構成情報が交換できれば、ＩＰ電話機１０，２０のソフトウェア同士での新たな通信（ＩＰｖ６プロトコル通信など）が可能になる。
【００５６】
すなわち、本発明においては、例えば、図１５に示すようなＩＰ電話網を含むＮＧＮ（Next  Generation  Network）８０において、ＩＰ電話機１０，２０同士で接続した状態で、ＩＰ電話ルータ３０，６０にそれぞれ接続されている別のデバイスである液晶テレビジョン７０やデジタルカメラ９０のアドレスやプロパティを送信することで、それらのデバイスも含めた新たなプライベートネットの構築に移行することなどが考えられる。
【図面の簡単な説明】
【００５７】
【図１】第１実施形態に係るＩＰ電話機における通信システムの構成例を示す図である。
【図２】第１実施形態に係るＩＰ電話機におけるＥｎｄ‐ｔｏ‐Ｅｎｄ方式によるコネクションを示す図である。
【図３】第１実施形態に係る送信側のＩＰ電話機におけるソフトウェア上の構成を示す機能ブロック図である。
【図４】第１実施形態に係る受信側のＩＰ電話機におけるソフトウェア上の構成を示す機能ブロック図である。
【図５】ＲＴＰヘッダの構造を示す図である。
【図６】第１実施形態に係るＥｎｄ‐ｔｏ‐Ｅｎｄ方式による音声データが含まれたＲＴＰパケットの転送を示すシーケンス図である。
【図７】第１実施形態に係るＥｎｄ‐ｔｏ‐Ｅｎｄ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。
【図８】第１実施形態に係るＩＰ電話機におけるＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式によるコネクションを示す図である。
【図９】第１実施形態に係るＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による音声データが含まれたＲＴＰパケットの転送を示すシーケンス図である。
【図１０】第１実施形態に係るＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。
【図１１】第２実施形態に係るＥｎｄ‐ｔｏ‐Ｅｎｄ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。
【図１２】第２実施形態に係るＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。
【図１３】第３実施形態に係るＥｎｄ‐ｔｏ‐Ｅｎｄ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。
【図１４】第３実施形態に係るＬｉｎｋ‐ｔｏ‐Ｌｉｎｋ方式による音声データが含まれたＲＴＰパケット及びアプリケーションデータが含まれたＲＴＰパケットの転送を示すシーケンス図である。
【図１５】ＩＰ電話機による通信システムに別のデバイスを接続した例を示す図である。
【符号の説明】
【００５８】
１０…ＩＰ電話機、１１…送信バッファ、１２…ＲＴＰパケット生成部、１３…タイムスタンプ値付与部、１４…マーカービット値付与部、１５…ＲＴＰポート、２０…ＩＰ電話機、２１…ＲＴＰポート、２２…ＲＴＰパケット訂正処理部、２３…受信バッファ、２４…ＲＴＰパケット解析部、２５…タイムスタンプ値解析部、２６…マーカービット値解析部、３０…ＩＰ電話ルータ、４０…ＩＰ電話網、５０…ＳＩＰ／ｐｒｏｘｙサーバ、６０…ＩＰ電話網、７０…液晶テレビジョン、８０…ＮＧＮ、９０…デジタルカメラ。
【図１】
2009147825.tif 000003
【図２】
2009147825.tif 000004
【図３】
2009147825.tif 000005
【図４】
2009147825.tif 000006
【図５】
2009147825.tif 000007
【図６】
2009147825.tif 000008
【図７】
2009147825.tif 000009
【図８】
2009147825.tif 000010
【図９】
2009147825.tif 000011
【図１０】
2009147825.tif 000012
【図１１】
2009147825.tif 000013
【図１２】
2009147825.tif 000014
【図１３】
2009147825.tif 000015
【図１４】
2009147825.tif 000016
【図１５】
2009147825.tif 000017