Migration strategy

There are two main aspects that need to be considered when deploying Office Communications Server 2007 R2 and migrating users from a TDM PBX to Office Communications Server 2007 R2 at the same time.

The first is that the Office Communications Server 2007 R2 architecture design session needs to define which Office Communications Server 2007 R2 roles need to be deployed in order to serve the customer’s needs and also where to place these servers.

Because of the migration from the TDM PBX to Office Communications Server 2007 R2, the design session must also develop an inventory list of the TDM PBX. This inventory is used to determine which and how many devices and which users will benefit from the migration. This information is combined with existing telephony feature sets to help decide whether current business workflows will be negatively impacted after the migration. The result of this exercise is deciding how many endpoints can be migrated to Office Communications Server 2007 R2 and what to do with the rest of the remaining endpoints.

Planning the Office Communications Server 2007 R2 Architecture

As stated in the introduction of this document, the main focus of this document is the voice deployment and its configuration. For planning of the Office Communications Server 2007 R2 base infrastructure, the Planning Tool for Office Communications Server 2007 R2 was used. The Planning Tool provides deployment guidance about which Office Communications Server 2007 R2 server roles need to be deployed based on locations, deployed workloads and user numbers. The Planning Tool is available for download at http://go.microsoft.com/fwlink/?LinkId=158266 . The result of this planning exercise can be seen in the following Figure:

Figure: Litware Enterprise Voice Architecture

As part of planning for Enterprise Voice, we strongly recommend that you conduct a network analysis in order to ensure that the network will be able to handle expected media traffic.

For didactic reasons we have not yet stated the physical and logical network connections for the media gateways. This will be part of the voice design session. The Office Communications Server 2007 R2 deployment depicted in this walkthrough is intentionally simplified in order to focus on the voice design features.

Voice design session

In planning your Enterprise Voice deployment, you will perform the following tasks:

  1. Create an inventory of devices and trunks that are connected to each PBX and their location.

  2. Compare mandatory user and administrative features between the PBX and Office Communications Server 2007 R2.

  3. Plan for user migration.

  4. Determine user dialing habits.

  5. Structure dialing authorization in order to control the types of calls that individual users can make.

  6. Create a configuration plan for least cost routing of international phone calls.

  7. Plan integration with the Exchange 2007 SP1 Unified Messaging dial plan.

Inventory PBX Devices

For each PBX that is going to be affected by the Office Communications Server 2007 R2 voice deployment, you will need to create an inventory of each extension, its location, and what devices are connected to it. .

Table Device Inventory

Extension Device Location Migrate to Office Communications Server?

100

Analog Group 3 fax

Level 0

No

105

Wall-mounted analog phone

Level 1 lobby

No

205

Standard user phone

Level 2

Yes

206

Boss phone

Level 2

Yes

207

Admin phone

Level 2

Yes

The inventory should also list currently used, as well as available but unused, trunk connections that factor into the migration strategy.

Amount Trunks

2

T1 PRI connections to PSTN

1

T1 PRI connection port unused

The tables above show an example of such an inventory list for the Redmond site. A similar exercise would also be performed for the German site.

Feature comparison

In order to take full advantage of an Office Communications Server 2007 R2 Enterprise Voice deployment, your users should have standard office workspaces with Microsoft Outlook connected to Microsoft Exchange. These users will receive enhanced benefits from the unified communication functionality that is provided by the integration of Office Communications Server 2007 R2 and Exchange 2007 Unified Messaging.

It is important to identify the main telephony features that a standard office user needs for his or her daily work. These needs should be compared against the current feature set of Office Communications Server 2007 R2 in order to determine if the user will be negatively affected in her daily work by eventually missing features after the migration to Office Communications Server 2007 R2.

One thing that should be kept in mind is that some telephony features might become obsolete after the migration to Office Communications Server 2007 R2 because of the new modalities that have been introduced. For example, a busy signal on an internal call is less important to the Enterprise Voice user because the user can check the presence status of the person that he or she wants to call and then decide whether IM or e-mail might be more efficient.

You should also consider what supplementary services you want to deploy. In this sample deployment, Litware has decided to use the Response Group Service on Office Communications Server 2007 R2 to implement an automatic welcome message for both main numbers, followed by a longest-idle distribution of calls to the two Office Communicator Attendant Console users in the US. In Germany, the Response Group Service will provide a Welcome Message followed by music on hold until the Office Communicator Attendant Console user answers the call. If no one answers within 45 seconds the call will be transferred to Microsoft Exchange 2007 Unified Messaging Server, where the caller can a leave a voice mail message that will be sent by e-mail to the Office Communicator Attendant Console user.

For simplicity’s sake, this walkthrough does not include the Office Communications Server Monitoring Server, which monitors call quality and captures call detail records.

The result of the feature comparison is a map of Enterprise Voice features to the needs of various users, including standard office users, administrative assistants and their bosses, and Attendant Console users.

Planning User Migration

You can use the PBX inventory and the feature comparison in order to determine which phone numbers will be transferred to Office Communications Server 2007 R2 and which will remain on the PBX. Analog devices, such as fax machines and wall-mounted hallway phones, will not benefit from the unified communication functionality provided by Office Communications Server 2007 R2, and so these analog devices will stay within the TDM environment. Ideal candidates for migration to Office Communications Server 2007 R2 are those who will get the most benefit from unified communications, such as users of standard office phones, administrative assistants and their bosses, and users of attendant consoles. In selecting candidates for migration, you should also consider if a given candidate will be able to handle the new set of functionality.

For Litware’s US site, there are about 30 devices and extensions that should not be migrated to Office Communications Server 2007 R2. Because of the high number of users compared to the German site, the migration strategy will not replace the entire PBX with Office Communications Server 2007 R2.

There are now multiple options on how to integrate the TDM/SIP Gateway with the existing telephony infrastructure:

  • Configuration of a PRI trunk between the PBX and the TDM/SIP Gateway A PRI trunk connection will be configured that creates a connection between the existing PBX and the TDM/SIP Gateway. Calls from the PSTN to Office Communications Server extensions will be routed by the PBX to the trunk connection where the TDM/SIP Gateway has been connected.

  • Placing the TDM/SIP gateway between the PSTN and the PBX The gateway sits between the PBX and the PSTN. Incoming calls from the PSTN will be routed by the gateway to Office Communications Server 2007 R2, Mediation Server. Calls from PBX extensions to Office Communications Server users need to be routed by the PBX to the gateway so that the gateway can forward these calls to the Mediation Server.

  • Establishing a SIP trunk between Mediation Server and the PBX

    If the PBX is an IP PBX and has been certified by the Microsoft Unified Communications Open Interoperability Program ( http://go.microsoft.com/fwlink/?LinkId=158268 ) for direct connection to the Mediation Server, a direct SIP connection can be established to route calls between the two systems.

Because an unused PRI port is already available in the TDM PBX and the PBX is not a certified IP PBX for direct SIP connection, the strategy will be to configure a PRI trunk connection with QSIG protocol in the existing PBX. Routing needs to be configured in the PBX that will route all Office Communications Server 2007 R2 phone extensions to the trunk connection. A single-span PRI Gateway (selected from the list of certified Gateways at http://go.microsoft.com/fwlink/?LinkId=158268 ) will be deployed and connected with the Mediation Server in the US site. The final architecture for the US site would look as follows:

Figure: US Site Voice Architecture

The same reasoning must be applied to the Germany site. Since there are only a few devices that should remain in the TDM environment, the migration strategy will connect these devices directly to analog ports provided by the gateway. This strategy allows a complete replacement of the TDM PBX on this site. The Germany site gateway needs to be dual-span PRI Gateway with additional four to eight analog ports that will be connected directly to the PSTN. The final architecture for the Germany site would look as follows:

Figure: Germany Site Voice Architecture

User dialing habits

A complete map of the organization and user dialing habits is critical to be able to configure the dial plan in Office Communications Server 2007 R2. Maintaining these dialing habits in an Office Communications Server 2007 R2 migration is important if users are to adopt the system quickly. Over time, users will become accustomed to contacting other users by clicking a contact’s name, and so the actual phone numbers and extensions will become less important. For the initial period after the deployment, however, the user should not be forced to change his or her dialing behavior.

The dialing habits of the US users are as shown in the following table. The external line prefix to identify outbound PSTN calls is 9.

Table US Dialing habits

# Location Profile US.litware.com Number pattern

1

Emergency call without external line prefix

911

2

Emergency call with external line prefix

9911

3

Operator services call with external line prefix

9311

4

Internal 3 digit call

118

5

Local call with external line prefix

9550001

6

Long Distance Call 10 digit with external line prefix

92065550001

7

Long Distance Call 11 digit with external line prefix

912065550001

8

International Call with external line prefix

90114144205575

The dialing habits of German users can be seen in the following table. The external line prefix to identify outbound PSTN calls is 0.

# Location Profile GER.litware.com Number pattern

1

Emergency number 110, 112 and 115, including external dial prefix

0110

2

Emergency number for data emergencies 116116, including external line prefix

0116116

3

Internal 2-digit subscriber number +49221801xx

12

4

Local call, Cologne (221) area code, including 0 as external line prefix

02882

5

National call, including 0 as external line prefix

008931760

6

International number, including 0 as external line prefix

00014255550001

Dialing Authorization

Not every user is necessarily allowed to dial any phone number. Depending on your organization’s policy, users will be classified into different class-of-service categories.

Litware currently utilizes the following class-of-service categories:

Table US Site Class of Service

US

Emergency Calls + Internal Calls

Emergency Calls + Internal Calls + Local Calls

Emergency Calls + Internal Calls + Local Calls + National Calls - Premium Calls

Emergency Calls + Internal Calls + Local Calls + National Calls + Premium Calls

Emergency Calls + Internal Calls + Local Calls + National Calls - Premium Calls + International Calls

Emergency Calls + Internal Calls + Local Calls + National Calls + Premium Calls + International Calls

Table Germany Class of Service

Germany

Emergency Calls + Internal Calls

Emergency Calls + Internal Calls + National Calls - Mobile Calls - Premium Calls

Emergency Calls + Internal Calls + National Calls + Mobile Calls - Premium Calls

Emergency Calls + Internal Calls + National Calls + Mobile Calls + Premium Calls

Emergency Calls + Internal Calls + National Calls + Mobile Calls - Premium Calls + International Calls

Emergency Calls + Internal Calls + National Calls + Mobile Calls + Premium Calls + International Calls

Here is an example to understand the tables above: A user that has been assigned to the Class-of-Service category “Emergency Calls + Internal Calls + National Calls + Mobile Calls – Premium Calls” is allowed to call any number in Germany except for premium rate numbers. For example:

Allowed:

+49 (221) 8010-0 (local call)

+49 (89) 3176-0 (national call

Not allowed:

+49 (900) 123456 (premium call)

+1 (425) 555 0001 (international call)

Least Cost Routing

Before the Office Communications Server 2007 R2 migration, the existing two PBX nodes in the US and in Germany have not been interconnected. Both PBX sites were standalone systems. The Office Communications Server 2007 R2 deployment and the existing WAN connection between the two sites made least-cost routing possible. In lease-cost routing, an authorized Office Communications Server 2007 R2 user in the US can dial a phone number in Austria by using the IP WAN connection to the gateway in Germany, where the call will be terminated in the PSTN. Configuring least cost routing will save money, because a call from Germany to Austria is less expensive than a call from the US to Austria.

Litware decided to allow German users to dial US numbers by using the US Gateway. Litware also wants to configure the system so that all calls from US Office Communications Server 2007 R2 users to Germany and adjacent countries (Netherlands, Belgium, Luxembourg, France, Switzerland, Liechtenstein, Austria, Czech Republic, Poland and Denmark) terminate on the German gateway.

For outbound calls that have been rerouted to a gateway other than the local gateway, correct calling party numbers cannot be guaranteed. The corporate main phone number of the gateway location will normally be used instead.

Exchange 2007 SP1 UM and Office Communications Server integration

Exchange 2007 SP1 Unified Messaging is the supported voice mail repository solution for Office Communications Server 2007 R2. To replace any existing voice mail solution that was provided by the TDM PBX system, Litware will need to deploy the Unified Messaging role in its Exchange 2007 deployment.

Because the two systems are designed to work with each other, users will experience additional features with little or no effort on the part of the system administrators. Users will be able to send voice mail to any phone that can be dialed as part of the outcalling configuration, listen to voice mail from within Outlook 2007, or use Outlook Web Access to listen to their voice mail.

Office Communications Server 2007 R2 will send unanswered voice calls to the Exchange 2007 SP1 Unified Messaging server by doing an Active Directory lookup on the phone number in the SIP INVITE message that is passed to the Mediation Server by the media gateway. That phone number should already be manipulated in such way that it follows IETF RFC 3966, “The tel URI for Telephone Numbers,” and the E.164 format. Because the Active Directory Domain Services have both phone numbers and SIP URI defined for each user, all communications to the various endpoints within the overall system occur by using the SIP URI addressing.

Exchange 2007 SP1 Unified Messaging also offers subscriber attendants and auto attendants to provide full voice mail access. Users can dial in to retrieve e-mail, and outside users can dial in to contact users by directory lookup and, if the call is unanswered, leave voice mail.