JP2005159582A - Ｉｐ網を用いたｉｐ電話と一般電話（ｉｓｄｎ含む）間のサービス方法及びこのための認証メッセージフォーマット - Google Patents

Abstract

【課題】 ＩＰ網を用いたＩＰ電話と一般電話（ISDN含む）との呼接続を可能にするサービス方法及びこのための認証メッセージフォーマットを提供する。
【解決手段】 IP電話と一般電話とが一般電話（ISDN含む）網でゲートウェイを介して呼接続できるように、IP電話番号を付与・管理するメインサーバ２００は、加入者か否かを通話開始時毎に認証メッセージフォーマットで認証する認証サーバ２１０を含み、IP電話番号加入者が呼要請するために一般電話（ISDN含む）番号を押すと、ゲートウェイ２８では認証サーバからIP電話番号加入者がIP電話サービスを受けられるか認証を受ける段階と、認証されると、IP電話番号加入者が一般電話（ISDN含む）番号を呼び出すとき、ゲートウェイ２８では呼出者がIP電話番号加入者であるか否かをゲートキーパーから確認する段階と、IP電話番号の確認後、通常の呼接続過程を経て一般電話（ISDN含む）と通話する呼接続段階とを順次行う。
【選択図】 図６

Description

本発明は、ＩＰ網を用いたIP電話と一般電話（ISDN含む）との通話ができるように、IP電話番号事業者のメインサーバで呼出者の呼出時に認証を行い、認証を受けた状態で一般電話（ISDN含む）との呼接続を可能にするサービス方法及びこのための認証メッセージフォーマットに関する。

一般に、有線網を介して電話を行う段階から、無線網を介して無線電話を行う段階に発展したが、最近は有無線共用に電話を行うことが可能な段階に至った。インターネットが主流を成している現在には、インターネット端末機同士の通話ができるように環境が発展している。

図１は一般的な電話有線網Ａとインターネット有線網Ｂとの関係を示す構成図である。 図１に示すように、一般電話（ISDN含む）有線網Ａは、回線網(Public Switched Circuit Network(ＰＳＴＮ))１を介して回線を提供する交換局１１に加入した加入者が使用する一般電話（ISDN含む）１２を含む構成をもつ。
インターネット有線網Ｂは、インターネットサービスプロバイダー(ＩＳＰ)１２から提供されたルーター２２を介して専用線でインターネットサービスプロバイダー２１に接続するコンピュータ２３と、他のインターネットサービスプロバイダー２１−１とのインターネット通信を行うようにインターネット網を成すパケット網３０と、前記インターネットサービスプロバイダー２１、２１−１からのパケット網を回線網方式に変換して回線網１に接続させるゲートウェイ４０とを含んでなる。

これらは交換局１１を介して一般電話（ISDN含む）１２加入者同士の通話を行い、またインターネットサービスプロバイダー２１に加入した加入者は、互いにインターネットサービスプロバイダー２１を経由して加入者番号を要請して接続する。そして、一般電話（ISDN含む）１２に連結されたモデムを介してコンピュータ１２使用者との接続を行う場合には、ゲートウェイ４０を経由して、当該ＩＰを有するコンピュータ２３に接続してメールのやり取り或いは通話を行うことができる。

一方、無線網は、図２に示すように各地域毎に分割して分散設置し、移動電話５４とのデータやり取りを行う基地局５１と、各基地局５１を一定のグループにして管掌する基地局５２と、各基地局５２を総括し、顧客番号等の認識、通話時間等のチェック及び交換機能を行う交換局５３とを含んでなる。
交換局５３は、他の交換局５３−１（例えば０１７）との接続時には、約定によって相互通過ができるようにデータをコード変換して使用している。

図３は有無線網が結合された方式の構成図であって、移動電話５４が基地局５１、基地局５２及び無線移動電話交換局５３を介して通話するようにする無線網Ｃと、回線網１を介して接続する有線電話交換局１１を介して一般有線電話１２使用者が通話する電話有線網Ａと、有線電話交換局１１に接続して有無線接続を可能にし、パケット網３０に接続してインターネットを可能にする。インターネットサービスプロバイダー２１に会員として加入したコンピュータ２３使用者が使用するインターネット有線網Ｂとからなり、インターネットサービスプロバイダー(２１は交換局１１と網変換するゲートウェイ４０とを含む構成を例示することができる。

一方、インターネット端末機を用いる網構成は、図４に示すように、コンピュータ２３、Ｗｅｂ電話２４、ＰＣ電話２５などのＩＰアドレスを認識するゲートキーパー２６と、ゲートキーパー２６によるアドレスに基づいて多数のゲートキーパー回線を共有するようにスイッチングするルーター２２と、各ルーター２２を介して接続するインターネットサービスプロバイダー２１と、インターネットサービスプロバイダー２１を介して提供されるインターネットパケット網３０と、一般有線電話交換局１１を介して一般電話（ISDN含む）１２を接続させる回線網１と、移動電話５４が基地局５１、基地局センタ５２及び無線移動電話交換局５３を介して通話するようにし、無線移動電話交換局５３が回線網１とも接続して一般電話（ISDN含む）１２との通話を可能にする無線網Ｃと、前記一般有線電話交換局１１或いは無線移動電話交換局５３とゲートキーパー２６とを互いに連結し、回線網利用一般電話（ISDN含む）１２と移動電話５４の当該電話番号とインターネットＩＰアドレスを相互変換して当該電話１２、５４とインターネット端末機２８とが相互接続できるように機能するゲートウェイ２８とからなる。

この場合、ゲートウェイ２８にはインターネット端末機２９の加入者ＩＰアドレスと回線網１を使用する加入者電話番号を同時に記憶し、加入者電話番号を一般有線電話交換局（ＯＬＥ：Originating Local Exchange）１１（又は無線（移動）電話交換局５３）を介して所望の電話を呼び出して通話するようにする。
すなわち、ゲートウェイ２８は、回線網１との接続時には電話番号に基づいて連結し、インターネット網のパケット網３０を利用するときにはＩＰアドレスに基づいて相互連結するように機能する。このために、ゲートウェイ２８はＩＰアドレスと電話番号を同時に記憶することが要求される。Ｄは回線網を成す有線網と無線網Ｃを含み、選択使用可能な一般電話（ISDN含む）網である。

前記インターネット端末機のＰＣ電話２５同士の通話を行うためには、図５に示すように、ゲートキーパー２６にＰＣ電話２５がＰＣ電話２５−１のＩＰアドレス認証を要請する(ＡＲＱ)（１）。ゲートキーパー２６はＰＣ電話２５−１のＩＰが連結可能であるかを内蔵データと比較して連結可否をＰＣ電話２５に知らせる（２）。すると、ＰＣ電話２５はセットアップをゲートキーパー２６に要請し（３）、ゲートキーパー２６はこれに基づいてＰＣ電話２５−１の状態をセットアップさせる（４）。次に、ＰＣ電話２５−１がゲートキーパー２６に認証を要請し（５）、ゲートキーパー２６はこれを受諾する（６）。受諾が終わると、ＰＣ電話２５とＰＣ電話２５−１とが互いに接続する（７）。

この場合、ＰＣ電話２５はIP電話を意味するもので、IP電話（例えば、Ｗｅｂ電話）は根本的にインターネットＩＰアドレスを介して相互接続が可能である。ところが、ＩＰ（アドレス）は一般人が記憶し難く、また動的IPを使用するＬＡＮ環境の下では随時ＩＰが変わるため、プログラムを用いて（例えば、「Get Local Host()」プログラムなど）確認する他はないため、一般人は分ることができない。したがって、この場合、一般人がＩＰアドレスを確認することは専門知識を有している人でなければ難しい。

かかる問題点を解決するために、IP電話では、一般人が使用してきた一般電話（ISDN含む）番号と類似の覚え易くて使用上便利な番号をＩＰアドレスに代えて与えた後、実際電話通話の際にＷｅｂ電話の電話交換装置であるゲートキーパー２６がマッピングテーブル（ＩＰアドレス、IP電話番号）を用いて通話対象端末機のＩＰアドレスを探し出してＷｅｂ電話に伝達することにより、ＩＰアドレスによる通話と同様の役割をする。

ところが、勧告案ＩＴＵ−Ｔによれば、ＩＰアドレスの代りに使用可能な電話番号で指定項目（フィールド）（Ｅ.１６４番号、電子メール番号、エイリアス番号）を指定して使用するようにする。このようなマッピング構造の一例としては、図１０ａのような表（ＩＰアドレス６１、Ａｌｉａｓ名義６２、電子メール番号６３、電話番号(Ｅ.１６４)６４及び状態６５のフィールドを有する）を挙げることができる。ところが、これらの構造は現在使用している方式であって、未だ実用化されていないＷｅｂ電話の場合、専門家ではない限り、既存のＷｅｂ電話の電話番号のみをもってはＷｅｂ電話かIP電話かを正確に分ることができないため、サーバがサービスを提供するには難しさがある。しかも、一般電話（ISDN含む）使用者はＷｅｂ電話のようなIP電話とは電話番号体系が異なって相互通話できない実情である。そして、一般電話（ISDN含む）からIP電話への通話の際、料金付加に必要な要件である加入者か否かの認証処理が出来ずに、サービス商用化が不可能であった。

本発明は、かかる従来の問題点を解決するためのもので、その目的は、IP電話を運営及び管理する事業者提供の認証過程を経由すると、IP電話使用者も一般電話（ISDN含む）使用者との通話ができるようにするサービス方法を提供することにある。
本発明の他の目的は、IP電話を運営及び管理する事業者提供の認証過程を経由すると、一般電話（ISDN含む）使用者もIP電話との通話ができるようにするサービス方法を提供することにある。
本発明のさらに他の目的は、IP電話使用者と一般電話（ISDN含む）使用者間のサービスを可能にする認証用データフォーマットを提供して認証を容易にすることにより、相互呼接続サービスを可能にすることにある。

上記目的を達成するため、本発明は、IP電話を管理するメインサーバに認証サーバを設け、一般電話（ISDN含む）加入者がIP電話への呼接続を要請するときに認証を受けるようにし、認証を受けると、メインサーバの助けで相互通話ができるようにする。
また、本発明は、ゲートウェイと認証サーバ間の認証を行うための標準メッセージフォーマットを作り、相互認証を受けて通話可能にする。

すなわち、本発明は、IP電話と一般電話（ISDN含む）とが一般電話（ISDN含む）網でゲートウェイを介して呼接続できるように、IP電話番号を付与・管理するメインサーバによって行われるが、メインサーバは、加入者か否かを通話開始時毎に認証メッセージフォーマットで認証する認証サーバとを含み、IP電話番号加入者が呼要請するために一般電話（ISDN含む）番号を押すと、ゲートウェイでは認証サーバからIP電話番号加入者がIP電話サービスを受けられるか認証を受ける段階と、認証されるとIP電話番号加入者が一般電話（ISDN含む）番号を呼び出すとき、ゲートウェイでは呼出者がIP電話番号加入者であるか否かをゲートキーパーから確認する段階と、IP電話番号の確認後、通常の呼接続過程を経て一般電話（ISDN含む）と通話する呼接続段階とを順次行う、ＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス方法を提供する。

また、本発明は、一般電話（ISDN含む）とIP電話が一般電話（ISDN含む）網でゲートウェイを介して呼接続できるように、IP電話番号を付与・管理するメインサーバによって行われるが、メインサーバは、加入者か否かを通話開始時毎に認証する認証サーバを含み、呼出者がIP電話番号事業者認識番号を押すと、ゲートウェイでは認証サーバから一般電話（ISDN含む）使用者がIP電話サービスを受けられるか認証を受ける段階と、認証されると一般電話（ISDN含む）使用者が、IP電話のIP電話番号認識番号を含むIP電話番号を呼び出すと、ゲートウェイではIP電話の前記電話番号であるか否かをゲートキーパーから確認する段階と、IP電話番号の確認後、通常の呼接続過程を経て通話する呼接続段階とを順次行う、ＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス方法を提供する。

また、本発明は、一般電話（ISDN含む）とIP電話との通話が可能であるよう、ゲートウェイを介した要請によってメインサーバが認証するメッセージフォーマットを構成し、メッセージフォーマットは認証プログラムバージョンフィールドと、認証拒否理由データフィールドがメッセージ内に含まれた個数を示すソースカウント(ＳＣ)フィールドと、認証によるコマンドメッセージの種類を示すタイプ(ＴＹＰＥ)フィールドと、メッセージの全長を表わすレングス(Length)フィールドと、電話を掛けた呼出者の電話番号(Caller ID)フィールドと、前記コマンドによる認証結果を表わすリターンバリュー(Return Value)フィールドを基本フィールドとして順次構成する、ＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス認証メッセージフォーマットを提供する。

本発明は、インターネット環境の下で使用するＷｅｂ電話の電話番号を与える方式の既存の使用者が勧告案ＩＴＵ−Ｔに基づくフィールド要素の前に、約定の数字又は符号を追加する方式でＷｅｂ電話の電話番号を与えるので、Ｗｅｂ電話使用者はＩＰアドレスが分らなくても、Ｗｅｂ電話の電話番号をもって互いに接続して使用できるように機能する。

また、IP電話から一般電話（ISDN含む）への通話を要請した場合、使用サービスの必須要件であるIP電話加入者のサービス認証手続を行うことにより、加入者に限るサービス提供が可能であり、認証過程による使用者制限がトラフィック制御方法として活用されて通話品質Ｑｏｓを保証する効果を提供する。そして、ＩＰ網(ＶｏＩＰ)を介した低廉な価格の電話サービスが可能になり、認証に必要なメッセージを通信プロトコルで使用するフォーマットを通信規約による形にして提供することにより、現在のゲートウェイなどで必要とする認証手続に対する標準案を提供する。

また、インターネット網を介した一般電話（ISDN含む）との通話の際、インターネット網を経由するので、既存の電話網より低廉な価格で通話することができるとともに、インターネット網で提供される各種付加サービス（天気情報、証券情報、ニュース、電子メール）を、一般電話（ISDN含む）においても提供されるようにすることができる。しかも、従来ではIP電話を設置しなければIP電話との通話が不可能であったが、本発明では、受信者がIP電話を設置しなくても、既存のIP電話加入者が一般電話（ISDN含む）加入者を呼要請すると、メインサーバの認証を経て一般電話（ISDN含む）との相互通話ができるようにした。

以下、本発明の実施例を添付図面に基づいて詳細に説明する。
図６は本発明の網構成図であって、一般電話（ISDN含む）網Ｄとインターネット網(ＩＰ網)のパケット網３０を介してIP電話サービスプロバイダとしてのメインサーバ２００の認証サーバ２１０にマルチメディア通信プロトコルＨ.３２３によってコールセットアップを処理するゲートウェイ２８と、ゲートウェイ２８とIP電話のようなインターネット端末機２９間の呼認証、コールセットアップ及びこれらのエントリーの登録を制御するゲートキーパー２６と、インターネット端末機２９の登録及びスイッチングを制御するメインサーバ２００とからなる。

前記メインサーバ２００は、一般電話（ISDN含む）網Ｄを介した一般電話（ISDN含む）利用者がインターネット端末機との通話のために、通話許可対象者か否かを認証データベース(IdentifyGWDB)のデータベースと比較して認証する認証サーバ２１０と、インターネット端末機２９及び一般電話（ISDN含む）のIP電話番号データを記憶するIP電話番号サーバ２２０と、インターネット網で提供する天気情報、証券情報、交通情報などの付加サービスを提供する付加サービスサーバ２３０とからなる。ＤＢはデータベース２１１、２２１、２３１である。

前記ゲートキーパー２６は、通信事業者の当該ゲートキーパー２６とメディアゲートウェイ２８−１を経て交換局１１加入者の一般電話（ISDN含む）（有無線電話１２、５４）との通話を可能にする。前記ゲートキーパー２６はメインサーバにあり、また回線網を介して通信事業者別のゲートキーパー２６’と接続され、各ゲートキーパー２６’は地域別のメディアゲートウェイ２８−１を介して有無線電話１２、５４に接続するように機能する。有無線電話１２、５４は通常の通信事業者交換局などを介した呼接続によって使用されるので、略式で表記した。

図７は本発明のゲートウェイ２８の内部構成を示すブロック構成図であって、回線網ＰＳＴＮを含む一般電話（ISDN含む）Ｄとゲートキーパー２６との間にはゲートウェイ２８を用いて呼設定を行うように構成する。
ゲートウェイ２８は、交換局１１のSS７プロトコルを処理するシグナル部２８−１１、及び時分割データ形式のメディアデータを処理してインターネット端末機へメディアデータを伝送するMG部２８−１２からなるメディアゲートウェイ２８−１と、シグナル部２８−１１を介したデータの中から付加サービスを分類して行うシグナルゲートウェイ(ＳＧ：Signal Gateway)２８−１と、シングル部２８−１１を介したコールセットアップデータを受けてゲートキーパー２６とマルチメディア通信プロトコルＨ.３２３を行うメディアゲートウェイコントローラ(ＭＧＣ：Media Gateway Controller)２８−３とを含んでなる。

このような構成は通常のゲートウェイ構成を示したもので、一般に商用化されたＣｉｓｃｏ社の製品ＡＳ５３００を例として挙げることができる。本発明は、このようなゲートウェイ２８が図６に示した本発明のメインサーバ２００の制御を受け、本発明を実現するために図９の認証機能を行うよう、ゲートウェイ２８のメディアゲートウェイコントローラ２８−３を本発明に合わせて完成した。

図８は本発明に使用する一般電話（ISDN含む）網Ｄ及びゲートウェイ２８を用いた一般電話（ISDN含む）とIP電話との通話を行うための呼設定手続図であって、後述する段階Ｓ２に次いで段階Ｓ３を行う前に、認証サーバを介して認証を受ける認証段階Ｓ２０を追加したものである。

図８において、一般電話（ISDN含む）１２のコール要請によって、交換局１１はまずLNP(Local Number Portability)を問合せし、SS７プロトコル(SS7 Signaling)をセットする（プロトコルＱ.９３１）（段階Ｓ１）。交換局ＯＬＥ１１はＩＡＭメッセージ(ISUP Initial Address Message)を隣接の交換局１１を介してゲートウェイ２８のメディアゲートウェイコントローラ(VOIP Media Gateway Controller;以下「ＭＧＣ」という）２８−３に伝達する。この場合、ＩＡＭに含まれる情報は、伝送回路情報(Forward Circuit Information)、キャリア認識コード(Carrier Identification Code)、受信者番号(Called Party Number)、呼出者番号(Calling Party Number)を含む（段階Ｓ２）。
この際、ＭＧＣ２８−３は本発明でメインサーバとして構成した図６の認証サーバ２１０にサービス可否を問うメッセージを伝送し、serviceIdentify return resultメッセージを受ける。
これにより、ＭＧＣは呼設定メッセージを呼出者(caller)の交換局ＯＬＥに送る（段階Ｓ３）。

次に、交換局ＯＬＥのメディア能力メッセージであるタイプSDP Stringが交換局ＯＬＥ１１からＡＣＫメッセージとして伝達される（Ｓ４）。
電話番号ディジットシーケンス(Digit Sequence)が伝達される（Ｓ４−１）。
ＭＧＣは呼出者に認知メッセージが収容されたという信号を送る（Ｓ４−２）。
ＭＧＣは被呼出者(Called Party)にＣＲＣＸメッセージを送って接続メッセージを生成する。すなわち、この段階において、ＭＧＣはゲートキーパー２６にセットアップメッセージを送ってＩＰ網を介してプロトコルＨ.３２３コールセットアップ手続を行う（Ｓ５）。
その後、被呼出者の受信者に呼接続ＩＤが選択され、受信者はそのＩＰアドレス、ＵＤＰポート、メディアタイプ、コネクションモードに関する情報を戻す（Ｓ６）。
そして、ＭＧＣからＭＤＣＸメッセージ信号が交換局ＯＬＥ１１に到達する（Ｓ７）。
すると、交換局ＯＬＥはＭＧＣに通知要求メッセージがそれによって収容されたことを知らせる。よって、リングバック(Ring Back)が始まる（Ｓ８）。

ＭＧＣは受信者にＲＱＮＴメッセージを送ってオンフック(On Hook)状態をチェックする（段階Ｓ９）。
そして、通知要求メッセージが受信者に受け入れられたことを、ＭＧＣはＡＣＫメッセージで受ける（コールが連結された状態）（Ｓ１０）。
ＭＧＣはＩＡＭを送った交換局ＯＬＥにＡＣＭ(Address Complete Message)メッセージを送る（段階Ｓ１１）。
受信者はＭＧＣにＮＴＦＴメッセージを伝送するが、これは電話がオフフック(off-hook)状態であることを知らせて「回答（Answer）」したことを示す（Ｓ１２）。
すると、ＭＧＣはＡＣＫメッセージで反応する（Ｓ１３）。
そして、ＭＧＣは受信者にRQNTメッセージを送り出してハングアップ(Hang-up)状態をチェックする（Ｓ１４）。

次に、ＭＧＣはこのＡＣＫセージを送る（Ｓ１５）。
その後、ＭＧＣ２８−３は、ゲートウェイシグナル部２８−１１にＭＤＣＸメッセージ信号を発送し、確認メッセージＡＣＫを受信して受信者とゲートウェイ２８間のコールセットアップが完了したことを知らせる（Ｓ１６、Ｓ１７）。
ＭＧＣはコールが安全に設定されたことをＩＳＵＰ（ＡＮＭ）メッセージで交換局ＯＬＥ１１に知らせる（Ｓ１８）。
次いで、交換局ＯＬＥは呼出者にConnectメッセージを送る（Ｓ１９）。

図９は本発明の認証段階を示すフローチャートであって、認証機能を持つ認証サーバを含み、使用者番号を付与・管理するメインサーバを設け、メディアゲートコントローラ２８−３が認証サーバ２１０に認証確認のためのserviceIdentify Invokeメッセージを伝送するメッセージ伝送段階（Ｓ２１）と、認証サーバ２１０でメッセージを確認して加入者なのか否かを認証する認証処理段階（Ｓ２２）と、認証処理結果メッセージ(serviceIdentify return result、serviceIdentify return error)を伝送する結果メッセージ伝送段階（Ｓ２３）と、結果メッセージをメディアゲートウェイコントローラ２８−３が受信し、結果メッセージがエラーであれば呼設定を停止し、結果メッセージがあれば呼設定を行い続ける認証結果処理段階（Ｓ２４）とから構成される。

図１０ｂは本発明のIP電話番号を示すマッピングテーブルの構造例示図である。図１０ｂを参照すると、本発明のフィールドは従来（図１０ａ）と同様にＩＰアドレス６１、Ａｌｉａｓ名義６２、電子メール番号６３、電話番号(Ｅ.１６４)６４及び状態６５フィールドをもっている。但し、本発明は、各フィールドを構成する要素からＩＰアドレス６１及び状態６５フィールドを除いたフィールドの要素構成を既存の要素名義の初頭に別途のIP電話認識用付加部１３０を付加する。

この付加部１３０は、メインサーバを指定するIP電話番号事業者認識番号（例えば、００Ｙ、０＊＊など文字及び／又は数字を含む）１１０と、IP電話番号か否かを区分するIP電話番号認識番号（文字及び／又は数字、null）１２０が順次並ぶように与える。付加部１３０を構成する各認識番号１１０、１２０の好適な例としては、数字（０〜９）又は文字（＃、＊、null）などを挙げることができる。 この際、文字がnullの場合は、IP電話番号認識番号１２０に適用され、既存の電話番号(TelCo No，Mobile Phone No.)体系と同一であることを意味する。勿論、必要に応じて追加文字又は符号を既存の電話番号要素の末尾に加えることができる。この追加する数字は１桁数字の他に２桁、３桁数字などに拡張可能である。しかも、海外から国内へ、逆に国内から海外に通話する場合は、国家番号の前に前記IP電話認識用数字又は文字を付加すると、IP電話番号として認識できる。

このようにIP電話番号マッピングテーブルを構成すると、インターネット環境の下でメール又は電話通話のためにメインサーバを介して認証を受け、加入者相互接続又は一般電話（ISDN含む）との接続を可能にするので、Ｗｅｂ電話サービスを行うメインサーバから会員加入結果及び加入番号を提供するとき、Ｗｅｂ電話事業者認識番号とＷｅｂ電話認識用付加部を含む電話番号とを提供する。このような電話番号はＷｅｂ電話使用者の電話番号であるか否かを直ちに確認できるようにするので、Ｗｅｂ電話使用者がインターネット環境の下で使用するＩＰアドレスを知らなくても、メインサーバを介した認証によってＷｅｂ電話加入者同士だけでなく、Ｗｅｂ電話使用者が一般電話（ISDN含む）使用者を呼び出して（その逆順も可能）容易に接続できるようにする。

図１１は図６及び図７に示したゲートウェイ２８のメディアゲートウェイコントローラ２８−３とメインサーバ２００の認証サーバ２１０との認証のためのメッセージフォーマットを示す。このメッセージフォーマットは、認証プログラムバージョンＶフィールド（２ビット）と、認証拒否理由データフィールドが、メッセージ内に含まれた個数を示すソースカウントＳＣフィールド（５ビット）と、認証によるコマンドメッセージの種類（メディアゲートウェイコントローラＭＧＣ）２８−３で生成するメッセージ１００(serviceIdentify Invoke)、１０１(serviceIdentify return result)、１０２(serviceIdentify return error)、１０３(serviceIdentify Reject)を示すタイプ(ＴＹＰＥ)フィールド（８ビット）と、メッセージの全長を示すレングス(Length)フィールド（１６ビット）と、電話を掛けた呼出者の電話番号(Caller ID)フィールド（１６ビット）と、前記コマンドによる認証結果（０：Success、１：Fail、２：認証サーバInternal Error）を示すリターンバリュー(Return Value)フィールド（８ビット）を基本フィールドとして順次構成する。

前記リターンバリュー(Return Value)フィールドに次いで、認証拒否理由を示すリーズン(Reason)フィールド（３２ビット）と、リーズンフィールドに認証拒否(Reject)理由に対する詳細説明を表わすデスクリプション(Description)フィールド（３２ビットの倍数）が順次付加される。
前記において、フィールドＶからフィールドReturn Valueまでは固定長を有し、フィールドReason、Descriptionは可変長を有する。

図１２は、ゲートウェイからの要請がある場合の認証サーバで認証を行う段階を示すステートダイアグラムであって、認証サーバ２１０の最初状態はアイドル状態（段階）であり、一般電話（ISDN含む）網Ｄからの要請によってゲートウェイ２８のメディアゲートウェイコントローラＭＧＣ２８−３から認証要請がくると、これを受け入れる。

すなわち、前記認証を受ける段階は、ゲートウェイ２８から認証要請メッセージ(serviceIdentity Invoke)ＮＷ１が到着すると、認証サーバ２１０は、待機段階に転換するとともに認証プロセシング段階に転換するアイドル段階(Idle State)ＳＴ１、認証要請メッセージによって伝達された呼出者ＩＤ(Caller ID)をもって認証データベース(IdentifyGWDB)をアクセスしてサービス可否を決定し、この決定作業が完了すると、認証完了段階ＳＴ３に転換する認証プロセシング段階(Processing State)ＳＴ２と、認証が問題なく終了すると、その結果を送り出すserviceIdentify return result(ＯＮＷ２)或いはserviceIdentify Reject(ＯＮＷ１)メッセージを作成した後ゲートウェイに送り出し、認証過程でエラーが発生すると、serviceIdentify return error(ＯＮＷ３)メッセージを作成してゲートウェイに伝送する認証完了段階ＳＴ３と、一定のタイムアウト(TIME-OUT)の間、認証作業の完了を待った後、もしタイムアウトが完了すれば、認証要請をリジェクトするメッセージを作成してゲートウェイに送り出し、起動状態ＳＴ５に転換した後、認証に使用された全ての支援を解除し、アイドル状態に戻って他の認証要請を待つ待機段階ＳＴ４と、前記段階ＳＴ３以後、認証サーバはアイドル段階ＳＴ１に転換されて他の認証要請を待つアウェイクン段階ＳＴ５とを含んで行う。図面において、メッセージＮＷ１は認証要請メッセージ(serviceIdentify Invoke)、メッセージＯＮＷ１は認証要請リジェクトメッセージ(serviceIdentify Reject) 、メッセージＯＮＷ２は認証要請結果メッセージ(serviceIdentify return result)、メッセージＯＮＷ３は認証要請結果メッセージ(serviceIdentify return error)をそれぞれ示す。

図１３は前記認証サーバで行う認証プロセシング段階ＳＴ２を行うフローチャートであって、ゲートウェイからserviceIdentify Invoke eventメッセージが発生するとき、このメッセージのバージョンＶ(Version)フィールドと認証サーババージョンとを比較し、呼出者(Caller ID)のデータが電話番号（数字）形式に合うか否かをチェックする段階（Ｔ１、Ｔ２、Ｔ３）と、バーションが一致しない、或いは呼出者(Caller ID)値が有効なフォーマットではない場合、serviceIdentify return errorメッセージを作成してゲートウェイに伝送する段階（Ｔ４、Ｔ５）と、バージョンが一致する、或いは呼出者値が有効なフォーマットである場合、認証に使用されるデータベース(IdentifyGWDB)をアクセスし、サービス可否を判断するフィールド値が、サービス可能を示す「１」であるか否かを確認する段階（Ｔ６、Ｔ７）、「１」であれば、serviceIdentify return result(ＴＹＰＥ=１０１)メッセージを作成してゲートウェイに伝送する段階（Ｔ１０、Ｔ１１）と、「０」であれば、サービス期間が満了したか或いは認証データベースに登録されていない場合であって、serviceIdentify Reject(ＴＹＰＥ=１０３)メッセージを作成し、この際、リジェクト理由及びその理由に対する詳細説明をリーズンフィールド及びデスクリプションフィールドに作成する段階（Ｔ８、Ｔ９）とを行う。

図１４は図１３に示した認証データベース(IdentifyGWDB)のデータフォーマットの一例を示す図であって、ゲートウェイから認証要請してきた呼出者(Caller ID)に関する認証基準の判断のためのデータベースであり、Caller IDフィールドはデータベース検索の基準になるフィールドであって、呼出者の電話番号を示し、Nameフィールドは呼出者の申込人の名前、apply dataフィールドは申込日付、due dateフィールドは支払期限、フィールド(valid)はサービス可否、フィールド(remark)は備考欄をそれぞれ示す。

図１５は本発明のゲートウェイ２８における認証を示すステートダイアグラムであって、認証を受ける段階は、ゲートウェイ２８から認証サーバ２１０への認証要請プログラム(evIdentifyStateChanged())を付加的に行い、認証要請プログラムは認証に対する要請が始まるエントリポイント(Entry Point)であって、メッセージ(ISUP(IAM) SS7)が到着すると、状態(evIdentifyNew)に移動する段階(evIdentifyIdle段階)ＳＴ１１と、メッセージ(ISUP(IAM) SS7)が到着して新しい認証要請が発生した状態で、コールバックプログラムではメッセージＩＡＭから呼出者番号を抽出した後、serviceIdentify Invokeメッセージを作成し、認証サーバに送り出す段階(evIdentifyNew段階)ＳＴ１２と、ISUP(IAM) SS7メッセージが到着して認証サーバ２１０に呼出者(Caller)に対する電話サービス認証結果を決定する間、交換局ＯＬＥにＣＲＣＸメッセージを送り出すことを待たせる状態で、待ち時間を設定し、この時間がを超えると、この段階(evIdentifyTO)に移動する段階(evIdentifyWaitForOrig段階)ＳＴ１３と、前記段階(evIdentifyWaitForOrig段階)ＳＴ１３で待ち時間が経過した場合、この状態で移動し、認証手続を終了し、段階(evIdentifyNew)で作られたメッセージ(serviceIdentify Invoke)が認証サーバ２１０に伝送されたことを知らせ、認証サーバからの結果到着を待つ段階(evIdentifySent段階)ＳＴ１５と、認証サーバ２１０からメッセージ(serviceIdentify return error)ＮＷ３又は(serviceIdentify Reject)ＮＷ１が到達して認証失敗した場合、交換局ＯＬＥにＮＡＣＫメッセージを送り出し、この段階(evIdentify Idle)に移動する段階(evIdentifyRejected段階)ＳＴ１６と、認証サーバ２１０からserviceIdentify return result(ＮＷ２)メッセージが到着してサービス認証が行われた場合、メディアゲートウェイコントローラＭＧＣ２８−３がＣＲＣＸメッセージを交換局ＯＬＥに伝送し、この段階(evIdentifyIdle)に移動する段階(evIdentifyApproved段階)ＳＴ１７とからなる。

以上説明した本発明は、前述した実施例及び図面によって限定されるものではない。よって、本発明の技術的思想から逸脱することなく、様々な置換、変形及び変更が可能なのは通常の知識を有する者には明らかなことであろう。

一般的な有線網の構成図である。 一般的な無線網の構成図である。 一般的な有無線及びインターネット有線網の構造を示す構成図である。 一般的なインターネット端末機を用いた網構成の例示図である。 ゲートキーパーを介して一般的なＩＰ認証を行う手続を示す構成図である。 本発明の網構成図である。 図６のゲートウェイ構成の例示図である 一般電話（ISDN含む）とＩＰ電話との通話を行うための本発明の呼設定手続図である。 ゲートウェイと認証サーバ間の認証を行うための本発明のフローチャートである。 （ａ）は一般的な電話番号を表わすデータマッピングフォーマット、（ｂ）は本発明のサービスのための電話番号データマッピングフォーマットである。 本発明のゲートウェイと認証サーバとの認証を行うためのメッセージフォーマットである。 認証サーバで認証を行うステートダイアグラムである。 本発明における認証サーバで認証プロセシングを行うフローチャートである。 本発明で認証サーバにデータベースを提供するデータフォーマットの例示図である。 本発明を構成するゲートウェイで認証を行うステートダイアグラムである。

符号の説明

Ａ…電話有線網 Ｂ…インターネット有線網
Ｃ…無線網 １…回線網
１１…有線電話交換局 １２…一般電話（ISDN含む）
２１…インターネットサービスプロバイダー ２２…ルーター
２３…コンピュータ ２８…ゲートウェイ
２８−１…メディアゲートウェイ ２８−２…シグナルゲートウェイ
２８−３…メディアゲートウェイコントローラ
２８−１１…シグナル部 ２８−１２…ＭＧ部
２９…インターネット端末機 ３０…パケット網
４０…ゲートウェイ ５１…基地局
５２…基地局センタ ５３…交換局
５４…移動電話
１１０…IP電話番号事業者認識番号
１２０…IP電話番号認識番号
１３０…付加部
２００…メインサーバ
２１０…認証サーバ
２２０…IP電話番号サーバ
２３０…付加サービスサーバ

Claims (7)

1. IP電話と一般電話（ISDN含む）とが一般電話（ISDN含む）網でゲートウェイを介して呼接続できるように、IP電話番号を付与・管理するメインサーバによって行われるが、
   メインサーバは、加入者か否かを通話初期時毎に認証メッセージフォーマットを用いて認証する認証サーバを含み、
   IP電話加入者（呼出者）が呼要請するために一般電話（ISDN含む）番号を押すと、ゲートウェイでは認証サーバからIP電話番号加入者がIP電話サービスを受けられるか認証を受ける段階と、
   認証されると、IP電話番号加入者が一般電話（ISDN含む）番号を呼び出すとき、ゲートウェイでは呼出者がIP電話番号加入者であるか否かをゲートキーパーから確認する段階と、
   IP電話番号の確認後、通常の呼接続過程を経て一般電話（ISDN含む）と通話する呼接続段階とを順次行うことを特徴とするＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス方法。
2. 前記認証を受ける段階は、ゲートウェイから認証要請メッセージ(serviceIdentity Invoke)(service identify invoke)ＮＷ１が到着すると、認証サーバは、待機段階に移行するとともに認証プロセシング段階に転換するアイドル段階(Idle State)（ＳＴ１）と、
   認証要請メッセージによって伝達された呼出者ＩＤ(Caller ID)をもって認証データベース(Identify GWDB)をアクセスしてサービス可否を決定し、この決定作業が完了すると、認証完了段階（ＳＴ３）に転換する認証プロセシング段階(Processing State)（ＳＴ２）と、
   認証が問題なく終了すると、その結果を送り出すserviceIdentify return result（ＯＮＷ２）又はserviceIdentify Reject（ＯＮＷ１）メッセージを作成した後ゲートウェイに送り出し、認証過程でエラーが発生すると、serviceIdentify return error（ＯＮＷ３）メッセージを作成してゲートウェイに伝送する認証完了段階（ＳＴ３）と、
   一定のタイムアウト(TIME−OUT)の間、認証作業の完了を待った後、もしタイムアウトが完了すれば、認証要請を拒否するメッセージを作成してゲートウェイに送り出し、アウェイクン(awaken)段階（ＳＴ５）に転換した後、認証に使用された全ての支援を解除し、アイドル状態に戻って他の認証要請を待つ待機段階（ＳＴ４）と、
   前記段階（ＳＴ３）以後、認証サーバはアイドル段階（ＳＴ１）に転換されて他の認証要請を待つアウェイクン段階（ＳＴ５）とを含んで行うことを特徴とする請求項１記載のＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス方法。
3. 前記認証プロセシング段階（ＳＴ２）は、ゲートウェイからserviceIdentify Invoke eventメッセージが発生するとき、このメッセージのバージョンＶ(Version)フィールドと認証サーババージョンとを比較し、呼出者(Caller ID)のデータが電話番号（数字）形式に合うか否かをチェックする段階（Ｔ１、Ｔ２、Ｔ３）と、
   バーションが一致しない、或いは呼出者(Caller ID)値が有効なフォーマットではない場合、serviceIdentify return errorメッセージを作成してゲートウェイに伝送する段階（Ｔ４、Ｔ５）と、
   バージョンが一致し、或いは呼出者値が有効なフォーマットである場合、認証に使用されるデータベース(Identify GWDB)をアクセスし、サービス可否を判断するフィールド値が、サービス可能を表わす「１」であるか否かを確認する段階（Ｔ６、Ｔ７）、
   「１」であれば、serviceIdentify return result (ＴＹＰＥ=１０１)メッセージを作成してゲートウェイに伝送する段階（Ｔ１０、Ｔ１１）と、
   「０」であれば、サービス時間が満了したか或いは認証データベースに登録されていない場合であって、serviceIdentify Reject (ＴＹＰＥ＝１０３)メッセージを作成し、この際、拒否理由及びその理由に対する詳細説明をリーズンフィールド及びデスクリプションフィールドに作成する段階（Ｔ８、Ｔ９）とを行うことを特徴とする請求項２記載のＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス方法。
4. 認証要請段階認証要求時は、ゲートウェイから認証サーバへの認証要請関数認証要求変更(evIdentifyStateChanged())を付加的に行い、
   認証要請関数は、認証に対する要請が始まるエントリポイント(Entry Point)としてISUP(ＩＡＭ) SS7メッセージが到着すると、新規状態(evIdentifyNew)に移行するまでの段階(evIdentifyIdle段階)（ＳＴ１１）と、
   ISUP(ＩＡＭ) SS7メッセージが到着して新しい認証要請が発生した状態で、コールバック関数ではメッセージＩＡＭから呼出者番号を抽出した後、serviceIdentify Invokeメッセージを作成し、認証サーバに送り出す段階(evIdentifyNew段階)（ＳＴ１２）と、
   ISUP(ＩＡＭ) SS7メッセージが到着して認証サーバに呼出者(Caller)に対する電話サービス認証結果を決定する間、交換局ＯＬＥにＣＲＣＸメッセージを送り出すことを待たせる状態で、ウェイトタイムアウト待ち時間切れを設定し、この時間が超えると、段階(evIdentifyTO)に移動する段階(evIdentifyWaitForOrig段階)（ＳＴ１３）と、
   前記段階(evIdentifyWaitForOrig段階)（ＳＴ１３）で待ち時間が経過した場合、この状態で変化し、認証手続を終了し、evIdentifyNew段階で作られたserviceIdentify Invokeメッセージが認証サーバに伝送されたことを知らせ、認証サーバからの結果到着を待つ段階(evIdentifySent段階)（ＳＴ１５）と、
   認証サーバからserviceIdentify return error （ＮＷ３）又はserviceIdentify Reject（ＮＷ１）メッセージが到達して認証失敗した場合、交換局ＯＬＥにＮＡＣＫメッセージを送り出し、evIdentify Idle段階に移行する段階(evIdentifiedRejected段階)（ＳＴ１６）と、
   認証サーバからserviceIdentify return result（ＮＷ２）メッセージが到達してサービス認証が行われた場合、メディアゲートウェイコントローラ（ＭＧＣ）がＣＲＣＸメッセージを交換局ＯＬＥに伝送し、evIdentifyIdle段階に移動する段階(evIdentifyApproved段階)（ＳＴ１７）とからなることを特徴とする請求項１記載のＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス方法。
5. 一般電話（ISDN含む）とIP電話が一般電話（ISDN含む）網でゲートウェイを介して呼接続できるように、IP電話番号を付与・管理するメインサーバによって行われるが、
   メインサーバは、加入者か否かを通話初期時毎に認証する認証サーバを含み、
   呼出者がIP電話番号事業者認識番号を押すと、ゲートウェイでは認証サーバから一般電話（ISDN含む）使用者がIP電話サービスを受けられるか認証を受ける段階と、
   認証されると、一般電話（ISDN含む）使用者がIP電話のIP電話番号認識番号を含むIP電話番号を呼び出すと、ゲートウェイではIP電話の前記電話番号であるか否かをゲートキーパーから確認する段階と、
   IP電話番号の確認後、通常の呼接続過程を経て通話する呼接続段階とを順次行うことを特徴とするＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス方法。
6. 一般電話（ISDN含む）とIP電話との通話ができるように、ゲートウェイを介した要請によってメインサーバが認証するメッセージフォーマットを構成し、
   メッセージフォーマットは、認証プログラムバージョンフィールドと、
   認証拒否理由データフィールドがメッセージ内に含まれた個数を示すソースカウント（ＳＣ）フィールドと、
   認証によるコマンドメッセージの種類を示すタイプ(ＴＹＰＥ)フィールドと、
   メッセージの全長を示すレングス(Length)フィールドと、
   電話を掛けた呼出者の電話番号(Caller・ID)フィールドと、
   前記コマンドによる認証結果を示すリターンバリュー(Return Value)フィールドとを基本フィールドとして順次構成することを特徴とするＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス認証メッセージフォーマット。
7. 前記リターンバリュー(Return Value)フィールドに次いで、認証拒否理由を示すリーズン(Reason)フィールドと、
   リーズンフィールドに認証失敗理由に対する詳細説明を表わすデスクリプション(Description)フィールドとが順次付加されたことを特徴とする請求項６記載のＩＰ網を用いたIP電話と一般電話（ISDN含む）間のサービス認証メッセージフォーマット。
   
   

Images