Log in

No account? Create an account
Telecom, Technology and Me
[Most Recent Entries] [Calendar View] [Friends]

Below are the 15 most recent journal entries recorded in Jayakrishnan K.'s LiveJournal:

Wednesday, May 21st, 2008
2:14 pm
Have you received a siliconindia invite?

Of late, I have been receiving regular invites from a social networking site called www.siliconindia.com

All of the invites are from people I don't know. I have occasionally written back asking who they are and have never received a reply. I had never looked at this in detail as I always assumed that it was a minor typo which probably ended up getting to me. However after getting a recent invite for the umpteenth time, I got curious enough to check it out.

The first e-mail I received from siliconindia was back in 19th sept 2007 from a e-mail address called sinet@siliconindia.org. Searching for this e-mail brings up 2 pages of search links to archiving sites including the red hat archive list, mailing list of educational institutions and others to whom this invite has gone. Add to the fact that the names of people who purportedly use sinet@siliconindia.org range from "Rakesh Grandhi" to "Gitika" leads me to believe that this is nothing but a sneaky way to sign up subscribers.

Intrigued by this, I decided to sign up for the service and check out some of the people who invited me to join.

  1. Anjali Chawla
    Account Manager - O&M

    Minimum details on profile. But has around 660 people on her network. Couple of scraps posted, no one seems to have received a response.

  2. Disha Ghosh
    HR at IBM

    Minimum details on profile. But has around 700 people on her network. Couple of scraps posted, no one seems to have received a response.

  3. Pooja Khanna
    Technical Writer

    Minimum details on profile. But has around 950 people on her network. Couple of scraps posted, no one seems to have received a response.

  4. Richa Bajaj
    Content Writer

    Minimum details on profile. But has around 600 people on her network. Couple of scraps posted, no one seems to have received a response.

  5. Riya Agarwal
    Recruitment Executive - Mafoi

    Minimum details on profile. But has around 936 people on her network. Couple of scraps posted, no one seems to have received a response.

  6. Nimisha Tandom
    Accent Trainer

    Minimum details on profile. But has around 630 people on her network. Couple of scraps posted, no one seems to have received a response.

On the average a person actively using a social networking site has around 40 to 100 friends on their network. These people all have 600 to 1000 people on their network list not to mention the fact that they don't reply to any of the scraps posted which leads me to believe that these are possibly nothing but dummy profiles used to lure unsuspecting internet users.

One interesting aspect is that most of the recent siliconindia invites contain a photograph, a name and a job position of the person sending the invite.

I honestly wonder who are these people whose photographs are used? Are they professional models or are they photographs of real existing users? Do they have permission to use them? Is this even allowed? Are these real names and job titles?

So many unanswered questions, so for now; the invite goes directly to the junk folder :-)

Current Mood: annoyed
Friday, January 25th, 2008
10:12 pm
Integrating Visual C++ 2008 Express Edition into the build process

Continuing on the process of discovery about the suitability of Visual C++ 2008 Express Edition for commercial use, I ran into the issue of integrating the Visual C++ 2008 Express Edition into the existing build process. The current build process for Xtend IVR used a collection of vbscripts that automated the entire build producing the final product installs. This had served us well for the past couple of years or so and I saw no reason to fix something that wasn't broken.

The first step of course was to get Visual C++ 2008 Express Edition to compile on the command line. Visual C++ 6.0 has a neat feature where you could invoke the development environment, passing the workspace and build configurations as parameters and get it to compile the project for you. Something like

    msdev [Workspace.dsw] /MAKE [BuildCongfiguration] /OUT [buildlog]

Looking around, I found that Microsoft had preserved similar functionality in the Visual Studio 2003 and 2005 although the actual options had changed. However the development environment (devenv.exe) which everyone was referring to for a command line build was nowhere to be found. Out of sheer desperation, I looked up the actual link which starts up the "Visual C++ 2008 Express Edition" and found that it points to vcexpress.exe. Running "vcexpress.exe /?" sure enough gave me a list of options which included the /build switch. Interestingly the help states:

    devenv solutionfile.sln /build [ solutionconfig ] [ /project projectnameorfile [ /projectconfig name ] ]

Apparently the fact that the Visual C++ Express Edition executable is called vcexpress.exe has not made it into the command line help. Ok... add the express edition ide directory "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE" to the path and let's see if it works...

    vcexpress diva40.sln /build Release

Yippie... success. But then there is something strange. The build seems to be happening in the background. I get the command prompt back immediately and I can see the object files being created in the release directory. This won't do for a automated build.

I spend the next half-an-hour researching this on the web. Most of the possible solutions point to devenv.com as an alternative for devenv.exe. However the express edition doesn't include this file. Nope.. no vcexpress.com either :-) I was about to give up when I thought of running vcexpress.exe from an actual script. Surprise... when run from a batch file or script, the build seems to complete correctly in the foreground! This is too good to be true.

A couple of minutes later, my new build script was ready to test.

It worked flawlessly.

Still missing however was the /OUT option of Visual C++ 6.0 which would generate the log useful for tracking down build errors. I didn't have to look far though. Lying in the release folder was the BuildLog.htm file which contained essentially the same information.

In conclusion, building a solution from the command line using the Visual C++ 2008 Express Edition while certainly possible does not seem to be very well documented. Also devenv.com which is deemed more suitable for use by a build tool is not available with the express edition. If you can live with these constraints, integrating Visual C++ 2008 Express Edition into the build process is actually quite easy.
Monday, January 21st, 2008
6:32 pm
How useful is Visual C++ 2008 Express Edition for commercial use?

The Visual Studio 2008 Express Editions FAQ clarifies on point 7 to the question "Can I use Express Editions for commercial use?" with the reply that "Yes, there are no licensing restrictions for applications built using Visual Studio Express Editions".

Intrigued by the fact that there are no licensing restrictions, I wanted to find out exactly how suitable the Visual C++ Express Edition would be for a real life commercial project. And I had just the thing to test it out. We were considering moving our 10 year old, 95 project, 1 million line Visual C++ 6.0 code-base to the latest version.

This project (Xtend IVR) had a mix of every programming technology imaginable; MFC, Active-X, COM, .Net, CLR Hosting, User mode drivers, Multimedia, Voice Cards, VB, Plugins and so on. I already knew that the Visual C++ 2008 Express Editions do not have either MFC or ATL. My plan therefore was to pick a couple of projects that do not have dependencies on MFC or ATL and get them to compile and build correctly under Visual C++ 2008 Express Edition.

The natural choice was therefore the voice cards driver section of Xtend IVR which generates the driver DLLs for Dialogic (Global Call & Diva Server SDK), Ai-Logix, NMS Communications, Donjin and Synway. As a test case, I decided to try converting the driver for Dialogic Diva Server voice cards to use Visual C++ 2008 Express Edition.

To my pleasant surprise Visual C++ 2008 Express Edition directly converts and opens a Visual C++ 6.0 workspace (.dsw) file with a single click. That's real nice of Microsoft. I was expecting to have to jump through hoops doing a vc 6.0 -> vs 2003 -> vs 2005 multi-step conversion before finally being able to open the workspace.

Now that I was in, I decided to do a test compile.

    1 error and 45 warnings.

That was not too bad. Most of the warning seems to be related to the deprecated functions. Ok, let's add the _CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_USE_32BIT_TIME_T defines to "Preprocessor Definitions" in the Project->Properties->Preprocessor Definitions. That should help to temporarily get rid of most of these warnings. Hit F7 and

     1 error(s), 0 warning(s)

Wow, I just got rid of all those warnings. That wasn't so hard. So what's the error..?

     fatal error RC1015: cannot open include file 'afxres.h'.

Hmm.., "afxres.h" is an MFC include. Let's replace that with #include < windows.h> and hit F7

     1 error(s), 0 warning(s)

So, what's the problem this time?

     error RC2104 : undefined keyword or key name: IDC_STATIC

Hmm..., IDC_STATIC is defined inside afxres.h, no wonder it can't be found. Add the following lines.

    #ifndef IDC_STATIC
    #define IDC_STATIC (-1)

and compile. Yippee... it builds.

    ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

and runs perfectly as well!

But then I run into a stumbling block. The Dialogic Diva Server driver includes one configuration dialog as a resource and the Visual C++ Express Edition does not have an Resource Editor for unmanaged code (It is only included in the Standard Edition or higher). Looking around, I locate ResEdit - which is a free resource editor for Win32 programs. Seems to be quite neatly done.

However attempting to load the .rc file gave a few errors. These went away once I added "C:\Program Files\Microsoft SDKs\windows\v6.0A\Include" to the Options-> Preferences->Include Paths setting of ResEdit. I made some changes to the dialog, saved and compiled from Visual C++.

     error RC2104 : undefined keyword or key name: TRACKBAR_CLASS

The solution was to add #include < CommCtrl.h> to the .rc file just below the #include < windows.h> and compile

    ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========


So, what were the lessons learned?

For a project not involving MFC or ATL, upgrading from Visual C++ 6.0 to Visual C++ 2008 Express Edition is easy. However the absence of the resource editor is something you have to live with. ResEdit takes away most of the pain, but if you are developing commercially using Visual C++, you are better off with either the Standard or higher editions.

In my opinion, Microsoft has found the sweet spot where the Visual C++ 2008 Express Edition has nearly all the features a hobbyist or beginner would ask for, while at the same time ensuring that commercial development happens on the Standard or higher editions.
Saturday, January 12th, 2008
8:57 pm
Stream audio to multiple telephones with a single command!

Xtend IVR completely utilizes the full-duplex capability of supported voice cards to stream both incoming and outgoing audio in a call. What is not obvious is that these audio streams are manipulated internally by Xtend IVR to provide numerous services that would otherwise be difficult or impossible to implement. This blog post attempts to explain how this capability makes it easy to stream audio to multiple telephones with a single command.

For example, consider the scenario where you want to stream the audio of a ongoing live event to users who dial into the IVR. A common enough situation you would imagine. Unfortunately most IVR toolkits are not flexible enough to incorporate this capability without horrendous workarounds.

Naturally there is a lot of work needed to implement such a capability which would include among other things, audio format conversion between voice card and the multimedia devices, mixing of the audio streams and maintaining a fifo queue of audio buffers on a per port basis.

However when utilizing Xtend IVR; all you need to do is to configure one multimedia device and other voice cards. All voice cards perform a SoftListen() to the multimedia device immediately after the answering the call. With this single command, the incoming audio stream from the multimedia device will be mixed into the outgoing audio stream of the voice card.

This means that if you connect say an FM radio to the mic input of the multimedia device, all callers would now hear the output of the radio on their phone... live! At a recent exhibition we pulled off a coup when we had the audio of four local TV news channels plugged into four separate multimedia mic inputs and callers could select between the live news channels they wanted to hear on their phone. Naturally it was a hit.

We didn't have the heart to tell them that all it took was one command - SoftListen().

Xtend IVR is an easy to use scalable IVR toolkit that works with voice cards from Dialogic, Eicon, Ai-Logix, NMS, Donjin, Synway and also supports TAPI, H323, SIP and Skype. The Developer Edition which includes an unrestricted single port runtime can be downloaded from http://www.xtendtech.com/ivr
Tuesday, November 6th, 2007
5:30 pm
You can't have your TTS and play it too...

Text-To-Speech (TTS) support is one of those innocuous additions that look pretty simple on the surface. Provide a line of text, convert to a wave block and push into your play queue, what could be simpler?

It is when you start to test the different TTS engines that you start running into issues. For instance, many TTS engine providers throttle the conversion speed to match a real time play back duration. What this means is that the line of text which should theoretically convert in say .1 seconds will now convert in the duration it takes to actually speak that line, which would be say 5 seconds.

Why do they do this? For licensing reasons of course! If you could convert as fast as the engine could technically go, then you could use the single license for converting text on multiple ports. However if the conversion speed is closer to real-time then you can use that single license for TTS playback on only one channel, which means extra $$ for the TTS Engine provider.

Naturally this throws your "convert and then play" logic for a six because you are converting the entire line into a wave block and that conversion now takes 5 seconds. Since you can queue the block only after the conversion, these 5 seconds translate to silence on the telephone line which is unacceptable. So, then you decide to stream the TTS data in real time. This works well until the point where you have a mix of TTS and Play commands. Since the output queue to which TTS and Play write to is the same, the play blocks tend to get interspersed with fragments of the TTS data. This again is completely unacceptable.

There is no easy solution to this problem.

Trying to solve the sequencing of TTS fragments and play blocks is a nightmare of misunderstood proportions. Even if you can sequence one TTS and play correctly, what about situations where multiple TTS and Play commands are intertwined? The practical way out is to "block any play until all TTS conversions are complete". This ensures that TTS only scripts work perfectly as will the Play only scripts. Scripts that combine TTS and Play will also work but will pause to complete TTS conversions before play blocks are queued.

Xtend IVR currently uses the "convert and then play" logic. Work is underway to support "block any play until TTS conversions are complete". Work is also on to externalize the TTS and ASR support into independent drivers so that native API engines and newer standards like MRCP 1.0 and 2.0 can be supported.

Xtend IVR is an easy to use scalable IVR toolkit that seamlessly works with voice cards from multiple vendors. The Developer Edition, which includes an unrestricted single port runtime; can be downloaded from http://www.xtendtech.com/ivr
Monday, September 24th, 2007
6:22 pm
Integrating with the .NET Framework

One of the advantages of Xtend IVR is the fact that it is easily able to integrate with the .NET Framework. In fact the developer edition contains samples in C# that demonstrate how easy it is to achieve this.

The standard Bank Balance example is of course implemented in C# as is the DotnetDailyFact webservice example that demonstrates how you could use C# to call a webservice and pass the return value back to the Xtend IVR script.

.NET integration is implemented in Xtend IVR by hosting the CLR. In fact I drew on my experiences learned while implementing the integration to author a webcast on how to host the clr from unmanaged code.

This webcast can be viewed here -> Hosting the CLR in your unmanaged application

Current Mood: accomplished
Thursday, August 16th, 2007
6:33 pm
Xtend IVR now supports Synway, Donjin and NMS

The latest release of Xtend IVR now supports the following voice cards and api.

  • Dialogic HMP (SDK 6.0)
  • Synway (SynCTI 4.7)
  • Donjin (NADK 1.8)
  • NMS (Natural Access 2005-1)

  • Dialogic (SDK 5.1.1)
  • Dialogic (SDK 6.0)
  • Diva Server (SDK 4.0)
  • Ai-Logix (SDK 3.8)
  • Telephony API 2.1 [Half-Duplex]
  • Telephony API 2.1
  • Multimedia Wave Driver
  • Xtend Service Driver

  • Opal H323 Driver (BETA)
  • Opal SIP Driver (BETA)
  • Skype Phone (BETA)

You can download the Developer Edition which includes a single port runtime supporting all the voice cards mentioned above from http://www.xtendtech.com/ivr

Current Mood: accomplished
Sunday, July 1st, 2007
9:48 pm
NMS Communications - No UI, Lots of Docs

NMS Natural Access is an OS independent api and framework for implementing voice applications. However this feature comes at a price - no UI. That's right.... absolutely no user interface.

So how do you configure the card? Well you fiddle around with the configuration files in a text editor. If the thought of configuring couple of lines containing obscure telecommunication references does not deter you, the fact that you have absolutely no clue on how to test the card will slowly sink in.

It is at this point that you realize that you better RTFM. Okay, you browse over to http://www.nmscommunications.com/manuals and your eyes glaze over at the sight of 291 manuals. That's right Two Hundred and Ninety One!

To NMS credit, the manuals are quite comprehensive. But they all seem to be htm files. Possibly OS independence at work. But that leaves us right where we are.

Okay, let's read some of the samples hoping to understand how the whole natural access funda works and what are the manuals we need to read. Again the samples are quite comprehensive; however most of the samples are written without using a callback function or a thread to handle events. Also in an attempt to reduce the lines of code, many standard functions are abstracted out to a demo library which every sample uses. As a direct result - the samples are not very intuitive, do not directly provide the api function usage and are at least couple of hundred lines larger than what they need to be.

Once you sort of get the hang of this and find the four manuals you actually need out of the two hundred and ninety one hard core documentation on the website; You will cruise along coding happily until you hit the MVIP puzzle. Magic number 16, 18, 4 and a couple of other appear in the source code along with a switch statement that doesn't seem to make any sense. Reading up on the MVIP documentation just confuses you more. In fact the standard developer manual seems to shrewdly skip most of this information as non-essential. My advice would be to keep reading until you figure it out. Perhaps it's the explanation or may the lack of it, but I certainly had a hard time understanding how it works.

The sore points I have with NMS is the over reliance on htm files for documentation, the fact that you need to refer four different groups of htm files to get something working, the lack of any UI for configuration purposes and the non-intuitive samples included.

On the bright side, the documentation is comprehensive (from a technical viewpoint), the api starts to make sense once you code on it for some time and the system more or less works the way you expect it to.

The NMS driver is being tested and will make it into the July release of the Xtend IVR toolkit.

Current Mood: content
Thursday, June 21st, 2007
9:02 pm
So, what can you do with the Skype IVR?

I had written earlier about why IVR software do not support Skype. Now that we have a working Skype driver in Xtend IVR and a free one port Developer Edition available for download, let us take a look at what is possible using Skype and the toolkit.

For starters, all generic ivr samples that are present in the samples directory work with the Skype driver without any modifications. All you have to do is to select the Skype driver from the Xtend IVR Configuration, select the appropriate script and you are up and running. This means that the tele-banking example, multi-lingual samples, dialout, language integration, speech recognition and text-to-speech examples will work out of the box with Skype.

However, what is not apparent on first glance is that Xtend IVR has the capability to support multiple Skype instances on the same machine. As you would be aware, each Skype instance needs to be run under a different windows user account. Ensure that all your windows accounts under which you will be running Skype utilize the same password (For the currently active user, a password is not required).

Once all the skype instances are up and running, simply run Xtend IVR Configuration and configure the password field of the Skype Driver to the Windows account password. The Skype driver will automatically scan through all Windows accounts and will display a list of supported Skype instances. Since the Developer Edition only supports a one port runtime, you will be able to select any one of the listed Skype instances.

Another capability which is not obvious is the ability of Xtend IVR to stream audio from Skype to any other supported device. This means that you can softstream audio from Skype to Skype, Skype to Diva Server, Skype to SIP, Skype to H323, Skype to Ai-Logix, Skype to Multimedia Device and vice versa. Since this requires at least a two port runtime, you unfortunately cannot try this with the developer edition.

One interesting example of what SoftStream() is capable of can be demonstrated by configuring Xtend IVR to support one port of Opal H323 and one port of Skype. Then create a simple script so that an incoming call in the H323 port will trigger an outgoing call to echo123 and softstream() the audio together. Now make an incoming call from a soft-phone to the H323 port of Xtend IVR, you will now be able to hear echo123 from your H323 soft-phone. This example is in fact not restricted to H323, any supported full-duplex channel in Xtend IVR would be able to implement this Skype gateway. Hmm... maybe I should put up a video of this in action.

Also present are the Skype specific samples incorporated in the Samples\Skype directory. Most of these use the Skype specific plugin library which wraps the raw Skype.Command() and Skype.Response() functions. For example there are functions that allow you to chat with a user, send an SMS etc. For example the WorldTime Skype sample accepts incoming chat requests from users, looks up the country they have specified in the chat message on the worldtime server, uses the http plugin, screen scrapes the resulting html and returns the current time in that country to the user.

In short it is possible to script the Skype api using Xtend IVR to write bots that answer queries and perform interesting functionality. Since the Xtend IVR scripting language can integrate with practically any language C#, VB, C++, Clipper! etc. it is possible to incorporate advanced functionality with minimal effort.

Now for the Caveat: The Skype driver is at present a proof-of-concept beta. We have decided to leave it that way since during testing Skype displays a tendency to useup/leak memory consistently. Since Skype reacts this way even on a standard install, there is nothing much we can do except take a deep breath and wait for a more stable release of Skype.

Current Mood: content
Sunday, June 17th, 2007
8:54 pm
Donjin - The Dark Horse of the Voice Card Industry

Of all the voice card vendors in the market, Donjin is unique. Not just because they seem to cover the entire analog and digital range of voice cards, but because they claim to be compatible with the Dialogic API!

Now those of you who have used the Dialogic API will find that claim hard to believe because the Dialogic API is more of a mish-mash of api duct tape concocted to cover various eventualities that had to be dealt with along the way. It's hard to get working, but once you do, it tends work like a charm. Until you have to support a different model... that is.

Therefore most people dismiss Donjin claims as just vendor hype. Well, last week we got our hands on the Donjin Digital and Analog card to include support for them in our toolkit. Well what do you know; Donjin supported most of our implementation out of the box. All we had to do was to make minor modification to a 3 functions (basically related to ANI) and a callback message which was giving us a wrong crn and we were up and running.

So what's the catch. Well for starters, Donjin does not provide any header files for their api. The unofficial or official (I wasn't able to figure out which) response was that since the api is compatible, just use the Dialogic 5.1 headers.

What... To me, that looks like a easy way to find yourself in a lawsuit!

Donjin seems to have taken the easy (or smart) way out by passing the potential lawsuit threat onto their customers. Having been sued for this themselves, I guess this was the smartest way out. No way Dialogic is going to sue all their existing customers and piss them off.

Well I don't feel comfortable using one vendors header files to compile another vendors api. No matter what the license says, I just wasn't going to do it. So we basically re-wrote the function prototypes and defines based on the Donjin documentation. That was easy too... just a day or two of effort to put my conscience at ease.

The good part is that its working and the driver passed our standard tests quite well. The Donjin driver is expected to make it into the July 2007 release of Xtend IVR.

Current Mood: accomplished
Thursday, June 14th, 2007
9:00 pm
Scalable IVR Solutions - The Easy Way

Many of the existing IVR toolkits were created at a time when powerful cpus were non-existent and multi-processing was the play-thing of super computing scientists. Due to the scarcity of computing resources, most toolkits implemented sophisticated multi-tasking runtimes to work around the OS limitations.

Today in a world of multi-processing, multi-threading OSes and when the average computer boasts a multi-core cpu; most of these toolkits are still stuck with their historical baggage that prevent them from providing full support for the facilities provided by the latest operating systems.

When we designed Xtend IVR, one of the decisions we made was to make full use of the OS capabilities in what we did. It was obvious to us that CPU and OS capabilities were only bound to increase. Firm with this belief was also the vision that IVR solutions created using Xtend IVR should be scalable without any extra coding effort on the part of the user. We designed the language and the plugin integration in such a way that an IVR created for a 1-port ivr solution would scale all the way to 512 ports without any change in code.

In fact the only change the user needs to make to run his system on more ports is to configure more ports in the Xtend IVR configuration. It's that simple.

We also threw in the ability for code to communicate across ports without having to deal with the nuances of locking, implemented a message queue for each port, provided for variable access across ports and implemented the ability to stream voices between devices.

The end result is an IVR Toolkit that makes implementing scalable solutions a cake walk.

If you are in the field of implementing IVR Solutions, you cannot afford not to take a look at our toolkit. Its power and simplicity is guaranteed to blow you away.

Current Mood: accomplished
Friday, June 8th, 2007
1:55 pm
Write Once, Use Any Hardware - The Holy Grail of IVR Software

Most IVR Software as written, work only with specific voice cards in the market and in most cases this is limited to the voice cards of a single vendor. The main reason for this is the voice card API that each Manufacturer bundles along with its voice cards. IVR Software written to work for one API become in a sense locked into that API. The overall effort to implement support for a second API is so great and the cost-benefit ratio so small that software developers do not consider implementing support for a new vendor.

While this might have been true for the past decade or so when the competition between voice card vendors were limited, the arrival of high speed multi-core CPU's bringing with it the ability to implement Host Media Processing thereby reducing the DSP requirements at the board level and the emergence of the Chinese voice card vendors into the global market has resulted in fierce competition between the vendors and a resulting drop in voice card prices.

Unfortunately many IVR solution providers have been unable to take advantage of this situation due to the lock-in imposed of the proprietary API. As a direct result many software developers have been looking at toolkits that support multiple voice devices. Unfortunately many toolkits are still voice card specific or only support one of the standard API like CAPI or TAPI.

The USP of Xtend IVR toolkit is its capability to support multiple voice devices out of the box. Each voice card has its own device driver which implements the Xtend IVR VDIL (Voice Device Independent Layer) enabling us to support any voice device in existence. (We even have a proof-of-concept driver for Skype that supports multiple Skype channels and works with all our standard IVR scripts)

API's and Voice Devices currently supported:

  • Dialogic (SDK 5.1.1)
    All Dialogic Voice Cards supporting Global Call API 5.1.1 is supported. Extensive testing of Xtend IVR is performed using D/4 PCI UF (for Analog) and D/300 E1 JCT (for Digital) voice cards.

  • Dialogic (SDK 6.0)
    All Dialogic Voice Cards supporting Global Call API 6.0 is supported. Extensive testing of Xtend IVR is performed using D/4 PCI UF (for Analog) and D/300 E1 JCT (for Digital) voice cards.

  • Diva Server (SDK 4.0)
    All Dialogic Diva Server Voice Cards and Soft Device (H323 & SIP) are supported. Extensive testing of Xtend IVR has been performed using Diva Server V-Analog-4P (For Analog) and Diva Server PRI/E1/T1-8 / Diva Server V-PRI/E1 (For Digital).

  • Ai-Logix (SDK 3.8)
    All E1/T1/Analog Ai-Logix Voice Cards are supported. Extensive testing of Xtend IVR has been performed using Ai-Logix LD409 (For Analog) and Ai-Logix DT3209 (For Digital).

  • Opal H323 Driver (BETA)
    Opal H323 driver supports the H.323 protocol for VoIP. The driver implementation utilizes the Opal Libraries available from http://www.voxgratia.org/

  • Opal SIP Driver (BETA)
    Opal H323 driver supports the SIP protocol for VoIP. The driver implementation utilizes the Opal Libraries available from http://www.voxgratia.org/

  • Skype Phone (BETA)
    Skype is supported via the Skype API. Extensive testing has been performed only for up to four simultaneous ports.

  • Telephony API 2.1 [Half-Duplex]
    TAPI 2.1 is supported in half-duplex mode. Extensive testing has been performed using the Dialogic D/4 PCI / Tata PCT An (For Analog) and Dialogic Diva Server PRI/E1/T1-8 (For Digital) voice devices.

  • Telephony API 2.1
    TAPI 2.1 is supported in this full-duplex tapi driver. Extensive testing has been performed using the Dialogic Diva Server PRI/E1/T1-8 (For Digital) voice devices.

  • Multimedia Wave Driver
    Multimedia devices are supported via this driver. This enables one to stream voice to the Multimedia Speakers or stream in voice from the Line-In/Mic. Live audio services can be supported via this driver.

  • Xtend Service Driver
    The service driver is a null device used to create worker threads that can be utilized to perform any background task like reading from the com port or to schedule services for later date.

  • Generic GSM Modem
    The Generic GSM Modem is a driver than supports the sending and receiving of SMS Messages using standard GSM Modems. Full support for Unicode, Long, Blink and Flash Sms are present. The Generic GSM Modem driver is available along with the Xtend SMS toolkit as a separate purchase and can be integrated into an IVR solution if required.

API's and Voice Devices whose support is planned or in progress include:

  • Dialogic (HMP SIP & H.323)

  • Synway (SynCTI 4.7)

  • Donjin (NADK 1.8)

  • NMS (Natural Access 2005-1)

  • Googletalk

The Developer Edition of Xtend IVR comes with a 1-port runtime that enables you to test the developed script on any of the currently supported voice devices and can be download from www.xtendtech.com/ivr.

Current Mood: content
Wednesday, June 6th, 2007
9:18 pm
Getting Started with Xtend IVR

We have just released version 3.0 of our IVR Toolkit. This release incorporates many new features, most of which I plan to cover in the days ahead. For today however, I leave you with a video that gives you a general picture of how to get started with Xtend IVR.

Current Mood: accomplished
Tuesday, June 5th, 2007
6:54 pm
Six reasons why IVR software do not support Skype

Around six months ago, we took a serious look at supporting Skype in our IVR toolkit. Confident of our Xtend IVR 3.0 design which provides a driver approach capable of supporting any voice card, we ventured forth to see how complicated actual Skype integration would be. After all, our toolkit supported SIP, H323, Multimedia devices, Eicon Diva Server, Dialogic Global Call, Ai-Logix and TAPI. So what else could be more complicated than all these? Boy, were we wrong... :-)

Skype had many gotchas to overcome. Not the least being the absence of a documented Audio API and that is just for starters. Read on...

1. Streaming Audio:
No problem, you know how to write a windows virtual audio device, don't you?

The Skype api does not provide any support for obtaining streaming audio data from Skype. So the method of using a windows virtual audio device is the only known method of obtaining audio necessary for implementing an IVR. This left us with the task of either licensing virtual audio cables or implementing a windows virtual audio driver from scratch.

2. Multiple Skypes Channels: Well you need to create as many user accounts.

An IVR has to support multiple channels. However the only known method to get multiple Skype channels up and running on a single system is to use the runas facility to run Skype as a different windows user. Windows uses the terminal services facility as a way to logon multiple users simultaneously. However this incurs extra cpu load and memory. Say for running eight channels of skype, you require eight different user accounts under windows which leads us to the next problem.

3. The API is easy:
Unless you have multiple skypes running, then it's an IPC nightmare!
The Skype API under windows uses WM_COPYDATA which is restricted to within the user account boundary. Therefore a single program cannot control multiple skype instances. The only way to get around this limitation is to have a helper program running in the same user account as skype, access the api and then pipe the data back to the controlling application via inter-process communication techniques. Think you want to debug this... good luck ;-).

4. And the sampling rate is:
How about 48 Khz?

Left to itself, Skype selects 48 Khz as the audio sampling rate. Surprised? I was too. A standard IVR functions somewhere in the 8 Khz to 11 Khz range for audio. Any attempt to massage a standard IVR to function with Skype requires one to convert between these sampling rates. To get the best audio quality you will need to interpolate the 8 Khz data to the 48 Khz range. 

5. Working on your computer:
Sorry, I am going to show popups all over the desktop.

Skype does not provide a silent mode of operation. The gui keeps popping up informational message and queries throughout a automated skype session. And since you are dealing with multiple skype instances, any hope of simultaneously using your computer for other purposes is a foregone conclusion. (Update: As of Oct 2006 Skype now provides a command for turning itself silent, but this command still has issues that needs to be threshed out).

6. Need Chat & SMS support:
Oops... how do I implement that in my IVR?

Skype allows extra functionality like chat messages and sms which have to be supported. Surprisingly enough, the practical approach seems to be to provide a way to access the raw skype command and response strings from the scripting language. The interface is then further simplified by providing appropriate functions in the script that encapsulate the required functionality. This approach also has the advantage of future proofing the design to support newer skype features.

The proof-of-concept Skype driver has made it into the March release of the Xtend IVR 3.0 developer edition and can be downloaded from http://www.xtendtech.com/ivr

Current Mood: accomplished
Friday, October 10th, 2003
11:57 am
To be or not to be - XML buzz word compliant

I have always felt that only simple, focused and easy to understand concepts catch on quickly. Take XML for example. The benefits of using XML as a data description standard for data exchange between applications is now well understood. Unfortunately its popularity has also resulted in XML being incorporated into completely un-needed areas.

For a good example, look no further than VXML. I can almost hear it being created. Hey XML is the in thing, so why don't use it as a programming language for IVRS applications... You know inter-operability and all that. Use XML as a programming language... GOD what will people think of next.

Personally I would like to bash the creator of VXML on the head with nothing less than a Dialogic E1 card. Ok... with the whole damn system, If I could just lift it.

The many advantages of XML are simply not there when used as a wrapper for a programming language. Due to my experience in building a popular IVR toolkit (http://www.xtendtech.com/), I was completely un-impressed by the command syntax a VXML programmer has to learn. Listen guys... it is just not obvious, nor is it simple, nor does it have any advantages of XML. So why push it down customers throats?

It was at this point that I came across a well written article titled Software Fashions that syncs with just what I feel (at least on the XML topic). However with most IVRS companies scrambling to support VXML, I guess I would have no choice but to provide support for this in the future. But I can never agree with using XML as a programming language. Let's all use XML for what it does best; describe data in a clean and open manner.

Current Mood: annoyed
About LiveJournal.com