Search the Asterisk Blog

Asterisk Call Party, Privacy, and Header Presentation

By Kevin Harwell

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.

From

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, 127.0.0.1 is only an example of IP address):

from_user from_domain From
“alice” <sip:alice@127.0.0.1>
wonder.land “alice” <sip:alice@wonder.land>
march_hare <sip:march_hare@127.0.0.1>
march_hare wonder.land <sip:march_hare@wonder.land>

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>
wonder.land “Anonymous” <sip:anonymous@wonder.land>
march_hare “Anonymous” <sip:march_hare@anonymous.invalid>
march_hare wonder.land “Anonymous” <sip:march_hare@wonder.land>

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

from_user from_domain From
“alice” <sip:asterisk@127.0.0.1>
wonder.land “alice” <sip:asterisk@wonder.land>
march_hare <sip:march_hare@127.0.0.1>
march_hare wonder.land <sip:march_hare@wonder.land>

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:

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@127.0.0.1>
wonder.land “alice” <sip:alice@wonder.land>
march_hare “alice” <sip:alice@127.0.0.1>
march_hare wonder.land “alice” <sip:alice@wonder.land>

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):

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:

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

Contact

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@127.0.0.1:5060>
wonder.land <sip:asterisk@127.0.0.1:5060>
march_hare <sip:march_hare@127.0.0.1:5060>
march_hare wonder.land <sip:march_hare@127.0.0.1:5060>

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@127.0.0.1:5060>
march_hare <sip:march_hare@127.0.0.1:5060>
march_hare chesire_cat <sip:cheshire_cat@127.0.0.1:5060>

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.

No Comments Yet

Get the conversation started!

Add to the Discussion

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

About the Author

Kevin Harwell

Kevin is a Software Developer at Digium. He has a diverse background in the software industry and has worked on an assortment of projects. Since joining the Asterisk team a few years ago he has been a frequent contributor to a variety of areas within the project. He also can usually be seen with a cup of hot tea.

See All of Kevin's Articles

More From
The Digium Blog

  • No items