I'm working with Microsoft's Bot Development Framework. They've released a calling API to handle taking calls, but what I'd really like to do is call a user on Skype (i.e. initiate the call). I don't believe they can do this currently, so if not are there plans to add this?
Skype doesn't offer this functionality at this time. I don't have any information about plans to implement bot calling the user with voice, but I will pass on the request to the Skype bot team.
Related
I have a use case where I want to build a portal for Agent Login and Registry and allow conversation to be transferred from Bot to an agent.
Looking at this article for possibilities -
https://blogs.msdn.microsoft.com/jamiedalton/2017/08/10/microsoft-bot-framework-handing-off-to-a-human-for-agentssupervisors-with-c-and-the-botbuilder-sdk/
The handoff should happen from customer using webchat and bot logic is coded in C#. The steps that I could think of -
User asks for handoff
The Bot logic connects the conversation to signalr hub on server side
The next conversation takes place directly using this hub.
Need to know if someone implemented such use case. What should be approach for creating this?
Look over the intermediator bot sample. It is designed to work with v4 of the BotFramework demonstrating bot-to-human hand-off in C#. You will, of course, need to adapt it to work with SignalR. But, I don't see any reason it couldn't be configured to do so.
I need a way to automate processing of messages/files sent in a Telegram channel. I've been told that is can't be done with a telegram bot since they can't join channels, nor am I the owner of the channel, so I would need to set up a client or to use regular Telegram API to be able to do that. I'm looking for guidance, suggestions, anything that could help me. The script/client will have to run on Windows (so I can't use the cli linux version).
You can try UNOFFICIAL PWRTelegram API, it can be login in use a user account, and have HTTP API like bots.
You can click here to see usages.
I've seen examples of bot programming that work with "Skype". Is it possible to develop enterprise bots that run on "Skype for Business" using Microsoft's Bot/Cognitive service tools/framework?
Skype for Business is not yet supported by Bot Framework. To find all the messaging channels that are supported visit the Bot Framework's documentation site.
The Microsoft Bot Framework now officially supports Skype for Business as a channel:
Skype for Business Bot Framework (Preview)
(As of writing this its in Preview mode, so things may change in the future. But at least its there.)
Skype for Business does use UCWA (Unified Communications Web API), though the documentation is pretty dated it is possible to have a user account for the bot and use the API calls for direct messaging.
This also requires some knowledge of the server that your Skype for Business is running through.
Further going thru the Build 2016 videos and Microsoft support site reveals Skype bot programming is limited to consumer skype and not for "Skype for Business". It seems microsoft has future plans to bring this to "Skype for Business"
Yes, bots can be built for skype for business, please have a look at the following link.
http://acuvate.com/blog/chatbots-on-skype-for-business/
I saw on internet that there is some programs that can use Telegram CLI.
I want to choose between them
for Telegram bot API there is much more documents explaining its functionality, but for CLI there isn't much that explains its features
it seems the only way to know about is to experiment with it.
unfortunately i don't have a linux distro installed on my pc so experimenting isn't an option right know.
so I thought to ask from people who already used it
I know about Telegram bot api, its powers and its limitations
here is my questions:
what can I do using Telegram CLI that I can't do with with bot api, and vice versa?
Telegram bot API:
do not require to register new Telegram account, so you don't need to have another phone number;
bot cannot write to user first, only after user sends a first message to bot;
already has the commands interface (/command);
can do stuff by simple HTTP POST (by sending request via cURL, for example). So you can hook to this tons of stuff (notifications about new articles at the website or so);
you can rather easily create lots of them;
you can write you own implementation in almost any programming language;
you have a list of bots you have created (thanks to #BotFather). If you have lost somehow control of your bot - just revoke the token via #BotFather and it's yours again;
pretty simple to use.
Telegram client application (in this case - CLI):
requires new Telegram account registration with phone number;
acts like any other actual Telegram user (can write to other users first, without invitation). Well, that's a good thing;
not really good cross-platform abilities for now (some lack of CLI-realisations);
not really easy to install and use;
you have to implement the commands handling part;
if you have lost your phone number - pretty much you lose this account, because it's not like you would make some precautions for CLI client account. So you will have to register a new one and repeat the setting procedure for client.
In conclusion, bots actually got rid of CLI clients, in my opinion. I had CLI account right to the moment the bots appeared. After that I deleted it and created a bot. And not just one :)
So, bots are for the "robot" stuff, and real accounts are for the real people.
The Telegram CLI library interacts directly with their MTproto protocol, which means it's like their desktop/mobile app...but for the console. You can send messages from one phone number to another. This means that when authenticating with the CLI application, you use your real number as if you were logging into the mobile application.
I wouldn't suggest using it for bot behavior as you have to write an application that wraps the Telegram CLI and parses the log file as it is displayed...since it doesn't implement all the MTproto methods and the outputs for the log file are custom...it can be quite annoying and different than what you would expect.
With Telegram CLI you can send a number to another Telegram user without having them initiate the conversation first (since it functions just like a normal Telegram client) where the Bot API requires the user to add the Bot and start interaction before the Bot knows you are there.
previous answers are almost correct. Two different interfaces for different purposes:
Telegram Bot API allows to develop a Telegram Bot.
Telegram CLI (as this one, as an implementation example: https://github.com/vysheng/tg) are telegram client implementations, running from command line, based on MTproto protocol, as Chris Brand said.
As a bot developer, I'm interested to have a TG CLI interface (2) to automatize dialogs tests, with bash scripts, with a bot made with (1).
We are using Lync 2010 server in the office. I would like to create a customer facing website that allows clients to chat to our support reps over this platform. Ideally, I would like the customer to just see the default web based interface for communicator.
When you have a chat going in Lync (Formerly office Communicator), you can invite someone to chat by email. That sends the user a link to join in the chat using the web version. I want to emulate that functionality on my webpage.
It looks like the Communicator AJAX API is promising, but all examples are for building your own custom interface and everything. I just want to link our site to the web access version.
Any ideas?
The Communicator AJAX API is no longer around, so the recommended way to do this would be to use UCMA 3.0 to build a middle-tier bot to handle the web chat.
In it's simplest form, the bot could expose a method (e.g. StartChat) via WCF, which could then be called from your web page. On receiving a call to that method, the bot could then start a new conference, and invite the support rep to it.
Once the conference is created, you could then return the URL of the conference (the same one that's used in the email invitation) to the web page. The web page would then open a new window at that URL, which would kick-start the Silverlight client.
In reality, you would probably also want to add a few extra features, such as
Allowing support reps to log-on to the bot to signal their willingness to take external calls
Aggregating the presence of the logged-on support reps, to display availability to the web site user
Route the call specifically to the logged-on support reps, and provide a way for them to accept the call
This codeplex project would be a great starting point.