The components that compose a VoIP topology are illustrated in Figure 11-15. This topology supports the following scenarios: calling and receiving calls outside your organization’s network (PSTN), providing external access for users, and receiving voice mail. New server roles come into play when deploying an Enterprise Voice infrastructure. In addition to the basic Office Communications Server home pool, which is either an Office Communications Server 2007 R2 Standard Edition Server or an Enterprise Edition pool, the following server roles are required or recommended.
Figure 11-15. Enterprise Voice topology. Note that the lines connecting the different server roles represent protocol traffic and do not necessarily represent the number of NICs the server must be configured with.
The elements specific to the VoIP topology that are in addition to a deployment of Office Communications Server for IM, presence, and conferencing are described in the following list.
Media gateway. This is a third-party server solution offered by Microsoft partners.
Mediation Server. Depending on the type of media gateway used, this Office Communications Server role is required.
A/V Edge Server. This Office Communications Server role is required to enable audio traffic to traverse the corporate firewall for users who are connecting from the Internet.
Access Edge Server. If you are giving users remote access to place and receive calls from outside the corporate firewall, the Access Edge Server must be deployed in addition to deploying an A/V Edge Server. Depending on capacity requirements, it is possible to collocate both the Access Edge Server role and the A/V Edge Server role on the same physical server.
Exchange Unified Messaging (UM). This Exchange Server role is required to enable Exchange Server to serve as the voice mail system for Office Communications Server. Exchange UM is also used to provide auto-attendant and call notification service.
Monitoring Server. This Office Communications Server role is recommended to collect Call Detail Records (CDRs) for monitoring Quality of Experience (QoE) of calls.
Devices. These are VoIP endpoints that are capable of terminating a voice call. This includes Session Initiation Protocol (SIP)–enabled hardware phones as well as soft-phones such as Office Communicator 2007 R2.
To place calls to and receive calls from outside your organization’s network, a third-party media gateway is required. The gateway’s purpose is to bridge the PSTN network and your corporate IP network. Depending on the type of media gateway used, you might need to deploy an Office Communications Server 2007 R2 Mediation Server to interoperate with the media gateway that your vendor provides. The Mediation Server performs codec translation between RTAudio and legacy codecs. Real-Time Audio (RTAudio) is an advanced audio codec used by Office Communications Server. It has been tried and tested in Microsoft Windows Live Messenger, which serves in excess of 1 billion voice minutes per month using RTAudio, to provide optimal audio quality over the Internet. Because most media gateways support only SIP over User Datagram Protocol (UDP), the Mediation Server converts SIP over the Transport Layer Security (TLS) used by Office Communications Server to SIP over UDP. There is a one-to-one mapping between the gateway and Mediation Server, because the gateway must be configured to route all incoming calls to the Mediation Server. The Mediation Server also acts like a client for Interactive Connectivity Establishment (ICE), which enables users connected from outside the enterprise firewall to make calls to and receive calls from the PSTN network.
To provide users external access, enabling them to dial and receive calls when connected from outside their corporate network, the following server roles are necessary: Access Edge Server and A/V Edge Server. These server roles must be deployed in the perimeter network.
For voice mail capability, the Exchange Server 2007 Unified Messaging (UM) server role is required. In addition to Exchange UM Servers, Exchange Mailbox Servers are required as well to store the voice mail. More details about voice mail connectivity with Exchange UM are presented in Chapter 12.
Finally, VoIP-enabled devices that support the SIP protocol with Microsoft’s extensions for signaling and the Real-Time Protocol (RTP) for audio media are needed to terminate the calls. Microsoft’s primary softphone client is Office Communicator 2007 R2; however, Microsoft as well as third-party partners provide a variety of hardphone and softphone options.
As with any telecommunication solution, Office Communications Server 2007 R2 Enterprise Voice must perform the following activities:
Outbound routing. Route calls from the organization running Office Communications Server Enterprise Voice to the PSTN
Inbound routing. Route calls from the PSTN to the organization’s Office Communications Server Enterprise Voice system
These routing activities are enforced by the front-end service in both the Standard Edition Server and Enterprise Edition pool as an integral part of Office Communications Server.
Outbound routing of VoIP traffic in Office Communications Server 2007 R2 is managed by the Outbound Routing component on the front-end server. When a user places a call, the client first attempts to normalize the dialed phone number. It then sends the request to the user’s home pool. Based on the permissions allowed in the Voice policy that is assigned to the user, the home pool determines where to route the call. The call (SIP INVITE) is routed to a Mediation Server. The audio media for the call is routed directly from the client to the Mediation Server. The Mediation Server forwards the call to the media gateway. The media gateway bridges the call to the PSTN. Figure 11-16 illustrates this process. Each of the elements—users, policies, usages, routes, and gateways—is represented as an object in Active Directory and is exposed as a Windows Management Instrumentation (WMI) class at the management Application Programming Interface (API) layer.
Figure 11-17 illustrates the logic flow performed by the user’s home server.
Every user enabled for Enterprise Voice is associated by the administrator to a Voice policy. A Voice policy defines the call privileges assigned to a user. The call privileges determine which routes the user is allowed to use. Each user must be associated to a single Voice policy. The administrator creates the number of available policies.
Each Voice policy contains a setting to allow or disallow users to enable simultaneous ringing and a collection of ordered phone usages. The Voice policy, similar to the Meeting policy, is a logical container of settings defined as an XML document stored in Active Directory. The value of this design is that it can be extended in future versions of Office Communications Server to support additional policy settings without requiring an Active Directory schema extension. For example, a Voice policy not associated with any phone usages has the effect of preventing users assigned to that policy from making any outbound calls to the PSTN. Such users would be able to dial only internal numbers.
A phone usage defines the phone routing privileges users are allowed. A phone usage is a collection of phone routes. It is a string that must be a unique keyword, meaning no other phone usage can have the same name. The administrator can create as many usages as she wants. Although a Voice policy can be directly associated with a route or a set of routes instead of phone usages, the phone usage keyword is an abstraction used to maintain the association between policies and routes. If policies were directly associated to routes (effectively removing the concept of phone usages) and the administrator modified the name of a route, every policy associated with that route would need to be updated. By using a phone usage, which is an attribute of both a policy and a route, to create the association between the policy and the route, the relationship between the policy and route is preserved even if the route’s name is changed.
A phone route defines how to route a call specified by a phone number to one or more Mediation Servers. The Mediation Server must be configured to route to a specific media gateway. The media gateway then either routes the call directly to the PSTN or it routes the call to an IP-PBX before reaching the PSTN. A route contains a phone number pattern and a list of gateways. This list of gateways includes Mediation Servers if using either basic media gateways or advanced and hybrid media gateways. A route must be assigned to at least one phone usage. This association between the pattern and gateways specifies how to route phone numbers that match that particular pattern.
The pattern specifies a range of phone numbers that it can match. It is defined as a regular expression (regex) that can include and exclude phone numbers. To help build these regular expressions more easily, use the Enterprise Voice Route Helper tool. If the phone number dialed matches the route’s regex pattern, the call is routed to one of the gateways defined in the route.
More than one gateway can be listed in the phone route. Office Communications Server routes calls to the gateways in a round-robin fashion as a way to balance the traffic across the gateways. If a gateway fails or is taken out of service for maintenance, Office Communications Server immediately attempts to route the call to another gateway in the route’s list. After 10 attempts to route calls to a failed gateway, Office Communications Server subsequently throttles traffic to that gateway until it becomes responsive again. If the gateway continues to fail to respond after an additional 10 attempts, Office Communications Server stops routing calls to that gateway entirely until it becomes responsive.
The list of gateways defined in the route is described by the gateway’s fully qualified domain name (FQDN) and the port number that the gateway is listening on. If the phone number does not match the regex pattern, the next route associated with the policy assigned to the user is checked until a match is found. If no match is found, the call cannot be routed and fails to reach its destination. The user receives a notification that the call could not be completed.
Let’s examine how Office Communications Server 2007 R2 routes a call originating from the PSTN network to a user in your corporate network. Figure 11-18 illustrates this logic.
Note
Inbound calls can originate from another internal user or from a federated partner over a federated link. Before routing the call to a media gateway, Office Communications Server checks whether the phone number matches an internal user’s number. If the phone number matches an internal user’s number, the TEL URI (Uniform Resource Identifier) is replaced by the internal user’s SIP URI and routed to that user.
When an outside call originating from the PSTN arrives for a user within your organization, the handoff between the two networks occurs at one of the organization’s media gateways. If a basic media gateway or basic hybrid media gateway is used, the gateway sends the call to the Mediation Server to which it is configured to route. The Mediation Server routes the signal to the Director it is configured to route to. The Director performs a reverse number lookup (RNL) to determine which user owns the called phone number, referred to as the TEL URI.
The assignment of the phone number to the user is configured in the msRTCSIP-Line attribute of the user’s object in Active Directory. If a match is not found, the Director cannot route the request and the call fails. Once a match is found, the TEL URI (for example, +14255551212) is translated into the user’s SIP URI (for example, sip:[email protected]). The Mediation Server then determines the FQDN of the user’s home pool and routes the SIP request. The SIP INVITE request is sent to the user’s home pool. The home pool performs additional logic. It applies any call-forwarding rules the user might have set. For example, if the called party is set to simultaneously ring another phone number, Office Communications Server routes the call to the new number in addition to forking the call to all the registered endpoints the called party is signed in to. It drops the call if the user sets his presence to Do Not Disturb. The only exception to this rule is if the caller is a contact in the called party’s Personal or Team access level. Then the call notification will be displayed. If the called party answers the call, the audio is routed directly from the Mediation Server to the user’s client.
If the called party is not signed in to Office Communications Server, the home pool determines that there are no active endpoints and instead of forking the incoming call to the user’s endpoints, it directly routes the call to the user’s voice mail server, Exchange Server 2007 Unified Messaging (UM). The user does not need to be signed in to Office Communications Server for voice mail to work. The called party can retrieve his messages once he opens Outlook and connects to his Exchange mailbox.
Although the concepts described so far make inbound and outbound calling possible, there are two limitations that must be addressed. First, this routing design works well if there is only a single way to represent a phone number. However, this is not always the case. Because the phone number is represented as a string, there are multiple ways to specify the same phone number. For example, the phone number (425) 555-1212 can be represented in the following ways:
(425) 555-1212
425-555-1212
+14255551212
0014255551212
425.555.1212
555-1212 (this assumes the area code 425)
5551212
555.1212
51212 (if the number is an internal extension)
(425) 555-1212 x51212
Although this list is not comprehensive, it demonstrates that the same phone number can be represented as a string in a variety of ways. It’s unlikely that the regex pattern defined in the route will be able to match all these variations. For the pattern-matching of the route to work, some form of normalization is necessary. This is the first problem.
Because there are multiple ways to address this issue, the International Telecommunication Union-Telecom (ITU-T) Standardization Committee created the E.164 recommendation. The E.164 recommendation defines the international public telecommunication numbering plan, which specifies a methodology that provides a standardized method for presenting the domestic numbering plans of all countries.
A second problem is that some of the phone number variations are ambiguous. For example, the 555-1212 string assumes a local area. If the user were to dial this number in Redmond, Washington, the area code that should be assumed is 425; however, if the user were to dial this same number in Seattle, Washington, the area code that should be used is 206. To correctly normalize a phone number into E.164 format, a context is necessary to correctly interpret it based on the user’s locale.
To address these two problems, Office Communications Server 2007 R2 exposes the following concepts:
Normalization rules. Normalization rules define a match pattern and a translation pattern. Both patterns are represented as regex rules that describe how to translate a given phone number into a well-formatted number in E.164 format. Translating all numbers to E.164 format simplifies the regex defined in the route to match only phone numbers that have already been normalized by the normalization rules.
Location profiles. A location profile is a collection of normalization rules. The location profile defines the collection of rules to apply for a particular region. A region can be a state, province, country, or city that has specific dialing rules. For example, if the user is dialing from Redmond, Washington, the normalization rules for that area code are applied to any phone number the user dials. So if the Redmond user enters, say, an eight-digit number, Office Communications Server 2007 R2, following a rule in the Redmond location profile, adds the area code 425 when the number is dialed.
The roles these components play in the routing logic of voice communications is illustrated in the Phone Normalization Logic dotted-line box in Figure 11-16. Location profiles and normalization rules are both defined by the administrator in charge of an organization’s telephony infrastructure.
Each user is assigned a location profile, and upon dialing a phone number, the ordered list of normalization rules associated with the user’s location profile is applied. If a first match to a normalization rule is found, the client translates the phone number into E.164 format before the SIP request is sent to the user’s home pool. If a match is not found, the phone number is still sent to the user’s home pool, but it is tagged as a dial string because it could not be normalized. The dial string that the client sends to Office Communications Server includes a phone-context attribute that specifies the name of the user’s location profile. The server attempts to resolve the phone number by using the specified location profile normalization rules.
Note
Office Communications Server 2007 R2 enables administrators to assign specific location profiles to users. Thus, users located in different regions can be homed on the same pool without having to share the same location profile. This is a new feature in Office Communications Server 2007 R2.
For example, INVITE SIP:5551212;[email protected] is an example of a dial string. The non-normalized phone number is 5551212, and the specified location profile is Redmond.
Office Communications Server 2007 R2 Enterprise Voice enables users to make and receive calls anywhere Internet access is available. They simply sign in to Office Communications Server and place calls as usual. Regardless of their geographic location, users’ dialing patterns can remain the same as long as they are using the same location profile. If the administrator changes the location profile to a different profile, the dialing patterns might change. Office Communications Server uses in-band provisioning to push the normalization rules associated with the location profile assigned to the user. If the user is not assigned a location profile by the administrator, the user is assigned a default location profile. This is the default location profile assigned to the user’s home pool configured by the administrator.
Office Communicator caches these normalization rules and is responsible for applying them when a user dials phone numbers. Office Communicator also applies the normalization rules to Outlook contact phone numbers when Office Communicator starts and adds these numbers to its local search cache. This allows Office Communicator to perform fast reverse name lookup on Outlook contacts when a call comes in. As a result, no matter what their locations might be, Enterprise Voice users are always calling from home.
For example, if the user dials the number 555-1212, the client runs through the normalization rules it got from the user’s home pool. If one of the rules matches, the phone number is normalized. The request is sent to the user’s home pool with the normalized phone number. The home pool checks whether the phone number matches any internal user’s phone number. If it matches an internal user, the phone number is replaced by the user’s SIP URI and is routed to that user’s home pool. If a match to an internal user is not found, the home pool performs a route-matching analysis. Once a match is found, the request is routed to one of the gateways listed in the route. The client then sends the audio media directly to the gateway.
So far we have discussed normalization rules associated with location profiles, which are used dynamically at runtime when calls are placed. Office Communications Server also has Address Book Service (ABS)–based normalization rules, which are used to clean up the phone number entries in the Global Address List (GAL) before calls are made. The purpose of these rules is to ensure that existing phone numbers in Active Directory are normalized to an E.164 format so that these numbers can be added to the translation database for inbound routing.
Numbers normalized using the ABS normalization rules are also present in the Global Address Book (GAL) database that clients download from the Address Book Service. The client uses this information to perform reverse name lookup for calls coming in from contacts within the same enterprise. This provides the Caller ID feature in Office Communicator.
Before we go into more detail about VoIP configuration, let us take a brief look at how Office Communicator 2007 R2 and Office Communicator 2007 R2 Phone Edition can work together to provide an even richer experience. Both Office Communicator and Office Communicator Phone Edition communicate with each other through a persistent SIP session they establish through Office Communications Server.
To enable Office Communicator to Office Communicator Phone Edition integration, a USB cable connection is required. When Office Communicator starts, it detects whether there is an Office Communicator Phone Edition device attached to the USB channel. It initiates a persistent SIP INVITE session over the IP network through Office Communications Server. Similar to the Computer-Supported Telepathy Applications (CSTA) protocol that is used for Remote Call Control to a PBX phone (see Chapter 9), Office Communicator uses the persistent INVITE session to send SIP INFO messages containing a payload of Third-Party Control Protocol (TPCP) commands to Office Communicator Phone Edition such as placing a call, answering a call, and so on. In the reverse direction, Office Communicator Phone Edition sends notifications using INFO messages that contain the TPCP protocol payload.
TPCP is a Microsoft protocol that is used in other scenarios as well, such as when a third-party server is required to make connections between two endpoints. An example of the use of TPCP is with Communicator Mobile. Whenever a user selects to call from Communicator Mobile, a TPCP message is sent to the Office Communications Server within the user’s enterprise. The Office Communications Server originates an outgoing PSTN call through the cellular network to the user’s cell phone. It also sends an INVITE to the destination phone number and then connects the two calls together.
One of the key aspects of this integration design is how the audio and video media are terminated. Because Office Communicator Phone Edition does not support video media, any video calls must be terminated on Office Communicator, and the audio is streamed from Office Communicator to Office Communicator Phone Edition over the USB channel. Whenever video is added to an existing audio call, Office Communicator will become the endpoint from which both the audio and video media channels flow and will stream the received audio media of the call to Office Communicator Phone Edition over the USB link.
Figure 11-19 and Figure 11-20 illustrate the two modes in which Office Communicator and Office Communicator Phone Edition can interact when connected over a USB cable.
In Figure 11-19, an audio call is made from the Office Communicator desktop client. Office Communicator sends the command to set up the audio call to Office Communicator Phone Edition over the TPCP protocol. Communicator Phone Edition originates an INVITE to the remote party, which in this case also has a paired configuration. When the callee’s Office Communicator Phone Edition receives the INVITE, it informs Office Communicator about the incoming call through the TPCP protocol. When the callee answers the call from Office Communicator, a TPCP command is sent to Office Communicator Phone Edition to answer the INVITE with a 200 OK.
In Figure 11-20, a video call was made from the Office Communicator client. In this case, Office Communicator sends the audio/video INVITE directly to the callee because only Office Communicator has the ability to consume video RTP media. The audio portion of the call is now streamed to Office Communicator Phone Edition through the USB interface. This enables using the speakerphone capabilities of Office Communicator Phone Edition. On the receiving end of the call, when the callee answers the video INVITE in Office Communicator, the audio/video RTP media are consumed on Office Communicator and the audio media is streamed to Office Communicator Phone Edition speakerphone through the USB link.