The Do’s and Dont’s of IVR Apps

August 4, 2008 by Tom Costelloe

It is often not until something is pointed out to me that I notice it in abundance. Take, for example, a particular “tag” or signature used by graffiti artists. My wife pointed out the side of a mailbox as we were going for a walk the other night. She commented on how she’d noticed it around the neighborhood. Personally I had seen that many signs, mailboxes, and buildings had been tagged. However, I hadn’t noticed any particular tag over the other. Now I noticed this tag, pointed out to me by my wife, virtually everywhere even if I am not looking for it.

Every day I deal with IVR applications, menus and voice prompts; whether for work trying to contact a customer, or in my own life trying to order food. It wasn’t until a conversation I had early last week when uncovering some of the mistakes people make, that I really started paying attention to what I was and was not hearing. There are many simple mistakes which people regularly make when trying to record their own prompts. A couple examples of what I came across include:

  • Quality: In many cases this is a client’s first impression of your company and its products and services. What are they hearing? What is their reaction? Take a minute to call into your own business and ask yourself, “Is what I want my customers to hear?”
  • Consistency: Is the same voice throughout the prompt? Is a similar tone of voice maintained? Does the voice quality switch between supplied prompts and recorded prompts? For example, you may have recorded an upbeat greeting–do you have or should you have the same tone for every prompt?
  • Order: Decide the order of information provided; will the name be given first, or the phone extension? I suggest that you let people know who it is before you say how to get to them. Something like: “For our customer service department, please press 1”.
  • Length: Don’t try to get out as much information as you can in the first 15 seconds. Only provide what you need to; there is a good chance that the important information might not be retained if the message contains too much information.
  • On Hold: If a client is willing to wait to talk to a live person, it is a good idea to inform them of some of the services your organization offers or recent achievements while they listen to music. If a client must be placed on hold, it is better to have them listen to something rather that nothing at all.

This may seem straight forward and simple, but if you pay careful attention, the next time you make a phone call and are placed on hold, you may be surprised by what you hear. All is not lost; there are plenty of options out there.

In regards to your business phone system one option is to take the time to individually record and replace every prompt with custom prompts. While it may be a bit time consuming, the end-product will be worthwhile. The other option is to purchase pre-recorded prompts combined with a smaller number of custom prompts. There are packages offering replacements for all standard prompts used within many different phone systems. Additionally custom prompts may be created for your greeting, menus and messages on hold. Custom prompts are recorded by the same person to complete the package. You’ve taken the time to design and layout out an IVR that covers every possible option a customer could want. Comparing the voice prompts within your phone system to a “tag” as I mentioned previously: Why go out with a can of spray paint for a few key words when you can have someone paint you a mural?

More on MagicJack

August 2, 2008 by Garrett Smith

Rich Tehrani, Editor in Chief at TMC and prolific VoIP industry writer, penned a recent post with some thoughts on MagicJack, current industry media darling and scourge of ITSPs everywhere.

Tehrani gives MagicJack high marks for their marketing campaign and product branding. I agree, they have done a good job of getting the word out about their service.

Rich also gives MagicJack props for letting their freak flag fly, daring to include mention of the technology gears behind their service and not hiding in the closet from an often VoIPoPhobic consumer audience. Heck they even modded the USB stick ATA so you can see the board, chips and circuits inside.

So I’m reading Rich’s post and nodding in agreement right up until the end, when he remarks:

I suspect we will see more companies doing similar things and packaging their products in a like fashion and switching to pricing plans that are very close to this offer.

I disagree here. One fact missing from the analysis of MagicJack is that their business model is built off the idea of subsidizing their service delivery costs by borrowing a monetization strategy that is the foundation of most web services…..ADVERTISING!

Rob Beschizza at BoingBoing Gadgets peeks behind the curtain and sees that the devil is in the details, and that privacy advocates are not likely to be signing up for MagicJack anytime soon.

From MagicJack’s EULA (End User Licensing Agreement):

“You also understand and agree that use of the magicJack device and Software will include advertisements and that these advertisements are necessary for the magicJack device to work … Our computers may analyze the phone numbers you call in order to improve the relevance of the ads”

Any claims, legal proceeding or litigation arising in connection with the magicJack device or Software will be resolved by binding arbitration … in Palm Beach, Florida.

Hmmmm…..”Our computers may analyze the phone numbers you call in order to improve the relevance of the ads”….

Does that allude to geo-targeting of local advertisements based upon area codes dialed? Or something more sinister like packet sniffing and keyword targeting based on actual conversation snippets from private phone calls?

I don’t buy the notion of consumers buying into ad supported phone service at a massive level, creating a trend that would shape the overall industry. That’s just my opinion, and I may be called out for it in the future and I’m willing to take the heat for it.

I wrote about using MagicJack to emulate POTS service with an IP PBX last year. At least one of our readers was working on gaining access to MagicJack’s SIP proxy in order to bypass the need for their USB dongle.

FreeSwitch and SipXecs and Second Generation IP PBX

July 31, 2008 by Garrett Smith

There’s a new generation and it won’t be denied. I have previously blogged on the exciting new FreeSwitch 1.0 release. I predicted it wouldn’t be long before others in the industry started seeing its worth and started making applications for it. Well, one major trend seems to be that the folks over at SipX Foundry, who make the very nice SipXecs, are a bit smitten with FreeSwitch, and what it can do for them. They’ve just created a conference server solution and next in line are an IVR and hints about a voicemail system based on FreeSwitch. They now have that feature/application server that they needed to complete their system. I expect to see the SipXecs project to use FreeSwitch more often.

Asterisk is starting to look like a first generation IP PBX. It is apparent now that its dominance in the FOSS VoIP market may be seeing its first real challenges by real players. Asterisk is going to have to start from scratch. They wouldn’t listen to their community, and may now pay the price for that hubris. Can they fix an inherently flawed design? Time will tell.

When I started with Asterisk, the learning curve was awfully steep. I didn’t know that much about telephony, and when I started with FreeSwitch I had to learn an entire new syntax and way of doing things (see -> steep learning curve). A lot of the people that are hanging on to Asterisk are doing so because they really don’t want to have to relearn something all over again. They are comfortable. Others have gained status in a community and don’t relish the idea of having to start at the bottom of the food chain again as noobs. They are comfortable. Asterisk gave me my start with VoIP, and I will always have place for it in my heart. But, I also realize that times and technology change, and so must I. Asterisk isn’t going anywhere anytime soon, but the writing is on the wall, and it reads “Niche Player.”

We here at VoIP Supply will have to react as the market changes or face the very real possibility that our competitors will do so first, and become the market leaders in doing so. To date, VoIP penetration has been limited by scalability. With new systems offering greater capacity the opportunity for growth is certainly there. The enterprise market that was previously cautious regarding VoIP may be a bit more open now. My point is not knocking Asterisk, simply categorizing it for what it is, a decent solution for the SMB/SOHO market. But, as my boss put it: “given the choice between a Mercedes and a Ford for the same price, I’ll take the Mercedes.” Others may feel the same.

UPDATE: The FreeSwitch group is getting ready to release version 1.0.1 soon that will improve the code’s stability and add Automatic Speech Recognition (ASR) and Text To Speech (TTS) to the code.

A little background on what others think of SipXecs is also in order. From the hyper-connected enterprise blog on TMCNet: “Asterisk may be older but sipXecs is better” (a Nortel Guy).

What’s Up with Shared Line Appearance and Polycom Phones?

July 30, 2008 by Garrett Smith

Recently, VoIP Supply had a technical support case dealing with SLA or Shared Line Appearance functionality. More specifically, the case dealt with a Polycom Soundpoint IP Phone. When I first opened the case, I was aware that the “shared” line option was available on the Polycom phones. This option is “plain as day” on the Web GUI Line tabs. Simply select the “shared” radio button on the two Polycom phones you would like to share and voila, right?…wrong!!!! SLA is considered a “server side” or IP PBX function, the phones can support only what is being pushed to them.

Hmm, ok, let’s try SLA on a couple of platforms with a variety of phones. I’ll try trixbox CE, Switchvox SMB, and Elastix running Free PBX for platforms and Polycom, Grandstream, and Linksys phones for endpoints. Here are my findings per platform and endpoint, wait actually we can simplify this to one statement: Polycom SLA didn’t work on any of these platforms while Grandstream and Linksys worked flawlessly. Polycom phones would register and display the “shared” icon look on the phone display, but all I got was busy signal when attempting to make a call.

Here is what I don’t understand, what’s the trick to get these Polycom phones to share a line on any of these platforms? I even engaged Polycom tech support, (not bashing these guys, they do one heck of a job) but they claim their phones have been tested with SLA to work on BroadSoft and Sylantro systems. What if I’m not using these systems? Do I turn to the IP PBX manufacturer? Trixbox? Switchvox? Elastix? Will they modify their systems to get this to work? I know plenty of others are having the same issues, I’ve read about them on the forums out there. What needs to be done about this?

I’m not calling out Polycom, in my mind their phones are “top of the line,” but when I first took this case, I thought to myself “hmm this will be an easy one,” I’ll never think those thoughts again. What is portrayed to be an easy one-button click in reality is causing nightmares for users who would like to take advantage of this feature.

I’d first like to ask anyone who has read this post, to comment on whether or not they have performed this function, desiring to explore this functionality, or simply gave up because you couldn’t get it to work. Share your thoughts on the topic as well what system you are using, and what you have done to your Polycom phones to get this function to work.

Maybe something needs to be done? When I have a problem, I first dig myself deep into hands-on testing, and if I can’t solve it, then I turn to assistance from the manufacturer, but what happens when you don’t get an answer that solves the problem?

Please share your thoughts, feelings, and experience with this subject. It has been weighing on me for two weeks now. Phew.

iLocus Predicts Digium IPO

iLocus predicts an IPO or acquisition of Digum within 12 months.

Highlights from the article include:

Asterisk Open Source PBX currently downloaded an average of 3000 times per day.

Digium claims to have recently had their 26th consecutive profitable growth quarter.

Digium has shipped over 4 million gateway ports to date.

Digium sales are allocated approximately 52% North America, 25% EMEA, 23% APAC and CALA.

Nearly 45% of all Asterisk downloads these days come from Europe.

According to Digium, there are roughly 3.5 million to 4 million Asterisk servers deployed worldwide.

Digium estimates 110 million end points are connected to Asterisk systems.

Service providers who have built production services on Asterisk accounted for over 6 billion commercial VoIP minutes in 2007, and that volume is expected to double in 2008.

Digium claims 900k IP Phones were added to Asterisk based service provider systems in 2007, excluding the self-managed Asterisk networks of enterprise users.

Digium plans to address scalability issues in the short term.

The remainder of 2008 will certainly not be without drama in the OSS telephony industry. OpenSER, recently re-named Kamailio Project, and FreeSwitch both have aspirations to unseat Asterisk. OpenSER is more widely deployed in the service provider/carrier space, and accounts for more wholesale minute traffic according to iLocus. FreeSwitch have recently aligned themselves with Sangoma, a fierce competitor to Digium in the TDM hardware space.

No Surprise Cable Companies Continue to Lead Subscriber Race

July 29, 2008 by Garrett Smith

ISP Planet has a list of the top ten VoIP providers ranked by total number of subscribers, with data current through May 2008.

1 – Comcast – leads all providers with 5.2 Million subscribers.

2 – Time Warner Digital Phone – 3.18 Million subscribers.

3 – Vonage – 2.61 Million subscribers.

4 – Cox – 2.46 Million subscribers

5 – Cablevision – 1.685 Million subscribers.

6 – Charter – 1.085 Million subscribers.

7 – Insight Communications – 204,000 subscribers.

8 – Mediacom – 204,000 subscribers.

9 – Surewest – 54,000 subscribers.

10 – CBeyond – 36,000 subscribers.

As you can see, amongst providers reporting their current number of VoIP subscribers, the list is comprised almost completely of cable providers,with the exception of Vonage and CBeyond. For that matter, I’m not sure CBeyond really belongs on this list, since they do not offer residential VoIP services, but rather focus on delivering converged voice and data to businesses.

Sister Company, IP Camera Supply, Launches Blog

Company Providing Information for the IP Camera and Security Industry

IPCameraSupply.com a division of Sayers Technology Holdings, sister company of VoIP Supply and a leading IP Surveillance solution provider, has launched a new blog aimed at educating and engaging customers in conversations.

“We are extremely excited to launch our blog,” said Garrett Smith, Director of Marketing and Business Development.

“With the relative youth of the IP surveillance industry, it is important for solution providers like IP Camera Supply to be proactive in educating customers to ensure that they can make informed decisions. In addition to educating our customers, the blog gives us the ability to create and engage in conversations with our customers, partners and other industry media outlets so that we stay in front of the latest trends in IP Surveillance and stay well positioned to meet the ever changing needs of the market.”

Written by the staff of IPCS, with the occasional guest post from leading industry experts, the blog will provide readers with product reviews, do-it-yourself instruction, IP Camera terminology, industry news, company news, promotion announcements, , and editorial commentary on how the technology and industry is growing and evolving.

Blogs in the technology sector spring up by the hundreds daily, but blogs in the IP Camera realm are just starting to emerge. The IP Camera industry itself is still young, yet starting to grow.

Ribbit Sells For $105 Million

I wrote two weeks ago about Ribbit, the next generation phone service provider getting purchased by BT for a reported $55 million, but it now looks as if the company received $105 million. The deal took a few weeks to finalize (not that it is indicative of anything) and when ti was officially announced, the total amount paid by BT had almost doubled. This isn’t just good news for telecommunications entrepreneurs, but in many ways it is “validation” that the voice 2.0/ teleco 2.0 era is upon us.

Many will debate the price paid for Ribbit and the fact that they do not have any revenues (yet), but to a company like BT $105 million is a drop in the bucket compared with the potential return that the Ribbit technology platform could bring them. It will be very interesting to see if BT will “close-up” the platform or keep it open; monetizing it by giving businesses the ability to easily create telephony applications.

Ask Mr. Andrews: Setting Up SIP Ports

Dear Mr Andrews:

Can you explain how to set SIP ports on modern popular hardware phones such as the medium priced (or are they entry level these days) Sipura/Linksys/Cisco line?

Why would you not use 5060? If you have several phones behind NAT on the same LAN, is there a logical way to set these? How does the other endpoint see this? Enquiring minds and all that… I shall wait here on ICE for a STUNning discussion in a future article.

Part of the problem with NAT is that there are several competing mechanisms for negotiating it, and the industry cannot seem to get behind a single, unified methodology. Until this happens, dealing with NAT will likely continue to be a pain in the butt.

STUN, ICE and TURN are three examples of solutions to issues inherent with SIP + NAT. STUN is not 100% reliable depending on the type of NAT you are dealing with. ICE builds upon STUN by allowing the device to use a range of ports and STUN techniques. However, ICE is not well supported. Media relay solutions like TURN can cause latency/QoS issues with VoIP, and are generally difficult to scale.

If you are behind NAT, you can set up port forwarding on your router/firewall to allow VoIP traffic to pass through. For SIP, use ports 5060 to 5070. For RTP audio, use port 8766 to 35000.

There are definitely some security concerns with port forwarding. Hacking tools such as SIPFlanker http://tinyurl.com/sipflanker are available as well as public posts detailing the default login credentials for many Sip devices http://tinyurl.com/sippasswords

When configuring Linksys devices behind NAT, there are a few things you want to be particular about. In the configuration UI, in the “SIP” Tab, make sure you have the following options set:
*******************************************************************
Substitute VIA Addr: yes
STUN Enable: yes
STUN Server:

In the “Ext 1” Tab, make sure you have the following options set:

NAT Mapping Enable: yes
*******************************************************************
Double check the NAT Keep Alive Interval setting on your Linksys phone and make sure it is set to a low value, ideally around 10-15 seconds. For more information on configuring Linksys phones for NAT, refer to (starting) page 59 of the phone administration guide here http://tinyurl.com/linksysspa.

Faxing and VoIP at a Near Flawless Success Rate

Well for those of you in the VoIP industry, and for those of you just starting to learn about it, you will hear many horror stories about VoIP and faxing. Often you will hear how unsuccessful it is, and some will hear more vulgar words in conjunction with it. But what if you had that magic wand to make it work? Would you trust it? Would you try it? To what extent would you try it before tossing it out the window? What if I told you that there is technology out there that can fix Faxing over VoIP that is notorious for not being successful and being the cause of many long days and even longer nights?

These are all questions that the great VoIP thinkers at Sangoma have put onto the drawing board and now have come up with a solution: The Sangoma Faxing Synch Cable. This was first introduced to us by Konrad Hammel, a Field Applications Engineer with Sangoma that visited VoIP Supply for Training on the newest PCI cards.

Wondering how it works, and what you need for a near flawless success rate?

Well let’s start off with an IP PBX. The Phonebochs appliance, trixbox appliance, or a blank chassis using Plain Jane Asterisk will do to start.

From there, PCI cards. More Specifically Sangoma analog and digital PCI cards. Which ones you ask? Well you will need two of them. A digital PCI card, like the A101D, or A102D (T1 Digital PCI card), and then an Analog card to hook your fax machine up to. (A20100D (2 Port FXS), A20200D (4 Port FXS)) Cards are good, but you can go to a bigger FXS card if you wish. The only limit to the amount of ports is that of your IP PBX and its limitations; however I do recommend using echo cancelation on both cards, and trust me, it is well worth it.

FoIP

From here it doesn’t look like anything special–some of you may already have this and could possibly be drooling at this setup because it is easy. Well there is one more piece. And at this point you are probably thinking that it will be expensive and that now it’s not worth it to read on, but please keep reading, because what I am about to tell you will blow you away. The key to this is only $10. That’s right, for $10 you can have a near perfect success rate with LITTLE configuration of the cards and codecs. But how do you use it? Well this small cable will connect to a two prong section on the top of the Digital card, then the other end will hook up to a similar spot on the Analog card. From there, the cable will automatically start the synch and make it work. That’s it. Go figure. For decades this has been hindering businesses, and all it took was a small cable to fix it.

  • Featured Posts

  • Popular Posts

  • Read Our Feed

  • Latest

  • VoIP Post Categories

  • Archives