Home > Lync > Integrating Microsoft Lync and Cisco Unified Communication Manager Part 4: Remote Site Scenario

Integrating Microsoft Lync and Cisco Unified Communication Manager Part 4: Remote Site Scenario

In this post I will discuss integrating the remote site which traditionally has been a Cisco site with a Cisco gateway. Cisco remote site configurations can be done a couple different ways:

  • Gateways can be configured with their own dial plan and send calls destined for Cisco Unified Communications Manager via H.323 or SIP trunks

    OR

  • Gateways can be controlled via Media Gateway Control Protocol (MGCP) which means call control is maintained at the central Cisco Unified Communications Manager versus local on the gateway. This is done to provide centralized administration of configuration and a centralized dial plan.

It is common to see SIP or H.323 trunks at some branch offices while others are MGCP in an environment.

The gateways in our scenario will utilize MGCP; if we utilized SIP trunks it would simplify our Lync environment but possibly complicate our CUCM environment. We will create a fictitious main office in Detroit with branch offices in Chicago and New York, the diagram below is a simple representation of the environment with each office connected via MPLS for Data and each has local connections to the PSTN via ISDN-PRI lines. We have a significant investment in hardware at remote sites already with Cisco gateways and we are not interested in purchasing additional gateway devices.

 

Each of our remote sites contains a Cisco gateway with hardware MTP resources configured per Part 2 of this series. In addition, to provide local survivability and media bypass for Lync users we have deployed a Survivable Brand Server (SBS) to each site. The SBS will be the primary registrar for the remote users who will also have a backup registrar of the regional pool in Detroit.

Cisco UCM Configuration:

  • First, we need to create a Media Resource Group List that contains the MTP resources we created on the branch office gateway. We will call those MRGLs Chicago_MRGL and NY_MRGL.
  • Next, a SIP trunk needs to be created with the following settings to each of the branch office sites:

Device Name

ChicagoTrunk

Device Pool

Chicago

Media Resource Group List

Chicago_MRGL

MTP Required

Yes

Destination Address

10.99.10.10 (IP of SBS)

Destination Port

5068

SIP Trunk Security Profile

Non Secure SIP Trunk Profile

SIP Profile

Standard SIP Profile

 

Device Name

NYTrunk

Device Pool

NewYork

Media Resource Group List

NY_MRGL

MTP Required

Yes

Destination Address

10.98.10.10 (IP of SBS)

Destination Port

5068

SIP Trunk Security Profile

Non Secure SIP Trunk Profile

SIP Profile

Standard SIP Profile

 

  • Now we need to create a route pattern. In our example our NY office has the 4 digit extension range 5500-5999 and the last 100 will go to Lync. So our route pattern will be 59xx. In Chicago it will be 55xx to send the range 5500-5599.

Our resulting configuration will look something like this:

There is also a known issue in Cisco Unified Communications Manager that as far as I can tell affects configurations running on CUCM version 6.1 and beyond. VoIPNorm explains the issue here: http://voipnorm.blogspot.com/2011/04/multiple-lync-mediation-server-pools.html. For our configuration, we will set the Organization Top Level Domain to unplugthepbx.com and more importantly the Cluster FQDN to *.unplugthepbx.com in Enterprise Parameters under System on the CUCM.

 

Lync Configuration:

My Goals for Lync calls are the following:

  • A voice call from Lync to Lync between sites should use RTAudio
  • A call across the WAN should be limited to 40kbps (enough for wide band with no FEC)
  • There should be a maximum of 10 calls site to site
  • A voice call from Lync to Cisco within the same site should be G.711 and the media must stay within the site
  • A voice call from Lync to Cisco across the WAN should be RTAudio across the WAN and be converted to G711 at the mediation server in the site with the Cisco phone

Known Issues/Limitations:

In OCS 2007 R2, you were able to have multiple mediation servers point to the same CUCM Subscriber IP address. Due to a limitation in the schema for Lync 2010, you are not able to utilize the same IP gateway name or IP address in the topology more than once. Therefore, we will need to create unique DNS A records for the CUCM subscriber(s) at each remote site. (ie: ChicagoSub1.unplugthepbx.com = 10.1.14.10, ChicagoSub2.unplugthepbx.com = 10.1.14.11, NYSub1.unplugthepbx.com = 10.1.14.10, NYSub2.unplugthepbx.com = 10.1.14.11, Sub1.unplugthepbx.com = 10.1.14.10, Sub2.unplugthepbx.com = 10.1.14.11)

Prior to the April 2011 CU2 Mediation Server patch (2502810), there was an issue where the Mediation Server does not associate the correct media bypass ID because the SIP invite comes from the same signaling IP address (CUCM). It is recommended that you install CU2 on all mediation servers in the environment to properly allow media bypass in your environment. Without this fix, you should assign an alternate media IP address to each PSTN gateway pointing to the local gateway with MTP resources. This is done in the topology builder by following these steps:

Open the Topology Builder and expand PSTN gateways as shown below.

Select the PSTN Gateway to be modified, right click and select properties. Enter the IP address of the local Cisco gateway with MTP resources configured.

The same will need to be done for all other PSTN gateways configured in the topology.

In the next post I will show expected media flow as a result of this configuration, finalizing the Lync configuration with a dial plan to support this environment and Call Admission Control.

About these ads
Categories: Lync
  1. April 12, 2011 at 11:53 am

    Bless you for trying to explain the terminlogy to the newbies!

  2. April 26, 2011 at 8:48 am

    Hi Mark. We run a fully hosted enterprise voice on Exchange 2007/R2. We are migrating to Lync and would like your opinion on the viability,(business-wise) of your hybrid Cisco architecture vs. a fully hosted Lync UC. Pros and cons? Please add me to your contacts. Thank you.

    • April 27, 2011 at 11:02 am

      @Taylor – I absolutely think this is a viable option for enterprises that are looking to take advantage of the investment they already have in a Cisco infrastructure. I also think that there will be a point in time for every company that has this dual configuration where a decision will be made on the future UC system. The cost of maintaining two separate systems is too high simply due to vendor relationships or bureaucratic reasons. There are definately cons with this solution and those mostly focus around video integration, remote call control and the fact that you have to figure out how to manage two separate call admission control environments without oversubscription of your priority queues.
      Mark

  3. May 10, 2011 at 12:04 pm

    Good stuff – keep it comming!

  4. October 3, 2011 at 12:31 pm

    If we already have the Lync licensing do you think there is much reason to go down the Cisco path?

    • October 3, 2011 at 2:48 pm

      There is NO reason to go the Cisco route if you already own Lync. I have many customers that are deploying Lync as their corporate UC solution including voice. Let me know if you need some assistance.

  5. Bill Taney
    November 1, 2011 at 4:48 pm

    We are considering deploying Lync for IM and a replacement for our existing collaboration tools. We have a all Cisco voice environment, what licensing do you need if you are deploying Lync integration in a Cisco environment where CallManager is handling all the voice etc, can you use a standard CAL or do you have to go with the pricey enterprise or PLUS CALS.
    Bill

    • November 2, 2011 at 10:10 pm

      If you are deploying Lync for multiparty IM, one to one voice, one to one video then you only need the standard CAL. If you are doing multiparty voice/video (conferencing), application sharing etc then you will need the enterprise CAL. If you are doing Remote Call Control, Enterprise Voice then you need the Plus CAL. There is a much better explanation here: http://lync.microsoft.com/en-us/HowToBuy/Pages/pricing-licensing.aspx

      • Roy
        February 8, 2012 at 4:14 pm

        I just noticed your statement..”If you are doing Remote Call Control, Enterprise Voice then you need the Plus CAL.” If we are looking into a mix environment Lync CUPS via RCC, would our users need a PLUS cal? Wouldn’t a Std Call suffice?

  6. Roy
    February 8, 2012 at 4:15 pm

    Roy :
    I just noticed your statement..”If you are doing Remote Call Control, Enterprise Voice then you need the Plus CAL.” If we are looking into a mix environment Lync CUPS via RCC, would our users need a PLUS cal? Wouldn’t a Std Call suffice? We wouldn’t use Lync for Voice..

    • February 10, 2012 at 12:55 pm

      If you are using RCC or EV you need the plus cal!

  1. No trackbacks yet.

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

Follow

Get every new post delivered to your Inbox.

Join 28 other followers

%d bloggers like this: