Content for  TS 24.186  Word version:  19.0.0

The multi-device service with IMS data channel, procedures for the IMS AS serving the user B having federated UEs, shall be in accordance with TS 24.174 with the additions defined in the present document. On reception of a SIP initial INVITE request with an SDP offer containing IMS data channel media descriptions, the IMS AS of the user B, shall execute multi-device service procedure, which branch the call into several call legs to alert the federated UEs of the user B. The IMS AS shall determine whether the served user B is authorized to use IMS data channel. If the served user is authorized to use IMS data channel, then for each federated UE of the user B the IMS AS shall determine if the federated UE supports IMS data channel capabilities. For each created call leg towards the federated UE:

1. if the served user B is authorized to use IMS data channel and if the federated UE supports IMS data channel capabilities, the IMS AS shall follow procedure specified in clause 9.3.3.2.1, bullet 1); and
2. if the served user B is authorized to use IMS data channel but the federated UE does not support IMS data channel capabilities or if the served user B is not authorized to use IMS data channel, the IMS AS shall follow procedure specified in clause 9.3.3.2.1, bullet 2).

On reception of an INVITE request from the UE of the user A who has triggered the call pull request, to establish new partial dialog with the IMS AS of the user A in accordance with clause 4.5.3.2.3 of TS 24.174:

1. the IMS AS shall update existing partial dialog towards the remote network in accordance with clause 4.5.3.2.3 of TS 24.174 and TS 24.229, containing media descriptions to close established data channels associated with the UE of the user A whose call is getting pulled; and
2. after the successful session acknowledgement between the UE of the user A who has triggered the call pull request and the remote network, the IMS AS shall notify the DCSF about the session release event for the call leg towards the UE of the user A whose call is getting pulled and the established data channels associated with the UE of the user A whose call is getting pulled are closed as part of a partial dialog termination in accordance with clause 9.3.2.1.5.

On reception of a SIP REFER request for call push request from the UE of the user A involved in ongoing call:

1. the IMS AS shall establish new partial dialog with the target UE of the user A in accordance with clause 4.5.3.2.4 of TS 24.174 and clause 4.4a of TS 24.628;
2. the IMS AS shall update existing partial dialog towards the remote network in accordance with clause 4.5.3.2.4 of TS 24.174 and TS 24.229, containing media descriptions to close established data channels associated with the UE of the user A who has triggered the call push request in accordance with clause 9.3.3.1.4 of this specification; and
3. after a successful session acknowledgement between the target UE of the user A and the remote network, the IMS AS shall notify the DCSF about the session release event for the call leg towards the UE of the user A who has initiated the call push request and the established data channels associated with the UE of the user A who has initiated the call push request are closed as part of a partial dialog termination in accordance with clause 9.3.2.1.5.

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, which is defined in TS 24.642.

When the UE initiates the initial IMS session before the CC services activation, the IMS data channel media description can be included in the INVITE along with other MMTel medias. The procedure defined in clause 9.3.2.1.2 applies. On reception of the 486 (Busy Here) in case of CCBS or the 480 (Temporarily Unavailable) in case of CCNL or on sending the 487 (Request Terminated) in case of CCNR, the UE shall terminate the existing call session as specified in TS 24.642 including data channel media. When the CC call is initiated, the IMS data channel media description can be included in initial INVITE message along with other MMTel medias.

Upon reception of the incoming sessions setup INVITE request in the IMS AS serving the originating UE with the media feature tag +sip.app-subtype="webrtc-datachannel" as specified in TS 26.114 in the Contact header field and SDP offer containing the media descriptions for the MMTel media according TS 24.173 and a data channel media description for the bootstrap data channel in accordance with TS 26.114, the AS will trigger the DC media resources reservation according to TS 23.228 and route the INVITE message to the S-CSCF towards the terminating UE. In case of CCBS activation, on reception of SIP response 486 (User Busy) from the terminating network, the IMS AS will release the reserved data channel media offered to the terminating network as per procedures defined in clause 9.3. On sending the SIP response 486 (User Busy) to the originating UE, the AS will release the reserved data channel media terminated from the originating UE as per procedures defined in clause 9.3. In case of CCNL activation, on reception of SIP response 480 (Temporarily Unavailable) from the terminating network, the IMS AS will release the reserved data channel media offered to the terminating network as per procedures defined in clause 9.3. On sending the SIP response 480 (Temporarily Unavailable) to the originating UE, the IMS AS will release the reserved data channel media terminated from the originating UE as per procedures defined in clause 9.3. In case of CCNR activation, upon reception a 180 (Ringing) response from the terminating network, the IMS AS will notify to DCSF and update the data channel media resources. Upon reception the SIP response 487 (Request Terminated) from the terminating network, the IMS AS will release the data channel media resources along with the session release.

The CRS service is an operator specific service specified in TS 24.183, which describes three models of CRS service:

• Download and play model: it has no interaction with IMS data channel.
• Gateway model: it has no impact to IMS data channel.
• Early session model: it has no impact to IMS data channel.

As specified in TS 24.183, the CRS media can consist of music, voice, text, video or other customized ringing signals.

When the originating UE is configured with IMS_DC_configuration node specified in TS 24.275 and the DC_Setup_Option leaf indicates that the IMS data channel is to be setup simultaneously while establishing an IMS session, the data channel media can be negotiated in the initial INVITE request and its corresponding response. In early session model, if the originating UE initiates an MMTel session with an IMS data channel, the UE shall include the data channel media description in the SDP offer of the initial SIP INVITE, as specified in the clause 9.3.2.1.2.

Upon receiving the SIP requests and responses containing data channel SDP media descriptions, the CRS AS shall ignore them and just transmit them transparently.

The CAT service is an operator specific service specified in TS 24.182, which describes three models of CAT service as follows:

• forking model: it has no impact to IMS data channel.
• gateway model: it has no impact to IMS data channel.
• early session model: it has no impact to IMS data channel.

As specified in TS 24.182, the CAT media can consist of favourable songs, multi-media clips or other customized alerting tones.

When the originating UE is configured with IMS_DC_configuration node specified in TS 24.275 and the DC_Setup_Option leaf indicates that the IMS data channel is to be setup simultaneously while establishing an IMS session, the data channel media can be negotiated in the initial INVITE request and its corresponding response. In early session model, if the originating UE initiates MMTel session with an IMS data channel, the UE shall include the data channel media description in the SDP offer of initial SIP INVITE message, as specified in clause 9.3.2.1.2.

Upon receiving the SIP requests and responses containing data channel SDP media descriptions, the CAT AS shall ignore them and just transmit them transparently.

The explicit communication transfer (ECT) service provides a party involved in a communication to transfer that communication to a third party as defined in TS 24.629. There are three actors active in a transfer, they are acting in the following roles:

On reception of REFER message, if ECT has been triggered as defined in TS 24.629, the IMS AS serving the transferor:

• shall trigger the closing of all the established data channels on the transferor's network (including the data channel between the transferor's network and the transferor, the data channel between the transferor's network and the transferee, the data channel between transferor's network and the transfer target) as per procedures defined in clause 9.3.
• route the session setup INVITE request which includes audio, video and data channel media towards a REFER-TO user as defined in TS 24.629. The data channel media set up shall be performed between the transferee and the transfer target together with audio, video media negotiation as per procedures defined in clause 9.3.

If the transferee's network has established data channel media with the transferor before the transfer happens, the transferee's network shall update the data channel between transferor and transferee's network to the data channel between transfer target and transferee's network, on reception of the re-INVITE message with the SDP offer of the transfer target from the transferor's network during the session setup towards the transfer target.

In case of blind transfer, if the transfer target's network provides data channel service, on reception of incoming INVITE request from transferor's network, the transfer target's network shall send the INVITE message to transfer target. On reception of the 18x response or 200 (OK) response on the INVITE message from the transfer target, the transfer target's network shall trigger the reservation of the data channel media resources to establish the data channel for the transfer target and the transferee, together with audio, video media negotiation as per procedures defined in clause 9.3 and then sends the 18x response or 200 (OK) response to transferor's network. In case of consultative transfer, if the transfer target's network provides data channel service, on reception of incoming re-INVITE request with the SDP offer of transferee's network from transferor's network, the transfer target's network shall update the established data channel between transfer target's network and transferor to data channel between transfer target's network and transferee.

If the UE want to put some media stream on hold, then in addition to the application of procedures according to TS 24.610, the following procedures shall be applied at the invoking UE. The invoking UE shall include in the generated SDP offer as specified in TS 26.114:

1. for each data channel media that was previously active (i.e. the SDP direction attribute "a=sendrecv" was present in the last SDP body or no SDP direction attribute was included), the SDP direction attribute "a=inactive" associated with the corresponding "m=application" line if the invoking UE wants to suspend the data channel media;
2. for each data channel media that was previously suspended (i.e. the SDP direction attribute "a=inactive" was present in the last SDP body), the SDP direction attribute "a=sendrecv" associated with the corresponding "m=application" line (or to omit the SDP direction attribute) if the invoking UE wants to resume the suspended data channel media;

and as specified in TS 24.610, the invoking UE shall send the generated SDP offer in a re-INVITE request to the remote UE.

In addition to the application of procedures according to TS 24.610, the held UE shall generate an SDP answer for the held data channel media as specified as TS 26.114.