More Than You Want To Know About CallerID, ANI, and DNIS

For those not 'in the know', the terms 'ANI' and 'DNIS' represent the calling number and the called number of a telephone call. Caller ID and ANI are affected by the entire path a call takes to reach its destination and requires perfect communication between the central office and tandem switches all along the routing path. There are many reasons that communication breaks down, from different regulatory environments in the home state of the caller, to choices the caller makes personally, to different (read "antiquated") switch hardware in some locales, to foreign country telephony standards, or to any number of subtle differences in even US standards. Telco programmers make the big bucks keeping track of current standards and figuring out how to translate from one to the other but it ain't easy. And if a particular state or locale forbids a telco from transmitting that information without the permission of the caller, you're out of luck.

One can think of it as being similar to the problem of making a telephone call to a random number selected from all the numbers in the world. What are the chances that the person who answers will speak English? While they're pretty good in some parts of the USA, they're not so good in some other parts. Worldwide, the chances become rather poor.

One common misconception these days is that ANI and Caller ID to be used synonymously. This is not the case. While they're similar, they also have subtle differences. Let's breakdown these differences down, shall we?

ANI (Automatic Number Identification)

- It delivers the billing number of the calling party
- ANI information cannot be blocked by the calling party, and cannot be spoofed.

ANI information can be accessed via the SIP headers. Specifically, the P-Charge-Info header.



  <assign var="ANI" value="'$session.sip.x-sbc-p-charge-info;'"/>

  <log>The ANI is $ANI;</log>

Caller ID

- Caller ID is the originating telephone number the phone company thinks is the subscriber
- It is one of several custom local area signaling services (CLASS) provided by a local exchange carrier (LEC)
- It can be blocked by the calling party, and spoofed.

Caller ID can be accessed two ways: via SIP header, or via session variable.



  <log>*** Caller ID via SIP header: $session.sip.from;</log>

  <log>*** Caller ID via session variable: $session.callerID;</log>

The short answer is that you simply can't trust Caller ID, no matter where it comes from. People use each other's phones. People have many phones. Even if you receive an identifiable call you should verify the caller's actual ID before proceeding, since you don't want the guy who steals your cell phone to be able to access your bank account without hindrance.

Note: This example application requires the enabling of outdial privileges on the Voxeo network, and the provisioning of a alphanumeric token string to your application. In order to get hooked up with all these neat features, check our Support Guide for all the juicy details.

Caller ID spoofing

Due to telco limitations, a DNIS value may not be spoofed. However, these restrictions do not apply to Caller ID, and we may designate a user defined Caller ID value by using the 'callerid' attribute of the <call> element:



<call value="$NumToCall;" callerID="6666666666"/>

CallerID for non-US developers

As the Voxeo datacenters outside of the US are locale-specific (meaning that calls will, by default, route to the regional locale of the datacenter), a country code must be specified in order for the call to reach the intended destination.

Developers who are using, or who intend to use the Voxeo hosted infrastructure in non-US locales sould be aware that we strictly abide by the E164 dial syntax. What this means is that any and all dial strings, and callerID spoofing should apply the explicit E164 syntax:

tel:+[country code][number]

As such, a developer who wishes to place an outbound call to a United Kingdom destination whose number is 02071112222 would specify the following dial string, where "44" maps to the country code for the UK:

tel:+4402071112222

It is not recommended that developers apply E164 formatting to SIP destinations, except in very specific circumstances. Production-grade developers who engage in load testing would be one example of a scenario where this might apply. In the event that you

Country Code Listings

Note that not all countries can be dialed from the UK datacenters due to carrier restrictions. Prior to any production-grade deployments, it is strongly advised that you contact sales@voxeo.com to verify availability beforehand.

There are a number of websites that list the various country codes that are in use. The more useful ones that are available at the time of this writing are listed below:

ANNOTATIONS: EXISTING POSTS

SethStern

1/26/2011 9:50 PM (EST)

G'day!

Just to clarify, it appears from the debugger session log that the ANI is not submitted in the "FirstURL" HTTP request. The CallXML 3.0 script returned from that request does have access to the ANI.

Is there a technical reason that the ANI is not available earlier in the process? It is worth logging as early as possible in handling an inbound call and may be useful in determining whether or not to accept the call.

The ANI can be had (at the remote XML server) by forcing an extra HTTP round trip, e.g. by using a <fetch submit="*"> element, but that seems rather wasteful.

Seth

VoxeoDante

1/27/2011 12:13 PM (EST)

Hello Seth,

The fetch to the initial document should contain munch of the information you are looking for. It may not be referenced as ANI, but rather callerID.

You should see the following line in your logs;

CXV/VXT202.ORL.VOXEO.NET - action: goto value="http://somewebserver.com/dvitulano/callxml/DomValidation.xml
Submit (method="GET" cache=""):
session.ID=4a86b06b96a4ae84d6245f253859311f-380
session.SIPCallID=0-13c4-4d41a5fa-1c1618ea-28e7-1d761de0
session.LastCallDuration=0
session.LastTransferDuration=0
session.callerid=407*******
session.calledid=202*******
session.accountid=*****
session.applicationid=*****
session.outbounddialingflags=icusb
session.ppid=***
session.subaccountcode=
callerID=407*******
calledID=202*******
SubAccountCode=
container.iteration=1

Obviously I have masked much of this data, but it should be fairly obvious on what is available. All of these variables should be passed on that initial fetch.

Will this meet your needs? Please let me know if you are not seeing these values.

Regards,
Dante Vitulano
Hosted Solutions Engineer

[url=http://voxeo.com/prophecy]Download Prophecy 10[/url] | [url=http://docs.voxeo.com/prophecy/10.0/home.htm]Prophecy 10 Docs[/url]

SethStern

3/15/2011 2:51 PM (EDT)

Dante,

Pardon my disappearance. We were waiting for some prototype hardware.

My understanding is that "caller identification" is subject to several problems that do not affect ANI:

1. It can be blocked by the caller.
2. It can be lost during the routing of a call between carriers.
3. It can be spoofed by the caller.

Our application determines the action(s) to take based on the incoming caller's telephone number. Without having access to the ANI before accepting a call it appears that we cannot implement a "white list" of acceptable numbers. Instead, we would have to incur the expense of accepting all incoming calls and subsequently verifying the ANI and either disconnecting or proceeding.

As an aside, where is the syntax for ANI strings documented? There is clearly more than just the originating telephone number in the string.

Thanks,
Seth

VoxeoDante

3/16/2011 1:24 PM (EDT)

Hello Seth,

You are correct, callerID can be both blocked and spoofed. It can also be lost, but so can ANI, when this happens, it is normally replaced with a local exchange number.

That said, your first assumption is correct, we would need to capture that data at the application level, then make a request to your server to send the data. It is not available before hand sadly. You could just write a simple static XML document and host it on our server which grabs the value and passes it to the back end to avoid the extra traffic.

Regards,
Dante Vitulano
Hosted Solutions Engineer

[url=http://voxeo.com/prophecy]Download Prophecy 10[/url] | [url=http://docs.voxeo.com/prophecy/10.0/home.htm]Prophecy 10 Docs[/url]

Answering Machine Detection

| TOC

| Transfer & Call Variables