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

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 Broker 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

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:

• Northbound SIP interface towards SIP applications

• Southbound IN interface towards the MSC

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.

Based on application's instructions, Service Broker uses different media resources:

• MSC's internal resource

• External resource, that is gsmSRF

• MRF

When Service Broker uses internal or external resources, 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

The following sections describe these two mechanisms.

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

For example:

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