Lync 2013, CUCM, ms-skip-rnl & SIP URI Dialling…
Note: I wrote this back in October 2013, but I got rid of my Wordpress site and wanted to move it over to Medium. It still gets a few views so though it would be worth re-sharing.
First up, a lot of the help I got was gained from Chris Norman’s blog at http://voipnorm.blogspot.co.uk/. You can follow him on Twitter here: https://twitter.com/voipnorm
I have recently been building a production Lync environment for my company including voice integration with CUCM 8.5. Whilst the company wanted to invest in Enterprise Voice it didn’t want to go the whole hog and start to get rid of desk phones. Prior significant investment in Cisco has meant this has to stay around for a while. Also, I’m not sure the user base is ready for a full push to Lync EV so I’m quite happy that’s how it’s happened. However, as Lync Enterprise Voice is seen as an addition to the current CUCM environment I was set an important requirement that when a call comes in both the Cisco desk phone and the Lync client must ring.
Now, this is simple enough with remote destinations configured in Cisco and a SIP trunk to Lync. That’s pretty bread and butter. There is plenty of help around for you to configure that. The problem comes when one EV enabled user calls another. If all your Line URI attributes are populated with E.164 numbers (as they should be) when the EV enabled person dials the other EV enabled user a reverse number lookup (RNL) happens in Lync and a SIP Lync call is made instead of routing the call to CUCM. This is totally understandable. It is not a bug as someone tried to convince me of. If you have a fully EV environment of course you would want it to happen like that.
Anyway, that was no good for us so we had to find another way of always routing the calls to CUCM. Many people recommend playing around with the Line URI so it doesn’t matching during a RNL or using non-E.164 formatted numbers. In the end, whilst this may work, you’re going to have issues eventually. It’s best to stay with the best practices around Line URI numbers.
Enter ms-skip-rnl.
This magical little addition to the Line URI attribute means that Lync skips the reverse number lookup when a call is made and because of this uses the rules and routes you have setup in Lync to route the call to CUCM. This solved the problem of both the Cisco phone and the Lync client ringing between two EV enabled users.
Example: tel:+441234567890;ext=4567890;ms-skip-rnl
Well, it kind of does. The problem we then had was that while the call was routed to Cisco it then didn’t call the Lync client. The reason for this is that when calls arrived in Lync from Cisco no RNL was happening. So, the E.164 number couldn’t be matched to the user and the endpoint wasn’t rung.
Enter SIP URI dialling.
By configuring SIP URI dialling in the remote destination in CUCM, calls were directed to first.last@lyncsipdomain.com instead of a number. This means reverse number lookup is not an issue as a number isn’t called, instead a SIP address is used.
Supportability with Microsoft may be an issue with this approach. At last check SIP URI dialling was not supported by Microsoft and I very much doubt ms-skip-rnl is supported either considering it’s lack of official documentation. That’s not to say Microsoft won’t help but I would always make sure you could get into a supported configuration should you need to call support.
Pros
Means all endpoints ring (Cisco & Lync) no matter who makes the call from wherever.
Cons
Questionable supportability.
All calls (except when the user expressly chooses ‘Lync call’) go to CUCM. Fully dependent on the CUCM infrastructure and may mean you use more MTP resources on CUCM.
Audio calls cannot be escalated to video calls or meetings as the audio stream is going to CUCM.
Hope this helps some people out there who have the same requirements as I had.
