Re: Warning: Mac CU-SeeMe 3.1.0.xx

Brian Godette (
Fri, 06 Mar 1998 11:02:01 -0700

At 10:03 AM 3/6/98 -0500, you wrote:
>I have had a chance to quickly check into your comment about 2.0 and 2.1
>but have not had the time to pull up old bug reports and install the old
>versions, will try to look a little deeper next week, but I wanted
>to get some answer out to you so you would know I was not ignoring this.
> From talking with
>my engineers and recollecting what this may be about, I have found
>the following:
>We did not change the code to send video over the aux channel in 2.1 or ever,
>new or old versions would not work at all if we did.
>Basically AUX data is send in two ways:
> 1) If there is data to send then it is appended to a video packet
>directly after the video data.
> The video packet header indicates the size of the packet and
>how much video is in it. If their is additional data on the packet, such
>as aux data, it contains it's own header describing the type and number of
>bytes etc. In this way other channel media types could be added later.
> 2) If there is data to send and their is no video packet going
>out during a short time span then a video packet with no video data but
>just AUX data is generated.
>What we recollect happening was that sometimes
>when a new aux data packet was sent at first connect and you had
>been running CU-SeeMe already for a while, there was some left over video
>data in the buffer after the aux data and this confused 2.0 but not 2.1
>because 2.1 has more intelligent buffer checking put in during our
>I need to check this out more exactly but this condition did not bother
>the Cornell version.

This is also a condition that was seen, where the aux packet would be
longer than the internal header lengths, and the trailing data would be the
previous packet's contents. As if the external packet length wasn't reset
correctly before sending it with sendto(). This was really minor at
shouldn't have caused any problems with any of the clients except for the
fact that more data was being sent than needed. This is still present in

What I've seen is one full frame of perfectly correct video packets (no aux
header after the VPH), with the vph->dataType set to AuxData (0x101), and
marked as client-to-client with a destination IP in the VPH. I've turned on
packet logging for this condition and will see what turns up tonight, it
may have been fixed in the later 2.1 clients.

This really is much of a non-issue at this point since it only effected WP
2.0.* 32bit clients, which I haven't seen anyone using since a few months
after 2.1 came out since it was a free upgrade.