4 Enhanced Calling Name (eCNAM)

24.1963GPPEnhanced Calling Name (eCNAM)Release 17TS

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

4.1 Introduction

The eCNAM service provides the terminating user with the name associated with the originating user and optionally delivers metadata about that originating user. While eCNAM is a terminating service, the eCNAM operations rely on information received from the originating network, such as the originating user’s E.164 telephone number (TN) to retrieve eCNAM data from trusted data sources (via methods outside the scope of this specification).

4.2 Service Description

4.2.1 General Description

The eCNAM service provides the terminating user with a name that identifies the originating user, and metadata about that originating user (e.g., address, language).

NOTE: The terminating service provider retrieves the name and metadata from pre-selected data sources. The terminating service provider can also partner with analytics providers that offer risk indicators about the incoming call (e.g., known perpetrators of scams) as part of the metadata eCNAM delivers.

To retrieve eCNAM data, the service provider formulates queries using a searchkey to retrieve the name and metadata. The searchkey is a user identity obtained from the incoming SIP INVITE. Most commonly, the service provider uses an E.164 TN as that searchkey. Other identities could be used to retrieve the eCNAM data.

If the terminating network determines that the telephone number’s (or other identity’s) presentation is restricted (i.e., not to be presented to the end user), the eCNAM data will also be restricted.

If the terminating network determines that the telephone number (or other identity’s) presentation is not restricted (i.e., to be presented to the end user), the eCNAM data will also be presented to the end user with no restriction.

4.3 Operational Requirements

4.3.1 Provision/withdrawal

The eCNAM service can be provided after prior arrangement with the service provider.

The eCNAM service can be withdrawn at the subscriber’s request or for administrative reasons.

4.3.2 Requirements on the Originating Network

eCNAM is a terminating service, however, the eCNAM operations rely on information received from the originating network.

If the originating user identity, such as the originating user’s E.164 TN, is not delivered by the originating network to the terminating network, the terminating service provider will not be able to retrieve eCNAM data from the relevant data sources.

NOTE: The searchkey element necessary for retrieving eCNAM data from the relevant data source is, in most cases, restricted to the originating user’s E.164 TN for most databases. However, other user identities can be used as searchkey elements.

The originating network can support a verification capability, such as the number verification capability described in 3GPP TS 24.229 [2]. Without a verification capability at the originating network, the integrity of the eCNAM data retrieved could be impacted.

4.3.3 Requirements on the Terminating Network

4.3.3.1 Data Sources

The eCNAM service involves the retrieval of the name data and the additional caller information from data sources that the terminating service provider has access to, based on service provider policy.

The special arrangements and interfaces between the terminating service provider and the data sources are outside the scope of this document and are subject to operator procedures.

NOTE 1: The accuracy of the name information and the metadata about the caller varies among sources; therefore, the terminating service provider exercises a choice of which source to use. The interfaces and protocols used to retrieve the data are typically negotiated between the terminating service provider and the data source.

NOTE 2: The terminating service provider pre‑determines the elements of metadata that will be delivered on each call to eCNAM subscribers. The set of metadata varies from one service provider to another.

4.4 Syntax Requirements

The syntax for the header fields are normatively described in 3GPP TS 24.229 [2]. The relevant headers are:

– The P‑Asserted‑Identity header field which shall conform to the specifications in RFC 3325 [5] and RFC 3966 [7].

– The Identity header field which shall conform to the specifications in RFC 8224 [9].

– The Call-Info header field which shall conform to the specifications in RFC 3261 [3].

– The Privacy header field which shall conform to the specifications in RFC 3323 [6] and RFC 3325 [5].

NOTE: The privacy level "session" and "critical" are not used in this specification.

– The From header field which shall conform to the specifications in RFC 3261 [3] and RFC 3966 [7].

4.5 Signalling Procedures

4.5.1 General

Configuration of the eCNAM is performed by the service provider.

4.5.2 Activation/Deactivation

The service provider activates the eCNAM service at provisioning, upon the user’s request.

The service provider deactivates the service at withdrawal upon the user’s request.

No user configuration is defined in this release.

4.5.3 Invocation and Operation

4.5.3.1 Actions at the Originating UE

No actions at the originating UE.

4.5.3.2 Actions at the AS serving the Originating UE

No actions at the AS serving the originating UE.

4.5.3.3 Actions at the AS serving the Terminating UE

4.5.3.3.1 Identity not available

eCNAM is a terminating service; however, the eCNAM operations rely on information received from the originating network.

If the incoming INVITE does not include the user’s E.164 TN in the "tel" URI or the ‘user element’ of the SIP URI, the terminating AS will not be able to retrieve eCNAM data from the relevant data sources. Based on service provider policy, the AS uses the E.164 TN in either the incoming From header field or the incoming P-Asserted-Identity header field to request eCNAM data from the trusted data sources.

If this information is not received in the incoming INVITE or is not available from the data sources (missing data or query timeouts) then the terminating AS shall consider the eCNAM data unavailable.

As a result, the terminating AS shall, according to local policy, populate the text string "Unavailable" in the "display-name" parameter of the outgoing From header field and/or P-Asserted-Identity header field in the SIP INVITE request that the terminating AS sends to the terminating UE.

If some elements of the eCNAM metadata are unavailable (e.g., requested data elements could not be found in the data source), the terminating AS shall deliver the available data to the terminating UE in Call-Info header fields, and shall not deliver the string "unavailable" for the missing elements.

4.5.3.3.2 Identity available, presentation not allowed

If the terminating AS receives a Privacy header field set to any of the priv-values "id", "user" or "header" (i.e., presentation is not allowed), then the terminating AS shall populate the text string "Anonymous" in the "display-name" parameter of the From header field in the SIP INVITE request that the AS sends to the terminating UE. The full SIP URI for Anonymous User Identity is described in 3GPP TS 23.003 [4].

The metadata may be sent to the terminating UE, based on service provider policy.

NOTE: The service provider may allow delivery of only the metadata (such as analytics), if allowed by local and national policies to caution users against fraudsters disguised with anonymous identities.

4.5.3.3.3 Identity available, originating user identity verified and passed, presentation allowed

The terminating AS shall consider that the user identity presentation is allowed when there is no Privacy header field in the received INVITE or a Privacy header field set to priv-value "none".

If the identity presentation is allowed and the result of the originating user identity verification performed (such as the verification resulting in the "verstat" tel URI parameter described in 3GPP TS 24.229 [2]) shows the verification passed, the AS shall proceed to retrieve eCNAM data from the trusted sources.

The AS shall extract the originating identity from the incoming INVITE in order to formulate the query to the trusted data sources. It is based on service provider policy to decide whether the identity retrieved from the P-Asserted-Identity header field, the From header field or both with a priority order.

If the chosen identity is the E.164 TN, the following procedures shall apply:

1 The terminating AS shall extract the TN from the username portion of the incoming SIP URI request of the incoming From header field or P-Asserted-Identity header field, if user=phone parameter is present.

2 If user=phone is not present in the SIP URI, the terminating AS shall extract the TN from the tel URI of the incoming From header field or P-Asserted-Identity header field.

3 If both a SIP URI with user=phone present, and a tel URI are available, the terminating AS shall extract the TN from the tel URI of the incoming From header field or P-Asserted-Identity header field.

4 The terminating AS will query the appropriate data source(s) using the extracted TN.

NOTE 1: The labels/titles of the data elements are known to the terminating service provider based on their arrangements with the data sources.

NOTE 2: Semantic translation is outside the scope of the present document.

NOTE 3: In addition to plain text, the Call-Info header field supports the delivery of icons, which may be needed if analytics results include symbols to be displayed on the UE.

The terminating AS shall populate the received name (retrieved from data sources) in the "display‑name" parameter of the From header field or the P-Asserted-Identity header field in the INVITE request being sent to the UE.

The terminating AS shall populate the received metadata elements in one or more Call-Info header fields.

NOTE 4: The eCNAM metadata elements can include information about the caller’s language, address, email, or type of business and more. The metadata can also include the results of analytics that the service provider makes available to the user directly or through third party affiliations. The analytics can contain text and icons about the originating user.

If other name information is received in the INVITE request , the terminating service provider local policy shall apply. The AS may discard the received name data.

4.5.3.3.4 Identity available, verification failed

If the originating user identity verification performed (such as the verification resulting in the "verstat" tel URI parameter described in 3GPP TS 24.229 [2]) shows that verification failed, the terminating AS may deliver partial or no eCNAM information to the subscriber’s UE.

As a result, and based on terminating service provider policy, the terminating AS may perform one or more of the following actions:

a) The AS may remove the display‑name of the From header field or the P-Asserted-Identity header field in the INVITE request being sent to the UE;

b) The AS may populate a text string of the terminating service provider’s choice in the display‑name of the From header field or the P-Asserted-Identity header field in the INVITE request being sent to the UE. Examples of such strings include "Suspected Spam" or "Fake Number";

c) The AS may populate graphical symbols of the service provider’s choice in one or more Call-Info header field(s) to the terminating UE. Examples include warning symbols and text.

4.5.3.4 Actions at the Terminating UE

The terminating UE shall support the receipt of one or more P-Asserted Identity header fields.

The terminating UE shall retrieve the originating user’s name from the "display-name" parameter of the P-Asserted Identity header field or the "display-name" parameter of the From header field depending on the header used for determining the originating party identity.

NOTE 1: The data sources queried for metadata are typically local to the service provider, and therefore are populated with data represented in the same language as the subscriber’s. Therefore, semantic translation is not likely to be needed. UEs can offer semantic translation of the display as an individual, manufacturer-based capability. Semantic translation is outside the scope of the present document.

The UE shall support receipt of one or more Call-Info header fields.

The terminating UE shall retrieve the metadata of the originating user from the Call-Info header fields.

NOTE 2: UEs can support capabilities such as text-to-speech for the blind, as well as ensuring that messages delivered in colours intended for warnings be relayed in a different method to accommodate colour-blind users.

4.6 Interaction with other Services

4.6.1 Originating Identification Presentation (OIP)

For users that subscribe to both OIP and eCNAM, and subject to service provider policy, the name information retrieved through eCNAM may override any name information available via OIP.

Subject to service provider policy, eCNAM metadata and other OIP data may both be presented to the end user with or without individual marking to distinguish the eCNAM service data from other call information.

4.6.2 Originating Identification Restriction (OIR)

The OIR service shall take precedence over the eCNAM service.

4.6.3 Terminating Identification Presentation / Terminating Identification Restriction (TIP/TIR)

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

4.6.4 Advice of Charge

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

4.6.5 Communication Waiting (CW)

If a terminating party has the eCNAM service active and is notified that an incoming communication is waiting, then this terminating user shall receive the eCNAM data on the incoming session, if presentation is not restricted on that incoming session.

4.6.6 Communication Hold

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

4.6.7 Explicit Communication Transfer (ECT)

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

4.6.8 Closed User Group (CUG)

In general, CUG members do not communicate with users outside the group. However, if members were allowed to activate eCNAM and to receive calls from outside the group, then eCNAM data will be delivered based on the caller’s OIR status.

4.6.9 Completion of Communications to Busy Subscriber (CCBS)

The originating party’s eCNAM data shall be transmitted to the CCBS customer’s UE when the terminating party becomes free, and a CCBS communication is generated to the terminating party.

4.6.10 Communication Diversion (CDIV)

Subject to service provider policy, the terminating AS serving the diverted to user may optionally deliver the eCNAM data of a diverting user. The identity of the diverting user is obtained from the History-Info header field, as described in 3GPP TS 24.604 [8].

4.6.11 Malicious Communication Identification (MCID)

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

4.6.12 Anonymous Communication Rejection (ACR) and Incoming Communications Barring (ICB)

Within the network execution of ICB and ACR services, either service shall take precedence over the eCNAM service.

4.6.13 Message Waiting Indication (MWI)

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

4.6.14 Flexible Alerting (FA)

If the FA Pilot has eCNAM activated, incoming calls to the FA Pilot shall apply eCNAM to the members of the FA group.

Metadata that is obtained from analytics shall be based on the FA Pilot and not the individual members’ identity.

NOTE: Analytics can sometimes be based on the called party’s identity. Therefore, it should be noted that in an FA group, the only identity available for use shall be that of the Pilot.

4.6.15 Personal Network Management (PNM)

For a user that subscribes to both PNM and eCNAM, both originating user identity and eCNAM identity data shall be delivered to the Personal Network UE that is configured to act as a Personal Network controller.

4.6.16 Multi-Device (MuD)

If the terminating user of the eCNAM service has activated the MuD service, eCNAM data shall be transmitted to all UEs of the terminating user.

4.6.17 Multi-Identity (MiD)

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

4.7 Parameter values (timers)

Not applicable.

Annex A (informative):
Change history

Change history
Date	Meeting	TDoc	CR	Rev	Cat	Subject/Comment	New version
2017-08	C1-105					Version after implementation of pCRs agreed in C1-105	0.1.0
2017-11	C1-106					Version after implementation of pCRs agreed in C1-106	0.2.0
2017-12	C1-107					Version after implementation of pCRs agreed in C1-107	0.3.0
2017-12	CT-78	CP-173044				Presentation for information at TSG CT	1.0.0
2018-01	C1-108					Version after implementation of pCRs agreed in C1-108	1.1.0
2018-02	C1-109					Version after implementation of pCRs agreed in C1-109	1.2.0
2018-03	CT-79	CP-180102				Presentation for approval at TSG CT	2.0.0
2018-03	CT-79					Version 15.0.0 created after approval	15.0.0
2019-09	CT-85	CP-192047	0001		F	Reference to RFC 8224	15.1.0
2019-12	CT-86	CP-193111	0002		B	Adding interactions with "Multi-Device" and "Multi-Identity" services	16.0.0
2022-03	CT-95e	–	–	–	–	Update to Rel-17 version (MCC)	17.0.0