Exchange 2007 SP1 and OCS 2007: What You Get

 

Executive Summary: Microsoft Exchange 2007 and Office Communications Server (OCS) 2007 are complementary parts of Microsoft's UC strategy. Exchange 2007 SP1 adds Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) dial plans and E.164 dial plans to enhance this relationship. Microsoft added a three-step fax-tone detection process to Exchange 2007 SP1 to assist IP PBX systems pass inbound fax CNG tones correctly to the UM server. One key scenario enabled in Exchange 2007 SP1 with OCS 2007 is support for remote and mobile users running Microsoft Office Communicator.

Microsoft has made much of the fact that Exchange Server 2007 and Office Communications Server (OCS) 2007 are complementary parts of its overall unified communications (UC) strategy, and the enhancements that came with Exchange 2007 SP1 deepen the relationship between these two applications. Exchange provides several key pieces of call answering functionality, including the ability to build automated attendants and record and deliver voice messages to users’ Inboxes. OCS provides presence, IM, conferencing, VoIP, and integration with conventional telephone systems. Understanding how these two systems work together, and what they can and can’t do, is critical to properly planning and executing their deployment.

The Better Together Story

Exchange 2007 SP1 makes significant improvements to the interoperability between Exchange and OCS. To understand these improvements, it’s helpful to understand that both Exchange and OCS use dial plan objects in Active Directory (AD). These objects are containers that represent the physical dial plan set up on your PBX systems. The dial plan specifies how many digits make up extensions and which extensions can dial which other extensions. Exchange 2007 RTM supports only ordinary PBX-based telephone extensions as a dial plan type. Exchange 2007 SP1 adds support for two additional types:

• Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) dial plans use a SIP URI (e.g., sip:[email protected]) to represent SIP endpoints, which lets OCS handle calls to and from devices that don’t have conventional phone numbers, such as PCs using Microsoft Office Communicator.
• E.164 dial plans use the Consultative Committee for International Telegraphy and Telephony (CCITT) E.164 numbering scheme. E.164 defines the format of international phone numbers; it’s what you use to place international calls on public telephone networks. E.164 support is required for Exchange and OCS to talk to each other in topologies that include servers in different international locations. In addition, many SIP trunk providers require that all numbers transmitted over their SIP trunks be E.164-formatted.

OCS didn’t ship until nearly a year after Exchange 2007, so these SP1 changes were necessary to make the two interoperate properly. Exchange unified messaging (UM) and OCS have to have corresponding dial plan objects so that Exchange can route calls it answers to the proper endpoint, even if that endpoint doesn’t have a conventional extension number. Exchange 2007 SP1 includes several other routing-related changes. For example, the SP1 version of the UM server role can resolve caller ID numbers against extensions stored on user objects in the entire AD forest, whereas the RTM version could only resolve extensions from the same dial plan as the call recipient.

Another new feature is that calls that are forwarded from Communicator can generate a call forwarding notification. For example, say that Alice calls Bob, who used Communicator to forward his calls to Carmen. Bob gets a notification that Alice’s call was forwarded to Carmen; this notification is sent from Bob’s UM server. When Carmen’s UM server answers the call, if Alice leaves a message, Carmen gets Alice's voicemail. If Alice hangs up, Carmen gets a missed call notification. This situation makes it easier to figure out who actually takes the call when you turn on forwarding.

Integration between Exchange UM and Communicator received some boosts with SP1, too. Typically, when you dial in to Outlook Voice Access (OVA), Exchange’s voice-enabled interface for accessing calendar, contact, voicemail, and email data, you have to enter your PIN. Communicator can now place calls directly to OVA without requiring you to dial the access number, connecting without requiring users to re-enter their PIN. Communicator users thus get single-click access to voicemail and other OVA functionality from within Communicator. This feature is very useful for remote or traveling users who want access to their voicemail from Communicator; it's made possible by SP1 improvements that let media streams from outside the firewall be routed to and from Exchange UM servers.

Understanding the Pieces

Figure 1 shows a simple topology that combines OCS 2007 and Exchange 2007 with an IP PBX. Exchange and OCS each include several roles that can be combined or separated according to the scale and requirements for your deployment. For organizations that have relatively small user populations, it’s certainly feasible to use one Exchange server and one OCS server, although this configuration wouldn’t provide high availability. In the example shown in Figure 1, the Exchange UM server role is separated, as Microsoft recommends for scalability and performance. The OCS server is shown as a pool of two servers, a configuration that’s only available with the Enterprise Edition of OCS.

There are several possibilities for building topologies that combine Exchange and OCS. For our purposes, let’s assume that the PBX, not OCS, is being used as the primary backbone of the phone system, a structure that reflects the majority of existing OCS deployments. This setup requires an IP PBX that works with Exchange; if you’re not sure whether a particular PBX is supported, check the Microsoft article "IP PBX and PBX Support." A data structure stored in the PBX called a call coverage map tells the PBX which extension to send incoming calls to and what to do if a call transfer fails because the target extension is busy or unanswered. Here are a few of the possible scenarios:

• Exchange could act as the primary answering point for incoming calls from the outside world. In this case, when the incoming call arrives, the PBX transfers it to the UM server, which runs the specified Exchange UM automated attendant. If the caller does something that requires a call transfer, such as requesting a particular user, the UM server transfers the call back to the PBX, which then rings the specified extension.
• The PBX could route the call directly to the target extension. This setup is normally the case for sites that use Direct Inward Dialing (DID), a configuration where each extension has its own externally accessible number. In this case, if the target extension isn't answered or is busy, the PBX sends the call back to the Exchange UM server, which answers it and allows the caller to leave a message. If the caller leaves a message, Exchange UM sends it to a Hub Transport server for delivery to the user’s mailbox. If the caller hangs up before leaving a message, the user instead gets a missed call notification message.
• The PBX might route the call directly to the target extension, at which point the user could choose to take action. For example, a user could tell Communicator to send the call to another number. When this happens, OCS redirects the call to the specified number; this redirection might involve the PBX, depending on the number to which the call is forwarded. Using Communicator to activate call forwarding has the same effect. When OCS forwards the call, it generates a call forwarding notification that goes to the extension owner’s Exchange mailbox.

Interestingly, it doesn’t matter much what kind of endpoint the call is routed to. The caller never has to know whether the call recipient is using Communicator, an OCS-compatible phone, or a conventional desk phone.

Fax Handling

Exchange 2007 SP1 doesn’t make major changes to the way calls are placed and received, primarily because it doesn’t have much to do with those functions in the first place. One exception is in the area of inbound fax handling. Exchange 2007 RTM supports inbound fax calls using the CCITT T.38 fax protocol, which requires the UM server to recognize the distinctive T.38 fax signal tones, known as CNG tones. However, not all IP PBX systems pass CNG tones correctly to the UM server. To fix this problem, Microsoft added a three-step fax-tone detection process:

1. If the IP gateway or PBX detects a fax tone, a T.38 request is sent to the UM server, which accepts it and receives the fax.
2. If the IP gateway or PBX can't detect the fax tone, it can send CNG tones as telephony events without using T.38. The UM server accepts these events, then sends a T.38 request to the gateway and accepts the call.
3. If you turn on in-band fax tone detection by using the EnableInbandFaxDetection setting in the Exchange global configuration file, the Exchange UM server listens for CNG tones on its own and accepts any fax calls that it hears.

Even with this three-step process, some IP gateway systems still don’t work properly. For example, Cisco Unified Communications Manager 6.x and 5.x are supported and work normally for voice calls, but they don’t support fax-tone detection with Exchange UM.

Another wrinkle with fax reception concerns deployments that use OCS as the IP PBX. Let’s say Alice is a user whose account is enabled for both OCS enterprise voice and for UM. Alice’s extension can’t be used for inbound fax because the OCS 2007 mediation server doesn’t support T.38. Voice calls can be passed to Exchange UM for usual actions, but fax calls can't. This limitation means that Alice needs a separate extension to receive faxes, which you can add as a secondary UM extension with an associated secondary dial plan.

Presence, IM, and Conferencing

In addition to handling telephone calls (or not, depending on the topology in use), OCS 2007 can be used to deliver three other very useful features:

• Presence indicates how willing and available a person is to communicate. For example, someone whose presence status appears as Away might be willing, but they’re unavailable. Someone with a presence status of Do Not Disturb is neither willing nor available. OCS supports multiple points of presence, meaning that you can be simultaneously signed in at multiple endpoints. OCS and the endpoints themselves combine to figure out what the appropriate presence state is, and to publish it to all the devices you’re signed in on. OCS supports a very rich presence model, which you can customize to reflect presence states, such as In the Field or On Assignment, specific to your organization.
• IM lets you exchange text messages and files with other users. OCS provides an array of archiving, monitoring, and policy-control features for this type of communication.
• OCS conferencing is actually two things: Web conferencing, which provides tools for hosting your own meetings using the Microsoft Office Live Meeting client so that you don’t need to use an external service; and voice or video conferences, which you can conduct with two or more participants from inside Communicator or Microsoft Messenger for Mac.

Exchange has nothing to do with these features; Outlook, Entourage, and the Communicator family of clients provide these services to the end user. However, these features make use of data stored in Exchange. For example, Communicator automatically sets your presence state to In a Meeting during times when you have meetings scheduled on your Exchange calendar, and all of these clients display your Exchange out-of-office message to users who have you in their contact list.

The Role of the Gateway

You might have noticed the lack of discussion of two OCS components: gateways (which route SIP traffic to and from your PBX) and mediation servers (which interconnect OCS to the gateway). Depending on the kind of PBX you have, you might not need a gateway. For example, the IP PBX in my basement lab can connect directly to Exchange 2007 UM servers, so I don't need an additional gateway for UM functionality. However, if you want OCS to handle calls, you’ll need to add an OCS mediation server. If you’re using SIP trunks, you might not need an additional gateway; however, if your OCS server will receive or place calls on standard Public Switched Telephone Network (PSTN) lines, you’ll need a gateway that can handle such traffic. Gateway selection and configuration, while fascinating, are best saved for a separate article; in the meantime, you can check out the Microsoft Unified Communications Open Interoperability Program page on Microsoft’s website for a list of supported gateways.

Firewall Traversal

One key scenario enabled in Exchange 2007 SP1 with OCS 2007 is support for remote and mobile users running Communicator. Communicator already uses TCP on port 443 for secure outside access to OCS services, but some additional steps are required to provide one-button authenticated access to voicemail. The basic process works like this:

1. Communicator makes a DNS SRV record query to find the correct access edge proxy for the target domain. This proxy is a server that sits in the perimeter network and handles communication requests from clients outside the firewall.
2. Communicator authenticates itself to the access edge proxy, which sends the authentication request to OCS and returns the resulting registration and presence data to Communicator. As part of this exchange, Communicator receives a Globally Routable User Agent URI (GRUU). Think of the GRUU as a globally unique identifier (GUID): It uniquely identifies a SIP service, in this case the A/V authentication service that OCS uses for client authentication.
3. Communicator sends SIP service requests to OCS, which in turn sends them on to the A/V authentication service. If this authentication succeeds, Communicator is assigned a port range on the A/V edge server’s public IP address. At this point, Communicator has an authenticated and usable SIP signaling channel.
4. Communicator starts a SIP session with the Exchange UM server. (This would be the first step in an inside-the-firewall call from Communicator to a user’s voicemail box).
5. The UM server authenticates itself by sending SIP service requests to the A/V edge server’s private IP address. When the authentication succeeds, the UM server gets its own port on the A/V edge server; this port is associated with the server’s public IP address.
6. The UM server answers the call that Communicator placed in step 4.
7. Audio passes between the UM server and Communicator over the ports set up in steps 3 and 5. The A/V edge server acts as a conduit to let Real Time Protocol (RTP) audio flow between the UM server and Communicator.

This process is complicated, but it’s necessary to handle the many edge scenarios that can occur. For example, one or both endpoints could be using a Network Address Translation (NAT) device, in which case the endpoint might use a protocol such as Interactive Connectivity Establishment (ICE) or Traversal Using Relay NAT (TURN), both currently Internet Engineering Task Force (IETF) drafts, to figure out how to reach the correct IP address and port combination for the server.

Putting It All Together

OCS 2007 and Exchange 2007 SP1 work together to provide a broad set of UC features. You should now have a good idea of what some of these features are, how they’re delivered, and how they work. The next question you might have is how you configure your UC environment with these tools and what administration challenges they present. Those are topics I plan to cover in future articles.