Direct SIP: Configuring Mediation Server
This article is a partner article to "Direct SIP: Cisco Unified Communications Manager 6.1" and focuses on the configuration requirements for the Mediation Server in Office Communications Server 2007 R2. The main steps include configuring CUCM as the Mediation Server's gateway and modifying Mediation Server's location profile, but you'll want to read on to get the details.
Author: Jerome Berniere, Rui Maximo
Original Publication date: December 2009
Product version: Office Communications Server 2007 R2
This article is a continuation of the article about how to configure Cisco Unified Communications Manager (CUCM), also known as CallManager, for Direct SIP with Office Communications Server 2007 R2. (For details about configuring CUCM, see Direct SIP: Cisco Unified Communications Manager 6.1.) This article focuses on the configuration requirements for the Mediation Server. The high-level tasks are described below.
Direct SIP: Configuring Mediation Server
Configure Office Communications Server 2007 R2:
- Configure CUCM as the Mediation Server's gateway
- Modify Mediation Server's Location Profile
The advantage of Direct SIP is that you can establish direct connectivity between Office Communications Server 2007 R2 and Cisco Unified Communications Manager without the need for a gateway, which decreases the complexity of the interop deployment and increases call quality. Figure 1 illustrates this configuration.
Figure 1. Direct SIP configuration
Configure CUCM as the Mediation Server's Gateway
You must configure the Mediation Server to connect to CUCM as its gateway. The Mediation Server needs to know the IP address of the CUCM. In our example, the Cisco CUCM's IP address is 192.168.0.210.
To configure this setting, right-click the Mediation Server node, and then click Properties in Administrative Tools (see Figure 2).
Figure 2. Administrative Tools Properties menu
From the Mediation Server's properties page, navigate to the Next Hop Connections tab. In the IP Address field under PSTN Gateway next hop, specify the CUCM's IP address (in this example, 192.168.0.210). In Port, type 5060. This is illustrated in Figure 3.
Figure 3. Properties dialog box
Modify the Mediation Server's Location Profile
Every Mediation Server must be assigned a default location profile. You can assign a location profile to the Mediation Server by navigating to the General tab of the Mediation Server's Properties as shown in Figure 4.
Figure 4. Mediation Server Properties dialog box
You must modify the Mediation Server's location profile. You must create new normalization rules to normalize the dial strings coming from CUCM across the SIP trunk. To edit the location profile in Administrative Tools, right-click the Forest node, click Properties, point to Voice Properties (see Figure 5).
Figure 5. Voice Properties menu
On the Location Profiles tab, locate the profile assigned to your Mediation Server, and then click Edit. This will bring up the Edit Location Profile dialog box where you can add new normalization rules or edit existing ones (see Figure 6).
Figure 6. Voice Properties dialog box and Edit Location Profile dialog box
A normalization rule is similar to CUCM's translation pattern. It serves the purpose of translating a phone number, which is called a dial string, from one format to another format.
One or more normalization rules must be defined depending on your needs. At a minimum, you need to define at least two normalization rules as follows:
- A normalization rule for incoming calls from CUCM users destined to Office Communicator users. This enables Cisco IP phone users to dial Office Communicator users within the organization.
- A normalization rule for incoming calls from the public switched telephone network (PSTN) to Office Communicator users. This enables external (that is, PSTN) users to call Office Communicator users.
CUCM to Office Communications Server Normalization Rule
This normalization rule applies for internal number routing so that users using a Cisco IP phone can dial an Office Communicator user within the organization by using an extension number. To be properly routable by Office Communications Server to the correct destination user, the Mediation Server must translate the extension number into an RFC3966 compliant global number. In this example, the normalization rule Internal number NR transforms an extension number, 4-digit dial string xxxx, into an RFC3966 compliant global number, +3316986xxxx, where +33 is the country code for France, 1 is the region code for Paris, 6986 is the prefix for the carrier's central office, and xxxx is for all numbers assigned to that organization. If the organization was located in Redmond, WA, the normalization rule would likely translate the 4-digit dial string, xxxx, into +1425703xxxx, where +1 is the country code for U.S., 425 is the area code for Redmond, WA as defined by NANPA, 703 is the prefix for the carrier's central office, xxxx is the prefix for all numbers for the organization.
After the extension is translated into an RFC3966 compliant number, Office Communications Server can route the call to the appropriate Office Communicator user whose phone number matches the RFC3966 compliant number. This normalization rule is applied to inbound traffic from the CUCM. The phone pattern regular expression in this scenario is ^([0-9]{4})$, and the translation pattern regular expression is +3316986$1 as shown in Figure 7.
Figure 7. Internal number NR normalization rule
In addition to translating the TO field dial string, this normalization rule will also convert the FROM field that matches the dial string xxxx to an RFC3966 global number. Once transformed into an RFC3966 number, Office Communications Server can then resolve the RFC3966 number into the corresponding dialer's SIP URI if available.
To allow Office Communicator users to dial users using an extension number, the same normalization rule can also be added to the user's location profile. The rule normalizes that dial string into a global number. If that number can be matched against a unified communications (UC) enabled user's phone number, it is associated to a SIP URI and routed within Office Communications Server. If there is no match, the call is routed to the appropriate external route, which is CUCM in this example.
PSTN to Office Communications Server Normalization Rule
This normalization rule applies for external number routing so that PSTN users can dial an Office Communicator user. In this example, CUCM formats the dial string prepended with "00". The leading digit, "0", is configured as the external prefix number in France. An external prefix is the digit you dial to get out to the PSTN. In the U.S., most organizations use the digit, "9", for example to call out to the PSTN. For calls passed by CUCM across the SIP trunk to Office Communications Server, the FROM field contains dial strings that start with "00". The leading zero is the external prefix so that if the callee were to call back the PSTN caller the call would be properly routed to the PSTN by CUCM. The second zero is for national PSTN numbers (instead of +33). PSTN presents only one "0" and the CUCM adds a second prefix "0" to differentiate external versus internal number. The normalization rule translates the FROM field into an RFC3966 global number that is used for reverse number lookup by Office Communications Server.
The normalization rule, named National, transforms a dial string that starts with 00 followed by 9 digits into an RFC3966 compliant global number by stripping the "00" and replacing with "+33". This normalization rule is applied to inbound calls to Office Communications Server from CUCM. The phone pattern regular expression in this scenario is ^00(d\{9})$, and the translation pattern regular expression is +33$1 (see Figure 8).
Figure 8. National normalization rule
Strip Plus Sign (+) from Request URI
Because CUCM 6.1 is not fully compliant with RFC3966, it doesn't support the use of the plus sign (+) in the TEL URI. This creates an interoperability issue when the Mediation Server forwards calls to CUCM as CUCM cannot properly interpret phone numbers in RFC3966 format. Luckily, Office Communications Server provides a means to strip the plus sign (+) from the TEL URI at the Mediation Server before it forwards the call to CUCM. This is exposed as a Windows Management Instrumentation (WMI) configurable setting called RemovePlusFromRequestURI. When it is set to true, it strips the plus sign (+).
Salman Khalid, a software test engineer in the Office Communications Group, provided the following VBScript code to set the RemovePlusFromRequestURI WMI setting. To run it, copy it into an ASCII text file with a file extension of .vbs.
Query = "SELECT * FROM MSFT_SIPMediationServerConfigSetting"
Set InstList = GetObject("Winmgmts:root\cimv2").ExecQuery(Query)
For Each Inst in InstList
Inst.RemovePlusFromRequestURI = True
Inst.Put_
Next
wscript.echo "Update successfully"
Additionally, Rui Silva has posted a very good blog entry that explains various ways to set this WMI setting. You can find this post in the Additional Information section.
Additional Information
To learn more, check out the following articles:
Direct SIP: Cisco Unified Communications Manager 6.1. at go.microsoft.com/fwlink/?LinkId=179795
Setting up the Cisco Call Manager 4.2.1 for "Direct SIP with IP-PBX" at go.microsoft.com/fwlink/?linkid=178442
Direct SIP with IP-PBX in Office Communications Server 2007 at go.microsoft.com/fwlink/?linkid=178443
RemovePlusFromRequestURI (or how to make OCS non-RFC 3966-compliant) at go.microsoft.com/fwlink/?linkid=178444
Office Communications Server Resources
- Visit the Office Communications Server main page at go.microsoft.com/fwlink/?LinkId=132607.
- View the complete Office Communications Server documentation library at go.microsoft.com/fwlink/?LinkId=132106.
- Follow tweets from the Office Communications Server team at go.microsoft.com/fwlink/?LinkId=167909.
- Download all the Office Communications Server content as a Word document at go.microsoft.com/fwlink/?LinkId=133609.
- Download all the Office Communications Server content as a compiled help file at go.microsoft.com/fwlink/?LinkId=160355. (Make sure you scroll down to the Additional Information section to download OCSDocumentation.chm.)
Comments
- Anonymous
June 15, 2010
Great article, during our recent Nortel deployment of OCS 2007 R2 we decided to use their intermediate software solution (MCM). When we complete our end-user migration from Nortel to Communications Server I would definately look to remove this and go directly attached. I am a big fan of the least complex approach, as stated within your article.