Version 5.1
Signals |
|---|
| |||||||
|
|
Version 5.1 |
|||||||||||||||||||||||||||||
|
|
For addresses not assigned to any local Account, the Router can use global and local ENUM services, as well as CommuniGate Pro Forwarders.
When the gatewayCaller application receives an incoming call, it requires authentication. As a result, only the users with the Accounts on your CommuniGate Pro Server or Cluster can place calls via this application.
When an authenticated call request is received, the application retrieves and uses the following Account PSTN Settings:
A CommuniGate Pro Account can use a default value for each of its setting (taken either from the Domain-wide or Server-wide/Cluster-wide Default Settings) or a setting value can set explicitly for that Account. As a result, all Accounts in all Domains can use the same Gateway and same Gateway credentials, but different Caller ID settings, or each Domain and/or each Account can use its own Gateway, with Domain or Account-specific credentials.
The applications needs to retrieve Settings from other Accounts,
so it should be started on behalf of an Account with the Domain Administrator access rights.
The automatically created postmaster or pbx Accounts can be used.
The application expects to get the destination number as its parameter.
The following Router record routes all addresses in the fictitious pstn domain
to the gatewaycaller application started on behalf of the pbx Account in the Main Domain,
and it passes the "user part" of the pstn domain address as the application parameter:
After processing all Account Settings, the application starts a new Task and instructs that Task
to send a call request to the selected Gateway using the retreieved Account settings. If the call
succeeds, the original and new Tasks "bridge" the media streams.
The original Task processes Signal requests from the caller, the second Task processes
the requests from the Gateway. Some of these requests are processed by the Tasks themselves,
some are relayed to the peering Task for relaying to the caller or the gateway.
The technology used to implement this type of call setup (when a call is established using two formally independent Signalling sessions) is called a Back-to-Back User Agent (B2BUA).
When a caller wants to Transfer a call, the Transfer request is sent to the original Task. This Task implements the requested call transfer itself, switching to some other VoIP device/entity. The second Task does not send any Transfer request to the Gateway, but it may send a call update (SIP re-INVITE or UPDATE) request to the gateway in order to redirect its media streams to the new call participant.
Some PSTN Gateways do not support even the simple call update requests. Specify the name of those Gateways with a leading asterisk (*) symbol. The application will remove that symbol from the name, and it will not bridge media streams. The application will use a CommuniGate Pro Media Server channel to relay media between the caller and gateway. If the caller switches its media address by sending a call Update request, or if the caller sends a call Transfer request, the Media Server channel updates its internal information, and no request is sent to the Gateway, which continues to exchange media data with the Media Server channel.
If you need to use several different gateways per user or per domain (depending on the destination), you can specify the gateaycaller PSTNxxxxxx settings as dictionaries. For example:
You can Route different PSTN numbers to different gateways by passing the second parameter to the gatewaycaller application:
All calls to unprocessed numbers in the pstn domain will be routed to the gatewaycaller application,
and this application will get the second parameter of "gw1" if the callee is in Sweden (a E.164 number starting with +46),
and "gw2" in all other cases.
The gatewaycaller application reads all required PSTNxxxxxx settings. If a settings value is a dictionary,
it takes either the "gw1" or the "gw2" element from the dictionary.
A Router record created during a CommuniGate Pro Server installation routes all calls to 7 digit number address in any local Domain to the localAreaCode application.
The stock localAreaCode application requires the caller to authenticate, and then it retrieves the following Account PSTN Settings:
The applications needs to retrieve Settings from other Accounts,
so it should be started on behalf of an Account with the Domain Administrator access rights.
The automatically created postmaster or pbx Accounts can be used.
The application expects to get the dialed destination number as its parameter.
The following Router record routes all 7-digit addresses in all local Domains
to the localAreaCall application started on behalf of the pbx Account in the Main Domain,
and it passes that address (a 7-digit number) as the application parameter:
The application retrieves the callers country code and the local area code from the caller's PSTNAreaCode Account Settings, removes all non-digit symbols from the Setting value, catenates the "cleaned" with the dialed number and the @telnum domain name, and Redirects the call request to the resulting address.
The Signal module processes the redirected request using the Router, so it can be directed to a PSTN Gateway or (after successful mapping) directly to some VoIP address.
If all CommuniGate Pro users are located in the same country, domestic calls can be properly routed with a single Router Record. For example, if all CommuniGate Pro users are located in Germany (country code 49, 0 is the out-of-area prefix), the following Router record can be used:
You can also use the localAreaCall application to properly route Domestic calls. Route all calls with the domestic prefix to the localAreaCall application, but specify the second parameter - a string c:
Use the Router to redirect calls to these numbers (in any Domain) to the emergency application:
The stock emergency application requires the caller to authenticate, and then it retrieves the following Account PSTN Settings:
The applications needs to retrieve Settings from other Accounts,
so it should be started on behalf of an Account with the Domain Administrator access rights.
The automatically created postmaster or pbx Accounts can be used.
The application processes the retrieved PSTNEmergency setting value:
The application makes an HTTP request using the emergency.settings dictionary as parameters for the HTTPCall CG/PL operation. The call body is a dictionary with the following elements:
When the application receives an HTTP response, the HTTP response body should contain a string or an array with the destination address(es).
The application redirects the call to the specified address(es).
If incoming calls are routed to the CommuniGate Pro PBX application, that application acts as a B2BUA and addresses these issues.
If incoming calls are directed to individual CommuniGate Pro Accounts (or other Objects), a direct session between the Gateway and the end-user device can be established, and all Gateway problems will be exposed to the end-user.
To solve PSTN Gateway problems when directing calls to addresses that are not necessarily answered with CommuniGate Pro Real-Time Applications, you may want to route all these calls to a special gatewayincoming application. This application, acting as B2BUA, will create a separate Task ("call leg") to call the destination and it will bridge the call in the same way the gatewaycaller application processes outgoing calls.
The stock gatewayincoming application expects the destination address to be delivered to it as an application parameter. If the Gateway sends incoming requests to your system using addresses in a special domain incoming.company.dom, then the following Router record will direct them to the gatewayincoming application:
Click the PSTN link to open the PSTN Settings page:
A Domain Administrator should have the PSTN Settings Access Right to modify PSTN Settings.