The Great world of Lync UC SDK

After some time , i decide to write this post to share some of my thoughts about Lync developing. Some time ago I’ve wrote a Lync plugin (CallViaPhone app ) that let to use Lync client to start calls directly from an ip-phone, and it gave me a lot of challenges . So, questions could be :

  • Why do I need to develop an application for Lync ?

Professionals that know Lync , know that a lot of features are still not available (or not designed at all) and sometimes this lack of features, could move customers decisions to another technology. In this case we could “extend” Lync with SDK. A good example of cauldron of ideas could be : http://lync.ideascale.com/  .

  • Where should I start and what approach should I have?

First of all , we must have little confidence about developing, example could be install Visual Studio and try to develop some “hello world” application on different enviroments like WPF (XAML) to develop Windows applications with rich graphical interface, or console applications to develop Windows services , or .NET web applications , web services , and so on. But the question could be, why should I have to learn all of these ? Because we need to have a 360° vision and we must use the right enviroment for the project.

Secondly we must have clear what we want to do : do we need a client application to extend Lync client , or we need to develop a server side application centralized for all users , or both? In all of these case we could find a lot of example on how to do it . A good starting point could be this : http://msdn.microsoft.com/en-us/library/office/jj162980(v=office.15).aspx , in which there is a lot of explanations about these :

  • Lync 2013 SDK (client side)

– These API gives you the possibility to control almost all Lync client behavior ,and interact with it. Example could be CRM integrations , client PBX integration , etc…

– There are also the option to add some custom menu in Lync interface to call applications or web url with registry key; for more information visit : http://msdn.microsoft.com/en-us/library/office/jj945535(v=office.15).aspx

– One of the most advantage of Lync Client API , compared to the others Lync API, is that you can develop also in a Office365 enviroments without the needs of a Lync On-Premisev env.

  • Lync Server 2013 SDK (server side)

– With these API you can manage,  in Lync Front End role , all sip communications. This means that, for example, i would like to create the BusyOnBusy feature (actually missing from Lync features)  , so i could develop a “Sip application”  with the “SIP application manifest” (MSPL script) that intercept a call if the user lync called is actually in another audio call.

– Another way to use Lync Server 2013 SDK is to develop a “Managed SIP applications API” ;  the mode is similar to MSPL script , indeed you must start from a MSPL script that route (forking or forwarding) the sip signaling to one or more specific endpoint, and then you can develop a .NET application that manage it. An example could be a reporting third party solution, or some advanced applications that take care of all Lync conversations .

  • UCMA 4.0 (Server side)

– With UCMA we can develop almost all of advanced features needed in enterprise scenario , for example , based on business needs we can develop a full functionally contact center with IVR (not response Group 🙂 ) , routing logic and so on. Great advantage is that we can extend it with all lync communications channel  , such as Audio, Video, IM, federation, Public (Skype, etc…) . UCMA give us also all tools that typically you have to pay so much with other vendors , for example : “Text To Speech”, “Speech Recognition” in a IVR enviroment.

  • UCWA 1.0 (web side :))

–  Unified Communications Web API ,  actually with these API you can develop your own web applications with some features like authentication, presence, IM and the Call Via Work (you simply manage the call forwarding , simultaneosly call, of your lync user) . We hope as soon as they will be ready , also Audio, Video and other lync features could be used in web applications. http://ucwa.lync.com/documentation/core-features .

  • Lync Software Defined Networking (SDN) API

– Imagine that you are at carrier side and you have to monitor some indicators for Lync quality , network performance , etc.. You have to integrate all of these in a third party monitoring system  ; these API is exactly what you need; take a look at this for other informations : http://msdn.microsoft.com/en-us/library/office/dn387069(v=office.15).aspx . A very interesting tool inside this API is the “SIP Obfuscator” that let you to hide username for privacy.

Conclusion

We have a lot of other sources to read about Lync SDK, for example these resources below are absolutely useful and saved my time in a lot of situations   :

Remember that deep knowledge of Lync API is not enough to develop a Lync applications ready for the market , we have to consider that there are a lot of aspects in terms of exceptions, enviroments , usability , integration with other not Lync application  , licensing , security, and so on .

A lot of companies today invest in Lync developing , awesome example are :

 

Lync Online and MSOSIA (Microsoft online Sign-in Assistant) issues

One of the big challenge to deploy a Office 365 enviroment in a big company is doubtless the security…obviously  from corp net to the office 365 cloud and viceversa, but main problems are certainly on Lync online due to the type of authentication with MSOSIA (Microsoft Online Sign In assistant).

Typically in a Lync on premise all of the authentication and communications protocol is managed by Lync servers and there’s not need to use MSOSIA to login, but with Lync Online  all of communications (except the authentication to the ADFS that is internally located ) pass through a web proxy (in each company we have a proxy…) and we are  not sure that this web proxy is a ISA server or TMG server . Here you can find a good KB that describe exactly how to configure an ISA or TMG to exclude the MSOSIA service for each user’s client  :

http://office.microsoft.com/en-au/communicator-help/troubleshooting-lync-sign-in-errors-administrators-HA102759022.aspx

but , as i write before we have to consider that with a SQUID proxy  or other type not well know , not MS,  we have to bypass the proxy and permit Lync to pass directly on Internet . Ok….done.. but typically we have also a firewall between  that work only with ip address (network level) and not name or service (application level) , so we have to exclude  this list provided by MS :

http://onlinehelp.microsoft.com/Office365-enterprises/hh373144.aspx

good to use but in this condition we have to configure firewall with static route, and if subnet change we have to change accordingly on it, but for now is the only way, for this enviroment.

After all you think that now it’s all ok , lync connected fine etc…not completly… because there are another important things to manage on MSOSIA .

MSOSIA is needed to connect to office365 cloud , with it we can obtain the personal certificate that lync use to connect to Lync online cloud ,  and when you install it the first time on a client , after you close the installation windows that seems that all working fine , services MSOIDSVC.EXE try to connect to internet to download  Certification authority CRL to confirm the origin of various root certificate installed on the client, infocert, verisign and so on. But if the client is a Windows 7 and it’s not connected on internet or it have  a web proxy configured that ask authentication to browse to those CA CRL site, at the time of Lync login , we have always this :

At the moment we are investigating how to solve the problem , and at this time the only way to make it work is to disabled authentication in web proxy side for this site :

  • –              *.verisign.net
  • –              *.verisign.com
  • –              *.inforcert.it

An update from MS :

To avoid this on your proxy web authentication you can add and filter to exclude *.crl. 

This is because Authenticode is trying to ensure that the certs that signed the files in use are valid. It does that by checking that the serial numbers are not in the CRL files that the issuing CA produces.

If it can’t get a CRL it assumes the certs are invalid

Also the CRL files have to be cryptographically signed by the same cert as signed the cert in question

If anyone have ideas or comments , please contribute 🙂