[GnomeMeeting-list] Recipe for Netmeeting, NAT success

[Marc Williams <marcw onlymooo com>]

After much pulling of hair and gnashing of teeth, I finally have what
appears to be a successful and working LAN, NAT, Gatekeeper (gk),
Gnomemeeting (GM), and Netmeeting (NM) arrangement.  Please don't ask me
about the specifics of how to get any of these individual components
working.  Do what I did and read the manuals, FAQs, mailing lists, etc. 
Besides, I'm no expert.  An expert wouldn't have taken this long to get
them all working.  :)  If this doesn't work for you, too bad.  It works
for me, so I thought I'd share it in case it helps someone else.  Much
of what is covered here is redundant because it is covered elsewhere
(although I don't recall seeing UDP 1719 anywhere else).  Well, that may
be but there's probably not too many places that have it all under one
roof.  If you've got questions about the whole setup, fire away.  

Here is my situation:
	Home LAN
		6 Windows and 2 Linux clients
		1 Linux server
	Broadband Internet (~1.5Mbs down)
	Nexland Router (h.323 compatible)
	Generic switch

Here is what I wanted to be able to do:
1) Have any family member be able to call any other any family member
regardless of whether they used GM or NM.
2) Have any family member call any other GM or NM user on the internet.
3) Have any family member be able to _receive_ NM or GM calls from the
internet.

What follows is how I did it.  

1) I made sure that all my GM and NM clients could initiate and receive
LAN and internet calls directly and individually.  This meant opening up
certain ports on the router and directing them to the appropriate
clients as I tested them one by one.  The GM FAQ does a good job of
describing the GM side of things.  Google does a good job for NM.  :)

2) I built a gk and installed it on my server.  The one I built was
Openh323gk as suggested in the GM FAQ.  I tested the gk using LAN
clients first.  This way, I wouldn't have to worry about which ports to
have open, etc.  Once I was satisfied that the gk worked on the LAN, I
had some friends help me test operation between LAN clients and internet
clients.  This is where you have to make sure the right ports are open
and pointing to the right places.  See below.

3) All GM and NM clients, both LAN and internet that want to participate
in h.323 calls, must register to the gk.

4) The ports I opened up on the router all point to the server:
	TCP 1718-1731 (this might just need to be 1720)
	TCP 30000-30020
	UDP 5000-5010
	UDP 1719-1720 (this might just need to be 1719)
(this last one took awhile to find)

5) The gnugk.ini file I'm using (I don't care about t.120):

[Gatekeeper::Main]
Fourtytwo=42

[RoutedMode]
GKRouted=1
AcceptUnregisteredCalls=1
SupportNATedEndpoints=1
H245PortRange=30000-30010
Q931PortRange=30011-30020

[RasSvr::ARQFeatures]
CallUnregisteredEndpoints=1

[Proxy]
Enable=1
RTPPortRange=5000-5010

[GkStatus::Auth]
rule=allow

[Gatekeeper::Auth]
default=allow



I want to stress that this setup is _not_ the definitive or last word on
h.323 and gatekeepers.  Far from it.  I'm still learning more and more
each day.  I will likely be modifying things as I go.  But this seems to
work well for now in the limited testing I've done.

Notes:
I am using 2.0 of the gnugk.  I haven't quite figured out the syntax of
the CVS version of gnugk.ini 

There seems to be a bug in gnugk that prevents video from being sent
when a NM client calls a GM client.  All other combinations seem to
work.

Narrowband NM users will definitely need the instcodec.exe file
available form the GM FAQ.  This has nothing to do with the rest of this
note but I thought I'd throw it in anyway.  :)

I have to do some more testing to see about using "@" when calling
unregistered clients.

My gnugk.ini is pretty much wide open for now.  I think almost anyone
could register.  This is probably a security risk that I'll be
eventually tightening up.