What is speech recognition or automatic speech recognition ?
Automatic speech recognition can be defined as a process by which spoken words are converted to text. Many people may confuse with voice recognition as speech recognition. Voice recognition is recognising the speaker of the voice, while automatic speech recognition recognise the words spoken. While speech recognition is mainly used for menu selection, voice recognition is used for checking authorised user.

How automatic speech recognition can be used in voice portal ?
Voice portal is a large IVR application which provides many value added services to the voice portal user. Normally, voice portals are operated by telecom operators to provide information of their services, activating deactivating services, utility services like matrimonial, job search, listening to music and download, jokes etc. Since voice portals have large information to be provided to a caller, it needs to give out a long list of options. But the DTMF digits or touch tones on a mobile phone or telephone instrument is limited. So automatic speech recognition is used as an alternative to touch tone or DTMF input for selecting a menu option in the voice portal or IVR.

Advantages of Automatic Speech Recognition over DTMF in Voice Portal:
1. Caller can choose a menu option quickly without having to listen to boring long list of menus. IVR can become truly interactive with its caller using same human voice.
2. Using an IVR was always a problem as one he has to remove it from his ear to look at the keypad and press a key. This can be again quite irritating for a voice portal user. Implementation of ASR completely remove this problem.
3. Change of menu or introduction of new options a menu, or shuffling of options in a menu becomes easier as menu options are the words most commonly used by everybody for a particular option. Using a touchtone or DTMF menu, any option was assigned to a DTMF key or a number. With ASR, it is assigned to the word itself.
4. Not many people are aware of # and * keys as they are hardly used in normal operation while IVR seems to use them for some options for very long menus. ASR does not face this kind of problem.

So, one may find it very useful in a developer point of view to use ASR in voice portal as it gives more flexibility for designing menu and presentation of data. But as user point of view it may not that user friendly as touch tone. This mainly due to lack of 100% accuracy in recognising the word spoken by the caller. Wrong detection of words by ASR may result in very awkward menu options and information fetching. One way of tackling this problem is to confirm a user of his chosen option in the menu with a YES or NO for every menu option. But it would be too irritating for a user! A voice portal is normally a premium service where irritating caller is the biggest crime one can commit!

Problems of Speech recognition
1. Accuracy of recognition
Accuracy of recognition can be thought as converting words spoken by a user accurately to ts corresponding text.
As per information available ( by Googling and visiting ASR engine provider websites), almost all ASR engine has high accuracy for detecting two words, YES and NO. Apart from them, other words like numbers, date of births etc. has lower accuracy in recognising. For example, accuracy of recognition of numbers 1,2,3 etc vary from 87 to 91% depending on ASR engine. Accuracy of recognising other natural English language is fare much worse! As per report, recognising departments in company is maximum 85%!
Though accuracy can be improved by training of ASR, but it is not practical at all and does not serve a voice portal.

2. Different accent
Using ASR in a big country where people speak different languages or same language with different accents,speech recognition accuracy is bound to fare worse.

3. Confirming YES/NO again and again is irritating
People may design IVR very intelligently to confirm for any doubtful word recognition by YES or NO, but it is still irritating for many people and it slows down the time for fetching an information. In a voice portal where caller pays by minute of usage, it may not work in the interest of voice portal users.

Still, automatic speech recognition (ASR) is used widely in voice portal now a days and here are the few services in voice portal where ASR may work well :-

1. Contests
2. Classifieds
3. City wise weather information

An interesting IVRS Application for Voice Portal is Voice Chat Application! It can be a real revenue spinner for a voice portal if it is properly moderated, if it has feature like outbound call, background music etc.!

This chat application has two modes:
1. One To One chat
Here two users chat one through voice portal. The connection can happen both ways. User calls to voice portal number and can browse profiles of IVR Chat users and then send request for chat. If the other user is not connected to Voice Portal, voice portal makes and outgoing call to the other user and initiates the chat!

2. Group Chat/Conference ( Moderated or Operator based)
Here many people join a chat room just like in normal chat room in a website. Here a moderator approves any joining to chat room request. Moderator can block any un-parliamentarian chatter. Telephonic talk-show as well as public opinion could be generated and sampled using this kind of chat.

All calls should be recorded through a dedicated voice logger. There should be dedicated moderators. In fact, customer care of a telecom service provider could be modeled around this IVR Chat and Conferencing for better service to customer.

IVR Chat Application in a Voice Portal

Suggested Technical Arrangements :
For better operation, we recommend using a private exchange (EPABX ) for chat application. IRIS IVDX with 512 lines is good option.

Chat Server is connected to this EPABX through ISDN PRI. (easy to integrate)
Here is the tentative option technical process:
1. All calls to voice portal lands on EPABX. EPBX routes the call to Chat Server.
2. Chat Server handles the call, does the patching, OBD calls, conference calls using EPABX conference facility. Normally, this is used for one to one chat.
3. Chat Server also uses Conferencing CTI hardware to conduct its own conference as per requirement. Normally this is used to Group Chat. CTI hardware should be Dialogic or Donjin. Actually it could be any other CTI hardware, but our software supports both Dialogic and Donjin CTI hardware.
4. Moderators or Operators are connected to EPABX locally and brought to conference as per call flow.

I hope this kind of application can increase revenue of a voice portal if it is properly marketed.

Voice based value added service is known as voice portal. This is good revenue source for both mobile and land line telecom companies. Just like SMS Portal, voice portal also provides similar services but accessed through IVR. With advent of voice enabled menu using speech recognition technique, IVR has become very popular as well as user-friendly application for both mobile and land line subscribers.
IVR can be thought as platform to deliver content to users. The content may be anything, from latest news to mobile ring tone. I have written about Technical challenges and commercial challenges in a voice portal in my previous posts. IVR as content delivery platform has advantage:-

1. Its is easy to dial using the keypad while SMS is not easy to type on mobile phones.
2. Few contents are better delivered on IVR. For example, ring tone can be heard on IVR before it is downloaded by user.
3. It is limited by number of characters like in SMS. For example, complete news can be heard on IVR. Same goes for other contents like jokes, breaking news, etc.
4. IVR can be used by any kind of mobile phone instrument. Other content delivery platform like WAP does not work on low cost mobile phones. SMS does not work on many land line telephone instruments. It may be a major factor in a price sensitive market like India where maximum mobile subscribers use low cost handsets. India is a huge mobile market with more than 400million mobile subscribers.

Here I would like to list few services which are popular in India:-

1. Listening to Music
I find it amusing that people listen to music on mobile phone in this era of Ipod, FM Radio etc.! The main reason is, FM is available in major cities in India. The initial investment is high for many Indians for IPod or MP3 players. But many IVR VAS players in India has provided option to listen unlimited songs with a monthly subscription of paltry Rs. 30.
2. Astrology
3. Contests
4. Jokes
Yes, people do hear jokes on IVR!
5. Shayeri
This is an interesting application for IVR VAS.

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.

[ad#large-ad]

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.