(57)【特許請求の範囲】
【請求項１】
第１の通信装置と、第２の通信装置と、前記第１の通信装置と前記第２の通信装置とを接続するための少なくとも１つの通信チャネルと、前記第１の通信装置と前記第２の通信装置との間の通信を制御するためのプロセッサとを含む通信システムにおける、送信側と受信側との間の音声通信における、音声通話の送信を現在担持している通信チャネルが混雑しているときの音声通信の維持方法であって、
前記通信チャネルは、少なくとも１つのシグナリングチャネルと、所定のサービス品質を有する少なくとも１つのペイロードチャネルとを含む、方法において、
前記通信システムが、前記ペイロードチャネルのサービス品質を監視するステップと、
前記ペイロードチャネルのサービス品質が所定の閾値を下回る場合、少なくとも前記通信チャネルの前記シグナリングチャネルの送信側による保持中に、前記通信システムが、前記ペイロードチャネルを介した送信側からの音声通話の送信をインタラプトするステップと、
前記通信システムが、対応する送信側の音声通話をテキストへ変換するステップと、
前記通信システムが、前記保持された通信チャネルを介して対応する受信側へ前記テキストを送信するステップと、
を含み、さらに、
前記送信側からの音声通話の送信をインタラプトするステップに応じて、前記通信システムが、前記受信側へアラームメッセージを送信するステップ
を含む
ことを特徴とする方法。
【請求項２】
前記方法はさらに、前記通信システムが、対応する受信側で、受信されたテキストを音声通話へ変換するステップを含む、
請求項１記載の方法。
【請求項３】
前記方法はさらに、充分なサービス品質が検出された後、前記通信システムが、保持されたペイロードチャネルを介して、音声通話の送信を再開するステップを含む、
請求項１記載の方法。
【請求項４】
現在の音声通信が所定の鍵及び特定のアルゴリズムを用いて暗号化されており、
前記方法はさらに、前記通信システムが、前記テキストを同じ鍵及び同じアルゴリズムで暗号化するステップを含む、
請求項１記載の方法。
【請求項５】
前記方法はさらに、前記通信システムが、前記テキストを送信するステップにおいてシグナリングチャネルのみを用いるステップを含む、
請求項１記載の方法。
【請求項６】
前記方法はさらに、前記通信システムが、音声通話の言語を識別して該音声通話を適切な言語のテキストへ変換するステップを含む、
請求項１記載の方法。
【請求項７】
前記方法はさらに、音声通話の送信からテキストの送信への目前に迫った変更を、前記通信システムが、前記受信側と取り決めるステップを含む、
請求項１記載の方法。
【請求項８】
前記方法はさらに、対応する送信側の音声通話を、前記通信システムが、フォネティック形式のテキストへ変換するステップを含む、
請求項１記載の方法。
【請求項９】
前記方法はさらに、ユーザの要求に応じて、前記通信システムが前記音声通話の送信をインタラプトするステップ、及び、前記通信システムが前記音声通話をテキストへ変換するステップ、及び、前記テキストを送信するステップを実行するために、前記通信システムがユーザ入力を受容するステップを含む、
請求項１記載の方法。
【請求項１０】
前記方法はさらに、前記テキストを送信するステップにおいて、前記通信システムが、使用すべき言語の指示を、対応する受信側へ前記テキストと共に送信するステップを含む、
請求項１記載の方法。
【請求項１１】
前記方法はさらに、前記テキストを送信するステップにおいて、前記通信システムが、前記ペイロードチャネルを介して前記テキストを送信するステップを含む、
請求項１記載の方法。
【請求項１２】
アプリケーションを格納した、非一時性のコンピュータ読み出し可能媒体であって、
前記アプリケーションは、当該アプリケーションが通信装置のプロセッサ上で実行されるときに、前記通信装置が請求項１から１１までのいずれか１項記載の方法を実施するための、前記通信装置のプロセッサにより実行可能な複数の命令を規定している、媒体。
【請求項１３】
コンピュータプログラムが通信装置のプロセッサ上で実行されるときに、前記通信装置が請求項１から１１までのいずれか１項記載の方法を実施するための、前記通信装置のプロセッサ用のコンピュータプログラム。
【請求項１４】
通信システムであって、
第１の通信装置と、
第２の通信装置と、
前記第１の通信装置と前記第２の通信装置とを接続するための、少なくとも１つの通信チャネルと、
前記第１の通信装置と前記第２の通信装置との間の通信を制御するために、請求項１から１１までのいずれか１項記載の方法を実行するように構成されたプロセッサと
を含む
ことを特徴とする通信システム。
【請求項１５】
前記通信システムはさらに、音声通話の言語を識別して該音声通話を適切な言語のテキストへ変換する言語識別手段を含む、
請求項１４記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、混雑した通信チャネルでの音声通信の維持方法、当該方法を実行するためのコンピュータプログラム、当該方法を実行するためのアプリケーションを記憶した非一時性のコンピュータで読み出し可能な媒体、及び、当該方法を実行するように構成された通信システムに関する。
【０００２】
発明の背景
ユーザは、データ、特に音声通話データ等の送信の際に、高いビットエラーレートＢＥＲもしくはパケット損失などのネットワークの問題によって生じる問題にしばしば遭遇する。こうした問題はワイヤレスの音声通信において特に頻繁に発生する。その結果、通信品質が低下し、通信状態が著しく劣悪となる。エラーが特定の通信チャネルだけでなくネットワーク全体に係る問題から生じている場合、リダイヤルは良好な品質の呼を確立する助けとはならない。ただし、緊急呼び出しの場合など、こうした呼が重要となることがある。
【０００３】
したがって、通信プロバイダはネットワークの問題が深刻な場合にも音声通信を維持するための良好なソリューションを提供しなければならない。
【０００４】
取り決めを経て確立されたコーデック及び／又はベアラチャネルでの通信の維持は、不充分な帯域幅や大きなパケット遅延、多量のパケット損失又は高いビットエラーレートＢＥＲなどが生じるため、不可能である。
【０００５】
ＵＳ７６１７１０６Ｂ２によれば、スピーチ‐ツー‐テキスト変換（ＳＴＴ変換）が正しいか否かを検査するために、変換されたテキストが再び音声通話へ変換される。ついで、オリジナルの音声通話とテキスト表現から形成された音声通話との双方がステレオヘッドセットで再生される。これにより、プルーフリーダー（この場合はプルーフリスナーであるが）はオリジナルの音声通話と変換された音声通話との相違を容易に発見できる。また、ＵＳ７６９７５５１Ｂ２の教説では、システムを介して電話機とインスタントメッセージ機能部ＩＭとが接続される。当該システムはＩＭテキストを音声通話へ変換し、その後、この音声通話をＩＭテキストへ戻す。ＵＳ２００２／１２３８９２Ａ１には、音声通話をテキストへ変換し、インタフェースを介してこのテキストをユーザに提示するエンベデッドシステムが示されている。エラーが生じた場合、ユーザはシステムに対して誤認のエラー識別子を供給する。これに応じて、実際の言語モデルへのリファレンスに沿った音声入力が学習プロセスへ転送される。ＣＮ２０１４４０７３３Ｕによれば、手話画像がモバイル通信装置のカメラによって捕捉される。当該画像からピクチャトラックが形成され、漠然としたテキスト情報へ変換される。その後、当該テキストが文法及び統語のパラメータによって修正される。ＪＰ２００６００５４４０Ａの教説では、雑音環境において、モバイル電話機のカメラが口唇の動きの画像を取得してこれを送信する。受信側では、当該画像が動画として表示される。これに代えて、口唇の運動パラメータのみが送信されることもある。ＵＳ２００５／０４９８６８Ａ１によれば、語句がテキスト‐ツー‐スピーチアプリケーションへ供給される。ついで、形成された音声通話が１つもしくは複数のスピーチ‐ツー‐テキストエンジンへ供給される。導出された語句にはコンフィデンスレベルが割り当てられる。
【０００６】
上述した問題は請求項１記載の方法によって解決される。本発明の有利な実施形態は各従属請求項の発明特定事項となっている。
【０００７】
本発明によれば、送信側と受信側との間の音声通信における、音声通話の送信を現在担持している通信チャネルが混雑しているときの音声通信の維持方法であって、通信チャネルが少なくとも１つのシグナリングチャネルと所定の（可変の）サービス品質を有する少なくとも１つのペイロードチャネルとを含む方法は、以下の各ステップを含む：すなわち、ペイロードチャネルのサービス品質を監視するステップと、ペイロードチャネルのサービス品質が所定の閾値を下回る場合、少なくとも通信チャネルのシグナリングチャネルが保持されている間、同時に、ペイロードチャネルを介した送信側からの音声通話の送信をインタラプトするステップとを含む。言い換えれば、本発明の方法では、通信チャネルの脱落なしに、つまり、少なくとも通信チャネルのシグナリング部分を保持した状態で、音声データの送信が停止されるのである。“完全な”通信チャネルすなわちそのペイロードチャネルを維持しつつ、音声通話データ（以下では単に「音声通話」と称する）の送信のインタラプトを行えることは云うまでもない。送信側から受信側へ音声通話を送信することに代えて、音声通話はテキストへ変換され、テキストデータとして受信側へ送信される。ユーザ又は通信方法のコントロールセンタによる別の指示がないかぎり、受信側で形成された音声がテキストへ変換され、今や受信側となっている（先の）送信側へ送信される。言い換えれば、テキストデータのみの送信への切り換え後、対応する送信側の音声通話がテキストへ変換され、対応する受信側へ送信されるのである。
【０００８】
上述したように、本発明の方法を用いることにより、サービス品質が不充分な状況においても呼を保存できる。
【０００９】
本発明の一実施形態によれば、テキストデータの送信はペイロードチャネルを介して行われる。
【００１０】
本発明は、混雑している通信チャネルの帯域幅も、テキストデータとしての必要な情報を通信／送信するには尚充分であり、低いサービス品質もしくは帯域幅を有するチャネルを利用するために音声のストリーミングを回避するという論究を基礎としている。サービス品質は、全てのタイプの通信において、既存のマトリクスによって検出可能である。ペイロードチャネル又はリアルタイムトランスポートプロトコルチャネル（ＲＴＰチャネル）での音声ストリームのサービス品質は、特には次のようにして検出される：
１）１ストリーム内のＲＴＰパケット（ＩＰユーザデータグラムプロトコルパケット（ＩＰＵＤＰパケット）として伝送される）に連続番号が付される。よって、１つもしくは複数のパケットが失われる場合にもパケット損失を容易に検出できる。シーケンスから外れたパケットも検出可能である。こうしたシーケンス外れは、ＩＰパケットが宛先まで種々のルートを取る場合に発生しうる。
２）ビットエラーを有するパケットは劣悪なパケットを標示している。ＲＴＰストリームがビットエラー検出機能を有さず、複数の符号化法を含む場合であっても、ＲＴＰペイロードは（ＲＦＣ４８６７にしたがって）ビットエラーを検出する機能を有する。本発明のコンテクストでは、Ｇ．７２２，ＡＭＲタイプなどのコーデックを使用可能である。
３）受信側におけるパケット遅延及びジッタバッファのセットアップを用いて、同様に、不充分な送信品質を検出することができる。定義されたもしくは使用されたコーデックに基づいて、ＲＴＰパケットの間隔が求められる。パケットの遅延は送信期間を超えるので、通常、割り当てられたバッファは僅かな数のパケットをバッファリングして到来したジッタを平滑化することしかできない。こうしたバッファによりストリーム外での遅延が発生する。受信側の人間は送信側を知らず、このため、遅延は所定量（「ラグ」とも称される）にいたるまで甘受される。しかし、バッファサイズは有限であり、パケットの到来がバッファサイズを超えて遅延する場合には、受信側で音声通話の休止が認識される。よって、ジッタバッファの不足も劣悪な音声品質（サービス品質）の標識となる。
４）ストリームを再構成した後の音声分析を利用して、劣悪な音声品質を検出できる。急激な音声変化に基づいて不規則性を検出することもできる。
【００１１】
本発明の方法が受信されたテキストを音声通話へ戻すステップを含む場合、対応する受信側にとって有利である。このケースでは、電話呼もしくは音声通信に関与している複数のユーザが音声ベースの通信を続行でき、先行して音声通話からテキスト変換された送信テキストの閲読を強制されないからである。もちろん、対話している各ユーザが、それぞれの側で、システムに、テキストから音声通話への再変換に代え、通信チャネルを介して送信されたテキストの表示の続行を命じることもできる。
【００１２】
また、ペイロードチャネルのサービス品質が連続的に監視されていれば、“通常の”音声通信もしくは電話呼を再確立するのに充分な品質が検出された時点で直ちに、保持されたペイロードチャネルを介した音声通話の送信への戻し切り換えが行われるので、有利である。
【００１３】
音声通話の送信がインタラプトされ、代わりにスピーチ‐ツー‐テキスト変換から得られたテキストデータが送信された時点で直ちにアラームメッセージが対応する受信側へ送信されると有利である。このようにすれば、対応する受信側が現在の通信の目前に迫った変更に対して充分に準備できる。
【００１４】
現在の音声通信が所定の鍵及び特定のアルゴリズムを用いて暗号化されている場合、送信テキストの暗号化にも同じ鍵及び同じアルゴリズムが用いられると有利である。このようにすれば、テキストデータのみの送信に変更が発生しても通信の安全性が維持される。
【００１５】
本発明の一実施形態によれば、テキストの送信に対して、シグナリングチャネルのみが用いられる。これにより、サービス品質（送信品質）があまりに低くなった場合、又は、ペイロードチャネルの利用料金を節約したい場合に、現在の通信チャネルからペイロードチャネルを離脱させることができる。この場合、データはＲＡＷもしくはＸＭＬその他のいずれのフォーマットでも形成できる。ただし、通信の相手方には、先の合意／取り決めに代わる別のデータが到来すること、及び、到来するテキストのタイプ及びフォーマットを報知する必要がある。
【００１６】
本発明の別の実施形態によれば、音声通話を適切な言語のテキストへ変換するために、音声通話の言語を識別するステップが行われる。スピーチ‐ツー‐テキスト技術の進歩は著しく、そのソリューションは本発明にも良好に適用可能である。ＳＴＴが言語を検出できない場合、現在の通信で音声通話送信からテキスト送信への変更が開始された側の通信装置の設定から、使用すべき言語を指示しなければならない。
【００１７】
処理を改善するために、音声通話送信からテキスト送信への目前に迫った変更が、その時点で送信側である通信関与者によって、例えばその時点で受信側である他方の通信関与者と取り決められると有利である。テキストへの切り換えが協議されている間、送信側は規定の言語をテキスト送信に用いることを指示できる。
【００１８】
さらに、ＳＴＴ（スピーチ‐ツー‐テキスト）及びＴＴＳ（テキスト‐ツー‐スピーチ）のソリューションにより、ユーザは音声タイプのカテゴリや受信側のＴＴＳで使用すべき設定された音声特性などのパラメータを識別できる。この場合、送信側は、テキストペイロードにおいて、言語が米語でありかつ「声＝マイク」であることを表示できる。従来技術のＴＴＳソリューションのなかには、マイク（男性用）又はメアリ（女性用）のような予め設定された音声特性を使用しているものもある。受信側は、自ら選択することによって又はデフォルト値を使用することで、こうした選択を受容したり却下したりできる。
【００１９】
受信側でのテキスト‐ツー‐スピーチプロセスを簡単化するために、対応する送信側の音声通話をフォネティック形式のテキストへ変換するステップを用いると有利である。
【００２０】
本発明の別の有利な実施形態によれば、ユーザは、通信装置に対し、そのつどコマンドを入力することで、音声通話の送信からテキストの送信への切り換えを、要求に応じて（オンデマンドで）命じることができる。例えば、ユーザが特定の通信に対して自身の声以外の声を使用したいと望むケースがありうる。他の例として、テキスト送信への切り換えによって可能となる、背景の障害雑音の除去が挙げられる。これは、通信装置がそれぞれのユーザの声を認識して最適にテキストへ変換できる充分なレベルの機能を有する場合に良好に動作し、これにより出力部は受信側での明瞭性を増大させることができる。
【００２１】
上述した問題は、上述した方法を実行できるアプリケーションを記憶した、非一時性のコンピュータで読み出し可能な媒体によっても解決される。なお、当該アプリケーションが通信装置のプロセッサで実行可能なように設計されなければならないことは云うまでもない。
【００２２】
また、上述した問題は、上述した方法を実行するように設計された、通信装置のプロセッサ用のコンピュータプログラム又はコンピュータプログラム製品によっても解決される。
【００２３】
本発明の別の実施形態によれば、上述した問題はさらに、次のような通信システムによって解決される。本発明の通信システムは、第１の通信装置と、第２の通信装置と、第１の通信装置と第２の通信装置とを接続するための少なくとも１つの通信チャネルと、第１の通信装置と第２の通信装置との間の通信を制御するために上述した方法を実行するように構成されたプロセッサとを含む。第１の通信装置及び第２の通信装置は、例えば、卓上電話機、ＰＤＡ、スマートフォン、又は、マイクロフォンを備えかつ電話回線網に接続されたコンピュータであってよい。
【００２４】
本発明の通信システムは、本発明の方法に関連して上述した全ての特徴を含むので、本発明の方法に関連して上述した利点及び独自性が本発明の通信システムにおいても得られることは云うまでもない。
【００２５】
通信システムがさらに、音声通話の言語を識別してこれを適切な言語のテキストへ変換する言語識別手段を含むと有利である。言語は、必ずしも送信側と受信側との２ユーザで同じでなくてよく、例えば各ユーザがそれぞれの母語を使用し、各言語が同じ言語の対応テキストへ変換されるように構成できる。
【００２６】
言語の取り決めが行われない場合、送信側から指示された言語を受信側の通信関与者が理解できない場合、メッセージが無視される可能性がある。すると、一方のユーザは、静寂が生じることで、適正な通信の欠落に気付くはずである。この場合、当該ユーザは、通信／呼を続行することも終了することもできるし、又は、この事実をマイクロフォンへ話しかけることで相手方へ通信問題の発生を伝えることもできる。
【００２７】
受信側のユーザが一般のもしくは現在のフォーマットでのＴＴＳを扱えない場合も、対応するユーザはこの事実を無視しうるし、又は、相手方へ問題発生を伝えようとすることもある。
【００２８】
上述したように、音声通話の送信からテキストの送信への切り換えは、変更なしでは音声通信を維持できない不充分なサービス品質が検出されたことに応じて行われる。
【００２９】
本発明の有利な実施形態を例として図示する。ただし、各実施形態は本発明を限定するものでない。
【図面の簡単な説明】
【００３０】
【図１】本発明の方法の第１の実施形態を実行可能な本発明の通信装置の一実施形態を示す図である。
【図２】図１の通信装置において本発明の方法の第２の実施形態が実行される様子を示す図である。
【００３１】
有利な実施形態の説明
図１に示されているように、本発明の通信システム２０は、第１の通信装置Ａと、第２の通信装置Ｂと、２つの通信Ａ，Ｂを相互に接続する通信網１０とを含む。通信網１０は、公衆交換電話回線ＰＳＴＮ又は移動通信網その他の適切なネットワークであってよい。通信網１０の要素の１つとして交換装置２８が示されている。第１の通信装置Ａ及び第２の通信装置Ｂとしては、携帯電話機、スマートフォン、卓上電話機又は類似のデバイスを利用可能である。例として、２つの通信装置Ａ，Ｂそれぞれが相互間の通信を確立するための２つのシグナリングライン又はチャネル３３，３４が示されている。こうした通信は、ペイロードチャネル３６（ＲＴＰチャネル又はベアラチャネルとも称される）によってセットアップ可能である。
【００３２】
本発明の方法は、プロセッサ４０に本発明の方法を実行させるための専用のコンピュータプログラム５２又はコンピュータプログラム製品として実現可能である。プロセッサ４０が第１の通信装置Ａ内及び第２の通信装置Ｂ内に設けられることが図示されている。選択的に、プロセッサを例えば交換装置２８内又は（図示されていない）コントロールセンタ内に設けることもできる。言い換えれば、本発明の方法はコンピュータによって実現される。これに代えて、本発明の方法をハードウェアとして実現してもよい。コンピュータプログラム５２は、図に概略的に示されているように、コンピュータで読み出し可能な媒体５０、例えばメモリスティック、メモリカード、ＳＳＤドライバ、又は、例示に過ぎないが、非一時性のコンピュータで読み出し可能な媒体などとしての「通常の」ハードディスクドライブに記憶可能である。
【００３３】
本発明の方法の説明のために、第１の通信装置Ａと第２の通信装置Ｂとの間の会話が、シグナリングチャネル３３，３４及びペイロードチャネル３６を含む通信チャネル３０を用いて確立されたとする。所定の時点で、第１の通信装置Ａが、通信チャネル３０のペイロードチャネル３６でのサービス品質が変更を行わないかぎり音声通信を維持できない程度に不充分なものとなったことを検出する。
【００３４】
本発明の方法の説明のために、最初、第１の通信装置Ａが通信の送信側２２を形成し、第２の通信装置Ｂが通信の受信側２４を形成するものとする。
【００３５】
本発明の方法は、ＳＩＰ（セッションイニシエーションプロトコル）を用いて記述される。他の通信プロトコルを代替使用できること、及び、本発明がＳＩＰの使用に限定されないことは云うまでもない。この状況を前提として、第１の通信装置Ａは、招待メッセージを、シグナリングライン３３を介して交換装置２８へ送信する。当該招待メッセージにおいては、セッションディスクリプションプロトコルＳＤＰは不活性に設定されている。ついで、交換装置２８が、ＳＤＰを不活性に設定したうえで、招待メッセージを第２の通信装置Ｂへ送信する。第２の通信装置Ｂは、ＳＤＰを不活性としたまま、応答メッセージを交換装置２８へ返送する。交換装置２８は、ＳＤＰを不活性としたまま、いわゆるメッセージ２００ＯＫを第１の通信装置Ａへ返送する。第１の通信装置Ａは、自身に接続されたマイクロフォン２１によって記録された音声通話データのスピーチ‐ツー‐テキスト変換（ＳＴＴ変換）を行う。例として"Wie stark ist der Sturm?"（風はどれくらい強いですか？）なる独語文とシステムが使用すべき言語が独語である旨の指示との双方が、テキスト情報としてシグナリングライン３３へ置かれる。同じメッセージが交換装置２８を介してシグナリングライン３４へ置かれ、第２の通信装置Ｂへ送信される。受信側２４（第２の通信装置Ｂ）での受信後、メッセージのテキスト‐ツー‐スピーチ変換（ＴＴＳ変換）が行われ、第２の通信装置Ｂに接続されたスピーカ２３を介して結果が出力される。第２の通信装置Ｂを使用しているユーザは、（図示されていない）自身のマイクロフォンへ"The wind speed is 250 miles per hour."（風速は毎時２５０マイルです。）と話しかけることによって、質問に答えることができる。今度は送信側２２となった第２の通信装置Ｂからの当該音声通話データはＳＴＴ変換され、データがメッセージ２００ＯＫとして（言語が米語であることの指示とともに）置かれ、交換装置２８へ送信される。交換装置２８は、今度は受信側２４となった第１の通信装置Ａへこのメッセージを供給する。このメッセージは第１の通信装置ＡでＴＴＳ変換され、（図示されていない）スピーカを介して出力される。
【００３６】
こうした通信の方式は、所望もしくは必要に応じて又は各通信の終了まで続行される。ここでは言語の取り決めがなされていないことに注意されたい。受信側２４が送信側２２の指示した言語を理解できない場合、受信側２４は当該メッセージを無視しうるし、又は、無視すべきである。受信側２４のユーザは（例えば静寂しか聞こえないため）適正な通信が欠落していることに気付くことができるので、呼を続行するか又は終了するかは当該ユーザに委ねられる。同じことが送信側２２のユーザにも当てはまる。
【００３７】
図２には、図１の通信システム２０と同じ設定が示されている。ただし、図２からわかるように、本発明の方法は図１とは異なって実行されている。図１によればデータ（音声テキストデータへＳＴＴ変換された音声通話データ）がシグナリングチャネル３３，３４に置かれたが、図２ではこれらに代えてペイロードチャネル３６が用いられている。通信チャネル３０で許容不能なサービス品質が検出されたことに応じて、第１の通信装置Ａは、仕様［ＳＤＰ  オーディオコーデック：不活性，ＴＴＳコード：活性，言語：独語］を有する招待メッセージを交換装置２８へ送信する。同じメッセージが交換装置２８を介して第２の通信装置Ｂへ供給される。第２の通信装置Ｂは、仕様［ＳＤＰ  オーディオコーデック：不活性，ＴＴＳコード：活性，言語：米語］を有する応答メッセージを送信することにより応答する。これは、この時点で送信側２２である第２の通信装置Ｂがこれから米語を言語として使用することを意味する。当該応答メッセージに応じて、交換装置２８は、同じ仕様を有するメッセージ２００ＯＫを第１の通信装置Ａへ送信する。このようにして、２つの通信装置Ａ，Ｂは、音声通話データから変換されるテキストデータの使用と、２つの通信装置２２，２４での独語及び米語の使用とをそれぞれ取り決めている。その後、ペイロードチャネル３６で、ＲＴＰストリーム、例えば"Wie stark ist der Sturm?"（風はどれくらい強いですか？）という質問と"The wind speed is 250 miles per hour."（風速は毎時２５０マイルです。）という答えとが上述したようにやり取りされる。ついで、上述したように、各テキストデータが対応する受信側でＴＴＳ変換され、適切なスピーカから出力される。
【００３８】
上記方法では、ＲＴＰの新たなペイロードタイプが定められる。ペイロードタイプの例のリストは
・http://en.wikipedia.org/wiki/Packet_loss
・http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1559904&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1559904
・http://vonage.nmhoy.net/packetloss.html
・http://pe.org.pl/articles/2011/10/78.pdf
・http://voip.netlab.uky.edu/~fei/teaching/cs671/slides/rtp.pdf
等に見出される。
【００３９】
プロトコルに取り決めが組み込まれている場合、プロトコルに予測される再取り決めの標準プロシージャも適用可能である。本発明の一実施形態によれば、サービス品質がテキスト通信に代えて通常の音声通話通信への戻し切り換えを許容できるレベルに再び達したか否かを識別するために、ペイロードチャネル３６が連続的に監視される。
【００４０】
上述したことがらからわかるように、テキストから音声通話への変換は任意である。言い換えれば、ユーザは自身の通信装置についてテキストから音声通話への変換を抑圧するように設定できる。
【００４１】
本発明の別の実施形態では、テキストデータ送信への切り換えはユーザの要求に応じて（オンデマンドで）呼び出し可能である。これは例えば、ユーザが自身の声とは異なる声を使用したい場合、又は、背景雑音が会話の障害となっている場合などである。後者のケースで、通信装置がユーザの声を識別して最適にテキストへ変換できる充分に高度な機能を有する場合、ノイズキャンセリングが行われているので、ＴＴＳ変換された出力は対応する受信側での明瞭性を増大するはずである。
【００４２】
本発明を幾つかの実施形態に即して説明したが、これらは本発明の範囲を限定するものでなく、幾つかの可能な実施形態の例であると理解されたい。当業者であれば、本発明の範囲において種々の変更及び修正及び別の実現手段を想到することが可能なはずである。各実施形態の個々の特徴は上述したのと異なる方式で相互に組み合わせ可能であることも理解されるであろう。このことは、例えば通信システムで使用される装置の種類、又は、本発明の方法を実行する際に使用されるメッセージの種類などについても当てはまる。
【００４３】
一方で、上述した詳細事項のうち特定のものを省略しても本発明を実現可能であることは、当業者には明らかなはずである。また、説明の簡明性のために、良く知られているステップ又は要素の幾つかを概略的に示したり、省略したりしたところがある。
【００４４】
本発明のシステム及び方法は、限定されるものではないが、ＩＳＤＮ、ＶｏＩＰ又は他の適切な環境で参照乃至適用可能である。
【図１】
0006355741.tif 000002
【図２】
0006355741.tif 000003