Who Was That Masked Man? Using P-Asserted-Identity

One of the things I love best about SIP is its simplicity.  There are only a baker’s dozen request messages and yet you can create a multitude of different features using them.  In fact, when it comes to session creation, management, and manipulation, there are really only four important ones – INVITE, ACK, BYE, and REFER.  In fact, I could arguably knock that list down to two since ACK and BYE are only briefly involved in session creation and release.

So, how is it possible to create all those features from only two basic messages?  It all comes down to SIP headers.  Headers can tell you whether this is a new session or an altered session.  Headers can be used to replace one session with another.  Headers can be used for timeouts, loop detection, security, and scores of other activities.  Today I want to write about how SIP headers can be used to protect your identity when making a multimedia call.

SIP identity is established with the To and  From headers.  As you would expect, the To header indicates with whom you wish to establish a session and the From header indicates who you are.  For example, you might encounter an INVITE that looks similar to the following:

INVITE sip:Linda@bigcompany.com SIP/2.0

Max-Forwards= 70

Via SIP/2.0/UDP myPC@littlecompany.com; branch=198398334

To: “Linda” <sip:Linda@bigcompany.com>

From: “Andrew” <sip:Andrew@littlecompany.com>; tag=12345




Here, Andrew is attempting to establish a session with Linda.  I don’t show you enough of the INVITE message to indicate the kind of media that will be used by this session, but that’s immaterial to the example.  The point is that Andrew is the sender and Linda is the recipient.

However, what if Andrew didn’t want Linda to know who is calling?  Similar to pressing *67 before dialing the land-line phone in his house, Andrew might want to suppress the sending of his identity.  How do you accomplish that with SIP?

The answer is quite simple.  Instead of putting his identity in the From header, Andrew’s SIP phone would do something similar to the following:

From: “Anonymous” <sip:Anonymous@annoymous.invalid>; tag=12345

Now, when Linda receives the INVITE message, she is unaware of who is calling and her phone might display “Unknown” as the caller.

However, we have a bit of a problem with this.  Despite the fact that Andrew might want to keep his identity hidden from Linda, the network SIP elements might not want to deal with an unknown, anonymous caller.  A caller’s true identity is required for class of service processing, billing, call detail recording (CDR), call recording, or any other traditional network activity.

This is where another SIP header comes into play.  P-Asserted-Identity is used within the “trusted” realm of a SIP network to allow servers and services to process SIP messages for the known, authenticated user and not an anonymous caller.  P-Asserted-Identity is inserted by a trusted SIP element (e.g. SIP Proxy) and preserved for the message’s entire time within the trusted realm.  In other words, as a call is being processed by the SIP network, a P-Asserted-Identity header will be part of all SIP messages for that call (i.e. INVITE, ACK, BYE).  As soon as any message leaves the trusted realm, the header is stripped and anonymity is restored.

Using the above example, this is how the same INVITE message might look within the trusted realm:

INVITE sip:Linda@bigcompany.com SIP/2.0

Max-Forwards= 70

Via SIP/2.0/UDP myPC@littlecompany.com; branch=198398334

To: “Linda” <sip:Linda@bigcompany.com>

From: “Anonymous” <sip:Anonymous@annoymous.invalid>; tag=12345

P-Asserted-Identity: “Andrew” <sip:Andrew@littlecompany.com>

P-Asserted-Identity: tel:+19524563516




Note that P-Asserted-Identity headers can be used to establish a SIP name as well as a public telephone number.

The altered form of the INVITE message will exist until it leaves the bounds of the trusted network.  At that point, all P-Asserted-Identity headers will be stripped and the caller’s identity will once again be hidden.

As with all things SIP, P-Asserted-Identity is defined by an RFC.  In this case, please refer to RFC 3325 for the gory details.

I hope this all made sense to you.  So, rather than adding a new message type for caller-ID blocking, SIP allows for the creation of a new feature with the addition of a single header.  As time goes by, I will explore more of these header-based features.  Stay tuned for further fun and games!


  1. Boon-Leng ong · · Reply

    Your ability to break down sip into easy to understand terms is amazing

    1. Thank you! I appreciate hearing that.

  2. Thanks for the nice explanation !

    What’s P stand for here in P-Asserted-Identity?

    1. The P stands for Private. There are a series of Private (P-) headers.

  3. SBoobathy · · Reply

    You have explained this as a Piece of Cake… Thank you so much..

    1. SBoobathy · · Reply

      Also pls explain about the “tag” number…

      From: “Anonymous” ; tag=12345

      P-Asserted-Identity: “Andrew”

      P-Asserted-Identity: tel:+19524563516

      What about the tag number in P-Asserted-Identity ???

      1. Thanks… 🙂

  4. Wissal · · Reply

    you really helped me understanding this SIP feature. Huge Thanx!!

  5. Lingyao · · Reply

    Thank you Andrew for your explaination! 🙂
    One more question about the relationship between P-Prefered-identity header and P-Asserted-header.
    If I undertand the RFC3325 well, P-Prefered-identity header is sent by the UA to trusted proxy, once the UA is authenticated, the proxy will replace the PPI header by the PAI header with the same value? And this PAI header will be transported between trusted proxies?

    1. You are correct. Preferred is the requested identity and Asserted is the authenticated identity.

  6. Thanks Andrew !! A brief and very good explanation !

  7. Andrew Xavier · · Reply

    When ever I visit your forum for any clarification regarding SIP I never get disappointed. The way you explain is very simple and brilliant. Thanks for your contribution and keep continuing your good work.


  8. sandeep · · Reply

    If the P-Preferred identity is different than the registered identities ,if so then what Trusted servers will do ?

  9. sandeep · · Reply

    Briefing my question again,if P-Preferred-Identity values are not matching with the AOR RCB list then what will happen?

  10. Ronak · · Reply

    Hello Andrew,

    Would you explain how name display and alternate caller id works in terms of SIP headers, I mean what headers are used when a company wants to show Company’s main number and name while calling out from any extension or they want to show caller name while calling and DID on ext while calling.

    I believe P-Asserted Identity is used to achieve that but I don’t have exact understanding of it


  11. Hi Andrew.. Thank you for very good explanation for P-Asserted ID header.

    Do you have a post on explaining other Private headers (mentioned below) as well? I tried but couldn’t find.

    P_Access_Network_Info, P_Answer_State, P_Asserted_Service, P_Associated_URI, P_Called_Party_ID, P_Charging_Function_Addresses, P_Charging_Vector, P_DCS_Billing_Info, P_DCS_LAES, P_DCS_OSPS, P_DCS_Redirect, P_DCS_Trace_Party_ID, P_Early_Media, P_Media_Authorization, P_Preferred_Identity, P_Preferred_Service, P_Private_Network_Indication, P_Profile_Key, P_Refused_URI_List, P_Served_User, P_User_Database, P_Visited_Network_ID

    1. I do not have anything on them, but thanks for the idea.

  12. Hello Andrew,

    Today one question brought me here about RFC 3325 for P-asserted identity::

    Based on its RFC 3325, which states that if endpoint wants to alter caller id, its proxy must enter P-asserted Identity field with legitimate caller information, keeping From and Contact field altered.

    I have seen some PBX provider implementing it other way: They keep legitimate caller id in From and Contact header and populate P-asserted identity with altered caller id.

    Are they still following RFC? Which approach is most widely used?


  13. Mohamed · · Reply

    Thank you very much for your ability to deliver complex things with easy way

  14. Great explanation! I had a situation where UK call was initially presenting PPI of originating caller but then switched to only present the PAI. I can only assume that one of the proxies is discarding the PPI info with the PAI now as that’s all I get from the UK. Your explanation clarified this for me. My favorite bit in RFC-3325 says “proxies can (and will) add and remove this header field.”

  15. Vikram Malhotra · · Reply

    Hi Andrew ,

    Your blogs are really helpful .I have a situation here where caller’s name(“Andrew”) is not getting delivered to the called party. My carrier is saying that we ware sending two PAI’s one with sip uri and one with tel uri and sonus switch at their end picks up the caller’s name and number from PAI with tel URI and ignores the first one with SIP uri.

    P-Asserted-Identity: “Andrew”

    P-Asserted-Identity: tel:+19524563516

    What do you think ? How does the proxy or switch at their end should react to these two PAI’s?

    1. Interesting. Two PAIs is perfectly legal. Unfortunately, I am not sure how it should react. You may want to reach out to Ribbon (they bought Sonus).

    2. Vikram Malhotra · · Reply

      That what I thought yet I am not sure how does a PAI with tel uri can carry a caller’s name in it .what should be the correct syntax of such PAI.

      P-Asserted-Identity: “Andrew”

      Thanks for your advice though!

  16. Well explained thanks

  17. ibrahim jlidi · · Reply

    Thank you very much, but I have a question.

  18. Leslie Shishimayi · · Reply

    Brilliant explanation of P Asserted Header

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: