Mino – The UC Guy

Microsoft Unified Communications Blog

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

Posted by Mino on October 7, 2008

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!

Advertisements

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

  1. Mark said

    Thanks for the article. I have an issue you may be able to help with. I have created a new Location profile and assigned it to the mediation server. When I make a call from CUCM to OCS I see that the Mediation server appends the Location profile in the To and From fields. I then see that the Translation service normalizes the Called Number but not the Calling Number. Both these numbers should match agains the same normalization rule. I’ve made sure I have all the necessary patches. any suggestions?

  2. Mino said

    i dont know if I understood you right or not but when i tested this in my LAB without Media gateway , i found that whenever i try to call from the Communicator client to the Cisco IP phone I still get a Number rather than a name , and vise versa …i was never able to see the name between both clients.
    but whenever i use a media gateway in the Midle ” Quintum ” the translation happens right and i can see the name in both directions.

    i traced the OCS logs and i still can see that the Mediation server sends the + in the traffic although i did everything as per microsoft said.
    i confirmed with one of my friends working by the Media gateway and he told me this is a well known issue and it is fixed by using the Media gateway in the middle .

    if you have moer updates please let me know

  3. Adam said

    How do you pass the external caller ID from the PSTN to OCS? I have followed your instructions exactly and the caller ID that shows up on the communicator is an internal extension. I have a CCM 4.2 and I am running an OCS 2007 R2 Enterprise. When a call comes in we have a call processor in CallXpress that gives options to transfer the call. I enter in an OCS extension that should transfer me to a communicator and it does, but I see a CX extension instead of the external caller-ID. If I call a standard phone the same way, I can see the external ID, so it seems like it has to be something on the CM side. Any ideas?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: