what are difference between "Lync Server 2010 SDK" / "UCMA 3.0 SDK" / and UCC API? - ocs

I'm looking for the client side and server side API for Lync 2010. But I found many API that can be able to develop. Anyone what are difference between all of them? Please help
Microsoft Lync Server 2010 SDK http://www.microsoft.com/downloads/en/details.aspx?FamilyID=58ccf6fd-31db-4f15-bafb-c5ef28afc5fc
Microsoft Unified Communications Managed API 3.0 Software Development
Kit
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4493BAAB-6214-4770-8CF9-69C813E8A9FA
Microsoft Unified Communications Client API SDK
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=82c468da-3294-4ca9-bbcc-d455cfd06af2

Lync 2010 SDK is the latest Client-side SDK for Lync 2010 (doesn't work against previous versions). Its a fully managed (i.e. .Net) API, and allows you to build apps that automate the running instance of Lync to perform tasks, e.g. display presence and start a conversation from your LoB app (Automation mode). It also allows you to build your own custom clients to completely replace the Lync UI (UI Supression mode).
Unified Communications Managed API 3.0 (UCMA) is the latest server-side SDK for Lync 2010 (doesn't work against previous versions) - its also a fully managed API, and allows you to build applications that register to Lync as endpoints. This is useful for building bots, for example, a stock ticker bot that IMs people when a stock price goes over a certain threshold. You can also build call routing and IVR (interactive voice response) apps with this, and it can use Windows Workflow Foundation to reduce the amount of code you have to write.
Lync Server 2010 SDK is another server-side SDK, but rather than creating endpoints as per UCMA, this allows you to write filters that plug in to a Front End server. A filter allows you to inspect SIP traffic as it passes through the server, so its useful for building e.g. archiving solutions.
Unified Communications Client API (UCCA) is a client side API that allows you to build custom endpoints - e.g. Lync client replacements. This is best avoided, as it is COM based, so you have a lot more code to write, and need to be very careful about memory leaks. Its recommended to use Lync SDK in UI Supression mode, instead of this API. One benefit it does have though, is it works against Communicator 2007, Communicator 2007 R2 and Lync.
If you're developing against Lync and no previous versions, then Lync SDK (client) and UCMA 3.0 (server) should give you what you need. Otherwise, this article here talks about the previous SDKs in a bit more detail
Edit: I've expanded on this in a blog post

The main difference for me between Unified Communications Client API and UCMA was that UCC supports digest auth and that's why it is possible to build sip/rtp client for linux based asterisk.

Related

Test Automation: Automate outgoing calls from fixed phones registered with a Skype for Business IP-PBX

For test automation purposes, we're currently investigating upon how we can have a fixed phone registered with a Skype for Business IP-PBX (e.g. an AudioCodes phone or a Yealink phone or...), make an outgoing call upon request.
E.g. Our test automation platform would send a request to the Skype for Business Server to tell this server to initiate an outgoing call from phone A registered with that Skype for Business Server to an external phone B. So a little bit similar as JTAPI functionality...
I.e. Would this be feasible by using UCMA 5.0?
There is no way to SIP to make a physical phone make a call.
With UCMA you are effectively a softphone, so with UCMA you can make your "softphone" make a call.
With the Lync Client API you are remote controlling the Lync Client (Skype for Business client), so with the Lync Client API you can remote control the Lync Client to make a call.
The only way I can think of to make a physical phone dial would be to use a Polycom VVX phone linked to a instance of a Lync Client using there "Better Together" application. Then you can use the Lync Client API to remote control the Lync Client which would in turn remote control the Polycom VVX phone.
I haven't done this in a Skype/Lync environment but I've done something similar in Asterisk a long time ago. I don't remember all the details of the test any more.
One key to get hardware involved, if you don't use a BToE connection, is to leverage the "Auto Answer" answer feature on most handsets.
I have seen some phones also allow for some push/curl commands to be sent to the device. An example of this with a polycom is here. The post is old and it's been years since I messed with that, but I assume some of that function may still be in some devices/firmware. I haven't seen anything similar with AudioCodes or Yealink, but they maybe there as well.

Should I use UCWA or UCMA or another API for a Skype for Business Server Application?

There seems to be a lot of different SDKs / APIs around Skype for Business. I'm having a tough time deciphering which one would be appropriate for a server side Bot like application that could communicate domain specific information to the users within the organization. For example we'd like to be able to deliver task(s) via messages and perform presence based task assignment. This seems to be fairly low hanging fruit but where's the REST endpoints and documentation to make this happen. Assuming for example I wanted to create a little console application that could facilitate this what API would you recommend?
Here are the main differences between UCMA and UCWA:
UCMA is a .NET SDK that provides rich control over a Skype for Business server deployment. It enables applications to automatically route calls and messages, provide automatic responses (IVR or chat bots), record conversations etc. It can be used in a number of scenarios such as a 'contact center' application that distributes incoming calls to an available agent with the right skillset. UCMA applications are managed by running them on application servers that are activated as part of the Skype for Business server deployment. As such, UCMA is not available for Skype for Business Online (Office 365).
UCWA is a RESTful Web API that acts on behalf of a single Skype for Business user. It enables applications to send and receive messages for that user, read presence for their contacts, etc. Typically it is used for interactive "line of business" applications that want to embed Skype for Business messaging/presence. It is also possible to create a 'technical account', that doesn't correspond to a real person, and use UCWA in 'headless' server applications but this approach currently has authentication and scalability limitations. UCWA applications have no deployment constraints since UCWA is a regular RESTful Web API. It is available for both Skype for Business Server (get started) and for Skype for Business Online (get started). The latter has slightly fewer capabilities right now: - for example, messages can be sent but not received - though this should change soon.
I think both UCMA and UCWA can be used. However, considering you want a server application, UCWA seems fit the case. Here is the detail of SDK, you can find code samples at there:
https://msdn.microsoft.com/en-us/library/office/mt650889(v=office.16).aspx

Difference between Office 365 REST Api and Microsoft Graph

I would like to know difference between Office 365 REST API and Microsoft Graph, since we could find similar functionality for both of these.
https://msdn.microsoft.com/en-us/office/office365/howto/rest-api-overview
Following is the text from above link:
Office 365 API functionality is also available through Microsoft
Graph, a unified API that includes APIs from other Microsoft services
such as Outlook, OneDrive, OneNote, Planner, and Office Graph,
accessible through a single endpoint and with a single access token.
If there is no such difference, do you plan to deprecate any of these?
Thanks
Microsoft API is one endpoint solution to access the Office 365 services like mails, calendars and .etc. By using the graph api, no more obtaining separate tokens for different services or calling a different endpoint for each API.
Some features may be available on the individual service endpoints,
but not yet on Microsoft Graph. We are working hard to bridge these
gaps. If you require one of these features, you can use the individual
endpoint in the meantime. Check the release notes for details on the
Microsoft Graph features in preview and generally available.
For details, you could refer the document Choosing your API endpoint.
The Documentation state that Office 365 API functionality is also available through the Microsoft Graph, a unified API that includes APIs from other Microsoft services such as Outlook, OneDrive, OneNote, Planner, and Office Graph, accessible through a single endpoint and with a single access token. We recommend using the Microsoft Graph in your apps when possible.
Also see this answer it says
Our recommendation is for you to use Microsoft Graph as long as it has the features/APIs you need in production to support your production apps, or at least in Preview to support app development. This makes it easy for you, in the future, to expand your app functionality requiring access to multiple Microsoft services, without changing endpoints. You can use individual service endpoints such as Outlook REST API if you need a feature that is only available in the individual service endpoint, either in production (v2.0) or as preview (beta).

Is Live SDK deprecated?

As I have understand - Live SDK has supporting 2 main features:
OneDrive and Microsoft account
Now with release OneDrive SDK all OneDrive features are coud be found in it.
But if you want to access Microsoft Account you still can use only Live SDK.
Seems that now we have 2 branches - Live SDK and OneDrive SDK.
One for account and another for files.
I am asking because sometimes it's not clearly written and looks like live SDk is depricated.
They are deprecated according to this:
The Live Connect APIs are deprecated. We recommend that you use the
Outlook REST APIs to build your solutions. This will extend your reach
to Outlook.com users and Office 365 enterprise customers. Although the
Live Connect APIs will be supported in Outlook.com for the short term,
existing Live Connect API solutions might stop working without
advanced notice. If your app is using IMAP with OAuth 2.0, it will
continue to work, but our REST APIs are the primary APIs for building
apps that connect to Outlook.com and Office 365. Read the article on
how you can take advantage of the Outlook REST APIs.
https://msdn.microsoft.com/en-us/library/hh243641.aspx

WCF, Windows Store apps, and reliable sessions

Is it possible to use WCF reliable sessions in Windows Store apps?
I am writing a Windows Store app in Visual Studio 2012 Professional using C#. I am trying to access a WCF service using sessions. I can't use WSHttpBinding because Windows Store apps don't support it. I found that Windows Store apps DO support NetHTTPBinding, which supports reliable sessions, but I can't seem to access the ReliableSession property of the binding, nor can I access the constructor that takes "bool reliableSessionEnabled" as a parameter.
Is there ANY binding that supports sessions for Windows Store apps?
-Joe
As stated in the documentation (Version Information section), ReliableSession property is not available for Windows Store apps, i.e. WCF reliable sessions are not supported.
This article describes the complete subset of WCF functionalities available in Windows Store apps. Although NetHttpBinding is included, ReliableSessionBindingElement is not.