Version 5.1
シグナル |
|---|
| |||||||
|
|
Version 5.1 |
|||||||||||||||||||||||||||||
|
|
リアルタイムコミュニケーションを行う場合、ユーザーはまず自分のデバイス（IP フォン、AV カン ファレンシングツール、インスタントメッセージングツールなど） を設定し、使用するSIP サー バーにオンラインで接続できるようにします。この設定により、ユーザーの「SIP 識別子」とネット ワーク（IP） アドレスがSIP サーバーに記憶され、そのユーザーが登録（レジストレーション） されます。
リアルタイムコミュニケーションのユーザー（SIP ユーザー） にはいずれも「SIP 識別子」があり、 この識別子はAOR （レコードのアドレス） とも呼ばれます。
ユーザーは、複数のコミュニケーションデバイス（IP フォン、デスクトップコンピュータ、ノート ブック上のインスタントメッセージングプログラムなど） を使用することもでき、その場合、複数の 登録がアクティブになります。
SIP ユーザーは登録を介して相互に通信でき、その際に必要なのは「SIP 識別子（AOR）」だけで、 ネットワークアドレスは不要です。
AOR の形式は、電子メールアドレスと同じくユーザー名@ ドメイン名です。CommuniGate Pro の場合 もユーザーのAOR は、そのユーザーの正規のアカウント名と同じです。つまり、SIP ユーザーの AOR 名は、そのユーザーの電子メールアドレスとまったく同じです。
CommuniGate Pro では、リアルタイムコミュニケーション処理にもすべてルータコンポーネントが使 われます。したがって、エイリアスやフォワーダなど、ルーティングが可能は要素はすべてリアルタ イムコミュニケーションでも有効です。
シグナルは、リアルタイムの基本タスクです。いずれかのリアルタイムエンティティから別のリアル タイムエンティティにシグナルが送信され、その結果、コミュニケーションダイアログの開始や修 正、停止、またステータスの更新が行われます。
シグナルの送信元のリアルタイムエンティティで要求オブジェクトが生成され、その要求が CommuniGate Pro のSignal モジュールに送られます。Signal モジュールは、その要求を処理します。 ここで、必要に応じて要求が別のエンティティに送信されたり、送信元のエンティティに応答オブ ジェクトが返送されます。
CommuniGate Pro の多くのモジュールやコンポーネントはシグナルの処理が可能です。
Signal モジュールで要求が受信されると、その要求のターゲット（送り先） のURI （要求URI） が計 算されます。続いて、その要求URI （または要求ルートセットにある最初のルートURI） とルータコ ンポーネントを使って要求のデスティネーション（最終の送り先） が検出されます。この場合、ルー タから返った値に応じて、次のような処理が行われます。
下記は、CommuniGate Pro サーバー内部のシグナルフローを示した図です。
アドレス（要求） がルータで処理されると、アドレスはローカルエンティティまたはリモートエン ティティにリレーされますが、その前にサーバーワイドとクラスタワイドの自動処理ルールが適用さ れます。
自動処理ルールは、要求の処理方法を制御します。つまり、自動処理ルールを介して要求を別のデス ティネーションに送信したり、要求を拒否したりといった処理が可能です。
なお、自動処理ルールでは、要求のうちダイアログ開始要求だけが処理されます。
Signal モジュールによる要求の処理の際、その要求のAOR （レコードのアドレス） セットとコンタク トセットが処理されます。この処理をフォーク処理といい、AOR セットのアドレスを使って次のような処理が行われます。
AOR （要求） の処理中に2xx 応答が受信された場合、AOR 処理は停止します。その要求がINVITE 要 求だったときには、未処理の要求のうち、そのAOR 以外のAOR にリレーされる要求はすべてキャ ンセルされます。
AOR セットのAOR の処理がすべて完了すると、Signal モジュールから「最良」の処理結果（応答） が要求のソースに返送されます。
処理対象のAOR のルート先が非ローカルアドレスだった場合、そのアドレスはコンタクトセットに 格納されます。
処理対象のAOR のルート先がローカルグループだった場合、そのグループの全メンバーがAOR セットに追加されます。
処理対象のAOR のルート先がローカルアカウントだった場合、そのアカウントのアクティブのすべ ての登録情報（そのアカウントのユーザーが使用しているデバイスの登録済みアドレス） がコンタク トセットに格納されます。
AOR がAOR セットに既に存在していたときには、そのAOR はAOR セットには追加されません。
コンタクトアドレスがコンタクトセットに既に存在していたときには、そのコンタクトアドレスはコ ンタクトセットには追加されません。
コンタクトアドレスがコンタクトセットに追加される場合、そのアドレスが次のようにしてチェック
されます。
追加されるコンタクトアドレスがローカルノードのアドレスだった場合、そのノードに要求が渡さ
れ、そのノードで処理されます。
追加されるコンタクトアドレスが外部のアドレスだった場合、SIP モジュールに要求が渡されリレー
されます。
Signal コンポーネントの設定は、WebAdmin インターフェイスで可能です。設定する場合、 ［Settings］ セクションの［RealTime］ ページを開きます。
The CommuniGate Pro Server requires user authentication for certain Requests.
When requests are sent remotely via SIP, authentication is performed with the
SIP モジュール server component.
The XIMSS and XMPP modules send all Signals authenticated, on behalf of the logged-in Account.
The Real-Time Applications send Signals authenticated, on behalf of their current Account (unless the Application has impersonated itself as "nobody").
When a call-type Signal (an initial INVITE request with audio-video Session Descriptor) is authenticated, the Signal Module peforms additional processing of the authenticated Account.
The Signal component can limit the number of "calls" an Account can place over a specified period of time.
AOR セットの中の最初のAOR （要求URI に指定されているAOR） がローカルアカウントのアドレス で、かつ要求がINVITE 要求だった場合、そのアカウントの登録情報とともに、そのアカウントのリ アルタイム設定が取り出されます。
An Account can have Automated Signal Rules, which are retrieved with Account device registrations. These Rules are "mixed" with the Domain-wide Rules specified for the Account Domain and are applied to all requests sent to the Account.
The Signal component controls how many "calls" (initial INVITE requests with audio-video Session Descriptors) an Account receives over a specified period of time.
要求のルート先がローカルドメインの*nnnn （ nnnnは任意の10 進数字で始まる数字列） だった場 合、その要求は発信元（要求のFrom: に格納されているアドレス） にリルートされます。
この処理を利用することで、ユーザーは*nnnn を発信し、サーバーに対してサービスを要求できま す。つまり、要求はユーザー自身のアカウントにルートされるため、セルフコール（自己呼び出し） アプリケーションの起動が可能です。この場合、セルフコールアプリケーションでは、要求のTo: フィールドのアドレスを使って、そのコールが「サービスコール」であることが認識されます。
CommuniGate Pro ユーザーが通信デバイスを使用する場合、そのデバイスをユーザーが登録しなけれ ばなりません。この登録により、デバイスが別のエンティティからの要求を受信できるようになりま す。
ユーザーがデバイスを登録する場合、登録要求が送信されますが、このときユーザー認証が必要で す。
アカウントのユーザーは、そのアカウントの資格（認証情報） を使って別のアカウントの登録情報を 変更することもできます。ただし、ユーザーには、別のアカウントが属しているドメインについて ［CanImpersonate］ （インパーソネート） アクセス権が付与されていなければなりません。
管理者は、レジストラサービスの設定を行うことができます。設定する場合、WebAdmin インター フェイスの［Settings］ セクションの［SIP］ ページを開きます。
Signal モジュールは、イベントパッケージ（複数） をサポートしています。要求がSUBSCRIBE 要求 で、そのターゲットがローカルアカウントの場合、その要求はイベントパッケージを使ってSignal モ ジュール自体で処理されます。このとき要求は、そのアカウントの登録済みエンティティ（デバイ ス） には転送さません。
Signal モジュールにより各アカウントについてそれぞれ、そのアカウントの「状態」が管理されま す。この管理は、Signal モジュールがサポートしているイベントパッケージごとに独立して行われま す。アカウントの「状態」は、単一もしくは複数のエンティティによって必要に応じて更新され、そ の後、Signal モジュールによって単一の「状態情報」に統合されます。この「統合状態情報」に変更 があった場合、Signal モジュールからNOTIFY 要求が更新後の「統合状態情報」とともに全スクライ ブドエンティティに送信されます。
Signal モジュールが管理するアカウントの状態は、PUBLISH 要求を介して外部エンティティによって 更新されます。
また、アカウントの状態は、イベントパッケージよっては非標準のSERVICE 要求を使って外部エン ティティにより更新されることもあります。
REGISTER タイプの要求の場合、Signal モジュールによって特殊処理が実行されます。つまり、外部
エンティティ（SIP デバイス） から要求があり、その要求でSUBSCRIBE メソッドのサポートが示さ
れている場合、そのエンティティとの間でプレゼンスサブスクリプションダイアログが確立されま
す。
その後、外部エンティティから送られたNOTIFY 要求がすべてSignal モジュールで処理されると、そ
のプレゼンス（存在＝エンティティ） の「状態」（セグメント） がSignal モジュール上で管理されま
す。
上記の値をすべて合計した値（ イベント合計値） が優先度が最高の値で、セグメントが存在しない場 合、値はoffline （オフライン） となります。
NOTIFY 要求が生成されると、イベント合計値がプレゼンスドキュメントに変換されます。プレゼン スドキュメントは、サポートされているフォーマット（PIDF とXPIDF） のいずれかで作成されま す。
Signal モジュールによって、MWI （ メッセージ待機インディケーション） サービスが実装されます。 このサービスによりメッセージサマリが生成されます。メッセージサマリの情報フォーマットとして は、simple-message-summary フォーマットをサポートしています。
MWI サービスでは、CommuniGate Pro サーバーによって"INBOX" の「状態」（セグメント） が管理さ れます。セグメントの値は、配列として生成されます。配列の要素は次の通りです。イベント合計値は、配列の各要素の値の合計です。
simple-message-summary 情報フォーマットを使ってNOTIFY 要求が生成される際、配列の第1 要素の値が新規のボイスメッセージの数として使用されます。また、第2 要素の値から第1 要素の値を差し引いた値が古いボイスメッセージ（既読のボイスメッセージ） の数として使われます。
配列の第1 要素の値が非0 の場合、要素Messages-Waiting の値がyes に設定されます。0 のと
きには、no にセットされます。
Subscription to the Message Summary package is available to the Account owner, and to other Accounts with the CanImpersonate Access Right.
Signal モジュールによってレジストラモニタリングサービスが実装されます。情報フォーマットとし てはreginfo+xml がサポートされています。このサービスを介して、Signal モジュールから、アカ ウントに登録されている全エンティティに関する情報が各ネットワークエンティティ（SIP クライア ントなど） に送信されます。
アカウントのオーナーは、レジストレーションパッケージに対するサブスクリプション（レジストラ モニタリング） が可能です。また、ユーザーにCanImpersonate が付与されている場合、そのユー ザーは別のアカウントの資格においてレジストレーションパッケージに対するサブスクリプションが 可能です。
CommuniGate Pro サーバーでは、必要に応じて動的に各種のリアルタイムノードが作成されます。
ノードはCommuniGate Pro サーバーの内部オブジェクトで、シグナル要求を受信し、要求に対する 応答を生成する機能があります。ノードにはまた、要求の送信と応答の処理の機能もあります。
ノードは、CommuniGate Pro の各種のコンポーネントやモジュールで使用され、その結果、シグナリ ング機能が実装されます。このようなコンポーネント、モジュールとしては次のものがあります。Nodes コンポーネントに関する設定は、WebAdmin インターフェイスで行えます。設定する場合、 ［Settings］ セクションの［RealTime］ ページを開き、［Nodes］ リンクをクリックします。
The Server creates special Local Nodes called Call Legs. Each Call Leg terminates signaling for one phone call. Each PBX Task is a Call Leg, and each XIMSS session can create one or more Call Legs to handle phone calls initiated or accepted by the XIMSS session user.
The settings in the Call Legs panel are applied to all types of Call Legs:
Signal モジュールによる処理がINVITE （開始） トランザクションとBYE （終了） トランザクション の場合、コール詳細レコード（CDR） を生成することができます。
外部CDR プロセッサ（ヘルパーアプリケーション） を使用しているときには、Signal モジュールに よってCDR が生成され、そのCDR が外部プロセッサアプリケーションに送信されます。
CDR データテキストのフォーマットは次の通りです。