[AG-TECH] room node certificates

[Ivan R. Judson]

> -----Original Message-----
> From: S.Booth [mailto:spb at epcc.ed.ac.uk] 
> Sent: Wednesday, October 01, 2003 4: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.
> 

Cool!

> 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 agree, but there are some facilities the venues provide that might be
necessary additional technology to make this work (I'm thinking about the
event channel and the venue state - every node has the state and it lists
the set of "nodes" which is the set of entities that are sending and
receiving media).

It makes sense to me to leverage the event channel - it's there and if a
node can send periodic and change related events that contain the
information needed to correlate streams with nodes, then we don't have to
use any of the RTP/RTCP tags being discussed in the other parts of this
thread (although it might be convenient to stick some GUID in a field to
have a "standard non-RTP/RTCP identifier". The SDES note seems reasonable
for this though. Using CNAMES as you mention below seems quite a reasonable
alternative.

> 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.

It doesn't seem all that unreasonble to use what we call the user (or node)
publicId, which is intended to be a unique identifier for that entity. It's
used and passed around between venues and clients and everybody is allowed
to have everybody elses publicId.

--Ivan