[Prev][Next][Index][Thread]

Even more on CU-SeeMe

I've talked a bit with the NV author. The impression I get is that all
this CU-SeeMe stuff in NV is marginal. In particular, the reflector
support for NV-style CU-SeeMe has some deficiencies. The big problem
is that CU-SeeMe seems to be locked up in proprietary stuff, no source
code, no protocol specs. Knowing that, I'm pretty happy with what I
can do so far.

I also got the impression that NV's CU-SeeMe stuff was really intended
to be used for multicast operation. I've never tried multicast, don't
really know anything about it.

He expressed interest in adding QuickCam support to NV, by the way. I
told him that the effort now was to build some standard interface to
the camera, maybe a kernel device driver, and when that was done the
NV support should be pretty straightforward. Hope that was right :-)

There's also a rumour that someone (White Pine?) intends a Unix
version of CU-SeeMe before too long. That would be awfully nice,
especially if we could help out by providing them a quickcam interface.

David Chow writes:
>Good news! These two hosts work as reflectors!
>192.233.34.5 vdorm.taponline.com

Yes, they work for me too! Hooray! Now I don't feel so bad.

Does anyone have a clever way to protect oneself from the bandwidth
that a reflector sends down the pipe? I had to drop carrier twice just
to protect my 28.8kbps link from those things. CU-SeeMe has some sort
of receive throttle. I can't even make the NV "receive halfsize" work.

>So the problem is not with NV, but rather the reflectors (i've
>tried nv on suns connecting to cucme and they don't work too)
>The strange thing is... they report version 1.0-b3 ???
>is that a production version from white pine???

That's a good question! How'd you see a version number? I searched
around a bit for other reflectors (cuseeme is remarkably hard to find
information about), but could only find this reflect-4.0b3 that I'm
using now. I've sent "feedback to the taponline web site" (the closest
I can come to an email address for the people running the reflector)
asking them what software they're using.

Anthony Rumble reports:
>The Cuseeme/NV encoding in the Reflector is ENDIAN specific
>(much like the problems in the NV program itself) and hence
>you can ONLY speak to reflectors on Sun's etc.

Oh, so there's an endianness problem in the reflector, but not NV?
I'm not sure what this implies - I confess I don't remember the
endianness of all the different architectures. It works on a Sun: if
the reflector is running on Linux, will it work?

Mehmet T Avcioglu asks:
>Ok, I think I am missing something. Can I connect to the reflector that I 
>am running on the same machine?

I haven't tried this. I did run the reflector on my Linux machine
once, had two CU-SeeMe people on PCs connect and it worked. I wasn't
part of the party, though. I don't have the first inkling about what
NV is doing to negotiate the connection. When I start NV with a
reflector running on my machine, I get an error message that the port
I wanted (4444) was already used:
  recvfd: bind: Address already in use    
but it seems to work. At least, the reflector receives a video stream:
don't know if it reflects it propertly to other connected people.
Follow-Ups: References: