JP6940587B2

JP6940587B2 - マルチメディア通信におけるコンパクト並列コーデックの使用のための方法および装置

Info

Publication number: JP6940587B2
Application number: JP2019501503A
Authority: JP
Inventors: ニコライ・コンラッド・レウン; イェクイ・ワン; ラマチャンドラン・スブラマニアン
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2016-07-21
Filing date: 2017-07-19
Publication date: 2021-09-29
Anticipated expiration: 2037-07-19
Also published as: WO2018017736A1; US20220030039A1; TWI829058B; KR20230133936A; AU2017298381B2; KR20190031239A; US20180027027A1; EP3488605B1; TW202218416A; TWI753928B; CN109479113A; AU2017298381A1; EP3488605C0; BR112019000850A2; EP3488605A1; US11171999B2; AU2022209216A1; TW201808001A; KR102577373B1; EP4380147A1

Description

本開示は、コーデック交渉の分野に関し、詳細には、非集中型マルチメディア会議(Decentralized Multimedia Conference)および通信におけるコンパクト並列コーデック交渉(Compact Concurrent Codec Negotiation)に関する。

デジタルビデオおよびオーディオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込むことができる。デジタルビデオおよびオーディオデバイスは、ムービングピクチャエキスパートグループ2(MPEG-2)、MPEG-4、国際電気通信連合-通信部門(ITU-T) H.263、ITU-T H.264/MPEG-4, Part 10、アドバンストビデオコーディング(AVC)、高効率ビデオコーディング(HEVC)規格、およびそのような規格の拡張によって定義される規格に記載されるような、ビデオおよびオーディオ圧縮技法を実装する。ビデオデバイスおよびオーディオデバイスは、そのようなビデオおよびオーディオコーディング技法を実装することによって、デジタルビデオおよびオーディオ情報をより効率的に送信し、受信し、符号化し、復号し、かつ/または記憶することができる。

スケーラブルHEVC(SHVC)およびマルチビューHEVC(MV-HEVC)のようなビデオおよびオーディオコーディング規格は、デコーダ能力を定義するためのレベル定義を提供する。以下では、既存のレベル定義および本発明が行われた時点でのSHVCの他の状況に基づいて、問題および解決法が説明されるが、この解決法はMV-HEVCに、および他のマルチレイヤコーデックにも適用される。

Bross他、「High Efficiency Video Coding (HEVC) Text Specification Draft 10」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のビデオコーディング共同研究部会(JCT-VC)、第12回会合、ジュネーブ、スイス、2013年1月14日〜2013年1月23日

添付の特許請求の範囲内のシステム、方法、およびデバイスの様々な実装形態は、各々がいくつかの態様を有し、それらのうちの単一の態様が単独で、本明細書で説明する望ましい属性を担うものではない。本明細書においては、添付の特許請求の範囲を限定することなしに、いくつかの顕著な特徴について説明する。

本明細書で説明する主題の1つまたは複数の実装形態の詳細は、添付の図面および下記の説明内に記載される。他の特徴、態様および利点は、説明、図面および特許請求の範囲から明らかになるであろう。以下の図の相対寸法は、縮尺どおりに描かれていない場合があることに留意されたい。

一態様では、複数のパーティの間で通信するための方法が開示される。この方法は、第1のデバイスにおいて、第2のデバイスへの送信用の第1のメッセージを生成するステップを含む。方法は、第1のデバイスにおいて、会議を確立するための第2のメッセージを受信するステップをさらに含む。第2のメッセージは、第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストを含む。第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストは、第1の列挙されるコーデックの1つまたは複数の並列インスタンス用に使用可能な1つまたは複数のリソースが、第2の列挙されるコーデックの1つまたは複数の並列インスタンス用に代わりに使われ得るかどうかの指示を含む。

本開示の別の態様は、複数のコーデックを利用するマルチパーティ、マルチストリーム会議を開始するための装置である。装置は、プロセッサおよび受信機を備える。プロセッサは、第1のデバイスへの送信用の第1のメッセージを生成するように構成される。受信機は、会議を確立するための第2のメッセージを第1のデバイスから受信するように構成される。第2のメッセージは、第1のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストを含む。第1のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストは、第1の列挙されるコーデックの1つまたは複数の並列インスタンス用に使用可能な1つまたは複数のリソースが、第2の列挙されるコーデックの1つまたは複数の並列インスタンス用に代わりに使われ得るかどうかの指示を含む。

本開示の別の態様は、複数のコーデックを利用するマルチパーティ、マルチストリーム会議を開始するための装置である。装置は、第1のデバイスへの送信用の第1のメッセージを生成するための手段と、会議を確立するための第2のメッセージを第1のデバイスから受信するための手段とを備える。第2のメッセージは、第1のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストを含む。第1のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストは、第1の列挙されるコーデックの1つまたは複数の並列インスタンス用に使用可能な1つまたは複数のリソースが、第2の列挙されるコーデックの1つまたは複数の並列インスタンス用に代わりに使われ得るかどうかの指示を含む。

本開示の追加態様は、実行されると、プロセッサに方法を実行させる命令を備える非一時的コンピュータ可読媒体である。この方法は、第1のデバイスにおいて、第2のデバイスへの送信用の第1のメッセージを生成するステップを含む。方法は、第1のデバイスにおいて、会議を確立するための第2のメッセージを受信するステップをさらに含み、第2のメッセージは、第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストを含み、第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストは、第1の列挙されるコーデックの1つまたは複数の並列インスタンス用に使用可能な1つまたは複数のリソースが、第2の列挙されるコーデックの1つまたは複数の並列インスタンス用に代わりに使われ得るかどうかの指示を含む。

複数の参加者のための会議アーキテクチャの例を示す図である。複数の参加者のための非集中型会議アーキテクチャの例を示す図である。複数の参加者のための非集中型会議アーキテクチャの別の例を示す図である。端末が混合器として機能する、複数の参加者のためのハイブリッド会議アーキテクチャの例を示す図である。端末が混合器および参加者として機能する、複数の参加者のためのハイブリッド会議アーキテクチャの例を示す図である。会議におけるコーデック交渉のための別の例示的な方法のフローチャートである。会議セッションを開始するためにコンパクト並列コーデックを使うための例示的な方法のフローチャートである。会議セッションを開始するためにコンパクト並列コーデックを使うための例示的な方法の別のフローチャートである。

添付の図面に関連して以下に記載する詳細な説明は、本発明の特定の実装形態の説明として意図されており、本発明を実践することができる実装形態のみを示すことは意図されていない。本説明全体を通して使用されている「例示的」という用語は、「例、事例、または例証としての役割を果たす」ことを意味しており、必ずしも他の例示的な実装形態に優る好ましい、または有利なものとして解釈してはならない。詳細な説明は、開示される実施態様の完全な理解を提供するための具体的な詳細を含む。いくつかの事例では、いくつかのデバイスはブロック図の形態で示される。

ビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、およびそれのスケーラブルビデオコーディング(SVC)拡張とマルチビュービデオコーディング(MVC)拡張とを含むITU-T H.264(ISO/IEC MPEG-4 AVCとも呼ばれる)を含む。

加えて、ビデオコーディング規格、すなわち、高効率ビデオコーディング(HEVC)が、ITU-Tビデオコーディングエキスパートグループ(VCEG)およびISO/IEC MPEGのビデオコーディング共同研究部会(JCT-VC)によって開発されている。HEVCドラフト10の完全な引用は、文書JCTVC-L1003、Bross他、「High Efficiency Video Coding (HEVC) Text Specification Draft 10」、ITU-T SG16 WP3およびISO/IEC JTC1/SC29/WG11のビデオコーディング共同研究部会(JCT-VC)、第12回会合、ジュネーブ、スイス、2013年1月14日〜2013年1月23日である。HEVCのマルチビュー拡張すなわちMV-HEVC、およびSHVCという名称であるHEVCのスケーラブル拡張も、それぞれ、JCT-3V(ITU-T/ISO/IEC 3Dビデオコーディング拡張開発共同研究部会)およびJCT-VCによって開発されている。MV-HEVCの最近のワーキングドラフト(WD)は、以後MV-HEVC WD7と呼ばれる。SHVCの最近のWDは、以後SHVC WD5と呼ばれる。

既存のレベル定義の手法は、マルチレイヤビットストリームの効率的な復号のためのデコーダ能力を定義するのに十分な情報を提供しない場合がある。たとえば、各々720pの解像度の5つ以上の信号対雑音比(SNR)スケーラブルレイヤ(等価な解像度を有するレイヤ)を復号するために、レベル5以上のデコーダが必要とされる。その結果、ルミナンスコーディングツリーブロック(CTB)サイズは、32×32または64×64に等しい(すなわち、16×16のようなより小さなコーディングサイズは使用され得ない)。しかしながら、720p以下の解像度を有するレイヤのような一部のレイヤに対しては、この制約は最適ではないコーディング効率をもたらし得る。

いくつかの例では、デコーダは、複数の既存のシングルレイヤデコーダを再使用することによって製造され得る。ある例では、4つのシングルレイヤHEVCレベル3.1デコーダからなるSHVCデコーダは、既存のレベル定義によれば、720pの4つのSNRレイヤを復号するためにレベル4以上に適合しなければならない。この定義により、デコーダは任意のレベル4ビットストリームを復号することが可能でなければならない。しかしながら、デコーダハードウェアへの変更がなければ、そのようなデコーダは、1080pの解像度の2つのSNRレイヤを伴うSHVCレベル4ビットストリームを復号することが可能ではないであろう。

既存のHEVCレベル定義の別の問題は、1080pのシングルレイヤHEVCビットストリームと720pの2レイヤSHVCビットストリームの両方を復号することが可能であるような方法で実装されるデコーダが、レベル3.1として分類されるということである。しかしながら、レベル3.1という分類は、1080pのシングルレイヤビットストリームを復号する能力を表さない。

別の例では、既存のレベル定義によれば、720pの4つのSNRレイヤを復号することが可能であるように4つのシングルレイヤHEVC 3.1デコーダを使用して実装されるデコーダについて、そのデコーダはレベル4以上に適合しなければならない。したがって、デコーダは、4つ以上のタイル行と4つ以上のタイル列とを有するビットストリームを復号することが可能であることを要求され、各タイルは256個のルーマサンプルの幅と144個のルーマサンプルの高さとを有する。しかしながら、デコーダのレベル3.1の制限により、一部のそのようなビットストリームを復号することが可能ではない。

SHVCの既存の設計のもとでは、HEVCテキストのA.4.1項のすべての項目が、各レイヤに適用されるように指定される。しかしながら、一部の項目は各レイヤに直接適用可能ではない。たとえば、復号ピクチャバッファ(DPB)のサイズに対する項目dについて、シーケンスパラメータセット(SPS)シンタックス要素はエンハンスメントレイヤに対して適用可能ではない。また、SHVC WD5におけるDPBは、共有サブDPB設計であるので、項目dは各レイヤに直接適用され得ない。別の例として、コーディングされたピクチャバッファ(CPB)のサイズに対する項目hおよびiに対して、ビットストリーム固有のCPB動作のために、パラメータは各レイヤに適用され得ない。

CPBのサイズに対するビットストリーム固有の制約(HEVCテキストの下位条項A.4.1における項目hおよびiによる)が必要とされる。しかしながら、HEVCテキストの下位条項A.4.1における項目hおよびiはビットストリームレベルに対して直接適用されることが可能ではなく、それは、直接適用されると、シングルレイヤビットストリームに対する同じCPBサイズの制限がマルチレイヤビットストリームに対する制限ともなるからである。これはレイヤの数に対してスケーラブルではなく、多数のレイヤがあるときに低いピクチャ品質しか可能にしない。

HEVCテキストの下位条項A.4.2における項目b、c、d、g、h、i、およびjによる制約は、レイヤだけに固有であるように指定される。しかしながら、これらの項目によるビットストリーム固有の制約が、それらの項目によるレイヤ固有の対応が指定されるかどうかにかかわらず、指定されるべきである。

ある実施形態が、本明細書でHEVC規格および/またはH.264規格の文脈で説明されるが、当業者は、本明細書で開示されるシステムおよび方法が、任意の適切なビデオコーディング規格または標準的ではないビデオコーデック設計に適用可能であり得ることを了解し得る。たとえば、本明細書で開示する実施形態は、スケーラブルおよびマルチビュー拡張を含む、国際電気通信連合(ITU)電気通信規格化部門(ITU-T)H.261、国際標準化機構/国際電気標準会議(ISO/IEC)MPEG 1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG 4 Visual、およびITU-T H.264(ISO/IEC MPEG-4 AVCとしても知られる)という規格のうちの1つまたは複数に適用可能であり得る。

HEVCは全般に、多くの点で、前のビデオコーディング規格のフレームワークに従う。HEVCにおける予測のユニットは、いくつかの前のビデオコーディング規格における予測のユニット(たとえば、マクロブロック)とは異なる。実際、いくつかの前のビデオコーディング規格において理解されているようなマクロブロックの概念は、HEVCに存在しない。マクロブロックは、4分木方式に基づく階層構造と置き換えられ、このことは、あり得る利点の中でもとりわけ、高い柔軟性を実現し得る。たとえば、HEVC方式では、コーディングユニット(CU)、予測ユニット(PU)、および変換ユニット(TU)という3つのタイプのブロックが定義される。CUは、領域分割の基本単位を指し得る。CUはマクロブロックの概念に類似すると見なされることがあるが、HEVCは、CUの最大サイズを制限せず、コンテンツ適応性を改善するために4つの等しいサイズのCUへの再帰的分割を許容し得る。PUはインター/イントラ予測の基本単位と見なされることがあり、単一のPUは、不規則な画像パターンを効果的にコーディングするために、複数の任意の形状区分を含むことがある。TUは、変換の基本単位と見なされることがある。TUは、PUとは無関係に定義され得るが、TUのサイズは、TUが属するCUのサイズに制限され得る。3つの異なる概念へのブロック構造のこの分離により、各ユニットをユニットのそれぞれの役割に従って最適化することが可能になり、このことはコーディング効率の改善をもたらし得る。

単に説明の目的で、本明細書で開示されるいくつかの実施形態は、ビデオおよび/またはオーディオデータの2つのレイヤ(たとえば、ベースレイヤなどの下位レイヤおよびエンハンスメントレイヤなどの上位レイヤ)のみを含む例とともに説明される。ビデオデータの「レイヤ」は、一般に、ビュー、フレームレート、解像度などの、少なくとも1つの共通の特性またはパラメータを有するピクチャのシーケンスを指し得る。たとえば、レイヤは、マルチビュービデオデータの特定のビュー(たとえば、視点)と関連付けられたビデオデータを含み得る。別の例として、レイヤは、スケーラブルビデオデータの特定のレイヤと関連付けられたビデオデータを含み得る。したがって、本開示は、ビデオデータのレイヤおよびビューに交換可能に言及することがある。すなわち、ビデオデータのビューはビデオデータのレイヤと呼ばれることがあり、ビデオデータのレイヤはビデオデータのビューと呼ばれることがある。加えて、マルチレイヤコーデック(マルチレイヤビデオコーダまたはマルチレイヤエンコーダデコーダとも呼ばれる)は、マルチビューコーデックまたはスケーラブルコーデック(たとえば、MV-HEVC、3D-HEVC、SHVC、または別のマルチレイヤコーディング技法を使用してビデオデータを符号化および/または復号するように構成されるコーデック)を一緒に指すことがある。ビデオ符号化およびビデオ復号は、一般に、両方ともビデオコーディングと呼ばれることがある。そのような例は、複数のベースレイヤおよび/またはエンハンスメントレイヤを含む構成に適用可能であり得ることを理解されたい。加えて、説明を簡単にするために、以下の開示は、いくつかの実施形態に関して「フレーム」または「ブロック」という用語を含む。しかしながら、これらの用語は限定的なものではない。たとえば、下で説明される技法は、ブロック(たとえば、CU、PU、TU、マクロブロックなど)、スライス、フレームなどの、任意の適切なビデオユニットとともに使用され得る。

ビデオコーディング規格
ビデオ画像、TV画像、静止画像、またはビデオレコーダもしくはコンピュータによって生成された画像のようなデジタル画像は、水平な線および垂直な線に並べられたピクセルまたはサンプルからなり得る。単一の画像中のピクセルの数は、一般に数万個である。各ピクセルは、一般に、ルミナンス情報とクロミナンス情報とを含む。圧縮がなければ、画像エンコーダから画像デコーダに搬送されるべき著しい量の情報により、リアルタイムの画像送信は不可能になるであろう。送信されるべき情報の量を減らすために、JPEG、MPEG、およびH.263規格のような、いくつかの異なる圧縮方法が開発された。ビデオコーディング規格は、本明細書で前に列挙された規格を含む。

マルチストリームマルチパーティ会議開催
いくつかの実施形態では、マルチストリームマルチパーティ会議(Multi-stream Multiparty Conference)において、マルチストリームビデオ、少なくとも2つのビデオコンテンツ(たとえば、1つのメインおよび1つのプレゼンテーション)、マルチストリームオーディオ、少なくとも2つのオーディオコンテンツ、ならびに他の追加能力をサポートすることが望ましい場合がある。いくつかの態様において、集中型プロセッサまたはブリッジが、これらの機能をサポートするように作用し得る。集中型プロセッサまたはブリッジは、マルチストリームビデオ/オーディオデータを受信し、ビデオ/オーディオデータを混合し、混合データストリームを参加者の各々に送ることができる。

図1は、複数の参加者のための例示的な会議アーキテクチャ100の図である。会議アーキテクチャ100は、端末110A〜Dおよび集中型プロセッサ125を含む。いくつかの態様において、集中型プロセッサ125は、サーバまたはカンファレンスブリッジプロバイダを備え得る。集中型プロセッサ125は、端末110A〜Dの各々からデータストリームを受信し、復号し、混合し、混合データストリームを端末110A〜Dに送信することができる。いくつかの態様において、集中型プロセッサ125は、マルチキャスト送信を使って混合データストリームを送信し得る。いくつかの実施形態では、データストリームは、1つまたは複数のオーディオ、ビデオ、および/またはメディアストリームを含み得る。いくつかの態様において、端末110A〜Dは各々、プロセッサ、受信機、送信機、トランシーバ、アンテナ、メモリ、データベース、およびユーザインターフェースのうちの1つまたは複数を備え得る。

いくつかの実施形態では、集中型プロセッサ125なしでマルチストリームマルチパーティ会議を確立することが望ましい場合がある。たとえば、集中型プロセッサ125は、コストおよび/または複雑性を追加し得る別個のインフラストラクチャおよびサービスを要求し得る。いくつかの実施形態では、複雑性は、マルチストリーム会議の1つまたは複数のメディアストリームの複雑性に少なくとも部分的に基づき得る。さらに、参加者は、マルチストリームマルチパーティ会議に先立って、集中型プロセッサ125を確立し、または集中型プロセッサ125に登録するよう要求され得る。したがって、参加者が、自分の端末(たとえば、コンピュータ、タブレット、スマートフォン、他のユーザ機器など)上で、集中型プロセッサ125を使わずにマルチストリームマルチパーティ会議(たとえば、非集中型会議)を確立することが望ましい場合がある。

図2は、複数の参加者のための非集中型会議アーキテクチャ200の例の図である。図2に示すように、非集中型会議アーキテクチャ200は、端末110A、110B、および110Cを含み得る。端末110A、110B、および110Cは、互いとデータストリームを交換することができ、受信および/または送付したデータストリームを復号、符号化、および/または混合することができる。たとえば、図2に示すように、参加者110Aは、端末110Bおよび110Cからデータストリームを受信し、端末110Bおよび110Cにデータストリームを送信する。データストリームは、メディアストリーム、オーディオストリーム、ビデオストリーム、またはそのようなストリームの組合せを含み得る。これらの複数のデータストリームは、別々に、および並列に復号され、次いで、各端末において、好ましくはある程度知覚的に空間分離して混合されてよく、その後、混合データストリームがビューアまたはリスナーに対してレンダリングされる。端末110A、110B、および110Cの各々は、並列に操作することができるデコーダ/エンコーダインスタンスの数に対して計算限度を有し得る。いくつかの態様において、端末内混合を用いてマルチストリームマルチパーティ会議をセットアップするとき(たとえば、非集中型会議)、会議開始者によって、これらの限度を考慮に入れることが望ましい場合がある。

図2に関して上述したように、端末110A、110B、および110Cの各々は、他の会議参加者から受信された複数のデータストリームを並列に復号するよう要求され得る。各端末110は、各端末が並列に操作することができるデコーダインスタンスの数への計算限度を有し得る。これは、端末を用いて会議に出られる参加者の数を制限し、または端末が、いくつかのデータストリームを復号するのを優先し、それ以外は無視することができることを要求する。たとえば、端末が、受信したどのデータストリームも無視しない場合、参加者の数は、デコーダの最大数プラス1以下でなければならない(N<=MaxDec+1)。ここで、Nは、会議開始者を含む、会議への参加者の数であり、MaxDecは、端末によって並列に稼働され得るデコーダの最大数である。いくつかの実施形態では、端末110Aは、端末110Bおよび110Cと接続することによって会議を開始することができ、次いで、端末110Bおよび110Cは、会議を完成させるために互いと接続すればよい。

図2を参照すると、端末110Aが会議開始者である場合、端末110Aは、上記算出を使って、どれだけ多くの発呼者/端末を会議に勧誘するか(すなわち、N-1)を判断することができる。さらに、他の端末(たとえば、端末110Bおよび110C)の各々が、受信したデータストリームを優先せず、無視する場合、各端末が、N-1個のデータストリームを復号することができる場合もある。したがって、開始者端末110Aが、N<=Min[各端末のMaxDec]+1という限定を検討することが望ましい場合がある。したがって、開始者端末110Aは、会議における各参加端末によって並列に稼働され得るデコーダの最大数を考慮し、参加者の数が、デコーダの最も小さい最大数プラス1を超えないことを保証することができる。

同様に、端末内混合を用いる会議は、端末が、他の参加端末に送られる複数のデータストリームを並列に符号化することを要求し得る。これは、開始者がデータタイプ用の複数のタイプのコーデックをオファーし、他の参加者が異なるコーデックを使うことを選択したときに起こり得る。いくつかの態様において、データタイプは、オーディオタイプ、ビデオタイプ、または他のメディアタイプを含み得る。

図1および図2に記載する集中型または非集中型会議アーキテクチャのいずれかにおいて、会議に参加している1つまたは複数の端末にセッション記述プロトコル(SDP)オファーメッセージを通信するのに先立って、集中型プロセッサまたは開始者端末(アーキテクチャのタイプに依存する)は、プレSDP交渉フェーズにより、どのような情報をSDPオファーメッセージ中に含めるかを決定することができる。この交渉フェーズ中、集中型プロセッサまたは開始者端末は、適用可能会議アーキテクチャを形成する他の端末のコーディングおよび復号能力をリクエストしてよい。他の端末のコーディングおよび復号能力についてのリクエストは、個別交渉メッセージ中で通信され得る。交渉メッセージは、送付側端末またはプロセッサの情報能力ならびに会議の一部として通信されることになる1つまたは複数のメディアストリームに関する情報を含むように構成され得る。

いくつかの実施形態では、交渉メッセージは、並列コーデック能力交換(CCCex: Concurrent Codec Capabilities Exchange)として機能し得る。いくつかの実施形態では、オファーメッセージおよび返答メッセージは、本明細書に記載するように、CCCex用に機能する場合もある。交渉メッセージは、したがって、送信デバイスのコーディングおよび復号能力に関する属性ならびに/または会議に関わり得るメディアストリームを考慮したコーディングおよび復号要求を含むように実装され得る。能力および要求情報の大部分は、端末と集中型プロセッサとの間で通信されるSDPオファーおよび応答メッセージ中に含められ得る。ただし、SDPオファーおよび応答メッセージの通信に先立って交渉または能力の交換を実施することによって、SDPオファーおよび応答メッセージは、会議アーキテクチャのデバイスの間での会議の確立に有用な情報のみを含むように合理化され、縮小され得る。先行通信および能力の交換は、会議開始者が、いずれの参加者の並列符号化および復号能力も超えない会議を確立し得るためにも必要である。したがって、並列コーデック能力を交換するために通信される交渉メッセージは、SDPオファーおよび応答メッセージが含むことになる情報の少なくとも一部を含み得る。

交渉メッセージは、端末および/またはプロセッサの間で効率的に、ならびにネットワークおよび/または処理リソースに負担をかけずに交渉メッセージが通信され得るような連結された形で、必要なSDPオファーおよび応答情報を含むように構成され得る。たとえば、交渉メッセージには、様々なパラメータが任意選択で含まれてよく、パラメータは、SDPオファーおよび応答メッセージ中に常に維持され得る。いくつかの実施形態では、交渉メッセージは、単一行メッセージ中で、SDPオファーおよび応答メッセージ中に含まれる40行を超える情報を伝えることができる。

いくつかの実施形態では、本明細書に記載する交渉メッセージは、1つまたは複数の端末がそれらの並列コーデック能力を提供することをリクエストする交渉リクエストメッセージとして送られ得る。いくつかの実施形態では、本明細書に記載する交渉メッセージは、交渉リクエストメッセージに応答する交渉応答メッセージとして送られ得る。いくつかの実施形態では、交渉リクエストメッセージは、リクエストを送る端末またはプロセッサの能力を含み得る。いくつかの実施形態では、交渉応答メッセージは、リクエスト側端末もしくはプロセッサの能力との関連で、またはリクエスト側端末もしくはプロセッサの能力に依存せずに、応答側端末またはプロセッサの能力を含み得る。いくつかの実施形態では、リクエストメッセージまたは応答メッセージのいずれかとしての交渉メッセージは、本明細書においてより詳しく記載するように、コーデック能力のリストの指示を含み得る。

たとえば、開始者端末から通信される交渉メッセージは、所望の属性および/または情報を次のように含むように定義することができよう。以下は、交渉メッセージ構造の拡張バッカス-ナウア記法(ABNF)表現であることに留意されたい。
codec_list="a" "=" "codec_list" ":" codeclist ":" "ENC:" num [*63(rule num)] ":" "DEC:" num [*63(rule num)]
codeclist="{" codec SP [level] SP [profile] "};" *63(";{" codec SP [level] SP [profile] "}")
codec=byte-string; RFC 4566において定義されるbyte-string
level=1*3DIGIT
profile=1*3DIGIT
rule=";" / ","
num=%d1-16

したがって、上のABNFコードは、並列コーデック能力情報を含む交渉メッセージが、通信用にどのように生成され得るかに対応する。交渉メッセージは、メッセージを送るエンティティが使うことが可能であるコーデックのリスト(たとえば、メッセージを送るエンティティによってサポートされるコーデックのリスト)を含み得る。いくつかの実施形態では、交渉メッセージを(応答またはリクエストのいずれかとして)送るどのエンティティも、対応する交渉メッセージ(リクエストまたは応答のいずれか)を受信することが可能である。

SDPオファーおよび応答メッセージに関連した交渉メッセージのサイズを低減するために、様々なパラメータおよび/または情報が、交渉メッセージにおいて除外され、または適応され得る。たとえば、いくつかの実施形態では、すべてのコーデックがコーデックレベルおよび/またはコーデックレベル情報を含み得るわけではないが、ビデオコーデック解像度を識別することができるコーデックレベルパラメータが、任意選択で交渉メッセージ中に含まれてよい。同様に、他の様々なパラメータが任意選択で含まれてよく、したがって、交渉メッセージが、SDPオファーおよび応答メッセージと比較して、サイズを低減されることを可能にする。

さらに、交渉メッセージは、いつ、またはどのようにして、1つまたは複数のコーデックが他のコーデックによって置き換えられ得る(たとえば、1つまたは複数のコーデック用のリソースが、他のコーデックによって代わりに使われ得る)かを示すように構成されてよい。たとえば、交渉メッセージは、集中型端末が、複数のコーデックを介して通信を復号することが可能であることを示し得る。たとえば、集中型端末は、その端末が、高品質ボイスサービス(EVS)、適応マルチレート(AMR)、および適応マルチレート広帯域(AMR-WB)を復号することが可能であることを示すことができ、同時に、プロセッサ上で稼働するEVSのインスタンスが、AMR-WBのインスタンスで置き換えられ得ること、およびAMR-WBのインスタンスが、必要に応じて、AMRのインスタンスで置き換えられ得ることを示す。さらに、交渉メッセージは、(本明細書におけるメッセージ定義に示すように)<codec>インスタンスと同じ数の<num>インスタンスを要求するようにさらに構成されてよい。いくつかの実施形態では、1つまたは複数のパラメータが、SDPオファーおよび/または応答メッセージ中には含まれるが、交渉メッセージからは除外され得る。

いくつかの実施形態では、上の交渉メッセージ定義に示されるように、項<codec>は、そのコーデック用のリアルタイムプロトコル(RTP)ペイロードフォーマットにおいて定義される、コーデックのメディアタイプ名に対応する。いくつかの実施形態では、項<codec>の例は、それぞれ、H.264ビデオ圧縮コーデックに対応する「video/H264」および/またはH.265ビデオ圧縮コーデックに対応する「video/H265」を含み得る。項<codec>によって識別されるコーデックは、交渉用メッセージを送る端末またはプロセッサが、メディアストリームをコーディングおよび/または復号する際に使用するように構成されるコーデックに対応し得る。交渉メッセージは、項<codec>によって識別される1つまたは複数のコーデックを含むことができ、たとえば、本明細書において示される交渉メッセージ#1は、EVS、AMR、およびARM-WBを、項<codec>によって識別されるコーデックとして含む。

項<level>は、上述したように、任意選択である。項<level>は、コーデックのレベルを指定することができ、レベルは、ビデオコーデックについて、どの解像度がサポートされるかを識別する。たとえば、項<codec>がH.264またはH.265コーデックのいずれかを示すとき、項<level>は、それぞれ、level_idcまたはlevel-idに等しくてよい。項<codec>がEVSコーデックを示すとき、項<level>は、1、2、3および/または4に等しくてよく、これは、それぞれ、狭帯域(NB)、WB、超広帯域(SWB)、および全帯域(FB)を指定する。

さらに、項<profile>も、交渉メッセージ中で任意選択である。項<profile>は、コーデックのプロファイルを指定することができ、プロファイルは、ビデオコーデックについて、どの標準化ツールがビデオエンコーダによって使われるかを識別する。たとえば、項<codec>によって示されるコーデックH.264およびH.265について、項<profile>は、それぞれ、profile_idcおよびprofile-idを示すか、またはそれらと等しくなり得る。項<profile>が交渉メッセージ中に含まれる場合、項<level>も含まれなければならない。一方、交渉メッセージが、項<profile>を含まずに項<level>を含むことが許容される。

交渉メッセージの項<rule>は、コーデックの並列インスタンス用に使われるリソースが、コーデックの前または後に列挙されるコーデックの並列インスタンスによって代わりに使われ得るかどうかを指定し得る。たとえば、本明細書に記載する交渉メッセージ#1中で、項<codec>は、AMR、AMR-WB、およびEVSコーデック(必ずしもその順序ではない)を識別する。項<rule>に基づいて、次の列挙されるコーデックは、計算がより複雑でなくてよく、したがって、前に列挙されるコーデックと同じプロセッサ上で稼働することができる。たとえば、項<rule>が「,」に等しいとき、項<codec>の1つまたは複数のインスタンスは、次の1つまたは複数の列挙されるコーデックで置き換えられ得る。ただし、項<rule>は、次の列挙されるコーデックが、計算がより複雑であるか、または別個のプロセッサ上で実装され、したがって、前に列挙されるコーデックと同じプロセッサ上では稼働し得ないことも示し得る。たとえば、項<rule>が「;」に等しいとき、項<codec>の1つまたは複数のインスタンスは、次の列挙されるコーデックで置き換えることはできない。したがって、項<rule>は、交渉メッセージを受信する端末および/またはプロセッサに対して、復号プロセッサがコーディングプロセッサよりも柔軟であることを示すように構成され得る。

本明細書における交渉メッセージ#1中に示される項<num>は、サポートされる並列エンコーダまたはデコーダの最大数を指定し得る。たとえば、交渉メッセージ中でテキスト「ENC」に項<num>が続くとき、項<num>は、(存在するとき、指定されたレベルおよびプロファイルにおいて)項<codec>によって指定されるコーデックの各々のサポートされる並列エンコーダの最大数を示す。同様に、交渉メッセージ中でテキスト「DEC」に項<num>が続くとき、項<num>は、(存在するとき、指定されたレベルおよびプロファイルにおいて)項<codec>によって指定されるコーデックのサポートされる並列デコーダの最大数を示す。テキスト「ENC」の直後に続く項<num>によって識別されるインスタンスの数およびテキスト「DEC」の直後に続く項<num>によって識別されるインスタンスの数は両方とも、項<codec>によって識別されるインスタンスの数と同じであるものとする。さらに、いくつかの実施形態では、項<num>によって識別されるインスタンスは、同位の項<codec>によって識別されるインスタンスにマップされ得る。

いくつかの実施形態では、端末および/またはプロセッサは、実際に復号したいくつかの受信されたメディアストリーム(m行)をトリミングすることができる場合がある。したがって、端末および/またはプロセッサは、端末および/またはプロセッサが、復号するための並列復号能力を実際に有するよりも多数のメディアストリームを復号することができる示す値を有する項<num>を広告することができる。

本明細書における記述によると、交渉メッセージは、単一SDP行中で、端末および/またはプロセッサによってサポートされる並列コーデック能力(エンコーダおよびデコーダ能力の両方を含む)の通信および/または交渉を提供し得る。たとえば、以下のTable 1(表1)は、典型的なSDPオファーメッセージを示す。このSDPオファーメッセージは、Table 2(表2)に関連して記載される、MSMTSI端末として構成された開始者端末の構成「A」に対応し得る。

示されるように、SDPオファーメッセージは、40を超えるSDP行を含む。これらのSDP行の多くは、本明細書に記載する交渉メッセージ中に含まれる情報を含み得る。ただし、これらの行は、SDPオファーメッセージ中に40近くの個々のSDP行を含み得るが、本明細書に記載する交渉メッセージは、これらの40行を単一行に削減することができる。広範囲SDPオファーメッセージのそのような削減は、端末および/またはプロセッサの各々において、SDPオファーおよび応答メッセージを受信し、処理し、応答するために場合によっては要求される通信および計算リソースの数を削減する。たとえば、本明細書に記載する交渉メッセージは、上のTable 1(表1)において「**」でオフセットされた、SDPオファーメッセージの行(38のSDP行に等しい)を、単一行交渉メッセージ#1に削減する。
交渉メッセージ#1
a=codec_list:EVS;AMR-WB;AMR:ENC:1;1;1:DEC:3,1,1

さらに、以下のTable 2(表2)に示す構成「B」および「C」用のSDPオファーメッセージも、交渉メッセージ中で通信されるとき、同様に削減され得る。たとえば、以下の組合せ「B」のSDPオファーメッセージ用の42のSDP行が、交渉メッセージ#2の単一SDP行で置き換えられ得る。
交渉メッセージ#2
a=codec_list:EVS;AMR-WB;AMR:ENC:1;1;0:DEC:4,1,0

同様に、以下の組合せ「C」のSDPオファーメッセージの44のSDP行が、交渉メッセージ#3の単一SDP行で置き換えられ得る。
交渉メッセージ#3
a=codec_list:EVS;AMR-WB;AMR:ENC:1;0;0:DEC:5,0,0

したがって、合計で、本明細書に記載するような交渉メッセージの使用は、(Table 2(表2)に記すように)6人の参加者とのCCCexを維持しながら、SDP行のうちの124行を3つのSDP行で通信することができ、通信オーバーヘッドにおいて41:1の削減よりも大きいものに等しくなる。したがって、本明細書に記載する交渉メッセージを使うと、概して、以下の圧縮比に従ってSDP行を削減することができる。
圧縮比1≧(5*(N-2)+4):1、ここで
・Nは、並列デコーダ(たとえば、ユーザ)の数であり、
・mは、並列デコーダをサポートするコーデックの組合せの数である。
したがって、大幅な通信および処理オーバーヘッドおよびリソース節約がもたらされ得る。

いくつかの実施形態では、通信および計算リソースをさらに削減するために、端末が、いくつかの受信されたストリームを、復号するのに先立って「トリミングする」ように構成され得る。トリミングは、復号される予定の、受信されたストリームの数の削減を伴うことができ、端末における復号用計算リソースを節約することができる。そのような「トリミング」能力は、端末が、端末が並列に復号することが可能であるよりも多くのメディアストリーム(たとえば、m行)を列挙することによってSDPオファーをブロードキャストすることによって示され得る。したがって、そのような端末は、新規のコンパクトSDP属性を、最大12個以上の並列デコーダを含むように生成するように構成されてよく、圧縮比が≧54:1に増す。

いくつかの実施形態では、上述したように交渉メッセージが交換されると、端末またはプロセッサのうちの1つまたは複数が、本明細書においてさらに記載するように、1つまたは複数の他の端末またはデバイスへの通信用に、1つまたは複数オファーメッセージおよび/またはデータストリームを生成し、通信し得る。いくつかの実施形態では、コーデック能力のリストの指示は、本明細書においてさらに詳しく記載するように、通信用のコーデックのタイプを選択するために使われ得る。たとえば、交渉応答メッセージが、どのコーデックを扱うように端末が構成されているかを示すことができ、プロセッサ(または開始者端末)は、交渉応答メッセージの指示に基づいてコーデックタイプを選択すればよい。いくつかの実施形態では、どの所与のプロセッサまたは端末についてのコーデック能力のリストのインジケータまたは指示も、データベースまたは他の記憶ロケーションに記憶され、かつ/またはそこから取り出され得る。いくつかの実施形態では、会議によってサポートされるコーデック能力のリストは、2つ以上のデバイスの各々によってサポートされるコーデック能力のリストの指示に少なくとも部分的に基づき得る。

図3は、複数の参加者のための非集中型会議アーキテクチャ300の別の例を示す。いくつかの実施形態では、開始者端末110Aは、端末110Bおよび110Cに複数のコーデックをオファーし得る。オファーは、上述した交渉メッセージを使う交渉が完了された後で通信され得る。たとえば、図3に示すように、端末110Aは、高機能ボイスサービス(EVS)コーデックと適応マルチレート広帯域(AMR-WB)の両方を端末110Bおよび110Cにオファーする。いくつかの態様において、オファーは、セッション記述プロトコル(SDP)オファーメッセージを含み得る。図示されるように、端末110Cは、EVSをサポートし、EVSを選択するメッセージで応答する。端末110Bは、AMR-WBをサポートし、端末110Aへの応答においてAMR-WBを選択するだけでよい。いくつかの態様において、端末110Aからのオファーに応答して端末110Bおよび110Cが送るメッセージは、SDP返答メッセージを含み得る。端末110Bおよび110Cは、独自のコーデック交渉(たとえば、端末110Aからのセッション開始プロトコル(SIP)REFERメソッドによるセットアップ)を実施することもでき、交渉において、端末110Bおよび110Cは、端末110BがEVSをサポートしないので、AMR-WBを選ぶ。図3からわかるように、端末110Aおよび110Cは両方とも、それらのコンテンツをEVSおよびAMR-WBフォーマットで並列に符号化しなければならないが、端末110Bは、AMR-WBフォーマットで符号化/復号する必要のみがある。

図4は、端末/メディアゲートウェイ450が混合器として機能する、複数の参加者のための例示的なハイブリッド会議アーキテクチャ400の図である。図4に示すように、端末110A〜Cは各々、データストリームを端末/メディアゲートウェイ450に送ってよく、それは次いで、複数のデータストリームを端末110A〜Cに送る。たとえば、端末/メディアゲートウェイ450は、端末110Bおよび110Cからデータストリームを受信し、それらのデータストリームを復号し、端末110Aに送り得る。いくつかの態様において、端末/メディアゲートウェイ450は、端末110Bおよび110Cからのデータストリームを混合し、混合データストリームを端末110Aに送ればよい。

一実装形態では、端末110Aは、いくつかの制限または会議パラメータに基づいて、端末/メディアゲートウェイ450から受信するデータストリームの数を調節してよい。たとえば、端末110Aは、端末/メディアゲートウェイ450(または図1の集中型プロセッサ125)処理能力を、それ自体の処理を削減し、もしくはオフロードし、または会議アーキテクチャ(集中型、非集中型、もしくはハイブリッドのいずれか)制限内での効率的通信を保証するのに使用することができる。一態様では、端末110Aは、1つのデータストリームを復号することだけが可能であり得るので、または端末110Aが限定処理能力を有するので、端末110Aは、端末/メディアゲートウェイ450に、1つの混合データストリームのみを送るようリクエストする場合がある。

さらに、図1〜図4(および以下の図5)の端末110A〜D、集中型プロセッサ125、および/または端末/メディアゲートウェイ450が、能力を切り替えることが可能であり得る。たとえば、端末110A〜Dおよび集中型プロセッサ125は、図1の会議アーキテクチャ100において動作中の場合があり、集中型プロセッサ125は、電力をなくし、または混合能力を失う場合がある。いくつかの態様において、端末110Dは、会議参加者としての動作から、図4の非参加端末/メディアゲートウェイ450としての動作に切り替える場合があり、集中型プロセッサ125機能を本質的に置き換える。さらに、図4の端末/メディアゲートウェイ450はまた、それ自体のデータストリームを会議への1人または複数の参加者(たとえば、端末110A〜D)に送ることによって、会議における参加端末/メディアゲートウェイ450として動作することができる。したがって、端末110A〜Dの各々、集中型プロセッサ125、および/または端末/メディアゲートウェイ450は、図1の集中型会議アーキテクチャ100、図2および図3の非集中型会議アーキテクチャ200および300、ならびに図4のハイブリッド会議アーキテクチャ400のうちの1つまたは複数において動作するように構成され得る。

一例では、会議(たとえば、会議アーキテクチャ100、200、300、400、および500[以下で論じる])は、第1の持続時間および第2の持続時間を含む会議持続時間を有し得る。いくつかの態様では、第1の持続時間中、端末110Dは、図1に示したように会議参加者として動作し得る。いくつかの態様では、第2の持続時間中、端末110Dは、図4(および以下の図5)に示される端末/メディアゲートウェイ450としての動作に切り替え得る。いくつかの態様において、端末110Dは、動作機能を、集中型プロセッサ125に、端末110A〜C(図1に示した)のうちの1つもしくは複数に、または別のコントローラもしくはデバイスに切り替えるようリクエストし得る。他の態様では、集中型プロセッサ125または端末110A〜C(図1に示した)のうちの1つもしくは複数が、端末110Dは、端末/メディアゲートウェイ450としての動作に切り替えることが可能であると判断し得る。

いくつかの態様では、会議開始または関連付けが、第1の持続時間中に起こる場合があり、会議データの交換が、第2の持続時間中に起こる場合がある。たとえば、図2および図3に関して、端末110Aは、第1の持続時間中、端末110Aによってサポートされるコーデック能力のリストを含むオファーメッセージを端末110Bおよび110Cに送信し得る。端末110Aは、端末110Bおよび110Cの各々から応答メッセージを受信し得る。応答メッセージは、それぞれの端末110Bまたは110Cのコーデック能力のリストと、端末110Bおよび110Cによって選択されたコーデックタイプとを含み得る。端末110Aは、応答メッセージの各々の中のコーデック能力のリストに基づいて、端末110Bおよび110Cの各々が、会議に参加することができるかどうかを判断し得る。第2の持続時間中、端末110A〜Cは、互いの間でデータストリームを交換し得る。

いくつかの態様では、集中型プロセッサ125または端末110A〜Cのうちの1つもしくは複数が、端末110Dが端末/メディアゲートウェイ450としての動作に切り替えることをリクエストし得る。いくつかの実施形態では、リクエストは、端末110Dの符号化/復号能力に基づき、かつ/あるいは集中型プロセッサ125または端末110A〜Cのうちの1つもしくは複数の符号化/復号能力に基づき得る。たとえば、端末110Aは、2つのデータストリームを受信することしかできないと判断する場合があり、端末110Dに、動作を切り替えるようリクエストすればよい。リクエストは、端末110Dが、端末110Bおよび110Cからの通信を処理し、混合すること、ならびに端末110Dが混合データストリームを端末110Aに送ることをリクエストすることを含み得る。いくつかの態様において、端末110Bおよび110Cについての新規の会議識別子または会議ユニフォームリソース識別子(URI)が、端末110Dについてのアドレスであることを示すリクエストが、端末110A、110Dのうちの1つ、または集中型プロセッサ125から端末110Bおよび110Cに送信され得る。いくつかの態様において、端末110Bおよび110C向けのデータストリームを処理し、混合するための、リクエストまたは新規の宛先(すなわち、端末110D)の指示は、帯域外通信により送られ得る。リクエストに応答して、端末110Bおよび110Cは次いで、集中型プロセッサ125へのデータストリームの送付から、端末110Dへのデータストリームの送付に切り替えればよい。切替えに関わる潜在的待ち時間問題を削減するために、端末110Bおよび110Cは、切替えが完了したと集中型プロセッサ125および/または端末110Dが判断するときまで、集中型プロセッサ125と端末110Dの両方にデータストリームを送ればよい。

図5は、端末/メディアゲートウェイ450が混合器および参加者として機能する、複数の参加者のための例示的なハイブリッド会議アーキテクチャ500の図である。図5に示すように、端末110Aが、会議への参加者としての端末110B、端末/メディアゲートウェイ450、および端末110D〜Eとの会議を開始し得る。端末110Aは、参加者(端末110B、端末/メディアゲートウェイ450、および端末110D〜E)が会議に加わるような、どの方法によって会議を開始してもよい。たとえば、端末110Aは、参加者との帯域外通信(たとえば、会議を示すeメール通信および/またはカンファレンスブリッジ)を使って会議を開始し得る。いくつかの態様において、端末110Aは、端末110Bおよび端末/メディアゲートウェイ450について上述したREFERメソッドを、端末/メディアゲートウェイ450を介して端末が会議に加わるための、端末110Dおよび110Eへの帯域外通信と組み合わせて利用することによって、会議を開始することもできる。他の態様では、端末110Aは、会議の始まりを告知するポールメッセージを通して会議を開始することができ、端末110Bおよび110D〜Eならびに端末/メディアゲートウェイ450は、会議に加わるために、それらのコーデック能力とともにメッセージを送信することができる。上述したように、会議を開始するための他の方法も可能である。

図1〜図4に関して上述したように、端末110Aは、会議を開始するとき、参加者の各々の符号化/復号能力を検討してよい。図5において、端末110Aは、端末110Bにデータストリーム516を送信し、端末/メディアゲートウェイ450にデータストリーム519を送信し、データストリーム517および521を、それぞれ端末110Bおよび端末/メディアゲートウェイ450から受信することができる。端末110Bも、端末/メディアゲートウェイ450にデータストリーム518を送信し、端末/メディアゲートウェイ450からデータストリーム520を受信することができる。端末/メディアゲートウェイ450も、端末110Dおよび110Eから、それぞれ、データストリーム524および525を受信し、端末110Dおよび110Eに、それぞれ、データストリーム522および523を送信することができる。データストリーム516〜525の各々は、1つまたは複数のオーディオおよび/またはビデオ(メディア)ストリームを含み得る。

いくつかの実施形態では、端末/メディアゲートウェイ450は、混合器と会議への参加者の両方として機能する。たとえば、端末/メディアゲートウェイ450は、端末110Aからデータストリーム519を、端末110Bからデータストリーム518を、端末110Dからデータストリーム524を、および端末110Eからデータストリーム525を受信し得る。いくつかの態様において、端末110Dおよび110Eは、各々1つのデータストリームだけを復号することができる場合があり、端末110Aおよび110Bは各々、3つのデータストリームだけを復号することができる場合がある。いくつかの態様において、端末110Aおよび110Bは、端末110Dおよび110Eと比較して、新規または高効率端末と見なされ得る。いくつかの態様において、端末110Dおよび110Eは、レガシーまたは端末110Aおよび110Bよりも古いデバイスと見なされ得る。一実施形態では、端末/メディアゲートウェイ450は、端末110Dに単一の混合データストリーム522を、および端末110Eに単一の混合データストリーム523を送信し得る。いくつかの態様において、端末/メディアゲートウェイ450は、端末110Dおよび110Eにマルチキャスト混合データストリームを送信することができ、その間、端末110Aおよび110Bにユニキャストデータストリーム521および520を並列に送る。さらに、端末/メディアゲートウェイ450は、端末110Aにデータストリーム521を送信することができ、このデータストリームは、端末110Bからのデータストリーム、端末/メディアゲートウェイ450からのデータストリーム、ならびに端末110Dおよび110Eからの混合データストリームを含み得る。

他の態様では、端末/メディアゲートウェイ450は、会議への他の参加者からの、データストリームの他の組合せを送信することができる。たとえば、端末/メディアゲートウェイ450は、端末110Eからのデータストリームを無視し、端末110B、110D、および端末/メディアゲートウェイ450からのデータストリームのみを端末110Aに送信すればよい。端末/メディアゲートウェイ450(ならびに端末110A、110B、110D、および110Eのうちのいずれも)は、本明細書に記載する実装形態または組合せのうちのいずれかに従って、いくつかのデータストリームを優先し、選択し、かつ/または無視してよい。別の例示的実施形態では、端末/メディアゲートウェイ450は、端末からデータストリームを受信し、アクティブスピーチ(たとえば、110B、110C)であるストリーム、およびバックグラウンド/非アクティブスピーチ(たとえば、110D、110E)であるストリームを識別し得る。端末/メディアゲートウェイ450は、DTX/非アクティブフレームを復号し、混合し、1つの非アクティブフレームとして複数のアクティブフレームとともに(たとえば、端末110Aへ)送信することを選んでよい。多数の参加者(たとえば、N>10)がいるマルチパーティ会議では、上で論じた、端末/ゲートウェイ450におけるDTX/非アクティブフレームの選択的事前解析および混合により、処理のために端末において受信される複数のストリームの数を削減することができる。受信側端末(たとえば、110A)は今では、検査し、復号のために優先するべきより少ないストリームを有し得る。別の例示的実施形態では、端末/メディアゲートウェイ450は、DTX/非アクティブフレームに関連付けられた対応するビデオストリームを判断し、それらのビデオ/画像データストリームの、1つのビデオストリームへのタイリング/再符号化を実施することができ、そうすることによって、処理のために端末において受信される複数のビデオストリームの数を削減する。

図4に関して上述したように、いくつかの態様では、端末110A、110B、110D、110Eのうちのいずれも、および図5の端末/メディアゲートウェイ450は、様々なやり方で動作機能を切り替えることができる。たとえば、端末110Bおよび端末/メディアゲートウェイ450は、端末/メディアゲートウェイ450の混合動作を端末110Bに転送すると(たとえば、帯域外通信により、またはコーデック能力の分析を通して)決定し得る。いくつかの態様において、端末/メディアゲートウェイ450および/または端末110Bは、端末/メディアゲートウェイ450の処理および混合動作を端末110Bが引き継いでいる所であることを、他の会議参加者に直接または間接的のいずれかで(たとえば、帯域外で、または別の端末を通して)ブロードキャストし得る。端末110Bが、端末/メディアゲートウェイ450の処理動作を引き継ぐものとして論じられるが、他の実施形態では、端末110A、110D、もしくは110Eのいずれも、または別のデバイスが、同様に、端末/メディアゲートウェイ450の処理および/または混合動作と置き換わることができる。

他の実施形態では、端末/メディアゲートウェイ450は、今では会議データストリームを端末110Bに送るために会議参加者が端末/メディアゲートウェイ450に送っている会議データストリームを転送するよう他の会議参加者にブロードキャストするのに、REFERメソッドを使用することができる。さらに、会議参加者は、自分たちのそれぞれのデータストリームを、端末/メディアゲートウェイ450と端末110Bの両方に、すべての会議参加者が自分たちのデータストリームを端末110Bへ送信中になるまでの時間期間だけ、送り得る。同様に、端末/メディアゲートウェイ450および端末110Bは、潜在的割込みまたは待ち時間問題を削減するために、すべての端末が切り替えたと端末/メディアゲートウェイ450および/または端末110Bが判断するまで、ある時間期間、他の会議参加者から受信した複数のデータストリームの処理と混合の両方を並列に行うことができる。

いくつかの実施形態では、提供されるべき情報の粒度と、より多くの並列動作をサポートする能力を示すことが可能であることとの間にはトレードオフがあり得る。サポートされ得る並列セッション、たとえば、マルチパーティ会議開催のために特に設計された上位ビジネス端末についての詳細な情報を通信することをベンダまたはオペレータが望むシナリオまたはデバイスがあり得る。一方、ベンダまたはオペレータが非常に基本的な機能性を露出することを望むだけであるセッションへの3〜4人よりも多くの参加者をサポートするように設計されていない、中位から下位の端末があり得る。通信されるべき適切な量の情報はシナリオおよびデバイスに依存し得るので、異なるケースに合わせることが望ましい場合がある。上述したフォーマットのうちの1つを選ぶのではなく、いくつかの態様では、端末(たとえば、端末110A〜Eまたは端末/メディアゲートウェイ450)は、記述されるフォーマットのうちのいずれも選ぶことが可能であり得る。会議参加者からのコーデック能力情報をすべて受信しなければならない開始者端末(たとえば、端末110A)は、フォーマットすべてを復号し、理解することが可能であるべきである。

コーデック能力情報についての上記フォーマット要求を満たす一例は、各データタイプ(たとえば、オーディオもしくはビデオ)、または各コーデックの並列実装の最大数を通信することである。

データタイプごとの限度
たとえば、新規のセッションレベルSDP属性は、次のように定義することができよう。
a=max_dec_audio:<num_instances>
a=max_dec_video:<num_instances>
a=max_enc_audio:<num_instances>
a=max_enc_video:<num_instances>

いくつかの態様において、<num_instances>は両端値を含む1〜16の範囲内の整数であり、端末によってサポートされるそのデータタイプ(たとえば、第1および第3についてはオーディオ、または第2および第4についてはビデオ)の、(最初の2つについて)並列デコーダまたは(最後の2つについて)エンコーダの最大数を指定する。

または、新規のデータレベルSDP属性は、次のように定義することができよう。
a=max_dec:<num_instances>
a=max_enc:<num_instances>

いくつかの態様において、<num_instances>は、両端値を含む1〜16の範囲内の整数であり、端末によってサポートされる(最新の上の「m=」行の)データタイプの、並列デコーダ(a=max_decについて)またはエンコーダ(a=max_encについて)の最大数を指定する。

いくつかの実施形態では、この例示的なソリューションは、上述したコーデック能力情報についてのフォーマット要求を満たさない場合がある。いくつかの態様において、並列インスタンスのmax数は、最も計算集約的なコーデックによって制約を受け得る。例示的な実施形態では、端末がH.265コーデックをサポートし、最大2つのビデオエンコーダ出現(H.264およびH.265)を端末がサポートし得ることを宣言するビデオテレフォニーセッションのためには、これらの2つのビデオエンコーダ用に十分なリソースを予約しなければならないことを知っているので、端末は、扱うことができるデータ(たとえば、ビデオまたはスピーチ)のデコーダインスタンスの数を制限され得る。

いくつかの態様において、デコーダインスタンスの数に対する制限は、端末が、より複雑でないデコーダを使う、より多数の参加者がいる会議に含められるのを防止し得るか、または会議への参加者すべてが、より高度な任意選択のコーデックをセッション中に使うのを防止し得る。

コーデックタイプごとの限度
さらに、新規SDPパラメータは、次のように定義することができよう。
a=max_dec:<codec><num_instances>
a=max_enc:<codec><num_instances>

いくつかの態様において、<codec>は、コーデック用のRTPペイロードフォーマット、たとえば、それぞれ、IETF RFC6184(https://tools.ietf.org/html/rfc6184において入手可能)において定義されるH.264用の「video/H264」およびH.265 RTPペイロードフォーマット(最新バージョンは、https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14にある)において定義されるH.265用の「video/H265」において定義される、そのコーデックのデータタイプ名である。いくつかの態様において、<num_instances>は、両端値を含む1〜16の範囲内の整数であり、指定されたコーデックの、並列デコーダ(a=max_decの場合)またはエンコーダ(a=max_encの場合)の最大数を指定する。

他の実装形態では、異なるレベルのビデオコーデックが異なる能力であり得ることを考慮に入れるために、新規のデータレベルSDP属性は、次のように定義することができよう。
a=max_dec:<codec><level><num_instances>[<profile>]
a=max_enc:<codec><level><num_instances>[<profile>]

いくつかの態様において、<codec>は上と同じである。いくつかの態様において、<level>は、コーデックのレベルを指定し、たとえば、H.264およびH.265の場合、値は、それぞれ、ITU-T H.264仕様において定義されるlevel_idc、およびH.265 RTPペイロードフォーマット(最新バージョンは、https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14にある)において定義されるlevel-idに等しく、コーデックがEVSであるとき、1、2、3および4であるこのフィールドの値は、それぞれ、NB、WB、SWBおよびFBを指定する。いくつかの態様において、<num_instances>は、両端値を含む1〜16の範囲内の整数であり、指定されたレベルおよびプロファイル(存在するとき)における、指定されたコーデックの並列デコーダ(a=max_decの場合)またはエンコーダ(a=max_encの場合)の最大数を指定する。いくつかの態様において、任意選択である<profile>は、コーデックのプロファイルを指定し、たとえば、H.264およびH.265の場合、値は、それぞれ、ITU-T H.264仕様において定義されるprofile_idc、およびH.265 RTPペイロードフォーマット(最新バージョンは、https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14にある)において定義されるprofile-idに等しい。

いくつかの実施形態では、上記代替すべてのために、<num_instances>について0の値も許可されてよく、値0は、端末が、データストリームを拾い出し、トリミングすることが可能であることを指定する。いくつかの態様において、データストリームを拾い出し、トリミングすることが可能な端末は、無限数のデータストリームを扱うことができる。

他の実装形態では、ビデオコーデックのための別の代替は、新規SDP属性を次のように定義するものであってよい。
a=max_vdec_cap:<codec><max_block_ps>
a=max_venc_cap:<codec><max_block_ps>

いくつかの態様において、<codec>は上と同じである。いくつかの態様において、<max_block_ps>は、指定されたビデオコーデックのすべての並列ビデオデコーダ(a=max_vdec_capの場合)またはエンコーダ(a=max_venc_capの場合)によって処理され得る、毎秒当たりの8×8ルーマブロックの最大数を指定する。

いくつかの実施形態では、この例示的なソリューションは、上述したコーデック能力情報についてのフォーマット要求を満たさない場合がある。いくつかの態様において、会議開始者端末(たとえば、図2〜図5の端末110A)が、コーデックのミックスがあるとき、何個の並列エンコーダおよびデコーダがサポートされ得るかを、どのようにして正確に判断し得るかが明らかでない場合がある。いくつかの実施形態では、何個の並列エンコーダおよびデコーダがサポートされ得るかを推定するやり方は、使われている最も計算負担の重いコーデックのエンコーダ/デコーダ限度を使うものである。いくつかの態様において、エンコーダ/デコーダ限度は、最も複雑なコーデックによって制約を受ける場合があり、それは、端末が扱うことができるデータ(たとえば、ビデオまたはスピーチ)のデコーダインスタンスの数を制限し得る。たとえば、いくつかの態様において、デコーダインスタンスの数に対する制限は、端末が、より複雑でないデコーダを使う、より多数の参加者がいる会議に含められるのを防止し得るか、または会議への参加者すべてが、より高度な任意選択のコーデックをセッション中に使うのを防止し得る。

コーデック能力情報についての上記フォーマット要求を満たす別の例は、各符号化/復号機能に利用可能または割り振られるプロセッサリソースの割合を記述することである。これにより、開始者端末は、所与のプロセッサにおいて、割り振られるリソースの100%程度の総複雑性負荷を保つ限り、異なるデータタイプのものを含むコーデックを、それらのエンコーダおよびデコーダとともに混合し、マッチングすることができる。上記情報の1つの記述法は、2つの新規SDP属性を採り入れることであり得る。
a=enc_use:<codec><alloc_factor><proc_idx>
a=dec_use:<codec><alloc_factor><proc_idx>
上式で、<alloc_factor>は、0〜1.0に渡り、プロセッサインデックス<proc_idx>をもつプロセッサを符号化(a=enc_useの場合)または復号(a=dec_useの場合)に使うときの、指定されたコーデック用のリソース割振り係数を記述する。

他の実施形態では、上記情報の別の記述法は、2つの新規SDP属性を採り入れることであり得る。
a=enc_use:<codec><level><alloc_factor><proc_idx>[<profile>]
a=dec_use:<codec><level><alloc_factor><proc_idx>[<profile>]

いくつかの態様において、<codec>、<level>、および<profile>は上と同じである。いくつかの態様では、<alloc_factor>は、0〜1.0に渡り、プロセッサインデックス<proc_idx>をもつプロセッサを符号化(a=enc_useの場合)または復号(a=dec_useの場合)に使うときの、指定されたレベルでの指定されたコーデック用のリソース割振り係数を記述する。いくつかの実施形態では、開始者端末は、各参加者からの上記情報を、提案される会議が、参加者の並列コーデック能力のうちのいずれも超えないことを保証するのに使えばよい。

情報は、Table 3(表3)において次のように概念化され得る。

コーデック並列コーデック組合せプロファイルの列挙
コーデック能力情報についての上記フォーマット要求を満たす別の例示的なソリューションは、端末が同時に扱うことができるコーデック動作の組合せすべてを列挙することである。これは、各コーデック機能によって消費されるプロセッサローディングを通信することを要求しないという利点を有し得る。以下のTable 4(表4)は、前のセクションにおいて記載したプロセッサローディング係数に基づく、サポートされるプロファイルの非網羅的リストを与える。たとえば、プロセッサローディング係数は、Table 3(表3)に関して上述したリソース割振り係数を含み得る。いくつかの態様において、端末によるコーデックタイプまたはデータタイプの選択は、プロセッサローディング係数またはリソース割振り係数に基づき得る。

いくつかの実施形態では、2つの新規SDP属性、すなわちa=enc_listおよびa=dec_listが、次のように(拡張バッカス-ナウア記法(ABNF)で)定義される。
enc_list="a" "=" "enc_list" ":" combination [*63(";" combination)]
dec_list="a" "=" "dec_list" ":" combination [*63(";" combination)] combination=1*32(num SP codec SP level SP [profile]))
num=%d1-16
codec=byte-string
;RFC4566において定義されるバイトストリング
level=1*3DIGITDIGIT
profile=1*3DIGIT

いくつかの態様において、numは、リストのエントリにおける指定されたレベルおよびプロファイル(存在するとき)での、指定されたコーデックのサポートされる並列エンコーダ(a=enc_listの場合)またはデコーダ(a=dec_listの場合)の最大数を指定する。いくつかの態様において、codec、levelおよびprofileは、それぞれ、リストのエントリにおける、上に挙げた<codec>、<level>および<profile>と同じセマンティクスを有する。

代替として、新規SDP属性が、次のようにABNFにおいて定義され得る。
codec_list="a" "=" "enc_list" ":" function ":" combination [*63(";" combination)]
function="ENC" / "DEC"
combination=1*32(num SP codec SP level SP [profile])
num=%d1-16
codec=byte-string
;RFC4566において定義されるバイトストリング
level=1*3DIGIT
profile=1*3DIGIT

いくつかの態様において、numは、リストのエントリにおける指定されたレベルおよびプロファイル(存在するとき)での、指定されたコーデックのサポートされる並列エンコーダ(function=「ENC」のとき)またはデコーダ(function=「DEC」のとき)の最大数を指定する。いくつかの実施形態において、codec、levelおよびprofileは、それぞれ、上に挙げた、<codec>、<level>および<profile>と同じセマンティクスを有する。

他の実施態様では、新規SDP属性が、次のようにABNFにおいて定義され得る。
codec_list="a" "=" "codec_list" ":" codeclist ":" "ENC:" combination [*63(";" combination)] ":" "DEC:" combination [*63(";" combination)]
codeclist="{" codec SP level SP [profile] "};" *15(";{" codec SP level SP [profile] "}")
combination=1*32(num SP codec_idx)
codec=byte-string
;RFC4566において定義されるバイトストリング
level=1*3DIGIT
profile=1*3DIGIT
num=%d1-16
codec_idx=%d1-16

いくつかの態様では、codec、levelおよびprofileは、それぞれ、上に挙げた、<codec>、<level>および<profile>と同じセマンティクスを有する。いくつかの態様において、numは、指定されたレベルおよびプロファイル(存在するとき)での、指定されたコーデックのサポートされる並列エンコーダ(組合せが「ENC」に続くとき)またはデコーダ(組合せが「DEC」に続くとき)の最大数を指定する。いくつかの態様において、codec_idxは、指定されたレベルおよびプロファイル(存在するとき)における指定されたコーデックのリストcodeclistへのインデックスを指定する。

いくつかの実施形態では、numは、num=%d0-16として定義され得る。上の記述および式に加え、0の値は、端末が、データストリームを拾い出し、トリミングすることが可能であることを指定する。いくつかの態様において、データストリームを拾い出し、トリミングすることが可能な端末は、無限数のデータストリームを扱うことができる。

他の実施形態では、すなわち、numが、両端値を含む1〜16の範囲内である上記代替では、もう1つの新規SDP属性が、次のように定義される。
a=stream_trimming

いくつかの態様において、この属性の存在は、端末が、データストリームを拾い出し、トリミングすることが可能であることを指定する。いくつかの態様において、データストリームを拾い出し、トリミングすることが可能な端末は、無限数のデータストリームを扱うことができる。組合せにおけるnumの値は依然として、特定のコーデックの実際にサポートされる並列エンコーダまたはデコーダの最大数、プロファイルおよびレベルを指定する。この場合、端末は、いかなる量のデータストリームも受信することができ、データストリームを、各コーデック/プロファイル/レベル組合せについてのa=codec_list属性によって許可される量までトリミングすればよい。

いくつかの態様では、多くのコーデック組合せがあってよく、サポートされるコーデックの数が増すと、指数関数的に増す。これにより、メッセージサイズ、たとえば、SDP/SIPが増大する。たとえば、シグナリングのある程度の削減は、コーデック機能を複雑性の降順で列挙するなどの追加規則を適用することによって行われ得る。次いで、より高い複雑性のコーデック機能のインスタンスの数が1だけ低減された場合、同じプロセッサ上のより複雑でないコーデック機能のうちの1つの、インスタンスが少なくとも1だけ増大され得ることを理解されたい。いくつかの態様では、これは、インスタンスの数が低減されるコーデックプロセスが、コーデックが処理する他のプロセスよりも複雑であるときに最適に満たない限度を与え得るが、いくつかのプロファイルを省かせる場合がある。いくつかの態様において、端末が、最大解像度画像とともにサイマルキャストされるサムネイルを生成する必要がある場合、同じビデオコーデックの並列動作が必要であり得る。

サポートされる並列コーデック組合せのプロファイル
Table 4(表4)に列挙されるプロファイルは、一度にただ1つのエンコーダがサポートされるとき、同じコーデックを使うビデオ(すなわち、低および高解像度画像)のサイマルキャストを要求する使用ケースにはうまく該当しない場合がある。これは、プロファイル方式自体ではなくプロセッサローディングの限定であり得る。

いくつかの実施形態では、Table 4(表4)のプロファイルA〜Dは、EVSの使用を許可しないことの代償としてH.265を使う「HDビデオ」プロファイルと思われ得る。プロファイルA〜Cは、4つのH.264ストリームの復号を扱うことができるが、1つのビデオストリームを符号化することだけが可能であり得るので、典型的なマルチ-ユニキャストビデオ会議では使うことはできない。いくつかの態様において、この端末のユーザは、ビデオ、たとえば、手話を通信するために使われるビデオサイドバー会話を他の参加者のうちの1人に送ることだけを望む場合がある。

単純な2パーティビデオセッションの他に、プロファイルA〜Dは、H.265コーデックが、すべての端末によってサポートされることが知られているマルチキャストまたは「フォーカスベースのマルチキャスト」会議により適用可能であり得る。AMR-NB復号がサポートされないとき、AMR-NBが、オファーされるサービス用の必須コーデックである場合、プロファイルCは、無効と見なされ得ることに留意されたい。

いくつかの態様において、プロファイルFは、スピーチ専用会議において使われるべき「HDボイス専用」プロファイルと思われ得る。同じエンコーダを使う、スピーチの同時符号化を要求する使用ケースはまだ識別されないので、スピーチ専用プロファイルは、各スピーチエンコーダの1つのインスタンスを並列に操作することを検討する必要のみがあり得る。これにより、スピーチ専用会議用に列挙される必要があるプロファイルの数を簡約することができ、13人を超える参加者をサポートする会議は見込みがなく、(以下でさらに記載する)端末のRTPストリーム処理限度を十分に超え得るので、プロファイルFは、唯一の関連スピーチ専用プロファイルであるように見える。

受信されたメディアストリームのトリミングまたは削減を、(以下でさらに説明するように)それらすべてを復号することを要求せずに実施する端末について、デコーダ機能のインスタンスの数は、Table 5(表5)において、次のように「無限大」と示され得る。Table 5(表5)は、受信されたオーディオデータの3つのストリームまでトリムダウンすることができる端末のための例示的な実施形態を示す。

図1〜図5を参照して上述したように、受信側端末またはデバイス(たとえば、端末110B、端末/メディアゲートウェイ450など)は、並列に操作/復号しなければならないデコーダインスタンスの数を低減するために、特定のデータストリームを優先し、無視してよい。端末が、そのような「トリミング」アルゴリズムを利用し、その並列復号能力をマッチングするために復号しなければならないデータストリームの数を制限することが可能な場合、端末は、端末の復号能力に基づいて、会議開始者に、呼への参加者の数を制限するよう要求しない。この場合、端末は、Table 6(表6)の以下の例に示すように、そのようなデータストリームに対応する、0のリソース割振り係数を示せばよい。

RTPストリーム処理限度
多くのデータストリームの並列復号をサポートすることが可能であることにより、復号が、会議のサイズを設定する際の制限係数ではあり得ない見込みが生じる。端末のプロトコルスタックによって扱うことができるリアルタイムトランスポートプロトコル(RTP)データストリームの数は、制限係数になる。したがって、この情報を通信することも有益であり得る。さらに、並列RTPスタックの数に対する限度を指定するために、2つの新規のセッションレベルSDP属性が定義され得る。
a=rtp_tx_limit:<rtp_instances>
a=rtp_rx_limit:<rtp_instances>

いくつかの態様において、<rtp_instances>は、両端値を含む1〜32の範囲内の整数であり、サポートされる並列RTPセッションの最大数を指定する。いくつかの態様において、会議開始者端末(たとえば、図2〜図5の端末110A)は、会議への各参加者からの上記情報を、提案される会議が、参加者のコーデックまたはRTP処理能力のいずれも超えないことを保証するのに使う。

いくつかの実施形態では、開始者端末は、その並列コーデック能力、および並列能力が前もってわかっている他の参加者の能力に基づいてオファーメッセージを送り得る。オファーメッセージを受信した後、各参加者の端末は、オファーメッセージを調べて、Nと、前のセクションに記載した制約を満たし得るかどうかを判断するようオファーされるコーデックの最大数とを判断すればよい。端末は、参加することができる場合、選択されたコーデックで応答すればよい。

別の実施形態では、他の参加端末(たとえば、端末110Bおよび110C)も、それらの並列コーデック能力を応答メッセージ中に含めることができる。これにより、開始者端末は、同じ開始者端末によって開始されるどの将来の会議のためにも、端末の能力が適切に検討されることを記憶し、保証することができる。いくつかの態様において、開始者端末は、データベースに能力を記憶し得る。

参加端末は、参加することができないと判断した場合、そのことを応答メッセージ中で示し、その並列コーデック能力を送る。開始者端末は次いで、他の参加端末からの応答を、次のように処理すればよく、すなわち、(1)開始者端末は、否定的応答を受信しなかった場合、会議を続けさせ、(2)開始者端末は、否定的応答を受信した場合、すべての受信された並列コーデック能力を使って、実現可能なオファーメッセージを構築し、それらを新規メッセージ(たとえば、SIP Re-INVITE/UPDATEメッセージ)中で、参加者の一部または全員に送信する。

いくつかの実施形態では、各端末は、端末の各々についての並列コーデック能力プロファイルを、そのアドレス帳またはデータベースに記憶することができる。このプロファイルは、各端末の各データタイプについてのMaxEncおよびMaxDecを含み得る。他の態様では、このプロファイルは、すべてのデータタイプについての端末のコーデックのリストを、リソース割振り係数またはコーデックの各インスタンスによって使われるプロセッサ複雑性の割合とともに含み得る。たとえば、以下のTable 7(表7)は、すべてのデータタイプについての端末のコーデックの例示的なリストを、コーデックの各インスタンスによって使われるプロセッサ複雑性の割合とともに示す。

いくつかの態様において、開始者端末は次いで、参加者の各々の上記プロファイルを使って、本明細書に記載する制約検討事項を使う各参加者によって満たすことができるオファーメッセージを判断することができる。

それらの並列コーデック能力を通信する際、端末は、特定のデータタイプのデータストリームを優先し、無視することが可能であるので、より多くのデータストリームの受信を扱うことができることを示してもよい。たとえば、端末110Aは、最大3つのEVSデータストリーム(各々が、そのプロセッサの20%を使う)を並列に復号することができ、その後は受信されたどの追加データストリームも無視することを示し得る。

いくつかの態様において、端末は、実現可能なオファーメッセージが第1の開始メッセージ(たとえば、第1のSIP INVITE)中に含まれることをより良好に保証するために、会議が開始される前に、並列コーデック能力情報を交換することもできる。並列コーデック能力情報のこの交換は、次のように実施されてよく、すなわち、ユーザが自分のアドレス帳または端末上のディレクトリに別のユーザを追加すると、アドレス帳アプリケーションは、並列コーデック能力ならびにどの他の個人情報(自宅住所など)も、または端末のコーデック能力が変化したとき(端末ハードウェアのダウンロードもしくはスワップにより)を交換するために、互いに連絡を取る。情報/プロファイルのこの交換は、ユーザの間でどの連絡先情報識別子(ID)が提供されても、それを使って実施することができよう。たとえば、IDがeメールアドレスである場合はeメール交換における埋め込みプロファイル多目的インターネットメール拡張(MIME)タイプにより、IDが電話番号である場合はショートメッセージサービス(SMS)を介して送られる拡張マークアップ言語(XML)スキーマにより、何らかの他のメッセージ通信プロトコルを介して送られるXMLスキーマにより、である。プロファイル情報は、様々なやり方で更新され得る。たとえば、ユーザは、端末内混合を用いて会議を確立するために、互いに、または前に記載したプロトコルにより、電話をかけ、すなわち、並列コーデック能力が応答中で送られ得る。別の例では、プロファイルを記憶する端末は、能力が変わったかどうかを見るために、他のユーザの端末を自律的および定期的に(たとえば、毎月)遡ってチェックするようにタイマを設定してよい。これらの能力は、ユーザによるソフトウェア更新もしくはダウンロード、またはユーザのハンドセットを変更したことにより、変わる場合がある。いくつかの態様において、プロファイルを提供した端末は、それ自体の能力が変わったときはいつでも、そのアドレス帳中のユーザ全員を更新してよい。代替として、会議への2人以上の参加者(開始者ではない)が、自分たちの間でデータセッションをセットアップするとき、自分たちの並列コーデック能力を交換し得る。

いくつかの態様において、OPTIONSリクエストは、別の端末に、その端末がそのコーデック能力を記述することをオファーするはずのセッション記述プロトコル(SDP)のコピーを送るよう依頼することによって、その端末のコーデック能力を照会するのに使うことができる。このSDPは、上述した並列コーデック能力情報を含むことになる。OPTIONSリクエストは、会議通話の十分事前に行われてよく、SDP応答は、被照会端末についてのプロファイル中に記憶され得る。いくつかの実施形態では、会議をセットアップする直前に、会議開始者は、開始者が情報を事前記憶させていない、開始者が勧誘することを計画する端末すべてのコーデック能力を照会すればよいであろう。

図6は、会議におけるコーデック交渉のための別の例示的な方法のフローチャートである。図10に示す方法600は、会議アーキテクチャ100、200、300、および/または400における1つまたは複数のデバイスにより実装され得る。いくつかの態様において、方法は、図1〜図4のユーザ端末110A〜Dおよび/もしくは集中型プロセッサ125と同様のデバイス、またはどの他の適したデバイスによっても実装され得る。

ブロック605において、端末またはプロセッサは、2つ以上のデバイスにリクエストメッセージを送信することができ、リクエストメッセージは、2つ以上のデバイスの各々によってサポートされるコーデック能力のリストをリクエストする。メッセージは、端末またはプロセッサによってサポートされるコーデック能力のリストの指示を含み得る。いくつかの態様において、メッセージは、開始者端末の、またはプロセッサの並列コーデック能力に基づき得る。いくつかの実施形態では、メッセージは、前もってそれらの並列能力が知られている他の参加者のコーデック能力にも基づき得る。

ブロック610において、端末は、2つ以上のデバイスの各々から応答メッセージを受信し、応答メッセージは、2つ以上のデバイスの各々によってサポートされるコーデック能力のリストの指示を含む。いくつかの態様において、応答を受信した後、端末またはプロセッサは、受信されたメッセージを処理して、数人の参加者のコーデック能力の示されるリストを判断することができる。

いくつかの実施形態では、SDPパラメータは、コンパクトCCC SPDオファーおよび回答を使って、マルチストリームマルチパーティ会議開催メディアハンドリング(MMCMH)セッション確立において同様に削減され得る。本明細書に記載するコンパクトCCC SDPパラメータのABNF定義は、MMCMHセッション確立のためのコンパクトCCCExおよびCCCの両方に当てはまり得る。ただし、CCCが単一SDP行に圧縮されるために許可されるCCCEx用にコンパクトCCCを使う間、MMCMHセッション開始のためにコンパクトCCCを使うことは、SDPオファーがSDPオファー/回答モデルまたは期待に準拠する必要によって制限され得る。たとえば、MMCMHセッション確立において、SDPオファーは、端末(たとえば、オファー側端末および回答側端末)によってサポートされるコーデック構成のどの組合せもSDP回答に選択させるための十分なメディア行を含み得る。たとえば、オファーには少なくともR個のメディア行があるはずであり、Rは、オファー側端末が並列に受信し、復号し得る最大数ストリームである。

MMCMHセッション確立のためのコンパクトCCC SDPオファーパラメータが、本明細書において証明されるように実施され得る。いくつかの実装形態では、3つのオーディオコーデック(AMR-NB、AMR-WB、およびEVS)が、オファー側端末(たとえば、MMCMHセッションを作成しようとする端末)によって利用可能であり得る。「A」は並列AMR-NBコーデックの最大数に対応し、「B」は並列AMR-WBコーデックの最大数に対応し、「C」は並列EVSコーデックの最大数に対応し、ここで、それらの相対複雑性により、A>=B>=Cである。したがって、オファーメッセージを生成するとき、オファー側端末は、A個のメディア行の合計を列挙することができ、A個のメディア行の各々は、AMR-NPをコーデックとして含む。同様に、オファー側端末は、B個のメディア行の合計を列挙することができ、ここでB個のメディア行は、AMR-WB、すなわちAMR-NBをもつ受信されたサイマルキャストをコーデックとして含むことになる。さらに、オファー側端末は、コーデックとしてのEVS、すなわちAMR-WBとAMR-NBの両方をもつ受信されたサイマルキャストを含むことになるC個のメディア行の合計を列挙することができる。オファー側端末の送付/符号化能力を示すとき、上記メディア行のうちの1つまたは複数は、サイマルキャスト送付構成におけるコーデックすべても含み得る。

上記A個のメディア行は、SDP回答において選択され得るであろうすべての可能メディア構成をカバーし得る。1つまたは複数の受容可能構成を選択するオファーに応答するために、回答側端末は、オファーにも含まれるコンパクトCCC SDP行に依拠しながら、その回答を通信すればよい。

本明細書に記載するように、コンパクトCCC SDP行を使用しないSDPオファーは、ほぼ同じ情報を通信するために、メディア行の以下のセットを含み得る。
・最大数の復号可能ストリームがサポートされるときの構成を示す「A」個のメディア行。これは、サイマルキャスト受信構成において、2つのコーデックをもつ少なくともB個のメディア行および3つのコーデックをもつC個のメディア行があることを除いて、コンパクトCCCを使うことに対応し得る。これらの追加コーデックの各々は、メディア行中にもう2つのSDP行を追加することになる。
・異なる数の並列に復号されるストリームおよびそのようなストリームのセットをサポートし得る各構成用のメディア行のセット。

たとえば、オファー側端末が、単一のEVSデコーダをサポートする場合、オファー側端末は、オファーメッセージ中で、AMR-NBストリームの最大数をAからA_1EVSに削減する。さらに、オファーメッセージは、多くのAMR-NBコーデックを列挙するメディア行と、EVSコーデックを含む1行とを受信するA_1EVS+1の別個のセットを含み得る。さらに、コンパクトCCC SDP行を使わないとき、メディア行のセットの各々は、MediaCapNegフレームワークにおいて指定される異なるメディア構成を要求する。

コンパクトCCC SDPパラメータが使われないときに通信され得る構成の異なるセットの例が、以下の表に示されている。表は、N=6に対して3つの構成(A、B、およびC)を含む。ただし、Nという異なる値に対して構成の異なるセットがあってよく、Nは、オファー側端末およびすべての回答側端末を含む、会議への参加者の数である。

ただし、オファーおよび返答メッセージとともにコンパクトCCC SDPパラメータを実装することによって、A個のメディア行とは別にいかなる構成も列挙することは回避することができ、したがって、MediaCapNegフレームワークの使用が回避され得る。MMCMHセッション確立とともにコンパクトCCC SDPパラメータを実装することによって節約されるSDP行の量は、コーデックの各々の間の相対的複雑性に依存し得る。相対的複雑性がより変化すると、非コンパクトCCC SDPパラメータオファーにおいて必要とされるメディア行のセットがより多くなるが、それは、あるコーデックインスタンスを別のコーデックインスタンスのために代用することは、並列デコーダの数に対して、より大きな影響を有し得るからである。

たとえば、コーデックCがコーデックBの2倍複雑であると仮定するが、コーデックBはコーデックAの2倍複雑であり、コーデックAは、稼働され得る最も単純なコーデックのインスタンスの最大数を表す。オファーメッセージ用にコンパクトCCC SDPパラメータを使うとき、SDPオファーメッセージ中には、以下の数のSDP行を含むA個のメディア行の1つのセットだけが存在する。
・共通SDP側面用に7行
・コーデックAを含むA個のメディア行の各々に2行
・コーデックBを含むB個のメディア行の各々に2行
・コーデックCを含むC個のメディア行の各々に2行
・コンパクトCCC SDPパラメータ用に1行
したがって、SDPオファーメッセージ用に合計で8+2A+2B+2C=8+2A+A+0.5A=8+3.5AのSDP行がある。

ただし、オファーメッセージ用にコンパクトCCC SDPパラメータを使わないとき、メディア行の以下のセットがあり得る。

上記パターンを拡張すると、コンパクトCCC SDPパラメータを使わないとき、可能構成をすべて示すのに必要とされるSDP行の総数は、A(1+2+3+...A/4)×(2A+m_i)であることがわかり、ここでm_iは、Aに依存しない、メディア行の特定のセットについての定数である。最低でも、上記に対する下限は、少なくとも0.25A⁴+A³というメディア行の数である。

したがって、SDPオファーにおいてコンパクトCCC SDPフォーマットを使うことの利得は、SDPオファー中のSDP行の数を、約(0.25A⁴+A³)/(3.5A+8)≒=0.0714A³+0.286A²という係数だけ削減する。

したがって、A=4の場合、5.81という圧縮利得係数があり、A=8の場合、42.67という圧縮利得係数があり、A=16の場合、320という圧縮利得係数がある。このことは、SDPオファーのサイズを低減する際の圧縮利得が、特に、異なる計算複雑性の多数の並列コーデックをサポートする能力を有するオファー側端末にとって大幅であり得ることを例証する。

いくつかの実施形態では、本明細書に記載するような、SDPオファー中のメディア行の数を圧縮するためのコンパクトCCC SDPパラメータの使用は、回答者端末がコンパクトCCC SDPオファー中に記述されるメディア構成すべてがサポートされるわけではないことを知るように、回答者端末がコンパクトCCC SDPパラメータを理解するように構成されることを要求し得る。回答者端末は、コンパクトCCC SDPパラメータを理解しない場合、オファー側端末によってサポートされない並列コーデックのセットを不適切に選択する場合がある。

したがって、オファー側がA個のメディア行の単一のメディア構成とともにコンパクトCCC SDPパラメータを使うときはいつでも、オファー側端末は、回答者端末がコンパクトCCC SDPパラメータを適切に理解できることを知っていてよい。たとえば、オファー側端末は、いずれかの方法(たとえば、OPTIONメソッド)を使って、回答者端末のCCCを前に照会し、コンパクトCCC SDPパラメータを含む応答を受信したことがある場合があり、このパラメータを、オファー側端末は、回答者端末がコンパクトCCCフォーマットを理解するとともに、MMCMHセッションを開始するときにこのフォーマットを使うことができることを記録するための根拠として使う。代替として、オファー側端末は、コンパクトCCCフォーマットを理解しない回答者端末が、サポートされない構成を選択するのを防止してよい。たとえば、オファー側端末は、これを、SIP INVITEのRequireヘッダ中に、本体中のコンパクトCCC SDPパラメータとともに投入されるCCC用の新規タグを定義することによって遂行することができる。回答者端末は、CCCタグを理解する場合、それに従ってINVITEに応答する。回答者端末は、CCCタグを理解しない場合、INVITEを拒絶し、オファー側端末は、CCCおよび関連付けられたメディア行構成すべてをもつ、より冗長なオファーなしで再INVITEを送らなければならない。

いくつかの実施形態では、コンパクトCCC SDPオファーパラメータは、オファー側端末によって1つまたは複数の回答者端末に送信され得る。コンパクトCCC SDPオファーパラメータは、オファー側端末によってサポートされる1つまたは複数のCCCを含み得る。オファー側端末は次いで、1つまたは複数の回答者端末のうちの少なくとも1つから応答を受信し得る。応答は、少なくとも1つの回答者端末によってもサポートされる、オファー側端末によってサポートされるCCCのうちの1つの、選択を含み得る。その応答に基づいて、オファー側端末は、少なくとも1つの回答者端末にデータストリームを送信し得る。

図7は、会議セッションを開始するためにコンパクト並行コーデックを使うための例示的な方法700のフローチャートである。図7に示す方法700は、会議アーキテクチャ100、200、300、および/または400における1つまたは複数のデバイスにより実装され得る。いくつかの態様において、方法700は、図1〜図4のユーザ端末110A〜Dおよび/もしくは集中型プロセッサ125と同様のデバイス、またはどの他の適したデバイスによっても実装され得る。

ブロック705において、端末またはプロセッサが、会議を確立するためのオファーメッセージを1つまたは複数のデバイスに送信し得る。オファーメッセージは、会議によってサポートされる並列コーデック能力のリストの指示を含み得る。いくつかの態様において、メッセージは、開始者端末の、またはプロセッサの並列コーデック能力に基づき得る。いくつかの実施形態では、メッセージは、前もってそれらの並列能力が知られている他の参加者のコーデック能力にも基づき得る。

ブロック710において、端末は、1つまたは複数のデバイスから返答メッセージを受信する。返答メッセージは、並列コーデック能力のリストの指示からの選択を含み得る。

ブロック715において、端末は、返答メッセージに基づいて、1つまたは複数のデバイスにデータストリームを選択的に送信する。

図8は、会議セッションを開始するためにコンパクト並行コーデックを使うための例示的な方法800の別のフローチャートである。図8に示す方法800は、会議アーキテクチャ100、200、300、および/または400における1つまたは複数のデバイスにより実装され得る。いくつかの態様において、方法800は、図1〜図4のユーザ端末110A〜Dおよび/もしくは集中型プロセッサ125と同様のデバイス、またはどの他の適したデバイスによっても実装され得る。

ブロック805において、第1のデバイスの端末またはプロセッサは、第2のデバイスへの送信用の第1のメッセージを生成し得る。第1のメッセージは、オファーメッセージまたはリクエストメッセージを含み得る。第1のメッセージは、端末もしくはプロセッサによってサポートされる並列コーデック能力のリストの指示を含むか、または第2のデバイスによってサポートされる並列コーデック能力のリストの指示をリクエストし得る。いくつかの実施形態では、第1のメッセージは、第2のデバイスへの送信用に第1のメッセージを生成するための手段によって生成され得る。いくつかの実施形態では、第1のメッセージを生成するための手段は、会議アーキテクチャ100、200、300、および/または400における1つまたは複数のデバイスを備え得る。いくつかの態様において、第1のメッセージを生成するための手段は、図1〜図4のユーザ端末110A〜Dおよび/もしくは集中型プロセッサ125と同様のデバイス、またはどの他の適したデバイスによっても実装され得る。

ブロック810において、端末は、端末と第2のデバイスとの間で会議を確立するための第2のメッセージを受信する。第2のメッセージは、第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストを含み得る。第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストは、第1の列挙されるコーデックの1つまたは複数の並列インスタンスに使用可能な1つまたは複数のリソースが、第2の列挙されるコーデックの1つまたは複数の並列インスタンス用に代わりに使われ得るかどうかの指示を含み得る。いくつかの実施形態では、第2のメッセージは、端末と第2のデバイスとの間で会議を確立するために、第2のメッセージを受信するための手段によって受信され得る。いくつかの実施形態では、第2のメッセージを受信するための手段は、会議アーキテクチャ100、200、300、および/または400における1つまたは複数のデバイスを備え得る。いくつかの態様において、第1のメッセージを生成するための手段は、図1〜図4のユーザ端末110A〜Dおよび/もしくは集中型プロセッサ125と同様のデバイス、またはどの他の適したデバイスによっても実装され得る。

いくつかの実施形態では、第2のメッセージは、オファーメッセージに応答して第2のデバイスによって送信される応答メッセージを含み得る。いくつかの実施形態では、第2のメッセージは、返答メッセージを含み得る。

上記で説明した方法の様々な動作は、様々なハードウェアおよび/もしくはソフトウェア構成要素、回路、ならびに/またはモジュールなど、動作を実施することができる任意の適切な手段によって実施されてよい。一般に、図に示すどの動作も、その動作を実施することが可能な対応する機能的手段によって実施され得る。たとえば、2つ以上のデバイスにオファーメッセージを送信するための手段は、端末110A〜Dの送信機またはアンテナを備え得る。さらに、応答メッセージを受信するための手段は、端末110A〜Dの受信機またはアンテナを備え得る。さらに、2つ以上のデバイスが会議に参加し続けることができるかどうかを判断するための手段は、ユーザ端末110A〜Dのプロセッサを備え得る。さらに、デバイスからオファーメッセージを受信するための手段は、端末110A〜Dの受信機またはアンテナを備え得る。また、応答メッセージを送信するための手段は、端末110A〜Dの送信機またはアンテナを備え得る。

情報および信号は、様々な異なる技術および技法のうちのいずれかを使用して表される場合がある。たとえば、上の説明全体に渡って参照される場合があるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、磁波、磁場もしくは磁気粒子、光場もしくは光粒子、またはそれらの任意の組合せによって表される場合がある。

本明細書で開示する実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装される場合がある。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップについて、概してそれらの機能性に関して上記で説明した。そのような機能性がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定の用途およびシステム全体に課される設計の制約によって決まる。説明された機能性は特定の適用例ごとに様々な方法で実装できるが、そのような実装の決定は、本発明の実施形態の範囲からの逸脱を生じるものと解釈されるべきではない。

本明細書で開示する実施形態に関して説明する様々な例示的なブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または、本明細書で説明する機能を実施するように設計されたそれらの任意の組合せで、実装または実施されてよい。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であってよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。

本明細書において開示されている実施形態に関連して説明されている方法またはアルゴリズムのステップおよび機能は、ハードウェアの中、プロセッサによって実行されるソフトウェアモジュールの中、またはその2つの組合せの中で直接具体化することができる。ソフトウェアとして実装される場合、機能は、1つまたは複数の命令またはコードとして有形の非一時的コンピュータ可読媒体上に記憶され、または送信され得る。ソフトウェアモジュールは、ランダムアクセスメモリ(RAM)、フラッシュメモリ、読取り専用メモリ(ROM)、電気的プログラマブルROM(EPROM)、電気的消去可能プログラマブルROM(EEPROM)、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体内に存在する場合がある。記憶媒体は、プロセッサが情報を記憶媒体から読み取り、記憶媒体に情報を書き込むことができるようにプロセッサに結合される。代替として、記憶媒体は、プロセッサに一体化され得る。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲の中に含まれるべきである。プロセッサおよび記憶媒体は、ASIC内に存在し得る。

本開示を要約するために、本明細書において、本発明のいくつかの態様、利点、および新規の特徴が説明されてきた。必ずしも本発明の何らかの特定の実施形態に従ってすべてのそのような利点を達成することができるわけではないことを理解されたい。したがって、本発明は、本明細書において教示または示唆され得る他の利点を必ずしも達成することなく、本明細書において教示された1つの利点または利点のグループを達成し、または最適化する方法で具現化または実施することができる。

上述の実施形態への様々な修正が容易に明らかになり、本明細書に定義する一般原理は、本発明の趣旨または範囲を逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書に示された実施形態に限定されることを意図したものではなく、本明細書に開示された原理および新規の特徴に一致する最も広い範囲を与えられるものである。

100 会議アーキテクチャ
110 端末
125 集中型プロセッサ
200 非集中型会議アーキテクチャ
300 非集中型会議アーキテクチャ
400 ハイブリッド会議アーキテクチャ、会議アーキテクチャ
450 端末/メディアゲートウェイ、端末/ゲートウェイ
500 会議アーキテクチャ、ハイブリッド会議アーキテクチャ

Claims

複数のパーティの間で通信するための方法であって、
第1のデバイスにおいて、第2のデバイスへの送信用の第1のメッセージを生成するステップと、
前記第1のデバイスにおいて、会議を確立するための第2のメッセージを受信するステップであって、前記第2のメッセージは、前記第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストを含み、前記第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力の前記リストは、第1の列挙されるコーデックの1つまたは複数の並列インスタンス用に使用可能な1つまたは複数のリソースが、第2の列挙されるコーデックの1つまたは複数の並列インスタンス用に代わりに使われ得るかどうかを示す指示を含む、ステップとを含む方法。
前記指示は、前記第1の列挙されるコーデックの前記1つまたは複数の並列インスタンス用に使用可能な前記1つまたは複数のリソースが、前記第2の列挙されるコーデックの前記1つまたは複数の並列インスタンス用に使われ得ることを示し、前記指示が、任意で前記第1および第2の列挙されるコーデックを分離する「,」を含む、請求項1に記載の方法。
前記指示は、前記第1の列挙されるコーデックの前記1つまたは複数の並列インスタンス用に使用可能な前記1つまたは複数のリソースが、前記第2の列挙されるコーデックの前記1つまたは複数の並列インスタンス用に使われ得ないことを示し、前記指示が、任意で前記第1および第2の列挙されるコーデックを分離する「;」を含む、請求項1に記載の方法。
前記第1および第2の列挙されるコーデックは、セッション記述プロトコル(SDP)フォーマットで提示される、請求項1に記載の方法。
前記リスト中の前記1つまたは複数の並列コーデック能力は、計算複雑性によって順序付けられる、請求項1に記載の方法。
前記第2の列挙されるコーデックは、前記第1の列挙されるコーデックよりも計算が複雑でなく、前記第2の列挙されるコーデックは、SDPフォーマットで、前記第1の列挙されるコーデックの後に列挙される、請求項5に記載の方法。
前記第1のメッセージは前記第2のデバイスへのリクエストメッセージであり、前記リクエストメッセージは、前記第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力の前記リストをリクエストし、前記第2のメッセージは前記第2のデバイスからの応答メッセージであり、前記応答メッセージは、前記第2のデバイスによってサポートされる1つまたは複数の並列コーデック能力の前記リストを含む、請求項1に記載の方法。
複数のコーデックを利用するマルチパーティ、マルチストリーム会議を開始するための装置であって、
第1のデバイスへの送信用の第1のメッセージを生成するための手段と、
会議を確立するための第2のメッセージを前記第1のデバイスから受信するための手段であって、前記第2のメッセージは、前記第1のデバイスによってサポートされる1つまたは複数の並列コーデック能力のリストを含み、前記第1のデバイスによってサポートされる1つまたは複数の並列コーデック能力の前記リストは、第1の列挙されるコーデックの1つまたは複数の並列インスタンス用に使用可能な1つまたは複数のリソースが、第2の列挙されるコーデックの1つまたは複数の並列インスタンス用に代わりに使われ得るかどうかを示す指示を含む、手段とを備える装置。
前記指示は、前記第1の列挙されるコーデックの前記1つまたは複数の並列インスタンス用に使用可能な前記1つまたは複数のリソースが、前記第2の列挙されるコーデックの前記1つまたは複数の並列インスタンス用に使われ得ることを示し、前記指示が、任意で前記第1および第2の列挙されるコーデックを分離する「,」を含む、請求項8に記載の装置。
前記指示は、前記第1の列挙されるコーデックの前記1つまたは複数の並列インスタンス用に使用可能な前記1つまたは複数のリソースが、前記第2の列挙されるコーデックの前記1つまたは複数の並列インスタンス用に使われ得ないことを示し、前記指示が、任意で前記第1および第2の列挙されるコーデックを分離する「;」を含む、請求項8に記載の装置。
前記第1および第2の列挙されるコーデックは、セッション記述プロトコル(SDP)フォーマットで提示される、請求項8に記載の装置。
前記リスト中の前記1つまたは複数の並列コーデック能力は、計算複雑性によって順序付けられる、請求項8に記載の装置。
前記第2の列挙されるコーデックは、前記第1の列挙されるコーデックよりも計算が複雑でなく、前記第2の列挙されるコーデックは、SDPフォーマットで、前記第1の列挙されるコーデックの後に列挙される、請求項12に記載の装置。
前記第1のメッセージは前記第1のデバイスへのリクエストメッセージであり、前記リクエストメッセージは、前記第1のデバイスによってサポートされる1つまたは複数の並列コーデック能力の前記リストをリクエストし、前記第2のメッセージは前記第1のデバイスからの応答メッセージであり、前記応答メッセージは、前記第1のデバイスによってサポートされる1つまたは複数の並列コーデック能力の前記リストを含む、請求項12に記載の装置。
命令を備えるコンピュータ可読記録媒体であって、前記命令は、実行されると、プロセッサに、請求項1から7のいずれか一項に記載の方法を実行させる、コンピュータ可読記録媒体。