This chapter provides instructions for upgrading to Oracle Communications WebRTC Session Controller Signaling Engine (Signaling Engine) from an earlier version.
Because of architectural changes in the underlying WebLogic platform, there is no automated upgrade path from earlier versions of Signaling Engine to version 8.0. Instead, you must install the latest version of Signaling Engine on each of your servers and manually synchronize the following configurations from old to new:
SSL Configuration: If you are using SSL, configure SSL on every node machine using the WebLogic configuration console.
Security Providers: Configure your security providers using the WebLogic configuration console. For more information see "Configuring WebRTC Session Controller Authentication" in the Oracle Communications WebRTC Session Controller Administrator's Guide.
Signaling Engine Applications: Using the Signaling Engine console, configure your applications in the Applications tab to match those from your old installation. For more information see the Oracle Communications WebRTC Extension Developer's Guide.
Signaling Engine Packages: Using the Signaling Engine console, configure your packages in the Packages tab to match those from your old installation. For more information see the Oracle Communications WebRTC Extension Developer's Guide.
Groovy Script Library: If you have customized your Signaling Engine Groovy Script Library, migrate your changes to the Script Library tab in the Signaling Engine console.
Proxy Registrar Addresses: Using the Signaling Engine console, set the proxy registrar address in the Script Library tab. For more information see the Oracle Communications WebRTC Extension Developer's Guide.
Media Engine Nodes: Using the Signaling Engine console, configure information for your Media Engine nodes. For more information see the Oracle Communications WebRTC Extension Developer's Guide.
This section lists the major changes affecting upgrade deployments in the latest version of Signaling Engine.
Signaling Engine replicated domains use Oracle Coherence for data persistence and caching instead of the Data Tier of earlier versions. Replica servers are not required in Signaling Engine replicated deployments and can either be removed from the configuration or repurposed as additional engines.
In addition to the Signaling Engine engine application (wsc), and the administration interface (wsc-ui), an additional Lightweight Proxy/Registrar application is deployed by default. For more information on configuring the Signaling Engine Lightweight Proxy/Registrar, see "Using the Lightweight Proxy Registrar" in the Oracle Communications WebRTC Session Controller System Administrator's Guide.
Note:
Unless the Lightweight Proxy/Registrar is configured, it has no impact on default Signaling Engine functionality.Signaling Engine still supports three security authentication methods, but two of them, REST and OAuth have added additional configuration options. For details on configuring Signaling Engine Security, see "Configuring WebRTC Session Controller Authentication" in the Oracle Communications WebRTC Session Controller System Administrator's Guide.
In the Script Library tab of the Signaling Engine console, the ME_CONFIG_NAME_APP and ME_CONFIG_NAME_NET configuration constants have been removed and the following constants added:
DMA_ENABLED: Default: false. When set to true, Dynamic Media Anchoring is enabled and WebRTC Session Controller Media Engine (Media Engine) handles media anchoring duties.
ME_CONFIG_NAME_DMA: Default web-to-web-anchor-conditional. When set to web-to-web-anchor-conditional, if an WebRTC session is brokered between two WebRTC compliant endpoints, Media Engine lets media streams pass directly between the two endpoints. When set to web-to-web-anchored, media streams are always routed through Media Engine between the two endpoints.
In addition to register, call, and message notification, Signaling Engine provides the following new packages in the Packages tab of the Signaling Engine console which can be added to new and existing Signaling Engine applications:
capability: Allows the implementation of capabilities exchange between endpoints.
messaging: Allows the configuration of session-less stand-alone messaging exchange between endpoints.
chat: Support bi-directional real-time chat between endpoints.
file_transfer: Supports file transfer between endpoints.
Logging levels of trace, debug, info, and warn, can now be set in the Signaling Engine sub tab of the Signaling Engine console Configuration tab. Logging levels can be set for the following Signaling Engine components:
Diameter
Groovy
HTTP/WebSocket
JSON
Media
Others
Security
SIP
Default logging levels can be overridden for each Signaling Engine engine. For more information on configuring logging, see "About Signaling Engine Properties and Log Settings" in the Oracle Communications WebRTC Session Controller System Administrator's Guide.
Instead of a single, monolithic wsc.js JavaScript file, the WebRTC Session Controller JavaScript SDK has been split into the following separate JavaScript files:
wsc.js: A composite JavaScript file provided as a convenience for backwards compatibility.
wsc-call.js: The Call package API implementation.
wsc-capability.js: The Capabilities Exchange API implementation.
wsc-chat.js: The session mode chat API implementation.
wsc-common.js: Common utility functionality used by the other JavaScript packages.
wsc-filetransfer.js: The file transfer API implementation.
wsc-messaging.js: The stand alone messaging API implementation.
wsc-msgalert.js: The message notification API implementation.
For more information on the WebRTC Session Controller JavaScript library, see "WebRTC Session Controller Support Libraries" in the Oracle Communications WebRTC Session Controller Application Developer's Guide.
For information on high availability environments, see "Failure Prevention and Automatic Recovery Features" in the Oracle Communications WebRTC Session Controller System Administrator's Guide.
The following example shows the theoretical steps involved in upgrading a replicated domain. For this example, the deployment model consists of three machines:
An Admin server, with the IP address 10.1.1.1.
A clustered machine with the IP address 10.1.1.2, hosting an engine, engine1, and a replica, replica1.
A second clustered machine with the IP address 10.1.1.3, hosting an engine, engine2, and a replica, replica2.
To upgrade the replicated domain:
Install Signaling Engine on each of the three machines following the instructions in "Installing WebRTC Session Controller Signaling Engine."
Create Oracle Communications WebRTC Session Controller Replicated Domain domains on each machine using the same configuration parameters from your old Signaling Engine installation. See "Creating and Configuring a WebRTC Session Controller Signaling Engine Domain."
Note:
You must select the Administration Server and Managed Servers, Clusters and Coherence advanced options when configuring the replicated domain otherwise Signaling Engine will fail to start.Note:
Replicas are no longer required. You can either repurpose replica1 and replica2 as additional engines or decommission them completely.Stop the old Admin server and start the new one using the command:
cd Domain_home/bin
./startWeblogic.sh
If you are using SSL, login to the Signaling Engine WebLogic console at http://10.1.1.1:7001/console and do the following:
Expand the Environment node in the Domain Structure panel and click Servers.
In the Configuration tab of the Summary of Servers pane, select an engine server, check SSL Listen Port Enabled, and set the SSL Listen Port in the engine server General tab.
Click Save to save your configuration.
Repeat for the remaining engine servers.
Login to the Signaling Engine WebLogic console at http://10.1.1.1:7001/console and configure the WebLogic security realm using the same parameters from your old installation. For more information on configuring a security realm, see "Configuring WebRTC Session Controller Authentication" in Oracle Communications WebRTC Session Controller System Administrator's Guide.
Login to the Signaling Engine console at http://10.1.1.1:7001/wsc-console and configure the following items using the same parameters from your old installation:
In the Applications tab, re-create the application configurations from your old installation.
In the Script Library tab, set the PROXY_SIP_URI to the URI of your proxy server/registrar, and set DMA_ENABLED to true.
In the Configuration tab, select the Media Engine sub tab and configure your Media Engines using the parameters from your old installation.
In the Packages and Script Library tabs of the Signaling Engine console integrate any custom code changes from your old installation.
Stop the engine and replica servers from your old installation.
On the first clustered machine, execute:
cd Domain_home/bin
./startManagedWebogic.sh engine1 t3://10.1.1.1:7001
Note:
If you have repurposed replica1 as an additional engine start it as well.On the second clustered machine, execute:
cd Domain_home/bin
./startManagedWebogic.sh engine2 t3://10.1.1.1:7001
Note:
If you have repurposed replica2 as an additional engine, start it as well.Configure a third-party load balancer as required.
Note:
Signaling Engine no longer includes load balancer support.Verify that your applications work as expected.