The last few days I have been helping out a peer do some troubleshooting around Lync Call Park. We managed to work out a few different issues that may arise when using the Lync Call Park Service with CUCM (Cisco Unified Communications Manager). I am glad to say that there are resolutions to these issues though. I was lucky enough to find these issues because of changes and configured items in my lab but all of them seemed relevant. Had my lab not been such a mess I may have not discovered they were issues. So, here's to having a lab in a mess, who says it doesn’t pay to be unorganized : )
Issue – Normalization and call routing
The Call Park orbit numbers are typically 3 or 4 digit numbers which is fine for normal call routing within the Lync environment but when dialing from a PBX or CUCM this may cause a issue with inbound normalization. Last thing you need is one of your inbound normalization rules to append + or other digit by accidently using the wrong normalization rule. Call orbit numbers can not utilize the + which means that they can not be in E.164 format. They can how ever use other prefixed digits like a * which is my preferred digit for this service.
Solution
Use the * prefix on your orbit numbers as shown below. Now this doesn’t mean that a user has to dial the star as you can normalize client side but it gives you a unique set of numbers that you can create inbound normalization rules for when your dialing from a external PBX.
Below I created a inbound normalization rule that adds the * digit to inbound calls from CUCM. So the CUCM user doesn’t have to dial the * they just need to know the 3 digit orbit number. Of course if that’s all to confusing you can just allow a normalization rule that passes the star coming inbound from CUCM as well. Adding the * in the normalization rule will require a customized rule. You can not add the * through the normal UI rules. You can use *$1 as the translation rule using the edit button on the UI page.
Issue – Lync Trunk to Trunk Call routing stops Call Park orbit lookup
With trunk to trunk call routing enabled (which is new in Lync 2013) external inbound calls to the call park orbit numbers will not be forwarded to the call park service. So basically if a person tries to retrieve a parked call from a CUCM (or other PBX) phone it will fail. Instead Lync will attempt to lookup possible route patterns after the usual reverse number lookup occurs. I am not sure the reason why call park orbit numbers are skipped over but this is the current behavior. In Snooper the call trace will show a 403 forbidden or a 404 not found depending on you call routing setup. The 403 occurs when you do not have a matching outbound route but have PSTN usage records applied to your trunk. The PSTN usage records applied to the trunk prevent the call orbit lookup.
A 404 may occur when the call does indeed have a matching route. The call is passed back to CUCM and it does not have a matching route, rejecting the call with a 404. In this case you may see traffic backwards and forwards between Lync and CUCM.
Solution
The most obvious solution here is to have a trunk that has no PSTN usage records applied to it as shown below. That may mean that if you require trunk to trunk routing that you may need to build a separate route to CUCM for the purposes of allowing inbound calls to the call park service. The good thing is that with Lync 2013 this is not all that complicated.
Issue – Refer Enabled
This issue is a little tricky. Even though the OIP page mentions refer is support for CUCM 8.5 and above it will cause issues with retrieving a call from the call park service from CUCM. The behavior is a little odd in that once a call is parked and you attempt to call into the service from a CUCM endpoint it seemingly makes a connection but then drops. The result is a 486 busy here.
Solution
Disable refer. It’s a simple fix but runs in the face of the OIP page which mentions that Refer is supported as of 8.5.
See below for the PowerShell and UI changes for turning off Refer to the CUCM trunk.
Set-CsTrunkConfiguration –Identity <see example> -EnableSessionTimer $false –RTCPActiveCalls $false –RTCPCallsOnHold $false
I noticed a few comments in various forums around accessing the Call Park service for the purposes of retrieving calls from external PBX’s. Hopefully this will help someone out. I did not find a single reference to these issues anywhere else on the web even though TechNet mentions that call retrieval is possible from a PBX. I am not sure if its because its not widely used or because these issues seldom occur but for what ever reason I thought it was important to document them.
VoIPNorm
