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 126.96.36.199).
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.
Authentication of the subscriber is performed during the registration procedures, as described in clause 188.8.131.52
. 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.
The detailed procedure is as follows:
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.
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.
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.
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.
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.
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.
S-CSCF#2 stores the Public User Identity and associated information.
S-CSCF#2 forwards the INVITE request to P-CSCF#2.
P-CSCF#2 forwards the INVITE request to UE#2.
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.