4 Completion of Communications to Busy Subscriber (CCBS), Completion of Communications on No Reply (CCNR) and Completion of Communications on Not Logged-in (CCNL)

24.6423GPPCompletion of Communications to Busy Subscriber (CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 18TS

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

4.1 Introduction

The CCBS, CCNR and CCNL services enable a user, encountering a destination that is busy, does not answer or is not logged-in, to have the communication completed at a later point in time without the user having to manually initiate a new communication attempt.

4.2 Description

4.2.1 General description

The CCBS service enables user A, encountering a busy destination B, to have the communication completed without the user having to manually initiate a new communication attempt when the destination B becomes not busy.

When user A requests the CCBS supplementary service, the network will monitor for destination B becoming free again.

When destination B becomes free again, the network will wait a short time in order to allow the resources to be re-used for originating a communication. If the resources are not re-used by destination B within this time, the network will automatically recall user A.

When user A accepts the CC recall, the network will automatically generate a CC call to destination B.

The CCNR supplementary service enables user A, encountering a destination B which does not answer the communication (No Reply), to have the communication completed without the user having to manually initiate a new communication attempt when the destination becomes not busy after having initiated and completed a new communication.

When user A encounters a destination B which does not answer the communication (No Reply), user A can request the CCNR supplementary service.

When user A requests the CCNR supplementary service, the network will monitor for destination B becoming not busy after having initiated and completed a new communication.

When destination B becomes not busy after having initiated and completed a new communication, the network will wait a short time (as defined by the destination B idle guard timer) in order to allow the resources to be reused for originating a communication. If the resources are not reused by destination B within this time, the network will automatically recall user A.

When user A accepts the CC recall, then the network will automatically generate a CC call to destination B.

The CCNL supplementary service enables user A, encountering a destination B which is not registered with the IMS network (Not Logged-in), to have the communication completed without the user having to manually initiate a new communication attempt when the destination becomes logged in.

When user A encounters a destination B which is not registered with the IMS network (Not Logged-in), user A can request the CCNL supplementary service.

When user A requests the CCNL supplementary service, the network will monitor for destination B becoming registered.

When destination B becomes registered, the network will wait a short time (as defined by the destination B idle guard timer) in order to allow the resources to be used for originating a communication. If the resources are not used by destination B within this time, the network will automatically recall user A.

When user A accepts the CC recall, then the network will automatically generate a CC call to destination B.

The CCBS, CCNR and CCNL service control is done by the application servers. It is possible to modify the queue by the users (add entry, delete entries, delete whole queue) by usage of appropriate procedures.

On the originating side the originating AS A manages the queue of user A and on terminating side the terminating AS B manages the queue of outstanding communications towards UE B.

The originating AS keeps track of the CC requests started by each user for a given period of time, and rejects a new request in case the provisioned limit has been overcome.

The terminating AS keeps track of the CC requests directed to each user for a given period of time, and rejects a new request in case the provisioned limit has been overcome.

After successful CC Call setup the respective entry is deleted in both queues. Also a proper management of the queue in the suspend/resume scenario upon reception of the corresponding message takes place.

4.3 Operational requirements

4.3.1 Provision/withdrawal

The CCBS, CCNR and CCNL services are provided to the served user after prior arrangement with the service provider, or as a service provider option. Withdrawal of these services is made on the served user’s request or for service provider reasons.

4.4 Coding requirements

No specific requirements needed.

4.5 Signalling requirements

4.5.1 Activation/deactivation

The call completion services are individually activated at provisioning or at the subscriber’s request.

The call completion services are individually deactivated at withdrawal or at the subscriber’s request.

4.5.2 Registration/erasure

The CCBS, CCNR and CCNL services require no registration. Erasure is not applicable.

4.5.3 Interrogation

For the interrogation of the call-completion services the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [4] or SIP based user configuration as described in 3GPP TS 24.238 [7] in combination with announcement procedures according to 3GPP TS 24.628 [3] could be used.

4.5.4 Invocation and operation

4.5.4.1 Actions at the originating UE

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method handling procedures according to 3GPP TS 24.229 [2] shall apply.

When the UE receives a SIP final response to the SIP INVITE request and the SIP response contains

a) a Date header field; and

b) a MIME body of the message/external-body MIME type as specified in IETF RFC 4483 [12] with:

1. "access-type" MIME type parameter containing "URL";

2. "URL" MIME type parameter containing an HTTP URI identifying an element <cc-entry> stored in the XML document of the "users" tree of the communication completion request records XCAP application usage and the element <cc-entry> is identified by attribute selector using the "id" attribute; and

3. "expiration" MIME type parameter;

then the UE should use this information to inform the user that:

a) if the date and time in the "expiration" MIME type parameter is later than the date and time of the Date header field, then the communication attempt has led to a communication completion invocation; and

b) if the date and time in the "expiration" MIME type parameter is equal to or earlier than the date and time of the Date header field, then the communication attempt has led to a communication completion revocation.

For invoking of the call completion services, announcement procedures according to 3GPP TS 24.628 [3] and inband-interaction procedures should be used. For revoking the call completions services SIP based user configuration as described in 3GPP TS 24.238 [7] may be used.

NOTE: Other methods for revoking outstanding CC requests such as web based methods are outside the scope of the present document, but are not precluded.

Editor’s note: The usage of inband interaction procedures needs further studies and specification. For invoking and revoking of the call-completion services also out-of-band stimulus procedures according to ETSI TR 183 057 [4] could be used.

4.5.4.2 Actions at the originating AS

4.5.4.2.0 General

The originating 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.

4.5.4.2.1 CC Invocation

4.5.4.2.1.1 Normal procedures

4.5.4.2.1.1.1 Detecting if CC is possible

When in case of CCNL a 480 (Temporarily Unavailable) response has been received from the terminating network, and the following set of conditions apply:

– the 480 (Temporarily Unavailable) response contains an Call-Info header field with a "purpose" header field parameter set to "call-completion"; and

– the user A CCNL queue limit has not been exceeded; and

– CCNL has not been activated for an identical communication (network option), determined by the stored basic communication information defined in subclause 4.5.4.2.1.1.2; and

– there are no service interactions that preclude CCNL;

then the service retention procedure as specified in subclause 4.5.4.2.1.1.2 is executed.

When in case of CCBS a 486 (Busy Here) response has been received from the terminating network, and the following set of conditions apply:

– the 486 (Busy Here) response contains a Call-Info header field with a "purpose" header field parameter set to "call-completion"; and

– the user A CCBS queue limit has not been exceeded; and

– CCBS has not been activated for an identical communication (network option), determined by the stored basic communication information defined in subclause 4.5.4.2.1.1.2; and

– there are no service interactions that preclude CCBS;

then the service retention procedure as specified in subclause 4.5.4.2.1.1.2 is executed.

When in case of CCNR a 180 (Ringing) response has been received from the terminating network, and the following set of conditions apply:

– the 180 (Ringing) response contains a Call-Info header with a purpose parameter set to ‘call-completion’; and

– the user A CCNR queue limit has not been exceeded; and

– CCNR has not been invoked for an identical communication (network option), determined by the stored basic communication information defined in subclause 4.5.4.2.1.1.2; and

– there are no service interactions that preclude CCNR,

then the originating AS shall remove the Call-Info header from the 180 (Ringing) response, forward it to UE-A and start the CC no-reply timer CCNR-T5. When this timer expires then the service retention procedure as specified in subclause 4.5.4.2.1.1.2 is executed.

4.5.4.2.1.1.2 Starting of the service retention procedure

The originating AS shall start the retention timer CC-T1. The originating AS shall retain the following information from the original communication, if available:

1) SDP offer, and

2) Request-URI, and

3) To header field, and

4) From header field, and

5) Privacy header field, and

6) P-Asserted-ID header field, and

7) the Resource-Priority header field.

4.5.4.2.1.1.3 CC service invocation by user A

For the invocation of the CC service, in case of CCNL immediately after receipt of a 480 (Temporarily Unavailable) response with a CCNL possible indication or in case of CCBS immediately after receipt of a 486 (Busy Here) response with a CCBS possible indication or in case of CCNR after receipt of a 180 (Ringing) response with a CCNR possible indication upon expiry of the No-Reply timer CCNR-T5, the originating AS shall provide an announcement that CC is possible to user A, according to 3GPP TS 24.628 [3], followed by inband-interaction procedures for the activation confirmation.

NOTE: User A can have a limited number of CC requests outstanding. This limit is a network provider option (with a maximum value of 5).

If user A does not confirm the activation of CC, the AS shall restore the communication condition from before the announcement and proceed with basic communication procedures by forwarding the 480 (Temporarily Unavailable) response in case of CCNL the 486 (Busy here) response in case of CCBS or sending a 199 (Early Dialog Terminated) on the announcement dialog in case of CCNR.

4.5.4.2.1.1.4 Stopping of the service retention procedure

On receiving a CC invocation confirmation from user A before the expiry of the retention timer CC-T1, the originating AS shall:

a) stop the retention timer CC-T1; and

b) store the retained call information from the original basic communication.

As a network option, in case of receipt of a CCNR invocation confirmation, the originating AS may terminate the original communication by sending a CANCEL request to UE-B, in accordance with the procedures described in 3GPP TS 24.229 [2].

NOTE: The above procedure avoids a race condition between answering the call at the terminating side and subscribing to CCNR at the originating side.

4.5.4.2.1.1.5 Sending of the CC invocation request to the terminating AS

The originating AS shall send a SUBSCRIBE request to the terminating AS according to RFC 6665 [6] and RFC 6910 [5]. The originating AS shall populate the SUBSCRIBE request as follows:

– a Request-URI set to the URI returned by the terminating AS in the Call-Info header field of the response including the CC possible indication

– in case of CCNL as received in the Call-Info header field in the 480 (Temporarily Unavailable) response, including an "m" SIP URI parameter with a value set to "NL";

– in case of CCBS as received in the Call-Info header field in the 486 (Busy Here) response, including an "m" SIP URI parameter with a value set to "BS";

– in case of CCNR as received in the Call-Info header in the 180 (Ringing) response, including an "m" SIP URI parameter with a value set to "NR";

– a From header field set to the URI of UE-A from the original communication;

– a To header field set to the URI of UE-B from the original communication;

– a Contact header field set to the URI of the originating AS;

– a Call-Info header field with the URI of UE-A from the P-Asserted-Identity, a "purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS or "NR" in case of CCNR or "NL" in case of CCNL;

– a P-Asserted-Identity header field as received from the original INVITE request;

NOTE 1: If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted-Identity header field that contains an E.164 number is preferable.

– an Expires header field set to at least the initial value of the service duration timer CC-T3; and

– a Resource-Priority header field from the original communication, if available.

The originating AS shall start the CC request timer CC-T2.

NOTE 2: The To header field is used to identify a particular CC target.

4.5.4.2.1.1.6 Procedures after CC invocation confirmation from the terminating AS

If the originating AS receives a NOTIFY request as an answer to an outstanding CC request which was described in subclause 4.5.4.2.1.1.5 with the cc-state parameter set to ‘queued’, the originating AS shall:

a) stop the CC request timer CC-T2;

b) start the CC service duration timer CC-T3;

c) store the information whether the cc-service-retention parameter has been received or not; and

d) confirm to the caller that the invocation was successful, using announcement procedures according to 3GPP TS 24.628 [3].

In case of CCNL the originating AS shall forward the 480 (Temporarily Unavailable) response to UE-A.

In case of CCBS the originating AS shall forward the 486 (Busy Here) response to UE-A.

In case of CCNR, if the original communication with the UE-B has already been cancelled by the originating AS, the originating AS shall send a 480 (Temporarily Unavailable) response to UE-A.

The originating AS shall include in the SIP 486 (Busy Here) response or the SIP 480 (Temporarily unavailable) response:

a) a Date header field containing the current date and time; and

NOTE: To function correctly the Date header field cannot be removed from SIP response to SIP INVITE request by an IBCF between originating P-CSCF and originating S-CSCF

b) an message/external-body MIME type as specified in IETF RFC 4483 [12] with:

1. "access-type" MIME type parameter containing "URL"; and

2. "URL" MIME type parameter containing an HTTP URI identifying an element <cc-entry>

i) representing the new communication completion request;

ii) stored in the XML document of the "users" tree of the communication completion request records XCAP application usage; and

iii) identified by attribute selector using the "id" attribute;

3. "expiration" MIME type parameter containing the date and time of the communication completion request expiration.

4.5.4.2.1.2 Exceptional procedures

If the originating AS receives a 480 (Temporarily Unavailable) response (short term denial) or a 403 (Forbidden) response (long term denial), in accordance with the procedures of subclause 4.5.4.3.2.2, to an outstanding CC request which was described in subclause 4.5.2.2.1.1.5, then the originating AS shall:

a) stop the CC request timer CC-T2; and

b) confirm to the caller that the invocation was not successful, using announcement procedures according to 3GPP TS 24.628 [3].

In case of CCNL the originating AS shall forward the 480 (Temporarily Unavailable) response to UE-A.

In case of CCBS the originating AS shall forward the 486 (Busy Here) response to UE-A.

4.5.4.2.2 CC Revocation

4.5.4.2.2.1 Normal procedures

4.5.4.2.2.1.1 Generating a revocation request

For revoking the CC service, the originating AS shall send a SUBSCRIBE request to the terminating AS according to RFC 6665 [6] and RFC 6910 [5] in the SUBSCRIBE dialog. The originating AS shall populate the SUBSCRIBE request following normal procedures as specified in 3GPP TS 24.229 [2] with the following additions:

– a P-Asserted-Identity header field as received from the original INVITE request;

NOTE: If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted-Identity header field that contains an E.164 number is preferable.

and

– an Expires header field set to zero.

4.5.4.2.2.1.2 Revocation requested by the user

If the originating AS receives a revocation request by the user, the originating AS shall

– construct a SUBSCRIBE request according to subclause 4.5.4.2.2.1.1; and

– send the SUBSCRIBE request to the terminating AS; and

– inform user A of the result of the revocation by using announcement procedures and inband-interaction procedures according to 3GPP TS 24.628 [3].

The originating AS shall include in the SIP final response to the revocation request:

a) a Date header field containing the current date and time; and

NOTE: To function correctly the Date header field cannot be removed from SIP response to SIP INVITE request by an IBCF between originating P-CSCF and originating S-CSCF

b) an message/external-body MIME type as specified in IETF RFC 4483 [12] with:

1. "access-type" MIME type parameter containing "URL"; and

2. "URL" MIME type parameter containing an HTTP URI identifying an element <cc-entry>

i) representing the communication completion request being revoked;

ii) stored in the XML document of the "users" tree of the communication completion request records XCAP application usage; and

iii) identified by attribute selector using the "id" attribute;

3. "expiration" MIME type parameter containing the date and time of the communication completion request revocation.

4.5.4.2.2.1.3 Revocation caused by timer expiry

If the service-duration timer CC-T3 or the CC recall timer CC-T4 expires, the originating AS shall:

– construct a SUBSCRIBE request according to subclause 4.5.4.2.2.1.1; and

– send the SUBSCRIBE request to the terminating AS.

4.5.4.2.2.2 Exceptional procedures

The originating AS shall be prepared to receive a NOTIFY request caused by a service-duration timer expiry at the terminating AS, according to the procedures of subclause 4.5.4.3.3.2, with:

– the Subscription-State header field set to "terminated"; and

– the "reason" Subscription-State header field parameter set to "noresource".

In this case the originating AS shall stop the CC service-duration timer CC-T3, if this timer is still running.

4.5.4.2.3 CC Operation

4.5.4.2.3.1 Normal procedures

On receipt of a CC recall notification as described in subclause 4.5.4.3.4.1.2, and if user A is neither busy nor CC busy, the originating AS shall initiate the CC recall to user A by sending a REFER request to UE-A according to 3GPP TS 24.229 [2], and shall start the recall timer CC-T4. The originating AS shall populate the REFER request as follows:

– a Request-URI set to the URI of UE-A from the original communication, including an "m" SIP URI parameter with a value set to "NL" in case of CCNL or "BS" in case of CCBS or "NR" in case of CCNR; and

– a Refer-to header set to the URI of UE-B, including an "m" SIP URI parameter set to the same value as in the Request-URI.

If there are multiple outstanding CC requests at the originating AS, then the correct target for the CC recall is identified using standard SIP dialog identification procedures.

In the case UE-A does not support the REFER method extension, the special REFER request handling procedures according to 3GPP TS 24.628 [3] should be used. As a network option, e.g. in the case the originating AS has knowledge that UE-A does not support the REFER method extension, the originating AS may start the 3rd party call control procedures according to 3GPP TS 24.628 [3] without waiting for a 3xx – 6xx response. In this case, the originating AS shall send an INVITE request with a Request-URI set to the URI of UE-A from the original communication, including a "m" SIP URI parameter with a value set to "NL" in case of CCNL or "BS" in case of CCBS or "NR" in case of CCNR. The INVITE request shall include:

– a Call-Info header field with the URI of UE-A from the From header field in the original communication, a "purpose" header field parameter set to "call-completion ", and an m-parameter set to "NL" in case of CCNL or "BS" in case of CCBS or "NR" in case of CCNR ; and

– identity information about user B in the From header field as received in the To header field of the original request. Other identity information may be included if allowed by the Privacy settings in the response of the original communication.

If user A accepts the recall before the CC recall timer expires (a NOTIFY request with a body containing SIP/2.0 100 Trying or a 200 OK to the 3pcc INVITE request according to the special REFER request handling procedures according to 3GPP TS 24.628 [3] is received), the originating AS shall stop timer CC-T4 and initiate the CC call to destination B by sending an INVITE request, in accordance with RFC 6910 [5]. The originating AS shall populate the INVITE request as follows.

– a Request-URI set to the URI of UE-B from the original communication, including an "m" SIP URI parameter

– set to "NL" in case of CCNL; or

– set to "BS" in case of CCBS; or

– set to "NR" in case of CCNR;

– a From header field set to the URI of UE-A from the original communication;

– a To header field set to the URI of UE-B from the original communication;

– a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a "purpose" header field parameter set to "call-completion", and an m-parameter set to "NL" in case of CCNL or "BS" in case of CCBS or "NR" in case of CCNR; and

– a Resource-Priority header field from the original communication, if saved.

4.5.4.2.3.2 Exceptional procedures

4.5.4.2.3.2.1 Non-acceptance of CC recall

If user A does not accept the CC recall or the CC recall timer CC-T4 expires, the originating AS shall perform the procedures in subclause 4.5.4.2.2.1.1.

4.5.4.2.3.2.2 User A is found not available

If the caller is not available for the recall when a CC recall notification as described in subclause 4.5.4.3.4.1.2 has been received, then the originating AS shall suspend the CC request until the caller becomes available again. The originating AS shall send a PUBLISH request to the terminating AS according to RFC 6910 [5] in the existing SUBSCRIBE dialog. The originating AS shall populate the PUBLISH request as following normal procedures as specified in 3GPP TS 24.229 [2] with the following additions:

– a Request-URI set to the contact address of the terminating AS returned by the terminating AS when the SUBSCRIBE dialog was created;

– a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a "purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS or "NR" in case of CCNR or "NL" in case of CCNL;

– a P-Asserted-Identity header field as received from the original INVITE request;

NOTE 1: If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted-Identity header field that contains an E.164 number is preferable.

– an Expires header field set to the current value of the remaining duration of the subscription; and

– a body set to a PIDF informing about the basic state ‘closed’ for the caller’s identity as presentity.

When the originating AS has received an indication that the caller is available again for the recall, then the originating AS shall resume the CC request. The originating AS shall send a PUBLISH request to the terminating AS according to RFC 6910 [5] in the existing SUBSCRIBE dialog. The originating AS shall populate the PUBLISH request as following normal procedures as specified in 3GPP TS 24.229 [2] with the following additions:

– a Request-URI set to the contact address of the terminating AS returned by the terminating AS when the SUBSCRIBE dialog was created;

– a To header field shall contain the URI of UE-B from the original communication;

– a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a "purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS or "NR" in case of CCNR or "NL" in case of CCNL;

– a P-Asserted-Identity header field as received from the original INVITE request;

NOTE 2: If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted-Identity header field that contains an E.164 number is preferable.

– an Expires header field set to the current value of the remaining duration of the subscription; and

– a body set to a PIDF informing about the basic state ‘open’ for the caller’s identity as presentity.

In case the originating AS has sent several suspension requests to different terminating ASs and the AS has received an indication that the caller is available again, the originating AS shall resume each suspended request.

4.5.4.2.3.2.3 The caller makes another call to the same destination B

If the caller initiates another communication to the same destination B and activates the same CC service (CCNL or CCBS or CCNR) again, then:

– if the two communications are identical, then the following network provider options exist:

1) the originating AS shall retain the original request with the current request being discarded and inform the caller that the request has not been accepted because a CC request had already been stored against the requested destination B; or

2) the originating AS shall treat this as a new CC request; and

– if the two calls are not identical, then the originating AS shall treat this as a new CC request. In order to decide that the two calls are identical, the originating AS shall only compare the basic communication information, i.e. the SDP offer, the destination selection information, and calling user identity (if any).

NOTE: It is a network provider option which information is used to identify identical communications.

4.5.4.2.3.2.4 CC call failure

If the CC call fails, the originating AS shall inform the caller as for the basic communication procedures.

If CC is possible (a received 180 (Ringing) or 486 (Busy Here) or 480 (Temporarily Unavailable) response contains a Call-Info header field with a purpose parameter set to "call-completion"), two possibilities exist:

– if the retain option is supported across the networks (the originating AS has received a cc-service-retention parameter in the NOTIFY request described in subclause 4.5.4.3.2.1), the originating AS shall keep the transaction resources and shall not restart the service duration timer CC-T3. If the caller attempts to activate CC again, the originating AS shall treat this as described in subclause 4.5.4.2.3.2.3.

– if the retain option is not supported across the networks, the originating AS shall release the transaction resources. The originating AS shall deactivate the CC request and shall inform the caller accordingly.

If CC is not possible (a received 180 (Ringing) or 486 (Busy Here) or 480 (Temporarily Unavailable) response does not contain a Call-Info header field with a purpose parameter set to ‘call-completion’), the originating AS shall deactivate the CC request according to the procedures described in subclause 4.5.4.2.2 and shall inform the caller accordingly.

4.5.4.3 Actions at the terminating AS

4.5.4.3.0 General

The terminating 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.

4.5.4.3.1 CC possible indication

4.5.4.3.1.1 Normal operation

When on an incoming communication the terminating AS supports the CCNR service, then the terminating AS shall insert a Call-Info header field with either the URI of the terminating AS or the URI received in the original INVITE request, a purpose-parameter set to ‘call-completion’, and an m-parameter set to ‘NR’ in the 180 (Ringing) response forwarded by the AS to indicate whether CCNR is possible or not, in accordance with RFC 6910 [5].

When on an incoming communication the callee is found to be busy and the terminating AS supports the CCBS service, then the terminating AS shall insert a Call-Info header field with either the URI of the terminating AS or the URI received in the original INVITE request, a "purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in the 486 (Busy Here) response generated by the terminating AS (in case of ‘network determined user busy’) or forwarded by the terminating AS (in case of ‘user determined user busy’) to indicate whether CCBS is possible or not, in accordance with RFC 6910 [5].

When on a incoming communication the callee is found to be not registered and the terminating AS supports the CCNL service, then the terminating AS shall insert a Call-Info header field with either the URI of the terminating AS or the URI received in the original INVITE request, a "purpose" header field parameter set to "call-completion", and a m-parameter set to "NL" in the 480 (Temporarily Unavailable) response generated by the terminating AS to indicate whether CCNL is possible or not, in accordance with RFC 6910 [5].

If the terminating AS knows that the CC is not possible on destination B, the terminating AS shall not include a Call-Info header field with a "purpose" header field parameter set to "call-completion" in any response sent to the originating side.

4.5.4.3.1.2 Exceptional procedures

Not applicable

4.5.4.3.2 CC Invocation

4.5.4.3.2.1 Normal operation

Several CC requests can be queued against one destination B in the destination B CC queue (queue B). The exact size of queue B (from 1 to 5 entries) is a destination network operator option.

As a network option the destination network operator can reduce the sizes of the CC queues associated with individual users. The reduced size can be zero. The size of the CCBS queue can also be related to the size of the CCNR queue if existing.

On receipt of a CC invocation request as described in subclause 4.5.4.2.1.1.5, the terminating AS shall:

a) acknowledge the receipt of the SUBSCRIBE request in accordance with RFC 6665 [6].

b) check if the Request-URI of the SUBSCRIBE request is available for the requested CC service; if there is no match, the terminating AS shall check if the URI in the To header field of the SUBSCRIBE request is available for the requested CC service; if it is available, the terminating AS shall store the information received in the CC invocation request in the destination B queue and send a NOTIFY request to the originating AS according to RFC 6910 [5]. The terminating AS shall populate the NOTIFY request as follows:

– a Request-URI set to the URI of the originating AS as received in the Contact header field of the SUBSCRIBE request;

– a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request;

– a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request;

– a Subscription-State header field set to "active";

– the "expires" Subscription-State header field parameter set to the current value of the subscription duration;

– a body set to a cc-state parameter set to ‘queued’; and

– if the retain option is supported at the terminating AS, a cc-service-retention parameter in the same body;

c) start the service duration timer CC-T7; and

d) monitor destination B

– in case of CCNL for becoming registered; or

– in case of CCBS for becoming not busy; or

– in case of CCNR for becoming not busy after having initiated an activity.

NOTE: Methods for monitoring the callee for becoming not busy are a network provider implementation option.

4.5.4.3.2.2 Exceptional procedures

When the invocation of the requested CC service is rejected by the terminating AS, in accordance with RFC 6910 [5] the terminating AS shall send a 480 (Temporarily Unavailable) response (short term denial) or a 403 (Forbidden) response (long term denial), in the following cases:

– if there are already the maximum number of requests queued against destination B;

– if there is an interaction with other services which prevents the invocation of the requested CC service;

– if the URI in the To header field of the SUBSCRIBE request is not available for the requested CC service at destination B.

If the callee is registered when the CCNL invocation request arrives, the terminating AS shall apply the normal CC invocation procedures as described in subclause 4.5.4.3.2.1.

If the callee is no longer busy when the CCBS invocation request arrives, the terminating AS shall apply the normal CC invocation procedures as described in subclause 4.5.4.3.2.1.

If the callee has answered the communication when the CCNR invocation request arrives, the terminating AS shall apply the normal CC revocation procedures as described in subclause 4.5.4.3.3.1.

NOTE: A general error, e. g. a syntax error, or a non-compliance to the call-completion event-package, is answered according to the procedures described in RFC 6665 [6].

4.5.4.3.3 CC Revocation

4.5.4.3.3.1 Normal operation

On receipt of a CC revocation request as described in subclause 4.5.4.2.2.1.1, the terminating AS shall delete the CC request from the destination B queue and send a NOTIFY request to the originating AS according to RFC 6665 [6] and RFC 6910 [5]. The terminating AS shall populate the NOTIFY request as follows:

– a Request-URI set to the URI of the originating AS as received in the Contact header field of the SUBSCRIBE request;

– a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request;

– a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request;

– a Subscription-State header field set to "terminated"; and

– the "reason" Subscription-State header field parameter set to ‘timeout’.

4.5.4.3.3.2 Exceptional procedures

The terminating AS shall automatically revoke a particular request for the CC service if the CC service duration timer CC-T7 expires. If timer CC-T7 expires, the terminating AS shall send a NOTIFY request to the originating AS as described in subclause 4.5.4.3.3.1 with the "reason" Subscription-State header field parameter set to ‘noresource’.

4.5.4.3.4 CC Operation

4.5.4.3.4.1 Normal operation

4.5.4.3.4.1.1 The callee becomes available

When the callee becomes registered or not busy, then the terminating AS shall check queue B:

a) if there is an entry in the queue currently being processed, the terminating AS shall take no further action;

b) otherwise, the terminating AS shall examine the entries in the queue:

c) if an entry is suspended, the terminating AS shall take another entry; and

d) if an entry is not suspended, the terminating AS shall select it for the CC recall.

NOTE: The algorithm for the order addressing entries in the queue is outside the scope of this document. It needs not to be the order of creation of the queue entries.

The terminating AS shall start the destination B idle guard timer CC-T8. When the destination B idle guard timer CC-T8 expires, the terminating AS shall process the selected CC request.

4.5.4.3.4.1.2 The CC recall is started

When processing a CC request, provided that the callee is still available, the terminating AS shall start the CC recall procedure.

The CC recall procedure is defined as follows:

– the terminating AS shall send a NOTIFY request to the originating AS according to RFC 6910 [5]. The terminating AS shall populate the NOTIFY request as follows:

– a Request-URI set to the URI of the originating AS as received in the Contact header field of the SUBSCRIBE request

– a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request;

– a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request;

– a Subscription-State header field set to "active";

– the "expires" Subscription-State header field parameter set to the remaining duration of the subscription;

– a body set to a cc-state parameter set to ‘ready’; and

– the terminating AS shall start the CC recall timer CC-T9.

4.5.4.3.4.1.3 Incoming communication during the CC recall processing

If the terminating AS receives an INVITE request while a CC recall is processed, the terminating AS shall check whether this new incoming communication includes a CC call indicator (an "m" SIP URI parameter is added to the Request-URI, or a Call-Info header field exists and includes an "m" header parameter).

NOTE: The value of the "m" SIP URI parameter and "m" header parameter does not necessary correspond to the invoked CC service.

If the INVITE request includes a CC Call indicator, the terminating AS offer the incoming communication to the callee.

If the INVITE request does not include a CC call indicator, the terminating AS shall reject the incoming communication by generating a 486 (Busy Here) response which includes a CC possible indication, according to the normal CC possible indication procedures described in subclause 4.5.4.3.1.1.

4.5.4.3.4.1.4 Procedures after the CC call was offered to the callee

When the terminating AS has sent a 183 (Session Progress) response, a 180 (Ringing) response or a 200 (OK) response, it shall:

– stop the timers CC-T7 and CC-T9;

– delete the CC request from the destination B queue

– send a CC revocation notification as described in subclause 4.5.4.3.3.2 to the originating AS; and

– if there are further CC requests to be processed, then check whether the callee is busy:

– if the callee is busy, the terminating AS shall take no further action; or

– if the callee is not busy, the terminating AS shall service the queue for destination B as described above.

4.5.4.3.4.1.5 Further procedures

If the originating AS resumes a CC request according to the procedures describe in subclause 4.5.4.2.3.2.2 because user A has become free (i.e. not busy and not CC busy), then, if the callee is available and there is no entry in the CC queue which is currently being processed, the terminating AS shall service the destination B queue as described above.

If the originating AS suspends a CC request according to the procedures describe in subclause 4.5.4.2.3.2.2, the terminating AS shall:

– stop timer CC-T9; and

– send a NOTIFY request to the originating AS, including a body with a cc-state parameter set to ‘queued’; and

– attempt to process another CC request in the same queue.

If the originating AS revokes a CC request according to the procedures described in subclause 4.5.4.2.2.1.1, the terminating AS shall stop timers CC-T7 and CC-T9 and attempt to process another CC request in the same queue.

4.5.4.3.4.2 Exceptional procedures

a) The callee is busy when destination B idle guard timer expires:

If, upon expiry of the destination B idle guard timer CC-T8, the callee is busy (e.g. the callee has initiated an outgoing communication), then the terminating AS shall defer servicing of the destination B CC queue until the callee becomes not busy again.

b) The terminating AS receives a "ready" notification while processing the destination B CC queue:

See subclause 4.6.10.

c) The callee is busy upon arrival of the CC call:

If the callee is busy when a CC call arrives, then the procedures depend on whether the retain option is supported across the networks:

– if the retain option is not supported at the terminating AS, the terminating AS shall cancel the corresponding CC request; the terminating AS shall send a 486 (Busy Here) response with a Call-Info header field with a "purpose" header field parameter set to "call-completion" to the originating AS; if a new CCBS invocation request is received from the originating AS, normal procedures apply, according to subclause 4.5.4.3.2;

– if the retain option is supported at the terminating AS, the terminating AS shall retain the original CC request in the queue; in this case the terminating AS shall continue to monitor destination B, shall not restart the timer CC-T7, shall stop timer CC-T9 and shall send a 486 (Busy Here) response with a Call-Info header field with a "purpose" header field parameter set to "call-completion" to the originating AS.

d) No CC call as result:

If no CC call results from the CC recall mechanism, the recall timer CC-T9 expires. In this case the terminating AS shall send a NOTIFY request to the originating AS according to RFC 6665 [6] and RFC 6910 [5]. The terminating AS shall populate the NOTIFY request as follows:

– a Request-URI set to the URI of the originating AS as received in the Contact header field of the SUBSCRIBE request;

– a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request;

– a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request;

– a Subscription-State header field set to ‘terminated’; and

– the "reason" Subscription-State header field parameter set to ‘rejected’.

4.5.4.4 Actions at the terminating UE

Basic call procedures according to 3GPP TS 24.229 [2] shall apply.

4.5.5 SIP specific Event Notifications

SIP specific Event Notifications shall be used in accordance with RFC 6665 [6] including as referenced in RFC 5875 [9] and RFC 4825 [10].

4.6 Interaction of Call-Completion with other services

4.6.1 Communication waiting (CW)

The CW AS shall not invoke the CW service on a CC recall.

NOTE 1: For a waiting communication, destination B is not considered as busy.
If the communication waiting indication cannot be given at the destination B, user A will receive busy indication and can invoke the CCBS service to destination B.

NOTE 2: Procedures for the case the CC call encounters busy again are described in subclause 4.5.4.3.4.2.

4.6.2 Communication Hold (HOLD)

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

NOTE: When receiving a CC recall indication, user A can invoke the communication hold service in order to make interface resources available for the establishment of the CC call.

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)

The TIR AS shall enforce the privacy settings of the CC recall answer on the CC call and if necessary on the subsequent communication, if the CC recall was invoked via 3pcc procedures.

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)

The OIR AS shall enforce the privacy settings of the originating call on the CC call.

The OIR AS shall enforce the privacy settings of the originating call for SUBSCRIBE and NOTIFY requests when CC is invoked.

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 General

The CDIV AS shall not divert a CC recall. The CDIV AS shall give a CC recall to user A at user A’s original location.

4.6.8.2 Communication Forwarding Unconditional

For CFU activated by B before A requests CC on B:

– If user B has activated CFU, and the forwarded communication results in a call-completion condition at user C, the CC AS shall inform user A that CC is possible at user C. If user A activates CC and subsequently activates CFU, the CDIV AS shall give the CC recall to user A at his original location.
As a network option, in case of a diversion at user B, the CC AS shall not inform user A that CC is possible.

For CFU activated by B after A requests CC on B:

– If user B activates CFU after user A has activated CC on user B, then the CC AS shall revoke the CC request by sending a NOTIFY request to the originating AS as described in subclause 4.5.4.3.3.1 with the "reason" Subscription-State header field parameter set to ‘noresource’.The CC AS serving user A shall send a notification "CC cancelled" to the user A.
As a network option, the CC AS shall suspend the CC request until user B deactivates CFU. If the service duration timer CC-T7 expires before user B deactivates CFU, the CC AS shall revoke the CC request as decribed in subclause 4.5.4.3.3.2.

NOTE: How the "CC cancelled" notification is send to user A is FFS.

4.6.8.3 Communication forwarding busy

For CFB activated by B before A requests CC:

– If user B has activated CFB and is busy, and the forwarded communication results in a call-completion condition at user C, the CC AS shall inform user A that CC is possible at user C.
As a network option, the CC AS shall inform user A that CCBS at user B is possible.

For CFB activated by B after A requests CC on B:

– If user B activates CFB after user A has activated CC on user B, a CC call from user A which encounters a busy condition at user B shall be treated as follows:

– user B shall be considered as being busy and the CC AS shall apply the procedures of CCBS; or

– the CDIV AS shall forward the communication as a normal communication.

4.6.8.4 Communication forwarding no reply

For CFNR activated by B before A requests CC:

– If user B has activated CFNR and does not answer the communication, and the forwarded communication results in a call-completion condition at user C, the CC AS shall inform user A that CC is possible at user C.
As a network option, the CC AS shall inform user A that CCNR at user B is possible.

For CFNR activated by B after A requests CC on B:

– If user B activates CFNR after user A has activated CC on user B, a CC call from user A which encounters a no reply condition at user B shall be treated as follows:

– the CC AS shall apply the procedures of CCNR; or

– the CDIV AS shall forward the communication as a normal communication.

4.6.8.5 Communication forwarding not registered

For CFNL activated by B before A requests CC on B:

– If user B has activated CFNL and is not logged in, and the forwarded communication results in a call-completion condition at user C, the CC AS shall inform user A that CC is possible at user C.
As a network option, the CC AS shall inform user A that CCNL at user B is possible.

For CFNL activated by B after A requests CC on B:

– If user B activates CFNL after user A has activated CC on user B, a CC call from user A which encounters a not logged-in condition at user B shall be treated as follows:

– the CC AS shall apply the procedures of CCNL; or

– the CDIV AS shall forward the communication as a normal communication.

4.6.8.6 Communication deflection (CD)

For the originating user A:

– If a communication to the called user B is deflected to user C by the CD service and results in a call-completion condition at user C, the CC AS shall inform user A that CC is possible at user C. The CDIV AS shall not deflect a CC recall.

For the called user B:

– The CDIV AS shall not deflect a CC call.

4.6.9 Advice of charge (AOC)

Charging information can be given for the original communication, and for the resulting CCBS communication.

4.6.10 Completion of communications (CCBS/CCNR/CCNL)

A user can be both a "user A" and a "user B" simultaneously, i.e. that user can have activated the CC service and have CC requests outstanding whilst at the same time that user can be the destination of CC requests from other users.

The CC AS shall handle CC requests activated by this user (the user’s queue A) with priority over CC requests activated by other users on this user (the user’s queue B), see subclause 4.5.4.3.4.1.1.

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 Message Waiting Indication (MWI)

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

4.6.14 Explicit Communication Transfer (ECT)

Editor’s note: For further studies. For ECT with REFER the transferee does not know to who he sends the INVITE, and if the SUBSCRIBE is sent on another dialog, the SUBSCRIBE may not reach the target AS.

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)

No impact. Neither service shall affect the operation of the other service.

4.6.19 Multi-Identity (MiD)

No impact. Neither service shall affect the operation of the other service.

4.7 Void

4.8 Parameter values (timers)

4.8.1 Timers referring to the originating AS

CC-T1 Retention timer. This timer specifies the amount of time that the network retains the communication information of the original communication which was not established successfully. After being informed that CC is possible the caller sends a CC invocation request before expiry of this timer. The minimum value of this timer is 15 seconds.

CC-T2 CC request operation timer. Supervision of response to a CC activation request sent from the originating AS to the terminating AS. CC-T2 will expire if signalling is not possible, at signalling failures, or if the terminating AS cannot respond. The minimum value of this timer is 10 seconds.

CC-T3 CC service duration timer. This timer specifies the maximum time the service will remain activated for user A. The maximum value of this timer is 180 minutes.

NOTE: The value of the CC service duration timer can differ in the network dependent on the invoked CC service. CCBS can take one value and CCNR or CCNL can take another value.

CC-T4 CC recall timer. This timer specifies the maximum time the originating AS will wait for a response from user A to a CC recall. The maximum value of this timer is 20 seconds.

CCNR-T5 No-reply timer. This timer specifies the maximum time after which the originating AS will provide the announcement that CCNR is possible, and inband activation is possible. The maximum value of this timer is 20 seconds.

4.8.2 Timers referring to the terminating AS

CC-T7 CC service duration timer CC-T7 expiry will only be meaningful if the expiry of CC-T3 has not been notified to the terminating AS. CC-T7 takes a longer duration than CC-T3, i.e. CC-T7 expires at abnormal situations only. The maximum value of this timer is 190 minutes. When CC-T7 expires, the CC request will be cancelled at the terminating AS as well as at the originating AS.

NOTE: The value of the CC service duration timer can differ in the network dependent on the invoked CC service. CCBS can take one value and CCNR or CCNL can take another value.

CC-T8 Destination B idle guard timer. This timer specifies the amount of time the terminating AS will delay after destination B has become free, before initiating a CC recall towards the originating AS. The maximum value of this timer is 10 seconds.

CC-T9 Recall timer. CC-T9 should expire at emergency only, i.e. the recall should be cancelled by CC-T4 at the originating AS if recall is not responded to. Duration of CC-T9 = 20 seconds + some seconds for CC call set-up. The maximum value is 30 seconds.

4.9 Communication completion configuration XCAP application usage

4.9.1 General

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

Data semantics: The semantics of the communication completion XML configuration document is specified in subclause 4.9.2.

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

4.9.2 Data semantics

The active attribute of <communication-completion> element indicates whether the communication completion service is activated or not.

The <communication-completion> element contains an optional <CCBS-CC-T3-timer> and optional <CCNR-CC-T3-timer> elements.

The <CCBS-CC-T3-timer> is a read-only element and indicates the value, in minutes, of the CC-T3 of the CCBS service.

The <CCNR-CC-T3-timer> is a read-only element and indicates the value, in minutes, of the CC-T3 of the CCNR and CCNL services.

4.9.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:include schemaLocation="XCAP.xml"/>

<xs:element name="communication-completion" substitutionGroup="ss:absService">

<xs:annotation>

<xs:documentation>communication completion</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:complexContent>

<xs:extension base="ss:simservType">

<xs:sequence>

<xs:element name="CCBS-CC-T3-timer" type="xs:positiveInteger" minOccurs="0"/>

<xs:element name="CCNR-CC-T3-timer" type="xs:positiveInteger" minOccurs="0"/>

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

</xs:sequence>

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

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

</xs:schema>

4.10 Communication completion request records

4.10.1 General

The communication completion request records XCAP application usage allows a UE to interrogate the communication completion AS to find out a list of the currently pending communication completion requests originated by a public user identity registered at the UE.

The communication completion AS shall support acting as XCAP server as specified in IETF RFC 4825 [10] providing the communication completion request records XCAP application usage as specified in subclause 4.10.2 and shall support acting as notifier of the changes in the communication completion request records XML document using RFC 5875 [9].

The UE may support acting as XCAP client as specified in IETF RFC 4825 [10] accessing the communication completion request records XCAP application usage as specified in subclause 4.10.2 and may support acting as subscriber for the changes in the communication completion request records XML document using RFC 5875 [9].

4.10.2 Communication completion request records XCAP application usage

4.10.2.1 Application Unique ID (AUID)

The AUID of the communication completion request records XCAP application usage is "org.3gpp.ccrr"

4.10.2.2 XML schema

The communication completion request records XML documents are composed according to the XML schema defined in this subclause.

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

<xs:schema

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

xmlns:ccrr="urn:3gpp:ns:ccrr:1.0"

targetNamespace="urn:3gpp:ns:ccrr:1.0"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:element name="cc-records" type="ccrr:Tcomm-completion-req-records"/>

<xs:complexType name="Tcomm-completion-req-records">

<xs:sequence>

<xs:element ref="ccrr:cc-entry" minOccurs="0" maxOccurs="unbounded"/>

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

</xs:sequence>

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

</xs:complexType>

<xs:element name="cc-entry" type="ccrr:Tcomm-completion-entry"/>

<xs:complexType name="Tcomm-completion-entry">

<xs:sequence>

<xs:element name="orig-URI" type="xs:anyURI"/>

<xs:element name="called-URI" type="xs:anyURI"/>

<xs:element name="term-URI" type="xs:anyURI" minOccurs="0"/>

<xs:element name="expiration" type="xs:dateTime"/>

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

</xs:sequence>

<xs:attribute name="id" type="xs:string" use="required"/>

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

</xs:complexType>

</xs:schema>

4.10.2.3 Default document namespace

The default namespace of the communication completion request records XCAP application usage is "urn:3gpp:ns:ccrr:1.0"

4.10.2.4 MIME type

The MIME type of the communication completion request records XML document is specified in annex C.

4.10.2.5 Validation constraints

No additional constraints beyond those defined by IETF RFC 4825 [10] are defined.

4.10.2.6 Data semantics

The communication completion request records XML document contains a root element <cc-records> containing a list of <cc-entry> child elements.

The <cc-entry> element contains information related to a particular pending communication completion request. The <cc-entry> element contains a <orig-URI> element, a <called-URI> element, an optional <term-URI> child element and a <expiration> child element.

The <orig-URI> element contains the identity of the caller.

The <called-URI> element contains the identity called by the caller.

The <term-URI> element contains the identity where the call was routed to. The <term-URI> element is included in the <cc-entry> element, if the identity where the call was routed to was provided by the terminating side and unless the privacy was requested.

The <expiration> element indicates the expiration of the communication completion request.

4.10.2.7 Naming conventions

When stored in a directory of a user within the "users" subdirectory of the communication completion request records XCAP application usage, the filename of the communication completion request records XML document is "index".

4.10.2.8 Resource interdependencies

When the communication completion request records XML document is stored in a directory of a user identified by a URI within the "users" subdirectory of the communication completion request records XCAP application usage, then the <orig-URI> elements contain the URI of the user owning the document.

4.10.2.9 Authorization policies

The owner of the communication completion request records XML document is allowed to read the XML document.

Annex A (informative):
Signalling flows