バッファ制御装置、バッファ制御プログラム及び通信装置
【課題】パケットの順序の入れ替わりやパケットロスなどが生じた場合に、できるだけ小さい遅延で、パケットの順序の入れ替えやパケットロス補償を実行して、音質の劣化を防止することができるようにする。
【解決手段】本発明は、バッファ手段と、バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段と、少なくとも、入力されたパケットのシーケンス番号に基づき、バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、データのバッファ手段への投入時又はバッファ手段からのデータ取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段とを備える。
【解決手段】本発明は、バッファ手段と、バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段と、少なくとも、入力されたパケットのシーケンス番号に基づき、バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、データのバッファ手段への投入時又はバッファ手段からのデータ取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バッファ制御装置、バッファ制御プログラム及び通信装置に関し、例えば、ネットワーク境界に設けられるセッションボーダーコントローラ（Ｓ／ＢＣ）に適用し得るものである。
【背景技術】
【０００２】
例えば、ＮＧＮ（次世代ネットワーク）等のＩＰ相互接続環境等において、各事業者網に収容された異なる端末間で、データ交換が行なわれるようになる。ＩＰ相互接続における通信は、単なるデータ以外に、音声や映像等のメディアデータも含まれることになる。この場合、各事業者網のコーデックが異なる場合、送信元の事業者網のコーデックから送信先の事業者網のコーデックに変換するコーデック変換技術が必要となる。
【０００３】
従来のコーデック変換方式として、特許文献１に記載の技術がある。特許文献１に記載のコーデック変換方式は、特許文献１の図１に示すように、パケット（例えばＲＴＰパケット）が受信されると、ＮＷ（ネットワーク）バッファにパケットを投入する。ＮＷバッファにパケットが蓄積されると、リソース振分部が、順次、ＮＷバッファからパケットを取り出し、リソース振分を行う。そして、各デコーダ／エンコーダでコーデック変換処理を実施して、パケット送出するというものである。
【０００４】
特許文献１には、多くのエンドのＶｏＩＰ電話端末が、パケットの順序入れ替えやパケットロス補償を実行することに鑑み、エンドツーエンドの端末にそれら処理を期待し、コーデック変換装置は、パケットの順序入れ替えやパケットロス補償を実行しないこととし、コーデック変換処理遅延を小さくすることが記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２６７６２８号公報
【特許文献２】特開２００５−６４８７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したように、特許文献１に記載の技術は、コーデック変換処理遅延を小さくするため、コーデック変換装置が、パケットの順序入れ替えやパケットロス補償を実行しないというものである。
【０００７】
しかしながら、エンドツーエンド端末でパケットの順序入れ替えやパケットロス補償を実行していたとしても、コーデック変換装置が、パケットの順序入れ替えやパケットロス補償を実行しないと、音質の劣化が生じることがあるという問題がある。
【０００８】
図２は、コーデック変換装置において、パケットの順序入れ替わりが発生した場合に、音質が劣化するときの例を説明する説明図である。図２では、コーデック変換装置９１が、ＡＭＲ（Adaptive MultiRate）からＩＴＵ−Ｔ Ｇ．７１１にコーデック変換を行うものである。
【０００９】
図２において、送信側の端末９２は、原音を例えば２０ｍｓで区切り、原音（１）、原音（２），原音（３），原音（４）を順次ＡＭＲでエンコードし、ＡＭＲ（１），ＡＭＲ（２），ＡＭＲ（３），ＡＭＲ（４）を順次送出する。ここで、送信側の端末９２からコーデック変換装置９１へのネットワークにて、パケットの順序入れ替わりが発生し、コーデック変換装置９１が、ＡＭＲ（２）より先にＡＭＲ（３）を受信したとする。
【００１０】
この場合、コーデック変換装置９１のＡＭＲデコーダ入力は、ＡＭＲ（１），ＡＭＲ（２），ＡＭＲ（３），ＡＭＲ（４）の順番ではなく、ＡＭＲ（１），ＡＭＲ（３），ＡＭＲ（２），ＡＭＲ（４）の順番でデコード処理を実行する。
【００１１】
ここで、デコーダ入力の順序が入れ替ったことにより、デコーダ出力のＬｉｎｅａｒ音声が原音と異なってしまい、音質が劣化するという問題が生ずる。これは、ＡＭＲなどの音声コーデックでは、過去の音声データより得られた情報も用いて、エンコード／デコード処理を実施しているからである。
【００１２】
受信側の端末９３において、パケットの順序入れ替わりを元に戻したとしても、劣化した音質を元通りにすることは出来ない。
【００１３】
また、例えば特許文献２に記載のジッタバッファを用いることで、パケットの順序入れ替わりやパケットロスが発生しても、音質の劣化を低減することができる。しかし、ジッタバッファへの投入から取り出しまでの時間分だけ、コーデック変換処理に遅延が増加してしまうという問題が生じ得る。
【００１４】
そのため、パケットの順序の入れ替わりやパケットロスなどが生じた場合に、できるだけ小さい遅延で、パケットの順序の入れ替えやパケットロス補償を実行して、音質の劣化を防止することができるバッファ制御装置、バッファ制御プログラム及び通信装置が求められている。
【課題を解決するための手段】
【００１５】
かかる課題を解決するために、第１の本発明は、（１）ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段と、（２）バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段と、（３）少なくとも、入力されたパケットのシーケンス番号に基づき、バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、データのバッファ手段への投入時又はバッファ手段からのデータ取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段とを備えることを特徴とするバッファ制御装置である。
【００１６】
第２の本発明は、コンピュータを、（１）ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段、（２）バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段、（３）少なくとも、入力されたパケットのシーケンス番号に基づき、バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、パケットのデータのバッファ手段への投入時又はバッファ手段からの取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段として機能させるものであることを特徴とするバッファ制御プログラムである。
【００１７】
第３の本発明は、それぞれ異なるネットワークに接続する通信装置において、各ネットワークにおけるコーデックの相違を吸収する第１の本発明のバッファ制御装置を有することを特徴とする通信装置である。
【発明の効果】
【００１８】
本発明によれば、パケットの順序の入れ替わりやパケットロスなどが生じた場合に、できるだけ小さい遅延で、パケットの順序の入れ替えやパケットロス補償を実行して、音質の劣化を防止することができる。
【図面の簡単な説明】
【００１９】
【図１】第１の実施形態のコーデック変換装置の詳細な内部構成を示すブロック図である。
【図２】コーデック変換装置において、パケットの順序入れ替わりが発生した場合に、音質が劣化するときの例を説明する説明図である。
【図３】第１の実施形態のセッションボーダーコントローラの概略内部構成を示すブロック図である。
【図４】第１の実施形態におけるソートバッファ制御部のバッファ制御処理に係る変数を説明する説明図である。
【図５】第１の実施形態におけるソートバッファ制御処理を説明する説明図である。
【図６】第１の実施形態におけるソートバッファ制御部による通常の投入動作を説明する説明図である。
【図７】第１の実施形態におけるソートバッファ制御部による通常の取出動作を説明する説明図である。
【図８】第１の実施形態において、順序が入れ替わって投入されたときのソートバッファ制御部による投入動作を説明する説明図である。
【図９】第１の実施形態において、順序が入れ替わって投入されたときのソートバッファ制御部による取出動作を説明する説明図である。
【図１０】第１の実施形態において、パケットロス発生時のソートバッファ制御部による投入動作を説明する説明図である。
【図１１】第１の実施形態において、パケットロス発生時のソートバッファ制御部による取出動作を説明する説明図である。
【図１２】第２の実施形態のソートバッファ制御部によるバッファ制御処理を説明する説明図である。
【発明を実施するための形態】
【００２０】
（Ａ）第１の実施形態
以下では、本発明のバッファ制御装置、バッファ制御プログラム及び通信装置の第１の実施形態を、図面を参照しながら説明する。
【００２１】
第１の実施形態では、事業者網の境界に設けられるセッションボーダーコントローラ（Ｓ／ＢＣ）のコーデック変換装置に、本発明を適用する場合の実施形態を例示する。
【００２２】
（Ａ−１）第１の実施形態の構成
図３は、第１の実施形態のセッションボーダーコントローラの概略内部構成（イメージ的な構成）を示すブロック図である。
【００２３】
第１の実施形態のセッションボーダーコントローラ１は、異なる事業者網間の境界設けられる通信装置である。図３に示すように、セッションボーダーコントローラ１は、複数のインタフェース部１１−１及び１１−２、制御部１２、スイッチ部１３を有する。
【００２４】
セッションボーダーコントローラ１は、例えば、文献「ＩＴＵ−Ｔ Ｙ．２０１２ Supplement」に規定されている、ＩＰｖ４／ｖ６変換（ＮＡＴ／ＮＡＰＴ）ピンホール制御、ＴＨＩＧ（トポロジーハイディング）等の機能を実現するものである。
【００２５】
また、セッションボーダーコントローラ１は、コーデック変換装置１４を内蔵又は外付けで備えるものである。
【００２６】
ＳＩＰサーバ２は、ＩＰ電話端末３−１及び３−２間の呼を制御する呼制御サーバである。ＳＩＰサーバ２は、ＳＩＰのセッションの確立処理の中で、通話しようとするＩＰ電話端末３−１、３−２が適用しているコーデック（ＩＰ電話端末３−１、３−２が収容されている事業者網の採用コーデック）を認識する。そして、両ＩＰ電話端末３−１及び３−２のコーデックが異なる場合、ＳＩＰサーバ２は、コーデック変換開始指示をセッションボーダーコントローラ２に発行するものである。
【００２７】
セッションボーダーコントローラ１において、制御部１２は、コーデック変換開始指示が与えられると、インタフェース部１１−１、１１−２、スイッチ部１３及びコーデック変換装置１４を制御し、コーデック変換を実行できるようにする。
【００２８】
制御部１２は、一方のＩＰ電話端末３−１からのパケットを、ＩＰ電話端末３−１を収容しているインタフェース部１１−１及びスイッチ部１３を介して、コーデック変換装置１４に与える。そして、制御部１２は、コーデック変換装置１４を制御して、他方のＩＰ電話端末３−２が適用しているコーデックに変換させ、コーデック変換装置１４から出力されたパケットを、スイッチ部１３、及び、ＩＰ電話端末３−２を収容しているインタフェース部１１−２を介して、他方のＩＰ電話端末３−２に送出できるように制御する。また、制御部１２は、逆方向についても、コーデック変換を実行できるように制御する。
【００２９】
コーデック変換が可能となったときに、制御部１２は、ＳＩＰサーバ２に、コーデック変換開始ＯＫを返信する。ＳＩＰサーバ２は、両電話端末３−１及び３−２に通話ＯＫを通知する。
【００３０】
これにより、通話が開始し、開始された通話に係るパケットは、コーデック変換装置１４を介して対向するＩＰ電話端末が適用しているコーデックのパケットに変換され、対向するＩＰ電話端末に送出される。
【００３１】
図１は、コーデック変換装置１４の詳細な内部構成を示すブロック図である。図１において、コーデック変換装置１４は、パケット受信部２１、チャネル振分け制御部２２、複数のソートバッファ２３−１〜２３−ｎ（ｎ：正の整数）、それぞれ対をなす複数のデコーダ２４−１〜２４−ｎ及びエンコーダ２５−１〜２５−ｎ、パケット送信部２６、ソートバッファ制御部２７を有する。
【００３２】
なお、コーデック変換装置１４は、例えば、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、入出力インタフェース部等を有して構成される装置である。コーデック変換装置１４の機能は、ＣＰＵが、ＲＯＭに格納されるコーデック変換プログラムやバッファ制御プログラム等の処理プログラムを実行することにより実現されるものである。なお、処理プログラムはネットワークを通じてインストールされるものであってもよく、その場合でも、図１に示す機能構成を有する。
【００３３】
コーデック変換装置１４は、ある事業者網の符号化方式のデータを、他の事業者網の符号化方式のデータに変換するものである。コーデック変換装置１４は、例えば、ＩＴＵ−Ｔ Ｇ．７１１、ＩＴＵ−Ｔ Ｇ．７２２、ＥＶＲＣ（Enhanced Variable Rate Codec）、ＡＭＲ等の間で符号化方式の変換を行うことができる。
【００３４】
例えば、コーデック変化装置１４は、「Ｇ．７１１→ＥＶＲＣ」、「Ｇ．７１１→ＡＭＲ」、「Ｇ．７１１→Ｇ．７２２」、「ＥＶＲＣ→Ｇ．７１１」、「ＡＭＲ→Ｇ．７１１」、「Ｇ．７２２→Ｇ．７１１」のコーデック変換を行うことができる。なお、上記以外のコーデック変換として、コーデック変化装置１４は、例えば「ＥＶＲＣ→ＡＭＲ」等のようなコーデック変換を行うようにしてもよい。
【００３５】
デコーダ２４−Ｎ（Ｎは１〜ｎ）は、入力された符号化音声データを復号して、原音に戻すものである。デコーダ２４−Ｎは、原音の音声データを、対応するエンコーダ２５−Ｎに与えるものである。
【００３６】
エンコーダ２５−Ｎは、原音の音声データを、自己について定まっている符号化方式（コーデック方式）に従って符号化し、符号化音声データをパケット送信部２６に与えるものである。
【００３７】
ここで、デコーダ２４−Ｎとエンコーダ２５−Ｎとは、対をなすものである。すなわち、デコーダ２４−Ｎ及びエンコーダ２５−Ｎの符号化方式の組み合わせによって、コーデック変換の内容が定まる。例えば、デコーダ２４−１がＧ．７１１対応であり、エンコーダ２５−１がＥＶＲＣ対応であれば、この対は、「Ｇ．７１１→ＥＶＲＣ」へのコーデック変換に供するものである。
【００３８】
例えば、デコーダ２４−Ｎとエンコーダ２５−Ｎとの対は、ＤＳＰ（ディジタルシグナルプロセッサ）によって実現される。１個のＤＳＰには、複数のチャネル（例えば２００チャネル程度）用のデコーダ及びエンコーダの対が搭載されている。コーデック変換装置１４は、このようなＤＳＰを複数個(例えば１５０個)設けられている。
【００３９】
パケット受信部２１は、入力されたパケットを受信し、その受信されたパケットをチャネル振分け制御部２２に与えるものである。
【００４０】
チャネル振分け制御部２２は、パケット受信部２１からのパケットのチャネルを識別し、チャネル別のソートバッファ２３−１〜２３−ｎにパケットを与えるものである。
【００４１】
チャネル振分け制御部２２によるチャネル振分け方法は、例えば、特許文献１に記載の技術を用いて振り分けることができる。例えば、チャネル振分け制御部２２は、デコーダ及びエンコーダの１対１の対を示す内部セッション番号を管理する内部セッション管理テーブルと、デコーダ及びエンコーダのコーデック変換種類と各コーデック変換を実行させるＤＳＰとを対応付けたＤＳＰ管理テーブル等を有する。チャネル振分け制御部２２は、ＩＰパケットのＲＴＰヘッダに含まれる情報（例えば、送信先ＩＰアドレス、送信先ポート番号、送信元ＩＰアドレス等）に基づいて、内部セッション番号テーブルから内部セッション番号を検索して、その検索した内部セッション番号に応じたデコーダ及びエンコーダの対に対応するソートバッファ２３−１〜２３−ｎに振り分ける。
【００４２】
パケット送信部２６は、エンコーダ２５−１〜２５−ｎにより符号化された符号化データを用いて送信パケットを形成し、その送信パケットを送出するものである。
【００４３】
パケット送信部２６によるパケットの形成方法は、種々の方法を適用することができるが、例えば、特許文献１に記載の方法を適用するようにしてもよい。例えば、チャネル振分け制御部２２が、処理対象のデータに、デコーダ及びエンコーダの対を示す内部セッション番号を付与しておく。このとき、内部セッション管理テーブルには、内部セッション番号と、ヘッダ情報（例えば、送信先ＭＡＣアドレス、送信元ＭＡＣアドレス、送信先ＩＰアドレス、送信元ＩＰアドレス、送信先ポート番号、送信元ポート番号）とを対応付ける。そして、パケット送信部２６が、符号化データに付与されている内部セッション番号に基づいて、対応するヘッダ情報を読み出し、このヘッダ情報を符号化データに付与してパケットを形成する方法を適用することができる。
【００４４】
ソートバッファ２３−１〜２３−ｎは、対応するデコーダ２４−１〜２４−ｎ及びエンコーダ２５−１〜２５−ｎの前段に設けられており、投入されたパケットの取り出し順序を変更することができるバッファ手段である。
【００４５】
ソートバッファ２３−１〜２３−ｎは、ソートバッファ制御部２７の制御により、チャネル振分け制御部２２からのパケットの投入及び取り出しを行い、取り出したパケットを、対応するデコーダ２４−１〜２４−ｎに与えるものである。
【００４６】
ソートバッファ制御部２７は、ソートバッファ２３−１〜２３−ｎに投入されるパケットのバッファ制御を行うものである。なお、ソートバッファ制御部２７によるバッファ制御処理については、動作の項で詳細に説明する。
【００４７】
図４は、ソートバッファ制御部２７のバッファ制御処理に係る変数を説明する説明図である。図５は、ソートバッファ制御処理を説明する説明図である。
【００４８】
図４において、ソートバッファ制御部２７は、バッファ制御処理に係る変数として「sort_buf_num」、ＲＴＰパケットのシーケンス番号を示す「sn」、受信したＲＴＰパケットのシーケンス番号を示す「sn_recv」、ソートバッファに存在する最大シーケンス番号を示す「sn_biggest」、ソートバッファに入り得る最小シーケンス番号を示す「sn_min」、ソートバッファに入り得る最大シーケンス番号を示す「sn_max」、Ｔｒａｎｓｃｏｄｅを実施するか否かを示す「trs_ctl」を用いる。
【００４９】
「sort_buf_num」は、各ソートバッファ２３−Ｎ（Ｎは１〜ｎ）内のバッファの個数である。「sort_buf_num」は、１つのソートバッファ２３−Ｎが受け入れることができるパケットデータの個数である。
【００５０】
「sort_buf_num」を設定することで、パケットデータの順序を入れ替えできる個数を設定することができる。つまり、「sort_buf_num」を設定は、「（sort_buf_num）−２」個のＲＴＰパケットデータの入れ替えができる。例えば、「（sort_buf_num）＝４」に設定すると、「（sort_buf_num）−２＝２個」のＲＴＰパケットデータの入れ替えができる。すなわち、この場合、２個のパケットデータの順序を元通りに並べ替えることができる。
【００５１】
ソートバッファ制御部２７は、受信したＲＴＰパケットのシーケンス番号（sn）に基づいて、ソートバッファ２３−Ｎへの投入及び当該ソートバッファからの取り出し処理を制御する。
【００５２】
ソートバッファ制御部２７は、ソートバッファ２３−Ｎにパケットデータを投入した時点で、図４に示した変数に基づいて、Ｔｒａｎｓｃｏｄｅを実施するかを判断し、Ｔｒａｎｓｃｏｄｅを実施する場合には、「trs_ctl」フラグを「Ｅｎａｂｌｅ」とし、そうでない場合には「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に設定する。
【００５３】
つまり、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置の先頭位置又は最終位置に、パケットデータが投入されると、「trs_ctl」フラグを「Ｅｎａｂｌｅ」とする。
【００５４】
「trs_ctl」フラグが「Ｅｎａｂｌｅ」となったら、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎからパケットデータを取り出す。これにより、ソートバッファ２３−Ｎからのパケットデータは、デコーダ２４−Ｎ及びエンコーダ２５−Ｎに与えられるために、Ｔｒａｎｓｃｏｄｅを実行させることができる。
【００５５】
また、ソートバッファ制御部２７は、ソートバッファ２３−Ｎからパケットデータを取り出す時点でも、継続してＴｒａｎｓｃｏｄｅを実施するかを判断し、上記と同様に、「trs_ctl」フラグを「Ｅｎａｂｌｅ」又は「Ｄｉｓａｂｌｅ」に設定する。
【００５６】
すなわち、パケットデータを取り出した時点で、引き続き、有効なデータ（すなわち、正しく取り出すべきデータ）があった場合には、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｅｎａｂｌｅ」のままとして、次のデータをソートバッファ２３−Ｎから取り出し、デコード及びエンコード処理を実行させる。有効なデータが無い場合、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に設定する。
【００５７】
また、ソートバッファ制御部２７は、受信したＲＴＰパケットデータのシーケンス番号が「sn_recv」＜「sn_min」である場合、ソートバッファ制御部２７は、受信したパケットデータを廃棄する。また、「sn_recv」＜「sn_max」である場合、ソートバッファ制御部２７は、すきまを空けずパケットデータを投入する。
【００５８】
（Ａ−２）第１の実施形態の動作
第１の実施形態のセッションボーダーコントローラ１の動作説明は省略する。以下では、第１の実施形態のコーデック変化装置１４におけるバッファ制御処理の動作を、図面を参照しながら詳細に説明する。
【００５９】
なお、以下では、各ソートバッファ２３−Ｎの「sort_buf_num」が「４」に設定されている場合を例示する。
【００６０】
図６は、ソートバッファ制御部２７による通常の投入動作を説明する説明図である。図７は、ソートバッファ制御部２７による通常の取出動作を説明する説明図である。
【００６１】
図６（Ａ）において、ソートバッファ２３−Ｎに入り得る最小シーケンス番号が「sn_min＝１２」であるとする。このとき、ソートバッファ２３−Ｎには、パケットデータが存在していないので、「sn_biggest＝−（なし）」である。
【００６２】
また、「sort_buf_num＝４」であるから、ソートバッファ２３−Ｎは４個のパケットデータを受け入れることができるので、ソートバッファ２３−Ｎに入り得る最大シーケンス番号は「sn_max＝１５」である。さらに、有効なデータがないので、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に設定する。
【００６３】
この状態で、シーケンス番号「sn_＝１２」のＲＴＰパケットデータが、シーケンス番号の順序通り受信されると、ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１２」に設定する（図６（Ａ）参照）。
【００６４】
そして、「sn_min＝１２」であるから、ソートバッファ制御部２７は、当該受信されたパケットデータをソートバッファ２３−Ｎの先頭の取出し位置に投入し、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に設定する。また、「sn＝１２」のパケットデータが投入されたので、ソートバッファ制御部２７は「sn_biggest＝１２」に設定する。
【００６５】
図７（Ａ）において、上記の状態で、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１２」パケットデータを取り出し、デコーダ２４−Ｎに与える。
【００６６】
このとき、図７（Ｂ）に示すように、ソートバッファ制御部２７は、「sn_min＝１３」、「sn_max＝１６」、「sn_biggest＝−」に更新すると共に、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に書き換える。
【００６７】
次に、図８及び図９を用いて、パケット順序が入れ替って、パケットデータがソートバッファに投入されたときの投入動作及び取り出し動作を説明する。
【００６８】
図８は、順序が入れ替わって投入されたときのソートバッファ制御部２７による投入動作を説明する説明図である。図９は、順序が入れ替わって投入されたときのソートバッファ制御部２７による取出動作を説明する説明図である。
【００６９】
以下では、シーケンス番号「sn＝１２」のＲＴＰパケットデータの前に、「sn＝１３」のＲＴＰパケットデータが受信された場合の動作を例示する。
【００７０】
図８（Ａ）の状態は、図６（Ａ）の状態と同じである。この状態で、「sn＝１３」のＲＴＰパケットデータが受信されると、ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１３」に設定する（図８（Ａ）参照）。
【００７１】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から２番目の位置に、当該受信されたパケットデータを投入する。「trs_ctl」フラグは「Ｄｉｓａｂｌｅ」のままとする。また、ソートバッファ制御部２７は「sn_biggest＝１３」に更新する（図８（Ｂ）参照）。
【００７２】
引き続き、シーケンス番号「sn＝１２」のＲＴＰパケットが受信されると、ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１２」に設定する（図８（Ｃ）参照）。
【００７３】
そして、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置の先頭の位置に、当該受信されたパケットデータを投入する。また、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に設定する。
【００７４】
図９（Ａ）において、上記状態において、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１２」パケットデータを取り出し、デコーダ２４−Ｎに与える（図９（Ｂ）参照）。
【００７５】
このとき、ソートバッファ制御部２７は、「sn_min＝１３」、「sn_max＝１６」に更新する。また、次に、取り出すべき「sn＝１３」のパケットデータがあるので、「trs_ctl」フラグは「Ｅｎａｂｌｅ」のままである。
【００７６】
そして、引き続き、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１３」パケットデータを取り出す。
【００７７】
このとき、ソートバッファ制御部２７は、「sn_min＝１４」、「sn_max＝１７」に更新すると共に、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に書き換える。
【００７８】
次に、図１０及び図１１を用いて、パケットロス発生時のソートバッファ２３−Ｎへの投入動作及び取出動作を説明する。
【００７９】
図１０は、パケットロス発生時のソートバッファ制御部２７による投入動作を説明する説明図である。図１１は、パケットロス発生時のソートバッファ制御部２７による取出動作を説明する説明図である。
【００８０】
以下では、送信側端末からコーデック変換装置１４までのネットワーク上で、シーケンス番号「sn＝１２」のＲＴＰパケットが失われた場合の動作を例示する。
【００８１】
図１０（Ａ）の状態は、図６（Ａ）の状態と同じである。この状態で、シーケンス番号「sn＝１３」のＲＴＰパケットが受信されたものとする。
【００８２】
ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１３」に設定する（図１０（Ａ）参照）。
【００８３】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から２番目の位置に、当該受信されたパケットデータを投入する。「trs_ctl」フラグは「Ｄｉｓａｂｌｅ」のままとする。また、ソートバッファ制御部２７は「sn_biggest＝１３」に更新する（図１０（Ｂ）参照）。
【００８４】
引き続き、シーケンス番号「sn＝１４」のＲＴＰパケットが受信される。ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１４」に設定する（図１０（Ｂ）参照）。
【００８５】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から３番目の位置に、当該受信されたパケットデータを投入する。「trs_ctl」フラグは「Ｄｉｓａｂｌｅ」のままとする（図１０（Ｂ）参照）。また、ソートバッファ制御部２７は「sn_biggest＝１４」に更新する（図１０（Ｃ）参照）。
【００８６】
次に、引き続き、シーケンス番号「sn＝１５」のＲＴＰパケットが受信される。ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１５」に設定する（図１０（Ｃ）参照）。
【００８７】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から４番目の位置に、当該受信されたパケットデータを投入する。
【００８８】
ここで、ソートバッファの取出位置の最後の位置にパケットデータが投入されたので、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に書き換え、
「sn_biggest＝１５」に更新する（図１０（Ｄ）参照）。
【００８９】
図１１（Ａ）において、上記の状態で、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎからの取出し処理を行う。
【００９０】
このとき、ソートバッファ２３−Ｎの先頭取出し位置にあるのは、「ｅｍｐｔｙ（データ無し）」であるから、デコーダ２４−Ｎは、パケットロス補償を実行し、エンコード処理も実行する（図１１（Ｂ）参照）。
【００９１】
また、このとき、ソートバッファ制御部２７は、「sn＿min＝１３」に更新をする（図１１（Ｂ）参照）。
【００９２】
そして、引き続き、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１３」パケットデータを取り出す（図１１（Ｃ）参照）。
【００９３】
このとき、ソートバッファ制御部２７は、「sn＿min＝１４」及び「sn＿max＝１７」に更新をする（図１１（Ｃ）参照）。
【００９４】
引き続き、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１４」のパケットデータを取り出す。ソートバッファ制御部２７は、「sn＿min＝１５」及び「sn＿max＝１８」に更新をする（図１１（Ｃ）参照）。
【００９５】
さらに、引き続き、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１５」のパケットデータを取り出す。ソートバッファ制御部２７は、「sn＿min＝１６」、「sn＿max＝１９」及び「sn＿biggest＝−」に更新をすると共に、「trs_ctl」フラグが「Ｄｉｓａｂｌｅ」に書き換える（図１１（Ｄ）参照）。
【００９６】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、ソートバッファ制御部は、パケット受信した時点で、ソートバッファにパケットデータを投入し、Ｔｒａｎｓｃｏｄｅを実施するかを判断する。そして、Ｔｒａｎｓｃｏｄｅの実施可能な条件となれば、直ちにデータを取出し、エンコードおよびデコード処理を実行するようにしたので、パケットの順序入れ替わりやパケットロスが発生しても、必要最小限の遅延で、パケットの順序入れ替えやパケットロス補償を実行し、音質の劣化を防止することができる。
【００９７】
（Ｂ）第２の実施形態
次に、本発明の本発明のバッファ制御装置、バッファ制御プログラム及び通信装置の第２の実施形態を、図面を参照しながら説明する。
【００９８】
（Ｂ−１）第２の実施形態の構成
第２の実施形態が、第１の実施形態と異なる点は、ソートバッファ制御部が、タイマ処理を行う点である。
【００９９】
それ以外の第２の実施形態の構成及び動作は、第１の実施形態の構成及び動作と同じであるので、第２の実施形態でも、図１及び図３を用いながら、第２の実施形態の特徴的な構成及び動作を中心に説明する。
【０１００】
第２の実施形態のソートバッファ制御部２７は、タイマ処理機能を有する。ソートバッファ制御部２７は、パケットデータがソートバッファ２３−Ｎの取出し位置の先頭又は最終位置以外に投入されると、所定のタイマ時間を計時するものである。また、ソートバッファ制御部２７は、タイマ時間が満了になると、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に書き換えるものである。なお、タイマ時間が満了する前に、次のパケットが受信された場合、ソートバッファ制御部２７はタイマをリセットする。
【０１０１】
（Ｂ−２）第２の実施形態の動作
図１２は、第２の実施形態のソートバッファ制御部２７のバッファ制御処理を説明する説明図である。
【０１０２】
図１２（Ａ）の状態は、図６（Ａ）の状態と同じである。この状態で、シーケンス番号「sn＝１３」のＲＴＰパケットが受信されたものとする。
【０１０３】
ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１３」に設定する（図１２（Ａ）参照）。
【０１０４】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から２番目の位置に、当該受信されたパケットデータを投入する。
【０１０５】
ここで、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置の先頭又は最終位置以外に、パケットデータが投入されたので、タイマを起動する。タイマ時間は、特に限定されるものではないが、例えば２０ｍｓとする。
【０１０６】
なお、ソートバッファ制御部２７は、「trs_ctl」フラグは「Ｄｉｓａｂｌｅ」のままとする。また、ソートバッファ制御部２７は「sn_biggest＝１３」に更新する（図１２（Ｂ）参照）。
【０１０７】
その後、タイマを起動してから、次に到着すべきＲＴＰパケットが受信しないものとする。
【０１０８】
タイマ時間が満了すると、図１２（Ｃ）に示すように、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に書き換えを行う。
【０１０９】
このとき、図１２（Ｄ）に示すように、ソートバッファ２３−Ｎの取出し位置の先頭位置は「Ｅｍｐｔｙ（データ無し）」であるから、ソートバッファ制御部２７は、「Ｅｍｐｔｙ」を取り出し、対応するデコーダ２４−Ｎによるパケットロス補償を行い、エンコード処理を行う。
【０１１０】
次に、図１２（Ｅ）に示すように、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置の先頭位置にある、シーケンス番号「sn＝１３」のパケットデータを取り出すようにする。
【０１１１】
そして、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に書き換え、又内部の変数の更新も行う。
【０１１２】
（Ｂ−３）第２の実施形態の効果
以上のように、第２の実施形態によれば、第１の実施形態の効果に加えて、パケットロス発生時のソートバッファでの遅延時間を、タイマ満了時間以下となるようにしたので、パケットロス発生時は更に遅延を低減することができる。但し、タイマ満了時間を短くし過ぎると、パケット入れ替わりに対応できないケースも生じるので、注意が必要である。
【０１１３】
（Ｃ）他の実施形態
上述した第１及び第２の実施形態では、デコーダ及びエンコーダが複数ある場合を例示したが、１個の場合であってもよい。
【０１１４】
また、上述した第１及び第２の実施形態では、コーデック変換装置に、本発明のバッファ制御処理を適用する場合を説明したが、コーデック変換装置のバッファ制御処理に限定されるものでない。例えば、コーデック変換処理が無くても、ＲＴＰパケットを中継する通信装置が、受信パケットをバッファリングする制御処理に、本発明を適用することができる。
【０１１５】
上述した第１及び第２の実施形態では、パケットロス発生時に、パケットロス補償を行うようにしたが、パケットロス時のデコード／エンコード処理を省略し、パケットロス補償を受信側の端末に委ねるようにしても良い。
【符号の説明】
【０１１６】
１…セッションボーダーコントローラ、１４…コーデック変換装置、
２１…パケット受信部、２２…チャネル振分け制御部、
２３−１〜２３−ｎ…ソートバッファ、２４−１〜２４−ｎ…デコーダ、
２５−１〜２５−ｎ…エンコーダ、２６…パケット送信部、
２７…ソートバッファ制御部。
【技術分野】
【０００１】
本発明は、バッファ制御装置、バッファ制御プログラム及び通信装置に関し、例えば、ネットワーク境界に設けられるセッションボーダーコントローラ（Ｓ／ＢＣ）に適用し得るものである。
【背景技術】
【０００２】
例えば、ＮＧＮ（次世代ネットワーク）等のＩＰ相互接続環境等において、各事業者網に収容された異なる端末間で、データ交換が行なわれるようになる。ＩＰ相互接続における通信は、単なるデータ以外に、音声や映像等のメディアデータも含まれることになる。この場合、各事業者網のコーデックが異なる場合、送信元の事業者網のコーデックから送信先の事業者網のコーデックに変換するコーデック変換技術が必要となる。
【０００３】
従来のコーデック変換方式として、特許文献１に記載の技術がある。特許文献１に記載のコーデック変換方式は、特許文献１の図１に示すように、パケット（例えばＲＴＰパケット）が受信されると、ＮＷ（ネットワーク）バッファにパケットを投入する。ＮＷバッファにパケットが蓄積されると、リソース振分部が、順次、ＮＷバッファからパケットを取り出し、リソース振分を行う。そして、各デコーダ／エンコーダでコーデック変換処理を実施して、パケット送出するというものである。
【０００４】
特許文献１には、多くのエンドのＶｏＩＰ電話端末が、パケットの順序入れ替えやパケットロス補償を実行することに鑑み、エンドツーエンドの端末にそれら処理を期待し、コーデック変換装置は、パケットの順序入れ替えやパケットロス補償を実行しないこととし、コーデック変換処理遅延を小さくすることが記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２６７６２８号公報
【特許文献２】特開２００５−６４８７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したように、特許文献１に記載の技術は、コーデック変換処理遅延を小さくするため、コーデック変換装置が、パケットの順序入れ替えやパケットロス補償を実行しないというものである。
【０００７】
しかしながら、エンドツーエンド端末でパケットの順序入れ替えやパケットロス補償を実行していたとしても、コーデック変換装置が、パケットの順序入れ替えやパケットロス補償を実行しないと、音質の劣化が生じることがあるという問題がある。
【０００８】
図２は、コーデック変換装置において、パケットの順序入れ替わりが発生した場合に、音質が劣化するときの例を説明する説明図である。図２では、コーデック変換装置９１が、ＡＭＲ（Adaptive MultiRate）からＩＴＵ−Ｔ Ｇ．７１１にコーデック変換を行うものである。
【０００９】
図２において、送信側の端末９２は、原音を例えば２０ｍｓで区切り、原音（１）、原音（２），原音（３），原音（４）を順次ＡＭＲでエンコードし、ＡＭＲ（１），ＡＭＲ（２），ＡＭＲ（３），ＡＭＲ（４）を順次送出する。ここで、送信側の端末９２からコーデック変換装置９１へのネットワークにて、パケットの順序入れ替わりが発生し、コーデック変換装置９１が、ＡＭＲ（２）より先にＡＭＲ（３）を受信したとする。
【００１０】
この場合、コーデック変換装置９１のＡＭＲデコーダ入力は、ＡＭＲ（１），ＡＭＲ（２），ＡＭＲ（３），ＡＭＲ（４）の順番ではなく、ＡＭＲ（１），ＡＭＲ（３），ＡＭＲ（２），ＡＭＲ（４）の順番でデコード処理を実行する。
【００１１】
ここで、デコーダ入力の順序が入れ替ったことにより、デコーダ出力のＬｉｎｅａｒ音声が原音と異なってしまい、音質が劣化するという問題が生ずる。これは、ＡＭＲなどの音声コーデックでは、過去の音声データより得られた情報も用いて、エンコード／デコード処理を実施しているからである。
【００１２】
受信側の端末９３において、パケットの順序入れ替わりを元に戻したとしても、劣化した音質を元通りにすることは出来ない。
【００１３】
また、例えば特許文献２に記載のジッタバッファを用いることで、パケットの順序入れ替わりやパケットロスが発生しても、音質の劣化を低減することができる。しかし、ジッタバッファへの投入から取り出しまでの時間分だけ、コーデック変換処理に遅延が増加してしまうという問題が生じ得る。
【００１４】
そのため、パケットの順序の入れ替わりやパケットロスなどが生じた場合に、できるだけ小さい遅延で、パケットの順序の入れ替えやパケットロス補償を実行して、音質の劣化を防止することができるバッファ制御装置、バッファ制御プログラム及び通信装置が求められている。
【課題を解決するための手段】
【００１５】
かかる課題を解決するために、第１の本発明は、（１）ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段と、（２）バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段と、（３）少なくとも、入力されたパケットのシーケンス番号に基づき、バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、データのバッファ手段への投入時又はバッファ手段からのデータ取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段とを備えることを特徴とするバッファ制御装置である。
【００１６】
第２の本発明は、コンピュータを、（１）ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段、（２）バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段、（３）少なくとも、入力されたパケットのシーケンス番号に基づき、バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、パケットのデータのバッファ手段への投入時又はバッファ手段からの取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段として機能させるものであることを特徴とするバッファ制御プログラムである。
【００１７】
第３の本発明は、それぞれ異なるネットワークに接続する通信装置において、各ネットワークにおけるコーデックの相違を吸収する第１の本発明のバッファ制御装置を有することを特徴とする通信装置である。
【発明の効果】
【００１８】
本発明によれば、パケットの順序の入れ替わりやパケットロスなどが生じた場合に、できるだけ小さい遅延で、パケットの順序の入れ替えやパケットロス補償を実行して、音質の劣化を防止することができる。
【図面の簡単な説明】
【００１９】
【図１】第１の実施形態のコーデック変換装置の詳細な内部構成を示すブロック図である。
【図２】コーデック変換装置において、パケットの順序入れ替わりが発生した場合に、音質が劣化するときの例を説明する説明図である。
【図３】第１の実施形態のセッションボーダーコントローラの概略内部構成を示すブロック図である。
【図４】第１の実施形態におけるソートバッファ制御部のバッファ制御処理に係る変数を説明する説明図である。
【図５】第１の実施形態におけるソートバッファ制御処理を説明する説明図である。
【図６】第１の実施形態におけるソートバッファ制御部による通常の投入動作を説明する説明図である。
【図７】第１の実施形態におけるソートバッファ制御部による通常の取出動作を説明する説明図である。
【図８】第１の実施形態において、順序が入れ替わって投入されたときのソートバッファ制御部による投入動作を説明する説明図である。
【図９】第１の実施形態において、順序が入れ替わって投入されたときのソートバッファ制御部による取出動作を説明する説明図である。
【図１０】第１の実施形態において、パケットロス発生時のソートバッファ制御部による投入動作を説明する説明図である。
【図１１】第１の実施形態において、パケットロス発生時のソートバッファ制御部による取出動作を説明する説明図である。
【図１２】第２の実施形態のソートバッファ制御部によるバッファ制御処理を説明する説明図である。
【発明を実施するための形態】
【００２０】
（Ａ）第１の実施形態
以下では、本発明のバッファ制御装置、バッファ制御プログラム及び通信装置の第１の実施形態を、図面を参照しながら説明する。
【００２１】
第１の実施形態では、事業者網の境界に設けられるセッションボーダーコントローラ（Ｓ／ＢＣ）のコーデック変換装置に、本発明を適用する場合の実施形態を例示する。
【００２２】
（Ａ−１）第１の実施形態の構成
図３は、第１の実施形態のセッションボーダーコントローラの概略内部構成（イメージ的な構成）を示すブロック図である。
【００２３】
第１の実施形態のセッションボーダーコントローラ１は、異なる事業者網間の境界設けられる通信装置である。図３に示すように、セッションボーダーコントローラ１は、複数のインタフェース部１１−１及び１１−２、制御部１２、スイッチ部１３を有する。
【００２４】
セッションボーダーコントローラ１は、例えば、文献「ＩＴＵ−Ｔ Ｙ．２０１２ Supplement」に規定されている、ＩＰｖ４／ｖ６変換（ＮＡＴ／ＮＡＰＴ）ピンホール制御、ＴＨＩＧ（トポロジーハイディング）等の機能を実現するものである。
【００２５】
また、セッションボーダーコントローラ１は、コーデック変換装置１４を内蔵又は外付けで備えるものである。
【００２６】
ＳＩＰサーバ２は、ＩＰ電話端末３−１及び３−２間の呼を制御する呼制御サーバである。ＳＩＰサーバ２は、ＳＩＰのセッションの確立処理の中で、通話しようとするＩＰ電話端末３−１、３−２が適用しているコーデック（ＩＰ電話端末３−１、３−２が収容されている事業者網の採用コーデック）を認識する。そして、両ＩＰ電話端末３−１及び３−２のコーデックが異なる場合、ＳＩＰサーバ２は、コーデック変換開始指示をセッションボーダーコントローラ２に発行するものである。
【００２７】
セッションボーダーコントローラ１において、制御部１２は、コーデック変換開始指示が与えられると、インタフェース部１１−１、１１−２、スイッチ部１３及びコーデック変換装置１４を制御し、コーデック変換を実行できるようにする。
【００２８】
制御部１２は、一方のＩＰ電話端末３−１からのパケットを、ＩＰ電話端末３−１を収容しているインタフェース部１１−１及びスイッチ部１３を介して、コーデック変換装置１４に与える。そして、制御部１２は、コーデック変換装置１４を制御して、他方のＩＰ電話端末３−２が適用しているコーデックに変換させ、コーデック変換装置１４から出力されたパケットを、スイッチ部１３、及び、ＩＰ電話端末３−２を収容しているインタフェース部１１−２を介して、他方のＩＰ電話端末３−２に送出できるように制御する。また、制御部１２は、逆方向についても、コーデック変換を実行できるように制御する。
【００２９】
コーデック変換が可能となったときに、制御部１２は、ＳＩＰサーバ２に、コーデック変換開始ＯＫを返信する。ＳＩＰサーバ２は、両電話端末３−１及び３−２に通話ＯＫを通知する。
【００３０】
これにより、通話が開始し、開始された通話に係るパケットは、コーデック変換装置１４を介して対向するＩＰ電話端末が適用しているコーデックのパケットに変換され、対向するＩＰ電話端末に送出される。
【００３１】
図１は、コーデック変換装置１４の詳細な内部構成を示すブロック図である。図１において、コーデック変換装置１４は、パケット受信部２１、チャネル振分け制御部２２、複数のソートバッファ２３−１〜２３−ｎ（ｎ：正の整数）、それぞれ対をなす複数のデコーダ２４−１〜２４−ｎ及びエンコーダ２５−１〜２５−ｎ、パケット送信部２６、ソートバッファ制御部２７を有する。
【００３２】
なお、コーデック変換装置１４は、例えば、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、入出力インタフェース部等を有して構成される装置である。コーデック変換装置１４の機能は、ＣＰＵが、ＲＯＭに格納されるコーデック変換プログラムやバッファ制御プログラム等の処理プログラムを実行することにより実現されるものである。なお、処理プログラムはネットワークを通じてインストールされるものであってもよく、その場合でも、図１に示す機能構成を有する。
【００３３】
コーデック変換装置１４は、ある事業者網の符号化方式のデータを、他の事業者網の符号化方式のデータに変換するものである。コーデック変換装置１４は、例えば、ＩＴＵ−Ｔ Ｇ．７１１、ＩＴＵ−Ｔ Ｇ．７２２、ＥＶＲＣ（Enhanced Variable Rate Codec）、ＡＭＲ等の間で符号化方式の変換を行うことができる。
【００３４】
例えば、コーデック変化装置１４は、「Ｇ．７１１→ＥＶＲＣ」、「Ｇ．７１１→ＡＭＲ」、「Ｇ．７１１→Ｇ．７２２」、「ＥＶＲＣ→Ｇ．７１１」、「ＡＭＲ→Ｇ．７１１」、「Ｇ．７２２→Ｇ．７１１」のコーデック変換を行うことができる。なお、上記以外のコーデック変換として、コーデック変化装置１４は、例えば「ＥＶＲＣ→ＡＭＲ」等のようなコーデック変換を行うようにしてもよい。
【００３５】
デコーダ２４−Ｎ（Ｎは１〜ｎ）は、入力された符号化音声データを復号して、原音に戻すものである。デコーダ２４−Ｎは、原音の音声データを、対応するエンコーダ２５−Ｎに与えるものである。
【００３６】
エンコーダ２５−Ｎは、原音の音声データを、自己について定まっている符号化方式（コーデック方式）に従って符号化し、符号化音声データをパケット送信部２６に与えるものである。
【００３７】
ここで、デコーダ２４−Ｎとエンコーダ２５−Ｎとは、対をなすものである。すなわち、デコーダ２４−Ｎ及びエンコーダ２５−Ｎの符号化方式の組み合わせによって、コーデック変換の内容が定まる。例えば、デコーダ２４−１がＧ．７１１対応であり、エンコーダ２５−１がＥＶＲＣ対応であれば、この対は、「Ｇ．７１１→ＥＶＲＣ」へのコーデック変換に供するものである。
【００３８】
例えば、デコーダ２４−Ｎとエンコーダ２５−Ｎとの対は、ＤＳＰ（ディジタルシグナルプロセッサ）によって実現される。１個のＤＳＰには、複数のチャネル（例えば２００チャネル程度）用のデコーダ及びエンコーダの対が搭載されている。コーデック変換装置１４は、このようなＤＳＰを複数個(例えば１５０個)設けられている。
【００３９】
パケット受信部２１は、入力されたパケットを受信し、その受信されたパケットをチャネル振分け制御部２２に与えるものである。
【００４０】
チャネル振分け制御部２２は、パケット受信部２１からのパケットのチャネルを識別し、チャネル別のソートバッファ２３−１〜２３−ｎにパケットを与えるものである。
【００４１】
チャネル振分け制御部２２によるチャネル振分け方法は、例えば、特許文献１に記載の技術を用いて振り分けることができる。例えば、チャネル振分け制御部２２は、デコーダ及びエンコーダの１対１の対を示す内部セッション番号を管理する内部セッション管理テーブルと、デコーダ及びエンコーダのコーデック変換種類と各コーデック変換を実行させるＤＳＰとを対応付けたＤＳＰ管理テーブル等を有する。チャネル振分け制御部２２は、ＩＰパケットのＲＴＰヘッダに含まれる情報（例えば、送信先ＩＰアドレス、送信先ポート番号、送信元ＩＰアドレス等）に基づいて、内部セッション番号テーブルから内部セッション番号を検索して、その検索した内部セッション番号に応じたデコーダ及びエンコーダの対に対応するソートバッファ２３−１〜２３−ｎに振り分ける。
【００４２】
パケット送信部２６は、エンコーダ２５−１〜２５−ｎにより符号化された符号化データを用いて送信パケットを形成し、その送信パケットを送出するものである。
【００４３】
パケット送信部２６によるパケットの形成方法は、種々の方法を適用することができるが、例えば、特許文献１に記載の方法を適用するようにしてもよい。例えば、チャネル振分け制御部２２が、処理対象のデータに、デコーダ及びエンコーダの対を示す内部セッション番号を付与しておく。このとき、内部セッション管理テーブルには、内部セッション番号と、ヘッダ情報（例えば、送信先ＭＡＣアドレス、送信元ＭＡＣアドレス、送信先ＩＰアドレス、送信元ＩＰアドレス、送信先ポート番号、送信元ポート番号）とを対応付ける。そして、パケット送信部２６が、符号化データに付与されている内部セッション番号に基づいて、対応するヘッダ情報を読み出し、このヘッダ情報を符号化データに付与してパケットを形成する方法を適用することができる。
【００４４】
ソートバッファ２３−１〜２３−ｎは、対応するデコーダ２４−１〜２４−ｎ及びエンコーダ２５−１〜２５−ｎの前段に設けられており、投入されたパケットの取り出し順序を変更することができるバッファ手段である。
【００４５】
ソートバッファ２３−１〜２３−ｎは、ソートバッファ制御部２７の制御により、チャネル振分け制御部２２からのパケットの投入及び取り出しを行い、取り出したパケットを、対応するデコーダ２４−１〜２４−ｎに与えるものである。
【００４６】
ソートバッファ制御部２７は、ソートバッファ２３−１〜２３−ｎに投入されるパケットのバッファ制御を行うものである。なお、ソートバッファ制御部２７によるバッファ制御処理については、動作の項で詳細に説明する。
【００４７】
図４は、ソートバッファ制御部２７のバッファ制御処理に係る変数を説明する説明図である。図５は、ソートバッファ制御処理を説明する説明図である。
【００４８】
図４において、ソートバッファ制御部２７は、バッファ制御処理に係る変数として「sort_buf_num」、ＲＴＰパケットのシーケンス番号を示す「sn」、受信したＲＴＰパケットのシーケンス番号を示す「sn_recv」、ソートバッファに存在する最大シーケンス番号を示す「sn_biggest」、ソートバッファに入り得る最小シーケンス番号を示す「sn_min」、ソートバッファに入り得る最大シーケンス番号を示す「sn_max」、Ｔｒａｎｓｃｏｄｅを実施するか否かを示す「trs_ctl」を用いる。
【００４９】
「sort_buf_num」は、各ソートバッファ２３−Ｎ（Ｎは１〜ｎ）内のバッファの個数である。「sort_buf_num」は、１つのソートバッファ２３−Ｎが受け入れることができるパケットデータの個数である。
【００５０】
「sort_buf_num」を設定することで、パケットデータの順序を入れ替えできる個数を設定することができる。つまり、「sort_buf_num」を設定は、「（sort_buf_num）−２」個のＲＴＰパケットデータの入れ替えができる。例えば、「（sort_buf_num）＝４」に設定すると、「（sort_buf_num）−２＝２個」のＲＴＰパケットデータの入れ替えができる。すなわち、この場合、２個のパケットデータの順序を元通りに並べ替えることができる。
【００５１】
ソートバッファ制御部２７は、受信したＲＴＰパケットのシーケンス番号（sn）に基づいて、ソートバッファ２３−Ｎへの投入及び当該ソートバッファからの取り出し処理を制御する。
【００５２】
ソートバッファ制御部２７は、ソートバッファ２３−Ｎにパケットデータを投入した時点で、図４に示した変数に基づいて、Ｔｒａｎｓｃｏｄｅを実施するかを判断し、Ｔｒａｎｓｃｏｄｅを実施する場合には、「trs_ctl」フラグを「Ｅｎａｂｌｅ」とし、そうでない場合には「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に設定する。
【００５３】
つまり、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置の先頭位置又は最終位置に、パケットデータが投入されると、「trs_ctl」フラグを「Ｅｎａｂｌｅ」とする。
【００５４】
「trs_ctl」フラグが「Ｅｎａｂｌｅ」となったら、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎからパケットデータを取り出す。これにより、ソートバッファ２３−Ｎからのパケットデータは、デコーダ２４−Ｎ及びエンコーダ２５−Ｎに与えられるために、Ｔｒａｎｓｃｏｄｅを実行させることができる。
【００５５】
また、ソートバッファ制御部２７は、ソートバッファ２３−Ｎからパケットデータを取り出す時点でも、継続してＴｒａｎｓｃｏｄｅを実施するかを判断し、上記と同様に、「trs_ctl」フラグを「Ｅｎａｂｌｅ」又は「Ｄｉｓａｂｌｅ」に設定する。
【００５６】
すなわち、パケットデータを取り出した時点で、引き続き、有効なデータ（すなわち、正しく取り出すべきデータ）があった場合には、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｅｎａｂｌｅ」のままとして、次のデータをソートバッファ２３−Ｎから取り出し、デコード及びエンコード処理を実行させる。有効なデータが無い場合、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に設定する。
【００５７】
また、ソートバッファ制御部２７は、受信したＲＴＰパケットデータのシーケンス番号が「sn_recv」＜「sn_min」である場合、ソートバッファ制御部２７は、受信したパケットデータを廃棄する。また、「sn_recv」＜「sn_max」である場合、ソートバッファ制御部２７は、すきまを空けずパケットデータを投入する。
【００５８】
（Ａ−２）第１の実施形態の動作
第１の実施形態のセッションボーダーコントローラ１の動作説明は省略する。以下では、第１の実施形態のコーデック変化装置１４におけるバッファ制御処理の動作を、図面を参照しながら詳細に説明する。
【００５９】
なお、以下では、各ソートバッファ２３−Ｎの「sort_buf_num」が「４」に設定されている場合を例示する。
【００６０】
図６は、ソートバッファ制御部２７による通常の投入動作を説明する説明図である。図７は、ソートバッファ制御部２７による通常の取出動作を説明する説明図である。
【００６１】
図６（Ａ）において、ソートバッファ２３−Ｎに入り得る最小シーケンス番号が「sn_min＝１２」であるとする。このとき、ソートバッファ２３−Ｎには、パケットデータが存在していないので、「sn_biggest＝−（なし）」である。
【００６２】
また、「sort_buf_num＝４」であるから、ソートバッファ２３−Ｎは４個のパケットデータを受け入れることができるので、ソートバッファ２３−Ｎに入り得る最大シーケンス番号は「sn_max＝１５」である。さらに、有効なデータがないので、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に設定する。
【００６３】
この状態で、シーケンス番号「sn_＝１２」のＲＴＰパケットデータが、シーケンス番号の順序通り受信されると、ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１２」に設定する（図６（Ａ）参照）。
【００６４】
そして、「sn_min＝１２」であるから、ソートバッファ制御部２７は、当該受信されたパケットデータをソートバッファ２３−Ｎの先頭の取出し位置に投入し、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に設定する。また、「sn＝１２」のパケットデータが投入されたので、ソートバッファ制御部２７は「sn_biggest＝１２」に設定する。
【００６５】
図７（Ａ）において、上記の状態で、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１２」パケットデータを取り出し、デコーダ２４−Ｎに与える。
【００６６】
このとき、図７（Ｂ）に示すように、ソートバッファ制御部２７は、「sn_min＝１３」、「sn_max＝１６」、「sn_biggest＝−」に更新すると共に、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に書き換える。
【００６７】
次に、図８及び図９を用いて、パケット順序が入れ替って、パケットデータがソートバッファに投入されたときの投入動作及び取り出し動作を説明する。
【００６８】
図８は、順序が入れ替わって投入されたときのソートバッファ制御部２７による投入動作を説明する説明図である。図９は、順序が入れ替わって投入されたときのソートバッファ制御部２７による取出動作を説明する説明図である。
【００６９】
以下では、シーケンス番号「sn＝１２」のＲＴＰパケットデータの前に、「sn＝１３」のＲＴＰパケットデータが受信された場合の動作を例示する。
【００７０】
図８（Ａ）の状態は、図６（Ａ）の状態と同じである。この状態で、「sn＝１３」のＲＴＰパケットデータが受信されると、ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１３」に設定する（図８（Ａ）参照）。
【００７１】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から２番目の位置に、当該受信されたパケットデータを投入する。「trs_ctl」フラグは「Ｄｉｓａｂｌｅ」のままとする。また、ソートバッファ制御部２７は「sn_biggest＝１３」に更新する（図８（Ｂ）参照）。
【００７２】
引き続き、シーケンス番号「sn＝１２」のＲＴＰパケットが受信されると、ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１２」に設定する（図８（Ｃ）参照）。
【００７３】
そして、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置の先頭の位置に、当該受信されたパケットデータを投入する。また、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に設定する。
【００７４】
図９（Ａ）において、上記状態において、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１２」パケットデータを取り出し、デコーダ２４−Ｎに与える（図９（Ｂ）参照）。
【００７５】
このとき、ソートバッファ制御部２７は、「sn_min＝１３」、「sn_max＝１６」に更新する。また、次に、取り出すべき「sn＝１３」のパケットデータがあるので、「trs_ctl」フラグは「Ｅｎａｂｌｅ」のままである。
【００７６】
そして、引き続き、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１３」パケットデータを取り出す。
【００７７】
このとき、ソートバッファ制御部２７は、「sn_min＝１４」、「sn_max＝１７」に更新すると共に、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に書き換える。
【００７８】
次に、図１０及び図１１を用いて、パケットロス発生時のソートバッファ２３−Ｎへの投入動作及び取出動作を説明する。
【００７９】
図１０は、パケットロス発生時のソートバッファ制御部２７による投入動作を説明する説明図である。図１１は、パケットロス発生時のソートバッファ制御部２７による取出動作を説明する説明図である。
【００８０】
以下では、送信側端末からコーデック変換装置１４までのネットワーク上で、シーケンス番号「sn＝１２」のＲＴＰパケットが失われた場合の動作を例示する。
【００８１】
図１０（Ａ）の状態は、図６（Ａ）の状態と同じである。この状態で、シーケンス番号「sn＝１３」のＲＴＰパケットが受信されたものとする。
【００８２】
ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１３」に設定する（図１０（Ａ）参照）。
【００８３】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から２番目の位置に、当該受信されたパケットデータを投入する。「trs_ctl」フラグは「Ｄｉｓａｂｌｅ」のままとする。また、ソートバッファ制御部２７は「sn_biggest＝１３」に更新する（図１０（Ｂ）参照）。
【００８４】
引き続き、シーケンス番号「sn＝１４」のＲＴＰパケットが受信される。ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１４」に設定する（図１０（Ｂ）参照）。
【００８５】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から３番目の位置に、当該受信されたパケットデータを投入する。「trs_ctl」フラグは「Ｄｉｓａｂｌｅ」のままとする（図１０（Ｂ）参照）。また、ソートバッファ制御部２７は「sn_biggest＝１４」に更新する（図１０（Ｃ）参照）。
【００８６】
次に、引き続き、シーケンス番号「sn＝１５」のＲＴＰパケットが受信される。ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１５」に設定する（図１０（Ｃ）参照）。
【００８７】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から４番目の位置に、当該受信されたパケットデータを投入する。
【００８８】
ここで、ソートバッファの取出位置の最後の位置にパケットデータが投入されたので、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に書き換え、
「sn_biggest＝１５」に更新する（図１０（Ｄ）参照）。
【００８９】
図１１（Ａ）において、上記の状態で、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎからの取出し処理を行う。
【００９０】
このとき、ソートバッファ２３−Ｎの先頭取出し位置にあるのは、「ｅｍｐｔｙ（データ無し）」であるから、デコーダ２４−Ｎは、パケットロス補償を実行し、エンコード処理も実行する（図１１（Ｂ）参照）。
【００９１】
また、このとき、ソートバッファ制御部２７は、「sn＿min＝１３」に更新をする（図１１（Ｂ）参照）。
【００９２】
そして、引き続き、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１３」パケットデータを取り出す（図１１（Ｃ）参照）。
【００９３】
このとき、ソートバッファ制御部２７は、「sn＿min＝１４」及び「sn＿max＝１７」に更新をする（図１１（Ｃ）参照）。
【００９４】
引き続き、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１４」のパケットデータを取り出す。ソートバッファ制御部２７は、「sn＿min＝１５」及び「sn＿max＝１８」に更新をする（図１１（Ｃ）参照）。
【００９５】
さらに、引き続き、「trs_ctl」フラグが「Ｅｎａｂｌｅ」であるから、ソートバッファ制御部２７は、直ちに、ソートバッファ２３−Ｎの先頭取出し位置にある、「sn＝１５」のパケットデータを取り出す。ソートバッファ制御部２７は、「sn＿min＝１６」、「sn＿max＝１９」及び「sn＿biggest＝−」に更新をすると共に、「trs_ctl」フラグが「Ｄｉｓａｂｌｅ」に書き換える（図１１（Ｄ）参照）。
【００９６】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、ソートバッファ制御部は、パケット受信した時点で、ソートバッファにパケットデータを投入し、Ｔｒａｎｓｃｏｄｅを実施するかを判断する。そして、Ｔｒａｎｓｃｏｄｅの実施可能な条件となれば、直ちにデータを取出し、エンコードおよびデコード処理を実行するようにしたので、パケットの順序入れ替わりやパケットロスが発生しても、必要最小限の遅延で、パケットの順序入れ替えやパケットロス補償を実行し、音質の劣化を防止することができる。
【００９７】
（Ｂ）第２の実施形態
次に、本発明の本発明のバッファ制御装置、バッファ制御プログラム及び通信装置の第２の実施形態を、図面を参照しながら説明する。
【００９８】
（Ｂ−１）第２の実施形態の構成
第２の実施形態が、第１の実施形態と異なる点は、ソートバッファ制御部が、タイマ処理を行う点である。
【００９９】
それ以外の第２の実施形態の構成及び動作は、第１の実施形態の構成及び動作と同じであるので、第２の実施形態でも、図１及び図３を用いながら、第２の実施形態の特徴的な構成及び動作を中心に説明する。
【０１００】
第２の実施形態のソートバッファ制御部２７は、タイマ処理機能を有する。ソートバッファ制御部２７は、パケットデータがソートバッファ２３−Ｎの取出し位置の先頭又は最終位置以外に投入されると、所定のタイマ時間を計時するものである。また、ソートバッファ制御部２７は、タイマ時間が満了になると、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に書き換えるものである。なお、タイマ時間が満了する前に、次のパケットが受信された場合、ソートバッファ制御部２７はタイマをリセットする。
【０１０１】
（Ｂ−２）第２の実施形態の動作
図１２は、第２の実施形態のソートバッファ制御部２７のバッファ制御処理を説明する説明図である。
【０１０２】
図１２（Ａ）の状態は、図６（Ａ）の状態と同じである。この状態で、シーケンス番号「sn＝１３」のＲＴＰパケットが受信されたものとする。
【０１０３】
ソートバッファ制御部２７は、受信されたＲＴＰパケットのシーケンス番号に基づいて「sn_recv＝１３」に設定する（図１２（Ａ）参照）。
【０１０４】
このとき、「sn_min＝１２」であるから、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置から２番目の位置に、当該受信されたパケットデータを投入する。
【０１０５】
ここで、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置の先頭又は最終位置以外に、パケットデータが投入されたので、タイマを起動する。タイマ時間は、特に限定されるものではないが、例えば２０ｍｓとする。
【０１０６】
なお、ソートバッファ制御部２７は、「trs_ctl」フラグは「Ｄｉｓａｂｌｅ」のままとする。また、ソートバッファ制御部２７は「sn_biggest＝１３」に更新する（図１２（Ｂ）参照）。
【０１０７】
その後、タイマを起動してから、次に到着すべきＲＴＰパケットが受信しないものとする。
【０１０８】
タイマ時間が満了すると、図１２（Ｃ）に示すように、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｅｎａｂｌｅ」に書き換えを行う。
【０１０９】
このとき、図１２（Ｄ）に示すように、ソートバッファ２３−Ｎの取出し位置の先頭位置は「Ｅｍｐｔｙ（データ無し）」であるから、ソートバッファ制御部２７は、「Ｅｍｐｔｙ」を取り出し、対応するデコーダ２４−Ｎによるパケットロス補償を行い、エンコード処理を行う。
【０１１０】
次に、図１２（Ｅ）に示すように、ソートバッファ制御部２７は、ソートバッファ２３−Ｎの取出し位置の先頭位置にある、シーケンス番号「sn＝１３」のパケットデータを取り出すようにする。
【０１１１】
そして、ソートバッファ制御部２７は、「trs_ctl」フラグを「Ｄｉｓａｂｌｅ」に書き換え、又内部の変数の更新も行う。
【０１１２】
（Ｂ−３）第２の実施形態の効果
以上のように、第２の実施形態によれば、第１の実施形態の効果に加えて、パケットロス発生時のソートバッファでの遅延時間を、タイマ満了時間以下となるようにしたので、パケットロス発生時は更に遅延を低減することができる。但し、タイマ満了時間を短くし過ぎると、パケット入れ替わりに対応できないケースも生じるので、注意が必要である。
【０１１３】
（Ｃ）他の実施形態
上述した第１及び第２の実施形態では、デコーダ及びエンコーダが複数ある場合を例示したが、１個の場合であってもよい。
【０１１４】
また、上述した第１及び第２の実施形態では、コーデック変換装置に、本発明のバッファ制御処理を適用する場合を説明したが、コーデック変換装置のバッファ制御処理に限定されるものでない。例えば、コーデック変換処理が無くても、ＲＴＰパケットを中継する通信装置が、受信パケットをバッファリングする制御処理に、本発明を適用することができる。
【０１１５】
上述した第１及び第２の実施形態では、パケットロス発生時に、パケットロス補償を行うようにしたが、パケットロス時のデコード／エンコード処理を省略し、パケットロス補償を受信側の端末に委ねるようにしても良い。
【符号の説明】
【０１１６】
１…セッションボーダーコントローラ、１４…コーデック変換装置、
２１…パケット受信部、２２…チャネル振分け制御部、
２３−１〜２３−ｎ…ソートバッファ、２４−１〜２４−ｎ…デコーダ、
２５−１〜２５−ｎ…エンコーダ、２６…パケット送信部、
２７…ソートバッファ制御部。
【特許請求の範囲】
【請求項１】
ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段と、
上記バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段と、
少なくとも、上記入力されたパケットのシーケンス番号に基づき、上記バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、データの上記バッファ手段への投入時又は上記バッファ手段からのデータ取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段と
を備えることを特徴とするバッファ制御装置。
【請求項２】
上記バッファ制御手段が、上記入力されたパケットのデータを、上記バッファ手段の取出し位置の先頭に投入する時、コーデック変換処理を実行すると判定するものであることを特徴とする請求項１に記載のバッファ制御装置。
【請求項３】
上記バッファ制御手段が、上記入力されたパケットのデータを、上記バッファ手段の取出し位置の最終位置に投入する時、コーデック変換処理を実行すると判定するものであることを特徴とする請求項１に記載のバッファ制御装置。
【請求項４】
上記バッファ制御手段が、上記バッファ手段の取出し位置の先頭からデータを取り出し、次に取り出すべきデータが残存するとき、コーデック変換処理を実行すると判定し、次に取り出すべきデータがないとき、コーデック変換処理を実行しないと判定するものであることを特徴とする請求項２に記載のバッファ制御装置。
【請求項５】
上記バッファ制御手段が、上記バッファ手段の取出し位置の先頭又は最終位置以外の位置にデータがある場合には、コーデック変換処理を実行させるためのタイマ処理を行うものであることを特徴とする請求項１〜４のいずれかに記載のバッファ制御装置。
【請求項６】
コンピュータを、
ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段、
上記バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段、
少なくとも、上記入力されたパケットのシーケンス番号に基づき、上記バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、上記パケットのデータの上記バッファ手段への投入時又は上記バッファ手段からの取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段
として機能させるものであることを特徴とするバッファ制御プログラム。
【請求項７】
それぞれ異なるネットワークに接続する通信装置において、
上記各ネットワークにおけるコーデックの相違を吸収する請求項１〜５のいずれかに記載のバッファ制御装置を有することを特徴とする通信装置。
【請求項１】
ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段と、
上記バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段と、
少なくとも、上記入力されたパケットのシーケンス番号に基づき、上記バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、データの上記バッファ手段への投入時又は上記バッファ手段からのデータ取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段と
を備えることを特徴とするバッファ制御装置。
【請求項２】
上記バッファ制御手段が、上記入力されたパケットのデータを、上記バッファ手段の取出し位置の先頭に投入する時、コーデック変換処理を実行すると判定するものであることを特徴とする請求項１に記載のバッファ制御装置。
【請求項３】
上記バッファ制御手段が、上記入力されたパケットのデータを、上記バッファ手段の取出し位置の最終位置に投入する時、コーデック変換処理を実行すると判定するものであることを特徴とする請求項１に記載のバッファ制御装置。
【請求項４】
上記バッファ制御手段が、上記バッファ手段の取出し位置の先頭からデータを取り出し、次に取り出すべきデータが残存するとき、コーデック変換処理を実行すると判定し、次に取り出すべきデータがないとき、コーデック変換処理を実行しないと判定するものであることを特徴とする請求項２に記載のバッファ制御装置。
【請求項５】
上記バッファ制御手段が、上記バッファ手段の取出し位置の先頭又は最終位置以外の位置にデータがある場合には、コーデック変換処理を実行させるためのタイマ処理を行うものであることを特徴とする請求項１〜４のいずれかに記載のバッファ制御装置。
【請求項６】
コンピュータを、
ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段、
上記バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段、
少なくとも、上記入力されたパケットのシーケンス番号に基づき、上記バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、上記パケットのデータの上記バッファ手段への投入時又は上記バッファ手段からの取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段
として機能させるものであることを特徴とするバッファ制御プログラム。
【請求項７】
それぞれ異なるネットワークに接続する通信装置において、
上記各ネットワークにおけるコーデックの相違を吸収する請求項１〜５のいずれかに記載のバッファ制御装置を有することを特徴とする通信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１３−７４４１９（Ｐ２０１３−７４４１９Ａ）
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１１−２１１２５２（Ｐ２０１１−２１１２５２）
【出願日】平成２３年９月２７日（２０１１．９．２７）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【出願人】（５９１０８９５５６）株式会社 沖情報システムズ (276)
【Ｆターム（参考）】
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２３年９月２７日（２０１１．９．２７）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【出願人】（５９１０８９５５６）株式会社 沖情報システムズ (276)
【Ｆターム（参考）】
[ Back to top ]