JP2005531999A - パケット交換型電話会議の管理方法、サーバ、及び端末装置 - Google Patents

Abstract

本発明は、複数の端末装置（１３）間でパケット交換型中央集中方式電話会議を管理する方法に関する。ユーザの快適さの改善を可能にするために、上記方法は、電話会議サーバ（１２）においてすべての端末装置（１３）からパケットデータを受信するステップを備えることが提案されている。次いで、これらのデータパケットに基づいて、現在音声データを出力している少なくとも１つの端末装置（１３）が決定される。次のステップで、データパケットで受信されたデータがミックスされ、これらのミックスされたデータは、音声データを出力していると決定された端末装置（１３）の１つに関連づけられた少なくとも１つの識別子と共に、新しいデータパケットの中に挿入され、その結果、データパケット内の少なくとも１つの識別子を他のいずれの情報からも識別することが可能となる。最後に、これらの新しいデータパケットは電話会議に参加している端末装置（１３）へ送信される。本発明は、これに対応するサーバと、同じく対応する端末装置にも同様に関連するものである。

Description

本発明は、複数の端末装置間でのパケット交換型中央集中方式電話会議（packet switched centralized conference call）の管理方法に関する。本発明は、また、中央集中方式電話会議を管理する手段を備えた電話会議サーバと、中央集中方式電話会議に参加する手段を備えた端末装置にも関する。

電話会議では、参加しているユーザのうちの一人が話しているとき、他のすべての参加しているユーザが、発言中の参加者の声を聞くことができるように、１つのグループの端末ユーザが一緒に接続される。このような種類の通信においては、一般に１度に発言するのは参加しているユーザのうちの一人だけであり、一方、その他のユーザたちはそれに耳を傾けることになる。中央集中方式電話会議では、参加しているユーザの端末装置は互いに直接接続されずに、電話会議サーバ（conference call server）を経由して接続される。中央集中方式電話会議は、例えば、インターネットにおけるボイスオーバインターネットプロトコル（ＶｏＩＰ：Voice over Internet Protocol）の電話会議アプリケーションによって実現したり、あるいはユニバーサル移動通信サービス（ＵＭＴＳ：Universal Mobile Telecommunication Services）ネットワークのパケット交換領域（network's packet switched domain）における音声会議として実現したりすることができる。

ＶｏＩＰセッションでは、ボイスデータは一般に、インターネットプロトコル（ＩＰ）の最上部にあるリアルタイムトランスポートプロトコル（ＲＴＰ：Real-time Transport Protocol）と、ユーザデータグラムプロトコル（ＵＤＰ：User Datagram Protocol）を用いることにより運ばれる。ＲＴＰについては、ＲＦＣ１８８９：“ＲＴＰ：リアルタイムアプリケーション用トランスポートプロトコル（A Transport Protocol for Real-Time Applications）”（１９９６年１月、H.Schulzrinne他）に詳細に記載されている。

エンドツーエンドＶｏＩＰ接続（end-to-end VoIP connection）はＶｏＩＰトンネル（VoIP tunnel）と呼ばれる場合が多い。典型的中央集中方式電話会議のセットアップの際に、個々の参加端末装置と電話会議サーバとの間でＶｏＩＰトンネルが形成される。

例として、集中方式の、ＲＴＰベースの電話会議におけるコード化されたボイスのトンネリング（tunneling）を図１に示す。

図１は、ＵＭＴＳネットワーク１１に接続された電話会議サーバ１２と、複数の移動端末装置１３とを備えた、ＵＭＴＳネットワーク１１のパケット交換領域における中央集中方式電話会議システムを概略的に示す図である。移動端末装置１３は、ＲＴＰトンネル１４を用いるＵＭＴＳネットワーク１１を経由して上記の電話会議サーバに接続される。

端末装置１３では、端末装置１３のそれぞれのユーザが出すボイスデータはまず符号化され、次いでＲＴＰパケットのペイロードへ挿入される。実際のボイス符号化を行うために使用可能な多数の代替のオーディオコーダ（audio coder）がある。例えば、第３世代システム用の必須スピーチコーデック（mandatory speech codec）として仕様が定められている適応型マルチレート（ＡＭＲ：Adaptive Multirate）スピーチコーデックは、ＲＴＰペイロードの内部で運ばれるスピーチデータの圧縮に用いることが可能であろう。これらのコーダはスピーチサンプルをフレームに符号化し、それからこれらのフレームは、ＵＭＴＳネットワーク１１を経由してＲＴＰ／ＵＤＰ／ＩＰプロトコルにより電話会議サーバ１２へ運ばれる。

電話会議サーバ１２はＲＴＰミキサ（RTP mixer）１５を備え、このＲＴＰミキサ１５は、接続された端末装置１３から入って来るＲＴＰパケットフローを受け取り、そのＲＴＰパッケージングを取り除き、上記のフローを結合してＲＴＰパケットの単一フローの中へ入れ、次いで、端末装置１３の各々へこのフローを送る。

端末装置１３と電話会議サーバ１２との間で伝送される個々のＲＴＰパケットに対して、ヘッダが関連づけられる。上記で引用したＲＦＣ１８８９で仕様が定められているこのヘッダの構造が図２に例示されている。このヘッダは、採用されたＲＴＰのバージョンを特定するフィールドＶと、パディングビット（padding bit）のためのフィールドＰとを備える。パディングビットがセットされた場合、そのパケットには、そのペイロードの一部ではない端部に１つまたはそれより多い追加のパディングオクテット（padding octet）が含まれる。このヘッダは更に、拡張ビット用フィールドＸを備える。この拡張ビットがセットされた場合、固定ヘッダに丁度１つのヘッダ拡張部（header extension）が従うことになる。このヘッダは更に、固定ヘッダの後に続くＣＳＲＣ識別子の番号を含む寄与ソース（ＣＳＲＣ）カウント（Contributing Source (CSRC) count）用のフィールドＣＣとマーカービット用のフィールドＭとを備え、このマーカーの解釈はプロフィールにより定義される。さらに、このヘッダはペイロードのフォーマットを特定するためのフィールドＰＴと、送信された個々のＲＴＰデータパケットに対して１ずつ増分するシーケンス番号用のフィールドとを備える。受信装置はこのシーケンス番号を使用して、パケット紛失の検出と、パケットシーケンスの復元とを行うことができる。上記のヘッダはまた、ＲＴＰデータパケットにおける第１のオクテットのサンプリング時点を反映するタイムスタンプ（Timestamp）用フィールドも備える。

さらに、ＲＴＰパケットヘッダは、同期ソース（ＳＳＲＣ）識別子（Synchronisation Source (SSRC) identifier）、並びに、ＣＣフィールドと関連して上述したように、寄与ソース（ＣＳＲＣ）識別子のリストを運ぶ。

ＳＳＲＣ識別子を使用して、当該ＲＴＰパケットを伝送した同期ソースが特定される。それぞれのＲＴＰセッションに対して固有のものであるＳＳＲＣ識別子は、個々のありうるソースに、すなわち、端末装置１３の各々と、電話会議サーバ１２にランダムに関連づけられる。個々の端末装置１３は、それに関連づけられたＳＳＲＣ識別子を、この端末装置が組み立てる個々のＲＴＰパケットのＲＴＰヘッダ内のＳＳＲＣ識別子フィールドに追加する。同様に、電話会議サーバ１２のＲＴＰミキサ１５は、サーバ１２を出る個々のＲＴＰパケットのＲＴＰヘッダ内のＳＳＲＣ識別子フィールドに、電話会議サーバ１２に関連づけられたＳＳＲＣ識別子を追加する。

ＣＳＲＣリストは、ＲＴＰパケットに寄与する異なるソースを特定するために使用され、したがって、ＣＳＲＣリストは、電話会議サーバ１３内に組み立てられたＲＴＰパケットとの関連性だけをもつ。ＲＴＰミキサ１５は、結合されたアウトバウンドＶｏＩＰフロー（outbound VoIP flow）に寄与する当該端末装置１３のＳＳＲＣ識別子を送出ＲＴＰパケットのＣＳＲＣフィールドに追加する。

ＲＴＰを用いるＶｏＩＰ接続の制御を可能にするために、リアルタイム制御プロトコル（ＲＴＣＰ：Real Time Control Protocol）が上記で引用したＲＦＣ１８８９に規定されている。ＲＴＣＰは、例えば、双方の接続の端部に、これらの端部が出したり、受けたりしているサービスの品質についての情報を与え続けるために使用される。この情報は、ＲＴＣＰ送り手側レポート（ＳＲ：sender report）と受け手側レポート（ＲＲ：receiver report）のパケットタイプで送られる。さらに、ＲＴＰ仕様はＲＴＣＰソース記述（ＳＤＥＳ）パケットタイプ（RTCP source description (SDES) packet type）を規定している。このソースは、ＲＴＣＰ ＳＤＥＳパケットを使用して、ソース自身に関するさらに多くの情報を提供することが可能である。ＳＤＥＳ ＣＮＡＭＥパケットまたはＮＡＭＥパケットを用いて、例えば、ランダムなＳＳＲＣ識別子とソースアイデンティティ（source identity）との間でマッピングを行うことが可能である。ＳＤＥＳ ＣＮＡＭＥパケットが標準エンドポイント識別子（canonical end-point identifier）の提供を意図するものであるのに対して、ＳＤＥＳ ＮＡＭＥパケットは、それぞれのソースを記述するために使用される実際の名称の提供を意図するものである。ＲＴＰミキサ１５は、すべての端末装置１３からのＳＲタイプとＲＲタイプのＲＴＣＰパケットを、それらを転送する前に結合するものと予想される。これと対照的に、ＳＤＥＳタイプのＲＴＣＰパケットは、変更なしでＲＴＰミキサ１５によってすべての会議参加者１３に転送される。

電話会議では、誰が発言しているかを参加しているユーザがすぐに認識することが時として困難なことがある。これは、多数の電話会議に参加しているユーザがいて、これらの参加しているユーザ同士が互いにあまりよく知らない場合、特に問題となる。

上記で引用したＲＦＣ１８８９には、オーディオ会議の例示アプリケーションが記載されており、このオーディオ会議では、ミキサが、その発言者のスピーチが結合されて発信パケット（outgoing packet）が生成されるすべての発言者を指示し、これによって、すべてのオーディオパケットが、同じＳＳＲＣ識別子、即ちミキサのそれを含んでいるのに、受信装置は現在の話者を示すことができる。

しかしながら、スピーチコーデックのどのような合理的なＶｏＩＰの使用時にも、コーデックは、それぞれの会議参加者がアクティブでない（即ち、傾聴中である）限りは、受信端で快適騒音（comfort noise）の発生を可能にする無音記述子（ＳＩＤ）フレーム（Silence Descriptor (SID) frame）を送り出すことになる。したがって、すべてのソースによって電話会議サーバ１２へ送信される信号が常に生成されることになる。電話会議サーバ１２は、参加者の各々から受信したＶｏＩＰフローを復号化してスピーチまたはＳＩＤフレームへ戻し、端末装置１３へ送信されるアウトバウンドのスピーチとＳＩＤフレームとを符号化する前に加重（summation）を行うようにする。これは、すべての端末装置１３のＳＳＲＣ識別子が、ミキサ１５によって、送出するミックスされたＲＴＰパケットのＣＳＲＣリストの中に含められることを意味し、したがって、受信端末１３がアクティブな参加者をアクティブでない参加者と区別することが不可能となる。すべての参加端末装置１３のＳＳＲＣ識別子を上記のＣＳＲＣリストの中に含むことはまた、例えば、会議に参加している他のすべてのユーザの番号とアイデンティティについて、個々の参加しているユーザをいつも最新のものに保つためにも、その利点があることにも留意しなければならない。

参加しているユーザの、ボイスオーバＩＰ電話会議中の快適さを向上させることが本発明の目的である。

上記の目的は、複数の端末装置間でのパケット交換型中央集中方式の電話会議を管理する方法で、第１のステップとして、電話会議に参加しているすべての端末装置からデータパケットを電話会議サーバで受信するステップを含む方法を用いる本発明により達せられる。これらのデータパケットには、ボイスデータまたはバックグラウンドノイズ情報とこれらボイスデータまたはバックグラウンドノイズ情報を提供するそれぞれの端末装置に関連づけられた識別子が含まれる。第２のステップでは、もし何らかのボイスデータが存在する場合には、ボイスデータを現在提供している少なくとも１つの端末装置が、受信したデータパケットに基づいて電話会議に参加している端末装置間で決定される。もし電話会議に参加しているユーザの誰もしばらくの間発言していない場合には、端末装置のいずれもしばらくの間ボイスデータを提供しないことになることは明らかであり、ボイスデータを提供する端末装置の決定を行うことはできない。第３のステップでは、受信したボイスデータとバックグラウンドノイズ情報とがミックスされ、もし何らかのボイスデータが存在する場合には、ボイスデータを現在提供していると決定された端末装置の１つに関連づけられた少なくとも１つの識別子と共に、上記の受信ボイスデータとバックグラウンドノイズ情報は新しいデータパケットの中に挿入される。この識別子は、含まれている他のいずれの情報からも上記の識別子を識別できるような方法で、データパケットの中に含まれる。このことは、特に、必ずしもボイスデータを提供する端末装置に関連づけられているとはかぎらない含まれている可能性のある他の識別子から、少なくとも１つの識別子を識別できることを暗に意味するものである。最後に、電話会議サーバによって新しいデータパケットが電話会議に参加している端末装置に伝送される。

本発明の目的は、同様に、上記の提案した方法を実現するための手段を備えた電話会議サーバを用いて達せられる。

さらに、本発明の目的は、中央集中方式電話会議に参加するための手段で、本発明に基づいて電話会議サーバにより伝送される情報を使用するのに適している手段を備えた端末装置を用いて達せられる。上記の端末装置は、電話会議サーバにより転送されるデータパケットを受信するための手段を上記の目的のために備えている。これらのデータパケットは、電話会議に参加している端末装置によって提供されるミックスされたボイスデータおよび／またはバックグラウンドノイズ情報と、もし何らかのボイスデータが存在する場合には、ボイスデータを現在提供していると電話会議サーバで決定された端末装置に関連づけられた少なくとも１つの識別子とを含む。さらに、上記の端末装置は、ボイスデータを現在提供していると電話会議サーバで決定された端末装置に関連づけられた識別子を受信データパケットにおいて認識する手段を備える。さらに、この端末装置は、ボイスデータを現在提供していると電話会議サーバで決定された端末装置に関連づけられた認識された識別子に基づいて、ボイスデータを提供している端末装置の識別（identification）をユーザに対して指し示すための手段を備える。

本発明は、現在アクティブな、すなわちボイスデータを提供している電話会議の参加者と、現在アクティブでない、すなわちバックグラウンドノイズ情報のみを提供している参加者とを識別することができるように電話会議サーバを設計することが可能であるという着想から生じたものである。本発明は、更に、端末が対応する情報を受信した場合、ユーザに対して、電話会議の現在アクティブな参加者を指し示すことができるように端末装置を設計することが可能であるという着想から生じたものである。したがって、電話会議サーバが電話会議の現在アクティブな参加者を決定することと、サーバが、対応する、識別可能な表示を電話会議に参加している端末装置に送ることが提案される。

本発明によって、アクティブな会議参加者に関する伝送された情報をユーザに示すことができるので端末装置の改良されたユーザインタフェースが可能となることが本発明の利点である。したがって、電話会議の参加者は、すべての参加者の中でアクティブな発言者を常に特定できることになる。

本発明の好適な実施形態は従属クレームから明らかとなる。

アクティブな端末装置の識別子は種々の方法で電話会議サーバにより伝送することが可能である。

第１の代替方法では、電話会議サーバは、個々の結合されたデータパケットで、現在アクティブな当該端末装置に関連づけられた識別子を排他的に伝送する。受信端末は、複数の同時に話す話者が存在する場合であっても、すべてのアクティブな話者を受信端末のユーザに示すことができることがこのアプローチの利点である。しかしながら、このアプローチでは、受信端末は、すべての参加者について受信端末のユーザを最新のものに保つことはできない。

第２の代替方法では、電話会議サーバは、個々の結合されたデータパケットで、会議に参加しているすべての端末装置に対する識別子を伝送するが、アクティブな端末装置に関連づけられた識別子が、識別子のリスト内の所定の場所に、例えば、そのリスト内の第１のエレメントとして常にリストアップされるようにする。このアプローチは、すべての会議参加者に関する最新の情報を絶えず提供するが、２つ以上のアクティブな端末装置を同時に示すことを可能にするものではない。しかしながら、理性的な討論においては、特に電話接続を介する場合は、１度に発言するのは一人の参加者だけであり、上記の問題は重要な問題ではないと考えることができる。

第３の代替方法は、第２のアプローチの改善により与えられるものである。この第３のアプローチでは、電話会議サーバはこの場合もまた会議に参加しているすべての端末装置に対する識別子を個々の結合されたデータパケットで常に伝送する。現在アクティブな端末装置に関連づけられた識別子は識別子のリストの初めにリストアップされる。さらに、いくつかのマーカーが、現在アクティブな端末装置に関連づけられた識別子と、現在アクティブでない端末装置に関連づけられた識別子との間に挿入される。この第３のアプローチは、単に１つの、伝送されるべき追加の値を導入することにより、第１と第２のアプローチの利点を組み合わせるものである。

それぞれの端末装置に関連づけられた識別子は、例えばランダムに配分されるＳＳＲＣ識別子のように、送信端末を受信端末で特定するのにそれ自体では適していないと考えられる。この場合、それぞれの端末装置の明確な識別（clear identification）に対する識別子のマッピングが、すべてのありうる送信端末から電話会議サーバにまず伝送され、次いで、さらに続けてすべてのありうる受信端末に上記のマッピングが伝送されるのが好適である。次いで、個々の受信端末は送信端末に関連づけられたその後受信される識別子をこの端末装置の対応する識別にマッピングすることができる。この識別は特にＳＩＰアドレスまたは電話番号であってもよい。受信端末はまた、別の種類の識別に上記の決定された識別を更にマッピングすることもできる。この識別が例えばＳＩＰアドレスまたは電話番号などである場合には、端末装置はこのアドレスまたは番号を受信端末のディレクトリに格納された名称または画像にマッピングすることができる。

電話会議のすべての参加者を端末装置のユーザに対して示す場合は、任意の適切な方法でユーザに対してアクティブな参加者を指し示すことができる。

排他的にというわけではないが、特に、中央集中方式電話会議が上記の引用したＲＦＣ１８８９に規定されているＲＴＰに基づいているシステムで、本発明を採用することができる。この場合、端末装置から電話会議サーバへ伝送されるデータパケット、及び、電話会議サーバから端末装置へ伝送されるデータパケットはＲＴＰパケットである。結合されたＲＴＰパケットで電話会議サーバにより伝送された端末装置の識別子は、ＲＴＰヘッダのＣＳＲＣリストに追加されたＳＳＲＣ識別子とすることが有利にできる。電話会議サーバによる識別子の伝送のために提示された上記の第３の代替方法では、採用されたマーカーは、例えば、電話会議サーバに関連づけられたＳＳＲＣ識別子などとすることができる。電話会議サーバに関連づけられたＳＳＲＣ識別子は個々の結合されたＲＴＰパケットのＲＴＰヘッダのＳＳＲＣフィールドでどのようにでも伝送されるので、受信端末はこの値についての知識を有し、この知識を利用して、アクティブでない端末装置からアクティブな端末装置をＣＳＲＣリストにおいて分離することができる。これと対照的に、従来のアプリケーションでは、電話会議サーバに関連づけられたＳＳＲＣ識別子は送出結合ＲＴＰパケット（outgoing combined RTP packet）のＳＳＲＣフィールドにだけ含まれ、ＣＳＲＣリストには含まれていない。これは、電話会議サーバ自体は結合されたＲＴＰフローに寄与しないからである。

電話会議サーバにより識別子の伝送のために示された上記３つの代替方法の各々は、現行のＲＴＰ仕様に準拠するものであり、特別のＳＳＲＣ／ＣＳＲＣ処理を使用するように設計されていない実施構成（implementation）を損なうものではない。

ＲＴＰベースのシステムで実行される本発明による方法の包括的な実施形態は３つの部分を備えるのが有利である。第１の部分は、ＲＴＰソース識別子を交換し、個々の端末装置または端末ユーザのそれぞれのアイデンティティに対して当該識別子をＲＴＣＰ ＳＤＥＳパケットによってマッピングするための、電話会議に参加している端末装置に対するメカニズムに存在する。第２の部分は、予め定義された規定に従ってＲＴＰヘッダのＣＳＲＣフィールドをセッティングするための、電話会議サーバで実施されるメカニズムに存在する。第３の部分は、受信端末のユーザに対する現在アクティブな話者のアイデンティティの表示を可能にするために、ＲＴＰパケットヘッダのＣＳＲＣフィールド内の識別子を端末装置またはユーザアイデンティティに対してマッピングするための、電話会議に参加している受信端末で実施されるメカニズムに存在する。

電話会議サーバにより参加端末装置へ伝送することができる識別子の数および／または受信端末により示すことができる参加者の数は、所定値に限定することができることに留意すべきである。例えば、上記で引用したＲＦＣ１８８９によれば、ＣＳＲＣリストは最大数１５エントリに限定される。

本発明はインターネットまたはＵＭＴＳパケット交換型の音声会議（voice conferencing）用として採用することができる。ＵＭＴＳの場合、アクティブな参加者に関する情報は、例えば移動端末装置のスクリーンなどに表示することができる。

本発明の他の目的と特徴は、添付図面と関連して考察される以下の詳細な説明から明らかになる。

図１〜図３を参照しながら本発明による方法の実施形態について以下に説明する。

本実施形態は、ＶｏＩＰ電話会議の管理をサポートするものであり、ＵＭＴＳネットワーク１１と、ネットワーク１１と接続されたＲＴＰミキサ１５を含む電話会議サーバ１２と、複数の端末装置１３とを備えたＲＴＰベースのシステムで実施される。端末装置１３は、ＲＴＰトンネル１４によってＵＭＴＳネットワーク１１を経由して電話会議サーバ１２と接続することができる。したがって、本システムは、一般に、すでに上述した図１に例示のシステムに相当する。

本システムにおいてＶｏＩＰ電話会議をセットアップするために、シグナリングプロトコルとしてセッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）が用いられる。ＳＩＰはセッション記述プロトコル（ＳＤＰ：Session Description Protocol）と共に用いられて、送信勧誘（invitation）が被呼者（called party）に送られ、ボイスコーデックなどの同意が行われる。端末装置１３のユーザは、電話会議サーバ１２にＳＩＰ送信勧誘メッセージ（SIP INVITE message）を送信するか、あるいは、電話会議サーバ１２を経由して受信した送信勧誘メッセージに応答するかのいずれかにより自分でセッションを開始することにより会議に参加する。

会議セッションの開始時に、個々の端末装置１３での会議用ソフトウェアによって、電話会議サーバ１２にＲＴＣＰ ＳＤＥＳパケットが送られる。これらのＳＤＥＳパケットは、上記セッション用のそれぞれの端末装置１３に関連づけられたＳＳＲＣ識別子を運び、さらに、ＳＤＥＳ項目フィールド（SDES items field）にそれぞれの端末装置１３のＳＩＰアドレスまたは電話番号を運ぶ。電話会議サーバ１２は、受信したＳＤＥＳパケットを電話会議に参加する個々の端末装置１３へ転送する。これらのパケット内の情報に基づいて、端末装置１３は、会議セッション中に受信したＳＳＲＣ識別子を、対応するＳＩＰアドレスまたは電話番号にマッピングする準備ができる。

会議セッションがアクティブになると、会議に参加するすべての端末装置１３が電話会議サーバ１２にＲＴＰパケットを伝送する。端末装置１３は、この目的のために、その入力にスピーチがあるとき、即ち端末装置１３のユーザが発言しているときには、通常レート（normal rate）で伝送を行い、また、ソースが無音のとき、即ち端末装置１３のユーザが他の参加者の話を傾聴しているときには、低減したレートで伝送を行うような方法で、例えばＡＭＲスピーチコーデック（AMR speech codec）などのスピーチコード（speech code）を採用する。第１のケースでは、スピーチコーデックはボイスデータを符号化し、ＲＴＰパケットのペイロードで伝送を行う。後者のケースでは、スピーチコーデックは、受信装置での快適騒音（comfort noise）の発生に必要なバックグラウンドノイズ推定値（background noise estimate）を運ぶＳＩＤフレームを生成し、このフレームを伝送する。この場合、この受信装置は電話会議サーバ１２である。

電話会議サーバ１２のＲＴＰミキサ１５は、復号化されたスピーチの加重と、結合されたスピーチの符号化とを可能にするために、すべての入ってくるストリームを復号化する。それぞれの採用されたデータ転送レート（data rate）に基づいて、電話会議サーバ１２は、復号化処理のサイド情報（side information）として、当該復号化信号がスピーチであるかバックグラウンドノイズ推定値であるかどうかに関する指示を取得する。

その後、電話会議サーバ１２のＲＴＰミキサ１５は、すべてのソース１３からの、復号化されたボイスデータと、バックグラウンドノイズ推定値とを一緒にミックスし、符号化され結合されたデータフローを有するＲＴＰパケットを組み立てる。個々の組み立てられたＲＴＰパケットは、すでに上述した図２に例示した構造に対応する構造を有するＲＴＰヘッダを備える。したがって、個々のＲＴＰヘッダは、ＳＳＲＣ識別子用のフィールドと、ＣＳＲＣリスト用のフィールドとを備える。

ＲＴＰミキサ１５は現在の電話会議用の電話会議サーバ１２に関連づけられたＳＳＲＣ識別子をアウトバウンドＲＴＰパケットのＲＴＰヘッダのＳＳＲＣ識別子フィールドに挿入する。これは、電話会議サーバ１２はこれらのＲＴＰパケット用のソースであるからである。

さらに、ＲＴＰミキサ１５はＲＴＰヘッダのＣＳＲＣリスト内の結合されたＲＴＰパケットに寄与する当該端末装置１３に関連づけられたＳＳＲＣ識別子を含む。電話会議に参加しているすべての端末装置１３は、ボイスデータか、バックグラウンドノイズ推定値かのいずれかと共に電話会議サーバ１２にＲＴＰパケットを常に伝送しているので、ＣＳＲＣリストは、すべての参加端末装置１３用のＳＳＲＣ識別子を常に含んでいる。しかしながら、ＲＴＰミキサ１５は、アクティブに参加している端末装置１３に関連づけられたＳＳＲＣ識別子がＣＳＲＣリスト内の第１のエレメントとして含まれるように処理する。

さらに、ＲＴＰミキサ１５は、電話会議サーバ１２に関連づけられたＳＳＲＣ識別子をもＣＳＲＣリストに挿入する。さらに詳細に述べると、電話会議サーバ１２に関連づけられたＳＳＲＣ識別子は、ＣＳＲＣリストの最初に配置されたアクティブな端末装置１３に関連づけられたＳＳＲＣ識別子と、ＣＳＲＣリストの最後に配置されたアクティブでない端末装置１３に関連づけられたＳＳＲＣ識別子との間のマーカー（marker）として含まれる。

次いで、電話会議サーバ１２は個々の参加端末装置１３に合成フロー（composite flow）を転送する。

端末装置１３は、ＵＭＴＳネットワーク１４を経由して電話会議サーバ１２によって伝送されたＲＴＰパケットを受け取り、ＲＴＰパケットのヘッダのそれぞれのＣＳＲＣリストの中に含まれるＳＳＲＣ識別子を検索する。次いで、以前に受信したマッピング情報に基づいて、端末装置１３は、ＣＳＲＣリストから検索したＳＳＲＣ識別子に対応するＳＩＰアドレスまたは電話番号を決定する。端末装置１３は、電話会議サーバ１２に関連づけられたＳＳＲＣ識別子に対するこのようなマッピングを実行しない。このＳＳＲＣ識別子は、ＲＴＰヘッダのＳＳＲＣ識別子フィールドに含まれる同一のＳＳＲＣ識別子に基づいて、端末装置１３によって認識される。端末装置１３は、更に、利用可能な限り、上記の決定されたＳＩＰアドレスまたは電話番号に対して、端末装置の内部アドレスディレクトリ（internal address directory）で関連づけられている名称を決定する。次いで、これらの決定された名称は、端末装置１３のディスプレイ上でそれぞれのユーザに対してリストの形で示される。

図３はこのようなディスプレイ３１の実施形態を示す図であり、このディスプレイ３１によって、別の情報およびオプションに加えて、現在進行中の電話会議に参加しているユーザの氏名を有するリスト３２が提示される。

さらに、端末装置１３は、電話会議サーバ１２に関連づけられたＳＳＲＣ識別子の前にリストに記載された、ＣＳＲＣリスト内のすべての当該ＳＳＲＣ識別子を決定する。当該ＳＳＲＣ識別子に対して決定された名称は現在アクティブな参加者に属し、ディスプレイ３１に提示されたリスト３２で指示される。図３の例では、現在発言している参加者を示すために、特別の発言者インディケータアイコン３３が採用されている。示されている状況では、ただ一人の参加者が現在発言中であり、発言者インディケータアイコン３３が、リスト３２内の対応する氏名“Ｓａｉｍｉ”の隣に置かれている。

したがって、端末装置１３のユーザは、電話会議に参加しているすべてのユーザの識別を常に見て、現在発言している参加者をアクティブでない参加者と識別することが可能となる。

記載した実施形態は、本発明の種々の可能な実施形態のうちの１つを構成するものに過ぎないことが理解される。

ＲＴＰベースの中央集中方式電話会議システムの原理を示す図である。 ＲＴＰヘッダの構造を示す図である。 本発明による方法の実施形態を使用する端末装置のユーザインタフェースを示す図である。

Claims (10)

1. 複数の端末装置（１３）間でのパケット交換型集中方式電話会議の管理方法であって、電話会議サーバ（１２）において、
   前記電話会議に参加するすべての端末装置（１３）からデータパケットを受信するステップであって、該データパケットが、ボイスデータまたはバックグラウンドノイズ情報のいずれか、並びに、前記ボイスデータまたは前記バックグラウンドノイズ情報を提供するそれぞれの前記端末装置（１３）に関連づけられた識別子を含むステップと、
   前記の受信したデータパケットに基づいて、前記電話会議に参加している前記端末装置（１３）の間で、もし何らかのボイスデータが存在する場合には、ボイスデータを現在提供している少なくとも１つの端末装置（１３）を決定するステップと、
   前記受信したボイスデータと前記の受信したバックグラウンドノイズ情報とをミックスして、もし何らかのボイスデータが存在する場合には、ボイスデータを現時点で提供していると決定された前記端末装置（１３）の１つに関連づけられた少なくとも１つの識別子と共に、新しいデータパケットの中に前記のミックスされたデータを挿入して、前記データパケットの中に含まれる他のいずれの情報からも前記少なくとも１つの識別子を識別できるようにするステップと、
   前記電話会議に参加する端末装置（１３）に前記新しいデータパケットを伝送するステップと、を具備するパケット交換型電話会議の管理方法。
2. 前記端末装置（１３）に関連づけられた前記識別子が、前記電話会議用の前記端末装置（１３）にランダムに関連づけられた識別子であり、前記ステップに先行するステップとして、前記電話会議サーバ（１２）で前記電話会議に参加する前記端末装置（１３）から制御パケットを受信するステップを含む前記方法であって、前記制御パケットが、前記端末装置（１３）の識別に対するそれぞれの端末装置（１３）に関連づけられた識別子のマッピングを含み、前記電話会議サーバ（１２）から前記電話会議に参加する前記端末装置（１３）に、前記制御パケットにおける前記マッピングを転送するステップを含む、請求項１に記載の方法。
3. 前記電話会議サーバ（１２）は、ボイスデータを提供していると決定された端末装置（１３）に関連づけられた識別子を前記新しいデータパケットで排他的に伝送する請求項１または２に記載の方法。
4. 前記電話会議サーバ（１２）は、ボイスデータを現在提供している端末装置（１３）に関連づけられた識別子と、バックグラウンドノイズ情報を現在提供している端末装置に関連づけられた識別子とを前記新しいデータパケットの中に含み、ボイスデータを提供していると決定された端末装置（１３）に関連づけられた少なくとも１つの識別子が、すべての含まれている識別子の間の所定位置で前記データパケットの中に含まれる請求項１または２に記載の方法。
5. 前記電話会議サーバ（１２）は、ボイスデータを現在提供している端末装置（１３）に関連づけられた識別子と、バックグラウンドノイズ情報を現在提供している端末装置（１３）に関連づけられた識別子とを前記新しいデータパケットの中に含み、もし何らかのボイスデータが存在する場合には、ボイスデータを提供していると決定された前記端末装置（１３）の１つに関連づけられた少なくとも１つの識別子が、すべての含まれている識別子の間の所定位置で前記データパケットの中に含まれ、また、ボイスデータを提供していると決定された端末装置（１３）に関連づけられた識別子が、他の端末装置（１３）に関連づけられた、パケットに含まれる識別子からマーカーによって分離される請求項１または２に記載の方法。
6. 前記マーカーは、前記電話会議サーバ（１２）に関連づけられた識別子に相当する請求項５に記載の方法。
7. 前記電話会議はリアルタイムトランスポートプロトコル（ＲＴＰ）に基づくものであり、前記データパケットはＲＴＰパケットであり、前記端末装置（１３）に関連づけられた前記識別子は同期ソース（ＳＳＲＣ）識別子であり、また、前記識別子は、前記電話会議サーバ（１２）によって、寄与ソース（ＣＳＲＣ）リスト用にパケットヘッダに備えられるフィールドに対して前記新しいデータパケットの中に含まれる請求項１から６までのいずれか一項に記載の方法。
8. 前記電話会議に参加する端末装置（１３）で前記電話会議サーバ（１２）により伝送される前記新しいデータパケットを受信するステップと、前記の受信した新しいデータパケットの中に含まれる識別子に基づいてユーザにボイスデータを提供していると決定された少なくとも１つの端末装置（１３）の識別（３２、３３）を指示するステップと、をさらに具備する請求項１から７までのいずれか一項に記載の方法。
9. 複数の端末装置（１３）間で集中方式電話会議を管理する手段を含む電話会議サーバ（１２）であって、前記手段が、請求項１から７までのいずれか一項に記載の方法のステップを実現する手段（１５）を具備する電話会議サーバ。
10. 集中方式電話会議に参加する手段を含む端末装置（１３）であって、前記手段は、
    電話会議サーバ（１２）によって転送されるデータパケットを受信する手段であって、該データパケットは、前記電話会議に参加している端末装置（１３）により提供されるミックスされたボイスデータおよび／またはバックグラウンドノイズ情報と、もし何らかのボイスデータが存在する場合には、ボイスデータを現在提供していると前記電話会議サーバ（１２）で決定された端末装置（１３）に関連づけられた少なくとも１つの識別子とを含む手段と、
    ボイスデータを現在提供していると電話会議サーバ（１２）で決定された端末装置（１３）に関連づけられた識別子を受信データパケットで認識する手段と、
    ボイスデータを現在提供していると電話会議用サーバ（１２）で決定された認識済みの端末装置（１３）に関連づけられた識別子に基づいてボイスデータを提供する端末装置（１３）の識別をユーザに対して指示する手段と、を具備する端末装置。

Images