[AG-TECH] room node certificates
Colin Perkins
csp at csperkins.org
Wed Oct 1 06:24:57 CDT 2003
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
More information about the ag-tech
mailing list