Re: CU-Seeme problems

gordon whelpley (zephyr@PRIMENET.COM)
Mon, 13 Feb 1995 20:28:27 -0500

I am also getting these errors when everything else (video, software, etc.)
seem to be work. The errors continue untill I am "timed out". As I am
using a dialup SLIP connection, I asked my provider about a permanent IP
address (vs. random). As it turns out, that for a small fee they will
provide me with one. The question is then; Will a permanent IP address
solve this problem? Any opinions or direct experience? GW

At 08:01 PM 2/9/95 -0500, wrote:
>> The most recent version of the reflector software does not work with
>> your set-up. The reason is that when SLIP sends a UDP packet, the
>> packet contains the address of your SLIP client. The reflector,
>> instead of reading this address from your packet, does a DNS lookup for
>> your IP address (which of course is different since you are using SLIP
>> and have essentially circumvented the normal domain name service.)
>> Thus, the packets are probably arriving at the reflector, but the
>> return packets from the reflector are going to a bogus address.
>For the record, this is not exactly correct. To quote from a posting of
>several days ago:
>Each CU-SeeMe packet contains the (apparent) IP address of the machine on
>which it originated (CU-SeeMe trying to find its own IP address is the
>source of the dreaded "GetHost" error that Windows folks experience). This
>is not intended to be used for network addressing, but just as a unique ID,
>e.g., to identify which window a video packet belongs to. Currently, the
>reflector software compares this supposed IP address with the actual source
>IP address (from the IP header) and rejects the packet if they don't match.
> I'm not sure why it does that; I think it was a quick fix to some problem
>we observed. In any case, anyone who is in a situation where the IP
>address that your machine thinks it has is different from the actual IP
>source of the packet that reaches the reflector will not be able to connect
>to a reflector.
>It doesn't have anything to do with DNS, but with packets arriving from an
>IP address that is different from the IP address where they originated
>(where the "originating IP" is whatever the TCP/IP stack tells CU-SeeMe).
>At least I'm pretty sure that's what's going on.
>Tim Dorcey
>Sr. Programmer/Analyst (607) 255-5715
>Advanced Technologies & Planning
>CIT Network Resources
>Cornell University
>Ithaca, NY 14850