(57)【要約】  様々な実施形態は、複数の個別のソースRTPストリームに対する復元保護を提供するために単一の修復フローが使用され得る、「バンドルされたFEC保護」を可能にする。本実施形態の技法は、複数のRTPフローに対して単一の修復フローが定義されることを可能にする新規なFECソースペイロードおよび修復ペイロードの定義を利用し得る。たとえば、FEC FRAMEラプターコードオプションは、現在、複数のリアルタイムトランスポートプロトコル(RTP)同期ソース(SSRC)を介して複数のメディアタイプのバンドルされた保護の場合に対処しないので、単一のFEC RTPストリームが複数のソースRTPストリームに対してそれらのコンテンツタイプ(たとえば、オーディオまたはビデオ)にかかわらず冗長性を与えるように構成されることを可能にするために、RTPストリームヘッダエクステンションが利用され得る。そのようなエクステンションに基づいて、本実施形態の技法は、一意のシーケンス番号空間をそれぞれ有するマルチプルソースRTPストリームの保護を可能にする。
2018518869.tif 000002
【特許請求の範囲】
【請求項１】
単一の前方誤り訂正(FEC)リアルタイムプロトコル(RTP)ストリームを使用して複数のRTPストリームを保護するためにFECを拡張するための方法であって、
送信側コンピューティングデバイスのプロセッサを介して受信側コンピューティングデバイスとセッション初期化データを交換するステップと、
前記プロセッサを介して、前記複数のソースRTPストリームに対するソースRTPストリームデータを生成するステップと、
前記プロセッサを介して、前記複数のソースRTPストリームに対応するFEC RTPストリームに対するFEC RTPストリームデータを生成するステップと、
前記複数のソースRTPストリームおよび前記FEC RTPストリームを前記受信側コンピューティングデバイスに送信するステップとを含む、方法。
【請求項２】
前記プロセッサを介して、ソースFECペイロード識別子(ID)を含むように前記複数のソースRTPストリームの各々のヘッダエクステンションを調整するステップをさらに含む、請求項1に記載の方法。
【請求項３】
前記プロセッサを介して、修復FECペイロード識別子(ID)を含むように前記FEC RTPストリームを調整するステップをさらに含む、請求項2に記載の方法。
【請求項４】
前記プロセッサを介して、前記複数のソースRTPストリームに対する前記FEC RTPストリームの修復ブロックを構築するステップであって、前記修復ブロックは前記ソースRTPストリームの各々に対する少なくともフロー識別子、長さインジケータおよびs値を含む、構築するステップと、
前記プロセッサを介して、前記FEC RTPストリームのペイロードフォーマットをバンドルされたメディアタイプとして登録するステップとをさらに含む、請求項1に記載の方法。
【請求項５】
前記複数のソースRTPストリームの各々が、オーディオストリームおよびビデオストリームのうちの1つである、請求項1に記載の方法。
【請求項６】
前記セッション初期化データが、セッション記述プロトコル(SDP)データを含む、請求項1に記載の方法。
【請求項７】
単一の前方誤り訂正(FEC)リアルタイムプロトコル(RTP)ストリームを使用して複数のRTPストリームを保護するためにFECを拡張するための方法であって、
受信側コンピューティングデバイスのプロセッサを介して送信側コンピューティングデバイスから複数のソースRTPストリームおよびFEC RTPストリームを受信するステップと、
前記プロセッサを介して、ソースブロックデータが前記複数のソースRTPストリームのいずれかから消失しているかどうかを決定するステップと、
前記プロセッサを介して、消失したソースブロックデータが存在するとの決定に応答して、消失したソースブロックデータを前記FEC RTPストリームの修復ブロックから取り出すステップと、
前記プロセッサを介して、前記複数のソースRTPストリームの前記データを使用するステップとを含む、方法。
【請求項８】
前記複数のソースRTPストリームの各々が、オーディオストリームおよびビデオストリームのうちの1つである、請求項7に記載の方法。
【請求項９】
トランシーバと、
前記トランシーバに結合されたプロセッサとを備え、前記プロセッサが、
受信側コンピューティングデバイスとセッション初期化データを交換するステップと、
複数のソースリアルタイムプロトコル(RTP)ストリームに対するソースRTPストリームデータを生成するステップと、
前記複数のソースRTPストリームに対応するFEC RTPストリームに対する前方誤り訂正(FEC)RTPストリームデータを生成するステップと、
前記複数のソースRTPストリームおよび前記FEC RTPストリームを前記受信側コンピューティングデバイスに送信するステップとを含む動作を実行するためのプロセッサ実行可能命令で構成される、コンピューティングデバイス。
【請求項１０】
前記プロセッサが、
ソースFECペイロード識別子(ID)を含むように前記複数のソースRTPストリームの各々のヘッダエクステンションを調整するステップをさらに含む動作を実行するためのプロセッサ実行可能命令で構成される、請求項9に記載のコンピューティングデバイス。
【請求項１１】
前記プロセッサが、
修復FECペイロード識別子(ID)を含むように前記FEC RTPストリームを調整するステップをさらに含む動作を実行するためのプロセッサ実行可能命令で構成される、請求項10に記載のコンピューティングデバイス。
【請求項１２】
前記プロセッサが、
前記複数のソースRTPストリームに対する前記FEC RTPストリームの修復ブロックを構築するステップであって、前記修復ブロックは前記ソースRTPストリームの各々に対する少なくともフロー識別子、長さインジケータおよびs値を含む、構築するステップと、
前記プロセッサを介して、前記FEC RTPストリームのペイロードフォーマットをバンドルされたメディアタイプとして登録するステップとをさらに含む動作を実行するためのプロセッサ実行可能命令で構成される、請求項9に記載のコンピューティングデバイス。
【請求項１３】
前記複数のソースRTPストリームの各々が、オーディオストリームおよびビデオストリームのうちの1つである、請求項9に記載のコンピューティングデバイス。
【請求項１４】
前記セッション初期化データが、セッション記述プロトコル(SDP)データを含む、請求項9に記載のコンピューティングデバイス。
【請求項１５】
トランシーバと、
前記トランシーバに結合されたプロセッサとを備え、前記プロセッサが、
送信側コンピューティングデバイスから複数のソースリアルタイムプロトコル(RTP)ストリームおよび前方誤り訂正(FEC)RTPストリームを受信するステップと、
ソースブロックデータが前記複数のソースRTPストリームのいずれかから消失しているかどうかを決定するステップと、
消失したソースブロックデータが存在するとの決定に応答して、消失したソースブロックデータを前記FEC RTPストリームの修復ブロックから取り出すステップと、
前記複数のソースRTPストリームの前記データを使用するステップとを含む動作を実行するためのプロセッサ実行可能命令で構成される、コンピューティングデバイス。
【請求項１６】
前記複数のソースRTPストリームの各々が、オーディオストリームおよびビデオストリームのうちの1つである、請求項15に記載のコンピューティングデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、その内容全体が参照により本明細書に組み込まれる、2015年5月1日に出願した「Bundled Forward Flow Error Correction (FEC) for Multiple Sequenced Flows」と題する米国仮出願第62/155,639号の優先権の利益を主張するものである。
【背景技術】
【０００２】
前方誤り訂正(FEC)は、データが通信リンクを介して送られることに対する信頼性を与えるためのメカニズムである。従来のFEC技法の場合、データ通信の信頼性を確保するために、再送信プロトコルにあまり依存しない場合がある。なぜならば、データ通信自体が、通信の消失した、またはさもなければアクセス不可能な部分(またはパケット)を復元するのに適切な、冗長な符号化された情報を含み得るからである。インターネットエンジニアリングタスクフォースのFECフレームワーク(「FEC FRAME」と呼ばれる)によって定義されるような、任意のストリーミングプロトコルに対するFECフレームワークが存在する。具体的には、FEC FRAMEは、リアルタイムプロトコル(RTP)ストリームの各パケットに対するシーケンス番号(すなわち、パケット識別子(「ID」))を利用するRTPなどのシーケンス化プロトコルとともに使用するためのいくつかのFEC機能を提供することができる。ストリーミングのためのそのようなFECは、リードソロモン(Reed-Solomon)、ラプター(Raptor)、ラプターキュー(RaptorQ)および低密度パリティ検査コード(LDPC)など、様々な標準化FECを利用してよい。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】2005年12月付けの「Media Type Specifications and Registration Procedures」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書4288(「RFC4288」)
【非特許文献２】2007年2月付けの「Media Type Registration of RTP Payload Formats」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書4855(「RFC4855」)
【非特許文献３】2007年10月付けの「Raptor Forward Error Correction Scheme for Object Delivery」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書5053(「RFC5053」)
【非特許文献４】2008年7月付けの「A General Mechanism for RTP Header Extensions」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書5285(「RFC5285」)
【非特許文献５】2011年8月付けの「RaptorQ Forward Error Correction Scheme for Object Delivery」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6330(「RFC6330」)
【非特許文献６】2011年10月付けの「Forward Error Correction (FEC) Framework」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6363(「RFC6363」)
【非特許文献７】2011年10月付けの「Session Description Protocol Elements for the Forward Error Correction (FEC) Framework」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6364(「RFC6364」)
【非特許文献８】2012年8月付けの「Raptor Forward Error Correction (FEC) Schemes for FECFRAME」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6681(「RFC6681」)
【非特許文献９】2012年8月付けの「RTP Payload Format for Raptor Forward Error Correction (FEC)」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6682(「RFC6682」)
【非特許文献１０】「FEC FRAME Raptor Extensions for Multiple RTP Synchronization Sources」
【発明の概要】
【課題を解決するための手段】
【０００４】
様々な実施形態は、単一のFEC RTPストリームを使用して複数のリアルタイムプロトコル(RTP)ストリームを保護するために前方誤り訂正(FEC)を拡張するための方法およびコンピューティングデバイスを含む。様々な実施形態は、送信側コンピューティングデバイスのプロセッサを介して受信側コンピューティングデバイスとセッション初期化データを交換するステップと、プロセッサを介して、複数のソースRTPストリームに対するソースRTPストリームデータを生成するステップと、プロセッサを介して、複数のソースRTPストリームに対応するFEC RTPストリームに対するFEC RTPストリームデータを生成するステップと、複数のソースRTPストリームおよびFEC RTPストリームを受信側コンピューティングデバイスに送信するステップとを含む場合がある。いくつかの実施形態は、プロセッサを介して、ソースFECペイロード識別子(ID)を含むように複数のソースRTPストリームの各々のヘッダエクステンションを調整するステップをさらに含む場合がある。いくつかの実施形態は、プロセッサを介して、修復FECペイロード識別子(ID)を含むようにFEC RTPストリームを調整するステップをさらに含む場合がある。
【０００５】
いくつかの実施形態は、複数のソースRTPストリームに対するFEC RTPストリームの修復ブロックをプロセッサを介して構築するステップであって、修復ブロックはソースRTPストリームの各々に対する少なくともフロー識別子、長さインジケータおよびs値を含む、構築するステップと、FEC RTPストリームのペイロードフォーマットをバンドルされたメディアタイプとしてプロセッサを介して登録するステップとをさらに含む場合がある。
【０００６】
いくつかの実施形態では、複数のソースRTPストリームの各々は、オーディオストリームおよびビデオストリームのうちの1つである。いくつかの実施形態では、セッション初期化データは、セッション記述プロトコル(SDP)データを含む。
【０００７】
様々な実施形態は、受信側コンピューティングデバイスのプロセッサを介して送信側コンピューティングデバイスから複数のソースRTPストリームおよびFEC RTPストリームを受信するステップと、プロセッサを介して、ソースブロックデータが複数のソースRTPストリームのいずれかから消失しているかどうかを決定するステップと、プロセッサを介して、消失したソースブロックデータが存在するとの決定に応答して、消失したソースブロックデータをFEC RTPストリームの修復ブロックから取り出すステップと、プロセッサを介して、複数のソースRTPストリームのデータを使用するステップとを含む場合がある。いくつかの実施形態では、複数のソースRTPストリームの各々は、オーディオストリームおよびビデオストリームのうちの1つである。
【０００８】
さらなる実施形態は、トランシーバとプロセッサとを含む送信側コンピューティングデバイスを含み、プロセッサは、複数のソースRTPストリームおよびFEC RTPストリームを生成して上記で要約された受信側コンピューティングデバイスに送信するステップのための方法の動作を実行するためのプロセッサ実行可能命令で構成される。
【０００９】
さらなる実施形態は、トランシーバとプロセッサとを含む受信側コンピューティングデバイスを含み、プロセッサは、複数のソースRTPストリームおよびFEC RTPストリームを上記で要約された送信側コンピューティングデバイスから受信して処理するステップの方法の動作を実行するためのプロセッサ実行可能命令で構成される。
【００１０】
本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、特許請求の範囲の様々な実施形態を示し、上記に与えた一般的な説明および下記の発明を実施するための形態とともに、特許請求の範囲の特徴を説明するのに役立つ。
【図面の簡単な説明】
【００１１】
【図１Ａ】コンピューティングデバイス間の従来のRTPストリーム交換を示す図である。
【図１Ｂ】コンピューティングデバイス間の従来のRTPストリーム交換を示す図である。
【図２】いくつかの実施形態による複数のソースRTPストリームと一緒に送信されるバンドルされたFEC RTPストリームを示す図である。
【図３Ａ】バンドルされたFEC RTPストリームとともにヘッダエクステンションを有するソースRTPストリームを交換するためのコンピューティングデバイスのための実施形態の方法を示すプロセスフロー図である。
【図３Ｂ】いくつかの実施形態において使用するのに適したヘッダエクステンションを有するソースRTPストリームに対応するバンドルされたFEC RTPストリームを示すSDPデータの図である。
【図４Ａ】バンドルされたFEC RTPストリームを有するRTPストリームを交換するためのコンピューティングデバイスのための実施形態の方法を示すプロセスフロー図である。
【図４Ｂ】いくつかの実施形態において使用するのに適したFECペイロードの図である。
【図４Ｃ】いくつかの実施形態において使用するのに適したソースRTPストリームに対応するバンドルされたFEC RTPストリームを示すSDPデータの図である。
【図５Ａ】様々な構成におけるバンドルされたFEC RTPストリームを有するRTPストリームを送信するための送信側コンピューティングデバイスのための実施形態の方法を示すプロセスフロー図である。
【図５Ｂ】様々な構成におけるバンドルされたFEC RTPストリームを有するRTPストリームを受信するための受信側コンピューティングデバイスのための実施形態の方法を示すプロセスフロー図である。
【図６】いくつかの実施形態において使用するのに適したモバイルコンピューティングデバイスの構成要素ブロック図である。
【図７】いくつかの実施形態において使用するのに適したサーバコンピューティングデバイスの構成要素ブロック図である。
【発明を実施するための形態】
【００１２】
添付の図面を参照して、様々な実施形態が詳細に説明される。可能な場合はいつでも、同じまた同様の部分を指すために、図面全体を通して同じ参照番号が使用される。特定の例および実装形態になされる参照は、説明のためであり、特許請求の範囲を限定することを意図していない。
【００１３】
「コンピューティングデバイス」という用語は、本明細書において、少なくとも1つのプロセッサを備えた電子デバイスを指すために使用される。コンピューティングデバイスの例としては、モバイルデバイス(たとえば、セルラー電話、ウェアラブルデバイス、スマートフォン、ウェブパッド、タブレットコンピュータ、インターネット対応セルラー電話、Wi-Fi(登録商標)対応電子デバイス、携帯情報端末(PDA)、ラップトップコンピュータなど)、パーソナルコンピュータ、およびサーバコンピューティングデバイスがあり得る。様々な実施形態では、コンピューティングデバイスは、メモリまたはストレージならびにワイドエリアネットワーク(WAN)接続(たとえば、セルラーネットワーク接続など)および/またはローカルエリアネットワーク(LAN)接続(たとえば、Wi-Fi(登録商標)ルータなどを介したインターネットへのワイヤード/ワイヤレス接続)を確立するように構成されたネットワークトランシーバおよびアンテナなどのネットワーキング機能で構成され得る。様々な実施形態とともに使用するのに適したモバイルコンピューティングデバイスが、図6を参照しながら以下で説明される。
【００１４】
「サーバ」という用語は、マスタ交換サーバ、ウェブサーバ、メールサーバ、ドキュメントサーバ、およびサーバ機能を実行するためにソフトウェアを用いて構成されたパーソナルまたはモバイルのコンピューティングデバイス(たとえば、「ライトサーバ」)など、サーバとして機能することが可能な任意のコンピューティングデバイスを指すのに使用される。サーバは、専用コンピューティングデバイスであっても、または(たとえば、コンピューティングデバイスにサーバとして動作させ得るアプリケーションを実行する)サーバモジュールを含むコンピューティングデバイスであってもよい。サーバモジュール(または、サーバアプリケーション)は、全機能搭載サーバモジュールであっても、またはライトサーバモジュールもしくは2次サーバモジュール(たとえば、ライトサーバアプリケーションもしくは2次サーバアプリケーション)であってもよい。ライトサーバまたは2次サーバは、スマートフォンなどのパーソナルまたはモバイルのコンピューティングデバイス上で実施することができ、それによって本明細書において説明する機能を実現するのに必要であるような限られた程度に、パーソナルまたはモバイルのコンピューティングデバイスをインターネットサーバ(たとえば、エンタープライズ電子メールサーバ)として機能させるのを可能にするサーバ型機能のスリムダウンバージョンであってもよい。様々な実施形態とともに使用するのに適したサーバが、図7を参照しながら以下で説明される。
【００１５】
「ソースストリーム」または「ソースRTPストリーム」または「ソースフロー」という用語は、本明細書では、データの様々なソースブロックからなるデータストリームを指すために互換的に使用される。ソースストリームの例は、ストリーミングメディアサービス(たとえば、ストリーミングムービー、ラジオ、など)を提供するために使用され得るオーディオおよびビデオデータストリーム、および/またはネットワーキング接続(たとえば、インターネット、P2P、など)を介してコンピューティングデバイス間で送信されるテレフォニー通信(たとえば、インターネットプロトコル(IP)オーディオ/ビデオチャット)を提供するために使用され得るオーディオおよびビデオデータストリームを含む場合がある。「修復ストリーム」または「FEC RTPストリーム」または「修復フロー」または「FECフロー」という用語は、本明細書では、ソースストリームに対応する冗長データからなるデータストリームを指すために互換的に使用される。たとえば、FECストリームは、ソースストリームの消失、喪失および/または破損したデータを修復、置換または場合によっては補償するために受信デバイスによって使用され得る様々な修復ブロックを含む場合がある。
【００１６】
本出願の実施形態の技法は、リアルタイムプロトコル(RTP)データストリームに関する前方誤り訂正(FEC)に対する新規な改善に取り組み、したがって様々な従来のまたは標準的FECおよび/またはRTP概念を改善する。したがって、以下の説明では、以下の文献、  2005年12月付けの「Media Type Specifications and Registration Procedures」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書4288(「RFC4288」)、2007年2月付けの「Media Type Registration of RTP Payload Formats」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書4855(「RFC4855」)、2007年10月付けの「Raptor Forward Error Correction Scheme for Object Delivery」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書5053(「RFC5053」)、2008年7月付けの「A General Mechanism for RTP Header Extensions」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書5285(「RFC5285」)、2011年8月付けの「RaptorQ Forward Error Correction Scheme for Object Delivery」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6330(「RFC6330」)、2011年10月付けの「Forward Error Correction (FEC) Framework」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6363(「RFC6363」)、2011年10月付けの「Session Description Protocol Elements for the Forward Error Correction (FEC) Framework」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6364(「RFC6364」)、2012年8月付けの「Raptor Forward Error Correction (FEC) Schemes for FECFRAME」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6681(「RFC6681」)、および2012年8月付けの「RTP Payload Format for Raptor Forward Error Correction(FEC)」と題するインターネットエンジニアリングタスクフォース(IETF)コメント要請(RFC)文書6682(「RFC6682」)の中で記述されるかまたはそれらに関連する様々な概念(たとえば、仕様、フォーマット、規格)に対する参照が行われてよい。
【００１７】
概して、RTPストリーム内のパケットロスに対して保護するために、従来のFEC技法を実装するコンピューティングデバイスは、ソースストリームをデータのソースブロックに区分することができ、それは、ソースストリームが利用可能になるとオンザフライで実行され得る。コンピューティングデバイスは、パケットロスに対する保護を提供するためにソースブロックデータに基づいてソースブロックのデータとFEC修復情報を含む符号化ブロックを生成してよい。符号化ブロックは、ソースストリームに対応する修復ストリーム内で送信されてよく、それによって受信側デバイスは、ソースストリーム内に何らかのパケットロスが存在するときにソースブロックを潜在的に復元し得る。一般的には、より小さいソースブロックを利用するFECストリーミング技法は、より小さいソースブロックが符号化ブロックに対して符号化すべきデータの量を低減するにつれて、エンドツーエンドのレイテンシの改善がもたらされ得る。しかしながら、より小さいソースブロックによる誤り回復の可能性は制限される。より大きいソースブロックによって、FECストリーミング技法は、より良い復元性能を有するが、より広い帯域幅を必要とする場合がある。概して、複数のRTPストリームは、ファイアウォールによってブロックされ、かなりの帯域幅を必要とし、またはさもなければブロードバンドネットワークによって禁止される場合があるので、複数のRTPストリームは好ましくない場合がある。
【００１８】
FEC FRAMEは、RTPストリーム(すなわち、ソースRTPストリーム)など、シーケンス化データフローのサポートを可能にする特定のコードオプションを提供する。そのような場合、送信側コンピューティングデバイスは、ソースRTPストリームを修正することなく送ってよく、また、FEC RTPストリームがソースRTPストリームに戻って参照することを可能にするデータ(すなわち、「修復FECペイロードID」)を含むソースRTPストリームに関連する別個の修復FEC RTPストリームを送ってもよい。具体的には、修復FECペイロードIDは、FEC RTPストリームの各修復パケットの生成に使用されたソースRTPストリームの初期RTPパケットのシーケンス番号を識別し得る。そのような従来の実装形態は、一般的に、1対1(すなわち、1ソースフローに対して1修復フロー)において冗長性をもたらす。
【００１９】
図1A〜図1Bは、コンピューティングデバイス間の従来のRTPストリーム交換を示す。従来のRTPストリームによって、シーケンス番号が、パケットを識別する目的で送出される各パケットに割り当てられ得る。個別のソースRTPストリームからそのようなシーケンス番号を識別し得るFEC RTPストリーム(または「修復ストリーム」)が、生成され得る。しかしながら、従来のFEC RTPストリームは、単一のソースストリームのみに対する冗長性(たとえば、ビデオストリームのためまたはオーディオストリームのためだけの保護)を提供するように構成される。
【００２０】
図1Aは、そのような従来のシナリオ100を示しており、ソースRTPストリーム104、106に関連する複数のFEC RTPストリーム105、107を受信側コンピューティングデバイス120(たとえば、スマートフォンモバイルデバイス、タブレット、ラップトップ、など)に送信する、送信側コンピューティングデバイス102(たとえば、メディアストリーミングサーバ、など)が示されている。ストリーム104、105、106、107は、ワイヤードまたはワイヤレス接続を使用してローカルエリアネットワーク、セルラーネットワーク、インターネットなどのネットワーク110に送信され得る。送信側コンピューティングデバイス102は、第1のソースRTPストリーム104のソースブロックに対する冗長データを有する修復ブロックを含む第1のFEC RTPストリーム105、ならびに第2のソースRTPストリーム106のソースブロックに対する冗長データを有する修復ブロックを含む第2のFEC RTPストリーム107を送信するように構成されてよい。この構成は、ソースRTPストリーム104、106のパケットロスを回避するための何らかのメカニズムを提供する。しかしながら、この構成は、多数の総RTPストリームを必要とする場合がある。そのような要件は、帯域幅および/またはネットワーク事業者/通信事業者の仕様もしくは他の制限に対して準最適である場合がある。図1Aに示すシナリオは、ピアツーピア(P2P)ビデオ-オーディオ呼(たとえば、「ウェブリアルタイム通信」(WebRTC)技術)を行うためのブラウザアプリケーションの従来の使用において利用され得る。
【００２１】
いくつかのシナリオでは、ソースコンテンツは、送信されるストリームの数を低減するために組み合わされるかまたは混合され、単一のFEC RTPストリームの使用を可能にする。具体的には、RFC6681は、複数のソースからなる単一のソースRTPストリームの保護を可能にする従来の技法を記述しており、この技法では、複数のソースの各々は、協調ソース(CSRC)RTPヘッダによって識別可能であり得る。
【００２２】
図1Bはそのような従来のシナリオ150を示しており、単一のFEC RTPストリーム155を関連する混合ソースRTPストリーム152とともに送信する送信側コンピューティングデバイス102(たとえば、サーバ)が示されている。たとえば、混合ソースRTPストリーム152は、送信側コンピューティングデバイス102によって一緒に混合された複数のオーディオストリームを含み得る。たとえば、送信側コンピューティングデバイス102は、電話会議の複数の話者に対応する複数のオーディオトラックを組み合わせてよい。FEC RTPストリーム155は、混合ソースRTPストリーム152の消失/喪失したデータの復元のための冗長性を与えるように構成されてよい。しかしながら、この技法は価値が限られる場合がある。なぜならば、FEC RTPストリームは単一ではあるが組み合わされたソースストリームにアドレスをアドレス指定するだけであるので、送信側コンピューティングデバイス102および受信側コンピューティングデバイス120は、組み合わされたソースデータを混合して処理するために追加のリソースを消費する必要があり得るからである。さらに、組み合わされたソースストリームは、一般的に同じタイプのストリーム(たとえば、すべてオーディオストリーム)のためであるので、そのような技法は準最適である場合がある。したがって、これらの技法は、異なるメディアタイプ(たとえば、オーディオストリームおよびビデオストリーム)の送信に対する単一のFECサポートを提供しない。
【００２３】
上述の従来のFEC技法の限界に対処するために、様々な実施形態は、単一の修復フローが複数の個別のソースRTPストリームに対する復元保護を提供するために使用され得る「バンドルされたFEC保護」のための方法、デバイス、システムおよび非一時的プロセッサ可読記憶媒体を提供する。したがって、複数のソースRTPストリームのバンドルされたFEC保護は、現在の規格(たとえば、RFC6681で定義される規格)によってRTPに対して正確に定義されることはなく、本実施形態は、マルチプルRTPソースストリームに対するFEC保護をサポートするためにFEC FRAMEに対するプロトコルエクステンションを利用する場合がある。言い換えれば、本実施形態の技法は、単一の修復フローが複数のRTPフローに対して定義されることを可能にする新規なFECソースペイロードおよび修復ペイロードの定義を利用する場合がある。たとえば、FEC FRAMEラプターコードオプションは、現在、複数のリアルタイムトランスポートプロトコル(RTP)同期ソース(SSRC)を介して複数のメディアタイプのバンドルされた保護の場合に対処しないので、RTPストリームヘッダエクステンションは、単一のFEC RTPストリームが、複数のソースRTPストリームに対してそれらのコンテンツタイプ(たとえば、オーディオまたはビデオ)にかかわらず冗長性を与えるように構成されることを可能にするために利用される場合がある。そのようなエクステンションに基づいて、本実施形態の技法は、一意のシーケンス番号空間をそれぞれ有するマルチプルソースRTPストリームの保護を可能にする。
【００２４】
いくつかの実施形態では、バンドルされたFEC保護は、ソースRTPストリームのRTPヘッダエクステンション内の明示的ソースFECペイロードID(すなわち、「明示的ソース識別」技法)を使用して達成される場合がある。そのようなRTPヘッダエクステンションは、ソースペイロードID(ヘッダエクステンション内に書き込まれる)を識別してよく、それによってソースRTPストリームおよびそれらの関連するFEC RTPストリームの受信側コンピューティングデバイスは、ソースペイロードIDに基づいて修復ペイロードとソースペイロードとを照合させ得る。この明示的ソース識別技法は、ソースRTPストリームに対する修正を必要とする場合がある。
【００２５】
いくつかの実施形態では、バンドルされたFEC保護は、ソースRTPストリームに対する十分な参照を含むようにFEC RTPストリームを構成することによって達成されてよく、それによってRTPヘッダエクステンションは、他の実施形態におけるように使用される必要はない(すなわち、「暗示的ソース識別」技法)。そのような実装形態は、ソースRTPストリーム(またはそれらのヘッダ構造)を修正しないが、代わりに、FEC RTPストリームの修復ペイロードの作成に伴うすべてのソースRTPストリームを識別し得る異なるタイプのFEC修復IDを定義および利用する場合がある。この暗示的ソース識別技法は、ソースRTPストリームに対する修正を必要としない。
【００２６】
本実施形態の技法は、単一のFECストリームが異なるタイプのメディア(たとえば、オーディオおよびビデオ)に対する保護を同時に提供することを可能にすることによって有益であり得る。本実施形態の技法は、より大きいペイロードを利用することによってさらに有益になる場合があり、FECコードは、一般的にペイロード/ストリームが大きくなるにつれてより良く働くので復元可能性をより大きくさせる。たとえば、FECストリームが単一のオーディオソースRTPストリームをサポートするために与えられる場合、そのソースペイロードに対応する修復ペイロードはかなり小さくなり、ペイロードが小さいチャンクに分裂されることを生じ、したがって低下したFECの有益性をもたらす場合がある。しかしながら、FECストリームが、一般的にはるかに大きいソースペイロードサイズを有するオーディオとビデオの両ストリームに対処した場合、FEC動作はより効率的であり得る。さらに、様々な実施形態によって可能にされるバンドルされたFEC保護は、全RTPストリームカウントをより低く保持し、したがって帯域幅の使用を改善する場合がある。なぜならば、個別のソースストリームと修復ストリームとの間の1対1の関係は必要ないからである。
【００２７】
図2は、様々な実施形態による、バンドルされたFEC RTPストリーム202が、複数のソースRTPストリーム104、106と一緒に送信されるシナリオ200を示す。具体的には、送信側コンピューティングデバイス102は、第1のソースRTPストリーム104と第2のソースRTPストリーム106の両方のソースブロックに対する冗長データを有する修復ブロックを含むFEC RTPストリーム202を送信するように構成されてよい。これは、パケットロスを回避するためのメカニズムを提供し、それによって、受信側コンピューティングデバイス120は、FEC RTPストリーム202からのソースRTPストリーム104、106の両方から消失/破損したデータを取得し得る。そのようなシナリオは、図3A〜図3Bを参照しながら以下でさらに説明する明示的ソース識別技法か、または図4A〜図4Cを参照しながら以下でさらに説明する暗示的ソース識別技法のいずれかを使用して実装され得る。
【００２８】
任意のマルチシーケンス化ソースストリームは、ソースがソースFECペイロードIDを明示的に使用して(たとえば、RFC6681のセクション6内で定義されるソースペイロードと一緒にソースFECペイロードIDを送る)識別される場合に保護され得る。しかしながら、ソースストリームヘッダ情報は、消失したパケットを復元するために単一のFEC内のデータと組み合わせて使用され得るようなソース情報を含むように修正されてよい。具体的には、ソースFECペイロードIDは、送信側コンピューティングデバイスから受信側コンピューティングデバイスに送信されたソースRTPストリームのヘッダエクステンション内で送られてよい。図3A〜図3Bは、ソースRTPストリームが、ソースFECペイロードIDを与えるためにヘッダエクステンションを含むように修正され得るような実施形態を取り上げる。
【００２９】
図3Aは、バンドルされたFEC RTPストリームとともにヘッダエクステンションを有するソースRTPストリームを交換するためのコンピューティングデバイスに対する実施形態の方法300および330(すなわち、「明示的ソース識別」技法)を示す。方法300の動作は送信側コンピューティングデバイス102のプロセッサによって実行されてよく、方法330の動作は受信側コンピューティングデバイス120のプロセッサによって実行されてよい。様々なシナリオでは、任意のコンピューティングデバイスは、方法300、330に従って送ることまたは受信することのいずれかを行うように構成されてよい。様々な実施形態では、方法300、330は、RFC6681内で記述されるシンタックス/フォーマッティングを利用する修復ペイロードIDを含むFEC RTPストリーム、およびRFC6681内で記述されるシンタックス/フォーマッティングを同様に利用するソースペイロードIDを含むソースRTPストリーム、ならびにRFC5285に基づく拡張RTPヘッダ(またはヘッダエクステンション)を利用してよい。
【００３０】
送信側コンピューティングデバイス102のプロセッサは、方法300のブロック301においてオファー/アンサーを受信側コンピューティングデバイス120と交換してよく、同様に、受信側コンピューティングデバイス120のプロセッサは、方法330のブロック331においてオファー/アンサーを送信側コンピューティングデバイス102と交換してよい。ブロック301および331の動作はセッション初期化(またはセッション開始)動作と見なされてよく、そこにおいて、両デバイスは、セッション初期化データを交換し、複数のソースRTPストリームに対するバンドルされたFEC保護がFEC RTPストリームを介して実施され得るかどうかを決定するために、セッション記述プロトコル(SDP)などのプロトコルを使用してよい。
【００３１】
方法300に戻ると、送信側コンピューティングデバイス102は、ブロック302においてオーディオストリームデータ、ビデオストリームデータなどのソースRTPストリーム(またはストリームデータ)を生成してよい。ブロック304において、送信側コンピューティングデバイス102は、受信側コンピューティングデバイス120に送るために複数のソースRTPストリームの次のソースRTPストリーム(すなわち、N-カウントストリーム)を選択してよい。たとえば、方法300の動作ループの第1の反復に対して、送信側コンピューティングデバイス102は、ソースRTPストリームのリスト中の第1のソースRTPストリームを選択してよい。ブロック306において、送信側コンピューティングデバイス102は、ソースFECペイロードIDデータを含むように、選択されたソースRTPストリーム(または選択されたソースRTPストリーム内のソースデータ)のヘッダエクステンションを調整してよい。例示的なヘッダエクステンションに対するデータは、SDP行「a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:SourceID」などによって、送信側コンピューティングデバイスにおいて受信されたSDPデータ内で定義され得る。ソースFECペイロードIDは、各ソースRTPソースストリームパケットに対するRTPヘッダエクステンション内で使用されてよい。
【００３２】
いくつかの実施形態では、ソースFECペイロードIDは32ビット長(すなわち、4バイト)であってよく、それによって1バイトのヘッダエクステンションの解法(RFC5285のセクション4.2において定義される)は、ソースFECペイロードIDを識別するのに十分であり得る。いくつかの実施形態では、2バイトのヘッダエクステンションは、たとえば8ビットのエクステンションID符号化のために必要であるときに、RFC5285のセクション4.3において与えられるように使用さる場合がある。いくつかの実施形態では、ソースFECペイロードIDは、RFC6681のセクション6.2.2において定義される場合がある。
【００３３】
決定ブロック308において、送信側コンピューティングデバイス102は、処理すべきソースRTPストリームがまだ存在するかどうかを決定し得る。処理すべきソースRTPストリームがまだ存在すると決定した(すなわち、決定ブロック308=「Yes」)ことに応答して、送信側コンピューティングデバイス102は、ブロック304における動作によって別のソースRTPストリームの選択を継続してよい。
【００３４】
処理すべきソースRTPストリームがもうないと決定した(すなわち、決定ブロック308=「No」)ことに応答して、送信側コンピューティングデバイス102は、ブロック310において調整されたソースRTPストリームに対するFEC RTPストリーム(またはFEC RTPストリームデータ)を確立/生成してよい。ブロック312において、送信側コンピューティングデバイス102は、修復FECペイロードIDをFEC RTPストリームのヘッダエクステンションに加えることなどによって、修復FECペイロードIDを含むように、FEC RTPストリーム(またはFEC RTPストリームデータ)を調整してよい。たとえば、送信側コンピューティングデバイス102は、(たとえば、帯域外信号を介して受信されたSDPデータを介して)セッション初期化の間に送信側コンピューティングデバイス102に与えられる修復FECペイロードIDを含むように、FEC RTPストリームを調整してよい。
【００３５】
いくつかの実施形態では、修復FECペイロードIDは、RFC6681のセクション6.2.3において定義されてよく、FEC RTPストリーム内の関連する修復ペイロードと一緒に送られてよい。いくつかの実施形態では、修復FECペイロードIDはまた、RTPヘッダエクステンションとして送られてもよいが、修復FECペイロードIDは、FEC RTPストリームのRTPペイロード内に含まれてもよい。ソースFECペイロードIDの場合と同様に、1バイトのヘッダエクステンションまたは2バイトのヘッダエクステンションが、いくつかの実施形態において修復FECペイロードIDのために使用される場合がある。
【００３６】
ブロック314において、送信側コンピューティングデバイス102は、ソースRTPストリームおよびFEC RTPストリームデータを、ワイドエリアネットワーク(WAN)などを介して受信側コンピューティングデバイスに送信してよい。送信側コンピューティングデバイス102は、新しいソースRTPストリームデータ(たとえば、ソースブロック)を生成するためにブロック302における動作を継続してよい。
【００３７】
方法330に戻ると、受信側コンピューティングデバイス120は、ブロック332において送信側コンピューティングデバイス102からソースRTPストリームおよびFEC RTPストリームのデータを受信し得る。決定ブロック334において、受信側コンピューティングデバイス120は、ソースRTPストリームのいずれかに対して消失したデータ(たとえば、消失したソースブロック)が存在するかどうかを決定し得る。消失したデータが存在すると決定した(すなわち、決定ブロック334=「Yes」)ことに応答して、受信側コンピューティングデバイス120は、ブロック336において調整されたヘッダエクステンションを使用してFEC RTPストリームから(たとえば、FECブロックまたは修復ブロックから)消失したデータ(または消失したソースブロックデータ)を取り出すことができる。消失したデータがないと決定した(すなわち、決定ブロック334=「No」)ことに応答して、またはブロック336の動作を実行したことに応答して、受信側コンピューティングデバイス120は、IPテレフォニー呼または他のストリーミングメディア(たとえば、ストリーミングムービー、など)の一部としてオーディオおよび/またはビデオをレンダリングすることなどによって、ブロック338においてソースFECストリームを使用してよい。受信側コンピューティングデバイス120は、ブロック332において後続のRTPストリームを受信することを継続してよい。
【００３８】
いくつかの実施形態では、ソースFECペイロードIDおよび/または修復FECペイロードIDは、リアルタイムトランスポートプロトコル(RTP)パラメータレジストリのRTPコンパクトヘッダエクステンションサブレジストリ内で定義される新しいRTPヘッダエクステンションユニフォームリソース識別子(URI)を利用してよい。たとえば、ソースFECペイロードIDは、「urn:ietf:params:rtp-hdrext:FEC-FR:SourceID」などのエクステンションURIを利用してよく、修復FECペイロードIDは、「urn:ietf:params:rtp-hdrext:FEC-FR:RepairID」などのエクステンションURIを利用してよい。
【００３９】
図3Bは、様々な実施形態において使用するのに適したヘッダエクステンションを有するソースRTPストリーム(たとえば、オーディオストリームおよびビデオストリーム)に対応するバンドルされたFEC RTPストリームの使用を示すSDPデータ350の一例である。SDPデータは、受信側コンピューティングデバイス120と送信側コンピューティングデバイス102との間の通信に使用されるRTPストリームの特性を示す様々な行を含んでよい。そのようなSDPデータの行(またはインライン)の順序は、最終的な送信におけるソースストリーム/パケットの外観を定義し得る。いくつかの実施形態では、そのようなSDPデータは、帯域外シグナリングを介してセッション初期化段階の間に受信側コンピューティングデバイス120によって受信され得る。いくつかの実施形態では、SDP行は、RFC5285のセクション5内で与えられるガイダンスに基づいてフォーマットされてよく、さらに、RFC6681のセクション10から導出され得るFEC保護に関する情報を含んでよい。
【００４０】
以下は、SDPデータの一例である。概して、「a=group:」行は、SDPデータ内に含まれてよく、グループのすべてのMIDに対処してよく、MIDは、オーディオストリームまたはビデオストリームなど、送られるべきストリームを記述するSDPデータのm行に関連する識別子であってよい。SDPデータの他の行は、関連するm行に対する「extmap:」パラメータを与えてよく、「extmap:」パラメータは、関連する各ストリームに対して使用されているRTPエクステンションヘッダのタイプに固有であってよい。具体的には、SDPデータは、グループのRTPストリームの順序(たとえば、S1、S2、R1)を示す行351(たとえば、「a=group:」属性行)を含んでよい。行352、362、372は、第1の行351によって識別されるm行と見なされてよい。SDPデータは、第1のソースRTPストリーム(たとえば、ビデオストリーム)が送信されるべきであることを示す第1の行352を含み得る。第2の行354は、第1のソースRTPストリームがFECを目的としてヘッダエクステンションを利用し得る(たとえば、ソースペイロードIDを含み得る)ことを示す「extmap:」パラメータを含み得る。SDPデータは、第2のソースRTPストリーム(たとえば、オーディオストリーム)が送信されるべきであることを示す第3の行362を含み得る。第3の行364は、第2のソースRTPストリームがFECを目的としてヘッダエクステンションを利用し得る(たとえば、ソースペイロードIDを含み得る)ことを示す「extmap:」パラメータを含み得る。SDPデータは、FEC RTPストリームが送信されるべきであることを示し得る第5の行372を含み得る。第6の行374は、FEC RTPストリームがヘッダエクステンションを利用し得る(たとえば、修復ペイロードIDを含み得る)ことを示す「extmap:」パラメータを含み得る。
【００４１】
図4Aは、バンドルされたFEC RTPストリームを有する修正されていないソースRTPストリームを交換するためのコンピューティングデバイスに対する実施形態の方法400および430(すなわち、「暗示的ソース識別」技法)を示す。言い換えれば、図4Aは、ソースFECペイロードIDなしにマルチシーケンス化フローを使用するための技法を示す。方法400、430は、方法400、430がソースRTPストリームを修正するための動作を含まないことを除いて、図3Aを参照しながら説明した方法と同様であり得る。代わりに、方法400、430では、送信側コンピューティングデバイス102および受信側コンピューティングデバイス120は、単に、ソースストリーム内の喪失データの復元をサポートするためにFEC RTPストリーム内で送信された情報に対する調整を行うことができる。具体的には、FEC RTPストリームの修復FECペイロードIDは、ソースRTPストリームを編集することなく使用され得る。このようにして、修復ペイロードIDは、FEC RTPストリームを介して保護されるソースRTPストリームの数に伴ってサイズが増加する場合がある。この技法は、FEC RTPストリームの生成に関してよりコストがかかる場合がある。なぜならば、送信側コンピューティングデバイス102は、各シーケンス番号と、各ソースRTPストリームから取られたバイトの数と、FEC RTPストリーム内で使用するための修復ペイロードID内のソースRTPストリームを示す情報とを識別することを必要とする場合があるからである。
【００４２】
方法400の動作は送信側コンピューティングデバイス102のプロセッサによって実行されてよく、方法430の動作は受信側コンピューティングデバイス120のプロセッサによって実行されてよい。様々なシナリオでは、任意のコンピューティングデバイスは、方法400、430に従って送ることまたは受信することのいずれかを行うように構成されてよい。RFC6681のセクション8は単一のシーケンス化フローに対する手順を記述するが、様々な実施形態は、この単一のシーケンス化フロー方法をマルチシーケンス化フロー、特に異なる同期ソース(すなわち、SSRC)に対応する複数のRTPフローに対して拡張する。様々な実施形態では、暗示的ソース識別技法が、FEC方式ID5および6など、様々なFECコードに対して使用される場合がある。様々な実施形態では、方法400、430は、RFC6681内で記述されるシンタックス/フォーマッティングを利用する修復ペイロードIDを含むFEC RTPストリームと、RFC6681内で記述されるシンタックス/フォーマッティングを同様に利用するソースペイロードIDを含むソースRTPストリームとを利用する場合がある。
【００４３】
方法400のブロック301、302、314の動作および方法430のブロック331、332、334、338の動作は、図3Aを参照しながら説明した同様に番号付けられたブロックの動作と同様であり得る。ブロック402において、送信側コンピューティングデバイス102のプロセッサは、複数のソースRTPストリームに対するFEC RTPストリーム(またはFEC RTPストリームデータ)を確立/生成し得る。ブロック402の動作は、ブロック402の動作がヘッダエクステンションを含むように修正されてはいないソースRTPストリームに基づいてFEC RTPストリームを確立/生成し得ることを除いて、図3Aのブロック310の動作と同様であり得る。
【００４４】
ブロック404において、送信側コンピューティングデバイス102は、ソースRTPストリームの各々に対する少なくともフロー識別子、長さインジケータ、およびs値(すなわち、RFC6681、セクション5内で定義される最小整数値)を含むFEC RTPストリームに対する修復ブロックを構築し得る。いくつかの実施形態では、修復FECペイロードに対する1つのフォーマットだけが、マルチシーケンス化フローのために必要なエクステンションを与えられてよい。いくつかの実施形態では、修復パケット内のフローの数およびフローが修復パケット内に現れる順序は、帯域外シグナリングを使用して(たとえば、図4Cにおいて以下で示されるSDPデータを介して)決定されてよい。
【００４５】
いくつかの実施形態では、ソースシンボル構成は、ブロック404の動作中に送信側コンピューティングデバイス102によって実行されてよい。具体的には、送信側コンピューティングデバイス102は、FECコードが適用され得るソースシンボルのセットを構築するためにRFC6681のセクション5内で定義されるFEC方式5およびFEC方式6の手順を利用してよい。たとえばソースブロックの構築中に、送信側コンピューティングデバイス102は、ソースパケット情報内に含まれる各ソースRTPストリーム(またはフロー)に対するフロー識別子(すなわち、f[i])と、各パケットに対するソースパケット情報内に含まれ、トランスポートペイロード内で搬送されるプロトコルに依存する長さ表示(すなわち、l[i])と、s[i]*T>=(l[i]+3)のような最小整数として識別され得る各パケットに対するソースパケット情報の構築におけるsの値(すなわち、s[i])とを決定してよく、Tはオクテットにおけるソースシンボルサイズであってよく、iはソースRTPストリームインデックスであってよい。
【００４６】
いくつかの実施形態では、ソースFECパケット識別情報の導出は、送信側コンピューティングデバイスによって利用されてよい。たとえば、ソースパケットに対するソースFECパケット識別情報は、各パケット内のフロー、パケットの各個々のフローのシーケンス番号、およびこのソースブロックに属する任意の修復FECパケット内で受信された情報から導出され得る。ソースブロックを構成するアプリケーションデータユニット(ADU)は、関連するフロー識別子およびブロック内の第1のソースパケットのシーケンス番号によって識別され得る。この情報は、初期シーケンス番号フィールド内のソースブロックに関連するすべての修復FECパケット内にシグナリングされ得る。
【００４７】
いくつかの実施形態では、ソースブロック内のソースパケットに対する(オクテットにおける)ソースパケット情報の長さは、そのブロックに対する修復パケットの符号化シンボル(すなわち、修復FECペイロードIDを含まない)を含むペイロードの長さに等しくてよく、その長さは、すべての修復パケットに対して同じであってよい。シンボル内のアプリケーションデータユニット情報長さ(ADUIL)は、この長さを(FECフレームワーク構成情報内でシグナリングされ得る)符号化シンボルサイズで割ったものに等しくてよい。ソースブロック内に含まれるソースパケットのセットは、次のように、初期シーケンス番号(ISN)およびソースサブブロック長さ(SSBL)によって決定され得る。fがフローのインデックスであるとすると(すなわち、fがソースブロック内の第1のフローを指す場合、f=1)、I(f)はフローfからのソースサブブロックの初期シーケンス番号であり、LP(f)はフローfに対するシンボル内のソースサブブロック情報長さであり、LB(f)はフローfに対するシンボル内のソースサブブロック長さである。次いで、フローfに対してI(f)からI(f)+(LB(f)/LP(f))-1までの両端値を含むシーケンス番号を有するソースパケットが、ソースブロック内に含まれ得る。ソースサブブロック長さ(SSBL)、LB(f)は、最大ソースパケット情報長さLP(f)と少なくとも同程度の大きさであるように選択されてよい。
【００４８】
いくつかの実施形態では、FEC方式1の場合、修復パケット内に入れられる符号化シンボルID(ESI)値は、RFC5053のセクション5.3.2内で指定されるように計算されてよい。いくつかの実施形態では、FEC方式2の場合、修復パケット内に入れられるESI値は、RFC6330のセクション4.4.2内で指定されるように計算されてよい。しかしながら、FEC方式1またはFEC方式2のいずれかにおいて、K(すなわち、RFC6330、セクション4.4.1内で定義されるように、ソースブロックが分割され得る、一定サイズTオクテットのソースシンボルの数)は、修復パケット内に示されるすべてのSSBLの合計と同等であってよい。
【００４９】
いくつかの実施形態では、RTPソースパケットフローの場合、RTPシーケンス番号フィールドは、上述の手順におけるシーケンス番号として使用されてよい。アプリケーションデータユニット情報内に含まれる長さ表示は、RTPペイロード長さに、もしあれば寄与するソース(CSRC)の長さと、もし存在すればRTPヘッダエクステンションと、もしあればRTPパディングオクテットとをプラスしたもののすべてのフローにわたる合計であり得る。この長さは、一般的に、パケットマイナス12のユーザデータグラムプロトコル(UDP)ペイロード長さに等しくあり得る。
【００５０】
ブロック406において、送信側コンピューティングデバイス102は、FEC RTPストリームのペイロードフォーマットをバンドルされたメディアタイプとして登録してよく、ブロック314においてソースRTPストリームおよびFEC RTPストリームデータを受信側コンピューティングデバイス120に送信してよい。いくつかの実施形態では、RTPペイロードフォーマットは、RFC4855に従って登録されてよく、RFC4288のテンプレートを使用する、「バンドルされた/raptorfec」メディアタイプを使用して登録され得る。そのようなメディアタイプ規定は、RFC6682のセクション6.2.1内で発見され得る「ビデオ/raptorfec」と同等であり得る。
【００５１】
方法430のブロック332において、受信側コンピューティングデバイス120は、ソースRTPストリームとFEC RTPストリームデータとを受信し得る。図3Aで論じたソースRTPストリームとは違って、図4AのソースRTPストリームは、ソースFECペイロードIDを含まない(すなわち、ソースRTPストリームのソースパケットは修正されていない)。セッション初期化の間(たとえば、ブロック331の動作の間)に受信されるような帯域外シグナリングによって、受信側コンピューティングデバイス120は、様々なソースRTPストリームに対応する第1のシーケンス番号またはソースブロック長さをすでに知っている場合がある。受信側コンピューティングデバイス120は、FEC RTPストリーム内に各ソースRTPストリームから与えられたパケット(またはブロック)が存在することになることを期待してよい(すなわち、FEC RTPストリームの各修復パケットは、各ストリームからの等しい数のソースバイトを含むことを期待され得る)。FEC修復パケットが受信されない場合、FEC復号は可能ではなくなり、受信側コンピューティングデバイス120がソースRTPストリームパケットに対するソースFECパケット識別情報を識別する必要はなくなる。
【００５２】
決定ブロック334において、受信側コンピューティングデバイス120は、同様に番号付けられたブロックに対して図3Aを参照しながら上記で説明したソースRTPストリームのうちの1つの中に消失したデータが存在するかどうかを決定し得る。ソースRTPストリームのうちの1つの中に消失したデータが存在すると決定した(すなわち、決定ブロック334=「Yes」)ことに応答して、受信側コンピューティングデバイス120は、ブロック436においてバンドルされたメディアFECペイロードを使用してFEC RTPストリームから消失したデータ(または消失したソースブロックデータ)を取り出すことができる。ソースRTPストリームからの消失したデータは存在しないと決定した(すなわち、決定ブロック334=「No」)ことに応答して、またはブロック436の動作を実行したことに応答して、受信側コンピューティングデバイス120は、ブロック338においてソースRTPストリームを使用してよく、ブロック332においてパケットを受信することを継続してよい。
【００５３】
図4Bは、様々な実施形態において使用するのに適したFECペイロードフォーマット440の一例である。図4Bに示すFECペイロードフォーマット440は、FECペイロードフォーマット440がマルチシーケンス化フローのために必要なエクステンションを含むことを除いて、RFC6681のセクション8.1.3内で定義されるフォーマット「A」と同様であり得る。マルチシーケンス修復FECペイロードIDフォーマット440に関して、「初期シーケンス番号」(ISN)フィールド(たとえば、フローi ISN)は16ビットであってよく、このサブブロック内に含まれるべき第1のパケットのシーケンス番号の最下位の16ビットを指定する1フィールドであってよい。シーケンス番号が16ビットより短い場合、受信されたシーケンス番号は、それぞれ、論理的にゼロビットでパディングされて16ビットの長さになり得る。ISNフィールドタイプは、符号なし整数であり得る。ソースサブブロック長さ(SSBL)フィールドは16ビットであってよく、シンボル内のソースサブブロックの長さを指定してよい。SSBLフィールドタイプは、符号なし整数であり得る。符号化シンボルID(ESI)フィールドは16ビットであってよく、どの修復シンボルがこの修復パケット内に含まれるかを示してよい。与えられたESIは、パケット内の第1の修復シンボルのESIであり得る。ESIフィールドタイプは、符号なし整数であり得る。
【００５４】
図4Cは、いくつかの実施形態において使用するのに適したソースRTPストリームに対応するバンドルされたFEC RTPストリームを示すSDPデータ450の一例を示す。そのようなSDPデータ450は、修復パケット内のフローの数と、フローが修復パケット内に現れる順序とを送信側コンピューティングデバイス/受信側コンピューティングデバイスに与えてよく、帯域外シグナリングを使用してこれらのデバイスに配信されてよい。SDPデータ450は、SDPデータ450がソースRTPストリームに対するヘッダエクステンションを含まないことを除いて、上記の図3Bに示すSDPと同様であり得る。上記で説明したように、SDPデータ450の行(またはインライン)の順序は、最終的な送信におけるソースストリーム/パケットの外観を定義し得る。いくつかの実施形態では、バンドルされたFEC保護を示すSDPデータは、RFC6681のセクション10から導出され得る。
【００５５】
一例として、SDPデータは、RTPストリームの外観の順序(すなわち、S1、S2、R1)を示す行451(たとえば、「a=group:」属性行)を含み得る。SDPデータ450は、第1のソースRTPストリーム(たとえば、ビデオストリーム)が送信されるべきであることを示す第1の行452(たとえば、m行)を含み得る。第2の行462(たとえば、m行)は、第2のソースRTPストリーム(たとえば、オーディオストリーム)が送信されるべきであることを示し得る。第3の行472(たとえば、m行)は、FEC RTPストリームが送信されるべきであることを示し得る。第4の行474は、FEC RTPストリームに対するバンドルされた構成情報を示し得る。
【００５６】
いくつかの実施形態では、送信側コンピューティングデバイスおよび受信側コンピューティングデバイスは、明示的ソース識別技法、暗示的ソース識別技法、および/またはソースRTPストリームのFEC保護を与えるための他の技法を利用するように構成されてよい。図5A〜図5Bは、様々な技法をダイナミックに利用するための送信側コンピューティングデバイスおよび受信側コンピューティングデバイスに対する実施形態の方法を示す。
【００５７】
図5Aは、様々な構成におけるバンドルされたFEC RTPストリームを有するソースRTPストリームを送信するための送信側コンピューティングデバイスのための実施形態の方法500を示す。言い換えれば、送信側コンピューティングデバイスは、バンドルされたFEC保護をいかにして可能にするかを決定するために送出するソースRTPストリームに関連するデータを継続的に評価してよい。方法500のブロック301〜302の動作は、図3Aを参照して上で説明した同様の番号のブロックの動作と同様であり得る。
【００５８】
決定ブロック504において、送信側コンピューティングデバイスは、明示的ソース識別のバンドルされたFEC保護(すなわち、修正されたソースRTPストリームを使用するRTPヘッダエクステンション技法)を使用するかどうかを決定し得る。そのような決定は、ブロック301の動作中に図3Bに示すように受信されたSDPデータに基づくことができる。RTPヘッダエクステンションが使用されるべきと決定した(すなわち、決定ブロック504=「Yes」)ことに応答して、送信側コンピューティングデバイスは、図3Aを参照しながら上記で説明したブロック304〜314の送出動作を実行してよい。
【００５９】
RTPヘッダエクステンションが使用されるべきでないと決定した(すなわち、決定ブロック504=「No」)ことに応答して、送信側コンピューティングデバイスは、決定ブロック506においてバンドルされたFEC保護を与えるために暗示的ソース識別技法(すなわち、ソースストリームに対する修正なし/ソースRTPヘッダエクステンションなし)を使用するかどうかを決定し得る。暗示的ソース識別技法が使用されるべきと決定した(すなわち、決定ブロック506=「Yes」)ことに応答して、送信側コンピューティングデバイスは、図4Aを参照しながら上記で説明したブロック314、402〜406の送出動作を実行してよい。
【００６０】
暗示的ソース識別技法が使用されるべきでないと決定した(すなわち、決定ブロック506=「No」)ことに応答して、複数のRTPソースフローにわたるバンドルされたFEC保護は不可能であり、送信側コンピューティングデバイスは、RFC6681に記述されるのと同様であるが異なるソースストリームを区別するためにCSRCを使用する技法を利用することを必要とされる。たとえば、送信側コンピューティングデバイスは、ゲートウェイの混合(たとえば、多者音声/ビデオ会議ブリッジ)において通常使用され得るようなソースに分離するためにCSRCを使用することができる。言い換えれば、送信側コンピューティングデバイスは、複数のソースに対する混合器として動作し得る。送信側コンピューティングデバイスは、ブロック508においてソースRTPストリームを一緒に混合し、ブロック510においてCSRCを使用して混合されたソースRTPストリームに対するFEC RTPストリームを生成し、ブロック512において混合されたソースRTPストリームおよびFEC RTPストリームを受信側コンピューティングデバイスに送信してよい。
【００６１】
図5Bは、様々な構成におけるバンドルされたFEC RTPストリームを有するソースRTPストリームを受信して処理するための受信側コンピューティングデバイスのための実施形態の方法550を示す。方法550のブロック331の動作は、図3Aを参照しながら説明した同様の番号のブロックの動作と同様であり得る。
【００６２】
決定ブロック504において、受信側コンピューティングデバイスは、明示的ソース識別のバンドルされたFEC保護(すなわち、ソースストリームを修正したRTPヘッダエクステンション技法)を使用するかどうかを決定し得る。そのような決定は、ブロック331の動作中に図3Bに示すように受信されたSDPデータに基づくことができる。RTPヘッダエクステンションが使用されるべきと決定した(すなわち、決定ブロック504=「Yes」)ことに応答して、受信側コンピューティングデバイスは、図3Aを参照しながら上記で説明したブロック332〜338の受信動作および処理動作を実行してよい。
【００６３】
RTPヘッダエクステンションが使用されるべきでないと決定した(すなわち、決定ブロック504=「No」)ことに応答して、受信側コンピューティングデバイスは、決定ブロック506においてバンドルされたFEC保護を与えるために暗示的ソース識別技法(すなわち、ソースストリームに対する修正なし、ソースRTPヘッダエクステンションなし)を使用するかどうかを決定し得る。暗示的ソース識別技法が使用されるべきと決定した(すなわち、決定ブロック506=「Yes」)ことに応答して、受信側コンピューティングデバイスは、図4Aを参照しながら上記で説明したブロック332、334、338、436の受信動作および処理動作を実行してよい。
【００６４】
暗示的ソース識別技法が使用されるべきでないと決定した(すなわち、決定ブロック506=「No」)ことに応答して、受信側コンピューティングデバイスは、混合されたソースRTPストリームを利用することに頼ってよい。ブロック552〜558の動作は、ブロック552〜558の動作が単一の混合されたソースRTPストリームおよびFEC RTPストリームを顧慮し得ることを除いて、図4Aのブロック332〜338またはブロック332、334、436、338の動作と同様であり得る。たとえば、ブロック558における動作によってソースRTPストリームを使用するために、受信側コンピューティングデバイスは、レンダリングなどの前に、様々な一緒に混合されたストリームを区別するために分離動作を実行することを必要とされる場合がある。そのような分離動作は、CSRCを利用してよい。一例として、マルチパーティ呼におけるエンドポイント(たとえば、送信側コンピューティングデバイス)は、異なるオーディオコーデック機能を有する呼において他のパーティをサポートするために異なるエンコーダレートにおいて複数のオーディオストリーム送ることができる。これらのストリームは、単一のRTPセッション(すなわち、「オーディオマルチキャスティング」)上で送られてよく、各オーディオストリームはCSRCによって識別されてよい。この受信側コンピューティングデバイスは、単一のRTPセッションを受信し、含まれるCSRCデータに基づいて個別のオーディオストリームを識別し得る。
【００６５】
上述の様々な実施形態のさらなる詳細は、「FEC FRAME Raptor Extensions for Multiple RTP Synchronization Sources」と題する文献内で発見され得、この文献は、本明細書に添付され、本明細書内に存在するかのように、その全体が本明細書に組み込まれている。
【００６６】
パーソナルコンピュータおよびラップトップコンピュータを含む、様々な形のコンピューティングデバイスは、様々な実施形態を実装するために使用され得る。一般的に、そのようなコンピューティングデバイスは、図6に示すモバイルデバイス120の構成要素を含む。様々な実施形態では、モバイルデバイス120は、タッチスクリーンコントローラ604および内部メモリ602に結合されたプロセッサ601を含み得る。プロセッサ601は、汎用または特定の処理タスクに指定された1つまたは複数のマルチコアICであり得る。内部メモリ602は揮発性または不揮発性メモリであってもよく、また、セキュアおよび/もしくは暗号化メモリ、または非セキュアおよび/もしくは非暗号化メモリ、あるいはそれらの任意の組合せであってもよい。タッチスクリーンコントローラ604およびプロセッサ601は、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなどのタッチスクリーンパネル612に結合される場合もある。モバイルデバイス120は、互いに結合され、かつ/またはプロセッサ601に結合された、送受信のための、1つまたは複数の無線信号トランシーバ608(たとえば、Bluetooth(登録商標)、ZigBee(登録商標)、Wi-Fi(登録商標)、RF無線)、およびアンテナ610を有し得る。トランシーバ608およびアンテナ610は、様々なワイヤレス送信プロトコルスタックおよびインターフェースを実施するために、前述の回路とともに使用され得る。モバイルデバイス120は、セルラーネットワークを介する通信を可能にし、プロセッサに結合され得る、セルラーネットワークワイヤレスモデムチップ616を含み得る。モバイルデバイス120は、プロセッサ601に結合された周辺デバイス接続インターフェース618を含み得る。周辺デバイス接続インターフェース618は、1つのタイプの接続を受け入れるように単独で構成される場合があり、またはUSB、FireWire、ThunderboltもしくはPCIeなどの様々なタイプの物理接続および通信接続を一般的な接続もしくは専用の接続として受け入れるように複合的に構成される場合がある。周辺デバイス接続インターフェース618はまた、同様に構成された周辺デバイス接続ポート(図示せず)に結合され得る。また、モバイルデバイス120は、音声出力を提供するためのスピーカー614を含むことも可能である。また、モバイルデバイス120は、プラスチック、金属もしくは材料の組合せで構築された、本明細書で説明した構成要素のすべて、またはいくつかを収容するためのハウジング620を含むことも可能である。モバイルデバイス120は、使い捨てまたは充電可能なバッテリーなどの、プロセッサ601に結合された電源622を含む場合もある。充電可能なバッテリーは、モバイルデバイス120の外部にある電源から充電電流を受けるために、周辺デバイス接続ポートに結合される場合もある。
【００６７】
パーソナルコンピュータ、モバイルコンピューティングデバイス(たとえば、スマートフォンなど)、サーバ、ラップトップコンピュータなどを含む、様々な形のコンピューティングデバイスが、様々な実施形態を実装するために使用され得る。そのようなコンピューティングデバイスは、通常、少なくとも、例示的なサーバコンピューティングデバイスを示す図7に示された構成要素を含み得る。そのようなサーバコンピューティングデバイス102は、通常、揮発性メモリ702と、ディスクドライブ703などの大容量不揮発性メモリとに結合されたプロセッサ701を含み得る。サーバコンピューティングデバイス102はまた、プロセッサ701に結合されたフロッピーディスクドライブ、コンパクトディスク(CD)、またはデジタル多用途ディスク(DVD)ディスクドライブ706を含み得る。また、サーバコンピューティングデバイス102は、他のシステムコンピュータおよびサーバに結合されたインターネットおよび/またはローカルエリアネットワークなどのネットワーク705とのデータ接続を確立するための、プロセッサ701に結合されたネットワークアクセスポート704(またはインターフェース)を含み得る。
【００６８】
本明細書で説明する様々なプロセッサは、本明細書で説明する様々な実施形態の機能を含む、様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成され得る、任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、または1つもしくは複数の多重プロセッサチップであり得る。様々なデバイスでは、ワイヤレス通信機能専用の1つのプロセッサおよび他のアプリケーションを実行する専用の1つのプロセッサなどの、複数のプロセッサが設けられてもよい。典型的には、ソフトウェアアプリケーションは、それらがアクセスされ、プロセッサ内にロードされる前に、内部メモリ内に記憶されてもよい。プロセッサは、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含んでもよい。多くのデバイスにおいて、内部メモリは、揮発性メモリ、もしくはフラッシュメモリなどの不揮発性メモリ、または両方の混合物であってもよい。この説明のために、メモリへの一般的な参照は、内部メモリ、または様々なデバイス内に差し込まれるリムーバブルメモリおよびプロセッサ内のメモリを含む、プロセッサによってアクセス可能なメモリを指す。
【００６９】
前述の方法の説明およびプロセスフロー図は、例示的な例として与えられるものにすぎず、様々な実施形態のステップが提示された順序で実行されなければならないことを要求または暗示するものではない。当業者によって諒解されるように、前述の実施形態におけるステップの順序は、任意の順序で実行され得る。「その後」、「次いで」、「次に」などの語は、ステップの順序を限定するものではなく、これらの語は単に、方法の説明を通じて読者を導くために使用される。さらに、たとえば、冠詞「a」、「an」または「the」を使用する、単数形での請求項の要素へのいかなる言及も、要素を単数形に限定するものとして解釈されるべきではない。
【００７０】
本明細書で開示した実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップは、その機能に関して一般的に上で説明された。そのような機能がハードウェアとして実現されるのか、それともソフトウェアとして実現されるのかは、特定の適用例および全体的なシステムに課された設計制約によって決まる。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装してもよいが、そのような実装決定は、特許請求の範囲からの逸脱を引き起こすものとして解釈されるべきではない。
【００７１】
本明細書で開示する実施形態に関して説明した様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明した機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行されてよい。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装されてよい。代替的に、いくつかのステップまたは方法は、所与の機能に専用の回路構成によって実行されてよい。
【００７２】
1つまたは複数の実施形態では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装されてもよい。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、非一時的プロセッサ可読、コンピュータ可読、もしくはサーバ可読媒体、または非一時的プロセッサ可読記憶媒体上に記憶され、またはそれを介して送信され得る。本明細書で開示される方法またはアルゴリズムのステップは、非一時的コンピュータ可読記憶媒体、非一時的サーバ可読記憶媒体、および/または非一時的プロセッサ可読記憶媒体上に存在し得る、プロセッサ実行可能ソフトウェアモジュールまたはプロセッサ実行可能ソフトウェア命令において具現化され得る。様々な実施形態では、そのような命令は、記憶されたプロセッサ実行可能命令または記憶されたプロセッサ実行可能ソフトウェア命令であり得る。有形の非一時的コンピュータ可読記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのような非一時的コンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または、命令もしくはデータ構造の形式で所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る任意の他の媒体を備え得る。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、DVD、フロッピーディスク(disk)、およびblu-ray(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、非一時的コンピュータ可読媒体の範囲内に含まれるべきである。加えて、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る、有形の非一時的プロセッサ可読記憶媒体および/またはコンピュータ可読媒体上のコードおよび/または命令の、1つまたは任意の組合せまたはセットとして存在し得る。
【００７３】
開示した実施形態の前述の説明は、任意の当業者が特許請求の範囲を製作または使用することを可能にするために提供される。これらの実施形態への様々な修正は当業者には容易に明らかになり、本明細書で定義する一般原理は、特許請求の範囲から逸脱することなく他の実施形態に適用されてよい。したがって、本開示は、本明細書に示す実施形態に限定されるものではなく、以下の特許請求の範囲ならびに本明細書で開示した原理および新規の特徴に一致する最大の範囲を与えられるものである。
【符号の説明】
【００７４】
100  従来のシナリオ
102  受信側コンピューティングデバイス
104  ソースリアルタイムプロトコル(RTP)ストリーム
105  前方誤り訂正(FEC)RTPストリーム
106  ソースRTPストリーム
107  FEC RTPストリーム
110  ネットワーク
120  受信側コンピューティングデバイス
150  従来のシナリオ
152  混合ソースRTPストリーム
155  シングルFEC RTPストリーム
200  シナリオ
202  バンドルされたFEC RTPストリーム
300  方法
330  方法
350  セッション記述プロトコル(SDP)データ
351  行
352  行
354  行
362  行
364  行
372  行
374  行
400  方法
430  方法
440  FECペイロードフォーマット
450  SDPデータ
451  行
452  行
462  行
472  行
474  行
500  方法
550  方法
601  プロセッサ
602  内部メモリ
604  タッチスクリーンコントローラ
608  無線信号トランシーバ
610  アンテナ
612  タッチスクリーンパネル
614  スピーカー
616  セルラーネットワークワイヤレスモデムチップ
618  周辺デバイス接続インターフェース
620  ハウジング
622  電源
701  プロセッサ
702  揮発性メモリ
703  ディスクドライブ
704  ネットワークアクセスポート
705  ネットワーク
706  デジタル多用途ディスク(DVD)ディスクドライブ
【図１Ａ】
2018518869.tif 000003
【図１Ｂ】
2018518869.tif 000004
【図２】
2018518869.tif 000005
【図３Ａ】
2018518869.tif 000006
【図３Ｂ】
2018518869.tif 000007
【図４Ａ】
2018518869.tif 000008
【図４Ｂ】
2018518869.tif 000009
【図４Ｃ】
2018518869.tif 000010
【図５Ａ】
2018518869.tif 000011
【図５Ｂ】
2018518869.tif 000012
【図６】
2018518869.tif 000013
【図７】
2018518869.tif 000014
【手続補正書】
【提出日】平成29年11月2日(2017.11.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
単一の前方誤り訂正(FEC)リアルタイムプロトコル(RTP)ストリームを使用して複数のRTPストリームを保護するためにFECを拡張するための方法であって、
送信側コンピューティングデバイスの1つまたは複数のプロセッサを介して受信側コンピューティングデバイスとセッション初期化データを交換するステップと、
前記1つまたは複数のプロセッサを介して、様々なデータタイプの前記複数のソースRTPストリームに対するソースRTPストリームデータを生成するステップと、
前記1つまたは複数のプロセッサを介して、前記複数のソースRTPストリームに対応するFEC RTPストリームに対するFEC RTPストリームデータを生成するステップと、
前記複数のソースRTPストリームおよび前記FEC RTPストリームを前記受信側コンピューティングデバイスに送信するステップとを含む、方法。
【請求項２】
前記1つまたは複数のプロセッサを介して、ソースFECペイロード識別子(ID)を含むように前記複数のソースRTPストリームの各々のヘッダエクステンションを調整するステップをさらに含む、請求項1に記載の方法。
【請求項３】
前記1つまたは複数のプロセッサを介して、修復FECペイロード識別子(ID)を含むように前記FEC RTPストリームを調整するステップをさらに含む、請求項2に記載の方法。
【請求項４】
前記1つまたは複数のプロセッサを介して、前記複数のソースRTPストリームに対する前記FEC RTPストリームの修復ブロックを構築するステップであって、前記修復ブロックは前記ソースRTPストリームの各々に対する少なくともフロー識別子と長さインジケータとを含む、構築するステップと、
前記1つまたは複数のプロセッサを介して、前記FEC RTPストリームのペイロードフォーマットをバンドルされたメディアタイプとして登録するステップとをさらに含む、請求項1に記載の方法。
【請求項５】
前記複数のソースRTPストリームの各々が、オーディオストリームおよびビデオストリームのうちの1つである、請求項1に記載の方法。
【請求項６】
前記セッション初期化データが、セッション記述プロトコル(SDP)データを含む、請求項1に記載の方法。
【請求項７】
単一の前方誤り訂正(FEC)リアルタイムプロトコル(RTP)ストリームを使用して複数のRTPストリームを保護するためにFECを拡張するための方法であって、
受信側コンピューティングデバイスの1つまたは複数のプロセッサを介して送信側コンピューティングデバイスから様々なデータタイプの複数のソースRTPストリームおよびFEC RTPストリームを受信するステップと、
前記1つまたは複数のプロセッサを介して、ソースブロックデータが前記複数のソースRTPストリームのいずれかから消失しているかどうかを決定するステップと、
前記1つまたは複数のプロセッサを介して、消失したソースブロックデータが存在するとの決定に応答して、消失したソースブロックデータを前記FEC RTPストリームの修復ブロックから取り出すステップと、
前記1つまたは複数のプロセッサを介して、前記複数のソースRTPストリームの前記データを使用するステップとを含む、方法。
【請求項８】
前記複数のソースRTPストリームの各々が、オーディオストリームおよびビデオストリームのうちの1つである、請求項7に記載の方法。
【請求項９】
トランシーバと、
前記トランシーバに結合されたプロセッサとを備え、前記プロセッサが、
受信側コンピューティングデバイスとセッション初期化データを交換するステップと、
様々なデータタイプの複数のソースリアルタイムプロトコル(RTP)ストリームに対するソースRTPストリームデータを生成するステップと、
前記複数のソースRTPストリームに対応するFEC RTPストリームに対する前方誤り訂正(FEC)RTPストリームデータを生成するステップと、
前記複数のソースRTPストリームおよび前記FEC RTPストリームを前記受信側コンピューティングデバイスに送信するステップとを含む動作を実行するためのプロセッサ実行可能命令で構成される、コンピューティングデバイス。
【請求項１０】
前記プロセッサが、
ソースFECペイロード識別子(ID)を含むように前記複数のソースRTPストリームの各々のヘッダエクステンションを調整するステップをさらに含む動作を実行するためのプロセッサ実行可能命令で構成される、請求項9に記載のコンピューティングデバイス。
【請求項１１】
前記プロセッサが、
修復FECペイロード識別子(ID)を含むように前記FEC RTPストリームを調整するステップをさらに含む動作を実行するためのプロセッサ実行可能命令で構成される、請求項10に記載のコンピューティングデバイス。
【請求項１２】
前記プロセッサが、
前記複数のソースRTPストリームに対する前記FEC RTPストリームの修復ブロックを構築するステップであって、前記修復ブロックは前記ソースRTPストリームの各々に対する少なくともフロー識別子と長さインジケータとを含む、構築するステップと、
前記プロセッサを介して、前記FEC RTPストリームのペイロードフォーマットをバンドルされたメディアタイプとして登録するステップとをさらに含む動作を実行するためのプロセッサ実行可能命令で構成される、請求項9に記載のコンピューティングデバイス。
【請求項１３】
前記複数のソースRTPストリームの各々が、オーディオストリームおよびビデオストリームのうちの1つである、請求項9に記載のコンピューティングデバイス。
【請求項１４】
前記セッション初期化データが、セッション記述プロトコル(SDP)データを含む、請求項9に記載のコンピューティングデバイス。
【請求項１５】
トランシーバと、
前記トランシーバに結合されたプロセッサとを備え、前記プロセッサが、
送信側コンピューティングデバイスから様々なデータタイプの複数のソースリアルタイムプロトコル(RTP)ストリームおよび前方誤り訂正(FEC)RTPストリームを受信するステップと、
ソースブロックデータが前記複数のソースRTPストリームのいずれかから消失しているかどうかを決定するステップと、
消失したソースブロックデータが存在するとの決定に応答して、消失したソースブロックデータを前記FEC RTPストリームの修復ブロックから取り出すステップと、
前記複数のソースRTPストリームの前記データを使用するステップとを含む動作を実行するためのプロセッサ実行可能命令で構成される、コンピューティングデバイス。
【請求項１６】
前記複数のソースRTPストリームの各々が、オーディオストリームおよびビデオストリームのうちの1つである、請求項15に記載のコンピューティングデバイス。
【国際調査報告】
2018518869.tif 000015
2018518869.tif 000016
2018518869.tif 000017