If a call is incoming when using a Client Browser (twilio.js) and I am already connected to an active call in the Client Browser. Client Browser doesn't ring or given any indication of an incoming call while I'm already on a call with someone else.
Is this a bug? What can be done about it so I can tell if there is an incoming call? I need to be able to answer that 2nd, 3rd, 4th, etc... incoming call should I have multiple people calling my Twilio number at the same time.
Kind of a late reply but you can use the Enqueue verb to place your callers in a queue, and then use the REST API with a javascript setInterval to list the callers in the queue. After that you can dequeue them with a Dial method or via the REST API.
We have crafted call-center functionality in node using a similar method where callers are placed in a queue which triggers a setInterval loop that monitors the queue for its members, and also looks for available agents to call.
For anyone interested I have solved this problem for myself, but in a different way to what #Ding suggests.
I'm not sure if the API has changed since this questions but you are able to access multiple Connections from a single Twilio.Device(). See this question for more details: Twilio call routing/management for small customer service team
Related
can someone point me to a service with api that can make calls to some numbers?
Just call, without any kind of voice, even if the call is answered, it is immediately disconnected. This would serve as a notification that the siren was on (o Will save that contact number “alarm on”), from a small alarm system I made. I had ideas on using ifttt to call this service's webhook. But o Only find services more complete and more expensive.What are you using? Thank you
I am currently using Twilio Studio to build a customer service process that allows clients to make calls to a Twilio number, which redirects to representatives.
How can I allow clients to send a voice message (voicemail) if the call is not picked up or if the call is not within working hours. Thanks!
Twilio developer evangelist here.
With the Connect Call To widget you can connect further widgets after either the call ending or the caller hanging up. In your case, you need to decide whether the call ended successfully or because the call wasn't picked up. You can do this by adding a Split Based On widget after the Connected Call Ended transition and testing on the DialCallStatus.
DialCallStatus can be any of completed, answered, busy, no-answer, failed, or canceled. In your case you are looking for "no-answer". You can use the Split widget to direct the flow onto the Record Voicemail widget when that happens.
As for calls not within working hours, that is a bit more complicated. To get the current time and compare to working hours will require you to run some code. You can do this with a Twilio Function, for example. There is an example application in the Twilio Code Exchange that implements this functionality but you would need to adjust it to use within your Studio Flow.
In wcf when i send to method which is one way-
I don't need to get answer now...
later,I need to get an answer for sure.
But how can I be sure that he got the message (to deal with it later )?
What about the 202 reponse ?
http://thejoyofcode.com/One_Way_operations_in_services.aspx
I think the article that you linked to does a nice job explaining it:
a one-way service call doesn't wait for the call to be processed, only
to be delivered - where delivery includes deserialization of the
request.
If you don’t get an exception then the message was successfully acknowledged as received.
IsOneWay introduces asynchronous aspects to your API. If you choose to go that route and you want to know what happened after the message was received, you’ll have to build that mechanism yourself. At a high level there’s nothing WCF specific about the solution. Either:
Call the service back and ask what the result was –OR–
Have the service call you back when its done
My WCF service(hosted as Windows Service), has some 'SendEmail' methods, which sends out emails after doing some processing.
Now, I have got another requirement where client wants to preview emails before they are being sent out, so my WCF service needs to return whole email object to calling web app.
If client is happy with emails object, they can simply click 'Send out' which will then again call WCF service to send the emails.
Because at times it can take a bit longer for emails object processingy, I do not want calling application to wait until emails object is ready.
Can anyone please guide what changes I need to make to my WCF service (which currently has all one way operation)?
Also, please guide me whether I need to go for Asynch operation or message queuing or may be a duplex contract?
Thank you!
Based on your description I think you will have to:
Change current operation from sending email to storing email (probably in database).
Add additional operation for retrieving prepared emails for current user
Add additional method to confirm sending one or more emails and removing them from storage.
The process will be:
User will trigger some http request which will result in calling your WCF service for processing (first operation)
WCF service will initiate some processing (asynchronously or firt operation will be one-way so that client doesn't have to wait).
Processing will save email somehow
Depend on duration of processing you can either use AJAX to poll WebApp which will in turn poll WCF service for prepared emails or you will create separate page which will user have to access to see prepared emails. Both methods are using second operation.
User will check prepared email(s) and trigger http request which will result in calling third operation to send those emails.
You have multiple options:
Use Ladislav's approach. Only to add that service returns a token and then client uses the token to poll until a time out or a successful response. Also server keeps these temp emails for a while and after a timeout purges them.
Use duplex communication so that server also gets a way to callback the client and does so when it has finished processing. But don't do this - and here is my view why not.
Use an Asynchronous approach. You can find nice info here.
I'm writing an API which is used to receive some data from another application. Currently the function is designed to block until data is received. In my mind this limits developers using the API to use multithreading or some sort of multi-process design. So is it better for a function to block or to return a null and then sleep for a few milliseconds before trying again.
Note the other application may not have any data to send through the API for an unknown period of time.
The API is written in C++
Why not use a callback?
You could define the API to allow the user to pass an optional timeout value. If the timeout is not specified, then the API function waits indefinitely, much like how select() works.
Consider another option: use an async transaction -> issue a request & provide a callback address with ticket id. When the response is available, the service end-point callbacks your application with the ticket id and of your the result ;-)
You should avoid as must as possible blocking when you possibly can.
As you say:
Note the other application may not have any data to send through the API for an unknown period of time.
In this case, using a synchronous interface ties up resources unnecessarily.
You haven't said what language this is, but it sounds like your API is listening or checking for some event, and the users of the API are either blocking or polling your API to determine if the event happened?
Is it possible to use a callback? Users of the API would register for notifications of the event happening, and when your library detects the event it will use the callback to notify all listeners.
When your applications calls the O/S api function read(), do you expect it to block? Of course you do—at least by default. In some circumstances, ioctl's allow a programmer to change the behavior to be asynchronous, which is particularly common in network applications.
You've shed very little light on what your API is about, so consider:
Does it make sense that an API user would want to be blocked? That is, is there little to do until it returns.
If you were writing an application for the API, what would you expect it to do? You should definitely write a few sample applications for your own education, as well as to document the API.
Is there any reason why the API user would not multithread (or fork, etc.) requests to the API?
If you want a reusable solution you could apply the Asynchronous Design 'Pattern' which is common in .NET but can also be implemented in C++ as demonstrated in this CodeProject project.
There's nothing wrong with providing both synchronous and asynchronous calls to the same feature in the interface.
Personally I would only go these lengths if I need to service multiple requests (in which case you can queue 'BeginOperation' requests for example), or there are many potentially asynchronous operations in the interface (and I want a standardised, flexible pattern). If you can only handle one request at a time a time-out is usually sufficient.