JP4527664B2 - ２台の端末の間で通信セッションを確立する方法および装置 - Google Patents

Description

本発明は、一般的に、２台の端末間でセッションパラメータの決定を必要とする通信セッションを確立するための方法および装置に関する。特に、本発明は、当該セッションで使用するパラメータを決定するときの、セッション設定手順の時間を短縮することに関する。

固定及び携帯電話は、今日まで主に音声通話のために使用されてきた。ＳＭＳ（Ｓｈｏｒｔ Ｎｅｓｓａｇｅ Ｓｅｒｖｉｃｅ、ショートメッセージサービス）メッセージのような限定されたテキストメッセージを携帯端末間で通信するサービスも利用可能である。これらはかなり簡明な電気通信サービスであり、多かれ少なかれ確定された要求条件の下で既に確立された技術を使用する。固定電話と携帯電話の両方またはどちらかの端末間の通話に使用される標準的な通信プロトコルにおいては、予め定義された通信規則とパラメータのセットが典型的に使用され、このセットは端末にとって既知であり、端末の能力の範囲内にある。この結果、そのようなそれぞれの端末にとって有効な確定した通信パラメータに基づいて、呼端末と被呼端末の双方が通話を実行できると推定される。それ故、使用するパラメータ、例えば、伝送方式や符号化方式に関するパラメータを、両端末が予め「知っている」ところであるため、単純な音声通話のような従来の通話が、極めて迅速に確立できる。従って、通話が確立され、実行される以前に、どの規則やどのパラメータを使用するかを決める手順を必要としない。

今日、多くの異なる電話サービスが開発されつつあるが、特に、新しい通信技術が導入されてより大きなネットワーク容量とより高速な伝送速度を提供するのに伴い、これらの電話サービスの利用が可能になるであろう。例えば、ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ、汎用パケット無線サービス）とＷＣＤＭＡ（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ、広帯域符号分割多元接続）の技術が、現在、広範囲の異なるデータ速度を必要とする無線電話サービスを可能にするために登場している。

いくつかの新しいサービスは、オーディオ情報とともにビデオ情報の実時間伝送を含み、さらに、種々の異なる形式とその組み合わせにより、テキスト、文書、画像、オーディオファイル、ビデオファイルなどを表現する追加的なデータの伝送も含み得る。このようなサービスは、一般に、「マルチメディア」サービスと呼ばれ、本明細書では、この用語を、通常の音声に加えて情報の伝送を含み、セッションパラメータの決定を必要とする、あらゆる電話サービスを表すのに使用する。

このような新しいサービスに適した機能を備える非常に多くの高度な新しい携帯端末が、市場で入手できるようになりつつある。結果として、各端末は、例えばコーデック（コーダ／デコーダ）、表示機能、伝送速度などに関して、多くの異なる能力を備える。本明細書においては、用語「端末」を、任意のタイプの通信局を広義に表すものとして使用し、あるいは、多地点会議ユニット（ＭＣＵ）を用いた会議では端末の集合を広義に表すものとして使用する。そして、この文脈では、ＭＣＵは、端末の集合を表す。

必然的に生じる問題は、マルチメディアサービスを使用する個々の特定のセッションの必須条件はもはや固定されておらず、予め知り得ないものとなり、要求されたサービス、呼端末及び被呼端末それぞれの能力、およびその他の要因に依存して変わることである。望みの情報を通信するために、セッション中に、呼端末及び被呼端末の両方が、ある種の所謂セッションパラメータを使用しなくてはならない。そのようなセッションパラメータは、通信規則を定め、利用可能なコーデックや多重化方式にも関連する可能性があるが、これについては後にさらに詳細に述べる。

セッションパラメータは、さらに、予め定められたユーザの希望条件や加入条件にも依存する。これらの条件は、個々の加入者に対して予め定められていたり、あるいは、特定の加入者グループに対して定められることもある。それ故、マルチメディアサービスに関連する２台の端末間のセッションを確立するためには、セッション設定手順において最初にセッションパラメータが選択されて決定されねばならず、その後実際のセッション或いは呼が開始され、それらのセッションパラメータを使用することができる。

図１に、２台の端末Ａ、Ｂ間の典型的な通信シナリオを図示する。この場合、端末Ａは携帯端末であり、例えばＷＣＤＭＡネットワークなどの移動アクセスネットワーク１００に無線接続される。他方、端末Ｂは、固定電話であり、例えばＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｃｈｅｄ Ｔｅｌｅｐｈｏｎｙ Ｎｅｔｗｏｒｋ、公衆交換電話ネットワーク）などの固定アクセスネットワーク１０２に接続される。この２つのアクセスネットワーク１００と１０２は、次には、実際には任意のタイプの通信ネットワーク、あるいは異なるネットワークの組み合わせであったりする、汎用「バックボーン」ネットワーク１０４に接続される。ネットワーク１００、１０２、１０４は、多かれ少なかれ周知の伝送技術を用いることがこの例では想定され、それ故、ここではこれ以上の説明を必要としない。

この例では、ビデオ情報とオーディオ情報の両方の双方向伝送を含むビデオセッションを構築するために、端末Ａが端末Ｂに発呼する。Ａ、Ｂ各端末は、それぞれ表示画面Ｓａ及びＳｂを備え、両者とも実時間でビデオとオーディオとに関する通信および表示ができる。この点で、端末Ａ、Ｂは、ほぼ同じ能力を有する。しかしながら、これら２台の端末は、上記の説明のようにコーデックや多重化方式に関して異なる能力を持つ見込みが極めて高いが、各端末は他方のことを知らない。それ故端末Ａ、Ｂは、この後のコールセッションの間に両者が使用できる、適する共通のセッションパラメータを協議し、合意するために、双方の特定の能力や希望条件に関する情報を交換しなくてはならない。特に、端末はコード／デコード方式（すなわちコーデックのタイプ）を選択し、利用可能な帯域幅が適切な方法で活用されるように、所定の物理チャネルにおいてビデオ情報とオーディオ情報のための異なるデータストリームをミックスする多重化方式について合意しなくてはならない。

Ｈ．３２４は、国際電気通信連合の電気通信標準化部門（ＩＴＵ−Ｔ）が定めた実時間ビデオおよびオーディオに関連するマルチメディアコール（呼）の標準である。Ｈ．３２４は、異なる能力を有し、また極めて多様な異なるサービスの利用を可能にする端末間で、そのような通信に柔軟に対処するために立案された。特に、３Ｇ−３２４Ｍと呼ばれる仕様は、Ｈ．３２４を基に、既存の回線交換無線ネットワークを介する無線マルチメディアサービスの実時間通信をサポートするために定められた。本発明は、Ｈ．３２４で規定されるいかなる手順にも制限され、制約されることは無いが、マルチメディアコールが本ソリューションに従い確立されることができる一つの例としてこの標準を参照する。

従って、端末Ａ、Ｂ間のビデオ通話が始まる前に、通信セッションを確立し、通話で使用するセッションパラメータを決定しなくてはならない。Ｈ．３２４によれば、通信セッションの確立は、ベアラ設定フェイズとセッション設定フェイズを含む２つの手順に分けられる。

ベアラ設定フェイズでは、通信の物理チャネルが双方向において端末Ａ、Ｂ間で全通信経路に亘って確保される。通話が対称か非対称かによって、物理チャネルは両方向で類似するか、あるいは異なりうる。エンドツーエンドの物理チャネルは、例えば、無線チャネルと、固定の回線交換音声またはデータチャネルとのうち、少なくとも一方のチャネルなどの異なる中間ネットワークを介した一連の経路を含む。しかしながら、ベアラ設定フェイズの詳細については、本発明に関係しないので、ここでは、これ以上述べない。

物理チャネルが確立したとき、セッション設定フェイズは、如何なる中間ノードの関与もなく２台の端末によってのみ実行される。両端末がコールセッションの間利用できる、上記のセッションパラメータを決定するために、セッション設定フェイズが実行される。それ故、所定の物理チャネルがどのように活用されるかは、完全に端末に委ねられる。セッション設定フェイズは、代表的には１） 端末能力情報の交換、２） マスター・スレーブの決定、３） 多重化方式の選択、４） 論理チャネルの開設、といったいくつかのステップを含む。基本的にはＨ．３２４標準で規定されているように、これらの手順のステップを、図２のフローチャートを参照して次に簡単に説明する。

最初のステップ２００では、端末能力が交換され、それぞれの端末が他方の端末に、端末が処理できるコーデックの種類と１組の多重化パラメータを含むリストを少なくとも送信して、それによってその能力を通知する。Ｈ．３２４では、そのような情報を「ＴＣＳ」（Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ、端末の能力セット）メッセージの中で送付し、それぞれの受信端末は、その受信を確認しなくてはならない。端末能力の更新のために、セッション中に随時、このメッセージを再度送信できる。

次のステップ２０２におけるマスター・スレーブの決定は、例えば、セッション設定の間の通信協議における信号の競合を避けるために、一方の端末をマスターに、他方の端末をスレーブに指定するために必要な手順である。Ｈ．３２４によれば、各端末は、「ＳＤＮ」（Ｓｔａｔｕｓ Ｄｅｔｅｒｍｉｎａｔｉｏｎ Ｎｕｍｂｅｒ、状態決定番号）と呼ぶ２４ビットの乱数を生成して、これを「ＭＳＤ」（Ｍａｓｔｅｒ−Ｓｌａｖｅ Ｄｅｔｅｒｍｉｎａｔｉｏｎ、マスター・スレーブの決定）メッセージに入れて送信し、これは受信端末でも同様に確認をしなくてはならない。次に、２つのＳＤＮが比較され、予め定められた規則に則り、マスター・スレーブの指定があいまいさを残すことなく決まる。マスター・スレーブの指定は、実際のセッションの間にも使用され得る。

上記のベアラ設定フェイズで確立する物理チャネルを介して伝送するために、複数の情報ストリームを、単一のビットストリームに様々な方法で多重化することができるかを制御する、複数の多重化方式が好適に定められた。それぞれが少なくとも１つの論理チャネルを必要とする、オーディオ、ビデオ、制御情報、及び、オプションで他のデータのために、ビデオ通話は典型的には少なくとも３つの別々の情報ストリームを必要とする。利用可能な帯域幅、即ち所与の物理チャネルを最適に利用するために、異なるストリーム間の比率が各ストリームにおける伝送の必要性によって動的に変えられる。例えば、Ｈ．３２４は、パケットと呼ぶ予め定義されたデータシーケンスにおける、オーディオ、ビデオ、データ、制御情報の種々のストリームの割当を制御する種々の多重化テーブルを定める、Ｈ．２２３と呼ばれる多重化標準を用いる。多重化テーブルに規定されるように、任意の数の論理チャネルが使用され得る。

パケットのビット位置に、各パケットは種々のパターンの論理チャネル割当を含むことができ、チャネル割当は連続する各パケットにおいても異なり得る。パケット長も可変にできる。個々の特定のパケットに対するチャネル割当方法は、各パケットのヘッダに含まれるショートワードのインデックス番号で示されるように選択する多重化テーブルの登録によって決定する。その際、多重化に関してそれ以上のオーバーヘッド情報を転送する必要はない。しかしながら、各インデックス番号に対する多重化パケット構造はまずセッション設定フェイズの間に定義されなくてはならない。

従って、マスター・スレーブ決定ステップ２０２に続いて、次のセッションの間に使用する多重化テーブルの設定に関して、端末が協議し、合意をする次のステップ２０４において、適当な多重化方式が選択される。次いでＨ．３２４に従い、各端末は、インデックス番号リストとそれぞれのパケット構造の定義を含む、所謂「ＭＥＳ」（Ｍｕｌｔｉｐｌｅ ｔａｂｌｅ Ｅｎｔｒｙ Ｓｅｎｄ、多重化テーブル登録の送信）メッセージを送信する。受信端末は、また、応答ＭＥＳメッセージの中で、提案されたインデックスとパケット構造に対する確認もしくは拒否をしなくてはならない。セッションの間に随時、さらなるＭＥＳメッセージにおいて、新しく、かつ、更新された多重化テーブルを送ることもできる。もし、未定義のインデックス番号を持つパケットを受信すると、そのパケットは受信端末で廃棄される。

最後にステップ２０６において、要求されたサービスもしくは複数のサービスに必要な全ての論理チャネルを両端末に共通な端末能力に基づいて確立する（すなわち、「開設」する）。それぞれの特定のメディアストリームに対して、セッションの間に両端末が使用できる、最も優先度の高いコーデックをそのストリームのために選択することが好ましい。Ｈ．３２４によれば、一方もしくは両方の端末は、ステップ２００で他の端末から受信したＴＣＳメッセージに関して、好ましくは指示された優先度を含む１つもしくは複数のコーデックの提案を含んだ所謂「ＯＬＣ」（Ｏｐｅｎ Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ、論理チャネルの開設）メッセージを他方の端末に送信する。次いで、各受信端末は、提案された１つもしくは複数のコーデックを、自身の能力及び希望（プリファレンス）のうち少なくとも一方に基づいて、受け入れたり拒否したりする。端末が特定の１つのコーデックもしくは複数のコーデックのセットを使用することを最終的に合意すると、それに対応する論理チャネルが確定し、実際のセッション、すなわちビデオ通話が開始されることができる。

上記の例は、通話セッションが実行可能になる前に、セッションパラメータで定められるように所定の通信条件や取り決めがどのように決定されるかを示す。実装によっては、ステップ２０４と２０６の順序も、ステップ２０２と２０４の順序も、逆になり得ることに注意すべきである。この「セッションパラメータ」の用語は、情報が如何に伝達され、解釈されるかを決定する詳細を一般的に表すために、ここで用いている。上記の例は、コーデックと多重化方式に関するセッションパラメータに焦点を当てた。しかしながら、Ｈ．３２４標準の一部であるＨ．２４５標準により、ＯＬＣメッセージに代表的に含まれるエラー訂正／エラー保護に関連するパラメータのような、他の重要なセッションパラメータも必要である可能性がある。

しかしながら、上記のベアラ設定とセッション設定手順は実行に時間がかかる。ベアラ設定フェイズにかかる時間は、２台の携帯端末間の通話を確立するのに７秒から１４秒の範囲と測定されているが、この時間は、現在、利用可能な方法をもっと効率化すれば、恐らく５秒程度に減少できるだろう。セッション設定フェイズにかかる時間は、既存の製品で４秒から７秒の範囲であると測定されている。ベアラ設定フェイズ後にセッション設定フェイズが実行されるので、実際に通話が開始されうるまでの遅延時間は、全体で少なくとも９秒から２１秒の範囲となる。このような大きな遅延時間は、マルチメディアサービスへの魅力を減退させることになるので、大きな障害である。ビデオモードと音声だけのモードとを繰り返し切り替えるときなど、セッション実行中にサービスモードが変わる場合、その遅延は、さらに一層我慢できないものになる。その場合設定手順は、サービスモードの切り替えが起こるたびに繰り返されなければならない。

このため、セッションの確立により課せられる遅延を最小にすることが一般に望まれる。実質的に標準を変更することなく、セッション設定フェイズの時間を減少させることは困難である。なぜなら図２に示したステップのように、セッション設定フェイズは、とりわけいくつもの往復遅延を含む、連続して実行しなくてはならない多くの異なるステップを含んでいるからである。確立されて現在使用中である物理チャネルの品質が悪く、その結果、送信データにビットエラーが生じ、再送信が必要になると、このフェイズでさらに遅延する。特に、通常、Ｈ．３２４のＴＣＳメッセージのように端末能力を含むメッセージは、典型的には極めて長いメッセージであり、再送が発生すれば相当な遅延を引き起こす。そのような長いメッセージは、いくつかの断片に分割されることができ、再び別々に送信されることになる。

一般的に、如何なるタイプのセッション設定に対しても同様の問題が存在する。そのセッション設定では、セッションの確立もしくは再確立のために必要な複数の往復遅延とあいまって、信号メッセージを伝えるチャネルは、長い往復遅延を被ったり、あるいは、伝送すべき情報量に比して狭い帯域しか有さなかったり、あるいは、その両方であったりする。これらの問題が発生するセッション設定のもう一つの仕様の例は、ＳＩＰ、「Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、セッション開始プロトコル」（ＩＥＴＦ ＲＦＣ ３２６１等）である。ＳＩＰは、１台もしくは２台以上のセッション参加端末によってセッションを構築、変更、終了するためのアプリケーション層の制御（信号）プロトコルである。これらのセッションにはインターネットマルチメディア会議、インターネット電話通話、マルチメディア配信が含まれる。

このため、例えばマルチメディアコールにおける、パラメータの決定を必要とするセッションの確立に関連した現状の大きな遅延を削減するソリューションが求められている。特に、新たな標準仕様を必要とすることなく、好ましくは既存の信号メッセージの組み合わせを用いて、現在定められている処理（手順）や標準を依然として使用することが望まれる。

本発明の目的は、上に述べた問題を低減もしくは解消することである。この目的およびその他の目的は、所定の物理チャネルを介して呼端末と被呼端末との間で要求された通信セッションを確立する方法及び装置であって、通信セッションは、該通信セッションが実行される前にセッションパラメータを決定することを必要とするものを提供することにより、達成される。この要求された通信セッションは、少なくともオーディオとビデオが独立したメディアストリームの転送が必要なマルチメディアコールである。

本発明の方法によれば、端末間の以前の通信セッションのためのセッションパラメータが端末において保存されたか否かが、少なくとも１つの利用可能なセッションキーを用いて判断される。セッションパラメータが保存された場合に、保存されたセッションパラメータをそれぞれの端末において読み出され、読み出したセッションパラメータに基づいて要求された通信セッションを実行できるようにする。

利用可能なセッションキー又は利用可能な複数のセッションキーは、２つの端末のうち少なくとも１つの電話番号を含み得る。呼端末は、利用可能なセッションキーとして被呼端末の電話番号を使用でき、電話番号と、保存されたセッションパラメータに関連して保存されたセッションキーとの間で一致を検出する。

セッションキーは、一次的なセッションキーと、対応する二次的なセッションキーとを含む。一次的なセッションキーと保存されたセッションパラメータに関連して保存されたセッションキーとの間で一致を検出した端末の少なくとも１つが、対応する二次的なセッションキーを読み出して他方の端末に送信し得る。一次的なセッションキーが二次的なセッションキーの受信側端末にとって利用可能でない場合も、あるいは、受信側端末が一次的なセッションキーと保存されたいかなるセッションキーとの間でもいかなる一致も検出しなかった場合も、保存されたセッションパラメータを読み出すために受信側端末によって二次的なセッションキーが使用され得る。二次的なセッションキーは、保存されたセッションパラメータが端末間の以前の通信セッションに使用されたことを確認するために使用され得る。

一次的なセッションキーは、２つの端末のうち少なくとも１つの電話番号でよく、二次的なセッションキーは、以前の通信セッションに関連した識別情報でよい。一実施形態においては、二次的なセッションキーは、例えばＩＴＵ−Ｔ Ｈ．２４５標準に従った以前の通信セッションのセッション設定手順においてマスター・スレーブを決定するステップの間に生成された乱数である。二次的なセッションキーの送信側端末は、受信側端末に二次的なセッションキーを伝達するために、乱数を含む標準マスター・スレーブ決定（Ｍａｓｔｅｒ−Ｓｌａｖｅ Ｄｅｔｅｒｍｉｎａｔｉｏｎ：ＭＳＤ）メッセージを使用することができる。ＭＳＤメッセージは、乱数が二次的なセッションキーとして機能するという指示情報も含み得る。ＩＴＵ−Ｔ Ｈ．３２４標準に従い、端末能力セット（Ｔｅｒｍｉｎａｌ Ｃａｐａｂｉｌｉｔｙ Ｓｅｔ：ＴＣＳ）メッセージがセッション設定手順において送信すべき最初のメッセージとして必須である場合、受信側端末は、ＭＳＤメッセージの受信前にＴＣＳメッセージを受信しなかった場合、ＭＳＤメッセージ中の乱数を二次的なセッションキーとして解釈することができる。

他の実施形態においては、二次的なセッションキーは、以前の通信セッションに割り当てられた、独立して定義されたコード、シーケンス番号、またはその種のものである。

さらに他の実施形態においては、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＳＩＰ）に従うセッション設定手順において、送信すべき最初のメッセージとしてＩＮＶＩＴＥメッセージが必須である場合、ＩＮＶＩＴＥメッセージのヘッダフィールド情報が、１以上のセッションキーとして使用され得る。

新たな通信セッションにおいて、保存されたセッションパラメータの使用を可能にするために、端末それぞれは、通信セッション実行中に使用されるセッションパラメータを、少なくとも１つのセッションキーと共に保存する。保存されたセッションパラメータが通信セッション実行中に使用される場合、各々の端末は、保存されたセッションパラメータを以後の通信セッションで使用する能力を確認するメッセージを、他方の端末に送信することが好ましい。

本発明は、さらに、所定の物理チャネルを介して他の端末との要求された通信セッションを確立するように適合された端末であって、通信セッションは、該通信セッションが実行される前にセッションパラメータを決定することを必要とするものを含む。要求された通信セッションは、少なくともオーディオとビデオの分離したメディアストリームの転送を要求するマルチメディアコール（呼）である。本発明の端末は、端末間の以前の通信セッションのためのセッションパラメータが端末において保存されたか否かを、少なくとも１つの利用可能なセッションキーを用いて判断する手段を備える。本発明の端末は、さらに、他の端末も成功裏に同一のセッションパラメータを読み出した場合に、保存されたセッションパラメータを読み出し、読み出したセッションパラメータに基づいて要求された通信セッションを実行できるようにする手段を備える。

端末は、好ましくは、利用可能なセッションキーとして他の端末の電話番号を使用し、電話番号と、保存されたセッションパラメータに関連して保存されたセッションキーとの間で一致を検出するように適合され得る。利用可能なセッションキーは一次的なセッションキーでよく、端末は、一次的なセッションキーと保存されたセッションパラメータに関連して保存されたセッションキーとの間で一致を検出した場合に、対応する二次的なセッションキーを読み出して他の端末に送信するように適合され得る。一次的なセッションキーが二次的なセッションキーの受信側端末にとって利用可能でない場合も、あるいは、受信側端末が利用可能な一次的なセッションキーと保存されたいかなるセッションキーとの間でもいかなる一致も検出しなかった場合も、受信側端末で保存されたセッションパラメータを読み出すために二次的なセッションキーが使用され得る。

利用可能なセッションキーが一次的なセッションキーである場合、端末は、さらに、他の端末から対応する二次的なセッションキーを受信し、二次的なセッションキーと保存されたセッションパラメータに関連して保存されたセッションキーとの間で一致を検出すことにより保存されたセッションパラメータを読み出すために二次的なセッションキーを使用するように適合され得る。端末はまた、保存されたセッションパラメータが端末間の以前の通信セッションに使用されたことを確認するために、二次的なセッションキーを使用するようにも適合され得る。

端末は、一次的なセッションキーとして他の端末の電話番号を使用し、二次的なセッションキーとして以前の通信セッションに関連した識別情報を使用するように適合され得る。一実施形態においては、端末は、二次的なセッションキーとして、例えばＩＴＵ−Ｔ Ｈ．２４５標準に従った以前の通信セッションのセッション設定手順においてマスター・スレーブを決定するステップの間に生成された乱数を使用するように適合され得る。この場合、端末は、さらに、二次的なセッションキーを伝達するために、乱数を含む標準マスター・スレーブ決定（Ｍａｓｔｅｒ−Ｓｌａｖｅ Ｄｅｔｅｒｍｉｎａｔｉｏｎ：ＭＳＤ）メッセージを使用するように適合され得るものであり、好ましくは、二次的なセッションキーとして乱数が機能するという指示情報をＭＳＤメッセージ中に含むように適合されてもよい。

代替的に、端末は、以前の通信セッションに割り当てられた、独立して定義されたコード、シーケンス番号、またはその種のものを二次的なセッションキーとして使用するように適合されてもよい。他の実施形態においては、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＳＩＰ）に従うセッション設定手順において、送信すべき最初のメッセージとしてＩＮＶＩＴＥメッセージが必須である場合、ＩＮＶＩＴＥメッセージのヘッダフィールド情報を１以上のセッションキーとして使用するように適合されてもよい。

端末は、新たな通信セッションにおいて、保存されたセッションパラメータの使用を可能にするために、通信セッション実行中に使用されたセッションパラメータを、少なくとも１つのセッションキーと共に保存するように適合される。端末は、好ましくは、保存されたセッションパラメータを以後のセッションで使用する能力を確認するメッセージを、他の端末に送信するようにも適合されてもよい。

本発明は、例えばマルチメディアコールにおける、パラメータの決定を必要とするセッションの確立に関連する遅延を軽減できる。さらに、新たな標準仕様の確立を必要とすることなく、現在定められている処理（手順）、標準、及び、既存の信号メッセージの組み合わせを依然として好適に使用することが可能である。

添付の図面を参照して、本発明をさらに詳細に説明する。

マルチメディアコールなどのようなセッションパラメータの決定を必要とする、要求されたコールすなわちセッションが２台の端末間で確立されるとき、これら２台の端末がそれ以前に同じようなセッションを実行していた場合に、セッションパラメータの決定手順が大幅に簡略化でき、そのセッション設定に起因する遅延を軽減できる。本ソリューションによると、個々の端末は最初のセッション実行後、最初のセッションの間に使用された関連したセッションパラメータを保存する必要がある。後になって同じ電話サービスを利用して同じ２台の端末間で２回目の類似するセッションを実行するとき、２回目のセッションの間に使用するように、それぞれの端末に保存済のそれ以前のセッションパラメータを再び読み出すことにより、そのセッションのセッションパラメータを決定できる。もし、新たなセッションの必須条件がそれ以前のセッションの条件と基本的に同じであれば、それらのセッションパラメータは依然として適切なものであり、上記のような時間のかかる通常のセッション設定手順中にもう一度決定する必要はない。条件が異なれば、進行中のセッションの間のいつの時点にでもその端末間で適切な更新メッセージを交換することにより如何なるセッションパラメータも変更できる。

本ソリューションの基本的な実施形態を、図３と図４のそれぞれのフローチャートを参照して説明する。図３では、後に使用されるセッションパラメータを保存する手順を説明する。少なくとも所定の複数の端末に本ソリューションを適用するため、これらの端末は、特定のセッションパラメータを決定して使用することが必須のマルチメディアコールのようなセッションを実行するとき、使用されるセッションパラメータを保存する必要がある。

最初のステップ３００では、マルチメディアに関わる通信セッションが、この機能を搭載した２台の端末間で要求される。すなわち、一方の端末が少なくとも１つの特定の電話サービスを要求し、もう一方の端末に発呼する。上記のように、マルチメディアサービスは、通常の音声に加えて情報伝達を伴い、その際に特定のセッションパラメータの決定を必要とする。従って、この場合要求されたセッション中にそのようなパラメータを決定して、使用しなければならないものと想定される。

このようにして、次のステップ３０２で、要求されたセッションのためにセッションパラメータが何らかの方法により決められる。例えば、そのセッションパラメータを上記のように図２に関連して説明したような、通常のセッション設定手順で決めることもできるし、他の方法で決めてもよい。次に、その決定したパラメータに基づき、要求されたセッションをステップ３０４で実行する。このセッションの間に、上の例で述べたようにいくつかのパラメータが更新されてもよい。

このセッションが完了したとき、次のステップ３０６で、不揮発性メモリのような各端末の適当な記憶手段を用いて使用して、通話に参加したそれぞれの端末内に、使用したセッションパラメータを保存する。そのセッションの間にそのパラメータが更新されていたのであれば、パラメータの最新版を保存する方が良い。さらに、関連する１以上のセッションキーを用いて保存済セッションパラメータを後に読み出すことを可能にするために、セッションパラメータと一緒に保存される、そのセッション用の少なくとも１つのキーも選択される。例えば、それぞれの端末は、実行するセッション用の一次的な（プライマリ）セッションキーとして他方の端末の電話番号を保存できる。なぜなら、以後のセッション要求時に、呼端末は少なくとも被呼番号を知っており、被呼端末も、利用可能であれば呼番号の通知機能を用いて呼番号を知ることができるからである。しかし、あらゆる利用可能な端末識別情報が、一次的なキーとしてそれぞれの端末に保存され得るものである。

このソリューションをさらに信頼のおけるものとするために、保存済セッションパラメータを現在のセッションで実際に使用したことを後のセッション要求において確認するために、追加的に二次的な（セカンダリ）セッションキーを任意で使用することもできる。セッションに割り当てられた、独立して定義されたコード、シーケンス番号、またはその種のような、実行したセッションに関連した何らかの識別情報として、二次的なセッションキーを選ぶことができる。そのセッションパラメータの確認を可能にするために、両端末は同じ二次的なセッションキーに合意して保存するか、もしくは、代替方法として既に関係が分かっている別々の異なったキーに合意して保存しなくてはならない。１つの実施形態では、Ｈ．３２４に基づいたセッション設定フェイズの間の、上記のマスター・スレーブ決定ステップにおいて使用される乱数ＳＤＮが、下記のさらに詳細な実施例で述べるように、二次的なセッションキーとしての役割を果たすことができる。

このセッションのセッションパラメータを決定するステップ３０２の間に、端末はそれぞれ後のセッションにおいて、保存済セッションパラメータが使用可能であることを確認するメッセージを交換することが好ましい。例えば現在のセッションがＨ．３２４に従って確立した場合、この「高速設定能力」の情報は、セッション設定フェイズを開始する最初のメッセージであるＴＣＳメッセージに含むことができる。それにより両端末がこの能力を有する場合に限り、端末それぞれが使用済のセッションパラメータを保存できる。そうではなく、一方の端末がこの能力を有しない場合、以後どのようにしてもその高速セッション設定手順を使用できない。この場合、たとえ他方の端末自体では高速設定能力を持っていても、他方の端末が使用済のパラメータを保存する意味がない。次のセッションを始めるときには、それぞれの端末の高速設定能力の情報を交換することによりセッション設定フェイズを開始して、保存済セッションパラメータを読み出し、これを使用する試みを始める。従って一方の端末が高速設定能力を確認しない場合には、他方の端末で高速設定手順を試みるようなことをして時間を無駄にすべきではない。

図４は、以前のセッションにおいてそのようなパラメータを保存していた場合に、如何にして２台の端末が新たなセッション用に以前に決定したセッションパラメータを利用できるかを説明するフローチャートである。最初のステップ４００において、２台の端末Ａ、Ｂ間で、例えばマルチメディアサービスに関わる通信セッションが要求される。このセッションは、端末Ａが端末Ｂに発呼して要求することを想定する。さらに、物理チャネルも、ここでは図示されないが、この手順の一部ではない適当な段階で確保されることを想定する。

次のステップ４０２では、同じ２台の端末間で以前のセッションに関連して、セッションパラメータが保存されたか否かを判定する。この判定ステップ４０２は、例えば一次的なキーとしての役割を果たす両端末の電話番号及び任意で二次的なキーなど、先に述べた利用可能な１つもしくは複数のセッションキーを用いて実行される。例えば、端末Ａに保存済のキーと番号Ｂとを比較することによって、端末Ａが１つのセッションキーとして番号Ｂを持つセッションパラメータを保存したかどうか調べることができるように、当然のことながら呼端末Ａは被呼番号Ｂを知っている。同時に、端末Ｂも同様に呼番号Ａが呼番号通知機能、またはそれに類したものにより端末Ｂにとって利用可能であれば、１つのセッションキーとして番号Ａを持つセッションパラメータを端末Ｂが保存したか調べることができる。

もし、ステップ４０２において、２台の端末内にそれ以前にそれぞれのセッションキーに一致するセッションパラメータが保存されていないと判定されていれば、上記図２に関連して述べられたような通常のセッション設定手順を用いることによって、新たなセッションパラメータをステップ４０４において定義し、決定しなければならない。その後ステップ４０６で、新しいパラメータに基づき、そのセッションを実行できる。この場合、本ソリューションは、ステップ４０４において通常の、そして時間のかかる設定手順が実行されるので、十分効果のあるものにはなり得ない。

しかしながら、ステップ４０２において、例えば、番号Ａと番号Ｂの少なくとも１つと、端末Ａ、Ｂの少なくとも一方に保存済のセッションキーとの間の一致を検出することにより、関係するセッションパラメータがそれ以前に実際に保存されていたと判定されれば、ステップ４０８において、１つもしくは複数のセッションキーを用いて保存済の関連するパラメータを読み出すことができる。もし、いずれかの端末において一致を検出すれば、その端末は他方の端末に１つの対応した二次的なセッションキーを送信することができ、そして、それを受信側端末が保存済の二次的なセッションキーと比較することができる。もし、一致が見つかれば、例えば、番号Ａが使えない（利用可能でない）などにより、受信側端末がそもそも（一次的な）セッションキーへのアクセスできない場合であっても、二次的なセッションキーを用いて、受信側端末は対応するセッションパラメータを読み出せる。一致（マッチング）を成功させた後に、もちろん、それぞれの端末は他方の端末に適当な確認メッセージを送信して、一致したことを伝達することになろう。

もし、両端末が上記のようにセッションキーを用いて、保存済セッションパラメータを首尾よく見つけた場合、ここに示していないが、適当な確認メッセージを交換した後、最後のステップ４１０において、読み出したセッションパラメータに基づき、要求されたセッションを最終的に実行する。それにより、新たなセッションパラメータを定義し、決定するという、時間のかかる通常のセッション設定手順は不要である。なぜなら、それ以前のセッションで保存済のパラメータは、依然として有効であり、その新たなセッションに対しても使用できると想定されるからである。その必須条件はその時点においても基本的に以前と同じである可能性が極めて高い。すなわち、端末ＡとＢはその能力（機能）をそれほど大きくは変えていない可能性が高い。

しかしながら、両端末のいずれかがその能力を変えた場合、あるいは使用する物理チャネルが著しく異なった場合には、そのセッションの間に随時２台の端末間で、適当な更新メッセージを交換することにより、そのセッションパラメータを更新できる。しかしこれは本ソリューションの範囲外で、それ故ここではこれ以上説明しない。代替方法として、両端末のいずれもが、以前に決定して保存したセッションパラメータに頼る代わりに、通常の設定手順を実行することを自由に決定できるようにしてもよい。

２台の端末間で任意的にＨ．３２４の標準メッセージングを用いて、要求された１つのセッションのために、保存済セッションパラメータをどのように読み出し、使用するかについてのさらに詳細な典型的な手順を図５ａから図５ｃに図示されたフローチャートを参照して説明する。上記の実施例にもある通り、１台の端末Ａが端末Ｂに発呼して１つのセッション要求がなされ、１つの物理チャネルも、それ自体図示も説明もしてはいないが、１つのベアラ設定手順において適当な段階でそのセッションのために確保されると想定する。最初のステップ５００において、例えばマルチメディアサービスに関するために特定のセッションパラメータを必要とする通信セッションが、２台の端末Ａ、Ｂ間で要求される。次に、この手順は端末Ｂに関する左の部分と端末Ａに関する右の部分に分岐する。

左の部分のステップ５０２Ｂでは、端末Ｂが例えば番号通知機能により、番号Ａを利用可能か決定する。例えば、端末Ｂが現在接続されているアクセス網が発呼番号通知をサポートしない場合、あるいは番号Ａが秘匿番号（番号非通知）の場合、番号Ａが利用できないこともある。番号Ａを端末Ｂで利用できる場合、ステップ５０４Ｂにおいて一致するかを決定するために、この番号Ａを１つの一次的なセッションキーとして使用でき、端末Ｂに保存済のセッションキーと比較することができる。しかしながら、それぞれステップ５０２Ｂと５０４Ｂからの破線で示したように、番号Ａが利用できない場合、もしくはステップ５０４Ｂで、端末Ｂが番号Ａに対し一致（マッチング）を見出せない場合、後に説明するように端末Ａが（ステップ５０４の「Ｙｅｓ」から）一致を検出するという条件のもと、端末Ｂは依然として、二次的なセッションキーを用いて関係するセッションパラメータを読み出すことができる。

ステップ５００から右側の部分では、ステップ５０４Ａにおいて、当然のことながら端末Ａが一次的なセッションキーとして知る番号Ｂを使用し、保存済セッションキーと比較する。Ａ、Ｂいずれの端末でも一致が見出されない場合、セッションパラメータを読み出せず、ステップ５０６に示したように新たなセッションパラメータを決定するため、通常の（そして時間のかかる）セッション設定手順を実行しなくてはならない。しかしながら、端末Ａがステップ５０４Ａにおいて番号Ｂに一致できるものが見出せない場合でも、端末Ａは端末Ｂが１つの一致を見出す条件のもと（ステップ５０４Ｂの「Ｙｅｓ」から）、ステップ５０４Ａから破線で示したように、依然として二次的なセッションキーを用いて関係するセッションパラメータを読み出すことができる。このようにして、一方、あるいは両方の端末が一致を検出すれば、両者は対応したセッションパラメータを読み出し、高速設定手順を実行できる。取得可能であれば、番号Ａを端末Ｂのための一次的なセッションキーとして役立てることができるし、番号Ｂを端末Ａのための一次的なセッションキーとして役立てることができる。

１つもしくは複数の一次的なセッションキーに対応するセッションパラメータが正しいものであること、すなわちこれら端末Ａ、Ｂ間のそれ以前のセッションで使用されたことを確認するために、二次的なセッションキーは次のように使用されることができる。かくして、一次的なセッションキーとその保存されたデータ間で一致を検出した端末の１台が、図３のステップ３０６に関連して先に説明したように、以前のセッション終了後に保存した対応する二次的なセッションキーを読み出し、次のステップ５０８で他方の受信側端末に二次的なセッションキーを送信することができる。端末ＡとＢのいずれもがこの段階で送信側端末か受信側端末となりうることに注意しなくてはならない。この実施例では、それ以前のセッションの間のマスター・スレーブ決定ステップで生成したＳＤＮを二次的なセッションキーとして保存したが、先に説明したように、実行したセッションに関連したいかなる識別情報も、二次的なセッションキーとして代わりに選択することができる。

そのＳＤＮ（すなわち二次的なセッションキー）を他方の端末に伝達するために、僅かに変更した方法で１つのＭＳＤメッセージを使用し、ステップ５０８におけるこの段階で、二次的なキーとして役立つそれ以前に保存済のＳＤＮを含めて送信することができる。この場合、ＭＳＤメッセージは従来のＭＳＤメッセージにおけるようにマスター・スレーブの指定を決めることを意図するものではないことを受信端末に知らせるために、そのＳＤＮが二次的なキーとして役立つということを示す何らかの指示情報を含めることにより、このＭＳＤメッセージを変更することができる。一実施形態において、ＭＳＤメッセージがあらゆるＴＣＳメッセージよりも前に送信されたという単純な事実をもって、このこと（ＳＤＮが二次的なキーとして役立つということ）を指示することができる。Ｈ．３２４に従えば、それ以外の場合は、ＴＣＳメッセージは一番最初に送信されるメッセージでなければならない。従って、受信側端末は、もしＴＣＳメッセージを事前に受信していなければ、そのＳＤＮメッセージを二次的なセッションキーと解釈する。

ステップ５０４Ａと５０４Ｂにおいて、両端末がそれぞれ一致を検出すると、両端末のうちいずれもが、このケースでは、ＭＳＤメッセージに含まれた二次的なセッションキーを、他方の端末に送信できる。ここでは、一方だけがステップ５０８で二次的なセッションキーを送信すると想定する。明確にするために、この手順の次の部分を２つの別々の図に分割する。図５ｂで二次的なキーを受信する端末が実行するステップを図示し、図５ｃで二次的なキーを送信する端末が実行するステップを図示する。

（ＭＳＤメッセージ中の）二次的なセッションキーを受信すると、受信側端末は受信した二次的なキー（この場合はＳＤＮ）が、図５ｂの次のステップ５１０ｂにおいて保存済の二次的なセッションキーとの一致をチェックする。受信側端末がステップ５１０ｂにおいて一致を検出しない場合、ステップ５１２ｂで拒否メッセージを他方の端末に送信する。この場合次のステップ５１４ｂにおいて、ステップ５０６と同様通常の設定手順が処理を引き継がなければならない。代替方法として、単にタイムアウト後に確認応答が無いことを拒否と解釈してもよく、この場合、ステップ５１２ｂが省略できる。

しかしながら、もし、受信側端末が、ステップ５１０ｂで実際に一致を検出した場合、すなわち、その受信したＳＤＮが保存済の二次的なキーに対応する場合、受信側端末は次のステップ５１６ｂにおいて、関連したセッションパラメータを読み出すことができる。その端末はまたステップ５１８ｂにおいて、標準に従った通常のＭＳＤＡｃｋメッセージのような、適当な高速設定確認メッセージを他方の端末に送信することもできる。次に、その端末はステップ５２０ｂにおいて、読み出したセッションパラメータに基づいてセッションを実行できる状態になる。

図５ｃを参照すると、二次的なキーを送信し終わった端末は、受信側端末から確認もしくは拒否を待つ。もしステップ５１０ｃにおいて、高速設定を確認するメッセージが受信されない場合、（あるいは、拒否メッセージが受信された場合）、その端末は図５ｂのステップ５１４ｂに対応する次のステップ５１４ｃにおいて通常の設定手順に戻る。しかしながら、ステップ５１０ｃにおいて、高速設定確認を受信した場合、その端末はステップ５１６ｃにおいて、二次的なキーあるいは一次的なキー、もしくは両方を使用することにより保存済セッションパラメータを読み出す。最終的に図５ｂのステップ５２０ｂに対応するステップ５２０ｃにおいて、読み出したセッションパラメータに基づいてセッションを実行することができる。

図５ａから図５ｃにおいて前述した手順は、本発明の範囲内においていくつかの方法で変更できる。例えば、ステップ５１８ｂで送信され得る確認応答メッセージを送信側端末が他方の端末から受信したか否かに基づき、送信側端末は決定ステップ５１０ｃを実行してもよい。セッションパラメータを首尾よく読み出した後、両端末が適当な確認メッセージを送信してもよいし、もしくは、確認応答を最初に受信する端末が確認応答を送信する必要がない場合は一方の端末だけが適当な確認メッセージを送信してもよい。

受信側端末が端末Ｂであり、ステップ５０２Ｂで番号Ａを使用できたとすると、端末Ｂはステップ５１０において、受信した二次的なキー（即ちＳＤＮ）を、一次的なキー（即ち番号Ａ）に対応する保存済の二次的なキーと、単純に比較することができる。このことは番号Ｂを常に利用可能な端末Ａが受信側端末である場合にも当てはまる。しかしながら、受信側端末が端末Ｂであり、番号Ａを利用できなかった場合、一致するものがあるかどうかを判定するために、端末Ｂは受信したＳＤＮと他の保存済二次的なキーとを比較しなくてはならない。

たとえ、端末Ｂがステップ５０４Ｂで一致を検出するために、端末Ａの番号が利用可能な状態でないが故に一次的なキーとしてそれを使用できない場合であっても、ステップ５０８、５１０、５１６におけるように二次的なセッションキーを使用して、その状況が救済できることに注意すべきである。このことから二次的なセッションキーの使用が本ソリューションにとって任意的なものであっても、これによって上に述べた状況においても高速セッション設定が可能になり、いずれにせよこの手順の信頼性を著しく高める。本ソリューションによれば、時間のかかる通常の設定手順を出来る限り避けることにより、セッションの確立に含まれる現状の大きな遅延を、著しく低減することができる。（従来の手順の）代わりに本発明の高速設定手順を用いれば、例えば３Ｇ−３２４Ｍコールのセッション設定時間は、およそ１秒よりも小さい値に減少できるであろう。その上、新たな標準規格を必要とせず、本発明の高速設定手順を、現状の定められた手順と標準の中に実装することができる。好ましくは、既存の信号（シグナリング）メッセージのセットを依然として使用することができる。

本発明を実際の応用に実装するかについて、下記にいくつかの一般的な、非制限的な実施態様を示す。以下の項目は、単なる任意的なものであり、そのうちいくつでも実用上考慮されることができることに注意すべきである。

Ａ）本発明の高速セッション設定は、セッションパラメータがほとんど変わらないセッションプロトコルを使用する、明確で「安定した」サービスに特に適している。

Ｂ）受信側端末は、例えば、物理チャネル設定（ここではこれ以上説明しない）の間に送信されるサービスのタイプ（種類）の指示情報を用いて検出できる、適用されるサービスタイプを検出することにより、誤って高速セッション設定を開始することを避けることができる。あるいは、例えば端末のタイプ、ネットワークのタイプ、または被呼番号のタイプから予めサービスのタイプを検出することにより、誤って高速セッション設定を開始することを避けることができる。

Ｃ）本ソリューションはセッション設定の間の信号方式（シグナリング）を変更するだけなので、セッション設定を開始する前に必要な、例えば信号（シグナリング）チャネルの構成や設定などの如何なる手順も、一般的には変更されない。

Ｄ）保存済セッションパラメータを読み出すためのセッションキーとして使用するのに十分一意性のある、少なくとも１つのメッセージまたはパラメータを用いることにより、セッション設定のシグナリングを実行できる。使用されるセッションプロトコルに依存するが、このメッセージまたはパラメータは既存のものでもよいし、あるいはこの目的のために特別に定められた新しいものでもよい。

Ｅ）例えば使用されるネットワークのタイプに依存したケースバイケースの原則における利用可能性に従って、保存済セッションパラメータは、（例えば物理チャネル設定パラメータで指定されるような）サービスタイプや、あるいは、リモート端末の（例えば発呼側の番号のような）識別番号や、あるいは、例えば１つもしくは複数の通常のセッション設定メッセージで提供される適当なパラメータによる情報を含む、セッションキーや、あるいは、これらの任意の組み合わせによってアクセス可能である。たとえ上で述べたキーの１つあるいは複数が現在利用できないか、もしくは一意でない場合でも、特定の実装における要求次第で、本ソリューションは依然としてうまく使用可能であり、発動されうる。リモート端末の登録（エントリ）が、電話帳、またはそれに類するものに存在する場合に限り、保存済セッションパラメータの読み出しを認めることが適切であろう。

Ｆ）セッションの間に、現在使用されているセッションパラメータ（場合により更新されたものも）を、一時記憶部に保存することが好ましい。セッションが終了したとき、全く新しいセッションパラメータが保存されてもよいし、既存のものが置き換えられたり更新されたりしてもよい。そして、セッションパラメータを、例えば現在のセッションキーとしての役割を果たす特定の識別番号、サービスタイプ、または１つもしくは複数のセッションキーなどに対応付ける（マッピングする）。任意的に、ユーザにそのセッションパラメータを保存すべきか廃棄すべきかを選択するよう促すこともできる。ユーザには古いセッションパラメータを上書きするか否かの選択肢も与えられる。例えば、電話番号やそういったものの形で一次的なキーが利用できないときに、例えば既存の電話帳の登録（エントリ）にセッションパラメータを連結することなどにより、後に読み出すためにどのようにセッションパラメータを識別するかをユーザに選択するよう促すこともある。

Ｇ）このソリューションの使用を示唆し、可能であれば１以上のセッションキーの伝達も行うメッセージを、以降、「キーメッセージ」と呼ぶ。このキーメッセージは、受信側で本発明の高速設定手順を認識させるきっかけを与えることを意図する。これは、予期したシーケンスとは別にキーメッセージを受信することで実現するか、もしくは当該の（問題となっている）セッションシグナリングの中で利用可能な他の適当な手段によって検出できる。

Ｈ）受信側（の端末）は、何らかの方法で「キーメッセージ」を拒否し、通常のセッション設定手順へのシームレスなフォールバック（後退）を提供することが可能であるべきである。拒否することは使用されるセッションシグナリングスキーマに依存したいくつかの方法により実現可能であり、明確な拒否メッセージや無応答によるタイムアウトを含むが、これに限るものではない。

Ｉ）セッションパラメータがセッションの間に更新されることは重要ではあるが、必須ではない。もしそのパラメータを新しいセッションの間に更新できれば、やや不適切な保存されたパラメータの影響は減じられる。本ソリューションが、そもそも速やかなセッションの再確立を達成することを意図しているということに注意すべきであり、そのセッションの最初の段階では、そのセッションが何かしら最適では無いということはあまり重要ではない。

Ｊ）任意的に、実行中のセッションで使用される更新されたセッションパラメータのうちどのバージョンが、新たに再確立されるセッションの開始時に有効かを選択するため、所定の方法が用いられ得る。もしそのような方法が利用できない場合には、例えば最初か最後の有効なものを選択するような、特定のソリューションにより、バージョンが決定されなければならない。もし、利用可能であれば、セッションパラメータを伝達するセッションメッセージに対するシーケンス（もしくはその他の）番号が付いた確認応答が使用され得る。この情報は、実現可能であれば、「キーメッセージ」の一部としても伝達可能である。もし、実行中のセッションで、ただ１つのバージョンしか利用できない場合には、何の選択情報も送信してはならない。

Ｋ）保存済セッションパラメータの使用が許されない、もしくは使用可能でないときのいくつかの条件を以下に示す。どちらかの端末が「キーメッセージ」を拒否することにより、通常のセッション設定が開始されることに注意すべきである。従って、以下に概要を示した条件のいずれかが、一方の端末に対して充たされれば十分である。

ａ）例えば２台の端末が最初のセッションを実行する場合、あるいは保存済セッションパラメータが壊れた、失われた、あるいは消去された場合など、如何なる保存済セッションパラメータも利用できない場合。

ｂ）例えばコーデックなどの何らかのセッションパラメータが、新たなセッションに対して、保存済セッションパラメータと矛盾する固定値に設定される場合。そのような設定は、ユーザによってなされたり、あるいは他の手段、例えばハードウエア構成や周辺機器を変更したりすることにより、時々なされる。これは、セッションパラメータが１つのデバイスから取り外され、別のデバイス（このデバイスは保存されるパラメータにとっては、「周辺機器」とみなされる）に挿入される周辺機器（例えばＳＩＭカード）に保存される場合も当てはまる。

ｃ）セッションシグナリングが正常に開始する場合に、セッションシグナリングを著しく変えるような態様で、転送チャネル及びシグナリングチャネルのうち少なくとも一方の構成が、実行されたセッションで使用されたものと異なったときには、任意的に、通常のセッション設定を実行しなくてはならない。例えば３Ｇ−３２４Ｍの特定のケースでは、異なる多重化レベルが使用され得る。

ｄ）結果としてそのサービス設定時間が大きく変わる欠点はあるが、１組（同じ組）のパラメータを繰り返し使用することを避けるため、任意的に、定期的に通常のセッション設定を実行すべきである。

ｅ）任意的に、ユーザによる積極的な選択により、通常のセッション設定を実行することができる。

先の説明の中で、本発明が適用されうる１つの実施例としてＨ．３２４を参照した。代替方法として、ＩＰ（インターネット プロトコル：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ベースのネットワークを介する端末間の通信に対し定義された公知のＳＩＰ（セッション開始プロトコル：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）標準においても、本発明の高速設定手順が適用できる。ＳＩＰでは、セッション設定を開始するため、「ＩＮＶＩＴＥ」と呼ばれる方法が使用され、これは２台の端末間でＳＤＰ（セッション デスクリプション プロトコル：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）と呼ばれるＩＮＶＩＴＥメッセージの交換を含む。このＳＤＰメッセージは、端末がその能力情報を交換する、Ｈ．３２４のＴＣＳメッセージに基本的に対応する。

上に述べた高速設定手順を実装するために、両端末がＳＩＰによりセッションを実行した後で使用したセッションパラメータと共に保存する、共通の二次的なキーとして「Ｃａｌｌ−ＩＤ」と呼ばれる、ＩＮＶＩＴＥメッセージ内のヘッダフィールドが用いられる。さらに、ゼロより大の「ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ」を有するＳＤＰコンテンツを含まなくてはならない通常の設定とは対照的に、高速設定を実行する能力を示すために端末は「ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ＝０」のヘッダフィールドを使用することができる。新しいセッションを開始するとき、伝送経路の中間ノードによって物理チャネルを確立するためにも使用されるので、ＩＮＶＩＴＥメッセージが可能な限り通常のものに近いことは好ましいが、全ＳＤＰを再規定する必要はない。従って、これら中間ノードのための手順変更を避けることは望ましい。その高速設定が何らかの理由で一方の端末で実行できない場合、ＳＤＰによる本文を付した応答を送信したその端末によって、または他にＳＤＰ失敗を示すリターンコードによって、通常の設定手順へのフォールバックが引き起こされ得る。

本発明が、特定の典型的な実施形態を参照して説明されたが、その説明は本発明の考え方を明らかにすることだけを意図したものであり、本発明の範囲を制約すると受け止めるべきではない。種々の代替、変更、および均等物は添付の請求の範囲に定めた本発明の精神から逸脱することなく使用できる。

２台の端末間でビデオ通話を実行するための通信シナリオの概要図である。 従来技術に従ったセッション確立手順の間のセッション設定フェイズを説明するフローチャートである。 本発明に従い、セッションパラメータを保存する手順を説明するフローチャートである。 本発明に従い、新たなセッション用に、これに先立って使用されたセッションパラメータを利用する手順を説明するフローチャートである。 それぞれ本発明に従い、要求されたセッションのためのセッションパラメータを決定する典型的な手順を詳細に説明するフローチャートの一部である。 それぞれ本発明に従い、要求されたセッションのためのセッションパラメータを決定する典型的な手順を詳細に説明するフローチャートの一部である。 それぞれ本発明に従い、要求されたセッションのためのセッションパラメータを決定する典型的な手順を詳細に説明するフローチャートの一部である。

Claims (30)

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. 前記要求されたマルチメディア通信セッションは、少なくともオーディオとビデオの分離したメディアストリームの転送を要求するマルチメディアコール（呼）であることを特徴とする請求項１７乃至２９のいずれか１項に記載の端末。

Images