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! https://youtu.be/Pgk-RtJfX-0