bug in CU-SeeMe Ver 8 talk

Hugo Jackson (hjackson@junction.net)
Mon, 31 Jul 1995 08:21:08 -0800


Okay, here's interesting behaviour that perhaps Tim or someone might be
interested in...

1. This is a one/on/one connection, both parties are running the mac software.
2. Parties A & B are both online and successfully connected both for video
& talk window.
3. Party A is informed by PPP that PPP has gone loopy and inquires whether
a restart (of PPP) should take place.

(sub note: PPP seems to do this a lot, but only in the following
circumstances: one/on/one connection, no audio on either end, talk
windows open on both ends. PPP goes loopy for both Party A and
Party B when there has been too long a pause in talk activity.)

(BUT THAT'S NOT THE PROBLEM I'M CONCERNED WITH RIGHT NOW.)

4. Party A says "ok". Service provider is redialed by PPP, a connection is
restablished and Party A is returned to one/on/one connection with Party B.

BUT HERE's THE INTERESTING THING:

5. Video still works but the talk window no longer works.

REASON: Because Party A's service provider assigns IP address dynamically,
party A's IP address has changed.

BUT HERE's THE REAL INTERESTING THING:

Why is it that even though the IP address of party A has changed, and the
talk window no longer works, the video still works?

PROBLEMS WITH THE EXISTING SETUP.

1. Because CU-SeeMe was not re-launched, it does not change the IP address
of Party A.
2. The only way for party A to find out the new IP is to restart CU-SeeMe,
but when Party B attempts to reconnect with Party A (using the old IP
number) there is according to CU-SeeMe, "no response" from Party A.
3. This seems odd, seeing as the restart of PPP (and the assignment by the
server of a new IP address) didn't seem to bother the video at all, only
the talk window.
4. It makes it very difficult for party A to inform party B of the new IP
address.

Yes I know that party A could have made a note of party B's IP before
quitting and relaunching CU-SeeMe, and accepted responsibility for
re-initiating the link, but Party A (that's me) for some other unknown
reason has never been able to initiate a link with Party B. Party A has
always received a "no response" from party B. But on the other hand, how
can the video handle the change in IP but the Talk window cannot? Inquiring
minds want to know.

Anyway, if this is not a bug, I sure wouldn't mind having someone explain
how this "feature" works. :)

Is there any chance someone could be coaxed into looking into this problem?
Or maybe send me a developer's kit so I can work on it myself?

Thanks.

+======================================================================+
| | Obviously this life is a test... |
| Hugo Jackson | Had this been a real life you would |
| hjackson@junction.net | have received complete instructions |
| | and told where to go and what to do.|
+======================================================================+