Developing IR.92 Supplementary Services

About Converged Application Server and VoLTE

GSM Association's (GSMA) IR.92 specifications defines the IP Multimedia Subsystem (IMS) profile for delivering Voice over LTE (VoLTE). The GSMA VoLTE initiative has defined IMS as the common way to deliver voice and messaging services over mobile broadband all-IP networks.

In September 2010, GSMA published the IREG Permanent Reference Document IR.92, which outlines the specifications for migrating 2G and 3G mobile voice, video and messaging services to 4G mobile broadband networks, such as LTE.

This chapter describes the following IR.92 call control services, and their implementation in Converged Application Server:

Communication Diversion

Communication Diversion (also referred to as Call Diversion or Call Forwarding) lets users of the service (the called party, or callee) forward incoming calls to another phone number (the third party). The third party may be a mobile telephone, voice-mail box, or other telephone number where the desired called party is situated.

With Communication Diversion activated:

Users can continue to make outgoing calls from their telephone while incoming calls are forwarded.
When the telephone number the user's calls are being forwarded to is busy, callers to the forwarded number will receive a busy signal.

Converged Application Server supports the following IR.92 defined Communication Diversion modes for VoLTE:

Communication Forwarding Unconditional 3GPP TS 24.604
Communication Forwarding on No Reply 3GPP TS 24.604
Communication Forwarding on not Logged in 3GPP TS 24.604
Communication Forwarding on Busy 3GPP TS 24.604
Communication Forwarding on not Reachable 3GPP TS 24.604

Communication Diversion applications forward calls by removing the callee (the person to whom the call is being made), and adding a new participant (the third party) in the calle's place.

Communication Barring

Communication Barring lets users bar (or restrict) certain or all types of calls to and from their phone. For example, a user can restrict outgoing calls, outgoing international calls, or incoming calls from undesirable callers.

Converged Application Server supports the following IR.92 defined Call Barring modes for VoLTE:

Barring of All Incoming Calls 3GPP TS 24.611
Barring of All Outgoing Calls 3GPP TS 24.611
Barring of Outgoing International Calls 3GPP TS 24.611
Barring of Outgoing International Calls—ex Home Country 3GPP TS 24.611
Barring of Incoming Calls When Roaming 3GPP TS 24.611

To implement international call barring, the Communication Barring application must have access to the phone number of the participant. The application can access this information from various sources, such as the Registrar, to determine roaming status. Similarly, the profile of the user—such as country of origin—can be obtained by the application using other interfaces (for example, the Diameter interface).

Communication Hold

Communication Hold (also referred to Call Hold) allows a user to suspend a communication session—the reception of media stream(s) from an established IP multimedia session—and resume the media stream(s) at a later time. Placing a Communication Hold on an ongoing session is achieved by sending a Session Description Protocol (SDP) offer where each of the communications (media streams) to be held are marked with the sendonly attribute if they were previously bidirectional media streams. To resume the session, a new SDP offer is issued in which each of the held media streams is marked with the default sendrecv attribute.

Communication Hold also allows an AS to play music or an announcement to the held party. This is achieved using an AS that acts as a third-party call controller (3PCC), and replaces the existing session of one of the users with a session originating from an application server that plays the announcement or music until the user's session is resumed. See the 3GPP TS 24.628 specification for more information on the playing of announcements during Communication Hold.

Setting the Communication Hold Bandwidth

The 3GPP TS 24.610 specification requires that the AS of the User Equipment (UE) invoking a media stream whose SDP session attribute is recvonly use a lower bandwidth. The SDP specifies a lower bandwidth by setting the bandwidth (the b= line in the SDP) to a lower value. The b= line contains two elements:

The bandwidth value expressed in kilo bits per second (kbps).
An alphanumeric modifier that indicates the communication session or media stream to which to apply the specified bandwidth value.

The modifiers whose bandwidth values are specified by SFT are:

AS: Application Specific Maximum, which specifies the total bandwidth for a single media stream from one source.
RS: RTCP bandwidth allocated to active data senders.
RR: RTCP bandwidth allocated to other participants (receivers) in the RTP session.

When the bandwidth setting is enabled, SFT sets the default value for the AS bandwidth to zero (b=AS:0). The b=RR: and b=RS: parameters are set to a value of 800 kbps, which is high enough to allow the continuation of the RTCP flow: b=RR:800 and b=RS:800

Example 2-10 Bandwidth Line in the Session Description Protocol

v=0
o=alice 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
b=AS:0
b=RR:800
b=RS:800

Note:

The 3GPP TS 24.610 specification recommends that the AS modify the bandwidth for media streams whose SDP session attribute is recvonly. Media streams whose SDP session attribute are inactive, sendonly, and sendrecv are not affected.

While the 3GPP TS 24.610 specification recommends these values to preserve network bandwidth when a communication is placed on hold, you may need to adjust the bandwidth to better suit the requirements of the Communication Hold application.

Originating Identification Presentation and Restriction

Converged Application Server supports the following Identity Presentation and Restriction services:

Originating Identification Presentation (OIP): Enables the called party to receive a network generated and trusted identity of the calling user on the screen of the mobile device. The originating user may also present a custom identity to be seen at the called party. The user generated identity is usually screened by the network of the originating user.
Originating Identification Restriction (OIR): Invoked when the calling user does not want their identity to be shown to the called party. In such cases, the network of the originating user signals to the network of the called user, to withhold the identity of the calling user.
Terminating Identification Presentation (TIP): Enables the calling party to receive the identification information of the remote party from the network. This information is provided to the originating party once the IMS communication has been accepted between the endpoints. The information is delivered regardless of the capability of the handset to process such information at the originating end.
Terminating Identification Restriction (TIR): Provides the terminating party with an option to restrict the identity to be presented to the originating party of the IMS communication. Logically speaking, TIR is the opposite of TIP.

To support the Identity Presentation and Restriction services listed above:

UE and IMS core network must support the SIP procedures described in the 3GPP TS 24.607 specification. Service configuration, as described in Section 4.10 of 3GPP TS 24.607, is optional.
UE and IMS core network must support the SIP procedures in the 3GPP TS 24.608 specification. Service configuration, as described in section 4.9 of 3GPP TS 24.608, is optional.

Privacy Service Behavior

The privacy service role is instantiated by a network intermediary. Typically this function is performed by entities that act as SIP proxy servers. The privacy service is designed to provide privacy functions for SIP messages that cannot otherwise be provided by the UAs themselves. Table 2-2 lists the semantics of each priv-value, and the RFC that defines them.

Table 2-2 Types of Privacy Service Behaviors

Privacy Type	Description
`user`	Request that privacy services provide a user-level privacy function. See RFC 3323, "A Privacy Mechanism for the Session Initiation Protocol (SIP)" for more information.
`header`	Request that privacy services modify headers that cannot be set arbitrarily by the user. For example, the Contact and Via headers. See RFC 3323, "A Privacy Mechanism for the Session Initiation Protocol (SIP)" for more information.
`session`	Request that privacy services provide privacy for session media. See RFC 3323, "A Privacy Mechanism for the Session Initiation Protocol (SIP)" for more information.
`none`	Privacy services must not perform any privacy function. See RFC 3323, "A Privacy Mechanism for the Session Initiation Protocol (SIP)" for more information.
`critical`	Privacy service must perform the specified services or fail the request. See RFC 3323, "A Privacy Mechanism for the Session Initiation Protocol (SIP)" for more information.
`id`	Privacy requested for Third-Party Asserted Identity. See RFC 3325, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks" for more information.
`history`	Privacy requested for History-Info headers. See RFC 4244, "An Extension to the Session Initiation Protocol (SIP) for Request History Information" for more information.

RFC 5379 describes privacy considerations and the recommended treatment of each SIP header that may reveal user-privacy information. Section 5, "Recommended Treatment of User-Privacy-Sensitive Information" of RFC 5379 describes how each header affects privacy, the desired treatment of the value by the user agent and privacy service, and other details needed to ensure privacy.Table 2-3 lists the recommended treatment for each priv-value contained in the SIP header. See "Section 5" of RFC 5379 "Guidelines for Using the Privacy Mechanism for SIP" for more information.

Table 2-3 Treatment of User-Privacy Information in Target SIP Headers

Target SIP Headers	Where	User	Header	Session	ID	History
Call-ID	R	Anonymize
Call-Info	Rr	Delete	Not added
Contact	R		Anonymize
From	R	Anonymize
History-Info	Rr		Delete	Delete		Delete
In-Reply-To	R	Delete
Organization	Rr	Delete	Not added
P-Asserted-Identity	Rr		Delete		Delete
Record-Route	Rr		Anonymize
Referred-By	R	Anonymize
Reply-To	Rr	Delete
Server	r	Delete	Not added
Subject	R	Delete
User-Agent	R	Delete
Via	R		Anonymize
Warning	r	Anonymize

Providing Privacy for the History-Info Header

The History-Info header (defined in RFC 4244) provides a way of capturing any redirection information that may have occurred during a particular call. Without the History-Info header the redirecting information would be lost. The History-Info header is generated when a SIP request is re-directed, and can appear in any SIP request not associated with a dialog. The History-Info header is generated by a User Agent or proxy and is passed from one entity to another through requests and responses.

Communication Waiting

Communication Waiting (also referred to as Call Waiting) informs a user (or the user equipment) that limited resources are available for incoming calls. Typically this means that the callee is involved in a communication session with another caller, and is not able to answer the incoming call from the second caller. Communication Waiting provides a mechanism by which you can create an application to inform a user that there is a second incoming call. The user then has the choice of accepting, rejecting, or ignoring the waiting call. Converged Application Server supports the 3GPP TS 24.615 and the GSMA IR.92 specifications.

Supporting Network- and Terminal-based Communication Waiting

When using SFT to develop Communication Waiting services, Converged Application Server supports both network- and terminal-based Communication Waiting.

About Network-based Communication Waiting

Network-based Communication Waiting occurs when the AS determines that one of the following conditions has occurred:

The SIP INVITE request fulfills the Network Determined User Busy (NDUB) condition for the callee.
The caller receives a SIP message 486 Busy Here (indicating that the callee is busy) with a 370 Warning in the SIP header field indicating that there is insufficient bandwidth for the call to complete.

To support network-based Communication Waiting, the AS performs the following functions in response to receiving an appropriate Communication Waiting condition:

Modifies the SIP INVITE request and forwards or re-sends it to User B.
Provides an announcement to User C upon receipt of a 180 Ringing response from User B.
Inserts an Alert-Info header field set to urn:alert:service:call-waiting in the 180 Ringing response and forwards it to User C.
Rejects the communication by sending a 486 Busy Here response to User C upon receipt of a 415 Unsupported Media Type response.

About Terminal-based Communication Waiting

Terminal-based Communication Waiting occurs when the AS receives the SIP message 180 Ringing with the Alert-Info header URN Indication Values set to urn:alert:service:call-waiting.

To support terminal-based Communication Waiting, the application server performs the following functions in response to receiving an appropriate Communication Waiting condition:

Sends an announcement to the calling user (the caller).
Sends a 180 Ringing response to the caller.
Initiates the Telephony Application Server-Communication Waiting (TAS-CW) timer. This optional timer specifies the amount of time the network will wait for a response from User B, in response to the communication from User C. The value of the timer is between 0.5 and 2 minutes.

If the TAS-CW timer expires, the AS sends a CANCEL request to User B with a Reason header field set to "SIP," and the cause set to 408 Request Timeout, indicating that the user could not be found in the allotted time. A 480 Temporarily Unavailable response is sent to User C, including a Reason header field set to ISUP Cause Code 19, indicating that there was no answer from the callee.

Message Waiting Indication

Message Waiting Indication (MWI) is a service that informs a user about the status of recorded messages. To use the notification feature, the user must subscribe to a notification service that makes use of the Message Waiting Indication status messages. With the Message Waiting Indication feature you can:

Send notification when a new subscription arrives.
Specify when notifications are sent in response to subscriptions.
Reject subscriptions.
Terminate subscriptions.

Note:

Typically a voice-mail server manages Message Waiting Indication accounts. When a new message arrives, the voice-mail server typically provides a listener or API that you can resister with to receive notification of new messages. How the application manages the message account is beyond the scope of the SFT Message Waiting Indication APIs.

Message Waiting Indication lets the AS notify a subscriber that there is a message waiting for them. The indication is delivered to the subscriber's UE after they have successfully subscribed to the Message Waiting Indication service. Message Waiting Indication is defined in the 3GPP TS 24.606 specification.

When Converged Application Server receives a SUBSCRIBE message, SFT notifies the MWI application via a SUBSCRIPTION event. RFC 3842 specifies that a NOTIFY message must be sent when accepting new subscriptions, the subscription has expired, or an unsubscribe event occurs. Converged Application Server's Event Notification Service sends these NOTIFY messages automatically.

Announcement Support

Announcements are service-related messages played to a recipient to inform them about the state of a call. Announcements can be provided using either audio or video content. Converged Application Server supports the playing of announcements as defined in the 3GPP TS 24.628 specification.

Converged Application Server supports the following approaches to playing announcements:

Send the media stream to the recipient of the announcement for playback.

This approach uses a media server and Media Resource Function Processor (MRFP). The media is streamed to the recipient using the Real-time Transport Protocol (RTP) after establishing a media session with the media server. Based on the point-in-time at which the media session is initiated, an early- or non-early media session can be used.

SFT reserves a media resource using the JSR 309 API (the JSR 309 driver used by the media server). The underlying mechanism between the JSR309 driver and MRFP is protocol agnostic.
Send information about the media content that lets the recipient retrieve and playback the announcement.

This approach sends a URI identifying the media to the recipient, allowing them to determine whether or not to play the announcement.