Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
What’s changing?With the hotfixes released in August 2008, Microsoft is significantly improving the capability for Office Communications Server 2007 to exchange calls with SIP-based IP-PBX, in particular from Cisco. As a consequence, Microsoft now supports OCS deployments in Direct SIP with IP-PBX between Office Communications Server and specific versions of Cisco Call Manager.
This change gives administrators the possibility to set up Office Communications Server so that it can directly interoperate with IP-PBX using E.164 globally routable telephone numbers without RFC3966’s mandated “+” prefix. Additionally, Office Communications Server will now be able to interoperate with IP-PBX within a private dialing plan, exchanging locally routable private numbers.
Author: Francois Doremieux, Jerome Berniere
Publication date: September 2008
Product version: Office Communications Server 2007 R2
Direct SIP is the documented and supported way in which Microsoft Office Communications Server exchanges voice calls with third-party on-premise devices such as SIP/PSTN gateways and IP-PBX. In Direct SIP, an Office Communications Server’s Mediation Server is directly connected to a SIP/PSTN gateway or an IP-PBX. Microsoft provides the Unified Communications Open Interoperability Program (OIP) for the qualification of third-party solutions for interoperability with Microsoft Office Communications Server. Under the OIP, Direct SIP is based upon common industry standards (SIP over TCP, RTP, G.711…). Direct SIP with a SIP/PSTN gateway enables Office Communications Server to exchange calls directly with the PSTN, as well as with virtually any TDM PBX, and (via back to back SIP/PSTN gateways) with virtually any IP-PBX.
Direct SIP with IP-PBX is a variation in which the calls are exchanged over IP between the Mediation Server and an IP-PBX, without the use of back to back IP/PSTN gateways (i.e. in IP all the way, without transcoding between IP and TDM). That is done across an IP to IP connection between the two systems (a connection which most IP-PBX vendors generically call a “SIP trunk”) over which the two systems will converse in a standard manner (SIP over TCP, RTP, G.711…) as specified in the OIP’s Direct SIP specifications.
Microsoft actually had built that capability from the start both into the product and into the OIP, in a standard-based way, and was ready to support Direct SIP with IP-PBX that qualified in the OIP. However, testing showed that few if any IP-PBX were capable of meeting the standards-based specifications for Direct SIP interoperability and OIP qualification.
Specifically, Office Communications Server conforms to RFC3966. RFC3966 defines the taxonomy and syntax for phone numbers that is mandated by the SIP standard. While Office Communications Server is RFC3966 compliant, many of the most commonly deployed IP-PBX in the market today are not. If two voice systems from different vendors do not format phone numbers the same way, Direct SIP interoperability will not work. Lack of RFC3966 compliance is the primary technical reason why those IP-PBX could not qualify for Direct SIP in the OIP.
Note: throughout Microsoft documentation, you may find references to “E.164 numbers” to describe numbers such as +14255551212 (i.e. a globally routable phone number with a leading “+”).ITU’s E.164 is a global scheme for normalizing globally routable numbers (and is used in particular for international numbering on the PSTN and increasingly on mobile phone networks). While not incorrect, the use of the term E.164 to designate those numbers can lead to confusion because E.164 does not mandate the leading “+” (as traditional phones and PBX do not have a way to input, transmit or process a “+”).Most IP-PBX can understand E.164 numbers but only do so when those numbers are expressed without the “+”, as dial strings. Typically, such IP-PBX do not support the “+” in the REQUEST and TO header fields of a SIP message. They may tolerate the “+” in the FROM header field of a SIP message, but generally are not able to process it: numbers with a “+” in the FROM field cannot be dialed back to Office Communications Server from the IP-PBX.Numbers such as +14255551212 are actually “RFC3966 compliant global numbers”. RFC3966 defines the tel: URI scheme that is used by SIP. For globally routable phone numbers, RFC3966 is based upon E.164, which it clarifies by requiring the leading “+”. It also adds support for non-globally routable numbers (also called local or private numbers) that are not defined in E.164. RFC3966 requires a “Phone-Context” in the tel: URI; the “Phone-Context” removes any ambiguity as to which system or network entity the local number refers to, and may enable to translate/normalize between local and global numbers.
The changes are accessible to users of Microsoft Communications Server 2007 via update packages as described in the following Microsoft Knowledge Base articles: http://support.microsoft.com/kb/952783/; http://support.microsoft.com/kb/952780/; http://support.microsoft.com/kb/953659/; http://support.microsoft.com/kb/957707 (Updating last url with October client update that includes prior fix).
The updates need to be installed to the RTM (6362.0) version or to previously updated installations and are available for both Office Communications Server Enterprise and Standard Edition.
For the following servers:
apply Server.msp to each server. No server reboot is required.
For the Mediation Server role: apply both MediationServer.msp and UCMARedist.msp to the Mediation Servers that will be connected to the IP-PBX; a service restart will be required after applying UCMARedist.msp.
For Office Communicator 2007: apply Communicator.msp.
After the updates, a configuration file is required on Office Communications Server 2007 to enable the changes. The configuration file, called “MediationServerSvc.exe.config”, needs to be located in the Mediation Server directory where the “MediationServerSvc.exe” file is installed. By default that directory would be C:\Program Files\Microsoft Office Communications Server 2007\Mediation Server.
Here is a sample configuration file where the value of “RemovePlusFromRequestURI” has been changed from the default of “NO” to “YES”:
<?xml version="1.0" encoding="utf-8" ?><configuration> <appSettings> <add key="RemovePlusFromRequestURI" value="YES" /> </appSettings></configuration>One this is completed, restart the Mediation Server.
Note: this configuration file is also used to turn Transport Layer Security (TLS) on or off in the Mediation Server existing functionality. Therefore, the file may already exist on a particular Mediation Server computer. By default, if the file does not exist or does not have the GatewayTLS setting, TLS is turned off.
Simultaneously with the changes, Microsoft announced that it had successfully tested the following IP-PBX against the test matrix that is part of the OIP requirements for Direct SIP:
Microsoft now supports OCS interoperating in Direct SIP with the above IP-PBX from Cisco. While not tested, other versions of Call Manager at or above the 5.x level are expected to comply.
Besides Cisco Call Manager, Alcatel, Avaya, NEC, Nortel, Siemens and several other vendors do not support RFC3966 in their most common releases. The changes in Office Communications Server should facilitate the qualification of these vendors’ IP-PBX in the OIP. We highly recommend you validate in your own environment prior to making a final topology decision.
Note: some earlier versions of Cisco Call Manager (in particular 4.1) have comparatively older versions of SIP which had not yet been tested at the date of writing. Also, IP-PBX vendors may occasionally have slightly different implementations of the more arcane aspects of SIP. That may become apparent in some rare, complex call flows outside of the scope of OIP qualification testing.
These changes enable interoperating with an IP-PBX using Direct SIP with IP-PBX, across an IP connection between the Mediation Server and the IP-PBX. This IP connection is typically called a “SIP trunk” on the IP-PBX side, and we will use that generic term hereafter.
For example, here is a schematic description of the environment with a Cisco Call Manager 5.1. Note the use of a Media Termination Point (MTP) on the Call Manager, where the media from the SIP trunk is terminated. MTP may or may not be required depending on the specific versions of Call Manager and Cisco devices used. For details on the use of the MTP please refer to Cisco’s documentation.
While this is not a requirement, we are assuming in this chart and in most of the explanations below that all PSTN interconnectivity is handled by the IP-PBX. Calls from the PSTN to Office Communications Server Enterprise Voice users will first be presented to the IP-PBX which will then pass them onto Office Communications Server across the SIP trunk. That is the most common deployment case for pilots or small scale deployments; for larger deployments it may be preferable for each system to handle its own PSTN interconnection directly, and reserve the Direct SIP interconnection to the exchange of calls between users of the two systems.
The changes are targeted at facilitating interoperability with an IP-PBX that, in its SIP messages across the SIP trunk, presents and receives dial strings. These dial strings might be E.164 numbers without a “+”, or any other set of dial strings such as extensions.
Because of the requirements for the SIP messages across the SIP trunk to not include the “+”, appropriate dial strings need to be used by the Office Communications Server Mediation Server when interacting with the IP-PBX. However the core internal logic of Office Communications Server with respect to phone numbers has to be preserved, in order to not disrupt a range of typical Office Communications Server scenarios such as publishing contact information within the presence document. Therefore the Mediation Server will play a critical role in this scenario.
The changes introduce the capability for Office Communications Server to normalize the FROM header so that a non-RFC3966 representation of an E.164 number (i.e. an E.164 number without a “+”) is converted to an RFC3966 conforming global number and is placed in the “P-Asserted-Identity” (PAI) header field. The PAI header enables the user lookup functionality in Office Communicator. If the normalization process does not result in a global number, Office Communications Server will add a Phone-Context value of "enterprise” in the PAI header. Additionally, Office Communications Server bypasses the server normalization logic if the REQUEST URI header already contains a Phone-Context value of "enterprise."
In summary, when the value of “RemovePlusFromRequestURI” is set to “YES”:
For outgoing calls (calls from the Mediation Server to the IP-PBX):
For incoming calls (calls from the IP-PBX to the Mediation Server):
Additionally, in environments where phone numbers in the Active Directory are entered as dial strings representing E.164 numbers without a “+”, these numbers will be converted to RFC3966 compliant global numbers, represented as TEL URI by the Address Book Service. The Address Book normalization rules will be used to convert these numbers into RFC3966 compliant numbers. Office Communications Server users in such scenarios will always have the “RTCSIP-Line” parameter configured with an RFC3966 compliant TEL URI.
As mentioned previously, those changes are not applied by default by just running the updates for Office Communications Server 2007. Administrators must also perform configuration steps and add the appropriate normalization rules. Configuration is also required on the IP-PBX side to set up the SIP trunk, as well as to normalize numbers as necessary.
To setup the Direct SIP with IP-PBX interoperability, we must first understand the dial plan and normalization rules on the IP-PBX side, and make decisions on the number range allocation between Office Communications Server and the IP-PBX. The next step is to provision and configure the SIP trunk from the IP-PBX to the Mediation Server. Last, we will setup Office Communications Server, starting with Mediation Server and adding the appropriate location profile(s) and normalization rule(s).
Enterprises’ dial plans vary broadly. Therefore each implementation will be somewhat unique, and the examples given here are not meant to cover every case.
Small or medium size enterprises (especially single-site ones) typically will have a pre-existing internal dial plan based on short dialing extensions (generally 3 to 5 digits). Users are accustomed to dialing the short extensions to reach internal users and to dialing a prefix (such as 9 or 0) prior to dialing numbers external to the enterprise.
To reach an internal user from the PSTN, outside callers have to dial a DID (Direct Inward Dialing) number, which is a publicly routable number corresponding to the extension of the user to reach. The IP-PBX will already be configured with the appropriate transformation rules to convert the DID requested to the corresponding extension, generally by striping the appropriate number of leading digits, and placing the result in the TO field. For example a DID of 14257771234 would be converted to the extension 1234.
This conversion however is only applied to the TO field (aka Called ID or called number) of the call. The FROM field (aka Caller ID or caller number) is commonly either left unchanged from what the operator provided, or transformed into a dial string that enables simple callback to the original caller. For example, for an IP-PBX located in the United States, a US Caller ID of 14259991234 may be converted to 914259991234, and a French Caller ID of 33169861234 may be converted to 901133169861234, where 9 is the prefix for external dialing on the IP-PBX and 011 the carrier mandated international dialing prefix in the US. It can take a large number of rules on the IP-PBX to cover all possible cases, and those rules vary based on what numbering format the operator will present and require.
Larger enterprises that use extensions generally need either much longer extensions (sometimes as long as 6 or 7 digits) or internal prefixes for site to site dialing. This situation creates a risk of overlap, where a dial string received as Caller ID could be identical to a dial string representing an internal route or user. For that reason, large enterprises almost always implement Caller ID transformation rules such as the ones described above (the exception is large enterprises that use E.164 numbering internally instead of extensions).
This of course determines the format in which the IP-PBX will pass TO and FROM dial strings to Office Communications Server and what normalization rules will be required on Office Communications Server. In most cases, it should be expected that the IP-PBX will present to Mediation Server the following:
For calls from an IP-PBX user to an Office Communications Server user:
For calls from the PSTN to an Office Communications Server user:
Therefore Office Communications Server should be provisioned with the appropriate normalization rules in particular to handle the various dial strings formats in the FROM field.
Conversely, in virtually all cases it should be expected that the Mediation Server will present the following to the IP-PBX:
Therefore the IP-PBX should be provisioned with the appropriate translation rules to transform these strings into the appropriate formats for the IP-PBX and the PSTN.
The simplest case for number range allocation is where specific ranges are dedicated to one or the other system. For example, in a four-digit extension plan, all extensions of the pattern 4xxx or 5xxx would be assigned to Office Communications Server and all other extensions would be assigned to the IP-PBX. Where possible, allocating ranges is preferable in order to simplify provisioning of users and routing patterns.
There are cases where simply allocating ranges is not possible. This can be because no unused range is available, or because users must retain their original DID as they migrate to Office Communications Server Enterprise Voice. In the case where all PSTN interconnectivity is handled by the IP-PBX as explained above, not allocating ranges does not change the way in which Office Communications Server is set up; all adjustments will have to be made on the IP-PBX. Typically that involves redirecting each DID from the IP-PBX to Office Communications Server. In our example hereafter we will show how that can be achieved.
In this post we have explained what Direct SIP with IP-PBX means, and how the recently announced changes to Microsoft Office Communications Server will make it easier. In our next blog post, we will provide an example of setting up Direct SIP with IP-PBX.