JP5182297B2 - 通信中継方法、通信中継プログラムおよび通信中継装置 - Google Patents

Description

本発明は、第１の音声通話装置と第２の音声通話装置との間の通信を中継する通信中継方法、通信中継プログラムおよび通信中継装置に関するものである。

ＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ：公衆電話回線網）やＩＰ網などのネットワークに接続された各種情報機器、たとえばＰＣ、ＰＤＡ、固定電話、携帯電話、ＰＨＳなどを一人のユーザが複数台所有して、仕事の状況や通信環境などに応じて使い分けることはもはや当たり前の時代となっている。ただ、いつでもどこでも仕事ができるということは、その反面、いつどこで仕事をしているか分からないということでもあり、たとえばあるユーザと今すぐ話がしたいとき、どの機器をどう呼び出せば最もスムーズに連絡がつくか分からないという問題がある。

そこで本出願人は、ユーザが使用する複数の機器のいずれかにかかってきた電話を、「呼転送サーバ」（具体的にはＳＩＰサーバを想定）の転送先選択機能により、その時点で最適な機器に転送する「ユビキタスＩＰ電話システム」を提案している（特許文献１）。上記システムにおいては、ユーザの現在位置や事前に設定されたプリファレンスにもとづいて電話の転送先が決定されるので、たとえば同一の電話番号にかかってきた電話でも、ユーザが在席中であればその自席の内線電話、外出中であれば携帯電話というように、実際に呼び出される機器はその時々で変化することになる。

一方、本出願人は複数の無線通信装置、たとえばＰＨＳのほかＷＬＡＮもあわせて搭載する携帯電話型のデュアル端末を提案している（特許文献２）。そしてこの端末では、
・ＷＬＡＮの圏内にあるときは、ＷＬＡＮでＩＰ網に接続（基本的には無料）
・ＷＬＡＮの圏外にあるときは、ＰＨＳでＰＳＴＮに接続（基本的には有料）
というように、通信環境などに応じて使用する通信装置や接続するネットワークを切り換えることで、通信コストを抑制することができる。

しかしながら図２０に示すように、上記「ユビキタスＩＰ電話システム」において、着信端末２００２が特に上記デュアル端末であった場合には、発信端末２００１がＰＳＴＮを経由しないで電話をかけた場合でも、着信端末２００２へは破線矢印ではなく、実線矢印すなわちＰＳＴＮ経由で接続されてしまう。そして、破線矢印の場合は通話料が発生しないのに対して、実線矢印の場合は、
・Ｓ−Ｐ（ＳＩＰ→ＰＳＴＮ）ゲートウェイ２００４〜着信端末２００２間の通話料
が発呼者に発生してしまう。

これは省電力の観点から、上記デュアル端末はＰＨＳが使える限りはもっぱらＰＨＳで待ち受けを行い、ＷＬＡＮにはできるだけ電力を供給しないようにしているためである。すなわち上記端末は、ＰＨＳ圏内でさえあれば、ＷＬＡＮの圏内か圏外かにかかわらずＷＬＡＮをＯＦＦにしている。言い換えると上記端末は、デュアル端末とはいうものの、ＰＨＳ圏内での待ち受け時には実質的にＰＨＳ相当となっている。このためこれをＩＰ網から呼び出すには、まずそのＷＬＡＮをＯＮにしてＩＰ網に接続させ、さらにＳＩＰサーバ２０００に必要事項（ＩＰアドレスなど）を登録させるためのしくみが必要である。

ちなみにこのしくみの一例としては、「株式会社インターナショナルシステムリサーチ」の「ＰＰＰｈｏｎｅ」システム（さらに詳細には、当該システムで採用されているＷａｋｅＯｎＲｉｎｇテクノロジ「ＰＰＰｕｓｈ」）がある。これは電源ＯＦＦの状態にあるＰＤＡが、「ＷａｋｅＯｎトリガー」と呼ばれる本体起動用のメッセージをＰＨＳで受信すると、自己の電源をＯＮにするとともにＷＬＡＮでＩＰ網に接続し、ＳＩＰサーバへ必要事項を登録するものである。

また、たとえば図２１の実線矢印で示すように、発呼者が発信端末２００１からＰＳＴＮ経由でＩＰ電話をかけ、その電話がＰ−Ｓ（ＰＳＴＮ→ＳＩＰ）ゲートウェイ２００３およびＳＩＰサーバ２０００を経て、さらにＰＳＴＮ経由で着信端末２００２に転送された場合、
・発信端末２００１〜Ｐ−Ｓゲートウェイ２００３間の通話料
・Ｓ−Ｐゲートウェイ２００４〜着信端末２００２間の通話料
の両者が発呼者に発生してしまう（二重課金）。この場合は結果的に、図中実線矢印の経路でＩＰ電話をかけるより、破線矢印の経路で普通に電話をかけたほうが安価だったことになり、上記システムを利用するメリットが減殺されてしまう。なお、この問題は発信端末２００１や着信端末２００２がデュアル端末でなくとも、双方ともにＰＳＴＮを利用する機器である場合に発生する。

特開２００５−２６９２９９号公報 特開２００６−２５００９号公報

まとめると、上記従来技術においては、本来負担しなくてもよいはずの通話料を発呼者が負担しなければならない場合があった。具体的には、
（１）ユビキタスＩＰ電話システムをＩＰ網経由で利用した場合、当該システムが着呼者をＰＳＴＮ経由で呼び出したことが原因で、ＩＰ網経由で呼び出せば無料だったはずの通話に料金がかかってしまう
（２）ユビキタスＩＰ電話システムをＰＳＴＮ経由で利用した場合、当該システムが着呼者をＰＳＴＮ経由で呼び出したことが原因で、当該システムを介さず直接ＰＳＴＮ経由で呼び出すのに比べて余分に料金がかかってしまう
などである。

本発明は、上記に鑑みてなされたものであって、発信端末〜着信端末間の通信を相対的に最も安価な経路で中継することが可能な通信中継方法、通信中継プログラム、および通信中継装置を提供することを目的とする。

上述した課題を解決し、目的を達成するために、第１の発明の通信中継方法、通信中継プログラムおよび通信中継装置は、第１の音声通話装置と複数のネットワークに接続可能な第２の音声通話装置との間の通信を中継する処理をサーバが実行する通信中継方法、通信中継プログラムおよび通信中継装置であって、前記ネットワークのうち第１のネットワークを通じて前記第１の音声通話装置から前記サーバが受信した、前記第１の音声通話装置と前記第２の音声通話装置との接続要求を、前記ネットワークのうち第２のネットワークを通じて、前記サーバが前記第２の音声通話装置に転送し、前記第２のネットワークで前記接続要求から変換された呼が前記第２の音声通話装置に転送された結果、前記第２の音声通話装置から、前記第１のネットワークを通じて、前記第１のネットワークで着信可能であることを示す通知を、前記サーバが受信し、前記通知を受信した場合に、前記サーバが、前記接続要求を前記第１のネットワークを通じて前記第２の音声通話装置に送信し、前記接続要求を前記第１のネットワークを通じて前記第２の音声通話装置に送信した結果、前記第２の音声通話装置から前記サーバが受信した、前記接続要求に対する応答を、前記サーバが、前記第１のネットワークを通じて前記第１の音声通話装置に転送することを要件とする。

上記発明（後述する「繋ぎ直し方式」）によれば、発信端末〜着信端末間に相対的に高価な通信経路Ａと安価な通信経路Ｂとがある場合、発信端末からのＡ経由の接続要求はＢ経由となるようその経路を変更される。

本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置は、発信端末〜着信端末間の通信を相対的に最も安価な経路で中継することができるという効果を奏する。

本発明の実施例１にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。 本発明の実施例１にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。 本発明の実施例１にかかる通信中継装置のハードウェア構成を示す説明図である。 本発明の実施例１にかかる通信中継装置の機能的構成を示す説明図である。 本発明の実施例１にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。 本発明の実施例１にかかる着信端末１０２における、着信処理の手順を示すフローチャートである。 本発明の実施例２にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。 本発明の実施例２にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。 本発明の実施例２にかかる通信中継装置の機能的構成を示す説明図である。 本発明の実施例２にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。 本発明の実施例２にかかる着信端末７０２における、着信処理の手順を示すフローチャートである。 本発明の実施例３にかかる通信中継装置により実現される、「繋ぎ直し＋かけ直し方式」の概略を示す説明図である。 本発明の実施例３にかかる通信中継装置により実現される、「繋ぎ直し＋かけ直し方式」の概略を示す説明図である。 本発明の実施例３にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。 本発明の実施例３にかかる着信端末１２０２における、着信処理の手順を示すフローチャートである。 本発明の実施例３にかかる発信端末１２０１における、発信処理の手順を示すフローチャートである。 本発明の実施例４にかかる通信中継装置により実現される、「かけ直し方式」の概略を示す説明図である。 本発明の実施例４にかかる通信中継装置の機能的構成を示す説明図である。 本発明の実施例４にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。 従来技術の問題点を示す説明図である。 従来技術の他の問題点を示す説明図である。

以下に、本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

本発明では上述した従来技術の問題点（１）（２）を解決するため、
・実施例１：コールバック方式・・・・・・問題点（１）を解決
・実施例２：繋ぎ直し方式・・・・・・・・問題点（１）を解決
・実施例３：繋ぎ直し＋かけ直し方式・・・問題点（２）を解決
・実施例４：かけ直し方式・・・・・・・・問題点（２）を解決
の４方式を提案する。以下、順次説明する。

（コールバック方式）
図１および図２は、本発明の実施例１にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。発信端末１０１はＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）によるＶｏＩＰ通話の可能な機器なら何であってもよいが、ここではたとえばＶｏＩＰアダプタを介してＩＰ網に接続された電話機（ＩＰ電話）であるものとする。発呼者がこの発信端末１０１から、あらかじめ着呼者ごとに付与されている代表番号、たとえば「０５０−ＸＸＸＸ−ＸＸＸＸ」へ電話をかけると、当該番号を意味するＳＩＰ ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）、たとえば「ｓｉｐ：＋８１−０５０−ＸＸＸＸ−ＸＸＸＸ＠・・・」を宛先とするＩＮＶＩＴＥリクエストが、ＩＰ網を経てＳＩＰサーバ１００へ送信される（図中（１））。なお、以下では上記ＵＲＩを「バーチャルＵＲＩ」と呼ぶ。

ＳＩＰサーバ１００は上述の転送先選択機能を備えており、着呼者のバーチャルＵＲＩあてのＩＮＶＩＴＥリクエストを、当該着呼者の現実のＳＩＰ ＵＲＩ（少なくとも一つ）のうちいずれか一つに転送する。なお、以下では上記現実のＳＩＰ ＵＲＩを「着信端末ＵＲＩ」と呼び、そのうち転送先として選択された一つを特に「選択中ＵＲＩ」と呼ぶ。なお、バーチャルＵＲＩと着信端末ＵＲＩとの対応関係、および着信端末ＵＲＩのうちどれが選択中ＵＲＩであるかは、ＳＩＰサーバ１００の「転送先テーブル」に保持されている。図中、「＊」印の付加された着信端末ＵＲＩが選択中ＵＲＩである。

そして発信端末１０１からのＩＮＶＩＴＥリクエストは、ＳＩＰサーバ１００でその宛先をバーチャルＵＲＩから選択中ＵＲＩに付け替えられた後、選択中ＵＲＩにより一意に特定される着信端末１０２へ転送される。ただし、選択中ＵＲＩがＰＳＴＮ上の識別子（具体的には電話番号）を意味するＳＩＰ ＵＲＩ、たとえば「ｔｅｌ：＋８１−０７０−ＸＸＸＸ−ＸＸＸＸ」であった場合は、上記リクエストはまずＳ−Ｐゲートウェイ１０４に転送（図中（２））されてＰＳＴＮの呼に変換の上、ＰＳＴＮ経由で着信端末１０２に転送（図中（３））される。このため上述のように、本来なら通話料が発生しない状況、具体的にはデュアル端末である着信端末１０２がＷＬＡＮ圏内にあるときでも、Ｓ−Ｐゲートウェイ１０４〜着信端末１０２間の通話料が発生してしまう。

ここで、選択中ＵＲＩは（ａ）相対的に高価な（通信コストの高い）ネットワークにも安価な（通信コストの低い）ネットワークにも接続可能な機器に対応するＳＩＰ ＵＲＩのうち、前者における識別子を意味するＳＩＰ ＵＲＩである場合と、（ｂ）上記以外のＳＩＰ ＵＲＩである場合とがある。たとえば、ＰＳＴＮにもＩＰ網にも接続可能なデュアル端末のＰＨＳ番号を意味するＳＩＰ ＵＲＩは（ａ）であり、一般のＰＨＳのＰＨＳ番号を意味するＳＩＰ ＵＲＩは（ｂ）である。別の言い方をすると、ＰＨＳ番号を意味するＳＩＰ ＵＲＩは、上記番号がデュアル端末のＰＨＳ番号であれば（ａ）、一般のＰＨＳのＰＨＳ番号であれば（ｂ）に該当することになる。なお、以下では（ｂ）に該当するＳＩＰ ＵＲＩの種別を「通常」と呼ぶ。

そして、発呼者が本来負担しなくてもよいはずの通話料（具体的にはＳ−Ｐゲートウェイ１０４〜着信端末１０２間の通話料）を負担しなければならなくなるのは、選択中ＵＲＩが特に（ａ）だった場合、すなわちその種別が「通常」ではなかった場合である。そこで実施例１では、選択中ＵＲＩの種別が「通常」でない場合は、ＳＩＰサーバ１００からＳ−Ｐゲートウェイ１０４へＩＮＶＩＴＥリクエストを転送した直後に、ＣＡＮＣＥＬリクエストを送信する（図中（２））ことで、Ｓ−Ｐゲートウェイ１０４から着信端末１０２への呼を通話料の発生前（具体的にはワンコール程度）で切断してしまう（図中（３））。

また、ＳＩＰサーバ１００は発信端末１０１からのＩＮＶＩＴＥリクエストを、Ｓ−Ｐゲートウェイ１０４とともにアナウンスサービス１０５へも転送し（図中（４））、アナウンスサービス１０５から発信端末１０１への２ＸＸ応答（成功）と、発信端末１０１からアナウンスサービス１０５へのＡＣＫリクエストとを順次転送する。これにより、発信端末１０１〜アナウンスサービス１０５間でＲＴＰコネクションが確立されると、アナウンスサービス１０５から発呼者へ、着呼者からコールバックするのでいったん電話を切って待つよう指示がなされ、発信端末１０１からアナウンスサービス１０５へＢＹＥリクエストが送信（図中（５））された時点で、発信端末１０１からの電話は切断される。

一方、Ｓ−Ｐゲートウェイ１０４からいわゆる「ワン切り」された着信端末１０２は、ＷＬＡＮでＩＰ網に接続、あるいはＰＨＳでＰＳＴＮに接続してただちにコールバックする。もっとも、着信端末１０２ではコールバック先となるべき発信端末１０１を特定できないので（着信履歴には発信端末１０１ではなく、Ｓ−Ｐゲートウェイ１０４の電話番号しか残らないため）、実施例１ではＳＩＰサーバ１００の「転送元テーブル」に、着信端末１０２とコールバック先となる発信端末１０１との対応関係を保持しておくようにする。

すなわちＳＩＰサーバ１００は、発信端末１０１から受信したＩＮＶＩＴＥリクエストをＳ−Ｐゲートウェイ１０４およびアナウンスサービス１０５に転送する際に、当該リクエストのＴｏヘッダに記述されたバーチャルＵＲＩ（図中（１）の「Ｒｅｃｅｉｖｅｒ Ｖｉｒｔｕａｌ」）と、Ｆｒｏｍヘッダに記述された発信端末１０１のＵＲＩ（発信端末ＵＲＩ。同「Ｃａｌｌｅｒ ＶｏＩＰ」）との組を、その保持する「転送元テーブル」に登録する。

その後図１のように、着信端末１０２がＷＬＡＮでＩＰ網に接続してＳ−Ｐゲートウェイ１０４へコールバックした場合、着信端末１０２からのＩＮＶＩＴＥリクエストは、その宛先であるＳ−Ｐゲートウェイ１０４を通過してＳＩＰサーバ１００に転送される（図１（６））。

したがって図１の場合、ＳＩＰサーバ１００が受信するＩＮＶＩＴＥリクエストには、（ａ）通常のＩＮＶＩＴＥリクエスト（図中（１）など）と、（ｂ）過去の電話をトリガーとするＩＮＶＩＴＥリクエスト（図中（６）など）との２種類があることになる。なお、以下では（ａ）に該当するＩＮＶＩＴＥリクエストの種別を「通常」、（ｂ）に該当するＩＮＶＩＴＥリクエストの種別を「コールバック」と呼ぶ。そして、あるＩＮＶＩＴＥリクエストが上記のいずれであるかは、上述の転送先テーブルおよび転送元テーブルを参照することで特定できる。具体的には転送先テーブルで、上記リクエストのＦｒｏｍヘッダに記述されたＳＩＰ ＵＲＩと対応づけられたバーチャルＵＲＩが、転送元テーブルにも登録されていれば（ｂ）、登録されていなければ（ａ）である。

そして、受信したＩＮＶＩＴＥリクエストの種別が「コールバック」だった場合、ＳＩＰサーバ１００は上記リクエストの宛先を、転送元テーブルで上記バーチャルＵＲＩに対応づけられている発信端末ＵＲＩ（図中「Ｃａｌｌｅｒ ＶｏＩＰ」）に付け替えて、発信端末１０１へ転送する（図１（７））。その後２ＸＸ応答（成功）とＡＣＫリクエストを経て、着信端末１０２〜発信端末１０１間でＲＴＰコネクションが確立される（図１（８））。

一方、図２のように、着信端末１０２がＰＨＳでＰＳＴＮに接続してＳ−Ｐゲートウェイ１０４へコールバックした場合（図２（６））、Ｓ−Ｐゲートウェイ１０４を宛先とするＩＮＶＩＴＥリクエストがＳ−Ｐゲートウェイ１０４からＳＩＰサーバ１００に送信される（図２（７））。そしてＳＩＰサーバ１００が、上記と同様にコールバックか否かを判定し、コールバックの場合は上記リクエストの宛先を、転送元テーブルから検索した発信端末ＵＲＩに付け替えて転送する（図２（８））。その後２ＸＸ応答（成功）とＡＣＫリクエストを経て、Ｓ−Ｐゲートウェイ１０４〜発信端末１０１間でＲＴＰコネクションが確立される（図２（９））。なお、図１および図２のＰ−Ｓゲートウェイ１０３はなくても構わない（Ｐ−Ｓゲートウェイ１０３がなくても実施例１の発明は実施可能である）が、ここでは後述する他の実施例との比較のために示している。

次に、図３は本発明の実施例１にかかる通信中継装置（具体的には図１に示したＳＩＰサーバ１００）のハードウェア構成を示す説明図である。図中、ＣＰＵ３０１は装置全体の制御を司る。ＲＯＭ３０２はブートプログラムなどを記憶している。ＲＡＭ３０３はＣＰＵ３０１のワークエリアとして使用される。

ＨＤＤ３０４は、ＣＰＵ３０１の制御にしたがってＨＤ３０５に対するデータのリード／ライトを制御する。ＨＤ３０５は、ＨＤＤ３０４の制御にしたがって書き込まれたデータを記憶する。ＦＤＤ３０６は、ＣＰＵ３０１の制御にしたがってＦＤ３０７に対するデータのリード／ライトを制御する。ＦＤ３０７は、ＦＤＤ３０６の制御にしたがって書き込まれたデータを記憶する。なお、ＦＤ３０７は着脱可能な記録媒体の一例であり、ＦＤ３０７の代わりにＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、メモリーカードなどであってもよい。

ネットワークＩ／Ｆ３０８はＬＡＮ／ＷＡＮなどのネットワークに接続され、当該ネットワークと装置内部とのデータの送受信を司る。また、バス３００は上記各部を接続する。なお、上記のほか本装置はディスプレイ、マウス、キーボードなどのコンソール類を備えていてもよい。

次に、図４は本発明の実施例１にかかる通信中継装置（具体的には図１に示したＳＩＰサーバ１００）の機能的構成を示す説明図、図５は当該装置における各種リクエストの処理手順を示すフローチャートである。図４中の各部の機能は、図５のフローチャートにおいて順次説明する。

ＳＩＰサーバ１００のプロキシ４０２がＩＮＶＩＴＥリクエストを受信すると（ステップＳ５０１：Ｙｅｓ）、当該リクエストはいったん転送先特定部４０３に出力され、転送先特定部４０３のＩＮＶＩＴＥ種別特定部４０３ａが、当該リクエストの種別を特定する。そして種別が「通常」だった場合は（ステップＳ５０２：Ｙｅｓ）、転送先特定部４０３の転送先種別特定部４０３ｂが、上記リクエストの宛先のバーチャルＵＲＩに対応づけられた選択中ＵＲＩの種別を特定する。

そして、選択中ＵＲＩの種別が「通常」でなかった場合、たとえばデュアル端末のＰＨＳ番号を意味するＳＩＰ ＵＲＩだった場合は（ステップＳ５０３：Ｎｏ）、転送先特定部４０３はプロキシ４０２から入力したＩＮＶＩＴＥリクエスト、選択中ＵＲＩ、およびアナウンスサービス１０５のＳＩＰ ＵＲＩをリクエスト生成部４０４に出力する。

そしてリクエスト生成部４０４が、
・選択中ＵＲＩを宛先とするＩＮＶＩＴＥリクエスト
・選択中ＵＲＩを宛先とするＣＡＮＣＥＬリクエスト
・アナウンスサービス１０５のＳＩＰ ＵＲＩを宛先とするＩＮＶＩＴＥリクエスト
の３つを生成し（ステップＳ５０４）、これらがプロキシ４０２により順次転送される（ステップＳ５０５）。なお、選択中ＵＲＩを宛先とするＣＡＮＣＥＬリクエストは、当該ＵＲＩを宛先とするＩＮＶＩＴＥリクエストを受けて、Ｓ−Ｐゲートウェイ１０４が着信端末１０２を呼び出した後に転送されるものとする。

また、転送先特定部４０３は転送元テーブル更新部４０５に指示して、プロキシ４０２から入力したＩＮＶＩＴＥリクエストのバーチャルＵＲＩと発信端末ＵＲＩとの組を転送元テーブル４０１に登録させる（ステップＳ５０６）。

一方、選択中ＵＲＩの種別が「通常」だった場合は（ステップＳ５０３：Ｙｅｓ）、転送先特定部４０３はプロキシ４０２から入力したＩＮＶＩＴＥリクエストと選択中ＵＲＩとをリクエスト生成部４０４に出力し、リクエスト生成部４０４が上記リクエストの宛先を上記ＵＲＩで置換することで、上記ＵＲＩを宛先とするＩＮＶＩＴＥリクエストを生成する（ステップＳ５０７）。次に、リクエスト生成部４０４が上記リクエストをプロキシ４０２に出力し、プロキシ４０２が上記リクエストの転送（ステップＳ５０８）後、応答の転送やＡＣＫリクエストの転送など、ＩＮＶＩＴＥリクエスト転送後の通常の処理を行う（ステップＳ５０９）。

一方、プロキシ４０２から入力したＩＮＶＩＴＥリクエストの種別が「コールバック」だった場合（ステップＳ５０２：Ｎｏ）、すなわち当該リクエストが以前ステップＳ５０１〜Ｓ５０６で転送された他のＩＮＶＩＴＥリクエストをトリガーとしてなされたものである場合は、転送先特定部４０３は当該リクエストと、当該他のリクエストの転送時に転送元テーブル４０１に登録された発信端末ＵＲＩとをリクエスト生成部４０４に出力する。そしてリクエスト生成部４０４が、上記リクエストの宛先を上記ＵＲＩで置換することで、上記ＵＲＩを宛先とするＩＮＶＩＴＥリクエストを生成し（ステップＳ５１０）、これがプロキシ４０２により発信端末１０１へ転送される（ステップＳ５１１）。

また、転送先特定部４０３は転送元テーブル更新部４０５に指示して、トリガーとなった他のＩＮＶＩＴＥリクエストの転送時に転送元テーブル４０１に登録された、バーチャルＵＲＩと発信端末ＵＲＩとの組を削除させる（ステップＳ５１２）。その後はプロキシ４０２が、応答の転送やＡＣＫリクエストの転送など、ＩＮＶＩＴＥリクエスト転送後の通常の処理を行う（ステップＳ５０９）。なお、ＩＮＶＩＴＥリクエスト以外のリクエストを受信した場合は（ステップＳ５０１：Ｎｏ）、ＳＩＰサーバ１００は受信したリクエストに対応するその他の処理を行う（ステップＳ５１３）。

次に、図６は本発明の実施例１にかかる着信端末１０２における、着信処理の手順を示すフローチャートである。ＰＨＳによる待ち受け中にＳ−Ｐゲートウェイ１０４から着信があった場合（ステップＳ６０１：Ｙｅｓ、ステップＳ６０２：Ｙｅｓ。なお、Ｓ−Ｐゲートウェイ１０４からの着信かどうかは電話番号により特定できる）、着信端末１０２は着信音は出力せずに呼の切断を待つとともに、ＯＦＦになっているＷＬＡＮをＯＮにして（ステップＳ６０３）ＷＬＡＮの圏内／圏外を判定し（ステップＳ６０４）、この結果にもとづいてＷＬＡＮ／ＰＨＳのいずれかを通信手段として選択する。なお、上記判定結果のほか通信コストや通話の品質、あらかじめ設定されているプリファレンスなどにもとづいて、いずれかの通信手段を選択するようにしてもよい。

そしてＷＬＡＮを選択した場合は（ステップＳ６０５：Ｙｅｓ）、着信端末１０２はＷＬＡＮでＩＰ網に接続し、Ｓ−Ｐゲートウェイ１０４あてのＩＮＶＩＴＥリクエストを送信（ステップＳ６０６）することで、通常のＳＩＰ通話（ステップＳ６０７）を開始する。そして通話終了時には、着信時にＯＮにしたＷＬＡＮを再びＯＦＦにする（ステップＳ６０８）。なお同図では省略しているが、実際にはＩＮＶＩＴＥリクエストの前に、ＳＩＰサーバ１００へＲＥＧＩＳＴＥＲリクエストを送信する。

一方、ＰＨＳを選択した場合は（ステップＳ６０５：Ｎｏ）、着信端末１０２はＯＮにしたＷＬＡＮを再びＯＦＦにする（ステップＳ６０９）。次にＰＨＳでＰＳＴＮに接続して、Ｓ−Ｐゲートウェイ１０４の電話番号に発呼（ステップＳ６１０）することで、通常のＰＨＳ通話（ステップＳ６１１。なお、Ｓ−Ｐゲートウェイ１０４から先はＳＩＰ通話となる）を開始する。また、Ｓ−Ｐゲートウェイ１０４以外から電話がかかってきた場合には着信音を出力し（ステップＳ６０２：Ｎｏ、ステップＳ６１２）、着呼者が電話に出た後は通常のＰＨＳ通話となる（ステップＳ６１１）。

図１および図２と、図５および図６とを対応づけて説明すると、まず図１の場合、発信端末１０１からの電話の転送先が「通常」でないので、ＳＩＰサーバ１００はＳ−Ｐゲートウェイ１０４に指示して、通話料のかからないいわゆる「ワン切り」で着信端末１０２を呼び出させるとともに、発信端末１０１をいったんアナウンスサービス１０５に接続する（図５ステップＳ５０１〜Ｓ５０６）。

その後、着信端末１０２がＷＬＡＮでＩＰ網に接続してＩＮＶＩＴＥリクエストを返してきた場合（図６ステップＳ６０１〜Ｓ６０６）、あるいは着信端末１０２がＰＨＳでＰＳＴＮに接続してＳ−Ｐゲートウェイ１０４を発呼（図６ステップＳ６０１〜Ｓ６０５、Ｓ６０９〜Ｓ６１０）した結果、Ｓ−Ｐゲートウェイ１０４がＩＮＶＩＴＥリクエストを返してきた場合のいずれも、ＳＩＰサーバ１００は上記リクエストがコールバックであることを特定して、その宛先を発信端末１０１に付け替えの上で転送する（図５ステップＳ５０１〜Ｓ５０２、Ｓ５１０〜Ｓ５１２）。

そして発信端末１０１から２ＸＸ応答が返ってくると、ＳＩＰサーバ１００は当該応答を着信端末１０２あるいはＳ−Ｐゲートウェイ１０４に転送するとともに、着信端末１０２あるいはＳ−Ｐゲートウェイ１０４からＡＣＫリクエストがあると、当該リクエストを発信端末１０１に転送する（図５ステップＳ５０９）。

以上説明した実施例１によれば、まず図１の場合、唯一ＰＳＴＮを利用する（３）でもワン切りしているため、（１）〜（８）の全体を通じて通話料が発生しない。通信経路は図２０の点線矢印と同等になり（ただしコールバックのため、矢印の向きは逆となる）、従来技術の実線矢印に比べて、Ｓ−Ｐゲートウェイ２００４〜着信端末２００２間の通話料が削減できていることになる。

一方、図２の場合は（３）および（６）でＰＳＴＮを利用しており、前者はワン切りのため無料であるが、後者は有料である。通信経路は図２０の実線矢印と同等であり（ただしコールバックのため、矢印の向きは逆となる）、通話料は従来技術と同様に発生する。もっとも課金先は発呼者でなく着呼者となるため、無料で電話をかけることはできてもかかってきた電話を無料にすることはできないという、デュアル端末の従来の弱点を補うことができる。

ただ、実施例１では発呼者に違和感を覚えさせてしまう（かけた電話をいったん切らなければならないため）ことのほか、発呼者と着呼者が実際に通話できるようになるまでの時間もかかってしまう。そこで、実施例１のように着呼者からコールバックするのでなく、次に説明する実施例２のように、従来のやり方で着呼者につないだのでは相対的に高価な通信経路Ａとなってしまう発呼者からの電話を、相対的に安価な通信経路Ｂで着呼者に繋ぎ直すようにしてもよい。

（繋ぎ直し方式）
図７および図８は、本発明の実施例２にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。バーチャルＵＲＩあてのＩＮＶＩＴＥリクエストを発信端末７０１から受信（図中（１））すると、ＳＩＰサーバ７００は転送先テーブルから、当該バーチャルＵＲＩに対応づけられた選択中ＵＲＩを検索し、当該リクエストの宛先を当該選択中ＵＲＩに付け替えて転送する。そして、この選択中ＵＲＩがデュアル端末のＰＨＳ番号を意味するＳＩＰ ＵＲＩだった場合、上記リクエストはＳ−Ｐゲートウェイ７０４に転送（図中（２））されてＰＳＴＮの呼に変換の上、ＰＳＴＮ経由で着信端末７０２に転送（図中（３））される。そして、ここまでは実施例１のコールバック方式と同様である。

Ｓ−Ｐゲートウェイ７０４から呼び出された着信端末７０２は、通信手段としてＷＬＡＮ／ＰＨＳのいずれかを選択し、ＷＬＡＮを選択した場合、図７のようにＳＩＰサーバ７００へＲＥＧＩＳＴＥＲリクエストを送信する（図中（４））。

したがって図７の場合、ＳＩＰサーバ７００が受信するＲＥＧＩＳＴＥＲリクエストには、（ａ）通常のＲＥＧＩＳＴＥＲリクエストと、（ｂ）過去の電話をトリガーとするＲＥＧＩＳＴＥＲ（図中（４）など）との２種類があることになる。そして、あるＲＥＧＩＳＴＥＲリクエストが上記のいずれであるかは、上述の転送先テーブルおよび転送元テーブルを参照することで特定できる。具体的には転送先テーブルで、上記リクエストのＴｏヘッダおよびＦｒｏｍヘッダに記述されたＳＩＰ ＵＲＩ（ＩＰアドレスを登録されるＳＩＰ ＵＲＩ）と対応づけられたバーチャルＵＲＩが、転送元テーブルにも登録されていれば（ｂ）、登録されていなければ（ａ）である。なお、以下では（ａ）に該当するＲＥＧＩＳＴＥＲリクエストの種別を「通常」と呼ぶ。

そして、受信したＲＥＧＩＳＴＥＲリクエストの種別が「通常」でなかった場合、ＳＩＰサーバ７００はＳ−Ｐゲートウェイ７０４にＣＡＮＣＥＬリクエストを送信（図中（５））することで、Ｓ−Ｐゲートウェイ７０４から着信端末７０２への呼を切断させる（図中（６））。またその一方で、発信端末７０１から受信（図中（１））したＩＮＶＩＴＥリクエストの宛先を、着信端末７０２がＩＰアドレスを登録（図中（４））したＳＩＰ ＵＲＩに付け替えて転送する（図中（７））。そして着信端末７０２から２ＸＸ応答（成功）を受信すると（図中（８））、当該応答を発信端末７０１へ転送し（図中（９））、さらにＡＣＫリクエストの転送を経て、発信端末７０１〜着信端末７０２間でＲＴＰコネクションが確立される（図中（１０））。

一方、Ｓ−Ｐゲートウェイ７０４から呼び出された着信端末７０２が、通信手段としてＰＨＳを選択した場合は、着呼者が電話に出た時点で、図８のように着信端末７０２からＰＳＴＮ経由で応答信号が返される（図中（４））。そして上記信号を受信したＳ−Ｐゲートウェイ７０４は、ＳＩＰサーバ７００へ２ＸＸ応答を送信し（図中（５））、ＳＩＰサーバ７００がさらに発信端末７０１へ当該応答を転送する（図中（６））。その後ＡＣＫリクエストの転送を経て、発信端末７０１〜Ｓ−Ｐゲートウェイ７０４間でＲＴＰコネクションが確立される（図中（７））。

本発明の実施例２にかかる通信中継装置（具体的には図７および図８に示したＳＩＰサーバ７００）のハードウェア構成は、図３に示した実施例１のそれと同様であるので説明を省略する。図９は上記装置の機能的構成を示す説明図、図１０は上記装置における各種リクエストの処理手順を示すフローチャートである。図９中の各部の機能は、図１０のフローチャートにおいて順次説明する。

ＳＩＰサーバ７００のプロキシ９０２がＩＮＶＩＴＥリクエストを受信すると（ステップＳ１００１：Ｙｅｓ）、当該リクエストはいったん転送先特定部９０３に出力され、転送先特定部９０３の転送先種別特定部９０３ａが、転送先テーブル９００を参照して、当該リクエストの宛先のバーチャルＵＲＩに対応づけられた選択中ＵＲＩの種別を特定する。

そして、選択中ＵＲＩの種別が「通常」でなかった場合（ステップＳ１００２：Ｎｏ）、転送元テーブル更新部９０５に指示して、上記リクエストのバーチャルＵＲＩと発信端末ＵＲＩとの組を転送元テーブル９０１に登録させる（ステップＳ１００３）。なお、選択中ＵＲＩの種別が「通常」だった場合は（ステップＳ１００２：Ｙｅｓ）、ステップＳ１００３の処理は省略される。

そしていずれの場合も、上記リクエストと選択中ＵＲＩとをリクエスト生成部９０４に出力し、リクエスト生成部９０４が上記リクエストの宛先を上記ＵＲＩで置換することで、上記ＵＲＩを宛先とするＩＮＶＩＴＥリクエストを生成する（ステップＳ１００４）。次に、プロキシ９０２が上記リクエストの転送（ステップＳ１００５）後、応答の転送やＡＣＫリクエストの転送など、ＩＮＶＩＴＥリクエスト転送後の通常の処理を行う（ステップＳ１００６）。

一方、ＳＩＰサーバ７００のレジストラ９０６がＲＥＧＩＳＴＥＲリクエストを受信すると（ステップＳ１００７：Ｙｅｓ）、通常のＳＩＰ登録処理（ステップＳ１００８）の後、レジストラ９０６のＲＥＧＩＳＴＥＲ種別特定部９０６ａが、上記リクエストの種別を特定する。

そして、種別が「通常」だった場合は（ステップＳ１００９：Ｙｅｓ）そのままステップＳ１００１に戻る。一方、種別が「通常」でなかった場合（ステップＳ１００９：Ｎｏ）、すなわち上記リクエストが以前ステップＳ１００１〜Ｓ１００６で転送されたＩＮＶＩＴＥリクエストをトリガーとしてなされたものである場合は、レジストラ９０６は当該ＩＮＶＩＴＥリクエスト、当該ＩＮＶＩＴＥリクエストの転送先となった選択中ＵＲＩ、および当該ＩＮＶＩＴＥリクエストの転送時に転送元テーブル９０１に登録された発信端末ＵＲＩをリクエスト生成部９０４に出力する。

そしてリクエスト生成部９０４が、
・発信端末ＵＲＩを宛先とするＩＮＶＩＴＥリクエスト
・選択中ＵＲＩを宛先とするＣＡＮＣＥＬリクエスト
の２つを生成し（ステップＳ１０１０）、これらがプロキシ９０２により順次転送される（ステップＳ１０１１）。

また、レジストラ９０６は転送元テーブル更新部９０５に指示して、トリガーとなったＩＮＶＩＴＥリクエストの転送時に転送元テーブル９０１に登録された、バーチャルＵＲＩと発信端末ＵＲＩとの組を削除させる（ステップＳ１０１２）。その後はプロキシ９０２が、応答の転送やＡＣＫリクエストの転送など、ＩＮＶＩＴＥリクエスト転送後の通常の処理を行う（ステップＳ１００６）。なお、ＩＮＶＩＴＥリクエストやＲＥＧＩＳＴＥＲリクエスト以外のリクエストを受信した場合は（ステップＳ１００１：Ｎｏ、ステップＳ１００７：Ｎｏ）、ＳＩＰサーバ７００は受信したリクエストに対応するその他の処理を行う（ステップＳ１０１３）。

次に、図１１は本発明の実施例２にかかる着信端末７０２における、着信処理の手順を示すフローチャートである。ＰＨＳによる待ち受け中にＳ−Ｐゲートウェイ７０４から着信があった場合（ステップＳ１１０１：Ｙｅｓ、ステップＳ１１０２：Ｙｅｓ）、着信端末７０２はＯＦＦになっているＷＬＡＮをＯＮにして（ステップＳ１１０３）ＷＬＡＮの圏内／圏外を判定し（ステップＳ１１０４）、この結果にもとづいてＷＬＡＮ／ＰＨＳのいずれかを通信手段として選択する。なお、上記判定結果のほか通信コストや通話の品質、あらかじめ設定されているプリファレンスなどにもとづいて、通信手段を選択するようにしてもよい。

そしてＷＬＡＮを選択した場合は（ステップＳ１１０５：Ｙｅｓ）、着信端末７０２はＷＬＡＮでＩＰ網に接続し、ＳＩＰサーバ７００へＲＥＧＩＳＴＥＲリクエストを送信する（ステップＳ１１０６）。一方、ＰＨＳを選択した場合は（ステップＳ１１０５：Ｎｏ）、ＯＮにしたＷＬＡＮをＯＦＦにするとともに（ステップＳ１１０７）着信音を出力し（ステップＳ１１０８）、着呼者が電話に出た後は通常のＰＨＳ通話となる（ステップＳ１１０９）。なお、ＰＨＳによる待ち受け中にＳ−Ｐゲートウェイ７０４以外から着信があった場合（ステップＳ１１０１：Ｙｅｓ、ステップＳ１１０２：Ｎｏ）も、着信端末７０２は着信音を出力し（ステップＳ１１０８）、着呼者が電話に出た後は通常のＰＨＳ通話となる（ステップＳ１１０９）。

また、ステップＳ１１０３でＯＮにしたＷＬＡＮへＩＮＶＩＴＥリクエストが着信すると（ステップＳ１１０１：Ｎｏ、ステップＳ１１１０：Ｙｅｓ）、着信端末７０２は着信音を出力し（ステップＳ１１１１）、着呼者が電話に出た後は通常のＳＩＰ通話となる（ステップＳ１１１２）。なお通話終了時には、着信時にＯＮにしたＷＬＡＮを再びＯＦＦにする（ステップＳ１１１３）。

図７および図８と、図１０および図１１とを対応づけて説明すると、まず図７の場合、ＳＩＰサーバ７００は発信端末７０１からの電話を、まずＰＳＴＮ経由で着信端末７０２に転送するが（図１０ステップＳ１００１〜Ｓ１００５）、着信端末７０２からＲＥＧＩＳＴＥＲリクエストがあると（図１１ステップＳ１１０１〜Ｓ１１０６）、それは取り消して次はＩＰ網経由で着信端末７０２に転送する（図１０ステップＳ１００７〜Ｓ１０１２）。そして着信端末７０２から２ＸＸ応答があると、当該応答を発信端末７０１に転送するとともに、発信端末７０１からＡＣＫリクエストがあると、当該リクエストを着信端末７０２に転送する（図１０ステップＳ１００６）。

一方図８の場合、着信端末７０２がＳ−Ｐゲートウェイ７０４に応答信号を返すと（図１１ステップＳ１１０１〜Ｓ１１０５、Ｓ１１０７〜Ｓ１１０９）、Ｓ−Ｐゲートウェイ７０４がＳＩＰサーバ７００に２ＸＸ応答を返すので、ＳＩＰサーバ７００は当該応答を発信端末７０１に転送するとともに、発信端末７０１からＡＣＫリクエストがあると、当該リクエストをＳ−Ｐゲートウェイ７０４に転送する（図１０ステップＳ１００６）。

なお、図７の場合、ＳＩＰサーバ７００が着信端末７０２からのＲＥＧＩＳＴＥＲリクエストを受信する前に、Ｓ−Ｐゲートウェイ７０４から３ＸＸ〜６ＸＸ応答を受信してしまうと、当該応答が発信端末７０１に転送された時点で発信端末７０１からの電話は切断されてしまい、その後に着信端末７０２が登録してきても発信端末７０１と接続することができなくなる。そこで図１０のステップＳ１００６における処理を、ＳＩＰサーバ７００がＳ−Ｐゲートウェイ７０４から３ＸＸ〜６ＸＸ応答を受信した場合は、所定時間内に着信端末７０２からＲＥＧＩＳＴＥＲリクエストがないことを条件として発信端末７０１へ転送するよう修正してもよい。すなわちＳ−Ｐゲートウェイ７０４から接続失敗が通知されてきても、すぐには発信端末７０１へ通知せず、上記所定時間だけは着信端末７０２からの登録を待つようにする。

以上説明した実施例２によれば、まず図７の場合、（３）でＳ−Ｐゲートウェイ７０４がかけた電話は着信端末７０２の応答前に切断されるので、（１）〜（１０）の全体を通じて通話料が発生しない。通信経路は図２０の点線矢印と同一になり、従来技術の実線矢印に比べて、Ｓ−Ｐゲートウェイ２００４〜着信端末２００２間の通話料が削減できていることになる。一方、図８の場合は図２０の実線矢印と同一、すなわち上述のユビキタスＩＰ電話システムにおいて、ＩＰ端末から代表番号へかけた電話が非ＩＰ端末へ転送されるケースと同一であり、Ｓ−Ｐゲートウェイ２００４〜着信端末２００２間の通話料が発呼者に課金される。

なお、図７で着信端末７０２がＳＩＰサーバ７００へ送信するＲＥＧＩＳＴＥＲリクエストは、本来的にはＳＩＰ登録のためのリクエストであるが、実施例２ではこれを一種の接続要求、すなわち発信端末７０１とＩＰ網経由で接続すべき旨の着信端末７０２からの要求とみなし、この要求に応じてＳＩＰサーバ７００が、いったんＰＳＴＮ経由で転送した電話をＩＰ網経由で転送し直していると言うこともできる。逆に言うと、上記接続要求は必ずしも着信端末７０２からのＲＥＧＩＳＴＥＲリクエストでなければならないわけではなく、着信端末７０２がＷＬＡＮで着信可能な状態になったことを示す何らかの通知（必ずしも着信端末７０２自身からの通知でなくともよい）などであってもよい。

（繋ぎ直し＋かけ直し方式）
図１２および図１３は、本発明の実施例３にかかる通信中継装置により実現される、「繋ぎ直し＋かけ直し方式」の概略を示す説明図である。上述した実施例２はＩＰ端末（たとえばＩＰ電話）から電話をかける場合であるが、実施例３は非ＩＰ端末、具体的には従来の電話機や、ＷＬＡＮ圏外にあるときのデュアル端末などから電話をかける場合である。そして図２１に示したように、発信端末２００１がＰＳＴＮ経由で発呼し、着信端末２００２もＰＳＴＮ経由で着呼すると、発信端末２００１〜Ｐ−Ｓゲートウェイ２００３間の通話料と、Ｓ−Ｐゲートウェイ２００４〜着信端末２００２間の通話料とが二重に発生してしまう。

そこで実施例３では、図１２および図１３に示すように、発信端末１２０１がＰＳＴＮ経由で発呼し（図中（１））、Ｐ−Ｓゲートウェイ１２０３からＳＩＰサーバ１２００を経てＩＮＶＩＴＥリクエストを転送（図中（２）（３））されたＰ−Ｓゲートウェイ１２０４が、さらにＰＳＴＮ経由で発呼する（図中（４））場合、ＩＮＶＩＴＥリクエストの転送直後にＳＩＰサーバ１２００からＳ−Ｐゲートウェイ１２０４へＣＡＮＣＥＬリクエストを送信する（図中（３））ことで、Ｓ−Ｐゲートウェイ１２０４から着信端末１２０２への呼を通話料の発生前（具体的にはワンコール程度）で切断してしまう（図中（４））。

そして着信端末１２０２は、通信手段としてＷＬＡＮを選択した場合、図１２に示すようにＳＩＰサーバ１２００へＲＥＧＩＳＴＥＲリクエストを送信する（図中（５））。ＳＩＰサーバ１２００は、上記リクエストの種別が「通常」でなかった場合、Ｐ−Ｓゲートウェイ１２０３から受信（図中（２））したＩＮＶＩＴＥリクエストの宛先を、着信端末１２０２がＩＰアドレスを登録（図中（５））したＳＩＰ ＵＲＩに付け替えて転送する（図中（６））。

そして着信端末１２０２から２ＸＸ応答を受信すると（図中（７））、当該応答をＰ−Ｓゲートウェイ１２０３へ転送し（図中（８））、さらにＡＣＫリクエストの転送を経て、Ｐ−Ｓゲートウェイ１２０３〜着信端末１２０２間でＲＴＰコネクションが確立される（図中（９））。その後、Ｐ−Ｓゲートウェイ１２０３から発信端末１２０１へ、ＰＳＴＮ経由で応答信号を返す（図中（１０））。

一方、着信端末１２０２は通信手段としてＰＨＳを選択した場合、図１３に示すように、Ｓ−Ｐゲートウェイ１２０４から電話がかかってきた（図中（４））後は続いて発信端末１２０１から電話がかかってくるのを待つ（自分からは何もしない）。Ｓ−Ｐゲートウェイ１２０４からの電話はワン切りされてしまうのでＰＨＳで応答しようにも間に合わず、しかもＷＬＡＮも使えない／使わないので、着信端末１２０２としてはＰＨＳでＳ−Ｐゲートウェイ１２０４にコールバックするしかないのであるが、Ｓ−Ｐゲートウェイ１２０４からＳＩＰサーバ１２００を経てＰ−Ｓゲートウェイ１２０３へＩＮＶＩＴＥリクエストが転送され、Ｐ−Ｓゲートウェイ１２０３からＰＳＴＮ経由で発信端末１２０１が呼び出されると、上述の二重課金の問題がここでも発生してしまう。

これを避けるため実施例３では、着信端末１２０２が何もしない代わりに、発信端末１２０１が電話を自動的にかけ直すようにする。すなわち実施例３にかかる発信端末１２０１は、着呼者の代表番号あてにかけた電話が所定時間内につながらない（所定時間内にＰ−Ｓゲートウェイ１２０３から応答信号が返ってこない）ときは、着呼者の別の電話番号を一つ選択して電話をかけ直す。なお、この別の電話番号はあらかじめ発信端末１２０１に保持しているのでも、あるいはＳＩＰサーバ１２００などからリアルタイムに取得するのでもよい。

そしてこの別の電話番号の中にデュアル端末のＰＨＳ番号があれば、Ｓ−Ｐゲートウェイ７０４からの着信後しばらく経ってから、着信端末１２０２へ今度は発信端末１２０１から直接電話がかかってくることになる（図中（５））。そして着信端末１２０２が応答信号を返した（図中（６））後は、通常のＰＨＳ通話となる。

本発明の実施例３にかかる通信中継装置（具体的には図１２および図１３に示したＳＩＰサーバ１２００）のハードウェア構成は、図３に示した実施例１のそれと同様であるので説明を省略する。また上記装置の機能的構成は、図９に示した実施例２のそれとほぼ同様であり、異なる点は図１４のフローチャートにおいて順次説明する。

図１４は、上記装置における各種リクエストの処理手順を示すフローチャートである。図１０に示した実施例２のそれとの差異は、ＣＡＮＣＥＬリクエストの生成・転送処理が、図１０ではＲＥＧＩＳＴＥＲリクエスト受信時の処理ループ内にある（ステップＳ１０１０・Ｓ１０１１）のに対して、図１４では当該リクエストのトリガーとなったＩＮＶＩＴＥリクエスト受信時の処理ループ内にある（ステップＳ１４０４・Ｓ１４０５）点である（なお、ＩＮＶＩＴＥリクエストやＲＥＧＩＳＴＥＲリクエスト以外のリクエストを受信した場合は、ＳＩＰサーバ１２００は受信したリクエストに対応するその他の処理を行う（ステップＳ１４０１：Ｎｏ、ステップＳ１４０９：Ｎｏ、ステップＳ１４１５））。

すなわち実施例３にかかるリクエスト生成部９０４は、ＳＩＰサーバ１２００が受信したＩＮＶＩＴＥリクエストについて、転送先種別特定部９０３ａで特定された選択中ＵＲＩの種別が「通常」でなかった場合、当該ＵＲＩを宛先とするＩＮＶＩＴＥリクエストおよびＣＡＮＣＥＬリクエストの２つを生成し、これらがプロキシ９０２により順次転送される（ステップＳ１４０１〜Ｓ１４０５）。なお、選択中ＵＲＩの種別が「通常」だった場合は、当該ＵＲＩを宛先とするＩＮＶＩＴＥリクエストを生成し、これがプロキシ９０２により転送された後は、プロキシ９０２が応答の転送やＡＣＫリクエストの転送など、ＩＮＶＩＴＥリクエスト転送後の通常の処理を行う（ステップＳ１４０１〜Ｓ１４０２、Ｓ１４０６〜Ｓ１４０８）。

また、実施例３にかかるリクエスト生成部９０４は、ＳＩＰサーバ１２００が受信したＲＥＧＩＳＴＥＲリクエストについて、ＲＥＧＩＳＴＥＲ種別特定部９０６ａにより特定されたその種別が「通常」でなかった場合、ＩＰアドレスが登録されたＳＩＰ ＵＲＩを宛先とするＩＮＶＩＴＥリクエストを生成し、これがプロキシ９０２により着信端末１２０２へ転送される（ステップＳ１４０９〜Ｓ１４１４）。

次に、図１５は本発明の実施例３にかかる着信端末１２０２における、着信処理の手順を示すフローチャートである。図中ステップＳ１５０１〜Ｓ１５１３のそれぞれにおける処理は、図１１に示したステップＳ１１０１〜Ｓ１１１３のそれぞれにおける処理と同一である。ただし実施例３では、着信端末１２０２が通信手段としてＰＨＳを選択し、ＷＬＡＮをＯＦＦにした（ステップＳ１５０５：Ｎｏ、ステップＳ１５０７）時点では、Ｓ−Ｐゲートウェイ１２０４からの呼は切断されていてＰＨＳ通話が不可能なため、ステップＳ１５０７の後そのままステップＳ１５０１に戻っている。

次に、図１６は本発明の実施例３にかかる発信端末１２０１における、発信処理の手順を示すフローチャートである。発呼者から特定の電話番号、たとえば着呼者の代表番号に対する発呼指示があると（ステップＳ１６０１：Ｙｅｓ）、発信端末１２０１はＰＳＴＮ経由で当該番号に発呼する（ステップＳ１６０２）。上記呼はＰ−Ｓゲートウェイ１２０３でＩＮＶＩＴＥリクエストに変換の上、ＳＩＰサーバ１２００に転送され、ＳＩＰサーバ１２００から２ＸＸ応答が返されると、さらにＰ−Ｓゲートウェイ１２０３から発信端末１２０１へ応答信号が返され（ステップＳ１６０３：Ｙｅｓ）、その後は通常の音声通話となる（ステップＳ１６０４）。

そして、発信端末１２０１は発呼から所定時間だけ上記信号を待ち（ステップＳ１６０３：Ｎｏ、ステップＳ１６０５：Ｎｏ）、当該時間が経過してもＰ−Ｓゲートウェイ１２０３から応答がない場合（ステップＳ１６０３：Ｎｏ、ステップＳ１６０５：Ｙｅｓ）、上記着呼者にまだ発呼していない他の電話番号があれば（ステップＳ１６０６：Ｙｅｓ）、その中から一つを選択の上（ステップＳ１６０７）当該番号へ発呼する（ステップＳ１６０２）。なお、着呼者のすべての電話番号を発呼して、それでも応答がない場合は（ステップＳ１６０６：Ｎｏ）、その時点で処理を終了する。

図１２および図１３と、図１４〜図１６とを対応づけて説明すると、まず図１２の場合、ＳＩＰサーバ１２００は着信端末１２０２からのＲＥＧＩＳＴＥＲリクエストを待たずに、そのトリガーとなるＩＮＶＩＴＥリクエストをキャンセルし（図１４ステップＳ１４０１〜Ｓ１４０５）、着信端末１２０２からＲＥＧＩＳＴＥＲリクエストがあると（図１５ステップＳ１５０１〜Ｓ１５０６）、ＩＰアドレスを登録されたＳＩＰ ＵＲＩへ発信端末１２０１からのＩＮＶＩＴＥリクエストを転送する（図１４ステップＳ１４０９〜Ｓ１４１４）。

一方図１３の場合、ＳＩＰサーバ１２００がＩＮＶＩＴＥリクエストをキャンセルする（図１４ステップＳ１４０１〜Ｓ１４０５）結果、Ｐ−Ｓゲートウェイ１２０３からの応答信号がないまま所定時間が経過するので、発信端末１２０１は着呼者の他の電話番号、ここではデュアル端末のＰＨＳ番号を選択して電話をかけ直す（図１６ステップＳ１６０１〜Ｓ１６０７）。

以上説明した実施例３によれば、図１２の場合も図１３の場合も、図２１のような通信経路となる電話はＳＩＰサーバ１２００の制御によって常にワン切り（すなわち通話料の発生前に切断）されるので、上述の二重課金が発生しない。

ただ、ＷＬＡＮの使える場所がＰＨＳの使える場所に比べてまだまだ限られており、そもそもデュアル端末もまだ普及が始まったばかりである現状から、実際には図１２のようにＳＩＰサーバ１２００が電話を繋ぎ直すのでなく、図１３のように発信端末１２０１が電話をかけ直すことになるケースがほとんどと考えられる。そして図１３の場合は、図中（３）（４）がなくても特に支障がない。そこで実施例３の「繋ぎ直し＋かけ直し方式」を、次に説明する実施例４の「かけ直し方式」のように簡略化してしまってもよい。

（かけ直し方式）
図１７は、本発明の実施例４にかかる通信中継装置により実現される、「かけ直し方式」の概略を示す説明図である。図示するように実施例４では、二重課金の原因となるＩＮＶＩＴＥリクエスト、具体的にはＰ−Ｓゲートウェイ１７０３からＳＩＰサーバ１７００を経てＳ−Ｐゲートウェイ１７０４に転送されることになるＩＮＶＩＴＥリクエスト（図中（２））を、ＳＩＰサーバ１７００で破棄してしまい、その先へ転送しないようにする。その結果、発呼から所定時間が経過してもＰ−Ｓゲートウェイ１７０３から応答信号が返ってこないので、発信端末１７０１は着呼者の他の電話番号、たとえばデュアル端末のＰＨＳ番号を選択して電話をかけ直し（図中（３））、着信端末１７０２から応答信号が返ってきた（図中（４））後は通常のＰＨＳ通話となる。

本発明の実施例４にかかる通信中継装置（具体的には図１７に示したＳＩＰサーバ１７００）のハードウェア構成は、図３に示した実施例１のそれと同様であるので説明を省略する。図１８は上記装置の機能的構成を示す説明図、図１９は上記装置における各種リクエストの処理手順を示すフローチャートである。図１８中の各部の機能は、図１９のフローチャートにおいて順次説明する。

ＳＩＰサーバ１７００のプロキシ１８０１がＩＮＶＩＴＥリクエストを受信すると（ステップＳ１９０１：Ｙｅｓ）、当該リクエストはいったん転送先特定部１８０２に出力され、転送先特定部１８０２の転送可否判定部１８０２ａが、転送先テーブル１８００を参照して当該リクエストの転送可否を判定する（ステップＳ１９０２）。具体的には、Ｓ−Ｐゲートウェイ１７０４に転送されることになるＩＮＶＩＴＥリクエストで、そのＴｏヘッダにもＦｒｏｍヘッダにも電話番号（ＰＳＴＮ上での識別子）を意味するＳＩＰ ＵＲＩが記述されることになる場合、すなわち上記リクエストがＳＩＰサーバ１７００の前にも後にもＰＳＴＮを経由することになる場合は転送不可、それ以外の場合は転送可とする。

そして転送不可の場合は（ステップＳ１９０２：Ｎｏ）、ステップＳ１９０１に戻って他のリクエストの受信待ちとなる一方、転送可の場合は（ステップＳ１９０２：Ｙｅｓ）リクエスト生成部１８０３で、上記リクエストの宛先を転送先テーブル１８００の選択中ＵＲＩに付け替えることで、当該ＵＲＩあてのＩＮＶＩＴＥリクエストを生成する（ステップ１９０３）。そしてこれがプロキシ１８０１により転送（ステップＳ１９０４）された後は、プロキシ１８０１が応答の転送やＡＣＫリクエストの転送など、ＩＮＶＩＴＥリクエスト転送後の通常の処理を行う（ステップＳ１９０５）。

なお、ＩＮＶＩＴＥリクエスト以外のリクエストを受信した場合は（ステップＳ１９０１：Ｎｏ）、ＳＩＰサーバ１７００は受信したリクエストに対応するその他の処理を行う（ステップＳ１９０６）。

なお、実施例４の着信端末１７０２はＰＳＴＮでの着呼が可能な機器であれば何であってもよく、当該装置における処理も従来技術と同一である。また、実施例４の発信端末１７０１もＰＳＴＮでの発呼が可能な機器であれば何であってもよいが、実施例３の発信端末１２０１と同様、図１６の手順により、所定時間以上電話がつながらないときは他の番号へ電話をかけ直す機能を備えているものとする。

以上説明した実施例４によれば、転送すると二重課金が発生するようなＩＮＶＩＴＥリクエストはＳＩＰサーバ１７００どまりとなり、発信端末１７０１は別の経路で電話をかけ直すことになるため、二重課金が発生しない。より一般的に言えば、相対的に高価な通信経路Ａと安価な通信経路Ｂとがあった場合に、先にＡ経由で電話がかかってきたときは経路上のどこか（たとえば実施例４のようにＳＩＰサーバ１７００）でそれを破棄し、あらためてＢ経由で電話をかけさせるので、最終的に電話がつながったときの通信経路は常に最も安価なものとなる。

もっとも、上記では図２１の実線矢印のような経路による通話は、破線矢印のような経路による通話より割高であることを前提としたが、発信端末２００１と着信端末２００２との機器の組み合わせによって通話料は異なるため、二重課金が発生するとしても実線矢印のほうが破線矢印より安価となる場合もある。そしてその場合は、たとえば発信端末２００１から点線矢印の経路で電話がかかってきても、着信端末２００２で着信を拒否し、あらためて実線矢印の経路で電話をかけさせるようにしてもよい。

なお、上述した実施例１および２では発信端末１０１／７０１がＩＰ端末、実施例３および４では発信端末１２０１／１７０１が非ＩＰ端末であることをそれぞれ前提としたが、現実のＳＩＰサーバが受信するＩＮＶＩＴＥリクエストの中には、（ａ）発信端末自身が発信したＩＮＶＩＴＥリクエストと、（ｂ）発信端末からの呼を変換してＰ−Ｓゲートウェイが転送してきたＩＮＶＩＴＥリクエストとが混在している。

そのため実際には、たとえば実施例２のＳＩＰサーバ７００と実施例３のＳＩＰサーバ１２００の双方の機能を併せ持つＳＩＰサーバを用意し、（ａ）を受信したときは図１０の手順、（ｂ）を受信したときは図１４の手順により処理するようにする。あるいは、実施例１のＳＩＰサーバ１００と実施例４のＳＩＰサーバ１７００の双方の機能を併せ持つＳＩＰサーバを用意し、（ａ）を受信したときは図５の手順、（ｂ）を受信したときは図１９の手順により処理するようにしてもよい。

以上のように、本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置は、発信端末〜着信端末間に複数の通信経路がある場合の最適な経路の選択に有用であり、特に、相対的に安価な通信経路が何らかの事情（たとえば省電力など）で事実上使用不能となっているケースに適している。

１００，７００，１２００，１７００ ＳＩＰサーバ
１０１，７０１，１２０１，１７０１ 発信端末
１０２，７０２，１２０２，１７０２ 着信端末
１０３，７０３，１２０３，１７０３ Ｐ−Ｓゲートウェイ
１０４，７０４，１２０４，１７０４ Ｓ−Ｐゲートウェイ
１０５ アナウンスサービス
３００ バス
３０１ ＣＰＵ
３０２ ＲＯＭ
３０３ ＲＡＭ
３０４ ＨＤＤ
３０５ ＨＤ
３０６ ＦＤＤ
３０７ ＦＤ
３０８ ネットワークＩ／Ｆ
４００，９００，１８００ 転送先テーブル
４０１，９０１ 転送元テーブル
４０２，９０２，１８０１ プロキシ
４０３，９０３，１８０２ 転送先特定部
４０３ａ ＩＮＶＩＴＥ種別特定部
４０３ｂ，９０３ａ 転送先種別特定部
４０４，９０４，１８０３ リクエスト生成部
４０５，９０５ 転送先テーブル更新部
９０６ レジストラ
９０６ａ ＲＥＧＩＳＴＥＲ種別特定部
１８０２ａ 転送可否判定部

Claims (3)

1. 第１の音声通話装置と複数のネットワークに接続可能な第２の音声通話装置との間の通信を中継する処理をサーバが実行する通信中継方法であって、
   前記ネットワークのうち第１のネットワークを通じて前記第１の音声通話装置から前記サーバが受信した、前記第１の音声通話装置と前記第２の音声通話装置との接続要求を、前記ネットワークのうち第２のネットワークを通じて、前記サーバが前記第２の音声通話装置に転送する第１の転送工程と、
   前記第２のネットワークで前記接続要求から変換された呼が前記第２の音声通話装置に転送された結果、前記第２の音声通話装置から、前記第１のネットワークを通じて、前記第１のネットワークで着信可能であることを示す通知を、前記サーバが受信する受信工程と、
   前記受信工程で前記通知を受信した場合に、前記サーバが、前記接続要求を前記第１のネットワークを通じて前記第２の音声通話装置に送信する送信工程と、
   前記送信工程で前記接続要求を前記第１のネットワークを通じて前記第２の音声通話装置に送信した結果、前記第２の音声通話装置から前記サーバが受信した、前記接続要求に対する応答を、前記サーバが、前記第１のネットワークを通じて前記第１の音声通話装置に転送する第２の転送工程と、
   を含むことを特徴とする通信中継方法。
2. 第１の音声通話装置と複数のネットワークに接続可能な第２の音声通話装置との間の通信を中継する処理をサーバに実行させる通信中継プログラムであって、
   前記ネットワークのうち第１のネットワークを通じて前記第１の音声通話装置から前記サーバが受信した、前記第１の音声通話装置と前記第２の音声通話装置との接続要求を、前記ネットワークのうち第２のネットワークを通じて、前記サーバが前記第２の音声通話装置に転送する第１の転送工程と、
   前記第２のネットワークで前記接続要求から変換された呼が前記第２の音声通話装置に転送された結果、前記第２の音声通話装置から、前記第１のネットワークを通じて、前記第１のネットワークで着信可能であることを示す通知を、前記サーバが受信する受信工程と、
   前記受信工程で前記通知を受信した場合に、前記サーバが、前記接続要求を前記第１のネットワークを通じて前記第２の音声通話装置に送信する送信工程と、
   前記送信工程で前記接続要求を前記第１のネットワークを通じて前記第２の音声通話装置に送信した結果、前記第２の音声通話装置から前記サーバが受信した、前記接続要求に対する応答を、前記サーバが、前記第１のネットワークを通じて前記第１の音声通話装置に転送する第２の転送工程と、
   を前記サーバに実行させることを特徴とする通信中継プログラム。
3. 第１の音声通話装置と複数のネットワークに接続可能な第２の音声通話装置との間の通信を中継する処理を実行する通信中継装置であって、
   前記ネットワークのうち第１のネットワークを通じて前記第１の音声通話装置から受信した、前記第１の音声通話装置と前記第２の音声通話装置との接続要求を、前記ネットワークのうち第２のネットワークを通じて、前記第２の音声通話装置に転送する第１の転送手段と、
   前記第２のネットワークで前記接続要求から変換された呼が前記第２の音声通話装置に転送された結果、前記第２の音声通話装置から、前記第１のネットワークを通じて、前記第１のネットワークで着信可能であることを示す通知を、受信する受信手段と、
   前記受信手段で前記通知を受信した場合に、前記接続要求を前記第１のネットワークを通じて前記第２の音声通話装置に送信する送信手段と、
   前記送信手段で前記接続要求を前記第１のネットワークを通じて前記第２の音声通話装置に送信した結果、前記第２の音声通話装置から受信した、前記接続要求に対する応答を、前記第１のネットワークを通じて前記第１の音声通話装置に転送する第２の転送手段と、
   を有することを特徴とする通信中継装置。

Images