Unified Messaging (UM) is an idea that seems simple on the surface but is complex in practice. The benefits of having access to all your voicemail, fax, and email messages in one place are pretty obvious: You can spend less time switching between the telephone, fax machine, and computer, and you can gain access to all of your communications from wherever you happen to be. In the real world, how does Exchange Server 2007’s UM implementation stack up to the unification promise, and what do you need to know to implement UM in your own environment? To answer these questions, you’ll need to learn some phone lingo and have a good basic understanding of what Exchange 2007 does and doesn’t provide.
I’ll look at what Exchange UM does, review its components, and discuss how a PBX works with Exchange, including setting up Exchange as an automated attendant. I’ll then describe Outlook Voice Access (OVA), a telephone-based client that offers users access to their mailboxes and calendars.
What Exchange UM Does
Exchange 2007’s UM server role provides several primary services to subscribers (in this context, a subscriber is a user or mailbox that’s enabled for telephony functions such as voicemail). The UM server role
• answers voice calls
• receives faxes (but doesn’t provide any kind of outbound fax service)
• delivers voicemail and fax messages to subscribers’ Inboxes, which they can access by using any version of Outlook, Pocket Outlook, Outlook Web Access (OWA), or Entourage
• provides interfaces that OWA 2007 and Microsoft Office Outlook 2007 can use to offer enhanced features, such as annotating voicemails with searchable text notes and playing a voicemail message on a phone instead of on the computer
• provides an automated attendant service that can answer calls and route them to people, by using both speech recognition and dual-tone multifrequency (DTMF)—touch-tone—input to find to whom the caller wants to speak
• provides OVA, a telephone-based client that gives subscribers full access to their mailboxes and calendars
Exchange UM doesn’t perform some important functions. As noted, it doesn’t send faxes. You’ll need some other kind of desktop or server fax solution if you want your users to be able to send faxes from their desktops or Outlook sessions. In addition, Exchange UM doesn’t replace your PBX; you must have a phone system that can originate, answer, and transfer calls. And Exchange UM might require a gateway, as I’ll address later.
To accomplish its magic, Exchange 2007 UM servers support several new protocols. First is Session Initiation Protocol (SIP), which Exchange uses to set up and route calls between phones, the PBX, and the UM server. Second is the Real Time Protocol (RTP), which actually moves voice data from the PBX or gateway to Exchange and back again. Third is T.38, an International Telecommunications Union (ITU) standard for fax data. Several other protocols are used at various points in the UM call-delivery process, but I’ve mentioned the major ones.
Exchange UM Components
The Exchange UM server is only one part of the phone system. Although that sounds odd, if you think of an Exchange UM server as a piece of telephone equipment, you’ll see more easily how all the pieces fit together. To use Exchange UM in your organization, you need a compatible PBX. Understanding what makes a PBX compatible requires a little side trip into what a PBX is and does. A PBX is essentially a specialized piece of hardware that creates a private telephone system for your organization and connects it with the Public Switched Telephone Network (PSTN). When your PBX is set up and working, you can receive incoming calls (either through a central operator or through Direct Inward Dialing—DID), and you can place calls between extensions in the organization or to outside phone numbers on the PSTN.
In telephone lingo, what you'd typically call a line is referred to as a trunk. The type of trunk your PBX supports determines whether you need a gateway. Exchange expects to see SIP packets arrive to indicate that there’s a call for it to handle. Some PBX systems create native SIP trunks, but most don’t. If your PBX doesn’t create SIP trunks itself, you’ll need a gateway to take signaling and call information from the PBX and turn it into a SIP trunk for routing to Exchange. The two major gateway vendors are AudioCodes and Dialogic. For information about which gateway models are supported for use with which PBX systems (a topic too complicated to cover in this article), go to http://www.microsoft.com:80/technet/prodtechnol/exchange/e2k7help/2516dac1-dfdc-47eb-8e6f-18b1537a57b2.mspx?mfr=true.
In an ordinary PBX system, several logical objects tell the PBX about how the phone system is set up:
• Extensions represent either physical phones or logical objects (e.g., hunt groups). The PBX might impose restrictions on extensions (e.g., which numbers extensions can call).
• The dial plan specifies how many digits each extension has and how to ring one extension from another (e.g., when multiple PBX systems at different locations are interconnected).
• One or more hunt groups permit calls to one number (a pilot number) to be routed to one of a group of extensions. For example, dialing extension 5000 might transfer a call to the first nonbusy extension in the sales department’s hunt group.
• Call-coverage information specifies what happens when an extension isn’t answered or is busy. Typically, a call that isn’t answered after a set number of rings is sent to the voicemail pilot number and a busy call is sent immediately to the pilot number.
Exchange has equivalent objects that tie the Exchange UM server’s knowledge of users and mailboxes to the physical equipment of the PBX system:
• Every UM-enabled user has an associated extension, defined as a property on the user’s Active Directory (AD) object. This extension should be the same as the user’s “real” phone extension.
• Every Exchange organization will have at least one dial-plan object. The dial plan contains information about the default language that Exchange should use in the telephone UI (TUI), the maximum length of a voicemail message, which audio codec to use, and how voice access to the directory should work. You can create multiple dial plans to handle complex PBX topologies.
• Every PBX-to-Exchange gateway has an associated IP gateway object. Exchange uses these objects to figure out where calls originate and where to send or transfer them. You must associate a gateway with a dial plan so that Exchange is aware of the existence of the gateway and will accept calls from it.
• The Exchange server itself has a pilot number, which Microsoft refers to as the subscriber access number. Users dial this number to get direct access to the voicemail system, and you program the call-coverage information on your PBX to route unanswered calls or calls to busy extensions to this number so that Exchange can answer them.
Hello, Exchange? It's for You!
After you’ve deployed an Exchange UM server, when someone calls a subscriber’s extension, the Exchange server won’t get involved until the PBX decides that the call won’t be answered. Let’s take a look at how call answering actually works. Alice calls Bob by using either the PSTN or an external extension. Her call arrives at the PBX, which rings Bob’s extension. If the extension is busy, the PBX will use its call-coverage information to redirect the call; if the call isn’t answered after a set interval, the same thing will happen. Because Exchange UM has been deployed, the PBX will send the call to the Exchange server’s subscriber access number.
How the PBX routes the call to the Exchange server depends on which kind of PBX you have and whether a gateway is involved. Generally, however, the PBX will send the call-signaling information (including the caller’s number, the desired extension, and some other phone system–specific information you don’t need to know about) to the gateway by using a phone-signaling protocol such as QSIG, an ISDN-based signaling protocol for signaling between PBXs. Because Exchange speaks only SIP, the gateway will turn the call-signaling information into a SIP INVITE request. This request, which has a specific format (described in Request for Comments—RFC 3261), contains the same information about the caller and the call recipient, but it adds a critical piece of information that indicates why the call was forwarded, or diverted, and who should get it now. That’s when the fun starts.
The Exchange UM server accepts the SIP INVITE message, then sets up a two-way RTP connection back to the PBX. As part of this process, the Exchange UM server examines the diversion information to figure out the extension for which the call is intended. Exchange uses the called number to attempt to find a matching extension belonging to a UM-enabled user. If Exchange finds one, it retrieves the user’s mailbox greeting message, which is stored in the user’s mailbox, and plays it to the caller by converting the audio file to a stream of RTP packets that Exchange sends back to the gateway or PBX. If the caller decides to leave a message, the message arrives at the UM server as a stream of RTP that’s converted into an audio file and delivered to the user’s mailbox. More precisely, the UM server creates a new message, by using the caller’s telephone number as the originating sender and resolving that against both the Global Address List (GAL) and the user’s Contacts folder. The UM server then sends the new message to a Hub Transport server in the site, from which it’s delivered to the user’s mailbox. (Fax calls are answered in essentially the same way, except that Exchange gets a stream of T.38 fax data and turns it into a TIFF file.)
Of course, this process involves lots of subtle details. For example, if the caller presses “0” to get an operator after the greeting plays, Exchange can send another diversion request to redirect the call to an operator. After the caller leaves a message, Exchange lets the caller perform actions such as listening to the message, rerecording it, and changing its priority.
The Automated Attendant
Exchange can also act as an automated attendant, answering calls and routing them to extensions based on the caller’s input. You can easily create a typical automated attendant phone tree, giving callers options such as pressing 1 for sales, pressing 2 for customer support, and pressing star (*) for a company directory. You do so by creating new automated attendant objects in Exchange Management Console. More interesting, however, is the automated attendant’s ability to dial users by name: The caller can ask for “Joe Smith,” and the UM server will look through a pre-generated “grammar” built from the contents of the GAL and attempt to find the correct user. Callers can also use touch-tones to spell the user’s name, a feature I appreciate, given that most people don’t know how to say my last name.
Outlook Voice Access
Voicemail and fax capabilities are only part of what Exchange UM provides. Voice access is another critical part of the Exchange UM story. OVA provides a TUI that lets callers interact with their Exchange mailboxes by using voice and touch-tone dialing. You can manipulate messages and appointments, look up contacts, and even place calls by calling the OVA subscriber access number and by using natural-language phrases such as “clear tomorrow’s calendar” or “call Paul Robichaux at home.” This feature is supremely useful for those times when you need to know something but can’t get to a computer, such as when you’re driving to a meeting and need to know the exact location or need a phone number that you don’t have with you. It’s also a useful way to communicate schedule changes caused by traffic, travel delays, or other unforeseen occurrences. Unfortunately, you can’t customize the vocabulary that OVA understands.
OVA works by answering calls sent to its extension, accepting the user’s PIN for logon, and logging on to the mailbox. Through segmentation settings that apply per user or security group, you can control which users have access to OVA and even which OVA features they can use. After users have logged on, they have full access to the messages in their mailboxes, which OVA will read on demand. In addition, logged-on users can create and modify calendar items, accept or reject meeting requests, clear their calendars for a specified period, and even get the details of a particular appointment. OVA works best when you’re in a relatively quiet environment; I’ve used OVA with a speakerphone in a crowded auditorium and found that, if there’s background noise, it’s better to use a headset or cell phone. For now, the release version of Exchange 2007 supports speech recognition for US English only, though it seems to handle accents reasonably well. Microsoft hasn’t made any formal announcement of support for other languages. However, the company has greatly expanded the number of languages that OVA supports, so I expect support for additional languages.
Deploying UM
Deploying Exchange UM requires you to understand your phone system, but the Exchange portion of the deployment is straightforward. You’ll have to purchase enterprise CALs to use UM, and you’ll need the UM server role installed on at least one server. After meeting those prerequisites, you need to UM-enable the users you want to have subscriber access, create a UM dial plan and one gateway object for each gateway, and configure the gateway and PBX to talk to each other. This final step is actually the most complicated, but you can make it easier by working with the people who support your phone system to make sure you know how the system works and exactly which kind of PBX hardware and software you have.
