The components that compose a VoIP topology are illustrated in Figure 10-18. 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 Standard Edition Server or an Enterprise Edition pool, the following server roles are required or recommended.
The elements of the VoIP topology 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 allow 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 also 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 Microsoft 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 softphones such as Office Communicator 2007.
To place calls to and receive calls from outside your organization 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, Mediation Server to interoperate with the media gateway provided by your vendor. The Mediation Server performs codecs translation between RTAudio and legacy codecs. The following legacy codecs are supported: G.711, G.722.1/SIREN, G.723.1, G.726, and GSM. G.729 is not supported in Office Communications Server 2007. RTAudio is an advanced audio codec used by Office Communications Server. It has been tried and tested in Windows Live Messenger, which serves in excess of one 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, as the gateway must be configured to route all incoming calls to the Mediation Server.
To provide users external access, where users can 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 Microsoft 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. Office Communications Server 2007 servers connect to the Exchange UM Servers by means of the SIP protocol instead of with MAPI or other protocols. This gives Exchange UM Servers the advantage of being able to scale well in capacity without introducing a lot of hardware. Because SIP is a standard protocol, a second advantage is the potential for third-party vendors of voice mail systems to interoperate with Office Communications Server 2007 servers as an alternative solution. Exchange UM Servers integrate a managed code (.NET) SIP stack that is available as a software development kit (SDK) called Microsoft Unified Communications Managed API SDK, which independent software vendors can take advantage of.
Finally, VoIP-enabled devices that support the SIP protocol with Microsoft's extensions for signaling and the Real-Time Protocol (RTP) for audio are needed to terminate the calls. Microsoft's primary softphone client is Office Communicator 2007; 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 Enterprise Voice must perform the following activities:
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 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 request) is routed to a Mediation Server. The audio portion of the call is routed directly from the client to the Mediation Server. The Mediation Server forwards the call and audio to the media gateway. The media gateway bridges the call to the PSTN. Figure 10-19 illustrates this process, and Figure 10-20 shows the call flow logic. 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 10-20 shows another way to visualize the call flow logic.
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 number of policies available is created by the administrator.
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, if a Voice policy is not associated with any phone usages, this 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 routes a call originating from the PSTN network to a user in your corporate network. Figure 10-21 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 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 to. 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 [email protected]). The Mediation Server then determines the FQDN of the user's home pool and routes the SIP request. The SIP 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.
In the case that 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 Microsoft 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. This is not 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:
Although this list is not comprehensive, it demonstrates that the same phone number can be represented as a string in a 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. This is the second problem.
To address these two problems, Office Communications Server 2007 exposes the following concepts:
Normalization Rules Normalization rules define a match pattern and a translation pattern. Both patterns are represented as regular expression 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, Communications Server 2007, 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 10-19 previously. 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 are 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.
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 Enterprise Voice enables users to make and receive calls anywhere Internet access is available. They simply sign in to 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 or the user 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 does not select a location profile (Office Communicator Phone Edition) or is not assigned a location profile by the administrator (Office Communicator 2007), 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. The administrator can assign a location profile to Office Communicator 2007 users who are using group policy.
Communicator caches these normalization rules and is responsible for applying them when a user dials phone numbers. 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 portion of the call directly to the gateway.
Now that you have a better understanding of the VoIP design of Office Communications Server 2007, this section jumps into the details of configuring VoIP by using the Admin Tools Microsoft Management Console (MMC). The Office Communications Server 2007 Resource Kit also provides useful tools. In particular, the Resource Kit tool Enterprise Voice Route Helper has several advantages currently not available in the Admin Tools MMC.
Another advantage of Enterprise Voice Route Helper is the ability to simulate the behavior of the system when a particular phone number is dialed. The route taken will be highlighted. Once the administrator is satisfied with her voice configuration, the Route Helper tool can apply the new configuration to Active Directory while maintaining a tracking history of the configurations applied to Active Directory.
The global Enterprise Voice settings can be configured only by administrators who are members of the RTCUniversalGlobalWriteGroup or RTCUniversalServerAdmins groups. Administrator members of the RTCUniversalGlobalReadOnlyGroup group can view the global settings, but they cannot modify them. Inbound routing rules (simultaneous ringing, call forwarding, and so on) are configured by the user.
The administrator can create as many Voice policies as desired regardless of whether they are used or not. To create a Voice policy by using the Admin Tools MMC, select the Voice Properties from the forest node, and click the Policy tab. The Policy tab allows administrators to manage their Voice policies. (See Figure 10-22.) Out of the box, a default policy is defined. The administrator can assign all users the same Voice policy or allow users to be assigned a different Voice policy by selecting the Use Per User Policy option from the drop-down list for the Global Policy setting.
Because Voice policies are associated with phone usages, the administrator also needs to create phone usages to represent routing restrictions. To create a phone usage, navigate to the Phone Usages tab (shown in Figure 10-23). A phone usage consists of a keyword and a description that is used purely for the benefit of the administrator to describe what that phone usage is used for. Out of the box, a default phone usage is defined.
Given the two geographic locations with their own egress to the PSTN in our example, the administrator responsible for this Office Communications Server 2007 deployment defined two Voice policies with associated usages for each office.
A phone route assigns defined sets of phone numbers to various media gateways. Consequently, a phone route consists of a name for the route, a description that the administrator creates, a target set of phone numbers expressed in the form of a regular expression (regex), a list of gateways to route phone numbers that match the target regex pattern, and a list of usages. (See Figure 10-24.)
The phone usage ties the phone route to the Voice policy (shown earlier in Figure 10-22). Therefore, only users assigned a Voice policy that specifies the same phone usage associated with a phone route can use that route. The list of gateways is specified by its FQDN and the port number to connect to. This FQDN can be the fully qualified name of an advanced media gateway or the fully qualified name of a Mediation Server if you are using a basic media gateway.
Specifying a target regular expression can be a little daunting at first when using the Admin Tools MMC. The Enterprise Voice Route Helper tool provides more assistance in defining phone routes. The user interface simplifies the creation of regular expressions. It automatically translates the regular expressions into plain English in the description field of the route. This makes it easier to understand the meaning of the regular expression. In addition, the Enterprise Voice Route Helper tool offers the ability to test the regular expression before saving it. Figure 10-25 shows the same route defined in Figure 10-24, this time using the Enterprise Voice Route Helper. To view the syntax of the regular expression, click on the Raw tab.
Another valuable feature of this tool is the ability to test which route(s) are triggered for a given phone number. This feature is particularly useful because it allows administrators to quickly test phone routes. Administrators can simulate the scenario of a user dialing a phone number and see how the call gets routed without applying the phone route in production (that is, in Active Directory). The route that matches is highlighted. The tool even simulates the phone number normalization performed by the client when the user's location profile is specified. This feature is available on the Ad-hoc Test tab.
A location profile is a container that holds a name, a description, and a list of normalization rules. Future versions of Office Communications Server can extend the location profile to include additional attributes. The normalization rules associated with a location profile define the dialing patterns for a specific region (location). For example, if the user dials 555-1212, what area code should the system assume? If the user has a location profile with a normalization rule that converts all seven-digit numbers into eleven-digit numbers assuming a country of 1 and an area code of 425, the phone number will be translated to +14255551212. But if a user has a location profile with a normalization rule that adds +1213 to all seven-digit numbers, the phone number will be translated to +12135551212.
Each normalization rule consists of two regular expressions. The first regex is the matching pattern; the second regex is the translation expression. When the user dials a phone number, the client (Office Communicator 2007) immediately runs through the ordered list of normalization rules for the location profile it obtained from the user's home pool. The phone number is translated upon finding the first match.
To manage your location profiles, open the Voice properties at the Active Directory forest node, and select the Location Profiles tab (shown in Figure 10-26). Embedded within this tab is the UI to create/edit normalization rules.
The Enterprise Voice Route Helper provides a slightly different user interface, with additional features such as assistance in creating regular expressions, seeing which normalization rules are matched as the user types a phone number, and automatically creating or updating the description of the normalization rule.
A default location profile can be assigned to pools. (See Figure 10-27.) Users inherit the location profile of their home pool if the administrator hasn't assigned a location profile to the user through group policy. If the user is using Office Communicator 2007, the client obtains the user's location profile from his home pool through in-band provisioning. If the user is using Office Communicator Phone Edition, he can select from the list of location profiles available, and the device will obtain the selected location profile from the home pool.
In addition, each Mediation Server is assigned a location profile (as shown in Figure 10-28) because an incoming call from the PSTN might list a phone number that is ambiguous to Office Communications Server. The location profile assigned to the Mediation Server is used to help disambiguate the target phone number.
