(57)【特許請求の範囲】
【請求項１】
アドレスされたマルチメディア呼を運ぶのに適合したコンピュータネットワークと、該コンピュータネットワークと公衆交換通信ネットワーク（ＰＳＴＮ）との間のゲートウェイと、ゲートキーパと、受領したマルチメディア呼をコンピュータネットワークの所望のノードへのアドレスを実効するように構成された呼マネージャとを含むマルチメディア通信呼センタであって、
ＰＳＴＮ上でのマルチメディア呼の受領時に、該ゲートウェイは信号をコンピュータネットワークを経由してゲートキーパへ送信し、該ゲートキーパは呼マネージャのコントロールのもと信号を所望のネットワークノードへ送信させて、該ノードに信号をコンピュータネットワークを経由して該ゲートウェイへ送信させて呼設定を実行し、それによって受信されたマルチメディア呼はＰＳＴＮからネットワークノードへコンピュータネットワークを経由して直接接続されることを特徴とするマルチメディア通信呼センタ。
【請求項２】
第１のネットワークノードに接続された、確立されたマルチメディア呼は、第２のネットワークノードへゲートキーパを介して送信され、該ゲートキーパはまず制御信号を第１のネットワークノードとゲートウェイの各々へ送信し、第１のネットワークノードを該ゲートウェイに接続しているコンピュータネットワークの論理チャネルを閉鎖し、該ゲートキーパは次に制御信号を第２のネットワークノードとゲートウェイの各々へ送信して、第２のネットワークノードとゲートウェイを接続しているコンピュータネットワークの論理チャネルを開けることを特徴とする請求項１に記載の呼センタ。
【請求項３】
前記ゲートキーパは前記コンピュータネットワーク上のノードを含んでいる請求項１又は２に記載の呼センタ。
【請求項４】
前記ゲートキーパはＣＳＴＡ規格プロトコルを用いて呼マネージャと通信する請求項１ないし請求項３のいずれか１項に記載の呼センタ。
【請求項５】
前記ゲートキーパは前記コンピュータネットワークを通って前記ゲートウェイと通信する請求項１ないし請求項４のいずれか１項に記載の呼センタ。
【請求項６】
前記ゲートキーパは国際電気通信連合（ＩＴＵ）Ｈ．３２３規格プロトコルを用いてゲートウェイと通信する請求項１ないし請求項５のいずれか１項記載の呼センタ。
【請求項７】
前記コンピュータネットワークはＬＡＮを含んでいる請求項１ないし請求項６のいずれか１項に記載の呼センタ。
【請求項８】
前記ゲートウェイは前記ＬＡＮに対して近くに在る装置を含む請求項７に記載の呼センタ。
【請求項９】
前記ゲートウェイは前記ＬＡＮから遠く離れた装置を含む請求項７に記載の呼センタ。
【請求項１０】
前記ゲートウェイは専用線を介して前記ＬＡＮに接続されている請求項９に記載の呼センタ。
【請求項１１】
複数のマルチメディア端末が前記コンピュータネットワークに接続されている請求項７ないし請求項１０のいずれか１項に記載の呼センタ。
【請求項１２】
前記端末は対応している複数のネットワークノードにおいて前記ＬＡＮに接続されている請求項１１に記載の呼センタ。
【請求項１３】
前記端末はスイッチ装置を介して、前記ＬＡＮに接続されている請求項１１に記載の呼センタ。
【請求項１４】
前記コンピュータネットワーク上に呼を置きたいと望む端末が前記ゲートキーパに向けてＳＥＴＵＰ信号を送るように構成された請求項１１に記載の呼センタ。
【請求項１５】
前記端末は前記ゲートキーパによってＳＥＴＵＰ信号を送るよう命令される請求項１１に記載の呼センタ。
【発明の詳細な説明】
この発明は、マルチメディア遠隔通信呼センタ、とくに、それに限定するわけではないが、この種のセンタで標準電話サービスだけではなく、データ及びビデオ情報もしくはその一方を運ぶ通信も統合したやり方で処理することができるものに関する。
典型的な従来技術の呼センタが図１に模式的に示されている。個々の組織体の電話と計算機装置は一般に参照番号１０で示されており、それが外部網１２、例えば一連のライン１４，１５を経て公衆電話網に接続されている。これらのラインは各種型式のものでよく、例えば音声トラヒック用の標準電話線、ＩＳＤＮライン、その他のものでよい。組織体で所有する装置は図では波形線１６によって外部網と境界を定めている。この線の左側の装置は通常は個人所有となるもので、１つの建物とか実際には１つの敷地（サイト）に全部が必ずしもなければならないというわけではない。大きな組織体となると、個人所有装置はいくつかのサイトにわたって分布されていてよいし、おそらくはいくつかの別の国、地方内にあって、素子は適当な私設電話及び／又は計算機網（及び／又は両者もしくはそのうちの一方の意）によってリンク（接続）されている。ここでの記載では、波形線１６の左側のものはすべて“呼センタドメイン”内にあると言うことにする。
到来呼はライン１４，１５により組織体に入り、先ずＡＣＤすなわち自動呼分配器１８に向う。これが発呼ラインＩＤ（識別子）を到来呼からはぎとって、インテリジェントインターフェースの助けを受けてその呼がＬＡＮ又はＷＡＮ２２を介して呼センタドメイン内に居る一番適切な人物のところに向けて、計算機２０の制御の下にルート設定をする。一般にＡＣＤ１８と計算機２０との間の通信はＣＳＴＡ（Computer Supported Telecommunications Applications-European Computer Manufacturers Associationにより定めた標準インターフェースとしてＥＣＭＡ  Technical Report TR/68,1994年12月に記載）を介して実効を得ている。このために、ＡＣＤはＴＣＰ／ＩＰインターフェース２８を組込んでいる。
ＡＣＤ１８は標準の（音声）電話を、ＩＳＤＮサービスとともに取扱うことができる。到来音声メッセージは適当な標準電話２８、音声メールユニット３０、又はＩＶＲ（対話形式の音声応答）ユニット３２へ自動的に切換えられる。同じように、到来ＩＳＤＮ呼は適当なＩＳＤＮ２電話３４又はＶＣ８０００端末３６（これはビデオ会議を可能としている）へ向けられる。
音声又はＩＳＤＮサービスに加えて、計算機２０は呼に関係する情報に対して使用者の計算機２４，２６上で表示がされるようにすることができる。
図１に示した先行技術のシステムは技術的に複雑であり、その理由は、ＡＣＤが異常に沢山の異なる装置で各々が異なるプロトコルを使用するものとインターフェースをとらなければならないことにある。図１では、例えば、ＡＣＤ１８はオーディオ、ビデオ、データ及び電話サービスを処理しなければならない。これが最初にこのようなシステムを設定する際に困難を生じさせるだけでなく、このようなシステムの拡張の際にもそうであって、例えば、問題の組織体がもっと端末を必要とするとか、追加のサービスを求める場合がそうである。このようなシステムの保守は比較的熟練した要員を使うことを求める。
この発明によると、マルチメディア遠隔通信呼センタとして、アドレスがついているマルチメディア呼を運ぶのに適した計算機網と、その網により伝送するためのマルチメディア呼を受領するのに適した網へのゲートウェイと、受領したマルチメディア呼についての所望の網ノードへのアドレスの効果があるようになっている呼マネージャとを含むものが用意されている。
この明細書と請求の範囲では、“マルチメディア”という用語は次の類型の呼の１又は複数（複数であるのが望ましい）を取扱うことができるデバイスを言う；標準のオーディオ（音声）呼、ビデオ及びデータ。データ機能は国際電気通信連合（ＩＴＵ）のデータ会議規格Ｔ．１２０に適ったものがよいが、その必要はない。
この発明は、初めて呼センタ環境内でビデオ、オーディオ、データ及び電話の統合機能を達成する可能性とともに、インターネット、ＩＳＤＮ、ＰＳＴＮ及び他の広域網への接続性についての可能性を用意している。
この発明の呼センタは分散形技術をローカルエリア網上で使用し、またＬＡＮへの別なゲートウェイと、ＬＡＮへのゲートキーパとを用意するのが好ましい。好ましい実施例での呼センタの分散した性質はゲートウェイとそれに恐らくはゲートキーパも顧客の施設上でのオーバーヘッド（諸経費）となるのではなく外部網内に帰属することができることを意味している。
この発明がもたらす統合的な解決はインフラストラクチャ（基礎構造）のコストを低くすることができるようにするもので、ケーブル布設のコストの低減を含んでいる。加えて、ゲートウェイは実施例では別個の網資源として用意され、この実施例では外部の網の一部で顧客の施設外のものを含んでいる。
好ましいのは、ゲートウェイとゲートキーパとの間の通信がＬＡＮを通って行なわれ、ＩＴＵ  Ｈ．３２３規格プロトコルを用いることである。ゲートキーパと業務応用が帰属している計算機（呼マネージャ）との間の通信もまた網を通って行なわれ、今度は欧州計算機製造業者協会のＣＳＴＡ規格プロトコルによって行なわれるのがよい。
この発明はさらにマルチメディア呼を呼センタ環境内部で伝送する方法にまで展開されており、この環境は特定の記述と請求の範囲で記述するようにまた上述した装置により定義されている。
この発明は多数のやり方で実用に供せられ、この発明を実施する好ましいマルチメディア呼センタは、いくつかの変形と一緒に、添付の図面を参照して記述される。
図１は前述のように先行技術の呼センタを示す；
図２はこの発明の好ましい実施例によるマルチメディア呼センタを示す；
図３は図２の実施例の変形を示す；
図４はシグナリングドメイン、すなわちＣＳＴＡとＨ．３２３との間の相互作用（対話）を示す；
図５は外へ向う呼がどのように取扱われるかを示す；
図６は補助的なサービスを用いて、端点間で呼転送がどのように使用できるかを示す；
図７は図６の代りを示し、補助的なサービスを用いなくとも呼転送がどのように行なわれるかを示す；また、
図８は到来呼を受領したときに呼センタ内部での一次メッセージの流れを示す簡略化した図である。
この発明の好ましい実施例によるマルチメディア呼センタが図２に模式的に示されている。この図では、また以下の図でも、同じ素子には図１ですでに使ったのと同じ番号がつけてある。
図２の実施例では、ＡＣＤ１８が除去されており、呼センタはここではＬＡＮ又はＷＡＮ２２と完全に一体となっている。ＡＣＤはゲートウェイにより置き換えられていて、それがノード３８でＬＡＮに直接接続されている。このＬＡＮはまたゲートキーパ４０を含み、その目的は到来呼による帯域幅の要求を受領するとＬＡＮへのアクセスを許すか拒否するかにすることである。ゲートキーパ４０はそれ故に“警察官（ポリスマン）”すなわち帯域幅マネージャとして効果的に動作して、多数の呼（とくにビデオ呼）が一度にＬＡＮに置かれることがないようにＬＡＮを保護する。ゲートキーパはまたＬＡＮ２２によって使用される番号づけ機構と、外部網１２によって使われるものとの間でルックアップ表を用意する。
外部網１２からの到来呼が今ゲートウェイ３６に到着し、そこでそれがゲートキーパ４０への要求を作ってその呼はＬＡＮ２２上に置かれてよいかどうかを問合せる。もしゲートキーパが許可を出すと呼はＬＡＮ上に置かれ、そこからスイッチ４２を経由して適当な端末４２，４６，４８，５０へ進むことができる。当業者には分ることであろうが、スイッチ４２は使われる網プロトコルに依存して削除されてもよい。各端末は図示のように、ビデオ、データ及び電話サービス（もしくは少くともそのうちの何かしか）を処理する施設を組込んでいる。
到来及び送出呼は網を形成する計算機５４上で走行している業務応用５２と対話（相互作用）をする。インターネット５６へのアクセスも専用網ノード５８を経て用意されている。
ゲートキーパ４０と計算機５４との間のインターフェースはＣＳＴＡ規格を使用し、それによっていずれの業務応用５２に対しても不変の標準化されたインターフェースとなるようにしている。
このやり方では、ゲートウェイ３６とゲートキーパ４０とは仮想ＰＢＸ（私設構内交換）として一緒に動作する。ゲートウェイとゲートキーパとはそれ故に業務応用５２の制御の下で、呼待ち行列のような追加の機能を帯びる必要がある。
ＬＡＮ２２を通る通信は好きなプロトコル、例えばＴＣＰ／ＩＰプロトコルを使用してよい。ＬＡＮ自体は便利な型式のものでよく、イーサーネットやトークンリング網のようなものでよい。ゲートウェイ３６とゲートキーパ４０との間の通信はＩＴＵの勧告により決められている標準Ｈ．３２３プロトコルを用いて符号化されていてよい。この勧告は１９９６年５月２８日付の“Visual Telephone Systems and Equipment for Local Area Networks which provide a non-guaranteed quality of service”の題名である。
別の実施例で、さらに進んだ開発のものが図３に示されている。ここでは、ゲートウェイ３６が今度は個々の組織体の構内でのオーバーヘッドに留まっているのでなく、外部網１２内部に帰属している。ゲートウェイと組織体との間の通信はここでは完定したＩＰ（インターネットプロトコル）パイプ６０を経由しており、このパイプが組織体構内のライン６２にリンクしている。これがラン２２上のルータ６４とリンクをとっている。このようなやり方の長所は組織体がここでは単一の外へ向うライン６２だけを必要とし、図２の実施例では必要であった異なる型式の複数のライン１４，１５を必要としないことである。ここではゲートウェイを購入して維持する経費が個々の顧客にかかるのではなくて、外部網１２の供給者にかかる。
図２と３の模式図もっと詳細に記述して行く。
図４はＣＳＴＡとＨ．３２３との間の変換（ほん訳）プロセスの詳細を示す。図２と３とから思い出されるように好ましい実施例では、ゲートキーパ４０はＣＳＴＡ規格を用いて業務応用と通信をし、ゲートキーパはＨ．３２３規格を用いてＬＡＮ２２を介してゲートウェイ３６と通信する。変換それ自体はゲートキーパで実行され、そのためには呼制御層６６とベアラ制御層６８とが備えられている。Ｈ．３２３プロトコルでＬＡＮ２２上の呼についての呼シグナリングはベアラ制御層と呼制御層とによりＣＳＴＡプロトコルに変換されて、それが業務無応用５２へ向けて送れるようにする。逆のプロセスは業務応用５２がＬＡＮ２２上に呼をのせたいとするときに生ずる。
とりあげている実施例では、呼制御層６６は論理接続を管理し、他方ベアラ制御層６８は物理接続を制御する。もっとはっきりさせると、呼制御層はＣＳＴＡとベアラ制御により使用されるインターフェースとの間の変換を実行する。ベアラ制御自体は物理的スイッチングコマンド、例えばＬＡＮ上の端末４４との接続を要求するものを送出する。
Ｈ．３２３ドメインと呼ばれるようなものでは、システムは一連のＨ．３２３固有の呼シグナリングプロセス、すなわちＳＥＴＵＰ（設定）、ＣＡＬＬ  ＰＲＯＣＥＥＮＩＧ（呼進行）、ＡＬＥＲＴＩＮＧ（知らせ）、ＣＯＮＮＥＣＴ（接続）、ＲＥＬＥＡＳＥ  ＣＯＭＰＬＥＴＥ（解放完了）を使用する。これらのことはもっと詳細にＩＴＵの規格Ｑ．９３１、Ｈ．３２３、及びＨ．２２５に記載されている。さらに、一連のＲＡＳ信号（registration,admission and status signals；登録，承認，状態信号）が、ＩＴＵ規格Ｈ．３２３とＨ．２２５に記述されるように、使用される。これらはＡＲＱ（ＬＡＮへの承認要求），ＡＣＦ（承認確定），ＡＲＪ（承認拒否）である。
好ましい実施例では、Ｈ．３２３ドメインはＩＴＵ規格Ｑ．９３２で定義されている補助サービスを使用してもよく、例えばＦＡＣＩＬＩＴＹ（施設）メッセージを使用する呼転送特徴のようなものを使える。
ＣＳＴＡドメインでは、メッセージの異なるシリーズが使用され、それについての主たるものは次のようなものである：
ルート要求：ルート要求は呼の指向先（目的地）を要求する。指向先を選ぶのを助けるために，サービス要求は現在の指向先を含みまた追加の情報を含むことができる。
ルート選定：ルート選定は前のルート要求もしくは再ルートサービスによって要求された指向先をクライアントに供給する。
モータ開始：これはイベントの要求である。
モニタ応答：上の要求に対する応答である。
呼識別子：これは一つの呼を識別することになるハンドル（ＣＢ無線で使われている用語で、ラベル、タグ、タイトルの意）である。転送もしくは会議は新しい呼識別子を生ずることができる。
呼サービスをせよ：二つのデバイス間でＣＳＴＡ呼を始める。このサービスは新しい呼を作り、始動用デバイスと接続をとる。「呼サービスをせよ」はまたＣＳＴＡ接続識別子を用意し、それかが始動用デバイスの接続を識別する。
呼は送られた：イベント報告は知らせる（アラートする，リンギンク）がデバイスに加えられたことを示す。
呼は確立された：イベント報告はデバイスが応答をされたが、呼に接続されたことを示す。
呼はクリアされた：イベント報告はデバイスがクリアされたことを示す。
会議呼サービス：会議呼は存在している呼と、他の活性な呼との間で会議デバイスで会議を作り出す。
図４に戻ると、ここでは、主たるメッセージの流れについて２つの主たる類型があることが分ると思う：
（ａ）ＣＳＴＡ呼管理メッセージ    これらのメッセージはゲートキーパへ呼制御層６６を経由して送られ、そこでは今度は業務応用５２によって管理がされる。業務応用は全体の呼管理機能を実行する。
（ｂ）Ｈ．３２３ドメインにおける呼シグナリングメッセージ    上述のように、これらのものはＨ．３２３メッセージとＱ．９３１内部の対応する呼シグナリングプロセスとで構成されている。これらはゲートキーパから呼制御層６６に向けて、ＬＡＮ２２上のシグナリングメッセージの流れに応答して送られる。
全端末の状態が常時業務応用により知られていることが必要であり、例えば所望の端末が使用中（ビジィ）である場合に１つの端末からの呼を別のところへ自動的に転送することがシステムにできるようにするために求められる。さらに、好ましい実施例では、ＦＡＣＩＬＩＴＹのようなメッセージはゲートキーパとゲートウェイとの間で呼転送機能を備えるために必要とされる。
明確にするために述べておかなければならないこととして、ＣＳＴＡ規格は“呼マネージャ”と読んでいるものを制御するためにＱ．９３１規格のスーパーセットを使用する。これは呼制御層６６、ベアラ制御層６８、及び応用層であって業務応用５２を含むことになるものとで構成されている。これらの個々の層は一般的に“呼管理層”と呼ぶことができる。
Ｈ．３２３ドメイン内に含まれているメッセージプロセスについてもっと詳しく考えてから、ＣＳＴＡドメイン内部でのメッセージを考えて行くこととする。Ｈ．３２３ドメイン内部での正規の呼設定プロセスは、ゲートウェイ３６とゲートキーパ４０とが先ずＨ．３２３ＲＡＳ（登録承認，状態）メッセージをＡＲＱ／ＡＣＦ／ＡＲＪを用いてＬＡＮへの承認について相談するために交換することである。それに続いて、上で述べたＱ．９３１呼シグナリングメッセージのサブセット、すなわちＳＥＴＵＰ（設定）メッセージと、その後はＣＡＬＬ  ＰＲＯＣＥＥＤＩＮＧ（呼進行）、ＡＬＥＲＴＩＮＧ（知らせ）、ＣＯＮＮＥＣＴ（接続）、及びＲＥＬＥＡＳＥ  ＣＯＭＰＬＥＴＥ（解放完了）が続く。このＣＯＮＮＥＣＴメッセージの中にはＩＰアドレスが含まれていて、その上で信頼できるる制御メッセージが、ＩＴＵにより定義されたＨ．２４５プロトコル規格を用いて、送られることになる。
信頼できるＨ．２４５制御チャンネルが確立されると、オーディオ、ビデオ、及びデータ用の追加のチャンネルがＨ．２４５機能交換の結果に依存して、Ｈ．２４５論理チャンネルプロセスを用いて設定できる。
Ｈ．３２３ドメイン内部では、到来呼が次のやり方で処理される：
１．呼はゲートウェイ３６により外部網１２から受領される。
２．ゲートウェイは承認要求（ＡＲＱ）をゲートキーパ４０に送る。
３．ゲートキーパは呼シグナリングを指向先端末に代ってゲートキーパに向けて送るべきことを特定している承認確定（ＡＣＦ）メッセージで応答する。
４．ゲートウェイ３６は呼シグナリングＳＥＴＵＰ（設定）メッセージをゲートキーパ４０に送る。
５．ゲートキーパはＳＥＴＵＰメッセージの内容をＣＳＴＡドメインで呼マネージャに送る。
６．呼マネージャはゲートキーパにどのＨ．３２３端末が呼をとるべきかを通知する。
７．ゲートキーパはそこで再方向付けされたＳＥＴＵＰメッセージを関連するＨ．３２３端末４４に送る。
Ｈ．３２３ドメイン内部で呼を送り出すことに関連してやや複雑なことが生じ、図５を参照しなければならない。業務応用５２が第一の発呼元端末４６と第二の宛先端末４４との間で呼を設定したいとするときには、先ず呼制御６６に対して呼を作る（メイクコール）コマンドを発し、それが次にゲートキーパ４０に命令して適当なＳＥＴＵＰメッセージを発する。ＳＥＴＵＰメッセージ７０でゲートキーパから宛先端末４４に向けたものはこれまでのように発生するが、それは端末４４に関する限りは、単に到来呼を受取るために設定されるにすぎないものである。しかし、発呼元端末４６については状態が違っており、それは正常環境の下ではゲートキーパがＳＥＴＵＰメッセージ７２を端末に向けて発するだけとなることによる。しかし、これは明らかに正しくなく、この端末に関する限りは、ＳＥＴＵＰメッセージは発呼元端末４６で開始して、宛先端末４４によって受取られなければならないことによる。逆向きのＳＥＴＵＰメッセージ７４で発呼元端末４６からゲートキーパ４２に向けて送られるものがそこで必要となる。これは次のいずれかのやり方で達成してよい。
（ａ）ゲートキーパ４０は端末４６に向けてメッセージを送り、それに命令してＳＥＴＵＰメッセージ７４を送るようにする；か、
（ｂ）ゲートキーパは多点制御器ＭＣとしてＨ．３２３規格内部で動作することができて、定義によりいくつでもよい数の端末端点を一緒に接続するための論理チャンネルプロセスを設定できるものとする。
図６と７とをここで見ると、呼転送が、依然としてＨ．３２３ドメイン内部で達成できる二つの方法が示されている。これは進行中の呼が第１の端末（“エンドポイント（端点）１”）から第２の端末（“エンドポイント（端点）２”）へ転送される必要がある状態を含んでいる。
図６に示した実施は補助サービスを使用するもので、とくに機能（ＦＡＣＩＬＩＴＹ）呼出しシグナリングメッセージを使用している。この実施では、端点１への呼が先ず通常方法で設定されるのであり、図６の二重線の上の上部に示してある。ＳＥＴＵＰメッセージは先ずゲートウェイからゲートキーパに送られ、そこから端点１へ送られる。そこでゲートキーパはゲートウェイに向けて呼進行（ＣＡＬＬ  ＰＲＯＣＥＥＤＩＮＧ）信号を送って、呼が処理中であることをゲートウェイに通知する。次に端点１は知らせ（ＡＬＥＲＴ）信号を生成し、それをゲートキーパがゲートウェイに向けて送る。接続（ＣＯＮＮＥＣＴ）信号がそこで同じように端点１により生成されてゲートキーパによりゲートウェイに向けて送られる。
ここで図６の下の部分に目を向けると、呼が端点１から端点２へ転送されるところを仮定している。これはゲートキーパがゲートウェイに機能（ＦＡＣＩＬＩＴＹ）呼出し信号メッセージを送り、それがゲートウェイに対して発呼のための新Ｈ．３２３番号（数）を与えるものとすることによって達成される。ゲートウェイはそこで解放完了（ＲＥＬＥＡＳＥ  ＣＯＭＰＬＥＴＥ）メッセージを発し、それがゲートキーパと端点１とに向けて送られる。これが端点１を解放する。次にＳＥＴＵＰ信号がゲートウェイにより発せられる。これがゲートキーパに送られ、次に新しい端点である端点２に直接送られる。端点２は接続（ＣＯＮＮＥＣＴ）信号をゲートキーパに向けて送り戻し、そこからゲートウェイにそれが送り戻される。端点２はこうして、端点１に代って、その呼に対する宛先点として設定がされる。
この実施ではすべてのメッセージがゲートキーパを通っていることが分る。
別な実施で、補助サービスＦＡＣＩＬＩＴＹ信号の使用を回避するものが図７に示されている。この図では、端点１へ向けた呼が何らかの方法ですでに設定されていることを仮定して（例えば図６の上の部分で示した信号を用いて設定された）、どのように呼転送が達成されるかを示している。
端点１から端点２へ呼を転送するために、ゲートキーパは先ずはゲートウェイと端点１とに向けて論理チャンネルを閉じる（Close Logical Channel）信号を送る。その両方ともがこのＣＬＣの受領告知（Close Logical Channel ACK）信号をゲートキーパに戻す。次にセッション終りコマンド（End Session Command）がゲートキーパにより端点２に向けて発せられるが、これはゲートウェイには送られない。端点１への呼はそこで解放完了（ＲＥＬ  ＣＯＭＰ）メッセージによってクリアされて、端点２への新しい呼が送出されるＳＥＴＵＰと戻りのＣＯＮＮＥＣＴ信号によって設定される。ここでゲートキーパはゲートウェイが端点２それ自体が変っていることを気付かずに、端点２において端末の正しい能力について学習することを確かにしなければならない。次にゲートキーパはゲートウェイに向けてモード要求（Request Mode）信号を発して、論理チャンネルを開く（Open Logical Channel）要求を生ずることができるようにする。これが次にゲートウェイによって端点２に送られて、それによってその端点と論理チャンネルが開くようにする。この実施では、ゲートキーパは多点制御器（ＭＣ）と非常によく似た動作をしている。これでＨ．３２３ドメイン内部でのシグナリングプロセスの詳細説明を終る。ここでＣＳＴＡドメイン内部での信号の流れれについての同じような説明に移る。
図４に戻って、到来呼を受取るときにＨ．３２３ドメイン内部で何が起ったかを先ず反復しておくのが有役と思われる。最初はゲートウェイ３６がゲートキーパにＡＲＱメッセージを用いてＬＡＮへ参加することを求める。ゲートキーパはＡＣＦメッセージで確認をするか、ＡＲＪメッセージで拒否する。次にゲートウェイがＳＥＴＵＰメッセージをゲートキーパに送る。
Ｈ．３２３ドメインシグナリングはそこでゲートキーパとベアラ制御６８との間で次のような送信をする：
（ａ）ＡＲＱとＳＥＴＵＰメッセージをゲートキーパから呼管理層へ送る。言い換えると呼制御層６６、ベアラ制御層６８、及び応用層（業務応用５２参照）へ送る；
（ｂ）ＳＥＴＵＰメッセージは次にゲートキーパ４０を経由して選定された端末４４へ向けて送られる；
（ｃ）ＡＬＥＲＴとＣＯＮＮＥＣＴ信号がそこで選定された端末４４から呼管理層へ戻される。
ＣＳＴＡドメイン内部でのメッセージの流れは、到来呼を受領するときは、図８の簡単化した図面によって最もよく理解できよう。この図はＨ．３２３とＣＳＴＡとの両方のメッセージを模式的に示しており、これらメッセージは外部網１２からゲートウェイ３６に到来呼が受領されるときに生ずる。
図８で番号付けしたシーケンスに従って、ゲートウェイは先ず、前述したように、ＬＡＮへのアクセスを要求し、ゲートキーパにＳＥＴＵＰ信号１を送る。次にゲートキーパはルート要求（ＲＯＵＴＥ  ＲＥＱＵＥＳＴ）信号２を業務応用に送り、そこがルート選定（ＲＵＯＴＥ  ＳＥＬＥＣＴ）信号３で応答する。これが今度はドメイン名称サーバ７６でゲートキーパ４０が関係しているものによって変換されて、要求された端末４４のアドレスを送出するようにする。次にゲートキーパは設定信号４をその端末に送り、その端末は知らせ（ＡＬＥＲＴＩＮＧ）信号５で応答する。次にゲートキーパは呼が発想されていることを呼発送（ＣＡＬＬ  ＤＥＬＩＶＥＲＥＤ）信号６によって業務応用に戻す。端末４４の準備ができていれば、それが接続（ＣＯＮＮＥＣＴ）信号をゲートキーパ７に送り、そこが呼設定（ＣＡＬＬ  ＥＳＴＡＢＬＩＳＨＥＤ）信号を業務応用に送り戻す。呼が完了してしまうと、この端末は解放（ＲＥＬＥＡＳＥ）信号９をゲートキーパに送り、そこでは自らが呼クリア（ＣＡＬＬ  ＣＬＥＡＲＥＤ）信号１０を業務応用に向けて送る。
図８はＣＳＴＡメッセージの流れれの簡単化した概観だけを示している。実際には他のＣＳＴＡメッセージも使用できることは前述したところであり、例えばモニタ開始（Monitor Start）、モニタ応答（Monitor Response）などがある。
業務応用５２は端末４４の状態を常時監視するのが望ましく、例えば端末ハンドセットか持ち上げられているかどうかを確認するのが望ましい。もし業務応用を走行させている計算機がハンドセットが持ち上げられていると判断するとすると、その後の呼でその端末に向けられたものはすべてが他の端末に再方向付けされる必要があることは明らかであろう。
【図１】
0003933703.tif 000002
【図２】
0003933703.tif 000003
【図３】
0003933703.tif 000004
【図４】
0003933703.tif 000005
【図５】
0003933703.tif 000006
【図６】
0003933703.tif 000007
【図７】
0003933703.tif 000008
【図８】
0003933703.tif 000009