(57)【特許請求の範囲】
【請求項１】
コンピュータにより実行される方法であって、
第１の音声入力クライアントから第１の入力を受信するステップであって、前記第１の入力は前記第１の音声入力クライアントが音声イベントにおける第１のアクティブな参加者であることを示し、前記音声イベントはアクティブな参加者及びアクティブでない参加者を含む、ステップと、
第２の音声入力クライアントから第２の入力を受信するステップであって、前記第２の入力は前記第２の音声入力クライアントが前記音声イベントにおける第２のアクティブな参加者であることを示す、ステップと、
第３の音声入力クライアントから第３の入力を受信するステップであって、前記第３の入力は前記第３の音声入力クライアントが前記音声イベントにおける第３のアクティブな参加者であることを示す、ステップと、
第１の識別子を前記第１の音声入力クライアントに、第２の識別子を前記第２の音声入力クライアントに、及び第３の識別子を前記第３の音声入力クライアントに関連付けるステップと、
前記第１、第２及び第３の入力を受信した場合に、前記第１の音声入力クライアントが前記第２及び第３の音声入力クライアントよりも支配的な話し手であることを確認するステップと、
前記第１の音声入力クライアントのアクティブな参加者が前記第２及び第３の音声入力クライアントのアクティブな参加者よりも支配的な話し手であることの確認に基づいて、リアルタイムトランスポートプロトコル（ＲＴＰ）の貢献ソースのリスト（ＣＳＲＣ）において前記第１の識別子を前記第２の識別子及び前記第３の識別子より上位に並び方を決定するステップであって、前記第１の識別子は前記第１、第２及び第３のアクティブなクライアントの相対的な関係を示すように前記ＣＳＲＣのリストのトップにあり、アクティブでない参加者は前記リストに含まれない、ステップと、
前記第１の識別子、前記第２の識別子及び前記第３の識別子が並んだ前記リストをパケットヘッダに挿入するステップと
を有する方法。
【請求項２】
前記リストは現在のアクティブな音声入力クライアントから始まる並び方で並ぶようにホスト混合音声ストリームによって決定される、請求項１記載の方法。
【請求項３】
前記各クライアントについて、正規名（ＣＮＡＭＥ）と、前記ＣＮＡＭＥにマッピングされた同期ソース（ＳＳＲＣ）識別子とを送信するステップを更に有する請求項１記載の方法。
【請求項４】
前記ＣＮＡＭＥ及び関連するＳＳＲＣは、前記各クライアントについてリアルタイムコントロールプロトコル（ＲＴＣＰ）レコードから得られる、請求項３記載の方法。
【請求項５】
前記ＣＮＡＭＥ及び関連するＳＳＲＣは、聴取しているクライアントにＲＴＣＰパケットで送信される、請求項４記載の方法。
【請求項６】
前記ＣＮＡＭＥ及びＳＳＲＣを、聴取しているクライアントのローカルメモリに格納するステップを更に有する請求項１記載の方法。
【請求項７】
支配的なクライアントが、エネルギーレベル、無言の期間、持続時間又はパケットサイズのうちの少なくとも１つに基づいて決定される、請求項１記載の方法。
【請求項８】
前記クライアントがセッションの中でソース伝送アドレスを変更した場合、クライアントの正規名（ＣＮＡＭＥ）で同期ソース（ＳＳＲＣ）の識別子を更新するステップを更に有する請求項１記載の方法。
【請求項９】
１つ以上のコンピュータにより読み取ることが可能なメモリであって、実行された場合にコンピュータシステムに方法を実行させる命令を格納し、前記方法は、
第１の音声入力クライアントから第１の入力を受信するステップであって、前記第１の入力は前記第１の音声入力クライアントが音声イベントにおける第１のアクティブな参加者であることを示し、前記音声イベントはアクティブな参加者及びアクティブでない参加者を含む、ステップと、
第２の音声入力クライアントから第２の入力を受信するステップであって、前記第２の入力は前記第２の音声入力クライアントが前記音声イベントにおける第２のアクティブな参加者であることを示す、ステップと、
第３の音声入力クライアントから第３の入力を受信するステップであって、前記第３の入力は前記第３の音声入力クライアントが前記音声イベントにおける第３のアクティブな参加者であることを示す、ステップと、
第１の識別子を前記第１の音声入力クライアントに、第２の識別子を前記第２の音声入力クライアントに、及び第３の識別子を前記第３の音声入力クライアントに関連付けるステップであって、音声入力クライアント各々は正規名（ＣＮＡＭＥ）及び同期ソース（ＳＳＲＣ）識別子に関連している、ステップと、
前記第１、第２及び第３の入力を受信した場合に、前記第１の音声入力クライアントが前記第２及び第３の音声入力クライアントよりも支配的な話し手であることを確認するステップと、
前記第１の音声入力クライアントのアクティブな参加者が前記第２及び第３の音声入力クライアントのアクティブな参加者よりも支配的な話し手であることの確認に基づいて、会議に関する１人以上のアクティブな音声入力クライアントのリストにおける並び方を決定するステップであって、前記第１、第２及び第３のアクティブなクライアントの相対的な関係を示すように、前記第１の識別子は前記リストにおいて前記第２及び前記第３の識別子より上位にあり、アクティブでない参加者は前記リストに含まれない、ステップと、
前記並び方が決定されたリストを、１つ以上のオーディオストリームにおけるリアルタイムプロトコル（ＲＴＰ）貢献ソースリスト（ＣＳＲＣ）フィールドに挿入するステップと
を有するメモリ。
【請求項１０】
前記並び方が決定されたリストは支配的なアクティブなクライアントから始まる、請求項９記載のメモリ。
【請求項１１】
エネルギーレベル、無言の期間、持続時間又はパケットサイズのうちの少なくとも１に基づいて支配的なクライアントを決定するステップを前記方法が更に有する、請求項１０記載のメモリ。
【請求項１２】
前記ＳＳＲＣ識別子は１つ以上の受信した音声ストリームのためのコントロールパケットから得られた前記ＣＮＡＭＥにマッピングされる、請求項９記載のメモリ。
【請求項１３】
前記コントロールパケットはリアルタイムコントロールプロトコル（ＲＴＣＰ）に準拠している、請求項１２記載のメモリ。
【請求項１４】
前記ＳＳＣＲ及び前記ＣＮＡＭＥはリアルタイムコントロールプロトコル（ＲＴＣＰ）パケットに含まれる、請求項１３記載のメモリ。
【請求項１５】
１人以上のアクティブなクライアントに含まれる支配的でアクティブな音声クライアントに、他の音声クライアントはアクティブでないことの通知を提供するステップを前記方法が更に有する、請求項９記載のメモリ。
【請求項１６】
方法を実行するメディアサーバを有するシステムであって、前記方法は、
第１の音声入力クライアントから第１の入力を受信するステップであって、前記第１の入力は前記第１の音声入力クライアントが音声イベントにおける第１のアクティブな参加者であることを示し、前記音声イベントはアクティブな参加者及びアクティブでない参加者を含む、ステップと、
第２の音声入力クライアントから第２の入力を受信するステップであって、前記第２の入力は前記第２の音声入力クライアントが前記音声イベントにおける第２のアクティブな参加者であることを示す、ステップと、
第３の音声入力クライアントから第３の入力を受信するステップであって、前記第３の入力は前記第３の音声入力クライアントが前記音声イベントにおける第３のアクティブな参加者であることを示す、ステップと、
第１の識別子を前記第１の音声入力クライアントに、第２の識別子を前記第２の音声入力クライアントに、及び第３の識別子を前記第３の音声入力クライアントに関連付けるステップと、
前記第１、第２及び第３の入力を受信した場合に、前記第１の音声入力クライアントが前記第２及び第３の音声入力クライアントよりも支配的な話し手であることを確認するステップと、
前記第１の音声入力クライアントのアクティブな参加者が前記第２及び第３の音声入力クライアントのアクティブな参加者よりも支配的な話し手であることの確認に基づいて、リアルタイムトランスポートプロトコル（ＲＴＰ）の貢献ソースのリスト（ＣＳＲＣ）において前記第１の識別子を前記第２の識別子及び前記第３の識別子より上位に並び方を決定するステップであって、前記第１の識別子は前記リストのトップにあり、アクティブでない参加者は、前記第１、第２及び第３のアクティブなクライアントの相対的な関係を示す前記リストには含まれない、ステップと、
前記第１の識別子、前記第２の識別子及び前記第３の識別子が並んだ前記リストをパケットヘッダに挿入するステップと
を有する、システム。
【請求項１７】
前記並び方が決定されたリストは、前記支配的なクライアントから受信したメディアストリームに関連するエネルギーレベル、無言の期間、持続時間、又はパケットサイズのうちの少なくとも１つに基づく支配的なクライアントを示している、請求項１６記載のシステム。
【請求項１８】
前記メディアサーバは、送信メディアストリームを受信するクライアントに、正規名（ＣＮＡＭＥ）と、リアルタイムコントロールプロトコル（ＲＴＣＰ）パケットにおける前記アクティブなクライアントについての前記ＣＮＡＭＥにマッピングされた前記同期ソース（ＳＳＲＣ）識別子とを含むアクティブクライアント識別子を送信する、請求項１６記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
メディア会議参加者は他のメディア会議参加者と識別する難しさを持っている。参加者は発言者の声又は顔となじみがなかったり、又は音声のやり取りをしたりすることは聞き手を混乱させる。後者の場合には、様々な参加者が同時に話していたり、又は複数の参加者間の早いやり取りがあったりするならば、聞き手、話しているか否かの区別が付かない。ある場合には、発言者は名前「ボブです．．．．。」を含むか、聞き手は前の発言者の身元を尋ねる。この問題の複雑さは、話すか又は音声入力に貢献する(contributing)参加者の数が増えるほど増大する。聞き手が会話の中で「文脈の手がかり」から発言者の身元を見いだす一方、ある場合には、どの参加者が音声入力をしているかを参加者は理解していない。
【発明の概要】
【発明が解決しようとする課題】
【０００２】
加えて、情報を担う帯域幅消費又はデータ処理量の最小化が望まれている。例えば、データを伝送するための物理的接続が追加の処理能力を有する一方、ユーザが限定したネットワーク帯域幅を有したならば、消費する通信リンクリソースは他のデータ転送に利用可能な能力を減少させるか又は会議音声データ転送に影響を与える。
【０００３】
メディア会議改善の受け入れはその改善が「過去との互換性」がないならば、限定される。例えば、変更が存在するプロトコル及びバージョンと一致しないならば、ユーザは変更したバージョンを実装する参加者と通信するために更新したバージョンを得るか、及び／又は組織の承認を探さなければならない。上記の状況は変更した技術の受け入れを妨げている。
【課題を解決するための手段】
【０００４】
音声イベント又は音声／映像イベントにおけるクライアントを識別する手法が示されている。例えば、メディアサーバは入力レベルに基づいて音声を提供するクライアントを順位付ける。識別子はイベント内で入力を提供するクライアントを識別するためにクライアントと関連付けられる。順位付けしたクライアントは音声コンテンツを担うパケットヘッダに挿入されるリストに含まれる。
【０００５】
この概要は以下に詳細な説明で更に説明される簡単なフォームにおいてコンセプトの選択を導くために与えられる。この概要は請求項の構成の重要な特徴又は主たる特徴を認識することを意図しておらず、又は請求項の構成の範囲を限定するために用いられることを意図していない。
【図面の簡単な説明】
【０００６】
詳細な説明は添付図面を参照して説明されている。図において、参照番号の最も左の数字はその参照番号が最初に現れる図を特定している。詳細な説明及び図において異なる例における同一の参照番号の使用は同類又は同一のアイテムを示している。
【図１】アクティブ発言者識別を可能にする技術を用いた実施例における環境を示している図である。
【図２】貢献ソース（ＣＳＲＣ）フィールドのリストにおいて順位付けした／又は再順位付けしたアクティブクライアントリストを含むリアルタイムプロトコルデータパケットを示す図である。
【図３】アクティブクライアントを識別するための実施例における手法を示すフロー図である。
【図４】リアルタイムプロトコル会議においてアクティブクライアントを識別するための実施例における手法を示すフロー図である。
【発明を実施するための形態】
【０００７】
概説
技術はメディアイベントにおいてアクティブ音声貢献者を識別することについて説明されている。実施例において、貢献する又は参加する音声クライアントのリストがセッションへのクライアント貢献に基づいて形成される。識別子は、どのクライアントがイベントにアクティブに貢献しているかクライアントが識別できるように参加するクライアントと関連付けられる。形成されたリストは会議クライアントに送信するためにデータストリームパケットヘッダに挿入される。実施例において、識別情報はデータ伝送と共に用いられるコントロールパケットに含まれる。本明細書で説明される技術は、最小のネットワークリソースの消費で、かつ同期問題を生ずることなく、発言者情報を提供する。
【０００８】
更なる実施例においては、音声ストリームを切り替える／混合するメディアサーバはデータパケットヘッダに順位付けしたアクティブクライアントのリストを挿入するように構成される。例えば、メディアサーバは現在のアクティブ発言者に基づいて順位付けされているアクティブ発言者のリストを含んでおり、それによりどのクライアントがアクティブに発言しているかについての情報がクライアントに提供される。リストはネットワークについてのメディア伝送費を増大させることなく提供される。
【０００９】
環境例
図１はアクティブ発言者識別を用いて動作可能な実施例における環境１００を示している。例えば、メディアサーバ１０２はメディアイベントにおけるクライアント提供の音声ストリーム間で混合及び切り替える一方、アクティブ音声クライアントを識別する。音声データの処理が説明されるが、メディアサーバ１０２はクライアント装置の会議及び互換性に基づいて映像等の他の種類のメディアデータを扱っても良い。例えば、メディアサーバ１０２は一部のクライアントに対しては音声／映像データを処理し、一方、映像互換性等を欠くクライアントに音声データを送信する。
【００１０】
例えば、メディアサーバプロセッサ１０４は、クライアントのために音声ストリームを混合／切り替える一方、どのクライアント又はどの複数のクライアントが音声コンテンツにアクティブに貢献しているか判別する。メディアサーバプロセッサ１０４は、送信メディアストリームを発生するプロセッサによって用いられる混合／切り替えのアルゴリズム／技術に基づいてどのクライアントが音声データをアクティブに入力しているか判別する。当該判別は、メディアサーバ１０２からの出力メディアストリームに関与するクライアントのリストを順位付けるために用いられる。
【００１１】
クライアント“Ａ”１０６、クライアント“Ｂ”１０８、クライアント“Ｃ”１１０、クライアント“Ｄ”１１２及びクライアント“Ｅ”１１４を含む音声イベントについて、クライアント“Ａ”１０６及びクライアント“Ｅ”１１４が音声入力に貢献しており（クライアント“Ａ”１０６及びクライアント“Ｅ”１１４等が会話を続けている）、非アクティブクライアント“Ｂ”１０８、“Ｃ”１１０、及び“Ｄ”１１２にはメディアサーバ１０２からの“Ａ＋Ｅ”送信ストリーム、すなわち２人の発言者の組み合わせが供給され、一方、クライアント“Ａ”１０６及びクライアント“Ｅ”１１４はメディアサーバ１０２から相手の送信ストリームを各々受信する（例えば、クライアント“Ａ”１０６はクライアントＥの送信ストリームを受信し、クライアント“Ｅ”１１４はクライアントＡの送信ストリームを受信する）。適切なクライアント装置は、限定されないが、ゲートウエイを介してディジタル音声セッションに接続されたＶｏＩＰ(voice over internet protocol)電話、音声互換性を有するコンピューティング装置、ＰＳＴＮ(publicly switched network telephones)電話等を含む。
【００１２】
一部の実施例では、アクティブ発言者にはフィードバック又はエコーを避けるために発言者自身の送信ストリームを含む信号が供給されない（例えば、クライアント“Ａ”１０６にはクライアントＡの音声を含む音声ストリームが送り届かない）。様々な一般的な識別シナリオ、例えば、クライアントＡがクライアントＥと（クライアント“Ａ”１０６と関係した参加者が大声で話し、（クライアント“Ｅ”１１４と関係した）参加者“Ｅ”が比較的普通の声で話しているように）話し合い、現在の発言者がその２人の発言者間で交代する早いやり取りの最中に参加者“Ａ及び“Ｅがあるか、又は、参加者Ａがその会話を支配し、参加者Ｂが比較的少ない入力を提供することが考慮される。後者の状況の例は、第１の発言者の支配的な一人の発言にマイナーな承認（acknowledgements）を加える参加者を含む。
【００１３】
実施例において、メディアサーバ１０２は音声コンテンツが受信されたときクライアントから受信したパケット数、パケットサイズ、エネルギー音声レベル等に基づいて支配的なクライアント(dominant client)（及び発言者）を判別する。よって、２以上のクライアントがコンテンツに同時に貢献している間に、１のアクティブクライアントは上記のファクタに基づいて支配的クライアント（及び発言者）として割り当てられる。例えば、メディアサーバ１０２は異なる複数のクライアントから受信した入力の間で混合及び又は切り替えると共に、アクティブクライアントから受信した音声コンテンツを含む現在のデータパケットに基づいて現在のアクティブクライアント（及び関係した発言者）を判別する。例えば、メディアサーバ１０２は、クライアントＥがデータパケットを現在提供していないならば、現在の“アクティブ”クライアントとしてクライアント“Ａ”１０６を指定する。他の例では、クライアント“Ａ”１０６及びクライアント“Ｅ１１４の両方がアクティブで、クライアント“Ａ”１０６はクライアント“Ｅ”１１４より大なるエネルギーレベルを有する音声コンテンツに貢献しているならば（すなわち、参加者Ａは大きな声で発言し、一方、参加者Ｅは小さな声で発言している）、クライアント“Ａ”１０６は支配的なアクティブ発言者として割り当てられる。クライアントにはクライアント“Ａ”１０６で始まるアクティブクライアントリストが備えられる。この種類の判別は１以上の進行している会議のためにクライアント入力音声ストリームを混合する／切り替えるときに行われる。例えば、メディアサーバ１０２のプロセッサは混合するアルゴリズムを用いるときアクティブクライアント間を区別し、識別モジュール１１６は適用可能なデータパケットに情報を挿入するために用いられる。
【００１４】
図２を参照して、実施例において、リアルタイムトランスポートプロトコル（ＲＴＰ）及び関連したリアルタイムコントロールプロトコル（ＲＴＣＰ）を実装するとき、メディアサーバ１０２はクライアントから送信されたデータ伝送ストリーム及びシグナリングストリームを含むストリーム内のデータを調べることによりアクティブクライアント及びアクティブ発言者を識別する。クライアント“Ａ”１０６の場合には、メディアサーバ１０２は、ＲＴＰパケット内の同期ソース（ＳＳＲＣ）フィールドを調べることにより、又はクライアントＳＳＲＣ（セッション内のクライアントについての識別子）及びＲＴＣＰレポートに含まれる正規名（ＣＮＡＭＥ）から、音声クライアント送信ストリームがクライアント“Ａ”１０６から発せられていることを識別する。他の情報は同様に調べられる。また、ＳＳＲＣはＲＴＰパケットヘッダから得られる。例えば、ＳＳＲＣはＲＴＣＰレポート内のＣＮＡＭＥにマッピングされる。
【００１５】
ＲＴＣＰシグナリングは欠落パケットを識別するため、データ伝送クオリティを保証するため等に用いられ、ＲＴＣＰレポートはＲＴＣＰ帯域外信号から得られる。例えば、ＲＴＣＰレポートはクライアントＣＮＡＭＥにマッピングされたランダム発生のクライアントＳＳＲＣを含む。ＣＮＡＭＥは一般にクライアント装置のために用いられるエイリアスと関連付けされている識別子／記録である。一部の場合には、ＣＮＡＭＥは数字等の文字列である。実施例においては、メディアサーバ１０２はセッション内のＳＳＲＣを割り当てられる。一部の場合には、ＳＳＲＣはセッションに含まれるクライアントについて変更することができる。例えば、クライアントＳＳＲＣは、クライアントが切断する（例えば、長いポーズ、その後の再接続）、クライアントＳＳＲＣが衝突する（１以上のクライアントが共通のＳＳＲＣを発せられる）等ならば、変更する。このように、入力データストリームがそのデータストリームにおいてＳＳＲＣから又はＲＴＣＰシグナリングから識別される。また、メディアサーバ１０２はクライアントの識別に用いるためにＲＴＣＰシグナリングから正規名を得ても良い。
【００１６】
（音声出力を含む）送信ストリームを発生するときに、メディアサーバ１０２はどのクライアントがアクティブクライアントから得られるＳＳＲＣ及びＣＮＡＭＥからセッションに音声入力に貢献しているか識別する。例えば、メディアサーバ１０２はＲＴＣＰパケットに挿入されたＳＳＲＣ、ＣＮＡＭＥを音声コンテンツ送信ストリーム（すなわち、音声データを担うメディアサーバ出力ストリーム）と関連付ける。クライアント“Ａ”１０６、クライアント“Ｂ”１０８、クライアント“Ｃ”１１０、クライアント“Ｄ”１１２及びクライアント“Ｅ”１１４間の前のセッション例に戻ると、混合した信号“Ａ＋Ｅ”の場合においてメディアサーバ１０２はどのクライアントが現在アクティブでそのセッションを支配しているか等に応じてクライアント“Ａ”及び“Ｅ”を順位付ける。その順位付けは音声入力を提供するクライアントに基づいて変更される。この場合において、クライアント“Ａ”が現在入力を提供しているか、又はクライアント“Ａ”が会話を支配しているならば、リストはクライアント“Ａ”１０６の識別子で始め、クライアント“Ｅ”１１４を含む。クライアント“Ａ”１０６とクライアント“Ｅ”１１４との間で音声交換がある状況では、その指令はパケット単位ベースで示されるように現在発言している参加者に基づいて変更される。
【００１７】
図２を参照すると、ＲＴＰ構成において、メディアサーバ識別モジュール１１６は出力ストリームＲＴＰパケットヘッダにＳＳＲＣの順位付けリストを挿入する。例えば、順位付けた識別子は、データストリームにおいて送信されたパケットヘッダ内の貢献ソース（ＣＳＲＣ）フィールドのリストに挿入される。クライアント“Ａ”とクライアント“Ｅ”とが現在のアクティブ役割を交代しているならば、ＳＳＲＣの配列は“クライアント“Ａ”，クライアント“Ｅ”．．．”２０４（ａ）から“クライアント“Ｅ”，クライアント“Ａ”．．．”２０４（ｂ）に変化する。その前の方式において、データストリームを受信するクライアント（セッションの聴取クライアント又は参加者）は、どのクライアントが入力、関係する貢献等を提供しているかについて通知され、追加のシグナリング、関連付けた同期発生及びネットワークオーバヘッドを避ける。例えば、ＣＳＲＣフィールドは各３２ビットの１５識別子まで含むことが可能にされ、仕様に従っている。本明細書で述べる技術に従って動作していないクライアントは、本明細書で述べる利益なしに参加することになる。よって、互換性がないシステム及び技術をなす。
【００１８】
ＳＳＲＣはアクティブクライアントを識別するが、ＳＳＲＣを用いることは問題があり、それは、ＳＳＲＣがランダムに割り当てられること、類似のＳＳＲＣを有する他のクライアントや、セッションを止めた後、そのセッションに再加入してＳＳＲＣを再割り当てされているクライアントとの衝突のため変化すること等である。
【００１９】
メディアサーバ１０２は、クライアントに送信するＲＴＣＰパケットにアクティブクライアントＣＮＡＭＥを挿入する（例えば、それで他の「聴取している」クライアントをアクティブクライアントＣＮＡＭＥ及びＳＳＲＣに気付かせる）。例えば、メディアサーバ識別モジュール１１６はメディアサーバＲＴＣＰパケットにおける「聴取クライアント」に送信されるアクティブクライアント識別子を「展開する」。例えば、様々なアクティブクライアントが会議に貢献しているならば、メディアサーバは、メディアサーバデータストリームと共に送信されるＲＴＣＰパケット内に、獲得したクライアント識別子を指定の間隔で挿入する。更に、ＲＴＣＰパケットは各パケット内にＣＮＡＭＥを含んでいる。ＣＮＡＭＥは聴取クライアントに送信されるＲＴＣＰパケット内に組み入れられ伝送オーバヘッドを最小化する。アクティブクライアント識別子を含むメディアサーバＲＴＣＰデータを受信するクライアントは、音声コンテンツが受信されるときＣＮＡＭＥがデータパケットと関連付けられるようにローカルメモリ内にデータを格納する。例えば、ＣＮＡＭＥ、マッピングされたＳＳＲＣ及び他の関係した情報がルックアップテーブル等に格納される。例えば、データストリームに含まれる音声コンテンツは普通の連続的方式で送信されるが、ＲＴＣＰ信号伝送は特定の間隔（例えば、５又は１０秒間隔）のように断続的にのみ生じる。よって、データパケットを受信するクライアントはＣＳＲＣ内のＳＳＲＣを前に受信したＣＮＡＭＥと関連付ける。実施例においては、ＧＲＵＵ(Globally Routable User Agent URI：グロバリルータブルユーザエージェントＵＲＩ)が特定のクライアントを識別するために用いられる。
【００２０】
実施例において、アクティブクライアントには、そのクライアントが会議でアクティブな１人であることが通知される。例えば、（アクティブクライアントと関係した）参加者は彼／彼女が他の参加者と「話し合って」いないことを知りたい。クライアント“Ａ”１０６、クライアント“Ｂ”１０８、クライアント“Ｃ”１１０、クライアント“Ｄ”１１２及びクライアント“Ｅ”１１４間の前のセッション例に戻ると、例えば、クライアント“Ａ”１０６がアクティブでクライアント“Ｂ”１０８，“Ｃ”１１０，“Ｄ”１１２及び“Ｅ”１１４がアクティブでないならば、これはクライアント“Ａ”に送信されるＲＴＣＰ信号を介して識別される。よって、メディアサーバ１０２は、クライアント“Ａ”送信ストリームを通過させることによりクライアント“Ｂ”，“Ｃ”，“Ｄ”及び“Ｅ”のために送信メディアストリームを発生し、一方、クライアント“Ａ”１０６はＣＳＲＣ／ＲＴＣＰパケットに基づいて「聴取する」クライアント又はセッションのメンバとして他のクライアントがアクティブでないことを識別する。
【００２１】
更なる実施例においては、人が理解可能な情報はＳＳＲＣ／ＣＮＡＭＥと関連付けられる。例えば、ユーザは、参加者が発言しているときに発言中の参加者の映像が関連のモニタに表示されることを望む。実施例においては、人が理解可能なクライアント情報がクライアント間で交換される。例えば、そのデータは通常、イベント又はセッションの開始時に交換される。
【００２２】
インターネット（ワールドワイドウェブ）がクライアント及び他のコンポーネントを接続するために用いられ、他のネットワーク及び様々なリンクも同様に適切である。例えば、メディアサーバ１０２をクライアントに接続するネットワークはワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、無線ネットワーク、公衆電話ネットワーク、イントラネット等を含む。そのネットワークは複数のサブネットワークを含んで構成される。
【００２３】
次の説明は、上記したシステム及び装置を用いて実施される技術を示している。その手法の各々の態様はハードウエア、ファームウエア、すなわちソフトウエア、又はそれらの組み合わせで実施される。その手法は、１以上の装置によって実行される動作を特定する１組のブロックとして示され、各ブロックによる動作を行うために示された順番に必ずしも限定されない。
【００２４】
手法例
次の説明は、上記したシステム及び装置を用いて実施される技術を示している。その手法の各々の態様はハードウエア、ファームウエア、すなわちソフトウエア、又はそれらの組み合わせで実施される。その手法は、１以上の装置によって実行される動作を特定する１組のブロックとして示され、各ブロックによる動作を行うために示された順番に必ずしも限定されない。また、各種の他の例が予想される。
【００２５】
図３はメディアセッションにおけるアクティブ音声入力クライアントを識別するための手法例を示している。例えば、その技術は、一部のクライアントが映像互換性等を有していない電話会議又はメディア会議において用いられる。
【００２６】
実施例において、メディアサーバは、各アクティブクライアントによって提供される入力に対する音声入力クライアントを判別する（３０２）。例えば、判別は音声クライアント入力を混合する及び／又は切り替えることの一部として行われる。よって、クライアント“Ａ”は異なるクライアントが音声入力を提供するまで最高のアクティブクライアントとして割り当てられる。他の例では、クライアント“Ａ”及びクライアント“Ｅ”が貢献しており、クライアント“Ａ”の音声がより高いエネルギーレベルを有しているならば、クライアント“Ａ”が選択される。クライアントと関係した参加者がそのクライアントが音声入力を支配しているように大きな声で話しているか又はより連続的な方法で話しているならば、クライアント音声はより高いエネルギーレベルを有する。
【００２７】
音声入力クライアントが現在、アクティブであり、会話を支配している等であるならば、その音声入力クライアントは「トップ」クライアントとして識別される。本技術に応じて機能しているＲＴＰ／ＲＴＣＰシステムにおいては、メディアサーバはクライアント入力ストリーム及び関連したＲＴＣＰパケット（例えば、クライアントから送信されたＲＴＣＰパケット）を受信し、そのＲＴＣＰパケットは音声コンテンツを含むストリームを発生する特定のクライアントのためにＣＮＡＭＥにマッピングされたＳＳＲＣを含む（３０４）。例えば、メディアサーバはクライアントについてＳＳＲＣ及びＣＮＡＭＥを得る。ＣＮＡＭＥはＳＳＲＣと共にクライアントを識別する。メディアサーバは、どのクライアントが音声入力を現在提供し、会話を支配しているか等に応じて入力クライアントＳＳＲＣを順位付けする（３０６）。例えば、メディアサーバは、現在のアクティブ「発言者」、例えば、入力を提供するアクティブクライアントからの順番とするようにアクティブクライアントＳＳＲＣ識別子を順位付けする。例において、ＲＴＰは、ＣＲＳＣに含まれるアクティブクライアント当たり３２ビットの識別子を用いて１５のアクティブ発言者の識別を可能にする。
【００２８】
メディアサーバは識別子を音声入力クライアントと関連付ける。例えば、メディアサーバは音声入力クライアントのＲＴＣＰパケットからＳＳＲＣ及びＣＮＡＭＥを得る。ＳＳＲＣは、メディアサーバの出力ストリームに含まれるＣＲＳＣフィールド内の音声入力クライアントを識別するために用いられる。
【００２９】
クライアントは他のデータを受信してそれを音声入力クライアントと関連付ける。例えば、受信するクライアント（聴取するクライアント又はメディアイベントにおけるクライアント）は、ＣＮＡＭＥと関連付けられた、人が理解可能な情報を有する。例えば、クライアントは、（ＣＮＡＭＥ／ＳＳＲＣと関連付けられた）参加者の写真、参加者の名前等を有する。
【００３０】
順位付けられた音声入力クライアントの識別子はパケットヘッダ内のリストに挿入される（３０８）。例えば、クライアント“Ａ”及び“Ｅ”が音声入力を提供しているならば（クライアント“Ａ”が現在のアクティブクライアントである状態で）、ＲＴＰヘッダのＣＳＲＣフィールドはリストの始まりをクライアント“Ａ”についてのＳＳＲＣとした複数のＳＳＲＣを含む。このように、聴取するクライアント（他のアクティブクライアントからの音声入力を受信する音声入力クライアントを含む）にはコンテンツストリーム内の発言者の同一性が伝えられる。他の例においては、リストの音声入力クライアントの順位は、どの音声入力クライアントがメディアセッションを支配しているかについての少なくとも一部に基づいている。支配についての考慮には、音声入力のエネルギーレベル、その入力の期間、無言の期間、パケットサイズ等が含まれる。例えば、クライアント“Ａ”が現在アクティブで、クライアント“Ａ”の送信ストリームが１以上の他の音声入力クライアントと比較して高エネルギーレベルを示すので、リストはクライアント“Ａ”で始まる。
【００３１】
メディアサーバは、メディアサーバの送信ストリーム（コンテンツ伝送と共に送信されるＲＴＣＰパケット等）内のＳＳＲＣ及びＣＮＡＭＥを聴取するクライアント（セッションクライアント）に送信する（３１０）。音声入力クライアントについてのＳＳＲＣは、ＲＴＰパケット内のデータストリームパケットヘッダにＣＳＲＣフィールドを配置させても良い。例えば、５つのクライアントメディアイベントにおいて３人の参加者が発言しているならば、音声入力クライアントと関連付けられたクライアントＳＳＲＣ及びＣＮＡＭＥは、音声コンテンツを伝送するＲＴＰパケットと関連付けられたメディアサーバの（聴取するクライアントに送信される）ＲＴＣＰパケットに含まれる。このように、メディアサーバはアクティブ音声クライアントを識別するＳＳＲＣ及びＣＮＡＭＥをクライアントに送信する。よって、聴取するクライアントはＲＴＰパケット内のＳＳＲＣ及びＣＮＡＭＥを参照して音声コンテンツの発生ソースを識別する。クライアントＳＳＲＣが他のクライアントに発せられたＳＳＲＣと衝突するならば、又はクライアントが他の理由でソース伝送アドレスを変更したならば、クライアントＳＳＲＣは更新される。聴取するクライアントがメディアイベントの間に情報をアクセスできるようにＳＳＲＣ及びＣＮＡＭＥはローカルメモリに格納される（３１２）。
【００３２】
図４はメディア会議においてアクティブクライアントを識別する技術例を示している。例えば、本技術は一部のクライアントが映像を欠いているか又は音声会議コールにおいて使用されているメディア会議の間に用いられる。
【００３３】
本実施例においては、メディアサーバは、アクティブクライアントからの識別子と共にアクティブクライアント入力（音声コンテンツ）を受信する（４０２）。例えば、音声会議に貢献するクライアントは、クライアントを識別するＳＳＲＣ及びＣＮＡＭＥを送信する。例えば、ＳＳＲＣはＲＴＰパケットヘッダ内、またＣＮＡＭＥと共にＲＴＣＰパケット内のデータストリームに含まれる。
【００３４】
会議内の１以上のアクティブクライアントの順位付けのリストが発生される（４０４）。例えば、メディアサーバの混合する／切り替える音声入力ストリームはアクティブクライアント（ＲＴＰ／ＲＴＣＰ内のＳＳＲＣ識別子）、すなわち会議又はセッションに入力を提供するクライアントのリストを配置している。例えば、メディアサーバは、データ部分及び関連した信号部分を順に含むアクティブクライアント送信ストリームからＳＳＲＣ識別を得る音声／映像混合サーバ（ＡＶＭＣＵ）である。ＡＶＭＣＵはセッション内のクライアントについてのアクティブクライアントＳＳＲＣ又は他の識別子の相対的な配列を決定する。ＳＳＲＣはクライアントＣＮＡＭＥにマッピングするＲＴＣＰレポートから識別される。例えば、ランキングはクライアントが現在アクティブであることに基づいてされる。他の実施例では、エネルギーレベル、供給されたデータパケットの数、無言の期間、パケットサイズ等のファクタは考慮に入れられる。例えば、順位付けされたリストは供給されたパケットの数のためにセッションを支配するアクティブクライアントで始まるが、次に同時にアクティブなクライアントにはより低い相対的位置が割り当てられる。
【００３５】
順位付けされたリストは、メディアサーバ送信データストリームの流れ内のパケットヘッダに含まれるＣＳＲＣリストフィールドに挿入される（４０６）。例えば、メディアサーバ出力はアクティブクライアントによって提供される音声、アクティブクライアントについてのＳＳＲＣ識別子の順位付けされたリストを有するＣＳＲＣフィールドを含む。その結果として、聴取するクライアント、すなわち音声コンテンツストリームを受信するクライアントはどのクライアントがアクティブであるか、及び複数のアクティブクライアントの相対的関係について伝えられる。加えて、ＳＳＲＣ及びＣＮＡＭＥはメディアサーバ送信ＲＴＣＰパケットに含まれる。
【００３６】
ＳＳＲＣはアクティブ音声クライアントのＣＮＡＭＥと関連付けられる（４０８）。例えば、メディアサーバは、ＲＴＰパケットヘッダ内のＣＲＳＣフィールドに含まれるＳＳＲＣに関係したクライアントＣＮＡＭＥを含むＲＴＣＰパケットを送信する。
【００３７】
人が理解可能な情報は、同様に、ＣＮＡＭＥ及び／又は音声入力クライアントＳＳＲＣと関連付けられる。例えば、写真又は名前は、関連付けられたクライアントが音声コンテンツを提供しているときに参加者の写真又は名前が現れるようにクライアントＣＮＡＭＥと関連付けられる。この情報は会議内で伝達されるか、又はクライアントがこの人が理解可能な情報を入力する。
【００３８】
更なる実施例ではＧＲＵＵがアクティブクライアントについてのＳＳＲＣと関連付けられる。１クライアントがアクティブであり、他のクライアントがアクティブでないある状況において、メディアサーバは、アクティブクライアント送信ストリームはそのアクティブクライアントには戻らないが、そのアクティブクライアントに他のクライアントがアクティブでないことを気付かせるようにそのアクティブクライアントに対する表示を提供する（４１０）。このように、アクティブクライアントは、参加者が他の参加者と「話し合って」いないことを気付かされる。
【００３９】
ＲＴＰ及びＲＴＣＰが説明されているが、本開示の技術及び実施例は他のプロトコルデータ伝送メカニズムに適用することができる。
【００４０】
結論
本発明は構成上の特徴及び／又は方法論的な動作に特有の言語で説明されているが、添付の特許請求の範囲に定義された本発明が説明された特有の特徴及び動作に必ずしも限定されないことは理解されるべきである。むしろ、特有の特徴及び動作は請求項の本発明を実施する形態例として開示されている。
【図１】
0005579598.tif 000002
【図２】
0005579598.tif 000003
【図３】
0005579598.tif 000004
【図４】
0005579598.tif 000005