Voice portal – technical challenges
The only IVR application generating direct revenue is Voice Portal. I’ve posted about using IVRS as a voice portal before. There I tried to explain the overall working of Voice Portal. Here I would try to discuss the technical challenges in developing and managing a voice portal.
I would say that the voice portal application should be divided into three tasks in total.
1. Call handling
In a voice portal, many calls land simultaneously in the IVRS application. The number of calls at once depends on the number of voice resource hardware used. There are not many CTI cards that provide high voice resources in a single board. Server computers also only have 3 or four PCI slots. So in one server one may not have a very large number of voice resources. Although there are different ways to connect voice resources between separate servers, an IVR application will only run on one server!
I have currently worked on one server (IBM X3400) which has one Dialogic SPCI4 and two DNI2410 connected via CTI cables. We have a total of 480 voice resources and received 480 calls during the class X board exam result. And our server dutifully crashed too! I still don’t know why it crashed due to CTI card failure, Dialogic HMP crash or our IVR application just crashed! A quick restart of the server itself was the fastest solution and also the calls started to decrease over time, but this experience got me thinking about handling a large number of calls without the server crashing or having to restart.
For any major voice gateway, the SS7 protocol is the best and most appropriate connection to the Switch. It gives a lot of flexibility in design, architecture and scalability.
So, with the above experience, I would say that one should design an IVR application keeping the following points in mind:
1. A process should handle only one call.
2. This process should implement only the call flow part and interact with the exchange of call-related messages with a CTI device driver. However, it should give periodic status and updates to another process that will record those updates.
3. Event-driven design may be a better proposition than synchronous status-driven design.
4. The application must be built with online debugging and monitoring capability. Remote .NET seems to be an excellent option. I have no idea if there is a Linux equivalent of .NET Remoting.
5. The activity logger should be there with another process. The call handler process should not receive any tasks other than call handling. I have observed major issues occurring with other tasks such as writing to disk, database, etc., which can crash the call handling process.
2. Working with a database
The Voice Portal application generates a huge amount of database records. Mainly apart from the mandatory CDR (call data recording), it is expected to record every activity of the caller. This in turn leads to huge records. Many people tend to overlook this during Voice Portal design and pay a high price later. And those many people include me for sure. All database processing tasks should be delegated to a dedicated process whose sole activity is to insert and retrieve data from the call processing process.
My personal database preference is MySQL because it’s free and MySQL 5.0 and up has some really cool features! But MS SQL is easy to install, learn and relatively more trained staff available.
Here are a few pointers I wish I had followed:
1. Two tables, one for call log and another for activity report, are very important! So these two tables should be designed very well considering that these two tables will be used for many insertions as well as retrievals during billing calculation.
2. Proper indexing and avoiding data types like varchar or any other data type which takes more time to process should be avoided.
3. The professional database administrator should be given the task of designing the database, while the IVR engineer should limit himself to the call handling part!
3. Content Management
Content management is an often overlooked part of any voice portal application! But once the above two tasks are done and working flawlessly, content management needs constant upgrade with news services, apps! So CMS application design at the beginning of Voice Portal development should be highlighted and followed. If possible, I would say that Billing Computation should be a completely separate application from the CMS.
I would say that you should keep the following points in mind:
1. The CMS should only support a local site (single site) or should also support a remote site (multiple sites).
2. The CMS should be able to validate the content before actually uploading it. It should force the leftovers to play the content once. Although it is annoying but it will help to add wrong content in wrong place!
3. It should support various waveform/mp3 format conversions.
4. Must have remote FTP facility for remote upload/download.
hmm! Quite a long and boring article! Well, this is my own experience and I haven’t actually developed a very large voice portal yet.
#Voice #portal #technical #challenges