データフローレートの変動を管理する方法
本発明はＨ．３２３のエンドポイントが最初協定したより多くのビデオ又は他のデータを送信している時データの作りすぎを検出し、標準フロー制御手順を使うことにより、それに、より少なく作らせる方法を開示する。フロー制御メッセージが周期的に送信され、該エンドポイントから受信されたビデオレートが該最初協定されたレート又は何等かの他の固定レート以下になるまで、より低い量のビットレートを送信するよう該Ｈ．３２３エンドポイントにインクレメント式に（ｉｎｃｒｅｍｅｎｔａｌｌｙ）命ずる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はビデオ会議システム（ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｉｎｇ ｓｙｓｔｅｍ）のフロー制御（ｆｌｏｗ ｃｏｎｔｒｏｌ）に関する。
【背景技術】
【０００２】
ビデオ会議システムは従来、回線交換（ｃｉｒｃｕｉｔ ｓｗｉｔｃｈｅｄ）、及びパケット交換（ｐａｃｋｅｔ ｓｗｉｔｃｈｅｄ）、の両方のネットワークを使うよう調整されている。かくして、質的損失（ｌｏｓｓ ｏｆ ｑｕａｌｉｔｙ）又は遅延の導入無しに対話と通信（ｉｎｔｅｒａｃｔｉｏｎ ａｎｄ ｃｏｍｍｕｎｉｃａｔｉｏｎ）を可能にする回線交換及びパケット交換の両ターミナル間の相互操作性（ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）を達成するため大きな努力が払われて来た。ＩＳＤＮの様な回線交換ネットワーク上でのマルチメディア通信用の共通の標準は国際電気通信連合（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）｛アイテーユー（ＩＴＵ）｝からのＨ．３２０標準（ｓｔａｎｄａｒｄ）である。パケット交換用の対応する標準はＨ．３２３である。本発明はパケット交換に関連する課題であるフロー制御に関するので、Ｈ．３２３により密接した検討が下記で行われる。
【０００３】
既述の様に、Ｈ．３２３は国際電気通信連合（ＩＴＵ）からの包括的勧告（ｕｍｂｒｅｌｌａ ｒｅｃｏｍｍｅｎｄａｔｉｏｎ）であり、それはパケット交換ネットワーク上でマルチメディア通信（ｍｕｌｔｉｍｅｄｉａ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）用の標準を設定しているが、それは保証されたサービス品質（ｇｕａｒａｎｔｅｅｄ Ｑｕａｌｉｔｙ ａｎｄ Ｓｅｒｖｉｃｅｓ）を提供するものではない。この様なネットワークは多くの共同ターミナル（ｃｏｒｐｏｒａｔｅ ｔｅｒｍｉｎａｌｓ）上に拡がり（ｐｅｒｖａｓｉｖｅ）、イーサーネット上のテーシーピー／アイピー（ＴＣＰ／ＩＰ）及びアイピーエックス（ＩＰＸ）、高速イーサーネット（Ｆａｓｔ Ｅｔｈｅｒｎｅｔ）そしてトークンリング（Ｔｏｋｅｎ Ｒｉｎｇ）ネットワーク技術を含んでいる。パケットベースのマルチメディア通信システム（Ｐａｃｋｅ−Ｂａｓｅｄ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）と名付けられる該Ｈ．３２３標準は、インターネットを含むアイピーベースのネットワーク（ＩＰ−ｂａｓｅｄ ｎｅｔｗｏｒｋ）に亘るオーディオ、ビデオ、そしてデータ通信用の基礎を提供する。該Ｈ．３２３に適合するマルチメディアの製品及び応用は相互操作可能（ｉｎｔｅｒｏｐｅｒａｂｌｅ）であり、相互に通信出来て、かくして互換性がある（ｃｏｍｐａｔｉｂｌｅ）。多くのサブ標準（ｓｕｂ ｓｔａｎｄａｒｄ）が該Ｈ．３２３標準又はプロトコルを構成し、その１つはＨ．２４５標準である。
【０００４】
該Ｈ．２４５標準は該Ｈ．３２３標準の制御プロトコル部分（ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ ｐａｒｔ）を規定する。このプロトコルに依れば、コール（ｃａｌｌ）中にフローレート（ｆｌｏｗ ｒａｔｅ）を変える幾つかの方法がある。最もローバストな方法は送信ターミナルにｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄを送信することである。該ｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄは、フィールド（ｆｉｅｌｄｓ）であるｌｏｇｉｃａｌＣｈａｎｎｅｌＮｕｍｂｅｒ及びｍａｘｉｍｕｍＢｉｔＲａｔｅを有する。該ｍａｘｉｍｕｍＢｉｔＲａｔｅは該論理チャンネル用の許される最大ビットレート（ｍａｘｉｍｕｍ ａｌｌｏｗｅｄ ｂｉｔ ｒａｔｅ ｆｏｒ ｔｈｅ ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ）を指示する。該メッセージは拒絶可能（ｒｅｊｅｃｔａｂｌｅ）でなく、すなわちターミナルは該メッセージ受信後より高いレートで送信することは許されない。該ｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄは、もし無ければ（ｉ．ａ．）、ターミナル間で協定された最大データレートを初期に設定するため使われる。該ビットレートを変える代わ
りの方法は論値チャンネルビットレートメッセージフロー（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ ｂｉｔ ｒａｔｅ ｍｅｓｓａｇｅｓ ｆｌｏｗ）を使うことである。図解する目的で、エンドポイント（Ｅｎｄｐｏｉｎｔ）から送信されたフローレートを変えるために論理チャンネルビットレートメッセージを使うゲートウエイを考えよう。ＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージは該ゲートウエイから該エンドポイントへ送信される。該メッセージは、論理チャンネル用の要求される最大ビットレートを、１００ビット／秒の単位で指示するｍａｘｉｍｕｍＢｉｔｒａｔｅに加えて、該ビットレート変更要求が適用される論理チャンネルを指示するｌｏｇｉｃａｌＣｈａｎｎｅｌＮｕｍｂｅｒを含んでいる。該エンドポイントは、前に受信したＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージに於けると同じパラメーターを含むＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＡｃｋｎｏｗｌｅｄｇｅメッセージを返すことにより、該指定されたチャンネルのデータレート変更用の要求を承認し肯定（ａｃｋｎｏｗｌｅｄｇｅｓ）する。代わりに、もし該エンドポイントが何等かの理由で該要求された変更を受け入れないならば、該ＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージは、何故該要求が否定されたかの理由を示すｒｅｊｅｃｔＲｅａｓｏｎを含むＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｊｅｃｔにより応答される。
【０００５】
Ｈ．３２３への代わりのプロトコルはＳＩＰ｛セションイニシエーションプロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）｝プロトコルである。現在のＳＩＰ標準では、コール中にフローレートを変えることは該エンドポイントへＲｅＩｎｖｉｔｅメッセージを送信することにより行われる。該ＲｅＩｎｖｉｔｅメッセージはＩｎｖｉｔｅメッセージと同じ情報を担っており、コールセットアップ（ｃａｌｌ ｓｅｔ
ｕｐ）で使われる、いわゆる、ＣａｐＳｅｔを含んでいる。かくして、ＲｅＩｎｖｉｔｅメッセージも又最大の許されるビットレートを含み、その結果、他のデータを変えないで置きながら新しい最大の許されるデータレートを有するＲｅＩｎｖｉｔｅメッセージを送信することはＨ．３２３の該ｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄと同じ結果を有するであろう。
【０００６】
ゲートウェイはマルチメディア会議のエンドポイント間の通信路の、ＩＰ側と回線交換側の間の接続を提供する。該ＩＰ側に定在するエンドポイントから見ると、該回線交換側のエンドポイントはＩＰエンドポイントへ仮想的に変換されており、その逆も起こる。該ゲートウェイの主な課題は結果的にネットワークに亘るデータストリーム（ｄａｔａ ｓｔｒｅａｍ）を実時間で翻訳し、パックし直し（ｒｅ−ｐａｃｋ）することである。該Ｈ．３２３エンドポイントから送信されるパケットはそれらがフエッチ（ｆｅｔｃｈｅｄ）される前に、バッフアー内に１時的に蓄積され、固定サイズのＨ．３２０フレーム内に配置される。
【０００７】
該ゲートウェイ内のＨ．３２３からＨ．３２０への翻訳過程は、アールエフシー（ＲＦＣ）２０３２｛アールテーピー（ＲＴＰ）上のＨ．２６１｝，アールエフシー２１９０（アールテーピー上のＨ．２６３）そしてアールエフシー２４２９（アールテーピー上のＨ．２６３＋）により指定されたパケットから生ビデオデータ（ｒａｗ ｖｉｄｅｏ ｄａｔａ）を抽出（ｅｘｔｒａｃｔｉｎｇ）し、この生データをいわゆるビーシーエイチ（ＢＣＨ）エンコーダーへ送ることにより達成される。
【０００８】
Ｈ．３２０からＨ．３２３へ反対方向に翻訳する時、その過程は遙かにより複雑であり、何故ならば上述のアールエフシーで説明されたパケット化スキーム（ｐａｃｋｅｔｉｚａｔｉｏｎ ｓｃｈｅｍｅｓ）はどこでパケット分割（ｐａｃｋｅｔ ｓｐｌｉｔ）が行われるかについて厳格な規則を有するからである。特にパケット分割は映像（ｐｉｃｔｕｒｅ）、ブロックのグループ（Ｇｒｏｕｐ ｏｆ Ｂｌｏｃｋ）（ＧＯＢ）及びマクロブロック（Ｍａｃｒｏ Ｂｌｏｃｋ）（ＭＢ）レベルで許される。分割を映像及びＧＯＢレ
ベルで発生させることが最も望ましく、何故ならばＭＢレベルでの分割は、該ビデオデータと一緒に幾らかのビデオデコーダーステイト情報（ｖｉｄｅｏ ｄｅｃｏｄｅｒ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ）を送信する必要による幾らかの付随オーバーヘッドを有するからである。
【０００９】
従来の実施例（ｃｏｎｖｅｎｔｉｏｎａｌ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）はビデオストリーム（ｖｉｄｅｏ ｓｔｒｅａｍ）の中でブロックのグループの位置と長さを決定するために可変長さデコーデイング（ｖａｒｉａｂｌｅ ｌｅｎｇｔｈ ｄｅｃｏｄｉｎｇ）を使う。ＧＯＢを見出した時、下記のアクションの１つを選ぶために該ＧＯＢ内のビット数（ａ）、現在のパケット内の利用可能ビット数（ｂ）、そして最大パケットサイズ（ｃ）を使うことにより対応するビットを処理する：
・もしａ＜＝ｂなら、該ＧＯＢを現在のパケットに付属させる
・もしａ＞ｂそしてａ＜＝ｃなら現在のパケットを送信し、該ＧＯＢを新しいパケットに付属させる
・もしａ＞ｂそしてａ＞ｃなら、現在のパケットを送信し、より最適さの低いマクロブロックレベルパケット化（ｌｅｓｓ ｏｐｔｉｍａｌ ｍａｃｒｏｂｌｏｃｋ ｌｅｖｅｌ ｐａｃｋｅｔｉｚａｔｉｏｎ）を使って該ＧＯＢを送信する。
【００１０】
これらの３つの規則は、可能な場合には幾つかのＧＯＢを１つのパケット内に組み合わせながら、もし可能ならパケット内の全ＧＯＢを適合させるようパケット化を最適化する。これは望ましく、何故ならばＧＯＢを整合されたパケットはより少ないオーバーヘッドを有し、少ない大型パケットは多数の小型パケットより少ない処理オーバーヘッドしか要しないからである。
【００１１】
上記規則に加えて、映像内の最後のＧＯＢがパケットに付加されると、複数パケットも送信される。この付加規則（ａｄｄｉｔｉｏｎａｌ ｒｕｌｅ）はそのゲートウエイが欲しない遅延を蓄積することを防止する。
【００１２】
ゲートウェイユニット内で一緒に接続されたＨ．３２３エンドポイントとＨ．３２０エンドポイントとは、該Ｈ．３２０プロトコルがそれをサポートしないので、エンドツーエンドフロー制御（ｅｎｄ−ｔｏ−ｅｎｄ ｆｌｏｗ ｃｏｎｔｒｏｌ）を使うことは出来ない。しかしながら、該ゲートウェイと該Ｈ．３２３エンドポイントの間ではフロー制御が使われ得る。例えば、ポリコム（Ｐｏｌｙｃｏｍ）及びエゼニア（Ｅｚｅｎｉａ）からの公知のＨ３２０／Ｈ３２３ゲートウェイ内の典型的シナリオは、該ゲートウェイが、作られたビデオデータレートを、該ゲートウェイから出て行くＨ．３２０接続内の利用可能な容量に調整するために、フロー制御メッセージを該Ｈ．３２３エンドポイントへ送信することである。該Ｈ．３２０プロトコルは簡単にこれをサポートしないので、該Ｈ．３２０エンドポイントをフロー制御することは出来ない。これは該Ｈ．３２０が該Ｈ．３２３エンドポイントがサポートするより多くのビデオを作ることが出来ることを意味する。該ゲートウェイから該Ｈ．３２３エンドポイントへのフロー制御メッセージのみが何等かの効果を有するであろう。該効果は該Ｈ．３２３エンドポイント内のフロー制御サポートに左右されよう。
【００１３】
該Ｈ．３２３エンドポイントが何かの理由で該フロー制御により始動されたよりも高いビットレートで該ゲートウェイにデータを送信することをスタートすると問題が起こる。これは、該エンドポイント内の欠陥、データ設定の消失（ｌｏｓｓ ｏｆ ｄａｔａ ｓｅｔｔｉｎｇｓ）又はドリフトする又は正しくないウオールクロック（ｗａｌｌ ｃｌｏｃｋ）、のために起こる。その時該ゲートウェイは、バッフアーが充たされる程速くＨ．３２０フレームへデータを取り込むことは出来ない。最初の場合、これは、ペイロード（ｐａｙｌｏａｄ）が該バッフアー内でより長い時間を費やすので、データ送信での益々大
きくなる遅延を意味し、それはビデオ会議の様な実時間的応用では重大（ｃｒｕｃｉａｌ）である。加えて、或る点で、該バッフアーの上方充填限界（ｕｐｐｅｒ ｆｉｌｌ ｌｉｍｉｔ）に到達するであろう。該上方充填限界に到達すると、該ゲートウェイは次に入って来るデータを拒絶する他に選択はない。この結果は不在映像アーチフアクト（ｉ．ａ． ｐｉｃｔｕｒｅ ａｒｔｅｆａｃｔｓ）として該Ｈ．３２０エンドポイントのユーザー用に出現するデータの消失となる。
【発明の開示】
【課題を解決するための手段】
【００１４】
ここに同封された独立請求項で規定された特徴がこの配置と方法を特徴付ける。
【００１５】
特に、本発明は、第１のパケット交換のＨ．３２３又はＳＩＰ構成のビデオ会議ターミナルから送信され、第２のパケット交換のＨ．３２３又はＳＩＰ構成のビデオ会議ターミナルで受信されるデータのフローレートを調整し、更に進んだ処理用に取り込まれる前に該第２パケット交換ビデオ会議ターミナル内の１つ以上のバッフアー内の該受信されたデータを１時的に蓄積する、方法を開示しており、該方法は更に、前記１つ以上のバッフアーからの各データ取り込みの後に、下記過程、すなわち、該１つ以上のバッフアーの充填レベル（ｆｉｌｌ ｌｅｖｅｌ）を予め規定されたレベルと比較し、もし前記充填レベルが前記予め規定されたレベルより低ければ、カウンターをリセットし、もし前記充填レベルが前記予め規定されたレベルより高ければ、前記カウンターをインクレメントし、そして前記カウンターを予め規定されたカウンターリミット（ｃｏｕｎｔｅｒ ｌｉｍｉｔ）と比較し、もし前記カウンターが前記予め規定されたカウンターリミットより大きければ、前記カウンターをリセットし、そして該第２から該第１のパケット交換ターミナルへフロー制御メッセージを送信するが、該第１のパケット交換ターミナルに、前記フロー制御メッセージに含まれたフローレート値により該フローレートを減ずるよう命ずる該メッセージを送信することにより該送信されるデータのフローレートを減ずる過程、を具備している。
【実施例１】
【００１６】
本発明を実施する最良モード
下記では、本発明は好ましい実施例を説明し、付属する図面を参照することにより論じられる。しかしながら、当業者はここに含まれる独立請求項に規定された本発明の範囲内で他の応用と変型を実現するであろう。
【００１７】
本発明は、例えばＨ．３２３のエンドポイントが初期に協定した（ｎｅｇｏｔｉａｔｅｄ）ものより多いビデオ又は他のデータを送信している時、データの作りすぎ（ｏｖｅｒｐｒｏｄｕｃｔｉｏｎ）の検出を自動的に提供し、データレート変更又は他のフロー制御機構用の上記説明のメッセージフロー（ｍｅｓｓａｇｅ ｆｌｏｗ）を利用することにより、それがより少なく作るようにさせる。Ｈ．３２３の場合、該エンドポイントから受信されるビデオレートが初期に協定されたレート、又は何等かの他の固定レート（ｆｉｘｅｄ ｒａｔｅ）以下になるまで、ｍａｘｉｍｕｍＢｉｔｒａｔｅのインクレメント式に（ｉｎｃｒｅｍｅｎｔａｌｌｙ）より低い量を有するｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄ又はＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージが当該のエンドポイントへ周期的に送信される。
【００１８】
本発明の方法はゲートウェイで特に有用である。ビデオデータの作りすぎは、受け入れバッフアー（ｉｎｃｏｍｉｎｇ ｂｕｆｆｅｒ）内のデータの量を周期的に観察することによりゲートウェイ内で検出される。該データ量が規定された時間で或る限界より多ければ、該エンドポイントは作りすぎしつつありと考えられる。該バッフアー用のデータリミットは出て行く（ｏｕｔｇｏｉｎｇ）Ｈ．３２０ビデオレートに比例して設定されるのが
好ましい。
【００１９】
作りすぎが検出された時、新しいｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄ又はＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージが該Ｈ．３２３エンドポイントへ送信される。それで該ビットレートは一定量減じられる。該リミットを超えるバッフアーレベルを観察するための時間（ｔｉｍｅ−ｐｅｒｉｏｄ）は予め規定されるべきである。
【００２０】
本発明の好ましい実施例がここで図１のフローシートを参照して説明される。関心のあるデータフローはＨ．３２３エンドポイントからＨ３２０／Ｈ３２３ゲートウェイへ送信されるビデオデータである。該ゲートウェイは入って来るビデオデータのペイロードを一定量のビデオデータを担うことが出来る１０ｍｓ持続時間のＨ．３２０フレームへとパックし直し（ｒｅｐａｃｋｉｎｇ）する。かくして１０ｍｓの間隔で（ａｔ ｉｎｔｅｒｖａｌ ｏｆ １０ｍｓ）、該ビデオのパックし直し部（ｒｅ−ｐａｃｋｅｒ）は１０ｍｓ（Ｈ．２２１）フレーム内へ填め込むようデータを作ることを求められる。カウンターは、該バッフアーの充填レベルが予め規定されたレベルの下になった最終の時から、該バッフアーからのデータ取り込みイベントの数を追跡し続ける。
【００２１】
該パックし直し部がＨ．２２１フレーム用データを作った後、該エンドポイント用に入って来るビデオデータを１時的に蓄積するビデオバッフアーの充填レベルを示すｂｕｆｆｅｒ＿ｌｅｖｅｌがチェックされる。もしｂｕｆｆｅｒ＿ｌｅｖｅｌが予め規定されたＭａｘ＿Ｌｅｖｅｌの下にあるならば、該カウンターはリセットされ、該手順は該パックし直し部がもう１つのＨ．２２１フレーム用に新データを作るのを待つが、もしそうでないなら、該カウンターはインクレントされる。この例では、Ｍａｘ＿ｌｅｖｅｌは１０ｍｓのＨ．２２１フレーム内のビデオデータの最大量である。
【００２２】
次いで該カウンター自身が調べられ、そして、もしそれが予め規定されたＯｖｅｒｐｒｏ＿Ｌｅｖｅｌの下にあれば、該手順は該パックし直し部がもう１つのＨ．２２１フレーム用に新データを作るのを待つ。もしそうでないなら、該Ｈ．３２３エンドポイントは作りすぎと考えられる。該カウンターはリセットされ、そして、該Ｈ．３２３エンドポイントから送信されるビデオデータのデータフローレートはそのパラメーターのＦｌｏｗ＿Ｓｔｅｐで示される予め規定された量だけ低下される。この例ではＦｌｏｗ＿Ｓｔｅｐは１６ｋビットの定数である。該データフローレートのデクレメント動作（ｄｅｃｒｅｍｅｎｔｉｎｇ）は、現在のフローレートマイナスＦｌｏｗ＿ＳｔｅｐのｍａｘｉｍｕｍＢｉｔｒａｔｅを含むｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄ又はｌｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージと、ビデオデータの論理チャンネルを示すｌｏｇｉｃａｌＣｈａｎｎｅｌＮｕｍｂｅｒと、を送信することにより行われる。しかしながら、デクレメント動作が起こる前に、該現在のフローレートマイナスＦｌｏｗ＿Ｓｔｅｐが予め規定されたＦｌｏｗ＿Ｍｉｎより低いかどうかをチェックせねばならない。もしそうであれば、該デクレメント動作はバイパスされ、該手順は該パックし直し部がもう１つのＨ．２２１フレーム用に新データを作るのを待つ。この理由は該Ｈ．３２３エンドポイントから送信される現実のビデオデータレートがゼロにセットされることを確認することである。
【００２３】
例えば、該フローレートの過大な削減（ｏｖｅｒｓｉｚｅｄ ｒｅｄｕｃｔｉｏｎ）をトリガーするデータバーストを避けるために、データバーストをもたらす少なくとも最も普通なイベント（ａｔ ｌｅａｓｔ ｔｈｅ ｍｏｓｔ ｃｏｍｍｏｎ ｅｖｅｎｔｓ ｐｒｏｄｕｃｉｎｇ ｄａｔａ ｂｕｒｓｔ）を中断（ｉｎｔｅｒｃｅｐｔｉｎｇ）させる機構が好ましくは導入されるべきである。例として、エンドポイントが種々のコールレートを有するＨ．３２３会議コールの場合（ｔｈｅ ｃａｓｅ ｏｆ ａ Ｈ．３２３
ｃｏｎｆｅｒｅｎｃｅ ｃａｌｌ ｗｈｅｒｅ ｔｈｅ ｅｎｄｐｏｉｎｔｓ ｈａｖｅ
ｄｉｆｆｅｒｅｎｔ ｃａｌｌ ｒａｔｅｓ）を考える。最も低いコールレートを有するエンドポイントが最初に、他のエンドポイントへそれらに該低いレートで作らせる（ｔｏ ｍａｋｅ ｔｈｅｍ ｐｒｏｄｕｃｅ ａｔ ｔｈｅ ｌｏｗ ｒａｔｅ）ようフロー制御メッセージを送信する。しかしながら、これは短期間の作りすぎを妨げないであろう。このスタートのバーストは本発明のオーバーフロー検出機構をトリガーし、必要より多くフローレートを減ずる。これを避けるために、該ゲートウェイは常に、ビデオチャンネルが開いた後規定された時間間隔だけ、該フローレートを該出て行くＨ．３２０レートまで増加させるよう構成されることが出来る。
【００２４】
本発明は該フロー制御始動されたレートに対してより多くのビデオデータ（又は他のマルチメデイアデータ）を一貫して作るＨ．３２３エンドポイント（又は同様な標準に調整されたエンドポイント）を取り扱う。
【００２５】
換言すれば、本発明はゲートウェイに、バッフアー溢れ（ｂｕｆｆｅｒ ｏｖｅｒｆｌｏｗ）とデータ消失を防止しつつ一貫して作りすぎするＨ．３２３エンドポイントと共に作動するようにさせる。この方法では、遅延と映像アーチフアクトの形成（ｂｕｉｌｄ ｕｐｓ）は、避けられるか又は大いに減じられる。
【００２６】
本発明はエンドポイントとゲートウェイの間のフロー制御だけに限定されず、エンドからエンドの背景で（ｅｎｄ−ｔｏ−ｅｎｄ ｃｏｎｔｅｘｔ）又はエムシーユー（ＭＣＵ）とエンドポイントの間でも同様に利用されてもよい。本発明はＨ．３２３標準に限定されず、それは他の同様な標準、例えば、ＳＩＰ標準に関連しても有用であり得る。ＳＩＰ標準の場合、Ｈ．３２３に関しての説明で使われたｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄは背景のセクションで説明されたＲｅＩｎｖｉｔｅメッセージと置き換えられる。本発明はフロー制御用に使われる該ＳＩＰ及びＨ．３２３標準の将来版の何等かのメッセージ又は方法用にも適用される。
【００２７】
本発明をより容易に理解可能にするために、行われる論議は付属する図面を参照する。
【図面の簡単な説明】
【００２８】
【図１】本発明の好ましい実施例を図解するフローシートである。
【技術分野】
【０００１】
本発明はビデオ会議システム（ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｉｎｇ ｓｙｓｔｅｍ）のフロー制御（ｆｌｏｗ ｃｏｎｔｒｏｌ）に関する。
【背景技術】
【０００２】
ビデオ会議システムは従来、回線交換（ｃｉｒｃｕｉｔ ｓｗｉｔｃｈｅｄ）、及びパケット交換（ｐａｃｋｅｔ ｓｗｉｔｃｈｅｄ）、の両方のネットワークを使うよう調整されている。かくして、質的損失（ｌｏｓｓ ｏｆ ｑｕａｌｉｔｙ）又は遅延の導入無しに対話と通信（ｉｎｔｅｒａｃｔｉｏｎ ａｎｄ ｃｏｍｍｕｎｉｃａｔｉｏｎ）を可能にする回線交換及びパケット交換の両ターミナル間の相互操作性（ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）を達成するため大きな努力が払われて来た。ＩＳＤＮの様な回線交換ネットワーク上でのマルチメディア通信用の共通の標準は国際電気通信連合（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）｛アイテーユー（ＩＴＵ）｝からのＨ．３２０標準（ｓｔａｎｄａｒｄ）である。パケット交換用の対応する標準はＨ．３２３である。本発明はパケット交換に関連する課題であるフロー制御に関するので、Ｈ．３２３により密接した検討が下記で行われる。
【０００３】
既述の様に、Ｈ．３２３は国際電気通信連合（ＩＴＵ）からの包括的勧告（ｕｍｂｒｅｌｌａ ｒｅｃｏｍｍｅｎｄａｔｉｏｎ）であり、それはパケット交換ネットワーク上でマルチメディア通信（ｍｕｌｔｉｍｅｄｉａ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）用の標準を設定しているが、それは保証されたサービス品質（ｇｕａｒａｎｔｅｅｄ Ｑｕａｌｉｔｙ ａｎｄ Ｓｅｒｖｉｃｅｓ）を提供するものではない。この様なネットワークは多くの共同ターミナル（ｃｏｒｐｏｒａｔｅ ｔｅｒｍｉｎａｌｓ）上に拡がり（ｐｅｒｖａｓｉｖｅ）、イーサーネット上のテーシーピー／アイピー（ＴＣＰ／ＩＰ）及びアイピーエックス（ＩＰＸ）、高速イーサーネット（Ｆａｓｔ Ｅｔｈｅｒｎｅｔ）そしてトークンリング（Ｔｏｋｅｎ Ｒｉｎｇ）ネットワーク技術を含んでいる。パケットベースのマルチメディア通信システム（Ｐａｃｋｅ−Ｂａｓｅｄ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）と名付けられる該Ｈ．３２３標準は、インターネットを含むアイピーベースのネットワーク（ＩＰ−ｂａｓｅｄ ｎｅｔｗｏｒｋ）に亘るオーディオ、ビデオ、そしてデータ通信用の基礎を提供する。該Ｈ．３２３に適合するマルチメディアの製品及び応用は相互操作可能（ｉｎｔｅｒｏｐｅｒａｂｌｅ）であり、相互に通信出来て、かくして互換性がある（ｃｏｍｐａｔｉｂｌｅ）。多くのサブ標準（ｓｕｂ ｓｔａｎｄａｒｄ）が該Ｈ．３２３標準又はプロトコルを構成し、その１つはＨ．２４５標準である。
【０００４】
該Ｈ．２４５標準は該Ｈ．３２３標準の制御プロトコル部分（ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ ｐａｒｔ）を規定する。このプロトコルに依れば、コール（ｃａｌｌ）中にフローレート（ｆｌｏｗ ｒａｔｅ）を変える幾つかの方法がある。最もローバストな方法は送信ターミナルにｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄを送信することである。該ｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄは、フィールド（ｆｉｅｌｄｓ）であるｌｏｇｉｃａｌＣｈａｎｎｅｌＮｕｍｂｅｒ及びｍａｘｉｍｕｍＢｉｔＲａｔｅを有する。該ｍａｘｉｍｕｍＢｉｔＲａｔｅは該論理チャンネル用の許される最大ビットレート（ｍａｘｉｍｕｍ ａｌｌｏｗｅｄ ｂｉｔ ｒａｔｅ ｆｏｒ ｔｈｅ ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ）を指示する。該メッセージは拒絶可能（ｒｅｊｅｃｔａｂｌｅ）でなく、すなわちターミナルは該メッセージ受信後より高いレートで送信することは許されない。該ｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄは、もし無ければ（ｉ．ａ．）、ターミナル間で協定された最大データレートを初期に設定するため使われる。該ビットレートを変える代わ
りの方法は論値チャンネルビットレートメッセージフロー（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ ｂｉｔ ｒａｔｅ ｍｅｓｓａｇｅｓ ｆｌｏｗ）を使うことである。図解する目的で、エンドポイント（Ｅｎｄｐｏｉｎｔ）から送信されたフローレートを変えるために論理チャンネルビットレートメッセージを使うゲートウエイを考えよう。ＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージは該ゲートウエイから該エンドポイントへ送信される。該メッセージは、論理チャンネル用の要求される最大ビットレートを、１００ビット／秒の単位で指示するｍａｘｉｍｕｍＢｉｔｒａｔｅに加えて、該ビットレート変更要求が適用される論理チャンネルを指示するｌｏｇｉｃａｌＣｈａｎｎｅｌＮｕｍｂｅｒを含んでいる。該エンドポイントは、前に受信したＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージに於けると同じパラメーターを含むＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＡｃｋｎｏｗｌｅｄｇｅメッセージを返すことにより、該指定されたチャンネルのデータレート変更用の要求を承認し肯定（ａｃｋｎｏｗｌｅｄｇｅｓ）する。代わりに、もし該エンドポイントが何等かの理由で該要求された変更を受け入れないならば、該ＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージは、何故該要求が否定されたかの理由を示すｒｅｊｅｃｔＲｅａｓｏｎを含むＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｊｅｃｔにより応答される。
【０００５】
Ｈ．３２３への代わりのプロトコルはＳＩＰ｛セションイニシエーションプロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）｝プロトコルである。現在のＳＩＰ標準では、コール中にフローレートを変えることは該エンドポイントへＲｅＩｎｖｉｔｅメッセージを送信することにより行われる。該ＲｅＩｎｖｉｔｅメッセージはＩｎｖｉｔｅメッセージと同じ情報を担っており、コールセットアップ（ｃａｌｌ ｓｅｔ
ｕｐ）で使われる、いわゆる、ＣａｐＳｅｔを含んでいる。かくして、ＲｅＩｎｖｉｔｅメッセージも又最大の許されるビットレートを含み、その結果、他のデータを変えないで置きながら新しい最大の許されるデータレートを有するＲｅＩｎｖｉｔｅメッセージを送信することはＨ．３２３の該ｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄと同じ結果を有するであろう。
【０００６】
ゲートウェイはマルチメディア会議のエンドポイント間の通信路の、ＩＰ側と回線交換側の間の接続を提供する。該ＩＰ側に定在するエンドポイントから見ると、該回線交換側のエンドポイントはＩＰエンドポイントへ仮想的に変換されており、その逆も起こる。該ゲートウェイの主な課題は結果的にネットワークに亘るデータストリーム（ｄａｔａ ｓｔｒｅａｍ）を実時間で翻訳し、パックし直し（ｒｅ−ｐａｃｋ）することである。該Ｈ．３２３エンドポイントから送信されるパケットはそれらがフエッチ（ｆｅｔｃｈｅｄ）される前に、バッフアー内に１時的に蓄積され、固定サイズのＨ．３２０フレーム内に配置される。
【０００７】
該ゲートウェイ内のＨ．３２３からＨ．３２０への翻訳過程は、アールエフシー（ＲＦＣ）２０３２｛アールテーピー（ＲＴＰ）上のＨ．２６１｝，アールエフシー２１９０（アールテーピー上のＨ．２６３）そしてアールエフシー２４２９（アールテーピー上のＨ．２６３＋）により指定されたパケットから生ビデオデータ（ｒａｗ ｖｉｄｅｏ ｄａｔａ）を抽出（ｅｘｔｒａｃｔｉｎｇ）し、この生データをいわゆるビーシーエイチ（ＢＣＨ）エンコーダーへ送ることにより達成される。
【０００８】
Ｈ．３２０からＨ．３２３へ反対方向に翻訳する時、その過程は遙かにより複雑であり、何故ならば上述のアールエフシーで説明されたパケット化スキーム（ｐａｃｋｅｔｉｚａｔｉｏｎ ｓｃｈｅｍｅｓ）はどこでパケット分割（ｐａｃｋｅｔ ｓｐｌｉｔ）が行われるかについて厳格な規則を有するからである。特にパケット分割は映像（ｐｉｃｔｕｒｅ）、ブロックのグループ（Ｇｒｏｕｐ ｏｆ Ｂｌｏｃｋ）（ＧＯＢ）及びマクロブロック（Ｍａｃｒｏ Ｂｌｏｃｋ）（ＭＢ）レベルで許される。分割を映像及びＧＯＢレ
ベルで発生させることが最も望ましく、何故ならばＭＢレベルでの分割は、該ビデオデータと一緒に幾らかのビデオデコーダーステイト情報（ｖｉｄｅｏ ｄｅｃｏｄｅｒ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ）を送信する必要による幾らかの付随オーバーヘッドを有するからである。
【０００９】
従来の実施例（ｃｏｎｖｅｎｔｉｏｎａｌ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）はビデオストリーム（ｖｉｄｅｏ ｓｔｒｅａｍ）の中でブロックのグループの位置と長さを決定するために可変長さデコーデイング（ｖａｒｉａｂｌｅ ｌｅｎｇｔｈ ｄｅｃｏｄｉｎｇ）を使う。ＧＯＢを見出した時、下記のアクションの１つを選ぶために該ＧＯＢ内のビット数（ａ）、現在のパケット内の利用可能ビット数（ｂ）、そして最大パケットサイズ（ｃ）を使うことにより対応するビットを処理する：
・もしａ＜＝ｂなら、該ＧＯＢを現在のパケットに付属させる
・もしａ＞ｂそしてａ＜＝ｃなら現在のパケットを送信し、該ＧＯＢを新しいパケットに付属させる
・もしａ＞ｂそしてａ＞ｃなら、現在のパケットを送信し、より最適さの低いマクロブロックレベルパケット化（ｌｅｓｓ ｏｐｔｉｍａｌ ｍａｃｒｏｂｌｏｃｋ ｌｅｖｅｌ ｐａｃｋｅｔｉｚａｔｉｏｎ）を使って該ＧＯＢを送信する。
【００１０】
これらの３つの規則は、可能な場合には幾つかのＧＯＢを１つのパケット内に組み合わせながら、もし可能ならパケット内の全ＧＯＢを適合させるようパケット化を最適化する。これは望ましく、何故ならばＧＯＢを整合されたパケットはより少ないオーバーヘッドを有し、少ない大型パケットは多数の小型パケットより少ない処理オーバーヘッドしか要しないからである。
【００１１】
上記規則に加えて、映像内の最後のＧＯＢがパケットに付加されると、複数パケットも送信される。この付加規則（ａｄｄｉｔｉｏｎａｌ ｒｕｌｅ）はそのゲートウエイが欲しない遅延を蓄積することを防止する。
【００１２】
ゲートウェイユニット内で一緒に接続されたＨ．３２３エンドポイントとＨ．３２０エンドポイントとは、該Ｈ．３２０プロトコルがそれをサポートしないので、エンドツーエンドフロー制御（ｅｎｄ−ｔｏ−ｅｎｄ ｆｌｏｗ ｃｏｎｔｒｏｌ）を使うことは出来ない。しかしながら、該ゲートウェイと該Ｈ．３２３エンドポイントの間ではフロー制御が使われ得る。例えば、ポリコム（Ｐｏｌｙｃｏｍ）及びエゼニア（Ｅｚｅｎｉａ）からの公知のＨ３２０／Ｈ３２３ゲートウェイ内の典型的シナリオは、該ゲートウェイが、作られたビデオデータレートを、該ゲートウェイから出て行くＨ．３２０接続内の利用可能な容量に調整するために、フロー制御メッセージを該Ｈ．３２３エンドポイントへ送信することである。該Ｈ．３２０プロトコルは簡単にこれをサポートしないので、該Ｈ．３２０エンドポイントをフロー制御することは出来ない。これは該Ｈ．３２０が該Ｈ．３２３エンドポイントがサポートするより多くのビデオを作ることが出来ることを意味する。該ゲートウェイから該Ｈ．３２３エンドポイントへのフロー制御メッセージのみが何等かの効果を有するであろう。該効果は該Ｈ．３２３エンドポイント内のフロー制御サポートに左右されよう。
【００１３】
該Ｈ．３２３エンドポイントが何かの理由で該フロー制御により始動されたよりも高いビットレートで該ゲートウェイにデータを送信することをスタートすると問題が起こる。これは、該エンドポイント内の欠陥、データ設定の消失（ｌｏｓｓ ｏｆ ｄａｔａ ｓｅｔｔｉｎｇｓ）又はドリフトする又は正しくないウオールクロック（ｗａｌｌ ｃｌｏｃｋ）、のために起こる。その時該ゲートウェイは、バッフアーが充たされる程速くＨ．３２０フレームへデータを取り込むことは出来ない。最初の場合、これは、ペイロード（ｐａｙｌｏａｄ）が該バッフアー内でより長い時間を費やすので、データ送信での益々大
きくなる遅延を意味し、それはビデオ会議の様な実時間的応用では重大（ｃｒｕｃｉａｌ）である。加えて、或る点で、該バッフアーの上方充填限界（ｕｐｐｅｒ ｆｉｌｌ ｌｉｍｉｔ）に到達するであろう。該上方充填限界に到達すると、該ゲートウェイは次に入って来るデータを拒絶する他に選択はない。この結果は不在映像アーチフアクト（ｉ．ａ． ｐｉｃｔｕｒｅ ａｒｔｅｆａｃｔｓ）として該Ｈ．３２０エンドポイントのユーザー用に出現するデータの消失となる。
【発明の開示】
【課題を解決するための手段】
【００１４】
ここに同封された独立請求項で規定された特徴がこの配置と方法を特徴付ける。
【００１５】
特に、本発明は、第１のパケット交換のＨ．３２３又はＳＩＰ構成のビデオ会議ターミナルから送信され、第２のパケット交換のＨ．３２３又はＳＩＰ構成のビデオ会議ターミナルで受信されるデータのフローレートを調整し、更に進んだ処理用に取り込まれる前に該第２パケット交換ビデオ会議ターミナル内の１つ以上のバッフアー内の該受信されたデータを１時的に蓄積する、方法を開示しており、該方法は更に、前記１つ以上のバッフアーからの各データ取り込みの後に、下記過程、すなわち、該１つ以上のバッフアーの充填レベル（ｆｉｌｌ ｌｅｖｅｌ）を予め規定されたレベルと比較し、もし前記充填レベルが前記予め規定されたレベルより低ければ、カウンターをリセットし、もし前記充填レベルが前記予め規定されたレベルより高ければ、前記カウンターをインクレメントし、そして前記カウンターを予め規定されたカウンターリミット（ｃｏｕｎｔｅｒ ｌｉｍｉｔ）と比較し、もし前記カウンターが前記予め規定されたカウンターリミットより大きければ、前記カウンターをリセットし、そして該第２から該第１のパケット交換ターミナルへフロー制御メッセージを送信するが、該第１のパケット交換ターミナルに、前記フロー制御メッセージに含まれたフローレート値により該フローレートを減ずるよう命ずる該メッセージを送信することにより該送信されるデータのフローレートを減ずる過程、を具備している。
【実施例１】
【００１６】
本発明を実施する最良モード
下記では、本発明は好ましい実施例を説明し、付属する図面を参照することにより論じられる。しかしながら、当業者はここに含まれる独立請求項に規定された本発明の範囲内で他の応用と変型を実現するであろう。
【００１７】
本発明は、例えばＨ．３２３のエンドポイントが初期に協定した（ｎｅｇｏｔｉａｔｅｄ）ものより多いビデオ又は他のデータを送信している時、データの作りすぎ（ｏｖｅｒｐｒｏｄｕｃｔｉｏｎ）の検出を自動的に提供し、データレート変更又は他のフロー制御機構用の上記説明のメッセージフロー（ｍｅｓｓａｇｅ ｆｌｏｗ）を利用することにより、それがより少なく作るようにさせる。Ｈ．３２３の場合、該エンドポイントから受信されるビデオレートが初期に協定されたレート、又は何等かの他の固定レート（ｆｉｘｅｄ ｒａｔｅ）以下になるまで、ｍａｘｉｍｕｍＢｉｔｒａｔｅのインクレメント式に（ｉｎｃｒｅｍｅｎｔａｌｌｙ）より低い量を有するｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄ又はＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージが当該のエンドポイントへ周期的に送信される。
【００１８】
本発明の方法はゲートウェイで特に有用である。ビデオデータの作りすぎは、受け入れバッフアー（ｉｎｃｏｍｉｎｇ ｂｕｆｆｅｒ）内のデータの量を周期的に観察することによりゲートウェイ内で検出される。該データ量が規定された時間で或る限界より多ければ、該エンドポイントは作りすぎしつつありと考えられる。該バッフアー用のデータリミットは出て行く（ｏｕｔｇｏｉｎｇ）Ｈ．３２０ビデオレートに比例して設定されるのが
好ましい。
【００１９】
作りすぎが検出された時、新しいｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄ又はＬｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージが該Ｈ．３２３エンドポイントへ送信される。それで該ビットレートは一定量減じられる。該リミットを超えるバッフアーレベルを観察するための時間（ｔｉｍｅ−ｐｅｒｉｏｄ）は予め規定されるべきである。
【００２０】
本発明の好ましい実施例がここで図１のフローシートを参照して説明される。関心のあるデータフローはＨ．３２３エンドポイントからＨ３２０／Ｈ３２３ゲートウェイへ送信されるビデオデータである。該ゲートウェイは入って来るビデオデータのペイロードを一定量のビデオデータを担うことが出来る１０ｍｓ持続時間のＨ．３２０フレームへとパックし直し（ｒｅｐａｃｋｉｎｇ）する。かくして１０ｍｓの間隔で（ａｔ ｉｎｔｅｒｖａｌ ｏｆ １０ｍｓ）、該ビデオのパックし直し部（ｒｅ−ｐａｃｋｅｒ）は１０ｍｓ（Ｈ．２２１）フレーム内へ填め込むようデータを作ることを求められる。カウンターは、該バッフアーの充填レベルが予め規定されたレベルの下になった最終の時から、該バッフアーからのデータ取り込みイベントの数を追跡し続ける。
【００２１】
該パックし直し部がＨ．２２１フレーム用データを作った後、該エンドポイント用に入って来るビデオデータを１時的に蓄積するビデオバッフアーの充填レベルを示すｂｕｆｆｅｒ＿ｌｅｖｅｌがチェックされる。もしｂｕｆｆｅｒ＿ｌｅｖｅｌが予め規定されたＭａｘ＿Ｌｅｖｅｌの下にあるならば、該カウンターはリセットされ、該手順は該パックし直し部がもう１つのＨ．２２１フレーム用に新データを作るのを待つが、もしそうでないなら、該カウンターはインクレントされる。この例では、Ｍａｘ＿ｌｅｖｅｌは１０ｍｓのＨ．２２１フレーム内のビデオデータの最大量である。
【００２２】
次いで該カウンター自身が調べられ、そして、もしそれが予め規定されたＯｖｅｒｐｒｏ＿Ｌｅｖｅｌの下にあれば、該手順は該パックし直し部がもう１つのＨ．２２１フレーム用に新データを作るのを待つ。もしそうでないなら、該Ｈ．３２３エンドポイントは作りすぎと考えられる。該カウンターはリセットされ、そして、該Ｈ．３２３エンドポイントから送信されるビデオデータのデータフローレートはそのパラメーターのＦｌｏｗ＿Ｓｔｅｐで示される予め規定された量だけ低下される。この例ではＦｌｏｗ＿Ｓｔｅｐは１６ｋビットの定数である。該データフローレートのデクレメント動作（ｄｅｃｒｅｍｅｎｔｉｎｇ）は、現在のフローレートマイナスＦｌｏｗ＿ＳｔｅｐのｍａｘｉｍｕｍＢｉｔｒａｔｅを含むｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄ又はｌｏｇｉｃａｌＣｈａｎｎｅｌＲａｔｅＲｅｑｕｅｓｔメッセージと、ビデオデータの論理チャンネルを示すｌｏｇｉｃａｌＣｈａｎｎｅｌＮｕｍｂｅｒと、を送信することにより行われる。しかしながら、デクレメント動作が起こる前に、該現在のフローレートマイナスＦｌｏｗ＿Ｓｔｅｐが予め規定されたＦｌｏｗ＿Ｍｉｎより低いかどうかをチェックせねばならない。もしそうであれば、該デクレメント動作はバイパスされ、該手順は該パックし直し部がもう１つのＨ．２２１フレーム用に新データを作るのを待つ。この理由は該Ｈ．３２３エンドポイントから送信される現実のビデオデータレートがゼロにセットされることを確認することである。
【００２３】
例えば、該フローレートの過大な削減（ｏｖｅｒｓｉｚｅｄ ｒｅｄｕｃｔｉｏｎ）をトリガーするデータバーストを避けるために、データバーストをもたらす少なくとも最も普通なイベント（ａｔ ｌｅａｓｔ ｔｈｅ ｍｏｓｔ ｃｏｍｍｏｎ ｅｖｅｎｔｓ ｐｒｏｄｕｃｉｎｇ ｄａｔａ ｂｕｒｓｔ）を中断（ｉｎｔｅｒｃｅｐｔｉｎｇ）させる機構が好ましくは導入されるべきである。例として、エンドポイントが種々のコールレートを有するＨ．３２３会議コールの場合（ｔｈｅ ｃａｓｅ ｏｆ ａ Ｈ．３２３
ｃｏｎｆｅｒｅｎｃｅ ｃａｌｌ ｗｈｅｒｅ ｔｈｅ ｅｎｄｐｏｉｎｔｓ ｈａｖｅ
ｄｉｆｆｅｒｅｎｔ ｃａｌｌ ｒａｔｅｓ）を考える。最も低いコールレートを有するエンドポイントが最初に、他のエンドポイントへそれらに該低いレートで作らせる（ｔｏ ｍａｋｅ ｔｈｅｍ ｐｒｏｄｕｃｅ ａｔ ｔｈｅ ｌｏｗ ｒａｔｅ）ようフロー制御メッセージを送信する。しかしながら、これは短期間の作りすぎを妨げないであろう。このスタートのバーストは本発明のオーバーフロー検出機構をトリガーし、必要より多くフローレートを減ずる。これを避けるために、該ゲートウェイは常に、ビデオチャンネルが開いた後規定された時間間隔だけ、該フローレートを該出て行くＨ．３２０レートまで増加させるよう構成されることが出来る。
【００２４】
本発明は該フロー制御始動されたレートに対してより多くのビデオデータ（又は他のマルチメデイアデータ）を一貫して作るＨ．３２３エンドポイント（又は同様な標準に調整されたエンドポイント）を取り扱う。
【００２５】
換言すれば、本発明はゲートウェイに、バッフアー溢れ（ｂｕｆｆｅｒ ｏｖｅｒｆｌｏｗ）とデータ消失を防止しつつ一貫して作りすぎするＨ．３２３エンドポイントと共に作動するようにさせる。この方法では、遅延と映像アーチフアクトの形成（ｂｕｉｌｄ ｕｐｓ）は、避けられるか又は大いに減じられる。
【００２６】
本発明はエンドポイントとゲートウェイの間のフロー制御だけに限定されず、エンドからエンドの背景で（ｅｎｄ−ｔｏ−ｅｎｄ ｃｏｎｔｅｘｔ）又はエムシーユー（ＭＣＵ）とエンドポイントの間でも同様に利用されてもよい。本発明はＨ．３２３標準に限定されず、それは他の同様な標準、例えば、ＳＩＰ標準に関連しても有用であり得る。ＳＩＰ標準の場合、Ｈ．３２３に関しての説明で使われたｆｌｏｗＣｏｎｔｒｏｌＣｏｍｍａｎｄは背景のセクションで説明されたＲｅＩｎｖｉｔｅメッセージと置き換えられる。本発明はフロー制御用に使われる該ＳＩＰ及びＨ．３２３標準の将来版の何等かのメッセージ又は方法用にも適用される。
【００２７】
本発明をより容易に理解可能にするために、行われる論議は付属する図面を参照する。
【図面の簡単な説明】
【００２８】
【図１】本発明の好ましい実施例を図解するフローシートである。
【特許請求の範囲】
【請求項１】
第１のパケット交換のＨ．３２３又はＳＩＰ構成されたビデオ会議ターミナルから送信され、第２のパケット交換のＨ．３２３又はＳＩＰ構成されたビデオ会議ターミナルにより受信されるデータのフローレートを調整し、該受信されたデータを、更に進んだ処理用に取り込まれる前に、該第２パケット交換ビデオ会議ターミナル内の１つ以上のバッフアー内に１時的に蓄積する方法に於いて、該方法が
前記１つ以上のバッフアーからの各データ取り込み後、
該１つ以上のバッフアーの充填レベルを予め規定されたレベルと比較し
もし前記充填レベルが前記予め規定されたレベルより低ければ
カウンターをリセットし、
もし前記充填レベルが前記予め規定されたレベルより高ければ
前記カウンターをインクレメントし、そして
前記カウンターを予め規定されたカウンターリミットと比較し、
もし前記カウンターが前記予め規定されたカウンターリミットより高ければ、
前記カウンターをリセットし、そして
該第２から該第１のパケット交換ターミナルへのフロー制御メッセージであるが、前記フロー制御メッセージ内に含まれるフローレート値により該フローレートを減ずるよう該第１パケット交換ターミナルに命ずる該フロー制御メッセージを送信することにより該送信されるデータの該フローレートを減ずることを特徴とする該方法。
【請求項２】
該第２パケット交換ビデオ会議ターミナルがゲートウェイであることを特徴とする請求項１の方法。
【請求項３】
該フローレートが予め規定された一定値だけ減じられることを特徴とする請求項１又は２の方法。
【請求項４】
該フローレートを減じる過程の前の下記過程、すなわち、
該フローレートと前記予め規定された一定値との間の差を予め規定された下方フローレートリミットと比較する過程と、
もし前記差が前記予め規定された下方フローレートリミットより大きい場合のみ該フローレートを減じる過程を行う過程と、を特徴とする請求項３の方法。
【請求項５】
前記ゲートウェイはＨ．３２３／Ｈ．３２０のゲートウェイであり、前記予め規定されたレベルは、該１つ以上のバッフアーから取り込まれたデータが挿入されるＨ．３２０フレーム内のデータの最大量に等しいことを特徴とする請求項２−４の方法。
【請求項６】
前記データが、１つのビデオ会議で該第１パケット交換ビデオ会議ターミナルから該第２パケット交換ビデオ会議ターミナルを経由して回線交換ターミナルへ送信されたビデオ、オーディオ及び／又は他のマルチメディアのデータであることを特徴とする請求項５の方法。
【請求項１】
第１のパケット交換のＨ．３２３又はＳＩＰ構成されたビデオ会議ターミナルから送信され、第２のパケット交換のＨ．３２３又はＳＩＰ構成されたビデオ会議ターミナルにより受信されるデータのフローレートを調整し、該受信されたデータを、更に進んだ処理用に取り込まれる前に、該第２パケット交換ビデオ会議ターミナル内の１つ以上のバッフアー内に１時的に蓄積する方法に於いて、該方法が
前記１つ以上のバッフアーからの各データ取り込み後、
該１つ以上のバッフアーの充填レベルを予め規定されたレベルと比較し
もし前記充填レベルが前記予め規定されたレベルより低ければ
カウンターをリセットし、
もし前記充填レベルが前記予め規定されたレベルより高ければ
前記カウンターをインクレメントし、そして
前記カウンターを予め規定されたカウンターリミットと比較し、
もし前記カウンターが前記予め規定されたカウンターリミットより高ければ、
前記カウンターをリセットし、そして
該第２から該第１のパケット交換ターミナルへのフロー制御メッセージであるが、前記フロー制御メッセージ内に含まれるフローレート値により該フローレートを減ずるよう該第１パケット交換ターミナルに命ずる該フロー制御メッセージを送信することにより該送信されるデータの該フローレートを減ずることを特徴とする該方法。
【請求項２】
該第２パケット交換ビデオ会議ターミナルがゲートウェイであることを特徴とする請求項１の方法。
【請求項３】
該フローレートが予め規定された一定値だけ減じられることを特徴とする請求項１又は２の方法。
【請求項４】
該フローレートを減じる過程の前の下記過程、すなわち、
該フローレートと前記予め規定された一定値との間の差を予め規定された下方フローレートリミットと比較する過程と、
もし前記差が前記予め規定された下方フローレートリミットより大きい場合のみ該フローレートを減じる過程を行う過程と、を特徴とする請求項３の方法。
【請求項５】
前記ゲートウェイはＨ．３２３／Ｈ．３２０のゲートウェイであり、前記予め規定されたレベルは、該１つ以上のバッフアーから取り込まれたデータが挿入されるＨ．３２０フレーム内のデータの最大量に等しいことを特徴とする請求項２−４の方法。
【請求項６】
前記データが、１つのビデオ会議で該第１パケット交換ビデオ会議ターミナルから該第２パケット交換ビデオ会議ターミナルを経由して回線交換ターミナルへ送信されたビデオ、オーディオ及び／又は他のマルチメディアのデータであることを特徴とする請求項５の方法。
【図１】
【公表番号】特表２００７−５１４３３５（Ｐ２００７−５１４３３５Ａ）
【公表日】平成１９年５月３１日（２００７．５．３１）
【国際特許分類】
【出願番号】特願２００６−５３２１５２（Ｐ２００６−５３２１５２）
【出願日】平成１６年５月１３日（２００４．５．１３）
【国際出願番号】ＰＣＴ／ＮＯ２００４／０００１４４
【国際公開番号】ＷＯ２００４／１０５３９４
【国際公開日】平成１６年１２月２日（２００４．１２．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＴＨＥＲＮＥＴ
【出願人】（５０５１９９３３７）タンドベルク・テレコム・エイ・エス (33)
【Ｆターム（参考）】
【公表日】平成１９年５月３１日（２００７．５．３１）
【国際特許分類】
【出願日】平成１６年５月１３日（２００４．５．１３）
【国際出願番号】ＰＣＴ／ＮＯ２００４／０００１４４
【国際公開番号】ＷＯ２００４／１０５３９４
【国際公開日】平成１６年１２月２日（２００４．１２．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＴＨＥＲＮＥＴ
【出願人】（５０５１９９３３７）タンドベルク・テレコム・エイ・エス (33)
【Ｆターム（参考）】
[ Back to top ]