Overview  

  OpenScape Voice Tutorial  

 

 Overview    Next Section

FRAMES     NO FRAMES    


 

Contents

 

OpenScape Voice CSTA Protocol

OpenScape Voice CSTA Operational Model

CSTA Service Feature – CSTA Monitored Subscriber

CSTA Protocol Transport considerations

Configuring the OpenScape Voice to run CSTA applications

Application Connectivity

Subscriber Management

 


 

OpenScape Voice CSTA Protocol

 

OpenScape Voice CSTA Operational Model

OpenScape Voice native CSTA interface is conformant ECMA 269 switching function CSTA service boundary. The OpenScape Voice functions in a limited fashion as a computing function.  OpenScape Voice augments its native CSTA interface services with a non-conformant version of ECMA TR-87 SIP User Agent CSTA supported by the OpenStage phone family.

CSTA Service Feature – CSTA Monitored Subscriber

Any non-virtual subscriber provisioned in the OpenScape voice can be configured to be a CSTA subscriber, e.g. been provisioned with the “CSTA Access” feature. Depending of the capabilities of the SIP device used by the subscriber, CSTA subscribers can be provisioned as CstaType 1, which basically uses the 3PCC features provided by the OpenScape Voice or CSTA Over SIP which uses the uaCSTA capabilities and Server Based features provided by the OpenScape Voice. Some of the main elements of the CSTA Model are listed below:

 

Device –Device is a CSTA object that corresponds to a physical entity such as a phone, a logical entity such as a user, or an entity that is a combination of both. In the OpenScape Voice, Devices are always represented in Fully Qualified Format (FQN – Fully Qualified Number0, which can be represented by a number in GNF (Global Number Format – e.g. +15619231000) for Subscribers with a DID or Fully Qualified Private Number (e.g. 9231000) for numbers that belong to a Private Numbering Network (no DID)

 

Monitor – Monitor is a special object that enables event reporting. A Monitor can be placed, for example, on Device or Call objects to observe and keep track of the states of the Provider objects.

 

Call – Call is a CSTA object that represents a communication relationship between one or more devices. The type of communication (voice, data, message, or any combination) is a property of the call.

 

Connection – Connection is a CSTA object that represents a logical relationship between a call object and a device object.

 

 

Key concept: The application built with CSTA-SDK MUST always use the FQN of the subscribers that will be monitored by CSTA. All CSTA messages reported by the OpenScape Voice will have devices in FQN format, unless explicitly described in the CSTA Interface Specification

 

CSTA Protocol Transport considerations

The OpenScape Voice CSTA TCP interface conforms to ECMA 323 – Appendix G – TCP without SOAP G.2 format. The CSTA TCP IP address is provisioned in OpenScape Voice as described in section “ Configuring the OpenScape Voice to run CSTA applications”, and will be known by the application by configuration or discovery using DNS SRV record. 

Each CSTA application is responsible to establish CSTA connections on the provisioned TCP IP address.

Starting with CSTA-SDK V1.2.0, HTTP/SOAP connection between CSTA-SDK and OpenScape Voice is supported, which implements ECMA-348. To use HTTP/SOAP connection, you must have OpenScape Voice V7 or higher. The machine where your CSTA Application is running must be configured on OpenScape Voice Server as a known CSTA Application. See the section on how to “Configure HTTP/SOAP CSTA Application on OpenScape Voice Server”.

Starting with CSTA-SDK V1.3.0, a TLS connection between CSTA-SDK and OpenScape Voice (OSV) is now supported. The OpenScape Voice requires mutual authentication (MTLS), and the user of CSTA SDK has to provide a keystore file and a truststore file on the machine where CSTA-SDK is running, in order to connect to the OpenScape Voice via TLS.

To generate a keystore file:

keytool -importkeystore -srckeystore client.p12 -srcstoretype pkcs12 -destkeystore client_keystore.jksdeststoretype jks

Input is “client.p12” file, which stores a private key along with its X.509 certificate. The CA who issues this certificate must be known to OSV. It would be easier if the client uses the same CA as OSV.

Output is the keystore file that required by CSTA SDK.

To generate a truststore file:

keytool -importcert -trustcacerts -keystore  client_truststore.jks -storetype jks -storepass <client_truststore_password> -file server_certificate.pem

Input is “server_certificate.pem”, which is the certificate of OSV. OSV has a default certificate file “root.pem” under /usr/local/ssl/certs which can be used to generate the truststore file for testing purpose.

Output is the truststore file that required by CSTA SDK.

The user may need to set a password for keystore and truststore.

 

Configuring the OpenScape Voice to run CSTA applications

Before running any CSTA application you need to configure the OpenScape Voice to allow them. This section is provided as a guideline that describes aspects of OpenScape Voice administration and SIP phone configuration pre-requisites to properly enable the CSTA services. There different pieces to configure:

Application Connectivity: Consists on enabling the CSTA TCP link and change packet filtering rules to allow an application to connect to OpenScape Voice

Subscriber management: Assign the CSTA service to the numbers (DNs) that the application will monitor

Application Connectivity

The instruction below refers to the configuration of the OpenScape Voice for CSTA over TCP Connections.

 

IMPORTANT: It is highly recommended that no more than 10,000 monitors are started per each TCP connection.

The packet filtering rules are changed with the OpenScape Voice CLI:

·         Log in to the OpenScape Voice as the srx user

·         Invoke the CLI and log in: startCli

·         Go to Application-level Management > Network Element Security Management (8) > Packet Filter Rules Security Management (4) > Create (1)

·         Enter a name for the rule

·         Hit the Enter key until the Remote IP Address option - this is the important piece!

·         Enter the IP address of the computer where your application will run

·         Take the default value for the other options until you reach Direction

·         Enter 3 (both ways) for Direction 

·         Take the default value for the other options until the prompt to execute the action

·         Enter yes to save the new rule

Refer to OpenScape Voice CLI configuration and administration documentation for your installation for specific management requirements.

Configure HTTP/SOAP CSTA Application on OpenScape Voice Server

·         Log in to OpenScape Voice Assistant

·         Select Administration > Signaling Management > CSTA

·         Set HTTP/SOAP Listener Port Number. Default is 7780, different than TCP connection port which is 1040.

·         Select Applications, and add one new Application Server to represent your CSTA-SDK Application

·         Specify your CSTA-SDK Application’s Name, listening IP and Port

 

Subscriber Management

The CSTA service is assigned to each subscriber with the OpenScape Voice Assistant:

·         Log into the OpenScape Voice Assistant

·         Select Business Group > Members > Subscribers and then select the subscriber number

·         Select tab Features and in section Subscriber Features select 'CSTA Access' in the field Feature Name.

·         Click on 'Save' to store the setting

CSTA_Access_01