JP4236032B2 - インターネット通信システム及びインターネット通信方法及びセッション管理サーバ及び通信アダプタ - Google Patents

インターネット通信システム及びインターネット通信方法及びセッション管理サーバ及び通信アダプタ Download PDF

Info

Publication number
JP4236032B2
JP4236032B2 JP2002582687A JP2002582687A JP4236032B2 JP 4236032 B2 JP4236032 B2 JP 4236032B2 JP 2002582687 A JP2002582687 A JP 2002582687A JP 2002582687 A JP2002582687 A JP 2002582687A JP 4236032 B2 JP4236032 B2 JP 4236032B2
Authority
JP
Japan
Prior art keywords
communication
adapter
session management
management server
communication adapter
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.)
Expired - Fee Related
Application number
JP2002582687A
Other languages
English (en)
Other versions
JPWO2002098085A1 (ja
Inventor
明彦 内藤
信仁 宮内
俊 木村
寛樹 森岡
Original Assignee
アイピートーク株式会社
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 アイピートーク株式会社 filed Critical アイピートーク株式会社
Publication of JPWO2002098085A1 publication Critical patent/JPWO2002098085A1/ja
Application granted granted Critical
Publication of JP4236032B2 publication Critical patent/JP4236032B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/10015—Access to distributed or replicated servers, e.g. using brokers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Description

技術分野
この発明は、例えば、音声データ（リアルタイム特性をもつデータとして、動画表示や３次元グラフィックス表示のためのデータも類似的に応用が可能である）を送受信する通信装置に通信アダプタを接続して、通信アダプタを接続した発呼側の通信装置と着呼側の通信装置とによりインターネットを介して音声データを送受信するインターネット通信システム、及び、インターネット通信方法に関する。特に、発呼側の通信アダプタを管理する発呼側セッション管理サーバと、着呼側通信アダプタを管理する着呼側セッション管理サーバとを備えるインターネット通信システム、及び、インターネット通信方法に関する。
また、発呼側通信アダプタと着呼側通信アダプタとから接続され、発呼側及び着呼側の双方の通信アダプタを管理するセッション管理サーバと、セッション管理サーバ上で動作するプログラムに関する。
また、発呼側セッション管理サーバと着呼側セッション管理サーバとに接続され、発呼側及び着呼側の双方のセッション管理サーバと通信を行う通信アダプタと、通信アダプタ上で動作するプログラムに関する。
また、発呼側の通信アダプタと発呼側通信中継サーバと着呼側の通信アダプタと着呼側通信中継サーバとのそれぞれの間を、所定の通信手順を用いてデータ通信するインターネット通信システム、及び、インターネット通信方法に関する。
また、通信アダプタとサーバ装置との間を、所定の通信手順を用いてデータ通信する通信中継サーバと、通信中継サーバ上で動作するプログラムに関する。
背景技術
音声データをインターネットを介して送受信するインターネット電話ネットワークシステムでは、発呼側の通信アダプタと着呼側の通信アダプタにＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを付与して通信をする。ここで、ＩＰアドレスは、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）で通信する送信元と送信先とを識別するアドレスである。ＩＰアドレスには、世界的にユニークな識別性を持つグローバルＩＰアドレスとユーザが独自に設定するローカルＩＰアドレス（プライベートＩＰアドレスとも呼ぶ場合もある）があるが、以下、単に「ＩＰアドレス」という場合は、グローバルＩＰアドレスを意味するものとする。
また、発呼側の通信アダプタと着呼側の通信アダプタが通信する場合、発呼側の通信アダプタと着呼側の通信アダプタとの間に通信を中継する中継サーバを設置する場合がある。例えば、着呼側のネットワーク環境が、例えば、着呼側がファイアフォールに守られているネットワーク環境である場合に、中継サーバにより着呼側のネットワーク環境に合わせた通信手段が選択されて、発呼側と着呼側とを接続することがある。
また、着呼側がＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ ｄｉｇｉｔａｌ ｓｕｂｓｃｒｉｂｅｒ ｌｉｎｅ）接続装置の下層に配置されていることによりアドレスが動的に割り当てられたり、ローカルＩＰアドレスが割り当てられたりしてしまうため、発呼側の通信アダプタが直接着呼側の通信アダプタと接続できないようなネットワーク環境である場合に、中継サーバにより着呼側のネットワーク環境に合わせた通信手段が選択されて、発呼側と着呼側とを接続することがある。
また、ＡＤＳＬに限らず、ＣＡＴＶ（Ｃａｂｌｅ Ｔｅｌｅｖｉｓｉｏｎ）、ＦＴＴＨ（Ｆｉｖｅｒ Ｔｏ Ｔｈｅ Ｈｏｍｅ）、インターネットマンション等、あらゆるインターネット接続環境の中でルータ装置の設定によってその下層に通信アダプタが配置されていることより、通信アダプタのアドレスが動的に割り当てられたり、通信アダプタにローカルＩＰアドレスが割り当てられたりしてしまうため、発呼側の通信アダプタが直接着呼側の通信アダプタと接続できないようなネットワーク環境である場合に、中継サーバにより着呼側のネットワーク環境に合わせた通信手段が選択されて、発呼側と着呼側とを接続することがある。
図２７に、ＰＣＴ／ＪＰ０１／０４００３（出願日が２００１年５月１５日であり、本出願の優先権主張の基礎となる出願出願時において未公開のＰＣＴ出願。詳細はＰＣＴ／ＪＰ０１／０４００３の出願を参照されたい。或いは、ここに、ＰＣＴ／ＪＰ０１／０４００３の出願を参照としてインコーポレートするものとする（ＰＣＴ／ＪＰ０１／０４００３ ＩＳ ＩＮＣＯＲＰＯＲＥＴＥＤ ＨＥＲＥＩＮ ＢＹ ＲＥＦＥＲＥＮＣＥ）。）に示されたインターネット電話ネットワークシステムの構成図を示す。図２７の９１０，９２０は、電話機であり屋内電話線９１１，９２１によって通話アダプタ９１２，９２２と接続されている。電話機９１０，９２０との間には通話データの送受信を中継する中継サーバ９１８が設置されている。中継サーバ９１８は、複数のＨＴＴＰ（ハイパーテキスト トランスファ プロトコル）中継サーバ９１８ａと９１８ｂと、ＨＴＴＰ中継サーバを管理するＨＴＴＰ中継サーバ管理サーバ９８０とにより構成されている。また、中継サーバ９１８はインターネット１６を介して電話機９１０，９２０とを接続している。電話機９１０を発呼側、電話機９２０を着呼側として、発呼側から着呼側へ通話を行うために接続を行うと、中継サーバ管理サーバ９８０は、インターネットを介して発呼側から発呼要求を受け取る。ＨＴＴＰ中継サーバ管理サーバ９８０は、受け取った発呼要求をもとに中継可能なＨＴＴＰ中継サーバを選択する。選択されたＨＴＴＰ中継サーバは、発呼側と着呼側との通信を中継する。
このようなシステムでは、一台のＨＴＴＰ中継サーバ管理サーバが全ての通話アダプタとＨＴＴＰ中継サーバを管理して、通信の中継を実現していた。
上記したインターネット電話ネットワークシステムでは、通話アダプタが普及して数十万台単位で通話アダプタが全国、全世界に設置されるようになると、一台の中継サーバ管理サーバで全ての中継サーバと通話の要求を行う通話アダプタとを管理することは能力的に無理があり、システムの実現が困難であるという問題が発生する。また、中継サーバ管理サーバが全ての中継サーバを管理できたとしても、提供できるサービスの質が低下するという問題が発生する。
この発明は、例えば、通話（通信）アダプタの数が増加しても通信システムが運営できるようにすることを目的とする。
発明の開示
この発明に係るインターネットを用いてデータ通信をするインターネット通信システムは、発呼側の通信アダプタと、着呼側の通信アダプタと、発呼側の通信アダプタを管理する発呼側のセッション管理サーバと、着呼側の通信アダプタを管理する着呼側のセッション管理サーバとを備え、発呼側の通信アダプタは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、発呼側のセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを発呼側の通信アダプタへ返信し、発呼側の通信アダプタは、発呼側のセッション管理サーバから着呼側のセッション管理サーバのサーバＩＤを受信し、受信したサーバＩＤで識別される着呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、着呼側の通信アダプタとのセッションの確立要求を送信し、着呼側のセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、着呼側の通信アダプタは、着呼側のセッション管理サーバにセッションの確立要求が記憶されているかを自己のアダプタＩＤにより検索し、着呼側のセッション管理サーバにセッションの確立要求が記憶されている場合に、かつ、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信し、着呼側のセッション管理サーバは、着呼側の通信アダプタから通信可能状態が通知された場合に、インターネットを用いたセッションの確立を発呼側の通信アダプタと着呼側の通信アダプタとに許可することを特徴とする。
また、この発明に係るインターネットを用いてデータ通信をするインターネット通信システムは、発呼側の通信アダプタと、着呼側の通信アダプタと、発呼側の通信アダプタを管理する発呼側のセッション管理サーバと、着呼側の通信アダプタを管理する着呼側のセッション管理サーバとを備え、発呼側の通信アダプタは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求を送信し、発呼側のセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している受信したサーバＩＤで識別される着呼側のセッション管理サーバへ、着呼側の通信アダプタのアダプタＩＤを含むその発呼メッセージを転送し、着呼側の通信アダプタとのセッションの確立要求を送信し、着呼側のセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、着呼側の通信アダプタは、あらかじめ、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信しておき、着呼側のセッション管理サーバによりセッションの確立要求が記憶されているかを自己のアダプタＩＤにより検索された結果、着呼側の通信アダプタにセッションの確立要求があったという情報を受信し、着呼側のセッション管理サーバは、着呼側の通信アダプタから通信可能状態が通知された場合に、インターネットを用いたセッションの確立を発呼側のセッション管理サーバと着呼側の通信アダプタとに許可し、発呼側の通信アダプタは、発呼側のセッション管理サーバから、通信可能状態にある場合に通信可能状態情報を受信し、インターネットを用いたセッションの確立を行うことを特徴とする。
この発明に係るインターネット通信システムは、インターネットを用いてデータ通信をするインターネット通信システムにおいて、
発呼側の通信アダプタと、
着呼側の通信アダプタと、
発呼側の通信アダプタを管理する発呼側のセッション管理サーバと、
着呼側の通信アダプタを管理する着呼側のセッション管理サーバ
とを備え、
発呼側の通信アダプタは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求を送信し、
発呼側のセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを求め、求めたサーバＩＤで識別される着呼側のセッション管理サーバへアダプタＩＤを送信して、着呼側の通信アダプタとのセッションの確率要求を送信し、
着呼側のセッション管理サーバは、発呼側のセッション管理サーバから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、着呼側の通信アダプタからの通信可能状態を受信して、受信した通信可能状態の着呼側の通信アダプタに対するセッション確立要求が記憶されている場合に、インターネットを用いたセッションの確立を発呼側のセッション管理サーバと着呼側の通信アダプタとに許可し、
着呼側の通信アダプタは、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信し、
発呼側の通信アダプタは、発呼側のセッション管理サーバから、着呼側のセッション管理サーバからインターネットを用いたセッションの確立を許可されたことを受信することを特徴とする。
また、この発明に係るインターネット通信システムは、更に、通信アダプタからアダプタＩＤを受信し、通信アダプタを管理するセッション管理サーバをアダプタＩＤに基づいて指定し、指定したセッション管理サーバのサーバＩＤを通信アダプタに通知する指定通知サーバを備えたことを特徴とする。
また、この発明に係るインターネット通信システムは、更に、発呼側の通信アダプタと着呼側の通信アダプタとの間の通信を中継する着呼側の通信中継サーバを備え、着呼側のセッション管理サーバは、着呼側の通信中継サーバを識別する着呼側の通信中継サーバＩＤを発呼側の通信アダプタと着呼側の通信アダプタとに送信し、発呼側の通信アダプタと着呼側の通信アダプタとは、着呼側の通信中継サーバＩＤを受信し、着呼側の通信中継サーバＩＤで識別される着呼側の通信中継サーバを介してセッションを確立することを特徴とする。
また、この発明に係る上記インターネット通信システムは、更に、発呼側の通信アダプタと着呼側の通信アダプタとの間の通信を中継する発呼側の通信中継サーバを備え、発呼側のセッション管理サーバは、発呼側の通信中継サーバを識別する発呼側の通信中継サーバＩＤを発呼側の通信アダプタに送信し、発呼側の通信アダプタは、発呼側の通信中継サーバＩＤを受信し、発呼側の通信中継サーバＩＤを着呼側のセッション管理サーバに送信し、着呼側のセッション管理サーバは、発呼側の通信中継サーバＩＤを着呼側の通信アダプタに送信し、着呼側の通信アダプタは、発呼側の通信中継サーバＩＤを受信し、発呼側の通信アダプタと着呼側の通信アダプタとは、発呼側の通信中継サーバＩＤで識別される着呼側の通信中継サーバを介してセッションを確立することを特徴とする。
また、上記アダプタＩＤは、インターネットサービスプロバイダ（ＩＳＰ）など個々のローカルＩＰアドレスにより各接続端末を管理しているドメインの識別子を含むことを特徴とする。
また、上記アダプタＩＤは、インターネットサービスプロバイダ（ＩＳＰ）が管理するローカルＩＰ（インターネットプロトコル）アドレスのドメインの識別子を含むことを特徴とする。
また、上記アダプタＩＤは、通信アダプタが設置されたエリア（ここでいうエリアは、物理的なエリアだけでなく、論理的に複数の端末をグループ化することによる、そのグループの形態をとる場合もある）の識別子を含むことを特徴とする。
また、上記アダプタＩＤは、通信アダプタをグループ化するグループ識別子を含むことを特徴とする。
この発明に係るインターネットを用いてデータ通信をするインターネット通信方法は、発呼側の通信アダプタから発呼側のセッション管理サーバに着呼側の通信アダプタを管理している着呼側のセッション管理サーバを問い合わせ、発呼側のセッション管理サーバから発呼側の通信アダプタに着呼側の通信アダプタを管理している着呼側のセッション管理サーバを回答し、発呼側の通信アダプタから着呼側のセッション管理サーバに着呼側の通信アダプタに対するセッションの確立要求を送信し、発呼側の通信アダプタから着呼側の通信アダプタに対してセッションの確立要求が合ったことを着呼側のセッション管理サーバに記憶し、着呼側の通信アダプタから着呼側のセッション管理サーバに対してセッションの確立要求があったか否かを問い合わせ、セッションの確立要求があった場合に、かつ、着呼側の通信アダプタが通信可能状態にある場合に、着呼側の通信アダプタから着呼側のセッション管理サーバに通信可能状態にあることを知らせ、着呼側の通信アダプタが通信可能状態にあることを通知された場合に、着呼側のセッション管理サーバがインターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可することを特徴とする。
この発明に係るインターネットを用いてデータ通信をするインターネット通信方法は、発呼側の通信アダプタから発呼側のセッション管理サーバに着呼側の通信アダプタに対する着呼側の通信アダプタのアダプタＩＤを含むセッションの確立要求を送信し、さらに、発呼側のセッション管理サーバから着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ、そのセッションの確立要求を転送し、発呼側の通信アダプタから着呼側の通信アダプタに対してセッションの確立要求が合ったことを着呼側のセッション管理サーバに記憶し、着呼側の通信アダプタは、あらかじめ、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信しておき、着呼側のセッション管理サーバによりセッションの確立要求が記憶されているかを自己のアダプタＩＤにより検索された結果、着呼側の通信アダプタにセッションの確立要求があったという情報を着呼側のセッション管理サーバが受信する場合に、着呼側のセッション管理サーバがインターネットを用いた発呼側のセッション管理サーバと着呼側の通信アダプタとのセッションの確立を許可し、発呼側のセッション管理サーバは、そのセッションの確立の許可に基づいて、発呼側の通信アダプタに通信可能状態にある場合にその通信可能状態情報を送信することを特徴とする。
この発明に係るインターネット通信方法は、インターネットを用いてデータを通信するインターネット通信方法において、
発呼側の通信アダプタから発呼側のセッション管理サーバに着呼側の通信アダプタに対するセッションの確立要求を送信し、
発呼側のセッション管理サーバから着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ、発呼側の通信アダプタから送信されたセッションの確立要求を送信し、
発呼側の通信アダプタから着呼側の通信アダプタに対してセッションの確立要求があったことを着呼側のセッション管理サーバに記憶し、
着呼側の通信アダプタが通信可能状態にある場合に、着呼側の通信アダプタから着呼側のセッション管理サーバに通信可能状態にあることを知らせ、
着呼側の通信アダプタから通信可能状態にあることを知らされた場合に、かつ、通信可能状態にある着呼側の通信アダプタに対してセッションの確立要求があった場合に、着呼側のセッション管理サーバが、インターネットを用いた発呼側のセッション管理サーバと着呼側の通信アダプタとのセッションの確立を許可し、
発呼側のセッション管理サーバが、セッションの確立を許可された場合に、発呼側の通信アダプタに、インターネットを用いた発呼側のセッション管理サーバと着呼側の通信アダプタとのセッションの確立を許可されたことを知らせることを特徴とする。
この発明に係る発呼側の通信アダプタと着呼側の通信アダプタとから接続されるセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを発呼側の通信アダプタへ返信する発呼側のセッション管理部と、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、記憶したセッションの確立要求を着呼側の通信アダプタに検索させ、着呼側の通信アダプタから通信可能状態が通知された場合に、インターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可する着呼側のセッション管理部とを備えたことを特徴とする。
この発明に係る発呼側の通信アダプタと着呼側の通信アダプタとから接続されるセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求を受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ、着呼側の通信アダプタのアダプタＩＤを含むそのセッション確立要求メッセージを転送し、通信可能状態であるかどうかの情報を発呼側の通信アダプタへ返信する発呼側のセッション管理部と、発呼側のセッション管理サーバから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、記憶したセッションの確立要求を着呼側のセッション管理サーバに検索させ、着呼側の通信アダプタの通信可能状態が判断された場合に、インターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可する着呼側のセッション管理部とを備えたことを特徴とする。
この発明に係るセッション管理サーバは、発呼側の通信アダプタと着呼側の通信アダプタとから接続されるセッション管理サーバであって、
発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求を受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ、発呼側の通信アダプタから受信した着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求を送信する発呼側のセッション管理部と、
発呼側のセッション管理サーバから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、着呼側の通信アダプタから通信可能状態が通知された場合に、記憶したセッションの確立要求を検索し、インターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可する着呼側のセッション管理部とを備えたことを特徴とする。
この発明に係る発呼側のセッション管理サーバと着呼側のセッション管理サーバとに接続される通信アダプタは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、発呼側のセッション管理サーバから着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを受信し、受信したサーバＩＤで識別される着呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、セッションの確立要求を送信する発呼側の通信アダプタ部と、着呼側のセッション管理サーバにセッションの確立要求が記憶されているかを自己のアダプタＩＤにより検索し、着呼側のセッション管理サーバにセッションの確立要求が記憶されている場合に、かつ、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信する着呼側の通信アダプタ部とを備えたことを特徴とする。
この発明に係る発呼側のセッション管理サーバと着呼側のセッション管理サーバとに接続される通信アダプタは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを含むセッションの確立要求を送信し、発呼側のセッション管理サーバは、その着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求メッセージを着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ転送し、発呼側のセッション管理サーバから着呼側の通信アダプタを管理している着呼側のセッション管理サーバからの着呼側の通信アダプタが通信可能状態にあるかどうかの情報を受信する発呼側の通信アダプタ部と、あらかじめ、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信しておき、着呼側のセッション管理サーバによりセッションの確立要求が記憶されているかを自己のアダプタＩＤにより検索された結果、着呼側の通信アダプタにセッションの確立要求があったという情報を受信する着呼側の通信アダプタ部とを備えたことを特徴とする。
この発明に係る発呼側の通信アダプタと着呼側の通信アダプタとの間でインターネットを用いてデータ通信をするインターネット通信システムは、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）を用いてインターネットを介して発呼側の通信アダプタとデータ通信する発呼側の通信中継サーバと、ＨＴＴＰを用いてインターネットを介して着呼側の通信アダプタとデータを通信し、かつ、ＨＴＴＰ以外のプロトコルを用いて発呼側の通信中継サーバとデータ通信する着呼側の通信中継サーバとを備えたことを特徴とする。
また、上記ＨＴＴＰ以外のプロトコルは、ユーザデータグラムプロトコル（ＵＤＰ）であることを特徴とする。
また、上記ＨＴＴＰ以外のプロトコルは、リアルタイムトランスポートプロトコル（ＲＴＰ）であることを特徴とする。
また、上記ＨＴＴＰ以外のプロトコルは、トランスミッションコントロールプロトコル（ＴＣＰ）上のアプリケーション用に作られたプロトコルであることを特徴とする。
また、上記ＨＴＴＰ以外のプロトコルは、シンプルコントロールトランスミッションプロトコル（ＳＣＴＰ）上のアプリケーション用に作られたプロトコルであることを特徴とする。
また、上記発呼側の通信中継サーバと着呼側の通信中継サーバとは、インターネットサービスプロバイダ（ＩＳＰ）の専用ネットワークで接続されることを特徴とする。
また、上記発呼側の通信中継サーバと着呼側の通信中継サーバとは、一般のインターネットのネットワークで接続されることを特徴とする。
この発明に係る発呼側の通信アダプタと着呼側の通信アダプタとの間でインターネットを用いてデータ通信するインターネット通信方法は、
インターネットを介して、発呼側の通信アダプタと発呼側の通信中継サーバとがハイパーテキストトランスファプロトコル（ＨＴＴＰ）を用いてデータを通信し、発呼側の通信中継サーバと着呼側の通信中継サーバとがＨＴＴＰ以外のプロトコルを用いてデータ通信し、インターネットを介して、着呼側の通信中継サーバと着呼側の通信アダプタとがＨＴＴＰを用いてデータ通信することを特徴とする。
この発明に係る通信アダプタとサーバ装置との間のデータ通信を中継する通信中継サーバは、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）を用いてインターネットを介して通信アダプタとデータを通信するＨＴＴＰ通信部と、ユーザデータグラムプロトコル（ＵＤＰ）を用いてサーバ装置とデータ通信するＵＤＰ通信部とを備えたことを特徴とする。
この発明に係る発呼側の通信アダプタと着呼側の通信アダプタとから接続されるセッション管理サーバで動作するプログラムは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを発呼側の通信アダプタへ返信する発呼側のセッション管理処理と、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、記憶したセッションの確立要求を着呼側の通信アダプタに検索させ、着呼側の通信アダプタから通信可能状態が通知された場合に、インターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可する着呼側のセッション管理処理とをコンピュータに実行させることを特徴とする。
この発明に係る発呼側の通信アダプタと着呼側の通信アダプタとから接続されるセッション管理サーバで動作するプログラムは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを含むセッションの確立要求を受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバへそのセッションの確立要求を転送し、着呼側のセッション管理サーバから着呼側の通信アダプタが通信可能状態であるかどうかの情報を受信し、その情報を発呼側の通信アダプタへ返信する発呼側のセッション管理処理と、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを含むセッションの確立要求を受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、記憶したセッションの確立要求を着呼側のセッション管理サーバにて検索を行い、着呼側の通信アダプタの通信可能状態が判断された場合に、インターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可し、着呼側の通信アダプタにセッションの確立要求があったという情報を着呼側の通信アダプタへ送信する着呼側のセッション管理処理とをコンピュータに実行させることを特徴とする。
この発明に係るプログラムは、発呼側の通信アダプタと着呼側の通信アダプタとから接続されるセッション管理サーバで動作するプログラムであって、
発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを含むセッションの確立要求を受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ発呼側の通信アダプタから受信したセッションの確立要求を送信する発呼側のセッション管理処理と、
発呼側のセッション管理サーバから着呼側の通信アダプタのアダプタＩＤを含むセッションの確立要求を受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、着呼側の通信アダプタの通信可能状態が通知された場合に、記憶したセッションの確立要求を検索して、インターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可し、着呼側の通信アダプタにセッションの確立要求があったことを通知する着呼側のセッション管理処理と
をコンピュータに実行させることを特徴とする。
この発明に係る発呼側のセッション管理サーバと着呼側のセッション管理サーバとに接続される通信アダプタで動作するプログラムは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、発呼側のセッション管理サーバから着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを受信し、受信したサーバＩＤで識別される着呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、セッションの確立要求を送信する発呼側の通信アダプタ処理と、着呼側のセッション管理サーバにセッションの確立要求が記憶されているかを自己のアダプタＩＤにより検索し、着呼側のセッション管理サーバにセッションの確立要求が記憶されている場合に、かつ、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信する着呼側の通信アダプタ処理とをコンピュータに実行させることを特徴とする。
この発明に係る発呼側のセッション管理サーバと着呼側のセッション管理サーバとに接続される通信アダプタで動作するプログラムは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを含むセッションの確立要求を送信し、発呼側のセッション管理サーバから着呼側の通信アダプタを管理している着呼側のセッション管理サーバを経由して着呼側の通信アダプタが通信可能状態であるかどうかの情報を受信する発呼側の通信アダプタ処理と、着呼側のセッション管理サーバに、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信し、発呼側の通信アダプタからのセッションの確立要求があったという情報を受信する着呼側の通信アダプタ処理とをコンピュータに実行させることを特徴とする。
この発明に係るプログラムは、発呼側のセッション管理サーバと着呼側のセッション管理サーバとに接続される通信アダプタで動作するプログラムであって、
発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを含むセッションの確立要求を送信する発呼側の通信アダプタ処理と、
着呼側のセッション管理サーバに、自己が通信可能状態にある場合に、通信可能状態にあることを送信し、着呼側のセッション管理サーバからセッションの確立要求があったことを受信する着呼側の通信アダプタ処理と
をコンピュータに実行させることを特徴とする。
この発明に係る通信アダプタとサーバ装置との間のデータ通信を中継する通信中継サーバで動作するプログラムは、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）を用いてインターネットを介して通信アダプタとデータを通信するＨＴＴＰ通信処理と、ユーザデータグラムプロトコル（ＵＤＰ）を用いてサーバ装置とデータ通信するＵＤＰ通信処理とをコンピュータに実行させることを特徴とする。
この発明に係る通信アダプタは、発呼を行う時点で、着呼側のセッション管理サーバについて、着呼側の通信アダプタが他の端末と通信状態にあるため、通信不可能状態となっているとき、その状態を示す情報を発呼側のセッション管理サーバを経由して、受信した場合に、通信アダプタ側に接続されている通信装置に対して、他端末と通信中を示す情報を送信することを特徴とする。
この発明に係る通信アダプタは、発呼側のセッション管理サーバと着呼側のセッション管理サーバとに接続されるとともに、少なくとも情報を出力する通信装置を接続する発呼側の通信アダプタであって、
上記着呼側のセッション管理サーバから発呼側のセッション管理サーバを経由して、着呼側の通信アダプタが既に通信状態にあるために、通信不能状態になっていることを受信すると、上記通信装置から着呼側の通信アダプタが既に通信状態にあるために通信不能状態になっていることを出力させることを特徴とする。
また、上記の他の端末と通信状態に入るという情報を着呼側の通信アダプタが、着呼側のセッション管理サーバに、通信開始時点に送信し、他の端末と通信状態を終了したという情報を着呼側の通信アダプタが、着呼側のセッション管理サーバに、通信終了時点に送信することを特徴とする。
この発明に係る通信アダプタは、発呼側のセッション管理サーバと着呼側のセッション管理サーバとに接続される通信アダプタであって、
通信を開始する場合には、着呼側のセッション管理サーバに通信を開始することを送信し、通信を終了する場合には、着呼側のセッション管理サーバに通信を終了することを送信することを特徴とする。
また、上記の他の端末との通信状態としては、本発明で示される呼制御方式での通信を含め、通信アダプタに装備された公衆回線経由での通信や、ＩＰネットワーク経由でのＨ．３２３方式やＳＩＰ方式等の他の呼制御方式での通信の場合があり、どの形態での通信を行っているかを示す情報を、通信アダプタがセッション管理サーバへ送信し、セッション管理サーバは、その情報を保持して、発呼側のセッション管理サーバや通信アダプタがどの形態での通信を行っているかを認識できることを特徴とする。
また、上記通信アダプタは、所定の呼制御方式によって通信を開始し、上記着呼側のセッション管理サーバに通信を開始することを送信する場合に、上記所定の呼制御方式を識別する情報も含めて送信することを特徴とする。
また、上記の他の端末との通信状態に加えて、その通信アダプタに接続された電話機の操作状況を示す情報を、通信アダプタがセッション管理サーバへ送信し、そのセッション管理サーバは、通信を行う相手側のセッション管理サーバへ、その電話機の操作状況を示す情報を転送し、さらに、その通信を行う相手側の通信アダプタへ転送することで、通信相手の電話機の操作状況を認知できることを特徴とする。
また、上記発呼側の通信アダプタは、少なくとも所定の操作を行うことができる通信装置を接続して、上記通信装置から所定の操作を行ったことを示す情報を入力し、上記発呼側のセッション管理サーバに、入力した所定の操作を行ったことを示す情報を送信し、
上記発呼側のセッション管理サーバは、受信した所定の操作を行ったことを示す情報を、上記着呼側のセッション管理サーバに送信し、
上記着呼側のセッション管理サーバは、受信した所定の操作を行ったことを示す情報を、上記着呼側の通信アダプタに送信することを特徴とする。
この発明に係る通信アダプタは、接続されたネットワーク環境によるＩＰアドレス取得形態に応じて、その通信アダプタの接続タイプを設定し、セッションの確立要求時に、その通信アダプタの接続タイプを発呼側あるいは着呼側のセッション管理サーバに送信し、セッション管理サーバは、その接続タイプに基づいて、サーバ装置あるいは、他の通信アダプタとの間のデータ通信として、ＨＴＴＰあるいはＵＤＰのいずれかを選択することを特徴とする。
また、上記発呼側の通信アダプタと着呼側の通信アダプタとはそれぞれ、所定のネットワーク環境に設置されて、上記所定のネットワーク環境に従うＩＰ（インターネット プロトコル）アドレスを割り当てられるとともに、上記ＩＰアドレスの割り当て形態に応じて決定される通信アダプタの接続タイプを記憶し、
上記発呼側の通信アダプタは、発呼側のセッション管理サーバに、上記発呼側の通信アダプタの接続タイプを送信し、
上記着呼側の通信アダプタは、着呼側のセッション管理サーバに、上記着呼側の通信アダプタの接続タイプを送信し、
上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから送信された接続タイプに基づいて、上記着呼側の通信アダプタとの間で、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）とユーザデータグラムプロトコル（ＵＤＰ）とのいずれか一方の通信プロトコルを用いてデータを通信することを決定して、上記着呼側の通信アダプタに決定した通信プロトコルを通知する情報を送信し、
上記発呼側のセッション管理サーバは、上記発呼側の通信アダプタから送信された接続タイプに基づいて、上記発呼側の通信アダプタとの間で、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）とユーザデータグラムプロトコル（ＵＤＰ）とのいずれか一方の通信プロトコルを用いてデータを通信することを決定して、上記発呼側の通信アダプタに決定した通信プロトコルを通知する情報を送信し、
上記発呼側の通信アダプタは、上記発呼側のセッション管理サーバから送信された上記通信プロトコルを通知する情報に従い、データを通信し、
上記着呼側の通信アダプタは、上記着呼側セッション管理サーバから送信された上記通信プロトコルを通知する情報に従い、データを通信することを特徴とする。
この発明に係る通信アダプタの接続タイプは、ＩＳＰ等のその通信アダプタが所属管理されるドメインにおいて与えれるＩＰアドレスの形態により、以下の５つのタイプを含むことを特徴とする。
（１）グローバルＩＰアドレスを固定的に割り当てられている。
（２）プライベートＩＰアドレスを固定的に割り当てられている。
（３）グローバルＩＰアドレスをＤＨＣＰにより動的に割り当てられる。
（４）プライベートＩＰアドレスをＤＨＣＰにより動的に割り当てられる。
（５）上記（１）〜（４）のいずれかであるが、その通信アダプタと、そのＩＰアドレスを与えられるネットワーク接続点の間に、ネットワークアドレス変換（ＮＡＴ機能）をもつルータ等を設置することで、さらに通信アダプタが局所的なローカルＩＰアドレスを割り当てられる。
また、上記発呼側の通信アダプタが上記所定のネットワーク環境に従い割り当てられるＩＰアドレスと上記着呼側通信アダプタが上記所定のネットワーク環境に従い割り当てられるＩＰアドレスとはそれぞれ、グローバルＩＰ（インターネットプロトコル）アドレスを固定的に割り当てられることと、プライベートＩＰアドレスを固定的に割り当てられることと、グローバルＩＰアドレスをＤｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＤＨＣＰ）により動的に割り当てられることと、プライベートＩＰアドレスをＤＨＣＰにより動的に割り当てられることと、ローカルＩＰアドレスを割り当てられることの少なくともいずれかによりＩＰアドレスを割り当てられることを特徴とする。
この発明に係る着呼側の通信アダプタは、発呼側の通信アダプタからのセッションの確立要求があったという情報を受信するために、ＨＴＴＰのＧＥＴメソッドを着呼側のセッション管理サーバに発行し、そのステータス応答の内容情報により、発呼側の通信アダプタからのセッションの確立要求があったという情報を受信できることを特徴とする。
また、上記着呼側の通信アダプタは、着呼側のセッション管理サーバに発呼側の通信アダプタからのセッションの確立要求が記憶されていることを確認するために、着呼側のセッション管理サーバにハイパーテキストトランスファープロトコル（ＨＴＴＰ）のＧＥＴメソッドを発行し、
上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから発行されたＧＥＴメソッドを受信すると、上記ＧＥＴメソッドを発行した着呼側の通信アダプタに対するセッション確立要求が記憶されているか検索し、検索した結果を上記ＧＥＴメソッドに対するＧＥＴ応答に含めて、上記着呼側の通信アダプタに送信することを特徴とする。
この発明に係る発呼側の通信アダプタは、着呼側の通信アダプタからの相手が電話に出るため受話器をオフフックしたとか、受話器をオンフックして通話を切断したとかなどのイベント情報を受信するために、ＨＴＴＰのＧＥＴメソッドを発呼側のセッション管理サーバに発行し、そのステータス応答の内容情報により、着呼側の通信アダプタからの各種イベントが発生したという情報を受信できることを特徴とする。
また、上記着呼側の通信アダプタは、所定の操作を行うことができる通信装置を接続し、上記接続した通信装置の所定の操作の内容を示す情報を入力して、発呼側のセッション管理サーバに送信し、
上記発呼側のセッション管理サーバは、上記着呼側の通信アダプタから送信された上記着呼側の通信アダプタの接続する通信装置の所定の操作の内容を示す情報を記憶し、
上記発呼側の通信アダプタは、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを用いて、上記発呼側のセッション管理サーバに記憶された上記着呼側の通信アダプタの接続する通信装置の所定の操作の内容を示す情報を取得することを特徴とする。
また、上記ＨＴＴＰのＧＥＴメソッドを着呼側の通信アダプタは、一定周期ごとに着呼側のセッション管理サーバに発行し、通話処理がなされていない間は、発呼側の通信アダプタからのセッションの確立要求がなかったという情報を着呼側のセッション管理サーバから受信し、通話処理開始時において、発呼側の通信アダプタからのセッションの確立要求があった時点のみ、発呼側の通信アダプタからのセッションの確立要求があったという情報を着呼側のセッション管理サーバから受信できることを特徴とする。
また、上記着呼側の通信アダプタは、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを一定周期ごとに着呼側のセッション管理サーバに送信し、
上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから上記ＧＥＴメソッドを受信すると、上記発呼側の通信アダプタからセッションの確立要求がなされているが、上記発呼側と着呼側の通信アダプタとの間で通信が開始されていない場合には、上記着呼側の通信アダプタに対して、上記発呼側の通信アダプタからのセッションの確立要求がなかったという情報を送信し、上記発呼側の通信アダプタからセッションの確立要求がなされて、上記発呼側と着呼側の通信アダプタとの間で通信が開始されている場合には、上記着呼側の通信アダプタに対して、上記発呼側の通信アダプタからのセッションの確立要求があったという情報を送信することを特徴とする。
また、上記ＨＴＴＰのＧＥＴメソッドを着呼側の通信アダプタは、初期化時において、一度着呼側のセッション管理サーバに発行し、通話処理開始時において、発呼側の通信アダプタからのセッションの確立要求があった時点で、着呼側のセッション管理サーバから着呼側の通信アダプタへそのステータス応答の内容情報が送信されることで、発呼側の通信アダプタからのセッションの確立要求があったという情報を受信できることを特徴とする。
また、上記着呼側の通信アダプタは、電源投入時や通話処理が完了した直後の通話開始の準備がなされるときに、上記着呼側のセッション管理サーバに、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを送信し、
上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから送信されたＧＥＴメソッドを保持して、上記発呼側の通信アダプタからのセッションの確立要求があった場合に、上記発呼側の通信アダプタからのセッションの確立要求があったことを上記保持していたＧＥＴメソッドに対する回答として上記着呼側の通信アダプタへ送信することを特徴とする。
また、上記ＨＴＴＰのＧＥＴメソッドを着呼側の通信アダプタは、初期化時において、一度着呼側のセッション管理サーバに発行し、ボディ情報を除いたヘッダ情報のみをすぐに応答として、着呼側のセッション管理サーバから着呼側の通信アダプタに対して送信し、通話処理がなされていない間は、一定周期ごとに、そのボディ情報の一部として、ＴＣＰの接続保持のためのＫｅｅｐ−Ａｌｉｖｅ情報（連続して信号を発行しつづけることで生存を確認する情報）を着呼側のセッション管理サーバから着呼側の通信アダプタに対して送信しつづけ、通話処理開始時において、発呼側の通信アダプタからのセッションの確立要求があった時点で、着呼側のセッション管理サーバから着呼側の通信アダプタへそのステータス応答の内容情報が送信されることで、発呼側の通信アダプタからのセッションの確立要求があったという情報を受信できることを特徴とする。
また、上記着呼側の通信アダプタは、電源投入時や通話処理が完了した直後の通話開始の準備がなされるときに、上記着呼側のセッション管理サーバに、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを送信し、
上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから上記ＧＥＴメソッドを送信された場合に、上記発呼側の通信アダプタからのセッションの確立要求がなされていない場合は、上記着呼側の通信アダプタに、上記着呼側の通信アダプタと上記着呼側のセッション管理サーバとの間の回線の接続を維持するための生存確認情報を送信し続け、上記発呼側の通信アダプタからのセッションの確立要求がなされた場合は、上記着呼側の通信アダプタに、上記発呼側の通信アダプタからのセッションの確立要求があったことを送信することを特徴とする。
また、上記ＨＴＴＰのＧＥＴメソッドを着呼側の通信アダプタは、ＴＣＰの接続保持のためのＫｅｅｐ−Ａｌｉｖｅ情報を着呼側のセッション管理サーバから着呼側の通信アダプタに対して一定周期ごとに送信し続ける処理中において、そのＫｅｅｐ−Ａｌｉｖｅ情報が一定周期を過ぎ、ある一定のタイムアウト値を過ぎても通信アダプタに到着しない場合、通信アダプタは、新たなＴＣＰの接続を行い、セッションの確立要求があったという情報を受信するために、ＨＴＴＰのＧＥＴメソッドを着呼側のセッション管理サーバにあらためて再発行し、発呼側の通信アダプタからのセッションの確立要求があったという情報を受信できる状態へ準備をやり直すことを特徴とする。
また、上記着呼側の通信アダプタは、上記着呼側のセッション管理サーバから送信される上記生存確認情報が予め定めた一定期間を過ぎても送信されない場合は、上記着呼側のセッション管理サーバに対して再度ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを送信することを特徴とする。
また、上記ＨＴＴＰのＧＥＴメソッドを着呼側の通信アダプタは、ＴＣＰの接続において、タイムアウト状態などにより、現状のＴＣＰ接続を切断して、新たなＴＣＰの接続を行い、セッションの確立要求があったという情報を受信するために、ＨＴＴＰのＧＥＴメソッドを着呼側のセッション管理サーバにあらためて再発行し、発呼側の通信アダプタからのセッションの確立要求があったという情報を受信できる状態へ準備をやり直す場合に、ちょうどセッション管理サーバから発呼側の通信アダプタからのセッションの確立要求があったという情報が送信されてきたとき、着呼側の通信アダプタは、その情報の受信を失敗する可能性を考慮し、再発行のＨＴＴＰのＧＥＴメソッドに再発行であることを示す情報を付加し、そのＧＥＴメソッドを受信したセッション管理サーバは、上記のセッションの確立要求があったという情報を再度、着呼側の通信アダプタへ送信することを特徴とする。
また、上記着呼側の通信アダプタは、上記着呼側のセッション管理サーバに対して再度ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを送信する場合に、再度の送信であることを示す情報を含めて送信することを特徴とする。
この発明に係る通信アダプタとセッション管理サーバのサーバＩＤを通信アダプタに通知する指定通知サーバは、通信アダプタから、一定周期ごとに、あるいは、電話をかける操作時ごとに、指定通知サーバに、通信アダプタの稼動状況を示す情報を送信し、その情報に基づいて、指定通知サーバが通信アダプタの動作状況が正常であるかどうか確認し、さらに、指定通知サーバがセッション管理サーバや通話中継サーバを含めたインターネット電話システムの動作状況を把握できる情報を上記の送信応答として送り返すことを特徴とする。
また、上記発呼側の通信アダプタは、発呼側の通信アダプタの稼働状況を通知する情報を、上記指定通知サーバに送信し、
上記指定通知サーバは、上記発呼側の通信アダプタより送信された稼働状況を通知する情報に基づいて、上記発呼側の通信アダプタが正常であるか否かを確認して、確認した結果とともに、上記指定通知サーバ自身の稼働状況を、上記発呼側の通信アダプタより送信された稼働状況の通知に対する応答として、上記発呼側の通信アダプタに送信することを特徴とする。
また、上記のインターネット電話システムの動作状況として、指定通知サーバ、あるいは、セッション管理サーバが保守や増設等のために、新しい指定通知サーバ、あるいは、セッション管理サーバに変更する指示情報を上記の通信アダプタへの送信応答へ含めることで、通信アダプタがアクセスを行う指定通知サーバ、あるいは、セッション管理サーバを変更することができることを特徴とする。
また、上記のインターネット電話システムの動作状況として、指定通知サーバ、あるいは、セッション管理サーバを各１台だけでなく、故障等の何らかの障害でアクセス不可能なとき、代替でアクセス可能な別の各サーバのＩＰアドレスについての情報を上記の通信アダプタへの送信応答へ含めることで、通信アダプタが、１台の指定通知サーバ、あるいは、セッション管理サーバが故障してアクセスできなくても、継続して代替サーバへのアクセスで処理を継続できることを特徴とする。
また、上記指定通知サーバは、複数のサーバ装置により構成され、上記複数のサーバ装置の１つをプライマリサーバとし、他のサーバ装置をセカンダリサーバとし、上記プライマリサーバを指定通知サーバとして稼働させ、上記プライマリサーバの稼働状況が異常になった場合に、上記セカンダリサーバを上記指定通知サーバとして稼働させるように切り替えて、上記発呼側の通信アダプタに、上記セカンダリサーバを上記指定通知サーバとして稼働させたことを通知することを特徴とする。
また、上記発呼側のセッション管理サーバは、複数のサーバ装置により構成され、上記複数のサーバ装置の１つをプライマリサーバとし、他のサーバ装置をセカンダリサーバとし、上記プライマリサーバを発呼側セッション管理サーバとして稼働させ、上記プライマリサーバの稼働状況が異常になった場合に、上記セカンダリサーバを上記発呼側のセッション管理サーバとして稼働させるように切り替えて、上記発呼側の通信アダプタに、上記セカンダリサーバを上記発呼側のセッション管理サーバとして稼働させたことを通知することを特徴とする。
また、上記着呼側のセッション管理サーバは、複数のサーバ装置により構成され、上記複数のサーバ装置の１つをプライマリサーバとし、他のサーバ装置をセカンダリサーバとし、上記プライマリサーバを着呼側セッション管理サーバとして稼働させ、上記プライマリサーバの稼働状況が異常になった場合に、上記セカンダリサーバを上記着呼側のセッション管理サーバとして稼働させるように切り替えて、上記着呼側の通信アダプタに、上記セカンダリサーバを上記着呼側のセッション管理サーバとして稼働させたことを通知することを特徴とする。
また、通信アダプタの利用者のインターネット電話システムの利用料金情報に基づいて、上記指定通知サーバへの稼動状況を示す情報を送信し、その応答の情報を受信するとき、その応答情報に利用料金を支払っていない場合にそれを指定する情報を含めておき、その応答情報を通信アダプタが受信した時点で、通信アダプタはインターネット電話システムの通信機能を動作不能に設定することを特徴とする。
また、上記インターネット通信システムは、さらに、発呼側の通信アダプタ毎にシステムの利用料を管理する顧客管理データベースを備え、
上記指定通知サーバは、上記通信アダプタを管理するセッション管理サーバのサーバＩＤを発呼側の通信アダプタに送信する場合に、上記発呼側の通信アダプタの利用料を上記顧客管理データベースより取得して、取得した利用料と上記サーバＩＤとを上記発呼側の通信アダプタに送信し、
上記発呼側の通信アダプタは、上記指定通知サーバより受信した利用料に基づいて、自身の通信機能を動作不能に設定するか否かを決定することを特徴とする。
また、上記のようにインターネット電話システムの通信機能が動作不能となった通信アダプタの利用者が利用料金を支払うようになったという情報も、上記指定通知サーバからの応答情報に含めておき、その利用料金を支払うようになった情報を通信アダプタが受信した時点で、通信アダプタは、インターネット電話システムの通信機能を動作可能に設定することを特徴とする。
また、上記発呼側の通信アダプタは、自身の通信機能が動作不能に設定されている場合、上記指定通知サーバより受信した利用料に基づいて、動作可能に設定するか否かを決定することを特徴とする。
また、通信アダプタの内蔵ソフトウェアのバージョン情報に基づいて、上記指定通知サーバへの稼動状況を示す情報を送信し、その応答の情報を受信するとき、その応答情報により新しいバージョンの内蔵ソフトウェアをインターネット電話システムの管理者側より入手することができるという情報を含めておき、その応答情報を通信アダプタが受信した時点で、通信アダプタは通信アダプタの新しい内蔵ソフトウェアへの所定の更新処理の起動を行えるように設定することを特徴とする。
また、上記発呼側の通信アダプタは、通信アダプタの機能を実行する、バージョン情報を有するソフトウェアを内蔵して、上記発呼側の通信アダプタの稼働状況を通知する情報とともに、上記ソフトウェアのバージョン情報を上記指定通知サーバに送信し、
上記指定通知サーバは、上記発呼側の通信アダプタより送信されたバージョン情報に基づいて、上記発呼側の通信アダプタが内蔵するソフトウェアを別のバージョンのソフトウェアに変更するか否かを決定して、決定した結果を上記発呼側の通信アダプタに送信することを特徴とする。
また、上記の通信アダプタの新しい内蔵ソフトウェアへの所定の更新処理として、上記指定通知サーバからの情報応答にて通知される指定ＵＲＬアドレスのＷｅｂサーバから通信アダプタがダウンロードを行い、更新処理をして再起動を行うことを特徴とする。
また、上記指定通知サーバは、上記発呼側の通信アダプタが内蔵するソフトウェアを管理するＷｅｂサーバのアドレスを管理して、上記発呼側の通信アダプタが内蔵するソフトウェアを別のバージョンのソフトウェアに変更することを決定した場合に、上記別のバージョンのソフトウェアのＷｅｂサーバのアドレスを上記発呼側の通信アダプタに送信することを特徴とする。
この発明に係る通信アダプタは、セッション管理サーバが管理する通信中継サーバによる中継処理が中継可能な通信容量を越えており、通信中継サーバ経由の通信が不可能な場合に、通信中継サーバ経由の通信を行おうとしたとき、セッション管理サーバが通信中継サーバによる中継が飽和しているという情報を発呼側の通信アダプタの発呼時に送信し、それを受信することで、通信アダプタに接続された通信装置を利用している者に、通信中継サーバによる中継が飽和していて、中継による通信ができないことを音声再生装置や表示装置などにより知らせることができることを特徴とする。
また、上記セッション管理サーバは、発呼側の通信中継サーバによる通信の中継数を管理して、上記発呼側の通信アダプタからセッションの確立要求を受信した場合に、通信の中継数が予め設定された通信の中継数を超える場合に、上記発呼側の通信アダプタに通信中継サーバによる中継が飽和しているという情報を送信し、
上記発呼側の通信アダプタは、少なくとも情報を出力する機能を有する通信装置を接続して、上記セッション管理サーバから発呼側の通信中継サーバによる中継が飽和しているという情報を受信すると、発呼側の通信中継サーバによる中継が飽和していて、発呼側の通信中継サーバによる通信ができないことを示す情報を、上記通信装置から出力させることを特徴とする。
また、上記セッション管理サーバは、着呼側の通信中継サーバによる通信の中継数を管理して、上記発呼側の通信アダプタからセッションの確立要求を受信した場合に、通信の中継数が予め設定された通信の中継数を超える場合に、上記発呼側の通信アダプタに通信中継サーバによる中継が飽和しているという情報を送信し、
上記発呼側の通信アダプタは、少なくとも情報を出力する機能を有する通信装置を接続して、上記セッション管理サーバから着呼側の通信中継サーバによる中継が飽和しているという情報を受信すると、着呼側の通信中継サーバによる中継が飽和していて、着呼側の通信中継サーバによる通信ができないことを示す情報を、上記通信装置から出力させることを特徴とする。
この発明に係る通信アダプタが、ＩＰネットワーク以外の公衆回線等の他の通信回線を備えている場合に、通信中継サーバによる中継容量が飽和している場合や、ネットワーク状況の原因によりセッション管理サーバや通信中継サーバを利用できない場合に、他の通信回線経由での通信処理を行うことができることを特徴とする。
また、上記インターネット通信システムは、さらに、公衆回線網を備え、
上記発呼側の通信アダプタは、上記公衆回線網を接続して、上記セッション管理サーバから発呼側の通信中継サーバによる中継が飽和しているという情報を受信すると、上記公衆回線網を使用して上記着呼側の通信アダプタを発呼することを特徴とする。
また、上記インターネット通信システムは、さらに、公衆回線網を備え、
上記発呼側の通信アダプタは、上記公衆回線網を接続して、上記セッション管理サーバから着呼側の通信中継サーバによる中継が飽和しているという情報を受信すると、上記公衆回線網を使用して上記着呼側の通信アダプタを発呼することを特徴とする。
この発明に係る通信アダプタは、セッション管理サーバや通信中継サーバへのＴＣＰ等の接続処理において、ある一定のタイムアウト値を過ぎても接続処理ができない場合に、その接続処理を中断する取り消し処理を行い、接続処理が成功するまで、かつ、再接続処理が上限回数に達するまで、再度、接続処理を開始することを繰り返すことを特徴とする。
また、上記通信アダプタは、上記セッション管理サーバと通信を行う前に、上記セッション管理サーバにＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）による接続処理を要求して、要求を行った後、予め設定された所定のタイムアウト値を過ぎても上記セッション管理サーバから上記接続処理の要求に対する応答が無い場合に、その接続処理を取り消して、接続処理が成功するまでと、接続処理の要求回数が予め設定された上限回数になるまでとのいずれか一方になるまで、接続処理の要求を繰り返し行うことを特徴とする。
また、上記通信アダプタは、上記通信中継サーバと通信を行う前に、上記通信中継サーバにＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）による接続処理を要求して、要求を行った後、予め設定された所定のタイムアウト値を過ぎても上記通信中継サーバから上記接続処理の要求に対する応答が無い場合に、その接続処理を取り消して、接続処理が成功するまでと、接続処理の要求回数が予め設定された上限回数になるまでとのいずれか一方になるまで、接続処理の要求を繰り返し行うことを特徴とする。
また、上記の通信アダプタのセッション管理サーバや通信中継サーバへのＴＣＰ等の接続処理における接続処理タイムアウト値、及び、再接続処理の上限回数について、ＴＣＰ等の接続処理が失敗するたびに、タイムアウト値を長く、再接続処理の上限回数を増加させる変更を自動的に行い、ＴＣＰ等の接続処理が成功するたびに、タイムアウト値を短く、再接続処理の上限回数を減少させる変更を自動的に行うことを特徴とする。
また、上記通信アダプタは、上記ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）による接続処理の要求が失敗した場合に、上記タイムアウト値を長くすることと、上記上限回数を増加させることのいずれか一方の変更を行うとともに、上記ＴＣＰによる接続処理の要求が成功した場合に、上記タイムアウト値を短くすることと、上記上限回数を減少させることのいずれか一方の変更を行うことを特徴とする。
また、上記通信アダプタは、上記ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）による接続処理の要求が失敗した場合に、上記タイムアウト値を長くすることと、上記上限回数を増加させることのいずれか一方の変更を行うとともに、上記ＴＣＰによる接続処理の要求が成功した場合に、上記タイムアウト値を短くすることと、上記上限回数を減少させることのいずれか一方の変更を行うことを特徴とする。
この発明に係る通信アダプタは、セッション管理サーバや通信中継サーバへのＴＣＰ等の接続処理において、ある一定のタイムアウト値を過ぎても接続処理ができない場合に、あるいは、規定の上限回数まで繰り返し再接続処理を行っても接続処理ができない場合に、通信アダプタに接続された通信装置を利用している者に、ネットワーク状況の原因により中継による通信ができないことを音声再生装置や表示装置などにより知らせることができることを特徴とする。
また、上記通信アダプタは、少なくとも情報を出力する機能を有する通信装置を接続して、上記ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）による接続処理の要求が、上記所定のタイムアウト値を過ぎても接続処理ができない場合と、上記上限回数を過ぎても接続処理ができない場合とのいずれか一方である場合に、上記インターネットを使用して通信の中継が行えないことを示す情報を、上記通信装置から出力させることを特徴とする。
また、上記通信アダプタは、上記ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）による接続処理の要求が失敗した場合に、上記タイムアウト値を長くすることと、上記上限回数を増加させることのいずれか一方の変更を行うとともに、上記ＴＣＰによる接続処理の要求が成功した場合に、上記タイムアウト値を短くすることと、上記上限回数を減少させることのいずれか一方の変更を行うことを特徴とする。
この発明に係るセッション管理サーバや通信中継サーバは、定期的に、他のセッション管理サーバや通信中継サーバや通信アダプタとの間の一般のＩＰパケットの到着時間を測定し、ある一定値を越えるかどうかで、通信経路の状況を判断し、ネットワークが非常に混雑していると判断した時点で、通信アダプタが通信を開始する前に、通信アダプタに接続された通信装置を利用している者に、ネットワークが非常に混雑しており、通信品質が悪いことを音声再生装置や表示装置などにより知らせることができることを特徴とする。
また、上記セッション管理サーバは、上記セッション管理サーバが管理する上記通信アダプタと上記通信中継サーバとに、パケット情報を送信して、上記通信アダプタと上記通信中継サーバとから上記送信したパケット情報に対する応答情報を受信するまでの到着時間を測定して、通信経路の輻輳状況を判断して、判断した結果を上記通信アダプタに送信し、
上記通信アダプタは、少なくとも情報を出力する機能を有する通信装置を接続して、上記セッション管理サーバから送信された上記判断結果を上記通信装置から出力させることを特徴とする。
また、上記通信中継サーバは、上記通信アダプタと上記セッション管理サーバとに、パケット情報を送信して、上記通信アダプタと上記セッション管理サーバとから上記送信したパケット情報に対する応答情報を受信するまでの到着時間を測定して、通信経路の輻輳状況を判断して、判断した結果を上記通信アダプタに送信し、
上記通信アダプタは、少なくとも情報を出力する機能を有する通信装置を接続して、上記通信中継サーバから送信された上記判断結果を上記通信装置から出力させることを特徴とする。
この発明に係るセッション管理サーバや通信中継サーバは、通信アダプタが通信を行っているとき、定期的に、他のセッション管理サーバや通信中継サーバや通信アダプタとの間の一般のＩＰパケットの到着時間を測定し、ある一定値を越えるかどうかで、通信経路の状況を判断し、ネットワークが非常に混雑するようになり、ほとんど通信データの到着が滞りがちになった時点で、通信アダプタに接続された通信装置を利用している者に、ネットワークが非常に混雑するようになり、通信品質が実用に耐えられないぐらい悪化したことを音声再生装置や表示装置などにより知らせることができることを特徴とする。
この発明に係るセッション管理サーバは、発呼側の通信中継サーバと着呼側の通信中継サーバの２段階中継だけではなく、さらに、他の第３以降の通信中継サーバを前記サーバ両者の間にて通信中継を行うように、通信経路を設定して、発呼側と着呼側の通信アダプタの間で通信処理を行うことができることを特徴とする。
また、上記インターネット通信システムは、さらに、
上記通信中継サーバの他に、通信経路を迂回するための迂回用通信中継サーバを備え、
上記セッション管理サーバは、上記通信経路の輻輳状況を判断した結果に基づいて、上記通信中継サーバを介して上記発呼側の通信アダプタと上記着呼側の通信アダプタとの間の通信を中継する第１の通信経路を、上記迂回用通信中継サーバを介して上記発呼側の通信アダプタと上記着呼側の通信アダプタとの間の通信を中継する第２の通信経路に切り替えることを特徴とする。
また、上記の他の第３以降の通信中継サーバの選択について、ネットワークが混雑していると、上記のセッション管理サーバ等で得られた通信経路遅延の測定情報を元に、通信遅延が良好な経路上のものを選択し、他の第３以降の通信中継サーバを前記サーバ両者の間にて通信中継を行うように、通信経路を設定して、発呼側と着呼側の通信アダプタの間で通信処理を行うことができることを特徴とする。
また、上記迂回用通信中継サーバは、複数備えられ、
上記セッション管理サーバは、上記複数の迂回用通信中継サーバに対してパケット情報を送信して、上記迂回用の通信中継サーバから上記送信したパケット情報に対する応答情報を受信するまでの到着時間を測定して、それぞれの迂回用通信中継サーバを接続する通信経路の輻輳状況を判断して、輻輳状況の良好な通信経路の迂回用通信中継サーバを選択して、上記第１の通信経路を、選択した迂回用通信中継サーバを介して上記発呼側の通信アダプタと上記着呼側の通信アダプタとの間の通信を中継する第２の通信経路に切り替えることを特徴とする。
また、既に、発呼側と着呼側の通信アダプタ同士で、通信中継サーバ経由で通信を行っているときに、ネットワーク通信状況が悪化して、上記の他の第３以降の通信中継サーバを前記サーバ両者の間にて通信中継を行うように、ネットワーク通信状況の良好な通信経路に変更する場合に、通信アダプタに接続された通信装置を利用している者に、ネットワークが非常に混雑するようになり、通信品質が実用に耐えられないぐらい悪化したために、通信経路を変更する処理を行うことを音声再生装置や表示装置などにより知らせることができることを特徴とする。
また、上記セッション管理サーバは、上記第１の通信経路を上記第２の通信経路に切り替えることを、上記通信アダプタに送信し、
上記通信アダプタは、少なくとも情報を出力する機能を有する通信装置を接続して、上記セッション管理サーバから送信された上記第１の通信経路を上記第２の通信経路に切り替えること示す情報を、上記通信装置から出力させることを特徴とする。
この発明に係るセッション管理サーバは、企業、団体等の特定限定地区のＬＡＮ環境に設置された場合に、その地区内に設置された通信アダプタに接続された電話機から、その地区内でのみ利用可能な内線電話番号を設定しておき、各電話機から電話をかける際に、その内線電話番号が入力されると、セッション管理サーバへその内線電話番号情報が送信され、セッション管理サーバ内に装備された電話番号から通信アダプタのＩＰアドレスや識別子へ変換するテーブルにより、その内線電話番号に該当する通信アダプタへ電話呼出をすることができることを特徴とする。
また、上記インターネット通信システムは、特定のネットワークエリア内で使用可能な内線電話番号情報を用いて通信を行うＬＡＮ（ローカルエリアネットワーク）を備え、
上記発呼側の通信アダプタと上記発呼側のセッション管理サーバは、上記ＬＡＮに接続され、
上記発呼側の通信アダプタは、通話先の内線電話番号情報を入力して、入力した内線電話番号情報を上記発呼側のセッション管理サーバへ送信し、
上記発呼側のセッション管理サーバは、上記内線電話番号情報と上記着呼側の通信アダプタのアダプタＩＤとを対応させて管理する内線電話番号情報記憶部を備えて、上記発呼側の通信アダプタから送信された内線電話番号情報を用いて上記内線電話番号情報記憶部から上記内線電話番号情報に対応する着呼側の通信アダプタのアダプタＩＤを取得して、取得したアダプタＩＤで識別される着呼側のセッション管理サーバのサーバＩＤを上記発呼側の通信アダプタに返信することを特徴とする。
また、上記インターネット通信システムは、特定のネットワークエリア内で使用可能な内線電話番号情報を用いて通信を行うＬＡＮ（ローカルエリアネットワーク）を備え、
上記発呼側の通信アダプタと上記発呼側のセッション管理サーバは、上記ＬＡＮに接続され、
上記発呼側の通信アダプタは、通話先の内線電話番号情報を入力して、入力した内線電話番号情報を上記発呼側のセッション管理サーバへ送信し、
上記発呼側のセッション管理サーバは、上記内線電話番号情報と上記着呼側の通信アダプタのアダプタＩＤとを対応させて管理する内線電話番号情報記憶部を備えて、上記発呼側の通信アダプタから送信された内線電話番号情報を用いて上記内線電話番号情報記憶部から上記内線電話番号情報に対応する着呼側の通信アダプタのアダプタＩＤを取得して、取得したアダプタＩＤと取得したアダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤとを、着呼側のセッション管理サーバに送信し、着呼側の通信アダプタとのセッションの確立要求を送信することを特徴とする。
また、内線電話番号を電話機から入力すると、通信アダプタにあらかじめ設定されていた内線電話番号のプレフィックス番号を元に、内線電話番号であることを認識し、通信アダプタに内蔵された変換テーブルではなく、セッション管理サーバ内の変換テーブルを参照して呼制御を行うように判別処理を行うことを特徴とする。
この発明に係るセッション管理サーバは、企業、団体等の特定限定地区のＬＡＮ環境に設置された場合に、その地区外からＩＰ回線経由で電話呼出があった場合に、呼出先の通信アダプタが既に通話中であったとき、代替可能な他の通信アダプタをグループとして、登録しておく記憶部を備え、その中に登録されている代替可能な他の通信アダプタへ電話呼出を自動的に転送する処理を行うことを特徴とする。
また、上記インターネット通信システムは、上記着呼側の通信アダプタを複数備えて、
上記発呼側のセッション管理サーバは、上記複数の着呼側の通信アダプタをグループ化して管理するグループＩＤと、上記内線番号情報と上記着呼側の通信アダプタのアダプタＩＤとを対応させて上記内線番号情報記憶部に記憶して、上記発呼側の通信アダプタからセッションの確立要求をされた着呼側の通信アダプタが通話中である場合に、通話中である着呼側の通信アダプタと同じグループＩＤの着呼側の通信アダプタのアダプタＩＤを上記内線番号情報記憶部より取得して、取得アダプタＩＤと取得アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤとを、上記発呼側の通信アダプタに返信し、
上記発呼側の通信アダプタは、発呼側のセッション管理サーバから着呼側の通信アダプタのアダプタＩＤと着呼側のセッション管理サーバのサーバＩＤとを受信し、受信したサーバＩＤで識別される着呼側のセッション管理サーバに受信したアダプタＩＤを送信し、着呼側の通信アダプタとのセッションとの確立要求を送信することを特徴とする。
また、上記インターネット通信システムは、上記着呼側の通信アダプタを複数備えて、
上記発呼側のセッション管理サーバは、上記複数の着呼側の通信アダプタをグループ化して管理するグループＩＤと、上記内線番号情報と上記着呼側の通信アダプタのアダプタＩＤとを対応させて上記内線番号情報記憶部に記憶して、上記発呼側の通信アダプタからセッションの確立要求をされた着呼側の通信アダプタが通話中である場合に、通話中である着呼側の通信アダプタと同じグループＩＤの着呼側の通信アダプタのアダプタＩＤを上記内線番号情報記憶部より取得して、取得したアダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ、取得したアダプタＩＤを送信し、着呼側の通信アダプタとのセッションの確立要求を送信することを特徴とする。
この発明に係るセッション管理サーバは、音声情報を送受信する通信中継サーバに対する通信アダプタのＨＴＴＰのＧＥＴメソッドについて、ＴＣＰの接続保持のためのＫｅｅｐ−Ａｌｉｖｅ情報を通信相手の通信アダプタから上記通信中継サーバ経由にて、その通信アダプタに対して一定周期ごとに送信し続ける処理中において、そのＫｅｅｐ−Ａｌｉｖｅ情報が一定周期を過ぎ、ある一定のタイムアウト値を過ぎても通信アダプタに到着しない場合、通信アダプタは、新たなＴＣＰの接続を行い、かつ、通信相手の通信アダプタに対して、セッション管理サーバを経由して、ＴＣＰの再接続の要求を行うことを特徴とする。
この発明に係る上記通信アダプタは、音声コーデック（音声符号化復号化装置或いはソフトウェア）の符号化、及び復号化を行う単位である音声フレームデータを通信アダプタが決定する指定時間内で１つ以上蓄積して１つのＩＰパケットとして構成し送信するものであり、連続した音声データが無音状態となる終端において、終端であることを示す音声フレームデータが生成された時点で、上記指定時間が経過していなくても、その終端であることを示す音声フレームデータをＩＰパケットに格納した直後に、そのＩＰパケットを送信することを特徴とする。
発明を実施するための最良の形態
以下に記載する実施の形態では、ＨＴＴＰによる音声データ配信を行う場合に問題となるファイアウォールに対処するため、発呼側と着呼側の中継を行うためのサーバを設置する。以下、このサーバを「通信中継サーバ」として記述する。
また、通信（通話）アダプタからの通信データ（音声データ）を通信中継サーバにて中継する場合は、複数の通信中継サーバを設置して、個々の通信中継サーバに負荷を分散する必要がある。そこで、通信（通話）アダプタと通信中継サーバとを管理する管理サーバを設置する。以下、この管理サーバを「セッション管理サーバ」として記述する。
また、セッション管理サーバを複数備え、各セッション管理サーバによって管理する通信アダプタを予め決めておく。通信アダプタから自身を管理するセッション管理サーバの問い合わせを受け付けて、管理するセッション管理サーバを通知する通知サーバを、以下、「指定通知サーバ」として記述する。
実施の形態１．
この実施の形態１では、インターネットを用いて通信データ、例えば音声データを発呼側から着呼側に送信するインターネット通信システムの一例を説明する。
図１は、実施の形態１のインターネット通信システムのシステム構成図であり、構成する各要素の関係を示している。
図１において、１０，２０は通信データ（音声データ）を送受信する通信装置である。１１０、１２０は、通信アダプタであり、通信装置１０，２０それぞれに屋内電話線によって接続されている。通信アダプタ１１０は、発呼側通信アダプタ部１１１と着呼側通信アダプタ部１１２とを備え、通信アダプタ１２０は、発呼側通信アダプタ部１２１と着呼側通信アダプタ部１２２とを備えている。通信アダプタ１１０，１２０とはそれぞれ、発呼側通信アダプタ部と着呼側通信アダプタ部とを備えているので、発呼側通信アダプタと着呼側通信アダプタのどちらにも使用できる。通信アダプタ１１０，１２０は、発呼側の通信アダプタ処理と着呼側の通信アダプタ処理とをコンピュータに実行させる通信アダプタ上で動作するプログラムを有している。
２１０、２２０は、セッション管理サーバであり、発呼側通信アダプタと着呼側通信アダプタと通信データ（例えば、音声データ）配信の中継を行う通信中継サーバとを管理し、発呼側通信アダプタからの通信要求（発呼メッセージ）に対して通信時に使用する通信中継サーバの指示を行う。また、着呼側通信アダプタからの通信問合せ（着呼メッセージ）に対して通信要求の有無を通知する。セッション管理サーバ２１０は、発呼側セッション管理部２１１と着呼側セッション管理部２１２とを備え、セッション管理サーバ２２０は、発呼側セッション管理部２２１と着呼側セッション管理部２２２とを備えているので、発呼側セッション管理サーバと着呼側セッション管理サーバのどちらにも使用できる。セッション管理サーバ２１０，２２０は、発呼側のセッション管理処理と着呼側のセッション管理処理とをコンピュータに実行させるセッション管理サーバ上で動作するプログラムを有している。
３１０，３２０は、本発明の通信中継サーバであり、通信アダプタ間の通信においてＨＴＴＰによる通信データ（例えば、音声データ）配信を行う為の発呼側と着呼側との中継を行う。通信中継サーバ３１０は、ＨＴＴＰ通信部３１１とＵＤＰ（ユーザ データグラム プロトコル）通信部３１２とを備え、通信中継サーバ３２０は、ＨＴＴＰ通信部３２１とＵＤＰ通信部３２２とを備えている。通信中継サーバ３１０，３２０はＨＴＴＰ通信処理とＵＤＰ通信処理とをコンピュータに実行させる通信中継サーバ上で動作するプログラムを有している。
通信アダプタ１１０，１２０と通信中継サーバ３１０，３２０とはＨＴＴＰ通信部３１１，３２１によりＨＴＴＰを用いてインターネットを介してデータの通信を行う。また、通信中継サーバ３１０と３２０とは、ＵＤＰ通信部３１２と３２２とによりＵＤＰを用いてインターネットを介してデータの通信を行う。
なお、ＵＤＰ通信部３１２と３２２の代わりに、ＲＴＰ（リアルタイム トランスポート プロトコル、又は、トランスポートプロトコル・フォー・リアルタイムアプリケーション）によるＲＴＰ通信部（図示せず）を用いてもよい。また、ＵＤＰ、ＲＴＰの代わりに、ＳＣＴＰ（シンプル コントロール トランスミッション プロトコル）や、ＴＣＰ上の様々なアプリケーション用に作られたプロトコルを用いてもよい。
４１０は、指定通知サーバである。指定通知サーバ４１０は、通信アダプタ１１０，１２０からの要求に基づいて通信アダプタ１１０，１２０を管理するセッション管理サーバ２１０，２２０を通信アダプタ１１０，１２０へ通知する。
以下に記載する説明では、音声データを通信データの一例として、音声データを発呼側と着呼側とで相互に送受信するインターネット通信システムの一例を記載する。このため、通信データを通話データ、通信装置を通話装置、通信アダプタを通話アダプタ、通信中継サーバを通話中継サーバとして記載する。
図２及び図２８は、実施の形態１の発呼側と着呼側とで行うデータ送受信の手順を示す図である。
図２及び図２８の指定通知サーバ、発呼側通話アダプタ、着呼側通話アダプタ、発呼側セッション管理サーバ、着呼側セッション管理サーバはそれぞれ、図５，６，９，１０に示す検索テーブルを備え、検索テーブルを参照して通信先のアドレスを取得する。
図２及び図２８に図示されている指定通知サーバ４１０は、各通話アダプタが所属するセッション管理サーバを管理し、通話アダプタの電源ＯＮ時に、通話アダプタからその通話アダプタ自身の所属するセッション管理サーバの問合せを受信する。そして、問い合わせに対して、所属するセッション管理サーバの通知を、問い合わせ元の通話アダプタへ行う。通話アダプタの電源ＯＮ時に、通話アダプタから所属するセッション管理サーバの問合せを受信するプロセスが、“所属セッション管理サーバ検索プロセス”である。セッション管理サーバは、通話アダプタ毎に管理しているセッション管理サーバを示す情報を記憶するデータファイルを有する。“所属セッション管理サーバ検索プロセス”は、立ち上がり時に通話アダプタ毎に管理しているセッション管理サーバを示す情報を記憶しているデータファイルよりデータをメモリ展開し、通話アダプタからの問合せに対して該当するセッション管理サーバを検索し、検索結果を問い合わせもとの通話アダプタへ応答する。実施の形態１では、セッション管理サーバ毎の処理負荷を分散するため、複数のセッション管理サーバを設置し、指定通知サーバから通話アダプタごとにその通話アダプタを管理するセッション管理サーバを通知する。上記したデータファイルの追加・更新は、管理者による手作業とする。このため、データファイルの追加・更新を行う場合は、所属セッション管理サーバ検索プロセスの停止を行い、データ更新後に再立ち上げを行う。上記した指定通知サーバの環境を図３に示す。
このように、セッション管理サーバ関連情報が更新されることを考慮して、通話アダプタは、定期的に指定通知サーバに電源ＯＮ時と同様な問い合わせを行うようにすることもできる。このようにすれば、通話アダプタのユーザが上記サーバ情報の更新に合わせて、電源の入れ直しやリセットを行う必要がなくなる。
発呼側通話アダプタと着呼側通話アダプタとを接続する手順について、図２の（１）から（１０）の順に説明する（図２８についても、図２との差異を中心に（１）から（１２）の順に説明を補足する）。
図２の（１），（２）（図２８も同様）は、所属セッション管理サーバ情報の取得処理である。すべての通話アダプタは、電源投入時に指定通知サーバへ一度だけ所属するセッション管理サーバ情報の問合せを行う。ここでは、発呼側通話アダプタ１１０及び、着呼側通話アダプタ１２０は、指定通知サーバ４１０に対して自分が所属するセッション管理サーバ情報の取得要求を行う。指定通知サーバ４１０は、要求元の通話アダプタの所属するセッション管理サーバを検索して、所属セッション管理サーバ情報を要求元通話アダプタに回答メッセージとして送信する。要求元通話アダプタは、指定通知サーバ４１０からの「セッション管理サーバ名回答」を取得して、所属するセッション管理サーバ情報を要求元通話アダプタ自身の有する記憶部に登録する。図４に、通話アダプタの所属セッション管理サーバ情報の取得処理を示す。
この実施の形態１では、複数のセッション管理サーバを備え、指定通知サーバから通話アダプタごとのセッション管理サーバ情報を通知する。１つのセッション管理サーバが管理する通話アダプタの数を有限とすることにより、セッション管理サーバの処理負荷を分散している。このため通話アダプタは、所属するセッション管理サーバ情報を取得する必要がある。
図５のＳ１は、図２の（１）（図２８の（１）も同様）に対応する。図５において、発呼側通話アダプタ１１０は、通話アダプタ毎に採番された通話アダプタ固有の番号である通話アダプタＩＤと、通話アダプタを管理する所属セッション管理サーバをアクセスするアドレスとを対応させて記憶する通話アダプタ情報テーブル１１３を備えている。通話アダプタは、通話アダプタ固有の製造番号を有しているので、製造番号を通話アダプタＩＤとする。通話アダプタは、製造番号を用いて図２の（１）（図２８の（１）も同様）のセッション管理サーバ情報の取得要求を行う。発呼側通話アダプタ１１０は、電源投入時にセッション管理サーバ情報の取得要求に「通話アダプタＩＤ」を“１−２−１２”と設定して指定通知サーバ４１０にＧＥＴメソッドメッセージとして送信する。指定通知サーバ４１０は、受取ったセッション管理サーバ情報の取得要求から「通話アダプタＩＤ“１−２−１２”」を取り出して所属セッション管理検索テーブル４１１を検索する。所属セッション管理検索テーブル４１１には、通話アダプタＩＤを範囲指定して、各範囲の通話アダプタＩＤに対してその通話アダプタを管理するセッション管理サーバのアドレスを記憶している。指定通知サーバ４１０は、通話アダプタＩＤ“１−２−１２”を元に所属セッション管理検索テーブル４１１の通話アダプタＩＤの範囲を検索して、所属するセッション管理サーバのアドレスを取得する。ここでは、セッション管理サーバのアドレスとして“ｓ１＠ｘｘ．ｃｏｍ”（もしくは、２１０．５４．１０．１５６のような３２ビットのグローバルＩＰアドレス）を取得する。指定通知サーバ４１０は、取得したセッション管理サーバのアドレスを、発呼側通話アダプタ１１０に対して、図２の（２）（図２８の（２）も同様）及び図５のＳ２により、ＧＥＴ応答メッセージとして通知する。通話アダプタは、通知された所属セッション管理サーバのアドレスを、通話アダプタ情報テーブル１１３の通話アダプタＩＤ“１−２−１２”に対応させて登録する。着呼側通話アダプタ１２０も、発呼側通話アダプタ１１０と同様に（１），（２）の処理を図５のＳ３，Ｓ４にて行う。
図２の（３），（４）は発呼側における着呼側の通話アダプタが所属するセッション管理サーバ情報の取得処理である。発呼側通話アダプタ１１０は、自分が所属するセッション管理サーバ（発呼側セッション管理サーバ２１０）に対して着呼側セッション管理サーバ名の要求を行う。発呼側セッション管理サーバ２１０は、着呼側通話アダプタの所属するセッション管理サーバ（着呼側セッション管理サーバ２２０）の情報を、要求元通話アダプタにセッション管理サーバ名回答として応答メッセージを送信する。実施の形態１では、セッション管理サーバの処理負荷を分散する為、セッション管理サーバの管理する通話アダプタを例えば、通話アダプタＩＤの範囲毎に指定している。このため、発呼側通話アダプタ１１０から着呼側通話アダプタ１２０に対してセッションの接続を行う場合、発呼側通話アダプタ１１０は、着呼側通話アダプタ１２０を管理するセッション管理サーバを知る必要がある。
図６のＳ５，Ｓ６，Ｓ７は、図２の（３），（４）の処理に該当する。図６において、通話装置１０から着呼側の電話番号が入力されると（Ｓ５）、発呼側通話アダプタ１１０がこの電話番号を受け取り、アドレス変換テーブル１１４を参照して、着呼側の電話番号に対応する着呼側通話アダプタＩＤを取得する。アドレス変換テーブル１１４は、着呼側の電話（ＴＥＬ）番号と、着呼側の通話アダプタをアクセスするＩＰアドレスと、着呼側の通話アダプタ固有の通話アダプタＩＤと、着呼側通話アダプタを管理するセッション管理サーバのアドレスとを対応させて記憶している。発呼側通話アダプタ１１０は、取得した着呼側通話アダプタＩＤを着呼側セッション管理サーバ名の要求に設定して、ＧＥＴメソッドメッセージとしてＳ２で取得したセッション管理サーバ（発呼側セッション管理サーバ２１０）に宛てて送信する（Ｓ６）。着呼側セッション管理サーバ名の要求を受け取った発呼側セッション管理サーバ２１０は、着呼側セッション管理サーバ検索テーブル２１３を参照して、着呼側通話アダプタの所属する着呼側セッション管理サーバのアドレスを取得する。セッション管理サーバは、通話アダプタＩＤの範囲単位に通話アダプタを管理している。このため、着呼側セッション管理サーバ検索テーブル２１３は、着呼側通話アダプタＩＤの範囲と、着呼側セッション管理サーバのアドレスとを対応させて記憶している。着呼側通話アダプタＩＤは“２−１−１１”であるので、着呼側セッション管理サーバのアドレスは“ｓ２＠ｘｘ．ｃｏｍ”（もしくは、２１０．５４．１０．１５６のような３２ビットのグローバルＩＰアドレス）と取得できる。発呼側セッション管理サーバ２１０は、取得した着呼側セッション管理サーバのアドレス“ｓ２＠ｘｘ．ｃｏｍ”（もしくは、２１０．５４．１０．１５６のような３２ビットのグローバルＩＰアドレス）を着呼側セッション管理サーバ名の回答に設定して、ＧＥＴ応答メッセージとして発呼側通話アダプタ１１０に通知する（Ｓ７）。発呼側通話アダプタ１１０は、受信した着呼側セッション管理サーバ名の回答より着呼側セッション管理サーバのアドレス“ｓ２＠ｘｘ．ｃｏｍ”（もしくは、２１０．５４．１０．１５６のような３２ビットのグローバルＩＰアドレス）を取得して、アドレス変換テーブル１１４の「着呼側通話アダプタＩＤ“２−１−１１”」に対応させて登録する。図７に、着呼側セッション管理サーバ名の取得処理を示す。
図２の（５），（６）は、発呼メッセージの発行（セッションＩＤ取得）処理である。発呼メッセージは、発呼側通話アダプタ１１０から着呼側セッション管理サーバ２２０へ送信されるメッセージである。発呼メッセージを受信することにより着呼側セッション管理サーバ２２０は、管理する着呼側通話アダプタ１２０に対して通話要求が発生したことを認識し、通話相手（着呼側通話アダプタ）の状況を判断するとともに、利用可能な通話中継サーバを求め、通話中継サーバ回答情報にて応答する。この実施の形態１では、図２９に示すように、着呼側通話アダプタ１２０は、所属するセッション管理サーバ２２０に対して周期的（例えば、１秒毎、或いは、３秒毎）に着呼問合せを行うものである。或いは、周期的問い合わせでなく、図３０、或いは、図３１に示すように、ＨＴＴＰのＧＥＴを一度発行した状態で、着呼情報が返されるまで待機しておく方法をとることもできる。この方法の場合は、周期的な問合せ処理の負荷が節約できる。ただし、この方法では、ＨＴＴＰの接続、つまりＴＣＰの接続をデータの送受信がない状態で長時間保持することになるので、実際のインターネット環境では、通信アダプタからセッション管理サーバまでの通信経路上で、ＩＳＰ等により管理されているルータなどにより、無断でＴＣＰの接続が遮断される場合があり、確実に着呼情報を取得できる保証がない。このため、この方法の改善作として、図３２に示すように、常にＫｅｅｐ−Ａｌｉｖｅ情報というＴＣＰの接続を保持するために、データはまだ流れているという意味のダミーデータをセッション管理サーバから通信アダプタへ送信しつづける方法がある。さらには、このようにダミーデータを送信しつづける方法を採用しても、通信経路上のどこかで、ＴＣＰの接続が切断され、セッション管理サーバも通信アダプタもその切断に気がつかない場合がある。このような事態の改善策として、図３３に示すように、Ｋｅｅｐ−Ａｌｉｖｅ情報のダミーデータを一定周期でセッション管理サーバから通信アダプタへ送信するようにして、受信する通信アダプタ側で、その周期より若干長めのタイムアウト値を設定して、一定周期でのダミーデータの到着が滞った場合に、ＴＣＰの接続が遮断されたとみなして、改めて、通信アダプタからセッション管理サーバへ新たなＴＣＰの接続を行うようにする方法がある。また、このようにＴＣＰの再接続を行うときにセッション管理サーバから、通信アダプタに対して、着呼情報をちょうど送信したタイミングとなる可能性もある。ちょうど送信したタイミングとなるような場合には、その着呼情報は、通信アダプタに到着しないで失われてしまう可能性がある。よって、確実に着呼情報が通信アダプタに届くように、ＴＣＰの再接続によるＨＴＴＰのＧＥＴメソッドには、再発行であることを示す情報を付加することで、正常な状態で発行されたＨＴＴＰのＧＥＴメソッドとは異なることが、セッション管理サーバにて認知することができ、着呼情報の送信失敗を考慮して、全く同じ着呼情報を再送するようにする。さらに、この着呼情報には、再送である情報を付加しておけば、通信アダプタ側で再送にて受信した着呼情報であることを通信アダプタが認識することができ、次に、また新たなＨＴＴＰのＧＥＴメソッドを正常な状態にて発行することができる状態となる。
なお、これらのＨＴＴＰのＧＥＴメソッドは、着呼側の通信アダプタが発呼側の通信アダプタからのセッションの確立要求情報を応答として受信する場合について説明したが、他方の通信アダプタが受話器を取り上げたり（オフフック）、受話器を置いて通話を終了したり（オンフック）、相手のリング音がなり始めたりといった情報をこのＨＴＴＰのＧＥＴメソッドの応答として、受信する場合についても、確実にＨＴＴＰのＧＥＴメソッドの応答情報を受信するしくみを全く同様に適用できる。
以上のように、発呼側通話アダプタ１１０より通話を行う場合は、着呼側通話アダプタ１２０の所属するセッション管理サーバ２２０に対して発呼メッセージを発行する必要がある。
以上の発呼メッセージ発行の処理は、図２の（３）〜（６）に基づいたものであったが、図２８の方式では、（３）〜（８）の一連の処理に置きかえることができる。発呼側のメッセージの流れは、（４）、（５）、（６）、（７）となる。
あらかじめ、着呼側は、図２の場合と同様で、図２８（３）に示されるように、着呼側通話アダプタ１２０は、所属するセッション管理サーバ２２０に対して周期的（例えば、１秒毎、或いは、３秒毎）に着呼問合せを行うものである。或いは、周期的問い合わせでなく、ＨＴＴＰのＧＥＴを一度発行した状態で、着呼情報が返されるまで待機しておく方法をとることもできる。
図２８の（４）は、発呼メッセージの発行（セッションＩＤ取得）処理である。発呼メッセージは、発呼側通話アダプタ１１０から発呼側セッション管理サーバ２１０へ送信されるメッセージである。発呼側セッション管理サーバ２１０は、着呼側通話アダプタの所属するセッション管理サーバ（着呼側セッション管理サーバ２２０）の情報を、図２の場合と同様に求め、さらなる発呼メッセージとして、図２８の（５）において、発呼側セッション管理サーバ２１０から着呼側セッション管理サーバ２２０へメッセージを送信する。
着呼側セッション管理サーバ２２０は、発呼メッセージを受信することにより、管理する着呼側通話アダプタ１２０に対して通話要求が発生したことを認識し、通話相手（着呼側通話アダプタ）の状況を判断するとともに、利用可能な通話中継サーバを求め、通話中継サーバ回答情報にて、図２８の（６）において、発呼側セッション管理サーバ２１０へ応答メッセージを送信する。さらに、図２８の（７）において、発呼側セッション管理サーバ２１０から発呼側通話アダプタ１１０へ、その応答メッセージが転送される。また、図２８の（８）において、着呼側セッション管理サーバ２２０は、管理する着呼側通話アダプタ１２０に対して、電話の着信があったことを応答メッセージとして送信する。
図８と図３４とに、呼制御方式を示す。図８の呼制御方式は、図２に対応し、図３４の呼制御方式は、図２８に対応する。
図８の呼制御方式は、発呼側通話アダプタ１１０から着呼側セッション管理サーバ２２０に対して発呼を行うとともに、着呼側通話アダプタ１２０から着呼側セッション管理サーバ２２０に対して着呼確認を行うことを示している。
図３４の呼制御方式は、発呼側通話アダプタ１１０から着呼側セッション管理サーバ２２０に対して発呼側セッション管理サーバ２１０を経由して発呼を行うとともに、着呼側通話アダプタ１２０から着呼側セッション管理サーバ２２０に対して着呼確認を行うことを示している。
図９のＳ８は、図２の（５），（６）、或いは、図２８の（５），（６）の処理に該当する。
図９のＳ８では、発呼側通話アダプタ１１０は、Ｓ７で取得した着呼側通話アダプタ１２０の所属する着呼側セッション管理サーバ２２０のアドレス（“ｓ２＠ｘｘ．ｃｏｍ”）に宛てて、着呼側通話アダプタＩＤが“２−１−１１”の着呼側通話アダプタに対して、発呼メッセージの発行を行う。発呼メッセージの発行はＧＥＴメソッドメッセージの発行により行う。着呼側セッション管理サーバ２２０は、発呼メッセージの発行を受取り、図９のセッション確立要求テーブル２２３に、セッション確立要求のあった着呼側通話アダプタＩＤと、要求時刻と、セッション確立要求を送信した発呼側通話アダプタの所属する発呼側セッション管理サーバのアドレスとを、対応させて登録する。図９のセッション確立要求テーブル２２３は、発呼メッセージの要求のあった着呼側通話アダプタＩＤと、要求の行われた要求時刻と、発呼側の通話アダプタの所属する発呼側セッション管理サーバのアドレスとを対応させて記憶するテーブルである。着呼側セッション管理サーバ２２０は、テーブルに記憶した後、着呼側通話アダプタ１２０の状況を判断するとともに、利用可能な通話中継サーバを求め、求めた通話中継サーバを示す情報を通話中継サーバ回答情報にて、図２の場合に発呼側通話アダプタ１１０に対して、図２８の場合に発呼側セッション管理サーバ２１０に対して、応答する。通話中継を行う通話中継サーバが全て使用中である場合は、そのことを通話中継サーバ回答情報に設定して、図２の場合に発呼側通話アダプタ１１０に通知し、図２８の場合に発呼側セッション管理サーバ２１０に通知する。発呼側通話アダプタ１１０、或いは、発呼側セッション管理サーバ２１０への応答は、ＧＥＴ応答メッセージにより行う。
図２の（７），（８）、或いは、図２８の（３），（８）は、着呼確認の問合せ（セッションＩＤ取得）処理である。これは、図８の呼制御方式を示した図の着呼側通話アダプタと着呼側セッション管理サーバとの処理と同様である。着呼側通話アダプタ１２０は、通話可能状態である場合に限り、着呼側セッション管理サーバ２２０に対して着呼メッセージ要求を行う（図２（７）、或いは、図２８（３））。そのため、図２の場合、着呼側セッション管理サーバ２２０は、着呼側通話アダプタ１２０からの着呼メッセージが受信されていなければ、着呼側通話アダプタ１２０は、通話中であると判断する。
上記図２の形態では、セッション管理サーバにより、発呼側の通信アダプタから、着呼側の通信アダプタへ、発呼する方式のインターネット通信システムについて説明を行ったが、上記方式は、１つの例であり、ここでは、セッション管理サーバへの呼制御メッセージのやりとりとして、図２８の方式について説明を行う。
上記図２の形態の方式では、着呼側の通信アダプタが電話をかけることができる場合のみ、着呼側の通信アダプタから、着呼情報のメッセージが、着呼側のセッション管理サーバへ送信されていた。ところが、着呼側の通信アダプタが何らかの障害で着呼情報のメッセージを送信できない場合があり、こうしたときに、着呼側の通信アダプタの異常について、全く気がつかない状態で、いつも通話中という状況に陥る可能性がある。また、キャッチホン機能を実現するためには、実際に通話中の通信アダプタについても、他の通信アダプタからの着呼情報を送信する必要がある。したがって、これらの問題を解決するために、通話中であるかどうかに係らず、着呼情報のメッセージを通信アダプタは常にセッション管理サーバへ送信しておき、着呼側の通信アダプタの状態を通知する情報をセッション管理サーバへ上げる方式がよい。他の通信アダプタからの発呼については、セッション管理サーバから、その情報が着呼側の通信アダプタへ送信されることで、着呼が確認できる点は、上記図２の形態と同様である。
以上から、着呼情報のメッセージを常にセッション管理サーバに出しておくことで、他の通信アダプタから発呼があったことを常に着呼側の通信アダプタは、把握できるようになる。さらに、常に着呼側の通信アダプタから、着呼情報のメッセージの到着を待っているセッション管理サーバに対して、着呼情報のメッセージが送信されるので、これがなされない場合に、通信アダプタの異常をセッション管理サーバが確認でき、何らかの復旧処理を開始することができる。
図２８の場合、着呼側セッション管理サーバ２２０は、着呼側通話アダプタ１２０からの着呼メッセージが通話中の間も受信されているが、着呼側通話アダプタ１２０が、何らかの方式で、例えば、公衆回線網を介して通話中の場合に、着呼側セッション管理サーバ２２０にその通話中であることが着呼側の通信アダプタから通知されているため、セッション管理サーバが仲介していない通話であっても、通話中であると判断する。
また、着呼側セッション管理サーバは、利用可能な通話中継サーバを求め、通話中継サーバ回答情報にて着呼側通話アダプタ１２０に対して応答する。通話中継を行う通話中継サーバが全て使用中である場合は、そのことを通話中継サーバ回答情報に設定して着呼側通話アダプタ１２０に通知する。着呼側セッション管理サーバ２２０は、着呼側通話アダプタ１２０に対する通話要求検索結果を通話中継サーバ回答情報に設定して通話中継サーバ回答メッセージとして送信する（図２（８）、或いは、図２８（８））。通話中継サーバ回答メッセージは、ＧＥＴ応答メッセージにより回答する。
実施の形態１では、通話アダプタごとにその通話アダプタを管理するセッション管理サーバが異なっている。つまり、発呼側と着呼側の通話アダプタとでは、所属するセッション管理サーバは必ずしも同じセッション管理サーバではない。そのため通話アダプタは、所属するセッション管理サーバに対して、図２の場合は直接、図２８の場合は発呼側セッション管理サーバ経由にて、着呼問合せを行うことにより、通話相手より電話がかかってきたことを認識する。
図１０のＳ９，Ｓ１０，Ｓ１１は、図２の（７），（８）、或いは、図２８の（３），（８）の処理に該当する。Ｓ９において、着呼側通話アダプタ１２０は、通話アダプタ情報テーブル１２３より自身の通話アダプタＩＤと着呼側セッション管理サーバを示すアドレスとを取得する。取得した着呼側セッション管理サーバのアドレスに宛てて、着呼メッセージ要求を行う（Ｓ９）。着呼メッセージ要求は、ＧＥＴメソッドメッセージとして着呼側セッション管理サーバ２２０に送信する。着呼側セッション管理サーバ２２０は、着呼メッセージ要求の通話アダプタＩＤに基づいてセッション確立要求テーブル２２３を検索して、セッション要求の有無を確認する。図１０では、セッション確立要求テーブル２２３に通話アダプタＩＤ“２−１−１１”宛に要求が行われている。このため、着呼側セッション管理サーバ２２０は、セッション要求がされていることを通話中継サーバ回答メッセージに設定して着呼側通話アダプタ１２０に宛てて通知する（Ｓ１１）。図８に示した呼制御方式の着呼側通話アダプタ１２０と着呼側セッション管理サーバ２２０との通話処理が、Ｓ９とＳ１１の処理を示している。さらに、着呼側セッション管理サーバ２２０は、セッション確立要求テーブル２２３から、着呼メッセージ要求のあったセッション確立要求の発呼側セッション管理サーバ２１０のアドレスを取得する。そして、着呼メッセージ要求のあったセッション確立要求の発呼側セッション管理サーバ２１０に対して、着呼メッセージ要求がなされていることを通知する（Ｓ１０）。
上記に説明した図２の（３），（４），（５），（６），（７），（８）、或いは、図２８の（３），（４），（５），（６），（７），（８）は、セッション管理サーバ２２０による通話中継管理処理である。セッション管理サーバ２２０は、通話アダプタからの発呼メッセージを受信して、それを契機に通話中継を開始する。通話中継方法を以下に示す。
（ａ）発呼側通話アダプタ１１０からの発呼メッセージを受信する。
（ｂ）受信した発呼メッセージの通話相手（着呼側通話アダプタ１２０）からの着呼メッセージを受信しているかを判断する。
（ｃ）受信した発呼メッセージの通話相手（着呼側通話アダプタ１２０）からの着呼メッセージを受信している場合は、通話中継未使用の通話中継サーバを検索する。セッション管理サーバ２２０は、受信した発呼メッセージと着呼メッセージ及び、地区管理データ（地区管理データについては別の実施の形態で説明を行う）を元に通話中継が可能であるかを判断する。通話中継が不可能な条件は、
・受信した発呼メッセージの通話相手（着呼側通話アダプタ１２０）からの着呼メッセージを受信していない（図２の場合）、或いは、受信した発呼メッセージの通話相手（着呼側通話アダプタ１２０）が既に通話中である（図２８の場合）・通話中継を行う通話中継サーバの各セッション数が全て使用中
のいずれかである。セッション管理サーバ２２０は、通話中継で使用する通話中継サーバを地区毎に作成された“地区管理データ”にて管理する。セッション管理サーバ２２０の発呼管理プロセス立ち上がり時に“所属セッション管理サーバデータファイル”よりデータを読み出し、メモリ上に“地区管理データ”、“中継サーバ管理データ”、“セッション管理データ”とを作成する。“所属セッション管理サーバデータファイル”、“地区管理データ”、“中継サーバ管理データ”、“セッション管理データ”については別の実施の形態で説明を行う。
検索した結果、通話中継可能な通話中継サーバが存在しない場合は、ログ出力を行い管理者に通知する。また、通話アダプタ１１０，１２０に対してもエラー通知を行い、通話アダプタ１１０，１２０経由（ＬＥＤ点灯など）で通話装置を操作しているユーザに異常状態を通知する。
（ｄ）着呼側セッション管理サーバ２２０から発呼側通話アダプタ１１０、着呼側通話アダプタ１２０へ通話中継サーバ回答情報を送信する（図２の場合）。発呼側セッション管理サーバ２１０から発呼側通話アダプタ１１０へ、着呼側セッション管理サーバ２２０から着呼側通話アダプタ１２０へ通話中継サーバ回答情報を送信する（図２８の場合）。図１１に通話中継サーバ回答情報に設定される情報を示す。
図２及び図２８の（９），（１０）は、音声データの配信処理である。ここでは、発呼側通話アダプタ１１０と着呼側通話アダプタ１２０との間を１台の通話中継サーバによって通話を中継する第一段階の中継データ送信と、発呼側通話アダプタ１１０と着呼側通話アダプタ１２０との間を２台（２台以上でも可）の通話中継サーバによって通話を中継する第二段階の中継データ送信とがあり、第一段階と第二段階について、それぞれ説明する。
始めに、第一段階の中継データ送信を説明する。
図１２に、第一段階の中継データ送信の処理を示す。第一段階の中継データ送信では、ファイアウォール越えを実現する一台の通話中継サーバ３１０を経由して、データ配信を行う。第一段階の中継データ送信では、発呼側通話アダプタ１１０は、図２の（６）、或いは、図２８の（７）により着呼側セッション管理サーバ２２０から取得した「通話中継サーバ回答メッセージ」に設定されている利用可能な通話中継サーバ３１０に対して「発呼側音声データ」をＰＯＳＴメソッドで送信する。発呼側通話アダプタ１１０は、図２の（６）、或いは、図２８の（７）により着呼側セッション管理サーバ２２０から取得した「通話中継サーバ回答メッセージ」に設定されている利用可能な通話中継サーバ３１０から「着呼側音声データ」をＧＥＴメソッドで受信する。また、発呼側と着呼側が逆転した場合は、着呼側通話アダプタ１２０は、通話中継サーバ３１０へ音声データを送信する。発呼側通話アダプタ１１０は、着呼側通話アダプタ１２０の音声データを取得する為に、通話中継サーバへ音声データ受信要求を行う。
通話中継サーバ３１０は、音声データとして発呼側通話アダプタ１１０から“発呼側音声データ送信情報”を受信する。図１３に発呼側音声データ送信情報の項目と内容を示す。
通話中継サーバ３１０では、発呼側通話アダプタ１１０から受信した音声データを元に着呼側へ送信する音声データとして“着呼側音声データ受信情報”を編集する。図１４に着呼側音声データ受信情報の項目と内容を示す。
尚、発呼側通話アダプタ１１０からの“発呼側音声データ送信（ＰＯＳＴメソッド）”の応答は、着呼側通話アダプタ１２０への“着呼側音声データ受信（ＧＥＴメソッド）”応答送信後に通知する。
次に、第二段階の中継データ送信を説明する。
図１５に、第二段階の中継データ送信の処理を示す。
第二段階での音声データ送信は、通話中継サーバ３１０，３２０との間をＵＤＰを用いて音声データを通信する。発呼側通話アダプタ１１０は、図２の（６）、或いは、図２８の（７）により着呼側セッション管理サーバ２２０から取得した「通話中継サーバ回答メッセージ」に設定された利用可能な通話中継サーバ３１０に対して「発呼側音声データ」をＰＯＳＴメソッドで送信する。ＰＯＳＴメソッドを受信した通話中継サーバ（発呼側）３１０は、ＵＤＰを用いて通話中継サーバ（着呼側）３２０に音声データを転送する。着呼側通話アダプタ１２０は、図２の（８）、或いは、図２８の（８）により着呼側セッション管理サーバ２２０から取得した「通話中継サーバ回答メッセージ」に設定された利用可能な通話中継サーバ３２０に対して「発呼側音声データ」をＰＯＳＴメソッドで送信を行う。ＰＯＳＴメソッドを受信した通話中継サーバ（着呼側）３２０は、ＵＤＰを用いて通話中継サーバ（発呼側）３１０より受信した音声データをＧＥＴメソッド応答として着呼側通話アダプタ１２０へ送信する。また、発呼側と着呼側が逆転した場合は、着呼側通話アダプタ１２０は、通話中継サーバ（着呼側）３２０へ音声データ送信を行い、通話中継サーバ（着呼側）３２０は、通話中継サーバ（発呼側）３１０へＵＤＰにて音声データを転送する。発呼側通話アダプタ１１０は、着呼側通話アダプタ１２０の音声データを取得する為に、通話中継サーバ３１０へ音声データ受信要求を行う。通話中継サーバ（発呼側）３１０は、通話中継サーバ（着呼側）３２０より受信した音声データをＧＥＴメソッド応答として発呼側通話アダプタ１１０へ送信する。
発呼側通話中継サーバ３１０では、音声データとして発呼側通話アダプタ１１０から“発呼側音声データ送信情報”を受信する。発呼側音声データ送信情報の項目と内容は、図１３と同じである。
発呼側通話中継サーバ３１０は、発呼側通話アダプタ１１０からの音声データ受信後に着呼側通話中継サーバ３２０へＵＤＰ送信にて音声データを送信する。
尚、発呼側からの“発呼側音声データ送信（ＰＯＳＴメソッド）”の応答は、着呼側通話中継サーバ３２０への“ＵＤＰ送信正常終了”受信後に通知する。
着呼側通話中継サーバ３２０では、発呼側通話中継サーバ３１０から受信した音声データを元に着呼側通話アダプタ１２０へ送信する音声データとして“着呼側音声データ受信情報”を編集する。着呼側音声データ受信情報の項目、内容は図１４と同じである。
尚、発呼側からの“ＵＤＰ送信”の応答は、着呼側への“着呼側音声データ受信（ＧＥＴメソッド）”応答送信後に通知する。
以下に、通話中継サーバによる通話中継管理処理について説明する。
通話中継サーバは、通話アダプタからの発呼側音声データ受信または、着呼側音声データ受信を契機に通話中継を開始する。ここでは、以降“発呼側音声データ”、“着呼側音声データ”は、発信元が異なるだけである為、発信元を区別する必要のない時は、以下、“音声データ”とする。
通話中継サーバは、通話中継で使用するセッションを“セッション管理データ”にて管理する。セッション管理データは、通話中継サーバの備える“サーバ管理データファイル”より生成される。“サーバ管理データファイル”は、セッション管理サーバにて管理するデータのリミット値が設定されているファイルであり、以下の内容のデータを有している。
セッション管理サーバが管理する通話中継サーバの設置台数
セッション管理サーバが管理する通話中継サーバー台当たりの最大セッション数
所属する通話中継サーバのサーバ識別情報
所属する通話中継サーバのＩＰアドレス
セッション管理データは、通話中継サーバのＨＴＴＰ中継サーバメインプロセス立ち上がり時に“サーバ管理データファイル”の上記した内容のデータから該当するデータを読み出し、メモリ上に通話中継サーバ管理データ、セッション管理データを作成する。セッション管理データ、通話中継サーバ管理データについては、別の実施の形態で説明を行う。上記した該当するデータとは、サーバ管理データファイルは、一台の通話中継サーバ上にセッション管理サーバ単位に複数存在しているため、該当するセッション管理サーバに関するデータのみを対象にするという意味である。
最初の受信を契機に、“セッション管理データ”にセッションＩＤとして発呼側通話アダプタの通話アダプタＩＤ（製造番号）を設定し、ＩＰアドレス（通話アダプタ、通話中継サーバのいずれか）を設定する。
尚、通話中継エラーは、セッション管理サーバにて通話中継の可／不可を判断している為、通話中継サーバ側では基本的には発生しない。しかし、エラーが発生した場合は、ログ出力を行い管理者に通知する。
また、システム管理者は、セッション管理サーバや通話中継サーバが正常に動作しているかどうかＣＰＵ負荷率やネットワークパケット送受信状況等をみてリアルタイム監視も行うが、同時に何通話の処理が実行されているか、あるいは、通話処理のエラーが発生しているかについても、サーバ側は把握しているので、その情報のリアルタイム監視表示を行うことが可能である。
以上が、インターネット通信システム、インターネット通話方法における発呼側と着呼側との音声データの送受信手順である。また、発呼側，着呼側のセッション管理サーバと、通話中継サーバと、発呼側，着呼側通話アダプタと、指定通知サーバとについて、その機能及び動作について説明を行った。
実施の形態２．
実施の形態１で説明したインターネット通信システムを用いたシステムの運用構成の一例を説明する。
図１６は、実施の形態２のインターネット通信システムの運用構成例を示す図であり、呼制御集中管理方式を用いたインターネット通信システムの運用構成図である。
図１６では、複数の通話中継サーバを全国に配置して、西日本と東日本の地域毎にグループ分けする。そして、セッション管理サーバを西日本と東日本とにそれぞれ一台ずつ配置して、東京に指定通知サーバの機能を兼ね備えたセッション管理サーバを配置する。図１６に示した運用構成のインターネット通信システムは、図１７に示す手順によって発呼側と着呼側との音声データの送受信を行う。図１７の（１）から（１０）の手順は図２（１）から（１０）の手順と同様である。また、図１７の別の手順として、図２（１）から（１０）を適用させることも可能である。図１６のようにセッション管理サーバを所定の地区に配置することにより、セッション管理サーバに所属する通話アダプタを地区毎に管理することが可能となる。実施の形態１で通話アダプタを通話アダプタＩＤ（製造番号）によって管理することを説明した。図１６のようにセッション管理サーバを配置する場合の通話アダプタＩＤは、「エリア識別子」と「通話アダプタ識別子」とにより構成する。指定通知サーバは、通話アダプタからセッション管理サーバ名要求メッセージを受信すると、通話アダプタが所属するセッション管理サーバを、「エリア識別子」に基づいて決定する。図１６では、セッション管理サーバは西日本と東日本に設置されているので、いずれかのセッション管理サーバに所属するかを「エリア識別子」から決定することができる。また、西日本の地域を更に細分化して、例えば、九州地区、近畿地区、山陰地区、四国地区それぞれにセッション管理サーバを設置する構成も可能である。この構成では、「エリア識別子」を階層化して、階層の上位に西日本と東日本を区別する識別子をもうけ、階層の下位に九州地区、近畿地区、山陰地区、四国地区をもうけることにより、通話アダプタの所属するセッション管理サーバを決定できる。また、図１７の東京セッション管理サーバ指定通知サーバは、西日本地区セッション管理サーバ及び東日本地区セッション管理サーバとを管理する。西日本地区セッション管理サーバは、福岡通話中継サーバと大阪通話中継サーバとを管理する。東日本地区セッション管理サーバは、仙台通話中継サーバと札幌通話中継サーバとを管理する。このように、通話中継サーバを、通話中継サーバが設置されている地域ごとにその近くの地域に設置されているセッション管理サーバによって管理する。このようにすると、通話アダプタの設置されている地域に最も近い場所に設置されている中継サーバによって、音声データの中継を行うことができるようになる。
また、複数のインターネットサービスプロバイダ（ＩＳＰ）と提携して、セッション管理サーバ及び、通話中継サーバをそれぞれのＩＳＰのサーバが配置されている場所に配置し、各ＩＳＰに配置されたサーバ群（セッション管理サーバと通話中継サーバ）をＩＳＰ網を介して接続する運用構成も考えられる。この場合、通話アダプタＩＤは、「ＩＳＰ識別子」と「通話アダプタ識別子」とにより構成する。指定通知サーバは、通話アダプタからセッション管理サーバ名要求メッセージを受信すると、「ＩＳＰ識別子」により通話アダプタが所属するセッション管理サーバを決定する。また、１つのＩＳＰが複数のセッション管理サーバを運用している場合は、さらに通話アダプタＩＤに「エリア識別子」を追加して、「ＩＳＰ識別子」と「エリア識別子」と「通話アダプタ識別子」とにより通話アダプタＩＤを構成する。通話アダプタの所属するセッション管理サーバは、「ＩＳＰ識別子」と「エリア識別子」とにより決定する。このように、１社だけでなく複数のＩＳＰと提携してインターネット通信システムを運用することも可能である。さらに、１社のＩＳＰがエリア識別子により複数のエリア相当でセッション管理サーバを複数設置して運用することも可能である。図１８に複数のＩＳＰと提携してインターネット通信システムを運用するシステムの構成図を示す。
また、各ＩＳＰごとに運用されているセッション管理サーバ間及び、通話中継サーバ間は、各ＩＳＰの有するＩＳＰ網を介して通信可能である。この場合、ＩＳＰ網を介してのセッション管理サーバ間、通話中継サーバ間、セッション管理サーバと通話中継サーバとの間の通信は、ＵＤＰを用いて通信を行う。あるいは、ＲＴＰ（トランスポートプロトコル・フォー・リアルタイムアプリケーション）または、ＴＣＰ（トランスミッション コントロール プロトコル）を用いて通信を行う。もちろん、同様な他のトランスポート層のプロトコルを採用することも可能である。このように異なるＩＳＰ間での通信を可能にすることにより、異なるＩＳＰの運用する通話中継サーバを介して発呼側と着呼側とで音声データを送受信できる。通話アダプタと通話中継サーバ間は、インターネット網を利用して上記実施の形態１と同様にＨＴＴＰを用いて通信を行う。図１９、図２０に、ＩＳＰ網を利用するインターネット通信システムの運用構成を示す。図１９は、通話中継サーバとセッション管理サーバのそれぞれが、ＩＳＰ網と接続されていることを示している。図２０は、通話中継サーバ間をＩＳＰ網を介して音声データを通信する例を示している。図１９に示されている複数の中継サーバのうち所定の２台の中継サーバを用いて中継サーバ間をＩＳＰ網を経由して音声データを通信する場合は、図２０に示すように、通話中継サーバ間は単純な音声データの転送を行い、発呼側通話アダプタと通話中継サーバ間および着呼側通話アダプタと通話中継サーバ間は、「ＰＯＳＴ（通話アダプタから通話中継サーバに情報を送信する場合）」と、「ＧＥＴ（通話アダプタに対して通話中継サーバから情報を送信する場合）」を用いて通信を行う。このことは、既に実施の形態１で説明を行ったことである。
また、ＩＳＰ網の一例としてＣＡＴＶ（ｃａｂｌｅ ｔｅｌｅｖｉｓｉｏｎ）会社が提供するインターネット接続サービスのＣＡＴＶ網を利用して、インターネット通信システムを運用することが考えられる。図２１、図２２にＣＡＴＶ網を利用したインターネット通信システムの運用例を示す。図２１は、各ＣＡＴＶ会社エリアに最も帯域が太く接続されている最寄りの通話中継サーバを各ＣＡＴＶエリア用にアサインする。図２１の例では、東京セッション管理サーバは、阪神ＣＡＴＶと市原ＣＡＴＶとの間でインターネット電話を使用する場合、阪神ＣＡＴＶ側は大阪通話中継サーバを使用するように指定を行い、市原ＣＡＴＶは東京通話中継サーバを使用するように指定を行う。東京通話中継サーバと大阪通話中継サーバ間は、ＵＤＰを用いて音声データを通信する。図２２は、一カ所にサーバ群（セッション管理サーバ、通話中継サーバ、指定通知サーバ）を設置して、サーバ群を設置した個所とＣＡＴＶ網を接続してシステムを運用する例を示している。現状の通信網の設置状況は、図２２のように東京（大手町）に最も太い帯域の通信網が集中して設置されている。このため、指定通知サーバとセッション管理サーバと通話中継サーバとを設置する。また、各ＣＡＴＶネットワークとの間も東京（大手町）を経由して通信を行うことが多い。このため、東京（大手町）にサーバ群を設置することにより、帯域の確保を図ることができる。
以上に、通話アダプタＩＤの構成と、インターネット通信システムの運用例を説明した。
実施の形態３．
実施の形態３では、セッション管理サーバの行うプロセスについて説明を行う。
実施の形態１，２のセッション管理サーバは、発呼側と着呼側の中継を行うための通話中継サーバの通話中継を負荷分散・管理するため“利用可能な通話中継サーバの指示”、“セッションＩＤの管理”を行う。
セッション管理サーバでのプロセスは、３つのプロセスが存在する。
１つめは、通話アダプタから所属するセッション管理サーバに対して、周期的に行われる着呼確認の問合せを受信する“着呼管理プロセス”である。
２つめは、通話を行う場合に自分（発呼側通話アダプタ）が所属するセッション管理サーバにて通話先相手の所属するセッション管理サーバの問合せを受信する“通話先所属セッション管理サーバ検索プロセス”である。通話先所属セッション管理サーバ検索プロセスは、通話アダプタからの問合せに対して該当するセッション管理サーバを検索し、図２の場合に、検索したセッション管理サーバを示す情報を応答する。また、図２８の場合には、検索したセッション管理サーバに対して、直接発呼メッセージの送信を行い、その着呼側セッション管理サーバからの応答メッセージを受信する。
３つめは、通信開始時に通話先相手の所属するセッション管理サーバにて発呼要求を受信するプロセスが“発呼管理プロセス”である。
この実施の形態のインターネット通信システムは、複数のセッション管理サーバを設置して、セッション管理サーバ毎にそのセッション管理サーバに所属する通話アダプタからの要求・問合せに対処して、各セッション管理サーバの負荷分散を行う。図２３に、図２に対応する上記に説明した３つのプロセスを実行するセッション管理サーバの環境を示す。図３５に、図２８に対応する上記に説明した３つのプロセスを実行するセッション管理サーバの環境を示す。図２３，図３５では、セッション管理サーバは、“所属セッション管理サーバデータファイル”と“地区管理データ”と“中継サーバ管理データ”と“セッション管理データ”とを用いて処理を行っている。
以下に、図２３の“所属セッション管理サーバデータファイル”、“地区管理データ”、“中継サーバ管理データ”、“セッション管理データ”について説明する。図３５についても、同様である。
“所属セッション管理サーバファイル”は、図２４に示す項目を有して、全てのセッション管理サーバに備えられている。図２４によると、「ステータス」、「ＩＳＰ識別子」、「エリア識別子」、「所属セッション管理サーバＩＰアドレス」とを有している。「ＩＳＰ識別子」は、セッション管理サーバを複数のＩＳＰによって運営される場合に必要である。この所属セッション管理サーバファイルを検索して、着呼側の通話アダプタの所属するセッション管理サーバを決定する。また、指定通知サーバが所属セッション管理サーバファイルを備えることにより、発呼側通話アダプタからのセッション管理サーバ名要求メッセージに回答することができる。
次に、地区管理データについて説明する。
地区管理データは、セッション管理サーバが管理している通話中継サーバの管理情報を記憶する。図２５に、地区管理データのデータ構成例を示す。セッション管理サーバは、この地区管理データを元に通話を中継する通話中継サーバの候補を決定し、候補となった通話中継サーバそれぞれの状態を確認して、実際に通話を中継するサーバとして選択する。
次に、中継サーバ管理データについて説明する。
図２６に地区管理データと中継サーバ管理データの関係及び、中継サーバ管理データとセッション管理データとの関係を示す。中継サーバ管理データは、地区管理データの通話中継サーバ管理情報とリンクしている。中継サーバ管理データは、地区管理データが図２６の地区管理データ５００の構成をしている時、中継サーバ管理データ先頭アドレスと最後尾アドレスとにリンクして、通話中継サーバ管理データ５１０を記憶する。個々の通話中継サーバ管理データは、データ５２０の“通話中継サーバ使用状況”から“セッション管理データ最後尾アドレス”までの各情報を有している。
セッション管理データは、図２６のセッション管理データ５３０を記憶する。セッション管理データ５３０は、データ５４０の“セッション状態”から“通話中継ＩＰアドレス（着呼側）”までの各情報を有している。セッション管理データ５３０は、通話中継サーバ管理データ５２０の“セッション管理データ先頭アドレス”と“セッション管理データ最後尾アドレス”とリンクしている。
セッション管理サーバは、図２５，２６に示したデータによって、通話中継サーバの状態を管理して、通話アダプタから通話要求がなされた場合に、使用可能な通話中継サーバを検索して決定している。
以上が、セッション管理サーバの機能、および、保有するデータである。
実施の形態４．
上記実施の形態１から３では、音声データを発呼側と着呼側とで送受信するインターネット通信システムについて説明を行ったが、音声データは通信データの一例であり、インターネット通信システムは、通信データを発呼側と着呼側とで送受信するシステムである。また、通話アダプタは、通信アダプタの一例である。通話中継サーバは、通信中継サーバの一例である。
また、「ＩＤ」は、名称又は識別情報又は識別子又はＩＰアドレス等の自他を識別できるものならばどのようなものでも良い。
また、システムを構成する各要素（図１の、発呼側通信アダプタ部１１１，１２１、着呼側通信アダプタ部１１２，１２２、発呼側セッション管理部２１１，２２１、着呼側セッション管理部２１２，２２２、ＨＴＴＰ通信部３１１，３２１、ＵＤＰ通信部３１２，３２２）は、ソフトウェア或いは、ハードウェア或いは、ソフトウェアとハードウェアの、いずれかで実施されるものである。
また、システムを構成する各要素（図１の、発呼側通信アダプタ部１１１，１２１、着呼側通信アダプタ部１１２，１２２、発呼側セッション管理部２１１，２２１、着呼側セッション管理部２１２，２２２、ＨＴＴＰ通信部３１１，３２１、ＵＤＰ通信部３１２，３２２）は、コンピュータ上で実行されるプログラムの処理で実施されるものである。
また、通信アダプタとセッション管理サーバ、指定通知サーバ、通信中継サーバとはそれぞれ、コンピュータである。また、プログラムは、コンピュータのＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）で実行されるものである。
また、プログラムは、ＦＸＤ（ｆｌｅｘｉｂｌｅ ｄｉｓｋ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）などの記録媒体に記録されているものである。
実施の形態５．
従来例で説明した図２７に示されるような通信アダプタでは、ＩＰ回線以外に、公衆回線経由での通話も可能である。この場合に、実施の形態１〜４にて示されるような本発明のＩＰ回線上での通話処理を行うときに、公衆回線での通話と同時に行われることがないように、排他的な制御処理が必要になる。
そこで、公衆回線経由での通話を行う際には、図３６の（３）にて示されるように、通信アダプタを管理するＩＰ（Ｉｎｔｅｒｎｅ Ｐｒｏｔｏｃｏｌ）回線上での呼制御を管理しているセッション管理サーバに、通話開始時と通話終了時に公衆回線経由通話の開始と終了に関する情報を通信アダプタから通知するようにする。
また、公衆回線経由通話だけでなく、ＩＰ回線上の他方式の通話、例えば、Ｈ．３２３方式（サービス品質が保証されていないＬＡＮ上での音声、動画像、データ通信の端末規定）、ＭＧＣＰ（Ｍｅｄｉａ Ｇａｔｅｗａｙ Ｃｏｎｔｏｒｏｌ Ｐｒｏｔｏｃｏｌ）方式、ＳＩＰ（セッション・イニシエイション・プロトコル）方式などでの通話を行える機能を通信アダプタが実装している場合がある。この場合、それら方式での通話処理と排他的な制御を行うために、それら方式での通話開始時と通話終了時に、それら方式でのＩＰ回線経由通話の開始と終了に関する情報を、図３６の（２）にて示されるように、通信アダプタからその通信アダプタを管理するセッション管理サーバに対して、他方式にて通話中であることを通知するようにする。
また、図３６の（１）のように、通信を行う通信アダプタ同士においても、通話相手の電話機の操作について、セッション管理サーバを経由して互いの電話機の操作情報を送受信しあうことで、一方の電話機が電話呼出時であれば、他方の電話機に対してはリングバックトーンを鳴らしたり、相手が受話器をとれば、通話開始としたり、受話器オンフック切断時に、相手側の受話器から切断音を鳴らしたりすることができる。このセッション管理サーバ経由の通信をＨＴＴＰのＧＥＴメソッドを用いた場合の通信処理の一例を、図３７に示す。
図３７の左側の「受話器オフフック」、「ダイヤル入力」、「リングバックトーン開始」、「相手切断音」と、右側の「リング開始」、「受話器オフフック」、「受話器オンフック」は、電話機の操作である。矢印線で示されているのがＨＴＴＰのＧＥＴメソッドを用いた場合の呼制御メッセージシーケンスである。
図３７に示すように、発呼側通信アダプタと着呼側通信アダプタとは、「受話器オフフック」や「ダイヤル入力」や「受話器オンフック」の電話機の操作を行った場合に、セッション管理サーバに対して受話器の操作内容を通知するＧＥＴメソッドを発行する。また、セッション管理サーバは、発呼側通信アダプタが「ダイヤル入力」を行ったことを通知された後、着信側のセッション管理サーバからオフフックの連絡が通知されるまで、発呼側通信アダプタに対して「リングバックトーンの開始」を行うための発呼ＧＥＴ応答を返す。着呼側通信アダプタから受話器オフフックの通知が着呼側セッション管理サーバに対して行われると、着呼側セッション管理サーバから発呼側セッション管理サーバへオフフックの連絡が通知され、発呼側セッション管理サーバから発呼側通信アダプタに対して着信ＧＥＴ応答が行われる。その後、発呼側通信アダプタと着呼側通信アダプタとの間で、音声通話が行われる。音声通話が終了し、着呼側通信アダプタが「受話器オンフック」すると、オンフックの連絡が着呼側セッション管理サーバから発呼側セッション管理サーバに通知され、発呼側セッション管理サーバは、発呼側通信アダプタに対して着信ＧＥＴ応答が通知され、発呼側通信アダプタは、電話機から相手の受話器がオンフックされたことを通知する切断音を発信させる。
上述したように、他の呼制御方式の通話開始時や通話終了時、及び、電話機の操作の情報を通信アダプタからの通知によってセッション管理サーバが収集することができるので、それぞれの情報の送受信時にログ情報として出力記録しておくことで、ユーザが利用したあらゆる形態の通話利用について情報を収集することができる。これにより、通話時間を確認することができ、課金情報として利用することができる。
さらに、この通話関係のログ情報をセッション管理サーバなどで、解析、整理するソフトウェアを実行することで、図３８に示すように、日ごと、月ごとの通話履歴情報をシステム管理者が参照し、システムの運用状況を確認することができる。図３８は、日ごと、月ごとのサマリを表示した例である。システム管理者は、セッション管理サーバのログ情報を解析するソフトウェアツールで得られた各通話情報ファイルから、図３８に示す表（もしくは、相当のＣＳＶ（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅの略称）形式等のファイル）を作成し、Ｗｅｂブラウザなどで表示させ、参照することができる。総通話数、瞬間同時最大通話数は、グラフ表示を行っても構わない。
実施の形態６．
全ての通信アダプタがグローバルＩＰアドレスを固定的に割り当てられていれば、いかなるプロトコルにても各種情報を直接に送受信することが基本的に可能である。しかし、ＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ バージョン４）においては、大半の通信アダプタがインターネットに間接的に接続されており、１つのグローバル固定ＩＰアドレスを割り当てられたルータからアドレス変換を経て、プライベートＩＰアドレスを割り当てられることが多い。これらのルータでは、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）やＩＰマスカレード（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ マスカレード）などのアドレス変換機能とともに、使用しないポート番号をふさぐなどのファイアウォール機能が設定されることが多い。
また、一般の家庭で利用できるインターネット回線では、家庭ごとに１つのグローバルＩＰアドレス、または、ドメイン内のプライベートＩＰアドレスを割り当てられることが多い。このため、家庭では、複数のパーソナルコンピュータをインターネットに接続して、家庭や小規模オフィス向けのＳＯＨＯ（Ｓｍａｌｌ Ｏｆｆｉｃｅ Ｈｏｍｅ Ｏｆｆｉｃｅ）ルータを介して接続する場合が多い。このＳＯＨＯルータにおいても、アドレス変換が行われることになり、ファイアウォール機能がある場合も多い。
上記のように、複数のルータを介することによって、プライベートＩＰアドレスへのアドレス変換が２回以上行われる場合もある通信アダプタから外部の通信アダプタに対してアクセス可能と考えられる一般的なアプリケーションレベルの通信プロトコルとしては、ＨＴＴＰとＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）がある。
また、ＩＰｖ４が普及している現状においては、グローバルＩＰアドレスであろうと、プライベートＩＰアドレスであろうと、動的に割り当てられることも非常に多い。このＩＰアドレスを動的に割り当てるために、指定通知サーバがＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ機能を備え、各通信アダプタがＤＨＣＰクライアント機能を備えることで対応する。
以上から、通信アダプタが通信先を特定するアドレシングとして、ＩＰアドレスを採用することは実質的に不可能な場合が多い。
既に記述していたように、ファイアウォールやＮＡＴルータ（ＳＯＨＯルータやブロードバンドルータなどと呼ばれることが多い）等でエリア管理されている各ドメイン内の通信アダプタは、そのドメインのＤＭＺ（Ｄｅ−Ｍｉｌｉｔａｒｉｓｅｄ Ｚｏｎｅ）内に設置されたセッション管理サーバと通話中継サーバを経由して、ドメイン外の通信アダプタや外部ドメインの各種サーバと通信を行う。
図３９に、リアルタイムデータの通信を行う通信アダプタと通話中継サーバの通話中継方式の種類を、方式１〜３に示す。
図３９では、通話中継方式の種類として、通話中継サーバを使用しない「方式１」と、通話中継サーバを発信側、或いは、着信側のいずれか一方で１台使用する「方式２」と、通話中継サーバを発信側と着信側のそれぞれで１台の合計２台使用する「方式３」とがある。
方式１では、発呼側通信アダプタと着呼側通信アダプタとはＵＤＰを用いて通信を行う。これを「Ｕ直型」と呼ぶ。
方式２では、発呼側通信アダプタと通話中継サーバとの間をＨＴＴＰ、或いは、ＵＤＰを用いて通信を行う。また、着呼側通信アダプタと通話中継サーバとの間は、ＨＴＴＰ、或いは、ＵＤＰを用いて通信を行う。通話中継サーバを着呼側に用いて通話中継サーバと着呼側通信アダプタとの間をＨＴＴＰを用いて通信を行い、発呼側通信アダプタと着呼側通話中継サーバとの間をＵＤＰを用いて通信を行う場合を「−ＵＨ型」と呼ぶ。通話中継サーバを発呼側に用いて、発呼側通信アダプタと通話中継サーバとの間をＨＴＴＰによって通信を行い、発呼側の通話中継サーバと着呼側通信アダプタとの間をＵＤＰを用いて通信を行う場合を「ＨＵ−型」と呼ぶ。また、発呼側に通話中継サーバを用いて、発呼側通信アダプタと発呼側の通話中継サーバとの間をＵＤＰを用いて通信を行い、発呼側の通話中継サーバと着呼側通信アダプタとの間をＵＤＰを用いて通信を行う場合を「ＵＵ−型」と呼ぶ。また、着呼側に通話中継サーバを用いて、着呼側の通話中継サーバと着呼側通信アダプタとの間をＵＤＰを用いて通信を行い、発呼側通信アダプタと着呼側通話中継サーバとの間をＵＤＰを用いて通信を行う場合を「−ＵＵ型」と呼ぶ。
更に、方式３では、発呼側通信アダプタと発呼側通話中継サーバとの間をＨＴＴＰ、或いは、ＵＤＰを用いて通信を行い、発呼側通話中継サーバと着呼側通話中継サーバとの間はＵＤＰを用いて通信を行い、着呼側通話中継サーバと着呼側通信アダプタとの間は、ＨＴＴＰ、或いは、ＵＤＰを用いて通信を行う。発呼側通信アダプタと発呼側通話中継サーバとの間をＨＴＴＰを用いて通信を行い、着呼側通話中継サーバと着呼側通信アダプタとの間をＨＴＴＰを用いて通信を行う場合を「ＨＵＨ型」と呼ぶ。発呼側通信アダプタと発呼側通話中継サーバとの間をＵＤＰを用いて通信を行い、着呼側通話中継サーバと着呼側通信アダプタとの間をＨＴＴＰを用いて通信を行う場合を「ＵＵＨ型」と呼ぶ。発呼側通信アダプタと発呼側通話中継サーバとの間をＨＴＴＰを用いて通信を行い、着呼側通話中継サーバと着呼側通信アダプタとの間をＵＤＰを用いて通信を行う場合を「ＨＵＵ型」と呼ぶ。発呼側通信アダプタと発呼側通話中継サーバとの間をＵＤＰを用いて通信を行い、着呼側通話中継サーバと着呼側通信アダプタとの間をＵＤＰを用いて通信を行う場合を「ＵＵＵ型」と呼ぶ。
通信アダプタ間の通話において通話中継サーバの使用・未使用を判定するための方法を以下に示す。
判定方法の手順は、
（１）発呼側通信アダプタと着呼側通信アダプタの所属ドメインが一致するか判定する。
（２）所属ドメインが一致した場合は、図４２に示す“ドメイン内通話中継判定方法”より「通話中継サーバ」の使用有無を求める。
（３）所属ドメインが一致しない場合は、セッション管理サーバのサーバタイプ（汎用／ＩＳＰ）と図４３に示す“ドメイン外通話中継判定方法”より「通話中継サーバ」の使用有無を求める。
上記のように、様々なネットワークアドレス環境がある現状では、まず前提として、通信全てをＨＴＴＰを用いれば可能であるが、リアルタイム通信は、可能な限り、ＲＴＰなどのＵＤＰを利用したい。
例えば、ＵＤＰの利用が可能な場合として、以下のようなものがある。
・グローバルＩＰアドレス（固定、ＤＨＣＰ）を各通信アダプタが割り当てられる。
・同じドメイン内でプライベートＩＰアドレス（固定、ＤＨＣＰ）を各通信アダプタが割り当てられる。
・ファイアウォールに対して、利用したいＵＤＰポートのアクセスが可能なように設定ができる。
以上のような様々な場合に、できる限りＵＤＰの利用ができるように通信アダプタの端末接続タイプを規定して、呼制御設定処理中にその情報を相互交換することで、ＵＤＰ通信を可能とする。
以下に、本発明の実施の形態６において通信アダプタの接続条件を列挙する。
（１）グローバルＩＰアドレス（固定）
（２）プライベートＩＰアドレス（固定）
（３）グローバルＩＰアドレス（ＤＨＣＰ）
（４）プライベートＩＰアドレス（ＤＨＣＰ）
（２），（４）のプライベートＩＰアドレスとは、所属ドメイン内で割り当てられるＩＰアドレスのことである。
（ｉ）ドメイン内でさらにローカルにＳＯＨＯルータなどでＩＰアドレスを割り当てる場合。
（ｉ−１）ドメイン内でドメイン管理の通話中継サーバを設置している。
（ｉ−２）ドメイン内でドメイン管理の通話中継サーバを設置していない。
（ｉｉ）ドメイン内で割り当てられたプライベートＩＰアドレスをそのまま使用する場合。
（ｉｉ−１）ドメイン内でドメイン管理の通話中継サーバを設置している。
（ｉｉ−２）ドメイン内でドメイン管理の通話中継サーバを設置していない。
以上の（１）〜（４）と（ｉ−１），（ｉ−２），（ｉｉ−１），（ｉｉ−２）の条件の組み合わせから、以下に端末接続タイプ（Ａ〜Ｅ，Ｐ〜Ｒ）を、図４０に列挙する。図４０中の（１），（２），（３），（４）及び（ｉ−１），（ｉ−２），（ｉｉ−１），（ｉｉ−２）は、上記した（１）〜（４）及び（ｉ−１），（ｉ−２），（ｉｉ−１），（ｉｉ−２）に相当する。
図４０に示した端末接続タイプＡ〜Ｅ，Ｐ，Ｑ，Ｒごとの通信アダプタと通話中継サーバとの接続方式を、図４１に示す。
図４１において、ＩＳＰ ＩＤ（インターネット・サービス・プロバイダを識別するための識別情報）により通信アダプタが所属するプライベートＩＰアドレスエリアが定まる。このエリア内には、複数のセッション管理サーバがある場合があり、このセッション管理サーバごとにエリアＩＤが対応する。複数のエリアを持つＩＳＰには、複数のＩＳＰＩＤを与える。通信アダプタには、Ａ〜Ｅのタイプのどれかを設定し、サーバ群に報告する。ＩＳＰ運営サーバに所属する通信アダプタは、Ａ〜Ｅタイプのどれかになる。汎用通話中継サーバに所属すると、タイプＡ〜Ｅは、Ｐ，Ｑ，Ｒにサーバ内処理で置き換えられる。
図４０のタイプ「Ｂ」は、図４１の（Ｂ）に示されているような接続形態で通信アダプタとルータと通話中継サーバ（同位置にセッション管理サーバも設置する）とインターネットが接続されている。
また、図４０のタイプ「Ｃ」は、図４１に示す（Ｃ）のように、通信アダプタと通話中継サーバ（同位置にセッション管理サーバも設置する）とルータとインターネットが接続されている。
また、図４０のタイプ「Ｄ」は、図４１の（Ｄ）に示すように、通信アダプタとルータと通話中継サーバ（同位置にセッション管理サーバも設置する）とインターネットとＤＨＣＰサーバが接続されている。
図４０のタイプ「Ｅ」は、図４１の（Ｅ）のように、通信アダプタとルータと通話中継サーバ（同位置にセッション管理サーバも設置する）とインターネットとＤＨＣＰサーバとが接続される。
また、図４０のタイプ「Ａ」は、図４１の（Ａ）のように、通信アダプタを接続するルータが更に上の階層のルータに接続され、上の階層のルータと通話中継サーバがインターネットに接続されている。タイプ「Ａ」の場合、ルータが階層化されていて、下位の階層のルータに通信アダプタが接続されているので、この場合の通信アダプタに設定されるＩＰアドレスは、ローカルＩＰアドレスと呼ぶものとする。
また、図４０のタイプ「Ｑ」とタイプ「Ｒ」は、ドメイン内でドメイン管理の通話中継サーバを設置していないので、図４１の（Ｑ），（Ｒ）のように、通信アダプタは、ルータとＤＨＣＰサーバとセッション管理サーバ（同位置にセッション管理サーバも設置する）とインターネットとに接続される。
また、図４０のタイプ「Ｐ」は、ドメイン内でドメイン管理の通話中継サーバを設置していない。更に、ドメイン内で割り当てられたプライベートＩＰアドレスをそのまま使用するので、通信アダプタは、図４１（Ｐ）のように、インターネットに接続される。更に、タイプ「Ｐ」の場合、ドメイン内で更にＳＯＨＯルータの直下に設置される場合もあるので、ＩＰアドレスを割り当てられる場合にドメイン内でドメイン管理の通話中継サーバを設置していない場合が考えられる。この場合を通信アダプタは、図４１の（Ｐ）のように、インターネットに接続される。
次に、端末接続タイプ毎の中継方式判定方法を、図４２〜図４３に図示した表で示す。
図４２は、同じドメイン内同士の通信における中継方式判定方法を示す。
図４２中のＡ〜Ｅは、図４０のＡ〜Ｅに相当する。また、図４２中の［１］，［２］は、図３９の［１］，［２］に相当する。
図４２の縦軸に発信側の通信アダプタのタイプを示す。横軸に着信側の通信アダプタのタイプを示す。
図４２において、同じドメイン内に発呼側と着呼側の通信アダプタが設置されて、これらの通信アダプタの間で通話を行う場合には、ドメイン外の通話中継サーバは用いないため、発信側の通信アダプタと着信側の通信アダプタのタイプが同じであるときは、［１］の中継方式によって通話を行う。発信側と着信側の通信アダプタとのタイプのどちらかがＮＡＴルータの直下に設置されてローカルＩＰアドレスを割り当てられる場合は、［２］の中継方式によって通話を行う。
図４３は、同じドメイン内同士ではない通信における中継方式判定方法を示す。
図４３中のＡ〜Ｅ及びＰ〜Ｒは、図４０のＡ〜Ｅ及びＰ〜Ｒに相当する。また、図４３中の［１］〜［３］は、図３９の［１］〜［３］に相当する。
図４３において、縦軸は発信側の通信アダプタのタイプを示し、横軸は着信側の通信アダプタのタイプを示す。
また、方式が［２］である場合には、通話中継サーバに発信側のものを使用するのか、着信側のものを使用するのかを区別するため、（発信側）又は（着信側）を明記している。
セッション管理サーバは、呼制御処理において、発呼側と着呼側の各通信アダプタの端末接続タイプの情報を得て、図４２，図４３の表に基づいて、通話中継方式を判定し、各通信アダプタにその方式に関する情報を送信する。通話中継サーバを必要とする場合には、セッション管理サーバが、各通信アダプタに対して、通話中継サーバのＩＰアドレス、及び、ＨＴＴＰかＵＤＰかのどちらかの指定について報告する。
図４５〜図５３において、図４４のインターネット電話ネットワークシステム構成における上記各通信アダプタの接続タイプに応じた呼制御のメッセージ送受信手順を示す。
なお、ＮＡＴルータ直下に設置された通信アダプタについては、端末接続タイプをＡ，Ｐとしており、音声データ送受信をＨＴＴＰにより行っていたが、ＮＡＴルータに対して、（静的）ＮＡＴ設定を行い、使用するＵＤＰポート番号を経由するＵＤＰによる音声データを直接通信アダプタに対して送受信させることが可能である。つまり、通話中継サーバから、ＮＡＴルータまでＵＤＰにより音声データを送受信させることができるため、通信アダプタは、端末接続タイプＡ，Ｐではなく、ＮＡＴルータの位置に相当する端末接続タイプＢ，Ｃ，Ｄ，Ｅ、Ｑ，Ｒとして設定すればよい。これにより、ＮＡＴルータ直下に接続しておいても、ＵＤＰによる音声データ送受信が可能になり、通話品質が向上する。
図４５は、図３９に示した方式３の「ＨＵＨ型」のメッセージ送受信手順を示す図である。
「ＨＵＨ型」のメッセージ送受信手順では、図４５に示す（１）〜（７）の手順によってメッセージを送受信する。以下に、（１）〜（７）の手順を示す。
なお、図４５に示す「Ｈ」はＨＴＴＰによる通信であり、「Ｕ」はＵＤＰによる通信を示すものである。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／中継サーバ指定
（６）発信側発呼／話中手続き／中継サーバ指定
（７）両側サーバによる通話中継処理
図４６は、図３９の方式２の「−ＵＨ型」のメッセージ送受信手順を示す図である。
「−ＵＨ型」では、以下に示す（１）〜（７）の手順によってメッセージを送受信する。
なお、図４６の「Ｈ」はＨＴＴＰであり、「Ｕ」はＵＤＰを示す。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／中継サーバ指定
（６）発信側発呼／話中手続き／中継サーバ指定
（７）受信側サーバによる通話中継処理
図４７は、図３９の方式２の「ＨＵ−型」のメッセージ送受信手順を示す図である。
「ＨＵ−型」のメッセージ送受信は、以下に示す（１）〜（７）の手順によってメッセージ送受信を行う。
図４７に記載した「Ｈ」はＨＴＴＰを示し、「Ｕ」はＵＤＰを示す。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／中継サーバ指定
（６）発信側発呼／話中手続き／中継サーバ指定
（７）発信側サーバによる通話中継処理
図４８は、図３９の方式３の「ＵＵＨ型」によるメッセージ送受信手順を示す図である。
「ＵＵＨ型」は、以下に示す（１）〜（７）の手順によってメッセージを送受信する。
図４８に記載した「Ｈ」はＨＴＴＰであり、「Ｕ」はＵＤＰである。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／中継サーバ指定
（６）発信側発呼／話中手続き／中継サーバ指定
（７）両側中継サーバによる通話中継処理
図４９は、図３９の方式３の「ＨＵＵ型」によるメッセージ送受信手順を示す図である。
「ＨＵＵ型」のメッセージ送受信処理は、以下に示す（１）〜（７）の手順によってメッセージを送受信する。
図４９の「Ｈ」はＨＴＴＰを示し、「Ｕ」はＵＤＰを示す。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／中継サーバ指定
（６）発信側発呼／話中手続き／中継サーバ指定
（７）両側サーバによる通話中継処理
図５０は、図３９の方式１の「Ｕ直型」によるメッセージ送受信手順を示す図である。
「Ｕ直型」のメッセージ送受信処理は、以下に示す（１）〜（７）の手順によってメッセージを送受信する。
図５０に記載した「Ｕ」はＵＤＰである。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／直接通話を指定
（６）発信側発呼／話中手続き／直接通話を指定
（７）直接通話処理
図５１は、図３９の方式２の「ＵＵ−型」によるメッセージ送受信処理の手順を示す図である。
「ＵＵ−型」のメッセージ送受信処理は、以下に示す（１）〜（７）の手順によってメッセージを送受信する。
図５１に記載した「Ｕ」はＵＤＰを示す。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／中継サーバ指定
（６）発信側発呼／話中手続き／中継サーバ指定
（７）発信側サーバによる通話中継処理
図５２は、図３９の方式２の「−ＵＵ型」によるメッセージ送受信処理の手順を示す図である。
「−ＵＵ型」は、以下に示す（１）〜（７）の手順によってメッセージを送受信する。
図５２に記載した「Ｕ」はＵＤＰである。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／中継サーバ指定
（６）発信側発呼／話中手続き／中継サーバ指定
（７）受信側サーバによる通話中継処理
図５３は、図３９の方式３の「ＵＵＵ型」によるメッセージ送受信処理の手順を示す図である。
「ＵＵＵ型」は、以下に示す（１）〜（７）の手順によってメッセージの送受信処理を行う。
図５３に記載した「Ｕ」はＵＤＰである。
（１）待ち受けセッション維持
（２）発信側セッション管理サーバへの発呼依頼
（３）受信側セッション管理サーバへの接続依頼
（４）受信側端末通話状況返信
（５）受信側発呼手続き／中継サーバ指定
（６）発信側発呼／話中手続き／中継サーバ指定
（７）両側中継サーバによる通話中継処理
実施の形態７．
実施の形態７では、指定通知サーバが遠隔保守管理サーバの機能を有して遠隔保守管理サーバとして動作する例について、以下に説明を行う。
図５４に示すように、通話アダプタがインターネットに接続されて電源がオンになると、一定周期（例えば、１日に１回くらいのペース）にて、遠隔保守管理サーバに対して生存報告メッセージ（製造番号、ＩＰアドレス、正常に動作しているかどうかの確認情報）を送信する。
遠隔保守管理サーバは、その生存報告メッセージの中で新規のものを確認し、顧客管理データベースに登録を行う。既に登録済みのものを含めて、生存報告が正常なものかどうか確認する。この生存報告の内容としては、通話アダプタがハードウェアの一部が故障している点などを付加する事ができ、このような異常状態が判明すると、指定通知サーバを管理している運営管理者がユーザに対して、通話アダプタ装置故障の連絡、代品の交換等の手続きを開始することができる。
生存報告メッセージとして、ＨＴＴＰのＧＥＴメソッドを利用した場合に対する応答メッセージとして、指定通知サーバ等が正常に動作しているかどうかの情報を返送することができる。この場合、通話アダプタ側に、指定通知サーバやセッション管理サーバなどの異常を知らせることで、通話アダプタの表示装置にエラー表示を行わせたり、受話器から「ただいま、サーバ側の故障中にて公衆回線にておつなぎいたします。」などとユーザへ通知したりすることが可能である。
一方で、指定通知サーバやセッション管理サーバについて、ハードウェアが故障した場合に備えて、冗長系を実装しておくことも可能である。この場合、基本的に使用する指定通知サーバやセッション管理サーバをプライマリサーバとすると、バックアップとして利用できるものをセカンダリサーバとして用意しておく。さらに、上記指定通知サーバへの生存報告メッセージの応答メッセージとして、各サーバのＩＰアドレスを知らせるときに、プライマリ側とセカンダリ側の両者について、送信することが可能である。冗長系は、プライマリとセカンダリだけでなく、３つ以上のサーバから構成されていてもかまわない。プライマリが故障した場合に、セカンダリに置き換わる様子を図５５，図５６に示す。
また、本実施の形態では、本インターネット電話ネットワークシステムを用いて、課金業務を行う場合を想定する。この課金業務のために、図５４に示すように、顧客管理データベース７１０を用意する。この顧客管理データベース７１０では、サービス料金の支払い状況の管理を行い、不払いが確認された場合、生存報告メッセージを指定通知サーバが受けると、ＨＴＴＰ中継のセッション管理サーバ側の受付を不能にするか、生存報告メッセージの応答メッセージにより通話アダプタを直接動作不能にするかの対応を行う。さらに、顧客が料金を支払い、顧客管理データベースへ支払い済みの登録がなされると、生存報告メッセージが指定通知サーバへ再度送信されてきたときに、上記の使用不可能の設定を解除する。
また、指定通知サーバへの生存報告メッセージの別の目的の利用として、通話アダプタのソフトウェアの版管理がある。通話アダプタのソフトウェアのバージョンアップが必要になったら、顧客管理データベース７１０を元に、ソフトウェア更新モジュールサーバ８１０のダウンロードバージョンアップ処理を指定通知サーバから遠隔操作によりスタートさせる。或いは、顧客に電話機によりバージョンアップコマンドを入力してもらい、通話アダプタにダウンロードさせる。なお、前者の場合には、管理者側の都合で、強制的に通話アダプタのソフトウェア更新処理を行うために、その処理中は、ユーザが利用できないことになる。このため、ユーザが通話中であれば、そのソフトウェア更新処理を通話操作が終了するまで遅らせるようにする。また、更新処理を行う際に、これから更新処理を行う旨を表示装置や発音装置によりユーザに連絡し、ユーザの都合により更新処理を行いたくない場合に、その更新処理を実行させない操作が可能なユーザインタフェースを通話アダプタは備える。
このように、ユーザのもつ通話アダプタに対して、システム管理者が指定通知サーバへのアクセスを利用して遠隔からダウンロード操作を行えるが、同様のしくみを利用して、通話アダプタ上で、自己診断プログラムを実行させ、その結果情報を指定通知サーバ側へ送信させることもできる。同様に、その結果情報に基づいてより詳細な情報を得るためのオプション的な自己診断プログラムを遠隔から実行させたり、ユーザに対して故障情報を知らせたりすることが可能である。
実施の形態８．
本実施の形態の呼制御では、通話アダプタは、呼制御を管理するセッション管理サーバや通話中継サーバへの通信が行えない場合、実質的にＩＰ回線による電話をかけることができない。そこで、ＩＰ回線による通話が不可能な場合に、ＩＰ回線による通話ができないことを通話アダプタや電話機のユーザインタフェースを利用してユーザに伝えるようにする。電話機の受話器からＩＰ回線による通話ができないことを人工音声により伝える方法もその一つである。人工音声とは、あらかじめ人間がメッセージを読み上げたものを録音しておき、そのデジタル情報をサーバや通話アダプタのメモリに記憶しておき、再生させる方法や、メッセージの文章テキストデータから、音声を人工的に合成して発音させる方法などがある。通話アダプタの表示装置により同様に伝えるようにすることもできる。また、この通話アダプタには、ＩＰ回線以外に、公衆回線経由の通話機能も加えて実装しておくことができ、ＩＰ回線での通話ができなかった場合に、自動的に公衆回線経由の通話を開始するようにもできる。
図５７に示すように、セッション管理サーバは、管理している通話中継サーバの通話セッション数を常にカウントしているので、通話中継サーバの通話中継可能な容量限界まで通話中継処理を行っていることを認識できる（図５７の（１））。この場合には、これ以上はＩＰ回線経由の通話ができないということで、上記のようにＩＰ回線通話不可能をユーザに知らせたり、公衆回線経由の通話に切り替えたりする（図５７の（２））ように実装することができる。
ここで、ユーザに通話アダプタの異常時等の警告メッセージについてまとめておく。
（１）ＬＥＤや液晶ディスプレイやブザー等での異常状態等を知らせる。
（２）通話中に、受話器から警告等のメッセージを再生する。以下に例を示す。
（Ａ）設定が誤っています。設定をやり直してください。
（Ｂ）ネットワークが込んでいますので、公衆でおつなぎ致します。
（Ｃ）中継局が込んでいますので、公衆でおつなぎ致します。
（Ｄ）ＩＰ電話をかけますが、ネットワークが込んでいますので、音質が悪い場合がございます。
（Ｅ）ネットワークが急激に込んできたため、一度お切り致します。おかけ直し下さい。
（Ｆ）ネットワークが急激に込んできたため、通信経路を変更致します。しばらくお待ち下さい。（処理時間経過）通話ができるようになりました。
実施の形態９．
通話アダプタは、呼制御を管理するセッション管理サーバや通話中継サーバへの通信を本発明方式ではＨＴＴＰを利用して実現している。このため、通信処理の開始時には、図５８に示すように、ＴＣＰの通信処理を行っている。通話アダプタ１１０は、各サーバに対してＨＴＴＰのクライアントからサーバへの通信処理のために、ＴＣＰの接続処理をｃｏｎｎｅｃｔというソケット関数を用いて最初に行う。ｃｏｎｎｅｃｔ関数の呼び出し待ち時間にタイムアウト値を設け、タイムアウト値を越える待ち時間が発生した場合に、現状のｃｏｎｎｅｃｔ関数実行を強制終了し、改めてｃｏｎｎｅｃｔ関数実行をやり直す。また、ｃｏｎｎｅｃｔ関数のやり直し回数にも上限値を設け、無限回数やり直すのではなく、上限値を超えた場合に、エラー処理を行う。ＴＣＰのソケット関数によるＨＴＴＰメッセージの送受信状況を図５９に示す。図５９は、ＨＴＴＰデータ送受信処理とソケット関数呼び出しの関係を示している。
ＴＣＰ通信のための最初の接続処理は、通話アダプタ側がクライアントとして、ｃｏｎｎｅｃｔ関数を呼び出すことで開始される（図５９の「（１）ＴＣＰの接続要求」）。このとき、ｃｏｎｎｅｃｔ関数のブロッキングモード（「ブロッキングモード」とは、サーバ側からの応答があるまではクライアント側は対応を待ち続けて、次の処理に進まないことをいう）を使用すると、ＴＣＰ接続が成立するまで（図５９の「（２）ＴＣＰの接続受理」）、ｃｏｎｎｅｃｔ関数は終了せずプログラム実行としては、ブロックされ停止状態となる。比較的短い時間でＴＣＰ接続が成立すれば問題ないが、ネットワーク上の原因など何らかの要因により、このＴＣＰ接続成立までに非常に長い時間がかかることがある。このような場合に、一度ｃｏｎｎｅｃｔ関数の実行を強制終了させ、改めてｃｏｎｎｅｃｔ関数の実行をやり直すと、すぐにＴＣＰ接続が成立する場合が多い。そこで、ｃｏｎｎｅｃｔ関数の実行に、タイムアウト値を設定しておき、そのタイムアウト値を越える場合に、ｃｏｎｎｅｃｔ関数の実行を中断及び強制終了し、改めて、ｃｏｎｎｅｃｔ関数の実行をやり直すようにすることで、処理が長く待たされることなく、確実にＴＣＰ接続が成功するようになる。このやり直しは、必ずしも１回だけでなく、やり直してもまだタイムアウト値を越えるような待ち時間となる場合に、また繰り返すようにできる。このようにすることで、失敗時の復旧処理を強化することになる。一方では、無限回やり直すことも意味はないので、やり直し回数に一定の上限値を設け、その上限値までＴＣＰ接続のやり直しを行うが、その上限値を越えるときは、ネットワーク等に何らかの障害が発生したと考えて、エラー処理を行うべきである。
さらに、上記のＴＣＰ接続開始処理のタイムアウト値ややり直し回数の上限値について、通話アダプタの起動時において、一定の定数としておき、比較的ＴＣＰ接続開始処理の短時間での成功率が高い場合には、タイムアウト値を短く、やり直し回数も少なくすることで、エラー発生が仮に起こったとしても、短時間でエラー発生が認識できる。一方で、成功率が低い場合には、より確実にＴＣＰ接続が行えるように、タイムアウト値を長く、やり直し回数も増加させるほうが望ましい。そこで、実際のＴＣＰ接続開始処理の経過時間ややり直し回数を測定しつつ、タイムアウト値ややり直し回数を最適な値に自動的に調整する機能を実装できる。これにより、最適なタイムアウト値ややり直し回数の調整作業に人手の作業を省くことが可能となる。
実施の形態１０．
インターネット経由の音声データ送受信による通話処理では、その通話品質を最も左右するのが、実際のインターネット経路のデータトラフィックがどの程度の混み具合であるかどうかである。そこで、特定の通話経路について、データ到達にかかる遅延時間を常に監視し、通話品質に影響がないレベルかどうかを調べる。それとともに、明らかに通話品質に影響を与える遅延が発生していることが確認されたら、通話品質が悪化したことをユーザに通話アダプタの表示装置等を用いて知らせることができる。
全国各地に設置されたセッション管理サーバは、それぞれのセッション管理サーバのＩＰアドレスをデータベースとして記憶しており、定期的に、特定のセッション管理サーバ（通話中継サーバをほぼ同位置にあると仮定している）間にて、一般的な通信遅延時間をｐｉｎｇやｔｒａｃｅｒｔというＷｉｎｄｏｗｓ（「Ｗｉｎｄｏｗｓ」は、マイクロソフト社のオペレーティングシステムである）やＵｎｉｘ（「Ｕｎｉｘ」は、ＡＴ ＆ Ｔベル研究所が開発したオペレーティングシステムの名称である）系のＯＳ上のコマンドにて、測定することが可能である。また、別途、本ＩＰ電話ネットワークシステムにて使用するＵＤＰやＨＴＴＰ等の音声パケットを実際に送受信させ、その遅延時間を測定するソフトウェアを作成し、それにより測定することも可能である。ＯＳ上のコマンドやソフトウェアによって、発呼側と着呼側の各アダプタが所属する２箇所のセッション管理サーバ間の直接の経路遅延を求めることができるとともに、他の第３のセッション管理サーバへ迂回した場合の経路遅延を求めることもできる。この結果、２箇所のセッション管理サーバ間の経路遅延よりも、迂回した場合の経路遅延の合計のほうが、より短時間である調査結果が得られた場合に、迂回経路を選択して、通話中継サーバの経路として、第３の地点の通話中継サーバを経由するように音声データ中継経路の設定へ変更することが可能である。
図６０は、インターネット経路遅延状況調査による混雑度の確認処理を説明する図である。
図６０では、東京大阪間の総遅延が１００ｍｓｅｃ、東京千葉間の総遅延が８００ｍｓｅｃ、東京千葉間の総遅延が２００ｍｓｅｃという調査結果が出ている。このため、東京大阪間と東京千葉間とを接続する場合の総遅延が大阪千葉間を接続する場合の総遅延よりも遅延が短くなるため、大阪千葉間の通信経路を、東京大阪間と東京千葉間との通信経路に置き換えている。この第３の中継拠点の選択も、全国に配置されるセッション管理サーバが数多くあれば、遅延時間の総和を計算し比較して、最適なものを選択することで、より快適な通信状況を確保することができる。当然のことながら、数多くの通信経路が同時に存在することになるため、可能な限り、それぞれの通信経路が一箇所に集中することなく、適宜分散するように制御することが可能である。
なお、各セッション管理サーバ及び通話中継サーバ間のネットワークトラフィック状況を図６０に示すような図を表示させるソフトウェアを実装することで、システム管理者が目視によりネットワーク輻輳状況を把握することができ、システム管理者が直接すいているネットワーク経路へ音声データ送受信経路が割り当てられるようにセッション管理サーバに第３の中継拠点の通話中継サーバの指示を行うことができる。これは、自動的なサーバ上のプロセス処理だけでは、時間的余裕のない緊急時に有効な操作ができる。
図６０では、総遅延を、例えば、「大阪−千葉間総遅延８００ｍｓｅｃ」と通信経路の近くに文字を表示していた。しかし、遅延速度別に通信経路を色分けしたり、点滅させたりすることも可能である。
管理者は、頻繁に通話障害が発生する場合には、既に提供してきたＩＰ電話ネットワークシステムを見直し、再設計、再構築を行う必要がある。これから、管理者への警告機能は重要である。以下に、管理者への警告内容を整理しておく。
（１）サーバ故障に対して基本的に二重系にて対応するが、故障時に自動復旧を行い、その点について、管理者へ自動メッセージ送信やログ出力などで連絡する。
（２）ＩＰ電話をかけようとして、サーバへのアクセスがタイムアウトになった場合等が多く、一定数以上公衆でかけざるをえない場合、管理者へ自動メッセージ送信やログ出力などで警告をあげる。
（３）ＩＰ電話をかけている状態で、一定以上のトラフィックがあり多くのユーザの通話品質に問題がある場合、管理者へ自動メッセージ送信やログ出力などで警告を上げる。
（４）ＩＰ電話をかける場合に、通常の通話中継サーバの音声データ送受信経路がほとんど利用できず、頻繁に通話経路変更があり、これが一定値を越える場合、管理者へ自動メッセージ送信やログ出力などで警告を上げる。
実施の形態１１．
セッション管理サーバ及び通話中継サーバは、企業や学校などの団体の限定された地区に設置することも可能である。この場合、特定の地区における電話に関しては、外線と異なり、地区内で利用可能な内線電話番号体系を設定することが多い。こうした内線電話番号に対して、本通信アダプタのＩＰアドレスや識別子へ変換する変換テーブルをデータベースとして、一括に管理できると、便利である。そこで、図６１に示すように、この変換テーブルをセッション管理サーバ上に実装する（図６１の内線電話番号データベース７２０）ことで、各通信アダプタから内線電話番号が入力された場合に、セッション管理サーバへ通信アダプタから内線電話番号情報を送信し、セッション管理サーバ上で、通話相手の通信アダプタを特定し、それから、特定した通話相手の通信アダプタに対して、図６２に示す（１）〜（６）の手順で呼制御処理を行う。
図６２を用いて内線電話呼制御方式の手順を説明する。
発呼側通信アダプタは内線電話番号が入力されると、入力された電話番号とともに、発呼メッセージをセッション管理サーバへ送信する（２）。セッション管理サーバは、送信された内線電話番号を元に、内線電話番号データベース７２０を参照し、通信相手を特定する（３）。着呼側通話アダプタから着呼メッセージ取得処理が行われると（１）、セッション管理サーバは、着呼メッセージを着呼側通信アダプタに返す。また、発呼側通信アダプタに対しても発呼メッセージの応答を行う（５）。（４）と（５）の後の処理は、通常のＵＤＰ直接通信による通信アダプタ間通話処理と同じように、発呼側と着呼側とで通話を行う（６）。もし、セッション管理サーバで内線電話番号データベース７２０を参照しても、通話相手の通信アダプタを特定できない場合は、検索が失敗したことを発呼側へ報告する（３）。発呼側通信アダプタは、ユーザに対して「おかけになった番号は、現在使われておりません。」や「番号管理システムが故障しております。」等のメッセージを伝える。
実際に内線番号対応の呼制御方式を導入する導入形態としては、ＰＢＸがない場合（図６３）、ＰＢＸ１３０がある場合（図６４，図６５）それぞれにいくつか例がある。
図６３に示したＰＢＸがない場合の導入形態では、内線電話は、拠点内においては域内Ｕ直型（「Ｕ直型」は、実施の形態６の図３９で説明した方式１の通話中継サーバ未使用のＵＤＰを用いたメッセージ送受信処理を示すものである）。拠点間は、域外間通話ＵＵＵとなる（「ＵＵＵ」とは、実施の形態６の図３９に示した方式３の通話中継サーバを２台使用する通信アダプタと通話中継サーバ間及び通話中継サーバと通話中継サーバ間とをＵＤＰを用いてメッセージ送受信処理を行うことを示すものである）。内線番号の判定は、直接公衆回線網に繋がるので、拠点間は［７−場所番号−内線番号」というようにプレフィックス「７」をつけて発信する。セッション管理サーバでは、プレフィックスを外して、「場所番号−内線番号」の電話番号情報を送信する。
次に、ＰＢＸがある場合の導入形態を説明する。
図６４では、ＰＢＸ内線側へ通信アダプタを設置する形態を示している。
図６４の場合、拠点内はＰＢＸによる内線であるが、拠点間は域外間通話「ＵＵＵ」となる（「ＵＵＵ」は、実施の形態６の図３９の方式３の「ＵＵＵ型」を示すものである）。電話番号判定の処理は、拠点間は「７−場所番号−内線番号」というように、プレフィックス「７」で、他拠点へのＩＰ電話をかける。
次に、ＰＢＸ外線側へ通信アダプタを設置する導入形態について説明する。
図６５では、拠点内はＰＢＸによる内線であるが、拠点間は域外間通話「ＵＵＵ」となる（「ＵＵＵ」は、実施の形態６の図３９の方式３の「ＵＵＵ型」を示すものである）。電話番号の判定処理は、拠点間は「０−場所番号−内線番号」というように、外線プレフィックス「０」で、他拠点へのＩＰ電話をかける。拠点間の内線と公衆外線との番号区別がないので、全ての内線番号に対応するアドレスと外線番号に対応するアドレスとをテーブルに記憶させて、セッション管理サーバにそのテーブルを設置するようにする。或いは、プレフィックスとして「＊」の記号を用いるなどの特殊処理を行う必要がある。セッション管理サーバへは、プレフィックス「＊」を外して電話番号を送信する。
なお、セッション管理サーバ上の変換テーブルデータベースについて、このセッション管理サーバ上でＨＴＴＰサーバプロセスを動作させ、ネットワーク上に接続された他のパソコンからＷｅｂブラウザによりそのデータベース、つまり、内線電話帳テーブルの保守作業を行うことが可能である。
実施の形態１２．
図６６に示すように、特定の団体内で設置されている通信アダプタにおいては、複数の通信アダプタの呼制御をそのセッション管理サーバにて管理しているので、外線としてかかってきたＩＰ回線経由の通話に対して、１台の通信アダプタが通話中であっても、代替可能な他の通信アダプタへ自動的に電話呼出を転送することが可能である。このそれぞれの通信アダプタを相互に代替可能なものをグループとしてまとめて、データベースとして記憶する記憶部をセッション管理サーバは備えておく（図６６のグループ外線ＤＢ７４０，７５０）。
図６６では、東京から大阪へＩＰネットワークを介す電話をかける場合に大阪の通信アダプタ「＃１」が使用中である場合は、大阪のセッション管理サーバが東京の通信アダプタに対して代替可能なアダプタ「＃２」を使用するように通知を行い、東京の通信アダプタが大阪の通信アダプタ「＃２」に対して接続を試みる。又は、大阪のセッション管理サーバが東京のセッション管理サーバへ通信アダプタ「＃１」が使用中であるため、通信アダプタ「＃２」を使用するように通知を行い、東京のセッション管理サーバから東京の通信アダプタに対して通信アダプタ「＃２」を使用するように通知しても構わない。但し、一般の公衆回線網を用いての第２のルートでの再接続を試みることは不可能である。また、グループに所属している通信アダプタ全てが使用中である場合は、通話中となる。
実施の形態１３．
既に、実施の形態１にて示したように、通信アダプタからセッション管理サーバへのＴＣＰ接続の状態について、通信アダプタは認知していないにもかかわらず、ＴＣＰ接続がインターネット経路上のどこかで切断されてしまう場合があることを説明した。ＴＣＰ接続がインターネット経路上のどこかで切断されてしまうことを通信アダプタが確認できるようにするため、図６７に示すように、セッション管理サーバは、通信アダプタから「ＨＴＴＰ ＧＥＴメソッド」の受信に対して、「ＨＴＴＰ ＧＥＴステータス応答」をボディ部を除いて返信する。ボディ部は、セッション確立要求があったときに返す。セッション管理サーバは、セッション確立要求があるまで「Ｋｅｅｐ−Ａｌｉｖｅ情報」をボディ部の一部として一定周期で通信アダプタに返す。通信アダプタは、ボディ部（Ｋｅｅｐ−Ａｌｉｖｅ情報）がタイムアウトになっても届かない場合、セッション管理サーバに対して再接続を要求する。このとき、ＧＥＴメソッドに再接続であることを知らせる情報を付加しておくと、タイムアウトから少し遅れて着信情報が届いた場合には、セッション管理サーバは、再接続の要求であることを確認してから送るはずであった着信情報を、ボディ部として応答することができる。
一方、通信アダプタは、音声情報についてもＨＴＴＰ、つまりＴＣＰ接続を確保して送受信することがあるので、同様に、ＴＣＰ接続が切断されてしまうと、音声情報の送受信が滞ってしまうことになる。
そこで、図６８に示すように、音声情報の送受信についても、音声情報送受信経路上のどこかで、ＨＴＴＰを用いている場合には、音声情報が存在するかしないかに係らず、一定周期で同じＴＣＰ接続上にて、Ｋｅｅｐ−Ａｌｉｖｅ情報を送受信する。これにより、音声情報の最終的な送信先である通信アダプタにてタイムアウトを検出した場合に、そのＴＣＰ接続の再接続を行うようにすることで、音声情報の送受信の途絶えを防ぐことが可能となる。
また、音声情報の送受信は、通信中継サーバを１段あるいは２段経由してなされる場合もあり、このときは、音声情報の送信先の通信アダプタのみＴＣＰ再接続を行うことに加え、音声情報の送信元の通信アダプタ側もＴＣＰ再接続を行う必要がある。実施の形態１での電話機のオフフック情報を通信先の通信アダプタに伝えるのと同様に、このＴＣＰ再接続の指示は、セッション管理サーバを経由することで、音声情報の送信元の通信アダプタに対して、伝えることが可能である。こうして、ＴＣＰ再接続処理が音声情報の送信先と送信元の通信アダプタの両側でなされることで、インターネット上のＴＣＰ接続の切断があっても、音声情報の通信を継続して行うことができる。
図６８では、通信アダプタ１２０は、音声情報の間に一定周期で「Ｋｅｅｐ−Ａｌｉｖｅ情報」を挿入し、通信アダプタ１１０に送る。通信アダプタ１１０は、通信アダプタ１２０からの「Ｋｅｅｐ−Ａｌｉｖｅ情報」を待つ。通信アダプタは、「Ｋｅｅｐ−Ａｌｉｖｅ情報」がタイムアウトになっても到着しない場合は、発呼側の通話中継サーバ３１０に対してＴＰＣの再接続を要求するとともに、セッション管理サーバ経由で通話先の通信アダプタ１２０に対しても、通話中継サーバを再接続するように指示を行う。
実施の形態１４．
上記通信アダプタは、音声データの送受信処理を行う。音声データは、通信アダプタに接続されている電話機やマイクスピーカ装置等から入力された音声アナログデータを通信アダプタ内に実装されているアナログデジタル変換装置或いはソフトウェアにより音声デジタルデータに変換し、さらに通信アダプタ内に実装されている音声コーデック（音声符号化復号化装置或いはソフトウェア）により、圧縮された音声データに変換される。
この音声コーデックが音声符号化復号化する単位時間分の圧縮音声データを音声フレームデータを呼ぶ。ＩＰネットワークに音声データを送信するときには、この音声フレームデータが１つ以上蓄積されて１つのＩＰパケットとして構成する。音声フレームデータが１つのＩＰパケットにいくつ格納されるかについては、ＩＰネットワークのトラフィック状況及び遅延時間による品質を考慮し、通信アダプタが適切な蓄積時間を指定することで決定される。例をあげると、音声フレームデータの時間長が２０ｍｓｅｃ，蓄積時間を６０ｍｓｅｃのようになり、この場合、１つのＩＰパケットに３つの音声フレームデータが格納されることになる。
図６９に示すように、従来の方法では、２０ｍｓｅｃ経過すると音声フレームデータが生成され機械的にＩＰパケットに格納され、蓄積時間６０ｍｓｅｃが経過するごとに自動的にＩＰパケットが送信されていた。
一方で、無音圧縮という方式があり、ある一定のレベル以下の音量では、無音状態とみなして、あえて音声フレームデータを生成しないようにして、不必要なＩＰパケットを送信しないようにする。
ここで、音声コーデックは、有音状態が続いていて、無音状態となったときに、有音が終端であることを示す音声フレームデータを生成する場合が多い。この有音が終端であることを示す音声フレームデータは、受信側の音声コーデックにおいて、その情報を元に自然な音声減衰消失を再現できる。一方では、無音状態から有音状態に変わる最初の音声フレームデータには、マーカビットというビット情報をオンにすることで、有音状態の再開を受信側の音声コーデックに示すことで、自然な音声の立ち上がりが再現できる。さらに、受信側では、音声データが到着していない無音状態のときに、適当なノイズを再生させることで、自然な背景音を利用者に与えるようにしている。
無音圧縮方式をサポートした音声コーデックにおいて、上記の有音が終端であることを示す音声フレームデータ及び、有音が開始されるマーカビットがオンとなった音声フレームデータを受信側にて受け取ることは、有音状態と無音状態との間の自然な移行を再現できる。逆に有音が終端であることを示す音声フレームデータ及び、有音が開始されるマーカビットがオンとなった音声フレームデータを受信側の音声コーデックがどちらでも受け取りに失敗すると、有音の立ち上がりが欠損したり、不快なノイズが発生したり、有音の終了時に音の乱れが発生したりする。
以上から、図７０に示すように、この従来の方法に従うと、ＩＰパケットの大幅な送信遅延揺らぎが発生した場合、上記の有音が終端であることを示す音声フレームデータを含むＩＰパケットだけが、それまでの有音状態の音声フレームデータから時間的にかなり遅れて到着すると、受信側の音声コーデックの無音圧縮の再生処理に影響を及ぼし、ＩＰパケットが欠損しないまでも、有音の終了時に音の乱れが発生したりする。
さらに、図７１に示すように、このようにその時点までの有音が終端であることを示す音声フレームデータを含むＩＰパケットが遅れて到着し、すぐその後に、次の有音状態が開始されるマーカビットがオンとなった音声フレームデータが到着すると、短時間に連続して受信側の音声コーデックに有音終了、有音開始が指示されることになり、有音の立ち上がりが欠損したり、不快なノイズが発生したりする場合がある。
従って、図７２に示すように、本発明においては、上記のようなＩＰネットワークの遅延揺らぎが激しい場合でも音声品質を保つために、上記の有音が終端であることを示す音声フレームデータが送信側の音声コーデックにより生成された場合、ＩＰパケットの蓄積時間が経過しなくても、すぐにその時点でＩＰパケットの構成を終了し、ＩＰネットワークへ送信を行うようにしている。この結果、無音圧縮をサポートしている受信側の音声コーデックは、自然な音声減衰消失や自然な音声の立ち上がりが再現可能となる。
産業上の利用可能性
以上のように、着呼側のセッション管理サーバは、発呼側通信アダプタからのセッション確立要求を受信したことを記憶する。このことは、発呼側通信アダプタは、着呼側の通信状態に関係なく、セッションの確立要求を行うことを可能にし、セッション確立要求を行った時に着呼側通信アダプタが通信不可能状態であっても、発呼側通信アダプタのセッション確立要求はセッション管理サーバ上に残り、着呼側通信アダプタから通信可能状態を通知されたときに、発呼側と着呼側のセッションが張られるようになる。このため、発呼側のユーザは、再ダイヤルを行う手間を省くことができる。
また、セッション管理サーバは、サーバＩＤにより識別され、通信アダプタは、アダプタＩＤにより識別される。これにより、発呼側及び着呼側のセッション管理サーバは、アダプタＩＤにより発呼側通信アダプタから要求されたセッションの確立要求を管理することができる。また、アダプタＩＤにより、セッションの確立要求がなされた着呼側の通信アダプタを特定することができる。また、発呼側及び着呼側通信アダプタは、サーバＩＤにより、自身および通信相手の通信アダプタを管理するセッション管理サーバを特定できる。
また、インターネット通信システムは、指定通知サーバから通信アダプタに対して、通信アダプタを管理するセッション管理サーバのサーバＩＤを通知する。このため、セッション管理サーバを複数配置することができるとともに、各セッション管理サーバの管理する通信アダプタの数を均一に配分したり、一定の条件に合うように配分できる。
また、インターネット通信システムは、着呼側セッション管理サーバが、発呼側と着呼側の通信アダプタ間を中継する着呼側の通信中継サーバを決定して、決定した通話中継サーバを発呼側と着呼側の通信アダプタに対してそれぞれ通知を行う。このため、通信アダプタは通信中継サーバを決定するための処理負荷を削減できる。
また、着呼側通信中継サーバは、通信中継サーバＩＤにより識別される。このため、発呼側及び着呼側通信アダプタは、通信中継サーバＩＤによって着呼側通信中継サーバを接続して、通信データの送受信を行うことができる。
また、インターネット通信システムは、発呼側セッション管理サーバが、発呼側と着呼側の通信アダプタ間を中継する発呼側の通信中継サーバを決定して、発呼側通信アダプタと着呼側セッション管理サーバに対してそれぞれ通知を行う。着呼側セッション管理サーバは、通知された発呼側の通信中継サーバを、着呼側通信アダプタに通知する。このため、通信アダプタは通信中継サーバを決定するための処理負荷を削減できる。
また、発呼側通信中継サーバは、通信中継サーバＩＤにより識別される。このため、発呼側及び着呼側通信アダプタは、通信中継サーバＩＤによって発呼側通信中継サーバを接続して、通信データを送受信することができる。
また、この発明のインターネット通信システムは、アダプタＩＤがＩＳＰの識別子を含む。このため、ユーザが既に所定のＩＳＰと契約を行っている場合は、そのＩＳＰを介してインターネットを接続して、発呼側と着呼側間のデータ送受信を行うことができる。また、発呼側のユーザと着呼側のユーザがそれぞれ異なるＩＳＰと契約を行っていても、アダプタＩＤがＩＳＰの識別子を含むので、発呼側と着呼側とでそれぞれ異なるＩＳＰを介してインターネットを接続することができる。
また、インターネット通信システムは、アダプタＩＤが通信アダプタが設置されたエリアの識別子を含む。これにより、発呼側のセッション管理サーバは、発呼側通信アダプタが設置されている最寄りの通信中継サーバを選択し、着呼側のセッション管理サーバは、着呼側通信アダプタが設置されている最寄りの通信中継サーバを選択できる。このため、通信アダプタと通信中継サーバ間の距離をできるだけ近くすることができ、距離に換算される通話コストを低減できる。ここでいう距離とは、地理的な距離ではなく、ネットワーク経路上のルータのホップ数で示されるネットワーク経路上距離である。
セッション管理サーバは、発呼側セッション管理部と着呼側セッション管理部とを備えた。このため、このセッション管理サーバは、発呼側と着呼側のいずれにも用いることができる。
通信アダプタは、発呼側の通信アダプタ部と着呼側通信アダプタ部とを備えた。このため、この通信アダプタは、発呼側と着呼側のいずれにも用いることができる。
インターネット通信システムは、発呼側の通信アダプタと発呼側の通信中継サーバとの間をＨＴＴＰを用いてインターネットを介して通信を行う。このため、発呼側の通信アダプタ側が設置されている環境がファイアフォールにより守られているような環境であっても、何ら問題なく発呼側の通信中継サーバとデータを送受信できる。また、着呼側の通信アダプタと着呼側の通信中継サーバとの間をＨＴＴＰを用いてインターネットを介して通信を行う。このため、着呼側の通信アダプタが設置されている環境がファイアフォールにより守られているような環境であっても、何ら問題なく着呼側の通信中継サーバとデータを送受信できる。また、発呼側と着呼側の通信中継サーバ間は、ＨＴＴＰ以外のプロトコルを用いて通信を行う。例えば、通信処理のリアルタイム特性に優れたプロトコルを用いて、通信の品質を向上できる。
特に、ＨＴＴＰ以外のプロトコルとして通信処理のリアルタイム特性に優れたプロトコルであるＵＤＰを用いることにより、通信の品質を向上できる。
また、特に、ＨＴＴＰ以外のプロトコルとして通信処理のリアルタイム特性に優れたプロトコルであるＲＴＰを用いることにより、通信の品質を向上できる。
また、特に、ＨＴＴＰ以外のプロトコルとして広く用いられているＴＣＰ上に作られる様々なアプリケーション用のプロトコルを用いることにより、既にインターネットを利用する環境を構築しているユーザに対して、このインターネット通信システムを容易に利用する環境を提供できる。
また、インターネット通信システムは、発呼側と着呼側の通信中継サーバ間をＩＳＰの専用ネットワークにより接続する。このため、従来から存在するＩＳＰの所持するサーバを通信中継サーバとして利用することができる。また、ＩＳＰがこの発明のインターネット通信システムを運用する場合に、既存のネットワーク環境を使用することができるので、ＩＳＰ事業者がこの発明のインターネット通信システムを運用する場合に、事業を立ち上げるためのコストを低くおさえて実現できる。
また、通信中継サーバは、ＨＴＴＰ通信部とＵＤＰ通信部とを備えた。このため、通信中継サーバは、ＨＴＴＰとＵＤＰのいずれのプロトコルを用いるネットワーク環境下でも、設置可能である。
セッション管理サーバで動作するプログラムは、発呼側のセッション管理処理と着呼側のセッション管理処理とをコンピュータに実行させる。このため、このセッション管理サーバは、発呼側と着呼側のいずれのサーバとしても設置できる。
通信アダプタで動作するプログラムは、発呼側の通信アダプタ処理と着呼側の通信アダプタ処理とをコンピュータに実行させる。このため、この通信アダプタは、発呼側と着呼側のいずれの通信アダプタとしても設置できる。
通信中継サーバで動作するプログラムは、ＨＴＴＰ通信処理とＵＤＰ通信処理とをコンピュータに実行させる。このため、この通信中継サーバは、ＨＴＴＰとＵＤＰとのいずれのプロトコルを用いるネットワーク環境下で使用できる。
【図面の簡単な説明】
図１は、実施の形態１のインターネット通信システムのシステム構成図。
図２は、実施の形態１の発呼側と着呼側とで行うデータ送受信の手順を示す図。
図３は、実施の形態１の指定通知サーバの環境を示す図。
図４は、実施の形態１の所属セッション管理サーバ名の取得を説明する図。
図５は、実施の形態１の所属セッション管理サーバ名の取得手順を示す図。
図６は、実施の形態１の着呼側の所属セッション管理サーバ名の取得手順を示す図。
図７は、実施の形態１の着呼側の所属セッション管理サーバ名の取得を説明する図。
図８は、実施の形態１の呼制御方式を説明する図。
図９は、実施の形態１のセッション確立要求を行う動作手順を示す図。
図１０は、実施の形態１の着呼側によるセッション要求受信の処理手順を示す図。
図１１は、実施の形態１の通話中継サーバ回答情報の項目と内容を示す図。
図１２は、実施の形態１の発呼メッセージの送信を説明する図。
図１３は、実施の形態１の発呼側音声データ送信情報の項目と内容を示す図。
図１４は、実施の形態１の着呼側音声データ受信情報の項目と内容を示す図。
図１５は、実施の形態１の発呼メッセージの送信を説明する図。
図１６は、実施の形態２のインターネット通信システムの運用構成例を示す図。
図１７は、図１６に示す運用構成における発呼側と着呼側のデータ送受信手順を示す図。
図１８は、実施の形態２の複数ＩＳＰ網によるインターネット通信システムの構成例を示す図。
図１９は、実施の形態２のＩＳＰ専用ネットワークによるインターネット通信システムの構成例を示す図。
図２０は、実施の形態２のＩＳＰ専用ネットワークによるインターネット通信システムの構成例を示す図。
図２１は、実施の形態２のＣＡＴＶネットワークによるインターネット通信システムの構成例を示す図。
図２２は、実施の形態２の所定のＩＳＰとＣＡＴＶのネットワークによるインターネット通信システムの構成例を示す図。
図２３は、実施の形態３のセッション管理サーバの環境を説明する図。
図２４は、実施の形態３の所属セッション管理サーバデータファイル情報の項目と内容を示す図。
図２５は、実施の形態３の地区管理データの項目を示す図。
図２６は、実施の形態３の通話中継管理データとセッション管理データの項目を示す図。
図２７は、インターネット通信システムのシステム構成の一例を示す図。
図２８は、実施の形態１の発呼側と着呼側とで行うデータ送受信の手順を示す図。
図２９は、実施の形態１の着呼側通話アダプタからセッション管理サーバに対して着呼問い合わせを行うことを説明する図。
図３０は、実施の形態１の着呼側通話アダプタからセッション管理サーバに対して着呼問い合わせを行うことを説明する図。
図３１は、実施の形態１の着呼側通話アダプタからセッション管理サーバに対して着呼問い合わせを行うことを説明する図。
図３２は、実施の形態１の着呼側通話アダプタからセッション管理サーバに対して着呼問い合わせを行うことを説明する図。
図３３は、実施の形態１の着呼側通話アダプタからセッション管理サーバに対して着呼問い合わせを行うことを説明する図。
図３４は、実施の形態１の呼制御方式を示す図。
図３５は、実施の形態３のセッション管理サーバの環境を説明する図。
図３６は、実施の形態５のセッション管理サーバと着呼側通信アダプタとの呼制御機能を説明する図。
図３７は、実施の形態５の電話機操作と呼制御メッセージシーケンスの関係を説明する図。
図３８は、実施の形態５の日毎、月毎の通話履歴情報の表示例を示す図。
図３９は、実施の形態６の通信アダプタと通話中継サーバの通話中継方式の種類を示す図。
図４０は、実施の形態６の端末接続タイプを示す図。
図４１は、実施の形態６の端末接続タイプ毎の通信アダプタと通話中継サーバとの接続方式を説明する図。
図４２は、実施の形態６の同じドメイン内同士の通信における中継方式判定方法を説明する図。
図４３は、実施の形態６の同じドメイン内同士ではない通信における中継方式判定方法を説明する図。
図４４は、実施の形態６のインターネット電話ネットワークシステム構成における通信アダプタの接続タイプに応じた呼制御のメッセージ送受信手順を示す図。
図４５は、実施の形態６のメッセージ送受信手順の一例を示す図。
図４６は、実施の形態６のメッセージ送受信手順の一例を示す図。
図４７は、実施の形態６のメッセージ送受信手順の一例を示す図。
図４８は、実施の形態６のメッセージ送受信手順の一例を示す図。
図４９は、実施の形態６のメッセージ送受信手順の一例を示す図。
図５０は、実施の形態６のメッセージ送受信手順の一例を示す図。
図５１は、実施の形態６のメッセージ送受信手順の一例を示す図。
図５２は、実施の形態６のメッセージ送受信手順の一例を示す図。
図５３は、実施の形態６のメッセージ送受信手順の一例を示す図。
図５４は、実施の形態７の遠隔保守機能を説明する図。
図５５は、実施の形態７の指定通知サーバが故障した場合に、プライマリ側からセカンダリ側へ指定通知サーバの接続を切り替えることを説明する図。
図５６は、実施の形態７の指定通知サーバが故障した場合に、プライマリ側からセカンダリ側へ指定通知サーバの接続を切り替えることを説明する図。
図５７は、実施の形態８のセッション管理サーバの管理機能を説明する図。
図５８は、実施の形態８のセッション管理サーバや通話中継サーバへのＴＣＰ接続処理を説明する図。
図５９は、実施の形態９のＨＴＴＰデータ送受信処理とソケット関数呼び出しの関係を示す図。
図６０は、実施の形態１０のインターネット経路遅延状況調査による混雑度の確認を説明する図。
図６１は、実施の形態１１の内線電話を管理するセッション管理サーバを説明する図。
図６２は、実施の形態１１の内線電話を管理するセッション管理サーバを説明する図。
図６３は、実施の形態１１の内線電話を管理するセッション管理サーバを説明する図。
図６４は、実施の形態１１の内線電話を管理するセッション管理サーバを説明する図。
図６５は、実施の形態１１の内線電話を管理するセッション管理サーバを説明する図。
図６６は、実施の形態１２の通信アダプタをグループ化したグループ回線ＩＰ電話の形態の一例を示す図。
図６７は、実施の形態１３の通信アダプタとセッション管理サーバとのＴＣＰ接続時の通信内容を説明する図。
図６８は、実施の形態１３の通信アダプタと通話中継サーバとの音声情報の送受信を説明する図。
図６９は、実施の形態１４における通信アダプタ間の一般的な音声データＩＰパケットの送受信を説明する図。
図７０は、実施の形態１４における通信アダプタ間の一般的な音声データＩＰパケットの送受信において大幅な遅延揺らぎ発生時の状態を説明する図。
図７１は、実施の形態１４における通信アダプタ間の一般的な音声データＩＰパケットの送受信において大幅な遅延揺らぎが発生した直後の状態を説明する図。
図７２は、実施の形態１４における通信アダプタ間の本発明における音声データＩＰパケットの送受信方式を説明する図。

Claims (22)

  1. インターネットを用いてデータ通信をするインターネット通信システムにおいて、
    発呼側の通信アダプタと、
    着呼側の通信アダプタと、
    発呼側の通信アダプタを管理する発呼側のセッション管理サーバと、
    着呼側の通信アダプタを管理する着呼側のセッション管理サーバと
    を備え、
    発呼側の通信アダプタは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、
    発呼側のセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを発呼側の通信アダプタへ返信し、
    発呼側の通信アダプタは、発呼側のセッション管理サーバから着呼側のセッション管理サーバのサーバＩＤを受信し、受信したサーバＩＤで識別される着呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、着呼側の通信アダプタとのセッションの確立要求を送信し、
    着呼側のセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、
    着呼側の通信アダプタは、着呼側のセッション管理サーバにセッションの確立要求が記憶されているかを自己のアダプタＩＤにより検索し、着呼側のセッション管理サーバにセッションの確立要求が記憶されている場合に、かつ、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信し、
    着呼側のセッション管理サーバは、着呼側の通信アダプタから通信可能状態が通知された場合に、インターネットを用いたセッションの確立を発呼側の通信アダプタと着呼側の通信アダプタとに許可することを特徴とするインターネット通信システム。
  2. 上記インターネット通信システムは、更に、通信アダプタからアダプタＩＤを受信し、通信アダプタを管理するセッション管理サーバをアダプタＩＤに基づいて指定し、指定したセッション管理サーバのサーバＩＤを通信アダプタに通知する指定通知サーバを備えたことを特徴とする請求項１記載のインターネット通信システム。
  3. 上記インターネット通信システムは、更に、
    発呼側の通信アダプタと着呼側の通信アダプタとの間の通信を中継する着呼側の通信中継サーバを備え、
    着呼側のセッション管理サーバは、着呼側の通信中継サーバを識別する着呼側の通信中継サーバＩＤを発呼側の通信アダプタと着呼側の通信アダプタとに送信し、
    発呼側の通信アダプタと着呼側の通信アダプタとは、着呼側の通信中継サーバＩＤを受信し、着呼側の通信中継サーバＩＤで識別される着呼側の通信中継サーバを介してセッションを確立することを特徴とする請求項１記載のインターネット通信システム。
  4. 上記インターネット通信システムは、更に、
    発呼側の通信アダプタと着呼側の通信アダプタとの間の通信を中継する発呼側の通信中継サーバを備え、
    発呼側のセッション管理サーバは、発呼側の通信中継サーバを識別する発呼側の通信中継サーバＩＤを発呼側の通信アダプタに送信し、
    発呼側の通信アダプタは、発呼側の通信中継サーバＩＤを受信し、発呼側の通信中継サーバＩＤを着呼側のセッション管理サーバに送信し、
    着呼側のセッション管理サーバは、発呼側の通信中継サーバＩＤを着呼側の通信アダプタに送信し、
    着呼側の通信アダプタは、発呼側の通信中継サーバＩＤを受信し、
    発呼側の通信アダプタと着呼側の通信アダプタとは、発呼側の通信中継サーバＩＤで識別される着呼側の通信中継サーバを介してセッションを確立することを特徴とする請求項１記載のインターネット通信システム。
  5. 上記アダプタＩＤは、インターネットサービスプロバイダ（ＩＳＰ）の識別子を含むことを特徴とする請求項１記載のインターネット通信システム。
  6. インターネットを用いてデータ通信をするインターネット通信方法において、
    発呼側の通信アダプタから発呼側のセッション管理サーバに着呼側の通信アダプタを管理している着呼側のセッション管理サーバを問い合わせ、
    発呼側のセッション管理サーバから発呼側の通信アダプタに着呼側の通信アダプタを管理している着呼側のセッション管理サーバを回答し、
    発呼側の通信アダプタから着呼側のセッション管理サーバに着呼側の通信アダプタに対するセッションの確立要求を送信し、
    発呼側の通信アダプタから着呼側の通信アダプタに対してセッションの確立要求が合ったことを着呼側のセッション管理サーバに記憶し、
    着呼側の通信アダプタから着呼側のセッション管理サーバに対してセッションの確立要求があったか否かを問い合わせ、
    セッションの確立要求があった場合に、かつ、着呼側の通信アダプタが通信可能状態にある場合に、着呼側の通信アダプタから着呼側のセッション管理サーバに通信可能状態にあることを知らせ、
    着呼側の通信アダプタが通信可能状態にあることを通知された場合に、着呼側のセッション管理サーバがインターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可することを特徴とするインターネット通信方法。
  7. 発呼側の通信アダプタと着呼側の通信アダプタとから接続されるセッション管理サーバであって、
    発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを発呼側の通信アダプタへ返信する発呼側のセッション管理部と、
    発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、記憶したセッションの確立要求を着呼側の通信アダプタに検索させ、着呼側の通信アダプタから通信可能状態が通知された場合に、インターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可する着呼側のセッション管理部と
    を備えたことを特徴とするセッション管理サーバ。
  8. 発呼側のセッション管理サーバと着呼側のセッション管理サーバとに接続される通信アダプタであって、
    発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、発呼側のセッション管理サーバから着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを受信し、受信したサーバＩＤで識別される着呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを送信し、セッションの確立要求を送信する発呼側の通信アダプタ部と、
    着呼側のセッション管理サーバにセッションの確立要求が記憶されているかを自己のアダプタＩＤにより検索し、着呼側のセッション管理サーバにセッションの確立要求が記憶されている場合に、かつ、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信する着呼側の通信アダプタ部と
    を備えたことを特徴とする通信アダプタ。
  9. インターネットを用いてデータ通信をするインターネット通信システムにおいて、
    発呼側の通信アダプタと、
    着呼側の通信アダプタと、
    発呼側の通信アダプタを管理する発呼側のセッション管理サーバと、
    着呼側の通信アダプタを管理する着呼側のセッション管理サーバ
    とを備え、
    発呼側の通信アダプタは、発呼側のセッション管理サーバに着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求を送信し、
    発呼側のセッション管理サーバは、発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤを求め、求めたサーバＩＤで識別される着呼側のセッション管理サーバへアダプタＩＤを送信して、着呼側の通信アダプタとのセッションの確率要求を送信し、
    着呼側のセッション管理サーバは、発呼側のセッション管理サーバから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、着呼側の通信アダプタからの通信可能状態を受信して、受信した通信可能状態の着呼側の通信アダプタに対するセッション確立要求が記憶されている場合に、インターネットを用いたセッションの確立を発呼側のセッション管理サーバと着呼側の通信アダプタとに許可し、
    着呼側の通信アダプタは、自己が通信可能状態にある場合に、着呼側のセッション管理サーバに通信可能状態にあることを送信し、
    発呼側の通信アダプタは、発呼側のセッション管理サーバから、着呼側のセッション管理サーバからインターネットを用いたセッションの確立を許可されたことを受信することを特徴とするインターネット通信システム。
  10. インターネットを用いてデータを通信するインターネット通信方法において、
    発呼側の通信アダプタから発呼側のセッション管理サーバに着呼側の通信アダプタに対するセッションの確立要求を送信し、
    発呼側のセッション管理サーバから着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ、発呼側の通信アダプタから送信されたセッションの確立要求を送信し、
    発呼側の通信アダプタから着呼側の通信アダプタに対してセッションの確立要求があったことを着呼側のセッション管理サーバに記憶し、
    着呼側の通信アダプタが通信可能状態にある場合に、着呼側の通信アダプタから着呼側のセッション管理サーバに通信可能状態にあることを知らせ、
    着呼側の通信アダプタから通信可能状態にあることを知らされた場合に、かつ、通信可能状態にある着呼側の通信アダプタに対してセッションの確立要求があった場合に、着呼側のセッション管理サーバが、インターネットを用いた発呼側のセッション管理サーバと着呼側の通信アダプタとのセッションの確立を許可し、
    発呼側のセッション管理サーバが、セッションの確立を許可された場合に、発呼側の通信アダプタに、インターネットを用いた発呼側のセッション管理サーバと着呼側の通信アダプタとのセッションの確立を許可されたことを知らせることを特徴とするインターネット通信方法。
  11. 発呼側の通信アダプタと着呼側の通信アダプタとから接続されるセッション管理サーバであって、
    発呼側の通信アダプタから着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求を受信し、アダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバへ、発呼側の通信アダプタから受信した着呼側の通信アダプタのアダプタＩＤを含むセッション確立要求を送信する発呼側のセッション管理部と、
    発呼側のセッション管理サーバから着呼側の通信アダプタのアダプタＩＤを受信し、受信したアダプタＩＤで識別されるアダプタに対してセッションの確立要求を受信したことを記憶し、着呼側の通信アダプタから通信可能状態が通知された場合に、記憶したセッションの確立要求を検索し、インターネットを用いた発呼側の通信アダプタと着呼側の通信アダプタとのセッションの確立を許可する着呼側のセッション管理部と
    を備えたことを特徴とするセッション管理サーバ。
  12. 上記通信アダプタは、少なくとも情報を出力する通信装置を接続し、上記着呼側のセッション管理サーバから発呼側のセッション管理サーバを経由して、着呼側の通信アダプタが既に通信状態にあるために、通信不能状態になっていることを受信すると、上記通信装置から着呼側の通信アダプタが既に通信状態にあるために通信不能状態になっていることを出力させることを特徴とする請求項８記載の通信アダプタ。
  13. 上記通信アダプタは、通信を開始する場合には、着呼側のセッション管理サーバに通信を開始することを送信し、通信を終了する場合には、着呼側のセッション管理サーバに通信を終了することを送信することを特徴とする請求項８記載の通信アダプタ。
  14. 上記発呼側の通信アダプタは、少なくとも所定の操作を行うことができる通信装置を接続して、上記通信装置から所定の操作を行ったことを示す情報を入力し、上記発呼側のセッション管理サーバに、入力した所定の操作を行ったことを示す情報を送信し、
    上記発呼側のセッション管理サーバは、受信した所定の操作を行ったことを示す情報を、上記着呼側のセッション管理サーバに送信し、
    上記着呼側のセッション管理サーバは、受信した所定の操作を行ったことを示す情報を、上記着呼側の通信アダプタに送信することを特徴とする請求項１記載のインターネット通信システム。
  15. 上記発呼側の通信アダプタと着呼側の通信アダプタとはそれぞれ、所定のネットワーク環境に設置されて、上記所定のネットワーク環境に従うＩＰ（インターネット プロトコル）アドレスを割り当てられるとともに、上記ＩＰアドレスの割り当て形態に応じて決定される通信アダプタの接続タイプを記憶し、
    上記発呼側の通信アダプタは、発呼側のセッション管理サーバに、上記発呼側の通信アダプタの接続タイプを送信し、
    上記着呼側の通信アダプタは、着呼側のセッション管理サーバに、上記着呼側の通信アダプタの接続タイプを送信し、
    上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから送信された接続タイプに基づいて、上記着呼側の通信アダプタとの間で、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）とユーザデータグラムプロトコル（ＵＤＰ）とのいずれか一方の通信プロトコルを用いてデータを通信することを決定して、上記着呼側の通信アダプタに決定した通信プロトコルを通知する情報を送信し、
    上記発呼側のセッション管理サーバは、上記発呼側の通信アダプタから送信された接続タイプに基づいて、上記発呼側の通信アダプタとの間で、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）とユーザデータグラムプロトコル（ＵＤＰ）とのいずれか一方の通信プロトコルを用いてデータを通信することを決定して、上記発呼側の通信アダプタに決定した通信プロトコルを通知する情報を送信し、
    上記発呼側の通信アダプタは、上記発呼側のセッション管理サーバから送信された上記通信プロトコルを通知する情報に従い、データを通信し、
    上記着呼側の通信アダプタは、上記着呼側セッション管理サーバから送信された上記通信プロトコルを通知する情報に従い、データを通信することを特徴とする請求項１記載のインターネット通信システム。
  16. 上記着呼側の通信アダプタは、着呼側のセッション管理サーバに発呼側の通信アダプタからのセッションの確立要求が記憶されていることを確認するために、着呼側のセッション管理サーバにハイパーテキストトランスファープロトコル（ＨＴＴＰ）のＧＥＴメソッドを発行し、
    上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから発行されたＧＥＴメソッドを受信すると、上記ＧＥＴメソッドを発行した着呼側の通信アダプタに対するセッション確立要求が記憶されているか検索し、検索した結果を上記ＧＥＴメソッドに対するＧＥＴ応答に含めて、上記着呼側の通信アダプタに送信することを特徴とする請求項１記載のインターネット通信システム。
  17. 上記着呼側の通信アダプタは、所定の操作を行うことができる通信装置を接続し、上記接続した通信装置の所定の操作の内容を示す情報を入力して、発呼側のセッション管理サーバに送信し、
    上記発呼側のセッション管理サーバは、上記着呼側の通信アダプタから送信された上記着呼側の通信アダプタの接続する通信装置の所定の操作の内容を示す情報を記憶し、
    上記発呼側の通信アダプタは、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを用いて、上記発呼側のセッション管理サーバに記憶された上記着呼側の通信アダプタの接続する通信装置の所定の操作の内容を示す情報を取得することを特徴とする請求項１記載のインターネット通信システム。
  18. 上記着呼側の通信アダプタは、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを一定周期ごとに着呼側のセッション管理サーバに送信し、
    上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから上記ＧＥＴメソッドを受信すると、上記発呼側の通信アダプタからセッションの確立要求がなされているが、上記発呼側と着呼側の通信アダプタとの間で通信が開始されていない場合には、上記着呼側の通信アダプタに対して、上記発呼側の通信アダプタからのセッションの確立要求がなかったという情報を送信し、上記発呼側の通信アダプタからセッションの確立要求がなされて、上記発呼側と着呼側の通信アダプタとの間で通信が開始されている場合には、上記着呼側の通信アダプタに対して、上記発呼側の通信アダプタからのセッションの確立要求があったという情報を送信することを特徴とする請求項１記載のインターネット通信システム。
  19. 上記着呼側の通信アダプタは、電源投入時や通話処理が完了した直後の通話開始の準備がなされるときに、上記着呼側のセッション管理サーバに、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを送信し、
    上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから送信されたＧＥＴメソッドを保持して、上記発呼側の通信アダプタからのセッションの確立要求があった場合に、上記発呼側の通信アダプタからのセッションの確立要求があったことを上記保持していたＧＥＴメソッドに対する回答として上記着呼側の通信アダプタへ送信することを特徴とする請求項１記載のインターネット通信システム。
  20. 上記着呼側の通信アダプタは、電源投入時や通話処理が完了した直後の通話開始の準備がなされるときに、上記着呼側のセッション管理サーバに、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）のＧＥＴメソッドを送信し、
    上記着呼側のセッション管理サーバは、上記着呼側の通信アダプタから上記ＧＥＴメソッドを送信された場合に、上記発呼側の通信アダプタからのセッションの確立要求がなされていない場合は、上記着呼側の通信アダプタに、上記着呼側の通信アダプタと上記着呼側のセッション管理サーバとの間の回線の接続を維持するための生存確認情報を送信し続け、上記発呼側の通信アダプタからのセッションの確立要求がなされた場合は、上記着呼側の通信アダプタに、上記発呼側の通信アダプタからのセッションの確立要求があったことを送信することを特徴とする請求項１記載のインターネット通信システム。
  21. 上記インターネット通信システムは、特定のネットワークエリア内で使用可能な内線電話番号情報を用いて通信を行うＬＡＮ（ローカルエリアネットワーク）を備え、
    上記発呼側の通信アダプタと上記発呼側のセッション管理サーバは、上記ＬＡＮに接続され、
    上記発呼側の通信アダプタは、通話先の内線電話番号情報を入力して、入力した内線電話番号情報を上記発呼側のセッション管理サーバへ送信し、
    上記発呼側のセッション管理サーバは、上記内線電話番号情報と上記着呼側の通信アダプタのアダプタＩＤとを対応させて管理する内線電話番号情報記憶部を備えて、上記発呼側の通信アダプタから送信された内線電話番号情報を用いて上記内線電話番号情報記憶部から上記内線電話番号情報に対応する着呼側の通信アダプタのアダプタＩＤを取得して、取得したアダプタＩＤで識別される着呼側のセッション管理サーバのサーバＩＤを上記発呼側の通信アダプタに返信することを特徴とする請求項１記載のインターネット通信システム。
  22. 上記インターネット通信システムは、特定のネットワークエリア内で使用可能な内線電話番号情報を用いて通信を行うＬＡＮ（ローカルエリアネットワーク）を備え、
    上記発呼側の通信アダプタと上記発呼側のセッション管理サーバは、上記ＬＡＮに接続され、
    上記発呼側の通信アダプタは、通話先の内線電話番号情報を入力して、入力した内線電話番号情報を上記発呼側のセッション管理サーバへ送信し、
    上記発呼側のセッション管理サーバは、上記内線電話番号情報と上記着呼側の通信アダプタのアダプタＩＤとを対応させて管理する内線電話番号情報記憶部を備えて、上記発呼側の通信アダプタから送信された内線電話番号情報を用いて上記内線電話番号情報記憶部から上記内線電話番号情報に対応する着呼側の通信アダプタのアダプタＩＤを取得して、取得したアダプタＩＤと取得したアダプタＩＤで識別される着呼側の通信アダプタを管理している着呼側のセッション管理サーバのサーバＩＤとを、着呼側のセッション管理サーバに送信し、着呼側の通信アダプタとのセッションの確立要求を送信することを特徴とする請求項９記載のインターネット通信システム。
JP2002582687A 2001-05-25 2001-11-28 インターネット通信システム及びインターネット通信方法及びセッション管理サーバ及び通信アダプタ Expired - Fee Related JP4236032B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JPPCT/JP01/04390 2001-05-25
PCT/JP2001/004390 WO2002098075A1 (fr) 2001-05-25 2001-05-25 Systeme de communication par internet, procede de communication par internet, serveur de commande de session, adaptateur de communication, serveur de relais de communication et programme
PCT/JP2001/010373 WO2002098085A1 (fr) 2001-05-25 2001-11-28 Systeme de communication internet

Publications (2)

Publication Number Publication Date
JPWO2002098085A1 JPWO2002098085A1 (ja) 2004-09-16
JP4236032B2 true JP4236032B2 (ja) 2009-03-11

Family

ID=11737351

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002582687A Expired - Fee Related JP4236032B2 (ja) 2001-05-25 2001-11-28 インターネット通信システム及びインターネット通信方法及びセッション管理サーバ及び通信アダプタ

Country Status (7)

Country Link
US (1) US20040153549A1 (ja)
EP (1) EP1392027A1 (ja)
JP (1) JP4236032B2 (ja)
KR (1) KR20030092018A (ja)
CN (1) CN1507725A (ja)
AU (1) AU2002218482A1 (ja)
WO (2) WO2002098075A1 (ja)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100445284B1 (ko) * 2000-10-26 2004-08-25 미쓰비시덴키 가부시키가이샤 인터넷 전화 네트워크 시스템 및 네트워크 액세스 방법 및통화 장치 어댑터
US20030009561A1 (en) 2001-06-14 2003-01-09 Sollee Patrick N. Providing telephony services to terminals behind a firewall and /or network address translator
US7068655B2 (en) * 2001-06-14 2006-06-27 Nortel Networks Limited Network address and/or port translation
EP1313294A1 (en) * 2001-11-12 2003-05-21 Alcatel Method for allocating a non-data device to a voice vlan
US7487212B2 (en) * 2001-12-14 2009-02-03 Mirapoint Software, Inc. Fast path message transfer agent
KR20040093656A (ko) * 2002-07-29 2004-11-06 아이피 토크 가부시키가이샤 인터넷 통신 시스템 및 인터넷 통신 방법 및 세션 관리서버 및 무선 통신 장치 및 통신 중계 서버 및 프로그램
US7890427B1 (en) * 2003-01-09 2011-02-15 Hewlett-Packard Development Company, L.P. Authentication of notifications received in an electronic device in a mobile services network
US7269692B2 (en) * 2003-05-27 2007-09-11 Oracle International Corporation Implicit connection caching
US7251700B2 (en) * 2003-05-27 2007-07-31 Oracle International Corporation Time-to-live timeout on a logical connection from a connection cache
US7486618B2 (en) * 2003-05-27 2009-02-03 Oracle International Corporation Weighted attributes on connections and closest connection match from a connection cache
US7302053B2 (en) * 2003-12-01 2007-11-27 International Business Machines Corporation System and method for providing a communication session
JP3821813B2 (ja) * 2003-12-17 2006-09-13 Ｎｅｃインフロンティア株式会社 通信転送装置及び通信転送方法
JP3994978B2 (ja) 2004-03-18 2007-10-24 セイコーエプソン株式会社 Ｉｐ電話システム及びその方法
US7904895B1 (en) 2004-04-21 2011-03-08 Hewlett-Packard Develpment Company, L.P. Firmware update in electronic devices employing update agent in a flash memory card
US8526940B1 (en) 2004-08-17 2013-09-03 Palm, Inc. Centralized rules repository for smart phone customer care
US7805517B2 (en) * 2004-09-15 2010-09-28 Cisco Technology, Inc. System and method for load balancing a communications network
JP4486033B2 (ja) * 2005-02-02 2010-06-23 株式会社エヌ・ティ・ティ・ドコモ コンテンツ配信方法及び中継装置
US7594020B2 (en) * 2005-05-31 2009-09-22 Microsoft Corporation Re-establishing a connection for an application layer via a service layer
US8272054B2 (en) * 2005-06-06 2012-09-18 International Business Machines Corporation Computer network intrusion detection system and method
US7492704B2 (en) * 2005-09-15 2009-02-17 International Business Machines Corporation Protocol definition for software bridge failover
WO2007146710A2 (en) 2006-06-08 2007-12-21 Hewlett-Packard Development Company, L.P. Device management in a network
JP2008005077A (ja) * 2006-06-21 2008-01-10 Nec Infrontia Corp ＶｏＩＰシステム、ゲートウェイ装置及びそれらに用いるメインサーバ障害時の通話保持・復旧処理方法
WO2008014454A2 (en) 2006-07-27 2008-01-31 Hewlett-Packard Development Company, L.P. User experience and dependency management in a mobile device
JP4333723B2 (ja) * 2006-09-29 2009-09-16 株式会社日立製作所 通信ログ管理システム
US20080091814A1 (en) * 2006-10-16 2008-04-17 Tao Xie Network Connection Fast Recovery
JP4274231B2 (ja) * 2006-11-24 2009-06-03 村田機械株式会社 中継サーバおよび中継通信システム
US10389762B2 (en) * 2006-12-19 2019-08-20 Bce Inc. Method, system and apparatus for causing a communication client to join a media-over-packet communication session
JP2010518503A (ja) * 2007-02-12 2010-05-27 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ネットワーク化された制御システム及びネットワーク化された制御システムの装置
US20080273680A1 (en) * 2007-05-04 2008-11-06 Ido Eli Zohar System and method for network communication using alternative identifiers
US8850029B2 (en) * 2008-02-14 2014-09-30 Mcafee, Inc. System, method, and computer program product for managing at least one aspect of a connection based on application behavior
JP4525780B2 (ja) * 2008-03-24 2010-08-18 ソニー株式会社 受信装置、送信装置、通信システム、および中継サーバのバッファ設定検出方法
CN104135756B (zh) * 2009-06-10 2018-01-26 苹果公司 移动站及其操作方法
WO2011017807A1 (en) * 2009-08-11 2011-02-17 Tyco Safety Products Canada Ltd. Load balancing for packet switched alarm monitoring
US8395994B2 (en) * 2009-10-28 2013-03-12 Liveops, Inc. System and method for adaptive call management
JP5036841B2 (ja) * 2010-03-31 2012-09-26 株式会社日立製作所 通信システム
JP5831050B2 (ja) * 2010-09-06 2015-12-09 株式会社リコー 伝送端末、伝送端末用プログラム、プログラム提供システム、及びメンテナンスシステム
KR101043415B1 (ko) * 2010-12-31 2011-06-22 썬파크 주식회사 에너지 절약형 가로등을 이용한 영상정보 제공 시스템 및 그의 영상 정보 제공 방법
US8923278B2 (en) * 2011-01-10 2014-12-30 Vtech Telecommunications Limited Peer-to-peer, internet protocol telephone system with system-wide configuration data
JP5490839B2 (ja) * 2012-03-14 2014-05-14 日本電信電話株式会社 センサ装置およびその再送制御方法
US9846597B2 (en) * 2013-03-13 2017-12-19 Microsoft Technology Licensing, Llc Durable program execution
US10375192B1 (en) * 2013-03-15 2019-08-06 Viasat, Inc. Faster web browsing using HTTP over an aggregated TCP transport
JP2016033811A (ja) * 2014-07-30 2016-03-10 富士通株式会社 セッション管理方法、セッション管理装置、セッション管理プログラム、および通話処理方法
JP6693505B2 (ja) * 2015-03-03 2020-05-13 日本電気株式会社 ログ解析システム、解析装置、解析方法、および解析用プログラム
CN110635934A (zh) * 2018-06-22 2019-12-31 京瓷办公信息系统株式会社 远程管理系统和信息处理方法
CN111385349B (zh) * 2020-02-07 2021-07-16 北京达佳互联信息技术有限公司 通信处理方法、装置、终端、服务器及存储介质
US11956204B1 (en) * 2022-12-23 2024-04-09 Plume Design, Inc. IPv4-in-IPv6 relaying systems and methods to preserve IPv4 public addresses

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5726984A (en) * 1989-01-31 1998-03-10 Norand Corporation Hierarchical data collection network supporting packetized voice communications among wireless terminals and telephones
JPH0677963A (ja) * 1992-07-07 1994-03-18 Hitachi Ltd 通信方式および端末装置
JPH07170288A (ja) * 1993-12-15 1995-07-04 Hitachi Ltd 音声通信システムおよび音声通信方法
US5572528A (en) * 1995-03-20 1996-11-05 Novell, Inc. Mobile networking method and apparatus
US5774668A (en) * 1995-06-07 1998-06-30 Microsoft Corporation System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing
US6009469A (en) * 1995-09-25 1999-12-28 Netspeak Corporation Graphic user interface for internet telephony application
US6069890A (en) * 1996-06-26 2000-05-30 Bell Atlantic Network Services, Inc. Internet telephone service
FR2748172B1 (fr) * 1996-04-24 1998-10-02 Alcatel Business Systems Equipement d'adaptation de protocole pour poste telephonique et poste equipe d'un tel equipement
US6014379A (en) * 1996-06-26 2000-01-11 Bell Atlantic Network Services, Inc. Telecommunications custom calling services
US6021126A (en) * 1996-06-26 2000-02-01 Bell Atlantic Network Services, Inc. Telecommunication number portability
US5761294A (en) * 1996-07-18 1998-06-02 Siemens Business Communication Systems Method and system for connecting a digital phone limited to analog transmissions
US5905872A (en) * 1996-11-05 1999-05-18 At&T Corp. Method of transferring connection management information in world wideweb requests and responses
JP3253542B2 (ja) * 1996-11-22 2002-02-04 株式会社日立製作所 ネットワーク通信システム
US6064653A (en) * 1997-01-07 2000-05-16 Bell Atlantic Network Services, Inc. Internetwork gateway to gateway alternative communication
US5953322A (en) * 1997-01-31 1999-09-14 Qualcomm Incorporated Cellular internet telephone
US6064667A (en) * 1997-02-10 2000-05-16 Genesys Telecommunications Laboratories, Inc. Apparatus and methods enhancing call routing to and within call centers
US6075783A (en) * 1997-03-06 2000-06-13 Bell Atlantic Network Services, Inc. Internet phone to PSTN cellular/PCS system
US6157648A (en) * 1997-03-06 2000-12-05 Bell Atlantic Network Services, Inc. Network session management
US6542497B1 (en) * 1997-03-11 2003-04-01 Verizon Services Corp. Public wireless/cordless internet gateway
US6026087A (en) * 1997-03-14 2000-02-15 Efusion, Inc. Method and apparatus for establishing a voice call to a PSTN extension for a networked client computer
US6125177A (en) * 1997-09-15 2000-09-26 Nortel Networks Corporation Telephone communications network with enhanced signaling and call routing
JPH11232201A (ja) * 1998-02-12 1999-08-27 Nippon Telegr & Teleph Corp <Ntt> 通信資源制御装置
US6363421B2 (en) * 1998-05-31 2002-03-26 Lucent Technologies, Inc. Method for computer internet remote management of a telecommunication network element
JP2000099428A (ja) * 1998-09-25 2000-04-07 Nippon Telegr & Teleph Corp <Ntt> ネットワーク間における情報の収集方法及びこれに用いるネットワーク管理装置
JP3558897B2 (ja) * 1998-10-28 2004-08-25 富士通株式会社 電話サーバシステムおよび電話サーバ
US6507577B1 (en) * 1998-11-12 2003-01-14 Nortel Networks Limited Voice over internet protocol network architecture
JP2000155736A (ja) * 1998-11-24 2000-06-06 Nec Corp サービス要求の振り分け方法及びアドレス変換装置
US6519249B1 (en) * 1998-12-23 2003-02-11 Nortel Networks Ltd Scalable gatekeepers in an internet telephony system and a method of operation
JP2000196745A (ja) * 1998-12-28 2000-07-14 Hidemitsu In インタ―ネット利用電話通信システム
EP1059796A3 (en) * 1999-06-07 2001-11-07 Comverse Network Systems, Inc. Rerouting telephone calls over the Internet during an active Internet sessions
DE19950231A1 (de) * 1999-10-19 2001-04-26 Alcatel Sa Verfahren zum Aktivieren eines inaktiven Endgeräts eines Datennetzes, insbesondere eines IP-Netzes
JP2001268248A (ja) * 2000-03-21 2001-09-28 Fujitsu Ltd ネットワーク電話システム
US6963918B1 (en) * 2000-06-29 2005-11-08 Cisco Technology, Inc. Voice over IP optimization for mobile IP
US6772210B1 (en) * 2000-07-05 2004-08-03 Nortel Networks Limited Method and apparatus for exchanging communications between telephone number based devices in an internet protocol environment
KR20010007833A (ko) * 2000-10-05 2001-02-05 박진 네트웍 기반 수신자 선택형 통신 시스템 및 방법
KR100445284B1 (ko) * 2000-10-26 2004-08-25 미쓰비시덴키 가부시키가이샤 인터넷 전화 네트워크 시스템 및 네트워크 액세스 방법 및통화 장치 어댑터
KR20040093656A (ko) * 2002-07-29 2004-11-06 아이피 토크 가부시키가이샤 인터넷 통신 시스템 및 인터넷 통신 방법 및 세션 관리서버 및 무선 통신 장치 및 통신 중계 서버 및 프로그램

Also Published As

Publication number Publication date
WO2002098085A9 (fr) 2008-04-17
WO2002098075A1 (fr) 2002-12-05
CN1507725A (zh) 2004-06-23
US20040153549A1 (en) 2004-08-05
AU2002218482A8 (en) 2008-06-12
EP1392027A1 (en) 2004-02-25
JPWO2002098085A1 (ja) 2004-09-16
KR20030092018A (ko) 2003-12-03
AU2002218482A1 (en) 2002-12-09
WO2002098085A1 (fr) 2002-12-05

Similar Documents

Publication Publication Date Title
JP4236032B2 (ja) インターネット通信システム及びインターネット通信方法及びセッション管理サーバ及び通信アダプタ
JP4238213B2 (ja) インターネット通信システム及びインターネット通信方法及びセッション管理サーバ及び無線通信装置及びプログラム
KR100445284B1 (ko) 인터넷 전화 네트워크 시스템 및 네트워크 액세스 방법 및통화 장치 어댑터
US8346942B2 (en) Call centers for providing customer services in a telecommunications network
US7330464B2 (en) Location identification for IP telephony to support emergency services
JP4548242B2 (ja) 音声ｉｐ電話方法と装置。
US5999612A (en) Integrated telephony and data services over cable networks
US20100046722A1 (en) Telephone system and method for reliable emergency services calling
WO2005125166A2 (en) System and method for facilitating enhanced call awareness
US9843557B2 (en) Systems and methods for dynamically registering endpoints in a network
JP4672011B2 (ja) Ｉｐ電話システム及びｉｐ電話方法
JP3437545B2 (ja) 通話装置アダプタ
US20070274494A1 (en) Computer-readable recording medium having recorded therein telephone-call connection program, telephone-call connection method, and telephone-call connection apparatus
US8514839B2 (en) Internet protocol (IP) address exchange service
EP1181805A1 (en) Method and apparatus for integrated voice gateway with interface to mobile telephone, ip telephone and un-pbx systems
US20060056393A1 (en) Apparatus and method for integrated and simultaneous voice and data communication
JP3682049B2 (ja) 通話装置アダプタ及び中継サーバ及びインターネット電話ネットワークシステム
JP2011151434A (ja) 事業者選択サービスを提供する通信システムおよび通信方法
JP2001127883A (ja) インターネット電話システム
JP3664718B2 (ja) Ｉｐ電話用ゲートウェイ装置の発着信処理、そのプログラムを記録した記録媒体、及びｉｐ電話システム
JP2011166253A (ja) 呼接続方法、呼接続プログラム、および、呼接続システム
JP4230827B2 (ja) プレディクティブ発信オペレータ選定方法
JP5417791B2 (ja) ネットワークシステム及び電話端末の通話状態取得方法
US20010033641A1 (en) Voice messaging system, method, and apparatus
JP2004056626A (ja) 通話料金の安いｉｐ電話事業者を自動的に選択するｉｐ電話システム

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20040625

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20040625

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20040915

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040915

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20041019

A072 Dismissal of procedure [no reply to invitation to correct request for examination]

Free format text: JAPANESE INTERMEDIATE CODE: A072

Effective date: 20050118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080219

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080311

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: 20081125

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: 20081210

R150 Certificate of patent or registration of utility model

Ref document number: 4236032

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20111226

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20121226

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20121226

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20131226

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees