|
|
|||
Overview Next Section |
||||
Contents
OpenScape
Voice CSTA Operational Model
CSTA
Service Feature – CSTA Monitored Subscriber
CSTA
Protocol Transport considerations
Configuring
the OpenScape Voice to run CSTA applications
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.jks –deststoretype
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
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
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