CUBE SIP Header Matching – Extracting DNIS from a Toll Free Number!

The Problem – Call Forwarding DNIS to Toll Free Numbers

Recently we were presented with a new challenge while deploying a Call Center based on the CISCO UCCX Version 11.5 feature set. Generally, we employ DNIS as a strategy for defining the CSQ  service parameters.   The more specific you can make the inbound number, the less you will need to “prompt and collect” digits from your caller.   A call to a specific DNIS number can separate the English callers from the other language options, or route “customer service” differently than routing “technical support”.   DNIS is always a preferred routing strategy.    Using DNIS we can design a single call routing script that can  pull in the CSQ name; offer up the proper audio menu’s; provide unique queue handling options and customize the caller experience all based on the dialed number.

In this centralized scheduling application for a large national medical practice, patients would call a local number in their community.   This number was then forwarded by the carrier to a toll free number that rang into the centralized CISCO cluster and UCCX call center.   The issue was setting up the dial peers to address the number the caller dialed, not the toll free number.   These numbers terminated on a SIP trunk that was serviced by a CISCO CUBE and the number presented was the 10 digits of the toll free number.   The DNIS number, or the number that the caller originally dialed may or may not be buried in the TO field of the incoming SIP headers.

Solution – Step 1 Debug Captures of inbound SIP messages

We need to setup “debug ccsip messages” and “debug voice ccapi inout” and make some test calls.   We need to understand how the carrier is handling the forwarded number.    In the log output below we can see the INVITE is the 877 toll free number.   The number that the caller dialed is the 9323646969 number and we can see that it is in the TO filed of the sip message headers.   We will need to write a dial-peer,voice class uri,  translation rule and profile that extracts the TO field and routes on that number rather than the original INVITE.   It is the “voice class uri” that is most magical in this solution.   (Note that we got luck here and the carrier was handling the call forwarded number in a manner that was appropriate to our goals.   This however is not always the case)!

 

Solution Step 2 “Voice Class URI”

In this example, the caller is dialing 93236453XX which is being call forwarded to the  toll free 877 number and shows up in the sip headers in the TO field.   The solution here is to create a “voice class uri”  rule.  In the snippet below we can see “voice class uri 102 sip” with a “user-id of 9323645323” as an example.   We are going to ultimately want to translate this to a four digit extension number 5323 and this is done with the traditional translation rules.  In this example “voice translation rule 102” does this conversion.  Note however that the translation rule refers to a match on the 877 toll free number, not the  9323645323 number.  This is where the magic of  “voice class uri”, the ability to do dial-peer matching based on the uri.

The Voice Class uri is structured such that it has a unique TAG and then a matching expression or host IP address.   The the snippet below we can see two attemtps to setup up a uri filter based on the last digits in the TO field of the SIP header.  Tag 102 looks to match 5323 and tag 103 looks to match 5324:

Solution Step 3 Dial Peer Matching

The call flow is dictated by dial-peer matching.   From the following snippet:

dial-peer voice 103 voip
translation-profile incoming 5324
session protocol sipv2
incoming uri to 103
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad

!

dial-peer voice 102 voip
description Incoming – FAX DID
translation-profile incoming 5323
session protocol sipv2
incoming uri to 102
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad

We can see that the voice class reference is applied to the dial-peer much the way a voice translation-profile is applied with the expression “incoming uri to 102” which sets up a filter to match for the number  9323645323.  Note that the dial peer matches the voice class but it is the translation-profile incoming 5223 that changes the ten digit number of the URI to the desired four digit extension.  In fact if you study the voice-translation rule 102 rule 1, references the toll free number!

These tools, the voice-translation rule and the voice-class uri work together to enable us to route and match dial-peers on information in the uri and not necessarily the original INVITE sip: number! Way powerful!

 

 

Use an Ingate SIParator and you are “virtually there”!

We have written on the subject of SBC quite extensively in the past and have also covered the easy installation of the Ingate product (see DrVoIP here).   Readers must find this interesting because the hit counter for our Ingate videos continues to grow, indicating engineers are eager to learn more about this product.   We generally regard ourselves as CISCO brats, but when it comes to Session Border Controllers, we remain deeply impressed with both the Ingate product and, most importantly, the Ingate support team!  Pre-sales support is typically as good as it gets when developing a relationship with a vendor.  Post sales support, however, is where the true value system of a company is tested and Ingate passes with high marks.

Ingate SIParator as a virtualized appliance

Ingate, began shipping product as early as 2001 and has its roots in firewall security products.  Ingate has now made its very popular SIParator Session Border controller available as a virtual software appliance.  The SIParator E-SBC, scalable from 5 -20K sessions can be obtained as either a hardware appliance or as a software package.  There are over 10K SIParators installed and working worldwide, making Ingate the “go to” knowledge base for documented SIP deployment experiences that is without equal on a global basis!   Those of you working with ShoreTel have already discovered how powerful a vmware ESXi deployment can be.   New options for fail safe, high availability and increased reliability magically appear when you virtualize your deployment!   Ingate is no different and the availability of the Ingrate SIParator as a virtualized appliance adds a significant level of both reliability and flexibility to your ShoreTel deployment.

The most widely asked question in the DrVoIP technical support forum:  “Is there a need for a Session Border Controller?”   Why can’t we just use our firewall is a common theme.  Though it is possible to use a firewall to do a SIP trunk implementation, it is not our best practice recommendation to use a firewall in that way.  Even firewalls with AGL SIP functionality fall short of the wide rage of features needed for true SIP arbitration.   We are firm believers that firewalls already have enough work to do and are being attacked even more ferociously every day by a wider group of hackers and evil doers than ever before.   If you are committed to using a “firewall” to do SIP deployments, then we urge you to consider at least using an Ingate SIParator Firewall as a best of breed solution!

A dedicated Session Boarder Controller

Session Border Controllers have a lot of work to do!  The concept of normalization alone could fill a text book.  The fact is,  not all SIP implementations are equal.It is often necessary to swap SIP message headers to achieve the desired results!   Try getting your firewall, unless it is a SIParator, to do a SIP message header translation and you will quickly understand why a dedicated Session Boarder Controller makes sense!

IngateFeatures

The software SIParator is easy to obtain, easy to install, easy to configure, and easy  to license.  Ingate has adopted a pay as you go philosophy, and though the software product scales from 5-2000 channels, you only pay for what you use!  In fact, Ingate is so confident in the adoption rate of its product over competitors,  they offer a 30 day free trial.  Just click here to take advantage of this outstanding offer.

The video is Part one of a two part video on the product!   Part one shows how to obtain, download, and install the virtual SIParator software package.  Part two goes through the configuration of the SIParator on a ShoreTel system for use in SIP trunking deployments.  This material was previously covered in our YouTube video on Ingate and that material is still relevant!

Kudos for Ingate

Lastly, we want to commend Ingate not for having a great product,  but for the quality of the support they offer the entire industry by an ongoing commitment toward the education of the market place on SIP and, now WebRTC technology.   We are not talking about thinly masqueraded advertising, but serious SIP education programs for serious technology students, and a demonstrated sincere desire to advance the state of the art!  They offer an endless variety of webinars,  seminars, ebooks and even work in partnership with the SIP school to further develop and educate industry stake holders.    Excellent work  Ingate and well done! – DrVoIP

 

V14 Configuring ShoreTel SIP Trunks P2 -SonicWall or InGate SBC?

A question that keeps coming up in the support ticket system is the subject of InGate and Session Border Controllers.  Folks want to know if you need a SBC to configure a SIP trunk.  Why not just use a Firewall?  Can you configure ShoreTel SIP trunks to work without a SBC?  The simple answer is “yes” but the smart answer is “no”.  In our humble opinion, just because you can do it, does not mean you should do it!   Session Border controllers, like those offered by Intuit for ShoreTel,  provide functionality not normally found on a firewall.   “Normalization” for example, the ability to mediate ShoreTel SIP and your carrier’s  SIP, as they most likely speak a different “dialect” of the common language SIP, is not a standard firewall feature.

Application Level Gateways, sometimes take actions that are injurious to SIP messages.  Remember, SIP was not designed for NAT based networks.   Something has to keep track of which internal private trusted network users made a SIP request for service to another IP address across an untrusted boundary!  Which RTP (voice, video or “media”) ports need to be opened to support this request?  SBC can do this more effectively than firewalls. At the end of the day, you end up turning off the SIP ALG functions in your firewall to make it work! (In SonicWall turn off  “consistent NAT” and “SIP transformations”.)

We have never recommended bringing your SIP services into your VoIP deployment over the same circuit as your Internet circuit, but so be it.   At least, let’s use a separate IP address and make use of the DMZ port on your firewall, if you are not going to use a separate circuit!  Let us try to keep the SIP traffic from undergoing the same port specific inspections you put the Internet traffic on!  Again our best practice recommendation for ShoreTel, if you are serious about SIP trunks as the main Communications link for your company, is get an Intuit SBC and bring your service in on a separate circuit or IP!

SonicWall has for sometime, had a number of “service objects” to support the ShoreTel MGCP phones.  In fact, before SIP was enabled on ShoreTel, all media flowed on port 5004 which was really great for enabling transport level QoS!   Though there is a steady trend to use TLS and get both SIP messages and RTP over a single port, most SIP carriers expect to send messages on UDP 5060.   So if you are using a SonicWall, you will need to create new Service Objects, and put them in new Service Groups to get SIP to work.   You will need to configure Network Objects for your ShoreTel SIP proxy and configure access rules.  We recommend you also create a network object for your ITSP rather than enabling  an open 5060 for all the script kiddies running SipVicious!

We will do this again on a  CISCO ASA 5505 just for giggles as we get a lot of requests for that as well!  At the end of the day, however, for a serious business application of SIP trunks on ShoreTel, get a separate circuit and invest in an Ingate SBC!  Heck, you can even get a virtualized version of InGate!

V14 Trouble Shooting ShoreTel SIP

ShoreTel SIP is just not that hard to configure! When things go right, and it all works, it is relatively painless and very easy.   When things don’t work however, you will need to sort out the problem and figure out how to make it work.   The good news is that SIP is a clear text, english like “requests” and “response” message exchange that, once understood can be relatively easy to work with.   Using packet capture tools like Wireshark can be a real assist.   ShoreTel has built “remote packet capture”  into the V14 diagnostic portal and makes debugging sip issues even more easy to digest.

The message exchange for SIP “extensions” is not much different than that for SIP “trunks”.   So to learn SIP why not study a successful SIP connection first, before diving into a debug session.  What we have tried to do in this tech tip, is to illustrate the process of a SIP extension registering with a ShoreTel proxy server.   We picked a configuration that is comparatively complex, but not unlike one that you might find in the real world.  SIP extensions can unit remote office workers into a seamless call handling workgroup.  As such your remote worker will traverse a couple of firewalls and routers on its way to the SIP proxy.

In this configuration we register a SIP soft phone, remotely from the ShoreTel HQ site, over a site to site VPN tunnel.    The VPN tunnel is between a CISCO ASA and a SonicWall TZ250.  We note that 90% of the SIP issues we see having nothing to do with the configuration of the ShoreTel equipment and everything to do with the network devices, routers, switches and firewalls that are part of the SIP solution.  Small business solutions, for example,  tend to bring the SIP trunks into the phone system over the same connection they bring in their internet connection.  This means the SIP trunk is passing through the firewall, another most likely candidate for inducing a SIP failure.

This tech tip walks you through a successful SIP registration of a remote soft phone.  In our next tech tip, we will walk you through configuring a SIP trunk through a SonicWall and then look at fixing some broken SIP connections!

ShoreTel SIP Trunk Configuration – Version 14 update Part 1

Our older posts on this subject are getting a bit dated and an update is long over due.   ShoreTel has been using a version of SIP since day one.  We say a version of SIP because at the formation of ShoreTel, SIP standards had not yet been solidified.   ShoreTel SIP, therefor, was not interoperable nor did it need to be.   Our fist experience with ShoreTel was Version 3.1  back in 2001!    At that time, ShoreTel did not yet support IP phones, but ShoreTel SIP was and continues to be the call setup protocol used between ShoreGear switches.

Though ShoreTel introduced IP Phones in Version 4 with the private labeling of Polycom handsets, ShoreTel SIP for desktop devices did not become available until Version 8.   This early version of the SIP protocol required you to configure the first version of the IP8000 as a SIP trunk not a SIP Extension.  It was a step in the right direction, but it was not until V13 that we got a version that was more compatible with other SIP devices and not until Version 14 before we reached PRI parity on SIP trunks with the introduction of media termination points.

SIP in general is relatively simple to configure and mirrors most of the steps you take to implement a normal TDM Trunk Group.   The devil, however is in the details!  IP profiles, NAT, firewall, Digest Authentication and Carrier particulars need to be mapped out.   Generally, a Session Border Controller is a best practice for a SIP deployment.  Where does your network end and the carrier network begin?  Well, that is the single most important benefit of a SBC!  Additionally, the SBC can be the point at which we “normalize” SIP messages and translate between any dialectic differences between SIP implementations.

Generally, in ShoreTel you will setup your underlying resources by allocating ShoreGear switch ports, media  termination points, profiles, timers and DTMF handling configurations.  The  Creation of a SIP trunk group is very similar to the configuration of a PRI trunk group and the same options will need to be specified as to the use of this group.   Then SIP trunks are added to the SIP trunk group, the actual circuits on which phone calls will take place.   If the trunk group is to support tandem trunking and is connecting to another system as a tie line, the off premise extensions and digit translation options will also need to be configured.

The first video will walk through the configuration of a TIE trunk between two ShoreTel systems.  One system will use the TIE trunk to place all outbound PSTN phone calls through the other ShoreTel system.  Both systems will use the Trunk Group for extension to extension calling, with one system having extensions in the range of 200-299 and the other having extension in the 300-399 range.   We will walk through the basic configuration and then also take a look at wireshark captures to illustrate the SIP call setup message exchange.    In the second part of this update, we will the route calls out a SIP trunk to a SIP carrier for PSTN calls, using several different SBC’s.

Contact DrVoIP@DrVoIP.com to have us setup this up for you!  We offer flat rate configurations!

 

SIP as a Disaster Recovery Strategy? EtherSpeak answers the call!

As a standard deployment practice, we at DrVoIP implement SIP trunks as a “fail over” on every system we install.   As reliable as your PRI circuit has been, they do fail from time to time!  In fact, we recently lost 27 PRI’s at a major San Diego Hospital when a carrier ( who’s name will remain anonymous) experienced a fiber cut taking out most of their clients in the region!  Stuff happens!   Having an alternative circuit in place is not only a wise step to take, but by using SIP,  can be very economical.     We find that most carriers offer a “circuit down” capability that  can automatically reroute incoming calls to another number if they detect a “D” channel failure, a sure sign that your PRI is out of service.   If you have not yet done so,  you should get with your carrier and set this up as many carriers require that this feature be programmed into their central office switches and is not something that can be easily done on demand.   This should be configured in advance of a real system failure, and always on line, ready for use!

EtherSpeak Inc,  always the innovator and at this point a “senior citizen”  in the SIP service community,  is now offering an intriguing disaster recovery product free of initial charge!    Throughout June, you can add a three channel SIP trunk, 100 minutes of talk time and a Virtual DID number for absolutely no cost!   EtherSpeak was among the first providers to interconnect with ShoreTel systems, for example, without the need for a Boarder Controller.   They simply built a private IP-sec site to site  tunnel, from your system to their soft-switch.  This is a huge savings in both money and aggravation!    This is an extraordinary value and eliminates any excuse for not implementing a disaster recovery plan to assure telephone calling services in the event your PRI goes down!   Simply work with your carrier to have your main telephone number call forwarded to the virtual DID number provided by EtherSpeak and callers will never know your PRI failed!   Calls will ring in over the SIP trunk and be handled by the ShoreTel like any normal phone call.   Clearly, you only have three circuits, but EtherSpeak will be happy to increase the number of circuits.  In fact, you might find that SIP is really all you need and you might just migrate over to EtherSpeak as your main provider!

The adoption rate of SIP technology,  by both large and small enterprises, is staggering!  Once the domain of only the true geek,  today SIP is a very reliable, cost effective and  viable alternative to traditional copper circuits.    The EtherSpeak disaster recovery package is not only a prudent business continuity move,  but it will allow you to get comfortable with SIP.   Remember a PRI commits you to 23 paths regardless of how many you actually need.  If you need 30 talk paths, the only way to get that capacity with PRI is to contract for a second 23 talk path circuit!  SIP enables you to purchase exactly what you need and you may even be able to “burst” upwards if special circumstances require more talk paths!   Truth be told, your carrier is most likely delivering your PRI over a SIP trunk anyway!  As the cost of maintaining copper lines has continued to escalate, carriers have been slowly migrating over to soft switches that bring SIP trunks to the customer premise.  Using an Integrated Access Device or IAD,  the SIP trunk is then  converted back to a PRI for hand off to your PBX.    If you have a ShoreTel T1/PRI switch you can re-purpose that switch by converting it for use as a DSP resource to support your SIP trunks, so your original equipment investment is protected.

We are not sure what you have to lose?   Free installation, no additional equipment, free virtual number and 100 free minutes of talk time?    Let the boss know you are thinking and taking actions in the best interest of protecting the business and get with the good folks at EtherSpeak by clicking here and taking advantage of this free offer!

ShoreTel Version 14.2 is “Virtually there”!

We have previously argued that ShoreTel should shed the hardware business and focus on software development only.  Just our opinion and personal hangup!  We believe that unless you have the Market Capitalization of an Apple, it is hard to walk both sides of the street and do both Hardware and Software!   Even Microsoft, does only Software!     Well ShoreTel may in fact be moving to Software only through the introduction of a family of “virtual” machine offerings.   Though versions prior to Version 14.1 offered some level of Server virtualization,  ShoreTel deployments would still require lots of those “Orange” ShoreGear switches.

On January 28th ShoreTel will begin to ship the first release of Version 14.2 and all components of the ShoreTel architecture will be virtualized!   This means that you don’t need those “Orange” boxes unless you are connecting to analog or digital trunk lines!   ShoreTel Switches including Conferencing servers will be available as OVA files for VMware deployments.    ShoreTel will begin to offer  a virtual phone switch, a virtual service appliance and a new family of virtual SIP Switches with complete PRI parity.  The ShoreTel compatible Ingate SIParator will also be available as a Virtual Session Border Controller.   Licensing can be significantly reduced to a phone or trunk license, now how kool is that?

The ShoreTel virtual phone switch will support between 250 and 1000 phones based on calculated VM resources.  The virtual phone switch will will support all ShoreTel features including backup automated attendant, make-me-conferences, hunt groups, bridged call appearances and extension monitoring.  Pricing is estimated at 8-15% below the cost of another “Orange” box and you can mix and match virtual and real boxes! The virtual SIP trunk switch is estimated to be some 50% below “Orange” box costs!  The virtual service appliance will offer IM and Web conferencing from 50-200 simultaneous sessions.  Instant Messaging is now without charge from ShoreTel when implemented on a virtual server,  just your usual VMware hardware costs!

We consider this the strongest move that ShoreTel has made in its product line, since it moved from analog phones to SIP handsets!  Though ShoreTel is following the examples of others like CISCO Version10, we see this a the right next step in the process for ShoreTel product development.   With the enterprise world solidly focused on virtualization and the rapid but steady migration from TDM to SIP, a Virtualized ShoreTel is an essential element of a successful business continuity and disaster recovery program.    ShoreTel is starting to look an awful lot like a pure software company and we think that is not only “brilliantly simple”, but very smart.

– DrVoIP

Compare ShoreTel and 3CX – Part 1 License Strategy

The trend in the Unified Communications industry is to charge a “per seat” license for access to VoIP Business Phone Solutions.  In large part a legacy “flat tax”  from the old TDM world, phone system suppliers continue to license based on the number of users that the system supports.   Microsoft, ShoreTel, Avaya and CISCO all seem to have software licensing based on the number of users.  Some licensing strategies become more complex as features and services are added.   ShoreTel has by the simplest licensing strategy of the major suppliers, but they do count the number of users as the base software license cost.   Additional license fees are assessed for “Professional” Communicators or Communicators that access Workgroup functionality for Agents and Supervisors.   It is all rooted, however, in the number of users the system will be hosting.

If we consider a simple 100 extension solution, ShoreTel will have a $20K software license fee before you purchase any of the required VoIP hardware.  Basically, you are paying $200 per user for an Extension and Voice Mailbox.  After you purchase your software license, you will still need to purchase handsets, gateways and servers! Microsoft, CISCO and Avaya, though significantly more complex in their licensing strategies, start from the same basic “per seat” model.    In fact, if you look across the  business communications landscape  all suppliers have to offer basically the same set of components   Yes, all automobiles are different,  but they generally have four wheels, a steering,  seats, dashboards and a power source!

Clearly this has a significant impact on your ongoing cost of support.    For reasons that I have yet to figure out, “technical support” is somehow a function of your system acquisition cost?   The industry trend is in the range of 10-20% of your total system cost, including software licenses, will then be used to calculate your ongoing cost for software insurance and technical support.    I know there are smarter people than I that have been working this out,  but I just cant see the relationship between the cost of equipment and the cost to service that equipment?   I get “making money”, but I don’t’ see the value relationship in punishing customers for buying more equipment?

Is there another model out there?  Are we forever bound to the “per seat” license model?  In fact there is another model out there!   Enter low profile, high performance, global provider of  Unified Communications, 3CX!    These guys amaze me and I think they are harbingers of how the communications industry will work as we move deeper into the 21st century.  Now hear this, they do NOT charge a “per seat” license!   Contrary to the industry trend, they also include most functionality that the other players generally “option”.  Full chat or IM services, presence, fax server, call center and mobility services, soft-phones, iPhone and Android applications are included with no “per seat” cost!   Then how do they bill for their software?   Simple.  They license based on “simultaneous connections”.    Clearly, if you have a 100 user system and a PRI for PSTN connectivity, all your users are not on the phone at the same time.   Why not pay only for the maximum number of live phone conversations that you project for your business?   3CX pricing ranges from 4 to 1024 simultaneous connections and that can cover both large and small deployments.  Lets assume that same 100 extension system and instead of $20K or $200 a user, you paid $5K to support 64 simultaneous phone calls?

This is not some small upstart trying to buy market share.  This company 3CX,  a certified  Microsoft Developer,  has been deploying on a global basis since 2006.   They have a fully formed, Unified Communications solution that can match the established players,  feature for feature.   They will not compete with ShoreTel and CISCO in the 1000 seat market, but in the larger 25-250 seat multi site segment, they are a serious contender.   Technical support is offered on a global basis, is astonishingly effective and uses a combination of traditional TAC center live remote support but leverages alternatives like video wiki, community, email and chat support. ( In future blogs, we will do the architecture comparison thing).

I know I am alone in the belief that you can not be both a hardware company and a software company!  I think you have to pick one side of the street and really do it well to create a defensible market share and posture for growth!   My Son argues that that is a ridiculous position, “just look at Apple they do both and have the best products on the market”?   Not withstanding Microsoft, I think that the issue of comparative size plays a key role in enabling a company to pursue both.    If you are a comparatively  smaller player (Market Cap: SHOR  $247M, APPL  $611B, CSCO 100B) I would argue that it is more important that you figure out if you are a hardware company or a software company!

I would identify 3CX as a software company that you need to pay very close attention to!

contact DrVoIP@DrVoIP.com

ShoreTel SIP, Mobility Router & the Firewall (Part 1)

This is not a SIP tutorial,  only an overview on the issues that impact remote SIP phones on any iPBX.  When you set up a SIP call between two end points, there are upwards of four “holes” that might need to be punched in your firewall for the phone call to work properly.  Clearly, there is the entire process of registering a remote phone and the process of setting up a phone.  Once these events have been negotiated, we  then have the issue of the media stream between the two phones.  Generally the registration and call setup are taking place through TCP/UDP port 5060 on a public IP address that terminates on your firewall.   Generally, your Firewall will have these ports forwarded to your SIP Proxy or iPBX which lives on your internal private network.   (Take note:  Public and Private IP, we will talk more about that later).

Once the call is setup, there is a “mouth to ear” path setup for each leg of the call.  These “dial peers” are really just media streams.  These media streams take place over UDP ports using RTP protocol, one for each “mouth to ear” stream, so that is two more ports open on the firewall.   Each of the RTP streams has a UDP cRTP protocol port requirement as well, so we need to open two more ports your firewall.  So to summarize, you will have TCP/UDP port 5060 open on your Firewall all the time, and four UDP ports open for each active phone call.  Your firewall is starting to look like a sponge?

You don’t have to be a network security guru to figure out this strategy has some obvious challenges!   12 year old Elementary school kids run port scanners looking for open 5060 and then run Sipvicious  in hopes of registering a rouge phone.   Through in the fact that your ISP may or may not block 5060, and or refuse to use the same ports and you have the making of a SIP nightmare!  SIP was never expected to traverse from public to private IP addresses either!  So we have SIP savvy firewalls and border controllers to help us out.  These devices, among other features they provide, can police ports, opening and closing them as required when a legitimate connection is required between an inside phone and an outside phone.   They also translate between the public IP address and the internal private address keeping an internal scratch list of who is using what, closing ports when done to increase security.

Is there a better way?  What if we could create a secure “tunneling strategy”?   Not a VPN,  but a strategy for getting the SIP call control and Media Stream to move through a single firewall port?   Sound like a winner?   This SIP Proxy Tunnel can combine all SIP (signaling) and RTP (media) VoIP Packets from one location (typically a remote office) and deliver them to and from another location (typically the PBX Server) using a custom TCP protocol.  This simple concept allows us to exploit the SIP Proxy Tunnel to overcome difficult situations, or to simplify a network scenario.

The SIP Proxy Tunnel can be used for the following reasons:

Resolve issues of NAT Traversal at both the remote and the PBX location
Simplify Firewall configuration at both the remote and the PBX location
Overcome difficulties with ISPs that block VoIP Traffic based on port numbers
Allows VoIP-over-WiFi in some restricted locations, such as Hotel rooms
“Fixes” Firewalls that cannot handle VoIP traffic correctly or which are very difficult or problematic to configure correctly, such as:
Microsoft ISA Server
SonicWall
What if “remote” also means a mobile phone?   When you have a user who is roaming around with a SIP soft phone extension on their cell phone,  we have no idea what IP address they will be connecting from!   The answer (excuse the pun) is an android or iPhone application  that enables you to create the tunnel from you mobile phone, bring up your iPBX extension and move your desk outside, down the hall or across the globe.  At the end of the day this would be a true Mobility router.   Last year ShoreTel acquired Agito Networks and obtained this very same technology and it is an outstanding solution. The ShoreTel Mobility Router and Roam Anywhere cell phone client can do all this SIP magic and even move your call seamlessly between WiFI and Cellular while your walking out to the parking lot.  How great is that?

SIP firmware for ShoreTel handsets?

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!