2 Developing a SIP Call Control Application

Controlling a Call

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.

Invoking a SIP Application

Table 2-1 Invoking a SIP Application: Applicable CAP Phases

CAP 1

CAP 2

CAP 3

CAP 4

YES

YES

YES

YES

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.

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:

Operator, Language French

Operator, Language English

Operator, Language German

Operator, Language Russian

Operator, Language Spanish

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:

Operator, Language French

Operator, Language English

Operator, Language German

Operator, Language Russian

Operator, Language Spanish

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.

Exposing Nature of Address

Table 2-3 Exposing Nature of Address: Applicable CAP Phases

CAP 1

CAP 2

CAP 3

CAP 4

YES

YES

YES

YES

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.

Table 2-4 NOA Token

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>

Exposing Diversion Information

Table 2-5 Applicable CAP Phases

CAP 1

CAP 2

CAP 3

CAP 4

YES

YES

YES

YES

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.

Developing an Initial Call Control Application

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".

Updating the Called Party Number

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.

Figure 2-3 Initial Call Control Application Updates the Called Party Number

Creating CAP Connect

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.

Leaving the Called Party Number Unmodified

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.

Figure 2-4 Initial Call Control Application Leaves the Called Party Number Unmodified

Updating the Calling Party Number

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

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.

Figure 2-7 Initial Call Control Application Updates the Calling Party Number

Developing a Full Call Control Application

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.

Handling the SDP

Table 2-13 Handling the SDP: Applicable CAP Phases

CAP 1

CAP 2

CAP 3

CAP 4

YES

YES

YES

YES

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-8 Architecture for Handling an SDP (Call Initiation Phase)

Figure 2-9 shows how the SDP is handled during the call answering phase.

Figure 2-9 Architecture for Handling an SDP (Call Answering Phase)

Handling the SIP Route Header

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.

Updating the Called Party Number

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.

Figure 2-13 Full Call Control Application Updates the Called Party Number

Figure 2-14 Full Call Control Application Updates the Called Party Number (cont'd)

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.

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.

Leaving the Called Party Number Unmodified

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.

Figure 2-15 Full Call Control Application Leaves the Called Party Number Unmodified

Figure 2-16 Full Call Control Application Leaves the Called Party Number Unmodified (cont'd)

Updating the Calling Party Number

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

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.

Figure 2-19 Full Call Control Application Updates the Calling Party Number

Updating the Nature of Address

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”.

Figure 2-20 Application Updates the Called Party Nature of Address

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.

Controlling the EDPs Arming

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.

Figure 2-21 Architecture for Controlling DPs by a Full Call Control Application

Receiving Call Events Notifications

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.

Figure 2-22 Architecture for Initiating a Call over a SIP Network (Alerting Phase)

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.

Figure 2-23 Architecture for Initiating a Call over a SIP Network (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-24 Architecture for Initiating a Call over a SIP Network (Disconnecting Phase)

Terminating a Call

Table 2-23 Terminating a Call: Applicable CAP Phases

CAP 1

CAP 2

CAP 3

CAP 4

YES

YES

YES

YES

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-29 Architecture for Terminating a Call over a SIP Network

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.

Figure 2-30 Architecture for Terminating a Call over a CAP Network Using Service Broker

Service Broker Error Responses

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.

Table 2-24 SIP Errors

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

Rejecting a Call

Table 2-25 Rejecting a Call: Applicable CAP Phases

CAP 1

CAP 2

CAP 3

CAP 4

YES

YES

YES

YES

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-31 Architecture for Rejecting a Call over a SIP Network

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.

Figure 2-32 Architecture for Rejecting a Call over a CAP Network Using Service Broker

Controlling the CAP Release Cause

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.