[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] Proposing change to Queue and missed calls behavior
From: Richard Mudgett <rmudgett () digium ! com>
Date: 2015-12-09 16:45:43
Message-ID: CALD46g38tm+qjT2ia+ra433r=6Pa297YwQa-M4k+7kHpHz5M6w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Dec 9, 2015 at 2:06 AM, Stian Hvatum <stian@unisoft.no> wrote:
> On 12/07/2015 05:02 PM, Olle E. Johansson wrote:
>
>> On 07 Dec 2015, at 16:53, Mark Michelson <mmichelson@digium.com> wrote:
>>>
>>> On 12/04/2015 01:00 PM, Stian Hvatum wrote:
>>>
>>>> Hi,
>>>> I have a problem with an accompanying solution that I wish to share,
>>>> but I am not sure if it is valuable enough or correct enough to be
>>>> suggested as a patch to Asterisk.
>>>>
>>>> When SIP-phones are members of a queue, they tend to accumulate "missed
>>>> calls" unless the C-flag is applied. When the C-flag is applied there is no
>>>> missed calls at all, since all hangups are marked as "answered elsewhere".
>>>> I have created and attached a patch which makes the C-flag "answer
>>>> elsewhere" all hangups that are caused by app_queue canceling the dial or
>>>> the call is really answered elsewhere, but sets normal cause when caller
>>>> actually hangs up before the call is answered.
>>>>
>>>> I know the patch alters the behavior of the C-flag, and altering
>>>> behavior of existing flags is probably a bad thing. I can try to create a
>>>> new flag for this "missed call on caller hangup"-behavior if that is of any
>>>> value. Also, I don't have much experience with the Asterisk source code, so
>>>> if I break something by setting normal cause here I would be very happy if
>>>> anyone would give me a hint about it. The only problem I have seen so far
>>>> is that if the caller hangs up during an announcement or between
>>>> app_queue's dial outs, the call is not marked as missed (as the previous
>>>> call was "answered elsewhere" and no new calls went out to the phones).
>>>>
>>>> The code is running a few places without causing any trouble as far as
>>>> I can tell. I wrote this after a customer had a few thousand missed calls
>>>> on his queue-connected phone...
>>>>
>>>> Best regards and thanks for a great project!
>>>> Stian Hvatum
>>>>
>>> In my opinion, if the c-flag is set and the caller hangs up, you are
>>> correct that the "answered elsewhere" status should not be applied. I also
>>> think the "answered elsewhere" status should not be applied if a call to a
>>> single queue member times out before the member answers the call. The
>>> c-flag behavior should only be applied when multiple queue members' phones
>>> are ringing at the same time, and Asterisk has to cancel the outgoing call
>>> to certain members due to the call being answered by someone else.
>>>
>>> I think the change you are suggesting would be welcome.
>>>
>> Mark,
>> That was not the idea when I wrote it. (If I remember correctly). The
>> case was that the phone should NEVER show any queue calls as missed,
>> regardless of why.
>>
>> This behaviour is still useful - to separate personal calls that require
>> callback from calls that doesn't require call back (i.e. calls from the
>> queue).
>>
>> I like the idea with a new option.
>>
>> /O
>>
>
> Thanks for comments.
> As Olle writes, there are many cases where a call never should be shown as
> missed. I think it might be better to implement a new option, then it at
> least won't hurt any one relying on the current behavior. Are there any
> naming schemes for these options, or can I use e.g. "M" for "only show call
> as Misse when first caller in line hangs up"?
>
> If I want to commit this as a new option upstream, should I also write
> some sort of unit test or regression test?
>
These links will answer your questions:
https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines
Basically it is a good idea to have either a testsuite test or unit test
whichever is appropriate.
Richard
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec \
9, 2015 at 2:06 AM, Stian Hvatum <span dir="ltr"><<a \
href="mailto:stian@unisoft.no" target="_blank">stian@unisoft.no</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On \
12/07/2015 05:02 PM, Olle E. Johansson wrote:<br> <blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> On 07 Dec \
2015, at 16:53, Mark Michelson <<a href="mailto:mmichelson@digium.com" \
target="_blank">mmichelson@digium.com</a>> wrote:<br> <br>
On 12/04/2015 01:00 PM, Stian Hvatum wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> Hi,<br>
I have a problem with an accompanying solution that I wish to share, but I am not \
sure if it is valuable enough or correct enough to be suggested as a patch to \
Asterisk.<br> <br>
When SIP-phones are members of a queue, they tend to accumulate "missed \
calls" unless the C-flag is applied. When the C-flag is applied there is no \
missed calls at all, since all hangups are marked as "answered elsewhere". \
I have created and attached a patch which makes the C-flag "answer \
elsewhere" all hangups that are caused by app_queue canceling the dial or the \
call is really answered elsewhere, but sets normal cause when caller actually hangs \
up before the call is answered.<br> <br>
I know the patch alters the behavior of the C-flag, and altering behavior of existing \
flags is probably a bad thing. I can try to create a new flag for this "missed \
call on caller hangup"-behavior if that is of any value. Also, I don't have \
much experience with the Asterisk source code, so if I break something by setting \
normal cause here I would be very happy if anyone would give me a hint about it. The \
only problem I have seen so far is that if the caller hangs up during an announcement \
or between app_queue's dial outs, the call is not marked as missed (as the \
previous call was "answered elsewhere" and no new calls went out to the \
phones).<br> <br>
The code is running a few places without causing any trouble as far as I can tell. I \
wrote this after a customer had a few thousand missed calls on his queue-connected \
phone...<br> <br>
Best regards and thanks for a great project!<br>
Stian Hvatum<br>
</blockquote>
In my opinion, if the c-flag is set and the caller hangs up, you are correct that the \
"answered elsewhere" status should not be applied. I also think the \
"answered elsewhere" status should not be applied if a call to a single \
queue member times out before the member answers the call. The c-flag behavior should \
only be applied when multiple queue members' phones are ringing at the same time, \
and Asterisk has to cancel the outgoing call to certain members due to the call being \
answered by someone else.<br> <br>
I think the change you are suggesting would be welcome.<br>
</blockquote>
Mark,<br>
That was not the idea when I wrote it. (If I remember correctly). The case was that \
the phone should NEVER show any queue calls as missed, regardless of why.<br> <br>
This behaviour is still useful - to separate personal calls that require callback \
from calls that doesn't require call back (i.e. calls from the queue).<br> <br>
I like the idea with a new option.<br>
<br>
/O<br>
</blockquote>
<br></span>
Thanks for comments.<br>
As Olle writes, there are many cases where a call never should be shown as missed. I \
think it might be better to implement a new option, then it at least won't hurt \
any one relying on the current behavior. Are there any naming schemes for these \
options, or can I use e.g. "M" for "only show call as Misse when first \
caller in line hangs up"?<br> <br>
If I want to commit this as a new option upstream, should I also write some sort of \
unit test or regression test?<br></blockquote><div><br></div><div>These links will \
answer your questions:<br><br><a \
href="https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process">https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process</a><br><a \
href="https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines">https://wiki. \
asterisk.org/wiki/display/AST/New+Feature+Guidelines</a><br><br></div><div>Basically \
it is a good idea to have either a testsuite test or unit test whichever is \
appropriate.<br></div><div><br></div><div>Richard<br></div></div><br></div></div>
--
_____________________________________________________________________
-- 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic