QueTwo's Blog

thouoghts on telecommunications, programming, education and technology

Tag Archives: Avaya

IAUG 2015 Review

IAUG-KeynoteIt’s been a month since I traveled to Denver to attend the IAUG (International Avaya Users Group) “Converge” conference in Denver, Colorado. This conference was one I used to go to every other year at most, but recently I’ve been attending every year… I think I’m on a three year streak.  Plus, this year the conference was in Denver, hands down one of my favorite places to visit in the US.

This year I was asked to speak on two separate topics which changed the experience of the conference for me.  It’s been nearly 10 years since I’ve spoken at an IAUG conference and this time I was speaking on two very diverse topics.  I’ll be posting more details on what I spoke on in subsequent blog posts, but I did a joint presentation on the EDP (Avaya Engagement Development Platform) and the OSSI Administration protocol.  Additionally I participated in the EDP meetup and presented some of MSU’s Telecom innovations during the Tuesday keynote.

This year the conference was in the Denver Convention Hall.  The conference center is /huge/ and our conference managed to only fill 1/4 of it with our thousands of attendees.  One of the things I like about the convention center is that there are lots of couches and places to get some quick work done between sessions or meet up with others without being in the way.  Generally the A/V was pretty good which for the last few conferences I attended was a sticking point.

I wish I could have attended more sessions, but given my schedule I was pretty booked up.  There was lots of buzz of a few topics (like the roadmaps) that sounded great.  The few sessions I did get to attend were great — I think I only ended up leaving one without getting something out of it.  The tradeshow floor was, as always, great.  When you are at your home office you often forget about how large the ecosystem is around the simple telephone on your desk.

In the years I’ve been working with Avaya, it seems like they are finally starting to be able to realize their ‘dreams’ of how all the building blocks come together.  This year there was much more cohesiveness between their products and seemingly less things being developed in silos.  There was also much less “us vs. them” between the “red” Avaya customers and “blue” Nortel customers than last year.  With Avaya a year into moving into a suite licensing where they can freely innovate products and worry less about separate licensing mechanisms for each one there is more and better innovation and alignment in them all.

It was neat watching the company promote the EDP (Avaya Engagement Platform, formerly Collaboration Environment) as heavily as they have.  This is a development platform, similar in effect to Twilio, that really cracks open the internals of the enterprise phone system and allows companies that want to innovate with their communications infrastructure to do so.   At Michigan State University we’ve been able to take advantage of the platform and push the boundaries of our capabilities to create some cool apps that are producing some real ROI.  With Avaya pushing the platform company wide, I only see the toolbox getting bigger and more useful as more adjuncts plug into the platform and allow us to do even cooler things.

I’ll be back again next year — and hopefully will be selected to speak on some more cool topics and projects we are doing.


Making ColdFusion Sing

One of the coolest things about CFML is the fact that it was designed for rapid application development.  Even more so, as the language (and server platform) evolved, it quickly turned into one of those tools that knew how to talk to just about everything.  From FTP, to the Web, to SSH connection, to specialized JDNI connections, it is pretty darn simple to make ColdFusion the glue that holds disparate systems together.

Last month I was tasked with coming up with a tool to allow some of my PBX users to record announcements.  The current system they were used to involved them calling a phone number, entering in a special code and then recording their announcements.  It was easy because the phone already had a mic, speakers and everything else setup to the point where the user didn’t have to worry about all the related computer settings.  I tried to re-create a solution that was just as easy using the Flash Player (and ever a Java applet) — but it turns out that very few people have microphones hooked up to their computers — and those who do have no idea how to tune it so that the sound levels are descent.

I came up with a nifty idea.  I wrote a really quick CFML app to interact with Twilio (an online phone company that provides a really wicked API for dealing with live telephone calls).  Essentially, they post back form requests to you, and you pass back XML documents back to them.  They even have an API that can do recordings.

The only problem was the recordings they saved weren’t in a format that my PBX understood.  While they provided me mono, 16-bit PCM, 16k wave files, I needed 64-bit, 8k mono uLaw wave files.  To a normal computer, these look the same, but to these two different systems, they were radically different.

The solution?  I found a really cool Java application known as JAVE.  JAVE is a wrapper for ffmpeg, which is a very well known application that can work with audio and video files.  JAVE allows me to convert from one type of wave file to another, or even from an mp3 to a wave, or from a Windows Media file to an MP4 file.

Using it?  Like dealing with most Java classes, you drop it into your CFML’s LIB directory.  I tried it both with Adobe ColdFusion and Railo and it worked flawlessly.  Once you have the Java class (jave-1.0.2.jar) in the lib directory and re-start your CFML server, you are ready to start writing some code.  Here is what I came up with to convert between my two wave formats :

 jave = createObject("java","it.sauronsoftware.jave.Encoder");
 incomingFile = createObject("java","java.io.File").init("C:\temp\incoming.wav");
 outgoingFile = createObject("java","java.io.File").init("C:\temp\outgoing.wav");

 audio = createObject("java","it.sauronsoftware.jave.AudioAttributes");

 attrib = createObject("java","it.sauronsoftware.jave.EncodingAttributes");

 jave.encode(incomingFile, outgoingFile, attrib);


That’s pretty much it.  If you do a cfdump of the “jave.getAudioDecoders()”, “jave.getSupportedDecodingFormats()” you will get a good feeling of all the different file types you can convert between.

This is more of the type of magic we need to be talking about.  Sure, converting between file formats can seem dull, but being able to come up with a solution to do it quickly is what makes a language, and a platform useful.

The truth about avoiding the phone company with VoIP

VoIP, or Voice Over IP is seen as the future of telecommunications.  In the enterprise, it took hold about 5 years ago, and about 3 years ago it became the norm for any new phone system. In the highly controlled network environment of the office, the technology flourished and eventually became rock-solid by breakthroughs made by companies like Avaya, 3com and Cisco.

Around the same time consumer-based VoIP products like Vonage started hitting the market.  These use the consumer’s internet connection and provided a dialtone like replacement for a standard phone line.  Generally these types of connections were less expensive (and in some cases, they were MUCH less expensive), but at the same time they relied on the general internet (without any quality-of-service gaurentees).  Recently there has been a lot of fanfare over Google Voice being available on various mobile devices like Google’s Android and Apple’s iPhone.  This allows users to use their data plans and bypass the cell-phone companies. The funny thing is, even AT&T sees consumers bypassing their services as a viable threat — they filed paperwork to lift the requirements that they provide phone services in their entire claimed market.

There are a few problems with this mass migration from traditional telephony services to this “wild-wild-west” VoIP services.

First off, VoIP has no concept of location-based services.  With traditional PSTN “landline” or business services, the phone company delivers your services to a physical location (your home or business).  This information is tied to a database which is given to 911 and other emergency services when you need it. Because VoIP connects over the internet, there is no real way to track where a call is physically being placed from — and the problem is exaserbated by devices like firewalls, VPN tunnels and MPLS networks.

Next, there is no concept of Quality of Service for many of these consumer devices.  Companies like AT&T in my local market offer DSL service in most areas that has a 1MB download and 256kbps upload.  This allows for a descent speed for doing things like browsing the web or reading emails.  However, if you try to use a VoIP connection you most likely will saturate this connection — and if you try to browse the internet while being on the phone (something I do quite a bit), you run a huge risk of your connection breaking up or being disconnected completely. More advanced routers and internet service providers offer QoS for connections, but these are not universal, nor are they easy to setup.  I won’t go into the reliability of internet connections in storms, power outages, etc. where quality and resiliency is a needed in emergencies.

Compatibility is another issue that is becomming apparent. There are hundreds of different “VoIP” providers out there, each with their own software or hardware application.  Companies are all trying to write their own standard (like Skype), or if they use some of the open standards (like Google), they implement them in a way that makes it very difficult to interconnect with others.  This is very similar to the beginning of the telephone network where there were lots of different networks, and none of them connected with eachother.  The government finally stepped in and created some laws (known as Common Carriage Laws) that required anybody who wanted to be a telephone provider to interconnect with each other.  Currently many VoIP providers do connect via the PSTN, but often times they charge users additional fees to do this.

Finally, we need to take a step back at the PSTN system itself.  It has become a commodity item, and even further more, it has become a so universal it is considered a utility.  In many markets it is heavily regulated by the government and has lots of redudancy, backups and, well it’s a proven technology. As more users disconnect their traditional phone lines and go with VoIP providers, less work is being put into this system and eventually that glue that holds it, along with all the PSTN providers will begin to go away.  Not only that, but because it has become such a commidity, you can get land-lines for cheap, and unlimited minutes (both in cell and landline), it makes very little sence to use these technologies other than it’s the “next best thing”.  If you don’t believe me, take a look at your VoIP provider, and compare that to a $14 phone line (unlimited local calls, and up to $0.05 a minute for long distance).

Think twice about cheering on AT&T in cutting the cord with land-line service.  It’s something that is easy and well understood.  Also think about how you plan to get internet access — and how those who are in unprofitable areas can get basic services (like phone and internet services) if companies like AT&T and Verizon are not forced to provide them.