ACDC Status

[Shiu Lam]

Hi

what is the status for ACDC (call_center) module, is it ready for Production?

Thanks

[sat...@gmail.com]

2600hz Experts,

We are also interested in ACDC.
Does anyone has success using CLI commands? We would appreciate any lead on this.

Thanks,

Sat

[Alex Budaev]

Hi, in current path on github module adcd work fine. U can login, logout in queue, call in queue. 

четверг, 26 июня 2014 г., 2:51:19 UTC+4 пользователь Shiu Lam написал:

[Graham Nelson-Zutter]

Has anyone run ACDc in production with a few agents using the module on a daily basis?

Is anyone accessing the ACDc stats and creating reports?

thanks,

Graham

[Graham Nelson-Zutter]

Hi there list friends. 

We’ve started doing some testing with ACDc to see what the caveats are. Maybe as a group we can help QA and debug.

We have the staging release kazoo-R15B-3.14-7 installed. We have the "acdc" what running and with crossbar enabled for both "cb_queues”, “cb_agents”.

Using the Kazoo "call_center" UI app, we’re able to create a new queue and add an agent. Unfortunately, we’re not able to get a call to ring through to the agent’s phone. 

After we log the agent in, the agent now shows in the Winkstart UI in the Queue agent list. When we place a test call into this queue using a routed DID, the queue appears to "answer" the call and add the call to queue. However, the queue doesn’t ring through to the agent’s SIP device. The call just stays in the queue indefinitely.

Maybe there's something relatively small or simple that we're overlooked? Perhaps there's some small trick that one of you might be able to share so we can get an agent's phone to start ringing?! 

thanks!
Graham

[remc...@gmail.com]

Hi Graham,

I got it to work in the latest staging. The issue I had was the agents were never actually logging in to the queue. Calls never were actually queued but were proceeding until timeout.
Look for a crash in the logs complaining about a missing integer upon logging in the agent. It should turn blue in the dashboard. It is missing the integer for max_connect_failures in the account doc. In my setup the parameter was there but it was not set. Once the parameter was set and the necessary caches were flushed, I got calls to queue. The implementation look really nice with the wrap-up time indicated, etc.

Remco.


Op vrijdag 1 augustus 2014 23:10:01 UTC+2 schreef Graham Nelson-Zutter:

[Graham Nelson-Zutter]

Hi Remco,

Thank you for your help! 

It seems like we may be experiencing deferent problems. 

In our staging install, I’m not able to load the Call Center Dashboard. When I try to load the Dashboard interface, logs show the below request, but nothing shows under the dashboard. 

GET: /v1/accounts/59afe532db3e3bc0411bff326a83507e/agents/status?_=1407262138652 from MY.REMOTE.V4.IP

Any ideas on why this might be occurring?

thanks,

Graham

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Graham Nelson-Zutter]

Hi Remco,

With the dashboard not loading, we figured there was something wrong with our testing environment. We’ve reset the environment and now we see the ACDC Dashboard. It looks just as you said, the Agent is shown in grey, not blue. 

We’ve added  "max_connect_failures": 3 to the system_config/acdc doc and also to the account/account_ID/account_ID. We’ve flushed cache and even restarted apps and still the Queue calls don’t ring through to the Agent. Perhaps we’ve added "max_connect_failures": 3 to the wrong location?  Any ideas would be great!

thank you,

Graham

[Yuriy Nasida]

Hello Graham and Remco,

I would also like to check call center functionality but unfortunately don't see any suitable documentation for installation(or enabling) that kazoo module.
I see only that one https://github.com/2600hz/kazoo/tree/master/applications/acdc/doc

Can you please to share documentation\instructions you used ?

Thanks.

---

Date: Tue, 5 Aug 2014 15:52:36 -0700
From: gra...@telephonic.ca
To: 2600h...@googlegroups.com; remc...@gmail.com
Subject: Re: ACDC Status

You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.

[Graham Nelson-Zutter]

Hi Yuriy,

Using current staging releases, we’ve only been able to get a certain point with Queues. We have the ACDc app running and the UI loaded, but we still don’t seem to be able to get agents to actually login to a Queue and receive calls with v3.15. 

Here are the steps that we’ve followed:

(Remco & Alex, do you see any problems with the below steps? Would you add anything?)

1. Install a fresh version of Kazoo (v3.15) from the staging RPMs:
- Edit /etc/yum.repos.d/2600hz.repo
- Disable “Base” repos using enabled=0
- Enable “Staging” repos using enabled=1 (for R15B not R16B)

2. Enable the ACDc kazoo app:
- Open Futon to http://127.0.0.1:15984/_utils/document.html?system_config/whapps_controller
- Add “acdc” to the whapps list
- Flush/Restart Kazoo

3. Make sure “max_connect_failures” is set:
- Open Futon to http://127.0.0.1:15984/_utils/document.html?system_config/acdc
- Make sure that "max_connect_failures": 0 greater than -1 is set
- Add if missing and Flush/Restart Kazoo

4. Enable Queues and Agents APIs in Crossbar:
- Open Futon to http://127.0.0.1:15984/_utils/document.html?system_config/crossbar
- Add “cb_queues” and “cb_agents” to the autoload_modules list.
- Flush/Restart Kazoo 

5. Enable the Call Centre web interface:
- Edit /var/www/html/kazoo-ui/config/config.js
- Add the equivalent “call_center” app references in every location you see the “voip” app, using the same format as the “voip” app (or any other UI app).
- Remove browser cache and add the “call_center” app to your user’s available apps from the “App Store"

Maybe try the above steps and see if you get further? You may not have the same issues! 

cheers,
Graham

P.S. The error that we’re getting relates to connecting inbound callers to a Queue’s Agent(s). We may have an AMQP connection problem. See below...

# grep acdc /var/log/2600hz-platform.log
Aug 12 17:21:05 staging.FQDN 2600hz[1576]: |acdc_agent_manager|acdc_agent_manager:147 (<0.871.0>) channel_create event
Aug 12 17:21:05 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|acdc_agent_handler:251 (<0.21223.35>) new channel in acct f5a05379128b031a7fded339ec2aab58: from +15554994351 to +15552592866(16042592866)
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_exe:588 (<0.21275.35>) moving to action 'cf_acdc_member'
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:36 (<0.21283.35>) sending call to queue bb9b35e2857c51c988c55a50508e14fb
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:45 (<0.21283.35>) loading ACDc queue: bb9b35e2857c51c988c55a50508e14fb
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|wapi_acdc_queue:530 (<0.21283.35>) failed to query queue size: NOT_FOUND - no queue 'acdc.queue.f5a05379128b031a7fded339ec2aab58.bb9b35e2857c51c988c55a50508e14fb' in vhost '/'
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:55 (<0.21283.35>) max size: 0 curr size: undefined
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:75 (<0.21283.35>) asking for an agent, waiting up to infinity ms
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |00000000000|wh_amqp_assignments:733 (<0.102.0>) floating channel <0.27109.0> on amqp://guest:gu...@KAZOO.V4.IP.ADDR:5672 went down while still assigned to consumer <0.21275.35>: {shutdown,{server_initiated_close,404,<<"NOT_FOUND - no queue 'acdc.queue.f5a05379128b031a7fded339ec2aab58.bb9b35e2857c51c988c55a50508e14fb' in vhost '/'">>}}
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|wh_amqp_channel:153 (<0.21275.35>) published to callmgr(undefined) exchange (routing key acdc.member.call.f5a05379128b031a7fded339ec2aab58.bb9b35e2857c51c988c55a50508e14fb) via <0.27903.0>
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |b9f7acedc4b304de2dcadbb045eb42e2|acdc_queue_manager:149 (<0.21291.35>) no agents are available to take the call, cancel queueing
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:92 (<0.21283.35>) timeout: infinity
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:150 (<0.21283.35>) ignoring {<<"call_event">>,<<"CHANNEL_PROGRESS_MEDIA">>}
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:92 (<0.21283.35>) timeout: infinity
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:150 (<0.21283.35>) ignoring {<<"call_event">>,<<"CHANNEL_EXECUTE">>}
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:92 (<0.21283.35>) timeout: infinity
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:150 (<0.21283.35>) ignoring {<<"call_event">>,<<"CHANNEL_EXECUTE_COMPLETE">>}
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:92 (<0.21283.35>) timeout: infinity
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:150 (<0.21283.35>) ignoring {<<"call_event">>,<<"CHANNEL_EXECUTE_COMPLETE">>}
Aug 12 17:21:06 staging.FQDN 2600hz[1576]: |84748795-3616867266-967807|cf_acdc_member:92 (<0.21283.35>) timeout: infinity

On August 12, 2014 at 2:05:03 PM, Yuriy Nasida (nas...@live.ru(mailto:nas...@live.ru)) wrote:

> Hello Graham and Remco,
>
> I would also like to check call center functionality but unfortunately don't see any suitable documentation for installation(or enabling) that kazoo module.
> I see only that one https://github.com/2600hz/kazoo/tree/master/applications/acdc/doc
>
> Can you please to share documentation\instructions you used ?
>
> Thanks.
>

> > > > We have the staging release kazoo-R15B-3.14-7(http://airmail.calendar/2014-08-01%2015:14:00%20PDT) installed. We have the "acdc" what running and with crossbar enabled for both "cb_queues”, “cb_agents”.

> > > > Using the Kazoo "call_center" UI app, we’re able to create a new queue and add an agent. Unfortunately, we’re not able to get a call to ring through to the agent’s phone.
> > > > After we log the agent in, the agent now shows in the Winkstart UI in the Queue agent list. When we place a test call into this queue using a routed DID, the queue appears to "answer" the call and add the call to queue. However, the queue doesn’t ring through to the agent’s SIP device. The call just stays in the queue indefinitely.
> > > > Maybe there's something relatively small or simple that we're overlooked? Perhaps there's some small trick that one of you might be able to share so we can get an agent's phone to start ringing?!
> > > >
> > > > thanks!
> > > > Graham
> > > >
> > > >
> > > >
> > > > On Wednesday, July 9, 2014 12:48:30 PM UTC-7, Graham Nelson-Zutter wrote:
> > > > > Has anyone run ACDc in production with a few agents using the module on a daily basis?
> > > > >
> > > > > Is anyone accessing the ACDc stats and creating reports?
> > > > >
> > > > > thanks,
> > > > > Graham
> > > > >
> > > > > On Monday, July 7, 2014 6:37:42 AM UTC-7, Alex Budaev wrote:
> > > > > > Hi, in current path on github module adcd work fine. U can login, logout in queue, call in queue.
> > > > > >
> > > > > > четверг, 26 июня 2014 г., 2:51:19 UTC+4 пользователь Shiu Lam написал:
> > > > > > > Hi
> > > > > > >
> > > > > > > what is the status for ACDC (call_center) module, is it ready for Production?
> > > > > > >
> > > > > > > Thanks --
> > > You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
> > > To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.

> > > To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com(mailto:2600hz-dev+...@googlegroups.com).

> > > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "2600hz-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com(mailto:2600hz-dev+...@googlegroups.com).

> For more options, visit https://groups.google.com/d/optout.
> --

> You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com(mailto:2600hz-dev+...@googlegroups.com).

[Graham Nelson-Zutter]

Thanks for the quick reply Alex!

It’s great to hear that you’ve been able use queues effectively.

Would you be able to provide more details on how you added your Callflows for Logon Agent and Logon into Queue? When we use similar Callflows from the Agent’s SIP device, we get an error messages or the call simply drops. 

Also, is there any special configuration to enable the “after_bridge” module? How can we turn it on and use it?

thank you!

Graham

On August 12, 2014 at 4:43:57 PM, Alex Budaev (buda...@gmail.com) wrote:

Hello. In our installation queue work fine. We use mix modules from many release. Main version is 3.12. We use API to create queue, create callflow to logon agent and logon into queue. Create callflow to call in queue. More: work fine modules "after_bridge" - we use this module to rating agent. On Ui we see how agent work in queue: starting call, ending call.

12.08.2014 22:38 пользователь "Graham Nelson-Zutter" <gra...@telephonic.ca> написал:

[Alex Budaev]

Hello. In our installation queue work fine. We use mix modules from many release. Main version is 3.12. We use API to create queue, create callflow to logon agent and logon into queue. Create callflow to call in queue. More: work fine modules "after_bridge" - we use this module to rating agent. On Ui we see how agent work in queue: starting call, ending call.

12.08.2014 22:38 пользователь "Graham Nelson-Zutter" <gra...@telephonic.ca> написал:

Hi Yuriy,

[Alex Budaev]

I try give example for you today evening, because i'am on vacation in Italy and here same trouble internet access.

13.08.2014 0:53 пользователь "Graham Nelson-Zutter" <gra...@telephonic.ca> написал:

[Yuriy Nasida]

Thanks for instruction Graham!

It was that I searched exactly and you saved me a lot of time!
I enabled call_center functionality and it works good for me for now.
Your problem is probably happens because you have not any device in queue.
Try to create simple callflow which will add caller device to your queue (action 'Queue login').
Next, try to call to queue and it should send call to this device.

Also we probably have to add one point to your instruction

6. In СouchDB add to account (personal (account id) database and database accounts)
available_apps: "call_center"

i use kazoo-R15B-3.12-20.el6.x86_64

Budaevav, thanks for information! It is very helpful too.

---

Date: Wed, 13 Aug 2014 03:43:56 +0400
Subject: RE: ACDC Status
From: buda...@gmail.com
To: gra...@telephonic.ca
CC: remc...@gmail.com; 2600h...@googlegroups.com; nas...@live.ru

To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.

[Graham Nelson-Zutter]

Hi Yuriy

I’m glad that the list was helpful. Yes, adding step-6 appears to be necessary for sub-accounts under the master account. 

We’ve rebuilt our testing server with kazoo-R15B-3.12-23. Following our shared steps, I’ve made a much more progress with v3.12-23 than with v3.15.

In the Call Center UI Dashboard, we can now see the agent as blue!! When we call into the queue, we see the caller in the left panel and calls finally ring through to our registered SIP device!!!!

Just a quick note: our first few calls into the Queue didn’t ring through. We had to dial the "Queue Login" and "Queue Logout Callflows" a couple times, then calls into the Queue finally rang through to our Agents’ SIP devices. 

I’m going to run some more tests and see what else we can find! Are you using ACDc/Queues with real live clients? Have you had any issues you might be able to advise on?

cheers,

Graham

To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.

[Yuriy Nasida]

Hi Graham,

Glad that you have much more progress with v3.12-23 :)

"Just a quick note: our first few calls into the Queue didn’t ring through. We had to dial the "Queue Login" and "Queue Logout Callflows" a couple times, then calls into the Queue finally rang through to our Agents’ SIP devices. "

I had same problems. Looks like I used these callflow actions not correctly. Better to use Queue GUI for adding user to Queue and use callflow with actions 'Login agent', etc to have sip device online(pause,offline) in the queue. Probably you already know this)

"I’m going to run some more tests and see what else we can find! Are you using ACDc/Queues with real live clients? Have you had any issues you might be able to advise on?"

Not yet but plan to use with real clients. Unfortunately today I got some problems with couchDB (I suppose) and had to restart all things to have them working. Not sure that it connected with Queue functionality but please let me know if you see similar odd behaviour.

Thanks.

---

Date: Tue, 12 Aug 2014 19:30:38 -0700
From: gra...@telephonic.ca
To: 2600h...@googlegroups.com; nas...@live.ru
CC: ja...@telephonic.ca
Subject: RE: ACDC Status

[Graham Nelson-Zutter]

Thank you for the follow-ups Yuriy, Alex and Alexander. 

You’re right Yuriy, adding the agent directly to the Queue in the UI is easier. Once we had a clean install of v3.12-23, getting ACDc working with agents really just took trying out the new ACDc Callflows. We’ve now tested Callflows for Login Agent, Agent Pause, Agent Resume and Logout Agent. All of these functions appear to me working as expected. When each of these Callflows is used, the agent status is updated in the Dashboard. 

As far as stability goes, we’re an “eat your own dog food” type of shop. We’re going to use ACDc first and, once it appears to be relatively stable, we’ll try it out with a couple select clients. 

Alexander, have you had any stability issues that you might encourage us ACDc newbies to look out for? Were you able to resolve the 20 second call disconnect issue you were having with agents? 

I do recall a possibly related post where RabbitMQ encountered some errors relating to ACDc. If I recall correctly, this Kazoo user’s solution was to restart RabbitMQ nightly to clear the ACDc message bus. Let’s continue to compare notes and see if we encounter this or other problems. 

cheers,

Graham

P.S. Sorry to hear about your CouchDB restart Yuriy. That's no fun! On the other hand, it’s amazing how quickly and well CouchDB can recover from a crash in a master-master setting. This would be much more work with MySQL. Rebuilding a MySQL database using replication log files is no fun at all!

[Te Matau]

We've been trying this out and are getting the following message:

Sep 27 01:08:33 hanoi 2600hz[22781]: |ZmY5NjFmODI0NmJiNDNkOTM5OTg1N2NkYzc1YmY4ZDU|cf_acdc_member:36 (<0.31357.2888>) sending call to queue ed6a37cf94c90db456b13a83ea9ffd96

Sep 27 01:08:33 hanoi 2600hz[22781]: |ZmY5NjFmODI0NmJiNDNkOTM5OTg1N2NkYzc1YmY4ZDU|cf_acdc_member:45 (<0.31357.2888>) loading ACDc queue: ed6a37cf94c90db456b13a83ea9ffd96

Sep 27 01:08:33 hanoi 2600hz[22781]: |ZmY5NjFmODI0NmJiNDNkOTM5OTg1N2NkYzc1YmY4ZDU|cf_menu:154 (<0.30730.2888>) selection is a callflow child

Sep 27 01:08:33 hanoi 2600hz[22781]: |ZmY5NjFmODI0NmJiNDNkOTM5OTg1N2NkYzc1YmY4ZDU|cf_menu:108 (<0.30730.2888>) hunt callflow found

Sep 27 01:08:33 hanoi 2600hz[22781]: |ZmY5NjFmODI0NmJiNDNkOTM5OTg1N2NkYzc1YmY4ZDU|cf_exe:437 (<0.30719.2888>) unhandled message: {'EXIT',<0.30730.2888>,normal}

Sep 27 01:08:33 hanoi 2600hz[22781]: |ZmY5NjFmODI0NmJiNDNkOTM5OTg1N2NkYzc1YmY4ZDU|wapi_acdc_queue:530 (<0.31357.2888>) failed to query queue size: NOT_FOUND - no queue 'acdc.queue.29f64cc2909bd21cdad6f13cf9cb3174.ed6a37cf94c90db456b13a83ea9ffd96' in vhost '/'

Sep 27 01:08:33 hanoi 2600hz[22781]: |ZmY5NjFmODI0NmJiNDNkOTM5OTg1N2NkYzc1YmY4ZDU|cf_acdc_member:55 (<0.31357.2888>) max size: 20 curr size: undefined

Sep 27 01:08:33 hanoi 2600hz[22781]: |ZmY5NjFmODI0NmJiNDNkOTM5OTg1N2NkYzc1YmY4ZDU|cf_acdc_member:67 (<0.31357.2888>) queue has reached max size

I can see the queue in the database. Has anyone encountered that?

[Dayton Turner]

Testing ACDc on 3.18, we're seeing a couple things that are causing us some grief:

1) After $someTime, agents seem to "auto log out".  They had logged in, could receive calls fine, and then suddenly stop taking calls - if they re log in, things are okay.  Anyone aware of any auto logout/etc sort of functions?

2) Calls to users that have cell phone devices have queue calls usurped immediately - even with 'require keypress' turned on, as soon as the call hits the carrier and gets ringing state, the caller has been hijacked.

Any input greatly appreciated!

Dayton

[Graham Nelson-Zutter]

Hi Dayton and Te,

It’s great that you and others are testing ACDc in v3.18! We too would like to make this upgrade and supporting ACDc is a big priority. 

I think there is a auto-logout feature for agents if they’ve missed a number of calls in a row. There may be defaults added to new queues that might be able to see the in queue config doc in CouchDB. There may also be a global variable for this in the ACDc config doc. 

We’ve not yet tried testing agents using mobile or other PSTN. We can’t confirm is this was working in 3.16. When you tested in v3.16, did this work?

thanks,

Graham

--

[Dayton Turner]

Graham,

The max_connect_failures was the autologout crux.  "0" is the same thing as infinity, and the system default is 3.  It can be set globally in system_config/acdc, or per account in the account editor itself. The default is ""(nothing) which defaults to using the system global default.

We hadn't tested PSTN devices on agents since 3.08.  They did work on 3.08. We're going to take a peek around the code and see if we can fix it.

Dayton

Graham Nelson-Zutter

January 9, 2015 at 12:19 PM

Dayton Turner

January 9, 2015 at 10:47 AM

Testing ACDc on 3.18, we're seeing a couple things that are causing us some grief:

1) After $someTime, agents seem to "auto log out".  They had logged in, could receive calls fine, and then suddenly stop taking calls - if they re log in, things are okay.  Anyone aware of any auto logout/etc sort of functions?

2) Calls to users that have cell phone devices have queue calls usurped immediately - even with 'require keypress' turned on, as soon as the call hits the carrier and gets ringing state, the caller has been hijacked.

Any input greatly appreciated!

Dayton

On Wednesday, 25 June 2014 15:51:19 UTC-7, Shiu Lam wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent with Postbox

[Eamon]

Hi

I have updated crossbar added queues, agents, and updated the UI. created a queue using the UI and added agents to it. I cant get the agents to log into the queue ?

The inbound number is set to "Queue Login" as per previous post.

On Friday, January 9, 2015 at 8:24:14 PM UTC, Dayton Turner wrote:

Graham,

The max_connect_failures was the autologout crux.  "0" is the same thing as infinity, and the system default is 3.  It can be set globally in system_config/acdc, or per account in the account editor itself. The default is ""(nothing) which defaults to using the system global default.

We hadn't tested PSTN devices on agents since 3.08.  They did work on 3.08. We're going to take a peek around the code and see if we can fix it.

Dayton

Graham Nelson-Zutter

January 9, 2015 at 12:19 PM

Hi Dayton and Te,

It’s great that you and others are testing ACDc in v3.18! We too would like to make this upgrade and supporting ACDc is a big priority. 

I think there is a auto-logout feature for agents if they’ve missed a number of calls in a row. There may be defaults added to new queues that might be able to see the in queue config doc in CouchDB. There may also be a global variable for this in the ACDc config doc. 

We’ve not yet tried testing agents using mobile or other PSTN. We can’t confirm is this was working in 3.16. When you tested in v3.16, did this work?

thanks,

Graham

On January 9, 2015 at 11:53:31 AM, Dayton Turner (day...@voxter.ca) wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to 2600hz-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Dayton Turner

January 9, 2015 at 10:47 AM

Testing ACDc on 3.18, we're seeing a couple things that are causing us some grief:

1) After $someTime, agents seem to "auto log out".  They had logged in, could receive calls fine, and then suddenly stop taking calls - if they re log in, things are okay.  Anyone aware of any auto logout/etc sort of functions?

2) Calls to users that have cell phone devices have queue calls usurped immediately - even with 'require keypress' turned on, as soon as the call hits the carrier and gets ringing state, the caller has been hijacked.

Any input greatly appreciated!

Dayton

On Wednesday, 25 June 2014 15:51:19 UTC-7, Shiu Lam wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to 2600hz-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Sent with Postbox

[Graham Nelson-Zutter]

Hi Eamon,

Can you confirm which Kazoo RPMs you’re running?

In version 3.16 to 3.18, we’ve generally found that queues need to be “warmed-up” after their initial creation.

After the agent has been added to the queue in the UI, you may also want to dial both the Agent Login and Queue Login options from the agent’s SIP device. 

Once the agent has logged-in and they are also logged-in to the queue, the queue typically “warmed-up” and works on the next inbound call. If this is not the case for you, please restart kz-whistle_apps and try again. 

Please also include your output from /var/log/2600hz/kazoo.log

Good luck!

Graham

P.S. We’ve found that leaving the UI dashboard open over time can cause kz-whistle_apps to partially crash and detach from RabbitMQ. This is due to excessive queue and agent stats requests. 

To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.

[Eamon]

Hi Graham

I'm running latest version 3.19, I have the agents now logged into the Queue and call flow for external number assigned to Queue. Test call i get the default MOH no agent device rings. attached log file.

http://pastie.org/private/7bvy14l9pc0b7xhyymcyag

Thanks,

Eamon

Hi

To unsubscribe from this group and all its topics, send an email to 2600hz-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Dayton Turner

January 9, 2015 at 10:47 AM

Testing ACDc on 3.18, we're seeing a couple things that are causing us some grief:

1) After $someTime, agents seem to "auto log out".  They had logged in, could receive calls fine, and then suddenly stop taking calls - if they re log in, things are okay.  Anyone aware of any auto logout/etc sort of functions?

2) Calls to users that have cell phone devices have queue calls usurped immediately - even with 'require keypress' turned on, as soon as the call hits the carrier and gets ringing state, the caller has been hijacked.

Any input greatly appreciated!

Dayton

On Wednesday, 25 June 2014 15:51:19 UTC-7, Shiu Lam wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to 2600hz-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Sent with Postbox

[kevinlovesing]

hi Eamon,

i have the same problem with you,

 have you dealt with it?

在 2015年3月25日星期三 UTC+8上午12:59:08，Eamon写道：

[Eamon]

Hi 

No not yet, still have the same issue

[Eamon]

Hi Graham

Inbound calls to queues/agents are working on 3.18 ok

Thanks,

Eamon

[Graham Nelson-Zutter]

Hi Eamon,

Thanks for confirming that ACDC is now working for you in 3.18. We’re using 3.18-57 with success. Which sub version are of v3.18 are using?

It would appear that an ACDC dependancy missing or configuration change is required to get ACDC to work in 3.19. We have yet to really investigate this issue. 

thanks,

Graham

[Eamon]

Hi Graham

I'm running 3.18-54

Eamon

[tesarm]

Hi,

I'm unable to get it work - I can't see call_center app in GUI - I followed all 6 steps provided. 

Currently running Kazoo 3.22.

How can I check everything is configured properly and running? I'm not able to find what am I doing wrong?

Thanks guys,

Michal

[remc...@gmail.com]

I just issued a PR for ACDC on 3.22. It is working okay since 3.20, but was broken on 3.22.
Agents with multiple devices assigned or hotdesking caused weird behavior with calls boucing back into the queue.

Op donderdag 26 juni 2014 00:51:19 UTC+2 schreef Shiu Lam:

[Graham Nelson-Zutter]

Thanks for issuing the PR! 

We've seen evidence of these ghost calls boucing back into the queue in v3.22.52.

What release are you using in production? 

thanks,

Graham

--

You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to 2600hz-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

thank you,

Graham

Graham Nelson-Zutter

CTO, Co-founder

CloudPBX Inc.

204-1350 Burrard Street

Vancouver, BC  V6Z 0C2

+1 604 638 3848 ext 102

+1 604 343 6650 fax

[Kirill Sysoev]

Hi guys!

What about 4.0, did you have a chance to test acdc with it?
Suddenly felt tired telling customers to install FreePBX if they need queues :)
People are not satisfied with such a solution anymore unfortunately.

Regards,
Kirill

You received this message because you are subscribed to the Google Groups "2600hz-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.

[Yuriy Nasida]

Kirill,

Unfortunately Darren said that ACDC has been deprecated some time.

https://groups.google.com/forum/#!topic/2600hz-dev/jBr-3YTkUuE

I have to use Fusion PBX for queues now... really nobody is satisfied with such solution.

Regards.

To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "2600hz-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+unsubscribe@googlegroups.com.

[Kirill Sysoev]

Hi Yuriy,

Yep, I saw this thread and the saddest thing was that it could be moved to community scripts repo.
It is very sad 'cause ACDC will be obsoleted much more quicker over there, just because it will be out of "all-apps-through" changes 2600hz devs apply from time to time..

If I'm not wrong, I remember two main reasons ACDC wasn't accepted as a first class citizen in kazoo:
- not stable;
- not scalable (I believe it goes about federation).

But they say, latest patches made it acceptable from stability point of view and, besides that, not all Kazoo admins (including me) use federation.

I need to say that I never touched ACDC previously, and was waiting for new queues app.
But since the new queues app doesn't visible even "behind horizon", I feel that I will be forced to give a try to ACDC..

At the same time I understand that people who use ACDC will not be able to just stop using it.
And we all see now how cool 4.0 with loads of improvements is.

So, I believe some of us will be keen to use ACDC with 4.0 and maybe tested it already.

This, actually, was the ground of my question about ACDC and 4.0 :)

Thanks,
Kirill

To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.

[Dayton Turner]

Guys,

I have good news and bad news. Well, maybe not bad news. 

The good news: We are actively maintaining ACDC! We are running it in a multi node cluster environment, and have spent hours and hours rewriting chunks of the code to work in all sorts of permutations where agents could get stuck (I didn't ever think we would see an agent transfer a caller BACK into the queue while on a call that came in to the queue, but...). Some sections have been entirely rewritten (the stats backend, how agents live across cluster nodes to facilitate a failed whapps node, and more) 

We've added admin controls to the kazoo-UI dashboard to restart agent processes, log in/out, and most recently even added "additional pause states" so people can go pause for lunch, meeting, etc.  

The bad news: we have not been keeping up with pull requests as we go. What this looks like next, is that we'd like to take the time to merge not only up to the latest 3.22, but into 4.0. So the bad news is that this will still take a bit of time. We're about to deploy a 4.0 development environment, and merging up to 4 is something were dedicating a reasonable amount of time to. For me, I want to have this done a couple weeks before kazoocon so we're fresh and up to date on things before getting together with everyone 

We've easily spent 300+ hours on acdc improvements, bug fixes, etc and can confidently say we run it in production for at least a dozen call centers of various sizes; the largest taking thousands of calls a day. It's stable enough to handle our needs but still not totally perfect. I'm sure more edge cases will arise. But that's going to be expected. 

As I mentioned this is high on our priority list, getting all of our work merged up to 4.0. I'll be talking with 2600hz about how to continue to provide access to acdc going forward as well. 

Hope this helps!

--
Dayton Turner, CEO
Voxter Communications Inc
P: (604)629-8647 F: (604)629-8646
www.voxter.com

To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.

[James Aimonetti]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


I don't know the fate of ACDc as far as keeping it in Kazoo vs moved to
a community repo of sorts, so can't comment there. I agree that it would
fall more quickly into disrepair if someone in the community isn't
actively maintaining it. We generally try to script any changes to
source code (like renaming module/functions across the codebase) so
those could be applied to community repos too.

I would be interested in exploring having a community board whose
membership would be responsible for maintaining any apps/modules/etc
that isn't 2600Hz-supported, in addition to working with 2600Hz core
team on up-and-coming changes. If we broke the "community-supported"
apps to their own repos, we could add the community board as committers
to review/accept pull requests. I'm thinking something along the idea of
how Debian/Ubuntu have repos for different parts of the ecosystem. We
could have core, apps, and community, and kazoo.

It would be cool to install the "kazoo" package and be able to build any
app/community...something like 'make crossbar acdc' would fetch crossbar
from 'apps' and acdc from 'community', build a release and boom, you
have a tarball to put on the server to run crossbar and acdc in a VM.

I have a branch where I'm working through some of the fun circular
dependencies that we have among the app/core libs, which once resolved
would facilitate breaking things up a bit more.

But that's well down the road!

Anyway, this is all stream-of-consciousness at the moment; happy to hear
what would serve the community better in this regard. What do you want
to see happen?

>> <https://groups.google.com/forum/#%21topic/2600hz-dev/jBr-3YTkUuE>

>>
>> I have to use Fusion PBX for queues now... really nobody is satisfied
>> with such solution.
>>
>> Regards.
>>
>> On 19 August 2016 at 10:11, Kirill Sysoev <kirill...@gmail.com

>> <mailto:kirill...@gmail.com>> wrote:
>>
>> Hi guys!
>>
>> What about 4.0, did you have a chance to test acdc with it?
>> Suddenly felt tired telling customers to install FreePBX if they
>> need queues :)
>> People are not satisfied with such a solution anymore unfortunately.
>>
>> Regards,
>> Kirill
>>
>>
>> On 18.08.2016 22:25, Graham Nelson-Zutter wrote:
>>> Thanks for issuing the PR!
>>>
>>> We've seen evidence of these ghost calls boucing back into the
>>> queue in v3.22.52.
>>>
>>> What release are you using in production?
>>>
>>> thanks,
>>> Graham
>>>
>>>
>>> On 18 August 2016 at 04:56, <remc...@gmail.com

>>> <mailto:remc...@gmail.com>> wrote:
>>>
>>> I just issued a PR for ACDC on 3.22. It is working okay since
>>> 3.20, but was broken on 3.22.
>>> Agents with multiple devices assigned or hotdesking caused
>>> weird behavior with calls boucing back into the queue.
>>>
>>> Op donderdag 26 juni 2014 00:51:19 UTC+2 schreef Shiu Lam:
>>>
>>> Hi
>>>
>>> what is the status for ACDC (call_center) module, is it
>>> ready for Production?
>>>
>>> Thanks
>>>
>>> --
>>> You received this message because you are subscribed to a
>>> topic in the Google Groups "2600hz-dev" group.
>>> To unsubscribe from this topic, visit

>>> <https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe>https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.

>>> To unsubscribe from this group and all its topics, send an

>>> email to 2600hz-dev+...@googlegroups.com
>>> <mailto:2600hz-dev+...@googlegroups.com>.

>>> For more options, visit https://groups.google.com/d/optout

>>> <https://groups.google.com/d/optout>.

>>>
>>>
>>>
>>>
>>> --
>>> thank you,
>>> Graham
>>>
>>> Graham Nelson-Zutter
>>> CTO, Co-founder
>>>
>>> CloudPBX Inc.
>>> 204-1350 Burrard Street
>>> Vancouver, BC V6Z 0C2
>>>
>>> +1 604 638 3848 ext 102
>>> +1 604 343 6650 fax
>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "2600hz-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it,

>>> send an email to 2600hz-dev+...@googlegroups.com
>>> <mailto:2600hz-dev+...@googlegroups.com>.

>>> For more options, visit https://groups.google.com/d/optout

>>> <https://groups.google.com/d/optout>.

>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "2600hz-dev" group.
>> To unsubscribe from this group and stop receiving emails from it,

>> send an email to 2600hz-dev+...@googlegroups.com
>> <mailto:2600hz-dev+...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout

>> <https://groups.google.com/d/optout>.

>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "2600hz-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send

>> an email to 2600hz-dev+...@googlegroups.com
>> <mailto:2600hz-dev+...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.

- --
James Aimonetti

Lead Systems Architect
"If Dialyzer don't care, I don't care"
2600HzPDX | http://2600hz.com
sip:ja...@2600hz.com
tel:415.886.7905
irc:mc_ @ freenode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXtziXAAoJENTKa+JPXCVgZWEH/0fQvGgwXgvlw1AjI1UvHqLW
pL2on9NBjrCdW2pxwjDGpIeecNiS/rJrlwIxu+cuC5b9cIo/OkUuQzPWavbBbXNM
V2JEG+FELrOswOTm/JfYvWAgaf5s0zDLAa/7tOcY33ltlzUaaYHW5Viy8H0CztUd
03eEp1qg7YnRcG2Ai0bojl3cSawsrj9aimZDmFuJPjSeoBVBbB+eKLJoNU5xuBLu
o3wmulDEVQbEXig5le3xeMSCNNco+rPCiBO/8Gs3D+x4461aXEsbHjl8kGQF6pbX
BaNrcYONPhl+Rcb3Ez8l+eFLoJkJRirAjGQKVAjnJPNxjIFEcqvCTskyYkxiQC8=
=j2cs
-----END PGP SIGNATURE-----

[Dayton Turner]

*raises hand offering to help with community maintained repo*

We're already maintaining our own repo for internal purposes anyways, if we had an "official" or "approved" means of sharing this back through 2600hz channels, I would hop on that for sure.  We get asked all the time to give access to our own repo for the things that we've modified and have yet to PR (sorry, I know this is our fault) and I always say no because I dont want to get into a position of confusion or skew.  If we had a predetermined path, that would solve the problem. 

I like your idea of being able to "make" or "configure" 3rd party things as well!  (Or, something like the centos EPEL repo for instance)

James Aimonetti

August 19, 2016 at 9:49 AM

- --
James Aimonetti

Lead Systems Architect
"If Dialyzer don't care, I don't care"
2600HzPDX | http://2600hz.com
sip:ja...@2600hz.com
tel:415.886.7905
irc:mc_ @ freenode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXtziXAAoJENTKa+JPXCVgZWEH/0fQvGgwXgvlw1AjI1UvHqLW
pL2on9NBjrCdW2pxwjDGpIeecNiS/rJrlwIxu+cuC5b9cIo/OkUuQzPWavbBbXNM
V2JEG+FELrOswOTm/JfYvWAgaf5s0zDLAa/7tOcY33ltlzUaaYHW5Viy8H0CztUd
03eEp1qg7YnRcG2Ai0bojl3cSawsrj9aimZDmFuJPjSeoBVBbB+eKLJoNU5xuBLu
o3wmulDEVQbEXig5le3xeMSCNNco+rPCiBO/8Gs3D+x4461aXEsbHjl8kGQF6pbX
BaNrcYONPhl+Rcb3Ez8l+eFLoJkJRirAjGQKVAjnJPNxjIFEcqvCTskyYkxiQC8=
=j2cs
-----END PGP SIGNATURE-----

Graham Nelson-Zutter

August 18, 2016 at 12:25 PM

Thanks for issuing the PR! 

We've seen evidence of these ghost calls boucing back into the queue in v3.22.52.

What release are you using in production? 

thanks,

Graham

--

thank you,

Graham

Graham Nelson-Zutter

CTO, Co-founder

CloudPBX Inc.

204-1350 Burrard Street

Vancouver, BC  V6Z 0C2

+1 604 638 3848 ext 102

+1 604 343 6650 fax

--

You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.

[Kirill Sysoev]

+1 ready to participate and spend time for this

and thanks James and Dayton for comprehensive answers!

Dayton, I keep fingers crossed you'll be able to merge your ACDC patches into 4.0 soon.
I believe all the list looks forward for this to happen.

Regards,  
Kirill

You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.

[Graham Nelson-Zutter]

Hi James,

Thanks for sharing your ideas on how best to include community contributions of non-core features. 

It would be excellent to create a more formal plan to help the community maintain ongoing compatibility for platform enhancements as we move to v4 and beyond. The Ubuntu Universe model seems like a great place to start. 

I think having a dedicated repo would help the 2600Hz team as well: with a separate community repo that users would have to manually activate and use, there would be no confusion that 2600Hz would be responsible for the support and maintenance of these separate community enhancements. 

Just like Ubuntu does, it would be ideal to provide key contributors with direct upload access to this new community repo. These core members can help with community engagement and help review PRs. They could also elect to raise future contributors as full members with direct upload access.

If 2600Hz chooses to create this new community repo, I'd like to nominate 3 developers who have shown great commitment to the platform:

@siplabs

@onnet

@danielfinke

thanks!

Graham

>>>         email to 2600hz-dev+unsubscribe@googlegroups.com
>>>         <mailto:2600hz-dev+unsub...@googlegroups.com>.

>>>         For more options, visit https://groups.google.com/d/optout
>>>         <https://groups.google.com/d/optout>.

>>>
>>>
>>>
>>>
>>>     --
>>>     thank you,
>>>     Graham
>>>
>>>     Graham Nelson-Zutter
>>>     CTO, Co-founder
>>>
>>>     CloudPBX Inc.
>>>     204-1350 Burrard Street
>>>     Vancouver, BC  V6Z 0C2
>>>
>>>     +1 604 638 3848 ext 102
>>>     +1 604 343 6650 fax
>>>
>>>     --
>>>     You received this message because you are subscribed to the
>>>     Google Groups "2600hz-dev" group.
>>>     To unsubscribe from this group and stop receiving emails from it,

>>>     send an email to 2600hz-dev+unsubscribe@googlegroups.com
>>>     <mailto:2600hz-dev+unsub...@googlegroups.com>.

>>>     For more options, visit https://groups.google.com/d/optout
>>>     <https://groups.google.com/d/optout>.

>>
>>     --
>>     You received this message because you are subscribed to the Google
>>     Groups "2600hz-dev" group.
>>     To unsubscribe from this group and stop receiving emails from it,

>>     send an email to 2600hz-dev+unsubscribe@googlegroups.com
>>     <mailto:2600hz-dev+unsub...@googlegroups.com>.

>>     For more options, visit https://groups.google.com/d/optout
>>     <https://groups.google.com/d/optout>.

>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "2600hz-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send

>> an email to 2600hz-dev+unsubscribe@googlegroups.com
>> <mailto:2600hz-dev+unsub...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.


- --
James Aimonetti

Lead Systems Architect
"If Dialyzer don't care, I don't care"
2600HzPDX | http://2600hz.com
sip:ja...@2600hz.com
tel:415.886.7905
irc:mc_ @ freenode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXtziXAAoJENTKa+JPXCVgZWEH/0fQvGgwXgvlw1AjI1UvHqLW
pL2on9NBjrCdW2pxwjDGpIeecNiS/rJrlwIxu+cuC5b9cIo/OkUuQzPWavbBbXNM
V2JEG+FELrOswOTm/JfYvWAgaf5s0zDLAa/7tOcY33ltlzUaaYHW5Viy8H0CztUd
03eEp1qg7YnRcG2Ai0bojl3cSawsrj9aimZDmFuJPjSeoBVBbB+eKLJoNU5xuBLu
o3wmulDEVQbEXig5le3xeMSCNNco+rPCiBO/8Gs3D+x4461aXEsbHjl8kGQF6pbX
BaNrcYONPhl+Rcb3Ez8l+eFLoJkJRirAjGQKVAjnJPNxjIFEcqvCTskyYkxiQC8=
=j2cs
-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[remc...@gmail.com]

Hi Graham and others,

Sorry for the late reply, I was enjoying a laptop free holiday (sort of ;)).

We are on 3.22-61. Since the fix, ACDC works acceptable for us. We also have some helper script that "solves" agents becoming inactive when their supervisor crashes.
When this happens, agents are logged in according to crossbar but there is no longer a agent sup so they are not actually active. Agents do no longer receive calls.

I haven't found the time yet to further investigate this, so for the time being we do periodic checks if the agents are still there and if not we kick them using crossbar.
Please note that the time being is already since we were on 3.20. Some other things just had more priority.

Another thing is the dashboard. We discourage people to use it, because it just hammers crossbar and subsequently couch. We are currently sketching up some ideas for a simple wallboard.
In general, I would vote against moving ACDC to the community-scripts as it is just something we need (among others). It will be much harder to maintain compatibility if it is outside the main repo.

I see the issues with ACDC, it is not up to standards compared with the rest of the project. But its a key element every PBX platform has. And I think the main use is not callcenter (as in, a large room with numerous agents answering loads of calls) but just a way of distributing calls in a small business. Thats how we see it being used. The only difference with a ring group is that you can log-on and log-off and that the caller is being held instead of continuous ringing.
I think a simple and "light" ACD solution would be a great addition especially for SmartPBX, although not named callcenter but just "advanced ring group". Just my two € 0.02 ;-).

Remco


Op vrijdag 19 augustus 2016 00:16:29 UTC+2 schreef Graham Nelson-Zutter:

Thanks for issuing the PR! 

We've seen evidence of these ghost calls boucing back into the queue in v3.22.52.

What release are you using in production? 

thanks,

Graham

On 18 August 2016 at 04:56, <remc...@gmail.com> wrote:

I just issued a PR for ACDC on 3.22. It is working okay since 3.20, but was broken on 3.22.
Agents with multiple devices assigned or hotdesking caused weird behavior with calls boucing back into the queue.

Op donderdag 26 juni 2014 00:51:19 UTC+2 schreef Shiu Lam:

Hi

what is the status for ACDC (call_center) module, is it ready for Production?

Thanks

--

You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/MA1PcKa79zQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[kirill.sysoev]

Hi Dayton,

So...,  kazoocon ended, acdc PR merged ... and I can't resist to make sure if it is this PR you was talking about? :)

 

https://github.com/2600hz/kazoo/pull/2689

Regards,

Kirill

пятница, 19 августа 2016 г., 19:22:32 UTC+3 пользователь Dayton Turner написал:

To unsubscribe from this group and all its topics, send an email to ...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

thank you,

Graham

Graham Nelson-Zutter

CTO, Co-founder

CloudPBX Inc.

204-1350 Burrard Street

Vancouver, BC  V6Z 0C2

+1 604 638 3848 ext 102

+1 604 343 6650 fax

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dayton Turner]

That's one. There are lots more. We're doing them in specific order. Stay tuned :)

--
Dayton Turner, CEO
Voxter Communications Inc
P: (604)629-8647 F: (604)629-8646
www.voxter.com

[remc...@gmail.com]

Hi Dayton,

Great news, thanks a lot!
Any chance we could somehow get these fixes into 3.22 as well? As some of us will be on 3.22 for some time..

Thanks!
Remco


Op vrijdag 21 oktober 2016 03:10:43 UTC+2 schreef Dayton Turner: