|Oracle® Communications Service Broker SIP Developer's Guide for GSM
Part Number E23533-01
This chapter describes the principles of the Oracle Communications Service Broker NG-IN solution.
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.
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.
The Service Broker NG-IN solution is composed of the following components:
One or more SIP applications
In an NG-IN solution, Service Broker has two external interfaces:
Northbound SIP interface towards SIP applications
Southbound IN interface towards the MSC
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.
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.
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
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.
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.
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.
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.
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.
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.
Specifies the code of the tunneled operation
Specifies a direction of the tunneled operation, that is whether the operation is an invocation or result.
Content-Type: application/cap-phase4+ber;op=123;dir=invoke Content-Type: application/cap-phase4+ber;op=456;dir=result