CODEWITHSUNDEEP
asp.netconfigurationskype-for-businessucma
Nithisha Nasser
Nithisha Nasser

Reputation: 47

How to point UCMA code to a dedicated Skype for Business ID

I am new to UCMA Bot development. I started my work with the sample application given in UCMA 5.0 SDK (named BuildaBot). I am not able to set up a application endpoint. I have created a dedicated SkypeforBusiness ID for this Bot.This is created within my organization cloud. I have deployed the code in our on-premises Server. How will I make my code integrated for this Skype ID.

I found in other QuickSamples in UCMA 5.0 SDK, they were using Userendpoint. I am able to use Skype ID (the one for Bot) here in the App.config and application is running in local. In production scenarios, where the Bot is targetted for many users, is it okay to use Userendpoint?

Upvotes: 0

Views: 780

Answers (2)

Nithisha Nasser
Nithisha Nasser

Reputation: 47

Its unlikely to find a ready made code for UCMA over internet. After a lot of work, I figured the answer to my question. For others reference, I am updating it here.

How to create UCMA User Endpoint

  1. Get a dedicated SFB Id (like [email protected]), which will work as Bot.

  2. In the App.config, provide this Bot parameters(value) necessary for the sample to run.

    <appSettings>
Provide the FQDN of the Microsoft Lync Server-->    
<add key="ServerFQDN" value="" />

<!--The user name of the user(BOT) that the sample logs in as -->
<add key="UserName" value="" /> 

<!--The user domain of the user(BOT) that the sample logs in as -->
<add key="UserDomain" value="" />

<!--The user URI of the user(BOT) that the sample logs in as, in the format sip:user@host-->
<add key="UserURI" value="sip:[email protected]" />

<!--The user URI of the user(BOT) that the sample logs in as-->
<add key="UserPwd" value="" />

</appSettings>

  3. In the Program.cs, place these below codes. This will establish User Endpoint. Which means, you have mapped the BOT id with the application and now your application will work for that Bot id.

    using System.Configuration;
using System.Collections.Concurrent;
using Microsoft.Rtc.Collaboration;
using Microsoft.Rtc.Signaling;

namespace Bot
{
public class Program
{
private static string sipaddress = ConfigurationManager.AppSettings["UserURI"];
private static string username = ConfigurationManager.AppSettings["UserName"];
private static string password = ConfigurationManager.AppSettings["UserPwd"];
private static string domain = ConfigurationManager.AppSettings["UserDomain"];

CollaborationPlatform _platform;
UserEndpoint _endpoint;

static void Main(string[] args)
{
var platformSettings = new ClientPlatformSettings(userAgent, SipTransportType.Tls);
    _platform = new CollaborationPlatform(platformSettings);

    UserEndpointSettings settings = new UserEndpointSettings(sipaddress);
    settings.Credential = new System.Net.NetworkCredential(username, password, domain);
    settings.AutomaticPresencePublicationEnabled = true;

    _endpoint = new UserEndpoint(_platform, settings);
    }}}

Further you have to code , in order to receive messages and reply to the messages.

Upvotes: 0

Shane Powell
Shane Powell

Reputation: 14148

First you need to understand the types of applications that you can write with UCMA:

  1. Trusted Server Applications
  2. Client Applications

Trusted Server Applications

This type of UCMA application is the most powerful and you can use either ApplicationEndpoints or UserEndpoints (via impersonation). They are constrained to only run on specific pre-setup machines (application pools). So setup to run a trusted server application is a lot higher and more difficult than a client application. A trusted server application does not require any usernames or passwords, they are setup using digital certificates (another setup issue that can happen is sorting out the correct certificates). This means it's very easy to use UserEndpoints to impersonate a user once running.

Client Applications

UCMA client applications can only use UserEndpoint's. For a client application to use the user endpoint it must know the username/password details for the user they wish to use. They are also not as "trusted" as a Trusted Server Application UserEndpoint is (although you may not ever need the extra privileges anyway).

Both applications types can do that same sorts of things, so it mainly comes down to running requirements.

Next you need to understand what the two types of endpoints are:

ApplicationEndpoint

An application endpoint can only be used by a Trusted Server Application. There are also no CAL requirement for an application endpoint (Client Access License). The no need for a CAL may be the main reason for going this route.

UserEndpoint

A user endpoint is a standard Lync user setup via AD integration, so there is normally a UserEndpoint per AD user. UserEndpoint's require some sort of CAL to be assigned. Either the "free" CAL license or the different levels of paid CAL licenses depending on the features required.

Both endpoint types are just SIP endpoints that you can do the same things with. So you can write a bot using either one. My guess would be a Trusted Application using ApplicationEndpoint's just because you are not required to pay CAL costs on application endpoints and you can create/use as many as you need. Also creating application endpoints (I find) is easier than having to create AD users as well.

Upvotes: 2

Related Questions