Port 5004 for RTP

[cardguy44]

Currently we have the "Always User Port 5004" checked on the Shoretel 7.5 system. We would like to purchase IP8000 phones but I know that we would have to uncheck that box in order to install them on the Shoretel system and for SIP. If I uncheck this checkmark and reboot the switches, phone, etc. I am worried it will possibly degrade voice quality somehow on the Cisco switches. My question is if something doesn't seem right after the change is made can we check the "Always User 5004 for RTP " again and will everything go back to the way it was? Is leaving this box unchecked the standard on installs now?

[cburgy]

You can revert back once you have made the change.

You shouldn't see any degredation on voice quality unless you were doing your QOS based on UDP 5004 (bad). Qos should be done based on the DSCP bit (value of EF/184/46).

[jmccumber]

Just a note from experience, may seem obvious but worth mention. When you uncheck that box you need to reboot everything. I made the mistake of just restarting the softswitch (instead of a reboot of the Director server), rebooted all the switches and phones. Everything worked fine except we had a one way talk path for the voicemail. So when a caller reached someones voicemail it detected silence and stopped recording the message. Also people trying to set up new accounts could not record their name or greetings. Once I actually rebooted the server everything worked great.

Just another example when we thought ShoreTel was broken only to find it was user error on our part. The documentation actually says failure to reboot may result in a one way talk path...and it was right.

[Forrest]

TCP/UDP ports

My question relates to setting up QOS on our WatchGuard VPN solution. I see in your post Chris that you recommend, "Qos should be done based on the DSCP bit (value of EF/184/46)." And I'm not familiar with what you're referring to.

We out source our WatchGuard Managed VPN/Firewall solution and our network engineer has asked what TCP/UDP ports does the ShoreTel use for QOS.

That prompted me to check the forum and I see Chris's post and I'm not understanding the information well enough to pass it on.

Thanks,

Forrest

[cburgy]

TCP/UDP ports

My question relates to setting up QOS on our WatchGuard VPN solution. I see in your post Chris that you recommend, "Qos should be done based on the DSCP bit (value of EF/184/46)." And I'm not familiar with what you're referring to.

We out source our WatchGuard Managed VPN/Firewall solution and our network engineer has asked what TCP/UDP ports does the ShoreTel use for QOS.

That prompted me to check the forum and I see Chris's post and I'm not understanding the information well enough to pass it on.

Thanks,

Forrest

Unfortunately, Watchguard (like practically all firewalls) can't prioritize based on the DSCP bit. Routers with Firewall capability (i.e. Juniper JunOS ES, Cisco IOS) can prioritize based on the DSCP bit.

UDP 5004 worked fine before because all the voice payload was sent via that port. However, once you enable SIP support, the UDP port is randomized in a huge range making it far more difficult to effectively classify and prioritize traffic (if you just do the whole range, you will prioritize any other UDP traffic operating in that port range).

You set the DSCP/TOS bit in shoretel under call control options. Shoretel classifies it in the decimal format and it should be 184 unless you have a specific design calling for a different priority. 184 is the commonly accepted classification for voice traffic and places voice in the expedited forwarding queue.

DSCP (also called DiffServ) information available from here:

DiffServ - voip-info.org

DiffServ -- The Scalable End-to-End QoS Model  [QoS Signaling] - Cisco Systems

[cburgy]

It is also worth mentioning that you can't guarantee QOS over the Internet. Most of the carriers either ignore QOS markings or strip them from the packets as they traverse their networks.

Keep in mind with an internet connection that you have no control over the order in which packets are recieved, you can only control the egress of packets from your firewall to the next hop.

[Forrest]

Udp 5004 +

Thank you very much for adding the detail Chris. I'm passing this info on to our WatchGuard Admin. If he has additional questions I or he will follow-up.

Thank You!

-Forrest

[eazeaz]

DSCP Watchguard

I have not used this but the watchguard support site claims you can

: Are QoS priority settings based on 802.1p, DiffServ, or other standards?
A: Fireware 9.0 and later supports DiffServ and IP precedence (ToS) marking types with flexible marking methods for granular control over QoS settings.

i think

[cburgy]

They can mark biu that is different then prioritizing based on those bits. A lot of firewalls can mark/reclassify traffic but not recognize and treat traffic accordingly (police).

[eazeaz]

DiffServ

Well that sucks

[drvoip]

COS or TOS/DiffServ

We need to seperate issues as it relates to QOS. The reference to setting the TOS byte is a reference to older equipment that can only see the high order three bits of this byte generally set to EF (express forwarding (101 base 2 or 5 base 10 ); newer equipment can look at the last six high order bits, refered to as Differential Service Control (DiffServ) and as recommended by ShoreTel should be 184/46 in your call control options. If you do the arithmetic binary/decimal they all have the same bit setting and it just depends on what bits your router can see in the TOS byte of the IP packet. The issue is, that it is an IP packet and not a frame. This means that on your LAN, you have to use other that TOS/DiffServ to do QOS. Generally, in the ShoreTel world you would use VLAN tag 802.1p bits to set up COS and that is why it is a good idea to VLAN regardless of network size. An issue with ShoreTel QOS is that "plain vanillia" QOS can not differentiate between MGCP call setup packets; SIP interswitch messages packets and the media stream packets. In ShoreTel it is all marked the same. As some other talented professional has already pointed out, all of this QOS at the router level is lost if you are connecting sites via the public internet as you have no control over the routers between your end points. This is why mpls is considered the best solution. Some carriers like Cbeyond are offering VPN on peered network endpoints but will not offer QOS SLA's between different markets (e.g. LA - LA is ok, but LA to Dallas is not). When you add SIP, an application level protocol, to the discussion it gets more interesting. Keep in mind that QOS is an IP level marking. Again this means SIP aware firewall and routers are needed to assure end to end QOS on WAN networks.

[tkilmer]

A few weeks ago, we disabled the 'Always Use Port 5004 for RTP' setting in order to use two IP800 conference phones. Our LAN/WAN guy has QOS configured on our Nortel routers using the DSCP bit methodology as suggested earlier in this post. We have two locations (HQ and remote) on our MPLS WAN who are using the Shoretel phone system. It seems like ever since we disabled that 5004 setting, every time someone calls our remote location and gets their auto-attendant (which is stored at the HQ mind you), the auto attendant sounds 'choppy.' Our remote location has a local PRI for incoming calls, and obviously once the actual call has been transferred to the intended recipient from the auto-attendant, the call sounds fine. It's only when the auto-attendant is playing for the caller across our WAN is when the call sounds choppy. When we place calls from the HQ to the remote sites (and vice versa), the calls sound fine. Only the auto-attendant seems to be affected. Are there any suggestions on what I can look at?

Thanks,
Travis

[cburgy]

The Shoretel servers do not mark their packets with DSCP values, you'll need to use another mechanism to mark the traffic (i.e. a Layer 3 switch or Router).


Shoretel has an application note that discusses this:

Configuring WAN Quality of Service for ShoreTel ( App Note ST-0130 / App Note 130 )

[tkilmer]

Thanks Chris. I actually found this tech not shortly after I posted my message earlier. I'll check it out and go from there. We don't have layer 3 switches, so we'd have to mark it with our routers. Do you happen to have an expample on how to do this? We use Nortel routers, but the command line is similar to Cisco. I'm also not the LAN/WAN guy either. Thanks again for your help.

[cburgy]

Unfortunately, we do not have an example for Nortel equipment. We work with Juniper, Foundry, Procurve, Extreme, Enterasys and Cisco...