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 |
Mediation Server |
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
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 |
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.
Very thorough. I look forward to reading about media bypass and Exchange UM
ReplyDeleteHi Roland,
ReplyDeleteI have an updated link for info on ISR's.
http://voipnorm.blogspot.com.au/2013/06/updated-again-important-settings-to.html
Cheers
Chris
Thanks Chris, I've added the new link.
DeleteRoland