<div dir="ltr">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. </div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 13, 2017 at 5:44 PM Phil Mickelson <<a href="mailto:phil@cbasoftware.com">phil@cbasoftware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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!<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 13, 2017 at 5:33 PM, Patrick Labbett <span dir="ltr"><<a href="mailto:patrick.labbett@gmail.com" target="_blank">patrick.labbett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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? <div><br></div><div>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. <div><br></div><div>My intention of asking this is to learn and evaluate a new technique: not to criticize. Thanks in advance!</div></div></div><div class="m_7532444300825254377HOEnZb"><div class="m_7532444300825254377h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 13, 2017 at 5:17 PM Phil Mickelson <<a href="mailto:phil@cbasoftware.com" target="_blank">phil@cbasoftware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Jean,<div><br></div><div>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. </div><div><br></div><div>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!</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 13, 2017 at 4:47 PM, Jean Aunis <span dir="ltr"><<a href="mailto:jean.aunis@prescom.fr" target="_blank">jean.aunis@prescom.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Le 13/11/2017 à 17:58, Steve Edwards a écrit :<br>
<blockquote type="cite">On
Mon, 13 Nov 2017, James Finstrom wrote:
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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."
<br>
<br>
<br>
<fieldset class="m_7532444300825254377m_2714796214458809715m_4541729556750387648m_4984839170191256825mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
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.<br>
<br>
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.<br>
</div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>
</div></div><br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>