JP2009512379A - データネットワークにおいてビデオ電話コネクションおよび／またはマルチメディア電話コネクションを確立する方法 - Google Patents

Abstract

本発明は、電話網およびインターネットプロトコルベースのＩＰネットワークを包含するデータネットワークにおいてビデオ電話コネクションを確立する方法に関する。ビデオ電話コネクションとは一般的なものであると解され、ビデオテレフォニーの他にマルチメディアテレフォニーも含まれる。

Description

本発明は、電話網およびインターネットプロトコルベースのＩＰネットワークを包含するデータネットワークにおいてビデオ電話コネクションを確立する方法に関する。本明細書においてビデオ電話コネクションという表記には純粋なビデオテレフォニー以外にもマルチメディアテレフォニーも含まれると解される。

従来技術からはマルチメディアデータを伝送するために、電話網、例えば移動無線網、殊にＧＳＭ移動無線網またはＵＭＴＳ移動無線網をＩＰベースのネットワークと接続し、その種の組み合わされたデータネットワークを介して音声テレフォニーまたはビデオテレフォニーを効率的に実施することが公知である。電話網のサービスがＩＰネットワークのサービスと協働し、また殊に使用されるシグナリングおよび有効データの伝送フォーマットの変換が確実に行われることが保証されていなければならない。

３ＧＰＰネットワーク（３ＧＰＰ＝3rd Generation Partnership Project）の領域では、３ＧＰＰ標準ＴＳ２９．１６３において、いわゆるＣＳ電話網（ＣＳ＝Circuit Switched；回線交換）、殊に３ＧＰＰ−ＣＳ領域またはＰＳＴＮネットワーク（ＰＳＴＮ＝Public Switched Telephone Network；公衆交換電話網）とＩＰベースのＩＭＳネットワーク（ＩＭＳ＝IP Multimedia Subsystem；ＩＰマルチメディアサブシステム）との間の協働が規定された。しかしながらこの仕様は純粋な音声テレフォニーにしか該当せず、またＣＳネットワークとＩＭＳネットワークとの間において効率的なビデオ電話コネクションをどのように確立することができるかという方法は公知ではない。

したがって本発明の課題は、電話網側の加入者とＩＰネットワーク側の加入者との間のビデオ電話コネクションの確立を実現する方法を提供することである。

この課題は独立請求項に記載されている構成によって解決される。本発明の有利な実施形態は従属請求項に記載されている。

本発明による方法ではステップａ）において、電話網内または電話網に隣接する第１の加入者と、ＩＰネットワーク内またはＩＰネットワークに隣接する第２の加入者との間において、電話網内の第１のシグナリングプロトコルおよびＩＰネットワーク内の第２のシグナリングプロトコルを用いて、電話網およびＩＰネットワークを介するコール確立が行われる。殊に加入者は端末装置であると解され、とりわけ移動無線端末装置または固定網端末装置であると解される。第１のシグナリングプロトコルと第２のシグナリングプロトコルとの間のシグナリングを保証するために、コール確立の際に第１のシグナリングプロトコルのシグナリングメッセージの第２のシグナリングプロトコルへの変換、および／または、第２のシグナリングプロトコルのシグナリングメッセージの第１のシグナリングプロトコルへの変換が行われる（ステップｂ））。ステップｃ）においてはこの変換の際に、ビデオ電話コネクションの間に交換される有効データを伝送する際に電話網において使用可能である、および／または、使用可能であると見込まれる１つまたは複数のコーディングが決定される。大抵の場合、電話網内の第１のシグナリングプロトコルを用いるシグナリングの際に有効データに関して使用可能なコーディングに関する情報は通知されないのでコーディングがこのように決定される。これらの情報は電話コネクションにおいては後の時点において初めて、すなわち有効データを伝送するための本来のデータコネクションが確立される際に通知される。他方では、ＩＰネットワークにおいて使用されるシグナリングプロトコルは使用可能なコーディングに関する情報を必要とする。したがってステップｄ）においては、ステップｃ）において決定されたコーディングが第２のシグナリングプロトコルの１つまたは複数のシグナリングメッセージを用いてＩＰネットワークに送信される。続けて、コール確立の実施後および／または実施中にビデオ電話コネクションの間に交換される有効データを伝送するためのデータコネクションが確立される。データコネクションにおいては、殊にステップｅ）によるデータコネクションの確立中に、電話網側において第３のシグナリングプロトコル、殊にＨ．２４５を用いて有効データに関して使用されるコーディングが決定される。

本発明は、ＩＰネットワークにおけるシグナリングのために既に使用可能なコーディング、もしくは使用可能であると見込まれるコーディングを決定する必要があるという認識を基礎とする。しかしながら電話網側のコーディングはシグナリングの際にまだ既知ではないので、本発明による方法においては、どのコーディングがペイロードの伝送の際に電話網において使用可能もしくは使用可能であると見込まれるかが事前に評価ないし検出される。この情報は第２のシグナリングプロトコルによって使用される。したがって本発明の方法によれば、実際に電話網において使用可能なコーディングが通知されるデータコネクションの本来の確立を待機する必要がないので高速なコネクション確立を保証することができる。

本発明による方法は有利には上述の３ＧＰＰデータネットワークにおいて使用される。電話網として、殊に上述のＣＳネットワークおよび／またはＰＳＴＮネットワークが使用される。本発明による方法においては、第１のシグナリングプロトコルとして有利には従来技術から公知のＢＩＣＣ（ＢＩＣＣ＝Bearer Independent Call Control；ベアラに依存しない呼制御）プロトコルが使用される。択一的または付加的に、従来技術から公知のＩＳＵＰ（ＩＳＵＰ＝ISDN User Part；ＩＳＤＮユーザ部）プロトコルも使用することができる。第２のＩＰネットワークとして有利には前述のＩＭＳネットワークが使用される。さらに第２のシグナリングプロトコルとして、殊に従来技術から十分に公知のＳＩＰ／ＳＤＰプロトコル（ＳＩＰ＝Session Initiation Protocol；セッション開始プロトコル／ＳＤＰ＝Session Description Protocol；セッション記述プロトコル）が該当する。有利な実施形態においては、ステップｆ）の後にトランスポートコネクション（ベアラコネクションと称される）の確立が終了していることをシグナリングするために、ＳＩＰプロトコルでは公知の前提条件拡張が使用される。

本発明の有利な実施形態においては、本発明による方法のステップｂ）からｄ）が電話網とＩＰネットワークとの間の１つまたは複数のインタフェースノードにおいて実施され、このインタフェースノードは有利にはＭＧＣＦノード（ＭＧＣＦ＝Media Gateway Control Function；メディアゲートウェイ制御機能）およびＩＭ−ＭＧＷノード（ＩＭ−ＭＧＷ＝IMS Media Gateway；ＩＭＳメディアゲートウェイ）を含む。この種のインタフェースノードないしインタフェースプロセッサは従来技術から十分に公知であるのでここでは詳細に説明しない。

殊に有利な実施形態においては、ステップｅ）におけるデータコネクションの確立の際に従来技術から十分に公知であるＨ．３２４プロトコルファミリーが使用される。電話網として移動無線網が使用される場合には、このプロトコルのヴァリエーション、すなわちＨ．３２４Ｍプロトコルが使用される。

ステップｃ）において、電話網において使用可能なコーディングの効果的な評価を保証するために、有利な実施形態ではこのステップにおいて、使用される電話網に依存してコーディングが決定される。使用される電話網に応じて決定されたコーディングが有利であるという認識が基礎とされる。

別の実施形態においては、コーディングが本発明による方法のステップｃ）において、電話網内または電話網に隣接する第１の加入者の電話番号に依存して決定される。第１の加入者の電話番号を用いてどの電話網に加入者が存在するかを求めることができるという認識が基礎とされる。このことから、どのコーディングが有利に使用されるかということを推定することができる。

別の実施形態ではステップｃ）において、使用される電話網および使用されるＩＰネットワークに依存して両方のネットワークにおいて使用される可能性が最も高いコーディング方法が決定される。これによって、互換性のあるコーディングの適切な選択が既に予め決定されることが保証される。コーディングのこの種の選択を例えば、統計の評価もしくは管理的な調整によって達成および最適化することができる。殊に、ただ１つの音声コーディングおよびビデオコーディングが選択されることも考えられる。

本発明の別の実施形態においては、第１のシグナリングプロトコルのシグナリングメッセージが電話網において使用可能な音声コーディングに関する情報を包含するように構成されている。有利にはこれらの音声コーディングは同様にステップｃ）におけるコーディングの決定の際に考慮される。これによって、ＩＰネットワークの側において純粋な音声テレフォニーのみが選択される場合であっても円滑なコール確立が保証される。

本発明の殊に有利な実施形態においては、本発明による方法のステップｆ）におけるデータコネクションの確立の際に、１つまたは複数の第１の仕様メッセージが電話網において伝送される。この第１の仕様メッセージは第１の加入者において使用可能なコーディングを規定する。これらの第１の仕様メッセージは殊に従来技術において、コーディング交渉のためのプロトコルＨ．２４５から「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージＴＣＳとして公知である。第１の仕様メッセージにおいて規定されているコーディングは殊にステップｃ）において決定されたコーディングと比較される。この比較により、第１の仕様メッセージにおいて規定されているコーディングとステップｃ）において決定されたコーディングとが一致しない、または部分的にしか一致しないことが明らかになると、有利な実施形態においては第２のシグナリングプロトコルのシグナリングメッセージがＩＰネットワークに送信される。このシグナリングメッセージは少なくとも部分的に第１の仕様メッセージにおいて規定されているコーディングを包含する。これによって、本来評価されたコーディングが実際に使用可能なコーディングと一致しない場合であってもデータコネクションを確立できることが保証される。

本発明による方法の別の有利な実施形態においては、第２のシグナリングプロトコルのシグナリングメッセージがＩＰネットワークにおいて伝送される。このシグナリングメッセージは第２の加入者において使用可能なコーディングを規定し、さらにはこのシグナリングメッセージ内に包含されているコーディングは第２の仕様メッセージを用いてステップｅ）におけるデータコネクションの確立の際に電話網に送信される。このようにして、ＩＰネットワークから受信したコーディングに関する情報が、殊にＨ．２４５プロトコルを用いて実施される電話網におけるコーディングの交渉の際に考慮される。

別の実施形態においては、第２の加入者において使用可能なコーディングを規定する第２のシグナリングプロトコルのシグナリングメッセージが第１の仕様メッセージと比較され、シグナリングメッセージにおいてビデオ電話コネクションに関して必要とされるコーディングと第１の仕様メッセージとが一致しない場合には、ビデオ電話コネクションの確立が中止されるか、音声テレフォニーへの切り換えが有利には３ＧＰＰ標準３ＧＰＰ ＴＳ２３．１７２に準拠するＳＣＵＤＩＦ−「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ」プロシージャを用いて指示される。

殊に本発明において使用されるコーディングは、ビデオテレフォニーにおいて使用される音声コーディングおよびビデオコーディングに関する。しかしながら本発明は必要に応じて別のデータコーディングも含む。

本発明による方法の別の実施形態においては、殊に使用されるＳＩＰプロトコルが前提条件拡張を支援しない場合には、第２の加入者には、データコネクション、殊に電話網におけるトランスポートコネクションを確立する所定の方法ステップが終了するまで有効データは伝送されないことが通知される。これによっていわゆる「クリッピング」、すなわち一貫したトランスポートコネクションが存在する前に、被発呼側によって送信される音声またはビデオの損失が回避される。

上述した本発明による方法の他に、さらに本発明は電話網およびインターネットプロトコルを基礎とするＩＰネットワークを有するデータネットワークに関する。このデータネットワークは本発明による方法を実施できるように構成されている。このためにデータネットワークは有利には、電話網とＩＰネットワークとの間の１つまたは複数のインタフェースノードを有し、このインタフェースノードは本発明による方法のステップｂ）からｄ）を実施するために使用される。有利にはインタフェースノードは、既に本発明による方法を説明する際に言及した従来技術から十分に公知のＭＧＣＦノードおよびＩＭ−ＭＧＷノードを有する。

以下では本発明の実施例を添付の図面に基づき詳細に説明する。ここで、
図１は、本発明による方法を使用することができるデータネットワークの実施形態の概略図を示す。

図２から図１６は、本発明において使用されるプロトコルにおけるメッセージのシグナリング経過を種々のシナリオに関して示したシグナリングチャートを示す。

本発明による方法の実施形態を詳細に説明する前に、先ず本発明のより良い理解のために従来技術において既に存在する構成を検討する。殊に、本発明による方法が好適に使用されるデータネットワークの発展を検討する。以下において規定されるプロトコルまた前記において規定したプロトコルおよびそれらの略号は従来技術から十分に公知であるのでここでは詳細に説明しない。

３ＧＰＰ移動無線プロジェクトからは、音声テレフォニーおよびビデオテレフォニーのためにいわゆる「回線交換領域（Circuit Switched Domain）」ネットワークＣＳおよびいわゆる「ＩＰマルチメディアサブシステム（ＩＭＳ）」ネットワークが公知である。このネットワークの関連するサービスのいわゆる「インターワーキング（Interworking）」が保証されていなければならない。すなわち、使用されるシグナリングおよびデータの使用される伝送フォーマットの適切な変換を用いたＩＭＳとＣＳ領域との間のサービスのコネクションが必要である。ＩＭＳは３ＧＰＰアクセスネットワーク「Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ」（ＧＳＭ）と「Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ」（ＵＭＴＳ）が他のアクセスネットワーク、例えば「無線ＬＡＮ」（ＷＬＡＮ）および「ディジタル加入者線」（ＤＳＬ）に対しても使用される。先ずこれらのシナリオにおいては、ＩＭＳを介して音声テレフォニーおよびビデオテレフォニーが行われることが期待される。ビデオテレフォニーは公共の電話網、すなわちいわゆる「公衆交換電話網（ＰＳＴＮ）」においても使用することができ、通常の場合、３ＧＰＰ−ＣＳ領域において使用されるプロトコルが伝送およびシグナリングのために使用されるＰＳＴＮネットワークによってもＩＭＳとのインターワーキングが必要とされる。

従来、ＩＭＳとＣＳ領域またはＰＳＴＮとのインターワーキングは音声テレフォニーに関してのみ規定されている。本発明はビデオテレフォニーのための相応のインターワーキングに関する。３ＧＰＰ−ＣＳ領域においてもＩＭＳにおいてもビデオテレフォニーは重要性を増しており、しかも殊にＷＬＡＮまたはＤＳＬなどのようなアクセスネットワークに関して、もしくは新たに生じたネットワークアクセス手段（例えばＷｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））に関しても重要性を増しているのでそのような需要が見込まれる。

ＩＭＳネットワークとＣＳネットワーク、すなわちＰＳＴＮまたは３ＧＰＰ−ＣＳ領域との間のインターワーキングは３ＧＰＰ Ｒｅｌｅａｓｅ６以降、純粋な音声テレフォニーに関してのみ３ＧＰＰ ＴＳ２９．１６３に規定されている。

ＴＳ２９．１６３によれば、いわゆる「呼制御（Call-Control）」シグナリングのインターワーキングが「メディアゲートウェイ制御機能（Media Gateway Control Function）」（ＭＧＣＦ）において行われる。有効コネクションのインターワーキング、すなわち転送および再パッケージ、また必要に応じて有効データのコード変換はいわゆる「インターネットマルチメディアメディアゲートウェイ（Internet Multimedia-Media Gateway）」（ＩＭ−ＭＧＷ）において行われる。ＭＧＣＦは３ＧＰＰ ＴＳ２９．３３２に詳細に記載されているようなＩＴＵ−Ｔによって標準化されたＨ．２４８プロトコルを用いてＩＭ−ＭＧＷを制御する。以下では、ＭＧＣＦおよびＩＭ−ＭＧＷを合わせて「マルチメディアインターワーキングノード」（ＭＩＫ）と称する。

ＣＳネットワークにおいてはベアラに依存しない呼制御（ＢＩＣＣ）またはＩＳＤＮユーザ部（ＩＳＵＰ）が呼制御シグナリングに使用される。呼制御シグナリングがトランスポートコネクションとは別個に行われる場合、この方式は「アウトオブバンド（out-of-band）」シグナリングとも称される。トランスポートコネクション内でシグナリングメッセージが交換されることも考えられ、これは「インバンド（in-band）」シグナリングと称される。ＩＳＵＰの場合には時分割多重（ＴＤＭ）がＣＳネットワークにおける伝送に使用され、ＢＩＣＣの場合にはインターネットプロトコル（ＩＰ）または非同期伝送モード（ＡＴＭ）によってパケット伝送が行われる。ＩＳＵＰに関して、純粋な音声テレフォニーが使用されるかビデオテレフォニーが使用されるかの交渉を、通話を確立するための呼制御シグナリング中にいわゆるＩＳＵＰ「ＵＤＩフォールバック（UDI Fallback）」プロシージャを用いて行うことができる。ＢＩＣＣに関してこの交渉は３ＧＰＰ ＴＳ２３．１７２において標準化されている「サービス変更およびＵＤＩフォールバック（Service Change and UDI Fallback）」（ＳＣＵＤＩＦ）を用いて行うことができ、これは通話中であっても音声テレフォニーとビデオテレフォニーの切り換えを実現する。ＳＣＵＤＩＦのような「ＵＤＩフォールバック」も「アウトオブバンド」シグナリングを使用する。この他にＩＳＵＰおよびＢＩＣＣに関しては、前述のプロシージャを使用しないこと、またコール確立（呼制御とも称される）をビデオテレフォニーのためにのみ試みること、さらにビデオテレフォニーが支援されない場合にはコール確立を中止することが考えられる。音声とビデオとの間の任意の交渉とは異なり、ビデオテレフォニーに使用される音声コーデックとビデオコーデックとの間の交渉は、既に先行してビデオテレフォニーが選択され、相応のトランスポートコネクション（英語「Bearer」）が確立された後に「インバンド」で行われる。

ビデオテレフォニーに関しては、ＣＳネットワークにおいて６４ｋｂｙｔｅ／ｓの帯域幅を有するいわゆるＢＳ３０データコネクションが使用される。このデータコネクション内ではＩＴＵ−Ｔによって標準化されたプロトコルスーツＨ．３２４が使用され、３ＧＰＰ−ＣＳ領域においては移動無線に関して適合されたヴァリエーションＨ．３２４Ｍが選択される。コール確立後に、マルチメディアコネクションのコンフィギュレーションがインバンドで、ＩＴＵ−Ｔによって標準化されたＨ．２４５プロトコルを介して交渉され、殊に使用されるビデオコーデック、音声コーデックおよびそれぞれのコーデックコンフィギュレーションの詳細が交渉される。音声およびビデオはＨ．２２３プロトコルを用いて同一のトランスポートコネクションにおいて多重化される。３ＧＰＰ−ＣＳ領域に関してＴＳ２６．１１０はプロトコルスーツＨ．２４５の使用を詳細に規定し、殊にいわゆるＨ．３２４Ｍコンフィギュレーションが選択される。

３Ｇ−３２４Ｍコネクションを確立する際に最も重要なシーケンス（英語「session」）は以下の通りである：
１ ＩＳＵＰまたはＢＩＣＣコール確立シグナリングを開始した後に、所望の「ベアラ」に必要とされるリソースが確保され、続けてトランスポートコネクションが確立される。

２ 「インバンド」交渉の開始先ず、どのＨ．２２３「マルチプレクサレベル」がこのトランスポートコネクションに対して使用されるべきかという交渉が行われる。

３ 必要であれば、Ｈ．２４５交渉によりマルチストリームコネクションを開く主導的な端末装置の識別。この機能は、双方向の論理チャネル（＝logical Channel）が開かれた際の関係において衝突が発生した場合にのみ必要とされる。この機能は「マスターまたはスレーブの決定（Master or Slave determination）」（ＭＳＤ）と称される。

４ いわゆる「端末能力セット（Terminal Capability Set）」Ｈ．２４５メッセージＴＣＳを用いてメッセージを送信する端末装置の能力が伝送される。その種のメッセージは両方の端末装置に依存せずに送信される。ここで説明する能力には以下の情報が含まれる：オーディオコーデックおよびビデオコーデックならびにその特別な特性ないし特徴；マルチプレクサの機能範囲、詳細にはどの適合層が支援されるか（例えば、「シンプル」（＝単純）または「ネスト」（＝入れ子）多重化）およびその移動無線固有の拡張。

５ Ｈ．２４５シグナリングを用いたメディアストリーム毎の「論理」チャネルの確立。この時点以降、ＭＳＤを用いてまたは用いずに、端末装置ないしＩＭ−ＭＧＷは音声有効データおよび／またはビデオ有効データの交換を実現するために「論理チャネル」を開ける状態にある。双方向の「論理チャネル」を形成する際に、チャネル番号（＝channel number）および最終的に使用されるべきメディアの能力（英語「media capabilities」）が確定される。

６． Ｈ．２４５を用いる多重化特性の定義。

７． ビデオ、オーディオ／音声またはデータの伝送の開始。

ＩＭＳにおいてはビデオテレフォニーに関する交渉が「アウトオブバンド」でいわゆる「セッション記述プロトコル」（ＳＤＰ）、ＩＥＴＦ ＲＦＣ２３２７を用いて行われ、これはいわゆる「セッション開始プロトコル」（ＳＩＰ）、ＩＥＴＦ ＲＦＣ３２６１を用いて伝送される。音声テレフォニーが使用されるかビデオテレフォニーが使用されるかの交渉は使用されるコーデックの交渉と関連付けられており、またベアラを確立する前またはベアラの確立中に行われる。ＲＦＣ３２５４に準拠するいわゆるＳＤＰ「ｏｆｆｅｒ−ａｎｓｗｅｒ（提示・応答）」メカニズムが使用される。提示側はＳＤＰ「ｏｆｆｅｒ」メッセージにおいて支援されるコーデックのリストを送信する。このメッセージを受信した後に、応答側はＳＤＰ「Answer」メッセージを送信し、このメッセージは前述のリストの中の応答側が支援および利用しようとするコーデックを含んでいる。応答側はＳＤＰ「ｏｆｆｅｒ」のリストに含まれていなかったコーデックを提示してはならない。ＣＳ領域とは異なり、音声およびビデオに関しては２つの別個のトランスポートコネクション（英語「Bearer」）が使用され、このトランスポートコネクションはそれぞれいわゆる「リアルタイム伝送プロトコル」（ＲＴＰ）、ＩＥＴＦ ＲＦＣ３５５０が使用される。汎用パケット無線サービス（ＧＰＲＳ）を介してアクセスネットワークを使用する３ＧＰＰ−ＩＭＳに関して、３ＧＰＰ ＴＳ２６．２３５はビデオテレフォニーに対して使用されるべきコーデックを規定している。

以下では、ＣＳ領域側およびＩＭＳ側においてビデオテレフォニーに対して使用されるプロトコルおよびコーデックを再度説明する。

ＣＳ−ネットワーク（殊に３ＧＰＰ ＣＳ領域）
呼制御： ＢＩＣＣまたはＩＳＵＰ
純粋な音声テレフォニーとビデオテレフォニーとの間の交渉をＩＳＵＰに関 しては「ＵＤＩフォールバック」を用いて、またＢＩＣＣに関しては「ＳＣ ＵＤＩＦ」を用いて行うことができる。
マルチメディアプロトコルスーツＨ．３２４Ｍ（Ｈ．３２４補遺Ｃ）：
コーデック交渉： 確立された６４ｋｂｉｔ／ｓを有するＣＳベアラを介するＨ．２４ ５インバンド交渉
ビデオコーデック：Ｈ．２６３による支援 規定
Ｈ．２６１ オプション
ＭＰ４Ｖ−ＥＳ（単純なビデオプロファイルレベル０） オプショ ン
音声コーデック： ＮＢ−ＡＭＲによる支援 規定
ＷＢ−ＡＭＲ オプション
Ｇ．７２３．１ 推奨
トランスポート： Ｈ．２２３補遺Ａ＋Ｂに準拠するベアラにおける音声とビデオの多 重化。

ＩＭＳ（ＧＰＲＳアクセスネットワークのためのコーデック）：
呼制御：ＳＩＰ
純粋な音声テレフォニーとビデオテレフォニーとの間の交渉、例えばコーデッ ク交渉を含む。

コーデック交渉：ベアラを確立する前にＳＤＰを用いるアウトオブバンド、これはＳＩ Ｐにおいて伝送される。

ビデオコーデック：Ｈ．２６３による支援 規定
Ｈ２６４ オプション
ＭＰ４Ｖ−ＥＳ（単純なビデオプロファイルレベル０） オプショ ン
音声コーデック： ＮＢ−ＡＭＲおよびＷＢ−ＡＭＲによる支援 規定
トランスポート： 種々のいわゆるＲＴＰ「ペイロード」フォーマットを使用した音声 およびビデオのための２つの別個のＲＴＰベアラ：
音声： ＮＢ−ＡＭＲ＋ＷＢ−ＡＭＲ：ＩＥＴＦ ＲＦＣ３２６７
ビデオ：Ｈ．２６３：ＩＥＴＦ ＲＦＣ２４２９
Ｈ．２６４（ＡＶＣ）：ＩＥＴＦ ＲＦＣ３９８４
ＭＰＥＧ−４：ＩＥＴＦ ＲＦＣ３０１６
並行するＲＴＰメディアストリームの同期はいわゆるＲＴＰ「タイ ムスタンプ」を用いて行われ、これらは「リアルタイム制御プロト コル（ＲＴＣＰ、ＩＥＴＦ ＲＦＣ３５５０を参照されたい）」に よって交渉される。

しかしながら、殊にＣＳ端末装置がＰＳＴＮ内に存在するか、ＩＭＳ端末装置がＧＰＲＳをアクセスネットワークとして使用しない場合には、上記のコーデックの他にまたは代わりに他のコーデックも端末装置によって支援することができる。

ＣＳ側およびＩＭＳにおいて同一のビデオコーデックを使用すること、また可能であれば、コード変換を回避するために同一の音声コーデックを使用することも望ましい。殊にビデオコーデックのコード変換、しかしながら僅かな範囲においては音声コーデックのコード変換もＩＭ−ＭＧＷにおける著しく高い計算能力および計算リソースを必要としていた。さらには伝送が遅延され、画像ないし音声の品質が劣化する虞がある。ＣＳ領域側でのコーデックとＩＭＳ側でのコーデックに対して必要とされる帯域幅が異なる場合には、一方の側では付加的な帯域幅が使用されることになるが、それによって画像または音声の品質が改善されることは無い。

図１は、以下において説明する本発明の実施形態において使用することができる典型的なネットワークコンフィギュレーションを示す。

３ＧＰＰのＣＳ領域と接続されている移動端末装置ＭＳ１の形の端末が、ＩＭＳと接続されている移動端末装置ＭＳ２の形の端末と通信できるようにするために必要とされるネットワークコンフィギュレーションが示されている。ＣＳ領域は「メディアゲートウェイ制御機能」（ＭＧＣＦ）およびＩＭＳメディアゲートウェイ（ＩＭ−ＭＧＷ）を用いてＩＭＳと接続されている。ＭＧＣＦはＩＭＳメディアゲートウェイをいわゆる「Ｍｎ」インタフェースを介して制御する。ＣＳ領域側ではコアネットワーク内にいわゆる「モバイルスイッチングセンター」（ＭＳＣ）サーバが設けられており、このサーバはＢＩＣＣシグナリングを用いて相互に通信し、またＭＧＣＦと通信する。これらはそれぞれＣＳ−ＭＧＷを制御する。ＣＳ−ＭＧＷは相互に接続されており、またＩＭ−ＭＧＷといわゆる「Ｎｂ」インタフェースを介して接続されている。ビデオテレフォニーに関してはいわゆる「ＢＳ３０」データ伝送サービス（英語「Bearer Service」）が使用される。ＭＳ１はいわゆる無線アクセスネットワーク、例えばＵＴＲＡＮにより、ＣＳ−ＭＧＷのＭＳＣサーバと接続されている。ＩＭＳ側ではＭＧＣＦがＳＩＰ呼制御プロトコルを用いていわゆる「コールセッション制御機能」（ＣＳＣＦ）と通信し、このコールセッション制御機能はゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）および無線アクセスネットワーク、例えばいわゆるＵＴＲＡＮを介して移動端末ＭＳ２に転送される。データはＩＭＳメディアゲートウェイからＭｂインタフェースを介してＧＧＳＮに伝送され、このＧＧＳＮはこれらのデータを同様に無線アクセスネットワークＵＴＲＡＮを介してＭＳ２に転送する。

したがって図１において、２つのＭＳＣサーバを介してＭＧＣＦへと延びる線Ｌ１はＢＩＣＣシグナリングを表す。ＭＧＣＦからＣＳＣＦおよびＧＧＳＮを介して、またそこからＩＭＳ側のＵＴＲＡＮへと延びる線Ｌ２はＳＩＰシグナリングを表す。さらに、ＣＳ側のインタフェースＵＴＲＡＮから２つのＣＳ−ＭＧＷおよびＩＭ−ＭＧＷにわたり延びる線Ｌ３は組み合わされた音声／ビデオストリームを表す。線Ｌ３と同様に、ＣＳ側のインタフェースＵＴＲＡＮから２つのＣＳ−ＭＧＷを介してＩＭ−ＭＧＷへと延びる線Ｌ４はＨ．２４５プロトコルに準拠する伝送を表す。ＩＭ−ＭＧＷからＧＧＳＮを介してＩＭＳ側のＵＴＲＡＮへと延びる線Ｌ５はＩＭＳネットワークにおけるビデオストリームの伝送を表し、また同様にＩＭ−ＭＧＷからＧＧＳＮを介してＩＭＳ側のＵＴＲＡＮへと延びる線Ｌ６はＩＭＳネットワークにおいて伝送される音声ストリームを表す。

ＣＳネットワーク、すなわちＰＳＴＮまたは３ＧＰＰのＣＳ領域と、コーデックの交渉のためにＳＩＰおよびＳＤＰを使用するＩＰネットワーク、すなわち例えばＩＭＳとの間でのコード変換を回避したビデオテレフォニーのインターワーキングを使用する方法が本発明の対象である。

以下では「ＩＭＳ終端」（ＩＭＳ−Ｔ）コール確立と称する、ＣＳネットワーク側からＩＭＳの方向へのコール確立の場合、ＭＧＣＦは先ずＩＳＵＰまたはＢＩＣＣシグナリングを受信し、このシグナリングからＭＧＣＦはビデオテレフォニーが所望されていることを識別または推定することができるが、どの音声コーデックまたはビデオコーデックが使用されるかは識別または推定することはできない。

以下では「ＩＭＳ起源（ＩＭＳ−Ｏ）」コール確立と称する、ＩＭＳ側からＣＳネットワークの方向へのコール確立の場合、ＭＧＣＦは先ずＳＩＰシグナリングを受信し、このシグナリングからＭＧＣＦはビデオテレフォニーが所望されていることを識別または推定し、またＩＭＳ側においてどのコーデックが支援されるかを識別または推定することができる。

コネクションを高速に確立するために、また続けてＩＭＳとＣＳネットワークとの間のシグナリングを適切に実施できるようにするために、ＩＭＳ−Ｏコール確立の場合、またＩＭＳ−Ｔコール確立の場合においても、ＭＧＣＦがＩＭＳの方向におけるシグナリングに関して、ＣＳ側で支援されるコーデックに関する情報を与えることが必要とされる。このことはＭＧＣＦがそれらの情報をＨ．３２４／Ｍコネクションから取得する前に行われる。この情報は、例えばその時点においてトランスポートコネクションが接続される場合に、コール確立のためのアウトオブバンド呼制御シグナリングが既に終了しているときに初めてＣＳ側に提供されることが多い。多くのネットワークにおいては、トランスポートコネクションにおいてコール確立の方向に送信されたデータ、いわゆる「ｆｏｒｗａｒｄ ｅａｒｌｙ ｍｅｄｉａ（転送初期メディア）」がこの時点まで阻止される。

本発明の核心は、マルチメディアインターワーキングノード（ＭＩＫ）がコール確立の際のＳＩＰコーデック交渉において先ず、ＣＳ側において支援されるコーデックの評価のみを出力することである。有利な実施形態においては、ＭＩＫがコーデックの選択の際にこのＭＩＫが接続されているＣＳネットワークを考慮する。ＣＳネットワークが３ＧＰＰ ＣＳ領域である場合、ＭＧＣＦは有利には３ＧＰＰ ＴＳ２６．１１０に記載されているコーデックを使用する。固定網においては別のコーデックが優勢になる可能性もある。別の有利な実施形態においては、ＭＩＫがコーデックの選択の際に、ＣＳ側の通話加入者が存在するネットワークを考慮する。ＭＩＫはＩＭＳ−Ｏの場合、このネットワークに関して選択される可能性が高いコーデックを選択するために、どのネットワークに被発呼側が存在するかを求めるために被発呼側の電話番号を使用する。ＭＩＫはＩＭＳ−Ｔの場合、このネットワークに関して選択される可能性が高いコーデックを選択するために、どのネットワークに発呼側が存在するかを求めるために発呼側の電話番号を使用する。コーデックの選択を統計の評価もしくはＭＩＫのプロバイダによる管理的な調整によって最適化することができる。

比較的簡単な実施形態においては、ＭＩＫがＩＭＳにおける端末によっても支援される確率が高い音声コーデックおよびビデオコーデック、例えばＨ．２６３およびＡＭＲコーデックをそれぞれ１つだけ選択する。この実施形態は、３ＧＰＰ ＴＳ２６．２３５およびＴＳ２６．１１０がＣＳ領域およびＩＭＳにおいて同一の音声コーデックおよびビデオコーデックを支援すればよいので十分である。この実施形態はこれに続くグナリングシーケンスを簡略化するために有利である。

ＩＭＳ−ＴにおいてＳＣＵＤＩＦが使用される場合、ＭＩＫが上述の選択されたコーデックの他に音声コーデックも受け取ることは有利である。この音声コーデックはＳＣＵＤＩＦを使用する場合に、コール確立時に最初に伝送されるＩＡＭメッセージ（ＩＡＭ＝Initial Address Message）においてコーデックリストに格納されている。これによって、ＩＭＳの側において音声テレフォニーが選択される場合であっても円滑なコール確立が保証される。

ＭＩＫが続けてＨ．２４５インバンド交渉においていわゆる「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを受信する。このメッセージはＣＳネットワーク側における端末の能力、殊に支援するビデオコーデックおよび音声コーデックについての情報、より正確には、個々のコーデックのどのオプションが支援されるかについての情報を含む。本発明によれば、ＭＩＫはそのメッセージに含まれるコーデックを、事前に評価されたＩＭＳにシグナリングされたコーデックと比較する。コーデックが相互に異なる場合には、ＭＩＫがこの時点において新たにＳＤＰ「ｏｆｆｅｒ」をＩＭＳに送信することが有利である、もしくは送信することが必要とされ、その場合ＭＩＫは「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージに表されるコーデックを転送する。ＳＤＰ「ｏｆｆｅｒ」を例えばＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」または「ＵＰＤＡＴＥ」メッセージを用いて伝送することができる。殊に、事前に評価されたコーデックが、「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージにおいて受信したコーデックを有する、それぞれ少なくとも１つの音声コーデックおよびビデオコーデックと一致しない場合には新たなＳＤＰ ｏｆｆｅｒが必要である。

ＩＭＳ−Ｏの場合、ＭＩＫは既にＳＩＰ「ＩＮＶＩＴＥ」メッセージにおいて、ＩＭＳ側が支援するコーデックに関する情報を取得している。このコーデックが少なくともそれぞれ１つの音声コーデックおよびビデオコーデックにおいて、「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージにおいて受信したコーデックと一致しない場合には、例えばＭＩＫがＳＣＵＤＩＦを使用するかＣＳ側においてコール確立を先ず完全に終了し、その後音声テレフォニーのために新たにコール確立を開始することによって、ＭＩＫがＨ．２２３コネクションを解消し、コール確立を音声テレフォニーとして継続する場合には有利である。ＭＩＫが事前に送信したＳＤＰ「ａｎｓｗｅｒ」において、「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージにおいて受信したコーデックに基づき選択しようとするＩＭＳ側において支援されるコーデックを排除している場合が発生することも考えられる。

これに対してＩＭＳ−Ｔにおいては、ＭＩＫは評価したコーデックをＳＤＰ「ｏｆｆｅｒ」において送信し、受信したＳＤＰ「ａｎｓｗｅｒ」から、先ずＭＩＫによって評価されたコーデックのうちのどのコーデックがＩＭＳ側において支援されるかという情報のみを有する。すなわち、新たなＳＤＰ「ｏｆｆｅｒ」を用いて、第１のＳＤＰ「ｏｆｆｅｒ」には含まれていないコーデックがＩＭＳにおいて支援されるか否かを問い合せることは有利である。

本発明のさらに重要な点は、ＭＩＫがＩＭＳ側から受信したコーデックに関する情報をＨ．２４５インバンド交渉において「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを用いて転送することである。有利には、ＭＩＫがこのメッセージの送信と同時に、このＭＩＫがＩＭＳ側からコーデックについての情報を有するＳＤＰメッセージを受信するまで待機する。ＭＩＫが自身で「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを送信する前に、所定の時間にわたりこのメッセージの受信を待機する場合には殊に有利である。何故ならば、上述したようにＭＩＫは受信した「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージに含まれているコーデック情報に基づき、ＩＭＳ側からＳＤＰ「ｏｆｆｅｒ」を送信することを決定することができ、また後続のＳＤＰ「ａｎｓｗｅｒ」に含まれている情報をこのＭＩＫから送信した「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージにおいて考慮することができるからである。

しかしながら、例えばＣＳネットワークの裏でやはり別のＭＩＫがＩＭＳネットワークへの伝送を行っているために、ＭＩＫが所定の時間にわたり反対側から「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを受信しない場合には、ＭＩＫは「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを受信する前に自身で「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを送信することが必要となる可能性がある。本発明によれば、ＭＩＫはこのメッセージにＩＭＳ側において送信ないし受信された最後のＳＤＰメッセージに含まれていたコーデックを表す。

本発明によれば、ＭＩＫがＩＭＳ側における「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージの送信後に、最初の「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージにおいて許可されたコーデックを排除するＳＤＰメッセージを新たに受信する場合、ＭＩＫは対応するコーデックが除去されている新たな「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを送信する。

ＣＳネットワーク側においてＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージが交換された後では、Ｈ．２４５シグナリングを用いることにより、Ｈ．２２３プロトコルの別個の論理チャネルが音声およびビデオを伝送するために選択される。またこれによって、支援される音声コーデックおよびビデオコーデックのうちの１つだけが選択される。この時点においてＩＭＳ側では依然として複数の音声コーデックまたはビデオコーデックが選択されている場合、本発明によればＭＩＫはＨ．２４５を用いて選択したコーデックを表すＳＤＰ「ｏｆｆｅｒ」をＩＭＳ側に新たに送信し、ＭＩＫが転送できないコーデックがＩＭＳの端末側によって使用されることは回避される。ＳＤＰ「ｏｆｆｅｒ」を例えばＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」または「ＵＰＤＡＴＥ」メッセージを用いて伝送することができる。

ＩＭＳ−Ｔの場合には「クリッピング（Clipping）」、すなわち一貫したトランスポートコネクションが存在する前に、被発呼側によって送信される音声またはビデオの損失を回避することが望ましい。ＩＭＳの側においてＩＥＴＦ ＲＦＣ３３１２に準拠する「ＳＩＰ前提条件」拡張が支援される場合には、ＭＩＫはＳＩＰ「前提条件」拡張を使用し、これにより局所的ないわゆる「ＱｏＳ前提条件」が存在していること、すなわちコール確立を終了できるようになる前にトランスポートコネクションの確立が必要であることが示される。本発明によれば、音声およびビデオに関する論理的なＨ．２２３チャネルを開くことによって、ＣＳ側のトランスポートコネクションの確立が終了していると、ＭＩＫはＳＩＰ「前提条件」拡張を使用し、局所的ないわゆる「ＱｏＳ前提条件」が満たされていることを示す。もっとも、ＣＳ側においては呼制御シグナリングにおけるコール確立の終了後に始めて「ｆｏｒｗａｒｄ ｅａｒｌｙ ｍｅｄｉａ」が伝送され、またこの時点に初めてトランスポートコネクション内でのＨ．２２３およびＨ．２４５交渉が実現されることも考えられる。コール確立の阻止を回避するために、トランスポートコネクションの確立後に所定の時間にわたりＨ．２２３シグナリングが受信されない場合には、ＭＩＫはＩＭＳの側にも局所的ないわゆる「ＱｏＳ前提条件」が満たされていることをシグナリングする。

ＩＭＳの側においてＳＩＰ「前提条件」拡張が支援されない場合、または、しかしながらＣＳネットワークの側において「ｆｏｒｗａｒｄ ｅａｒｌｙ ｍｅｄｉａ」が支援されない場合、ＭＩＫが有利にはＩＭＳ側の端末に、ＣＳ側のトランスポートコネクション内でＨ．２２３およびＨ．２４５交渉が終了するまでメディアストリームを送信しないことを指示する。ＩＭＳ端末がこの情報を自身のユーザに示すことができ、これによって同様に「クリッピング」が回避される。このために本発明によれば、ＭＩＫがＲＦＣ３２６４に規定されているいわゆる「ｈｏｌｄ」プロシージャ、すなわち例えばＳＤＰ「ｉｎａｃｔｉｖｅ」属性を使用する。本発明によれば、音声およびビデオに関する論理的なＨ．２２３チャネルを開くことによってＣＳ側のトランスポートコネクションの確立が終了されると、ＭＩＫはＲＦＣ３２８４に準拠する「Ｒｅｓｕｍｅ」プロシージャを使用し、これによりＩＭＳ側の端末はメディアストリームを送信することができる。

ＩＭＳ−Ｔの場合には、トランスパレントなＢＳ３０ベアラのみがシグナリングされるので（例えば「ＩＡＭ」メッセージにおける値「ＵＤＩ」を有するパラメータ「ＴＭＲ」のみ）、呼制御シグナリングにおいてビデオテレフォニーを一義的に識別できないことも考えられる。この場合、有利にはＭＩＫがＩＭＳ側の音声コーデックおよびビデオコーデックの他に、該当する他のデータコーデック、例えばいわゆる「クリアモード」コーデック、ＩＥＴＦ ＲＦＣ４０４０または例えばＲＦＣ３３６２のフォーマットのＦＡＸコーデックも提供する。「クリアモード」コーデックによって、ＢＳ３０データサービスをトランスパレントにＩＭＳを介して転送することも可能である。したがって「クリアモード」コーデックの使用は、コネクション確立がＩＭＳから他のＭＩＫへと転送される場合のインターワーキングを容易にするために有利である。１つの実施形態においては、ＭＩＫがＣＳ側のトランスポートコネクションを先ずＢＳ３０サービスのためにのみコンフィギュレートするが、データコネクションはまだ確立されない。ＭＩＫが選択されたコーデックに関するシグナリングをＩＭＳ側から受信すると、ＭＩＫはビデオテレフォニーが問題であるか否かを識別することができ、またこの場合にはＨ．２２３インバンド交渉を開始する。別の実施形態においては、ＭＩＫが既にＩＡＭメッセージを受信しているとＨ．２２３およびＨ．２４５を用いてインバンド交渉を開始する。ＭＩＫが選択されたコーデックに関するシグナリングをＩＭＳ側から受信し、またビデオテレフォニーが選択されなかったことを識別すると、ＭＩＫはＨ．２２３およびＨ．２４５交渉の試みを終了する。

以下では、本発明による方法の種々のシナリオに関するコール確立を詳細に説明する。

図２は、以下では「ＩＭＳ終端」（ＩＭＳ−Ｔ）コール確立と称する、ＣＳネットワークの側からＩＭＳの方向へのコール確立の場合における、例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができるマルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＨ．２４５シグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングの原理をシグナリング経過を用いて示したものである。ここでは本発明に直接的に関連するメッセージのみが示されている。

シグナリングステップの詳細は以下の通りである：
１ ＭＩＫはいわゆるＢＩＣＣまたはＩＳＵＰ「ＩＡＭ」メッセージをＣＳ側から受信する。ＭＩＫはこの「ＩＡＭ」メッセージに包含されているパラメータに基づき、ビデオテレフォニーが所望されていること、もしくは所望されている可能性があることを識別する。ＩＭＡメッセージはビデオテレフォニーのために使用されるべき音声コーデックおよびビデオコーデックに関する情報を包含していない。

２ ＭＩＫはＩＡＭメッセージをＳＩＰ「ＩＮＶＩＴＥ」メッセージに変換する。本発明によれば、ＭＩＫはこの「ＩＮＶＩＴＥ」メッセージに包含されるＳＤＰ「ｏｆｆｅｒ」において、Ｈ．３２４ビデオテレフォニーに関してＣＳ側において支援される可能性が高い音声コーデック（例えばＡＭＲ）およびビデオコーデック（例えばＨ．２６３およびＭＰ４Ｖ−ＥＳ）に関する情報を表す。コーデックを選択する際にＭＩＫは、例えばエアインタフェースにおける伝送のために過度に大きい帯域幅を必要としなくするために、どのコーデックをＩＭＳネットワークのプロバイダが所望しているかも考慮することができる。シグナリング経過およびインプリメンテーションを簡単なものに維持するために、ＭＩＫがＩＭＳにおける端末によっても支援される確率の高い音声コーデックおよびビデオコーデックをそれぞれ１つだけ選択する、例えばＨ．２６３コーデックおよびＡＭＲコーデックを選択する場合には有利である。これによって、選択されたコーデックが実際にＣＳ側およびＩＭＳにおいて支援される場合にはステップ７，８，１１および１２を省略することができる。これに対して、ＣＳ側およびＩＭＳにおいて支援されるそれぞれの１つの所定の音声コーデックおよび所定のビデオコーデックをＭＩＫが知らない確率が高い場合には、ある程度の確率で少なくともメッセージ７および８を省略するために、対象となる全てのコーデックを採用する。

コネクション確立がＩＭＳから他のＭＩＫに転送される場合にインターワーキングを容易にするために、ＭＩＫが付加的に「クリアモード」コーデック、ＲＦＣ４０４０も挿入する場合には有利である。クリアモードコーデックによって、ＢＳ３０データサービスをトランスパレントにＩＭＳを介して転送することも可能である。

３ トランスポートコネクションがＣＳネットワーク側で確立される。続いて、トランスポートコネクションを介してＨ．２２３マルチプレクサレベルのインバンド交渉が行われ、Ｈ．２４５メッセージを交換するための論理的なＨ．２２３チャネルが開かれる。

４ ＭＩＫはトランスポートコネクションにおいてＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージ５を待機する。本発明によれば、例えば別のＭＩＫがＣＳ側に存在するためにＭＩＫが所定時間このメッセージを受信しない場合にのみ、ＭＩＫはＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを送信し、このＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージにおいて、ＭＩＫはメッセージ２において送信した音声コーデックおよびビデオコーデック、もしくはメッセージ６が既に到来している場合にはこのメッセージ６において受信した音声コーデックおよびビデオコーデックを表す。

５ ＭＩＫはトランスポートコネクションにおいてＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを受信する。このメッセージには、個々のコーデックのどのオプションが支援され、またどのコーデックを並行して支援することができるかが正確に表されている、ＣＳネットワーク側の端末の性能、殊に支援するビデオコーデック（例えばＨ．２６３およびＨ．２６１）および音声コーデック（例えばＧ．７１１およびＡＭＲ）についての情報が含まれている。

６ ＭＩＫはＩＭＳ側において、ＳＤＰ ａｎｓｗｅｒを包含するＳＩＰメッセージを受信する。ＳＤＰ ａｎｓｗｅｒには、メッセージ２において提供されたコーデックのリストのうちＩＭＳ側の端末によって支援および所望されるコーデック、例えば音声コーデックとしてのＡＭＲまたビデオコーデックとしてのＨ．２６３およびＭＰ４Ｖ−ＥＳが包含されているが、クリアモードコーデックは包含されていない。本発明によればＭＩＫはメッセージ５において受信したコーデックとメッセージ６において受信したコーデックとを比較する。これらのコーデックが一致する場合、またはその一部（例えばＨ．２６３およびＡＭＲ）が少なくともプロバイダの許容するそれぞれ少なくとも１つの音声コーデックおよびビデオコーデックを包含する場合には、ＭＩＫは直接的にステップ９を継続する。

７ メッセージ２と比較して付加的なコーデック（例えばＨ．２６１ビデオコーデックおよびＧ．７１１音声コーデック）がメッセージ５に包含されていた場合には、例えばこれらの付加的なコーデックがより高い品質を提供するか、ＭＩＫのプロバイダによって好まれるため、もしくは事前に求められたコーデックの一部が音声コーデックおよび／またはビデオコーデックを包含していないために、その付加的なコーデックがＩＭＳ側において支援されるか否かを検査することが望ましいということをＭＩＫは判断できる。例えばＭＩＫはＨ．２６１ビデオコーデックがＩＭＳ側において支援されるか否かを検査することを決定する。本発明によれば、検査を実施するためにＭＩＫはコーデックの一部また付加的に検査すべきコーデックを包含するＳＤＰ ｏｆｆｅｒを用いて、適切なＳＩＰメッセージ、例えばｒｅ−ＩＮＶＩＴＥメッセージまたはＵＰＤＡＴＥメッセージを送信する。

８ ＭＩＫがメッセージ７を送信した場合には、ＭＩＫはＳＩＰメッセージにおけるＳＤＰ「ａｎｓｗｅｒ」を再び受信する。ＳＤＰ「ａｎｓｗｅｒ」には、メッセージ６において提供されたコーデックのリストのうちＩＭＳ側の端末によって支援および所望されるコーデック、例えば音声コーデックとしてのＡＭＲまたビデオコーデックとしてのＨ．２６３が包含されている。

９ 本発明によれば、メッセージ４が送信されなかった場合、またはこのメッセージ４に包含されているコーデックがメッセージ８において受信したコーデック、もしくはステップ７および８がスキップされた場合にはメッセージ６において受信したコーデックとは異なる場合、ＭＩＫはメッセージ８において受信した音声コーデックおよびビデオコーデックならびにコーデックコンフィギュレーションの詳細、もしくはステップ７および８がスキップされた場合にはメッセージ６において受信した音声コーデックおよびビデオコーデックならびにコーデックコンフィギュレーションの詳細をＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを用いて転送する。

メッセージ４ないし９において転送されたコーデックおよびメッセージ５において受信したコーデックの一部がそれぞれ１つの音声コーデックおよびビデオコーデックしか包含していない場合、ステップ１１をステップ１０に並行して実施することは有利である。

１０ いわゆるＨ．２４５「Ｍａｓｔｅｒ−Ｓｌａｖｅ−Ｄｅｔｅｒｍｉｎａｔｉｏｎ」、すなわち「マスター」端末ないし「スレーブ」端末の決定が実施される。「Ｍａｓｔｅｒ−Ｓｌａｖｅ−Ｄｅｔｅｒｍｉｎａｔｉｏｎ」メッセージを既に「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージ５および４ないし９と一緒に送信することもできる。「Ｍａｓｔｅｒ−Ｓｌａｖｅ−Ｄｅｔｅｒｍｉｎａｔｉｏｎ」はリソース衝突を解消することにしか関与しないので、本発明においてはこれ以上考察しない。Ｈ．２４５を用いて、音声およびビデオを伝送するためのＨ．２２３プロトコルのいわゆる論理チャネルが開かれる。メッセージ５および４ないし９において伝送されたコーデックの一部からそれぞれ１つの音声コーデックおよびビデオコーデックが選択される。

１１ 本発明によれば、メッセージ６ないし８において１つ以上の音声コーデックまたは１つ以上のビデオコーデックが包含されていた場合、ＭＩＫがステップ１０において選択された音声コーデックおよびビデオコーデックが表されているＳＤＰ「ｏｆｆｅｒ」を用いて、ＭＩＫは適切なＳＩＰメッセージ、例えばｒｅ−ＩＮＶＩＴＥメッセージまたはＵＰＤＡＴＥメッセージを送信する。

１２ ＭＩＫがメッセージ１１を送信した場合には、ＭＩＫは所属のＳＤＰ「ａｎｓｗｅｒ」を包含するＳＩＰメッセージを受信する。

図３は、以下では「ＩＭＳ起源」（ＩＭＳ−Ｏ）コール確立と称する、ＩＭＳ側からＣＳネットワークの方向へのコール確立の場合における、例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができるマルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＨ．２４５シグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングの原理をシグナリング経過を用いて示したものである。ここでは本発明に直接的に関連するメッセージのみが示されている。

シグナリングステップの詳細は以下の通りである：
１ ＭＩＫは、ＩＭＳ側の端末が支援し、且つこのコールに対して使用されることが所望される音声コーデック（例えばＡＭＲ）およびビデオコーデック（例えばＨ．２６３およびＭＰ４−ＥＳ）に関する情報を包含するＳＤＰ「ｏｆｆｅｒ」を有するＳＩＰ「ＩＮＶＩＴＥ」メッセージを受信する。ＭＩＫはビデオコーデックおよび音声コーデックの組み合わせにおいてビデオテレフォニーが所望されることを識別する。

２ ＭＩＫはいわゆるＢＩＣＣまたはＩＳＵＰ「ＩＡＭ」メッセージをＣＳ側に送信し、このＩＳＵＰ「ＩＡＭ」メッセージにおいてビデオテレフォニーが所望されることを表す。しかしながら、ＩＡＭメッセージはビデオテレフォニーのために使用されるべき音声コーデックおよびビデオコーデックに関する情報を包含していない。

３ ＭＩＫはＩＭＳ側において、ＳＤＰ ａｎｓｗｅｒを包含するＳＩＰメッセージを送信する。このことは多くの場合において、ＲＦＣ３２６１におけるＳＩＰ内のＳＤＰ「ｏｆｆｅｒ」および「ａｎｓｗｅｒ」の伝送についての特別な規則に基づき、コネクションの確立を遅延させないため、またコネクションの確立中に後続のＳＩＰメッセージおよびＩＳＵＰ／ＢＩＣＣメッセージの有意義なインターワーキングを実現するために、ステップ４におけるＣＳ側でのトランスポートコネクションの確立の前に既に必要である。本発明によればＭＩＫは、メッセージ１において提供されたコーデックのリストのうちＣＳ側においてＨ．３２４／Ｍビデオテレフォニーに関して支援される可能性が高いコーデック（例えばＨ．２６３ビデオコーデックおよびＡＭＲ音声コーデック）をＳＤＰ ａｎｓｗｅｒに挿入するコーデックを選択する際にＭＩＫは、例えばエアインタフェースにおける伝送のために過度に大きい帯域幅を必要としなくするために、どのコーデックをＩＭＳネットワークのプロバイダが所望しているかも考慮することができる。

シグナリング経過およびインプリメンテーションを簡単なものに維持するために、ＭＩＫが音声コーデックおよびビデオコーデックをそれぞれ１つだけ選択する、例えばＨ．２６３コーデックおよびＡＭＲコーデックを選択する場合には有利である。これによって、選択されたコーデックが実際にＣＳ側において支援される場合にはステップ７および８を省略することができる。

ＭＩＫがメッセージ３を送信する前に既にメッセージ６を受信していた場合には、ＭＩＫはメッセージ１および６におけるコーデックの一部からそれぞれ１つの音声コーデックおよびビデオコーデックを選択し、この選択したコーデックをメッセージ３に挿入する。

４ トランスポートコネクションがＣＳネットワーク側で確立される。続いて、トランスポートコネクションを介してＨ．２２３マルチプレクサレベルのインバンド交渉が行われ、Ｈ．２４５メッセージを交換するための論理的なＨ．２２３チャネルが開かれる。

５ ＭＩＫはトランスポートコネクションにおいてＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージ６を待機する。本発明によれば、例えば別のＭＩＫがＣＳ側に存在するためにＭＩＫが所定時間このメッセージを受信しない場合にのみ、ＭＩＫはＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを送信し、このＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージにおいて、ＭＩＫはメッセージ３において送信した音声コーデックおよびビデオコーデックを表す。

６ ＭＩＫはトランスポートコネクションにおいてＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを受信する。このメッセージにはＣＳネットワーク側の端末の性能、殊に支援するビデオコーデック（例えばＭＰ４Ｖ−ＥＳおよびＨ．２６１）および音声コーデック（例えばＧ．７１１およびＡＭＲ）についての情報が含まれている。本発明によれば、ＭＩＫはメッセージ５において受信したコーデックをメッセージ３において送信したコーデックと比較する。メッセージ３においてビデオコーデックおよび音声コーデックがそれぞれ１つだけ選択されており、またそれらのコーデックがメッセージ６に包含されていた場合には、ＭＩＫは直接的にステップ９を継続する（例えばメッセージ３において送信したビデオコーデックＨ．２６３はメッセージ５に包含されていない）。

７ 本発明によれば、ＭＩＫはメッセージ６において受信したコーデックをメッセージ１において送信したコーデックと比較する。ＭＩＫはメッセージ６および１におけるコーデックの一部からそれぞれ１つの音声コーデックおよびビデオコーデックを選択する。本発明によればＭＩＫはこれらのコーデックを適切なＳＩＰメッセージ、例えばｒｅ−ＩＮＶＩＴＥまたはＵＰＤＡＴＥメッセージ内のＳＤＰ「ｏｆｆｅｒ」メッセージにおいて送信する。

８ ＭＩＫがメッセージ７を送信した場合には、ＭＩＫはＳＩＰメッセージにおけるＳＤＰ「ａｎｓｗｅｒ」を再び受信する。ＳＤＰ「ａｎｓｗｅｒ」においてＩＭＳの端末はメッセージ６からコーデックを選択することを確認しなければならない。ＩＭＳの端末はこれらのコーデックを既に自身でメッセージ１において提供していたので、これらのコーデックを許容する。

９ 本発明によれば、メッセージ５が送信されなかった場合、ＭＩＫはメッセージ７において送信した音声コーデックおよびビデオコーデックならびにコーデックコンフィギュレーションの詳細、もしくはステップ７および８がスキップされた場合にはメッセージ３において送信した音声コーデックおよびビデオコーデックならびにコーデックコンフィギュレーションの詳細をＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを用いて転送する。メッセージ５およびメッセージ７が送信されており、それらのメッセージに包含されているコーデックが異なる場合、ＭＩＫは同様にＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージを送信し、またこのＨ．２４５「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージにおいてメッセージ７に包含されているコーデックを表す。

１０ いわゆるＨ．２４５「Ｍａｓｔｅｒ−Ｓｌａｖｅ−Ｄｅｔｅｒｍｉｎａｔｉｏｎ」、すなわち「マスター」端末ないし「スレーブ」端末の決定が実施される。「Ｍａｓｔｅｒ−Ｓｌａｖｅ−Ｄｅｔｅｒｍｉｎａｔｉｏｎ」メッセージを既に「Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ」メッセージ６および５ないし９と一緒に送信することもできる。「Ｍａｓｔｅｒ−Ｓｌａｖｅ−Ｄｅｔｅｒｍｉｎａｔｉｏｎ」はリソース衝突を解消することにしか関与しないので、本発明においてはこれ以上考察しない。Ｈ．２４５を用いて、音声およびビデオを伝送するためのＨ．２２３プロトコルのいわゆる論理チャネルが開かれる。メッセージ５ないし９において既に選択された音声コーデックおよびビデオコーデックが使用される。

図４は、ＩＭＳ終端コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＣＳネットワークはいわゆる「ｆｏｒｗａｒｄ ｅａｒｌｙ ｍｅｄｉａ」を支援する、すなわちＢＩＣＣ「ＡＮＭ」メッセージの前に既に発呼側から送信された有効データを転送するようコンフィギュレートされていることを前提とする。ＩＭＳ側ではＳＩＰ「前提条件（Preconditions）」（ＩＥＴＦ ＲＦＣ３３１２）、「更新（Ｕｐｄａｔｅ）」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用される。ＩＭＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１ ＭＩＫはいわゆる「ＩＡＭ」メッセージをＣＳ側から受信する。ＳＣＵＤＩＦシグナリングによればこの「ＩＡＭ」メッセージ内にはコーデックリストが含まれており、このコーデックリストは音声テレフォニーに関して使用すべきコーデックを表し、またビデオテレフォニーのためのプレスホルダとしていわゆる「ＭｕＭｅ」ダミーコーデックを表し、この「ＭｕＭｅ」ダミーコーデックはＨ．３２４Ｍによるビデオテレフォニーが支援されるが、その場合どの音声コーデックおよびビデオコーデックが支援されるかは示さない。ＭｕＭｅコーデックは第１のコーデックとしてコーデックリストに含まれているのでＣＳ側では好まれる。すなわちビデオテレフォニーが所望されている。

２ ＭＩＫはＩＡＭメッセージをＳＩＰ「ＩＮＶＩＴＥ」メッセージに変換する。本発明によれば、ＭＩＫはこのメッセージに包含されているＳＤＰ「ｏｆｆｅｒ」において、図２におけるステップ２に関して既に説明したように、Ｈ．３２４ビデオテレフォニーに関してＣＳ側において支援される可能性が高い音声コーデック（例えばＡＭＲ）およびビデオコーデック（例えばＨ．２６３およびＭＰ４Ｖ−ＥＳ）に関する情報を表す。ＩＭＳ側において音声テレフォニーが選択される場合であっても円滑なコール確立を保証するために、択一的に本発明によればＭＩＫがメッセージ１に包含されている音声コーデックを表してもよい。ＭＩＫは、コール確立を終了できるようになる前にトランスポートコネクションの確立が局所的に必要であることを示すためにＳＩＰ「前提条件」拡張を使用する。このことはいわゆる「クリッピング」、すなわち一貫したトランスポートコネクションが存在する前に、被発呼側によって送信される音声またはビデオの損失を回避するために有利である。

３ ＳＩＰ「Ｔｒｙｉｎｇ」メッセージによりＩＮＶＩＴＥメッセージに応答する。

４ ＭＩＫはＩＭＳ側から、ＳＤＰ「ａｎｓｗｅｒ」を包含するＳＩＰ「１８３」メッセージを受信する。ＳＤＰ ａｎｓｗｅｒには、メッセージ２において提供されたコーデックのリストのうちＩＭＳ側の端末によって支援および所望されるコーデックが包含されている。ＭＩＫはビデオコーデックが包含されていること、ビデオテレフォニーが所望されていることを識別し、図２におけるメッセージ５に関して詳述したように処理を行う。

５ ＭＩＫは、いわゆる「利用可能コーデックリスト（available codec list）」としてＭｕＭｅコーデック、また本発明によればメッセージ１においてもメッセージ４においても包含されていた音声コーデックが包含されている「ＡＰＭ」メッセージを送信する。「選択されたコーデック（selected codec）」として「ＭｕＭｅ」コーデックが表される。すなわち本発明によれば、ＭＩＫはアウトオブバンドＢＩＣＣコーデック交渉の規則を遵守するために、Ｈ．３２４Ｍを用いるビデオテレフォニーにのみ関係する音声コーデックをメッセージ４から除去する。

６ ＳＩＰ「１００ｒｅｌ」拡張によればＭＩＫは１８３メッセージの受信をＳＩＰ「ＰＲＡＣＫ」メッセージにより確認する。

７ ＳＩＰ「ＰＲＡＣＫ」メッセージが確認される。

８ トランスポートコネクションがＣＳネットワーク側で確立される。

９ ＣＳネットワーク側においていわゆる「連続性チェック（Continuity Check）」プロシージャが使用される場合には、ＭＩＫはいわゆるＢＩＣＣ「ＣＯＴ」メッセージを受信する。

１０ ＣＳネットワークのトランスポートコネクションによって、Ｈ．２２３マルチプレクサレベルのインバンド交渉ならびに図２において説明したＨ．２４５交渉が行われる。

１１〜１２ 図２においてメッセージ７および８に関して説明したように、Ｈ．２４５交渉中にＳＤＰ「ｏｆｆｅｒ」および「ａｎｓｗｅｒ」を送信することができる。これらはＳＩＰ「ＵＰＤＡＴＥ」メッセージ（ＩＥＴＦ３３１１）を用いて伝送される。

１３ Ｈ．２４５インバンド交渉の終了後に、本発明によればＭＩＫはＳＩＰ「前提条件」拡張を用いて、トランスポートコネクションの局所的な確立が終了していることをシグナリングする。必要に応じてメッセージを図２のメッセージ１１と結合することができる。ＳＩＰ「ＵＰＤＡＴＥ」メッセージは相応のＳＤＰの伝送に使用される。

１４ ＳＩＰ「ＵＰＤＡＴＥ」メッセージが確認される。

１５ ＳＩＰ「Ｒｉｎｇｉｎｇ（呼び出し）」メッセージが受信される。

１６ メッセージ１５に由来する情報が「ＡＣＭ」メッセージとして転送される。

１７ 被発呼側の加入者はコールを受け取る。ＭＩＫはＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」メッセージを受信する。

１８ メッセージ１７に由来する情報が「ＡＮＭ」メッセージとして転送される。

１９ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」が確認される。

図５は、ＩＭＳ終端コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用される。ＩＭＳ端末が音声テレフォニーのみを支援することを前提とする。

シグナリングステップの詳細は以下の通りである：
１〜３ 図４に示した通りである。

４ ＭＩＫはＩＭＳ側から、ＳＤＰ「ａｎｓｗｅｒ」を包含するＳＩＰ「１８３」メッセージを受信する。ＳＤＰ ａｎｓｗｅｒには、メッセージ２において提供されたコーデックのリストのうちＩＭＳ側の端末によって支援および所望されるコーデックが包含されている。ＭＩＫは、音声コーデックしか包含されていないことに基づき音声テレフォニーが所望されていることを識別する。

５ ＭＩＫは、いわゆる「利用可能コーデックリスト」として、本発明によればメッセージ１においてもメッセージ４においても包含されていた音声コーデックが包含されているＢＩＣＣ「ＡＰＭ」メッセージを送信する。「選択されたコーデック」として音声コーデックが表される。すなわち本発明によれば、ＭＩＫはアウトオブバンドＢＩＣＣコーデック交渉の規則を遵守するために、Ｈ．３２４Ｍを用いるビデオテレフォニーにのみ関係する音声コーデックをメッセージ４から除去する。

６〜１６ コール確立はＴＳ２９．１６３に記載されているように行われる。

図６は、ＩＭＳ終端コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＣＳネットワークがいわゆる「ｆｏｒｗａｒｄ ｅａｒｌｙ ｍｅｄｉａ」を支援しない、すなわちＢＩＣＣ「ＡＮＭ」メッセージの前に発呼側から送信された有効データを転送しないようコンフィギュレートされていることを前提とする。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用される。ＩＭＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１〜９ 図４に示した通りである。

１０ ＭＩＫがコンフィギュレーションによってＣＳネットワーク側では「ｆｏｒｗａｒｄ ｅａｒｌｙ ｍｅｄｉａ」は支援されないことを既に知っている場合、ＭＩＫはこのステップをスキップする。そうでない場合ＭＩＫは、Ｈ．２２３マルチプレクサレベルを交渉するために、所定の時間にわたりトランスポートコネクションにおいてＨ．２２３シグナリングの受信を待機する。本発明によれば、ＭＩＫは「ｆｏｒｗａｒｄ ｅａｒｌｙ ｍｅｄｉａ」が支援されないことを確認し、以下において説明するように処理を行う。

１１ コール確立を継続するために、本発明によればＭＩＫは「前提条件」拡張を用いて、トランスポートコネクションの局所的な確立が終了していることをシグナリングする。「クリッピング」、すなわち一貫したトランスポートコネクションが存在する前に、被発呼側によって送信される音声またはビデオの損失を回避するために、本発明によれば有利には、ＭＩＫがＳＤＰにおけるメディアをＲＦＣ３２６４に記載されているように「ｈｏｌｄ」にセットする。これはＭＩＫがメディアにいわゆる「ｉｎａｃｔｉｖｅ」属性を設けることによって行われる。ＳＩＰ「ＵＰＤＡＴＥ」メッセージは相応のＳＤＰの伝送に使用される。

１２ ＳＩＰ「ＵＰＤＡＴＥ」メッセージが確認される。

１３ ＳＩＰ「Ｒｉｎｇｉｎｇ」メッセージが受信される。

１４ メッセージ１３に由来する情報が「ＡＣＭ」メッセージとして転送される。

１５ 被発呼側の加入者はコールを受け取る。ＭＩＫはＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」メッセージを受信する。

１６ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」メッセージが確認される。

１７ メッセージ１５に由来する情報が「ＡＮＭ」メッセージとして転送される。

１８ ＣＳネットワークのトランスポートコネクションによって、Ｈ．２２３マルチプレクサレベルのインバンド交渉ならびに図２において説明したＨ．２４５交渉が行われる。

１９〜２０ 図２においてメッセージ７および８に関して説明したように、Ｈ．２４５交渉中にＳＤＰ「ｏｆｆｅｒ」および「ａｎｓｗｅｒ」を送信することができる。これらはＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージを用いて伝送される。

２１ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」２０が確認される。

２２ ＭＩＫがメッセージ１１内のメディアを「ｈｏｌｄ」にセットしている場合には、ＲＦＣ３２６４に記載されているように、ＭＩＫは「ｉｎａｃｔｉｖｅ」属性を有していないＳＤＰを送信することによってＨ．２４５インバンド交渉の終了後にメディアをアクティブにする。必要に応じてメッセージを図２のメッセージ１１と結合することができる。ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージは相応のＳＤＰの伝送に使用される。

２３ ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージが確認される。

２４ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」２３が確認される。

図７は、ＩＭＳ終端コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）および「更新」（ＩＥＴＦ ＲＦＣ３３１１）拡張は使用されないが、ＳＩＰ「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張は使用される。ＩＭＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１ 図４に示した通りである。

２ ＭＩＫはＩＡＭメッセージをＳＩＰ「ＩＮＶＩＴＥ」メッセージに変換する。本発明によれば、ＭＩＫはこのメッセージに包含されているＳＤＰ「ｏｆｆｅｒ」において、図２におけるステップ２に関して既に説明したように、Ｈ．３２４ビデオテレフォニーに関してＣＳ側において支援される可能性が高い音声コーデック（例えばＡＭＲ）およびビデオコーデック（例えばＨ．２６３およびＭＰ４Ｖ−ＥＳ）に関する情報を表す。ＩＭＳ側において音声テレフォニーが選択される場合であっても円滑なコール確立を保証するために、択一的に本発明によればＭＩＫがメッセージ１に包含されている音声コーデックを表してもよい。「クリッピング」、すなわち一貫したトランスポートコネクションが存在する前に、被発呼側によって送信される音声またはビデオの損失を回避するために、本発明によれば有利には、ＭＩＫがＳＤＰにおけるメディアをＲＦＣ３２６４に記載されているように「ｈｏｌｄ」にセットする。これはＭＩＫがメディアにいわゆる「ｉｎａｃｔｉｖｅ」属性を設けることによって行われる。

３〜１０ 図４に示した通りである。

１１〜１５ 図４におけるメッセージ１５〜１９と同様である。

１６〜１７ 図２においてメッセージ７および８に関して説明したように、Ｈ．２４５交渉中にＳＤＰ「ｏｆｆｅｒ」および「ａｎｓｗｅｒ」を送信することができる。これらはＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージを用いて伝送される。

１８ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」メッセージが確認される。

１９ ＭＩＫがメッセージ２内のメディアを「ｈｏｌｄ」にセットしている場合には、ＲＦＣ３２６４に記載されているように、ＭＩＫは「ｉｎａｃｔｉｖｅ」属性を有していないＳＤＰを送信することによってＨ．２４５インバンド交渉の終了後にメディアをアクティブにする。必要に応じてメッセージを図２のメッセージ１１と結合することができる。ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージは相応のＳＤＰの伝送に使用される。

２０ ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージが確認される。

２１ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」メッセージが確認される。

図８は、ＩＭＳ終端コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用されない。ＩＭＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１〜３ 図７に示した通りである。

４ コール確立を継続するためにＭＩＫはＢＩＣＣ「ＡＰＭ」メッセージを送信する。この時点においてＭＩＫはＩＭＳ側においてビデオテレフォニーが許容されるか否か、またどのコーデックが支援されるかを知らない。ＭＩＫは、ビデオテレフォニーが許容され、メッセージ１に包含されているコーデックのリストからＩＭＳ側において支援される可能性が高い音声コーデック、例えば「ＡＭＲ」コーデックを選択することを前提とする。ＭＩＫはこれらの音声コーデックおよび「ＭｕＭｅ」コーデックをいわゆる「利用可能コーデックリスト」に挿入する。「選択されたコーデック」として「ＭｕＭｅ」コーデックが表される。

５〜９ 図７におけるメッセージ８〜１２と同様である。

１０ ＭＩＫはＩＭＳ側からＳＤＰ「ａｎｓｗｅｒ」を包含するＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」メッセージを受信する。ＳＤＰ ａｎｓｗｅｒには、メッセージ２において提供されたコーデックのリストのうちＩＭＳ側の端末によって支援および所望されるコーデックが包含されている。ＭＩＫはビデオコーデックが包含されていること、ビデオテレフォニーが所望されていることを識別し、図２におけるメッセージ５に関して詳述したように処理を行う。

１１〜１８ 図７におけるメッセージ１４〜２１と同様である。

図９は、ＩＭＳ終端コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用されない。ＩＭＳ端末が音声テレフォニーのみを支援することを前提とする。

シグナリングステップの詳細は以下の通りである：
１〜９ 図９に示した通りである。

１０ ＭＩＫはＩＭＳ側からＳＤＰ「ａｎｓｗｅｒ」を包含するＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」メッセージを受信する。ＳＤＰ ａｎｓｗｅｒには、メッセージ２において提供されたコーデックのリストのうちＩＭＳ側の端末によって支援および所望されるコーデックが包含されている。ＭＩＫは、ビデオコーデックは包含されていないが、音声コーデックは包含されていること、音声テレフォニーが所望されていることを識別する。

１１ ＭＩＫはＨ．２２３およびＨ．２４５交渉を中止する。

１２〜１３ 図９におけるメッセージ１１および１２と同様である。

１４ ＭＩＫがメッセージ２内のメディアを「ｈｏｌｄ」にセットしている場合には、ＲＦＣ３２６４に記載されているように、ＭＩＫが「ｉｎａｃｔｉｖｅ」属性を有していないＳＤＰを送信することによってＨ．２４５インバンド交渉の終了後にメディアをアクティブにする。ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージは相応のＳＤＰの伝送に使用される。

１５ ＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージが確認される。

１６ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」１５が確認される。

１７〜１８ ＭＩＫはＣＳネットワーク側において音声テレフォニーに切り換えるために、いわゆるＢＩＣＣ「Ｃｏｄｅｃ Ｍｏｄｉｆｉｋａｔｉｏｎ」プロシージャを使用する。

図１０は、ＩＭＳ終端コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＩＳＵＰシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークはいわゆる「ｆｏｒｗａｒｄ ｅａｒｌｙ ｍｅｄｉａ」を支援する、すなわちＢＩＣＣ「ＡＮＭ」メッセージの前に既に発呼側から送信された有効データを転送するようコンフィギュレートされていることを前提とする。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用される。ＩＭＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１ ＭＩＫはいわゆるＩＳＵＰ「ＩＡＭ」メッセージをＣＳ側から受信し、シグナリングされたパラメータに基づき、例えばパラメータＴＭＲにおける値「ＵＤＩ」ならびにパラメータ「ＵＳＩ」における適切な値に基づきビデオテレフォニーが所望されることを識別または推定する。

２ ＭＩＫはＩＡＭメッセージをＳＩＰ「ＩＮＶＩＴＥ」メッセージに変換する。本発明によれば、ＭＩＫはこのメッセージに包含されているＳＤＰ「ｏｆｆｅｒ」において、図２におけるステップ２に関して既に説明したように、Ｈ．３２４ビデオテレフォニーに関してＣＳ側において支援される可能性が高い音声コーデック（例えばＡＭＲ）およびビデオコーデック（例えばＨ．２６３およびＭＰ４Ｖ−ＥＳ）に関する情報を表す。ＭＩＫは、コール確立を終了できるようになる前にトランスポートコネクションの確立が局所的に必要であることを示すためにＳＩＰ「前提条件」拡張を使用する。このことはいわゆる「クリッピング」、すなわち一貫したトランスポートコネクションが存在する前に、被発呼側によって送信される音声またはビデオの損失を回避するために有利である。

ビデオテレフォニーが所望されているのか他のデータサービスが所望されているのかをＭＩＫが確実に判断できない場合には、ＭＩＫは付加的に他のデータサービスにとって適切なコーデック、例えばＲＦＣ３３６２に準拠するＦＡＸコーデック「ｔ３８」を挿入することができる。被発呼側の端末が所定のデータサービスしか支援しない場合には、相応のデータサービスが選択される。発呼側は場合によっては同様に、端末がこの所定のデータサービスのみを支援し、相応にこのデータサービスを送信することを知っている。

３〜４ 図４に示した通りである。

６〜７ 図４におけるメッセージ７〜８と同様である。

７〜１７ 図４におけるメッセージ９〜１９と同様である。

図１１は、ＩＭＳ終端コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＳＩＰシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用されない。ＩＭＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１〜３ 図１０に示した通りである。

４〜１６ 図８におけるメッセージ６〜１８と同様である。

図１２は、ＩＭＳ起源コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用される。ＣＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１ ＭＩＫは、ＳＤＰ「ｏｆｆｅｒ」を包含するいわゆるＳＩＰ「ＩＮＶＩＴＥ」メッセージを受信する。ＳＤＰ ｏｆｆｅｒには、ＩＭＳ側の端末によって支援され、コールに関して所望されるコーデックが包含されている。ＭＩＫはビデオコーデックが包含されていること、ビデオテレフォニーが所望されていることを識別し、図３におけるメッセージ１に関して詳述したように処理を行う。

２ ＭＩＫはいわゆる「ＩＡＭ」メッセージをＣＳ側へ送信する。ＳＣＵＤＩＦシグナリングによればこの「ＩＡＭ」メッセージ内にはコーデックリストが含まれており、このコーデックリストは音声テレフォニーに関して使用すべきコーデックを表し、またビデオテレフォニーのためのプレスホルダとしていわゆる「ＭｕＭｅ」ダミーコーデックを表し、この「ＭｕＭｅ」ダミーコーデックはＨ．３２４Ｍによるビデオテレフォニーが支援されるが、その場合どの音声コーデックおよびビデオコーデックが支援されるかは示さない。音声コーデックとしてＭＩＫは有利にはメッセージ１に包含されているコーデックを選択する。ＭＩＫはＭｕＭｅコーデックを第１のコーデックとしてコーデックリストに挿入し、ビデオテレフォニーが所望されていることを表す。

３ ＳＩＰ「Ｔｒｙｉｎｇ」メッセージがＩＮＶＩＴＥメッセージに応答する。

４ ＭＩＫはＢＩＣＣ「ＡＰＭ」メッセージを受信し、このＢＩＣＣ「ＡＰＭ」メッセージにはいわゆる「選択されたコーデック」として「ＭｕＭｅ」コーデックが表されている。これによりＭＩＫはＣＳ端末もビデオテレフォニーを支援することを識別する。ＭｕＭｅコーデックの「利用可能なコーデックリスト」には音声コーデックが含まれており、ＣＳ端末はこの音声コーデックを音声テレフォニーに関して支援する。

５ トランスポートコネクションがＣＳネットワーク側で確立される。

６ ＭＩＫはＩＭＳ側に、図３におけるメッセージ３に関して詳細に説明したように、ＳＤＰ「ａｎｓｗｅｒ」を包含するＳＩＰ「１８３」メッセージを送信する。

７ ＳＩＰ「１００ｒｅｌ」拡張によればＭＩＫは１８３メッセージの確認としてのＳＩＰ「ＰＲＡＣＫ」メッセージを受信する。

８ ＳＩＰ「ＰＲＡＣＫ」メッセージが確認される。

９ ＭＩＫはＳＩＰ「ＵＰＤＡＴＥ」メッセージを受信し、このＳＩＰ「ＵＰＤＡＴＥ」メッセージはＳＩＰ「前提条件」拡張を用いて、ＩＭＳの側においてトランスポートコネクションの局所的な確立が終了していることを示す。

１０ ＣＳネットワーク側においていわゆる「連続性チェック」プロシージャが使用される場合には、ＭＩＫはいわゆるＢＩＣＣ「ＣＯＴ」メッセージを送信する。

１１ ＳＩＰ「ＵＰＤＡＴＥ」メッセージが確認される。

１２ ＣＳネットワークのトランスポートコネクションによって、Ｈ．２２３マルチプレクサレベルのインバンド交渉ならびに図３において説明したＨ．２４５交渉が行われる。

１３〜１４ 図３においてメッセージ７および８に関して説明したように、Ｈ．２４５交渉中にＳＤＰ「ｏｆｆｅｒ」および「ａｎｓｗｅｒ」を送信することができる。これらはＳＩＰ「ＵＰＤＡＴＥ」メッセージ（ＩＥＴＦ３３１１）を用いて伝送される。この時点においてメッセージ２０が既に送信されていた場合には、「ＵＰＤＡＴＥ」メッセージの代わりにＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージが使用される。

１５ 「ＡＣＭ」メッセージが受信される。

１６ メッセージ１５に由来する情報がＳＩＰ「Ｒｉｎｇｉｎｇ」メッセージとして転送される。

１７ 被発呼側の加入者はコールを受け取る。ＭＩＫは「ＡＮＭ」メッセージを受信する。

１８ メッセージ１７に由来する情報がＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」として転送される。

１９ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」が確認される。

図１３は、ＩＭＳ起源コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用される。ＣＳ端末が音声テレフォニーのみを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１〜３ 図１２に示した通りである。

４ ＭＩＫはＢＩＣＣ「ＡＰＭ」メッセージを受信し、このＢＩＣＣ「ＡＰＭ」メッセージには「利用可能なコーデックリスト」として音声コーデックのみが包含されている。これによりＭＩＫはＣＳ端末が音声テレフォニーのみを支援することを識別する。

５ トランスポートコネクションがＣＳネットワーク側で確立される。

６ ＭＩＫはＩＭＳ側に、メッセージ１に関するＳＤＰ「ａｎｓｗｅｒ」を包含するＳＩＰ「１８３」メッセージを送信する。このメッセージにおいてＭＩＫは音声コーデックのみを表す。

７〜１６ 音声テレフォニーに関するコール確立はＴＳ２９．１６３に記載されているように行われる。

図１４は、ＩＭＳ起源コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＢＩＣＣシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＣＳネットワークにおいては３ＧＰＰ ＴＳ２３．１７２に準拠する「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ ａｎｄ ＵＤＩ Ｆａｌｌｂａｃｋ」（ＳＣＵＤＩＦ）が使用される。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張は使用されない。ＣＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１〜５ 図１２に示した通りである。

６ ＣＳネットワーク側においていわゆる「連続性チェック」プロシージャが使用される場合には、ＭＩＫはいわゆるＢＩＣＣ「ＣＯＴ」メッセージを送信する。

７ ＣＳネットワークのトランスポートコネクションによって、Ｈ．２２３マルチプレクサレベルのインバンド交渉ならびに図３において説明したＨ．２４５交渉が行われる。

８ 「ＡＣＭ」メッセージが受信される。

９ 情報がＳＩＰ「Ｒｉｎｇｉｎｇ」メッセージとして転送される。

１０ 被発呼側の加入者はコールを受け取る。ＭＩＫは「ＡＮＭ」メッセージを受信する。

１１ ＭＩＫはＩＭＳ側に、図３におけるメッセージ３に関して詳細に説明したように、ＳＤＰ「ａｎｓｗｅｒ」を包含するＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」メッセージを送信する。

１２ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」が確認される。

１３〜１４ 図３においてメッセージ７および８に関して説明したように、Ｈ．２４５交渉中にＳＤＰ「ｏｆｆｅｒ」および「ａｎｓｗｅｒ」を送信することができる。これらはＳＩＰ「ｒｅ−ＩＮＶＩＴＥ」メッセージを用いて伝送される。

１５ ＳＩＰ「２００ＯＫ（ＩＮＶＩＴＥ）」が確認される。

図１５は、ＩＭＳ起源コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＩＳＵＰシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張が使用される。ＣＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１ 図１２に示した通りである。

２ ＭＩＫはいわゆる「ＩＡＭ」メッセージをＣＳ側へ送信する。ＭＩＫはこの「ＩＭＡ」メッセージにおいて、例えばパラメータＴＭＲに関する値「ＵＤＩ」およびパラメータ「ＵＳＩ」における適切な値を選択することによってビデオテレフォニーが所望されていることを表す。

３ 図１２に示した通りである。

４〜１７ 図１２におけるメッセージ６〜１９と同様である。

図１６は、ＩＭＳ起源コール確立の場合における、マルチメディアインターワーキングノード（ＭＩＫ）を介する、ＣＳ側におけるＩＳＵＰシグナリングとＩＭＳ側におけるＳＩＰ／ＳＤＰ呼制御シグナリングとの間のインターワーキングをシグナリング経過を用いて示したものである。ＭＩＫは例えばＭＧＣＦおよびＩＭ−ＭＧＷから構成することができる。ＩＭＳ側ではＳＩＰ「前提条件」（ＩＥＴＦ ＲＦＣ３３１２）、「更新」（ＩＥＴＦ ＲＦＣ３３１１）および「１００ｒｅｌ」（ＩＥＴＦ ＲＦＣ ３２６２）拡張は使用されない。ＣＳ端末がビデオテレフォニーを支援および許容することを前提とする。

シグナリングステップの詳細は以下の通りである：
１ 図１４に示した通りである。

２ ＭＩＫはいわゆる「ＩＡＭ」メッセージをＣＳ側へ送信する。ＭＩＫはこの「ＩＭＡ」メッセージにおいて、例えばパラメータＴＭＲに関する値「ＵＤＩ」およびパラメータ「ＵＳＩ」における適切な値を選択することによってビデオテレフォニーが所望されていることを表す。

３ 図１４に示した通りである。

４〜３ 図１４におけるメッセージ６〜１５と同様である。

本発明による方法を使用することができるデータネットワークの実施形態の概略図。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。 本発明において使用されるプロトコルにおけるメッセージのシグナリング経過。

Claims (25)

1. 電話網（ＣＳ）およびインターネットプロトコルベースのＩＰネットワーク（ＩＭＳ）を包含するデータネットワークにおいてビデオ電話コネクションおよび／またはマルチメディア電話コネクションを確立する方法において、
   ａ） 前記電話網（ＣＳ）内または前記電話網（ＣＳ）に隣接する第１の加入者（ＭＳ１）と、前記ＩＰネットワーク（ＩＭＳ）内または前記ＩＰネットワーク（ＩＭＳ）に隣接する第２の加入者（ＭＳ２）との間において、前記電話網（ＣＳ）内の第１のシグナリングプロトコル（ＢＩＣＣ）および前記ＩＰネットワーク（ＩＭＳ）内の第２のシグナリングプロトコル（ＳＩＰ）を用いて、前記電話網（ＣＳ）および前記ＩＰネットワーク（ＩＭＳ）を介するコール確立を実施するステップと、
   ｂ） 前記コール確立の際に、前記第１のシグナリングプロトコル（ＢＩＣＣ）のシグナリングメッセージを前記第２のシグナリングプロトコル（ＳＩＰ）のシグナリングメッセージに変換する、および／または、前記第２のシグナリングプロトコル（ＳＩＰ）のシグナリングメッセージを前記第１のシグナリングプロトコル（ＢＩＣＣ）のシグナリングメッセージに変換するステップと、
   ｃ） 前記ステップｂ）において、前記ビデオ電話コネクションの間に交換される有効データを伝送する際に前記電話網（ＣＳ）において使用可能である、および／または、使用可能であると見込まれる１つまたは複数のコーディングを決定するステップと、
   ｄ） 前記ステップｃ）において決定されたコーディングを、前記第２のシグナリングプロトコル（ＳＩＰ）の１つまたは複数のシグナリングメッセージを用いて前記ＩＰネットワーク（ＩＭＳ）に送信するステップと、
   ｅ） 前記コール確立の実施後および／または実施中に前記ビデオ電話コネクションの間に交換される前記有効データを伝送するためのデータコネクションを確立するステップと、
   ｆ） 前記データコネクション内で前記電話網（ＣＳ）の側において第３のシグナリングプロトコル（Ｈ．２４５）を用いて、前記有効データに関して使用されるコーディングを決定するステップとを有することを特徴とする、方法。
2. 前記データネットワークは３ＧＰＰネットワーク（３ＧＰＰ＝3rd Generation Partnership Project）である、請求項１記載の方法。
3. 前記電話網はＣＳネットワーク（ＣＳ＝Circuit Switched）および／またはＰＳＴＮネットワーク（ＰＳＴＮ＝Public Swiched Telephone Network）である、請求項１または２記載の方法。
4. 前記第１のシグナリングプロトコルはＢＩＣＣ（ＢＩＣＣ＝Bearer Independent Call Control）および／またはＩＳＵＰ（ＩＳＵＰ＝ISDN User Part）である、請求項１から３までのいずれか１項記載の方法。
5. 前記ＩＰネットワーク（ＩＭＳ）はＩＭＳネットワーク（ＩＭＳ＝IP Multimedia Subsystem）である、請求項１から４までのいずれか１項記載の方法。
6. 前記第２のシグナリングプロトコルはＳＩＰ／ＳＤＰ（ＳＩＰ＝Session Initiation Protocol；ＳＤＰ＝Session Description Protocol）である、請求項１から５までのいずれか１項記載の方法。
7. 前記ＳＩＰ／ＳＤＰプロトコルは前提条件拡張を包含し、該前提条件拡張を用いて前記ステップｆ）の後に前記電話網（ＣＳ）におけるトランスポートコネクションの確立が終了していることをシグナリングする、請求項６記載の方法。
8. 前記ステップｂ）からｄ）を前記電話網（ＣＳ）と前記ＩＰネットワーク（ＩＳＭ）との間の１つまたは複数のインタフェースノードにおいて実施する、請求項１から７までのいずれか１項記載の方法。
9. 前記インタフェースノードはＭＧＣＦノード（ＭＧＣＦ＝Media Gateway Control Function）およびＩＭ−ＭＧＷノード（ＩＭ−ＭＧＷ＝IMS Media Gateway）を包含する、請求項８記載の方法。
10. 前記ステップｅ）における前記データコネクションの確立をＨ．３２４プロトコルファミリー、例えばＨ．３２４Ｍプロトコルファミリーを用いて行う、請求項１から９までのいずれか１項記載の方法。
11. 前記ステップｃ）における１つまたは複数のコーディングを使用される電話網（ＣＳ）に依存して決定する、請求項１から１０までのいずれか１項記載の方法。
12. 前記ステップｃ）における１つまたは複数のコーディングを前記第１の加入者（ＭＳ１）の電話番号に依存して決定する、請求項１から１１までのいずれか１項記載の方法。
13. 前記ステップｃ）において、使用される電話網（ＣＳ）および使用されるＩＰネットワーク（ＩＳＭ）に依存して両方のネットワークにおいて使用される可能性が最も高いコーディング方法を決定する、請求項１から１２までのいずれか１項記載の方法。
14. 前記第１のシグナリングプロトコルの前記シグナリングメッセージには、前記電話網（ＣＳ）において使用可能な音声コーディングに関する情報が包含されており、例えば前記ステップｃ）において該音声コーディングを決定する、請求項１から１３までのいずれか１項記載の方法。
15. 前記ステップｆ）における前記データコネクションの確立の際に、１つまたは複数の第１の仕様メッセージ（ＴＣＳ）を前記電話網（ＣＳ）において伝送し、該第１の仕様メッセージ（ＴＣＳ）は前記第１の加入者（ＭＳ１）において使用可能なコーディングをそれぞれ規定する、請求項１から１４までのいずれか１項記載の方法。
16. 前記第１の仕様メッセージ（ＴＣＳ）において規定されているコーディングを前記ステップｃ）において決定されたコーディングと比較する、請求項１５記載の方法。
17. 前記比較により前記第１の仕様メッセージ（ＴＣＳ）において規定されているコーディングと前記ステップｃ）において決定されたコーディングとが一致しない、または部分的にしか一致しないことが判明した場合には、前記第２のシグナリングプロトコル（ＳＩＰ）のシグナリングメッセージを前記ＩＰネットワークに送信し、該シグナリングメッセージは少なくとも部分的に前記第１の仕様メッセージ（ＴＣＳ）において規定されているコーディングを包含する、請求項１６記載の方法。
18. 第２の加入者（ＭＳ２）において使用可能なコーディングを規定する、前記第２のシグナリングプロトコル（ＳＩＰ）のシグナリングメッセージをＩＰネットワーク（ＩＭＳ）に伝送し、該シグナリングメッセージ内に包含されているコーディングを、第２の仕様メッセージを用いて前記ステップｅ）における前記データコネクションの確立の際に前記電話網（ＣＳ）に送信する、請求項１から１７までのいずれか１項記載の方法。
19. 第２の加入者（ＭＳ２）において使用可能なコーディングを規定する、前記第２のシグナリングプロトコル（ＳＩＰ）のシグナリングメッセージを第１の仕様メッセージと比較し、該シグナリングメッセージにおいてビデオ電話コネクションに関して必要とされるコーディングと前記第１の仕様メッセージとが一致しない場合には、ビデオ電話コネクションの確立を中止するか、音声テレフォニーへの切り換えを有利には３ＧＰＰ標準３ＧＰＰ ＴＳ２３．１７２に準拠するＳＣＵＤＩＦ−「Ｓｅｒｖｉｃｅ Ｃｈａｎｇｅ」プロシージャを用いて指示する、請求項１８記載の方法。
20. 前記ステップｃ）において決定されたコーディングは音声コーデックおよびビデオコーデックを包含する、請求項１から１９までのいずれか１項記載の方法。
21. 前記ステップｃ）において決定されたコーディングは音声コーデックおよびビデオコーデックの他に別のデータコーディングを包含する、請求項２０記載の方法。
22. 前記データコネクション、例えば前記電話網（ＣＳ）におけるトランスポートコネクションを確立する所定のステップが終了するまで有効データが伝送されないことを前記第２の加入者（ＭＳ２）に通知する、請求項１から２１までのいずれか１項記載の方法。
23. 電話網（ＣＳ）およびインターネットプロトコルベースのＩＰネットワーク（ＩＭＳ）を包含するデータネットワークにおいて、
    請求項１から２２までのいずれか１項記載の方法を実施するよう構成されていることを特徴とする、データネットワーク。
24. 請求項１記載の方法のステップｂ）からｄ）を実施する、前記電話網（ＣＳ）と前記ＩＰネットワーク（ＩＭＳ）との間の１つまたは複数のインタフェースノードを有する、請求項２３記載のデータネットワーク。
25. 前記インタフェースノードはＭＧＣＦノード（ＭＧＣＦ＝Media Gateway Control Function）およびＩＭ−ＭＧＷノード（ＩＭ−ＭＧＷ＝IMS Media Gateway）を包含する、請求項２４記載のデータネットワーク。

Images