通信ネットワーク環境におけるアナウンスメディアの処理
ユーザメディアとアナウンスメディアとの切替を効果的に処理するために、基本ステップ（Ｓ１）は、まず、ユーザメディアのコンフィグレーションを判定することである。次に、判定されたユーザメディアコンフィグレーションに基づいて、提示されるアナウンスメディアのコンフィグレーションが判定される（Ｓ２）。続いて、アナウンスメディアコンフィグレーションに従って、アナウンスメディアがコンフィグレーションされ（Ｓ３）、最後にコンフィグレーションされたアナウンスメディアが意図したユーザに送信される（Ｓ４）。このようにして、アナウンスの全体的な外観または音は、ユーザメディアの全体的な外観または音と事実上同一または少なくとも類似し、好ましくは歪がない。これにより、ユーザは、アナウンスをできるだけはっきりと知覚することが可能になる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、現代の通信ネットワークにおけるアナウンス技術（announcement technology）に関し、より詳細には、アナウンスメディアの処理と、ユーザメディアとアナウンスメディアとの切替に関係する課題とに関するものである。
【背景技術】
【０００２】
アナウンス（告知）は、テレフォニーサービス等の通信サービスにおいて重要な役割を果たす。アナウンスは、通常は、予め録音されたメディア（pre-recorded media）、または機械で生成されたメディア（machine-generated media）である。機械で生成されたメディアは、例えば、テキストを音声に変換する機能（別名、音声合成）またはテキストを画像に変換する機能で生成され得る。アナウンスは、通信ネットワーク内で生成されてもよいし、またリモートユーザの交換台またはコンピュータによって生成されてもよい。
【０００３】
通信ネットワークからのアナウンスの使用例には、以下のものを含む。
【０００４】
・ユーザが開始しているコマンドを完了できない場合のエラーメッセージ。例えば、発呼者が電話番号を非通知にしていて、電話番号を見ることなしには電話に応答しないと着呼者が設定している場合、システムは、発呼者にエラーメッセージを提示しなければならない。
【０００５】
・ユーザがセッションを保留する場合、システムは、通話相手に保留メッセージまたは保留音を再生することができる。
【０００６】
・会議電話において、新規のユーザがセッションに参加する場合またはユーザがセッションから退出する場合に、会議サーバが、例えば、「Ｊｏｈｎ Ｓｍｉｔｈ（ジョン スミス）が会議に参加しました」および「Ｊｏｈｎ Ｓｍｉｔｈが会議から退出しました」等のアナウンスを提示することができる。
【０００７】
・ユーザが料金を前払いしていて、その前払い金を使い切りそうになっている。オペレータは、残金が少ないので使用を制限してもよく、セッション開始時またはセッション中（非常に長いセッションのことがある）にそれについてアナウンスしたい。
【０００８】
・インターネットでますます使用されている方法は、ウェブページ上にピンコード（またはパスワード）を有する画像を提示することである。ピンコードの画像はかなり歪んでいるので、自動テキスト認識システムはピンコードを検出できないはずであるが、賢明な人間にとっては、それでも文字と数字を読むことができるはずである。これは、（安全でない）電子メールで、対応するピンコードを送信する代わりに使用される。
【０００９】
着呼者側のアナウンスの使用例には、以下のものがある。
【００１０】
・ユーザが旅行会社に電話してチケットを予約する。以下のシナリオが想定される。
【００１１】
１．ユーザが旅行会社のスタッフと相談して、最善の旅行プランを見つける。このステップでは、話し合いは２人の人間の間で行われる。
【００１２】
２．旅行について決定後、ユーザは、自身のクレジットカード番号をキーインするように依頼される。これは、人間と機械の通信であり、ここで、ユーザは、事前録音メッセージまたは機械生成メッセージを聞いて、ダイヤルボタン（０〜９）を押して自身のクレジットカード番号を入力する。このプロセスでは、以下の文が想定される。「あなたのクレジットカード番号をキーインしてください」、「番号は、１２３４ ５６７８ ９０１２ ３４５６ですね」、「これで正しい場合は１を押してください、正しくない場合は２を押してください」、「あなたのクレジットカードの有効期限を入力してください」、「有効期限は、２００７年１月１日ですね」。これらの文は、アナウンスサーバによって生成されるであろう。
【００１３】
３．クレジットカード番号および他の必要なデータをキーイン後、更なる旅行のオプションを決定するために、旅行会社のスタッフとのセッションは続く。
【００１４】
４．これらのステップは、複数回繰り返される場合がある。
【００１５】
・ユーザは、新しいコンピュータの購入後後のいくつかの問題を解決するために、サービスデスクまたは顧客電話窓口に電話する。サービスデスクは、スクリーニングプロセスを使用して問題を分類してから、電話を技術者に連絡する。このスクリーニングプロセスでは、ユーザは次のような質問に回答しなければならない。「お客様の問題がソフトウェア関連の場合は『１』と＃を押してください。ハードウェア関連の場合は『２』を押してください。わからない場合は『３』を押してください」。このスクリーニングプロセス後、セッションは保留され、待機メッセージがユーザに対して再生される。技術者が電話に応答してもよく、また、待機メッセージを任意の時点で中断してもよい。
【００１６】
従来、プロンプトおよび音声アナウンス等の情報メッセージの生成は、エンコーディング（encoding：符号化）およびデコーディング（decoding：復号）用の従来のパルス符号変調（ＰＣＭ）または適応的差分ＰＣＭ（ＡＤＰＣＭ）を使用する、回線交換システムの相対的に単純な時分割多重（ＴＤＭ）ベースのアナウンスマシンによって実行されている。現代および未来の通信システムでは、アナウンスを処理する条件および要件は劇的に変化するであろうから、そのような通信システムにおいてアナウンスメディアを効果的に処理するためのソリューションを提供する一般的必要性がある。
【発明の概要】
【発明が解決しようとする課題】
【００１７】
本発明は、上述および他の先行技術の装置の欠点を解決する。
【００１８】
本発明の一般的な目的は、通信ネットワーク環境におけるアナウンスメディアの処理を改良することである。
【００１９】
本発明の一目的は、遷移に伴う不快さおよび歪の少なくとも一方を伴うことなく、または少なくとも切替によって引き起こされる歪を削減するように、ユーザメディアとアナウンスメディアとの切替を効果的に処理することである。
【００２０】
特に、ユーザができるだけはっきりとアナウンスを知覚できるようにすることが望ましい。
【００２１】
特に、具体的な一目的は、ユーザメディアとアナウンスメディアとを切り替える方法およびシステムを改良し提供することである。
【００２２】
別の具体的な目的は、通信ネットワーク用のアナウンスサーバを改良し提供することである。
【課題を解決するための手段】
【００２３】
上述および他の目的は、添付の特許請求の範囲によって定義される本発明によって達成される。
【００２４】
現代の通信ネットワークがもたらす広範囲の様々なメディアコンフィグレーションにより、アナウンスメディアの全体的な音または外観が通常のユーザメディアの音または外観と比べて非常に異なることになることがあるので、それはアナウンスサーバに問題を引き起こすことがあることを、発明者たちは認識している。これは、ユーザにとって非常に不快なことがある。
【００２５】
ユーザメディアとアナウンスメディアの切替を処理するために、本発明の基本的な概念は、まず、ユーザメディアのコンフィグレーションを判定し、次いで判定したユーザメディアコンフィグレーションに基づいて、提示されるアナウンスメディアのコンフィグレーションを判定することである。続いて、アナウンスメディアをアナウンスメディアコンフィグレーションに従ってコンフィグレーションし、このコンフィグレーションされたアナウンスメディアを、意図したユーザに送信する。このようにして、アナウンスの全体的な外観または音は、ユーザメディアの全体的な外観または音と事実上同一または少なくとも類似し、好ましくは、歪がなく、ユーザができるだけはっきりとアナウンスを知覚することを可能にするであろう。
【００２６】
しかしながら、本発明が、音声やオーディオに限定されず、映像にも適用されてもよいことも理解されるべきである。
【００２７】
通常、ユーザメディアは、通話相手のリモートユーザから到来し、アナウンスメディアは、アナウンスサーバまたはプロセッサから到来する。しかしながら、アナウンスサーバは、ネットワークベースのアナウンスサーバとしてネットワーク側に配置されてもよいし、またリモートユーザに関連したユーザ側、例えば、ユーザ機器もしくは構内交換機（ＰＢＸ）内に配置されてもよい。
【００２８】
本発明の好ましい例示的実施形態では、そのユーザメディアコンフィグレーションから適切なユーザメディアコンフィグレーションを選択または他の手段で判定されてもよい、１つ以上の有効なユーザメディアコンフィグレーションを識別するために、当該ユーザ（considered users）間のユーザメディアに関する通信セッションのセットアップがモニタされる。
【００２９】
好ましくは、現在使用されているユーザメディアコンフィグレーションを検出するために、ユーザ通信がモニタされ、アナウンスメディアコンフィグレーションを現在のユーザメディアコンフィグレーションに一致（マッチング）させることを可能にする。次いで、アナウンスサーバにそのコンフィグレーションされたアナウンスメディアをセッションに挿入させることによって、コンフィグレーションされたアナウンスメディアは、意図したユーザに転送されることが好ましい。選択的には、アナウンスメディアは、例えば、アナウンスメディア用の新規のセッションを確立することによって、ユーザメディアと並行して送信される。
【００３０】
好ましくは、ユーザメディアに対するコーデックおよび／または伝送フォーマットコンフィグレーションが判定され、次いで、アナウンスメディアコンフィグレーションが、アナウンスメディアのコーデックおよび／または伝送フォーマットコンフィグレーションとユーザメディアのコーデックおよび／または伝送フォーマットコンフィグレーションとの一致（マッチング）に基づいて判定される。
【００３１】
別の態様では、本発明は、通信ネットワーク用のアナウンスサーバに関する。基本的には、アナウンスサーバは、ネットワークの通信セッションにおけるユーザメディアのコンフィグレーションを示すメディアコンフィグレーション情報を取得するように、かつメディアコンフィグレーション情報に基づいてセッションに挿入されるアナウンスメディアをコンフィグレーションするように構成される。さらに、アナウンスサーバは、コンフィグレーションされたアナウンスメディアをセッションに挿入するように動作可能である。
【００３２】
本発明によって提供される他の利点は、本発明の実施形態についての以下の説明を読むと理解されるであろう。
【００３３】
本発明の他の目的および利点とともに、本発明は、添付の図面と一緒に以下の説明を参照することにより最もよく理解されるであろう。
【図面の簡単な説明】
【００３４】
【図１】例示的システム概観を示す概略図である。
【図２】エンコーダ状態がリセットされるのに対してデコーダ状態がリセットされない場合の歪を示す概略図である。
【図３】デコーダ状態がリセットされるのに対してエンコーダ状態がリセットされない場合の歪を示す概略図である。
【図４】本発明の一例示的実施形態に従うユーザメディアとアナウンスメディアの切替の基本的方法の概略のフロー図である。
【図５】本発明の別の例示的実施形態に従うユーザメディアとアナウンスメディアの切替方法の概略のフロー図である。
【図６】本発明の一例示的実施形態に従うネットワーク側およびユーザ側を含むシステム概観図である。
【図７】本発明の別の例示的実施形態に従う概観図である。
【図８】本発明のまた別の例示的実施形態に従う概観図である。
【図９】取り得る好ましい実施形態に従うアナウンスサーバの概略のブロック図である。
【発明を実施するための形態】
【００３５】
図面全体を通して、同一の参照文字は、対応する要素または同様の要素に対して使用される。
【００３６】
本発明のより良い理解のためには、簡潔なシステム概観から始めるのが役立つであろう。
【００３７】
図１は、例示的なシステムの概観を示す概略図である。この例示的なシステムは、関連基地局２０−１、２０−２経由で通信中の２人のエンドユーザＡおよびＢのユーザ機器（ＵＥ）１０−１、１０−２と、ネットワークベースのアナウンスサーバ３０とを有する。この場合、リアルタイムプロトコル（ＲＴＰ）［１］メディアストリーム等のメディアストリームは、メディアリソース機能プロセッサ（ＭＲＦＰ）［２］でもよいアナウンスサーバを常に通過する。この例では、アナウンスサーバは、ユーザＡからのＲＴＰストリームをアナウンスに置換する、これは、インバンドアナウンス（in-band announcement：帯域内アナウンス）と呼ばれる。
【００３８】
アナウンスを導入する他の方法も可能であり、例えば、アナウンスサーバを通過することなく、メディアがＡとＢの間で直接送信されるものがある。この場合、アナウンスは、アナウンスサーバからＵＥ（ユーザ機器）ＢへＳＩＰ ＩＮＶＩＴＥで送信されてもよく、ＵＥ Ｂは、アナウンスサーバから受信されるメディアを生成するために、ＵＥ Ａから受信されるメディアを破棄しなければならない。別の代替方法としては、アナウンスメディアへのリンク（ＵＲＬ）を含むＳＩＰ ＩＮＦＯまたはＳＩＰ ＮＯＴＩＦＹメッセージ等のメッセージを送信することである。一般に、代替方法は、このように、アナウンスメディア用に新規のセッションを確立してまたは確立せずに、ユーザメディアに並行してアナウンスメディアを送信することである。
【００３９】
アナウンスサーバは、通信ネットワーク内に設置されてもよい。ＩＰマルチメディアサブシステム（ＩＭＳ）等の現代のシステムでは、アナウンスサーバは、メディアリソース機能プロセッサ（ＭＲＦＰ）内に通常設置されるであろうが、例えば、会議サーバ等のアプリケーションサーバにも設置できよう。
【００４０】
アナウンスサーバを、エンドポイント内もしくはエンドポイント近くに、ユーザ機器内に、コンピュータ内に、または構内交換機（ＰＢＸ）内に有することも可能である。
【００４１】
発明者たちによる入念な分析で、既存のソリューションは、以下に説明する１つ以上の問題に晒されていることが明らかになっている。
【００４２】
現在のところ既存の回線交換システムでは、アナウンスが機能しているが、これは、使用されるコーデックが典型的にはＰＣＭ［４］またはＡＤＰＣＭ［５］であるからうまく機能しているのである。これらのコーデックは、予測を全く使用しない（ＰＣＭ）、または非常に限られた量の予測しか使用しない（ＡＤＰＣＭ）、サンプル単位のコーデックである。これは、デコーダが状態不一致から非常に急激に回復すると、聞き取れる歪を引き起こす可能性が低いことを意味する。
【００４３】
さらに、従来のシステムは、コーデックを１つだけ使用する、例えば、ＰＣＭまたはＡＤＰＣＭのどちらかを使用するのであって、決して両方を使用しない。システムは、全セッション中に、同一の伝送フォーマットも使用し、例えば、コーデックレート、フレームアグリゲーション（frame aggregation：フレーム集約）、または冗長度を決して状況に応じて変化させない。実際のところ、システムは、すべてのセッションに対して同一の構成を使用する。
【００４４】
ＩＰマルチメディアサブシステム（ＩＭＳ）等の現代および将来のシステムでは、その中でも特にマルチメディアテレフォニ（ＭＭＴｅｌ）［６］に関しては、状況は完全に異なる。数種類のメディアを送信することが可能である。このメディアは、異なるコーデックでかつ異なるレートで符号化され得る。異なる伝送フォーマットが使用される可能性がある。すなわち、ペイロードフォーマットが、フレームアグリゲーションありでまたはなしで、冗長度ありでまたはなしでも、使用される得る。これらの変形は、ネットワーク輻輳に対するリスクを減らし、輻輳期間中でさえ合理的な品質でセッションを維持できるようにセッションを適応させるために必要である。これは、無線チャネルが大幅に変化するセルラ方式では特に重要である。しかしながら、これらの変形は、アナウンスサーバに対して問題を引き起こす。以前したような１つの方法だけでアナウンスメディアを符号化し、受信者が満足することを望むことはできない。ＵＥ ＡとＵＥ Ｂとの間のメディアは、通常、広帯域コーデック（ＡＭＲ−ＷＢ）で符号化されているが、アナウンスを狭帯域コーデック（適応マルチレート：ＡＭＲ）で符号化する場合、メディアは全く異なって聞こえるであろうし、受信ユーザは、アナウンスが通常のメディアとはなぜ大幅に異なって聞こえるのか疑問に感じるであろう。最悪の場合、受信ユーザは、不快になりアナウンスの実際の内容よりメディア品質に関心が行ってしまうかもしれず、これは、ユーザがアナウンスを誤解さえしかねないことを意味する。
【００４５】
さらに、現代の予測ベースのコーデックの使用は、アナウンスが通常のメディアを中断する場合に、状態不一致をもたらすことがあり、同様に、ユーザを不快にさせることがある聞き取り可能な歪を生じる可能性がある。予測は、例えば、ＡＭＲ［７］またはＡＭＲ−ＷＢ［８］等の現代のコーデックに関しては非常に重要である。フレーム間予測は、ビットレートを減少させるために、すなわち、高圧縮比にするために使用されるが、それでもよい品質を提供する。フレーム間予測では、フレームからフレームへ状態が渡される必要がある。アナウンスが通常のメディアを中断する場合、ユーザからの音声メディアに対するＵＥ Ａの１つのコーデックインスタンスと、アナウンスサーバの１つのコーデックインスタンスとの２つの異なるコーデックインスタンスが使用されるので、状態不一致となるであろう。ＵＥ Ａの状態は、使用される予測に従って進展しているのに対して、アナウンスサーバの状態は、初期設定状態から開始する。状態不一致は、現在のコンテンツに依存して、多かれ少なかれ聞き取れる歪を引き起こし得るる。そのような歪の２つの例が、図２および図３に示されている。両方の場合とも歪は、はっきり聞き取れ、聞き手によって容易に気付かれるが、図２のスパイクの方がはるかに気に障る。
【００４６】
図２および３からは、非同期のリセット後、合成音が正常な状態に回復させるためには、約１００〜２００ｍｓかかることを把握することができる。その代わりに、ＰＣＭ等のステートレス（state-less）コーデックは、状態（ステート）を適切なコンテンツに「作り上げる」必要がないので、直ぐに正常な状態に戻るであろう。
【００４７】
従来の回線交換システムは、典型的には、音量レベルの制御も有しており、音量が適切でない場合、ネットワーク内で音量を調節する。マルチメディアテレフォニのようなＶｏＩＰシステムは、着想が変換（transcoding：トランスコーディング）および他の種類の変更なしにＶｏＩＰパケットをエンドツーエンドで送信するものなので、おそらくそのような機能を持たないであろう。ＶｏＩＰに関しては、それゆえ、通話相手が大声または小声で話している場合、エンドユーザは音量をかなり多く調整していそうである。アナウンスサーバが音量を確認せずにアナウンスメディアを挿入する場合、小さすぎる音量で提示されたり、とても大きな音量で提示され、聞き手が直ぐに耳から電話機を離さなければならなかったりするので、メッセージ全部が聞き洩らされるかもしれない。
【００４８】
これらの問題は、音声に限られていない。同様の問題は、オーディオおよび映像に関しても起こる。これらの問題に関して、これらのメディアタイプに対するコーデックが、典型的には、音声コーデックよりさらに高い圧縮比を有し、また、この圧縮比を達成するために、よい品質状態にさらにもっと依存するので、さらに大きな問題を予想することができる。
【００４９】
本発明の実施形態は、これらの問題の１つ以上に関連する。
【００５０】
最初に、現代の通信ネットワークの多種多様の可能なメディアコンフィグレーション（configuration：構成）によってもたらされる問題に、主に向けられている実施形態例を説明する。この問題は、アナウンスメディアの全体的な音または外観（appearance：アピアランス）が、通常のユーザメディアの音または外観と比べて非常に異なっていることになることがあるということである。これは、ユーザにとって非常に不快となり得る。
【００５１】
図４は、本発明の一例示的実施形態に従う、ユーザメディアとアナウンスメディア間の切替の基本的方法の概略のフロー図である。ユーザメディアとアナウンスメディア間の切替を効果的に処理するために、基本ステップ（Ｓ１）は、まず、ユーザメディアのコンフィグレーションを判定する。次に、提示されるアナウンスメディアのコンフィグレーションが、判定されたユーザメディアコンフィグレーションに基づいて判定される（Ｓ２）。続いて、アナウンスメディアがアナウンスメディアコンフィグレーションに従ってコンフィグレーションされ（Ｓ３）、コンフィグレーションされたアナウンスメディアが意図したユーザに最終的に送信される（Ｓ４）。このようにして、アナウンスの全体的な外観または音は、好ましくは、歪みなしに、ユーザメディアの全体的な外観または音と事実上同一または少なくとも類似することになる。これにより、ユーザに、できるだけはっきりとアナウンスを知覚させることが可能になる。例えば、ユーザメディアおよびアナウンスメディアは、音声、オーディオまたは映像であってもよい。
【００５２】
好ましくは、本発明の例示的実施形態では、ユーザメディアのコーデックコンフィグレーションが判定され、次いで、アナウンスメディアのコーデックコンフィグレーションがユーザメディアの判定されたコーデックコンフィグレーションに一致させることが好ましい。これは、アナウンスメディアに対して同一または少なくとも類似のコーデックコンフィグレーションが使用されることを意味する。こうすることにより、２つのメディアが意図したユーザに同様に聞こえるまたは同様に見える機会が増加する。例えば、コーデックコンフィグレーションは、コーデックのタイプ、コーデックモード、およびオプションでコーデックモード切替機能も含んでもよい。
【００５３】
また、ユーザメディアの伝送フォーマットコンフィグレーションを判定し、アナウンスメディアの伝送フォーマットコンフィグレーションをユーザメディアの伝送フォーマットコンフィグレーションに一致させようとすることも可能である。このようにして、アナウンスメディアは、伝送機能障害によって深刻な影響を受けなさそうである。
【００５４】
オプションとして、ユーザメディアのフレームアグリゲーションおよび冗長度フォーマットコンフィグレーションが判定され、アナウンスメディアのフレームアグリゲーションおよび冗長度フォーマットコンフィグレーションを、ユーザメディアのアナウンスメディアのフレームアグリゲーションおよび冗長度フォーマットコンフィグレーションと一致させることが可能になる。
【００５５】
図５は、本発明の別の例示的実施形態によるユーザメディアとアナウンスメディアの切替方法の概略のフロー図である。
【００５６】
好ましくは、適切なユーザメディアコンフィグレーションを選択または判定することができる、１つ以上の有効なユーザメディアコンフィグレーションを識別するために、該当ユーザのユーザ機器間のユーザメディアに対する通信セッションのセットアップがモニタされる（Ｓ１１）。続いて、有効なユーザメディアコンフィグレーションの中の現在使用されているメディアコンフィグレーションを検出するために、セッション中のユーザ通信がモニタされる（Ｓ１２）。次いで、アナウンスメディアコンフィグレーションが現在のユーザメディアコンフィグレーションに一致される（Ｓ１３）。オプションで、セッション中にアナウンスメディアを挿入する適切なタイミングが、例えば、アナウンスの緊急性を検討することによって判定される（Ｓ１４）。アナウンスサーバにコンフィグレーションされたアナウンスメディアをセッションに挿入させる（Ｓ１５）ことによって、コンフィグレーションされたアナウンスメディアは、意図したユーザに最終的に転送される。選択的には、例えば、アナウンスメディア用に新規のセッションを確立することによって、またはアナウンスメディアへのリンクを有する制御メッセージを単に送信することによって、アナウンスメディアは、ユーザメディアと並行して送信される。
【００５７】
この特定のシナリオでは、セッションの基本定義は、例えば、セッション開始プロトコル（ＳＩＰ）のセッション記述プロトコル（ＳＤＰ）を使用することによって、セッションセットアップ中に普通はネゴシエートされる。例えば、いくつかの取り得る有効なメディアコンフィグレーションは、ＳＤＰシグナリングで定義され、かつそれぞれの識別子に関連付けられてもよい。特定の例示的実施形態では、識別子として、ペイロードタイプ番号を利用することによって、メディアコンフィグレーションを識別するために、ＲＴＰパケットのペイロードタイプフィールドが使用されてもよい。この番号は、有効なメディアコンフィグレーションに関係付けることができる。ペイロードタイプ番号とメディアコンフィグレーションの関連付けは、セッションセットアップ中（例えば、ＳＩＰ ＩＮＶＩＴＥ）およびセッション再コンフィグレーション時（ＳＩＰ ＵＰＤＡＴＥ、またはいわゆるＳＩＰ ＲＥ−ＩＮＶＩＴＥ）の少なくとも一方の時点で行われるのが好ましい。その後の通信中に、ＲＴＰパケット等のメディアパケットの送信時、ペイロードタイプ番号を抽出するために、ペイロードタイプフィールドがモニタされてもよく、次いで、ペイロードタイプ番号は、現在使用されているメディアコンフィグレーションに関連付けられ得る。
【００５８】
一例として、メディアコンフィグレーションは、以下の情報項目の１つまたはいくつかによって定義され得る。
【００５９】
・コーデック（群）
例えば、ＡＭＲ、ＧＳＭ−ＥＦＲ（ＧＳＭ Ｅｎｈａｎｃｅｄ Ｆｕｌｌ Ｒａｔｅ：ＧＳＭ拡張フルレート）、ＥＶＲＣ（Ｅｎｈａｎｃｅｄ Ｖａｒｉａｂｌｅ Ｒａｔｅ Ｃｏｄｅｃ」拡張可変レートコーデック）等。
【００６０】
・コーデックモード（群）
適用可能な場合
例えば、ＡＭＲに対して、８つのコーデックモードのすべてが許容されてもよいし、またコーデックモードのサブセットが許容されてもよい。
【００６１】
・コーデックモード切替機能
適用可能な場合
例えば、ＡＭＲに対して、コーデックモード切替が隣接したコーデックモード間だけで許容されると指定されてもよい、すなわち、一例として、ビットレート１２．２、７．４、５．９および４．７５ｋｂｐｓで規定されるコーデックモード等のＡＭＲコーデックモードのサブセットが許容され、かつビットレート１２．２のコーデックモードからビットレート４．７５のコーデックモードへの切替が望まれる場合、その切替は、コーデックモード７．４および５．９を通過しなければならない。
【００６２】
・ペイロードフォーマット
適用可能な場合
例えば、ＡＭＲに対しては、帯域幅高効率およびオクテット配列（octet-aligned）の２つの基本的なオプションがある。
【００６３】
・パケット当たり推奨フレーム数
これは一般に厳格な要件ではない。
【００６４】
・パケット当たり最大データ量
これは一般に厳格な要件である。
【００６５】
それゆえ、セッションセットアップ時、様々な取り得るメディアコンフィグレーションの範囲が通常は指定される。セッションセットアップ中にネゴシエートされるメディアコンフィグレーションの中の任意のメディアコンフィグレーションを単に選択することによって、適正ではあるが、通常は次善のソリューションを取得することが可能である。いくつかの有効なメディアコンフィグレーションが許容される場合、より良いソリューションは、種々のコンフィグレーションが好ましくはどの順番で使用されるべきかを示す優先順を提供することであってもよい。例えば、例示的なコンフィグレーションＡ、ＢおよびＣが許容される場合、ＳＩＰ ＩＮＶＩＴＥの中で好ましい順番はＢ、Ｃ、Ａであると指定することができる。
【００６６】
しかしながら、ユーザ通信中にどのコンフィグレーション（群）が現在使用されているかをモニタすることによって、アナウンスメディアに対するメディアコンフィグレーションの選択を最適化することが可能である。
【００６７】
一例として、ユーザクライアントが状態の悪いチャネルを感知し、例えば、可能な最低のビットレートを使用し、かつ同一のフレームを数回送信して冗長性を加えることによってして、ロバスト性（robustness）を最大に適用させている場合、同一のまたは同様のコンフィグレーションを使用してアナウンスが処理される場合が最善となるであろう。そうでなければ、音声コーディング（符号化）に対するデフォルトコンフィグレーションは、可能な最高のビットレートで通常開始され、続いて、よりロバスト性になる方向に適応を実行することになるであろう。しかしながら、この適応は、通常は時間がかかり、ユーザメディアに対して使用されたものに対応する同一のロバスト性のレベルに適応が到達する前に、アナウンスが既に完了しているというリスクがある。本発明を使用して、現在使用されているメディアコンフィグレーションをモニタすることによって、アナウンスメディアコンフィグレーションをユーザメディアコンフィグレーションに直ぐに一致させることができる。
【００６８】
アナウンスサーバが何らかの理由でセッションセットアップ中に示される有効なメディアコンフィグレーションの一部または全部をサポートしない場合、どのメディアコンフィグレーションを使用すべきかについてのローカルでの決定は、アナウンスサーバによって許容されているコンフィグレーション（のサブセット）に基づき、アナウンスサーバで行われてもよい。
【００６９】
一般に、ユーザメディアおよびアナウンスメディアは、第１のユーザのユーザ機器等の第１のネットワーク要素を対象にしている。ユーザメディアは、通常、リモートユーザのユーザ機器等の第２のネットワーク要素から到来する。アナウンスメディアは、通常、アナウンスサーバ等の第３のネットワーク要素から到来する。しかしながら、アナウンスサーバは、ネットワークベースのアナウンスサーバとしてネットワーク側に配置されてもよいし、リモートユーザに関連するユーザ側に配置されてもよいことに留意するべきである。後者の場合、第２のネットワーク要素および第３のネットワーク要素は同一であっても良いし、または少なくとも互いに近い関係にあってもよい。本発明の種々の例示的な実施形態について説明する。
【００７０】
図６は、本発明の一例示的実施形態に従うネットワーク側およびユーザ側を含むシステム概観図である。基本的に、２人のユーザＡおよびＢのユーザ機器（ＵＥ）１０−１、１０−２が、通信ネットワークを介して通信している。この特定の例では、通信はアナウンスサーバ３０を通過し、このアナウンスサーバ３０は、適切にコンフィグレーションされたアナウンスをユーザ間の通信に挿入する。アナウンスサーバ３０は、ユーザメディアコンフィグレーションおよびアナウンスメディアコンフィグレーションの判定のためのモジュール３２と、１つ以上の事前録音アナウンスまたは機械生成アナウンスを保持するデータベース３４と、アナウンスメディアのコンフィグレーション用のモジュール３６と、ユーザメディアストリームをコンフィグレーションされたアナウンスメディアで置換するための制御可能切替機構３８とを備える。
【００７１】
好ましくは、アナウンスサーバ３０は、ユーザ間のセッションセットアップをモニタし、１つ以上の有効なユーザメディアコンフィグレーションを識別するようにコンフィグレーションされる。有効なユーザメディアコンフィグレーションについての情報は、通常、アナウンスサーバに関連するテーブル（不図示）内に関連識別子とともに記憶される。次いで、アナウンスサーバ３０は、いくつかの異なる方法でこれらのメディアコンフィグレーションの中から選択してもよい。本発明の好ましい例示的実施形態では、ユーザメディアパケットが、現在使用されているユーザメディアコンフィグレーションを識別するために、セッション中モニタされる。好ましくは、これは、１つ以上のメディアパケットのパケットヘッダからメディアコンフィグレーション識別子を抽出し、この識別子を有効なユーザメディアコンフィグレーションのテーブルに記憶されている特定のユーザメディアコンフィグレーションにマッピングすることによって実行される。
【００７２】
指定のユーザメディアコンフィグレーションについての情報に基づいて、次いで、アナウンスメディアの適切なコンフィグレーションを判定することが可能である。一旦、アナウンスメディアコンフィグレーションが判定されると、データベース３４から取得されるまたは他の手段で生成される、選択されたアナウンスが、それに応じてコンフィグレーションモジュール３６でコンフィグレーションされてもよい。これは、典型的には、判定されたコンフィグレーションに従うアナウンスメディアのエンコーディング（encoding）およびフォーマッティング（formatting）の少なくとも一方を含んでいる。次いで、アナウンスメディアは、通信セッションに挿入されてもよい。詳細は後述するが、状況に応じて、アナウンスを挿入するための適切なタイミングを判定する必要があってもよいしなくてもよい。
【００７３】
ユーザ間の通信セッション中に引き続き制御情報をモニタすることも有利なことがある。特に、コーデックモードもしくは冗長モードの変更等のユーザメディアコンフィグレーションに起こり得るいかなる変化も識別するために、リンク適応に対するフィードバック情報をモニタすることは有利なことがあり、これは、ユーザメディアコンフィグレーションについての最新情報に従ってアナウンスメディアのコンフィグレーションの適応を可能にする。
【００７４】
モニタリングは、アナウンスサーバ３０またはアナウンスサーバに関連するオプション部４０で実行されてもよい。
【００７５】
図７は、本発明の別の例示的実施形態による概観図である。この例では、ユーザメディアは、ネットワークを通してユーザの１０−１、１０−２間で送信されるが、アナウンスサーバ３０を直接通過しない。好ましくは、外部モニタ部４０がセッションセットアップおよびオプションでユーザ通信および制御フィードバックの少なくとも一方もモニタして、判定モジュール３２にユーザメディアコンフィグレーションおよびアナウンスメディアコンフィグレーションを判定させる。次いで、判定されたアナウンスメディアコンフィグレーションに従って、コンフィグレーションモジュール３６で、アナウンスデータベース３４から取得されるまたは他の手段で生成されるアナウンスがコンフィグレーションされる。次いで、コンフィグレーションされたアナウンスは、例えば、アナウンスメディア用の新規のセッションを確立するために、ＳＩＰ ＩＮＶＩＴＥ等を使用することによって、出力モジュール３８から意図したユーザへ送信されてもよい。次いで、意図したユーザ、例えば、ユーザＢは、そのユーザ機器によって複数のセッションがサポートされない限り、アナウンスメディアを生成するためにユーザＡからのユーザメディアを通常破棄しなければならない。
【００７６】
図８は、本発明のまた別の例示的実施形態による概観図である。この例では、アナウンスサーバは、ユーザ側に存在する。ユーザ間通信に対する通常の機器に加えて、ユーザＡのユーザ機器（ＵＥ）システム１０−１全体では、アナウンスサーバ（ＡＳ）またはアナウンスメディアを提供できる同等のアナウンスデバイスも備える。ユーザ機器システム全体では、メディアコンフィグレーション部（ＭＣ）をさらに備える。ユーザメディアのコンフィグレーションについての情報に基づいて、次いで、ＭＣ部は、適切なアナウンスメディアコンフィグレーションを判定し、それに応じて通話相手のユーザＢ １０−２に提示するアナウンスをコンフィグレーションする。ユーザシステム全体では、ユーザメディアからアナウンスメディアに切替、次いで切り戻ししてもよい。
【００７７】
また、別の代替実施形態では、アナウンスサーバは、エンドポイントに接続した構内交換機（ＰＢＸ）に実装される。
【００７８】
実際のところ、当該ネットワークシステムに１つを超えるアナウンスサーバがあってもよく、本発明は、第１のアナウンスサーバからのアナウンスメディアと第２のアナウンスサーバからのアナウンスメディアとの間の切替も、ユーザメディアとアナウンスメディアとの切替に対する上述の方法と同一のまたは同様の方法で処理することができる。例えば、ＵＥからのユーザメディアは、ＰＢＸのアナウンスサーバからのアナウンスメディアで置換されてもよく、ＰＢＸのアナウンスサーバからのアナウンスメディアは、ネットワークベースのアナウンスサーバからのアナウンスメディアで置換されてもよい。
【００７９】
以下では、通話相手の（人間の）ユーザからのメディアとアナウンスサーバからのメディアとの間の切替をどのように管理することができるかについての、さらなる例示的実施形態について説明する。
【００８０】
例えば、ユーザは、メディア伝送用にＩＰ、ＵＤＰおよびＲＴＰを使用し、セッション制御用にＳＩＰを使用するマルチメディアテレフォニーにかかわっていてもよい。アナウンスサーバは、電気通信ネットワークに配置されても、また遠隔（リモート）の通話相手（の位置）に配置されてもよい。
【００８１】
全体的な目標は、２つのメディアソース間およびメディアタイプ間の切替が気に障らないようにすることを保証することである。好ましくは、これは、アナウンスメディアが、ＵＥ ＡとＵＥ Ｂとの間のメディアと同様のコーデックで、同様のビットレートでエンコードされるべきであり、また、同様の伝送フォーマットを使用して伝送されるべきであることを意味する。これは、切替が歪を全く作らないかまたは少なくともできるだけ少ない歪にするべきであることも意味する。これは、以下の例示的方法で行われてもよい。
【００８２】
アナウンスサーバは、
１．セッションセットアップをモニタし、セッションでどのコーデックを使用してもよいかを判定する。これは、通常は、セッション中の静的情報であるが、任意のセッションパラメータがセッション中に再ネゴシエートされる場合、変更されてもよい。
【００８３】
２．現在使用されているコーデックおよび伝送フォーマットを判定するために、メディアパケットおよび品質フィードバックの少なくとも一方をモニタする。これは、通常かなり頻繁に更新される必要のある一時的情報であり、おそらく一つ一つのパケットごとではないが、少なくとも定期的に更新される必要がある。これらの更新の頻度は、システム負荷に依存してもよい。高システム負荷およびチャネル状態の変化の少なくとも一方に対しては、ユーザ間のメディアをかなり頻繁に適応する必要があることを予想してもよい。しかしながら、低システム負荷に対しては、適応はかなり稀なはずである。
【００８４】
３．アナウンスメディアに対する適切な符号化および伝送フォーマットを判定する。
【００８５】
４．適切な遷移をどのようにして生成するかを判定する。
【００８６】
ａ．アナウンスに、フェードインおよびフェードアウトを使用すべきかどうか。
【００８７】
ｂ．アイドル期間（無音、空白画像）を加えるべきかどうか。
【００８８】
ｃ．デコーダをリセット（コーデックホーミング（codec homing）、ＣＲＣを確実に機能しなくする等）させる必要があるかどうか。
【００８９】
５．アナウンスを挿入すべき適切なタイミングを判定する。このタイミングは、通常、アナウンスの緊急度に依存する。
【００９０】
６．アナウンスを挿入し、ＵＥ Ａからのメディアを破棄する。音量は、ＵＥ Ａからのメディアの音量と合わせるために調整される必要があってもよい。
【００９１】
７．アナウンスの完了後、ＵＥ Ａからのメディアへの適切な遷移をどのようにして生成するかについても判定する。
【００９２】
これらのステップのすべてが正確にこの順序で行われる必要はないことに留意されたい。場合によっては、これらのステップのいくつかをスキップすることも可能な場合がある。
【００９３】
本発明のより良い理解のために、あり得る好ましい実施形態に従うアナウンスサーバについて、これより図９を参照してより詳細に説明する。
【００９４】
この特定の例では、様々なブロックの機能は、以下のようにまとめることができる。
【００９５】
・ＵＥ ＡとＵＥ Ｂとの間のセッションセットアップは、ＳＩＰで行われるのが好ましい。これは、セッションでどのメディアを使用できるか、各メディアをどのようにエンコードするか、およびどの伝送フォーマットを使用すべきかを判定する。明らかにする例のいくつかは、
−メディアは、音声および／または映像および／またはテキストかどうか。
【００９６】
−各メディアに対してどのコーデックを使用すべきか。１つのメディアに対していくつかのコーデックが許容されてもよい。セッションセットアップは、例えば、ＡＭＲとＡＭＲ−ＷＢの両方とも、セッションでの音声に許容されると結論付けても良い。コーデックは、いくつかのコーデックモードも含んでいてもよい。例えば、ＡＭＲは８つのコーデックモードを定義している。各コーデックモードは、それ自体のビットレート（１２．２、１０．２、７．９５、７．４、６．７、５．９、５．１５および４．７５ｋｂｐｓ）を有する。一部の映像コーデックは、代わりに映像がどのようにエンコードされるべきかを判定する「プロファイル」および「レベル」を定義している。
【００９７】
−どのペイロードフォーマットを使用すべきか。各コーデックは、それ自体のペイロードフォーマットを有する。一部のペイロードフォーマットは、ペイロードフォーマットのいくつかの変形を定義している。例えば、ＡＭＲおよびＡＭＲ−ＷＢに対しては、ペイロードフォーマットは、帯域幅高効率フォーマットとオクテット配列フォーマットの両方を定義している。
【００９８】
−エンコーダがネゴシエートされたどのモードにもいつの時点でも自由に切替できる場合、コーデックモード切替がどのように行われてもよいか。例えば、ＵＴＲＡＮおよびＧＥＲＡＮにおけるＡＭＲに対する、回線交換サービスとの相互作用のシナリオに関しては、そのようなコーデックモードの切替は、ＵＴＲＡＮおよびＧＥＲＡＮ ＣＳの少なくとも一方のネットワークに存在する制約に合うように制限される必要がある場合もある。
【００９９】
−このように、メディアは、通常、いくつかの異なる方法でコンフィグレーションされてもよい。セッションに許容される各コンフィグレーションに対して、１つのＲＴＰペイロードタイプ番号が定義される。各メディアに対していくつかのコンフィグレーションを予想してもよいことに気付かれたい。
【０１００】
・メディア入力は、ＵＥ Ａからのメディア（音声、オーディオ、映像、テキスト等）である。選択的には、メディアは、上述のように別のアナウンスサーバからのメディアであることができよう。このメディアは、アナウンスによって中断されることになる。ＲＴＰは、通常、メディアを伝送するために使用される。
【０１０１】
・メディア出力は、ＵＥ Ｂに送信されるメディアである。
【０１０２】
・ＵＥ Ｂは、ＵＥ Ａに品質フィードバックまたは適応要求を送信する。品質フィードバックは、典型的には、ＲＴＣＰで送信され、たいていは数的指標（パケット損失率、ジッタ等）の形態である。適応要求の例には、コーデックモード要求、フレームアグリゲーション要求、冗長性要求、および映像フレームのイントラリフレッシュがある。フィードバックは、伝送機能障害のメディアへの影響を削減するために、ビットレート、パケットレートおよび冗長度を適応させるように送信者（ＵＥ Ａ）によって使用される。
【０１０３】
−適応をトリガする伝送の制約がＵＥ Ａとアナウンスサーバとの間にあるかどうか、またはそれがアナウンスサーバとＵＥ Ｂとの間にあるかどうかを知らないことに気付かれたい。しかし、アナウンスがサーバとＵＥ Ｂとの間の伝送機能障害によってひどく損なわれるリスクを最小にするために、アナウンスがＵＥ Ａからのメディアと同一の方法でエンコードされ、かつフォーマットされることは有益である。
【０１０４】
・セッションおよびメディア分析部は、セッションセットアップおよび／またはメディアおよび／またはメディアフィードバックを分析し、入力メディアの特性および現在使用されている伝送フォーマットを検出する。検出される特性の例には、以下のものがある。
【０１０５】
−メディアタイプ（群）
−コーデック（群）、コーデックレート（群）もしくはコーデックモード（群）、フレームアグリゲーション、冗長度等
−ペイロードフォーマット（群）
−メディアの音のレベル、すなわち、音量。これは、おそらくメディアのデコーディングを必要とする。休みなくデコーダを実行することを回避するために、この分析は、少ない頻度で行われるべきであり、セッション中に、１回だけかまたは２、３回程度行われるのが好ましい。
【０１０６】
−メディアがアイドル状態、例えば、無音、背景雑音、空白画像等であるかどうか。これを検出する１つの方法は、ＳＩＤ ＵＰＤＡＴＥフレームが現在送信されているかどうかを検証することであり、これには、ＲＴＰパケットを構文解析する必要がある（または少なくともサイズを点検する必要がある）が、メディアのデコーディングを必要としない。
【０１０７】
−メディアがアクティブ状態、例えば、話中の音声、動画等であるかどうか。その場合は、
・メディアが構築されているかどうか、または、例えば、音声開始直後等の開始されたばかりかどうか。
【０１０８】
・メディアがフェードアウトしていくかどうか、これは文および語の終わりで起こる。
【０１０９】
−状況次第では、この分析のすべての部分が連続的に実行される必要があるわけではない、または全く必要がないことに留意されたい。一部分は、セッションセットアップおよびセッションが再ネゴシエートされる場合だけに適用されるのに対して、他の部分はセッション中に（頻度に程度の差はあるが）モニタされるのが好ましい。この分析の一部分は、ＲＴＰパケットのデコーディングを必要としてもよい。
【０１１０】
・メディアデータベースは、実際のアナウンスメディア（音声、オーディオ、映像、画像等）を収容する。
【０１１１】
・メディアエンコーダおよびモディファイア（modifier：モディファイア）は、ＵＥ Ａからのメディアと同様にメディアをエンコードおよびフォーマットの少なくと一方を行なう能力を有し、例えば、
−様々なコーデック（ＡＭＲ、ＡＭＲ−ＷＢ、Ｈ．２６３［９］、Ｈ．２６４［１０］等）を使用してもよい。
【０１１２】
−音響帯域幅を変更してもよい（狭帯域フィルタ（filter to narrowband）、広帯域フィルタ（filter to wideband）、帯域幅拡張、スクリーンサイズ、フェードインおよびフェードアウトの適用等）。
【０１１３】
−アイドル期間（無音、空白画像）が開始および終了の少なくとも一方の時点に加えられるべきかどうか）。
【０１１４】
−デコーダをリセットさせるために、アナウンスの開始と終了にコーデックホーミング情報も追加してもよい。
【０１１５】
−ボリュームレベルを調整する。
【０１１６】
−様々なペイロードフォーマットを使用する。
【０１１７】
−ＵＥ Ａによって使用される場合、フレームアグリゲーションおよび冗長度を適用する。
【０１１８】
・アナウンスコマンドは、アナウンスサーバに以下の情報を通知する。
【０１１９】
−どのアナウンスを使用すべきか。
【０１２０】
−アナウンスの緊急性、すなわち、アナウンスをユーザに直ちに提示することがどのくらい重要であるか、またはアナウンスが少しの間遅延してもよいかどうか。
【０１２１】
・可能なメディアの変更方法のリストは、メディア分析部によって判定された、各状態に対してどのメディア変更方法が適しているかの記述である。様々な状態に対して適切な様々な動作の例について、以下に説明する。
【０１２２】
・コントローラは、アナウンスコマンド、およびＵＥ ＡとＵＥ Ｂとの間のセッションでメディアが現在どのようにフォーマットされているかについての情報を受信する。
【０１２３】
−コントローラは、メディアを送信する前に何らかの方法でそれを変更するべきである場合、メディアをどのようにエンコードすべききか、またエンコードされたメディアがＲＴＰパケットにどのようにフォーマットされるべきかを判定する。この情報は、メディアエンコーダおよびモディファイアに送信される。
【０１２４】
−コントローラは、ＵＥ Ａからのメディアがいつ中断されるか、およびアナウンスメディアがいつ挿入されるかも判定する。
【０１２５】
・緊急性が高い場合、直ちにまたはできるだけ短い遅延で、ＵＥ Ａからのメディアを中断するべきである。
【０１２６】
・緊急性が低い場合、ＵＥ Ａからのメディアにアイドル期間を検出するまで待機するべきである。
【０１２７】
アナウンスコマンドは、アナウンスもトリガする。このトリガは、背景技術セクションで例示されるように、いくつかの異なる場所から発生してもよい。追加の例としては、緊急呼が待機していることを通話者の一人に通知するために通話を中断することを要望する場合がある電話交換手、または「円滑な中断」を行うことを要望する場合があるネットワークオペレータを含んでいる。例えば、通話者の一人がサービス圏外に移動する場合、オペレータは、単にサービスを中断する代わりに、「通話相手がサービス圏外に移動しました」という種類のアナウンスを挿入したいと要望してもよい。
【０１２８】
例示的メディア符号化および変更方法
エンコーディングおよび伝送フォーマット
コントローラは、エンコーディングおよび伝送フォーマットを、ＵＥ ＡとＵＥ Ｂとの間で送信されている現在のメディアのエンコーディングおよび伝送フォーマットに一致させるべきである。
【０１２９】
・コントローラは、セッションで現在使用されているコーデック及びコーデックモード／レートと同一のコーデックおよびコーデックモード／レートを選択するべきである。
【０１３０】
−アナウンスメディアがより広い音響帯域幅を有する場合、選択されたコーデックに一致させるために帯域通過フィルタを通するべきである。
【０１３１】
−アナウンスメディアがより狭い音響帯域幅を有する場合、帯域幅拡張が適用されるべきである。
【０１３２】
−正確に同一のコーデックまたはコーデックモード／レートを選択できない場合、類似の特性（音響帯域幅、ビットレート、フレームレート、エンコーディング品質等）を有するコーデックを選択するべきである。
【０１３３】
・コントローラは、セッションで現在使用されているフレームアグリゲーション（パケット当たりフレーム数）および冗長フォーマット（数ＲＴＰパケットごとにフレームの繰り返し）と同一のフレームアグリゲーションおよび冗長フォーマットを選択するべきである。
【０１３４】
・コントローラは、セッションで現在使用されている伝送フォーマット（ＲＴＰペイロードタイプ、ペイロードフォーマット、ペイロードフォーマットバージョン）と同一の伝送フォーマットを選択するべきである。
【０１３５】
適切なエンコーディングフォーマットの選択は、２つのメディアが事実上同一のように聞こえる機会を増加する。
【０１３６】
適切な伝送フォーマットの選択は、アナウンスメディアが伝送機能障害によって深刻な影響を受けない機会を増加する。
【０１３７】
切替時の円滑な遷移
アナウンスメッセージがあまり重要でない場合で、かつアナウンスサーバが音声内にアイドル期間を検出するまでメッセージを保持している場合、異なる情報源からのメディアの途中で切り替わる場合に、特別なスムージングが必要とされるべきでない。
【０１３８】
アナウンスメッセージが非常に重要である場合、アナウンスサーバは、ＵＥ Ａからのメディアがアクティブな場合でさえ通常は中断することになるであろう。この場合、アナウンスサーバは、以下をするべきである。
【０１３９】
・ＵＥ Ａからのメディアにフェードアウトを適用する（これは常に可能ではなくてもよい）。
【０１４０】
・アナウンスメディアをフォーマットし、これが、デコーダを段階的にリセットさせるように、デコーダ状態または数フレームに対するＥＣＵの動作のリセットを、例えば、以下によりトリガするようにする。
【０１４１】
−ＡＭＲに対しては、これは、アナウンスメディアが開始する前に、コーデックホーミングフレームを挿入することによって行うことができる。他のコーデックは、同様の特性を持たない場合がある。
【０１４２】
−ＣＲＣまたはチェックサム検証を確実に失敗させる。すべてのペイロードフォーマットが、そのような情報を含むわけではない。このソリューションは、信号を十分に弱めることを確実にするために、いくつかのフレームに対して繰り返される必要がある。
【０１４３】
−不良フレームインジケータ（ＢＦＩ）ビットを設定し、これで受信機でＥＣＵの動作をトリガさせる。すべてのペイロードフォーマットがそのような情報を含むわけではない。このソリューションは、信号を十分に弱めることを確実にするために、いくつかのフレームに対して繰り返される必要がある。
【０１４４】
−ダミーフレームまたはアイドルフレーム（ＮＯ＿ＤＡＴＡ、無音、空白画像）を挿入する。ＮＯ＿ＤＡＴＡは、すべてのコーデックに対して定義されているわけではない。アナウンスサーバは、これを実現するために無音フレームを符号化しなければならない。このソリューションは、信号を十分に弱めることを確実にするために、いくつかのフレームに対して繰り返される必要がある。
【０１４５】
−これらの方法の存在はコーデックに依存するので、コントローラは、どの動作を現在使用されているコーデックに適用するか決定する必要がある。
【０１４６】
・ＵＥ Ａからのメディアの大きさと同程度になるように、アナウンスメディアの大きさを調整する。
【０１４７】
・アナウンスメディアに対してフェードインを適用する。
【０１４８】
・アナウンスメディアの送信が完了する場合で、かつＵＥ Ａからのメディアに切り戻す場合に、同様の動作が行われるべきである。
【０１４９】
スムージングは、アナウンスメディアの開始もしくは終了のどちらかまたは両方で必要とされてもよいし、また全く必要とされなくてもよいことに留意されたい。
【０１５０】
既に説明したように、本発明は、電気通信ネットワークで挿入されるアナウンスだけに限定されない。同様のアナウンスは、ほとんどの商用サービスデスクにも存在する（「切符の注文を続ける場合は１を押してください。日時の変更は２を押してください。販売スタッフと話す場合は３を押してください」）。この場合、アナウンスはリモート「ユーザ」から到来しており、また、リモート「ユーザ」は、事前録音メッセージと人間の話し手を切り替えてもよい。
【０１５１】
メディア間の切替による歪は、完全に取り除かれるまたは少なくとも減少されるであろう。アナウンスメディアのフォーマットは、会話で使用されるメディアのフォーマットに一致されることが好ましい。これは、ＵＥ Ａからのメディアとアナウンスメディアとの間でのより心地良い遷移を提供する。
【０１５２】
受信側のＵＥで、ＭＩＰＳとメモリの両方に関して複雑さの面で利点もあるが、これは、並行して実行するいくつかのアクティブコーデックインスタンスを有する必要がないからである。
【０１５３】
本発明は、ＲＴＰメディアストリームに限定されないし、伝送プロトコルとしてのＵＤＰの使用にも限定されないし、また、セッションセットアップに対するＳＩＰの使用にも限定されないことも理解されるべきである。
【０１５４】
上述の実施形態は単に例として与えられており、本発明がそれらに限定されないことは理解されるべきである。本明細書で開示され特許請求の範囲で定義されている基礎をなす基本的な原理を維持する、さらなる修正、変更および改良は、本発明の範囲内にある。
【０１５５】
略語
ＡＤＰＣＭ 適応的差分ＰＣＭ（Adaptive Differential PCM）
ＡＭＲ 適応マルチレート（Adaptive Multi-Rate）
ＡＭＲ−ＷＢ ＡＭＲ広帯域（AMR-WideBand）
ＢＦＩ 不良フレームインジケータ（Bad Frame Indicator）
ＣＲＣ 巡回冗長コード（Cyclic Redundancy Code）
ＣＳ 回線交換（Circuit Switched）
ＥＣＵ エラー隠蔽部（Error Concealment Unit）
ＥＶＲＣ 拡張可変レートコーデック（Enhanced Variable Rate Codec）
ＧＥＲＡＮ ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク（GSM Edge Radio Access Network）
ＧＳＭ 移動通信用グローバルシステム（Global System for Mobile communications）
ＧＳＭ−ＥＦＲ ＧＳＭ拡張フルレート（GSM Enhanced Full Rate）
ＩＭＳ ＩＰマルチメディアサブシステム（IP Multimedia Subsystem）
ＩＰ インターネットプロトコル（Internet Protocol）
ＭＩＰＳ １００万命令／秒（Million Instructions Per Second）
ＭＭＴｅｌ マルチメディアテレフォニー（Multi Media Telephony）
ＭＲＦＰ メディアリソース機能プロセッサ（Media Resource Function Processor）
ＰＣＭ パルス符号変調（Pulse Code Modulation）
ＰＢＸ 構内交換機（Private Branch eXchange）
ＰＳ パケット交換（Packet Switched）
ＲＴＣＰ リアルタイム制御プロトコル（Real-Time Control Protocol）
ＲＴＰ リアルタイムプロトコル（Real-Time Protocol）
ＳＤＰ セッション記述プロトコル（Session Description Protocol）
ＳＩＰ セッション開始プロトコル（Session Initiation Protocol）
ＴＤＭ 時分割多重（Time Division Multiplexing）
ＵＤＰ ユーザデータグラムプロトコル（User Datagram Protocol）
ＵＭＴＳ ユニバーサル移動通信システム（Universal Mobile Telecommunication System）
ＵＴＲＡＮ ＵＭＴＳ地上無線アクセスネットワーク（UMTS Terrestrial Radio Access Network）
ＵＥ ユーザ機器（User Equipment）
ＶｏＩＰ ボイスオーバＩＰ（Voice over IP）
参考文献
［１］ ＲＦＣ ３５５０「ＲＴＰ：リアルタイムアプリケーション用伝送プロトコル（RTP:A Transport Protocol for Real-Time Applications）」、H.Schulzrinne、S.Casner、R.Frederick、V.Jacobson著
［２］ ３ＧＰＰ ＴＳ ２３．２２８「ＩＰマルチメディアサブシステム（ＩＭＳ）ステージ２（IP Multimedia Subsystem(IMS), Stage 2）」
［３］ ＲＦＣ ３２６１「ＳＩＰ：セッション開始プロトコル（SIP:Session Initiation Protocol）」、ＲＦＣ ３２６１、２００２年６月、Rosenberg,J、Schulzrinne,H.、Camarillo,G.、Johnston,A.、Peterson,J.、Sparks,R.、Handley,M.、E.Schooler著
［４］ ＩＴＵ−Ｔ勧告Ｇ．７１１「音声周波数のパルス符号変調（ＰＣＭ）方式（Pulse Code Modulation (PCM) of Voice Frequencies）」
［５］ ＩＴＵ−Ｔ勧告Ｇ．７２６「４０、３２、２４、１６キロビット／秒適応的差分パルス符号変調（ＡＤＰＣＭ）方式（40,32,24,16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)」
［６］ ３ＧＰＰ ＴＳ ２６．１１４「ＩＰマルチメディアサブシステム（ＩＭＳ）：マルチメディアテレフォニ：メディア処理および相互作用（IP Multimedia Subsystem(IMS); Multimedia Telephony; Media handling and interaction）」
［７］ ３ＧＰＰ ＴＳ ２６．０７１「音声コーデックの必須音声処理機能：ＡＭＲ音声コーデック：一般記述（Mandatory Speech Codec speech processing functions; AMR Speech CODEC; General description）」
［８］ ３ＧＰＰ ＴＳ ２６．１７１「音声コーデックの音声処理機能：適応マルチレート広帯域（ＡＭＲ−ＷＢ）音声コーデック：一般記述（Speech codec speech processing functions; Adaptive Multi-Rate-Wideband (AMR-WB) speech codec; General description）」
［９］ ＩＴＵ−Ｔ勧告Ｈ．２６３、低ビットレート通信用ビデオ符号化方式（Video coding for low bit rate communication）
［１０］ ＩＴＵ−Ｔ勧告Ｈ．２６４、オーディオビジュアルサービス全般のための高度ビデオ符号化方式（Advanced video coding for generic audiovisual services）
【技術分野】
【０００１】
本発明は、一般的には、現代の通信ネットワークにおけるアナウンス技術（announcement technology）に関し、より詳細には、アナウンスメディアの処理と、ユーザメディアとアナウンスメディアとの切替に関係する課題とに関するものである。
【背景技術】
【０００２】
アナウンス（告知）は、テレフォニーサービス等の通信サービスにおいて重要な役割を果たす。アナウンスは、通常は、予め録音されたメディア（pre-recorded media）、または機械で生成されたメディア（machine-generated media）である。機械で生成されたメディアは、例えば、テキストを音声に変換する機能（別名、音声合成）またはテキストを画像に変換する機能で生成され得る。アナウンスは、通信ネットワーク内で生成されてもよいし、またリモートユーザの交換台またはコンピュータによって生成されてもよい。
【０００３】
通信ネットワークからのアナウンスの使用例には、以下のものを含む。
【０００４】
・ユーザが開始しているコマンドを完了できない場合のエラーメッセージ。例えば、発呼者が電話番号を非通知にしていて、電話番号を見ることなしには電話に応答しないと着呼者が設定している場合、システムは、発呼者にエラーメッセージを提示しなければならない。
【０００５】
・ユーザがセッションを保留する場合、システムは、通話相手に保留メッセージまたは保留音を再生することができる。
【０００６】
・会議電話において、新規のユーザがセッションに参加する場合またはユーザがセッションから退出する場合に、会議サーバが、例えば、「Ｊｏｈｎ Ｓｍｉｔｈ（ジョン スミス）が会議に参加しました」および「Ｊｏｈｎ Ｓｍｉｔｈが会議から退出しました」等のアナウンスを提示することができる。
【０００７】
・ユーザが料金を前払いしていて、その前払い金を使い切りそうになっている。オペレータは、残金が少ないので使用を制限してもよく、セッション開始時またはセッション中（非常に長いセッションのことがある）にそれについてアナウンスしたい。
【０００８】
・インターネットでますます使用されている方法は、ウェブページ上にピンコード（またはパスワード）を有する画像を提示することである。ピンコードの画像はかなり歪んでいるので、自動テキスト認識システムはピンコードを検出できないはずであるが、賢明な人間にとっては、それでも文字と数字を読むことができるはずである。これは、（安全でない）電子メールで、対応するピンコードを送信する代わりに使用される。
【０００９】
着呼者側のアナウンスの使用例には、以下のものがある。
【００１０】
・ユーザが旅行会社に電話してチケットを予約する。以下のシナリオが想定される。
【００１１】
１．ユーザが旅行会社のスタッフと相談して、最善の旅行プランを見つける。このステップでは、話し合いは２人の人間の間で行われる。
【００１２】
２．旅行について決定後、ユーザは、自身のクレジットカード番号をキーインするように依頼される。これは、人間と機械の通信であり、ここで、ユーザは、事前録音メッセージまたは機械生成メッセージを聞いて、ダイヤルボタン（０〜９）を押して自身のクレジットカード番号を入力する。このプロセスでは、以下の文が想定される。「あなたのクレジットカード番号をキーインしてください」、「番号は、１２３４ ５６７８ ９０１２ ３４５６ですね」、「これで正しい場合は１を押してください、正しくない場合は２を押してください」、「あなたのクレジットカードの有効期限を入力してください」、「有効期限は、２００７年１月１日ですね」。これらの文は、アナウンスサーバによって生成されるであろう。
【００１３】
３．クレジットカード番号および他の必要なデータをキーイン後、更なる旅行のオプションを決定するために、旅行会社のスタッフとのセッションは続く。
【００１４】
４．これらのステップは、複数回繰り返される場合がある。
【００１５】
・ユーザは、新しいコンピュータの購入後後のいくつかの問題を解決するために、サービスデスクまたは顧客電話窓口に電話する。サービスデスクは、スクリーニングプロセスを使用して問題を分類してから、電話を技術者に連絡する。このスクリーニングプロセスでは、ユーザは次のような質問に回答しなければならない。「お客様の問題がソフトウェア関連の場合は『１』と＃を押してください。ハードウェア関連の場合は『２』を押してください。わからない場合は『３』を押してください」。このスクリーニングプロセス後、セッションは保留され、待機メッセージがユーザに対して再生される。技術者が電話に応答してもよく、また、待機メッセージを任意の時点で中断してもよい。
【００１６】
従来、プロンプトおよび音声アナウンス等の情報メッセージの生成は、エンコーディング（encoding：符号化）およびデコーディング（decoding：復号）用の従来のパルス符号変調（ＰＣＭ）または適応的差分ＰＣＭ（ＡＤＰＣＭ）を使用する、回線交換システムの相対的に単純な時分割多重（ＴＤＭ）ベースのアナウンスマシンによって実行されている。現代および未来の通信システムでは、アナウンスを処理する条件および要件は劇的に変化するであろうから、そのような通信システムにおいてアナウンスメディアを効果的に処理するためのソリューションを提供する一般的必要性がある。
【発明の概要】
【発明が解決しようとする課題】
【００１７】
本発明は、上述および他の先行技術の装置の欠点を解決する。
【００１８】
本発明の一般的な目的は、通信ネットワーク環境におけるアナウンスメディアの処理を改良することである。
【００１９】
本発明の一目的は、遷移に伴う不快さおよび歪の少なくとも一方を伴うことなく、または少なくとも切替によって引き起こされる歪を削減するように、ユーザメディアとアナウンスメディアとの切替を効果的に処理することである。
【００２０】
特に、ユーザができるだけはっきりとアナウンスを知覚できるようにすることが望ましい。
【００２１】
特に、具体的な一目的は、ユーザメディアとアナウンスメディアとを切り替える方法およびシステムを改良し提供することである。
【００２２】
別の具体的な目的は、通信ネットワーク用のアナウンスサーバを改良し提供することである。
【課題を解決するための手段】
【００２３】
上述および他の目的は、添付の特許請求の範囲によって定義される本発明によって達成される。
【００２４】
現代の通信ネットワークがもたらす広範囲の様々なメディアコンフィグレーションにより、アナウンスメディアの全体的な音または外観が通常のユーザメディアの音または外観と比べて非常に異なることになることがあるので、それはアナウンスサーバに問題を引き起こすことがあることを、発明者たちは認識している。これは、ユーザにとって非常に不快なことがある。
【００２５】
ユーザメディアとアナウンスメディアの切替を処理するために、本発明の基本的な概念は、まず、ユーザメディアのコンフィグレーションを判定し、次いで判定したユーザメディアコンフィグレーションに基づいて、提示されるアナウンスメディアのコンフィグレーションを判定することである。続いて、アナウンスメディアをアナウンスメディアコンフィグレーションに従ってコンフィグレーションし、このコンフィグレーションされたアナウンスメディアを、意図したユーザに送信する。このようにして、アナウンスの全体的な外観または音は、ユーザメディアの全体的な外観または音と事実上同一または少なくとも類似し、好ましくは、歪がなく、ユーザができるだけはっきりとアナウンスを知覚することを可能にするであろう。
【００２６】
しかしながら、本発明が、音声やオーディオに限定されず、映像にも適用されてもよいことも理解されるべきである。
【００２７】
通常、ユーザメディアは、通話相手のリモートユーザから到来し、アナウンスメディアは、アナウンスサーバまたはプロセッサから到来する。しかしながら、アナウンスサーバは、ネットワークベースのアナウンスサーバとしてネットワーク側に配置されてもよいし、またリモートユーザに関連したユーザ側、例えば、ユーザ機器もしくは構内交換機（ＰＢＸ）内に配置されてもよい。
【００２８】
本発明の好ましい例示的実施形態では、そのユーザメディアコンフィグレーションから適切なユーザメディアコンフィグレーションを選択または他の手段で判定されてもよい、１つ以上の有効なユーザメディアコンフィグレーションを識別するために、当該ユーザ（considered users）間のユーザメディアに関する通信セッションのセットアップがモニタされる。
【００２９】
好ましくは、現在使用されているユーザメディアコンフィグレーションを検出するために、ユーザ通信がモニタされ、アナウンスメディアコンフィグレーションを現在のユーザメディアコンフィグレーションに一致（マッチング）させることを可能にする。次いで、アナウンスサーバにそのコンフィグレーションされたアナウンスメディアをセッションに挿入させることによって、コンフィグレーションされたアナウンスメディアは、意図したユーザに転送されることが好ましい。選択的には、アナウンスメディアは、例えば、アナウンスメディア用の新規のセッションを確立することによって、ユーザメディアと並行して送信される。
【００３０】
好ましくは、ユーザメディアに対するコーデックおよび／または伝送フォーマットコンフィグレーションが判定され、次いで、アナウンスメディアコンフィグレーションが、アナウンスメディアのコーデックおよび／または伝送フォーマットコンフィグレーションとユーザメディアのコーデックおよび／または伝送フォーマットコンフィグレーションとの一致（マッチング）に基づいて判定される。
【００３１】
別の態様では、本発明は、通信ネットワーク用のアナウンスサーバに関する。基本的には、アナウンスサーバは、ネットワークの通信セッションにおけるユーザメディアのコンフィグレーションを示すメディアコンフィグレーション情報を取得するように、かつメディアコンフィグレーション情報に基づいてセッションに挿入されるアナウンスメディアをコンフィグレーションするように構成される。さらに、アナウンスサーバは、コンフィグレーションされたアナウンスメディアをセッションに挿入するように動作可能である。
【００３２】
本発明によって提供される他の利点は、本発明の実施形態についての以下の説明を読むと理解されるであろう。
【００３３】
本発明の他の目的および利点とともに、本発明は、添付の図面と一緒に以下の説明を参照することにより最もよく理解されるであろう。
【図面の簡単な説明】
【００３４】
【図１】例示的システム概観を示す概略図である。
【図２】エンコーダ状態がリセットされるのに対してデコーダ状態がリセットされない場合の歪を示す概略図である。
【図３】デコーダ状態がリセットされるのに対してエンコーダ状態がリセットされない場合の歪を示す概略図である。
【図４】本発明の一例示的実施形態に従うユーザメディアとアナウンスメディアの切替の基本的方法の概略のフロー図である。
【図５】本発明の別の例示的実施形態に従うユーザメディアとアナウンスメディアの切替方法の概略のフロー図である。
【図６】本発明の一例示的実施形態に従うネットワーク側およびユーザ側を含むシステム概観図である。
【図７】本発明の別の例示的実施形態に従う概観図である。
【図８】本発明のまた別の例示的実施形態に従う概観図である。
【図９】取り得る好ましい実施形態に従うアナウンスサーバの概略のブロック図である。
【発明を実施するための形態】
【００３５】
図面全体を通して、同一の参照文字は、対応する要素または同様の要素に対して使用される。
【００３６】
本発明のより良い理解のためには、簡潔なシステム概観から始めるのが役立つであろう。
【００３７】
図１は、例示的なシステムの概観を示す概略図である。この例示的なシステムは、関連基地局２０−１、２０−２経由で通信中の２人のエンドユーザＡおよびＢのユーザ機器（ＵＥ）１０−１、１０−２と、ネットワークベースのアナウンスサーバ３０とを有する。この場合、リアルタイムプロトコル（ＲＴＰ）［１］メディアストリーム等のメディアストリームは、メディアリソース機能プロセッサ（ＭＲＦＰ）［２］でもよいアナウンスサーバを常に通過する。この例では、アナウンスサーバは、ユーザＡからのＲＴＰストリームをアナウンスに置換する、これは、インバンドアナウンス（in-band announcement：帯域内アナウンス）と呼ばれる。
【００３８】
アナウンスを導入する他の方法も可能であり、例えば、アナウンスサーバを通過することなく、メディアがＡとＢの間で直接送信されるものがある。この場合、アナウンスは、アナウンスサーバからＵＥ（ユーザ機器）ＢへＳＩＰ ＩＮＶＩＴＥで送信されてもよく、ＵＥ Ｂは、アナウンスサーバから受信されるメディアを生成するために、ＵＥ Ａから受信されるメディアを破棄しなければならない。別の代替方法としては、アナウンスメディアへのリンク（ＵＲＬ）を含むＳＩＰ ＩＮＦＯまたはＳＩＰ ＮＯＴＩＦＹメッセージ等のメッセージを送信することである。一般に、代替方法は、このように、アナウンスメディア用に新規のセッションを確立してまたは確立せずに、ユーザメディアに並行してアナウンスメディアを送信することである。
【００３９】
アナウンスサーバは、通信ネットワーク内に設置されてもよい。ＩＰマルチメディアサブシステム（ＩＭＳ）等の現代のシステムでは、アナウンスサーバは、メディアリソース機能プロセッサ（ＭＲＦＰ）内に通常設置されるであろうが、例えば、会議サーバ等のアプリケーションサーバにも設置できよう。
【００４０】
アナウンスサーバを、エンドポイント内もしくはエンドポイント近くに、ユーザ機器内に、コンピュータ内に、または構内交換機（ＰＢＸ）内に有することも可能である。
【００４１】
発明者たちによる入念な分析で、既存のソリューションは、以下に説明する１つ以上の問題に晒されていることが明らかになっている。
【００４２】
現在のところ既存の回線交換システムでは、アナウンスが機能しているが、これは、使用されるコーデックが典型的にはＰＣＭ［４］またはＡＤＰＣＭ［５］であるからうまく機能しているのである。これらのコーデックは、予測を全く使用しない（ＰＣＭ）、または非常に限られた量の予測しか使用しない（ＡＤＰＣＭ）、サンプル単位のコーデックである。これは、デコーダが状態不一致から非常に急激に回復すると、聞き取れる歪を引き起こす可能性が低いことを意味する。
【００４３】
さらに、従来のシステムは、コーデックを１つだけ使用する、例えば、ＰＣＭまたはＡＤＰＣＭのどちらかを使用するのであって、決して両方を使用しない。システムは、全セッション中に、同一の伝送フォーマットも使用し、例えば、コーデックレート、フレームアグリゲーション（frame aggregation：フレーム集約）、または冗長度を決して状況に応じて変化させない。実際のところ、システムは、すべてのセッションに対して同一の構成を使用する。
【００４４】
ＩＰマルチメディアサブシステム（ＩＭＳ）等の現代および将来のシステムでは、その中でも特にマルチメディアテレフォニ（ＭＭＴｅｌ）［６］に関しては、状況は完全に異なる。数種類のメディアを送信することが可能である。このメディアは、異なるコーデックでかつ異なるレートで符号化され得る。異なる伝送フォーマットが使用される可能性がある。すなわち、ペイロードフォーマットが、フレームアグリゲーションありでまたはなしで、冗長度ありでまたはなしでも、使用される得る。これらの変形は、ネットワーク輻輳に対するリスクを減らし、輻輳期間中でさえ合理的な品質でセッションを維持できるようにセッションを適応させるために必要である。これは、無線チャネルが大幅に変化するセルラ方式では特に重要である。しかしながら、これらの変形は、アナウンスサーバに対して問題を引き起こす。以前したような１つの方法だけでアナウンスメディアを符号化し、受信者が満足することを望むことはできない。ＵＥ ＡとＵＥ Ｂとの間のメディアは、通常、広帯域コーデック（ＡＭＲ−ＷＢ）で符号化されているが、アナウンスを狭帯域コーデック（適応マルチレート：ＡＭＲ）で符号化する場合、メディアは全く異なって聞こえるであろうし、受信ユーザは、アナウンスが通常のメディアとはなぜ大幅に異なって聞こえるのか疑問に感じるであろう。最悪の場合、受信ユーザは、不快になりアナウンスの実際の内容よりメディア品質に関心が行ってしまうかもしれず、これは、ユーザがアナウンスを誤解さえしかねないことを意味する。
【００４５】
さらに、現代の予測ベースのコーデックの使用は、アナウンスが通常のメディアを中断する場合に、状態不一致をもたらすことがあり、同様に、ユーザを不快にさせることがある聞き取り可能な歪を生じる可能性がある。予測は、例えば、ＡＭＲ［７］またはＡＭＲ−ＷＢ［８］等の現代のコーデックに関しては非常に重要である。フレーム間予測は、ビットレートを減少させるために、すなわち、高圧縮比にするために使用されるが、それでもよい品質を提供する。フレーム間予測では、フレームからフレームへ状態が渡される必要がある。アナウンスが通常のメディアを中断する場合、ユーザからの音声メディアに対するＵＥ Ａの１つのコーデックインスタンスと、アナウンスサーバの１つのコーデックインスタンスとの２つの異なるコーデックインスタンスが使用されるので、状態不一致となるであろう。ＵＥ Ａの状態は、使用される予測に従って進展しているのに対して、アナウンスサーバの状態は、初期設定状態から開始する。状態不一致は、現在のコンテンツに依存して、多かれ少なかれ聞き取れる歪を引き起こし得るる。そのような歪の２つの例が、図２および図３に示されている。両方の場合とも歪は、はっきり聞き取れ、聞き手によって容易に気付かれるが、図２のスパイクの方がはるかに気に障る。
【００４６】
図２および３からは、非同期のリセット後、合成音が正常な状態に回復させるためには、約１００〜２００ｍｓかかることを把握することができる。その代わりに、ＰＣＭ等のステートレス（state-less）コーデックは、状態（ステート）を適切なコンテンツに「作り上げる」必要がないので、直ぐに正常な状態に戻るであろう。
【００４７】
従来の回線交換システムは、典型的には、音量レベルの制御も有しており、音量が適切でない場合、ネットワーク内で音量を調節する。マルチメディアテレフォニのようなＶｏＩＰシステムは、着想が変換（transcoding：トランスコーディング）および他の種類の変更なしにＶｏＩＰパケットをエンドツーエンドで送信するものなので、おそらくそのような機能を持たないであろう。ＶｏＩＰに関しては、それゆえ、通話相手が大声または小声で話している場合、エンドユーザは音量をかなり多く調整していそうである。アナウンスサーバが音量を確認せずにアナウンスメディアを挿入する場合、小さすぎる音量で提示されたり、とても大きな音量で提示され、聞き手が直ぐに耳から電話機を離さなければならなかったりするので、メッセージ全部が聞き洩らされるかもしれない。
【００４８】
これらの問題は、音声に限られていない。同様の問題は、オーディオおよび映像に関しても起こる。これらの問題に関して、これらのメディアタイプに対するコーデックが、典型的には、音声コーデックよりさらに高い圧縮比を有し、また、この圧縮比を達成するために、よい品質状態にさらにもっと依存するので、さらに大きな問題を予想することができる。
【００４９】
本発明の実施形態は、これらの問題の１つ以上に関連する。
【００５０】
最初に、現代の通信ネットワークの多種多様の可能なメディアコンフィグレーション（configuration：構成）によってもたらされる問題に、主に向けられている実施形態例を説明する。この問題は、アナウンスメディアの全体的な音または外観（appearance：アピアランス）が、通常のユーザメディアの音または外観と比べて非常に異なっていることになることがあるということである。これは、ユーザにとって非常に不快となり得る。
【００５１】
図４は、本発明の一例示的実施形態に従う、ユーザメディアとアナウンスメディア間の切替の基本的方法の概略のフロー図である。ユーザメディアとアナウンスメディア間の切替を効果的に処理するために、基本ステップ（Ｓ１）は、まず、ユーザメディアのコンフィグレーションを判定する。次に、提示されるアナウンスメディアのコンフィグレーションが、判定されたユーザメディアコンフィグレーションに基づいて判定される（Ｓ２）。続いて、アナウンスメディアがアナウンスメディアコンフィグレーションに従ってコンフィグレーションされ（Ｓ３）、コンフィグレーションされたアナウンスメディアが意図したユーザに最終的に送信される（Ｓ４）。このようにして、アナウンスの全体的な外観または音は、好ましくは、歪みなしに、ユーザメディアの全体的な外観または音と事実上同一または少なくとも類似することになる。これにより、ユーザに、できるだけはっきりとアナウンスを知覚させることが可能になる。例えば、ユーザメディアおよびアナウンスメディアは、音声、オーディオまたは映像であってもよい。
【００５２】
好ましくは、本発明の例示的実施形態では、ユーザメディアのコーデックコンフィグレーションが判定され、次いで、アナウンスメディアのコーデックコンフィグレーションがユーザメディアの判定されたコーデックコンフィグレーションに一致させることが好ましい。これは、アナウンスメディアに対して同一または少なくとも類似のコーデックコンフィグレーションが使用されることを意味する。こうすることにより、２つのメディアが意図したユーザに同様に聞こえるまたは同様に見える機会が増加する。例えば、コーデックコンフィグレーションは、コーデックのタイプ、コーデックモード、およびオプションでコーデックモード切替機能も含んでもよい。
【００５３】
また、ユーザメディアの伝送フォーマットコンフィグレーションを判定し、アナウンスメディアの伝送フォーマットコンフィグレーションをユーザメディアの伝送フォーマットコンフィグレーションに一致させようとすることも可能である。このようにして、アナウンスメディアは、伝送機能障害によって深刻な影響を受けなさそうである。
【００５４】
オプションとして、ユーザメディアのフレームアグリゲーションおよび冗長度フォーマットコンフィグレーションが判定され、アナウンスメディアのフレームアグリゲーションおよび冗長度フォーマットコンフィグレーションを、ユーザメディアのアナウンスメディアのフレームアグリゲーションおよび冗長度フォーマットコンフィグレーションと一致させることが可能になる。
【００５５】
図５は、本発明の別の例示的実施形態によるユーザメディアとアナウンスメディアの切替方法の概略のフロー図である。
【００５６】
好ましくは、適切なユーザメディアコンフィグレーションを選択または判定することができる、１つ以上の有効なユーザメディアコンフィグレーションを識別するために、該当ユーザのユーザ機器間のユーザメディアに対する通信セッションのセットアップがモニタされる（Ｓ１１）。続いて、有効なユーザメディアコンフィグレーションの中の現在使用されているメディアコンフィグレーションを検出するために、セッション中のユーザ通信がモニタされる（Ｓ１２）。次いで、アナウンスメディアコンフィグレーションが現在のユーザメディアコンフィグレーションに一致される（Ｓ１３）。オプションで、セッション中にアナウンスメディアを挿入する適切なタイミングが、例えば、アナウンスの緊急性を検討することによって判定される（Ｓ１４）。アナウンスサーバにコンフィグレーションされたアナウンスメディアをセッションに挿入させる（Ｓ１５）ことによって、コンフィグレーションされたアナウンスメディアは、意図したユーザに最終的に転送される。選択的には、例えば、アナウンスメディア用に新規のセッションを確立することによって、またはアナウンスメディアへのリンクを有する制御メッセージを単に送信することによって、アナウンスメディアは、ユーザメディアと並行して送信される。
【００５７】
この特定のシナリオでは、セッションの基本定義は、例えば、セッション開始プロトコル（ＳＩＰ）のセッション記述プロトコル（ＳＤＰ）を使用することによって、セッションセットアップ中に普通はネゴシエートされる。例えば、いくつかの取り得る有効なメディアコンフィグレーションは、ＳＤＰシグナリングで定義され、かつそれぞれの識別子に関連付けられてもよい。特定の例示的実施形態では、識別子として、ペイロードタイプ番号を利用することによって、メディアコンフィグレーションを識別するために、ＲＴＰパケットのペイロードタイプフィールドが使用されてもよい。この番号は、有効なメディアコンフィグレーションに関係付けることができる。ペイロードタイプ番号とメディアコンフィグレーションの関連付けは、セッションセットアップ中（例えば、ＳＩＰ ＩＮＶＩＴＥ）およびセッション再コンフィグレーション時（ＳＩＰ ＵＰＤＡＴＥ、またはいわゆるＳＩＰ ＲＥ−ＩＮＶＩＴＥ）の少なくとも一方の時点で行われるのが好ましい。その後の通信中に、ＲＴＰパケット等のメディアパケットの送信時、ペイロードタイプ番号を抽出するために、ペイロードタイプフィールドがモニタされてもよく、次いで、ペイロードタイプ番号は、現在使用されているメディアコンフィグレーションに関連付けられ得る。
【００５８】
一例として、メディアコンフィグレーションは、以下の情報項目の１つまたはいくつかによって定義され得る。
【００５９】
・コーデック（群）
例えば、ＡＭＲ、ＧＳＭ−ＥＦＲ（ＧＳＭ Ｅｎｈａｎｃｅｄ Ｆｕｌｌ Ｒａｔｅ：ＧＳＭ拡張フルレート）、ＥＶＲＣ（Ｅｎｈａｎｃｅｄ Ｖａｒｉａｂｌｅ Ｒａｔｅ Ｃｏｄｅｃ」拡張可変レートコーデック）等。
【００６０】
・コーデックモード（群）
適用可能な場合
例えば、ＡＭＲに対して、８つのコーデックモードのすべてが許容されてもよいし、またコーデックモードのサブセットが許容されてもよい。
【００６１】
・コーデックモード切替機能
適用可能な場合
例えば、ＡＭＲに対して、コーデックモード切替が隣接したコーデックモード間だけで許容されると指定されてもよい、すなわち、一例として、ビットレート１２．２、７．４、５．９および４．７５ｋｂｐｓで規定されるコーデックモード等のＡＭＲコーデックモードのサブセットが許容され、かつビットレート１２．２のコーデックモードからビットレート４．７５のコーデックモードへの切替が望まれる場合、その切替は、コーデックモード７．４および５．９を通過しなければならない。
【００６２】
・ペイロードフォーマット
適用可能な場合
例えば、ＡＭＲに対しては、帯域幅高効率およびオクテット配列（octet-aligned）の２つの基本的なオプションがある。
【００６３】
・パケット当たり推奨フレーム数
これは一般に厳格な要件ではない。
【００６４】
・パケット当たり最大データ量
これは一般に厳格な要件である。
【００６５】
それゆえ、セッションセットアップ時、様々な取り得るメディアコンフィグレーションの範囲が通常は指定される。セッションセットアップ中にネゴシエートされるメディアコンフィグレーションの中の任意のメディアコンフィグレーションを単に選択することによって、適正ではあるが、通常は次善のソリューションを取得することが可能である。いくつかの有効なメディアコンフィグレーションが許容される場合、より良いソリューションは、種々のコンフィグレーションが好ましくはどの順番で使用されるべきかを示す優先順を提供することであってもよい。例えば、例示的なコンフィグレーションＡ、ＢおよびＣが許容される場合、ＳＩＰ ＩＮＶＩＴＥの中で好ましい順番はＢ、Ｃ、Ａであると指定することができる。
【００６６】
しかしながら、ユーザ通信中にどのコンフィグレーション（群）が現在使用されているかをモニタすることによって、アナウンスメディアに対するメディアコンフィグレーションの選択を最適化することが可能である。
【００６７】
一例として、ユーザクライアントが状態の悪いチャネルを感知し、例えば、可能な最低のビットレートを使用し、かつ同一のフレームを数回送信して冗長性を加えることによってして、ロバスト性（robustness）を最大に適用させている場合、同一のまたは同様のコンフィグレーションを使用してアナウンスが処理される場合が最善となるであろう。そうでなければ、音声コーディング（符号化）に対するデフォルトコンフィグレーションは、可能な最高のビットレートで通常開始され、続いて、よりロバスト性になる方向に適応を実行することになるであろう。しかしながら、この適応は、通常は時間がかかり、ユーザメディアに対して使用されたものに対応する同一のロバスト性のレベルに適応が到達する前に、アナウンスが既に完了しているというリスクがある。本発明を使用して、現在使用されているメディアコンフィグレーションをモニタすることによって、アナウンスメディアコンフィグレーションをユーザメディアコンフィグレーションに直ぐに一致させることができる。
【００６８】
アナウンスサーバが何らかの理由でセッションセットアップ中に示される有効なメディアコンフィグレーションの一部または全部をサポートしない場合、どのメディアコンフィグレーションを使用すべきかについてのローカルでの決定は、アナウンスサーバによって許容されているコンフィグレーション（のサブセット）に基づき、アナウンスサーバで行われてもよい。
【００６９】
一般に、ユーザメディアおよびアナウンスメディアは、第１のユーザのユーザ機器等の第１のネットワーク要素を対象にしている。ユーザメディアは、通常、リモートユーザのユーザ機器等の第２のネットワーク要素から到来する。アナウンスメディアは、通常、アナウンスサーバ等の第３のネットワーク要素から到来する。しかしながら、アナウンスサーバは、ネットワークベースのアナウンスサーバとしてネットワーク側に配置されてもよいし、リモートユーザに関連するユーザ側に配置されてもよいことに留意するべきである。後者の場合、第２のネットワーク要素および第３のネットワーク要素は同一であっても良いし、または少なくとも互いに近い関係にあってもよい。本発明の種々の例示的な実施形態について説明する。
【００７０】
図６は、本発明の一例示的実施形態に従うネットワーク側およびユーザ側を含むシステム概観図である。基本的に、２人のユーザＡおよびＢのユーザ機器（ＵＥ）１０−１、１０−２が、通信ネットワークを介して通信している。この特定の例では、通信はアナウンスサーバ３０を通過し、このアナウンスサーバ３０は、適切にコンフィグレーションされたアナウンスをユーザ間の通信に挿入する。アナウンスサーバ３０は、ユーザメディアコンフィグレーションおよびアナウンスメディアコンフィグレーションの判定のためのモジュール３２と、１つ以上の事前録音アナウンスまたは機械生成アナウンスを保持するデータベース３４と、アナウンスメディアのコンフィグレーション用のモジュール３６と、ユーザメディアストリームをコンフィグレーションされたアナウンスメディアで置換するための制御可能切替機構３８とを備える。
【００７１】
好ましくは、アナウンスサーバ３０は、ユーザ間のセッションセットアップをモニタし、１つ以上の有効なユーザメディアコンフィグレーションを識別するようにコンフィグレーションされる。有効なユーザメディアコンフィグレーションについての情報は、通常、アナウンスサーバに関連するテーブル（不図示）内に関連識別子とともに記憶される。次いで、アナウンスサーバ３０は、いくつかの異なる方法でこれらのメディアコンフィグレーションの中から選択してもよい。本発明の好ましい例示的実施形態では、ユーザメディアパケットが、現在使用されているユーザメディアコンフィグレーションを識別するために、セッション中モニタされる。好ましくは、これは、１つ以上のメディアパケットのパケットヘッダからメディアコンフィグレーション識別子を抽出し、この識別子を有効なユーザメディアコンフィグレーションのテーブルに記憶されている特定のユーザメディアコンフィグレーションにマッピングすることによって実行される。
【００７２】
指定のユーザメディアコンフィグレーションについての情報に基づいて、次いで、アナウンスメディアの適切なコンフィグレーションを判定することが可能である。一旦、アナウンスメディアコンフィグレーションが判定されると、データベース３４から取得されるまたは他の手段で生成される、選択されたアナウンスが、それに応じてコンフィグレーションモジュール３６でコンフィグレーションされてもよい。これは、典型的には、判定されたコンフィグレーションに従うアナウンスメディアのエンコーディング（encoding）およびフォーマッティング（formatting）の少なくとも一方を含んでいる。次いで、アナウンスメディアは、通信セッションに挿入されてもよい。詳細は後述するが、状況に応じて、アナウンスを挿入するための適切なタイミングを判定する必要があってもよいしなくてもよい。
【００７３】
ユーザ間の通信セッション中に引き続き制御情報をモニタすることも有利なことがある。特に、コーデックモードもしくは冗長モードの変更等のユーザメディアコンフィグレーションに起こり得るいかなる変化も識別するために、リンク適応に対するフィードバック情報をモニタすることは有利なことがあり、これは、ユーザメディアコンフィグレーションについての最新情報に従ってアナウンスメディアのコンフィグレーションの適応を可能にする。
【００７４】
モニタリングは、アナウンスサーバ３０またはアナウンスサーバに関連するオプション部４０で実行されてもよい。
【００７５】
図７は、本発明の別の例示的実施形態による概観図である。この例では、ユーザメディアは、ネットワークを通してユーザの１０−１、１０−２間で送信されるが、アナウンスサーバ３０を直接通過しない。好ましくは、外部モニタ部４０がセッションセットアップおよびオプションでユーザ通信および制御フィードバックの少なくとも一方もモニタして、判定モジュール３２にユーザメディアコンフィグレーションおよびアナウンスメディアコンフィグレーションを判定させる。次いで、判定されたアナウンスメディアコンフィグレーションに従って、コンフィグレーションモジュール３６で、アナウンスデータベース３４から取得されるまたは他の手段で生成されるアナウンスがコンフィグレーションされる。次いで、コンフィグレーションされたアナウンスは、例えば、アナウンスメディア用の新規のセッションを確立するために、ＳＩＰ ＩＮＶＩＴＥ等を使用することによって、出力モジュール３８から意図したユーザへ送信されてもよい。次いで、意図したユーザ、例えば、ユーザＢは、そのユーザ機器によって複数のセッションがサポートされない限り、アナウンスメディアを生成するためにユーザＡからのユーザメディアを通常破棄しなければならない。
【００７６】
図８は、本発明のまた別の例示的実施形態による概観図である。この例では、アナウンスサーバは、ユーザ側に存在する。ユーザ間通信に対する通常の機器に加えて、ユーザＡのユーザ機器（ＵＥ）システム１０−１全体では、アナウンスサーバ（ＡＳ）またはアナウンスメディアを提供できる同等のアナウンスデバイスも備える。ユーザ機器システム全体では、メディアコンフィグレーション部（ＭＣ）をさらに備える。ユーザメディアのコンフィグレーションについての情報に基づいて、次いで、ＭＣ部は、適切なアナウンスメディアコンフィグレーションを判定し、それに応じて通話相手のユーザＢ １０−２に提示するアナウンスをコンフィグレーションする。ユーザシステム全体では、ユーザメディアからアナウンスメディアに切替、次いで切り戻ししてもよい。
【００７７】
また、別の代替実施形態では、アナウンスサーバは、エンドポイントに接続した構内交換機（ＰＢＸ）に実装される。
【００７８】
実際のところ、当該ネットワークシステムに１つを超えるアナウンスサーバがあってもよく、本発明は、第１のアナウンスサーバからのアナウンスメディアと第２のアナウンスサーバからのアナウンスメディアとの間の切替も、ユーザメディアとアナウンスメディアとの切替に対する上述の方法と同一のまたは同様の方法で処理することができる。例えば、ＵＥからのユーザメディアは、ＰＢＸのアナウンスサーバからのアナウンスメディアで置換されてもよく、ＰＢＸのアナウンスサーバからのアナウンスメディアは、ネットワークベースのアナウンスサーバからのアナウンスメディアで置換されてもよい。
【００７９】
以下では、通話相手の（人間の）ユーザからのメディアとアナウンスサーバからのメディアとの間の切替をどのように管理することができるかについての、さらなる例示的実施形態について説明する。
【００８０】
例えば、ユーザは、メディア伝送用にＩＰ、ＵＤＰおよびＲＴＰを使用し、セッション制御用にＳＩＰを使用するマルチメディアテレフォニーにかかわっていてもよい。アナウンスサーバは、電気通信ネットワークに配置されても、また遠隔（リモート）の通話相手（の位置）に配置されてもよい。
【００８１】
全体的な目標は、２つのメディアソース間およびメディアタイプ間の切替が気に障らないようにすることを保証することである。好ましくは、これは、アナウンスメディアが、ＵＥ ＡとＵＥ Ｂとの間のメディアと同様のコーデックで、同様のビットレートでエンコードされるべきであり、また、同様の伝送フォーマットを使用して伝送されるべきであることを意味する。これは、切替が歪を全く作らないかまたは少なくともできるだけ少ない歪にするべきであることも意味する。これは、以下の例示的方法で行われてもよい。
【００８２】
アナウンスサーバは、
１．セッションセットアップをモニタし、セッションでどのコーデックを使用してもよいかを判定する。これは、通常は、セッション中の静的情報であるが、任意のセッションパラメータがセッション中に再ネゴシエートされる場合、変更されてもよい。
【００８３】
２．現在使用されているコーデックおよび伝送フォーマットを判定するために、メディアパケットおよび品質フィードバックの少なくとも一方をモニタする。これは、通常かなり頻繁に更新される必要のある一時的情報であり、おそらく一つ一つのパケットごとではないが、少なくとも定期的に更新される必要がある。これらの更新の頻度は、システム負荷に依存してもよい。高システム負荷およびチャネル状態の変化の少なくとも一方に対しては、ユーザ間のメディアをかなり頻繁に適応する必要があることを予想してもよい。しかしながら、低システム負荷に対しては、適応はかなり稀なはずである。
【００８４】
３．アナウンスメディアに対する適切な符号化および伝送フォーマットを判定する。
【００８５】
４．適切な遷移をどのようにして生成するかを判定する。
【００８６】
ａ．アナウンスに、フェードインおよびフェードアウトを使用すべきかどうか。
【００８７】
ｂ．アイドル期間（無音、空白画像）を加えるべきかどうか。
【００８８】
ｃ．デコーダをリセット（コーデックホーミング（codec homing）、ＣＲＣを確実に機能しなくする等）させる必要があるかどうか。
【００８９】
５．アナウンスを挿入すべき適切なタイミングを判定する。このタイミングは、通常、アナウンスの緊急度に依存する。
【００９０】
６．アナウンスを挿入し、ＵＥ Ａからのメディアを破棄する。音量は、ＵＥ Ａからのメディアの音量と合わせるために調整される必要があってもよい。
【００９１】
７．アナウンスの完了後、ＵＥ Ａからのメディアへの適切な遷移をどのようにして生成するかについても判定する。
【００９２】
これらのステップのすべてが正確にこの順序で行われる必要はないことに留意されたい。場合によっては、これらのステップのいくつかをスキップすることも可能な場合がある。
【００９３】
本発明のより良い理解のために、あり得る好ましい実施形態に従うアナウンスサーバについて、これより図９を参照してより詳細に説明する。
【００９４】
この特定の例では、様々なブロックの機能は、以下のようにまとめることができる。
【００９５】
・ＵＥ ＡとＵＥ Ｂとの間のセッションセットアップは、ＳＩＰで行われるのが好ましい。これは、セッションでどのメディアを使用できるか、各メディアをどのようにエンコードするか、およびどの伝送フォーマットを使用すべきかを判定する。明らかにする例のいくつかは、
−メディアは、音声および／または映像および／またはテキストかどうか。
【００９６】
−各メディアに対してどのコーデックを使用すべきか。１つのメディアに対していくつかのコーデックが許容されてもよい。セッションセットアップは、例えば、ＡＭＲとＡＭＲ−ＷＢの両方とも、セッションでの音声に許容されると結論付けても良い。コーデックは、いくつかのコーデックモードも含んでいてもよい。例えば、ＡＭＲは８つのコーデックモードを定義している。各コーデックモードは、それ自体のビットレート（１２．２、１０．２、７．９５、７．４、６．７、５．９、５．１５および４．７５ｋｂｐｓ）を有する。一部の映像コーデックは、代わりに映像がどのようにエンコードされるべきかを判定する「プロファイル」および「レベル」を定義している。
【００９７】
−どのペイロードフォーマットを使用すべきか。各コーデックは、それ自体のペイロードフォーマットを有する。一部のペイロードフォーマットは、ペイロードフォーマットのいくつかの変形を定義している。例えば、ＡＭＲおよびＡＭＲ−ＷＢに対しては、ペイロードフォーマットは、帯域幅高効率フォーマットとオクテット配列フォーマットの両方を定義している。
【００９８】
−エンコーダがネゴシエートされたどのモードにもいつの時点でも自由に切替できる場合、コーデックモード切替がどのように行われてもよいか。例えば、ＵＴＲＡＮおよびＧＥＲＡＮにおけるＡＭＲに対する、回線交換サービスとの相互作用のシナリオに関しては、そのようなコーデックモードの切替は、ＵＴＲＡＮおよびＧＥＲＡＮ ＣＳの少なくとも一方のネットワークに存在する制約に合うように制限される必要がある場合もある。
【００９９】
−このように、メディアは、通常、いくつかの異なる方法でコンフィグレーションされてもよい。セッションに許容される各コンフィグレーションに対して、１つのＲＴＰペイロードタイプ番号が定義される。各メディアに対していくつかのコンフィグレーションを予想してもよいことに気付かれたい。
【０１００】
・メディア入力は、ＵＥ Ａからのメディア（音声、オーディオ、映像、テキスト等）である。選択的には、メディアは、上述のように別のアナウンスサーバからのメディアであることができよう。このメディアは、アナウンスによって中断されることになる。ＲＴＰは、通常、メディアを伝送するために使用される。
【０１０１】
・メディア出力は、ＵＥ Ｂに送信されるメディアである。
【０１０２】
・ＵＥ Ｂは、ＵＥ Ａに品質フィードバックまたは適応要求を送信する。品質フィードバックは、典型的には、ＲＴＣＰで送信され、たいていは数的指標（パケット損失率、ジッタ等）の形態である。適応要求の例には、コーデックモード要求、フレームアグリゲーション要求、冗長性要求、および映像フレームのイントラリフレッシュがある。フィードバックは、伝送機能障害のメディアへの影響を削減するために、ビットレート、パケットレートおよび冗長度を適応させるように送信者（ＵＥ Ａ）によって使用される。
【０１０３】
−適応をトリガする伝送の制約がＵＥ Ａとアナウンスサーバとの間にあるかどうか、またはそれがアナウンスサーバとＵＥ Ｂとの間にあるかどうかを知らないことに気付かれたい。しかし、アナウンスがサーバとＵＥ Ｂとの間の伝送機能障害によってひどく損なわれるリスクを最小にするために、アナウンスがＵＥ Ａからのメディアと同一の方法でエンコードされ、かつフォーマットされることは有益である。
【０１０４】
・セッションおよびメディア分析部は、セッションセットアップおよび／またはメディアおよび／またはメディアフィードバックを分析し、入力メディアの特性および現在使用されている伝送フォーマットを検出する。検出される特性の例には、以下のものがある。
【０１０５】
−メディアタイプ（群）
−コーデック（群）、コーデックレート（群）もしくはコーデックモード（群）、フレームアグリゲーション、冗長度等
−ペイロードフォーマット（群）
−メディアの音のレベル、すなわち、音量。これは、おそらくメディアのデコーディングを必要とする。休みなくデコーダを実行することを回避するために、この分析は、少ない頻度で行われるべきであり、セッション中に、１回だけかまたは２、３回程度行われるのが好ましい。
【０１０６】
−メディアがアイドル状態、例えば、無音、背景雑音、空白画像等であるかどうか。これを検出する１つの方法は、ＳＩＤ ＵＰＤＡＴＥフレームが現在送信されているかどうかを検証することであり、これには、ＲＴＰパケットを構文解析する必要がある（または少なくともサイズを点検する必要がある）が、メディアのデコーディングを必要としない。
【０１０７】
−メディアがアクティブ状態、例えば、話中の音声、動画等であるかどうか。その場合は、
・メディアが構築されているかどうか、または、例えば、音声開始直後等の開始されたばかりかどうか。
【０１０８】
・メディアがフェードアウトしていくかどうか、これは文および語の終わりで起こる。
【０１０９】
−状況次第では、この分析のすべての部分が連続的に実行される必要があるわけではない、または全く必要がないことに留意されたい。一部分は、セッションセットアップおよびセッションが再ネゴシエートされる場合だけに適用されるのに対して、他の部分はセッション中に（頻度に程度の差はあるが）モニタされるのが好ましい。この分析の一部分は、ＲＴＰパケットのデコーディングを必要としてもよい。
【０１１０】
・メディアデータベースは、実際のアナウンスメディア（音声、オーディオ、映像、画像等）を収容する。
【０１１１】
・メディアエンコーダおよびモディファイア（modifier：モディファイア）は、ＵＥ Ａからのメディアと同様にメディアをエンコードおよびフォーマットの少なくと一方を行なう能力を有し、例えば、
−様々なコーデック（ＡＭＲ、ＡＭＲ−ＷＢ、Ｈ．２６３［９］、Ｈ．２６４［１０］等）を使用してもよい。
【０１１２】
−音響帯域幅を変更してもよい（狭帯域フィルタ（filter to narrowband）、広帯域フィルタ（filter to wideband）、帯域幅拡張、スクリーンサイズ、フェードインおよびフェードアウトの適用等）。
【０１１３】
−アイドル期間（無音、空白画像）が開始および終了の少なくとも一方の時点に加えられるべきかどうか）。
【０１１４】
−デコーダをリセットさせるために、アナウンスの開始と終了にコーデックホーミング情報も追加してもよい。
【０１１５】
−ボリュームレベルを調整する。
【０１１６】
−様々なペイロードフォーマットを使用する。
【０１１７】
−ＵＥ Ａによって使用される場合、フレームアグリゲーションおよび冗長度を適用する。
【０１１８】
・アナウンスコマンドは、アナウンスサーバに以下の情報を通知する。
【０１１９】
−どのアナウンスを使用すべきか。
【０１２０】
−アナウンスの緊急性、すなわち、アナウンスをユーザに直ちに提示することがどのくらい重要であるか、またはアナウンスが少しの間遅延してもよいかどうか。
【０１２１】
・可能なメディアの変更方法のリストは、メディア分析部によって判定された、各状態に対してどのメディア変更方法が適しているかの記述である。様々な状態に対して適切な様々な動作の例について、以下に説明する。
【０１２２】
・コントローラは、アナウンスコマンド、およびＵＥ ＡとＵＥ Ｂとの間のセッションでメディアが現在どのようにフォーマットされているかについての情報を受信する。
【０１２３】
−コントローラは、メディアを送信する前に何らかの方法でそれを変更するべきである場合、メディアをどのようにエンコードすべききか、またエンコードされたメディアがＲＴＰパケットにどのようにフォーマットされるべきかを判定する。この情報は、メディアエンコーダおよびモディファイアに送信される。
【０１２４】
−コントローラは、ＵＥ Ａからのメディアがいつ中断されるか、およびアナウンスメディアがいつ挿入されるかも判定する。
【０１２５】
・緊急性が高い場合、直ちにまたはできるだけ短い遅延で、ＵＥ Ａからのメディアを中断するべきである。
【０１２６】
・緊急性が低い場合、ＵＥ Ａからのメディアにアイドル期間を検出するまで待機するべきである。
【０１２７】
アナウンスコマンドは、アナウンスもトリガする。このトリガは、背景技術セクションで例示されるように、いくつかの異なる場所から発生してもよい。追加の例としては、緊急呼が待機していることを通話者の一人に通知するために通話を中断することを要望する場合がある電話交換手、または「円滑な中断」を行うことを要望する場合があるネットワークオペレータを含んでいる。例えば、通話者の一人がサービス圏外に移動する場合、オペレータは、単にサービスを中断する代わりに、「通話相手がサービス圏外に移動しました」という種類のアナウンスを挿入したいと要望してもよい。
【０１２８】
例示的メディア符号化および変更方法
エンコーディングおよび伝送フォーマット
コントローラは、エンコーディングおよび伝送フォーマットを、ＵＥ ＡとＵＥ Ｂとの間で送信されている現在のメディアのエンコーディングおよび伝送フォーマットに一致させるべきである。
【０１２９】
・コントローラは、セッションで現在使用されているコーデック及びコーデックモード／レートと同一のコーデックおよびコーデックモード／レートを選択するべきである。
【０１３０】
−アナウンスメディアがより広い音響帯域幅を有する場合、選択されたコーデックに一致させるために帯域通過フィルタを通するべきである。
【０１３１】
−アナウンスメディアがより狭い音響帯域幅を有する場合、帯域幅拡張が適用されるべきである。
【０１３２】
−正確に同一のコーデックまたはコーデックモード／レートを選択できない場合、類似の特性（音響帯域幅、ビットレート、フレームレート、エンコーディング品質等）を有するコーデックを選択するべきである。
【０１３３】
・コントローラは、セッションで現在使用されているフレームアグリゲーション（パケット当たりフレーム数）および冗長フォーマット（数ＲＴＰパケットごとにフレームの繰り返し）と同一のフレームアグリゲーションおよび冗長フォーマットを選択するべきである。
【０１３４】
・コントローラは、セッションで現在使用されている伝送フォーマット（ＲＴＰペイロードタイプ、ペイロードフォーマット、ペイロードフォーマットバージョン）と同一の伝送フォーマットを選択するべきである。
【０１３５】
適切なエンコーディングフォーマットの選択は、２つのメディアが事実上同一のように聞こえる機会を増加する。
【０１３６】
適切な伝送フォーマットの選択は、アナウンスメディアが伝送機能障害によって深刻な影響を受けない機会を増加する。
【０１３７】
切替時の円滑な遷移
アナウンスメッセージがあまり重要でない場合で、かつアナウンスサーバが音声内にアイドル期間を検出するまでメッセージを保持している場合、異なる情報源からのメディアの途中で切り替わる場合に、特別なスムージングが必要とされるべきでない。
【０１３８】
アナウンスメッセージが非常に重要である場合、アナウンスサーバは、ＵＥ Ａからのメディアがアクティブな場合でさえ通常は中断することになるであろう。この場合、アナウンスサーバは、以下をするべきである。
【０１３９】
・ＵＥ Ａからのメディアにフェードアウトを適用する（これは常に可能ではなくてもよい）。
【０１４０】
・アナウンスメディアをフォーマットし、これが、デコーダを段階的にリセットさせるように、デコーダ状態または数フレームに対するＥＣＵの動作のリセットを、例えば、以下によりトリガするようにする。
【０１４１】
−ＡＭＲに対しては、これは、アナウンスメディアが開始する前に、コーデックホーミングフレームを挿入することによって行うことができる。他のコーデックは、同様の特性を持たない場合がある。
【０１４２】
−ＣＲＣまたはチェックサム検証を確実に失敗させる。すべてのペイロードフォーマットが、そのような情報を含むわけではない。このソリューションは、信号を十分に弱めることを確実にするために、いくつかのフレームに対して繰り返される必要がある。
【０１４３】
−不良フレームインジケータ（ＢＦＩ）ビットを設定し、これで受信機でＥＣＵの動作をトリガさせる。すべてのペイロードフォーマットがそのような情報を含むわけではない。このソリューションは、信号を十分に弱めることを確実にするために、いくつかのフレームに対して繰り返される必要がある。
【０１４４】
−ダミーフレームまたはアイドルフレーム（ＮＯ＿ＤＡＴＡ、無音、空白画像）を挿入する。ＮＯ＿ＤＡＴＡは、すべてのコーデックに対して定義されているわけではない。アナウンスサーバは、これを実現するために無音フレームを符号化しなければならない。このソリューションは、信号を十分に弱めることを確実にするために、いくつかのフレームに対して繰り返される必要がある。
【０１４５】
−これらの方法の存在はコーデックに依存するので、コントローラは、どの動作を現在使用されているコーデックに適用するか決定する必要がある。
【０１４６】
・ＵＥ Ａからのメディアの大きさと同程度になるように、アナウンスメディアの大きさを調整する。
【０１４７】
・アナウンスメディアに対してフェードインを適用する。
【０１４８】
・アナウンスメディアの送信が完了する場合で、かつＵＥ Ａからのメディアに切り戻す場合に、同様の動作が行われるべきである。
【０１４９】
スムージングは、アナウンスメディアの開始もしくは終了のどちらかまたは両方で必要とされてもよいし、また全く必要とされなくてもよいことに留意されたい。
【０１５０】
既に説明したように、本発明は、電気通信ネットワークで挿入されるアナウンスだけに限定されない。同様のアナウンスは、ほとんどの商用サービスデスクにも存在する（「切符の注文を続ける場合は１を押してください。日時の変更は２を押してください。販売スタッフと話す場合は３を押してください」）。この場合、アナウンスはリモート「ユーザ」から到来しており、また、リモート「ユーザ」は、事前録音メッセージと人間の話し手を切り替えてもよい。
【０１５１】
メディア間の切替による歪は、完全に取り除かれるまたは少なくとも減少されるであろう。アナウンスメディアのフォーマットは、会話で使用されるメディアのフォーマットに一致されることが好ましい。これは、ＵＥ Ａからのメディアとアナウンスメディアとの間でのより心地良い遷移を提供する。
【０１５２】
受信側のＵＥで、ＭＩＰＳとメモリの両方に関して複雑さの面で利点もあるが、これは、並行して実行するいくつかのアクティブコーデックインスタンスを有する必要がないからである。
【０１５３】
本発明は、ＲＴＰメディアストリームに限定されないし、伝送プロトコルとしてのＵＤＰの使用にも限定されないし、また、セッションセットアップに対するＳＩＰの使用にも限定されないことも理解されるべきである。
【０１５４】
上述の実施形態は単に例として与えられており、本発明がそれらに限定されないことは理解されるべきである。本明細書で開示され特許請求の範囲で定義されている基礎をなす基本的な原理を維持する、さらなる修正、変更および改良は、本発明の範囲内にある。
【０１５５】
略語
ＡＤＰＣＭ 適応的差分ＰＣＭ（Adaptive Differential PCM）
ＡＭＲ 適応マルチレート（Adaptive Multi-Rate）
ＡＭＲ−ＷＢ ＡＭＲ広帯域（AMR-WideBand）
ＢＦＩ 不良フレームインジケータ（Bad Frame Indicator）
ＣＲＣ 巡回冗長コード（Cyclic Redundancy Code）
ＣＳ 回線交換（Circuit Switched）
ＥＣＵ エラー隠蔽部（Error Concealment Unit）
ＥＶＲＣ 拡張可変レートコーデック（Enhanced Variable Rate Codec）
ＧＥＲＡＮ ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク（GSM Edge Radio Access Network）
ＧＳＭ 移動通信用グローバルシステム（Global System for Mobile communications）
ＧＳＭ−ＥＦＲ ＧＳＭ拡張フルレート（GSM Enhanced Full Rate）
ＩＭＳ ＩＰマルチメディアサブシステム（IP Multimedia Subsystem）
ＩＰ インターネットプロトコル（Internet Protocol）
ＭＩＰＳ １００万命令／秒（Million Instructions Per Second）
ＭＭＴｅｌ マルチメディアテレフォニー（Multi Media Telephony）
ＭＲＦＰ メディアリソース機能プロセッサ（Media Resource Function Processor）
ＰＣＭ パルス符号変調（Pulse Code Modulation）
ＰＢＸ 構内交換機（Private Branch eXchange）
ＰＳ パケット交換（Packet Switched）
ＲＴＣＰ リアルタイム制御プロトコル（Real-Time Control Protocol）
ＲＴＰ リアルタイムプロトコル（Real-Time Protocol）
ＳＤＰ セッション記述プロトコル（Session Description Protocol）
ＳＩＰ セッション開始プロトコル（Session Initiation Protocol）
ＴＤＭ 時分割多重（Time Division Multiplexing）
ＵＤＰ ユーザデータグラムプロトコル（User Datagram Protocol）
ＵＭＴＳ ユニバーサル移動通信システム（Universal Mobile Telecommunication System）
ＵＴＲＡＮ ＵＭＴＳ地上無線アクセスネットワーク（UMTS Terrestrial Radio Access Network）
ＵＥ ユーザ機器（User Equipment）
ＶｏＩＰ ボイスオーバＩＰ（Voice over IP）
参考文献
［１］ ＲＦＣ ３５５０「ＲＴＰ：リアルタイムアプリケーション用伝送プロトコル（RTP:A Transport Protocol for Real-Time Applications）」、H.Schulzrinne、S.Casner、R.Frederick、V.Jacobson著
［２］ ３ＧＰＰ ＴＳ ２３．２２８「ＩＰマルチメディアサブシステム（ＩＭＳ）ステージ２（IP Multimedia Subsystem(IMS), Stage 2）」
［３］ ＲＦＣ ３２６１「ＳＩＰ：セッション開始プロトコル（SIP:Session Initiation Protocol）」、ＲＦＣ ３２６１、２００２年６月、Rosenberg,J、Schulzrinne,H.、Camarillo,G.、Johnston,A.、Peterson,J.、Sparks,R.、Handley,M.、E.Schooler著
［４］ ＩＴＵ−Ｔ勧告Ｇ．７１１「音声周波数のパルス符号変調（ＰＣＭ）方式（Pulse Code Modulation (PCM) of Voice Frequencies）」
［５］ ＩＴＵ−Ｔ勧告Ｇ．７２６「４０、３２、２４、１６キロビット／秒適応的差分パルス符号変調（ＡＤＰＣＭ）方式（40,32,24,16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)」
［６］ ３ＧＰＰ ＴＳ ２６．１１４「ＩＰマルチメディアサブシステム（ＩＭＳ）：マルチメディアテレフォニ：メディア処理および相互作用（IP Multimedia Subsystem(IMS); Multimedia Telephony; Media handling and interaction）」
［７］ ３ＧＰＰ ＴＳ ２６．０７１「音声コーデックの必須音声処理機能：ＡＭＲ音声コーデック：一般記述（Mandatory Speech Codec speech processing functions; AMR Speech CODEC; General description）」
［８］ ３ＧＰＰ ＴＳ ２６．１７１「音声コーデックの音声処理機能：適応マルチレート広帯域（ＡＭＲ−ＷＢ）音声コーデック：一般記述（Speech codec speech processing functions; Adaptive Multi-Rate-Wideband (AMR-WB) speech codec; General description）」
［９］ ＩＴＵ−Ｔ勧告Ｈ．２６３、低ビットレート通信用ビデオ符号化方式（Video coding for low bit rate communication）
［１０］ ＩＴＵ−Ｔ勧告Ｈ．２６４、オーディオビジュアルサービス全般のための高度ビデオ符号化方式（Advanced video coding for generic audiovisual services）
【特許請求の範囲】
【請求項１】
通信ネットワークにおける第１のネットワーク要素に向けられている、ユーザメディアとアナウンスメディアとを切り替える方法であって、
前記ユーザメディアは、第２のネットワーク要素から到来するものであり、
前記アナウンスメディアは、第３のネットワーク要素から到来するものであり、
前記方法は、
前記ユーザメディアのコンフィグレーションを判定するステップと、
前記判定されたユーザメディアのコンフィグレーションに基づいて、前記第１のネットワーク要素に提示される前記アナウンスメディアのコンフィグレーションを判定するステップと、
前記アナウンスメディアのコンフィグレーションに従って、前記アナウンスメディアをコンフィグレーションするステップと、
前記コンフィグレーションされたアナウンスメディアを前記第１のネットワーク要素に送信するステップと
を備えることを特徴とする方法。
【請求項２】
前記ユーザメディアのコンフィグレーションを判定するステップは、前記ユーザメディアのコーデックコンフィグレーションを判定するステップを含み、
前記アナウンスメディアのコンフィグレーションを判定するステップは、前記アナウンスメディアのコーデックコンフィグレーションと前記ユーザメディアのコーデックコンフィグレーションとのマッチングに基づいている
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ユーザメディアのコンフィグレーションを判定するステップは、前記ユーザメディアの伝送フォーマットコンフィグレーションを判定するステップを更に含み、
前記アナウンスメディアのコンフィグレーションを判定するステップは、更に、前記アナウンスメディアの伝送フォーマットコンフィグレーションと前記ユーザメディアの伝送フォーマットコンフィグレーションとのマッチングに基づいている
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記ユーザメディアのコンフィグレーションを判定するステップは、前記ユーザメディアのフレームアグリゲーションコンフィグレーションと冗長性フォーマットコンフィグレーションを判定するステップを更に含み、
前記アナウンスメディアのコンフィグレーションを判定するステップは、更に、前記アナウンスメディアのフレームアグリゲーションコンフィグレーションと冗長性フォーマットコンフィグレーションと、前記ユーザメディアのフレームアグリゲーションコンフィグレーションと冗長性フォーマットコンフィグレーションとのマッチングに基づいている
ことを特徴とする請求項２または３に記載の方法。
【請求項５】
前記ユーザメディアのコーデックコンフィグレーションを判定するステップは、コーデックのタイプ、コーデックモード、及びプションでコーデックモード切替機能の判定を含んでいる
ことを特徴とする請求項２に記載の方法。
【請求項６】
通信セッションが、前記第１のネットワーク要素と前記第２のネットワーク要素との間のユーザメディアに対してセットアップされ、
前記コンフィグレーションされたアナウンスメディアを前記第１のネットワーク要素に送信するステップは、前記通信セッションに前記コンフィグレーションされたアナウンスメディアを挿入するステップを含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記ユーザメディアのコンフィグレーションを判定するステップは、
少なくとも１つの有効なユーザメディアのコンフィグレーションを識別するために、前記第１のネットワーク要素と前記第２のネットワーク要素との間のユーザメディア用の通信セッションのセットアップをモニタするステップと、
前記少なくとも１つの有効なユーザメディアのコンフィグレーションに基づいて、前記ユーザメディアのコンフィグレーションを判定するステップと
を備えることを特徴とする請求項１に記載の方法。
【請求項８】
複数の有効なユーザメディアのコンフィグレーションが、前記セッションセットアップをモニタする場合に識別され、
前記ユーザメディアのコンフィグレーションは、前記複数の有効なユーザメディアのコンフィグレーションから判定される
ことを特徴とする請求項７に記載の方法。
【請求項９】
前記ユーザメディアのコンフィグレーションを判定するステップは、更に、前記複数の有効なユーザメディアコンフィグレーションの内の、現在使用されているものを検出するために、前記セッションにおけるネットワーク要素間の通信をモニタするステップを含んでいる
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ネットワーク要素間の通信をモニタするステップは、前記アナウンスメディアのコンフィグレーションの適切な判定を実現するために、前記ユーザメディアのコンフィグレーションの適応用の情報を検出するステップを含んでいる
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記セッションに前記アナウンスメディアを挿入するタイミングは、前記アナウンスの緊急性に基づいて判定され、
前記コンフィグレーションされたアナウンスメディアは、前記判定されたタイミングに従って、前記セッションに挿入される
ことを特徴とする請求項６に記載の方法。
【請求項１２】
前記アナウンスメディアが前記セッションに挿入される場合、前記ユーザメディアと前記アナウンスメディアとの間の円滑な遷移のための遷移処理を適用するステップを更に備える
ことを特徴とする請求項６に記載の方法。
【請求項１３】
前記第１のネットワーク要素は、第１のユーザのユーザ機器を含み、
前記第２のネットワーク要素は、第２のユーザのユーザ機器を含み、
前記第３のネットワーク要素は、第３のユーザのユーザ機器を含む
ことを特徴とする請求項１に記載の方法。
【請求項１４】
前記アナウンスサーバは、前記ネットワークの側と前記ユーザの側との一方に配置されている
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ユーザは、メディア伝送用のリアルタイムプロトコル（ＲＴＰ）と、セッション制御用のセッション開始プロトコル（ＳＩＰ）を使用するマルチメディアセッションに関与している
ことを特徴とする請求項１３に記載の方法。
【請求項１６】
通信ネットワークにおける通信セッションで、ユーザメディアとアナウンスメディアの切替を行なうためのシステムであって、
前記通信セッション用の前記ユーザメディアのコンフィグレーションを判定する手段と、
前記判定されたユーザメディアコンフィグレーションに基づいて、前記セッションに挿入される前記アナウンスメディアのコンフィグレーションを判定する手段と、
前記アナウンスメディアのコンフィグレーションに従って、前記アナウンスメディアをコンフィグレーションする手段と
前記セッションに、前記コンフィグレーションされたアナウンスメディアを挿入する手段と
を備えることを特徴とするシステム。
【請求項１７】
前記ユーザメディアのコンフィグレーションを判定する手段は、前記セッションにおける前記ユーザメディアのコーデックコンフィグレーションを判定する手段を含み、
前記アナウンスメディアのコンフィグレーションを判定する手段は、前記アナウンスメディアのコーデックコンフィグレーションと前記ユーザメディアのコーデックコンフィグレーションとのマッチングを行なうように構成されている
ことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記ユーザメディアのコンフィグレーションを判定する手段は、前記セッションにおける前記ユーザメディアの伝送フォーマットコンフィグレーションを判定する手段を更に含み、
前記アナウンスメディアのコンフィグレーションを判定する手段は、更に、前記アナウンスメディアの伝送フォーマットコンフィグレーションと前記ユーザメディアの伝送フォーマットコンフィグレーションとのマッチングを行なうように構成されている
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記セッションにおける前記ユーザメディアのコーデックコンフィグレーションを判定する手段は、コーデックのタイプ及びコーデックモードを判定する手段を含んでいる
ことを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記ユーザメディアのコンフィグレーションを判定する手段は、
少なくとも１つの有効なユーザメディアのコンフィグレーションを識別するために、前記セッションのセットアップをモニタする手段と、
前記少なくとも１つの有効なユーザメディアのコンフィグレーションに基づいて、前記ユーザメディアのコンフィグレーションを判定する手段と
を備えていることを特徴とする１６に記載のシステム。
【請求項２１】
前記ユーザメディアのコンフィグレーションを判定する手段は、
複数の有効なユーザメディアのコンフィグレーションを識別するために、前記セッションのセットアップをモニタする手段と、
前記複数の有効なユーザメディアのコンフィグレーションの内の、現在使用されているものを検出するために、前記セッションにおけるユーザ間の通信をモニタする手段と
を備えていることを特徴とする１６に記載のシステム。
【請求項２２】
前記アナウンスの緊急性に基づいて、前記セッションにおいて前記アナウンスメディアを挿入するタイミングを判定する手段を更に備え、
前記コンフィグレーションされたアナウンスメディアを挿入する手段は、前記判定されたタイミングに従って、前記セッションに、前記コンフィグレーションされたアナウンスメディアを挿入するように動作可能である
ことを特徴とする１６に記載のシステム。
【請求項２３】
前記アナウンスメディアが前記セッションに挿入される場合、前記ユーザメディアと前記アナウンスメディアとの間の円滑な遷移のための遷移処理を適用する手段を更に備える
ことを特徴とする１６に記載のシステム。
【請求項２４】
前記通信セッションは、異なるユーザのユーザ機器間の通信に関連し、
前記アナウンスは、前記ネットワークの側と前記ユーザの側との内の一方に配置されているアナウンスサーバから到来する
ことを特徴とする１６に記載のシステム。
【請求項２５】
通信ネットワーク用のアナウンスサーバであって、
前記通信ネットワークのセッションにおけるユーザメディアのコンフィグレーションを示すメディアコンフィグレーション情報を取得する手段と、
前記メディアコンフィグレーション情報に基づいて、前記セッションに挿入されるアナウンスメディアをコンフィグレーションする手段と、
前記セッションに、前記コンフィグレーションされたアナウンスメディアを挿入する手段と
を備えることを特徴とするアナウンスサーバ。
【請求項１】
通信ネットワークにおける第１のネットワーク要素に向けられている、ユーザメディアとアナウンスメディアとを切り替える方法であって、
前記ユーザメディアは、第２のネットワーク要素から到来するものであり、
前記アナウンスメディアは、第３のネットワーク要素から到来するものであり、
前記方法は、
前記ユーザメディアのコンフィグレーションを判定するステップと、
前記判定されたユーザメディアのコンフィグレーションに基づいて、前記第１のネットワーク要素に提示される前記アナウンスメディアのコンフィグレーションを判定するステップと、
前記アナウンスメディアのコンフィグレーションに従って、前記アナウンスメディアをコンフィグレーションするステップと、
前記コンフィグレーションされたアナウンスメディアを前記第１のネットワーク要素に送信するステップと
を備えることを特徴とする方法。
【請求項２】
前記ユーザメディアのコンフィグレーションを判定するステップは、前記ユーザメディアのコーデックコンフィグレーションを判定するステップを含み、
前記アナウンスメディアのコンフィグレーションを判定するステップは、前記アナウンスメディアのコーデックコンフィグレーションと前記ユーザメディアのコーデックコンフィグレーションとのマッチングに基づいている
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ユーザメディアのコンフィグレーションを判定するステップは、前記ユーザメディアの伝送フォーマットコンフィグレーションを判定するステップを更に含み、
前記アナウンスメディアのコンフィグレーションを判定するステップは、更に、前記アナウンスメディアの伝送フォーマットコンフィグレーションと前記ユーザメディアの伝送フォーマットコンフィグレーションとのマッチングに基づいている
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記ユーザメディアのコンフィグレーションを判定するステップは、前記ユーザメディアのフレームアグリゲーションコンフィグレーションと冗長性フォーマットコンフィグレーションを判定するステップを更に含み、
前記アナウンスメディアのコンフィグレーションを判定するステップは、更に、前記アナウンスメディアのフレームアグリゲーションコンフィグレーションと冗長性フォーマットコンフィグレーションと、前記ユーザメディアのフレームアグリゲーションコンフィグレーションと冗長性フォーマットコンフィグレーションとのマッチングに基づいている
ことを特徴とする請求項２または３に記載の方法。
【請求項５】
前記ユーザメディアのコーデックコンフィグレーションを判定するステップは、コーデックのタイプ、コーデックモード、及びプションでコーデックモード切替機能の判定を含んでいる
ことを特徴とする請求項２に記載の方法。
【請求項６】
通信セッションが、前記第１のネットワーク要素と前記第２のネットワーク要素との間のユーザメディアに対してセットアップされ、
前記コンフィグレーションされたアナウンスメディアを前記第１のネットワーク要素に送信するステップは、前記通信セッションに前記コンフィグレーションされたアナウンスメディアを挿入するステップを含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記ユーザメディアのコンフィグレーションを判定するステップは、
少なくとも１つの有効なユーザメディアのコンフィグレーションを識別するために、前記第１のネットワーク要素と前記第２のネットワーク要素との間のユーザメディア用の通信セッションのセットアップをモニタするステップと、
前記少なくとも１つの有効なユーザメディアのコンフィグレーションに基づいて、前記ユーザメディアのコンフィグレーションを判定するステップと
を備えることを特徴とする請求項１に記載の方法。
【請求項８】
複数の有効なユーザメディアのコンフィグレーションが、前記セッションセットアップをモニタする場合に識別され、
前記ユーザメディアのコンフィグレーションは、前記複数の有効なユーザメディアのコンフィグレーションから判定される
ことを特徴とする請求項７に記載の方法。
【請求項９】
前記ユーザメディアのコンフィグレーションを判定するステップは、更に、前記複数の有効なユーザメディアコンフィグレーションの内の、現在使用されているものを検出するために、前記セッションにおけるネットワーク要素間の通信をモニタするステップを含んでいる
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ネットワーク要素間の通信をモニタするステップは、前記アナウンスメディアのコンフィグレーションの適切な判定を実現するために、前記ユーザメディアのコンフィグレーションの適応用の情報を検出するステップを含んでいる
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記セッションに前記アナウンスメディアを挿入するタイミングは、前記アナウンスの緊急性に基づいて判定され、
前記コンフィグレーションされたアナウンスメディアは、前記判定されたタイミングに従って、前記セッションに挿入される
ことを特徴とする請求項６に記載の方法。
【請求項１２】
前記アナウンスメディアが前記セッションに挿入される場合、前記ユーザメディアと前記アナウンスメディアとの間の円滑な遷移のための遷移処理を適用するステップを更に備える
ことを特徴とする請求項６に記載の方法。
【請求項１３】
前記第１のネットワーク要素は、第１のユーザのユーザ機器を含み、
前記第２のネットワーク要素は、第２のユーザのユーザ機器を含み、
前記第３のネットワーク要素は、第３のユーザのユーザ機器を含む
ことを特徴とする請求項１に記載の方法。
【請求項１４】
前記アナウンスサーバは、前記ネットワークの側と前記ユーザの側との一方に配置されている
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ユーザは、メディア伝送用のリアルタイムプロトコル（ＲＴＰ）と、セッション制御用のセッション開始プロトコル（ＳＩＰ）を使用するマルチメディアセッションに関与している
ことを特徴とする請求項１３に記載の方法。
【請求項１６】
通信ネットワークにおける通信セッションで、ユーザメディアとアナウンスメディアの切替を行なうためのシステムであって、
前記通信セッション用の前記ユーザメディアのコンフィグレーションを判定する手段と、
前記判定されたユーザメディアコンフィグレーションに基づいて、前記セッションに挿入される前記アナウンスメディアのコンフィグレーションを判定する手段と、
前記アナウンスメディアのコンフィグレーションに従って、前記アナウンスメディアをコンフィグレーションする手段と
前記セッションに、前記コンフィグレーションされたアナウンスメディアを挿入する手段と
を備えることを特徴とするシステム。
【請求項１７】
前記ユーザメディアのコンフィグレーションを判定する手段は、前記セッションにおける前記ユーザメディアのコーデックコンフィグレーションを判定する手段を含み、
前記アナウンスメディアのコンフィグレーションを判定する手段は、前記アナウンスメディアのコーデックコンフィグレーションと前記ユーザメディアのコーデックコンフィグレーションとのマッチングを行なうように構成されている
ことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記ユーザメディアのコンフィグレーションを判定する手段は、前記セッションにおける前記ユーザメディアの伝送フォーマットコンフィグレーションを判定する手段を更に含み、
前記アナウンスメディアのコンフィグレーションを判定する手段は、更に、前記アナウンスメディアの伝送フォーマットコンフィグレーションと前記ユーザメディアの伝送フォーマットコンフィグレーションとのマッチングを行なうように構成されている
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記セッションにおける前記ユーザメディアのコーデックコンフィグレーションを判定する手段は、コーデックのタイプ及びコーデックモードを判定する手段を含んでいる
ことを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記ユーザメディアのコンフィグレーションを判定する手段は、
少なくとも１つの有効なユーザメディアのコンフィグレーションを識別するために、前記セッションのセットアップをモニタする手段と、
前記少なくとも１つの有効なユーザメディアのコンフィグレーションに基づいて、前記ユーザメディアのコンフィグレーションを判定する手段と
を備えていることを特徴とする１６に記載のシステム。
【請求項２１】
前記ユーザメディアのコンフィグレーションを判定する手段は、
複数の有効なユーザメディアのコンフィグレーションを識別するために、前記セッションのセットアップをモニタする手段と、
前記複数の有効なユーザメディアのコンフィグレーションの内の、現在使用されているものを検出するために、前記セッションにおけるユーザ間の通信をモニタする手段と
を備えていることを特徴とする１６に記載のシステム。
【請求項２２】
前記アナウンスの緊急性に基づいて、前記セッションにおいて前記アナウンスメディアを挿入するタイミングを判定する手段を更に備え、
前記コンフィグレーションされたアナウンスメディアを挿入する手段は、前記判定されたタイミングに従って、前記セッションに、前記コンフィグレーションされたアナウンスメディアを挿入するように動作可能である
ことを特徴とする１６に記載のシステム。
【請求項２３】
前記アナウンスメディアが前記セッションに挿入される場合、前記ユーザメディアと前記アナウンスメディアとの間の円滑な遷移のための遷移処理を適用する手段を更に備える
ことを特徴とする１６に記載のシステム。
【請求項２４】
前記通信セッションは、異なるユーザのユーザ機器間の通信に関連し、
前記アナウンスは、前記ネットワークの側と前記ユーザの側との内の一方に配置されているアナウンスサーバから到来する
ことを特徴とする１６に記載のシステム。
【請求項２５】
通信ネットワーク用のアナウンスサーバであって、
前記通信ネットワークのセッションにおけるユーザメディアのコンフィグレーションを示すメディアコンフィグレーション情報を取得する手段と、
前記メディアコンフィグレーション情報に基づいて、前記セッションに挿入されるアナウンスメディアをコンフィグレーションする手段と、
前記セッションに、前記コンフィグレーションされたアナウンスメディアを挿入する手段と
を備えることを特徴とするアナウンスサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２０１０−５１２１０６（Ｐ２０１０−５１２１０６Ａ）
【公表日】平成２２年４月１５日（２０１０．４．１５）
【国際特許分類】
【出願番号】特願２００９−５４０２０２（Ｐ２００９−５４０２０２）
【出願日】平成１９年１１月３０日（２００７．１１．３０）
【国際出願番号】ＰＣＴ／ＳＥ２００７／００１０６１
【国際公開番号】ＷＯ２００８／０６９７２３
【国際公開日】平成２０年６月１２日（２００８．６．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２２年４月１５日（２０１０．４．１５）
【国際特許分類】
【出願日】平成１９年１１月３０日（２００７．１１．３０）
【国際出願番号】ＰＣＴ／ＳＥ２００７／００１０６１
【国際公開番号】ＷＯ２００８／０６９７２３
【国際公開日】平成２０年６月１２日（２００８．６．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]