Re: CU-SEEME and Wingate

Brian Godette (bgodette@idcomm.com)
Wed, 24 Sep 1997 15:59:50 -0600


At 01:25 PM 9/24/97 +0200, you wrote:
>Help please...:
>
>We have a little problem:
>
>How we must configure the Autosock client with CuSeeMe or
>iphone (vocaltec) client and the SOCK ( v.4 or v.5) service of Wingate
>in the server machine?
>
>We have intented many possibles (and impossibles) configurations
>of the Autosocks and Wingate....and nothing of nothing
>
>Please may y assistant? Is very important for Net 64 because
>we would get a very important client for us.
>
>Thanks a lot of. Best regards,
>

Ok, guess it's time to say something on this subject of CUSeeMe (or any
other UDP based program, netphones etc) and Proxy-Gateways (IP Masquarading
(including Linux 2.0.30 CU Masq'ing), NAT's, Wingate, MSProxy, etc).

It comes down to this, there is *NO* way for the "gateway" system to know
which internal system an inbound (net->lan) UDP packet is ment for as there
is no connection (TCP) based socket that is opened to the gateway system by
the internal system (which is how HTTP/SMTP/POP3 and all other TCP based
protocols are proxied). On top of which the gateway needs to remap the IP
address contained in CU packet headers for outbound packets, and remap the
IP address(s) in the body of OC packets received from a reflector/client.

NAT comes close, but would require the client and server to use a range of
UDP ports to send/receive packets over. But it would also have to modify
the packets as well just like a traditional gateway.

Linux's CU Masq'ing only half works and suffers the same problem as
Wingate/MSProxy/etc (no way to tell who the packet is for), and it's only
half functional in that it only remaps the IP addresses in the CU packet
headers and doesn't deal with the IP addresses in the body of the OC
packets which maintains the list of who does/doesn't have your vid open,
whether or not they can send/receive audio and aux (chat) data. The result
of which makes it appear as if *everyone* has your vid open and *everyone*
can send/receive audio.

I do have a solution that *will* work, that I've been kicking around for
about three months and keep adding new ideas to, but have yet to write any
code for. It's just not been something way up there on the list of things
to do as, working for an ISP and seeing it from experience, most people who
are using proxy/gateways are try to get "cheap" "dedicated" connections for
a LAN by using an unlimited/unmetered dial-up account on an ISP, which by
most ISP's (in the US anyways) Acceptable Use Policies isn't allowed.