UM Auto Attendants | Planning for Unified Messaging

Using a UM auto attendant, you can create a voice-menu system that enables your callers to navigate through voice menus to locate or transfer calls to your UM-enabled users or departments. You can create and use your own voice prompts so that you're able to fully customize the UM auto attendant to your own needs.

The UM auto attendant uses a series of WAV files that callers hear instead of a human operator. The callers can navigate the menu system, place calls, or locate users using DTMF or voice inputs.

Note

You can join auto attendants together to form multi-level menus.

The UM auto attendant allows you to provide the following:

• Corporate or informational greetings, such as business hours or directions to a location
• Custom corporate menus that you can customize to have more than one level
• A directory search function that enables callers to search the organization's name directory
• The ability for callers to connect to the telephone of—or leave a message for—UM-enabled mailboxes

You are not limited in the number of UM auto attendants you can create, and each auto attendant can support an unlimited number of extensions. However, you should design menu systems for auto attendants carefully to ensure that the user has a positive experience. If you design them incorrectly, users can become very frustrated if the time it takes to connect correctly is lengthy or navigating the system is difficult. You should especially consider creating additional UM auto attendants if you are operating in a multi-language environment so that you can provide a dial-in number for each language.

When you create a UM auto attendant, you must provide the associated UM dial plan and extension number(s) to access the UM auto attendant. After creating the UM auto attendant, you can configure alternative greetings by specifying the WAV files to use. You also can configure different settings for work and non-work hours and features such as call transferring. You can create auto attendants in the EMC or by using the New-UMAutoAttendant cmdlet in the EMS.

UM Hunt Groups | Planning for Unified Messaging

A UM hunt group is a logical representation of an existing PBX or IP PBX hunt group. When the hunt group's pilot number receives a call, the PBX or IP PBX looks for the next available extension number to deliver the call. When the call's recipient does not answer an incoming call, or the line is busy because the recipient is on another call, the PBX or IP PBX routes the call to the UM server.

UM hunt groups act as a link between UM IP gateways and UM dial plans. Therefore, you must associate a UM hunt group with at least one UM IP gateway and one UM dial plan. UM hunt groups locate the PBX hunt group from which the incoming call was received. A pilot number that is specified for a hunt group in the PBX also must be specified within the UM hunt group. The pilot number enables the UM server to associate the call with the correct UM dial plan so that it can route the call correctly.

When you create a new UM hunt group, you enable UM servers in the specific UM dial plan to communicate with the UM IP gateway. You need to specify the UM dial plan and the pilot identifier or pilot number that you want it to use with the new UM hunt group.

Note

You can create UM hunt groups only if you have already created a UM IP gateway.

UM IP Gateways | Planning for Unified Messaging

A UM IP gateway is a logical representation of a physical IP gateway hardware device that translates between the circuit-switched telephone network and an IP or packet-switched network. This represents either a VoIP gateway or an IP PBX.

The UM IP gateway contains one or more UM hunt groups and other UM IP gateway-configuration settings, including the actual IP gateway. The combination of the IP gateway object and a UM hunt group establishes a logical link between an IP gateway hardware device and a UM dial plan.

Note

Before an IP gateway can process calls, a UM IP gateway must be associated with at least one UM dial plan.

You can create a UM IP gateway using the Exchange Management Shell (EMS) or Exchange Management Console (EMC). When you create a new UM IP gateway, you enable UM servers to connect to the VoIP gateway or IP PBX. However, you can enable or disable the UM IP gateway. You can disable a UM IP gateway in two different modes:

• Disable After Completing Calls Forces UM servers associated with this UM IP gateway to stop handling any new calls.
• Disable Immediately Forces all associated UM servers to drop existing calls for this UM IP gateway.

UM Dial Plans | Planning for Unified Messaging

The UM dial plan is the basic Unified Messaging administrative unit and used for telephony extension-numbering. 

The UM dial plan, plus the extension number, provides the unique identifier for each UM-enabled user. The UM dial plan also controls the numbering scheme and the outbound dialing plan.

The UM dial plan is an Active Directory container object that is a logical representation of a Telephony dial plan that you configure on a PBX. The UM dial plan establishes a link from an Exchange Server 2010 recipient's telephone extension number in Active Directory to a UM-enabled mailbox.

Before you can use Unified Messaging, your Exchange environment requires at least one UM dial plan to be created, assigned to a UM server, and associated with a UM IP gateway.

When you configure UM dial plan settings, you have to define at least the extension length. Additionally, you can configure other UM dial plan settings:

• Access numbers for subscribers (OVA phone number) or your UM -enabled users dial to access their mailbox via a phone.
  
  
• Default greetings that is used when subscribers call into the UM server.
  
  
• Dial codes for dialing external phone numbers and international numbers.
  
  
• Features such as whether subscribers can transfer callers to other users and whom callers can contact.
  
  
• Time limits for calls, messages, and idle timeouts.
  
  
• Default language for OVA and voice prompts.
  
  
• The audio codec format for voice messages, such as MP3.

Important

If you want to upgrade your existing Exchange 2007 UM environment that is connected to OCS, you need to create new UM dial plans for Exchange 2010 UM to make OCS UM-version aware. Until SP1, changing a user's dial plan means de-provisioning and re-provisioning a user from the UM system. SP1 changes that by enabling the Move Request to update the UM dial plan automatically.

Exchange 2010 SP1 will include secondary UM dial plan support, which means that you can assign two UM dial plans to your users, especially those who use two phones connected to different gateways.

Unified Messaging Servers | Planning for Unified Messaging

If you want to plan your Exchange 2010 Unified Messaging implementation, you need to consider two important factors: How many UM servers do you need, and where do you physically place your UM server roles?

Planning Amount and Hardware for UM Servers

Planning for how many Unified Messaging servers you need for your environment is logically the first question that needs to be answered before considering their configuration.

Planning the amount of UM servers depends mainly on the number of concurrent calls to the server as well as how many Voicemail Previews a CPU has to produce. These assumptions are based on an average voice mail of 50k and an average voice mail length of 30 seconds.

You can follow these guidelines for UM server planning:

• From the processor power, assume that one voice mail per core per minute can be produced. The UM role supports up to 12 cores, but because this is based on a reasonable price and performance ratio, it might rise in the future.
  
  
• Each language installed and supported on an UM server adds memory and CPU overhead because it has to rebuild the language library of words every 24 hours.
  
  
• Call answering rules do not have a measurable impact on processor power.
  
  
• Every UM server can support as many as 200 concurrent calls maximum; the default configuration is 100 concurrent calls.
  
  
• If you don't know your average concurrent callers, you can calculate that roughly 1 percent of your users produce concurrent calls at peak times. This means that if you have 5,000 UM-enabled users accessing a single UM server, they produce 50 concurrent calls during peak hours.
  
  
• You should plan to have at least two UM server roles available in your organization to provide failover capabilities.
  
  
• 8 GB memory is the recommended memory configuration for a dedicated UM server. More memory will not provide much benefit, even though UM will utilize it.

At Microsoft, three dedicated, centralized Exchange 2010 UM servers are currently available that host more than 90,000 mailboxes. 

Inside Track—Voicemail Preview and CPU Scalability

Ankur Kothari

Senior Technical Product Manager, Exchange Server, Microsoft Corporation

Scalability of the messaging role is primarily bottlenecked at the CPU. The process of taking an audio stream and determining a best-fit language model for the words spoken is primarily a processor task. We estimate that a single CPU core can handle one voice mail message per minute. An average voice mail message is roughly 25 to 30 seconds, although this can vary by industry or geography. Planning for CPU usage on this role is crucial to providing a consistent end-user experience.

UM Server Placement

If you have a small, single-site implementation of Exchange, you do not give much thought to where you physically place the UM server role. However, if you have a global implementation with several large branch offices located in different countries, you must ask yourself whether you want to place a UM server role close to the branch office's PBX or if you want to place the UM server role in the location where the mailboxes are hosted. The subsequent discussion uses the term PBX, meaning that the PBX can be connected to the UM role or already includes an IP PBX.

Let's use the Litware scenario and assume that you have mailboxes from your branch offices in Brussels and Amsterdam hosted on the Mailbox server in Berlin. You also have local PBXs available in Brussels and Amsterdam. Obviously you can place the UM server close to the PBX or close to the Mailbox server role. The following considerations will help you to make a valid decision for this situation:

• Placing the UM server close to the PBX but far from the Mailbox server improves the voice quality because the PBX to UM role is very close. The UM role might need a short delay to open a mailbox and read the items, but the voice quality when the message is played or sent is excellent. Having centralized UM servers and sending VoIP traffic over an unreliable or high-latency WAN should be considered carefully. A delay in opening messages could be acceptable for your users, but a delay in the voice traffic or bad voice quality is not. On the other hand, having the UM server close to the PBX but far from the Mailbox server also means that retrieving and playing personal greetings may not work well. Because the event of "leaving a voice mail" is more of a one-way conversation from the caller to the UM server, best practice is having the UM server near the Mailbox server.
  
  
• Placing the UM server close to the Mailbox role, but distant from the PBX might cause voice issues if you do not have a Quality of Service (QoS) network that prioritizes VoIP traffic over your WAN:
  • If you can guarantee or have sufficient network bandwidth available, it is best practice to place the server close to the Mailbox server role.
  • If you cannot guarantee network quality between the PBX and UM server role, your users might not be able to understand voice messages because of network latency or outages, which might cause user confusion.
    
    
• Security is another aspect worth considering. Most of the time voice mails are private, and it is sometimes difficult or even unsupported on a lot of PBXs to have the RTP protocol stream secured. This might be an easy target for eavesdropping.
  
  
• You can also consider adding a multi-role server to the site where the PBX is located, including the Mailbox, Client Access, Hub Transport, and UM roles to make sure all traffic is local and users get the best voice quality possible. However, carefully consider other implications, such as Domain Controller requirements, that you need to satisfy before installing a multi-role Exchange server onsite.

Note

The Microsoft recommended best practice is to place the UM server close to the Mailbox, Hub Transport, and Client Access servers. An IP PBX/IP gateway roundtrip needs to be less than 300 ms, which is higher latency than the RPC traffic between Exchange servers can tolerate and still perform well.

Exchange Unified Messaging Architecture

The Unified Messaging server role includes connections to different components, such as the Client Access or Mailbox server roles, and also to IP PBX or IP gateways, as shown in Figure 1.

 

Figure 1: Unified Messaging architecture

Generally, the UM server role communicates to an IP PBX or to a PBX using an IP gateway with the Voice over IP protocols (VoIP), Session Initiation Protocol (SIP), and Real-time Transport Protocol (RTP).

The UM server role uses MAPI protocol to communicate with Client Access and Mailbox server roles, and SMTP protocol to send voice mail messages to the destination mailbox viathe Hub Transport server. For Outlook Voice Access the UM server role accesses the mailbox using MAPI protocol to have full access to all items in the mailbox such as messages or contacts.

The Unified Messaging role no longer supports an inbound fax like Exchange 2007 UM. However, UM retains fax configuration properties, and continues to be sensitive to fax tones on calls that it answers and forwards these calls to a partner fax solution. The received fax messages look essentially the same as those created by Exchange 2007 UM, and will appear as a fax when the user is UM-enabled.

The communication to the other Exchange roles—namely the Hub Transport, the Mailbox, and Client Access Server roles—uses MAPI connections to perform tasks such as opening a mailbox for OVA or sending a voice mail message when the call has ended.

The Basics of Telephony

Because Unified Messaging must be integrated into your company's telephony solution, it's important to understand the most crucial terms and definitions to be able to follow.

Note

If your company is already connected to Office Communications Server 2007 or later with your telephone system, you don't need to consider the details in the following sections; Exchange 2010 will use OCS as the gateway.

Types of Telephone Systems

Three general types of business telephone systems can be integrated with Unified Messaging:

• Centrex Phone System Phone companies lease a Centrex phone system (also known as Central Office Telephone Exchange) to businesses. The Centrex phone system uses the phone company's central office (CO) exchange to route internal calls to an extension. A new Centrex version called IP Centrex is available. With IP Centrex, the organization does not rent phone lines from the telephone company's CO. Instead, the CO sends the phone calls through a VoIP gateway, which routes them over a VoIP gateway or through the Internet. At the organization's office, another VoIP gateway translates the call to a traditional circuit-switched call.
  
  
• Key Telephone System This phone system is similar to the Centrex system in that the organization leases several phone lines from the telephone company. However, with the Key Telephone System, each phone line connects to multiple telephones in the organization. When someone calls the company, all phones ring that are associated with that line. Businesses with Key Telephone Systems often arrange for someone to answer incoming calls, and then announce the call to the correct recipient.

  Note

  Some key telephone systems can work with UM if an IP gateway is added. However, some less sophisticated systems may not work even if a supported IP gateway is used. Make sure you contact your vendor before you try to use your key telephone system with Exchange 2010.

• Private Branch Exchange System A Private Branch Exchange (PBX) system is different from the other telephone systems in that it typically has only a single connection to the phone company and all call switching happens at the organization. The connection to the phone company usually occurs through a T1 or E1 line, both of which provide multiple channels to enable multiple calls over the same line, also called trunk lines. The PBX routes internal phone calls and those between external and internal users. In a PBX system, each user has a telephone extension. When an internal user places a call to another internal user, she uses only the extension number, and the PBX routes the call to the appropriate extension.

Types of PBX

PBX systems are the most common telephone system type that medium- and large-size organizations use. Several types of PBX systems are available:

• Analog PBX Analog PBX systems send voice and signaling information, such as the touch tones of dialed phone numbers, as actual analog sound. Analog PBX systems never digitize the sound. To direct the call, the PBX and the phone company's CO listens for the signaling information.
  
  
• Digital PBX Digital PBXs encode analog sound into a digital format. They typically encode the voice using a standard industry audio codec, G.711. After digital PBXs encode the sound, they send the digitized voice on a channel using circuit switching. The process of circuit switching establishes an end-to-end open connection, and leaves the channel open for the call's duration and for the call's users only. Some PBX manufacturers have proprietary signaling methods for call setup, such as Avaya Definity G3si PBX.
  
  
• IP PBX IP PBXs include a Network Interface Card (NIC) to provide voice over regular network. The phone converts voice into digitized packets, which it then transfers over the network. The network sends the voice packets via packet switching, a technique that enables a single network channel to handle multiple calls. The IP PBX also acts as a gateway between the internal packet-switched network and the external circuit-switched networks that phone company's use. In this situation, external phone calls arrive at the IP PBX on the normal public phone lines, and the IP PBX converts the phone call to packets sent on the internal IP-based network. An example of this is Cisco Call Manager.
  
  
• Hybrid PBX Hybrid PBXs provide both digital and IP PBX capabilities. This hybrid approach enables a customer to run a mixture of digital and IP-based phones. Most modern PBXs are in this hybrid category, such as SEN HiPath 4000.

VoIP Gateway Introduction

A VoIP gateway is a third-party hardware device or product that converts traditional phone-system or circuit-switching protocols into data-networking or packet-switched protocols. The VoIP gateway connects a telephone network with a data network.

Unified Messaging servers can connect only to packet-switched data networks. This means that organizations with a traditional PBX must deploy a VoIP gateway to communicate between the PBX and the Unified Messaging server.

Unified Messaging Protocols

There are a number of voice-related, IP-based protocols. A Unified Messaging environment with Exchange Server 2010 uses the following:

• Session Initiation Protocol (SIP) SIP is a real-time signaling protocol that creates, manipulates, and disconnects interactive communication sessions on an IP network. The UM role uses SIP mapped over Transmission Control Protocol (TCP) and supports TLS for secured SIP environments. SIP clients, such as IP/VoIP gateways and IP/PBXs, can use TCP port 5060 or port 5061 (for Secure SIP) to connect to UM server roles. You can find more information about the SIP protocol at http://tools.ietf.org/html/rfc3261.
  
  
• Real-time Transport Protocol (RTP ) RTP is for voice transport between the IP gateway and the Unified Messaging server. RTP provides high-quality, real-time, streaming voice delivery. One of the issues with sending voice messages over an IP network is that voice requires real-time transport with specific quality requirements to ensure that the voice sounds normal. If the protocol uses large packets, listeners must wait for the entire packet to arrive before they can respond. Any delay in packet delivery can produce undesirable periods of midstream silence. Packet loss can cause voice garbling. You can get more information about the RTP protocol at http://tools.ietf.org/html/rfc3550.