I am quite impressed with your success stories. :) I used to have an ACD running pretty well on a 4.0.2 box. Now, I have some 4.4 boxes and all kinds of issues. Have you ever faced some of them?
- Audio issues. People complaining about chopping voice and noise. Indeed, if I call the extension directly, without passing through ACD, there's a noticeable difference in the audio quality. - Realtime statistics - some calls that enter the queue and got picked up never "leave" the queue. On *sipxacd_events.log* one can see the events "enter-queue", "pick-up" and "terminate". Sometimes there is the "transfer" event as well. Some calls never got the "terminate" event written on that log. Then you have on Calls Statistics page calls with +70min long, when the real call took only 3min. - Routing to agent: still on the above example, ACD Presence shows the user as idle but the ACDServer "thinks" the user is still not free. That agent will never get a call again until you restart ACDServer. - sipxacd.log is full of "2012-08-30T18:44:02.139782Z":934039:KERNEL:NOTICE:sip.example.com:MpMedia:B6BB1B90:sipxacd:"OsMsgQShared::doSendCore message queue 'mpStartUp::MpMisc.pSpkQ' is over half full - count = 12, max = 14" +1 on what Todd Hodgen said about the best practices/tips. Sorry to hijack the thread. - MM On Wed, Aug 29, 2012 at 9:29 AM, Matt White <mwh...@thesummit-grp.com>wrote: > I've often heard it cited that the old ACD cant transfer out of the > queue. I think this is based on very old info....pre 4.2 days. We have no > less than hundreds of calls (if not thousands) across several customers > sites sending calls into queues and back out to non ACD extensions. ACD > has preformed very well for us and is very stable (i cant think of one ACD > related crash/issue). When it comes to transferring out of the queue, I'd > say our heaviest call center customer that has 23 agents and processes no > less than 800 calls a day will transfer 50% of the calls from and agent out > of the queue to a regular extension. They even transfer ACD calls back out > to external numbers (hairpins). > > In fact, we have a customer that has some pretty complex call flow in and > out of the ACD. > Calls come into the queue. If its not answered it overflows out to an AA > where they get custom options to keep holding etc. they then get > transferred back into a second ACD queue. This happens multiple times. > Siptraces are quite long because each call stays anchored in the queue > which is great for reporting. > > Hunt groups do not provide was call centers want. Call center managers > need to run reports based on when an agent signed in/out; how long did they > talk; how long did they ring; how long are customers waiting in queues and > how many customers are stacking up in queues.... > > The distinctive tone as noted in this original thread and modified caller > id are also part of that need. > > Hunt groups just dont preform these functions (if they did, they would be > an ACD and not a hunt group). > > So for us, the bulk of our installations are call centers. As VOIP/SIP > becomes more common place its increasingly difficult to sell something that > just does call routing and voicemail...there is just so many cheap and > hosted solutions if thats all you need. Which is why are installations for > the last few years have moved up the stack to customers that have more > specialized needs. > > So for us, our dilemma is get sipXacd maintained internally (we have an > elance dev working on that now), or look for a new platform. > > -M > > >>> Michael Picher <mpic...@ezuce.com> 08/29/12 6:53 AM >>> > > The problem with the old ACD, every time I tried to use it, was that it > was fragile. Do this, don't ever do that, etc... Any time I tried to use > it in a situation the customer (and then ultimately me) had a bad > experience. > > If they can make it stable, and make it so you can transfer calls out of > queue that would be awesome. > > Most people don't need a real ACD (even though they think they want an > ACD). What they need are fancy hunt groups which is exactly what the 4.4 > ACD does. > > Work has begun on a new hunt group app that will hopefully alleviate the > need for an ACD in cases where it really isn't needed. This will be based > around some new code and involve a B2BUA that can 'own' the call and then > hunt out. This will be in contrast to how hunt groups work now where it's > a SIP messaging nightmare. > > Circular hunt groups, linear hunt groups, being able to ring the same > extension at more than one point in a hunt group are all envisioned. At > some point I'd even like to see users be able to (from a phone or user > portal) login/out of hunt groups, or only ring certain users for different > days/hours in a hunt group. > > With the current workload I wouldn't expect anything until 4.8 though. > > Thanks, > Mike > > On Wed, Aug 29, 2012 at 6:21 AM, Matt White <mwh...@thesummit-grp.com>wrote: > >> Funny, the beep is one reason my customers wont move to openACD. OpenACD >> for my customers that need a true ACD. The old ACD worked well despite its >> bad rap. >> >> We have a developer working on get sipXacd ported over to 4.6 so there is >> hope yet. >> >> As to your specific issue, I don't think the tone is an audio file, so >> you would need to create a patch to remove it. >> >> -m >> >> >> >> >>> Ali Dashti <ali.das...@gmail.com> 08/28/12 9:14 AM >>> >> >> Thanks Tony, one thing that made me go back to 4.4 ACD was the CallerID >> and DNID! In 4.4 ACD when a call arrives; an agent would see a Queue name >> and the Line extention in CallerID but in OpenACD even the DNID changes to >> agent extension number; therefore prevents me from knowing what number was >> dialed!! This was my primary result, do you see this as well? >> >> On Tue, Aug 28, 2012 at 5:29 PM, Tony Graziano < >> tgrazi...@myitdepartment.net> wrote: >> >>> fyi - If you are referring to the existing ACD (not openacd) I don't >>> think any resources are going into it as it is being removed in favor of >>> the openacd integration starting up in 4.6. >>> >>> On Tue, Aug 28, 2012 at 8:55 AM, Ali Dashti <ali.das...@gmail.com>wrote: >>> >>>> This could be a very old issue! I was wondering if there is a way to >>>> remove the beep heard a short moment after an agent picks up a call on >>>> ACD!! Thanks. >>>> >>>> _______________________________________________ >>>> sipx-users mailing list >>>> sipx-users@list.sipfoundry.org >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>> >>> >>> >>> >>> -- >>> ~~~~~~~~~~~~~~~~~~ >>> Tony Graziano, Manager >>> Telephone: 434.984.8430 >>> sip: tgrazi...@voice.myitdepartment.net >>> Fax: 434.465.6833 >>> ~~~~~~~~~~~~~~~~~~ >>> Linked-In Profile: >>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> Ask about our Internet Fax services! >>> ~~~~~~~~~~~~~~~~~~ >>> >>> Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab >>> 2013! >>> <http://sipxcolab2013.eventbrite.com/?discount=tony2013> >>> >>> >>> LAN/Telephony/Security and Control Systems Helpdesk: >>> Telephone: 434.984.8426 >>> sip: helpdesk@voice.myitdepartment.**net<helpd...@voice.myitdepartment.net> >>> >>> Helpdesk Customers: >>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> >>> Blog: http://blog.myitdepartment.net >>> >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > > -- > Michael Picher, Director of Technical Services > eZuce, Inc. > > 300 Brickstone Square**** > > Suite 201**** > > Andover, MA. 01810 > O.978-296-1005 X2015 > M.207-956-0262 > @mpicher <http://twitter.com/mpicher> > linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro> > www.ezuce.com > > > ------------------------------------------------------------------------------------------------------------ > There are 10 kinds of people in the world, those who understand binary and > those who don't. > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
