| 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 call control application.
When Oracle Communications Service Broker invokes a call control application, the application can perform one of the following actions:
Rejecting the call
Allowing the call to continue leaving the call information unmodified
Allowing the call to continue with the call information modified. The application performs this action by providing Service Broker with the call routing information. When Service Broker receives the call routing information, Service Broker propagates this information towards the MSC through the IN interface.
If the application decides to allow the call to continue, the application can do this in one of the following forms:
Routing the call while retaining call control for the entire call duration. An application that retains call control for the entire call duration is known as a full call control application.
Routing the call without retaining call control for the entire call duration. An application that routes the call to destination without retaining call control for the entire call duration is known as initial call control application.
Acting as a standard SIP entity, Service Broker invokes a SIP application by sending a SIP INVITE message. The Service Broker sets the SIP INVITE content based on the information received in the CAP InitialDP operation.
Table 2-2 describes how Service Broker constructs SIP INVITE headers based on a CAP InitialDP.
Table 2-2 Constructing a SIP INVITE Based on CAP InitialDP
| SIP INVITE Headers | Taken from... |
|---|---|
|
Request-URI :: User part (see the note for Request-URI below the table) |
InitialDP :: CalledPartyNumber, if exists InitialDP :: CalledPartyBCDNumber, if CalledPartyNumber is not included in InitialDP. |
|
Request-URI :: Domain part |
Service Broker configuration |
|
To :: User part |
InitialDP :: CalledPartyNumber, if exists InitialDP :: CalledPartyBCDNumber, if CalledPartyNumber is not included in InitialDP. |
|
To :: Domain part |
Service Broker configuration |
|
From :: User part |
|
|
From :: Domain part |
Service Broker configuration |
|
P-Asserted-Identity :: User part (see the note for P-Asserted-Identity below the table) |
InitialDP :: CallingPartyNumber, if exists if InitialDP :: CallingPartyNumber is missing or presentation is not available, Service Broker sets P-Asserted-Identity :: User part to anonymous |
|
P-Asserted-Identity :: Domain part |
Service Broker configuration |
|
Privacy |
|
|
Diversion - top most header :: name-addr |
InitialDP :: RedirectingPartyID |
|
Diversion - top most header :: Counter |
InitialDP :: RedirectionInformation :: RedirectionCounter |
|
Diversion - top most header :: Reason |
InitialDP :: RedirectionInformation :: RedirectingReason |
|
Diversion - top most header :: Domain part |
Service Broker configuration (im_scf_domain_name_address) |
|
Diversion - bottom most header :: name-addr (see the note for Diversion - bottom most header below the table) |
InitialDP :: OriginalCalledPartyID |
|
Diversion - bottom most header :: Counter |
InitialDP :: RedirectionInformation :: RedirectionCounter |
|
Diversion - bottom most header :: Reason |
InitialDP :: RedirectionInformation :: OriginalRedirectionReason |
|
Diversion - bottom most header :: Domain part |
Service Broker configuration (im_scf_domain_name_address) |
|
Route |
If InitialDP::eventTypeBCSM holds an O side DP, Service Broker adds the orig token. If InitialDP::eventTypeBCSM holds a T side DP, the token is omitted. |
|
x-wcs-session-case |
|
|
CallingPartyCategory |
InitialDP :: CallingPartysCategory If InitialDP :: CallingPartysCategory is set to one of the following, Service Broker sets CallingPartyCategory to operator:
If InitialDP :: CallingPartysCategory is set to Ordinary calling subscriber, Service Broker sets CallingPartyCategory to ordinary. If InitialDP :: CallingPartysCategory is set to Calling subscriber with priority, Service Broker ignores the header. If InitialDP :: CallingPartysCategory is set to Data call, Service Broker sets CallingPartyCategory to data. If InitialDP :: CallingPartysCategory is set to Test call, Service Broker sets CallingPartyCategory to test. If InitialDP :: CallingPartysCategory is set to Payphone, Service Broker sets CallingPartyCategory to payphone. |
|
Accept-Language |
InitialDP :: CallingPartysCategory Service Broker adds the SIP Accept-Language header only if InitialDP :: CallingPartysCategory is set to one of the following:
In this case, SIP Accept-Language is set to the language (for example, French). |
|
P-Charging vector :: icid-value |
InitialDP :: CallReferenceNumber If CallReferenceNumber is not included in the InitialDP, Service Broker does not add P-Charging-Vector. |
|
P-Charging vector :: icid-gen-addr |
Service Broker configuration for the Domain Name Address specified in the IM-SCF configuration. |
|
P-Charging vector :: Orig-ioi |
Not set |
|
P-Charging vector :: Term-ioi |
Not set |
|
Subject |
Service Broker sets Subject as follows: Subject:call control |
|
x-wcs-mobile-number |
InitialDP :: iMSI |
|
x-wcs-service-key |
InitialDP :: ServiceKey |
|
x-wcs-network-name |
Service Broker configuration The x-wcs-network-name enables Service Broker to provide the application with enhanced information about the underlying network. This information can be used by application to apply specific logic based on the network where call was initiated. |
|
x-wcs-msc-address |
InitialDP :: mscAddress |
|
x-wcs-module-name |
im-scf instance name (as set in Route header) |
|
P-Access-Network-Info |
If InitialDP :: LocationInformation :: SAI exists, Service Broker sets P-Access-Network-Info as follows:
If InitialDP :: LocationInformation :: SAI is missing, Service Broker sets P-Access-Network-Info as follows:
Regardless of the value of access-type, Service Broker sets gsm-location-number to InitialDP LocationNumber |
Notes to Table 2-2:
Request-URI
Service Broker sets the Request-URI with a noa token. For more information on the noa token, see "Exposing Nature of Address".
P-Asserted-Identity
The Service Broker sets the P-Asserted-Identity with a noa token. For more information on the noa token, see "Exposing Nature of Address".
Diversion - bottom most header
For more information, see "Exposing Diversion Information".
x-wcs headers
These are vendor specific headers used by Service Broker.
Service Broker exposes CAP nature of address information to the SIP application using a vendor specific token, named noa. The noa token carries the nature of address of various call parties as follows:
Nature of address of the called party number provided by noa token in the Request-URI header of the SIP INVITE, which is sent to the application
Nature of address of the calling party number provided by noa token in the P-Asserted-Identity header of the SIP INVITE, which is sent to the application
Table 2-4 describes how Service Broker sets the noa token for various nature of address values.
Service Broker uses the standard SIP Diversion header, as described in Steve Levy, J. R.Yang, "Diversion Indication in SIP draft-levy-sip-diversion-08", to provide CAP redirection information to a SIP application. Service Broker sets the SIP INVITE message with one or more Diversion headers depending on availability of information in the CAP InitialDP operation as follows:
CAP OriginalCalledPartyID is provided to the application using the bottom most SIP Diversion header (for more information, see Table 2-2).
CAP RedirectingPartyID is provided to the application using the top most Diversion header (for more information, see Table 2-2).
CAP RedirectionInformation is provided to the application as defined in Table 2-6.
Table 2-6 CAP RedirectionInformation
| CAP RedirectionInformation Parameter: Value | Used SIP Header |
|---|---|
|
OriginalRedirection Reason :: unknown/not available |
bottom most diversion header, reason=unknown |
|
OriginalRedirection Reason :: user busy (national use) |
bottom most diversion header, reason=user-busy |
|
OriginalRedirection Reason :: no reply (national use) |
bottom most diversion header, reason=no-answer |
|
OriginalRedirection Reason :: unconditional (national use) |
bottom most diversion header, reason= unconditional |
|
RedirectionCounter :: binary number between 1 and 5 |
diversion-counter |
|
RedirectingReason :: unknown/not available |
top most diversion header, reason=unknown |
|
RedirectingReason :: user busy |
top most diversion header, reason=user-busy |
|
RedirectingReason :: no reply |
top most diversion header, reason=no-answer |
|
RedirectingReason :: unconditional |
top most diversion header, reason= unconditional |
|
RedirectingReason :: deflection during alerting |
top most diversion header, reason= deflection |
|
RedirectingReason :: deflection immediate response |
top most diversion header, reason= follow-me |
|
RedirectingReason :: mobile subscriber not reachable |
top most diversion header, reason=out-of-service |
Table 2-7 Developing an Initial Call Control Application: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To provide an initial call control, a SIP application needs to respond to the SIP INVITE message with a SIP 302 Moved Temporarily message.
An initial call control application can perform one of the following actions:
Updating the called party number (that is to replace the number dialed by the calling party with a new number)
Leaving the called party number unmodified
Updating the calling party number.
The following sections describe how to implement these options.
Note:
An initial call control application may also reject a call. This functionality is described in "Rejecting a Call".Table 2-8 Updating the Called Party Number: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To update the called party number (that is to replace the number dialled by the calling party with a new number), the application sets Contact header of the SIP 302 Moved Temporarily to the new destination address and sends the SIP 302 Moved Temporarily to Service Broker.
Based on this message, Service Broker generates a CAP Connect operation and sends it to the MSC.
Note:
The application can set the user part with digits only.Figure 2-1 shows the high level architecture for an initial call control application that updates the called party number.
Figure 2-1 Architecture for Updating the Called Party Number by an Initial Call Control Application over a SIP Network
Figure 2-2 shows the same application as shown on Figure 2-1. However, on Figure 2-2, the application provides the same functionality over a CAP network using Service Broker.
Figure 2-2 Architecture for Updating the Called Party Number by an Initial Call Control Application over a CAP Network Using Service Broker
Figure 2-3 shows the detailed sequence diagram for an initial call control application that updates the called party number.
Service Broker creates a CAP Connect operation based on the information received in the SIP 302 Moved Temporarily response. Table 2-9 shows the content of the CAP Connect operation as set by Service Broker.
Table 2-9 Service Broker Maps SIP 302 Moved Temporarily to CAP Connect Operation
| CAP Connect | Source |
|---|---|
|
DestinationRoutingAddress :: AddressSignal |
302 Moved Temporarily :: Contact :: user part |
|
DestinationRoutingAddress :: InternalNetworkNumberIndicator |
Service Broker configuration |
|
DestinationRoutingAddress :: NumberingPlanIndicator |
Service Broker configuration |
Table 2-10 Leaving the Called Party Number Unmodified: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To leave the called party number unmodified, the application sets the SIP 302 Moved Temporarily response to the address provided in the user part of the RequestURI header of the SIP INVITE, which is sent by Service Broker. This address is set in the user part of the Contact header.
This action makes Service Broker to respond to a CAP InitialDP with a CAP Continue operation.
The Continue operation has no parameters.
Figure 2-4 shows the detailed sequence diagram for an initial call control application that leaves the called party number unmodified.
Table 2-11 Updating the Calling Party Number: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To update the calling party number, the application responses with a SIP INVITE in which the P-Asserted-Identity header or the From header are set to the new destination.
After Service Broker receives this SIP INVITE, Service Broker sets the genericNumbers parameter of the CAP Connect operation to the value set in P-Asserted-Identity header or the From header of the SIP INVITE. Then Service Broker sends the CAP Connect to the MSC.
Figure 2-5 shows the high level architecture for an initial call control application that updates the calling party number over a SIP network.
Figure 2-5 Architecture for Updating the Calling Party Number by an Initial Call Control Application over a SIP Network
Figure 2-6 shows the same application as shown on Figure 2-5. However, on Figure 2-6, the application provides the same functionality over a CAP network using Service Broker.
Figure 2-6 Architecture for Updating the Calling Party Number by an Initial Call Control Application over a CAP Network Using Service Broker
Figure 2-7 shows the detailed sequence diagram for an initial call control application that updates the calling party number.
Table 2-12 Developing a Full Call Control Application: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To provide a full call control, the application implements a SIP B2BUA. The application receives the SIP INVITE message sent by Service Broker and creates a new SIP dialog by sending a new SIP INVITE towards Service Broker.
Service Broker receives the SIP INVITE and sends a CAP Continue or a CAP Connect operation accompanied by a CAP RequestReportBCSEvent operation.
The CAP RequestReportBCSEvent operation instructs the MSC to monitor the call for call related events (for example O_Busy or O_No_Answer) and send notifications to Service Broker when an event is detected.
Service Broker sets the specific events to be monitored in the CAP RequestReportBCSEvent operation as defined in the Service Broker configuration.
Note:
Service Broker enables the application to specify events to be monitored, and by doing this, to overwrite the Service Broker configuration. For more information, see "Controlling the EDPs Arming".The following sections describe various call control capabilities. To provide each of the call control capabilities defined below, the application must follow relevant instructions described in the following sections.
A full control application needs to propagate the SDP which is provided by Service Broker, back-to-back. Figure 2-8 shows how the SDP is handled during the call initiation phase.
Figure 2-9 shows how the SDP is handled during the call answering phase.
Table 2-14 Handling the SIP Route Header: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
The SIP Route header is defined in RFC 3323. A SIP full call control application implemented over Service Broker has to follow the loose-routing mechanism defined in RFC 3261.
Figure 2-10 demonstrates the loose-routing mechanism.
Table 2-15 Updating the Called Party Number: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To update the called party number, application sets the SIP INVITE which is sent to Service Broker, to a new destination address. The new destination address is set in the user part of the RequestURI header. This makes Service Broker to respond to the CAP InitialDP with a CAP Connect operation.
Figure 2-11 shows the high level architecture for a full control application that updates the called party number.
Figure 2-11 Architecture for Updating the Called Party Number by a Full Call Control Application over a SIP Network
Figure 2-12 shows the same application as shown on Figure 2-11. However, on Figure 2-12, the application provides the same functionality over a CAP network using Service Broker.
Figure 2-12 Architecture for Updating the Called Party Number by a Full Call Control Application over a CAP Network Using Service Broker
Figure 2-13 and Figure 2-14 show the detailed sequence diagram for a full control application that updates the called party number.
An application can trigger Service Broker to create a CAP Connect operation using one of the following methods:
An application can transfer the information that Service Broker uses to generate a CAP Connect in the headers of the SIP INVITE message. In this case, Service Broker maps the contents of these headers to the CAP Connect. Table 2-16 shows the contents of the CAP Connect operation as set by Service Broker.
Table 2-16 Service Broker Maps SIP INVITE to CAP Connect Operation
| CAP Connect | Source |
|---|---|
|
DestinationRoutingAddress :: AddressSignal |
INVITE :: Request-URI :: user part |
|
DestinationRoutingAddress :: NatureOfAddress indicator |
INVITE :: Request-URI :: noa token For more information on the noa token, see "Exposing Nature of Address" and "Updating the Nature of Address". |
|
DestinationRoutingAddress :: InternalNetwork NumberIndicator |
Service Broker configuration |
|
DestinationRoutingAddress :: NumberingPlan Indicator |
Service Broker configuration |
|
CallingPartysCategory |
INVITE :: CPC |
|
OriginalCalledPartyID |
Diversion :: name-addr OriginalCalledPartyID is set from the bottom most Diversion header. |
|
RedirectingPartyID |
Diversion :: name-addr RedirectingPartyID is set from the top most Diversion header. |
|
RedirectionInformation :: counter |
Diversion :: counter The counter is set from the top most Diversion header. |
|
RedirectionInformation :: RedirectingReason |
Diversion :: reason The RedirectingReason is set from the top most Diversion header. |
|
RedirectionInformation :: OriginalRedirectionReason |
Diversion :: reason OriginalRedirection Reason is set from the bottom most Diversion header. |
|
RedirectionInformation :: RedirectingIndicator |
RedirectingIndicator is set to "call diverted". |
|
GenericNumbers :: AddressSignal |
INVITE :: From :: user part |
|
GenericNumbers :: NumberQualifierIndicator |
Service Broker configuration |
|
GenericNumbers :: NatureOfAddressIndicator |
INVITE :: From :: noa token For more information on the noa token, see "Exposing Nature of Address"and "Updating the Nature of Address". |
|
GenericNumbers :: NumberIncompleteIndicator |
Service Broker configuration |
|
GenericNumbers :: NumberingPlanIndicator |
Service Broker configuration |
|
GenericNumbers :: AddressPresentationRestrictedIndicator |
Service Broker configuration |
|
GenericNumbers :: ScreeningIndicator |
Service Broker configuration |
|
ServiceInteractionIndicatorTwo :: ForwardServiceInteractionInd :: CallingPartyRestrictionIndicator |
CallingPartyRestrictionIndicator is set to "presentation restricted" if INVITE :: Privacy set to “id” and INVITE :: From is set to: "Anonymous" sip:anonymous@anonymous.invalid. |
The application can encapsulate a CAP Connect operation into a SIP INVITE in the XER format. The XER must contain the destinationRoutingAddress and callingPartysCategory fields.
Note:
Service Broker is provided with a set of XSD files that define the structure of 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.Table 2-17 Leaving the Called Party Number Unmodified: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To leave the called party number unmodified, the application sets the SIP INVITE, which is sent to Service Broker, to the address provided in the SIP INVITE message received from Service Broker.
This procedure is done by copying the user part of the Request-URI of the received SIP INVITE and pasting it into the SIP INVITE sent to Service Broker. This makes Service Broker to respond to InitialDP with a CAP Continue operation.
Figure 2-15 and Figure 2-16 show the detailed sequence diagram for a full control application that leaves the called party number unmodified.
Table 2-18 Updating the Calling Party Number: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To update the calling party number, the application responses with a SIP INVITE in which the P-Asserted-Identity header or the From header are set to the new destination.
After Service Broker receives this SIP INVITE, Service Broker sets the genericNumbers parameter of the CAP Connect operation to the value set in P-Asserted-Identity header or the From header of the SIP INVITE. Then Service Broker sends the CAP Connect to the MSC.
Figure 2-17 shows the high level architecture for a full call control application that updates the calling party number over a SIP network.
Figure 2-17 Architecture for Updating the Calling Party Number by a Full Call Control Application over a SIP Network
Figure 2-18 shows the same application as shown on Figure 2-17. However, on Figure 2-18, the application provides the same functionality over a CAP network using Service Broker.
Figure 2-18 Architecture for Updating the Calling Party Number by a Full Call Control Application over a CAP Network Using Service Broker
Figure 2-19 shows the detailed sequence diagram for a full call control application that updates the calling party number.
Table 2-19 Updating the Nature of Address: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
To update the nature of address of a call party, the application sets the noa token in the SIP INVITE message, which is sent to Service Broker, to the required value as follows:
To update the called party nature of address, the application sets the noa token in the Request-URI header to the required value.
Figure 2-20 shows an example in which the application updates the called party nature of address. This example assumes that the CalledPartyNumber in CAP InitialDP is set with NatureOfAddress of type “national”. The application updates the called party nature of address and sets it to "unknown". This causes Service Broker to set the DestinationRoutingAddress in the CAP Connect operation to NatureOfAddress of type “unknown”.
Note:
In the example shown on Figure 2-20, although the application does not update the called party number, Service Broker uses CAP Connect rather than CAP Continue. This is done because the Connect operation enables Service Broker to update the called party nature of address towards the MSC. The DestinationRoutingAddress parameter of the CAP Connect is set to the called party number as it was set in the calledPartyNumber parameter of the CAP InitialDP operation.For more information on tNOA token, see "Invoking a SIP Application".
Table 2-20 Controlling the EDPs Arming: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
As described in "Developing a Full Call Control Application", when Service Broker receives a SIP INVITE message, which is sent by a full call control application, Service Broker sends a CAP Continue or a CAP Connect operation accompanied by a CAP RequestReportBCSEvent operation.
The specific events to be monitored are set in the CAP RequestReportBCSEvent operation as defined in the Service Broker configuration.
In some cases, it is required that an application dynamically controls the events that Service Broker arms for a given call, that is to define the CAP EDPs set by Service Broker in the CAP RRBCSM operation.
To control the events that Service Broker arms in the RequestReportBCSEvent operation, the application sends a SIP INFO message prior to the SIP INVITE. The SIP INFO is sent through the SIP dialog created by Service Broker and contains a XER representation of the CAP RequestReportBCSEvent operation.
Note:
Service Broker is provided with a set of XSD files that define the structure of 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.Figure 2-21 shows the high level architecture for a full control application that controls the DPs armed by Service Broker.
Table 2-21 Receiving Call Events Notifications: Applicable CAP Phases
| CAP 1 | CAP 2 | CAP 3 | CAP 4 |
|---|---|---|---|
|
YES |
YES |
YES |
YES |
Service Broker notifies a full call control application about encountered call-related events. For each call event encountered at the MSC and reported to Service Broker, Service Broker notifies the application using a corresponding SIP message as described in Table 2-22.
Table 2-22 Event Notifications
| CAP event | SIP message |
|---|---|
|
Route Select Failure |
410 Gone |
|
Busy |
486 Busy Here |
|
No Answer |
480 Temporary Unavailable |
|
Term Seized, Call Accepted |
180 Ringing |
|
Answer |
200 OK |
|
Disconnect |
BYE |
|
Abandon |
CANCEL |
|
Change Of Position, Service Change |
INFO, on outgoing leg containing a XER representation of the ERBCSM |
Notes to Table 2-22:
RouteSelectFailure events are applicable for originating calls only.
The table is applicable for both originating and terminating BCSM. For example, Service Broker uses SIP 486 Busy Here to notify the application about oCalledPartyBusy in an originating call and for tBusy in a terminating call.
If a Disconnect event is reported by the calling party, Service Broker sends a SIP BYE message through the dialog created by Service Broker. If a Disconnect event is reported by the calling party, Service Broker sends a SIP BYE message through the dialog created by the application.
For the DPs reported using SIP INFO, Service Broker sets the SIP INFO with a XER representation of the corresponding CAP EventReportBCSM operation.
Table 2-22 provides the full EDP list supported in CAP 4. Earlier CAP phases support only part of the EDPs listed in the table.
For all T-side notifications that Service Broker receives from, and sends to, an application with a SIP error response, Service Broker uses CAP Continue if the application propagates the response B2B as is. If the application updates the error response, Service Broker uses CAP ReleaseCall.
For a Disconnect and Abandon T-side messages, Service Broker uses SIP BYE and SIP CANCEL set with the Reason header. If the application propagates the BYE/CANCEL B2B as is without updating the contents of the Reason header, Service Broker uses CAP Continue. If the application updates or removes the Reason header, Service Broker uses CAP ReleaseCall.
To confirm notification and enable Service Broker to instruct the MSC to continue call processing at event notification, the application propagates the received SIP message back-to-back.
Note:
Call processing is suspended by the MSC when an event armed as EDP-R is encountered. When EDP-R is reported to Service Broker, MSC requests Service Broker instructions for call processing.Figure 2-22 shows a full control application in the call initiation process. When the called party is alerted, the application receives a SIP 180 Ringing message and propagate it back-to-back.
When the called party answers the call, the application receives a SIP 200 OK and again propagates this message back-to-back towards the initiating side.
Figure 2-23 shows a full control application in the call answering phase.
Finally, when the called party (or in another scenario, the calling party) disconnects the call, the application receives a SIP BYE and propagates it towards the initiating side as shown on Figure 2-24.
Figure 2-25, Figure 2-26, and Figure 2-27 show the same application as shown on Figure 2-22 and Figure 2-24. However, the application below provides the same functionality over a CAP network using Service Broker.
Figure 2-25 Architecture for Initiating a Call by a Full Control Application over a CAP Network Using Service Broker (Alerting Phase)
Figure 2-26 Architecture for Initiating a Call by a Full Control Application over a CAP Network Using Service Broker (Answering Phase)
Figure 2-27 Architecture for Initiating a Call by a Full Control Application over a CAP Network Using Service Broker (Disconnecting Phase)
Figure 2-28 shows the detailed sequence diagram that demonstrates how Service Broker notifies the application for alerting, answer, and disconnect events.
To terminate a call, the application sends a SIP BYE request towards Service Broker. The BYE request is sent on both active dialogs, that is the dialog created by Service Broker and the dialog created by the application.
Service Broker uses the BYE request to terminate the CAP dialog towards MSC using a CAP ReleaseCall operation.
Figure 2-29 shows architecture for a full control application terminating a call.
Figure 2-30 shows the same application as shown on Figure 2-29. However, on Figure 2-30, the application provides the same functionality over a CAP network using Service Broker.
Service Broker may respond towards the application with a SIP error in case an application request cannot be fulfilled or in other error cases as defined in Table 2-24.
| SIP Error | Description |
|---|---|
|
405 Method Not Allowed |
Sent by Service Broker in case the application requests a call control operation which is not legal in the current moment on the CAP interface. |
|
403 Forbidden |
Sent by Service Broker in case the application requests a call control operation which is not supported by the specific CAP interface. |
|
415 Unsupported Media Type |
Sent by Service Broker in case the application provides a non-supported SDP. |
To reject a call, the application responds to the SIP INVITE with a SIP error response (for example, SIP 404 Not Found). When Service Broker receives the SIP error response, Service Broker performs one of the following actions:
Instructs the MSC to terminate the call by sending a CAP ReleaseCall operation
Instructs the MSC to allow the call to continue by sending a CAP Continue operation
Service Broker determines the action to be performed based on its configuration.
Figure 2-31 shows the high level architecture for a full control application that terminates a call.
Note:
The figures below shows an example in which the application uses SIP 404 Not Found to reject the call. In practice, applications are not limited to a specific SIP error response.Figure 2-32 shows the same application as shown on Figure 2-31. However, on Figure 2-32, the application provides the same functionality over a CAP network using Service Broker.
A SIP application can control how Service Broker generates the cause parameter of a CAP Release message using the following methods:
Setting the Reason header of a SIP BYE or SIP CANCEL message. This header should contain a specific cause that IM-SCF can use. For example: Reason: Q.850; cause:31; text: "Session terminated". See RFC 3326, The Reason Header Field for the Session Initiation Protocol (SIP), for more information about the Reason header.
Sending a SIP error response to Service Broker. Service Broker uses this response to set the cause parameter in the CAP ReleaseCall operation. To instruct Service Broker to set the cause parameter of a ReleaseCall operation to a specific value, the application uses the corresponding SIP error response as defined in Table 2–26.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
