[AG-TECH] room node certificates

[Jay Beavers]

The "first issue", using CNAME to link multiple streams to a logical
sender, is very clear from the spec.  In the "second issue", AKA reusing
a CNAME between multiple hosts, it's possible that you'll run into
interoperability problems.  It's a reasonable assumption from reading
the spec that you could reuse CNAMES between multiple hosts, there's
nothing in the spec which says you can't do this.  It's also a
reasonable assumption from reading the spec that a CNAME bound to a
specific host.  There's also nothing in the spec to say this isn't true
and at least to me this is implied by the recommended value for CNAME of
"user at host".  Because of the ambiguity here, you may run into problems
between two spec compliant implementations of the same standard.

I like your paper below, I think it is a good analysis of the issues you
run into using Rtp for shared applications.  I also feel there are a few
additions you can make within the Rtp protocol (a SDES PRIV extension
for CHANNEL as noted below, Reed-Solomon FEC, NAK ARQ, and PGMCC) that
are within the purview of the Rtp spec that address your concerns :-)
The end result is one network stack which can handle streaming a/v data
or shared state data depending upon behavior properties which are set on
a per Stream or PayloadType basis while exposing an Api to application
writers which is consistent between media types.

 - jcb

-----Original Message-----
From: Colin Perkins [mailto:csp at csperkins.org] 
Sent: Wednesday, October 01, 2003 4:25 AM
To: Jay Beavers
Cc: s.booth at epcc.ed.ac.uk; Ivan R. Judson; Robert Olson;
ag-tech at mcs.anl.gov
Subject: Re: [AG-TECH] room node certificates

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