"ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段と、上記バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段と、少なくとも、上記入力されたパケットのシーケンス番号に基づき、上記バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、データの上記バッファ手段への投入時又は上記バッファ手段からのデータ取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段とを備えることを特徴とするバッファ制御装置。上記バッファ制御手段が、上記入力されたパケットのデータを、上記バッファ手段の取出し位置の先頭に投入する時、コーデック変換処理を実行すると判定するものであることを特徴とする請求項1に記載のバッファ制御装置。上記バッファ制御手段が、上記入力されたパケットのデータを、上記バッファ手段の取出し位置の最終位置に投入する時、コーデック変換処理を実行すると判定するものであることを特徴とする請求項1に記載のバッファ制御装置。上記バッファ制御手段が、上記バッファ手段の取出し位置の先頭からデータを取り出し、次に取り出すべきデータが残存するとき、コーデック変換処理を実行すると判定し、次に取り出すべきデータがないとき、コーデック変換処理を実行しないと判定するものであることを特徴とする請求項2に記載のバッファ制御装置。上記バッファ制御手段が、上記バッファ手段の取出し位置の先頭又は最終位置以外の位置にデータがある場合には、コーデック変換処理を実行させるためのタイマ処理を行うものであることを特徴とする請求項1~4のいずれかに記載のバッファ制御装置。コンピュータを、ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段、上記バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段、少なくとも、上記入力されたパケットのシーケンス番号に基づき、上記バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、上記パケットのデータの上記バッファ手段への投入時又は上記バッファ手段からの取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段として機能させるものであることを特徴とするバッファ制御プログラム。それぞれ異なるネットワークに接続する通信装置において、上記各ネットワークにおけるコーデックの相違を吸収する請求項1~5のいずれかに記載のバッファ制御装置を有することを特徴とする通信装置。上述したように、特許文献1に記載の技術は、コーデック変換処理遅延を小さくするため、コーデック変換装置が、パケットの順序入れ替えやパケットロス補償を実行しないというものである。しかしながら、エンドツーエンド端末でパケットの順序入れ替えやパケットロス補償を実行していたとしても、コーデック変換装置が、パケットの順序入れ替えやパケットロス補償を実行しないと、音質の劣化が生じることがあるという問題がある。図2は、コーデック変換装置において、パケットの順序入れ替わりが発生した場合に、音質が劣化するときの例を説明する説明図である。図2では、コーデック変換装置91が、AMRAdaptiveMultiRateからITU-TG.711にコーデック変換を行うものである。図2において、送信側の端末92は、原音を例えば20msで区切り、原音1、原音2,原音3,原音4を順次AMRでエンコードし、AMR1,AMR2,AMR3,AMR4を順次送出する。ここで、送信側の端末92からコーデック変換装置91へのネットワークにて、パケットの順序入れ替わりが発生し、コーデック変換装置91が、AMR2より先にAMR3を受信したとする。この場合、コーデック変換装置91のAMRデコーダ入力は、AMR1,AMR2,AMR3,AMR4の順番ではなく、AMR1,AMR3,AMR2,AMR4の順番でデコード処理を実行する。ここで、デコーダ入力の順序が入れ替ったことにより、デコーダ出力のLinear音声が原音と異なってしまい、音質が劣化するという問題が生ずる。これは、AMRなどの音声コーデックでは、過去の音声データより得られた情報も用いて、エンコード/デコード処理を実施しているからである。受信側の端末93において、パケットの順序入れ替わりを元に戻したとしても、劣化した音質を元通りにすることは出来ない。また、例えば特許文献2に記載のジッタバッファを用いることで、パケットの順序入れ替わりやパケットロスが発生しても、音質の劣化を低減することができる。しかし、ジッタバッファへの投入から取り出しまでの時間分だけ、コーデック変換処理に遅延が増加してしまうという問題が生じ得る。そのため、パケットの順序の入れ替わりやパケットロスなどが生じた場合に、できるだけ小さい遅延で、パケットの順序の入れ替えやパケットロス補償を実行して、音質の劣化を防止することができるバッファ制御装置、バッファ制御プログラム及び通信装置が求められている。かかる課題を解決するために、第1の本発明は、1ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段と、2バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段と、3少なくとも、入力されたパケットのシーケンス番号に基づき、バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、データのバッファ手段への投入時又はバッファ手段からのデータ取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段とを備えることを特徴とするバッファ制御装置である。第2の本発明は、コンピュータを、1ネットワークから入力されたパケットに含まれるデータを複数蓄積するバッファ手段、2バッファ手段から出力されたデータについてコーデック変換処理を行うコーデック変換手段、3少なくとも、入力されたパケットのシーケンス番号に基づき、バッファ手段においてシーケンス番号順となる位置に当該パケットのデータを格納させるものであって、パケットのデータのバッファ手段への投入時又はバッファ手段からの取出時に、コーデック変換処理を実行するか否かを決定するバッファ制御手段として機能させるものであることを特徴とするバッファ制御プログラムである。第3の本発明は、それぞれ異なるネットワークに接続する通信装置において、各ネットワークにおけるコーデックの相違を吸収する第1の本発明のバッファ制御装置を有することを特徴とする通信装置である。本発明によれば、パケットの順序の入れ替わりやパケットロスなどが生じた場合に、できるだけ小さい遅延で、パケットの順序の入れ替えやパケットロス補償を実行して、音質の劣化を防止することができる。A第1の実施形態以下では、本発明のバッファ制御装置、バッファ制御プログラム及び通信装置の第1の実施形態を、図面を参照しながら説明する。第1の実施形態では、事業者網の境界に設けられるセッションボーダーコントローラS/BCのコーデック変換装置に、本発明を適用する場合の実施形態を例示する。A-1第1の実施形態の構成図3は、第1の実施形態のセッションボーダーコントローラの概略内部構成イメージ的な構成を示すブロック図である。第1の実施形態のセッションボーダーコントローラ1は、異なる事業者網間の境界設けられる通信装置である。図3に示すように、セッションボーダーコントローラ1は、複数のインタフェース部11-1及び11-2、制御部12、スイッチ部13を有する。セッションボーダーコントローラ1は、例えば、文献ITU-TY.2012Supplementに規定されている、IPv4/v6変換NAT/NAPTピンホール制御、THIGトポロジーハイディング等の機能を実現するものである。また、セッションボーダーコントローラ1は、コーデック変換装置14を内蔵又は外付けで備えるものである。SIPサーバ2は、IP電話端末3-1及び3-2間の呼を制御する呼制御サーバである。SIPサーバ2は、SIPのセッションの確立処理の中で、通話しようとするIP電話端末3-1、3-2が適用しているコーデックIP電話端末3-1、3-2が収容されている事業者網の採用コーデックを認識する。そして、両IP電話端末3-1及び3-2のコーデックが異なる場合、SIPサーバ2は、コーデック変換開始指示をセッションボーダーコントローラ2に発行するものである。セッションボーダーコントローラ1において、制御部12は、コーデック変換開始指示が与えられると、インタフェース部11-1、11-2、スイッチ部13及びコーデック変換装置14を制御し、コーデック変換を実行できるようにする。制御部12は、一方のIP電話端末3-1からのパケットを、IP電話端末3-1を収容しているインタフェース部11-1及びスイッチ部13を介して、コーデック変換装置14に与える。そして、制御部12は、コーデック変換装置14を制御して、他方のIP電話端末3-2が適用しているコーデックに変換させ、コーデック変換装置14から出力されたパケットを、スイッチ部13、及び、IP電話端末3-2を収容しているインタフェース部11-2を介して、他方のIP電話端末3-2に送出できるように制御する。また、制御部12は、逆方向についても、コーデック変換を実行できるように制御する。コーデック変換が可能となったときに、制御部12は、SIPサーバ2に、コーデック変換開始OKを返信する。SIPサーバ2は、両電話端末3-1及び3-2に通話OKを通知する。これにより、通話が開始し、開始された通話に係るパケットは、コーデック変換装置14を介して対向するIP電話端末が適用しているコーデックのパケットに変換され、対向するIP電話端末に送出される。図1は、コーデック変換装置14の詳細な内部構成を示すブロック図である。図1において、コーデック変換装置14は、パケット受信部21、チャネル振分け制御部22、複数のソートバッファ23-1~23-nn:正の整数、それぞれ対をなす複数のデコーダ24-1~24-n及びエンコーダ25-1~25-n、パケット送信部26、ソートバッファ制御部27を有する。なお、コーデック変換装置14は、例えば、CPU、RAM、ROM、EEPROM、入出力インタフェース部等を有して構成される装置である。コーデック変換装置14の機能は、CPUが、ROMに格納されるコーデック変換プログラムやバッファ制御プログラム等の処理プログラムを実行することにより実現されるものである。なお、処理プログラムはネットワークを通じてインストールされるものであってもよく、その場合でも、図1に示す機能構成を有する。コーデック変換装置14は、ある事業者網の符号化方式のデータを、他の事業者網の符号化方式のデータに変換するものである。コーデック変換装置14は、例えば、ITU-TG.711、ITU-TG.722、EVRCEnhancedVariableRateCodec、AMR等の間で符号化方式の変換を行うことができる。例えば、コーデック変化装置14は、G.711→EVRC、G.711→AMR、G.711→G.722、EVRC→G.711、AMR→G.711、G.722→G.711のコーデック変換を行うことができる。なお、上記以外のコーデック変換として、コーデック変化装置14は、例えばEVRC→AMR等のようなコーデック変換を行うようにしてもよい。デコーダ24-NNは1~nは、入力された符号化音声データを復号して、原音に戻すものである。デコーダ24-Nは、原音の音声データを、対応するエンコーダ25-Nに与えるものである。エンコーダ25-Nは、原音の音声データを、自己について定まっている符号化方式コーデック方式に従って符号化し、符号化音声データをパケット送信部26に与えるものである。ここで、デコーダ24-Nとエンコーダ25-Nとは、対をなすものである。すなわち、デコーダ24-N及びエンコーダ25-Nの符号化方式の組み合わせによって、コーデック変換の内容が定まる。例えば、デコーダ24-1がG.711対応であり、エンコーダ25-1がEVRC対応であれば、この対は、G.711→EVRCへのコーデック変換に供するものである。例えば、デコーダ24-Nとエンコーダ25-Nとの対は、DSPディジタルシグナルプロセッサによって実現される。1個のDSPには、複数のチャネル例えば200チャネル程度用のデコーダ及びエンコーダの対が搭載されている。コーデック変換装置14は、このようなDSPを複数個設けられている。パケット受信部21は、入力されたパケットを受信し、その受信されたパケットをチャネル振分け制御部22に与えるものである。チャネル振分け制御部22は、パケット受信部21からのパケットのチャネルを識別し、チャネル別のソートバッファ23-1~23-nにパケットを与えるものである。チャネル振分け制御部22によるチャネル振分け方法は、例えば、特許文献1に記載の技術を用いて振り分けることができる。例えば、チャネル振分け制御部22は、デコーダ及びエンコーダの1対1の対を示す内部セッション番号を管理する内部セッション管理テーブルと、デコーダ及びエンコーダのコーデック変換種類と各コーデック変換を実行させるDSPとを対応付けたDSP管理テーブル等を有する。チャネル振分け制御部22は、IPパケットのRTPヘッダに含まれる情報例えば、送信先IPアドレス、送信先ポート番号、送信元IPアドレス等に基づいて、内部セッション番号テーブルから内部セッション番号を検索して、その検索した内部セッション番号に応じたデコーダ及びエンコーダの対に対応するソートバッファ23-1~23-nに振り分ける。パケット送信部26は、エンコーダ25-1~25-nにより符号化された符号化データを用いて送信パケットを形成し、その送信パケットを送出するものである。パケット送信部26によるパケットの形成方法は、種々の方法を適用することができるが、例えば、特許文献1に記載の方法を適用するようにしてもよい。例えば、チャネル振分け制御部22が、処理対象のデータに、デコーダ及びエンコーダの対を示す内部セッション番号を付与しておく。このとき、内部セッション管理テーブルには、内部セッション番号と、ヘッダ情報例えば、送信先MACアドレス、送信元MACアドレス、送信先IPアドレス、送信元IPアドレス、送信先ポート番号、送信元ポート番号とを対応付ける。そして、パケット送信部26が、符号化データに付与されている内部セッション番号に基づいて、対応するヘッダ情報を読み出し、このヘッダ情報を符号化データに付与してパケットを形成する方法を適用することができる。ソートバッファ23-1~23-nは、対応するデコーダ24-1~24-n及びエンコーダ25-1~25-nの前段に設けられており、投入されたパケットの取り出し順序を変更することができるバッファ手段である。ソートバッファ23-1~23-nは、ソートバッファ制御部27の制御により、チャネル振分け制御部22からのパケットの投入及び取り出しを行い、取り出したパケットを、対応するデコーダ24-1~24-nに与えるものである。ソートバッファ制御部27は、ソートバッファ23-1~23-nに投入されるパケットのバッファ制御を行うものである。なお、ソートバッファ制御部27によるバッファ制御処理については、動作の項で詳細に説明する。図4は、ソートバッファ制御部27のバッファ制御処理に係る変数を説明する説明図である。図5は、ソートバッファ制御処理を説明する説明図である。図4において、ソートバッファ制御部27は、バッファ制御処理に係る変数としてsortbufnum、RTPパケットのシーケンス番号を示すsn、受信したRTPパケットのシーケンス番号を示すsnrecv、ソートバッファに存在する最大シーケンス番号を示すsnbiggest、ソートバッファに入り得る最小シーケンス番号を示すsnmin、ソートバッファに入り得る最大シーケンス番号を示すsnmax、Transcodeを実施するか否かを示すtrsctlを用いる。sortbufnumは、各ソートバッファ23-NNは1~n内のバッファの個数である。sortbufnumは、1つのソートバッファ23-Nが受け入れることができるパケットデータの個数である。sortbufnumを設定することで、パケットデータの順序を入れ替えできる個数を設定することができる。つまり、sortbufnumを設定は、sortbufnum-2個のRTPパケットデータの入れ替えができる。例えば、sortbufnum=4に設定すると、sortbufnum-2=2個のRTPパケットデータの入れ替えができる。すなわち、この場合、2個のパケットデータの順序を元通りに並べ替えることができる。ソートバッファ制御部27は、受信したRTPパケットのシーケンス番号snに基づいて、ソートバッファ23-Nへの投入及び当該ソートバッファからの取り出し処理を制御する。ソートバッファ制御部27は、ソートバッファ23-Nにパケットデータを投入した時点で、図4に示した変数に基づいて、Transcodeを実施するかを判断し、Transcodeを実施する場合には、trsctlフラグをEnableとし、そうでない場合にはtrsctlフラグをDisableに設定する。つまり、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置の先頭位置又は最終位置に、パケットデータが投入されると、trsctlフラグをEnableとする。trsctlフラグがEnableとなったら、ソートバッファ制御部27は、直ちに、ソートバッファ23-Nからパケットデータを取り出す。これにより、ソートバッファ23-Nからのパケットデータは、デコーダ24-N及びエンコーダ25-Nに与えられるために、Transcodeを実行させることができる。また、ソートバッファ制御部27は、ソートバッファ23-Nからパケットデータを取り出す時点でも、継続してTranscodeを実施するかを判断し、上記と同様に、trsctlフラグをEnable又はDisableに設定する。すなわち、パケットデータを取り出した時点で、引き続き、有効なデータすなわち、正しく取り出すべきデータがあった場合には、ソートバッファ制御部27は、trsctlフラグをEnableのままとして、次のデータをソートバッファ23-Nから取り出し、デコード及びエンコード処理を実行させる。有効なデータが無い場合、ソートバッファ制御部27は、trsctlフラグをDisableに設定する。また、ソートバッファ制御部27は、受信したRTPパケットデータのシーケンス番号がsnrecv<snminである場合、ソートバッファ制御部27は、受信したパケットデータを廃棄する。また、snrecv<snmaxである場合、ソートバッファ制御部27は、すきまを空けずパケットデータを投入する。A-2第1の実施形態の動作第1の実施形態のセッションボーダーコントローラ1の動作説明は省略する。以下では、第1の実施形態のコーデック変化装置14におけるバッファ制御処理の動作を、図面を参照しながら詳細に説明する。なお、以下では、各ソートバッファ23-Nのsortbufnumが4に設定されている場合を例示する。図6は、ソートバッファ制御部27による通常の投入動作を説明する説明図である。図7は、ソートバッファ制御部27による通常の取出動作を説明する説明図である。図6Aにおいて、ソートバッファ23-Nに入り得る最小シーケンス番号がsnmin=12であるとする。このとき、ソートバッファ23-Nには、パケットデータが存在していないので、snbiggest=-なしである。また、sortbufnum=4であるから、ソートバッファ23-Nは4個のパケットデータを受け入れることができるので、ソートバッファ23-Nに入り得る最大シーケンス番号はsnmax=15である。さらに、有効なデータがないので、ソートバッファ制御部27は、trsctlフラグをDisableに設定する。この状態で、シーケンス番号sn=12のRTPパケットデータが、シーケンス番号の順序通り受信されると、ソートバッファ制御部27は、受信されたRTPパケットのシーケンス番号に基づいてsnrecv=12に設定する図6A参照。そして、snmin=12であるから、ソートバッファ制御部27は、当該受信されたパケットデータをソートバッファ23-Nの先頭の取出し位置に投入し、trsctlフラグをEnableに設定する。また、sn=12のパケットデータが投入されたので、ソートバッファ制御部27はsnbiggest=12に設定する。図7Aにおいて、上記の状態で、trsctlフラグがEnableであるから、ソートバッファ制御部27は、直ちに、ソートバッファ23-Nの先頭取出し位置にある、sn=12パケットデータを取り出し、デコーダ24-Nに与える。このとき、図7Bに示すように、ソートバッファ制御部27は、snmin=13、snmax=16、snbiggest=-に更新すると共に、trsctlフラグをDisableに書き換える。次に、図8及び図9を用いて、パケット順序が入れ替って、パケットデータがソートバッファに投入されたときの投入動作及び取り出し動作を説明する。図8は、順序が入れ替わって投入されたときのソートバッファ制御部27による投入動作を説明する説明図である。図9は、順序が入れ替わって投入されたときのソートバッファ制御部27による取出動作を説明する説明図である。以下では、シーケンス番号sn=12のRTPパケットデータの前に、sn=13のRTPパケットデータが受信された場合の動作を例示する。図8Aの状態は、図6Aの状態と同じである。この状態で、sn=13のRTPパケットデータが受信されると、ソートバッファ制御部27は、受信されたRTPパケットのシーケンス番号に基づいてsnrecv=13に設定する図8A参照。このとき、snmin=12であるから、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置から2番目の位置に、当該受信されたパケットデータを投入する。trsctlフラグはDisableのままとする。また、ソートバッファ制御部27はsnbiggest=13に更新する図8B参照。引き続き、シーケンス番号sn=12のRTPパケットが受信されると、ソートバッファ制御部27は、受信されたRTPパケットのシーケンス番号に基づいてsnrecv=12に設定する図8C参照。そして、snmin=12であるから、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置の先頭の位置に、当該受信されたパケットデータを投入する。また、ソートバッファ制御部27は、trsctlフラグをEnableに設定する。図9Aにおいて、上記状態において、trsctlフラグがEnableであるから、ソートバッファ制御部27は、直ちに、ソートバッファ23-Nの先頭取出し位置にある、sn=12パケットデータを取り出し、デコーダ24-Nに与える図9B参照。このとき、ソートバッファ制御部27は、snmin=13、snmax=16に更新する。また、次に、取り出すべきsn=13のパケットデータがあるので、trsctlフラグはEnableのままである。そして、引き続き、trsctlフラグがEnableであるから、ソートバッファ制御部27は、直ちに、ソートバッファ23-Nの先頭取出し位置にある、sn=13パケットデータを取り出す。このとき、ソートバッファ制御部27は、snmin=14、snmax=17に更新すると共に、trsctlフラグをDisableに書き換える。次に、図10及び図11を用いて、パケットロス発生時のソートバッファ23-Nへの投入動作及び取出動作を説明する。図10は、パケットロス発生時のソートバッファ制御部27による投入動作を説明する説明図である。図11は、パケットロス発生時のソートバッファ制御部27による取出動作を説明する説明図である。以下では、送信側端末からコーデック変換装置14までのネットワーク上で、シーケンス番号sn=12のRTPパケットが失われた場合の動作を例示する。図10Aの状態は、図6Aの状態と同じである。この状態で、シーケンス番号sn=13のRTPパケットが受信されたものとする。ソートバッファ制御部27は、受信されたRTPパケットのシーケンス番号に基づいてsnrecv=13に設定する図10A参照。このとき、snmin=12であるから、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置から2番目の位置に、当該受信されたパケットデータを投入する。trsctlフラグはDisableのままとする。また、ソートバッファ制御部27はsnbiggest=13に更新する図10B参照。引き続き、シーケンス番号sn=14のRTPパケットが受信される。ソートバッファ制御部27は、受信されたRTPパケットのシーケンス番号に基づいてsnrecv=14に設定する図10B参照。このとき、snmin=12であるから、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置から3番目の位置に、当該受信されたパケットデータを投入する。trsctlフラグはDisableのままとする図10B参照。また、ソートバッファ制御部27はsnbiggest=14に更新する図10C参照。次に、引き続き、シーケンス番号sn=15のRTPパケットが受信される。ソートバッファ制御部27は、受信されたRTPパケットのシーケンス番号に基づいてsnrecv=15に設定する図10C参照。このとき、snmin=12であるから、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置から4番目の位置に、当該受信されたパケットデータを投入する。ここで、ソートバッファの取出位置の最後の位置にパケットデータが投入されたので、ソートバッファ制御部27は、trsctlフラグをEnableに書き換え、snbiggest=15に更新する図10D参照。図11Aにおいて、上記の状態で、trsctlフラグがEnableであるから、ソートバッファ制御部27は、直ちに、ソートバッファ23-Nからの取出し処理を行う。このとき、ソートバッファ23-Nの先頭取出し位置にあるのは、emptyデータ無しであるから、デコーダ24-Nは、パケットロス補償を実行し、エンコード処理も実行する図11B参照。また、このとき、ソートバッファ制御部27は、sn_min=13に更新をする図11B参照。そして、引き続き、trsctlフラグがEnableであるから、ソートバッファ制御部27は、直ちに、ソートバッファ23-Nの先頭取出し位置にある、sn=13パケットデータを取り出す図11C参照。このとき、ソートバッファ制御部27は、sn_min=14及びsn_max=17に更新をする図11C参照。引き続き、trsctlフラグがEnableであるから、ソートバッファ制御部27は、直ちに、ソートバッファ23-Nの先頭取出し位置にある、sn=14のパケットデータを取り出す。ソートバッファ制御部27は、sn_min=15及びsn_max=18に更新をする図11C参照。さらに、引き続き、trsctlフラグがEnableであるから、ソートバッファ制御部27は、直ちに、ソートバッファ23-Nの先頭取出し位置にある、sn=15のパケットデータを取り出す。ソートバッファ制御部27は、sn_min=16、sn_max=19及びsn_biggest=-に更新をすると共に、trsctlフラグがDisableに書き換える図11D参照。A-3第1の実施形態の効果以上のように、第1の実施形態によれば、ソートバッファ制御部は、パケット受信した時点で、ソートバッファにパケットデータを投入し、Transcodeを実施するかを判断する。そして、Transcodeの実施可能な条件となれば、直ちにデータを取出し、エンコードおよびデコード処理を実行するようにしたので、パケットの順序入れ替わりやパケットロスが発生しても、必要最小限の遅延で、パケットの順序入れ替えやパケットロス補償を実行し、音質の劣化を防止することができる。B第2の実施形態次に、本発明の本発明のバッファ制御装置、バッファ制御プログラム及び通信装置の第2の実施形態を、図面を参照しながら説明する。B-1第2の実施形態の構成第2の実施形態が、第1の実施形態と異なる点は、ソートバッファ制御部が、タイマ処理を行う点である。それ以外の第2の実施形態の構成及び動作は、第1の実施形態の構成及び動作と同じであるので、第2の実施形態でも、図1及び図3を用いながら、第2の実施形態の特徴的な構成及び動作を中心に説明する。第2の実施形態のソートバッファ制御部27は、タイマ処理機能を有する。ソートバッファ制御部27は、パケットデータがソートバッファ23-Nの取出し位置の先頭又は最終位置以外に投入されると、所定のタイマ時間を計時するものである。また、ソートバッファ制御部27は、タイマ時間が満了になると、trsctlフラグをEnableに書き換えるものである。なお、タイマ時間が満了する前に、次のパケットが受信された場合、ソートバッファ制御部27はタイマをリセットする。B-2第2の実施形態の動作図12は、第2の実施形態のソートバッファ制御部27のバッファ制御処理を説明する説明図である。図12Aの状態は、図6Aの状態と同じである。この状態で、シーケンス番号sn=13のRTPパケットが受信されたものとする。ソートバッファ制御部27は、受信されたRTPパケットのシーケンス番号に基づいてsnrecv=13に設定する図12A参照。このとき、snmin=12であるから、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置から2番目の位置に、当該受信されたパケットデータを投入する。ここで、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置の先頭又は最終位置以外に、パケットデータが投入されたので、タイマを起動する。タイマ時間は、特に限定されるものではないが、例えば20msとする。なお、ソートバッファ制御部27は、trsctlフラグはDisableのままとする。また、ソートバッファ制御部27はsnbiggest=13に更新する図12B参照。その後、タイマを起動してから、次に到着すべきRTPパケットが受信しないものとする。タイマ時間が満了すると、図12Cに示すように、ソートバッファ制御部27は、trsctlフラグをEnableに書き換えを行う。このとき、図12Dに示すように、ソートバッファ23-Nの取出し位置の先頭位置はEmptyデータ無しであるから、ソートバッファ制御部27は、Emptyを取り出し、対応するデコーダ24-Nによるパケットロス補償を行い、エンコード処理を行う。次に、図12Eに示すように、ソートバッファ制御部27は、ソートバッファ23-Nの取出し位置の先頭位置にある、シーケンス番号sn=13のパケットデータを取り出すようにする。そして、ソートバッファ制御部27は、trsctlフラグをDisableに書き換え、又内部の変数の更新も行う。B-3第2の実施形態の効果以上のように、第2の実施形態によれば、第1の実施形態の効果に加えて、パケットロス発生時のソートバッファでの遅延時間を、タイマ満了時間以下となるようにしたので、パケットロス発生時は更に遅延を低減することができる。但し、タイマ満了時間を短くし過ぎると、パケット入れ替わりに対応できないケースも生じるので、注意が必要である。C他の実施形態上述した第1及び第2の実施形態では、デコーダ及びエンコーダが複数ある場合を例示したが、1個の場合であってもよい。また、上述した第1及び第2の実施形態では、コーデック変換装置に、本発明のバッファ制御処理を適用する場合を説明したが、コーデック変換装置のバッファ制御処理に限定されるものでない。例えば、コーデック変換処理が無くても、RTPパケットを中継する通信装置が、受信パケットをバッファリングする制御処理に、本発明を適用することができる。上述した第1及び第2の実施形態では、パケットロス発生時に、パケットロス補償を行うようにしたが、パケットロス時のデコード/エンコード処理を省略し、パケットロス補償を受信側の端末に委ねるようにしても良い。"