Now that all the Lync 2010 Mobile clients have been released in the respective “App Stores”/”Marketplaces” etc I find myself answering questions around how you get the client, when it will work in your environment and what is required. This by no means is a representation of the work that I have done around Lync Mobile but more of a group of resources I use to understand what is new, get a Lync environment configured for mobility and get those beloved mobile clients!!!
This blog will be updated regularly when I see cool new tutorials or quick tips come out!
MCX = Mobility Service
Autodiscover = Not to be confused with Exchange Autodiscover, the lyncdiscover.sipdomain.com and lyncdiscoverinternal.sipdomain.com tell the Lync Mobile client where to reach the mobility service.
APNS = Apple Push Notification Service = The Apple Push Notification Service is utilized on iOS devices to receive push notification incoming Instant Messages.
MPNS = Microsoft Push Notification Service = Same as Apple Push Notification Service but is utilized for Windows Phone 7.5 devices
Microsoft Lync Server Push Notification Service = The Cloud based solution that is leveraged by the MCX service to send push notifications to iOS and WP devices.
Lync Server 2010 Cumulative Update 4
End to End Configuration Guides:
Get the Apps Here!:
Lync Windows Phone App:
Lync Android App: https://market.android.com/details?id=com.microsoft.office.lync
Feature Comparison Chart:
Lync Partner Finder:
Music On Hold for Lync is provided by a client side policy (CsClientPolicy) and is enabled by setting the EnableClientMusicOnHold value to True, this is by default set to False for the Global Policy. To change this you can run the following PowerShell command:
Set-CsClientPolicy Global –EnableClientMusicOnHold:$true
This is a great feature for those that use the Lync client, but unfortunately this does not provide MoH for Aries phones (Polycom CX600, Aastra 6725iP). Fortunately we can supplement the capabilities of the Lync with that of gateway vendors. In our situation, we were already using AudioCodes M1000 MSBGs as the Session Border Controller (SBC). We noticed the gateways had a configuration under Protocol Configuration – SIP Advanced Paramaters — Supplementary Services called “Enable Hold to ISDN” which meant we knew it would play at least a tone to users that called in via POTS or T1/E1 lines, but we wanted this to also be enforced for IP2IP calls as the calls would originate from a SIP trunk.
After some digging and a couple emails around we identified a parameter that needs to be added to the INI file called “PlayHeldToneForIP2IP”. When set to 1 this enabled that same tone to be played when a user was placed on hold over the SIP trunk. To be a little more technical, when the party that initiates the hold a SIP re-INVITE is sent to the gateway with a=inactive in the SDP. When the gateway detects this it injects the audio stream. This file can be replaced with a pre-recorded voice prompt once converted to a Prerecorded Tone (PRT) file. This can be accomplished with the TrunkPack Downloadable Conversion Utility (DConvert) – https://us-support.audiocodes.com/ftp/release/AudioCodes/Utilities/DConvert.zip
This proved to be the hardest part for us as the WAV file we had was not sampled correctly (only 8000kz/mono/8bit or 16000kz/mono/16bit Linear PCM files are supported). I used Audacity (http://audacity.sourceforge.net/download/) Once we got the sampling correct, the rest was pretty easy:
We launched the Dconvert.exe program
Select “Process Prerecorded Tone file(s).
Select Add File(s)… Locate the file you want to convert.
Once you have the file in the list, double click it to bring up the File Data dialog box. Set the fields as follows:
Coder: G711Alaw_64 or G711ulaw – Do not use LinearPCM
Close the File Data Box and select Make File(s).
Once you have the output file in DAT format, simply upload the DAT file to the gateway using the Web interface.
Navigate to Maintenance – Load Ancillary files
Under Prerecorded Tones select the file and upload. Note at the top of the window (not the popup) if the upload was successful or not.
Once the file has been uploaded and the AudioCodes rebooted, you should begin to experience Music On Hold on any device provided by the gateway!
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 (NYSecurity@unplugthepbx.com) 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>@domain.com 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 10.10.10.0 -–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 “https://www.911enable.com/ocsvalidation” –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 “10.10.1.0” –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:
- 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
- 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
- Don’t forget to run Publish-CsLisConfiguration after each change to the LIS
- Addresses not validated by the Master Street Address Guide (MSAG) will not be used by clients
- 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!
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.
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:
Media Resource Group List
10.99.10.10 (IP of SBS)
SIP Trunk Security Profile
Non Secure SIP Trunk Profile
Standard SIP Profile
Media Resource Group List
10.98.10.10 (IP of SBS)
SIP Trunk Security Profile
Non Secure SIP Trunk 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.
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
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.
Integrating Microsoft Lync and Cisco Unified Communication Manager Part 3: Configuring CUCM to Route Calls to Lync
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
Integrating Microsoft Lync and Cisco Unified Communication Manager Part 2: Cisco and Microsoft Co-existence in a Primary Site
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:
- Enterprise Edition Pool: lyncpool.unplugthepbx.com
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 Pub.unplugthepbx.com
- 2 Cisco 2851 ISRs
- 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
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
maximum sessions hardware 100
associate application SCCP
- 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)
- 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 (Lyncpool.unplugthepbx.com)
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.