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 call control application.
When 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 shows the content of the SIP INVITE message as set by Service Broker. The SIP Header column describes the SIP INVITE headers. The Source column includes the source of the information used by Service Broker to set the SIP INVITE message.
Table 2-2 Service Broker Mapping of CAP 4 InitialDP Operation to SIP INVITE Message
SIP Header | Source |
---|---|
Request-URI :: User part (see the note for Request-URI below the table) |
InitialDP :: CalledPartyNumber OR InitialDP :: CalledPartyBCDNumber CalledPartyBCDNumber is used only when CalledPartyNumber is not included in InitialDP. |
Request-URI :: Domain part |
Service Broker configuration |
To :: User part |
Equals to the value set in RequestURI :: User part |
To :: Domain part |
Service Broker configuration |
From :: User part |
InitialDP :: AdditionalCallingPartyNumber If AdditionalCallingPartyNumber is not included in InitialDP, the From header is set from InitialDP :: CallingPartyNumber. If InitialDP :: CallingPartyNumber :: Address presentation restricted indicator is set to "presentation restricted": The From header is set as follows: From: "Anonymous" sip:anonymous@anonymous.invalid The Privacy header is set as follows: Privacy: id |
From :: Domain part |
Service Broker configuration |
P-Asserted-Identity :: User part (see the note for P-Asserted-Identity below the table) |
InitialDP :: CallingPartyNumber |
P-Asserted-Identity :: Domain part |
Service Broker configuration |
Privacy |
The Privacy header is set as follows: Privacy:id The Privacy header is included only if InitialDP :: CallingPartyNumber :: Address presentation restricted indicator is set to "presentation restricted". |
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 |
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 |
Route |
The "orig" token is included if InitialDP :: eventTypeBCSM set to CollectedInfo or to AnalyzedInformation. The "term" token is included if InitialDP :: EventTypeBCSM set to TermAttemptAuthorized. Service Broker sets the Route header with a token that indicates call direction, that is originating call or terminating call. For originating call, Service Broker sets the token to “orig” while for terminating call token is set to “term”. The SIP INVITE received by application may include several Route headers. |
x-wcs-session-case |
If InitialDP :: EventTypeBCSM set to CollectedInfo or to AnalyzedInformation, the x-wcs-session-case is set as follows: x-wcs-session-case:orig If InitialDP :: EventTypeBCSM set to TermAttemptAuthorized, the x-wcs-session-case is set as follows: x-wcs-session-case:term. |
CPC |
InitialDP :: CallingPartysCategory If InitialDP :: CallingPartysCategory is one of the following:
the CPC header is set to “operator” and the specific language is set in the SIP Accept-Language header |
Accept-Language |
InitialDP :: CallingPartysCategory The SIP Accept-Language is included 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, the P-Charging-Vector header is not included in the SIP INVITE. |
P-Charging vector :: icid-gen-addr |
IM_SCF instance name |
P-Charging vector :: Orig-ioi |
Not set |
P-Charging vector :: Term-ioi |
Not set |
Subject |
The Subject header is set 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 the 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 |
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 towards 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.
Call party nature of address | NOA token content |
---|---|
subscriber number (national use) |
subscriber |
unknown (national use) |
unknown |
national (significant) number (national use) |
national |
International |
noa token is not used |
As shown in Table 2-4, Service Broker does not set the noa token for nature of address of type “International”. When the nature of address of one of the call parties is set to “International”, the user part in the corresponding SIP header is prefixed with “+”. For example:
For the calling party nature of address of type “International”, Service Broker sets the P-Asserted-Identity in the SIP INVITE, which is sent to the application, as follows:
P-Asserted-Identity: <sip:+97297888019@domain:5060>
For the calling party nature of address of type “national (significant) number”, Service Broker sets the P-Asserted-Identity in the SIP INVITE, which is sent to the application, as follows:
P-Asserted-Identity: <sip:97888019@domain:5060;noa=national>
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 towards the 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, the application responds 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 two 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 the SIP 302 Moved Temporarily to the new destination address.
The new destination address is set in the user part of the Contact header. This makes Service Broker to respond to the CAP InitialDP with a CAP Connect operation.
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 the 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 :: NatureOfAddress |
302 Moved Temporarily :: Contact :: noa Service Broker sets the NatureOfAddress in the Connect operation based on the noa token, as set by the application in the Contact header of SIP 302 Moved Temporarily. For more information on noa values, see Table 2-4. |
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 Request-URI 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 302 Moved Temporarily message. This message contains a new calling party number encapsulated into the message body and encoded in the XER format as follows:
Example 2-1 Updating Calling Party Number in SIP 302 Moved Temporarily
<genericNumbers> <OCTET_STRING>0684136307 45716909</OCTET_STRING> </genericNumbers>
After Service Broker receives SIP 302 Moved Temporarily message, Service Broker sets the genericNumbers parameter of the CAP Connect operation to the value set in genericNumbers of SIP 302 Moved Temporarily and sends the CAP Connect to 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 the 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:
The 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.
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 302 Moved Temporarily message. This message contains a new calling party number encapsulated into the message body and encoded in the XER format as follows:
Example 2-2 Updating Calling Party Number in SIP 302 Moved Temporarily
<genericNumbers> <OCTET_STRING>0684136307 45716909</OCTET_STRING> </genericNumbers>
After Service Broker receives SIP 302 Moved Temporarily message, Service Broker sets the genericNumbers parameter of the CAP Connect operation to the value set in genericNumbers of SIP 302 Moved Temporarily and sends the CAP Connect to 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. CAP Connect is set to the called party number as received from 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.
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.
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.
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 |
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.