Here is a summary of the TWSS components, database tables, and other network elements that are required when you deploy Parlay X Third Party Call over Parlay.
This topic provides information about what is needed in the network in order to deploy the Web service implementation. The order in which the information is presented does not represent the order in which the elements should be installed.
Do not deploy Parlay X Third Party Call over Parlay on the same application server as Parlay X Third Party Call over SIP/IMS.
The Access Gateway must be installed in the network and is typically in a different cluster than the Web service implementation. All incoming calls are routed through message processing flows, which are deployed on the Access Gateway. A default Third Party Call message processing flow is provided and should be deployed, unless you are using a custom message processing flow.
The Service Policy Manager must be installed in the network, either in the Service Platform cluster or in its own cluster. The Service Policy Manager manages policies associated with the Web service implementation. When the database tables are created, they are populated with default policies. For information about default policies, see the Reference section of this information center.
The consoles must be installed on the deployment manager node for the cluster where the Web service is deployed. The TWSS Administration Console must be installed before the Parlay Administration Console.
The TWSS Administration Console is used to configure the Web service implementations and the Service Platform components and to specify how they should be invoked. It is also used to administer MBeans that are included in the EAR file for the Web service implementations. It is managed through JMX.
The Parlay Administration Console is used to configure the Parlay Connector.
Both console plug-ins act as extensions to the Integrated Solutions Console.
Service Platform component | Required? | Remarks |
---|---|---|
Admission Control | No | When the Admission Control component Web service is available, the Web service implementation issues a VerifyAdmittableRequest to the Admission Control component to determine if the service request can be processed. |
Traffic Shaping | No | Recommended in an integrated environment–that is, in a full setup where all of the TWSS components (Access Gateway, Service Policy Manager, and so forth) coexist. |
Network Resources | No | Recommended in an integrated environment. |
Notification Management | No | Not used by Parlay X Third Party Call over Parlay. |
PX Notification | No | Not used by Parlay X Third Party Call over Parlay. |
Address Masking | No | When deployed, the Address Masking component Web service works in conjunction with the Address Masking mediation primitive (part of the processing flow for the Access Gateway). |
Fault and Alarm | No | Recommended. When the Fault and Alarm component Web service is
available, the Web service implementation issues a RecordFaultRequest request
to the Fault and Alarm component to generate a fault or an alarm when
the following conditions occur:
|
Usage Record | No | Recommended. When the Usage Record component Web service is
available, the Web service implementation uses it to record information
about services rendered for status and billing purposes. A usage record is generated for the makeCall event and for the endCall event. The usage record includes information about how many calls were made, how long the calls lasted, and whether there were any associated charges. |
Parlay X Third Party Call over Parlay uses the Service Platform's Integrated Solutions Console interface and MBeans to provide configuration settings. The wsadmin for MBeans is also available for the configuration settings.
The Parlay Connector enables the Web services to communicate with a Parlay gateway. In a production environment, an additional Parlay gateway may be configured for failover. When you have multiple Parlay gateways in your network, you must configure unique service IDs for each gateway. The Web service implementations use the gateway session IDs to track Parlay X Third Party Call over Parlay requests sent to the gateway. The Parlay Connector is included in the file Pxx_ParlayConnector.ear (where xx is the Parlay version, such as 42 or 33).
To configure the Parlay Connector, use the Parlay Administration Console. The Parlay Administration Console must be installed on the network deployment manager for the cluster where the Web service is deployed.
Database tables must be created to store configuration and policy data. You can use a single database to store this data, or you can create a unique database for each type of data. When you use the First Steps script, the required tables are created for a single database configuration.
If you choose to use multiple unique databases, or if you prefer to configure the database tables manually, you can find additional information in the topic Planning for the database.
The Parlay X Third Party Call over Parlay Web service implementation interacts with network elements and other entities. The following interactions are important.