| Oracle® Communications WebRTC Session Controller Extension Developer's Guide Release 7.0 E40977-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications WebRTC Session Controller Extension Developer's Guide Release 7.0 E40977-01 |
|
|
PDF · Mobi · ePub |
This chapter introduces the Oracle Communications WebRTC Session Controller Signaling Engine (Signaling Engine) and WebRTC Session Controller Media Engine (Media Engine) features that you use to establish communication between WebRTC-enabled browsers and SIP-based network services.
In order to use WebRTC Session Controller functionality, you must be familiar with
The SIP transport protocol, and how it builds up and tears down calls.
The JSON data format.
JavaScript, and how it communicates with web servers.
The Java and Groovy Programming Languages that you use to create scripts that perform JSON to SIP and SIP to JSON translations within Signaling Engine.
WebRTC Session Controller builds up and tears down real-time multimedia calls between client applications on WebRTC-enabled web browsers, and your SIP multimedia services. WebRTC Session Controller does this by translating telecom messages between the JSON data structure used by the client applications and the SIP protocol used by your IMS core.
See "WebRTC Session Controller Software and Protocol Conformance" for details on the protocol levels this release uses.
Figure 1-1 illustrates the WebRTC Session Controller architecture, lists the developer extension points you use to customize the JSON to SIP communication, and shows how JSON messages are translated to SIP and SIP messages to JSON.
Client applications send JSON messages to Signaling Engine, which uses Groovy scripts to process them and translate them to SIP messages and send them on to your SIP servers and IMS core. During Groovy processing you can use interact with a Policy Control and Rules Function (PCRF) to include policy (QoS) information, and Media Engine to manage the call's media session.
Figure 1-1 WebRTC Session Controller Components and Developer Extension Points
This guide explains how to customize Signaling Engine Groovy scripts to:
Change the JSON data used in messages. For example, to modify your JSON data if the JSON specifications change.
Change the SIP data used in messages. You can then add any additional SIP header data that your SIP implementation requires.
Use Media Engine to affect the media parameters (SDP data) of media sessions. For example, you can use Media Engine to negotiate a codec supported by both call parties.
Send and receive policy information from your PCRF. You can exchange information with a PCRF and affect the call (or the subscriber's account) either before or after the call's media session.
Streamline communication between client applications and WebRTC Session Controller to provide a more lightweight and efficient protocol. You can tune the network traffic by filtering or aggregating messages to limit the call flow. For example, you could remove some or all of the SIP 1xx informational messages from the call flow as they arrive at WebRTC Session Controller. Or you could aggregate related SIP messages and forward them to the client application as a single combined message once WebRTC Session Controller has received them all. This reduces the amount of traffic that the client application must process, enabling you to simplify the client applications logic.
The WebRTC Session Controller Web Application Developer's Guide explains the extension points not covered in this document, including:
How to extend the default WebRTC Session Controller JavaScript API package
How to create a WebRTC Session Controller JavaScript API package
During the JSON to SIP translation you have a lot of flexibility in what you can do with individual messages. You can manipulate messages:
At the field level, by adding new fields, creating a new field layout, adding optional data, and creating a new data representation.
At the header level, by separating a SIP message header from the message content, and pass on one or the other in a new message (for a different service). You can then pass one or both to a new service.
As shown in Figure 1-1, calls can originate either from a WebRTC-enabled web browser (client application), or from the SIP IMS core itself. Browser-originating messages are first translated from JSON to a normalized format by Signaling Engine. Then the normalized message is translated to the SIP protocol by Signaling Engine Groovy scripts calling methods from the WebRTC Session Controller API.
Signaling Engine processes SIP server-originated messages in the opposite direction. They are first translated from SIP to a normalized format using your Groovy scripts. Then Signaling Engine translates them again from the normalized format to the JSON format that your web browser can parse.
Figure 1-2 shows the WebRTC Session Controller console graphical interface that you use to create, select, and modify the Groovy scripts that translate and customize messages. In Figure 1-2 the Packages tab is selected, showing one of the default Groovy scripts provided with this release.
Figure 1-2 The WebRTC Session Controller Console Window
See "Customizing Messages for New SIP or JSON Data" for details on how to use the WebRTC Session Controller console.
WebRTC Session Controller uses these concepts and components:
WebRTC Session Controller applications - Each application represents a single WebRTC-enabled client application and all of its capabilities. For example, an application could be a website that offers a video and audio chat capabilities. Each application uses a set of WebRTC Session Controller packages.
See "About Applications" for more details and "Creating Applications" for instructions on how to create them.
WebRTC Session Controller packages - Each WebRTC Session Controller package is a unit of real time communication capability that WebRTC Session Controller supports. Each package is a collection of the individual Groovy scripts (criteria) that actually do the message processing and translation from SIP to JSON and back. Each JavaScript client application must reference the packages that it is allowed to use.
Each package typically includes the logical set of message processing behaviors for an application. For example you might put all message translation scripts for video chat calls between a web browser and a SIP phone in one package. You would probably define a separate package for audio chat calls, and another for a sending SMSs, and another for file transfers.
See "About Packages" for more details and "Creating Packages" for details on how to create one.
WebRTC Session Controller criteria - Each criteria includes information to identify a SIP or JSON message to translate, and a Groovy script to do the translation. The translation can be from SIP to JSON or JSON to SIP. For example one criteria accepts the BYE message from a SIP phone to stop a media stream, and translates it to a JSON shutdown message.
You use one criteria for each type of message that you expect to receive during the process of setting up or tearing down the WebRTC multimedia calls that WebRTC Session Controller processes. The Groovy scripts that you create and use are where you add code to process any new or custom SIP or JSON data that your implementation requires.
See "About Criteria" for more details on WebRTC Session Controller criteria, and "Creating Criteria" for details on creating criteria.
Script Library - The script library is a collection of useful groovy code and examples that you can use or reuse in any of the criteria Groovy scripts that you create.
See "About the Groovy Scripts" for details on using the script library.
WebRTC Session Controller console - A Graphical User Interface (GUI) that you use to create WebRTC Session Controller applications, packages, and criteria. This GUI also contains the Script Library, and a Configuration tab that use to configure Signaling Engine and Media Engine.
See "About the WebRTC Session Controller Console" for information about this GUI. See the WebRTC Session Controller System Administrator's Guide for information on the configuration settings.
Web RTC Session Controller console configuration settings - Used to set performance limits for each Signaling Controller implementation. You use these settings to balance WebRTC Session Controller capabilities with your network load and hardware capabilities. For example you use this tab to enable/disable glare handling (avoiding race conditions caused by concurrent requests), and set a maximum number of WebSocket connections.
The WebRTC Signaling Controller Groovy scripts translate WebRTC messages between JSON messages to SIP, and also serve as extension points that you use to customize behavior during the translation. During the translation process you can:
Make your WebRTC-based client web applications communicate with your SIP servers and IMS core.
Make the client-to-SIP communication more efficient by removing unimportant messages. For example, your IMS core probably includes media servers, which send status messages that may by unimportant to a client application. You can add instructions to the Groovy scripts to remove any unnecessary messages from traffic, to save bandwidth.
Redirect the messages to different SIP services. For example, during a shopping session, offer a video chat with a customer representative. As the chat session is being set up, you can automatically provision the chat session with subscriber information.
Intercept, modify, or replace individual messages as they are being processed, within the same session. For example, you could modify or replace functionality based on the values included in the message parameters. If your message includes subscriber information, you could apply a special deal to all residents of a specific city; or shut off service to all residents of a city; or redirect suspicious messages to a quarantine area. You can make these decisions based on any information contained in the messages from your SIP servers or client application. You are only limited by the information in your JSON and SIP messages and the capabilities of the Groovy scripting language.
Use policy control and charging rules function (PCRF) information to affect the call or the subscriber's account. You can use policy information to affect the call either before the media stream is set up or afterward.
Use Media Engine data to change the call's Session Description Protocol (SDP) parameters. for example, to negotiate a codec that two web browsers support.
Add other features or behaviors that your implementation requires.
You use the WebRTC Session Controller JavaScript API library to create multimedia applications that run on WebRTC-enabled browsers. These client applications use this API to communicate with the Signaling Engine, and Signaling Engine, in turn, translates the JSON data format to one the SIP nodes can use.
See WebRTC Session Controller Web Application Developer's Guide for details on how to use this API to create client applications.
You use the WebRTC Session Controller Configuration API, documented in the WebRTC Session Controller Configuration API Reference and WebRTC Session Controller JavaScript API Reference documents to translate call messages between the JSON data format that the client application uses, and the SIP language that your IMS core understands. It contains separate packages for:
Creating, sending, and receiving SIP messages
Creating, sending, and receiving JSON messages
Sending and receiving policy (Diameter Rx) messages
Creating and using Java Future interface objects to delay processing until computations by Media Engine or a PCRF are complete. For example you can delay establishing a media session until your PCRF confirms that the subscriber is entitled to the resources.
Using Media Engine to translate between WebRTC-enabled browsers and entities that do not support the same codecs. These entities can be SIP nodes, or web browsers that do not support the codec sent in the call request.
Administering Signaling Engine. WebRTC Session Controller API contains a configuration MBean. See WebRTC Session Controller System Administrator's Guide for details on using this MBean.
WebRTC Session Controller includes the JsonRTC WebSocket subprotocol that it uses to communicate with client applications and extend the default JavaScript capabilities. JsonRTC uses the JSON data interchange format and the MBWS subprotocol as the basis for message reliability.
If you use the WebRTC Session Controller console to create applications and packages, then you do not need to understand this protocol. However, if your implementation requires that you extend WebRTC Session Controller with new software packages, you use this protocol to do so.
You can use this protocol to change the extend the JSON and SIP data structures and add new fields and headers as necessary using the optional fields in the JsonRTC protocol. However, you must use a Groovy script to validate and use the data as necessary. WebRTC Session Controller accepts new data freely, but ignores if you do not process it in your Groovy scripts.
See "Extending WebRTC Session Controller Functionality" for guidelines for creating a custom package, and "JsonRTC Protocol Reference" for details on the WebRTC Session Controller JsonRTC Protocol.
WebRTC Session Controller uses the following revision levels of the software tools and protocols:
The JSON data format for communicating with web browsers and other HTTP nodes.
Session Description Protocol (SDP) RFC 4566 for communicating information about message media streams. The specification is available at the SDP specification website: http://tools.ietf.org/html/rfc4566
The default JDK version - 1.7.
The Groovy scripting engine version 2.1.3.
The SIP protocol RFC 3261 for building up, tearing down calls.
A Groovy scripting language. See this Groovy website for information and documentation:
Before using the instructions in this guide to configure and customize your WebRTC to SIP communication, you need to know:
How to program in the Groovy scripting language. This Groovy website can get you started: http://groovy.codehaus.org. There are also third party tutorials and books available.
Details of your WebRTC client application message requirements.
Details of your SIP message requirements.
Details of any policy information that you provide to a PCRF to affect subscriber profiles or accounts, and any policy information that you intend to use to affect calls.
Details of the security groups that your WebLogic server uses. For details on using security roles, see the discussion on users, groups, and security roles in Oracle Fusion Middleware Securing Resources and Policies for Oracle Weblogic Server.
Details on the other security considerations that your network requires. See WebRTC Session Controller Security Guide for information about setting up a secure WebRTC Session Controller implementation.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
