Nothing Special   »   [go: up one dir, main page]

JP2005269574A - インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム - Google Patents

インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム Download PDF

Info

Publication number
JP2005269574A
JP2005269574A JP2004083209A JP2004083209A JP2005269574A JP 2005269574 A JP2005269574 A JP 2005269574A JP 2004083209 A JP2004083209 A JP 2004083209A JP 2004083209 A JP2004083209 A JP 2004083209A JP 2005269574 A JP2005269574 A JP 2005269574A
Authority
JP
Japan
Prior art keywords
uri
telephone
destination
uris
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004083209A
Other languages
English (en)
Other versions
JP4384529B2 (ja
Inventor
Kazuto Kobayashi
和人 小林
Akira Miyajima
晃 宮嶋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Priority to JP2004083209A priority Critical patent/JP4384529B2/ja
Priority to US11/082,710 priority patent/US7508819B2/en
Priority to EP05006165A priority patent/EP1580974B1/en
Priority to DE602005025052T priority patent/DE602005025052D1/de
Publication of JP2005269574A publication Critical patent/JP2005269574A/ja
Application granted granted Critical
Publication of JP4384529B2 publication Critical patent/JP4384529B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0066Details of access arrangements to the networks
    • H04M7/0069Details of access arrangements to the networks comprising a residential gateway, e.g. those which provide an adapter for POTS or ISDN terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/42314Systems providing special services or facilities to subscribers in private branch exchanges
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/46Arrangements for calling a number of substations in a predetermined sequence until an answer is obtained
    • H04M3/465Arrangements for simultaneously calling a number of substations until an answer is obtained
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/487Arrangements for providing information services, e.g. recorded voice services or time announcements
    • H04M3/493Interactive information services, e.g. directory enquiries ; Arrangements therefor, e.g. interactive voice response [IVR] systems or voice portals
    • H04M3/4931Directory assistance systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/253Telephone sets using digital voice transmission
    • H04M1/2535Telephone sets using digital voice transmission adapted for voice communication over an Internet Protocol [IP] network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2203/00Aspects of automatic or semi-automatic exchanges
    • H04M2203/20Aspects of automatic or semi-automatic exchanges related to features of supplementary services
    • H04M2203/2044Group features, e.g. closed user group
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S379/00Telephonic communications
    • Y10S379/90Internet, e.g. Internet phone, webphone, internet-based telephony

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】 宛先の電話機と接続できない場合に同一ネットワークのグループに属する電話機に自動的にかけ直すこと。
【解決手段】 各端末(インターネット電話機)の電話番号に対応するURIを含むNAPTRリソースレコード及びURIに応じたIPアドレスを記憶し、特定の電話番号に、隣接して設置された端末の電話番号に応じた複数のURIが登録されたサーバ101と、入力された電話番号に応じてサーバ101からURI等を得て宛先に発呼する端末とを用いたインターネット電話システムにおいて、端末から特定の電話番号に対応するURIの問い合わせを受けるとサーバ101から当該電話番号に応じた複数のURIを返送し、端末からいずれかのURIに応じた宛先に発呼し、接続できない場合には発呼対象のURIを変更して異なるURIに応じた宛先に再発呼する。
【選択図】 図1

Description

本発明は、インターネットを介して通話するインターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システムに関する。
従来、この種のインターネット電話のネットワークは、以下のように構成されていた。
例えば、H.323プロトコルを用いたインターネット電話システムの場合、インターネット電話のネットワーク内にゲートキーパーという呼管理サーバを設ける。このゲートキーパーは通話したい宛先の電話番号を各電話機から一元的に受信して、前記電話番号を対応するIPアドレスに変換して、前記電話番号を発呼した電話機に返送する機能を有する。
一方、電話機では、オペレータが通話したい宛先の電話番号を入力すると、その電話番号を発呼する。電話機が前記電話番号に対応するIPアドレスをゲートキーパーから受信すると、オペレータの介在なく、前記IPアドレスに基づいて通話したい宛先の電話機に対してゲートキーパーを介してアクセスし、あるいはゲートキーパーを介さず直接アクセスする。これにより、インターネットを介した電話機間の通話が可能になる(例えば、特許文献1参照)。
また、通常、ゲートキーパーと各電話機との間にはルータが介在する。前記ルータには複数のインターネット電話機が接続され、ネットワーク上のグループを形成する。同一グループ内の電話機には、ネットワークアドレスが共通なIPアドレスが割り当てられる。通常会社のオフィスでは、同一部署の電話機はネットワーク上の同一グループとして構成される。
図28(a)は、一般的なインターネット電話システムのネットワークの構成を示す図である。同図に示すネットワークにおいては、呼管理サーバ(サーバ)2801にルータA2802とルータB2803が接続されている。ルータA2802にグループ(A)を形成するA1〜A4のインターネット電話機が接続され、ルータB2803にグループ(B)を形成するB1〜B4のインターネット電話機が接続されている。
図28(b)、(c)は、このサーバ2801において管理される、各インターネット電話機に割り当てられた電話番号とその電話番号に対応するIPアドレスとが登録された管理表を示している。図28(b)は、グループ(A)の管理表を示し、図28(c)は、グループ(B)の管理表を示している。ここで、電話番号としては会社内で用いられる内線番号を示している。
同図(b)に示すように、インターネット電話機(端末)A1〜A4には、それぞれ電話番号として1001〜1004が割り当てられ、IPアドレスとして192.168.1.1〜192.168.1.4が割り当てられている。すなわち、グループ(A)の端末には、ネットワークアドレス(192.168.1)が共通なIPアドレスとして割り当てられている。
一方、同図(c)に示すように、インターネット電話機(端末)B1〜B4には、それぞれ電話番号として2001〜2004が割り当てられ、IPアドレスとして192.168.2.1〜192.168.2.4が割り当てられている。すなわち、グループ(B)の端末には、ネットワークアドレス(192.168.2)が共通なIPアドレスとして割り当てられている。
特開2002−101198号公報(第4―5頁、第1図)
しかし、かかる従来の技術では、以下のような問題が生じていた。
即ち、ある部署の1つの電話機を宛先として電話した際、その電話機が話中の場合がある。この場合、通話者は一旦電話を切り、緊急の場合などは特に話中の電話機に隣接する電話機の番号を入力して、再度かけ直すという作業を行うことになる。このように、同一部署内の1つの電話機が話中の場合、再度改めて隣接する電話機にかけ直さなければならず、電話をする作業が大変煩雑なものになっていたという問題があった。
上述のネットワークの構成例を用いて説明する。例えば、端末A1が端末B1を宛先として電話する場合について考える。図29は、従来のインターネット電話システムにおける動作を示すシーケンス図である。
同図に示すように、端末A1から端末B1に対して電話する場合、通話者は、まず、端末B1の電話番号(2001)を入力する。この電話番号を受け付けると、端末A1は、サーバ2801に端末B1のIPアドレスを問い合わせ、端末B1のIPアドレスの通知を受ける。そして、そのIPアドレスに基づいて端末B1に発呼する。
ここで、端末B1は話中であったものとする。端末B1が話中であるため、端末B1には接続することができず、端末A1には話中音が鳴動する。この話中音を確認すると、通話者は一旦電話を切り、隣接する端末B2の電話番号(2002)を入力する。端末B1の場合と同様に、サーバ2801から端末B2のIPアドレスの通知を受けると端末B2に発呼する。
ここで、端末B2も話中であったものとする。この場合、端末B2には接続することができず、端末A1には話中音が鳴動する。この話中音を確認すると、通話者は一旦電話を切り、さらに隣接する端末B3の電話番号(2003)を入力する。端末B1、B2の場合と同様に、サーバ2801から端末B3のIPアドレスの通知を受けると端末B3に発呼する。
ここで、端末B3は、話中でなかったものとする。この場合、端末B3が話中でないため、端末A1は端末B3と接続する。そして、例えば、端末B1のオペレータへのメッセージ等を端末B3のオペレータに伝える。このように同一部署内の1つの端末が話中の場合、再度改めて隣接する端末にかけ直さなければならない事態が生じている。
本発明は、かかる問題点に鑑みて為されたものであり、通話したい宛先の電話機が応答しない場合であっても、同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができるインターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システムを提供することを目的とする。
本発明は、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及びURIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバからURI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムにおいて、インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼するようにしたものである。
本発明に係るインターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システムによれば、通話したい宛先の電話機が応答しない場合であっても、同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができる。
本発明の第1の態様に係るインターネット電話機は、入力された電話番号に対応するNAPTRリソースレコード上のURIを受信すると共に前記URIに応じたIPアドレスを受信する受信手段と、前記IPアドレスが割り当てられた宛先に発呼する発呼手段と、前記URIを複数受信した場合であっていずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させる制御手段と、を具備する構成を採る。
この構成によれば、サーバから受信した複数のURIのうち、いずれかのURIに対応する宛先と接続できない場合には他のURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。特に、複数の電話機と連続して接続できないような場合、操作負担を軽減する効果は一層大きくなる。
本発明の第2の態様に係るインターネット電話機は、入力された電話番号に対応するNAPTRリソースレコード上のURI及びPreferenceフィールドの設定値を受信すると共に前記URIに応じたIPアドレスを受信する受信手段と、前記IPアドレスが割り当てられた宛先に発呼する発呼手段と、前記URIを複数受信した場合であって前記設定値が差異を有する場合には当該設定値の大小関係に応じて発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させる制御手段と、を具備する構成を採る。
この構成によれば、サーバから複数のURIを受信した場合であってPreferenceフィールドの設定値が差異を有する場合、いずれかのURIに対応する宛先と接続できない場合には他のURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
特に、Preferenceフィールドの設定値の大小関係に応じて発呼動作が行われる。これにより、Preferenceフィールドの設定値に応じて発呼順序が決定されるので、発呼順序を指定することができる。
本発明の第3の態様は、第2の態様に係るインターネット電話機において、前記制御手段は、前記設定値が小さいURIに対応する宛先から優先して発呼させる構成を採る。
この構成によれば、Preferenceフィールドの設定値が小さいURIに対応する宛先から優先して発呼されるので、発呼させたい順番に設定値を定めることで発呼順序を指定することができる。
本発明の第4の態様は、第2の態様に係るインターネット電話機において、前記制御手段は、前記URIを複数受信した場合であって前記設定値が同一の場合には全てのURIに対応する宛先に一斉に発呼させる構成を採る。
この構成によれば、Preferenceフィールドの設定値が同一の場合には全てのURIに対応する宛先に一斉に発呼される。これにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。
本発明の第5の態様は、第2の態様に係るインターネット電話機において、前記制御手段は、前記設定値を無視する指示を受け付けると前記設定値を無視して全てのURIに対応する宛先に一斉に発呼させる構成を採る。
この構成によれば、Preferenceフィールドの設定値を無視する指示を受け付けると、この設定値を無視して全てのURIに対応する宛先に一斉に発呼する。これにより、設定値が差異を有する場合においても、この設定を無視する指示を受け付けた場合には全てのURIに対応する宛先に一斉に発呼される。これにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。
本発明の第6の態様に係るインターネット電話機は、入力された電話番号に対応するNAPTRリソースレコード上のURI及びServiceフィールドに設定された通信種別を受信すると共に前記URIに応じたIPアドレスを受信する受信手段と、前記IPアドレスが割り当てられた宛先に発呼する発呼手段と、前記URIを複数受信した場合であって前記通信種別にsip及びsip以外の通信種別が存在する場合には前記通信種別にsipと設定されたURIに対応する宛先に発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させ、前記通信種別にsipと設定された全てのURIに対応する宛先と接続できなかった場合にはsip以外の通信種別が設定されたURIに対して当該通信種別に応じた処理を実行させる制御手段と、を具備する構成を採る。
この構成によれば、サーバから複数のURIを受信した場合であってServiceフィールドに設定された通信種別(プロトコル)にsip及びsip以外の通信種別が存在する場合、通信種別にsipと設定されたURIに対応する宛先に発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
また、Serviceフィールドに設定された通信種別にsipと設定された全てのURIに対応する宛先と接続できなかった場合にはsip以外の通信種別が設定されたURIに対して当該通信種別に応じた処理を実行する。これにより、sipと設定された全てのURIに対応する宛先と接続できなかった場合においても、予めsip以外の通信種別を用いた処理を登録しておくことで接続できなかった宛先に対して何らかの意図を伝達することができる。
本発明の第7の態様は、第6の態様に係るインターネット電話機において、前記受信手段は、前記sip以外の通信種別として電子メール又は電話でのFAXを受信し、前記制御手段は、前記電子メール又は電話でのFAXと設定されたURIが示す宛先に予め用意された定型文を送信する構成を採る。
この構成によれば、Serviceフィールドに設定された通信種別にsipと設定された全てのURIに対応する宛先と接続できなかった場合に電子メール又は電話でのFAXと設定されたURIが示す宛先に予め用意された定型文が送信される。これにより、例えば、定型文に折り返し電話が欲しい旨を通知する文章を設定しておくことで、接続できなかった宛先に対して折り返し電話が欲しい意図を伝達することができる。
本発明の第8の態様に係るインターネット電話機は、入力された電話番号に対応するNAPTRリソースレコード上のURIを受信すると共に前記URIに応じた識別情報及びIPアドレスを受信する受信手段と、前記IPアドレスが割り当てられた宛先に発呼する発呼手段と、前記URIを複数受信した場合であって前記識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させる制御手段と、を具備する構成を採る。
この構成によれば、サーバから複数のURIを受信した場合であって識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼動作を行い、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力し発呼順序を指定するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
特に、オペレータから指定された発呼順序に従って発呼動作が行われる。これにより、発呼元のオペレータにおいて要件を伝達したい発呼先のオペレータを指定することができる。この結果、要件に関連しないオペレータの作業等を阻害する事態を事前に回避することができる。
本発明の第9の態様に係るインターネット電話機は、入力された電話番号に対応するNAPTRリソースレコード上のポート番号を含むURIを受信すると共に前記URIに応じたIPアドレスを受信する受信手段と、前記IPアドレス及びポート番号で特定される宛先に発呼する発呼手段と、前記URIを複数受信した場合であっていずれかのURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先に再発呼させる制御手段と、を具備する構成を採る。
この構成によれば、サーバから複数のURIを受信した場合であって当該URIにポート番号が含まれる場合、いずれかのURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
特に、URIに含まれるポート番号とURIに応じたIPアドレスとで特定される宛先に対して発呼するので、例えば、インターネット電話機にプライベートIPアドレスが割り当てられている場合等、外部のネットワークから直接アクセスできないような状況下においても同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができる。
本発明の第10の態様は、第1から第9のいずれかの態様に係るインターネット電話機において、前記制御手段は、発呼した宛先が話中の場合又は所定時間継続して応答しない場合に発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させる構成を採る。
この構成によれば、発呼した宛先が話中の場合又は所定時間継続して応答しない場合に発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼する。これにより、話中や所定時間継続して応答しない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
本発明の第11の態様に係るネットワークサーバは、ネットワークを介して接続するインターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶する記憶手段と、前記電話番号に対応するURI並びに当該URIに応じたIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録する構成を採る。
この構成によれば、特定の電話番号に対応するURIの問い合わせを受けると隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを返送する。URIを問い合わせたインターネット電話機において、受信した複数のURIのうち、いずれかのURIに対応する宛先と接続できない場合には他のURIに対応する宛先に再発呼することにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
本発明の第12の態様に係るネットワークサーバは、ネットワークを介して接続するインターネット電話機の電話番号に対応するURI及びPreferenceフィールドの設定値を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶する記憶手段と、前記電話番号に対応するURI及び設定値並びに当該URIに応じたIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記設定値に差異を有する値を登録する構成を採る。
この構成によれば、特定の電話番号に対応するURIの問い合わせを受けると、隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び差異を有する設定値を返送する。URIを問い合わせたインターネット電話機において、複数のURIを受信した場合であってPreferenceフィールドの設定値が差異を有する場合、いずれかのURIに対応する宛先と接続できない場合には他のURIに対応する宛先に再発呼することにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
特に、URIを問い合わせたインターネット電話機において、Preferenceフィールドの設定値の大小関係に応じて発呼動作を行うことにより、Preferenceフィールドの設定値に応じて発呼順序が決定されるので、発呼順序を指定することができる。
本発明の第13の態様は、第12の態様に係るネットワークサーバにおいて、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記設定値に同一の値を登録する構成を採る。
この構成によれば、特定の電話番号に対応するURIの問い合わせを受けると隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び同一の設定値を返送する。URIを問い合わせたインターネット電話機において、設定値が同一の場合には全てのURIに対応する宛先に一斉に発呼することにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。
本発明の第14の態様に係るネットワークサーバは、ネットワークを介して接続するインターネット電話機の電話番号に対応するURI及びServiceフィールドの通信種別を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶する記憶手段と、前記電話番号に対応するURI及び通信種別並びに当該URIに応じたIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記通信種別にsip及びsip以外の通信種別を登録する構成を採る。
この構成によれば、特定の電話番号に対応するURIの問い合わせを受けると、隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び当該複数のURIに応じたsip及びsip以外の通信種別を返送する。URIを問い合わせたインターネット電話機において、複数のURIを受信した場合であってServiceフィールドに設定された通信種別にsip及びsip以外の通信種別が存在する場合、通信種別にsipと設定されたURIに対応する宛先に発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼することにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
また、URIを問い合わせたインターネット電話機において、Serviceフィールドに設定された通信種別にsipと設定された全てのURIに対応する宛先と接続できなかった場合にはsip以外の通信種別が設定されたURIに対して当該通信種別に応じた処理を実行することにより、sipと設定された全てのURIに対応する宛先と接続できなかった場合においても、予めsip以外の通信種別を用いた処理を登録しておくことで接続できなかった宛先に対して何らかの意図を伝達することができる。
本発明の第15の態様は、第14の態様に係るネットワークサーバにおいて、前記記憶手段は、前記sip以外の通信種別として電子メール又は電話でのFAXを登録する構成を採る。
この構成によれば、URIを問い合わせたインターネット電話機において、Serviceフィールドに設定された通信種別にsipと設定された全てのURIに対応する宛先と接続できなかった場合に電子メール又は電話でのFAXと設定されたURIが示す宛先に予め用意された定型文を送信することにより、例えば、定型文に折り返し電話が欲しい旨を通知する文章を設定しておくことで、接続できなかった宛先に対して折り返し電話が欲しい意図を伝達することができる。
本発明の第16の態様に係るネットワークサーバは、ネットワークを介して接続するインターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及び前記URIに応じた識別情報及びIPアドレスを記憶する記憶手段と、前記電話番号に対応するURI並びに当該URIに応じた識別情報及びIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び当該複数のURIに応じた前記識別情報を登録する構成を採る。
この構成によれば、特定の電話番号に対応するURIの問い合わせを受けると、隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び当該複数のURIに応じた識別情報を返送する。URIを問い合わせたインターネット電話機において、複数のURIを受信した場合であって識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼動作を行い、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼することにより、オペレータは単に電話番号を入力し発呼順序を指定するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
特に、URIを問い合わせたインターネット電話機において、オペレータから指定された発呼順序に従って発呼動作を行うことにより、発呼元のオペレータにおいて要件を伝達したい発呼先のオペレータを指定することができる。この結果、要件に関連しないオペレータの作業等を阻害する事態を事前に回避することができる。
本発明の第17の態様に係るネットワークサーバは、ネットワークを介して接続するインターネット電話機の電話番号に対応しポート番号を有するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶する記憶手段と、前記電話番号に対応しポート番号を有するURI並びに当該URIに応じたIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録する構成を採る。
この構成によれば、特定の電話番号に対応するURIの問い合わせを受けると、隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを返送する。この返送されるURIにはポート番号を含んでいる。URIを問い合わせたインターネット電話機において、複数のURIを受信した場合であって当該URIにポート番号が含まれる場合、いずれかのURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先に再発呼することにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
特に、URIを問い合わせたインターネット電話機において、URIに含まれるポート番号とURIに応じたIPアドレスとで特定される宛先に対して発呼することにより、例えば、インターネット電話機にプライベートIPアドレスが割り当てられている場合等、外部のネットワークから直接アクセスできないような状況下においても同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができる。
本発明の第18の態様に係る通話方法は、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼するものである。
本発明の第19の態様に係る通話方法は、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI及びPreferenceフィールドの設定値を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び前記設定値に差異を有する値が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに応じた前記設定値を返送し、インターネット電話機から前記設定値の大小関係に応じていずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼するものである。
本発明の第20の態様は、第19の態様に係る通話方法において、前記サーバは、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記設定値に同一の値を登録し、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに応じた前記設定値を返送し、インターネット電話機で前記設定値が差異を有する場合には当該設定値の大小関係に応じて発呼動作を行い、いずれかのURIに応じたIPアドレスの宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼する一方、前記設定値が同一の場合には全てのURIに応じたIPアドレスの宛先に一斉に発呼するものである。
本発明の第21の態様に係る通話方法は、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI及びServiceフィールドに設定された通信種別を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び前記通信種別にsip及びsip以外の通信種別が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに対応する通信種別を返送し、インターネット電話機で前記通信種別にsip及びsip以外の通信種別が存在する場合には前記通信種別にsipと設定されたURIに応じたIPアドレスの宛先に発呼動作を行わせ、いずれかのURIに応じたIPアドレスの宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼し、前記通信種別にsipと設定された全てのURIに応じたIPアドレスの宛先と接続できなかった場合にはsip以外の通信種別が設定されたURIに対して当該通信種別に応じた処理を実行するものである。
本発明の第22の態様に係る通話方法は、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI並びに前記URIに応じた識別情報及びIPアドレスを記憶し、特定の電話番号に応じて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び識別情報が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに対応する識別情報を返送し、前記識別情報に応じて発呼順序の指定を受けるとインターネット電話機から当該発呼順序に従って発呼動作を行い、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼するものである。
本発明の第23の態様に係る通話方法は、ネットワークを介して接続する各インターネット電話機の電話番号に対応しポート番号を有するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレス及び当該URIが有するポート番号で特定される宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレス及び当該URIが有するポート番号で特定される宛先に再発呼するものである。
本発明の第24の態様に係るインターネット電話システムは、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼するものである。
本発明の第25の態様に係るインターネット電話システムは、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI及びPreferenceフィールドの設定値を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び前記設定値に差異を有する値が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに応じた前記設定値を返送し、インターネット電話機から前記設定値の大小関係に応じていずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼するものである。
本発明の第26の態様は、第25の態様に係るインターネット電話システムにおいて、前記サーバは、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記設定値に同一の値を登録し、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに応じた前記設定値を返送し、インターネット電話機で前記設定値が差異を有する場合には当該設定値の大小関係に応じて発呼動作を行い、いずれかのURIに応じたIPアドレスの宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼する一方、前記設定値が同一の場合には全てのURIに応じたIPアドレスの宛先に一斉に発呼するものである。
本発明の第27の態様に係るインターネット電話システムは、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI及びServiceフィールドに設定された通信種別を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び前記通信種別にsip及びsip以外の通信種別が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに対応する通信種別を返送し、インターネット電話機で前記通信種別にsip及びsip以外の通信種別が存在する場合には前記通信種別にsipと設定されたURIに応じたIPアドレスの宛先に発呼動作を行わせ、いずれかのURIに応じたIPアドレスの宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼し、前記通信種別にsipと設定された全てのURIに応じたIPアドレスの宛先と接続できなかった場合にはsip以外の通信種別が設定されたURIに対して当該通信種別に応じた処理を実行するものである。
本発明の第28の態様に係るインターネット電話システムは、ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI並びに前記URIに応じた識別情報及びIPアドレスを記憶し、特定の電話番号に応じて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び識別情報が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに対応する識別情報を返送し、前記識別情報に応じて発呼順序の指定を受けるとインターネット電話機から当該発呼順序に従って発呼動作を行い、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼するものである。
本発明の第29の態様に係るインターネット電話システムは、ネットワークを介して接続する各インターネット電話機の電話番号に対応しポート番号を有するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレス及び当該URIが有するポート番号で特定される宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレス及び当該URIが有するポート番号で特定される宛先に再発呼するものである。
以下、本発明の実施の形態について図面を参照して詳細に説明する。
(実施の形態1)
図1は、本発明の実施の形態1に係るインターネット電話機が適用されるネットワークの構成を示す図である。同図に示すネットワークにおいては、呼管理サーバ(以下、「サーバ」という)101にルータA102とルータB103が接続されている。ルータA102にグループ(A)を形成するA1〜A4のインターネット電話機が接続され、ルータB103にグループ(B)を形成するB1〜B4のインターネット電話機が接続されている。それぞれのグループは、会社内の部署毎に設定され、部署におけるインターネット電話機の配置は、同図に示す配置と同一であるものとする。
なお、図1においては、各ルータにインターネット電話機が接続された場合について示しているが、このインターネット電話機は、通常の電話機(インターネット電話機の機能を有しないもの)をインターネット電話機の機能を実現させる制御装置(以下、「制御アダプタ」という)に接続して構成してもよい。以下の本実施の形態の説明では、かかる制御アダプタに通常の電話機を接続したものをインターネット電話機として説明する。
図2は、図1に示すネットワークに接続されたインターネット電話機に割り当てられた電話番号及びIPアドレスを示す図である。図2(a)はグループ(A)を構成するインターネット電話機に割り当てられた電話番号及びIPアドレスを示し、図2(b)はグループ(B)を構成するインターネット電話機に割り当てられた電話番号及びIPアドレスを示している。
同図(a)に示すように、インターネット電話機(端末)A1〜A4には、それぞれ電話番号として0310000000〜0310000003が割り当てられ、IPアドレスとして192.168.1.1〜192.168.1.4が割り当てられている。また、同図(b)に示すように、インターネット電話機(端末)B1〜B4には、それぞれ電話番号として0310001000〜0310001003が割り当てられ、IPアドレスとして192.168.2.1〜192.168.2.4が割り当てられている。なお、グループ(A)及びグループ(B)においてはそれぞれ端末A1及び端末B1に割り当てられた電話番号が代表番号とされている。
図3は、実施の形態1に係るインターネット電話機の構成を示すブロック図である。
同図に示すように、本実施の形態に係るインターネット電話機は、制御アダプタ301に通常の電話機302を接続して構成される。なお、本実施の形態に係る制御アダプタ301は、2台の通常の電話機302を接続可能であり、各電話機をインターネット電話機として機能させることができる。なお、制御アダプタ301が接続可能な電話機を3台以上にすることも当然に可能である。
制御アダプタ301は、装置本体の全体を制御するCPU303を備えている。このCPU303に制御バス304を介してROM305及びRAM306が接続されている。ROM305には、CPU303が読み込んで実行する本制御アダプタ301の制御プログラムが格納されている。RAM306は、CPU303が制御プログラムを実行する際のワークメモリとして機能する。なお、本制御アダプタ301においては、ROM305としてフラッシュROMを用い、RAM306としてSDRAMを用いる。
また、CPU303にポート307を介してクロスポイントミキサ308が接続されている。クロスポイントミキサ308は、後述するNCUを介して接続された2台の電話機に提供する通話路の切換え機能及びミキシング機能を備える。
クロスポイントミキサ308にNCU(Network Control Unit)309が接続されている。NCU309は、本制御アダプタ301に接続された電話回線を制御して通信相手との回線の接続又は切断を行う。
さらに、CPU303に制御バス304を介してA/D・D/ACODEC310及びLANコントローラ311が接続されている。A/D・D/ACODEC310は、電話機302から入力された音声データのアナログ/デジタル変換を行った後、圧縮処理を施す。一方、LANコントローラ311を介して受け取った圧縮データを復元した後、デジタル/アナログ変換処理を施す。
LANコントローラ311は、本制御アダプタ301が接続されたネットワークを構成するイーサネット(R)との間で信号の制御を行う。なお、ネットワーク上を送信されるパケットデータの組立て及び解析は、LANコントローラ311によって行われる。
なお、以上の制御アダプタ301に通常の電話機を接続せずに、インターネット電話機でかかる構成を実現する場合には、本制御アダプタ301の機能を有する制御ボードをインターネット電話機に搭載することで実現可能である。
図4は、実施の形態1に係るサーバ101の概略構成を示すブロック図である。実施の形態1に係るサーバ101は、ホスト名の問い合わせに応じてIPアドレスを通知するDNS(Domain Name System)サーバとしての機能を有する。特に、本実施の形態では、ホスト名が電話番号で特定されるENUM(Telephone Number Mapping)技術を取り入れたサーバ(ENUMサーバ)としての機能を有する。
同図に示すように、実施の形態1に係るサーバ101は、サーバ101全体の制御を行う制御手段としてのCPU401を備えている。このCPU401に制御バス402を介して記憶手段としてのメモリ403、ネットワークインターフェイス(I/F)404及び入出力装置405が接続されている。
メモリ403は、CPU401が読み込んで実行する本サーバ101の制御プログラムを格納するROM及びCPU401が制御プログラムを実行する際のワークメモリとして機能するRAMの機能を有する。
メモリ403は、ネットワークを介して接続された各インターネット電話機に割り当てられた電話番号からURI(Uniform Resource Identifier)への変換を行うためのデータベースを格納している。かかるデータベースにおいて、データはNAPTR(The Naming Authority Pointer)と呼ばれるリソースレコード(以下、「NAPTRリソースレコード」という)で記述されている。NAPTRリソースレコードは、単一又は複数のNAPTRレコードから構成される。また、メモリ403は、電話番号から変換されたURIと対応付けられるIPアドレスを登録している。
ネットワークI/F404は、本サーバ101が接続されたネットワークを構成するイーサネット(R)との間で信号の制御を行う。入出力装置405は、キーボードやマウス等の入力手段と液晶モニタ等の出力手段で構成され、オペレータの入力を受け付ける一方、本サーバ101における動作状態を出力する。
図5は、実施の形態1に係るサーバ101のメモリ403に記述されたNAPTRリソースレコードの一例を示す図である。図5(a)は、図1に示すグループ(A)に対応したNAPTRリソースレコードを示し、図5(b)は、図1に示すグループ(B)に対応したNAPTRリソースレコードを示している。
図5(a)に示すように、端末A1の電話番号(代表番号)「0310000000」から得られるドメイン名「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」に対して4つのURI「81310000000@tokyo.sip.jp」、「81310000001@tokyo.sip.jp」、「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」が対応付けられている。同様に、端末A2、A3及びA4の電話番号「0310000001」、「0310000002」及び「0310000003」から得られるドメイン名「1.0.0.0.0.0.0.1.3.1.8.e164.arpa」、「2.0.0.0.0.0.0.1.3.1.8.e164.arpa」及び「3.0.0.0.0.0.0.1.3.1.8.e164.arpa」にそれぞれURI「81310000001@tokyo.sip.jp」、「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」が対応付けられている。このように端末A1の電話番号から得られるドメイン名に対して、端末A1に対応するURIのみならず、端末A2〜A4に対応するURIも対応付けられている。
また、図5(b)に示すように、端末B1の電話番号(代表番号)「0310010000」から得られるドメイン名「0.0.0.1.0.0.0.1.3.1.8.e164.arpa」に4つのURI「81310001000@tokyo.sip.jp」、「81310001001@tokyo.sip.jp」、「81310001002@tokyo.sip.jp」及び「81310010003@tokyo.sip.jp」が対応付けられている。同様に、端末B2、B3及びB4の電話番号「0310001001」、「0310001002」及び「0310001003」から得られるドメイン名「1.0.0.1.0.0.0.1.3.1.8.e164.arpa」、「2.0.0.1.0.0.0.1.3.1.8.e164.arpa」及び「3.0.0.1.0.0.0.1.3.1.8.e164.arpa」にそれぞれURI「81310001001@tokyo.sip.jp」、「81310001002@tokyo.sip.jp」及び「81310001003@tokyo.sip.jp」が対応付けられている。図5(a)と同様に、端末B1の電話番号から得られるドメイン名に対して、端末B1に対応するURIのみならず、端末B2〜B4に対応するURIも対応付けられている。
図6は、実施の形態1に係るサーバ101のメモリ403に記憶されたURI及びIPアドレスの対応関係の一例を示す図である。図6(a)は、図1に示すグループ(A)に対応するURI及びIPアドレスを示し、図6(b)は、図1に示すグループ(B)に対応するURI及びIPアドレスを示している。
図6(a)に示すように、URI「81310000000@tokyo.sip.jp」、「81310000001@tokyo.sip.jp」、「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」にそれぞれIPアドレス「192.168.1.1」、「192.168.1.2」、「192.168.1.3」及び「192.168.1.4」が対応付けられている。
また、図6(b)に示すように、URI「81310001000@tokyo.sip.jp」、「81310001001@tokyo.sip.jp」、「81310001002@tokyo.sip.jp」及び「81310001003@tokyo.sip.jp」にそれぞれIPアドレス「192.168.2.1」、「192.168.2.2」、「192.168.2.3」及び「192.168.2.4」が対応付けられている。
以下、上記構成を有するサーバ101に接続された本インターネット電話機間で発呼を行う場合の動作について図7を用いて説明する。ここでは、特に端末B1からグループ(A)に含まれる端末に発呼する場合の動作について説明する。なお、サーバ101のメモリ403には、図5に示すNAPTRリソースレコード及び図6に示す対応表が登録されているものとする。
グループ(A)の端末に発呼する場合、端末B1は、端末A1〜A4のいずれかの電話番号の入力をオペレータから受け付ける(ST701)。例えば、端末A1に対して発呼する場合には、「0310000000」あるいは「03」を省略した「10000000」の入力をオペレータから受け付ける。
電話番号を受け付けると、端末B1は、この電話番号に対応するURIをサーバ101に対して問い合わせる(ST702)。上述の例の場合、端末B1は、オペレータが入力した「0310000000」を国番号付きのE.164番号である「+81−3−10000000」に変換し、先頭の+と数字を残して「+81310000000」としてから数字以外の文字を抹消して数字間にドットを挿入して「8.1.3.1.0.0.0.0.0.0.0」とし、次に数字を逆順にして最後に文字列.e164.arpaを追加することにより、ドメイン名である「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」を得て、この文字列に対応するURIを問い合わせる。
URIの問い合わせを受けると、サーバ101がメモリ403に格納されたNAPTRリソースレコードに従ってURIを返してくるので、端末B1は、このURIを受信する(ST703)。上述の例の場合、サーバ101は、図5(a)に示したNAPTRリソースレコードに従って、上記文字列に対応する4つのURI「81310000000@tokyo.sip.jp」、「81310000001@tokyo.sip.jp」、「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」を返してくる。
URIを受信したならば、端末B1は、URIが複数存在するか判断する(ST704)。ここでURIが複数存在するか判断するのは、後述する通常発呼処理及びグループ発呼処理のいずれを行うべきか判断するためである。
URIが複数存在しない場合、すなわち、単一のURIを受信した場合には処理をST705に移行し通常発呼処理を行う。一方、複数存在する場合、すなわち、複数のURIを受信した場合には処理をST706に移行しグループ発呼処理を行う。通常発呼処理においては単一の宛先に対して発呼処理が行われるのに対し、グループ発呼処理においては複数の宛先に対して発呼処理が行われる。上述の例の場合には、4つのURIが存在するのでグループ発呼処理が行われる。なお、通常発呼処理及びグループ発呼処理の詳細な処理については後述する。
通常発呼処理又はグループ発呼処理を行った後、端末B1は、いずれかの発呼処理の結果(以下、「発呼結果」という)の状態が「通話OK」であるか判断する(ST707)。発呼結果の状態には「通話OK」、「通話NG」及び「待機中」があり、いずれかの状態がRAM306上の所定領域に登録される。
発呼結果の状態が「通話OK」の場合には通話処理に移行する一方(ST708)、「通話OK」以外の場合には切断処理に移行する(ST709)。通話処理においては、端末B1のオペレータと発呼先のオペレータとの通話が終わり次第、端末B1による発呼処理が終了する。切断処理においては、移行すると同時に端末B1による発呼処理が終了する。
ここで、実施の形態1における通常発呼処理について図8を用いて説明する。図8は、実施の形態1における通常発呼処理について説明するためのフロー図である。
通常発呼処理に移行した場合、端末B1は、受信したURIに対応するIPアドレスをサーバ101に問い合わせる(ST801)。例えば、「81310000001@tokyo.sip.jp」をURIとして受信した場合には、このURIに対応するIPアドレスをサーバ101に問い合わせる。
IPアドレスの問い合わせを受けると、サーバ101がメモリ403に登録された対応表に従ってIPアドレスを返してくるので、端末B1は、このIPアドレスを受信する(ST802)。上述の例の場合、サーバ101は、図6(a)に示した対応表に従って、IPアドレス「192.168.1.2」を返してくる。
IPアドレスを受信したならば、端末B1は、発呼結果の状態を初期化する(ST803)。具体的には、発呼結果の状態を「待機中」に設定することにより発呼結果の状態を初期化する。
次に、端末B1は、受信したIPアドレスに対して発呼処理を行う(ST804)。上述の例の場合、「192.168.1.2」に対して発呼処理を行う。すなわち、端末A2に対して発呼処理が行われる。
発呼処理を行った後、端末B1は、当該宛先と接続できたかを判断する(ST805)。ここで、接続できたならば、端末B1は、発呼結果の状態を「通話OK」に切り替えて(ST806)、通常発呼処理を終了する。一方、接続できなかったならば、端末B1は、発呼結果の状態を「通話NG」に切り替えて(ST807)、通常発呼処理を終了する。このように通常発呼処理においては単一の宛先に対して発呼処理を行い、その宛先に対する接続の可否に応じて発呼結果の状態が切り替えられる。
なお、宛先と接続できない場合としては、例えば、宛先が話中である場合や宛先のオペレータが不在で所定時間応答しない場合(無応答の場合)が該当する。無応答の場合には、タイマで所定時間をカウントし、所定時間継続して宛先からリングバックトーンを示す信号が出力された場合に接続できないと判断することが一般的である。
次に、実施の形態1におけるグループ発呼処理について図9を用いて説明する。図9は、実施の形態1におけるグループ発呼処理について説明するためのフロー図である。
グループ発呼処理に移行した場合、端末B1は、受信したURIに対応するIPアドレスをサーバ101に問い合わせる(ST901)。グループ発呼処理に移行した場合には複数のURIが受信されているため、端末B1は、いずれかのURIに対応するIPアドレスをサーバ101に問い合わせる。例えば、「81310000000@tokyo.sip.jp」、「81310000001@tokyo.sip.jp」、「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」をURIとして受信した場合には、いずれかのURIに対応するIPアドレスをサーバ101に問い合わせる。
端末B1からこのURIによりIPアドレスの問い合わせを受けると、通常発呼処理における説明と同様に、サーバ101からIPアドレスが返されてくるので、端末B1は、これを受信する(ST902)。IPアドレスを受信したならば、発呼結果の状態を初期化した後(ST903)、受信したIPアドレスに対して発呼処理を行う(ST904)。そして、当該宛先と接続できたかを判断し(ST905)、接続できたならば、発呼結果の状態を「通話OK」に切り替えて(ST906)、グループ発呼処理を終了する。
これに対して、接続できなかった場合には、端末B1は、対応するIPアドレスを問い合わせしていないURIが存在するか判断する(ST907)。問い合わせしていないURIが存在するならば、端末B1は、処理をST901に戻し、問い合わせしていないURIが存在しなくなるまでST901〜ST907の処理を繰り返す。4つのURIを受信した場合には最高4回までST901〜ST907の処理が行われる。
ST901〜ST907の処理を繰り返すうちにIPアドレスを問い合わせしていないURIが存在しなくなったならば、端末B1は、発呼結果の状態を「通話NG」に切り替えて(ST908)、グループ発呼処理を終了する。このようにグループ発呼処理においては複数の宛先に対して発呼処理を行い、全ての宛先に対して接続ができなかった場合に発呼結果の状態が「通話NG」に設定される。
なお、ここでは、対応するIPアドレスを問い合わせるURIを任意に選択可能とし、特にそのURIの優先順位は決めていない。問い合わせしていないURIが存在しなくなった時点でST908において発呼結果が「通話NG」と切り替えられることとなる。
以下、このグループ発呼処理を実行することで、端末B1とグループ(A)に含まれる端末との間で行われるシーケンスについて図10を用いて説明する。なお、図10においては、端末B1から端末A1に割り当てられた代表番号「0310000000」を発呼した場合のシーケンスについて示している。
端末B1のオペレータから電話番号「0310000000」の入力を受け付けると、端末B1は、かかる電話番号に対応するURIを問い合わせる(ST1001)。これに応じてサーバ101から当該電話番号に対応するURIの通知を受ける(ST1002)。このとき、端末B1は、「81310000000@tokyo.sip.jp」、「81310000001@tokyo.sip.jp」、「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」の4つのURIの通知を受ける。
次に、端末B1は、いずれかのURIに対応するIPアドレスを問い合わせ(ST1003)、サーバ101から当該URIに対応するIPアドレスの通知を受ける(ST1004)。ここでは、URI「81310000000@tokyo.sip.jp」に対応するIPアドレスを問い合わせ、IPアドレス「192.168.1.1」の通知を受けたものとする。IPアドレスの通知を受けると、端末B1は、当該IPアドレスに対して発呼する(ST1005)。これにより、端末A1に対する発呼処理が行われる。
ここで、端末A1は、話中等で接続ができなかったものとする。この場合、端末B1は、先にIPアドレスを問い合わせしたURI以外のいずれかのURIに対応するIPアドレスを問い合わせ(ST1006)、サーバ101から当該URIに対応するIPアドレスの通知を受ける(ST1007)。ここでは、URI「81310000001@tokyo.sip.jp」に対応するIPアドレスを問い合わせ、IPアドレス「192.168.1.2」の通知を受けたものとする。IPアドレスの通知を受けると、端末B1は、当該IPアドレスに対して発呼する(ST1008)。これにより、端末A2に対する発呼処理が行われる。
ここで、端末A2も、話中等で接続ができなかったものとする。この場合、端末B1は、更に先にIPアドレスを問い合わせしたURI以外のいずれかのURIに対応するIPアドレスを問い合わせ(ST1009)、サーバ101から当該URIに対応するIPアドレスの通知を受ける(ST1010)。ここでは、URI「81310000002@tokyo.sip.jp」に対応するIPアドレスを問い合わせ、IPアドレス「192.168.1.3」の通知を受けたものとする。IPアドレスの通知を受けると、端末B1は、当該IPアドレスに対して発呼する(ST1011)。これにより、端末A3に対する発呼処理が行われる。
ここで、端末A3は、話中等で接続ができない事態にないものとする。したがって、端末B1は、端末A3を利用するオペレータと通話することが可能となる。なお、ここでは、対応するIPアドレスを問い合わせるURIの順番として、端末A1、端末A2、端末A3の順番に処理を行ったが、当該順番は一例に過ぎず、他のどのような順番で処理を行うようにしてもよい。
このように実施の形態1に係るインターネット電話機によれば、サーバ101から受信した複数のURIのうち、いずれかのURIに対応する宛先と接続できない場合には他のURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。特に、複数の電話機と連続して接続できないような場合、操作負担を軽減する効果は一層大きくなる。
特に、実施の形態1に係るインターネット電話機においては、発呼した宛先が話中の場合又は所定時間継続して応答しない場合に発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼する。これにより、話中や所定時間継続して応答しない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。かかる効果は以下の実施の形態においても同様である。
(実施の形態2)
実施の形態1に係るインターネット電話機がサーバ101から複数のURIを受信した場合に任意のURIを選択してIPアドレスを問い合わせた後、当該IPアドレスに対応する宛先に対して発呼するのに対し、実施の形態2に係るインターネット電話機は、URIを選択する際に優先順位を設け、その優先順位に従ってIPアドレスを問い合わせた後、当該IPアドレスに対応する宛先に対して発呼する点で相違する。
実施の形態2に係るインターネット電話機は、URIを選択する際の優先順位を判断するパラメータとしてNAPTRリソースレコードに記述されたPreferenceフィールドの値(以下、「Preference値」という)を利用する。Preference値は、Orderフィールドに同じ値を有するNAPTRレコードが複数ある場合に処理順序を決めるものであるが、実施の形態2に係るインターネット電話機は、このPreference値を、URIを選択する際の優先順位を判断するパラメータとして用いることで、複数存在する宛先に対して優先順位を付けて発呼する。
図11は、実施の形態2に係るサーバ101のメモリ403に記述されたNAPTRリソースレコードの一例を示す図である。図11においては、図1に示すグループ(A)に対応したNAPTRリソースレコードを示している。
同図においては、そのPreference値を除き、図5(a)に示すNAPTRリソースレコードと同一であるため、その詳細な説明は省略する。図11に示すNAPTRリソースレコードにおいては、異なるPreference値が設定されている点で図5(a)に示すNAPTRリソースレコードと相違する。
図11においては、端末A1の電話番号(代表番号)「0310000000」から得られるドメイン名「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」に対応付けられた4つのURIのうち、「81310000000@tokyo.sip.jp」を含むNAPTRレコードのPreference値に「10」が設定されている。また、「81310000001@tokyo.sip.jp」を含むNAPTRレコードのPreference値に「20」が設定され、同様に、「81310000002@tokyo.sip.jp」を含むNAPTRレコードのPreference値に「30」が設定され、「81310000003@tokyo.sip.jp」を含むNAPTRレコードのPreference値に「40」が設定されている。
以下、上記構成を有するサーバ101に接続された本インターネット電話機間で発呼を行う場合の動作について図12を用いて説明する。ここでは、特に端末B1からグループ(A)に含まれる端末に発呼する場合の動作について説明する。なお、サーバ101のメモリ403には、図11及び図6に示す内容が登録されているものとする。
グループ(A)の端末に発呼する場合、端末B1は、端末A1〜A4のいずれかの電話番号の入力をオペレータから受け付ける(ST1201)。例えば、端末A1に対して発呼する場合には、「0310000000」あるいは「03」を省略した「10000000」をオペレータから受け付ける。
電話番号を受け付けると、端末B1は、この電話番号に対応するURI及びPreference値をサーバ101に対して問い合わせる(ST1202)。上述の例の場合、端末B1は、「0310000000(10000000)」から文字列「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」を得て、この文字列に対応するURI及びPreference値を問い合わせる。
URI及びPreference値の問い合わせを受けると、サーバ101がメモリ403に格納されたNAPTRリソースレコードに従ってURI及びPreference値を返してくるので、端末B1は、このURI及びPreference値を受信する(ST1203)。上述の例の場合、サーバ101は、図11に示したNAPTRリソースレコードに従って、この文字列に対応する4つのURI及びPreference値を返してくる。具体的には、「81310000000@tokyo.sip.jp」及び「10」、「81310000001@tokyo.sip.jp」及び「20」、「81310000002@tokyo.sip.jp」及び「30」、並びに、「81310000003@tokyo.sip.jp」及び「40」を返してくる。
URI等を受信したならば、端末B1は、URIが複数存在するか判断する(ST1204)。受信したURIが複数存在しない場合には処理をST1205に移行し通常発呼処理を行う。一方、複数存在する場合には処理をST1206に移行しグループ発呼処理を行う。なお、実施の形態2における通常発呼処理については図8に示す説明と同様のため、その説明を省略する。また、実施の形態2におけるグループ発呼処理については後述する。
通常発呼処理又はグループ発呼処理を行った後、端末B1は、発呼結果の状態が「通話OK」であるか判断する(ST1207)。発呼結果の状態が「通話OK」の場合には通話処理に移行する一方(ST1208)、「通話OK」以外の場合には切断処理に移行する(ST1209)。通話処理においては、端末B1のオペレータと発呼先のオペレータとの通話が終わり次第、端末B1の発呼処理が終了する。切断処理においては、移行すると同時に端末B1の発呼処理が終了する。
ここで、実施の形態2におけるグループ発呼処理について図13を用いて説明する。図13は、実施の形態2におけるグループ発呼処理について説明するためのフロー図である。
グループ発呼処理に移行した場合、端末B1は、受信したPreference値の大小関係を判断する(ST1301)。そして、最小のPreference値についてのURIに対応するIPアドレスをサーバ101に問い合わせる(ST1302)。
端末B1からこのURIによりIPアドレスの問い合わせを受けると、サーバ101からIPアドレスが返されてくるので、端末B1は、これを受信する(ST1303)。IPアドレスを受信したならば、発呼結果の状態を初期化した後(ST1304)、受信したIPアドレスに対して発呼処理を行う(ST1305)。そして、当該宛先と接続できたかを判断し(ST1306)、接続できたならば、発呼結果の状態を「通話OK」に切り替えて(ST1307)、グループ発呼処理を終了する。
これに対して、接続できなかった場合には、端末B1は、対応するIPアドレスを問い合わせしていないURIが存在するか判断する(ST1308)。問い合わせしていないURIが存在するならば、端末B1は、処理をST1302に戻す。そして、対応するIPアドレスを問い合わせしていないURIのうち、最小のPreference値を有するものに対して、再びST1302〜ST1308の処理を行う。4つのURIを受信した場合には最高4回までST1302〜ST1308の処理が行われる。
ST1302〜ST1308の処理を繰り返すうちにIPアドレスを問い合わせしていないURIが存在しなくなったならば、端末B1は、発呼結果の状態を「通話NG」に切り替えて(ST1309)、グループ発呼処理を終了する。
このように実施の形態2に係るインターネット電話機によれば、サーバ101から複数のURIを受信した場合であってPreference値が差異を有する場合、いずれかのURIに対応する宛先と接続できない場合には他のURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
また、実施の形態2に係るインターネット電話機によれば、Preference値の大小関係に応じて発呼動作が行われる。これにより、Preference値に応じて発呼順序が決定されるので、発呼順序を指定することができる。特に、Preference値が小さいURIに対応する宛先から優先して発呼するので、発呼させたい順番に設定値を定めることで発呼順序を指定することができる。
なお、上述のように実施の形態2においては、NAPTRリソースレコードに記述されたPreference値をパラメータとして用いることで、複数存在する宛先に対して優先順位を付けて発呼する。しかし、Preference値をパラメータとして用いることで、複数存在する宛先に対して発呼する方法としては、常に優先順位を付けて発呼する場合に限られない。
例えば、Preference値を全て同一の値に設定しておき、そのURIに対応する全ての宛先に対して一斉に発呼することも可能である。図5(a)に示すNAPTRリソースレコードを実施の形態2に係るインターネット電話機に利用したとする。図5(a)に示すNAPTRリソースレコードのPreference値は全て「10」に設定されている。このため、図13に示すST1302においては全てのURIに対応するIPアドレスの問い合わせが行われ、ST1305においては全ての宛先端末(A1〜A4)に発呼されることとなる。
このように実施の形態2を応用したインターネット電話機によれば、Preference値が同一の場合には全てのURIに対応する宛先に一斉に発呼される。これにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。
なお、インターネット電話機においてPreference値を無視する指示を受けられるようにしておき、Preference値に差異を有する値を設定した場合において、Preference値を無視する指示を受け付けた場合にこの設定値を無視して全てのURIに対応する宛先に一斉に発呼することも可能である。この場合には、Preference値が差異を有する場合においても、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。
また、Preference値に同一の値を設定した組を複数用意しておき、その組単位で優先順位を付けて発呼することも可能である。図14は、かかる場合にサーバ101のメモリ403に記述されたNAPTRリソースレコードの一例を示す図である。同図においては、そのPreference値を除き、図11に示すNAPTRリソースレコードと同一であるため、その詳細な説明は省略する。図14に示すNAPTRリソースレコードにおいては、Preference値に同一の値を設定した組を有する点で図11に示すNAPTRリソースレコードと相違する。
図14においては、端末A1の電話番号(代表番号)「0310000000」から得られるドメイン名「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」に対応付けられた4つのURIのうち、「81310000000@tokyo.sip.jp」及び「81310000001@tokyo.sip.jp」を含むNAPTRレコードのPreference値に「10」が設定されている。また、「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」を含むNAPTRレコードのPreference値に「20」が設定されている。このため、図13に示す1回目のST1302において「81310000000@tokyo.sip.jp」及び「81310000001@tokyo.sip.jp」に対応するIPアドレスの問い合わせが行われると共に、1回目のST1305において端末A1及び端末A2に対して一斉に発呼される。そして、2回目のST1302において「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」に対応するIPアドレスの問い合わせが行われると共に、2回目のST1305において端末A3及び端末A4に対して一斉に発呼される。
このように実施の形態2を応用したインターネット電話機によれば、Preference値が同一の値を設定した組を複数用意しておき、その組単位で優先順位を付けて発呼するので、発呼させたい順番に設定値の組を定めることで段階的に発呼順序を指定することができる。
更に、ここまではPreference値に異なる値を設定して複数存在する宛先に対して優先順位を付けて発呼する場合、並びに、Preference値を全て同一の値に設定して複数存在する宛先に対して一斉に発呼する場合について個別に説明してきたが、これらを並存させる実施の形態も可能である。かかる実施の形態は、例えば、上記電話番号(0310000000〜0310000003)に新たに電話番号を追加することで実現することが可能である。ここでは、例えば、電話番号0310000004を追加し、この電話番号を一斉に発呼する際に用いる番号(以下、「一斉番号」という)に設定したものとする。
図15は、かかる場合にサーバ101のメモリ403に記述されたNAPTRリソースレコードの一例を示す図である。同図においては、最下段のNAPTRレコードが追加されている点を除き、図11に示すNAPTRリソースレコードと同一であるため、その詳細な説明は省略する。
図15においては、電話番号0310000004から得られるドメイン名「4.0.0.0.0.0.0.1.3.1.8.e164.arpa」に対して4つのURI「81310000000@tokyo.sip.jp」、「81310000001@tokyo.sip.jp」、「81310000002@tokyo.sip.jp」及び「81310000003@tokyo.sip.jp」が対応付けられている。これらのURIを含むNAPTRレコードのPreference値に全て同一の値である「10」が設定されている。このため、電話番号031000000を受け付けた場合には異なるPreference値に従って複数存在する宛先に対して優先順位を付けて発呼が行われる。また、一斉番号0310000004を受け付けた場合には同一であるPreference値に従って複数存在する宛先に対して一斉に発呼が行われる。
このように実施の形態2を応用したインターネット電話機によれば、サーバ101から複数のURIを受信した場合であってPreference値が差異を有する場合(上述の電話番号0310000000が入力された場合)、優先順位の高いURIに対応する宛先と接続できない場合には次に優先順位の高いURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
一方、Preference値が同一の場合(上述の一斉番号が入力された場合)には全てのURIに対応する宛先に一斉に発呼する。これにより、隣接する全ての電話機に一斉に発呼することができるので、緊急時等においてオペレータを選ばずに発呼するような場合の操作負担を軽減することができる。
(実施の形態3)
実施の形態2に係るインターネット電話機がNAPTRリソースレコードに記述されたPreference値に応じて複数存在する宛先に対して優先順位を付けて発呼する。その際に利用するサービスプロトコル(通信種別)としてsip(Session Initiation Protocol)に限定しているのに対し、実施の形態3に係るインターネット電話機は、sipのみならず他のサービスプロトコルを組み合わせて利用する点で相違する。
実施の形態3に係るインターネット電話機は、sipと組み合わせるサービスプロトコルとして、例えば、電子メールや電話によるFAXを利用する。以下の説明においては、特に電子メールや電話によるFAXを組み合わせた実施の形態について説明するが、これに限定されず、H.323、H.323による電話、インターネットFAX、既存電話及びWEBを利用するサービスプロトコルとして適用することができるのはいうまでもない。
図16は、実施の形態3に係るサーバ101のメモリ403に記述されたNAPTRリソースレコードの一例を示す図である。同図においては、最上段のNAPTRレコードが変更されている点を除き、図11に示すNAPTRリソースレコードと同一であるため、その詳細な説明は省略する。
図16においては、電話番号0310000000から得られるドメイン名「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」に対して6つのURIが対応付けられている。上段4つのURIを含むNAPTRレコードは図11と同一のため、その説明を省略する。下段2つのURIを含むNAPTRレコードのうち、上側のものはServiceフィールドに「E2U+message:mailto」と設定され、サービスプロトコル(通信種別)として電子メールを指定している。URIには電子メールの宛先である「info@panasonic.co.jp」が指定されている。一方、下側のものは「E2U+tel」と設定され、サービスプロトコル(通信種別)として電話でのFAXを指定している。URIにはFAXの宛先である「+81310000010;svc=fax」が指定されている。なお、下段2つのURIを含むNAPTRレコードのうち、上側のものはPreference値に「50」と設定され、下側のものは「60」と設定されている。
以下、上記構成を有するサーバ101に接続された本インターネット電話機間で発呼を行う場合の動作について図17を用いて説明する。ここでは、特に端末B1からグループ(A)に含まれる端末に発呼する場合の動作について説明する。なお、サーバ101のメモリ403には、図16及び図6に示す内容が登録されているものとする。
グループ(A)の端末に発呼する場合、端末B1は、端末A1〜A4のいずれかの電話番号の入力をオペレータから受け付ける(ST1701)。例えば、端末A1に対して発呼する場合には、「0310000000」あるいは「03」を省略した「10000000」をオペレータから受け付ける。
電話番号を受け付けると、端末B1は、この電話番号に対応するURI、Preference値及びServiceをサーバ101に対して問い合わせる(ST1702)。上述の例の場合、端末B1は、「0310000000(10000000)」から文字列「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」を得て、この文字列に対応するURI、Preference値及びServiceを問い合わせる。
URI、Preference値及びServiceの問い合わせを受けると、サーバ101がメモリ403に格納されたNAPTRリソースレコードに従ってURI、Preference値及びServiceを返してくるので、端末B1は、このURI、Preference値及びServiceを受信する(ST1703)。上述の例の場合、サーバ101は、図16に示したNAPTRリソースレコードに従って、この文字列に対応する6つのURI、Preference値及びServiceを返してくる。具体的には、「81310000000@tokyo.sip.jp」、「10」及び「E2U+sip」、「81310000001@tokyo.sip.jp」、「20」及び「E2U+sip」、「81310000002@tokyo.sip.jp」、「30」及び「E2U+sip」、並びに、「81310000003@tokyo.sip.jp」、「40」及び「E2U+sip」、「info@panasonic.co.jp」、「50」及び「E2U+message:mailto」、並びに、「+81310000010;svc=fax」、「60」及び「E2U+tel」を返してくる。
URI等を受信したならば、端末B1は、URIが複数存在するか判断する(ST1704)。受信したURIが複数存在しない場合には処理をST1705に移行し通常発呼処理を行う。一方、複数存在する場合には処理をST1706に移行しグループ発呼処理を行う。なお、実施の形態3における通常発呼処理については図8に示す説明と同様のため、その説明を省略する。また、実施の形態3におけるグループ発呼処理については後述する。
通常発呼処理又はグループ発呼処理を行った後、端末B1は、発呼結果の状態が「通話OK」であるか判断する(ST1707)。発呼結果の状態が「通話OK」の場合には通話処理に移行する一方(ST1708)、「通話OK」以外の場合には切断処理に移行する(ST1709)。通話処理においては、端末B1のオペレータと発呼先のオペレータとの通話が終わり次第、端末B1の発呼処理が終了する。切断処理においては、移行すると同時に端末B1の発呼処理が終了する。
ここで、実施の形態3におけるグループ発呼処理について図18を用いて説明する。図18は、実施の形態3におけるグループ発呼処理について説明するためのフロー図である。なお、図18において、図13と同一の処理については同一の符号を付し、その詳細な説明を省略する。
グループ発呼処理に移行した場合、端末B1は、受信したServiceの種別を判断する(ST1801)。そして、sip以外のServiceを含むかどうか判断する(ST1802)。sip以外のServiceを含まない場合には、図13に示すST1301〜ST1306及びST1308を行うと共に、後述するST1809及びST1815において発呼結果の状態を「通話OK」か「通話NG」に切り替えてグループ発呼処理を終了する。
これに対してsip以外のServiceを含む場合には、端末B1は、まず、ServiceがsipのNAPTRレコードのPreference値の大小関係を判断する(ST1803)。そして、最小のPreference値についてのURIに対応するIPアドレスをサーバ101に問い合わせる(ST1804)。
端末B1からこのURIによりIPアドレスの問い合わせを受けると、サーバ101からIPアドレスが返されてくるので、端末B1は、これを受信する(ST1805)。IPアドレスを受信したならば、発呼結果の状態を初期化した後(ST1806)、受信したIPアドレスに対して発呼処理を行う(ST1807)。そして、当該宛先と接続できたかを判断し(ST1808)、接続できたならば、発呼結果の状態を「通話OK」に切り替えて(ST1809)、グループ発呼処理を終了する。
これに対して、接続できなかった場合には、端末B1は、対応するIPアドレスを問い合わせしていないsip対応のURIが存在するか判断する(ST1810)。問い合わせしていないsip対応のURIが存在するならば、端末B1は、処理をST1804に戻す。そして、対応するIPアドレスを問い合わせしていないURIのうち、最小のPreference値を有するものに対して、再びST1804〜ST1810の処理を行う。4つのsip対応のURIを受信した場合には最高4回までST1804〜ST1810の処理が行われる。
ST1804〜ST1810の処理を繰り返すうちにIPアドレスを問い合わせしていないsip対応のURIが存在しなくなったならば、端末B1は、今度は、Serviceがsip以外のNAPTRレコードのPreference値の大小関係を判断する(ST1811)。そして、最小のPreference値を有するNAPTRレコードのURIで指定された宛先に予め用意しておいた定型文を送信する(ST1812)。
図16に示す例の場合には、電子メールアドレス「info@panasonic.co.jp」に対して定型文が電子メールで送信される。定型文としては、例えば、「○○様宛てに電話を差し上げましたが、不在のようでしたので、折り返しご連絡下さい。」等の文章が想定される。しかし、定型文の内容としてはこれに限定されず、いかなる内容を設定しておいてもよい。
そして、電子メールを送信できたかを判断し(ST1813)、送信できたならば、発呼結果の状態を「通話OK」に切り替えて(ST1809)、グループ発呼処理を終了する。これに対して、送信できなかった場合には、端末B1は、未処理のURIが存在するか判断する(ST1814)。未処理のURIが存在するならば、端末B1は、処理をST1812に戻す。そして、未処理のURIのうち、最小のPreference値を有するものに対して、再びST1812の処理を行う。図16に示す例の場合には、電話番号「+81310000010」に対して定型文がファクシミリ文書として送信される。定型文は、電子メールの場合と同様である。
ST1812〜ST1814の処理を繰り返すうちに未処理のURIが存在しなくなったならば、端末B1は、発呼結果の状態を「通話NG」に切り替えて(ST1815)、グループ発呼処理を終了する。
このように実施の形態3に係るインターネット電話機によれば、サーバ101から複数のURIを受信した場合であってServiceフィールドに設定されたプロトコル(通信種別)にsip及びsip以外のプロトコルが存在する場合、プロトコルにsipと設定されたURIに対応する宛先に発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
また、Serviceフィールドに設定されたプロトコルにsipと設定された全てのURIに対応する宛先と接続できなかった場合にはsip以外のプロトコルが設定されたURIに対して当該プロトコルに応じた処理を実行する。これにより、sipと設定された全てのURIに対応する宛先と接続できなかった場合においても、予めsip以外のプロトコルを用いた処理を登録しておくことで接続できなかった宛先に対して何らかの意図を伝達することができる。
特に、実施の形態3に係るインターネット電話機によれば、Serviceフィールドに設定されたプロトコルにsipと設定された全てのURIに対応する宛先と接続できなかった場合に電子メール又は電話でのFAXと設定されたURIが示す宛先に予め用意された定型文が送信される。これにより、例えば、定型文に折り返し電話が欲しい旨を通知する文章を設定しておくことで、接続できなかった宛先に対して折り返し電話が欲しい意図を伝達することができる。
(実施の形態4)
実施の形態2に係るインターネット電話機がNAPTRリソースレコードに記述されたPreference値に応じて複数存在する宛先に対して優先順位を付けて発呼するのに対し、実施の形態4に係るインターネット電話機は、オペレータの指示に応じて複数存在する宛先に対して優先順位を付けて発呼する点で相違する。
実施の形態4に係るインターネット電話機は、予めサーバ101のメモリ403に宛先端末のオペレータの識別情報を予め登録しておき、発呼元のインターネット電話機のURIの問い合わせに応じてURIと共に識別情報を返す。発呼元のインターネット電話機のオペレータは、その識別情報を確認した上で発呼する際の優先順位をダイアルキー等により指定する。インターネット電話機は、オペレータからの指定に応じて発呼処理を行うものである。
なお、実施の形態4に係るサーバ101のメモリ403において、宛先端末のオペレータの識別情報を登録する際の形式は、どのような形式で登録しておいてもよい。しかし、発呼元のインターネット電話機からのURIの問い合わせに応じて識別情報を返すことを考慮した場合、URIに対応させて登録しておくことが実施の形態として好ましい。
図19は、実施の形態4に係るサーバ101のメモリ403に登録された識別情報の一例を示す図である。図19(a)は、図1に示すグループ(A)に対応するURI及び識別情報を示し、図19(b)は、図1に示すグループ(B)に対応するURI及び識別情報を示している。
以下、上記構成を有するサーバ101に接続された本インターネット電話機間で発呼を行う場合の動作について図20を用いて説明する。ここでは、特に端末B1からグループ(A)に含まれる端末に発呼する場合の動作について説明する。なお、サーバ101のメモリ403には、図5、図6及び図19に示す内容が登録されているものとする。
グループ(A)の端末に発呼する場合、端末B1は、端末A1〜A4のいずれかの電話番号の入力をオペレータから受け付ける(ST2001)。例えば、端末A1に対して発呼する場合には、「0310000000」あるいは「03」を省略した「10000000」をオペレータから受け付ける。
電話番号を受け付けると、端末B1は、この電話番号に対応するURI及び識別情報をサーバ101に対して問い合わせる(ST2002)。上述の例の場合、端末B1は、「0310000000(10000000)」から文字列「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」を得て、この文字列に対応するURI及び識別情報を問い合わせる。
URI及び識別情報の問い合わせを受けると、サーバ101がメモリ403に格納されたNAPTRリソースレコードに従ってURIを返すと共に、当該URIに対応して登録された識別情報を返してくるので、端末B1は、このURI及び識別情報を受信する(ST2003)。上述の例の場合、サーバ101は、図5に示したNAPTRリソースレコードに従って、この文字列に対応する4つのURIと共に、図19に示した対応表に従ってURIに対応する識別情報を返してくる。具体的には、「81310000000@tokyo.sip.jp」及び「松下太郎」、「81310000001@tokyo.sip.jp」及び「松下二郎」、「81310000002@tokyo.sip.jp」及び「松下三郎」、並びに、「81310000003@tokyo.sip.jp」及び「松下花子」を返してくる。
URI等を受信したならば、端末B1は、URIが複数存在するか判断する(ST2004)。受信したURIが複数存在しない場合には処理をST2005に移行し通常発呼処理を行う。一方、複数存在する場合には処理をST2006に移行しグループ発呼処理を行う。なお、実施の形態4における通常発呼処理については図8に示す説明と同様のため、その説明を省略する。また、実施の形態4におけるグループ発呼処理については後述する。
通常発呼処理又はグループ発呼処理を行った後、端末B1は、発呼結果の状態が「通話OK」であるか判断する(ST2007)。発呼結果の状態が「通話OK」の場合には通話処理に移行する一方(ST2008)、「通話OK」以外の場合には切断処理に移行する(ST2009)。通話処理においては、端末B1のオペレータと発呼先のオペレータとの通話が終わり次第、端末B1の発呼処理が終了する。切断処理においては、移行すると同時に端末B1の発呼処理が終了する。
ここで、実施の形態4におけるグループ発呼処理について図21を用いて説明する。図21は、実施の形態4におけるグループ発呼処理について説明するためのフロー図である。
グループ発呼処理に移行した場合、端末B1は、オペレータから発呼する際の優先順位、すなわち、発呼順序を受け付ける(ST2101)。グループ発呼処理に移行すると、端末B1の表示部などに図20に示すST2003で受信した全ての識別情報が表示される。オペレータは、その識別情報において優先的に着信して欲しいオペレータの順序を指定してくるので、端末B1はこれを受け付ける。例えば、端末B1のオペレータにより図19(a)に示す識別情報の上段から下段に向かって発呼順序が指定される。
発呼順序を受け付けたならば、端末B1は、指定された発呼順序を判断する(ST2102)。これにより、端末B1が本グループ発呼処理で発呼すべき順序が認識される。上述の例の場合、1番目に「松下太郎」、2番目に「松下二郎」、3番目に「松下三郎」、最後に「松下花子」に対して発呼すべき旨が認識される。
次に、端末B1は、最初に発呼すべき識別情報に応じたURIに対応するIPアドレスをサーバ101に問い合わせる(ST2103)。上述の例の場合、まず、「松下太郎」に応じた「813100000000@tokyo.sip.jp」に対応するIPアドレスの問い合わせが行われる。
端末B1からこのURIによりIPアドレスの問い合わせを受けると、サーバ101からIPアドレスが返されてくるので、端末B1は、これを受信する(ST2104)。IPアドレスを受信したならば、発呼結果の状態を初期化した後(ST2105)、受信したIPアドレスに対して発呼処理を行う(ST2106)。そして、当該宛先と接続できたかを判断し(ST2107)、接続できたならば、発呼結果の状態を「通話OK」に切り替えて(ST2108)、グループ発呼処理を終了する。
これに対して、接続できなかった場合には、端末B1は、対応するIPアドレスを問い合わせしていないURIが存在するか判断する(ST2109)。問い合わせしていないURIが存在するならば、端末B1は、処理をST2103に戻す。そして、対応するIPアドレスを問い合わせしていないURIのうち、次の発呼順序のものに対して、再びST2103〜ST2109の処理を行う。4つのURIを受信した場合には最高4回までST2103〜ST2109の処理が行われる。
ST2103〜ST2109の処理を繰り返すうちにIPアドレスを問い合わせしていないURIが存在しなくなったならば、端末B1は、発呼結果の状態を「通話NG」に切り替えて(ST2110)、グループ発呼処理を終了する。
このように実施の形態4に係るインターネット電話機によれば、サーバ101から複数のURIを受信した場合であって識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼動作を行い、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼する。これにより、オペレータは単に電話番号を入力し発呼順序を指定するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
特に、実施の形態4に係るインターネット電話機においては、オペレータから指定された発呼順序に従って発呼動作が行われる。これにより、発呼元のオペレータにおいて要件を伝達したい発呼先のオペレータを指定することができる。この結果、要件に関連しないオペレータの作業等を阻害する事態を事前に回避することができる。
(実施の形態5)
上記実施の形態1〜4に係るインターネット電話機は、社内LANなどのネットワークに設置された場合であって外部のネットワークから直接アクセスできないような場合には適用が制限される場合がある。例えば、社内LAN上のインターネット電話機にプライベートIPアドレスを割り当て、外部ネットワークとの通信にはNAT(Network Address Translation)機能を有するルータ(以下、「NATルータ」という)を介して行うような場合には適用が制限される。実施の形態5に係るインターネット電話機は、外部のネットワークから直接アクセスできないような状況下においても同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができるようにするものである。
図22は、本発明の実施の形態5に係るインターネット電話機が適用されるネットワークの構成を示す図である。
同図において、インターネット電話機(端末)A1〜A4は、社内LAN上に設置され、端末B1は外部ネットワークに設置されている。端末A1〜A4には、図2(a)に示した例と同様に、電話番号として0310000000〜0310000003が同様に割り当てられる。しかし、図2(a)に示した例と異なり、IPアドレスとしてプラーベートIPアドレス(ローカルIPアドレス)である192.168.1.100〜192.168.1.103が割り当てられている。NATルータ2201にはグローバルIPアドレスである2.2.2.2が割り当てられている。端末A1〜A4から外部ネットワークの端末(例えば、端末B1)にアクセスする場合には、NATルータ2201においてプライベートIPアドレスからグローバルIPアドレスへの変換が行われ、モデム2202による通信制御の下、インターネット2203を介して通信が行われる。なお、図22においては、端末B1を外部ネットワークに設置されたインターネット電話機として説明しているが、これに限定されず、端末A1〜A4のような社内LANに接続された一台の端末であってもよい。
サーバ2204は、ネットワークI/F404がインターネットとの間で信号の制御を行う点を除き、図4における説明と同様の構成を有している。実施の形態5に係るサーバ2204のメモリ403は、端末A1〜A4に割り当てられた電話番号からURIへの変換を行うためのデータベース(NAPTRリソースレコード)を格納し、また、電話番号から変換されたURIと対応付けられるIPアドレスを登録している。しかし、実施の形態5においては、端末A1〜A4にプライベートIPアドレスが割り当てられているため、電話番号から変換されたURIには全てNATサーバ2201のグローバルIPアドレスが対応付けられている。
図23は、実施の形態5に係るサーバ2204のメモリ403に格納されたNAPTRリソースレコードの一例を示す図である。同図においては、端末A1〜A4に対応したNAPTRリソースレコードを示している。
図23に示すように、端末A1の電話番号(代表番号)「0310000000」から得られるドメイン名「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」に対して4つのURI「81310000000@tokyo.sip.jp:5060」、「81310000001@tokyo.sip.jp:60001」、「81310000002@tokyo.sip.jp:60002」及び「81310000003@tokyo.sip.jp:60003」が対応付けられている。同様に、端末A2、A3及びA4の電話番号「0310000001」、「0310000002」及び「0310000003」から得られるドメイン名「1.0.0.0.0.0.0.1.3.1.8.e164.arpa」、「2.0.0.0.0.0.0.1.3.1.8.e164.arpa」及び「3.0.0.0.0.0.0.1.3.1.8.e164.arpa」にそれぞれURI「81310000000@tokyo.sip.jp:60001」、「81310000000@tokyo.sip.jp:60002」及び「81310000000@tokyo.sip.jp:60003」が対応付けられている。
このように各URIにそれぞれ「5060」、「60001」、「60002」及び「60003」が追加されている。これらは、通信に用いられるポート番号を示している。追加されている「5060」はsipのデフォルトのポート番号であり、「60001」〜「60003」は未定義ポートから利用したポート番号の一例を示している。これらのポート番号は、NATルータ2201においてポートフォワーディングを行う際に用いられる。NATルータ2201にはポートフォワーディングを行うため、特定のポート番号と端末A1〜A4のIPアドレスとを対応付ける設定が予め行われている。
図24は、実施の形態5に係るNATルータ2201に設定された特定のポート番号とIPアドレスとの対応関係を示す図である。
同図に示すように、ポート番号「5060」に端末A1のプライベートIPアドレス「192.168.1.100」が設定され、ポート番号「60001」に端末A2のプライベートIPアドレス「192.168.1.101」が設定され、ポート番号「60002」に端末A3のプライベートIPアドレス「192.168.1.102」が設定され、ポート番号「60003」に端末A4のプライベートIPアドレス「192.168.1.103」が設定されている。予めこのように設定しておくことで、外部ネットワークの端末からNATルータ2201のIPアドレス(2.2.2.2)にポート番号を指定してアクセスされると、指定されたポート番号に対応するIPアドレスの端末と通信が可能となる。
以下、実施の形態5に係るインターネット電話機に対して外部ネットワークに設置されたインターネット電話機から発呼を行う場合の動作について図25を用いて説明する。ここでは、端末B1から端末A1〜A4のいずれかに発呼する場合の動作について説明する。なお、サーバ2204のメモリ403には図23に示すNAPTRリソースレコードが登録され、NATルータ2201には図24に示す設定が行われているものとする。
端末A1〜A4のいずれかに発呼する場合、端末B1は、端末A1〜A4のいずれかの電話番号の入力をオペレータから受け付ける(ST2501)。例えば、端末A1に対して発呼する場合には、「0310000000」あるいは「03」を省略した「10000000」の入力をオペレータから受け付ける。
電話番号を受け付けると、端末B1は、この電話番号に対応するURIをサーバ2204に対して問い合わせる(ST2502)。実施の形態5においてはURIにポート番号が含まれているため、結果としてポート番号も問い合わせたこととなる。上述の例の場合、端末B1は、「031000000(10000000)」から文字列「0.0.0.0.0.0.0.1.3.1.8.e164.arpa」を得て、この文字列に対応するURIを問い合わせる。
URIの問い合わせを受けると、サーバ2204がメモリ403に格納されたNAPTRリソースレコードに従ってURIを返してくるので、端末B1は、このURIを受信する(ST2503)。実施の形態5においてはURIにポート番号が含まれているため、結果としてポート番号も受信する。これにより、端末B1は、入力された電話番号に対応するURIとポート番号を把握する。上述の例の場合、サーバ101は、図23に示したNAPTRリソースレコードに従って、上記文字列に対応する4つのURI「81310000000@tokyo.sip.jp:5060」、「81310000001@tokyo.sip.jp:60001」、「81310000002@tokyo.sip.jp:60002」及び「81310000003@tokyo.sip.jp:60003」を返してくる。
URI等を受信したならば、端末B1は、URIが複数存在するか判断する(ST2504)。受信したURIが複数存在しない場合には処理をST2505に移行し通常発呼処理を行う。一方、複数存在する場合には処理をST2506に移行しグループ発呼処理を行う。なお、実施の形態5における通常発呼処理及びグループ発呼処理については後述する。
通常発呼処理又はグループ発呼処理を行った後、端末B1は、発呼結果の状態が「通話OK」であるか判断する(ST2507)。発呼結果の状態が「通話OK」の場合には通話処理に移行する一方(ST2508)、「通話OK」以外の場合には切断処理に移行する(ST2509)。通話処理においては、端末B1のオペレータと発呼先のオペレータとの通話が終わり次第、端末B1の発呼処理が終了する。切断処理においては、移行すると同時に端末B1の発呼処理が終了する。
ここで、実施の形態5における通常発呼処理について図26を用いて説明する。図26は、実施の形態5における通常発呼処理について説明するためのフロー図である。
通常発呼処理に移行した場合、端末B1は、受信したURIに対応するIPアドレスをサーバ2204に問い合わせる(ST2601)。例えば、「81310000000@tokyo.sip.jp:5060」をURIとして受信した場合には、このURIに対応するIPアドレスをサーバ101に問い合わせる。
IPアドレスの問い合わせを受けると、サーバ2204がメモリ403に登録された内容に従ってIPアドレスを返してくるので、端末B1は、このIPアドレスを受信する(ST2602)。上述のように、実施の形態5に係るサーバ2204は、NATルータ2201のIPアドレスしか登録していないため、このIPアドレス(2.2.2.2)を返してくる。IPアドレスを受信すると、端末B1は、図25に示す処理(ST2503)で得たポート番号と合わせることで、結果としてNATルータ2201のIPアドレスと宛先端末のポート番号を把握する。
IPアドレスを受信したならば、端末B1は、発呼結果の状態を初期化する(ST2603)。具体的には、発呼結果の状態を「待機中」に設定することにより発呼結果の状態を初期化する。
次に、端末B1は、受信したIPアドレスに対して発呼処理を行う(ST2604)。実施の形態5においては、NATルータ2201に対して把握した宛先のポート番号に向けた発呼処理が行われる。具体的には、SIPのINVITEメッセージ中に「sip:2.2.2.2:5060」を記述することでNATルータのIPアドレスと宛先端末のポート番号を指定する。
発呼処理を行った後、端末B1は、当該宛先と接続できたかを判断する(ST2605)。ここで、接続できたならば、端末B1は、発呼結果の状態を「通話OK」に切り替えて(ST2606)、通常発呼処理を終了する。一方、接続できなかったならば、端末B1は、発呼結果の状態を「通話NG」に切り替えて(ST2607)、通常発呼処理を終了する。このように通常発呼処理においては単一の宛先に対して発呼処理を行い、その宛先に対する接続の可否に応じて発呼結果の状態が切り替えられる。
次に、実施の形態5におけるグループ発呼処理について図27を用いて説明する。図27は、実施の形態5におけるグループ発呼処理について説明するためのフロー図である。
グループ発呼処理に移行した場合、端末B1は、受信したURIに対応するIPアドレスをサーバ2204に問い合わせる(ST2701)。グループ発呼処理に移行した場合には複数のURIが受信されているため、端末B1は、いずれかのURIに対応するIPアドレスをサーバ2204に問い合わせる。例えば、「81310000000@tokyo.sip.jp:5060」、「81310000001@tokyo.sip.jp:60001」、「81310000002@tokyo.sip.jp:60002」及び「81310000003@tokyo.sip.jp:60003」をURIとして受信した場合には、いずれかのURIに対応するIPアドレスをサーバ2204に問い合わせる。
IPアドレスの問い合わせを受けると、通常発呼処理における説明と同様に、サーバ2204からNATルータ2201のIPアドレスが返されてくるので、端末B1は、これを受信する(ST2702)。IPアドレスを受信すると、通常発呼処理における説明と同様に、端末B1は、図25に示す処理(ST2503)で得たポート番号と合わせることで、結果としてNATルータのIPアドレスと宛先端末のポート番号を把握する。
IPアドレスを受信したならば、発呼結果の状態を初期化した後(ST2703)、受信したIPアドレスに対して発呼処理を行う(ST2704)。そして、当該宛先と接続できたかを判断し(ST2705)、接続できたならば、発呼結果の状態を「通話OK」に切り替えて(ST2706)、グループ発呼処理を終了する。
これに対して、接続できなかった場合には、端末B1は、対応するIPアドレスを問い合わせしていないURIが存在するか判断する(ST2707)。問い合わせしていないURIが存在するならば、端末B1は、処理をST2701に戻し、問い合わせしていないURIが存在しなくなるまでST2701〜ST2707の処理を繰り返す。4つのURIを受信した場合には最高4回までST2701〜ST2707の処理が行われる。
ST2701〜ST2707の処理を繰り返すうちにIPアドレスを問い合わせしていないURIが存在しなくなったならば、端末B1は、発呼結果の状態を「通話NG」に切り替えて(ST2708)、グループ発呼処理を終了する。このようにグループ発呼処理においては複数の宛先に対して発呼処理を行い、全ての宛先に対して接続ができなかった場合に発呼結果の状態が「通話NG」に設定される。
このように実施の形態5に係るインターネット電話機によれば、サーバ2204から複数のURIを受信した場合であって当該URIにポート番号が含まれる場合、いずれかのURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先に再発呼する。これにより、オペレータは単に電話番号を入力するだけである宛先と接続できない場合は別の宛先に順次自動的にかけ直してくれるので、同一グループ内のある電話機に接続できない場合に一旦電話を切り、オペレータが隣接する別の電話機の電話番号を別途入力し直すという手間を省くことができ、電話をする際の操作負担を著しく軽減することができる。
特に、実施の形態5に係るインターネット電話機によれば、URIに含まれるポート番号とURIに応じたIPアドレスとで特定される宛先に対して発呼するので、例えば、インターネット電話機にプライベートIPアドレスが割り当てられている場合等、外部のネットワークから直接アクセスできないような状況下においても同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができる。
なお、上記説明におけるインターネット電話は、総務省が定義し通信事業者が運用するIP電話や、ローカルなネットワーク又は自営網でのTCP/IP等のコンピュータ通信プロトコルによるネットワークで実現されるものも含むものとする。
本発明に係るインターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システムによれば、通話したい宛先の電話機が話中の場合であっても、同一のネットワークのグループに属する電話機にオペレータの操作を介在させずに自動的にかけ直すことができ、オペレータの利便性に優れたインターネット電話機等を提供できる点で有用である。
本発明の実施の形態1に係るインターネット電話機が適用されるネットワークの構成を示す図 図1に示すネットワークに接続されたインターネット電話機に割り当てられた電話番号及びIPアドレスを示す図 実施の形態1に係るインターネット電話機の構成を示すブロック図 実施の形態1に係るサーバの概略構成を示すブロック図 実施の形態1に係るサーバのメモリに記述されたNAPTRリソースレコードの一例を示す図 実施の形態1に係るサーバのメモリに記憶されたURI及びIPアドレスの対応関係の一例を示す図 実施の形態1に係るサーバに接続された本インターネット電話機間で発呼を行う場合の動作についてについて説明するためのフロー図 実施の形態1における通常発呼処理について説明するためのフロー図 実施の形態1におけるグループ発呼処理について説明するためのフロー図 実施の形態1におけるグループ発呼処理を実行することで、端末B1とグループ(A)に含まれる端末との間で行われるシーケンスを説明するための図 本発明の実施の形態2に係るサーバのメモリに記述されたNAPTRリソースレコードの一例を示す図 実施の形態2に係るサーバに接続された本インターネット電話機間で発呼を行う場合の動作について説明するためのフロー図 実施の形態2におけるグループ発呼処理について説明するためのフロー図 実施の形態2に係るサーバのメモリに記述されたNAPTRリソースレコードの変形例を示す図 実施の形態2に係るサーバのメモリに記述されたNAPTRリソースレコードの変形例を示す図 本発明の実施の形態3に係るサーバのメモリに記述されたNAPTRリソースレコードの一例を示す図 実施の形態3に係るサーバに接続された本インターネット電話機間で発呼を行う場合の動作を説明するためのフロー図 実施の形態3におけるグループ発呼処理について説明するためのフロー図 本発明の実施の形態4に係るサーバのメモリに登録された識別情報の一例を示す図 実施の形態4に係るサーバに接続された本インターネット電話機間で発呼を行う場合の動作を説明するためのフロー図 実施の形態4におけるグループ発呼処理について説明するためのフロー図 本発明の実施の形態5に係るインターネット電話機が適用されるネットワークの構成を示す図 実施の形態5に係るサーバのメモリに格納されたNAPTRリソースレコードの一例を示す図 実施の形態5に係るNATルータに設定された特定のポート番号とIPアドレスとの対応関係を示す図 実施の形態5に係るインターネット電話機に対して外部ネットワークに設置されたインターネット電話機から発呼を行う場合の動作を説明するためのフロー図 実施の形態5における通常発呼処理について説明するためのフロー図 実施の形態5におけるグループ発呼処理について説明するためのフロー図 (a)従来の一般的なインターネット電話システムのネットワークの構成を示す図 (b)、(c)従来のインターネット電話システムのサーバにおいて管理される、各インターネット電話機に割り当てられた電話番号とその電話番号に対応するIPアドレスとが登録された管理表を示す図 従来のインターネット電話システムにおける動作を示すシーケンス図
符号の説明
A1〜A4、B1〜B4 インターネット電話機(端末)
101 サーバ
102、103 ルータ
301 制御アダプタ
302 通常の電話機
303 CPU
305 ROM
306 RAM
401 CPU
403 メモリ
2201 NATルータ
2202 モデム
2204 サーバ

Claims (29)

  1. 入力された電話番号に対応するNAPTRリソースレコード上のURIを受信すると共に前記URIに応じたIPアドレスを受信する受信手段と、前記IPアドレスが割り当てられた宛先に発呼する発呼手段と、前記URIを複数受信した場合であっていずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させる制御手段と、を具備することを特徴とするインターネット電話機。
  2. 入力された電話番号に対応するNAPTRリソースレコード上のURI及びPreferenceフィールドの設定値を受信すると共に前記URIに応じたIPアドレスを受信する受信手段と、前記IPアドレスが割り当てられた宛先に発呼する発呼手段と、前記URIを複数受信した場合であって前記設定値が差異を有する場合には当該設定値の大小関係に応じて発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させる制御手段と、を具備することを特徴とするインターネット電話機。
  3. 前記制御手段は、前記設定値が小さいURIに対応する宛先から優先して発呼させることを特徴とする請求項2記載のインターネット電話機。
  4. 前記制御手段は、前記URIを複数受信した場合であって前記設定値が同一の場合には全てのURIに対応する宛先に一斉に発呼させることを特徴とする請求項2記載のインターネット電話機。
  5. 前記制御手段は、前記設定値を無視する指示を受け付けると前記設定値を無視して全てのURIに対応する宛先に一斉に発呼させることを特徴とする請求項2記載のインターネット電話機。
  6. 入力された電話番号に対応するNAPTRリソースレコード上のURI及びServiceフィールドに設定された通信種別を受信すると共に前記URIに応じたIPアドレスを受信する受信手段と、前記IPアドレスが割り当てられた宛先に発呼する発呼手段と、前記URIを複数受信した場合であって前記通信種別にsip及びsip以外の通信種別が存在する場合には前記通信種別にsipと設定されたURIに対応する宛先に発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させ、前記通信種別にsipと設定された全てのURIに対応する宛先と接続できなかった場合にはsip以外の通信種別が設定されたURIに対して当該通信種別に応じた処理を実行させる制御手段と、を具備することを特徴とするインターネット電話機。
  7. 前記受信手段は、前記sip以外の通信種別として電子メール又は電話でのFAXを受信し、前記制御手段は、前記電子メール又は電話でのFAXと設定されたURIが示す宛先に予め用意された定型文を送信することを特徴とする請求項6記載のインターネット電話機。
  8. 入力された電話番号に対応するNAPTRリソースレコード上のURIを受信すると共に前記URIに応じた識別情報及びIPアドレスを受信する受信手段と、前記IPアドレスが割り当てられた宛先に発呼する発呼手段と、前記URIを複数受信した場合であって前記識別情報に応じて発呼順序の指定を受けた場合には当該発呼順序に従って発呼動作を行わせ、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させる制御手段と、を具備することを特徴とするインターネット電話機。
  9. 入力された電話番号に対応するNAPTRリソースレコード上のポート番号を含むURIを受信すると共に前記URIに応じたIPアドレスを受信する受信手段と、前記IPアドレス及びポート番号で特定される宛先に発呼する発呼手段と、前記URIを複数受信した場合であっていずれかのURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスと当該URIに含まれるポート番号で特定される宛先に再発呼させる制御手段と、を具備することを特徴とするインターネット電話機。
  10. 前記制御手段は、発呼した宛先が話中の場合又は所定時間継続して応答しない場合に発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼させることを特徴とする請求項1から請求項9のいずれかに記載のインターネット電話機。
  11. ネットワークを介して接続するインターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶する記憶手段と、前記電話番号に対応するURI並びに当該URIに応じたIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録することを特徴とするネットワークサーバ。
  12. ネットワークを介して接続するインターネット電話機の電話番号に対応するURI及びPreferenceフィールドの設定値を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶する記憶手段と、前記電話番号に対応するURI及び設定値並びに当該URIに応じたIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記設定値に差異を有する値を登録することを特徴とするネットワークサーバ。
  13. 前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記設定値に同一の値を登録することを特徴とする請求項12記載のネットワークサーバ。
  14. ネットワークを介して接続するインターネット電話機の電話番号に対応するURI及びServiceフィールドの通信種別を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶する記憶手段と、前記電話番号に対応するURI及び通信種別並びに当該URIに応じたIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記通信種別にsip及びsip以外の通信種別を登録することを特徴とするネットワークサーバ。
  15. 前記記憶手段は、前記sip以外の通信種別として電子メール又は電話でのFAXを登録することを特徴とする請求項14記載のネットワークサーバ。
  16. ネットワークを介して接続するインターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及び前記URIに応じた識別情報及びIPアドレスを記憶する記憶手段と、前記電話番号に対応するURI並びに当該URIに応じた識別情報及びIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び当該複数のURIに応じた前記識別情報を登録することを特徴とするネットワークサーバ。
  17. ネットワークを介して接続するインターネット電話機の電話番号に対応しポート番号を有するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶する記憶手段と、前記電話番号に対応しポート番号を有するURI並びに当該URIに応じたIPアドレスを返送する制御手段と、を具備し、前記記憶手段は、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録することを特徴とするネットワークサーバ。
  18. ネットワークを介して接続する各インターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼することを特徴とする通話方法。
  19. ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI及びPreferenceフィールドの設定値を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び前記設定値に差異を有する値が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに応じた前記設定値を返送し、インターネット電話機から前記設定値の大小関係に応じていずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼することを特徴とする通話方法。
  20. 前記サーバは、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記設定値に同一の値を登録し、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに応じた前記設定値を返送し、インターネット電話機で前記設定値が差異を有する場合には当該設定値の大小関係に応じて発呼動作を行い、いずれかのURIに応じたIPアドレスの宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼する一方、前記設定値が同一の場合には全てのURIに応じたIPアドレスの宛先に一斉に発呼することを特徴とする請求項19記載の通話方法。
  21. ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI及びServiceフィールドに設定された通信種別を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び前記通信種別にsip及びsip以外の通信種別が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに対応する通信種別を返送し、インターネット電話機で前記通信種別にsip及びsip以外の通信種別が存在する場合には前記通信種別にsipと設定されたURIに応じたIPアドレスの宛先に発呼動作を行わせ、いずれかのURIに応じたIPアドレスの宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼し、前記通信種別にsipと設定された全てのURIに応じたIPアドレスの宛先と接続できなかった場合にはsip以外の通信種別が設定されたURIに対して当該通信種別に応じた処理を実行することを特徴とする通話方法。
  22. ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI並びに前記URIに応じた識別情報及びIPアドレスを記憶し、特定の電話番号に応じて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び識別情報が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに対応する識別情報を返送し、前記識別情報に応じて発呼順序の指定を受けるとインターネット電話機から当該発呼順序に従って発呼動作を行い、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼することを特徴とする通話方法。
  23. ネットワークを介して接続する各インターネット電話機の電話番号に対応しポート番号を有するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いた通話方法であって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレス及び当該URIが有するポート番号で特定される宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレス及び当該URIが有するポート番号で特定される宛先に再発呼することを特徴とする通話方法。
  24. ネットワークを介して接続する各インターネット電話機の電話番号に対応するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼することを特徴とするインターネット電話システム。
  25. ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI及びPreferenceフィールドの設定値を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び前記設定値に差異を有する値が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに応じた前記設定値を返送し、インターネット電話機から前記設定値の大小関係に応じていずれかのURIに応じたIPアドレスの宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼することを特徴とするインターネット電話システム。
  26. 前記サーバは、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIを登録し且つ前記設定値に同一の値を登録し、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに応じた前記設定値を返送し、インターネット電話機で前記設定値が差異を有する場合には当該設定値の大小関係に応じて発呼動作を行い、いずれかのURIに応じたIPアドレスの宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼する一方、前記設定値が同一の場合には全てのURIに応じたIPアドレスの宛先に一斉に発呼することを特徴とする請求項25記載のインターネット電話システム。
  27. ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI及びServiceフィールドに設定された通信種別を含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び前記通信種別にsip及びsip以外の通信種別が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに対応する通信種別を返送し、インターネット電話機で前記通信種別にsip及びsip以外の通信種別が存在する場合には前記通信種別にsipと設定されたURIに応じたIPアドレスの宛先に発呼動作を行わせ、いずれかのURIに応じたIPアドレスの宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレスの宛先に再発呼し、前記通信種別にsipと設定された全てのURIに応じたIPアドレスの宛先と接続できなかった場合にはsip以外の通信種別が設定されたURIに対して当該通信種別に応じた処理を実行することを特徴とするインターネット電話システム。
  28. ネットワークを介して接続する各インターネット電話機の電話番号に対応するURI並びに前記URIに応じた識別情報及びIPアドレスを記憶し、特定の電話番号に応じて隣接して設置されたインターネット電話機の電話番号に対応する複数のURI及び識別情報が登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURI及び当該複数のURIに対応する識別情報を返送し、前記識別情報に応じて発呼順序の指定を受けるとインターネット電話機から当該発呼順序に従って発呼動作を行い、いずれかのURIに対応する宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに対応する宛先に再発呼することを特徴とするインターネット電話システム。
  29. ネットワークを介して接続する各インターネット電話機の電話番号に対応しポート番号を有するURIを含むNAPTRリソースレコード及び前記URIに応じたIPアドレスを記憶し、特定の電話番号に対応させて隣接して設置されたインターネット電話機の電話番号に対応する複数のURIが登録されたサーバと、入力された電話番号に応じてサーバから前記URI及びIPアドレスを得て宛先に発呼するインターネット電話機とを用いたインターネット電話システムであって、前記インターネット電話機から特定の電話番号に対応するURIの問い合わせを受けるとサーバから当該特定の電話番号に対応する複数のURIを返送し、インターネット電話機からいずれかのURIに応じたIPアドレス及び当該URIが有するポート番号で特定される宛先に発呼し、当該宛先と接続できない場合には発呼対象となるURIを変更して異なるURIに応じたIPアドレス及び当該URIが有するポート番号で特定される宛先に再発呼することを特徴とするインターネット電話システム。
JP2004083209A 2004-03-22 2004-03-22 インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム Expired - Fee Related JP4384529B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2004083209A JP4384529B2 (ja) 2004-03-22 2004-03-22 インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム
US11/082,710 US7508819B2 (en) 2004-03-22 2005-03-18 Internet telephone, server apparatus, calling method, and internet telephone system
EP05006165A EP1580974B1 (en) 2004-03-22 2005-03-21 Internet telephone calling system and corresponding method
DE602005025052T DE602005025052D1 (de) 2004-03-22 2005-03-21 Internet-Fernsprechanrufsystem und entsprechendes Verfahren

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004083209A JP4384529B2 (ja) 2004-03-22 2004-03-22 インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム

Publications (2)

Publication Number Publication Date
JP2005269574A true JP2005269574A (ja) 2005-09-29
JP4384529B2 JP4384529B2 (ja) 2009-12-16

Family

ID=34858379

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004083209A Expired - Fee Related JP4384529B2 (ja) 2004-03-22 2004-03-22 インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム

Country Status (4)

Country Link
US (1) US7508819B2 (ja)
EP (1) EP1580974B1 (ja)
JP (1) JP4384529B2 (ja)
DE (1) DE602005025052D1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007251289A (ja) * 2006-03-13 2007-09-27 Ricoh Co Ltd 画像通信装置
JP2008035250A (ja) * 2006-07-28 2008-02-14 Fujitsu Ltd 情報提供サービス制御システム
JP2008160693A (ja) * 2006-12-26 2008-07-10 Nec Infrontia Corp 通信システム
JP2009193538A (ja) * 2008-02-18 2009-08-27 Seiko Epson Corp コンテンツ伝送システム及び印刷装置特定方法
JP2012060653A (ja) * 2011-10-24 2012-03-22 Nec Infrontia Corp 通信システム及び通信システムにおける通信方法
JP2012209711A (ja) * 2011-03-29 2012-10-25 Oki Networks Co Ltd 連携システム、サーバ、ユーザ端末、対応サービス管理プログラム及び対応サービス取得プログラム

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7020707B2 (en) * 2001-05-30 2006-03-28 Tekelec Scalable, reliable session initiation protocol (SIP) signaling routing node
JP4377741B2 (ja) * 2004-04-30 2009-12-02 パナソニック株式会社 Ip電話システム、ip電話装置及び通話方法
JP4328266B2 (ja) * 2004-06-28 2009-09-09 パナソニック株式会社 Enumサーバ、ip電話装置及びip電話システム
ATE515870T1 (de) * 2004-09-08 2011-07-15 Koninkl Kpn Nv Verfahren zur adressierung eines kommunikationsgeräts zur herstellung eines übertragungsweges zwischen einem datennetzwerk und einem fernsprechnetzwerk
JP4516398B2 (ja) * 2004-10-05 2010-08-04 パナソニック株式会社 Ip通信装置および通信サービス選択方法
JP4995416B2 (ja) * 2004-10-05 2012-08-08 パナソニック株式会社 Ip通信装置およびip通信方法
US7924820B2 (en) * 2005-12-07 2011-04-12 Marron Interconnect Llc Method and system for facilitating communications
KR100714114B1 (ko) * 2005-12-09 2007-05-02 한국전자통신연구원 Uri를 획득하기 위한 클라이언트, 기록매체 및 그 방법
US20070183400A1 (en) * 2006-02-07 2007-08-09 Bennett James D Telephone supporting bridging between a packet switched network and the public switched telephone network
US7889718B2 (en) * 2006-05-10 2011-02-15 Microsoft Corporation Determining physical location of network devices
JP4779844B2 (ja) 2006-07-13 2011-09-28 富士通株式会社 通信システム及び加入者端末
US8077701B2 (en) * 2006-07-20 2011-12-13 At&T Intellectual Property I, Lp Systems, methods, and apparatus to prioritize communications in IP multimedia subsystem networks
US7929419B2 (en) * 2006-08-04 2011-04-19 Tekelec Methods, systems, and computer program products for inhibiting message traffic to an unavailable terminating SIP server
US7836150B2 (en) * 2006-12-30 2010-11-16 Arcsoft (Shanghai) Technology Company, Ltd Point-to-point communication using UPnP protocol
JP2008259053A (ja) * 2007-04-06 2008-10-23 Matsushita Electric Ind Co Ltd 構内交換機、電話機、及びこれらを備えた電話システム
US20080320116A1 (en) * 2007-06-21 2008-12-25 Christopher Briggs Identification of endpoint devices operably coupled to a network through a network address translation router
US7742421B2 (en) * 2007-07-31 2010-06-22 Tekelec Systems, methods, and computer program products for distributing application or higher layer communications network signaling entity operational status information among session initiation protocol (SIP) entities
US8139563B2 (en) * 2007-10-03 2012-03-20 At&T Knowledge Ventures, L.P. System for alternate communications in an internet protocol multimedia subsystem network
US8027445B2 (en) * 2007-11-07 2011-09-27 At&T Intellectual Property I, L.P. Method and system to provision emergency contact services in a communication network
US8411665B2 (en) * 2007-12-11 2013-04-02 At&T Intellectual Property I, L.P. System and method of routing voice communications via peering networks
US8165116B2 (en) * 2007-12-12 2012-04-24 At&T Intellectual Property I, L.P. Method and system to provide contact services in a communication network
US7957373B2 (en) * 2007-12-12 2011-06-07 At&T Intellectual Property I, L.P. Method and system to provide contact services in a communication network
US9397862B2 (en) 2008-12-12 2016-07-19 At&T Intellectual Property I, L.P. Method and apparatus for completing a circuit switched service call in an internet protocol network
JP5171676B2 (ja) * 2009-02-05 2013-03-27 キヤノン株式会社 送信装置、その制御方法およびプログラム
WO2011100587A2 (en) * 2010-02-12 2011-08-18 Tekelec Methods, systems, and computer readable media for inter-diameter-message processor routing
US9071512B2 (en) 2010-08-06 2015-06-30 Tekelec, Inc. Methods, systems, and computer readable media for distributing diameter network management information
US8842810B2 (en) * 2012-05-25 2014-09-23 Tim Lieu Emergency communications management
US10778527B2 (en) 2018-10-31 2020-09-15 Oracle International Corporation Methods, systems, and computer readable media for providing a service proxy function in a telecommunications network core using a service-based architecture
US11012931B2 (en) 2019-05-24 2021-05-18 Oracle International Corporation Methods, systems, and computer readable media for enhanced signaling gateway (SGW) status detection and selection for emergency calls
US11018971B2 (en) 2019-10-14 2021-05-25 Oracle International Corporation Methods, systems, and computer readable media for distributing network function (NF) topology information among proxy nodes and for using the NF topology information for inter-proxy node message routing
US11528334B2 (en) 2020-07-31 2022-12-13 Oracle International Corporation Methods, systems, and computer readable media for preferred network function (NF) location routing using service communications proxy (SCP)
US11570262B2 (en) 2020-10-28 2023-01-31 Oracle International Corporation Methods, systems, and computer readable media for rank processing for network function selection

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0967764A3 (en) 1998-06-25 2002-05-15 Siemens Information and Communication Networks, Inc. Improved apparatus and methods to realize H.323 proxy services
DE59913224D1 (de) * 1998-12-21 2006-05-11 Siemens Ag Verfahren zum Realisieren einer Sammelanschlussfunktion in einem Kommunikationsnetz nach ITU-T H.323
JP2001320485A (ja) 2000-05-08 2001-11-16 Nec Corp インターネット電話への話中転送方式
JP2002101198A (ja) 2000-09-26 2002-04-05 Matsushita Electric Ind Co Ltd インターネット電話システム
US7027582B2 (en) * 2001-07-06 2006-04-11 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for resolving an entity identifier into an internet address using a domain name system (DNS) server and an entity identifier portability database
FR2841072A1 (fr) * 2002-06-14 2003-12-19 France Telecom Systeme de consultation et/ou mise a jour de serveurs dns et/ou d'annuaires ldap
US7320026B2 (en) * 2002-06-27 2008-01-15 At&T Bls Intellectual Property, Inc. Intersystem messaging using ENUM standard
US7161933B2 (en) * 2002-09-24 2007-01-09 Intel Corporation Optimistic caching for address translations
US7564836B2 (en) * 2003-03-27 2009-07-21 Panasonic Corporation Internet telephone apparatus, adapter and server for internet telephone communication, internet telephone system, and control method

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007251289A (ja) * 2006-03-13 2007-09-27 Ricoh Co Ltd 画像通信装置
JP2008035250A (ja) * 2006-07-28 2008-02-14 Fujitsu Ltd 情報提供サービス制御システム
JP2008160693A (ja) * 2006-12-26 2008-07-10 Nec Infrontia Corp 通信システム
US9042529B2 (en) 2006-12-26 2015-05-26 Nec Platforms, Ltd. Communication system
US9143607B2 (en) 2006-12-26 2015-09-22 Nec Platforms, Ltd. Communication system
JP2009193538A (ja) * 2008-02-18 2009-08-27 Seiko Epson Corp コンテンツ伝送システム及び印刷装置特定方法
JP2012209711A (ja) * 2011-03-29 2012-10-25 Oki Networks Co Ltd 連携システム、サーバ、ユーザ端末、対応サービス管理プログラム及び対応サービス取得プログラム
JP2012060653A (ja) * 2011-10-24 2012-03-22 Nec Infrontia Corp 通信システム及び通信システムにおける通信方法

Also Published As

Publication number Publication date
EP1580974B1 (en) 2010-12-01
DE602005025052D1 (de) 2011-01-13
EP1580974A1 (en) 2005-09-28
US20050207402A1 (en) 2005-09-22
JP4384529B2 (ja) 2009-12-16
US7508819B2 (en) 2009-03-24

Similar Documents

Publication Publication Date Title
JP4384529B2 (ja) インターネット電話機、ネットワークサーバ、通話方法及びインターネット電話システム
JP4336263B2 (ja) Ip電話システム、ip電話装置及び通話方法
JP4469209B2 (ja) Ip電話システム、ip電話装置及び通話方法
JP4426921B2 (ja) Ip電話システム、ip電話装置及び宛先ユーザ識別方法
JP4426920B2 (ja) Ip電話システム、ip電話装置及び宛先ユーザ識別方法
JP4283740B2 (ja) Ip電話システム、ip電話装置及び通話方法
KR100671532B1 (ko) Ip 전화 시스템, ip 전화 장치 및 착신 유저 식별 방법
US7564836B2 (en) Internet telephone apparatus, adapter and server for internet telephone communication, internet telephone system, and control method
US7778238B2 (en) IP telephone apparatus
JP4426922B2 (ja) Ip電話システム、ip電話装置及び伝言メッセージ録音方法
JP2006050432A (ja) 呼接続制御装置、ip電話装置及びip電話システム
JP4377741B2 (ja) Ip電話システム、ip電話装置及び通話方法
JP2006041915A (ja) 情報通信装置およびその制御方法
JP4369776B2 (ja) インターネット電話機、インターネット電話に用いる制御装置及びネットワークサーバ、並びにインターネット電話システム及びインターネット電話による通話方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070319

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090316

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090331

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090422

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090901

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090925

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121002

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131002

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees