JP2009506677A

JP2009506677A - 異なるネットワークタイプのアクセスポイントへの無線ＶｏＩＰ／ＶＩＰローミング

Info

Publication number: JP2009506677A
Application number: JP2008528205A
Authority: JP
Inventors: コッティリンガル、サディープ・ラビ
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2005-08-24
Filing date: 2006-08-24
Publication date: 2009-02-12
Anticipated expiration: 2026-08-24
Also published as: CN101292499B; TW200715791A; WO2007025158A1; EP1929744A1; CN101292499A; EP1929744B1; JP5113056B2; US8542668B2; US20070047516A1; TWI326179B; KR100954512B1; KR20080040774A

Abstract

モバイル通信デバイス（例えば、セルラ電話）は、無線ＬＡＮとの無線通信のための１つのエアインタフェースと、セルラ電話ネットワークとのセルラ電話通信のための他のエアインタフェースとを有する。先ず、通信デバイスは、第１のセッションにおいて、エアインタフェースのうちの１つを介して、メディアストリームのＶｏＩＰパケットをターゲット通信デバイスへ送信するために使用される。その後、それは、他のエアインタフェースを使用することが望まれる。ＳＰＡＷＮＳＩＰメッセージがターゲットへ通信される。ターゲットは、ＳＰＡＷＮ識別子を返す。通信デバイスは、ＳＰＡＷＮ識別子を含むＳＩＰＩＮＶＩＴＥを他のエアインタフェースを介してターゲットへ送ることによって第２のセッションをセットアップする。両方のセッションともアクティブなＶｏＩＰセッションである。ターゲットは、第１のセッションと第２のセッションとを関連付けるためにＳＰＡＷＮ識別子を用いる。その後、メディアストリームのＶｏＩＰパケットのフローが、第１のセッションから第２のセッションへと切り換えられる。
【選択図】図１

Description

開示された実施形態は、一般に、ＩＰテレフォニーに関する。

セルラ電話のようなモバイル通信デバイスは、複数のエアインタフェースを有しうる。一例では、セルラ電話は、従来、ＣＤＭＡ（符号分割多元接続）トランシーバを用いたセルラ電話ネットワークを用いて、比較的長距離にわたって通信をすることができる。セルラ電話のＣＤＭＡトランシーバは、セルラ電話ネットワーク上のセルラＢＴＳ（基地送信機サイト）と通信する。更に、セルラ電話は、ＩＥＥＥ８０２．１１トランシーバを用いた無線ローカルエリアネットワーク（ＬＡＮ）を用いて、比較的短距離で通信することができる。セルラ電話の８０２．１１トランシーバは、ＬＡＮ上のアクセスポイントと無線で通信する。

第１のパーティは、ＶｏＩＰ (voice over Internet Protocol）技術を用いて第２のパーティへ通話するために、セルラ電話を使用することができる。音声データは、セルラ電話から、アクセスポイントへの８０２．１１無線リンク、ＬＡＮ、及びインターネットを介してＩＰパケットによって第２のパーティへと通信される。第１のパーティがそのような通話に従事している場合、第１のパーティは、８０２．１１通信リンクがつながらないように、８０２．１１アクセスポイントから移動したいと思っているかもしれない。そのような状況では、セルラ電話ネットワークを用いて通話が継続できるように、通話が失われることなく、より長い距離のセルラ電話ネットワークを用いるように自動的に切り換わることが望まれる。

Ｓａｇｉらへの米国特許公開２００４／０２６４４１０号は、第１の通信デバイスと第２の通信デバイスとの間に第１のＶｏＩＰ (Voice over Internet Protocol) 通話をセットアップするために、ＳＩＰ(Session Initialization Protocol) を用いることを開示する。ＳＩＰＩＮＶＩＴＥメッセージは、第１の通信デバイスから、無線ＬＡＮ上の無線アクセスポイントと第１の通信デバイスとの間の無線リンクや企業サーバを介して、第２の通信デバイスへ渡る。第１の通信デバイスが、無線ＬＡＮの有効範囲領域外への移動を始める場合、企業サーバは、セルラＷＡＮ（広域ネットワーク）上の第１の通信デバイスに関連するプライベート番号へ新たな通話を行う。この新たな通話は、第１の通信デバイスと、セルラＷＡＮのＢＴＳ（セルラ基地送信機サイト）との間の従来式回路切換リンクを含む。従来式の通話セットアップ手順を用いて新たな通話が一旦セットアップされると、企業サーバは、第１の通話と新たな通話とを含む３方式カンファレンス通話を確立する。そして、企業サーバは、無線ＬＡＮによるリンクを終了する。その結果、通話は、第１の通信デバイスからセルラＢＴＳへの回路切換リンクを含む。その結果得られる通話は、幾つかの観点において好ましくない。なぜなら、回路切換リンクを用いることは、たとえハンドオフの対象である通話が、帯域幅量の変動を必要とするか、あるいは、少量の帯域幅を必要とするのみであっても、専用の帯域幅量を確保することを含むからである。未使用の帯域幅を過剰に確保することが、追加コストとなる場合においては、ハンドオフされた通話のコストは、望まれないほど高くなる。

ハンドオフされた通話のコストが望まれないほど高くなるのみならず、専用の企業サーバも必要とされる。そのような企業サーバを提供し、維持することは、費用が高くつくかもしれない。更に、このハンドオフ方法は、そのような企業サーバが展開されていないところでは、実施することができない。たとえ企業サーバが提供されても、２つの通話がともに、企業サーバを通過することが要求される。第１の通信デバイスのユーザが、第２の通話が企業サーバを通過しないセルラネットワークの有効範囲領域へローミングすることが可能である。従って、この通話ハンドオフ方法は、実行することができない。解決策が望まれる。

モバイル通信デバイス（例えば、セルラ電話）は、無線ＬＡＮ（ローカルエリアネットワーク）との無線通信のための１つのエアインタフェースと、セルラ電話ネットワークとのセルラ電話通信のための別のエアインタフェースとを有する。無線ＬＡＮとの無線通信は、例えば、ＩＥＥＥ８０２．１１に従いうる。セルラ電話ネットワークは、例えば、ＣＤＭＡ（符号分割多元接続）電話ネットワークでありうる。

先ずモバイル通信デバイスは、第１のセッションにおいて、エアインタフェースのうちの１つを介して、メディアストリームのデータペイロードＶｏＩＰパケットを、ターゲット通信デバイスへ送信するために使用される。ＶｏＩＰパケットは、ＩＰ（Internet Protocol）、ＵＤＰ（User Datagram Protocol）及びＲＴＰ（Real-Time Protocol）を用いて通信される。ＶｏＩＰメディアストリームは、例えば、モバイル通信デバイスを用いた第１のパーティＡと、ターゲット通信デバイスを用いた第２のパーティＢとの間の会話のための音声データを含む。

そして、モバイル通信デバイスの他のエアインタフェースを用いて通話を継続することが望まれる。これは、例えば、初めは短距離無線ＬＡＮインタフェースとして使用されているエアインタフェースによるものかもしれない。パーティＡは、短距離の無線ＬＡＮの有効範囲領域から出るかもしれない。より長距離のセルラ電話エアインタフェースを用いることに切り換えることによって、通話を継続することが望まれる。あるいは、第１のエアインタフェースを用いることから、第２のエアインタフェースへ切り換えることが望まれる。ここで、第１のエアインタフェースは、より長距離のセルラ電話インタフェースであり、第２のエアインタフェースは、より短距離の無線ＬＡＮインタフェースである。最初はセルラ電話エアインタフェースが使用されるが、次に、パーティＡが、無線ＬＡＮの有効範囲領域へ移動する。例えば、パーティＡのセルラ電話プロバイダが、そのセルラ電話ネットワーク上で音声会話を伝送することに課金するのであれば、パーティＡはそのセルラエアインタフェースを用いることをやめ、より費用の安い無線ＬＡＮエアインタフェースを用いて通話を継続することが望ましい。

最初に使用されていたエアインタフェースから別のエアインタフェースへ切り換えることを望む理由に関わらず、パーティＡのモバイル通信デバイスは、パーティＢのターゲット通信デバイスへＳＰＡＷＮＳＩＰメッセージを送る。ＳＰＡＷＮＳＩＰメッセージは、ＩＰ、ＴＣＰ(Transmission Control Protocol)、及びＳＩＰ(Session Initialization Protocol) を用いて通信される。ターゲットは、ＳＰＡＷＮ識別子を含む２００ＯＫＳＩＰメッセージを送ることによって応答する。その後、モバイル通信デバイスは、他のインタフェースを介してＳＩＰＩＮＶＩＴＥ要求をターゲットへ送ることによって、他のエアインタフェースを介した第２のセッションをセットアップする。ＳＩＰＩＮＶＩＴＥ要求は、ＳＰＡＷＮ識別子を含んでいる。第２のセッションは初期化され、第１及び第２のセッションの両方が、アクティブなＶｏＩＰセッションとなる。どちらのセッションも、回路切換リンクを含む。ターゲット通信デバイスは、第１のセッションと第２のセッションとを関連付けるＳＩＰＩＮＶＩＴＥ要求で受信されるＳＰＡＷＮ識別子を用いる。

第２のセッションが一旦初期化されると、モバイル通信デバイスは、第１のセッションにおいて、メディアストリームのためＶｏＩＰパケットを送信することをやめ、第２のセッションにおいて、メディアストリームのため次のＶｏＩＰパケットを送信する。幾つかの実施形態では、モバイル通信デバイスからターゲットへとハンドオフ制御パケットが送られ、ターゲットに対して、次のＶｏＩＰパケットは第１のセッション内ではもはや受信されないが、第２のセッション内で受信されることを知らせる。他の実施形態では、メディアストリームのデータペイロードＶｏＩＰパケットはもはや第１のセッションにおいてターゲットによって受信されないので、ターゲットは、データペイロードＶｏＩＰパケットを通信するために第２のセッションが使用されているが、メディアストリームのデータペイロードＶｏＩＰパケットは第２のセッションにおいてターゲットによって受信されていると判定する。ＶｏＩＰパケットが、第２のセッションにおいて通信されていると、ターゲットがどのようにして判定するかに関わらず、パーティＡの通信デバイスとパーティＢの通信デバイスとの間の両方向におけるＶｏＩＰパケットのフローは、第２のセッションで生じ、第１のセッションでは生じない。

例えば、データペイロードＶｏＩＰパケットが、会話のための音声データを含んでいる場合、ＶｏＩＰパケットを受信する通信デバイスは、第２のセッションで受信したＶｏＩＰペイロードを、ＦＩＦＯ（first in first out）バッファ内に、第１のセッションで受信したＶｏＩＰパケットのペイロードの後にバッファする。ＶｏＩＰパケットは、ＲＴＰシーケンス番号及びタイムスタンプに従ってＦＩＦＯ内に順序付けられる。ＦＩＦＯバッファの出力は、通信デバイスのユーザによって聞かれる音に変換される。

２つのセッションがアクティブなままである限り、データペイロードＶｏＩＰパケットのフローは、所望により、１つのセッションから別のセッションへと切り換えることができる。データペイロードＶｏＩＰパケットを通信するために使用されていないセッションは、所望により、停止することができる。第１のセッションを停止するために、モバイル通信デバイスは、ＳＩＰプロトコルに従って、ＳＩＰＢＹＥメッセージをターゲット通信デバイスへ送る。

更なる実施形態が、以下の詳細記述に記載される。この要約は、発明を定義することを意図していない。本発明は、特許請求の範囲によって定義される。

図１は、１つの斬新な局面に従ったＩＰ（Internet Protocol）テレフォニー通信システム１の簡略トポロジカルブロック図である。第１のパーティ（図１において「パーティＡ」と示す）は、例えばＩＰ電話２のようなモバイル無線通信デバイスを用いる。ＩＰ電話２は、図１においてＩＰアドレス＃１と示されたＩＰアドレスを有する。もしもＩＰ電話２が、アクセスポイント３の通信範囲内にあるのであれば、ＩＰ電話２は、ＬＡＮ（ローカルエリアネットワーク）４上のアクセスポイント３との短距離無線通信が可能である。この例では、ＩＰ電話２及びアクセスポイント３は、ＩＥＥＥ８０２．１１仕様に従って通信する。ＬＡＮ４は、パーティＡが、ローカル領域内においてＩＰ電話２を移動することができ、アクセスポイントのうち少なくとも１つを経由してＬＡＮ４と通信し続けることができるように、複数のアクセスポイントを含む。

システム１は更に、セルラ電話ネットワーク５を含んでいる。この例において、セルラ電話ネットワーク５は、ＣＤＭＡ（符号分割多元接続）セルラ電話ネットワークである。またＩＰ電話２は、ＣＤＭＡセルラ電話ネットワーク５において、トランシーバを用いて長距離の無線通信を行うことができる。パーティＡは、ＩＰ電話２を用いて、ＣＤＭＡセルラ電話ネットワーク５によって通話を行ったり、受信する。ＩＰ電話２は、ＣＤＭＡセルラ電話通信のみならず、８０２．１１通信も可能であるので、ＩＰ電話２は、デュアルモードＩＰ電話と称される。

ＬＡＮ４及びセルラ電話ネットワーク５はＩＰネットワークに接続される。この例において、ＩＰネットワークは、インターネットすなわち「インターネット」６である。インターネット６は、複数の相互接続したルータを含んでいる。ＳＩＰプロキシ７は、ＬＡＮ４からインターネット６へ、また、インターネット６からＬＡＮ４へとＩＰパケットを通信できるように、ＬＡＮ４とインターネット６との両方に配置される。ＳＩＰプロキシ７は、ＬＡＮ４のＡＴＬＡＮＴＡ１．ＣＯＭドメインのためのインバウンドプロキシとアウトバウンドプロキシとの両方として動作する。ＳＩＰプロキシ７は、ＬＡＮ４上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ７は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。

他のＳＩＰプロキシ８は、セルラ電話ネットワーク５、及びインターネット６の両方に配置され、これによって、ＳＩＰプロキシ８は、セルラ電話ネットワーク５からインターネット６へ、及び、インターネット６からセルラ電話ネットワーク５へとＩＰパケットを通信することができる。ＳＩＰプロキシ８は、セルラ電話ネットワーク５のＡＴＬＡＮＴＡ２．ＣＯＭドメインのためのインバンドプロキシ及びアウトバウンドプロキシの両方として動作する。ＳＩＰプロキシ８は、セルラ電話ネットワーク５上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ８は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。

第２のパーティ（図１に示す「パーティＢ」）は、ＩＰ電話９のような第２の通信デバイスを有する。この例では、ＩＰ電話９は、モバイルＩＰ電話ではなく、むしろ、固定式の陸線ＩＰ電話である。ＩＰ電話９は、図１においてＩＰアドレス＃２と示されたＩＰアドレスを持っている。ＩＰ電話９は、ＬＡＮ１０を経由してインターネット６に接続される。ＬＡＮ１０は、例えば、パーティＢのインターネットサービスプロバイダ（ＩＳＰ）によって維持されるＬＡＮであるかもしれないし、又は、パーティＢの雇用者によって維持される企業ＬＡＮでもありうる。ＳＩＰプロキシ１１は、ＬＡＮ１０からインターネット６へ、及び、インターネット６からＬＡＮ１０へとＩＰパケットを通信できるように、ＬＡＮ１０とインターネット６との両方に配置される。ＳＩＰプロキシ１１は、ＬＡＮ１０のＢＩＬＯＸＩ.ＣＯＭドメインのためのインバンドプロキシと、アウトバウンドプロキシとの両方として動作する。ＳＩＰプロキシ１１は、ＬＡＮ１０上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ１１は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。

図２は、ＩＰ電話２及びＳＩＰプロキシ７を示す。プロトコル処理レイヤのスタック１２は、ＳＩＰプロキシ７のハードウェアプラットフォーム上で動作する。ＳＩＰプロキシ７，８及び１１の各々で動作するプロトコル処理レイヤには、このようなスタックがある。スタック１２は、ＭＡＣレイヤ１３、ＩＰレイヤ１４、ＴＣＰレイヤ１５、及びＳＩＰレイヤ１６を含んでいる。ＭＡＣは「媒体アクセス制御」を表わす。ＩＰは「インターネットプロトコル」を表わす。ＴＣＰは「転送制御プロトコル」を表わす。ＳＩＰは「セッション初期化プロトコル」を表わす。ＩＰ電話２内のプロセッサは、プロトコル処理レイヤの類似のスタック１７を実行する。スタック１７は、ＩＰレイヤ１８、ＴＣＰレイヤ１９、及びＳＩＰレイヤ２０を含んでいる。スタック１２，１７の各々は、ＩＰレイヤ及びＴＣＰレイヤを含んでいるので、ＩＰ電話２とＳＩＰプロキシ７との間でＴＣＰ接続を確立することができる。図２では、ＩＰ電話２内の黒い点が、ＩＰ電話２のＩＰアドレス＃１を表わす。ＳＩＰプロキシ７内の黒い点は、ＩＰアドレスを表わす。左端の矢印は、ＩＰ電話２及びＳＩＰプロキシ７内で終端する第１のＴＣＰ接続２１を表わす。ＩＰプロトコル通信は、単なるベストエフォート通信だが、ＩＰに加えてＴＣＰを用いることによって、ＴＣＰ接続２１を介したＩＰ電話２とＳＩＰプロキシ７との間の情報の信頼できる通信が可能となる。ＴＣＰ接続２１が確立され、ＩＰ電話２とＳＩＰプロキシ７との間で維持されるのと同じ方法で、第２のＴＣＰ接続２２が確立され、ＩＰプロトコル処理レイヤとＴＣＰプロトコルレイヤとを含むスタック、及び、ＩＰアドレスを有するインターネット上の他のデバイスとＳＩＰプロキシ７との間で維持される。ＳＩＰプロキシ１１（図１参照）は、そのような１つのデバイスである。図２では、右端の矢印は、ＳＩＰプロキシ７で一端が終端し、ＳＩＰプロキシ１１で他端が終端している第２のＴＣＰ接続２２を表す。

図３は、斬新な方法に従った第１のステップのブロック図である。このブロック図では、時間は、垂直のディメンションにおける上端から下端まで及ぶ。“パーティＡ”とラベルされたボックスと、このボックスから下の方向へ伸びる垂線は、ＩＰ電話２を表す。“パーティＢ”とラベルされたボックスと、このボックスから下の方向へ伸びる垂線は、ＩＰ電話９を表す。「ＳＩＰプロキシ＃１」とラベルされた垂線は、ＳＩＰプロキシ７を表わす。「ＳＩＰプロキシ＃２」とラベルされた垂線は、ＳＩＰプロキシ１１を表わす。

ＩＰ電話２内には、ＩＰ電話２がＬＡＮ４と通信している場合に使用されるＳＩＰプロキシの識別情報が格納されている。ＩＰ電話２は、ＩＰ電話２がセルラ電話ネットワーク５と通信している場合に使用される別のＳＩＰプロキシの別の識別情報を格納する。この例において、ＬＡＮ４と通信している場合に使用されるＳＩＰプロキシの識別情報は、ＰＲＯＸＹ１．ＡＴＬＡＮＴＡ１．ＣＯＭである。セルラ電話ネットワーク５と通信している場合に使用されるＳＩＰプロキシの識別情報は、ＰＲＯＸＹ３．ＡＴＬＡＮＴＡ２．ＣＯＭである。ＩＰ電話２はＬＡＮ４と通信しているので、ＩＰ電話２は、識別情報ＰＲＯＸＹ１．ＡＴＬＡＮＴＡ１．ＣＯＭを用い、この識別情報を解釈して、識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスを取得する。この識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスが、前のＳＩＰトランザクションでアドレスされたＳＩＰプロキシと関連付けられてＩＰ電話２内にキャッシュされると、このキャッシュされたＩＰアドレスは、ＳＩＰプロキシのＬＡＮ側のＩＰアドレスとして使用される。この識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスが、ＩＰ電話２内にキャッシュされていないのであれば、ＩＰ電話２は、ＤＮＳサーバ（図示せず）にＤＮＳ要求を送る。ＤＮＳサーバは、この例では、ＬＡＮ４に配置される。ＤＮＳサーバは、各ＳＩＰプロキシに対するＩＰアドレスを含むルックアップテーブルを含む。ＤＮＳサーバは、ＩＰ電話２にＩＰアドレスを送り返すことによって、ＤＮＳ要求に応答する。この例では、ＩＰ電話２のＩＰアドレスは１０．３２．１．１４１である。識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスを、ＩＰ電話２がどのようにして取得するかに関わらず、ＩＰ電話２は、ＳＩＰ呼出人又は発信人として動作し、ＩＰ電話２とＳＩＰプロキシ７との間のＴＣＰ接続２１を介して、ＳＩＰプロキシのＬＡＮ側のＩＰアドレスへＳＩＰＩＮＶＩＴＥ要求を送る。図３では、パーティＡからＡＴＬＡＮＴＡ１．ＣＯＭへ伸びる一番上の矢印２３は、このＳＩＰＩＮＶＩＴＥ要求の送信を示している。

図４は、ＳＩＰＩＮＶＩＴＥ要求のブロック図である。ＳＩＰＩＮＶＩＴＥ要求のヘッダフィールド部は、ＳＩＰＩＮＶＩＴＥ要求が、ＳＩＰアドレスＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭへ向けられていることを示している。ＳＩＰＩＮＶＩＴＥ要求のヘッダフィールド部は、ＳＩＰＩＮＶＩＴＥが、ＳＩＰアドレスＡＬＩＣＥ＠ＡＴＬＡＮＴＡ１．ＣＯＭからのものであることを示す。ＳＩＰＩＮＶＩＴＥ要求は、ＳＩＰプロキシ７上で終端しているＴＣＰ接続において受信され、ＳＩＰプロキシ７のＳＩＰプロトコル処理レイヤへ提供される。ＳＩＰプロキシ７のＳＩＰプロトコル処理レイヤは、このアドレス情報を検査し、ＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭを得る。そして、ＳＩＰプロトコル処理レイヤは、ＳＩＰＩＮＶＩＴＥ要求をどこへ送信するかを判定するポリシーのセットを用いる。このポリシーのセットは、各ドメインネームに対する関連するＳＩＰプロキシを示す。本例では、ポリシーは、ドメインネームＢＩＬＯＸＩ．ＣＯＭが、関連するＳＩＰプロキシ＃２によってサービス提供されるべきであることを示す。そして、ＳＩＰプロキシ７内のＳＩＰプロトコル処理レイヤは、識別されたＳＩＰプロキシ＃２を解釈し、ＳＩＰプロキシ＃２のインターネット側のＩＰアドレスを決定する。これは、キャッシュされた情報を調べることにより、又は、ＤＮＳサーバルックアップを行うことによってなされうる。ＳＩＰプロキシ＃２のインターネット側ＩＰアドレスが一旦決定されると、ＳＩＰプロキシ７は、ＳＩＰプロキシ＃２へのＴＣＰ接続を確立し、ＳＩＰＩＮＶＩＴＥ要求を、インターネット６を介してＳＩＰプロキシ＃２へ転送する（図１参照）。ＳＩＰプロキシ＃２は、ドメインＢＩＬＯＸＩ．ＣＯＭ上にある。ＢＩＬＯＸＩ．ＣＯＭは、ＬＡＮ１０のドメインネームである。図３のブロック図において、ＡＴＬＡＮＴＡ１．ＣＯＭからＢＩＬＯＸＩ．ＣＯＭへ伸びる矢印２４は、ＳＩＰプロキシ７からＳＩＰプロキシ１１へのＳＩＰＩＮＶＩＴＥ要求の転送を表わす。

ＳＩＰプロキシ１１は、このＳＩＰＩＮＶＩＴＥ要求を受信する。ＳＩＰプロキシ１１上で動作するスタックのＳＩＰレイヤは、ＬＡＮ１０上の全てのデバイスのＩＰアドレスを知っている。ＳＩＰＩＮＶＩＴＥ要求の、示されたＳＩＰ呼出先アドレスＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭから、ＳＩＰプロキシ１１のＳＩＰレイヤは、ＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭのＩＰアドレスを取得し、ＳＩＰＩＮＶＩＴＥ要求を、ＴＣＰ接続を介して、ＩＰ電話９のＩＰアドレス（ＩＰアドレス＃２）へ転送する。図３では、ＢＩＬＯＸＩ．ＣＯＭからパーティＢへ伸びる矢印２５は、この転送を表わす。ＩＰ電話９のスタックのＳＩＰレイヤは、このＳＩＰＩＮＶＩＴＥ要求を受信し、ＳＩＰプロトコルに従って、２００ＯＫＳＩＰメッセージを返す。２００ＯＫＳＩＰメッセージは、上述した転送処理と逆の処理によって、ＳＩＰプロキシ１１及びＳＩＰプロキシ７を介して、パーティＡ及びＩＰ電話２へ戻される。図３では、この転送は、矢印２６、２７及び２８によって表わされる。

次に、ＩＰ電話２は、２００ＯＫＳＩＰメッセージを受信し、これからＩＰ電話９のＩＰアドレスを得る。そして、ＩＰ電話２は、ＩＰ電話２からＩＰ電話９へのＴＣＰ接続を直接的に確立することができる。２００ＯＫＳＩＰメッセージを受信することに応じて、ＩＰ電話２は、ＴＣＰ接続を介して、ＩＰ電話９へとＳＩＰアクノレッジ（ＡＣＫ）メッセージを送り返す。図３では、これは、パーティＡからパーティＢまで直接伸びている矢印２９によって図示される。

図５は、ＳＩＰＩＮＶＩＴＥ要求、２００ＯＫメッセージ、及びＡＣＫを含むＳＩＰトランザクションを示す。トランザクションの３つ全てのＳＩＰメッセージが、ネットワークを通って同時に伝搬するものとして例示されていているが、ＳＩＰメッセージは、実際には、上述したように、一度に１つ送られ、受信される。ＳＩＰトランザクションの結果は、（パーティＡの）ＩＰアドレス＃１と、（パーティＢの）ＩＰアドレス＃２の初期化である。データペイロードがセッション中に通信されていようともいまいとも、終了していない初期化ＳＩＰセッションは、“アクティブ”であると呼ばれる。本例では、第１のＳＩＰセッションが一旦初期化されると、音声及び／又はビデオデータペイロードを有する第１のＶｏＩＰ／ＶＩＰ (voice over IP or video over IP）が、ＲＴＰ（Real-Time Protocol）プロトコルに従って、ＵＤＰ（User Datagram Protocol）パケットによって、ＩＰ電話２のＩＰアドレス＃１とＩＰ電話９のＩＰアドレス＃２との間で通信される。第１のセッションのデータペイロードは、ＩＰ、ＵＤＰ、及びＲＴＰを用いて通信される。一方、第１のセッションの制御パケットは、ＩＰ、ＴＣＰ、及びＳＩＰを用いて通信される。

図６は、ＩＰ電話２とＩＰ電話９との間のこれら第１のＶｏＩＰ／ＶＩＰＩＰデータペイロードパケットの幾つかの通信を例示している。この通信は、８０２．１１プロトコルに従った、ＬＡＮ４のアクセスポイント３とＩＰ電話２との間の無線通信を含む。８０２．１１は、比較的短距離のＲＦ通信プロトコルである。本例では、パーティＡは、アクセスポイント３から更に遠くへ移動する。ＩＰ電話２は、アクセスポイント３から受信したＲＦ送信の信号強度を検知する。本例では、検知された信号強度の表示は、ＩＰ電話２において、ＩＰ電話２内の８０２．１１トランシーバの受信機増幅器から出力されるＲＳＳＩ（Radio Signal Strength Indicator）信号として利用可能である。アクセスポイント３内の８０２．１１トランシーバの受信機増幅器はまた、ＩＰ電話２から受信したＲＦ送信の信号強度を検知する。この検知された信号強度は、アクセスポイント３からＩＰ電話２へと報告される。このように、ＩＰ電話２は、両方向で受信した送信の強度を認識する。パーティＡ及びＩＰ電話２がアクセスポイント３から離れると、ＩＰ電話２とアクセスポイント３との間の８０２．１１無線リンクの検知された信号強度は、しきい値に達するまで低下する。しきい値に到達すると、ＩＰ電話２は、ＩＰ電話２が、その長距離のセルラ電話トランシーバを用いて第２のＳＩＰセッションを初期するべきであると判定する。ＩＰ電話２は、第１のセッションにおいて、ＳＰＡＷＮメッセージと呼ばれる斬新なＳＩＰメッセージをパーティＡからパーティＢへ送ることによって、この第２のＳＩＰセッションを初期化する。

図７は、ＳＰＡＷＮＳＩＰメッセージを例示するブロック図である。

図８は、パーティＡからパーティＢへのＳＰＡＷＮＳＩＰメッセージの通信を例示するブロック図である。上述したように、パーティＡからパーティＢへとＩＮＶＩＴＥＳＩＰメッセージが通信されるのと同じ方法で、ＳＰＡＷＮＳＩＰメッセージもまた、ＩＰ電話２から、８０２．１１無線リンクを介してＬＡＮ４上のアクセスポイント３へ、ＬＡＮ４を介してＳＩＰプロキシ７へ、インターネット６を介してＳＩＰプロキシ１１へ、ＬＡＮ１０を介してパーティＢのＩＰ電話９へ通信される。パーティＢのＩＰ電話９は、ＳＰＡＷＮＳＩＰメッセージを受信し、パーティＡのＩＰ電話２に２００ＯＫＳＩＰメッセージを送り返すことにより応答する。しかしながら、この２００ＯＫＳＩＰメッセージは、ＳＰＡＷＮＩＤ（ＳＰＡＷＮ識別子）を含んでいる。ＩＰ電話９は、ＦＲＯＭフィールド、ＴＯフィールド、ＣＡＬＬ−ＩＤフィールド、及び第１のセッションのＣＳＥＱ番号のハッシュを生成することによって、ＳＰＡＷＮＩＤを生成する。このＳＰＡＷＮＩＤは、将来の参照のためにＩＰ電話９内に格納され、第２のセッションが第１のセッションと関連付けられる。本例では、ＳＰＡＷＮＩＤは、２００ＯＫＳＩＰメッセージ内のフィールド名“ＳＰＡＷＮ−ＩＤ”に続く１６バイトキャラクタストリングである。ＳＰＡＷＮＩＤを含む２００ＯＫＳＩＰメッセージは、ＳＩＰプロキシ１１及びＳＩＰプロキシ７を介してＩＰ電話２に転送される。

図９は、ＳＰＡＷＮＳＩＰ要求と、ＳＰＡＷＮＩＤ及びＡＣＫを含む２００ＯＫとを含むＳＩＰトランザクションを例示するブロック図である。例示するように、このトランザクションは第１のＳＩＰセッションにおいて生じる。

図１０は、２００ＯＫを受信すると、第２のＩＮＶＩＴＥＳＩＰ要求を発行する次のステップを例示するブロック図である。ＩＰ電話２内の黒い点はＩＰアドレスを表わす。第２のＩＮＶＩＴＥ要求は、ＳＰＡＷＮＩＤを含んでおり、パーティＡのＩＰ電話２からパーティＢのＩＰ電話９へ通信される。この第２のＩＮＶＩＴＥ要求は、ＣＤＭＡセルラ電話リンクを介してＩＰ電話２から、セルラ電話ネットワーク５上のアクセスポイント（ＢＴＳ又は基地送信サイトとも呼ばれる）３０へ通信され、次に、セルラ電話ネットワーク５を介してＳＩＰプロキシ＃３（ＳＩＰプロキシ８）へ通信される。この通信は、ＩＰ電話２におけるＩＰアドレス＃３における一端、及びその他の端において終端するＴＣＰ接続を介して、ＳＩＰプロキシ８のセルラ電話ネットワーク側ＩＰアドレスへ通信される。そして、第２のＩＮＶＩＴＥ要求が、インターネット６を介してＳＩＰプロキシ８から、他のＴＣＰ接続を介してＳＩＰプロキシ１１へと転送される。この第２のＩＮＶＩＴＥ要求は、その後、ＬＡＮ１０を介してＳＩＰプロキシ１１から、別のＴＣＰ接続を介してパーティＢのＩＰ電話９へと転送される。

パーティＢのＩＰ電話９は、既に存在するアクティブセッション（第１のセッション）によって、通常は、到来するＩＮＶＩＴＥ要求を拒絶するが、本発明では、パーティＢのＩＰ電話９内のＳＩＰレイヤ機能が、到来する第２のＩＮＶＩＴＥ要求のＳＰＡＷＮＩＤを認識し、それ自身のＲＴＰストリームを開くことを含む第２のセッションをセットアップし、この第２のセッションを第１のセッションに関連付ける。ＩＰ電話９は、ＳＰＡＷＮＩＤを、格納されたＳＰＡＷＮＩＤのリストと比較することによって、到来する第２のＩＮＶＩＴＥ要求のＳＰＡＷＮＩＤを認識する。

図１０Ａは、ＩＰ電話９内で動作するソフトウェアの構造の簡略図である。ＩＰ電話９は、２００ＯＫＳＩＰメッセージを、パーティＡのＩＰ電話２へ返すことによって応答する。ＩＰ電話２は、ＩＰ電話９にＡＣＫを返すことによって、トランザクションを終了する。第２のＩＮＶＩＴＥ要求、２００ＯＫ、及びＡＣＫは、ＣＤＭＡ無線リンク及びＣＤＭＡＢＴＳ３０を介してＩＰ電話２と通信される。

図１１は、アクティブな第１のセッションと、現在初期化されたアクティブな第２のセッションとを例示する図である。第２のセッションはアクティブであるが、データペイロードパケットは、ＩＰ、ＵＤＰ、及びＲＴＰを用いて、第２のセッションにおいて、まだ通信されていない。（ＩＰ電話２とアクセスポイント３との間の８０２．１１通信を含む）第１のセッションは、第１のＣＡＬＬ−ＩＤを有する。一方、（ＩＰ電話２とセルラＢＴＳ３０との間のＣＤＭＡ通信を含む）現在初期化されている第２のセッションは、第２のＣＡＬＬ−ＩＤを有する。

図１２は、ＩＰ電話２とＩＰ電話９との間のペイロードデータメディアフローが、第１のセッションから第２のセッションへと切り換わる（すなわち、「ハンドオフ」される）次のステップを例示する。矢印３１，３２は、パーティＡのＩＰ電話２と、パーティＢのＩＰ電話９との間のペイロードデータメディアフローＶｏＩＰパケットの初期フローを例示する。データ制御ハンドオフパケットが、ＩＰ、ＵＤＰ、及びＲＴＰを用いて、パーティＡのＩＰ電話２から、パーティＢのＩＰ電話９へ送られる。本例では、このデータ制御ハンドオフパケットは、ＳＩＰプロキシ７，１１を介して第１のセッションで通信されるが、このデータ制御ハンドオフパケットはまた、ＳＩＰプロキシ８，１１を介して第２のセッションで通信される。矢印３３は、データ制御ハンドオフパケットの転送を示す。データ制御ハンドオフパケットは、一例として、ＳＷＩＴＣＨ−ＦＲＯＭ：フィールド名と、ＳＷＩＴＣＨ−ＴＯ：フィールド名とを含むＳＩＰメッセージである。データ制御ハンドオフパケットは、ＩＰ電話９へ通信するために使用され、次のデータペイロードパケットが、第２のセッションで送られる。データ制御ハンドオフパケットの起こりうる損失に対処するために、パーティＢは、ＩＰアドレス＃３を用いるパーティＡのＩＰ電話２によって発信された制御パケットを拒否しないことが命じられる。

図１３は、第１のセッションにおいてＩＰ電話２からＩＰ電話９へ通信されるデータペイロードパケットに続くメディアフローハンドオフ制御パケット３４を例示する。

図１４は、メディアフローハンドオフ制御パケット３４のブロック図である。メディアフローハンドオフ制御パケットを送った後、ＩＰ電話２は、第１のセッションにおいて、メディアストリームのデータペイロードを送ることから、第２のセッションにおいて、メディアストリームのデータペイロードを送ることに切り換える。本例におけるメディアストリームは、音声会話である。ＩＰ電話９がメディアフローハンドオフ制御パケットを受信した場合、ＩＰ電話９は、第２のセッションにおいて、次のデータペイロードパケットを受信し、これらパケットのデータペイロードを、ＦＩＦＯ（first-in-first out）メモリ内の、第１のセッションにおいて以前に受信したパケットのデータパケットの後にバッファする。このデータペイロードはＦＩＦＯから出力され、ＲＴＰシーケンス番号及びタイムスタンプに従って順序付けられるように、ＩＰ電話９のユーザに提供される。従って、メディアストリームのデータペイロードは、認識できるほど通話が破壊されることなく、第１のアクティブなセッションから第２のアクティブなセッションへとシームレスに切り換えられる。第１のセッションも第２のセッションも、切換回路部を含んでいない。第１のセッションも第２のセッションも、ＶｏＩＰパケットを含んでおり、ＩＰ電話９は、２つのセッションを知っている。２つのセッションは、３方式の通話を構成しない。更に、ＳＩＰプロキシ７，８，１１は、この斬新なＳＰＡＷＮ方法をサポートする如何なる特別な機能も含まない標準的なＳＩＰプロキシである。図１２では、矢印３４，３５は、第２のセッションにおける次のＶｏＩＰデータペイロードパケットのフローを例示する。

図１５は、データ制御ハンドオフパケットが第１のセッションにおいて通信された後の、第２のセッションにおけるデータペイロードＶｏＩＰパケットのフローを例示する。ＩＰ電話２は、フローデータパケットペイロードＶｏＩＰパケットを、必要に応じて、又は希望に応じて、第１のセッションと第２のセッションとの間で切り換えることができる。

図１６は、次のステップを例示する。このステップでは、ＩＰ電話２が、ＩＰ電話９にＳＩＰＢＹＥメッセージを送ることによって、第１のセッションを終了する。８０２．１１無線リンクの信号強度が低下する場合、ＩＰ電話２とアクセスポイント３との間の通信が存在している間、このＳＩＰＢＹＥメッセージが送られる。このＢＹＥメッセージが送信され受信された後、第１のセッションが終了し、メディアストリームのためのデータペイロードパケットの通信を維持するために第２のセッションが使用される。

図１７は、第１のセッションが終了した後、第２のセッションにおけるデータペイロードＶｏＩＰパケットのフローを示す。

上述した例は、８０２．１１リンクを有する第１のセッションから、ＣＤＭＡリンクを有する第２のセッションへの切換を含むが、これはそうである必要はない。別の例では、第１のセッションが、ＣＤＭＡ無線リンクを含み、第２のセッションが、８０２．１１無線リンクを含む。そのような状態は、パーティＡが最初はセルラＢＴＳ３０を介したＣＤＭＡ通信を用いており、次に、アクセスポイント３のローカル有効範囲領域に到達する場合に生じる。ＣＤＭＡサービス及び８０２．１１サービスともに、アクセスポイント３のローカル有効範囲領域内で利用可能であるが、上述した本方法は、８０２．１１無線リンクを含む第２のセッションをセットアップするために使用される。その後、データペイロードＶｏＩＰパケットのフローが、ＣＤＭＡ第１のセッションから、８０２．１１第２のセッションへと切り換えられる。ＣＤＭＡリンクの使用に関する課金を避けるために、第２のセッションが一旦アクティブになり、ＶｏＩＰメディアストリームのデータペイロードを取り扱うと、ＣＤＭＡリンクを有する第１のセッションが終了する。

図１８は、代替データフローハンドオフメカニズムを示す。１つのセッションから別のセッションへのデータペイロードＶｏＩＰパケットの切り換えをシグナルするためにハンドオフ制御パケットを送るのではなく、ＩＰ電話２は単に、第２のセッションにおいて、データペイロードＶｏＩＰパケットを通信し始める。矢印３６は、パーティＡからパーティＢへと通信される最初のデータペイロードＶｏＩＰパケットを表す。パーティＢが第１のセッションにおいてデータペイロードＶｏＩＰパケットを受信した場合、パーティＢは、第１のセッションにおいてパーティＡへ送ることを望んでいるあらゆるデータペイロードＶｏＩＰパケットを送ることによって応答する。パーティＢからパーティＡへのデータペイロードＶｏＩＰパケットのフローは、矢印３７によって示される。第１のセッションから第２のセッションへのデータペイロードＶｏＩＰパケットのフローを切り換えるために、パーティＡは単に、第２のセッションにおいて、データペイロードＶｏＩＰパケットをパーティＢへ送ることを開始する。このフローは、矢印３８によって表わされる。パーティＢが、第２のセッションにおいて、データペイロードＶｏＩＰパケットを受信し始めると、パーティＢは、第２のセッションにおいてパーティＡへ送ることを望んでいる次のあらゆるデータペイロードＶｏＩＰパケットを送ることによって応答する。第２のセッションにおけるパーティＢからパーティＡへのデータペイロードＶｏＩＰパケットのフローは、矢印３９によって表される。

パーティＢが、ＩＰ電話において終端するＴＣＰ接続を介してＶｏＩＰデータペイロードパケットが送られるＩＰ電話を有するシステムについて上述したが、パーティＢは、ＩＰ電話を有しておらず、メディアゲートウェイを経由するＩＰテレフォニーを用いることもできる。通話がパーティＢへの通話である場合、このメディアゲートウェイがＶｏＩＰ通話を受信し、パーティＢへの従来式の第２の通話を行い、ＶｏＩＰ通話とこの従来式の第２の通話との間でペイロード情報を中継する。通話がパーティＢから発信された通話である場合、パーティＢが、メディアゲートウェイへ従来式の通話を行い、メディアゲートウェイが、意図する呼出先へと第２のＶｏＩＰ通話を行い、メディアゲートウェイが、従来式の通話とＶｏＩＰ通話との間でペイロード情報を中継する。従って、メディアゲートウェイは、パーティＢのためのダミーのＩＰ電話として動作する。

上述した例におけるＩＰ電話９は、陸線ＩＰ電話であるが、他の例では、ＩＰ電話９は、（例えば、セルラ電話のような）モバイル無線通信デバイスである。第１及び第２のセッションは、モバイルＩＰ電話か陸線ＩＰ電話かの何れかによって開始することができる。

ある特定の実施形態が、説明目的のために上述されたが、本発明はそれに限定されない。従って、上述した具体的実施形態の様々な特徴の変更、適応、及び組み合わせは、特許請求の範囲で述べられた本発明の範囲から逸脱することなく実施することができる。

図１は、１つの斬新な局面に従ったＩＰ（Internet Protocol）テレフォニー通信システム１の簡略トポロジカルブロック図である。図２は、図１のシステムにおけるＩＰ電話２とＳＩＰプロキシ７との間のＴＣＰ接続を例示する。図３は、斬新な方法に従った第１のステップのブロック図である。図４は、斬新な方法に従って第１のセッションをセットアップするＳＩＰＩＮＶＩＴＥ要求のブロック図である。図５は、第１のセッションの初期化を例示する。図６は、パーティＡが、図１のシステムのアクセスポイント３からＩＰ電話２を移動する第１のセッションを例示する。図７は、本斬新な方法に従って、ＩＰ電話２からＩＰ電話９へ送られるＳＰＡＷＮＳＩＰメッセージの図である。図８は、本斬新な方法に従って、ＳＰＡＷＮＳＩＰメッセージの通信を例示するブロック図を示す。図９は、図１のシステムによるＳＰＡＷＮＳＩＰメッセージの通信、及び、ＳＰＡＷＮＩＤを含む２００ＯＫＳＩＰメッセージを戻すことを例示する。図１０は、本斬新な方法に従って第２のセッションを初期化するために、ＩＰ電話２からＩＰ電話９へ第２のＳＩＰＩＮＶＩＴＥ要求を送ることを例示する。図１０Ａは、ＩＰ電話９において実行するソフトウェアの構造の簡略図である。図１１は、アクティブな第１及び第２の両セッションを例示する。図１２は、第１のセッションから第２のセッションへとＶｏＩＰデータパケットを切り換えるようシグナルするために、メディアハンドオフ制御パケットを使用することを例示するブロック図である。図１３は、ＩＰ電話２からＩＰ電話９へのハンドオフ制御パケットの送信を例示する。図１４は、ハンドオフ制御パケットのブロック図である。図１５は、第２のセッションによるデータペイロードのフローを示す。図１６は、第１のセッションを終了するために、ＩＰ電話２からＩＰ電話９へＢＹＥＳＩＰメッセージを送信することを例示する。図１７は、第１のセッションの終了後における図１のシステムを例示する。ここで、メディアストリームのデータペイロードＶｏＩＰパケットは、もはや第１のセッションでは通信されていないが、第２のセッションにおいて通信されている。図１８は、メディアストリームのＶｏＩＰデータペイロードパケットが、第１のセッションにおいてもはや通信されていないが、第２のセッションにおいて通信されることをＩＰ電話９が判定する他の方法を例示する。

Claims

（ａ）第１のセッションにおいて、第１のＩＰアドレスと第２のＩＰアドレスとの間で、第１のＶｏＩＰ／ＶＩＰ（voice over Internet Protocol or video over Internet Protocol）パケットを通信することであって、前記第１のＩＰアドレスは、第１のデバイスに関連付けられたＩＰアドレスであり、前記第２のＩＰアドレスは、第２のデバイスに関連付けられたＩＰアドレスであり、前記第１のＶｏＩＰ／ＶＩＰパケットを通信することは、第１のネットワーク上のトランシーバと前記第１のデバイスとの間の第１の無線通信リンクによって前記第１のＶｏＩＰ／ＶＩＰパケットを通信することを含んでいることと、
（ｂ）前記第１のセッションにおいて、前記第１のデバイスから前記第２のデバイスへＳＩＰ（Session Initialization Protocol）メッセージを通信することであって、前記ＳＩＰメッセージは、前記第１のセッションを識別することと、
（ｃ）前記第１のセッションと第２のセッションとが同時にアクティブになるように、前記ＳＩＰメッセージを用いて前記第２のセッションを初期化することであって、前記第２のセッションは、前記第２のＩＰアドレスと第３のＩＰアドレスとの間にあり、前記第３のＩＰアドレスは、前記第１のアドレスに関連付けられたＩＰアドレスであることと、
（ｄ）前記第２のセッションにおいて、前記第２のＩＰアドレスと前記第３のＩＰアドレスとの間で、第２のＶｏＩＰ／ＶＩＰパケットを通信することであって、前記第２のＶｏＩＰ／ＶＩＰパケットを通信することは、第２のネットワーク上のトランシーバと前記第１のデバイスとの間で、第２の無線通信リンクを介して前記第２のＶｏＩＰ／ＶＩＰパケットを通信することを含み、前記第１のＶｏＩＰ／ＶＩＰパケットと前記第２のＶｏＩＰ／ＶＩＰパケットとは、単一のメディアストリームからなる音声データを含むことと
を備える方法。
前記第１のＶｏＩＰ／ＶＩＰパケットは、無線ＬＡＮ（local area network）通信プロトコルに従って、前記第１の無線通信リンクを介して通信され、前記第２のＶｏＩＰ／ＶＩＰパケットは、セルラ電話通信プロトコルに従って、前記第２の無線通信リンクを介して通信され、前記第１のデバイスは、ＩＰ電話と、セルラ電話と、ＰＤＡ（パーソナルデジタルアシスタント）と、無線通信機能を有するコンピュータとからなるグループから選択されるデバイスである請求項１に記載の方法。
前記ステップ（ｂ）において、前記ＳＩＰメッセージはＳＰＡＷＮメッセージであり、
前記ステップ（ｃ）は、
前記第２のデバイスにおいて前記ＳＰＡＷＮメッセージを受信し、その応答として、前記第２のデバイスから前記第１のデバイスへ、ＳＰＡＷＮ識別子を含む第１のＳＩＰＯＫメッセージを送ることと、
前記第１のデバイスにおいて前記第１のＳＩＰＯＫメッセージを受信し、その応答として、前記第１のデバイスから前記第２のデバイスへ第１のＳＩＰＡＣＫメッセージを送ることと、
前記第１のデバイスから前記第２のデバイスへ、前記ＳＰＡＷＮ識別子を含むＳＩＰＩＮＶＩＴＥメッセージを送ることと、
前記第２のデバイスにおいて前記ＳＩＰＩＮＶＩＴＥメッセージを受信し、その応答として、前記第２のデバイスから前記第１のデバイスへ第２のＳＩＰＯＫメッセージを送ることと、
前記第１のデバイスにおいて前記第２のＳＩＰＯＫメッセージを受信し、その応答として、前記第１のデバイスから前記第２のデバイスへ第２のＳＩＰＡＣＫメッセージを送ることと
を備える請求項１に記載の方法。
前記第１のＶｏＩＰ／ＶＩＰパケットは、第１のＲＴＰ（Real-Time Transport Protocol）ペイロードパケットであり、前記第２のＶｏＩＰ／ＶＩＰパケットは、第２のＲＴＰペイロードパケットであり、前記第２のＲＴＰペイロードパケットのうちの幾つかは前記第２のセッションで通信され、その後、前記第１のＲＴＰペイロードパケットのうちの幾つかが前記第１のセッションで通信される請求項１に記載の方法。
前記第１のＶｏＩＰ／ＶＩＰパケットは、第１のＲＴＰ（Real-Time Transport Protocol）ペイロードパケットであり、前記第２のＶｏＩＰ／ＶＩＰパケットは、第２のＲＴＰペイロードパケットであり、前記第２のセッションにおいて何れかのＲＴＰペイロードパケットが一旦通信されると、前記第１のセッションにおいてどのＲＴＰペイロードパケットも通信されない請求項１に記載の方法。
前記第１のデバイスはＩＰ電話であり、前記第２のデバイスは、ＩＰ電話及びメディアゲートウェイからなるグループから選択される請求項１に記載の方法。
（ｅ）前記第１のデバイスから前記第２のデバイスへ第２のＳＩＰメッセージを通信することを更に備え、
前記第２のＳＩＰメッセージは、前記第１のデバイスが、前記第１のセッションを用いず前記第２のセッションを用いて、次のＶｏＩＰ／ＶＩＰパケットを通信することを示す請求項１に記載の方法。
（ｅ）前記第１のデバイスから前記第２のデバイスへ第２のＳＩＰメッセージを通信することを更に備え、
前記第２のＳＩＰメッセージは、前記第１のデバイスが、前記第２のセッションを用いず前記第１のセッションを用いて、次のＶｏＩＰ／ＶＩＰパケットを通信することを示す請求項１に記載の方法。
プロセッサ読取可能媒体に格納されたプロセッサ実行可能命令のセットであって、前記プロセッサ読取可能媒体はＳＩＰ終点エンティティの一部であり、
前記命令のセットは、
前記ＳＩＰ終点エンティティと通話終点との間である第１のセッションにおいて、モバイル通信デバイスに受信された第１のＶｏＩＰ／ＶＩＰ（voice over Internet Protocol or video over Internet Protocol）データペイロードを取り扱うことと、
前記第１のセッションにおいて、前記ＳＩＰ終点エンティティに受信され、前記通話終点から発行されたＳＰＡＷＮメッセージを分析することと、
ＳＰＡＷＮ識別子を生成し、前記ＳＩＰ終点エンティティから前記通話終点へと前記ＳＰＡＷＮ識別子を送り返すことと、
前記通話終点から前記ＳＩＰ終点エンティティへと受信され、前記ＳＰＡＷＮ識別子を含むＳＩＰＩＮＶＩＴＥ要求を分析することと、
前記第１のセッションと第２のセッションとの両方が同時にアクティブになるように、
前記通話終点と前記ＳＩＰ終点エンティティとの間に第２のセッションをセットアップすることと、
前記第２のセッションにおいて、前記モバイル通信デバイスに受信された第２のＶｏＩＰ／ＶＩＰデータペイロードを取り扱うことであって、前記第１のＶｏＩＰ／ＶＩＰデータペイロード及び前記第２のＶｏＩＰ／ＶＩＰデータペイロードは、単一のメディアストリームからなるデータペイロードであることと
のためであるプロセッサ実行可能命令のセット。
前記通話終点はセルラ電話であり、前記ＳＩＰ終点エンティティはメディアゲートウェイである請求項９に記載のプロセッサ実行可能命令のセット。
前記ＳＰＡＷＮメッセージは、前記第１のセッションを識別する第１の部分を含み、前記第１の部分は、前記第１のセッションに関連付けられた第１のＳＩＰアドレスを含み、前記第１のＳＩＰアドレスは、ＸＸＸ＠ＹＹＹＹなる形式を有し、前記ＸＸＸは前記通話終点を識別し、前記ＹＹＹＹは、第１のネットワークのドメインネームであり、第２の部分は、前記第２のセッションに関連付けられた第２のＳＩＰアドレスを含み、前記第２のＳＩＰアドレスは、ＸＸＸ＠ＺＺＺＺなる形式を有し、前記ＸＸＸは、前記第１のＳＩＰアドレスにおけるＸＸＸと同一であり、前記ＺＺＺＺは、第２のネットワークのドメインネームである請求項９に記載のプロセッサ実行可能命令のセット。
前記第１のセッションは、第１のＣＡＬＬ−ＩＤを有し、前記第２のセッションは、第２のＣＡＬＬ−ＩＤを有する請求項９に記載のプロセッサ実行可能命令のセット。
前記ＳＰＡＷＮメッセージは、前記第１のＣＡＬＬ−ＩＤと前記第２のＣＡＬＬ−ＩＤとを含む請求項１２に記載のプロセッサ実行可能命令のセット。
前記通話終点は、第１のエアインタフェースと第２のエアインタフェースとを有し、前記第１のセッションにおいて通信することは、前記第１のエアインタフェースを用いて通信することを含み、前記第２のセッションにおいて通信することは、前記第２のエアインタフェースを用いて通信することを含む請求項９に記載のプロセッサ実行可能命令のセット。
前記ＳＩＰ終点エンティティは、モバイル無線通信デバイスと、ＩＰ電話と、セルラ電話と、セルラＩＰ電話と、無線通信機能を有する携帯情報端末（ＰＤＡ）と、無線通信機能を有するコンピュータと、メディアゲートウェイとからなるグループから選択される請求項９に記載のプロセッサ実行可能命令のセット。
前記第２の音声データペイロードを取り扱うことは、前記第１及び第２のＶｏＩＰ／ＶＩＰデータペイロードを順序付けすることを含む請求項９に記載のプロセッサ実行可能命令のセット。
前記順序付けを行った後、前記第１及び第２のＶｏＩＰ／ＶＩＰデータペイロードが、音を生成するために使用される請求項１６に記載のプロセッサ実行可能命令のセット。
プロセッサ読取可能媒体に格納されたプロセッサ実行可能命令のセットであって、前記プロセッサ読取可能媒体はモバイル無線通信デバイスの一部であり、
前記命令のセットは、
第１のセッションにおいて、第１のＶｏＩＰ／ＶＩＰ（voice over Internet Protocol or video over Internet Protocol）データペイロードを通話終点へ通信することと、
前記第１のセッションにおいて前記モバイル無線デバイスから前記通話終点へ送られるＳＰＡＷＮメッセージを生成することと、
前記第１のセッションにおいて、前記モバイル無線通信デバイスへ受信され、ＳＰＡＷＮ識別子を含むＳＩＰ応答を分析することと、
第２のセッションがセットアップされるように前記モバイル無線通信デバイスから前記通話終点へと送られるＳＩＰＩＮＶＩＴＥであって、前記ＳＰＡＷＮ識別子を含むＳＩＰＩＮＶＩＴＥを生成することであって、前記第１及び第２のセッションは、同時にアクティブであり、異なるＣＡＬＬ−ＩＤを有することと、
前記第２のセッションにおいて、第２のＶｏＩＰ／ＶＩＰデータペイロードを前記通話終点へ通信することであって、前記第１のＶｏＩＰ／ＶＩＰデータペイロードと、前記第２のＶｏＩＰ／ＶＩＰデータペイロードは、単一のメディアストリームのペイロードであることと
のためであるプロセッサ実行可能命令のセット。
前記ＳＰＡＷＮメッセージは、前記第１のセッションを識別する第１の部分を含み、前記第１の部分は、前記第１のセッションに関連付けられた第１のＳＩＰアドレスを含み、前記第１のＳＩＰアドレスは、ＸＸＸ＠ＹＹＹＹなる形式を有し、前記ＸＸＸは前記モバイル無線通信デバイスを識別し、前記ＹＹＹＹは、第１のネットワークのドメインネームであり、第２の部分は、前記第２のセッションに関連付けられた第２のＳＩＰアドレスを含み、前記第２のＳＩＰアドレスは、ＸＸＸ＠ＺＺＺＺなる形式を有し、前記ＸＸＸは、前記第１のＳＩＰアドレスにおけるＸＸＸと同一であり、前記ＺＺＺＺは、第２のネットワークのドメインネームである請求項１８に記載のプロセッサ実行可能命令のセット。
前記モバイル無線通信デバイスは、第１のエアインタフェースと第２のエアインタフェースとを有し、前記第１のセッションにおける通信は、前記第１のエアインタフェースを用いて通信することを含み、前記第２のセッションにおける通信は、前記第２のエアインタフェースを用いて通信することを含む請求項１８に記載のプロセッサ実行可能命令のセット。