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!
Tao, Zen, and Tomorrow 
Your ability to break down sip into easy to understand terms is amazing
Thank you! I appreciate hearing that.
Thanks for the nice explanation !
What’s P stand for here in P-Asserted-Identity?
The P stands for Private. There are a series of Private (P-) headers.
You have explained this as a Piece of Cake… Thank you so much..
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 ???
Read this for your answer: https://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/
Thanks… 🙂
you really helped me understanding this SIP feature. Huge Thanx!!
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?
You are correct. Preferred is the requested identity and Asserted is the authenticated identity.
Thanks Andrew !! A brief and very good explanation !
Thanks!
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.
Thanks,
Andrew
If the P-Preferred identity is different than the registered identities ,if so then what Trusted servers will do ?
Briefing my question again,if P-Preferred-Identity values are not matching with the AOR RCB list then what will happen?
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
Regards,
Ronak
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
I do not have anything on them, but thanks for the idea.
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?
Regards,
Ronak
Thank you very much for your ability to deliver complex things with easy way
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.”
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?
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).
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!
Well explained thanks
Thank you very much, but I have a question.
Brilliant explanation of P Asserted Header