We had dedicated lines for our ACD enabled handsets. They also had a
direct assigned extension. Our support agents had a reason to have both.
I didn't realize it might or might not have helped with potential
issues. Our server was (it is still doing the job, I'm just not with
that company any more) a relatively robust HP DL360 with 16 GB of RAM.
I'm guessing it was a quad core proc. I didn't have the 127.0.0.2 issue,
but we also did not NAT at all (not sure if that is relevant). Our
server was directly connected to the Verizon SIP network with no NAT.
On 8/31/2012 6:57 AM, Matt White wrote:
The audio issue you mention is likely due to resources. There is no
doubt the ACD is a resource hog. Specifically CPU. Which odd as the
rest of sipx seems to be more RAM constrained.
We used to have issues with the choppy audio until we standardized our
platform with an ODM 3-4 years ago. The equipment we have used for
the last 3-4 years has a Dual Core Core2 w/ 8GB of ram and an
enterprise Intel SSD. Its starting to get dated but even our largest
call centers run well on that.
I have not had any of the other issues you mentioned. But I will note
we never use the "presence" with the ACD. For us, its not needed.
In a call center, the people manning the phones are only their to
answer ACD calls. So unless they are on a current queue call....they
shouldnt be on the phone. The ACD then doesn't have to worry about
subscribing to the presence of each phone. It know when the queue
call starts/ends.
Other than the ACD has been pretty straight forward for us. Only once
in a great while do we get the call thats stuck in the call stats and
we have to bounce the CDR. I'd say once every 6 months. But most of
our customers get a non-acd stuck call in the CDR about once every six
months anyways.
They only consistent change we make to the acd to make it stable is to
set a local subnet under "internet" for 127.0.0.2 (in fact now we add
the entire 127.0.0.0/24 subnet as local)
I think 127.0.0.1 is in by default but we cant even pick up queued
calls without 127.0.0.2 listed. We discovered that a few years back
when 4.2 came out....should be a thread on it. Traces showed the ACD
would reference 127.0.0.2 and not 127.0.0.1 and it would think the
call is natted and throw the public natted ip in the response.
But I'm not sure if that is unique to us or not. We maintain our own
builds based on SLES so it may be in how we compile.
-M
>>> On 8/30/2012 at 07:30 PM, in message
<CAEpO7ZwUGFuXu=2UKuwmVLuC1ekia+2L=wgidkts9lu5cqs...@mail.gmail.com>,
Melcon Moraes <[email protected]> wrote:
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 <[email protected]
<mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>>
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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
List Archive:
http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430 <tel:434.984.8430>
sip: [email protected]
<mailto:[email protected]>
Fax: 434.465.6833 <tel: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 <tel:434.984.8426>
sip: [email protected]
<mailto:[email protected]>
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
[email protected]
<mailto:[email protected]>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
<mailto:[email protected]>
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 <tel:978-296-1005%20X2015>
M.207-956-0262 <tel:207-956-0262>
@mpicher <http://twitter.com/mpicher>
linkedin
<http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com <http://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
[email protected] <mailto:[email protected]>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
