JP2010035169A - 第三者の装置による呼の確立および制御 - Google Patents

Abstract

【課題】第三者の通信要素（Ｃ）によるイベント（Ｓ）の受信によってトリガされる２つの通信エージェント（Ａ、Ｂ）の間の通信セッション（ＳＭ）を確立する方法。
【解決手段】このイベントの受信後に、第三者の要素は、２つのエージェントのうちの第２のエージェント（Ｂ）に宛てられた、かつ第三者の要素（Ｃ）を介して伝送するように意図された招待メッセージ（Ｍ_２）を２つのエージェントのうちの第１のエージェント（Ａ）に送信させるように構成されたシグナリング・メッセージ（Ｍ_１）を、２つのエージェントのうちの第１のエージェント（Ａ）に送信することを特徴とする。
【選択図】図１

Description

本発明は、第３の通信ネットワーク装置による、２つの通信装置間の呼の確立および確立された呼の制御に関する。

そのような課題は、専門家には頭文字の３ＰＣＣ（Third-party Call Control：第三者呼制御）で知られている。図１には、ネットワーク装置Ｃが２つの他の装置ＡおよびＢの間の通信セッション（または呼）の確立をトリガしようとしているところが示されている。このトリガは、それ自体、ネットワーク装置Ｃが受信した刺激によって引き起こされていることがあり、ネットワーク装置Ｃは種類が異なることがある。

現代の通信ネットワークでは、通信セッション（マルチメディアまたはそれ以外）は、特にＳＩＰプロトコルに準拠したシグナリング・メッセージを交換することによって確立される。このプロトコルは、「Session Initiation Protocol」という名称のＩＥＴＦのＲＦＣ３２６１によって規定されている。

ＳＩＰプロトコルを使用して通信ネットワーク上に第三者呼制御（３ＰＣＣ）を実装することは専門家に知られている。

米国特許願第２００６／０２００３６号は、そのような呼制御（３ＰＣＣ）を提示している。しかしながら、これは、かなり基本的なものであり、呼をトリガすることしかできない。通信が確立された後、イニシエータは呼を制御することができず、もはや呼を変更することも終了させることもできない。イニシエータは、通信状況の情報を得ること（言い換えれば、通信がいつ終了するのか、その持続時間などの通知を受けること）もできない。

この解決策はまた、ＲＦＣ３７２５によって定義された第三者呼制御にもはや対応しない。

このＩＥＴＦのＲＦＣ３７２５は「Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)」という名称である。これには、大きな欠点を有するいくつかの解決策、および推奨される解決策が記載されている。

しかしながら、この推奨される解決策も著しい欠点を有する。

まず第１に、文書ＲＦＣ３７２５それ自体は、その推奨される解決策が、発呼が有効に行われる前に発呼側端末Ａのユーザが長い無音を聞くという状況を生じる欠点を有することを認めている。

保留音楽または情報メッセージを再生するアナウンスメント・サーバを実装することによって、この欠点を打ち消すことが可能である。しかしながら、この解決策は、追加の装置の展開を必要とし、呼の確立プロセスをより複雑にする。

さらに、ＲＦＣ３７２５が推奨する解決策では、装置ＣがＳＩＰプロトコル用のＢ２ＢＵＡ（Back-to-Back User Agent）として動作する必要がある。そのようなＢ２ＢＵＡの欠点は、ＲＦＣ３２６１およびＩＥＴＦの様々な著作によってあまり十分に規定されていないことである。したがって、簡単な事例以外のもののために展開される前に、かなりの規定および開発作業が必要となる。

ＲＦＣ３７２５は簡単な動作シナリオしか提示していないが、より一般的なシナリオは、いくつかの他の状況、たとえば、被呼ユーザがいくつかの端末を有する場合、またはセッションが通信ネットワークの他のサービスと対話しなければならない場合、またはサービス品質に関して保証を与えるためにＲＦＣ３２６２に記載されている拡張機能（言い換えれば「ＰＲＡＣＫ」メッセージ）を使用して呼を確立する必要がある３ＧＰＰおよびＴＩＳＰＡＮ団体によって規定されている標準ＩＭＳ（ＩＰマルチメディア・サブシステム）アーキテクチャに準拠した実装に関して、装置Ｃの挙動の規定を必要とする。考慮すべき他の状況には、媒体の再交渉、取消し、矛盾した状況（発呼側が取消しメッセージを送信し、被呼側が再交渉メッセージを送信したときにどの挙動を採用するか）が含まれる。

これらすべての場合において、再送の可能性、エラー・シナリオなどを伴う装置Ｃ内のＳＩＰプロトコルを管理する状態機械の規定作業は極めて複雑であり、実際に、解決策を使用するのを困難にする。

さらに、Ｂ２ＢＵＡタイプの装置では、管理されるマルチメディア・セッション間の相互作用を管理するためにコンテキスト情報を維持する必要がある。これは、このコンテキスト情報をメモリに記憶する問題をもたらす。第１に、大きいボリュームが典型であり、かなりの記憶容量が必要になることがあり、第２に、装置Ｃの起こりうる故障を解決するためにこのコンテキスト情報を確保するための機構を提供することが重要である。

最後に、ＲＦＣによって推奨される解決策は「何も提供しない」（言い換えれば、マルチメディア・セッションを確立するいかなる手段をも提供しない）ＳＩＰ招待メッセージに基づいている。しかしながら、これらのメッセージは必ずしも通信デバイスによって正しくサポートされるわけではない。したがって、提案された解決策はインターオペラビリティの問題をもたらすおそれがある。

これらのすべての理由で、ＲＦＣ３７２５によって規定された解決策は満足なものではない。

別の現況技術は、「3pcc using the REFER method」という名称の文書「draft-bhatia-3pcc-refer-01.txt」から構成されている。

この解決策によれば、コントローラ装置Ｃは、エージェントＡに「ＲＥＦＥＲ」タイプのシグナリング・メッセージＭ_１を送信する。このシグナリング・メッセージは、コントローラ装置Ｃのアドレスを示す「ｒｅｆｅｒ−ｔｏ」ヘッダを含む。「ＲＥＦＥＲ」メッセージを規定するＲＦＣ３５１５によれば、受信したとき、エージェントＡは、コントローラＣに招待メッセージＭ_２（「ＩＮＶＩＴＥ」）を送信し、コントローラＣは、それをエージェントＢに転送することができる（メッセージＭ_３）。

それにもかかわらず、この解決策はかなりの欠点を有する。

このドキュメントの段落４．０に示されるように、コントローラＣは招待メッセージＭ_２がメッセージＭ_１への応答であることを決定することができるように、「ｒｅｐｌａｃｅ」パラメータを挿入しなければならない。しかしながら、通信エージェントによるこのパラメータに対するサポートは比較的少なく、したがって、パラメータの使用はインターオペラビリティの問題をもたらすおそれがある。

また、コントローラＣは、セッションが予め確立されていない場合に、エージェントＢへの招待メッセージＭ_２の再送を管理することができるようにコンテキストを生成しなければならない。このコンテキストは「ｒｅｐｌａｃｅ」パラメータによって指定されている。したがって、この解決策は、上述した問題と同様の、コンテキストをメモリに記憶することに関する問題を生じる。

最後に、招待メッセージＭ_１の送信およびこの２つの呼の収束を管理するために特定の処理を実装しなければならないので、コントローラＣは、この解決策では、Ｂ２ＢＵＡとして動作する。

米国特許願第２００６／０２００３６号

ＩＥＴＦ ＲＦＣ３２６１、「Session Initiation Protocol」 ＩＥＴＦ ＲＦＣ３７２５、「Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)」 ＲＦＣ３２６２ 「3pcc using the REFER method」、draft-bhatia-3pcc-refer-01.txt ＲＦＣ３５１５

したがって、本発明は、これらの様々な問題を解決することを目的とする。

本発明の第１の目的は、第三者の通信要素によるイベントの受信によってトリガされる２つの通信エージェントの間の通信セッションを確立する方法である。このイベントの受信後に、第三者の要素が、２つのエージェントのうちの第２のエージェント（Ｂ）に宛てられた、かつ第三者の要素（Ｃ）を介して伝送するように意図された招待メッセージを前記エージェントのうちの第１のエージェントに送信させるように構成されたシグナリング・メッセージを、前記エージェントのうちの第１のエージェントに送信するという点で、この方法は革新的である。

本発明の一実施形態によれば、シグナリング・メッセージは、エージェントのうちの第２のエージェントを招待メッセージの受信者として識別する第１の情報項目と、第三者の要素を招待メッセージのルートの要素として識別する第２の情報項目とを含む、ＳＩＰプロトコルに準拠した「ＲＥＦＥＲ」メッセージとすることができる。

第１の情報項目はシグナリング・メッセージの「ｒｅｆｅｒ−ｔｏ」ヘッダに含めることができる。

第２の情報項目も、「ｒｅｆｅｒ−ｔｏ」ヘッダに含め、エスケープ記号によって第１の情報項目と区別することができ、第三者の要素は、第２のエージェントに招待メッセージを送信するために、ヘッダから第１の情報項目を決定する。この場合、第１の情報項目を決定するために、第三者の要素が、「＠」記号で始まる「ｒｅｆｅｒ−ｔｏ」ヘッダのコンテンツを削除し、このエスケープ記号を「＠」記号と置き換えることができる。

本発明の別の実装形態によれば、第２の情報項目はシグナリング・メッセージの「ｒｅｆｅｒ−ｒｏｕｔｅ」ヘッダに含めることができる。

本発明の別の実装形態によれば、第２の情報項目は前記「ｒｅｆｅｒ−ｔｏ」ヘッダのパラメータとして含めることができる。

第三者の通信要素は、前記イベントの発信元である装置に戻り情報を送信することができる。

通信エージェントの１つは、コンテンツ・サーバ、特にアナウンスメント・サーバの場合がある。

本発明はまた、第三者の通信要素が、イベントを受信したとき、２つの通信エージェントの間の通信セッションを確立することを目的としている。この第三者の通信要素は、第２のエージェントに宛てられた、かつ前記第三者の要素を介して伝送するように意図された招待メッセージを第１のエージェントに送信させるように構成されたシグナリング・メッセージを、第１のエージェントに送信するように意図されたことを特徴とする。

本発明の第３の目的は、第２の目的による少なくとも１つの第三者の通信要素を備える通信ネットワークである。

エージェントＢに宛てられた、かつコントローラＣを介して伝送するように意図された招待メッセージをエージェントＡに送信させることによって、本発明は、現況技術の解決策の欠点を生じることなしに３ｐｃｃセッションを確立し、制御する技術的課題を解決する。

実際に、そのようなメッセージは、コンテキストをメモリに記憶する必要なしに、コントローラＣによってエージェントＢに自動的に送信される。そのようなメッセージは、ＲＦＣ３２６１によって定義された「プロキシ」の挙動に従って動作する。したがって、そのような解決策を使用して、コンテキスト情報のメモリへの記憶に関連する問題とＢ２ＢＵＡタイプの装置の実装の問題の両方を克服する。

いわゆる「ステートフル」プロキシ、言い換えればコンテキスト情報をメモリに記憶するプロキシを使用することを選択してもよいが、その場合、この情報はＳＩＰダイアログの要素のみを含み、Ｂ２ＢＵＡタイプの装置のものなど複雑な状態機械は含まない。

本発明およびその恩恵は、添付の各図を参照しながら以下の説明を読めばよりはっきり明らかになろう。

前述のように現況技術の図である。 本発明による方法を実装する通信ネットワークの図である。

第三者の要素による２つのエージェントの間の通信セッションの確立は、この第三者の要素上で受信された様々なイベントまたは刺激によってトリガできる。２つの例を図２に示す。

ウェブ・サーバＷはユーザにインターフェースを与えることができる。このマンマシン・インターフェースと対話することによって、ユーザは刺激Ｓが第三者の要素Ｃに送信されるようにすることができる。

たとえば、サーバＷは、通信者（会社、個人など）に関する情報を表示し、ユーザが所与のリンクをクリックすることによって、この刺激（またはイベント）の送信をトリガして、最終的にユーザの通信端末と通信者の通信端末との間のマルチメディア通信セッションを確立することができる。

したがって、このイベントはＨＴＴＰプロトコルに準拠したメッセージでもよい。

イベントＳは、「ＳＩＰプロキシ」、ＩＭＳ（「ＩＰマルチメディア・システム」）アーキテクチャに準拠したＣＳＣＦタイプの機能要素など、シグナリング要素ＳＥによって送信されるＳＩＰシグナリング・メッセージでもよい。

イベントＳは、ウェブ・サービスから生じ、ＳＯＡＰプロトコルに準拠したものでもよい。

このイベントまたは刺激Ｓは、確立すべきマルチメディア・セッションＳＭのパラメータを決定するためにシグナリング要素ＳＥが必要とする情報を含む。特に、この情報は、マルチメディア・セッションＳＭがその間で確立されなければならない２つのエージェントＡおよびＢを識別しなければならない。

このイベントＳの受信後に、第三者の要素Ｃは、マルチメディア・セッションＳＭのイニシエータと考えられるエージェントにシグナリング・メッセージＭ_１を送信する。このエージェントは刺激Ｓのコンテンツによって決定できる。図２の例では、この開始側エージェントはエージェントＡである。

このエージェントは、ＩＥＴＦのＲＦＣ３２６１の用語によれば、ＵＡＣエージェントまたはＵＡＳエージェント（それぞれ「ユーザ・エージェント・クライアント」および「ユーザ・エージェント・サーバ」）である。エージェントは、様々なタイプの通信端末（固定または携帯電話、コンピュータ、携帯情報端末など）またはユーザと対話することができるまたは対話することができない他のタイプの装置を含むことができる。

エージェントは、たとえば、アプリケーション・サーバまたはアナウンスメント・サーバなどのコンテンツ・サーバを含むことができる。

シグナリング・メッセージＭ_１は、様々な方法で実装できる。このシグナリング・メッセージは、特に、ＳＩＰプロトコルに準拠した「ＲＥＦＥＲ」シグナリング・メッセージを含むことができる。そのような「ＲＥＦＥＲ」メッセージは、ＩＥＴＦのＲＦＣ３５１５によって規定されており、「ＩＮＶＩＴＥ」招待メッセージの送信を受信側でトリガすることによって通信セッション中の呼の転送を可能にする目的を有する。

本発明のこの実施形態によれば、このメッセージは、エージェントＢを招待メッセージＭ_２の受信者として識別する第１の情報項目と、第三者の要素Ｃを、招待メッセージＭ_２がそれを介して送信されなければならないルートの要素として識別する第２の情報項目とを含む。

一般に、第１の情報項目は、エージェントＢの物理アドレスまたは論理アドレスでよく、シグナリング・メッセージＭ_１の、「ｒｅｆｅｒ−ｔｏ」ヘッダに含まれる。

ＲＦＣ３５１５によれば、招待メッセージＭ_２を作成するために、「ｒｅｆｅｒ−ｔｏ」ヘッダがシグナリング・メッセージＭ_１の受信側であるエージェントＡによって自動的に使用される。より具体的には、「ｒｅｆｅｒ−ｔｏ」ヘッダに含まれるアドレスは、招待メッセージＭ_２の「Ｔｏ」ヘッダを作成するために使用される。

第２の情報項目により、招待メッセージＭ_２は、そのルート内に第三者の要素Ｃを有しなければならない。そのような制約の目的は、シグナリング・メッセージＭ_１から生じるエージェントＡとエージェントＢとの間のすべてのシグナリング・トラフィックがこの第三者の要素に通知されるようにすることである。このトラフィックは、「２００ Ｏｋ」、「Ａｃｋ」、「Ｒｉｎｇｉｎｇ」タイプのメッセージ、エラー・メッセージ、終了メッセージ（「Ｂｙｅ」）などを含む。

これは、刺激Ｓの発生元である装置ＷＳ、ＳＥ、Ｗに戻り情報Ｆを送信するために必要な場合がある。

この情報は、たとえば「確立」、「進行中」、「応答なし」など、呼持続時間など、通信状況をマンマシン・インターフェース上に表示するために使用できる。

これはまた、第三者の装置Ｃが通信を制御できるようにするため、特に通信を中断できるようにするために必要である可能性がある。被呼エージェントがコンテンツ・サーバである場合、制御は、再招待メッセージの送信およびセッションの構成の変更（たとえばビデオ解像度の変更など）を含むことができる。

第三者の要素を識別する第２の情報項目は、様々な方法でシグナリング・メッセージＭ_１に含めることができる。

第１の実施形態によれば、第２の情報項目は「ｒｅｆｅｒ−ｒｏｕｔｅ」ヘッダに含まれる。

本発明によれば、この「ｒｅｆｅｒ−ｒｏｕｔｅ」ヘッダは、シグナリング・メッセージＭ_２の「ｒｏｕｔｅ」ヘッダを作成するために、エージェントＢによって自動的に使用される。「ｒｅｆｅｒ−ｒｏｕｔｅ」名は任意であり、本発明は、上述した「ｒｅｆｅｒ−ｒｏｕｔｅ」ヘッダの目的をもつ任意のタイプの新たなヘッダに関することに留意されたい。

第２の情報項目は第三者の装置Ｃの（論理または物理）アドレスを含むので、招待メッセージＭ_２の「ｒｏｕｔｅ」ヘッダは、招待メッセージがこの装置を介して伝送されなければならないようにする。

ＳＩＰプロトコルの通常の挙動に従って、「ｒｏｕｔｅ」ヘッダは、エージェントＢによって送信される後続のメッセージによって自動的に再利用され、それにより２つのエージェントＡおよびＢとの間のすべてのトラフィックが第三者の要素Ｃを介して自動的に通過する。

本発明の別の実施形態では、第２の情報項目を「ｒｅｆｅｒ−ｔｏ」ヘッダに含めるが、エスケープ記号を使用することによって第２の情報項目を第１の情報項目と区別し、それによって招待メッセージＭ_２が直接第三者の要素Ｃに送信される。

エスケープ記号は、たとえば「％」などの単一の記号でよい。制約は、このエスケープ記号が論理または物理アドレス内にあってはならないこと、および「ｒｅｆｅｒ−ｔｏ」ヘッダのコンテンツ全体が文法的に正しく、招待メッセージＭ_２が第三者の要素に有効に送信されるように構成されなければならないことのみである。

その場合「ｒｅｆｅｒ−ｔｏ」ヘッダは次の形式をとることができる。

Ｒｅｆｅｒ−ｔｏ： ＜ｓｉｐ：ｂ％ｄｂ．ｃｏｍ＠ｄｃ．ｃｏｍ＞

このヘッダは、エージェントＡによって送信されるシグナリング・メッセージＭ_２の「Ｔｏ」ヘッダに自動的にコピーされる。通信ネットワークは、このヘッダを解釈して、ドメイン「ｄｃ．ｃｏｍ」に対応する要素に周知の方法で送信する。メッセージは最終的に第三者の要素Ｃに送信される。

この第三者の要素は、アドレスｓｉｐ：ｂ％ｄｂ．ｃｏｍ＠ｄｃ．ｃｏｍを分析するように構成される。この要素は、記号「＠」で始まる文字列を削除し、エスケープ記号をこの「＠」記号で置き換える。その結果、アドレスｓｉｐ：ｂ＠ｄｂ．ｃｏｍになり、そこにシグナリング・メッセージＭ_２を送信しなければならない。したがって、このメッセージはエージェントＢで終了する。したがって、第三者の装置Ｃによって適用される処理は、いかなるコンテキスト情報をも必要としない。したがって、装置Ｃは、いわゆる「ステートレス」プロキシになる。

第３の実施形態では、第２の情報項目を「ｒｅｆｅｒ−ｔｏ」ヘッダのパラメータとして含める。したがって、第２の情報項目は、予め指定されたキーワードによって導入できる。このキーワードは任意であり、「ｒｏｕｔｅ＝」とすることができる。

したがって、シグナリング・メッセージＭ_１に含まれる「ｒｅｆｅｒ−ｔｏ」ヘッダは、次の形式をとることができる。

Ｒｅｆｅｒ−ｔｏ： ＜ｓｉｐ：ｂ＠ｄｍ．ｃｏｍ；ｒｏｕｔｅ＝ｃ＠ｄｃ．ｃｏｍ＞

このヘッダは、アドレスｓｉｐ：ｂ＠ｄｍ．ｃｏｍを「Ｔｏ」ヘッダにコピーし、パラメータ「ｃ＠ｄｃ．ｃｏｍ」を「ｒｏｕｔｅ」ヘッダにコピーすることによってシグナリング・メッセージＭ_２を作成するためにエージェントＡによって自動的に使用される。このようにして、招待メッセージＭ_２はまた、エージェントＢおよびそのルート内の第三者の要素Ｃに送信される。

シグナリング・メッセージＭ_２を受信したとき、エージェントＢは、ＲＦＣ３２６１およびＲＦＣ３５１５によって規定された挙動に従って動作することができる。特に、招待メッセージＭ_２内で送信されるルート情報に従うことで、エージェントＡおよびＢとの間のすべてのシグナリング・トラフィックが第三者の要素Ｃを介して伝送されることになる。

マルチメディア・セッションＳＭも、この２つのエージェントとの間で確立できる。

第三者の要素は、ＲＦＣ３２６１によって規定されているように、これらのやりとりにおいてプロキシとして動作する。特に、ＲＦＣ３２６１によって規定されていること以外、送信メッセージに対して処理は実施されず、これらのメッセージを送信するためにコンテキスト情報は必要とされない。

したがって、本発明に記載の方法には、Ｂ２ＢＵＡタイプの装置とメモリへのコンテキスト・データの記憶とに基づく、現況技術の解決策の欠点がない。

これは、刺激またはイベントＳのソース装置にマルチメディア・セッションの状況に関する戻り情報Ｆを送信するために使用される。

Claims (19)

1. 第三者の通信要素（Ｃ）によるイベント（Ｓ）の受信によってトリガされる２つの通信エージェント（Ａ、Ｂ）の間の通信セッション（ＳＭ）を確立する方法であって、前記受信後に、前記第三者の要素が、前記第２のエージェント（Ｂ）に宛てられた、かつ前記第三者の要素（Ｃ）を介して伝送するように意図された招待メッセージ（Ｍ_２）を前記第１のエージェント（Ａ）に送信させるように構成されたシグナリング・メッセージ（Ｍ_１）を、前記第１のエージェント（Ａ）に送信することを特徴とする方法。
2. 前記シグナリング・メッセージが、前記第２のエージェントを前記招待メッセージの受信者として識別する第１の情報項目と、前記第三者の要素を前記招待メッセージのルートの要素として識別する第２の情報項目とを含む、ＳＩＰプロトコルに準拠した「ＲＥＦＥＲ」メッセージである、請求項１に記載の通信セッションを確立する方法。
3. 前記第１の情報項目が、前記シグナリング・メッセージの「ｒｅｆｅｒ−ｔｏ」ヘッダに含まれる、請求項２に記載の通信セッションを確立する方法。
4. 前記第２の情報項目も、前記「ｒｅｆｅｒ−ｔｏ」ヘッダに含まれ、エスケープ記号によって前記第１の情報項目と区別され、前記第三者の要素が、前記第２のエージェントに前記招待メッセージを送信するために前記ヘッダから前記第１の情報項目を決定する、請求項２または３のいずれか１項に記載の通信セッションを確立する方法。
5. 前記第三者の要素が、前記第１の情報項目を決定するために、「＠」記号で始まる前記「ｒｅｆｅｒ−ｔｏ」ヘッダのコンテンツを削除し、前記エスケープ記号を「＠」記号で置き換える、請求項４に記載の通信セッションを確立する方法。
6. 前記第２の情報項目が、前記シグナリング・メッセージの「ｒｅｆｅｒ−ｒｏｕｔｅ」ヘッダに含まれる、請求項２または３のいずれか１項に記載の通信セッションを確立する方法。
7. 前記第２の情報項目が、前記「ｒｅｆｅｒ−ｔｏ」ヘッダのパラメータとして含まれる、請求項２または３のいずれか１項に記載の通信セッションを確立する方法。
8. 前記第三者の通信要素（Ｃ）が、前記イベント（Ｓ）の発生元である装置（ＷＳ、ＳＥ、Ｗ）に戻り情報（Ｆ）を送信する、請求項１乃至７のいずれか１項に記載の通信セッションを確立する方法。
9. 前記通信エージェント（Ａ、Ｂ）の１つがコンテンツ・サーバである、請求項１乃至８のいずれか１項に記載の通信セッションを確立する方法。
10. イベント（Ｓ）を受信したとき、２つの通信エージェント（Ａ、Ｂ）の間の通信セッション（ＳＭ）を確立する第三者の通信要素（Ｃ）であって、前記第２のエージェント（Ｂ）に宛てられた、かつ前記第三者の要素（Ｃ）を介して伝送するように意図された招待メッセージ（Ｍ_２）を前記第１のエージェント（Ａ）に送信させるように構成されたシグナリング・メッセージ（Ｍ_１）を、前記第１のエージェント（Ａ）に送信するように意図されたことを特徴とする前記第三者の通信要素（Ｃ）。
11. 前記シグナリング・メッセージ（Ｍ_１）が、前記第２のエージェントを前記招待メッセージの受信者として識別する第１の情報項目と、前記第三者の要素を前記招待メッセージ（Ｍ_２）のルートの要素として識別する第２の情報項目とを含む、ＳＩＰプロトコルに準拠した「ＲＥＦＥＲ」メッセージである、請求項１０に記載の第三者の通信要素（Ｃ）。
12. 前記第１の情報項目が、前記シグナリング・メッセージの「ｒｅｆｅｒ−ｔｏ」ヘッダに含まれる、請求項１１に記載の第三者の通信要素。
13. 前記第２の情報項目も、前記「ｒｅｆｅｒ−ｔｏ」ヘッダに含まれ、エスケープ記号によって前記第１の情報項目と区別され、前記第三者の要素が、前記招待メッセージを前記第２のエージェントに送信するために前記ヘッダから前記第１の情報項目を決定するように意図された、請求項１１または１２のいずれか１項に記載の第三者の通信要素。
14. 前記第１の情報項目を決定するために、「＠」記号で始まる前記「ｒｅｆｅｒ−ｔｏ」ヘッダのコンテンツを削除し、前記エスケープ記号を「＠」記号で置き換えるように意図された、請求項１３に記載の第三者の通信要素。
15. 前記第２の情報項目が、前記シグナリング・メッセージの「ｒｅｆｅｒ−ｒｏｕｔｅ」ヘッダに含まれる、請求項１１または１２のいずれか１項に記載の第三者の通信要素。
16. 前記第２の情報項目が、前記「ｒｅｆｅｒ−ｔｏ」ヘッダのパラメータとして含まれる、請求項１１または１２のいずれか１項に記載の第三者の通信要素。
17. 前記イベント（Ｓ）の発生元である装置（ＷＳ、ＳＥ、Ｗ）に戻り情報（Ｆ）を送信するようにも意図された、請求項１０乃至１６のいずれか１項に記載の第三者の通信要素。
18. 請求項１０乃至１７のいずれか１項に記載の第三者の通信要素を少なくとも１つ備える通信ネットワーク。
19. 前記通信エージェントの１つがコンテンツ・サーバである、請求項１８に記載の通信ネットワーク。

Images