Oracle® Communications Service Broker SIP Developer's Guide for GSM Release 6.0 Part Number E23533-01 |
|
|
View PDF |
This chapter describes how to develop a SIP application that performs CAP charging operations.
Service Broker enables a SIP application to 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 towards an MSC by sending a SIP INFO message towards Service Broker. The SIP INFO message includes an XML representation of CAP FurnishChargingInformation carried by the message body.
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-1 shows a SIP initial call control application that performs a CAP FurnishChargingInformation operation.
Figure 3-2 and Figure 3-3 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 INVITE sent to Service Broker (for creating the 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-4 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-5 and Figure 3-6 show a SIP full call control application that performs a CAP phase 4 ApplyCharging operation.
Note:
In the example shown on Figure 3-5, 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.