Is it possible to see Extension being called as it's ringed?

[torontob]

Hello,

Am I missing something or is the Wall-board not capable of showing what Extension is being ringed? As a call comes in, I see the call in Wait and I hear an extension ringing but I can't see the extension number on the Wall-Board.

Am I missing a parameter in the configuration file or is it not supported at all?

I think this adds a very much needed feature to the system because one can literally see which Agent is lazy and not picking up the phone specially in a system where Agents do not have a time and they must pick up a call. This also helps with troubleshooting calls that are lost or not picked up.

Currently Wall-board only shows Extension number if a call is CONNECTED and ANSWERED and not when it's ringing.

Please shed some light on it.

Thanks

[QueueMetrics]

You are right - Asterisk does not log ringing attempts, just failed ones.

[torontob]

That's why maybe QM should start reading EVENTs. I always wondered why you chose Queue Logs?

Is it because different versions of Asterisk change Events output and it would have been ton of work to keep up?

Thanks

[coolname]

Does "ACD attempts by terminal" for this?

[torontob]

Not sure what your question is but if you are asking if an event is generated then I should say with a resounding "Yes".

SIP ends always echo back Ringing stage and also Asterisk shows in channelstatus() and generates a Ringing event for it. So, it exists in Asterisk logs and AMI events.

[QueueMetrics]

That's why maybe QM should start reading EVENTs. I always wondered why you chose Queue Logs?

Is it because different versions of Asterisk change Events output and it would have been ton of work to keep up?

Thanks

It is a ton of work to keep up with differences in the queue_log as well. ;-)
The idea is that QM is decoupled from Asterisk, so it does not cause additional load on the server.

[torontob]

But it's also so easy to add an:

Code: [Select]

exten = _X.,n,System(echo "Ringing" >> /var/log/asterisk/queue_log)
to incoming context and so it adds the Ringing line to Queue log. This can be easy work-around rather than reading events and only other change is to be made on the java-script running the dashboard to pick this up. Probably if the 5 second is lowered to 1 or 2 seconds then this feature would make more sense as it's time sensitive.

-Bruce

[QueueMetrics]

It is true, if you have Local agents; not so easy for other ones. Maybe using a queue macro?
Anyway it is an interesting idea....

[torontob]

So let's add it as a quick feature (to be enhanced in future version) and assign it a bug #. 

[QueueMetrics]

We basically have the logging in place, it is called AGENTATTEMPT and was before Asterisk standardized on RINGNOANSWER.
See http://queuemetrics.com/manuals/QM_UserManual-chunked/ar01s23.html - "23.6. Enabling ACD call attempts recording on Asterisk 1.0 and 1.2".

The problem is that if there are both, tracking does not work.

So we should probably add a config option that turns off RINGNOANSWER reading (if you manually added AGENTATTEMPT)  and it should be working fine.

We track this as bug #1299.

[torontob]

Hmmm....We are using Asterisk 1.6.x. I didn't change any of the settings so basically I should see which Agent is ringing but that is not happening.

Did you say there is a parameter I have to set to off (AGENTATTEMPT) for this to work on Asterisk 1.6? What is the name of the parameter in the configuration.properties file?

Thanks

[QueueMetrics]

No there is an old patch for Asterisk 1.0 and 1.2 but we do not recommend running it on 1.6.

[QueueMetrics]

We basically have the logging in place, it is called AGENTATTEMPT and was before Asterisk standardized on RINGNOANSWER.

After giving this a bit of consideration, this is not very easy to do, because
a macro can only be called when an agent answers, and so this is not
generalizable. We can of course make it work for LOCAL channels, or we could
write a very simple, trivial patch to the app_queue module, but this would make
deployment of a QM system a bit more complex for "canned" systems, and this is
not what we would like to do.


On the other side, people are interested in ringing to know whether the call is
being mis-routed or agents are not answering thus causing delays. We already
have this information, so this is something that we are going to implement as
issue #1306.


If a call, while unanswered, has failed attempts, I would display the name of
the agent that was called without success and maybe the duration or the number
of failed attempts. These would be displayed in red. This way you get kind-of
the same information you have when ringing.

[torontob]

That is very much needed and brilliant. In fact the aim of this feature like you said is to see if a call is misrouted or not. And that is what we get from Supervisors. They continuously ask where the call went. With that kind of information, we should be in much better shape.

When do you expect this bug to resolve?

Regards

[QueueMetrics]

I expect this to be a part of the next release (in about one month or two).
BTW, the basic plumbing at the parser level has been written last week; we will also allow "ringing" in case you are able to configure it at the Asterisk level.