Lync Server Support Home
Top Lync Solutions RSS Feed
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
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.
In our previous post, we introduced changes in Office Communications Server to enable Direct SIP with IP-PBX such as Cisco Call Manager. In this simple example, we provide a configuration of Direct SIP with Cisco Call Manager 4.2.1.
Author: Francois Doremieux, Jerome Berniere
Publication date: September 2008
Product version: Office Communications Server 2007 R2
Here are the main assumptions for this example:
We are also making the following assumptions for the formatting of the FROM and TO fields of calls:
The local PSTN carrier requires the following:
For calls from a Cisco Call Manager extension xxxx to an Office Communications Server extension yyyy sent across the SIP trunk:
For calls from the PSTN to an Office Communications Server extension yyyy:
First we will create a partition, which we name “OCSIncoming”.
A Cisco Call Manager partition contains a list of route patterns. Partitions facilitate call routing by dividing the route plan into logical subsets that are based on organization, location, and call type. For more information about partitions, please refer to "Partitions and Calling Search Spaces" in the Cisco Call Manager System Guide.
This partition will enable us to apply specific rules (route patterns and translation patterns) specific to the incoming traffic into the Cisco Call Manager from the Mediation Server across the SIP trunk.
Note: whether a partition is required or not in a particular environment may depend on the rules required. Please verify with your Cisco Call Manager administrator.
A Cisco Call Manager calling search space is an ordered list of route partitions. Calling search spaces determine which partition(s) (and in which order) are searched when Cisco Call Manager is attempting to complete a call.
In this case, we create a calling search space which we call "OCSIncoming", and to which we assign the "OCSIncoming" partition created above.
Next we create translation patterns for the partition. The translation patterns will be used for inbound calls to the Cisco Call Manager from Office Communications Server. Translation patterns manipulate dial strings before routing a call.
The first translation pattern (called [^33]!, which means TO strings that do not start with 33) will handle all calls from Office Communications Server that are destined to an international PSTN number. Note that the translation pattern is assigned to the “OCSIncoming” partition.
For the FROM field: the pattern retains the last 9 digits; therefore it strips the country prefix (which is always 33 in this case) from the E.164 calling party dial string, and presents it to the PSTN in the required format. In this case it transforms 3316986xxxx into 16986xxxx.
For the TO field: the pattern simply adds 000 as a prefix to the called party dial string. For example it transforms 14255551212 into 00014255551212.
The reason it translates dial strings sent by the Mediation Server in a different manner for the TO and the FROM is the need for the TO field to start with the outside line prefix (in this example “0”) to obtain an outside line on the Cisco Call Manager, then the international prefix 00, and then the full E.164 dial string.
The second translation pattern (called 33.xxxxxxxxx, which means TO strings starting with 33 followed by 9 digits) will handle all calls from Office Communications Server that are destined to a domestic PSTN number. Here too the translation pattern is assigned to the “OCSIncoming” partition.
For the FROM field: as for the previous translation pattern, we retain the last 9 digits, stripping the country prefix (which is always 33 in this case) from the E.164 calling party dial string, and presenting it to the PSTN in the required format. In this case it transforms 3316986xxxx into 16986xxxx.
For the TO field: the pattern strips the leading 33 (i.e. the digits prior to the dot) and adds 00 as a prefix to the remaining string. It transforms 33xxxxxxxxx into 00xxxxxxxxx, where the first 0 is the outside line prefix needed to obtain an outside line on the Cisco Call Manager.
The third translation pattern (called 3316986xxxx) will handle all calls from Office Communications Server that are destined to a Cisco Call Manager assigned number. Here again the translation pattern is assigned to the “OCSIncoming” partition. This pattern will be applied to calls where the TO field is of the form 3316986xxxx, rather than the second translation pattern, because it represents a longer match. Cisco Call Manager selects translation patterns from a list on the basis of the longest match.
The translation pattern translates dial strings for calls sent by the Mediation Server where the TO field matches the pattern. It strips all leading digits from TO and FROM fields to retain the last 4 digits of both. Dial strings of the pattern 3316986xxxx will be translated to dial strings of the form xxxx that match the internal Cisco Call Manager dial plan. As can be seen below, this translation will be performed on both the called number and the caller number.
Other translation patterns could be set up if appropriate, for example for normalization of emergency number, but are outside the scope of this example.
At this time we will set up a SIP trunk on the Cisco Call Manager, and assign the Calling Search Space for incoming traffic we created previously, “OCSIncoming”.The trunk name in this example is “Trunk_to_OCS”. The Mediation Server’s external edge IP address here is 192.168.0.105. Please note the selection of TCP for transport, and the port selection:
Route Patterns are used for outbound calls from Cisco Call Manager to Mediation Server. They define what calls are sent to the SIP trunk based on matching the number in the TO field with a specific pattern. Route Patterns can also perform transformations of the dial strings in both the TO and the FROM field.
We now create a route pattern [4-5]xxx to handle outgoing calls from Cisco Call Manager to Office Communications Server, associated with the “Trunk_to_OCS” SIP trunk. This Route Pattern instructs Cisco Call Manager to route to Mediation Server all calls destined to Office Communicator users (from both the PSTN and Cisco Call Manager users), on the basis of the match of the TO string with the pattern [4-5]xxx. In this case we do not need any transformation of the strings in the TO and the FROM fields.
Setting up Office Communications Server for Direct SIP with IP-PBX involves configuring the Mediation Server; creating a specific Location Profile with a Normalization Rule for the Mediation Server; and defining a Phone Route to route calls to Cisco Call Manager 4.2.1 through the SIP trunk.
Configuring Mediation ServerIn this example, the Mediation Server’s outside edge’s IP address is 192.168.0.105, and the Cisco Call Manager’s IP address is 192.168.0.110 (the Cisco Call Manager listens by default on its server IP address).
The Cisco Call Manager’s IP address is inserted in the “PSTN Gateway next hop” section of the “Next Hop Connections” tab in the “Properties” dialog. Please note the selection of the ports, corresponding to the selection made on the SIP trunk.
Note the selection of a default location profile for the Mediation Server (in this example the location profile is called “Paris-LP.mocs2007.fr”). This location profile will be edited later in this configuration process.
Configuring voice routing: modifying Mediation Server default location profileAt this point, we edit the location profile used by the Mediation Server, “Paris-LP.mocs2007.fr”, to include the appropriate normalization rule(s) for the SIP trunk. In this case, we will add/edit the normalization rules “Internal number NR”, “International” and “National”.
Configuring voice routing: creating normalization rulesWe now create normalization rules to normalize the dial strings coming across the SIP trunk from Cisco Call Manager into Office Communications Server. In this example we create “Internal number NR”, “International” and “National”.
“Internal number NR” transforms a 4-digit dial string xxxx into an RFC3966 compliant global number +3316986xxxx. The rule will be applied to inbound traffic to Office Communications Server from the Cisco Call Manager. The phone pattern regular expression in this scenario is ^([0-9]{4})$, and the translation pattern regular expression is +3316986$1.
Because of the Route Pattern configuration for the SIP trunk as we set it up above, calls that are passed to Mediation Server must have a TO field that matches the route pattern [4-5]xxx (and as a result the dial string xxxx). Therefore the normalization rule “Internal number NR” will translate the TO field to RFC3966 global numbers that should match Enterprise Voice enable users of Office Communications Server.In addition, calls that are passed to Mediation Server across the SIP trunk may have a FROM field that matches the dial string xxxx. This will be the case when the calls have been dialed from an extension of the Cisco Call Manager. The normalization rule will also translate that FROM field to an RFC3966 global number, enabling querying against Active Directory for the name and SIP URI of the dialer. When the dialer is a user of Office Communications Server for Instant Messaging and Presence, having their SIP URI enables advanced scenarios; for example the call recipient could redirect the incoming phone call to reply with an Instant Message.
Last, the normalization rule can also used if users dial a 4-digit dial string in Office Communicator. The rule will normalize that dial string into a global number. If that number can be matched against a UC enabled user’s phone number, then it will be associated to a SIP URI and routed within Office Communications Server. If there is no match, the call will be routed to the appropriate external route – in our case to the Cisco Call Manager.
“International” transforms a dial string that starts with 000 into an RFC3966 compliant global number by stripping the 000 and adding a “+”. The rule will be applied to inbound traffic to Office Communications Server from the Cisco Call Manager. The phone pattern regular expression in this scenario is ^000(d\*)$, and the translation pattern regular expression is +$1.
For calls passed by Cisco Call Manager across the SIP trunk, only the FROM field should contain dial strings that start with 000. This will be the case when the calls have been dialed by a PSTN user outside of France, after the Cisco Call Manager has added the prefix 0. The normalization rule will translate that FROM field to an RFC3966 global number for use by Office Communications Server.
“National” transforms a dial string that starts with 00 followed by 9 digits into an RFC3966 compliant global number by stripping the 00 and adding a “+33”. The rule will be applied to inbound traffic to Office Communications Server from the Cisco Call Manager. The phone pattern regular expression in this scenario is ^00(d\{9})$, and the translation pattern regular expression is +33$1.
For calls passed by Cisco Call Manager across the SIP trunk, only the FROM field should contain dial strings that start with 00. This will be the case when the calls have been dialed by a PSTN user in France, after the Cisco Call Manager has added the prefix 0. The normalization rule will translate that FROM field to an RFC3966 global number for use by Office Communications Server.
Advanced case: setting up support for numbers outside of the rangeThe following steps provide a way to support migrating users from Cisco Call Manager to Office Communications Server without having to change their original extension to a new one taken from the contiguous range of numbers allocated to Office Communications Server. That is a frequent case for VIP or externally facing users whose phone number is broadly known outside of the organization. This can also be used as the general case when no dedicated range has been allocated to Office Communications Server.
This is simply achieved by creating a “Forward All” setting of the extension line (say extension 6668) to a prefixed line, for example 96668; and by creating a new route pattern on the SIP trunk to match strings of the 9xxxx pattern, strip the 9, and redirect to extension 6668 on Office Communications Server.
Setting up the Forward All for the extensionThe following steps set up Forward All on the IP Phone line extension 6668 to 96668: the prefix 9 will be used to reroute that extension to Office Communications Server. Note the Forwarded Call Information.
Creating a Route Pattern associated with the prefixThe following steps create a route pattern to reroute all traffic with the 9xxxx pattern (i.e. with the 9 prefix) to the SIP trunk to Office Communications Server. The prefix will be stripped (as indicated by the Called Party Transform Mask) and the call redirected to extension 6668 on Office Communications Server.
In this post we have shown a simple example of setting up Direct SIP with IP-PBX, between Office Communications Server and Cisco Call Manager 4.2.1. As always, your specific situation may vary, and we recommend checking for updated information, as well as thorough lab testing, prior to production deployment.
Acknowledgment
We would like to acknowledge the contributions of our friend Rui Maximo, who has greatly helped us in preparing these two blog posts. The content of these posts is excerpted from the upcoming 2nd edition of the Resource Kit book, effort that Rui is leading. The 2nd edition will of course reflect the next release of Office Communications Server. We highly recommend it!