A little while ago, a customer asked if it was possible for a company’s name to appear on the display of their telephones so that they knew who was calling before they answered the phone. For those that do not really know much about telephony, this might sound extremely easy to do – just save the number and then enter the contact’s name. If only it was that simple.
If you have a company with over 3,000 employees, the chances are that these employees will have direct dial numbers which will show up rather than the company’s phone number. Additionally, each phone will need to have every potential phone number for a company saved in its own directory. The permutations of this set up become astronomical when you think that a medium sized company will typically have 3,000 employees. If each of these employees of Company A have a DDI, and Company B also has roughly 3,000 employees, that means that 9,000,000 entries need to be entered on the phones!
One way in which this can be achieved is through the use of TCL scripts, also know as Tickle scripts. The Tickle script runs directly on the Cisco IOS of a router – in this case it will be the voice gateway. The script will run a look up on a .txt or .csv file which will list a company’s name and an associated phone number. Once a call is presented to the voice gateway, the Tickle script will take a hold of the ANI, run a look up on the .txt/.csv file and then send the company’s name directly to the phone.
Obviously, there are downsides to having this script running – especially in a very busy environment. The performance of the router will be considerably affected. This is one thing I mentioned to the customer. Another downside is that the scripts can be extremely flaky, even more so in a very busy environment when there could be hundreds of calls going through the voice gateway every hour.
In the end the customer decided against the script being implemented but my interest in TCL scripts has been piqued, especially as the modifications of what can be displayed on the phones could potentially be limitless – it is also interesting to find out a more efficient way of doing the above without compromising on the routing performance.
Watch this space for developments!