[AG-TECH] room node certificates

[Ivan R. Judson]

> > This is almost exactly correct, with the added benefit that 
> the Node 
> > Service and Service Manager will hopefully be started at 
> system boot 
> > time automatically :-)
> > 
> 
> I guess if the Service Manager starts at boot time we really 
> need Audio and video services that don't start GUIs so don't 
> require anyone to be logged into the capture/audio nodes. 
> This is fine for the video-capture as nobody adjusts the 
> video settings by hand anyway. 
> For audio it is less clear cut as its often useful to tweak 
> the audio during a session. 
> Luckily there is an obvious solution. RAT already has 
> seperate processes for the GUI and the audio engine that 
> communicate via multicast packets. its a relatively minor 
> change to the source to allow the GUI and the audio engine to 
> run on seperate machines.

Right, in fact we have a headless video sender that we're working on
packaging up already, based on OpenMASH.  For audio, rat does have this
separation as you noted, and we're working on SWIG'ing UCL's libcommon
(which has an mbus component -- mbus is the protocol used to between the rat
ui and the rat media engine). We'd like to have that swig'ing done because
then we could also write python rtp/rtcp monitors for things (common also
has a very nice rtp/rtcp implementation). That being said, rat isn't the
only part of audio control we need to address, we need to address the genter
(or other echo-cancel hardware) so that it can be adjusted. I remember
someone did some perl based code for the gentner at one point, but I've lost
the pointer to it. We're looking at a pySerial based controller for the
gentner so we can make that a service as well.
 
> So what we need are seperate services for audio capture and 
> audio control so we can run the gui on the display machine 
> even if there is a seperate audio machine in the node.

Given the services we described above, the last bit (that I think you're
referring to here) is having some GUI controls -- we've been thinking of
this two ways, configuration stuff (more static) is done via node
management, interactive adjustments we're guessing happen via something
we're calling the operators panel (no we don't have it yet :-). The
operators panel should be able to be pointed at the local (or a remote) node
-- eventually, so that it might be possible for one node operator to manage
a set of nodes...we'll see...

--Ivan