The only direct revenue generating IVR Application is Voice Portal. I have posted about using IVRS as Voice Portal before. There I tried to explain the overall Voice Portal operation. Here I would try to discuss about technical challenges of developing and running a voice portal.
I would say, Voice Portal Application should be broadly divided into three tasks.
1. Call Handling
In a voice portal, many calls land on the IVRS Application simultaneously. The number of calls at one time depends on the number of voice resources hardware used. There are not many CTI cards which provide high voice resources in a single board. Server PCs too have 3 or four PCI slots only. So, in a single server, one may not have very high number of voice resources. Though there are various ways to connect voice resources between separate servers, one IVR application is going to work on a Single Server only!
Presently I have worked on one server ( IBM X3400) that has one Dialogic SPCI4 and two DNI2410 connected through CTI cables. We have total 480 Voice Resources and we have experienced 480 calls during Class X board examination result. And our server dutifully crashed too ! I still do not know why it crashed due to CTI card failure, Dialogic HMP Crash or Our IVR Application simply crashed! A quick restart of the server itself was the quickest remedy and also calls began to decrease with time, but this experience has forced me thinking to handle large number of calls without Server crashing or needing to restart.
For any large voice portal SS7 protocol is the best and most suitable connectivity with Switch. It gives many flexibilities in the design, architecture and scalability.
So, with the above experiences, I would say one should design IVR Application with the following points in mind:
1. One process should only handle one call.
2. This process should implement only the call flow part and interact with Call related Messaging exchange with CTI device driver. It should though give out periodical status and updates to another process which will record those updates.
3. Event Driven Designing might be better proposition than synchronous status driven design.
4. Application should be built with online debug and monitoring facility. .NET remoting seems to eb an excellent option. I have no idea if there is any Linux Equivalent of .NET Remoting.
5. Activity Logging Facility should be there with another process. The call handling process should not be given any other task other than call handling. I have observed major problems occurring with other tasks like writing to disk, database etc. which might crash the call handling process.
2. Database Handling
Voice Portal Application generates huge amount of database records. Mainly apart from mandatory, CDR ( Call Data Record), it is expected that it records each and every activity by the caller. This produces in turn huge records. Many people tend to overlook this during designing of Voice Portal and pay heavy price later. And these many people includes me for sure. All database handling tasks should be given to dedicated process whose sole activity is to insert and fetch data by Call Handling Process.
My personal preference of database is MySQL as it is free and MySQL 5.0 and above have really cool features! But MS SQL is easy to install, learn and compartively larger trained manpower available.
Here are few guidelines I wish I had followed:
1. Two Tables one for Call Log and another for Activity Report are very important! So these two tables must be designed very well keeping in mind that these two tables will be used for many inserts as well as fetch during billing calculation.
2. Proper Indexing and avoiding data types like varchar, or any other datatype which takes longer time to process should be avoided.
3. Professional DBA should be given the task of Database design is the bottom line while IVR Engineer should restrict themselves to Call handling Part!
3. Content Management
Content management is often overlooked part of any Voice Portal Application! But once the above two tasks are complete and works flawlessly, its is the Content Management that needs constant upgradation with news services, applications! So, designing CMS application at the beginning of Voice Portal development should be stressed and followed. If possible, I would say Billing Computation should be totally seperate application than CMS.
I would say the following points to should be kept in mind:
1. CMS should support only local site (Single Site) or has to support remote site (Multiple Sites) too.
2. CMS Should have facility to check content before actually uploading the content. It should forcefully ask remainders to play the content once. Though its annoying, but it will help adding wrong content at wrong place!
3. It should support various wave format/ mp3 format conversions.
4. Should have remote FTP facility for remote upload/download.
hmm! Pretty Long and boring Article! Well, these are my own experiences and I have not actually developed very large Voice Portal yet. I tried Googling/Yahooing a lot about information about Voice Portal Development, I did not find many useful information. So I thought myself writing one! Please help me with your valuable input. I am a quite newbie here! Thanx in advance.