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 <p...@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.labb...@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 <p...@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.au...@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
-- _____________________________________________________________________ -- 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