Several users on Rel.11 system complaining that when they attempt to answer an inbound call using the HEADSET button on their 6408D+ sets, there is often a delay of 3-4 seconds, or they can't retrieve the call at all. Only on a call back will it come through. We are using Plantronics M-10 amps which are set to 'Headset' all the time. The only action the user has to do is touch the HEADSET button and start talking. Anyone have this delay or disconnect problem I've described? I've removed the feature and reset it, busied, tested....
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!
Delayed answer on 6408D using Headset button
- Thread starter adminman3
- Start date
Hi,
I see that there are no replies to your question but this may assist in some way.
I have 6416D+ handsets with users on headsets and we struck a similar problem this week where the agent was answering the call but getting delayed connection. The caller at the A end could hear the agent but not vice versa.
In our case it seems to be the DS1 which is supplying the trunk for these calls was the issue. We busied that trunk and forced all calls to the second trunk in the route and the problem has gone away for most part of the day. The thing is we now have to do some testing on the DS1 to ascertain where the problem lies. This may not be the case for you but try to trace where the call is originating on the switch.
So how did we find it? If you have CMS CentreVu Supervisor running try starting traces on the agents that are affected (Agent Administration>Activate Agent Trace) and then run an historical report on the agent and select the report "Trace by Location". Unfortunately, the data is only collected starting after you turn on the trace. This will show you all of the calls the agent has taken since the time you started the trace, or for the date you select, whichever is longest. In the report you will see the calls taken and the time and the port ID for that call. This may point you to a specific DS1 card as the main problem. This is how we identified our issue. Hope this helps.
Zarbs
I see that there are no replies to your question but this may assist in some way.
I have 6416D+ handsets with users on headsets and we struck a similar problem this week where the agent was answering the call but getting delayed connection. The caller at the A end could hear the agent but not vice versa.
In our case it seems to be the DS1 which is supplying the trunk for these calls was the issue. We busied that trunk and forced all calls to the second trunk in the route and the problem has gone away for most part of the day. The thing is we now have to do some testing on the DS1 to ascertain where the problem lies. This may not be the case for you but try to trace where the call is originating on the switch.
So how did we find it? If you have CMS CentreVu Supervisor running try starting traces on the agents that are affected (Agent Administration>Activate Agent Trace) and then run an historical report on the agent and select the report "Trace by Location". Unfortunately, the data is only collected starting after you turn on the trace. This will show you all of the calls the agent has taken since the time you started the trace, or for the date you select, whichever is longest. In the report you will see the calls taken and the time and the port ID for that call. This may point you to a specific DS1 card as the main problem. This is how we identified our issue. Hope this helps.
Zarbs
- Thread starter
- #3
Your response is appreciated. A few variables stick out still. First, your 6416 sets...do they have a headset port underneath the phone which is activated when the user touches the Headset button on the phone? Our 6408s don't, but our 6416M and 6424M do. Curious about that. Also, I'm not sure that either the caller or the called can hear each other so I'll check that out. We'll also enlist the help of CMS with Agent Trace. Good call there. Many thanks!
If M-10 amps are anything like the M-12 then they may have a powersaving mode when they are on battery power. If they are unused for a period of time they will enter this mode and it takes either a few seconds of activity or pressing a button on the amp in order for them to wake up.
We have had this issue with M-12 amps in the past, but our users have learned to just hit the mute button on and off before the first few calls and then they tend to be fine for the remainder of the day.
We have had this issue with M-12 amps in the past, but our users have learned to just hit the mute button on and off before the first few calls and then they tend to be fine for the remainder of the day.
- Thread starter
- #5
- Status
Similar threads
