JP6285027B2 - ビデオ電話におけるビデオ中断インジケーション - Google Patents

Description

関連出願

[0001]本出願は、２０１３年７月２６日に出願され、そのすべての内容が全体として参照により本明細書に組み込まれる、インド特許出願第２４７７／ＭＵＭ／２０１３号の利益を主張する。

[0002]本開示はビデオ電話（video telephony）に関し、より具体的には、ビデオ電話アプリケーションにおいてビデオ中断を検出するための技法に関する。

[0003]モバイル電話のような通信デバイスは、マイクロフォンまたは音声合成器のようなオーディオキャプチャデバイス、オーディオパケット（またはフレーム）を生成するためのオーディオエンコーダ、カメラのようなビデオキャプチャデバイス、およびビデオパケットフレームを生成するためのビデオエンコーダを含むことができる。電話は、リアルタイムトランスポートプロトコル（ＲＴＰ）、無線リンクプロトコル（ＲＬＰ）、媒体アクセス制御（ＭＡＣ）、および物理（ＰＨＹ）レイヤのような通信プロトコルレイヤを使用することができる。ビデオ電話アプリケーションでは、通信デバイスは、ＲＬＰ待ち行列にビデオおよびオーディオＲＴＰパケットを配置することができる。ＭＡＣレイヤモジュールは、ＲＬＰ待ち行列のコンテンツからＭＡＣレイヤパケットを生成することができる。ＭＡＣレイヤパケットは、別の通信デバイスへの通信チャネルをわたった送信のために、ＰＨＹレイヤパケットに変換されうる。

[0004]本開示はビデオ電話に関し、より具体的には、ビデオ電話アプリケーションにおいてビデオ中断を検出するための技法に関する。

[0005]本開示の一例では、ビデオ電話のための方法は、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを、受信デバイスにおいて検出することと、ビデオ制御パケットに含まれた情報に基づいて、該送信元デバイスが該ビデオ電話呼のビデオ部分を中断したと決定することと、を備える。

[0006]本開示の別の例では、ビデオ電話のために構成された装置は、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを、受信デバイスにおいて検出するための手段と、ビデオ制御パケットに含まれた情報に基づいて、該送信元デバイスが該ビデオ電話呼のビデオ部分を中断したと決定するための手段と、を備える。

[0007]本開示の別の例では、ビデオ電話のために構成された装置は、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを、受信デバイスにおいて検出し、ビデオ制御パケットに含まれた情報に基づいて、該送信元デバイスが該ビデオ電話呼のビデオ部分を中断したと決定するように構成された受信デバイスと、を備える。

[0008]別の例では、本開示は、命令を記憶するコンピュータ可読媒体を説明しており、該命令は、実行されるとき、ビデオ電話のためのデバイスの１つ以上のプロセッサに、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを、受信デバイスにおいて検出することと、ビデオ制御パケットに含まれた情報に基づいて、該送信元デバイスが該ビデオ電話呼のビデオ部分を中断したと決定することと、を行わせる。

[0009]１つ以上の実施形態の詳細は、添付図面および以下の説明において述べられる。

ビデオおよびオーディオ符号化および復号システムを例示している。 汎用パケット交換（ＰＳ）ネットワークをわたった２方向ＶＴ呼の簡略化されたブロック図を描写している。 Ｃａｌｌ Ｈｏｌｄ明示シグナリングを使用したビデオ中断中の呼ダウングレードの使用ケースに関する信号フローを図示する概略図である。 本開示の技法を使用したビデオ中断検出の１つの使用ケースに関する例となる信号フローを図示している概略図である。 本開示の技法を使用したビデオ中断検出の別の使用ケースに関する別の例となる信号フローを図示している概略図である。 本開示の技法にしたがった例となる方法を図示しているフローチャートである。

[0016]本開示は、ビデオ電話に関し、より具体的には、ビデオ電話アプリケーションにおいてビデオ中断を検出するための技法に関する。ビデオ電話呼中のビデオの中断を示し、検出するための現在の技法は、その呼に携わる通信デバイス間で曖昧な状態を引き起こしうる。いくつかの環境では、以前に中断されたことのあるビデオ電話呼のビデオ部分が再スタートされた後に、ビデオの中断を示すための現在の技法は、その呼中の通信デバイスのうちの１つに一方向ビデオ呼（１つのデバイスからのみ送られたビデオ）が依然として実施されていることを想定させうる一方で、他の通信デバイスは、二方向ビデオ呼（両方の当事者（parties）から送られたビデオ）が再開したことを想定しうる。本開示の技法は、そのような曖昧な状態を回避する、ビデオの中断を示して決定するための技法を対象としている。

[0017]図１は、本開示の技法を利用することができるビデオ符号化および復号システム１０を例示している。システム１０は、デコーダシステム１４に送信チャネル１６をわたってデータを送るエンコーダシステム１２を含む。エンコーダシステム１２は、第１のビデオ通信デバイス中にあり得、オーディオソース１７、ビデオソース１８、ビデオエンコーダ２０、オーディオエンコーダ２２、リアルタイムトランスポートプロトコル（ＲＴＰ）／ユーザデータグラムプロトコル（ＵＤＰ）／インターネットプロトコル（ＩＰ）／ポイント対ポイントプロトコル（ＰＰＰ）変換モジュール２６、無線リンクプロトコル（ＲＬＰ）待ち行列２８、ＭＡＣレイヤモジュール３０、および物理（ＰＨＹ）レイヤモジュール３２を含むことができる。エンコーダシステム１２の他の実施形態は、図１で図示されている要素の代わりに、またはその要素に加えて、他の要素を含むことができる。エンコーダシステム１２の他の実施形態は、図１で図示されているものよりも少ない要素を含みうる。

[0018]デコーダシステム１４は、別のビデオ通信デバイス中にあり得、ＰＨＹレイヤモジュール３４、ＭＡＣレイヤモジュール３６、ＲＬＰ待ち行列３８、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０、ビデオデコーダ４２、ビデオデコーダ４４、オーディオ出力ユニット４６、およびビデオ出力ユニット４８を含むことができる。デコーダシステム１４の他の実施形態は、図１で図示されている要素の代わりに、またはその要素に加えて、他の要素を含むことができる。デコーダシステム１４の他の実施形態は、図１で図示されているものよりも少ない要素を含みうる。

[0019]システム１０は、例えば、送信チャネル１６を介したビデオ電話（ＶＴ）のために、双方向ビデオおよびオーディオ送信を提供することができる。互恵的符号化（Reciprocal encoding）、復号、および変換モジュールは、チャネル１６の反対側上で提供されうる。いくつかの実施形態では、エンコーダシステム１２およびデコーダシステム１４は、ビデオストリーミング、ＶＴ、またはその両方のために装備されたワイヤレスモバイル端末のようなビデオ通信デバイス内で具現化されうる。モバイル端末は、ＲＴＰ、ＵＤＰ、ＩＰ、またはＰＰＰのようなパケット交換規格にしたがってＶＴをサポートすることができる。

[0020]ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、オーディオエンコーダ２２およびビデオエンコーダ２０から受信されたオーディオおよびビデオデータに、適切なＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダを加え、ＲＬＰ待ち行列２８にそのデータを配置する。ＲＴＰがＵＤＰの上部で作動する一方で、ＵＤＰがＩＰの上部で作動し、ＩＰはＰＰＰの上部で作動する。ＭＡＣレイヤモジュール３０は、ＲＬＰ待ち行列２８のコンテンツからＭＡＣ ＲＬＰパケットを生成する。ＰＨＹレイヤモジュール３２は、チャネル１６をわたった送信のために、ＰＨＹレイヤパケットにＭＡＣ ＲＬＰパケットを変換する。

[0021]復号システム１４のＰＨＹレイヤモジュール３４およびＭＡＣレイヤモジュール３６は、互恵的形式でオペレートする。ＰＨＹレイヤモジュール３４は、ＭＡＣ ＲＬＰパケットにチャネル１６から受信されたＰＨＹレイヤパケットを変換する。ＭＡＣレイヤモジュール３６は、ＲＬＰ待ち行列３８にＭＡＣ ＲＬＰパケットを配置する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール４０は、ＲＬＰ待ち行列３８におけるデータからヘッダ情報を取り除き、ビデオデコーダ４２およびオーディオデコーダ４４のそれぞれへの搬送のためにビデオおよびオーディオデータを再構築する。

[0022]システム１０は、符号分割多元接続（ＣＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、時分割多元接続（ＴＤＭＡ）、または直交周波数分割多重（ＯＦＤＭ）、または別の適したワイヤレス技法のような、１つ以上のワイヤレス通信技術をサポートするように設計されうる。上記のワイヤレス通信技術は、様々な無線アクセス技術のいずれかにしたがって搬送されうる。例えば、ＣＤＭＡは、ｃｄｍａ２０００、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））規格、３Ｇ、４Ｇ、ＬＴＥ（登録商標）、またはあらゆる他のＣＤＭＡベースのエアインターフェースにしたがって搬送されうる。ＴＤＭＡは、移動通信のためのグローバルシステム（ＧＳＭ（登録商標））規格にしたがって搬送されうる。ユニバーサルモバイル通信システム（ＵＭＴＳ）規格は、ＧＳＭまたはＷＣＤＭＡオペレーションを許可する。ＶＴアプリケーションでは、システム１０は、ｃｄｍａ２０００ １ｘ ＥＶ−ＤＯ、リリース０、リビジョンＡ、または後続ＥＶ−ＤＯリリースのような高データレート（ＨＤＲ）技術をサポートするように設計されうる。

[0023]ビデオソース１８は、１つ以上のビデオカメラ、１つ以上のビデオアーカイブ、またはビデオカメラとビデオアーカイブの組み合わせのようなビデオキャプチャデバイスでありうる。ビデオエンコーダ２０は、ＭＰＥＧ−４、Ｈ．２６４／ＡＶＣ（アドバンスドビデオコーディング）、または高効率ビデオコーディング（ＨＥＶＣ）のようなビデオ圧縮方法にしたがって、符号化されたビデオデータを生成する。国際電気通信連合（ＩＴＵ）Ｈ．２６３、ＶＰ９、ＭＰＥＧ−２、または他の標準化されたもしくは独占権下にある方法のような、他のビデオ圧縮方法もまた使用されうる。ビデオエンコーダ２０は、概してＣＯＤＥＣ依存であるビデオソースレート制御スキームを提供することができる。ＨＥＶＣ、ＭＰＥＧ４、ＩＴＵ Ｈ．２６３、ＩＴＵ Ｈ．２６４、または別の規格もしくは技法にしたがったビデオ符号化のために適合されうる。一例では、ビデオエンコーダ２０は、ＤＳＰまたは組み込まれたロジックコアによって実装されうる。

[0024]オーディオソース１７は、マイクロフォンまたは音声合成器デバイスのような、オーディオキャプチャデバイスでありうる。オーディオエンコーダ２２は、ビデオデータに付随するようにオーディオデータを符号化することができる。オーディオデータは、適応マルチレート狭帯域（ＡＭＲ−ＮＢ）または他の技法のようなオーディオ圧縮方法にしたがって符号化されうる。ＶＴアプリケーションでは、ビデオは、ＶＴ会議に対する当事者の表示を許可することになり、オーディオは、当事者の話す声が聞こえることを許可することになる。

[0025]オペレーションにおいて、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、ビデオエンコーダ２０およびオーディオエンコーダ２２からビデオおよびオーディオデータパケットを取得する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、オーディオパケットに適切なヘッダ情報を追加し、ＲＬＰ待ち行列２８内に結果として生じたデータを挿入する。同様に、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換モジュール２６は、ビデオパケットに適切なヘッダ情報を追加し、ＲＬＰ待ち行列２８内に結果として生じたデータを挿入する。ＭＡＣレイヤモジュール３０は、ＲＬＰ待ち行列２８からデータを検索し、ＭＡＣレイヤパケットを形成する。各ＭＡＣレイヤパケットは、ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダ情報、およびＲＬＰ待ち行列２８内に含まれるオーディオまたはビデオパケットデータを運ぶ。

[0026]オーディオパケットは、ビデオパケットから独立して、ＲＬＰ待ち行列２８に挿入されうる。いくつかのケースでは、ＲＬＰ待ち行列２８のコンテンツから生成されたＭＡＣレイヤパケットは、ヘッダ情報およびビデオパケットデータのみを運ぶことになる。他のケースでは、ＭＡＣレイヤパケットは、ヘッダ情報およびオーディオパケットデータのみを運ぶことになる。

[0027]いくつかのケースでは、ＭＡＣレイヤパケットは、ＲＬＰ待ち行列２８のコンテンツに依存して、ヘッダ情報、オーディオパケットデータ、およびビデオパケットデータを運ぶことになる。ＭＡＣレイヤパケットは、無線リンクプロトコル（ＲＬＰ）にしたがって構成され得、ＭＡＣ ＲＬＰパケットとして称されうる。ＰＨＹレイヤモジュール３２は、チャネル１６をわたった送信のために、ＰＨＹレイヤパケットにＭＡＣ ＲＬＰオーディオ−ビデオパケットを変換する。

[0028]チャネル１６は、デコーダシステム１４にＰＨＹレイヤパケットを運ぶ。例えば、チャネル１６は、ローカルまたはワイドエリア有線ネットワークのような有線接続でありうる。代わりとして、本明細書で説明されるように、チャネル１６は、セルラ、衛星、または光学チャネルのようなワイヤレスチャネルでありうる。

[0029]チャネル条件は、有線およびワイヤレスチャネルに関する懸念事項でありうるけれども、特に、チャネル条件がフェーディングまたは輻輳に起因して損害を被るワイヤレスチャネル１６をわたって実行されるモバイルＶＴアプリケーション対して問題がある。例えば、チャネル１６は、チャネル条件にしたがって変動するスループットを有する逆リンク（ＲＬ）によって特徴付けられうる。スループットは、現在のワイヤレスチャネル送信レート、ワイヤレス基地局アクティビティ、および送信電力制限、のうちの１つ以上によって表されるような、チャネル条件に基づいて推定されうる。例えば、チャネル条件は、現在のＭＡＣレイヤデータレート、逆アクティビティビット（ＲＡＢ）、および電力増幅器（ＰＡ）制限に基づいて決定されうる。

[0030]ビデオエンコーダ２０は、ターゲット符号化レートに対する符号化されたビデオの量を表す仮想ビデオバッファを維持することができる。ターゲット符号化レートは、チャネル１６をわたって送信されるビデオパケットに対して指定された最大符号化レートでありうる。ビデオエンコーダ２０は、ビデオソース１８からのビデオの実際の符号化レートを制御することができる。

[0031]デコーダシステム１４のＰＨＹレイヤモジュール３４は、ＰＨＹレイヤパケットからＭＡＣレイヤパケットを識別し、ＭＡＣ ＲＬＰパケットにコンテンツを再構築する。ＭＡＣレイヤモジュール３６はその後、ＲＬＰ待ち行列３８内への挿入のためのビデオおよびオーディオパケットを提供するように、ＭＡＣ ＲＬＰパケットのコンテンツを再構築する。ＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰモジュール４０は、付随するヘッダ情報を排除し、ビデオデコーダ４２にビデオパケットを、オーディオデコーダ４４にオーディオパケットを提供する。

[0032]ビデオデコーダ４２は、ディスプレイデバイスを駆動させる際に使用するビデオデータのストリームを作り出すためにビデオデータフレームを復号する。オーディオデコーダ４４は、例えば、オーディオスピーカを介したユーザへの提示のためのオーディオ情報を作り出すように、オーディオデータを復号する。

[0033]ビデオ電話（ＶＴ）は、システム１２および１４のような少なくとも２つのデバイス間でオーディオおよびビデオデータを運ぶパケットのリアルタイム通信を指す。第１のＶＴデバイス１２は、ビデオカメラまたはビデオアーカイブのようなビデオキャプチャデバイス１８からビデオを取得し、ビデオパケットを生成するビデオエンコーダ２０を含む。同様に、ＶＴデバイス１２中のオーディオエンコーダ２２は、マイクロフォンまたは音声合成器のようなオーディオキャプチャデバイス１７からオーディオを取得し、オーディオパケットを生成する。ビデオパケットおよびオーディオパケットは、ＲＬＰ待ち行列２８に配置される。ＭＡＣレイヤモジュール３０は、ＲＬＰ待ち行列２８のコンテンツからＭＡＣレイヤパケットを生成する。ＭＡＣレイヤパケットは、第２のＶＴ通信デバイス１４への通信チャネル１６をわたった送信のために、ＰＨＹレイヤパケットに変換される。

[0034]モバイルＶＴアプリケーションでは、ＶＴデバイス（ワイヤレス端末）は、基地局からワイヤレス順方向リンク（ＦＬ）（すなわち、「ダウンリンク」）を介してＰＨＹレイヤパケットを受信する。ＶＴデバイスは、基地局にワイヤレス逆リンク（ＲＬ）（すなわち、「アップリンク」）を介してＰＨＹレイヤパケットを送信する。各ＶＴデバイスは、受信されたＰＨＹおよびＭＡＣレイヤパケットを変換し、オーディオパケットおよびビデオパケットにそのパケットペイロードを再構築するためのＰＨＹおよびＭＡＣレイヤを含む。ＶＴデバイス内のビデオデコーダ４２は、ディスプレイデバイス（ビデオ出力）４８を介したユーザへの提示のためにビデオデータを復号する。ＶＴデバイス内のオーディオデコーダ４４は、スピーカデバイス（オーディオ出力）４６を介した出力のためにオーディオデータを復号する。

[0035]図２は、汎用パケット交換（ＰＳ）ネットワーク５２をわたった２方向ＶＴ呼の簡略化されたブロック図を描写している。ＰＳネットワーク５２は、ＬＴＥ、ＨＳＰＡ、（ｅ）ＨＲＰＤ、ＷｉＦｉ、衛星、同軸ケーブル、電力線通信、および同様のもの、または上記の任意のものの組み合わせでありうる。デバイスＡの送信サイドでは、ＶＴ呼のオーディオ／ビデオは、マイク／スピーカ５６およびカメラ／ディスプレイ５４においてキャプチャされ、処理ユニット５８によって、該当する場合（if applicable）、前処理され、符号化／圧縮され、ＲＴＰ／ＵＤＰ／ＩＰパケット化され、およびモデムに渡される。デバイスＡの受信サイドでは、受信されたオーディオ／ビデオパケットは、マイク／スピーカ５６およびカメラ／ディスプレイ５４に送られる前に処理ユニット５８によって、該当する場合、復調され、パケット解除され（dis-packetized）、ジッタ除去され（de-jittered）、復号され、ＡＶ同期され、および後処理される。

[0036]同様に、デバイスＢの送信サイドでは、ＶＴ呼のオーディオ／ビデオは、マイク／スピーカ６６およびカメラ／ディスプレイ６４においてキャプチャされ、処理ユニット６８によって、該当する場合、前処理され、符号化／圧縮され、ＲＴＰ／ＵＤＰ／ＩＰパケット化され、およびモデムに渡される。デバイスＢの受信サイドでは、受信されたオーディオ／ビデオパケットは、マイク／スピーカ６６およびカメラ／ディスプレイ６４に送られる前に処理ユニット６８によって、該当する場合、復調され、パケット解除され、ジッタ除去され、復号され、ＡＶ同期され、および後処理される。

[0037]オーディオ／ビデオＲＴＣＰパケットもまた、ＡＶ同期、メディア性能関連統計、レート適合等のためにオーディオ／ビデオＲＴＰパケットとともに送られる。ＲＴＣＰパケットは、ＲＴＰパケットよりも低い頻度で生じる。すなわち、ＲＴＣＰパケットの制御情報が通常、５００ｍｓ毎から２秒毎でシグナリングされる一方で、ＲＴＰパケットはより高い頻度で生じる。

[0038]典型的な２当事者（two-party）ビデオ電話（ＶＴ）呼中、ビデオは、ユーザアクションの結果として一方向または両方向で１回以上中断されうる。例えば、どちらサイドのユーザも、いくつかの他のタスクを簡潔に実行するために、デバイス上で背景にＶＴアプリケーションを移動させうる。例えば、ＶＴ呼の途中で、ユーザの一方が、写真を撮るために電話カメラを使用する、電子メールを素早くチェックする、または別のタスクを実行することができる。結果として、ＶＴ呼のためのカメラリソースはリリースされ得、このケースではどのビデオもピアサイドに送られる。すなわち、ユーザが背景にＶＴアプリケーションを移動させるとき、ビデオは通常、ＶＴ呼においてもう一方の当事者にはもはや送られない。ビデオは、背景にあるＶＴアプリケーションのユーザが、どのビデオが送られているかを示すプレビューウィンドウをもはや見ることができないので、停止されうる。増大したプライバシを提供するために、および通知なしでビデオを送ることを回避するために、ＶＴアプリケーションは通常、ビデオＲＴＰパケットを送ることを中止することになる。しかしながら、オーディオパケットは継続するだろうことになり（would）、ＶＴはドロップ（drop）されない。ビデオ通話が継続する一方でビデオストリームが１つ以上の方向に流れるのを停止する現象は通常、ビデオ中断と呼ばれる。

[0039]図２に戻って参照すると、ＶＴシステムは、デバイスＡ（またはデバイスＢ）がデバイスＢ（またはデバイスＡ）に、それがビデオを中断したことを示すことを可能にする技法の利益を享受する。ＶＴシステムはまた、incomingビデオが打ち切られたときにデバイスが、打ち切られたビデオがビデオ送信の意図的な停止（例えば、ビデオ中断）に起因しているのかどうか、または打ち切られたビデオが送信経路の深刻な劣化の結果であるのかどうか、を見極めることを可能にする技法の利益も享受する。そのような技法は、複数当事者ＶＴ／ＶＳ呼と同様に、一方向ビデオ（またはビデオ共有（ＶＳ））呼に適用可能でありうる。

[0040]ビデオ中断を示すための１つの既存の解決策は、Ｃａｌｌ Ｈｏｌｄプロシージャと呼ばれる。すなわち、デバイスＡがビデオを中断するとき、それは、明示シグナリングを使用して、デバイスＢのビデオストリームを保留にする、また逆に関しても同様のことを行う。この手法は、特に、ユーザ開始型の呼ダウングレード（例えば、ユーザが二方向ビデオ呼から一方向ビデオ呼にＶＴ呼を変更すること）、および／またはユーザ開始型の呼アップグレード（例えば、ユーザが一方向ビデオ呼から二方向ビデオ呼にＶＴを変更すること）と合されるとき、複雑および／または曖昧になりうる。

[0041]図３は、Ｃａｌｌ Ｈｏｌｄ明示シグナリングを使用したビデオ中断中の呼ダウングレードの使用ケースに関する信号フローを図示する概略図である。呼は、ＶＴ呼としてスタートする。時間１００において、デバイスＡおよびデバイスＢは、ＶＴ呼中にあり、オーディオおよびビデオＲＴＣＰパケットと同様に、オーディオおよびビデオＲＴＰパケットの両方を送っている。イベント１において、デバイスＡユーザのユーザは、背景にＶＴアプリケーションを移動させる。イベント１は、ビデオ中断を引き起こす。従来の解決策では、ビデオ中断は、デバイスＢビデオを保留にするために明示シグナリングをトリガする。図３で図示されているシグナリングは、セッション開始プロトコル（ＳＩＰ）と呼ばれる。時間１０２において、デバイスＡは、デバイスＢに、再ＩＮＶＩＴＥ（ビデオ：sendonly、オーディオ：sendrecv）ＳＩＰメッセージを送る。再ＩＮＶＩＴＥメッセージは、デバイスＡがビデオパケットに関して「sendonly」としてオペレートすることになることを示す。すなわち、デバイスＡは、デバイスＢに対して、デバイスＡにビデオパケットを送ることを中止するように命令している。時間１０４において、デバイスＢは、デバイスＢが要求の受け取りを完了し、「recnonly」モードになる（つまり、デバイスＢがビデオペットを受信するのみになり、それらを送らない）ことを示す、ＳＩＰメッセージ２００ＯＫ（ビデオ：recvonly、オーディオ：sendrecv）で応答する。そのため、時間１０６において、どちらのデバイスからもＲＴＣＴ以外のビデオトラフィックは存在しない。

[0042]図３の例では、イベント２において、デバイスＢのユーザは、二方向ビデオ呼を一方向ビデオに変更するためにダウングレードを開始する（イベント２）。しかしながら、デバイスＢが「recvonly」モードになるための要求の受け取りを完了しているので、それが既にイベント１の結果としてそのような状態にあるため、デバイスＢは、ダウングレードを示すためのＳＩＰメッセージ（ビデオ：recvonly、オーディオ：sendrecv）を送ることができない。次に、イベント３では、デバイスＡのユーザは、最前面にＶＴアプリケーションを移動させる。このイベントは、時間１０８において、デバイスＡの視点から二方向ビデオを再開するために、デバイスＡがデバイスＢにＳＩＰメッセージ再ＩＮＶＩＴＥ（ビデオ：sendrecv、オーディオ：sendrecv）を送るようにトリガする。しかしながら、それは、デバイスＢには（一方向ビデオから二方向ビデオへの）「アップグレード」のように見えるので、デバイスＢは、アップグレードを受け取るようにユーザを促す。しかしながら、イベント２に起因して、デバイスＢのユーザは、時間１１０においてＳＩＰメッセージ６０３（拒絶）を送ることによって、「アップグレード」を拒絶する可能性が高い。このケースでは、デバイスＡが、ＶＴ呼が二方向ビデオ呼であるという想定の下にありうる一方で、デバイスＢは、ＶＴ呼が一方向ビデオ呼であるという想定の下にありうる。この例は、ビデオ中断を示すために明示ＳＩＰシグナリング、特にＣａｌｌ Ｈｏｌｄプロシージャのためのシグナリングを使用することによって引き起こされるユーザ予測（user expectation）およびシグナリングにおける乱雑さ／曖昧さを表す。

[0043]これらの欠点の観点から、本開示は、ビデオ中断を示して決定するための代わりの手法を提案する。本開示の手法は、いずれの明示シグナリングメッセージ（例えば、ＳＩＰメッセージ）も用いない。代わりに本開示は、incoming側メディア自体で運ばれる既に利用可能な情報を使用することを提案する。例えば、本開示は、ビデオ中断のインジケーションとして、ＲＴＰおよび／またはＲＴＣＰパケットに含まれる情報（例えば、ビデオＲＴＣＰパケットにおいて運ばれる、ビデオＲＴＰ非アクティビティ（inactivity）／アクティビティ、ＲＴＣＰパケットタイプ、および／または統計）を使用することを提案する。本手法は、シグナリングおよびユーザエクスペリエンス／予測において乱雑さを引き起こすことなく、ビデオ中断を決定するためのリアルタイムで、簡素で、明確で、かつ効果的なメカニズムを提供する。

[0044]再び、図２が提供しているデバイスＡおよびデバイスＢがアクティブＶＴ呼にあり、（例えば、背景にＶＴアプリケーションを移動させた結果として）デバイスＡがビデオを中断することを想定されたい。このケースでは、デバイスＡは、デバイスＢにビデオＲＴＰパケットを送るのを停止する。しかしながら、デバイスＡは、ビデオＲＴＣＰパケットを発し続ける。ＲＴＰおよびＲＴＣＰシグナリングプロトコルを指定する、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）ドキュメントＲＦＣ３５５０にしたがって、ビデオが中断されるとき、送信側報告（ＳＲ）（すなわち、「ペイロードタイプ」＝２００）を含む、最初の２つのＲＴＣＰパケットは、依然として中断の後にシグナリングされる。ＳＲは、送信側情報セクションにおける「送信側のパケットカウント」および「送信側のオクテットカウント」に関する＼情報を含む。「送信側パケットカウント」が送られたＲＴＰパケットの数である一方で、「送信側オクテットカウント」は、ＲＴＰパケットで送られたデータの総量である。ＩＥＴＦ ＲＦＣ３５５０は、２０１３年７月２５日付でhttp://www.ietf.org/rfc/rfc3550.txtから利用可能であり、この全体の内容は、本明細書において参照によって組み込まれている。

[0045]デバイスＡがビデオを中断し、ＲＴＰパケットを送るのを停止した場合、２つの連続するＲＴＣＰパケットの第２のＲＴＣＰパケットは、２つの連続するＲＴＣＰパケットの第１のＲＴＣＰパケットに含まれるものと同一の「送信側パケットカウント」および「送信側オクテットカウント」を有するべきである。すなわち、２つの連続するＲＴＣＰパケットが、どのデータも送られていない（すなわち、送信側のパケットカウントおよび／または送信側のオクテットカウントが同一である）ことを示すＳＲ情報を有する場合、受信デバイス（例えば、デバイスＢ）は、ビデオＲＴＰパケットの中止が通信チャネルの悪化ではなくビデオ中断に起因すると決定するように構成されうる。しかしながら、ＲＴＰパケットが受信されることを中止してしまった後、２つの連続するＲＴＣＰパケットにおけるＳＲが、ＲＴＰパケットが送られ続けられた（例えば、送信側パケットカウントおよび／または送信側のオクテットカウントが等しくない）ことを示す場合、受信デバイスは、ＶＴ呼のためのチャネルが悪化したことを設定（configure）するように継続され得、いくつかのに例では、ＶＴ呼は、終了されるべきである。また、ビデオ中断が十分に長い場合、デバイスＡによって発せられたＳＲ ＲＴＣＰパケットの後の後続のＲＴＣＰパケットは、受信機報告（ＲＲ）（すなわち、「ペイロードタイプ」＝２０１）ＲＴＣＰパケットであるべきである。

[0046]このように、ビデオＲＴＣＰパケットが到着し続ける間にビデオＲＴＰパケットの受信が打ち切られるとき、デバイスＢは、（デバイスＡからデバイスＢへの送信経路が悪化されることになると決定することであり、このケースにおいてはビデオＲＴＰおよびＲＴＣＰの両方が失われているはずである、よりむしろ）デバイスＡがビデオを中断したと決定することができる。デバイスＢはさらに、「ペイロードタイプ」情報（ＳＲ対ＰＲ）、ならびに／または「送信側のパケットカウント」および「送信側のオクテットカウント」フィールドを調査することによって、受信されたＲＴＣＰパケットがＳＲである場合、この結論を承認する。一度デバイスＡがビデオ中断に起因してビデオＲＴＰパケットを送るのを停止したとデバイスＢが承認してしまうと、デバイスＢは、デバイスＡとのオーディオ接続を依然として維持しながら、デバイスＡにビデオを送り続ける（このケースでは、デバイスＡは単に、ビデオＲＴＰパケットをドロップするか、または各フレームを再構築および復号するがそれらをレンダリングしないことがある）か、いくつかの他のタスクを実行するために、背景にそれ自らのサイドのＶＴアプリケーションを置く（すなわち、ビデオ中断）か、または一方向ビデオにＶＴ呼をダウングレードすることさえしうる。デバイスＢが背景にそれ自らのサイドのＶＴアプリケーションを移動させるか、または一方向ビデオにＶＴ呼をダウングレードする場合、デバイスＢは、デバイスＡにビデオＲＴＣＰパケットを送リ続けながらビデオＲＴＰパケットを送るのを停止することになる。デバイスＢからのＲＴＣＰパケットは、デバイスＢによるビデオ中断を決定するために、デバイスＡによって同じ方法で使用されうる。両側が互いにビデオＲＴＰパケットを送るのを停止するとき、各サイドから送られるＲＴＣＰパケットは、結果として空のＲＲになる。

[0047]本開示の別の例では、ＲＴＣＰパケットの継続された受信と関連して、ＲＴＰパケットの存在またはその欠如が、ＶＴ呼におけるデバイスがビデオ呼を開始したと決定するために使用されうる。例えば、ＶＴ呼がＲＴＣＰパケット間の長い遅延（例えば、２秒以上）を使用するいくつかの状況では、ビデオが中断したかを決定するために２つの連続するＲＴＣＰパケットを待つことは望ましくないことがある。このように、本開示はさらに、ビデオ中断が生じたと決定するための追加のトリガとして、ＲＴＰパケットの継続された非受信を使用することを提案する。

[0048]一例として、デバイスＢは、デバイスＡからビデオＲＴＰパケットを受信するのを停止し、後続して１つのＲＴＣＰパケットを受信する。ＲＴＣＰパケットが受信された後、デバイスＢがタイマをスタートすることができる。どのＲＴＰパケットも、タイマが何らかの所定のしきい値に達する前に受信されない場合、デバイスＢは、デバイスＡがビデオを中断したと積極的に決定することができる。しきい値は、ＲＴＣＰパケット間の間隔よりも小さいいずれの値にも設定されうる。デバイスＢはその後、第２の連続するＲＴＣＰパケットが受信される時間にビデオ中断の決定を承認することができる。この方法で、ビデオ中断の決定は、ＲＴＣＰパケット間の長い遅延が存在する状況でより迅速に行われうる。

[0049]要約すると、本開示の技法を使用して、１つのデバイスがＶＴ呼においてビデオを中断するとき、ピアサイドは、ビデオＲＴＣＰパケットで運ばれるincomingビデオＲＴＰ非アクティビティ、ＲＴＣＰパケットタイプ、および／または統計をチェックすることによって、そのようなイベントを確実に、かつリアルタイムに、検出することができる。ビデオＲＴＰパケットが再開するとき、ピアサイドは、ビデオ中断が終了されたと決定することができる。いくつかの例では、デバイスは、上記の検出に基づいて、ビデオ中断スタートおよびビデオ中断終了インジケーションをユーザに提示することができる。

[0050]本開示の技法を使用するとき、指定の呼／媒体フローのいくつかは、デバイスＢ（すなわち、中断しなかったデバイス）のアクション、および／またはデバイスＡがビデオを中断した後のイベントの順序に依存して、変化しうる。図４は、本開示の技法を使用したビデオ中断検出の１つの使用ケースに関する例となる信号フローを図示している概略図である。時間２００において、デバイスＡおよびデバイスＢは二方向ＶＴ呼中にあり、ここにおいてオーディオおよびビデオＲＴＣＰパケットとともに、オーディオおよびビデオＲＴＰパケットの両方が送られる。イベント１において、デバイスＡは、背景にＶＴアプリケーションを配置し、それにより、ビデオを中断し、ビデオＲＴＰパケットの送信を中止する。そのため、時間２０２では、どのビデオＲＴＰパケットもデバイスＢに送られない。ビデオＲＴＣＰパケットは、デバイスＢに送られることを継続される。上記で説明された本開示の技法に基づいて、デバイスＢは、ビデオＲＴＣＰパケットにおける情報（例えば、ＳＲ）に基づいてビデオ中断が生じたと決定する。図４の例では、時間２０４において、デバイスＢがデバイスＡによるビデオ中断を検出した後、デバイスＢは、ビデオＲＴＰパケットを送り続けると決める。

[0051]イベント２では、デバイスＢのユーザは、一方向モードにＶＴ呼を配置するためにダウングレードオペレーションを実行する。ダウングレードオペレーションに応答して、再ＩＮＶＩＴＥおよび２００ＯＫ ＳＩＰメッセージは、ＶＴ呼を一方向モードにするために時間２０６および２０８において交換される。このため、時間２１０では、どのビデオＲＴＰメッセージもいずれのデバイスからも送られない。オーディオＲＴＰ／ＲＴＣＰメッセージおよびビデオＲＴＣＰメッセージは、送られることを継続される。

[0052]イベント３で、デバイスＡのユーザは、最前面にＶＴアプリケーションを戻す。このため、時間２１２では、ビデオＲＴＰパケットは、デバイスＢに再び送信される。時間２１４において、デバイスＢは、イベント２におけるユーザダウングレードに起因して、オーディオＲＴＰパケットのみを送信し続ける。しかしながら、ビデオ中断が明示ＳＩＰシグナリングではなくＲＴＣＰパケットを通じて検出されたので、両デバイスは、一方向ビデオ呼が依然として実施されていると正確に決定する。

[0053]図５は、本開示の技法を使用したビデオ中断検出の別の使用ケースに関する別の例となる信号フローを図示している概略図である。時間３０２において、デバイスＡおよびデバイスＢは二方向ＶＴ呼中にあり、ここにおいてオーディオおよびビデオＲＴＣＰパケットとともに、オーディオおよびビデオＲＴＰパケットの両方が送られる。イベント１において、デバイスＡは、背景にＶＴアプリケーションを配置し、それにより、ビデオを中断し、ビデオＲＴＰパケットの送信を中止する。このため、時間３０４では、どのビデオＲＴＰパケットもデバイスＢに送られない。ビデオＲＴＣＰパケットは、デバイスＢに送られることを継続される。上記で説明された本開示の技法に基づいて、デバイスＢは、ビデオＲＴＣＰパケットにおける情報（例えば、ＳＲ）に基づいてビデオ中断が生じたと決定する。図５の例では、時間３０６において、デバイスＢがデバイスＡによるビデオ中断を検出した後、デバイスＢは、デバイスＡにビデオＲＴＰパケットを送ることを中止すると決める。

[0054]イベント２では、デバイスＢのユーザは、一方向モードにＶＴ呼を配置するためにダウングレードオペレーションを実行する。ダウングレードオペレーションに応答して、再ＩＮＶＩＴＥおよび２００ＯＫ ＳＩＰメッセージは、ＶＴ呼を一方向モードにするために時間３０８および３１０で交換される。このため、時間３１２では、どのビデオＲＴＰメッセージもいずれのデバイスからも送られない。オーディオＲＴＰ／ＲＴＣＰメッセージおよびビデオＲＴＣＰメッセージは、送られることを継続される。

[0055]イベント３では、デバイスＡは、例えばユーザ入力に応答して、最前面にＶＴアプリケーションを戻す。このため、時間３１４では、ビデオＲＴＰパケットは、デバイスＢに再び送信される。時間３１６において、デバイスＢは、イベント２におけるユーザダウングレードに起因して、オーディオＲＴＰパケットのみを送信し続ける。しかしながら、ビデオ中断が明示ＳＩＰシグナリングではなくＲＴＣＰパケットを通じて検出されたので、両デバイスは、一方向ビデオ呼が依然として実施されていると正確に決定する。図３における呼／媒体フローと比較されると、図４および図５における各デバイスの状態は、各ステップで決定性があり、ユーザ予測の観点から乱雑さは存在しない。

[0056]図６は、本開示の技法にしたがった例となる方法を図示しているフローチャートである。図６の技法は、図２、１のデバイスＡまたはデバイスＢの１つ以上の構造ユニットまたはプロセッサによって実施されうる。

[0057]図６の例にしたがうと、ビデオ電話呼における受信デバイス（例えば、デバイスＢ）は、受信デバイスにおいて、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを検出するように構成されうる（６００）。受信デバイスはさらに、送信元デバイスが、ビデオ制御パケットに含まれる情報に基づいて、ビデオ電話呼のビデオ部分を中断したと決定するようにさらに構成されうる（６０２）。

[0058]本開示の一例では、ビデオ制御パケットは、ビデオデータパケットが到着するのを停止した後に、受信デバイスにおいて受信され続ける。いくつかの例では、ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである。いくつかの例では、送信元デバイスがビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用されるＲＴＣＰパケットにおける情報は、パケットカウントおよび総データ量のうちの１つ以上である。ＲＴＣＰと一貫したいくつかの例では、パケットカウントは、ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、総データ量は、ＲＴＣＰパケットのＳＲにおける送信側のオクテットカウントである。

[0059]本開示の別の例では、送信元デバイスがビデオ電話呼のビデオ部分を中断したと決定することは、ビデオが中断されたかを決定するために２つの連続するＲＴＣＰパケットにおけるパケットカウントおよび総データ量のうちの１つ以上を比較することを備え、ビデオが中断されたという決定は、パケットカウントおよび総データ量のうちの１つ以上が２つの連続するＲＴＣＰパケットに対して同じである場合に行われる。

[0060]本開示の別の例では、送信元デバイスがビデオ電話呼のビデオ部分を中断したと決定することは、ビデオ制御パケットが受信された後にタイマをスタートすることと、どのビデオデータパケットもタイマのスタートからのしきい値の時間内で受信されなかった場合、送信元デバイスがビデオ電話呼のビデオ部分を中断したと決定することと、を備える。いくつかの例では、しきい値の時間は、２つの連続するビデオ制御パケット間の時間より小さい。

[0061]１つ以上の例では、説明されている機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらのあらゆる組み合わせで実行されうる。ソフトウェアで実行される場合、機能は、コンピュータ可読媒体上で１つ以上の命令またはコードとして記憶または送信され、ハードウェアベースの処理ユニットによって実行されうる。コンピュータ可読媒体はまた、例えば、通信プロトコルにしたがったコンピュータプログラムのある場所から別の場所への転送を容易にするあらゆる媒体を含む通信媒体、またはデータ記憶媒体のような有体の媒体に対応するコンピュータ可読記憶媒体を含むことができる。このように、コンピュータ可読媒体は、概して、（１）非一時的である有体のコンピュータ可読記憶媒体、または（２）信号または搬送波のような通信媒体に対応しうる。データ記憶媒体は、本開示において説明されている技法の実行のための命令、コード、および／またはデータ構造を検索するために、１つ以上のコンピュータ、または１つ以上のプロセッサによってアクセスされうるあらゆる利用可能な媒体でありうる。コンピュータプログラム製品は、コンピュータ可読媒体を含むことができる。

[0062]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光学ディスクストレージ、磁気ディスクストレージ、または他の磁気記憶デバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態で所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされうる何らかの他の媒体を備えることができる。また、あらゆる接続手段は適切にコンピュータ可読媒体と呼ばれる。例えば、命令が、ウェブサイトから、サーバから、あるいは同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）、または赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用している他の遠隔ソースから送信された場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、あるいは赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続手段、搬送波、信号、または他の一時的な媒体を含まないが、代わりとして非一時的な有体の記憶媒体を対象にすることは理解されるべきである。本明細書で使用される場合、ディスク（disk）およびディスク（disc）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光学ディスク、デジタル多目的ディスク（ＤＶＤ）、フロッピー（登録商標）ディスクおよびBlu-ray（登録商標）ディスクを含み、ここでディスク（disk）は、大抵磁気的にデータを再生し、一方ディスク（disc）は、レーザーを用いて光学的にデータを再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれるべきである。

[0063]命令が、１つ以上のデジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または、他の同等な集積またはディスクリートな論理回路、のような１つ以上のプロセッサによって実行されうる。したがって本明細書で使用される場合「プロセッサ」という用語は、前述の構造、または本明細書で説明されている技法の実行に適したあらゆる何らかの他の構造のいずれも指すことができる。加えていくつかの態様では、本明細書で説明されている機能は、符号化および復号のために構成された専用ハードウェアモジュールおよび／またはソフトウェアモジュール内で提供されうる、あるいは組み合わせられたコデックに組み込まれうる。また、技法は、１つ以上の回路あるいは論理要素において十分に実行されうる。

[0064]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い種類のデバイスまたは装置において実行されうる。様々なコンポーネント、モジュール、またはユニットは、開示されている技法を実行するように構成されたデバイスの機能的な態様を強調するために本開示で説明されているが、必ずしも異なるハードウェアユニットによる実現を要求しない。むしろ、上記で説明されたように、様々なユニットがコデックハードウェアユニットで組み合わせられうるか、あるいは適したソフトウェアおよび／またはファームウェアと連携した上記で説明されたような１つ以上のプロセッサを含む、対話型（interoperative）ハードウェアユニットの集合によって提供されうる。

[0065]様々な例が説明されてきた。これらの例および他の例は、次の請求項の範囲内にある。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ビデオ電話のための方法であって、
受信デバイスにおいて、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを検出することと、
前記受信デバイスにおいて、前記送信元デバイスが、ビデオ制御パケットに含まれる情報に基づいて、前記ビデオ電話呼のビデオ部分を中断したと決定することと、
を備える、方法。
［Ｃ２］
前記ビデオ制御パケットは、前記ビデオデータパケットが到着するのを停止した後に、前記受信デバイスにおいて受信され続ける、Ｃ１に記載の方法。
［Ｃ３］
前記ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、前記ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである、Ｃ１に記載の方法。
［Ｃ４］
前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用される前記ＲＴＣＰパケットにおける前記情報は、パケットカウントおよび総データ量のうちの１つ以上である、Ｃ３に記載の方法。
［Ｃ５］
前記パケットカウントは、前記ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、前記総データ量は、前記ＲＴＣＰパケットの前記ＳＲにおける送信側のオクテットカウントである、Ｃ４に記載の方法。
［Ｃ６］
前記受信デバイスにおいて、前記送信元デバイスが、前記ビデオ電話呼の前記ビデオ部分を中断したと決定することは、
前記ビデオが中断されたかを決定するために２つの連続するＲＴＣＰパケットにおける前記パケットカウントおよび前記総データ量のうちの１つ以上を比較することを備え、前記ビデオが中断されたという決定は、前記パケットカウントおよび前記総データ量のうちの１つ以上が前記２つの連続するＲＴＣＰパケットに対して同じである場合に行われる、Ｃ４に記載の方法。
［Ｃ７］
前記受信デバイスにおいて、前記送信元デバイスは、前記ビデオ電話呼の前記ビデオ部分を中断したと決定することは、
ビデオ制御パケットが受信された後にタイマをスタートすることと、
どのビデオデータパケットも前記タイマの前記スタートからのしきい値の時間内で受信されなかった場合に前記送信元デバイスが前記ビデオ電話呼の前記ビデオ部分を中断したと決定することと、
を備える、Ｃ１に記載の方法。
［Ｃ８］
前記しきい値の時間は、２つの連続するビデオ制御パケット間の時間より小さい、Ｃ７に記載の方法。
［Ｃ９］
ビデオ電話のために構成された装置であって、
受信デバイスにおいて、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを検出するための手段と、
前記受信デバイスにおいて、前記送信元デバイスが、ビデオ制御パケットに含まれる情報に基づいて、前記ビデオ電話呼のビデオ部分を中断したと決定するための手段と、
を備える、装置。
［Ｃ１０］
前記ビデオ制御パケットは、前記ビデオデータパケットが到着するのを停止した後に、前記受信デバイスにおいて受信され続ける、Ｃ９に記載の装置。
［Ｃ１１］
前記ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、前記ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである、Ｃ９に記載の装置。
［Ｃ１２］
前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用される前記ＲＴＣＰパケットにおける前記情報は、パケットカウントおよび総データ量のうちの１つ以上である、Ｃ１１に記載の装置。
［Ｃ１３］
前記パケットカウントは、前記ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、前記総データ量は、前記ＲＴＣＰパケットの前記ＳＲにおける送信側のオクテットカウントである、Ｃ１２に記載の装置。
［Ｃ１４］
前記受信デバイスにおいて、前記送信元デバイスが、前記ビデオ電話呼の前記ビデオ部分を中断したと決定するための手段は、
前記ビデオが中断されたかを決定するために２つの連続するＲＴＣＰパケットにおける前記パケットカウントおよび前記総データ量のうちの１つ以上を比較するための手段を備え、前記ビデオが中断されたという決定は、前記パケットカウントおよび前記総データ量のうちの１つ以上が前記２つの連続するＲＴＣＰパケットに対して同じである場合に行われる、Ｃ１２の記載の装置。
［Ｃ１５］
前記受信デバイスにおいて、前記送信元デバイスが、前記ビデオ電話呼の前記ビデオ部分を中断したと決定するための手段は、
ビデオ制御パケットが受信された後にタイマをスタートするための手段と、
どのビデオデータパケットも前記タイマの前記スタートからのしきい値の時間内で受信されなかった場合に前記送信元デバイスが前記ビデオ電話呼の前記ビデオ部分を中断したと決定するための手段と、
を備える、Ｃ９に記載の装置。
［Ｃ１６］
前記しきい値の時間は、２つの連続するビデオ制御パケット間の時間より小さい、Ｃ１５に記載の装置。
［Ｃ１７］
ビデオ電話のために構成された装置であって、
受信デバイスにおいて、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを検出し、
前記送信元デバイスが、ビデオ制御パケットに含まれる情報に基づいて、前記ビデオ電話呼のビデオ部分を中断したと決定する、ように構成された前記受信デバイス、
を備える、装置。
［Ｃ１８］
前記ビデオ制御パケットは、前記ビデオデータパケットが到着するのを停止した後に、前記受信デバイスにおいて受信され続ける、Ｃ１７に記載の装置。
［Ｃ１９］
前記ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、前記ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである、Ｃ１７に記載の装置。
［Ｃ２０］
前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用される前記ＲＴＣＰパケットにおける前記情報は、パケットカウントおよび総データ量のうちの１つ以上である、Ｃ１９に記載の装置。
［Ｃ２１］
前記パケットカウントは、前記ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、前記総データ量は、前記ＲＴＣＰパケットの前記ＳＲにおける送信側のオクテットカウントである、Ｃ２０に記載の装置。
［Ｃ２２］
前記受信デバイスは、
前記ビデオが中断されたかを決定するために２つの連続するＲＴＣＰパケットにおける前記パケットカウントおよび前記総データ量のうちの１つ以上を比較するようにさらに構成され、前記ビデオが中断されたという決定は、前記パケットカウントおよび前記総データ量のうちの１つ以上が前記２つの連続するＲＴＣＰパケットに対して同じである場合に行われる、Ｃ２０に記載の装置。
［Ｃ２３］
前記受信デバイスは、
ビデオ制御パケットが受信された後にタイマをスタートし、
どのビデオデータパケットが、前記タイマの前記スタートからのしきい値の時間内で受信されなかった場合に前記送信元デバイスが前記ビデオ電話呼の前記ビデオ部分を中断したと決定する、
ようにさらに構成される、Ｃ１７に記載の装置。
［Ｃ２４］
前記しきい値の時間は、２つの連続するビデオ制御パケット間の時間より小さい、Ｃ２３に記載の装置。
［Ｃ２５］
命令を記憶するコンピュータ可読記憶媒体であって、前記命令は実行されるとき、ビデオ電話のためのデバイスの１つ以上のプロセッサに、
受信デバイスにおいて、ビデオ電話呼に関連付けられたビデオデータパケットが送信元デバイスから到着するのを停止したことを検出し、
前記受信デバイスにおいて、前記送信元デバイスが、ビデオ制御パケットに含まれる情報に基づいて、前記ビデオ電話呼のビデオ部分を中断したと決定することと、
を行わせる、コンピュータ可読記憶媒体。
［Ｃ２６］
前記ビデオ制御パケットは、前記ビデオデータパケットが到着するのを停止した後に、前記受信デバイスにおいて受信され続ける、Ｃ２５に記載のコンピュータ可読記憶媒体。
［Ｃ２７］
前記ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、前記ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである、Ｃ２５に記載のコンピュータ可読記憶媒体。
［Ｃ２８］
前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用される前記ＲＴＣＰパケットにおける前記情報は、パケットカウントおよび総データ量のうちの１つ以上である、Ｃ２７に記載のコンピュータ可読記憶媒体。
［Ｃ２９］
前記パケットカウントは、前記ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、前記総データ量は、前記ＲＴＣＰパケットの前記ＳＲにおける送信側のオクテットカウントである、Ｃ２８に記載のコンピュータ可読記憶媒体。
［Ｃ３０］
前記命令は、前記１つ以上のプロセッサに、
前記ビデオが中断されたかを決定するために２つの連続するＲＴＣＰパケットにおける前記パケットカウントおよび前記総データ量のうちの１つ以上を比較することをさらに行わせ、前記ビデオが中断されたという決定は、前記パケットカウントおよび前記総データ量のうちの１つ以上が前記２つの連続するＲＴＣＰパケットに対して同じである場合に行われる、Ｃ２８に記載のコンピュータ可読記憶媒体。

Claims (16)

1. ビデオ電話のための方法であって、
   受信デバイスにおいて、送信元デバイスからの、ビデオ電話呼に関連付けられたビデオデータパケットの到着が停止したことを検出することと、
   前記受信デバイスにおいて、ビデオ制御パケットに含まれる情報に基づいて、前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したと決定することと、ここにおいて、前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用される前記ビデオ制御パケットにおける前記情報は、パケットカウントまたは総データ量のうちの１つ以上を含み、前記受信デバイスにおいて、前記送信元デバイスが前記ビデオ電話呼の前記ビデオ部分を中断したと決定することは、前記ビデオ部分が中断されたかを決定するために２つの連続するビデオ制御パケットにおける前記パケットカウントまたは前記総データ量のうちの１つ以上を比較することを備え、前記ビデオ部分が中断されたという決定は、前記パケットカウントまたは前記総データ量のうちの１つ以上が前記２つの連続するビデオ制御パケットに対して同じである場合に行われる、
   を備える、方法。
2. 前記ビデオ制御パケットは、前記ビデオデータパケットの到着が停止した後に、前記受信デバイスにおいて受信され続ける、請求項１に記載の方法。
3. 前記ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、前記ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである、請求項１に記載の方法。
4. 前記パケットカウントは、前記ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、前記総データ量は、前記ＲＴＣＰパケットの前記ＳＲにおける送信側のオクテットカウントである、請求項３に記載の方法。
5. ビデオ電話のために構成された装置であって、
   前記装置において、送信元デバイスからの、ビデオ電話呼に関連付けられたビデオデータパケットの到着が停止したことを検出するための手段と、
   前記装置において、ビデオ制御パケットに含まれる情報に基づいて、前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したと決定するための手段と、ここにおいて、前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用される前記ビデオ制御パケットにおける前記情報は、パケットカウントまたは総データ量のうちの１つ以上を含み、前記装置において、前記送信元デバイスが前記ビデオ電話呼の前記ビデオ部分を中断したと決定するための前記手段は、前記ビデオ部分が中断されたかを決定するために２つの連続するビデオ制御パケットにおける前記パケットカウントまたは前記総データ量のうちの１つ以上を比較するための手段を備え、前記ビデオ部分が中断されたという決定は、前記パケットカウントまたは前記総データ量のうちの１つ以上が前記２つの連続するビデオ制御パケットに対して同じである場合に行われる、
   を備える、装置。
6. 前記ビデオ制御パケットは、前記ビデオデータパケットの到着が停止した後に、前記装置において受信され続ける、請求項５に記載の装置。
7. 前記ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、前記ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである、請求項５に記載の装置。
8. 前記パケットカウントは、前記ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、前記総データ量は、前記ＲＴＣＰパケットの前記ＳＲにおける送信側のオクテットカウントである、請求項７に記載の装置。
9. ビデオ電話のために構成された装置であって、
   受信デバイスを備えており、前記受信デバイスは、
   前記受信デバイスにおいて、送信元デバイスからの、ビデオ電話呼に関連付けられたビデオデータパケットの到着が停止したことを検出することと、
   ビデオ制御パケットに含まれる情報に基づいて、前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したと決定することと、ここにおいて、前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用される前記ビデオ制御パケットにおける前記情報は、パケットカウントまたは総データ量のうちの１つ以上を含み、前記受信デバイスにおいて、前記送信元デバイスが前記ビデオ電話呼の前記ビデオ部分を中断したと決定することは、前記ビデオ部分が中断されたかを決定するために２つの連続するビデオ制御パケットにおける前記パケットカウントまたは前記総データ量のうちの１つ以上を比較することを備え、前記ビデオ部分が中断されたという決定は、前記パケットカウントまたは前記総データ量のうちの１つ以上が前記２つの連続するビデオ制御パケットに対して同じである場合に行われる、
   を行うように構成される、
   装置。
10. 前記ビデオ制御パケットは、前記ビデオデータパケットの到着が停止した後に、前記受信デバイスにおいて受信され続ける、請求項９に記載の装置。
11. 前記ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、前記ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである、請求項９に記載の装置。
12. 前記パケットカウントは、前記ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、前記総データ量は、前記ＲＴＣＰパケットの前記ＳＲにおける送信側のオクテットカウントである、請求項１１に記載の装置。
13. 命令を記憶する非一時的なコンピュータ可読記憶媒体であって、前記命令は実行されるとき、ビデオ電話のためのデバイスの１つ以上のプロセッサに、
    前記デバイスにおいて、送信元デバイスからの、ビデオ電話呼に関連付けられたビデオデータパケットの到着が停止したことを検出することと、
    前記デバイスにおいて、ビデオ制御パケットに含まれる情報に基づいて、前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したと決定することと、ここにおいて、前記送信元デバイスが前記ビデオ電話呼のビデオ部分を中断したかどうかを決定するために使用される前記ビデオ制御パケットにおける前記情報は、パケットカウントまたは総データ量のうちの１つ以上を含み、前記デバイスにおいて、前記送信元デバイスが前記ビデオ電話呼の前記ビデオ部分を中断したと決定することは、前記ビデオ部分が中断されたかを決定するために２つの連続するビデオ制御パケットにおける前記パケットカウントまたは前記総データ量のうちの１つ以上を比較することを備え、前記ビデオ部分が中断されたという決定は、前記パケットカウントまたは前記総データ量のうちの１つ以上が前記２つの連続するビデオ制御パケットに対して同じである場合に行われる、
    を行わせる、非一時的なコンピュータ可読記憶媒体。
14. 前記ビデオ制御パケットは、前記ビデオデータパケットの到着が停止した後に、前記デバイスにおいて受信され続ける、請求項１３に記載のコンピュータ可読記憶媒体。
15. 前記ビデオデータパケットは、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットであり、前記ビデオ制御パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）パケットである、請求項１３に記載のコンピュータ可読記憶媒体。
16. 前記パケットカウントは、前記ＲＴＣＰパケットの送信側報告（ＳＲ）における送信側のパケットカウントであり、前記総データ量は、前記ＲＴＣＰパケットの前記ＳＲにおける送信側のオクテットカウントである、請求項１５に記載のコンピュータ可読記憶媒体。

Images