(Note: FS-> Freeswitch)
Following is the use case that I want to achieve using FS:
FS makes an outbound call to a PSTN user A.
A picks up the call and is greeted with a welcome message.
A then dials another PSTN number (that of user B) using the dial pad.
FS captures the number and calls B.
B picks up the call and FS joins A and B.So that A and B can communicate with each other now.
it's quite easy. You build an IVR which accepts the destination number and bridges the call to B. Then you call the originate command from CLI or external script to call A and execute the IVR.
You probably need to read the FreeSWITCH book first :)
Related
I'm trying to write a logic (js script) to communicate with external system. As far as understand, logic will be executed on all endorsing peer.
In this case, how can I avoid duplicate operation to external system ? For example, how to increment a value in external database ? If I write a logic to increment the value in js, I think the value will be incremented by all endorsing peer.
I'll appreciate any comment.
Firstly, currently the only way you can interact with external systems is using the experimental post API. This allows your Transaction Processor function to HTTP POST data to an external system and then to process the response.
Documentation here:
https://hyperledger.github.io/composer/integrating/call-out.html
You are correct in stating that if you have 4 peers, then the chain code container for each peer will run your logic, so you'd expect to see 4 calls to your HTTP service. This is required because each peer node is independent and Fabric must achieve consensus across the peers.
The external functions should therefore (ideally) be side-effect free "pure" functions (idempotent), meaning that for a given set of input parameters you always get the same set of output results.
Clearly a function that returns an incrementing integer doesn't fit this description! You probably need to rethink how you are structuring your problem to make it compatible with a decentralised blockchain-based approach.
I've been trying to implement a call centre type system using Taskrouter using this guide as a base:
https://www.twilio.com/docs/tutorials/walkthrough/dynamic-call-center/ruby/rails
Project location is Australia, if that affects call details.
This system dials multiple numbers (workers), and I have run into an issue where phones will continue to ring even after the call has been accepted or cancelled.
ie. If Taskrouter calls Workers A and B, and A picks up first they are connected to the customer, but B will continue to ring. If B then picks up the phone they are greeted by a hangup tone. Ringing can continue for at least minutes until B picks up (I haven't checked if it ever times out).
Similar occurs if no one picks up and the call simply times out and is redirected to voicemail. As you can imagine, an endlessly ringing phone is pretty annoying, especially when there's no one on the other end.
I was able to replicate this issue using the above guide without modification (other than the minimum changes to set it up locally). Note that it doesn't dial workers simultaneously, rather it dials the first in line for a few seconds before moving to the next.
My interpretation of what is occurring is that Taskrouter is dialling workers, but not updating them when dialling should end, and simply moving on to the next stage of the workflow. It does update Worker status, so it knows if they've timed out for instance, but that doesn't update the actual call.
I have looked for any solutions to this and havent found much about it except the following:
How to make Twilio stop dialing numbers when hangup() is fired?
https://www.twilio.com/docs/api/rest/change-call-state
These don't specifically apply to Taskrouter, but suggest that a call that needs to be ended can be updated and completed.
I am not too sure if I can implement this however, as it seems to be using the same CallSid for all calls being dialled within a Workflow, makes it hard/impossible to seperate each call, and would end the active call as well.
It also just seems wrong that Taskrouter wouldn't be doing this automatically, so I wanted to ask about this before I tinker too much and break things.
Has anyone run into this issue before, or is able/unable to replicate it using the tutorial code?
When testing I've noticed the problem much more on landline numbers, which may only be because mobiles have their own timeout/redirects. VOIPs seem to immediately answer calls, so they behave a bit differently.
Any help/suggestions appreciated, thanks!
Current suggestion to work around this is to not issue the dequeue instruction immediately, but rather issue a Call instruction on the REST API when the Worker wishes to accept the Inbound Call.
This will create an Outbound Call to bridge the two calls together and thus won’t have many outbound calls for the same inbound caller at once.
Your implementation will depend on the behavior that you want to achieve:
Do you want to simul-dial both Workers?
Do you want to send
the task to both Workers and whoever clicks to Accept the Task first
will have the call routed to them?
If it's #2, this is a scenario where you're saying that the Worker should accept the Reservation (reservation.accepted) before issuing the Call.
If it's #1, you can either issue a Call Instruction or Dequeue Instruction. The key being that you provide a DequeueStatusCallbackUrl or CallStatusCallbackUrl to receive call progress events. Once one of the outbound calls is connected, you will need to complete the other associated call. So you will have to unfortunately track which outbound calls are tied to which Reservation, by using AssignmentCallbacks or EventCallbacks, to make that determination within your app.
I have a problem with call transfer using pjsua2 api. Actually I don't understand how this should be implemented for call transfer (REFER method).
My issue is on the transferee: when the transferee receives the REFER message, after sending NOTIFY to the transferor it creates the call to the transfer target: But the same Call class instance is used for both calls (the lookup method changes the id to match the searched id), while pjsua has 2 different call ids for the old and new calls.
Therefore, when the transferee receives the BYE from the transferor, it deletes the Call instance which is used for both calls, whereas pjsua still keeps a reference to the new call with the target transfer, which ends with a program exception.
I implemented the onCallTransferRequest() callback in the transferee but I don't see what to do here (pjsua doesn't do anything in its similar callback...)
My question is: how should I process this kind of transfer using pjsua2?
Thanks for your help and merry Christmas.
Thibault
Unfortunately I am not expert in C++. If I may, I can explain you how to blind transfer an active SIP call generally in PJSUA2.
First of all you have to create CallOpParam-object with default call settings. Then, you have to call your current Call-object and transfer method on it. As I know, blind transfer method should take two (2) parameters, destination as a String and CallOpParam. You should specify destination as: sip:username#domain. Last thing you have to do is set a status code to your CallOpParam, it should be PJSIP_SC_DECLINE, and hang up your active Call.
After all that B and C partner should be able to talk.
I have been reading up on zmq design patterns but I haven't seem to find that fits my need.
1. Box A sends info (json) to Box B and C; B and C gets different info from each other
2. Boxes B and C do some work based on info received from Box A
3. After finishing the work, Boxes B and C sends result back to Box A
Forwarder device (http://learning-0mq-with-pyzmq.readthedocs.org/en/latest/pyzmq/devices/forwarder.html) can achieve step 1 and 2 but not 3, correct?
Are there any patterns I can use to achieve?
Is it simple request/reply pattern?
If so, is there a centralized request/reply pattern so that Box A doesnt pick Boxes B and C but rather Box A sends info to something central and it knows to send to Boxes B and C and send the result back to Box A?
This looks like a pretty basic Load Balancing pattern which is in the guide. A is the controller and will be a ROUTER, while the workers, B and C, are DEALERS. The messaging is simple enough; the dealers send an initial message to the controller to say "I'm ready". The controller then hands out work to the ready workers.
This topology is the opposite of Jason's answer. Which you choose just depends on how you're wanting to extend your application. When the controller hands out work, it really ought to go to a worker that is ready to handle it. With the Load Balancing pattern that is guaranteed.
This is a pretty basic DEALER/ROUTER pattern.
DEALER sockets are round-robin, which means it'll send one request to box B, then the next to box C, then the next to box B, etc. If you want to hold any work until the worker is completed, you just have to know the current count of available workers.
On box B and box C, use a ROUTER socket (or a REP socket if your use case is simple enough, but that'll limit your options). Receive the work, work on it, send it back, wait for more work.
There are many examples like this in the guide, which I recommend you read.
I'm originating multiple sequential calls on freeswitch
originate {continue_on_fail=true,originate_continue_on_timeout=true,originate_timeout=20,ignore_early_media=true}[record_number=abcd,campaign=test-presidio,idbrand=2]sofia/gateway/c-gw-1/yyyyy|[record_number=efgh,campaign=test-presidio,idbrand=2]sofia/gateway/c-gw-1/xxxxxxx &park()
I'm using the bgapi.
is there an event that is raised when the originate command has processed all calls ? Is there a way to determine if all calls failed ?
thx
This question is a little dated, but a note here...
NEVER EVER process calls like this if you are running a dialer (like the OP seems to be doing). This will just cause you heartache, as it is not a clean way to originate calls especially if there are hundreds of calls being sent. You need to be running these in seperate threads (i.e. seperate calls altogether). You can limit calls in your ESL/XML-RPC client if needed.
This is also invalid syntax for an enterprise originate. ':_:' should be used instead of '|'.
Are you passing this directly into cli? Or are you using XMLRPC? Or are you using an ESL? In the latter two scenarios, you can send off your calls and check those calls as they're in-progress. Your language of choice should let you use error checking to find out what happens and how many calls were successful vs. failed, etc..