×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Dead Calls

Dead Calls

Dead Calls

(OP)
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?

RE: Dead Calls

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

RE: Dead Calls

(OP)
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.

RE: Dead Calls

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

RE: Dead Calls

(OP)
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...

RE: Dead Calls

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.   

RE: Dead Calls

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

RE: Dead Calls

Of zullen we gewoon in het nederlands verder gaan?

RE: Dead Calls

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

RE: Dead Calls

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

RE: Dead Calls

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?  

RE: Dead Calls

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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close