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

If you are implementing the PBX integration deployment option, in which all users are provisioned both for Enterprise Voice and a legacy PBX, you should continue to use the PBX for voice mail and related services. If you move all or part of an organization to a stand-alone Enterprise Voice deployment, deploy Exchange Unified Messaging for those users who are no longer homed on the PBX.

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 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 Enterprise Voice. With native PBX integration, all users in an organization can make and receive phone calls by 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 Office 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 are 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 1. 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 will support native PBX integration, and even then it is likely that a software upgrade will need 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 http://go.microsoft.com/fwlink/?LinkId=125757 ). For details 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 Office Communications Server. The PBX forks the call by translating the incoming call alert to a SIP INVITE transaction and then passing this request to the Mediation Server that connects it with Office Communications Server. In turn, Office 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 on Alice's name in her Communicator Contacts List. The call takes the form of a SIP INVITE request. Office Communications Server performs reverse number lookup on the called number and rings all of Alice's SIP endpoints. Office 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.

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 will be routed to Dan's desktop phone by the PBX. But the PBX will also fork the call to Office Communications Server, which will route 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 Office 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 Office 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. For details, see Step 1. Configure Unified Messaging on Microsoft Exchange to Work with Office Communications Serverin Deploying Enterprise Voice in the Deployment documentation.

Call Forwarding

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

Team Call

The new Team Call feature in Office Communications Server 2007 R2 makes it possible to forward incoming calls to a defined team. When a team receives a forwarded call, each member's phone rings, and all members can see who forwarded the call. When a team member answers the call, the phones of all other members stop ringing.

Call Delegation

Call Delegation enables managers to delegate phone-call handling to one or more administrative assistants or other delegates. When a delegate answers a call, the manager receives notification that the call has been answered, along with the name of the delegate who answered.

Response Group

The Response Group Service enables administrators to create and configure one or more small Response Groups for the purpose of routing and queuing incoming phone calls to one or more designated agents. These Response Groups can be deployed in departmental or workgroup environments and in entirely new telephony installations. For example, a Response Group could be an internal helpdesk, a customer service desk, or a general external call handler.

Office Communications Server 2007 R2 Attendant

Office Communications Server 2007 R2 Attendant is a new integrated call management client application that enables a user to effectively manage many conversations at once through rapid call handling, instant messaging (IM), and on-screen routing in a single window. It is designed for administrative assistants, team delegates, receptionists, and other users who must handle multiple calls and conversations at once.


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

Remote Call Control

Remote call control (RCC) enables users to use Communicator to monitor and control their PBX phones. This feature is disabled for Enterprise Voice, but it remains available with PBX integration. If you have previously implemented RCC for your Office Communications Server users, there is no need to change that setting when you enable them for PBX integration.

TDM-PBX Integration Through a Media Gateway

If you want to enable the coexistence of Communications Server and PBX on a TDM-PBX infrastructure that supports forking of calls, you can also 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 http://go.microsoft.com/fwlink/?LinkId=125757 ). 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 2. TDM-PBX Integration through a media gateway

Communications Server Stand-Alone

If your organization uses one of the deployments described in this section, you can use Office Communications Server 2007 as the sole telephony solution for part or all of an organization. This section describes the following deployments in detail:

  • Departmental deployment

  • Greenfield deployment

Departmental Deployment

In departmental deployment, Office Communications Server is the sole telephony solution for individual teams or departments, while the rest of the users in an organization continue to use 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 best if you have clearly defined user groups that share communication requirements in common and lend themselves to centralized management. This option is also attractive if you have 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 may be scattered across the globe. You can create, amend, or disband such teams 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 3. Departmental deployment 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 Office 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 and Enterprise Voice in front of the PBX.

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. The following table shows the advantages and disadvantages of this topology.

Table 1. Advantages and Disadvantages of Deploying Enterprise Voice Behind PBX

Advantages Disadvantages

PBX still serves users not enabled for Enterprise Voice.

If necessary, tie line board in PBX must be added for gateway connection.

PBX handles all legacy devices.

PBX must be configured to route Enterprise Voice numbers to gateway.

Users can keep 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 Office 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. The following table shows the advantages and disadvantages of this topology.

Table 2. Advantages and Disadvantages of Deploying Enterprise Voice in Front of PBX

Advantages Disadvantages

PBX still serves users not enabled for Enterprise Voice.

Existing gateways may not support desired features or capacity.

PBX handles all legacy devices.

It may be necessary to rehome trunks from the local exchange carrier to point to media gateway.

Enterprise Voice users keep the same phone numbers.


The remote worker option and departmental option both assume 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 on-site 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 or Communicator Phone Edition serves as a softphone. RCC is unavailable and unnecessary because there are no PBX phones for users to control. Voice mail and auto-attendant services are available through the optional deployment of Exchange Unified Messaging.

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

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

Figure 4. Greenfield deployment option