Anyway, I’ve summarized what I love about the AA60, and what can be improved:

Pros:

- Recording calls from the web interface. Works great. Recorded calls end up in your voicemail box. Perfect. In-call recording using a dialed code to start and stop, not included.

- Panels can easily be integrated into desktop apps, like the experimental panel I built for my Excel contact sheet using RealBasic’s browser control.  Good stuff.

- No problems with call quality. Works great with Junction Networks IAX and SIP trunks (I’ve tried both but prefer IAX since it’s more firewall-friendly).

- Auto-provisioning is stupid simple.  And Polycom makes some of the best SIP hardphones money can buy. P.S. Polycom seems to be the preferred phone vendor for SwitchVox PBXs.

- Call-logging and reporting is great. There are a variety of built-in traffic reports, CDRs, and an Excel export that works very well.

Cons:

- No IAX endpoint support.  Given how downright simple it is to support IAX in an Asterisk environment like SwitchVox, this is just silly.  Add IAX support, guys. Really.

- The web interface could use a few tweaks. Setting up cascading call groups is tricky, for example. But hey the AA60 is a small business product so it’s hard to complain.

- No redundant power supply or storage (the higher-up model offers both).

Well, I’ve finally had what I consider to be ample time to check out every nook and cranny of the SwitchVox AA60 VoIP , and I’ll stand by the belief that SwitchVox is the best Asterisk variant available, and not just because of its slick user interface. (For what it’s worth, Polycom owns the sound quality battlefield, too.)

One of the coolest things about SwitchVox is called Panels, which are web service apps that you can run in your web browser when attached to the SwitchVox server. When a call comes in, or some other event occurs on the phone system, your panels can perform certain behavior–like display a virtual switchboard or the status of a call queue.  Or, my current favorite, the Google Maps panel, which displays the location of the caller based on the caller’s area code and prefix.

There are a few problems with Panels, though.  For one, there doesn’t seem to be enough adoption of the Panels idea in the industry. That is to say, you can’t just go download cool new panels the way you can download Dashboard Widgets or iPhone apps.  So, the few Panels that are freely available in the marketplace, while nifty, serve as little more than props for the idea of Panels, concept demos if you will.

One of the programs I’ve been experimenting with is Now Software‘s Now Up-To-Date and Contact, a contact management / quasi-CRM package from the fellas a few miles south of me in Columbus.  I’m really digging this program, but as I’ve begun to envision how I might combine Now Contact with a telephone system such as SwitchVox, the integration becomes a daunting task.  I’d like to be able to trigger web service events from what Digium calls “SwitchVox URLs” (get requests that occur when certain telephony events happen) that point to the server where my Now Contact data is stored to, say, set up an automated dialer, or better yet, journal incoming and outgoing calls.

Of course, the folks at Now are knee-deep in their as-yet-unreleased flagship product, Nighthawk, and I believe that, architecturally, the Now people are keeping an open mind about VoIP interfaces and XML web services-the two things that could make Asterisk users (numbering in the 100′s of thousands) absolutely lust for Nighthawk.

Indeed, adding a combination of simple SIP signaling and XML web-service functionality to Nighthawk and then setting it alongside Asterisk/SwitchVox would create a CRM/contact-center system so potent that even fearless old Cisco might tremble.  After all, Cisco’s Express contact management and CallManager are a hair more expensive than Now’s products and SwitchVox, even if Cisco stuff could be dumbed down for SMBs.

So I’m encouraged by what I’m seeing from Now Software, but equally excited about SwitchVox, so back to the AA60.  Configuring hunt patterns and call cascading was kind of a pain at first, probably because I’m so accustomed to doing it on other systems, most notably plain vanilla Asterisk, but now that I’ve got the hang of it on SwitchVox, I realized how dead simple they’ve made it.

I can’t wait to see future revs on the user interface. The AA60′s response time loading web page was a bit less than snappy, and there are elements of the user interface that shouldn’t require full blown page loads, so I would love to see Ajax used heavily in future revs.

In a future post I’ll talk about how phone provisioning differs on SwitchVox versus Jazinga, and I’ll also cover setting up a soft phone on SwitchVox and describe the interesting experience I’ve had with Junction Networks this week.

Anyway, the point I was trying to make is, more precisely, that port-forwarding in particular doesn’t break IAX connections the way it breaks SIP connections. Aswath writes:

If so, then SIP could also decide to use a standard UDP port for media and realize the same benefit. Consider the case of an end-point that is behind a NAT.

Not true, Aswath. For one, it is NOT possible with SIP to use the same port for media all the time, since SIP uses RTP (while IAX has its own buil-in payload protocol), and RTP by definition must be set up by a signaling protocol such as SIP, MEGACO, or H.323. Protocol interop requires that RTP run on the port specified at call-setup during capabilities negotiation stage in its various forms on each signaling protocol.

For two, even if you could get all endpoints to use the same socket address for all signalling connections and media connections, SIP still doesn’t advertisig the correct socket address within its headers in a NAT scenario. More specifically: SIP headers, created by VoIP endpoints like phones and servers, include the local (not NATted) socket addresses that the responding endpoints will use to create a UDP connection back to an advertised socket at the calling host prior to the beginning of a call. So, even when attempting to port-forward SIP’s port (5060/5061), or RTP’s payload ports, the protocol simply breaks.  Not because there are multiple ports, but because the protocol itself requires the use of non-NATted socket addresses in its headers in order to advertise communication pathways.

IAX simply doesn’t have this problem because the protocol doesn’t carry socket addresses to create connections back to the calling endpoint using a different socket.  Rao does clarify his position by stating that the ICE traversal framework is his basis for his statement that I’m not giving the full story about IAX (because I didn’t mention direct call paths as a feature of IAX2, something just about nobody needs).  But, on the streets, and especially on the SMB prem, nobody’s relying on ICE or worried about adherance, and everybody’s using inward NAT, port-forwarding, and socket translation.  Seriously, ICE may be elegent  but isn’t required to make IAX work in both directions through a NAT device.  IAX simply works better than SIP when NAT techniques are used.  Indeed, SIP doesn’t work at all with NAT (in either direction) unless application proxies are in place (STUN, a SIP media gateway, or something of the ilk).

Now, on Aswath’s point about direct call paths with IAX and SIP (which you can read about in my book Switching to VoIP), let’s face it. The only people using IAX are Asterisk users. Period. You won’t find Asterisk support on a Cisco or Avaya device.  The bulk of Asterisk installations are campus-area in nature and fewer than 500 users per server. There’s literally no need to use direct call paths in the vast majority of these installs because IAX imposes little overhead on a modern server, even with dozens of simultaneous calls.  In most environments where an Asterisk server would have a high enough call load to require the use of direct call paths a la CPO, you’re talking call center, you’re talking call recording, barging, conferencing, etc.  The needs of a large environment necessitate centralized (ie server-proxied) call paths, making Asterisk users that much LESS likely to touch direct call paths.

So if the only people running IAX are Asterisk people, and Asterisk servers almost never experience a bottleneck requiring the use of direct call paths, seriously, who cares about ICE?

Anyway, Aswath, I love your blog, keep it coming.  You should post more often!   Just remember there’s more to life than protocol purity and adherance. There’s also what the street demands: practicality.

Regarding the Digium/Switchvox AA60 appliance, it’s obviously Linux and Asterisk based, but all the delightful fun ordinarily associated with Asterisk administration has been boiled down to a cute web interface that really works, and really works better than the competition.

And it’s built to run.  I mean, the thing doesn’t even have a power switch.  Plug it in and it boots up.  Want to shut it down? Unplug it (or do a soft shutdown).  Point is, there’s nothing to bump to accidentally turn off your PBX, and that’s not necessarily a bad thing. (Neither is the external power brick–much more serviceable than an internal PC power supply.)

Out of the box, the self-signed certificate on the web interface will make IE and Firefox both moan, but add it to your exception list and you’re off and running.

The version I’m looking at is SMB 3.5.  The web interface is the familiar Switchvox red-bar-across-the-top with pop out menus.

Above, you can see Switchvox’s clean, snappy UI, probably one of the main reasons for the appeal to Digium, whose Asterisk Appliance had a comparatively clunky, slow UI.

The User Tool is a web-based app that any user of the PBX can log into using a browser. It gives access to personal call histories and allows the user to export his/her own CDR directly to an Excel file.  Useful stuff. I can see this coming in handy for inside salespeople.

The Switchboard, launchable from the User Tool, is another web based app. It provides front-desk-like command and control of all lines, extensions, and calls within a user’s credentialed reach so they can drag and drop to perform telephony functions like call parking and so on.  I’ll go into more detail on this later after I’ve provisioned a few phones on this AA60.

This Switchboard app is not as sparkly as the Trixbox HUD (which is not web-based), but I would think this would be sufficient for a small call center operator or a group manager.  The only drawback is being forced to leave a browser window open.  We all know how tricky it can sometimes be to surf the web with a window we WANT to keep parked a certain URL open in the background. Sometimes the browser or a client side script will decide to jack that window and poof, there goes our Switchboard.  But that’s no fault of the AA60, of course.

Next I’m going to add some phones to the system. Stay tuned.

And, I was going to videotape the whole process so I could share the ups and downs with folks on YouTube. I plugged the Linksys phone into the LAN and went to get my camcorder.  But, by the time I got back with it, which was about 2 minutes, the phone was ALREADY RUNNING on the Jazinga system. So it went from out the factory box to being a working SIP peer on the Jazinga system, firmware config and all, in under two minutes, and the best part–I did NOTHING, just as Jazinga claimed. Heck, I didn’t even have to key the MAC address of the phone into the Jazinga box.

Those clever Canadians are pretty good at this VoIP stuff–they should keep it up!

Yesterday I had a great talk on the phone with Randy Busch, CEO of Jazinga, the Toronto-based technology company behind the Jazinga VoIP PBX system. I learned several positive things during this conversation:

• Jazinga isn’t required to be a NAT firewall in order to support IAX trunks, as it is in order to support SIP trunks.
• Jazinga is based on Asterisk and Freeswitch.
• Its web user interface is mainly Flash-driven.
• It has an onboard hard disk and is basically a single-board PC type appliance.

Autoprovisioning: Here’s How it Works

One of the things I really like about the Jazinga is autoprovisioning. If you enter a phone’s MAC address into the admin interface and then boot the phone up from a factory state, it obtains all it needs configuration-wise directly from the DHCP and TFTP servers onboard the Jazinga unit.  So, very easy for non-technical folks trying to get set up.  Right now, Jazinga supports automatic provisioning of Polycom, Linksys, Aastra, and SNOM phones. Randy tells me that Cisco 79XX support is in the works.

Having this simple endpoint setup is awesome, and the reduction in steps required handily downs many Asterisk solutions, becuase all the phone provisioning components (DHCP, TFTP, generation of firmware configs, etc.) are already done for you.

Softphone and Hold Music: No Sweat

Running Bria with the Jazinga was as easy as it was with the Asterisk Appliance.  I uploaded an MP3 of Runaround by Blues Traveler to test the hold music feature, and it worked great.

Groups and Call Distribution

Ring groups are a snap, though the only option for ring patterns is simultaneous. Given the size of customer Jazinga is going for here, I don’t think that’s a drawback.  Note that Asterisk Appliance allows different ring-around patterns, but only if you know the Asterisk keywords necessary to make them work.  The keyword with call distribution on Jazinga is “simple”, which I believe appeals to the SOHO customer.

Jazinga SIP Trunk Service

The Cleveland-local number the Jazinga folks set up for me worked like a champ, though I did have to reboot the Jazinga unit in order to get incoming calls to work.  There seem to be no options for tweaking caller ID on the Jazinga-operated PRI, but I’ve got to assume that it’s coming.  Sound quality was acceptible. I called my mother, who was camping in central Ohio at the time.

So what’s the verdict?  We’ll discuss it in a few days after I’ve run Jazinga through its paces with a few auto-provisioned IP phones. Stay tuned.

- When I say Asterisk is thought of as an API and not a solution, what I mean it’s a product-making kit, not a product. So there’s no Asterisk “S8300 media server” or some such. The point is, it’s up to the consultants to productize Asterisk in a meaningful way, and save for Switchvox and Fonality, that just hasn’t happened.

- Asterisk won’t sell into the Fortune 1000. It is a breakdown of logic to think Asterisk can be sold into the Fortune 1000 for lots of reasons, but the most prescient one is this: Fortune 1000 companies require national, if not international service footprints that are dense, quick, and connected to aggressive SLAs. Asterisk consultancies offer no such service. Hence Avaya and Cisco sell into the Fortune 1000 while Asterisk does not. This is the key problem with open source. It’s not open source’s fault. It’s just a fact.

1. Digium and its channel can’t sell against blue chippers. Avaya has a huge distributor channel filled with high-paid salespeople that get the job done. Asterisk, not so much. So there’s a polish Avaya, Cisco, and Nortel offer that Asterisk doesn’t. Some of the people running around calling themselves Asterisk consultants are just plain shabby. Then again, this is not uncommon in the open source world, I’m sorry to say.

2. Avaya has well-defined hardware products that are tangible and capital-oriented. Digium does not.

3. Asterisk is open source and there’s no comfort level with open source among board room buyers.

4. It’s still too hard to get immediate support for Asterisk-based products, and a Switchvox or a Fonality doesn’t have the same mobile support force that an Avaya does.

5. Asterisk is a solution developer’s product of choice, not an end-customer’s product of choice. When people hear ‘Asterisk’, they think ‘API’ instead of thinking ‘solution’.

6. The market is growing. Asterisk’s market share could increase steadily without the necessity for a decrease among its competitors.

- Inherit and continue development of a mostly-PHP based management add-on for Asterisk.
- Develop new features and database functions for one-of-a-kind, industry-specific telephony management application.

Required skills:

- PHP
- Apache
- Asterisk
- MySQL

Desired skills:

- AMP or FreePBX experience strongly preferred
- Strong SIP knowledge preferred

You’ll be working as a subcontractor on a high-profile VoIP project with some of the leading VoIP thinkers in the industry. Interested? Contact me right here.

If any specific product is given more attention than others, it’s Asterisk, but that’s not only welcome, it’s unavoidable given the subject matter. The treatment it receives here also beats the everloving tar out of the O’Reilly book dedicated to Asterisk exclusively.

Here’s the rest of  the review.

This release contains a very large number of bug fixes, including a fix
for the recently discovered security vulnerability.

It also contains a complete rewrite of the Shared Line Appearance (SLA)
support that was first released as part of Asterisk 1.4.0. The new
version of this functionality has been tested against a variety of
phones and provides much more flexibility and configurability (along
with actually working properly in most scenarios, which the original
implementation failed to do). Users who are interested in SLA
functionality should update to this version and try it out; we welcome
bug reports and test reports.

Because of the security vulnerability fix present in this version, all
users of Asterisk 1.4 are urged to update as soon as they can schedule it.

The VoIP Business Analyst is an individual contributor and is responsible for the analysis, design and implementation of processes for the delivery of VoIP, IPT and other voice services. Your role will include communicating with both technical and business-oriented individuals.

You will be responsible for developing working documents, as well as coordinating deliverables, individual status reports and client provided documentation.
You will need a solid technical foundation in VoIP, IPT technologies as well as hands-on experience with UNIX Admin, SQL, SNMP and scripting, implementing and validating solutions.

If that’s you, Skype me at tedwallingford or leave a comment with your email address (it will not be shared with the public).

Many of you may have seen the recent announcement about Danny Windham coming on as the new CEO of Digium.  This is one of the most exciting things to happen to Digium and to Asterisk at large.  When Danny comes on board, I will be transitioning to the role of Chief Technical Officer (retaining my position of chairman of the board of directors), providing strategic vision for the company as well as being able to focus more extensively on the community, the customers and the technology.

My sincere hope is that this transition will not only directly benefit the Asterisk community and Digium customers, but will allow me to spend much more time with the community and with Asterisk, playing a more important technical role in our roadmap for both hardware and software.

I’m looking forward to working more with the community and the developers to help grow the future of Asterisk even more!

Mark