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 http://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.

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.

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.

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.

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 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.

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 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 tel:+14257221234
  
• E.164 + Extension, such as tel:+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 tel: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 tel, either this number or tel:+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).

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 http://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