2 Configuring WebRTC Session Controller

This chapter describes how to configure application profiles, the Signaling Engine, the Media Engine, and the Notification Service for multitenancy in the WebRTC Session Controller web console.

About Multitenancy

WebRTC Session Controller 7.2 is a platform that can support multi-tenant Software as a service (SaaS) applications that you host elsewhere. An in-premise installation of WebRTC Session Controller enables multiple departments of a customer to use WebRTC Session Controller for their specific applications. The main benefits of multi-tenancy in WebRTC Session Controller are increased density, tenant isolation, and simplified cloud configuration and management.

In your WebRTC Session Controller installation, a tenant represents a configuration scope for a customer or a department that is authenticated to use its services. Multiple tenants can access a single WebRTC Session Controller installation or it can be configured as a single tenant installation. A tenant is associated with a tenant key that allows you to manage and track all usage of the installation by that customer or department. Every user account that is authenticated to access WebRTC Session Controller is associated with a tenant.

About Tenants

As the administrator of WebRTC Session Controller, you set up and manage the configuration for one or more tenants. These configurations allow the tenants to utilize the WebRTC Session Controller installation for their users. WebRTC Session Controller establishes the tenant profile with some default resource limits and allots an equal slice of the available resource limits to the tenant profile. In a multitenancy scenario, the tenant profile configuration WebRTC Session Controller enables a partitioning that isolate each tenant.

As a system administrator for the tenant, you set up the global configuration of the runtime environment for the tenant. To do so, you first review these default resource limits and usage parameters at the global level and update them for your environment. WebRTC Session Controller displays these global settings as selections for configuring the profiles for applications that you own in the environment.

When you have configured the global settings for your WebRTC Session Controller environment you register the individual applications for your customers to use. You create application profiles to associate with each tenant. To create the application profile, you can select from the available (global) values and enter others specific to the application.

About the Tenant Key

When a tenant profile is created, WebRTC Session Controller generates a key as an identifier for the tenant. WebRTC Session Controller uses this key to associate the request with a tenant and identify the tenant profile. It is recommended that key is not hard coded in the applications. For example, SaaS application could store this key in a database as a way for the application to access the key.

About Managing Tenant and Application Profiles

Tenants are registered with specific SaaS applications using the tools within the SaaS applications or in the cloud infrastructure. Both application profiles and tenant profiles contain the following information:

• Security realm to which the tenant or application belongs.

• Resource limits.

• Statistics to collect on the tenant or application.

• Groovy properties defined for the use of that tenant.

Application profiles contain in addition, information on any packages and scripts that are defined for them.

How Multitenancy Works

A websocket connection belongs to a tenant profile. WebRTC Session Controller associates the HTTP request that is used for the login and the request used for the websocket handshake with the tenant profile.

Web and mobile applications include the tenant key as the HTTP request parameter named tenant_profile_key. When a single user identity is associated with multiple tenant profiles, a request from each tenant can reach different SIP proxy registrars. WebRTC Session Controller Signaling engine stores the tenant key as the value of the tenantToken parameter in the SipURI of the contact header in the requests it sends to lightweight proxy registrar. In turn, the lightweight proxy registrar incorporates this information in its decision making process and sends each request from a tenant to the corresponding proxies.

In the runtime environment, WebRTC Session Controller gathers and stores the statistics for each tenant profile and each application profile. Any notification configuration contains the associated tenant identification information. And the resource limit profiles contains the resource limit for maximum number of notifications.

WebRTC Session Controller allows traffic to domains for a tenant based on the domains configured in the tenant profile. If your installation supports SaaS applications, configure the domain name in the tenant profile. Doing so enables your SaaS applications to provide cross-domain access.

About Service Level Agreements

Service level agreements (SLAs) are set between a SaaS application and its tenant. These SLAs translate the defined quantities of resources within the services used by the SaaS application. For example, an SLA may specify usage parameters for services such as the database or messaging server. In addition, where necessary, SaaS applications can allot resources to their tenants and monitor those resources within WebRTC Session Controller. The users of the tenants use a "slice" of the SaaS application.

About Managing Tenant and Application Profiles

The following sections in this chapter describe how you configure tenant profiles and manage global- and application-level configurations in WebRTC Session Controller Administration Console.

You can also use MBeans to create and remove tenant profiles, configure and manage application profiles in the runtime environment using MBeans. See "Managing Application and Tenant Profiles Using WebLogic Scripting Tool".

WebRTC Session Controller provides application level statistics for each tenant. For information on monitoring the tenancy and applications, see "Monitoring Statistics and Resource Limits". For an explanation on the MBeans, see WebRTC Session Controller Configuration API Reference.

About Secure Connections

This section describes some of the security-related features in WebRTC Session Controller.

About Security for Connections Between the Signaling and Media Engine

All communication between the WebRTC Signaling Engine and any Media engine uses the HTTPS protocol. For all media engines that you add to WebRTC Session Controller, ensure that the required SSL certificates are configured and stored in WebLogic Server.

Storing and Managing Certificates in WebLogic Server

When you configure SSL, Oracle recommends using separate keystores for both identity and trust because the identity keystore (holding the private key and associated digital certificate) and the trust keystore (trusted CA certificates) may have different security requirements. It also provides separate tools and procedures for using keystores and certificates in a development environment and a production environment. For more information, see the description about "Configuring Keystores" in Oracle Fusion Middleware Administering Security for Oracle WebLogic Server.

For information about managing a new WebRTC Session Controller Media Engine (ME) system, see "Managing and Administering ME Systems".

Disabling the HTTPS Setting in WebLogic Server

If your installation uses a hardened network configuration and need to disable the HTTPS protocol setting, then, use the following system property when you start the WebLogic server, -Doracle.wsc.se-me-http=true.

About Security for Connections to Cloud Messaging Providers

WebRTC Session Controller connects to Google Cloud Messaging and Apple Push Notification Service over secure channels.

If you are providing services using APNS, ensure that you access Apple Development Center to create appropriate certificates and install them for use in your WebRTC Session Controller system. The APNS certificates are stored in the wsc-config.xml file using Base64 encoding. Passphrases are encrypted and stored in this file using Weblogic encryption mechanism.

When you register your applications, you enter these certificates in WebRTC Session Controller. See "Creating Applications for the Notification Service".

About Security for WebRTC Application Features

This section describes some of the security features in the WebRTC-enabled applications.

RTCDataChannel Interface

The RTCDataChannel interface in WebRTC-enabled applications is secured with Datagram Transport Layer Security (DTLS). DTLS is a derivation of SSL protocol and used to provide communications privacy for datagram protocols and is built-in element of WebRTC Session Controller.

Device Handover

By default, WebRTC Session Controller does not allow session transfers. To support device handovers in your applications, you should enable session transfer validation when starting the WebRTC Session Controller server. Your application must be in charge of session transfer information security, because this data is transmitted between customer application network.

TURN Authorization

The Signaling Engine stores the secret key provisioned on the media engine in the wsc-config file using Weblogic encryption mechanism. The credentials are passed to the client over WebSocket. Use Web Services Security (wss) so that these credentials are not sniffed on the network.

About WebRTC Session Controller Console Configuration

The Home, Packages, and Script Library tabs provide access to the configuration settings at the global level. As Table 2-1 shows, the Home tab enables you to configure the Signaling Engine, Media Engine, and the Notification Service for WebRTC Session Controller.

Figure 2-1 WebRTC Session Controller Administration Console Configuration Tabs

The values configured in the Home and Packages tab become the default settings for the individual applications you create in the Application Profiles tab.

You can also configure WebRTC Session Controller console options using configuration Mbeans. See the oracle.wsc.core.configuration.admin.mbean package page for more information about using these MBeans in WebRTC Session Controller Configuration API Reference.

About the Administration Console Configuration Process

To manage WebRTC Session Controller for messaging applications associated with an access account, do the following:

1. Access the configuration tabs in WebRTC Session Controller administration console. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

2. Configure and update the general parameters for WebRTC Session Controller described in each of the following sections:

   • Configuring Default Parameters for WebRTC Session Controller Applications.

   • Configuring Messaging Packages.

   • About the WebRTC Session Controller Global Script Library.

3. Configure and update the specific parameters for each application your account creates, as described in "Managing WebRTC Session Controller Application Profiles".

Accessing the WebRTC Session Controller Console Configuration Tabs

The WebRTC Session Controller console resides in the same domain as your WebRTC Session Controller installation. When you start your domain, both the Oracle WebLogic administration console and the WebRTC Session Controller console become available.

The following procedure requires a running WebLogic server, and that you know the WebLogic user name and password that you created for the domain. See the discussion about "creating and starting a WebLogic domain" in WebRTC Session Controller Installation Guide.

To access the WebRTC Session Controller console configuration tabs:

1. Start the WebRTC Session Controller domain server.

2. Open a web browser.

3. Access one of the following URLs, as appropriate.

   • http://localhost:port/wsc-console

   • If HTTP security is configured:

     https://localhost:port/wsc-console

   • To start the WebRTC Session Controller console on a local system using the default port:

     http://localhost:7001/wsc-console

   localhost is the IP address of the system running the WebLogic domain or the value localhost and port is the port of the domain. The default port is 7001.

4. The WebLogic user login screen appears. Enter the Username and Password you set when creating the WebLogic domain.

5. Click Login.

   The WebRTC Session Controller console window appears. It displays the Home, Packages, Script Library, and Application Profiles configuration tabs as seen in Figure 2-1.

About Templates for Message Notifications

Review this section before you configure the notification service supported in your WebRTC Session Controller installation.

As a WebRTC Session Controller system administrator, you can configure application-specific templates that specify the default parameters for the push notification payload for each application. The push notification is made up by combining the message payload provided with the application settings with the message payload received from the application.

A template entry allows WebRTC Session Controller to construct the message correctly based on the cloud messaging provider that the message is targeted for. WebRTC Session Controller determines the format based on the application-id that the browser application sends along with the message.

In the WebRTC Session Controller administration console, there is a Template entry for each application profile configured in the Notification Service tab. Provide a JSON message as a template for the push payloads, by using this entry.

About the Push Payload Construction for Android Notifications

Example 2-1 shows the contents of the Template field for an Android application with the application ID oracle.mywsc.myandroidapp:

Example 2-1 Application Template Entry for Android Notification

{
  "collapse_key" : "app1",
  "delay_while_idle" : true,
  "time_to_live" : 60,
  "data" : {
      "wsc_time": "$data.time$",
      "wsc_from": "from $data.from$",
      "wsc_event": "Got $data.message$"
   }
}

Example 2-2 shows an example message payload that the GCM server sends for the Android application with that application ID oracle.mywsc.myandroidapp:

Example 2-2 The Message Payload Received from WebRTC Session Controller

{
  "data" : {
    "time": "15:16.2342",
    "from": "[e-mail]",
    "message": "Incoming Call"
  }
}

The runtime message payload received from WebRTC Session Controller contains the values for the time (15:16.2342), the calling party information ([e-mail]), and the event (Incoming Call). Any payload from the Groovy layer is only used for merging with the template if any dynamic parameters are specified.

The resulting payload in the push notification received by the called party shows the information merged in the following way:

Example 2-3 The Merged Push Notification (Android)

{
  "collapse_key" : "app1",
  "delay_while_idle" : true,
  "to" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx...",
  "time_to_live" : 3,
  "data" : {
    "wsc_time": "15:16.2342",
    "wsc_from": "[e-mail]",
    "wsc_message": "Incoming Call"
  }
}

The value for the "to" : attribute can be the registration ID or the device token that receives the notification. In Example 2-3, the value for the "to" : attribute is the registration ID of the application that was sent to the application when it registered with the GCM server.

About the Push Payload Construction for iOS Notifications

Example 2-4 shows the contents of the Template field for an iOS application with the application ID oracle.mywsc.myiOSapp:

Example 2-4 Application Template Entry for iOS Notification

{"aps" : {
    "alert" : "$data.message$ from $data.from$",
    "badge" : 1,
    "sound" : "chime.aiff"
    }
  }

Example 2-5 shows an example message payload that APNs server sends for the iOS application with that application ID oracle.mywsc.myiOSapp:

Example 2-5 Message Payload Received from WebRTC Session Controller

{
  "data" : {
    "time": "15:16.2342",
    "from": "[e-mail]",
    "message": "Incoming Call"
  }
}

The runtime message payload received from WebRTC Session Controller contains the values for the time (15:16.2342), the calling party information ([e-mail]), and the event (Incoming Call). Any payload from the Groovy layer is only used for merging with the template if any dynamic parameters are specified.

Example 2-6 shows the resulting payload in the push notification received by the called party:

Example 2-6 The Merged Push Notification (iOS)

"aps" : {
    "alert" : "Incoming Call from [e-mail]"
    "badge" : 1,
    "sound" : "chime.aiff"
  },
  "data" : {
    "time": "15:16.2342",
    "from": "[e-mail]",
    "message": "Incoming Call"
  }

Handling Silent Notifications

iOS7.0 and later versions support silent remote notifications where the silent notification wakes up the application in the background so that the application can get new data from the server.

Tip:

Use a template that contains application-specific data only. Do not set sound, badge, or alert in the template if you require silent notifications.

Configuring Default Parameters for WebRTC Session Controller Applications

Configure the global (default) parameters for WebRTC Session Controller through the Home tab seen in Figure 2-1. The Home tab contains three sub tabs, Signaling Engine, Media Engine, and Notification Service.

You can override these defaults when you register your applications using the Application Profile tab and configure the application profiles for your Web, Android of iOS applications.

To configure the default parameters for all the applications, complete the following tasks:

1. Configuring Global Properties for the Signaling Engine.

2. Managing Media Engine Nodes Configuration and Status.

3. Managing WebRTC Session Controller Notification Service.

Configuring Global Properties for the Signaling Engine

The Signaling Engine tab displays configuration parameters grouped under Integration Parameters, Runtime Parameters, Resource Limits, and Log Settings headings.

To configure signaling engine parameters:

1. If you are not already viewing the Signaling Engine tab, access the Home tab. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

   By default, Signaling Engine is the selected tab.

2. Click Edit in the upper right corner of the screen.

3. Alter the contents of each of the following as needed for your environment:

   1. Integration Parameters. For a description of the integration parameters, see Table 2-1.

   2. Runtime parameters. For a description of the runtime parameters, see Table 2-8.

   3. Resource Limits. For a description of the resource limits, see Table 2-3.

   4. Default Log levels. For a description of the default log levels, see "Configuring the Default Logging Level for the Signaling Engine".

   5. Logging levels for a signaling engines in a cluster. For a description of the fields, see "Logging for Single Engines in a Cluster".

4. Click Save.

Global Integration Parameters of the Signaling Engine

Table 2-1 describes the signaling engine parameters for integration with the Media Engine.

Table 2-1 Configurable Signaling Engine Integration Parameters

Parameter	Description
Proxy Registrar URI	Enter a SIP proxy server/Registrar URI. The value you enter in this field becomes the default SIP proxy server/Registrar URI for any new application you create. Access this parameter in Groovy as context.properties.proxyRegistrar using SipContext, AuthenticationContext, TemplateContext, or WebContext.
Dynamic Media Anchoring Type	Select a media anchoring option supported by WebRTC Session Controller. The possible selections are: Disabled The application should not connect to the Media Engine. web-to-web-anchor-conditional web to web conditional anchoring is used in a session when WebRTC-enabled browsers are allowed to communicate directly. If for some reason the browsers cannot communicate directly, they can communicate through WebRTC Session Controller. web-to-web-anchored web to web forced anchoring is used in a session when all media flows through Media Engine. The supported Media Engine session type, is assigned to the Groovy constant ME_CONFIG_NAME_DMA, in the Groovy library
Media Engine MSRP	Select a message Session Relay Protocol (MSRP) to Media Engine from Signaling Engine. The possible selections are: msrpwss-to-msrptcp msrpws-to-msrptcp Access this parameter in Groovy as context.properties.webMSRP using SipContext, AuthenticationContext, TemplateContext, or WebContext.
Signaling Engine MSRP	Select an MSRP to Signaling Engine from Media Engine. msrptcp-to-msrpwss msrptcp-to-msrpws Access this parameter in Groovy as context.properties.netMSRP using SipContext, AuthenticationContext, TemplateContext, or WebContext.
File Transfer	Enter a pattern for resolving file_transfer packages by SDP. Access this parameter in Groovy as context.properties.fileTransferPattern using SipContext, AuthenticationContext, TemplateContext, or WebContext.
MSRP	Enter a pattern for resolving MSRP packages by the Session Description Protocol (SDP). MSRP signaling is carried in SIP INVITE requests. When WebRTC Session Controller receives a SIP INVITE, it determines whether the request should be processed as a call, msrp chat or msrp file transfer. To do so, it looks at these regex expressions. Access this parameter in Groovy as context.properties.msrpPattern using SipContext, AuthenticationContext, TemplateContext, or WebContext.

For information about accessing the parameters in Groovy scripts, see "Accessing Integration Parameters and Package Filters Using Groovy Scripts" in WebRTC Session Controller Extension Developer's Guide.

Global Runtime Parameters of the Signaling Engine

Table 2-2 describes the configurable signaling engine runtime parameters.

Table 2-2 Configurable Signaling Engine Runtime Parameters

Parameter	Description
Glare Handling	By default, glare handling is selected and enabled. To avoid race conditions that arise when a caller and callee send simultaneous invitations, reinvitations, or session update, select glare handling for the signaling engine.
Sip Session Default Time	Enter the default SIP session time (in seconds). The default value is 3600 seconds.
Sip Session Minimum Time	Enter the minimum SIP session time (in seconds). The default value is 90 seconds.
WebSocket Disconnect Time Limit	Enter the time interval after which the WebSocket times out (in milliseconds). The default value is 60,000 milliseconds.
WebSocket Idle Time Limit	Enter the idle time interval after which the WebSocket times out (in seconds). The default value is 30 seconds.
WebSocket Maximum Connections	Enter the maximum number of WebSocket connections allowed. The default value is -1, allowing unlimited connections.

Global Resource Limit Parameters of the Signaling Engine

Set the global resource limits for the resource parameters you include in the Signaling Engine.

First, add a resource limit entry for the signaling engine:

1. Click Edit in the upper right corner of the screen.

2. In the Resource Limits section of the Signaling Engine tab, click Create.

3. In the entry field within the Create a resource limit dialog, enter a resource name.

4. Click OK.

5. Click Save.

Then, update the resource limit entry for the signaling engine:

1. Click Edit in the upper right corner of the screen.

2. In the Resource Limits table of the Signaling Engine tab, select the row entry for the required resource name.

3. Update the row as described in Table 2-3.

   The numeric entries seen in this table represent the maximum values for each resource limit parameter. The default value is -1, indicating that the entry does not have an upper limit.

4. Click Save.

Table 2-3 Configurable Signaling Engine Resource Limit Entry Parameters

Resource Parameter	Description
Name	Enter the name of the resource limit.
Sessions	Enter the maximum number of sessions for this resource limit.
SessPerUser	Enter the maximum number of sessions per user for this resource limit.
SubSessPerSess	Enter the maximum number of sub sessions per session for this resource limit.
SubSessPerUser	Enter the maximum number of sub sessions per user for this resource limit.

To delete a resource limit entry for the signaling engine:

Note:

The default entry cannot be deleted.

1. Click Edit in the upper right corner of the screen.

2. In the Resource Limits table of the Signaling Engine tab, select the row entry for the required resource name.

3. Click Delete.

4. Click Save.

Configuring the Default Logging Level for the Signaling Engine

You can specify the default logging level for each of the following logging components of the Signalling Engine: Diameter protocol, Groovy scripts, HTTP/WebSocket, JSON, Media, Others, Security, and SIP.

Table 2-4 lists the output associated with each logging level.

Table 2-4 Logging Levels for Signaling Engine Components

Logging Level	Output
Trace	Logs fine-grained events that are useful for tracing the actions of the application.
Debug	Logs fine-grained events that would be useful for debugging the application.
Info	Logs high-level information that indicates the progress of the application.
Warn	Logs messages that describe situations that are potentially harmful.
Default	Assigns the default log level for the component that is specified in the Default log level panel. For example, you set the log level for Groovy to Default. If the default log level for Groovy is Info, the log level for Groovy is set to Info.

Signaling Engine writes the log records to the domain_home/servers/server_name/logs/wsc.log file. Here, domain_home is the name of the WebRTC Session Controller domain and server_name is the name of the service.

When you select a level heading, all the sliders move to that heading indicating that WebRTC Session Controller logs all the components at that level. To set the logging output for any individual component, move the corresponding slider to the required level. Select from one of the following levels:

To set default logging levels for each of the logging components of an engine, use the Default log level pane. The engine log settings pane allows you to set the log level for each of its logging components.

To set the logging level for an engine logging component:

1. Click Edit in the upper right corner of the screen.

2. In the enginename panel, move the slider for the logging component to one of the logging levels listed in Table 2-4.

   Repeat this step for each logging component that you wish to set.

3. Click Save.

Logging for Single Engines in a Cluster

When signaling engines are in a cluster, the administration console displays the log for each signalling engine adjacent to the Default log level pane. Figure 2-2 shows the default logging level as the selection for all the components of engine1.

In the enginename panel, move the slider for the logging component to one of the logging levels listed in Table 2-4. The Refresh button refreshes the engine status for each engine in the cluster.

Figure 2-2 Log Settings Pane

Managing Media Engine Nodes Configuration and Status

Managing Media Engine nodes consists of configuring the media nodes, blocking and unblocking WebRTC network traffic to media nodes, monitoring their availability, and ensuring that their load factor remains within accepted limits. And removing a media node after blocking all traffic to the node.

The Media Engine tab displays the Credentials section followed by Cluster Nodes. Each row in the Cluster Nodes table displays the settings of a Media Engine node currently configured in WebRTC Session Controller. The row entries for a Media Engine node display the engine access details, whether it is enabled or not, its running status, and the load factor. An upward-pointing green arrow indicates that the engine is in a running state and a downward-pointing red arrow indicates that it is not.

Configuring the Media Engine

To configure Media Engine parameters:

1. If you are not already viewing the Home tab, access the Home tab. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

2. Click Media Engine.

3. Click Edit in the upper right corner of the screen.

4. In the Credentials section of the Media Engine tab, enter the information for the account authorized to connect to the Media Engine server:

   1. In the User field, enter the user name for the account.

   2. In the Password field, enter the password for the account.

   3. Click Save.

5. In the Credentials section of the Media Engine window, manage the Media Engine by doing the following:

   1. Adding Media Engine Nodes

   2. Blocking and Unblocking Media Node Traffic

   3. Removing Media Engine Nodes

   4. Refreshing Media Node Information

6. Click Save.

Providing Credentials for the Media Server

In the Credentials section of the Media Engine window, enter the user name and password for accessing the Media Engine server. Click Save.

Adding Media Engine Nodes

To add a Media Engine node:

1. Click the Home tab.

2. Click the Media Engine tab.

3. Click Edit in the upper right corner of the screen.

4. In the Credentials section of the Media Engine tab, enter the information for the account authorized to connect to the Media Engine server:

   1. In the User field, enter the user name for the account.

   2. In the Password field, enter the password for the account.

   3. Click Save.

5. In the Cluster Nodes section, click Add.

6. In the Add a Media Engine dialog:

   1. In the Address field, enter the address of the media server node.

   2. In the Port field, enter the port number.

   3. Click OK.

      The Cluster Nodes table displays a row with the address and port you provided.

7. In that row, configure the Media Engine with the information required.

   See Table 2-5 for a description of the configurable and viewable media node properties.

8. Click Save.

Table 2-5 Media Node Properties

Property	Description
User	Enter the user name required to connect to the Media Engine server.
Password	Enter the password require to connect to the Media Engine server.
Address	Enter the IP address of the node associated with the Media Engine.
Port	Enter the port number of the node connection.
Media Node Traffic Enabled	Specify whether traffic is enabled to the node associated with the Media Engine.
Media Node Status	Specify whether a connection to the node is active.
Load Factor	The load percentage on a node controlled by the internal load balancer that attempts to distribute load evenly to available media server nodes. WebRTC Session Controller stops sending requests to media nodes with a Load Factor of 100%.

Blocking and Unblocking Media Node Traffic

To block or unblock traffic to a media node:

1. Go to the Media Engine tab.

2. Click Edit in the upper right corner of the screen.

3. In the Cluster Nodes section, select the row with the media node you wish to block or unblock traffic to.

4. Click Unblock Traffic or Block Traffic.

   The traffic to the node opens or closes accordingly. The command button you selected continues to stay selected until you change the setting.

5. Click Save.

Removing Media Engine Nodes

Block the traffic for a media node before removing the node. To remove a media node:

1. Go to the Media Engine tab.

2. Click Edit in the upper right corner of the screen.

3. In the Cluster Nodes section, select the row with the media node you wish to block or unblock traffic to.

4. Click Block Traffic.

5. Click Remove.

   The Remove Media Node window appears.

6. Click OK.

7. Click Save.

Refreshing Media Node Information

To refresh media node information:

1. Click Refresh in the Media Engine window.

For information about configuring the nodes of a Media Engine server, see "Managing Media Engine Nodes Configuration and Status".

Managing WebRTC Session Controller Notification Service

WebRTC Session Controller Notification Service implements the protocol specific to the selected cloud messaging provider, such as Google Cloud Messaging system (GCM), Apple Push Notification System (APNS). This notification service is available on all engine nodes.

You can configure multiple client applications for various client platforms on the Notification Service and activate them at the same time. If your installation supports multi-tenancy, each tenant can configure multiple applications on the various client platforms using same or different credentials on the cloud messaging provider.

Manage the notification service by defining and updating the properties of your client applications in the Notification Service tab. This tab displays a table of the client applications currently configured for the notification service.

Configuring WebRTC Session Controller Notification Service

To configure the notification service for WebRTC Session Controller:

1. If you are not already viewing the Home tab, access the Home tab. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

2. Click Notification Service.

3. Click Edit in the upper right corner of the screen.

4. In the Notification Service tab, manage the notification service by completing the following tasks.

   1. Creating Applications for the Notification Service

   2. Updating an Application in the Notification Service

   3. Removing Applications from the Notification Service

5. Click Save.

Creating Applications for the Notification Service

Manage an application that uses the Notification Service by adding your applications and entering their configuration parameters. See Table 2-6 for a description of the parameters. You should have the JSON message to enter as template entry for an application as described in About Templates for Message Notifications.

Do the following:

Add the Application to the Client Applications Table 

1. Go to the Notification Service tab.

2. Click Edit in the upper right corner of the screen.

3. In the Client Applications window, click Create.

4. In the Add an Application window:

   1. Enter an application ID and a unique name for the application. See Table 2-6 for details.

   2. Click OK.

5. To save your updates thus far, click Save.

Configure the JSON Message as a Template 

1. If you are not in the Edit mode, click Edit in the upper right corner of the screen.

2. From the list of application entries, select the row for the application.

3. In the Template field:

   1. Click the Add link.

      The Enter JSON Template window is displayed.

   2. Copy your JSON message and paste it in this window.

   3. Click OK.

4. To save your updates thus far, click Save.

Enable Traffic to Access the Application 

1. If you are not in the Edit mode, click Edit in the upper right corner of the screen.

2. From the list of application entries, select the row for the application.

3. In the Enable field for the selected application entry, select the check box, to allow traffic.

4. To save your updates thus far, click Save.

Configure the Cloud Providers 

1. If you are not in the Edit mode, click Edit in the upper right corner of the screen.

2. From the list of application entries, select the row for the application.

3. In the Cloud Providers field, click the Add link.

   A list of supported cloud providers is displayed.

4. From the list of cloud providers, select the cloud provider.

5. Click OK.

6. To save your updates thus far, click Save.

Provide the API Key for Non-iOS Applications 

1. If you are not in the Edit mode, click Edit in the upper right corner of the screen.

2. From the list of application entries, select the row for the application.

3. Place your cursor over the API Key entry field and double-click.

   The cursor is active in the field.

4. Enter the API key you obtained from the Google Developers console.

5. To save your updates thus far, click Save.

Add an SSL Certificate 

1. If you are not in the Edit mode, click Edit in the upper right corner of the screen.

2. From the list of application entries, select the row for the application.

3. In the Certificate field for the application entry, click the Add sign.

4. In the Certificate window, click Create.

5. In the Add certificate window, click Browse.

6. In the File Upload window, locate the certificate and click Open.

7. In the Certificate Name field, enter the name for the certificate.

8. In the Certificate Password field, enter the certificate password.

9. Click OK.

10. Click Save in the upper right corner of the screen.

When the application data is saved successfully, the Client Applications window becomes disabled and the Edit button is enabled.

Client Application Configuration settings

Table 2-6 describes the properties for the client applications you define in the WebRTC Session Controller console.

Table 2-6 Configuring Support for Notification Service

Property	Description
Application ID	The unique identifier for the Android or iOS application registering to receive messages. Enter the identifier in the format appropriate for the application. For example, the naming convention for an entry could be: com.android.hello for an Android application com.ios.hello for an iOS application
Name	Name of the application. Enter a unique name.
Template	JSON message to be used as a template. The WebRTC Session Controller server combines this message with the message payload received from the application to create the push notification. See "About Templates for Message Notifications".
Enable	The API service is disabled, by default. To enable this API, select the check box.
Cloud Providers	The cloud provider for the API service. Click the down arrow and select the required cloud provider.
API Key	The API Key you obtained from the Credentials page of the Google Developers console. Note: This entry is not required for iOS applications.
Certificate	Add an SSL certificate for Apple Push Notification Server. See "About Secure Connections". Note: This entry is optional for Android applications.

Updating an Application in the Notification Service

To update an application listed in the Notification service:

1. Go to the Notification Service tab.

2. Click Edit in the upper right corner of the screen.

3. In the Client Applications table, select the row with the application entry you wish to update.

4. Click Edit in the upper right corner of the screen.

5. Edit the contents of that row. For information about how to delete an SSL certificate, see "Deleting an SSL Certificate".

   Note:

   You cannot update the entry in the Application ID field.

6. Do one of the following:

   • To save your edits, click Save in the upper right corner of the screen.

   • To discard your edits, click Cancel in the upper right corner of the screen.

Removing Applications from the Notification Service

To remove an application from the displayed table:

1. Go to the Notification Service tab.

2. Click Edit in the upper right corner of the screen.

3. In the Client Applications table, select the row with the application entry you wish to delete.

4. Click Edit in the upper right corner of the screen.

5. Click Delete.

6. In the Delete an application window, click OK.

7. Click Save in the upper right corner of the screen.

Deleting an SSL Certificate

To delete a certificate for an application:

1. If you are not already viewing the Home tab, access the Home tab. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

2. Click Notification Service.

3. In the Client Applications table, select the row with the application entry from which to delete the SSL certificate.

4. Click Edit in the upper right corner of the screen.

5. In the Certificate field for the application entry, click the Add sign.

6. In the Certificate window, select the certificate to delete.

7. Click Delete.

8. To save your changes, click Save.

Configuring Messaging Packages

A package is a collection of all the criteria (Groovy scripts) necessary to translate the telecom messages in a session between JSON to SIP protocols. The Packages tab at the global level enables you to configure the messaging packages that WebRTC Session Controller installation supports. Figure 2-3 shows an example.

Figure 2-3 Global Configuration for Supported Messaging Packages

In this figure, the Search field contains the entry "sipRequest". The display shows the result of the filter "sipRequest". The table under Package Name lists the packages that contain this string. The Criteria table lists the criteria configured for the selected package, call. The Groovy Script section displays the content of the criteria row entry selected in the Criteria table for the selected package.

About the Global Packages Tab

The Packages Tab at the global level is made up of three panes:

• Packages

  The Packages pane in the Packages tab displays three icons and a table below them. The table displays the names of the default packages that are currently in the database and created by the current user account. The three icons are used to create, delete, and clone a package.

  The packages that you create at this level display as selections when you create an application profile (accessed through the Application Profiles tab).

• Criteria

  The Criteria pane displays the possible message criteria defined for the selected package.

  Each signaling engine criterion forms a single Groovy script that performs the translation and processing tasks for a single type of JSON or SIP message. Create separate criteria for all possible JSON or SIP message that your signaling engine implementation processes. In synchronous request/response communication, create a separate criteria for each request and response message.

  Criteria are applied to messages based on this information included in each criteria. Table 2-7 describes the properties for the request and response messages you define in the WebRTC Session Controller administration console.

• Groovy Script

  When you select a row in the Criteria table, WebRTC Session Controller displays the Groovy version of this message criteria. Depending on your browser allowance, the Groovy Script pane displays to the right of or below the Criteria table.

  To validate the displayed Groovy script, undo, or redo your last action, use the Validate, Undo, Redo command buttons respectively. To maximize or minimize the viewing of this pane, use the Maximize or Minimize command buttons.

Creating Packages

When you create a new package WebRTC Session Controller just creates a shell that you fill with criteria. This procedure assumes that you have already created the criteria required.

To create a package:

1. If you are at the Packages tab of the WebRTC Session Controller administration console:

   1. Access the administration console configuration tabs. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

   2. Click the Packages tab.

2. In the Packages pane of the Packages tab, click the Add icon.

3. Click Edit in the upper right corner of the screen.

4. In the Create a package dialog box:

   1. Enter a name for the new package.

      Package names must be unique in the list. A package name must begin with an alphabet (a - z) or a number (0 - 9).

   2. Click OK.

   Your new package now appears in the package table which is arranged alphabetically.

5. To make your changes take effect, click Save.

You are now ready to configure and manage the package.

Managing Package Criteria

To manage the package criteria for an existing package:

1. Go to the Packages tab.

2. From the list of packages under Package Name, select the package.

3. Click Edit in the upper right corner of the screen.

4. In the Packages tab, manage the package by doing the following:

   1. Configuring Package Criteria.

   2. Updating Package Criteria.

   3. Deleting a Criteria.

5. Click Save.

Configuring Package Criteria

To create a signaling engine criteria for a selected package:

1. Click Edit in the upper right corner of the screen.

2. Click Create Criteria.

   A row appears at the top of the criteria table. A Groovy script pane appears next to or below the criteria table, depending on the browser size.

3. Provide the values for the Direction, Verb, Type, and Network fields for this criteria. See Table 2-7 for a description of the fields.

4. In the Groovy Script window, enter a Groovy script as appropriate for this criteria.

   The Groovy script defines all actions for this criteria. See "About the Groovy Scripts" in WebRTC Session Controller Extension Developer's Guide.

5. To ensure that your Groovy script meets the signaling engine validation requirements, click Validate. Fix all errors.

   See "About the WebRTC Session Controller Console Validation Tests" for a list of the validation tests and error messages.

6. To save your new criteria, click Save. For details, see "About the Groovy Scripts" in WebRTC Session Controller Extension Developer's Guide.

Table 2-7 Configuring Support for Notification Service

Property	Description
Direction	This entry indicates the message origin. Select from one of the following: FROM_APP for messages that originate from a WebRTC-enabled browser. FROM_NET for messages originating from your IMS core (SIP server or proxy). SYSTEM for messages that originated in a WebRTC Session Controller server
Verb	A verb matching the type of JSON or SIP request or response. For example, an UPDATE verb matches SIP UPDATE requests and response messages, and a complete verb matches a JSON complete request or response message. Enter the verb that identifies the message action verb (SIP method or JSON action) that the criteria matches. For example, REGISTER, PUT, GET, ACK, BYE, CANCEL, INVITE, complete, shutdown,
Type	The type of message; can be one of: request response message error acknowledgment
Network	Identifies the application that the message is being used for.

Updating Package Criteria

To update the contents of a package criteria:

1. Go to the Packages tab in the administration console.

2. From the list of packages under Package Name, select the package.

3. Click Edit in the upper right corner of the screen.

4. From the Criteria table, select the row entry for the criteria.

5. Do one or both of the following, as required:

   • Update the Direction, Verb, Type, and Network fields for this criteria. See Table 2-7 for a description of the fields.

   • Update the Groovy Script.

6. To verify the signaling engine validation requirements, click Validate. Fix all errors.

7. To save the updated criteria, click Save.

Deleting a Criteria

To delete a package criteria:

1. Go to the Packages tab in the administration console.

2. From the list of packages under Package Name, select the package.

3. From the Criteria table, select the row entry for the criteria.

4. Click Edit in the upper right corner of the screen.

5. Click Delete Criteria.

6. To save your updates, click Save.

About the WebRTC Session Controller Global Script Library

The Script Library tab displays the contents of the mandatory WebRTC Session Controller functions that are required to handle message processing.

Important:

The signature of these methods must not be changed, but the implementation can be modified according to your requirements.

In the Edit mode, use the Validate, Undo, Redo command buttons to validate the displayed Groovy script, undo, or redo your last action in this pane.

Managing WebRTC Session Controller Application Profiles

An application profile that you create in WebRTC Session Controller is a collection of packages. Each package contains criteria that translate (and probably change) WebRTC application to SIP network communication for a single program.

In the WebRTC Session Controller administration console, set up the application profile by selecting the packages from the set of globally defined packages. Provide information to identify the application profile and by defining other parameters such as a security group, domains, and resource limits.

Each application profile contains its set of Groovy scripts. After you change the configuration and save the changes, the modified Groovy is saved in the configuration file. At runtime, WebRTC Session Controller generates a copy of the complete configuration containing each profile data combined with the common Groovy script (packages and script library) data.

About the Application Profiles Tab

The Application Profiles tab enables you to configure the application profiles that your WebRTC Session Controller installation supports. Figure 2-4 displays the contents of this tab.

Figure 2-4 Application Profiles Tab

When you select the Application Profiles tab, it displays two panes. To the left, a navigation pane lists the names of the currently created application profiles. To the right is a larger pane with three tabs, Profile, Packages, and Library. These tabs display the general profile information, the Groovy scripts for the packages selected for this application profile and the general script library, respectively.

Managing Application Profiles

The application profile navigation pane consists of a table of application profile names currently configured in WebRTC Session Controller. Three icons above the Name table allow you to add, delete, or clone an application.

Creating Your Application Profile

To create an application profile:

1. If you are not logged in to WebRTC Session Controller, access the administration console configuration tabs. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

2. Click Application Profiles.

3. Click Edit in the upper right corner of the screen.

4. In the navigation panel to the left, click the Add link.

5. In the Create an application profile dialog window, enter a name for the application profile.

   Application profile names must unique, begin with an alphabet character, and contain alphanumeric characters only (a-z, A-Z, and 0-9).

   Click OK.

6. Complete the configuration for the application profile by completing the following tasks:

   • Providing the Profile Information for the Application

   • Managing the Groovy Script for the Application Profile

7. Click Save.

Providing the Profile Information for the Application

Some fields in the Profile tab display the default values defined earlier in the Home tab. Fields marked with asterisks require a valid entry. You can modify the default values also.

Enter or update the following information associated with the selected application:

1. General runtime parameters to associate with your application profile, described in Table 2-8.

   Table 2-8 Configurable Signaling Engine Runtime Parameters

   Parameter	Description
   Security Group	A required field. Enter the name of the security group for this application. WebLogic Server contains some default security groups that you can use. For details about using security groups, see the discussion on users, groups, and security roles in Oracle Fusion Middleware Securing Resources and Policies for Oracle WebLogic Server.
   Allowed Domains	A required field containing a list of allowed domains that serve as a white list of domains the application is allowed to contact. Enter all domains to allow cross-origin resources sharing (CORS) with this application. Enter the names of the allowed domains. For a tenant of a SaaS application, a specific web domain name. To support cross domain access, configure the domain name in the tenant profile. WebRTC Session Controller would apply this setting on a per tenant profile basis.
   Resource Limits	Select the resource limits that allow you to protect system performance by limiting the impact on Signaling Engine. These resource limits can also serve as application white- and black-lists for individual applications. To view the configured parameters for each resource limit, select the Signaling Engine tab under the Home tab.
   Description	Enter a short description of the application profile.
   Packages	The messaging packages this application supports. See "Managing Packages in Your Application Profile".
   Request URI	Enter the URI endpoint that you want WebRTC applications to use to access WebRTC Session Controller. This entry is the value configured for the Guest URl Match Pattern field located on the Provider Specific tab for the associated authentication provider in WebLogic Server Administration Console.
   Active	The application setting. Active, by default. To deactivate the application, clear the check box.
   Debug	To run the application in a debug mode, select this check box.

   
   

2. System properties to associate with your application profile, described in Table 2-9.

   Note:

   The values you assign to a system property on the Application Profile tab overrides the value assigned to that property on the Home tab.

   Table 2-9 Configurable Signaling Engine System Properties

   Parameter	Description
   Proxy Registrar URI	The default SIP proxy server/Registrar URI. The value you enter in this field becomes the default for any new application you create. Access this parameter in Groovy as context.properties.proxyRegistrar using SipContext, AuthenticationContext, TemplateContext, or WebContext.
   Dynamic Media Anchoring Type	Select a media anchoring option supported by WebRTC Session Controller. The possible selections are: Disabled The application cannot connect to the Media Engine. web-to-web-anchor-conditional web to web conditional anchoring is used in a session when WebRTC-enabled browsers are allowed to communicate directly. If for some reason the browsers cannot communicate directly, they can communicate through WebRTC Session Controller. web-to-web-anchored web to web forced anchoring is used in a session when all media flows through Media Engine. The supported Media Engine session type, is assigned to the Groovy constant ME_CONFIG_NAME_DMA, in the Groovy library
   File Transfer Filter	Pattern for resolving file_transfer packages by SDP. Access this parameter in Groovy as context.properties.fileTransferPattern using SipContext, AuthenticationContext, TemplateContext, or WebContext.
   Net MSRP	A required field. The WebLogic Server contains some default security groups that you can use. For details about using security groups, see the discussion on users, groups, and security roles in Oracle Fusion Middleware Securing Resources and Policies for Oracle WebLogic Server.
   Web MSRP	A required field. A list of allowed domains that serve as a white list of domains the application is allowed to contact.
   MSRP	Select the pattern for resolving MSRP packages by the Session Description Protocol (SDP). MSRP signaling is carried in SIP INVITE requests. When WebRTC Session Controller receives a SIP INVITE, it determines whether the request should be processed as a call, msrp chat or msrp file transfer. To do so, it looks at these regex expressions. Access this parameter in Groovy as context.properties.msrpPattern using SipContext, AuthenticationContext, TemplateContext, or WebContext.

   
   

3. Click Save.

Managing Packages in Your Application Profile

To map messaging packages to your application profile:

Mapping Packages 

1. If you are not in the Profile tab under for the application entry:

   1. Access the administration console configuration tabs. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

   2. Click Application Profiles.

   3. Select the application name.

2. Click Edit in the upper right corner of the screen.

3. For the Packages field, click the Add sign next to the field.

   The Package mapping dialog displays the names of the available packages.

4. In the Package mapping dialog, do the following for each package your application is to support:

   1. To include a package, select the check box next to its name.

   2. If using an alias, then, in the Alias column, enter an alias.

      For example, an alias entry myFam for a call package call displays as call:myFam.

      Note:

      The alias name can be mapped to a different package without a need for any change to the internal code of the client. For example:

      You have a client names Aimee.com that uses the call package named call. You create a special package for Aimee.com, named as callAmee. In this step, you use this alias entry to create a map between call and callAmee.

      In the run environment, for all the call packages of Aimee.com, the signaling engine will use the package callAmee.

   3. Click OK.

5. Click Save.

Removing a Package from the Mapped List 

1. Go to the Profile tab for the application entry,

2. Click Edit in the upper right corner of the screen.

3. Click the Add sign next to the Packages field for your application profile.

   The Package mapping dialog displays the names of the available packages.

4. To delete the package, clear the check box.

5. Click OK.

6. Click Save.

Managing the Groovy Script for the Application Profile

Manage the Groovy script for the application profiles using the Package tab associated with each application profile entry.

Validating the Scripts for the Selected Packages 

1. If you are not in the Profile tab under for the application entry:

   1. Access the administration console configuration tabs. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

   2. Click Application Profiles.

   3. Select the application profile name entry.

2. Click Edit in the upper right corner of the screen.

3. Click Packages.

4. To view the scripts, click Populate.

   WebRTC Session Controller displays all the default functionality in the Groovy scripts associated with the selected packages. The selected criteria are displayed in the form of methods. You can uncomment an entry and enter the specific overriding functionality and save the changes.

   At runtime, the signaling engine calls the updates package script.

5. Update the script as appropriate.

6. Click Validate. Fix all errors using the Undo and Redo buttons in this pane.

7. Click Save.

Validating the Global Library Information for the Application Profile 

1. If you are not in the Profile tab under for the application entry:

   1. Access the administration console configuration tabs. See "Accessing the WebRTC Session Controller Console Configuration Tabs".

   2. Click Application Profiles.

   3. Select the application profile name entry.

2. Click Edit in the upper right corner of the screen.

3. Click Library.

4. To view the global scripts, click Populate.

   The Library tab displays the default functionality of the WebRTC Session Controller library. These library methods are required to handle message processing for the packages associated with this application profile. They are displayed as commented methods. You can uncomment an entry and enter the specific overriding functionality and save the changes.

   At runtime, the signaling engine calls the updates package script.

5. Update the script as appropriate.

6. Click Validate. Fix all errors using the Undo and Redo buttons in this pane.

7. Click Save.

Exporting and Importing a Configuration

You can export your current configuration settings to a file or import a set of configuration settings from a file to which a configuration instance was previously saved.

To export a configuration:

1. Click Edit in the upper right corner of the screen.

2. Click Export.

   The configuration is exported to the wsc-config.xml file in your system directory for downloads.

To import a saved configuration:

1. Click Edit in the upper right corner of the screen.

2. Click Import.

3. In the Import dialog, choose the XML file that contains the configuration that you wish to import.

4. Click OK.

Debugging Groovy Script Run Time Errors

You can diagnose Groovy script problems using the stack trace in the domain_home/wsc.log file, which contains Signaling Engine stack trace messages. You identify the individual Groovy script by searching for the individual criteria method name that contains the criteria information. See "About the Groovy Scripts" for details about the signature that each script uses, and the method it calls.

Figure 2-5 shows an illustration of a formatting problem in the register package, in the FROM_APP/connect/request/default criteria shown highlighted. The red arrows show the problem, the sipReq variable is used before it is declared.

Figure 2-5 Groovy Script With a Syntax Error

This is a violation of Java syntax, and as you would expect, the operation failed and these debugging messages were written to the wsc.log file:

Caused by: groovy.lang.MissingPropertyException: No such property: sipReq for class: Script2
     at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:50)
     at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49)
     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:231)
     at Script2.pkg_register_dir_FROM_APP_typ_request_verb_connect_netsvc_default(Script2.groovy:705)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at java.lang.reflect.Method.invoke(Method.java:606)
     at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
     at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
     at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1085)
     at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:952)
     at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
     at groovy.lang.Closure.call(Closure.java:411)
     at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.callGlobal(GroovyScriptEngineImpl.java:411)
     at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.callGlobal(GroovyScriptEngineImpl.java:405)
     at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.invokeImpl(GroovyScriptEngineImpl.java:394)
     ...

The package and criteria values of the offending Groovy script are identified in this line from wsc.log:

Script2.pkg_register_dir_FROM_APP_typ_request_verb_connect_netsvc_default(Script2.groovy:705)

This message shows the method name that Signaling Engine creates from each criteria's package name and criteria values (highlighted).

In this example, the criteria with the syntax error is in the register package. Within that package the criteria with the problem has a FROM_APP direction; a request type; a connect verb; and a default network service. This matches the syntax error of the FROM_APP/connect/request/default criteria shown in Figure 2-2.

In addition, as you are developing your Groovy scripts, you can validate the scripts by clicking the Validate button in the Groovy Script editor pane. Syntax errors and other issues are reported in the console. Figure 2-2 shows the validation error message.

About the WebRTC Session Controller Console Validation Tests

The WebRTC Session Controller console runs validation tests to confirm that your Groovy scripts, Groovy library, packages, and applications are all valid. It runs the validation tests each time you commit changes to an application, package, or criteria, or click the Validate button.

Table 2-10 lists the validation error types and their error messages.

Table 2-10 WebRTC Session Controller Groovy Script Validity Tests

Error Type	Error Message
APPLICATION_NAME_NOT_UNIQUE	Application name application_name is not unique.
DUPLICATE_CRITERIA	Duplicate criteria found for criteria direction, verb, type, network_service in package package_name.
DUPLICATE_LWNG_APPLICATION_ID	Notification Service Application Id app_id is not unique.
DUPLICATE_LWNG_APPLICATION_NAME	Notification Service Application name app_name is not unique.
DUPLICATE_LWNG_CERTIFICATE_NAME	Certificate name cert_name is not unique.
DUPLICATE_PACKAGE_NAME_IN_APP	Package name package_name is not unique in application profile application_name.
DUPLICATE_TENANT_NAME_IN_APP	Tenant name tenant_name is not unique in application profile app_name.
EMPTY_LWNG_API_KEY	API KEY should be defined for Notification Service Application with id app_id.
EMPTY_LWNG_APPLICATION_ID	Notification Service Application Id should be defined for Notification Service Application with name app_name.
EMPTY_LWNG_APPLICATION_NAME	Notification Service Application name should be defined for Notification Service Application with Id app_id.
EMPTY_LWNG_CERTIFICATE	Name should be defined for Notification Service Certificate.
EMPTY_LWNG_CERTIFICATE_CONTENT	Certificate Content should be defined for Notification Service certificate with name certificate_name.
EMPTY_LWNG_CERTIFICATE_NAME	Certificate name should be defined for Notification Service Application with Id app_id.
EMPTY_LWNG_CERTIFICATE_PASSPHRASE	Passphrase should be defined for Notification Service certificate with name certificate_name.
EMPTY_LWNG_PROVIDER	Provider name should be defined for Notification Service Application with Id app_id.
EMPTY_LWNG_TEMPLATE	Template should be defined for Notification Service Application with is app_id.
GROOVY_APPLICATION_LIBRARY_COMPILATION_ERRORS	Application Library validation error, reason for the application profile application_name at line line_number.
GROOVY_APPLICATION_PROFILE_PKG_COMPILATION_ERRORS	Application profile validation error, reason for the application profile application_name, method method_name, error reason at line line_number.
GROOVY_APPLICATION_PROFILE_RESTRICTIONS	Error occurred in application profile application_name.
GROOVY_COMPILATION_ERRORS	Error is reason, at line number line_number.
GROOVY_SCRIPT_LIBRARY_COMPILATION_ERRORS	Script Library validation error, reason at line line_number.
GROOVY_SCRIPT_LIBRARY_RESTRICTIONS	Error occurred in script library scriptlibrary_name.
GROOVY_SCRIPT_RESTRICTIONS	Error message is reason.
GROOVYALL_COMPILATION_ERRORS	Error occurred for the criteria direction, verb, type, network_service in the packagepackage_name and the error message is reason at line line_number.
GROOVYALL_SCRIPT_RESTRICTIONS	Error occurred for the criteria direction, verb, type, network_service in the packagepackage_name and the error message is reason.
INVALID_ALLOWED_DOMAINS_EXPRESSION	Allowed domain contains invalid characters domains_expression.
INVALID_APP_NAME	Application profile name contains invalid characters, application_profile_name.
INVALID_CRITERIA_NETWORK	The package package_name network contains invalid characters.
INVALID_CRITERIA_TYPE	The package package_name type contains invalid characters.
INVALID_CRITERIA_VERB	The package package_name verb contains invalid characters.
INVALID_LWNG_APPLICATION_ID	Notification Service Application Id should be in a valid Android Package or Apple Bundle format for Notification Service Application with Id app_id.
INVALID_LWNG_CERTIFICATE_CONTENT	Notification Service Certificate content is not a valid p12 file or the password is incorrect for certificate with name cert_name.
INVALID_LWNG_CERTIFICATE_NAME	Certificate name certificate_name is referenced from application with Id app_id, but it does not exist.
INVALID_LWNG_DELETE_CERT_CMD	Notification Service Certificate cert_name is being used by app_name. Please update these apps before deleting the Certificate.
INVALID_LWNG_PROXY_IP	Notification Service Proxy IP proxy_ip_address should be in the format 001.001.001.
INVALID_LWNG_PROXY_PORT	Notification Service Proxy Port port_number should be in the range of 1 to 65535.
INVALID_LWNG_TEMPLATE	Template template_name is not a valid JSON formatted string for application with Id app_id.
INVALID_MODULE_NAME	The module_name module contains invalid characters.
INVALID_MODULE_REFERENCE	Nonexistent module module_name is referenced from application profile application_name.
INVALID_NETWORK	The network_name network contains invalid characters.
INVALID_PACKAGE_REFERENCE	Package name package_name is referenced from application profile application_name but it does not exist.
INVALID_PKG_NAME	The package_name package contains invalid characters.
INVALID_PROXY_URI_PATTERN	Invalid proxy registrar URI uri.
INVALID_REQUEST_URI	The request URI contains invalid characters request_uri for the application profile, application_name.
INVALID_RESOURCE_LIMITS_NAME	Invalid resource name resource_name in application_name application application profile.
INVALID_RESOURCE_NAME	Resource contains invalid characters, resource_name.
INVALID_SCRIPT_TYPE	The script script_name contains an error of type error_type.
INVALID_SECURITY_EXPRESSION	Security group contains invalid characters security_expression.
INVALID_TENANT_PROFILE_NAME	Tenant profile name contains invalid characters tenant_name.
INVALID_TENANT_PROFILE_REFERENCE	Tenant name tenant_name is referenced from application profile app_name but it does not exist.
INVALID_TYPE	The package package_name type contains invalid characters type.
INVALID_VERB	The package package_name verb contains invalid characters verb.
ME_ADDRESS_IS_NOT_UNIQUE	Media Engine address address is not unique.
ME_INVALID_LOGIN	Invalid credentials found, for the Media Engine.
ME_LIFE_CYCLE_ERROR	Media Engine life cycle is not initiated for the server server_name and port port_number.
ME_NODE_NOT_REACHABLE	Server not reachable with address address and port port_number.
ME_PORT_IS_INVALID	Invalid media engine port port_number.
MODULE_NAME_NOT_UNIQUE	Module name module_name is not unique.
PACKAGE_NAME_NOT_UNIQUE	Package name package_name is not unique.
PKG_REQUIRED	At least one package is required for the application profile application_name.
REQUEST_URI_UNIQUE	Request URI request_uri is not unique in application profile application_profile_name.
RESOURCE_LIMITS_PROFILE_NAME_IS_CANNOT_DELETE	Cannot delete resource limits resource_limit_profile_name, as it is used by application profile(s) application_name.
RESOURCE_LIMITS_PROFILE_NAME_IS_NOT_UNIQUE	Resource limits profile name resource_limit_profile_name is not unique.
RESTRICTED_GROOVY	Error occurred in restricted groovy script at line line_number.
SCRIPT_NAME_NOT_UNIQUE	Script name script_name is not unique for the package_name package.
TENANT_PROFILE_NAME_NOT_UNIQUE	Tenant profile name tenant_name is not unique.