Sometimes VOIP w/SIP works with ISA
...other times it doesn't. The determination depends completely upon who wrote the software for the VOIP system.
System types that work include those that come with their own router and those that encapsulate SIP. For example I use Lingo. Lingo comes with its own router and uses regular phones. This router ends up as the only device with an IP on your network and it handles all of the SIP stuff internally. It's managed from Lingo's website. On my network I put the device on the outside because I don't know enough about the internal workings of the router to trust it. On the flip side, I know someone else that put it on the inside of the network for the exact same reason. The point is because it doesn't ask ISA to handle SIP for it, it works.
I also recently worked on getting a SIP CRM application through ISA. This app by five9.com has two java apps that have to work together. One app handles the phone call and the other app handles the CRM and pops up the contact info when a call comes in. It's a slick distributed call center. It worked with ISA because the SIP was actually being handled on the host end with the results being passed through a java client to the end user. So what on the surface appeared to be a SIP VOIP application was really just 2 java apps and an SSL website.
The difficult part of implementing these solutions for clients is working your way through the documentation provided by the vendor. Here's what we got from five9 when we asked what ports were required:
1) IP (local machine)/ Port 8443 (HTTPS)
2) IP 188.8.131.52 / Port 80 (HTTP)
3) Port 5060 UDP (SIP)
4) Port 8000 UDP (RTP)
5) Port 8001 UDP (RTCP)
6) Port 3478 UDP (STUN)
6) Allow incoming TCP traffic from IP addresses ranges
184.108.40.206 - 220.127.116.11
18.104.22.168 - 22.214.171.124
126.96.36.199 - 188.8.131.52
If you have personal firewall installed on the PC, please also make sure the following ports are opened for the loopback (127.0.0.1)
1) Port 1196
2) Port 1197
Outgoing traffic to UDP Port 5060.
Full access to these URL:
All incoming traffic to these IP address:
All Incoming traffic to this IP range:
184.108.40.206 to 220.127.116.11
My reaction to any request that has this many open port requirements is no and that’s what I would have advised my client. In this case the situation came to me after the money had already been spent.
Now don't get me wrong I'd rather have vendors fess up than deny that they require anything out of the ordinary. I just get a little bent when a single app requires many ports.
The first thing I did was load up the application without making any ISA changes, I then watched the logs for what happened when I ran the app. Next I added 8443 to the SSL range, then I ran the app and let the logs tell me what happened. The next thing I did was wonder if I had the right set of instructions from the vendor because what I saw in the logs had very little in common with the instructions I received.
Vendors take note: in this case the app is very cool and it works. But at this time it appears you are going to loose the customer because you dragged them through a month of unnecessary ugliness that finally resulted in them giving up on your support and hiring outside help at their own expense. Vendors if you don’t know ISA, then you’d better contract with someone who does or you’ll probably loose the client. If you are to promise full configuration services then you’d better make sure you can deliver.
As it happens all we needed to do to get this VOIP app to work through ISA was make sure that the java apps could get through ISA using direct access, add to our tunnel port range and make sure everyone using the app was running the latest version of the firewall client.
The moral of the story is that you can’t trust vendor instructions when it comes to ISA. Do your own DD (due diligence) and use the ISA logs to determine what steps you need to take. The firewall client is your friend. It’ll handle a lot of port availability issues for your clients on the fly without admin intervention.