Select a Deployment Option in Office Communications Server

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

Enterprise Voice provides several deployment scenarios that address various deployment strategies, timelines, and existing telephony investments. These scenarios fall into two groups:

• Communications Server-PBX Coexistence

• Communications Server stand-alone

Office Communications Server-PBX Coexistence

This option involves a PBX coexisting with Office Communications Server 2007 and Office Communicator 2007 to provide a flexible and powerful combination of traditional telephony and the benefits of unified communications, including rich audio, intuitive call control, enhanced presence notification, and the ability to communicate directly from Microsoft Office applications.

This Office Communications Server-PBX Coexistence option offers two alternatives:

• Native IP-PBX integration

• TDM-PBX integration through a media gateway

Native IP-PBX Integration

Native IP-PBX integration refers to full coexistence between Communications Server and a PBX that natively supports SIP and IP media in a format that is interoperable with Microsoft Enterprise Voice. With native PBX integration, all users in an organization can make and receive phone calls using their existing desktop PBX phone or Office Communicator 2007.

A call is anchored on the system that originates the call. Calls from the PSTN or internal PBX phones are anchored on the PBX; calls initiated in Communicator are anchored on Communications Server. The system anchoring a call is configured to "fork" the call to the other system in addition to ringing its own endpoints. All signaling and media is terminated and normalized on the Mediation Server, which mediates both signaling and media between the two systems.

The following diagram shows a typical topology for PBX Integration.

Figure 11. Native IP-PBX integration deployment option

PBX integration is possible only with an IP PBX that natively supports SIP and Internet protocol media in a form that is interoperable with Communications Server.

Only the latest IP PBX models support native PBX integration and even then it is likely that a software upgrade needs to be provided by the PBX vendor. These next-generation IP PBXs are being developed by several third-party vendors (for a list of vendors, see https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=IPpbxVend) and should be available soon, if they are not already. For information about the availability and functionality consult each vendor directly.

The following simple call scenarios demonstrate how PBX integration works.

Outside Call to Internal User

Bob calls Alice from the PSTN. The call is routed by the PSTN service provider to the enterprise PBX, which rings Alice's desktop PBX phone and also forks the call to Communications Server. The PBX forks the call by translating the incoming call alert to a SIP INVITE transaction and passing this request to the Mediation Server that connects it with Communications Server. In turn, Communications Server performs reverse number lookup on the called number to obtain all of Alice's registered SIP endpoints and, upon finding them, rings all the endpoints. Alice has the choice of answering the call on whichever endpoint device is most convenient. When Alice answers the call on one of her endpoints, all other endpoints stop ringing.

Ann, a mobile worker, calls Alice from her laptop by clicking Alice's name in her Communicator Contacts list. The call takes the form of a SIP INVITE request. Communications Server performs reverse number lookup on the called number and rings all of Alice's SIP endpoints. Communications Server also forks the call to the PBX, which understands SIP and therefore uses the TEL URI to ring Alice's desktop PBX phone. Once again, Alice has the option of answering the call on whichever device is most convenient.

Note

Voice calls between users outside the corporate firewall who are enabled for Enterprise Voice and using Office Communicator 2007 and internal users who are enabled for Communications Server 2005 SP1 and using Office Communicator 2005 should not be expected to work.

Internal Calls Among Users

Because all internal users are enabled for both PBX and VoIP calls, the device each user chooses to place a call determines which system handles the routing. If Alice uses her PBX phone to call Dan's extension, the call is routed to Dan's desktop phone by the PBX. But the PBX also forks the call to Communications Server, which routes the call to all Dan's SIP endpoints.

If Alice uses Communicator or a SIP phone to make the call, the SIP INVITE is sent to Communications Server, which routes the INVITE to all Dan's SIP endpoints and also forwards it to the PBX, which rings Dan's desktop PBX phone.

Internal Call to Outside User

The routing of calls to external numbers depends on routing rules that are configured on both the PBX and Communications Server. Routing rules can be configured on Office Communications Server to route calls to phone numbers to the PBX or to a media gateway, if deployed.

Voice Mail

Users who are enabled for PBX integration do not have access to Office Communications Server voice mail. Therefore, when deploying PBX integration, you should plan to keep the voice mail system on your PBX. If you eventually retire the voice mail system on your PBX, you can then disable PBX integration and reconfigure voice mail on Exchange Unified Messaging, as described in this guide.

Call Forwarding

Call forwarding can be configured on Communicator, the PBX phone, or both. If both are configured, then both should point to the same destination.

If RCC is enabled, then only the PBX forwarding options are shown, and a single option can be set on the PBX side. If RCC is not enabled, then the user can set forwarding independently for Enterprise Voice and the PBX. It is recommended that the user manually synchronize the forwarding options for the two systems.

Conferencing

Conference calls are established on the system that initiates the conference. If Communicator establishes a conference on the Communications Server A/V Conferencing Server, PBX telephones are enrolled in the conference by means of "dial out" as an outbound call leg. If a PBX user initiates a PBX conference, an Enterprise Voice user can join or be "dialed" in to the conference as a normal inbound or outbound call leg.

RCC

RCC allows users to use Communicator to monitor and control their PBX phones. This feature is disabled for Enterprise Voice, but remains available with PBX integration. In order for RCC to work in a PBX integration scenario, each user must be configured with the same SIP and/or TEL URI for both RCC and Enterprise Voice. Otherwise, a call received through either of these systems cannot be correlated to the same calling party. As a result, a user might be presented with two toasts announcing the same call.

Two phone number formats are supported for both RCC and Enterprise Voice:

• E.164, such as +14257221234

• E.164 + Extension, such as +14257221234;ext=21234

If a user receives a call from a remote party, then the caller ID must be populated with these formats and must be consistent across the two systems.

Note

Although an RCC user can also be configured with a private phone number, such as 21234;phone-context=xxx, Enterprise Voice does not support private numbers. Therefore, if a user has a private number it must be configured as E.164 with an extension, using a global E.164 access number to the user’s domain.

Following are some examples and guidelines to consider for ensuring that dual forking and remote call control work together:

• If a PBX can handle E.164 numbers natively and can provide such numbers in the URIs delivered by means of both RCC and SIP, and if all the numbers are Direct Inward Dialing (DID) numbers, then there is no need to configure extensions in Active Directory for individual users.

• If a PBX uses extensions to route calls — the typical case — then the PBX uses an extension to designate the users both making and receiving a call. Because the PBX does not natively correlate the extensions with E.164 equivalents, it needs to access Active Directory to convert the extensions to E.164 for both parties when using RCC to communicate with Enterprise Voice users. There are 2 cases to consider here, all of which assume that a single extension can uniquely identify a user even if a call traverses several PBXs with DIDs that are potentially from completely different locations:

• Case 1: The PBX has a unique E.164 DID number for each user, and the internal extension used by internal callers is a subset of this DID number.

  For this case, each individual user can be represented in the Active Directory Line URI by either an E.164 number or an E.164 number + extension. For example, if the user has an E.164 DID number of +14257272133, either this number or +14257272133;ext=72133 can be entered in the Line URI field. If the PBX is capable of parsing entries in the Line URI field when it needs to convert an extension to E.164, then no additional configuration is necessary. An alternative way to associate a user with the appropriate extension, is to configure one of the other fields in Active Directory — such as the phone-office-other field associated with the user — with the value of the extension.

• Case 2: The PBX does not have a unique E.164 DID number for each user. To reach a particular user from the PSTN, an outside caller must dial the E.164 number of the PBX and specify the extension when prompted by the Interactive Voice Response.

  For this case, the Active Directory Line URI for ach user must contain an E.164 number + extension. if the PBX is capable of parsing the Line URI field when it needs to convert an extension, then no additional configuration is necessary. An alternative way to associate a user with the appropriate extension, is to configure one of the other fields in Active Directory — such as the phone-office-other field associated with the user — with the value of the extension.

For information on how to configure RCC for users who are enabled for PBX integration, see Step 9. Enable Users for PBX Integration (Optional).

TDM-PBX Integration Through a Media Gateway

In order to enable the coexistence scenario, in the event you have TDM-PBX infrastructure that supports forking of calls, an alternative approach is to deploy a Microsoft-certified media gateway or gateway/Mediation Server combination between Office Communications Server and the PBX. A number of these media gateways are available within the Microsoft Unified Communications Media Gateway partner program (for the current list, see https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=IPpbxVend). These media gateways interoperate with the Office Communications Server Mediation Server by means of SIP and IP media and with the PBX by means of various telephony protocols.

Figure 12 TDM-PBX Integration Through a Media Gateway

Office Communications Server Stand-Alone

Three deployment scenarios use Communications Server 2007 as the sole telephony solution for part or all of an organization. These scenarios include the following deployments:

• Departmental deployment

• Greenfield deployment

The following topics describe these scenarios in detail.

Departmental Deployment

In this scenario, Communications Server is deployed as the sole telephony solution for individual teams or departments, while the rest of the users in an organization continue using a PBX. This incremental deployment strategy provides one way to introduce IP telephony into your enterprise through controlled pilot programs. Workgroups whose communication needs are best served by Microsoft Unified Communications are moved to Enterprise Voice, while other users remain on the existing PBX. Additional workgroups can be migrated to VoIP as needed.

The departmental option is recommended for clearly defined user groups that share communication requirements in common and lend themselves to centralized management. This option is also attractive for teams or departments that are spread over wide geographic areas, where the savings in long-distance charges can be significant. In fact, this option is useful for creating virtual teams whose members might be scattered across the globe. Such teams can be created, amended, or disbanded in rapid response to shifting business requirements.

The following figure shows the generic topology for deployment of Enterprise Voice behind a PBX. This is the recommended topology for departmental deployment.

Figure 13. Departmental migration option

In this topology, selected departments or workgroups are enabled for VoIP. A media gateway links the VoIP-enabled workgroup to the PBX. Users enabled for VoIP, including remote workers, communicate across the IP network. Calls by VoIP users to the PSTN and to coworkers who are not enabled for VoIP are routed to the appropriate media gateway. Calls from colleagues who are still on the PBX system, or from callers on the PSTN, are routed to the media gateway, which forwards them to Communications Server 2007 for routing.

There are two recommended topologies for connecting Enterprise Voice with an existing PBX infrastructure for interoperability:

• Enterprise Voice behind the PBX

  In this topology, all calls from the PSTN arrive at the PBX, which routes calls to Enterprise Voice users to a media gateway, and calls to PBX users in the usual way. Table 1 shows the advantages and disadvantages of this topology.

  Table 1. Advantages and disadvantages of deploying Enterprise Voice behind a PBX

  Advantages	Disadvantages
  The PBX still serves users not enabled for Enterprise Voice.	If necessary, tie line board in the PBX must be added for gateway connection.
  The PBX handles all legacy devices.	The PBX must be configured to route Enterprise Voice numbers to the gateway.
  Users can keep the same phone numbers.

• Enterprise Voice in front of the PBX

  In this topology, all calls arrive at the media gateway, which routes calls for Enterprise Voice users to Communications Server and calls for PBX users to the PBX. Calls to the PSTN from both Enterprise Voice and PBX users are routed over the IP network to the most cost-efficient media gateway. Table 2 shows the advantages and disadvantages of this topology.

  Table 2. Advantages and disadvantages of deploying Enterprise Voice in front of a PBX

  Advantages	Disadvantages
  The PBX still serves users not enabled for Enterprise Voice.	Existing gateways might not support desired features or capacity.
  The PBX handles all legacy devices.	It might be necessary to reset trunks from the local exchange carrier to point to the media gateway.
  Enterprise Voice users keep the same phone numbers.

The departmental option assumes that you have an existing PBX infrastructure and intend to introduce Enterprise Voice incrementally to smaller groups or teams within your organization. The greenfield option assumes that you are considering deploying Enterprise Voice at a site without traditional telephony infrastructure.

Greenfield Deployment

Enterprise Voice provides new businesses or even new office sites for existing businesses with the opportunity to implement a full-featured VoIP solution without having to worry about PBX integration or incurring the substantial deployment and maintenance costs of an IP PBX infrastructure. This solution supports both onsite and remote workers.

In this scenario, all calls are routed over the IP network. Calls to the PSTN are routed to the appropriate media gateway. Communicator serves as a softphone. RCC is unavailable in this scenario because Communicator Phone Edition, like Communicator, provides click-to-call capability. Voice mail and auto-attendant services are available through the optional deployment of Exchange Unified Messaging.

Note

In addition to the network infrastructure that is required to support Communications Server 2007, a greenfield deployment might require a small PBX to support fax machines and analog or ISDN devices. In certain scenarios, this might require a new PRI (Primary Rate Interface) link with a new set of numbers.

The following figure shows a typical topology for a greenfield deployment.

Figure 14. Greenfield deployment option