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
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?

ShoreTel SIP Trunks a Snap with Ingate SIParator!

I don’t think your average business professional wakes up in the morning and says “Gee, I need some SIP”!   They do however ask questions like how do we get an Area Code from New York to appear on our System in San Diego?  Do I really have to buy 23 channels of voice on a PRI when I only use about 12 channels max?  Can’t we just “burst” up to 23 or 50 channels when we need them?   Can we have our phone calls re-routed to our branch office, if something happens to our main location?   These are market drivers that are encouraging businesses of all sizes to consider implementing SIP trunks.

What is a SIP trunk?  If you mention a T1 to a telephone guy,  he will think you are looking for a channelized voice path to the telephone company.  Ask an IT guy the same question and he will think you are talking about a 1.5MB connection to the internet!   Now bring an integrated T1 into the conversation and things get a bit more interesting.  Ask about a SIP trunk and you may get both of them scratching there heads.  If you are not working SIP trunk integration today, you most certainly will be doing so in the very near future!

To over simplify for purposes of discussion, a SIP trunk brings “dial tone” to your phone system over an Internet connection.    In most PBX systems, the connection to the phone company has been through a traditional TDM interface.  In a ShoreTel PBX, for example, you would come from the phone company provided “smart jack” to an SGT1K.  You would then use the Shoreware Director to configure the parameters that make a vanilla T1 a Primary Rate interface  like defining  the CO Switch type  (e.g. NI2, ESS5, DMS100), framing and signaling.

In a traditional TDM deployment, the separation of the PBX system from the Telephone Company is clear and unambiguous.  In fact, you often trouble shoot analog telephone  lines by going to the 66 punch down block, known in the industry as the “D Mark”  and remove the bridging clips that connect the phone company with the customers phone equipment.    In this way you can easily determine which side of the block has the problem.   With SIP there si a new challenge:  how do you separate the customer premise equipment from the telephone company provided network connection?    Where does your network end and the telephone companies network begin?

As we add SIP trunks to our network, the border of our network can easily disappear.   For this reason, we need to introduce a “enterprise edge border controller”!  The Border Controller is an essential element in provisioning a SIP trunk and is generally a dedicated appliance that provides a range of functionality that includes  NAT traversal, Security, Port management, Normalization, Call routing  and most importantly it acts as a “D mark” for your network, setting up a B2BUA between your iPBX and  your border controller; and between your border controller and your ITSP.    In this way you can think of your Border Controller as logical equivalent to a a 66 Block!

Why not use a Firewall to manage SP?   Clearly, if you are connecting your phone system to the Internet, there needs to be a “firewall” function.   A SIP RTP media stream is basically your phone conversation and it will take place over a 1000 different firewall ports.  Clearly nobody is going to open 1000 ports in a firewall or you might as well not have a firewall!  So a key functional requirement  for a  SIP trunk implementation  is the ability to track legitimate requests to open a port and then to close it when the session is over.   Firewalls that are “SIP capable” have this ability and are the minimum requirement for establishing SIP trunks on a phone system.

There are other equally critical functions that you must have in place for SIP trunking that exceed the ability of a Firewall and are more appropriately handled by a Border Controller.   “Normalization” for example, enables the appliance to provide language translation.    Like English or any other language, SIP sessions have  “dialects” and ShoreTel SIP might be different than SIP from Level3, Net Solutions or Paetec.    The Border Controller can mediate these difference enabling interoperability between these systems.

Two of the most widely deployed Border Controllers in the market are the CISCO CUBE  and the Ingate SIParator.  Both are excellent solutions, offering the required functionality to securely enable SIP trunking, including NAT traversal, Normalization and Security.    If you are integrating SIP Trunks with a ShoreTel iPBX, you will be very pleased with the Ingate “SIPParator” solution.  The Ingate solution  “Start-up” tool that is designed to get your up and running as quickly and as painlessly as possible.   If you  know the basic configuration parameters of your  ShoreTel and ITSP, the start up tool is the shortest possible path to your first SIP phone call from a ShoreTel iPBX.  Using the start-up tool you can quickly configure the basics, sanity test the basic configuration, upload it and then use  the Ingate  Web based Administration portal can then be used to further your configuration, logging,  reporting, monitoring and trouble shooting.    The SIParator  has been tested with a long list of SIP carriers and has many of the ShoreTel required parameters per-configured.    The support team at Ingate is both knowledgeable, patient and committed to making your ShoreTel deployment a success.

It is time to start integrating SIP solutions