Mino – The UC Guy

Microsoft Unified Communications Blog

Archive for the ‘Cisco 4.x Integration’ Category

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

Posted by Mino on August 10, 2009

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

From OCS

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

From Cisco

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>

Posted in AVAYA, Cisco 4.x Integration, Cisco 5.x Integration, Cisco 6.x Integration, Cisco 7.x Integration, communicator client, Mediation Server, Nortel CS1000, OCS 2007 R2, PBX Integration, Phone Edition, Quintum's gateways | Tagged: , , , , , , , , , , , , , , | 3 Comments »

How to Integrate Exchange UM Voicemail into Cisco IP Phones

Posted by Mino on March 27, 2009

I am working with a client who is using Cisco CUCM with Cisco Phones, along with Microsoft Exchange 2007 voice mail on the UM , but when you divert the phone to voicemail you are not prompted with the users voicemail prompt – you are prompted with the Subscriber access greeting of “ Welcome , you are connected to Microsoft exchange ,…etc )

Usually when you call someone and there is no answer then you are transferred to the Pilot number, the extension of the person you are calling is sent also in the request so that you would be directly transferred to the users voice mail not to the Welcome greeting.

This Problem Happens when Diverted Calls are not accepted because both sides cannot agree on DTMF handling , the MTP is important, because it deals with differences in how DTMF is signaled between the phones and gateways and the sip trunk

Just make sure the following on the Cisco SIP trunk:

  1. Accept Out-of-Dialog REFER
  2. Accept unsolicited Notification
  3. Accept Replaces Header
  4. Have the SIP trunk configured to use MTP, once I’d configured MTP and MRG/MGRL

The changes detailed below are based on a new installation of Call Manager 5. As this environment been created for the purpose of testing the integration between platforms, it contains only minimum configuration. The required Changes are with:

·         Media Termination Point (MTP)

·         Changes to security profile

Media Termination Point: The Cisco Call Manager installation builds the default media termination point.

Media Resource Group: Create a media resource group “MRG_CCM5” and add the media resource (MTP) to the group. Multicast is not required.

Media Resource Group List: Create a media resource group list “MRGL_CCM5” and add the media resource group “MRG_CCM5” to the list.

Device Pools: By default Cisco Call Manager creates the “default” device pool. Open the device pool “default” and select the new media resource group list “MRGL_CCM5”.

SIP Trunk Security Profiles: Copy the “Non Secure SIP Trunk Profile” to “E2K7 Non Secure SIP Trunk Profile” and enable “Accept Unsolicited Notifications”.

Partition Configuration: Create a Class of Control Partition “Local”.

Calling Search Space: Create a Class of Control Calling Search Space “CCS_Local” and add the Partition “Local” to the calling search space.

Trunk Configuration:

Trunk Configuration

General

Setting

Device Name

E2K7

Description

Exchange UM

Device Pool

Default

Call Classification

Use System Default

Media Resource Group List

<None>

Location

Hub_None

AAR Group

<None>

Packet Capture Mode

None

Packet Capture Duration

0

Media Termination Point Required

Enabled

Retry Video Calls as Audio

Disabled

Transmit UTF-8 for Calling Party Name

Disabled

Unattended Port

Disabled

MLPP Domain Information

<None>

   

Trunk Configuration
Call Routing Information

Setting

Inbound Calls

Significant Digits

All

Connected Line ID Presentation

Default

Connected Name Presentation

Default

Calling Search Space

CCS_Local

ARR Calling Search Space

<None>

Prefix DN

<Blank>

Redirecting Diversion Header Delivery

Disabled

Outbound Calls

Calling Party Selection

First Redirect Number

Connected Line ID Presentation

Default

Connected Name Presentation

Default

Caller ID DN

<Blank>

Caller Name

<Blank>

Redirecting Diversion Header Delivery

Enabled

Trunk Configuration

SIP Information

Setting

Destination Address

<IP Address of E2K7 Server>

Destination Address is an SRV

Disabled

Destination Port

5060

MTP Preferred Originating Codec

711alaw

Presence Group

Standard Presence Group

SIP Trunk Security Profile

E2K7 Non Secure SIP Trunk Profile

Rerouting Calling Search Space

<None>

Out-of-Dialog Refer Calling Search Space

<None>

SUBSCRIBE Calling Search Space

Default

SIP Profile

Standard SIP Profile

DTMF Signalling Method

No Preference

Posted in Cisco 4.x Integration, Cisco 5.x Integration, Cisco 6.x Integration, Cisco 7.x Integration, Good Articles take from Other Blogs, OCS & Exchange07, Unified Messaging | Tagged: , , , , , , , , | 8 Comments »

How to enable inbound fax for OCS 2007 Enterprise Voice and Exchange 2007 UM enabled users?

Posted by Mino on March 9, 2009

Any Post starting with this disclaimer means that this post was not written by me however I have liked it and added to my blog. I will also include the link to the original or Similar post to provide credit to the original author.

http://blogs.technet.com/jenstr/archive/2007/11/13/how-to-enable-inbound-fax-for-enterprise-voice-and-exchange-2007-um-enabled-ocs-2007-users.aspx

Exchange 2007 SP1 UM supports both voice mail and incoming fax to a given extension. However, if the user is both UM-enabled and enabled for Enterprise Voice using OCS 2007, incoming fax is not supported using the same extension. The reason being that OCS 2007 Mediation Server does not currently support T.38.

How is it possible to provide incoming fax support for Enterprise Voice enabled users? The answer is to use a separate extension for fax and route fax calls to this extension directly to Exchange 2007 SP1 UM outside of OCS 2007.

Let’s assume we have a company called Contoso with the environment shown below and we will use that company to explain the issue and the solution

12

The OCS 2007 environment is connected to the PBX via a SIP/PSTN gateway called PSTNOCSGWY. The PBX routes all calls to the DID range +131255xxxxx to OCS 2007. OCS 2007 is integrated with the Exchange 2007 SP1 UM server called UMSRV1. It hosts a UM Dial Plan called OcsUmDialPlan of UriType = SipName (required for OCS 2007 integration). There is a UM Mailbox Policy associated with this UM dial plan called OcsUm. Exchange 2007 SP1 UM is connected to the PBX via OCS 2007.2

The Contoso user Test User is enabled for Enterprise Voice with the DID +13125510001 and SIP URI TestUser@contoso.com. His extension is 10001. His Enterprise Voice configuration is shown below.

 

 

To be enabled for Exchange 2007 SP1 UM the administrator would issue the following Exchange Management Shell command:

Enable-UmMailbox -id TestUser -UmMailboxPolicy OcsUmPolicy -Extensions 10001 -SIPResourceIdentifier TestUser@contoso.com -Pin 1234

Test User is now enabled for Exchange 2007 SP UM, but will not be able to receive incoming fax on extension 10001 or DID +13125510001.

As indicated above the solution is to give Test User a separate extension for fax and the extension needs to be routed to Exchange 2007 SP1 UM directly without going through OCS 2007. Contoso will therefore have to create a configuration as shown below. There is a dedicated SIP/PSTN gateway for connectivity to Exchange 2007 SP1 UM. The PBX routes the DID range +131266xxxxx to this SIP/PSTN gateway. There is a new UM Dial Plan called UmDialPlan with UriType=TelExtn. There is a UM Mailbox Policy associated with this UM dial plan called Um. The UM server UMSRV1 hosts both UM Dial Plans.

The administrator now decides that Test User should have the extra extension 11001 and DID +13126611001 as the fax number.

To enable Test User to receive fax the administrator need to issue the following Exchange Management Shell command:

Set-Mailbox -id TestUser -SecondaryAddress 11001 -SecondaryDialPlan UmDialPlan

With the above configuration Test User is now able to receive fax on DID +13126611001.

3

Posted in AVAYA, Cisco 4.x Integration, Cisco 5.x Integration, Cisco 6.x Integration, Cisco 7.x Integration, Mediation Server, Nortel CS1000, OCS & Exchange07, OCS 2007 R2, PBX Integration, Quintum's gateways, Unified Messaging | Tagged: , , , , , , , , , , , , , , , , | 13 Comments »

Office Communications Server and the Contact Center

Posted by Mino on March 4, 2009

Any Post starting with this disclaimer means that this post was not written by me however I have liked it and added to my blog. I will also include the link to the original or Similar post to provide credit to the original author.

https://blogs.pointbridge.com/Blogs/mcgillen_matt/Pages/Post.aspx?_ID=58

One of the best places to add value to an organization is in the way contacts with customers or partners is handled. For many – this is the call center / contact center. This is how sales are made, support tickets are resolved, new customers are discovered, current customers are retained

Also we as LINK Development were able to integrate these new Contact center features with Microsoft CRM server to provide end to end Helpdesk Contact center solution on the Call handeling and on the Backend activity system.

crm11

 

crm21

There are several new features that can be used for call routing. I thought I’d build a matrix to keep it straight:

R2 Feature Description Ease to Deploy Admin Control Deployment Options
Call Delegates Have an admin answer calls for you, or multiple people Very Easy End User Controlled Built in to OCS R2 client – point and click interface
Team Call Have calls ring a group of users simultaneously Very Easy End User Controlled Built in to OCS R2 client – point and click interface
Basic Hunt Group Ring a group of users in various methods: longest available, circular, serial, round-robin etc. Easy OCS Admin can delegate mgmt. to any user Configured in OCS console, managed via web interface
Enhanced Hunt Group Same as above, but with Welcome Message & Open/Closed Hours Easy OCS Admin can delegate mgmt. to any user Configured in OCS console, managed via web interface
Response Groups Call queueing, music on hold, text-to-speech, speech recognition, open/closed hours Medium OCS Admin can delegate mgmt. to any user Configured in OCS console, managed via web interface
IVR / Speech applications   Somewhat Complex OCS Admin Using the UCMA 2.0 SDK, write “drag-and-drop” Windows Workflow applications / .Net applications
Enterprise Contact Center Functionality Write your own contact center workflows Complex OCS Admin Using the UCMA 2.0 SDK, write “drag-and-drop” Windows Workflow applications / .Net applications

 

IVR / Contact Center Applications with the UCMA 2.0 SDK

This is by far the most exciting feature of OCS R2. MS is giving away the toolkit (the Unified Communications Mangaed API aka UCMA SDK) to write your own IVR apps and contact center apps: anyone with an IM client can be an “agent”! No additional licensing necessary. This is going to change the way people do contact centers.

Posted in AVAYA, Cisco 4.x Integration, Cisco 5.x Integration, Cisco 6.x Integration, Cisco 7.x Integration, Nortel CS1000, OCS 2007 R2, PBX Integration, Quintum's gateways | Tagged: , , , , , , , , , | 1 Comment »

How to strip “Remove” the + from all outgoing SIP communication from an OCS Mediation server ?

Posted by Mino on October 13, 2008

It might be useful in a Cisco direct SIP environment to automatically strip the + from all outgoing SIP communication from an OCS Mediation server.

To do this, create a text (XML) file called MediationServerSvc.exe.config and place it in the location of the MediationServerSvc.exe file. It should be in the ‘C:\Program Files\Microsoft Office Communications Server 2007\Mediation Server’ directory. The contents of this file should be:

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

Now, you are free to normalize to E.164 without having to worry about your Cisco devices getting confused!

Srouce : http://jimraymond.wordpress.com/ 

Posted in Cisco 4.x Integration, Cisco 5.x Integration, Cisco 6.x Integration, Mediation Server, Miscellaneous, Nortel CS1000, PBX Integration, Quintum's gateways | Tagged: , , , , , , , , , | 2 Comments »

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!

Posted in Cisco 4.x Integration | Tagged: , , , , | 3 Comments »

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

Posted by Mino on October 7, 2008

 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.

Posted in Cisco 4.x Integration | Tagged: , , , , | Leave a Comment »