[AG-TECH] room node certificates

[Jay Beavers]

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.

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.

-----Original Message-----
From: owner-ag-tech at mcs.anl.gov [mailto:owner-ag-tech at mcs.anl.gov] On
Behalf Of S.Booth
Sent: Wednesday, October 01, 2003 2:16 AM
To: Ivan R. Judson
Cc: 'Robert Olson'; 'Colin Perkins'; s.booth at epcc.ed.ac.uk;
ag-tech at mcs.anl.gov
Subject: RE: [AG-TECH] room node certificates

On Tue, 30 Sep 2003, Ivan R. Judson wrote:

> We definitely need to figure out a way to coordinate (and keep track
of this
> information) I know Robert Putnam is doing something ad-hoc for his
cool
> spatialized audio (and maybe window highliting) work. I don't know
that we
> want to keep it in the venue, it feels to me like a "per-node" cache
of data
> with some interface for sending "meta-information" updates that ties
> together existing pieces of information.
> 
> Ie, the tools already assign ssrcs, if we just sent an event that
said, "I'm
> node ID and my SSRCS are x, y, z" that might be sufficient to start
with.
> 
> We probably should start gathering some reqiurements for what this
data is
> to be used for so we can get a better handle on what we need to
engineer.
> Any volunteers for requirements gathering?
> 

Ok I'm interested in helping with requirement gathering.

I'm also worried about relying on the venue to store everything 
It gives you problems with interoperating with non AG RTP equipment 
and if you are not very careful could introduce unecessary software
dependency between otherwise uncoupled components.

I think Colin is right the correct thing to do is to fix the choice
of CNAMEs My reading of RFC1889 is that this is the sole purpose of
CNAMEs

 RTCP carries a persistent transport-level identifier for an
 RTP source called the canonical name or CNAME, Section
 6.4.1. Since the SSRC identifier may change if a conflict
 is discovered or a program is restarted, receivers require
 the CNAME to keep track of each participant. Receivers also
 require the CNAME to associate multiple data streams from a
 given participant in a set of related RTP sessions, for
 example to synchronize audio and video.

Therefore I would suggest that the VenueClient or NodeManager chooses
the CNAMES and gives them to the RTP engines to use. 
Normally each node would choose a single CNAME for all streams.
In an earlier email I suggested adding the certificate name to the RTCP 
info and using this instead but I don't think that this would work
because
you can imagine a situation where a single node is sending multiple
audio
streams, each stream associated with a different group of cameras. This
would require the Node to allocate multiple CNAMES.
The selected CNAMES could also be registered in the VenueServer in case
you ever wanted to  cross reference RTP streams with other VenueServer
info.


				Stephen




======================================================================
|epcc| Dr Stephen P Booth             Project Manager           |epcc|
|epcc| s.booth at epcc.ed.ac.uk          Phone 0131 650 5746       |epcc|
======================================================================