Le 15/11/2017 à 22:47, Joshua Colp a écrit :
On Wed, Nov 15, 2017, at 05:45 PM, Jean Aunis wrote:
Le 13/11/2017 à 23:17, Phil Mickelson a écrit :
Jean,
You should know that I wrote something very similar to what you are
asking for. Slightly different reasons and I use ARI which makes it
very
On Wed, Nov 15, 2017, at 05:45 PM, Jean Aunis wrote:
> Le 13/11/2017 à 23:17, Phil Mickelson a écrit :
> > Jean,
> >
> > You should know that I wrote something very similar to what you are
> > asking for. Slightly different reasons and I use ARI which makes it
> > very easy. However, the result
Le 13/11/2017 à 23:17, Phil Mickelson a écrit :
Jean,
You should know that I wrote something very similar to what you are
asking for. Slightly different reasons and I use ARI which makes it
very easy. However, the result is the same. The inbound call gets
terminated.
I also considered the
Phil, thanks for the explanation. It's an interesting approach for sure,
and I agree it's much more explicit than a busy -- I kind of like it.
On Mon, Nov 13, 2017 at 5:44 PM Phil Mickelson wrote:
> James: There were multiple ways of handling this. My customer preferred
> this way. Also, sinc
James: There were multiple ways of handling this. My customer preferred
this way. Also, since all my code uses ARI and we don't use dial plan etc
I can easily control when this happens. In our case they mark the customer
on credit hold and an email is sent to the admin staff alerting them that
Out of curiosity, for your use case, couldn't you just play a busy signal
for customer DID's that aren't paying their bills? I've worked for a live
operator telephone answering service (TAS) for the last 12 years and have
never heard of this type of behavior used in our industry from my peers,
indu
I wasn't saying it was an invalid feature at all, I just see the
ramifications of these features because someone set something wrong. Their
system starts doing obscure things and you spend way too much time tracking
it down. In general the user experience which is also heavily linked to
their cus
Jean,
You should know that I wrote something very similar to what you are asking
for. Slightly different reasons and I use ARI which makes it very easy.
However, the result is the same. The inbound call gets terminated.
For those of you who don't know why you'd do this here's the situation: If
Le 13/11/2017 à 17:58, Steve Edwards a écrit :
On Mon, 13 Nov 2017, James Finstrom wrote:
Generally the idea of arbitrarily killing calls seems awful, even if
the behavior is expected. Yeah so john we need to . RING
John is confused, your brain has to reset because whatever was
happening
On Mon, 13 Nov 2017, James Finstrom wrote:
Generally the idea of arbitrarily killing calls seems awful, even if the
behavior is expected. Yeah so john we need to . RING John is
confused, your brain has to reset because whatever was happening no
longer matters.
At least play a message l
On Mon, 13 Nov 2017, Jean Aunis wrote:
At the moment, it is possible to limit the number of calls to a peer
using the GROUP/GROUP_COUNT functions. It is also possible to list all
channels in Asterisk and choose one to hangup in an AGI script, but
there is no way to list channels in a particula
Generally the idea of arbitrarily killing calls seems awful, even if the
behavior is expected.
Yeah so john we need to . RING John is confused, your brain has
to reset because whatever was happening no longer matters.
You can have priority queues and allow the agents to manage the transition
Hello,
As I highlighted recently on the asterisk-users list
(http://lists.digium.com/pipermail/asterisk-users/2017-November/292079.html),
there is no native way in Asterisk to implement call preemption. By call
preemption, I mean the following :
- given calls have a priority, which may be no
13 matches
Mail list logo
