Caller ID in SIP

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, for call tracing or to notify the emergency services of the caller’s location.

Privacy laws or local communication regulations frequently mandate that callers be allowed the option to block their ID so it is not visible to the called party. However, this must not interfere with the more serious network requirements like billing or emergency (999/911) call location. To accommodate both requirements, telephony signalling protocols tend to use two different pieces of data – a ‘Presentation Number’ (effectively, a display ID) that can optionally be blocked and a ‘Network Number’ which is effectively an asserted ID that identifies the point of ingress into the communication network. In telephony, Caller ID is often referred to as CLI, which stands for Calling Line Identification. The network number may sometimes be referred to as ANI, which stands for Automatic Number Identification. ANI harks back to the original AT&T specifications used on legacy telephone systems before VoIP had been invented.

The SIP protocol has elements that allow for all the Caller ID requirements – CLI, ANI and privacy.

The From header

The From header provides basic Caller ID data and consists of a SIP URI along with an optional display name. It is equivalent to the Presentation Number or CLI. Here is an example:

From: “John Quick” <sip:1001@svr2.smartvox.co.uk:5061>;tag=2014274981

Unfortunately, it is very easily modified, blocked or spoofed. It may also, for reasons of privacy, be deliberately obscured by rewriting key elements within it; for example, replacing display name and username with “Anonymous”. In the next example, the caller wanted their identity to be withheld so the user’s device – or a SIP server – has overwritten the From header and anonymised the details:

From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as7fb2d045

These weaknesses generally make 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 convey the Network Number.

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 and I will not be discussing it further.

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. Here is an example of a P-Asserted-Identity header:

P-Asserted-Identity: "Oliver Jennings" <sip:441727321123@10.0.0.1>
Privacy: id

This SIP header 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, as shown above, may be used to indicate that the data in the PAI header is not to be revealed. The PAI header field should only be shared among trusted SIP entities. Unfortunately, it is easy for PAI 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. In fact, the PAI header should not be passed to any untrusted downstream server if a Privacy header forbids it. For VoIP service providers, it can be difficult to know where the so-called ‘trust boundary’ is located – it makes sense to pass the Network Number on to downstream servers to allow them to identify the true originator of the call, but not if those downstream servers may misuse the information. But who makes that judgement, and how?

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.

Regulatory constraints, privacy and spam prevention

UK regulations and OFCOM

In the UK, OFCOM guidance requires that most callers be allowed the option to block their ID so it is not visible to the called party. One way of doing this – on a call-by-call basis – is to prefix the dialled number with 141.

OFCOM provides the following document explaining the requirements in the UK:

Guidance on the provision of Calling Line Identification facilities

It’s a useful and well constructed document that UK-based service providers should read. A couple of points worth noting from it:

“Any person making direct marketing calls or calls on automated calling systems must not prevent the presentation of the identity of the calling line on the called line and must present the identity of a telephone number on which they can be contacted.”

“For calls originated on networks outside the UK, the responsibility to check the validity of the CLI Data falls on the Communication Provider at the first point of ingress to the UK network.” and “calls from abroad should not use UK CLI as a Network Number, except in a limited number of use cases”. It goes on to list the exceptions.

Stir/Shaken

Look out for this standard which originated in the USA and may one day be adopted in the EU and/or the 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.