[asterisk-dev] Adding a call preemption feature

Tue Nov 14 07:28:12 CST 2017

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 <phil at cbasoftware.com> wrote:

> 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 a
> call was terminated and the reason.  They'd be deluged with emails if
> something went wrong.  That's not to say someone hasn't been put on credit
> hold when they shouldn't have been, but they're alerted to it quickly!
>
> Patrick:  Yes, we could've.  However, if you give them a busy then they'll
> think that the lines are tied up.  In reality you want the caller to show
> up at the customer's site (if possible) or have the customer call in for
> messages, etc and find the same thing.  Hanging up the phone is much more
> explicit.  No, we're not going to answer your call.  And, as I said above,
> this is the way my customer wanted it.
>
> On Mon, Nov 13, 2017 at 5:33 PM, Patrick Labbett <
> patrick.labbett at gmail.com> wrote:
>
>> 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,
>> industry groups, or otherwise?
>>
>> From my understanding, this thread is talking about having X channels,
>> and when X+1 is reached, assuming there is some priority of that X+1
>> caller, you drop one of the existing channels instead and allow the X+1
>> caller to continue.
>>
>> My intention of asking this is to learn and evaluate a new technique: not
>> to criticize. Thanks in advance!
>>
>> On Mon, Nov 13, 2017 at 5:17 PM Phil Mickelson <phil at cbasoftware.com>
>> wrote:
>>
>>> 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 you're running a live operator answering service and have a customer who
>>> hasn't and won't pay their bill but still forwards the calls.  Unless you
>>> terminate the call when it comes in then you have operators answering calls
>>> where they have to tell the caller they're not going to get taken care of.
>>> It's much easier to just terminate the call before it's answered.  ARI
>>> makes this very easy.  And, BTW, it get the customer's attention very
>>> quickly.  And, the bill is generally paid!
>>>
>>> Everyone has some feature that's important to them.  Just because you
>>> don't understand or see the reason doesn't mean it's not valid.
>>>
>>> On Mon, Nov 13, 2017 at 4:47 PM, Jean Aunis <jean.aunis at prescom.fr>
>>> wrote:
>>>
>>>> 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 .<CLICK> RING.... John is
>>>> confused, your brain has to reset because whatever was happening no longer
>>>> matters.
>>>>
>>>>
>>>> At least play a message like "The boss needs to call his
>>>> mom/bookie/hooker. Thank you for understanding, your call just wasn't
>>>> important enough. Better luck next time -- and have a great day."
>>>>
>>>>
>>>>
>>>> Thank you for your remarks. The fact is, it is not a question of user
>>>> experience. We are working on critical communication networks, in which
>>>> network resources are limited. Hanging up a low priority call to leave room
>>>> to another is not an option, it is an absolute necessity, and it must be
>>>> done in near real-time. We cannot afford to play any announcement.
>>>>
>>>> By the way, I think call preemption is a native feature of ISDN
>>>> networks (at least it's my understanding of the MLPP stuff, but I'm not a
>>>> ISDN expert). But it is probably not used very often.
>>>>
>>>> --
>>>> _____________________________________________________________________
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>
>>>> asterisk-dev mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171114/ed0a851b/attachment-0001.html>