Tweet
I am hosting several servers for a client of mine. At one of their remote sites they setup a call center and installed a Shoretel system. I setup a new term server at my hosting site to direct all of the call center users to use that TS. The Shoretel reseller installed the Shoretel client app on the term server, however we are having a couple of issues with the Shoretel app. I have a 3MB point to point connection between the hosting site and the call center. I have been monitoring the bandwidth and found that at peak times they only spike to 1.8MB of usage. What is happening is that the shoretell client disconnects from the shoretel sever. Then cycles back and forth, connects, disconnects, connects, disconnects, etc... The Shoretel sever is at the call center and the term server is at the hosting site. As anyone seen this before???? I am at a loss, and it is causing headaches for my client.
-
-
I started a post last week about the same issue and have yet to find a resolution. THe Call Manager application contacts all the end points and basically enumerates all the devices from what i understand...
your situation, sounds exactly like mine:
Please keep me posted if you hear anything, and i will do the same.
-t -
Yeah I looked at your post and you have a very similar situation. I am getting involved because the Shoretel vendor wants to blame the network, Server, and WAN connection. I have gone thought all of the setting with a fine tooth comb and have not found a thing wrong with how things are setup. I also setup a traffic probe on both routers and they are not coming close to maxing out the pipe. I am beginning to think this is a bug or config problem with the shoretel software.Comment
-
Losing Connection
We had a similar issue when we first installed. It turned out to be a known bug in watchguard firewalls. The connection would work for a while, then cycle up and down, then work, etc. It never affected any other traffic except the shoretel traffic (because the entire phone system was on a seperate physical network and port of the watchguard).
3MB is plenty for the call manager to function properly.... especially if you have QOS (which you should) turned on giving preference to shoretel traffic.
I think this issue will live somewhere in firewall/vlan/access list/qos/etc land.
Can you post some general network configs, router configs, hardware, qos,vlan, etc?Comment
-
Eazeaz, thanks for the reply. I am glad to hear that someone else has had this issue. Right now I don't have QoS enabled on the router because I don't know what Protocols the Shoretel apps use. I am not running any voice across this circuit at all, just the connection for the PCM client sitting on a term server, which communicates with a stack of Shoretel switches and the Shoretel server / call manager (I think) across the point to point. There is no firewall in the way of the connection, just a 3MB point to point using Adtran Routers.
If you or someone could lend some assistance with what ports / protocols the Shoretel apps use and an config example that would allow me to setup some QoS / prioritazation for the Shoretel traffic.
Thanks....Comment
-
Adtran Routers
Can you look at the interface statistics on the adtran immediately after the PCM drops connection and see if any packets are dropped out of the output/input queues.
Since you are not running any voice I am not sure how much the QOS will apply in your situation.
Can you post the config of the adtran?Comment
-
I do not notice any dropped packets when the problems occur. I have attached a document that I received from another person with the ports and protocols that the PCM software uses. However the port range is very large. The second attachment is the router configs. They are the same config on both ends.Comment
-
Adtran Routers
I know this may sound strange, but it may be worth looking into.
At first glance, (to me anyway) it looks like the clocking on your T1 configs may not be correct. It does not appear that you are running a DSX port, but your T1's are set to "Through" clocking. In addition, only ONE T1 is set.
Both T1's on one end should be set to INTERNAL and both t1's on the other end should be set to LINE (if it is truly a PTP clearline t1...).
With incorrect clocking the circuit/connection could work for hours/days/weeks/months and then begin to "slip" causing intermittent connection loss.
I am not really familiar with the adtrans anymore, so take the suggestion for what it is worth.
I saw something VERY similar just a few weeks ago. Other types of traffic will retransmit, and you will never know the connection was lost/slipped.Comment
-
Ok, I made sure the clock source is now setup correctly. I usually know to look for that stuff when I config a router, however I must of overlooked that when I was working on these. I am trying to figure out how to come up with a way to give prioritazation to the RPC traffic for the communication between the shoretel switches and server to the PCM clients on the term server. Do you think that would be worth a try.Comment
-
Qos
I *think* that the PCM clients only talk to the shoretel server, and not the switches. So you could do simple catch-all QOS policy for any traffic going to the IP address of the shoretel server.....
The only downside is that when you do an upgrade, and the clients (your TS servers) pull down a new PCM client, it will saturate the connection between you and the server as it will give priority to the download as well.
I really do not think QOS may be necessary for what you are doing. Since you now have one side set to line and one to internal i wonder if the problem will go away/lessen?
let us know. It sucks to have the thread die and not know what fixed the problem.
If the clocking was truly off, I am suprised that it has been working as well as it has been. You should have seen millions of timing slips. The PPP multilink makes them worse. Anytime one T1 suffers an up/down/slip the multilink goes offline for a second or so.Comment
-
Eazeaz I did put a "catch all" QoS / ACL policy in place on the router. However you are probably right in that it will not help much. I believe that QoS really only helps on a saturated link, in this case we are not even close.
Even with the clocking being off I did not see any slipping on the counters or any errors, which is odd. Usually when clocking is off the T-1 really does not even come up. But I am glad that you caught it and it is now corrected. Who knows that maybe the problem.
If you have any other suggestions let me know, also thanks all your help.Comment
-
Errors
You wont see timing slip errors on the interface statistics. If you call the phone company and have them pull stats, they should see a ton of them at the smartjack.Comment
-
Errors
Here is a bit more info for you. I did add the QoS policy and it did help a bit. It took about 30 seconds off the login time to the Shoretel PCM. Here are the exact error messages they are getting.
"TAPI Connection is unhealthy or extension is not being serviced"
"Server Configuration is Unavailable"
The first error comes up as they are logging in to the PCM app or when they get kicked off completely. The second error message cycles (in a pop up balloon), and they get kicked off the PCM app.
From what I can tell this PCM application is not very WAN friendly, or am I just missing something with the config. Is there any way to optimize the PCM application for WAN operation?Comment
-
Login Times
30 seconds "off"? How long is it taking you to login?
The PCM is very WAN friendly by default (with the exception of a PCM Upgrade). Current shoretel architecture only allows one voicemail server to control call functions for ALL sites. This means that if you have 100 locations, ALL of them communicate back over the WAN to the Main shoretel server. They do this without problems... even over slower links.
We have 40 people on the other side of a T1 and login times are about 2 seconds to the PCM.
1. Did your vendor install the Call manager application using the TS instructions... or just throw it on there? You never know.
2. Is there any sort of firewall between you and them or is it a clean straight link?
3. There aren't two NICS configured on the shoretel server for the two networks is there?
4. If you do a continuous ping do you lose replies when the call manager drops (could indicate a problem with the voicemail server itself since your citrix sessions stay up).
Can you post a tracert from your TS server to their Shoretel server?
Also, If you setup a pc/laptop with the call manager (not a citrix/ts server) and login over the WAN does it act that same? This would elimiate the TS/citrix servers/setup of the PCM on the TS.Comment
-
PCM Response
Right now it is taking about 2 to 3 minutes for the PCM application to come up and fully connect to the Shoretel server. Right now we have a group of 20 telemarketers logging into the term server at the hosted site. The PCM software is installed on that term server. I made sure that it was installed for the terminal server per the instructions in the manual.
To Answer your questions:
1. I made sure it was installed correctly for term server
2. We have a 3MB point to point connection / no Firewalls
3. There are 2 NIC's in the Shoretel server and the Term server. They are currently configured for fail-over mode. (Both servers are HP's)
4. I have run extended and continuous pings across the link and the latency is 40ms with no dropped packets. There is 1 hop between the TS and the Shoretel server, the hop is the Point to Point router.
Setting up a PC with the PCM clinet at this end is a good idea. We did somewhat take it a step further and setup a 2nd terminal server and put it at the remote end (where the ShoreTel server is installed), installed the PCM software and found that it works great. We then shipped the server to the hosted site and then tried to open the PCM software and found the same issues with a long delay; 2 to 3 minutes; to open the PCM software, as well as it dropping off-line.Comment
Comment