| Oracle® Communications Service Broker SIP Developer's Guide for GSM Release 6.0 Part Number E23533-01 |
|
|
View PDF |
| 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 multi-leg call control application.
Multi-leg call control is the method of having an application controlling a call that involves two or more call parties. This method is used by enhanced applications to provide services, such as personalized ring-back tone and call transfer.
The multi-leg call control functionality enables an application to control individual parties in a call by performing the following actions:
Creating a new leg, when the application creates a new leg in a new call or creates an additional leg in an existing call
Disconnecting leg, when the application disconnects a specific leg
Removing a leg from a call, when the application removes a leg from a call and placing that leg on hold
Connecting call legs, when the application connects two or more call legs.
Service Broker enables the application to control a multi-leg call in accordance with SIP third part call control conventions. These conventions relay on SDP negotiation across call legs as described in the following sections.
Service Broker uses the SDP carried by SIP messages to represent CAP call leg information. Specifically, the “i” attribute of SDP is used for this purpose as shown in the following examples:
Figure 5-1 shows an example in which Service Broker sets a SIP INVITE sent to application with SDP of i=l1. l1 represents leg number 1, that is the call initiating leg.
Figure 5-2 shows an example in which Service Broker sets a SIP 200 OK which acknowledges INVITE with SDP of i=l2. l2 represents leg number 2, that is the call destination leg.
As shown on Figure 5-1 and Figure 5-2, each leg created Service Broker on the CAP interface is represented by Service Broker using the “i” attribute of the SDP. Service Broker sets the “i” attribute to the number assigned by Service Broker to that leg.
An application can create a new call leg in one of the following forms:
Creating a new leg in a new call
Creating a new leg in an existing call
To create a new leg in a new call, the application sends a SIP INVITE message to Service Broker. The application sets the INVITE with an empty SDP, that is the INVITE message does not include SDP.
When the SIP INVITE message is received, Service Broker sends a CAP InitiateCallAttempt (ICA) operation towards the MSC. The InitiateCallAttempt is accompanied by a CAP RequestReportBCSM and ContinueWithArgument operations.
Figure 5-3 shows the high level architecture for an application creating a new call leg.
When the CAP InitiateCallAttempt is sent, Service Broker sends a SIP 183 SESSION PROGRESS message to the application. Service Broker sets the 183 SESSION PROGRESS with SDP of i=l(x) where x is the number assigned by Service Broker to the newly created leg.
Figure 5-4 shows the high level architecture for an application that receives the call leg assigned by Service Broker to a new leg.
To create a new leg in an existing call, the application follows the procedure described in "Creating a New Leg in a New Call".
To enable Service Broker to associate the new leg with an existing call, the application sets the SIP INVITE message which is used to create the new leg, with a Route header (one or more) and includes the same content as in the header of the SIP INVITE used to create previous legs in that call.
You restrict the calling line identification by setting the Presentation indicator to "presentation restricted". You can restrict the calling line identification in one of the following ways:
On a permanent basis by setting the Presentation indicator to "presentation restricted" for all ICA messages that Service Broker generates.
On a per-message basis by setting the Presentation indicator to "presentation restricted" for specific ICA messages.
If you want to set the Presentation indicator to "presentation restricted" in all ICA messages that Service Broker generates, in the sip.xml file of the relevant IM-SCF module, set the string_address-presentation-restriction-indicator-of-calling-party-number-of-ICA parameter to restricted.
If you want to set the Presentation indicator to "presentation restricted" for specific ICA messages only, add the following XER to the ICA that Service Broker generates:
<?xml version="1.0" encoding="UTF-8"?>
<Cap4>
<initiateCallAttempt>
<destinationRoutingAddress>
<OCTET_STRING>8490630975071008</OCTET_STRING>
</destinationRoutingAddress>
<callingPartyNumber>8213 0A00 000000</callingPartyNumber>
</initiateCallAttempt>
</Cap4>
The first 4 digits of the callingPartyNumber are setting the numbering format, including the presentation and are specified in ITU-T Q763 section 3-10
To disconnect a leg, the application sends a SIP BYE or a SIP CANCEL request. The SIP BYE or SIP CANCEL request is sent through the SIP dialog that represents the leg that the application wants to disconnect.
When Service Broker receives a SIP BYE or a SIP CANCEL, Service Broker waits for a predefined configurable period of time. If during this period, all call legs are terminated by the application (that is, the application sends a SIP BYE and or SIP Cancel for all call legs), Service Broker terminates the call by sending a CAP ReleaseCall. Otherwise, (that is the application does not terminate all call legs), Service Broker sends a CAP DisconnectLeg accompanied by a CAP ContinueWithArgument towards the MSC for each leg terminated by the application.
Figure 5-5 shows the high level architecture for an application that disconnects the leg. Figure 5-5 assumes that two call legs (1 and 2) exist, and the call is active.
To remove a leg from a call, the application sends a SIP reINVITE, or a SIP 183 SESSION PROGRESS message depending on the actual call state.
When the SIP reINVITE or SIP 183 SESSION PROGRESS message is received, Service Broker sends a CAP SplitLeg operation towards the MSC followed by CAP ContinueWithArgument.
To connect a leg to another existing leg, the application sends a SIP reINVITE, SIP 183 SESSION PROGRESS or SIP 200 OK message depending on the actual call state.
When the SIP reINVITE, SIP 183 SESSION PROGRESS message or SIP 200 OK, is received, Service Broker sends a CAP MoveLeg operation towards the MSC followed by CAP ContinueWithArgument.
This section provides an example of a multi-leg call control application.
Figure 5-6, Figure 5-7, and Figure 5-8 show the detailed sequence diagram for an application that controls a multi-leg call. The call is established as an ordinary 2 legs call. When the call is active, the application creates a new call leg (leg 3).
Note:
To create a new call leg, the application sends a SIP INVITE (no SDP) message and keeps the Route header with the same content as the Route header of the SIP INVITE sent by the application during the call establishment phase (message 3 in the sequence diagram).While leg 3 is being alerted, Service Broker sends a SIP 180 Ringing to the application. At this point, the application removes leg 2 from the call and puts it on hold. This is done by sending a SIP reINVITE message on the dialog created by Service Broker. The application sets the SDP of the reINVITE to leg 3. Latter on, when leg 1 and leg 3 are in an active call, the application disconnects leg 3 by sending a SIP BYE request on the corresponding SIP dialog and than reconnects leg 1 and leg 2.
Figure 5-9, Figure 5-10, and Figure 5-11 show a parallel ringing application. This application routes the call to two destinations simultaneously (leg3 and leg 4) by sending two SIP INVITE messages (no SDP). When one of the legs answers the call, the application connects that leg to leg 1 by sending the SDP of the answering leg towards leg 1 using SIP 200 OK message (message 21 in the sequence diagram). Next, the application terminates the other leg (leg 4) by sending SIP CANCEL.
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
