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 break down these differences, 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.



<transition event="connection.alerting">

  <assign name="ANI" expr="event$.connection.protocol.sip.headers['x-sbc-p-charge-info']"/>

  <log expr="'*** ANI = ' + ANI"/>

</transition>

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 the connection object.



<transition event="connection.alerting">

  <log expr="'*** Caller ID via SIP header = ' + event$.connection.protocol.sip.headers.From"/>

  <log expr="'*** Caller ID via connection object = ' + event$.connection.remote"/>

</transition>

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 in CCXML by following this syntax snippet closely:



<createcall dest="'tel:+12223334444'" callerid="'1111111111'"/>

Of course, you can get a wee bit fancier with this if you so desire:



If you want to use variables, here's how you can do it:



<var name="phoneNumber" expr="'4071234455'"/>

<var name="cid" expr="'4075551234'"/>

 ..

<createcall dest="'tel:+1' + phoneNumber"  callerid="cid"/>

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 E64 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.

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

konrad.garus

7/20/2010 7:56 AM (EDT)

In the second example, should it be:

<createcall dest="'tel:+1' + phoneNumber" callerid="cid"/>

Rather than:
<createcall dest="'tel:+1' + phoneNumber + 'callerid=' + cid"/>

voxeoJeffK

7/20/2010 8:05 AM (EDT)

Hello,

Yes, you are correct. Thank you for noticing that error. I have altered the documentation source, and changes will be pushed live when the documentation build is nest performed.

Regards,
Jeff Kustermann
Voxeo Support

Unjoin via termdigit

| TOC

| G: Send Element & HTTP requests