Options for getting T.120 running through a firewall.

I should first point out that my interest in NetMeeting is strictly with
data conferencing. This includes application sharing/collaboration, shared
whiteboarding, and file transfer. I have very little interest in the video
and audio capabilities in NetMeeting (at this time). So my work to date with
firewalls has been in support of T.120.

There are few options available here. The T.120 protocol has no notion of a
proxy. Some future version of it might but I haven't kept up with it for
awhile.

You also have to think about two different scenarios when dealing with
firewalls. First, how do you get outside of your firewall? Second, who will
you call? Is your destination party behind another firewall? In the case of
Ford and suppliers both participants are behind firewalls.

So, how to you get by that firewall? One way is to configure the firewall to
allow the T.120 port through (I forget the port number at the moment). The
biggest problem here is with your firewall or security admin. They might not
let you connect to just any system. But if they do then you are almost done.

Next problem is with DNS. Many firewall admins don't allow DNS queries to go
out so you are stuck with numeric IP addresses. (Note: this isn't a problem
with your web browser because HTTP has support for an application proxy)

Another option is to use a winsock proxy (I've labeled this a transparent
proxy since the application doesn't know it is being proxied but that label
may be mis-applied). I've tried both MS-Proxy's winsock proxy and the
Aventail AutoSocks. These products proxy the actual winsock calls, tunneling
the T.120 protocol until it hits a proxy server in the DMZ which unwraps it
and sends the stream on outside your network. It pretty much feels like you
are connected to the Internet (even DNS lookups are handled).

I'm sure both products work fine (and there may be others which I am not
aware of) but when I used AutoSocks it didn't support the ILS server lookups
(but that wasn't a problem for me since I didn't plan on using it anyway and
I suspect they've fixed this problem my now). I have a slight preference
towards the Aventail product since it uses any version 5 socks proxy server
(I tested mine with Wingate) and also support UNIX clients (btw: there are
UNIX versions of NetMeeting available from SUN and SGI).

The big drawback here is that every desktop system has to have an extra
piece of code running on it. So you take a hit on cost to buy and distribute
the software.

Now, once you've traversed your firewall where do you want to go? If the
person you are calling is directly accessible on the Internet then you're
done, enjoy your NetMeeting.

If, however, your destination is behind yet another firewall what do you do?
As I said earlier, T.120 has no notion of a proxy and it certainly doesn't
have any support for dynamically finding a path to another party (like,
perhaps, H.323 does with gatekeepers and gateways).

You're only solution at this point is a conference server. Think of a
conference server as a headless NetMeeting client. It's sole purpose in life
it to supply a "meet-me" type of bridge for data conferences. This is
analogous to an audio or video bridge where all of the participants in a
conference call the bridge to form a multipoint conference (I should point
out that NetMeeting data conferences are inherently multipoint without the
need for a conference server).

The nice thing about a conference server is that it makes firewall admins
happy. You now only poke one small hole through the firewall to a known
conference server where everyone meets. It also deals very well with the
problem of multiple participants sitting behind firewalls.

So where does one find a conference server? Well, if you are so inclined you
can deploy one yourself. Check http://www.databeam.com or
http://www.wpine.com to name just two. Commercial data conferencing services
are now starting to appear on the market. Check with your isp.

The approach we plan on taking is to allow T.120 connections through the
firewall to a limited number of conference servers.

Larry

-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to