Equipment receiving calls, whether a humble handset or a sophisticated Call centre ACD system, likes to know the identity of the caller. It may simply display the caller’s number on an LCD display, look it up in a directory so the caller’s name can be displayed or pre-populate a screen with information about the caller recovered from a database. However, the network also needs to know the caller’s identity because it may be important for billing or to notify the emergency services of the caller’s location.
In the UK, a caller may choose to block their ID so it is not visible to the called party by prefixing the dialed number with 141. However, this must not interfere with the more serious network requirements like billing or 999 call location. To accommodate both requirements, telephony signalling protocols tend to use two different pieces of data – a display ID that can optionally be blocked and an asserted ID or ANI that cannot.
The SIP protocol also has elements that allow for all the caller ID requirements.
The From header
The From header provides basic caller ID data and consists of a SIP URI along with an optional display name. Here is an example:
From: “John Quick” <sip:1001@svr2.smartvox.co.uk:5061>;tag=2014274981Unfortunately, it is very easily modified, blocked or spoofed. This generally makes it unsuitable for use by downstream servers on the network which need to have a verifiable caller number for billing etc. For this reason, other mechanisms had to be added to the SIP protocol to overcome the weaknesses.
The Remote-Party-ID header
Many years ago, there was a proposal to extend the SIP protocol to support the use of the Remote-Party-Id (RPI or RPID) header. It was described in an IETF memo, but never gained enough support and traction to be widely adopted. Today, it is very much in the shadow of the P-Asserted Identity header.
The P-Asserted-Identity header
This header – also referred to as the PAI or PAID header – is described in RFC 3325. It explains the requirements for provision of an authenticated caller ID within a trusted network using the P-Asserted-Identity header to convey the authenticated identity of a caller along with a separate Privacy header to show if this data must be hidden.
It contains the authenticated identity information for the caller and is normally inserted by the calling device before the call starts. You might expect to see a PAI header within the SIP INVITE request when a new call is being set up. Its purpose is to provide a verifiable Network-Level Identifier of the call originator.
PAI is designed to be shared and used by service providers who trust each other. It may be used for call tracing, billing or routing by carriers. It is sometimes used for routing decisions or Caller ID presentation within call centres or by PBX telephone systems. It also allows the correct originator’s number to be seen when a call is made to the emergency services.
It may be used alongside the default caller ID associated with the Sip endpoint (generally the From header) and does not have to be the same as the Caller ID displayed on the receiving phone. It is an identifier that should always contain a SIP URI and may also include a display name. It does not necessarily have to be a live number, but it should be a correctly assigned number that can be used to trace the originator.
This identifier is especially useful in situations where the caller wanted to protect their identity by withholding their Caller ID number. The PAI header still provides valid information even when the Caller ID has been deliberately overwritten. In these situations, the intermediate VoIP servers can read the caller’s true identity from the PAI header even though it has been withheld or overwritten in the From header. An additional Privacy header may be used to indicate that the data in the PAID header is not to be revealed. The PAI header field should only be used among trusted SIP entities. Unfortunately, it is easy for PAID headers to leak outside the trust boundaries and be passed to unknown downstream carriers even when the Privacy header demands withholding of information. In this situation, the header should not be passed to the final endpoint and the final endpoint should not present it as a CLI.
Configuring caller ID in FreePBX
FreePBX provides user configurable parameters for extensions, outbound routes and trunks that are used to set a caller ID. Generally the format for these entries is like this:
"caller name" <#########>where the caller name is just a bit of text such as the name of a person or department and ###### represents a telephone number.
As mentioned, you can configure a caller ID that is associated with the extension, another that is associated with the outbound route and a third that is associated with the trunk. There is also scope for having so-called emergency caller ID’s in addition to the normal one. FreePBX has some built-in rules it uses to decide which caller ID may trump another. For example, this is the text from the help-hints in the outbound routes configuration page:
Essentially, the caller ID will trickle down from the extension to the route to the trunk, and it may get overridden at each stage depending if the rules allow and if certain check boxes have been ticked. With a bit of experimentation, it should be possible to achieve whatever outcome you need.
However, this isn’t the complete picture. If you are using pjsip in FreePBX, there are settings within each trunk (under the pjsip Settings > Advanced tabs which control the inclusion of the additional headers RPI and/or PAI:
The settings look like this:
The “Trust” setting concerns handling of PAI or RPI received on inbound calls. The second setting show above is the critical one. It allows you to include an RPI header, a PAI header or both (or none). There is also an option to override the privacy setting. This last option should be used with caution.
Stir/Shaken
Look out for this standard which originated in the USA and will very likely be adopted in the EU and UK. It was introduced to stop or greatly reduce the excessive use of spoofed numbers, especially on robocalling devices. Essentially, it is a new standard in VoIP that should help overcome the feeble security of the existing PAI and Caller ID standards. I wish it luck and look forward to no longer receiving the absurd and irritating calls that start with a long silence, then a short burst of sound followed by a foreign voice trying to persuade me to install dodgy software, put money into dodgy investments, buy dodgy products or give away personal information and bank details.
Leave a Reply