Twilio - how to connect two calls (one inbound, one outbound) by SIDs? - c#

I'm trying to develop a workflow for "on-call" workers, which looks a bit like this:
Third party calls our number
Using Twilio, we call each of our "on-call" staff members
The first person to answer and press '1' on their phone keypad, gets connected to the third party
So far we have steps 1 and 2 implemented, and a webhook which receives the "on-call" colleagues pressing a number.
What I can't work out from the Twilio docs is, given the SID of the inbound call from the third party, and the SID of the colleague pressing '1', how do I connect the two calls together?
Using either the .NET SDK VoiceResponse or the Twilio REST API would work.
Is there an API endpoint that I'm missing which allows connecting two calls by SID?
VoiceResponse().Redirect() appears to only take URLs
VoiceResponse().Dial() doesn't appear to have a property to specify a call SID to connect to
Not sure what else..

Related

Best Practices: Adding a CLI to Existing Windows Service in .NET / Core

I'm wondering if anyone has any recommendations for the best way to implement a command line interface to an existing Windows service.
Ideally, the following requirements can be met:
Supports .Net Core and works cross platform
Is self hosted (ie not a separate executable)
Is registered globally and available in any terminal (ie. > myApp doThis -please --prettyplease)
Can be piped through to a web interface for remote terminal access via existing web app
Is available via terminals on other local network devices
The big requirement is that this works cross platform and is not tied to Windows. Any recommendations are very much appreciated!!!
Questions that feature the phrase "what is the best" typically aren't a good fit for stackoverflow as they're subjective - there may be no right answer to your query, but maybe there will be some good ones.
One option that I've employed several times in the past is to implement something like a simple shell/command prompt, accessed via telnet. You simply open a listening socket (TcpListener) and accept text commands sent to it/write text to it, something like your first day's of programming, with console in and out stream printing. There are bucketloads of examples on the web of simple tcp servers so I won't provide any code here. In terms of your points:
Supports .Net Core and works cross platform
It's tcp based, this is intrinsic
Is self hosted (ie not a separate executable)
Starts when the app starts, hosted by the app, doesn't need any complex IPc
Is registered globally and available in any terminal (ie. > myApp doThis -please --prettyplease)
The firewall is probably the only thing stopping your remote device communicating
Call be piped through to a web interface for remote terminal access via existing web app
html5/web based implementations of telnet exist. Could also make a simple web interface out of it (treat the browser like telnet; Here's little difference between them, they both read and write tcp sockets, just the browser adds more text from the http protocol. You can filter that out and just get the interesting bit the user can vary (the URL))
Is available via terminals on other local network devices
Covered above
The last time I implemented this was on a server that was used by credit card terminals. It already had a listening socket and clients followed a strict protocol, so it was easy to detect when a message didn't match protocol and treat it as a command instead. The system grew to the point where the server was full remotely configurable via a simple telnet interface, new credit card ranges and routings could be added,debug printouts could be enabled and all traffic would be sent to the telnet client, certain card terminals could be monitored etc; it was nothin more than compsci101 stuff of command = streamreader.ReadLine(), if(command == "debug") Global.DebugLoggingStream = tcpWriterStream
It had a web interface too, based on HttpListener, that just provided a nicely formatted list of the most recent errors, some config settings etc.. some stuff is better on a web page in a table than in an 80char column format. Eventually I upgraded this to be more like the terminal; the user could end the URL with a command, the command would be carried out and the result put in an array. Each time the page was served he array was dumped, so it became a sort of command shell in itself, not requiring telnet. I kept the telnet interface because it was good for realtime debugging, watching messages as they happened etc but if you wanted to get really fancy, websockets exists today for that sort of thing.
Another thought struck me; perhaps most of this hard work has been done for you, if you can find a c# implementation of an irc server, paired with a web based irc client, it would provide a way to "chat" with your service (which is pretty much all a command shell is; a human having a text chat with a program)

Solution for Calling Clients from Server Application

I have a Windwos Application (Let's name it App) and a WebService Project (name it WS) and a SqlServer Database (DB), and the technologies are all from Microsoft and .net.
The roles are that whenever App needs to do an action, it calls WS and WS does the magic work with DB and then returns the result to App.
So far, so good, but I need something more than that. I need a third Application, let's call it a Robot, this Robot monster should have the ability to find all alive clients (App instances) and not kill, but call them on some specific times, then the App(s) will decide do an action on being called.
My information lacks here, and that is why I want you guys to help me find the best solution for this Server-Calls-Client-And-Client-Does-Something thing.
I have very short handed and pragmatic solution ideas:
Each client application invokes a method for instance YesIamAlive() of the webservice each x seconds/minutes. If the server gets this request it will be saved so you are be able so see which clients are alive. Each client which not sending an alive request for the last x seconds / minutes is not any longer alive. Another method which is also called on a routinely basis and it forces the client to do an action.
You could use SignalR for a websocket communication between your server and client. This example shows a chat server, which is not simular to your request but it shows the idea behind it:
http://braindrivendevelopment.com/2013/01/28/signalr-with-windows-azure-cloud-services/
I am quite sure that there are even more elegant solutions for your problem.
SignalR (GitHub) is an excellent framework for "pushing" to clients in near real-time. It works with both web and WinForms clients.

Can Application Receive Call Using Modem Services

I'm working on a project based on IVR(Interactive Voice Response). In which registration, modification in DB will take place by dialing a telephone number and following simple steps, like that which is used in telecom help centers to change our tariff or SMS packages etc.
Can I use simple voice modem with C# code with TAPI as back-end to mange all this?
Actually, I have "conexant hda d330 mdc v.92 modem". Can I use this to make this type of application...?
If yes, can we handle more than one call on this modem?
If not, what hardware will be required to perform this?

Multiple signalR connections/hubs on your website

If I have multiple pages that could use multiple hub classes, what is the best way to manage this?
For instance:
Is it bad to navigate to another page in the website and essentially "reopen" the connection to the same hub class that was open on the previous page?
Am I correct in thinking that opening multiple hub connections on a page is ok because they are all unified in one connection, even if they are different hub classes?
You can have multiple hubs sharing one connection on your site. SignalR 2.0 was updated to handle multiple hubs over one signlar connection with no lost in performance.
Official docs: http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-server#multiplehubs
All clients will use the same URL to establish a SignalR connection with your service ("/signalr" or your custom URL if you specified one), and that connection is used for all Hubs defined by the service.
There is no performance difference for multiple Hubs compared to defining all Hub functionality in a single class.
SignalR Core - NOT POSSIBLE
Unfortunately this is not possible anymore in the new 'Core' version of SignalR
https://github.com/aspnet/SignalR/issues/456
https://github.com/aspnet/SignalR/issues/955
Notes: Issues with iOS and self signed certificates
On iOS there's a limit of FOUR connections per server.
Now there isn't this limit for websockets (I think it may be 32 but not sure). However I am using a self signed certificate which has all kinds of issues in Safari - so it actually drops down to long polling (and it's not obvious it's done so).
So I ended up with these connections:
1 - Angular / Webpack hot reload socket
2 - Web API calls
3 - Hub number one
4 - Hub number two
5 - #&#&#$&#$&
So if I had ONLY three hubs the whole Safari page would lock up with a blue bar. Even Web API calls got blocked.
Note: With HTTP/2 this limit is gone but you're probably better off limiting yourself to one hub especially if you're using hot reload. Plus setting up HTTP/2 in development isn't necessarily a trivial task.
So how to fix?
First (temporarily) set your hub to only accept websockets. This will give you an error in Safari (make sure errors are being caught and shown in an alert dialog).
routes.MapHub<SignalRHub>("/rt", options =>
{
// when run in debug mode only WebSockets are allowed
if (Debugger.IsAttached) {
options.Transports = Microsoft.AspNetCore.Http.Connections.HttpTransportType.WebSockets;
}
});
Now you'll be able to confirm the fix - run in debug mode, or remove the 'if'.
The problem with iOS is even if you accept a self signed certificate for https traffic - and get a nice little 'lock' symbol in the browser - it doesn't apply to the wss: protocol. So connections cannot be upgraded to wss, which is why they block at the max of 4.
Solution #1
If you can get everything down to one hub it's just easier :-)
I also realized that multiple hubs complicates reconnect logic if the connection is lost. One hub just makes this easier. If you're not careful you'll end up showing 3 dialog boxes saying 'Connection lost. Retry?' I'm switching to a single hub just because of this.
While I hate mixing everything, partial classes help and I personally don't have many SignalR methods anyway.
Solution #2
This is only relevant to debugging, and assumes you're using a https cert which you self-signed.
Use instead something like letsencrypt - or Cloudflare's argo tunnel to get a publically trusted cert. This will be fully trusted by Safari, so your connections will get upgraded to real web sockets.
Solution #3
Create a self signed ROOT certificate (CA) and then generate SSL certificates with the domain name from it.
This was trickier than I imagined. In the end it turned out I was missing Subject Type=CA in my root cert - which iOS requires. Without this 'extension' it will install your root the certificate as a profile, but won't allow you to select it for SSL.
Once you have the root cert installed Safari will work with websockets just fine.
Solution #4
Use http only. This wasn't an option for me because I use certain APIs like Facebook / Google / Payment and they require https.
Notes
Important: Now consider production. Realize that websockets may be unavailable for various reasons, so if you have 4 hubs that are connected on iOS this can still cause blocking. You're living dangerously.
Better to use one hub in the first place. BUT also best to get your cert installed properly so iOS will work with websockets.
How to create and install X.509 self signed certificates in Windows 10 without user interaction?
To start with Hubs read the WIKI entry for Hubs and Client Side of Hubs. There are couple of things according to the context of a multiple pages.
When you start a hub it gives your client an ID which stays the same for that hub (someone can confirm with example) over multiple pages.
Its not bad to reopen the connection to the same hub. You might have hub.start client side method running on all pages however if its one client opening multiple windows or going from one page to another you will have same connection ID on that hub so you can keep in contact. If it was multiple hubs then you have to manage hubs as well as connection IDs. So this question is like "Is it bad to have multiple ISPs serving my internet connection for different websites". You can have them but it is an overkill. A single ISP can server all pages to you as well.
Multiple hubs on a single page is not ideal but it will work. Again the answer need a bit of context to the problem but in general you can differentiate between various requests on same connection ID via groups or using other parameter based approach. Having two hubs on same page may take more resources (need to test this) than using parameters or groups to separate different areas of messaging.
Example:
You have a page that has two parts, a graph which shows real time user activity and an area to see real time data changes done by users as a table. Will you create two hubs or two groups or what? There are other pages which use same graph and data table.
My Solution:
I will create a single hub for the application to recieve real time data from the server.
I will create different methods on server to send graph points and data tables.
I will create client side method on all pages that use these graphs to communicate with server methods on the same hub.
When you switch between pages the client will connect with same hub and request getGraph or getDataTable or both and populate its client with relevant data. Similarly on server when data changes you can call client side method to update all clients or group of them (lets add this complexity)
Assume you have students and teachers looking at your application. They require different level of data access. You can use groups to keep them separate on the hub so you are not sending teachers info to students and students data to teachers.
On your hub join you can add them to join a group associated with their role or any differentiating function.
When you send to all clients , now you can send to group of clients that is teachers or students. Not creating another hub for teachers or students, they are all on same hub.
Coming back to your question of "is it bad" and "is ok" this is difficult to establish without context of actual application. I cant think of a scenario where you can justify multiple hubs apart from Performance.

How to communicate between two different WPF application over LAN?

I want to communicate between two different WPF windows. The WPF UI in first computer generates some data and add to a database table, then it generates a message which includes the unique ID of the new data in the table and forwards it to the another computer. Upon receiving the message with unique ID by same computer, it queries for that data in it and displays in it's UI.
I don't want the WPF application in the second computer to repeatedly (timer based) check the database. Instead I want to have some event listener in this application which just initiates an action upon receiving the message.;
Everything is being operated in LAN where, obviously, two computers are connected within the same network.
A suggestion and better solution will be a great help.
Microsoft have provided a framework for this very purpose:
https://msdn.microsoft.com/en-us/library/ms731082(v=vs.110).aspx
WCF has a variety of flavours dependant on your specific requirements, the link above is a good place to begin your research.
So WPF1 generates ID and WPF2 has to know about it.
Expose WPF2 as a Webservice. Consume the webservice in WPF1.
When ever WPF1 generates ID, it inserts the ID and invokes the WPF2 Webservice.
There are various ways to communicate over LAN:
TCP Listener
UDP
MSMQ
Remoting
You can choose as per your requirement.

Categories

Resources