<div>Erik,</div>
<div> </div>
<div>Dont give up so soon, AC has not been a reliable application but it can be troubleshooted with little help. CTI redundancy is something which should consider,twiking the parametters of CTI service should also be considered. AC logs when the problem occures can be picked from client pc to see what component fails.
</div>
<div> </div>
<div> </div>
<div>Aman<br> </div>
<div><span class="gmail_quote">On 11/13/07, <b class="gmail_sendername">Scott Voll</b> <<a href="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Arc Console might be a good third party option for the customer.<br><br>Scott<br><br>On Nov 12, 2007 11:49 AM, Erik Erasmus (E) <
<a href="mailto:ErasmuE4@telkom.co.za">ErasmuE4@telkom.co.za</a>> wrote:<br>><br>> Hi Justin<br>><br>> Unfortunately they customer wil not budge from the fact that he wants Qing<br>> -- Can try again. For the HQ I did set up a demo for them where we use IPCC
<br>> express and agents combined with the ac client and they were not even keen<br>> on this - a case of I baught it make it work. For branches - even if they<br>> give in to the IPCC express idea I can not use it because I can not allow
<br>> the voice media across the wan for all attendant calls in a branch to the<br>> central IPCC express.<br>><br>> I will keep it in mind anyway - maybe we get (or the customer gets ) so<br>> desperate that we have no choice but to look at other alternatives like the
<br>> one you mention -- thanks<br>><br>> I am opening a tac case tomorrow<br>><br>> erik<br>><br>> ________________________________<br>> From: Justin Steinberg [mailto:<a href="mailto:jsteinberg@gmail.com">
jsteinberg@gmail.com</a>]<br>> Sent: Mon 2007-11-12 21:34<br>> To: Erik Erasmus (E)<br>> Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> Subject: Re: [cisco-voip] ccm 4-2 remote branch attendant console problem
<br>><br>><br>><br>><br>><br>> Does this environment absolutely require AC call queuing ? If you can<br>> get away from this need, maybe you can switch from AC hunt groups to<br>> CM hunt groups. You could still use AC software for call control,
<br>> just not TCD for call routing.<br>><br>> The benefit of this is that since you're on CM4.2 you could use the<br>> hlog key to control call flow.<br>><br>> I know this doesn't directly answer your question, but it's atleast an
<br>> option if it fits.<br>><br>> Justin<br>><br>> On Nov 12, 2007 2:21 PM, Erik Erasmus (E) <<a href="mailto:ErasmuE4@telkom.co.za">ErasmuE4@telkom.co.za</a>> wrote:<br>> ><br>> ><br>> > I have a customer on 4-2-3 sr3 with central cluster and one branch both
<br>> > sides using cisco attendant consoles. Had issues with the attendants for<br>> > months now. before we were on sr3 we had calls stuck in the attendant Qs.<br>> > Cisco promissed this will be fixed in sr3 and we loaded it -- will wait
<br>> and<br>> > see -- lasted a couple of days now. We also had a problem at the branch<br>> > attendants. Randomly - once a day or sometimes twice a day or some times<br>> not<br>> > at all the attendants receives a call from the pstn on the voice gateway
<br>> > PRIs but the caller and the called attendant can not hear each other for<br>> > several seconds - eventually the voice stream come through and they talk.<br>> > The attendant then needs to treansfer the caller to an Ip phone in the
<br>> > branch and this alos fails - the transfer just doesn't want to happen.<br>> When<br>> > we reset tcd service and cti manager things start working again. I am<br>> going<br>> > to open a tac case again but not that hopeful so looking for ideas. Have
<br>> > already checked:<br>> ><br>> > wan - 256 Kbps MPLS circuit from central ccm cluster to branch - looks<br>> good<br>> > and not highly utilised<br>> > QoS - wan and lan looks good<br>
> > call manager config looks fine because 99.9% of time things work correctly<br>> > attendant PCs and apps fine and latest 4-2-3 sr 3 builds<br>> > happens at all three remote attendats so no one PC or port etc problem
<br>> > lan switches look fine<br>> > voice gateway - configured like many others and clocking looks fine<br>> > remote branch runs MOH multicast from flash<br>> ><br>> > as said will open a tac case but can not rely on this only - with stuck in
<br>> Q<br>> > it took several weeks before cisco admitted it was a bug.<br>> ><br>> > Unforunately the customer does not have sasu or ucss so can not upgrade to<br>> > anything and with call centres etc hanging of the CCM cluster not
<br>> something<br>> > one would just tackle lightly one afternoon. Keeping sharp objects away<br>> from<br>> > myself because I am getting depressed<br>> ><br>> > any ideas<br>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<br>> > This e-mail is subject to the Telkom SA electronic communication legal<br>> > notice, available at :<br>> > <a href="http://www.telkom.co.za/TelkomEMailLegalNotice.PDF">http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
</a><br>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>> ><br>> > _______________________________________________<br>> > cisco-voip mailing list<br>> > <a href="mailto:cisco-voip@puck.nether.net">
cisco-voip@puck.nether.net</a><br>> > <a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>> ><br>><br>> _______________________________________________
<br>> cisco-voip mailing list<br>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip
</a><br>><br>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">
https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></blockquote></div><br>