12 Supplementary services associated with the IMS multimedia telephony communication service

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

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

12.1 General

In order to assure the end-to-end service interoperability through the Inter-IMS Network to Network Interface (II-NNI), the associated supplementary services of the multimedia telephony communication service may be supported on the II-NNI between the two IMS networks.

The MMTEL communication service is identified by means of the "urn:urn-7:3gpp-service.ims.icsi.mmtel" URN. The "urn:urn-7:3gpp-service.ims.icsi.mmtel" can appear in:

– the media feature tag "g.3gpp.icsi-ref" (specified in 3GPP TS 24.229 [5] clause 7.2A.8) in the Contact header field and the Accept-Contact header field;

– the feature-capability indicator "g.3gpp.icsi-ref" (specified in 3GPP TS 24.229 [5] clause 7.9A.2) in the Feature-Caps header field; and

– the P-Asserted-Service header field.

The support of each associated supplementary service is based on agreement between operators.

If a supplementary service is supported, the related procedures from the 3GPP TS 22.173 [30], the protocol details from the 3GPP TS 24.173 [31] and specifications referenced in the 3GPP TS 24.173 [31] shall be applied with the requirements in the relevant clause below due to the crossing of the II-NNI.

A classification of the importance of supplementary services applicable over the II-NNI is available in the informative annex Db of 3GPP TS 22.173 [30].

NOTE: Agreeing on interworking of entire class of services according to this classification can simplify the cooperation between interconnecting networks but remains optional.

12.2 Malicious Communication IDentification (MCID)

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

The P-Asserted-Identity header field shall be supported at the II-NNI.

The INFO request and the 200 (OK) response to the INFO request containing the "application/vnd.etsi.mcid+xml" MIME body defined in 3GPP TS 24.616 [33] may be supported at the II-NNI.

If a network terminating the dialog supports MCID, the terminating network shall only deliver the MCID request in the "application/vnd.etsi.mcid+xml" MIME body, as specified in the 3GPP TS 24.616 [33], if an agreement to use the MCID supplementary service according to the 3GPP TS 24.616 [33] exists with the network originating the dialog and if the INVITE request received by the terminating network does not contain the information of the originating party.

NOTE: The IBCF and the AS in the terminating network interact to deliver the MCID request only if an agreement to use the MCID supplementary service exists, as specified in 3GPP TS 24.616 [33] and 3GPP TS 24.229 [5].

The originating network and the terminating network shall have a bilateral agreement to support transportation of the minimum information specified in clause 4.5.2.5.0 of the 3GPP TS 24.616 [33] between the networks.

12.3 Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR)

Service specific requirements in accordance with 3GPP TS 24.607 [32] and 3GPP TS 24.229 [5] shall be supported over the II-NNI.

The P-Asserted-Identity header field and the Privacy header field with values "id", "user", "none", "header" and "critical" shall be supported at the II-NNI.

NOTE 1: P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields will impact the intended end-to-end operation between the end users. Where a trust relationship exists on the P-Asserted-Identity header field between the two IMS networks, this header field cannot be altered when passing through the II-NNI according to 3GPP TS 24.229 [5]. Where no trust relationship exists on the P-Asserted-Identity header field between the two IMS networks, the IBCF determines whether to remove the P-Asserted-Identity header field according to procedures described in 3GPP TS 24.229 [5] clause 4.4.2 referencing IETF RFC 3325 [44] and local policy rules for using additional screening capabilities as defined in 3GPP TS 24.229 [5] clause 5.10.6.

NOTE 2: Where a trust relationship exists with the remote domain the From header field will be passed transparently by the IBCF. If a SIP request is received by the terminating network and the application of the OIR service is required with the value "user" for the Privacy header field then the From header field will be anonymised in accordance with IETF RFC 3323 [34] by the terminating network. Where no trust relationship exists with the remote domain, the From header field can be, based on local policy rules, anonymised by the IBCF of the originating network prior passing through the II-NNI using screening capabilities defined in 3GPP TS 24.229 [5] clause 5.10.6 and clause 5.10.8.

NOTE 3: The privacy level "session" and "critical" are not used in the OIP/OIR service as described in 3GPP TS 24.607 [32].

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.4 Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR)

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

The P-Asserted-Identity header field and the Privacy header field with values "id", "user", "none", "header" and "critical" shall be supported at the II-NNI.

NOTE: P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields will impact the intended end-to-end operation between the end users. Where a trust relationship exists on the P-Asserted-Identity header field between the two IMS networks, this header field will be passed transparently through the II-NNI according to 3GPP TS 24.229 [5]. Where no trust relationship exists on the P-Asserted-Identity header field between the two IMS networks, the IBCF determines whether to remove the P-Asserted-Identity header field according to procedures described in 3GPP TS 24.229 [5] clause 4.4.2, referencing IETF RFC 3325 [44] and local policy rules for using additional screening capabilities as defined in 3GPP TS 24.229 [5] clause 5.10.6.

The option tag "from-change" defined in IETF RFC 4916 [158], in the Supported header field should be supported at II-NNI.

12.5 Anonymous Communication Rejection (ACR)

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

The P-Asserted-Identity header field and the Privacy header field shall be supported at the II-NNI.

Procedures as described in clause 12.21.4 are used to provide announcements.

The response code 433 (Anonymity Disallowed) shall be supported at the II-NNI.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.6 Communication DIVersion (CDIV)

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

NOTE 1: The support of the Diversion header field not adopted in 3GPP TS 24.604 [117] requires bilateral agreement between the operators.

Procedures as described in clause 12.21.2 are used to provide announcements.

The Privacy header field with a priv-value set to "history" included in the hi-targeted-to-uri or as a standalone header field shall be supported at the II-NNI.

The History-Info header field as described by 3GPP TS 24.604 [117] containing an "mp" header field parameter as defined by IETF RFC 7044 [25] and a "cause" SIP URI parameter with cause values as defined by the IETF RFC 4458 [58] shall be supported over the II-NNI.

NOTE 2: The networks can have an internal limit in the number of allowed diversions, as described in 3GPP TS 24.604 [117], clause 4.5.2.6.1. To ensure efficiency of this control operators can indicate in their bilateral agreements their own number of allowed communication diversions, the parameter that is used for counting, and the network behavior when the internal limit is reached.

The response code 181 (Call Is Being Forwarded) shall be supported at the II-NNI.

The MESSAGE request procedure for indication of communication diversion to the diverting user as specified in 3GPP TS 24.604 [117] and 3GPP TS 24.229 [5] should be supported at the roaming II-NNI.

NOTE 3: The content of the MESSAGE request is operator specific.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.7 Communication Waiting (CW)

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

The "application/vnd.3gpp.cw+xml" MIME body defined in 3GPP TS 24.615 [37] in the INVITE request shall be supported at the roaming II-NNI.

The Alert-Info header field set to "urn:alert:service:call-waiting" in a 180 (Ringing) response shall be supported at the II-NNI.

As a network option, in case of expiry of the CW timer, the response code 480 (Temporarily Unavailable) including a Reason header field containing the protocol value "Q.850" and the "cause" header field parameter set to "19" shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

Procedures as described in clause 12.21.2 are used to provide announcements.

12.8 Communication HOLD (HOLD)

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

NOTE: The support of an alternative method not adopted in 3GPP TS 24.610 [36] requires bilateral agreement between the operators and is outside the scope of the present document.

Procedures as described in clause 12.21.3 are used to provide announcements.

12.9 Message Waiting Indication (MWI)

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

The event package name "message-summary" in the Event header field according to IETF RFC 6665 [20] and 3GPP TS 24.229 [5] in the SUBSCRIBE request shall be supported at the roaming II-NNI.

The "application/simple-message-summary" MIME body described in 3GPP TS 24.606 [112] in the NOTIFY request shall be supported at the roaming II-NNI.

12.10 Communication Barring (CB)

12.10.1 Incoming Communication Barring (ICB)

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

Procedures as described in clause 12.21.4 are used to provide announcements.

The response code 603 (Decline) including a Reason header field containing the protocol value set to "SIP" and the "cause" header field parameter set to value "603" as described in 3GPP TS 24.611 [114] shall be supported at the II-NNI.

A Reason header field containing the protocol value set to "SIP" and the "cause" header field parameter set to value "603" as described in 3GPP TS 24.611 [114] included in the BYE request shall be supported at the II-NNI.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

If the option IIFC (Inhibition of Incoming Forwarded Calls) is supported the transparency of information related to communication diversion (see clause 12.6) shall be supported at II-NNI.

12.10.2 Outgoing Communication Barring (OCB)

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

Procedures as described in clause 12.21.4 are used to provide announcements.

The response code 603 (Decline) including a Reason header field containing the protocol value set to "SIP" and the "cause" header field parameter set to "603" as described in 3GPP TS 24.611 [114] shall be supported at the roaming II-NNI.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.11 Completion of Communications to Busy Subscriber (CCBS)

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

The response code 486 (Busy Here) containing a Call-Info header field with a "purpose" header field parameter set to "call-completion" and the "m" parameter set to "BS" shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

For invoking and revoking of the CCBS supplementary service, announcement procedures shall be used to provide announcements and inband-interaction procedures as described in clause 12.21.3 and clause 12.21.4 shall be supported at the roaming II-NNI.

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI.

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 [5] shall be supported at the roaming II-NNI.

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [38] should be supported at the roaming II-NNI.

NOTE 1: 3^rd party call control procedures can be used when the REFER request is not supported at the II-NNI.

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5].

The SUBSCRIBE and NOTIFY methods according to IETF RFC 6665 [20] and 3GPP TS 24.229 [5] containing the event package name "call-completion" in the Event header field and the Call-Info header field with a purpose parameter set to ‘call-completion’ and the m parameter set to "BS" shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

The NOTIFY request containing the "application/call-completion" MIME body as defined in IETF RFC 6910 [208] shall be supported at the non-roaming II-NNI.

The Request-URI with the "m" SIP URI parameter with a value set to "BS" and the Call-Info header field with a purpose parameter set to ‘call-completion’ and the "m" parameter set to "BS" in the INVITE method shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

The Date header field in the 486 (Busy Here) response to the INVITE request shall be supported at the roaming II-NNI.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.12 Completion of Communications by No Reply (CCNR)

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

The response code 180 (Ringing) containing a Call-Info header field with a purpose parameter set to ‘call-completion’ and the "m" parameter set to "NR" shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

For invoking and revoking of the CCNR supplementary service, announcement procedures shall be used to provide announcements and inband-interaction procedures as described in clause 12.21.3 and clause 12.21.4 shall be supported at the roaming II-NNI.

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI.

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [38] should be supported at the roaming II-NNI.

NOTE 1: 3^rd party call control procedures can be used when the REFER request is not supported at the II-NNI.

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5].

The SUBSCRIBE and NOTIFY methods according to IETF RFC 6665 [20] and 3GPP TS 24.229 [5] containing the event package name "call-completion" in the Event header field and the Call-Info header field with a purpose parameter set to ‘call-completion’ and the m parameter set to "NR" shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

The NOTIFY request containing the "application/call-completion" MIME body as defined in IETF RFC 6910 [208] shall be supported at the non-roaming II-NNI.

The Request-URI with the "m" SIP URI parameter with a value set to "NR" and the Call-Info header field with a purpose parameter set to ‘call-completion’ and the "m" parameter set to "NR" in the INVITE method shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

The Date header field in the 480 (Temporarily Unavailable) response to the INVITE request shall be supported at the roaming II-NNI.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.13 Explicit Communication Transfer (ECT)

12.13.1 Consultative and blind transfer

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

The REFER method, the Referred-By header field and the Replaces header field as specified in 3GPP TS 24.629 [116] and the NOTIFY method containing an "application/sipfrag" MIME body shall be supported at the II-NNI for call transfer without third party call control.

The REFER method, the Referred-By header field and the Replaces header field as specified in 3GPP TS 24.629 [116] and the NOTIFY method containing an "application/sipfrag" MIME body shall be supported at the roaming II-NNI for call transfer with third party call control.

The Refer-To URI header parameter in the REFER request containing the Require header field set to "replaces" shall be supported at the roaming II-NNI.

The Replaces header field in the INVITE request shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

12.13.2 Assured transfer

The requirements for the assured transfer are the same as in clause 12.13.1 with the additional requirements in this clause.

An Expires header field parameter in the Refer-To URI of the REFER Request shall be supported at the II-NNI for call transfer without third party call control.

An Expires header field parameter in the Refer-To URI of the REFER Request shall be supported at the roaming II-NNI for call transfer with third party call control.

The Refer-To header field in the REFER request containing the method parameter set to "CANCEL" shall be supported at the II-NNI for call transfer without third party call control.

The Refer-To header field in the REFER request containing the method parameter set to "CANCEL" shall be supported at the roaming II-NNI with third party call control.

12.14 Customized Alerting Tone (CAT)

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

The P-Early-Media header field as described in 3GPP TS 24.182 [129] shall be supported at the II-NNI.

The response code 180 (Ringing) and the response code 183 (Session Progress) including a P-Early-Media header field shall be supported over the II-NNI.

The response code 199 (Early Dialog Terminated) shall be supported over the II-NNI.

The Supported header field and the Require header field with "early-session" option-tag shall be supported at the II-NNI, if the early session model is supported.

An "application/sdp" MIME body with the Content-Disposition header field set to "early-session" as specified in IETF RFC 3959 [96] shall be supported at II-NNI, if the early session model is supported.

A SDP "a=content" attribute with a "g.3gpp.cat" value in the 18x responses shall be supported at the II-NNI.

The SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [5] may be supported at the roaming II-NNI.

NOTE 1: For telephone-event based DTMF transport, the DTMF digits are sent as media and not visible in the control plane.

NOTE 2: Multiple methods for DTMF transport are defined in 3GPP TS 24.182 [129].

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.15 Customized Ringing Signal (CRS)

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

An Alert-Info header field in the initial INVITE request containing an URI followed by a URN "urn:alert:service:crs" shall be supported at the II-NNI.

An "application/vnd.3gpp.crs+xml" MIME body in the initial INVITE request shall be supported at the II-NNI.

A SDP "a=content" attribute with a "g.3gpp.crs" value in the PRACK request or the re-INVITE request may be supported at the II-NNI.

The Supported header field and the Require header field with "early-session" option-tag may be supported at the II-NNI.

An "application/sdp" MIME body with the Content-Disposition header field set to "early-session" as specified in IETF RFC 3959 [96] may be supported at II-NNI.

The SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [5] may be supported at the II-NNI.

NOTE: For telephone-event based DTMF transport, the DTMF digits are sent as media and not visible in the control plane.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.16 Closed User Group (CUG)

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

The "application/vnd.etsi.cug+xml" MIME body as specified 3GPP TS 24.654 [103] shall be supported in INVITE requests at the II-NNI.

NOTE: If no agreement between the originating network and the terminating network exists to support the CUG supplementary service the INVITE request is rejected as described in IETF RFC 5621 [89] when the "handling" parameter in the Content-Disposition header field of the " application/vnd.etsi.cug+xml" MIME body is set to "required".

The 403 (Forbidden) response, the 603 (Decline) response and the 500 (Server Internal Error) response shall be supported at II-NNI.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.17 Personal Network Management (PNM)

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

A "g.3gpp.iari_ref" feature tag with the value "urn:urn-7:3gpp-application.ims.iari.pnm-controller" in the Contact header field of the REGISTER request shall be supported at the roaming II-NNI.

A "g.3gpp.iari_ref" feature tag with the value "urn:urn-7:3gpp-application.ims.iari.pnm-controller" in the Accept-Contact header field shall be supported at the II-NNI.

The History-Info header field shall be supported at II-NNI.

A "histinfo" option tag as described by 3GPP TS 24.259 [99] in the Supported header field shall be supported at II-NNI.

12.18 Three-Party (3PTY)

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

NOTE 1: The requirements below can be relaxed by bilateral agreements between operators.

The requirements for the 3PTY supplementary service are the same as for the CONF supplementary service specified in clause 12.19 with the following additional requirement:

– If a REFER request is supported at the II-NNI, a Replaces header field in the header portion of the SIP URI of the Refer-to header field of the REFER request shall also be supported at II-NNI.

NOTE 2: Clause 12.19 describes the conditions for the support of the REFER request.

12.19 Conference (CONF)

Service specific requirements in accordance with 3GPP TS 24.605 [105] and 3GPP TS 24.147 [106] shall be supported over the II-NNI.

NOTE 1: The requirements below can be relaxed by bilateral agreements between operators.

The REFER request shall be supported at the roaming II-NNI in the direction from visited to home network. Based on inter-operator agreement, the REFER request may be supported at the non-roaming II-NNI, for the loopback traversal scenario, and at the roaming II-NNI in the direction from home network to visited network.

NOTE 2: If the REFER request is not supported at the non-roaming II-NNI, for the loopback traversal scenario, or at the roaming II-NNI in the direction from home network to visited network, an attempt of an UE to send the REFER directly to peers to invite them to a conference without involvement of the conference focus can fail over such an II-NNI. However such failures can also occur if a peer is located in a circuit switched network, or if a peer does not support the REFER method. An operator can avoid such failures by configuring an AS to convert the REFER to an INVITE, as detailed in 3GPP TS 24.628 [38]. Information on security risks associated with the REFER request is provided within the "security consideration" of IETF RFC 3515 [22].

NOTE 3: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5].

The "application/resource-lists+xml" MIME body in the INVITE request shall be supported at the roaming II-NNI.

The Referred-By header field in the INVITE request shall be supported at the II-NNI.

The "isfocus" feature parameter indicated in Contact header field of the INVITE request and in the 200 (OK) response shall be supported at the II-NNI.

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

The NOTIFY request including an "application/conference-info+xml" MIME body shall be supported at the II-NNI.

NOTE 4: The subscription to "conference event" package does not apply at the roaming II-NNI between the MSC Server enhanced for ICS/MSC Server enhanced for SRVCC/MSC server enhanced for dual radio and the IMS network where the communication is anchored.

The Allow-Events header field in the INVITE request with the value "conference" shall be supported at the roaming II-NNI and may be supported at the non-roaming II-NNI and for the loopback traversal scenario.

12.20 Flexible Alerting (FA)

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

The 486 (Busy Here) response code shall be supported at the II-NNI.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.21 Announcements

12.21.1 General

Announcements may be provided during the establishment of a communication session, during an established communication session or when a communication request is rejected. All of them shall be managed over the II-NNI.

12.21.2 Providing announcements during the establishment of a communication session

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements during the establishment of a communication session.

There are two methods defined in 3GPP TS 24.628 [38] to provide the announcement:

1) sending an announcement as an early media; and

NOTE 1: There are two methods to use early media for sending the announcement in-band. First method is the gateway model defined by IETF RFC 3960 [150] and 3GPP TS 24.628 [38] annex G, second method is described in 3GPP TS 24.628 [38] annex D.

2) sending an Alert-Info header field in 180 (Ringing) response to the INVITE request.

The P-Early-Media header field authorizing early media as defined in IETF RFC 5009 [74] during the establishment of a communication shall be supported at the II-NNI.

The Alert-Info header field in the 180 (Ringing) response to the INVITE request during the establishment of a communication, should be supported at the II-NNI.

NOTE 2: The IBCF can decide to remove the Alert-Info header field if required by local policy.

12.21.3 Providing announcements during an established communication session

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements during an established communication session.

In case of provision of an announcement to a user over the II-NNI during an established communication, the Call-Info header field in a re-INVITE request should be supported at the II-NNI.

NOTE 1: An alternative method to provide announcements is to use the existing media stream.

NOTE 2: The IBCF can decide to remove the Call-Info header field if required by local policy.

12.21.4 Providing announcements when communication request is rejected

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements when a communication request is rejected.

There are three methods defined in3GPP TS 24.628 [38] to provide the announcement:

1) sending an announcement as an early media;

2) sending an Error-Info header field in the 3xx, 4xx, 5xx or 6xx response to the INVITE request; and

3) accept the communication request and then provide the announcement.

NOTE 2: The II-NNI requirements for accepting the communication request and then provide the announcement is not within the scope of this clause.

The P-Early-Media header field authorizing early media as defined in IETF RFC 5009 [74] and the Reason header field with the proper cause value shall be supported at the II-NNI.

The Error-Info header field in the 3xx, 4xx, 5xx or 6xx response to the INVITE request when rejecting the communication request, should be supported at the II-NNI.

NOTE 3: The IBCF can decide to remove the Error-Info header field if required by local policy.

12.22 Advice Of Charge (AOC)

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

The Accept header field with "application/vnd.etsi.aoc+xml" shall be supported at the roaming II-NNI.

The INVITE method containing an "application/vnd.etsi.aoc+xml" MIME body shall be supported at the roaming II-NNI.

Non-100 provisional responses and the 200 (OK) response to the initial INVITE request containing an "application/vnd.etsi.aoc+xml" MIME body shall be supported at the roaming II-NNI.

The INFO method containing an "application/vnd.etsi.aoc+xml" MIME body shall be supported at the roaming II-NNI.

The response code 504 (Server Time-out) shall be supported at the II-NNI.

A Reason header field containing the protocol value set to "SIP" and the "cause" header field parameter set to "504" or containing the protocol value set to "Q.850" and the "cause" header field parameter set to "31" in the BYE method shall be supported at the II-NNI.

An "application/vnd.etsi.aoc+xml" MIME body in the BYE request or the final response to the BYE request shall be supported over the roaming II-NNI.

12.23 Completion of Communications on Not Logged-in (CCNL)

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

The response code 480 (Temporarily unavailable) containing a Call-Info header field with a purpose parameter set to ‘call-completion’ and the "m" parameter set to "NL" shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

For invoking and revoking of the CCNL supplementary service, announcement procedures shall be used to provide announcements and inband-interaction procedures as described in clause 12.21.3 and clause 12.21.4 shall be supported at the roaming II-NNI.

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI.

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [38] should be supported at the roaming II-NNI.

NOTE: 3^rd party call control procedures can be used when the REFER request is not supported at the II-NNI.

The SUBSCRIBE and NOTIFY methods according to IETF RFC 6665 [20] and 3GPP TS 24.229 [5] containing the event package name "call-completion" in the Event header field and the Call-Info header field with a purpose parameter set to ‘call-completion’ and the "m" parameter set to "NL" shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

The NOTIFY request containing the "application/call-completion" MIME body as defined in IETF RFC 6910 [208] shall be supported at the non-roaming II-NNI.

The Request-URI with the "m" SIP URI parameter with a value set to "NL" and the Call-Info header field with a purpose parameter set to ‘call-completion’ and the "m" parameter set to "NL" in the INVITE method shall be supported at the non-roaming II-NNI and for the loopback traversal scenario.

The Date header field in the 480 (Temporarily Unavailable) response to the INVITE request shall be supported at the roaming II-NNI.

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI.

12.24 Unstructured Supplementary Service Data (USSD)

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

The Recv-Info header field containing the "g.3gpp.ussd" info package name and the "application/vnd.3gpp.ussd" MIME body as described in annex B of 3GPP TS 24.390 [163] in the INVTE request shall be supported at the roaming II-NNI.

The Recv-Info header field containing the "g.3gpp.ussd" info package name in the 200 (OK) response to the INVITE request shall be supported at the roaming II-NNI.

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

The "application/vnd.3gpp.ussd" MIME body in the BYE request shall be supported at the roaming II-NNI.

12.25 Enhanced Calling Name (eCNAM)

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

An initial INVITE request with:

– a display‑name in a From header field;

– a display‑name in a P-Asserted-Identity header field; and

– Call-Info header field(s),

shall be supported at the roaming II-NNI in the direction from home to visited network.

12.26 Multi-Device and Multi-Identity (MuD and MiD)

12.26.1 Multi-Device (MuD)

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

NOTE: No specific SIP signalling requirements exist for MuD over the II-NNI.

12.26.2 Multi-Identity (MiD)

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

An initial INVITE request, a REFER request and a MESSAGE request with an Additional-Identity header field (as defined in 3GPP TS 24.229 [5] clause 7.2.20) shall be supported over the roaming II-NNI.