[Live-devel] Custom RTSP options

[Wouter Verhelst]

On Sun, Jan 23, 2011 at 02:34:26PM -0800, Ross Finlayson wrote:
> >What I think we'd need is some way to (1) advertise (from the server
> >side) that a particular RTSP server would understand our custom tally
> >light command, (2) the possibility to send a tally command from the
> >client side, and (3) register a callback on the server that gets called
> >when that custom command has arrived.
> >
> >Am I mistaken in believing that isn't available?
> 
> The RTSP protocol does, indeed, have a mechanism to support the
> querying and/or setting of custom server parameters - namely, the
> "GET_PARAMETER" and "SET_PARAMETER" commands.  You should use those,
> instead of trying to extend the RTSP protocol in a way that no
> standard client or server would understand.
> 
> I.e., rather than trying to customize (modify) the RTSP *protocol*,
> you would instead be leaving the standard RTSP protocol 'as is', but
> instead defining custom *parameters* that clients could query and/or
> set using the standard "GET_PARAMETER" and "SET_PARAMETER" commands.

Right -- I was aware that there is a way to extend RTSP compatibly, I
was just not entirely clear on the specifics. So it's parameters that we
want to use rather than commands, okay.

> Our default RTSP server implementation - which we distribute in our
> released source code - implementes "GET_PARAMETER" and
> "SET_PARAMETER" as 'no-op's.  I.e., it responds to them with a "200
> OK" response, but doesn't actually do anything.  To change this, you
> should not modify the supplied source code, but instead *extend* it,
> using C++ subclassing.
> 
> Specifically, you would define your own subclass of "RTSPServer" and
> "RTSPClientSession", and reimplement the virtual function
> "createNewClientSession()" so that it creates and returns an object
> of your "RTSPClientSession" subclass.
> 
> Then, in your "RTSPClientSession" subclass, you would reimplement
> the virtual functions "handleCmd_GET_PARAMETER()" and
> "handleCmd_SET_PARAMETER()".

Great, thanks; that seems to be straightforward enough.

> > If so, could anyone
> >point me towards the necessary parts of the code that I should be
> >looking at? If not, I'll probably look into implementing this myself,
> >but it'd be nice to get some input on that first, so that I don't end up
> >writing something which would be refused.
> 
> As I noted above, you should be thinking about extending the
> existing library via C++ subclassing, rather than modifying it.

Note that I was only offering to implement anything if it wasn't
supported yet :-)

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html