2 Developing a SIP Call Control Application

Updating the Called Party Number

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

Based on this message, Service Broker generates a CAP Connect operation and sends it to the MSC.

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

Leaving the Called Party Number Unmodified

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.

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

Updating the Calling Party Number

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

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

Handling the SDP

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

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.

Figure 2-10 Architecture for the SIP Loose Routing Mechanism

Updating the Called Party Number

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 Controller to create a CAP Connect operation using one of the following methods:

• An application can transfer the information that Service Controller uses to generate a CAP Connect in the headers of the SIP INVITE message. In this case, Service Controller 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 Controller 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.

Leaving the Called Party Number Unmodified

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

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

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

Updating the Nature of Address

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

For more information on tNOA token, see "Invoking a SIP Application".

Controlling the EDPs Arming

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

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.

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.

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)

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.

Figure 2-28 Service Broker Notifies Application: Alerting, Answering, and Disconnecting Phases

Terminating a Call

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

Controlling the CAP Release Cause

A SIP application can control how Service Controller 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 Controller 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.

  Table 2-26 Release Cause

  CAP Release Cause	SIP Response
  31, normal unspecified	400 to 479
  19, no answer from user	480
  31, normal unspecified	481 to 485
  17, user busy	486
  31, normal unspecified	487 to 699
  31, normal unspecified	Any other SIP error response