Archive for the ‘Lync’ Category

Lync E911 Deployment

July 6, 2011 6 comments

I have recently been working with a number of clients that are interested in deploying Enhanced 911 (E911) with Lync Server and there is one thing in common…. They have a lot of questions about the capabilities and functionality. When thinking about how end users will connect their Lync client to the environment we know there will be a couple of different scenarios:

  • A user with a phone at a desk
  • A common area phone
  • A roaming user with a laptop
  • A user with Lync installed on their desktop with only a soft phone

Thankfully, Lync has an answer for each of these scenarios, plus more! There are numerous ways you can automatically set the location of a user, and if you can’t identify their location automatically you can (and should) prompt them to enter their location. Think about a scenario where an employee working from home calls 911 from Lync. The call would be routed out the PSTN at the office. The Caller-ID would exist in the legacy PS-ALI database controlled by your local telco and most likely would not be associated with your home address and your call would get sent to the wrong PSAP.

This is where E911 comes in. With more offices going to a “hoteling” scenario and the significant increase in remote and travelling workforces, tools like Lync need to be smart enough to follow them where they go and work like they did in the office.

The configuration of E911 is not difficult; however, it requires planning in advance and consideration of the following:

  • What detail on location proximity do you need to provide to the emergency responder? Most laws are specifying a range in square feet (ie: 5,000 sq ft).
  • How will you assign an E911 policy to users?
  • Will you have multiple locations with security desks that you would like to inform in the event of an emergency?
  • What will you do in the event the Lync environment or WAN is down when trying to make 911 calls?

In many situations, the answers to these questions are very similar. Many customers want the flexibility to inform a security desk for larger offices, hospital buildings or retail facilities. This notification can be transmitted with a simple IM message indicating the person (or device) that called 911, their location and even the ability to conference in a security officer or security operations center.

The configuration detailed below includes 2 main sites (LA and NY) as well as outlines how a branch office and mobile user would utilize enhanced 911.

Our Lync configuration is a single Enterprise Pool which houses all users in our NY offices. Each branch office has a Survivable Branch Appliance deployed with local PSTN connections for alarm and emergency purposes only. We will be utilizing E911 services provided by 911Enable (Connexon) which at the time that this post was published is the only certified enhanced 911 service provider for Lync. Our network infrastructure consists of LLDP compatible switches and wireless access points.

We will configure the following in Lync:

  • A Location Policy for each site
  • A route for 911 for each site
  • A failover route for 911 for each site
  • A PSTN usage for 911 at each site
  • Location Information Services (LIS)
    • Civic Address
    • Switch Port for LLDP-MED
    • Wireless Access Point BSSID
    • Network Subnets for Lync clients
    • Validate the LIS database Civic addresses
    • A disclaimer for remote users


Lync Routing Configuration

First, we will configure the routes and PSTN usages required to make calls to 911.

Our Routes will be called E911(NY) and E911(LA), shown below is our E911(NY) voice route. The route will match the pattern +911. A normalization rule has been created that will add a + to all numbers dialed that are exactly “911”. In addition, we are suppressing caller ID and supplying a local number that is in the legacy PS-ALI database in case of a failure of 911 enable providing the location information to the PSAP. This will typically be the telephone number of your building security desk if you have one at the location.

Now to the PSTN usage which will reference this route. Our PSTN Usage will be called E911 (NY) and will use the route E911(NY) that we just created.


Since we do not have a global security operations center and our operations have local security offices, we will want to define a location policy per site. This will allow us to send security notifications via IM to the local security desk and to conference in the security desk number. We have already configured our sites in the topology and will be creating the Location Policy for the New York Site in the example below. Note however that we are creating a Location Policy that is scoped at for a User not for the Site. This policy will be assigned later to a Communications Server Network Site which is not the same as the Topology Builder Site, the main reason for this is when a user travels to a different site they will get a Location Policy based on the Network Site they are in (based on their subnet and the configuration of the CsNetworkSite). In the policy, I am requiring users to enter the location if it is not automatically applied by the Lync LIS detection. I am also enabling enhanced emergency services and assigning the E911(NY) PSTN usage to this site. In addition, I am sending a IM message to the security officer ( and conferencing in the security desk number. The conference URI does not have to be a Lync EV number, it could be any phone and if so should be in the format sip:+1<10digitnumber> so it is routable by Lync.


In the event the WAN is out or the Mediation server pool that routes to the 911Enable SIP trunk is unavailable, it will still be necessary to allow users to make 911 calls. In this case, we will need to build a failover Route, PSTN usage, and assign that to a voice policy that gets assigned to a user. The configuration is shown below:

A new route is created called 911Failover that matches the same string as the 911Enable route. The failover route will point to a local gateway or in our case the SBA (Survivable Branch Appliance) gateway component.

Our PSTN usage for failover routing will utilize the route seen below.

The next step is to ensure the route list is ordered properly and has the E911 usage listed above the 911 Failover route. This will ensure that the E911 route will be preferred over the failover route and the failover route will only be used after the E911 route is marked as unavailable.

Location Information Service (LIS) Configuration

There are a number of PowerShell commands that perform various configuration tasks within the LIS. Those commands and some samples are shown below:


The Switch ChassisID and Port number are used in Set-CsLisPort to create an association between a switch port and a location. It can be difficult to identify what information is being provided to a phone via LLDP broadcast messages, but by using network monitor you can view the LLDP packet (even though Windows 7 does not honor LLDP broadcast messages). This will help you identify how the switch manufacturer identifies the switch port id.

I have configured a single switch port with the command:

Set-CsLisPort –ChassisID 3c-4a-92-30-ec-00 –PortId 7 –Description “New York Wired Connections” –Location “New York Wired” – CompanyName “UnplugThePBX” –HouseNumber “12345” –PreDirectional N -StreetName “Cedar” –StreetSuffix “Dr” –City “New York” –State “NY” –PostalCode 98765 –Country US



Lync clients that run on laptops with mobile users and do not typically connect to a wired network can receive location information based on the wireless access point they are connected to. This information is entered into the LIS is based on the access point BSSID. To configure wireless provisioning the following command can be used:

Set-CsLisWirelessAccessPoint -BSSID 00-19-5b-7f-77-0D –Description “New York Wireless Connections 3rd Floor” –Location “New York 3rd Floor Wireless” – CompanyName “UnplugThePBX” –HouseNumber “12345” –PreDirectional N -StreetName “Cedar” –StreetSuffix “Dr” –City “New York” –State “NY” –PostalCode 98765 –Country US



Lync softphone clients (non IP phones) cannot use LLDP-MED for location provisioning. Therefore we need to identify a way to determine their location when they are connected to the corporate network and not to a wireless base station. To do this, we will utilize network subnets which generally are consolidated to a floor, building wing, department, or other location. To configure a subnet:

Set-CsLisSubnet –Subnet -–Description “New York” –Location “New York 1st Floor” – CompanyName “UnplugThePBX” –HouseNumber “12345” –PreDirectional N -StreetName “Cedar” –StreetSuffix “Dr” –City “New York” –State “NY” –PostalCode 98765 –Country US



Lync requires the addresses entered to the LIS are validated against the 3rd party provider’s Master Street Address Guide to ensure the correct address is provided to the PSAP and the correct PSAP is contacted for the address. To do so, the E911 provider will provide a web service URL and certificate used to authenticate against the provider’s web service. This is done by completing the following:

Set-CsLisProvider –ServiceProviderName “911 Enable” –ValidationServiceURL “; –CertFileName “C:\temp\911enablevalidation.pfx”



For users that are remote, users can be prompted to enter their address. Many times it also makes sense to provide a disclaimer to inform them of what should be expected when they call 911. We talk with many customers who want remote employees to use their personal phone, hotel phone, or mobile phone to dial 911 in the event of an emergency and avoid using their Lync client. An optional cmdlet provides the ability to display a global disclaimer to users who cannot have their location automatically detected. The example below directs users to use their personal cell phone in the event of an emergency.

New-CSEnhancedEmergencyServiceDisclaimer –Identity Global –Body “Please use your personal cell phone to dial 911 in the event of an emergency”

Note: The disclaimer message is configured globally. There is currently no ability to provide disclaimers per site or per pool.


Next up – you will need to make sure you have network sites configured that unite your network regions to the appropriate location policy. You will have to create a network region, network site, and network subnet that will be associated with the location policy that we created previously named “New York City”. We will first create a Network Site as shown below:

New-CsNetworkSite –SiteID “NY1” –NetworkRegionID “NorthAmerica” -LocationPolicy “New York Location Policy”


After creating the site we will now assign subnets to that site:

New-CsNetworkSubnet –SubnetID “” –Maskbits “24” –NetworkSiteID “NY1”



Now on to the important part – there are a few known issues or config items that you will want to address when configuring E911:

  1. The Global Trunk Group configuration in Lync does not send PIDIFLO information by default. This prevents location information from being sent to the E911 provider. To enable this for the Global trunk run Set-TrunkConfiguration –EnablePIDIFLOSupport $True
  2. IP Phones do not use the subnet as a fallback if the switch and port information is provided to the phone via LLDP-MED, but is not found in the LIS
  3. Don’t forget to run Publish-CsLisConfiguration after each change to the LIS
  4. Addresses not validated by the Master Street Address Guide (MSAG) will not be used by clients
  5. Analog devices do not use Lync LIS, numbers will have to be added to the Legacy PS-ALI database the provider maintains.

Big thanks to Ryan Gates for your great work getting reviewing, validating in our lab and proving out the solution!

Categories: Lync

My Thoughts on the Microsoft – Skype Deal

May 11, 2011 2 comments

So here it is, I have been asked my opinion a couple of times the past 2 days and have been reluctant to comment.  I typically do not write editorials, so here we go..  I have spent a lot of time thinking about the decision by Microsoft to purchase Skype, it started off pretty negative when I first heard rumblings, I think I have finally come to see the light.  This blog is about my opinions about this deal and does not reflect the views of anyone else pretty much like everything I write.

I must say that at first sight I think Microsoft overpaid for Skype, they had to.  They had to block Google from getting a product that has the market share and brand recognition as Skype.  The reason Google is gaining ground is simply due to brand recognition, it would be devastating to the UC world if Google acquired Skype.  Google is an advertising company and doesn’t put a fraction of the investment into UI and Quality than any of their competitors in the market.

Back on topic… I am not an avid user of Skype, I think I may have signed up for an account when it first came out, purchased credits and never used them…  I have however seen customers use Skype in a business environment on a weekly basis, crazy right?! 

The positive for all of us:

Facebook integration – Microsoft has an investment in Facebook, that is well-known.  Facebook didn’t have to lift a finger and will benefit more than anyone from this!  As a Facebook user (not stalker or freak about it) I am excited about this.  How cool is it going to be when we can securely click to call from Facebook without Lync installed?!  Notice how I mention securely right there, I will not use the server until we have AES encryption, TLS security and I know that my conversations are protected. 

Office 365 – Can you say Skype Enterprise?  Obviously Skype has a huge brand, how cool would it be for Microsoft to have Skype Online, Skype On Premise?  Oh that’s right, that’s what Lync is!!  Still everyday I meet with customers that know what Skype is and have no idea what Lync is.  This is a pretty easy story for me to tell, I have told the history of NetMeeting, Live Meeting, OCS and Lync for years.  Lync provides more features, better security and a MUCH better user interface. 

Windows Phone – I am a Windows Phone user.  I have had almost every version of Windows Phone OS from WM2003-WM6.5, in between WM6.5 I had an Android for a while and loved the performance but hated the interface.  Windows Phone 7 just does it for me, the Samsung Focus after 7 months is the best phone I have used, minus the update fiasco, I am excited about the product.  Joe Belfiore announced at MIX 11 that Skype and Microsoft confirmed that a client is imminent.  To me, this announcement means WiFi calling, a competitor to Facetime for consumers and a possibility to replace expensive carrier network fees for international calling. 

Skype Users – Microsoft will put the time and effort into Skype to make it the product it can be.  Think enterprise integration with the consumer look and feel, a massive upgrade to the interface is necessary but there is a right mix here of capabilities and function.  Microsoft has grown their enterprise UC business 30% last quarter by investing in a great product, Skype is a great product with great potential.

As a Microsoft investor I was first upset with the price, after all my stock has been down all year and continued to decline after this was announced.  I am a frustrated that Microsoft continues to see losses in Bing as a business but growth in market share.  I don’t want Microsoft to approach purchasing internet services as a way just to keep Google down.  I don’t think this is the case with this acquisition and truely think Microsoft is poised to make Skype great!  I am hopeful after thinking about this and I hope that my friends in the UC space are also thankful that Microsoft over others in the race got the prize. 

Now back to your regularly scheduled programmming.


Categories: Lync

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

April 11, 2011 11 comments

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


  • 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


Device Pool


Media Resource Group List


MTP Required


Destination Address (IP of SBS)

Destination Port


SIP Trunk Security Profile

Non Secure SIP Trunk Profile

SIP Profile

Standard SIP Profile


Device Name


Device Pool


Media Resource Group List


MTP Required


Destination Address (IP of SBS)

Destination Port


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: For our configuration, we will set the Organization Top Level Domain to and more importantly the Cluster FQDN to * 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: =, =, =, =, =, =

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.

Categories: Lync

Integrating Microsoft Lync and Cisco Unified Communication Manager Part 3: Configuring CUCM to Route Calls to Lync

March 16, 2011 19 comments

So I said I wasn’t going to do this part, but I have received some feedback that people would like one location to go to in order to get an end-to-end configuration. In Part 2 I showed the necessary configuration on the Microsoft Lync side to set the Cisco Subscribers as the PSTN gateway for Lync.

There are a number of steps that need to be done successfully for you to be able to make calls between Lync and Cisco phones, those steps are identified below:

  • Identify or create a region
  • Identify or create a device pool
  • Identify or create a partition
  • Identify or create a calling search space
  • Create the SIP trunk
  • Create the Routing Pattern
  • Create the Translation Pattern

Identifying or Creating a Region

A Region is used to specify codec and bandwidth for audio calls within that Region and between Regions. As I have already noted, the Lync Mediation Server role will take RTAudio media from a Lync Client and will transcode RTAudio media to G.711. Therefore we need a Region that supports G.711.

The image below shows a Region LyncRegion and the important part to note is the relationship LyncRegion has with other regions should always have the Audio Codec set to G.711.


Identifying or Creating a Device Pool

Device pools are used to define a common set of characteristics like SRST (Survivable Remote Site Telephony) gateway reference, Music on Hold sources and much more. For our purposes it tells the device which Region it belongs to. Now that we have established a Region that will dictate what codec we will use, we now need to identify or create a device pool that the SIP trunk will eventually belong to. Our Device Pool Configuration is shown below, notice that we have selected LyncRegion as our Region:


Identify or create a partition

Partitions are logical subsets of a route plan based typically based on location that facilitates call routing. We have created our own Partition shown below called LyncPartition

Identify or create a Calling Search Space (CSS)

A CSS is an ordered list of partitions that Cisco Unified Communications Manager uses to search when a device makes a call. Our CSS (LyncIncoming) will contain our Partition (LyncPartition) plus any other Partition configured in the organization that we want Lync to be able to call across the SIP trunk.

Creating the SIP trunk

The next step is to create the SIP trunk that will identify how Cisco and Lync will communicate. The important items to fill out:

  • Device Pool = The Device Pool we created (LyncDP) that is in the Region (LyncRegion)
  • Media Resource Group List = A list of MTP resources available at the local site. In our instance we have created a MRGL that contains the MTP resources on the Subscribers (UPXMTP1).
  • Media Termination Point Required and Retry Video Call as Audio Call must be selected
  • Inbound Calls CSS = LyncIncoming
  • DTMF Signaling Method = No Preference
  • MTP Preferred Originating Codec = G711ulaw
  • Destination Address = IP of Mediation Server (or Front End server if collocated)
  • Destination Port = 5068 (default TCP port for Mediation role on collocated FE Server)
  • Rerouting Calling Search Space = LyncIncoming

Create the Routing Pattern

A Routing Pattern is pretty self-explanatory; a pattern of digits that are entered in the Cisco environment will be handled according to a rule created in the routing pattern. For our environment we decided that the numbers 7000-7999 would be routed to Lync. Therefore, our routing pattern will be configured to send 7xxx to the SIP Trunk created above named Lync.

Create the Translation Pattern

We are going to demonstrate how to create 2 different translation patterns for our enterprise. The first will translate calls from Lync to the PSTN for calls in North America; the second will translate calls from Lync to CUCM extensions in our main office (all 248555 DIDs).

Lync to PSTN Routing Pattern

  • Translation Pattern: XXXXXXXXXXX (that is 11 X’s)
  • Partition: LyncIncoming
  • Numbering Plan: NANP
  • Discard Digits: PreDot
  • Prefix Digits (Outgoing Calls): 9

Lync to CUCM Routing Pattern

  • Translation Pattern: 1248555XXXX
  • Partition: LyncIncoming
  • Numbering Plan: NANP


Categories: Lync

Integrating Microsoft Lync and Cisco Unified Communication Manager Part 2: Cisco and Microsoft Co-existence in a Primary Site

March 9, 2011 7 comments

In this second post in my blog series on integration between Microsoft Lync Server 2010 and Cisco Unified Communication Manager we will explore integration in a site that houses CUCM Subscribers and the Enterprise Edition Pools for Lync. In part 1 we discussed terminology and capabilities, please have a look at that post because I will be using terminology defined previously.

For our purposes we will use the following architecture:

  • Lync Architecture
    • Enterprise Edition Pool:
    • 2 Front End Servers
    • Collocated Mediation Server Role on the FE Server
    • Collocated Audio/Video Pool on the FE Server
    • 1 Monitoring / Archiving VM
  • Exchange UM Architecture
    • 2 Exchange 2010 UM Servers
  • Cisco UCM Architecture
    • 3 Node CUCM Cluster
      • 1 Publisher
      • 2 Subscribers
    • 2 Cisco 2851 ISRs
  • PSTN
    • Direct SIP from a certified SIP Trunking Provider

My requirements for this integration are the following:

  • Users must be able to make & receive audio and video calls from their desk phones or soft phones when in the office.
  • Users must be able to make & receive audio and video calls from anywhere without a VPN.
  • Users can choose if they want to have a desk phone altogether, If they choose to forego a desk phone they may be required to change their number
  • In the event of a failure of a single server or gateway, users should still be able to make & receive audio and video calls internal and to the PSTN
  • In the event of a failure of a single server or gateway, users should still be able to make audio calls between Cisco phones and Lync (and vice versa)
  • In the event of a complete site failure, users should be able to make & receive audio and video calls by connecting to a secondary site

Enough of the background information… on to the configuration. As we discussed in the previous post, Cisco UCM, Cisco ISRs and Lync can communicate using SIP, we call this Direct SIP. This is sometimes referred to as a SIP Trunk, I would call it just a trunk that uses SIP and retain the phrase SIP Trunk for the service provided by a ITSP.

High Level Architecture


Cisco Configuration:

I have provided detailed Cisco configuration based on an easy to follow scenario in Part 3.


We have created hardware Media Termination Points (MTPs) on our two Cisco 2851 Gateways. The configuration includes modifications to our gateways (assuming they are already registered with CUCM). Sample configuration of LyncRouter1 shown below:

sccp ccm group 1
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate profile 102 register LyncRouter1

dspfarm profile 102 mtp
codec g711ulaw
maximum sessions hardware 100
associate application SCCP

SIP Trunks:

  • SUB1 – LYNCFE1
  • SUB2 – LYNCFE1
  • SUB1 – LYNCFE2
  • SUB2 – LYNCFE2

A Route List is created in CUCM that includes the 4 SIP Trunks

A Route Pattern is created that sends a block of DIDs to Lync from Cisco UCM. In this instance we have selected 7xxx (7000-7999)


Lync Configuration:

  • Our Front End Pool has the Mediation role collocated
  • We have also added 2 PSTN gateways (SUP1 and SUP2) on ports 5060 (TCP) and associated them with the Mediation Pool (


Media Bypass:

Our primary site has been configured in Lync to allow media bypass and therefore, as shown in the diagram above, G.711 media will flow directly from a Lync client to the MTP and on to the IP Phone. Signaling for the environments would still take place using SIP to the Lync Pool in the Lync environment and using SCCP to the CUCM cluster for Cisco.

Categories: Lync

Cisco ISR – Lync Integration Issue

February 24, 2011 2 comments

Great post by voipnorm here regarding issues with Cisco gateways and
Microsoft Lync!

Categories: Lync

Integrating Microsoft Lync and Cisco Unified Communication Manager Part 1: Understanding the Capabilities and Terminology

February 21, 2011 14 comments

This is part one of a multipart series I will be writing on the integration of two of the most popular Unified Communications systems. This is based off many hours of research and historical and recent personal experience actually doing this integration.

As in any project, it is important to understand your customer’s requirements and to set proper expectations. Microsoft and Cisco have in the past worked to provide recommendations for integrating their products but as of recently have increased the competition part of their relationship due to the realization that Microsoft has a player with Lync.

Let’s start to define the features that might be desired with a Microsoft Lync and Cisco UCM integration:

Feature Capabilities
Enterprise Voice Cisco and Lync are both fully functional Enterprise Voice Solutions and provide integrations together utilizing a direct SIP (SIP Trunk in Cisco world)
Media Bypass Microsoft Lync Server 2010 can utilize media bypass and send direct G.711 traffic to a Cisco gateway configured as a Media Termination Point (MTP)
Survivable Branch Microsoft and Cisco both provide a means for a survivable branch, Cisco through Survivable Remote Site Telephony (SRST) and Lync through Survivable Branch Appliance or Survivable Branch Server
Dual Forking / Simultaneous Ring Microsoft and Cisco both provide technology to ring another device.
Unified Messaging Both Microsoft Lync and Cisco UCM can be easily integrated into Microsoft Exchange Server 2010 for Unified Messaging. And yes, you can light the Message Waiting Indicator natively.
Call Admission Control Lync 2010 provides Call Admission Control based on Regions, Sites and Links with the ability to provide CAC to roaming users not just the device. Cisco also has the ability to provide CAC to Cisco based devices. The same CAC solution cannot control the competing product.
Quality of Service Microsoft and Cisco both utilize Differential Services (DiffServ) markings for Quality of Service.
Conferencing Conferencing can be easily provided to users of Cisco UCM and Lync utilizing Lync Server’s conferencing MCU. The conferencing MCU also has certified integrations with Polycom RMX and LifeSize MCUs through the Unified Communications Open Interoperability Program for Lync.
Remote Call Control Microsoft Lync has the ability to control Cisco desk phones in order to enable you to dial a number in your Lync client and have it make your Cisco desk phone go off hook and dial the number in Lync. This also enables presence information to pass between the Cisco desk phone and your Lync client to show that you are “In a Call” when you pick up your Cisco desk phone.

It should be noted, that I will provide some opinions and recommendations during this multi-part series of blogs, that is why this is my blog and hopefully why you read it. I write this blog because I know there are a lot of people out there looking for information on what works and not just from someone that has read about it themselves, but someone that has done this themselves and knows the good, bad and ugly. I know that there are reasons for organizations to keep their investment in Cisco, whether they are technical or probably more likely political. With all that said, let’s get started on what part 1 will focus on: Understanding the Capabilities and Terminology.

In our environment we will try to replicate what I would expect to see in any midsize to large organization. Our main location in the US has a Cisco environment built with Cisco 2851 ISRs and a single publisher and multiple subscriber nodes. Our ISDN/PRI lines terminate at our Cisco 2851 which are MGCP controlled by our Cisco UCM infrastructure. Our dial plan is centrally maintained by call manager and our 2851 is configured for SRST and has necessary configuration information to allow calls to the PSTN in the event of an outage of our cluster (which never happensJ).

We have also deployed a highly available Microsoft Lync 2010 consisting of a two node Lync Enterprise Edition Pool with DNS load balancing for the SIP traffic and a pair of Hardware Load Balancers for the HTTPS traffic. Management has decided to begin to provide users the option to switch from their desk phone to a soft phone to reduce licensing cost and provide a better user experience for users that have laptops that tend to work remotely a lot.

The decision to begin offering Lync as an alternative to a desk phone needs to come from management. There needs to be buy-in at the top levels which is not necessarily due to the capabilities but due to pushback organizations receive from telecom departments. In addition, to provide an easy to manage environment moving from a desk phone to a soft phone will typically require a user to change their phone number. This is not necessary for technical reasons, but sure makes management of both systems much easier. This is due to the fact that one system will “own” the phone number. In our implementation Cisco “owns” the phone numbers since the gateway is MGCP controlled and there needs to be either a Directory Number (DN) or a route pattern in the CUCM*.

* It is possible but an administrative nightmare to have a directory number for a number that should be in Lync, this can be done by forwarding all calls to a dummy route pattern across a SIP trunk to the Lync server. This is not recommended due to the added complexity of managing the CUCM and Lync environment. In addition, it would typically require coordination with multiple groups for implementation and troubleshooting.

Back to our scenario…

Before you begin the integration, it is important to take your requirements and map them to the capabilities of the integrated Lync and Cisco environment. One of the features that we want to implement is media bypass which allows the Lync client to talk directly to the Cisco 2851 gateway using G.711. Cisco gateways support this capability by using Media Termination Points or MTPs. MTPs are resources that do a number of functions depending on the protocol used. In our scenario, MTPs are required to provide RFC 2833 compliant SIP services between the Lync and Cisco environment such as DTMF and a relay point for media between Cisco and Lync endpoints. RTP traffic encoded with G.711 flows from the Lync client to a MTP then to a Cisco IP Phone when the client has detected that the site that it is in has that capability and the administrator has allowed and configured it.

There are two types of MTPs:

  1. Software based MTP resources can be configured on the router or CUCM Subscriber nodes. Software based MTP resources use server based hardware resources (memory, processor) and degrades the performance and capabilities of the cluster or gateway
  2. Hardware based MTP resources are configured on the gateways. These resources utilize Digital Signal Processors (DSPs) rather than the built-in hardware on the router. It is recommended to use hardware based MTP resources to provide added scalability to your environment.

A typical configuration for hardware based MTP resources will look something like this:

sccp ccm group 1
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate profile 102 register LyncRouter1

dspfarm profile 102 mtp
codec g711ulaw
maximum sessions hardware 100
associate application SCCP

MTP resources, once created on a gateway will be available use on our “SIP Trunk” when we create it in our CUCM environment. It is required when we create our “SIP trunk” to enable direct SIP integration between Lync and CUCM that we require a Media Termination Point and select a of Media Resource Groups List (MRGL). A MRGL provides a prioritized list of Media Resource Groups (MRGs). In our next section, we will discuss how to complete the integration between the CUCM and Lync environments in our main site. Further sections will talk about branch office scenarios and what happens when we experience a failure. I will leave you with a high level diagram of what this environment will look like at our main site.

Categories: Lync