Can anyone tell me if my call flow below will work with OpenVBX & Twilio and if so, how to set this up there? I'm using Twilio with a trial number to test it out, but no luck so far. I have downloaded a plugin "OpenVBX-Plugin-Queue-master" that looks like it may work, but I can't get it to. I'm not a telephony expert. I am a programmer. =)
Here is what I need. I need to be able to receive multiple calls at the same time and move the caller to the next available attendants.
They need to hear the main greeting, press 1
Then go to the support group ideally (that is not working for me
right now either)- let's say attendant #1.
If attendant #1 is on the phone, put them on hold briefly listening
to another greeting, then send them to attendant #2
If attendant #2 is busy...repeat the process until I run out of
attendants and then they go to VM.
Here is my install version:
Current Version: 1.2.20
Schema Version: 79
Latest Schema Available: 79
Site Revision: 1026
Any help would be most appreciated!
Support for OpenVBX is not active at this time.
I'd suggest you take a look at the guide for Queues.
https://www.twilio.com/docs/api/twiml/guides/queues
Beginning with queuing your caller (an example in Ruby):
require 'sinatra'
require 'twilio-ruby'
# Handles the POST request from Twilio and generates the TwiML that puts caller in a queue.
post '/caller/?' do
response = Twilio::TwiML::Response.new do |r|
# Use <Enqueue> verb to place caller in a <Queue>
r.Enqueue "Queue Demo"
end
response.text
end
You can handle more sophisticated workflows like iterating through agents via TaskRouter.
And this Call Screening tutorial demonstrates how to handle agent voicemail with production ready code.
Please let me know if this helps at all.
Related
I am making a website, where I provide a button which can :
POST a JSON to a route (nothing hard for now)
but the process should also start multiples system commands, and at the end of it provide a zip the user can download
To do that, I think I need a queue. Because two users connected on the same time CANNOT start the process.
Is a queue ok ? But I do not know how to retain the session and send back the zip file...
PS: I am using angular2 & a Python WS.
There are three parts to your question:
First, allow only one execution of your system commands per user at a time.
This could be as simple as maintaining a synchronized flag bit per user, which stores 1 if the request can be processed, 0 otherwise. Whenever a post request comes, first check if this flag is set or not. Continue if it is not 1 return some non-200 status code. Else, set it to 0 and trigger the commands.
Second, handle multiple POST requests that trigger the system commands.
You should use a queue only if your system commands take more time and usually run in the background.
Three, how to retain the session
Retaining a session is not a good idea. You have two options. One, client continuously pools to another end point to check if the zip creation is complete or not. Second, (better than first) use websockets to send the notification back to client once the zip creation is complete.
As far as I understand, in a CQRS-oriented API exposed through a RESTful HTTP API the commands and queries are expressed through the HTTP verbs, the commands being asynchronous and usually returning 202 Accepted, while the queries get the information you need. Someone asked me the following: supposing they want to change some information, they would have to send a command and then a query to get the resulting state, why to force the client to make two HTTP requests when you can simply return what they want in the HTTP response of the command in a single HTTP request?
We had a long conversation in DDD/CRQS mailing list a couple of months ago (link). One part of the discussion was "one way command" and this is what I think you are assuming. You can find out that Greg Young is opposed to this pattern. A command changes the state and therefore prone to failure, meaning it can fail and you should support this. REST API with POST/PUT requests provide perfect support for this but you should not just return 202 Accepted but really give some meaningful result back. Some people return 200 success and also some object that contains a URL to retrieve the newly created or updated object. If the command handler fails, it should return 500 and an error message.
Having fire-and-forget commands is dangerous since it can give a consumer wrong ideas about the system state.
My team also recently had a very heated discussion about this very thing. Thanks for posting the question. I have usually been the defender of the "fire and forget" style commands. My position has always been that, if you want to be able to move to an async command dispatcher some day, then you cannot allow commands to return anything. Doing so would kill your chances since an async command doesn't have much of a way to return a value to the original http call. Some of my team mates really challenged this thinking so I had to start thinking if my position was really worth defending.
Then I realized that async or not async is JUST an implementation detail. This led me to realize that, using our frameworks, we can build in middleware to accomplish the same thing our async dispatchers are doing. So, we can build our command handlers the way we want to, returning what ever makes sense, and then let the framework around the handlers deal with the "when".
Example: My team is building an http API in node.js currently. Instead of requiring a POST command to only return a blank 202, we are returning details of the newly created resource. This helps the front-end move on. The front-end POSTS a widget and opens a channel to the server's web socket using the same command as the channel name. the request comes to the server and is intercepted by middleware which passes it to the service bus. When the command is eventually processed synchronously by the handler, it "returns" via the web socket and the front-end is happy. The middleware can be disabled easily, making the API synchronous again.
There is nothing stopping you from doing that. If you execute your commands synchronously and create your projections synchronously, then it will be easy for you to just make a query directly after executing the command and returning that result. If you do this asynchronously via the rest-api, then you have no query result to send back. If you do it asynchronously within your system, then you can wait for the projection to be created and then send the response to the client.
The important thing is that you separate your write and read models in classic CQRS style. That does not mean that you cannot do a read in the same request as you do the command. Sure, you can send a command to the server and then with SignalR (or something) wait for a notification that your projection have been created/updated. I do not see a problem with waiting for the projection to be created on the server side instead for on the client.
How you do this will affect you infrastructure and error handling. Also, you will hold the HTTP request open for a longer time if you return the result at once.
I am running asterisk on a elastix 2.2 distro. I have a Queue with EXT 9000 where 3 softphone (c#) extensions belong to this round robin queue.
I know that I could trigger a AGI or AMI event from the dialplan and let in some way a webservice know about the length of the queue and then forward this information to the softphones.
Is there any way that the softphones could get this information directly from asterisk. Either something AsteriskBuiltIn or ElastixBuiltIn.
a last resort (baaaaaad) idea was to open a line, call an encoded number like (555*1) and receive back a dtmf. it is a Bad Way but it would work.
Open for any suggestions
Queue drop events into ami.
Also queue log all actions into /var/log/asterisk/queue_log, which is posible put to mysql(see this)
There are no way say how your softphone can catch that event. But for sure you can get that info from mysql and rewrite your softphones to show that info.
Also elastix call center edition have web panel for call center. As option you can check fop2 project for panel.
I am going to use Laravel 4 queues and integrate them with Iron.io
All of that is pretty straight forward, and I dont think I am going to have problems with that.
Thing that interests me is what is the best way to get status once task is completed?
Iron.io is going to do return call to my server to trigger job, and once that job completes I need to notify user about that...
How could I store this responses, and still be aware of job its related to, because there will be number of different job types?
I would like to hear how did you implement this.
Thanks
As Joseph pointed out in the comments, you'll need to:
Hopefully have a job quick enough for it to be finished when a user is still in browser
Use some sort of way to PUSH data back to your web browser.
The popular methods are:
Websockets
Server-sent events
Long polling - with ajax
I'm trying to implement a basic but flexible "event queue" so that my web app can go run subs asynchronously. The way I have working for me now is the app writes a record to an "event queue" table in my database with info on what to do and when to fire. Then I have a daemon script that queries that table periodically and if something needs to be done, it fires it off.
I'd like to start moving towards watchers using something like AnyEvent or EV so I'm not hitting my database so often, but try as I might, I can't find good info on "best practices" for setting something like this up. AnyEvent's documentation is pretty good, but it seems to assume you know how your events should be passed around...which I don't.
What should my watcher be watching? A file? If so, what should be in that file? I don't need to send a whole bunch of data around, I just basically need something that says, "go off and run this sub right now"
I would greatly appreciate someone pointing me in the right direction.
EDIT:
It's been requested that I be more specific: The events I'm trying to fire are various. Sometimes it's an email that needs sending, sometimes it's some DB work, sometimes I just need an action to be delayed for a few hours or days. In all cases, I have some sort of backend script to handle the action, I just need a way for my frontend (web app) to tell my backend, "hey I need you to go do this in x minutes" or "I need you to do this now"
You might look at Mojolicious which is built to be non-blocking and respond asynchronously. It even uses EV internally if you have it installed. To get started read the doc for Mojolicious::Lite and then the Guides (in order) from here: http://mojolicio.us/perldoc
So what is it that you are actually trying to do? Until you describe what it is you actually need, I can't help you any further that that.
There are some CPAN modules in order to run asynchronous tasks via message queues. Examples:
Queue::DBI
POE::Component::MessageQueue
Any::MQ