Important URL’s for Lync to Skype Connectivity

I am guessing by now everyone that follows Twitter should have seen the flood of tweets around this but I thought I would put together a couple of important links if you didn’t.

Official Provisioning Guide:

Lync Server Provisioning Guide for Lync-Skype Connectivity

For some companies already federated with MSN you may only need to edit your current PIC provider where as others that have never enabled PIC will need to go through the whole PIC enablement process.

From the configuration guide:

To edit a Messenger PIC provider and configure it for Skype, do the following:

1. From a Lync Server Front End Server, open the Lync Server Management Shell.

2. Run the following two commands:

Remove-CsPublicProvider -Identity Messenger

New-CsPublicProvider -Identity Skype -ProxyFqdn federation.messenger.msn.com -IconUrl "https://images.edge.messenger.live.com/Messenger_16x16.png" -VerificationLevel 2 -Enabled 1

3. From a Lync client, you can now select Skype as the PIC provider, and add a Skype client by specifying their MSA account. .

clip_image002

 

Announcements:

Lync Team Blog announcement

Skype Big Blog announcement

Customer comments:

A Customer Perspective: L’Occitane

VoIPNorm

Lync Online TRIP Tool

Transport Reliability IP Probe for Lync Online is a great test tool to check your connectivity to Lync Online Service data center. Lots of great data for testing your sites and the only thing required is a Web Brower with Java.

image

VoIPNorm

Northwest Microsoft UC User Groups Portland, Seattle and Boise Upcoming June Meetings

Not going to TechEd, we got you covered! Come have more fun than a trip to Maui*

* Fun experienced during meeting may be less than trip to Maui

We are a forum for computer professionals in the Portland, Boise and Seattle areas who are interested in gaining and sharing knowledge in Microsoft Unified Communications technologies through networking and education.

The presentation starts around 11:00am. 

Come when you can, and leave when you must. (We are an informal groups)
Interested in joining our group - just attend a meeting!  That is it.  There is no fee to join just your enthusiastic participation is requested!

Agenda is as follows:

10:30am - 11:00am

Welcome

11:00am – 11:45am

Lync-specific network impacts

Polycom Video interoperability

12:00pm – 12:30pm

Lunch

12:30pm- 1:30pm

Overview WAN and SIP trunk considerations

Lync 2013 mobility capability and cost savings review

1:30pm – 2:00pm

UC discussions: Lync 2010, tips and tricks, challenges, solutions, Future meeting topics.

Seattle June 4th

Date: June 4th

Time: 11:00 – 2:00pm

 

Location: Polycom Executive Briefing Center –Bellevue

411 108th Ave NE

Suite 2100

Bellevue WA 98004

Seattle - Register Here

Boise June 5th

Date: June 4th

Time: 11:00 – 2:00pm

 

Location: Microsoft Boise Office 

401 West Front Street

Boise - Register Here

Portland June 6th

Date: June 6th

Time: 11:00 – 2:00pm

 

Location: Microsoft

1414 NW Northrup St

Suite 900

Portland OR 97209

Portland -Register Here

Come and take part in our Second User Group meetings of the year and catch up on what's happening with Lync 2013.

Hope to see you there.

VoIPNorm

Lync Server 2013 Call Park Retrieval Issues From CUCM 8.x

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.

image

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.

image

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.

image

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.

image

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.

image

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.

image

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