I have a WCF service allowing users to connect to different protocols accounts (like Yahoo)
I'm now interested in adding a "microsoft" feature to this WCF, so users can connect to their msn/skype/lync account.
I've searched online and found good infos on how lync and LCS don't work together, but nothing really clear about the microsoft plans of regrouping APIs. (now that the own Skype)
2 questions:
I] Is there something I've missed (like a nice unified microsoft API) or should i really use different & separate APIs?
(skype API mentions: The Skype Public API is no longer being improved, although it is still being maintained)
II] Lync API needs Lync client to be install on the computer: it re-uses the lync server connection. I'm afraid i'll have problems if I try to implement it on a WCF. (multiple connection, authorization, disconnection of the "real" client if he uses lync in his Outlook)
Thank you
Dont know about all questions, but Lync definately allows multiple connections for a single user. I'm using a trusted server application (in a hosted service) in which I create user endpoints for people connecting through the service. This has no impact on any other connections a user might have.
Related
This may be a very simple issue but is (I think) complex to explain so, please bear with me.
We have a WCF API (written in C#) on our server which attaches to third-party APIs (a sort of one-stop place, if you will). These use a mixture of OAuth and certificates for security. The idea is that we don't have to put (the third party) certificates / security on all of our servers, just the one.
Therefore, the plan is for an application on one server to call the API on this server which calls the third-party API. This seems to work for all but one third-party.
If I use the Visual Studio (2017) inbuilt WCF Test Client on our API, it works fine. If I try to use our API from another application (by adding a service reference) even on the same server it fails with the above message.
Our API does not (yet) use https.
The plan is for use to release our API to others so we can't share any certificates / logins with them - this is the underlying reason for our API.
I have done a lot of Googling about this and all of the answers seems to point to the certificate has to be on the calling application which would seem to defeat the object of our "catch all" API
I have probably not explained this very well - sorry. Maybe the issue could be summed up as "how do I stop the security being "passed down" to the calling application?"
Seems that the culprit was the Application Pool Identity that "Our" API was running under. I changed that and now everything works as I would expect it to :)
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.
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
I have created UCMA trusted application using C# console application.
I want to monitor all Lync Users instant messaging calls (in one place) as well as store their conversations in the database via this console application.
Is it possible?.
If possible, please give an idea or any url.
UCMA trusted applications will only respond to traffic to the endpoints associated with that application so if you want to monitor all instant message traffic it would be the wrong API.
I would suggest using SIP Application API http://msdn.microsoft.com/en-us/library/office/hh364644(v=office.14).aspx to create a server application. This will also require the use of MSPL documented here
As Dai has asked - is the console application a requirement or will a windows service be ok?
Try our this sample application SipSnoop it basically shows all the metadata passing throught the lync server, you can tweak around it according to your requirement.
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.