JP2020174396A - リアルタイム通信でメディア経路を確立するための方法 - Google Patents

Abstract

【課題】中間者攻撃から保護するために指紋を使用して、サービス内のリアルタイム通信（ＲＴＣ）メディアトラフィックを傍受および復号化するためのメディア経路を確立または再確立する方法を提供する。【解決手段】第１のメディアエンドポイント２０２を備えるリアルタイム通信機器（ＲＴＣ機器）２００、第２のメディアエンドポイント２０３、ＲＴＣサーバ２１８及び傍受するゲートウェイ２２４を提供するステップであって、ＲＴＣ機器２００、第２のメディアエンドポイント２０３、ＲＴＣサーバ２１８及び傍受するゲートウェイ２２４の各々が、メモリ１９２及びメモリ１９２に結合したプロセッサ１９０が実行するソフトウェアを備える。【選択図】図１

Description

（関連特許出願の相互参照）
本出願は、開示全体が参照により本明細書に組み込まれる、２０１５年５月５日に出願された米国特許仮出願第６２／１５７，３５９号明細書に基づき、その優先権の恩典を主張する。

本方法、電気通信機器、システム、またはソフトウェアモジュールは、一般に電気通信の分野に関する。

現在の広域電話網、すなわち、ＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ、公衆電話交換網）は、限定された帯域幅（３．５ｋＨｚだけ）の音声通信のために構築されている。広帯域ネットワーク、たとえば、インターネットはまた、リアルタイムの個人間通信、たとえば、しばしばＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）と呼ばれる音声通信のために使用することができる。インターネットは、データの内容またはアプリケーションとは無関係にエンドポイント間でデータを転送し、したがって、転送ネットワークと呼ばれる。

ＶｏＩＰ、またはより一般にリアルタイム通信（Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＲＴＣ）はまた、従来の電話（Ｐｌａｉｎ Ｏｌｄ Ｔｅｌｅｐｈｏｎｙ Ｓｅｒｖｉｃｅ、ＰＯＴＳ）以外のマルチメディア通信、たとえば、ビデオ、プレゼンス、およびインスタントメッセージングのために使用される。ＲＴＣのための標準およびドラフトが、多くの場合インターネット技術タスクフォース（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、ＩＥＴＦ）により規定される。

セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ、ＲＦＣ３２６１）は、ＲＴＣのために広く使用されているプロトコルである。ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）は、ＩＥＴＦにより規定されるインターネット標準である。ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ−Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）は、ＩＥＴＦおよびＷＷＷコンソーシアム（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ、Ｗ３Ｃ）により開発および標準化中の、ウェブブラウザの中に組み込まれるＲＴＣである。

ＲＴＣプロトコルは、エンドポイント機器間で音声およびビデオなどのメディアストリームを確立するために使用され、多くの場合、電話通信のような機能およびサービスを提供する。ＲＴＣプロトコルは多くの場合呼設定手順を、すなわち、呼がどのように開始され、処理され、完了するかを規定する。

データ通信ネットワークは、典型的にはインターネットのようなパケット交換網であり、パケットのアドレスにより指定される宛先にデータからなるパケットを送付する。パケットはまた、典型的にはパケットが送信されたソースアドレスを含む。データパケットは、リクエスト、応答、または文書、ファイル、もしくは映画および音声のようなメディアを表すデータを含むメッセージであってもよく、エンドポイント間で交換される。

データ通信ネットワークはまた、多くの場合組み合わされ、かつ単にＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ）、またはファイアウォール、またはアクセスルータと呼ばれることもあるＮＡＴまたはファイアウォールを通してグローバルネットワークと通信するプライベートセグメント、イントラネット、またはローカル・エリア・ネットワーク（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ、ＬＡＮ）を含んでもよい。

パケット交換網では、トラフィックは送信および受信されているデータパケットである。

リアル・タイム・トラフィックは、音声、またはビデオのような他のメディアのストリームである。そのようなメディアストリームは、ネットワークを介して電話通信のようなサービスまたは呼により使用される。

メディア経路は、そのようなメディアストリームをいくつかの異なるタイプのネットワークセグメントから構成されてもよいネットワークを介して転送する。

さまざまな機器、クライアント、およびサーバなどのエンドポイントは、ネットワーク・アクセス・ポイントに接続する、イーサネット（登録商標）、Ｗｉ−Ｆｉ、またはＬＴＥ無線インタフェースのようなネットワークインタフェースを１つまたはいくつか有する。

ネットワーク内のアドレスは、（ＩＰｖ４アドレスまたはＩＰｖ６アドレスのような）数字、またはたとえば、ドメイン・ネーム・システム（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ、ＤＮＳ）のサービスにより数字アドレスにさらに変換される完全修飾ドメイン名（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ、ＦＱＤＮ）のような記号アドレスであってもよい。

そのようなアドレスはまた、使用されているプロトコルを、またはこの状況では一般にネットワークアドレスの１つの形とすることができる、上記で例証したアドレスタイプの拡張（たとえば、ポートが指定されたＩＰｖ４アドレス１３２．６４．７５．１：１２３４）として単に使用されているプロトコルを示すために、ポート番号によりさらに指定されてもよい。

さまざまな機器、クライアント、およびサーバなどのエンドポイントは、トラフィックを送信および受信することができる、ネットワーク内のアドレスを１つまたはいくつか有する。典型的には、エンドポイントに至るアドレスは、エンドポイントのネットワークインタフェース、およびネットワークのアクセスポイントに依存する。

サーバは、クライアントによりアクセスされるネットワーク機器である。クライアントは、コンピュータ上のプログラム、またはネットワークに接続された機器とすることができる。

アプリケーションサーバは、ユーザにサービスまたは機能を提供するサーバである。

ネットワーク・アクセス・ポイントは異なる場所にあり、イーサネット（登録商標）、ＡＤＳＬモデム、ケーブルモデム、ファイバなどの異なる固定アクセス技術、およびたとえばＷｉ−Ｆｉ、３Ｇ、４Ｇ ＬＴＥなどのさまざまな無線および移動体技術を使用することができる。

公衆インターネット、およびプライベートなイントラネットまたはＬＡＮのような一般的なネットワークセグメントに加えて、特定用途向けネットワークセグメントが、たとえば、音声のための、およびおそらくはビデオのためであろうが一般的なデータトラフィックのためではない、シグナリングおよびメディアを伝える電話通信タイプのネットワークがある。ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）は、インターネットのような一般的なデータネットワークを介しても、移動体の世界で呼ばれるようなＯＴＴ（Ｏｖｅｒ Ｔｈｅ Ｔｏｐ）でも、またはＩＰネットワークを使用するＶｏＬＴＥ（Ｖｏｉｃｅ ｏｖｅｒ ＬＴＥ）のような特定用途向けネットワークセグメントを介してもよい。

シグナリングは、典型的にはネットワークセグメントを介したエンドポイントとプロキシとサーバの間のシグナリングチャネル内のメッセージである。シグナリングチャネルを介したシグナリングは、たとえば、無線有効範囲を解放する、機器のインタフェースを変更する、またはネットワークセグメントのアクセスポイントを変更するときに中断することができるが、その後、シグナリング接続性を再確立するように回復することができる。

ファイアウォールおよびＮＡＴは、典型的にはリアルタイム通信を遮断し、これは、プライベートネットワークのエッジにあるセッション・ボーダ・コントローラ（Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ、ＳＢＣ）により、またはたとえば、ＳＴＵＮ（Ｓｅｓｓｉｏｎ Ｔｒａｖｅｒｓａｌ Ｕｔｉｌｉｔｉｅｓ ｆｏｒ ＮＡＴ、ＲＦＣ５３８９）、ＴＵＲＮ（Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙｓ ａｒｏｕｎｄ ＮＡＴ、ＲＦＣ５７６６）、およびＩＣＥ（Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ、ＲＦＣ５２４５）などの方法もしくはプロトコルにより解決される問題である。

ＴＵＲＮサーバは、２つのネットワークアドレス間のトラフィックを中継する、中継サーバの一例である。ＴＵＲＮサーバはＲＴＣエンドポイントにより発見されることができ、封じ込められたネットワークセグメントの場合、封じ込められたネットワークセグメントの外側で、ＲＴＣメディアトラフィックのために使用されなければならない。

ＳＢＣはまた、ＶｏＩＰおよびＲＴＣのためのセキュリティおよび相互運用性の機能を実装し、多くの場合インターネット電話通信サービスプロバイダの（ＩＴＳＰの）ＶｏＩＰサービスをＩＰ−ＰＢＸに接続するために使用され、ＳＩＰトランキングとも呼ばれる。

ＩＰ−ＰＢＸは、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、ＩＰ）構内交換機（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ、ＰＢＸ）である。

コールセンタは、ほとんどの場合ＩＰ−ＰＢＸまたはユニファイドコミュニケーション（Ｕｎｉｆｉｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＵＣ）のソリューションがＩＴＳＰのＳＩＰトランクを経由して呼を受け取ることに基づく。これらの呼は、典型的には電話網から料金無料番号（米国では８００番）を経由して開始される。

ＰＢＸまたはＵＣの機能は、音声応答録音装置（Ｉｎｔｅｒａｃｔｉｖｅ Ｖｏｉｃｅ Ｒｅｓｐｏｎｓｅ、ＩＶＲ）、キュー、音声メール、およびビデオメールである可能性がある。

インスタントメッセージング（Ｉｎｓｔａｎｔ ｍｅｓｓａｇｉｎｇ、ＩＭ）、プレゼンス、画面共有、およびグループ呼出は、他のＲＴＣ機能である。

プロトコルは、通信の言語および方法を規定する１組の規則である。

一例が、どのメディアおよびコーデックを使用すべきか、およびメディアをどこに送信すべきかを記述するセッション記述プロトコル（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＤＰ、ＲＦＣ４５６６）である。そのようなリアルタイム通信を、一方のエンドポイントが、エンドポイント間のメディア通信セッションを設定するために自分の意向およびメディア能力で応じることができる他のエンドポイントに提供することができる。これがオファー・アンド・アンサ・プロトコル（Ｏｆｆｅｒ ａｎｄ Ａｎｓｗｅｒ ｐｒｏｔｏｃｏｌ、Ｏ／Ａプロトコル）である。

Ｏ／Ａプロトコルは、典型的にはメディアタイプを、たとえば、音声およびビデオがどのコーデックを使用すべきかを指定する。

そのようなＯ／Ａプロトコルはまた、たとえば、ＮＡＴトラバーサルのためにＩＣＥプロトコルにより規定されるような、エンドポイント間にメディア経路をどのように設定すべきかの方法および候補を提案してもよい。

メディア経路は、典型的にはリアルタイム通信のために設定されるが、その一方で、より範囲が広い用語である通信経路は、メディアを表しても表さなくてもよいデータを伝達するための直接チャネルまたは間接チャネルを指す。

メディアエンドポイントは、典型的には、音声またはビデオを表すリアル・タイム・トラフィックを含むメディアストリームが流れることができるようにするように、ネットワークを介してメディア経路が結合されるエンドポイントである。

再び設定された、メディアエンドポイント間に確立されたメディア経路は、再確立されたと言われる。

メディアエンドポイントは、サーバ、たとえば、ＴＵＲＮサーバを通過して、または通過することなく、他のメディアエンドポイントに直接至るメディア経路を設定することができる場合、ピア・ツー・ピア・メディア能力を有する。相互のピア・ツー・ピア・メディア能力は、２つのエンドポイントに互換性があり、かつ互いの間に直接メディア経路を設定することができることを意味する。

セッション開始プロトコル（ＳＩＰ）は、ユーザを見つけて、ＳＩＰクライアント間に呼を設定するために使用され、ＳＩＰクライアントのリアルタイム通信機器、たとえば、ハードウェアＳＩＰ電話機またはソフトウェアＳＩＰ電話機は、コンピュータ上のソフトウェアアプリケーションである。ＳＩＰは、レジストラおよびプロキシサーバを使用してユーザを見つけるシグナリングプロトコルであり、ＳＤＰ Ｏ／Ａプロトコルをさらに使用して、ＳＩＰクライアントエンドポイント間にメディアチャネルを確立する。ＳＩＰクライアントは、典型的にはユーザをＳＩＰプロキシにインタフェースで接続するＳＩＰユーザエージェントを含む。

ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）は、ウェブブラウザを拡張してウェブブラウザ間のリアルタイム通信を可能にするための、標準化中の１組の勧告およびプロトコルである。ＷｅｂＲＴＣは、ユーザを見つけるためのシグナリングを指定するのではなく、同じウェブサーバに接続されたウェブブラウザが、ＳＤＰ Ｏ／Ａプロトコルを使用して、ウェブブラウザ間のリアルタイム通信のためのメディアチャネルを確立することができるようにする。ＷｅｂＲＴＣは、ＳＴＵＮおよびＴＵＲＮを含むＩＣＥプロトコルを使用して、ＷｅｂＲＴＣメディアエンドポイント間にメディア経路を設定する。

したがって、メディアエンドポイントを含むＲＴＣ機器は、ウェブサーバからＲＴＣ機器のプログラムコードを（ＨＴＭＬおよびＪａｖａ Ｓｃｒｉｐｔ（登録商標）の形で）取り出すＷｅｂＲＴＣブラウザ内に実装されてもよい。

ＷｅｂＲＴＣを用いると、メディアストリームはＤＴＬＳ−ＳＲＴＰプロトコルを使用して暗号化され、「中間者」攻撃から保護される。保護は、暗号化鍵を生成するために使用されるチャネルまたは経路とは違った他のチャネルまたは経路を介した当事者間での指紋（暗号化鍵生成のために使用される証明書のデジタル署名）の交換を伴う。これは、メディア経路またはシグナリング経路を傍受するだけではメディアトラフィックを解読することができないことを意味する。

ウェブブラウザは、ワールド・ワイド・ウェブ（ウェブ）、インターネット上のサーバ、またはウェブサーバ上に実装されたイントラネットにアクセスするために、コンピュータまたはスマートホン上で走らせるプログラムである。

ソフトウェアアプリケーションは、コンピュータまたはスマートホン上で走らせる他のプログラムである。

ウェブサーバは、ウェブブラウザ内で実行するためのプログラムコードを、典型的にはＪａｖａ Ｓｃｒｉｐｔ（登録商標）をウェブブラウザに伝達することができ、これはＷｅｂＲＴＣと共に使用される技術である。

ハイパーテキスト転送プロトコル（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、ＨＴＴＰ）ＵＲＬ（または単に「リンク」）は、ウェブ資源を識別し、ウェブ資源を実行する際の動作を指定する。たとえば、ＵＲＬは、ドメイン名がｅｘａｍｐｌｅ．ｏｒｇであるサーバから、関連するプログラムコードがＨＴＴＰを使って得られるウェブ資源である／ｗｉｋｉ／Ｍａｉｎ＿Ｐａｇｅを指してもよい。

ＷｅｂＲＴＣブラウザ内でＨＴＴＰ ＵＲＬを実行することにより、アドレス指定されているウェブサーバから設定すべき呼を開始してもよく、これは、新興のＷｅｂＲＴＣ技術の有用な特徴である。そのようなＵＲＬは、設定すべき呼の電話番号および他の情報を、たとえば呼び出すために使用することができるＵＲＬの時間制限を含んでもよい。

ＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬは長く、不明瞭な場合があり、Ｂｉｔｌｙなどの、リンクを短縮するサービスが、Ｂｉｔｌｙが記憶している長いＨＴＴＰ ＵＲＬを表す固有のストリングにちなんで、Ｂｉｔｌｙの短いドメイン名ｂｉｔ．ｌｙを使用するので、ＵＲＬがウェブブラウザ内で実行されたときに、Ｂｉｔｌｙに進み、ＢｉｔｌｙがそのＵＲＬを完全な長いウェブリンクにリダイレクトする。

そのようなＷｅｂＲＴＣのクリック・ツー・コール・リンクは、ブラウザ内でクリックされたときに呼び出されるＷｅｂＲＴＣサーバにより生成され、ＷｅｂＲＴＣサーバに記憶されることができる。たとえば、サーバのドメイン名が次に続く固有のストリングから構成される短縮されたリンクは、それをＷｅｂＲＴＣブラウザ内で実行することが意図されるユーザに渡される。最後の有効な時間を暗号化することにより、または短縮されたリンクが有効である限りずっとＷｅｂＲＴＣサーバにリンク変換を記憶することだけにより、時間制限を実装することができる。

クリック・ツー・コール・リンク、またはそのようなリンクを実行するボタンもまたウェブサイト上で使用することができ、しばしば状況に依存し、すなわち、リンクをクリックしたのは誰か、行われた可能性があるのはどの選択か、リンクがいつクリックされたか、およびリンクがどこからクリックされたかに関する情報を伝えることができる。

ウェブブラウザの中にはＷｅｂＲＴＣをサポートするものもあれば、サポートしないものもあり、他よりもサポートが充実したものもある。したがって、他の方法では利用できない場合があるＷｅｂＲＴＣ機能を呼び出すために、ＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬリンク内に特定のドメイン名拡張を、たとえば、ｗｒｔｃ．ｃｏｍｐａｎｙ．ｃｏｍ内にｗｒｔｃを規定し、識別することが有利な場合がある。

ゲートウェイは、より多くのユーザ間でサービスが機能することができるようにするように、異なるネットワークセグメントおよびプロトコルの間で変換を行うために使用される。

クライアントは、必要なときにクライアントのサーバにアクセスするが、ＲＴＣクライアント、たとえば、ＳＩＰまたはＷｅｂＲＴＣのクライアントもまた、着信シグナリングのため、着信呼のため、または進行中の呼に関するメディア経路を再確立するために、これらのサーバに至る接続を維持する必要がある。

メディアエンドポイントは、典型的にはメディアトラフィック（メディアストリーム）を伝えるメディア経路がどのアドレス間で設定されているかをわかっており、それにより、メディア経路が個々のアドレス変更に依存するかどうかを判断することができる。

移動体機器であるスマートホンは、使用されていないときにスリープ状態に移行して、残っているバッテリ時間を節約することができるが、しばしば、メッセージを受信する、または集中型プッシュ通知サーバからのいわゆるプッシュ通知により着信ＶｏＩＰ呼の準備をするために、スリープ状態を解除することができる。

ＶｏＩＰ、ソフトクライアント、スマートホン、ならびにＲＴＣを使った拡張通信の可能性および機能により、ＲＴＣクライアントのグラフィカル・ユーザ・インタフェース（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ、ＧＵＩ）が重要になっている。ＧＵＩを改善する１つの方法が、呼状態（たとえば、アイドル、活動中、グループ呼出中、保留中、キューｎの中にある、転送中、着信未応答呼など）に基づいて別個のリストの形で連絡先（人またはユーザ）を整理することであり、この場合、（リストの形の、または単体の）各連絡先は、現在利用可能な選択を列挙する拡張可能な動作メニュー（たとえば、呼び出す、電話を切る、転送する、保留する、会議接続する、ビデオをミュート／ミュート解除する、音声をミュート／ミュート解除する、メッセージを送信する、プレゼンスおよび場合によってはさらに管理上のタスクを変更する）を有する。そのようなメニューは、短い記号を通して、たとえば、スマートホンにより連絡先の行で一般に使用される３つのバーティカルドット記号またはメニューライン記号を通して拡張することができる。

リアル・タイム・メディア・チャネルでは、デュアル・トーン・マルチ・フリーケンシ（Ｄｕａｌ Ｔｏｎｅ Ｍｕｌｔｉ Ｆｒｅｑｕｅｎｃｙ、ＤＴＭＦ）の数字を可聴周波として符号化して、またはデータパケットの形で、帯域外で伝達することができる。ＤＴＭＦで規定される記号は、０、１、２、３、４、５、６、７、８、９、＃、＊、Ａ、Ｂ、Ｃ、およびＤである。

メモリに結合したプロセッサをサーバおよびゲートウェイが有する最新のネットワークおよび電気通信機器によって、電話通信はリアルタイム通信、すなわちＲＴＣに発展しており、呼がネットワークを介してシグナリングチャネルを経由して設定され、次に、音声またはビデオのようなＲＴＣメディアトラフィックがメディアエンドポイント間を流れることができる、ネットワークを介したメディア経路の確立が続く。

一様態では、呼のハンドオーバが、スマートホンまたはラップトップコンピュータのようなＲＴＣ機器がＷｉ−Ｆｉ、ＬＴＥ無線または有線イーサネット（登録商標）のようなネットワークインタフェースをいくつか有してもよく、かつＲＴＣ機器がそのサーバに接続したときに接続識別情報を作成し、次に、シグナリングチャネルとメディア経路の両方を監視し、試験し、ネットワークへのアクセスが変更されたときにシグナリングチャネルの接続性を回復し、必要なときにメディア経路を確立または再確立することにより、インターネット、イントラネット、または電話通信タイプのネットワークセグメントのような異なるネットワークセグメントの異なるアクセスポイントからネットワークにアクセスしてもよい環境で実装される。

他の様態では、メディア経路を再確立する必要性が、シグナリングチャネルおよびメディア経路のために使用されるアドレスがさまざまに変更されることにより判断される。

他の様態では、シグナリングチャネルを監視するためにメッセージを送信する頻度が、プロセッサの能力および電力消費を節約するために、呼が継続中かどうか、またはＮＡＴもしくはファイアウォールの通路を存続させる必要があるかどうかに適合させられる。

他の様態では、シグナリングもしくはメディアに関して互換性のないエンドポイント間で呼を接続するために、またはシグナリングもしくはメディアに関して互換性のないネットワークセグメントを介して呼を接続するために、ゲートウェイが形成される。

他の様態では、監視、解析、および記録する目的でプロキシおよびメディアサーバを含むことにより、傍受するゲートウェイを通してメディア経路が確立または再確立される。

他の様態では、監視、解析、および記録する目的でＴＵＲＮサーバを含むことにより、傍受するゲートウェイを通してメディア経路が確立される、または再確立される。

他の様態では、よりリッチなメディア、改善されたメディア品質、より低いネットワーク負荷、またはより低コストの呼のために、直接メディア経路を確立または再確立することにより、異なるタイプのネットワークセグメントを介したメディア経路が避けられる。

他の様態では、異なるタイプのネットワークセグメントを有するネットワークを介して通信するためのシステムが、２つ以上のＲＴＣ機器を使用する。

他の様態では、ユーザエージェントがＲＴＣ機器に結合されたネットワークを介して通信するためのシステムが、サーバまたは相互接続するサーバ内に実装される。

他の様態では、相互接続するサーバが、ＳＩＰプロトコルを使用し、ＲＴＣ機器に結合したＳＩＰユーザエージェントが、ＲＴＣ機器内ではなくサーバ内に実装され、これは、ＲＴＣ機器自体がＳＩＰクライアントであった場合にあてはまる。

他の様態では、ゲートウェイの負荷を軽減するために、ゲートウェイ内ではなく、ＲＴＣ機器の規定されたプロトコルから逸脱することにより、ＲＴＣ機器内に、エンドポイントとの、またはネットワークセグメントとの互換性を実装する。

一様態では、呼のハンドオーバを提供するために、異なるタイプのネットワークセグメントのネットワーク・アクセス・ポイントに接続された１つまたは複数の異なるタイプのネットワークインタフェースを有するエンドポイント間にメディア経路を確立または再確立するための方法が、第１のメディアエンドポイント、第２のメディアエンドポイント、およびサーバを備えるリアルタイム通信機器を提供するステップであって、ＲＴＣ機器、第２のメディアエンドポイント、およびサーバの各々が、メモリ、およびメモリに結合したプロセッサを有するステップ、ＲＴＣ機器および第２のメディアエンドポイントが使用されるネットワークセグメントのアクセスポイントから、複数のアドレスでサーバを到達可能にするステップ、ＲＴＣ機器とサーバの間でメッセージを送信および受信するように、何らかのネットワーク・アクセス・ポイントに接続されたＲＴＣ機器の少なくとも１つのネットワークインタフェースを配置するステップ、Ｏ／Ａプロトコル（Ｏｆｆｅｒ ａｎｄ Ａｎｓｗｅｒ ｐｒｏｔｏｃｏｌ）を使用してＲＴＣ機器と第２のメディアエンドポイントの間にメディア経路を確立および再確立することにより、ピア・ツー・ピア・メディア能力を有するようにＲＴＣ機器および第２のメディアエンドポイントを構成し、次いで、ＲＴＣ機器とサーバの間に接続を確立した後に、ＲＴＣ機器とサーバの間で共有される固有の接続識別情報を作成して、非応答接続を識別し、かつ回復することができるようにし、サーバに接続するためにＲＴＣ機器により使用されるネットワーク・アクセス・ポイントもしくはネットワークインタフェースが変更されることがあるときに、またはメディア経路のために使用されるアクセスポイントもしくはネットワークインタフェースが呼の間に変更されることがあるときに、ＲＴＣ機器により、ネットワークセグメントのアクセスポイントからサーバに至るアドレスを収集するステップにより行われる。

他の様態では、サーバに至る１つまたは複数のアドレスを呼設定手順から取り出すステップ、サーバからのメッセージのソースアドレスとしてサーバに至る１つまたは複数のアドレスを取り出すステップ、サーバに至る１つまたは複数のアドレスを運ぶメッセージをサーバから受信するステップ、ＤＮＳまたは他のデータベースによるサーバに至るアドレスの検索を使用して、サーバに至る所定のアドレスからなるリストを記憶するステップ、ＲＴＣ機器により、サーバのアドレスにメッセージを繰り返し送信し、応答を受信しない場合、応答を受信し、かつ応答を受信したアドレスにメッセージを送信し続けることによりシグナリング接続性を回復するまで、他の収集されたサーバに至るアドレスを試みるステップ、ＲＴＣ機器とサーバの間のシグナリングを回復した後に、ＲＴＣ機器により、呼を受け取ることができるように、またはＯ／Ａプロトコルを使用して、ＲＴＣ機器と第２のメディアエンドポイントの間にメディア経路を確立することができるように、特定の接続を回復するためにサーバに接続識別情報を提示するステップ、ＲＴＣ機器により、メディア経路が再確立される必要があるかどうかを監視する、または通知されることにより、メディア経路再確立の必要性を判断するステップ、およびメディア経路を再確立する必要がある場合、ＲＴＣ機器により、サーバを経由してＯ／Ａプロトコルを使用することにより、ＲＴＣ機器と第２のメディアエンドポイントの間のメディア経路の再確立を開始するステップのうちの１つまたは複数により、ネットワークセグメントのアクセスポイントからサーバに至るアドレスをＲＴＣ機器が収集してもよい。

他の様態では、異なるタイプのネットワークセグメントのネットワーク・アクセス・ポイントに接続された１つまたは複数の異なるタイプのネットワークインタフェースを有するエンドポイント間にメディア経路を確立または再確立するための方法が、ＲＴＣ機器の１つまたは複数が、サーバに接続するために使用されるサーバのアドレスが変更されたことを検出する、またはサーバからのメッセージにより通知され、かつメディア経路がその変更された宛先アドレスに依存するということによる、ＲＴＣ機器が、メッセージの宛先アドレスが以前のアドレスと比較して変更されたメッセージをサーバから受信し、かつメディア経路がその変更されたアドレスに依存するということによる、ＲＴＣ機器が、メディア経路のためのサーバのアドレスが変更されたことを検出することによる、ＲＴＣ機器が、サーバを経由して第２のメディアエンドポイントから得たメッセージにより、第２のメディアエンドポイントによりメディア経路のために使用されるアドレスが変更されたということを通知されることによる、およびＲＴＣ機器が、ＲＴＣ機器と第２のメディアエンドポイントの間のメディア経路で、どちらかの方向でトラフィックが停止した、または劣化したことを検出する、または通知されることによる、アドレスまたはメディア経路状態が変更されたというイベントの発生により、ＲＴＣ機器によりメディア経路再確立の必要性を判断するステップを含む。

他の様態では、異なるタイプのネットワークセグメントのネットワーク・アクセス・ポイントに接続された１つまたは複数の異なるタイプのネットワークインタフェースを有するエンドポイント間にメディア経路を確立および再確立するための方法が、ＲＴＣ機器により、呼が継続しているかどうか、または存続させる必要があるＮＡＴまたはファイアウォールの通路があるかどうかに応じて、サーバにメッセージを繰り返し送信する頻度を適合させるステップを含む。

他の様態では、異なるタイプのネットワークセグメントのネットワーク・アクセス・ポイントに接続された１つまたは複数の異なるタイプのネットワークインタフェースを有するエンドポイント間にメディア経路を確立または再確立するための方法が、ＲＴＣ機器により使用されるプロトコルがメディア暗号化を必要とし、かつ暗号化鍵がメディアエンドポイントによりメディア経路を介して取り決められ、かつシグナリングチャネルを通してサーバにだけ利用可能な指紋を調べることにより中間者攻撃から保護するときに、シグナリングもしくはメディアに関してＲＴＣ機器と互換性がないエンドポイントに呼を接続するために、またはシグナリングもしくはメディアに関して互換性のないネットワークセグメントを介して呼を接続するために、第２のメディアエンドポイントをサーバと統合してゲートウェイを形成するステップを含む。

他の様態では、監視、解析、および記録の目的で、指紋を使用して中間者攻撃からメディアトラフィックが保護される通信プロトコルを使用して、ＲＴＣ機器とＲＴＣサービスの間でリアルタイム通信メディアトラフィックを傍受し、解読するためにエンドポイント間にメディア経路を確立するための方法が、第１のメディアエンドポイント、第２のメディアエンドポイント、ＲＴＣサーバ、および傍受するゲートウェイを備えるリアルタイム通信機器を提供するステップであって、ＲＴＣ機器、第２のメディアエンドポイント、ＲＴＣサーバ、および傍受するゲートウェイの各々が、メモリ、およびメモリに結合したプロセッサを有するステップ、ＲＴＣサービスおよびメディアサーバにより使用される通信プロトコルのためのプロキシを、傍受するゲートウェイと統合するステップであって、プロキシおよびメディアサーバの各々が、メモリ、およびメモリに結合したプロセッサを有するステップ、プロキシがメッセージを書き換えることにより、ＲＴＣ機器とメディアサーバの間に、およびメディアサーバと第２のメディアエンドポイントの間に、ＲＴＣメディア経路を確立するステップ、メディアサーバによりＲＴＣメディアを傍受、解読、および伝達するために、プロキシがメッセージを書き換えることにより指紋を配置するステップ、およびＲＴＣサービスにより使用される通信プロトコルのために前記プロキシを使用するようにＲＴＣ機器を構成するステップにより行われる。

他の様態では、監視、解析、および記録の目的で、指紋を使用して中間者攻撃からメディアトラフィックが保護されるＴＵＲＮプロトコルを使用して、ＲＴＣ機器とＲＴＣサービスの間でリアルタイム通信メディアトラフィックを傍受し、解読するためにエンドポイント間にメディア経路を確立するための方法が、第１のメディアエンドポイント、第２のメディアエンドポイント、ＲＴＣサーバ、および傍受するゲートウェイを備えるリアルタイム通信機器を提供するステップであって、ＲＴＣ機器、第２のメディアエンドポイント、ＲＴＣサーバ、および傍受するゲートウェイの各々が、メモリ、およびメモリに結合したプロセッサを有するステップ、メモリ、およびメモリに結合したプロセッサを有するＴＵＲＮサーバを、傍受するゲートウェイと統合するステップ、ＴＵＲＮサーバを使用するようにＲＴＣ機器またはＲＴＣサービスを構成することにより、または封じ込められたネットワークセグメント内でメディアエンドポイントの１つがＴＵＲＮサーバを発見することにより、ＲＴＣ機器とＴＵＲＮサーバの間に、およびＴＵＲＮサーバと第２のメディアエンドポイントの間に、ＲＴＣメディア経路を確立するステップ、および傍受するゲートウェイを通過するＲＴＣメディアトラフィックを解読するために、第１のメディアエンドポイントにより、または第２のメディアエンドポイントにより、傍受するゲートウェイにＲＴＣメディアトラフィックのための解読鍵を運ぶステップにより行われる。

他の様態では、よりリッチなメディア、改善されたメディア品質、より低いネットワーク負荷、またはより低コストの呼のためのメディア経路を実現するために、異なるタイプのネットワークセグメント間を、ゲートウェイを有するネットワークを介して接続される、ピア・ツー・ピア・メディア能力を有するエンドポイント間にメディア経路を確立または再確立するための方法が、第１のメディアエンドポイント、第２のメディアエンドポイント、および相互接続するサーバを備えるリアルタイム通信機器を提供するステップであって、ＲＴＣ機器、第２のメディアエンドポイント、および相互接続するサーバの各々が、メモリ、およびメモリに結合したプロセッサを有するステップ、Ｏ／Ａプロトコル（Ｏｆｆｅｒ ａｎｄ Ａｎｓｗｅｒ ｐｒｏｔｏｃｏｌ）を使用して、異なるタイプのメディアトラフィックのためのメディア経路を確立および再確立することにより、ピア・ツー・ピア・メディア能力を有するようにＲＴＣ機器および第２のメディアエンドポイントを構成するステップ、ＲＴＣ機器および第２のメディアエンドポイントが相互のピア・ツー・ピア・メディア互換性を有するかどうか、または相互接続するサーバが、ＲＴＣ機器と第２のメディアエンドポイントの間でＯ／Ａプロトコルを運んで、ＲＴＣ機器と第２のメディアエンドポイントの間に直接メディア経路を確立するかどうかを知ることなく、ＲＴＣ機器と第２のメディアエンドポイントの間に呼を設定しようとするステップ、ＲＴＣ機器により、第２のメディアエンドポイントが接続される相互接続するサーバに至る第１のシグナリングチャネルを確立するステップ、およびＲＴＣ機器により、相互のピア・ツー・ピア・メディア互換性の指示を受信し、次いで、直接メディア経路の確立および再確立のための処理を呼び出すステップにより行われる。

他の様態では、直接メディア経路を確立または再確立するための処理が、ＲＴＣ機器により、ＲＴＣ機器と第２のメディアエンドポイントの間のエンド・ツー・エンド・シグナリング・チャネルを通して、圧縮されてもよいＯ／Ａプロトコルを使用して、呼のための直接メディア経路の確立を要求するステップ、ＲＴＣ機器により、ＲＴＣ機器と第２のメディアエンドポイントの間の確立された第１のメディア経路を通して、圧縮されてもよいＯ／Ａプロトコルを使用して、呼のための直接メディア経路の確立を要求するステップ、およびＲＴＣ機器により、Ｏ／Ａプロトコルを使用して、呼のための直接メディア経路を確立するために、確立された第１のメディア経路を通して、またはエンド・ツー・エンド・シグナリング・チャネルを通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいＨＴＴＰ ＵＲＬの形であってもよい、呼設定に関する情報、およびＲＴＣ機器が接続される相互接続するサーバのネットワークアドレスに関する情報を送信するステップ、および第２のメディアエンドポイントにより、相互のピア・ツー・ピア・メディア互換性の指示を受信し、次いで、直接メディア経路の確立または再確立のための処理を呼び出すステップのうちの１つまたは複数により呼び出される。

他の様態では、直接メディア経路を確立または再確立するための処理が、第２のメディアエンドポイントにより、ＲＴＣ機器と第２のメディアエンドポイントの間のエンド・ツー・エンド・シグナリング・チャネルを通して、圧縮されてもよいＯ／Ａプロトコルを使用して、呼のための直接メディア経路の確立を要求するステップ、第２のメディアエンドポイントにより、ＲＴＣ機器と第２のメディアエンドポイントの間の確立された第１のメディア経路を通して、圧縮されてもよいＯ／Ａプロトコルを使用して、呼のための直接メディア経路の確立を要求するステップ、および第２のメディアエンドポイントにより、Ｏ／Ａプロトコルを使用して、呼のための直接メディア経路を確立するために、確立された第１のメディア経路を通して、またはエンド・ツー・エンド・シグナリング・チャネルを通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいＨＴＴＰ ＵＲＬの形であってもよい、呼設定に関する情報、および第２のメディアエンドポイントが接続される相互接続するサーバのネットワークアドレスに関する情報を送信するステップのうちの１つまたは複数により呼び出される。

他の様態では、第２のエンドポイントが、他のＲＴＣ機器またはゲートウェイである。

他の様態では、ネットワークを介して通信するためのシステムが、２つ以上のＲＴＣエンドポイントを含む。

他の様態では、システムのクライアント側が、電気通信機器により実装される。

他の様態では、セッション・ボーダ・コントローラの一部であってもよい、システムのサーバ側が、電気通信機器により実装される。

他の様態では、電気通信のための機器が、プログラムを組み入れ、クライアントにプログラムを送信することができる。

他の様態では、電気通信のための機器が、ウェブサーバである。

他の様態では、システムのクライアント側またはサーバ側が、ウェブブラウザ内のソフトウェアモジュール、またはスマートホン、タブレット、ラップトップ、またはパーソナルコンピュータもしくはコンピュータサーバのためのアプリケーションとしてのソフトウェアモジュール、またはプログラムを実行するためのプロセッサを備える電気通信機器内のソフトウェアモジュールにより実装される。

他の様態では、ソフトウェアモジュールが、メディア経路（１４６）を通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいメッセージ（１６４）をエンドポイントに送信する機能、メディア経路（１４６）を通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいメッセージ（１６４）をエンドポイントから受信する機能、メディアトラフィックのための代替メディア経路を使用して、品質または他の指標が評価される追加の代替メディア経路を確立する機能、セッション開始プロトコル（ＳＩＰ）を使用してリアルタイムで通信する機能、ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）プロトコルを使用してリアルタイムで通信する機能、ＩＣＥ（Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔ）を使用してエンドポイント間にメディア経路を確立する機能、ＳＴＵＮ（Ｓｅｓｓｉｏｎ Ｔｒａｖｅｒｓａｌ Ｕｔｉｌｉｔｉｅｓ ｆｏｒ ＮＡＴ）プロトコルを使用してメディア経路を確立する機能、ＴＵＲＮ（Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙｓ ａｒｏｕｎｄ ＮＡＴ）プロトコルを使用してメディア経路を確立する機能、自己学習処理から得られる、エンドポイントまたはネットワークセグメントが相互のピア・ツー・ピア・メディア互換性を有するかどうかの知識を記憶する機能、時間が制限されてもよく、ＷｅｂＲＴＣサーバに記憶され、かつＷｅｂＲＴＣブラウザユーザに短縮した形で送信されることができるＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬクリック・ツー・コール・リンクを生成する機能、時間が制限されてもよく、かつＷｅｂＲＴＣサーバに記憶することができ、かつＷｅｂＲＴＣブラウザユーザから短縮した形で受信することができるＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬリンクを実行する機能、他の方法で利用可能ではない場合があるＷｅｂＲＴＣ機能を呼び出すために、ＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬリンク内に特定のドメイン名拡張を、たとえば、ｗｒｔｃ．ｃｏｍｐａｎｙ．ｃｏｍ内にｗｒｔｃを識別する機能、ＲＴＣクライアントのためのグラフィカル・ユーザ・インタフェースで、呼状態に基づきリストの形で連絡先を整理する機能、移動体アプリケーションで使用される、小さな３つのバーティカルドット記号またはメニューライン記号により、ＲＴＣクライアントのためのグラフィカル・ユーザ・インタフェースで単一の連絡先のための拡張可能な動作メニューを表す機能、プッシュ通知によりスマートホンまたは他の移動体機器のスリープ状態を解除して、着信呼を受け取る機能、構内交換機（ＰＢＸ）機能を統合する機能、セッション・ボーダ・コントローラ（ＳＢＣ）機能を統合する機能、ユニファイドコミュニケーション（ＵＣ）のソリューション機能を統合する機能、ＳＩＰゲートウェイ機能にＷｅｂＲＴＣを統合する機能、コールセンタまたはコンタクトセンタの機能を統合する機能、状況依存のクリック・ツー・コール・リンクを生成する機能、状況依存のクリック・ツー・コール・リンクを実行する機能、ＷｅｂＲＴＣブラウザをクライアントとして使用して、コールエージェントを接続する機能、およびインスタントメッセージング（ＩＭ）、プレゼンス、画面共有、およびグループ呼出を提供する機能などの機能を遂行するプログラムを含む。

他の様態では、システムのＲＴＣ機器に結合したユーザエージェントが、サーバ、相互接続するサーバ、またはＲＴＣサーバ内に実装される。

他の様態では、相互接続するサーバが、互いの間でＳＩＰプロトコルを使用し、ＲＴＣ機器に結合したＳＩＰユーザエージェントが、相互接続するサーバ内に実装される。

他の様態では、サーバまたは相互接続するサーバが、ゲートウェイまたは傍受するゲートウェイと組み合わされる。

他の様態では、メディアエンドポイントのための規定されたＯ／Ａプロトコルがエンドポイントまたはネットワークセグメントと互換性がないときに、ゲートウェイの負荷を軽減して通信を可能にするために、規定されたＯ／Ａプロトコルから逸脱することにより、通信すべきエンドポイントおよびネットワークセグメントと互換性があるＯ／Ａプロトコルをメディアエンドポイント内に実装し、メディアエンドポイントのための規定されたメディア経路能力がエンドポイントまたはネットワークセグメントと互換性がないときに、ゲートウェイの負荷を軽減して通信を可能にするために、規定されたメディア経路能力から逸脱することにより、通信すべきエンドポイントおよびネットワークセグメントと互換性があるメディア経路能力をメディアエンドポイント内に実装する。

本明細書に組み込まれ、かつ本明細書の一部を形成する添付図面は、本発明のさまざまな実施形態を例示し、本明細書と共に本発明の原理を説明し、かつ当業者が本発明を利用することができるようにする役割をさらに果たしている。図面では、同様の参照番号が同一の要素または機能的に類似する要素を示す。添付図面と併せて考慮したときに、以下の詳細な説明を参照することにより、本発明がよりよく理解されるようになるので、本発明のより完全な理解、および本発明の付随する利点の多くが容易に得られるであろう。

関連技術による、メモリを接続されたプロセッサを含む機器、エンドポイント、サーバ、プロキシ、およびゲートウェイを示す。 関連技術による、１つのサーバを使用して２つのＲＴＣ機器間でリアルタイム通信するためのシステムを示す。 関連技術による、異なるネットワークセグメントのエンドポイント間でリアルタイム通信するためのシステムを示す。 関連技術による、ゲートウェイにより分離された異なるネットワークセグメント上のエンドポイント間でリアルタイム通信するためのシステムを示す。 本発明の一実施形態による、エンドポイント間で呼をハンドオーバするための方法を使用するシステムを示す。 本発明の一実施形態による、ゲートウェイを含む呼をハンドオーバするための方法を使用するシステムを示す。 本発明の一実施形態による、プロキシおよびメディアサーバを使用してリアルタイム通信（ＲＴＣ）メディアトラフィックを傍受し、解読するための方法を使用するシステムを示す。 本発明の一実施形態による、ＴＵＲＮサーバを使用してリアルタイム通信（ＲＴＣ）メディアトラフィックを傍受し、解読するための方法を使用するシステムを示す。 本発明の一実施形態による、異なるタイプのネットワークセグメントを介してエンドポイント間に直接メディア経路を実現するための方法を使用するシステムを示す。 一実施形態による、呼をハンドオーバするためにエンドポイント間にメディア経路を確立または再確立するための処理を示す。 一実施形態による、呼をハンドオーバするためにエンドポイント間にメディア経路を確立または再確立するための処理を示す。 プロキシを使用する一実施形態による、エンドポイント間でＲＴＣトラフィックを傍受するためのメディア経路を確立するための処理を示す。 ＴＵＲＮサーバを使用する一実施形態による、エンドポイント間でＲＴＣトラフィックを傍受するためのメディア経路を確立するための処理を示す。 一実施形態による、エンドポイント間にメディア経路を確立または再確立するための処理を示す。

一実施形態による、エンドポイント間にメディア経路を確立または再確立するための方法が図５に示されており、この図では、エンドポイントが、異なるタイプの１つまたは複数のネットワークインタフェース１９４を有し、呼のハンドオーバを実装するために、異なるタイプのネットワークセグメント１０４、１０６、１０８のネットワーク・アクセス・ポイント１４０に接続される。

携帯電話は、典型的には異なる携帯電話基地局を通して電話網にアクセスするときに、呼が維持され、継続することができるようにする。同様に、メディアストリームを確立および再確立するこの実施形態により、リアルタイム通信機器（ＲＴＣ機器）２００（たとえば、スマートホン上のソフトウェアクライアントまたはアプリケーション）が、ネットワーク・アクセス・ポイントが変更されたときに、異なるネットワークインタフェース（たとえば、固定イーサネット（登録商標）、Ｗｉ−Ｆｉ、移動体３Ｇデータ、およびＬＴＥ）を使用するときに、およびさまざまなネットワーク・アクセス・サービス・プロバイダを経由するときに、継続している呼を維持することができるようになる。

呼をハンドオーバするこの能力を実現するために、一方のメディアエンドポイント２０２および通信すべき他方のメディアエンドポイント２０３を含むリアルタイム通信機器（ＲＴＣ機器）２００が、Ｏ／Ａプロトコル（Ｏｆｆｅｒ ａｎｄ Ａｎｓｗｅｒ ｐｒｏｔｏｃｏｌ）１６０を使用して、一方のメディアエンドポイント２０２と他方のメディアエンドポイント２０３の間にメディア経路１４６を確立および再確立することにより、ピア・ツー・ピア・メディア能力を有する。そのようなメディア経路が、図３に示すファイアウォールまたはＮＡＴ、および図１に示すＴＵＲＮサーバを通過してもよい。

両方のエンドポイントは、エンドポイントが使用されるネットワークセグメント１０４、１０６、および１０８のアクセスポイント１４０から、何らかのアドレス１２０で到達可能なサーバ２１０に接続することができる。

ＲＴＣ機器（２００）は、少なくとも１つのネットワークインタフェース（１９４）を経由して何らかのネットワーク・アクセス・ポイント１４０に接続され、メッセージ１６４を送信および受信することにより、サーバ２１０に至る、またはサーバ２１０を通るシグナリングチャネルを確立する。

ＲＴＣ機器２００は、他のネットワークセグメント１０４、１０６、１０８を経由してアクセスするおかげで、サーバ２１０の数値アドレスが変更された可能性がある場合でさえ、ＤＮＳで検索されるＦＱＤＮを経由してサーバ２１０に到達することができる。サーバ２１０は、各セグメント上で別個のアドレス１２０を有するいくつかのネットワークセグメントに接続されてもよい。このとき、他のネットワークセグメント１０４、１０６、１０８にアクセスを変更するＲＴＣ機器２００が、アクセスポイント１４０が変更される以前に、ＲＴＣ機器２００が接続される、さまざまなネットワークセグメント１０４、１０６、１０８上のサーバ２１０のアドレス１２０を、サーバ２１０から受信していた可能性があり、このとき、新しいネットワークセグメントを経由して再接続することができる。

ＲＴＣ機器２００とサーバ２１０の間で接続を確立した後に、非応答接続を識別し、回復することができるようになるように、固有の接続識別情報が作成され、ＲＴＣ機器２００とサーバ２１０の間で共有される。

サーバ２１０に接続するためにＲＴＣ機器２００により使用されるネットワーク・アクセス・ポイント１４０もしくはネットワークインタフェース１９４が変更される可能性があるときに、またはメディア経路１４６のために使用されるアクセスポイント１４０もしくはネットワークインタフェース１９４が呼の間に変更される可能性があるときに、以下のステップによりメディア経路１４６を確立または再確立することができる：

−ＲＴＣ機器（２００）が、サーバ２１０に至る１つまたは複数のアドレス１２０を呼設定手順から取り出すステップにより、サーバ２１０に至る１つまたは複数のアドレス１２０をサーバ２１０からのメッセージ１６４のソースアドレスとして取り出すステップにより、サーバ２１０に至る１つまたは複数のアドレス１２０を運ぶメッセージ１６４をサーバ２１０から受信することにより、ＤＮＳまたは他のデータベースを使用してサーバ２１０に至るアドレス１２０を検索することにより、またはサーバ２１０に至る所定のアドレス１２０からなるリストを記憶することにより、ネットワークセグメント１０４、１０６、および１０８のアクセスポイント１４０からサーバ２１０に至るアドレス１２０を収集する。

−ＲＴＣ機器２００が、サーバ２１０のアドレス１２０にメッセージ１６４を繰り返し送信し、応答を受信しない場合、応答を受信し、かつ応答を受信したアドレス（１２０）にメッセージ（１６４）を送信し続けることによりシグナリングの接続性を回復するまで、他の収集されたサーバ２１０に至るアドレス１２０を試みる。

−ＲＴＣ機器２００とサーバ２１０の間のシグナリングが回復した場合、呼を受け取ることができるように、またはＯ／Ａプロトコル１６０を使用してＲＴＣ機器２００と第２のメディアエンドポイント２０３の間にメディア経路を確立および再確立することができるように、特定の接続を回復するために、ＲＴＣ機器２００によりサーバ２１０に接続識別情報が提示される。

−ＲＴＣ機器２００が、メディア経路１４６を再確立する必要があるかどうかを監視する、または通知されることにより、メディア経路再確立の必要性を判断する。

−メディア経路を再確立する必要がある場合、ＲＴＣ機器２００が、サーバ２１０を経由してＯ／Ａプロトコル１６０を使用することにより、メディア経路１４６の再確立を開始する。

メディアチャネルは、典型的には別個に監視され、中断した、または悪い品質を示すときだけ、再確立されるように試みられる。

同じく図５を参照する、呼のハンドオーバを行う他の実施形態では、ＲＴＣ機器２００が、以下のアドレスまたはメディア経路状態の変更のうちの１つが発生することにより、メディア経路確立の必要性を検出してもよい：

−サーバ２１０に接続するために使用されるサーバ２１０のアドレスが変更されたことを、ＲＴＣ機器２００が検出する、またはサーバ２１０からのメッセージ１６４により通知され、かつメディア経路１４６がその変更されたアドレスに依存する。

−メッセージ１６４の宛先アドレスが以前のメッセージと比較して変更されたサーバ２１０から、ＲＴＣ機器２００がメッセージ１６４を受信し、メディア経路１４６がその変更されたアドアレスに依存する。

−ＲＴＣ機器２００が、メディア経路１４６のためのサーバ２１０のアドレスが変更されたことを検出する。

−ＲＴＣ機器２００が、第２のメディアエンドポイントによりメディア経路１４６のために使用されるアドレスが変更されたことを、サーバを経由して第２のメディアエンドポイント２０３からのメッセージ１６４により通知される。

−ＲＴＣ機器２００が、ＲＴＣ機器２００と第２のメディアエンドポイント２０３の間のメディア経路１４６で、どちらかの方向でトラフィックが停止した、または劣化したことを検出する、または通知される。

メディアチャネルは、典型的には別個に監視され、中断した、または悪い品質を示すときだけ、再確立されるように試みられる。

同じく図５を参照する、呼のハンドオーバを行うための他の実施形態では、ＲＴＣ機器２００が、呼が継続しているかどうか、または存続させる必要があるＮＡＴまたはファイアウォールの通路があるかどうかに応じて、サーバ２１０にメッセージを繰り返し送信する頻度を適合させている。

他の実施形態が図６に示されており、この図では、ＲＴＣ機器２００により使用されるプロトコルがメディア暗号化を必要とし、かつ暗号化鍵がメディアエンドポイント２０２、２０３によりメディア経路１４６を介して取り決められ、かつシグナリングチャネルを通してサーバ２１０にだけ利用可能な指紋を調べることにより中間者攻撃から保護するときに、シグナリングまたはメディアに関してＲＴＣ機器２００と互換性がないエンドポイントに呼を接続するために、またはシグナリングまたはメディアに関して互換性がないネットワークセグメント１０４、１０６、１０８を介して呼を接続するために、ゲートウェイ２２２が第２のメディアエンドポイント２０３をサーバ２１０と統合する。

リアルタイム通信（ＲＴＣ）メディアトラフィックを、通信プロトコルを使用してＲＴＣ機器２００とＲＴＣサービス２２８の間で傍受し、解読するために、エンドポイント間にメディア経路を確立または再確立するための方法であって、メディアトラフィックが監視、解析、および記録する目的で指紋を使用して中間者攻撃から保護される、本発明による方法が、図７に示されている。

最新のプロトコル、たとえば、ＷｅｂＲＴＣは、暗号化されたメディアトラフィックを可能にするだけでなく、エンドポイント間で暗号化されたメディアトラフィックを義務づけさえし、中間者攻撃からの保護を含み、コールセンタなどがＲＴＣ通信を監視し、解析し、記録することを困難にする。この実施形態では、シグナリングを制御するためにプロキシ２１１が使用され、メディアサーバ２１４がメディアトラフィックを傍受し、解読し、中継している。

リアルタイム通信機器（ＲＴＣ機器）２００が、第１のメディアエンドポイント２０２、第２のメディアエンドポイント２０３、ＲＴＣサーバ２１８、および傍受するゲートウェイ２２４を備え、ＲＴＣ機器２００、第２のメディアエンドポイント２０３、ＲＴＣサーバ２１８、および傍受するゲートウェイ２２４の各々が、メモリ１９２、およびメモリ１９２に結合したプロセッサ１９０を有する。

傍受するゲートウェイ２２４が、ＲＴＣサービス２２８により使用される通信プロトコルのためのプロキシ２１１、およびメディアサーバ２１４を統合し、プロキシ２１１およびメディアサーバ２１４の各々が、メモリ１９２、およびメモリ１９２に結合したプロセッサ１９０を有する。

プロキシ２１１がメッセージ１６４、１６４ｂを書き換えることにより、ＲＴＣ機器２００とメディアサーバ２１４の間に、およびメディアサーバ２１４と第２のメディアエンドポイント２０３の間に、ＲＴＣメディア経路が確立される。

メディアサーバ２１４によりＲＴＣメディアトラフィックを傍受、解読、および伝達するために、プロキシ２１１がメッセージ１６４、１６４ｂを書き換えることにより、指紋が配置される。

ＲＴＣ機器２００が、ＲＴＣサービス２２８により使用される通信プロトコルのために前記プロキシ２１１を使用するように構成される。

リアルタイム通信（ＲＴＣ）メディアトラフィックを、ＴＵＲＮプロトコルを使用してＲＴＣ機器２００とＲＴＣサービス２２８の間で傍受し、解読するために、エンドポイント間にメディア経路を確立または再確立するための方法であって、メディアトラフィックが監視、解析、および記録する目的で指紋を使用して中間者攻撃から保護される、他の実施形態による方法が、図８に示されている。

最新のプロトコル、たとえば、ＷｅｂＲＴＣは、暗号化されたメディアトラフィックを可能にするだけでなく、エンドポイント間で暗号化されたメディアトラフィックを義務づけさえし、中間者攻撃からの保護を含み、コールセンタなどがＲＴＣ通信を監視し、解析し、記録することを困難にする。この実施形態では、ＴＵＲＮサーバ２１６がメディアトラフィックを中継している。

メディアストリームは、ＩＥＴＦのｄｒａｆｔ−ｓｃｈｗａｒｔｚ−ｒｔｃｗｅｂ−ｒｅｔｕｒｎ−０６に概説されるように「封じ込められている」と考えられる場合、またはＴＵＲＮサーバが自動的に発見される、もしくはソフトウェアアプリケーションにより割り当てられ、使用されるように強制される場合、ＴＵＲＮサーバを流れる。

傍受するゲートウェイもまた、メディアエンドポイント間のＩＰデフォルトゲートウェイまたはファイアウォール／ＮＡＴの中に構築されてもよい。

傍受するサーバの他の場所が、ＲＴＣがプライベートドメイン上にあり、かつ外部トラフィックが監視されるべきである使用事例を取り扱うために、ローカルネットワークまたはプライベートネットワークと広域転送ネットワークとの間でリアル・タイム・トラフィックを取り扱う機器の中であってもよい。前記傍受するサーバに自分のメディアを送信する、そのようなプライベートドメインに至る遠隔ユーザもまた、提案する方法を使用して解析されることができる。

さらに、クライアント、たとえばそうするように構成されたＷｅｂＲＴＣブラウザが、ＩＣＥ手順を修正することにより、または他の手段により、傍受するサーバを通してメディアを確立することができる。

傍受するサーバ、たとえば現行のブラウザを通して鍵を運ぶように、またはメディアを確立するように実装していないクライアントに関しては、そのようなことは、ブラウザへのプラグインまたは拡張により追加することができる。

リアルタイム通信機器（ＲＴＣ機器）２００が、第１のメディアエンドポイント２０２、第２のメディアエンドポイント２０３、ＲＴＣサーバ２１８、および傍受するゲートウェイ２２４を備え、ＲＴＣ機器２００、第２のメディアエンドポイント２０３、ＲＴＣサーバ２１８、および傍受するゲートウェイ２２４の各々が、メモリ１９２、およびメモリ１９２に結合したプロセッサ１９０を有する。

傍受するゲートウェイ２２４が、メモリ１９２、およびメモリ１９２に結合したプロセッサ１９０を有するＴＵＲＮサーバ２１６を、傍受するゲートウェイ２２４と統合する。

ＴＵＲＮサーバ２１６を使用するようにＲＴＣ機器２００またはＲＴＣサービス２２８を構成することにより、または封じ込められたネットワークセグメント内のメディアエンドポイントのうちの一方２０２または２０３がＴＵＲＮサーバ２１６を発見することにより、ＲＴＣ機器２００とＴＵＲＮサーバ２１６の間に、およびＴＵＲＮサーバ２１６と第２のメディアエンドポイント２０３の間に、ＲＴＣメディア経路が確立される。

傍受するゲートウェイ２２４を通過するＲＴＣメディアトラフィックを解読するために、第１のメディアエンドポイント２０２により、または第２のメディアエンドポイント２０３により、傍受するゲートウェイ２２４にＲＴＣメディアトラフィックのための解読鍵が運ばれる。

傍受するサーバはまた、典型的にはＮＡＴおよびファイアウォールを通り抜けるようにメディアフローを取り扱うＳＢＣ（セッション・ボーダ・コントローラ）の中に構築することができる。

よりリッチなメディア、改善されたメディア品質、より低いネットワーク負荷、またはより低コストの呼のための直接メディア経路を実現するために、異なるタイプのネットワークセグメント１０４、１０６、１０８間を、ゲートウェイ２２２を有するネットワークを介して接続される、ピア・ツー・ピア・メディア能力を有するエンドポイント２０２、２０３間にメディア経路を確立または再確立するための、本実施形態による方法が、図９に示されている。

ＶｏＩＰサービスは、呼がＬＡＮ（イントラネットタイプのネットワークセグメント）上で、またはインターネット上で、コンピュータクライアントまたはＩＰ電話から開始されるときでさえ、電話通信タイプのネットワークセグメントの中にゲートウェイ機能をほとんどいつも含み、他方のエンドポイントがＶｏＩＰ電話と互換性があるときでさえ、電話通信タイプのネットワークセグメントを伴うので、メディアトラフィックは制限される、またはコストがかかる。ビデオの能力がある最新のプロトコル、たとえば、ＷｅｂＲＴＣおよびＳＩＰ、またはそれらの組み合わせを使えば、電話通信タイプのネットワークセグメントを介してメディア経路を設定するよりはむしろ、互換性のあるエンドポイント間に直接メディア経路を確立するほうが有利である。

リアルタイム通信呼は、今日では同じく大部分の通話も、いくつかのネットワークセグメントおよび相互接続するサーバ２１０、２１２を介してもよい、シグナリングチャネルを介したメッセージを使って２段階処理でエンドポイントを接続し、次に、同じくいくつかのネットワークセグメントおよびサーバを介してもよいメディアチャネル確立が続く。これらの接続のいずれも、少なくとも制限された量のデータをエンドポイント間で送信および受信するために使用することができ、従来の音声電話通信のためのメディア経路がデータ内容を、たとえばＤＴＭＦ数字の形で依然として伝達することができることに注目されたい。

２つのエンドポイントが、互いの間にエンドポイント間の直接メディア経路ではないシグナリングチャネルまたはメディア経路を確立したときに、設定処理を継続して、別の方法でゲートウェイを間に有するいくつかのネットワークセグメントを介したメディア経路であってもよい、ピア・ツー・ピア・メディア経路とも呼ばれる、エンドポイント間の直接メディア経路を確立または再確立することが有利な場合がある。エンドポイントのいずれかが、ピア・ツー・ピア・メディア経路能力を有していることを他方のエンドポイントに示すことができ、エンドポイントのいずれかが、そのような確立または再確立を開始することができる。そのような直接メディア経路は、この状況ではＴＵＲＮサーバを含んでもよく、依然として直接メディア経路であると考えられてもよい。

メディア経路の確立または再確立の開始は、Ｏ／Ａプロトコルを使用することにより、シグナリングチャネルまたはメディア経路を介して信号で伝えられてもよい。しかしながら、メディア経路が音声のためだけのためにある場合、Ｏ／Ａプロトコルは長すぎて、たとえばＤＴＭＦの数字に符号化することができず、その音声チャネルを介して伝達することができない場合がある。そのような場合、Ｏ／Ａプロトコルの圧縮バージョンを使用することができる。あるいは（より望ましい場合がしばしばある）一方のエンドポイントが、自分が接続したのと同じサーバに他方のエンドポイントが接続するように要求することができ、そのサーバを通して、Ｏ／Ａプロトコルを実行することができ、エンドポイント間に直接メディア経路を確立することができる。

この仕組みは、この仕組みのシグナリングが伝達されるサーバ（ウェブサーバ）と連絡を保つＷｅｂＲＴＣブラウザ内に実装することができる。その場合、リクエストは、シグナリングチャネルまたはメディア経路を介して他方のエンドポイントにＨＴＴＰ ＵＲＬの伝達として実装することができ、その後、次の共通サーバ２１０を経由して完全なＯ／Ａプロトコルを信号で伝えることができる。

リアルタイム通信機器（ＲＴＣ機器）２００が、第１のメディアエンドポイント２０２、第２のメディアエンドポイント２０３、および相互接続するサーバ２１２、２１２ｂを備え、ＲＴＣ機器２００、第２のメディアエンドポイント２０３、および相互接続するサーバ２１２、２１２ｂの各々が、メモリ１９２、およびメモリ１９２に結合したプロセッサ１９０を有する。

ＲＴＣ機器２００および第２のメディアエンドポイント２０３が、Ｏ／Ａプロトコル（Ｏｆｆｅｒ ａｎｄ Ａｎｓｗｅｒ ｐｒｏｔｏｃｏｌ）を使用して、異なるタイプのメディアトラフィックのためのメディア経路を確立および再確立することにより、ピア・ツー・ピア・メディア能力を有するように構成される。

ＲＴＣ機器２００および第２のメディアエンドポイント２０３が相互のピア・ツー・ピア・メディア互換性を有するかどうか、または相互接続するサーバ２１２、２１２ｂがＲＴＣ機器２００と第２のメディアエンドポイント２０３の間でＯ／Ａプロトコルを運んでＲＴＣ機器２００と第２のメディアエンドポイント２０３の間に直接メディア経路１４８を確立するかどうかを知ることなく、ＲＴＣ機器２００と第２のメディアエンドポイント２０３の間に呼を設定しようとするときに、以下のステップにより直接メディア経路１４８を確立することができる：

−ＲＴＣ機器２００が、第２のメディアエンドポイント２０３が接続される相互接続するサーバ２１２ｂに至る第１のシグナリングチャネル１５０を確立する。

−ＲＴＣ機器２００が相互のピア・ツー・ピア・メディア互換性の指示を受信し、次いで、直接メディア経路の確立または再確立のために以下の処理のうちの１つを呼び出す。

ＲＴＣ機器２００が、ＲＴＣ機器２００と第２のメディアエンドポイント２０３の間で、エンド・ツー・エンド・シグナリング・チャネル１５２を通して、圧縮されてもよいＯ／Ａプロトコルを使用して、呼のための直接メディア経路１４８の確立を要求する、もしくは

ＲＴＣ機器２００が、ＲＴＣ機器２００と第２のメディアエンドポイント２０３の間の確立された第１のメディア経路１４６を通して、圧縮されてもよいＯ／Ａプロトコルを使用して、呼のための直接メディア経路１４８の確立を要求する、もしくは

ＲＴＣ機器２００が、Ｏ／Ａプロトコルを使用して、呼のための直接メディア経路１４８を確立するために、確立された第１のメディア経路１４６を通して、またはエンド・ツー・エンド・シグナリング・チャネル１５２を通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいＨＴＴＰ ＵＲＬの形であってもよい、呼設定に関する情報、およびＲＴＣ機器２００が接続される相互接続するサーバ２１２のネットワークアドレスに関する情報を送信する。

−または第２のメディアエンドポイント２０３が、相互のピア・ツー・ピア・メディア互換性の指示を受信し、次いで、直接メディア経路の確立または再確立のために以下の処理のうちの１つを呼び出す：

第２のメディアエンドポイント２０３が、ＲＴＣ機器２００と第２のメディアエンドポイント２０３の間で、エンド・ツー・エンド・シグナリング・チャネル１５２を通して、圧縮されてもよいＯ／Ａプロトコルを使用して、呼のための直接メディア経路１４８の確立を要求する、もしくは

第２のメディアエンドポイント２０３が、ＲＴＣ機器２００と第２のメディアエンドポイント２０３の間の確立された第１のメディア経路１４６を通して、圧縮されてもよいＯ／Ａプロトコルを使用して、呼のための直接メディア経路１４８の確立を要求する、もしくは

第２のメディアエンドポイント２０３が、Ｏ／Ａプロトコルを使用して、呼のための直接メディア経路１４８を確立するために、確立された第１のメディア経路１４６を通して、またはエンド・ツー・エンド・シグナリング・チャネル１５２を通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいＨＴＴＰ ＵＲＬの形であってもよい、呼設定に関する情報、および第２のメディアエンドポイント２０３が接続される相互接続するサーバ２１２ｂのネットワークアドレスに関する情報を送信する。

図５、図７、図８、および図９を参照する他の実施形態では、第２のエンドポイント２０３が、他のＲＴＣ機器２００またはゲートウェイ２２２、２２４であってもよい。

他の実施形態が、２つ以上のエンドポイント２０２、２０３、２０３ｂをさらに備えるメディア経路を確立または再確立するための方法を使用して、ネットワークを介して通信するためのシステムであってもよい。

他の実施形態では、ＲＴＣ機器２００に結合したユーザエージェントが、サーバ２１０または相互接続するサーバ２１２、２１２ｂ内に実装される。

図９を参照する他の実施形態が、相互接続するサーバ２１２、２１２ｂが互いの間でＳＩＰプロトコルを使用し、かつＲＴＣ機器２００に結合したＳＩＰユーザエージェントが、相互接続するサーバ２１２、２１２ｂ内に実装されるシステムである。

図６を参照する他の実施形態は、ゲートウェイ２２２の負荷を軽減して通信を可能にするためにあり、（ｉ）メディアエンドポイント２０２、２０３、２０３ｂのための規定されたＯ／Ａプロトコルが、エンドポイント２０８もしくは２０６、またはネットワークセグメント１０４、１０６、もしくは１０８と互換性がないときに、規定されたＯ／Ａプロトコルから逸脱することにより、通信すべきエンドポイントおよびネットワークセグメントと互換性があるＯ／Ａプロトコルをメディアエンドポイント２０２、２０３、２０３ｂ内に実装し、（ｉｉ）メディアエンドポイント２０２、２０３、２０３ｂのための規定されたメディア経路能力が、エンドポイント２０８もしくは２０６、またはネットワークセグメント１０４、１０６、もしくは１０８と互換性がないときに、規定されたメディア経路能力から逸脱することにより、通信すべきエンドポイントおよびネットワークセグメントと互換性があるメディア経路能力をメディアエンドポイント２０２、２０３、２０３ｂ内に実装し、ゲートウェイ２２２の負荷を軽減して通信を可能にする。

他の実施形態では、ネットワークを介して通信するためのシステムが、２つ以上のＲＴＣエンドポイントを含む。

他の実施形態では、システムのクライアント側が、電気通信機器により実装される。

他の実施形態では、セッション・ボーダ・コントローラの一部であってもよい、システムのサーバ側が、電気通信機器により実装される。

他の実施形態では、電気通信のための機器が、プログラムを組み入れ、クライアントにプログラムを送信することができる。

他の実施形態では、電気通信のための機器が、ウェブサーバである。

他の実施形態では、システムのクライアント側またはサーバ側が、ウェブブラウザ内のソフトウェアモジュール、またはスマートホン、タブレット、ラップトップ、またはパーソナルコンピュータもしくはコンピュータサーバのためのアプリケーションとしてのソフトウェアモジュール、またはプログラムを実行するためのプロセッサを備える電気通信機器内のソフトウェアモジュールにより実装される。

他の実施形態では、システムのＲＴＣ機器に結合したユーザエージェントが、サーバ、相互接続するサーバ、またはＲＴＣサーバ内に実装される。

他の実施形態では、相互接続するサーバが、互いの間でＳＩＰプロトコルを使用し、ＲＴＣ機器に結合したＳＩＰユーザエージェントが、相互接続するサーバ内に実装される。

他の実施形態では、サーバまたは相互接続するサーバが、ゲートウェイまたは傍受するゲートウェイと組み合わされる。

図１０Ａおよび図１０Ｂには、一実施形態による、呼をハンドオーバするためにエンドポイント間にメディア経路を確立または再確立するための処理が示されている。 図１０Ａに示す第１の操作１００２では、第１のメディアエンドポイント、第２のメディアエンドポイント、およびサーバを備えるリアルタイム通信機器（ＲＴＣ機器）が提供される。第２の操作１００４では、ネットワークセグメントのアクセスポイントから、複数のアドレスでサーバを到達可能にする。第３の操作１００６では、何らかのネットワーク・アクセス・ポイントに接続されたＲＴＣ機器の少なくとも１つのネットワークインタフェースが、ＲＴＣ機器とサーバの間でメッセージを送信および受信するように配置される。第４の操作１００８では、ＲＴＣ機器および第２のメディアエンドポイントが、Ｏ／Ａプロトコル（Ｏｆｆｅｒ ａｎｄ Ａｎｓｗｅｒ ｐｒｏｔｏｃｏｌ）を使用して、ＲＴＣ機器と第２のメディアエンドポイントの間にメディア経路を確立および再確立することにより、ピア・ツー・ピア・メディア能力を有するように構成される。第５の操作１０１０では、非応答接続を識別し、かつ回復することができるようになるように、ＲＴＣ機器とサーバの間で共有される固有の接続識別情報が作成される。第６の操作１０１２では、ＲＴＣ機器により、ネットワークセグメントのアクセスポイントからサーバに至るアドレスが収集される。図１０Ｂに示す第７の操作１０１４では、ＲＴＣ機器によりサーバのアドレスにメッセージが繰り返し送信され、応答が全く受信されない場合、応答が受信され、かつ応答が受信されたアドレスにメッセージを送信し続けることによりシグナリング接続性が回復するまで、他の収集されたサーバに至るアドレスを試みる。第８の操作１０１６では、呼を受け取ることができるように、またはＯ／Ａプロトコルを使用して、ＲＴＣ機器と第２のメディアエンドポイントの間にメディア経路を確立または再確立することができるように、特定の接続を回復するために、ＲＴＣ機器によりサーバに接続識別情報が提示される。第９の操作１０１８では、ＲＴＣ機器により、メディア経路を再確立する必要性が判断され、メディア経路を再確立する必要がある場合、メディア経路の再確立が開始される。

図１１には、プロキシを使用する一実施形態による、エンドポイント間でＲＴＣトラフィックを傍受するためのメディア経路を確立するための処理が示されている。第１の操作１１０２では、第１のメディアエンドポイント、第２のメディアエンドポイント、ＲＴＣサーバ、および傍受するゲートウェイを備えるリアルタイム通信（ＲＴＣ）機器が提供される。第２の操作１１０４では、ＲＴＣ機器およびメディアサーバにより使用される通信プロトコルのためのプロキシが、傍受するゲートウェイと統合される。第３の操作１１０６では、ＲＴＣ機器とメディアサーバの間に、およびメディアサーバと第２のメディアエンドポイントの間に、ＲＴＣメディア経路が確立される。第４の操作１１０８では、メディアサーバによりＲＴＣメディアトラフィックを解読および伝達するために、プロキシがメッセージを書き換えることにより、傍受のための指紋が配置される。第５の操作１１１０では、ＲＴＣ機器により使用される通信プロトコルのためにプロキシを使用するようにＲＴＣ機器が構成される。

図１２には、ＴＵＲＮサーバを使用する一実施形態による、エンドポイント間でＲＴＣトラフィックを傍受するためのメディア経路を確立するための処理が示されている。第１の操作１２０２では、第１のメディアエンドポイント、第２のメディアエンドポイント、ＲＴＣサーバ、および傍受するゲートウェイを備えるリアルタイム通信機器（ＲＴＣ機器）が提供される。第２の操作１２０４では、ＴＵＲＮサーバが、傍受するゲートウェイと統合される。第３の操作１２０６では、ＲＴＣ機器とＴＵＲＮサーバの間に、およびＴＵＲＮサーバと第２のメディアエンドポイントの間に、ＲＴＣメディア経路が確立される。第４の操作１２０８では、第１のメディアエンドポイント（２０２）により、または第２のメディアエンドポイントにより、ＲＴＣメディアトラフィックのための解読鍵が、傍受するゲートウェイ（２２４）に運ばれる。

図１３には、一実施形態による、エンドポイント間にメディア経路を確立または再確立するための処理が示されている。操作１３０２では、第１のメディアエンドポイント、第２のメディアエンドポイント、および相互接続するサーバを備えるリアルタイム通信機器（ＲＴＣ機器）が提供され、ＲＴＣ機器、第２のメディアエンドポイント、および相互接続するサーバの各々が、メモリ、およびメモリに結合したプロセッサを有する。操作１３０４では、ＲＴＣ機器および第２のメディアエンドポイントが、Ｏ／Ａプロトコル（Ｏｆｆｅｒ ａｎｄ Ａｎｓｗｅｒ ｐｒｏｔｏｃｏｌ）を使用して、異なるタイプのメディアトラフィックのためのメディア経路を確立および再確立することにより、ピア・ツー・ピア・メディア能力を有するように構成される。操作１３０６では、ＲＴＣ機器および第２のメディアエンドポイントが相互のピア・ツー・ピア・メディア互換性を有するかどうか、または相互接続するサーバがＲＴＣ機器と第２のメディアエンドポイントの間でＯ／Ａプロトコルを運んでＲＴＣ機器と第２のメディアエンドポイントの間に直接メディア経路を確立するかどうかを知ることなく、ＲＴＣ機器と第２のメディアエンドポイントの間に呼を設定しようとする。操作１３１０では、ＲＴＣ機器が相互のピア・ツー・ピア・メディア互換性の指示を受信し、次いで、直接メディア経路の確立または再確立のための処理を呼び出す。操作１３１２では、第２のメディアエンドポイントが相互のピア・ツー・ピア・メディア互換性の指示を受信し、次いで、直接メディア経路の確立または再確立のための処理を呼び出す。

実施形態は、データを記憶し、取り出し、および／もしくは出力する、ならびに／または他のコンピュータと通信することができる（限定しない例で）任意のコンピュータなどのコンピューティングハードウェア（コンピューティング装置）および／またはソフトウェア内に実装することができる。実施形態を実装するプログラム／ソフトウェアは、コンピュータ可読記録媒体を備えるコンピュータ可読媒体上に記録されてもよい。実施形態を実装するプログラム／ソフトウェアはまた、伝送通信媒体を介して伝送されてもよい。コンピュータ可読記録媒体の例には、磁気記録装置、光ディスク、光磁気ディスク、および／または半導体メモリ（たとえば、ＲＡＭ、ＲＯＭ、ＦＬＡＳＨなど）が含まれる。磁気記録装置の例には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、および磁気テープ（ＭＴ）が含まれる。光ディスクの例には、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、およびＣＤ−Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷが含まれる。通信媒体の一例には、搬送波信号が含まれる。

さらに、実施形態の一様態によれば、説明した特徴、機能、および／または操作の任意の組み合わせを提供することができる。

実施形態の多くの特徴および利点が詳細な明細書から明らかであり、したがって、添付の特許請求の範囲により、本発明の真の精神および範囲に入る、実施形態のそのような特徴および利点すべてを包含することが意図される。さらに、当業者が数多くの修正形態および変更形態を容易に思いつくので、本発明の実施形態を、例示し、説明したまさにその構成および操作に限定することは望ましくなく、それに応じて、適切な修正形態および均等物すべてが本発明の範囲に入ると訴えられてもよい。

ＷｅｂＲＴＣについて言及しているときに、ＷｅｂＲＴＣはまた、他のリアルタイム通信プロトコル、または一般に通信方法を意味する（またはそれらに適用される）場合がある。

Claims (24)

1. リアルタイム通信（ＲＴＣ）メディアトラフィックを、通信プロトコルを使用してＲＴＣ機器（２００）とＲＴＣサービス（２２８）の間で傍受し、解読するためにエンドポイント間にメディア経路を確立するための方法であって、前記ＲＴＣメディアトラフィックが監視、解析、および記録する目的で指紋を使用して中間者攻撃から、暗号化により、保護される方法であって、
   第１のメディアエンドポイント（２０２）を備えるリアルタイム通信機器（ＲＴＣ機器）（２００）、第２のメディアエンドポイント（２０３）、ＲＴＣサーバ（２１８）、および傍受するゲートウェイ（２２４）を提供するステップであって、前記ＲＴＣ機器（２００）、前記第２のメディアエンドポイント（２０３）、前記ＲＴＣサーバ（２１８）、および前記傍受するゲートウェイ（２２４）の各々が、メモリ（１９２）、および前記メモリ（１９２）に結合したプロセッサ（１９０）に前記方法を実装するソフトウェアを備える、ステップを備え、
   前記ＲＴＣ機器（２００）によって、前記ＲＴＣサービス（２２８）およびメディアサーバ（２１４）により使用される前記通信プロトコルのためのプロキシ（２１１）を前記傍受するゲートウェイ（２２４）と統合するステップであって、前記プロキシ（２１１）および前記メディアサーバ（２１４）の各々が、メモリ（１９２）、および前記メモリ（１９２）に結合したプロセッサ（１９０）に前記方法を実装するソフトウェアを備える、ステップをさらに備え、
   前記プロキシ（２１１）がメッセージ（１６４、１６４ｂ）を書き換えることにより、前記ＲＴＣ機器（２００）と前記メディアサーバ（２１４）の間に、および前記メディアサーバ（２１４）と前記第２のメディアエンドポイント（２０３）の間に、ＲＴＣメディア経路を確立するステップと、
   前記メディアサーバ（２１４）を介した前記ＲＴＣメディアトラフィックの前記傍受、解読、および伝達のために、前記プロキシ（２１１）が前記メッセージ（１６４、１６４ｂ）を書き換えることにより前記指紋を配置するステップと、
   前記ＲＴＣサービス（２２８）により使用される前記通信プロトコルのために前記プロキシ（２１１）を使用するように前記ＲＴＣ機器（２００）を構成するステップと、
   を備えることを特徴とし、
   中間者攻撃から保護するために指紋を使用した電気通信サービス内の傍受するゲートウェイを介して、確立されたメディア経路によって、ＲＴＣメディアトラフィックが傍受され、解読される方法。
2. 前記第２のメディアエンドポイント（２０３）が他のＲＴＣ機器（２００）またはゲートウェイ（２２２、２２４）である、請求項１に記載の方法。
3. ２つ以上のメディアエンドポイント（２０２、２０３、２０３ｂ）をさらに備える、請求項１による前記方法を使用して、ネットワークを介して通信するためのシステム。
4. 請求項３に記載の前記システムのクライアント側であり、前記クライアント側は前記第１のメディアエンドポイント（２０２）または前記第２のメディアエンドポイント（２０３）を実装する電気通信機器。
5. 請求項３に記載の前記システムのサーバ側を実装する電気通信機器であって、前記サーバ側は前記傍受するゲートウェイ（２２４）であり、前記システムのサーバ側がセッション・ボーダ・コントローラ（Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ、ＳＢＣ）の一部である電気通信機器。
6. 請求項３に記載の前記システムのサーバ側を実装する通信装置であって、前記サーバ側は前記傍受するゲートウェイ（２２４）であり、前記電気通信装置は、プログラムを組み込み、前記プログラムをクライアントに送信することができ、前記プログラムは、前記メディアエンドポイントの一部を実装する電気通信機器。
7. 前記プログラムが、前記電気通信機器に組み込まれたウェブサーバ上にある、請求項６に記載の電気通信機器。
8. 請求項３に記載の前記システムのクライアント側またはサーバ側を実装するソフトウェアモジュールであって、前記クライアント側は前記第１のメディアエンドポイント（２０２）または前記第２のメディアエンドポイント（２０３）であり、前記サーバ側は前記傍受するゲートウェイ（２２４）であり、ウェブブラウザ内の、またはスマートホン、タブレット、ラップトップ、またはパーソナルコンピューターもしくはコンピューターサーバのためのアプリケーションとしての、またはプログラムを実行するための、メモリに結合したプロセッサーを備える電気通信機器内にある、ソフトウェアモジュール。
9. メディア経路（１４６）を通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいメッセージ（１６４）をエンドポイントに送信する機能、
   メディア経路（１４６）を通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいメッセージ（１６４）をエンドポイントから受信する機能、
   品質または他の指標が評価される追加の代替メディア経路を確立し、その後、前記ＲＴＣメディアトラフィックのために前記代替メディア経路を使用する機能、
   セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）を使用してリアルタイムに通信する機能、
   ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）プロトコルを使用してリアルタイムに通信する機能、
   ＩＣＥ（Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔ）を使用してエンドポイント間にメディア経路を確立する機能、
   ＳＴＵＮ（Ｓｅｓｓｉｏｎ Ｔｒａｖｅｒｓａｌ Ｕｔｉｌｉｔｉｅｓ ｆｏｒ ＮＡＴ）プロトコルを使用してメディア経路を確立する機能、
   ＴＵＲＮ（Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙｓ ａｒｏｕｎｄ ＮＡＴ）プロトコルを使用してメディア経路を確立する機能、
   エンドポイントまたはネットワークセグメントが相互のピア・ツー・ピア・メディア互換性を有するかどうかの、自己学習処理から得られる知識を記憶する機能、
   時間が制限されてもよく、かつＷｅｂＲＴＣサーバ内に記憶されることができ、かつＷｅｂＲＴＣブラウザクライアントに短縮した形で送信されるＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬクリック・ツー・コール・リンクを生成する機能、
   時間が制限されてもよく、かつＷｅｂＲＴＣサーバ内に記憶され、かつＷｅｂＲＴＣブラウザユーザから短縮した形で受信されるＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬリンクを実行する機能、
   他の方法では利用できない場合があるＷｅｂＲＴＣ機能を呼び出すためのＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬリンク内の特定のドメイン名拡張を、たとえば、ｗｒｔｃ．ｃｏｍｐａｎｙ．ｃｏｍ内のｗｒｔｃを識別する機能、
   ＲＴＣクライアントのためのグラフィカル・ユーザ・インタフェースで呼状態に基づき連絡先をリストの形で整理する機能、
   移動体アプリケーションで使用される、小さな３つのバーティカルドット記号またはメニューライン記号によりＲＴＣクライアントのためのグラフィカル・ユーザ・インタフェースで単一連絡先のための拡張可能な動作メニューを表す機能、
   プッシュ通知により着信呼を受け取るために、スマートホンまたは他の移動体機器のスリープ状態を解除する機能、
   構内交換機（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ、ＰＢＸ）の機能を統合する機能、
   セッション・ボーダ・コントローラ（ＳＢＣ）の機能を統合する機能、
   ユニファイド通信（Ｕｎｉｆｉｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＵＣ）のソリューション機能を統合する機能、
   ＳＩＰゲートウェイ機能にＷｅｂＲＴＣを統合する機能、
   コールセンタまたはコンタクトセンタの機能を統合する機能、
   状況依存のクリック・ツー・コール・リンクを生成する機能、
   状況依存のクリック・ツー・コール・リンクを実行する機能、
   ＷｅｂＲＴＣブラウザをクライアントとして使用してコールエージェントを接続する機能、および、
   インスタントメッセージング（Ｉｎｓｔａｎｔ ｍｅｓｓａｇｉｎｇ、ＩＭ）、プレゼンス、画面共有、およびグループ呼出の機能を提供する機能、
   からなるグループから選択される機能を遂行するプログラムを備える、請求項８に記載のソフトウェアモジュール。
10. 前記ＲＴＣ機器（２００）に結合したユーザエージェントが、前記サーバ（２１０）、前記相互接続するサーバ（２１２、２１２ｂ）、または前記ＲＴＣサーバ（２２８）内に実装される、請求項３に記載のシステム。
11. 前記相互接続するサーバ（２１２、２１２ｂ）が、互いの間で前記ＳＩＰプロトコルを使用し、前記ＲＴＣ機器（２００）に結合したＳＩＰユーザエージェントが、前記相互接続するサーバ（２１２、２１２ｂ）内に実装される、請求項１０に記載のシステム。
12. サーバ（２１０）または相互接続するサーバ（２１２）は、ゲートウェイ（２２２）または傍受するゲートウェイ（２２４）と組み合わされる、請求項３に記載のシステム。
13. リアルタイム通信（ＲＴＣ）メディアトラフィックを、ＴＵＲＮプロトコルを使用してリアルタイム通信機器（ＲＴＣ機器）（２００）とＲＴＣサービス（２２８）の間で傍受し、解読するためにエンドポイント間にメディア経路を確立するための方法であって、前記ＲＴＣメディアトラフィックが監視、解析、および記録する目的で指紋を使用して中間者攻撃から、暗号化により、保護される方法であって、
    第１のメディアエンドポイント（２０２）を備える前記ＲＴＣ機器（２００）、第２のメディアエンドポイント（２０３）、ＲＴＣサーバ（２１８）、および傍受するゲートウェイ（２２４）を提供するステップであって、前記ＲＴＣ機器（２００）、前記第２のメディアエンドポイント（２０３）、前記ＲＴＣサーバ（２１８）、および前記傍受するゲートウェイ（２２４）の各々が、メモリ（１９２）、および前記メモリ（１９２）に結合したプロセッサ（１９０）に前記方法を実装するソフトウェアを備える、ステップを備え、
    メモリ（１９２）、および前記メモリ（１９２）に結合したプロセッサ（１９０）に前記方法を実装するソフトウェアを備えるＴＵＲＮサーバ（２１６）を前記傍受するゲートウェイ（２２４）と統合するステップをさらに備え、
    前記ＲＴＣ機器（２００）が、前記ＴＵＲＮサーバ（２１６）を使用するように前記ＲＴＣ機器（２００）または前記ＲＴＣサービス（２２８）を構成することにより、または封じ込められたネットワークセグメント内で前記メディアエンドポイント（２０２または２０３）のうちの一方が前記ＴＵＲＮサーバ（２１６）を発見することにより、前記ＲＴＣ機器（２００）と前記ＴＵＲＮサーバ（２１６）の間に、および前記ＴＵＲＮサーバ（２１６）と前記第２のメディアエンドポイント（２０３）の間に、ＲＴＣメディア経路を確立するステップと、
    前記傍受するゲートウェイ（２２４）を通過する前記ＲＴＣメディアトラフィックを解読するために、前記第１のメディアエンドポイント（２０２）により、または前記第２のメディアエンドポイント（２０３）により、前記傍受するゲートウェイ（２２４）に前記ＲＴＣメディアトラフィックのための解読鍵を運ぶステップと、
    を備えることを特徴とし、
    中間者攻撃から保護するために指紋を使用した電気通信サービス内の傍受するゲートウェイを介して、確立されたメディア経路によって、ＲＴＣメディアトラフィックが傍受され、解読される方法。
14. 前記第２のメディアエンドポイント（２０３）は、他のＲＴＣ機器（２００）またはゲートウェイ（２２２、２２４）である、請求項１３に記載の方法。
15. ２つ以上のメディアエンドポイント（２０２、２０３、２０３）をさらに備える、請求項１３に記載の方法を使用してネットワークを介して通信するためのシステム。
16. 請求項１５に記載の前記システムのクライアント側であり、前記クライアント側は前記第１のメディアエンドポイント（２０２）または前記第２のメディアエンドポイント（２０３）を実装する電気通信機器。
17. 請求項１５に記載の前記システムのサーバ側を実装する電気通信機器であって、前記サーバ側は前記傍受するゲートウェイ（２２４）であり、前記システムのサーバ側がセッション・ボーダ・コントローラ（Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ、ＳＢＣ）の一部である電気通信機器。
18. 請求項１５に記載の前記システムのサーバ側を実装する通信装置であって、前記サーバ側は前記傍受するゲートウェイ（２２４）であり、前記電気通信装置は、プログラムを組み込み、前記プログラムをクライアントに送信することができ、前記プログラムは、前記メディアエンドポイントの一部を実装する電気通信機器。
19. 前記プログラムが、前記電気通信機器に組み込まれたウェブサーバ上にある、請求項１８に記載の電気通信機器。
20. 請求項１５に記載のシステムのクライアント側またはサーバ側を実装するソフトウェアモジュールであって、前記クライアント側は前記第１のメディアエンドポイント（２０２）または前記第２のメディアエンドポイント（２０３）であり、前記サーバ側は前記傍受するゲートウェイ（２２４）であり、ウェブブラウザ内の、またはスマートホン、タブレット、ラップトップ、またはパーソナルコンピューターもしくはコンピューターサーバのためのアプリケーションとしての、またはプログラムを実行するための、メモリに結合したプロセッサーを備える電気通信機器内にある、ソフトウェアモジュール。
21. メディア経路（１４６）を通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいメッセージ（１６４）をエンドポイントに送信する機能、
    メディア経路（１４６）を通して、短縮されても、圧縮されても、時間が制限されても、またはＤＴＭＦ符号化されてもよいメッセージ（１６４）をエンドポイントから受信する機能、
    品質または他の指標が評価される追加の代替メディア経路を確立し、その後、前記ＲＴＣメディアトラフィックのために前記代替メディア経路を使用する機能、
    セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）を使用してリアルタイムに通信する機能、
    ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）プロトコルを使用してリアルタイムに通信する機能、
    ＩＣＥ（Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔ）を使用してエンドポイント間にメディア経路を確立する機能、
    ＳＴＵＮ（Ｓｅｓｓｉｏｎ Ｔｒａｖｅｒｓａｌ Ｕｔｉｌｉｔｉｅｓ ｆｏｒ ＮＡＴ）プロトコルを使用してメディア経路を確立する機能、
    ＴＵＲＮ（Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙｓ ａｒｏｕｎｄ ＮＡＴ）プロトコルを使用してメディア経路を確立する機能、
    エンドポイントまたはネットワークセグメントが相互のピア・ツー・ピア・メディア互換性を有するかどうかの、自己学習処理から得られる知識を記憶する機能、
    時間が制限されてもよく、かつＷｅｂＲＴＣサーバ内に記憶されることができ、かつＷｅｂＲＴＣブラウザクライアントに短縮した形で送信されるＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬクリック・ツー・コール・リンクを生成する機能、
    時間が制限されてもよく、かつＷｅｂＲＴＣサーバ内に記憶され、かつＷｅｂＲＴＣブラウザユーザから短縮した形で受信されるＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬリンクを実行する機能、
    他の方法では利用できない場合があるＷｅｂＲＴＣ機能を呼び出すためのＷｅｂＲＴＣ ＨＴＴＰ ＵＲＬリンク内の特定のドメイン名拡張を、たとえば、ｗｒｔｃ．ｃｏｍｐａｎｙ．ｃｏｍ内のｗｒｔｃを識別する機能、
    ＲＴＣクライアントのためのグラフィカル・ユーザ・インタフェースで呼状態に基づき連絡先をリストの形で整理する機能、
    移動体アプリケーションで使用される、小さな３つのバーティカルドット記号またはメニューライン記号によりＲＴＣクライアントのためのグラフィカル・ユーザ・インタフェースで単一連絡先のための拡張可能な動作メニューを表す機能、
    プッシュ通知により着信呼を受け取るために、スマートホンまたは他の移動体機器のスリープ状態を解除する機能、
    構内交換機（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ、ＰＢＸ）の機能を統合する機能、
    セッション・ボーダ・コントローラ（ＳＢＣ）の機能を統合する機能、
    ユニファイド通信（Ｕｎｉｆｉｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＵＣ）のソリューション機能を統合する機能、
    ＳＩＰゲートウェイ機能にＷｅｂＲＴＣを統合する機能、
    コールセンタまたはコンタクトセンタの機能を統合する機能、
    状況依存のクリック・ツー・コール・リンクを生成する機能、
    状況依存のクリック・ツー・コール・リンクを実行する機能、
    ＷｅｂＲＴＣブラウザをクライアントとして使用してコールエージェントを接続する機能、および、
    インスタントメッセージング（Ｉｎｓｔａｎｔ ｍｅｓｓａｇｉｎｇ、ＩＭ）、プレゼンス、画面共有、およびグループ呼出の機能を提供する機能、
    からなるグループから選択される機能を遂行するプログラムを備える、請求項２０に記載のソフトウェアモジュール。
22. 前記ＲＴＣ機器（２００）に結合したユーザエージェントが、前記サーバ（２１０）、前記相互接続するサーバ（２１２、２１２ｂ）、または前記ＲＴＣサーバ（２２８）内に実装される、請求項１３に記載の方法。
23. 前記相互接続するサーバ（２１２、２１２ｂ）が、互いの間で前記ＳＩＰプロトコルを使用し、前記ＲＴＣ機器（２００）に結合したＳＩＰユーザエージェントが、前記相互接続するサーバ（２１２、２１２ｂ）内に実装される、請求項２２に記載の方法。
24. 前記サーバ（２１０）または相互接続するサーバ（２１２）は、ゲートウェイ（２２２）または傍受するゲートウェイ（２２４）と組み合わされる、請求項１３に記載の方法。