(57)【特許請求の範囲】
【請求項１】
着信メディアを復号するデコーダと復号されたメディアを再生する再生器とを有する受信機において、進行中のＶｏＩＰ通信セッション中のメディア歪みを軽減する方法であって、
‐第１のエンコーダからの着信メディアを受信するステップと、
‐前記着信メディアが第２のエンコーダに起因して変更されることを検出するステップと、
‐前記第１のエンコーダからの前記着信メディアを復号するために用いられたデコーダによって新たな着信メディアを復号する前に、前記検出された変更に応じて前記デコーダのデコーダ状態をその初期状態にリセットするステップと
を備えることを特徴とする方法。
【請求項２】
前記変更を検出するステップは、前記第２のエンコーダからのメディアが前記通信セッションに挿入されたことを検出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記変更を検出するステップは、前記第１のエンコーダから前記第２のエンコーダへの切り替えを検出するステップを含み、前記新たな着信メディアは前記第２のエンコーダからのメディアを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記第１のエンコーダから前記第２のエンコーダへの前記切り替えは、遠隔ユーザからのユーザ・メディアとアナウンス・サーバからのアナウンス・メディアとの間の切り替えを含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記変更を検出するステップは、混合メディア・ストリームの寄与エンコーダの変更を検出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記変更を検出するステップは、着信メディア・データ内の複数のパケット間のパケット・ヘッダ・フィールドの変更を検出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記変更を検出するステップは、通話保留状態の変更を検出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記変更を検出するステップは、着信メディア・データ内の複数のパケット間のメディア・エンコーディングの変更を検出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項９】
‐前記受信機内の前記デコーダに関連して提供されるジッタ・バッファに記憶された前記第１のエンコーダからの既存のメディアをすべて再生するステップと、
‐前記ジッタ・バッファを再初期化するステップと、
‐第２のエンコーダからのメディアを前記ジッタ・バッファにバッファリングするステップとをさらに備え、
前記デコーダ状態がリセットされた時点で前記バッファリングされたメディアの復号の準備が整うことを特徴とする請求項１に記載の方法。
【請求項１０】
前記第１のエンコーダからの前記既存のメディアはフェードアウトを用いてすべて再生され、前記第２のエンコーダからの前記メディアはフェードインを用いてすべて再生されることを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１のエンコーダからのメディアと前記第２のエンコーダからのメディアとの間の滑らかな移行を実現するための移行手順を適用するステップをさらに備えることを特徴とする請求項９に記載の方法。
【請求項１２】
着信メディアを復号するデコーダと復号されたメディアを再生する再生器とを有する受信機において、進行中のＶｏＩＰ通信セッション中のメディア歪みを軽減するシステムであって、
‐第１のエンコーダからの着信メディアを受信する手段と、
‐前記着信メディアが第２のエンコーダに起因して変更されることを検出する手段と、
‐前記第１のエンコーダからの前記着信メディアを復号するために用いられたデコーダによって新たな着信メディアを復号する前に、前記検出された変更に応じて前記デコーダのデコーダ状態をその初期状態にリセットする手段と
を備えることを特徴とするシステム。
【請求項１３】
前記変更を検出する手段は、前記第２のエンコーダからのメディアが前記通信セッションに挿入されたことを検出する手段を含むことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記変更を検出する手段は、前記第１のエンコーダから前記第２のエンコーダへの切り替えを検出する手段を含み、前記新たな着信メディアは前記第２のエンコーダからのメディアを含むことを特徴とする請求項１２に記載のシステム。
【請求項１５】
前記第１のエンコーダから前記第２のエンコーダへの前記切り替えは、遠隔ユーザからのユーザ・メディアとアナウンス・サーバからのアナウンス・メディアとの間の切り替えを含むことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記変更を検出する手段は、混合メディア・ストリームの寄与エンコーダの変更を検出する手段を含むことを特徴とする請求項１２に記載のシステム。
【請求項１７】
前記変更を検出する手段は、着信メディア・データ内の複数のパケット間のパケット・ヘッダ・フィールドの変更を検出する手段を含むことを特徴とする請求項１２に記載のシステム。
【請求項１８】
前記変更を検出する手段は、着信メディア・データ内の複数のパケット間のメディア・エンコーディングの変更を検出する手段を含むことを特徴とする請求項１２に記載のシステム。
【請求項１９】
‐着信メディアを記憶するために前記デコーダに関連して提供されるジッタ・バッファであって、前記ジッタ・バッファにすでに記憶されている前記第１のエンコーダからの既存のメディアをすべて再生するように前記再生器が動作可能である、ジッタバッファと、
‐前記ジッタ・バッファを再初期化する手段と、
‐前記第２のエンコーダからのメディアを前記ジッタ・バッファにバッファリングする手段とをさらに備え、
前記デコーダ状態がリセットされた時点で前記バッファリングされたメディアの復号の準備が整うことを特徴とする請求項１２に記載のシステム。
【請求項２０】
前記再生器は、フェードアウトを用いて前記既存のメディアをすべて再生するように動作可能であり、フェードインを用いて前記第２のエンコーダからの前記メディアをすべて再生するように動作可能であることを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記システムは前記受信機内に実装されることを特徴とする請求項１２に記載のシステム。
【請求項２２】
進行中のＶｏＩＰ通信セッション中に着信メディアを復号するデコーダを有する受信機であって、
第１のエンコーダから着信メディアを受信し、第２のエンコーダに起因する前記デコーダで起こり得る状態不一致を検出し、前記状態不一致を避けるため、又は少なくとも歪みを軽減するために、検出された起こり得る状態不一致に応じて、前記第１のエンコーダからの前記着信メディアを復号するために用いられたデコーダによって前記第２のエンコーダからのメディアを復号する前に前記デコーダのデコーダ状態をその初期状態にリセットするように構成されたことを特徴とする受信機。
【請求項２３】
前記着信メディアが前記第２のエンコーダに起因して変更されることを検出することによって、前記デコーダ内で起こり得る状態不一致を検出するように構成されたことを特徴とする請求項２２に記載の受信機。
【請求項２４】
着信メディア・データ内の複数のパケット間のメディア・エンコーディングの変更を検出することによって、前記デコーダ内で起こり得る状態不一致を検出するように構成されたことを特徴とする請求項２２に記載の受信機。
【請求項２５】
着信メディアを復号するデコーダと復号されたメディアを再生する再生器とを有する受信機におけるメディア歪みを軽減する方法であって、
‐第１のエンコーダからのメディアの受信を伴う進行中のＶｏＩＰ通信セッション中に、第２のエンコーダからのメディアの後続する受信に備えて所定の信号パターンを受信するステップと、
‐前記第１のエンコーダからの前記着信メディアを復号するために用いられたデコーダによって前記第２のエンコーダからのメディアを復号する前に、前記所定の信号パターンに応じて前記デコーダのデコーダ状態をその初期状態にリセットするステップと
を備えることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に通信環境におけるメディア技術に関し、より具体的には効率的なメディアの扱いのための受信機側の動作と実装との少なくとも何れかに関する。
【背景技術】
【０００２】
最新の通信システムは、音声、オーディオ、ビデオ、テキスト、及び画像を含む、ユーザ間の幅広い種類のメディアの交換をサポートする。いわゆるマルチメディア・システムのほとんどはインターネット・プロトコル（ＩＰ）技術に基づいている。このようなＩＰベースのシステムの特定の例はＩＰマルチメディア・サブシステム（ＩＭＳ）（非特許文献１）であり、これにより、進歩したマルチメディア・サービス及びコンテンツをブロードバンド・ネットワークを通じて供給することが可能となる。例えば、リアルタイムのユーザ間マルティメディア・テレフォニー（ＭＭＴｅｌ）・サービス（非特許文献２）は様々なマルチメディア・サービスのニーズを満足させるために重要な役割を果たすだろう。
【０００３】
例えば、ＩＭＳマルチメディア・テレフォニー（ＭＭＴｅｌ）のような最新の通信システムにおいて付加サービス（ｓｕｐｐｌｅｍｅｎｔａｒｙ  ｓｅｒｖｉｃｅ）が重要な役割を果たすだろうし、このようなシステムがメディア歪み（ｍｅｄｉａ  ｄｉｓｔｏｒｔｉｏｎ）のような性能劣化を生じさせることなく従来システムで見られるのと同一の又は少なくとも類似する付加サービスをサポートすることが重要である。付加サービスの例として、発呼線識別表示、通話保留、会議、及びアナウンス（ａｎｎｏｕｎｃｅｍｅｎｔ）がある。例えば、アナウンスは、通信ネットワークによって生成されてもよく、遠隔ユーザの交換台又はコンピュータによって生成されてもよい。
【０００４】
通信ネットワークからのアナウンスの使用例は以下を含む。
・ユーザが開始したコマンドを完了できない場合のエラー・メッセージ。例えば、発呼者が電話番号の提示を抑制したが、被呼者が電話番号を見ないで呼に応答することはしないと規定している場合に、システムは発呼者にエラー・メッセージを提示しなければならない。
・ユーザＡがセッションを保留にした場合に、システムはこれに関するメッセージをユーザＢに再生してもよい。
・会議通話において、会議サーバは、新たなユーザが参加した場合に又はユーザがセッションから離れた場合に、例えば「ジョン・スミスが会議に参加しました」及び「ジョン・スミスが会議から離れました」というアナウンスを提示してもよい。
・ユーザは、なくなりかけているプリペイド加入契約を有している。オペレータは少量であることに起因して使用を制限でき、セッションの開始時又は（とても長いセッションの場合にありうるだろうが）セッションの間に、このことをアナウンスすることを望む。
・インターネットでますます用いられている方法は、ウェブ・ページにピンコード（又はパスワード）を有する画像を提示することである。ピンコードの画像は歪んでいるので、自動テキスト認識システムはピンコードを検出できないが、賢い人間が文字及び数字を読みことはなおも可能である。これは、対応するピンコードを（セキュアでない）電子メールで送信するかわりに用いられる。
【０００５】
被呼者からのアナウンスの使用例は以下である。
・ユーザはチケットの予約をするために旅行代理店に電話する。以下のシナリオが起こり得る。
１．ユーザは最良の旅行オプションを見つけるために旅行代理人と会話する。このステップでは、二人の人間の間で議論される。
２．旅行を決定した後に、ユーザは自分のクレジット・カード番号を入力することを要求される。これは、事前に録音されたメッセージ又は機械が生成するメッセージをユーザが聞いて、自分の番号を入力するために電話のボタン（０−９）を押すマン−マシン通信である。この処理において、以下の文が考えられる。「あなたのクレジット・カード番号を入力してください。」「あなたの入力は、１２３４  ５６７８  ９０１２  ３４５６です。正しい場合は１を、そうでない場合は２を押してください。」「あなたのクレジット・カードの有効期限を入力してください。」「あなたの入力は、２００７年１月１日です。」これらの文はアナウンス・サーバによって生成されるだろう。
３．クレジット・カード番号及びその他の要求されたデータを入力した後に、追加の旅行オプションを決定するために、旅行代理人とのセッションが継続する。
４．これらのステップは複数回繰り返されてもよい。
【０００６】
従来の通信システムと比較して、メディアを扱う状況及び要件は最新のマルチメディア通信システムにおいて劇的に変化しているだろうし、よって、このような通信システムにおいてメディアを効率的に扱うためのソリューションを提供する一般的なニーズがある。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】３ＧＰＰ  ＴＳ  ２３．２２８「ＩＰマルチメディア・サブシステム（ＩＭＳ）、ステージ２」
【非特許文献２】３ＧＰＰ  ＴＳ  ２６．１１４「ＩＰマルチメディア・サブシステム（ＩＭＳ）；マルチメディア・テレフォニー；メディアの扱い及びインタラクション」
【非特許文献３】ＲＦＣ３５５０「ＲＴＰ：リアルタイム・アプリケーションのためのトランスポート・プロトコル」Ｈ．シュルズリン、Ｓ．キャスナー、Ｒ．フレデリック、及びＶ．ヤコブソン
【非特許文献４】ＩＴＵ−Ｔ勧告Ｇ．７１１「音声周波数のパルス符号変調（ＰＣＭ）」
【非特許文献５】ＩＴＵ−Ｔ勧告Ｇ．７２６「４０，３２，２４，１６ｋｂｉｔ／ｓ適応差分パルス符号変調（ＡＤＰＣＭ）」
【非特許文献６】３ＧＰＰ  ＴＳ  ２６．０７１「必須音声コーデック音声処理機能；ＡＭＲ音声コーデック；概要」
【非特許文献７】３ＧＰＰ  ＴＳ  ２６．１７１「音声コーデック音声処理機能；ＡＭＲ音声コーデック；適合マルチレート−広帯域（ＡＭＲ−ＷＢ）音声コーデック；概要」
【非特許文献８】オープン・モバイル・アライアンス「ＰｏＣユーザ・プレーン」候補バージョン１．０、２００６年１月２７日、６．５章
【非特許文献９】オープン・モバイル・アライアンス「ＯＭＡ  ＰｏＣシステム説明」ドラフト・バージョン２．０、２００６年６月２１日
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、先行技術の装置のこれらの欠点及びその他の欠点を克服する。
【０００９】
本発明の一般的な目的は、（マルチメディア）通信システムにおけるメディアの扱いを改良することである。
【００１０】
特に、受信機側のメディア歪みを排除又は軽減しつつ、極めてコスト効率の高い方法で付加サービスをサポートすることが望ましい。
【００１１】
個別の目的は、受信メディア・ストリームを復号するデコーダを備える受信機におけるメディア歪みを軽減するための改良された方法及び装置を提供することである。
【００１２】
別の個別の目的は、（マルチメディア）通信システムで用いられる改良された受信機を提供することである。
【課題を解決するための手段】
【００１３】
これらの目的及びその他の目的は添付の特許請求の範囲で規定される発明によって達成される。
【００１４】
通信セッション中に異なるエンコーダ・インスタンスを用いることは、受信機側のデコーダにおける状態不一致（ｓｔａｔｅ  ｍｉｓｍａｔｃｈ）を引き起こし、その結果、エンドユーザを不快にさせるかもしれない歪みが生じるかもしれないことが発明者により認識されていた。例えば、これが生じるのは、新たなメディア送信元からのメディアが通信セッションに挿入された場合、例えば、一つのメディア送信元から別のメディア送信元に切り替わった場合又は新たな送信元からのメディアが既存のメディア・ストリームに追加された場合である。
【００１５】
従って、本発明の基本的な考えは、進行中の通信セッション中に着信メディアの送信元の変更を検出し、新たな着信メディアを復号する前に、このような検出された変更に応じてデコーダのデコーダ状態をリセットすることである。このようにして、受信機内に複数のアクティブなデコーダ・インスタンスを必要とすることなく状態不一致を回避することができ、全体的な複雑さ、メモリ使用量、及び電力消費量の観点で大幅な節減につながる。これはまた、復号されたメディアが最終的にレンダリングされる場合に、メディア歪みを排除でき、又は少なくとも軽減することができることを意味する。
【００１６】
場合によっては、検出メカニズムは、例えば一つのメディア送信元から別のメディア送信元に切り替わった場合又は新たな送信元からのメディアが既存のメディア・ストリームに追加された場合に、新たなメディア送信元からのメディアが通信セッションに挿入されたことを検出するように構成される。しかしながら、一般に、送信元の変更は、送信元間の切り替え、送信元の追加、及び送信元の削除の少なくとも何れかであり得る。
【００１７】
言い換えると、受信機は、進行中の通信セッション中にデコーダで起こり得る状態不一致を検出し、検出された起こり得る状態不一致に応じてデコーダをリセットすることによって状態不一致を回避するように構成される。
【００１８】
本発明の密接に関連する形態では、送信側は、所定の信号パターンを送信することによって、新たな送信元からのメディアに備えて受信側でデコーダのリセットを実施する。受信側では、これは、第１のメディア送信元からのメディアの受信をもたらす進行中の通信セッションの間に、受信機が、異なる第２のメディア送信元からのメディアの後続する受信に備えて所定の信号パターンを受信するだろうことを意味する。その後に、デコーダは、第２のメディア送信元からのメディアの復号を開始する前に、所定の信号パターンに応じてリセットされるだろう。
【００１９】
本発明は特に、アナウンス、通話保留、及び会議サービスのような付加サービスのための最新の通信システムに適用可能である。
【００２０】
本発明により提供されるその他の利点は以下の本発明の実施形態の説明を読む場合に理解されるだろう。
【００２１】
本発明は、その更なる目的及び利点とともに、添付の図面と一緒に以下の明細書を参照することによって最もよく理解されるだろう。
【図面の簡単な説明】
【００２２】
【図１】異なるメディア送信元間の切り替えの基本的な例を説明する概略図である。
【図２】混合メディア・ストリームの寄与送信元の追加／削除の基本的な例を説明する概略図である。
【図３】エンコーダ状態はリセットされるがデコーダ状態はリセットされない場合の歪みを説明する概略図である。
【図４】デコーダ状態はリセットされるがエンコーダ状態はリセットされない場合の歪みを説明する概略図である。
【図５】本発明の例示的な実施形態に係る基本的な方法の概略フロー図である。
【図６】本発明の例示的な実施形態に係る受信機を主に説明する概略ブロック図である。
【図７】本発明の別の例示的な実施形態に係る方法の概略フロー図である。
【図８】本発明の更なる例示的な実施形態に係る受信機を主に説明する概略ブロック図である。
【図９】本発明のさらに別の例示的な実施形態に係る方法の概略フロー図である。
【発明を実施するための形態】
【００２３】
すべての図面を通じて、対応する要素又は類似する要素のために同じ参照文字が用いられる。
【００２４】
発明者の注意深い分析により、既存のソリューションが一つ以上の問題を抱えることが明らかになった。特に、エンコーダの異なるインスタンスによってメディアが符号化される一方で同じデコーダが用いられることによって、デコーダにおいて通常は状態不一致が生じ、その結果、復号されたメディアがレンダリングされる際に顕著な歪みが生じることが認識されてきた。
【００２５】
主な問題は、エンコーダの異なるインスタンスでメディアが符号化されるがデコーダは同一であることである。同一のデコーダを用いる理由は、複雑さを制限することと、メモリを制限することと、電力消費との少なくとも何れかのためである。図１に説明される例では、１種類のメディアがＡで表される送信機／エンコーダ１０で生成され、このメディアが、Ｂで表される受信機／デコーダ２０に、例えばＶｏＩＰセッションで送信されることを考える。セッション中に、Ａである送信機／エンコーダ１０からのメディアは、Ｘで表される送信機／エンコーダ３０により符号化されたメディアによって置き換えられる。つまり、Ａで生成されたメディアがＢに送信され、その後にＸからのメディアによって少なくとも一時的に置き換えられる。
【００２６】
図２に説明されるように、Ａで表される送信機／エンコーダ１０とＢで表される受信機／デコーダ２０との間の通信セッションにおいて、Ｘで表される送信機／エンコーダ３０からのメディアが中間のミキサ４０により新たな寄与送信元として混合メディア・ストームに追加される場合に、同様の問題を生じるかもしれない。リアルタイム・トランスポート・プロトコル（ＲＴＰ）（非特許文献３）に基づくメディア通信の特定の例では、メディア・ストリーム通信にとって特に重要であるＲＴＰデータパケットのヘッダ内の二つのフィールド、つまりＳＳＲＣフィールドとＣＳＲＣフィールドとがある。ＳＳＲＣは同期送信元を意味し、個別のＲＴＰ送信機を識別する。ＣＳＲＣは寄与送信元又はコンテンツ送信元を意味し、混合メディアのペイロードの寄与送信元（群）を識別する。複数の寄与送信元がある場合に、ペイロードはこれらの送信元からの混合データである。図２を参照すると、メディア送信元Ａ及びメディア送信元Ｘのそれぞれは、ペイロード送信元に対応するＳＳＲＣで個別のメディア・ストリームをミキサ４０に送信してもよいことが見て取れる。ミキサ４０からの混合メディア・ストリームはミキサに対応するＳＳＲＣを有し、ＣＳＲＣ値はＢへの混合メディア・ストリームの寄与送信元Ａ及び寄与送信元Ｘを識別する。例えば、寄与送信元はもちろん混合メディア・ストリームから除去されてもよい。
【００２７】
ミキサ（又はアプリケーション・サーバ）が送信元の一つを外してもう一方の送信元を受信機に単に転送することも可能である。別の可能性として、両方のストリームが受信機への経路全体を通り、受信機が聞き手に提示するために一つを選択しなければならない。
【００２８】
エンコーダ・インスタンスの切り替えは今日の既存の回線交換システムで動作するが、これは、使用されるコーデックが典型的なＰＣＭ（非特許文献４）又はＡＤＰＣＭ（非特許文献５）であるためにうまく動作する。これらのコーデックは、予測（ＰＣＭ）を使用しないか、非常に限られた量の予測（ＡＤＰＣＭ）しか使用しないかのいずれかであるサンプル単位のコーデックである。これは、デコーダが状態不一致から非常に速く回復するだろうし、これにより聞き取り可能な又はその他の知覚可能な歪みが生じる可能性が低いことを意味する。
【００２９】
予測及び状態にもっと依存するコーデック、例えばＡＭＲ（非特許文献６）又はＡＭＲ−ＷＢ（非特許文献７）を使用するであろう場合に、二つのエンコーダ間の切り替えはデコーダにおける状態不一致を生じさせるだろう。例えば、エンコーダＡからの音声メディアから、エンコーダＸからのメディアに切り替える場合に、デコーダ状態は切り替えの瞬間においてエンコーダＡと同じである一方で、エンコーダＸの状態は初期状態から始まるだろう。エンコーダＡからのメディアに戻されるように切り替えが行われる場合に同様の状態不一致が生じるだろう。
【００３０】
ＡＭＲのようなマルチレートのコーデックに伴う更なる問題は、エンコーダＡからの音声は、低レートのコーデック・モード、例えばＡＭＲの５．９ｋｂｐｓで符号化されることは十分にありえる一方で、エンコーダＸからのメディアは、高レートのコーデック・モード、例えばＡＭＲの１２．２ｋｂｐｓで符号化されることは十分にありえることである。この場合、状態不一致が生じるだけでなく、コーデック・モードの不一致も生じる。別の例では、コーデックの不一致を表すコーデック間の切り替え、例えばＡＭＲとＥＶＲＣとの間、又はＡＭＲとＡＭＲ−ＷＢとの間の切り替えを伴う。
【００３１】
良好な音声品質をなおも提供しつつ良好な圧縮比を達成するために状態が必要となるため、最新の低レート音声コーデックでは状態は非常に重要である。状態不一致は、現在のコンテンツに依存して多かれ少なかれ聞き取り可能な歪みを生じ得る。従って、品質への影響を軽減するために、メディアを適切に扱うことが重要となる。特に、最新の予測ベースのコーデックの使用は、例えばアナウンスが通常のメディアを中断する際に、通常は状態不一致を生じるだろう。その結果、ユーザを不快にさせもするかもしれない聞き取り可能又はその他の知覚可能な歪みを生じる。良好な品質をなおも提供しつつ、ビットレートを低減するためすなわち高圧縮比を獲得するため、ＡＭＲ又はＡＭＲ−ＷＢのような多くの最新コーデックにおいてフレーム間予測が用いられる。フレーム間予測は、フレームからフレームへと状態が渡されることを要求する。アナウンスが通常のメディアを中断する場合に、コーデックの二つの異なるインスタンス、つまりユーザからの音声メディアのためのＵＥ  Ａにおける一つのコーデック・インスタンスとアナウンス・サーバにおける一つのコーデック・インスタンスとが用いられるため、状態不一致が生じるだろう。ＵＥ  Ａにおける状態は用いられる予測に従って展開する一方で、アナウンス・サーバにおける状態は初期状態から始まる。状態不一致は、現在のコンテンツに依存して多かれ少なかれ聞き取り可能な歪みを生じ得る。このような歪みの二つの例が図３及び図４に示される。歪みは両方の場合においてはっきりと聞き取り可能であり、聞き手によって容易に気付かれるが、図３のスパイクの方がはるかに不快である。
【００３２】
図３及び図４から、非同期のリセットの後に同期が回復するために約１００−２００ｍｓかかることも見て取れる。その代わりに、ＰＣＭのような状態を持たないコーデックは直ちに回復するだろう。なぜなら、適切なコンテンツのための状態を「構築する」必要がないからである。
【００３３】
この問題は音声に制限されない。同様の問題が、一般オーディオに対して、及びビデオに対しても生じる。これらの場合について、これらのコーデックは一般的に音声コーデックよりも高い圧縮比を有し、この圧縮比を達成するために高い品質状態により大きく依存するため、いくつかの場合でさらに大きな問題を予想できる。
【００３４】
前述のように、所与のエンコーダからのメディアが中断されて異なるエンコーダにより符号化されたアナウンスにより置き換えられた場合にエンコーダ・インスタンスの切り替えが生じるだろうし、アナウンスが始まる場合に切り替えが生じるだろうし、アナウンスが終わる場合に別の切り替えが生じるだろうし、及び／又は当初のエンコーダ・インスタンスに戻される場合に切り替えが生じる。アナウンスは「その場で（ｏｎ  ｔｈｅ  ｆｌｙ）」符号化されてもよく、又は事前に記録された素材として存在してもよいが、受信機の観点からはこれが違いを生じさせることはない。
【００３５】
状態不一致はまた、通話保留状況において生じてもよい。通話保留シナリオにおける状態不一致の問題は以下に説明され得る。
１．ユーザＡはユーザＢと会話をしていて、両方のＵＥは送受信状態である。
２．ユーザＡはユーザＢを保留にする。ＵＥ  Ａは送信専用状態に入り、ＵＥ  Ｂは受信専用状態に入るだろう。
３．ユーザＡはユーザＣとの会話を開始し、両方のＵＥが送受信モードとなる。ユーザＢはその間にＸからの保留中のアナウンス又は音楽を得ているかもしれないし、ミュートされているかもしれない。
４．ユーザＡはユーザＢとの会話を再開する。ＵＥ  ＡとＵＥ  Ｂとの両方が送受信モードとなる。
【００３６】
Ａからのメディアが保留中のアナウンス又は音楽によって中断される場合のＢにおける問題に加えて、上述のシナリオは、ステップ３からステップ４への移行において、少しの起こり得る問題をも与える。
１．ユーザＡのＵＥはユーザＣのＵＥからのパケットを受信してきていて、突然にユーザＢのＵＥからのパケットを得る。二つのストリームＣ→ＡとＢ→Ａとが二つの異なるデコーダ・インスタンスで復号される場合に、このことは、通常はささいな問題でなる。一方、二つのストリームが単一のデコーダ・インスタンスを共有する場合には、このことは、デコーダがリセットされない限り、深刻な状態不一致が起こり得るリスクを与える。
２．ユーザＢのＵＥは、ユーザＡのＵＥからのＤＴＸ  ＳＩＤ更新パケットを受信しているかもしれないし、保留中の通話アナウンス又は音楽を受信しているかもしれないし、何も受信していないかもしれない。これは、デコーダが完全なミュート状態であるかもしれないし、別の未知の状態であるかもしれないことを意味する。保留中の音楽又はアナウンスが別個のデコーダ・インスタンスにより扱われる場合、問題は通常は制限される。一方、一つのデコーダ・インスタンスだけが用いられる場合に、やはり深刻な状態不一致の問題が頻繁に生じるだろう。
【００３７】
デコーダ・インスタンスがただ一つであることによる課題は、複雑さ及び物理サイズの課題が重要な要因となる携帯電話の用途で特に重要である。
【００３８】
例示的な技術に係る基本的な考えは、進行中の通信セッション中にデコーダにおいて起こり得る状態不一致を検出し、状態不一致を回避するため又は少なくとも歪みを軽減するために、デコーダをリセットすることである。
【００３９】
図５は本発明の例示的な実施形態に係る基本的な方法の概略フロー図である。本発明は、進行中の通信セッション中に着信メディアの送信元の変更を検出すること（Ｓ１）に基づく。このような検出された変更に応じて、デコーダのデコーダ状態は、新たな着信メディアを復号する前にリセットされる（Ｓ２）。このようにして、受信機における複数のアクティブなデコーダ・インスタンスを必要とすることなく、状態不一致を回避でき、又は少なくとも歪みが軽減されるだろう。これは、復号されたメディアが最終的にレンダリングされる際にメディア歪みが軽減されることにつながり、全体的な複雑さ、メモリ使用量、電力消費の観点で大幅な節減にもなる。一般に、デコーダをリセットすることは、検討中のデコーダ状態が明確な初期状態に設定されることを意味する。
【００４０】
図６は、本発明の例示的な実施形態に係る受信機を主に説明する概略ブロック図である。基本的に、着信メディアは複数のメディア送信元から由来してもよく、送信元の変更は例えば、メディア送信元の切り替え、若しくは既存のメディア・ストリームからのメディア送信元の追加又は削除であってもよい。受信器１００は、一つ以上のバッファ１１０、デコーダ１２０、及び再生器１３０のほかに、検出器１４０を含む。ジッタ・バッファのようなバッファ（群）１１０は着信データパケットを一時的に記憶し、その後に着信データパケットは更なる処理のためにデコーダ１２０に送られる。パケット到着時間の揺らぎいわゆるジッタが、ネットワーク輻輳、タイミング・ドリフト、又はルート変更のせいで生じるかもしれない。そして、ジッタ・バッファは、意図的に到着パケットを遅延し、当該パケットを一定間隔でデコーダに転送することによって、遅延揺らぎを等しくするために用いられてもよい。このようにして、エンド・ユーザは、極めて小さい歪みを有するクリアな接続を経験する。検出器１４０は好適には、着信メディアの送信元の変更を検出するために、着信メディア・ストリーム、又はバッファされたメディア・ストリームを監視する。好適には、バッファ１１０内の既存のメディア・フレームがバッファから連続的に出力され、復号及びレンダリングされ、そして新たなメディア・フレームがバッファされる。その後に、検出器１４０はデコーダ１２０に対するリセット信号を生成する。リセット信号に応じて、デコーダ１２０は、新たなメディア・フレームの復号及びレンダリングを始める前に、自身の初期状態にリセットされる。
【００４１】
有利には、一つ以上のパケット・ヘッダ・フィールドを監視して着信メディア・データ・ストリーム内の複数のパケット間のパケット・フィールドの変化を検出するか、送信元の変化を検出するための信号分類アルゴリズム又はすかし技術を用いてメディア・ペイロードを監視するか、若しくはＳＩＰシグナリングのような明示的な制御シグナリングを監視する。
【００４２】
適切な検出メカニズムの例は、ＲＴＰストリームにおけるＳＳＲＣフィールドとＣＳＲＣフィールドとの少なくとも何れかのようなパケット・ヘッダ・フィールドの変化を検出することと、通話保留状態の変化を検出することと、及び着信メディア・データ内の複数のパケット間のメディア・エンコーディングの変化を検出することとを含む。他の例は以下に説明される。
【００４３】
デコーダに関連付けられたジッタ・バッファの再初期化（いわゆる再バッファリング）がデコーダをリセットすることの特定の形式としてみなされてもよいことも理解されるべきである。
【００４４】
本発明の特定の用途はＭＭＴｅｌシステムにおけるＶｏＩＰ（ボイス・オーバ・ＩＰ）であるが、本発明をビデオ・コーデック及び一般のオーディオ・コーデックに用いることもできる。特に、通話アナウンス、通話保留、明示的通話転送（ＥＣＴ）のような付加サービス、又はメディア送信元が変更されるその他の付加サービスが、受信機において、一切の歪みなく又は少なくとも可能な限り小さい歪みで再構築されることを保証することが望ましい。例えば、受信機は、アナウンスが（ＵＥ  Ａからの）通常のメディアとは異なる送信元から来ることを検出して、、歪みを最小化（又は少なくとも軽減）するために適切な動作をおこしてもよい。受信機はまた、着信メディアの送信元の変更を示す、通話保留、明示的通話転送、又はその他の同様なサービスへの転送若しくはこれらからの転送を検出してもよい。
【００４５】
上述のように、任意の不快な歪みを最小化するために、メディアを適切に扱うことが重要である。歪みを軽減するための動作の扱いは主に受信機側で行われる。
【００４６】
＜状態リセット・トリガの検出の例＞
例えば、アナウンスの開始及び終了又はその他の送信元の変更に起因してデコーダのリセットが必要となることを検出する複数の方法がある。いくつかの検出方法は信頼でき、何らかの種類のシグナリングに依存する。その他の検出方法は、何らかの種類の特性を検出することを必要とするため、信頼が低い。
【００４７】
信頼できる方法の例は以下を含む。
・ＲＴＰヘッダが、送信元からの乱数を含むＳＳＲＣ（同期送信元）フィールドを含む。ＳＳＲＣフィールドが変更された場合に、受信機は送信元が異なることを知る。
・アナウンス・メディアが終了した場合に、ＳＳＲＣ値は当初のＳＳＲＣ値に戻るように切り替わるだろう。
・一つのＲＴＰパケット内に複数の送信元からのメディアを有することが可能である。この場合、一つのＳＳＲＣフィールドと一つ以上のＣＳＲＣ（寄与送信元）フィールドとがあるだろう。アナウンス・メディアを符号化するエンコーダＸは、自身のメディアをエンコーダＡからのＲＴＰパケットに加えることを選択してもよい。これは、ＣＳＲＣ値を加えるだろうことを意味する。ＳＳＲＣとＣＳＲＣとの少なくとも何れかが変わった場合に、受信機は追加されたメディアが異なる送信元から来たことを知る。
・アナウンス・メディアが終了した場合に、ＣＳＲＣ値は後続するＲＴＰパケットから除去されるだろう。
・エンコーダＡからのメディアとアナウンス・サーバからのメディアとはまた、異なるように符号化されてもよい。例えば、エンコーダＡからのメディアはＡＭＲ−ＷＢ（広帯域ＡＭＲ）を用いてもよいし、エンコーダＸからのメディアはＡＭＲ（挟帯域ＡＭＲ）を用いてもよい。
異なる符号化は、異なる構成のための異なるＲＴＰペイロード・タイプ（ＰＴ）を割り当てられることによって示される。これはまた、メディアが異なる送信元から来たことを検出するための一つの信頼できる方法である。
エンコーダＸからのメディアが終了した場合に、当初のコーデック形式が、エンコーダＡからのメディアに対して用いられるだろう。
・ＳＩＰシグナリング。通話保留シナリオにおいて、いくつかのパーティは送信専用状態又は受信専用状態に入り、その後に送受信状態に戻るだろう。そして、これらの移行は送信元の変更を示すものとして働く。
・アナウンス・サーバから由来するメディアが信号分類アルゴリズムによって検出されてもよい。
・何らかの種類のアナウンス識別子がいわゆるメディアすかしを用いて実際のメディアに含まれ得る。
・アナウンス・サーバはまた、アナウンス・メディアの送信が開始されたこと及びアナウンス・メディアの送信がいつ終了したかを受信機に通知するため、明示的な信号を送ってもよい。一つの可能性は、ＰｏＣ（プッシュ−ツー−トーク・オーバ・セルラ）（非特許文献９）のために規定されるトーク・バースト制御（ＴＢＣ）シグナリング（非特許文献８）を用いることである。
【００４８】
代替の方法の例は以下を含む。
・通常、エンコーダＸはアナウンス・サーバに存在するため、エンコーダＡからのメディアからエンコーダＸからのメディアに切り替わる場合にジッタ特性が変わる。これは、受信機によって知覚される全体のジッタが、アップリンク、コア・ネットワーク、及びダウンリンクを通じたジッタの合計だからである。そして、アナウンス・サーバからメディアが送られる場合に、この無線インタフェースを通じてメディアが送られないため、アップリンクからのジッタは適用できない。
・同様の理由で、パケットロス特性が変わることも期待できる。
【００４９】
図７は本発明の別の例示的な実施形態に係る方法の概略フロー図である。この特定の例では、進行中のセッション中のメディア送信元の変更がまず検出され（Ｓ１１）、その後にジッタ・バッファ内の既存のメディアが復号され、すべて再生される（Ｓ１２）。オプションとして、ジッタ・バッファが再初期化される（Ｓ１３）。新たな送信元からのメディア・データがジッタ・バッファに記憶される（Ｓ１４）。送信元の変更の検出に応じて、新たなメディアを復号する前にデコーダ状態がリセットされる（Ｓ１５）。最後に、新たなメディアが復号され、すべて再生される（Ｓ１６）。
【００５０】
図６のものと同様に、図８は本発明の更なる例示的な実施形態に係る受信機を主に説明する概略ブロック図である。しかしながら、この特定の例では、受信機１００は、ジッタ・バッファ（群）を再初期化するユニット１５０をさらに備える。さらに、再生器１３０は、より柔軟で一般的なレンダリング・モジュールとして実装され、異なる送信元からのメディア間の滑らかな移行を実現するための、フェージング、時間スケーリング、及び帯域拡張のようなオプションの機能を含む。
【００５１】
以下では、アナウンス又は保留通話が検出された場合の動作に関する本発明の例示的な実施形態が図９を例示的に参照して説明される。
【００５２】
アナウンス・メディアが受信されたこと又は通話保留状態が変更されたことを検出すると（Ｓ２１）、受信エンティティ（ＵＥ）の動作の例は以下を含む。
・ジッタ・バッファ内のエンコーダＡからの既存のメディア・フレームを可能な限り速くすべて再生又は終了させ（Ｓ２２）、アナウンス・メディアをバッファする（Ｓ２４）。
・エンコーダＡからのメディアのすべての再生をスピードアップするために、受信機は時間スケーリングを用いてもよい。
・アナウンス・メディアの生成を開始する前に、デコーダは初期状態にリセットされるべきである（Ｓ２５）。デコーダがリセットされた時点で、新たなメディアの復号を開始できる（Ｓ２６）。
・ジッタ・バッファを再初期化（いわゆる再バッファリング）する（Ｓ２３）。
・エンコーダＸにより符号化されたメディアがアナウンス・メディアである場合に、これは真にリアルタイムではない（リアルタイム要件は事前に記録されたメディアには適用されない）。受信機はすべての再生を開始する前にジッタ・バッファ内により多くのメディアをバッファしてもよく、それによって遅延ロスのリスクを軽減する。
・エンコーダＡからのメディアのすべての再生は、好適には、フェードアウト（使用されている（通常の）音量からゼロへ音量を徐々に減少すること）を用いるべきである。受信機は、好適には、アナウンス・メディアに対してフェードイン（ゼロから通常の音量へ音量を徐々に増加すること）を用いるべきである（Ｓ２８）。
・受信機は、すべてのスパイクを検出してミュートできるようにするために、再生成された信号をすべて再生する前に監視することもできる。
・エンコーダＡからの音声メディアとアナウンス・メディアとが異なる音響の帯域幅を使用していること、例えば、それぞれＡＭＲ−ＷＢ（５０−７０００Ｈｚ）とＡＭＲ（３００−３４００Ｈｚ）とで符号化されていることを検出すると、受信機は好適には、滑らかな移行を行うために、帯域拡張（広帯域拡張）を用いるべきである（Ｓ２７）。異なるメディア間の移行を滑らかに実施するためのその他の同様の手順もオーディオ及びビデオに対して予想できる。
【００５３】
受信しているアナウンス・メディアがこれ以上ない場合に、受信エンティティ（ＵＥ）の動作の例は以下を含む。
・ジッタ・バッファ内になおも存在している任意のアナウンス・メディアを出来るだけ速くすべて再生する（Ｓ２２）。
・受信機は、残っているアナウンス・メディアのすべての再生をスピードアップするために時間スケーリングを用いてもよい。
・エンコーダＡからのメディアを再生する前にデコーダをリセットする（Ｓ２５）。
・ジッタ・バッファを再初期化（再バッファリング）する（Ｓ２３）。これは特に重要である。なぜなら、アナウンス・サーバのようなネットワーク内のボックスに存在する場合に、エンコーダＸからのＲＴＰパケット上のジッタはエンコーダＡからのものより通常は少なくなるためである。これは、ジッタ・バッファは、エンコーダＡからのＲＴＰパケットに対して用いられるものよりも低いバッファリング・レベルに通常は適合されることを意味する。そして、その後にエンコーダＡからのメディアに戻すように切り替わった際に、ジッタ・バッファは、エンコーダＡからのメディアについて予想され得る大きなジッタを処理するのに十分なデータを含んでいない。
・可能な変形は、アナウンス・メディアに切り替える前にジッタ・バッファ目標レベルと適合（ａｄａｐｔａｔｉｏｎ）状態とを記憶し、当該レベルと当該状態とでジッタ・バッファ適合を再初期化することである。
【００５４】
前述のように、送信側は、所定の信号パターンを送信することによって、新たな送信元からのメディアに備えて受信機側のデコーダのリセットを実施してもよい。これは、第１のメディア送信元からのメディアの受信を伴う進行中の通信セッション中に、受信機は、異なる第２のメディア送信元からのメディアの後続する受信に備えて所定の信号パターンを受信するだろうことを意味する。そして、デコーダは、第２のメディア送信元からのメディアの復号を開始する前に、所定の信号パターンに応じてリセットされる。例えば、通話保留状態から戻るように切り替わる際に、送信エンティティ（ＵＥ）はコーデック・ホーミング・フレーム又は同様の信号パターン（複数の空フレームであってもよい）を送信して、それによって受信機におけるデコーダのリセットを実施してもよい。
【００５５】
本発明の例示的な利点は以下である。
・メディア送信元間の切り替え、メディア送信元の追加、及びメディア送信元の削除の少なくとも何れかに起因する歪みが軽減し、そして完全に除去されさえするかもしれない。これは、例えば、受信ユーザのためにアナウンスが生成されなければならない場合に、メディア間のより好ましい移行を与える。
・ＵＥ内のＭＩＰＳ及びメモリの両方について、複雑さの利点もある。なぜなら、ＵＥは、並列に実行する複数のアクティブなコーデック・インスタンスを有する必要がないからである。
【００５６】
上述の実施形態は単に例として与えられ、本発明がこれに限定されないことが理解されるべきである。本明細書で開示され主張された基本的な根底原理を保持している更なる修正、変更、改良が本発明の範囲に含まれる。
【００５７】
＜略語＞
ＡＤＰＣＭ    適合差分ＰＣＭ（Adaptive Differential PCM）
ＡＭＲ        適合マルチレート（Adaptive Multi-Rate）
ＡＭＲ−ＷＢ  ＡＭＲ−広帯域（AMR-WideBand）
ＣＳＲＣ      寄与送信元（Contributing Source）
ＤＴＸ        不連続送信（Discontinuous Transmission）
ＥＣＴ        明示的通話転送（Explicit Call Transfer）
ＥＶＲＣ      可変速度符号化（Enhanced Variable Rate Codec）
ＩＭＳ        ＩＰマルチメディア・サブシステム（IP Multimedia Subsystem）
ＩＰ          インターネット・プロトコル（Internet Protocol）
ＭＩＰＳ      １００万命令／秒（Million Instructions Per Second）
ＭＭＴｅｌ    マルチメディア・テレフォニー（Multi Media Telephony）
ＰＣＭ        パルス符号変調（Pulse Code Modulation）
ＰｏＣ        プッシュ−ツー−トーク・オーバ・セルラ（Push-to-talk over Cellular）
ＲＴＰ        リアルタイム・プロトコル（Real-Time Protocol）
ＳＩＤ        無音記述子（Silence Descriptor）
ＳＩＰ        セッション開始プロトコル（Session Initiation Protocol）
ＳＳＲＣ      同期送信元（Synchronization Source）
ＴＢＣ        トーク・バースト制御（Talk-Burst Control）
ＵＥ          ユーザ装置（User Equipment）
ＶｏＩＰ      ボイス・オーバ・ＩＰ（Voice over IP）
【図１】
0005528811.tif 000002
【図２】
0005528811.tif 000003
【図３】
0005528811.tif 000004
【図４】
0005528811.tif 000005
【図５】
0005528811.tif 000006
【図６】
0005528811.tif 000007
【図７】
0005528811.tif 000008
【図８】
0005528811.tif 000009
【図９】
0005528811.tif 000010