![]() |
Version 5.1 |
|||||||||||||||||||||||||||||
|
|
システム上のシグナルアドはすべてCommuniGate Pro のルータによって処理(ルーティング) され ます。ルータによる処理は次の通りです。
ルータには、コールをリアルタイムアプリケーションを介してPSTN ネットワークにルートするという機能も搭載されています。
CommuniGate Pro サーバーにはリアルタイムアプリケーションとしてgatewaycaller アプリケー
ションが付属しています。このgatewaycaller を使って、送信PSTN コールを単一もしくは複数
のPSTN ゲートウエイにリレーすることができます。
gatewayCaller アプリケーションで受信コールが受信されると、認証が行われます。そのため、CommuniGate Pro サーバーまたはCommuniGate Pro サーバーのクラスタのユーザーに限って、gatewayCallerアプリケーション経由のコールを発信できます。
gatewayCaller にコール要求が届き、その要求が正規のユーザーからの要求だった(認証された) 場合、gatewayCaller によって次のPSTN 設定(アカウントの設定)が取り出され、使用されます。
上記の設定の値としてはそれぞれ、CommuniGate Pro のアカウントのデフォルト値( ドメインワイ ド、サーバーワイド、クラスタワイドのデフォルト設定の値) を使用できます。また、アカウントご とに明示的に指定することもできます。例えば、全ドメインの全アカウントで同じゲートウエイ、同 じ資格(認証情報) が使用されるようにすると同時に、コーラーID はアカウントごとに別々にする といった設定が可能です。また、ドメインごと、アカウントごとに別々の資格で別個のゲートウエイ が使用されるように設定することもできます。
gatewayCaller アプリケーションの起動アカウントは、ドメイン管理者アクセス権を持ったアカウントでなければなりません。これは、起動アカウント以外のアカウント(例えばコーラー) の設定情
報の取り出しが必要なためです。起動アカウントとしては自動的に生成されるアカウント、つまり
postmaster やpbx を使用できます。
また、gatewayCaller アプリケーションには、パラメータとしてデスティネーション番号(数値
アドレス、つまり相手の電話番号) が渡されることが必要です。
上記の処理は、ルータレコードを使って可能です。下は、ドメインpstn(仮想ドメイン)の全アド レスをgatewaycaller アプリケーションにルートする場合の例です。このレコードにより、メイ ンドメインのアカウントpbx によってgatewaycaller が起動され、ドメインpstn のアドレスの ユーザー部(*)がパラメータとして渡されます。
gatewaycaller アプリケーションの起動後、必要なアカウント設定がすべて取り出されます。続い
てgatewaycaller によって新規のタスクが生成され、そのタスクを介して、取り出されたアカウ
ント設定を使って、指定されているゲートウエイにコール要求が送信されます。送信が成功すると、
オリジナルのタスク(gatewaycaller の最初のタスク)と新規のタスクによってメディアスト
リームが処理(橋渡し)されます。
この場合、オリジナルのタスクはコーラー(発信側) からのシグナル要求を処理し、2 番目(新規)
のタスクはゲートウエイからの要求を処理します。要求の中にはピアリング(補助) タスクによって
処理され、そのピアリングタスクを介してコーラーやゲートウエイにリレーされるものもあります。
上記のようなコールセットアップ(2 つの独立したシグナルセッション/ タスクによってコールを確 立させる処理) を実装する手法をバックツーバックユーザーエージェント(B2BUA) と呼んでいま す。
コーラーがコールのトランスファー(第三者への切り替え) を指示した場合、トランスファー (Transfer) 要求がオリジナルのタスクに送られます。その後、オリジナルのタスク自体でトランス ファー要求が処理され、コールが別のVoIP デバイス/ エンティティに切り替えられます。トランス ファー要求は、2 番目のタスクによって処理されることはなく、したがってゲートウエイに送信され ることもありません。代わりに、2 番目のタスクからはコール更新要求(SIP 再INVITE 要求または UPDATE 要求) がゲートウエイに送信され、その結果、メディアストリームが新規のコール参加者 (第三者) にリダイレクトされます。
一部のPSTN ゲートウエイでは、コール更新要求、それも簡単なコール更新要求もサポートされてい ない場合もあります。こういったPSTN ゲートウエイを使用する場合、その名前 (PSTNGatewayName) の前にアステリスク(*) を付加しておきます(このアステリスクは、処理 時にgatewaycaller によって自動的に削除されます)。こうすることで、gatewaycaller によるメディアストリームの「橋渡し」は行われなくなります。代わりに、CommuniGate Pro のメディア サーバーのチャンネルを介して、コーラーとゲートウエイとの間でメディアがリレーされます。コー ラーがメディアアドレスを切り替えた( コール更新要求が送信された) 場合、または、コーラーから コールトランスファー要求が送信された場合、メディアサーバーのチャンネルを介して内部情報が更 新されます。要求は一切、ゲートウエイには送られません。つまり、メディアサーバーのチャンネル によるメディアデータ交換が続行されます。
ユーザーまたはドメインについてPSTN ゲートウエイを複数使用したい場合、PSTNGatewayName と PSTNFromName の各オプションの値を辞書で指定します。たとえば、次のようになります。上のように定義しておいた場合、まず、ドメインpstn に対するコールのうち、その番号が未処理の
コールがすべてgatewaycaller アプリケーションに送られます。ここで、電話の受け手の国がス
エーデンの場合(E.164 番号では+46 で始まります)、"gw1" がgatewaycaller アプリケーション
に送られます。それ以外の場合、"gw2" がgatewaycaller アプリケーションに送られます。
その後、gatewaycaller アプリケーションにより、必須のPSTN 設定値がすべて読み取られます。
このとき、PSTN 設定値が辞書だったときには( ここではPSTNGatewayName)、その辞書のいずれか
の要素(つまり、gw1 またはgw2) の値が使用されます。
ユーザーが発信した相手先電話番号が「短い」電話番号(国コードと地域コードの両方を除いた電話 番号)だけの場合、その電話番号は、ユーザー自身の地域の番号と解釈されます。
CommuniGate Pro サーバーには、上記の電話番号用のルータレコードが用意されています (CommuniGate Pro をインストールしたときに自動的に作成されます)。このルータレコードにより、コールの宛先がローカルドメインのアドレスで、かつ7 桁の番号の場合、コールはすべてlocalAreaCode アプリケーションにルートされます。
localAreaCode アプリケーションではコーラーの認証が行われ、この認証は必須です。認証後、次 のPSTN 設定(アカウントの設定)が取り出されます。
localAreaCode アプリケーションの起動アカウントは、ドメイン管理者アクセス権を持ったアカウ ントでなければなりません。これは、起動アカウント以外のアカウント(例えばコーラー) の設定情 報の取り出しが必要なためです。起動アカウントとしては自動的に生成されるアカウント、つまり postmaster やpbx を使用できます。
また、gatewayCaller アプリケーションには、パラメータとしてデスティネーション番号(数値 アドレス、つまり相手の電話番号) が渡されることが必要です。localAreaCall アプリケーションの起動後、コーラーの国コードと地域コードがコーラーのアカウ ント設定(PSTNAreaCode)から取り出され、その値から数字以外の記号がすべて削除されます。そ の後、その値(国コードと地域コード)、発信(相手先)番号、ドメイン名@telnum が結合されま す。最後にlocalAreaCall アプリケーションによって、コール要求が結合後のアドレスにリダイ レクトされます。
リダイレクトされた要求は、シグナルモジュールによってルータを使って処理されます。処理後、要求 はPSTN ゲートウエイに送信されるか、または何らかのVoIP アドレスに直接送信されます(マッピ ングが成功した場合)。
多くの国では、域外(市外)電話と国際電話の付加番号としては、異なる形式を用いています。つま り、域外電話の場合は0 地域コードローカル番号の形式、国際電話の場合は00 国コード地域 コードローカル番号という形式を使用しているのが普通です。
CommuniGate Pro ユーザーが同じ国にいるCommuniGate Pro ユーザーに国内電話(域外電話) をかけ る場合、その電話は単一のルータレコードで問題なくルートできます。例えば、CommuniGate Pro ユーザーが全員ドイツにいるときには(国コードは49、域外電話の付加番号は0)、次のルータレ コードを使って国内電話をルートできます。
緊急対応センターの電話番号(緊急電話番号) は国によって異なります。たとえば、北米では911、 西ヨーロッパでは112 です。
こうした緊急電話番号へのコール( ドメインは任意) は、ルータを使ってemergency アプリケーションにルートすることで処理できます。ルータレコードは次の通りです。emergency アプリケーションの起動アカウントは、ドメイン管理者アクセス権を持ったアカウント でなければなりません。これは、起動アカウント以外のアカウントの設定情報の取り出しが必要なた めです。起動アカウントとしては自動的に生成されるアカウント、つまりpostmaster やpbx を使 用できます。
emergency アプリケーションによって取り出される[PSTNEmergency] の値と、その後の処理は次 の通りです。その後、emergency アプリケーションでHTTP 応答が受信されますが、このHTTP 応答の 内容は文字列または配列で、デスティネーション(送信先) アドレス(単一または複数) が 格納されていなければなりません。
最後に、emergency アプリケーションによって、指定されたデスティネーションアドレスにコールがリダイレクトされます。
PSTN ゲートウエイには基本的には、CommuniGate Pro サーバーへのコール(受信コール) を、その PSTN ゲートウエイを介してCommuniGate Pro サーバーに送信するという機能があります。ただし、 送信ゲートウエイ(gatewaycaller を使用、上記を参照) と同じような問題があります。例えば、 コールトランスファー(第三者への切り替え) ができない、メディアストリームの切り替えが不可能 といった問題があります。
このような問題は、受信コールをCommuniGate Pro のPBXアプリケーション(gatewayincoming) にルートすることで解決できます。その場合、gatewayincoming アプリケーションはB2BUA とし て動作します。
一方、受信コールがCommuniGate Pro のアカウントや、その他のオブジェクトに送信された場合で も、ゲートウエイとエンドユーザーのデバイスとの間で直接セッションが確立されますが、上記のよ うな問題が発生します。
また、PSTN ゲートウエイから送られてくるコールの中には、そのアドレスによっては必ずしも CommuniGate Pro のリアルタイムアプリケーションで応答されないものもあります。こういったコー ルは、gatewayincoming アプリケーションにルートすることで処理できます。gatewayincoming はB2BUA として動作し、タスク(コールレグ) を生成してデスティネーションにコールを実行し たり、コールを橋渡したりという処理を行います。これは、送信コール処理用のアプリケーションで あるgatewaycaller と同じです。
gatewayincoming アプリケーションのパラメータは、デスティネーションアドレスです。例えば、 受信コール要求のアドレスのドメインがincoming.company.dom の場合、次のルータレコードを 使って受信コールをgatewayincoming アプリケーションに渡すことができます。
PSTN 設定は、カスタムアカウント設定の一部です。ただし、WebAdmin インターフェイスのメイン のアカウント管理セクションの[Custom Settings] ページには、PSTN 設定のリンクはありません。 ここではなく、[Account Settings] ページと[Account Default Settings] ページにPSTN 設定のリンク があります。
PSTN アカウント設定を行いたい場合、[PSTN] リンクをクリックします。クリック後、[PSTN Settings] ページが表示されます。
A Domain Administrator should have the PSTN Settings Access Right to modify PSTN Settings.