Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ACD Dead-Air Problem

Status
Not open for further replies.

trin14

Technical User
Mar 8, 2007
20
0
0
Hi Guys,

On one of our ACD Q's, agents are receiving dead-air phone calls. This is a random problem and appears to be happening a dozen times a day.

I've enabled call trace, but that hasn't told me much as far as the CLID goes.

MCE CUST00 RM099 044 *ACD5006 7:57:38 7/04/2007
CLID# *DN5006 NPI:1 TON:2

The calls usually just display as 6001 on an Agent set. It doesn't appear to be an actual phone call and we are not receiving and complaints from clients about this issue.

When I print the DN for 6001 this is what I receive:

REQ: prt
TYPE: dnb
CUST 0
DN 6001
DATE
PAGE
DES

DN 6001
TYPE RDB
ROUT 99

Any idea’s or assistance will be appreciated.
 
It's an actual call, 6001 is the ACOD of your route 99 coming into the pbx/acd queue. Might turn on msgo on the dch for route 99.
 
msgo or msgi.. i for inbound.. that can cause a ton of msgs on high traffic.. i had a simular problem.. it looked like a trunk would "hang" then recall to an agent... i changed supervision to no, and changed the acod to 7 digits.. if 6001 is a did, then be sure to block it via an idc.. we have all 10K did's so we have strange problems

john poole
bellsouth business
columbia,sc
 
Thanks John and bigindian,

I have enabled MSGO and MSGI.. I will keep you updated.
 
msgi is the only one you need for that acd scenerio, JP cleaned that up for me there. If you dis the msgo, that will save you some research, as all this will print on a real time basis, and you'll have to match up a dead air call time to your msgi time when your watching it. Hopefully you have low inbound volume when the problem re-occurs. Good luck.
 
How can I get my company's name to display on my Nortel sets. It is still showing Nortel.

Thanks in advance.
 
dennislyn What does your question have to do with the original question????????????

Start your own thread, don't highjack some else's.

Plus you might get a quicker answer.
 
Even with MSGI turned on that may not help you. If someone is calling in with privacy set on their phone you won't receive the incoming digits in your data stream. Had this problem with another of my customers...

This is a synopsis of what we went through...

The reported problem was Caller Line Identification not showing up on display phones and calls not being routed properly incoming on the T-1.

The routing problem was easy just adding the IDC table number to the Route block. Note: Had to add the IDC table number to both DCNO and the NDNO fields. For some reason the switch was routing on the Night routing during the day.

The caller line ID problem was a little more difficult. The actual problem was not for all calls. They're actual complaint is that when their customers hit "*67" to turn off Caller line ID, the calls don't display. By enabling messaging display on the D-Channel (ENL MSGI {D-Channel #}) I saw that the Caller line information was not even coming in. Paetec said that they were sending it regardless in the ANI Stream and we were not looking in the right place for it. Of course our switches look for caller line ID only in one place (by industry standards). Only 911 centers can extract the ANI information from a different portion of the stream. If we don't see it in the D-Channel call setup information we can not display it. This problem was solved in two steps:

First: Paetec Changed their database. They turned on "Privacy Override". What this does is send the Caller Line ID information no matter what. This was proven by viewing the Maintenance terminal and seeing the Caller Information in the D-Channel call setup information. However, when the call was presented to the phones, all that was shown was the trunk group and the associated channel. Caller information was still not being displayed on the phone even though the information was getting to the switch. The reason for this is that even though they are sending the information they are also sending a flag that marks the call as private. Therefore our switch honored that privacy request.

Second: To override the privacy request, in load 16, we answered yes to PII field. PII stands for Privacy Indicator Ignore. So now we are telling the system to ignore the privacy flag and the calls display normally on the phones whether or not the caller uses "*67".
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top