IMS

SIP Parameters : P-Asserted-Identity

P-Asserted-Identity is a special type of UA identity implying "This is the proven ID for me within this trusted network".

Usuall UA ID is set in 'From' header, but the From header does not necessarly contain the actual identity. Actually, you can put any kind of string for 'From' header.

Therefore, once the authentication is complete for a UA, a proxy can add P-Asserted-Identity to inform other proxies saying 'Hey, this is a proven ID. so you can trust'.

P-Asserted-Identity (PAI) is a header field used in the SIP (Session Initiation Protocol) protocol within trusted networks to carry the identity of the user sending the SIP message. When a SIP request travels through a network, intermediate entities, usually SIP proxies, may need to assert the identity of a user to subsequent network entities. In short, P-Asserted-Identity is a means for a SIP entity, usually in a service provider's network, to assert the identity of a user, and it is used internally within trusted network domains for legitimate service features and management.

The P-Asserted-Identity header is used in scenarios where network entities require access to the identity of the user for various functions such as billing, call routing, or network-based services that depend on knowing the actual identity of the user making the call.

Here are some key points about PAI:

Trusted Networks: PAI is considered a trusted header, which means it should only be used and trusted in secure, closed networks where the proxies and other elements are managed by the service provider. It should not be used over the open internet or between different service providers because it could be subject to spoofing.
Privacy Considerations: Because the PAI can contain sensitive information about the user's identity, its usage is generally controlled by privacy services within the network to ensure that it is not exposed to unauthorized entities.
Format: The header typically includes a SIP URI or tel URI that represents the user's identity. For example: P-Asserted-Identity: <sip:user@example.com> or P-Asserted-Identity: <tel:+1234567890>.
Use Cases: PAI is used for various purposes, including:

Caller ID presentation in the terminating network.
Access control and authorization.
Accounting and billing purposes where accurate user identification is necessary.
Enforcement of communication policies based on user identity.

Security: Because the PAI can be used to assert the identity of a calling party, it must be protected from tampering using mechanisms like SIP over TLS, and it should only be inserted or modified by trusted network elements.

NOTE : Why we need this kind of new Identity of the sender where we have From header ?

The From header in SIP messages is used to indicate the originating identity of the request, which might be the user agent of the caller. However, this header can be set by the user agent itself, and therefore it can be manipulated or spoofed. In other words, it's not always a reliable source of the caller's true identity, especially for services that require a verified identity, such as billing or law enforcement.

In essence, P-Asserted-Identity provides a way for the network to convey a verified identity that is not subject to user manipulation, separate from the user-controlled From header, to support various network services and regulatory requirements.

The P-Asserted-Identity header serves a different and more secure purpose:

Network Trust: The P-Asserted-Identity is used within trusted network domains where the SIP proxies and other elements are under the control of the service provider. Since these network elements are trusted, they can assert the identity of the user accurately.
Security and Verification: The P-Asserted-Identity header is inserted by a trusted entity, usually the first hop SIP proxy in the service provider’s network that can authenticate the user. This means the identity has been verified by the network, and subsequent entities can trust it to be accurate.
Privacy and Anonymity: Users may want to present a different identity to the called party than the one used for billing or network records. The From header can be used to carry the public identity, while the P-Asserted-Identity carries the actual identity for internal network use. This allows services to maintain user privacy when necessary.
Functional Separation: The From header is used to manage the signaling layer of the call setup, reflecting who initiated the request. The P-Asserted-Identity is used for services that rely on knowing the actual identity regardless of the signaling, such as lawful interception, billing systems, or other administrative purposes.
Regulatory Compliance: In some jurisdictions, service providers are legally required to ensure that the identity presented for billing and law enforcement purposes is verifiable and not subject to user manipulation. P-Asserted-Identity helps meet these legal requirements.

NOTE : How about using 'Contact' header instead of P-Asserted-Identity ? Contact header should be the url that should really reacheable

The Contact header in SIP serves a very different purpose compared to P-Asserted-Identity. While P-Asserted-Identity provides a verified identity of the sender for trusted services within a network, the Contact header is used to indicate where and how the sender can be reached for subsequent SIP messages in the current session.

In short, the Contact header is not suitable for replacing P-Asserted-Identity because they serve different roles within the SIP protocol. Contact is used for session management and routing, while P-Asserted-Identity is used within a trusted network for services that require a verifiable identity.

Here are the primary differences and reasons why P-Asserted-Identity is used instead of Contact:

Purpose of the Contact Header:

The Contact header specifies the direct URI (Uniform Resource Identifier) at which the sender of the request can be reached. It is used in registration and call establishment to inform the other party where to send SIP messages for the duration of the session.
During a session, if the user agent moves or changes its point of contact (such as switching from Wi-Fi to a cellular network), the Contact header will be updated to reflect the new reachable address.

Reachability vs. Identity:

The Contact header is about reachability, not identity verification. It tells the recipient and the SIP proxies along the path how to route SIP responses and requests for the duration of the session.
P-Asserted-Identity is about asserting the verified identity of a user for trusted purposes within the service provider's network, which can be used for billing, law enforcement, and other official functions.

Changing Values:

The Contact header can change throughout the life of a registration or a call as the user's endpoint changes. It's dynamic and reflects the current contact URI for SIP signaling.
The P-Asserted-Identity typically remains constant and reflects the true identity of the user as recognized by the service provider. It is not meant to change as it represents a verified identity.

Privacy and Security:

The Contact header is visible in the SIP messages and can be manipulated by the client, potentially exposing private IP addresses or user agent information to the called party.
P-Asserted-Identity is inserted by a trusted network element after the user has been authenticated, and it's used internally for services that require a known, trusted identity. It's not meant to be exposed outside of the trusted network domain.

Network Trust and Service Logic:

P-Asserted-Identity is trusted by the network elements for executing service logic that depends on the user's identity, like call routing based on user profiles, special billing arrangements, etc.
The Contact header doesn't carry the same level of trust for these purposes because it's under the control of the user agent and is primarily for reachability.

NOTE : How can a SIP message be qualified to use P-Asserted-Identity ?

The use of the P-Asserted-Identity (PAI) header in a SIP message is subject to several conditions, primarily due to its nature as a trusted identity mechanism.

Service providers typically configure their SIP network elements to automatically handle the insertion and processing of PAI headers according to these qualifications, ensuring that the header is used appropriately and securely.

Here's how a SIP message can be qualified to use PAI:

Trusted Network Domain: The SIP message must originate from and be used within a trusted network domain. Typically, this means the message should be within a service provider's network where each element—such as proxies, registrars, and session border controllers—is managed and trusted by the provider. PAI headers should not be used or trusted across network boundaries where the trust cannot be assured, such as on the open internet.
Network Authentication: The user sending the SIP message must be authenticated by the network. The PAI is inserted by a network element after it has authenticated the user and can thus vouch for the identity contained in the PAI header.
Privacy and Legal Considerations: The network must handle PAI in compliance with privacy regulations and policies. Service providers need to ensure that they are legally permitted to insert and use PAI information, as it can contain sensitive data.
Secure Transmission: Since PAI carries sensitive information about a user's identity, the SIP message should be transmitted securely, using encryption protocols such as Transport Layer Security (TLS), to prevent interception and tampering.
Conformance to Standards and Best Practices: The usage of PAI should conform to the relevant standards, including RFC 3325, which defines the PAI header. Service providers should also follow industry best practices for SIP communication to ensure interoperability and security.
Access Control: Only authorized network elements should be able to insert, modify, or delete the PAI header. This typically includes proxies or servers at the edge of the provider's network that interface with user agents.
Intended Use Case: PAI should be used for specific use cases where asserting the identity of the user is necessary, such as billing, lawful interception, network services, and other administrative functions. It should not be used for general call routing or session management.
Downstream Trust: Any downstream elements that receive a SIP message with a PAI header must also be trusted to handle it correctly. This includes not forwarding the PAI to untrusted or unauthorized entities.
Client Support: Although the client user agent does not insert the PAI, it must be capable of understanding and processing the PAI if it is to act on the asserted identity. However, user agents typically do not modify or insert PAI headers.
Compliance with Service Agreements: Finally, the insertion and use of PAI should be in line with any service agreements between the service provider and the user, respecting any stipulations about the use of identity information.

NOTE : How do you compare P-Asserted-Identity with P-Preferred-Identity ?

P-Asserted-Identity (PAI) and P-Preferred-Identity (PPI) are both header fields used in SIP (Session Initiation Protocol) messaging within trusted networks. They serve related but distinct purposes concerning the identity of the party making a SIP request.

In practice, when a SIP message contains both PAI and PPI headers, the network uses PAI for trusted identity verification and may ignore the PPI or use it to inform the called party's display information, provided it aligns with the network's policies and the PAI.

Here is a comparison of the two:

P-Asserted-Identity (PAI):

PAI is used by the network (usually a proxy server or a session border controller) to assert the identity of a user once they have been authenticated.
It is a way for the network to convey a verified identity to other entities within the network that are also considered trusted.
PAI is used in scenarios where the service provider needs to assert the caller's identity for functions such as billing, call routing, or providing specific network services.
The header is not supposed to be altered by the user's client (user agent) and should only be added by trusted elements within the provider's network.
Receivers of the PAI header can use this information to make trusted decisions because it is assumed to be a verified identity.

P-Preferred-Identity (PPI):

PPI is used by the user (through their user agent) to indicate their preferred identity to be used by the called party.
It allows a user to suggest which identity they would like to present to the called party, for example, when they have multiple identities/numbers.
PPI is considered when the calling party wishes to present a particular identity, but this identity is not necessarily verified by the network.
Unlike PAI, PPI can be set by the user's client and is intended for scenarios where the user's preference for identity presentation needs to be considered by the network.
The network might use the PPI as a suggestion, but it will only trust this header if the network can verify the user's identity. If not, the network might override the PPI with a PAI.

Key Differences:

Trust Level: PAI carries a higher level of trust because it is asserted by the network after verifying the user's identity. PPI, on the other hand, indicates a user's preference and may not be independently verified by the network.
Control: PAI is controlled by the network, while PPI is controlled by the user.
Use Case: PAI is often used internally within the network for billing, lawful interception, or other official functions, while PPI is used to inform the network and the called party of the user's preferred identity.
Visibility: PAI is intended for use within the network and is not usually forwarded to the end-user, whereas PPI may be used to convey the user's identity to the called party.

NOTE : Followings are some of the quotes from specifications.

< From RFC 3325 9.1 The P-Asserted-Identity Header >

The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication.

A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-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) add and remove this header field.

< From 3GPP 24.229 4.4.1 General >

The PSAP is typically regarded as being within the trust domain, except where indicated. National regulator policy applicable to emergency services determines the trust domain applicable to certain header fields.This means that e.g, the handling of the P-Access-Network-Info header field, P-Asserted-Identity header field and the History-Info header field can be as if the PSAP is within the trust domain and trust domain issues will be resolved accordingly..

< From TS24.341 5.3.2.4 Sending a delivery report >

When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP MESSAGE request with the following information:

a) the Request-URI, which shall contain the IP-SM-GW;

NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE request including the delivered short message

c) the To header, which shall contain the IP-SM-GW;