[Live-devel] Custom RTSP options
Ross Finlayson
finlayson at live555.com
Sun Jan 23 14:34:26 PST 2011
>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/
More information about the live-devel
mailing list