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

24.6083GPPProtocol specificationRelease 17Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR) using IP Multimedia (IM) Core Network (CN) subsystemTS

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

4.1 Introduction

The Terminating Identification Presentation (TIP) service provides the originating party with the possibility of receiving identity information in order to identify the terminating party.

The network shall deliver the Terminating Identity to the originating party on communication acceptance regardless of the terminal capability to handle the information.

The Terminating Identification Restriction (TIR) is a service offered to the connected party which enables the connected party to prevent presentation of the terminating identity information to originating party.

4.2 Description

4.2.1 General description

The Terminating Identification Presentation (TIP) service provides the originating party with the possibility of receiving trusted information in order to identify the terminating party.

The Terminating Identification Restriction (TIR) is a service offered to the terminating party which enables the terminating party to prevent presentation of the terminating identity information to originating party.

4.3 Operational requirements

4.3.1 Provision/withdrawal

4.3.1.1 TIP provision/withdrawal

The TIP service may be provided after prior arrangement with the service provider or be generally available.

The TIP service shall be withdrawn at the subscriber’s request or for administrative reasons.

As a general operator policy a special arrangement may exist on a per subscriber basis or on a general behaviour basis whereby the terminating user’s identity information intended to be transparently transported by the network is not screened by the network.

4.3.1.2 TIR provision/withdrawal

The TIR service, temporary mode, may be provided on a subscription basis or may be generally available.

The TIR service, permanent mode, shall be provided on a subscription basis.

As a network option, the TIR service can be offered with several subscription options. A network providing the TIR service shall support temporary mode at a minimum. Subscription options are summarized in table 1.

Table 1: TIR subscription options

Subscription option values

Values

Mode

‑ permanent mode (active for all requests)

‑ temporary mode (specified by the user per request)

Temporary mode default

‑ presentation restricted

‑ presentation not restricted

4.3.2 Requirements on the originating network side

For originating users that subscribe to the TIP service, if network provided identity information about the terminator is available, and if presentation is allowed, the network shall include that information in the responses sent to the user.

If the presentation of the network asserted identity is restricted due to the TIR service, then the originating user shall receive an indication that the network provided identity was not sent because of restriction.

If the network asserted identity information is not available at the originating network (for reasons such as interworking), then the network shall indicate to the originating user that the network asserted identity information was not included for reasons other than restriction.

As a national option, the originating AS can override the presentation restriction indication and the terminating identity is then presented to the originating subscriber for specific originating access’s categories (e.g. police).

NOTE 1: The priv-value "id" in the Privacy header field is not expected be removed when removing any P-Asserted-Identity header field as described in 3GPP TS 24.229 [2].

NOTE 2: Annex B provides an example of an initial filter criterion that can be applied for the TIP/TIR service.

NOTE 3: It is assumed that the IBCF is responsible for stripping the P-Asserted‑Identity from the SIP header when interworking with untrusted networks.

4.3.3 Requirements on the terminating network side

As part of the basic communication control procedures specified in 3GPP TS 24.229 [2], the following requirements apply at the terminating network side in support of the TIP service and the TIR service. Unless noted otherwise, these requirements are meant to apply to responses where the presence of the P-Asserted-Identity and Privacy header fields are allowed. These procedures apply regardless of whether the originating or terminating parties subscribe to the TIP service or the TIR service.

The terminating network shall include network asserted identity information in responses where allowed by
3GPP TS 24.229 [2]. For TIR subscribers:

– The terminating user may include an indication that it wishes to have the presentation of its identity information restricted, in any response where allowed by 3GPP TS 24.229 [2].

– If the terminating user has subscribed to the TIR service in the permanent or temporary mode, then the network shall invoke the TIR service for every incoming request.

NOTE 1: The above requirement needs appropriate configuration of the initial filter criteria.

If the TIR service is not invoked, the network-provided identity shall be considered to be presentation allowed.

NOTE 2: Annex B provides an example of an initial filter criterion that that can be applied for the TIP/TIR service.

NOTE 3: It is assumed that the IBCF is responsible for stripping the P-Asserted-Identity from the SIP header when interworking with untrusted networks.

4.4 Syntax requirements

The syntax for the relevant header fields in the SIP requests and SIP responses shall be as follows:

– The syntax of the P-Asserted-Identity header field shall conform to the requirements in 3GPP TS 24.229 [2] (IETF RFC 3325 [6] and IETF RFC 3966 [8]).

– The syntax of the Privacy header field shall conform to the requirements in 3GPP TS 24.229 [2] (IETF RFC 3323 [5] and IETF RFC 3325 [6]).

– The Syntax of the option tag "from-change" shall conform to the requirements in IETF RFC 4916 [17]

4.5 Signalling procedures

4.5.0 General

Configuration of supplementary services by the user should:

– take place over the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [15]; or

– use SIP based user configuration as described in 3GPP TS 24.238 [19].

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the operator are outside the scope of the present document, but are not precluded

The enhancements to the XML schema for use over the Ut interface are described in subclause 4.9.

4.5.1 Activation/deactivation

The TIP service is activated at provisioning and deactivated at withdrawal.

The TIR service is activated at provisioning and deactivated at withdrawal.

4.5.1A Registration/erasure

The TIP service requires no registration. Erasure is not applicable.

The TIR service requires no registration. Erasure is not applicable.

4.5.1B Interrogation

For interrogation of TIP and TIR, the mechanisms specified in subclause 4.5.0 should be used.

4.5.2 Invocation and operation

4.5.2.1 Actions at the originating UE

A UE that supports the TIP service signalling procedures shall support the receipt, in SIP responses to SIP requests initiating a dialog or for standalone transactions, one or more P-Asserted-Identity headers, each one containing a network-provided identity information of the terminating user.

If no P-Asserted‑Identity header fields are present, but a Privacy header field set to "id" was present, then the
network-provided identity information was withheld due to presentation restriction.

If neither P-Asserted-Identity header fields nor a Privacy header fields set to "id" are present, then the network-provided identity information was not available (due, for example, to interworking with other networks).

Once a 2xx response is received, the P-Asserted-Identity header field of the first 2xx response is used, e.g. when presenting the identity to the user.

NOTE 1: Any P-Asserted-Identity received in a provisional response is outside the scope of this service.

If the originating user is subscribed to the TIP services and wants to receive changes of the terminating identity in the dialog the UE shall add the option tag "from-change" to the Supported header field in the initial request.

NOTE 2: This option tag is used to indicate that a UA supports changes to URIs in From and To header fields during a dialog. Not setting this indication shows that the UE is not supporting this procedure.

4.5.2.2 Void

4.5.2.3 Void

4.5.2.4 Actions at the AS serving the originating UE

If the originating user is subscribed to the TIP service the AS shall pass the option tag "from-change" in the Supported header field in the initial request if received from the originating user.

If the originating user is not subscribed to the TIP service the AS shall remove the option tag "from-change".

NOTE 1: If the terminating user requests privacy the S-CSCF or PCSCF removes the P-Asserted-Identity header field as part of the basic communication procedures defined in 3GPP TS 24.229 [2].

If an originating user does not subscribe to the TIP service, any P-Asserted-Identity header fields or Privacy header fields included in the SIP response shall be removed. As a network option, if the originating user has an override category, the AS shall send the P-Asserted-Identity headers and remove the Privacy header fields.

When the Privacy header field is set to "id", with the exception of the cases listed above, the AS should not remove this Privacy header entry.

NOTE 2: The priv-value "id" in the Privacy header will be used by the originating UE to distinguish the request of TIR by the terminating user.

4.5.2.5 Void

4.5.2.6 Void

4.5.2.7 Void

4.5.2.8 Void

4.5.2.9 Actions at the AS serving the terminating UE

For a terminating user who subscribes to the TIR service in "permanent mode", if a SIP response to a SIP request includes a Privacy header field that is set to "none", the AS shall remove the "none" value from the Privacy header field. The AS shall insert a Privacy header field set to "id" if not already present.

For a terminating user who subscribes to the TIR service in "permanent mode", if an INVITE request with a Supported header field including an option tag "from-change" is received, the AS shall remove the option tag "from-change".

For a terminating user who subscribes to the TIR service in "temporary mode" with default set to "restricted", if a SIP response to a SIP request does not include a Privacy header field, the AS shall insert a Privacy header field set to "id".

For a terminating user who subscribes to the TIR service in "temporary mode" with default set to "not restricted" normal procedures apply.

As a terminating network option, if the "no screening" special arrangement does not exist with the terminating user and an UPDATE request is received from the terminating user, then the AS may attempt to match the information in the From header with the set of registered public user identities for the served user. If no match is found, the AS may change the value of the From header in the UPDATE request to the public user identity of the served user.

4.5.2.10 Void

4.5.2.11 Void

4.5.2.12 Actions at the terminating UE

A terminating UE receiving an initial request including a Supported header field with the option tag "from-change" and supporting the "from-to" change shall send within a provisional or final response the Supported header with the option tag "from-change".

A terminating UE receiving an initial request including a Supported header field with the option tag "from-change" may send a UPDATE request with a updated from and to header according the rules of IETF RFC 4916 [17].

The destination UE, if the terminating user wishes to override the default setting of "presentation not restricted" of the TIR service in temporary mode, shall include a Privacy header with privacy type of "id" in any non-100 responses it sends upon receipt of a SIP request.

The destination UE , if the terminating user wishes to override the default setting of "presentation restricted" of the TIR service in temporary mode, shall include a Privacy header with privacy type of "none" in any non-100 responses it sends upon receipt of a SIP request.

NOTE: It is assumed that TIR subscribers support IETF RFC 3325 [6].

4.6 Interaction with other services

4.6.1 Communication session Hold (HOLD)

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

4.6.2 Terminating Identification Presentation (TIP)

The TIR service shall normally take precedence over the TIP service. The TIP service can take precedence over the TIR service when the originating user has an override category. This is a national matter, the operation of which is outside the scope of the present document.

4.6.3 Terminating Identification Restriction (TIR)

4.6.4 Originating Identification Presentation (OIP)

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

4.6.5 Originating Identification Restriction (OIR)

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

4.6.6 Conference (CONF)

Conference controller: no impact, i.e. neither service shall affect the operation of the other service.

Participants in a conference shall not receive the TIP service information of participants being added to the conference.

4.6.7 Communication DIVersion services (CDIV)

In case of the TIP service if the served (forwarding/deflecting) user selects the option that the originating user is not notified of communication diversion, then the originating user shall receive no diversion notification. In addition, the originating user shall not receive the terminating user’s identity information when the communication is answered, unless the originating user has override capability.

In case of the TIP service if the served (forwarding/deflecting) user selects the option that the originating user is notified, but without the diverted‑to address, then the originating user shall not receive the terminating user’s identity information when the communication is answered, unless the originating user has override capability.

If a diverted-to user subscribes to the TIR service "permanent mode", then the diverted-to user’s URI shall not be provided with the notification that the communication has been diverted.

If a diverted-to user subscribes to the TIR service "temporary mode", then the diverted‑to user’s URI shall not be provided until negotiation with the user has taken place and a positive indication from the user has been received.

In each of the above situations, a originating user that subscribes to the TIP service and who has override capability will not receive the diverted-to user’s number as part of the diverting notification information, but can use the override capability in order to receive the terminating identity information when the communication is answered.

4.6.8 Malicious Communication IDentification (MCID)

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

4.6.9 Enhanced Calling Name (eCNAM)

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

4.6.10 Multi-Device (MuD)

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

4.6.11 Multi-Identity (MiD)

No impact on the TIR service. The TIR service handles the Privacy header field following the procedures in this specification.

No impact on the TIP service.

4.7 Interactions with other networks

4.7.1 Void

4.7.2 Void

4.7.3 Void

4.8 Parameter values (timers)

Void

4.9 Service configuration

4.9.0 General

Terminating Identity documents are sub‑trees of the simservs XML document specified in 3GPP TS 24.623 [15]. As such, Terminating Identity documents use the XCAP application usage in 3GPP TS 24.623 [15].

Data semantics: The semantics of the Terminating Identity XML configuration document is specified in subclause 4.9.1.

XML schema: Implementations in compliance with the present document shall implement the XML schema that minimally includes the XML Schema defined in subclause 4.9.2 and the simservs XML schema specified in subclause 6.3 of 3GPP TS 24.623 [15].

An instance of an Terminating Identity document is shown:

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

<terminating-identity-presentation active="true"/>

<terminating-identity-presentation-restriction active="true">

<default-behaviour>presentation-restricted</default-behaviour>

</terminating-identity-presentation-restriction>

</simservs>

4.9.1 Data semantics

The TIP service can be activated/deactivated using the active attribute of the <terminating‑identity‑presentation> service element.

The TIR service can be activated/deactivated using the active attribute of the <terminating‑identity‑presentation‑restriction> service element. Activating the TIR service this way activates the temporary mode TIR service. When deactivated and not overruled by operator settings, basic communication procedures apply.

The behaviour of the temporary mode TIR is configured with the optional <default‑behaviour> element. There are two values that this element can take:

– Presentation-restricted: configures the service to behave as specified in subclause 4.5.2.9 for the case TIR service in "temporary mode" with default "restricted".

– Presentation-not-restricted: configures the service to behave as specified in subclause 4.5.2.9 for the case TIR service in "temporary mode" with default "not restricted".

Authorization for manipulation of the active attribute of the <terminating‑identity‑presentation> service element and of the <terminating‑identity‑presentation‑restriction> service element is subject to local policy. Unauthorized manipulation attempts are rejected with an HTTP 409 (Conflict) response as defined in IETF RFC 4825 [20].

4.9.2 XML schema

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

<xs:schema xmlns:ss="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://uri.etsi.org/ngn/params/xml/simservs/xcap" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="terminating-identity-presentation-restriction" substitutionGroup="ss:absService">

<xs:annotation>

<xs:documentation>Terminating Identity presentation Restriction

</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:complexContent>

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

<xs:sequence>

<xs:element name="default-behaviour" default="presentation-restricted" minOccurs="0">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="presentation-restricted"/>

<xs:enumeration value="presentation-not-restricted"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

<xs:element name="terminating-identity-presentation" type="ss:simservType" substitutionGroup="ss:absService">

<xs:annotation>

<xs:documentation>Terminating Identity Presentation

</xs:documentation>

</xs:annotation>

</xs:element>

</xs:schema>

Annex A (informative):
Signalling flows

No signalling flows are provided.

Annex B (informative):
Example of filter criteria

This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria evaluation.