JP2015519801A - リアルタイム通信のための冗長性 - Google Patents

Abstract

リアルタイム通信のための冗長性のシステムおよび方法を開示する。１つのこのような方法は、メディアパケットのストリームの第１のメディアパケットと、メディアパケットのストリームの第２のメディアパケットとを結合して、フレームにするステップを含む。第２のメディアパケットは、ストリームにおいて第１のメディアパケットに続くメディアパケットである。第２のメディアパケットとストリームの第３のメディアパケットとは結合されて、別のフレームにされる。第３のメディアパケットは、第２のメディアパケットに続くメディアパケットである。フレームおよび別のフレームは、受信側に送信される。

Description

関連出願の相互参照
本願は、２０１２年４月１８日に出願された米国仮出願番号第６１／６２５，８３８号の利益を主張し、当該米国仮出願番号第６１／６２５，８３８号は引用によって本明細書に援用される。

技術分野
本開示は、インターネット音声およびデータサービスに関する。

背景
多くの企業が、従来の電話会社によって提供される公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）を用いた電話サービスから、インターネットプロトコル（Internet Protocol：ＩＰ）電話サービスプロバイダによって提供されるＩＰを用いた電話サービスに移行してきた。このようなサービスは、ボイスオーバーＩＰ（ＶｏＩＰ）またはＩＰ電話として一般に知られている。

今や、制約のあるＰＳＴＮではなく、パブリックインターネットまたはプライベートＩＰネットワークなどのＩＰネットワークが基幹回線として使用可能であるので、ＩＰ電話は、数例を挙げると、ビデオ会議、通話記録および着信転送などの高度な機能を提供できる能力がある。しかし、ＩＰ電話サービスの主な用途は、依然としてＩＰ電話発信者をＰＳＴＮ発信者に接続することである。

この理由のために、ＩＰ電話サービスプロバイダが利用するシグナリングインフラストラクチャ（例えば、プロキシ、アプリケーションサーバなど）は、多くの異なるタイプのエンドポイントが、ＰＳＴＮゲートウェイによって提供される、それほど機能が豊富でないサービスにアクセスできるように設計される。サービスプロバイダは、しばしば、トラフィックを操作および／または標準化する。このような操作としては、例えば最小公分母コーデックへの変換、特定のＳＩＰヘッダの操作／除去などが挙げられ得る。このような操作は、ＩＰ電話をＰＳＴＮ電話と区別する働きをする高度なＩＰ電話サービスと干渉する可能性がある。

本開示の多くの局面は、以下の図面を参照してよりよく理解され得る。図面中の構成要素は、必ずしも一定の比率に応じているわけではなく、その代わりに本開示の原理を明らかに示すことに重きが置かれている。

本明細書に開示されているいくつかの実施例に係るリアルタイム通信（real time communication：ＲＴＣ）サービスのためのネットワーク環境のシステム図である。 本明細書に開示されているいくつかの実施例に係る時間をずらした冗長メカニズムを用いて伝送されるパケットの例示的なシーケンスを示す図である。 本明細書に開示されているいくつかの実施例に係る時間をずらした冗長メカニズムを用いた構成およびパケット伝送を示すメッセージフロー図である。 本明細書に開示されているいくつかの実施例に係るラウンドロビン冗長メカニズムを用いて伝送されるパケットの例示的なシーケンスを示す図である。 本明細書に開示されているいくつかの実施例に係るラウンドロビン冗長メカニズムを用いた構成およびパケット伝送を示すメッセージフロー図である。 本明細書に開示されているいくつかの実施例に係るストライピング冗長メカニズムを用いて伝送されるパケットの例示的なシーケンスを示す図である。 本明細書に開示されているいくつかの実施例に係るストライピング冗長メカニズムを用いた構成およびパケット伝送を示すメッセージフロー図である。 本明細書に開示されているいくつかの実施例に係る冗長トンネルシステムによって用いられるプロトコルスタックのブロック図である。 本明細書に開示されているいくつかの実施例に係る冗長パケットのフォーマットを示す図である。 本明細書に開示されているいくつかの実施例に係る冗長およびトンネリングカプセル化後のメディアパケットを示す図である。 本明細書に開示されているいくつかの実施例に係るアプリケーションペイロードを有する冗長パケットのフォーマットをより詳細に示す図である。 本明細書に開示されているいくつかの実施例に係る冗長トンネル接続状態マシンのフローチャートである。 本明細書に開示されているいくつかの実施例に係る図１のネットワーク化されたシステムの構成要素を実現するために使用可能なネットワークコンピューティング装置のブロック図である。

詳細な説明
図１は、リアルタイム通信（ＲＴＣ）サービスを安全な態様で提供するネットワーク環境のシステム図である。本明細書において用いられるリアルタイム通信（ＲＴＣ）とは、全てのユーザが、瞬時にまたは待ち時間を無視できる状態で、情報をやり取りすることができる任意の通信モードである。したがって、この文脈において、「リアルタイム」という用語は、「ライブ」と同義である。このようなリアルタイム通信の応用例としては、例えば音声通話、ビデオ通話、アプリケーションストリーミングおよびリモートデスクトップアプリケーションが挙げられ得る。エンドユーザトラフィックのためのセキュリティは、ファイアウォール、プロキシ、およびネットワーク内にある他のセキュリティ装置によって保証され得る。ネットワークは、エンドユーザトラフィックに対する制御をアサートするために管理者権限も利用し得る。本明細書に記載の技術により、指定のアプリケーショントラフィックは、ファイアウォールなどのセキュリティ装置も横断しながら、エンドユーザとリモートサーバとの間を安全に行き交うことができる。さらに、本明細書に記載の技術は、さまざまな冗長メカニズムを設けることによって、通話品質、待ち時間および／またはジッターに対処する。

図１に示されるネットワーク環境１００は、冗長なトンネリングされたサービス制御機能１１０（Redundant Tunneled Services Control Function：ＲＴＳＣＦ）と、冗長なトンネリングされたサービス要素１２０（Redundant Tunneled Services Element：ＲＴＳＥ）とを含んでいる。ＲＴＳＣＦ １１０はネットワーク側に位置しており、ＲＴＳＥ １２０はユーザ側に位置している。より具体的には、ＲＴＳＣＦ １１０は、ユーザ要素１３０（user element：ＵＥ）の一部であるか、またはＵＥ １３０と同一の側にあり、ＲＴＳＣＦ １１０は、プロキシ呼セッション制御機能１４０（proxy call session control function：Ｐ−ＣＳＣＦ）の一部であるか、またはＰ−ＣＳＣＦ １４０と同一の側にある。さらに、Ｐ−ＣＳＣＦは、アプリケーションサーバ１５０−Ａまたはリモート認証ダイヤルインユーザサービス（Remote Authentication Dial In User Service：ＲＡＤＩＵＳ）サーバ１５０−Ｒなどのサーバであり得る１つ以上のコアネットワーク要素１５０と通信する。このようなコアネットワーク要素１５０は、サービスプロバイダコアネットワーク１５５を構成する。ユーザ要素側で、ＲＴＳＥ １２０は、ＳＩＰまたはリッチコミュニケーションサービスアプリケーションなどのリアルタイム通信（ＲＴＣ）アプリケーション１６０と通信し得る。

ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、冗長で安全なトンネル１６５を確立および維持するように協働する。ＲＴＳＣＦ １１０とＲＴＳＥ １２０との間の通信は、ＲＴＳＣＦ制御プロトコルによって支配される。さらに、冗長で安全なトンネル１６５の各々は、１つ以上の安全なトンネルを用いて実現される。すなわち、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、トランスポート層セキュリティ（Transport Layer Security：ＴＬＳ）トンネルまたはデータグラムトランスポート層セキュリティ（Datagram Transport Layer Security：ＤＴＬＳ）トンネルなどの特定の安全なトンネルに冗長性を提供する。本明細書において用いられる「ＴＬＳ」という用語は、ＲＦＣ２２４６、ＲＦＣ４３４６またはＲＦＣ５２４６に規定されたプロトコルを用いて作成された接続を指し、「ＤＴＬＳ」は、ＲＦＣ６３４７またはＲＦＣ５２４８に規定されたプロトコルを用いて作成された接続を指す。

冗長で安全なトンネル１６５は、ＵＥ １３０からインターネット１７０を介してサービスプロバイダネットワークエッジ１７５まで延びている。ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、これらの冗長で安全なトンネル１６５を介してさまざまなメディアフロー１８０またはストリームをＵＥ １３０に伝送する。より具体的には、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、これらのメディアフロー１８０のペイロードを伝送し、これらのペイロードは、ＩＰマルチメディアサブシステムトラフィック、ボイスオーバーＩＰトラフィックまたはリッチコミュニケーションサービス（Rich Communication Services：ＲＣＳ）トラフィックなどのリアルタイムトラフィックを含む。ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、リアルタイムトラフィックに何らかの形態の冗長性を提供する。また、ＲＴＳＣＦ １１０は、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）メッセージの形態をとり得る制御メッセージを冗長で安全なトンネル１６５を介して中継する。

いくつかの実施例では、冗長で安全なトンネル１６５は、とりわけセッション開始プロトコル（Session Initiation Protocol：ＳＩＰ）、リアルタイム伝送プロトコル（Real-time Transport Protocol：ＲＴＰ）およびメッセージシステムリレープロトコル（Message System Relay Protocol：ＭＳＲＰ）を用いるものなどのリアルタイム通信（real-time communication：ＲＴＣＯ）サービスを提供する複数のアプリケーション間で共有され得る。他の実施例では、ＵＥ １３０上の各々のＲＴＣアプリケーション１６０は、それ自体の冗長で安全なトンネル１６５を利用する。

インターネットなどのベストエフォート型ネットワークを介してリアルタイム通信を伝送することにより、パケットロスおよびジッターのために、通話品質が下がる可能性がある。Ｇ．７２９ａなどのいくつかのＶｏＩＰコーデックは、音声品質の大幅な劣化なしにある程度のパケットベースのエラーを音声またはスピーチストリームに隠すことができる内蔵型回復メカニズムを有している。しかし、これらのコーデック隠蔽アルゴリズムは、ジッターの影響を無くすことができず、大量の残余のジッターがスピーチ品質を大幅に低下させる。さらに、厳重な（すなわち、ＩＭＳを認識しない）ファイアウォールを横断するためにＴＣＰ／ＴＬＳ伝送が用いられる場合、伝送メカニズムの特性は、自然な量のバースト性またはジッターをさらに悪化させる。このジッターがジッターバッファ許容値を超えると、音声品質がさらに低下したパケットロスが生じることになる。

本明細書に記載の実施例は、冗長な態様で安全なトンネルを介してユーザペイロードを伝えるために選択されたメカニズムを用いる冗長で安全なトンネル１６５を提供することによって、音声品質およびジッターに対処する。ＴＬＳおよびＤＴＬＳなどのトンネル伝送とともに使用される複数のメカニズムが、本明細書に記載されている。ＴＬＳおよびＤＴＬＳの実現例が本明細書に記載されているが、本明細書に開示されている技術は、他のトンネル伝送メカニズムにも適用可能である。さらに、本明細書に記載の実施例は、任意の特定のリアルタイムプロトコルに特有のものではなく、いかなるタイプのリアルタイム通信（ＲＴＣ）トラフィックにも使用可能である。

ＲＴＳＣＦ １１０は、安全なトンネルに対して、または安全なトンネル上で、冗長なサービスを提供する。冗長で安全なトンネル１６５の基礎を構成する安全なトンネルは、ＲＴＳＣＦ １１０によってソケットとして指定され得る。いくつかの実施例では、安全で冗長なサービスは、ソケット作成時に要求される。他の実施例では、ＲＴＳＣＦ １１０は、既に作成されているソケット上にソケットオプションを設定することによって、安全な冗長性を有効にする。いくつかの実施例では、ＲＴＳＥ １２０は、ソケットについての特定のＲＴＣ冗長性ファクタまたは冗長度を指定し得る。冗長性ファクタについては、以下でさらに詳細に説明する。

ＲＴＳＥ １２０のいくつかの実施例は、例えばジッターバッファが空であるか、または空に達しているときに、ソケットの冗長性を動的に有効にする。次いで、このようなＲＴＳＥ １２０の実施例は、当該機能が必要でないときには、冗長機能を無効にし得る。同様に、ＲＴＳＥ １２０のいくつかの実施例は、安全で冗長なトンネル機能を使用しているリアルタイム通信アプリケーションが経験する条件に応答してソケットの冗長度を動的に修正する。

単一のトンネル上のパケットの、時間をずらしたコピー、複数のトンネルにまたがるパケットのラウンドロビン送信、および複数のトンネルにまたがる時間ずらしまたはストライピングを含むさまざまな冗長メカニズムが本明細書に記載されている。ＲＴＳＣＦ １１０のいくつかの実施例は、ネットワーク条件およびトンネル伝送タイプによって適切なメカニズムを選択および設定可能であるように複数の冗長メカニズムをサポートする。本明細書では安全なトンネルを参照して説明しているが、本明細書に開示されている冗長性の技術は、セキュリティを持たないトンネルにも適用可能である。

ここで、冗長なトンネリングの概要について説明する。初めに、クライアントアプリケーション（例えば、ＳＩＰまたはリッチコミュニケーションサービスアプリケーション）がＲＴＳＥ １２０上に冗長メカニズムを設定する。次いで、ＲＴＳＥ １２０は、ＲＴＳＣＦ １１０の方へのクライアントサービス要求メッセージを起動する。クライアントサービス要求メッセージは、接続情報（例えば、アプリケーションに割り当てられたＩＰアドレスおよびポート）、特定の冗長メカニズムおよび（任意に）特定の冗長性ファクタを指定する。いくつかの実施例では、接続は、ソケット識別子を用いて指定可能である。ＲＴＳＣＦ １１０は、このサービスを提供および受け付ける準備が整っていることを示すためのクライアントサービス応答メッセージにより、サービス要求に応答する。いくつかの実施例では、特定のＲＴＣ冗長メカニズムは、ＴＳＥとＴＳＣＦとの間に現在確立されているトンネルのトンネルタイプ（ＴＬＳまたはＤＴＬＳ）に基づいて、ＲＴＳＣＦ １１０によって利用可能にされ得る。したがって、いくつかのシナリオでは、クライアントサービス要求は、冗長メカニズムが現在のトンネルタイプに適切でなければ、失敗し得る。トンネルの伝送タイプがＴＬＳ／ＴＣＰである場合、ＲＴＳＣＦ １１０は、当該要求によって作成される各々の補助（冗長な）トンネルごとに１つのＴＳＩＤ（トンネルセッション識別子）のリストをＲＴＳＥ １２０に提供し得る。当該識別子リストは、クライアントサービス応答の一部として提供されてもよく、または別個のメッセージで提供されてもよい。

図２は、単一のトンネル上でパケットの時間をずらしたコピーを使用する１つの冗長メカニズムを示す図である。このモードでは、追加の冗長なトンネルが必要とされることはなく、または作成されることはなく、既存の安全なトンネルが冗長なトンネル１６５として動作する。例えば、基礎をなすトンネルがトランスポートとしてＤＴＬＳ／ＵＤＰを用いる場合に、時間をずらした単一トンネルメカニズムが使用され得る。この冗長モードでは、（ＲＴＳＣＦ １１０またはＲＴＳＥ １２０のいずれかに対応する）送出側は、複数のカプセル化されたＲＴＣパケット２２０を結合するフレーム２１０を送信する。各フレーム２１０は、Ｎ個の以前に送信されたカプセル化されたＲＴＣパケット２２０のコピーとともに、最新の（以前に送信されていない）カプセル化されたＲＴＣパケット２２０を含む。ここで、Ｎは、冗長性ファクタまたは冗長度としてクライアントによって指定される追加の（時間をずらした）コピーの数である。

図２に示される例示的なシナリオでは、冗長性ファクタが２であるため、送出側は、単一のトンネル１６５を用いて、最新のパケット２２０とともに２つの以前に送信されたパケット２２０を送信する。この例では、パケット番号５（すなわち、シーケンス番号５）が最新であり、パケット番号３および４が既に送信されている。したがって、フレーム２１０−Ａは、パケット２２０−３（シーケンス番号３）、パケット２２０−４（シーケンス番号４）およびパケット２２０−５（シーケンス番号５）を含む。同様に、次に送信されるフレームは、フレーム２１０−Ｂであり、当該フレーム２１０−Ｂは、パケット２２０−４、パケット２２０−５およびパケット２２０−６を含む。次は、フレーム２１０−Ｃであり、当該フレーム２１０−Ｃは、パケット２２０−５、パケット２２０−６およびパケット２２０−７を含む。示されているシーケンスの中の最後のフレームは、フレーム２１０−Ｄであり、当該フレーム２１０−Ｄは、パケット２２０−６、パケット２２０−７およびパケット２２０−８を含む。

時間をずらした単一トンネルメカニズムは、スライドウィンドウ手法に基づいて冗長パケットを選択する。受信側は、受信すると予想される最後のＮ個のパケットシーケンス（ここで、Ｎは、予め構成されたパラメータである）を追跡する。

スライドウィンドウアルゴリズムは、以下の疑似コードによって記載され得る。

図３は、図２に関連付けて上記した時間をずらした単一トンネルメカニズムのための例示的なメッセージフローを示すメッセージ図である。シーケンスは、安全なトンネルを構築するためにＲＴＳＣＦ １１０またはＲＴＳＥ １２０の間で一連のメッセージ（３０５）がやり取りされることから開始する。例えば、ＴＬＳプロトコルを用いて安全なトンネルを提供する実施例では、トンネルを作成および設定するためにＴＬＳハンドシェイクが用いられる。当業者によって理解されるであろう適切なハンドシェイキングとともに、安全なトンネルを作成および維持するための他のメカニズムも利用可能である。

安全なトンネルが確立されると、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、それらのそれぞれのエンドポイントであるＲＴＣアプリケーション１６０およびＰ−ＣＳＣＦ １４０の代わりに、安全なトンネルを介してリアルタイムトラフィックを伝える。ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、構成要求および応答メッセージ３１０および３１５をやり取りし得る。ある時点で、ＲＴＣアプリケーション１６０は、安全なトンネル上で冗長性を要求するメッセージ３２０をＲＴＳＥ １２０に送る。ＲＴＳＥ １２０は、冗長性要求をクライアントサービス要求メッセージ３２５としてＲＴＳＣＦ １１０に伝え、当該クライアントサービス要求メッセージ３２５は、特定の冗長メカニズムおよび特定の冗長性ファクタを示すパラメータを含み得る。この例では、冗長メカニズムとしてTime_Staggeredが指定され、冗長性ファクタは１である。このようなパラメータが含まれていない場合、ＲＴＳＣＦ １１０は、適切なデフォルト値を利用し得る。

ＲＴＳＣＦ １１０は、要求が成功したか否かを示すクライアントサービス応答メッセージ３３０により応答する。この通知は、ＲＴＳＥ １２０が次いで、冗長性要求が成功したか否かの応答３３２によってＲＴＣアプリケーション１６０に通知することを含み得る。この時点で、ＲＴＳＣＦ １１０とＲＴＳＥ １２０との間には、冗長で安全なトンネル１６５が確立されている。

次いで、以下のように、冗長で安全なトンネル１６５を通してリアルタイム通信トラフィックが伝えられる。この例では、リアルタイム通信トラフィックは、ＲＴＰパケットに対応するが、他のタイプのメディアパケットもサポートされる。ＲＴＣアプリケーション１６０は、第１のメディアパケット３３５をＲＴＳＥ １２０に供給し、冗長で安全なトンネル１６５を通して伝える。ＲＴＳＥ １２０は、シーケンス番号を含む冗長ヘッダによりこのメディアパケット３３５をカプセル化し、フレーム３４０を生成する。これは一連のパケットの中の第１のパケットであるので、冗長で安全なトンネル１６５を通して送られるフレーム３４０は、第１のメディアパケット３３５のみを含む。ＲＴＳＣＦ １１０は、冗長ヘッダを除去することによってフレーム３４０の脱カプセル化を行い、結果として生じるメディアパケット３３５をプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１４０に供給する。次いで、Ｐ−ＣＳＣＦ １４０は、ＳＩＰサーバまたはＲＡＤＩＵＳサーバなどのＲＴＣアプリケーション１６０に対するピアとしての役割を果たすサーバ１５０−Ａ（図示せず）にメディアパケット３３５を供給する。

ＲＴＣアプリケーション１６０が第２のメディアパケット３４５を供給すると、ＲＴＳＥ １２０は、次のシーケンス番号を含む冗長ヘッダによりこのメディアパケットをカプセル化する。これは一連のパケットの中の第１のパケットではないので、冗長で安全なトンネル１６５を通して送られるフレーム３５０は、以前のＮ個のメディアパケットのコピー（ここで、Ｎは、当該トンネルについての冗長性ファクタである）と、新たなメディアパケットとを含む。この例では、Ｎ＝１であり、そのためフレーム３５０は、（既に送信されている）第１のメディアパケット３３５のコピーを含み、第２のメディアパケット３４５も含む。ＲＴＳＣＦ １１０は、フレーム３５０の脱カプセル化を行い、スライドウィンドウ（上記）を用いて、第１のメディアパケット３３５のコピーが、送信が成功したメディアパケットの複製であることを発見し、そのため第１のメディアパケット３３５のコピーを廃棄する。スライドウィンドウは、フレーム３５０内の他のメディアパケット３４５が複製ではないが、その代わりにこの特定のメディアパケットの第１の発生であることも示し、そのためＲＴＳＣＦ １１０は、メディアパケット３４５をＰ−ＣＳＣＦ １４０に供給する。次いで、Ｐ−ＣＳＣＦ １４０は、メディアパケット３４５をサーバ１５０−Ａに転送する。

ＲＴＳＥ １２０は、ＲＴＣアプリケーション１６０から別のメディアパケット３５５を受取り、次のシーケンス番号を有する冗長ヘッダによりメディアパケット３５５をカプセル化する。冗長で安全なトンネル１６５を通して送られるフレーム３６０は、以前のＮ個のメディアパケット（すなわち、メディアパケット３４５）のコピーと、まだ送信されていないメディアパケット３５５とを含む。ＲＴＳＣＦ １１０は、フレーム３６０の脱カプセル化を行い、スライドウィンドウ（上記）を用いて、第２のメディアパケット３４５のコピーが、送信が成功したメディアパケットの複製であることを発見し、そのため第１のメディアパケット３４５のコピーを廃棄する。スライドウィンドウは、フレーム３５０内の他のメディアパケット３５５が複製ではないことも示し、そのためＲＴＳＣＦ １１０は、メディアパケット３５５をＰ−ＣＳＣＦ １４０に供給する。次いで、Ｐ−ＣＳＣＦ １４０は、メディアパケット３５５をサーバ１５０−Ａに転送する。

続いて、ＲＴＳＥ １２０は、ＲＴＣアプリケーション１６０から別のメディアパケット３６５を受取り、次のシーケンス番号を有する冗長ヘッダによりメディアパケット３６５をカプセル化する。冗長で安全なトンネル１６５を通して送られるフレーム３７０は、メディアパケット３５５のコピーと、まだ送信されていないメディアパケット３６５とを含む。この例示的なシナリオでは、メディアパケット３６５は失われる。すなわち、メディアパケット３６５は、冗長で安全なトンネル１６５を通して上手く送信されず、ＲＴＳＣＦ １１０は、フレーム３７０を受取らない。代替的なシナリオでは、ＲＴＳＣＦ １１０はフレーム３７０を受取り得るが、フレーム３７０内のメディアパケット３６５は破損している恐れがある。

続いて、ＲＴＳＥ １２０は、ＲＴＣアプリケーション１６０から別のメディアパケット３７５を受取り、次のシーケンス番号を有する冗長ヘッダによりメディアパケット３７５をカプセル化する。冗長で安全なトンネル１６５を通して送られるフレーム３８０は、メディアパケット３６５のコピーと、まだ送信されていないメディアパケット３７５とを含む。ＲＴＳＣＦ １１０は、フレーム３８０の脱カプセル化を行い、スライドウィンドウにより、第４のメディアパケット３６５のコピーが予想通り複製ではないが、その代わりに新たに送信されたメディアパケットであることを知る。したがって、複製としての第４のメディアパケット３６５のコピーを廃棄する代わりに、ＲＴＳＣＦ １１０は、メディアパケット３６５およびメディアパケット３７５の両方をＰ−ＣＳＣＦ １４０に転送する。次いで、Ｐ−ＣＳＣＦ １４０は、メディアパケット３５５をサーバ１５０−Ａに転送する。

図２および図３に記載されている実施例は、単一の安全なトンネルに沿ってメディアパケットの複数のコピーを送信することによって当該トンネルを介して冗長性を提供する。言い換えれば、図２および図３の実施例では、メディアパケットが時間的にずらされる。ここで、複数の安全なトンネルを利用して冗長性を提供する他の実施例について説明する。下記のように、いくつかの実施例は、複製パケットと複数のトンネルとを組み合わせ得る。

図４は、複数のトンネルを通したパケットのラウンドロビン送信を使用する別の冗長メカニズムを示すブロック図である。いくつかの実施例では、このメカニズムは、トンネルがトランスポートとしてＴＬＳ／ＴＣＰを用いる場合にサポートされる。この冗長モードでは、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、追加の安全なトンネルを構築するように協働する。このような追加のトンネルは、本明細書では「補助トンネル」と呼ばれてもよく、冗長性要求時に存在しているトンネルは、「主トンネル」または「主要トンネル」と呼ばれる。そして、主要トンネルおよび補助トンネルは、全体で冗長性を提供するように協働する。この実施例では、トンネルの数Ｎは、クライアントサービス要求における冗長性ファクタとして指定される。

（ＲＴＳＣＦ １１０またはＲＴＳＥ １２０のいずれかに対応する）送出側は、一連のフレーム４１０を送信し、各々の後続のフレーム４１０は、ラウンドロビンまたは循環する態様で次のトンネル（１〜Ｎ＋１）に沿って送られる。図４に示される例示的なシナリオでは、冗長性ファクタは２であり、これは、合計３つのトンネル、すなわち１つの主要トンネルおよび２つの補助トンネルを示している。この特定の例では、パケット４２０−５（すなわち、シーケンス番号５）を含む第１のフレーム４１０−Ａが、主要トンネル１６５−Ｐに沿って送信される。次いで、フレーム４１０−Ｂが補助トンネル１６５−Ａ１に沿って送信され、フレーム４１０−Ｂは、次のパケット４２０−６（すなわち、シーケンス番号６）を含む。その後、フレーム４１０−Ｂ（すなわち、シーケンス番号８）が、次のトンネルである補助トンネル１６５−Ａ２に沿って送信される。フレーム４１０−Ｃは、次のパケット４２０−７（すなわち、シーケンス番号８）を含む。次いで、Ｎ個のトンネルを通るシーケンシングがラウンドロビンの態様で繰り返される。すなわち、パケット４２０−８を有するフレーム４１０−Ｄが主要トンネル１６５−Ｐに沿って送信され、パケット４２０−９を有するフレーム４１０−Ｅが補助トンネル１６５−Ａ１に沿って送信され、パケット４２０−１０を有するフレーム４１０−Ｆが補助トンネル１６５−Ａ２に沿って送信される。

図４に示される例示的なシナリオでは、厳密なラウンドロビンの態様でシーケンシングが行われ、そのためトンネルのシーケンスは固定される。他の実施例では、シーケンスは変化し得て、例えば１からＮまでシーケンスが増加し、続いてＮ−１から１までシーケンスが減少するというものであってもよい。このようなシーケンスは、時には「スネーク（snake）」または「ジグザグ」と呼ばれる。また、図４に示される実施例では各フレーム４１０内に単一のＲＴＣパケット４２０のみが担持されるが、他の実施例ではフレーム４１０当たり２つ以上のＲＴＣパケット４２０が担持されてもよい。

図５は、図４に関連付けて上記したラウンドロビン複数トンネルメカニズムのための例示的なメッセージフローを示すメッセージ図である。シーケンスは、主要トンネルとして動作する第１の安全なトンネルを構築するためにＲＴＳＣＦ １１０とＲＴＳＥ １２０との間で一連のメッセージ（５０５）がやり取りされることから開始する。ＴＬＳプロトコルを用いて安全なトンネルを提供する実施例は、トンネルを作成および設定するためにＴＬＳハンドシェイクを使用し得る。当業者によって理解されるであろう適切なハンドシェイキングとともに、安全なトンネルを作成および維持するための他のメカニズムも利用可能である。

安全なトンネルが確立されると、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、それらのそれぞれのエンドポイントであるＲＴＣアプリケーション１６０およびＰ−ＣＳＣＦ １４０の代わりに、安全なトンネルを介してリアルタイムトラフィックを伝える。ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、構成要求および応答メッセージ５１０および５１５をやり取りし得る。ある時点で、ＲＴＣアプリケーション１６０は、安全なトンネル上で冗長性を要求するメッセージ５２０をＲＴＳＥ １２０に送る。ＲＴＳＥ １２０は、冗長性要求をクライアントサービス要求メッセージ５２５としてＲＴＳＣＦ １１０に伝え、当該クライアントサービス要求メッセージ５２５は、特定の冗長メカニズムおよび特定の冗長性ファクタを示すパラメータを含み得る。この例では、冗長メカニズムとしてRound_Robinが指定され、冗長性ファクタは２である。このようなパラメータが含まれていない場合、ＲＴＳＣＦ １１０は、適切なデフォルト値を利用し得る。

ＲＴＳＣＦ １１０は、要求が成功したか否かを示すクライアントサービス応答メッセージ５３０により応答する。クライアントサービス応答５３０は、新たに作成される補助トンネルについてのトンネルセッション識別子のリストを含み得る。クライアントサービス応答５３０を受取った後、ＲＴＳＥ １２０は、冗長性要求が成功したか否かをＲＴＣアプリケーション１６０に通知する。この時点で、ＲＴＳＣＦ １１０とＲＴＳＥ １２０との間には冗長で安全なトンネル１６５が確立されており、冗長で安全なトンネル１６５は、主要トンネルと、冗長性ファクタによって規定される数の補助トンネルとを含む。最後に、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、補助トンネルを構成するためにＴＬＳハンドシェイク５４０を実行し得る。

次いで、以下のように、冗長で安全なトンネル１６５を通してリアルタイム通信トラフィックが伝えられる。この例では、リアルタイム通信トラフィックは、ＲＴＰパケットに対応するが、他のタイプのメディアパケットもサポートされる。ＲＴＣアプリケーション１６０は、第１のメディアパケット５４５をＲＴＳＥ １２０に供給し、冗長で安全なトンネル１６５を通して伝える。ＲＴＳＥ １２０は、シーケンス番号を含む冗長ヘッダによりこのメディアパケット５４５をカプセル化し、結果として生じるフレーム５５０を主要トンネル１６５−Ｐを通して送信する。ＲＴＳＣＦ １１０は、冗長ヘッダを除去することによってフレーム５５０の脱カプセル化を行い、結果として生じるメディアパケット５４５をプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１４０に供給する。次いで、Ｐ−ＣＳＣＦ １４０は、ＳＩＰサーバまたはＲＡＤＩＵＳサーバなどのＲＴＣアプリケーション１６０に対するピアとしての役割を果たすサーバ１５０−Ａ（図示せず）にメディアパケット５４５を供給する。

後の時点で、ＲＴＣアプリケーション１６０は、第２のメディアパケット５５５を供給し、ＲＴＳＥ １２０は、次のシーケンス番号を含む冗長ヘッダによりこのメディアパケットをカプセル化し、結果として生じるフレーム５６０を第１の補助トンネル１６５−Ａ１を通して送信する。ＲＴＳＣＦ １１０は、フレーム５６０の脱カプセル化を行って５５５を明らかにし、５５５は、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１４０に伝えられ、次いでサーバ１５０−Ａ（図示せず）に伝えられる。図５から分かるように、第３のメディアパケット５６５は同様に処理される。すなわち、メディアパケット５６５は、カプセル化され、その結果フレーム５７０が得られ、フレーム５７０は、第２の補助トンネル１６５−Ａ２を介して送信される。ＲＴＳＣＦ １１０は、フレーム５７０の脱カプセル化を行って５６５を明らかにし、５６５は、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１４０に伝えられ、次いでサーバ１５０−Ａ（図示せず）に伝えられる。図５から分かるように、連続的なパケットが、異なるトンネルに沿って送信されるだけでなく、時間の点で切り離されてもいる。これは、パケット番号２がパケット番号１の後に送信を開始し、パケット番号３がパケット番号２の後に送信を開始するなどの理由からである。これらの差異化の各々は、全体の誤り率を減少させる。このラウンドロビンメカニズムはパケットを複製しないので、より高いレベル、例えばＴＣＰまたはＴＬＳで誤り検出および／または訂正を処理することができる。

図６は、複数のトンネルにまたがる時間ずらしまたはストライピングを使用する別の冗長メカニズムを示すブロック図である。ストライピング複数トンネルメカニズムは、例えばトンネルがトランスポートとしてＴＬＳ／ＴＣＰを用いる場合に使用され得る。この冗長モードでは、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、既に存在している主要トンネルに加えて安全な補助トンネルを構築するように協働する。この実施例では、トンネルの数Ｎは、クライアントサービス要求における冗長性ファクタとして指定される。メディアパケットは、トンネルをまたがって複製され、当該複製は、時間がずらされている。ストライピング複数トンネルモードでは、ＲＴＳＣＦ １１０もＲＴＳＥ １２０も、（メディアパケットのカプセル化中に追加される冗長ヘッダに設けられる）最後に受取られるＲＴＣシーケンスを追跡する。受信側は、冗長ヘッダを取除き、ペイロード（元のパケット）を対応するアプリケーションに転送する。受取られるパケットＲＴＣシーケンスが以前に受取られたもの以下であれば、当該パケットは廃棄される。

この動作モードは、図６に示されている。（ＲＴＳＣＦ １１０またはＲＴＳＥ １２０のいずれかに対応する）送出側は、一連のフレーム６１０を送信し、各々の後続のフレーム６１０は、各トンネルに沿って送られるが、時間がずらされる。図６に示される例示的なシナリオでは、冗長性ファクタは２であり、これは、合計３つのトンネル、すなわち１つの主要トンネルおよび２つの補助トンネルを示している。この特定の例では、メディアパケット６２０−５（すなわち、シーケンス番号５）を含む第１のフレーム６１０−Ａが、最初に主要トンネル１６５−Ｐに沿って送信され、その後補助トンネル１６５−Ａ１に沿って送信され、さらにその後補助トンネル１６５−Ａ２に沿って送信される。主要トンネル１６５−Ｐに沿って（パケットメディア６２０−５を含む）フレーム６１０−Ａを送信した後、送出側は次いで、次のメディアパケット６３０−６（すなわち、シーケンス番号６）を含むフレーム６１０−Ｂを、全てのトンネル、すなわち主要トンネル１６５−Ｐ、続いて補助トンネル１６５−Ａ１、続いて補助トンネル１６５−Ａ２に沿って送信する。図６から分かるように、フレーム６１０−Ｃ、６１０−Ｄおよび６１０−Ｅは、同様に処理される。

図７は、ストライピング複数トンネルメカニズムのための例示的なメッセージフローを示すメッセージ図である。シーケンスは、主要トンネルとして動作する第１の安全なトンネルを構築するためにＲＴＳＣＦ １１０またはＲＴＳＥ １２０の間で一連のメッセージ（７０５）がやり取りされることから開始する。ＴＬＳプロトコルを用いて安全なトンネルを提供する実施例は、トンネルを作成および設定するためにＴＬＳハンドシェイクを使用し得る。当業者によって理解されるであろう適切なハンドシェイキングとともに、安全なトンネルを作成および維持するための他のメカニズムも利用可能である。

安全なトンネルが確立されると、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、それらのそれぞれのエンドポイントであるＲＴＣアプリケーション１６０およびＰ−ＣＳＣＦ １４０の代わりに、安全なトンネルを介してリアルタイムトラフィックを伝える。ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、構成要求および応答メッセージ７１０および７１５をやり取りし得る。ある時点で、ＲＴＣアプリケーション１６０は、安全なトンネル上で冗長性を要求するメッセージ７２０をＲＴＳＥ １２０に送る。ＲＴＳＥ １２０は、冗長性要求をクライアントサービス要求メッセージ７２５としてＲＴＳＣＦ １１０に伝え、当該クライアントサービス要求メッセージ７２５は、特定の冗長メカニズムおよび特定の冗長性ファクタを示すパラメータを含み得る。この例では、冗長メカニズムとしてStripe_Across_Multipleが指定され、冗長性ファクタは１である。このようなパラメータが含まれていない場合、ＲＴＳＣＦ １１０は、適切なデフォルト値を利用し得る。

ＲＴＳＣＦ １１０は、要求が成功したか否かを示すクライアントサービス応答メッセージ７３０により応答する。クライアントサービス応答７３０は、新たに作成される補助トンネルについてのトンネルセッション識別子のリストを含み得る。クライアントサービス応答７３０を受取った後、ＲＴＳＥ １２０は、冗長性要求が成功したか否かをＲＴＣアプリケーション１６０に通知する。この時点で、ＲＴＳＣＦ １１０とＲＴＳＥ １２０との間には冗長で安全なトンネル１６５が確立されており、冗長で安全なトンネル１６５は、主要トンネルと、冗長性ファクタによって規定される数の補助トンネルとを含む。最後に、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０は、補助トンネルを構成するためにＴＬＳハンドシェイク７４０を実行し得る。

次いで、以下のように、冗長で安全なトンネル１６５を通してリアルタイム通信トラフィックが伝えられる。この例では、リアルタイム通信トラフィックは、ＲＴＰパケットに対応するが、他のタイプのメディアパケットもサポートされる。ＲＴＣアプリケーション１６０は、第１のメディアパケット７４５をＲＴＳＥ １２０に供給し、冗長で安全なトンネル１６５を通して伝える。ＲＴＳＥ １２０は、シーケンス番号を含む冗長ヘッダによりこのメディアパケット７４５をカプセル化し、結果として生じるフレーム７５０を主要トンネル１６５−Ｐを通して送信する。また、ＲＴＳＥ １２０は、結果として生じるフレーム７５０を、このシナリオでは単一の補助トンネル１６５−Ａ１である補助トンネルを通して送信する。例示的なシナリオでは、この送信は実質的に同時に行われるが、他の実施例では、遅延が生じ得る。

フレーム７５０の第１のインスタンスが到着すると、ＲＴＳＣＦ １１０は、冗長ヘッダを除去することによってフレーム７５０を受取ってフレーム７５０の脱カプセル化を行い、結果として生じるメディアパケット７４５をプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１４０に供給する。フレーム７５０の第２のインスタンスが到着すると、ＲＴＳＣＦ １１０は、スライドウィンドウを用いて、後続の到着が、送信が成功したフレームの複製であることを発見し、そのため後続のインスタンスを廃棄する。より具体的には、ＲＴＳＣＦ １１０もＲＴＳＥ １２０も、（冗長ヘッダに見られる）最後に受取られるＲＴＣシーケンス番号を追跡し、ＲＴＣシーケンス番号が以前に受取られたＲＴＣシーケンス番号以下であればＲＴＣパケットを廃棄する。

このシナリオでは、次のメディアパケットは、ＲＴＳＥ １２０ではなくＲＴＳＣＦ １１０によって送られる。Ｐ−ＣＳＣＦ １４０は、第２のメディアパケット７５５番号２を供給し、ＲＴＳＣＦ １１０は、次のシーケンス番号を含むように冗長ヘッダによりこのメディアパケットをカプセル化する。結果として生じるフレーム７６０番号２は、両方のトンネル、すなわち主要トンネル１６５−Ｐおよび補助トンネル１６５−Ａ１を通して送信される。フレーム７６０番号２の第１のインスタンスが到着すると、受け手であるＲＴＳＥ １２０は、冗長ヘッダを除去することによって７６０番号２の脱カプセル化を行い、結果として生じるメディアパケット７５５番号２をプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）１４０に供給する。フレーム７６０番号２の第２のインスタンスが到着すると、ＲＴＳＣＦ １１０は、スライドウィンドウを用いて、後続の到着が、送信が成功したフレームの複製であることを発見し、そのため後続のインスタンスを廃棄する。この例示的なシナリオでは、フレーム７５０は、送信される最初のフレームであるが、主要トンネル１６５−Ｐにおける遅延のために、フレーム７６０番号２よりも遅くに受取られる。

図８は、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０のいくつかの実施例に係るさまざまなプロトコルスタックおよび層を通るメディアパケットの移動を示す。メディアパケットは、ユーザ側スタック８１０−Ｕ、ＲＴＳＣＦスタック８１０−Ｒ、Ｐ−ＣＳＣＦスタック８１０−ＰおよびＣＮＥスタック８１０−Ｃを横断する。パケットは、最初に冗長で安全なトンネル１６５を介して伝えられてＰ−ＣＳＣＦ １４０に到達し、次いでＰ−ＣＳＣＦ １４０からＣＮＥ １５０までクリアテキスト経路を進む。

（図３、図５および図７に関連付けて前で参照した）トンネル構築およびネゴシエーション手順中に、ＲＴＳＣＦ １１０は、内側（リモート）ＩＰアドレスをＵＥ １３０に割り当てる。内側アドレスは、ＲＴＳＣＦ １１０上で局所的に構成されてもよく、または、ＲＴＳＣＦ １１０が、ＩＰマルチメディアサービス（IP Multimedia Services：ＩＭＳ）ネットワークに位置する認証、承認およびアカウンティング（authentication, authorization and accounting：ＡＡＡ）サーバなどの３ＧＰＰ ＡＡＡサーバを介してリモートＩＰアドレスを取得してもよい。

リアルタイム通信（ＲＴＣ）アプリケーション１６０によって実現される全ての上位層プロトコルは、ＲＴＳＣＦ １１０によって割り当てられたリモートＩＰアドレスを用いて、コアネットワーク要素１５０と通信する。ＲＴＣアプリケーション１６０によって生成されたメディアパケットは、ユーザ側スタック８１０−Ｕを通って、最初に層８２０−Ｕによって内側ＩＰアドレスを備える。次いで、ＴＬＳトンネリング層８３０−Ｕが、メディアパケットに対してトンネリングカプセル化を行う。次いで、外側トランスポートＩＰ層８４０−Ｕが、外側ＩＰアドレスを付加する。最後に、メディアパケットは、Ｌ２／Ｌ１層８５０−Ｕを通過して、リンク上に送信される。

ＲＴＳＣＦ １１０では、このプロセスの逆のプロセスが行われる。パケットは、リンクに沿ってＲＴＳＣＦ １１０によって受取られ、Ｌ２／Ｌ１層８５０−ＲにおいてＲＴＳＣＦスタック８１０−Ｒに入る。パケットは、外側トランスポート層８４０−Ｒに伝えられ、そこで外側ＩＰアドレスが取除かれる。パケットは、続いてＴＬＳトンネリング層８３０−Ｒを通り、次いで内側ＩＰ層８２０−Ｒを通り、そこで内側ＩＰアドレスが取除かれる。

冗長で安全なトンネル１６５を横断すると、パケットは次いで、方向転換して、Ｐ−ＣＳＣＦスタック８１０−Ｐを下がっていく。脱トンネリングされたメディアパケットは、最初にＲＴＣアプリケーション１６０−Ｐによって処理され、次いでリモートＩＰ層８２０−Ｐによって処理される。この時点で、パケットは、クリアテキストであり、Ｌ２／Ｌ１層８５０−Ｐによって処理されて、リンク上に送信される。なお、Ｐ−ＣＳＣＦ １４０とＣＮＥ １５０との間にはトンネルが関与していないので、１つの（リモート）ＩＰ層のみが使用される。パケットは、ＣＮＥ １５０において受取られ、逆のプロセスが行われる。すなわち、最初にＬ２／Ｌ１層８５０−Ｃによって処理され、次いでリモートＩＰ層８２０−Ｃによって処理される。最後に、メディアパケットは、リアルタイム通信（ＲＴＣ）アプリケーション１６０−Ｃに送達される。

このように、ＲＴＳＣＦ １１０は、ＩＭＳパケットをトンネリングおよび脱トンネリングし、冗長で安全なトンネル１６５からＣＮＥ １５０に内側パケットを転送する。ＲＴＳＣＦ １１０がＩＭＳメッセージをＰ−ＣＳＣＦ １４０に転送すると、Ｐ−ＣＳＣＦ １４０は、３ＧＰＰ ＩＭＳ仕様（３ＧＰＰ ＴＳ ２４．２２９）に規定されているようにＩＭＳメッセージを処理する。

図９は、本明細書に記載のさまざまな実施例に係る冗長パケットのフォーマットを示す。ＲＴＳＣＦ １１０が特定のアプリケーションソケット上で冗長性を有効にし、設定するたびに、当該ソケットに沿って送信される各々のメディアパケットは、冗長ヘッダ９１０を元のメディアパケットに追加することによってカプセル化され、したがってこれは、ペイロード９２０であると考えられる。冗長ヘッダ９１０は、シーケンス番号フィールド９３０と、ペイロード長フィールド９４０とを含む。冗長ヘッダ９１０は、１つ以上の予備のフィールド９５０も含み得る。

図１０は、冗長性およびトンネリングカプセル化後に送信リンク上に現れるメディアパケットの分解組立図である。ＵＥ １３０から生じたパケットが、ユーザ側スタック８１０−Ｕを横断し、リンク上での送信の準備が整ったとき、このようなパケットは、ＴＬＳトンネルヘッダ１０３０によって切り離される内側ヘッダ部分１０１０および外側ヘッダ部分１０２０から構成されている。外側ヘッダ部分１０２０およびペイロード９２０は、冗長で安全なトンネル１６５内で暗号化されるが、残りの部分は暗号化されない。

最初に「電話線で」送信される外側ヘッダ部分１０２０は、外側Ｌ２ヘッダ１０４０と、それに続く外側Ｌ３ヘッダ１０５０と、それに続く外側Ｌ４ヘッダ１０６０とを含む。次に、ＴＬＳトンネルヘッダ１０３０が送信される。次に送信されるのは、内側ヘッダ部分１０１０であり、当該内側ヘッダ部分１０１０は、内側Ｌ３ヘッダ１０７０と、内側Ｌ４ヘッダ１０８０とを含む。ペイロード９２０が最後に送信される。トンネルの存在は、アプリケーション／Ｐ−ＣＳＣＦ層にトランスペアレントであるか、またはアプリケーション／Ｐ−ＣＳＣＦ層に直交している。言い換えれば、内側ＩＰアドレスは、ＴＬＳトンネルを収容するようには修正されておらず、まるでトンネルが存在しないように動作する。

図１１は、ＲＴＳＣＦ １１０およびＲＴＳＥ １２０によって使用される制御パケットの分解組立図である。制御メッセージは、キープアライブメカニズム、プロトコルのバージョン、ＵＥ内側ＩＰアドレスの割り当て、ヘッダ圧縮および認証メカニズムなどのパラメータをネゴシエートするために使用され得る。制御パケットは、ＴＬＳトンネルヘッダ１１３０によって切り離される制御メッセージ１１１０および外側ヘッダ部分１１２０から構成されている。最初に「電話線で」送信される外側ヘッダ部分１１２０は、外側Ｌ２ヘッダ１１４０と、それに続く外側Ｌ３ヘッダ１１５０と、それに続く外側Ｌ４ヘッダ１１６０とを含む。次に、ＴＬＳトンネルヘッダ１１３０が送信される。制御メッセージ１１１０が最後に送信される。

図１２は、ＲＴＳＥ １２０のいくつかの実施例によって使用される接続状態マシンのためのフローチャートである。このような状態マシンは、ＩＭＳを認識しないファイアウォールの存在を検出し、このファイアウォールを横断するために使用され得る。初めに、ブロック１２１０において、ＩＭＳアプリケーションは、３ＧＰＰ仕様ＴＳ ２４．２２９に規定された通常の手順に従ってレジスタを試みる。ブロック１２２０において、レジスタの成功が確認される。レジスタが成功すると、処理はブロック１２３０に進み、ブロック１２３０において、ＲＴＳＥ １２０は、トンネルを維持する状態に入る。いくつかの実施例では、ＲＴＳＥ １２０は、ＮＡＴ横断のための３ＧＰＰに規定された代替的な手順を用いてレジスタを試みてもよい。

しかし、レジスタが失敗すると、処理はブロック１２４０に進み、ブロック１２４０において、ＲＴＳＥ １２０は、ＲＴＳＣＦ １１０上の特定の宛先ポート（例えば、８０／４４３）にＴＬＳトンネルを確立しようと試みる。ブロック１２５０において、確立が成功したか否かについて確認される。ＴＬＳトンネルの確立が成功すると、処理はブロック１２３０に進み、ブロック１２３０において、ＲＴＳＥ １２０は、トンネルを維持する状態に入る。トンネルが確立されると、ＲＴＳＥ １２０は、ＩＭＳを認識しない（すなわち、厳密な）ファイアウォールの存在もＩＭＳ制御プレーンおよびユーザプレーンプロトコルに示し得る。この時点で、全てのＩＭＳプロトコルは、確立された安全なトンネルを介して全てのそれらのトラフィックを送る。任意に、エンド・ツー・エンドセキュリティが有効にされない場合には、ＩＭＳプロトコルは、プロトコルレベルでセキュリティを無効にすることができる。なぜなら、ＴＬＳトンネリングメカニズムが、パケットレベル暗号化および認証メカニズムを提供することになるからである。

ＴＬＳトンネルの確立が成功しなければ、処理はブロック１２６０に進む。このような失敗は、明示的なＨＴＴＰプロキシが存在する可能性があることを示し得る。したがって、ＲＴＳＥ １２０は、ＨＴＴＰ ＣＯＮＮＥＣＴメソッド（ＲＦＣ２６１６）はネットワーク内のデフォルトＨＴＴＰプロキシ（例えば、ポート８０／４４３）に送る。ブロック１２７０において、ＲＴＳＥ １２０は、ＨＴＴＰ ＣＯＮＮＥＣＴに対する応答を得る。ＨＴＴＰ ＣＯＮＮＥＣＴに対する応答が失敗であれば、処理はブロック１２８０に進み、ブロック１２８０において、ＲＴＳＥ １２０は、遅延期間の間、待機し、次いで処理を再び開始させる。予め定められたいくつかの失敗は、ネットワークにおける不適当な構成を示し、その結果、ＩＭＳサービスはこのネットワークを通ることはない。

ブロック１２７０においてＨＴＴＰ ＣＯＮＮＥＣＴに対する応答が成功を示すと、ＲＴＳＥ １２０はブロック１２９０に進み、ブロック１２９０において、ＲＴＳＣＦ １１０にＴＬＳトンネルを構築しようとする別の試みがなされる。ブロック１２９５において構築の成功が確認され、成功すると、処理はブロック１２３０に進み、ブロック１２３０において、ＲＴＳＥ １２０は、トンネルを維持する状態に入る。ブロック１２９５においてＴＬＳトンネルの確立が成功しなかったと判断されると、処理はブロック１２８０に進み、ＲＴＳＥ １２０は、処理を再び開始する前に、遅延期間の間、待機する。

図１３は、本明細書に開示されているＲＴＳＣＦ １１０および／またはＲＴＳＥ １２０の実施例を実現するために使用可能なネットワーク装置のブロック図である。ネットワーク装置は、プロセッサ１３１０と、メモリ１３２０と、ネットワークインターフェイス１３３０と、記憶装置１３４０（例えば、不揮発性メモリまたはディスクドライブ）と、１つ以上の入出力（Ｉ／Ｏ）インターフェイス１３５０とを含む。これらのハードウェアコンポーネントは、バス１３６０によって結合されている。ネットワーク装置の動作を説明するために不必要ないくつかのコンポーネントは、図１３からは省略されている。

冗長メカニズムは、ソフトウェア（すなわち、プロセッサ上で実行される命令）で実現可能である。図１３は、ソフトウェア実現例を示しており、メモリ１３２０が冗長コード１３７０およびプロトコルコード１３８０を格納している。

冗長メカニズムは、専門のハードウェア論理でも実現可能である。ハードウェア実現例としては、プログラマブル論理素子（programmable logic device：ＰＬＤ）、プログラマブルゲートアレイ（programmable gate array：ＰＧＡ）、フィールドプログラマブルゲートアレイ（field programmable gate array：ＦＰＧＡ）、特定用途向け集積回路（application-specific integrated circuit：ＡＳＩＣ）、システムオンチップ（system on chip：ＳｏＣ）およびシステム・イン・パッケージ（system in package：ＳｉＰ）が挙げられる（しかし、これらに限定されるものではない）。当業者は、これらのコンポーネントがハードウェアおよびソフトウェアの任意の組合せを用いて実現されてもよいということも理解すべきである。

ネットワーク装置のいくつかの実施例では、ソフトウェアによって実現される冗長メカニズムは、コンピュータ読取可能媒体上に格納され、コンピュータ読取可能媒体は、本開示の文脈では、プロセッサによって実行可能な命令を収容、格納または実施し得る任意の構造を指す。コンピュータ読取可能媒体は、例えば電子技術、磁気技術、光学技術、電磁気技術、赤外線技術または半導体技術に基づくものであり得るが、これらに限定されるものではない。電子技術を用いたコンピュータ読取可能媒体の具体的な例としては、ランダムアクセスメモリ（random access memory：ＲＡＭ）、リードオンリーメモリ（read-only memory：ＲＯＭ）および消去可能プログラマブルリードオンリーメモリ（erasable programmable read-only memory：ＥＰＲＯＭまたはフラッシュメモリ）が挙げられるであろう（しかし、これらに限定されるものではない）。磁気技術を用いた具体的な例としては、ディスクドライブおよび携帯型コンピュータディスケットが挙げられる（しかし、これらに限定されるものではない）。光学技術を用いた具体的な例としては、コンパクトディスクリードオンリーメモリ（compact disk read-only memory：ＣＤ−ＲＯＭ）またはデジタルビデオディスクリードオンリーメモリ（digital video disk read-only memory：ＤＶＤ−ＲＯＭ）が挙げられる（しかし、これらに限定されるものではない）。

フローチャート内のいかなるプロセス説明またはブロックも、プロセスにおいて具体的な機能またはステップを実現するための１つ以上の実行可能な命令を含むモジュール、セグメントまたはコードの一部を表わすものとして理解されるであろう。ソフトウェア開発の分野における当業者によって理解されるであろうように、代替的な実現例も本開示の範囲内に包含される。これらの代替的な実現例では、機能は、関係する機能に応じて、実質的に同時または逆の順序を含む、示されているまたは記載されている順序とは異なるばらばらの順序で実行されてもよい。

上記の説明は、例示および説明の目的で提示されてきた。上記の説明は、網羅的であるように意図したものではなく、開示されている厳密な形態に本開示を限定することを意図したものでもない。上記の教示に鑑みて、自明な変形または変更が可能である。しかし、記載の実現例は、本開示の原理およびその実際的な適用を示すことによって、当業者が、意図されている特定の用途に合うように、さまざまな実現例において、さまざまな変形例とともに、本開示を利用できるようにするために、選択および記載された。すべてのこのような変形例および変更例は、公正かつ法的に認められる広がりに従って解釈される場合に、添付の特許請求の範囲によって規定される本開示の範囲内である。

Claims (11)

1. メディアパケットのストリームの第１のメディアパケットと、メディアパケットのストリームの第２のメディアパケットとを結合して、フレームにするステップを備え、前記第２のメディアパケットは前記ストリームにおいて前記第１のメディアパケットに続くメディアパケットであり、
   前記第２のメディアパケットと、前記ストリームの第３のメディアパケットとを結合して、別のフレームにするステップを備え、前記第３のメディアパケットは前記第２のメディアパケットに続くメディアパケットであり、
   前記フレームおよび前記別のフレームを受信側に送信するステップを備える、方法。
2. 前記ストリーミングメディアパケットの選択された部分の各々について、前記選択されたストリーミングメディアパケットのペイロードを前記受信側にチャネルを介して送信するステップと、
   前記ストリーミングメディアパケットの残りの部分の各々について、前記残りのストリーミングメディアパケットのペイロードを前記受信側に追加のチャネルを介して送信するステップとをさらに備える、請求項１に記載の方法。
3. 前記ストリーミングメディアパケットの前記選択された部分の各々について、前記選択されたストリーミングメディアパケットの前記ペイロードを前記受信側に前記追加のチャネルを介して送信するステップと、
   前記ストリーミングメディアパケットの前記残りの部分の各々について、前記残りのストリーミングメディアパケットの前記ペイロードを前記受信側に前記チャネルを介して送信するステップとをさらに備える、請求項２に記載の方法。
4. 前記追加のチャネルを介した前記選択されたストリーミングメディアパケットの各々の前記ペイロードの送信は、前記チャネルを介した前記選択されたストリーミングメディアパケットの対応するメディアパケットの前記ペイロードの送信に対して遅延させられる、請求項２に記載の方法。
5. メディアパケットのストリームの第１のメディアパケットのペイロードを受信側にチャネルを介して送信するステップと、
   前記ストリーミングメディアパケットの次のメディアパケットのペイロードを前記受信側に追加のチャネルを介して送信するステップとを備える、方法。
6. 前記第１のメディアパケットの前記ペイロードを前記受信側に前記追加のチャネルを介して送信するステップと、
   前記ストリーミングメディアパケットの前記次のメディアパケットの前記ペイロードを前記受信側に前記チャネルを介して送信するステップとをさらに備える、請求項５に記載の方法。
7. 送信側において実行される方法であって、
   前記送信側と受信側との間にＮ個のチャネルを確立するステップと、
   メディアパケットのストリームの各々を前記Ｎ個のチャネルからのあるチャネルに割り当てるステップと、
   各々のストリーミングメディアパケットのペイロードを前記受信側に前記割り当てられたチャネルを介して送信するステップとを備える、方法。
8. 前記メディアパケットのストリームのうちの１／Ｎを前記チャネルの各々に割り当てるステップをさらに備える、請求項７に記載の方法。
9. 前記メディアパケットは、ラウンドロビンの態様でチャネルに割り当てられる、請求項８に記載の方法。
10. 各々のストリーミングメディアパケットは、単一のチャネルに割り当てられ、各々のストリーミングメディアパケットの前記ペイロードは、前記割り当てられたチャネルのみに沿って送信される、請求項８に記載の方法。
11. 前記メディアパケットのストリームの各々を前記Ｎ個のチャネルからの別のチャネルに割り当てるステップと、
    各々のストリーミングメディアパケットのペイロードを前記受信側に前記別の割り当てられたチャネルを介して送信するステップとをさらに備える、請求項８に記載の方法。

Images