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.
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()".
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.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
