About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2016) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.

2015/02/13

Lync 2013 Mobile call failure

Isiah Hudson, CDW UC Consultant, reports the following:

Failures of IM and calling to Lync 2013 mobile clients in two very specific scenarios. The findings are listed below:

 

Issue

When an IM is sent from an internal user (using any Lync client) to a user on the Internet using the Lync mobile 2013 client. The Internal user would get an error message saying the IM failed immediately after the Lync 2013 mobile user accepts the IM.

…or…

When a call (audio or video) is initiated from an internal user to a Lync 2013 mobile user on the Internet the call results in a failure.

This issue only impacted Lync 2013 mobile clients. The Lync 2010 mobile client worked fine in all IM and call scenarios.

 

Tell-Tale Signs

After the IM or call is accepted by the Lync 2013 mobile client the following a SIP/2.0 403 Forbidden message is generated by an FE server with the following information in it:

ms-diagnostics: 24118;Component="RTCC/5.0.0.0_UCWA/5.0.0.0";Reason="Application accepts invitations via static registration only.";Source="whatevertheFEservernameis.ad.local"

 

Solution

A ticket was opened with MSFT and after a couple of months of working on it the problem was the public certificate on the reverse proxy for the Lync external web services had SAN names in them that were not resolvable by public DNS. I am told by MSFT support that the Lync 2013 mobile client will try and resolve all SAN entries of the public certificate presented to it at sign-in. If it cannot resolve any SAN entry on the certificate you may experience the problems outlined in the Issue section above.

 

Take Away

Make sure all SAN entries on the public certificate you put on your reverse proxy for Lync can be resolved to an IP address or you will have a bad time.

And there you go.  Nice work Isiah!

YMMV

1 comment:

Unknown said...

Thank you.
Also, push notifications doesn't work with wildcards in the certificate and error will be the same.

Technical Consulting

Something went through both of my brain cells today. And to keep a long story short, it centers on your approach to the question – whatever ...