Welcome to

Welcome to!

This site was created as a place to share stories, tips, and troubleshooting help with ShoreTel/Mitel systems. ShoreTel/Mitel is obviously the MOST exciting VoiP platform on the market right now, and we realized there was no centralized place to discuss this platform, but now there is. Please feel free to join and share your experiences.

Please Note: This site IS NOT owned, funded, or managed by ShoreTel/Mitel, Inc. although you may find ShoreTel/Mitel employees sharing there experiences and expertise. If you would like more information on ShoreTel/Mitel systems, contact BTX at [email protected]

As always please support the advertisers that help support our site.

Thank You,
See more
See less
  • Filter
  • Time
  • Show
Clear All
new posts

  • Odd CC agent issue

    We've been running our Shoretel system since the beginning of the year. One of the unresolved issues has started to occur more often and there doesn't seem to be an immediate fix that I can find on the forums.

    Ok, enough of the preamble. The issue is that randomly agents (all agents are connected on our LAN, no VLAN/VPN/etc.) will be disconnected from the system. Now, at first I thought it was something related to the agents having too many resources taken up, streaming too much data, or something similar which was causing connectivity issues with the server. Here's the catch : Not everyone is having the same problem. The only systems that are having the problem are the ones running the regular agent toolbar (as opposed to the supervisor CAC). All agents are running the agent toolbar and the softphone.

    Now occasionally it was happening at random while the agent was not interacting with a call. This is where my thoughts on traffic congestion had arisen. Once I addressed this with the people in question, that part of the problem ceased (basically, they were pulling too much data and it was causing the toolbar to time out)... Here is where the issue separates from a simple network congestion issue:

    Agents will be ready to receive a call on idle. A call will be routed to them. Their toolbar status bar changes color to yellow with a note of "Busy" (sometimes it will turn green/ACD, then go yellow/Busy immediately). At this point, the call is handled in one of three ways (also seemingly randomly): The call is dropped completely, the call is routed to the next available agent, or the call is routed to the operator. Once the call has left the agent (mind you, we're talking fractions of a second), the agent then receives the standard "You have been logged out of all of your groups" message due to losing connectivity with the server. They must close the toolbar and log back in in order for it to work. Sometimes this won't happen for a couple of days for some agents and for other agents it can occur for a period of time during the day where it's happening every 4-7 minutes.

    So far I've wiped out profiles (thinking it was a profile issue linked with the way things were stored by the software), reinstalled the software and reinstalled the software after clearing out the registry of anything that contains Shoretel, Shoreline and Shoreware (and also of anything that hints of "Shore").

    Any ideas?

    Thanks in advance,

  • #2
    Time to Involve TAC

    I would begin gathering Logs and get the TAC involved, it sounds like there is a bug to me. It is, remotely, possible that this is still linked to congestion, but you should be able to look at your switches and see that in the console (what kind of switches are you using by the way, and is your VOIP traffic VLANed off on it's own or in the mix with everything else); the other thing that jumps to mind is that possibly the Call Center package is running into some kind of glitch that ShoreTel will need to qualify and patch.

    I would love to hear the outcome of a TAC call.


    • #3
      Yeah, I suppose you are correct that it is likely a bug. This has occurred even through rebooting, so I'm sure it's not a buffer issue or anything like that.

      The traffic for the phones are on the same network as the rest of the traffic. These occurrences have happened when there have been no calls to be heard of then one coming in out of the blue (we actually run a call center help desk). Then there are times when the agents are slammed with calls and it isn't occurring. This is what made me think that maybe this was not a congestion issue.

      There are about 25 computers running into a pair of switches over a 100M LAN. The network is actually quite reliable in this sense. I have also sniffed the packets on the network and found that even with the number of computers that are connected that the overall traffic is relatively low.

      So which logs do you think I should be looking at specifically? When I look at the agent's log, it says that it was a 6 second call that was terminated (i.e. nothing as in 'we lost the call'). I'm pretty adept at the system for not having much experience with it, but I am definitely new to it.


      • #4
        Logs to Pull


        I actually have never had to hand in Contact Center Logs, but I can tell you what you need to start for the ShoreTel System itself and TAC will fill you in on anything else you need.

        1). All system logs from the date in question. (The best thing to do is pick a day when you know what the call time stamp was when it happened and then put in the request about that specific instance) These logs are located under the "C:\Shoreline Date\Logs\" directory and you will need one of each type of log that contains the date in question. (Dates are embedded in the names of the logs)

        2). You will also need a dump of the system database. That can be obtained by opening a cli and then changing your directory to the root bin for the MySQL database, (i.e. C:\Program Files\Shorline Communications\Shoreware Server\MySQL\MySQL Server 5.0\bin\) and then running the command "mysqldump.exe --user=root --password=shorewaredba --databases shoreware --routines --single-transaction > <<FILE.SQL>>" where the "<<FILE.SQL>>" is replaced with desired path and filename of the database dump.

        3). They also like it when you provide info on your severs (I would get an info on the CC server as well. START / All Programs / Accessories / System Tools / System Information File / Save (Saves as an .NFO file) File / Export (Saves as an .TXT file)

        4). Include a copy of the server even logs for both servers for the day in question.

        5). Provide the call GUID for the call that experienced the issue. (Can be found by right clicking on the call in the history tab and selecting "properties" there will be a "support info" link at the bottom of the dialog box that will bring up the GUID)

        Like I said, that should be a good start and get them off of the ground. TAC always feels free to ask for more information if they need it.


        • #5
          Excellent. Thanks for the response. Sorry for the slight delay in response, but was kept rather busy yesterday!

          Anyways, I have an occurrence for yesterday, so I can use that as a log. I have one of the people who having it most frequently occur send me an email whenever it happens. I'll gather up the logs and contact support. Thanks again for the help.