| Oracle® Communications Service Broker SIP Developer's Guide for GSM Release 6.1 Part Number E29447-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Service Broker SIP Developer's Guide for GSM Release 6.1 Part Number E29447-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how to develop a SIP application that receives charging requests from Oracle Communications Service Broker and sends charging responses to Service Broker.
Service Broker can request a SIP charging application to allocate a quota. The application can send a response that contains a required amount of units.
A charging solution architecture requires the following components:
SIP application
Service Broker
MSC
Figure 3-1 shows a SIP charging application that interacts with the MSC through Service Broker.
The application communicates with Service Broker using a Service Broker's SIP interface provided by an IM-ASF interworking module. An MSC uses a Service Broker's CAP interface provided by an IM-SCF CAP interworking module.
The way Service Broker communicates with the MSC depends on the method of monitoring the call. You can use one of the following methods:
Internal monitoring, which means the call is monitored by Service Broker. In this case, Service Broker counts the used quota, generates credit reservation requests, and sends them to the charging application.
External monitoring, which means the call is monitored by the MSC. To trigger the MSC to begin to monitor the call, Service Broker sends an ApplyCharging operation to the MSC. The MSC counts the used quota and sends an ApplyChargingReport operation to Service Broker. Based on the ApplyChargingReport, Service Broker generates credit reservation requests and sends them to the charging application.
The monitoring method and the way how Service Broker generates credit reservation requests (when the call is monitored by Service Broker) is determined by the configuration of the IM-SCF. For more information, see the discussion on configuring IM-SCF CAP in the Oracle Communications Service Broker Modules Configuration Guide.
A SIP application can send to, and receive charging information from, Service Broker using one of the following methods:
Charging Info body of a SIP message. See "Exchanging Charging Information Using a Charging Info Body" for more information.
XER representation of CAP operations. See "Exchanging Charging Information Using XER" for more information.
A Charging Info body carries a XER representation of request-related and response-related data within a SIP message. The contents of a Charging Info body is generated by the IM-SCF and SIP application.
The IM-SCF adds to the Charging Info body information about requested and used units. To generate a Charging Info body, the IM-SCF uses the information received from the MSC, results of the call monitoring (when the IM-SCF monitors the call), and the IM-SCF configuration settings.
The SIP application adds to the Charging Info body information about granted units.
The following SIP messages can carry a Charging Info body:
SIP INVITE
Re-INVITE
SIP INFO
SIP BYE
SIP 200 OK (on SIP INVITE or SIP Re-INVITE only)
SIP 183 Session In Progress (on SIP INVITE or SIP Re-INVITE only)
When an application communicates with an MSC, the flow works as follows:
The MSC sends to Service Broker a CAP InitialDP.
A first charging request can be also triggered by an Initial DP oTermSeized or oAnswer depending on the configuration of the IM-SCF.
After receiving a CAP InitialDP, Service Broker generates a SIP INVITE with a Charging Info body. The Charging Info body contains a request for allocating an initial quota as defined in the IM-SCF configuration. The Content-Type header of the Charging Info body is set to "application/charging-info".
The application adds a response to the received Charging Info body. The response contains information about granted units. Then the application sends the SIP message back to Service Broker.
Service Broker does one of the following:
When the call is monitored internally, Service Broker begins to monitor the call by itself.
When the call is monitored by the MSC, Service Broker sends an Apply Charging to the MSC.
Note:
Service Broker begins to monitor or sends an ApplyCharging to the MSC as defined in the configuration of the IM-SCF. Depending on how the IM-SCF is configured, the beginning of the monitoring or sending of the ApplyCharging might not occur immediately after receiving a response from the application with the granted quota.For more information on IM-SCF configuration, see the discussion on configuring IM-SCF CAP in Oracle Communications Service Broker Modules Configuration Guide.
One of the following happens during the call:
If the call is monitored internally, Service Broker sends an additional request in the Charging Body of a SIP INFO after the quota is exhausted.
If the call is monitored externally, the MSC sends an ApplyChargingReport to Service Broker. This triggers Service Broker to send to the application an additional request in the Charging Body of a SIP INFO.
Figure 3-2 show an example call flow for exchanging charging information using a Charging Info body when Service Broker monitors the call.
Figure 3-3 show an example call flow for exchanging charging information using a Charging Info body when the MSC monitors the call.
A SIP application can perform CAP charging operations by attaching a XER formatted body to a SIP message. The XER body is an XML representation of the CAP charging operation to be performed.
For example, an application may instruct Service Broker to send a CAP FurnishChargingInformation to the MSC by sending to Service Broker a SIP INFO message that includes an XML representation of CAP FurnishChargingInformation carried by the message body.
Note:
Service Broker is provided with a set of XSD files that define how you should represent CAP operations in the XER format. The XSD file for each CAP phase is stored in the directory with the corresponding name in the /protocols/inap/ directory in /samples/service_controller.samples.zip. For example, the XSD file that defines the structure of CAP phase 4 operations is stored in /protocols/inap/cap4/ directory.Depending on the phase of the CAP, the application needs to set the Content-Type header of the body that carries the CAP message to one of the following:
application/cap-phase1+xml
application/cap-phase2+xml
application/cap-phase3+xml
application/cap-phase4+xml
Note:
Some of the charging operations, such as ApplyCharging, can be used only by a full call control application, while others, such as FurnishChargingInformation, can be used by an initial call control application as well.To perform a CAP FurnishChargingInformation operation, the application sends a SIP INFO message through the SIP dialog created by Service Broker. The application attaches a XER representation of FurnishChargingInformation operation to the SIP INFO body.
Figure 3-4 shows a SIP initial call control application that performs a CAP FurnishChargingInformation operation.
Figure 3-5 and Figure 3-6 show a SIP full call control application that performs a CAP FurnishChargingInformation operation.
To perform a CAP FurnishChargingInformation operation, the application sends a SIP INFO message through the SIP dialog created by the application. The application attaches a XER representation of the FurnishChargingInformation operation to the SIP INFO body.
When performing CAP FurnishChargingInformation in an application initiated call, the application should perform the following steps:
To set a SIP INVITE sent to Service Broker (for creating a new leg) with an x-wcs-cps header that holds the value of "start".
To receive a SIP 183 SESSION PROGRESS message from Service Broker
To send a SIP INFO message (carrying the CAP FurnishChargingInformation) and set the SIP INFO with an x-wcs-cps header that holds the value of "stop"
The application uses the x-wcs-cps header (with the value of "start") to instruct Service Broker to avoid continuing call processing towards the MSC immediately after the CAP InitiateCallAttempt is sent and instead, to consider the SIP INFO sending CAP FurnishChargingInformation. The CAP ContinueWithArgument is sent by Service Broker only upon receiving an x-wcs-cps header that holds the value of "stop".
Figure 3-7 shows an application that performs a CAP FurnishChargingInformation operation in an application initiated call.
To perform a CAP SendChargingInformation operation, the application sends a SIP INFO message through the SIP dialog created by Service Broker. The application attaches a XER representation of the CAP SendChargingInformation operation to the SIP INFO body.
To perform a CAP ApplyCharging operation, the application sends a SIP INFO message through the SIP dialog created by Service Broker. The application attaches a XER representation of ApplyCharging operation to the SIP INFO body.
The following example shows a XER representation of the CAP phase 4 ApplyCharging operation.
<Cap4> <applyCharging> <aChBillingChargingCharacteristics> A004800204B0 </aChBillingChargingCharacteristics> </applyCharging> </Cap4>
A SIP application that performs an ApplyCharging operation expects to receive a report when, for example, the allocated call duration expires.
Service Broker sends the report by sending a SIP INFO message. Service Broker attaches a XER representation of an ApplyChargingReport operation to the SIP INFO message and sends this message through the dialog created by Service Broker.
The following example shows a XER representation of the CAP phase 4 ApplyChargingReport operation.
<Cap4> <applyChargingReport> A014A003 810101A1 0380012F 820100A5 05A20381 0101 </applyChargingReport> </Cap4>
The CAP phase 4 ApplyChargingReport operation includes a parameter called legActive that indicates whether or not the call is active at the time when the report is sent. If at the time when Service Broker is sending the report the call is still active, the application may allocate additional quota that allows the call to continue. In this case, several ApplyCharging and ApplyChargingReport operations are exchanged between the application and Service Broker.
Figure 3-8 and Figure 3-9 show a SIP full call control application that performs a CAP phase 4 ApplyCharging operation.
Note:
In the example shown on Figure 3-8, the application reserves quota for the call. When the first quota is exhausted, Service Broker sends a report towards the application which reserve an additional quota.To perform a CAP CallInformationRequest operation, the application sends a SIP INFO message through the SIP dialog created by Service Broker. The application attaches a XER representation of the CAP CallInformationRequest operation to the SIP INFO body.
The following example shows an XML representation of the CAP phase 4 CallInformationRequest operation.
<Cap4> <callInformationRequest> <requestedInformationTypeList> <callAttemptElapsedTime/> </requestedInformationTypeList> </callInformationRequest> </Cap4>
A SIP application that performs a CallInformationRequest operation expects to receive a report holds the charging related information. Service Broker sends a report by sending a SIP INFO message. Service Broker attaches a XER representation of the CallInformationReport operation to the SIP INFO message and sends this message through the dialog created by Service Broker.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
