[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