Asterisk Call Party, Privacy, and Header Presentation

Asterisk Call Party, Privacy, and Header Presentation

Asterisk allows users to manipulate call party identification information through mechanisms like configuration options and dialplan functions (for instance CALLERID and CONNECTEDLINE to name a couple). This grants the user freedom to adjust values with regards to what call/caller information to expose and/or override. With this freedom, though, comes some complexity, and confusion. Especially when you mix in some PJSIP configuration options.

This post attempts to alleviate some of that confusion by clarifying the relationships between the presentation information and the relevant PJSIP endpoint configuration options. Primarily, with regards to the final presentation found in any applicable SIP headers: From, P-Asserted-Identity, Remote-Party-ID, Contact.


Depending on the options and parameters set within Asterisk you can mask or expose some, or all of the caller’s presentation information. For instance, setting the from_user and/or from_domain options on an endpoint will affect what’s written for the header’s SIP URI. If given that endpoint “alice” dials endpoint “mad_hatter”, by altering “mad_hatter’s” from user and domain options you’ll see something similar to the From headers written below (Note, is only an example of IP address):

from_user from_domain From
“alice” <sip:alice@> “alice” <>
march_hare <sip:march_hare@>
march_hare <>

Of course altering the callerid also has an effect. For example, by prohibiting the callerid’s presentation some or all of the header’s sip URI will be anonymized:

from_user from_domain From
“Anonymous” <sip:anonymous@anonymous.invalid> “Anonymous” <>
march_hare “Anonymous” <sip:march_hare@anonymous.invalid>
march_hare “Anonymous” <>

What happens though if you invalidate just the callerid number? The string literal ‘asterisk’ is used in the SIP URI instead:

same =&gt; n,Set(CALLERID(num-valid)=no)
from_user from_domain From
“alice” <sip:asterisk@> “alice” <>
march_hare <sip:march_hare@>
march_hare <>

As you can see there is an order to things with the from user and domain options taking precedence over other settings.

P-Asserted-Identity and Remote-Party-ID

These headers are added to appropriate outbound SIP messages only under certain conditions. Once those conditions are met, and the header is added, parts of the privacy information transmitted can be concealed based on what’s allowed by the presentation. In order to add one or both of the headers, enable one or both of the following options on the target endpoint in the pjsip.conf configuration file:

send_pai=yes ; Adds a P-Asserted-Identity header to an outgoing SIP message
send_rpid=yes ; Send the Remote Party ID header

By setting one of those options the applicable header is now added, and will contain the pertinent privacy information. Much like the From header, by setting the domain option you can override some of the privacy data.

from_user from_domain P-Asserted-Identity or Remote-Party-ID
“alice” <sip:alice@> “alice” <>
march_hare “alice” <sip:alice@>
march_hare “alice” <>

Notice though that setting the from_user did not alter the header in any way. Only setting the from_domain has an effect. You can, though, remove the quoted name portion of the URI by invalidating the name presentation. For instance, by doing the following:


It results in something like below (from_domain not set):

P-Asserted-Identity: &lt;sip:alice@;
Remote-Party-ID: &lt;sip:alice@;;privacy=off;screen=no

However, if you use the CALLERID function to invalidate the number then the headers are blocked from being added to outgoing messages. The headers are also blocked from addition if you prohibit, or set the total presentation to unavailable:

; OR

This last case though is overridden if the following option is set on the endpoint definition in the pjsip.conf file:

trust_id_outbound=yes ; Send private identification details to the endpoint


I’ll only briefly talk about the contact header as it is not affected by call party data. However, it can be affected by an option already mentioned, namely the from_user option, so I figured it is worth showing what happens to the Contact header if that option is used. Here is a table showing how that option can override the default:

from_user from_domain From
<sip:asterisk@> <sip:asterisk@>
march_hare <sip:march_hare@>
march_hare <sip:march_hare@>

Note, that the from_domain option has no affect on the header. The user portion can also be further overridden by the contact_user endpoint option:

from_user contact_user From
chesire_cat <sip:chesire_cat@>
march_hare <sip:march_hare@>
march_hare chesire_cat <sip:cheshire_cat@>

Concluding Remarks

As you can see Asterisk allows many ways to control the final presentation seen in various SIP headers. Hopefully, things are a little clearer about how you apply these methods to obtain a desired outcome.

Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.

About the Author

What can we help you find?