通信中継方法、通信中継プログラムおよび通信中継装置
【課題】WLANとPHSの双方を搭載する携帯型のデュアル端末は、省電力の観点から、PHS圏内にある限りはたとえWLAN圏内でもWLANをOFFにしている。そのため電話がかかってくると、通常はS−Pゲートウェイ104からPSTN経由で呼び出されることになり、発呼者に通話料が発生してしまう。
【解決手段】そこで、S−Pゲートウェイ104から着信端末102への呼を通話料の発生前に切断するとともに、着信端末102からIP網またはPSTN経由でS−Pゲートウェイ104へコールバックする。そして着信端末102の代わりに、SIPサーバ100でコールバック先となる発信端末101を特定し、これにより着信端末102からの電話が発信端末101に接続される。なおこの「コールバック方式」のほか、「繋ぎ直し方式」「繋ぎ直し+かけ直し方式」「かけ直し方式」の4方式を提案する。
【解決手段】そこで、S−Pゲートウェイ104から着信端末102への呼を通話料の発生前に切断するとともに、着信端末102からIP網またはPSTN経由でS−Pゲートウェイ104へコールバックする。そして着信端末102の代わりに、SIPサーバ100でコールバック先となる発信端末101を特定し、これにより着信端末102からの電話が発信端末101に接続される。なおこの「コールバック方式」のほか、「繋ぎ直し方式」「繋ぎ直し+かけ直し方式」「かけ直し方式」の4方式を提案する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、第1の音声通話装置と第2の音声通話装置との間の通信を中継する通信中継方法、通信中継プログラムおよび通信中継装置に関するものである。
【背景技術】
【0002】
PSTN(Public Switched Telephone Network:公衆電話回線網)やIP網などのネットワークに接続された各種情報機器、たとえばPC、PDA、固定電話、携帯電話、PHSなどを一人のユーザが複数台所有して、仕事の状況や通信環境などに応じて使い分けることはもはや当たり前の時代となっている。ただ、いつでもどこでも仕事ができるということは、その反面、いつどこで仕事をしているか分からないということでもあり、たとえばあるユーザと今すぐ話がしたいとき、どの機器をどう呼び出せば最もスムーズに連絡がつくか分からないという問題がある。
【0003】
そこで本出願人は、ユーザが使用する複数の機器のいずれかにかかってきた電話を、「呼転送サーバ」(具体的にはSIPサーバを想定)の転送先選択機能により、その時点で最適な機器に転送する「ユビキタスIP電話システム」を提案している(特許文献1)。上記システムにおいては、ユーザの現在位置や事前に設定されたプリファレンスにもとづいて電話の転送先が決定されるので、たとえば同一の電話番号にかかってきた電話でも、ユーザが在席中であればその自席の内線電話、外出中であれば携帯電話というように、実際に呼び出される機器はその時々で変化することになる。
【0004】
一方、本出願人は複数の無線通信装置、たとえばPHSのほかWLANもあわせて搭載する携帯電話型のデュアル端末を提案している(特許文献2)。そしてこの端末では、
・WLANの圏内にあるときは、WLANでIP網に接続(基本的には無料)
・WLANの圏外にあるときは、PHSでPSTNに接続(基本的には有料)
というように、通信環境などに応じて使用する通信装置や接続するネットワークを切り換えることで、通信コストを抑制することができる。
【0005】
しかしながら図20に示すように、上記「ユビキタスIP電話システム」において、着信端末2002が特に上記デュアル端末であった場合には、発信端末2001がPSTNを経由しないで電話をかけた場合でも、着信端末2002へは破線矢印ではなく、実線矢印すなわちPSTN経由で接続されてしまう。そして、破線矢印の場合は通話料が発生しないのに対して、実線矢印の場合は、
・S−P(SIP→PSTN)ゲートウェイ2004〜着信端末2002間の通話料
が発呼者に発生してしまう。
【0006】
これは省電力の観点から、上記デュアル端末はPHSが使える限りはもっぱらPHSで待ち受けを行い、WLANにはできるだけ電力を供給しないようにしているためである。すなわち上記端末は、PHS圏内でさえあれば、WLANの圏内か圏外かにかかわらずWLANをOFFにしている。言い換えると上記端末は、デュアル端末とはいうものの、PHS圏内での待ち受け時には実質的にPHS相当となっている。このためこれをIP網から呼び出すには、まずそのWLANをONにしてIP網に接続させ、さらにSIPサーバ2000に必要事項(IPアドレスなど)を登録させるためのしくみが必要である。
【0007】
ちなみにこのしくみの一例としては、「株式会社インターナショナルシステムリサーチ」の「PPPhone」システム(さらに詳細には、当該システムで採用されているWakeOnRingテクノロジ「PPPush」)がある。これは電源OFFの状態にあるPDAが、「WakeOnトリガー」と呼ばれる本体起動用のメッセージをPHSで受信すると、自己の電源をONにするとともにWLANでIP網に接続し、SIPサーバへ必要事項を登録するものである。
【0008】
また、たとえば図21の実線矢印で示すように、発呼者が発信端末2001からPSTN経由でIP電話をかけ、その電話がP−S(PSTN→SIP)ゲートウェイ2003およびSIPサーバ2000を経て、さらにPSTN経由で着信端末2002に転送された場合、
・発信端末2001〜P−Sゲートウェイ2003間の通話料
・S−Pゲートウェイ2004〜着信端末2002間の通話料
の両者が発呼者に発生してしまう(二重課金)。この場合は結果的に、図中実線矢印の経路でIP電話をかけるより、破線矢印の経路で普通に電話をかけたほうが安価だったことになり、上記システムを利用するメリットが減殺されてしまう。なお、この問題は発信端末2001や着信端末2002がデュアル端末でなくとも、双方ともにPSTNを利用する機器である場合に発生する。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2005−269299号公報
【特許文献2】特開2006−25009号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
まとめると、上記従来技術においては、本来負担しなくてもよいはずの通話料を発呼者が負担しなければならない場合があった。具体的には、
(1)ユビキタスIP電話システムをIP網経由で利用した場合、当該システムが着呼者をPSTN経由で呼び出したことが原因で、IP網経由で呼び出せば無料だったはずの通話に料金がかかってしまう
(2)ユビキタスIP電話システムをPSTN経由で利用した場合、当該システムが着呼者をPSTN経由で呼び出したことが原因で、当該システムを介さず直接PSTN経由で呼び出すのに比べて余分に料金がかかってしまう
などである。
【0011】
本発明は、上記に鑑みてなされたものであって、発信端末〜着信端末間の通信を相対的に最も安価な経路で中継することが可能な通信中継方法、通信中継プログラム、および通信中継装置を提供することを目的とする。
【課題を解決するための手段】
【0012】
上述した課題を解決し、目的を達成するために、本発明は第1の音声通話装置と第2の音声通話装置との間の通話を中継する処理をサーバが実行する通信中継方法、通信中継プログラム、および通信中継装置であって、前記第1の音声通話装置と前記第2の音声通話装置との接続要求を、前記サーバが、第1のネットワークを通じて前記第1の音声通話装置から受信し、受信された前記接続要求が転送されることになる第2のネットワークを、前記サーバが特定し、前記第1のネットワークと特定された第2のネットワークとが同一でない場合に、前記サーバが、前記接続要求を前記第2のネットワークを通じて前記第2の音声通話装置に送信することを要件とする。
【0013】
上記発明(後述する「かけ直し方式」)によれば、発信端末〜着信端末間で同一ネットワークを二回経由するために料金が二重に発生するような接続要求は、一方の料金が発生する前に破棄される。
【発明の効果】
【0014】
本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置は、発信端末〜着信端末間の通信を相対的に最も安価な経路で中継することができるという効果を奏する。
【図面の簡単な説明】
【0015】
【図1】本発明の実施例1にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。
【図2】本発明の実施例1にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。
【図3】本発明の実施例1にかかる通信中継装置のハードウェア構成を示す説明図である。
【図4】本発明の実施例1にかかる通信中継装置の機能的構成を示す説明図である。
【図5】本発明の実施例1にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。
【図6】本発明の実施例1にかかる着信端末102における、着信処理の手順を示すフローチャートである。
【図7】本発明の実施例2にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。
【図8】本発明の実施例2にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。
【図9】本発明の実施例2にかかる通信中継装置の機能的構成を示す説明図である。
【図10】本発明の実施例2にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。
【図11】本発明の実施例2にかかる着信端末702における、着信処理の手順を示すフローチャートである。
【図12】本発明の実施例3にかかる通信中継装置により実現される、「繋ぎ直し+かけ直し方式」の概略を示す説明図である。
【図13】本発明の実施例3にかかる通信中継装置により実現される、「繋ぎ直し+かけ直し方式」の概略を示す説明図である。
【図14】本発明の実施例3にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。
【図15】本発明の実施例3にかかる着信端末1202における、着信処理の手順を示すフローチャートである。
【図16】本発明の実施例3にかかる発信端末1201における、発信処理の手順を示すフローチャートである。
【図17】本発明の実施例4にかかる通信中継装置により実現される、「かけ直し方式」の概略を示す説明図である。
【図18】本発明の実施例4にかかる通信中継装置の機能的構成を示す説明図である。
【図19】本発明の実施例4にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。
【図20】従来技術の問題点を示す説明図である。
【図21】従来技術の他の問題点を示す説明図である。
【発明を実施するための形態】
【0016】
以下に、本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【0017】
本発明では上述した従来技術の問題点(1)(2)を解決するため、
・実施例1:コールバック方式・・・・・・問題点(1)を解決
・実施例2:繋ぎ直し方式・・・・・・・・問題点(1)を解決
・実施例3:繋ぎ直し+かけ直し方式・・・問題点(2)を解決
・実施例4:かけ直し方式・・・・・・・・問題点(2)を解決
の4方式を提案する。以下、順次説明する。
【実施例1】
【0018】
(コールバック方式)
図1および図2は、本発明の実施例1にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。発信端末101はSIP(Session Initiation Protocol)によるVoIP通話の可能な機器なら何であってもよいが、ここではたとえばVoIPアダプタを介してIP網に接続された電話機(IP電話)であるものとする。発呼者がこの発信端末101から、あらかじめ着呼者ごとに付与されている代表番号、たとえば「050−XXXX−XXXX」へ電話をかけると、当該番号を意味するSIP URI(Uniform Resource Identifier)、たとえば「sip:+81−050−XXXX−XXXX@・・・」を宛先とするINVITEリクエストが、IP網を経てSIPサーバ100へ送信される(図中(1))。なお、以下では上記URIを「バーチャルURI」と呼ぶ。
【0019】
SIPサーバ100は上述の転送先選択機能を備えており、着呼者のバーチャルURIあてのINVITEリクエストを、当該着呼者の現実のSIP URI(少なくとも一つ)のうちいずれか一つに転送する。なお、以下では上記現実のSIP URIを「着信端末URI」と呼び、そのうち転送先として選択された一つを特に「選択中URI」と呼ぶ。なお、バーチャルURIと着信端末URIとの対応関係、および着信端末URIのうちどれが選択中URIであるかは、SIPサーバ100の「転送先テーブル」に保持されている。図中、「*」印の付加された着信端末URIが選択中URIである。
【0020】
そして発信端末101からのINVITEリクエストは、SIPサーバ100でその宛先をバーチャルURIから選択中URIに付け替えられた後、選択中URIにより一意に特定される着信端末102へ転送される。ただし、選択中URIがPSTN上の識別子(具体的には電話番号)を意味するSIP URI、たとえば「tel:+81−070−XXXX−XXXX」であった場合は、上記リクエストはまずS−Pゲートウェイ104に転送(図中(2))されてPSTNの呼に変換の上、PSTN経由で着信端末102に転送(図中(3))される。このため上述のように、本来なら通話料が発生しない状況、具体的にはデュアル端末である着信端末102がWLAN圏内にあるときでも、S−Pゲートウェイ104〜着信端末102間の通話料が発生してしまう。
【0021】
ここで、選択中URIは(a)相対的に高価な(通信コストの高い)ネットワークにも安価な(通信コストの低い)ネットワークにも接続可能な機器に対応するSIP URIのうち、前者における識別子を意味するSIP URIである場合と、(b)上記以外のSIP URIである場合とがある。たとえば、PSTNにもIP網にも接続可能なデュアル端末のPHS番号を意味するSIP URIは(a)であり、一般のPHSのPHS番号を意味するSIP URIは(b)である。別の言い方をすると、PHS番号を意味するSIP URIは、上記番号がデュアル端末のPHS番号であれば(a)、一般のPHSのPHS番号であれば(b)に該当することになる。なお、以下では(b)に該当するSIP URIの種別を「通常」と呼ぶ。
【0022】
そして、発呼者が本来負担しなくてもよいはずの通話料(具体的にはS−Pゲートウェイ104〜着信端末102間の通話料)を負担しなければならなくなるのは、選択中URIが特に(a)だった場合、すなわちその種別が「通常」ではなかった場合である。そこで実施例1では、選択中URIの種別が「通常」でない場合は、SIPサーバ100からS−Pゲートウェイ104へINVITEリクエストを転送した直後に、CANCELリクエストを送信する(図中(2))ことで、S−Pゲートウェイ104から着信端末102への呼を通話料の発生前(具体的にはワンコール程度)で切断してしまう(図中(3))。
【0023】
また、SIPサーバ100は発信端末101からのINVITEリクエストを、S−Pゲートウェイ104とともにアナウンスサービス105へも転送し(図中(4))、アナウンスサービス105から発信端末101への2XX応答(成功)と、発信端末101からアナウンスサービス105へのACKリクエストとを順次転送する。これにより、発信端末101〜アナウンスサービス105間でRTPコネクションが確立されると、アナウンスサービス105から発呼者へ、着呼者からコールバックするのでいったん電話を切って待つよう指示がなされ、発信端末101からアナウンスサービス105へBYEリクエストが送信(図中(5))された時点で、発信端末101からの電話は切断される。
【0024】
一方、S−Pゲートウェイ104からいわゆる「ワン切り」された着信端末102は、WLANでIP網に接続、あるいはPHSでPSTNに接続してただちにコールバックする。もっとも、着信端末102ではコールバック先となるべき発信端末101を特定できないので(着信履歴には発信端末101ではなく、S−Pゲートウェイ104の電話番号しか残らないため)、実施例1ではSIPサーバ100の「転送元テーブル」に、着信端末102とコールバック先となる発信端末101との対応関係を保持しておくようにする。
【0025】
すなわちSIPサーバ100は、発信端末101から受信したINVITEリクエストをS−Pゲートウェイ104およびアナウンスサービス105に転送する際に、当該リクエストのToヘッダに記述されたバーチャルURI(図中(1)の「Receiver Virtual」)と、Fromヘッダに記述された発信端末101のURI(発信端末URI。同「Caller VoIP」)との組を、その保持する「転送元テーブル」に登録する。
【0026】
その後図1のように、着信端末102がWLANでIP網に接続してS−Pゲートウェイ104へコールバックした場合、着信端末102からのINVITEリクエストは、その宛先であるS−Pゲートウェイ104を通過してSIPサーバ100に転送される(図1(6))。
【0027】
したがって図1の場合、SIPサーバ100が受信するINVITEリクエストには、(a)通常のINVITEリクエスト(図中(1)など)と、(b)過去の電話をトリガーとするINVITEリクエスト(図中(6)など)との2種類があることになる。なお、以下では(a)に該当するINVITEリクエストの種別を「通常」、(b)に該当するINVITEリクエストの種別を「コールバック」と呼ぶ。そして、あるINVITEリクエストが上記のいずれであるかは、上述の転送先テーブルおよび転送元テーブルを参照することで特定できる。具体的には転送先テーブルで、上記リクエストのFromヘッダに記述されたSIP URIと対応づけられたバーチャルURIが、転送元テーブルにも登録されていれば(b)、登録されていなければ(a)である。
【0028】
そして、受信したINVITEリクエストの種別が「コールバック」だった場合、SIPサーバ100は上記リクエストの宛先を、転送元テーブルで上記バーチャルURIに対応づけられている発信端末URI(図中「Caller VoIP」)に付け替えて、発信端末101へ転送する(図1(7))。その後2XX応答(成功)とACKリクエストを経て、着信端末102〜発信端末101間でRTPコネクションが確立される(図1(8))。
【0029】
一方、図2のように、着信端末102がPHSでPSTNに接続してS−Pゲートウェイ104へコールバックした場合(図2(6))、S−Pゲートウェイ104を宛先とするINVITEリクエストがS−Pゲートウェイ104からSIPサーバ100に送信される(図2(7))。そしてSIPサーバ100が、上記と同様にコールバックか否かを判定し、コールバックの場合は上記リクエストの宛先を、転送元テーブルから検索した発信端末URIに付け替えて転送する(図2(8))。その後2XX応答(成功)とACKリクエストを経て、S−Pゲートウェイ104〜発信端末101間でRTPコネクションが確立される(図2(9))。なお、図1および図2のP−Sゲートウェイ103はなくても構わない(P−Sゲートウェイ103がなくても実施例1の発明は実施可能である)が、ここでは後述する他の実施例との比較のために示している。
【0030】
次に、図3は本発明の実施例1にかかる通信中継装置(具体的には図1に示したSIPサーバ100)のハードウェア構成を示す説明図である。図中、CPU301は装置全体の制御を司る。ROM302はブートプログラムなどを記憶している。RAM303はCPU301のワークエリアとして使用される。
【0031】
HDD304は、CPU301の制御にしたがってHD305に対するデータのリード/ライトを制御する。HD305は、HDD304の制御にしたがって書き込まれたデータを記憶する。FDD306は、CPU301の制御にしたがってFD307に対するデータのリード/ライトを制御する。FD307は、FDD306の制御にしたがって書き込まれたデータを記憶する。なお、FD307は着脱可能な記録媒体の一例であり、FD307の代わりにCD−ROM(CD−R、CD−RW)、MO、DVD(Digital Versatile Disk)、メモリーカードなどであってもよい。
【0032】
ネットワークI/F308はLAN/WANなどのネットワークに接続され、当該ネットワークと装置内部とのデータの送受信を司る。また、バス300は上記各部を接続する。なお、上記のほか本装置はディスプレイ、マウス、キーボードなどのコンソール類を備えていてもよい。
【0033】
次に、図4は本発明の実施例1にかかる通信中継装置(具体的には図1に示したSIPサーバ100)の機能的構成を示す説明図、図5は当該装置における各種リクエストの処理手順を示すフローチャートである。図4中の各部の機能は、図5のフローチャートにおいて順次説明する。
【0034】
SIPサーバ100のプロキシ402がINVITEリクエストを受信すると(ステップS501:Yes)、当該リクエストはいったん転送先特定部403に出力され、転送先特定部403のINVITE種別特定部403aが、当該リクエストの種別を特定する。そして種別が「通常」だった場合は(ステップS502:Yes)、転送先特定部403の転送先種別特定部403bが、上記リクエストの宛先のバーチャルURIに対応づけられた選択中URIの種別を特定する。
【0035】
そして、選択中URIの種別が「通常」でなかった場合、たとえばデュアル端末のPHS番号を意味するSIP URIだった場合は(ステップS503:No)、転送先特定部403はプロキシ402から入力したINVITEリクエスト、選択中URI、およびアナウンスサービス105のSIP URIをリクエスト生成部404に出力する。
【0036】
そしてリクエスト生成部404が、
・選択中URIを宛先とするINVITEリクエスト
・選択中URIを宛先とするCANCELリクエスト
・アナウンスサービス105のSIP URIを宛先とするINVITEリクエスト
の3つを生成し(ステップS504)、これらがプロキシ402により順次転送される(ステップS505)。なお、選択中URIを宛先とするCANCELリクエストは、当該URIを宛先とするINVITEリクエストを受けて、S−Pゲートウェイ104が着信端末102を呼び出した後に転送されるものとする。
【0037】
また、転送先特定部403は転送元テーブル更新部405に指示して、プロキシ402から入力したINVITEリクエストのバーチャルURIと発信端末URIとの組を転送元テーブル401に登録させる(ステップS506)。
【0038】
一方、選択中URIの種別が「通常」だった場合は(ステップS503:Yes)、転送先特定部403はプロキシ402から入力したINVITEリクエストと選択中URIとをリクエスト生成部404に出力し、リクエスト生成部404が上記リクエストの宛先を上記URIで置換することで、上記URIを宛先とするINVITEリクエストを生成する(ステップS507)。次に、リクエスト生成部404が上記リクエストをプロキシ402に出力し、プロキシ402が上記リクエストの転送(ステップS508)後、応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS509)。
【0039】
一方、プロキシ402から入力したINVITEリクエストの種別が「コールバック」だった場合(ステップS502:No)、すなわち当該リクエストが以前ステップS501〜S506で転送された他のINVITEリクエストをトリガーとしてなされたものである場合は、転送先特定部403は当該リクエストと、当該他のリクエストの転送時に転送元テーブル401に登録された発信端末URIとをリクエスト生成部404に出力する。そしてリクエスト生成部404が、上記リクエストの宛先を上記URIで置換することで、上記URIを宛先とするINVITEリクエストを生成し(ステップS510)、これがプロキシ402により発信端末101へ転送される(ステップS511)。
【0040】
また、転送先特定部403は転送元テーブル更新部405に指示して、トリガーとなった他のINVITEリクエストの転送時に転送元テーブル401に登録された、バーチャルURIと発信端末URIとの組を削除させる(ステップS512)。その後はプロキシ402が、応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS509)。なお、INVITEリクエスト以外のリクエストを受信した場合は(ステップS501:No)、SIPサーバ100は受信したリクエストに対応するその他の処理を行う(ステップS513)。
【0041】
次に、図6は本発明の実施例1にかかる着信端末102における、着信処理の手順を示すフローチャートである。PHSによる待ち受け中にS−Pゲートウェイ104から着信があった場合(ステップS601:Yes、ステップS602:Yes。なお、S−Pゲートウェイ104からの着信かどうかは電話番号により特定できる)、着信端末102は着信音は出力せずに呼の切断を待つとともに、OFFになっているWLANをONにして(ステップS603)WLANの圏内/圏外を判定し(ステップS604)、この結果にもとづいてWLAN/PHSのいずれかを通信手段として選択する。なお、上記判定結果のほか通信コストや通話の品質、あらかじめ設定されているプリファレンスなどにもとづいて、いずれかの通信手段を選択するようにしてもよい。
【0042】
そしてWLANを選択した場合は(ステップS605:Yes)、着信端末102はWLANでIP網に接続し、S−Pゲートウェイ104あてのINVITEリクエストを送信(ステップS606)することで、通常のSIP通話(ステップS607)を開始する。そして通話終了時には、着信時にONにしたWLANを再びOFFにする(ステップS608)。なお同図では省略しているが、実際にはINVITEリクエストの前に、SIPサーバ100へREGISTERリクエストを送信する。
【0043】
一方、PHSを選択した場合は(ステップS605:No)、着信端末102はONにしたWLANを再びOFFにする(ステップS609)。次にPHSでPSTNに接続して、S−Pゲートウェイ104の電話番号に発呼(ステップS610)することで、通常のPHS通話(ステップS611。なお、S−Pゲートウェイ104から先はSIP通話となる)を開始する。また、S−Pゲートウェイ104以外から電話がかかってきた場合には着信音を出力し(ステップS602:No、ステップS612)、着呼者が電話に出た後は通常のPHS通話となる(ステップS611)。
【0044】
図1および図2と、図5および図6とを対応づけて説明すると、まず図1の場合、発信端末101からの電話の転送先が「通常」でないので、SIPサーバ100はS−Pゲートウェイ104に指示して、通話料のかからないいわゆる「ワン切り」で着信端末102を呼び出させるとともに、発信端末101をいったんアナウンスサービス105に接続する(図5ステップS501〜S506)。
【0045】
その後、着信端末102がWLANでIP網に接続してINVITEリクエストを返してきた場合(図6ステップS601〜S606)、あるいは着信端末102がPHSでPSTNに接続してS−Pゲートウェイ104を発呼(図6ステップS601〜S605、S609〜S610)した結果、S−Pゲートウェイ104がINVITEリクエストを返してきた場合のいずれも、SIPサーバ100は上記リクエストがコールバックであることを特定して、その宛先を発信端末101に付け替えの上で転送する(図5ステップS501〜S502、S510〜S512)。
【0046】
そして発信端末101から2XX応答が返ってくると、SIPサーバ100は当該応答を着信端末102あるいはS−Pゲートウェイ104に転送するとともに、着信端末102あるいはS−Pゲートウェイ104からACKリクエストがあると、当該リクエストを発信端末101に転送する(図5ステップS509)。
【0047】
以上説明した実施例1によれば、まず図1の場合、唯一PSTNを利用する(3)でもワン切りしているため、(1)〜(8)の全体を通じて通話料が発生しない。通信経路は図20の点線矢印と同等になり(ただしコールバックのため、矢印の向きは逆となる)、従来技術の実線矢印に比べて、S−Pゲートウェイ2004〜着信端末2002間の通話料が削減できていることになる。
【0048】
一方、図2の場合は(3)および(6)でPSTNを利用しており、前者はワン切りのため無料であるが、後者は有料である。通信経路は図20の実線矢印と同等であり(ただしコールバックのため、矢印の向きは逆となる)、通話料は従来技術と同様に発生する。もっとも課金先は発呼者でなく着呼者となるため、無料で電話をかけることはできてもかかってきた電話を無料にすることはできないという、デュアル端末の従来の弱点を補うことができる。
【0049】
ただ、実施例1では発呼者に違和感を覚えさせてしまう(かけた電話をいったん切らなければならないため)ことのほか、発呼者と着呼者が実際に通話できるようになるまでの時間もかかってしまう。そこで、実施例1のように着呼者からコールバックするのでなく、次に説明する実施例2のように、従来のやり方で着呼者につないだのでは相対的に高価な通信経路Aとなってしまう発呼者からの電話を、相対的に安価な通信経路Bで着呼者に繋ぎ直すようにしてもよい。
【実施例2】
【0050】
(繋ぎ直し方式)
図7および図8は、本発明の実施例2にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。バーチャルURIあてのINVITEリクエストを発信端末701から受信(図中(1))すると、SIPサーバ700は転送先テーブルから、当該バーチャルURIに対応づけられた選択中URIを検索し、当該リクエストの宛先を当該選択中URIに付け替えて転送する。そして、この選択中URIがデュアル端末のPHS番号を意味するSIP URIだった場合、上記リクエストはS−Pゲートウェイ704に転送(図中(2))されてPSTNの呼に変換の上、PSTN経由で着信端末702に転送(図中(3))される。そして、ここまでは実施例1のコールバック方式と同様である。
【0051】
S−Pゲートウェイ704から呼び出された着信端末702は、通信手段としてWLAN/PHSのいずれかを選択し、WLANを選択した場合、図7のようにSIPサーバ700へREGISTERリクエストを送信する(図中(4))。
【0052】
したがって図7の場合、SIPサーバ700が受信するREGISTERリクエストには、(a)通常のREGISTERリクエストと、(b)過去の電話をトリガーとするREGISTER(図中(4)など)との2種類があることになる。そして、あるREGISTERリクエストが上記のいずれであるかは、上述の転送先テーブルおよび転送元テーブルを参照することで特定できる。具体的には転送先テーブルで、上記リクエストのToヘッダおよびFromヘッダに記述されたSIP URI(IPアドレスを登録されるSIP URI)と対応づけられたバーチャルURIが、転送元テーブルにも登録されていれば(b)、登録されていなければ(a)である。なお、以下では(a)に該当するREGISTERリクエストの種別を「通常」と呼ぶ。
【0053】
そして、受信したREGISTERリクエストの種別が「通常」でなかった場合、SIPサーバ700はS−Pゲートウェイ704にCANCELリクエストを送信(図中(5))することで、S−Pゲートウェイ704から着信端末702への呼を切断させる(図中(6))。またその一方で、発信端末701から受信(図中(1))したINVITEリクエストの宛先を、着信端末702がIPアドレスを登録(図中(4))したSIP URIに付け替えて転送する(図中(7))。そして着信端末702から2XX応答(成功)を受信すると(図中(8))、当該応答を発信端末701へ転送し(図中(9))、さらにACKリクエストの転送を経て、発信端末701〜着信端末702間でRTPコネクションが確立される(図中(10))。
【0054】
一方、S−Pゲートウェイ704から呼び出された着信端末702が、通信手段としてPHSを選択した場合は、着呼者が電話に出た時点で、図8のように着信端末702からPSTN経由で応答信号が返される(図中(4))。そして上記信号を受信したS−Pゲートウェイ704は、SIPサーバ700へ2XX応答を送信し(図中(5))、SIPサーバ700がさらに発信端末701へ当該応答を転送する(図中(6))。その後ACKリクエストの転送を経て、発信端末701〜S−Pゲートウェイ704間でRTPコネクションが確立される(図中(7))。
【0055】
本発明の実施例2にかかる通信中継装置(具体的には図7および図8に示したSIPサーバ700)のハードウェア構成は、図3に示した実施例1のそれと同様であるので説明を省略する。図9は上記装置の機能的構成を示す説明図、図10は上記装置における各種リクエストの処理手順を示すフローチャートである。図9中の各部の機能は、図10のフローチャートにおいて順次説明する。
【0056】
SIPサーバ700のプロキシ902がINVITEリクエストを受信すると(ステップS1001:Yes)、当該リクエストはいったん転送先特定部903に出力され、転送先特定部903の転送先種別特定部903aが、転送先テーブル900を参照して、当該リクエストの宛先のバーチャルURIに対応づけられた選択中URIの種別を特定する。
【0057】
そして、選択中URIの種別が「通常」でなかった場合(ステップS1002:No)、転送元テーブル更新部905に指示して、上記リクエストのバーチャルURIと発信端末URIとの組を転送元テーブル901に登録させる(ステップS1003)。なお、選択中URIの種別が「通常」だった場合は(ステップS1002:Yes)、ステップS1003の処理は省略される。
【0058】
そしていずれの場合も、上記リクエストと選択中URIとをリクエスト生成部904に出力し、リクエスト生成部904が上記リクエストの宛先を上記URIで置換することで、上記URIを宛先とするINVITEリクエストを生成する(ステップS1004)。次に、プロキシ902が上記リクエストの転送(ステップS1005)後、応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS1006)。
【0059】
一方、SIPサーバ700のレジストラ906がREGISTERリクエストを受信すると(ステップS1007:Yes)、通常のSIP登録処理(ステップS1008)の後、レジストラ906のREGISTER種別特定部906aが、上記リクエストの種別を特定する。
【0060】
そして、種別が「通常」だった場合は(ステップS1009:Yes)そのままステップS1001に戻る。一方、種別が「通常」でなかった場合(ステップS1009:No)、すなわち上記リクエストが以前ステップS1001〜S1006で転送されたINVITEリクエストをトリガーとしてなされたものである場合は、レジストラ906は当該INVITEリクエスト、当該INVITEリクエストの転送先となった選択中URI、および当該INVITEリクエストの転送時に転送元テーブル901に登録された発信端末URIをリクエスト生成部904に出力する。
【0061】
そしてリクエスト生成部904が、
・発信端末URIを宛先とするINVITEリクエスト
・選択中URIを宛先とするCANCELリクエスト
の2つを生成し(ステップS1010)、これらがプロキシ902により順次転送される(ステップS1011)。
【0062】
また、レジストラ906は転送元テーブル更新部905に指示して、トリガーとなったINVITEリクエストの転送時に転送元テーブル901に登録された、バーチャルURIと発信端末URIとの組を削除させる(ステップS1012)。その後はプロキシ902が、応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS1006)。なお、INVITEリクエストやREGISTERリクエスト以外のリクエストを受信した場合は(ステップS1001:No、ステップS1007:No)、SIPサーバ700は受信したリクエストに対応するその他の処理を行う(ステップS1013)。
【0063】
次に、図11は本発明の実施例2にかかる着信端末702における、着信処理の手順を示すフローチャートである。PHSによる待ち受け中にS−Pゲートウェイ704から着信があった場合(ステップS1101:Yes、ステップS1102:Yes)、着信端末702はOFFになっているWLANをONにして(ステップS1103)WLANの圏内/圏外を判定し(ステップS1104)、この結果にもとづいてWLAN/PHSのいずれかを通信手段として選択する。なお、上記判定結果のほか通信コストや通話の品質、あらかじめ設定されているプリファレンスなどにもとづいて、通信手段を選択するようにしてもよい。
【0064】
そしてWLANを選択した場合は(ステップS1105:Yes)、着信端末702はWLANでIP網に接続し、SIPサーバ700へREGISTERリクエストを送信する(ステップS1106)。一方、PHSを選択した場合は(ステップS1105:No)、ONにしたWLANをOFFにするとともに(ステップS1107)着信音を出力し(ステップS1108)、着呼者が電話に出た後は通常のPHS通話となる(ステップS1109)。なお、PHSによる待ち受け中にS−Pゲートウェイ704以外から着信があった場合(ステップS1101:Yes、ステップS1102:No)も、着信端末702は着信音を出力し(ステップS1108)、着呼者が電話に出た後は通常のPHS通話となる(ステップS1109)。
【0065】
また、ステップS1103でONにしたWLANへINVITEリクエストが着信すると(ステップS1101:No、ステップS1110:Yes)、着信端末702は着信音を出力し(ステップS1111)、着呼者が電話に出た後は通常のSIP通話となる(ステップS1112)。なお通話終了時には、着信時にONにしたWLANを再びOFFにする(ステップS1113)。
【0066】
図7および図8と、図10および図11とを対応づけて説明すると、まず図7の場合、SIPサーバ700は発信端末701からの電話を、まずPSTN経由で着信端末702に転送するが(図10ステップS1001〜S1005)、着信端末702からREGISTERリクエストがあると(図11ステップS1101〜S1106)、それは取り消して次はIP網経由で着信端末702に転送する(図10ステップS1007〜S1012)。そして着信端末702から2XX応答があると、当該応答を発信端末701に転送するとともに、発信端末701からACKリクエストがあると、当該リクエストを着信端末702に転送する(図10ステップS1006)。
【0067】
一方図8の場合、着信端末702がS−Pゲートウェイ704に応答信号を返すと(図11ステップS1101〜S1105、S1107〜S1109)、S−Pゲートウェイ704がSIPサーバ700に2XX応答を返すので、SIPサーバ700は当該応答を発信端末701に転送するとともに、発信端末701からACKリクエストがあると、当該リクエストをS−Pゲートウェイ704に転送する(図10ステップS1006)。
【0068】
なお、図7の場合、SIPサーバ700が着信端末702からのREGISTERリクエストを受信する前に、S−Pゲートウェイ704から3XX〜6XX応答を受信してしまうと、当該応答が発信端末701に転送された時点で発信端末701からの電話は切断されてしまい、その後に着信端末702が登録してきても発信端末701と接続することができなくなる。そこで図10のステップS1006における処理を、SIPサーバ700がS−Pゲートウェイ704から3XX〜6XX応答を受信した場合は、所定時間内に着信端末702からREGISTERリクエストがないことを条件として発信端末701へ転送するよう修正してもよい。すなわちS−Pゲートウェイ704から接続失敗が通知されてきても、すぐには発信端末701へ通知せず、上記所定時間だけは着信端末702からの登録を待つようにする。
【0069】
以上説明した実施例2によれば、まず図7の場合、(3)でS−Pゲートウェイ704がかけた電話は着信端末702の応答前に切断されるので、(1)〜(10)の全体を通じて通話料が発生しない。通信経路は図20の点線矢印と同一になり、従来技術の実線矢印に比べて、S−Pゲートウェイ2004〜着信端末2002間の通話料が削減できていることになる。一方、図8の場合は図20の実線矢印と同一、すなわち上述のユビキタスIP電話システムにおいて、IP端末から代表番号へかけた電話が非IP端末へ転送されるケースと同一であり、S−Pゲートウェイ2004〜着信端末2002間の通話料が発呼者に課金される。
【0070】
なお、図7で着信端末702がSIPサーバ700へ送信するREGISTERリクエストは、本来的にはSIP登録のためのリクエストであるが、実施例2ではこれを一種の接続要求、すなわち発信端末701とIP網経由で接続すべき旨の着信端末702からの要求とみなし、この要求に応じてSIPサーバ700が、いったんPSTN経由で転送した電話をIP網経由で転送し直していると言うこともできる。逆に言うと、上記接続要求は必ずしも着信端末702からのREGISTERリクエストでなければならないわけではなく、着信端末702がWLANで着信可能な状態になったことを示す何らかの通知(必ずしも着信端末702自身からの通知でなくともよい)などであってもよい。
【実施例3】
【0071】
(繋ぎ直し+かけ直し方式)
図12および図13は、本発明の実施例3にかかる通信中継装置により実現される、「繋ぎ直し+かけ直し方式」の概略を示す説明図である。上述した実施例2はIP端末(たとえばIP電話)から電話をかける場合であるが、実施例3は非IP端末、具体的には従来の電話機や、WLAN圏外にあるときのデュアル端末などから電話をかける場合である。そして図21に示したように、発信端末2001がPSTN経由で発呼し、着信端末2002もPSTN経由で着呼すると、発信端末2001〜P−Sゲートウェイ2003間の通話料と、S−Pゲートウェイ2004〜着信端末2002間の通話料とが二重に発生してしまう。
【0072】
そこで実施例3では、図12および図13に示すように、発信端末1201がPSTN経由で発呼し(図中(1))、P−Sゲートウェイ1203からSIPサーバ1200を経てINVITEリクエストを転送(図中(2)(3))されたP−Sゲートウェイ1204が、さらにPSTN経由で発呼する(図中(4))場合、INVITEリクエストの転送直後にSIPサーバ1200からS−Pゲートウェイ1204へCANCELリクエストを送信する(図中(3))ことで、S−Pゲートウェイ1204から着信端末1202への呼を通話料の発生前(具体的にはワンコール程度)で切断してしまう(図中(4))。
【0073】
そして着信端末1202は、通信手段としてWLANを選択した場合、図12に示すようにSIPサーバ1200へREGISTERリクエストを送信する(図中(5))。SIPサーバ1200は、上記リクエストの種別が「通常」でなかった場合、P−Sゲートウェイ1203から受信(図中(2))したINVITEリクエストの宛先を、着信端末1202がIPアドレスを登録(図中(5))したSIP URIに付け替えて転送する(図中(6))。
【0074】
そして着信端末1202から2XX応答を受信すると(図中(7))、当該応答をP−Sゲートウェイ1203へ転送し(図中(8))、さらにACKリクエストの転送を経て、P−Sゲートウェイ1203〜着信端末1202間でRTPコネクションが確立される(図中(9))。その後、P−Sゲートウェイ1203から発信端末1201へ、PSTN経由で応答信号を返す(図中(10))。
【0075】
一方、着信端末1202は通信手段としてPHSを選択した場合、図13に示すように、S−Pゲートウェイ1204から電話がかかってきた(図中(4))後は続いて発信端末1201から電話がかかってくるのを待つ(自分からは何もしない)。S−Pゲートウェイ1204からの電話はワン切りされてしまうのでPHSで応答しようにも間に合わず、しかもWLANも使えない/使わないので、着信端末1202としてはPHSでS−Pゲートウェイ1204にコールバックするしかないのであるが、S−Pゲートウェイ1204からSIPサーバ1200を経てP−Sゲートウェイ1203へINVITEリクエストが転送され、P−Sゲートウェイ1203からPSTN経由で発信端末1201が呼び出されると、上述の二重課金の問題がここでも発生してしまう。
【0076】
これを避けるため実施例3では、着信端末1202が何もしない代わりに、発信端末1201が電話を自動的にかけ直すようにする。すなわち実施例3にかかる発信端末1201は、着呼者の代表番号あてにかけた電話が所定時間内につながらない(所定時間内にP−Sゲートウェイ1203から応答信号が返ってこない)ときは、着呼者の別の電話番号を一つ選択して電話をかけ直す。なお、この別の電話番号はあらかじめ発信端末1201に保持しているのでも、あるいはSIPサーバ1200などからリアルタイムに取得するのでもよい。
【0077】
そしてこの別の電話番号の中にデュアル端末のPHS番号があれば、S−Pゲートウェイ704からの着信後しばらく経ってから、着信端末1202へ今度は発信端末1201から直接電話がかかってくることになる(図中(5))。そして着信端末1202が応答信号を返した(図中(6))後は、通常のPHS通話となる。
【0078】
本発明の実施例3にかかる通信中継装置(具体的には図12および図13に示したSIPサーバ1200)のハードウェア構成は、図3に示した実施例1のそれと同様であるので説明を省略する。また上記装置の機能的構成は、図9に示した実施例2のそれとほぼ同様であり、異なる点は図14のフローチャートにおいて順次説明する。
【0079】
図14は、上記装置における各種リクエストの処理手順を示すフローチャートである。図10に示した実施例2のそれとの差異は、CANCELリクエストの生成・転送処理が、図10ではREGISTERリクエスト受信時の処理ループ内にある(ステップS1010・S1011)のに対して、図14では当該リクエストのトリガーとなったINVITEリクエスト受信時の処理ループ内にある(ステップS1404・S1405)点である(なお、INVITEリクエストやREGISTERリクエスト以外のリクエストを受信した場合は、SIPサーバ1200は受信したリクエストに対応するその他の処理を行う(ステップS1401:No、ステップS1409:No、ステップS1415))。
【0080】
すなわち実施例3にかかるリクエスト生成部904は、SIPサーバ1200が受信したINVITEリクエストについて、転送先種別特定部903aで特定された選択中URIの種別が「通常」でなかった場合、当該URIを宛先とするINVITEリクエストおよびCANCELリクエストの2つを生成し、これらがプロキシ902により順次転送される(ステップS1401〜S1405)。なお、選択中URIの種別が「通常」だった場合は、当該URIを宛先とするINVITEリクエストを生成し、これがプロキシ902により転送された後は、プロキシ902が応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS1401〜S1402、S1406〜S1408)。
【0081】
また、実施例3にかかるリクエスト生成部904は、SIPサーバ1200が受信したREGISTERリクエストについて、REGISTER種別特定部906aにより特定されたその種別が「通常」でなかった場合、IPアドレスが登録されたSIP URIを宛先とするINVITEリクエストを生成し、これがプロキシ902により着信端末1202へ転送される(ステップS1409〜S1414)。
【0082】
次に、図15は本発明の実施例3にかかる着信端末1202における、着信処理の手順を示すフローチャートである。図中ステップS1501〜S1513のそれぞれにおける処理は、図11に示したステップS1101〜S1113のそれぞれにおける処理と同一である。ただし実施例3では、着信端末1202が通信手段としてPHSを選択し、WLANをOFFにした(ステップS1505:No、ステップS1507)時点では、S−Pゲートウェイ1204からの呼は切断されていてPHS通話が不可能なため、ステップS1507の後そのままステップS1501に戻っている。
【0083】
次に、図16は本発明の実施例3にかかる発信端末1201における、発信処理の手順を示すフローチャートである。発呼者から特定の電話番号、たとえば着呼者の代表番号に対する発呼指示があると(ステップS1601:Yes)、発信端末1201はPSTN経由で当該番号に発呼する(ステップS1602)。上記呼はP−Sゲートウェイ1203でINVITEリクエストに変換の上、SIPサーバ1200に転送され、SIPサーバ1200から2XX応答が返されると、さらにP−Sゲートウェイ1203から発信端末1201へ応答信号が返され(ステップS1603:Yes)、その後は通常の音声通話となる(ステップS1604)。
【0084】
そして、発信端末1201は発呼から所定時間だけ上記信号を待ち(ステップS1603:No、ステップS1605:No)、当該時間が経過してもP−Sゲートウェイ1203から応答がない場合(ステップS1603:No、ステップS1605:Yes)、上記着呼者にまだ発呼していない他の電話番号があれば(ステップS1606:Yes)、その中から一つを選択の上(ステップS1607)当該番号へ発呼する(ステップS1602)。なお、着呼者のすべての電話番号を発呼して、それでも応答がない場合は(ステップS1606:No)、その時点で処理を終了する。
【0085】
図12および図13と、図14〜図16とを対応づけて説明すると、まず図12の場合、SIPサーバ1200は着信端末1202からのREGISTERリクエストを待たずに、そのトリガーとなるINVITEリクエストをキャンセルし(図14ステップS1401〜S1405)、着信端末1202からREGISTERリクエストがあると(図15ステップS1501〜S1506)、IPアドレスを登録されたSIP URIへ発信端末1201からのINVITEリクエストを転送する(図14ステップS1409〜S1414)。
【0086】
一方図13の場合、SIPサーバ1200がINVITEリクエストをキャンセルする(図14ステップS1401〜S1405)結果、P−Sゲートウェイ1203からの応答信号がないまま所定時間が経過するので、発信端末1201は着呼者の他の電話番号、ここではデュアル端末のPHS番号を選択して電話をかけ直す(図16ステップS1601〜S1607)。
【0087】
以上説明した実施例3によれば、図12の場合も図13の場合も、図21のような通信経路となる電話はSIPサーバ1200の制御によって常にワン切り(すなわち通話料の発生前に切断)されるので、上述の二重課金が発生しない。
【0088】
ただ、WLANの使える場所がPHSの使える場所に比べてまだまだ限られており、そもそもデュアル端末もまだ普及が始まったばかりである現状から、実際には図12のようにSIPサーバ1200が電話を繋ぎ直すのでなく、図13のように発信端末1201が電話をかけ直すことになるケースがほとんどと考えられる。そして図13の場合は、図中(3)(4)がなくても特に支障がない。そこで実施例3の「繋ぎ直し+かけ直し方式」を、次に説明する実施例4の「かけ直し方式」のように簡略化してしまってもよい。
【実施例4】
【0089】
(かけ直し方式)
図17は、本発明の実施例4にかかる通信中継装置により実現される、「かけ直し方式」の概略を示す説明図である。図示するように実施例4では、二重課金の原因となるINVITEリクエスト、具体的にはP−Sゲートウェイ1703からSIPサーバ1700を経てS−Pゲートウェイ1704に転送されることになるINVITEリクエスト(図中(2))を、SIPサーバ1700で破棄してしまい、その先へ転送しないようにする。その結果、発呼から所定時間が経過してもP−Sゲートウェイ1703から応答信号が返ってこないので、発信端末1701は着呼者の他の電話番号、たとえばデュアル端末のPHS番号を選択して電話をかけ直し(図中(3))、着信端末1702から応答信号が返ってきた(図中(4))後は通常のPHS通話となる。
【0090】
本発明の実施例4にかかる通信中継装置(具体的には図17に示したSIPサーバ1700)のハードウェア構成は、図3に示した実施例1のそれと同様であるので説明を省略する。図18は上記装置の機能的構成を示す説明図、図19は上記装置における各種リクエストの処理手順を示すフローチャートである。図18中の各部の機能は、図19のフローチャートにおいて順次説明する。
【0091】
SIPサーバ1700のプロキシ1801がINVITEリクエストを受信すると(ステップS1901:Yes)、当該リクエストはいったん転送先特定部1802に出力され、転送先特定部1802の転送可否判定部1802aが、転送先テーブル1800を参照して当該リクエストの転送可否を判定する(ステップS1902)。具体的には、S−Pゲートウェイ1704に転送されることになるINVITEリクエストで、そのToヘッダにもFromヘッダにも電話番号(PSTN上での識別子)を意味するSIP URIが記述されることになる場合、すなわち上記リクエストがSIPサーバ1700の前にも後にもPSTNを経由することになる場合は転送不可、それ以外の場合は転送可とする。
【0092】
そして転送不可の場合は(ステップS1902:No)、ステップS1901に戻って他のリクエストの受信待ちとなる一方、転送可の場合は(ステップS1902:Yes)リクエスト生成部1803で、上記リクエストの宛先を転送先テーブル1800の選択中URIに付け替えることで、当該URIあてのINVITEリクエストを生成する(ステップ1903)。そしてこれがプロキシ1801により転送(ステップS1904)された後は、プロキシ1801が応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS1905)。
【0093】
なお、INVITEリクエスト以外のリクエストを受信した場合は(ステップS1901:No)、SIPサーバ1700は受信したリクエストに対応するその他の処理を行う(ステップS1906)。
【0094】
なお、実施例4の着信端末1702はPSTNでの着呼が可能な機器であれば何であってもよく、当該装置における処理も従来技術と同一である。また、実施例4の発信端末1701もPSTNでの発呼が可能な機器であれば何であってもよいが、実施例3の発信端末1201と同様、図16の手順により、所定時間以上電話がつながらないときは他の番号へ電話をかけ直す機能を備えているものとする。
【0095】
以上説明した実施例4によれば、転送すると二重課金が発生するようなINVITEリクエストはSIPサーバ1700どまりとなり、発信端末1701は別の経路で電話をかけ直すことになるため、二重課金が発生しない。より一般的に言えば、相対的に高価な通信経路Aと安価な通信経路Bとがあった場合に、先にA経由で電話がかかってきたときは経路上のどこか(たとえば実施例4のようにSIPサーバ1700)でそれを破棄し、あらためてB経由で電話をかけさせるので、最終的に電話がつながったときの通信経路は常に最も安価なものとなる。
【0096】
もっとも、上記では図21の実線矢印のような経路による通話は、破線矢印のような経路による通話より割高であることを前提としたが、発信端末2001と着信端末2002との機器の組み合わせによって通話料は異なるため、二重課金が発生するとしても実線矢印のほうが破線矢印より安価となる場合もある。そしてその場合は、たとえば発信端末2001から点線矢印の経路で電話がかかってきても、着信端末2002で着信を拒否し、あらためて実線矢印の経路で電話をかけさせるようにしてもよい。
【0097】
なお、上述した実施例1および2では発信端末101/701がIP端末、実施例3および4では発信端末1201/1701が非IP端末であることをそれぞれ前提としたが、現実のSIPサーバが受信するINVITEリクエストの中には、(a)発信端末自身が発信したINVITEリクエストと、(b)発信端末からの呼を変換してP−Sゲートウェイが転送してきたINVITEリクエストとが混在している。
【0098】
そのため実際には、たとえば実施例2のSIPサーバ700と実施例3のSIPサーバ1200の双方の機能を併せ持つSIPサーバを用意し、(a)を受信したときは図10の手順、(b)を受信したときは図14の手順により処理するようにする。あるいは、実施例1のSIPサーバ100と実施例4のSIPサーバ1700の双方の機能を併せ持つSIPサーバを用意し、(a)を受信したときは図5の手順、(b)を受信したときは図19の手順により処理するようにしてもよい。
【産業上の利用可能性】
【0099】
以上のように、本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置は、発信端末〜着信端末間に複数の通信経路がある場合の最適な経路の選択に有用であり、特に、相対的に安価な通信経路が何らかの事情(たとえば省電力など)で事実上使用不能となっているケースに適している。
【符号の説明】
【0100】
100,700,1200,1700 SIPサーバ
101,701,1201,1701 発信端末
102,702,1202,1702 着信端末
103,703,1203,1703 P−Sゲートウェイ
104,704,1204,1704 S−Pゲートウェイ
105 アナウンスサービス
300 バス
301 CPU
302 ROM
303 RAM
304 HDD
305 HD
306 FDD
307 FD
308 ネットワークI/F
400,900,1800 転送先テーブル
401,901 転送元テーブル
402,902,1801 プロキシ
403,903,1802 転送先特定部
403a INVITE種別特定部
403b,903a 転送先種別特定部
404,904,1803 リクエスト生成部
405,905 転送先テーブル更新部
906 レジストラ
906a REGISTER種別特定部
1802a 転送可否判定部
【技術分野】
【0001】
本発明は、第1の音声通話装置と第2の音声通話装置との間の通信を中継する通信中継方法、通信中継プログラムおよび通信中継装置に関するものである。
【背景技術】
【0002】
PSTN(Public Switched Telephone Network:公衆電話回線網)やIP網などのネットワークに接続された各種情報機器、たとえばPC、PDA、固定電話、携帯電話、PHSなどを一人のユーザが複数台所有して、仕事の状況や通信環境などに応じて使い分けることはもはや当たり前の時代となっている。ただ、いつでもどこでも仕事ができるということは、その反面、いつどこで仕事をしているか分からないということでもあり、たとえばあるユーザと今すぐ話がしたいとき、どの機器をどう呼び出せば最もスムーズに連絡がつくか分からないという問題がある。
【0003】
そこで本出願人は、ユーザが使用する複数の機器のいずれかにかかってきた電話を、「呼転送サーバ」(具体的にはSIPサーバを想定)の転送先選択機能により、その時点で最適な機器に転送する「ユビキタスIP電話システム」を提案している(特許文献1)。上記システムにおいては、ユーザの現在位置や事前に設定されたプリファレンスにもとづいて電話の転送先が決定されるので、たとえば同一の電話番号にかかってきた電話でも、ユーザが在席中であればその自席の内線電話、外出中であれば携帯電話というように、実際に呼び出される機器はその時々で変化することになる。
【0004】
一方、本出願人は複数の無線通信装置、たとえばPHSのほかWLANもあわせて搭載する携帯電話型のデュアル端末を提案している(特許文献2)。そしてこの端末では、
・WLANの圏内にあるときは、WLANでIP網に接続(基本的には無料)
・WLANの圏外にあるときは、PHSでPSTNに接続(基本的には有料)
というように、通信環境などに応じて使用する通信装置や接続するネットワークを切り換えることで、通信コストを抑制することができる。
【0005】
しかしながら図20に示すように、上記「ユビキタスIP電話システム」において、着信端末2002が特に上記デュアル端末であった場合には、発信端末2001がPSTNを経由しないで電話をかけた場合でも、着信端末2002へは破線矢印ではなく、実線矢印すなわちPSTN経由で接続されてしまう。そして、破線矢印の場合は通話料が発生しないのに対して、実線矢印の場合は、
・S−P(SIP→PSTN)ゲートウェイ2004〜着信端末2002間の通話料
が発呼者に発生してしまう。
【0006】
これは省電力の観点から、上記デュアル端末はPHSが使える限りはもっぱらPHSで待ち受けを行い、WLANにはできるだけ電力を供給しないようにしているためである。すなわち上記端末は、PHS圏内でさえあれば、WLANの圏内か圏外かにかかわらずWLANをOFFにしている。言い換えると上記端末は、デュアル端末とはいうものの、PHS圏内での待ち受け時には実質的にPHS相当となっている。このためこれをIP網から呼び出すには、まずそのWLANをONにしてIP網に接続させ、さらにSIPサーバ2000に必要事項(IPアドレスなど)を登録させるためのしくみが必要である。
【0007】
ちなみにこのしくみの一例としては、「株式会社インターナショナルシステムリサーチ」の「PPPhone」システム(さらに詳細には、当該システムで採用されているWakeOnRingテクノロジ「PPPush」)がある。これは電源OFFの状態にあるPDAが、「WakeOnトリガー」と呼ばれる本体起動用のメッセージをPHSで受信すると、自己の電源をONにするとともにWLANでIP網に接続し、SIPサーバへ必要事項を登録するものである。
【0008】
また、たとえば図21の実線矢印で示すように、発呼者が発信端末2001からPSTN経由でIP電話をかけ、その電話がP−S(PSTN→SIP)ゲートウェイ2003およびSIPサーバ2000を経て、さらにPSTN経由で着信端末2002に転送された場合、
・発信端末2001〜P−Sゲートウェイ2003間の通話料
・S−Pゲートウェイ2004〜着信端末2002間の通話料
の両者が発呼者に発生してしまう(二重課金)。この場合は結果的に、図中実線矢印の経路でIP電話をかけるより、破線矢印の経路で普通に電話をかけたほうが安価だったことになり、上記システムを利用するメリットが減殺されてしまう。なお、この問題は発信端末2001や着信端末2002がデュアル端末でなくとも、双方ともにPSTNを利用する機器である場合に発生する。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2005−269299号公報
【特許文献2】特開2006−25009号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
まとめると、上記従来技術においては、本来負担しなくてもよいはずの通話料を発呼者が負担しなければならない場合があった。具体的には、
(1)ユビキタスIP電話システムをIP網経由で利用した場合、当該システムが着呼者をPSTN経由で呼び出したことが原因で、IP網経由で呼び出せば無料だったはずの通話に料金がかかってしまう
(2)ユビキタスIP電話システムをPSTN経由で利用した場合、当該システムが着呼者をPSTN経由で呼び出したことが原因で、当該システムを介さず直接PSTN経由で呼び出すのに比べて余分に料金がかかってしまう
などである。
【0011】
本発明は、上記に鑑みてなされたものであって、発信端末〜着信端末間の通信を相対的に最も安価な経路で中継することが可能な通信中継方法、通信中継プログラム、および通信中継装置を提供することを目的とする。
【課題を解決するための手段】
【0012】
上述した課題を解決し、目的を達成するために、本発明は第1の音声通話装置と第2の音声通話装置との間の通話を中継する処理をサーバが実行する通信中継方法、通信中継プログラム、および通信中継装置であって、前記第1の音声通話装置と前記第2の音声通話装置との接続要求を、前記サーバが、第1のネットワークを通じて前記第1の音声通話装置から受信し、受信された前記接続要求が転送されることになる第2のネットワークを、前記サーバが特定し、前記第1のネットワークと特定された第2のネットワークとが同一でない場合に、前記サーバが、前記接続要求を前記第2のネットワークを通じて前記第2の音声通話装置に送信することを要件とする。
【0013】
上記発明(後述する「かけ直し方式」)によれば、発信端末〜着信端末間で同一ネットワークを二回経由するために料金が二重に発生するような接続要求は、一方の料金が発生する前に破棄される。
【発明の効果】
【0014】
本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置は、発信端末〜着信端末間の通信を相対的に最も安価な経路で中継することができるという効果を奏する。
【図面の簡単な説明】
【0015】
【図1】本発明の実施例1にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。
【図2】本発明の実施例1にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。
【図3】本発明の実施例1にかかる通信中継装置のハードウェア構成を示す説明図である。
【図4】本発明の実施例1にかかる通信中継装置の機能的構成を示す説明図である。
【図5】本発明の実施例1にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。
【図6】本発明の実施例1にかかる着信端末102における、着信処理の手順を示すフローチャートである。
【図7】本発明の実施例2にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。
【図8】本発明の実施例2にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。
【図9】本発明の実施例2にかかる通信中継装置の機能的構成を示す説明図である。
【図10】本発明の実施例2にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。
【図11】本発明の実施例2にかかる着信端末702における、着信処理の手順を示すフローチャートである。
【図12】本発明の実施例3にかかる通信中継装置により実現される、「繋ぎ直し+かけ直し方式」の概略を示す説明図である。
【図13】本発明の実施例3にかかる通信中継装置により実現される、「繋ぎ直し+かけ直し方式」の概略を示す説明図である。
【図14】本発明の実施例3にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。
【図15】本発明の実施例3にかかる着信端末1202における、着信処理の手順を示すフローチャートである。
【図16】本発明の実施例3にかかる発信端末1201における、発信処理の手順を示すフローチャートである。
【図17】本発明の実施例4にかかる通信中継装置により実現される、「かけ直し方式」の概略を示す説明図である。
【図18】本発明の実施例4にかかる通信中継装置の機能的構成を示す説明図である。
【図19】本発明の実施例4にかかる通信中継装置における、各種リクエストの処理手順を示すフローチャートである。
【図20】従来技術の問題点を示す説明図である。
【図21】従来技術の他の問題点を示す説明図である。
【発明を実施するための形態】
【0016】
以下に、本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【0017】
本発明では上述した従来技術の問題点(1)(2)を解決するため、
・実施例1:コールバック方式・・・・・・問題点(1)を解決
・実施例2:繋ぎ直し方式・・・・・・・・問題点(1)を解決
・実施例3:繋ぎ直し+かけ直し方式・・・問題点(2)を解決
・実施例4:かけ直し方式・・・・・・・・問題点(2)を解決
の4方式を提案する。以下、順次説明する。
【実施例1】
【0018】
(コールバック方式)
図1および図2は、本発明の実施例1にかかる通信中継装置により実現される、「コールバック方式」の概略を示す説明図である。発信端末101はSIP(Session Initiation Protocol)によるVoIP通話の可能な機器なら何であってもよいが、ここではたとえばVoIPアダプタを介してIP網に接続された電話機(IP電話)であるものとする。発呼者がこの発信端末101から、あらかじめ着呼者ごとに付与されている代表番号、たとえば「050−XXXX−XXXX」へ電話をかけると、当該番号を意味するSIP URI(Uniform Resource Identifier)、たとえば「sip:+81−050−XXXX−XXXX@・・・」を宛先とするINVITEリクエストが、IP網を経てSIPサーバ100へ送信される(図中(1))。なお、以下では上記URIを「バーチャルURI」と呼ぶ。
【0019】
SIPサーバ100は上述の転送先選択機能を備えており、着呼者のバーチャルURIあてのINVITEリクエストを、当該着呼者の現実のSIP URI(少なくとも一つ)のうちいずれか一つに転送する。なお、以下では上記現実のSIP URIを「着信端末URI」と呼び、そのうち転送先として選択された一つを特に「選択中URI」と呼ぶ。なお、バーチャルURIと着信端末URIとの対応関係、および着信端末URIのうちどれが選択中URIであるかは、SIPサーバ100の「転送先テーブル」に保持されている。図中、「*」印の付加された着信端末URIが選択中URIである。
【0020】
そして発信端末101からのINVITEリクエストは、SIPサーバ100でその宛先をバーチャルURIから選択中URIに付け替えられた後、選択中URIにより一意に特定される着信端末102へ転送される。ただし、選択中URIがPSTN上の識別子(具体的には電話番号)を意味するSIP URI、たとえば「tel:+81−070−XXXX−XXXX」であった場合は、上記リクエストはまずS−Pゲートウェイ104に転送(図中(2))されてPSTNの呼に変換の上、PSTN経由で着信端末102に転送(図中(3))される。このため上述のように、本来なら通話料が発生しない状況、具体的にはデュアル端末である着信端末102がWLAN圏内にあるときでも、S−Pゲートウェイ104〜着信端末102間の通話料が発生してしまう。
【0021】
ここで、選択中URIは(a)相対的に高価な(通信コストの高い)ネットワークにも安価な(通信コストの低い)ネットワークにも接続可能な機器に対応するSIP URIのうち、前者における識別子を意味するSIP URIである場合と、(b)上記以外のSIP URIである場合とがある。たとえば、PSTNにもIP網にも接続可能なデュアル端末のPHS番号を意味するSIP URIは(a)であり、一般のPHSのPHS番号を意味するSIP URIは(b)である。別の言い方をすると、PHS番号を意味するSIP URIは、上記番号がデュアル端末のPHS番号であれば(a)、一般のPHSのPHS番号であれば(b)に該当することになる。なお、以下では(b)に該当するSIP URIの種別を「通常」と呼ぶ。
【0022】
そして、発呼者が本来負担しなくてもよいはずの通話料(具体的にはS−Pゲートウェイ104〜着信端末102間の通話料)を負担しなければならなくなるのは、選択中URIが特に(a)だった場合、すなわちその種別が「通常」ではなかった場合である。そこで実施例1では、選択中URIの種別が「通常」でない場合は、SIPサーバ100からS−Pゲートウェイ104へINVITEリクエストを転送した直後に、CANCELリクエストを送信する(図中(2))ことで、S−Pゲートウェイ104から着信端末102への呼を通話料の発生前(具体的にはワンコール程度)で切断してしまう(図中(3))。
【0023】
また、SIPサーバ100は発信端末101からのINVITEリクエストを、S−Pゲートウェイ104とともにアナウンスサービス105へも転送し(図中(4))、アナウンスサービス105から発信端末101への2XX応答(成功)と、発信端末101からアナウンスサービス105へのACKリクエストとを順次転送する。これにより、発信端末101〜アナウンスサービス105間でRTPコネクションが確立されると、アナウンスサービス105から発呼者へ、着呼者からコールバックするのでいったん電話を切って待つよう指示がなされ、発信端末101からアナウンスサービス105へBYEリクエストが送信(図中(5))された時点で、発信端末101からの電話は切断される。
【0024】
一方、S−Pゲートウェイ104からいわゆる「ワン切り」された着信端末102は、WLANでIP網に接続、あるいはPHSでPSTNに接続してただちにコールバックする。もっとも、着信端末102ではコールバック先となるべき発信端末101を特定できないので(着信履歴には発信端末101ではなく、S−Pゲートウェイ104の電話番号しか残らないため)、実施例1ではSIPサーバ100の「転送元テーブル」に、着信端末102とコールバック先となる発信端末101との対応関係を保持しておくようにする。
【0025】
すなわちSIPサーバ100は、発信端末101から受信したINVITEリクエストをS−Pゲートウェイ104およびアナウンスサービス105に転送する際に、当該リクエストのToヘッダに記述されたバーチャルURI(図中(1)の「Receiver Virtual」)と、Fromヘッダに記述された発信端末101のURI(発信端末URI。同「Caller VoIP」)との組を、その保持する「転送元テーブル」に登録する。
【0026】
その後図1のように、着信端末102がWLANでIP網に接続してS−Pゲートウェイ104へコールバックした場合、着信端末102からのINVITEリクエストは、その宛先であるS−Pゲートウェイ104を通過してSIPサーバ100に転送される(図1(6))。
【0027】
したがって図1の場合、SIPサーバ100が受信するINVITEリクエストには、(a)通常のINVITEリクエスト(図中(1)など)と、(b)過去の電話をトリガーとするINVITEリクエスト(図中(6)など)との2種類があることになる。なお、以下では(a)に該当するINVITEリクエストの種別を「通常」、(b)に該当するINVITEリクエストの種別を「コールバック」と呼ぶ。そして、あるINVITEリクエストが上記のいずれであるかは、上述の転送先テーブルおよび転送元テーブルを参照することで特定できる。具体的には転送先テーブルで、上記リクエストのFromヘッダに記述されたSIP URIと対応づけられたバーチャルURIが、転送元テーブルにも登録されていれば(b)、登録されていなければ(a)である。
【0028】
そして、受信したINVITEリクエストの種別が「コールバック」だった場合、SIPサーバ100は上記リクエストの宛先を、転送元テーブルで上記バーチャルURIに対応づけられている発信端末URI(図中「Caller VoIP」)に付け替えて、発信端末101へ転送する(図1(7))。その後2XX応答(成功)とACKリクエストを経て、着信端末102〜発信端末101間でRTPコネクションが確立される(図1(8))。
【0029】
一方、図2のように、着信端末102がPHSでPSTNに接続してS−Pゲートウェイ104へコールバックした場合(図2(6))、S−Pゲートウェイ104を宛先とするINVITEリクエストがS−Pゲートウェイ104からSIPサーバ100に送信される(図2(7))。そしてSIPサーバ100が、上記と同様にコールバックか否かを判定し、コールバックの場合は上記リクエストの宛先を、転送元テーブルから検索した発信端末URIに付け替えて転送する(図2(8))。その後2XX応答(成功)とACKリクエストを経て、S−Pゲートウェイ104〜発信端末101間でRTPコネクションが確立される(図2(9))。なお、図1および図2のP−Sゲートウェイ103はなくても構わない(P−Sゲートウェイ103がなくても実施例1の発明は実施可能である)が、ここでは後述する他の実施例との比較のために示している。
【0030】
次に、図3は本発明の実施例1にかかる通信中継装置(具体的には図1に示したSIPサーバ100)のハードウェア構成を示す説明図である。図中、CPU301は装置全体の制御を司る。ROM302はブートプログラムなどを記憶している。RAM303はCPU301のワークエリアとして使用される。
【0031】
HDD304は、CPU301の制御にしたがってHD305に対するデータのリード/ライトを制御する。HD305は、HDD304の制御にしたがって書き込まれたデータを記憶する。FDD306は、CPU301の制御にしたがってFD307に対するデータのリード/ライトを制御する。FD307は、FDD306の制御にしたがって書き込まれたデータを記憶する。なお、FD307は着脱可能な記録媒体の一例であり、FD307の代わりにCD−ROM(CD−R、CD−RW)、MO、DVD(Digital Versatile Disk)、メモリーカードなどであってもよい。
【0032】
ネットワークI/F308はLAN/WANなどのネットワークに接続され、当該ネットワークと装置内部とのデータの送受信を司る。また、バス300は上記各部を接続する。なお、上記のほか本装置はディスプレイ、マウス、キーボードなどのコンソール類を備えていてもよい。
【0033】
次に、図4は本発明の実施例1にかかる通信中継装置(具体的には図1に示したSIPサーバ100)の機能的構成を示す説明図、図5は当該装置における各種リクエストの処理手順を示すフローチャートである。図4中の各部の機能は、図5のフローチャートにおいて順次説明する。
【0034】
SIPサーバ100のプロキシ402がINVITEリクエストを受信すると(ステップS501:Yes)、当該リクエストはいったん転送先特定部403に出力され、転送先特定部403のINVITE種別特定部403aが、当該リクエストの種別を特定する。そして種別が「通常」だった場合は(ステップS502:Yes)、転送先特定部403の転送先種別特定部403bが、上記リクエストの宛先のバーチャルURIに対応づけられた選択中URIの種別を特定する。
【0035】
そして、選択中URIの種別が「通常」でなかった場合、たとえばデュアル端末のPHS番号を意味するSIP URIだった場合は(ステップS503:No)、転送先特定部403はプロキシ402から入力したINVITEリクエスト、選択中URI、およびアナウンスサービス105のSIP URIをリクエスト生成部404に出力する。
【0036】
そしてリクエスト生成部404が、
・選択中URIを宛先とするINVITEリクエスト
・選択中URIを宛先とするCANCELリクエスト
・アナウンスサービス105のSIP URIを宛先とするINVITEリクエスト
の3つを生成し(ステップS504)、これらがプロキシ402により順次転送される(ステップS505)。なお、選択中URIを宛先とするCANCELリクエストは、当該URIを宛先とするINVITEリクエストを受けて、S−Pゲートウェイ104が着信端末102を呼び出した後に転送されるものとする。
【0037】
また、転送先特定部403は転送元テーブル更新部405に指示して、プロキシ402から入力したINVITEリクエストのバーチャルURIと発信端末URIとの組を転送元テーブル401に登録させる(ステップS506)。
【0038】
一方、選択中URIの種別が「通常」だった場合は(ステップS503:Yes)、転送先特定部403はプロキシ402から入力したINVITEリクエストと選択中URIとをリクエスト生成部404に出力し、リクエスト生成部404が上記リクエストの宛先を上記URIで置換することで、上記URIを宛先とするINVITEリクエストを生成する(ステップS507)。次に、リクエスト生成部404が上記リクエストをプロキシ402に出力し、プロキシ402が上記リクエストの転送(ステップS508)後、応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS509)。
【0039】
一方、プロキシ402から入力したINVITEリクエストの種別が「コールバック」だった場合(ステップS502:No)、すなわち当該リクエストが以前ステップS501〜S506で転送された他のINVITEリクエストをトリガーとしてなされたものである場合は、転送先特定部403は当該リクエストと、当該他のリクエストの転送時に転送元テーブル401に登録された発信端末URIとをリクエスト生成部404に出力する。そしてリクエスト生成部404が、上記リクエストの宛先を上記URIで置換することで、上記URIを宛先とするINVITEリクエストを生成し(ステップS510)、これがプロキシ402により発信端末101へ転送される(ステップS511)。
【0040】
また、転送先特定部403は転送元テーブル更新部405に指示して、トリガーとなった他のINVITEリクエストの転送時に転送元テーブル401に登録された、バーチャルURIと発信端末URIとの組を削除させる(ステップS512)。その後はプロキシ402が、応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS509)。なお、INVITEリクエスト以外のリクエストを受信した場合は(ステップS501:No)、SIPサーバ100は受信したリクエストに対応するその他の処理を行う(ステップS513)。
【0041】
次に、図6は本発明の実施例1にかかる着信端末102における、着信処理の手順を示すフローチャートである。PHSによる待ち受け中にS−Pゲートウェイ104から着信があった場合(ステップS601:Yes、ステップS602:Yes。なお、S−Pゲートウェイ104からの着信かどうかは電話番号により特定できる)、着信端末102は着信音は出力せずに呼の切断を待つとともに、OFFになっているWLANをONにして(ステップS603)WLANの圏内/圏外を判定し(ステップS604)、この結果にもとづいてWLAN/PHSのいずれかを通信手段として選択する。なお、上記判定結果のほか通信コストや通話の品質、あらかじめ設定されているプリファレンスなどにもとづいて、いずれかの通信手段を選択するようにしてもよい。
【0042】
そしてWLANを選択した場合は(ステップS605:Yes)、着信端末102はWLANでIP網に接続し、S−Pゲートウェイ104あてのINVITEリクエストを送信(ステップS606)することで、通常のSIP通話(ステップS607)を開始する。そして通話終了時には、着信時にONにしたWLANを再びOFFにする(ステップS608)。なお同図では省略しているが、実際にはINVITEリクエストの前に、SIPサーバ100へREGISTERリクエストを送信する。
【0043】
一方、PHSを選択した場合は(ステップS605:No)、着信端末102はONにしたWLANを再びOFFにする(ステップS609)。次にPHSでPSTNに接続して、S−Pゲートウェイ104の電話番号に発呼(ステップS610)することで、通常のPHS通話(ステップS611。なお、S−Pゲートウェイ104から先はSIP通話となる)を開始する。また、S−Pゲートウェイ104以外から電話がかかってきた場合には着信音を出力し(ステップS602:No、ステップS612)、着呼者が電話に出た後は通常のPHS通話となる(ステップS611)。
【0044】
図1および図2と、図5および図6とを対応づけて説明すると、まず図1の場合、発信端末101からの電話の転送先が「通常」でないので、SIPサーバ100はS−Pゲートウェイ104に指示して、通話料のかからないいわゆる「ワン切り」で着信端末102を呼び出させるとともに、発信端末101をいったんアナウンスサービス105に接続する(図5ステップS501〜S506)。
【0045】
その後、着信端末102がWLANでIP網に接続してINVITEリクエストを返してきた場合(図6ステップS601〜S606)、あるいは着信端末102がPHSでPSTNに接続してS−Pゲートウェイ104を発呼(図6ステップS601〜S605、S609〜S610)した結果、S−Pゲートウェイ104がINVITEリクエストを返してきた場合のいずれも、SIPサーバ100は上記リクエストがコールバックであることを特定して、その宛先を発信端末101に付け替えの上で転送する(図5ステップS501〜S502、S510〜S512)。
【0046】
そして発信端末101から2XX応答が返ってくると、SIPサーバ100は当該応答を着信端末102あるいはS−Pゲートウェイ104に転送するとともに、着信端末102あるいはS−Pゲートウェイ104からACKリクエストがあると、当該リクエストを発信端末101に転送する(図5ステップS509)。
【0047】
以上説明した実施例1によれば、まず図1の場合、唯一PSTNを利用する(3)でもワン切りしているため、(1)〜(8)の全体を通じて通話料が発生しない。通信経路は図20の点線矢印と同等になり(ただしコールバックのため、矢印の向きは逆となる)、従来技術の実線矢印に比べて、S−Pゲートウェイ2004〜着信端末2002間の通話料が削減できていることになる。
【0048】
一方、図2の場合は(3)および(6)でPSTNを利用しており、前者はワン切りのため無料であるが、後者は有料である。通信経路は図20の実線矢印と同等であり(ただしコールバックのため、矢印の向きは逆となる)、通話料は従来技術と同様に発生する。もっとも課金先は発呼者でなく着呼者となるため、無料で電話をかけることはできてもかかってきた電話を無料にすることはできないという、デュアル端末の従来の弱点を補うことができる。
【0049】
ただ、実施例1では発呼者に違和感を覚えさせてしまう(かけた電話をいったん切らなければならないため)ことのほか、発呼者と着呼者が実際に通話できるようになるまでの時間もかかってしまう。そこで、実施例1のように着呼者からコールバックするのでなく、次に説明する実施例2のように、従来のやり方で着呼者につないだのでは相対的に高価な通信経路Aとなってしまう発呼者からの電話を、相対的に安価な通信経路Bで着呼者に繋ぎ直すようにしてもよい。
【実施例2】
【0050】
(繋ぎ直し方式)
図7および図8は、本発明の実施例2にかかる通信中継装置により実現される、「繋ぎ直し方式」の概略を示す説明図である。バーチャルURIあてのINVITEリクエストを発信端末701から受信(図中(1))すると、SIPサーバ700は転送先テーブルから、当該バーチャルURIに対応づけられた選択中URIを検索し、当該リクエストの宛先を当該選択中URIに付け替えて転送する。そして、この選択中URIがデュアル端末のPHS番号を意味するSIP URIだった場合、上記リクエストはS−Pゲートウェイ704に転送(図中(2))されてPSTNの呼に変換の上、PSTN経由で着信端末702に転送(図中(3))される。そして、ここまでは実施例1のコールバック方式と同様である。
【0051】
S−Pゲートウェイ704から呼び出された着信端末702は、通信手段としてWLAN/PHSのいずれかを選択し、WLANを選択した場合、図7のようにSIPサーバ700へREGISTERリクエストを送信する(図中(4))。
【0052】
したがって図7の場合、SIPサーバ700が受信するREGISTERリクエストには、(a)通常のREGISTERリクエストと、(b)過去の電話をトリガーとするREGISTER(図中(4)など)との2種類があることになる。そして、あるREGISTERリクエストが上記のいずれであるかは、上述の転送先テーブルおよび転送元テーブルを参照することで特定できる。具体的には転送先テーブルで、上記リクエストのToヘッダおよびFromヘッダに記述されたSIP URI(IPアドレスを登録されるSIP URI)と対応づけられたバーチャルURIが、転送元テーブルにも登録されていれば(b)、登録されていなければ(a)である。なお、以下では(a)に該当するREGISTERリクエストの種別を「通常」と呼ぶ。
【0053】
そして、受信したREGISTERリクエストの種別が「通常」でなかった場合、SIPサーバ700はS−Pゲートウェイ704にCANCELリクエストを送信(図中(5))することで、S−Pゲートウェイ704から着信端末702への呼を切断させる(図中(6))。またその一方で、発信端末701から受信(図中(1))したINVITEリクエストの宛先を、着信端末702がIPアドレスを登録(図中(4))したSIP URIに付け替えて転送する(図中(7))。そして着信端末702から2XX応答(成功)を受信すると(図中(8))、当該応答を発信端末701へ転送し(図中(9))、さらにACKリクエストの転送を経て、発信端末701〜着信端末702間でRTPコネクションが確立される(図中(10))。
【0054】
一方、S−Pゲートウェイ704から呼び出された着信端末702が、通信手段としてPHSを選択した場合は、着呼者が電話に出た時点で、図8のように着信端末702からPSTN経由で応答信号が返される(図中(4))。そして上記信号を受信したS−Pゲートウェイ704は、SIPサーバ700へ2XX応答を送信し(図中(5))、SIPサーバ700がさらに発信端末701へ当該応答を転送する(図中(6))。その後ACKリクエストの転送を経て、発信端末701〜S−Pゲートウェイ704間でRTPコネクションが確立される(図中(7))。
【0055】
本発明の実施例2にかかる通信中継装置(具体的には図7および図8に示したSIPサーバ700)のハードウェア構成は、図3に示した実施例1のそれと同様であるので説明を省略する。図9は上記装置の機能的構成を示す説明図、図10は上記装置における各種リクエストの処理手順を示すフローチャートである。図9中の各部の機能は、図10のフローチャートにおいて順次説明する。
【0056】
SIPサーバ700のプロキシ902がINVITEリクエストを受信すると(ステップS1001:Yes)、当該リクエストはいったん転送先特定部903に出力され、転送先特定部903の転送先種別特定部903aが、転送先テーブル900を参照して、当該リクエストの宛先のバーチャルURIに対応づけられた選択中URIの種別を特定する。
【0057】
そして、選択中URIの種別が「通常」でなかった場合(ステップS1002:No)、転送元テーブル更新部905に指示して、上記リクエストのバーチャルURIと発信端末URIとの組を転送元テーブル901に登録させる(ステップS1003)。なお、選択中URIの種別が「通常」だった場合は(ステップS1002:Yes)、ステップS1003の処理は省略される。
【0058】
そしていずれの場合も、上記リクエストと選択中URIとをリクエスト生成部904に出力し、リクエスト生成部904が上記リクエストの宛先を上記URIで置換することで、上記URIを宛先とするINVITEリクエストを生成する(ステップS1004)。次に、プロキシ902が上記リクエストの転送(ステップS1005)後、応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS1006)。
【0059】
一方、SIPサーバ700のレジストラ906がREGISTERリクエストを受信すると(ステップS1007:Yes)、通常のSIP登録処理(ステップS1008)の後、レジストラ906のREGISTER種別特定部906aが、上記リクエストの種別を特定する。
【0060】
そして、種別が「通常」だった場合は(ステップS1009:Yes)そのままステップS1001に戻る。一方、種別が「通常」でなかった場合(ステップS1009:No)、すなわち上記リクエストが以前ステップS1001〜S1006で転送されたINVITEリクエストをトリガーとしてなされたものである場合は、レジストラ906は当該INVITEリクエスト、当該INVITEリクエストの転送先となった選択中URI、および当該INVITEリクエストの転送時に転送元テーブル901に登録された発信端末URIをリクエスト生成部904に出力する。
【0061】
そしてリクエスト生成部904が、
・発信端末URIを宛先とするINVITEリクエスト
・選択中URIを宛先とするCANCELリクエスト
の2つを生成し(ステップS1010)、これらがプロキシ902により順次転送される(ステップS1011)。
【0062】
また、レジストラ906は転送元テーブル更新部905に指示して、トリガーとなったINVITEリクエストの転送時に転送元テーブル901に登録された、バーチャルURIと発信端末URIとの組を削除させる(ステップS1012)。その後はプロキシ902が、応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS1006)。なお、INVITEリクエストやREGISTERリクエスト以外のリクエストを受信した場合は(ステップS1001:No、ステップS1007:No)、SIPサーバ700は受信したリクエストに対応するその他の処理を行う(ステップS1013)。
【0063】
次に、図11は本発明の実施例2にかかる着信端末702における、着信処理の手順を示すフローチャートである。PHSによる待ち受け中にS−Pゲートウェイ704から着信があった場合(ステップS1101:Yes、ステップS1102:Yes)、着信端末702はOFFになっているWLANをONにして(ステップS1103)WLANの圏内/圏外を判定し(ステップS1104)、この結果にもとづいてWLAN/PHSのいずれかを通信手段として選択する。なお、上記判定結果のほか通信コストや通話の品質、あらかじめ設定されているプリファレンスなどにもとづいて、通信手段を選択するようにしてもよい。
【0064】
そしてWLANを選択した場合は(ステップS1105:Yes)、着信端末702はWLANでIP網に接続し、SIPサーバ700へREGISTERリクエストを送信する(ステップS1106)。一方、PHSを選択した場合は(ステップS1105:No)、ONにしたWLANをOFFにするとともに(ステップS1107)着信音を出力し(ステップS1108)、着呼者が電話に出た後は通常のPHS通話となる(ステップS1109)。なお、PHSによる待ち受け中にS−Pゲートウェイ704以外から着信があった場合(ステップS1101:Yes、ステップS1102:No)も、着信端末702は着信音を出力し(ステップS1108)、着呼者が電話に出た後は通常のPHS通話となる(ステップS1109)。
【0065】
また、ステップS1103でONにしたWLANへINVITEリクエストが着信すると(ステップS1101:No、ステップS1110:Yes)、着信端末702は着信音を出力し(ステップS1111)、着呼者が電話に出た後は通常のSIP通話となる(ステップS1112)。なお通話終了時には、着信時にONにしたWLANを再びOFFにする(ステップS1113)。
【0066】
図7および図8と、図10および図11とを対応づけて説明すると、まず図7の場合、SIPサーバ700は発信端末701からの電話を、まずPSTN経由で着信端末702に転送するが(図10ステップS1001〜S1005)、着信端末702からREGISTERリクエストがあると(図11ステップS1101〜S1106)、それは取り消して次はIP網経由で着信端末702に転送する(図10ステップS1007〜S1012)。そして着信端末702から2XX応答があると、当該応答を発信端末701に転送するとともに、発信端末701からACKリクエストがあると、当該リクエストを着信端末702に転送する(図10ステップS1006)。
【0067】
一方図8の場合、着信端末702がS−Pゲートウェイ704に応答信号を返すと(図11ステップS1101〜S1105、S1107〜S1109)、S−Pゲートウェイ704がSIPサーバ700に2XX応答を返すので、SIPサーバ700は当該応答を発信端末701に転送するとともに、発信端末701からACKリクエストがあると、当該リクエストをS−Pゲートウェイ704に転送する(図10ステップS1006)。
【0068】
なお、図7の場合、SIPサーバ700が着信端末702からのREGISTERリクエストを受信する前に、S−Pゲートウェイ704から3XX〜6XX応答を受信してしまうと、当該応答が発信端末701に転送された時点で発信端末701からの電話は切断されてしまい、その後に着信端末702が登録してきても発信端末701と接続することができなくなる。そこで図10のステップS1006における処理を、SIPサーバ700がS−Pゲートウェイ704から3XX〜6XX応答を受信した場合は、所定時間内に着信端末702からREGISTERリクエストがないことを条件として発信端末701へ転送するよう修正してもよい。すなわちS−Pゲートウェイ704から接続失敗が通知されてきても、すぐには発信端末701へ通知せず、上記所定時間だけは着信端末702からの登録を待つようにする。
【0069】
以上説明した実施例2によれば、まず図7の場合、(3)でS−Pゲートウェイ704がかけた電話は着信端末702の応答前に切断されるので、(1)〜(10)の全体を通じて通話料が発生しない。通信経路は図20の点線矢印と同一になり、従来技術の実線矢印に比べて、S−Pゲートウェイ2004〜着信端末2002間の通話料が削減できていることになる。一方、図8の場合は図20の実線矢印と同一、すなわち上述のユビキタスIP電話システムにおいて、IP端末から代表番号へかけた電話が非IP端末へ転送されるケースと同一であり、S−Pゲートウェイ2004〜着信端末2002間の通話料が発呼者に課金される。
【0070】
なお、図7で着信端末702がSIPサーバ700へ送信するREGISTERリクエストは、本来的にはSIP登録のためのリクエストであるが、実施例2ではこれを一種の接続要求、すなわち発信端末701とIP網経由で接続すべき旨の着信端末702からの要求とみなし、この要求に応じてSIPサーバ700が、いったんPSTN経由で転送した電話をIP網経由で転送し直していると言うこともできる。逆に言うと、上記接続要求は必ずしも着信端末702からのREGISTERリクエストでなければならないわけではなく、着信端末702がWLANで着信可能な状態になったことを示す何らかの通知(必ずしも着信端末702自身からの通知でなくともよい)などであってもよい。
【実施例3】
【0071】
(繋ぎ直し+かけ直し方式)
図12および図13は、本発明の実施例3にかかる通信中継装置により実現される、「繋ぎ直し+かけ直し方式」の概略を示す説明図である。上述した実施例2はIP端末(たとえばIP電話)から電話をかける場合であるが、実施例3は非IP端末、具体的には従来の電話機や、WLAN圏外にあるときのデュアル端末などから電話をかける場合である。そして図21に示したように、発信端末2001がPSTN経由で発呼し、着信端末2002もPSTN経由で着呼すると、発信端末2001〜P−Sゲートウェイ2003間の通話料と、S−Pゲートウェイ2004〜着信端末2002間の通話料とが二重に発生してしまう。
【0072】
そこで実施例3では、図12および図13に示すように、発信端末1201がPSTN経由で発呼し(図中(1))、P−Sゲートウェイ1203からSIPサーバ1200を経てINVITEリクエストを転送(図中(2)(3))されたP−Sゲートウェイ1204が、さらにPSTN経由で発呼する(図中(4))場合、INVITEリクエストの転送直後にSIPサーバ1200からS−Pゲートウェイ1204へCANCELリクエストを送信する(図中(3))ことで、S−Pゲートウェイ1204から着信端末1202への呼を通話料の発生前(具体的にはワンコール程度)で切断してしまう(図中(4))。
【0073】
そして着信端末1202は、通信手段としてWLANを選択した場合、図12に示すようにSIPサーバ1200へREGISTERリクエストを送信する(図中(5))。SIPサーバ1200は、上記リクエストの種別が「通常」でなかった場合、P−Sゲートウェイ1203から受信(図中(2))したINVITEリクエストの宛先を、着信端末1202がIPアドレスを登録(図中(5))したSIP URIに付け替えて転送する(図中(6))。
【0074】
そして着信端末1202から2XX応答を受信すると(図中(7))、当該応答をP−Sゲートウェイ1203へ転送し(図中(8))、さらにACKリクエストの転送を経て、P−Sゲートウェイ1203〜着信端末1202間でRTPコネクションが確立される(図中(9))。その後、P−Sゲートウェイ1203から発信端末1201へ、PSTN経由で応答信号を返す(図中(10))。
【0075】
一方、着信端末1202は通信手段としてPHSを選択した場合、図13に示すように、S−Pゲートウェイ1204から電話がかかってきた(図中(4))後は続いて発信端末1201から電話がかかってくるのを待つ(自分からは何もしない)。S−Pゲートウェイ1204からの電話はワン切りされてしまうのでPHSで応答しようにも間に合わず、しかもWLANも使えない/使わないので、着信端末1202としてはPHSでS−Pゲートウェイ1204にコールバックするしかないのであるが、S−Pゲートウェイ1204からSIPサーバ1200を経てP−Sゲートウェイ1203へINVITEリクエストが転送され、P−Sゲートウェイ1203からPSTN経由で発信端末1201が呼び出されると、上述の二重課金の問題がここでも発生してしまう。
【0076】
これを避けるため実施例3では、着信端末1202が何もしない代わりに、発信端末1201が電話を自動的にかけ直すようにする。すなわち実施例3にかかる発信端末1201は、着呼者の代表番号あてにかけた電話が所定時間内につながらない(所定時間内にP−Sゲートウェイ1203から応答信号が返ってこない)ときは、着呼者の別の電話番号を一つ選択して電話をかけ直す。なお、この別の電話番号はあらかじめ発信端末1201に保持しているのでも、あるいはSIPサーバ1200などからリアルタイムに取得するのでもよい。
【0077】
そしてこの別の電話番号の中にデュアル端末のPHS番号があれば、S−Pゲートウェイ704からの着信後しばらく経ってから、着信端末1202へ今度は発信端末1201から直接電話がかかってくることになる(図中(5))。そして着信端末1202が応答信号を返した(図中(6))後は、通常のPHS通話となる。
【0078】
本発明の実施例3にかかる通信中継装置(具体的には図12および図13に示したSIPサーバ1200)のハードウェア構成は、図3に示した実施例1のそれと同様であるので説明を省略する。また上記装置の機能的構成は、図9に示した実施例2のそれとほぼ同様であり、異なる点は図14のフローチャートにおいて順次説明する。
【0079】
図14は、上記装置における各種リクエストの処理手順を示すフローチャートである。図10に示した実施例2のそれとの差異は、CANCELリクエストの生成・転送処理が、図10ではREGISTERリクエスト受信時の処理ループ内にある(ステップS1010・S1011)のに対して、図14では当該リクエストのトリガーとなったINVITEリクエスト受信時の処理ループ内にある(ステップS1404・S1405)点である(なお、INVITEリクエストやREGISTERリクエスト以外のリクエストを受信した場合は、SIPサーバ1200は受信したリクエストに対応するその他の処理を行う(ステップS1401:No、ステップS1409:No、ステップS1415))。
【0080】
すなわち実施例3にかかるリクエスト生成部904は、SIPサーバ1200が受信したINVITEリクエストについて、転送先種別特定部903aで特定された選択中URIの種別が「通常」でなかった場合、当該URIを宛先とするINVITEリクエストおよびCANCELリクエストの2つを生成し、これらがプロキシ902により順次転送される(ステップS1401〜S1405)。なお、選択中URIの種別が「通常」だった場合は、当該URIを宛先とするINVITEリクエストを生成し、これがプロキシ902により転送された後は、プロキシ902が応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS1401〜S1402、S1406〜S1408)。
【0081】
また、実施例3にかかるリクエスト生成部904は、SIPサーバ1200が受信したREGISTERリクエストについて、REGISTER種別特定部906aにより特定されたその種別が「通常」でなかった場合、IPアドレスが登録されたSIP URIを宛先とするINVITEリクエストを生成し、これがプロキシ902により着信端末1202へ転送される(ステップS1409〜S1414)。
【0082】
次に、図15は本発明の実施例3にかかる着信端末1202における、着信処理の手順を示すフローチャートである。図中ステップS1501〜S1513のそれぞれにおける処理は、図11に示したステップS1101〜S1113のそれぞれにおける処理と同一である。ただし実施例3では、着信端末1202が通信手段としてPHSを選択し、WLANをOFFにした(ステップS1505:No、ステップS1507)時点では、S−Pゲートウェイ1204からの呼は切断されていてPHS通話が不可能なため、ステップS1507の後そのままステップS1501に戻っている。
【0083】
次に、図16は本発明の実施例3にかかる発信端末1201における、発信処理の手順を示すフローチャートである。発呼者から特定の電話番号、たとえば着呼者の代表番号に対する発呼指示があると(ステップS1601:Yes)、発信端末1201はPSTN経由で当該番号に発呼する(ステップS1602)。上記呼はP−Sゲートウェイ1203でINVITEリクエストに変換の上、SIPサーバ1200に転送され、SIPサーバ1200から2XX応答が返されると、さらにP−Sゲートウェイ1203から発信端末1201へ応答信号が返され(ステップS1603:Yes)、その後は通常の音声通話となる(ステップS1604)。
【0084】
そして、発信端末1201は発呼から所定時間だけ上記信号を待ち(ステップS1603:No、ステップS1605:No)、当該時間が経過してもP−Sゲートウェイ1203から応答がない場合(ステップS1603:No、ステップS1605:Yes)、上記着呼者にまだ発呼していない他の電話番号があれば(ステップS1606:Yes)、その中から一つを選択の上(ステップS1607)当該番号へ発呼する(ステップS1602)。なお、着呼者のすべての電話番号を発呼して、それでも応答がない場合は(ステップS1606:No)、その時点で処理を終了する。
【0085】
図12および図13と、図14〜図16とを対応づけて説明すると、まず図12の場合、SIPサーバ1200は着信端末1202からのREGISTERリクエストを待たずに、そのトリガーとなるINVITEリクエストをキャンセルし(図14ステップS1401〜S1405)、着信端末1202からREGISTERリクエストがあると(図15ステップS1501〜S1506)、IPアドレスを登録されたSIP URIへ発信端末1201からのINVITEリクエストを転送する(図14ステップS1409〜S1414)。
【0086】
一方図13の場合、SIPサーバ1200がINVITEリクエストをキャンセルする(図14ステップS1401〜S1405)結果、P−Sゲートウェイ1203からの応答信号がないまま所定時間が経過するので、発信端末1201は着呼者の他の電話番号、ここではデュアル端末のPHS番号を選択して電話をかけ直す(図16ステップS1601〜S1607)。
【0087】
以上説明した実施例3によれば、図12の場合も図13の場合も、図21のような通信経路となる電話はSIPサーバ1200の制御によって常にワン切り(すなわち通話料の発生前に切断)されるので、上述の二重課金が発生しない。
【0088】
ただ、WLANの使える場所がPHSの使える場所に比べてまだまだ限られており、そもそもデュアル端末もまだ普及が始まったばかりである現状から、実際には図12のようにSIPサーバ1200が電話を繋ぎ直すのでなく、図13のように発信端末1201が電話をかけ直すことになるケースがほとんどと考えられる。そして図13の場合は、図中(3)(4)がなくても特に支障がない。そこで実施例3の「繋ぎ直し+かけ直し方式」を、次に説明する実施例4の「かけ直し方式」のように簡略化してしまってもよい。
【実施例4】
【0089】
(かけ直し方式)
図17は、本発明の実施例4にかかる通信中継装置により実現される、「かけ直し方式」の概略を示す説明図である。図示するように実施例4では、二重課金の原因となるINVITEリクエスト、具体的にはP−Sゲートウェイ1703からSIPサーバ1700を経てS−Pゲートウェイ1704に転送されることになるINVITEリクエスト(図中(2))を、SIPサーバ1700で破棄してしまい、その先へ転送しないようにする。その結果、発呼から所定時間が経過してもP−Sゲートウェイ1703から応答信号が返ってこないので、発信端末1701は着呼者の他の電話番号、たとえばデュアル端末のPHS番号を選択して電話をかけ直し(図中(3))、着信端末1702から応答信号が返ってきた(図中(4))後は通常のPHS通話となる。
【0090】
本発明の実施例4にかかる通信中継装置(具体的には図17に示したSIPサーバ1700)のハードウェア構成は、図3に示した実施例1のそれと同様であるので説明を省略する。図18は上記装置の機能的構成を示す説明図、図19は上記装置における各種リクエストの処理手順を示すフローチャートである。図18中の各部の機能は、図19のフローチャートにおいて順次説明する。
【0091】
SIPサーバ1700のプロキシ1801がINVITEリクエストを受信すると(ステップS1901:Yes)、当該リクエストはいったん転送先特定部1802に出力され、転送先特定部1802の転送可否判定部1802aが、転送先テーブル1800を参照して当該リクエストの転送可否を判定する(ステップS1902)。具体的には、S−Pゲートウェイ1704に転送されることになるINVITEリクエストで、そのToヘッダにもFromヘッダにも電話番号(PSTN上での識別子)を意味するSIP URIが記述されることになる場合、すなわち上記リクエストがSIPサーバ1700の前にも後にもPSTNを経由することになる場合は転送不可、それ以外の場合は転送可とする。
【0092】
そして転送不可の場合は(ステップS1902:No)、ステップS1901に戻って他のリクエストの受信待ちとなる一方、転送可の場合は(ステップS1902:Yes)リクエスト生成部1803で、上記リクエストの宛先を転送先テーブル1800の選択中URIに付け替えることで、当該URIあてのINVITEリクエストを生成する(ステップ1903)。そしてこれがプロキシ1801により転送(ステップS1904)された後は、プロキシ1801が応答の転送やACKリクエストの転送など、INVITEリクエスト転送後の通常の処理を行う(ステップS1905)。
【0093】
なお、INVITEリクエスト以外のリクエストを受信した場合は(ステップS1901:No)、SIPサーバ1700は受信したリクエストに対応するその他の処理を行う(ステップS1906)。
【0094】
なお、実施例4の着信端末1702はPSTNでの着呼が可能な機器であれば何であってもよく、当該装置における処理も従来技術と同一である。また、実施例4の発信端末1701もPSTNでの発呼が可能な機器であれば何であってもよいが、実施例3の発信端末1201と同様、図16の手順により、所定時間以上電話がつながらないときは他の番号へ電話をかけ直す機能を備えているものとする。
【0095】
以上説明した実施例4によれば、転送すると二重課金が発生するようなINVITEリクエストはSIPサーバ1700どまりとなり、発信端末1701は別の経路で電話をかけ直すことになるため、二重課金が発生しない。より一般的に言えば、相対的に高価な通信経路Aと安価な通信経路Bとがあった場合に、先にA経由で電話がかかってきたときは経路上のどこか(たとえば実施例4のようにSIPサーバ1700)でそれを破棄し、あらためてB経由で電話をかけさせるので、最終的に電話がつながったときの通信経路は常に最も安価なものとなる。
【0096】
もっとも、上記では図21の実線矢印のような経路による通話は、破線矢印のような経路による通話より割高であることを前提としたが、発信端末2001と着信端末2002との機器の組み合わせによって通話料は異なるため、二重課金が発生するとしても実線矢印のほうが破線矢印より安価となる場合もある。そしてその場合は、たとえば発信端末2001から点線矢印の経路で電話がかかってきても、着信端末2002で着信を拒否し、あらためて実線矢印の経路で電話をかけさせるようにしてもよい。
【0097】
なお、上述した実施例1および2では発信端末101/701がIP端末、実施例3および4では発信端末1201/1701が非IP端末であることをそれぞれ前提としたが、現実のSIPサーバが受信するINVITEリクエストの中には、(a)発信端末自身が発信したINVITEリクエストと、(b)発信端末からの呼を変換してP−Sゲートウェイが転送してきたINVITEリクエストとが混在している。
【0098】
そのため実際には、たとえば実施例2のSIPサーバ700と実施例3のSIPサーバ1200の双方の機能を併せ持つSIPサーバを用意し、(a)を受信したときは図10の手順、(b)を受信したときは図14の手順により処理するようにする。あるいは、実施例1のSIPサーバ100と実施例4のSIPサーバ1700の双方の機能を併せ持つSIPサーバを用意し、(a)を受信したときは図5の手順、(b)を受信したときは図19の手順により処理するようにしてもよい。
【産業上の利用可能性】
【0099】
以上のように、本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置は、発信端末〜着信端末間に複数の通信経路がある場合の最適な経路の選択に有用であり、特に、相対的に安価な通信経路が何らかの事情(たとえば省電力など)で事実上使用不能となっているケースに適している。
【符号の説明】
【0100】
100,700,1200,1700 SIPサーバ
101,701,1201,1701 発信端末
102,702,1202,1702 着信端末
103,703,1203,1703 P−Sゲートウェイ
104,704,1204,1704 S−Pゲートウェイ
105 アナウンスサービス
300 バス
301 CPU
302 ROM
303 RAM
304 HDD
305 HD
306 FDD
307 FD
308 ネットワークI/F
400,900,1800 転送先テーブル
401,901 転送元テーブル
402,902,1801 プロキシ
403,903,1802 転送先特定部
403a INVITE種別特定部
403b,903a 転送先種別特定部
404,904,1803 リクエスト生成部
405,905 転送先テーブル更新部
906 レジストラ
906a REGISTER種別特定部
1802a 転送可否判定部
【特許請求の範囲】
【請求項1】
第1の音声通話装置と第2の音声通話装置との間の通話を中継する処理をサーバが実行する通信中継方法であって、
前記第1の音声通話装置と前記第2の音声通話装置との接続要求を、前記サーバが、第1のネットワークを通じて前記第1の音声通話装置から受信する受信工程と、
前記受信工程で受信された前記接続要求が転送されることになる第2のネットワークを、前記サーバが特定する特定工程と、
前記第1のネットワークと前記特定工程で特定された第2のネットワークとが同一でない場合に、前記サーバが、前記接続要求を前記第2のネットワークを通じて前記第2の音声通話装置に送信する送信工程と、
を含むことを特徴とする通信中継方法。
【請求項2】
前記第1のネットワークと前記第2のネットワークとが同一である場合に、前記サーバが、前記接続要求を破棄する破棄工程を含むことを特徴とする請求項1に記載の通信中継方法。
【請求項3】
第1の音声通話装置と第2の音声通話装置との間の通話を中継する処理をサーバに実行させる通信中継プログラムであって、
前記第1の音声通話装置と前記第2の音声通話装置との接続要求を、前記サーバが、第1のネットワークを通じて前記第1の音声通話装置から受信する受信工程と、
前記受信工程で受信された前記接続要求が転送されることになる第2のネットワークを、前記サーバが特定する特定工程と、
前記第1のネットワークと前記特定工程で特定された第2のネットワークとが同一でない場合に、前記サーバが、前記接続要求を前記第2のネットワークを通じて前記第2の音声通話装置に送信する送信工程と、
を前記サーバに実行させることを特徴とする通信中継プログラム。
【請求項4】
前記第1のネットワークと前記第2のネットワークとが同一である場合に、前記サーバが、前記接続要求を破棄する破棄工程を前記サーバに実行させることを特徴とする請求項3に記載の通信中継プログラム。
【請求項5】
第1の音声通話装置と第2の音声通話装置との間の通話を中継する処理を実行する通信中継装置であって、
前記第1の音声通話装置と前記第2の音声通話装置との接続要求を、第1のネットワークを通じて前記第1の音声通話装置から受信する受信手段と、
前記受信手段で受信された前記接続要求が転送されることになる第2のネットワークを特定する特定手段と、
前記第1のネットワークと前記特定手段で特定された第2のネットワークとが同一でない場合に、前記接続要求を前記第2のネットワークを通じて前記第2の音声通話装置に送信する送信手段と、
を備えることを特徴とする通信中継装置。
【請求項6】
前記第1のネットワークと前記第2のネットワークとが同一である場合に、前記接続要求を破棄する破棄手段を備えることを特徴とする請求項5に記載の通信中継装置。
【請求項1】
第1の音声通話装置と第2の音声通話装置との間の通話を中継する処理をサーバが実行する通信中継方法であって、
前記第1の音声通話装置と前記第2の音声通話装置との接続要求を、前記サーバが、第1のネットワークを通じて前記第1の音声通話装置から受信する受信工程と、
前記受信工程で受信された前記接続要求が転送されることになる第2のネットワークを、前記サーバが特定する特定工程と、
前記第1のネットワークと前記特定工程で特定された第2のネットワークとが同一でない場合に、前記サーバが、前記接続要求を前記第2のネットワークを通じて前記第2の音声通話装置に送信する送信工程と、
を含むことを特徴とする通信中継方法。
【請求項2】
前記第1のネットワークと前記第2のネットワークとが同一である場合に、前記サーバが、前記接続要求を破棄する破棄工程を含むことを特徴とする請求項1に記載の通信中継方法。
【請求項3】
第1の音声通話装置と第2の音声通話装置との間の通話を中継する処理をサーバに実行させる通信中継プログラムであって、
前記第1の音声通話装置と前記第2の音声通話装置との接続要求を、前記サーバが、第1のネットワークを通じて前記第1の音声通話装置から受信する受信工程と、
前記受信工程で受信された前記接続要求が転送されることになる第2のネットワークを、前記サーバが特定する特定工程と、
前記第1のネットワークと前記特定工程で特定された第2のネットワークとが同一でない場合に、前記サーバが、前記接続要求を前記第2のネットワークを通じて前記第2の音声通話装置に送信する送信工程と、
を前記サーバに実行させることを特徴とする通信中継プログラム。
【請求項4】
前記第1のネットワークと前記第2のネットワークとが同一である場合に、前記サーバが、前記接続要求を破棄する破棄工程を前記サーバに実行させることを特徴とする請求項3に記載の通信中継プログラム。
【請求項5】
第1の音声通話装置と第2の音声通話装置との間の通話を中継する処理を実行する通信中継装置であって、
前記第1の音声通話装置と前記第2の音声通話装置との接続要求を、第1のネットワークを通じて前記第1の音声通話装置から受信する受信手段と、
前記受信手段で受信された前記接続要求が転送されることになる第2のネットワークを特定する特定手段と、
前記第1のネットワークと前記特定手段で特定された第2のネットワークとが同一でない場合に、前記接続要求を前記第2のネットワークを通じて前記第2の音声通話装置に送信する送信手段と、
を備えることを特徴とする通信中継装置。
【請求項6】
前記第1のネットワークと前記第2のネットワークとが同一である場合に、前記接続要求を破棄する破棄手段を備えることを特徴とする請求項5に記載の通信中継装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【公開番号】特開2012−170151(P2012−170151A)
【公開日】平成24年9月6日(2012.9.6)
【国際特許分類】
【出願番号】特願2012−121409(P2012−121409)
【出願日】平成24年5月28日(2012.5.28)
【分割の表示】特願2010−4395(P2010−4395)の分割
【原出願日】平成16年11月2日(2004.11.2)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
【公開日】平成24年9月6日(2012.9.6)
【国際特許分類】
【出願日】平成24年5月28日(2012.5.28)
【分割の表示】特願2010−4395(P2010−4395)の分割
【原出願日】平成16年11月2日(2004.11.2)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
[ Back to top ]