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!
SIP firmware for ShoreTel handsets?
November 22nd, 2009
Related articles
Amazon Connect "Tool Kit"
Building Tools for Amazon Connect Administration Over the years I have come to learn that if the folks who develop [...]
How can an Agent Originate an SMS message in Amazon Connect ! - Part 2 Routing the Return Message
SMS Return Message Routing In part 1 of this blog we looked at three options that enable an Agent to [...]
How can an Agent Originate an SMS message in Amazon Connect !
Pinpoint SMS For some time now, you have been able to channel SMS messages through the Amazon Connect CHAT API, [...]