1 Principles of the Oracle Communications Service Broker NG-IN Solution

This chapter describes the principles of the Oracle Communications Service Broker NG-IN solution.

Introduction

Service Broker NG-IN solution enables a SIP application to control an IN-enabled MSC or SSP in a legacy network.

With a Service Broker NG-IN solution, you can:

Deploy new SIP applications and deliver them towards a legacy network.
Migrate legacy SCP-based applications to SIP-based applications and deliver them towards a legacy network.

Figure 1-1 shows a SIP application that controls an IN-enabled MSC in a legacy network.

Figure 1-1 Architecture for Controlling a Legacy IN-Enabled MSC by a SIP Application

Controlling Legacy IN-Enabled MSC by SIP Application

Service Broker provides SIP applications with a standard SIP interface to control IN-enabled MSCs. This enables a SIP application to control an MSC in a legacy network as it controls an MGC or CSCF in a SIP or IMS network. Furthermore, from the application developer's perspective, the application's control over an MSC does not require any network-specific customization.

Service Controller enables advanced applications (for example charging applications) to control IN-specific parameters by exposing these parameters towards the application through the SIP interface.

Figure 1-2 shows a SIP application that provides call control to an MGC or CSCF in a SIP or IMS network, and to an IN-enabled MSC in a legacy network.

Figure 1-2 Architecture for controlling an MSC and MGC/CSCF by a SIP Application

Controlling MSC and MGC/CSCF by SIP Application

Solution Architecture

The Service Broker NG-IN solution is composed of the following components:

One or more SIP applications
Service Broker

In an NG-IN solution, Service Broker has two external interfaces:

Application-facing module, such as R-IM-ASF, for communication with SIP applications
Network-facing module, such as IM-SCF, for communication with MSCs

Session Control

Service Broker enables a SIP application to control an IN call through the SIP interface. An application may operate in a full call control mode or an initial call control mode acting as a SIP B2BUA or as a SIP Redirect Server accordingly.

Charging

Service Broker enables a SIP application to control an MSC for online and offline charging services. Charging operations are transferred from the application to Service Broker using SIP INFO messages. These messages carry an XML representation of the charging operation that needs to be performed.

For example, an application may send a SIP INFO message with a body that carries an XML representation of a CAP phase 4 FurnishChargingInformation operation. Upon receiving a SIP INFO, Service Broker sends a CAP FurnishCahrgingInformation towards the MSC.

User Interaction

Service Broker enables a SIP application to interact with a call party for providing service announcement to the call party with or without DTMF collection.

User interaction operations are transferred from the application to Service Broker using SIP INFO messages that carry an XML representation of the user interaction operation to be performed.

For example, an application may send a SIP INFO message with a body that carries the XML representation of CAP phase 4 PlayAnnouncement operation.

Multleg Control

Service Broker enables a SIP application to control individual parties in a call. For example, an application may create a new leg in an existing call or in a new call, connect two or more legs, split a leg out from the call, and more.

Multi-leg control is used by an application acting as a B2BUA to provide enhanced services, such as personalized ringback tone and click-to-dial.

Information Exchange through the SIP Interface

Service Broker exchanges information with the SIP application through the common SIP interface using two different mechanisms:

Using SIP headers
Using SIP message body

Information Exchange using SIP Headers

To provide the application with the call related information received through the CAP interface, Service Broker uses the headers of the messages sent to the application.

For example, when Service Broker receives an InitialDP operation through the CAP interface, Service Broker sends a SIP INVITE message to the application and sets the Request-URI to the called party address as received in the CAP InitialDP operation. In the other direction, Service Broker uses the headers of the messages received from the application to construct CAP operation and send it towards the MSC.

In addition, to exchange information with a SIP application, Service Broker uses SIP tokens. For example Service Broker uses the noa token to exchange the nature of address information of various call parties with the SIP application.

Information Exchange using SIP Body

Service Broker uses the SIP message body to exchange two types of information:

IN parameters, which are not naturally transferred using the SIP headers. For example, Service Broker may use the SIP INVITE message body to propagate the IN BearerCapability parameter towards the application.

IN parameters are exchanged using the SIP body in both directions: from Service Broker to the application and from the application to Service Broker.
SDP, which contains call leg information.

Setting the Content-Type Header for BER Tunneling

When Service Broker tunnels BER through the SIP interface, Service Broker uses the "op" token and "dir" token of the SIP Content-Type header to describe the message that the body contains. Table 1-1 describes these tokens.

Table 1-1 Content-Type Tokens

Token	Description
op	Specifies the code of the tunneled operation
dir	Specifies a direction of the tunneled operation, that is whether the operation is an invocation or result. Possible values: Invoke Result

Token

Description

Specifies the code of the tunneled operation

dir

Specifies a direction of the tunneled operation, that is whether the operation is an invocation or result.

Possible values:

Invoke
Result

For example:

Content-Type: application/cap-phase4+ber;op=123;dir=invoke
Content-Type: application/cap-phase4+ber;op=456;dir=result

Setting the Format for Specifying a Phone Number in the Header of a SIP Message

When Service Controller receives a session from a phone, Service Controller can transfer the phone number to a SIP application using one of the following formats:

SIP URI, which is set as follows: sip:phone_number; tel. For example: sip:123-4567;tel
Tel URI, which is set as follows: tel:phone_number. For example: tel:123-4567

By default, Service Controller uses the Tel URI format. However, your SIP application might expect to receive a phone number in the SIP URI format. In this case, you need to set the ocsb.backward.compatibility property of the DomainServiceMBean MBean to true.

See the discussion on configuring Service Controller using JConsole in Service Controller System Administrator's Guide.

In addition, if Service Controller receives a non-international Tel URI whose phone_context parameter is not defined, then Service Controller adds the phone_context parameter set to local.