(57)【特許請求の範囲】
【請求項１】
第１訪問先インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）ネットワーク（６）内に存在する発信側加入者のユーザ装置（２）と、第２訪問先ＩＭＳネットワーク（８）内でローミングしている受信側加入者のユーザ装置（４）の間に、通信ネットワーク（１）内の通信セッションを確立する方法であって、
前記第１訪問先ＩＭＳネットワーク（６）から、前記受信側加入者のホームＩＭＳネットワーク（１２）を経由して、前記第２訪問先ＩＭＳネットワーク（８）までの、メディアパスを経由する前記通信セッションのための第１インバイトリクエストであって、前記第１訪問先ＩＭＳネットワーク（６）から、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を経由して、前記第２訪問先ＩＭＳネットワーク（８）までの、前記通信セッションのための制御パスを有した第１インバイトリクエストをルーティングすること（１０４）と、
前記受信側加入者のユーザ装置（４）によって前記通信セッションを確立することと、次いで、
前記第２訪問先ＩＭＳネットワーク（８）内に存在する追加的ＩＭＳネットワークエンティティ（３６、３８）を、前記通信セッションの前記メディアパスの、前記第１訪問先ＩＭＳネットワーク（６）から前記受信側加入者の前記ホームＩＭＳネットワーク（１２）までの部分に挿入し（１０８、１１０）、前記第２訪問先ＩＭＳネットワーク（８）内に存在する追加的ＩＭＳネットワークエンティティ（３６、３８）を、前記通信セッションの前記制御パスの、前記第１訪問先ＩＭＳネットワーク（６）から前記受信側加入者の前記ホームＩＭＳネットワーク（１２）までの部分に挿入することと、
前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を、前記通信セッションの前記メディアパスから除去すること（１１８）とを含み、
前記追加的ＩＭＳネットワークエンティティ（３６、３８）を挿入する前記ステップは、
前記追加的ＩＭＳネットワークエンティティ（３６、３８）が前記メディアパスに挿入されうることを示し、前記第２訪問先ＩＭＳネットワーク（８）の前記追加的ＩＭＳネットワークエンティティ（３６）のドメイン名を含む表示を前記第１訪問先ＩＭＳネットワーク（６）のＩＭＳプロキシ（２４）に提供すること（１０６）を含む、方法。
【請求項２】
前記通信ネットワーク（１）は、ロングタームエボリューションを介しての音声通話（ＶｏＬＴＥ）に基づく通信ネットワークである、請求項１に記載の方法。
【請求項３】
前記追加的ＩＭＳネットワークエンティティ（３６、３８）を挿入すると、前記追加的ＩＭＳネットワークエンティティから、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を経由して前記受信側加入者のユーザ装置（４）へと、信号伝達パスが確立される、請求項１又は２に記載の方法。
【請求項４】
前記第１インバイトリクエストは、前記追加的ＩＭＳネットワークエンティティ（３６、３８）の挿入が前記発信側加入者にサポートされ、かつ／又は、前記第１訪問先ＩＭＳネットワークにサポートされるという表示を含む（１０２）、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記追加的ＩＭＳネットワークエンティティ（３６、３８）を挿入する前記ステップは、
前記第１訪問先ＩＭＳネットワーク（６）の前記ＩＭＳプロキシ（２４）によって、第２インバイトリクエストを、前記追加的ＩＭＳネットワークエンティティ（３６）に送信すること（１０８）と、
前記追加的ＩＭＳネットワークエンティティ（３６）によって、前記第２インバイトリクエストを、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）に転送すること（１１０）とをさらに含み、それによって前記第２インバイトリクエストは、前記追加的ＩＭＳネットワークエンティティ（３８）を通じて転送される、請求項１から４のいずれか一項に記載の方法。
【請求項６】
前記追加的ＩＭＳネットワークエンティティ（３６）は、前記メディアパスをアンカーする（１１２）、請求項５に記載の方法。
【請求項７】
前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を前記メディアパスから除去することに先立って、
前記第２インバイトリクエストに、前記インバイトリクエストは、前記第１訪問先ＩＭＳネットワーク（６）の前記ＩＭＳプロキシ（２４）と前記受信側加入者の前記ホームＩＭＳネットワーク（１２）の間に確立された旧ダイアログに取って代わるという、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）への指令を入れることを含む、請求項５又は６に記載の方法。
【請求項８】
前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を前記メディアパスから除去する前記ステップは、
前記受信側加入者のプロキシコールセッションコントロールファンクション（Ｐ‐ＣＳＣＦ）（２０）によって、前記Ｐ‐ＣＳＣＦ（２０）と前記追加的ＩＭＳネットワークエンティティ（３６）の間の各中継点に関連付けられた各ネットワークエンティティ（２６、２８、３０、３８）は前記メディアパスから除去されることになるという表示を含む更新リクエストを前記追加的ＩＭＳネットワークエンティティ（３６）に送信すること（１１８）を含む、請求項１から７のいずれか一項に記載の方法。
【請求項９】
前記追加的ＩＭＳネットワークエンティティ（３６、３８）は、第１インターコネクトボーダーコントロールファンクション（ＩＢＣＦ）（３６）及び第２ＩＢＣＦ（３８）を含み、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を前記メディアパスから除去する前記ステップの後に、前記第１ＩＢＣＦ（３６）は、ユーザプレーンの前記第１訪問先ＩＭＳネットワーク（６）との通信をハンドリングするための、第１ＩＢＣＦ（３６）に関連付けられた伝送ゲートウェイ（ＴｒＧＷ）を有し、前記第１ＩＢＣＦ（３６）は、前記第１訪問先ＩＭＳネットワーク（６）との制御プレーン通信をハンドリングし、かつ、前記第２ＩＢＣＦ（３８）は、前記制御プレーンの、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）との通信をハンドリングする、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
更に、
通信セッションであって、
前記通信セッションの制御プレーンは、前記第１訪問先ＩＭＳネットワーク（６）と前記発信側加入者の前記ホームＩＭＳネットワーク（１０）の間にルーティングされ、
前記制御プレーンとユーザプレーンは、前記第１訪問先ＩＭＳネットワーク（６）と前記第２訪問先ＩＭＳネットワーク（８）の間に直接ルーティングされ、かつ、
前記制御プレーンは、前記第２訪問先ＩＭＳネットワーク（８）と前記受信側加入者のホームＩＭＳネットワーク（１２）の間にルーティングされる、通信セッションを実行することを含む、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
第１訪問先インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）ネットワーク（６）内に存在する発信側加入者のユーザ装置（２）、及び、第２訪問先ＩＭＳネットワーク（８）内をローミングしており、前記受信側加入者のホームＩＭＳネットワーク（１２）をそれに関連付けている受信側加入者のユーザ装置（４）を含む、通信ネットワーク（１）であって、
前記第１訪問先ＩＭＳネットワーク（６）は、前記第１訪問先ＩＭＳネットワーク（６）から、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を経由して前記第２訪問先ＩＭＳネットワーク（８）までの、前記通信セッションのためのメディアパスを有するように、第１インバイトリクエストをルーティングするよう構成され、
前記第１訪問先ＩＭＳネットワーク（６）は、前記第１訪問先ＩＭＳネットワーク（６）から、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を経由して前記第２訪問先ＩＭＳネットワーク（８）までの、前記通信セッションのための制御パスを有するように、第１インバイトリクエストをルーティングするよう構成され、
前記受信側加入者のユーザ装置（４）は、前記通信セッションを確立するよう構成され、
前記第２訪問先ＩＭＳネットワーク（８）は、次に、追加的ＩＭＳネットワークエンティティ（３６）を、前記通信セッションの前記メディアパスの、前記第１訪問先ＩＭＳネットワーク（６）から前記受信側加入者の前記ホームＩＭＳネットワーク（１２）までの部分に挿入するよう構成され、
前記第２訪問先ＩＭＳネットワーク（８）は、次に、追加的ＩＭＳネットワークエンティティ（３６）を、前記通信セッションの前記制御パスの、前記第１訪問先ＩＭＳネットワーク（６）から前記受信側加入者の前記ホームＩＭＳネットワーク（１２）までの部分に挿入するよう構成され、
前記第１訪問先ＩＭＳネットワーク（６）はＩＭＳプロキシ（２４）であって、前記追加的ＩＭＳネットワークエンティティ（３６、３８）は前記メディアパスに挿入されうるという表示であって、前記第２訪問先ＩＭＳネットワーク（８）の前記追加的ＩＭＳネットワークエンティティ（３６）のドメイン名を含む表示を提供されるよう構成されたＩＭＳプロキシ（２４）を含み、
前記受信側加入者の前記ホームＩＭＳネットワーク（１２）は、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を前記メディアパスから除去するよう構成される、通信ネットワーク（１）。
【請求項１２】
制御プレーンは、前記第１訪問先ＩＭＳネットワーク（６）と前記発信側加入者の前記ホームＩＭＳネットワーク（１０）の間にルーティングされ、
前記制御プレーンとユーザプレーンは、前記第１訪問先ＩＭＳネットワーク（６）と前記第２訪問先ＩＭＳネットワーク（８）の間に直接ルーティングされ、かつ、
前記制御プレーンは、前記第２訪問先ＩＭＳネットワーク（８）と前記受信側加入者の前記ホームＩＭＳネットワーク（１２）の間にルーティングされる、請求項１１に記載の通信ネットワーク（１）。
【請求項１３】
インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）加入者のユーザ装置（４）向けの訪問先ＩＭＳネットワーク（８）内で使用するためのＩＭＳプロキシエンティティ（３６、３８）であって、第１インターコネクトボーダーコントロールファンクション（ＩＢＣＦ）（３６）及び第２ＩＢＣＦ（３８）を含み、
前記第１ＩＢＣＦ（３６）は、前記第１ＩＢＣＦ（３６）を、前記ＩＭＳ加入者のユーザ装置との既存のＩＭＳ通信セッションのメディアルーティングに挿入する（１０８、１１０）よう構成されたアンカーユニット（１５１５）を含み、前記第１ＩＢＣＦ（３６）は更に、表示に応答して、前記第２ＩＢＣＦ（３８）を、前記ＩＭＳ加入者のユーザ装置との既存のＩＭＳ通信セッションの制御パスに挿入するよう構成され、
前記第１ＩＢＣＦ（３６）は更に、前記受信側加入者の前記ＩＭＳ加入者のユーザ装置（４）に関連付けられたホームＩＭＳネットワーク（１２）に向けて送信されることになる、前記第１ＩＢＣＦ（３６）はユーザプレーンを前記ＩＭＳ加入者のユーザ装置へと前記受信側加入者の前記ホームＩＭＳネットワーク（１２）を通過することなくルーティングすることが可能であるという表示を、生成するよう構成された処理ユニット（１５１４）、及び、前記表示を、前記受信側加入者の前記ＩＭＳ加入者のユーザ装置（４）に関連付けられた前記ホームＩＭＳネットワーク（１２）に向けて送信するための送信器（１５１２Ｂ）を含み、
前記第１ＩＢＣＦ（３６）は、ユーザプレーン（１５）の前記第１訪問先ＩＭＳネットワーク（６）との通信をハンドリングするための、第１ＩＢＣＦ（３６）に関連付けられた伝送ゲートウェイ（ＴｒＧＷ）を有し、
前記第１ＩＢＣＦ（３６）は、前記第１訪問先ＩＭＳネットワーク（６）との制御プレーン通信をハンドリングするよう構成され、
前記第２ＩＢＣＦ（３８）は、前記制御プレーンの、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）との通信をハンドリングするよう構成される、ＩＭＳプロキシエンティティ（３６、３８）。
【請求項１４】
訪問先ＩＭＳネットワーク（８）内に存在する受信側加入者に関連付けられたプロキシコールセッションコントロールファンクション（Ｐ‐ＣＳＣＦ）エンティティ（２０）であって、
発信側加入者に関連付けられたＩＭＳネットワーク（６）から、通信セッションを確立するための、前記通信セッションのメディアパスの最適化がサポートされるという表示を含むインバイトリクエストを受信するよう構成された受信器（１５０４Ａ）と、
前記通信セッションを、前記受信側加入者の前記訪問先ＩＭＳネットワーク（８）内の追加的ネットワークエンティティ（３６、３８）を経由して再ルーティングするための、前記追加的ネットワークエンティティが前記メディアパス及び制御パスに挿入されることになるという第１指令を生成するよう構成された処理ユニット（１５０２）と、
前記指令を、前記発信側加入者に関連付けられた前記ＩＭＳネットワーク（６）に向けて送信するよう構成された送信器（１５０４Ｂ）を含み、
前記受信器（１５０４Ａ）は更に、前記受信側加入者の前記訪問先ＩＭＳネットワーク（８）の前記追加的ネットワークエンティティ（３６）はメディアを、前記受信側加入者のホームＩＭＳネットワーク（１２）を通過することなくＰ‐ＣＳＣＦ（２０）に転送することが可能であるという表示を受信するよう構成されており、
前記処理ユニット（１５０２）は更に、前記メディアが前記ホームＩＭＳネットワークを通過しないように、前記メディアパスのアンカーを解除するための、前記受信側加入者の前記ホームＩＭＳネットワーク（１２）向けの第２指令を生成するよう構成されており、
前記送信器（１５０４Ｂ）は更に、前記第２指令を前記受信側加入者の前記ホームＩＭＳネットワーク（１２）に送信するよう構成されており、前記指令は前記追加的ＩＭＳネットワークエンティティ（３６）へと転送される、Ｐ‐ＣＳＣＦエンティティ（２０）。
【発明の詳細な説明】
【技術分野】
【０００１】
発明は、インターネットプロトコルマルチメディアネットワークに関する。発明はまた、かかるネットワーク内で使用するためのネットワークエンティティに関する。より具体的には、発明は、ロングタームエボリューションを介しての音声通話（ＶｏＬＴＥ）に基づく通信ネットワークに関し、かかるネットワークは、音声、映像及びデータメッセージの対話セッションを可能にする能力を備える。
【背景技術】
【０００２】
第３世代パートナーシップ・プロジェクト（３ＧＰＰ）のリリース１１は、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）をローミングしているユーザによって発呼された、セッションイニシエーションプロトコル（ＳＩＰ）セッションのためのメディア転送を最適化する仕組みを導入した。この方法は、３ＧＰＰの中のＲＡＶＥＬ作業項目（３ＧＰＰ  ＴＲ  ２３．８５０：ローカルブレイクアウトを伴うＩＰマルチメディアサブシステムを介しての音声通話のためのローミングアーキテクチャについての研究（「ＲＡＶＥＬ」））において解析された。この研究の結果は、３ＧＰＰ  ＴＳ２３．２２８ｖ１１．３．０に含まれている。本書の図１は、ローミング加入者による発呼側のロングタームエボリューションを介しての音声通話（ＶｏＬＴＥ）セッションのための、最適化されたメディアルーティングの概念的アーキテクチャを示す。
【０００３】
３ＧＰＰのリリース１１によるメディア最適化は、Ａ相手先（すなわち発信側加入者）の訪問先ＩＭＳネットワークとＢ相手先（すなわち受信側加入者）のホームＩＭＳネットワークの間のメディアルーティングに適合する。Ｂ相手先がそのホームＩＭＳネットワークの外部をローミングしている時には、通話のためのユーザプレーンは、Ａ相手先の訪問先ＩＭＳネットワークから、Ｂ相手先のホームＩＭＳネットワークを経由してＢ相手先の訪問先ＩＭＳネットワークへと、ルーティングされることになる。
【０００４】
このメディア転送は、完全に最適化される訳ではない。例えば、Ａ相手先とＢ相手先が両方とも同一の国の中をローミングしている時、メディアは、Ａ相手先の訪問先ＩＭＳネットワークから、Ｂ相手先のホームＩＭＳネットワークを経由してＢ相手先の訪問先ＩＭＳネットワークへとルーティングされることになり、その逆もまた真である。メディアは、訪問先の国からＢ相手先のホームの国へとルーティングされ、訪問先の国へと戻る。この状態は、必要以上のメディアルーティングリソースを使用し、かつ、ＶｏＬＴＥ加入者にとってのローミングのコストを付加すると思われる。
【発明の概要】
【０００５】
発明の一目的は、上記の不利益のうち少なくとも一部を未然に防止して、ローミング加入者向けの通信セッションを確立するための改善された方法を提供することである。ＩＰマルチメディアネットワークのためのネットワークエンティティを提供して汎用性を強化することも目的である。市場は、ローミング時の通信のコスト削減に尽力している。この努力は、個人対個人モバイル通信の望ましい方法に向けてＶｏＬＴＥを発展させるという電気通信産業の目標に照らし、特に重要である。受信側加入者、又は受信側と発信側の両方の加入者がローミングしている時で、特に、発信側加入者と受信側加入者が同一の訪問先の国に存在し、かつ、通信が確立される時、そのセッションのコストは、ローカルのメディア伝送インフラを通じてその通話のユーザプレーンをルーティングすることによって抑制しうる。しかし、現行の３ＧＰＰネットワークアーキテクチャは、これを可能にするものではない。
【０００６】
そのことに関し、発明により、第１訪問先インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）ネットワーク内に存在する、すなわち、かかるネットワークにレジスタされている、発信側加入者のユーザ装置と、第２訪問先ＩＭＳネットワーク内をローミングしている受信側加入者のユーザ装置の間に、通信セッションを確立するための方法が提供される。方法は、発信側加入者に関連付けられた第１訪問先ＩＭＳネットワークから、受信側加入者のホームＩＭＳネットワークを経由して、受信側加入者に関連付けられた第２訪問先ＩＭＳネットワークへと延在するメディアパスを経由する通信セッションのための、第１インバイトリクエストをルーティングすることを含む。第１インバイトリクエストを受信すると、受信側加入者のユーザ装置は通信セッションを確立する。次に、受信側加入者に関連付けられた第２訪問先ＩＭＳネットワーク内に存在する追加的ＩＭＳネットワークエンティティが、通信セッションのメディアパスの、発信側加入者に関連付けられた第１訪問先ＩＭＳネットワークから受信側加入者のホームＩＭＳネットワークへと延在する部分に挿入される。それに続いて、受信側加入者のホームＩＭＳネットワークは、通信セッションのメディアパスから除去される。  
【０００７】
これには、この通信セッションではメディアが、発信側加入者の訪問先ＩＭＳネットワークから、受信側加入者の訪問先ＩＭＳネットワーク内の追加的ＩＭＳネットワークエンティティを経由して受信側加入者のユーザ装置へと、受信側加入者のホームＩＭＳネットワークを通過することなくルーティングされるという利点がある。追加的ＩＭＳネットワークエンティティを挿入すると、追加的ＩＭＳネットワークエンティティから、受信側加入者のホームＩＭＳネットワークを経由して受信側加入者のユーザ装置へと、信号伝達パスが確立される。
【０００８】
本書の中の訪問先ＩＭＳネットワークという用語は、加入者が現在レジスタされているＩＭＳネットワークを表す。本書の中のホームＩＭＳネットワークという用語は、発信側加入者又は受信側加入者がそれぞれ加入者であるＩＭＳネットワークを表す。当然のことながら、発信側加入者のユーザ装置は第１訪問先ＩＭＳネットワーク内をローミングしていることがあり、第１訪問先ＩＭＳネットワークは、発信側加入者のホームＩＭＳネットワークではない。発信側加入者のユーザ装置がホームＩＭＳネットワーク内に存在することも可能であり、その際には、かかるネットワークは、第１訪問先ＩＭＳネットワークとして識別されることになる。発明は、受信側加入者のユーザ装置が、受信側加入者のホームＩＭＳネットワークではない訪問先ＩＭＳネットワーク内をローミングしている、すなわち、かかるネットワーク内に存在する状態に関する。当然のことながら、発信側加入者と受信側加入者が同一のＩＭＳネットワークにレジスタされている、例えば、両方が同一の国の中をローミングしている時、第１訪問先ＩＭＳネットワークと第２訪問先ＩＭＳネットワークは、同一のＩＭＳネットワークとなる。
【０００９】
当然のことながら、発信側加入者のユーザ装置は、加入者の端末のような人間が操作する装置、又は人間以外が操作する装置でありうる。代替的に又は追加的に、受信側加入者のユーザ装置は、加入者の端末のような人間が操作する装置、又は人間以外が操作する装置でありうる。
【００１０】
通信ネットワークは、ロングタームエボリューションを介しての音声通話（ＶｏＬＴＥ）に基づく通信ネットワークでありうる。ＶｏＬＴＥは、ロングタームエボリューション（ＬＴＥ）接続ネットワークを介するＩＭＳ内での基本電話方式である、マルチメディアテレフォニー（ＭＭＴｅｌ）を使用する。ＶｏＬＴＥネットワークは、音声、映像及びデータメッセージの対話セッションを可能にする能力を備える。「ＶｏＬＴＥ」という用語は、元々はＬＴＥを介しての音声セッションを示すために適用されたが、映像及びデータのセッションを可能にすることができるネットワークへと発展した。本書では「ＶｏＬＴＥ」という用語は、音声、映像及びデータのセッションを可能にするネットワークであると理解される。
【００１１】
当然のことながら、発信側加入者のユーザ装置及び／又は受信側加入者のユーザ装置は、特定の使用事例において、ワイドバンドコードディビジョンマルチプルアクセス（Ｗ−ＣＤＭＡ）又はハイスピードパケットアクセス（ＨＳＰＡ）といった非ＬＴＥ接続を使用しうる。  
【００１２】
任意には、第１インバイトリクエストは、追加的ＩＭＳネットワークエンティティの挿入は発信側加入者にサポートされ、かつ／又は、第１訪問先ＩＭＳネットワークにサポートされるという表示を含む。これは、第２訪問先ＩＭＳネットワーク内の、例えばサーバのような他のネットワークエンティティが、発信側加入者及び／又は第１訪問先ＩＭＳネットワークがそのようにサポートしていることを知覚するという利点をもたらす。
【００１３】
追加的ＩＭＳネットワークエンティティを挿入するステップは、第２訪問先ＩＭＳネットワークのインターコネクトボーダーコントロールファンクション（ＩＢＣＦ）のようなＩＭＳプロキシに、受信側加入者のホームＩＭＳネットワークにより、又は受信側加入者により、要求ヘッダ内の所定のオプションタグのような、追加的ＩＭＳネットワークエンティティがメディアパス及び制御パスに挿入されることになっているという表示を提供することを含む。かかる表示は、受信側加入者のＰ−ＣＳＣＦによって提供されうる。ここでは、表示は、第２訪問先ＩＭＳネットワークの追加的ＩＭＳネットワークエンティティのドメイン名を含む。このステップは更に、第１訪問先ＩＭＳネットワークのＩＭＳプロキシによって、第２インバイトリクエストを、追加的ＩＭＳネットワークエンティティに、例えばそれに含まれる（第１インターコネクトボーダーコントロールファンクション、ＩＢＣＦ、のような）ＩＭＳプロキシに、伝送することを含む。このステップは、追加的ＩＭＳネットワークエンティティによって、第２インバイトリクエストを、受信側相手先のホームＩＭＳネットワークに、例えばそのＩＭＳプロキシに転送することを含み、それによって第２インバイトリクエストが、追加的ＩＭＳネットワークエンティティを通じて転送される。
【００１４】
追加的ＩＭＳネットワークエンティティ（例えばその第１ＩＢＣＦ）はメディアパスを、例えば追加的ＩＭＳネットワークエンティティに関連付けられた伝送ゲートウェイ（ＴｒＧＷ）内にアンカーする。これは、メディアパスのアンカーが、受信側加入者のホームＩＭＳネットワークから、受信側加入者に関連付けられた第２訪問先ＩＭＳネットワークへと移動されうるという利点をもたらす。
【００１５】
受信側加入者のホームＩＭＳネットワークのメディアパスからの除去に先立ち、受信側相手先のホームＩＭＳネットワーク（のＩＭＳプロキシ）に対する（例えばヘッダを置換するダイアログ内の）表示が、第２インバイトリクエストに含まれる。前記表示により、前記第２インバイトリクエストは、第１訪問先ＩＭＳネットワークのＩＭＳプロキシと受信側加入者のホームＩＭＳネットワークの間に確立された、旧ダイアログを置換することになる。
【００１６】
受信側加入者のホームＩＭＳネットワークをメディアパスから除去するステップは、受信側加入者のプロキシコールセッションコントロールファンクション（Ｐ−ＣＳＣＦ）によって、追加的ＩＭＳネットワークエンティティに、例えばそれに含まれる（第１ＩＢＣＦのような）ＩＭＳプロキシに、Ｐ−ＣＳＣＦと追加的ＩＭＳネットワークエンティティの間の各中継点に関連付けられた各ネットワークエンティティが、メディアパスから除去されることになるという（要求ヘッダ内の所定のオプションタグのような）表示を含む、更新リクエストを伝送することを含む。
【００１７】
第１インバイトリクエストは、第１訪問先ＩＭＳネットワークから、受信側加入者のホームＩＭＳネットワークを経由して第２訪問先ＩＭＳネットワークへと延在する、通信セッションのための制御パスを有し、挿入するステップは、第２訪問先ＩＭＳネットワーク内に存在する追加的ＩＭＳネットワークエンティティを、通信セッションの制御パスの、第１訪問先ＩＭＳネットワークから受信側加入者のホームＩＭＳネットワークへと延在する部分に挿入することを含む。ゆえに、制御パスは、第１訪問先ＩＭＳネットワークから第２訪問先ＩＭＳネットワークまでメディアパスに従うが、制御パスは、受信側加入者のホームＩＭＳネットワークを通過することにもなる。
【００１８】
一実施形態では、追加的ＩＭＳネットワークエンティティは、第１ＩＢＣＦ及び第２ＩＢＣＦを含み、受信側加入者のホームＩＭＳネットワークをメディアパスから除去するステップの後に、第１ＩＢＣＦは、第１訪問先ＩＭＳネットワークとのユーザプレーン通信をハンドリングするために、第１ＩＢＣＦに関連付けられたＴｒＧＷを有し、第１ＩＢＣＦは、第１訪問先ＩＭＳネットワークとの制御プレーン通信をハンドリングし、かつ、第２ＩＢＣＦは、受信側加入者のホームＩＭＳネットワークとの制御プレーン通信をハンドリングする。
【００１９】
発明によって通信セッションが確立された後、通信セッションのルーティングパスは下記のようになる。通信セッションの制御プレーンは、第１訪問先ＩＭＳネットワークと発信側加入者のホームＩＭＳネットワークの間に、ユーザプレーンを発信側加入者のホームＩＭＳネットワーク内にアンカーすることなくルーティングされる。制御プレーンとユーザプレーンは、インターネットプロトコルパケットエクスチェンジ（ＩＰＸ）を通じて、第１訪問先ＩＭＳネットワークと第２訪問先ＩＭＳネットワークの間で直接に、受信側加入者のホームＩＭＳネットワークを通過することなくルーティングされる。制御プレーンは、第２訪問先ＩＭＳネットワークと受信側加入者のホームＩＭＳネットワークの間に、ユーザプレーンを受信側加入者のホームＩＭＳネットワーク内にアンカーすることなくルーティングされる。
【００２０】
発明は、第１訪問先インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）ネットワーク内に存在する発信側加入者のユーザ装置、及び、第２訪問先ＩＭＳネットワーク内をローミングし、受信側加入者のホームＩＭＳネットワークをそれに関連付けている受信側加入者のユーザ装置を含む、ＶｏＬＴＥに基づく通信ネットワークのような通信ネットワークにも関する。第１訪問先ＩＭＳネットワークは、第１訪問先ＩＭＳネットワークから、受信側加入者のホームＩＭＳネットワークを経由して第２訪問先ＩＭＳネットワークまでの、通信セッションのためのメディアパスを有するように、第１インバイトリクエストをルーティングするよう配設される。受信側加入者のユーザ装置は、通信セッションを確立するよう配設される。第２訪問先ＩＭＳネットワークは、追加的ＩＭＳネットワークエンティティを、通信セッションのメディアパスの、及び任意で制御パスの、第１訪問先ＩＭＳネットワークから受信側加入者のホームＩＭＳネットワークまでの部分に、挿入するよう配設される。受信側加入者のホームＩＭＳネットワークは、受信側加入者のホームＩＭＳネットワークをメディアパスから除去するよう配設される。ゆえに、メディアは、第１訪問先ＩＭＳネットワークから第２訪問先ＩＭＳネットワーク内の追加的ＩＭＳネットワークエンティティを経由して、受信側加入者のユーザ装置へと、受信側加入者のホームＩＭＳネットワークを通過することなくルーティングされうる。
【図面の簡単な説明】
【００２１】
発明について、以下の図面を参照しつつ、非限定的な実施例を用いて更に説明する。
【図１】先行技術の通信ネットワークを概略的に図示したものである。
【図２】先行技術の通信ネットワークを概略的に図示したものである。
【図３】発明による通信ネットワークの一部を概略的に図示したものである。
【図４】通信ネットワークを概略的に図示したものである。
【図５Ａ】通信ネットワークを概略的に図示したものである。
【図５Ｂ】通信ネットワークを概略的に図示したものである。
【図５Ｃ】通信ネットワークを概略的に図示したものである。
【図６】通信ネットワークを概略的に図示したものである。
【図７】通信ネットワークを概略的に図示したものである。
【図８】通信ネットワークの一部を概略的に図示したものである。
【図９】通信ネットワークの一部におけるメッセージの流れを概略的に図示したものである。
【図１０】通信ネットワークの一部を概略的に図示したものである。
【図１１】通信ネットワークの一部におけるメッセージの流れを概略的に図示したものである。
【図１２】通信ネットワークの一部を概略的に図示したものである。
【図１３】通信ネットワークの一部を概略的に図示したものである。
【図１４】プロセスを示すフロー図である。
【００２２】
図面では、同じ図示番号は同じエンティティやプロセスを表す。
【発明を実施するための形態】
【００２３】
第３世代パートナーシップ・プロジェクト（３ＧＰＰ）のリリース１１は、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）をローミングしているユーザによって発呼された、セッションイニシエーションプロトコル（ＳＩＰ）セッションのためのメディア転送を最適化する仕組みを導入した。この方法は、３ＧＰＰの中のＲＡＶＥＬ作業項目（３ＧＰＰ  ＴＲ２３．８５０：ローカルブレイクアウトを伴うＩＰマルチメディアサブシステムを介しての音声通話のためのローミングアーキテクチャについての研究（「ＲＡＶＥＬ」））において解析された。この研究の結果は、３ＧＰＰ  ＴＳ２３．２２８ｖ１１．３．０に含まれている。図１は、ローミング加入者による発呼側のロングタームエボリューションを介しての音声通話（ＶｏＬＴＥ）セッションのための、最適化されたメディアルーティングの概念的アーキテクチャを示す。ＶｏＬＴＥネットワークは、音声、映像及びデータメッセージの対話セッションを可能にする能力を備える。「ＶｏＬＴＥ」という用語は、元々はＬＴＥを介しての音声セッションを示すために適用されたが、映像及びデータのセッションを可能にすることができるネットワークへと発展した。本書では「ＶｏＬＴＥ」という用語は、音声、映像及びデータのセッションを可能にするネットワークであると理解される。
【００２４】
ローミングしているＶｏＬＴＥ加入者２によって確立されるＳＩＰセッションの制御プレーンは、Ａ相手先の訪問先ＩＭＳネットワーク６から、Ａ相手先のホームＩＭＳネットワーク１０へとルーティングされ、次いで、Ａ相手先の訪問先ＩＭＳネットワーク６へと戻る。このＳＩＰセッションのためのユーザプレーンは、Ａ相手先のホームＩＭＳネットワーク１０内にアンカーされず、すなわち、ユーザプレーンはＡ相手先のホームＩＭＳネットワーク１０を通過しない。次いで制御プレーン及びユーザプレーンは共に、相手先ＢのホームＩＭＳネットワーク１２にルーティングされる。このルーティングは、ＩＰインターコネクトネットワーク（ＩＰＸ）３４を通じて行われる。ＩＰＸは、当業者である読者には既知であり、ここで更なる詳細について取り扱うことはない。ＩＰＸにあまりなじみがないのであれば、特に、ＧＳＭＡ  ＰＲＤ  ＩＲ．６５ＩＭＳローミング＆インターワーキングガイドライン、及び、サービスプロバイダ＆ＧＲＸ／ＩＰＸプロバイダ向けＧＳＭＡ  ＰＲＤ  ＩＲ．６７ＤＮＳ／ＥＮＵＭガイドラインを参照しうる。
【００２５】
図１では、音声メディア又は映像メディアを搬送する、このＳＩＰセッションのためのユーザプレーンは、ＩＰＸ３４を通過しつつ、その同じＩＰＸを通じて、ユーザプレーンの関連制御プレーンに伴われている。同時に、Ａ相手先のホームＩＭＳネットワーク１０は、制御プレーンがＡ相手先のホームＩＭＳネットワーク１０を通じてルーティングされ、次いでＡ相手先の訪問先ＩＭＳネットワーク６へと戻ることから、ＳＩＰセッションを制御し続ける。
【００２６】
３ＧＰＰのリリース１１によるメディア最適化は、Ａ相手先の訪問先ＩＭＳネットワーク６とＢ相手先のホームＩＭＳネットワーク１２の間の、メディアルーティングに適合する。Ｂ相手先がそのホームＩＭＳネットワーク１２の外部をローミングしている時には、通話のためのユーザプレーンは、Ａ相手先の訪問先ＩＭＳネットワーク６から、Ｂ相手先のホームＩＭＳネットワーク１２を経由してＢ相手先の訪問先ＩＭＳネットワーク８へと、ルーティングされることになる。  
【００２７】
図２は、かかるＳＩＰセッションを概略的に図示する。図２は、完全なネットワークアーキテクチャを提供することを意図しておらず、３ＧＰＰのリリース１１による最適化されたメディア転送の概念の理解に適するエンティティを示している。「Ｐ」と記されたボックス２２、２４、２６、２８、３０、３２は、制御プレーン構成要素とユーザプレーン構成要素、例えば、インターコネクトボーダーコントロールファンクション（ＩＢＣＦ）と伝送ゲートウェイ（ＴｒＧＷ）を備えるセッションボーダーゲートウェイを表す。マルチメディアテレフォニー（ＭＭＴｅｌ）アプリケーションサーバ（ＡＳ）は、明示的に示されてはいないが、ＭＭＴｅｌＡＳ、並びにサービスセントラライゼーションアンドコンティニュイティアプリケーションサーバ（ＳＣＣ−ＡＳ）はサービングコールセッションコントロールファンクション（Ｓ−ＣＳＣＦ）に接続されると理解される。また、訪問先ＩＭＳネットワーク内のアクセストランスファーコントロールファンクション（ＡＴＣＦ）及び、アクセストランスファーゲートウェイ（ＡＴＧＷ）のようなエンティティも示されていない。
【００２８】
ＳＩＰセッションが確立されると、Ａ相手先のホームＩＭＳネットワーク１０内のＳ−ＣＳＣＦ１４と、Ａ相手先の訪問先ＩＭＳネットワーク６内のプロキシコールセッションファンクション（Ｐ−ＣＳＣＦ）１８は協働し、その結果、Ｓ−ＣＳＣＦ１４は、メディアをホームＩＭＳネットワーク１０内にアンカーすることなしに、すなわち、メディアパスがホームＩＭＳネットワーク１０を通過することを要せずに、ＳＩＰセッションが訪問先ＩＭＳネットワーク６へと戻るようルーティングしうることになる。次いでＳＩＰセッションの確立は、ＩＰＸ３４を通じて、Ｂ相手先のホームＩＭＳネットワーク１２に向けて（或いは、Ｂ相手先がサーキットスイッチト（ＣＳ）加入者である場合は、Ｂ相手先のＣＳネットワークへと）、継続する。
【００２９】
ＩＰＸ３４は、上記の説明、及び図１と図２の中ではＩＭＳオペレータがそれを通じて接続されうる相互接続ネットワークを表す「クラウド」として、提示されている。実際には、オペレータは一又は複数のＩＰＸに基づく相互接続を使用しうる。異なるＩＰＸネットワークが、異なるパートナーＩＭＳネットワークに向けて使用されうる。この区別は、本書では更に説明されることはないが、知識ある読者は理解していることが前提とされる。
【００３０】
図１及び図２と共に説明されたメディア転送は、完全に最適化されている訳ではない。例えば、Ａ相手先とＢ相手先が両方とも同一の国の中をローミングしている時、メディアは、Ａ相手先の訪問先ＩＭＳネットワーク６から、Ｂ相手先のホームＩＭＳネットワーク１２を経由してＢ相手先の訪問先ＩＭＳネットワーク８へとルーティングされることになり、その逆もまた真である。メディアは、訪問先の国からＢ相手先のホームの国へとルーティングされ、訪問先の国へと戻る。この望ましからざる状態は、必要以上のメディアルーティングリソースを使用し、かつ、ＶｏＬＴＥ加入者にとってのローミングの不必要なコストを付加増加すると思われる。
【００３１】
図４は、発明による、ＶｏＬＴＥに基づく通信ネットワークにおける、発信側Ａ相手先加入者２及び受信側Ｂ相手先加入者４のための最適化されたメディア転送を、概略的に図示する。Ａ相手先２とＢ相手先４の間に確立されている通信セッションは、下記の特徴を有する。制御プレーンは、Ａ相手先２の訪問先ＩＭＳネットワーク６とＡ相手先２のホームＩＭＳネットワークの間にルーティングされる。ここでは、ユーザプレーンはホームＩＭＳネットワーク１０を通過せず、すなわち、ユーザプレーンはＡ相手先のホームＩＭＳネットワーク１０内にアンカーされない。本書の中の訪問先ＩＭＳネットワークという用語は、加入者が現在レジスタされているＩＭＳネットワークを表す。本書の中のホームＩＭＳネットワークという用語は、発信側Ａ相手先が（又は受信側Ｂ相手先が、それぞれ）加入者であるＩＭＳネットワークを表す。当然のことながら、Ａ相手先のユーザ装置が訪問先ＩＭＳネットワーク６内をローミングしている時、訪問先ＩＭＳネットワーク６は、Ａ相手先のホームＩＭＳネットワーク１０とは異なるＩＭＳネットワークである。Ａ相手先のユーザ装置がそのホームＩＭＳネットワーク内に存在する場合には、Ａ相手先の訪問先のＩＭＳネットワーク６とＡ相手先のホームＩＭＳネットワーク１０が同一のＩＭＳネットワークであることも可能である。
【００３２】
制御プレーンとユーザプレーンは、ＩＰＸ３４を通じて、Ａ相手先の訪問先ＩＭＳネットワーク６とＢ相手先の訪問先ＩＭＳネットワーク８の間に確立される。制御プレーンは、Ｂ相手先の訪問先ＩＭＳネットワーク８とＢ相手先のホームＩＭＳネットワーク１２の間にルーティングされる。ここでは、ユーザプレーンはホームＩＭＳネットワーク１２を通過せず、すなわち、ユーザプレーンはＢ相手先のホームＩＭＳネットワーク１２内にアンカーされない。  
【００３３】
図４及び上記の説明は、通話が確立する時の状態におけるＳＩＰセッションを反映している。結果として生じるこの状態は、下記の所望の態様をもたらす。通話のためのメディア、例えば音声及び／又は映像は、Ａ相手先２とＢ相手先４の間に、至適にルーティングされる。Ａ相手先のホームＩＭＳネットワーク１０は、通話を制御する。この制御は、Ａ相手先のホームＩＭＳネットワーク１０内のＳ−ＣＳＣＦ１４に接続されたＭＭＴｅｌ  ＡＳに、また潜在的には、ＭＭＴｅｌ  ＡＳからのノースバウンドインターフェースを通じてＭＭＴｅｌ  ＡＳに接続された付加価値サービスノードに属する。Ｂ相手先４のホームＩＭＳネットワーク１２は、通話を制御する。この制御は、Ｂ相手先のホームＩＭＳネットワーク１２内のＳ−ＣＳＣＦ１６に接続されたＭＭＴｅｌ  ＡＳに、また潜在的には、ＭＭＴｅｌ  ＡＳからのノースバウンドインターフェースを通じてＭＭＴｅｌ  ＡＳに接続された付加価値サービスノードに属する。
【００３４】
発明の基本概念により、Ａ相手先２とＢ相手先４の間の通信セッションが一旦確立すると、ＳＩＰセッションは、Ａ相手先の訪問先ＩＭＳネットワーク６とＢ相手先の訪問先ネットワーク８の間に直接ルーティングされるように変更され、メディアがＢ相手先のホームＩＭＳネットワーク１２内にアンカーされることはないということになる。かかる通信セッションがいかにして確立されるかについて、以下に説明する。
【００３５】
本発明による方法は、ＢＯＲとは根本的に異なる。通話が（ローミングしている）ＩＭＳのＡ相手先とローミングしているＩＭＳのＢ相手先の間に確立されている時、通話に関与する２つの相手先の間のメディアプレーンは最適化されることになる一方で、制御プレーンは、発信側相手先と受信側相手先のそれぞれのホームネットワークを通過するままにされる。ゆえに、Ａ相手先とＢ相手先向けのそれぞれの電話方式のサーバは、通話を完全に制御し続ける。
【００３６】
下記に、機能的アーキテクチャを説明する。実際的な配置では、２つ以上の機能的エンティティが組み合わされて単一のノードになりうる。かかる組み合わせは、提案された方法の原理の逸脱を構成しない。エンドツーエンドのＳＩＰセッションに通常要求される全ての詳細が、下記に反映されている訳ではない。  
【００３７】
Ａ相手先は、第１インバイトリクエストをＢ相手先へとルーティングする（図１４のステップ１０４を参照）。訪問先ＩＭＳネットワーク６内のＡ相手先のユーザ装置又はネットワークエンティティは、それが最適化されたメディアルーティングをサポートすることを、（第１）インバイトリクエスト内に示す（図１４のステップ１０２を参照）。Ａ相手先２によって確立された通信セッションのデスティネーションは、セッションがアクティブ状態に到達する時、すなわち、Ａ相手先２からＢ相手先４に向けて送信されたインバイトの結果、Ｂ相手先４の一又は複数の端末からの２００  Ｏｋ最終応答がもたらされる時に、既知となる。しかし、Ｂ相手先４の一端末が２００  Ｏｋ最終応答を送信すると、図２及び図４に示すように、ＳＩＰセッションは確立される。その時点において、下記の変更のＳＩＰセッションへの適用が可能でなくなるということは明白である（１）ＳＩＰセッションのルーティングの：「訪問先ＩＭＳネットワーク（Ａ）６−ホームＩＭＳネットワーク（Ｂ）１２−訪問先ＩＭＳネットワーク（Ｂ）８」から「訪問先ＩＭＳネットワーク（Ａ）６−訪問先ＩＭＳネットワーク（Ｂ）８」への変更、及び、（２）メディアのアンカーの：「メディアがＢ相手先のホームＩＭＳネットワーク１２内にアンカーしている状態」の、「メディアがＢ相手先のホームＩＭＳネットワーク１２内にアンカーしていない状態」への変更。
【００３８】
図５Ａから５Ｃは、上述のような所望の状態を実現するための２段階アプローチを示す。図５Ｃの状況に到達するための方法が、ローミングしている２つのＶｏＬＴＥ加入者間に、図６によるユーザプレーンの最適化なしで通話が確立される時の、より詳細なＳＩＰ信号伝達フローをまず描くことで説明される。
【００３９】
図６は概念的なアーキテクチャを示す。例えばＶｏＬＴＥ加入者の接続ネットワークは、図示されていない。当然のことながら、いくつかの実施形態では、Ａ相手先及び／又はＢ相手先のユーザ装置は、非ＶｏＬＴＥ接続ネットワークに使用されうる。インテロゲーティングコールセッションコントロールファンクション（Ｉ−ＣＳＣＦ）１６Ａによるホーム加入者サーバ（ＨＳＳ）対話も図示されていない。上述のように、異なる「ＩＰＸクラウド」は、一配置状況においては、１つのＩＰＸネットワーク３４、又は複数のＩＰＸネットワークでありうる。
【００４０】
通話のためのメディアパスは、Ｂ相手先のホームＩＭＳネットワーク１２を通じて確立され、メディアパスはそこから、Ｂ相手先の訪問先ＩＭＳネットワークへとルーティングされる。ネットワーク境界を横断するＳＩＰ信号伝達は、インターコネクトボーダーコントロールファンクション（ＩＢＣＦ）４２、４４、４６、４８、２４、２６、２８、３０を通過する。ネットワーク境界を横断するメディアは、伝送ゲートウェイ（ＴｒＧＷ）２４、２６、２８、３０を通過する。図示されているＩＢＣＦ（任意でＴｒＧＷを含む）は、機能構成要素を表す。図３は、通信ネットワークの一部を概略的に図示する。Ａ相手先２の訪問先ＩＭＳネットワーク６とＡ相手先２のホームＩＭＳネットワーク１０の間のＳＩＰ信号伝達は、ＩＭＳネットワーク６、１０のそれぞれにおいて、同一のＩＢＣＦ４２／４８、４４／４６を通過しうる。
【００４１】
図６のＳＩＰセッションは、通話がＢ相手先４によってそのＶｏＬＴＥ端末上で応答されている場合の、第１インバイトトランザクションに関するＳＩＰセッションである。Ｉ−ＣＳＣＦ  １６Ａは、第１インバイトトランザクションの後、ＳＩＰセッションから離脱することになる。ＳＩＰセッションがアクティブになる前に、発信側相手先２に向けて通告が発されることがありうる。また、（接続ネットワークのための）リソース予約が行われうる。ゆえに、一又は複数の早期ダイアログが、発信側相手先２に向けて確立されている可能性がある。最終的に、２００  Ｏｋが、受信側相手先４から発信側相手先２に向けて送信されることになる。
【００４２】
受信側Ｂ相手先４から発信側Ａ相手先２への２００  Ｏｋの返送は、図６に示すように、ＳＩＰセッションがアクティブＳＩＰセッションになるという効果を有する。メディアパスは、第１インバイトトランザクション中に定義された。アクティブになっているＳＩＰセッションと共に、メディアは定義されたメディアパスを貫流し始めることになる。
【００４３】
ここで通話は応答され、ＳＩＰ信号伝達及びメディアパスは、図７に示すようなルーティングを辿るべきである。図７に描写されたネットワーク状況は、図６に描写されたネットワーク状況とは、下記のように異なる。Ａ相手先の訪問先ＩＭＳネットワーク６とＢ相手先のホームＩＭＳネットワーク１２の間のＳＩＰセッションは、Ｂ相手先４の訪問先ＩＭＳネットワーク８内の追加的ＩＭＳ相互接続ポイントを経由してルーティングされる。この「相互接続ポイント」は、ＩＢＣＦ／ＴｒＧＷの組み合わせ３６、及び、Ｂ相手先４の訪問先ＩＭＳネットワーク８内のＩＢＣＦ３８によって形成される。メディアはＢ相手先のホームＩＭＳネットワーク１２内にアンカーされず、すなわち、メディアは、Ｂ相手先のホームＩＭＳネットワーク１２を通過しなくなる。
【００４４】
この状態を実現するために、図６のネットワーク状況は、図７のネットワーク状況へと移行する。そのことに関し、下記のステップが実行される。
【００４５】
１．Ａ相手先のＵＥ２とＢ相手先のＵＥ４（通話が応答されるＵＥ）の間の第１インバイトトランザクションが完了すると、新たなＳＩＰ信号伝達パスが確立される必要がある。この実施例では、２つの追加的ＳＩＰプロキシ（Ｂ相手先の訪問先ＩＭＳネットワーク８内の２つのＩＢＣＦ３６、３８）がＳＩＰパスに付加される。このステップの効果は、Ａ相手先２とＢ相手先４のＵＥの間のＳＩＰセッションが、Ａ相手先の訪問先ＩＭＳネットワーク６とＢ相手先の訪問先ＩＭＳネットワーク８の間に直接確立されることである。
【００４６】
２．Ｂ相手先のホームＩＭＳネットワーク１２内のＩＢＣＦ２６、２８は、メディアパスのそれらのアンカーを落とすものとする。ゆえに、メディアパスは、Ｂ相手先のホームＩＭＳネットワーク１２を通過することを要しなくなる。
【００４７】
上述のＳＩＰ信号伝達とメディアパス最適化は、通話が一旦確立すると行われる。通信セッションがいかにして確立されることになる（必要がある）かが明らかなのは（Ｂ相手先による）通話応答においてのみであることが、理論的根拠である。通話が応答されない限り、Ｂ相手先が非ＳＩＰ電話で通話に応答すること、又は、通話がボイスメール等に転送されることは、依然として可能である。かかる場合において、通話状況は異なることになり、ＳＩＰ信号伝達とメディアパス最適化は適用されるべきではない。
【００４８】
Ａ相手先２とＢ相手先４の間のＳＩＰセッションがエンドツーエンドで確立される時には、記録ルートヘッダは、それぞれのエンドポイントの間で交換されている。当然のことながら、ＳＩＰプロキシの一部は、バックツーバックユーザエージェント（Ｂ２ＢＵＡ）としての役割を果たすことになり、そのため、記録ルートヘッダの交換は、完全にエンドツーエンドという訳ではない。その代わりに、記録ルートヘッダの交換は次いで、Ｂ２ＢＵＡからＢ２ＢＵＡまでとなる。
【００４９】
図８は、２つのＳＩＰエンティティ、ＩＢＣＦ３６とＩＢＣＦ３８、のＳＩＰ信号伝達パスへの付加を描写している。図８は、ＳＩＰパスのための２つの新たなＳＩＰエンティティ３６、３８に隣接する２つのＳＩＰエンティティ２４、２６のみを示す。ＳＩＰセッションが確立すると、すなわち、２００  Ｏｋが発信側相手先２に向けてルーティングされている時に、ＳＩＰパスは図６に描写したようになる。ここで、ＳＩＰパスのＩＢＣＦ２４とＩＢＣＦ２６の間の区域は、ＩＢＣＦ３６とＩＢＣＦ３８を通過するＩＢＣＦ２４とＩＢＣＦ２６の間のＳＩＰパス区域によって、置換されるものとする。図９は、これがいかにして達成されるかという実施例を示す。  
【００５０】
ステップ９０１では、ＩＢＣＦ２４からの第１インバイトリクエストに応答して、２００  ＯｋがＩＢＣＦ２６で、遠隔エンド（Ｂ相手先の端末）から受信され、２００  Ｏｋは、ＳＩＰセッションの置換が適用されるものとするという表示を包含する（図１４のステップ１０６を参照）。かかる表示の一例は、
Ｌｏｃａｌ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇ：Ｔｒｕｅ、である。
【００５１】
この表示は、Ｂ相手先４の訪問先ＩＭＳネットワーク８のＩＭＳドメイン名（「領域（ｒｅａｌｍ）」）も含む。例としては、：
Ｌｏｃａｌ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇ：Ｔｒｕｅ；
ｒｅａｌｍ＝ｉｍｓ．ｍｎｃ７２０．ｍｃｃ３０２．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ、である。  
【００５２】
この表示及びこの領域は、Ｂ相手先のＰ−ＣＳＣＦ２０により２００  Ｏｋ内に含まれた。そのことに関し、Ｐ−ＣＳＣＦ２０のプロセッサ１５０２は、受信側加入者の訪問先ＩＭＳネットワーク８内のＩＢＣＦ３６を経由して通信セッションを再ルーティングするための、第１指令を生成するよう配設される。Ｐ−ＣＳＣＦ２０の入出力（Ｉ／Ｏ）ユニット１５０４の送信器１５０４Ｂは、この第１指令を、例えば２００  Ｏｋ内の表示として、Ａ相手先の訪問先ＩＭＳネットワークに向けて送信する。２００  Ｏｋ内のセッションディスクリプションプロトコル（ＳＤＰ）応答は、下り回線メディアプロキシの、メディアストリームのためのＩＰアドレスを包含する。
【００５３】
ＳＤＰネゴシエーションは、２００  Ｏｋに先立って完了されていることがある。ＳＤＰ応答は、例えば１８３セッションプログレス内で、転送されていることがある。その場合、その段階までネゴシエーションされたＳＤＰが使用されるものとする
【００５４】
複数のＳＤＰ応答が、発信側相手先に向けて返送されているということが可能である。これは、複数の早期ＳＩＰダイアログが発信側相手先２に向けて確立された時に起こりうる。第１インバイトトランザクションのために２００  Ｏｋが送信される時、２００  Ｏｋは、それまでに確立されたダイアログのうちの１つに関する。そのダイアログのＳＤＰが使用されるものとする。そのＳＤＰは、１８３セッションプログレス内、又は、このダイアログのための２００  Ｏｋ内で受信されうる。
【００５５】
第１インバイトがＳＤＰオファーを包含しない時には、受信側相手先４は、２００  Ｏｋ内、又は１８３セッションプログレス内でＳＤＰオファーを提供する。またかかる場合には、受信側相手先からの２００  Ｏｋの時点で適用可能なＳＤＰが使用されるものとする。
【００５６】
ステップ９０２では、この第１インバイトトランザクションのためにＩＢＣＦ２６によって保存された経由ヘッダに基づいて、２００  Ｏｋが通常通り上り回線に転送される。ＳＩＰセッションの置換が適用されるものとするという表示は、２００  Ｏｋ内に保持される。２００  Ｏｋ内のＳＤＰ応答は、下り回線メディアプロキシの、メディアストリームのためのＩＰアドレスを包含する。ＩＢＣＦ２６は、透過的Ｂ２ＢＵＡとしての役割を果たし、関連付けられた一ＴｒＧＷ内にメディアストリームをアンカーする。
【００５７】
ステップ９０３では、ＩＢＣＦ２４は、ＳＩＰセッションの置換をサポートし、そのため、要求に応じて、ＳＩＰセッション区域置換を適用することになる。これに関し、ＩＢＣＦ２４は、このＳＩＰセッションに適用可能な遠隔連絡アドレスに、第２インバイトリクエストを送信する。そのことに関し、ＩＢＣＦ２４のプロセッサ１５０６は、ＩＢＣＦ２６に向けて送信されることになる、第２インバイトリクエストを生成するよう配設されるＩＢＣＦ２４の一Ｉ／Ｏユニットは、第２インバイトを送信するための送信器１５０８Ｂを含む。ＩＢＣＦ２４に関して、遠隔連絡アドレスはＩＢＣＦ２６のアドレスである（図１４のステップ１０８を参照）。ＩＢＣＦ２４はインバイト内に、Ｂ相手先４の訪問先ＩＭＳネットワーク８のＩＭＳドメインであるルートヘッダを含む。ＩＢＣＦ２４は、第２インバイトリクエスト内にダイアログ置換ヘッダも含む。このＳＩＰヘッダは、第２インバイトリクエストの受信者に、この第２インバイトリクエストは別の既存のダイアログ、つまり、ダイアログ置換ヘッダに示されたダイアログを置換することを示す。第２インバイトは、（ルートヘッダ内に示された）Ｂ相手先４の訪問先ＩＭＳネットワーク８に向けて発送されることになる（図１４のステップ１１０を参照）。ＩＢＣＦ３６は、Ｂ相手先４の訪問先ＩＭＳネットワーク８のための入来ＩＢＣＦを表す。
【００５８】
第２インバイト内のＳＤＰオファーは、第１インバイト内でＩＢＣＦ２４からＩＢＣＦ２６へと当初オファーされたＳＤＰオファーに等しい。
【００５９】
この実施例では、ＩＰＸ３４は、発信側Ａ相手先２と受信側Ｂ相手先４の間でネゴシエーションされたＳＤＰを、ユーザプレーンプロキシ（伝送ゲートウェイ、ＴｒＧＷ）を通じてメディアをアンカーする可能性がある以外は、修正しない。ＩＢＣＦ２４とＩＢＣＦ３６の間のＳＩＰセッションの再確立のために、ＩＢＣＦ２４とＩＢＣＦ３６の間、並びに、ＩＰＸ３８とＩＢＣＦ２６の間に、ＩＰＸ３４が存在することになる。これらのＩＰＸによるメディアのアンカーは、それぞれのＩＢＣＦにとって透過的である。ここでは、ＩＢＣＦ３８とＩＢＣＦ２６の間のメディアのアンカーは、メディアルーティング最適化手順全体の一部として、次のステップで行われることにはならないことが、既に留意されている。
【００６０】
ステップ９０４では、ＩＢＣＦ３６は、要求ＵＲＩに示されるように、Ｉ／Ｏユニット１５１０、１５１２（及び、それらに含まれる受信器１５１０Ａ、１５１２Ａ、送信器１５１０Ｂ、１５１２Ｂ）を用いて、第２インバイトリクエストをそのデスティネーション、つまりＩＢＣＦ２６に向けて転送する。第２インバイトは、送出ＩＢＣＦを経由してＢ相手先の訪問先ＩＭＳネットワーク８、すなわちＩＢＣＦ３８へと、ルーティングされることになる。ＩＢＣＦ３６とＩＢＣＦ３８は、実際的な配置では、同一のＩＢＣＦでありうる。ＩＢＣＦ２６は、透過的Ｂ２ＢＵＡとしての役割を果たし、ＴｒＧＷ内にユーザプレーンをアンカーする。これは、ＩＢＣＦ３６からＩＢＣＦ３８へと．送信されたＳＤＰオファー内に反映される。
【００６１】
ステップ９０５では、要求ＵＲＩに示されるように、第２インバイトリクエストがＩＢＣＦ２６に転送される。第２インバイトリクエスト内のダイアログ置換ヘッダは、ＩＢＣＦ２６に、このインバイトリクエストはＩＢＣＦ２４とＩＢＣＦ２６の間に確立されたダイアログを置換すると告知する。ＩＢＣＦ２６は、Ｂ２ＢＵＡとしての役割を果たしており、そのため、この性能をサポートしうる。ＩＢＣＦ３８は、透過的Ｂ２ＢＵＡとしての役割を果たし、ＴｒＧＷ内にユーザプレーンをアンカーする。これは、ＩＢＣＦ３８からＩＢＣＦ２６へと．送信されたＳＤＰオファー内に反映される。  
【００６２】
ステップ９０６からステップ９０８では、第２インバイトリクエストに応答して、２００  Ｏｋが、ＩＢＣＦ２６からＩＢＣＦ２４へと返送され、経由ヘッダに基づいて、通常通りＩＢＣＦ３８及びＩＢＣＦ３６を通過する。第２インバイトリクエスト（ステップ９０３、９０４、９０５）及び関連２００  Ｏｋ（ステップ９０６、９０７、９０８）の結果として、ＩＢＣＦ２４とＩＢＣＦ２６は、ＩＢＣＦ３６とＩＢＣＦ３８を通過するＳＩＰセッション区域を確立している。ＩＢＣＦ３６とＩＢＣＦ３８は、ネットワーク境界に存在することから、透過的Ｂ２ＢＵＡとしての役割を果たすと理解される。
【００６３】
ステップ９０６の２００  Ｏｋ内のＳＤＰ応答は、ステップ９０２でＩＢＣＦ２６からＩＢＣＦ２４へと提供されたＳＤＰ応答に等しい。ＩＢＣＦ３６とＩＢＣＦ３８はメディアを、ステップ９０７の２００  Ｏｋとステップ９０８の２００  Ｏｋを反映したものである、それぞれのＴｒＧＷ内にアンカーする（図１４のステップ１１２を参照）。そのことに関し、ＩＢＣＦ３６のプロセッサ１５１４は、メディアをアンカーするよう配設されたアンカーユニット１５１５を含む。アンカーユニット１５１５は、ＴｒＧＷを、通信セッションのメディアパスの、第１訪問先ＩＭＳネットワーク（６）からＢ相手先のホームＩＭＳネットワーク（１２）へと延在する部分に挿入するよう配設される。
【００６４】
ステップ９０６、９０７及び９０８の２００  Ｏｋの結果として、ＩＢＣＦ２４とＩＢＣＦ２６は、関連付けられたそれらのＴｒＧｗも下記のように更新する。ＩＢＣＦ２４は、ＩＢＣＦ３６に制御されているＴｒＧＷとのユーザプレーン接続のために、そのＴｒＧＷを更新する。ＩＢＣＦ２６は、ＩＢＣＦ３８に制御されているＴｒＧＷとのユーザプレーン接続のために、そのＴｒＧＷを更新する。ステップ９０３からステップ９０８のＳＩＰメッセージは、「置換ＳＩＰセッション区域」の確立に関する。
【００６５】
ステップ９０９では、ＩＢＣＦ２４は上り回線に２００  Ｏｋを送信する。この２００  Ｏｋは、以前に上り回線から受信された第１インバイトリクエストに関する。
【００６６】
ステップ９１０とステップ９１１では、ＩＢＣＦ２４とＩＢＣＦ２６の間のＳＩＰセッション区域が開放される。それは、ＩＢＣＦ３６とＩＢＣＦ３８を通過する、ＩＢＣＦ２４とＩＢＣＦ２６の間のＳＩＰセッション区域によって、置換されている（図１４のステップ１１４を参照）。  
【００６７】
ステップ９１２では、Ａｃｋが、発信側相手先２から通常通り受信される。
【００６８】
ステップ９１３からステップ９１５では、Ａｃｋは、ＩＢＣＦ３６及びＩＢＣＦ３８を通過する、ＩＢＣＦ２４とＩＢＣＦ２６の間に確立されたＳＩＰセッション区域のためのＡｃｋである。
【００６９】
ステップ９１４では、ＩＢＣＦ３６によって生成されるＡｃｋは、メディアパス最適化が適用されるべきであるとの表示を包含する（図１４のステップ１１６を参照）。そのことに関し、ＩＢＣＦ３６のプロセッサ１５１４は、この表示を生成し、表示をＡｃｋ内に挿入するよう配設される。表示を包含するＡｃｋは、ＩＢＣＦ３６の送信器１５１２Ｂによって送信される。この表示は下記の形態を有することがある。：
Ｌｏｃａｌ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇ：Ｔｒｕｅ、である。
【００７０】
このＳＩＰヘッダは、受信側相手先４に向けて、更に下り回線へと伝達される。それは、受信側相手先のＰ−ＣＳＣＦ２０の受信器１５０４Ａによるものであり、次のステップとしてこの通話向けのユーザプレーンを最適化するために使用されることになる。
【００７１】
ステップ９１６では、Ａｃｋは、受信側Ｂ相手先４に向けて、下り回線へと送信される。
【００７２】
ＩＢＣＦ３６及びＩＢＣＦ３８を通過する、ＩＢＣＦ２４とＩＢＣＦ２６の間のＳＩＰセッション区域による、ＩＢＣＦ２４とＩＢＣＦ２６の間のＳＩＰセッション区域の置換（図６参照）は、図１０に描写したようなＳＩＰセッション状況へとつながる。
【００７３】
ＳＩＰセッション区域の置換後のＳＩＰセッション及びメディアルーティングは、図１０に描写したように、所望のエンド状態を構成しない。次のステップは、Ｂ相手先４のホームＩＭＳネットワーク１２とＢ相手先４の訪問先ＩＭＳネットワーク８の間のメディアパスの最適化である。
【００７４】
Ｂ相手先のホームＩＭＳネットワーク１２とＢ相手先の訪問先ＩＭＳネットワーク８の間のメディアアンカーの除去が、図１１の参照を通じて説明される。
【００７５】
ＳＩＰシーケンス図表は、Ｂ相手先のＰ−ＣＳＣＦ２０からＵＥ−Ｂ４へと送信されたＡｃｋで始まる。発信側相手先のＵＥ２からＢ相手先のＰ−ＣＳＣＦ２０までのＡｃｋは、図示されていない。
【００７６】
受信側相手先の訪問先ＩＭＳネットワーク８と受信側相手先のホームＩＭＳネットワーク１２の間のメディアアンカーを除去するためのメディアプレーンの更新は、着信半呼のための最適化である。それは、受信側相手先の訪問先ＩＭＳネットワーク８と受信側相手先のホームＩＭＳネットワーク１２の間の信号伝達に関与する。より具体的には、それは、ＩＢＣＦ３６、ＩＢＣＦ３８、ＩＢＣＦ２６、ＩＢＣＦ２８、ＩＢＣＦ３０及びＰ−ＣＳＣＦ２０とそれらのそれぞれのＴｒＧＷ、この場合にはＩＭＳアクセスゲートウェイ（ＡＧ）との間の、信号伝達及びメディアパス更新に関与する。発信側相手先の訪問先ＩＭＳネットワーク６、並びに発信側相手先のホームＩＭＳネットワーク１０は、受信側相手先のためのこのメディア最適化によって影響を受けない。
【００７７】
ステップ１１０１では、Ｐ−ＣＳＣＦ２０はＡｃｋを、ＵＥ４に向けて既に転送している。
【００７８】
ステップ１１０２では、Ｐ−ＣＳＣＦ２０はメディアパス更新を開始する。このメディアパス更新は、ＩＢＣＦ３６に制御されているＴｒＧＷ（２）と、Ｐ−ＣＳＣＦ２０に制御されているＩＭＳ  ＡＧの間のメディアパスに関する。Ｐ−ＣＳＣＦ２０はこれに関し、このメディアパス更新を開始し、適用するよう、適切に適合する。Ｐ−ＣＳＣＦ２０のプロセッサ１５０２は、メディアがホームＩＭＳネットワークを通過しなくなるように、メディアパスのアンカーを解除するための受信側加入者のホームＩＭＳネットワーク１２向けの第２指令を生成するよう配設される。そのことに関し、Ｐ−ＣＳＣＦ２０のプロセッサ１５０２は、ローカルのメディアルーティングは適合するものとするという表示を生成し、この表示を更新リクエストに含む。Ｐ−ＣＳＣＦ２０の送信器１５０４Ｂは、発信側相手先に向けて更新を送信する。Ｐ−ＣＳＣＦ２０は、透過的Ｂ２ＢＵＡとしての役割を果たしており、そのため、この性能を有する。この表示は、要求ヘッダ内の所定のオプションタグの形態を有する。：
Ｒｅｑｕｉｒｅ：Ｌｏｃａｌ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇ
【００７９】
更新は、標準ＳＩＰルーティングに従って（このＳＩＰセッションに対して有効な記録ルートヘッダ及び連絡ヘッダを使用して）送信され、つまり、ＩＢＣＦ３０がＳＩＰチェーン内の旧ＳＩＰエンティティであったことから、更新はＩＢＣＦ３０に向けて送信される。更新は、インバイトトランザクション中に応じられたＳＤＰ（そのバージョンのＳＤＰは要求に応じてステップ処理される）に等しいＳＤＰオファーを包含する。
【００８０】
ステップ１１０２からステップ１１０６では、更新リクエストは、ＩＢＣＦ３６に到達する前に、ＩＢＣＦ３０、ＩＢＣＦ２８、ＩＢＣＦ２６及びＩＢＣＦ３８を通過する。各中継点は、標準ＳＩＰルーティングに従って通過される。それぞれのＩＢＣＦは、Ｂ２ＢＵＡとしての役割を果たす。Ｒｅｑｕｉｒｅ：  Ｌｏｃａｌ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇ、というヘッダは、ＩＢＣＦ３０、２８、２６及び３８にメディア最適化が要求され認可されることを通知する。ゆえに、これらのＩＢＣＦは、このＳＩＰセッションのためのユーザプレーンを、関連付けられたＴｒＧＷ内にアンカーしなくなるものとする。そのため、それぞれのＩＢＣＦによって割り当てられたＴｒＧＷリソース（メディア接続）は開放される（図１４のステップ１１８を参照）。そのことに関し、例えばＩＢＣＦ２６のプロセッサ１５２０は、メディアアンカーを解除する、すなわち、ＩＢＣＦ２６をメディアパスから除去するよう配設される。更新リクエストのＳＤＰオファーは、修正されずに伝わる。
【００８１】
ステップ１１０６では、更新リクエストがＩＢＣＦ３６に到達する。ＩＢＣＦ３６はＳＩＰエンティティであり、ＳＩＰエンティティはがメディア最適化を適用しうることを示している、ＳＩＰエンティティである。これは、ＩＢＣＦ３６が、更新リクエストの最終デスティネーションとしての役割を果たすことになることを示唆する。ＩＢＣＦ３６は既に、ユーザプレーンのためのＴｒＧＷを割り当てている。それは割り当てられたＴｒＧＷを保つが、ユーザプレーンを更新することになる。；それは、更新リクエスト内で受信したＳＤＰオファーを使用して、ＩＭＳ  ＡＧと、ＩＢＤＦ３６に制御されているこのＴｒＧＷの間に、ユーザプレーンを確立する。そのことに関し、ＩＢＤＦ３６のプロセッサ１５１４は、それに応じて配設される。
【００８２】
ステップ１１０７からステップ１１１１では、ＩＢＣＦ３６は、ＳＤＰ応答を包含する２００  Ｏｋを返送する（図１４のステップ１２０を参照）。ＳＤＰ応答は、Ｐ−ＣＳＣＦ２０によって受信され、ＩＭＳ  ＡＧのためのユーザプレーンを更新するために使用される。２００  ＯｋのＰ−ＣＳＣＦ２０への到達で、更新トランザクションが完了する。
【００８３】
更新トランザクションが完了する時には、下記の所望の通話状態が実現している。発信側相手先と受信側相手先の間のＳＩＰ信号伝達及び通話のためのユーザプレーンは、発信側相手先の訪問先ＩＭＳネットワーク６から受信側相手先の訪問先ＩＭＳネットワーク８へと直接ルーティングされる。制御プレーンは、受信側相手先の訪問先ＩＭＳネットワーク８と受信側相手先のホームＩＭＳネットワーク１２の間にルーティングされる。ユーザプレーンは受信側相手先の訪問先ＩＭＳネットワーク内に保たれ、すなわち、ユーザプレーンは、発信側相手先の訪問先ＩＭＳネットワーク６と受信側相手先の訪問先ＩＭＳネットワーク８の間に直接ルーティングされる。この状態が図１２に描写されている。
【００８４】
当然のことながら、３ＧＰＰ  ＴＳ  ２３．２２８ＩＰマルチメディアサブシステム（ＩＭＳ）；第２段階セクションＱの「最適メディアルーティング（ＯＭＲ）」は、ユーザプレーンエンティティがいかにして、確立済のＳＩＰセッションから除去されうるかを特定している。本発明は、ＯＭＲを超えて、受信側加入者がローミングしている時にＶｏＬＴＥ通話のメディア転送を最適化するための概念を使用する。しかし、ＯＭＲのこれらの通話への適用は、所望の最適化を実現するには十分ではないかもしれないということが強調される。本発明の一態様は、第１ＳＩＰセッションが、通話が応答された場合に、発信側相手先の訪問先ＩＭＳネットワーク６から受信側相手先の訪問先ＩＭＳネットワーク８へと直接ルーティングされるように、移動するというものである。ＳＩＰセッションが一旦上述のようにルート変更されると、発信側相手先の訪問先ＩＭＳネットワークと受信側相手先のホームＩＭＳネットワークの間をメディアがルーティングされなくなるように、メディアパス最適化が適用される。
【００８５】
上述のように、ユーザプレーンの最適化は、受信側相手先の訪問先ＩＭＳネットワーク８と受信側相手先のホームＩＭＳネットワーク１２の間の信号伝達を通じて適用される。このユーザプレーン最適化は、受信側相手先のＰ−ＣＳＣＦ２０とＩＢＣＦ３６の間の信号伝達を通じて行われる。Ｐ−ＣＳＣＦ２０とＩＢＣＦ３６の間の更新トランザクションは、これに関してはユーザである。ユーザプレーン最適化は、どのような場合にも、ＳＩＰセッションのこの部分に制限されるということが、理論的根拠である。
【００８６】
Ａｃｋが受信側相手先のＵＥ４に転送された後にＰ−ＣＳＣＦ２０とＩＢＣＦ３６の間の信号伝達を適用する代わりに、Ｐ−ＣＳＣＦ２０とＩＢＣＦ３６の間の信号伝達は、ＡＣＫの受信側相手先のＵＥ４に向けての転送に先立って行われうる。利点は、ＵＥ４がＡｃｋを受信する時には、ユーザプレーン最適化は行われており、ユーザプレーンに対する更なる変更がなくなるということである。
【００８７】
ユーザプレーン最適化は、関連エンティティ間での性能ネゴシエーションを要する。発信側相手先の訪問先ＩＭＳネットワーク６内のＩＢＣＦ２４と受信側相手先のホームＩＭＳネットワーク１２内のＩＢＣＦ２６の間に、置換ＳＩＰセッション区域を確立するためには、ＩＢＣＦ２４とＩＢＣＦ２６の間のネゴシエーションが必要である。ＩＢＣＦ２４は、（第１）インバイトリクエスト内に、最適化されたメディアルーティングをサポートすることを示す（図１４のステップ１０２を参照）。例えば、：
Ｓｕｐｐｏｒｔｅｄ：Ｏｐｔｉｍｉｚｅｄ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇ
【００８８】
ＩＢＣＦ２６は次いで、ＩＢＣＦ２４に、最適化されたメディアルーティングを上述のように適用するよう指示するか否かを決定しうる。受信側相手先の訪問先ＩＭＳネットワーク８と受信側相手先のホームＩＭＳネットワーク１２の間のユーザプレーン最適化に関しては、ＩＢＣＦ３６とＰ−ＣＳＣＦ２０の間の性能ネゴシエーションが必要となる。これは、Ａｃｋ内の所定の表示を通じて行われる。：
Ｓｕｐｐｏｒｔｅｄ：Ｌｏｃａｌ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇ
【００８９】
Ｐ−ＣＳＣＦ２０は次いで、このＳＩＰセッションのためにＬｏｃａｌ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇがサポートされることを検出すると、ローカルのメディアルーティングを上述のように開始しうる。Ｐ−ＣＳＣＦ２０からの更新リクエストは以下のヘッダを包含する。：
Ｒｅｑｕｉｒｅ：Ｌｏｃａｌ＿ｍｅｄｉａ＿ｒｏｕｔｉｎｇ
【００９０】
発信側相手先の訪問先ＩＭＳネットワーク６から受信側相手先の訪問先ＩＭＳネットワーク８までユーザプレーンが直接確立されると、これは、発信側相手先にとってのコスト削減へとつながりうる。ＩＢＣＦ２４から発信側相手先へ向けての２００  Ｏｋの返答は、そのことに関して、ＳＩＰセッションは最適化された様態で、すなわち、受信側相手先の訪問先ＩＭＳネットワーク８へと直接、確立されるという、妥当な表示を包含する。この表示は、発信側相手先のＳ−ＣＳＣＦ１４、及び発信側相手先のＭＭＴｅｌアプリケーションサーバ等、様々なＳＩＰエンティティを通過する。これは次いで、ＳＩＰセッションのコストを適合させるために使用される。
【００９１】
同様に、受信側相手先の訪問先ＩＭＳネットワーク８と受信側相手先のホームＩＭＳネットワーク１２の間の、受信側相手先のためのＳＩＰ信号伝達は、ユーザプレーンは最適化される、すなわち、受信側相手先の訪問先ＩＭＳネットワーク８内でローカルにルーティングされるという表示を搬送する。これは、受信側相手先のコスト削減へとつながりうる。受信側相手先にとってのコスト削減は、例えば、国外をローミングしている受信側相手先へと、同一の（国外の）国に存在する発信側相手先によって通話が確立される時に、適合しうる。
【００９２】
発信側相手先の訪問先ＩＭＳネットワーク６は、最適化されたＳＩＰセッションルーティングを選択的に適用しうると、更に理解される。ＩＢＣＦ２６からＩＢＣＦ２４によって受信された２００  Ｏｋは、最適化されたＳＩＰセッションルーティングが適用されうるという表示を包含する。ＩＢＣＦ２４は次いで、最適化されたＳＩＰセッションルーティングの適用が、発信側相手先にとってのコスト削減へとつながるか否かを決定する。具体的には、ＩＢＣＦ２４と関連付けられたＴｒＧＷからＩＢＣＦ３６と関連付けられたＴｒＧＷまでのユーザプレーンは、ＩＢＣＦ２４と関連付けられたＴｒＧＷからＩＢＣＦ２６と関連付けられＴｒＧＷまでのユーザプレーンよりも、低いコストをもたらすか否かということである。
【００９３】
Ａ相手先２のＵＥとＢ相手先４のＵＥの間で、制御プレーンとユーザプレーンの両方を含む前記ＳＩＰセッションが確立される時に、通告の発呼を求める要求がありうる。かかる要求は、例えば、Ａ相手先又はＢ相手先のためのＭＭＴｅｌサービス論理処理の中に存在しうる。
【００９４】
ＲＡＶＥＬで提案されたアーキテクチャ内において、Ａ相手先の通話を制御するＭＭＴｅｌサービスは、ＳＤＰ更新を適用して、訪問先ＩＭＳネットワーク６内のＡ相手先２のＵＥと、ホームＩＭＳネットワーク１０内のメディアリソースファンクションサーバ（ＭＲＦ）５２の間に、ユーザプレーン接続を確立しうる。遠隔相手先を有するユーザプレーンは、サービス対象相手先とのユーザ対話が続いている間、保留状態にされる。一時的に「ホームＩＭＳネットワークを通じてユーザプレーンを引き込む」というこの方法は、Ｂ相手先にも適用されうる。これは図１３に反映されている。
【００９５】
提案された、ＶｏＬＴＥ通話のための最適化されたメディア転送の方法は、ＬＴＥ接続とユニバーサルテレストリアルラジオアクセスネットワーク（ＵＴＲＡＮ）接続の間のシングルラジオボイスコールコンティニュイティ（ＳＲ−ＶＣＣ）の対象である通話に対しても、いずれの方向にも、使用可能であるべきである。そのことに関し、下記の要件が適合する。受信側相手先のためのメディアアンカーは、訪問先ネットワーク８のエンハンストパケットシステム（ＥＰＳ）内で行われる。具体的には、音声及び／又は映像通話は、３ＧＰＰのリリース１０でＳＲ−ＶＣＣについて規定されているように、アクセストランスファーコントロールファンクション（ＡＴＣＦ）を通じて確立される。ＵＴＲＡＮ接続性能を提供する訪問先ネットワーク内のＭＳＣは、ＩＭＳ集中型サービスのための３ＧＰＰに規定されているように、Ｉ２基準点をサポートする。ここでは、ＭＳＣはエンハンストＭＳＣ（ｅＭＳＣ）である。ＳＣＣ−ＡＳ内のターミネーティングアクセスドメインセレクション（Ｔ−ＡＤＳ）手順によって、ＣＳ接続を通じて受信側加入者の携帯電話に向けて着信接続通話を確立することは、Ｔ−ＡＤＳがモバイルステーションルーティングナンバ（ＭＳＲＮ）をホーム加入者サーバ／ホーム位置登録（ＨＳＳ／ＨＬＲ）から取得し、ホームＩＭＳネットワーク内のＣＳＣＦから訪問先ＩＭＳネットワーク内のｅＭＳＣまでのＳＩＰセッションを、ＧＭＳＣ機能を使用する必要なく確立することを、促進することによって行われる。ＣＳ接続を通じての、受信側加入者の携帯電話に向けての着信接続通話は、ＡＴＣＦを通じて行われる。ゆえに、ＡＴＣＦは、受信側加入者にサービス提供するｅＭＳＣに向けてのＳＩＰセッションのためのパスヘッダとして使用される。ＳＩＰセッションを、ＡＴＣＦを通じてｅＭＳＣに向けてルーティングすることは、ＵＴＲＡＮ接続からＬＴＥ接続へのリバースＳＲ−ＶＣＣ（ｒＳＲ−ＶＣＣ）のために必要である。
【００９６】
上記では、発明の実施形態の特定の実施例を参照して、発明が説明された。しかし、その中において、発明の本質から乖離することなく様々な改造及び変更がなされうることは明白である。
【００９７】
発明は、ローミングしているＶｏＬＴＥ加入者間の、又は受信側相手先がローミングしている時のＶｏＬＴＥ通話に関して、コスト削減が実現するという利点を提供する。加えて、メディアがより少ないメディアプロキシを通じてルーティングされ、その結果、通常、メディア品質が改善されることになるという利点が得られる。これは特に、映像通話（ＬＴＥを介しての映像）に適しうる。別の利点は、最適化されたメディアルーティングが、ネットワーク負荷を軽減することである。
【００９８】
ローミングしているＶｏＬＴＥ加入者間の音声／映像通話に関して、ユーザプレーンを含むＳＩＰセッションは、発信側相手先の訪問先ＩＭＳネットワークと受信側相手先の訪問先ＩＭＳネットワークの間を直接搬送される。これにより、最適化されたユーザプレーンが、発信側相手先の訪問先ＩＭＳネットワークと受信側相手先の訪問先ＩＭＳネットワークの間をルーティングすることが可能になる。通話のための制御プレーンは、依然として、受信側相手先のホームＩＭＳネットワークを通じてルーティングされている。図７は、この通話事例のための、制御プレーンとユーザプレーンのルーティングを図示している。
【００９９】
一使用事例では、メディア最適化は、（関連エンティティにサポートされて）実現可能であり、かつ、コスト削減へとつながると判断される通話事例にのみ適用されることになる。
【０１００】
当然のことながら、プロセッサ１５０２、１５０６、１５１４、１５２０、Ｉ／Ｏユニット１５０４、１５０８、１５１０、１５１２、１５１６、１５１８及び／又は、アンカーユニット１５１５は、場合によってはソフトウェアコード部を含む専用電子回路として、具現化されうる。プロセッサ１５０２、１５０６、１５１４、１５２０、Ｉ／Ｏユニット１５０４、１５０８、１５１０、１５１２、１５１６、１５１８及び／又は、アンカーユニット１５１５は、コンピュータのようなプログラマブル装置上で実行され、例えばそのメモリに保存される、ソフトウェアコード部としても具現化されうる。
【０１０１】
しかし、他の改造、変形、代替も可能である。仕様書、図面及び実施例は、それに応じて、限定的な認識というよりは例示的な認識において考慮されることになる。
【０１０２】
特許請求の範囲では、括弧の中に置かれたいかなる参考符号も、特許請求の範囲を限定するとは解釈されないものとする。「を含む」「を備える」という言葉は、請求項の中に列挙されたもの以外の特性又はステップの存在を除外するものではない。更に、「一」及び「一つの」という言葉は、「唯一の」という意味に限定されるとは解釈されないものとし、その代わりに、「少なくとも１つ」を意味するよう使用され、かつ、複数性を除外しない。互いに異なる請求項の中に特定の措置が列挙されているという単なる事実は、これらの措置の組み合わせが利点のために使用され得ないということを示すものではない。
【図１】
0006001164.tif 000002
【図２】
0006001164.tif 000003
【図３】
0006001164.tif 000004
【図４】
0006001164.tif 000005
【図５Ａ】
0006001164.tif 000006
【図５Ｂ】
0006001164.tif 000007
【図５Ｃ】
0006001164.tif 000008
【図６】
0006001164.tif 000009
【図７】
0006001164.tif 000010
【図８】
0006001164.tif 000011
【図９】
0006001164.tif 000012
【図１０】
0006001164.tif 000013
【図１１】
0006001164.tif 000014
【図１２】
0006001164.tif 000015
【図１３】
0006001164.tif 000016
【図１４】
0006001164.tif 000017