4 Communication Waiting (CW)

24.6153GPPCommunication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Introduction

The Communication Waiting (CW) service enables a UE to be informed that no resources are available for an incoming communication. The user then has the choice of accepting, rejecting or ignoring the incoming communication (as per basic communication procedures).

4.2 Description

4.2.1 General description

Two cases can occur depending on the network’s ability to validate the status of the destination user upon receipt of an incoming communication and where the CW condition is determined (i.e. "approaching NDUB" condition):

– network based CW, i.e. sufficient information on the user is available at the time a communication is to be delivered to the user, the network validates the status of this user. If the status of the user is "approaching NDUB", the network presents the waiting communication to the destination user; or

– terminal based CW, the network may be informed of the communication waiting situation upon receipt from the destination user of a communication waiting indication (i.e. the CW condition is determined by the UE using UDUB).

When a communication arrives at the destination user, the UE validates the status of the user. If the user is already involved in one or more communications, the terminal notifies the served user of a communication waiting situation.

The user then has different possibilities to react, for example if it may decide to free some resources and accept the incoming communication.

NOTE: The procedures for NDUB are out of scope of this specification. Information for the handling of NDUB can be found in 3GPP TS 22.173 [1] Annex Da and 3GPP TS 24.628 [4] clause B.2.

4.3 Operational requirements

4.3.1 Provision/withdrawal

The Communication Waiting service shall be provided after prior arrangement with the service provider.

The CW service can as a network option, be offered to the corresponding users with a subscription option. This subscription option is part of the CW profile of the served user. The subscription option is shown in the table 4.3.1.1.

Table 4.3.1.1: Subscription option for CW

Subscription option

Value

Served user subscribes to "calling user receives notification that his/her communication is waiting"

No (default)
________________________

Yes (NOTE)

NOTE: The notification can take the form of an announcement played to user C, or an out-of band notification or both. This is up to the network operator to decide.

Timer T_AS-CW is a service provider option. This optional timer specifies the period the network will wait for a response (answer), from user B, to the offered communication from user C. The timer value is specified in subclause 4.7.

NOTE: When used, the value of T_AS-CW is set by the service provider as a default value subject to change only by the service provider.

4.4 Coding requirements

4.4.1 CW indication

The XML schema for the CW information XML body is defined in table 4.4.1.1.

Table 4.4.1.1: IM CN subsystem CW XML body, XML Schema

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema targetNamespace="urn:3gpp:ns:cw:1.0"

xmlns:cw10="urn:3gpp:ns:cw:1.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:complexType name="tEmptyType"/>

<xs:complexType name="tCWtype">

<xs:sequence>

<xs:element name="communication-waiting-indication" minOccurs="0" maxOccurs="1"

type="cw10:tEmptyType"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>

<xs:element name="ims-cw" type="cw10:tCWtype"/>

</xs:schema>

The CW XML schema shall be transported as a SIP MIME body. The MIME type for the CW information is "application/vnd.3gpp.cw+xml" (see subclause 5.1). Any SIP message that transports a body with CW information shall identify the payload as the MIME type associated with CW information (see subclause 5.1).

4.4.2 CW notification

Usage of the urn namespace "alert" with the sub-label "service" and its initial value "call-waiting" within the Alert-Info header field is described in RFC 7462 [8].

4.5 Signalling requirements

4.5.1 General

Configuration of supplementary services by the user should:

– take place over the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [7]; or

– use SIP based user configuration as described in 3GPP TS 24.238 [10].

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the operator are outside the scope of the present document, but are not precluded.

The enhancements to the XML schema for use over the Ut interface is described in subclause 4.8.

4.5.2 Activation/deactivation

The service CW is individually activated at provisioning or at the subscriber’s request.

The service CW is individually deactivated at withdrawal or at the subscriber’s request.

4.5.3 Registration/erasure

The CW service requires no registration. Erasure is not applicable.

4.5.4 Interrogation

For interrogation of CW the mechanisms specified in subclause 4.5.1 should be used.

4.5.5 Invocation and operation

4.5.5.1 Actions at the UE of user C

The procedures described for the originating UE in 3GPP TS 24.229 [2] shall apply with the clarifications below.

Upon receipt of a 180 (Ringing) response with an Alert-Info header field set to "<urn:alert:service:call-waiting>" according to RFC 7462 [8], the UE may indicate that the outgoing communication is being treated as a waiting communication.

4.5.5.2 Actions at the AS of user B

4.5.5.2.1 General

The AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] or operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] for the incoming INVITE request and all future requests and responses in the same dialog.

NOTE: For the case when CW, according to the requirements in this document, is the only service being applied by the AS and if none of the "approaching NDUB" condition, the "calling user receives notification that his communication is waiting" option and the "T_AS-CW timer" option are used, then the AS only needs to act as a SIP proxy. If additional services are applied, then the AS might need to act as a routeing B2BUA.

If a CW condition occurs, upon receipt of a 180 (Ringing) response, the AS shall as a network option start the T_AS-CW timer. Upon expiry of the T_AS-CWtimer, the AS shall send a CANCEL request towards the user B’s UE as described in 3GPP TS 24.229 [2] including a Reason header field (see RFC 3326 [12]) with the protocol set to "SIP" and the cause set to "408", and a 480 (Temporarily unavailable) response towards user C, including a Reason header field with the protocol set to "Q.850" and the cause set to "19", in accordance with RFC 6432 [11].

4.5.5.2.2 AS supporting the network based CW

The AS shall determine that a CW condition has occurred when one of the following conditions are met:

– receipt of an INVITE request that fulfils the "approaching NDUB" condition for user B; or

– receipt of a 486 (Busy here) response with a 370 Warning header field indicating "insufficient bandwidth".

When the CW condition is met:

– if the Contact header received from user B in the establishment or modification of the the existing active communication contained a GRUU then the AS shall:

a) include that GRUU in the Request-URI in the INVITE request;

b) include as the hi-entry in the History-Info header field the contents of the Request-URI from the received INVITE request according to RFC 7044 [14] if it was not already present; and

c) include as the last hi-entry in the History-Info header field the contents of the new Request-URI (with the GRUU) including the "rc" header field parameter as described in RFC 7044 [14];

– if the CW indication is supported, the AS may insert a MIME body according to subclause 4.4.1 in the INVITE request, with the <communication-waiting-indication> element contained in the <ims-cw> root element. If the MIME body described in subclause 4.4.1 is inserted, the AS shall set the Content-Type header field of the inserted MIME body to "application/vnd.3gpp.cw+xml", and set the Content-Disposition header field of the inserted MIME body to "render" as specified in RFC 3261 [15] and include the "handling" header field parameter set to "optional" as specified in RFC 3459 [16];

– if required by operator policy, the AS shall include the Expires header field set to the value of T_AS-CW timer; and

– the AS shall forward or send the INVITE request to user B.

NOTE: If the user is roaming, and the terminating P-CSCF is in the visited network, this functionality can only be supported if an SLA (Service Level Agreement) exists between the operators to provide the related functionality.

If the CW condition was determined by the AS based on validation of the "approaching NDUB" condition and if the subscription option "calling user receives notification that his communication is waiting" is set to "Yes", then after receipt of a 180 (Ringing) response from user B:

– the AS may provide an announcement to user C in accordance with 3GPP TS 24.628 [4]; and

– if not included, the AS shall insert an Alert-Info header field set to "<urn:alert:service:call-waiting>" according to RFC 7462 [8] in the 180 (Ringing) response and forward it to user C.

After the receipt of a 415 (Unsupported Media Type) response, the AS shall reject the communication by sending a 486 (Busy Here) response to user C.

4.5.5.2.3 AS supporting the terminal based CW

The AS shall determine that a CW condition has occurred on receipt of a 180 (Ringing) response with an Alert-Info header field set to "<urn:alert:service:call-waiting>" according to RFC 7462 [8].

When the CW condition is met:

a) If the subscription option "calling user receives notification that his/her communication is waiting" is set to "Yes", the AS may initiate the procedures for notifying user C by performing a combination of the following actions:

1. provide an announcement to the calling user in accordance with 3GPP TS 24.628 [4]; and

2. forward the 180 (Ringing) response to the calling party; and

b) If the subscription option "calling user receives notification that his/her communication is waiting" is set to "No", the AS shall:

1. remove the Alert-Info header field set to "<urn:alert:service:call-waiting>" from the received 180 (Ringing) response; and

2. forward the modified 180 (Ringing) response to the calling party.

4.5.5.3 Actions at the UE of user B

4.5.5.3.1 General

Basic communication procedures according to 3GPP TS 24.229 [2] shall apply with the clarifications and additions described in the following subclauses.

4.5.5.3.2 Communication waiting presentation procedures

When receiving an initial INVITE request, the UE shall determine the CW condition and the UDUB condition.

Upon detecting CW condition and if the maximum number of waiting communications is not reached (i.e. UDUB condition has not occured) the UE shall:

a) provide a CW indication to the user;

b) optionally, if the INVITE includes an Expires header field, use the value of this header field to provide the time to expiry information of the communication waiting to the user;

c) optionally start timer T_UE-CW;

NOTE 1: The timer T_UE-CWis used in order to limit the duration of the CW condition at the UE. For terminals that can provide an indication to the user that a CW condition is occuring without disturbing the active communication, this timer is not needed.

d) if the received INVITE:

– does not contain a MIME body according to subclause 4.4.1;

– the UE does not support the MIME body specified in subclause 4.4.1; or

– contains a MIME body according to subclause 4.4.1 with the <communication-waiting-indication> element contained in the <ims-cw> root element and a Content-Type header field set to "application/vnd.3gpp.cw+xml" and the "handling" header field parameter in the Content-Disposition header field of the inserted MIME body is set to "optional";

then the UE shall insert an Alert-Info header field, set to "<urn:alert:service:call-waiting>", specified in RFC 7462 [8], in the 180 (Ringing) response in accordance with the provisional response procedures described in 3GPP TS 24.229 [2]; and

e) if the UE supports the MIME body specified in subclause 4.4.1 and the received INVITE contains a MIME body according to subclause 4.4.1 with the <communication-waiting-indication> element contained in the <ims-cw> root element and a Content-Type header field set to "application/vnd.3gpp.cw+xml", then the UE shall send a 180 (Ringing) response to the INVITE request according to the provisional response procedures described in 3GPP TS 24.229 [2];

NOTE 2: RFC 5621 [9] describes conditions under which a 415 (Unsupported Media Type) response is returned.

4.5.5.3.3 User B actions during communication waiting condition

Case A

If user B accepts the waiting communication and holds (per procedures in 3GPP TS 24.610 [5]) or releases (per procedures in 3GPP TS 24.229 [2]) the active communication and timer T_UE-CW has not expired, user B’s UE shall:

– stop timer T_UE-CW(if it has been started);

– stop providing the CW indication to user B; and

– apply the procedures for answering the waiting communication to user B as described in 3GPP TS 24.229 [2].

Case B

If T_UE-CW was started and expires, user B’s UE shall:

– stop providing the CW indication to user B; and

– send a 480 (Temporarily Unavailable) response towards user C, optionally including a Reason header field set to cause "19", in accordance with RFC 6432 [11].

4.5.5.3.4 Communication release during a communication waiting condition

If user B’s UE receives a CANCEL request or BYE request from user C during a CW condition, user B’s UE shall:

– stop timer T_UE-CW (if necessary);

– stop providing the CW indication to user B; and

– apply the terminating UE procedures upon receipt of CANCEL or BYE as described in 3GPP TS 24.229 [2].

If user B’s UE receives a CANCEL request or BYE request from user A and during a CW condition, user B’s UE shall:

– stop timer T_UE-CW (if necessary);

– stop providing the CW indication to user B;

– apply the terminating UE procedures upon receipt of CANCEL request or BYE request as described in 3GPP TS 24.229 [2]; and

– optionally apply the procedure for accepting the waiting communication as described in 3GPP TS 24.229 [2].

4.6 Interaction with other services

4.6.1 Communication Waiting (CW)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.2 Communication Hold (HOLD)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.3 Terminating Identification Presentation (TIP)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.4 Terminating Identification Restriction (TIR)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.5 Originating identification presentation (OIP)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.6 Originating identification restriction (OIR)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.7 Conference calling (CONF)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.8 Communication diversion services (CDIV)

4.6.8.1 Communication forwarding unconditional (CFU)

If user B has activated the communication forwarding unconditional supplementary service, then the execution of the communication forwarding unconditional supplementary service shall take precedence over the network based CW service. The communication forwarding unconditional service can be activated while a communication is waiting without changing the state of the waiting communication.

A forwarded communication can invoke the CW service.

4.6.8.2 Communication forwarding busy (CFB)

No impact, i.e. neither supplementary service shall affect the operation of the other supplementary service.

NOTE: The following text clarifies the situation. If user B is NDUB, communication forwarding busy will take place, and the communication is not offered to user B. If user B is not NDUB, the communication is offered to B, and if the UDUB (User Determined User Busy) condition occurs, then the communication forwarding busy will take place.

A forwarded communication can invoke the CW service.

4.6.8.3 Communication forwarding no reply (CFNR)

If user B has activated the communication forwarding no reply service, then a waiting communication shall still be offered as described in this document. If the communication forwarding no reply timer expires before an answer is received then the communication forwarding no reply service is invoked and the communication is forwarded and communication waiting ceases.

A forwarded communication can invoke the CW service.

4.6.8.4 Communication forwarding on Not Logged-in (CFNL)

No impact, i.e. neither supplementary service shall affect the operation of the other service.

A forwarded communication can invoke the CW service.

4.6.8.5 Communication deflection (CD)

When receiving the communication waiting indication, user B can invoke the communication deflection service.

A deflected communication can invoke the CW service.

4.6.9 Advice of charge (AOC)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.10 Completion of calls to busy subscriber (CCBS) Completion of Communications by No Reply (CCNR)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.11 Malicious communication identification (MCID)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.12 Anonymous Communication Rejection and Communication Barring (ACR/CB)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.13 Explicit Communication Transfer (ECT)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.14 Message Waiting Indication (MWI)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.15 Flexible Alerting (FA)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.16 Customized Alerting Tones (CAT)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.17 Enhanced Calling Name (eCNAM)

No impact, i.e. neither service shall affect the operation of the other service.

4.6.18 Multi-Device (MuD)

If user B has activated the MuD service, the terminal-based CW (using UDUB) shall be applied.

4.6.19 Multi-Identity (MiD)

No impact.

4.7 Parameter values (timers)

The use of T_AS-CWtimer is a network option. When used, the value of T_AS-CWtimer shall be set by the network operator as a default value subject to change only by the network operator. The value of this timer is between 0,5 and 2 minutes.

NOTE 1: When used, the value of T_AS-CW is set by the service provider as a default value subject to change only by the service provider.

The use of T_UE-CWtimer is a terminal option. This timer has no predefined value.

NOTE 2: The timer T_UE-CWis used in order to limit the duration of the CW condition at the UE. For terminals that can provide an indication to the user that a CW condition is occuring without disturbing the active communication, this timer is not needed.

4.8 Service Configuration

4.8.1 General

Communication waiting documents are sub-trees of the simservs XML document specified in 3GPP TS 24.623 [7]. As such, communication waiting documents use the XCAP application usage in 3GPP TS 24.623 [7].

Data semantics: The semantics of the communication waiting XML configuration document is specified in subclause 4.8. 2.

XML schema: Implementations in compliance with this specification shall implement the XML schema that minimally includes the XML Schema defined in subclause 4.8. 3 and the simservs XML schema specified in subclause 6.3 of 3GPP TS 24.623 [7].

An instance of a communication waiting document is shown:

<?xml version="1.0" encoding="UTF-8"?>

<communication-waiting active="true"/>

</simservs>

4.8.2 Data Semantics

The CW service can be activated/deactivated using the active attribute of the <communication-waiting> service element.

4.8.3 XML Schema

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:ss="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://uri.etsi.org/ngn/params/xml/simservs/xcap" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="communication-waiting" type="ss:simservType" substitutionGroup="ss:absService">

<xs:annotation>

<xs:documentation>communication waiting

</xs:documentation>

</xs:annotation>

</xs:element>

</xs:schema>