Site Switch HQ assignment

[carpadum]

Do you have to have a voice switch in the headquarters site? We have sites in remote offices but are not planning to deploy a switch in our headquarters site.

[Jlorenz]

Do you have to have a voice switch in the headquarters site? We have sites in remote offices but are not planning to deploy a switch in our headquarters site.

Absolutely unequivocally yes

However, there is nothing stopping you from placing that SG on the remote site but built under the HQ.

The issue with that is all Voice Traffic will be back and forth across the WAN twice.

If this is close to your design (As you can see, I am no graphics artists )

[carpadum]

Thanks for the reply. I want to make sure I understand what happens with the switch in the HQ site. We currently have one remote location that has a switch that is in the HQ site. We just installed another switch in a different remote location (child site to HQ). This new switch is having all kinds of strange issues with server communications. VM dropping, call transfers dropping, PCM dropping, etc. The phones work fine with no issues, only server related apps are having issues. We were wondering if there is any reason that the first switch being located in a remote area was the cause. Does the HQ server contact its HQ switch to process anything or does the switch that is closest to the client do the processing.....if that makes sense. ATTACHMENT

[Jlorenz]

Thanks for the reply. I want to make sure I understand what happens with the switch in the HQ site. We currently have one remote location that has a switch that is in the HQ site. We just installed another switch in a different remote location (child site to HQ). This new switch is having all kinds of strange issues with server communications. VM dropping, call transfers dropping, PCM dropping, etc. The phones work fine with no issues, only server related apps are having issues. We were wondering if there is any reason that the first switch being located in a remote area was the cause. Does the HQ server contact its HQ switch to process anything or does the switch that is closest to the client do the processing.....if that makes sense. ATTACHMENT

Far to many variables missing to realy understand what is going on. The System is only as good as your network. The ShoreTel sits on top of the network, with that said:

1. What is your WAN Like (MPLS, Dedicated T1, Public Network)
2. Bandwidth for site(s)
3. Steady Ping time between Sites
4. LSP_PING what is this showing for packet lost (Consult TAC or Partner)

These are just a few options I would look at. If the HQ is the only server, your remote site is totally Dependant on Network for best performance. If you can elaborate on your network topology then this would help a tad bit.

[carpadum]

I will try to explain a little better. There is also an attachment that shows links, speeds, site assignments, etc. Ping times are generally less than 40ms from the shoreware server to the remote location B switch. This is an MPLS circuit that has class of service defined so that all voice service is in the Real Time Queue. End to end we have monitored switch ports to verify there are no network errors, etc. Utilization on the WAN link is low. Phone calls from extension to extension across sites function fine. Users at Remote Location A have no issues with anything. This site uses an internet VPN which can not be setup with COS but it still works fine. Location B only has issues with Auto Attendant, Voice Mail, Call Handling, etc. Sometimes it works and sometimes it does not. Also the call manager application seems to only function part of the time. No errors found on the switches.
How do I do the LSP Ping test. I would like to verify that.
Thanks

[Jlorenz]

I will try to explain a little better. There is also an attachment that shows links, speeds, site assignments, etc. Ping times are generally less than 40ms from the shoreware server to the remote location B switch. This is an MPLS circuit that has class of service defined so that all voice service is in the Real Time Queue. End to end we have monitored switch ports to verify there are no network errors, etc. Utilization on the WAN link is low. Phone calls from extension to extension across sites function fine. Users at Remote Location A have no issues with anything. This site uses an internet VPN which can not be setup with COS but it still works fine. Location B only has issues with Auto Attendant, Voice Mail, Call Handling, etc. Sometimes it works and sometimes it does not. Also the call manager application seems to only function part of the time. No errors found on the switches.
How do I do the LSP Ping test. I would like to verify that.
Thanks

I am not sure if I can list this information openly regarding LSP_PING,

One of the areas I always suggest is to add to your QOS ports 5440 - 5446, 2427, 2727 under UDP as the Transport is defined. HTTP Port 80 is a must as well, since it is part of the PCM communication to the Server.

Your Location B is pulling all information from the HQ Server (A Known) your indicating issues with PCM, CHM, Auto Attendant and Voicemail. These are all dependent on your connection to HQ. What exactly is your SLA for the MPLS and when you mean Real Time Q, is this relative to "Detection of Traffic Only" it grows and shrinks Band width?

[carpadum]

Realtime meaning that any traffic defined as shoretel with the exception of http is put into the real time traffic queue on the mpls circuit. It gets delivered before anything else and can grow and srink up to a certain point. I believe it is 40% of the T1. Right now there is hardly any traffic on the link so know this is not a traffic issue on the mpls. I was wondering if the HQ server needed to talk to a HQ switch at all times so that it could find codec's and other information. If that was the case then something initiated from location B would need to also get information from Location A's switch which would mean traffic on both the mpls and vpn links.

[Jlorenz]

Realtime meaning that any traffic defined as shoretel with the exception of http is put into the real time traffic queue on the mpls circuit. It gets delivered before anything else and can grow and srink up to a certain point. I believe it is 40% of the T1. Right now there is hardly any traffic on the link so know this is not a traffic issue on the mpls. I was wondering if the HQ server needed to talk to a HQ switch at all times so that it could find codec's and other information. If that was the case then something initiated from location B would need to also get information from Location A's switch which would mean traffic on both the mpls and vpn links.

In Bold above
Absolutely, your SLA should be a sustainable burst rate at all times not as needed. If your Traffic sizing, meaning growing the Bandwidth on the MPLS as needed then this must go. And yes your correct about site a and B as well, LSP does keep alives 24,7,365 every few seconds, same as the HQ through RPC port 111 under UDP and TCP. PCM is effected by this as well, in short, you pipe from HQ to Site B must be open at all times