VOIP Tech Blog

To the sales team, I sound like a broken record as I repeated the engineering driven mantra: “A VoIP solution is only as good as the network it is build on”.     No matter how many times we tell clients that you can not obtain reliable, predictable toll quality voice communications over the public Internet, they insist on having us implement it.   The old marketing adage “you do not give customers what they need, you give them what they want” clearly applies and despite our best arguments to do otherwise; we find ourselves implementing VoIP solutions using VPN over DSL or Cable.   The good news is that when it works,  it is  often useable for inter-office communications.   When it does not work, it sounds like the worst cell phone  call and would not be something that you would use to support business communications with a client.

In the VoIP world in general and the ShoreTel world in particular, there is a measurable performance difference between an MPLS deployment and a VPN tunnel through the public internet.    An appropriately designed MPLS circuit with carrier Service Level Agreements in place will out perform the best VPN tunnel through the public internet.   Yet clients continue to believe they can put a VoIP handset  at the bosses house and run it over a DSL based VPN back to the “puzzle palace” and that it will  perform as well as the phone on his office desk.   The reality of the deployment is that this implementation seldom meets customer expectations.

A ShoreTel deployment of a remote handset for a home based work force can be accomplished under two basic models.   In the more desirable, albeit more costly model,  we create a “site” which involves the placement of a ShoreTel media gateway (read SG switch) at the remote location.  VoIP handsets interact with the SG media gateway or call manager at the remote location for all call setup, addressing, signaling and control.    In the ShoreTel world the call setup between a VoIP handset and an SG media gateway will use the MGCP protocol.   This protocol is a client/server or master/slave model and when compared with other protocols can generally be summarized as complex and “chatty”.   ShoreTel implements SIP for SG-SG communication, but uses MGCP for SG witch to handset call control.  Once a phone call is setup up, only the RTP media stream needs to traverse the VPN tunnel, however.

The other less expensive model s the placement of a remote VoIP handset only.   In this model, the handset is part of the “headquarters” site.  Unfortunately this is the deployment model we see the most when clients attempt to interconnect a single home worker with the corporate network with out the benefit of a carrier SLA.     A DSL, hopefully with a static IP address, and a device that can support a “point-to-point” VPN tunnel are the “minimum daily adult” requirement for VoIP connectivity.   In this model, the VoIP handset is communicating MGCP over the VPN tunnel with a call manager at the headquarters location.  Every handset action, from off-hook to digit key depress, is communicated over the VPN tunnel back to a media gateway at the home office.  Very “chatty”.

As engineers we can talk ourselves into a coma when discussing QOS options, DSCP markings, router queuing strategies and bandwidth reservation parameters.   At the end of the day, however, the only QOS “opinion” that really matters is what the users thinks!   Mean Opinion Score or MOS is the measure of what users rate the quality of a phone call.   Here is what we have learned after supporting hundreds of remote users on none SLA based circuits, typically VPN over DSL and Cable.   Rule one:  use only symetrical circuits (same up and down load speeds).  Rule two: Hard phones beat soft phones; and Rule three:  SIP phones beat MGCP phones.  It is that simple.   If we put a SIP based phone at a remote location, they will out perform an MGCP based handsets on the same circuit as measured by user MOS!  The SIP phone will perform with a higher level of reliability, be more resilient to latency and jitter, and will experience significantly less call disconnects than an MGCP based VoIP handset.

If you study the hosted VoIP service provider market, you will find that the predominant VoIP handset deployment strategy is SIP based.   Why is that?  We could go completely geek on you and  illustrate the complexity of call setup comparing MGCP with SIP setup messages, but why bother.  MOS rocks.  In this environment SIP deployments will yield higher customer satisfaction scores than MGCP deployments.   We are sincerely hoping and praying that ShoreTel has a “SIP firmware load” on the product road map to support their family of outstanding desktop handsets as they do not have a SIP handset solution.    Currently, when we have to support remote workers who insist on running VPN tunnels over DSL and Cable, we deploy Polycom and Aastra handsets to achieve maximum customer satisfaction in the wild west of internet telephony and home based workers!

DrVoIP ShoreTel Configuration, Shoretel Support and Service, Sip Phone, Trixbox Asterisk, VoIP Tech Tip mgcp protocol, sip firmware

This is a follow up post to an earlier post on LLDP-MED. VoIP phones on the market today follow the same basic boot and operations process:

1 – Wait for an LLDP packet from the Ethernet switch

2- Send a DHCP discovery packet to find the DHCP Server

3- Send a DHCP request to the DHCP server to get an IP address

4- Send an LLDP-MED packet to the Ethernet switch

5- Wait for an LLDP-MED packet from the Ethernet switch and read the Network Policy TLV to get the VLAN ID, L2 priority and DSCP value

6 – Download applciations and software from the “call manager”

7 – After configuration , voice packets are sent as tagged frames and data packets are sent as untagged frames

The ShoreTel implementation of LLDP seems to follow this process only after step 5, the result of the IP Phone learning LLDP by having its firmware configured. In other words, a phone out of the box is a hung of iron with no inherent ability to define itself as an IP phone to an LLDP enabled ethernet switch. The ShoreTel phone will still require an intial boot in the native VLAN and then reboot in the voice vlan, where it will then download its firmware. The real value here, is that once this process is “learned” by the ShoreTel phone, should the phone restart for any reason in the future, it can start at step one above. LLDP in ShoreTel is a version 9.1 feature enhancement not available in earlier releases of ShoreTel.

DrVoIP Shoretel Support and Service, Sip Phone, VoIP Tech Tip, Voip Service & Solutions ShoreTel LLDP, The ShoreTel implementation of LLDP, VoIP phones

If you are and iPhone aficionado, you absolutely want your iPhone to work  on your ShoreTel IPBX! I recently downloaded VeNetCorps SipPhone fromt the iPhone App store! There are several SIP phone apps at the store, but most have a pre-programmed domain name for the sip registration proxy server. If you want to use your own SIP proxy there was no easy way to change the IP address so you had to hack your DNS to get it to point to the ShoreTel SIP proxy. Also you need at least iPhone firmware 2.2 as previous versions had WiFi connectivity challenges that negatively impacted the potential for using a SIP softphone. After the iPhone WiFi acquired an IP address, if you attempted to ping the address you would see latency in excess of 300ms. With version 2.2 this issue has all but become unnoticeable. As with any SIP extension setup on ShoreTel, you need to assign sip extension proxy resources on a ShoreGear switch. In the sites section of the ShoreWare Director, make sure you assign a virtual IP address. This is the address you will use for your “domain’ when you setup the Iphone SipPhone. Clearly you will need a User setup with a SIP phone password defined in the individual user section of the ShoreWare Director.

Clearly the assumption here is that you have a WAP that your iPhone can connect to. Also that that wireless connection can route to your ShoreTel network! Once the ShoreTel SIP user, virtual IP address and proxy resources are configured it is time to configure your iPhone SipPhone! After you down load the application and tap to activate the application you will get a screen that lists the options: Dialer, Recent, Contacts, Accounts and Settings. Hit the Accounts tab and you will then EDIT a new SIP account. To get this app to work on ShoreTel you need to enter only three values. First you need to enter the domain name, we have previously defined in the ShoreTel Director as the Virtual IP address. The Username and password are also as specified in the individual user setup in ShoreTel. Hit the DONE tab, and the phone should register and you can make and receive calls from your ShoreTel. I put together a video clip that covers this so you can see that it accutaly works! The video suggests that you enter the user name, but if you want to call the iPhone from a ShoreTel extension, enter the user’s extension number instead.  This was just a fun project and latency on the iPhone WiFi is still a challenge for SIP phone usage.  I suspect that Version 3.0 of the iPhone will fix this small issue, but it was a blast trying it out!  Enjoy!

Add your iPhone as a ShoreTel SIP extension!

DrVoIP ShoreTel Configuration, Sip Phone, Voip Service & Solutions iPhone running SIP on your ShoreTel IPBX, IPhone shoretel, iphone shoretel ipbx, iphone sip

When VoIP gateways first started hitting the market back in 98′, the vendors tried to packetize DTMF and quickly learned it did not work well.   For this reason they quickly learned to “regenerate” DTMF at the outbound gateway rather than packetize and truck it across the network.   Moving modem tones is even more challenging and most VoIP solutions discourage attempting to send modem tones over an IP connection.  If you can get it to work at all, the modems will negotiate down to about teletype speed or about 300 baud. (Now there is a device and an term you don’t hear much about anymore).   Given that a fax machine generates modem tones, faxing over an IP connection is equally challenging.  ShoreTel makes it possible, for example, to attach a low end fax server as a couple of analog IPBX ports.   Incoming fax calls to the IPBX system, can reroute these faxes and even regenerate the DID number as DTMF to the fax server enabling fax to email applications.  What we are beginning to see as the SIP market matures, is that the phone companies are bringing PRI circuits to the customer premise disguised as traditional TDM circuits.   Your Telco interface may in fact be a ShoreGear T1, but you are interfacing to an Integrated Access Device that is converting SIP signaling  to SIP and then on to the Telephone companies softswitch.   Currently, this is a big problem for fax machines connected as analog lines to the host IPBX.  True Fax over IP is going to require a T38 interface and fax machines and servers that can support this protocol.  The message here is, make sure you know what you are connecting to!  True TDM or a SIP trunk!  Knowing the difference will enable you to properly handle fax traffic.

DrVoIP Sip Phone ipbx, ipbx systems, SIP, sip trunk, VoIP Fax, VoIP gateways

In telephony, IP QOS is somewhere between a science and an art. Setting up VOIP QOS on your network is essential for toll quality voice from end point to end point, especially across a WAN. Historically, in ShoreTel, IP packets were marked with the DSCP value set in the Call Control Options page. Generally this is generally set as a value of 184 or Precedence Level 5, what CISCO would call Express Forwarding or EF. This value is represented as 184 (10111000 or 46) but as a TOS/Differential Service Control Point marking it is only applied to the IP layer and has no impact on your LAN. Additionally, IP packets were only marked on the media stream between IP phones, not between the switches or between the phones and the switches. Version 9 of ShoreTel, now reports “system wide” TOS/DSCP support, which represents a significant improvement in your ability to control VOIP QOS. At the LAN level, it is important to know that you are working with Ethernet frames and for this reason the only QOS marking available to you is a VLAN tag. Inside the VLAN tag, three bits have been set aside for precedence markings and are named COS for “class of service”. If you are NOT running SIP on your network, you have another QOS tool available to you. ShoreTel media streams in other than SIP environments run on UDP port 5004 enabling you to prioritize voice over data at the transport level. ShoreTel also provides the opportunity for you to establish “admission bandwidth control” per site, to assure that the next phone call does not exceed the limits you have set with this parameter. Beware that this parameter exists only within the ShoreTel architecture and has no real knowledge about the actual bandwidth utilization of your network. Establishing this threshold is left entirely to the engineer designing the network. In large part IP QOS is best determined at the IP level and is heavily dependent on establishing queue in your routers that service latency sensitive traffic, voice and video, over less sensitive best efforts traffic. Knowing about these different QOS markings is the science. Knowing how to pass markings from one level to the next is the art of QOS!

DrVoIP Business Voip, Sip Phone, Voip Service & Solutions cisco qos, ip qos, voip qos