IMS  

 

 

 

SIP Parameters : P-Preferred-Identity

P-Preferred-Identity (PPI) is a header field used in SIP (Session Initiation Protocol) for signaling in IP-based communications. This header is used by the user agent to indicate which of the user's addresses-of-record (AORs) it prefers to be used as its identity in the SIP messages, particularly in requests.

P-Preferred-Identity allows a user to communicate their choice of public identity for a particular session or communication. However, the actual use of this identity is subject to network policies, privacy considerations, and verification processes.

Here's a detailed look at the PPI header:

  • User Control: Unlike P-Asserted-Identity, which is set by the network, the P-Preferred-Identity header is set by the user or their user agent. It expresses the user's preference for which identity should be used for the session being established.
  • Multiple Identities: Users can have multiple identities (like several phone numbers or SIP URIs) associated with their account. The PPI header allows the user to indicate which identity they want the called party to see. This is particularly useful in services like caller ID.
  • Privacy Considerations: PPI is sensitive to privacy concerns. While users can indicate their preferred identity, networks typically enforce privacy services that may restrict the visibility of this information based on user settings, service agreements, or regulatory requirements.
  • Verification and Trust: PPI does not carry the same level of network-verified trust as P-Asserted-Identity. Networks will often use PPI as a suggestion but may override it based on their policies or when they cannot verify the PPI against the user's account.
  • RFC 3325: The use of P-Preferred-Identity is defined in RFC 3325 ("Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks"). It specifies that PPI should be used within trusted networks and not across the open internet or untrusted domains.
  • Network Behavior: When a SIP proxy server or a session border controller receives a SIP INVITE with a PPI header, it may use the PPI to determine the calling line ID presentation if the user's identity can be verified. If the network cannot verify the identity or if the user has requested anonymity, the network may ignore the PPI and either use a different identity for the call or withhold the identity entirely.
  • Legal and Regulatory Compliance: Service providers must handle P-Preferred-Identity in compliance with local laws and regulations, particularly those concerning user privacy and data protection.

 

NOTE :Is this the ID shown up in the reciever's display when the reciever get a ring ?.

Yes, the identity information conveyed in the P-Preferred-Identity header may be used for display purposes on the receiver's side, typically to show the caller ID. However, whether it actually shows up on the receiver's display when the phone rings depends on several factors:

In other words, while the P-Preferred-Identity is designed to influence what is shown on the receiver's display, its effectiveness is subject to the conditions and constraints of the network, devices, and regulations involved.

  • Network Policies and Verification: The network might verify the P-Preferred-Identity against the user's account information. If the network cannot verify the identity, or if network policies or regulations do not allow it, the network may use a different identity or a generic identifier.
  • Privacy Settings: The user might have privacy settings that override the PPI. If the user has requested that their identity be kept private, the network may not display any identity or might display a network-defined privacy notice instead.
  • Intermediate Networks: If the call traverses multiple networks (for example, from one service provider to another), the intermediate networks might not support the PPI header or might have different policies that affect the display of the calling identity.
  • End-User Device: The receiver's device must support the SIP protocol and be capable of interpreting and displaying the information provided in the PPI header. Some devices might only display the information in the From header or might have settings that affect caller ID display.
  • Regulatory Requirements: In some jurisdictions, there are regulatory requirements about what can be displayed as the caller ID, which might restrict the use of PPI information for caller ID purposes.
  • Manipulation and Security: To prevent caller ID spoofing, networks may have security measures in place that affect the display of caller IDs, ensuring that only verified identities are shown.

 

NOTE :Followings are some of the quotes from specifications.

    < Based on 3GPP 24.229 5.1.2A.1.1 General >

    the UE may insert a P-Preferred-Identity header field in any initial request for a dialog or request for a standalone transaction as a hint for creation of an asserted identity (contained in the P-Asserted-Identity header field) within the IM CN subsystem.

    The UE shall determine the public user identity to be used for this request as follows:

      1) if a P-Preferred-Identity was included, then use that as the public user identity for this request; or

      2) if no P-Preferred-Identity was included, then use the default public user identity for the security association or TLS session and the associated contact address as the public user identity for this request;

     

    < Based on RFC 3325 >

    The P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity. The user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert.

    A P-Preferred-Identity header field value MUST consist of exactly one name-addr or addr-spec.  There may be one or two P-Preferred-Identity values.  If there is one value, it MUST be a sip, sips, or tel URI.

    If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI.  It is worth noting that proxies can (and will) remove this header field.

    If a P-Preferred-Identity header field is present in the message that a proxy receives from an entity that it does not trust, the proxy MAY use this information as a hint suggesting which of multiple valid identities for the authenticated user should be asserted.

    A user agent only sends a P-Preferred-Identity header field to proxy servers in a Trust Domain; user agents MUST NOT populate the P-Preferred-Identity header field in a message that is not sent directly to a proxy that is trusted by the user agent.