Dead Calls 1

[BIS]

Hello Everybody.
A curious situation has arisen, perhaps some of you have heard of this before. We are on a G3R V8, and it seems as if sometimes (and only sometimes), exactly every second call is 'dead', by which I mean the caller and the the receiver cannot hear each other. The caller hangs up, calls back and everything is fine. This is happening in an ACD environment, we are using EAS if this is of any help. Personally I think this is something to do with the public network, but you never know...I have checked the trunks etc but see nothing out of the ordinary. Any ideas?

 

[LeoVBrown]

A couple of questions:
1 It it only ACD calls?
2 What type of trunks are the calls coming in on?
3 Are you using vectoring?
4 Is there a prompting step in the vector?
5 If the agent and caller hang on long enough do they finally get talk path?

One thing I have seen in the past and this was on outgoing calls, is that there was a faulty touch-tone sender board that after pulsing out digits it wouldn't drop off the line. In effect the two callers and the sender were "conferenced" but the sender actually blocks the talk path. It is possible on an incoming call with vectoring and a call prompting step for this to happen.
If there is no prompting then my next guess is the trunk group. I am assuming that you have DS1 or ISDN trunks and your agents have DCP phones. Try to record the the instances of the problem and see if it is related to a particular trunk board or digital line card. If there is a pattern, try replacing the board. Check if there is any frame slips on the digital trunks.
It could be the network but before you can get them to do anything, you really have to do a good job of debugging your end.
Hope this helps.

Leo V. Brown

 

[BIS]

Leo,

Thanks for your response, it does give me a few options. A few answers: I don't know if this only happens on ACD calls, but this is at least where it gets noticed. I am using standard vectoring on ISDN (E1) trunks, and yes there is prompting involved. The agent and caller generally don't hang around enough to answer your last question.
You might have a point with the prompting. Some calls are entering a simple IVR treatment (through conversant), I am currently looking into the log files there. I have also set up agent trace through CMS to try to pin down the cause. The trunks look OK, no frame slips (error seconds on the DS1 cards) either.
Thanks for pointing me in this direction, I will let you (and everybody else who reads this) know the outcome of this case as I progress.

 

[LeoVBrown]

It could be that the conversant is not dropping of the call when the call is delivered to the agent. What does your vector look like? Are you using the converse step to go to the conversant? I think you are on the right track on checking out the Conversant. There could be a port on the conversant that is not disconnecting after it performs a flash transfer. The call is transferred back to the vector and the caller would hear silence since it is on soft hold when the call is delivered to the agent, the agent is "talking" to the Conversant.
Leo V. Brown

 

[BIS]

Leo,
Just standard converse on steps, sending DNIS and ANI. The call is passed back to the vector with a FAC (converse data return code) and digits, vector collects digits and routes accordingly. I am still investigating...

 

[KoenT]

Do you know if this happens on KPN-trunks or some other provider? Have you divided your trunks into incoming- outgoing and multidirectional channels? We had some problems with versatel trunks, apparently their isdn-switch doesn't support dividing your trunks into channels with specific directions.

 

[BIS]

No,
None of the trunks are split, both incoming and outgoing is possible.

 

[MKU]

Of zullen we gewoon in het nederlands verder gaan?

 

[cclausen]

If you pass the call back from the Conversant using a converse data step, it looks like you are doing this, you can pass up to 20 digits (yes I know documentation refers to 16 digits) back to the switch.
The receiving vector will now receive the digits via a converse data return. Assume the collect step does a "collect 10 digits". Assume however the IVR sent 14 digits. The left over digits are stored in digit buffer. The next collect step in a vector woul get the remaining digits from the bufer. Any uncollect digits sent but not collected are left in buffer until the next collect step.

Is the conversant sending more digits then expected?

IE: IVR does a converse data return and sends 12345678904444
Receiving Vector collects 10 digits and does it thing.
The left over digits 4444 will now move from the collected digits buffer to the digits in the switch. The next collect step (assuming you were collecting 4 digits) would get 4444 as the collected digits.

Hope this is not confusing.

Chris

 

[BIS]

Make sense,
And I wasn't aware of this. However in this case this limit is not reached. Thanks for your input though

 

[robsuttonjr]

Have you tried calling out directly on all of your trunks to make sure you don't have any faulty circuits? I have also had an intermittant problem with the loopback connectors that attach to the integrated CSU's and once removed the problem went away. Also have you done list measrurement ds1 xx?

 

[BIS]

Sorry Guys,
Should have closed this. Turned out it was a faulty (read old) expansion interface to the EPN.