Subject: White Pine CU-Seeme Multicast and SDR/VIC/VAT

From: "Charley D. Granieri" <[email-masked]>
Date: Mon, 24 Mar 1997 15:58:58 -0800 (PST)

The White Pine Enhanced CU-Seeme V2.2.1 for Windows has Multicast support.
I tried to make a connection from CU-Seeme to the SDR/VIC/VAT tools on my Sun
workstation, but was unsuccessful.  Does any one know if they are susposed to
work together?  And how to do it?

Thanks,
Charles Granieri
[email-masked]

---

From: Bill Fenner <[email-masked]>
Date: Mon, 24 Mar 1997 16:55:23 PST

I think that CU-SeeMe still uses its own proprietary packet format,
so whether using unicast or multicast you won't be able to get it
to talk to vic or vat.  It is supposed to send session announcements
that sdr can receive, though.

  Bill

---

From: "Mark L. Fausett" <[email-masked]>
Date: Mon, 24 Mar 1997 18:16:11 -0800

The multicast support in the client does *not* seem mbone compatible.

You're supposed to be able to use a multicast-capable reflector to
bridge mbone and cuseeme;  I've been able to make it work in public
(3.x) reflectors (with a bit of pain), the alpha/beta versions of 4.x
reflectors and not at all in the released reflector.

I've been told by white pine people that they're dropping mbone support
from the reflector.

Mark Fausett
[email-masked]

---

From: "Alan J. Flavell" <[email-masked]>
Date: Tue, 25 Mar 1997 10:58:30 +0000

> The multicast support in the client does *not* seem mbone compatible.

I'm not sure that we are talking about the same thing.

The WP reflector is quite capable of relaying a CuSeeme conference to an
MBone multicast address.  I've hosted one of the WP reflectors that was
relaying a USA meeting via CuSeeme, and we configured our reflector to
also inject the traffic into a uk-scoped MBone conference, this certainly
worked. The UK audience was able to receive the MBone traffic on normal
(nv/vat) clients successfully, although this was admittedly only one-way
traffic on that occcasion.

However, AFAIK one must use nv, in its CuSeeme mode, as the MBone client
(vic does not have this option, I think).  

Quite a different issue is using a multicast address to connect a number
of CuSeeMe reflectors together.  It's mentioned in the configuration file
as a possibility - I haven't tried this myself, I heard rumours that it 
doesn't work but cannot vouch for that. 

> I've been told by white pine people that they're dropping mbone support

I can't comment on that, but I know a man who could.  I've added him as
a BCC recipient to this mail, maybe he'd want to contribute to the 
discussion (but if not then I'll preserve his anonymity ;-)

Disclaimer: I'm just a small-time _user_ of this stuff.  I don't
understand the internals too well.  Possibly it uses the old pre-RTPV2
formats for its MBone traffic.

---

From: "Brian O'Shea" <[email-masked]>
Date: Tue, 25 Mar 1997 10:47:34 -0500

-
-The multicast support in the client does *not* seem mbone compatible.

The mbone is just a pipe.  If you send multicast data, you're using the mbone.
 So, the term "mbone compatible" makes no sense to me.

I think what you meant is that it's not compatible with what you are trying to
use it with, and that is certainly the case.  You're trying to mix apples and
oranges.

The client, although it uses multicast, which implies the mbone, uses the
CU-SeeMe protocol, which is proprietary.  You were expecting it to use RTP,
and you found that it didn't work.

The client will work just fine in multicast mode, and you can even have a
reflector involved, connected to the multicast group, and allow other clients
to connect via Unicast, and the reflector will send multicast data to the
unicast clients, and vice versa.

-You're supposed to be able to use a multicast-capable reflector to
-bridge mbone and cuseeme;  I've been able to make it work in public
-(3.x) reflectors (with a bit of pain), the alpha/beta versions of 4.x
-reflectors and not at all in the released reflector.

It ought to work.

What, exactly, specifically, were you trying to do?
What, exactly, was your configuration?

-
-I've been told by white pine people that they're dropping mbone support
-from the reflector.

Not mbone support, NV and VAT support.  NV and VAT compatiibilty in the
current 2.1 reflector is done by translating the CU-SeeMe <-> RTP 1.0 protocol
headers.  The NV and CU-SeeMe clients must be using the CU-Grey codec, and if
you want to use VAT, the CU-SeeMe clients must be sending Intel DVI 32kb/s
audio.

We are moving towards standards, and the standard is H.323.  In an effort to
focus on the future, we've decided to free ourselves from the past.

-bos

P.S. the 3.0 reflector will be called "Meeting Point Conferencing Server"

+***********************************************************************+
+ Brian O'Shea ([email-masked])			White Pine Software	+
+ Group Leader					542 Amherst St		+
+ Meeting Point Conferencing Server (MPCS)	Nashua NH, 03063	+
+ Phone: 603-886-9050				Fax: 603-886-9051	+
+		All it takes is all you've got.				+
+***********************************************************************+

---

From: "Brian O'Shea" <[email-masked]>
Date: Tue, 25 Mar 1997 11:01:07 -0500

-
-On Mon, 24 Mar 1997, Mark L. Fausett wrote:
-
-> The multicast support in the client does *not* seem mbone compatible.
-
-I'm not sure that we are talking about the same thing.
-
-The WP reflector is quite capable of relaying a CuSeeme conference to an
-MBone multicast address.  I've hosted one of the WP reflectors that was
-relaying a USA meeting via CuSeeme, and we configured our reflector to
-also inject the traffic into a uk-scoped MBone conference, this certainly
-worked. The UK audience was able to receive the MBone traffic on normal
-(nv/vat) clients successfully, although this was admittedly only one-way
-traffic on that occcasion.
-
-However, AFAIK one must use nv, in its CuSeeme mode, as the MBone client
-(vic does not have this option, I think).  

Correct.

-
-Quite a different issue is using a multicast address to connect a number
-of CuSeeMe reflectors together.  It's mentioned in the configuration file
-as a possibility - I haven't tried this myself, I heard rumours that it 
-doesn't work but cannot vouch for that. 

The rumor is a Fascist Lie!!  :-)

Linking reflectors together using multicast works just fine.

We had multicast connectivity in the reflector BEFORE we had client multicast
capability.  I'd like to take credit for it, but the 4.00B3 reflector source
base that we started from had it in there.

-
-> I've been told by white pine people that they're dropping mbone support
-> from the reflector.
-

As I said in my direct response, we're dropping support for NV and VAT, not
for Multicast.

-I can't comment on that, but I know a man who could.  I've added him as
-a BCC recipient to this mail, maybe he'd want to contribute to the 
-discussion (but if not then I'll preserve his anonymity ;-)
-
-Disclaimer: I'm just a small-time _user_ of this stuff.  I don't
-understand the internals too well.  Possibly it uses the old pre-RTPV2
-formats for its MBone traffic. 
-

-bos

---

From: "Mark L. Fausett" <[email-masked]>
Date: Tue, 25 Mar 1997 11:21:12 -0800

> The WP reflector is quite capable of relaying a CuSeeme conference to an

The current White Pine PC version of CU-SeeMe *client*  is capable of
multicast conferencing (***without reflector***) with other White Pine
PC CU-SeeMe clients.  It does not by itself interoperate with MBONE
tools such as Vat/Vic/NV/Wb, et al..  (I have not tried it beyond the
confines of a lan.)

That's all I thought I said.

> MBone multicast address.  I've hosted one of the WP reflectors that was
...
> (vic does not have this option, I think).

It's also a pity that SDR is *not* out-of-the-box able to describe the
settings required
to view a CU-SeeMe session --> send/receive small, CU-SeeMe encoding,
audio format dvi, etc..
I once hacked up sd to extend it's language to encode such things for a
use on a "intra-mbone", but I don't think it ever got used, beyond
testing.

....

> formats for its MBone traffic.

I'm pretty sure that reflector multicast support was added well before
RTP.  Then again,
I've been wrong before.

mf

---

From: "Mark L. Fausett" <[email-masked]>
Date: Tue, 25 Mar 1997 11:58:18 -0800

>  So, the term "mbone compatible" makes no sense to me.

My apologies; a poor choice of terms perhaps.  The MBONE is indeed a
pipe;  which to date has been primarily utilized by a set of
conferencing applications originating at places such as Xerox Parc,
Lawrence Berkeley Laboratory and University College of London; All of
which interoperate, and most of which have converged to RTPV2.  It's
been a long time since I've needed to differentiate between the two.

> use it with, and that is certainly the case.  You're trying to mix apples and

I'd prefer to see it as mixing different varieties of apples.  

I have a variety of machines which wish to teleconference on the net.
Some are PC's (mostly but not entirely NT), some are Mac's but most are
various Unix Boxes
(predominantly HP and Sun, some SGI, etc.).

I can, and have extensively used the tools referred to above to
conference on the unix boxes.
I have had mixed results using the PC varieties with NT(4) -- mostly,
but not entirely sdr difficulties;

I've also tried Precept's IPTV on the NT box;  works EXTREMELY well as a
viewer.  It just didn't seem to targeted as a multiparty conferencing
app.  I haven't checked lately to see if this is still the case.

> and you found that it didn't work.

No, I didn't really expect client-only multicast to work.  It was worth
checking/clarifying.

> unicast clients, and vice versa.

I was able to interoperate with NV/VAT using 3.X and 4.X(?) beta
reflector.  Given more time and effort I probably could have made the
commercial version of the reflector work also.  It just didn't seem
worth the additional time and effort to track down the problem.  I'll
give tech support their due;  they tried to help, but it came down to --
"it works for us, have you got all the patches you need?".

> Not mbone support, NV and VAT support.  NV and VAT compatiibilty in the

Again, my apologies for mixing terminologies;  It's only lately that
I've heard anyone actually make the distinction.  My interest is in
multiplatform interoperability.  I mean that to include boxes besides
PC's and Mac's (Is multicast support into the Mac product yet?).  

> you want to use VAT, the CU-SeeMe clients must be sending Intel DVI 32kb/s

Yep; Been there, done that.  It's simply annoying to have everybody on
the non-CuSeeme side have to open the session, then change video size,
set greyscale and set CuSeeMe encoding.
Once upon a time I hacked up an SD to allow me to specify the settings
necessary for CU-SeeMe; but sdr was so much better in other ways that we
abandoned sd and I never got around to hacking on sdr.

> focus on the future, we've decided to free ourselves from the past.

I'm not even going to touch that one...seems to have the makings of a
flame storm.

Mark Fausett
[email-masked]
San Diego, CA, USA

---

From: Joe Izen <[email-masked]>
Date: Tue, 25 Mar 1997 14:19:48 -0600

distribution:  videoconf

Hi Alan, Mark, Charlie,
   Let me try answering, and Brian O'Shea and Dick Cogger can correct any
misperceptions of mine.  CU-SeeMe reflectors can be 'peered' to each other
and exchange packets, either by Unicast or Multicast.  Multicast packets
are also used by MBone, however that is different from saying that CU-SeeMe
and MBone can interact.  There is limited compatibility between nv/vat and
CU-SeeMe reflectors.  An nv client, if configured properly (CU-Seeme
encoding and the 160x120
or 320x240 window sizes can join a WP 2.1 reflector--based conference.
There is a slight incompatibility between nv and CU-SeeMe which means that
that nv has to continually transmit in order for the reflector to know that
the nv client is still there.  I am aware of one nv user who complains pops
in an out of conferences, possibly because of lost packets, but it
basically works.  Vat does as well, if a compatible codec like DVI is
selected.  I am told that VIC has not implemented the CU-SeeMe
compatibility mode.

A little history:  Unicasting CU-Seeme reflectors is buggy in the free
Cornell Version 4.03.  I don't recall if it is supposed to do MC, but since
unicast is buggy, I wouldn't bother.  The White Pine 2.0 reflector release
advertised unicast and multicast support.  In my experience, Unicast worked
on some platforms, but multicast failed, at least on OSF/alphas.  The 2.0
reflector also did not count the # of nv clients correctly, and nv
connections could render the reflector unuseable.

The nv client counting bug was fixed in the WP 2.1 reflector release, and
2.1 is the most reliable release, Unicast-wise yet.  I only have 1 SunOS
4.1 machine that refuses to unicast, but I have unicasted other sunos 4.1
and hp 9.0x cpus without a problem.  WP is working with me on the
recalcitrant machine.
I have not tested multicast on 2.1 myself, however the WP quality assurance
people I have dealt with have told me they have tested it sucessfully.

I believe the CU-SeeMe PC client is MC capable, but I'm a mac user so I
have no direct experience.  This would only enable connections to other
CU-SeeMe clients or reflectors however, not to 'MBone'.  CU-SeeMe clients
can only interact with nv/vat clients if they are connected to a CU-SeeMe
reflector.

I have asked WP about nv support.  They have always been unenthusiastic,
but have never told me definetly they would drop it, although it is
possible  that my information is old.  Whenever I've raised the subject,
I've been told that WP is moving in the direction of standards-based
protocols.  I do not know what Dick Cogger's plans are for the Cornell
reflector.  The current Cornell release 4.03 has endian problems with nv
connections from some platforms.

My own view is that it is useful to have CU-SeeMe and MBone users
interact..  In the high energy physics community, people have Macs, PC,s or
Unix on their desk top and a videconferencing solution which ignores one of
the platforms is not a solution.  I find it surprising that VIC would not
have a CU-SeeMe compatible mode, and that the CU-SeeMe reflectors don't
support nv better.  It would make both systems more attractive.  Perhaps
someday there will be Unix CU-SeeMe clients and Mac/PC MBone clients as
well.  I am aware that Apple was developing an MBone client but I think
that has recently been axed in an Apple downsizing.

Hope this helps resolve some of the confusion.

-Joe

---

From: "Alan J. Flavell" <[email-masked]>
Date: Tue, 25 Mar 1997 20:27:17 +0000

On Tue, 25 Mar 1997, Joe Izen wrote:

> the nv client is still there.

Joe, this (and your nv client counting bug) surely only applies when nv
connects in _unicast_ mode to a reflector?  I don't recall any such
problem when relaying into the MBone in multicast mode.

> the platforms is not a solution. 

The way things presently are, I think that was a useful point to make.

Sure we'd all like to use a common standard when it's deployed, but
meantime, it's useful to be able to patch together a number of partial
solutions that exist.

---

From: Joe Izen <[email-masked]>
Date: Tue, 25 Mar 1997 14:42:42 -0600

distribution:  videoconf

Hi Alan,

At 8:27 PM +0000 3/25/97, Alan J. Flavell wrote:
>connects in _unicast_ mode to a reflector?

Correct, and the bug is only for the WP 2.0 Unix reflector.  Brian fixed
this for the 2.1 release.  The cunting bug was due to the reflector, not nv
itself.

>I don't recall any such

You mean using nv in its native MBone environment right?

-Joe

---

From: "Alan J. Flavell" <[email-masked]>
Date: Tue, 25 Mar 1997 22:07:54 +0000

> >connects in _unicast_ mode to a reflector?
..
> You mean using nv in its native MBone environment right?

Right.  In the specific example, I was referring to relaying into a
UK-scope nv/vat "conference" from a 2.0 WP reflector, as you might recall. 
This worked well with the WP reflector (though on an even earlier test
with the public domain reflector, it worked badly with one platform, that
I don't have access to, but most of the other platforms either weren't
offered or didn't work.  Still, that's ancient history now.)

F.y.i, I've never actually tried reflector-to-reflector relaying
via multicast.  I mistakenly passed on a rumour that it didn't work,
but I've been assured, earlier in this thread, that it does.

---

From: Mark Handley <[email-masked]>
Date: Tue, 25 Mar 1997 18:35:56 -0500

>to view a CU-SeeMe session --> send/receive small, CU-SeeMe encoding,

No-one's every sent me a plugin to put into sdr.  If they did, it
could include this.

However, there's no *current* Mbone tool (nv and vat 3.x are obsolete)
able to receive a CUSeeMe session other than CUSeeMe itself.  Right
now, sdr has code to receive old-style vat and nv announcements, but
creating these announcements is disabled as we don't want to prolong
their use.

Migrating CU-SeeMe to use RTP would be a prefered path (and I gather
this is happening anyway for H.323 support).

Mark

---

From: "Brian O'Shea" <[email-masked]>
Date: Tue, 25 Mar 1997 19:12:37 -0500

Hi Joe,

-A little history: Unicasting CU-Seeme reflectors is buggy in the free
-Cornell Version 4.03.  I don't recall if it is supposed to do MC, but since
-unicast is buggy, I wouldn't bother.  The White Pine 2.0 reflector release
-advertised unicast and multicast support.  In my experience, Unicast worked
-on some platforms, but multicast failed, at least on OSF/alphas.  

That is an OSF kernel bug.  The reflector would send and receive multicast
fine until you run mrouted.  I talked to Joe Burrescia (sp?) about it at the
IETF, and he agreed.  Unfortunately, that's how you wanted to use all of the
OSF/Alpha's, with multicast reflectors and mrouted.

-bos

---

From: Ajay Kachrani USG <[email-masked]>
Date: Wed, 26 Mar 1997 11:21:20 -0500 (EST)

> OSF/Alpha's, with multicast reflectors and mrouted.
What OSF/Alpha kernel bug are you referring to and under what version of 
OSF/Alphas?

We've mrouted 3.8 and all appropriate tools and kernel changes (3.5 from Parc)
included starting from DIGITAL UNIX 4.0 and not aware of any Multicast 
kernel bugs...

--Ajay Kachrani
[email-masked]