Configuring a user for dual forking requires the following steps.
Configuring Office Communications Server. This requires configuring Enterprise Voice first, which involves configuring phone routes, policies, location profiles, and normalization rules. Details on how to configure these settings are covered in Chapter 11.
When configuring a policy for the user, ensure that the policy has Simultaneous Ring to PSTN Phone turned off. This is a check box in the Policy dialog box, as shown in Figure 10-11. (For detailed configuration of Voice policies, see Chapter 11.) This is a recommended step so that forking the call to the PSTN phone does not interact with forking to the PBX. If this policy is not configured and the user enables Simultaneous Ring from PSTN Phone, the PSTN phone can receive two incoming call notifications for the same call in certain scenarios. If the PSTN system has voice mail, the adverse side effect could be that some calls are always answered by voice mail directly.
Once these configurations are done, users can be configured for dual forking. This step is covered in this section.
Configuring the PBX. This step varies based on the PBX vendor. This configuration is not covered in this chapter. Consult your PBX vendor’s documentation for more details. Also check if the PBX is certified for dual forking. (For more information, see the section titled "Additional Resources" later in this chapter for Qualified IP PBX’s for Office Communicator.)
To configure a single user for Enterprise Voice with dual forking, select the user’s Properties from the right-click menu in DSA.MSC or the Admin Tools Microsoft Management Console (MMC). On the Communications tab, select Configure to view additional options. In the Telephony section, select Enable Enterprise Voice Routing and configure the user’s phone number. Check Enable PBX Integration to enable dual forking to the PBX. Specify a valid TEL URI assigned to the user in the Line URI field. This TEL URI is the same as the user’s existing phone number in RFC 3966 format. For example, if a user has the phone number 4255551212, the TEL URI should be set to tel:+14255551212. These settings are shown in Figure 10-12.
To enable dual forking with RCC, all that is necessary is to specify the SIP URI of the SIP/CSTA gateway in the Server URI field. This field is sufficient for Office Communicator to connect to the SIP/CSTA gateway for enabling RCC functionality.
Real World: Deploying Dual Forking with RCC with Nortel CS 1000
Sonu Aggarwal
CEO, UnifySquare, Inc.
Duncan Blake
Enterprise Voice Architect, UnifySquare, Inc.
Implementing dual forking with RCC between Office Communications Server 2007 R2 and Nortel CS 1000 requires some planning and preparation. Plan on at least an eight-week project time frame for a production implementation in the field. Check with the Nortel channel stipulations regarding whether you need to involve a Nortel certified technician and a technician from Nortel Services.
A few areas you need to watch out for while configuring dual forking with RCC include:
Patching. It is important that the CS1K PBX be patched with the right PIPs, and that the Mediation Server, front-end server, Office Communications Server proxy, and Communicator itself be patched appropriately for dual forking with RCC.
Versioning. The requirements for configuring the Nortel CS1K change significantly between Nortel CS1K version 5.0 and 5.5. For example, in the CS1K 5.0 configuration, forking is enabled by creating a Personal Call Assistant (PCA) to a dummy number, which is then routed to the Nortel MCM server. In CS1K 5.5, PCAs have been replaced by universal extensions (UEXTs), although the underlying PCA service still needs to be running on the CS1K.
Normalization. Ensuring that converged system alerts work correctly requires that two separate sets of normalization rules are set correctly—for dual forking calls (SIP INVITEs) as well as RCC calls (SIP INFOs). It also requires that the clients download updated Address Book information from the ABS with phone numbers in the prescribed format. This is accomplished through correctly formatting the correct AD Phone Number field or the correct Proxy field in Active Directory and then regenerating Address Book information.
Routing. Routing is complicated by the fact that the MCM Server has two roles, acting both as a CSTA gateway (for RCC signaling traffic) and as a SIP proxy (for the SIP signaling and media traffic through the Mediation Server). Both the MCM and the Office Communications Server Mediation Server typically have two separate networks or subnets with which they need to communicate: the Office Communications Server network and the PBX network (or, in CS1K-specific terms, the TLAN). The Office Communications Server network can be viewed as "internal" to the Office Communications Server cloud, and the TLAN be viewed as "external" (again, to the Office Communications Server cloud). The Office Communications front-end server has a static route for RCC SIP traffic that points to the "internal" edge of the MCM Server. However, the Mediation Server is configured to point to the external edge of the MCM Server as the Mediation Server gateway. In certain call flows in the dual forking/RCC scenario, the Mediation Server will use the Via: header of incoming traffic (which is based on the fully qualified domain name [FQDN]) to route responses. If the Mediation Server can resolve the internal edge of the MCM Server using the Domain Name System (DNS), this may result in a condition in which the networking stack will erroneously send traffic to the inner edge of the MCM Server. The MCM will correctly send a SIP ACK to the internal edge of the Mediation Server (the IP address from which the traffic came). However, the Mediation Server will ignore this ACK because it is received on the wrong interface for SIP traffic from the gateway.
Although the root cause is a dropped ACK, the symptom manifests itself as an established call "mysteriously" getting dropped at the 32-second mark. The easiest solution for this problem is to add an entry to the Mediation server "hosts" file, ensuring that the Mediation Server will always resolve the MCM Server FQDN to the MCM Server’s external IP address. Not being particularly intuitive, though, this is an easily overlooked step.
18.227.52.11