One of the most irritating aspect of IVR ( Interactive Voice Response) System is having to listen to the complete prompt before making a choice. While this is essential for first time dialer to the IVR system, it is really irritating and time consuming for regular callers who already know the options. So, many IVR systems give an option to press option Keys during the announcement is going on. While using speech enabled IVR where commands are entered through voice, the same procedure is followed.

So a good IVR System should be intelligent enough to recognise the first time caller and frequent caller by capturing and storing Caller ID. This may be useful specially in customer support IVR provided in Telecom companies. It may increase usability of IVR to some extent. Also, there are many IVR applications where entering data by DTMF is much faster, accurate and desirable.

But this same “Key Press Through” can be a reason for other type of problems in some cases. In many practical IVR implementation, multiple Keys (DTMF – Dual Tone Multiple Frequency) or digits required to be captured in the form of PIN ( Personal Identification Number ), Credit Card Number, Customer ID number, Mobile Number, Date format in DD-MM-YY format, amount etc.

These multiple digits entries are normally terminated by pressing HASH key (#) or Star (*) Key or some time just maximum allowed digits or maximum allowed inter digit pause.

For example, it is always a practice in IVR to get the multiple numbers or values entered by IVR user confirmed by pressing 1, to renter press 2. So in a scenario of entering Customer ID of 5 digits length, IVR caller is allowed to press 12345# or just 12345. In both ways, if the IVR user presses the numbers correctly and wait for some response from IVR, it is good, but what happens when a user presses like 123451 continuously or 12345#1 continuously ? Chances are, if the press through is enabled, the IVR will skip the next confirmation step having received the key 1 already pressed and user will not even hear the confirmation prompt!

Also, it is important to decide how the error prompts a well as time out prompt would be played depending on the number of digits entered. Many clients may want to play an “Invalid Customer ID” prompts when a caller enters 123451 as it exceeds maximum length of Customer ID. Explaining these small but important features, options to customer might become cumbersome when clients do not understand them!

But it will also serve as shortcut for the smart IVR user who can bypass the irritating confirmation step by already pressing 1 along with the Customer ID.

So, in case the IVR wants the user to listen out the confirmation prompt, IVR developer can disable “Key Press Through” feature while playing Confirmation prompt, while allowing it in longer menu option prompts.

This is a small details while developing your IVR applications, but this can improve usability of the IVR and also improve accuracy of data entered by user. It will also make smart and regular IVR users happy as it provide them a shortcut to avail the information provided by the IVR.

Few days ago, I had posted about using IVR ( Interactive Voice Response) System in mission critical operation in underground mining operation. Continuing int he same line, there is another interesting IVR application which is useful in our day to day life and can prove to be life saving at times! That is IVR based automatic pill reminder service.

In short, automatic Pill reminder service is essentially an outbound IVR which is capable of dialing out programmed phone number of the patient at programmed time automatically without any manual intervention. When the call is connected, it will play a recorded message and then wait for confirmation whether the patient has taken the medicine or not. When the patient dos not respond the call or confirm the medicine taken, IVR will raise an alarm either by sending an email or SMS to medical staff responsible for the patient’s hospital so that some manual intervention can be taken immediately depending on the severity of the timely medicine!

This kind of automatic pill reminder service can be hosted or on premise IVR system. In India, Niche Tech Services (P) Ltd offers both on premise as well as hosted IVR based automatic pill reminder service.

Few essentials in pill reminder services are :-

1. It should support different language for different patients

The IVR should be able to play messages in different languages so that save IVR system could be used to alert many patients.

2. It should be be able to record response from patient

The pill reminder service should be able to accept some response either DTMF ( Dual Tone Multi Frequency) press or automatic speech recognition. Automatic Speech recognition ( ASR ) may work well since it will just need YES or NO response from the patient.

3. It should provide alarms

The IVR should be capable of raising an alarm to concerned doctor or medical supervisor responsible for the patient immediately if the patient fails to respond to the pill reminding call or respond about the medicine taken in negative. Timely intervention by a medical supervisor may prove to be life saving exercise at times.

4. It should have MIS

The system should be able to provide patient wise, call wise MIS ( management information system) so that complete medical history for the patient could be organised. It should also store all responses by the patient.

Having IVR based pill reminder system offers many benefits. For example, now a days everybody keeps a mobile phone with him all the time and always attentive to any call. So, alert system using a telephonic call has more chances of being attended.

Getting response and storing them is useful information for he doctor for analysing about the patient responsiveness to the treatment.

Using phone is one of the cheapest and better option that having any web based reminder system or alarm system. An IVR can precisely play a message about the type of medicine the patient is required to take at that time. This will help the patient to concentrate on his regular works having to remember about his medicines and worry about it all the time.

So, if you have a hospital or medical service facility, it is time you put automatic IVR based pill reminder system in place to serve your patients better! Even call centers can offer this service to many large hospitals and health care industries.

Recently, I have started getting mails about asking open source IVR as well as its availability for free, download-able from internet! Most of the people who have asked me about “‘Open Source IVR” have heard about Asterisk. Before going into the details about Asterisk, being open source IVR, I would like to clarify few things about IVR ( Interactive Voice Response)  System.

IVR system consists of  four components, one can say. They are :-

1. CTI ( Computer Telephony) board
2. Call Flow development as per requirement
3. Voice prompts, TTS ( Text To Speech) Engine  and ASR (Automatic Speech Recognition) Engine
4. Host PC or Server for #1 through #3 above.

1. CTI ( Computer Telephony) board

CTI board is a hardware and I m quite sure, nobody will make it ‘open source’ or free for anyone! The other alternative is SIP ( Session Initiated Protocol) on VoIP ( Voice Over Internet Protocol). But for connecting to PSTN ( Public Switched Network), TDM based CTI Board is a must and there is no alternative, as of now!

All CTI boards come with their own set of API ( Application Programming Interfaces) to control telecom protocols and call handling. Dialogic, the biggest CTI company provides many APIs as well as sample codes in three major operating systems, Windows, Linux and MAC OS. Likewise, other CTI vendors too provide their proprietary C++ API for at least two OS.

2. Call Flow development as per requirement

There are many online as well as offline call flow development tools. Some Call Flow development tools are completely pictorial visual tool where one can drag and drop various call flow like components to make a call flow. Some others use simple ‘English’ like/natural language like scripts to define call flow. Incidentally, all these tools are free to use for developing the call flow, but to execute these call flow, one has to pay per port licenses.

VXML is standard call flow development language adopted by W3 which uses HTML like simple syntax. Presently this requires a third party interpreter which again requires per port licenses.

3. Voice prompts, TTS ( Text To Speech) Engine and ASR (Automatic Speech Recognition) Engine

Voice prompts are normally recorded in a studio by professional artists. One can also record voice prompts using computer/laptop and MIC for development purpose. There are many open source, freely available TTS. Even MS SAPI is freely available. eSpeak, a popular TTS which has support for many languages from all around the world, is an open source TTS which works well both in Windows and Linux.
Likewise there are many open source ASR that works well after refinements.

Now, major challenge is to integrate all these components and build a reliable IVR system. Now a days, IVR is no longer simple call flow of yes and no by the caller, but complex system with data retrieving from multiple sources. It performs complex task as well compute input data by caller, make a decision and respond to caller with appropriate answer.

Most of the time, making an informed choice of IVR which is most suitable for a particular IVR application is quite difficult.

Now finally, Asterisk is a truly open source telephony system with IVR facility. It is Linux based and supports many CTI hardware and many developers contributing to it. It is a completely DIY ( Do It Yourself) IVR platform. It may not be easy to develop an IVR system quickly for a beginner using Asterisk from a scratch. At the end, it may be as difficult as building IVR using native API available with CTI board itself.

Many high density and widely deployed CTI hardware are not supported by Asterisk. This is one disadvantage which Asterisk will take some time to overcome. And at the end, while some one tries to customise Asterisk, he might end up with his own proprietary piece of codes, specific to some CTI hardware only!

Advantage of using API of CTI board is the freedom of choice of operating system as well as programming language. Programming languages like C++ offer power of ‘real programming’ language to complete complex tasks as well as integrate with any third party software.

So, one may not have much choice as Open Source IVR!

Recently, I have been able to test VBVoice 5.6.2 using Dialogic D300 springware board as well as HMP 3.0. Mr. Sean from Pronexus has been kind enough to configure and give us a presentation to quick start developing voice application.

VBVoice IVR Toolkit : Power to Programmer

VBVoice is one of the most powerful IVR toolkit which is available in Microsoft .NET Integrated Development Environment as simple controls/components to develop powerful CTI application/IVR Software with any kind of computational need in the back ground. Any .NET developers using either VB .NET, C# can use its “CTI Building Blocks” to start building any kind of IVR system with complex call flow. This is one tool which has no limitation on computational capabilities except the limitation of .NET environment itself or programming skill! One need not worry about implementing smart features of any IVR Software DTMF, ASR, TTS, VBVoice has all features built into it.

We prepared two different machines with Windows XP OS, one each for Dialogic D300 springware board and HMP 3.0. And we installed required Dialogic System Release 6.0 for D300 board and HMP 3.0 as well as VBVoice 5.6.2. Mr. Sean from Pronexus had remotely activated license for VBVoice.

First we configured Dialogic HMP Software an activated four channel licenses for VoIP calls. Once it was done, we opened Microsoft Visual Studio 2005 C# project and loaded some VBVoice sample application. And it worked in single click! We used X-Lite installed in different computer on the same LAN to make voice calls.

After that we wanted to check with TDM board (Dialogic D300) in other machine. Since we had already activated VBVoice license on other machine with HMP, we needed to access the same license from this machine with TDM board through LAN. It was a simple configuration.

Once the license was done, we created a simple Inbound IVR to select Language on DTMF keypress using Microsoft Visual Studio 2005. It was done in less than five minutes and we could make calls to our PRI number and select languages.

VBVoice has both GUI tool for editing and configuring its various options like License settings, Telephony Interface type etc. For advanced users, one can simply edit the configuration text file quickly. Depending on the active licenses, all the controls, components gets loaded in .NET IDE, ready to be used! Any call flow can be created visually by dragging these controls and dropping on the design form. After that, one may simply configure the required DTMF keys, point to next menu options etc. All finer details like number of DTMF digits to accept, total delay time etc. are available for configuration on each control/component. After creating and setting the properties of these components, component’s events allow using code ( C#, VB .NET) to customize further the behaviour of the components at runtime depending on user input or any other external event.

VBVoice : Powerful IVR Toolkit

One of the interesting feature of VBVoice is Worker thread. It allows programmer to create separate thread for doing some computation separately without holding the main IVR Call Flow thread. For example, the Worker thread may try to access remote database server, access API, do some computation, billing etc. before giving feedback to main IVR call Flow thread.

To learn about more features one may visit Pronexus : VBVoice – IVR ToolKit.

We have been able to develop a few IVR applications in response to inquiries from our clients to give them POC (proof of Concept) about our IVR capabilities using VBVoice in very short period of time and could impress them suitably.

It also provides controls to dynamically create list of voice files from pre-recorded WAV files without using TTS which is played for menu selection. This kind of intelligent dynamic menu has been forte of C++ developers till now.

Like any other great products, VBVoice has one drawback, presently it supports only Dialogic boards. It does not support Sangoma or other cheaper cousins of Dialogic.

According to Pronexus representative, roadmap of VBVoice includes support for H.263 video play using Dialogic HMP and running VoIP in virtual machines. It will be available for testing very soon. So, we may be able to develop IVVR (Interactive Video and Voice Response System) pretty soon using VBVoice! In the age of 3G and IPad, VBVoice is going to provide exciting time for IVR developers!

In order to get evaluation version of VBVoice : one may contact me or Pronexus Directly : Get VBVoice or Write to Mr. Steve Brown, V.P. Sales at: steve.brown@pronexus.com.

There are few parameters or features of IVR which are important and are common to almost any type of IVR application. These parameters play very important role in making the voice application more user friendly. These parameters are used at many stages in IVR software or in any call flow. I hope, knowing these would help people who are looking to develop an IVR or looking to purchase IVR software.

These are very small parameters, but they may play crucial role in reducing call abandon rate in IVR. Some of them are :-

1. Allowing or not allowing caller to press a key while IVR plays the menu options

IVR may be configured to accept or to reject any key press while caller is listening the menu options. Allowing to press key during playing of menu allows caller to ‘cut through‘ the IVR menus and reach his desired IVR stage or menu quickly. But it may also increase chances of wrong key press, specially when some menus options are changed. Many regular caller may not like to hear known menus again and again.

2. Duration to allow a caller to press any key or voice command

Waiting time for callers key press or voice command may become crucial. During wait period, IVR does not play anything and become silent, so if this wait period is too long, caller may think the IVR is not responding, so disconnect the call.

3. How many times to play a same menu and number of attempts to choose correct menu options

Naturally, people make mistakes while pressing key or may make mistakes intentionally. So, it is important to decide the number of attempts one may try for each and every menu options. This kind of parameter may be required even while accepting some valid input from caller, for example mobile number, customer ID, complaint ticket etc. If this is not defined, then some caller may occupy some channel of the IVR unnecessarily.

4. Confirming menu menu selection of digit (s) pressed or voice command spoken

It is an important decision to make. Should IVR confirm every menu choice made by caller or not! Even in any software, when some one tries to do some important task, it pops up an confirmation window, similarly, IVR also ask confirmation for menu choice! But it may also irritate IVR caller. When using ASR ( Automatic Speech Recognition), confirming every option may become a necessity rather than a choice.

5. Inter-digit pause while expecting more than one DTMF keys as input from caller.

While caller enters multiple digits as input to the IVR, for example, credit card number, phone number, ID number, the duration of pause in between two consecutive DTMF digits or key press is important. Very long inter digit pause may result caller disconnect.

6. Using # ( hash) or star (*) keys to terminate

Deciding to use # or * keys to end entry of multiple digit is a good option. But these keys may also confuse some people who do not know about # or * keys as many of them do not use these keys. In India, many land line phones do not have # key. But with penetration of mobile phones, one may expect people to know about these keys.

These parameters are quite common and many developers use some configuration files or provide user friendly forms to configure.

It may not be easy to define a successful IVR ( Interactive voice response) System. In single line, one IVR system could be termed successful when it has lowest abandon rate by both genuine new and old callers. When an IVR system is designed to perform some specific task for a caller, if the caller completes those tasks using the IVR easily at the shortest time possible, then the IVR will have very less abandonment rate and the IVR could be termed successful IVR.

For example, if one IVR system retrieves outstanding bill for telephone number, the caller should be able to hear his/her outstanding bill at the shortest possible time, without failure with having to choose minimum options, either using DTMF/Key-press or voice command. If the caller disconnects the call before he hears his outstanding bill amount, then it would be ‘abandon of IVR call’. But if the caller listens to his outstanding bill amount, and then disconnects the call, it is ‘successful IVR call’.

So, apart from technical challenge (developing the IVR software, integrating with PBX/ IP-PBX etc.), the major consideration for IVR or any voice application for matter, remains making the most user-friendly IVR call flow or Voice User Interface (VUI) design. So, success of IVR will depend on majorly on the VUI design! The callers who are the users of IVR system, will care little about the technology involved for developing the IVR system and will care about only the information they want. If they do not find it easy to get the information they want, IVR system is useless for them. ( One may check #ivr #ivrs trending in twitter.com to find how people hate about IVRS, everywhere in the world!)

There are two types of caller, new caller and old or regular callers to any IVR system. One of the most common complaint by regular caller is the change of menu options! In any customer care IVR system, normally, regular caller outnumber new callers, if call flow is changed, suddenly, there is no longer any old or regular caller for the IVR as everybody becomes new caller. Everybody will have to listen to all menu options as long as the prompts play! This increases not only abandon calls, but also increase time spent on the IVR system by callers! Normally, IVR system should aim to complete its ‘task’ at the shortest time, to server more caller with fixed number of lines.

Recently, I have experienced increase in demand from IVR users who wanted to have options to change the call flow using some visual tools, I always wanted to discourage them! Though visual tool is an excellent way for developing IVR application, it should not be used to keep changing the call flow quickly or just for the sake of changing it and just because one has a easy visual tool to change it! Else the very purpose of installing IVR system would be defeated and one will own a failed IVR system with high call abandon rate!

Designing IVR call flow is very important for success of an IVR deployment, and sticking to the same call flow is also equally important. Call flow should be changed only when it is a must, other wise IVR call flow should not be changed. One is sure to see spike in abandoned calls when call flow is changed.

Everyone involved in IVR industry may have heard reasons why normal users, customers ‘hate’ using IVR ( Interactive Voice Response) Systems. There are many reasons why people hate using IVR and how IVR could be made more user-friendly with good VUI design practices. I thought I would update top five things about IVR that people hate about.

1. Duplicate Information

When customer calls to any call center looking for support, query etc., they are normally answered by IVR and customer needs to provide their information like phone number, account ID etc. ( depending on services they subscribe to). After all these ‘question-answer-round’ and agonising repeat-confirmation round by IVR, customer is finally connected to a CSR or human agent. But immediately, customer is asked the same questions which he had already answered to IVR!

Simple POP-UP screen at CSR dsktop is the solution and many call center do not use them and the customer ire falls on IVR!

2. Being on-hold for long time before one may speak to human agent

After customer’s call is connected and then when she chooses to speak to human/live agent, IVR takes long time to actually transfer the call to live agent as live agents are busy. While everybody agrees that human resources are costly, but so are the time of customers/callers! This long time required for successful call transfer to human agents make customer hate IVR.

Smart predictive dialer is one solution to this.

3. Irritating music on hold/advertisement

As if making wait to speak an human agent is not enough to antagonize the caller, many people use IVR to play irritating music or advertisements while call hold! Imagine, one customer wants to complaint about a service and he gets to listen to advertisements about the same service while waiting to lodge her complaint against the very service!

It is not possible to play music which would be liked by everyone. Simple all waiting tone or announcing of time remaining till CSR would be free to attend the call should be good enough information during call wait.

4. Having to repeat YES/NO in ASR and DTMF pressing

Many ASR ( automatic speech recognition) repeats the answer by the caller and asks to confirm by speaking YES or NO. While this may be a required step for validating user input for IVR developer, but it becomes irritating for a caller having to confirm every answer or repeating the same. It is not easy to press telephone keys using a mobile phone, so many people simply hate IVR for making them press DTMF keys!

Looks like IVR will not be able to come out of this!

5. Long Menu

Some IVR of call centers really provide long menus or long options to choose from! If there are 9 options in an IVR and if IVR plays them as soon as caller is connected, most probably, caller would disconnect his call before he hears the 3rd option! Many people hate IVR for making them hear options which are not required by them!

We can hope, with smart IVR systems and good VUI design practice, this hatred can be reduced.

What is Speaker Verification
Speaker verification, also known as speaker recognition, can be defined as process of authenticating ones claimed identity by comparing their voice and previously recorded or computed speech characteristics (voiceprint, which is as unique as finger print ). While speech recognition is widely used in IVR, speaker verification or recognition is different than speech recognition and is relatively recent addition to numerous usage of IVR systems.

Speaker verification is one of the recent and advanced IVR feature which is increasingly being used some IVR applications where personal identification is very important, for example, Banking, attendance registration etc.

How it can be used in IVR ?

As the name suggests, speaker verification is essentially used for authentication a IVR caller to manage his account. Since now, IVR systems have been authenticating its caller with ‘password’ or PIN ( Personal Identification Number) by pressing telephone keys or DTMF or even speech recognition.

Normally, while using speaker recognition for user authentication, IVR caller is asked to speak a random phrase which is compared with caller’s existing voice print. This is a quicker process for user authentication.

Advantages of Speaker Verification

The age-old IVR user authentication method of asking caller to enter a 4 digit ( or 5 digit) PIN is slow as well as it needs to changed periodically. But with usage of speaker recognition, authentication process is faster and IVR may ask a caller to speak any phrase randomly without user having to remember PIN or keep changing it periodically.

Another method of caller verification was using ANI (Automatic Number Identification) or Caller ID. But though detection of caller ID is fool proof, but this kind of user authentication may not be fool proof as anybody could dial from user’s phone number. But speaker recognition with voice print does not suffer from these drawbacks. Speaker recognition along with speech recognition may provide almost fool prof user authentication.

How it helps usability of IVR

With speaker recognition, customer details could be retrieved quickly from CRM ( Customer Resource Management) and many routine questions to a caller could be avoided. Caller would be happier not having to repeat his information each time he calls to the IVR.

Since it authenticates a caller much faster, it can provider any service quicker to the caller and usability of the IVR increases.

Many people may feel frustrated having to enter PIN or change it periodically for security reasons. But with speaker recognition, a caller just has to speak a given phrase and can authenticate herself. Many people. specially the one, who use call center or IVR rarely, may forget PIN. With speaker recognition, user does not need to remember any PIN or change the PIN periodically.

Like any other computer software, IVR too work inputs of responses provided by the user. Though, a computer application software has widely used input devices like keyboard, mouse, voice, even hand movement, IVR applications have limited, only two types of inputs or responses. One is telephone keypad which has 12 keys and automatic speech recognition!

Another specific difference between a normal computer application software and a IVR software is, IVR can provide the options sequentially in voice while computer application software can software options in various menus, buttons, drop down menu, quick links using related graphics etc. So IVR provides its options or tasks it can perform to a caller in series of voice announcement along with key option to press or word, phrase to speak for choosing the tasks. This is known as IVR menu.

With advent of hosted IVR services, IVR application has become designing of this menu system only, while the integration of CTI hardware with various PBX systems have become standard modules provided by hosted IVR service provider.

Irrespective of direction of call of the IVR ( inbound IVR or outbound IVR), menu starts as soon as the call is picked up. Normally, IVR starts with a “welcome prompt” typically welcoming the caller with greetings and quick short brief about the service, organisation behind the IVR.

IVR menus can be divided into two types depending on how user give commands to IVR application or how user responds to its menu options, DTMF(DualTone Multiple Frequency) or Telephone driven and ASR (Automatic Speech Recognition) driven. Both have advantage and disadvantages and are widely used. ( Click here for more about DTMF driven menu or ASR driven menu)

Apart from above two types of IVR menus, it can also be divided another two types depending on how menu options are generated.

1. Menu options can be recorded using a voice artist in studio and played back.
2. Menu options can be generated using TTS (Text to Speech) converters.

Again, choices in a menu, may be static or dynamic. When the choices in a menu are fixed for the IVR system, than the menu can be called as static menu while if the menu options changes dynamically depending on caller id, time of the day etc., than the menu can be called dynamic. For example:-

In a call center IVR, if a registered customer dials, he may be given different options while an unregistered customer would be presented a different options in the IVR menu.

Many people do not like TTS generated menus as one can make out the difference between human voice and TTS generated voice, specially in India, it has mainly to do with accent of the voice. TTS can be very useful in dynamic menu as well as presenting data retrieved from database where playing recorded voice may not be possible all the time.

Usability of an IVR depends mainly on the design of IVR menu. For more about usability one may check this : Usability of IVR systems.

An IVR user is interacts with IVR through it menu only. So it is very important to design IVR menu which is easily understandable to first time callers. Previously people used Visio like tools to design IVR menu. But now a days, almost all IVR development tools come with powerful, feature rich visual IVR menu designer giving DYI(Do It Yourself) feature for IVR customers.

I keep getting mails by various people about detecting caller id using D4PCI and Dialogic API. I remember I too had to try hard once and finally contacted Dialogic support for getting ideas how caller ID could be detected using D4/PCI analog CTI board from Dialogic. I think the same procedure should work for Donjin Analog boards as well as any kind of Analog CTI boards, for that matter.

So the steps for detecting Caller ID in D4PCI board is :

1. As soon as you detect RINGING, do not connect or answer the call. But start detecting digit using appropriate API function. For example dx_getdig();

2. Important part is the settings in DV_TPT structure which is used in dx_getdig() function. Here is how I have been configuring:

• End of DX_MAXDTMF should be configured to be length of expected Caller ID length.
• DX_MAXTIME should be configured to be delay between two rings.
• Since DTMF digits for Caller ID are sent together quickly by the PBX, one may take advantage of the option DX_IDDTIME ( Inter-digit Pause).

3. As soon as one comes out of from dx_getdig() function either because of DX_MAXDTMF,DX_MAXTIME or DX_IDDTIME, one should check if Caller ID is detected or not!

So these are the three simple steps for detecting Caller ID using D4PCI board. Here is the C++ code snippet:-

DV_TPT tpt[4];

// Allocate memory
memset( tpt, 0, (sizeof( DV_TPT ) * 3) );

/* Terminate GetDigits on Receiving MAXDTMF Digits, Interdigit Pause and MAxrime */
tpt[ 0 ].tp_type = IO_CONT;
tpt[ 0 ].tp_termno = DX_MAXDTMF;
//tpt[ 0 ].tp_length = MAXDTMF;
tpt[ 0 ].tp_length = digits; // Number of digits of expected caller ID
tpt[ 0 ].tp_flags = TF_MAXDTMF;

// Terminate dx_getdig function after 3 second Interdigit pause
tpt[ 1 ].tp_type = IO_CONT;
tpt[ 1 ].tp_termno = DX_IDDTIME;
tpt[ 1 ].tp_length = 30; // Gap in betwwen digits
tpt[ 1 ].tp_flags = TF_IDDTIME;

/* Terminate GetDigits after 8 Seconds */
tpt[ 2 ].tp_type = IO_EOT;
tpt[ 2 ].tp_termno = DX_MAXTIME;
tpt[ 2 ].tp_length = 80; // Maximum time
tpt[ 2 ].tp_flags = TF_MAXTIME;

if (dx_getdig( voiceh_handle, tpt, &(dtbuf),(unsigned short)ASYNC ) == -1 )
{
printf(“getdtmfs return 0x%X\n”, ATDV_LASTERR(pline->voiceh));

}

So here are few facts I have realised:-

1. D4PCI board ( or any analog board in that matter ) may not detect caller ID all the time completely (all the digits) all the time. It has nothing to do with the Dialogic CTI board though. The reason can be explained as below :

Normally, caller ID is presented in the form of DTMF ( Dual Tone Multiple Frequency) digits after the first ring and before the second ring.

I have observed that, some times, analog board fails to detect the first ring and detects the ring from the second ring only. It this case, any CTI application would miss the caller ID completely. Some other times, the analog board (D4PCI or equivalent analog CTI boards) would detect the ring at the end of first ring cadence which may result in missing first few caller ID digits.

So, detecting caller id perfectly using analog board may depend on PBX being used. If any one knows any better technique, it will be great to share here.