4 General

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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

4.1 Conformance of IM CN subsystem entities to SIP, SDP and other protocols

SIP defines a number of roles which entities can implement in order to support capabilities. These roles are defined in annex A.

Each IM CN subsystem functional entity using an interface at the Gm reference point, the Ma reference point, the Mg reference point, the Mi reference point, the Mj reference point, the Mk reference point, the Ml reference point, the Mm reference point, the Mr reference point, the Mr’ reference point, the Cr reference point, the Mw reference point, the I2 reference point, the I4 reference point and the Ici reference point, and also using the IP multimedia Subsystem Service Control (ISC) Interface, shall implement SIP, as defined by the referenced specifications in Annex A, and in accordance with the constraints and provisions specified in annex A, according to the following roles.

Each IM CN subsystem entity using an interface at the Rc reference point and the Ms reference point shall implement HTTP as defined in RFC 7230 [280], RFC 7231 [281], RFC 7232 [282], RFC 7233 [283], RFC 7234 [284] and RFC 7235 [285].

Each IM CN subsystem entity using an interface at the W2 reference point may implement SIP as an option. The detailed procedures of W2 interface are defined in 3GPP TS 24.371 [8Z].

The Gm reference point, the W2 reference point, the Ma reference point, the Mg reference point, the Mi reference point, the Mj reference point, the Mk reference point, the Ml reference point, the Mm reference point, the Mr reference point, the Mw reference point, the Cr reference point, the I2 reference point, the I4 reference point and the ISC reference point are defined in 3GPP TS 23.002 [2]. The Ici reference point and the Ms reference point are defined in 3GPP TS 23.228 [7]. The Mr’ reference point and the Rc reference point are defined in 3GPP TS 23.218 [5].

For SIP:

– The User Equipment (UE) shall provide the User Agent (UA) role, with the exceptions and additional capabilities to SIP as described in subclause 5.1, with the exceptions and additional capabilities to SDP as described in subclause 6.1, and with the exceptions and additional capabilities to SigComp as described in subclause 8.1. The UE shall also provide the access technology specific procedures described in the appropriate access technology specific annex (see subclause 3A and subclause 9.2.2). The UE may include one or several interconnected SIP elements registered as a single logical entity when the UE performs the functions of an external attached network (e.g. an enterprise network). This specification does not place any constraint on the SIP role played by each of the elements as long as the compound entity appears to the IM CM subsystem as a SIP UA with the aforementioned exceptions and additional capabilities except for the modifications defined by the UE performing the functions of an external attached network modifying role in annex A.

NOTE 1: When the UE performs the functions of an external attached network (e.g. an enterprise network), the internal structure of this UE is outside the scope of this specification. It is expected that in the most common case, several SIP elements will be connected to an additional element directly attached to the IM CN subsystem.

– The P-CSCF shall provide the proxy role, with the exceptions and additional capabilities to SIP as described in subclause 5.2, with the exceptions and additional capabilities to SDP as described in subclause 6.2, and with the exceptions and additional capabilities to SigComp as described in subclause 8.2. Under certain circumstances, if the P-CSCF provides an application level gateway functionality (IMS-ALG), the P-CSCF shall provide the UA role with the additional capabilities, as follows:

a) when acting as a subscriber to or the recipient of event information (see subclause 5.2);

b) when performing P-CSCF initiated dialog-release, even when acting as a proxy for the remainder of the dialog (see subclause 5.2);

c) when performing NAT traversal procedures (see subclause 6.7.2);

d) when performing media plane security procedures (see subclause 5.2); and

e) when providing in-call access update procedures (see subclause 5.2.14).

The P-CSCF shall also provide the access technology specific procedures described in the appropriate access technology specific annex (see subclause 3A and subclause 9.2.2).

– The I-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in subclause 5.3.

– The S-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in subclause 5.4, and with the exceptions and additional capabilities to SDP as described in subclause 6.3. Under certain circumstances as described in subclause 5.4, the S-CSCF shall provide the UA role with the additional capabilities, as follows:

a) the S-CSCF shall also act as a registrar. When acting as a registrar, or for the purposes of executing a third-party registration, the S-CSCF shall provide the UA role;

b) as the notifier of event information the S-CSCF shall provide the UA role;

c) when providing a messaging mechanism by sending the MESSAGE method, the S-CSCF shall provide the UA role; and

d) when performing S-CSCF initiated dialog release the S-CSCF shall provide the UA role, even when acting as a proxy for the remainder of the dialog.

– The MGCF shall provide the UA role, with the exceptions and additional capabilities as described in subclause 5.5, and with the exceptions and additional capabilities to SDP as described in subclause 6.4.

– The BGCF shall provide the proxy role, with the exceptions and additional capabilities as described in subclause 5.6.

– The AS, acting as terminating UA, or redirect server (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.1), shall provide the UA role, with the exceptions and additional capabilities as described in subclause 5.7.2, and with the exceptions and additional capabilities to SDP as described in subclause 6.6.

– The AS, acting as originating UA (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.2), shall provide the UA role, with the exceptions and additional capabilities as described in subclause 5.7.3, and with the exceptions and additional capabilities to SDP as described in subclause 6.6.

– The AS, acting as a SIP proxy (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.3), shall provide the proxy role, with the exceptions and additional capabilities as described in subclause 5.7.4.

– The AS, performing 3rd party call control (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.4), shall provide the UA role, with the exceptions and additional capabilities as described in subclause 5.7.5, and with the exceptions and additional capabilities to SDP as described in subclause 6.6. An AS performing media control of an MRFC shall also support the procedures and methods described in subclause 10.2.

NOTE 2: Subclause 5.7 and its subclauses define only the requirements on the AS that relate to SIP. Other requirements are defined in 3GPP TS 23.218 [5].

– The AS, receiving third-party registration requests, shall provide the UA role, with the exceptions and additional capabilities as described in subclause 5.7.

– The MRFC shall provide the UA role, with the exceptions and additional capabilities as described in subclause 5.8, and with the exceptions and additional capabilities to SDP as described in subclause 6.5. The MRFC shall also support the procedures and methods described in subclause 10.3 for media control.

– In inline aware mode, the MRB shall provide the UA role, with the exceptions and additional capabilities as described in subclause 5.8A. In inline unaware mode, the MRB shall provide the proxy role, with the exceptions and additional capabilities as described in subclause 5.8A. The MRB shall also support the procedures and methods described in subclause 10.4 for media control.

– The IBCF shall provide the proxy role, with the exceptions and additional capabilities to SIP as described in subclause 5.10. If the IBCF provides an application level gateway functionality (IMS-ALG), then the IBCF shall provide the UA role, with the exceptions and additional capabilities to SIP as described in subclause 5.10, and with the exceptions and additional capabilities to SDP as described in subclause 6.7. If the IBCF provides screening functionality, then the IBCF may provide the UA role, with the exceptions and additional capabilities to SIP as described in subclause 5.10.

– The E-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in subclause 5.11. Under certain circumstances as described in subclause 5.11, the E-CSCF shall provide the UA role in accordance with RFC 3323 [33], with the additional capabilities, as follows:

a) when operator policy (e.g. determined by national regulatory requirements applicable to emergency services) allows user requests for suppression of public user identifiers and location information, then the E-CSCF shall provide the UA role, with the exceptions and additional capabilities to SIP as described in subclause 5.11;

b) when performing E-CSCF initiated dialog release the E-CSCF shall provide the UA role, even when acting as a proxy for the remainder of the dialog, e.g. for any of the reasons specified in RFC 6442 [89] or RFC 3323 [33];

c) when acting as a notifier for the dialog event package the E-CSCF shall provide the UA role; and

d) if operator policy allows any LRF to provide a location by value using the mechanism defined in subclause 5.11.3. the E-CSCF shall provide the UA role.

– The LRF shall provide the UA role.

– The ISC gateway function shall provide the proxy role, with the exceptions and additional capabilities to SIP as described in subclause 5.13. If the ISC gateway function provides an application level gateway functionality (IMS-ALG), then the ISC gateway function shall provide the UA role, with the exceptions and additional capabilities to SIP as described in subclause 5.13, and with the exceptions and additional capabilities to SDP as described in subclause 6.7.

– The MSC Server enhanced for ICS shall provide the UA role, with the exceptions and additional capabilities as described in 3GPP TS 24.292 [8O].

– The MSC server enhanced for SRVCC using SIP interface shall provide the UA role, with the exceptions and additional capabilities as described in 3GPP TS 24.237 [8M].

– The MSC server enhanced for DRVCC using SIP interface shall provide the UA role, with the exceptions and additional capabilities as described in 3GPP TS 24.237 [8M].

– The EATF shall provide the UA role, with the exceptions and additional capabilities as described in 3GPP TS 24.237 [8M].

– The ATCF shall:

a) provide the proxy role, with the exceptions and additional capabilities as described in 3GPP TS 24.237 [8M]; and

b) provide the UA role, with the exceptions and additional capabilities as described in 3GPP TS 24.237 [8M].

– Where access to the IM CN subsystem is provided using Web Real-Time Communication (WebRTC) in accordance with 3GPP TS 24.371 [8Z], the eP-CSCF shall act as the P-CSCF in regard to the Mw reference point. For SIP, conformance of the eP-CSCF and WIC (or whatever functionality is downloaded to the WIC) is not specified by this document unless 3GPP TS 24.371 [8Z] specifies that these entities act as specified for the interface Gm reference point, in which case existing P-CSCF and UE procedures apply, with the exceptions and additional capabilities as described in 3GPP TS 24.371 [8Z]. For SDP, these entities act as specified for the interface Gm reference point, in which case existing P-CSCF and UE procedures apply, with the exceptions and additional capabilities as described in 3GPP TS 24.371 [8Z].

In addition to the roles specified above, the P-CSCF, the I-CSCF, the IBCF, the S-CSCF, the BGCF, the E-CSCF and the ISC gateway function can act as a UA when providing server functionality to return a final response for any of the reasons specified in RFC 3261 [26].

In addition to the roles specified above the S-CSCF, AS and an entity hosting the additional routeing capabilities as specified in subclause I.3 can act as a UA when providing either client or server functionality when the event package associated with overload control is deployed.

NOTE 3: Annex A can change the status of requirements in referenced specifications. Particular attention is drawn to table A.4 and table A.162 for capabilities within referenced SIP specifications, and to table A.317 and table A.328 for capabilities within referenced SDP specifications. The remaining tables build on these initial tables.

NOTE 4: The allocated roles defined in this clause are the starting point of the requirements from the IETF SIP specifications, and are then the basis for the description of further requirements. Some of these extra requirements formally change the proxy role into a B2BUA. In all other respects other than those more completely described in subclause 5.2 the P-CSCF implements proxy requirements. Despite being a B2BUA a P-CSCF does not implement UA requirements from the IETF RFCs, except as indicated in this specification, e.g., relating to registration event subscription.

NOTE 5: Except as specified in clause 5 or otherwise permitted in RFC 3261, the functional entities providing the proxy role are intended to be transparent to data within received requests and responses. Therefore these entities do not modify message bodies. If local policy applies to restrict such data being passed on, the functional entity has to assume the UA role and reject a request, or if in a response and where such procedures apply, to pass the response on and then clear the session using the BYE method.

All the above entities are functional entities that could be implemented in a number of different physical platforms coexisting with a number of other functional entities. The implementation shall give priority to transactions at one functional entity, e.g. that of the E-CSCF, over non-emergency transactions at other entities on the same physical implementation. Such priority is similar to the priority within the functional entities themselves specified elsewhere in this document.

Additional routeing functionality can be provided to support the ability for the IM CN subsystem to provide transit functionality as specified in Annex I. The additional routeing functionality shall assume the proxy role.

4.2 URI and address assignments

In order for SIP and SDP to operate, the following prerequisite conditions apply:

1) I-CSCFs used in registration are allocated SIP URIs. Other IM CN subsystem entities may be allocated SIP URIs. For example sip:pcscf.home1.net and sip:<impl-specific-info>@pcscf.home1.net are valid SIP URIs. If the user part exists, it is an essential part of the address and shall not be omitted when copying or moving the address. How these addresses are assigned to the logical entities is up to the network operator. For example, a single SIP URI may be assigned to all I-CSCFs, and the load shared between various physical boxes by underlying IP capabilities, or separate SIP URIs may be assigned to each I-CSCF, and the load shared between various physical boxes using DNS SRV capabilities.

2) All IM CN subsystem entities are allocated IP addresses. Any IM CN subsystem entities can be allocated IPv4 only, IPv6 only or both IPv4 and IPv6 addresses. For systems providing access to IM CN subsystem using a GPRS IP-CAN or an EPS IP-CAN this is specified in 3GPP TS 23.221 [6] subclause 5.1. For systems providing access to IM CN subsystem using a cdma2000^®packet data subsystem IP-CAN this is specified in subclause M.2.2.1. For systems providing access to IM CN subsystem using a 5GS IP-CAN this is specified in 3GPP TS 23.501 [257], subclause 5.8.2.2.

3) The subscriber is allocated a private user identity by the home network operator. This private user identity is available to the SIP application within the UE. Depending on the network operator, various arrangements exist within the UE for retaining this information:

a) where an ISIM is present, within the ISIM, see subclause 5.1.1.1A;

b) where no ISIM is present but USIM is present, the private user identity is derived (see subclause 5.1.1.1A);

c) neither ISIM nor USIM is present, but IMC is present, within IMC (see subclause 5.1.1.1B.1);

d) when neither ISIM nor USIM nor IMC is present, the private user identity is available to the UE via other means (see subclause 5.1.1.1B.2).

NOTE 1: 3GPP TS 33.203 [19] specifies that a UE attached to a 3GPP network has an ISIM or a USIM.

NOTE 2: The SIP URIs can be resolved by using any of public DNSs, private DNSs, or peer-to-peer agreements.

4) The subscriber is allocated one or more public user identities by the home network operator. The public user identity shall take the form of SIP URI as specified in RFC 3261 [26] or tel URI as specified in RFC 3966 [22]. At least one of the public user identities is a SIP URI. All registered public user identities are available to the SIP application within the UE, after registration. Depending on the network operator, various arrangements exist within the UE for retaining this information:

a) where an ISIM is present, at least one public user identity, which is a SIP URI, within the ISIM, see subclause 5.1.1.1A;

b) where no ISIM is present but USIM is present, a temporary public user identity is derived (see subclause 5.1.1.1A);

c) neither ISIM nor USIM is present, but IMC is present, within IMC (see subclause 5.1.1.1B.1);

d) when neither ISIM nor USIM nor IMC is present, the public user identities are available to the UE via other means (see subclause 5.1.1.1B.2).

NOTE 3: 3GPP TS 33.203 [19] specifies that a UE attached to a 3GPP network has an ISIM or a USIM.

5) If the UE supports GRUU (see table A.4, item A.4/53) or multiple registrations, then it shall have an Instance ID, in conformance with the mandatory requirements for Instance IDs specified in RFC 5627 [93] and RFC 5626 [92].

6) For each tel URI, there is at least one alias SIP URI in the set of implicitly registered public user identities that is used to implicitly register the associated tel URI.

NOTE 4: For each tel URI, there always exists a SIP URI that has identical user part as the tel URI and the "user" SIP URI parameter equals "phone" (see RFC 3261 [26] subclause 19.1.6), that represents the same public user identity. If a tel URI identifies a subscriber served by the IM CN subsystem, then the hostport parameter of the respective SIP URI contains the home network domain name of the IM CN subsystem to which the subscriber belongs.

6A) Identification of the UE to a PSAP with point of presence in the CS domain is not possible if a tel URI is not included in the set of implicitly registered public user identities. If the included tel URI is associated either with the first entry in the list of public user identities provisioned in the UE or with the temporary public user identity, then a PSAP can uniquely identify the UE if emergency registration is performed.

NOTE 5: The tel URI uniquely identifies the UE by not sharing any of the implicit registered public user identities in the implicit registration set that contains this tel URI.

NOTE 6: Emergency registration is not always needed or supported.

7) The public user identities may be shared across multiple UEs. A particular public user identity may be simultaneously registered from multiple UEs that use different private user identities and different contact addresses. When reregistering and deregistering a given public user identity and associated contact address, the UE will use the same private user identity that it had used during the initial registration of the respective public user identity and associated contact address. If the tel URI is a shared public user identity, then the associated alias SIP URI is also a shared public user identity. Likewise, if the alias SIP URI is a shared public user identity, then the associated tel URI is also a shared public user identity.

8) For the purpose of access to the IM CN subsystem, UEs can be allocated IPv4 only, IPv6 only or both IPv4 and IPv6 addresses. For systems providing access to IM CN subsystem using a GPRS IP-CAN or an EPS IP-CAN this is specified in 3GPP TS 23.221 [6] subclause 5.1 (see subclause 9.2.1 for the assignment procedures). For systems providing access to IM CN subsystem using a cdma2000^® network this is specified in subclause M.2.2.1. For systems providing access to IM CN subsystem using a 5GS IP-CAN this is specified in 3GPP TS 23.501 [257], subclause 5.8.2.2.

9) For the purpose of indicating an IMS communication service to the network, UEs are assigned ICSI values appropriate to the IMS communication services supported by the UE, coded as URNs as specified in subclause 7.2A.8.2.

NOTE 7: cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA-USA).

10) E-CSCFs are allocated multiple SIP URIs. The SIP URI configured in the P-CSCF, AS or IBCF to reach the E-CSCF is distinct from the one given by the E-CSCF to the EATF such that EATF can reach the E-CSCF.

11) If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the subscriber is allocated one or usually more public user identities by the home network operator. The public user identity(s) shall be allocated as global numbers in the international format.

4.2A Transport mechanisms

This document makes no requirement on the transport protocol used to transfer signalling information over and above that specified in RFC 3261 [26] clause 18, unless such requirement is defined in the access technology specific annex for the current access technology (see subclause 3A). However, the UE and IM CN subsystem entities shall transport SIP messages longer than 1300 bytes according to the procedures of RFC 3261 [26] subclause 18.1.1, even if a mechanism exists of discovering a maximum transmission unit size longer than 1500 bytes.

NOTE 1: Support of SCTP as specified in RFC 4168 [96] is optional for IM CN subsystem entities implementing the role of a UA or proxy. SCTP transport between the UE and P-CSCF is not supported in the present document. Support of the SCTP transport is currently not described in 3GPP TS 33.203 [19].

For initial REGISTER requests, the UE and the P-CSCF shall apply port handling according to subclause 5.1.1.2 and subclause 5.2.2.

The UE and the P-CSCF shall send and receive request and responses other than initial REGISTER requests on the protected ports as described in 3GPP TS 33.203 [19].

In case of an emergency session if the UE does not have sufficient credentials to authenticate with the IM CN subsystem and regulations allow, the UE and P-CSCF shall send request and responses other than initial REGISTER requests on non protected ports.

NOTE 2: When TCP is used to carry SIP signalling between the UE and the P-CSCF, it is known that there is no NAT between the UE and the P-CSCF and neither TLS nor the multiple registration mechanism is used, then both the UE and the P-CSCF can decide to close an existing TCP connection subject to the conditions described in RFC 3261 [26].

4.2B Security mechanisms

4.2B.1 Signalling security

3GPP TS 33.203 [19] defines the security features and mechanisms for secure access to the IM CN subsystem. This document defines a number of access security mechanisms, as summarised in table 4-1.

Table 4-1: Summary of access security mechanisms to the IM CN subsystem

Mechanism	Authentication	Integrity protection	Use of security agreement in accordance with RFC 3329 [48]	Support (as defined in 3GPP TS 33.203 [19])
IMS AKA plus IPsec ESP (see 3GPP TS 33.203 [19] clause 6) (NOTE 8)	IMS AKA	IPsec ESP	Yes	Mandatory for all UEs containing a UICC, else optional. Mandatory for all P-CSCF, I-CSCF, S-CSCF.
IMS AKA using HTTP Digest AKAv2 without IPSec security association (see 3GPP TS 33.203 [19] annex X)	IMS AKA	TLS session (NOTE 7)	No	Mandatory for all UEs containing a WIC able to access to UICC. Mandatory for all eP-CSCF. Optional for S-CSCF.
SIP digest plus check of IP association (see 3GPP TS 33.203 [19] annex N) (NOTE 2)	SIP digest	None (NOTE 3)	No	Optional for UEs. Optional for P-CSCF, I-CSCF, S-CSCF.
SIP digest plus Proxy Authentication (see 3GPP TS 33.203 [19] annex N) (NOTE 2)	SIP digest	None (NOTE 3)	No	Optional for UEs Optional for P-CSCF, I-CSCF, S-CSCF
SIP digest with TLS (see 3GPP TS 33.203 [19] annex N and annex O)	SIP digest	TLS session	Yes	Optional for UEs. Optional for P-CSCF, I-CSCF, S-CSCF.
NASS-IMS bundled authentication (see 3GPP TS 33.203 [19] annex R) (NOTE 4, NOTE 5)	not applicable (NOTE 1)	None (NOTE 3)	No	No UE support required. Optional for P-CSCF, I-CSCF, S-CSCF.
GPRS-IMS-Bundled authentication (see 3GPP TS 33.203 [19] annex S) (NOTE 5)	not applicable (NOTE 1)	None (NOTE 3)	No	Optional for UEs. Optional for P-CSCF, I-CSCF, S-CSCF.
Trusted node authentication (see 3GPP TS 33.203 [19] annex U)	not applicable (NOTE 6)	None (NOTE 3)	No	No UE support required. Optional for I-CSCF, S-CSCF.
SIP over TLS with client certificate authentication (see 3GPP TS 33.203 [19] annex O)	TLS client certificate	TLS session	No	Mandatory for a UE performing the functions of an external attached network operating in static mode. Optional for IBCF and P-CSCF.
NOTE 1: Authentication is not provided as part of the IM CN subsystem signalling. NOTE 2: The term "SIP digest without TLS" is used in this specification to refer to both "SIP digest plus check of IP association" and "SIP digest plus Proxy Authentication". NOTE 3: This security mechanism does not allow SIP requests to be protected using an IPsec security association because it does not perform a key agreement procedure. NOTE 4: A P-Access-Network-Info aware P-CSCF is required in order to provide NASS-IMS bundled authentication. NOTE 5: The P-CSCF is restricted to the home network when performing this security mechanism. NOTE 6: Trusted node authentication. For example the MSC server enhanced for IMS centralized services has authenticated the UE and as a consequence S-CSCF will skip authentication. NOTE 7: SIP requests received at the eP-CSCF are protected by a TLS session established prior registration (see 3GPP TS 33.203 [19] annex X). NOTE 8: IMS AKA and IPsec ESP mechanism includes support of "AKAv2-SHA-256" and "AKAv1-MD5" digest algorithms, but "AKAv1-MD5" algorithm is only supported for backward compatibility.

Specification of the mechanisms identified within table 4-1 within this document are provided in clause 5. Subclauses where security procedures are required consist of a general subclause applicable whichever security mechanisms are in use, and a separate subclause for each security mechanism identified by a row within table 4-1.

For access to the IM CN subsystem different than WebRTC TLS is optional to implement and is used only in combination with SIP digest authentication. For WebRTC based access to the IM CN subsystem TLS can be used in combination with IMS AKA using HTTP Digest AKAv2 without IPSec security association. Authentication associated with registration to the IM CN subsystem is applicable to IMS AKA and SIP digest and is covered in subclause 5.1.1 for the UE, subclause 5.2.2 for the P-CSCF and subclause 5.4.1 for the S-CSCF. Additionally, SIP digest allows for authentication to also occur on an initial request for a dialog or a request for a standalone transaction, this additional capability is covered in subclause 5.1.2A and subclause 5.4.3.2.

If a UE that implements SIP digest is configured not to use TLS, then the UE does not establish a TLS session toward the P-CSCF. If a UE supports TLS, then the UE supports TLS as described in 3GPP TS 33.203 [19].

For SIP digest authentication, the P-CSCF can be configured to have TLS required or disabled:

– if TLS is required, the P-CSCF requires the establishment of a TLS session from all SIP digest UEs, in order to access IMS subsequent to registration; or

– if TLS is disabled, the P-CSCF does not allow the establishment of a TLS session from any UE.

NOTE: The mechanism to configure the P-CSCF to have TLS required or disabled is outside the scope of this specification.

SIP digest cannot be used in conjunction with the procedures of Annex F.

For emergency calls, 3GPP TS 33.203 [19] specifies some relaxations, which are further described in the subclauses of this document relating to emergency calls.

3GPP TS 33.210 [19A] defines the security architecture for network domain IP based control planes. 3GPP TS 33.210 [19A] applies for security mechanisms between entities in the IM CN subsystem.

4.2B.2 Media security

3GPP TS 33.328 [19C] defines mechanisms for support of security on the media plane.

This document defines the required elements for signalling the support of media security.

The media security mechanisms are summarised as shown in table 4-2.

Table 4-2: Summary of media security mechanisms to the IM CN subsystem

Mechanism	Applicable to media			Support required by UE		Support required by IM CN subsystem entities	Network support outside IM CN subsystem entities
End-to-access-edge media security using SDES.	RTP based media only.			Support RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/34, A.317/36 and A.317/37.		P-CSCF (IMS-ALG) is required. P-CSCF support of RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/34, A.317/36 and A.317/37. (NOTE)	Not applicable.
End-to-access-edge media security using DTLS-SRTP.		RTP based media only.	Support RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/51 and A.317/55.		P-CSCF (IMS-ALG) is required. P-CSCF support of RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/51 and A.317/55. (NOTE)			Not applicable.
End-to-access-edge media security for MSRP using TLS and certificate fingerprints.	MSRP based media only.			Support RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/40, A.317/40A, A.317/51 and A.317/37A.		P-CSCF (IMS-ALG) is required. P-CSCF support of RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/40, A.317/40A, A.317/51 and A.317/37A. (NOTE)	Not applicable.
End-to-access-edge media security for BFCP using TLS and certificate fingerprints.	BFCP based media only.			Support RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/28, A.317/51 and A.317/37B.		P-CSCF (IMS-ALG) is required. P-CSCF support of RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/28, A.317/51 and A.317/37B. (NOTE)	Not applicable.
End-to-access-edge media security for UDPTL using DTLS and certificate fingerprints.	UDPTL based media only.			Support RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/52, A.317/51 and A.317/37C.		P-CSCF (IMS-ALG) is required. P-CSCF support of RFC 3329 additions specified in subclause 7.2A.7 and SDP extensions specified in table A.317, items A.317/52, A.317/51 and A.317/37C. (NOTE)	Not applicable.
End-to-end media security using SDES.	RTP based media only.			Support SDP extensions specified in table A.317, items A.317/34 and A.317/36.		Not applicable.	Not applicable.
End-to-end media security using KMS.	RTP based media only.			Support SDP extensions specified in table A.317, items A.317/34 and A.317/35.		Not applicable.	GBA and KMS support required.
End-to-end media security for MSRP using TLS and KMS.	MSRP based media only.			Support SDP extensions specified in table A.317, items A.317/40, A.317/40A and A.317/35, and support RFC 4279 [218].		Not applicable.	GBA and KMS support required.
NOTE: Support of end-to-access-edge media security is determined entirely by the network operator of the P-CSCF, which need not be the same network operator as that of the S-CSCF.

For RTP media security using SDES, the UE supports the SDES key management protocol and optionally the KMS key management protocol as defined in 3GPP TS 33.328 [19C] and SRTP as defined in RFC 3711 [169] for secure transport of media.

For end-to-access-edge media security of RTP media using DTLS-SRTP, the UE supports DTLS‑SRTP as defined in RFC 5763 [222] and RFC 5764 [223] with certificate fingerprints as defined in 3GPP TS 33.328 [19C].

For end-to-access-edge media security for MSRP using TLS and certificate fingerprints, the UE supports MSRP over TLS as defined in RFC 4975 [178] and RFC 6714 [214] with certificate fingerprints as defined in 3GPP TS 33.328 [19C].

For end-to-access-edge media security for BFCP using TLS and certificate fingerprints, the UE supports BFCP over TLS as defined in RFC 4583 [108] with certificate fingerprints as defined in 3GPP TS 33.328 [19C].

For end-to-access-edge media security for UDPTL using DTLS and certificate fingerprints, the UE supports UDPTL over DTLS as defined in RFC 7345 [217] and RFC 8842 [240], with certificate fingerprints as defined in 3GPP TS 33.328 [19C].

For end-to-end media security for MSRP using TLS and KMS, the UE supports MSRP over TLS as defined in RFC 4975 [178] and RFC 6714 [214] with pre-shared key ciphersuites as defined in RFC 4279 [218] and the KMS key management protocol as defined in 3GPP TS 33.328 [19C]. The certificate fingerprints are not indicated.

There is no support for media security in the MGCF, because there would be no end-to-end media security support on calls interworked with the CS domain and the CS user. In this release of this document, there is no support for media security in the MRF. End-to-access-edge media security is not impacted by this absence of support.

For emergency calls, it is not expected that PSAPs would support end-to-end media security and therefore the procedures of this document do not allow the UE to establish such sessions with end-to-end media security. End-to-access-edge media security is not impacted and can be used on emergency calls.

When the UE performs the functions of an external attached network (e.g. an enterprise network):

– where end-to-access-edge media security is used, the UE functionality is expected to be in the gateway of the external attached network, and support for further media security is outside the scope of this document; and

– where end-to-end media security is used, the UE functionality is expected to be supported by the endpoints in the attached network.

4.3 Routeing principles of IM CN subsystem entities

Each IM CN subsystem functional entity shall apply loose routeing policy as described in RFC 3261 [26], when processing a SIP request. In cases where the I-CSCF, IBCF, S-CSCF and the E-CSCF may interact with strict routers in non IM CN subsystem networks, the I-CSCF, IBCF, S-CSCF and E-CSCF shall use the routeing procedures defined in RFC 3261 [26] to ensure interoperability with strict routers.

4.4 Trust domain

4.4.1 General

A trust domain can apply for specific header fields, tel URI parameters and SIP URI parameters within the IM CN subsystem.

For the IM CN subsystem, this trust domain consists of the functional entities that belong to the same operator’s network (P-CSCF, the eP-CSCF, the E-CSCF, the I-CSCF, the IBCF, the S-CSCF, the BGCF. the MGCF, the MRFC, the MRB, the EATF, the ATCF, the ISC gateway function, and all ASs that are included in the trust domain). Additionally, other nodes within the IM CN subsystem that are not part of the same operator’s domain may or may not be part of the trust domain, depending on whether an interconnect agreement exists with the remote network. SIP functional entities that belong to a network for which there is an interconnect agreement are part of the trust domain. ASs outside the operator’s network can also belong to the trust domain if they have a trusted relationship with the home network.

NOTE 1: Whether any peer functional entity is regarded as part of the same operator’s domain, and therefore part of the same trust domain, is dependent on operator policy which is preconfigured into each functional entity.

NOTE 2: For the purpose of this document, the PSAP is typically regarded as being within the trust domain, except where indicated. National regulator policy applicable to emergency services determines the trust domain applicable to certain header fields. This means that e.g. the handling of the P-Access-Network-Info header field, P-Asserted-Identity header field and the History-Info header field can be as if the PSAP is within the trust domain, and trust domain issues will be resolved accordingly.

The trust domain can exist for a number of purposes:

a) for the protection of information specific to an operator;

b) to provide for privacy requirements of the end user; or

c) to ensure that information is only passed to another entity if certain responsibilities related to that information are met by the receiving entity, for example that the signalled requirements in the Privacy header field will be met (see subclause 4.4.2 and 4.4.4).

Within the IM CN subsystem trust domains will be applied to a number of header fields. These trust domains do not necessarily contain the same functional entities or cover the same operator domains. The procedures in this subclause apply to the functional entities in clause 5 in the case where a trust domain boundary for that header field, tel URI parameter, or SIP URI parameter, exists at that functional entity.

Where the IM CN subsystem supports business communication, different trust domains can apply to public network traffic, and to private network traffic belonging to each supported corporate network.

NOTE 3: Where an external attached network (e.g. an enterprise network) is in use, the edges of the trust domains need not necessarily lie at the P-CSCF. In this release of the specification, the means by which the P-CSCF learns of such attached devices, and therefore different trust domain requirements to apply, is not provided in the specification and is assumed to be by configuration or by a mechanism outside the scope of this release of the specification.

A trust domain applies for the purpose of the following header fields: P-Asserted-Identity, P-Access-Network-Info, History-Info, Resource-Priority, P-Asserted-Service, Reason (only in a response), P-Profile-Key, P-Private-Network-Indication, P-Served-User, P-Early-Media, Feature-Caps, Restoration-Info, Relayed-Charge, Service-Interact-Info, Cellular-Network-Info, Response-Source, Attestation-Info, Origination-Id, Additional-Identity and Priority-Verstat. A trust domain applies for the purpose of the CPC and OLI tel URI parameters. A trust domain applies for the iotl SIP URI parameter. The trust domains of these header fields and parameters need not have the same boundaries. Clause 5 defines additional procedures concerning these header fields, tel URI parameters and SIP URI parameter.

4.4.2 P-Asserted-Identity

RFC 3325 [34] provides for the existence and trust of an asserted identity within a trust domain. A functional entity at the boundary of the trust domain will need to determine whether to remove the P-Asserted-Identity header field according to RFC 3325 [34] when SIP signalling crosses the boundary of the trust domain. The priv-value "id" shall not be removed from the Privacy header field when SIP signalling crosses the boundary of the trust domain. Subclause 5.4 identifies additional cases for the removal of the P-Asserted-Identity header field.

4.4.3 P-Access-Network-Info

A functional entity at the boundary of the trust domain shall remove any P-Access-Network-Info header field according to RFC 7315 [52].

4.4.4 History-Info

A functional entity at the boundary of the trust domain will need to determine whether to remove the History-Info header field according to RFC 7044 [66] subclause 10.1.2 when SIP signalling crosses the boundary of the trust domain. Subclause 5.4 identifies additional cases for the removal of the History-Info header field.

4.4.5 P-Asserted-Service

A functional entity at the boundary of the trust domain will need to determine whether to remove the P-Asserted-Service header field according to RFC 6050 [121] when SIP signalling crosses the boundary of the trust domain.

4.4.6 Resource-Priority

If Priority verification using assertion of priority information features described in subclause 3.1 is supported then a functional entity at the boundary of the trust domain will need to determine, based on the operator policy, whether to remove a Resource-Priority header field.

Otherwise, if Priority verification using assertion of priority information features described in subclause 3.1 is not supported a functional entity shall only include a Resource-Priority header field in a request or response forwarded to another entity within the trust domain. If a request or response is forwarded to an entity outside the trust domain, the functional entity shall remove the Resource-Priority header field from the forwarded request or response. If a request or response is received from an untrusted entity (with the exception requests or responses received by the P-CSCF from the UE for which procedures are defined in subclause 5.2) that contains the Resource-Priority header field, the functional entity shall remove the Resource-Priority header field before forwarding the request or response within the trust domain.

NOTE: Alternate treatments can be applied when a non-trusted Resource-Priority header field is received over the boundary of trust domain. The exact treatment (e.g. removal, modification, or passing of the Resource-Priority header field) is left to national regulation and network configuration.

4.4.7 Reason (in a response)

A functional entity shall only include a Reason header field in a response forwarded to another entity within the trust domain (as specified in RFC 6432 [130]). If a response is forwarded to an entity outside the trust domain, the functional entity shall remove the Reason header field from the forwarded response.

NOTE: A Reason header field can be received in a response from outside the trust domain and will not be removed.

4.4.8 P-Profile-Key

A functional entity at the boundary of the trust domain will need to determine whether to remove the P-Profile-Key header field as defined in RFC 5002 [97] when SIP signalling crosses the boundary of the trust domain.

4.4.9 P-Served-User

A functional entity at the boundary of the trust domain will need to determine whether to remove the P-Served-User header field according to RFC 5502 [133] when SIP signalling crosses the boundary of the trust domain.

4.4.10 P-Private-Network-Indication

A functional entity shall only include a P-Private-Network-Indication header field in a request forwarded to another entity within the trust domain. If a request is forwarded to an entity outside the trust domain, the functional entity shall remove the P-Private-Network-Indication header field from the forwarded request. If a request is received from an untrusted entity that contains the P-Private-Network-Indication header field, the functional entity shall remove the P-Private-Network-Indication header field before forwarding the request within the trust domain.

NOTE 1: Other entities within the enterprise will frequently be part of this trust domain.

NOTE 2: The presence of the P-Private-Network-Indication header field is an indication that the request constitutes private network traffic. This can modify the trust domain behaviour for other header fields.

NOTE 3: If a trust domain boundary is encountered for this header field without appropriate business communication processing, then this can be an indication that misconfiguration has occurred in the IM CN subsystem. Removal of this header field changes the request from private network traffic to public network traffic.

4.4.11 P-Early-Media

A functional entity at the boundary of the trust domain will need to determine whether to remove the P-Early-Media header field as defined in RFC 5009 [109] when SIP signalling crosses the boundary of the trust domain.

4.4.12 CPC and OLI

Entities in the IM CN subsystem shall restrict "cpc" and "oli" URI parameters to specific domains that are trusted and support the "cpc" and "oli" URI parameters. Therefore for the purpose of the "cpc" and "oli" URI parameters within this specification, a trust domain also applies.

SIP functional entities within the trust domain shall remove the "cpc" and "oli" URI parameters when the SIP signalling crosses the boundary of the trust domain.

4.4.13 Feature-Caps

A functional entity at the boundary of the trust domain shall remove all Feature-Caps header fields received from UEs and external networks outside the trust domain.

NOTE: A UE that is a privileged sender is considered as part of the trust domain.

4.4.14 Priority

Based on local policy, a functional entity at the boundary of the trust domain shall remove all Priority header fields with a "psap-callback" header field value.

4.4.15 iotl

Entities in the IM CN subsystem shall restrict "iotl" URI parameter to specific domains that are trusted and support the "iotl" URI parameter. Support implies that the parameter is removed before the containing request is sent over an interface of a different type. Therefore for the purpose of the "iotl" URI parameter within this specification, a trust domain also applies.

SIP functional entities within the trust domain shall remove the "iotl" URI parameter when the SIP signalling crosses the boundary of the trust domain.

4.4.16 Restoration-Info

A functional entity at the boundary of the trust domain will need to determine whether to remove the Restoration-Info header field when SIP signalling crosses the boundary of the trust domain.

4.4.17 Relayed-Charge

Entities in the IM CN subsystem shall restrict the Relayed-Charge header field to specific domains that are trusted and support the Relayed-Charge header field. Trust implies that the sending domain intends the receiving domain to have the contents of this header field. Therefore for the purpose of the Relayed-Charge header field within this specification, a trust domain also applies.

SIP functional entities within the trust domain shall remove the Relayed-Charge header field when the SIP signalling crosses the boundary of the trust domain.

4.4.18 Service-Interact-Info

A functional entity at the boundary of the trust domain shall remove all Service-Interact-Info header fields defined in subclause 7.2.when SIP signalling crosses the boundary of the trust domain.

4.4.19 Cellular-Network-Info

A functional entity shall only include a Cellular-Network-Info header field in a request forwarded to another entity within the trust domain. If a request is forwarded to an entity outside the trust domain, the functional entity shall remove the Cellular-Network-Info header field from the forwarded request. If a request is received from an untrusted entity that contains the Cellular-Network-Info header field, the functional entity shall remove Cellular-Network-Info header field before forwarding the request within the trust domain.

4.4.20 Response-Source

A functional entity at the boundary of the trust domain will need to determine whether to remove the Response-Source header field according to subclause 7.2.17. when SIP signalling crosses the boundary of the trust domain.

4.4.21 Attestation-Info header field

A functional entity at the boundary of the trust domain will need to determine whether to remove the Attestation-Info header field according to subclause 7.2.18. when SIP signalling crosses the boundary of the trust domain.

4.4.22 Origination-Id header field

A functional entity at the boundary of the trust domain will need to determine whether to remove the Origination-Id header field according to subclause 7.2.19 when SIP signalling crosses the boundary of the trust domain.

4.4.23 Additional-Identity header field

A functional entity at the boundary of the trust domain will need to determine whether to remove the Additional-Identity header field according to subclause 7.2.20 when SIP signalling crosses the boundary of the trust domain.

4.4.24 Priority-Verstat header field

A functional entity at the boundary of the trust domain will need to determine whether to remove the Priority-Verstat header field according to subclause 7.2.21 when SIP signalling crosses the boundary of the trust domain.

4.5 Charging correlation principles for IM CN subsystems

4.5.1 Overview

This subclause describes charging correlation principles to aid with the readability of charging related procedures in clause 5. See 3GPP TS 32.240 [16] and 3GPP TS 32.260 [17] for further information on charging.

The IM CN subsystem generates and retrieves the following charging correlation information for later use with offline and online charging:

1. IM CN subsystem Charging Identifier (ICID);

2. Access network charging information;

3. Inter Operator Identifier (IOI);

4. Charging function addresses:

a. Charging Data Function (CDF);

b. Online Charging Function (OCF);

5. IM CN subsystem Functional Entity Identifier.

How to use and where to generate the parameters in IM CN subsystems are described further in the subclauses that follow. The charging correlation information is encoded in the P-Charging-Vector header field as defined in subclause 7.2A.5 and in RFC 7315 [52]. The P-Charging-Vector header field contains the following header field parameters: "icid-value", "icid-generated-at", "related-icid", "related-icid-generated-at", "access-network-charging-info", "orig-ioi", "term-ioi", "transit-ioi" and "fe-identifier".

The offline and online charging function addresses are encoded in the P-Charging-Function-Addresses as defined in RFC 7315 [52]. The P-Charging-Function-Addresses header field contains the following header field parameters: "ccf" for CDF and "ecf" for OCF.

NOTE: P-Charging-Function-Addresses parameters were defined using previous terminology.

4.5.2 IM CN subsystem charging identifier (ICID)

The ICID is the session level data shared among the IM CN subsystem entities including ASs in both the calling and called IM CN subsystems. The ICID is used also for session unrelated messages (e.g. SUBSCRIBE request, NOTIFY request, MESSAGE request) for the correlation with CDRs generated among the IM CN subsystem entities.

The first IM CN subsystem entity involved in a SIP transaction will generate the ICID and include it in the "icid-value" header field parameter of the P-Charging-Vector header field in the SIP request.

For a dialog relating to a session, the generation of the ICID will be performed only on the initial request. This ICID will be used for the initial request and any response to the initial request, and all subsequent SIP messages ina P-Charging-Vector header field.

For all other transactions, generation of the ICID will be performed on each SIP request. This ICID will be used for the SIP request and any response to the SIP request in a P-Charging-Vector header field.

The "icid-value" header field parameter is inserted in the IM CN subsystem, as summarised in table 4-2A.

NOTE: This summary is also applicable for SIP messages which are not specified in clause 5, although each procedure for the P-Charging-Vector header field in clause 5 is described only for specific SIP message(s) (e.g. only for a 200 (OK) response).

Table 4-2A: Summary of ICID insertion in the IM CN subsystem

Inserted in	For initial or standalone SIP message	For subsequent SIP message
Any request	The first IM CN subsystem entity receiving the request inserts the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17].	The first IM CN subsystem entity receiving the request inserts the "icid-value" header field parameter set to the value populated in the initial request for the dialog.
Any response to the request	The first IM CN subsystem entity receiving the response inserts the "icid-value" header field parameter set to the value populated in the initial request for the dialog or the standalone request.	The first IM CN subsystem entity receiving the response inserts the "icid-value" header field parameter set to the value populated in the initial request for the dialog.

See 3GPP TS 32.260 [17] for requirements on the format of ICID. The P-CSCF will generate an ICID for UE-originated calls. The I-CSCF will generate an ICID for UE-terminated calls if there is no ICID received in the initial request (e.g. the calling party network does not behave as an IM CN subsystem). The AS will generate an ICID when acting as an originating UA. The MGCF will generate an ICID for PSTN/PLMN originated calls. The MSC server will generate an ICID for ICS and SRVCC originated calls. Each entity that processes the SIP request will extract the ICID for possible later use in a CDR. The I-CSCF and S-CSCF are also allowed to generate a new ICID for UE-terminated calls received from another network.

There is also an ICID generated by the P-CSCF with a REGISTER request that is passed in a unique instance of P-Charging-Vector header field. The valid duration of the ICID is specified in 3GPP TS 32.260 [17].

The "icid-value" header field parameter is included in any request and response that includes the P-Charging-Vector header field. However, the P-Charging-Vector (and ICID) is not passed to the UE.

The ICID is also passed from the P-CSCF to the IP-CAN via PCRF. The interface supporting this operation is outside the scope of this document.

4.5.2A Related ICID

During the process of SRVCC access transfer the MSC server or the P-CSCF generates an ICID for the target access leg. For the purpose of charging correlation between the source access leg and the target access leg when the user is roaming the SCC AS and the ATCF includes the ICID used on the source access leg in the "related-icid" header field parameter of the P-Charging-Vector header field returned in 1xx and 2xx responses to the initial INVITE request.

During the process of dual radio access transfer the MSC server or the P-CSCF generates an ICID for the target access leg. For the purpose of charging correlation between the source access leg and the target access leg when the user is roaming the SCC AS includes the ICID used on the source access leg in the "related-icid" header field parameter of the P-Charging-Vector header field returned in 1xx and 2xx responses to the initial INVITE request.

4.5.3 Access network charging information

4.5.3.1 General

The access network charging information are the media flow level data shared among the IM CN subsystem entities for one side of the session (either the calling or called side). GPRS charging information (GGSN identifier and PDP context information) is an example of access network charging information.

4.5.3.2 Access network charging information

The IP-CAN provides the access network charging information to the IM CN subsystem. This information is used to correlate IP-CAN CDRs with IM CN subsystem CDRs, i.e. the access network charging information is used to correlate the bearer level with the session level.

The access network charging information is generated at the first opportunity after the resources are allocated at the IP-CAN. The access network charging information is passed from IP-CAN to P-CSCF via PCRF, over the Rx and Gx interfaces. Access network charging information will be updated with new information during the session as media flows are added or removed. The P-CSCF provides the access network charging information to the S-CSCF. The S-CSCF may also pass the information to an AS, which may be needed for online pre-pay applications. The access network charging information for the originating network is used only within that network, and similarly the access network charging information for the terminating network is used only within that network. Thus the access network charging information are not shared between the calling and called networks. The access network charging information is not passed towards the external ASs from its own network.

The access network charging information is populated in the P-Charging-Vector header field.

The access network charging information can be included in a P-Charging-Vector header field in dialog forming requests, mid-dialog requests, and responses. This is dependant on when updated information is avialable in the P-CSCF.

4.5.4 Inter operator identifier (IOI)

The Inter Operator Identifier (IOI) is a globally unique identifier to share between sending and receiving networks, service providers or content providers.

The sending network populates the "orig-ioi" header field parameter of the P-Charging-Vector header field in a request and thereby identifies the operator network from which the request was sent. The "term-ioi" header field parameter is left out of the P-Charging-Vector header field in this request. The sending network retrieves the "term-ioi" header field parameter from the P-Charging-Vector header field in a response to the request, which identifies the operator network from which the response was sent.

The receiving network retrieves the "orig-ioi" header field parameter from the P-Charging-Vector header field in the request, which identifies the operator network from which the request was sent. The receiving network populates the "term-ioi" header field parameter of the P-Charging-Vector header field in the response to the request, which identifies the operator network from which the response was sent.

The "orig-ioi" and "term-ioi" header field parameters are inserted in the IM CN subsystem, as summarised in table 4-2B.

Table 4-2B: Summary of IOI insertion in the IM CN subsystem

Inserted in

For initial, standalone or subsequent SIP message

Any request

The IM CN subsystem entity in the sending network:

1) removes any received "orig-ioi" header field parameter, if present;

2) inserts the "orig-ioi" header field parameter to a value that identifies the sending network of the request; and

3) does not insert the "term-ioi" header field parameter.

Any response to the request

The IM CN subsystem entity in the receiving network:

1) removes any received "orig-ioi" and "term-ioi" header field parameters, if present;

2) inserts the "orig-ioi" header field parameter set to the previously received value of "orig-ioi" header field parameter, if received in the request; and

3) inserts the "term-ioi" header field parameter to a value that identifies the receiving network from which the response is sent.

There are three types of IOI:

a) Type 1 IOI, between the visited network and the home network. This includes the following cases:

– between the P-CSCF (possibly in the visited network) and the S-CSCF in the home network. This is exchanged in REGISTER requests and responses, and in all session-related and session-unrelated requests and responses;

– between the SCC AS in the home network and the ATCF (possible in the visited network). This is exchanged in MESSAGE requests and responses;

NOTE: For applications where the primary relationship is home and visited network, request and responses to the request will normally contain a type 1 IOI value.

– between the MSC server (possibly in the visited network) and the S-CSCF in the home network. This is exchanged in REGISTER requests and responses, and in all session-related and session-unrelated requests and responses; and

– when using Roaming Architecture for Voice over IMS with Local Breakout and loopback routeing occurs, between the S-CSCF of the home network and the TRF of the visited network or between the BGCF of the home network and the TRF of the visited network. This is exchanged in all session-related requests and responses.

b) Type 2 IOI, between originating network and the terminating network. This includes the following cases:

– between the S-CSCF of the home originating network and the S-CSCF of the home terminating network or between the S-CSCF of the home originating network and the MGCF when a call/session is terminated at the PSTN/PLMN;

– between the MGCF and the S-CSCF of the home terminating network when a call/session is originated from the PSTN/PLMN or with a PSI AS when accessed across I-CSCF; and

– when using Roaming Architecture for Voice over IMS with Local Breakout and loopback routeing occurs, between the TRF of the visited network and the S-CSCF of the home terminating network.

This is exchanged in all session-related and session-unrelated requests and responses.

Additionally, for emergency transactions, a type 2 IOI is exchanged between the E-CSCF and the MGCF or IBCF where the request is routed to a PSAP. In scenarios where the E-CSCF receives emergency requests from an S-CSCF, a type 2 IOI is exchanged. This can also occur where the E-CSCF receives emergency requests from an IBCF.

c) Type 3 IOI, between the S-CSCF or I-CSCF of the home operator network and any AS. Type 3 IOI are also used between E-CSCF and LRF, between E-CSCF and EATF, and between transit function and AS. The type 3 IOI is exchanged in all session-related and session-unrelated requests and responses.

Each entity that processes the SIP request will extract the IOI for possible later use in a CDR. The valid duration of the IOI is specified in 3GPP TS 32.240 [16].

4.5.4A Transit inter operator identifier (Transit IOI)

The Transit Inter Operator Identifier (Transit IOI) is a globally unique identifier to share between sending, transit and receiving networks, service providers or content providers.

A network sending a request can retrieve the "transit-ioi" header field parameter value(s) from the P-Charging-Vector header field in the response to the sent request, which identify the operator network(s) which the response was transitting.

The transit network(s) populate(s) the "transit-ioi" header field parameter value(s) of the P-Charging-Vector header field in a request and thereby identify(ies) the operator network(s) which the request was transitting. The "transit-ioi" header field parameter is an indexed value that is incremented each time a value is added. When the index is calculated then "void" entries are taken into account.

The transit network(s) populate(s) the "transit-ioi" header field parameter value(s) of the P-Charging-Vector header field in the response to the request and thereby identify(ies) the operator network(s) which the response was transitting. The "transit-ioi" header field parameter is an indexed value that is incremented each time a value is added. When the index is calculated then "void" entries are taken into account.

A network receiving a request can retrieve the "transit-ioi" header field parameter value(s) from the P-Charging-Vector header field in the request, which identify the operator network(s) which the request was transitting.

EXAMPLE:

Transit-IOI in a request when arriving on the terminating side:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; transit-ioi="operatorA.1, void, operatorB.3"

Transit-IOI in the corresponding response when arriving on the originating side:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home2.net; transit-ioi="operatorB.1, void, operatorA.3"

The Transit IOI is exchanged between functional entities, as summarised in table 4-3.

Table 4-3: Summary of Transit IOI exchange in the IM CN subsystem

Item	Entities adding Transt IOI (NOTE 1)	Entities deleting Transit IOI (NOTE 1)
1	additional routeing functions as defined in annex I or IBCF (NOTE 2) in the transit network located between the visited network and the home network	S-CSCF of the home network; P-CSCF of the visited network; or TRF of the visited originating network when using Roaming Architecture for Voice over IMS with Local Breakout and loopback routeing occurs
2	additional routeing functions as defined in annex I or IBCF (NOTE 2) in the transit network located between originating network and the terminating network	S-CSCF of the home terminating network; S-CSCF of the home originating network; MGCF when a call/session is terminated at the PSTN/PLMN; or TRF of the visited originating network when using Roaming Architecture for Voice over IMS with Local Breakout and loopback routeing occurs
3	additional routeing functions as defined in annex I colocated with MGCF when a call/session was transitting the PSTN/PLMN	S-CSCF of the home terminating network
NOTE 1: Transit IOIs can also be exchanged with non 3GPP networks, e.g. IPX networks. NOTE 2: In the transit network, the IBCF acting as an entry point adds the Transit IOI in requests and the IBCF acting as an exit point adds the Transit IOI in responses, as described in subclause 5.10.

Each entity that processes the SIP requests and responses may extract the Transit IOI for charging purposes, as described in 3GPP TS 32.260 [17].

4.5.5 Charging function addresses

Charging function addresses are distributed to each of the IM CN subsystem entities in the home network for one side of the session (either the calling or called side) and provide a common location for each entity to send charging information. Charging Data Function (CDF) addresses are used for offline billing. Online Charging Function (OCF) addresses are used for online billing.

There may be multiple addresses for CDF and OCF addresses populated into the P-Charging-Function-Addresses header field of the SIP request or response. The header field parameters are "ccf" and "ecf" for CDF and OCF, respectively. At least one instance of either "ccf" or "ecf" header field paramter is required. If "ccf" header field parameter is included for offline charging, then a secondary "ccf" header field paramter may be included by each network for redundancy purposes, but the first instance of "ccf" header field parameter is the primary address. If ecf address is included for online charging, then a secondary instance may also be included for redundancy.

The CDF and/or OCF addresses are retrieved from an Home Subscriber Server (HSS) via the Cx interface and passed by the S-CSCF to subsequent entities. The charging function addresses are passed from the S-CSCF to the IM CN subsystem entities in its home network, but are not passed to the visited network or the UE. When the P-CSCF is allocated in the visited network, then the charging function addresses are obtained by means outside the scope of this document. The AS receives the charging function addresses from the S-CSCF via the ISC interface. CDF and/or OCF addresses may be allocated as locally preconfigured addresses. The AS can also retrieve the charging function address from the HSS via Sh interface.

4.5.6 Relayed charge parameters

Where there is a desire to pass charging information to an entity over an interface to which the charging information is not directly related, then the Relayed-Charge header field is used. This is used only in accordance with the capabilities specified in this document, which currently specify only the relay of a transit IOI to an associated AS.

4.5.7 Loopback-indication parameter

When there is a desire to send the information that loopback has been applied to an entity, then the loopback-indication parameter is used. This parameter can e.g. be evaluated when processing the P-CSCF CDR and possibly the ATCF CDR to know whether or not to attempt to locate a correlated TRF CDR even for the non-loopback scenario when no such CDR exists. It is used only in accordance with the capabilities specified in this document.

4.5.8 IM CN subsystem Functional Entity Identifier

4.5.8.1 General

Different rules for generating and processing of charging information apply. In order to inform the billing domain which IM CN subsystem functional entities have created charging information, the IM CN subsystem functional entities and ASs include an "fe-identifier" header field parameter as additional information in the P-Charging-Vector header field when generating charging information as specified in 3GPP TS 32.260 [17].

NOTE: Within the billing domain this information given within the "fe-identifier" header field in a final response allows the billing domain to compare the generated data records for specific IM CN subsystem functional entities with the recorded addresses/identifiers of the IM CN subsystem functionial entities themselves. Thus information can be compared and missing information can be identified.

4.5.8.2 Tracking of IM CN subsystem functional entities generating charging information

Each IM CN subsystem functional entity that generates charging events, includes its own address or specific IM CN subsystem functional entity identifier within the "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field into the initial SIP request to be sent from own domain.

The last element of the operator domain stores the "fe-identifier" header field parameter in the P-Charging-Vector header field and removes the "fe-identifier" header field parameter from the P-Charging-Vector header field.

When receiving the final SIP response sent back to its own domain, the last element of the operator domain deletes, if received, the "fe-identifier" header field parameter from the P-Charging-Vector header field, adds the stored "fe-identifier" and adds its own "fe-addr" to the "fe-identifier".

4.5.8.3 Tracking of applications generating charging information

Each application for which the hosting AS is generating charging events, includes the address or specific identifier of the AS within the "as-addr" element and the application identifier within the "ap-id" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field into the initial SIP request to be sent.

The final SIP response sent back by the last element of the operator domain supporting the "fe-identifier" header field contains the list of addresses and application identifiers received within the initial SIP request.

4.6 Support of local service numbers

For the IM CN subsystem, the support of local service numbers is provided by an AS in the subscriber’s home network as described in subclause 5.7.1.7.

4.7 Emergency service

4.7.1 Introduction

The need for support of emergency calls in the IM CN subsystem is determined by national regulatory requirements.

4.7.2 Emergency calls generated by a UE

If the UE cannot detect the emergency call attempt, the UE initiates the request as per normal procedures as described in subclause 5.1.2A. Depending on network policies, for a non-roaming UE or for a roaming UE where the P-CSCF is in the same network where the UE is roaming an emergency call attempt can succeed even if the UE did not detect that an emergency session is being requested, otherwise the network rejects the request indicating to the UE that the attempt was for an emergency service.

The UE procedures for UE detectable emergency calls are defined in subclause 5.1.6.

The P-CSCF, S-CSCF, IBCF, and E-CSCF procedures for emergency service are described in subclause 5.2.10, 5.4.8, 5.10.3.2 and 5.11, respectively.

Access dependent aspects of emergency service (e.g. whether the access technology defines emergency bearers, emergency registration support and location provision) are defined in the access technology specific annexes for each access technology.

There are a number of variants within these procedures and which variant gets used depends on a number of issues. These conditions are defined more specifically in 3GPP TS 23.167 [4B] and, where appropriate, in the access technology specific annex, but are summarised as follows:

a) if the UE knows that it is in its own home network, then an existing registration is permitted to be used for signalling the emergency call, except where item c) applies. The access technology specific annexes define the mechanism by which home network determination is made;

b) if emergency calls are permitted without security credentials (or additionally where the authentication is not possible or has failed), then the emergency call is made directly without use of any security association created by a registration, and therefore without the registration; and

c) where the access technology defines emergency bearers for the support of emergency calls, a new emergency registration is required so that these emergency bearers can be used for both signalling and media, unless an existing emergency registration exists on those emergency bearers.

4.7.3 Emergency calls generated by an AS

In certain circumstances an AS can identify that a request is an emergency call. This may relate to a request received from a UE (or subscription-based business trunking), or may be a call generated by an AS on behalf of a UE as far as the IM CN subsystem operation is concerned. These applications are outside the scope of this document to define.

Procedures in support of an AS initiating emergency calls are provided in subclause 5.7.1.14.

4.7.4 Emergency calls received from an enterprise network

An IBCF can also route emergency calls received from an enterprise network (peering-based business trunking) to an E-CSCF.

4.7.5 Location in emergency calls

A number of mechanisms also exist for providing location in support of emergency calls, both for routeing to a PSAP, and for use by the PSAP itself, in the IM CN subsystem:

a) by the inclusion by the UE of the Geolocation header field containing a location by reference or by value (see RFC 6442 [89]);

b) by the inclusion by the UE of a P-Access-Network-Info header field, which contains a cell identifier or location identitifier, which is subsequently mapped, potentially by the recipient, into a real location;

c) by the inclusion by the P-CSCF of a P-Access-Network-Info header field based on information supplied by either the PCRF or the NASS, and which contains a cell identifier or location identitifier, which is subsequently mapped, potentially by the recipient, into a real location;

d) by the allocation of a location reference that relates to the call by the LRF. Location is then supplied to the recipient over the Le interface (see 3GPP TS 23.167 [4B] for a definition of the Le interface) along with other call information. The LRF can obtain the location from entities outside the IM CN subsystem, e.g. by the e2 interface from the NASS (see ETSI TS 283 035 [98] or from the Gateway Mobile Location Centre (GMLC); and

e) by the inclusion by the S-CSCF of a P-Access-Network-Info header field based on information supplied by HSS, and which contains a location identitifier, which is subsequently mapped, potentially by the recipient, into a real location.

Mechanisms also exist for providing emergency-related information to a PSAP, in requests subsequent to routeing an initial request to a PSAP, in the IM CN subsystem:

a) by the inclusion by the UE of the Geolocation header field containing a location by reference or by value (see RFC 6442 [89]);

d) by the inclusion by the UE of the emergency-related information as specified in subclause 5.1.6.10;

f) by LRF requesting the location from the UE via E-CSCF as specified in subclause 5.12.3.2, subclause 5.11.4.3, subclause 5.11.4.4, subclause 5.11.5 and subclause 5.1.6.12.

The E-CSCF routes such a subsequent request to the PSAP using normal SIP procedures.

NOTE 1: Mechanisms independent from SIP for providing the emergency related information to a PSAP after session setup exist and are not listed. The use of such mechanisms is not precluded.

Which means of providing location is used depends on local regulatory and operator requirements. One or more mechanisms can be used. Location can be subject to privacy constraints.

NOTE 2: A similar variety of mechanisms also exists for normal calls, where location can be made use of by the recipient or by an intermediate AS, again subject to privacy constraints. The LRF is not involved in a normal call, but an AS can obtain location from the e2 interface from the NASS (see ETSI TS 283 035 [98] or from the Gateway Mobile Location Centre (GMLC).

4.7.6 eCall type of emergency service

A PSAP supporting eCall over IMS supports:

– receipt of the minimum set of emergency related data (MSD) in an INVITE or INFO request;

– the EmergencyCallData.eCall.MSD Info-Package and the ability to request an updated MSD by including an "application/EmergencyCallData.Control+xml" MIME body part containing a "request" element with an "action" attribute set to "send-data" and a "datatype" attribute set to "eCall.MSD" in an INFO request as defined in RFC 8147 [244];

– sending of an acknowledgement for an MSD received in an INVITE request by including, in the final response to the INVITE request, an "application/EmergencyCallData.Control+xml" MIME body part with an "ack" element containing a "received" attribute set to "true" or "false" and a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE, as defined in RFC 8147 [244];

– receipt of the MSD using audio media stream encoded as described in 3GPP TS 26.267 [9C];

– the ability to request an updated MSD using audio media stream encoded as described in 3GPP TS 26.267 [9C]; and

– the ability to request an updated MSD using audio media stream encoded as described in 3GPP TS 26.267 [9C], if the remote UA modifies an IMS emergency call of the eCall type of emergency service and stops supporting the EmergencyCallData.eCall.MSD Info-Package defined in RFC 8147 [244].

NOTE: The remote UA modifies an IMS emergency call of the eCall type of emergency service and stops supporting the EmergencyCallData.eCall.MSD Info-Package defined in RFC 8147 [244] when SRVCC access transfer takes place.

4.8 Tracing of signalling

4.8.1 General

IM CN subsystem entities can log SIP signalling, for debugging or tracing purposes, as described in 3GPP TS 32.422 [17A]. Debugging of SIP signalling is configured using the 3GPP IMS service level tracing management object (MO), specified in 3GPP TS 24.323 [8K]. This management object can provide configuration data to a UE or an S-CSCF, including in a visited network. Logging always begins with the initial request that creates a dialog and ends when a pre-configured stop trigger occurs or the dialog ends, whichever occurs first, as described in RFC 8497 [140] and configured in the trace management object defined in 3GPP TS 24.323 [8K].

4.8.2 Trace depth

The depth parameter in trace control and configuration indicates which SIP requests and responses are logged. If the trace depth is "maximum" then all requests and responses within a dialog or standalone transaction are logged. If the trace depth is "minimum" then all requests and responses except for non-reliable 1xx responses (including 100 (Trying) responses) and the ACK request are logged.

4.9 Overlap signalling

4.9.1 General

This subclause explains the overlap signalling impacts on the core entities of the IM CN subsystem.

The support of overlap signalling, and each of the overlap signalling method, within the IM CN subsystem, are optional and is dependent on the network policy.

Only one overlap signalling method shall be used within one IM CN subsystem.

NOTE: Interworking between the overlap signalling methods is not specified in this release.

4.9.2 Overlap signalling methods

4.9.2.1 In-dialog method

4.9.2.1.1 General

The in-dialog method uses INFO requests or INVITE requests in order to transport additional digits. Before an early dialog has been established, upon reception of a 404 (Not Found) or 484 (Address Incomplete) response to an earlier INVITE request, new INVITE requests will be sent to transfer additional digits (as specified in 3GPP TS 29.163 [11B]). Once an entity establishes an early dialog, by sending a provisional response to a INVITE request, INFO requests will be sent to carry additional digits on the early dialog.

The message body, and associated header values, which is used to carry additional digits in INFO requests is defined in 3GPP TS 29.163 [11B].

4.9.2.2 Multiple-INVITE method

4.9.2.2.1 General

The multiple-INVITE method uses INVITE requests with the same Call ID and From header in order to transport digits (as specified in 3GPP TS 29.163 [11B]).

4.9.3 Routeing impacts

4.9.3.1 General

If overlap dialing is supported, the IM CN subsystem needs to be configured in such a manner that erroneous routeing of INVITE requests with incomplete numbers towards others entities than the corresponding INVITE requests with full numbers is avoided, for instance towards a default destination for unknown numbers such as a PSTN. Possibly impacted nodes include the S-CSCF for the UE-originated case, the transit routeing function, the I-CSCF, and application servers.

A misrouteing can be avoided by configuring the entity sending overlap signalling in such a manner that it will send the first INVITE request with a sufficient number of digits to find a suitable entry in the translation database. If ENUM is used, the ENUM database in a typical deployment contains sufficient information about the first digits, as required to identify the destination IP domain. Therefore, ENUM is able to handle incomplete numbers in such deployments. As another alternative, the routeing entity can reject calls with unknown numbers with a 404 (Not Found) response, using entries in the routeing database to identify calls towards the PSTN. The S-CSCF for the UE-originated case could also forward calls with unknown numbers to the BGCF, if the BGCF is configured to reject calls to unknown destinations with a 404 (Not Found) response.

4.9.3.2 Deterministic routeing

If the multiple-INVITE method is used for overlap signalling, if an entity receives a INVITE request outside an existing dialog with the same Call ID and From header field as a previous INVITE request during a certain period of time, the entity shall route the new INVITE request to the same next hop as the previous INVITE request.

NOTE: INVITE requests with the same Call ID and From header fields received in sequence during a certain period of time belong to the same call. The routeing towards the same next hop could be achieved by an appropriately configured database or by the entity comparing the Call ID and From header fields of each INVITE request outside an existing dialog with Call IDs and "tag" From header field parameters of previous INVITE requests. If the entity compares the Call ID and From header field, it stores the information about received Call ID and From header fields at least for a time in the order of call setup times. If paths have been established at registration time, deterministic routeing will be automatic for entities on these paths.

4.9.3.3 Digit collection

Entities performing routeing decicisions may require additional digits for a decision where to route an INVITE request. These entities may interact with a routeing database to reach this decision.

If no suitable entry in a database is found for the digits received in a INVITE request, an entity can reject the INVITE request with a 404 (Not Found) or 484 (Address Incomplete) response. This method of digit collection can be performed by a SIP proxy and is suitable both for the in-dialog and multiple-INVITE overlap signalling methods. Replying with a 404 (Not Found) response avoids the need to keep apart uncomplete and unknown numbers. The 484 (Address Incomplete) response requires the recognition of incomplete numbers.

NOTE: An HSS does not support the recognition of incomplete numbers. A routeing database being queried by ENUM also does not support the recognition of incomplete numbers.

As an alternative for the in-dialogue method, the digit collection function described in annex N.2 may be invoked. It shall be performed by an entity acting as a B2BUA. The digit collection function requires the ability to recognise incomplete number.

4.10 Dialog correlation for IM CN subsystems

4.10.1 General

The Call-ID header field in combination with the tags in the From header field and in the To header field is the standard mechanism to identify SIP messages which belong to the same dialog. However the Call-ID header field is often changed by B2BUAs and other SIP intermediaries in the end-to-end message path.

To solve this problem, a Session-ID header field containing a globally unique session identifier, as defined in RFC 7989 [162], can be used to correlate SIP messages belonging to the same session. In the case of a concatenation of dialogs, the dialog correlation mechanism indicates that these dialogs belong to the same session.

The usage of the Session-ID header field is specified in annex A.

4.10.2 CONF usage

In case of the activation of a 3PTY conference, in the INVITE request to the CONF AS the Session-ID header field is added to the URIs in the URI list, in order to indicate the dialogs which are to be included to the 3PTY conference at the CONF AS, as described in 3GPP TS 24.147 [8B].

4.11 Priority mechanisms

In support of priority, the IM CN subsystem uses the mechanisms of RFC 4412 [116]. The request for prioritisation of a transaction / dialog may, for some deployments, be marked with the Resource-Priority header field by the UE. For other deployments, the request is not marked for priority by the UE, but the request is instead identified as a priority request and marked for priority (via a Resource-Priority header field) by a functional entity (e.g., P-CSCF) within the network. Subsequent to successful authorisation at an authorisation point (e.g. AS), request is considered to be authorised.

The characteristics of any priority scheme is defined by the namespace that is used. This determines how priority is applied to the SIP signalling, to the bearer carrying the SIP signalling, and to the bearers carrying any media. Different priority levels exist within each namespace. Priority levels in one namespace have no relationship to the priority levels in any other namespace, i.e. priority level "1" in namespace "A" may have an entirely different level and characteristic of priority treatment to an identically labelled priority level "1" in namespace "B".

A network can support multiple namespaces. It is up to the network operator (potentially based on regulatory or contractural obligations) to define the relationship between the priority mechanisms for each namespace, and indeed with calls that are not given any priority. It is normal that prioritised calls do not have access to 100% of any available resource and indeed are limited to a much lower figure. Priority is optional, and this document places no requirement on a conformant IM CN subsystem implementation to support priority, or indeed any namespace in a priority scheme. Regulators can however place their own requirements on an operator. Emergency transactions or dialogs (see subclause 4.7) can also have their own priority scheme.

RFC 4412 [116] specifies several resource priority namespaces. For example, certain national MPS implementations use resource priority namespaces of ETS (Emergency Telecommunications Service) and WPS (Wireless Priority Service).

Several ways of using priority exist, depending on the authorisation mechanism adopted. These are identified as follows. In each of these authorisation means authorisation to use the service, the namespace, and the priority level within that namespace:

1) Authorisation based on subscription in the IM CN subsystem only, priority requested by the UE using the Resource Priority header field. Whether the user is allowed to use priority or not, and the appropriate namespace and priority levels, is stored as part of the user profile in the HSS. As part of the reg event package subscription, this information is given to the P-CSCF when the contact information for any public user identity changes, and based on this information, the P-CSCF acts as the authorisation point for priority on individual requests. At the P-CSCF, when a Resource-Priority header field is received from the UE, if the requested priority equates to a value (namespace and priority level) that the P-CSCF knows is allowed for that public user identity, the priority is authorised.

2) Authorisation based on a database deployed by an AS; priority requested by the UE using a special dialstring. In this case the user requires no priority subscription information in the HSS. Specific dialstrings are configured in the P-CSCF. When a request is received from the UE by the P-CSCF, if the request contains a specific dialstring that is recognised by the P-CSCF as being eligible for priority treatment, the request is marked for temporary priority, subject to subsequent authorisation by an authorisation point (i.e., AS). And all such requests are routed to an AS. Final authorisation is granted by the AS, based on a PIN or password exchange with the UE. Subsequent requests or responses after authorisation are only given priority by the P-CSCF and S-CSCF if some backwards indication is received for that specific dialog. The definition of this backwards indication is outside the scope of this document (because non-standardised mechanisms have already been implemented in association with this approach).

3) Authorisation based on subscription in the IM CN subsystem and on a database deployed by an AS; priority requested by the UE using a special dialstring. Specific dialstrings are configured in the P-CSCF. When a request is received from the UE by the P-CSCF, if the request contains a specific dialstring that is recognised by the P-CSCF as being eligible for priority treatment, the request is marked for temporary priority, subject to subsequent authorisation by an authorisation point (i.e., AS). Based on iFC functionality that exists at the S-CSCF (from the users subscription in the HSS), such requests are routed to an AS. Final authorisation is granted by the AS, based on a PIN or password exchange with the UE or based on user profile. Subsequent requests or responses after authorisation are only given priority by the P-CSCF and S-CSCF if some backwards indication is received for that specific dialog. The definition of this backwards indication is outside the scope of this document (because non-standardised mechanisms have already been implemented in association with this approach).

Some administrations can require the use of multiple approaches in the same network.

For the cases of interworking with other networks, where the P-CSCF of the other network does not support priority, but it is intended or required to give users of that P-CSCF priority in the home network, provision is made for recognition of dialstrings by the IBCF and the S-CSCF. In such scenarios, when the IBCF or S-CSCF recognize that a request contains a dialstring as being eligible for priority treatment, the request is marked by the IBCF or S-CSCF for temporary priority, subject to subsequent authorisation by an authorisation point (i.e. AS). This mechanism does not have an impact on the network where the P-CSCF resides.

Where the network has a requirement to prioritise emergency calls, it can either perform this function by the use of the "esnet" namespace in the Resource-Priority header field (as defined in RFC 7135 [197]), or by recognition of the presence of the service URN relating to an emergency. Where the Resource-Priority header field is used for this purpose, it is inserted by the entity identifying the emergency call, i.e. the P-CSCF or the IBCF. There is no usage of this namespace from the UE, and when this namespace is used, the trust domain implementation is set to remove it if it occurs from the UE.

Where a network has requirements on attestation and signing of priority IMS sessions (e.g., MPS sessions) the Priority verification using assertion of priority information feature described in subclause 3.1 shall be supported and the Calling number verification using signature verification and attestation information feature described in subclause 3.1 may be supported.

Where the network has requirements on attestation and signing of originating calling identification information for emergency and emergency callback IMS sessions, and on authentication of a Resource-Priority header field and a header field value "psap-callback" of a Priority header field, Calling number verification using signature verification and attestation information and Priority verification using assertion of priority information features described in subclause 3.1 shall be supported.

4.12 Overload control

Usage of overload control is independent of the nature of any SIP using entity, i.e. there are no specific requirements for any particular IMS functional entity implementing SIP. The capability however is not extended to the UE except when performing the function of an externally attached network.

Two mechanisms are defined as follows:

– a feedback based mechanism defined in RFC 7339 [199], where the feedback is given in the Via header field of signalling messages supporting the traffic. RFC 7339 [199] also defines the default algorithm for usage of the feedback based mechanism in the IM CN subsystem (i.e. loss-based algorithm). Additional algorithms are either already defined, e.g. the rate-based scheme defined in RFC 7415 [200] or can also be defined in the future. As it is carried in the Via header fields the nature of the mechanism is hop by hop.

– an event package for distributing load filters defined in RFC 7200 [201], which can be either used in a hop-by-hop manner between adjacent entities in a similar manner to the feedback based mechanism, or can be used on a wider basis across the network, subject to the restrictions given in annex A. In this manner it can be used to address expected overload situations, e.g. for voting calls initiated by a specific television programme.

When the load filters based mechanism is used in the IMS, the default algorithm is loss-based (i.e. the filter specifies the relative percentage of incoming requests that can be accepted).

The S-CSCF, application servers and entities that implement the additional routeing capability can use both mechanisms in parallel on the same interfaces.

There are no specific reasons why one protocol mechanism should be specified over another, although some discussion is given in the documents specifying the mechanisms themselves. It is regarded as a deployment issue as to which mechanisms are supported, and which algorithms are supported within those mechanisms, beyond those that the mechanisms themselves identify as mandatory. An operator will need to take a network wide view to planning their overload control strategy, it cannot be performed on ad-hoc basis as nodes are deployed.

For the distribution of load filters mechanism, typical deployments might include an S-CSCF subscribing to the load control event package at an AS, an AS subscribing to the load control event package at an AS, and an entity hosting additional routeing capabilities as specified in subclause I.3 subscribing to the load-control event package at the AS.

Based on regional/national requirements and network operator policy, priority calls (e.g., multimedia priority service) are exempted from SIP overload controls up to the point where further exemption would cause network instability. Therefore, SIP messages related to priority calls have the highest priority, and are last to be dropped or rejected, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction. The interaction between SIP overload control and priority services is covered in RFC 7339 [199] and RFC 7200 [201].

Based on regional/national requirements and network operator policy, emergency calls are exempted from SIP overload controls up to a configured threshold. Therefore, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction due to overload control, SIP messages related to emergency calls are not dropped while the configured threshold regarding the amount of the ongoing emergency calls is not reached.

Mid-dialog SIP messages have higher priority with regard to initial SIP requests, and therefore are last to be dropped or rejected, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction due to overload control.

Operation between two network operators is supported. If two network operators wish to implement overload control, it is a matter for bilateral agreement as to what is supported.

Operation with enterprise networks is supported. The network operator and the enterprise operator will need to agree on the overload control options to be supported.

4.13 II-NNI traversal scenario

4.13.1 General

Within the IM CN subsystem, the signalling path between a calling user and a called user can be divided into one or more traffic legs, referred to as II-NNI traversal scenarios. Each II-NNI traversal scenario can span networks belonging to different operators and will have its own characteristics that can be different from other II-NNI traversal scenarios in the same call.

Dialog creating SIP requests and standalone requests can contain an "iotl" SIP URI parameter as specified in RFC 7549 [225] in a Request-URI or in one or more Route header fields. The "iotl" SIP URI parameter is appended to the URI representing the end of the II-NNI traversal scenario. The value of "iotl" SIP URI parameter can be used to identify the II-NNI traversal scenario.

If the "iotl" SIP URI parameter is not included in a dialog creating SIP requests or a standalone request, the II-NNI traversal scenario type can be determined by analysing the content of the SIP request or using a default II-NNI traversal scenario type.

NOTE: How the content of the SIP request can be used to determine the II-NNI traversal scenario is implementation dependent and outside the scope of this specification.

The "iotl" SIP URI parameter is included by the start of the II-NNI traversal scenario (e.g. P-CSCF, S-CSCF, BGCF or SCC AS) and removed by the end of the II-NNI traversal scenario (e.g. S-CSCF, TRF or P-CSCF).

4.13.2 Identifying the II-NNI traversal scenario

The "iotl" SIP URI parameter specified in RFC 7549 [225] containing traffic leg information can be used to identify the II-NNI traversal scenario type. The II-NNI traversal scenario type can be used by intermediary entities (e.g. IBCF and transit networks) to make policy decisions related to e.g. media anchoring, screening of SIP signalling, insertion of media functions (e.g. transcoder) and charging.

One example on how the "iotl" SIP URI parameter is included in the Route header field by the P-CSCF in a visited network when sending a request towards the home network is shown below.

EXAMPLE: Route: <sip:ibcf-vA1.visited-A.net;lr>,<sip:home-abc@scscf-hA1.home-A.net;lr:iotl=visitedA-homeA>

If neither the Request-URI nor any of the Route header fields included in the SIP request contains the "iotl" SIP URI parameter, the II-NNI traversal scenario type can be determined by analysing the content of the SIP request or using a default II-NNI traversal scenario type. The recommended II-NNI traversal scenario type default value is "homeA-homeB".

NOTE: How the content of the SIP request can be used to determine the II-NNI traversal scenario is implementation dependent and outside the scope of this specification.

4.13.3 Security aspects

When receiving a dialog creating SIP request or a standalone SIP request from outside the trust domain the IBCF acting as an entry point removes any "iotl" SIP URI parameter according to subclause 4.4.15 and assume the default II-NNI traversal scenario type or can use trusted elements of the SIP request to determine the II‑NNI traversal scenario type.

NOTE: Examples of trusted elements are protocol elements within the trust domain and protocol elements manipulated, checked or added by a previous hop secured by network domain security.

4.14 Restoration procedures

4.14.1 General

The present document includes optional restoration procedures for failure of P-CSCF and S-CSCF. The general mechanism is to inform the UE that one of the entities along its registration path is not working, and hence the UE needs to perform an initial registration. For systems providing access to IM CN subsystem using a GPRS IP-CAN, EPS IP-CAN or a 5GS IP-CAN, the mechanism to trigger the UE can be to use the Protocol Configuration Options IE or extended Protocol Configuration Options IE specified in 3GPP TS 24.008 [8], include an 3GPP IM CN subsystem XML body in a 504 (Server Time-out) response, or disconnect the PDN connection.

4.14.2 P-CSCF restoration procedures

P-CSCF restoration procedures are implemented in the S-CSCF, the IBCF and the UE.

When the UE originates a session it can detect that a P-CSCF is not reachable based on no response from the P-CSCF in which case the UE selects another P-CSCF if possible and performs a new initial registration.

UDM/HSS or HSS based P-CSCF restoration applies to UE terminating requests where the SIP entity neighbouring the P-CSCF (S-CSCF, IBCF) can detect that a P-CSCF is not reachable. When the neighbouring entity is the S-CSCF, the S-CSCF can in this case initiate the P-CSCF restoration. The S-CSCF sends an indication to the HSS to initiate the restoration. If the terminating user is roaming, the neighbouring entity is an entry IBCF which uses the Restoration-Info header field to inform the S-CSCF about the failure in a 408 (Request Timeout) response for INVITE requests or a 504 (Server Time-out) response for non-INVITE requests and the S-CSCF can send an indication to the HSS to initiate the restoration.

PCF or PCRF based P-CSCF restoration applies to UE terminating INVITE requests. For PCF or PCRF based P-CSCF restoration the S-CSCF uses the Restoration-Info header field to send the IMSI in initial INVITE requests to an alternative P-CSCF. When the user is roaming, the IBCF selects an alternative P-CSCF and forwards the IMSI of the terminating user in a Restoration-Info header field.

Restoration can also be initiated when the P-CSCF has restarted, and lost all bindings for a particular user. In this case the P-CSCF rejects the incoming request with a 404 (Not Found) response. If the home network applies UDM/HSS or HSS based P-CSCF restoration the S-CSCF initiates the restoration procedure by sending an indication to the HSS. If PCF or PCRF based restoration is used, the S-CSCF initiate the PCF or PCRF based P-CSCF restoration procedure for the served user by including the IMSI in a Restoration-Header field included in an initial INVITE request.

NOTE: In the rest of the present document where the "PCRF based P-CSCF restoration" procedure is mentioned the "PCF based P-CSCF restoration" procedure also applies, and where the "HSS based P-CSCF restoration" procedure is mentioned the "UDM/HSS based P-CSCF restoration" procedure also applies.

4.14.3 S-CSCF restoration procedures

The P-CSCF can inform the UE about S-CSCF failures in a 504 (Server Time-out) response using the 3GPP IM CN subsystem XML body defined in subclause 7.6, in accordance with subclause 5.2.6.3.2A, when the P-CSCF is unable to forward a request to an S-CSCF.

When the S-CSCF receives a request initiated by the served user for which the S-CSCF does not have the user profile or does not trust the data that it has (e.g. due to restart) the S-CSCF can if it fails to retrieve the data from the HSS trigger a registration by sending a 504 (Server Time-out) response using the 3GPP IM CN subsystem XML body defined in subclause 7.6 to the UE, in accordance with subclause 5.4.3.2.

An I-CSCF can reselect S-CSCF if the previously selected S-CSCF is not available.

If an IBCF acting as an entry point in the originating home network cannot forward the request the IBCF can trigger the UE to perform initial registration by including the 3GPP IM CN subsystem XML body in a 504 (Server Time-out) response, in accordance with subclause 5.10.3.5.

4.15 Resource sharing

Resource sharing allows two or more sessions to use the same resources for one or more media streams in uplink, downlink or both uplink and downlink direction.

A P-CSCF that supports resource sharing can determine that there is a potential for resource sharing based on local configuration or defer the determination of potential resource sharing to an AS in the home network.

If the determination of potential resource sharing is deferred to an AS in the home network:

– the P-CSCF on the originating side indicates that resource sharing is supported in the initial REGISTER request in the Resource-Share header field defined in subclause 7.2.13. The Resource-Share header field is included in the third-party REGISTER request towards the AS; and

– if the "message/sip" MIME body in the third-party REGISTER request included the Resource-Share header field with the value "supported", the AS in the home network includes the Resource-Share header field containing the rules for resource sharing in responses and requests towards the P-CSCF.

If the rules for resource sharing are updated, the updated rule will be sent to P-CSCF in one of the sessions that share resources. The updated resource sharing rules will then be applied for all sessions that are sharing resources.

NOTE: In this release of the technical specification the UE cannot indicate support of resource sharing. However, the Resource-Share header field is not removed from requests and responses towards the UE and the UE can use the information in the header field to adapt its behaviour according to the information.

4.16 Priority sharing

Priority sharing allows two or more sessions with different priority to share the same bearer.

The determination of the use of priority sharing is deferred to an AS in the home network:

1) if P-CSCF supports priority sharing and if according to local policy, the P-CSCF indicate that priority sharing is supported by including the g.3gpp.priority-share feature-capability indicator defined in subclause 7.9A.10 in a Feature-Caps header field in the REGISTER request;

NOTE: The Feature-Caps header field with the g.3gpp.priority-share feature-capability indicator is included in the "message/sip" MIME body in the third-party REGISTER request sent over the ISC interface.

2) if the "message/sip" MIME body in the third-party REGISTER request included the g.3gpp.priority-share feature-capability indicator and:

a) if the AS determined to enable priority sharing, the AS includes the Priority-Share header field with a value "allowed" in a request or response sent towards the P-CSCF; or

b) if the AS determined to disable priority sharing, the AS includes the Priority-Share header field with a value "not-allowed" in a request or response sent towards the P-CSCF.

4.17 3GPP PS data off

The UE and the network can support the 3GPP PS data off.

When 3GPP PS data off is supported and active, IP packets that are associated with services that are not a 3GPP PS data off exempt service are prevented from transport over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN as specified in 3GPP TS 23.228 [7]. The UE may be configured by the HPLMN, the EHPLMN or the subscribed SNPN with up to two indications whether a 3GPP IMS service is a 3GPP PS Data Off exempt service, one indication is valid when the UE is in the HPLMN, the EHPLMN, or a subscribed SNPN and the other indication is valid when the UE is in the VPLMN or, if the UE supports access to an SNPN using credentials from a CH, a non-subscribed SNPN. When the UE is only configured with the indication valid for the UE camping in HPLMN the EHPLMN or a subscribed SNPN, the UE shall use this indication also when the UE is in the VPLMN or the non-subscribed SNPN.

When 3GPP PS data off is supported and active and the UE is configured, either as specified in 3GPP TS 24.167 [8G] or in 3GPP TS 31.102 [15C], with services that are 3GPP PS data off exempt, then the UE will not send uplink IP packets related to any services that are not 3GPP PS data off exempt over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN. The UE informs the network about its 3GPP PS data off status by including a g.3gpp.ps-data-off media feature tag specified in subclauce 7.9.8 in all REGISTER requests sent over GPRS IP-CAN, EPS IP-CAN or 5GS IP-CAN. The UE reregisters over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN every time the 3GPP PS data off status is changed or the UE is provided by the network with a new list of 3GPP PS data off exempt services while the 3GPP PS data off status is "active".

An AS handling a service is configured with information whether the service is a 3GPP PS data off exempt service. If the 3GPP PS data off status is active and the service is not a 3GPP PS data off exempt service, the AS prevents downlink IP packets of the service from reaching the UE over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN. The AS shall be configured with up to two indications whether a 3GPP IMS service is a 3GPP PS Data Off exempt service, one indication is valid for non-roaming users, and the other indication is valid for users roaming in the various VPLMNs with whom roaming agreements exist or users accessing non-subscribed SNPNs. When the AS is only configured with the indication valid for the UE camping in the HPLMN, the EHPLMN or the subscribed SNPN, the AS shall use this indication also when the UE is in the VPLMN or non-subscribed SNPN.

4.18 Dynamic Service Interaction

Dynamic Service Interaction allows that different ASs involved in the same IMS session (within an operator network or across networks) exchange information about executed services to avoid conflicting interactions between these services. Dynamic Service Interaction information is included in a SIP header field Service-Interact-Info defined in subclause 7.2.14.

If an AS which supports dynamic service interaction:

– provides one or more services:

a) the AS inserts in a SIP message the Service-Interact-Info header field with the identities of the services which have been performed; and

b) if the AS identified services which should be further avoided the AS adds the identities of those services in the Service-Interact-Info header field; and

– receives a SIP message containing the Service-Interact-Info header field, the AS takes the received Service-Interact-Info header field information into account as described in subclause 7.2.14.3.

4.19 Restricted Local Operator Services

The UE and the network can support Restricted Local Operator Services (RLOS).

RLOS services are operator defined services that are offered to UEs when using an EPS IP-CAN as specified in annex L in the following scenarios:

– UE is successfully registered using IMS AKA or GPRS-IMS bundled authentication; or

– UE has attempted to register and the registration is rejected from the network with a 403 (Forbidden) response.

RLOS services are offered only for the UE-originating case.

RLOS services can be offered to an operator’s own subscribers and roaming subscribers.