[AG-TECH] room node certificates

[Colin Perkins]

On Wednesday, Oct 1, 2003, at 11:24 Europe/London, Jay Beavers wrote:
> I'd be concerned about overloading CNAME in this way.  While it doesn't
> specifically state that you should do so in the RFC, I put CNAME
> duplication checking via IP address lookup table in to my Rtp
> implementation to prevent the uncommon-but-occurred-a-couple-of-times
> scenario of someone logging in twice at the same time using the same
> identity which has the effect of drastically confusing users when
> someone else's video stream shows up under their name.  In reading
> through the spec, it doesn't spell out explicitly that CNAME is a
> machine-local identifier, but the recommended binding of CNAME to
> "user at host" strongly implies this, at least to me.

There are two issues here. The first is that a single user can start 
multiple instances of a media tool on a single host. For example, there 
have been a number of occasions when I've started two instances of vic, 
sending to the same RTP session from the same host (for example, to 
send video from two different cameras in a lecture room). If I also 
send audio from that host, and want to lip-sync the audio and two video 
streams, then all three streams need the same CNAME, so the receiver 
can associate them. I believe this is clearly defined by RFC 3550, 
Section 6.5.1 which says "To provide a binding across multiple media 
tools used by one participant in a set of related RTP sessions, the 
CNAME SHOULD be fixed for that participant".

The second issue is if I want to do the same thing, but I'm sending 
higher quality video and so need two separate hosts, one for each video 
stream. I also have a third host that is sending the audio. Assume that 
I have somehow synchronised the clocks on those machines, and that I 
want the receiver to be able to lip-sync the resulting three media 
streams. There are two ways to do this: we could signal to the receiver 
that the three CNAMEs really identify the same participant, and that it 
should synchronise the media streams. Or, the senders could collude to 
use a common CNAME, in which case the receiver can be unaware that 
anything special is going on, and will naturally synchronise the 
streams. I would argue that the latter is considerably easier to 
implement, and while not common, is not prohibited by the RTP 
specification.

> Perhaps a RTCP SDES PRIV extension field might be better used for this
> purpose?  I have some scenarios where a "group" of data is not "owned"
> by any specific CNAME -- such as a peer to peer whiteboarding scenario
> -- and therefore I needed to create a logical grouping of Rtp Streams.
> For instance, Ivan, Jay, and Colin are all sending ink onto a 
> whiteboard
> and we don't want the whiteboard to go away if just Jay leaves even
> though Jay was perhaps the originator of the whiteboard.  To allow the
> higher level application to understand the membership semantics of this
> group, I created an RTCP field extension to add a "CHANNEL" identity
> between these streams.  You could do something similar, such as a field
> name of "NODE".  The RTCP extension can contains a variable length 
> field
> of up to 255 UTF-8 characters (minus field name size), so it should be
> sufficient to hold a logical node name.  Since applications which don't
> understand a RTCP SDES PRIV field should ignore it, this is a much
> "safer" implementation than overloading an existing field with a "new"
> definition.

As we've discussed before, I don't think RTP is an appropriate protocol 
for applications like shared whiteboards: there are many issues like 
this, where the semantics of RTP don't match those of a shared 
workspace application. I wrote about this a while ago, in:

   Colin Perkins & Jon Crowcroft, Notes on the use of RTP for shared
   workspace applications, ACM Computer Communication Review, Volume
   30, Number 2, April 2000. 
http://csperkins.org/publications/CCR-2000.pdf

Cheers,
Colin