BY LAURA GUEVIN
Managing Editor, INTERNET TELEPHONY

Scaling The Wall: VoIP Firewall Dilemmas And Solutions

The main objective of this column is to bring to light issues I feel are important in the world of Voice over IP and next-gen communications. It's always encouraging when I get feedback on one of my columns, and my last piece -- in which I highlighted some inherent problems with using VoIP from behind a firewall -- produced the most responses I've seen yet. I thought I'd share some of them in this space.

One of the first companies I heard from is HearMe, which recently merged with AudioTalk. Their small Java applet allows users to conduct PC-to-PC chats for personal calls as well as business conferencing. Customers can also add click-to-talk buttons to their Web sites for PC-to-phone applications like e-commerce and customer service. And, the service is "firewall friendly," meaning that if users are behind a firewall, they indicate that when they set up the chat. While the service normally uses the session initiation protocol (SIP) to send traffic, when users are behind a firewall the applet uses HTTP tunneling to route packets through port 80, so they appear as Web traffic. A great way around the firewall problem, but not a solution for people using different software clients or services to chat.

I tried a one-on-one chat using HearMe from behind my office firewall and it worked perfectly -- in fact, the quality was exceptionally good. AudioTalk requires users to press the Ctrl button on their keyboards while they are speaking, and even when my colleague and I were talking at the same time we were able to hear each other, true duplex audio.

As for the ultimate issue of getting through the existing firewalls in my life, there's still no permanent solution. Our TMCnet.com technology director offered a fix for my home firewall, which is part of Red Hat Linux. Apparently, the firewall may be configured to open and close TCP and UDP ports on the fly. Unfortunately, I have an old version of Red Hat at home that needs to be updated so this feature is not available, but this will obviously be a priority once the upgrade is complete.

READERS RESPOND
The majority of the e-mails I received were from network administrators and end users who had experienced similar problems to the ones I had. I have included some of their queries below, and I'd like to open up this discussion to the software developers and interoperability leaders in this industry. Please e-mail me any solutions you may have to the current problems with using VoIP software over a firewall.

I read your "The VoIP Firewall Paradox" recalling my experience with VoIP in a corporate network. A few years ago, I was an engineer working with various VoIP products from some vendors like Micom (now part of Nortel), Selsius (now part of Cisco), and one other (TouchWave if I remember correctly -- this one also bought by a big company too). [TouchWave was bought by Ericsson. Ed.]

Unfortunately, some of my colleague engineers were working with Micom VoIP products (one of the VoIP forerunners with good quality of sound) and didn't know this problem exists. I later found out there were not many engineers back then who knew why (I believe even the manufacturer didn't know).

Now this problem is well known among engineers and good product manuals warn the customers about how to deal with it. I recently found out commercially available publications like Cisco books have explanations.

Fortunately, when I started to install VoIP products for corporate customers, I was familiar with randomly assigned UDP ports and knew what caused the problem with firewalls. And thank God, the manufacturers prepared a list of those UDP ports soon after.

VoIP products with quality came into market about three years ago. That's the time we didn't know much about the problem. Two years ago, there came a lot of VoIP products and we started to notice the problem. One year ago, it was well known among industry. But I don't think someone outside knows much.

While I was dealing with VoIP products, I noticed most of my customers were network conscious (having a good knowledge of the entire network). However, some newly formed companies like ISPs didn't know much. From my own experience, there's too much you can't control with ISP-related networks. And simply put, individual users like you may not fully take advantage of VoIP technology yet.

(Once I was installing an Internet telephony add-in card in a PC, and it didn't work. I contacted the manufacturer, and they couldn't make it work. I simply assumed hardware incompatibility was the problem and gave up installation.)

Still, VoIP technology is refined and getting better. And there's always people working to solve the problems. They're the trailblazers. Just give them time and have a good wide open mind to find the answer.

Kazuhiro Takahashi
CCDA, MCSE, MCP+Internet

We read with interest the July 6 story by Laura Guevin about the VoIP firewall paradox. Since visitalk.com offers both audio and video calling over the Internet, we are very interested in this issue as it relates to expanding our service to the office environment.

We believe that the industry -- VoIP infrastructure and service providers, camera vendors, networking infrastructure providers, software providers, and others who have an interest -- should work together to develop industry-standard solutions that can benefit users and make VoIP a reality for the enterprise. We are willing to provide technical and other resources to help the industry, but all players ideally should participate to make a solution happen.

Anne Price, Director Public Relations
visitalk.com
PCN 2001111-32108

Read your column on VoIP and firewalls with fascination. This is just the problem I have been grappling with for the past year! Let me tell you about me: I am not at all a techie. I am just an ordinary guy running a translation company in Chicago and trying to solve my international communication problems. But I have been forced into all kinds of technical somersaults trying to make what is basically a still very immature technology or rather, set of technologies, work.

The firewall problem is one that, as far as I can see, can be solved. However, and this is the maddening thing, nobody really wants to solve it apart from frustrated consumers like you and I. I have been running Quicknet's PCI Internet PhoneJACK card. It's very good. I have been trying to connect it to Net.Caller 2.0 (a bit of VocalTec software repackaged by Access Power), as Access Power offers $20 a month unmetered calling from the US to my homeland, the UK. Here I had two problems: First, the firewall (I was running a network off a hub and router to a DSL connection) and secondly, getting the card to work with Net.Caller. I have solved neither problem. Instead, I got round each of them.

The firewall thing: I changed to cable instead of DSL, as AT&T cable services allow me up to five IP addresses. I got rid of the router. There have been suggestions that Cisco routers can be programmed to allow VoIP calls through, the extent of this traffic being determined by the available bandwidth, but I didn't try it. Why? Because it is too time-consuming for me, a non-techie, to mess with all that stuff.

Compatibility with Net.Caller 2.0: I mention this because it gives a good illustration of how people are not really interested in solving the technical problems in this area, even though the solution is probably easily within reach. Quicknet told me their card was compatible with this software. I bought the card (two of them in fact). Turns out, it is NOT compatible. It used to be, but they introduced a modification (nobody knows which) and now it no longer works with it. So, I use Net2Phone instead. If I want free calling to Europe, I just use Net.Caller with my ordinary sound card. I told Quicknet about this. They go: "OK, so?" I said, well if you could get your card to work with Net.Caller and you could recommend a router that works with the combination, you would have a goldmine. If you made it even slightly user-friendly, people would desert even ordinary telcos by the millions. They go: "OK, so?" In other words, NOT INTERESTED. The reaction from Access Power was the same. Go figure!

Another thing: VoIP is so unstable and demanding of resources, the best thing is not to put it on the same computer as everything else. The pragmatic solution is to buy a cheap computer at onsale.com or somewhere else and run it next to your main one. Use the second, cheap computer basically as a computerized telephone. I have found that this works really well. If it crashes, it doesn't affect all your other work.

Jon Berger

Your column is an example of what many of us have experienced when embracing VoIP. We attempted to use VoIP from the desktop to the Internet. However, our firewall would always hinder the communications. We went through five different vendors. None of them are fully capable of supporting VoIP. This list includes Checkpoint, Cisco, 3Com, etc. Even if they say they support H.323, it is only partial. We were given many excuses as to why it did not fully work.

As I read articles like yours, I laugh. It is funny to read about people going through what we went through. Whenever I read an article about the greatness of VoIP I laugh again, because I know that it will never take hold until the end users can really use it. 

PBX-to-PBX VoIP is easy. That is not what will take VoIP to the next level. VoIP will flounder as a technology until a new version of H.323 is released, or a new technology replaces it. Perhaps IPv6 will offer alternatives. Until then, companies will get burned and turn away, especially with lower long-distance rates being offered.

Craig Andreas

I am unfortunately still not convinced about the effect on transmission speeds by using UDP instead of TCP. The reason is that any application requires complete data to function properly. So, even if UDP does not provide flow control and guaranteed delivery, in the upper layers of the protocol stack -- maybe in the application layer, there has to exist some mechanism to ensure guaranteed delivery of data, by repeated transmission if necessary. So, that way, whatever benefits you may get by using UDP in the transport layer will be lost in the delivery mechanisms of the application itself.

To this you may reply that in many streaming data applications, there is always some data that is ignored/discarded to provide a reasonable throughput and quality. But, this discard is performed at the application layer and not at the transport or network layer, for these have no means to decide about the QoS required.

So, at the end, the question remains -- how do lack of flow control and guaranteed delivery mechanisms in UDP help speed up throughput over TCP, keeping in mind that data loss has to be minimized, and that this decision is in the application layer rather the transport layer?

As for this query, I asked around in the office. Those with knowledge of this issue say that UDP is used when the underlying transmission media/fabric provides for high speeds at extremely low error rates. For example, if the switching and transmission fabric is ATM -- which provides for error rates as low as one in a million cells, then it makes sense to use UDP. However, the query still remains unsolved because most VoIP applications have to be designed with the idea of using the Net for packet delivery over large distances, and ATM plays a minor role there.

Sandeep Banerjee
Daewoo Telecom Ltd, India R & D Centre
Gurgaon, India

Laura Guevin welcomes your comments at lguevin@tmcnet.com.