JP5588527B2 - マルチホップｒｔｐストリーミングにおいて重要なパケットロスを扱うためのシステム及び方法 - Google Patents

Description

この発明は、ビデオ通信に関し、特にマルチポイント（多地点）ビデオ会議の分野に関する。

この特許出願は、２０１２年２月１０日に出願された「マルチホップＲＴＰストリーミングにおいて重要なパケットロスを扱うためのシステム及び方法」と題された米国特許出願番号第６１／５９７５２４号に対する優先権を要求するものであり、これの出願に記載された全ての記載内容を援用するものである。

ビデオ会議（videoconferencing）は、互いに遠隔に位置する各個人が対面式の会合を行うことを可能にするものである。ビデオ会議は、音声及びビデオの遠距離通信を用いて実行されるだろう。ビデオ会議は、２つのサイト（ポイント・ツー・ポイント（point to point））のような少数の間で行われるか、或いは、多数のサイト（マルチポイント（multi‐point））の間で行われるだろう。１つの会議サイトは、単一の参加者（ユーザ、会議出席者）又は多数の参加者（複数のユーザ、複数の会議参加者）を含むだろう。また、ビデオ会議は、ドキュメント、プレゼンテーション及び情報などを、共有するのが常である。

参加者は、例えばビデオ会議エンドポイント（ＥＰ）経由で、ビデオ会議に参加する。エンドポイント（ＥＰ）は、例えば端末又はネットワークであろう。エンドポイントは、他の端末及び／又はマルチポイント制御ユニット（ＭＣＵ）と、リアルタイムで双方向の音声／映像／データ通信が、可能である。或るエンドポイント（ＥＰ）は、音声、音声及びビデオ、データ、音声及びビデオなどを含む種々の形式で、情報／データを供給する。“端末”、“サイト”及び“エンドポイント”の各用語は互換的に使用されている。本開示においては、エンドポイントという用語は、上位概念を表す用語として使用されている。

エンドポイントは表示ユニット（スクリーン）を備え、表示ユニット上には１以上の遠隔地点からのビデオ画像が表示されるだろう。エンドポイントは、例えば、ＰＯＬＹＣＯＭ（登録商標）、ＶＳＸ（登録商標）、及び、ＨＤＸ（登録商標）であり、それぞれ、ポリコム社から入手できる（ＰＯＬＹＣＯＭ（登録商標）、ＶＳＸ（登録商標）、及び、ＨＤＸ（登録商標）は、ポリコム社の登録商標である）。ビデオ会議エンドポイントは、音声、ビデオ及び／又はデータを、ローカルサイトから、１以上の遠隔サイトに送信し、また、そのスクリーン（表示ユニット）上に、１又は複数の遠隔サイトから受信したビデオ及び／又はデータを表示するだろう。

エンドポイントにおいてスクリーン上に表示されたビデオ画像は、アレンジ（整理）されたレイアウトで表示されるだろう。レイアウトは、ビデオ画像を表示するための１以上のセグメント（部分、区画）を含むだろう。１つのセグメントは、受信エンドポイントのスクリーンの予め定義された一部分であり、ビデオ会議セッションに参加しているサイトの１つから受信されたビデオ画像に配分さるだろう。２参加者間のビデオ会議においては、１つのセグメントは、各エンドポイントの各スクリーンのディスプレイ領域全体を覆うだろう。

或るローカルサイトと多数の遠隔サイトとの間のビデオ会議におけるビデオ表示モードの一例は、スイッチングモードであろう。スイッチングモードとは、複数の遠隔サイトのうちの１つから送られたビデオ／データだけが、ローカルサイトのスクリーン上に同時に表示されるモードである。表示されたビデオは、会議の変遷に応じて、別のサイトから受信されたビデオに切り替えられるだろう。

前記スイッチングモードとは対照的に、常駐表示（continuous presence（ＣＰ）；画面分割）においては、ローカルエンドポイントの会議参加者（参加者）は、当該ビデオ会議に参加している種々のエンドポイントの他の個々の参加者を、同時に観察するだろう。各サイトは、ローカルスクリーン上に表示されたレイアウト中の異なるセグメントに表示されるだろう。複数のセグメントは、同じサイズであってもよいし、或いは、異なるサイズであってもよい。スクリーンに表示される複数のサイトの組み合わせ、及び、レイアウトのセグメントに対するそれらサイトの関連付けは、同じセッションに参加している種々のサイトの間で異なっていてよい。更に、常駐表示レイアウトにおいて、或るサイトから受信したビデオ画像は、拡張又は縮小調整される、及び／又は、それが配分されたセグメントのサイズに適合するようにトリミングされてよい。なお、“会議参加者”、“ユーザ”、及び“参加者”との用語は、互換的に使用されている。本開示において、用語“会議参加者”は、上位概念を表す用語として使用されるだろう。

ＭＣＵは、ビデオ会議を管理するために使用される。ＭＣＵは、会議制御エンティティ（entity；実体、構成要素）であり、典型的には、エンドポイントからの様々なチャンネルを受信するネットワークのノード又は端末に設置されており、何らかの基準（抽出条件）に従って音声及び／又は音声信号を処理し、そして、それらを１組の接続されたチャンネルに分配する。

複数のＭＣＵは、例えば、ポリコム社から入手できるＭＧＣ‐１００及びＲＭＸ２０００（登録商標）を含む（ＲＭＸ２０００（登録商標）は、ポリコム社の登録商標である）。いくつかのＭＣＵは、２つの論理的ユニットから構成されるだろう：メディア制御装置（media controller ; ＭＣ）と、メディア処理装置（media processor ; ＭＰ）とである。エンドポイント及びＭＣＵのより詳細な定義は、Ｈ．３２０、Ｈ３２４及びＨ．３２３を含む国際電気通信（ＩＴＵ）規格に見つかるだろう。例えばＩＴＵ規格又はセッション イニシエーションプロトコル（ＳＩＰ）などのビデオ会議規格及びプロトコルに関する更なる情報は、それぞれ、ＩＴＵのウェブサイトwww.itu.int、又は、インターネット技術タスクフォース（Internet Engineering Task Force；ＩＥＴＦ）のウェブサイトwww.ietf.orgに見つかるだろう。

別のビデオ会議システムでは、メディア中継会議システム（ＭＲＣ）を使用するだろう。ＭＲＣにおいて、メディア中継ＭＣＵ（ＭＲＭ）は、参加している各メディア中継エンドポイント（ＭＲＥ）から、１以上のストリームを受信する。ＭＲＭは、会議内の他の複数のエンドポイントから受信された１組の複数ビデオストリームを、各参加エンドポイントに中継する。各受信エンドポイントは、複数のストリームを使用して、レイアウトに従うＣＰビデオ画像を生成する。ＣＰビデオ画像は、ＭＲＥのユーザに提示される。１つのＭＲＥは、当該セッション内の会議参加者の端末になり得、この端末は、或る１つのＭＲＭから中継されたメディアを受信し、或る１つのＭＲＭからの指示に従い圧縮されたメディアを送出できる。複数のＭＲＭは、米国特許公開公報第２０１０／０１９４８４７号により詳細に記載されており、これの出願に記載された全ての記載内容を援用する。本開示においては、用語“エンドポイント”と“ＭＲＥ”は互換的に使用されるだろう。

いくつかのＭＲＣシステムにおいて、送信ＭＲＥは、２以上の品質のレイヤ乃至レベルで、自身のビデオ映像を送信する。いくつかのシステムにおいて、前記２以上のレイヤは、単一のストリームによって搬送される。別のＭＲＣシステムにおいては、各レイヤは異なるストリームに関連付けられる。これらのシステムは、レイアウト内での種々のウィンドウサイズ、各受信エンドポイントにより使用される種々の解像度、種々のフレームレートなどを提供できる。更に、複数のレイヤは、パケットロス（パケット損失）を克服するために使用され得る。品質は、フレームレート、解像度、及び／又は、信号対ノイズ比（Ｓ／Ｎ比；ＳＮＲ）などに関して異なる。

本開示を通じて、ビデオストリーミングとの用語は、マルチメディア会議セッション、メディアストリームリーミング、又は、圧縮マルチメディアストリームの伝送を用いた任意の実用例における、任意の圧縮メディア（例えば音声、及び／又は、ビデオ）の送信を表しており、該メディアはスケーラブル符号化エンコーダ（scalable coding encoder）により圧縮されたものである。更に、送信された圧縮メディアは、メディアの品質に関して互いに異なるレイヤからなり複数のレイヤを含むだろう。複数の異なるレイヤは、開示された実施形態によって様々に扱われるだろう。また、用語“スケーラブル符号化（ＳＣ）”は、本開示においては、マルチレイヤメディア符号化の一例を表す。

ビデオストリームリーミングはますます一般的になっている。更に、ビデオ会議システムと同様に、ますます多くのビデオストリーミング源が複数のレイヤを送出するようになっており、これらレイヤは圧縮ビデオの品質によって互いに異なっている。品質は、例えば時間ドメイン（例えばフレーム毎秒）、空間ドメイン（例えば高精細度（ＨＤ）、又は、ＣＩＦ（Common Intermediate Format））、及び／又は、品質（例えば鮮鋭度（シャープネス））などのように、多数のドメイン（定義域）で表現される。ビデオストリームリーミング及び多品質（マルチクオリティ）レイヤで使用されるビデオ圧縮規格は、Ｈ．２６４ＡＶＣ、Ｈ．２６４ａｎｎｅｘＧ、ＭＰＥＧ‐４などを含む。Ｈ．２６４などのこれら圧縮規格は、ＩＴＵのウェブサイトwww.itu.int、又は、www.mpeg.orgに見つかるだろう。

いくつかのビデオ圧縮技術は、イントラフレームとインターフレームとの２種のフレームを用いる。イントラフレームは、同じフレーム内にのみ含まれ且つ当該ビデオシークエンス内の他のどのフレームにも関連付けられていない情報に関連して圧縮されたビデオフレームである。インターフレームは、同じフレーム内に含まれ且つ当該ビデオシークエンス内の他の１以上のフレーム（参照フレーム）にも関連付けられている情報に関連して圧縮されたビデオフレームである。インターフレームは、Ｐフレーム（予測フレーム）、及び／又は、Ｂフレーム（双方向予測フレーム）を含み得る。ビデオ会議において、複数のＢフレームは、それがもたらすレイテンシのため、一般的に使用されるのではない。以下の説明では。インターフレームは、用語“Ｐフレーム”を表す用語として使用される。

インターネットプロトコル（ＩＰ）ネットワークによって搬送される共通のビデオ会議セッションのメディア（例えば音声及びビデオ）は、該メディアのパケットの転送プロトコルとして、リアルタイム転送プロトコル（ＲＴＰ）を使用する。ＲＴＰプロトコルは、リアルタイムデータ転送制御プロトコル（ＲＴＣＰ）と合わせて使用される。ＲＴＣＰは、送信の統計とサービス品質（ＱｏＳ）とをモニタするために使用され、多数のストリームの同期を助ける。更に、ＲＴＰパケットは、ＵＤＰ／ＩＰにより搬送される。ＵＤＰ／ＩＰが無接続方式のプロトコルであり、信頼性に欠きパケットロス（パケット損失）を被るものであることは、当該技術において周知である。パケットロスを識別するための方法の１つとして、ビデオ会議ストリームのソースにおいて、共通のＲＴＰ処理装置が、メディアパケットの１つ１つに、それらを各宛先に送信する前に、シーケンス番号を加える。

圧縮ビデオストリームの宛先において、ＲＴＰ処理装置は、それらのシーケンス番号に従って受信したパケットをソート（整列）して、該圧縮ビデオストリームを関連するデコーダに送出する。接続両端のＲＴＰ処理装置は、パケットロスを克服するために、種々の前方誤り訂正技術を使用するだろう。更に、接続両端のビデオエンコーダ／デコーダは、パケットロスを克服するために、種々の回復方法を使用する。更に別の回復方法は、１以上の欠損パケットの再送信要求を含み得、この再送信要求はストリームのソースへ送信されるものである。

例えばビデオ会議などのリアルタイム通信において、再送信は、イントラフレームをエンコードすることと、そのビデオ画像を提示している全てのエンドポイントへ該イントラフレームを送信することとを含むだろう。しかし、再送信されたフレームは、それらエンドポイントの中の１つによって要求されたものである。イントラフレームを送信することによりネットワーク上での帯域幅消費量が増加してしまうとともに、フレームレートの一時的な低下のためにユーザエクスペリエンス（ユーザ体験）が低減してしまう。

パケットロス（パケット損失）は、典型的には複数のメディアホップ（media‐hop）を用いるセッションにおいて、より頻繁に起こる。１つのメディアホップは、２以上のエンドポイントの間の中間のノードである。例えば、１つのメディアホップは、例えばＭＣＵ、ＭＲＭ、メディアゲートウェイなどであり得る。本開示においては、用語“ＭＣＵ”、“ＭＲＭ”、“メディアゲートウェイ”及び“メディアホップ”は、文脈に応じて互換的に使用できる。複数のメディアホップが伴われるセッションにおいては、経路上のどのセグメントでも複数のパケットが欠損し得る。したがって、１番目のホップへの途中で失われたパケットは、２番目のホップにより要求されるだけでなく、当該ストリームの宛先の端末を含む１以上の次のホップにより要求され得る。このような場合、複数の再送信されたパケットによって生じた複数の不必要な再送信要求は、ネットワーク及び接続両端におけるエンドポイントに負荷をかけるだろう。

本開示の一実施形態に係る装置及びシステムの一例は、ビデオ会議セッションの参加者の体験（ユーザエクスペリエンス）を高めると同時に、セッションによる帯域消費量を軽減するものである。メディアストリーミングシステムにおいては様々な方法が使用され得、該システムにおいてメディア圧縮技術が複数のスケーラブル（scalable）レイヤを送出する。例えば、本開示に係る技術は、ビデオ会議セッションにおいて実行され、ビデオ会議セッションにおいて、ビデオ圧縮はＳＣ形式に基づく。ＳＣ形式圧縮規格の一例は、一般にＳＶＣと称されるＨ．２６４ａｎｎｅｘＧであり得る。ＳＣ形式において、種々の複数のレイヤは、レイヤ間の従属性のために異なるレベルの重要性を持つ。例えば時間的スケーラビリティにおいて、３つのレイヤ（Ｔ０，Ｔ１及びＴ２）が使用されているとすると、図１Ａに説明するように、各レイヤは異なるフレームレートに関連付けられている。図１ＡにおいてＸ軸は、ＲＴＰストリームにおけるフレームを表しており、そのフレームは３０フレーム毎秒（Ｆ／ｓ）のフレームレートを用いてＳＣ形式でエンコードされたものである。３０Ｆ／ｓで圧縮されたビデオを送出するために、圧縮ストリームは、宛先へ送信される３つのレイヤにより構成される。

第１のレイヤはベースレイヤ（ＢＬ）である。ＢＬは、時間的スケーラビリティを表して「Ｔ０」と呼ばれる。ＢＬ（Ｔ０）は、７．５Ｆ／ｓで圧縮された圧縮フレームからなり、各フレームは、同じレイヤＢＬ（Ｔ０）の先行するフレームをエンコードしている間に生成された参照フレームに基づいて圧縮される。従って、このレイヤＢＬ（Ｔ０）の第２フレームであるフレーム♯５は、このレイヤの第１フレーム（フレーム♯１）をエンコードしている間に作成された参照フレームに基づいて圧縮される。このように、このレイヤＢＬ（Ｔ０）の第３フレームであるフレーム♯９は、このレイヤの第２フレーム（フレーム♯５）をエンコードしている間に作成された参照フレームに基づいて圧縮され、以下同様に続く。

第２のレイヤは第１のエンハンスレイヤ（ＥＬ１）である。ＥＬ１は、時間的スケーラビリティを表して「Ｔ１」と呼ばれる。ＥＬ１（Ｔ１）は、７．５Ｆ／ｓで圧縮され、第１レイヤＢＬ（Ｔ０）から２フレーム分シフトした圧縮フレームからなる。各フレームは、第１レイヤＢＬ（Ｔ０）の先行するフレームをエンコードしている間に生成された参照フレームに基づいて圧縮される。従って、レイヤＥＬ１（Ｔ１）の第１フレームであるフレーム♯３は、第１レイヤＢＬ（Ｔ０）の第１フレーム（フレーム♯１）に基づいて圧縮される。レイヤＥＬ１（Ｔ１）の第２フレームであるフレーム♯７は、レイヤＢＬ（Ｔ０）の第２フレーム（フレーム♯５）に基づいて圧縮される。従って、フレームのレイヤＢＬ１（Ｔ０）とＥＬ１（Ｔ１）からなるストリームは、１５Ｆ／ｓのフレームレートで、デコード及び提示できる。

第３のレイヤは第２のエンハンスレイヤ（ＥＬ２）である。第３のレイヤは、時間的スケーラビリティを表して「Ｔ２」と呼ばれる。ＥＬ２（Ｔ２）は、１５Ｆ／ｓで圧縮されており、このレイヤの第１フレームであるフレーム♯２は、ＢＬ（Ｔ０）の第１フレームであるフレーム♯１と、ＥＬ１（Ｔ１）の第１フレームであるフレーム♯３との間にある。ＥＬ２（Ｔ２）の各奇数フレームは、第１レイヤＢＬ（Ｔ０）の先行するフレームをエンコードしている間に生成された参照フレームに基づいて圧縮される。ＥＬ２（Ｔ２）の各偶数フレームは、第２レイヤＥＬ１（Ｔ１）の先行するフレームをエンコードしている間に生成された参照フレームに基づいて圧縮される。したがって、レイヤＥＬ２（Ｔ２）の第１フレームであるフレーム♯２は、ＢＬ（Ｔ０）の第１フレームであるフレーム♯１に基づいて圧縮される。レイヤＥＬ２（Ｔ２）の第２フレームであるフレーム♯４は、ＥＬ１（Ｔ１）の第１フレーム（フレーム♯３）に基づいて圧縮され、以下同様に続く。従って、フレームのレイヤＢＬ１（Ｔ０）、ＥＬ１（Ｔ１）及びＥＬ２（Ｔ２）からなるストリームは、３０Ｆ／ｓのフレームレートで、デコード及び提示できる。

上記の異なる複数のレイヤを圧縮する方法に基づいて、レイヤ間の優先度が割り当てられる。ベースレイヤＢＬ（Ｔ０）のフレーム群は、最も重要なフレームであり、最も高い優先度を持ち得る。他の２つのレイヤＥｌ１及びＥＬ２（時間的スケーラビリティで表すとＴ１及びＴ２）それぞれのフレーム群のデコードは、先行するＢＬ（Ｔ０）のフレームに依存するからである。ＥＬ１（Ｔ１）のフレーム群は重要度が少なく、ＥＬ２（Ｔ２）のフレーム群のデコードのみが、ＥＬ１（Ｔ１）のフレームに基づく。同様に、ＥＬ２（Ｔ２）のフレーム群はＥＬ１（Ｔ１）のフレーム群よりも重要度が少ない。ＥＬ２（Ｔ２）フレームの圧縮データを搬送するパケット例えばフレーム♯８の欠損（損失）は、ＢＬ（Ｔ０）に属する次のフレーム♯９を受信するまでの短い期間（〜３０ミリ秒）、提示される画像の品質を低下させる。しかし、ＢＬ（Ｔ０）のフレーム♯１３のデータを搬送するパケットが欠損した場合には、永続的にアーティファクト（画像の乱れ）が生じてしまい、パケット欠損から回復するためにはイントラフレームが必要となる。

一例に係る実施形態は、ＳＣ形式の圧縮データを搬送するパケットのＲＴＰヘッダーを、拡張ヘッダーを含むように変更する。拡張ヘッダーは、そのパケットにより搬送される圧縮ビデオの優先度を示す領域を含む。この領域は、ＰｒＩＤ領域とよばれ、Ｐｒ０が最も高い優先度を示す。いくつかの実施形態において、送信エンドポイント（圧縮ストリームのソース）は、優先度レベルを定義できる。いくつかの実施形態において、優先度レベルはセッションの最中に変更され得る。優先度レベルを変更することは、例えば再送信要求の頻度に依存し得る。ベースレイヤＢＬ（Ｔ０）の圧縮ビデオデータを搬送するパケットは、最も高い優先度Ｐｒ０で示される。ＥＬ２（Ｔ２）の圧縮ビデオデータを搬送するパケットは、最も低い優先度Ｐｒ２で示される。少数の再送信要求しか受信されないセッションにおいては、送信エンドポイントは、Ｔ０及びＴ１のレイヤの両方を最も高い優先度Ｐｒ０で評価するだろう。更に、ソースから宛先への経路中のメディアホップは、より低い優先度を持つＲＴＰパケットは欠落させ、より高い優先度を持つＲＴＰパケットを伝送するようになっていてもよい。メディアホップは、例えば、メディアＧＷ、ＭＣＵ、ＭＲＭ、ブリッジなどであり得る。

更に、ＳＣ形式のＲＴＰパケットの宛先において、ＲＴＰ処理装置は、より低い優先度を持つパケットの欠損に対しては、高い優先度を持つパケットの欠損とは別様に応答するようになっていてもよい。

別の実施形態において、例えば、ＲＴＰの拡張ヘッダーは、更に、シーケンス番号に関連付けできる新しい領域を含んでよい。第１シーケンス番号は、Ｐｒ０のフレームの圧縮データを搬送する各ＲＴＰパケット毎に、ストリームのソースによって増加され得る。この領域の値は、ＲＴＰパケットのソースから受信エンドポイントまでの全工程で不変である。このシーケンス番号は、オリジナルＰｒ０シーケンス番号（ＯＰｒ０ＳＮ）と呼ばれる。このＯＰｒ０ＳＮにより、ＳＣ形式のストリームの宛先のデコーダに接続されたＲＴＰ処理装置は、欠損したＰｒ０パケットを識別できる。例えばＢＬ（Ｔ０）パケットなど重要なパケットの欠損が発覚した場合、１つのＩフレーム（イントラフレーム）の要求が成され得る。

第２シーケンス番号は、ホップＰｒ０シーケンス番号（ＨＰｒ０ＳＮ）と呼ばれる。ＨＰｒ０ＳＮは、そのストリームの経路中の各メディアホップによって置換される。ＨＰｒ０ＳＮにより、次のホップに接続されたＲＴＰ処理装置は、そのＲＴＰ処理装置に先行する最後のセグメントで損失されたＰｒ０パケットを識別できる。この領域は、或るホップから次のホップへ移る毎に、変化する。各ホップは別のシーケンスカウンタを使用できるので、ＨＰｒ０ＳＮの値は或る１つのホップと別のホップとで劇的に異なり得る。各ホップは、そのシーケンス番号、すなわちＨＰｒ０ＳＮの値を、送信又は再送信された各Ｐｒ０パケット毎に増加する。

加えて、各ホップのＲＴＰ処理装置は、この領域を調べる（チェックする）。例えばＢＬ（Ｔ０）パケットなどの重要なパケット（Ｐｒ０）の欠損が次のＲＴＰ受信部により発見された場合、ＲＴＣＰ再送信要求を用いて、ＲＴＰ受信部からその送信元に再送信要求を送信できる。欠損した重要なパケット（Ｐｒ０）を識別し且つ欠損した重要なパケットの再送信を要求するために、ＨＰｒ０ＳＮ領域を使用することにより、優先度の低い欠損パケットの再送信要求のオーバヘッドトラフィック（通信料の余計な負荷）を効果的に除去できる。更に、各ホップは、送信された重要なパケットの一時記憶装置を処理するように構成されることで、イーグレス（egress、出口）と次のＲＴＰ受信部との間で生じた重要なパケット（Ｐｒ０）のための再送信要求に対して、ローカルで応答できるようになる。一時メモリの一例は、送信されたＰｒ０パケットの最後の数十から数百を記憶できる。メモリの一例は、ランダムアクセスメモリ（ＲＡＭ）であり、そのアドレスビットは、ＨＰｒ０ＳＮの末尾の数ビット（例えば６，８又は１０ビット）であり得る。

更に、別の実施形態において、ＨＰｒ０ＳＮは、全レイヤのパケットを計数するために使用され得る。かかる実施形態において、次のホップのＲＴＣＰは、先行するホップからのセグメントに欠損パケットが生じる限りずっと、それら欠損パケットのレイヤに関わらず再送信を要求することにより、パケット欠損に対して応答するだろう。

第３シーケンス番号は、オリジナルシーケンス番号（ＯＳＮ）と呼ばれ得る。ＯＳＮは、圧縮ストリームのソースにより制御され、全てのホップを通じて不変であり続けるだろう。ＯＳＮは、各送信されたパケット毎に、そのパケットの優先度に関わらずに、且つ、そのパケットにより搬送されるスケーラブルレイヤに関わらずに、増加される。このＯＳＮにより、圧縮ＳＣ形式ストリームがデコードされるストリーム宛先のＲＴＰ処理装置は、ビデオデコーダに複数のパケットを送信するよりも前に、それら複数のパケットを編成（順番付け）できる。

本開示に係る実施形態は、時間的スケーラビリティに関連付けられているが、本開示は時間的スケーラビリティに限定されず、例えば空間的スケーラビリティなど、他の種類のスケーラビリティにも実装できることを、当業者は理解するだろう。

本開示に係るシステムの実施形態は、欠損パケットの再送信を、高い優先度のパケット（Ｐｒ０）のみに制限している。したがって、開示されたシステム及び方法によれば、帯域幅消費量を軽減でき、且つ、イントラフレームの再送信要求を軽減でき、会議参加者の体験（ユーザエクスペリエンス）を向上できる。

これら本開示の態様、及び、その他の態様は、添付の図面と詳細な説明を参照することにより、明白になるだろう。前述の概要は、本開示の可能な各実施形態又は全ての様相を要約することを意図しておらず、また、本開示の他の特徴及び利点は、以下に述べる添付図面を参照した実施形態の詳細な説明と特許請求の範囲とを読むことにより、明らかになるだろう。

更に、実施形態の具体例は、当業者に本発明の概念を説明するために詳細に記載されているが、かかる実施形態は、種々の変更及び別の形態が可能である。したがって、図面と明細書は、いずれにせよ、本発明の概念の範囲を制限することを意図してはいない。

本開示の１以上の実施形態に従う、時間的スケーラビリティの３つのレイヤを用いた３０Ｆ／ｓの圧縮ビデオストリームの可能なＳＣ形式の構造の一例を示す模式図。

一例に係る実施形態に従う、多種の電子ビデオ会議システムを備えたマルチメディア会議システム１００を説明する図。

一例に係る実施形態に従う、送信エンドポイントのＲＴＰ処理装置例に関連する要素を示すロック図。

一例に係る実施形態に従う、受信エンドポイントのＲＴＰ処理装置例に関連する要素を示すブロック図。

一実施形態に係る中間メディアホップに従い、中間メディアホップの送信ＲＴＰ処理装置の一実施形態に関連する要素を示すブロック図。

一実施形態に係る中間メディアホップに従い、中間メディアホップの受信ＲＴＰ処理装置の一実施形態に関連する要素を示すブロック図。

一実施形態に係る送信ＥＰ‐ＲＴＰ処理装置の送信タスクに関連するブロックのフローチャート。

圧縮されたＳＣ形式のストリームの宛先エンドポイントのＲＴＰ処理装置の受信部により実装され得る受信方法に関連するブロックのフローチャート。 圧縮されたＳＣ形式のストリームの宛先エンドポイントのＲＴＰ処理装置の受信部により実装され得る受信方法に関連するブロックのフローチャート。

圧縮されたＳＣ形式のストリームを受信している間に宛先エンドポイントのＲＴＰ処理装置の受信部により実装され得る受信方法に関連するブロックのフローチャート。

圧縮されたＳＣ形式のストリームを送信している間に中間メディアホップのＲＴＰ処理装置の一例により実装され得る方法例に関連するブロックのフローチャート。

次に図面に移ると、図面において同様な番号は同様な要素を表しており、種々の図を通じて本開示の種々の実施形態が描かれている。便宜上、同じグループの幾つかの要素のみが番号付けされる。図面の目的は、種々の実施形態を説明することであり、設計・製造の目的ではない。従って、図面に示された特徴は、説明の便宜とわかりやすさのためにのみ、選択されたものである。更に、本開示で使用される言葉は、原則的に、読みやすさと教示の目的とで選択されたものであり、発明の主題を境界付ける又は制限するために選ばれているのではない。かかる発明の主題を定義するためには、特許請求範囲の参照を必要とする。

明細書における“一実施形態”又は“或る実施形態”とは、その実施形態に関連して説明された個別の特徴、構造又は特質がこの発明の少なくとも１つの実施形態に含まれていることを意味しており、“一実施形態”又は“或る実施形態”に対する複数の言及は、必ずしも、同じ実施形態への言及の全と、理解すべきではない。

以下の説明の幾つは、ソフトウェア又はファームウェアに関連する用語で記述されるが、複数の実施形態は、ここで記述された特徴及び機能を、ソフトウェア、ファームウェア又はハードウェア、或いは、ソフトウェア、ファームウェア及びハードウェアの任意の組み合わせで実装するだろう。以下の説明において、“ユニット”、“エレメント”、“モジュール”及び“論理モジュール”は互換的に使用されるだろう。ユニット又はモジュールとして示されたものは何でも、スタンドアローンニット、又は、専用の若しくは統合されたモジュールであってよい。ユニット又はモジュールは、モジュラーであるか又はモジュラーの態様を持ち、取り外し及び別の同種のユニットモジュールへの取替えを簡単に行えるものである。各ユニット又はモジュールは、ソフトウェア、ハードウェア、及び／又は、ファームウェアのどれか１つ、又は、その任意の組み合わせであってよく、最終的に、ユニット又はモジュールに与えられた機能を実行するようにプログラムされた１以上の処理装置（processor: プロセッサ）となる。加えて、同種の又は異なる種の複数のモジュールが、単一の処理装置により実装されてよい。論理モジュールのソフトウェアは、例えば読み書き可能なハードディスク、ＣＤＲＯＭ、フラッシュメモリ、ＲＯＭ、又は、その他のメモリ若しくはストレージなど、コンピュータ読み取り可能な媒体に記録されてよい。何らかのタスクを実行するために、ソフトウェアプログラムは、必要に応じて適宜の処理装置にロードされる。本開示において、用語“タスク”、“方法”、“処理”は互換的に使用できる。

図１Ａは、時間的スケーラビリティの３つのレイヤを用いた３０Ｆ／ｓのＳＣ形式圧縮ビデオストリームに属する圧縮フレーム間の関係を説明している。前述した図１Ａの説明を参照されたい。

図１Ｂは、本開示の一実施形態に従う、マルチメディア会議システム１００を示す。システム１００は、ネットワーク１１０、１以上のマルチメディア中継ＭＣＵ（ＭＲＭ）１２０及び複数のメディア中継エンドポイント（ＭＲＥ１３０）を含む。別の実施形態に係るシステム１００において、ＭＲＭ１２０はマルチポイント制御ユニット（ＭＣＵ）であり得、複数のＭＲＥ１３０はビデオ会議エンドポイント（ＥＰ）であり得る。ネットワーク１１０は、任意のパケット交換ネットワーク、ＩＰネットワーク、又は、それらの任意の組み合わせであり得る。セッション管理通信は、例えばＨ．３２３及びＳＩＰなどのプロトコルに基づいて行われ、メディア送信プロトコルは、ＲＴＣＰと組み合わせたＲＴＰに基づいて行われ、例えば音声（オーディオ）圧縮規格Ｇ．７１１及びＧ．７１９、及び／又は、Ｈ．２６４ＡＶＣ、Ｈ．２６４ａｎｎｅｘ、ＭＰＥＧ‐４などのビデオストリーミング及び多品質ストリーミングのために使用されるビデオ圧縮規格を、使用するだろう。

各ＥＰ又はＭＲＥ１３０は、他のエンドポイント１３０又はＭＣＵ１２０に、リアルタイムの双方向音声及び／又は映像通信を提供できる。或るＥＰ１３０は、セッションにおいて会議参加者の端末になり、ＭＣＵから圧縮されたメディアを受信でき、且つ、ＭＣＵからの指示に従い圧縮された音声及びビデオを送出できる。ビデオ会議するエンドポイントとＭＣＵとで共通の動作は、当業者にとって周知であり、ここでは更なる詳述はしない。

ＭＲＥ１３０は、例えば、ＭＲＭへ１以上の圧縮ビデオストリームを送出し、且つ、ＭＲＭ１２０から１以上の選択された圧縮ビデオストリームを受信するだろう。該ＭＲＥは、該受信された１以上の圧縮ビデオストリームをデコード（復号）し、デコードされたビデオストリームからＭＲＥ１３０のスクリーン上に表示されるビデオ画像を構成するだろう。ＭＲＭ１２０は、メディア中継ＭＣＵであり、複数のＭＲＥ１３０から複数の圧縮ビデオストリームを受信し、１以上の圧縮ビデオストリームのセットを選択し、その１以上の圧縮ビデオストリームのセットを複数のＭＲＥ１３０に中継する。複数のＭＲＥ１３０は、メディア中継会議（ＭＲＣ）セッションに参加している。ＭＲＥ，ＭＲＭ及びＭＲＣについてもっと学びたい読者には、米国特許出願公開番号２０１０／０１９４８４７号公報を読むことを勧め、その内容を本開示に援用する。

前述したような、ＥＰ又はＭＲＥ１３０の共通動作の一例に加えて、ＥＰ／ＭＲＥ１３０は、２種類のＲＴＰ処理装置を含むように構成できる。第１の種類のＲＴＰ処理装置は、送信エンドポイントＲＴＰ処理装置（ＴＥＲＴＰ）と呼ばれ得る。各ＴＥＲＴＰは、ビデオストリームのエンコーダ（図示せず）と該エンドポイントのネットワークインタフェースカード（図示せず）との間に、通信可能に接続され得る。或る実施形態に係るＴＥＲＰは、圧縮ビデオストリーム・ネットワーク・アブストラクション・レイヤ（ＮＡＬ）データユニットを取得でき、ＮＡＬユニットを集めてＲＴＰパケットにでき、そして、ネットワークインタフェースへの該ＲＴＰパケットの伝送より優先的に、該ＲＴＰパケットに拡張ＲＴＰヘッダーを付加できる。並行して、最も優先度の高いレイヤ（Ｐｒ０）の圧縮ビデオを搬送するＲＴＰパケットは、一時メモリに記憶され得る。記憶されたパケットは、送信エンドポイントと次のメディアホップの間でＰｒ０パケットが欠損（すなわちパケットロス）した際の再送信用に使用され得る。

拡張ＲＴＰヘッダーは、共通ＲＴＰヘッダーの領域を含み得る。例えばシーケンス番号（ＳＮ）、タイムスタンプなどの領域。更に、拡張ＲＴＰヘッダーは、本開示の技術の一実施形態により使用される追加的な４つの領域の拡張を含み得る。そのうちの１つの領域は、ＰｒＩＤと呼ばれ、ＲＴＰパケットにより搬送された圧縮ビデオレイヤの優先度レベルを示す。別の１つの領域は、シーケンス番号に割り当てられ、オリジナルシーケンス番号（ＯＳＮ）と呼ばれる。ＯＳＮは、全ての中間メディアホップを通じて不変である。ＯＳＮは、その優先度とは関係なく、最初のパケット送信に対して、ＴＥＲＰによって増加される。このＯＳＮにより、圧縮ＳＣ形式ストリームがデコードされるストリーム宛先のＲＴＰ処理装置は、ビデオデコーダ（図示せず）に複数のパケットを伝送する前に、それら複数のパケットを編成（順番付け）できる。

更に別の領域は、別の新たなシーケンス番号に割り当てられる。このシーケンス番号は、重要なフレーム（Ｐｒ０のフレーム）の圧縮データを搬送する各ＲＴＰパケット毎に、増加され得る。この領域の値は、ソースＥＰのＴＥＲＰからＲＴＰパケットの受信エンドポイントまでの全経路で、不変であり続ける。このシーケンス番号は、オリジナルＰｒ０シーケンス番号（ＯＰｒ０ＳＮ）と呼ばれる。ＯＰｒ０ＳＮは、初めて送信された各重要な（Ｐｒ０）ＲＴＰパケットに対して、増加される。ＯＰｒ０ＳＮにより、ＳＣ形式ストリームの宛先のデコーダ（図示せず）に接続されたＲＴＰ処理装置は、欠損したＰｒ０パケットを識別できる。例えばＢＬ（Ｔ０）パケットなど重要なパケットの欠損が発覚した場合、１つのイントラフレーム（Ｉフレーム）の要求が成され得る。

４つ目の領域は、ホップＰｒ０シーケンス番号（ＨＰｒ０ＳＮ）と称されるシーケンス番号に割り当てられる。ＨＰｒ０ＳＮは、ストリームの経路中の各メディアホップによって置換され得る。ＨＰｒ０ＳＮにより、次のメディアホップにおいてＲＴＰ処理装置は、そのセグメントで損失されたＰｒ０パケットを識別できる。ＨＰｒ０ＳＮの値は、欠損した１以上の重要なパケットの再送信要求のために、該次のメディアホップにより使用され得る。ＴＥＲＰの実施形態についての詳細は、ＦＩＧ２Ａ及びＦＩＧ４と併せて後述される。

第２の種類のＲＴＰ処理装置は、受信エンドポイントＲＴＰ処理装置（ＲＥＲＰ）と呼ばれる。ＲＥＲＰの一例は、エンドポイントのネットワークインタフェースカード（図示せず）と、該エンドポイントのビデオストリームのデコーダ（図示せず）の間に、通信可能に接続され得る。一実施形態に係るＲＥＲＰは、圧縮ビデオストリームＮＡＬデータユニットを搬送するＲＴＰパケットのストリームを取得できる。一実施形態に係るＲＥＲＰは、拡張ＲＴＰヘッダーを解析できる。ＨＰｒ０ＳＮの値に基づいて、前記ＲＥＲＰは、最終メディアホップと受信ＥＰの間にあるネットワークセグメントの最後で、重要なパケットが失われたかどうかを決定できる。重要なパケットが失われている場合、最終メディアホップに、再送信要求が送信され得る。

ＲＥＲＰは、拡張ＲＴＰヘッダーのＯＳＮ領域に従って、受信されたＲＴＰパケットを編成（順番付け）でき、ＯＰｒ０ＳＮは、重要なパケットが欠損したかどうかを決定するためにチェックされて、重要なパケットが失われている場合には、１つのイントラフレームの要求が、当該ストリームのソースであるエンコーダ（図示せず）に送信される。編成されたＲＴＰパケットは解析され、そして圧縮ＮＡＬデータユニットとして扱われる。圧縮ＮＡＬデータユニットは、デコーダ（図示せず）へ伝送され得る。拡張ＲＴＰヘッダーを処理できるようにしたＭＲＥ１３０の一例は、ＭＲＭ１２０から中継された圧縮ビデオストリーム毎に１つずつ、複数のＲＥＲＰを含む。一実施形態に係るＴＥＲＰについての詳細は、ＦＩＧ２Ｂ及びＦＩＧ５Ａ‐５Ｂと併せて後述される。

本開示に従い構成されたＭＣＵの一実施形態は、複数のＲＥＲＰモジュールと複数のＴＥＲＰモジュールを具備する。各ＲＥＲＰモジュールは、或るエンドポイントに割り当てられたネットワークインタフェースカード（図示せず）とデコーダを含む入力ポート（図示せず）との間に、通信可能に接続され得る。入力ポートも、そのエンドポイントに割り当てられる。各ＲＥＲＰは、上述したＥＰのＲＥＲＰユニットのタスクと同様なタスクを実行できる。入力ポートのデコーダによりデコードされたビデオは、出力ポートへ伝送され得る。出力ポートは、複数の入力ポートからデコードされたビデオを取得し、該デコードされたビデオを調整（scale；スケール）し、そして、ＣＰ（常駐表示、画面分割）ビデオ画像を作成できる。ＣＰビデオ画像は、出力ポート（図示せず）のＳＣ形式ビデオエンコーダにより圧縮され得る。

各出力ポートからの圧縮ＣＰビデオ画像のＮＡＬデータユニットは、ＴＥＲＰモジュールに伝送され得る。このＴＥＲＰモジュールは、出力ポートとして共通の受信ＥＰに割り当てられており、且つ、同じＥＰに割り当てられたネットワークインタフェースカード（図示せず）に通信可能に接続される。各ＴＥＲＰは、上述したＥＰのＴＥＲＰユニットのタスクと同様なタスクを実行できる。

本開示に従い構成されたＭＲＭ１２０の一実施形態は、１以上の中間メディアホップ受信ＲＴＰ処理装置（ＩＭＨＲＲＰ）及び１以上の１以上の中間メディアホップ送信ＲＴＰ処理装置（ＩＭＨＴＲＰ）を具備できる。各ＩＭＨＲＲＰは、１つのＭＲＥ１３０から受信された圧縮ＳＣ形式ビデオのストリームに割り当てられており、且つ、１以上の他のＭＲＥ１３０に中継される。共通ＲＴＰ処理装置の数多のタスクの中で、一実施形態に係るＩＭＨＲＲＰは、割り当てられたＭＲＥ１３０から圧縮ＳＣ形式ビデオのＲＴＰパケットを取得して、拡張ＲＴＰヘッダーを解析する。ＨＰｒ０ＳＮ領域に基づいて、重要なパケットが最後のセグメントで損失したかどうかを決定することができる。重要なパケットを損失した場合、ＩＭＨＲＲＰは、ＨＰｒ０ＳＮに基づいて、先行のメディアホップに再送信要求を送信できる。一実施形態に係るＩＭＨＴＲＰは、拡張ヘッダーのＰｒＩＤ領域を調べ得る。該ＰｒＩＤ領域がＰｒ０の場合、ＩＭＨＴＲＰは、そのＨＰｒ０ＳＮを増加して、当該ＩＭＨＴＲＰのＨＰｒ０ＳＮカウンタの新しい値に、ＲＴＰヘッダー内のＨＰｒ０ＳＮの値を置換する。該ＰｒＩＤ領域の値がＰｒ０でない場合、ＨＰｒ０ＳＮカウンタは増加されず、拡張ＲＴＰヘッダーのＨＰｒ０ＳＮ領域には、直前の値がロードされる。ＳＮ値は、新しいものに置換され得、ＲＴＰパケットは１以上のＭＲＥ１３０へ伝送され得る。最も優先度の高いレイヤ（Ｐｒ０）の圧縮ビデオを搬送するＲＴＰパケットは、一時メモリに記憶され得る。記憶されたパケットは、ＭＲＭ１２０と次のメディアホップ又はＭＲＥの間でＰｒ０パケットが欠損した場合の再送信要求に使用され得る。ＭＲＭ１２０の詳細情報は、ＦＩＧ３Ａ，３Ｂ、６及び７と併せて後述される。

図２Ａは、一実施形態に係る送信ＥＰの送信エンドポイントＲＴＰ処理装置（ＴＥＲＰ）２００に関連する要素のブロック図を例示する。ＥＰは、或るＭＣＵからＣＰビデオ画像を受信する共通のビデオ会議エンドポイント、または、自身によりＣＰビデオ画像を作成するＭＲＥであり得る。数多の要素のうち、ＭＲＥの要素は、１以上のＴＥＲＰ２００を含み得る。各ＴＥＲＰ２００は、ＭＲＥ（図示せず）のエンコーダに関連付けられ得る。一実施形態に係るＴＥＲＰ２００は、ＮＡＬ累算部２１０、ＲＴＰヘッダー作成部２１５、送信バッファ２２０、再送信Ｐｒ０バッファ（ＲｅＸ‐Ｐｒ０バッファ）２２５、送信ＲＴＰ管理部２３０及び４つのシーケンスカウンタ２３５ａ〜２３５ｄを具備してよい。関連するＥＰがビデオ会議に参加したとき、各シーケンスカウンタは、例えばランダムに生成された数にセットされ得る。

１つのシーケンスカウンタ２３５ａは、共通のＲＴＰシーケンス番号をカウントでき、このカウンタは、最終ＳＮと呼ばれ、最初に又は再送信要求の受信に応じてエンドポイントから送信されるＲＴＰパケット毎に、増加される。最終ＳＮの値は、送信されたＲＴＰパケットのヘッダーのＳＮ領域に書き込まれ得る。別のシーケンスカウンタ２３５ｂは、関連するＥＰ（図示せず）の関連付けられたエンコーダにより圧縮されたオリジナルＲＴＰパケットをカウントできる。シーケンスカウンタ２３５ｂは、最終ＯＳＮと呼ばれ、最初にエンドポイントから送信されたオリジナルの（再送信されたものでない）ＲＴＰパケット毎に、増加される。最終ＯＳＮの値は、送信されたＲＴＰパケットの拡張ヘッダーのＯＳＮ領域に書き込まれ得る。更に別のシーケンスカウンタ２３５ｃは、Ｐｒ０フレームの圧縮データを搬送するオリジナルＲＴＰパケットをカウントできる。シーケンスカウンタ２３５ｃは、最終ＯＰｒ０ＳＮと呼ばれ、Ｐｒ０フレームの圧縮データを搬送しており且つ最初にエンドポイントから送信されたオリジナルの（再送信されたものでない）ＲＴＰパケット毎に、増加される。最終ＯＰｒ０ＳＮカウンタの値は、送信されたＲＴＰパケットの拡張ヘッダーのＯＰｒ０ＳＮ領域に書き込まれ得る。もう１つのシーケンスカウンタ２３５ｄは、Ｐｒ０フレームの圧縮データを搬送し且つそのＥＰから送信されたオリジナルＲＴＰパケットをカウントできる。このシーケンスカウンタ２３５ｄは、最終ＨＰｒ０ＳＮと呼ばれ、Ｐｒ０フレームの圧縮データを搬送しており且つエンドポイントから送信又は再送信されたオリジナル及び再送信されたＲＴＰパケット毎に、増加される。最終ＨＰｒ０ＳＮカウンタの値は、送信されたＲＴＰパケットの拡張ヘッダーのＨＰｒ０ＳＮ領域に書き込まれ得る。

一実施形態に係るＴＥＲＰ２００は、関連付けられたエンコーダ（図示せず）から圧縮されたＮＡＬユニットのストリームを受信するだろう。ＮＡＬユニットのストリームは、異なる優先度を持つ２以上のレベルの圧縮ＮＡＬユニットを搬送できる。取得されたＮＡＬユニットのストリームは、ＲＴＰパケットを完成させるためのＲＴＰプロトコルの条件を果たすまで、ＮＡＬ累算部２１０に集積され得る。１つのＲＴＰパケットのための条件の一例は、ＲＴＰパケットのペイロードとして搬送されるべきバイト数であり得る。別の条件は、ビデオフレームの末尾であり得る。更に別の条件は、他の優先度レベルを持つＮＡＬなどであり得る。かかる条件が生じるとき、集積された１以上のＮＡＬは、ヘッダー作成部２１５のキュー（待ち行列）に、１つのＲＴＰパケットのペイロードとして伝送され得る。

一実施形態に係るヘッダー作成部２１５において、パケットの共通ＲＴＰヘッダーは、パケットのペイロードに加えられ得る。共通ＲＴＰヘッダーの拡張領域は、拡張されたＲＴＰ領域の存在を示すようにセットされ得る。数多の領域のうち、共通ＲＴＰヘッダーは、タイプスタンプ領域に書き込まれた取込時刻を含む。次に、最終ＳＮカウンタ２３５ａは、ＲＴＰヘッダー内のＳＮ領域などにコピーされ得る。

共通ヘッダーに加えて、拡張ヘッダーの領域が追加され得る。圧縮データのスケーラブルレイヤが、エンコーダから受信され、パケットの優先度レベルが、Ｐｒ０，Ｐｒ１・・・などとして定義され得る。一実施形態において、パケットの優先度レベルは、受信された再送信要求の頻度に基づき得る。複数の再送信要求が受信された場合、圧縮されたフレームのベースレイヤを搬送するパケットのみが、Ｐｒ０と定義され得る。幾つかの再送信要求が受信された場合、ベースレイヤ及び第１エンハンスレイヤの圧縮レイヤを搬送するパケットが、Ｐｒ０と定義され得る。幾つかの実施形態において、優先度レベルは、再送信要求の頻度の機能として、会議セッション中に変更され得る。Ｐｒの値は、拡張ＲＴＰヘッダーのＰｒ領域に記憶され得る。

更に、３つのシーケンスカウンタ、最終ＯＳＮ、最終ＯＰｒ０ＳＮ、最終ＨＰｒ０ＳＮ（それぞれ２３５ｂ，２３５ｃ，２３５ｄ）の値は、それぞれＯＳＮ領域、ＯＰｒ０ＳＮ領域、ＨＰｒ０ＳＮ領域という、拡張ＲＴＰヘッダー内の適宜の領域に、コピーされ得る。作成されたＲＴＰパケットは、拡張ＲＴＰヘッダーを有しており、ヘッダー作成部２１５から、送信バッファ２２０を経て、ネットワークインタフェースカード（図示せず）へ伝送され得る。ここで、ネットワークインタフェースカードは、圧縮ビデオストリームに関連付けられている。並行して、重要なフレーム（Ｐｒ０）の圧縮ビデオデータを搬送するＲＴＰパケットは、ＲｅＸ‐Ｐｒ０バッファ２２５に記憶され得る。

ＲｅＸ‐Ｐｒ０バッファ２２５は、ＲＡＭ装置であり得、ＲｅＸ‐Ｐｒ０バッファ２２５の各アドレスは、拡張ＲＴＰヘッダーを持つＰｒ０圧縮ビデオのＲＴＰパケット全体を記憶できる。Ｐｒ０のＲＴＰパケットを記憶できるアドレスは、該パケットの拡張ＲＴＰヘッダーのＨＰｒ０ＳＮ領域の末尾数ビットを表し得る。末尾数ビットの数は、例えば、ＨＰｒ０ＳＮ領域の末尾の６〜１０ビットであり得る。

送信ＲＴＰ管理部２３０は、ＴＥＲＰ２００の全体処理を管理する。ＲＴＰ接続の初期化の間、送信ＲＴＰ管理部２３０は、４つのシーケンスカウンタ２３５ａ〜ｄを割り当て且つセットする。各シーケンスカウンタ２３５ａ〜ｄは、ランダムな数にセットされ得、送信されたＲＴＰパケットの特質に従い、増加される。幾つかの実施形態では、１以上のシーケンスカウンタは、或る一定の数にセットされ得る。たとえば、最終ＨＰｒ０ＳＮはゼロにセットされ得る。加えて、ＲＴＰ管理部は、ＲＴＰ接続を制御するために、ＲＴＰ接続の受信側のＲＴＰ管理モジュールと通信できる。ＲＴＰ接続の受信側のＲＴＰ管理モジュールとの通信は、ＲＴＣＰ通信プロトコルを用いて行うことができる。

会議セッション中、ＲＴＰ管理部２３０は、受信側のＲＴＰ管理部からＲＴＣＰ再送信要求を受信するだろう。再送信要求の一例は、再送信要求リスト（ＲｅＸＲｅｑリスト）を含む。ＲｅＸＲｅｑリストは、要求されたＰｒ０パケットのリストを含み得る。該リストは、欠損した重要なパケット（Ｐｒ０）のＨＰｒ０ＳＮ領域の値を含み得る。ＲｅＸＲｅｑリストに基づいて、ＲＴＰ管理部２３０は、同じＨＰｒ０ＳＮ値を持つパケットを求めて、ＲｅＸ‐Ｐｒ０バッファ２２５を検索するだろう。要求されたＰｒ０パケットがＲｅＸ‐Ｐｒ０バッファ２２５に記憶されている場合、これらパケットはＲｅＸ‐Ｐｒ０バッファ２２５から取り出されて、ヘッダー作成部２１５へ伝送され得る。

ヘッダー作成部２１５において、ＳＮ及びＨＰｒ０ＳＮの領域は、最終ＳＮカウンタ２３５ａ及び最終ＨＰｒ０ＳＮカウンタ２３５ｄの現在値に従い、更新され得る。拡張ＲＴＰヘッダーのＯＳＮ領域及びＯＰｒ０ＳＮ領域の値は、変更しないままである。そして、最終ＳＮカウンタ２３５ａ及び最終ＨＰｒ０ＳＮカウンタ２３５ｄは増加され得、要求されたパケットは送信バッファ２２０経由で再送信され得る。１以上の要求されたＰｒ０パケットがＲｅＸ‐Ｐｒ０バッファ２２５に存在しない場合、イントラ要求が、関連付けられたエンコーダ（図示せず）に、ＲＴＰ管理部２３０により送信され得る。なお、ＴＥＲＰ２００の動作についての更なる情報は、図４に併せて後述される。

次に図２Ｂを参照すると、一実施形態に係る受信ＥＰ‐ＲＴＰ処理装置（ＲＥＲＰ）２５０に関連する要素によりブロック図が示されている。受信ＥＰは、ＣＰ画像を作成するＭＣＵ又はＭＲＥから、ＣＰビデオ画像を受信する共通ビデオ会議エンドポイントであり得る。数多の要素のうち、一実施形態に係るＭＲＥは、１以上のＲＥＲＰ２５０を具備してよい。各ＲＥＲＰ２５０は、送信ＭＲＥから例えば直接又はＭＲＭ経由で受信している圧縮ストリームと、受信したストリームをデコードするためのデコーダ（図示せず）とに関連付けられ得る。一実施形態に係るＲＥＲＰ２５０は、ジッタバッファ２５５、編成ＯＳＮバッファ（ＯＯＳＮＢ）２６０、重要レイヤ確認部２６２、ＮＡＬバッファ２６５、ＲＴＰヘッダー解析部２７０及び受信ＲＴＰ管理部２７５を備えてよい。

一実施形態に係るＲＥＲＰ２５０は、関連するストリームに関連付けられたネットワークインタフェース（図示せず）から、圧縮ビデオＮＡＬデータユニットを搬送するＲＴＰパケットのストリームを取得するだろう。取得されたＲＴＰパケットは、ジッタバッファ２５５に記憶される。ヘッダー解析部２７０は、ジッタバッファ２５５に記憶されたＲＴＰパケットの拡張ＲＴＰヘッダーを解析するだろう。拡張領域ＰｒＩＤ及びＨＰｒ０ＳＮの値に基づいて、最後のメディアホップからの経路中で１以上の重要なパケットＰｒ０が失われたかどうかについて決定がなされる。ＨＰｒ０ＳＮ内にギャップ（隙間、空き）が検出された場合、１以上の欠損Ｐｒ０パケットの再送信要求用リストの要求が、受信ＲＴＰ管理部２７５経由で、送信ＥＰの送信ＲＴＰ管理部２３０（図２Ａ）へ送信され得る。

ジッタバッファ２５５の複数のＲＴＰパケットは、伝送され、それらのＯＳＮ拡張領域の値に基づいてＯＯＳＮＢ２６０に記憶され得る。一実施形態に係る重要レイヤ確認部２６２は、そのＯＳＮの値に基づいて、ＯＯＳＮＢ２６０の中から、次の１つのパケットを取得でき、拡張ＲＴＰヘッダーのＯＰｒ０ＳＮ領域の値が、重要なパケット（Ｐｒ０）が欠損したかどうかを決定するために、チェックされる。ＯＰｒ０ＳＮ内にギャップが検出された場合、イントラフレームの要求が、ＲＴＣＰ接続を用いて、受信ＲＴＰ管理部２７５経由で、送信ＥＰの関連付けられたエンコーダ（図示せず）へ送信される。取得されたＲＴＰパケットは、１以上のＮＡＬユニットに分解され、複数のＮＡＬユニットは、ＮＡＬバッファ２６５に記憶され得る。ＮＡＬユニットは、ＮＡＬバッファ２６５内に記憶されたＮＡＬユニットの順番に従い、図示外の関連付けられたデコーダに取得され得る。共通エンドポイントにおいて、関連付けられたデコーダは、受信した圧縮ＣＰビデオ画像をデコードでき、デコードされたＣＰビデオ画像は、当該ＥＰの表示ユニット上に表示され得る。ＭＲＥにおいて、関連付けられたデコーダからのデコードビデオ画像は、ＣＰ画像作成部（図示せず）へ伝送され、そこでＣＰビデオ画像の一区画に配置され、ＭＲＥ表示ユニットにおいて、ＣＰビデオ画像の一部として提示され得る。

受信ＲＴＰ管理部２７５は、ＲＥＲＰ２５０の処理全体を管理するだろう。ＲＴＰ接続の初期化の間、受信ＲＴＰ管理部２７５は、ＲＥＲＰ２５０のリソースに割り当てられ、セットされ得る。また、受信ＲＴＰ管理部２７５は、ＲＴＰ接続を制御するために、ＲＴＣＰ接続経由で、ＲＴＰ接続の送信側の送信ＲＴＰ管理モジュールと通信できる。送信側は、例えばＥＰ，ＭＲＥ，ＭＣＵ又はＭＲＭであり得る。

会議セッション中、受信ＲＴＰ管理部２７５は、送信側の送信ＲＴＰ管理部へ、ＲＴＣＰ再送信要求を送信するだろう。再送信要求の一例は、再送信要求リスト（ＲｅＸＲｅｑリスト）を含む。ＲｅＸＲｅｑリストは、要求されたＰｒ０パケットのリストを含み得る。該リストは、欠損した重要なパケット（Ｐｒ０）のＨＰｒ０ＳＮ領域の値を含み得る。更に、受信ＲＴＰ管理部２７５は、関連付けられたデコーダ（図示せず）へ圧縮ビデオを伝送する前に重要なパケットの欠損が検出された場合、イントラフレームの要求を送信できる。ＲＥＲＰ２５０の動作に関する更なる情報は、図５Ａ，５Ｂと併せて後述される。

ＭＣＵは、複数のＥＰからの複数の圧縮ビデオストリームを受信し；圧縮されたストリームをデコードし；１以上のＣＰビデオ画像を作成し；１以上のＣＰビデオ画像を圧縮して、複数のＥＰへ１以上の圧縮されたＣＰビデオ画像を送信するメディアホップの一例である。かかるＭＣＵは本開示の技術の一実施形態に従い適用され得る。一実施形態に係るＭＣＵは、複数のＲＥＲＰ２５０を具備する。各ＲＥＲＰ２５０は、或る１つのＥＰからの圧縮ビデオに関連付けられたネットワークインタフェースとデコーダの間に通信可能に設置される。また、一実施形態に係るＭＣＵは、複数のＴＥＲＰ２００を具備する。各ＴＥＲＰ２００は、１以上のＥＰへ送信される圧縮ビデオストリームに関連付けられたエンコーダとネットワークインタフェースの間に通信可能に設置される。

図３Ａは、一実施形態に係る中間メディアホップに従う、中間メディアホップ送信ＲＴＰ処理装置（ＩＭＨＴＲＰ）３００の一実施形態に関連する要素のブロック図を描いている。中間メディアホップは、複数のＭＲＥからの複数の圧縮ビデオストリーム、及び、複数のＭＲＥへの複数の圧縮ビデオストリームを、中継するＭＲＭである。数多の要素のうち、一実施形態に係るＭＲＭは、１以上のＩＭＨＴＲＰ３００を具備してよい。各ＩＭＨＴＲＰ３００は、ＭＲＭとＭＲＥの間のＲＴＰ接続に関連付けられ得る。一実施形態に係るＩＭＨＴＲＰ３００は、入力バッファ３１０、ＲＴＰヘッダー変更部３２０、メディアホップ（ＭＨ）送信バッファ３２５、ＭＨ再送信‐Ｐｒ０バッファ（ＲｅＸＰｒ０バッファ）３３０、送信ＭＨ‐ＲＴＰ管理部３４０及び２つのＭＨシーケンスカウンタ３３５ａ，ｂを具備する。関連するＲＴＰが確立されたとき、各ＭＨシーケンスカウンタ３３５ａ，ｂは、例えばランダムに生成された数にセットされ得る。幾つかの実施形態において、１以上のシーケンスカウンタが一定の数にセットされ得る。例えば最終ＨＰｒ０ＳＮはゼロにセットされ得る。

１つのＭＨシーケンスカウンタ３３５ａは、共通ＲＴＰシーケンス番号をカウントでき、このカウンタは最終ＳＮと呼ばれ、最初に又は再送信要求の受信に応じて、ＩＭＨＴＲＰ３００から送信されたＲＴＰパケット毎に、増加され得る。最終ＳＮの値は、送信されたＲＴＰパケットのヘッダーのＳＮ領域に書き込まれ得る。もう一方のシーケンスカウンタ３３５ｂは、重要なフレーム（Ｐｒ０フレーム）の圧縮されたデータを搬送するＲＴＰパケットをカウントでき、このカウンタは最終ＨＰｒ０ＳＮと呼ばれ、ＩＭＨＴＲＰ３００から送信又は再送信されたＰｒ０フレームの圧縮データを搬送するオリジナルのＲＴＰパケット、又は、再送信されたＲＴＰパケット毎に、増加され得る。最終ＨＰｒ０ＳＮの値は、送信されたＲＴＰパケットの拡張ヘッダーのＨＰｒ０ＳＮ領域に書き込まれ得る。

一実施形態に係るＩＭＨＴＲＰ３００は、中間メディアホップの内部要素（図示せず）から圧縮ＲＴＰパケットストリームを受信してよく、関連ＲＴＰ接続へ向けられてよい。圧縮ＲＴＰパケットストリームは、異なる優先度を持つ２以上のレイヤの圧縮ＮＡＬユニットを搬送できる。取得されたＲＴＰパケットは、入力バッファ３１０に記憶され得る。この入力バッファ３１０から各ＲＴＰパケットが、ヘッダー変更部３２０によって取得される。

一実施形態に係るヘッダー変更部３２０において、パケットのＲＴＰヘッダーは、変更され得る。ＭＨ最終ＳＮカウンタ３３５ａの値は、例えば直前の値に代えて、ＲＴＰヘッダーのＳＮ領域に書き込まれる。ＭＨ最終ＨＰｒ０ＳＮカウンタ３３５ｂの値は、直前の値に代えて、拡張ＲＴＰヘッダーのＨＰｒ０ＳＮ領域に書き込まれる。ＨＰｒ０ＳＮ領域の変更は、パケットが関連するＲＴＰ接続へ送信された最初のとき又はパケットの再送信に対して、行われ得る。拡張ＲＴＰヘッダーを有するＲＴＰパケットは、ヘッダー変更部３２０からＭＨ送信バッファ３２５経由でネットワークインタフェースカード（図示せず）へ伝送され得る。ネットワークインタフェースカードは、関連するＲＴＰ接続に関連付けられ得る。並行して、重要なフレーム（Ｐｒ０）の圧縮ビデオデータを搬送するＲＴＰパケットは、ＭＨＲｅＸ‐Ｐｒ０バッファ３３０に記憶され得る。

ＭＨＲｅＸ‐Ｐｒ０バッファ３３０はＲＡＭ装置であり得、ＭＨＲｅＸ‐Ｐｒ０バッファ３３０のＲＡＭないの各アドレスは、拡張ＲＴＰヘッダーを持つＰｒ０圧縮ビデオのＲＴＰパケット全体を記憶できる。Ｐｒ０のＲＴＰパケットを記憶できるアドレスは、該パケットの拡張ＲＴＰヘッダーのＨＰｒ０ＳＮ領域の末尾数ビットを表し得る。末尾数ビットの数は、例えば、ＨＰｒ０ＳＮ領域の末尾の６〜１０ビットであり得る。

送信ＭＨ‐ＲＴＰ管理部３４０は、ＩＭＨＴＲＰ３００の処理全体を管理するだろう。ＲＴＰ接続の初期化の間、送信ＭＨＲＴＰ管理部３４０は、２つのＭＨシーケンスカウンタ３３５ａ，ｂを割り当てて、セットできる。各ＭＨシーケンスカウンタ３３５ａ，ｂは、ランダムな数又はゼロにセットされ得、送信されたＲＴＰパケットの性質に従い増加され得る。更に、ＭＨＲＴＰ管理部３４０は、ＲＴＰ接続を制御するために、ＲＴＰ接続の受信側のＲＴＰ管理モジュールと通信できる。接続の受信側の管理モジュールとの通信は、ＲＴＣＰ通信プロトコルを用いて行われ得る。

会議セッション中、ＭＨＲＴＰ管理部３４０は、接続の受信側のＲＴＰ管理部からのＲＴＣＰ再送信要求を受信するだろう。再送信要求の一例は、再送信要求リスト（ＲｅＸＲｅｑリスト）を含む。ＲｅＸＲｅｑリストは、要求されたＰｒ０パケットのリストを含み得る。該リストは、欠損した重要なパケット（Ｐｒ０）のＨＰｒ０ＳＮ領域の値を含み得る。ＲｅＸＲｅｑリストに基づいて、ＭＨ‐ＲＴＰ管理部３４０は、同じＨＰｒ０ＳＮの値を持つパケットを求めて、ＭＨＲｅＸ‐Ｐｒ０バッファ３３０を検索する。要求されたＰｒ０パケットがＭＨＲｅＸ‐Ｐｒ０バッファ３３０に記憶されている場合、これらパケットはＭＨＲｅＸ‐Ｐｒ０バッファ３３０から取り出されて、ヘッダー変更部３２０へ伝送され得る。

ヘッダー変更部３２０において、ＳＮ及びＨＰｒ０ＳＮ領域は、ＭＨ最終ＳＮカウンタ３３５ａ及びＭＨ最終ＨＰｒ０ＳＮカウンタ３３５ｂの現在値に従い更新され得る。拡張ＲＴＰヘッダーのＯＳＮ及びＯＰｒ０ＳＮ領域の値は、変更されないままである。そして、ＭＨ最終ＳＮカウンタ３３５ａ及びＭＨ最終ＨＰｒ０ＳＮカウンタ３３５ｂが増加されて、要求されたパケットがＭＨ送信バッファ３２５経由で再送信され得る。１以上の要求されたＰｒ０パケットがＭＨＲｅＸ‐Ｐｒ０バッファ３３０に存在しない場合は、ＭＨＲＴＰ管理部３４０により、関連するストリームを発したエンドポイントに対して、イントラ要求が送信され得る。いくつかの実施形態において、１以上のシーケンスカウンタは、ＲＴＰヘッダー内の関連する領域の更新前に増加され得る。ＩＭＨＴＲＰ３００の動作に関する更なる情報は、図７と併せて後述される。

次に図３Ｂを参照すると、一実施形態にかかる中間メディアホップ受信ＲＴＰ処理装置（ＩＭＨＲＲＰ）３５０の関連要素のブロック図が描かれている。中間メディアホップは、複数のＭＲＥからの複数の圧縮ビデオストリーム、及び、複数のＭＲＥへの複数の圧縮ビデオストリームを、中継するＭＲＭである。数多の要素のうち、一実施形態に係るＭＲＭは１以上のＩＭＨＲＲＰ３５０を具備してよい。各ＩＭＨＲＲＰ３５０は、当該ＭＲＭと、送信ＭＲＥ又は経路に沿う他のＭＲＭとの間の、ＲＴＰ接続に関連付けられ得る。一実施形態に係るＩＭＨＲＲＰ３５０は、バッファ３６０、ＭＨ‐ＲＴＰヘッダー解析部３７０及びＭＨ‐受信‐ＲＴＰ管理部３８０を具備する。

一実施形態に係るＩＭＨＲＲＰ３５０は、関連するＲＴＰ接続に関連付けられたネットワークインタフェースカード（図示せず）からの圧縮ビデオＮＡＬデータユニットを搬送しているＲＴＰパケットのストリームを取得するだろう。取得されたＲＴＰパケットは、バッファ３６０に記憶される。バッファ３６０は、例えば循環メモリであり得、複数の取得されたＲＴＰパケットを記憶する。

ＭＨヘッダー解析部３７０は、バッファ３６０の中から、次の１つのＲＴＰパケットを取得して、取得されたＲＴＰパケットの拡張ＲＴＰヘッダーを解析し、中間メディアホップの内部ユニット（図示せず）へ、該取得されたＲＴＰパケットを伝送するだろう。

ＰｒＩＤ及びＨＰｒ０ＳＮ拡張領域の値に基づいて、一実施形態に係るＭＨヘッダー解析部３７０は、Ｐｒ０パケットすなわち重要なパケットが、送信ＭＲＥ又はＭＲＭからの経路の最終セグメントにて損失したかどうかを決定するだろう。

ＨＰｒ０ＳＮにギャップが検出された場合、受信ＭＨＲＴＰ管理部３８０はいずれの１以上の重要なパケットが欠損したかを決定でき、１以上の欠損したＰｒ０パケットの再送信用のリストを含む要求が、受信ＭＨＲＴＰ管理部３８０経由で、ＲＴＣＰ接続を通じて、送信ＭＲＥの送信ＲＴＰ管理部２３０（図２Ａ）又は直前の中間ＭＨの送信ＭＨＲＴＰ管理部３４０へ送信され得る。

受信ＭＨＲＴＰ管理部３８０は、ＩＭＨＲＲＰ３５０の処理全体を管理してよい。ＲＴＰ接続の初期化の間、受信ＭＨＲＴＰ管理部３８０は、ＩＭＨＲＲＰ３５０のリソースを割り当てて、セットしてよい。更に、受信ＭＨＲＴＰ管理部３８０は、ＲＴＰ接続を制御するために、ＲＴＣＰ接続経由で、送信ＲＴＰ管理モジュール２３０（図２Ａ）、又は、ＲＴＰ接続の送信側の送信ＭＨＲＴＰ管理部３４０と、通信できる。

会議セッション中、受信ＭＨＲＴＰ管理部３８０は、送信ＥＰの送信ＲＴＰ管理部２３０又はメディアホップの送信ＲＴＰ管理部３４０へ、ＲＴＣＰ再送信要求を送信するだろう。再送信要求の一例は、再送信要求リスト（ＲｅＸＲｅｑリスト）を含む。ＲｅＸＲｅｑリストは、要求されたＰｒ０パケットのリストを含み得る。該リストは、欠損した重要なパケット（Ｐｒ０）のＨＰｒ０ＳＮ領域の値を含み得る。ＩＭＨＲＰ３５０の動作に関する更なる情報は、図６と併せて後述される。

次に図４を参照すると、送信ＥＰ‐ＲＴＰ処理装置（ＴＥＲＰ）２００の送信タスク４００の関連ブロックを示すフローチャートである。ＴＥＲＰ２００は、当該ＴＥＲＰ２００に関連付けられたＲＴＰ接続を通じて伝送された圧縮ＳＣ形式ストリームのソースであるＥＰ又はＭＲＥに関連付けられ得る。方法４００は、送信ＥＰ／ＭＲＥと次のメディアホップとの間のＲＴＰ接続確立中に開始され得る（４０２）。ＲＴＰ接続は、会議セッションの確立中又は進行中のセッションへの参加に際して開始され得る。

開始後、ＴＥＲＰのリソースが割り当て及びセットされる（４０４）。例えば、４つのシーケンスカウンタ２３５ａ〜ｄ（図２Ａ）が割り当てられて得る。各カウンタ（最終ＳＮ、最終ＯＳＮ、最終ＯＰｒ０ＳＮ、最終ＨＰｒ０ＳＮ）は、例えばランダムな数又はゼロにセットされ得る。更に、例示に限定されないが、例えばＲｅＸ−Ｐｒ０バッファ２２５（図２Ａ）などのバッファが割り当て及びリセットされ、また、例えば最終ＩＤＲなどのレジスタが割り当て及びリセットされる。

次に、送信ＲＴＰ管理部２３０（図２Ａ）は、そのキュー（待ち行列）内に、ＲｅＸ要求リストへの記入が存在しているかどうかをチェックする（４１０）。存在しない場合、方法４００はブロック４１２に続く。４１０においてＲｅＸ要求リストへの記入が存在している場合、当該要求が取り出され、該記入がクリアされ、取り出された要求が解析され、そして、要求されたＨＰｒ０ＳＮの値が最終ＩＤＲレジスタに記憶された値よりも小さいかどうかの決定がなされる（４３０）。最終ＩＤＲレジスタは、イントラＰｒ０フレームの始まりを搬送する１番目のパケットのＨＰｒ０ＳＮ領域の値を記憶する。前記ブロック４３０において値がより小さい場合、欠損したパケットにより搬送された圧縮Ｐｒ０ビデオデータの後にイントラフレームが既に送信されたことを示しており、欠損パケットの再送信の必要がなく、方法４００はブロック４１０に戻る。

前記ブロック４３０において値がより小さくない場合、ＲｅＸ−Ｐｒ０バッファ２２５（図２Ａ）がチェックされ（４３２）、要求されたＰｒ０パケットがＲｅＸ−Ｐｒ０バッファ２２５に存在するかどうかの決定がなされる。要求されたパケットがＲｅＸ−Ｐｒ０バッファ２２５に存在していない場合、デコーダリフレッシュ要求（イントラ要求）が、関連するストリームのエンコーダに対して送信されて（４３６）、方法４００はブロック４１０に戻る。前記ブロック４３２において、要求されたリストに記載されたＰｒ０パケットがＲｅＸ−Ｐｒ０バッファ２２５に存在している場合、要求されたＰｒ０パケットがＲｅＸ−Ｐｒ０バッファ２２５から取得され、削除され（４３４）、そして方法４００は、取得されたＰｒ０パケットを処理するために、ブロック４４０に進む。

ブロック４１０に戻ると、ＲｅＸ要求リストに最早記入がない場合、ＮＡＬ累算部２１０（図２Ａ）は調査され（４１２）、それにより、１つのＲＴＰパケットのペイロード用に十分なバイト数があるかどうか（４１４）を決定する。前記ブロック４１４において十分なバイト数がない場合、関連するエンコーダから追加のＮＡＬユニットを集めることができるように、方法４００はブロック４１０に戻る。前記ブロック４１４において、１つのＲＴＰパケットのペイロード用に十分なバイト数がある場合、ＮＡＬ累算部２１０からＮＬＡユニットを取得することによりペイロードが集められる。そして、該ペイロードに対するＲＴＰヘッダーを組み立て、また、拡張ヘッダーを組み立てるために、該ペイロードがヘッダー作成部２１５（図２Ａ）に伝送されて、ＲＴＰパケットを作成する（４１６）。ＰｒＩＤはエンコーダから受信された情報に従いセットされ得る。

ＯＳＮシーケンスカウンタの値、最終ＯＳＮは増加され、そして、新しい最終ＯＳＮが、拡張ＲＴＰヘッダーのＯＳＮ領域に書き込まれ得る（４１８）。次に、ペイロードのコンテンツがＰｒ０フレーム、すなわち重要なフレームの圧縮ビデオを含んでいるかどうかの決定がなされる（４２０）。含んでいない場合、最終ＯＰｒ０ＳＮの値はそのまま残り、その値が拡張ＲＴＰヘッダーのＯＰｒ０ＳＮ領域にコピーされる（４２８）。そして方法４００はブロック４４２に進む。

前記ブロック４２０において、ＲＴＰパケットのペイロードが重要なフレームの圧縮ビデオを搬送している場合は、最終ＯＰｒ０ＳＮカウンタの値が増加され（４２２）、新しい値が拡張ＲＴＰヘッダーのＯＰｒ０ＳＮ領域にコピーされる（４２８）。次に、解析された圧縮ビデオのヘッダーに基づいて、ＲＴＰパケットがイントラフレームの始まりを搬送しているかどうかの決定がなされる（４２４）。搬送している場合、シーケンスカウンタ最終Ｐｒ０ＳＮに１加算した値が最終ＩＤＲレジスタにコピーされる（４２６）。この最終ＩＤＲレジスタは、ブロック４３０において再送信要求を処理するために使用される。方法４００はブロック４４０に進む。

ブロック４４０においてシーケンスカウンタ最終Ｐｒ０ＳＮが増加される。シーケンスカウンタ最終Ｐｒ０ＳＮの値は、拡張ＲＴＰヘッダーのＨＰｒ０ＳＮ領域にコピーされ（４４２）、且つ、シーケンスカウンタ最終ＳＮが増加されて（４４２）、シーケンスカウンタ最終ＳＮの新しい値がＲＴＰヘッダーのＳＮ領域にコピーされる。

拡張ＲＴＰヘッダーのＰｒＩＤ領域に基づいて、パケットが重要なフレームのデータを搬送しているかどうかの決定がなされる（４５０）。前記４５０においてパケットが重要なフレームのデータを搬送していない場合、方法４００はブロック４５４に進み、ネットワークインタフェースカード（図示せず）経由で、且つ、関連するＲＴＰ接続を通じて、次のメディアホップへ新しいＲＴＰパケットを送信する。ＲＴＰパケットの送信後、方法４００は、ブロック４１０に戻り新たな処理サイクルを始める。前記４５０においてパケットが重要なフレームのデータを搬送している場合、方法４００は、ＲｅＸ−Ｐｒ０バッファ２２５にＲＴＰパケットのコピーを記憶して（４５２）、ネットワークインタフェースカード（図示せず）経由で、且つ、関連するＲＴＰ接続を通じて、次のメディアホップへ新しいＲＴＰパケットを送信する（４５４）。それから、方法４００は、ブロック４１０に戻り新たな処理サイクルを始める。いくつかの実施形態に係るＲＴＥＲ２００（図２Ａ）において、ＲｅＸ−Ｐｒ０バッファ２２５においてＲＴＰパケットを記憶するアドレスは、そのパケットの拡張ＲＴＰヘッダーのＨＰｒ０ＳＮ領域の値を表し得る。

図５Ａは、編成方法５００の一例に関連するブロックのフローチャートを示す。編成方法５００は、一実施形態に係る受信ＥＰ−ＲＴＰ処理装置（ＲＥＲＰ）２５０により実行され得る。ＲＥＲＰ２５０は、当該ＲＥＲＰ２５０に関連付けられたＲＴＰ接続を通じて伝送される圧縮ＳＣ形式ストリームの宛先における受信ＥＰ又は受信ＭＲＥに関連付けられ得る。方法５００は、受信ＥＰ／ＭＲＥと直前のメディアホップとの間のＲＴＰ接続確立中に開始され得る（５０２）。ＲＴＰ接続は、会議セッションの確立中又は進行中のセッションに対する受信ＥＰの参加に際して開始され得る。

開始の後、ＲＥＲＰ２５０のリソーイが割り当て及びセットされる（５０４）。例示に限定されないが、例えば、ＯＯＳＮＢ２６０（図２Ｂ）、ＮＡＬバッファ２６５、ジッタバッファ２５５、Ｎレジスタ、最終Ｐｒ０レジスタなどのリソースが、割り当て及びリセットされる。

ジッタバッファ２５５（図２Ｂ）から、或る次の受信ＲＴＰパケットが取得され得る。パケットの拡張ＲＴＰヘッダーが解析され（５０６）、そしてＨＰｒ０ＳＮ及びＰｒＩＤ領域の値が取り出される。取り出されたＨＰｒ０ＳＮの値と最終Ｐｒ０レジスタに書き込まれた値との差が計算され（５０８）、その結果が、‘Ｎ’レジスタに記憶され得る。

‘Ｎ’に差の値を記憶した後、‘Ｎ’の値がゼロより小さいか、又は、ゼロかどうかの決定がなされる（５１０）。値がゼロより小さいか又はゼロの場合、パケットが、最終メディアホップ及び受信ＥＰからの経路上の順を外れて受信されたことを示しており、その場合、取得されたＰｒＩＤの値がゼロであるかどうか、更なる決定がなされる（５１２）。取得されたＰｒＩＤの値がゼロであるかどうかは、現在のパケットが重要なフレームのデータを搬送しているかどうかを示す。前記ブロック５１２において、ＰｒＩＤの値がゼロの場合、再送信要求リスト（ＲｅＸＲｅｑリスト）が調査され（５１４）、同じＨＰｒ０ＳＮの値を持つＲＴＰパケットの再送信要求が再送信要求リストから削除される。そして、方法５００はブロック５３０に進み得る。前記ブロック５１２において、ＰｒＩＤの値がゼロでない場合、それが重要なパケットでないことを示しており、方法５００はブロック５３０に進み得る。

ブロック５３０において、ＲｅＸＲｅｑリストに基づく再送信要求が、ＲＴＣＰ接続を通じて、受信ＲＴＰ管理部２７５（図２Ｂ）から、該ＲＴＣＰ接続のもう一方の側のＲＴＰ管理部へ、送信される。受信されたＲＴＰパケットは、方法５０００（図５Ｂ）により処理されるべくＯＯＳＮＢ２６０（図２Ｂ）へ転送され（５３２）、方法５００はブロック５０６に戻る。

いくつかの実施形態において、リストは、イントラフレームが受信される度いつも、又は、リスト内の各エントリの時間経過などに基づいて、クリアされ得る。更に、幾つかの実施形態において、ブロック５３２において、重複パケット、すなわち同じＯＳＮを持つパケットは、ＯＯＳＮＢ２６０（図２Ｂ）から破棄され得る。

ブロック５１０に戻ると、‘Ｎ’の値がゼロより大きい場合、取得されたＰｒＩＤの値がゼロであるかどうかの、決定がなされる（５１６）。取得されたＰｒＩＤの値がゼロかどうかは、現在のパケットが重要なフレームのデータを搬送しているかどうかを示す。前記ブロック５１６において、取得されたＰｒＩＤがゼロでない場合、直前のメディアホップからの最後のセグメントにおいて１以上の重要なパケットが欠損したことを示しており、その場合、ＲｅＸＲｅｑリストが更新され得る（５１８）。更新は、複数の要求されたパケットのリストを記述することにより行われ得、ここで記述されるリスト中の各パケットの拡張ＲＴＰヘッダー領域のＨＰｒ０ＳＮ領域の値は、最終Ｐｒ０レジスタの記憶値に１を加算した値、２を加算した値、３を加算した値・・・‘Ｎ’レジスタの記憶値を加算した値である。ＲｅＸＲｅｑリストの更新後、現在受信したＲＴＰパケットの拡張ＲＴＰヘッダー領域のＨＰｒ０ＳＮ領域の値が、最終Ｐｒ０の直前の値に代えて記憶され（５２４）、そして方法５００はブロック５３０に進み得る。

前記ブロック５１６において取得されたＰｒＩＤがゼロである場合、現在のパケットが重要なフレームのデータを搬送していることを示しており、その場合、‘Ｎ’の値が１かどうか、更なる決定がなされる（５２０）。前記ブロック５２０において、‘Ｎ’の値が１の場合、重要なパケットの損失がないことを示しており、方法５００はブロック５２４に進み得る。前記ブロック５２０において、‘Ｎ’の値が１でない場合、このパケットに至るまでに、１以上の重要なパケットが欠損したことを示しており、従って、ＲｅＸＲｅｑリストが更新され得る（５２２）。更新は、複数の要求されたパケットのリストを記述することにより行われ得、ここで記述されるリスト中の各パケットの拡張ＲＴＰヘッダー領域のＨＰｒ０ＳＮ領域の値は、最終Ｐｒ０レジスタの記憶値に１を加算した値、２を加算した値、３を加算した値・・・‘Ｎ’レジスタの記憶値のマイナス１を加算した値である。ＲｅＸＲｅｑリストの更新後、現在受信したＲＴＰパケットの拡張ＲＴＰヘッダー領域のＨＰｒ０ＳＮ領域の値が、最終Ｐｒ０の直前の値に代えて記憶され（５２４）、そして方法５００はブロック５３０に進み得る。

図５Ｂは、一実施形態にかかるＰｒ０確認方法５０００の一例の関連ブロックのフローチャートを示す。Ｐｒ０確認方法５０００は、一実施形態に係る受信ＥＰ−ＲＴＰ−処理装置（ＲＥＲＰ）２５０により実行され得る。ＲＥＲＰ２５０は、該ＲＥＲＰ２５０に関連付けられたＲＴＰ接続を通じて伝送された圧縮ＳＣ形式ストリームの宛先における受信ＥＰ又は受信ＭＲＥに関連付けられ得る。方法５０００は、受信ＥＰ／ＭＲＥと直前のメディアホップとの間のＲＴＰ接続確立中に開始され得る（５５０）。ＲＴＰ接続は、会議セッションの確立中又は進行中のセッションに対する受信ＥＰの参加に際して開始され得る。

開始後、方法５０００に関連したＲＥＲＰ２５０のリソースが割り当てられ（５５２）、セットされる。リソースは、例示に限定されないが、例えば、ＯＯＳＮＢ２６０（図２Ｂ）、ＮＡＬバッファ２６５、ジッタバッファ２５５、Ｎレジスタ、最終Ｐｒ０レジスタなどのリソースが、割り当て及びリセットされる。

ＯＯＳＮＢ２６０（図２Ｂ）の中から、次の１つの受信されたＲＴＰパケットが取得され得る。該パケットの拡張ＲＴＰヘッダーは解析され得（５５４）、ＯＰｒ０ＳＮ及びＰｒＩＤ領域の値が取り出され得る。取り出されたＯＰｒ０ＳＮの値と、最終Ｐｒ０レジスタに書き込まれた値との差が計算され（５５６）、その結果が、‘Ｍ’レジスタに記憶され得る。

‘Ｍ’レジスタに差の値を書き込んだ後、取得されたＰｒＩＤの値がゼロであるかどうかの決定がなされる（５６０）。取得されたＰｒＩＤの値がゼロかどうかは、現在のパケットが重要なフレームのデータを搬送しているかどうかを示している。前記ブロック５６０において取得されたＰｒＩＤの値がゼロの場合、‘Ｍ’レジスタの値が１かどうか、更なる決定がなされる（５６４）。‘Ｍ’レジスタの値が１の場合、受信した圧縮ビデオストリームのオリジナルソースから当該圧縮ビデオストリームの受信宛先までに、重要なパケットの欠損がないことを示しており、現在受信されたＲＴＰパケットの拡張ＲＴＰヘッダーのＯＰｒ０ＳＮ領域の値が、最終ＯＰｒ０レジスタの直前の値に代えて、書き込まれ（５７０）、方法５０００はブロック５７２に進む。ブロック５７２において、受信されたＲＴＰパケットは、ＮＡＬバッファ２６５（図２Ｂ）に転送され、このＮＡＬバッファ２６５から受信ＥＰのデコーダへ伝送され得る。デコーダは、圧縮ビデオストリームを処理することができ、この圧縮ビデオストリームは関連するＲＴＰ接続上で搬送されたものである。そして、方法５０００は、ＯＯＳＮＢ２６０内の次のＲＴＰパケットを処理するために、ブロック５５４に戻る。

前記ブロック５６０において取得されたＰｒＩＤの値がゼロでない場合、現在のパケットが重要なフレームを搬送するものでないことを示しており、‘Ｍ’レジスタの値が１かどうか、更なる決定がなされる（５６２）。前記ブロック５６２において‘Ｍ’レジスタの値が１の場合、受信した圧縮ビデオストリームのオリジナルソースから当該圧縮ビデオストリームの受信宛先までに、重要なパケットの欠損がないことを示しており、現在受信されたＲＴＰパケットの拡張ＲＴＰヘッダーのＯＰｒ０ＳＮ領域の値が、最終ＯＰｒ０レジスタの直前の値に代えて、書き込まれ（５７０）、方法５０００はブロック５７２に進む。ブロック５７２において、受信されたＲＴＰパケットは、ＮＡＬバッファ２６５（図２Ｂ）に転送され、このＮＡＬバッファ２６５から受信ＥＰのデコーダへ伝送され得る。デコーダは、圧縮ビデオストリームを処理することができ、この圧縮ビデオストリームは関連するＲＴＰ接続上で搬送されたものである。そして、方法５０００は、ＯＯＳＮＢ２６０内の次のＲＴＰパケットを処理するために、ブロック５５４に戻る。

次にブロック５６４又はブロック５６２に戻ると、‘Ｍ’レジスタの値がそれぞれ１又はゼロと等しくない場合、１以上の重要なパケットが欠損したことを示しており、受信ＲＴＰ管理部２７５（図２Ｂ）によりイントラフレームの要求が送信され得る（５６８）。イントラ要求は、ＲＴＰＣ接続を通じて、関連する圧縮ビデオストリームのソースの送信ＲＴＰ管理部へ送信され得る。イントラ要求は、１以上の中間メディアホップ経由で伝送され得る。そして、方法５０００は、ブロック５７０に進み得る。

いくつかの実施形態に係る方法５０００において、前記ブロック５７２においてＲＴＰパケットをデコーダへ転送した後、処理は、送信されたフレーム内のジッタを克服するために、所定期間待機し得る。待機期間は、例えば５〜２０ミリ秒の間の数ミリ秒の範囲内であり得る。

図６は、中間メディアホップ受信方法６００の一例の関連ブロックのフローチャートを示す。方法６００は、一実施形態に係るＩＭＨＲＲＰ３５０（図３Ｂ）により実行され得る。ＩＭＨＲＲＰ３５０は、圧縮ビデオストリームのソースと圧縮ＳＣ形式ビデオストリームの受信宛先との間に位置する中間メディアホップに関連付けられ得る。中間メディアホップは、例えば２以上のＭＲＥの間に位置するＭＲＭであり得る。方法６００は、メディアホップと、圧縮ＳＣ形式ビデオストリームのソースであるＥＰ／ＭＲＥ又は直前のメディアホップとの間のＲＴＰ接続確立中に開始され得る（６０２）。ＲＴＰ接続は、例えば、会議セッションの確立中又は進行中のセッションに対する受信ＥＰ／ＭＲＥの参加に際して開始され得る。

開始後、ＩＭＨＲＲＰ３５０のリソースが割り当てられ（６０４）、セットされる。リソースは、例示に限定されないが、例えば、バッファ３６０（図３Ｂ）、Ｎ´レジスタ、最終Ｐｒ０´レジスタなどのリソースが、割り当て及びリセットされる。バッファ３６０（図３Ｂ）の中から、次の１つの受信されたＲＴＰパケットが取得され得る。該パケットの拡張ＲＴＰヘッダーは解析され得（６０６）、そして、ＨＰｒ０ＳＮ及びＰｒＩＤ領域の値が取り出され得る。取り出されたＨＰｒ０ＳＮの値と、最終Ｐｒ０´レジスタに書き込まれた値との差が計算され（６０８）、その結果が、‘Ｎ´’レジスタに記憶され得る。

‘Ｎ´’レジスタに差の値を書き込んだ後、‘Ｎ´’の値がゼロより小さいかどうかの決定がなされる（６１０）。Ｎ´’の値がゼロより小さいか又はゼロである場合、パケットが最終メディアホップ及び受信ＥＰからの経路上の順を外れて受信されたことを示しており、その場合、取得されたＰｒＩＤの値がゼロであるかどうかの、更なる決定がなされる（６１２）。取得されたＰｒＩＤの値がゼロかどうかは、現在のパケットが重要なフレームのデータを搬送しているかどうかを示している。前記ブロック６１２において取得されたＰｒＩＤの値がゼロの場合、再送信要求リスト（ＲｅＸＲｅｑリスト）が調査され（６１４）、同じＨＰｒ０ＳＮの値を持つＲＴＰパケットの再送信要求が再送信要求リストから削除される。そして、方法６００は、ブロック６３０に進む。前記ブロック６１２において取得されたＰｒＩＤの値がゼロでない場合、そのパケットが重要なフレームでないことを示しており、その場合、方法６００は、ブロック６３０に進む。

ブロック６３０において、ＲｅＸＲｅｑリストに基づく再送信要求が、ＲＴＣＰ接続を通じて、受信ＭＨＲＴＰ管理部３８０（図３Ｂ）から、該ＲＴＣＰ接続のもう一方の側のＲＴＰ管理部へ、送信され得る。そして、受信されたＲＴＰパケットは、メディアホップの１以上の別の内部ユニット（図示せず）に転送され得る（６３２）。そして、方法６００は、バッファ３６０内の次のＲＴＰパケットを処理するために、ブロック６０６に戻る。いくつかの実施形態において、ＲｅＸＲｅｑリストは、イントラフレームが受信される度いつも、又は、リスト内の各エントリの時間経過などに基づいて、クリアされ得る。更に、幾つかの実施形態において、ブロック６３０において、重複パケット、すなわち同じＯＳＮを持つパケットは、ＯＯＳＮＢ２６０（図２Ｂ）から破棄され得る。

ブロック６１０に戻ると、‘Ｎ´’の値がゼロより大きい場合、取得されたＰｒＩＤの値がゼロであるかどうかの、決定がなされる（６１６）。取得されたＰｒＩＤの値がゼロかどうかは、現在のパケットが重要なフレームのデータを搬送しているかどうかを示す。前記ブロック６１６において、取得されたＰｒＩＤがゼロではない場合、直前のメディアホップ又はＥＰ／ＭＲＥからの最後のセグメントにおいて、１以上の重要なパケットが欠損したことを示しており、その場合、ＲｅＸＲｅｑリストが更新され得る（６１８）。更新は、複数の要求されたパケットのリストを記述することにより行われ得、ここで記述されるリスト中の各パケットの拡張ＲＴＰヘッダー領域のＨＰｒ０ＳＮ領域の値は、最終Ｐｒ０´レジスタの記憶値に１を加算した値、２を加算した値、３を加算した値・・・‘Ｎ´’レジスタの記憶値を加算した値である。ＲｅＸＲｅｑリストの更新後、現在受信したＲＴＰパケットの拡張ＲＴＰヘッダー領域のＨＰｒ０ＳＮ領域の値が、最終Ｐｒ０´の直前の値に代えて記憶され（６２４）、そして方法５００はブロック６３０に進み得る。

前記ブロック６１６において取得されたＰｒＩＤがゼロの場合、現在のパケットが重要なフレームのデータを搬送していることを示しており、その場合、‘Ｎ´’の値が１と等しいかどうか、更なる決定がなされる（６２０）。前記ブロック６２０において、‘Ｎ´’の値が１の場合、重要なパケットの損失がないことを示しており、方法６００はブロック６２４に進み得る。前記ブロック６２０において‘Ｎ´’の値が１ではない場合、このパケットに至るまでにいくつかの重要なパケットが欠損したことを示しており、従って、ＲｅＸＲｅｑリストが更新され得る（６２２）。更新は、複数の要求されたパケットのリストを記述することにより行われ得、ここで記述されるリスト中の各パケットの拡張ＲＴＰヘッダー領域のＨＰｒ０ＳＮ領域の値は、最終Ｐｒ０´レジスタの記憶値に１を加算した値、同２を加算した値、同３を加算した値・・・ ‘Ｎ´’レジスタの記憶値のマイナス１を加算した値である。ＲｅＸＲｅｑリストの更新後、現在受信したＲＴＰパケットの拡張ＲＴＰヘッダー領域のＨＰｒ０ＳＮ領域の値が、最終Ｐｒ０´の直前の値に代えて記憶され（６２４）、そして方法６００はブロック６３０に進み得る。

図７は、中間メディアホップ送信方法７００の一例の関連ブロックのフローチャートを示す。方法７００は、一実施形態に係るＩＭＨＴＲＰ３００（図３Ａ）により実行され得る。ＩＭＨＴＲＰ３００は、圧縮ビデオストリームのソースと圧縮ＳＣ形式ビデオストリームの受信宛先との間に位置する中間メディアホップに関連付けられ得る。中間メディアホップは、例えば２以上のＭＲＥの間に位置するＭＲＭであり得る。方法７００は、メディアホップと、圧縮ＳＣ形式ビデオストリームの宛先であるＥＰ／ＭＲＥ又は次のメディアホップとの間のＲＴＰ接続確立中に開始され得る（７０２）。ＲＴＰ接続は、例えば、会議セッションの確立中又は進行中のセッションに対する受信ＥＰ／ＭＲＥの参加に際して開始され得る。

開始後、ＩＭＨＴＲＰ３００のリソースが割り当てられ（７０４）、セットされる。例えば、ＭＨシーケンスカウンタ３３５ａ，ｂ（図３Ａ）の２つが割り当てられる。各カウンタ（最終ＳＮと最終Ｐｒ０ＳＮ）はランダムな数又はゼロにセットされ得る。更に、例示に限定されないが、例えばＭＨ‐ＲｅＸ‐Ｐｒ０バッファ３３０（図３Ａ）などのバッファが割り当てられ（７０４）、リセットされ、また、例えば最終ＩＤＲレジスタなどのレジスタが割り当てられ、リセットされる。

次に、ＭＨ送信管理部３４０（図３Ａ）は、ＲｅＸ要求エントリがキュー（待ち行列）にあるかどうかを調べる（７１０）。存在しない場合、方法７００はブロック７１２に進み得る。前記７１０においてＲｅＸ要求エントリが見つかった場合、該要求が取り出されて、該エントリがクリアされ、該取り出された要求が解析され、そして、要求されたＨＰｒ０ＳＮの値が最終ＩＤＲレジスタに記憶された値よりも小さいかどうかに基づいて決定がなされる（７２０）。最終ＩＤＲレジスタは、或るイントラＰｒ０フレームの始まりを搬送する１番目のパケットのＨＰｒ０ＳＮ領域の値を記憶している。前記ブロック７２０において要求されたＨＰｒ０ＳＮの値が、最終ＩＤＲレジスタに記憶された値よりも小さい場合、イントラフレームが既に発されており、欠損したパケットによって搬送された圧縮Ｐｒ０ビデオデータの作成後に、当該イントラフレームが受信されたであろうことを示しており、従って、欠損したパケットの再送信の必要がなく、方法７００はブロック７１０に戻る。

前記ブロック７２０において要求されたＨＰｒ０ＳＮの値が、最終ＩＤＲレジスタに記憶された値よりも小さくない場合、ＭＨ‐ＲｅＸ‐Ｐｒ０バッファ３３０（図３Ａ）がチェックされ（７２２）、そして、リストのエントリに記載されたＰｒ０パケットがＭＨ‐ＲｅＸ‐Ｐｒ０バッファ３３０に存在するかどうかに基づいて決定がなされる。要求されたパケットがＭＨ‐ＲｅＸ‐Ｐｒ０バッファ３３０に存在しない場合、デコーダリフレッシュ要求（すなわちイントラ要求）が、ＲＴＰ接続を通じて、圧縮ＳＣ形式ビデオストリームのソースへ、送信され得る（７２６）。そして、方法７００は、ブロック７１０に戻る。前記ブロック７２２において、要求リストのエントリに記載されたＰｒ０パケットがＭＨ‐ＲｅＸ‐Ｐｒ０バッファ３３０に存在する場合、要求されたＰｒ０パケットがＭＨ‐ＲｅＸ‐Ｐｒ０バッファ３３０から取得され、削除され（７２４）、方法７００は、取得された要求されたパケットを処理するために、ブロック７３０に進む。

ブロック７１０に戻ると、前記キューに保留中（ペンディング）のＲｅＸ要求がない場合、入力バッファ３１０（図３Ａ）が調査され（７１２）、ＩＭＨＴＲＰ３００の内部モジュール（図示せず）の中から、次の１つのＲＴＰパケットが取得され得る。該取得されたＲＴＰパケットのＲＴＰヘッダーと拡張ＲＴＰヘッダーが解析され、ＨＰｒ０ｓＳＮ領域及びＰｒＩＤ領域の値が取り出される（７１２）。次に、ペイロードのコンテツがＰｒ０フレーム、つまり重要なフレームの圧縮ビデオを含んでいるかどうか決定がなされる（７１４）。前記ブロック７１４において重要なフレームの圧縮ビデオを含んでいない場合、方法７００はブロック７３２に進む。

前記ブロック７１４において前記パケットが重要なフレームを搬送している場合、ＲＴＰパケットが新しい重要なイントラフレームの始まりを搬送しているかどうかを決定する（７１６）ために、該ＲＴＰパケットのヘッダーがチェックされる。前記ブロック７１６においてＲＴＰパケットが新しい重要なイントラフレームの始まりを搬送していない場合、方法７００はブロック７３０に進む。前記ブロック７１６においてＲＴＰパケットが新しい重要なイントラフレームの始まりを搬送している場合、最終Ｐｒ０ＳＮに１を加算した合計が、最終ＩＤＲレジスタの直前のデータに代えて、該最終ＩＤＲレジスタに書き込まれ得る。

ブロック７３０において、最終Ｐｒ０ＳＮシーケンスカウンタが増加され得る。最終Ｐｒ０ＳＮシーケンスカウンタの値は、拡張ＲＴｐヘッダーのＨＰｒ０ＳＮ領域内に書き込まれ得る（７３２）。更に、最終Ｐｒ０ＳＮシーケンスカウンタが増加され（７３４）、新たな値が共通ＲＴＰヘッダーのＳＮ領域に書き込まれ得る。

次に、拡張ＲＴＰヘッダーのＰｒＩＤ領域に基づいて、パケットのペイロードが重要なフレームの圧縮ビデオを搬送しているかどうか（７４０）、決定がなされる。パケットのペイロードが重要なフレームの圧縮ビデオを搬送していない場合、該ＲＴＰパケットは、ネットワークインタフェースカード（図示せず）経由で且つ関連するＲＴＰ接続を通じて、次のメディアホップ又は受信ＥＰ／ＭＲＥへ送信される（７４４）。前記ブロック７４０において、パケットのペイロードが重要なフレームの圧縮ビデオを搬送している場合、該ＲＴＰパケットのコピーがＭＨＲｅＸＰｒ０バッファ３３０（図３Ａ）に記憶され、そして、該ＲＴＰパケットはネットワークインタフェースカード（図示せず）経由で且つ関連するＲＴＰ接続を通じて、次のメディアホップ又は受信ＥＰ／ＭＲＥへ送信される（７４４）。宛先へのＲＴＰパケットの送信後、方法７００はブロック７１０に戻り新しいサイクルを開始する。

本開示の明細書及び特許請求の範囲において、“備える（ｃｏｍｐｒｉｓｅ）”、“含む（ｉｎｃｌｕｄｅ）”、“持つ（ｈａｖｅ）”及びその同義語は、その動詞の対象又は複数の対象が部材、構成要素（コンポーネント）、要素（エレメント）の完全なリスト、又は、その動詞の主語又は複数の主語の部分である必要はないことを示すように使われている。

上述した通り、本開示の実施形態は、メディア送信装置において複数の送信プロトコル（ＴＰ）パケットのストリームを取得することと、ここで、前記複数のＴＰパケットのストリームは、スケーラブル符号化（ＳＣ）エンコーダにより生成された圧縮データメディアユニットを搬送し、前記複数のＴＰパケットのそれぞれは、割り当てられた優先度を持ち、前記複数のＴＰパケットの前記ストリームは、少なくとも１つの第１優先度レベルのパケットと少なくとも１つの第２優先度レベルのパケットを備え；前記複数のＴＰパケットのそれぞれに対して、複数のヘッダー領域のうち第１ヘッダー領域に第１シーケンス番号を割り当てることと、ここで前記第１シーケンス番号は、前記第１優先度レベルのＴＰパケット毎に変更され；前記複数のＴＰパケットを１以上のメディア受信装置へ送信することとを備える方法を、含み得る。

また、前記ＳＣエンコーダは、発信元（originating）のメディア送信装置に含まれ得る。更に、前記発信元のメディア送信装置において第２シーケンス番号が第２ヘッダ領域に割り当てられ得、ここで割り当てられる第２シーケンス番号は前記第１優先度レベルの複数パケットのオリジナルのシーケンス番号を示す。前記第２シーケンス番号は、先行する任意のネットワークセグメントからの１以上の欠損した第１優先度レベルのバケットを識別するために、最終メディア受信装置において、使用され得る。前記発信元のメディア送信装置は、また、第３ヘッダー領域に第３シーケンス番号を割り当ててよく、該第３シーケンス番号は全てのＴＰパケットのオリジナルのシーケンス番号を示し、前記第３シーケンス番号は優先度に関わらずに複数のＴＰパケットを再順番付け（再編成）するために使用される。

前記発信元のメディア送信装置は、メディア中継エンドポイント（ＭＲＥ）により生成されたメディアを圧縮する前記ＳＣエンコーダを持つエンドポイント又は前記ＭＲＥを備えてよく、或いは、前記発信元のメディア送信装置は、更には、マルチポイント制御ユニット（ＭＲＵ）を備え、前記ＳＣエンコーダが複数のエンドポイントから受信された複数のビデオ画像に基づく常駐表示（ＣＰ，画面分割）ビデオ画像をエンコードする。前記第１シーケンス番号は、前記１以上のメディア受信装置から選択された第１メディア受信装置により、１以上の欠損したパケットを識別して、前記第１メディア受信装置に関連付けられているネットワークセグメント経由で再送信を要求するために、使用されてよい。

更に、開示された方法及びシステムは、１以上の送信されたＴＰパケットを、ソース再送信バッファに記憶し、受信装置から特定のＴＰパケットの再送信要求を受信し、前記特定のＴＰパケットを求めてソース再送信バッファを探し、そして、前記要求に応じて前記受信装置に前記特定のＴＰパケットを再送信するように構成されてよい。任意で、第１優先度レベルを持つ複数のＴＰパケットのみがソース再送信バッファに記憶されてよい。また、常駐表示（ＣＰ）ビデオ画像を表示するために複数のＴＰパケットを受信するエンドポイントから、再送信要求が受信されてよい。いくつかのケースでは、前記特定のＴＰパケットが前記ソース再送信バッファに見つからなかった場合に、前記発信元のメディア送信装置から１つのイントラフレームを要求することが有益であり得る。もちろん、上述した方法のいくつかは、中間メディアホップを供えるメディア送信装置において実行され得る。

前述した明細書が例示することを目的としており制限することを目的としていないことは理解されるべきである。前述した装置、システム、及び、方法は、ステップの順番を変えることを含む様々な方法、及び、使用される正確な実施で変更されてよい。前述した実施形態は、様々な特徴を含んでおり、その全てが、本開示の全ての実施形態に要求されるのではない。更に、いくつかの本開示の実施形態では、いくつかの特徴又は複数の特徴の可能な組み合わせのみが、使用される。当業者にとって、開示された実施形態において示された特徴の種々の組み合わせが思い浮かぶであろう。更に、本開示のいくつかの実施形態は、本開示において異なる実施形態の例に関連付けて記述されていた特徴及び要素の組み合わせにより実行されてよい。本発明の範囲は、添付の特許請求の範囲及びそれとの均等物によりのみ制限される。

Claims (17)

1. メディア送信装置において複数の送信プロトコル（ＴＰ）パケットのストリームを取得することと、ここで、前記複数のＴＰパケットのストリームは、スケー ラブル符号化（ＳＣ）エンコーダにより生成された圧縮データメディアユニットを搬送し、前記複数のＴＰパケットのそれぞれは、割り当てられた優先度を持 ち、前記複数のＴＰパケットの前記ストリームは、少なくとも１つの第１優先度レベルのパケットと少なくとも１つの第２優先度レベルのパケットを備え、
   前記複数のＴＰパケットのそれぞれに対して、複数のヘッダー領域のうち第１ヘッダー領域に第１シーケンス番号を割り当てることと、
   前記複数のＴＰパケットを１以上のメディア受信装置へ送信すること
   からなり、
   前記メディア送信装置は、発信元のメディア送信装置と最終メディア受信装置の間の中間ノードであり、
   前記第１シーケンス番号は、前記ストリームの経路中の各前記中間ノードにより、前記第１優先度レベルの各ＴＰパケット毎に置換され、
   前記第１シーケンス番号は、前記メディア送信装置と前記１以上のメディア受信装置から選択された第１のメディア受信装置との間の或るネットワークセグメント内で損失された１以上の欠損ＴＰパケットを識別して、該メディア送信装置に、該欠損したＴＰパケットの再送信をリクエストするために、該第１のメディア受信装置により使用可能であり、且つ、
   前記第１優先度レベルのＴＰパケットのそれぞれが、ベースレイヤのフレームの圧縮ビデオデータを表す
   ことを特徴とする方法。
2. 前記ＳＣエンコーダは、前記発信元のメディア送信装置に含まれることを特徴とする請求項１に記載の方法。
3. 更に、前記発信元のメディア送信装置において第２シーケンス番号を第２ヘッダー領域に割り当てることからなり、前記第２シーケンス番号とは前記第１優先度レベルの複数のパケットのオリジナルのシーケンス番号を示すものであり、該第２シーケンス番号は、先行する任意のネットワークセグメントからの１以上の欠損した第１優先度レベルのバケットを識別するために、最終メディア受信装置において使用されることを特徴とする請求項２に記載の方法。
4. 更に、前記発信元のメディア送信装置において第３ヘッダー領域に第３シーケンス番号を割り当てることからなり、前記第３シーケンス番号とは全てのＴＰパケットのオリジナルのシーケンス番号を示すものであり、該第３シーケンス番号は、優先度に関わらずに複数のＴＰパケットを再順番付けするために使用されることを特徴とする請求項２又は３に記載の方法。
5. 前記発信元のメディア送信装置は、メディア中継エンドポイント（ＭＲＥ）により生成されたメディアを圧縮する前記ＳＣエンコーダを持つエンドポイント又は前記ＭＲＥを備えることを特徴とする請求項２乃至４の何れかに記載の方法。
6. 前記発信元のメディア送信装置は、マルチポイント制御ユニット（ＭＣＵ）を備え、前記ＳＣエンコーダが複数のエンドポイントから受信された複数のビデオ画像に基づく常駐表示（ＣＰ）ビデオ画像をエンコードすることを特徴とする請求項２乃至４の何れかに記載の方法。
7. 前記第１優先度レベルは前記第２優先度レベルよりも優先度が高いことを特徴とする請求項１乃至６の何れかに記載の方法。
   
8. 更に、
   ソース再送信バッファに１以上の送信されたＴＰパケットを記憶することと、
   或る受信装置から特定のＴＰパケットの再送信要求を受信することと、
   前記特定のＴＰパケットを求めてソース再送信バッファを探すことと、
   前記要求に応じて前記受信装置に前記特定のＴＰパケットを再送信すること
   からなることを特徴とする請求項１乃至７の何れかに記載の方法。
9. 前記第１優先度レベルを持つ複数のＴＰパケットのみが前記ソース再送信バッファに記憶されることを特徴とする請求項８に記載の方法。
10. 常駐表示（ＣＰ）ビデオ画像を表示するために、複数のＴＰパケットを受信するエンドポイントから、前記再送信要求が受信されることを特徴とする請求項８に記載の方法。
11. 更に、前記特定のＴＰパケットが前記ソース再送信バッファに見つからなかった場合に、前記発信元のメディア送信装置から、１つのイントラフレームを要求することからなることを特徴とする請求項８乃至１０の何れかに記載の方法。
12. 前記ＳＣエンコーダは、時間的スケーラビリティを含むスケーラブル符号化エンコーディングを実行するものであることを特徴とする請求項１乃至１１の何れかに記載の方法。
13. 前記送信プロトコル（ＴＰ）はリアルタイム送信プロトコル（ＲＴＰ）からなることを特徴とする請求項１乃至１２の何れかに記載の方法。
14. 前記第１シーケンス番号は、各送信又は再送信された第１優先度レベルのＴＰパケット毎に増加されることを特徴とする請求項１乃至１３の何れかに記載の方法。
15. 前記メディア送信装置及び前記１以上のメディア受信装置はマルチポイント会議装置からなることを特徴とする請求項１乃至１４の何れかに記載の方法。
16. ネットワークインタフェースと、
    メモリと、
    前記ネットワークインタフェース及び前記メモリに通信可能に接続されたプロセッサと
    を具備するメディア送信装置であって、
    前記プロセッサが、
    前記ネットワークインタフェース経由で、前記メディア送信装置において複数の送信プロトコル（ＴＰ）パケットの第１ストリームを取得するように構成さ れ、ここで、前記複数のＴＰパケットの前記第１ストリームは、スケーラブル符号化（ＳＣ）エンコーダにより生成された圧縮データメディアユニットを搬送 し、該複数のＴＰパケットのそれぞれは、割り当てられた優先度を持つものであり、前記複数のＴＰパケットの前記第１ストリームは、少なくとも１つの第１優 先度レベルのパケットと少なくとも１つの第２優先度レベルのパケットを備えており、
    前記複数のＴＰパケットのそれぞれに対して、複数のヘッダー領域のうち第１ヘッダー領域に第１シーケンス番号を割り当てるように構成され、
    前記複数のＴＰパケットを１以上のメディア受信装置へ送信するように構成され、
    前記メディア送信装置は、発信元のメディア送信装置と最終メディア受信装置の間の中間ノードであり、
    前記第１シーケンス番号は、前記ストリームの経路中の各前記中間ノードにより、前記第１優先度レベルの各前記ＴＰパケット毎に置換され、
    前記第１シーケンス番号は、前記メディア送信装置と前記１以上のメディア受信装置から選択された第１のメディア受信装置との間の或るネットワークセグメント内で損失された１以上の欠損ＴＰパケットを識別して、該メディア送信装置に、該欠損したＴＰパケットの再送信をリクエストするために、該第１のメディア受信装置により使用可能であり、且つ、
    前記第１優先度レベルのＴＰパケットのそれぞれが、ベースレイヤのフレームの圧縮ビデオデータを表す
    ことを特徴とするメディア送信装置。
17. メディア送信装置のプロセッサに、請求項１乃１５のいずれかの方法を実行させるためのプログラム。

Images