Users configured for dual forking will have an experience similar to that of users configured for Enterprise Voice (see Chapter 11) from click to call in Office Communicator to calling Response Groups. Dual forking can be set up in two different configurations. The first configuration is dual forking without Remote Call Control (RCC) to the PBX. The second configuration is dual forking coupled with RCC to the PBX. This section explores where the user experience differs in dual forking and dual forking with RCC.
Note
Office Communicator Phone Edition does not support the dual forking scenario. The only audio-capable client that supports dual forking is Office Communicator.
The section titled "Examining Technical Details Behind Dual Forking Scenarios" later in this chapter offers more detail on how these scenarios work.
Making a call in a dual forking environment is similar to making a call in an Enterprise Voice environment. When RCC is available, the user can choose whether to place the call from the PBX phone or Office Communicator. This is shown in Figure 10-1.
Answering a call in a dual forking environment is similar to answering a call in an Enterprise Voice environment. When RCC is available, dual forking enables the call to be answered on either Office Communicator or the PBX phone. Clicking the incoming call notification answers the call on the default device (which can be set to Computer or Phone from Call Forwarding Settings). The redirect option enables the user to select a different device. This is shown in Figure 10-2.
The in call experience for dual forking is similar to the in call experience for an Enterprise Voice environment. If the PBX phone is used for calling (RCC scenario), then the user experience differs from using Communicator because the call controls that are available to an RCC-enabled user depend on what features are supported by the PBX (see Chapter 9). Another notable difference is that the RCC conversation window does not have speaker or microphone controls. Call controls when RCC is used to make or answer calls are shown in Figure 10-3.
Dual forking scenarios enable the user to use the conferencing capabilities of either the PBX system or Office Communications Server. A multiparty audio conference can be started on either the PBX side or the Office Communications Server side. The multiparty audio conference can be started by adding another user to a two-party call or when a call with three or more people is started directly. The Office Communications Server and PBX systems will maintain the roster for the conferences independently.
For example, user A starts a call with user B, who is also a dual forking user. User A uses Office Communicator as the endpoint. User B selects to answer the call on the PBX phone. User A now adds user C to the two-party call to create a conference. Office Communicator creates the audio conference on the Office Communications Server’s A/V Conference Server. User A sees a conference roster and is able to view user B and user C joined to the conference. However, user B continues to see user A as the only person in the call because the PBX system does not have access to the conference roster in Office Communications Server.
Conference calls hosted on the Office Communications Server infrastructure give Office Communicator users information about participants in the call and access to conference controls. Therefore, in the preceding example, if user B had picked up the call from Office Communicator instead of her PBX phone, the conference roster information would be available to user B from Office Communicator.
Note
When RCC is used in conjunction with dual forking to make calls or answer two-party calls, such calls cannot be escalated to an audio conference from that endpoint. This is because Office Communicator is using the Computer Supported Telephony Applications (CSTA) protocol to control the PBX phone, and conferencing using CSTA is not supported from Office Communicator.
The user can configure call forwarding on Office Communications Server from a client such as Office Communicator. This is similar to the capabilities that the user has when enabled for Enterprise Voice, as described in Chapter 11.
Note
Certain call forwarding features for Enterprise Voice users, which are described in Chapter 11, are not available to dual forking users. See the section titled "Understanding Routing Rules in Dual Forking Scenarios" later in this chapter for details on features that are available.
One of the features likely not to be available to the user from Office Communicator, but which can be available on the PBX phone, is voice mail. The reason voice mail is not available in Office Communicator to dual forking users is because the administrator would likely use the existing PBX’s voice mail system instead of Exchange Unified Messaging, which is the only voice mail system supported by Office Communicator.
When optional RCC is enabled for dual forking users, the user is enabled to set call forwarding rules from the PBX. The capability to control forwarding in Office Communications Server is no longer available. The call forwarding user interface (UI) in that configuration is the same as the user would get when RCC is enabled. This is shown in Figure 10-4.
