[asterisk-dev] Adding a call preemption feature

[Patrick Labbett]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171113/f37f0ec9/attachment-0001.html>