JPH10505985A - 簡略化したマルチコール処理 - Google Patents

Abstract

(57)【要約】 本発明は電気通信システムにおいて通話処理を構築する方法を提供するものであり、標準的で基本的な構造をつくるために、好ましくはハードウェア／ソフトウェアを用いる。本方法は半通話原理を利用するものであって、半通話を扱うセッションコントローラ（ＳＣ）を含むセッションを含む。対話要求に応じてプロトコルを処理するための第１のエントリポート（ＰＡ＝Ｂ）をつくると同時に、第２の対話要求を処理するための第２のエントリポート（ＰＡ−Ａ）もつくる。こうすることによって、もし通話中の加入者が第２の対話要求を受入れるならば、現行のセッションに設けられた第２のエントリポートに向けられた第２の対話要求が進行中の通話に確実に加われるようになるであろう。

Description

【発明の詳細な説明】 簡略化したマルチコール処理 技術分野 本発明は通話処理用のデータ構造に関するものであり、特に電気通信アプリケ ーションのためのトラヒック制御プロセスにおいて、マルチコールを簡単に処理 することを可能にするデータ構築に関するものである。 発明の背景 現代の電気通信交換システムにおいて、新しい電話アプリケーションが常に開 発されている。このことは交換システムに新しいアプリケーションを加えること が容易であるべきであることを意味する。 電気通話システムにおいて通話を処理している間、多量のデータを処理したり 集めたりする必要がある。このような通話に関するデータは特定の通話にどんな 種類のサービスが使われているか、周囲のネットワークと通信するのにどのプロ トコルが使われているか等々により通話間に大きな相違がある。データは電気通 信システムの様々なユーザにとって有用な情報を含んでいる。勘定記録をつくり たいと思っているネットワーク／サービス・プロバイダもいれば、他方各種の統 計をつくりたいと思っている者もいる。ベンダはどのデータをユーザが使いたが っているかに依存しないで、なお既存のソフトウェアを変更する必要なく新しい サービスと共に新しいデータを加えることを望んでいるので、この通話に関する データレコードは新しい効率的な方法で扱わなければならない。 通話に関するデータを処理するにはいくつかの解決方法が可能である。ひとつ の明白な方法は情報を集めるのに従来のデータベースを利用することであるが、 これはすぐに容量の問題にぶつかる。別の解決方法は内容の宣言がなされる宣言 型ソリューションを選択することである（たとえばパスカルにおけるレコードと 比較されたい）。パスカルレコードのような宣言型ソリューションの欠点は所望 の柔軟性が得られないということである。更に別の方法は必要なときにいつでも オブジェクト間でデータを回送することである。この場合データの複製がつくら れる。現状の技術では、現代の電気通信システムにおいて処理するためのオブジ ェクト指向ソフトウェア構造に関するいくつかの考えがある。ＥＰ−０ ５２４ ０８９ Ａ１，発明の名称「Structure de logiciel pour systeme de に電気通信システムにおけるデータ処理システムのための論理構造）」には、特 に電気通信システムにおけるデータ処理のための論理構造システムが記載されて いる。この構造によれば特に、ＣＣＩＴＴ規格Ｘ２００に従ったオブジェクト間 のリアルタイム通信が簡単になる。ＥＰ−０ ５２４ ０７７ Ａ１，発明の名 （情報処理システム用の論理構造）」には、アプリケーションプログラムに対し てハードウェアとソフトウェアのシステムの特性を隠す構造が記載されている。 ＥＰ−０ ４７０ ４１５ Ａ２には、共通のデータベースに記憶されている 通話関連情報にアクセスするのに、電話システムにいくつかのアプリケーション プロセッサを設ける方法が記載されている。情報にはタグが付されて、通信が続 く間データベース内のレコードとして一時的に記憶されている。情報は特に、オ ペレータが制御する交換システムにおいて管理用のディスプレイ端末で直接見れ るようになっている。 もうひとつの問題はいかにして効率的にマルチコールの状況を扱うかに関わる ことである。マルチコールは３人以上の加入者による通話が成立することができ なければならないことを意味する。ある加入者（Ａ）から他の加入者（Ｂ）へ呼 びがなされると、通常の方法で接続がなされる。第１図に示すように第３の加入 者（Ｃ）が第１の加入者（Ａ）を呼び出すと、通話に加われるようにしなければ ならない。すなわち、第１の加入者（Ａ）は別の呼び出しがかかっているという 指示を得て、これを受入れるかまたは拒否することができる。 発明の要約 したがって、電気通信システムにおいて好ましくはソフトウェアとまたはハー ドウェアを用いて、マルチコール用の標準的で基本的な構造をつくるという要求 がある。それは半通話原理を用いて、既存のシステムの運用ソフトウェアに影響 を与えることなく、前記システムに新しいサービスとデータとを追加することを 可能にするものである。 本発明の第１の目的は、半通話を扱うセッションコントローラを含むセッショ ンを含んで半通話原理を利用するプロセスにおいて、対話要求に基づいてプロト コルを処理するための第１のエントリポートをつくると同時に、第２の対話要求 を処理するための第２のエントリポートをつくることであり、それによって、も し通話中の加入者が第２の対話要求を受入れるならば、セッション内に設けられ た第２のエントリポートに送られた第２の対話要求が進行中の通話に加わること ができるようになるであろう。 本発明の第２の目的は、対話要求がセットアップサーバによって受信され、セ ットアップサーバがその対話要求をセッションに送ることである。 本発明の第３の目的は、セッションはメモリ機能を使い、種々のレコードがポ インタの形式でローカルメモリ機能に対する参照事項を記憶し、ポインタはタグ 要素と組合わされていて、記憶されているデータはタグによって唯一に識別され ることである。 本発明の第４の目的は、セッションは通話の実行オブジェクトとデータオブジ ェクトに関する参照事項をポインタの形式で記憶しているセッションレコードを 利用し、もしタグ要素の下に記憶されているオブジェクトがわかれば、そのレコ ードからセッション内のすべての他のオブジェクトの記憶場所を特定することが 可能となることである。 本発明の第５の目的は、セッションはセッションスコープと類似の構造を有す るトラヒックケーススコープを含み、トラヒックケースレコードはセッションレ コードから参照され、トラヒックケースレコードは通話の実行オブジェクトに対 する参照事項を記憶するためにつくられることである。 本発明の第６の目的は、トランザクションレコードはトラヒックケースに属す るデータオブジェクトを記憶することである。 本発明の第７の目的は、タグ要素は使用される実行オブジェクトまたはデータ オブジェクトに唯一に割当てられた整数により表わされることである。 図面の簡単な説明 付属の図面と一緒に以下の説明を参照することによって、本発明および本発明 のその他の目的および利点もあわせて最も良く理解できるであろう。 第１図はマルチコールの状況を含む一般的な場合を示す。 第２図はＡハーフコールとＢハーフコールとを用いた原理を一般的に示す。 第３図はセッションを示し、セッション内ではいくつかのトラヒックケースが それぞれのトラヒックケース毎にそれぞれの開始呼びＯＣを含み、それがそれぞ れの終了呼びＴＣを含む他のトラヒックケースと通信している場合を扱うセッシ ョンコントローラＳＣが含まれる。 第４図はセッションコントローラＳＣが本発明の方法とシステムに従って、実 行オブジェクトに対する参照事項を記憶するためのセッションレコードと、デー タオブジェクトに対する参照事項を記憶するためのトランザクションレコードと を使うことを示している。 第５図は本発明の方法とシステムに従って、開始呼びＯＣの中にトラヒックケ ースオブジェクトを記憶するための接続を示す。 第６図はセッションにおけるデータの流れを制御するオブジェクトを示す。 第７図は賦課基準のデータがセッションから取り出されるときの例を示す。 第８図はつくられた管理オブジェクト間の関係を簡単な例で示す。 第９図は第６図の簡単な例に従った完全な静的な見方を示す。 第１０図はセットアップサーバにより表わされるスタティックプロセスが、第 ４図に示したセッションコントローラによってどのようにダイナミックプロセス を開始するかを示す。 第１１図は加入者が通話中でないとき、半通話のセッションをつくるステップ を示す。 第１２図は加入者が既に通話中のとき、本発明に従ってセッションに加わるた めに、第１１図のステップと併行するステップを示す。 第１３図は本発明による、三人の加入者を含むマルチコール処理接続を要約し たものである。 基礎 本発明の主題を効率的に扱うことができるように、以下の説明に一貫して役に 立ついくつかの技術用語を最初に定義しておくのが実用的であろう。 電話の通話処理交換システムにおいてソフトウエアを構築するための一般的な 方法は、通話の制御をハーフコールＡとハーフコールＢというふうに二分割する ことである。このことを第２図に示す。半通話(ハーフコール，half call)を制 御するソフトウェアはセッションと呼ばれるプロセスで動いている。セッション は１個またはいくつかのトラヒックケースを同時に扱うことができる（たとえば 多重通話（マルチコール，multi-call）の場合）。トラヒックケースはセッショ ンにおける通話を扱う機能とデータとを定義する。三人の通話は１セッションに おいて２個のトラヒックケースにより扱われる、すなわち各通話径路につき１個 のトラヒックケースがあてられる 簡略化のためにセッションをいくつかのスコープに組織化するので、セッショ ンスコープ とトラヒックケーススコープとを導入する。このことを第３図に示す 。セッションスコープはベースフロー・セッション・コントローラ，ＳＣにより 制御される。セッションコントローラの主な仕事はアクセスプロトコル，ＡＣＰ のコマンドインタプリタとして働き、これらのコマンド（メッセージ）の役割分 析をすることである。それからこれはたとえば、新しいトラヒックケースを開始 することと終了すること、アクセスプロトコルから入手した情報を正しいトラヒ ックケースへ分配すること、新しいサービスを開始すること等々を含む。 セッション内のすべてのトラヒックケースは１個のベースフローにより制御さ れる。このようなベースフローは開始通話（Originating Call），ＯＣまたは終 了通話 （Terminating Call），ＴＣのいずれでもよい。このベースフローの主な 仕事は基礎的な通話処理を世話することである。これはたとえば通話を確立する ことと切断すること（半通話間の電気通信サービスプロトコル，ＴＳＰの扱いを 含む）、接続（たとえば音声接続）の確立／切断を命令すること、アドレス情報 の分析を命令すること等々を含む。 異なるスコープとスコープ内の制御論理演算を支持するには、類似のデータ構 造にすることが必要である。したがって、アプリケーションを組込んで維持する ことができるような方法で、データを構築しなければならない。そのために、こ こでは実行オブジェクトとデータオブジェクトと呼ぶ２種類のオブジェクトが存 在する。 実行オブジェクトはセッション内でたとえば、制御オブジェクト、プロトコル オブジェクト、資源オブジェクト等々を実行する。純粋なデータオブジェクトは たとえば遠隔サービスプロトコルメッセージから受信したデータを含むであろう 。賦課目的または統計目的のためにこの種のデータを出力することもできなけれ ばならない。２種類のオブジェクトは異なるセマンテクス（意味論）を有し、セ ッション内の異なるレコードに記憶される。このことを第４図に示す。あるレコ ードはセッションレコードと呼ばれ、プロトコルオブジェクトと資源オブジェク トを指定するポインタを記憶するのに使われる。具体例を挙げるとセッション内 の制御オブジェクトと資源オブジェクトである。セッションレコードに記憶され るオブジェクトはそのセッション全体に共通である。純粋なデータオブジェクト に関する参照事項を記憶するのに、トランザクションレコードが使われる。セッ ションレコードがオブジェクトを指定するポインタを記憶するのと同様に、トラ ンザクションレコード（通話レコードとも呼ばれる）は純粋なデータオブジェク トを指定するポインタを記憶するのに使われる。具体例を挙げると、セッション またはセッション内で実行するトラヒックケース内の制御オブジェクト、プロト コルオブジェクト、資源オブジェクトである。 ユーザがセッションレコードを見ることはセッション・レコード・ビューと呼 ばれ、ユーザは高い抽出レベルでセッションレコードとのインタフェイスを与え られる。同様に、ユーザがトランザクションレコードを見ることはトランザクシ ョン・レコード・ビュー と呼ばれ、ユーザは高い抽出レベルでトランザクション レコードとのインタフェイスを与えられる。 最後に、トラヒックケースに属するオブジェクトを指定するポインタが記憶さ れているトラヒック・ケース・レコードもある。このレコードにはプロトコルオ ブジェクトとリソースオブジェクトを指定するポインタだけが記憶される。純粋 なデータオブジェクトを記憶するには、トランザクションレコードを使用すべき である。トラヒック・ケース・レコードをユーザが見ることはトラヒック・ケー ス・レコード・ビューと呼ばれ、ユーザは高い抽出レベルでセッションレコード とのインタフェイスを与えられる。 好ましい実施例の詳細な説明 電気通信システムにおける通話処理のために各種のスコープとそれに対応する 制御論理を支持するには、適切なデータ構造が必要である。データはアプリケー ションを組込んで維持することができるように構築しなければならない。そこで 我々は２種類のオブジェクト、実行オブジェクトとデータオブジェクトとをそれ ぞれ導入して、セッション内で追跡する。これらの２個の術語は既に前に定義し たが、異なるセマンテクスを有し、創られたセッション内で別々のレコードに記 憶されるのである。コレクションにオブジェクトを記憶するとき、記憶するのは そのオブジェクトを指定するポインタを記憶するという問題だけであるから、そ のステップでオブジェクト自体が複製されることは全くない。このことはまた、 このようにポインタを記憶するために特定のオブジェクトのサイズを知る必要は 実際全くないことを意味する。 第３図はセッションコントローラＳＣにより制御されるセッションスコープの 一般化した図である。セッションコントローラはアクセスプロトコルＡＣＰに対 するコマンドインタプリタである。ＡＣＰは加入者すなわちネットワークにアク セスする者が使う基本的な術語である。第３図から明らかなように、セッション は１個またはいくつかのトラヒックケースを含み、ここではこのセッションは２ 個のトラヒックケースを含んでいる。どちらもＯＣ型（開始通話）のトラヒック ケースである。ＯＣ型の２個のトラヒックケースの各々は、ハンドリング・テレ コミュニケーション・サービス・プロトコルＴＳＰを介して、ＴＣ型（終了通話 ）の別のトラヒックケースとそれぞれ接続される。 第４図に示すように、セッションスコープにはセッションレコードがあって、 これは各実行オブジェクト、たとえばいわゆるセッションエージェントを指定す るポインタ，ＰＴＲを記憶するのに使われなければならない。セッションレコー ドＳＲは、他のポインタによって各セッション内のデータ構造にアクセスするた めの道を示している。セッション全体の中のデータオブジェクトは、トランザク ションレコードの中でそれぞれのポインタＰＴＲにより見つけられる。セッショ ンレコードにおける各エントリは特定の名前すなわちキーであるタグ（ＴＡＧ） を有している。このことにより、もし特定のシステムオペレータが特定の名前す なわちＴＡＧを知れば、セッションスコープ内に任意のオブジェクトの記憶場所 を特定することが可能になる。 第５図はトラヒック・ケース・スコープの一般化した図である。ここでは開始 通話型ＯＣを含んでいるが、終了通話型TＣも同様な構造を有するであろう。も しアプリケーションがセッション内の任意の数の並列トラヒックケースを実行す る必要があるならば、このスコープを導入しなければならない。このようにトラ ヒックケーススコープの構造はセッションスコープの構造と似ている。セッショ ン内の各トラヒックケースごとに、実行オブジェクトを記憶するためのトラヒッ クケースレコードがつくられる。セッションレコードと同様、名前すなわちＴＡ ＧとポインタＰＴＲとが用いられる。したがって、トラヒックケースレコードは セッションレコードから参照される。その結果、トラヒックケースに属するデー タオブジェクトを記憶するには、トランザクションレコードＴＲを用いて、この トラヒックケースのレベルでデータオブジェクト用の表をつくる。 セッションレコードまたはトラヒックケースレコードのすべてのユーザは自分 のビューオブジェクトを有し、それを用いて記憶されている実行オブジェクトま たはデータオブジェクトにアクセスすることができる。 第６図は開始通話ＯＣを実行するセッションのデータフローを詳細に示したも のである。あるデータがアクセスエージェント、すなわち入力エージェントによ り受信されると、データフローがスタートする。受信されたデータはＡＸＥ内部 表現に変換される。それから変換されたデータはトランザクションレコードＴＲ に記憶される。データオブジェクトはタグと一緒に記憶される。タグはこの特定 のデータオブジェクトのために保有される整数である。データオブジェクトを必 要とする他のユーザ、たとえばアプリケーション分析は、タグによることと、ト ランザクション・レコード・ビュー・オブジェクト、ＴＲ Viewを利用すること とにより、トランザクションレコードからそれを取ってくることができる。この 例はまた、いつデータが出力エージェントにより、テレコミュニケーション・サ ービス・プロトコル，ＴＳＰを経由して他のハーフコールに送られるかも示す。 データの他にそれを識別するタグを含むパラメータの中に含まれてデータが送ら れる。 上述のように、データオブジェクトはトランザクションレコード内に記憶され る（トランザクションレコードの類義語もまた通話レコードである）。トランザ クションレコードＴＲは既に述べたように、常にビューオブジェクトを経由して アクセスされる。ビューオブジェクトはユーザにＴＲとのハイレベルのインタフ ェイスを与える。このことは以下詳しく説明する。トランザクションレコードに 記憶されている各データオブジェクトは、ＴＡＧと呼ばれる名前、すなわちキー によって意味上識別される。ＴＡＧはたとえば１６ビット語から成る整数であり 、１個の特定のデータオブジェクトを表わすために取っておかれたものである。 データオブジェクトをタグと一緒に記憶しているトランザクションレコードのよ うなダイナミック記憶装置を利用することによって、非常に柔軟性のある出力機 構を支持することが可能になるであろう。言い換えると、後の分析のためにユー ザの要求に応じて、どんなときにでも選択された任意のデータオブジェクトを抽 出することが、電気通信システムの一般的な働らきに影響を与えることなく、極 めて容易にできるであろう。この結果、このような動作の構造にしたがって働ら くシステムにサービスを追加することは、いとも簡単にできるであろう。 ここで、エージェントがプロトコルＡＣＰを介してパラメータ「通信者番号」 を受信することを想定する。データはＡＸＥ内部表現に変換されて、専用のタグ 「App Calling Party Number Tag」と一緒にＴＲに記憶される。それから通話者 の番号を必要とするＴＲの他のユーザがＴＲに向かって、ＴＡＧ「App Calling Party Number Tag」と一緒に記憶されているデータオブジェクトを要求すること ができる。アプリケーション・プラットフォーム・タグ・インタフェイス，ＡＴ Ｉというインタフェイスは、機能により使用されるタグの数を含んでいる。ＡＴ Ｉはまた、新しいタグが保有されるときに従うべき規則も含んでいる。 既に述べたように、ＴＲは常にビューオブジェクトを経由してアクセスされる 。ビューオブジェクトはふたつの主要な仕事を持っている。第１の仕事はＴＲと の顧客向けインタフェイスを提供することである。ＴＲの各ユーザはＴＲの内容 との専用インタフェイスを持つべきである。第２の仕事はＴＲに対するハンドル オブジェクトとして働らくことである。ハンドルはすべてのハンドルが削除され るまでＴＲを除去しないことを保証するものである。 ビューオブジェクトはまた現存する他の２種類のレコード、セッションレコー ドとトラヒックケースレコードの内容にアクセスするのにも使われる。前述のよ うに、ビューオブジェクトのひとつの役目は、レコードとの顧客向けインタフェ イスを高い抽出レベルでユーザに提供することである。顧客化の意味は、そのイ ンタフェイスはアクセスすることが必要なオブジェクトのみにユーザをアクセス させるということであり、それはレコード中の全内容のほんの一部にすぎないで あろう。 トランザクションレコードとトラヒックケースレコードに対するビューオブジ ェクトの第２の主な役目は、このオブジェクトがハンドルの役をつとめるという ことである。レコードがハンドルを有する限り、それを削除することはできない 。レコードに対する最後のハンドルが除去されると、レコードとすべてのその内 容もローカルメモリ装置から除去される。このことによりローカルメモリ装置の 管理が非常に便利になるのは明らかである。 前述の通話レコード出力機構は、後の処理のためにトランザクションレコード の内容の一部を出力するのに用いられる。セッションレコードとトラヒックケー スレコードとトランザクションレコードの内容は、その特定のセッションの間だ け存在していて、セッションが終ると消滅するものであることを心に留めておく べきである。出力機構はタグリストを含むいくつかの管理オブジェクトの周囲に 構築される。電気通信システムの運用に際して、たとえば、いろいろな加入者に 正確に料金請求することができるように、賦課データを集める必要がある。第７ 図にセッションで起こり得る例を示す。コントロールオブジェクト「賦課」がオ ブジェクトCro Type（クロタイプ）を開いたところである。この特定のCro Type オブジェクトはデータベースから取って来たTagリストを含み、これにはトラン ザクションレコードから抽出すべきデータオブジェクトが示されている。それか らCro Typeはデータオブジェクトから成るレポートをコンパイルするように命令 される。そのデータオブジェクトは、データベースに記憶されているタグリスト により照合される。それからコントロールオブジェクトはCro Typeインタフェイ スを使って、特定のセッションが存在している間にデータを集めるように命令す る。データはデータ領域に入れられて、それから後処理用節点に送られるだろう 。したがって本発明によれば、構造を有する現存システムと全く干渉することな く、 タグリストを簡単に修正することによって、サービスを増やしたことに起因する 賦課基準をいつでも変更することができる。 この結果、たとえ種々のセッションの内容がローカルデータとして定義されよ うとも、あたかもそれがグローバルデータであるかのように、内容のうち所望の 部分を同時に利用することが可能となるという効果がある。ローカルデータとグ ローバルデータとの違いはたとえば、ほかのユーザがアクセスすることができる ためには、必要に応じて後者には通常あらかじめ定められたメモリ位置を割り当 てなければならないということである。 例示した実施例において、我々はここで述べる柔軟性のある出力機構を実施す るために、３種類の管理オブジェクトを使う。これらはクロサービステンプレー ト（Cro Service Template）、クロタイプ（Cro Type）、クロカスタマテンプレ ート(Cro Customer Template)と呼ばれる。第１の管理オブジェクトタイプであ るCro Service Templateは、特定の基本サービスまたは補助サービスのためにど のデータオブジェクトを抽出することができるかということを特定するのに使わ れる。Cro Service Templateは１個のアトリビュートと、特定のサービス、たと えばこの場合、「基本通話」または「三者通話」、のためにトランザクションレ コードＴＲからどんなデータを抽出することができるかを示す可能性のある複数 のＴＡＧとを含む。 第２の管理オブジェクトタイプであるCro Typeは、ある出力タイプを特定する のに使われる。Cro TypeのすべてのインスタンスはCro Service Templateの１個 または２個以上のインスタンスに接続される。これらのCro Service Templateに おけるデータのかたまりは、特定のCro Typeのためにどのデータを出力するのが 可能であるかを決める。 ３番目で最後の管理オブジェクトタイプはCro Customer Templateである。こ れは特定の出力タイプ、Cro Typeで特定の顧客向けにどのデータを抽出すべきか という情報を保有する管理オブジェクトである。 第８図は以下の条件を有する小さな例である。 −２人の顧客ＡとＢがいる。 −２種類のサービス、「基本通話」と「三者通話」がある。 −２種類のCro Type、Cro Type１とCro Type２がある。 ２種類のサービスがあるから、以下の２種類のCro Service Templateが必要で ある。 −タグ１，２，５，８を含むCro Service Template基本通話。 −タグ１，２，６，８を含むCro Service Template三者通話。 このことは、「基本通話」に対して我々はタグ１，２，５，８を有するＴＲ内 に記憶されているデータを出力することができると共に、サービス「三者通話」 に対して、タグ１，２，６，９の下に記憶されているデータを出力することがで きることを意味する。 ここで我々は２個の出力タイプを定義する。Cro Type１は両方のサービスに関 連するデータを出力することができるようになっており、Cro Type２は基本通話 に関連するデータを出力することができるようになっている。第８図ではつくり だされた管理オブジェクトの基本的な構造と相互の関係を図示している。 出力機構「通話記録出力（Call Record Output）」，ＣＲＯがすべての顧客に 対してすべてのCro Typeを出力することができるように、各顧客とCro Type毎に １個のCro Customer Templateが必要である。この結果、この例では合計４個のC ro Customer Templateが必要となる。第９図にこの構造を示す。顧客ＡはCro Ty pe１に可能性のあるすべてのタグを要求し、Cro Type２にタグ１，２を要求する 。顧客ＢはすべてのCro Typeに８より小さい数のすべてのタグを要求する。これ で我々は出力機構ＣＲＯが適切な分配をするのに必要とする最終的な構造を手中 にしている。我々はすべての異なる顧客がすべての異なるCro Typeにどのデータ フィールドを要求するかを特定したのである。 第６図のデータフローの最後の部分で、いつデータを他のハーフコールに送る べきかを説明する。ハーフコールは電気通信サービスプロトコル、ＴＳＰにより 通信する。ＴＳＰは自己識別パラメータを送る。パラメータはデータオブジェク トを含み、タグにより識別され、この実施例ではいくつかのバイト、たとえば２ 進１６ビットで構成される。受信者はタグを見ることによって、どのデータを受 信するかを決めることができる。ＴＳＰでパラメータを照合するのに使われるタ グは、ＴＲに記憶されているデータを照合するのに使われるタグと同じものであ る。 既に述べたように、電話用の通話処理交換システムにおいてソフトウェアを構 築するひとつの方法は、通話の制御を半分ずつ２個に分割することである。この ことはハーフコール（半通話）原理と呼ばれ、１個の通話の各部分が自分自身の ソフトウェアにより制御されることを意味する。これをこれらの半通話間で適切 な基本プロトコルと組合せることにより、新しい電話応用を追加することが極め て容易なシステムを構築することが可能である。この構造は第２図にも示してあ る。 ここで、本発明に従って、既に確立されている通話に容易に加われるように、 これらの半通話の一方を構築する方法を、たとえばオブジェクト指向プログラミ ングを用いて説明する。この通話方式は前述のように、たとえば「三者通話」の ようなマルチコール（多重通話）である。 前述のように、１個の半通話のオブジェクトを扱うソフトウェアかつまたはハ ードウェアはセッションと呼ばれる。セッションはセットアップ・サーバ（ＳＵ Ｓ）により開始されるダイナミックプロセスである。セッションは既に述べたよ うに、セッションコントローラ（ＳＣ）と呼ばれる主制御部と、セッションレコ ード（ＳＲ）と呼ばれる記憶構造とを有する。セッションレコードには、そのセ ッションに関するすべての実行オブジェクトとデータ構造に対する参照事項が記 憶されている。このことは第１０図にも示してある。 呼出しが開始されると、セットアップサーバ（ＳＵＳ）はそのポートエージェ ントを介して対話要求を受信する。セットアップサーバは最初に、受信したこの 要求が有効であること、すなわち行先が正しいことを確認する。それからセット アップサーバは新しいセッションを作るべきか、それとも現存するセッションに 加わってもよいのかを調べる（現存するセッションは被呼者が既に通話中である ことを示す）。第１０図はこの状況を示している。 被呼者が通話中でない場合、セットアップサーバは第１１図の径路１に沿って 被呼者のために新しいダイナミックセッションをつくる。この例では対話要求に 応じてプロトコルを扱うために、２で、セッション・プロトコル・エージェント 、第１１図のＰＡ−Ｂがつくられる。それから３ａと３ｂで制御論理ＣＬがスタ ー トして、セッションを引継ぐ。それから制御論理はセッションに関する情報を記 憶するために、４で、前述のようにセッションレコードと呼ばれるデータ構造を つくる。それから受信したメッセージを処理するために、５でプロトコル・エン トリ・ポート、この場合ＰＥＰ−Ｂをスタートさせる。後で別の呼びがこのセッ ションに参加することができるように、制御論理はまた６で別のプロトコル・エ ントリ・ポート、ＰＥＰ−Ａをスタートさせる。ここで対話要求は７でプロトコ ルエージェントＰＡ−Ｂに転送されるだろう。ＰＡ−Ｂは対話要求を調べてから 、８でそれを制御論理ＣＬに転送する。この後は対話要求が何を含むかと、制御 論理がこれをどのように処理するかによるのであり、そのことは当業者には明ら かであろう。 ここで重要な点は、第２のエントリポートであるオブジェクトＰＥＰ−Ａがこ の時点でつくられるということである。もしこの時点でつくらないと、後の段階 でつくらなければならないが、同じ加入者に別の要求が発生する危険性がある。 後になると、偶然に別のプロセスが現存するプロセスと平行してつくられるとい う危険性があるのは明らかである。その場合、進行中の通話に加わるのに所望の 柔軟性を持つのは、たとえ可能であったとしても、複雑なものになるであろう。 したがって重要なことは、制御論理ＣＬが２個のプロトコルエントリポート、（ ＰＥＰ−ＢとＰＥＰ−Ａ）をつくることによって、別の呼びが容易に進行中のこ のセッションに加わることを可能にするという点である。 もし被呼者が既に通話中であったならば、すなわちこの加入者のためのセッシ ョンが既に存在している場合、第１２図に示すように、セットアップサーバがこ の加入者に対する別の対話要求１１を受信したとき、セットアップサーバはこの ことを発見して、現存するセッションに加わろうとするだろう。セットアップサ ーバは最初に、利用可能なプロトコルエントリポートＰＥＰ−Ａへのアドレスに 関するデータベース、すなわちセッションレコードを調べる。それから１２で対 話要求をこのポートに転送する。プロトコルエントリポートＰＥＰ−Ａはそれか ら１３でプロトコルエージェントＰＡ−Ａをつくって、１４で、このプロトコル エージェントＰＡ−Ａを介してメッセージが来るというメッセージを制御論理Ｃ Ｌに送る。今や（１６で）セットアップサーバＳＵＳ−Ａからプロトコルエージ ェントＰＡ−Ａに転送されていた対話要求は、１７で制御論理に送られるだろう 。制御論理はメッセージの処理を開始する。この続きは対話要求が何を含んでい て、制御論理ＣＬがこれをどのように処理するかによる。 ここで重要なのは、プロトコルエントリＰＥＰ−Ａがどこにあるかという情報 をセットアップサーバＳＵＳ−Ａが得ることができるということである。この情 報はセッションレコードＳＲの中に見い出される。セットアップサーバＳＵＳ− ＡとＳＵＳ−Ｂは、セッションに関する情報が記憶されている共通のデータ領域 をおそらく一般的にローカルなデータベース内に持っている。 既に２つの通話が進行中であるとき、前と同じ加入者に対する更に別の対話要 求がセットアップサーバＳＵＳ−Ａに入ってきた場合、セットアップサーバはそ のメッセージをプロトコルエントリポートＰＥＰ−Ａに転送するだろう。プロト コルエントリポートＰＥＰ−Ａはそれから前述のように新しいプロトコルエージ ェント（第２のＰＡ−Ａ）をつくるだろう。これら２つの異なる対話は混ぜるべ きでないので、この新しい要求は現存するプロトコルエージェントＰＡ−Ａには 転送されないだろう。ここで説明した構造は一般的な電気通信交換システムと実 際上干渉することなく、マルチコールサービスのために容易にセッションを拡張 する方法を開示するものである。 第１３図は３人の加入者が関わるマルチコール処理ケースを要約したものであ る。ここでＰＡ−ＡとＰＡ−Ｂは２つの異なるトラヒックケースに属するが、同 じセッションでかつ同じセッションコントローラＳＣにより扱われる。一方のト ラヒックケースにおいて、加入者Ｂは終了呼びであり、他方第２のトラヒックケ ースでは加入者Ｃは開始呼びである。これらのトラヒックケースは両方とも同じ セッションにより扱われるので、たとえば既に通話中である加入者ＡまたはＢを 呼び出そうとしていた加入者Ｃが、加入者ＡまたＢにアクセスするのは容易であ ろう。 要約すると、特定の加入者向けに受信された新しい対話要求毎に、その対話を 扱うための新しいプロトコルエージェントがつくられるだろう。特定のセッショ ンに属しているすべての実行オブジェクトとデータオブジェクトはセッションレ コード内のそのタグ，ＴＡＧにより定義され、それぞれのポインタＰＴＲはメモ リ内の記憶位置を示すアドレスを与えるであろう。その利点は以下のようになる であろう。 ◇開示した方法はすべての電気通信アプリケーションに共通する標準的で基本 的な構造を創造するものであって、特定の加入者に対する任意の数の通話を追加 することを可能にする。 ◇この方法は新しい対話（ＴＳＰ対話）を追加するのが容易な構造を創造する ものである。このことが基本的機能に影響することなく行われる。 ◇本方法は特定の加入者に対するデータと相互作用のすべての処理が１個のダ イナミックプロセスに集約することができるような構造を創造するものである。 ◇性能およびメモリの使用という特定の見地からいうと、このことは、プロセ ス間通信を全く使わずに、すべての調整とデータ操作をダイナミックプロセスで 行うことができることを意味する。 請求の範囲に記載されている本発明の精神と範囲から逸脱することなく、本発 明の思想に従ってハードウェア／ソフトウェアにいろいろな修正と変更を施し得 ることが当業者に理解されるであろう。

Claims (1)

1. 【特許請求の範囲】 １．好ましくはソフトウェアにより標準的で基本的な構造をつくることによっ て、電気通信システムにおけるマルチコール処理を構築するための方法であって 、該方法は半通話原理を用いて、既に動いているシステムの主なハードウェアと ソフトウェアに影響することなく、該システムに新しいサービスとデータとを追 加することを可能にするものであって、該半通話を扱うセッションコントローラ （ＳＣ）を含むセッションを含んで該半通話原理を利用するプロセスにおいて、 対話要求に応じてプロトコルを処理するための第１のエントリポート（ＰＥＰ− Ｂ）がつくられると同時に、第２の対話要求を処理するための第２のエントリポ ート（ＰＥＰ−Ａ）もつくられ、それによって、もし通話中の加入者が該第２の 対話要求を受入れるならば、該セッション内に設けられた該第２のエントリポー トに向けられた該第２の対話要求が進行中の通話に確実に加わることができるこ とを特徴とする、マルチコール処理の構築方法。 ２．請求項１記載の方法において、前記対話要求はセットアップサーバによっ て受信され、該セットサーバが前記対話要求を前記セッションに送ることを特徴 とする、マルチコール処理の構築方法。 ３．請求項２記載の方法において、前記セッションはメモリ機能を利用し、種 種のレコードがポインタの形式でローカルメモリ機能に関する参照事項を記憶し ており、ポインタ（ＰＴＲ）はタグ要素（ＴＡＧ）と結合していて、その場所に 記憶されているデータが該タグによって唯一に識別されるであろうことを特徴と する、マルチコール処理の構築方法。 ４．請求項３記載の方法において、前記セッションは通話の実行オブジェクト とデータオブジェクトに関する参照事項をポインタの形式で記憶しているセッシ ョンレコード（ＳＲ）を利用し、もしタグ要素（ＴＡＧ）の下に記憶されている オブジェクトを知れば、そのレコードからセッション内のすべての他のオブジェ クトの記憶場所を特定することが可能になるであろうことを特徴とする、マルチ コール処理の構築方法。 ５．請求項４記載の方法において、セッションは前記セッションスコープと類 似した構造を有するトラヒックケーススコープを含み、トラヒックケースレコー ドは前記セッションレコード（ＳＲ）から参照され、該トラヒックケースレコー ドは通話の実行オブジェクトに対する参照事項を記憶するためにつくられている ことを特徴とする、マルチコール処理の構築方法。 ６．請求項５記載の方法において、トランザクションレコード（ＴＲ）は前記 トラヒックケースに属するデータオブジェクトを記憶していることを特徴とする 、マルチコール処理の構築方法。 ７．請求項６記載の方法において、前記タグ要素（ＴＡＧ）は使用される各実 行オブジェクトまたはデータオブジェクトに唯一に割当てられた整数により表わ されていることを特徴とする、マルチコール処理の構築方法。 ８．好ましくはソフトウェアかつまたはハードウェアにより標準的で基本的な 構造をつくる、電話のマルチコール処理交換システムであって、該システムは半 通話原理を用い、既に動いているシステムの主なハードウェアとソフトウェアに 影響することなく該システムに新しいサービスとデータとを追加することを可能 にするものであって、該半通話を扱うセッションコントローラ（ＳＣ）を含むセ ッションを含んで該半通話原理を利用するプロセスにおいて、対話要求に応じて プロトコルを処理するための第１のエントリポート（ＰＥＰ−Ｂ）がつくられる と同時に、第２の対話要求を処理するための第２のエントリポート（ＰＥＰ−Ａ ）もつくられ、それによって、もし通話中の加入者が該第２の対話要求を受入れ るならば、該セッション内に設けられた該第２のエントリポートに向けられた該 第２の対話要求が進行中の通話に確実に加わることができるであろうことを特徴 とする、マルチコール処理交換システム。 ９．請求項８記載の装置において、前記対話要求はセットアップサーバ（ＳＵ Ｓ）によって受信され、該サーバが前記対話要求を前記セッションに送ることを 特徴とする、マルチコール処理交換システム。 10．請求項９記載の装置において、前記セッションはメモリ機能を利用し、種 種のレコードがポインタの形式でローカルメモリ機能に関する参照事項を記憶し ており、ポインタ（ＰＴＲ）はタグ要素（ＴＡＧ）と結合していて、その場所に 記憶されているデータが該タグによって唯一に識別されるであろうことを特徴と する、マルチコール処理交換システム。 11．請求項１０記載の装置において、前記セッションは通話の実行オブジェク トとデータオブジェクトに対する参照事項をポインタの形式で記憶しているセッ ションレコード（ＳＲ）を利用し、もしタグ要素（ＴＡＧ）の下に記憶されてい るオブジェクトを知れば、そのレコードからセッション内のすべての他のオブジ ェクトの記憶場所を特定することが可能になるであろうことを特徴とする、マル チコール処理交換システム。 12．請求項１１記載の装置において、セッションは前記セッションスコープと 類似した構造を有するトラヒックケーススコープを含み、トラヒックケースレコ ードは前記セッションレコード（ＳＲ）から参照され、該トラヒックケースレコ ードは通話の実行オブジェクトに対する参照事項を記憶するためにつくられてい ることを特徴とする、マルチコール処理交換システム。 13．請求項１２記載の装置において、トランザクションレコード（ＴＲ）は前 記トラヒックケースに属するデータオブジェクトを記憶していることを特徴とす る、マルチコール処理交換システム。 14．請求項１３記載の装置において、前記タグ要素（ＴＡＧ）は使用される各 実行オブジェクトまたはデータオブジェクトに唯一に割当てられた整数により表 わされていることを特徴とする、マルチコール処理交換システム。