No Name Appears When Callings from OC to Cisco or vice versa

One of the frustrating drawbacks when Implementing OCS enterprise voice integrating with Cisco Call Manager or other PBX is that No name would appear in Communicator 2007 when a telephone user calls a Communications Server 2007 user or vice versa .

The only solution by then was to place a media gateway in the middle between mediation and IP-PBX and use a translation feature built in the media gateway to edit the packet header and add Caller Name before sending it to the PBX.

But Finally Microsoft has listened to my prayers and they have released July fix for OCS 2007 R2, once they were released our team started to do the testing in our LABs. At the beginning things didn’t work fine but in the end it worked and it appeared that we only applied the server side updates while the KB 971844 includes Office Communicator update too.

However, even with these fixes, this don’t send display name by default. So, this configuration in KB 972721 will be also necessary. Below are the snapshots taken by our Engineer Amr Nassar who has worked on this and successfully made it work after applying those Fixes.

Calling from Office Communicator R2 with ext 6000 to Cisco IP Phone with ext 10000

Calling from  Cisco IP Phone with ext 10000 to Office Communicator R2 with ext 6000 

But let me also share Microsoft explanation on why this problem happens in the first place and what these updates fix?

Problem Explanation:

When a Private Branch Exchange (PBX) telephone user calls a Microsoft Office Communications Server (OCS) 2007 R2 user, the calling party name that exists in PBX is stripped at the OCS 2007 R2 Mediation Server. Because the PBX telephone user does not exist in Active Directory, no name appears in Microsoft Office Communicator 2007 R2

This problem occurs because the OCS 2007 R2 Mediation Server does not forward the display name information from the Unified Communications (UC) side to the gateway side. Therefore, the Communicator 2007 R2 client does not receive the display name information.

Update 970679 introduces functionality for the Mediation Server role of Communications Server 2007 R2 to forward Display Name information that is part of the From header between its gateway side and its proxy side.

A file called MediationServerSvc.exe.config should be created in the Mediation Installation Directory which be default is at  %programfiles%\Microsoft Office Communications Server 2007\Mediation Server

This file should contain.

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
                 <appSettings>
                                <add key=”forwardDisplayName” value=”True” />
                 </appSettings>
</configuration>

Setting up the Cisco Call Manager 4.2.1 with Ofice Communication Server 2007 “Part Two – OCS 2007 Side”

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 2^nd edition will of course reflect the next release of Office Communications Server. We highly recommend it!

Setting up the Cisco Call Manager 4.2.1 with Ofice Communication Server 2007 “Part One – Cisco Side”

 configuration of Direct SIP with Cisco Call Manager 4.2.1.

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 Communications Server; that is of course possible but exceeds the scope of this simple example.

·         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:

o   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

o   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:

o   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

o   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.