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


1) Main assumptions for the example

Here are the main assumptions for this example:

  • This is a single site, located in Paris, France (country code 33, local code 1).
  • All PSTN calls, incoming and outgoing, from and to Cisco Call Manager and Office Communications Server, use the preexisting PSTN interconnection trunks that are connected to and managed by the Cisco Call Manager. All calls to and from Office Communications Server go across the SIP trunk between Cisco Call Manager and Mediation Server.
    As discussed before, it is also possible (and eventually more effective, especially at large scale and for example with the use of SIP Trunking to Carrier) to have direct PSTN-out routes from Office Communications Server to the PSTN without going through the Cisco Call Manager. Also, in this example, we do not implement redundant routes between Cisco Call Manager and Office.
  • All users are assigned a unique, externally routable DID from a local range and a unique 4 digits extension that matches their DID’s last 4 digits.
  • Specifically all DID for users on both the Cisco Call Manager and Office Communications Server are of the format +3316986xxxx where xxxx is their extension.
  • Users on the Cisco Call Manager are accustomed to dialing 4 digits for internal users, and we want to maintain that pattern when they dial out to users on Office Communications Server.
  • Users on the Cisco Call Manager need dial 0 as prefix to exit to the PSTN.
  •  In the first part of this example, the extension range 4xxx to 5xxx is allocated to Office Communications Server; in the advanced section, we will provide a configuration for situations where there are exceptions to the range allocation.
    We do not assume that all numbers in the range are actually allocated on Office Communications Server; calls to unallocated numbers will be routed by Cisco Call Manager to Office Communications Server which will answer 503 (service unavailable) and reject the call, which will receive a “fast busy” dial tone.
  • All other numbers are allocated to the Cisco Call Manager; it is of course possible, but beyond the scope of this example, to create more complex, granular route patterns.

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:

  • The FROM field must be formatted as a 9-digit dial string xxxxxxxxx
  • The TO field:
    • For domestic (i.e. destined to a DID in France) calls: the TO field must be formatted as a full 10-digit local French number (which is not an E.164 number): 0xxxxxxxxx
    • For international calls (i.e. destined to a DID outside of France): the TO field must be formatted as a 00 (the prefix for international dialing in France) followed by the E.164 dial string for the caller, for example 0014255551212
  • Please note that this may vary by locale, carrier or even on the basis of the type of trunk used; please check appropriately.


For calls from a Cisco Call Manager extension xxxx to an Office Communications Server extension yyyy sent across the SIP trunk:

  • The FROM field is the dial string xxxx
  • The TO field is the dial string yyyy.

For calls from the PSTN to an Office Communications Server extension yyyy:

  • The FROM field has already been formatted by Cisco Call Manager into a dial string that enables immediate dial back to the PSTN in France:
    • For domestic (i.e. originated from a DID in France) calls: the “outside line prefix” 0 followed by the full ten-digit local French number (which is not an E.164 number): 00xxxxxxxxx
    • For international calls (i.e. originated from a DID outside of France): the “outside line” prefix 0 followed by 00 (the prefix for international dialing in France) and by the E.164 dial string for the caller, for example 00014255551212
  • The TO field is the dial string yyyy.

2) Creating a partition on Cisco Call Manager

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.

3) Creating a Calling Search Space on Cisco Call Manager

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.

4) Setting up Translation Patterns for the Partition on Cisco Call Manager

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.

5) Provisioning the SIP trunk on Cisco Call Manager

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:


6) Setting up a Route Pattern for the SIP trunk on Cisco Call Manager

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.


 

7) Setting up Office Communications Server for “Direct SIP with IP-PBX”

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 Server
In 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 profile
At 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 rules
We 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 range
The 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 extension
The 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 prefix
The 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.

 

 
Conclusion

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!

Lync Server Resources

We Want to Hear from You