More Asterisk and XMPP (Jabber) integration

Last month I wrote about how to send an XMPP (Jabber) message with Caller*ID information to one or more users when a call comes in to your Asterisk server. This is a simple, one-way notification and is easy to set up. What if we want to interact more fully with the Asterisk server over XMPP?

Please note that I am referring to administrative interaction, not call-level interaction. Asterisk 1.6 adds a JabberReceive command to the dial plan, which would allow some interactive instant messaging within the context of a call.

It turns out that the Asterisk Manager Interface (AMI) posts an event for every XMPP packet–both outgoing and incoming–so writing a Manager application to interface with XMPP is a good way to go.

Writing a daemon in Perl to listen on the Manager interface for XMPP messages, and then interact with Asterisk through the Manager, ends up being pretty straightforward, especially with the Asterisk::AMI module available on CPAN.

Here’s the general flow:

  1. Set up the AMI connection, with Events => ‘on’ so that we get events. The user this script logs in as must be in manager.conf and have permission to receive events and perform any actions you want to be able to perform (originate calls, write to the database, etc.).

  2. Read in a list of buddies from Asterisk’s jabber.conf from whom Asterisk should accept commands.

  3. Set up a simple event loop that filters out just the Jabber events. Mine looks like this:

    while (my $event = $ami->get_event) {
    if ($event->{'Event'} == 'JabberEvent' && defined($event->{'Packet'} )) {

  4. Validate the XMPP message. Make sure it came from a valid buddy (step 2) and contains a command.

  5. Process the command, initiating any actions and sending results back to the XMPP buddy. So far in my script I’ve implemented a “call” command, where you can instruct Asterisk to originate a call to a certain number from an extension (or use the ring-all group as the default extension); a “dnc” command, that adds a number to the FreePBX blacklist (telemarketers), and help text.

How does it work? It’s simple–just add the Asterisk XMPP user (the one that sends you the call pop-ups from the previous posting) to your buddy list, and IM it your commands.

What’s left? I’d like to add some more useful interactive features.

  • When a call comes in and I get the Caller*ID pop-up, typing “cell” in the pop-up window will let me redirect the call to my cell phone. Or “vm” for voicemail or “zap” for Zapateller.
  • Missed/placed/received calls lists by pulling records from the CDR database.
  • Channel status, tech (sip/iax2) status, other statuses.

When is enough enough?

You could implement the entire Manager command set in this way, even implementing a very clunky attendant console or ACD supervision tool. That could be a bit much, but I see this being useful as a tool for common call-control tasks and simple administration tasks that would otherwise have to be performed at the command line (requires you to have an SSH session open to the server) or web interface.

If anyone’s interested in the Perl code in its current form, let me know.

What may drive opening the Unity Connection web interface

At this week’s meeting of the PSU VoIP tech folks, we had a short review of the Unity Connection upgrade from a couple weeks ago and discussed getting to the next version, 8.x, where we will have the ability (though not the scripting and configuration, yet) to open the web interface to end users.

I think the primary feature of interest to end users on the web interface will be the visual voicemail, called Unity Connection Inbox. But what may drive getting the web interface up and running, at first, will be the ability for end users to change their own PIN.

Very roughly speaking, from some stats I received a few weeks ago, our NOC gets about 1,000 voicemail PIN resets a year. They account for 18% of all voice-related tickets and 11,000 minutes of staff time.

With the web interface, voicemail users could log in with other credentials they know and use daily–their single sign-on access accounts–and reset their voicemail PIN. The concept is simple but the implementation, at least in our environment, may not be.

Cisco Virtualized Unified Communications

Cisco now offers VMware ESXi as a platform for many of their Unified Communications products, including Communications Manager, Unity and Unity Connection, and Contact Center.

I attended Cisco’s TechTV webinar today to learn about it. Great stuff. As you can guess, there’s a catch–it runs on their own server offering, only. It makes sense. Cisco has always prescribed the hardware in order to ensure the environment is right for enterprise voice-over-IP. That is still the case. But the big deal here is that you can now get TAC-supported, VMware-platform Unified Communications products and the benefits of virtualization–more servers on less hardware, easier backups, management through vSphere tools, speedy deployment, and so on.

Will the VMware offering be restricted to Cisco server hardware forever? My guess is, probably not. But the environment would still need to be well-controlled, with strict hardware specifications and not loading other (non-Cisco) VMs into the environment.

Voicemail, standardized

One of the technical details of last weekend’s move from Unity to Unity Connection 7.1 is that the integration with Call Manager is no longer through CTI ports (Skinny protocol) but through a SIP trunk. This was a design choice; CTI connectivity is still available.

There is a bit of a move at PSU University Park to get Call Manager out of the center of the voice network. That is to say, Call Manager doesn’t need to be the core entity to which everything connects. As the “SIP Core” is planned out and the pieces designed, we are able to see how some generic SIP routing devices can be the glue to hold together SIP-connected components: PBXes from the whole Penn State system, including the Call Manager cluster at University Park; Unity Connection; trunking providers and PSTN gateways; standalone analog gateways; adjunct applications like Contact Center; video conferencing over SIP; and more.

Unity Connection is now directly connected to Call Manager via SIP trunk, but can easily be attached to a SIP core in the future, where it could also provide voicemail services outside of the Call Manager domain. My opinion is that this is a really good thing, because Unity Connection is a high-quality voicemail system. (Compare to Asterisk’s “Comedian Mail.”)

Shared voicemail between PSU campuses? Voicemail services for analog users? Yes, please. (Note, Unity Connection has a “multi-tenant”-type system that could allow extension overlap, but for a true unified voicemail system, you’d probably have to renumber per E.164 standards to get rid of overlap and simplify.)

High per-user licensing costs are one hindrance to making this progress, but compared to the costs of implementing and maintaining multiple voicemail systems, the numbers don’t look so bad.


PS. Voicemail seems like something that could go away any day now–not from our service offerings, but from public interest. We probably thought the same of FAX every year for the last several, but it hangs on, and in spite of voicemail-killing technologies like SMS (which the students seem to prefer quite a bit over voicemail for notifying each other that they tried to call), voicemail is hanging on, too.

PSU voicemail upgrade – Unity Connection 7

This Friday, the University Park VoIP voicemail system, currently Cisco Unity 4.0.5, will be upgraded–migrated, actually–to Unity Connection 7. A number of us received training on this last fall, and we are eager to move ahead to the new system.

In terms of features, this is a one-for-one migration–no features lost, and no features added at the time of the upgrade. We have been running Unity in voice-mail-only (VMO) mode, where an Exchange mail system acts as the voice mail storage facility and nothing more–no e-mail integration, web access, or other Exchange features. Connection is designed for the VMO-type deployment, so while the feature set remains the same, we are gaining a lot with this upgrade, administratively:

  • no more Exchange
  • no more domain management to support an isolated Exchange
  • no more Microsoft patching for the above
  • two messaging servers rather than two (Unity) + two (DC) + two (Exchange) = six
  • Cisco Linux platform, including the better Disaster Recovery System (DRS) and upgrade/patch deployment

And lastly, this gets PSU un-stuck from 2004 and able to move ahead more easily as new versions or features come along.

Coworkers Chris (who needs to update his blog) and Sean are the ones making this happen. Huge thanks, guys.

Going beyond the straight migration of this weekend, what’s next? I wrote about some end-user web features we saw in training:

End-user Web Features
  • Unity assistant – per-user settings manager, like Communications Manager User Options site
  • Unity inbox – view, listen to, forward, reply, etc. to voice messages. Play messages through the web browser or download to PC.

I believe that with some reconfiguration on the back end having to do with the way accounts are keyed (need some affiliation with the PSU access account ID), a proxy written similar to what we did with Call Manager 6, and some gentle but consistent pressure from users for such useful features, we could enable the two listed above. And in time, and depending on where University e-mail is headed presently, we may even be able to deposit voicemail in people’s e-mail boxes. (NOTE: this is my wishlist and not a statement that these things are planned or that I am even working on them… but I’d like to.)

Stanford VoIP

Our educational brethren at Stanford University are deploying fully-converged, full-featured Cisco Voice-over-IP, including

Stanford has moved from an analog, apparently carrier-based offering, to Nortel VoIP, and now to Cisco VoIP, and continues to support all three. This looks like a great voice communications package for university faculty and staff. Kudos, Stanford!