[GnomeMeeting-list] gatekeeper considerations

[Joachim Keltsch <joachim keltsch net>]

Hello again,

I now played around with the gk a bit more and configured it to run as a
proxy. I use it as an application level firewall because I am not
allowed to have inbound packets from the internet directly routed into
my private network.

As a result of my experiments I'd like to make an addition to the FAQ:

o if you want a transparent proxy for in and outbound calls,
  you will have to enable inbound calls using

	AcceptUnregisteredCalls=1

  in contrast to what the FAQ says.

  Security implications:
  of course, having unregistered calls allowed is less secure than
  to forbid them. But that is the problem with firewalls and inbound
  traffic anyway.

  It is still much more secure than to route the inbound traffic
  directly into your network.

o however, this will be an issue, as soon as you internally route
  calls into a public telephone network. You wouldn't want anyone
  on the world to have telephone calls on your bill, would you?



Besides the above FAQ issue, I figured out a conceptional ILS problem:

o if using a proxy, on an ILS server the following should be
  registered:
	alias on the proxy (h323_ID)
	IP of the proxy
	calling port on the proxy

o this information is available only to the proxy in the full extent,
  but to nothing else (gm doesn't know about the proxy's IP or port)
  Hence, the GK should do ILS registration on behalf of the client.

o however, I have not found any hints about ILS registration within
  gnuGK

So there are these Problems:
	1) where can the alias be recorded in the ILS data structure?
	2) what to do if using gnugk or any other gk that doesn't do
	   proper ils registration on behalf of the client?

Some more internet inquiries yield:

o there is a commercial product 
	http://www.dialupaudio.com/dualgatekeeper.html
  they state that inbound calls can either
	- be rejected
	- forwarded to a specific client
	- forwarded to any currently connected client
  so far that's easy, but a small attached note contains the
  important stuff:
	- if an inbound call is placed via an ils lookup, usually
	  the correct client is called. (All referring to MS
	  products, of course)

This means, there must be data stored on the ils used by netmeeting
to work around problem 1)

The solution is described in "The Linux Netmeeting Howto",
section "4.5 Serving Mutliple Aliases" using a forwarder program.
http://www.linuxdocs.org/HOWTOs/NetMeeting-HOWTO/using.html#SERVMULTALIAS
The gk proxy behaves exactly as a forwarder for inbound calls.

It is said there, that the 'cn' attribute is used as the alias on
the gk.
This means that a gk should register (and DUAL GK probably does) a
client on behalf of itself at an ils server with the clients alias as
'cn' attribute.

Hence, problem 2) can partially be solved within GM by using the same
text string in both
 	- General / Personal Data / E-mail Address
as well as
	- General / Directory Settings / Gatekeeper alias

So what remains of problem 2?
o IP and Port of the Proxy are not known to GM

Solution:
o for the IP problem it seems that ils.seconix.com ignores it anyway
  and uses the ip source address of the registration connection.
  So the solution is
	- to use ils.seconix.com
  OR
	- fill in the gatekeeper's IP into the NAT/PAT Router Support
	  fields in GM Settings

o for the port problem you have to configure all clients to listen on
  the same calling port, as well as the GK. So all clients register to
  the ILS as listeners on, say, port 1720 and as the gk is actually
  listening there, too, everything works fine.

  OR: Feature Request: add a
	Public Port of the NAT/PAT router
  to GM Settings.

The true solution is, of course, to add ils proxy features to the
gk in use. /but even for port forwarders the extra field might be
useful. You might want to use an extra port for each client on the
firewall but still run GM internally on it's standard port)


implications on clients:
========================

GM registering to the GK (and ils)
----------------------------------

a GM client using the same calling port (ideally 1720) as the
gatekeeper to which GM is registered, with both, the
	ils e-mail field
and the
	gatekeeper alias
set identically, can be contacted through the data available
on the ILS server using:
	'cn'@'sipaddress':'sport'


NM registering to the GK
------------------------

a NM client using the gk won't register to the ils, at least I believe
so. This seems correct behavior to me, from the above considerations.
--> no way to work around the gnugk problem from within NM. NM obviously
expects the proxy to do all proxy work, not just h323...


GM placing a call
-----------------

calling a proxied client from GM is possible manually by entering
	'cn'@'sipaddress':'port'

However, on double clicking on an entry in the ils directory, GM tries
to place a call to
	@'sipaddress':'port'
which won't work.

Therefore, you *must* manually add the users e-mail entry in front of
the ip-address in the callto URL.	:-(


NM placing a call
-----------------

calling a proxied client from NM works fine by double clicking on
the client's ILS entry. NM will place a call to
	'cn'@'sipaddress':'sport'

However, i have not figured out how to manually place a call to a
proxied client from NM. Something like name ip:port won't work,
as NM tries to lookup that at the ILS and will not find it.


Conclusions
===========

It would be very useful if GM could be extended by the
following feature:

o placing calls to 'cn'@'sipaddress':'port' instead of
  'sipaddress':'port' when using ils

  This won't harm non-proxied clients, as they accept any rubbish in
  the cn part ;-)


It might be useful to add these features as well:

o expand the NAT/PAT part by a port specification.
o place a warning, if e-mail and gk alias  mismatch


Hope I didn't bore you with this lengthy text.


And keep things up going. GnomeMeeting is real great work!!!

Joachim