Monday, 26 November 2012

Connecting Lync 2010 with a Cisco 3925 ISR

I've recently finished a deployment of Lync 2010 enterprise voice using a Cisco 3925 ISR as an IP gateway.  I struggled to find information on configuring the Cisco side so I thought I'd post my experience here.

The ISR was already in use as a PSTN gateway using the built-in Cisco Unified Communications Manager Express (CUCME) with voicemail being handled by the Cisco Unity Express module.  Staff have Cisco SCCP IP phones and Lync was deployed as an alternative phone system using a subset of the extension numbers.  Let's say that the extension numbers 600 - 699 are configured on the ISR.  I've sent extensions 670 - 679 from the ISR to Lync instead of to Cisco phones.

Although I do some Cisco networking it's mostly switching and firewalls and I don't have a lot of experience with voice.  I find it a little terrifying to be honest!  My goal in making changes to the ISR was to have no interruptions to service and to make as few changes to the existing configuration as possible.

The first thing to do is to update the Lync topology.  Create a PSTN gateway listening on TCP 5060 and using the IP address of your ISR (probably the Loopback0 interface):


PSTN Gateway
Associate the PSTN gateway with your mediation server/pool and enable TCP 5068.  TCP must be used as TLS isn't compatible between the ISR and Lync.


Mediation Server
Don't forget to publish the topology and update your servers using the Deployment Wizard.

The next step is to configure the voice routing and policies.  This can be daunting.  Or, it can really easy if you let someone else do the hard work!  Head on over to www.lyncoptimizer.com and run through the steps and you'll end up with a PowerShell script that you run in the Lync shell.  Depending on the choices you made this script will create:
  • A site dial plan
  • Normalisation rules
  • Site and user voice policies
  • PSTN usage records
  • Voice routes
  • Gateway trunk
  • Trunk translation rules
Big thanks to Ken Lasko for this amazing and useful tool.

Now, in my particular deployment the ISR normalisation is based on extensions (6xx) while Lync is based around E.164 numbers.  This means that you need to create some new rules so that Lync users can dial extensions without having to enter the full number.

Edit your site (or pool) dial plan and create a new normalisation rule to translate the extension numbers that get dialed (e.g. 678) to a full E.164 number.  Mark it as an internal extension.

New Normalisation Rule


Move the new normalisation rule to the top of the list.  It's a good idea to create a voice routing test case to prove that the normalisation works.

Jump over to your trunk configuration and edit your gateway's trunk.  Check that the Encryption support level is set to Optional and that Refer support is disabled.

Create a new associated translation rule to remove the leading digits to expose your internal extensions:


New Trunk Translation Rule
Move the new rule to the top of the list and commit the changes.

You may also want to configure the Call Park and Unassigned Numbers features now.  I won't include details on how to do that here as this post is already getting longer than I'd anticipated.

One more thing to configure and this time it's in the Lync Management shell.  You need to disable the trunk's RTCP session timers to avoid an issue of calls between Cisco users and Lync users dropping after 30 minutes:

Set-CsTrunkConfiguration –Identity [name of your trunk] -EnableSessionTimer $false –RTCPActiveCalls $false –RTCPCallsOnHold $false 

Alright, enough about Lync, let's get to the juicy stuff: configuring the Cisco ISR.

Like I said earlier, I'm not an expert here and a lot of things I discovered through trial and error (never a good idea on a production system but I only broke it once for a minute!).  So be warned: these changes are your responsibility and the configuration examples I've listed may not work with your system!!!

The first thing is to add your Lync mediation server to the list of trusted IP addresses that can talk to the ISR.  This may not be necessary if this feature isn't already turned on.

voice service voip
 ip address trusted list
  ipv4 [Mediation server's IP address]


Now check that SIP control is bound to CUCME.  This one cost me a day of my life:

voice service voip
  sip
   bind control source-interface Loopback0
 


You need to create voice translation rules and profiles so that the ISR sends E.164 numbers to Lync instead of extensions.  The examples below are normalising extensions 670-679 to +61712345670 - +61712345679 for calls placed from ISR users to Lync users.  The reverse happens when Lync users call ISR extensions; we want the Lync user's calling number to be normalised so that it appears as a 3-digit extension on the Cisco phones.
 

voice translation-rule 5
 rule 1 /^\(67.\)$/ /+61712345\1/

voice translation-rule 6
 rule 1 /^.61712345\(67.\)$/ /\1/

voice translation-profile ToLync
 translate called 5

voice translation-profile FromLync
 translate calling 6


Now create a dial peer for the Lync server.  This will be used for both inbound and outbound calls to/from Lync.
 

dial-peer voice 5 voip
 tone ringback alert-no-PI
 description ** SIP Trunk to Lync **
 translation-profile incoming FromLync
 translation-profile outgoing ToLync
 answer-address .6171234567.
 destination-pattern 67.
 notify redirect ip2pots
 session protocol sipv2
 session target ipv4:[Mediation server's IP address]:5068
 session transport tcp
 voice-class sip rel1xx disable

 voice-class sip block 183 sdp present
 dtmf-relay rtp-nte
 codec g711ulaw
 fax protocol none
 no vad
 no supplementary-service sip refer

 

Here's some info on some of the entries:

tone ringback alert-no-PI voice-class sip block 183 sdp present voice-class sip rel1xx disable

These are used to help with ringback (the ringing sound you hear when you've dialed a number and are waiting for it to be answered) for the Cisco phones.

The man whose blog you want to read about these and other Lync goodness is Chris Norman's (VoIPNorm):

voipnorm.blogspot.com.au/2012/09/updated-ringback-info-important.html

-UPDATE-

Chris has updated his info on Cisco ISR/Lync integration:

http://voipnorm.blogspot.com.au/2013/06/updated-again-important-settings-to.html

-/UPDATE-

If you read Chris' post you'll notice I disabled rel1xx and sip refer at the dial peer level rather than at the higher voice service voip level.  This is in keeping with my desire to limit changes that affect the existing services.  I've no idea if what I've done is right or not but it seems to work.

 answer-address .6171234567.
 destination-pattern 67.


These two lines are used to associate the numbers with Lync.  The answer-address line identifies the calling number of the Lync user when they dial out and associates it with the dial peer.  This works in my deployment because the incoming called-number . line was already configured on the inbound POTS dial peer like so:

dial-peer voice 11 pots
 incoming called-number .
 direct-inward-dial
 port 0/0/0:15
 

I may have had to remove it, add the answer-address line then add the incoming called-number line back again before the ISR figured it all out.  My memory is blurry.

The destination-pattern 67.  line sends all calls to extensions 670 - 679 to Lync.


no supplementary-service sip refer

This is where to disable refer support.  You can also disable it globally at the voice service voip level.

Hopefully that provides enough information for those of you configuring ISRs that use CUCME.

When I find time I'll post about configuring media bypass and Exchange UM with the ISR as well.



This post in its entirety is the copyright of Roland Paix. I don't mind if you link to it but if you copy any of the content you must provide a link to the post and credit me appropriately.

3 comments:

  1. Very thorough. I look forward to reading about media bypass and Exchange UM

    ReplyDelete
  2. Hi Roland,

    I have an updated link for info on ISR's.

    http://voipnorm.blogspot.com.au/2013/06/updated-again-important-settings-to.html

    Cheers
    Chris

    ReplyDelete
    Replies
    1. Thanks Chris, I've added the new link.

      Roland

      Delete