JP2016021639A - 通信装置、通信方法及びプログラム - Google Patents

Abstract

【課題】分割されたＩＰパケットの転送を低遅延にて行う通信装置を提供する。
【解決手段】通信装置は、第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、自装置と第１端末及び第２端末との間のセッション情報を生成する生成部と、符号化されたマルチメディアデータが複数のパケットに分割されて送信され、複数のパケットのうちの先頭パケットを第１端末から受信し、且つ、第２端末にて符号化されたマルチメディアデータが復号される場合に、第１端末から受信した先頭パケットに対応するパケットであって、第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築するヘッダ構築部と、第１端末から受信した先頭パケットのペイロードに構築されたヘッダを付与したパケットを前２端末に向けて送信する送信部と、を備える。
【選択図】図１

Description

本発明は、通信装置、通信方法及びプログラムに関する。特に、メディアゲートウェイとして機能する通信装置に関する。

近年、ネットワークを経由して、マルチメディアデータ（音声データ、画像データ）を符号化したデータをパケットとして通信する、ＶｏＩＰ（Voice over IP）やＴＶｏＩＰ（Television over ＩＰ）と呼ばれるシステムを利用したサービスが普及してきている。このようなサービスでは、音声や画像をやり取りする端末同士の呼を接続する呼接続プロトコル（例えば、ＳＩＰ（Session Initiation Protocol））により、端末間のセッションが確立される。

端末間のセッションが確立されると、メディアゲートウェイ（ＭＧＷ；Media Gateway）を介して、端末間にて音声データ等が符号化されたパケットが送受信される。その際、一方の端末が利用する符号化方式と他方の端末が利用する符号化方式が異なる場合に、メディアゲートウェイにて符号化方式の変換（コーデック変換）が行われる。例えば、一方の端末がＡＭＲ（Adaptive Multi-Rate）方式を用いて、他方の端末がＧ．７１１方式を用いる場合に、メディアゲートウェイにてコーデック変換が行われる。

特許文献１において、基地局から送信されてきた音声データを、符号変換してから移動体交換局に出力するか、符号変換をせずに移動体交換局に出力するかを選択する手段を備える基地局制御装置を含むシステムが開示されている。

特許文献２において、パケットのバッファリングを実行しないことでパケットのフラグメントに係る遅延時間を短縮する通信装置が開示されている。

非特許文献１において、チェックサム値の更新方法が開示されている。

特開平１１−５５７１６号公報 特開２００７−１２９４５２号公報

A. Rijsinghani、"Computation of the Internet Checksum via Incremental Update"、［online］、１９９４年５月、［平成２６年６月１１日検索］、インターネット＜URL:http://tools.ietf.org/html/rfc1624＞

なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。

上述のように、それぞれの端末が利用可能なコーデックが異なる場合には、メディアゲートウェイにてコーデック変換が行われる必要がある。しかし、各端末に同一のコーデックが搭載されている場合には、メディアゲートウェイでのコーデック変換は不要である。そこで、メディアゲートウェイには、端末間で使用する伝送プロトコル（例えば、ＲＴＰ（Real-time Transport Protocol））に係るペイロードを操作しないコーデックスルーの設定がなされることがある。具体的には、端末からＳＩＰを用いてＳＩＰサーバ（ＣＳＣＦ（Call Session Control Function））にアクセスし、ＣＳＣＦ及びメディアゲートウェイコントローラ（ＭＧＣ；Media Gateway Controller）を介して、メディアゲートウェイにコーデックスルーが設定される。

メディアゲートウェイにコーデックスルーが設定されると、端末間（End to End）で同一のコーデックを使用した通信が行われる。コーデックスルーが設定されることで、メディアゲートウェイはパケットを中継する処理だけが必要となり、低遅延にてパケット転送が行える。メディアゲートウェイでのコーデックスルーには、エンドユーザに対してリアルタイムな情報提供が可能となる利点がある。

しかし、近年、ＴＶｏＩＰに代表されるようにビデオ通信の広帯域化が進んでおり、ＩＰ（Internet Protocol）パケットが分割されて送受信される通信に対する考慮が必要な状況にある。ＵＤＰ（User Datagram Protocol）チェックサム値の計算対象は、ＵＤＰ擬似ヘッダ、ＵＤＰヘッダ及びＵＤＰペイロードである。そのため、パケットが分割されて送信されるＩＰフラグメントパケットに関しては、ＵＤＰチェックサムの検証は分割されたＩＰパケットを全て受信した後に行う必要がある。しかし、このような対応では、メディアゲートウェイでのパケット送信処理が遅延し、エンドユーザに対してリアルタイムな情報提供が阻害される可能性がある。

本発明は、分割されたＩＰパケットの転送を低遅延にて行うことに寄与する通信装置、通信方法及びプログラムを提供することを目的とする。

本発明の第１の視点によれば、第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する生成部と、符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築するヘッダ構築部と、前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する送信部と、を備える通信装置が提供される。

本発明の第２の視点によれば、第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する工程と、符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築する工程と、前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する工程と、を含む通信方法が提供される。

本発明の第３の視点によれば、第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する処理と、符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築する処理と、前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する処理と、を通信装置を制御するコンピュータに実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。

本発明の各視点によれば、分割されたＩＰパケットの転送を低遅延にて行うことに寄与する通信装置、通信方法及びプログラムが提供される。

一実施形態の概要を説明するための図である。 第１の実施形態に係るネットワークシステムの概略構成の一例を示す図である。 メディアゲートウェイとＭＧＣ＆ＣＳＣＦの間のネットワーク構造の一例を示す図である。 メディアゲートウェイの内部構成の一例を示す図である。 ＲＴＰセッション情報の一例を示す図である。 ＩＰヘッダの構成を示す図である。 内部フォーマットＡの一例を示す図である。 受信側フラグメント情報の一例を示す図である。 送信側フラグメント情報の一例を示す図である。 内部フォーマットＢの一例を示す図である。 メディアゲートウェイが非フラグメントパケットを受信した場合の動作を説明するための図である。 メディアゲートウェイの動作の一例を示すフローチャートである。 メディアゲートウェイがフラグメントパケットを受信した場合の動作を説明するための図である。 メディアゲートウェイの動作の一例を示すフローチャートである。 メディアゲートウェイの動作の一例を示すフローチャートである。 コーデック終端時のＲＴＰプロトコルスタックを示す図である。 コーデックスルー時のＲＴＰプロトコルスタックを示す図である。

初めに、図１を用いて一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。

上述のように、分割されたＩＰパケットの転送を低遅延にて行う通信装置（メディアゲートウェイ）が望まれる。

そこで、一例として図１に示す通信装置１００を提供する。通信装置１００は、生成部１０１と、ヘッダ構築部１０２と、送信部１０３と、を備えている。生成部１０１は、第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、第１端末と自装置の間に形成されるセッションに関する第１セッション情報と第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する。ヘッダ構築部１０２は、符号化されたマルチメディアデータが複数のパケットに分割されて送信され、複数のパケットのうちの先頭パケットを第１端末から受信し、且つ、第２端末にて符号化されたマルチメディアデータが復号される場合に、第１端末から受信した先頭パケットに対応するパケットであって、第２端末に送信する先頭パケットのヘッダを、少なくともセッション情報に基づき構築する。送信部１０３は、第１端末から受信した先頭パケットのペイロードに構築されたヘッダを付与したパケットを第２端末に向けて送信する。

通信装置１００は、フラグメント化されたＩＰパケットを第１端末から受信し、当該分割されたＩＰパケットのコーデック変換が不要な場合（第２端末にてデータの復号が行われる場合）には、先頭パケットのペイロードに格納されたデータをコーデック変換することなく、第２端末に送信する。第２端末に送信する先頭パケットにはＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ等の各種ヘッダが必要となるが、通信装置１００は、各端末と自装置間に形成されるセッションの情報に基づいて、上記各種ヘッダを構築する。通信装置１００は、構築されたヘッダを、第１端末から受信した先頭パケットのペイロードに付与して、第２端末に送信する。

従って、通信装置１００は、分割されたパケットの全てを受信せずに、第１端末から送信された先頭パケットを第２端末に向けて送信できるので、低遅延にてパケットの転送を実現できる。

以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

図２は、第１の実施形態に係るネットワークシステムの概略構成の一例を示す図である。図２を参照すると、ネットワークシステムは、端末１０−１及び１０−２と、メディアゲートウェイ２０と、ＭＧＣ（Media Gateway Controller）＆ＣＳＣＦ３０と、を含んで構成される。ネットワークシステムに含まれる各装置は、ＩＰ網を介して接続される。なお、以降の説明において、端末１０−１と１０−２を区別する特段の理由が無い場合には、単に「端末１０」と表記する。

第１の実施形態では、２つの端末１０にＴＶｏＩＰに係るサービスを提供するネットワークシステムを例示して説明を行う。但し、ネットワークシステムにて提供するサービスを限定する趣旨ではない。また、図２に示す構成は例示であって、システム構成を限定する趣旨ではない。例えば、ＭＧＣ＆ＣＳＣＦ３０は同じ装置にて実現する形態を図２では図示しているが、ＭＧＣとＣＳＣＦが異なる装置にて実現されていてもよい。

図２において、端末１０−１は、呼制御プロトコルにＳＩＰを用いて、ＭＧＣ＆ＣＳＣＦ３０に対し端末１０−２とのセッション確立を要求する。

ＭＧＣ＆ＣＳＣＦ３０は、ＳＣＴＰ（Stream Control Transmission Protocol）を用いてメディアゲートウェイ２０に対する制御信号を伝送する。その際、ＭＧＣ＆ＣＳＣＦ３０は、Ｍｅｇａｃｏ（media gateway control）に係るプロトコルを用いてメディアゲートウェイ２０の動作を制御する（図３参照）。具体的には、ＭＧＣ＆ＣＳＣＦ３０は、端末１０−１と端末１０−２の間で送受信されるパケットを伝送するための制御情報を、メディアゲートウェイ２０に設定する。

端末１０−１及び１０−２は、確立されたセッション上にてＴＶｏＩＰに係るマルチメディアデータ（音声データ、画像データ等）を格納するＲＴＰパケットを送受信する。なお、本実施形態では、端末１０−１から端末１０−２に向けてパケットが送信される場合について説明する。

図４は、メディアゲートウェイ２０の内部構成の一例を示す図である。図４を参照すると、メディアゲートウェイ２０は、Ｍｅｇａｃｏ処理部２０１と、受信部２０２と、コーデックスルー処理部２０３と、コーデック変換部２０４と、送信部２０５と、記憶部２０６と、を含んで構成される。なお、メディアゲートウェイ２０を構成する各要素は、メディアゲートウェイ２０に搭載されたコンピュータに、そのハードウェアを用いて、後に詳述する処理を実行させるコンピュータプログラムにより実現することもできる。

Ｍｅｇａｃｏ処理部２０１は、ＭＧＣ＆ＣＳＣＦ３０から送信されてくる制御情報を処理する手段である。Ｍｅｇａｃｏ処理部２０１には、ＭＧＣ＆ＣＳＣＦ３０に対するインターフェイスとなるＭｅｇａｃｏＩ／Ｆ部３０１と、ＲＴＰセッション情報管理部３０２と、が含まれる。

ＲＴＰセッション情報管理部３０２は、ＭＧＣ＆ＣＳＣＦ３０から受信した制御情報に応じて（同期して）、ＲＴＰセッション情報を生成し、記憶部２０６に格納する。ＲＴＰセッション情報管理部３０２は、自装置（メディアゲートウェイ２０）を基準として受信側と送信側それぞれのＲＴＰセッション情報を生成する。なお、端末１０−１とメディアゲートウェイ２０の間に形成されるセッションであって、端末１０−１から受信するパケットが属するセッションを受信側セッションとすれば、メディアゲートウェイ２０から端末１０−２の間に形成されるセッションであってメディアゲートウェイ２０から送信されるパケットが属するセッションが送信側セッションとなる。

生成されるＲＴＰセッション情報には、少なくとも、Ｍｅｇａｃｏにより指定される送信元及び宛先ＩＰアドレス、送信元及び宛先ポート番号、ＲＴＰ情報（例えば、ペイロードタイプ、送信元ＩＤ（ＳＳＲＣ））、メディア情報（例えば、コーデック情報）が含まれる。

図５は、ＲＴＰセッション情報の一例を示す図である。図５に示す受信側セッション情報における「ＭＧＷアドレス」は、端末１０からＲＴＰパケットを受信する場合の宛先ＩＰアドレスが設定される。また、受信側セッション情報における「対向アドレス」は、ＲＴＰパケットを送信する端末１０の送信元ＩＰアドレスが設定される。

同様に、送信側セッション情報における「ＭＧＷアドレス」は、端末１０へＲＴＰパケットを送信する場合の送信元ＩＰアドレスが設定される。送信側セッション情報における「対向アドレス」は、ＲＴＰパケットを送信する端末１０の宛先ＩＰアドレスが設定される。

「ＭＧＷポート」及び「対向ポート」も同様であり、送信元ポート番号と宛先ポート番号が適宜設定される。

ＲＴＰセッション情報管理部３０２は、ＭＧＣ＆ＣＳＣＦ３０から送信される制御情報に応じて、図５に示すＲＴＰセッション情報を生成し、記憶部２０６に格納する。また、ＲＴＰセッション情報管理部３０２は、受信側セッション情報と送信側セッション情報を１組として、セッション番号を用いて管理可能に構成する。

受信部２０２は、端末１０から送信されてくるＲＴＰパケットを処理する手段である。受信部２０２は、受信パケットに付与されたＩＰアドレス、ポート番号、ＲＴＰヘッダ情報を参照し、当該受信パケットに対応するＲＴＰセッション情報を記憶部２０６に格納されたＲＴＰセッション情報のなかから検索する。

受信部２０２は、検索したＲＴＰセッション情報に基づき、受信パケット（ＲＴＰパケット）に内部的なヘッダを付与することで、受信パケットを内部フォーマットＡに変換する。内部フォーマットＡの詳細は後述する。

受信部２０２は、コーデック変換が不要と判断された受信パケットを、コーデックスルー処理部２０３に出力する。受信部２０２は、コーデック変換が必要と判断された受信パケットを、コーデック変換部２０４に出力する。

受信部２０２は、受信処理部３１１と、パケット種別決定部３１２と、フォーマット変換部３１３と、受信側フラグメント情報管理部３１４と、チェックサム検証部３１５と、を含んで構成される。

受信処理部３１１は、端末１０から送信されてくるパケット（ＲＴＰパケット）を受信するインターフェイスとなる。受信処理部３１１は、受信パケットをパケット種別決定部３１２に引き渡す。

パケット種別決定部３１２は、受信パケットのＩＰアドレス、ポート番号、ＲＴＰヘッダ情報に基づいて、当該受信パケットに対応するセッション情報を検索する。パケット種別決定部３１２は、検索結果と受信パケットのヘッダに応じて受信パケットの内部的な種別を決定する。具体的には、パケット種別決定部３１２は、受信パケットを以下の４種類の種別に振り分ける。

第１のパケット種別は、受信パケットがＩＰフラグメントされず送信され、且つ、ＲＴＰペイロードに格納されたマルチメディアデータ（以下単にデータと表記する）のコーデック変換が不要なパケットに与えられる。

第２のパケット種別は、受信パケットがＩＰフラグメントされた先頭のパケットであり、且つ、ＲＴＰペイロードに格納されたデータのコーデック変換が不要なパケットに与えられる。

第３のパケット種別は、受信パケットがＩＰフラグメントされた先頭のパケットに続く後続のパケットであり、且つ、ＲＴＰペイロードに格納されたデータのコーデック変換が不要なパケットに与えられる。

第４のパケット種別は、ＩＰフラグメントの有無に関わらず、ＲＴＰペイロードに格納されたデータのコーデック変換が必要なパケットに与えられる。

パケット種別決定部３１２は、受信パケットがＩＰフラグメントされているか否かに関し、受信パケットのＩＰヘッダを参照することで決定する（図６参照）。

パケット種別決定部３１２は、ＲＴＰペイロードに格納されたデータのコーデック変換の要否に関し、検索されたセッション情報のメディア情報フィールドを参照することで決定する。例えば、図５を参照すると、セッション番号０ｘ０００１に属するパケットは、受信側と送信側とで同じコーデック（ＣｏｄｅｃＡ）を用いて処理されることが判明する。

パケット種別決定部３１２は、受信パケットが属するセッション番号におけるメディア情報フィールドの値が受信側と送信側で一致していれば、当該受信パケットにはコーデック変換は不要と判断する。一方、図５に示すセッション番号０ｘ０００３のように、受信側と送信側とで異なるコーデック（ＣｏｄｅｃＡ、ＣｏｄｅｃＢ）が使用される場合には、パケット種別決定部３１２は、当該受信パケットにはコーデック変換が必要と判断する。

パケット種別決定部３１２は、受信パケットが第１〜第３のパケット種別に該当する場合には、当該受信パケットをフォーマット変換部３１３に引き渡す。

パケット種別決定部３１２は、受信パケットが第４のパケット種別に該当する場合には、受信パケットを内部フォーマットＡに変換する必要がないので、コーデック変換部２０４に出力する。

パケット種別決定部３１２は、受信パケットが第２又は第３のパケット種別（ＩＰフラグメント化されたパケット）に該当する場合には、当該受信パケットをフォーマット変換部３１３に加えて、受信側フラグメント情報管理部３１４に引き渡す。なお、パケット種別決定部３１２は、受信パケットをフォーマット変換部３１３や受信側フラグメント情報管理部３１４に引き渡す際には、先に検索した受信パケットに対応するセッション番号を付帯情報として併せて通知する。

フォーマット変換部３１３は、受信パケットのフォーマットを内部フォーマットＡに変換する手段である。フォーマット変換部３１３は、受信パケットをパケット種別ごとに異なる内部フォーマットＡに変換する。具体的には、フォーマット変換部３１３は、第１のパケット種別に係る受信パケットを内部フォーマットＡ１に、第２のパケット種別に係る受信パケットを内部フォーマットＡ２に、第３のパケット種別に係る受信パケットを内部フォーマットＡ３に、それぞれ変換する。

図７は、内部フォーマットＡの一例を示す図である。図７（ａ）が内部フォーマットＡ１、図７（ｂ）が内部フォーマットＡ２、図７（ｃ）が内部フォーマットＡ３にそれぞれ該当する。

図７（ａ）を参照すると、内部フォーマットＡ１は、受信パケット（ＲＴＰパケット）本来のＲＴＰヘッダとＲＴＰペイロードに加え、フォーマット（ＦＭＴ）フィールド、セッション番号フィールドを有するフォーマットである。フォーマットフィールドには、内部フォーマットＡに変換された受信パケットが内部フォーマットＡ１に相当することを識別する値が設定される。図７（ａ）では、フォーマットフィールドには「００１」が設定されている。また、セッション番号には、記憶部２０６に格納されたＲＴＰセッション情報から得られる値を設定する。

図７（ｂ）を参照すると、内部フォーマットＡ２は、ＲＴＰヘッダとＲＴＰペイロードに加え、フォーマットフィールド、セッション番号フィールド、送信元アドレスフィールド、フラグメントＩＤフィールド、フラグメントオフセットフィールド、Ｍフラグ、ＵＤＰチェックサム計算用フィールドを有するフォーマットである。フォーマットフィールドとセッション番号フィールドは、図７（ａ）に示す内部フォーマットＡ１の同種のフィールドであるため説明を省略する。

上記の内部フォーマットＡ２の各種フィールドのうち、フォーマットフィールド、セッション番号フィールド及びＵＤＰチェックサム計算用フィールド以外のフィールドには、対応するＲＴＰセッション情報又はＩＰヘッダから得られる値を格納する。

フォーマット変換部３１３は、ＵＤＰチェックサム計算用フィールドに設定する値を、先頭パケットのＵＤＰチェックサムと、受信側のＵＤＰ擬似ヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダから計算する。即ち、フォーマット変換部３１３は、端末１０−１から受信した先頭パケットに含まれ、符号化されたデータの正当性を検証するためのＵＤＰチェックサムと、受信側セッション情報から得られる値と、に基づいてＵＤＰチェックサム計算用フィールドに設定する値を計算する。具体的には、フォーマット変換部３１３は、先頭パケットに付与されたＵＤＰチェックサムの１の補数に対して、ＵＤＰ擬似ヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダそれぞれの値を２バイトごとに減算し、ＵＤＰチェックサム計算用フィールドに設定する４バイトの値を計算する。

図７（ｃ）を参照すると、内部フォーマットＡ３は、ＩＰペイロードに加え、フォーマットフィールド、セッション番号フィールド、送信元アドレスフィールド、フラグメントＩＤフィールド、フラグメントオフセットフィールド、Ｍフラグ、全パケット受信判定フラグを有するフォーマットである。フォーマットフィールドとセッション番号フィールドは、図７（ａ）に示す内部フォーマットＡ１の同種のフィールドであるため説明を省略する。

上記の内部フォーマットＡ３の各種フィールドのうち、フォーマットフィールド、セッション番号及び全パケット受信判定フラグ以外のフィールドには、対応するＲＴＰセッション情報又はＩＰヘッダから得られる値を格納する。フォーマット変換部３１３は、全パケット受信判定フラグに設定する値を、受信側フラグメント情報管理部３１４が生成する受信側フラグメント情報に基づいて決定する。全パケット受信判定フラグ及び受信側フラグメント情報の詳細は後述する。

受信側フラグメント情報管理部３１４は、受信側フラグメント情報を生成し、記憶部２０６に格納する。先頭パケットに続く後続パケットには、セッションを特定するために必要となるＵＤＰポート番号が付与されていない。そのため、後続パケットが属するセッションを特定するための情報として受信側フラグメント情報が生成される。

受信側フラグメント情報管理部３１４は、第２のパケット種別に係る受信パケット（ＩＰフラグメント化された先頭パケット）を入力するたびに、当該先頭パケットに対応する受信側フラグメント情報を生成する。また、受信側フラグメント情報管理部３１４は、第３のパケット種別に係る受信パケット（ＩＰフラグメント化されたパケットのうちの後続パケット）を入力するたびに、先頭パケットの入力に応じて生成された受信側フラグメント情報の一部を更新する。

図８は、受信側フラグメント情報の一例を示す図である。図８を参照すると、受信側フラグメント情報は、送信元アドレスフィールド、フラグメントＩＤフィールド、変換フラグ、セッション番号フィールド、ＵＤＰレングスフィールド、ＵＤＰチェックサムフィールド、検証用ＵＤＰレングスフィールド、検証用ＵＤＰチェックサムフィールドを有する。

受信側フラグメント情報管理部３１４は、受信側フラグメント情報の各種フィールドのうち、セッション番号フィールドに関しては、受信パケットに対応するＲＴＰセッション情報から得られる値を設定する。受信側フラグメント情報管理部３１４は、送信元アドレスフィールド、フラグメントＩＤフィールド、ＵＤＰレングスフィールド、ＵＤＰチェックサムフィールドに関しては、先頭パケットのＩＰヘッダ、ＵＤＰヘッダから得られる値を設定する。

受信側フラグメント情報管理部３１４は、ＵＤＰレングスフィールドに、先頭パケットに付与されたＵＤＰレングス値を設定する。

受信側フラグメント情報管理部３１４は、ＵＤＰチェックサムフィールドに、先頭パケットに付与されたＵＤＰチェックサム値を設定する。

受信側フラグメント情報管理部３１４は、変換フラグにはコーデック変換が不要（コーデックスルー）であることを明示する「０」を設定する。

受信側フラグメント情報管理部３１４は、検証用ＵＤＰレングスフィールドに、先頭パケットのＩＰペイロードサイズからフラグメントヘッダのバイト数を減算した値を設定する。検証用ＵＤＰレングスフィールドは、メディアゲートウェイ２０にて端末１０−１が送信する複数のパケットの受信が完了したか否かを検証するために設けられている。

受信側フラグメント情報管理部３１４は、検証用ＵＤＰチェックサムフィールドに、ＵＤＰ擬似ヘッダ、ＵＤＰヘッダ及び先頭パケットに含まれるＵＤＰペイロードの１の補数を２バイト単位で合計した値を設定する。検証用ＵＤＰチェックサムフィールドは、端末１０−１から送信されてくる先頭パケットに含まれるＵＤＰチェックサムの正当性を事後的に検証するために設けられる。

受信側フラグメント情報管理部３１４は、第３のパケット種別に係る受信パケット（後続パケット）を入力するたびに検証用ＵＤＰレングスフィールド及び検証用ＵＤＰチェックサムフィールドを更新する。

チェックサム検証部３１５は、端末１０−２に送信する先頭パケットに付与したＵＤＰチェックサム値と、検証用ＵＤＰチェックサムに所定の演算を施した結果得られる値と、を比較することで、受信した先頭パケットのＵＤＰチェックサムの正当性を検証する手段である。

コーデックスルー処理部２０３は、コーデック変換が不要と判断された受信パケットを処理する手段である。コーデックスルー処理部２０３は、内部フォーマットＡに変換された受信パケット（ＲＴＰパケット）に関し、パケット種別に応じて必要な処理を実行する。

コーデックスルー処理部２０３は、送信側フラグメント情報管理部３２１と、ヘッダ構築部３２２と、を含んで構成される。

送信側フラグメント情報管理部３２１は、送信側フラグメント情報を生成し、記憶部２０６に格納する。送信側フラグメント情報管理部３２１は、受信パケットがＩＰフラグメント化されたパケットである場合に、送信側フラグメント情報を生成し、記憶部２０６に格納する。

送信側フラグメント情報管理部３２１は、内部フォーマットＡ２に変換された受信パケットを入力した場合には、当該受信パケットのフラグメントＩＤとセッション番号を関連付けると共に送信用のフラグメントＩＤを付与する。

図９は、送信側フラグメント情報の一例を示す図である。図９を参照すると、例えば、０ｘａａａａａａａａのフラグメントＩＤ値と０ｘ０００１のセッション番号が関連付けられると共に、これらに対して送信側フラグメント情報に登録されていない（直近では使用されていない）０ｘｂｂｂｂｂｂｂｂの送信用フラグメントＩＤが付与されている。

ヘッダ構築部３２２は、内部フォーマットＡに変換された受信パケットに付与するＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを構築する手段である。その際、ヘッダ構築部３２２は、ＩＰヘッダ等を受信パケットに付与すると共に、内部ヘッダを付与することで受信パケットを内部フォーマットＢに変換する。

具体的には、ヘッダ構築部３２２は、内部フォーマットＡ１に変換されたパケットを内部フォーマットＢ１に、内部フォーマットＡ２に変換されたパケットを内部フォーマットＢ２に、内部フォーマットＡ３に変換されたパケットを内部フォーマットＢ３に、それぞれ変換する。

図１０は、内部フォーマットＢの一例を示す図である。図１０（ａ）が内部フォーマットＢ１、図１０（ｂ）が内部フォーマットＢ２、図１０（ｃ）が内部フォーマットＢ３にそれぞれ該当する。

図１０（ａ）を参照すると、内部フォーマットＢ１は、フォーマットフィールド、セッション番号フィールド、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ、ＲＴＰペイロードを有するフォーマットである。

図１０（ｂ）を参照すると、内部フォーマットＢ２は、フォーマットフィールド、セッション番号フィールド、ＩＰヘッダ、フラグメントヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ、ＲＴＰペイロードを有するフォーマットである。

図１０（ｃ）を参照すると、内部フォーマットＢ３は、フォーマットフィールド、セッション番号フィールド、ＩＰヘッダ、フラグメントヘッダ、ＩＰペイロードを有するフォーマットである。

内部フォーマットＢ１〜Ｂ３におけるフォーマットフィールドとセッション番号フィールドが内部ヘッダである。フォーマットフィールドとセッション番号フィールドは、対応する内部フォーマットＡの値と同じである。

ヘッダ構築部３２２は、受信パケットを内部フォーマットＡ１から内部フォーマットＢ１に変換する際、記憶部２０６に格納されたＲＴＰセッション情報から、当該受信パケットに対応するＲＴＰセッション情報を検索する。具体的には、ヘッダ構築部３２２は、内部フォーマットＡ１のセッション番号フィールドに一致するＲＴＰセッション情報を検索し、当該ＲＴＰセッション情報の送信側セッション情報に含まれる各フィールド値を取得する。

ヘッダ構築部３２２は、この送信側セッション情報に含まれる各フィールド値を用いて、端末１０−１から受信したパケットに対応するパケットであって、端末１０−２に送信するパケットのＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを構築する。

ヘッダ構築部３２２は、受信パケットを内部フォーマットＡ２から内部フォーマットＢ２に変換する際にも、ＲＴＰセッション情報を検索し、当該ＲＴＰセッション情報の送信側セッション情報に含まれる各フィールド値を取得する。ヘッダ構築部３２２は、この送信側セッション情報に含まれる各フィールド値を用いて、端末１０−１から受信した先頭パケットに対応するパケットであって、端末１０−２に送信する先頭パケットのＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを構築する。

なお、ＵＤＰヘッダを構築する際、ＵＤＰチェックサムが必要となる。しかし、先頭パケットを受信した段階では、先頭パケットに続く後続パケットの受信が行えていないので、正規のＵＤＰチェックサムを計算することはできない。

そこで、ヘッダ構築部３２２は、内部フォーマットＡ２のＵＤＰチェックサム計算用フィールドに設定された値と送信側セッション情報から得られる情報を用いて、送信パケットのＵＤＰヘッダに設定するＵＤＰチェックサムの予測値を生成する。具体的には、ヘッダ構築部３２２は、ＵＤＰヘッダに設定するＵＤＰチェックサムを、内部フォーマットＡ２のＵＤＰチェックサム計算用フィールドに設定されている値に送信側のＵＤＰ擬似ヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダの１の補数を加算することで計算する。ヘッダ構築部３２２により生成されたＵＤＰチェックサムの予測値は、端末１０-２にて、符号化されたデータの正当性を検証するためのチェックサムとして使用される。

ヘッダ構築部３２２は、受信パケットを内部フォーマットＡ３から内部フォーマットＢ３に変換する際にも、ＲＴＰセッション情報を検索し、当該ＲＴＰセッション情報の送信側セッション情報に含まれる各フィールド値を取得する。ヘッダ構築部３２２は、この送信側セッション情報に含まれる各フィールド値を用いて、ＩＰヘッダを構築する。また、ヘッダ構築部３２２は、記憶部２０６に格納された送信側フラグメント情報を参照し、フラグメントヘッダを構築する。

コーデック変換部２０４は、受信パケット（ＲＴＰパケット）に対してコーデック変換が必要な場合に、ＲＴＰパケットのペイロードから得られるデータに対してコーデック変換を行い、変換後のデータを送信部２０５に出力する。

送信部２０５は、内部ヘッダ除去部３３１にて不要な内部ヘッダ（フォーマットフィールド、セッション番号フィールド）を除去し、送信処理部３３２によりＩＰパケットを端末１０に向けて送信する。つまり、送信部２０５は、端末１０−１から受信したパケットのペイロードに、ヘッダ構築部３２２により構築されたヘッダを付与したパケットを端末１０−２に向けて送信する。

次に、第１のネットワークシステムの動作について説明する。

初めに、図１１及び図１２を参照しつつ、メディアゲートウェイ２０が非フラグメントパケットを受信した際の動作について説明する。

図１１において、端末１０−１とメディアゲートウェイ２０は、ＩＰｖ６アドレス／ポート番号（Ｘ：Ｘ：Ｘ：１０／２００００、Ｘ：Ｘ：Ｘ：２／１００００）を使用してＲＴＰパケットの送受信を行うものとする。端末１０−２とメディアゲートウェイ２０は、ＩＰｖ６アドレス／ポート番号（Ｘ：Ｘ：Ｘ：２０／３００００、Ｘ：Ｘ：Ｘ：２／１０００２）を使用してＲＴＰパケットの送受信を行うものとする。

端末１０−１からメディアゲートウェイ２０宛てのＲＴＰパケットのヘッダには、ＵＤＰチェックサムフィールドに０ｘａａａａが、ＩＰｖ６ペイロードレングスに１０００バイトが設定されているものとする。

メディアゲートウェイ２０のＭｅｇａｃｏ処理部２０１では、上記のＲＴＰパケットに対応するＲＴＰセッション情報をセッション番号０ｘ０００１として管理するものとする（図５参照）。

ステップＳ１０１において、パケット種別決定部３１２は、受信したＲＴＰパケットに付与されているＩＰｖ６アドレス、ポート番号、ＲＴＰペイロードタイプに一致するセッション情報を、記憶部２０６に記憶されているＲＴＰセッション情報から検索する。この場合、図５に示すセッション番号０ｘ０００１が検索される。

受信パケットは非フラグメントパケットであって、且つ、受信側と送信側で同一のコーデックを利用するものであるから、パケット種別決定部３１２は、受信パケットの種別を第１のパケット種別とし、フォーマット変換部３１３に引き渡す。

ステップＳ１０２において、フォーマット変換部３１３は、受信パケットを内部フォーマットＡ１に変換する（図７（ａ）参照）。フォーマット変換部３１３は、フォーマットフィールドに００１を、セッション番号フィールドに０ｘ０００１を設定し、受信パケットを内部フォーマットＡ１に変換する。なお、内部フォーマットＡ１のＲＴＰヘッダとＲＴＰペイロードは、受信パケットのＲＴＰヘッダとＲＴＰペイロードのとおりとする。内部フォーマットＡ１に変換された受信パケットはコーデックスルー処理部２０３に出力される。

ステップＳ１０３において、ヘッダ構築部３２２は、内部フォーマットＡ１に変換された受信パケットを内部フォーマットＢ１に変換する。ヘッダ構築部３２２は、記憶部２０６に格納されたＲＴＰセッション情報を検索し、セッション番号０ｘ０００１に該当する送信側セッション情報を特定する。この場合には、図５のセッション番号０ｘ０００１の送信側セッション情報が特定される。

ヘッダ構築部３２２は、セッション番号０ｘ０００１の送信側セッション情報として格納されている値を用いてＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを構築し、受信パケットを内部フォーマットＢ１に変換する。その際、ヘッダ構築部３２２は、ＲＴＰヘッダにおけるペイロードタイプ及びＳＳＲＣを、送信側セッション情報のペイロードタイプ及びＳＳＲＣに置き替える。

ヘッダ構築部３２２は、内部フォーマットＢ１に変換した受信パケットを送信部２０５に出力する。

ステップＳ１０４において、送信部２０５は、内部フォーマットＢ１の内部ヘッダ（フォーマットフィールド及びセッション番号）を除去し、ＲＴＰパケットとして端末１０−２に送信する。

次に、図１３〜図１５を参照しつつ、３つに分割されたフラグメントパケットを受信した場合のメディアゲートウェイ２０の動作について説明する。ＩＰｖ６アドレス及びポート番号の設定とセッション情報については、図１１に例示する場合と同様とする。

端末１０−１からメディアゲートウェイ２０宛てにＩＰフラグメント化されたＲＴＰパケットの先頭パケットのオフセットフィールドには０ｘ００００が、Ｍフラグには１が、フラグメントＩＤフィールドには０ｘａａａａａａａａが、ＵＤＰチェックサムフィールドには０ｘ１２３４が、ＩＰｖ６ペイロードレングスには１４４８バイトが、それぞれ設定されているとする。

後続パケットのオフセットフィールドには０ｘ００ｂ５が、Ｍフラグには１が、フラグメントＩＤフィールドには０ｘａａａａａａａａが、ＩＰｖ６ペイロードレングスには１４５６バイトが、それぞれ設定されているとする。

最終パケットのオフセットフィールドには０ｘ０１６ａが、Ｍフラグには０が、フラグメントＩＤフィールドには０ｘａａａａａａａａが、ＩＰｖ６ペイロードレングスには１００８バイトが、それぞれ設定されているとする。

メディアゲートウェイ２０のＭｅｇａｃｏ処理部２０１では、上記のＲＴＰパケットに対応するＲＴＰセッション情報をセッション番号０ｘ０００１として管理しているものとする（図５参照）。

＜先頭パケットの受信＞
初めに、先頭パケットを受信した場合のメディアゲートウェイ２０の動作を、図１４を参照しつつ説明する。

ステップＳ２０１において、パケット種別決定部３１２は、受信パケットに付与されているＩＰｖ６アドレス、ポート番号、ＲＴＰペイロードタイプに一致するセッション情報を、記憶部２０６に記憶されているＲＴＰセッション情報から検索する。この場合、図５のセッション番号０ｘ０００１が検索される。

受信パケットはフラグメントパケットの先頭パケットであって、且つ、受信側と送信側で同一のコーデックを利用するものであるから、パケット種別決定部３１２は、受信パケットの種別を第２のパケット種別とし、フォーマット変換部３１３及び受信側フラグメント情報管理部３１４に引き渡す。

ステップＳ２０２において、受信側フラグメント情報管理部３１４は、後続パケットの属するセッションを特定するための受信側フラグメント情報を生成する。図１３に示す例では、送信元アドレスフィールドにはＸ：Ｘ：Ｘ：１０が、フラグメントＩＤフィールドには０ｘａａａａａａａａが、変換フラグには０が、セッション番号フィールドには０ｘ０００１が、ＵＤＰレングスフィールドには３８８８が、ＵＤＰチェックサムフィールドには０ｘ１２３４が、検証用ＵＤＰレングスフィールドには１４４０が、検証用ＵＤＰチェックサムフィールドには０ｘＸＸＸＸが、それぞれ受信側フラグメント情報として生成される（図８参照）。

なお、ＵＤＰレングスフィールドに設定する値は先頭パケットに付与されたＵＤＰレングスが用いられる。ＵＤＰチェックサムフィールドに設定する値は先頭パケットに付与されたＵＤＰチェックサムが用いられる。

検証用ＵＤＰレングスフィールドに設定する値は、先頭パケットのＩＰｖ６ペイロードサイズからフラグメントヘッダのバイト数（８バイト）を減算することで算出される。検証用ＵＤＰレングスフィールドの値は、フラグメント化されたパケットの全てが到達したか否かの判断に使用される。

検証用ＵＤＰチェックサムフィールドに設定する値は、ＵＤＰ擬似ヘッダ、ＵＤＰヘッダ及び先頭パケットに含まれるＵＤＰペイロードの１の補数を２バイト単位で合計することで算出される。

ステップＳ２０３において、フォーマット変換部３１３は、受信パケットを内部フォーマットＡ２に変換する（図７（ｂ）参照）。具体的には、フォーマット変換部３１３は、フォーマットフィールドには０１０、セッション番号フィールドには０ｘ０００１、送信元アドレスフィールドにはＸ：Ｘ：Ｘ：１０、フラグメントＩＤフィールドには０ｘａａａａａａａａ、フラグメントオフセットフィールドには０ｘ００００、Ｍフラグには１を、それぞれ設定する。

また、フォーマット変換部３１３は、ＵＤＰチェックサム計算用フィールドに設定する値を、先頭パケットに付与されたＵＤＰチェックサムと、受信側のＵＤＰ擬似ヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダと、から算出する。

より具体的には、フォーマット変換部３１３は、先頭パケットに付与されたＵＤＰチェックサムの１の補数に対して、受信側のＵＤＰ擬似ヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダそれぞれの値を２バイトごとに減算し、４バイトのＵＤＰチェックサム計算用フィールドに設定する値を計算する。図１３に示す例では、ＵＤＰチェックサム計算用フィールドに設定する値として０ｘＡＡＡＡが計算されたものとする。

なお、フォーマット変換部３１３は、内部フォーマットＡ２のＲＴＰヘッダとＲＴＰペイロードは、受信したＲＴＰパケットのＲＴＰヘッダとＲＴＰペイロードのとおりとする。

内部フォーマットＡ２に変換された受信パケットは、コーデックスルー処理部２０３に出力される。

ステップＳ２０４において、送信側フラグメント情報管理部３２１は、内部フォーマットＡ２に変換された受信パケットを入力したので、送信側フラグメント情報を生成し、記憶部２０６に格納する（図９参照）。

ステップＳ２０５において、ヘッダ構築部３２２は、内部フォーマットＡ２に変換された受信パケットを内部フォーマットＢ２に変換する。図１３に示す例では、送信元アドレスにはＸ：Ｘ：Ｘ：２が、宛先アドレスにはＸ：Ｘ：Ｘ：２０が、フラグメントＩＤ値には０ｘｂｂｂｂｂｂｂｂが、送信元ポート番号には１０００２が、宛先ポート番号には３００００が、ＵＤＰチェックサム値には０ｘ５６７８が、ＲＴＰペイロードタイプ値＝１０２が、ＳＳＲＣ値にはｘｘｘ＠ｘｘｘが、それぞれ用いられ、ＩＰヘッダ、フラグメントヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダが構築される。上記以外のフィールド値については、内部フォーマットＡ２の各フィールド値がそのまま使用される。

ヘッダ構築部３２２は、内部フォーマットＡ２のＵＤＰチェックサム計算用フィールドに設定されている値（図１３の例では０ｘＡＡＡＡ）に送信側のＵＤＰ擬似ヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダ（８バイト）の１の補数を２バイト単位で加算することで、４バイトのＵＤＰチェックサム値（図１３の例では０ｘ５６７８）を得る。

ヘッダ構築部３２２は、送信側フラグメント情報を参照することで、フラグメントＩＤ値として０ｘｂｂｂｂｂｂｂｂをフラグメントヘッダに設定する。

ヘッダ構築部３２２は、内部フォーマットＢ２に変換した受信パケットを送信部２０５に出力する。

ステップＳ２０６において、送信部２０５は、内部フォーマットＢ２の内部ヘッダ（フォーマットフィールド及びセッション番号）を除去し、ＲＴＰパケットとして端末１０−２に送信する。なお、ＵＤＰヘッダのＵＤＰチェックサムフィールドには３つのＩＰパケットにフラグメント化されたパケットを受信して算出したチェックサムではなく、先頭パケットのＵＤＰチェックサムから予測されたＵＤＰチェックサムが設定されている。

＜後続パケットの受信＞
次に、後続パケットを受信した場合のメディアゲートウェイ２０の動作を、図１５を参照しつつ説明する。

ステップＳ３０１において、パケット種別決定部３１２は、受信パケットに付与されているＩＰｖ６アドレス、ポート番号、ＲＴＰペイロードタイプに一致するセッション情報を、記憶部２０６に記憶されているＲＴＰセッション情報から検索する。この場合、図５のセッション番号０ｘ０００１が検索される。

受信パケットはフラグメントパケットの後続パケットであって、且つ、受信側と送信側で同一のコーデックを利用するものであるから、パケット種別決定部３１２は、受信パケットの種別を第３のパケット種別とし、フォーマット変換部３１３及び受信側フラグメント情報管理部３１４に引き渡す。

ステップＳ３０２において、受信側フラグメント情報管理部３１４は受信側フラグメント情報を更新する。後続パケットにはＵＤＰポート番号が付与されていない。そこで、受信側フラグメント情報管理部３１４は、記憶部２０６を検索し、先頭パケットを受信した際に生成された受信側フラグメント情報の中に、受信パケットの送信元アドレスとフラグメントＩＤが一致する受信側フラグメント情報が存在するか否かを確認する。

受信側フラグメント情報を検索すると、受信した後続パケットの送信元アドレス（Ｘ：Ｘ：Ｘ：１０）とフラグメントＩＤ（０ｘａａａａａａａａ）に一致する受信側フラグメント情報が発見される（図８の１段目）。

受信側フラグメント情報管理部３１４は、受信側フラグメント情報を構成する各種フィールドのうち検証用ＵＤＰレングスフィールドと検証用ＵＤＰチェックサムフィールドを、受信パケット（後続パケット）から算出する値に更新する。具体的には、受信側フラグメント情報管理部３１４は、既に検証用ＵＤＰレングスフィールドに設定されている値に、後続パケットのＩＰｖ６ペイロードサイズからフラグメントヘッダのバイト数（８バイト）を減算した値を加算することで、検証用ＵＤＰレングスフィールドの値を更新する。

図１３の例では、既に設定されている１４４０に１４４８（１４５６−８）を加算することで、検証用ＵＤＰレングスフィールドの値が更新される。

また、受信側フラグメント情報管理部３１４は、既に検証用ＵＤＰチェックサムフィールドに設定されている値に、後続パケットのＩＰペイロード値の１の補数を２バイト単位で加算することで、検証用ＵＤＰチェックサムフィールドを更新する。図１３の例では、検証用ＵＤＰチェックサムフィールドの値は０ｘＹＹＹＹに更新される。

ステップＳ３０３において、フォーマット変換部３１３は、受信パケットを内部フォーマットＡ３に変換する（図７（ｃ）参照）。具体的には、フォーマット変換部３１３は、フォーマットフィールドには１００、セッション番号フィールドには０ｘ０００１、送信元アドレスフィールドにはＸ：Ｘ：Ｘ：１０、フラグメントＩＤフィールドには０ｘａａａａａａａａ、フラグメントオフセットフィールドには０ｘ００ｂ５、Ｍフラグには１、全パケット受信判定フラグには０（未受信パケットあり）を、それぞれ設定する。

フォーマット変換部３１３は、受信パケットを内部フォーマットＡ３に変換する際に、受信側セッション情報を参照し、ＵＤＰレングスフィールドの値と検証用ＵＤＰレングスの値が同じか否かに応じて、未受信パケットの有無を判定する。具体的には、ＵＤＰレングスフィールドの値と検証用ＵＤＰレングスフィールドの値が不一致であれば、フォーマット変換部３１３は未受信パケットありと判定し、全パケット受信判定フラグに０を設定する。

一方、ＵＤＰレングスフィールドの値と検証用ＵＤＰレングスフィールドの値が一致すれば、フォーマット変換部３１３は未受信パケットなしと判定し、全パケット受信判定フラグに１を設定する。

内部フォーマットＡ３に変換された受信パケットは、コーデックスルー処理部２０３に出力される。

ステップＳ２０４において、ヘッダ構築部３２２は、内部フォーマットＡ３に変換された受信パケットを内部フォーマットＢ３に変換する。その際、ヘッダ構築部３２２は、内部フォーマットＡ３に変換された受信パケットに付与されたセッション番号を用いて、ＲＴＰセッション情報を検索し、対応する送信側セッション情報を特定する。図１３に示す例では、図５のセッション番号０ｘ０００１に対応する送信側セッション情報が特定される。

続いて、ヘッダ構築部３２２は、特定された送信側セッション情報を用いて、内部フォーマットＡ３から内部フォーマットＢ３へ受信パケットを変換する。図１３に示す例では、セッションＩＤには０ｘ０００１が、送信元アドレスにはＸ：Ｘ：Ｘ：２が、宛先アドレスにはＸ：Ｘ：Ｘ：２０が、フラグメントＩＤ値には０ｘｂｂｂｂｂｂｂｂが、オフセット値には０ｘ００ｂ５が、Ｍフラグには１が、それぞれ用いられ、ＩＰヘッダ、フラグメントヘッダが構築される。

なお、フラグメントＩＤ値は、内部フォーマットＡ３に付与されているセッション番号とフラグメントＩＤをキーとして、送信側フラグメント情報を検索することで得られる（図９参照）。

ヘッダ構築部３２２は、内部フォーマットＢ３に変換した受信パケットを送信部２０５に出力する。

ステップＳ３０５において、送信部２０５は、内部フォーマットＢ３の内部ヘッダ（フォーマットフィールド及びセッション番号）を除去し、ＲＴＰパケットとして端末１０−２に送信する。

＜最終パケットの受信＞
次に、最終パケットを受信した場合のメディアゲートウェイ２０の動作について説明する。

最終パケットにもＵＤＰポート番号が付与されていない。従って、最終パケットを受信すると、メディアゲートウェイ２０は、後続パケットと同様に受信側フラグメント情報の更新処理と内部フォーマットＡ３への変換処理を行う。そのため、最終パケットを受信した際のメディアゲートウェイ２０の動作に関しては、後続パケットの受信時の動作と異なる点を中心に説明する。

受信側フラグメント情報管理部３１４は、最終パケットの受信を受けて受信側フラグメント情報の更新を行う。受信側フラグメント情報管理部３１４は、検証用ＵＤＰレングスフィールドに設定されている２８８８に１０００（１００８−８）を加算することで、検証用ＵＤＰレングスフィールドの値を更新する。

受信側フラグメント情報管理部３１４は、既に検証用ＵＤＰチェックサムフィールドに設定されている値に、後続パケットのＩＰペイロード値の１の補数を２バイト単位で加算することで、検証用チェックサムフィールドを更新する。図１３の例では、検証用ＵＤＰチェックサムフィールドの値は０ｘＥＤＣＢに更新される。

フォーマット変換部３１３は、受信パケット（最終パケット）のフォーマットを変換する。具体的には、フォーマット変換部３１３は、フォーマットフィールドには１００、セッション番号フィールドには０ｘ０００１、送信元アドレスフィールドにはＸ：Ｘ：Ｘ：１０、フラグメントＩＤフィールドには０ｘａａａａａａａａ、フラグメントオフセットフィールドには０ｘ０１６ａ、Ｍフラグには０、全パケット受信判定フラグには１（全パケット受信）を、それぞれ設定する。

フォーマット変換部３１３は、受信側フラグメント情報を確認すると、ＵＤＰレングスフィールドの値と検証用ＵＤＰレングスフィールドの値が一致するので、全パケット受信（未受信パケットなし）と判定し、全パケット受信判定フラグに１を設定する。

チェックサム検証部３１５は、受信側フラグメント情報のＵＤＰチェックサムフィールドの値と検証用ＵＤＰチェックサムフィールドの値の１の補数値と、を比較する。比較した結果、同値であれば、チェックサム検証部３１５は一連のＩＰフラグメント化されたＩＰパケットのチェックサム値は正常であると判定する。なお、異常の場合は、チェックサム検証部３１５は、ログに残す等の対処を行う。

図１３の例では、検証用ＵＤＰチェックサムフィールドの最終的な値は０ｘＥＤＣＢであり、ＵＤＰチェックサムフィールドの１の補数となっている。そのため、ＩＰフラグメント化されたＩＰパケットのチェックサムは正常であると判断される。チェックサムが正常である場合には、チェックサム検証部３１５はその旨を受信側フラグメント情報管理部３１４に通知する。受信側フラグメント情報管理部３１４は、該当する受信側フラグメント情報を記憶部２０６から削除する。

内部フォーマットＡ３に変換された受信パケットは、コーデックスルー処理部２０３に出力される。ヘッダ構築部３２２は、内部フォーマットＡ３から内部フォーマットＢ３へ最終パケットを変換する。図１３に示す例では、セッションＩＤには０ｘ０００１が、送信元アドレスにはＸ：Ｘ：Ｘ：２が、宛先アドレスにはＸ：Ｘ：Ｘ：２０が、フラグメントＩＤ値には０ｘｂｂｂｂｂｂｂｂが、オフセット値には０ｘ０１６ａが、Ｍフラグには０が、それぞれ用いられ、ＩＰヘッダ、フラグメントヘッダが構築される。その後、送信部２０５から内部ヘッダが除去された最終パケットが送信される。

以上、図１１〜図１５を参照しつつ、メディアゲートウェイ２０のコーデックスルーに係る動作を説明した。メディアゲートウェイ２０が、コーデック変換を要するパケットを受信した場合には、コーデック変換部２０４にてコーデック変換が行われ、送信パケットが生成される。生成された送信パケットは送信部２０５を介して端末１０に送信される。

なお、特許文献１が開示する技術では、フラグメント化されたパケットに対する考慮がなく、仮に特許文献１が開示する技術をフラグメント化されたパケットに対応するならば、デフラグメント処理を行う必要がある。一方、第１の実施形態に係るメディアゲートウェイ２０では、デフラグメント処理を行うことなく、フラグメント化されたパケットを端末１０に転送することができる。

また、特許文献２が開示する技術は、パケットのバッファリングを行わないことでフラグメント転送処理の低遅延化を実現するものである。その際、全てのフラグメントパケットを受信した後にＵＤＰチェックサムの計算を行い、先頭パケットに付与している。従って、特許文献２が開示する技術では、フラグメント化されたパケットを低遅延で端末１０に転送することができない。

第１の実施形態では、メディアゲートウェイを例に取り、フラグメント化されたパケットの転送について説明したが、メディアゲートウェイに限定されず、Ｍｅｇａｃｏ設定によりフラグメントパケットを転送するような装置であれば同様の動作が実現できる。

以上のように、第１の実施形態に係るメディアゲートウェイでは、ＲＴＰパケットのコーデック変換を行う場合（コーデック終端時；図１６参照）には、端末１０から受信したパケットのコーデックを変換し、他の端末１０に送信する。一方、コーデック変換が不要な場合（コーデックスルー時；図１７参照）には、端末１０から受信したパケットのペイロードには何らの処理を施すことなく、ＭＧＣ＆ＣＳＣＦ３０により設定される制御情報に基づき、他の端末１０に送信するヘッダを構築し、他の端末１０に送信する。

その結果、符号化されたマルチメディアデータが複数のパケットに分割されて転送される場合であっても、分割されたパケットの受信を待つことがないので、メディアゲートウェイ２０は他の端末にパケットを低遅延にて転送できる。また、メディアゲートウェイ２０は、先頭パケットを送信した後に、検証用ＵＤＰチェックサムを用いて受信したデータの正当性を検証しているので、提供するサービスの信頼性が低下することもない。さらに、メディアゲートウェイ２０は、パケットのバッファリングを要せず、パケットを中継するという簡易な処理（簡易な実装）で実現できるコーデックスルーを実現できる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

［付記１］
第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する生成部と、
符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築するヘッダ構築部と、
前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する送信部と、
を備える通信装置。
［付記２］
前記第１端末から受信した先頭パケットに含まれ、前記符号化されたマルチメディアデータの正当性を検証するための第１チェックサムと前記第１セッション情報に基づいて、計算用チェックサムを計算する計算部をさらに備え、
前記ヘッダ構築部は、前記計算用チェックサムと前記第２セッション情報に基づいて、前記第２端末に送信する先頭パケットに含まれ、前記符号化されたマルチメディアデータの正当性を検証するための第２チェックサムを生成する、付記１の通信装置。
［付記３］
前記計算部は、前記第１セッション情報から前記第１チェックサムの生成に使われる第１ヘッダ情報を取得し、前記第１チェックサムの値から前記第１ヘッダ情報に係る値を減算することで、前記計算用チェックサムを計算し、
前記ヘッダ構築部は、前記計算用チェックサムの値に、前記第２セッション情報から得られるヘッダ情報であって、前記第１ヘッダ情報と同種の第２ヘッダ情報に係る値を加算することで、前記第２チェックサムを生成する、付記２の通信装置。
［付記４］
前記第１端末から先頭パケットを受信することに応じて、前記第１端末から送信される先頭パケットに続く後続パケットが属するセッションを特定するためのフラグメント情報を生成するフラグメント情報生成部をさらに備える、付記３の通信装置。
［付記５］
前記フラグメント情報には、
前記第１端末から受信した先頭パケットの少なくともペイロードサイズから算出され、且つ、自装置にて前記第１端末が送信する前記複数のパケットの受信が完了したか否かを検証するための検証用レングスが少なくとも含まれる、付記４の通信装置。
［付記６］
前記フラグメント情報には、前記第１チェックサムの正当性を事後的に検証するための検証用チェックサムが含まれ、
前記フラグメント情報生成部は、
前記第１端末から先頭パケットを受信した場合に、前記第１ヘッダ情報に係る値と前記第１端末から受信した先頭パケットのペイロードから算出した値を前記検証用チェックサムとし、
前記第１端末から送信される先頭パケットに続く後続パケットを受信した場合に、前記後続パケットのペイロードの値と前記検証用チェックサムの値を加算することで、前記検証用チェックサムを更新する、付記４又は５の通信装置。
［付記７］
前記第２チェックサムと、前記検証用チェックサムに所定の演算を施した結果と、を比較することで、前記第１チェックサムの正当性を検証する検証部をさらに備える付記６の通信装置。
［付記８］
前記第１セッション情報には、前記第１端末におけるマルチメディアデータの符号化方式に関する情報が含まれ、
前記第２セッション情報には、前記第２端末における符号化されたマルチメディアデータの復号化方式に関する情報が含まれ、
前記第１セッション情報に含まれる符号化方式と前記第２セッション情報に含まれる復号化方式を比較することで、自装置での符号化方式を変換する必要があるか否かを判定する判定部をさらに備える付記１乃至７のいずれか一に記載の通信装置。
［付記９］
第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する工程と、
符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築する工程と、
前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する工程と、
を含む通信方法。
［付記１０］
第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する処理と、
符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築する処理と、
前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する処理と、
を通信装置を制御するコンピュータに実行させるプログラム。
なお、付記９の形態及び付記１０の形態は、付記１の形態と同様に、付記２の形態〜付記８の形態に展開することが可能である。

なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１０、１０−１、１０−２ 端末
２０ メディアゲートウェイ
３０ ＭＧＣ＆ＣＳＣＦ
１００ 通信装置
１０１ 生成部
１０２、３２２ ヘッダ構築部
１０３、２０５ 送信部
２０１ Ｍｅｇａｃｏ処理部
２０２ 受信部
２０３ コーデックスルー処理部
２０４ コーデック変換部
２０６ 記憶部
３０１ ＭｅｇａｃｏＩ／Ｆ部
３０２ ＲＴＰセッション情報管理部
３１１ 受信処理部
３１２ パケット種別決定部
３１３ フォーマット変換部
３１４ 受信側フラグメント情報管理部
３１５ チェックサム検証部
３２１ 送信側フラグメント情報管理部
３３１ 内部ヘッダ除去部
３３２ 送信処理部

Claims (10)

1. 第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する生成部と、
   符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築するヘッダ構築部と、
   前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する送信部と、
   を備える通信装置。
2. 前記第１端末から受信した先頭パケットに含まれ、前記符号化されたマルチメディアデータの正当性を検証するための第１チェックサムと前記第１セッション情報に基づいて、計算用チェックサムを計算する計算部をさらに備え、
   前記ヘッダ構築部は、前記計算用チェックサムと前記第２セッション情報に基づいて、前記第２端末に送信する先頭パケットに含まれ、前記符号化されたマルチメディアデータの正当性を検証するための第２チェックサムを生成する、請求項１の通信装置。
3. 前記計算部は、前記第１セッション情報から前記第１チェックサムの生成に使われる第１ヘッダ情報を取得し、前記第１チェックサムの値から前記第１ヘッダ情報に係る値を減算することで、前記計算用チェックサムを計算し、
   前記ヘッダ構築部は、前記計算用チェックサムの値に、前記第２セッション情報から得られるヘッダ情報であって、前記第１ヘッダ情報と同種の第２ヘッダ情報に係る値を加算することで、前記第２チェックサムを生成する、請求項２の通信装置。
4. 前記第１端末から先頭パケットを受信することに応じて、前記第１端末から送信される先頭パケットに続く後続パケットが属するセッションを特定するためのフラグメント情報を生成するフラグメント情報生成部をさらに備える、請求項３の通信装置。
5. 前記フラグメント情報には、
   前記第１端末から受信した先頭パケットの少なくともペイロードサイズから算出され、且つ、自装置にて前記第１端末が送信する前記複数のパケットの受信が完了したか否かを検証するための検証用レングスが少なくとも含まれる、請求項４の通信装置。
6. 前記フラグメント情報には、前記第１チェックサムの正当性を事後的に検証するための検証用チェックサムが含まれ、
   前記フラグメント情報生成部は、
   前記第１端末から先頭パケットを受信した場合に、前記第１ヘッダ情報に係る値と前記第１端末から受信した先頭パケットのペイロードから算出した値を前記検証用チェックサムとし、
   前記第１端末から送信される先頭パケットに続く後続パケットを受信した場合に、前記後続パケットのペイロードの値と前記検証用チェックサムの値を加算することで、前記検証用チェックサムを更新する、請求項４又は５の通信装置。
7. 前記第２チェックサムと、前記検証用チェックサムに所定の演算を施した結果と、を比較することで、前記第１チェックサムの正当性を検証する検証部をさらに備える請求項６の通信装置。
8. 前記第１セッション情報には、前記第１端末におけるマルチメディアデータの符号化方式に関する情報が含まれ、
   前記第２セッション情報には、前記第２端末における符号化されたマルチメディアデータの復号化方式に関する情報が含まれ、
   前記第１セッション情報に含まれる符号化方式と前記第２セッション情報に含まれる復号化方式を比較することで、自装置での符号化方式を変換する必要があるか否かを判定する判定部をさらに備える請求項１乃至７のいずれか一項に記載の通信装置。
9. 第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する工程と、
   符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築する工程と、
   前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する工程と、
   を含む通信方法。
10. 第１及び第２端末間で送受信されるパケットを伝送するための制御情報に基づき、前記第１端末と自装置の間に形成されるセッションに関する第１セッション情報と前記第２端末と自装置の間に形成されるセッションに関する第２セッション情報を１組とするセッション情報を生成する処理と、
    符号化されたマルチメディアデータが複数のパケットに分割されて送信され、前記複数のパケットのうちの先頭パケットを前記第１端末から受信し、且つ、前記第２端末にて前記符号化されたマルチメディアデータが復号される場合に、前記第１端末から受信した先頭パケットに対応するパケットであって、前記第２端末に送信する先頭パケットのヘッダを、少なくとも前記セッション情報に基づき構築する処理と、
    前記第１端末から受信した先頭パケットのペイロードに前記構築されたヘッダを付与したパケットを前記第２端末に向けて送信する処理と、
    を通信装置を制御するコンピュータに実行させるプログラム。

Images