Content for  TS 23.228  Word version:  16.6.0

5.11.4  Procedures for providing or blocking identity  Word‑p. 170

5.11.4.0  General |R6|

Identity is composed of a Public User Identity and an optional display name:

• The Public User Identity is used by any user for requesting communications to other users (see clause 4.3.3.2).
• The display name is the user's name if available, an indication of privacy or unavailability otherwise. The display name is a text string which may identify the subscriber, the user or the terminal.

This clause gives information flows for the procedures for providing the authenticated Public User Identity and the optional display Name information of the originating party to the terminating party. It also describes the mechanisms for blocking the display of Public User Identity and optional display name if requested by the originating party.

5.11.4.1  Procedures for providing the authenticated identity of the originating party

Authentication of the subscriber is performed during the registration procedures, as described in clause 5.2.2.3. As a result of the registration procedures, one or several Public User Identity(ies) of the originating party is/are stored in P-CSCF#1. As part of this procedure, the display name associated with each Public User Identity, if provided by the HSS, is also returned via the S-CSCF and stored in the P-CSCF#1. This is shown in the sub-procedure represented in the following information flow in step 1.

When UE#1 attempts to initiate a new session, the UE shall include one of the Public User Identities the UE received during the SIP registration in the INVITE request. The P-CSCF#1 ensures that the INVITE request includes an authenticated Public User Identity, including the associated display name if provided by the S-CSCF during the registration procedures, before forwarding the INVITE request to the S-CSCF#1.

In the following call flow, it is assumed that no privacy has been required by UE#1.If the Public User Identity supplied by UE#1 in the INVITE request is incorrect, or if the UE did not provide a public identify, then the P-CSCF may reject the request, or may overwrite with the correct URI, including the associated display name if provided by the S-CSCF during the registration procedures.

(not reproduced yet)

Figure 5.34: Providing the authenticated Identity of the originating party

The detailed procedure is as follows:

Step 1.

Registration and authentication of UE#1 is performed. One or more authenticated identities for UE#1, including display names if provided, are stored in the P-CSCF#1 and the UE.

Step 2.

UE#1 initiates a new multi-media session, by sending an INVITE request to P-CSCF#1. This INVITE request includes a Public User Identity, and may include a display name that may identify the specific person using the UE.

Step 3.

P-CSCF#1 checks the Public User Identity of the originating party, and replaces it (or rejects the request) if it is incorrect. If provided during registration procedures via the S-CSCF, the P-CSCF#1 ensures that the display name associated with the verified Public User Identity is present before forwarding the INVITE request.

Step 4.

P-CSCF#1 forwards the INVITE request, with the verified Public User Identity and display name of the originating party if present, to S-CSCF#1.

Step 5.

S-CSCF#1 invokes whatever service logic is appropriate for this session set up attempt to check in particular that no identity restriction is active.

Step 6.

S-CSCF#1 forwards the INVITE request, with verified Public User Identity and display name of the originating party if present, to S-CSCF#2.

Step 7.

S-CSCF#2 stores the Public User Identity and associated information.

Step 8.

S-CSCF#2 forwards the INVITE request to P-CSCF#2.

Step 9.

P-CSCF#2 forwards the INVITE request to UE#2.

Step 10.

UE#2 displays the Public User Identity and the display name information (i.e. user-name if available, indication of privacy or unavailability otherwise) to the terminating party.

5.11.4.2  Procedures for blocking the identity of the originating party  Word‑p. 172

Regulatory agencies, as well as subscribers, may require the ability of an originating party to block the display of their identity either permanently or on a session by session basis. This is a function performed by the destination P-CSCF. In this way, the terminating party is still able to do a session-return, session-trace, transfer, or any other supplementary service.

In this call flow, it is assumed that privacy has been required by UE#1 on Public User Identity (i.e. 'id' privacy).

(not reproduced yet)

Figure 5.35: Blocking the identity of the originating party

The detailed procedure is as follows:

Step 1.

UE#1 initiates a new multi-media session, by sending an INVITE request to P-CSCF#1. This INVITE request includes Public User Identity, and may include a display name that may identify the specific person using the UE. Also included in this INVITE message is an indication that the identity of the originating party shall not be revealed to the destination.

Step 2.

P-CSCF#1 checks the Public User Identity of the originating party, and replaces it (or rejects the request) if it is incorrect. If provided during registration procedures, the P-CSCF#1 ensures that the display name associated with the Public User Identity is present before forwarding the INVITE request.

Step 3.

P-CSCF#1 forwards the INVITE request, with the verified Public User Identity and display name, to S-CSCF#1.

Step 4.

S-CSCF#1 invokes whatever service logic is appropriate for this session set up attempt. Based on the subscriber's profile, S-CSCF#1 may insert an indication in the INVITE message that the identity of the originating party shall not be revealed to the terminating party. S-CSCF#1 may insert an indication to block the IP address of UE#1 too and may remove other information from the messaging which may identify the caller to the terminating party.

Step 5.

S-CSCF#1 forwards the INVITE request, with verified Public User Identity, and with user-name of the originating party if present, to S-CSCF#2.

Step 6.

If the terminating party has an override functionality in S-CSCF#2/Application Server in the terminating network the S-CSCF#2/Application Server removes the indication of privacy from the message.

Step 7.

S-CSCF#2 forwards the INVITE request to P-CSCF#2.

Step 8.

If privacy of the user identity is required, P-CSCF#2 removes the Public User Identity, including the display name if present, from the message.

Step 9.

P-CSCF#2 forwards the INVITE request to UE#2.

5.11.4.3  Procedures for providing the authenticated identity of the originating party (PSTN origination) |R7|  Word‑p. 173

For calls originating from the PSTN, the MGCF extracts information received from the PSTN and inserts an asserted identity into the SIP message. If the incoming information includes the calling name, or the MGCF can obtain the calling name, the MGCF may insert the information into the display name portion of the asserted identity.

The MGCF must propagate the privacy indicators received from the PSTN in the SIP message.

5.11.4.4  Procedures for providing the authenticated identity of the originating party (PSTN termination) |R7|

For calls terminating to the PSTN, the MGCF extracts information received in the SIP message and inserts the information into the PSTN signalling. This information must include the privacy setting and may include the display name.