14 Interoperability of IMS Service Continuity over II-NNI

29.1653GPPInter-IMS Network to Network Interface (NNI)Release 18TS

14.1 General

In order to assure the end-to-end service interoperability through the Inter-IMS Network to Network Interface (II-NNI), the associated services of the IMS Service Continuity may be supported on the II-NNI between two IMS networks. The support of each service is based on agreement between operators.

If a service is supported, the related procedures from the 3GPP TS 24.237 [131] shall be applied with the requirements in the relevant clause below due to the crossing of the II-NNI.

14.2 PS to CS Single Radio Voice Call Continuity (SRVCC) and Single Radio Video Call Continuity (vSRVCC)

14.2.1 Basic PS to CS SRVCC

Service specific requirements in accordance with 3GPP TS 24.237 [131] shall be supported over the roaming II-NNI.

Media type "video" in SDP m-lines may be supported at the roaming II-NNI. Related SDP can appear in SDP offer answer exchanges within INVITE dialogues at the roaming II-NNI, and in responses to OPTIONS requests at the roaming II-NNI. If media type "video" is supported within INVITE dialogues at the roaming II-NNI, it shall also be supported within responses to OPTIONS requests at the roaming II-NNI.

The "+g.3gpp.srvcc" header field parameter (specified in 3GPP TS 24.237 [131] annex C) in the Feature-Caps header field of the INVITE request and in non-100 provisional responses or the 2xx response should be supported at the roaming II-NNI.

The Reason header field containing the protocol value set to "SIP" and "cause" header field parameter set to "487" in the re-INVITE request shall be supported at the roaming II-NNI.

The Reason header field containing the protocol value set to "SIP" and "cause" header field parameter set to "503" in the BYE request shall be supported at the roaming II-NNI.

Procedures as described in clause 14.4 are used to provide MSC server assisted mid-call features.

14.2.2 PS to CS SRVCC for calls in alerting phase

The requirements for the PS to CS transfer for alerting calls are the same as in clause 14.2.1 with the following additional requirements:

The "g.3gpp.srvcc-alerting" media feature tag (described in 3GPP TS 24.237 [131] annex C) in a Contact header field of the INVITE request and in non-100 provisional responses and the 2xx response to the INVITE request shall be supported at the roaming II-NNI.

The "+g.3gpp.srvcc-alerting" header field parameter (described in 3GPP TS 24.237 [131] annex C) included in a Feature-Caps header field as described in IETF RFC 6809 [143] in an INVITE request and in non-100 provisional responses and the 2xx response to the INVITE request or in the UPDATE request and in the 2xx response to the UPDATE request shall be supported at the roaming II-NNI.

The Target-Dialog header field in the INVITE request shall be supported at the roaming II-NNI.

An INFO request containing the Info-Package header field as specified in IETF RFC 6086 [39] with "3gpp.state-and-event" info package name and an "application/vnd.3gpp.state-and-event-info +xml" XML body shall be supported at the roaming II-NNI.

14.2.3 Using the ATCF based architecture

The requirements for the ATCF based architecture is the same as in clause 14.2.1 with the following additional requirements:

The "+g.3gpp.atcf", the "+g.3gpp.atcf-mgmt-uri" and the "+g.3gpp.atcf-path" header field parameters (specified in 3GPP TS 24.237 [131] annex C) in the Feature-Caps header field of the REGISTER request as described in IETF RFC 6809 [143] shall be supported at the roaming II-NNI.

A MESSAGE request containing the "application/vnd.3gpp.srvcc-info+xml" MIME body as defined in annex D of 3GPP TS 24.237 [131] shall be supported at the roaming II-NNI.

The URIs of SCC ASs authorised to provide PS to CS SRVCC information in the MESSAGE request need to be specified in the roaming agreement.

The Target-Dialog header field in the INVITE request shall be supported at the roaming II-NNI.

14.2.4 PS to CS SRVCC for originating calls in pre-alerting phase

The requirements for the PS to CS transfer for originating calls in pre-alerting phase are the same as in clause 14.2.1 and in clause 14.2.2 with the additional requirements in this clause.

NOTE: If PS to CS transfer for originating calls in pre-alerting phase is supported also PS to CS SRVCC for calls in alerting phase specified in clause 14.2.2 is supported.

The "g.3gpp.ps2cs-srvcc-orig-pre-alerting" media feature tag described in 3GPP TS 24.237 [131] annex C in a Contact header field of the REGISTER request and in the INVITE request shall be supported at the roaming II-NNI.

The "g.3gpp.ps2cs-srvcc-orig-pre-alerting" feature-capability indicator as described in 3GPP TS 24.237 [131] annex C in the Feature-Caps header field as described in IETF RFC 6809 [143] in non-100 provisional responses and the 2xx response to the INVITE request and in any target refresh request and in non-100 provisional responses or the 2xx response to target refresh request shall be supported at the roaming II-NNI.

14.2.5 PS to CS SRVCC with the MSC server assisted mid-call feature

The requirements for the PS to CS SRVCC with the assisted mid-call feature are the same as in clause 14.2.1 and in clause 14.4.

14.2.6 PS to CS SRVCC for terminating calls in pre-alerting phase

The requirements for the PS to CS transfer for terminating calls in pre-alerting phase are the same as in clause 14.2.1 and in clause 14.2.2 with the additional requirements in this clause.

NOTE: If PS to CS transfer for terminating calls in pre-alerting phase is supported also PS to CS SRVCC for calls in alerting phase specified in clause 14.2.2 is supported.

The "g.3gpp.ps2cs-srvcc-term-pre-alerting" media feature tag described in 3GPP TS 24.237 [131] annex C in a Contact header field of the REGISTER request and in the INVITE request shall be supported at the roaming II-NNI.

The g.3gpp.ps2cs-srvcc-term-pre-alerting feature-capability indicator as described in 3GPP TS 24.237 [131] annex C in the Feature-Caps header field as described in IETF RFC 6809 [143] in non-100 provisional responses and the 2xx response to the INVITE request and in any target refresh request and in non-100 provisional responses or the 2xx response to target refresh request shall be supported at the roaming II-NNI.

14.3 Inter UE Transfer (IUT)

IUT is described in clause 18.

14.4 MSC server assisted mid-call feature

Service specific requirements in accordance with 3GPP TS 24.237 [131] shall be supported over the roaming II-NNI.

The Contact header field of the REGISTER request and the 200 (OK) response containing "g.3gpp.mid-call" media feature tag as described in annex C of 3GPP TS 24.237 [131] shall be supported at the roaming II-NNI.

The Feature-Cap header field of the REGISTER request and the 200 (OK) response containing "+g.3gpp.mid-call" header field parameter specified in annex C of 3GPP TS 24.237 [131] shall be supported at the roaming II-NNI.

The media feature tag "g.3gpp.accesstype" in the Contact header field of the REGISTER request shall be supported at roaming II-NNI.

A Contact header field of the INVITE request and the 200 (OK) response containing the "g.3gpp.mid-call" media feature tag as described in annex C of 3GPP TS 24.237 [131] shall be supported at the roaming II-NNI.

The "g.3gpp.mid-call" feature-capability indicator according to 3GPP TS 24.237 [131] annex C included in the Feature-Caps header field of the INVITE request, in responses to the INVITE request and in any target refresh request and in non-100 provisional responses or the 2xx response to target refresh request shall be supported at the roaming II-NNI.

The Recv-Info header field containing the "g.3gpp.mid-call" package name in the INVITE request as specified in annex D of 3GPP TS 24.237 [131] shall be supported at the roaming II-NNI.

An Accept header field in the INVITE request containing the MIME type "application/vnd.3gpp.mid-call+xml" as specified in clause D.1 of 3GPP TS 24.237 [131] shall be supported at the roaming II-NNI.

The "application/vnd.3gpp.mid-call+xml" MIME body described in clause D.1.3 of 3GPP TS 24.237 [131] in the INVITE request shall be supported at the roaming II-NNI.

The SUBSCRIBE request containing a "g.3gpp.mid-call" media feature tag in the Contact header field shall be supported at the roaming II-NNI.

NOTE: The "g.3gpp.mid-call" media feature tag in the Contact header field of the SUBSCRIBE request may appear if the CONF supplementary service is supported at roaming II-NNI as described in clause 12.9.

An INFO request containing the Info-Package header field as specified in IETF RFC 6086 [39] with "3gpp.state-and-event" info package name and an "application/vnd.3gpp.state-and-event-info+xml" XML body shall be supported at the roaming II-NNI.

A REFER request sent inside an existing SIP dialog containing the "application/vnd.3gpp.mid-call+xml" MIME body specified in the clause D.1.3 of 3GPP TS 24.237 [131] shall be supported at the roaming II-NNI.

The Contact header field of the REFER request and the 2xx response to the request containing "g.3gpp.mid-call" media feature tag as described in annex C of 3GPP TS 24.237 [131] shall be supported at the roaming II-NNI.

The Target-Dialog header field in the INVITE request shall be supported at the roaming II-NNI.

The communication HOLD supplementary service as specified in clause 12.8 for the roaming II-NNI shall be supported.

The Allow-Event header field with "application/conference-info+xml" in an INVITE request shall be supported at the roaming II-NNI.

The Event header field containing the event package name "conference" and the Accept header field with "application/conference-info+xml" in a SUBSCRIBE request shall be supported at the roaming II-NNI.

The "application/conference-info+xml" MIME body and the Event header field containing the event package name "conference" in a NOTIFY request shall be supported at the roaming II-NNI.

The REFER request with the "method" header field parameter set to the value "BYE" sent in the Refer-To header field shall be supported at the roaming II-NNI.

14.5 CS to PS Single Radio Voice Call Continuity (SRVCC)

14.5.1 Basic CS to PS SRVCC

Service specific requirements in accordance with 3GPP TS 24.237 [131] shall be supported over the roaming II-NNI.

Requirements for the ATCF based architecture at II-NNI as described in clause 14.2.3 shall be supported at the roaming II-NNI.

Requirements for IMS Centralized Services (ICS) at II-NNI as described in clause 13 shall be supported at the roaming II-NNI.

The "g.3gpp.cs2ps-srvcc" and "g.3gpp.path" media feature tags in the Contact header field of the REGISTER request shall be supported at the roaming II-NNI.

The Feature-Caps header field with the "g.3gpp.cs2ps-srvcc" feature-capability indicator in the REGISTER request shall be supported at the roaming II-NNI.

The MESSAGE request containing the Accept-Contact header field with the "g.3gpp.path" media feature tag and the "application/vnd.3gpp.srvcc-ext+xml" MIME body shall be supported at the roaming II-NNI.

The URIs of SCC ASs authorised to provide CS to PS SRVCC information in the MESSAGE request need to be specified in the roaming agreement.

14.5.2 CS to PS SRVCC for calls in alerting phase

The requirements for the CS to PS SRVCC for calls in alerting phase are the same as in clause 14.5.1 with the following additional requirement:

The "g.3gpp.cs2ps-srvcc-alerting" media feature tag in the Contact header field of the REGISTER request shall be supported at the roaming II-NNI.

The REFER request sent inside an existing SIP dialog with the Refer-Sub header field and the "application/vnd.3gpp.state-and-event-info+xml" MIME body shall be supported at the roaming II-NNI.

The INFO request with the Info-Package header field containing the "g.3gpp.state-and-event" package name and the "application/vnd.3gpp.state-and-event-info+xml" MIME body shall be supported at the roaming II-NNI.

14.5.3 CS to PS SRVCC with the assisted mid-call feature

The requirements for the CS to PS SRVCC with the assisted mid-call feature are the same as in clause 14.5.1 with the following additional requirement:

The "application/vnd.3gpp.access-transfer-events+xml" MIME body in the REFER request shall be supported at the roaming II-NNI.

14.6 PS to CS dual radio voice call continuity (DRVCC)

14.6.1 Basic PS to CS DRVCC

Service specific requirements in accordance with 3GPP TS 24.237 [131] shall be supported over the roaming II-NNI.

The "g.3gpp.dynamic-stn" media feature tag according to 3GPP TS 24.237 [131] annex C included in the Contact header field of the INVITE request and in responses to the INVITE request shall be supported at the roaming II-NNI.

The "g.3gpp.dynamic-stn" feature-capability indicator according to 3GPP TS 24.237 [131] annex C included in the Feature-Caps header field of the INVITE request, in responses to the INVITE request and in any target refresh request and in non-100 provisional responses or the 2xx response to target refresh request shall be supported at the roaming II-NNI.

NOTE 1: The g.3gpp.dynamic-stn feature capability indicator from the home network contains an STN. The STN is a tel URI that the UE will use when establishing the call in CS. If the STN is known by the visited network the STN can also be used to identify that a call from a UE is a PS to CS dual radio access transfer allowing the visited network to suppress services and announcement that otherwise is executed during the CS call setup. The value of the tel URI STN needs to be communicated between operators when DRVCC is supported.

The requirements for providing IMS Centralized Services (ICS) as described in clause 13.2 should be supported at the roaming II-NNI.

NOTE 2: The support of IMS Centralized Services (ICS) as described in clause 13.2 is only needed if MSC servers in the visited network are enhanced for ICS.

14.6.2 PS to CS DRVCC with the assisted mid-call feature

The requirements for the PS to CS DRVCC with the assisted mid-call feature are the same as in clause 14.6.1 and in clause 14.4.

NOTE: Transfer of an additional call requires the use of IMS Centralized Services (ICS).

14.6.3 PS to CS DRVCC for calls in alerting phase

The requirements for the PS to CS DRVCC for calls in alerting phase are the same as in clause 14.6.1 with the additional requirements in this clause.

The "g.3gpp.drvcc-alerting" media feature tag according to 3GPP TS 24.237 [131] annex C and IETF RFC 3840 [56] included in the Contact header field of the INVITE request and in responses to the INVITE request shall be supported at the roaming II-NNI.

The "g.3gpp.drvcc-alerting" feature-capability indicator according to 3GPP TS 24.237 [131] annex C included in the Feature-Caps header field of the INVITE request, in responses to the INVITE request and in any target refresh request and in non-100 provisional responses or the 2xx response to target refresh request shall be supported at the roaming II-NNI.

A 488 (Not Acceptable Here) response to the INVITE request without an SDP body shall be supported at the roaming II-NNI.

14.6.4 PS to CS DRVCC for originating calls in pre-alerting phase

The requirements for the PS to CS DRVCC for originating calls in pre-alerting phase are the same as in clause 14.6.1 and in clause 14.6.3 with the additional requirements in this clause.

The "g.3gpp.ps2cs-drvcc-orig-pre-alerting" media feature tag according to 3GPP TS 24.237 [131] annex C and IETF RFC 3840 [56] in the Contact header field of the INVITE request shall be supported at the roaming II-NNI.

The "g.3gpp.ps2cs-drvcc-orig-pre-alerting" feature-capability indicator according to 3GPP TS 24.237 [131] annex C included in the Feature-Caps header field of the INVITE request, in responses to the INVITE request and in any target refresh request and in non-100 provisional responses or the 2xx response to target refresh request shall be supported at the roaming II-NNI.

14.7 CS to PS Dual Radio Voice Call Continuity (DRVCC)

14.7.1 Basic CS to PS DRVCC

Service specific requirements in accordance with 3GPP TS 24.237 [131] shall be supported over the roaming II-NNI.

The requirements for providing IMS Centralized Services (ICS) as described in clause 13.2 should be supported at the roaming II-NNI.

NOTE: The support of IMS Centralized Services (ICS) as described in clause 13.2 is only needed if MSC servers in the visited network are enhanced for ICS.

14.7.2 CS to PS DRVCC with the assisted mid-call feature

The requirements for the PS to CS DRVCC with the assisted mid-call feature are the same as in clause 14.7.1 and in clause 14.4.

14.7.3 CS to PS DRVCC for calls in alerting phase

The requirements for the CS to PS DRVCC for calls in alerting phase are the same as in clause 14.7.1 with the additional requirements in this clause.

The "g.3gpp.cs2ps-drvcc-alerting" media feature tag as described included in the Contact header field of the INVITE request and in responses to the INVITE request shall be supported at the roaming II-NNI.

The "g.3gpp.cs2ps-drvcc-alerting" feature-capability indicator according to 3GPP TS 24.237 [131] annex C included in the Feature-Caps header field of the INVITE request, in responses to the INVITE request and in any target refresh request and in non-100 provisional responses or the 2xx response to target refresh request shall be supported at the roaming II-NNI.

A 488 (Not Acceptable Here) response to the INVITE request without an SDP body shall be supported at the roaming II-NNI.

14.7.4 CS to PS DRVCC for originating calls in pre-alerting phase

The requirements for the CS to PS DRVCC for originating calls in pre-alerting phase are the same as in clause 14.7.1 and in clause 14.7.3 with the following additional requirements:

The "g.3gpp.cs2ps-drvcc-orig-pre-alerting" media feature tag according to 3GPP TS 24.237 [131] annex C and IETF RFC 3840 [56] in the Contact header field of the INVITE request shall be supported at the roaming II-NNI.

The "g.3gpp.cs2ps-drvcc-orig-pre-alerting" feature-capability indicator according to 3GPP TS 24.237 [131] annex C included in the Feature-Caps header field of the INVITE request, in responses to the INVITE request and in any target refresh request and in non-100 provisional responses or the 2xx response to target refresh request shall be supported at the roaming II-NNI.

14.8 PS to PS access transfer

Service specific requirements in accordance with 3GPP TS 24.237 [131] clause 10 shall be supported over the roaming II-NNI.

The "g.3gpp.pstops-sti" media feature tag in the Contact header field of the REGISTER request shall be supported at the roaming II-NNI.

The INVITE request containing:

a) the "g.3gpp.ics" media feature tag; and

b) either:

– the Replaces header field and the option tag value "replaces" in the Require header field; or

– the Target-Dialog header field and the option tag value "tdialog" in the Require header field,

shall be supported at the roaming II-NNI.

A Recv-Info header field containing the "g.3gpp.state-and-event" info package name in the 183 (Session Progress) response shall be supported at the roaming II-NNI.

The INFO request containing the Info-Package header field as specified in IETF RFC 6086 [39] with the "g.3gpp.state-and-event" info package name and the "application/vnd.3gpp.state-and-event-info+xml" XML body shall be supported at the roaming II-NNI.