JP2011525752A - マルチコンポーネント通信セッションでのセッション連続性情報の伝達 - Google Patents

Abstract

複数のメディアコンポーネントを有するマルチメディア通信セッション内で、１つまたは複数のメディアコンポーネントを、１のアクセスネットワークから別のアクセスネットワークへ転送することが可能であり、なおかつ通信セッション全体の連続性を維持することができる。各セッションは、まず識別され、その後、転送を意図されたメディアコンポーネントも、識別される。識別されたセッションおよびコンポーネントのアイデンティティは、メディアコンポーネント転送を実行するために通信ネットワーク内の１つまたは複数のエンティティに送信される。

Description

米国特許法第１１９条の下での優先権の主張
本特許出願は、２００８年６月１９日に出願され、本願の譲受人に譲渡され、参照によって明示的に本明細書に組み込まれる米国仮出願第６１／０７３９０２号、名称「Ｃｏｎｖｅｙｉｎｇ Ｓｅｓｓｉｏｎ Ｃｏｎｔｉｎｕｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ ｉｎ ａ Ｍｕｌｔｉ−Ｃｏｍｐｏｎｅｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｓｓｉｏｎ」の優先権を主張するものである。

本発明は、一般に通信に関し、より詳細には、複数のセッションコンポーネントを有する通信セッションでの情報の交換および処理に関する。

電気通信の進歩は、マルチメディアセッションをインターネット上で異なるネットワークアクセスを介して搬送することを可能にする。たとえば、１つの通信セッション内で、複数のセッションコンポーネントが単一のネットワークアクセスを介して行われることは、珍しくはない。たとえば、ある通信セッションで、複数のビデオセッションコンポーネントおよびオーディオセッションコンポーネントを、単一のネットワークアクセスを介して同時に実行することができる。これらのマルチメディアセッションコンポーネントは、非常にしばしば、データ集中型である。時々、いくつかのセッションコンポーネントを、さまざまな理由から別のネットワークに転送することが必要になる。理由は、たとえば、コスト、サポートの可用性、およびネットワーク負荷などに起因するものとすることができる。

これまでは、異なるネットワークの間でのセッションコンポーネントの転送は、仮に可能であるとしても、問題があった。

したがって、通信セッションの連続性を維持するために、信頼できる形での通信セッションコンポーネントの転送の効率的な方式を提供する必要がある。

複数のメディアコンポーネントを有するマルチメディア通信セッション内で、１つまたは複数のメディアコンポーネントは、一つのアクセスネットワークから別のアクセスネットワークへ転送されることが可能であり、なおかつ通信セッション全体の連続性を維持することができる。各セッションは、まず識別され、その後、転送を意図されたメディアコンポーネントも、識別される。識別されたセッションおよびコンポーネントのアイデンティティは、メディアコンポーネント転送を実行するために通信ネットワーク内の１つまたは複数のエンティティに送信される。

上記および他の特徴および利点は、添付図面と共に解釈される次の詳細な説明から当業者に明白になり、添付図面では、類似する符号が類似する部分を指す。

本発明の例示的実施形態による通信システム全体を示す単純化された概略図。 さまざまなエンティティの間で通信セッションのセッションアイデンティティを識別するために交換されるメッセージを示すコールフロー図。 さまざまなエンティティの間で通信セッションのセッションアイデンティティを識別するために交換されるメッセージを示す別のコールフロー図。 通信セッションのセッション識別が識別された後にさまざまエンティティの間で交換されるメッセージおよびデータと、メディアコンポーネント転送に関する要求を開始するためにユーザエンティティによってインフラストラクチャエンティティに送信されるメッセージとを示すコールフロー図。 メディアコンポーネント転送に関する要求を開始するために通信セッションのセッションアイデンティティをユーザエンティティからインフラストラクチャエンティティに送信する代替方式を示す部分フロー図。 メディアコンポーネント転送に関する要求を開始するために通信セッションのセッションアイデンティティをユーザエンティティからインフラストラクチャエンティティに送信する代替方式を示す部分フロー図。 転送を意図されたメディアコンポーネントを識別する、さまざまなエンティティの間で交換される例示的メッセージの本体を示す単純化された図。 転送を意図されたメディアコンポーネントを識別する、さまざまなエンティティの間で交換される例示的メッセージの本体を示す単純化された図。 転送を意図されたメディアコンポーネントを識別する、さまざまなエンティティの間で交換される図７および８に示されたメッセージの代替としての別の例示的メッセージの本体を示す単純化された図。 転送を意図されたメディアコンポーネントを識別する、さまざまなエンティティの間で交換される図７および８に示されたメッセージの代替としての別の例示的メッセージの本体を示す単純化された図。 例示的実施形態による、ユーザエンティティによって用いられるプロセスステップを全体的に要約するフローチャート。 例示的実施形態によるネットワークエンティティによって用いられるプロセスステップを全体的に要約するフローチャート。 例示的実施形態によるハードウェア実施態様の一部を示す単純化された概略図。

次の説明は、当業者が本発明を作り、使用することを可能にするために提示される。説明のために、次の説明では詳細を示す。当業者が、これらの特定の詳細の使用なしで本発明を実践できることを認めるはずであることを了解されたい。他の場合には、不必要な詳細で本発明の説明を不明瞭にしないようにするために、周知の構造およびプロセスは詳しく述べない。したがって、本発明は、示される実施形態によって限定されることを意図されているのではなく、本明細書で開示される原理および特徴と一貫する最も広い範囲に従わなければならない。

さらに、次の説明では、簡潔さおよび明瞭さのために、国際電気通信連合（ＩＴＵ）によって３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）の下で公表されたＷｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（ＷＣＤＭＡ）標準規格に関連する用語法が使用される。本発明が、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交周波数分割多元接続（ＯＦＤＭＡ）などに関連するテクノロジおよび関連する標準規格など、他のテクノロジにも適用可能であることを強調しなければならない。異なるテクノロジに関連する用語法は、変化する可能性がある。たとえば、検討されるテクノロジに応じて、ＷＣＤＭＡ標準規格で使用されるユーザ機器（ＵＥ）が、時々、いくつか例を挙げると、アクセス端末（ＡＴ）、ユーザ端末、移動局（ＭＳ）、加入者ユニット、ユーザ機器（ＵＥ）、などと呼ばれる可能性がある。同様に、ＷＣＤＭＡ標準規格で使用されるアクセスネットワーク（ＡＮ）が、時々、アクセスポイント、アクセスノード（ＡＮ）、Ｎｏｄｅ Ｂ、基地局（ＢＳ）などと呼ばれる可能性がある。ここでは、異なる用語法が、適用可能である時に異なるテクノロジに適用されることに留意されたい。

符号１０によって示される通信システム全体を概略的に示す図１を参照する。

図１では、説明の単純さおよび簡単さのために、システム１０を、３つのアクセスネットワーク（ＡＮ）１２、１４、および１６を備えるものとして図示する。

この例では、ＡＮ １２は、インターネットプロトコル（ＩＰ）接続性をＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）３０によって提供されるマルチメディアサービスに提供できるＬｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）通信ネットワークである。ＡＮ １２は、Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｒ Ｅｎｔｉｔｙ（ＭＭＥ）３２、Ｎｏｄｅ Ｂ ３４、Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ（ＳＧＷ）３６、およびＰＤＮ Ｇａｔｅｗａｙ（ＰＧＷ）３８などの異なるネットワークエンティティを備える。この例では移動体デバイスであるＵＥ ２２などのユーザエンティティは、無線リンクレベルで無線でＮｏｄｅ Ｂ ３４と通信する。

ＡＮ １４は、ＷＬＡＮネットワーク、たとえば、ＩＥＥＥ ８０２．１１標準規格および他の無線ローカルエリアネットワークテクノロジの下で動作するネットワークである。ＡＮ １４は、とりわけ、アクセスポイント（ＡＰ）２７を備える。別のＵＥ ２６などの別のユーザエンティティが、たとえばバックボーンネットワーク２０のアクセスのために無線でＡＰ ２７と通信することができる。

ＡＮ １６は、もう１つのネットワーク、たとえば、ＣＤＭＡ２０００ネットワークである。ＡＮ １６は、とりわけ、Ｐａｃｋｅｔ Ｄａｔａ Ｓｅｒｖｉｃｅ Ｎｏｄｅ（ＰＤＳＮ）２９、アクセスノード（ＡＳ）３１、およびＳｅｒｖｉｎｇ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ（ＳＲＮＣ）３３を含む。別のＵＥ ２５などのさらに別のユーザエンティティが、たとえばバックボーンネットワーク２０のアクセスのために無線でＡＮ ３１と通信することができる。

図１では、３つすべてのＡＮ １２、１４、および１６が、ＩＭＳコアネットワーク３０にリンクされる。この実施形態で説明されるＩＭＳコアネットワーク３０は、さまざまな標準規格組織によってサポートされるアーキテクチャ的フォーマットを有するネットワークであり、例は、いくつか例を挙げると３ＧＰＰ、３ＧＰＰ２（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２）、ＩＥＥＥ（米国電気電子技術者協会）などである。ＩＭＳコアネットワーク３０は、ＩＰプロトコルを使用し、バックボーンネットワーク２０に接続される。バックボーンネットワーク２０は、インターネットまたはイントラネットとすることができる。

図１では、ＵＥ ２２、２６、および２５は、それぞれＬＴＥ ＡＮ １２、ＷＬＡＮ ＡＮ １４、およびＣＤＭＡ２０００ ＡＮ １６を介してＩＭＳコアネットワーク３０に接続されているように図示されている。単一のＵＥが、１つのＡＮ、任意のＡＮ、またはすべてのＡＮを介してＩＭＳコアネットワーク３０へのアクセスを得ることができることを理解されたい。たとえば、ＵＥ ２２は、ＬＴＥ ＡＮ １２とＷＬＡＮ ＡＮ １４との両方を介して、同時にまたは異なる時間期間にＩＭＳコアネットワーク３０へのアクセスを得ることができる。

上述されたＡＮのタイプが、単に例示的であることに留意されたい。他のタイプのＡＮによるＩＭＳコアネットワーク３０への接続は、明らかに可能である。

次の説明では、ＩＭＳ標準規格によるシグナリングおよびデータ交換に関連する用語法およびプロトコルが使用される。ＩＭＳ標準規格の基礎は、３ＧＰＰによって発行された刊行物、名称「Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ （ＩＰ） ｍｕｌｔｉｍｅｄｉａ ｃａｌｌ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ ｂａｓｅｄ ｏｎ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｐｃｏｌ （ＳＩＰ） ａｎｄ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＤＰ）」、３ＧＰＰ ＴＳ ２４．２２９に見出すことができる。

当初に、ＩＭＳコアネットワーク３０を介して別のＵＥ ２５に対応するＵＥ ２２があると仮定する。ＵＥ ２２は、ＡＮ １２を介してＩＭＳコアネットワーク３０へのアクセスを得る。同様に、ＵＥ ２５は、ＡＮ １６を介してＩＭＳコアネットワーク３０へのアクセスを得る。

ＩＭＳコアネットワーク３０では、ＩＭＳコアネットワーク３０は、Ｐｒｏｘｙ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（Ｐ−ＣＳＣＦ）サーバ４０、Ｓｅｒｖｉｎｇ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ（Ｃ−ＣＳＣＦ）サーバ４２、Ｓｅｓｓｉｏｎ Ｃｏｎｔｉｎｕｉｔｙ（ＳＣ）サーバ（ＡＳ）４６、および他のＩＭＳエンティティ４４を含む。Ｓｅｓｓｉｏｎ Ｃｏｎｔｉｎｕｉｔｙ（ＳＣ）サーバ４６は、異なるアクセスの間での通信セッションのシームレスセッション転送を可能にする機能性を提供する、ＩＭＳコアネットワーク３０内のアプリケーションサーバの１タイプである。この例では、ＩＭＳセッション連続性を維持するために、すべてのＩＭＳセッションが、ＳＣサーバ４６でアンカリングされる。

この例の実施形態では、当初に、ＵＥ ２２が、複数のマルチメディアコンポーネントを有するＵＥ ２５とのＩＭＳセッションを有していると仮定する。本明細書および添付の特許請求の範囲では、用語「マルチ」または「複数」は、１つまたは複数を意味する。前述のように、ＩＭＳセッションは、ＳＣサーバ４６でアンカリングされる。そのようなセッションの例は、ＵＥ ２２が、複数の音声(voice)ストリームおよびビデオストリームを有するＵＥ ２５とのビデオ会議を行っていることとすることができる。説明のために、３つのセッションコンポーネント、すなわち、音声＃１、ビデオ＃２、およびビデオ＃３が通信セッション内にあると仮定する。たとえば、ビデオ＃２を、ＵＥ ２２および２５のユーザの対面ビデオとすることができ、ビデオ＃３を、ある製品の製品デモンストレーションビデオとすることができる
以下では、用語「セッションコンポーネント」、「メディアコンポーネント」、通信コンポーネント」、「マルチメディアコンポーネント」、および時々単に「コンポーネント」が、交換可能に使用される。

この例では、ＵＥ ２２が、移動体であり、ＡＮ １２、１４、および１６などの複数のＡＮにアクセスできると仮定する。ＵＥ ２２が、異なるＡＮの間でローミングしている時には、ＵＥ ２２が、ＩＭＳ通信セッションまたはセッションの任意のコンポーネントをあるＡＮから別のＡＮに転送できることが、非常に望ましい。

例示のために、この例では、ＵＥ ２２は、当初に、前述の３つのメディアコンポーネントすなわち、音声＃１、ビデオ＃２、およびビデオ＃３を伴って、ＬＴＥ ＡＮ １２を介してＵＥ ２５と通信すると仮定する。ＵＥ ２２が、ＷＬＡＮ ＡＮ １４へのアクセスを得ることができる時に、ＵＥ ２２は、一例として、メディアコンポーネントビデオ＃３をＷＬＡＮ ＡＮ １４に転送するというオプションを有するが、ＬＴＥ ＡＮ １２を用いて他のメディアコンポーネント、音声＃１およびビデオ＃２を維持することができる。

以下で説明するのは、あるＡＮから別のＡＮへのＳＣサーバ４６を介するセッションおよびセッションコンポーネントの転送を容易にする方式である。

ＵＥ ２２などのＩＭＳユーザエンティティは、上述のように、複数の対応を有する複数のマルチメディアセッションを確立することを許される。たとえば、ＵＥ ２２は、上述のＵＥ ２５とのＩＭＳセッションを有することができ、それと同時に、ＵＥ ２２は、ＵＥ ２６との別のＩＭＳセッションをも有することができる。セッション転送を可能にするために、すべてのマルチメディアセッションが、ＩＭＳ ＳＣサーバ４６でアンカリングされ、これが、ＵＥ ２２の、そのホームＩＭＳネットワークでのセッション転送を容易にする。ＵＥ ２２が、ＵＥ ２５との現在処理中のセッション内のメディアコンポーネントの一部を１つまたは複数の他のＡＮに転送するようにＳＣサーバ４６に要求する時に、ＵＥ ２２は、他のどのセッションでもなく、所期のセッションとして転送に関してメディアコンポーネントを有するセッションを明瞭に識別し、示す必要がある。この例では、この所期のセッションは、前述したように、３つのメディアコンポーネント、音声＃１、ビデオ＃２、およびビデオ＃３を有する、ＵＥ ２２がＵＥ ２５と通信するセッションである。これは、他のセッションが存在する場合に、他のどのセッションでもなく、たとえばＵＥ ２２がＵＥ ２６と通信することもできる。

異なるセッションを区別するために、ＩＭＳ ＳＣサーバ４６は、ＵＥ ２２が特定の遠隔のユーザエンティティと行っている各セッションに一意ＩＤ（Ｉｄｅｎｔｉｔｙ）を割り当てる。この例示的実施形態ではＳＴＩ（Ｓｅｓｓｉｏｎ Ｔｒａｎｓｆｅｒ Ｉｄｅｎｔｉｆｉｅｒ）と呼ばれるこの一意ＩＤは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ＵＲＩ（Ｕｓｅｒ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）などのＵＲＩ、電話ＵＲＩ、ＳＩＰダイアログのＳＩＰダイアログＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）などのフォーマットをとることができる。以下で説明されるのは、ＳＣサーバ４６とＩＭＳ ＵＥ ２２との間でのこのアイデンティティ情報ＳＴＩを転送する方式である。

ここで、図１に関連して図２を参照する。図２は、システム１０のさまざまなエンティティの間のメッセージフローおよびデータフローを示すコールフロー図である。

当初に、ＵＥ ２２が、図２に示されたメッセージパス４８によって示されるように、ＡＮ １２を介してＩＭＳコアネットワーク３０にＳＩＰ ＩＮＶＩＴＥメッセージを送信することによって、上で述べたマルチメディアＩＭＳセッションを開始すると仮定する。図２〜６などの続くコールフロー図では、ＵＥ（たとえば、ＵＥ ２２、２５、および２６）は、ＡＮ（たとえば、ＡＮ １２、１４、および１６）を介してコアネットワーク３０およびそのエンティティ（たとえば、ＳＣサーバ４６）にアクセスする。しかし、明瞭さのために、関連するメッセージパスを有するＡＮは、これらのコールフロー図には図示されていない。すなわち、図２〜６には、論理メッセージパスだけが示されている。特定のフローの関連するＡＮには、この説明で必要な時に言及する。ここで、参照を図２に戻す。ＳＩＰ ＩＮＶＩＴＥメッセージは、ＳＣサーバ４６を介し、メッセージパス３０を介してアンカリングのためにルーティングされ、さらに、図２に示されているように、メッセージパス５２を介してＵＥ ２５にさらに送信される。

ＵＥ ２５が、ＵＥ ２２によって開始されたマルチコンポーネントビデオ会議セッションを受け入れる場合には、ＵＥ ２５は、メッセージパス５４を介して、ＳＣサーバ４６に２００ ＯＫメッセージを送り返す。

パス３０を介してＳＩＰ ＩＮＶＩＴＥメッセージを受信するとまたはパス５４を介して２００ ＯＫメッセージを受信すると、ＳＣサーバ４６は、ビデオ会議セッションのＳＴＩを割り当てる。このプロセスは、図２では符号５５によって示される。ＳＴＩを割り当てることの目的は、後に、セッションまたはセッションのコンポーネントをあるＡＮから別のＡＮに転送するために必要な場合に、ＵＥ ２２がこのＩＭＳセッションを参照することを可能にするためである。ＳＴＩは、ＵＥ ２２とＵＥ ２５との間のビデオ会議セッションを、ＵＥ ２２がＵＥ ２５または他のエンティティのいずれかと確立する可能性がある他の可能なセッションから区別する。さらに、割り当てられたＳＴＩは、現在のセッションを、ＵＥ ２２と通信してはいない他のＵＥによって確立された、やはり同一のＳＣサーバ４６を通過する他のセッションからも区別する。

この実施形態では、一旦ＳＣサーバ４６によって割り当てられたＳＴＩは、図２に示されているように、ＩＭＳコアネットワーク３０を介し、ＡＮ １２を介し、メッセージパス５６および５８をそれぞれ介してＵＥ ２２に送信される２００ ＯＫメッセージなどのＳＩＰ応答メッセージを介してＵＥ ２２に伝えられる。より具体的には、割り当てられたＳＴＩは、２００ ＯＫメッセージ内の新しいＳＩＰヘッダに含まれる。この特定の例では、新しいＳＩＰヘッダは、「Ｐ−ＳＴＩ」と呼ばれる。新しいヘッダの他の名前を使用することもできることに留意されたい。Ｐ−ＳＴＩヘッダは、図２に示されているように、メッセージ内容と一緒に、メッセージパス５６および５８を介して送信される２００ ＯＫメッセージに含まれる。この特定の例では、ＳＴＩの内容または値は、図２では「ＡＢＣ」というラベルを付けられている。ＡＢＣは、たとえば、Ｓｅｓｓｉｏｎｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）−ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）または電話ＵＲＩ、あるいはＳＩＰセッションのダイアログＩＤとすることができる。

ＳＩＴが、ＳＩＰダイアログＩＤの形である場合には、ＳＩＰ ２００ ＯＫメッセージなどの既存ＳＩＰメッセージが、既に異なるヘッダ内で暗黙のうちにＳＴＩの包含をサポートするので、パス５６および５８を介して送信されるＳＩＰ ２００ ＯＫメッセージなどのＳＩＰメッセージを介してＳＴＩをＵＥ ２２に送信するための「Ｐ−ＳＴＩ」ヘッダなどの明示的ヘッダを有する必要がないことに留意されたい。

ＳＴＩの受信に伴って、ＵＥ ２２は、後のセッション転送に関して要求するためにおよび以下でさらに説明するように、ＳＴＩを使用することができる。２００ ＯＫメッセージの受信すると、ＵＥ ２２は、ＩＭＳコアネットワーク３０を介し、それぞれメッセージパス５７および５９を介して、ＳＣサーバ４６に肯定応答メッセージを送信することができる。

図３に、ＵＥ ２５がＵＥ ２２の代わりにビデオ会議セッションを開始するシナリオを示す。再び、一旦、ＳＴＩが、プロセスステップ５５によって示されるようにＳＣサーバ４６によって割り当てられると、ＳＴＩ情報を、図３に示されているようにメッセージパス６０および６２を介して送信されるＳＩＰ ＩＮＶＩＴＥメッセージ内でＵＥ ２２に送信することができる。受信時に、ＵＥ ２２は、前に説明したように、メッセージパス６１および６２を介して肯定応答として２００ ＯＫメッセージを送信することができる。簡潔にするために、図３は、さらに詳しくは述べない。

すべての実施形態で説明されるメッセージおよびそのフローが、変形形態を有することができ、さらに、異なる名前を使用できることに留意されたい。たとえば、被呼ＵＥ、たとえばこの場合にはＵＥ ２５が、最終的な２００ ＯＫメッセージを送信する前に、１８ｘメッセージなどの中間メッセージを送信することが可能である。

ここで、戻って、図１に関連して図２を参照する。

メッセージパス５８および５６を介する２００ ＯＫメッセージの受信の後に、ＵＥ ２２が、ＵＥ ２５とのビデオ会議を実行すると仮定する。本質的に、３つのメディアコンポーネントが確立される。この３つのメディアコンポーネントは、図４に示されているように、それぞれセッションコンポーネント、音声＃１、ビデオ＃２、およびビデオ＃３の符号６５、６７、および６９によって表される。図４では、データトンネル６５、６７、および６９の確立の前のメッセージフローは、図２から複製されたものである。

ビデオ会議の途中のある時刻に、ＵＥ ２２が、通信セッションコンポーネントをＡＮ １２からＡＮ １４に転送すると判断すると仮定する。そのような転送には、多数の理由がありえる。転送の例示的な理由は、いくつか例を挙げると、ネットワークの負荷、コスト、ネットワークによって設定される特定のポリシ、ネットワークの能力、ＵＥユーザのプリファレンスなどの要因に基づくものとすることができる。

セッションコンポーネント転送を開始するために、ＵＥ ２２は、図４に示されているように、それぞれメッセージパス７０および６８を介してコアＩＭＳネットワーク３０へのターゲットＡＮ １４を介してＳＣサーバ２６にＳＩＰ ＩＮＶＩＴＥメッセージを送信する。

ＳＴＩすなわち、図２および３に示されたＡＢＣとして内容値を有するＳＴＩが、前の例のようにＳＩＰ ＵＲＩまたは電話ＵＲＩである場合には、新しいＳＩＰヘッダＰ−ＳＴＩが、内容値ＡＢＣと一緒に、パス６８および７０を介して送信されるＳＩＰ ＩＮＶＩＴＥメッセージにも含まれる。前に述べたように、ＳＩＰ ＵＲＩまたは電話ＵＲＩの他に、ＡＢＣを、ＳＩＰダイアログＩＤなどの他のＩＤとすることができる。ヘッダＰ−ＳＴＩの内容、この場合にはＡＢＣは、図２〜４に示されたようにプロセスステップ５５を介してＳＣサーバ４６によって割り当てられたものと同一のＳＴＩ値をとる。

ＳＣサーバ４６は、ＳＴＩを含むＳＩＰ ＩＮＶＩＴＥメッセージの受信時に、ＡＮ １４を介して受信したセッション転送要求を、図２〜４のＡＮ １２を介して確立されたオリジナルセッションに相関させ、要求されたセッション転送動作を実行することができる。

ＳＴＩが、たとえば単純なＳＩＰ ＵＲＩまたは電話ＵＲＩではなくＳＩＰダイアログＩＤの形態である場合には、ＳＴＩをＳＣサーバ４６に伝えるための複数の他の方式が可能である。

まず、図４に示されているようにパス６８および７０を介して送信されるＳＩＰ ＩＮＶＩＴＥメッセージでは、ＳＩＰ ＩＮＶＩＴＥヘッダのＲｅｑｕｅｓｔ−ＵＲＩフィールド内で、指定されるＲｅｑｕｅｓｔ−ＵＲＩに加えて、追加の新しいＵＲＩパラメータ情報を添付することができる。パス６８および７０が図４から複製されるが、異なるＳＩＰ ＩＮＶＩＴＥメッセージを伴う１つの例が、図５に示されている。上述のように指定されたＲｅｑｕｅｓｔ−ＵＲＩは、図５に示されるようにＩＰアドレス「ｓｃ＠ｗｉｒｅｌｓｓ．ｃｏｍ」である。図５に示されるように情報「ＳＴＩ： ＡＢＣ」は、そのコンポーネントが転送されるべきオリジナルセッションを識別する、添付される追加の新しいＵＲＩパラメータ情報である。

別の方式では、ＳＩＰダイアログＩＤがＳＴＩとして使用される場合に、ＳＩＰ Ｒｅｐｌａｃｅｓヘッダを、セッション転送要求内でＳＴＩを搬送するのに使用することができる。さらに、ＳＩＰ ＩＮＶＩＴＥメッセージのヘッダ内のＲｅｐｌａｃｅｓヘッダに、新しいヘッダパラメータを追加することができる。通常、Ｒｅｐｌａｃｅｓヘッダは、識別されるセッションがセッション転送によって置換されることを示す。しかし、新しいヘッダパラメータフィールドの内容は、このＳＩＰ要求が置換の代わりにセッション転送（たとえば、メディアコンポーネントの一部を転送するのみ）の要求であることの情報を搬送することができる。例が、図６に示されており、図６では、メッセージパス６８および７０が図４から複製されるが、ヘッダフィールド「Ｒｅｐｌａｃｅｓ」を有する異なるＳＩＰ ＩＮＶＩＴＥメッセージを伴い、このヘッダフィールド「Ｒｅｐｌａｃｅｓ」では、内容が、識別されたセッションがセッション置換の代わりにセッション転送の対象であることを示すために新しいヘッダパラメータ「ｔｒａｎｓｆｅｒ−ｏｎｌｙ」を含む。

ＩＭＳマルチメディアセッションは、上の例で説明したように、複数のメディアコンポーネントを含むことができる。セッション転送を実行する時に、ＩＭＳ ＵＥは、セッションの一部だけを新しいアクセスに転送することを選択することができる。（たとえば、既存の音声＃１およびビデオ＃２からビデオ＃３）。以下で説明するのは、ＩＭＥ ＵＥがどのメディアコンポーネントを転送すべきなのかを示すための方式である。

ここで、参照を図１および４に戻す。３つのメディアコンポーネント６５、６７、および６９が確立された後に、ビデオ会議の途中のどこかで、ＵＥ ２２が、通信セッションの全体ではなく一部をＡＮ １２からＡＮ １４に転送すると判断すると仮定する。例示的な実例として、ＵＥ ２２が、ビデオ＃３コンポーネントをＡＮ １２からＡＮ １４に転送するが、他のコンポーネント、ビデオ＃２および音声＃１は維持することを望むと仮定する。転送の理由は、上で述べた理由のうちの１つまたは複数とすることができる。

ＵＥ ２２は、転送すべきコンポーネントを識別し、ＳＣサーバ４６に知らせることができる。再び、複数の可能な方式がある。

まず、図２および４のすべてのＳＩＰ ＩＮＶＩＴＥメッセージ（たとえば、パス５２を介する）および２００ ＯＫメッセージ（たとえば、パス５４を介する）または図３のＳＩＰ ＩＮＶＩＴＥ（たとえば、パス６０および６２を介する）および２００ ＯＫメッセージ（たとえば、パス６１および６３を介する）の本体部分に含まれるのは、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｃｏｔｏｌ（ＳＤＰ）オファー／アンサー（ｏｆｆｅｒ／ａｎｓｗｅｒ）本体である。ＳＤＰ本体は、各メディアコンポーネントのプロパティを指定する。

図７は、そのような構成を示すＳＤＰ本体を概略的かつ部分的に示す。図７は、メッセージパス４８、５０、および５２（図２および４）を介してＵＥ ２２によって送信されるＳＩＰ ＩＮＶＩＴＥメッセージのＳＤＰ本体の一部を具体的に示す。図７では、文字「ｍ」は、基本的に、その行がメディアコンポーネントの記述に関係することを指定する。たとえば、最初の「ｍ」の行では、とりわけ、これが、ＵＥ ２２のポート番号「１０００」を使用するオーディオコンポーネントとして指定される。この行の残りは、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）によって公表されたＲＦＣ ３５５１の下で指定されるＲｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ／ Ａｕｄｉｏ Ｖｉｄｅｏ Ｐｒｏｆｉｌｅ（ＲＴＰ／ＡＶＰ）のプロトコルとして、使用されるプロトコルを記述する。メディアコンポーネントのコーデック（コーディングおよび復号化）も示される。

セッションコンポーネント転送の第１方式では、図７のメディアコンポーネントは、割り当てられる可能性がある指定された値またはインデックス値に関連する。指定された値の割当ては、明示的または暗示的とすることができる。例示的な明示的割当ては、ＳＤＰでのメディアコンポーネントの出現の順序に基づくなど、事前に合意された方法論に基づくものとすることができる。たとえば、オーディオコンポーネントでは、インデックス「＃１」が、このコンポーネントに割り当てられる。一方のビデオコンポーネントは、インデックス「＃２」を割り当てられ、他方のビデオコンポーネントは、インデックス「＃３」を割り当てられる。ＳＣサーバ４６ならびにＵＥ ２２および２５など、マルチコンポーネントセッションにかかわるすべてのエンティティが、インデックス値割当ての同一の方法論を使用する。したがって、この場合には、ＵＥ ２２とＳＣサーバ４６との両方が、図７に示されたものなどの起点ＳＩＰメッセージ内のＳＤＰ本体のメディアコンポーネントに対応するものとしてインデックス値を知る。かかわるすべてのエンティティが、同一の割当て方式を採用し、これによって、後続のＳＩＰメッセージ交換中のオファー／アンサーに関する一貫性がもたらされる。

指定された値またはインデックス値を、暗示的に割り当てることもできる。指定された値は、ＳＩＰオファー／アンサー交換中にＳＤＰ本体自体の中で明示的には搬送されなくともよい。しかし、後続のＳＩＰメッセージのＳＤＰ本体は、必ず、メディアコンポーネントのリスティングの同一の順序を維持する。ＳＣサーバ４６またはＵＥ ２２もしくは２５など、マルチコンポーネントセッションにかかわる各関連エンティティは、そのリスティングの順序が開始ＳＩＰメッセージのリスティングの順序と同一である後続のＳＩＰメッセージ内のメディアコンポーネントのリスティングの一貫した順序から、指定された値を導出することができる。たとえば、図７に示されているように、ポート番号１０００を有するオーディオコンポーネントは、他のコンポーネントの中で最初に現れる。したがって、＃１という指定された値を、すべての関連エンティティによって導出することができる。別の例として、図７に示されたポート番号１００４を有するビデオコンポーネントは、リスティングの順序で他のコンポーネントの中で３番目に現れる。その結果、＃３という指定された値を、かかわるすべてのエンティティによって導出することができる。

参照を、セッションコンポーネント転送の第１方式に戻す。インデックス値または指定された値を明示的にまたは暗示的にのいずれかで割り当て、ＵＥ ２２が、あるコンポーネント、この例ではビデオ＃３の転送を要求する時に、ＵＥ ２２は、図８に絵図的に例示的に示されているように、新しいＳＤＰ属性、この例では「ｏｒｉｇ−ｍｉｄ」を介してオリジナルセッション内のコンポーネントの割り当てられた指定された値（すなわち、＃３）を含むメッセージをＳＣサーバ４６に送信することによって、そのような要求についてＳＣサーバ４６に知らせることができる。図８では、属性行「ａ」は、すぐ上のメディアコンポーネントの属性を指定する。新しいＳＤＰ属性の他の名前が、明らかに可能であることに留意されたい。より具体的には、この例では、ＵＥ ２２は、図４〜６に示されたパス６８および７０を介して送信されるメッセージなど、ＳＣサーバ４６に送信されるＳＩＰ ＩＮＶＩＴＥメッセージに指定された値（すなわち、＃３）を含めることができる。説明されたように例示的なＳＩＰ ＩＮＶＩＴＥメッセージは、図８に示され、このメッセージでは、ＳＩＰ本体は、新しいＳＤＰ属性「ｏｒｉｇ−ｍｉｄ」を使用して＃３として識別された転送されるべきコンポーネントの割り当てられた指定された値と、新たに割り当てられたポート番号「２０００」を有するものとして転送されるべきコンポーネントを記述する新しいメディア行と共に、部分的に示されている。

ＳＣサーバ４６に関して、以前に受信されたＳＩＰ ＩＮＶＩＴＥメッセージと新たに受信されたＳＩＰ ＩＮＶＩＴＥメッセージのメディア記述とを比較することと、メッセージの各割り当てられたインデックスの新しい属性を精査することとによって、サーバ４６は、どのコンポーネントが転送されるのかを知る。次に、ＳＣサーバ４６は、示されたコンポーネントを新しいアクセスに転送すると同時に、オリジナルアクセス上の残りのコンポーネントを維持することとによって、アクションを行う。

別の方式では、上述の方法論の代わりに、ＵＥ ２２が、明示的なもしくは暗黙のインデックス値またはいかなる新しいＳＤＰ属性を伴わないメッセージをＳＣサーバ４６に送信することによって、転送されるコンポーネントについてＳＣサーバ４６に知らせる。その代わりに、ＵＥ ２２は、ＳＤＢ本体に、以前に説明した方式とは異なる形でセッション転送に関する記述を含める。

当初に、メディアコンポーネントが、図９に示されたメッセージパス４８、５０、および５２（図２および４）を介してＵＥ ２２によって送信されるオリジナルＳＩＰ ＩＮＶＩＴＥメッセージの本体で指定されると仮定する。

この方式では、オリジナルセッションのすべてのメディアコンポーネントが、パス６８および７０を介して送信されるセッション転送要求に、それらがオリジナルセッションで合意されたＳＤＰに現れるのと同一の順序で含まれる。転送される必要がないコンポーネントについて、ＵＥ ２２は、所定の値、たとえば「０」を、そのメディアコンポーネントに対応するポート番号に割り当てた。その一方で、転送される必要があるコンポーネントについて、ＵＥ ２２は、通常のＳＤＰオファー／アンサーハンドリングと同様にポート番号を割り当てる。再び、ＵＥ ２２は、図４〜６に示されたパス６８および７０を介して送信されるメッセージなどのＳＩＰ ＩＮＶＩＴＥメッセージ内でそのような情報を伝えることができる。図１０では、オリジナルセッションのすべてのメディアコンポーネントが、同一の順序で含まれる、パス６８および７０を介して送信されるＳＩＰ ＩＮＶＩＴＥメッセージ内のＳＤＰ本体が概略的に示されている。ＵＥ ２２が転送を意図しないコンポーネントは、「０」という所定の値を割り当てられ、転送が意図されるコンポーネントは、たとえば「２００８」という、通常のポート番号値を割り当てられる。

再び、ＳＣサーバ４６について、以前に受信されたＳＩＰ ＩＮＶＩＴＥメッセージのメディア記述と新たに受信されたＳＩＰ ＩＮＶＩＴＥメッセージのメディア記述とを比較することによって、新しいＳＩＰ ＩＮＶＩＴＥはセッション転送を要求し、メディアコンポーネント、オーディオ＃１およびビデオ＃２について０という所定の値を示すので、ＳＣサーバ４６は、この２つのメディアコンポーネントが転送されないことを理解する。次に、ＳＣサーバ４６は、ビデオコンポーネント＃３だけを新しいアクセスに転送し、ここで、このメディアコンポーネントは、ポート番号「２００８」を割り当てられる。

図１１は、ＵＥ ２２などのユーザエンティティによって実行される、上記で説明された例示的な例でのプロセスを要約するフローチャートである。

図１２は、ＳＣサーバ４６などのネットワークエンティティによって実行される、上記で説明された例示的な例でのプロセスを要約するもう１つのフローチャートである。

図１３に、上記で説明した方式またはプロセスを実行する装置のハードウェア実施態様の一部を示す。この回路装置は、符号９０によって示され、ＵＥ ２２および２５などのユーザエンティティまたはＳＣサーバ４６および他の適用可能な通信エンティティなどのネットワークエンティティ内で実施することができる。

装置９０は、複数の回路を一緒にリンクする中央データバス９２を備える。これらの回路は、ＣＰＵ（中央処理装置）またはコントローラ９４、受信回路９６、伝送回路９８、およびメモリユニット１００を含む。

装置９０が、無線デバイスの一部である場合には、受信回路９６および伝送回路９８を、ＲＦ（無線周波数）回路に接続することができるが、図面には示されていない。受信回路９６は、データバス９２に送出する前に、受信された信号を処理し、バッファリングする。その一方で、伝送回路９８は、デバイス９０から送信する前に、データバス９２からのデータを処理し、バッファリングする。ＣＰＵ／コントローラ９４は、データバス２９２のデータ管理の機能を実行し、さらに、メモリユニット１００の命令内容を実行することを含む全般的なデータ処理の機能を実行する。

メモリユニット１００は、符号１０２によって全体的に示されるモジュールおよび／または命令の組を含む。この実施形態では、モジュール／命令は、とりわけ、上記で説明した方式およびプロセスを実行するセクションコンポーネント管理機能１０８を含む。機能１０８は、図１〜１２に示され、説明されたプロセスステップを実行するためのコンピュータ命令またはコードを含む。エンティティに特有の特定の命令を、機能１０８内で選択的に実施することができる。たとえば、装置９０がユーザエンティティの一部である場合には、とりわけ、図１〜１１に示され、説明されたユーザエンティティに特有の命令を、機能１０８内でコーディングすることができる。同様に、装置９０がインフラストラクチャ通信エンティティまたはネットワークエンティティ、たとえばＳＣサーバの一部である場合には、図１〜１０および１２に示され、説明されたインフラストラクチャエンティティの態様に特有の命令を、機能１０８内でコーディングすることができる。

この実施形態では、メモリユニット１００は、ＲＡＭ（ランダムアクセスメモリ）回路である。ハンドオフ機能１０８および１１０などの例示的機能は、ソフトウェアルーチン、モジュール、および／またはデータセットである。メモリユニット１００を、揮発性タイプまたは不揮発性タイプのいずれかとすることができる別のメモリ回路（図示せず）に結び付けることができる。代替として、メモリユニット３００を、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気ディスク、光ディスク、および当技術分野で周知の他のものなど、他の回路タイプから作ることができる。

さらに、メモリユニット１００を、特定用途向け集積回路（ＡＳＩＣ）とすることができる。すなわち、機能１０８内の命令またはコードを、ハードワイヤド(hard-wired)とするか、ハードウェアまたはハードウェアおよびソフトウェアの組合せによって実施することができる。

さらに、メモリユニット１００を、ＡＳＩＣと、揮発性タイプおよび／または不揮発性タイプから作られたメモリ回路との組合せとすることができる。

説明された発明的プロセスを、当技術分野で既知の任意のコンピュータ可読媒体上で担われるコンピュータ可読命令としてコーディングすることもできることに、さらに留意されたい。本開示では、用語「コンピュータ可読媒体」は、図１３の図に示され、説明されたＣＰＵ／コントローラ９４などの任意のプロセッサに実行のために命令を供給することに加わるすべての媒体を指す。そのような媒体は、ストレージタイプとすることができ、たとえば図１３のメモリユニット１００の説明で以前説明されたように、揮発性記憶媒体または不揮発性記憶媒体の形をとることができる。そのような媒体は、伝送タイプとすることができ、機械またはコンピュータによって可読の信号を搬送することができる音響波、電磁波、または光波を搬送する同軸ケーブル、銅ワイヤ、光ケーブル、およびエアインタフェースを含むことができる。コンピュータ可読媒体を、装置９０とは別のコンピュータ製品の一部とすることができる。

最後に、他の変更が、本発明の範囲内で可能である。上記で説明されたもの以外に、実施形態に関連して説明された任意の他の論理ブロック、回路、およびアルゴリズムステップを、ハードウェア、ソフトウェア、ファームウェア、またはその組合せで実施することができる。当業者は、形態および詳細における上記および他の変更を、本発明の範囲および趣旨から逸脱せずに作ることができることを理解するであろう。

Claims (35)

1. セッション識別を受信することと、
   複数のセッションコンポーネントを含む通信セッションを確立することと、
   前記複数のセッションコンポーネントからのコンポーネントの転送のためにネットワークエンティティに前記セッション識別を送信することと、
   を備える、通信システム内のユーザエンティティによって動作可能な方法。
2. 転送のために識別されたコンポーネントとして前記複数のセッションコンポーネントから前記コンポーネントを識別することと、
   前記通信セッションからの前記識別されたコンポーネントの前記転送のためにネットワークエンティティに前記識別されたコンポーネントの情報を提供することと
   をさらに備える、請求項１に記載の方法。
3. 転送のために前記識別されたコンポーネントの前記情報として前記識別されたコンポーネントの指定された値を前記ネットワークエンティティに提供することをさらに備え、前記指定された値は、セッションイニシエーションプロトコルメッセージ内の前記複数のセッションコンポーネントのリスティングの順序から導出される、請求項２に記載の方法。
4. 転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記ゼロ値とは異なる値を有する別のポート番号とを前記転送のために前記識別されたコンポーネントの前記情報として前記ネットワークエンティティに提供することをさらに備える、請求項２に記載の方法。
5. 前記セッション識別は、ＳＩＰ−ＵＲＩ（セッションイニシエーションプロトコル−Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、電話ＵＲＩ、およびＳＩＰダイアログＩＤ（識別子）からなるグループから選択される、請求項１に記載の方法。
6. 複数のセッションコンポーネントを含む通信セッションを確立することと、
   転送のために識別されたコンポーネントとして前記複数のセッションコンポーネントからコンポーネントを識別することと、
   前記通信セッションからの前記識別されたコンポーネントの前記転送のためにネットワークエンティティに前記識別されたコンポーネントの情報を提供することと、
   を備える、通信システム内のユーザエンティティによって動作可能な方法。
7. 転送のために前記識別されたコンポーネントの前記情報として前記識別されたコンポーネントの指定された値を前記ネットワークエンティティに提供することをさらに備え、前記指定された値は、セッションイニシエーションプロトコルメッセージ内の前記複数のセッションコンポーネントのリスティングの順序から導出される、請求項６に記載の方法。
8. 転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記ゼロ値とは異なる値を有する別のポート番号とを前記転送のために前記識別されたコンポーネントの前記情報として前記ネットワークエンティティに提供することをさらに備える、請求項６に記載の方法。
9. マルチコンポーネント通信セッションのセッション識別子を割り当てることと、
   前記セッション識別子をユーザエンティティに送信することと、
   前記マルチコンポーネント通信セッションからのコンポーネントの転送のために前記ユーザエンティティから前記セッション識別子を受信することと
   を備える、通信システム内のネットワークエンティティによって動作可能な方法。
10. 前記転送のために識別された前記コンポーネントの指定された値を前記ユーザエンティティから受信することをさらに備え、前記指定された値は、前記マルチコンポーネント通信セッションの複数のセッションコンポーネントのリスティングの順序から導出され、リスティングの前記順序は、セッションイニシエーションプロトコルメッセージ内で提供される、請求項９に記載の方法。
11. 転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記転送を意図される前記コンポーネントについて前記ゼロ値とは異なる値を有する別のポート番号とを前記ユーザエンティティから受信することをさらに備える、請求項９に記載の方法。
12. セッション識別を受信するための手段と、
    複数のメディアコンポーネントを含む通信セッションを確立するための手段と、
    前記複数のメディアコンポーネントからのコンポーネントの転送のためにネットワークエンティティに前記セッション識別を送信するための手段と、
    を備えるユーザ機器。
13. 転送のために識別されたコンポーネントとして前記複数のメディアコンポーネントから前記コンポーネントを識別するための手段と、
    前記通信セッションからの前記識別されたコンポーネントの前記転送のためにネットワークエンティティに前記識別されたコンポーネントの情報を提供するための手段と
    をさらに備える、請求項１２に記載のユーザ機器。
14. 転送のために前記識別されたコンポーネントの前記情報として前記識別されたコンポーネントの指定された値を前記ネットワークエンティティに提供するための手段をさらに備え、前記指定された値は、セッションイニシエーションプロトコルメッセージ内の前記複数のメディアコンポーネントのリスティングの順序から導出される、請求項１３に記載のユーザ機器。
15. 転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記ゼロ値とは異なる値を有する別のポート番号とを前記転送のために前記識別されたコンポーネントの前記情報として前記ネットワークエンティティに提供するための手段をさらに備える、請求項１３に記載のユーザ機器。
16. 前記セッション識別は、ＳＩＰ−ＵＲＩ（セッションイニシエーションプロトコル−Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、電話ＵＲＩ、およびＳＩＰダイアログＩＤ（識別子）からなるグループから選択される、請求項１２に記載のユーザ機器。
17. 複数のメディアコンポーネントを含む通信セッションを確立するための手段と、
    転送のために識別されたコンポーネントとして前記複数のセッションコンポーネントからコンポーネントを識別するための手段と、
    前記通信セッションからの前記識別されたコンポーネントの前記転送のためにネットワークエンティティに前記識別されたコンポーネントの情報を提供するための手段と、
    を備えるユーザ機器。
18. 転送のために前記識別されたコンポーネントの前記情報として前記識別されたコンポーネントの指定された値を前記ネットワークエンティティに提供するための手段をさらに備え、前記指定された値は、セッションイニシエーションプロトコルメッセージ内の前記複数のメディアコンポーネントのリスティングの順序から導出される、請求項１７に記載のユーザ機器。
19. 転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記ゼロ値とは異なる値を有する別のポート番号とを前記転送のために前記識別されたコンポーネントの前記情報として前記ネットワークエンティティに提供するための手段をさらに備える、請求項１７に記載のユーザ機器。
20. マルチコンポーネント通信セッションのセッション識別子を割り当てるための手段と、
    前記セッション識別子をユーザエンティティに送信するための手段と、
    前記マルチコンポーネント通信セッションからのコンポーネントの転送のために前記ユーザエンティティから前記セッション識別子を受信するための手段と
    を備えるインフラストラクチャ機器。
21. 前記転送のために識別された前記コンポーネントの指定された値を前記ユーザエンティティから受信するための手段をさらに備え、前記指定された値は、前記マルチコンポーネント通信セッションの複数のメディアコンポーネントのリスティングの順序から導出され、リスティングの前記順序は、セッションイニシエーションプロトコルメッセージ内で提供される、請求項２０に記載のインフラストラクチャ機器。
22. 転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記転送を意図される前記コンポーネントについて前記ゼロ値とは異なる値を有する別のポート番号とを前記ユーザエンティティから受信するための手段をさらに備える、請求項２０に記載のインフラストラクチャ機器。
23. プロセッサと、
    前記プロセッサに結合され、セッション識別を受け取り、複数のメディアコンポーネントを含む通信セッションを確立し、前記複数のメディアコンポーネントからのコンポーネントの転送のためにネットワークエンティティに前記セッション識別を送信するように構成された回路網と、
    を備えるユーザ装置。
24. 前記プロセッサおよび前記回路網は、転送のために識別されたコンポーネントとして前記複数のメディアコンポーネントから前記コンポーネントを識別し、前記通信セッションからの前記識別されたコンポーネントの前記転送のためにネットワークエンティティに前記識別されたコンポーネントの情報を提供するようにさらに構成される、請求項２３に記載のユーザ装置。
25. 前記プロセッサおよび前記回路網は、転送のために前記識別されたコンポーネントの前記情報として前記識別されたコンポーネントの指定された値を前記ネットワークエンティティに提供するようにさらに構成され、前記指定された値は、セッションイニシエーションプロトコルメッセージ内の前記複数のメディアコンポーネントのリスティングの順序から導出される、請求項２４に記載のユーザ装置。
26. 前記プロセッサおよび前記回路網は、転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記ゼロ値とは異なる値を有する別のポート番号とを前記転送のために前記識別されたコンポーネントの前記情報として前記ネットワークエンティティに提供するようにさらに構成される、請求項２４に記載のユーザ装置。
27. 前記セッション識別は、ＳＩＰ−ＵＲＩ（セッションイニシエーションプロトコル−Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、電話ＵＲＩ、およびＳＩＰダイアログＩＤ（識別子）からなるグループから選択される、請求項２３に記載のユーザ装置。
28. プロセッサと、
    前記プロセッサに結合され、複数のメディアコンポーネントを含む通信セッションを確立し、転送のために識別されたコンポーネントとして前記複数のセッションコンポーネントからコンポーネントを識別し、前記通信セッションからの前記識別されたコンポーネントの前記転送のためにネットワークエンティティに前記識別されたコンポーネントの情報を提供するように構成された回路網と、
    を備えるユーザ装置。
29. 前記プロセッサおよび前記回路網は、転送のために前記識別されたコンポーネントの前記情報として前記識別されたコンポーネントの指定された値を前記ネットワークエンティティに提供するようにさらに構成され、前記指定された値は、セッションイニシエーションプロトコルメッセージ内の前記複数のメディアコンポーネントのリスティングの順序から導出される、請求項２８に記載のユーザ装置。
30. 前記プロセッサおよび前記回路網は、転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記ゼロ値とは異なる値を有する別のポート番号とを前記転送のために前記識別されたコンポーネントの前記情報として前記ネットワークエンティティに提供するようにさらに構成される、請求項２８に記載のユーザ装置。
31. プロセッサと、
    前記プロセッサに結合され、マルチコンポーネント通信セッションのセッション識別子を割り当て、前記セッション識別子をユーザエンティティに送信し、前記マルチコンポーネント通信セッションからのコンポーネントの転送のために前記ユーザエンティティから前記セッション識別子を受信するように構成された回路網と、
    を備えるインフラストラクチャ装置。
32. 前記プロセッサおよび前記回路網は、前記転送のために識別された前記コンポーネントの指定された値を前記ユーザエンティティから受信するようにさらに構成され、前記指定された値は、前記マルチコンポーネント通信セッションの複数のメディアコンポーネントのリスティングの順序から導出され、リスティングの前記順序は、セッションイニシエーションプロトコルメッセージ内で提供される、請求項３１に記載のインフラストラクチャ装置。
33. 前記プロセッサおよび前記回路網は、転送を意図されない別のコンポーネントについてゼロ値を有するポート番号と、前記転送を意図される前記コンポーネントについて前記ゼロ値とは異なる値を有する別のポート番号とを前記ユーザエンティティから受信するようにさらに構成される、請求項３１に記載のインフラストラクチャ装置。
34. 請求項６に記載の方法を実行するためのコンピュータ可読プログラムコードと共に物理的に具体化されたコンピュータ可読媒体を備えるコンピュータプログラム製品。
35. 請求項９に記載の方法を実行するためのコンピュータ可読プログラムコードと共に物理的に具体化されたコンピュータ可読媒体を備えるコンピュータプログラム製品。

Images