Thank you Jean, Antony and J Montoya or A J Stiles for replying.
Jean: My Asterisk is version 1.8 therefore I don't think it supports ARI
Antony: In general you are right about calling local channel first however if I
issue the call setup simultaneously in 99.9% of the cases the local agent will
answer way before the remote side will and I'm willing to sacrifice this 0.1%
for this purpose. The reason for this is that the local agents are on a queue.
Would you know how to Originate() or callfile to a queue? AMI is an option I'll
look at.
JM or AJS: Yes, this is how it is working for me (including the move vs copy)
so my problem is not there.
My main objective is to initiate a call as soon as an agent becomes available
(also using predictive algorithms) and I don't want to waste time on calling
one side and only when answered calling the other.
Harel
-- Original Message
---
Message: 1
Date: Mon, 26 Jun 2017 15:06:10 +0300
From: "Harel"
To:
Subject: [asterisk-users] Autodialer - call simultaneously to both
ends
Message-ID: <012b01d2ee74$9a52cb60$cef86220$@mayorcom.com>
Content-Type: text/plain; charset="utf-8"
Hello List,
I'm working on an autodialer project.
At the moment I use the Originate application then I "throw" it to an extension
where I Dial() the other party and then both legs are bridged. The problem is
that the Dial() will only run after the Originate finish its bit and I have
lots of wasted time or even worse, the remote party hanging the call because
instead of a human speaking to him the call setup to the 2nd leg only starts
when remote answers.
Is there a way to start calling both parties at the same time and bridge them
when one answers (which will then hear the ringback tone until 2nd party
answers)?
Thank you
Harel
--
From: Jean Aunis
Hello,
You can certainly do this with the ARI interface but you will have to write
some code.
You could for example originate two channels, send them to the same Stasis
application, create a bridge and place both channels in it.
Best regards
Jean Aunis
--
From: Antony Stone
Sounds like you're dialling the legs the wrong way round.
You should dial the extension of the person who wants the autodial function
first (ie: the person who knows about this system).
They answer their phone (which should be quick, because they're expecting it to
ring after they've initiated the autodial), and they then wait for the remote
party (who doesn't know there's an autodialler involved) to answer.
Dialling both numbers simultaneously always runs the risk that the remote party
(who doesn't know about the autodialler) will answer the call first, so unless
you have some recorded announcement "please wait while we connect your call"
(which if I heard it would make me hang up immediately, because I'd know it was
some automated dialler, probably a cold-calling sales organisation), they
answer the phone, hear ringing, think "what the hell?" or even "oh, one of them
again" and hang up.
Always start from the "local" end - ie: the person who knows about the auto-
dialler.
Antony.
--
Atheism is a non-prophet-making organisation.
Please reply to the list;
please *don't* CC me.
--
From: J Montoya or A J Stiles
Our auto-dialler works as follows;
* Agent clicks number on screen in their web browser
* Agent's phone rings
* Agent picks up phone
* Far end party's phone rings
* Far end party answers
* Agent and far end party are bridged.
and is implemented using the truly ancient technology of callfiles.
All you need then is a Perl or PHP script, which accepts the destination
number as a query parameter. Your script then needs to identify the
workstation by means of its IP address and determine the number of the nearest
phone (this does require proper configuration of DHCP server, but is worth
it), then write out a callfile.
Note: There exists a race condition in Asterisk (at least, when using the
common Linux file systems, which update a folder's directory as soon as the
*first* block of a file is written) which means that if a callfile exceeds one
block, Asterisk could end up reading only the first block and ignoring the
rest. If there is any danger that a callfile could exceed one block on your
filesystem, you must write the callfile to a different folder, and then use the
`mv` command to move it to /var/spool/asterisk/outgoing/ . This sidesteps the
race condition due to the behaviour of the mv command. When moving *within* a
filesystem, the whole file was already on the disk anyway when the directory is
updated; when moving from one filesystem to another, it does not update the
directory of the destination folder until the *last* block
