Re: White Pine CUSeeMe Version 3.1.1

Scott Lacroix (slacroix@wpine.com)
Fri, 17 Apr 1998 22:21:55 -0300


Well, I wasn't going to respond... But I came in late tonight, and (like
everyone else it seems) I'd had my Wheaties so I was all fired up...
*sigh*
This is gonna be a long one... I combined alot of messages on a common
thread into one resonse.

At 03:20 PM 4/16/98 +0000, Wayne Fisher wrote:
>For those users experiencing problems with version 3.1 of White Pine's
>CUSeeMe Product, there is a public beta of version 3.1.1 available from
>the White Pine web site (http://www.wpine.com) that contains some major
>bug fixes which will probably correct the problems you are having. You

Hey Wayne! Thanks for the (positive) public announcement! I bet you didn't
have any idea you'd be catching such a ration of flack for it, did ya? *G*

[clipping & mixing messages... there will be alot if this...]

At 11:21 AM 4/16/98 -0500, Jason Williams wrote:
>On Thu, 16 Apr 1998, Wayne Fisher wrote:
>> 2 of the major problems fixed in this new version:
>> (1) Failure to transmit using Cornell Greyscale coldec to 2.x and
>> cornell users.
>> (2) Falilure to transmit Color MPEG codec when you leave and then
>> (re)join the same or another reflector
>
>I've heard mixed reports concerning this...At least one person told me
>that this hasn't been fixed yet as of 3.1.1.004.

Possibly, but not a word one about the Greyscale fix, not even a thank
you! *sigh* Passed right over it in favor of pointing out the flaws.

At 11:21 AM 4/16/98 -0500, Jason Williams wrote:
>> The problem with private chat sending messages publicly when the other
>> user has disconnected also seems to be fixed.
>
>Unfortunately, the problem sending 3.X private chat to users with Enhanced
>CU 2.X still seems to have problems. Luckily, Brian Godette's Enhanced
>Reflector fixes this.

Yes, and that's a completely different thing. And not a bug... The older
clients have never been able to tell the difference between private &
public chat. That's been a problem since GeekTalk. And yes, correctly used
GeekTalk will modify the chat so that it's flagged as private. I know.
What Brian did is to modify every private chat packet outgoing to an older
client. I'm glad he took it apon himself to do that, it's a big help to
some people. Modifying users chat as it passes through the server is a
choice not all people would agree with, however. Is there an option NOT to
do that for certain conferences? Not that it's a big deal one way or the
other, just curious...

At 02:36 PM 4/16/98 -0400, David Toole wrote:
>problems when switching. IMHO, software should work, period.

Now that's a nice, broad blanket statement. I take it you mean every piece
of software should work with everything you expect it to. In this case, all
versions of any client claiming to be CU-SeeMe should work with all
servers/reflectors claiming to support CU-SeeMe. That's an aweful tall
order, isn't it?
Let's see, people have been using the Microsoft example here. Thus, you
would expect all apps that run on Windows 3.0 to run correctly on
Win95/WinNT and beyond (otherwise complete backwards compatability cannot
be claimed). Well, even Microsoft can't claim that. They try, and they come
close, but every now & then I download shareware that (I'm sure) ran just
fine on the Win3.1 machine it was written for but dies a horrible death on
my Win95 machine.
Also (vise-versa) you'd expect everything that claims to be Windows
compatible to run every app that ever ran on Windows. IBM OS/2 couldn't do
it, SoftWindows for Mac and/or Solaris couldn't do it... The NT emulators
couldn't do it, and Windows NT for Alpha (from Microsoft) can't do it.
So yes, in a perfect world everything would hold 100% backwards
compatability. But we're not perfect. We're human.

At 12:55 PM 4/16/98 -0600, Brian Godette wrote:
>My take on this, based on the 3.1.1 release notes, is that they are having
>problems related to switching between old style CU headers and RTP headers
>when switching refs. It's my understanding that WP Ref 2.1 and up support
>RTP headers from the new WP CU clients (3.0 and up). I would guess there
>would be no problems switching refs as long as you stay exclusively on WP
>2.1 and up or ERef/Cornell/WP 2.0.

Hmmm... that would also (I assume) be based on an email conversation we
had? Sorry about not responding... I had WAY too much to do for awhile
there & lost the thread... At any rate, I think you're wrong here.
First off, a technical point. The 2.X reflectors didn't do RTP, so if
there's a problem that's common between 3.X and 2.X then it can't be based
on RTP.
Next, based on testing reports I've seen, it can't have anything to do
with RTP. Apparently connecting to certain servers, then disconnecting, and
RECONNECTING TO THE SAME SERVER can fail. Thus, it has nothing to do with
state. Now I'm not a client guy, so I can't get technical here (and I won't
in a public thread anyway...) but I thought I'd point that out.

At 03:55 PM 4/16/98 -0500, Jason Williams wrote:
>How about the somewhat random spewing of someone's text in the chat
>window? That seems to be different from the private chat bug.
>
>An old email from Brian concerning this:
>"BTW there appears to be an oddity with WPCU 3.1.* in regards to chat
>recovery. Seems that if it doesn't know about the client that's making the
>recovery request (hasn't ever received an OC packet from them) it'll send
>the requested chat lines as public (client->group instead of
>client->client). This behavior is of course induced by a conference with
>too many participants for it to list"

Just a random thought on that one... It seems to me you guys do some
incredibly detailed testing/debugging... I don't suppose you ever
considered mailing your tests and/or results to WhitePine to get a fix?
Since it's obvious that you are very concerned with the quality of our
software (and I think that's great), why don't you send the data to the
beta-test program rather than blasting WhitePine in a public mailing list?
You've already worked out the problem, why would you...
Oh, never mind.

At 04:03 PM 4/16/98 -0500, Jason Williams wrote:
>Yep..I agree :)
>But is it really any worse than the 3.X client not being fully compatible
>with their OWN 2.1 client with private chatting? At least now, their 3.1
>client works with other White Pine reflectors. A step in the right
>direction. :)

Again, it's not compatability that's an issue. The private chat
sends/recieves just fine between 3.X & 2.X clients. The problem is that the
3.X client doesn't stuff "<privately>" (or whatever the ERef is inserting)
into the outgoing chat. If you're sending priv chat to a user that can't
tell, do it yourself. Right click the participant name... if they don't
have the ability to download thier contact card, they probably can't tell
the difference between priv chat and public. Make a macro in 3.X that
inserts "<privately>" in the text, click it before you type, and send that.
*sigh*
It's not a bug, it's just up to YOU to mark it.
And if people NEED to have the server do it FOR them, then the ERef has
that ability now. Personally, I'd rather just do it myself then have
anything else leading me along. Or for that matter, having the ERef stuff
something into a message I've already marked...
BTW, I know the arguement that it makes it easier to tell if someone is
harrassing you with private chat... But most people can tell pretty quick
if they are the only ones getting obnoxious messages. And stuffing
"<privately>" in the chat won't stop people from sending it anyway...

At 12:55 AM 4/17/98 -0500, Jason Williams wrote:
>key! White Pine's market is NOT the Cornell/Enhanced Reflector market or
>one in which Cornell/WP 2.X clients co-exist with 3.X clients. And that's
>where all the problems seem to be arising.

Given that, why does this follow:

>I have no problem with White Pine optimizing their client for use on MPCS
>servers and their 2.1 reflector. What I do have a problem with is when
>they BREAK compatibility with older clients and don't seem to think much
>of it.

If you state the one, the other become irrelevant. I think you're wrong on
the first statement, however... In fact I KNOW you're wrong about the
Cornell client compability issue. It may be broken today, but imperfect
humans have bugs. They get fixed in beta cycles. Be patient, we're not done
yet... :)

>reflectors makes sense. But does that also mean they should develop their
>own independent protocols that work solely on MPCS servers and nowhere
>else? If you do that, then why have the name CU-SeeMe at all? That's

Ok, so lets assume you're basing this on the RTP mention that Brian made
earlier. What difference does it matter if the WhitePine client supports
RTP, H.323, and Pete Jones' Spiffy standard? (Ok, I made the last one up...
:) So long as it handles the basic Cornell-defined standard, it's CU-SeeMe.
And so long as the reflector(s) handle the same standard, everything's
happy. Thus, you can have one protocol that speaks only to MPCS's, another
for NetMeeting, another for point-to-point client connections, and the
basic CU-SeeMe for everyone else. And six more if you like... No problem.

>kind of like saying "there are two versions of Win95..one version runs one
>set of applications while the other version runs another and they can't
>cooperate".

It's more like saying there's one kind of Win95 and it runs 16 bit apps
AND 32 bit apps. Which is pretty much like saying you support the old AND
the new.

>There's also not a "myriad" of reflectors. As far as I know, the MAIN
>one used is Brian Godette's Enhanced Reflector (And Brian performs a great

Actually, there are four as I see it. The base Cornell reflectors, the
WhitePine 2.X reflectors, the ERef, and the MPCS. And I don't know WHAT the
MAIN one is, but I'd LOVE to see a survey! How bout a show of hands...
Everyone that runs a ref that's reading this list: What type/version of
reflector/server do you use?
This should be interesting, eh? :)

>> Let me use the Cornell CUSeeMe client as an example. In the release
>> notes, the types of cameras which are supported by the Cornell version
>> of the software are clearly outlined.
>
>Actually, in the release notes it states:
>"If your capture card is not listed above, but does support one of the
>above video formats, it will likely work."

Ok, let's pick nits here...

>And to be fair, the Cornell supported hardware list what capture devices
>have been tested and work, not which devices DON'T work. There's also a

It's not possible to give a definitive list of things you DON'T support.
So in most cases, it's much better to say what you KNOW you DO support.

>So what you're saying is..it's ok for a software to distribute bugs with
>its software as long as the limitations and bugs are clearly states in the
>documentation?

Uhm, all software has bugs. It's a sad, sad fact of life. Like I said,
we're all human. Would you preferr that the list be distributed WITH the
product, or go back to Win311's cryptic "Fatal Error 302157" type dialogs?

>client. White Pine could easily allow their client to work with other
>reflectors without having to handle tech support for other reflectors. I
>haven't heard of any cases where Enhanced Reflector or Cornell reflector
>operators have bombarded White Pine with questions on how to setup their
>reflector.

Uhm, no that's not true. Have you ever worked in Tech Support? Actually,
niether have I, but I work WITH them... You get phone calls from EVERYONE
that uses the software, REGARDLESS of how or why. They wouldn't get
"reflector operators" calling in, it will be people using 3.X clients to
connect to ERefs that WILL call (regardless of support status of the ERef).
And they won't care what kind of server it is, just that they need to know
how to configure the WhitePine client to connect to it. And yes, there
probably will be a lot.

>Phone users. With CU-SeeMe, there's White Pine and Cornell. Since the

Hmmm... that's not entirely accruate either. Those are certainly the two
biggies, but there is an OS/2 client, an Amiga client, a Java client, and a
Linux client that are all developed independantly.
Oh, and by-the-by, you can add connection problems between WhitePine and
THOSE clients to your support call list as well...

>An interesting aside to this is H.323 compatibility. If you were so
>deeply concerned about White Pine's tech support consider H.323 and having
>the ability of OTHER clients not made by White Pine OR Cornell to connect
>with MPCS servers. Just imagine the nightmare tech support is having
>now...supporting Intel's Videophone, Netmeeting, etc. The ironic thing

An excellent point, lets add them in too...
Now, tell me again how simple it would be to keep support for all four
existing server implementations? :)

>And I'm sure you'd hear a LOT of complaining if someone like Microsoft put
>out an update to Netmeeting which allowed you to ONLY conference with
>other Netmeeting users using the same version as you and then also charged

Ok, it's been done. I'll admit, they never charged money for it, and
that's a good thing. You should try keeping up with Microsoft's development
cycle! Thank goodness they're happy with NetMeeting 2.1. *G*

>you money for it. I doubt it would be very popular in the positive sense.
>That's the whole idea for H.323: interoperability. Which means backwards
>compatibility has to be supported as well.

Mmmhmmm. To my knowledge, you cannot connect NetMeeting 2.0 clients to
NetMeeting 2.1 clients... but I'm not SURE about that. They certainly will
work ALOT better if you use the same version numbers!
By-the-by (again :) the H.323 standard is only MOSTLY standardized...

>Thanks for the comments...<joke>And I wouldn't bash them if they did
>things correctly </joke> :)

<sarcasm> It's good that you marked that as a joke! :) </sarcasm>

At 11:43 AM 4/17/98 -0600, Brian Godette wrote:
>>White Pine knows the ins and outs of their server software (i.e., Reflector
>I'd argue that.... considering how long some long standing problems and
>(relatively obvious) security issues still exist in it.

Ok, THIS is actually where I decided that I was going to respond... It's a
LOOONG way to go to get here, eh? :)
I think I pretty much know the ins and outs of my server software....
(note that I said *my* server software, I'm very protective of it :) But I
don't want to get into a pissing contest with Brian over who can be more
technical when describing the inner workings of the code and/or protocol.
First off, Brian's VERY good at what he does. I'm impressed that the ERef
is maintained by ONE guy! And second, if there are issues you've got with
the MPCS, send them to me offine. You've got my email address... I'd be
happy to look into them.
MORE than happy to hear about anything new! :)

>>2.x and MPCS), so wouldn't it make sense for them to limit support for
>>their client software (CUSeeMe 2.x and 3.x)? Tech support can only do so
>>much....
>This doesn't make since considering they claim to be backwards compatible
>with the Cornell software, and as stated above there is only *TWO* flavors
>of reflectors from the client program's point of view.

Mmmm... and as stated above, there are FOUR versions of the
reflector/server from the Tech Support point of view.

>reflector software is out there from a *client* point of view. There's only
>*two* "systems" in use here, the standard Cornell headers, and what WP uses
>with Ref 2.1 and MPCS, which involves RTP headers (standard set by MBone

And again, the 2.X refs don't do RTP. Never did it, never will.

>>Pine be any different? I don't hear anyone complaining about these
>>company's limiting the server software which can be supported by their
>>clients.
>
>They don't complain because those systems are self-contained, there is no
>compatibility issues with other publicly available software from third
>parties. The reason wht WP *IS* different is they have, once again, a
>backwards compatibility issue to live with.

That's an EXCELLENT point, and THANK YOU for making it!

>So you'd be perfectly happy if Microsoft made a "technical decision" that
>resulted in say... Win98 running Microsoft software only, or charging money
>for Internet Explorer and having it work only with web sites on NT running
>IIS 4.0? Think about how much damage that would do to their market share.
>This is exactly what *does* and will happen when products built on existing
>products break backwards compatibility with the existing products, and is
>exactly why iVisit, VocalTec, ICUII, VDOPhone don't have this problem.

Why does everyone pick Miscrosoft as a shining exemple?

How about if someone changed (added to) Java then fixed it so that only
THIER browswer understood the new stuff? (I've bumped against these myself)
Or had outstanding agreements with a company for compatability between
operating systems and as soon as the contracts ran out, changed thier OS in
ways that made all new binaries incompatable with thier former "partner"?
(Talk to IBM about OS/2 Warp) Or intentionally implemented OS specific
extentions to Java that make a cross platform language/development tool
system specific? (COM extentions to Java, ActiveX plugins, ...) Microsoft
has done all that... and lets not get into the problems with the supposed
wonderful 32bit enhanced filesystem for Win95...
Mind you I'm only staying with very recent exemples here. :)

Ok, my point here is not to bash Microsoft. Just to clear up a few points,
and to say that everyone has problems...
Thank you for pointing them out. Rest assured that people on both the
client and server teams are recieving your input. The problems are being
addressed. As far as compatatbility goes, WhitePine clients are STILL going
to have compatability with the Cornell refs. If (as Brian says above) there
are no differences between the ERef and the basic Cornell refs (as far as
the client is concerned), then there is nothing to worry about (as far as
the ERef is concerned).

At 03:20 PM 4/16/98 +0000, Wayne Fisher wrote:
>Thought everyone would like to know this....
>

Just my (very vocal) $0.02...

- Scott

--

,-==================================-.-==================================-. | I haven't lost my mind, it's backed | Scott LaCroix (slacroix@wpine.com) | | up on tape around here somewhere... | Sr. Software Engineer ___ | | - Author Unknown | White Pine Software ./_ -\. | | #include<disclaimer/std.h> | http://www.wpine.com q| o O |p | `-==================================-^-=====================oOOo=~U~=oOOo-'