Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x
Top   in Index   Prev   Next

TS 24.196
Enhanced Calling Name (eCNAM)

3GPP‑Page   ETSI‑search   CONTENT↓
V18.0.0 (PDF)  2024/03  15 p.
V17.0.0  2022/03  15 p.
V16.0.0  2019/12  15 p.
V15.1.0  2019/09  15 p.
Rapporteur:
Mrs. Biondic, Nevenka
Ericsson LM

Content for  TS 24.196  Word version:  18.0.0

Here   Top

1  Scope  p. 5

The present document specifies the stage three (protocol description) of the Enhanced Calling Name (eCNAM) supplementary service based on stage one description in TS 22.173. It provides the protocol details in the IP Multimedia (IM) Core Network (CN) subsystem (see TS 24.229) based on the Session Initiation Protocol (SIP) (see RFC 3261) where the eCNAM data is retrieved by the terminating network from trusted data sources.
Up

2  References  p. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services".
[2]
TS 24.229: "IP Multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[3]
RFC 3261:  "SIP: Session Initiation Protocol".
[4]
TS 23.003: "Numbering, addressing and identification".
[5]
RFC 3325:  "Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks".
[6]
RFC 3323:  "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
[7]
RFC 3966:  "The tel URI for Telephone Numbers".
[8]
TS 24.604: "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem".
[9]
RFC 8224:  "Authenticated Identity Management in the Session Initiation Protocol (SIP)".
[10]
ITU-T Recommendation E.164 (11/2010): "The international public telecommunication numbering plan".
[11]
ITU-T Recommendation I.210 (03/1993): "Principles of telecommunication services supported by an ISDN and the means to describe them".
Up

3  Definitions and abbreviations  p. 5

For the purposes of the present document, the following definitions and abbreviations apply.

3.1  Definitions  p. 5

For the purposes of the present document, the following definitions and abbreviations apply:
Identity information:
all the information identifying a user, including trusted (network generated) and/or untrusted (user generated) addresses.
Originating UE:
sender of a SIP request intended to initiate either a dialog (e.g. INVITE, SUBSCRIBE), or a standalone transaction.
Private information:
information that according to RFC 3323 and RFC 3325 is not permitted to be delivered to the remote end.
Searchkey:
a user identity employed to retrieve the eCNAM data associated with that identity from the appropriate data sources.
terminating UE:
recipient of a SIP request intended either to initiate a dialog or to initiate either a dialog or a standalone transaction
trusted identity information:
network generated user public identity information
For the purposes of the present document, the following definitions given in RFC 3261 apply.
header
header field
request
response
session
(SIP) transaction
For the purposes of the present document, the following definitions given in ITU-T Recommendation I.210 [11] apply:
supplementary service
E.164 telephone number: telephone number formatted according to ITU-T.
Up

3.2  Abbreviations  p. 6

For the purposes of the present document, the following abbreviations apply.
3GPP
3rd Generation Partnership Project
ACR
Anonymous Communication Rejection
AS
Application Server
CCBS
Completion of Communication to Busy Subscriber
CDIV
Communication DIVersion
CN
Core Network
CUG
Closed User Group
CW
Communication Waiting
eCNAM
Enhanced Calling Name
ECT
Explicit Communication Transfer
FA
Flexible Alerting
HOLD
Communication Hold
ICB
Incoming Communications Barring
IETF
Internet Engineering Task Force
IM
IP Multimedia
IMS
IP Multimedia Subsystem
IP
Internet Protocol
MCID
Malicious Communication Identification
MiD
Multi-iDentity
MuD
Multi-Device
MWI
Message Waiting Indication
OIP
Originating Identification Presentation
OIR
Originating Identification Restriction
PNM
Personal Network Management
SDP
Session Description Protocol
SIP
Session Initiation Protocol
TIP
Terminating Identification Presentation
TIR
Terminating Identification Restriction
TN
Telephone Number
UE
User Equipment
URI
Universal Resource Identifier
Up

4  Enhanced Calling Name (eCNAM)  p. 7

4.1  Introduction  p. 7

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  p. 7

4.2.1  General Description  p. 7

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).
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.
Up

4.3  Operational Requirements  p. 7

4.3.1  Provision/withdrawal  p. 7

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  p. 7

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.
The originating network can support a verification capability, such as the number verification capability described in TS 24.229. Without a verification capability at the originating network, the integrity of the eCNAM data retrieved could be impacted.
Up

4.3.3  Requirements on the Terminating Network  p. 8

4.3.3.1  Data Sources  p. 8

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.
Up

4.4  Syntax Requirements  p. 8

The syntax for the header fields are normatively described in TS 24.229. The relevant headers are:
  • The P-Asserted-Identity header field which shall conform to the specifications in RFC 3325 and RFC 3966.
  • The Identity header field which shall conform to the specifications in RFC 8224.
  • The Call-Info header field which shall conform to the specifications in RFC 3261.
  • The Privacy header field which shall conform to the specifications in RFC 3323] and RFC 3325.
  • The From header field which shall conform to the specifications in RFC 3261 and RFC 3966.
Up

4.5  Signalling Procedures  p. 8

4.5.1  General  p. 8

Configuration of the eCNAM is performed by the service provider.

4.5.2  Activation/Deactivation  p. 8

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  p. 9

4.5.3.1  Actions at the Originating UE  p. 9

No actions at the originating UE.

4.5.3.2  Actions at the AS serving the Originating UE  p. 9

No actions at the AS serving the originating UE.

4.5.3.3  Actions at the AS serving the Terminating UE  p. 9

4.5.3.3.1  Identity not available  p. 9
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.
Up
4.5.3.3.2  Identity available, presentation not allowed  p. 9
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 TS 23.003.
The metadata may be sent to the terminating UE, based on service provider policy.
Up
4.5.3.3.3  Identity available, originating user identity verified and passed, presentation allowed  p. 9
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 TS 24.229) 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.
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.
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.
Up
4.5.3.3.4  Identity available, verification failed  p. 10
If the originating user identity verification performed (such as the verification resulting in the "verstat" tel URI parameter described in TS 24.229) 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:
  1. 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;
  2. 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";
  3. 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.
Up

4.5.3.4  Actions at the Terminating UE  p. 10

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.
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.
Up

4.6  Interaction with other Services  p. 11

4.6.1  Originating Identification Presentation (OIP)  p. 11

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)  p. 11

The OIR service shall take precedence over the eCNAM service.

4.6.3  Terminating Identification Presentation / Terminating Identification Restriction (TIP/TIR)  p. 11

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

4.6.4  Advice of Charge  p. 11

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

4.6.5  Communication Waiting (CW)  p. 11

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  p. 11

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

4.6.7  Explicit Communication Transfer (ECT)  p. 11

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

4.6.8  Closed User Group (CUG)  p. 11

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)  p. 11

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)  p. 12

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 TS 24.604.

4.6.11  Malicious Communication Identification (MCID)  p. 12

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

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

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)  p. 12

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

4.6.14  Flexible Alerting (FA)  p. 12

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.

4.6.15  Personal Network Management (PNM)  p. 12

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)  p. 12

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)  p. 12

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

4.7  Parameter values (timers)  p. 12

Not applicable.

$  Change history  p. 13

Up   Top