(57)【要約】【課題】  リアルタイム性の電話サービスにおいて、２つ以上の通信網を切り替えて通話を継続する場合において、当該通信網の切り替えを円滑に行うことが可能な技術を提供する。【解決手段】  ２端末間(104,105)にハンドオーバ機能を提供するハンドオーバサーバ（100）を設置し、ハンドオーバサーバが２端末間の通話セッションを中継する仕組みを導入する。そしてハンドオーバサーバと端末の間に、同一の通話データのセッションを２本同時に確立することで、切れ目のないハンドオーバ処理を実行し、円滑に通話サービスの継続を実現する。【選択図】図１
2007142786.tif 000002
【特許請求の範囲】
【請求項１】
第１端末と第２の端末との通話をハンドオーバ処理するためのハンドオーバサーバにおいて、
第１通信ネットワーク及び第２通信ネットワークの少なくともいずれかで上記第１端末との通話を確立するための通話処理部と、
上記第２端末から送信される通話データを上記第１及び第２通信ネットワークを介して前記第１端末へ同時に転送し、上記第１端末からの上記第１及び第２通信ネットワークを介して受信された通話データをバッファに蓄積して上記２の端末へ転送するハンドオーバ処理部と、
を備え、上記ハンドオーバ処理部は、該第１及び第２通信ネットワークの両方から受信される上記第１端末からの通話データの時刻情報に基づいて、上記通話データを上記第２端末へ転送する際に用いられる通信ネットワークの切り替えを行い、
上記切り替えに失敗した場合は、上記切替前の通信ネットワークを介しての通話、もしくは上記切り替えの再試行のいずれか一方の処理を実行することを特徴とするハンドオーバサーバ。
【請求項２】
第１端末と第２の端末との通話をハンドオーバ処理するためのハンドオーバサーバにおいて、
第１通信ネットワーク及び第２通信ネットワークの少なくともいずれかで上記第１端末との通話を確立するための通話処理部と、
上記第２端末から送信される通話データを上記第１及び第２通信ネットワークを介して前記第１端末へ同時に転送し、上記第１端末からの上記第１及び第２通信ネットワークを介して受信された通話データをバッファに蓄積して上記２の端末へ転送するハンドオーバ処理部と、
を備え、上記ハンドオーバ処理部は、該第１及び第２通信ネットワークの両方から受信される上記第１端末からの通話データの時刻情報に基づいて上記第１及び第２通信ネットワークの切り替えを行い、該切り替えられた通信ネットワークを介して上記通話データを上記第２端末へ転送し、
上記第１端末から第２端末へ通話データを送信するときは上記第１通信ネットワークを用い、上記第２端末から第１端末への通話データを送信するときは上記第２通信ネットワークを用いることを特徴とするハンドオーバサーバ。
【請求項３】
請求項２に記載のハンドオーバサーバにおいて、上記第１通信ネットワークは公衆通信網であり、上記第１通信ネットワークは無線ＬＡＮであることを特徴とするハンドオーバサーバ。
【請求項４】
請求項１に記載のハンドオーバサーバにおいて、上記通話処理部は、ＮＡＴ越え処理用のポート番号、呼確立用のポート番号、通話データ用のポート番号、または通話制御用のポート番号の少なくともいずれかに送られたグローバルアドレス要求メッセージを受信する受信部と、
該受信部で受信したメッセージから発信元のグローバルアドレスを取得し、上記グローバルアドレスを含むメッセージを、上記グローバルアドレス宛てに送信する送信部と、
を含むことを特徴とするハンドオーバサーバ。
【請求項５】
請求項４に記載のハンドオーバサーバにおいて、前記通話処理部は、外部の移動通端末からの要求に応じて、前記ハンドオーバサーバの通話データ用ポート番号、もしくは通話制御用ポート番号を含むメッセージを、上記要求元の移動通端末へ送信することを特徴とするハンドオーバサーバ。
【請求項６】
請求項４に記載のハンドオーバサーバにおいて、前記通話処理部は、発呼および着呼が開始される前に、予め前記グローバルポート番号を一つ以上確保し、該ポート番号を宛先とする前記グローバルアドレス要求メッセージを受信することを特徴とするハンドオーバサーバ。
【請求項７】
請求項４に記載のハンドオーバサーバにおいて、前記通話処理部は、前記グローバルアドレスを要求したメッセージと同じ発信元ポート番号を持つダミーパケットを外部の移動通信端末から受信し、これを破棄することを特徴とするハンドオーバサーバ。
【請求項８】
ハンドオーバサーバと通信を行う移動通信端末において、
前記ハンドオーバサーバと、第１通信ネットワーク及び第２通信ネットワークの少なくともいずれか一方を介して通信可能な通信網インタフェース部と、
上記第１及び第２通信ネットワークを介して、上記ハンドオーバサーバとの間で並行して少なくとも２つの通話を確立する通話処理部と、
上記第１及び第２通信ネットワークに送話音声データを並行して送出し、該上記第１及び第２通信ネットワークから受信された通話データをバッファに蓄積するハンドオーバ処理部と、
上記ハンドオーバ処理部のバッファに蓄積された通話データをデコードして再生する音声処理部と、
を備え、上記ハンドオーバ処理部は、該第１及び第２通信ネットワークの両方から受信される上記ハンドオーバサーバからの通話データの時刻情報に基づいて、上記通話データを受信する際に用いる通信ネットワークの切り替えを行い、
上記切り替えに失敗した場合は、上記切替前の通信ネットワークを介しての通話、もしくは上記切り替えの再試行のいずれか一方の処理を実行することを特徴とする移動通信端末。
【請求項９】
ハンドオーバサーバと通信を行う移動通信端末において、
前記ハンドオーバサーバと、第１通信ネットワーク及び第２通信ネットワークの少なくともいずれか一方を介して通信可能な通信網インタフェース部と、
上記第１及び第２通信ネットワークを介して、上記ハンドオーバサーバとの間で並行して少なくとも２つの通話を確立する通話処理部と、
上記第１及び第２通信ネットワークに送話音声データを並行して送出し、該上記第１及び第２通信ネットワークから受信された通話データをバッファに蓄積するハンドオーバ処理部と、
上記ハンドオーバ処理部のバッファに蓄積された通話データをデコードして再生する音声処理部と、
を備え、上記ハンドオーバ処理部は、該第１及び第２通信ネットワークの両方から受信される上記ハンドオーバサーバからの通話データの時刻情報に基づいて、上記通話データを受信する際に用いる通信ネットワークの切り替えを行い、
上記ハンドオーバサーバへ通信データの送信するときは上記第１通信ネットワークを用い、上記ハンドオーバサーバから通信データを受信するときは上記第２通信ネットワークを使用することを特徴とする移動通信端末。
【請求項１０】
請求項８に記載の移動通信端末において、上記通話処理部は、上記ハンドオーバサーバにおける既知のＮＡＴ越え処理用のポート番号を宛先として、上記移動通信端末の呼確立用グローバルアドレス、通話データ用グローバルアドレス、通話制御用グローバルアドレスのいずれかを要求して取得し、
該取得されたグローバルアドレスから対応する上記移動通信端末のグローバルポート番号を取得して前記ハンドオーバサーバへ通知することを特徴とする移動通信端末。
【請求項１１】
請求項８に記載の移動通信端末において、上記通話処理部は、前記ハンドオーバサーバにおける既知の呼確立用のポート番号、通話データ用のポート番号、通話制御用のポート番号もしくは通話データ用ポート番号のいずれかを宛先として、該宛先に対応するグローバルアドレスを要求して取得し、
該取得された上記グローバルアドレスから上記移動通信端末のグローバルポート番号を取得して前記ハンドオーバサーバへ通知することを特徴とする移動通信端末。
【請求項１２】
請求項８に記載の移動通信端末において、上記通話処理部は、前記ハンドオーバサーバの通話制御用のポート番号を上記ハンドオーバサーバに対して要求して取得し、
上記取得した通話制御用のポート番号を宛先として、上記移動通信端末の通話制御用グローバルアドレスを要求して取得し、
該取得された上記通話制御用グローバルアドレスから上記移動通信端末の通話制御用グローバルポート番号を取得して前記ハンドオーバサーバへ通知することを特徴とする移動通信端末。
【請求項１３】
請求項１０に記載の移動通信端末において、前記通話処理部は、発呼および着呼が開始される前に、予め前記グローバルポート番号を取得することを特徴とする移動通信端末。
【請求項１４】
請求項１０に記載の移動通信端末において、前記通話処理部は、前記グローバルアドレスを要求したメッセージと同じ発信元ポート番号を持つダミーパケットを、上記メッセージと同じ宛先のポート番号へ、定期的に送信し続けることを特徴とする移動通信端末。
【請求項１５】
請求項８に記載の移動通信端末において、
上記ハンドオーバ処理部は、上記バッファに蓄積された通話データを、上記第１及び第２の通信ネットワークから受信した通話データの再生時刻に応じて切り替えて出力するハンドオーバ制御部を含み、
上記音声処理部は、上記ハンドオーバ制御部からの通話データをデコードするデコーダと、該デコーダによってデコードされた通話データが入力されるエラー修正部とを含み、
上記エラー修正部は、上記デコードされた通話データの切替前後における再生時刻の相違を修正することを特徴とする移動通信端末。
【請求項１６】
請求項１５に記載の移動通信端末において、上記エラー修正部は、切替後の通話データの再生時刻が切替前のそれよりも進んでいる場合、上記切替後の通話データを上記切替前の通話データの直後の時刻に再生するように修正することを特徴とする移動通信端末。
【請求項１７】
請求項１５に記載の移動通信端末において、上記エラー修正部は、切替後の通話データの再生時刻が切替前のそれよりも進んでいる場合、上記切替前の通話データの再生時刻から上記切替後の通話データの再生時刻までの間を、無音もしくは他の音声により補間することを特徴とする移動通信端末。
【請求項１８】
請求項１５に記載の移動通信端末において、前記他の音声は、予め用意された音データ、受信済みの通話データを元に作成された音データ、上記切替前もしくは切替後のいずれか一方の通話データ、または該通話データを時間的に伸張して得られた音データに基づき生成されることを特徴とする電話端末。
【請求項１９】
請求項１５に記載の移動通信端末において、上記エラー修正部は、切替後の通話データの再生時刻が切替前のそれよりも遅れている場合、上記切替後の通話データを上記切替前の通話データの直後の時刻に再生するように修正することを特徴とする移動通信端末。
【請求項２０】
請求項１５に記載の移動通信端末において、上記エラー修正部は、切替後の通話データの再生時刻が切替前のそれよりも遅れている場合、上記切替前の通話データの再生時刻以降の通話データを上記デコーダから受信するまでの間、無音状態もしくは他の音声により補間し、上記受信した通話データを切替後の先頭の通話データとすることを特徴とする移動通信端末。
【請求項２１】
請求項２０に記載の移動通信端末において、
前記他の音声は、予め用意された音データ、受信済みの通話データを元に作成された音データ、上記切替前の通話データ、または上記切替前後の通話データを時間的に伸張して得られた音データに基づき生成されることを特徴とする移動通信端末。
【請求項２２】
請求項８に記載の移動通信端末において、上記ハンドオーバ処理部は、上記第１及び第２の通信ネットワークのいずれかを経由してロケーションサーバと情報を交換することにより、前記移動通信端末の位置情報を取得する位置情報取得部を有し、
上記位置情報取得部は、予め設定されたマッピング情報と上記位置情報を用いて上記位置情報における電話端末の通信経路を判定し、
上記判定結果を元に上記第１及び第２の通信ネットワークの切替を決定することを特徴とする移動通信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の移動通信端末（例えば携帯電話）間で複数の通信ネットワークを介して通信を行う場合におけるハンドオーバ処理の技術に関する。
【背景技術】
【０００２】
携帯電話などの移動通信端末が他の端末やサーバと接続して通信サービスを受けているときに、動的に通信網を切り替えて通信サービスを継続する場合は、いわゆるハンドオーバ処理が為される。このハンドオーバ処理は、例えば通信サービスのセッション情報を、通信ネットワーク（以下、通信路と呼ぶ場合もある）にある中継装置やエージェントに保持しておき、切替後の通信網における通信サービスで上記セッション情報を用いて通信サービスを継続するものである。
【０００３】
ここでセッション情報とは、例えば、サーバ／クライアント端末のＩＰアドレスとポート番号、通信プロトコル、セッション開始時刻、サービス経過時間、サービス名、使用アプリケーション名等がある。
【０００４】
上記通信網の切り替えを円滑に行うための従来技術としては、例えば特許文献１に記載のものが知られている。これは、切替前の通信路におけるセッションと切替後の通信路におけるセッションとを、一時的に二つ同時に移動端末との間で確立する方法を開示する。
【０００５】
【特許文献１】特開2004-356922号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記特許文献１に記載のものは、蓄積されたコンテンツを配信するサービスのみに適用され得るもので、異なる複数の移動通信端末間での通信において上記通信網の切替を円滑にすることについては考慮されていない。
【０００７】
本発明は、上記事情を鑑みて為されたものであり、その目的は、異なる複数の移動通信端末間での通信において通信網の切り替えを円滑に行うための技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明は、通信ネットワークの切替時には、切り替え前後の各通信ネットワーク上で互いにセッションを一時的に二つ同時に確立する。そして、両セッションで同一の通話データの送受信を行い、切替前と切替後の二つの通信ネットワークから受信された通話データの時刻情報に基づいて、通信ネットワーク（セッション）を切替えることを特徴とするものである。
【０００９】
上記通信ネットワークの切り替えが失敗したときには、切替前の通信ネットワークを介しての通話、もしくは上記切り替え処理の再試行のいずれか一方を実行する。また、ある移動通信端末から別の移動通信端末へ通話データを送信するときは、ある通信ネットワークを用い、上記別の移動通信端末から別の移動通信端末へ通話データを送信するときは、別の通信ネットワークを用いることも、本発明の特徴である。
【発明の効果】
【００１０】
本発明によれば、異なる複数の移動通信端末間での通信において通信網の切り替えを円滑に行うことが可能となる。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照して本発明の実施形態について説明する。
【実施例１】
【００１２】
図１〜図２を参照して、本発明の実施形態１による電話ハンドオーバシステムについて説明する。
【００１３】
図１は、実施形態１に係る電話ハンドオーバシステムにおけるハンドオーバサーバ１００、および移動通信端末であるハンドオーバ端末１０５の構成を示す図である。同図では、ハンドオーバサーバ１００を中継して、電話端末１０４とハンドオーバ端末１０５とが通話を行う場合のシステム構成を示している。ここで電話端末１０４は、本発明で開示するハンドオーバ機能を持たない、一般的なＩＰ電話機能を有する電話端末である。
【００１４】
同図において、ハンドオーバサーバ１００は、ハンドオーバ処理部１０１、通話処理部１０２、および通信網インタフェース部１０３とから構成される。ハンドオーバ処理部１０１は、通信網＃２（１０８）経由の通話セッションと通信網＃３（１０７）経由の通話セッションとの切替処理を行うとともに、電話端末１０４とハンドオーバサーバ１００間の通話セッションと、ハンドオーバサーバ１００とハンドオーバ端末１０５間の通話セッションとの通話内容を互いへ反映させる。通話処理部１０２は、他端末との間の通話セッションにおけるメッセージの送受信、および通話データの送受信を制御する。通信網インタフェース部１０３は、通信網＃１へアクセスするための網インタフェースである。
【００１５】
ハンドオーバ端末１０５は、通信網インタフェース部１０９、通話処理部１１０、ハンドオーバ処理部１１１、および音声処理部１１２とから構成される。通信網インタフェース部１０９は、通信網＃２（１０８）と通信網＃３（１０７）へアクセスするための網インタフェースである。ハンドオーバ端末は通信網＃２（１０８）と通信網＃３（１０７）を経由して通信網＃１（１０６）へ接続できる。通話処理部１１０は、他端末との間の通話セッションにおけるメッセージの送受信、および通話データの送受信を制御する。ハンドオーバ処理部１１１は、通信網＃２（１０８）経由の通話セッションと通信網＃３（１０７）経由の通話セッションとの切替処理を行う。音声処理部１１２は、マイク等の入力デバイスから入力される通話音をエンコードしてハンドオーバ処理部１１１へ渡す（Ｄ１０３a）とともに、ハンドオーバ処理部から渡される受信通話データ（Ｄ１０３b）をデコードしてスピーカ等の出力デバイスへ通話音を出力する。
【００１６】
次に図２を用いて、ハンドオーバサーバ１００を介してハンドオーバ端末１０５と、一般的な電話端末１０４とでＩＰ電話サービスのハンドオーバを行うときの流れを示す。同図では、ＩＰ電話サービスの通話を行うための呼制御プロトコルとしてＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ：  ＩＥＴＦ  ＲＦＣ３２６１）を用いた例を示す。ただし本発明のハンドオーバ処理は、ＩＴＵ−Ｔ  Ｈ．３２３など他の呼制御プロトコルであっても同様に適用できる。
【００１７】
また同図では、ハンドオーバ端末１０５、ハンドオーバサーバ１００、および電話端末１０４が直接ＳＩＰメッセージを交換しているが、ハンドオーバ端末１０５とハンドオーバサーバ１００の間、およびハンドオーバサーバ１００と電話端末１０４の間の呼確立のためにＳＩＰプロキシなどの呼制御サーバを一つ以上経由した構成であっても、本発明のハンドオーバ処理は同様に適用できる。
【００１８】
ハンドオーバ端末１０５は、通話処理部１１０において、通常のＩＰ電話機能で動作するか、ハンドオーバサーバ経由で動作するかを示すモードフラグを備える。ハンドオーバサーバ経由モードである場合、通話処理部１１０は通信網＃２（１０８）を経由して、電話端末１０５へのＩＮＶＩＴＥ（セッション確立要求）メッセージ（Ｍ２００）をハンドオーバサーバ１００へ送信する。ハンドオーバサーバ１００における通話処理部１０２は、ＩＮＶＩＴＥメッセージ（Ｍ２００）を受信すると、Ｒｉｎｇｉｎｇ（呼び出し中）メッセージ（Ｍ２０１）をハンドオーバ端末１０５へ返すとともに、ＩＮＶＩＴＥメッセージ内の“To”ヘッダに含まれる着信先ＵＲＩ（同図の例では電話端末１０４のＵＲＩ）を解析し、電話端末１０４へＩＮＶＩＴＥメッセージを送信する（Ｍ２０２）。ハンドオーバ端末１０５内の通話処理部１１０がRingingメッセージ（Ｍ２０１）を受信すると、通話処理部１１０はハンドオーバ端末１０５で呼び出し音を鳴らす。
【００１９】
電話端末１０４はＩＮＶＩＴＥメッセージ（Ｍ２０２）を受信すると、Ringingメッセージ（Ｍ２０３）を返すとともに、着信音を鳴らし、電話端末１０４のユーザが受話器を上げて、通話を許可するまで待つ。そして通話が許可されると、ＯＫメッセージ（Ｍ２０４）をハンドオーバサーバ１００へ送信する。ハンドオーバサーバ１００内の通話処理部１０２はＯＫメッセージ（Ｍ２０４）を受信すると、ハンドオーバ端末１０５に対しＯＫメッセージ（Ｍ２０５）を送信する。ハンドオーバ端末１０５内の通話処理部１１０はＯＫメッセージ（Ｍ２０５）を受信すると、ＡＣＫ（確認応答）メッセージ（Ｍ２０６）をハンドオーバサーバ１００へ返す。ハンドオーバサーバ１００内の通話処理部１０２は、ＡＣＫメッセージ（Ｍ２０６）を受信すると、電話端末１０４へＡＣＫメッセージ（Ｍ２０７）を送信する。電話端末１０４がＡＣＫメッセージ（Ｍ２０７）を受信した時点で、通信網＃２（１０８）経由でハンドオーバサーバ１００を介して、ハンドオーバ端末１０５と電話端末１０４との通話セッションが確立される。
【００２０】
この時点以降、ハンドオーバ端末１０５はハンドオーバサーバ１００との間で通話データの送受信（Ｄ１０１）を行う。またハンドオーバサーバ１００は電話端末１０４との間で通話データの送受信（Ｄ１００）を行う。ハンドオーバサーバ１００におけるハンドオーバ処理部１０１では、ジッタなどの通信遅延の変動を吸収するために、ハンドオーバ端末１０５から送られる通話データ（Ｄ１０１b）を、内部のバッファ領域４０１に格納し、バッファがある一定量に達した時点で古い順に通話データを電話端末１０４へ転送するとともに、電話端末１０４から送られる通話データ（Ｄ１００a）をハンドオーバ端末１０５へ転送する。ハンドオーバオーバ端末１０５では、ジッタなどの通信遅延の変動を吸収するために、受信した通話データ（Ｄ１０１a）をバッファ３０１に格納し、バッファがある一定量に達した時点で古い順に通話データ（Ｄ１０１a）を音声処理部１１２へ転送する（Ｄ１０３）。音声処理部１１２では通話データ（Ｄ１０３a）のパケット解析、音声データの分離、音声デコードを行い、出力デバイスから音声を出力する。また入力デバイスから音声を入力、音声エンコード、パケット生成を行い、通話データ（Ｄ１０３b）として通話処理部１１０へ送り、これが通話データ（Ｄ１０１b）としてハンドオーバサーバ１００へ送出される。上記のような処理により、ハンドオーバ端末１０５と電話端末１０４との通話が実現される。なお、ＳＩＰでは上記の通話データはＲＴＰ（Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ：ＩＥＴＦ  ＲＦＣ３５５０）に従う音声パケット形式で送受信されるが、本発明においては必ずしもＲＴＰに限定されるものではない。
【００２１】
なお、図２ではハンドオーバ端末１０５から電話端末１０４へ呼び出しをかける場合の例を示したが、電話端末１０４からハンドオーバ端末１０５へ呼び出しをかける場合にも、同様にハンドオーバサーバ１００を経由したセッション確立が行われる。この場合、ハンドオーバ端末１０５は予め、自身への着信をハンドオーバサーバ１００へ転送するよう、同端末１０５を管理するＳＩＰサーバへ登録しておくなどの処理を行う必要がある（例えば、ＳＩＰのリダイレクト機能などを用いる方法がある）。そして電話端末１０４がハンドオーバ端末１０５の転送先としてハンドオーバサーバ１００のＵＲＩを知ることができる状態にしておく必要がある。
【００２２】
次に、上記のようにハンドオーバ端末１０５が通信網＃２（１０８）を経由してハンドオーバサーバ１００を介して電話端末１０４と通話を行っている状態で、ハンドオーバ端末１０５が何らかの形で通信網＃２（１０８）のスループット低下を検知し、ハンドオーバを決定したときに（２０１）、通話を通信網＃３（１０７）経由に切り替える処理について述べる。ただし、ハンドオーバの決定（２０１）は、必ずしもスループット低下の検知のみにより行われるものではない。例えば、ハンドオーバ端末１０５が、通信網＃３（１０７）が使用可能である場合には優先的に通信網＃３（１０７）へ切り替えるように設定されている場合には、通信網＃２（１０８）のスループットが低下していなくても、ハンドオーバが決定される。その他、ハンドオーバ端末１０５のユーザが、強制的に通信網＃３（１０７）へ切り替えるように、端末上で操作を行うことにより、ハンドオーバが決定されてもよい。また、ハンドオーバ端末１０５がＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）などの機能を備えるなど、何らかの手段により端末自身の位置情報を取得することができる場合には、通信網＃２、通信網＃３のスループットに関わらず、位置情報に応じてハンドオーバが決定されてもよい。位置情報に応じてハンドオーバを決定する端末の構成については、実施例８として後述する。
【００２３】
上記のスループット低下を検知する方法としては、ＲＴＣＰ（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ：ＩＥＴＦ  ＲＦＣ３５５０）によりパケットの送受信情報を交換する方法がある。その他、受信したＲＴＰパケットのシーケンス番号からパケットロスの増加を検出する方法や、バッファ残量の低下を検出する方法、スループット計測用のダミー通信を行う方法、もしくは端末の無線デバイスが公開する電波状況を参照する方法、なども適用可能である。
【００２４】
ハンドオーバ端末１０５が通信網＃２（１０８）のスループット低下を検知し、ハンドオーバの実行を決定（２０１）すると、ハンドオーバ処理部１１０は、通信網＃３（１０７）経由で、ＩＮＶＩＴＥメッセージ（Ｍ２０８）をハンドオーバサーバ１００へ送信する。ハンドオーバサーバ１００内のハンドオーバ処理部１０２は、ＩＮＶＩＴＥメッセージ（Ｍ２０８）を受信すると、通信網＃２（１０８）経由で確立済みのセッションの着信元の識別子（Fromヘッダのtag値などを利用）と着信先アドレス（Toヘッダ）との情報が、ＩＮＶＩＴＥメッセージ（Ｍ２０８）内の情報と一致するかどうかを照合する（２０２）。上記の照合により、通信網＃２（セッション確立済み）と通信網＃３（セッション確立要求中）の着信元と着信先とが一致することが確認されると、ハンドオーバサーバ１００内の通話処理部１０２は、ＯＫメッセージ（Ｍ２０９）をハンドオーバ端末１０５へ返す。ハンドオーバ端末１０５内の通話処理部１１０は、ＯＫメッセージ（Ｍ２０９）を受信すると、ＡＣＫメッセージ（Ｍ２１０）をハンドオーバサーバ１００へ返す。この時点で通信網＃３（１０７）経由でのハンドオーバサーバ１００とのセッションが確立されたことで、通信網＃２（１０８）と通信網＃３（１０７）との２つの通信網上で同時に２つのセッションが確立される。
【００２５】
その後、ハンドオーバサーバ１００はハンドオーバ端末１０５との間で通話データの送受信（Ｄ１０２）を行う。このときハンドオーバサーバ１００におけるハンドオーバ処理部１０１では、ハンドオーバ端末１０５へ既に送信している通話データと同じデータを通信網＃３（１０７）を経由してハンドオーバ端末１０５へ転送する（Ｄ１０２a）。ハンドオーバ端末１０５は、受信した通話データ(Ｄ１０２a)をバッファ３０２へ格納し続ける。バッファ３２０の残量がなくなった場合には、古い順に削除していく。またハンドオーバ処理部１０１では、通信網＃３（１０７）を経由してハンドオーバ端末１０５から送られる通話データ（Ｄ１０２ｂ）を受信し、内部のバッファ領域４０２に格納する。バッファ残量がなくなった場合には、古い通話データから削除していく。
【００２６】
この時点でハンドオーバサーバ１００からは、電話端末１０４から送られる通話データ（Ｄ１００）が、通信網＃２（１０８）と通信網＃３（１０７）の両方の網から同時に、それぞれ通話データＤ１０１ａ、Ｄ１０２ａとして、ハンドオーバ端末１０５へ送出される。また通信網＃２（１０８）と通信網＃３（１０７）を経由してハンドオーバ端末１０５から通話データＤ１０１ｂ，Ｄ１０２ｂがハンドオーバサーバへ送られる。そして通信網＃２（１０８）の通話データ（Ｄ１０１）が電話端末１０４へ、通話データ（Ｄ１００）として転送されている。
【００２７】
この状態で、ハンドオーバ端末１０５のハンドオーバ処理部１１１においてハンドオーバ処理２０３を、ハンドオーバサーバ１００のハンドオーバ処理部１０１において、ハンドオーバ処理２０４をそれぞれ実行開始する。
【００２８】
ここでハンドオーバ端末１０５において行われるハンドオーバ処理２０３について述べる。上記のように２つの通話セッションが確立された時点では、ハンドオーバ端末１０５におけるハンドオーバ処理部１１１では、通信網＃２（１０８）を経由して受信される通話データ（Ｄ１０１a）と、通信網＃３（１０７）を経由して受信される通話データ（Ｄ１０２a）とが、それぞれバッファ３０１と３０２とに格納されている。ハンドオーバ処理２０３においては、それぞれのバッファに格納されている通話データの時刻情報を管理し、双方のバッファ内の通話データが、時刻的に途切れがないような時刻をハンドオーバ時刻と決定し、その時刻以降の通話データ（Ｄ１０３a）を、バッファ３０１の通話データ（Ｄ１０１a）からバッファ３０２の通話データ（Ｄ１０２a）へと切り替える。ただし通信網＃２と通信網＃３との遅延差が大きいなどの理由で、両バッファ内で時刻的に重複するようなデータが格納されていない場合については、極力、時刻の差が少なくなるような時刻をハンドオーバ時刻と決定して、上記の通話データの切替を行う。
【００２９】
ハンドオーバサーバ１００において行われるハンドオーバ処理２０４もハンドオーバ処理２０３と同様である（図４参照）。すなわち上記のように２つの通話セッションが確立された時点では、ハンドオーバサーバ１００におけるハンドオーバ処理部１０１では、通信網＃２（１０８）を経由して受信される通話データ（Ｄ１０１b）と、通信網＃３（１０７）を経由して受信される通話データ（Ｄ１０２b）とが、それぞれバッファ４０１と４０２とに格納されている。ハンドオーバ処理２０４においては、それぞれのバッファに格納されている通話データの時刻情報を管理し、双方のバッファ内の通話データが、時刻的に途切れがないような時刻をハンドオーバ時刻と決定し、その時刻以降の通話データ（Ｄ１００b）を、バッファ４０１の通話データ（Ｄ１０１b）からバッファ４０２の通話データ（Ｄ１０２b）へと切り替える。ただし通信網＃２と通信網＃３との遅延差が大きいなどの理由で、両バッファ内で時刻的に重複するようなデータが格納されていない場合については、極力、時刻の差が少なくなるような時刻をハンドオーバ時刻と決定して、上記の通話データの切替を行う。
【００３０】
ハンドオーバサーバ１００におけるハンドオーバ処理２０４が終了すると、ハンドオーバサーバ１００のハンドオーバ処理部１０１は、ハンドオーバ完了メッセージ（Ｍ２１１）をハンドオーバ端末１０５へ送信する。ハンドオーバ端末１０５は、ハンドオーバ完了メッセージ（Ｍ２１１）を受信することで、ハンドオーバサーバ１００のハンドオーバ処理２０４の終了を知る。自身のハンドオーバ処理２０３と、ハンドオーバサーバ２０４とが終了すると、ハンドオーバ端末１０５は通信網＃２経由でＢＹＥメッセージ（Ｍ２１２）をハンドオーバサーバ１００に送信し、自身は通信網＃２経由でのハンドオーバサーバへ送信する通話データ（Ｄ１０１b）の送信を終了する（２０５）。ハンドオーバサーバ１００は、ＢＹＥメッセージ（Ｍ２１２）を受信すると、自身は通信網＃２経由でのハンドオーバ端末１０５への通話データ（Ｄ１０１a）の送信を停止し（２０６）、ＯＫメッセージ（Ｍ２１３）をハンドオーバ端末１０５へ送信する。以上のように、通信網＃２の通話セッションが終了することで、通信網＃２から通信網＃３への通話セッションのシームレスな切替が実現できる。上述の例は、ハンドオーバ端末１０５とハンドオーバサーバ１００とは、双方におけるハンドオーバ処理が完了してから、それぞれにおける通話データの送信が停止され、通信網＃２の通話セッションが終了されるケースである。
【００３１】
一方、ハンドオーバ端末１０５とハンドオーバサーバ１００とは、自身のハンドオーバ処理完了を待つことなく、他方のハンドオーバ処理が終了した時点で他方への通話データの送信を停止するような動作も可能である。この場合の処理について図７を用いて説明する。
【００３２】
図７において、ハンドオーバ端末１０５とハンドオーバサーバ１００の双方でそれぞれハンドオーバ処理２０３、および２０４が実行されるまでの流れは既述と同様である。ここで、ハンドオーバ端末１０５は、ハンドオーバ処理２０３が完了したとき、ハンドオーバ完了メッセージ（Ｍ７００）をハンドオーバサーバ１００へ送信する。ハンドオーバサーバ１００は、この完了メッセージ（Ｍ７００）を受信すると、通信網＃２への通話データの送信を停止する（２０６）。そしてハンドオーバサーバ１００は、ハンドオーバ処理２０４が完了したとき、ハンドオーバ完了メッセージ（Ｍ７０１）をハンドオーバ端末１０５へ送信する。ハンドオーバ端末１０５は、完了メッセージ（Ｍ７０１）を受信した時点で、ハンドオーバ端末、ハンドオーバサーバ双方でハンドオーバ処理が完了したことを知り、通信網＃２経由でＢＹＥメッセージ（Ｍ２１２）をハンドオーバサーバ１００へ送信する。そしてハンドオーバ端末１０５は、ハンドオーバサーバ１００への通話データの送信を停止する（２０５）。その後、ハンドオーバサーバ１００は、ＢＹＥメッセージ（Ｍ２１２）に対するＯＫメッセージ（Ｍ２１３）をハンドオーバ端末１０５へ返す。このように通信網＃２の通話セッションが終了することで、通信網＃２から通信網＃３への通話セッションのシームレスな切替が実現できる。
【００３３】
上述のように、本発明の実施形態１による電話ハンドオーバシステムでは、２端末間にハンドオーバ機能を提供するハンドオーバサーバを設置し、ハンドオーバサーバが２端末間の通話セッションを中継する仕組みを導入する。そしてこのハンドオーバサーバとハンドオーバ端末の間に、同一の通話データのセッションを同時に確立することができる。そしてハンドオーバ端末とハンドオーバサーバはそれぞれ、これらのセッションにおいて受信される二つの通話データの再生時刻を取得し、極力中断が発生しないようにタイミングを決めて双方のデータの切替を行う。よって、従来の片方向の配信サービスのみでしか実現できなかったシームレスハンドオーバ機能を、ＩＰ電話のような双方向通信サービスでも実現することが可能となる。
【実施例２】
【００３４】
本発明の実施形態２は、実施形態１の変形例として、ハンドオーバ端末１０５のハンドオーバ処理部１１１が、音声処理部１１２から渡される通話データＤ１０３ｂをハンドオーバサーバへ送出する際に、バッファへ蓄積後、一定のバッファ量に達してからハンドオーバサーバ１００へ通話データＤ１０３ｂを送出する構成をとる。同様にハンドオーバサーバ１００のハンドオーバ処理部１０１が、電話端末１０４から送られる通話データＤ１００aをハンドオーバ端末１０５へ送出する際に、バッファへ蓄積後、一定のバッファ量に達してからハンドオーバ端末１０５へ送出する構成をとる。本発明の実施形態２によると、ハンドオーバ端末１０５、ハンドオーバサーバ１００とも、送出時にバッファである程度の遅延を設けることで、通信網へのパケット送出時のレートの変動やジッタなどの影響を軽減することができる。
【実施例３】
【００３５】
本発明の実施形態３は、実施形態２の変形例として、監視されたスループットに応じてコーデックやコンテンツビットレートを変更する構成をとる。本発明の実施形態３によると、送出時のコーデックやビットレートを、スループットに適応させることで、パケットロスを減少させることができる。
【実施例４】
【００３６】
本発明の実施形態４は、実施形態１の変形例として、音声のみではなく、映像処理機能も含める構成をとる。映像データに対しても、実施例１の通話データと全く同様の構成を追加することで、ＩＰ−ＴＶ電話サービスに対してもシームレスなハンドオーバ機能を実現できる。
【実施例５】
【００３７】
本発明の実施形態５は、図２と図７で示した実施形態１におけるシーケンスに、ハンドオーバ処理が失敗した場合の処理を含めたシーケンスにより動作する。ここで、ハンドオーバ処理が失敗する現象とは、新たな通信網＃３に通信経路を切り替えたが、通信網＃３におけるスループットが不足し、通話を継続するに十分な通話データが受信されないことを意味する。
【００３８】
図２では、ハンドオーバ端末１０５とハンドオーバサーバ１００とは、双方におけるハンドオーバ処理が完了するまで、それぞれにおける通話データの送信は停止されない。すなわち、ハンドオーバ処理の失敗時にも、通信網＃２と通信網＃３の両方で通話データの送信が双方向で行われている。本実施形態のハンドオーバシステムでは、ハンドオーバ処理の失敗時には、ハンドオーバ実行前の通信網（通信網＃２）か、ハンドオーバ実行後の通信網（通信網＃３）かのいずれかに、双方向通信の経路が戻るように動作する。
【００３９】
図５を用いて、ハンドオーバ処理失敗時に、ハンドオーバ通信網＃２へ、双方向通信の経路を戻す処理の流れを説明する。図５において、ハンドオーバ端末１０５とハンドオーバサーバ１００の双方でそれぞれハンドオーバ処理２０３、および２０４が実行されるまでの流れは既述と同様である。ハンドオーバサーバ１００は、ハンドオーバ処理２０４が失敗すると、ハンドオーバ失敗メッセージ（Ｍ５００）をハンドオーバ端末１０５へ送信する。ハンドオーバ端末１０５は、ハンドオーバ失敗メッセージ（Ｍ５００）を受信すると、ハンドオーバ処理２０３を中止する（５０１）。
【００４０】
このハンドオーバ中止処理５０１は、ハンドオーバ失敗メッセージ（Ｍ５００）を受信した時点で、もしもハンドオーバ処理２０３が音声処理部１１２へ送られる通話データが、通信網＃２から受信したデータである場合には、音声処理部１１２へ送る通話データを通信網＃３経由へ切り替える動作を停止する。もしもハンドオーバ処理２０３が音声処理部１１２へ送られる通話データが、通信網＃３から受信したデータである場合には、音声処理部１１２へ送る通話データを通信網＃２経由へシームレスに切り替える動作を実行する。
【００４１】
ハンドオーバ端末１０５は、このハンドオーバ中止処理５０１により、通話データの受信経路が通信網＃２となった時点で、ＢＹＥメッセージ（Ｍ２１２）を通信網＃３経由でハンドオーバ端末１００へ送信する。そしてハンドオーバ端末１０５は、ハンドオーバサーバ１００への通信網＃３経由による通話データの送信を停止する（２０５）。
【００４２】
その後、ハンドオーバサーバ１００は、ＢＹＥメッセージ（Ｍ２１２）を受信すると、ハンドオーバ端末１０５への通信網＃３経由による通話データの送信を停止し（２０６）、ＯＫメッセージ（Ｍ２１３）をハンドオーバ端末１０５へ返す。以上に述べた流れにより、ハンドオーバサーバにおいてハンドオーバ処理が失敗した場合でも、ハンドオーバ実行前の通信網に双方向通信経路を戻すことが可能である。このような動作は、通信網＃３に比べ、通信網＃２が比較的安定していることが期待されるような状況において有効である。
【００４３】
逆に、通信網＃２に比べて、通信網＃３の方が安定していることが期待できるような状況においては、ハンドオーバ処理が失敗したときに、通信網＃２へ通信経路を戻さずに、通信網＃３への切替を繰り返し実行する方が、通信を継続できる可能性が高い。
【００４４】
図６を用いて、ハンドオーバ処理が失敗したときに、通信網＃３への切替を繰り返し試行するときの処理の流れを示す。図６において、ハンドオーバ端末１０５とハンドオーバサーバ１００の双方でそれぞれハンドオーバ処理２０３、および６００が実行されるまでの流れは既述と同様である。ここでハンドオーバ処理６００は、既に述べたハンドオーバ処理２０４に対し、ハンドオーバが失敗した場合でも、図５で述べたようなハンドオーバ失敗通知メッセージを送信せずに、通信網＃３からの通話データ受信が安定するまで繰り返し、切替を試みる機能が付加されたものである。すなわち、ハンドオーバ処理６００が完了し、通信網＃３からの通話データが音声処理部１０１へ供給されるまで、ハンドオーバ処理は完了しない。ハンドオーバ処理が完了するまでの間、通信網＃２と通信網＃３の両方において、双方向の通話データの送受信が行われる。ハンドオーバ処理６００が完了した以降の処理の流れは、既に述べた通りである。
【００４５】
図７に、図２と異なるハンドオーバ処理（成功例）を示す。図７と図２との違いは、ハンドオーバ端末１０５とハンドオーバサーバ１００とは、自身のハンドオーバ処理完了を待つことなく、他方のハンドオーバ処理が終了した時点で他方への通話データの送信を停止ることのみである。これ以外については図２のものと同様である。
【００４６】
ハンドオーバ処理メッセージ完了したときのハンドオーバ端末の処理について、図８を用いて説明する。ここでは、図７のようなケースにおいて、ハンドオーバ処理が失敗した場合の動作について説明する。
【００４７】
図８では、通信網＃２においては、上り（端末->サーバ）方向のスループットが下り（サーバ->端末）に比べて良好であり、通信網＃３においては、下り方向のスループットが上りに比べて良好であるような状況を想定している。図８において、ハンドオーバ端末１０５とハンドオーバサーバ１００の双方でそれぞれハンドオーバ処理２０３、および２０４が実行され、ハンドオーバ処理２０３が完了する。その後、完了メッセージ（Ｍ７００）がハンドオーバサーバ１００へ通知される。そして、ハンドオーバサーバ１００にて通信網＃２への通話データ送信が停止される（２０６）。ここまでの処理の流れは、図７の流れと同様である。
【００４８】
この状態では、通信網＃３では双方向の通話データが、通信網＃２では、上り（端末->サーバ）向きの通話データがそれぞれ送られている（Ｄ８００）。ハンドオーバサーバ１００は、ハンドオーバ処理２０４において、通信網＃３への切替処理に失敗すると、ハンドオーバ失敗通知メッセージ（Ｍ７０１）をハンドオーバ端末１０５へ送信する。ハンドオーバ端末１０５は、メッセージ（Ｍ７０１）を受信しても、ハンドオーバ処理２０３を継続し、通信網＃３への通話データの送信を停止する（２０５）。この状態では、上り方向の通信では通信網＃２が、下り方向の通信では通信網＃３がそれぞれ通信経路として使用されている。
【００４９】
もしもそれぞれの通信網がこの状態で安定していれば、この通信形態のまま継続することが可能である。もしこの状態から、仮に通信網＃３の上り方向のスループットが回復した場合には、ハンドオーバサーバ１００は、ハンドオーバ端末１０５へ、通信網＃３を経由した通話データの再送信要求メッセージを送信する（Ｍ８００）。
【００５０】
ハンドオーバ端末１０５は、上記メッセージ（Ｍ８００）を受信すると、送話データを通信網＃３を経由してハンドオーバサーバ１００へ送信する。この状態では、通信網＃３では双方向の通話データが、通信網＃２では、上り（端末->サーバ）向きの通話データがそれぞれ送られている（Ｄ８０２）。ハンドオーバサーバ１００は、この状態の間にハンドオーバ処理２０４を再実行し、通信網＃３への切替を試みる。以降、ハンドオーバ処理２０４が成功した際の処理は図７と同様である。
【００５１】
上述の内容では、ハンドオーバサーバ１００においてハンドオーバ処理が失敗したケースについて説明してきたが、ハンドオーバ端末１０５においてハンドオーバ処理が失敗したケースについても同様に適用可能である。
【実施例６】
【００５２】
本発明の実施形態６は、図９に示すように、ハンドオーバ端末がプライベート通信網に属し、ハンドオーバサーバがグローバル通信網に属するようなハンドオーバシステムにおいて、ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ）越え機能を備えるものである。例えば、図１において通信網＃１はグローバル通信網９０３であり、通信網＃２と通信網＃３の少なくともいずれか一つが、プライベート通信網９０４であるような場合に相当する。
【００５３】
実施形態６の具体的な例としては、通信網＃１がインターネット、通信網＃２が家庭やオフィス内のプライベートな無線ＬＡＮ通信網、通信網＃３が携帯電話網に接続されるグローバル通信網である構成が典型的である。プライベート通信網とグローバル通信網との間にはルータが存在し、ルータは一般的にＮＡＴ機能を備える。ＮＡＴとは、プライベート通信網のＩＰアドレスと、グローバル通信網のＩＰアドレスとを透過的に相互変換することにより、一つのグローバルＩＰアドレスを、プライベート通信網内の複数のコンピュータにより共有することを可能とする技術である。なお、本発明では、特に断りのない限り、ＮＡＴとは、ＩＰアドレスとポート番号を変換するＮＡＰＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ／Ｐｏｒｔ  Ｔｒａｎｓｌａｔｉｏｎ）を指すこととする。
【００５４】
ＮＡＴではポート番号の変更が行われるため、グローバル通信網上のコンピュータからプライベート通信網上のコンピュータへのアクセスが行えない。このため、ハンドオーバサーバからハンドオーバ端末へＳＩＰメッセージや音声データの送信を行うためには、ＮＡＴを越えるための何らかの手法が実装される必要がある。
【００５５】
ＮＡＴ越えの手法としてはいくつか存在するが、ここではＵＤＰホールパンチングと呼ばれる手法を用いた実施形態について図１０から図１７を用いて説明する。ただしこれらの図では、ハンドオーバ端末とハンドオーバサーバの間のＮＡＴ越え通信のみについて説明する。ハンドオーバサーバより先の電話端末との通信は、これらの図では省略されているが、実施形態１と同様である。
【００５６】
図１０を用いて、ＳＩＰメッセージ交換のＮＡＴ越えの方法について説明する。ハンドオーバ端末９０２、ハンドオーバサーバ９００はともに、ＮＡＴ越えを行うための機能を有する。ハンドオーバ端末９０２は、ＳＩＰソケットを作成し（１００１）、そのソケット（すなわちＳＩＰ用のポート番号）を使用してハンドオーバサーバ９００に対し、グローバルアドレス要求メッセージ（Ｍ１０００）を送信する。ここで、ソケットとは、通信プログラムのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）において、ＩＰアドレス、ポート番号、プロトコルになどを指定して通信を行うたまに作成される記述子であり、このソケットを引数として通信プログラムはＡＰＩを用いた通信を実現する。また、グローバルアドレスとは、ＮＡＴがプライベート通信網からグローバル通信網へ送られるパケットに割り当てるグローバルＩＰアドレスと、ポート番号の対を意味する。
【００５７】
メッセージＭ１０００は、ＵＤＰパケットとして送信される。以降、特に断りのない限り、図１０から図１７に記されているメッセージは全てＵＤＰパケットにより送信されていることとするが、ＴＣＰパケットであっても同様に適用できる。また、メッセージＭ１０００の送信先のポート番号は、ハンドオーバサーバ９００で用意したＮＡＴ越え処理専用のポート番号である。このポート番号はハンドオーバサーバで予め設定済みであり、ハンドオーバ端末に既知の値とする。すなわちハンドオーバサーバ９００では、ＮＡＴ越え処理用のソケットは予め作成されているものとする（図１０では省略）。
【００５８】
ハンドオーバサーバ９００は、このメッセージパケットＭ１０００にマッピングされたグローバルアドレス（ＮＡＴ上のポート番号と、グローバルＩＰアドレス）を取得し、メッセージＭ１００１により、グローバルアドレスをハンドオーバ端末９０２へ通知する。
【００５９】
以上により、ハンドオーバサーバ９００は、取得したグローバルアドレスに対し、ＳＩＰメッセージを格納したＵＤＰパケットを送信することで、ＵＤＰによるＳＩＰメッセージを、ＮＡＴを越えてハンドオーバ端末９０２へ送信することができる。ただし、このマッピングを用いた通信が全く無い状態がある程度の時間続くと、マッピング情報がルータ内で削除されてしまう。このためハンドオーバ端末９０２は、ＳＩＰ用のポート番号を発信元として、定期的にダミーのＵＤＰパケットを前記グローバルアドレスに対して送信することで、マッピング情報を維持する（Ｄ１００２）。ハンドオーバサーバ９００は、受信したダミーデータを単に破棄する。
【００６０】
次に、図１１を用いてハンドオーバ端末側からの発呼によるハンドオーバサーバとの通話までの流れについて説明する。ハンドオーバ端末９０２は、端末利用者が電話をかけるなどの発呼のアクションを実行することで発呼を開始すると、ＲＴＰとＲＴＣＰ用のソケットを生成する（１１０１）。ＲＴＰソケットは、音声通話データ（ＲＴＰパケット形式）を送受信するためのソケット、ＲＴＣＰソケットは送受信結果に関する統計情報（ＲＴＣＰパケット）を送受信するためのソケットである。
【００６１】
そして、ＲＴＰ用ソケットとＲＴＣＰ用ソケット（すなわちそれぞれ、ＲＴＰ用ポート番号とＲＴＣＰ用のポート番号とが発信元となる）を使用して、それぞれハンドオーバサーバ９００に対し、グローバルアドレス要求メッセージ（Ｍ１１００）を送信する。ここで、Ｍ１１００は、ＲＴＰ用のグローバルアドレス要求メッセージと、ＲＴＣＰ用のグローバルアドレス要求メッセージの両方を意味するものである。
【００６２】
送信先のポート番号は、ＮＡＴ越え処理専用のポート番号とする（図１０と同様）。ハンドオーバ端末９００は、このメッセージＭ１１００にマッピングされたグローバルアドレスを調べ、メッセージＭ１１０１により、このグローバルアドレスをハンドオーバ端末９０２へ通知する。
【００６３】
ここで、Ｍ１１００は、ＲＴＰ用のグローバルアドレス返送メッセージと、ＲＴＣＰ用のグローバルアドレス返送メッセージの両方を意味するものである。ハンドオーバ端末９０２は、受信したグローバルアドレスの中のポート番号を取得し、これを含むようなＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）メッセージを生成する（１１０２）。ＳＤＰはＲＦＣ２３２７に規定される、セッション情報を記述するためのメッセージプロトコルである。
【００６４】
このＳＤＰメッセージの例を図２１に示す。同図で示すＳＤＰメッセージのうち、“ｍ＝”の行が、メディアタイプとトランスポート情報を記述するために必須な内容である。“ｍ＝”行の2番目の値（＝４９０００）が、このメディア（すなわち音声）を受信するためのポート番号を表す。このポート番号の値を、前記メッセージＭ１１０１で通知されたポート番号とする。他の行については、本発明内容と直接関わりはないため省略するが、詳細はＲＦＣ２３２７を参照されたい。
【００６５】
ハンドオーバ端末９０２は、図１０で既に述べたＳＩＰ用ポート番号を使い、ＩＮＶＩＴＥメッセージＭ１１０２をハンドオーバサーバ９００へ送信する。以降、図１１から図１７において、ハンドオーバ端末９０２からハンドオーバサーバ９００へ送信されるＳＩＰメッセージは、全て図１０で述べたＳＩＰ用ポート番号が使用される。ＩＮＶＩＴＥメッセージ（Ｍ１１０２）には、前述のＳＤＰメッセージ（１１０２）が含まれており、ハンドオーバサーバ９００は、このＳＤＰメッセージの中のポート番号を取得する。その後、ハンドオーバサーバ９００は、ＲＴＰ／ＲＴＣＰ用ソケットを作成（１１０３）し、自身のＲＴＰ／ＲＴＣＰ用ポート番号を含むＳＤＰメッセージを作成し、受信準備が完了した後、ＲＩＮＧＩＮＧ（Ｍ１１０３）を送信する。
【００６６】
ＲＩＮＧＩＮＧの送信先は、図１０で述べた処理において取得済みの、ＳＩＰメッセージ用のグローバルアドレスである。以降、図１１から図１７において、ハンドオーバサーバ９００からハンドオーバ端末９０２へ送信されるＳＩＰメッセージの送信先は、図１０、もしくは図１３（後述）で述べた処理によって予めハンドオーバサーバから通知されたＳＩＰメッセージ用のグローバルアドレスである。その後、ハンドオーバサーバ９００にて、ハンドオーバ端末９０２への応答準備が完了すると、ＯＫ（Ｍ１１０４）を送信する。
【００６７】
ハンドオーバ端末９０２は、その後ＡＣＫ（Ｍ１１０５）をハンドオーバサーバ９００へ返す。以上により、通話用セッションが確立され、通話データの送受信が開始される（Ｄ１１０１）。このとき、ハンドオーバサーバ９００からハンドオーバ端末９０２へ送信される通話データの送信先ＩＰアドレスは、Ｍ１１０１で通知したグローバルアドレス内のグローバルＩＰアドレスである。
【００６８】
また、ハンドオーバサーバ９００からハンドオーバ端末９０２へ送信される通話データ（ＲＴＰパケット）の送信先ポート番号は、ＩＮＶＩＴＥ（Ｍ１１０２）内のＳＤＰメッセージで示されるポート番号である。ただし、通常は、通話データ（ＲＴＰパケット）に対応するＲＴＣＰパケットの送信先ポート番号は、ＲＴＰポート番号に１を加えた値である。以上により、ハンドオーバ端末から発呼した場合の通話のＮＡＴ越えが実現できる。
【００６９】
ハンドオーバサーバが発呼する場合の通話のシーケンスを図１２に示す。図１１と比べて、発呼開始がハンドオーバサーバ９００から起こるため、ＲＴＰ／ＲＴＣＰソケット生成（１１０１、１１０３）とＳＤＰメッセージ作成（１１０２、１１０４）の順序が異なることや、ＳＩＰメッセージの方向が異なること以外は、同様である。
【００７０】
図１１と図１２では、それぞれ端末側からの発呼、およびサーバ側からの発呼開始後にグローバルアドレス取得のためのメッセージ交換（Ｍ１１００、Ｍ１１０１）が行われた。しかし、シームレスハンドオーバを実現するためには、切替前の通信網経由のデータのバッファが枯渇しない間に、切替後の通信網にて呼を確立し、音声通話を開始しなければならない。従って、発呼から通話開始までに要する時間は短い方が望ましい。特に通信網の遅延が大きい場合には、発呼後のメッセージ交換は少しでも少ない方が望ましい。メッセージ交換を少なくする処理の流れの例を、図１７を用いて説明する。
【００７１】
図１７では、図１０のＳＩＰ通信のＮＡＴ越えが完了後、ハンドオーバサーバ、ハンドオーバ端末の発呼、着呼を待たずに、双方ともすぐにＲＴＰ、およびＲＴＣＰ用ソケットを生成する。その後すぐにハンドオーバ端末９０２は、ＲＴＰ、およびＲＴＣＰ通信のためのグローバルアドレス要求メッセージ（Ｍ１１００）を送信し、ハンドオーバサーバ９００はグローバルアドレスを返す（Ｍ１１０１）。
【００７２】
その後、ハンドオーバ端末９０２は、ＲＴＰ、およびＲＴＣＰ用ポートを発信元ポート番号として、定期的にホールパンチングのためのダミーパケットをハンドオーバサーバ９００へ送信する（Ｄ１００３）ことで、ＮＡＴ９０１におけるマッピングを維持させる。このように、実際の発呼が始まる前にグローバルアドレスを取得しておくことで、図１１および図１２において、グローバルアドレスの取得が不要となるため、発呼から通話開始までの時間を短縮できる。
【００７３】
ハンドオーバ端末９０２は、通話する相手の数は通常一つ（ハンドオーバサーバ９００）なので、予めＲＴＰ、およびＲＴＣＰ用のソケットを生成しておくことは容易である。しかしハンドオーバ端末９００は、不特定多数のハンドオーバ端末と通話を行う。このため、ハンドオーバ端末９００では、予め複数のハンドオーバ端末を想定し、ＲＴＰ、およびＲＴＣＰソケットをＮ組用意しておき、不足してきたらさらにＮ組追加して用意する、などの管理が必要となる。
【００７４】
これまでに述べたＮＡＴ越えの例では、図１０ではハンドオーバサーバ９００におけるＮＡＴ処理用ポート番号とＳＩＰ用ポート番号とは異なっていた。同様に、図１１、図１２における、ＮＡＴ処理用ポート番号とＲＴＰ、及びＲＴＣＰ用ポート番号とはそれぞれ異なっていた。すなわち図１０〜図１３では、ハンドオーバサーバ９００からＮＡＴ９０１へパケットを送信する際、発信元ポート番号に関係なく、ＮＡＴ９０１で変換されるハンドオーバ端末９０２の宛先ポート番号は同じ値となることを想定していた。
【００７５】
しかしながら、ＮＡＴの種類によっては、上記のような想定が成り立たない場合がある。この例としては、対称型ＮＡＴやポート制限付きコーン型ＮＡＴなどが挙げられる。これらのＮＡＴでは、プライベート網内部ホストがグローバル網へパケット送信したＩＰアドレスとポートアドレスの外部ホストのみが内部ホストへ通信することができるように制限が加えられる。
【００７６】
すなわち、図１２の例では、ハンドオーバサーバ９００から送信されるＮＡＴ９０１へ送信されるメッセージＭ１１０１の発信元ポート番号はＮＡＴ処理用ポート番号（＃Ｐ１）であり、Ｍ１１０１の宛先ポート番号（＃Ｐ２）はＮＡＴ９０１によりハンドオーバ端末９０２のＲＴＰ用ポート番号（＃Ｐ３）へ変換される。
【００７７】
このとき、図１２のＮＡＴ越えの場合、ハンドオーバサーバ９００では、ポート番号（＃Ｐ２）と異なるＲＴＰ用ポート番号（＃Ｐ４）を発信元ポート番号として、ＮＡＴ９０１へパケットを送信しても、ポート番号（＃Ｐ３）へ変換される。しかし、対称型ＮＡＴでは、前記ＲＴＰ用ポート番号へ変換されるには、ハンドオーバサーバ９００から送られるパケットの発信元ポート番号が、ポート番号（＃Ｐ２）である必要がある。
【００７８】
このため図１２の場合、上記対称型ＮＡＴを想定したＮＡＴ越えを行うためには、次のことが必要となる。すなわち、ハンドオーバ端末９０２からＲＴＰパケットを受信するときのグローバルアドレスを要求するときの宛先ポート番号が、ハンドオーバサーバ９００が実際にＲＴＰパケットを送信するときの発信元ポート番号（＃Ｐ４）である必要がある。
【００７９】
以下、図１３から図１６を用いて、対称型ＮＡＴを想定したＮＡＴ越えの処理の流れについて説明する。
【００８０】
図１３を用いて、ＳＩＰ通信のＮＡＴ越えの処理を説明する。図１０との違いは、ハンドオーバ端末９０２から送信されるグローバルアドレス要求メッセージ（Ｍ１０００）の宛先ポート番号が、ハンドオーバサーバ９００において予め定められたＳＩＰ処理用ポート番号となっている点である。ハンドオーバサーバ９００では、このポート番号を指定されたＳＩＰ用ソケットを予め作成しておき（１００２）、このＳＩＰ用ソケットを用いて（すなわち、ＳＩＰ処理用ポート番号を発信元ポート番号として）グローバルアドレス返送メッセージ（Ｍ１００１）を送信する。
【００８１】
これにより、対称型ＮＡＴ（１３０１）において、Ｍ１００１は正しく、ハンドオーバ端末９０２のＳＩＰ用ポート番号へ変換される。以降のホールパンチングのパケット送信（Ｄ１００２）は、図１０と同様である。よって、図１３の構成の場合、ハンドオーバサーバ９００において、ＳＩＰ用ソケットにより受信するデータには、ＳＩＰメッセージのみならず、ＳＩＰメッセージに先立ったグローバルアドレス要求メッセージ（Ｍ１１００）が含まれることになる。よってハンドオーバサーバ９００では、上記２種類のメッセージを区別する必要がある。
【００８２】
図１４を用いて、ハンドオーバ端末９０２発呼時の、対称型ＮＡＴ越えの処理について説明する。図１１との違いは、一つには、ハンドオーバ端末９０２がグローバルアドレスを要求する（Ｍ１１００）よりも先立ち、ハンドオーバサーバ９００におけるＲＴＰ／ＲＴＣＰ用ポート番号が予め設定され、ハンドオーバ端末９０２に対して既知となっていることと、そのポート番号が指定されたＲＴＰ送信用ソケット、およびＲＴＣＰ送信用ソケットが予め作成されていること（１１０３）である。そしてもう一つは、ハンドオーバ端末９０２が送信するグローバルアドレス要求メッセージＭ１１００の宛先ポート番号、ハンドオーバサーバ９００が送信するグローバルアドレス返送メッセージＭ１１０１の発信元ポート番号が、ハンドオーバサーバ９００におけるＲＴＰ、およびＲＴＣＰ送信用ポート番号であることである。
【００８３】
これらにより、ＲＴＰ、およびＲＴＣＰ送信用ソケットから送信されるパケットは、対称型ＮＡＴ１３０１により、ハンドオーバ端末９０２のＲＴＰ受信用ポート番号、およびＲＴＣＰ受信用ポート番号とへそれぞれ変換され、ＮＡＴ越えが実現される。以降の処理は図１１で述べた処理と同様である。ハンドオーバサーバ９００は、ＲＴＰ用ソケット、およびＲＴＣＰ用ソケットにより受信するデータには、それぞれＲＴＰパケット、ＲＴＣＰパケットのみならず、グローバルアドレス要求メッセージ（Ｍ１１００）が含まれているため、これらを区別して処理できる必要がある。
【００８４】
図１５は、図１４で述べた端末側発呼時の対称型ＮＡＴ越え処理の変形例である。図１５では、図１４と異なり、ハンドオーバサーバ９００において予め設定されたＲＴＰ、およびＲＴＣＰ送信用ポート番号がハンドオーバ端末９０２に対して知らされていない、もしくは動的に設定されるケースを想定している。この場合、図１５では、ハンドオーバ端末９０２が、ハンドオーバサーバ９００に対し、ＲＴＰ、およびＲＴＣＰポート番号を要求し（Ｍ１５００）、これらのＲＴＰ、ＲＴＣＰポート番号をそれぞれ返送する（Ｍ１５０１）処理を行う。メッセージＭ１５００の宛先ポート番号、およびメッセージＭ１５０１の発信元ポート番号は、ＮＡＴ処理用に予めハンドオーバサーバ、端末間で定められたポート番号とする。その後は図１４と同様に、このＲＴＰ、ＲＴＣＰポート番号に対してそれぞれグローバルアドレス要求メッセージ（Ｍ１１００）を送信する。以降の処理は図１４で述べた処理と同様である。
【００８５】
図１６は、端末側着呼時の対称型ＮＡＴ越えの処理例を示した図である。図１２との違いは、ハンドオーバ端末９０２から送信されるグローバルアドレス要求メッセージ（Ｍ１１００）の宛先ポート番号と、ハンドオーバサーバ９００から送信されるグローバルアドレス返送メッセージ（Ｍ１１０１）の発信元ポート番号とが、ハンドオーバサーバ９００におけるＲＴＰ用、およびＲＴＣＰ用ポート番号となっている点である。
【００８６】
これにより、ハンドオーバサーバ９００から送信されるＲＴＰ、およびＲＴＣＰパケットの宛先ポート番号が、対称型ＮＡＴ１３０１においてハンドオーバ端末９０２のＲＴＰ用ポート番号、およびＲＴＣＰ用ポート番号にそれぞれ変換され、ハンドオーバ端末９０２へ送信される。なお、図１６では、ハンドオーバサーバ９００におけるＲＴＰ、およびＲＴＣＰ用ポート番号が、ハンドオーバ端末９０２において既知であることを前提としている。もしも、これらがハンドオーバ端末９０２で既知でない場合には、図１５で述べた方法と同様に、ハンドオーバサーバ９００におけるＲＴＰ、およびＲＴＣＰポート番号を取得するためのメッセージ交換（Ｍ１５００、Ｍ１５０１）を予め行うことにより、ハンドオーバ端末９０２は、ＲＴＰ及びＲＴＣＰポート番号を取得することが可能となる。
【００８７】
以上、図１０から図１６を用いて、通常（非制限な）ＮＡＴ、および対称型ＮＡＴのＮＡＴ越えの処理について、ＵＤＰホールパンチングを例として説明したが、本発明ではＮＡＴ越えの手法として必ずしもＵＤＰホールパンチングに限定されるものではない。例えば、プライベート通信網とグローバル通信網の間のルータが、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）に対応するルータであれば、ＵＰｎＰを利用し、ハンドオーバ端末がＮＡＴに対してポートマッピングの設定をＮＡＴに対して行う。これにより、ＮＡＴでマッピングされるグローバルアドレスを取得し、このグローバルアドレスをハンドオーバサーバへ送信することで、上記と同様にＮＡＴ越えを実現することが可能である。
【実施例７】
【００８８】
本発明の実施形態７は、実施形態１の電話ハンドオーバシステムにおけるハンドオーバ端末において、シームレスなハンドオーバが実現できない場合に、聴覚上の音声品質劣化の修正処理（以下、隠蔽処理とも呼ぶ）を行うハンドオーバシステムである。
【００８９】
図１８に、本発明の実施形態７のハンドオーバ端末の構成を示す。同図におけるエラー修正部（隠蔽部）１８０２が、実施形態１に新たに追加された部分であり、他は実施形態１と同様である。デコーダ１８０１は、通話データＤ１０３ａ（音声フレームデータ）を、音声のデータレートに従って取得し、これをデコードし、サンプルデータ（音声波形データ）を生成する。従って、デコーダ１８０１に渡される通話データＤ１０３ａに、通信時のパケットロス等により、時間的な不連続（相違）が生じていたとしても、再生時刻に関係なく、連続してエラー隠蔽部１８０２へ、Ｄ１８１０として渡される。なお、このＤ１８１０には、音声サンプルデータに加え、そのサンプルデータの再生時刻情報も含まれる。エラー隠蔽部１８０２は、デコーダ１８０１が出力するサンプルデータに対して処理を加え、サンプルデータＤ１８１１として再生バッファへ渡す。
【００９０】
シームレスハンドオーバが失敗する場合とは、ハンドオーバ制御部１８０５により、ハンドオーバする時刻において、デコーダ１８０１へ渡される通話データＤ１０３ａが、バッファ３０１とバッファ３０２の間で切り替わるときに、再生時刻に不連続な部分があるときに生じる。
【００９１】
図１９および図２０を用いて、ハンドオーバ時に不連続が生じる場合のエラー隠蔽部１８０２における処理について説明する。
【００９２】
図１９は、バッファ３０１から、バッファ３０２へハンドオーバする際、バッファ３０１における通話データの再生時刻が、バッファ３０２におけるそれよりも遅れている場合の処理を示している。この場合、同図に示すように、各音声フレームに対応する音声波形は、時間的に間隙が生じたものとなる。この場合のエラー隠蔽部１８０２における処理としては、例えば下記のような処理のいずれかを行う。
（１）不連続なデータを詰める：再生時刻がスキップするという問題はあるが簡易かつ一瞬でデータの切替が終了する。
（２）無音状態とする：簡易かつ、再生時刻がスキップしないという利点はあるが、無音部分による聴覚的な劣化は大きい。
（３）ノイズや別の音で置換する：（２）に比べ、ノイズ音を間隙部に挿入することで、聴覚的な劣化が軽減できる。ノイズとしては、前フレームデータと同じ振幅の白色雑音ノイズなどが挙げられる。また、不連続な時間が長い場合には、ノイズではなく、メロディ音やメッセージなどの音声により、間隙部分を置換することで、ユーザの不快感を軽減することが可能である。
（４）前後の音声で置換する：欠落部分の前後の波形をそのまま置換することで、間隙全体を覆う。また両端からの波形の境界部分については平均値を取ることも可能である。不連続な時間が比較的短い場合には、前後の音で置換するだけでも聴覚的な劣化を避けられる場合がある。
（５）前後の音を伸張する：欠落部分の前後の波形を引き伸ばすことで、間隙全体を覆う。例えば、欠落部分の両端から欠落部分をカバーするようにピッチ周期を伸ばし、両端からの波形がぶつかる部分については平均値を取る、などの方法がある（これの詳細については、「H.Sanneck, A. Stenger, K.B.Younes, and B.Girod. 鄭 New Technique for Audio Packet Loss Concealment,  IEEE Global Internet Symposium, London, December 1996.」を参照）。
【００９３】
図２０は、バッファ３０１から、バッファ３０２へハンドオーバする際、バッファ３０１における通話データの再生時刻が、バッファ３０２におけるそれよりも進んでいる場合の処理を示している。この場合、同図に示すように、各音声フレームに対応する音声波形は、時間的に逆転が生じたものとなる。この場合のエラー隠蔽部１８０２における処理としては、例えば下記のような処理のいずれかを行うことができる。
（１）不連続なデータを詰める：過去に再生済みのデータが再生されるという問題はあるが、簡易かつ一瞬でデータの切替が終了する。
（２）次の時刻のデータを受信するまで無音状態とする：簡易かつ、再生時刻がスキップしないという利点はあるが、無音部分による聴覚的な劣化は大きい。
（３）次の時刻のデータを受信するまで、ノイズや別の音で置換する：（２）に比べ、ノイズ音を間隙部に挿入することで、聴覚的な劣化が軽減できる。ノイズとしては、前フレームデータと同じ振幅の白色雑音ノイズなどが挙げられる。また、不連続な時間が長い場合には、ノイズではなく、メロディ音やメッセージなどの音声により、間隙部分を置換することで、ユーザの不快感を軽減することが可能である。
（４）次の時刻のデータが来るまで前の音声で置換する：欠落部分の前の波形をそのまま繰り返し置換することで、間隙全体を覆う。また両端からの波形の境界部分については平均値を取ることも可能である。不連続な時間が比較的短い場合には、前後の音で置換するだけでも聴覚的な劣化を避けられる場合があるが、長い場合には、聴覚的な品質劣化は大きい。
（５）次の時刻のデータが来るまで前の音を伸張する：欠落部分の前後の波形を引き伸ばすことで、間隙全体を覆う。例えば、欠落部分の前後から予め決めた割合で欠落部分をカバーするようにピッチ周期を伸ばす。次のデータの到着が遅いために、欠落部分をカバーできなかった場合は無音にするか、ゆるやかにフェードアウトするかなどを行ってもよい。
【実施例８】
【００９４】
本発明の実施形態８は、実施形態１の電話ハンドオーバシステムにおけるハンドオーバ端末において、端末の位置情報を外部から取得することにより、ハンドオーバを決定するハンドオーバシステムである。
【００９５】
図２２に、本発明の実施形態８に係るハンドオーバ端末１０５の構成を示す。実施形態８では、ハンドオーバ端末へ位置情報を提供するロケーションサーバ２２０１が通信網＃３に接続されていることを前提とする。ただし、ロケーションサーバ２２０１が接続している通信網は、必ずしも通信網＃３である必要はなく、何らかの通信網を経由してハンドオーバ端末１０５から接続できればよい。以下、図２２を用いてハンドオーバ端末１０５が位置情報を取得してハンドオーバを決定する流れについて説明する。
【００９６】
位置情報の取得処理は、ハンドオーバ端末１０５におけるハンドオーバ処理部１１１内の位置情報取得部２２０２にて行われる。位置情報取得部２２０２は、定期的にロケーションサーバ２２０１とメッセージ交換（Ｍ２２１０、Ｍ２２１１）を行い、最終的に位置情報を取得する。
このロケーションサーバと位置情報取得部２２０２との間のメッセージ交換の方法や測位方法は、本発明においては特に限定されるものではない。位置情報はロケーションサーバから渡されてもよいし、端末側でロケーションサーバからの情報を元に計算するものであってもよい。また測位方法も、ＧＰＳ衛星を用いた方法や、基地局を衛星に見立てて位置情報を特定する方式や、複数の基地局間の伝送速度や遅延、電波強度などの情報から即位を行う方式などでもよい。
【００９７】
位置情報取得部２２０２は、何らかの方式により端末の位置情報を取得した後、この位置情報を含むメッセージＭ２２１２をマッピング情報管理部２２０３へ渡す。マッピング情報管理部２２０３は、メッセージＭ２２１２内の位置情報を受け取ると、その位置情報が示す位置では、通信網＃２と通信網＃３のどちらを利用するかを判定する。この判定を行うための、位置情報と通信網の選択のマッピング情報は、何らかの方法で予め端末に設定されていることとする。
【００９８】
マッピング情報管理部２２０３は、この判定結果（すなわち端末がどちらの通信網を利用するか）を含むメッセージＭ２２１３を位置情報取得部２２０２へ渡す。このメッセージＭ２２１３は、位置情報取得部２２０２からハンドオーバ制御部１８０５へ渡される。ハンドオーバ制御部２２１３は、現在、通信網＃２と通信網＃３のどちらで通話が行われているかを常に把握している。ハンドオーバ制御部２２１３で、現在通信中の通信網と、メッセージＭ２２１３により送られる通信網とが異なる場合には、ハンドオーバを決定（図２中の２０１）する。ハンドオーバ決定以降の処理は図２で示した流れと同様である。
【００９９】
このように、本実施形態にかかる電話ハンドオーバシステムによれば、通信の途中であっても、映像も含む電話サービスなどの双方向性通信サービスであっても、一時的に映像や音が中断することが防止される。よって、このような中断がなく通信網を切替えることが可能となり、ユーザは中断による不利益を受けずに上記通信サービスを継続することが可能である。
【０１００】
また本実施形態では、それぞれのセッションにてコーデックやビットレートを変更させることができるので、それぞれの通信網における現在のスループットに応じたビットレートでの通話を適時実現することが可能である。
【０１０１】
また本実施形態では、ルータを介したプライベートな通信網とグローバルな通信網との間においても、通話の継続が可能である。
【０１０２】
また本発明では、通信網の遅延等により切替前後の通話が不連続な場合であっても、隠蔽処理を行うことで通話切替の際の音声の主観的劣化を軽減できる。
【０１０３】
以上に述べたように本発明によれば、特性が異なる複数の通信網や、通信速度の変動が激しい通信網においても、リアルタイム性の要求の高い双方向性通信サービスを、一時的な中断なく継続的に提供することが可能である。従って現在広く普及している携帯端末を利用することで、ユーザに対して利便性の高いサービスを提供することが可能である。
【図面の簡単な説明】
【０１０４】
【図１】本発明の実施形態１による電話ハンドオーバシステムの構成例を示すブロック図
【図２】本発明の実施形態１による電話ハンドオーバシステムの処理フローの例を示す図
【図３】本発明の実施形態１による電話ハンドオーバシステムのハンドオーバ端末におけるハンドオーバ処理部の構成例を示す図
【図４】本発明の実施形態１による電話ハンドオーバシステムのハンドオーバサーバにおけるハンドオーバ処理部の構成例を示す図
【図５】本発明の実施形態５による電話ハンドオーバシステムの、ハンドオーバ失敗時における処理フローの第一の例を示す図
【図６】本発明の実施形態５による電話ハンドオーバシステムの、ハンドオーバ失敗時における処理フローの第二の例を示す図
【図７】本発明の実施形態５による電話ハンドオーバシステムの、ハンドオーバ失敗時における処理フローの第三の例を示す図
【図８】本発明の実施形態５による電話ハンドオーバシステムの、ハンドオーバ失敗時における処理フローの第四の例を示す図
【図９】本発明の実施形態６による電話ハンドオーバシステムの構成例を示す図
【図１０】本発明の実施形態６による電話ハンドオーバシステムの、ＳＩＰメッセージのＮＡＴ越えを行う処理シーケンスの例を示す図
【図１１】本発明の実施形態６による電話ハンドオーバシステムの、ハンドオーバ端末側発呼における音声通話のＮＡＴ越えを行う処理シーケンスの例を示す図
【図１２】本発明の実施形態６による電話ハンドオーバシステムの、ハンドオーバ端末側着呼における音声通話のＮＡＴ越えを行う処理シーケンスの例を示す図
【図１３】本発明の実施形態６による電話ハンドオーバシステムの、ＳＩＰメッセージのシンメトリックＮＡＴ越えを行う処理シーケンスの例を示す図
【図１４】本発明の実施形態６による電話ハンドオーバシステムの、ハンドオーバ端末側発呼における音声通話のシンメトリックＮＡＴ越えを行う処理シーケンスの第一の例を示す図
【図１５】本発明の実施形態６による電話ハンドオーバシステムの、ハンドオーバ端末側発呼における音声通話のシンメトリックＮＡＴ越えを行う処理シーケンスの第二の例を示す図
【図１６】本発明の実施形態６による電話ハンドオーバシステムの、ハンドオーバ端末側着呼における音声通話のシンメトリックＮＡＴ越えを行う処理シーケンスの例を示す図
【図１７】本発明の実施形態６による電話ハンドオーバシステムの、予め音声通話用グローバルアドレスを取得する処理シーケンスの例を示す図
【図１８】本発明の実施形態７によるハンドオーバ端末の構成例を示す図
【図１９】本発明の実施形態７によるハンドオーバ端末におけるエラー隠蔽処理における動作の第一の例を示す図
【図２０】本発明の実施形態７によるハンドオーバ端末におけるエラー隠蔽処理における動作の第二の例を示す図
【図２１】本発明の実施形態におけるＳＤＰメッセージの例を示す図
【図２２】本発明の実施形態８による位置情報取得処理のための構成例
【符号の説明】
【０１０５】
１００、９００…電話ハンドオーバサーバ
１０１…ハンドオーバ処理部（サーバ）
１０２…通話処理部(サーバ)
１０３…通信網インタフェース部（サーバ）
１０４…電話端末
１０５、９０２…ハンドオーバ端末
１０６、１０７、１０８…通信網
１０９…通信網インタフェース部（端末）
１１０…通信処理部（端末）
１１１…ハンドオーバ処理部（端末）
１１２…音声処理部（端末）
９０１…ＮＡＴ
１３０１…シンメトリックＮＡＴ
２２０１…ロケーションサーバ
【図１】
2007142786.tif 000003
【図２】
2007142786.tif 000004
【図３】
2007142786.tif 000005
【図４】
2007142786.tif 000006
【図５】
2007142786.tif 000007
【図６】
2007142786.tif 000008
【図７】
2007142786.tif 000009
【図８】
2007142786.tif 000010
【図９】
2007142786.tif 000011
【図１０】
2007142786.tif 000012
【図１１】
2007142786.tif 000013
【図１２】
2007142786.tif 000014
【図１３】
2007142786.tif 000015
【図１４】
2007142786.tif 000016
【図１５】
2007142786.tif 000017
【図１６】
2007142786.tif 000018
【図１７】
2007142786.tif 000019
【図１８】
2007142786.tif 000020
【図１９】
2007142786.tif 000021
【図２０】
2007142786.tif 000022
【図２１】
2007142786.tif 000023
【図２２】
2007142786.tif 000024