At the time of this writing, RTSP messages are generated all over the place. We try to fix that right now and to move all message creation code to the child classes of RTSP::Msg in komssys/rtsp/RTSPMsg.h. When that is complete, the creation of RTSP packets will be easily readable.
The actual sending of RTSP messages involves two steps: the TCP socket for RTSP is known to the RTSPFillBuffer class in komssys/rtsp/parser and it is used by calling one of several MsgOut functions. The MsgOut functions are called from different places in komssys/rtsp/server/Admin, komssys/rtsp/server/ProxyAdmin and komssys/rtsp/client/lower/rtsp.
When it is necessary to extend RTSP and SDP, this means changes to the RTSP and SDP scanners and parsers. When the RTSP header is extended, the information can usually be made available at the relevant places in the code by adding it to the ParseHeaderLines class in komssys/rtsp/parser/RTSPHeader.h. When SDP is extended, the information can usually be made available by extending SDPSessionDescription or SDPMediaDescription. These files are for now in komssys/rtsp/parser but they will soon be moved to komssys/sdp.
In some cases, it will be interesting to know in more detail how reception is handled. It will be inevitable to know and change these details if you want to add data transport through the RTSP control connection. It works roughly as follows:
- One thread uses a Unix select to wait for RTSP messages and probably some other events. The selector is encapsulated in an MNSelector object.
- When something arrives on the RTSP socket, the callback function RTSPFillBuffer::receiveIt is called. The function collects bytes until a double return is found that indicates a complete RTSP header. Such a double return may consist of 2 carriage returns, 2 line feeds or 2 of both. When such a double return is found, this is an indication that a complete RTSP header has been received. The RTSP parser is called with the buffer.
- The parser consists of RTSPScanner.l and RTSPParser.yyy. These are flex and bison++ input files. Do you need more information on the standard Unix tools lex and yacc? Flex and bison++ are variations of these tools that work with C++. Flex is GNU tool that is usually found wherever gcc is used. Bison++ is hard to find and the original had a tiny bug. Download a patched version from the komssys sourceforge pages
- To extend the RTSP header, you must change both RTSPScanner.l and RTSPParser.yyy. The parser is quite straight-forward. The scanner is slighly more complicated because we use context-depending scanning. For example, when a line starts with "Transport:", we switch to TRANSPORT_MODE scanning. Some strings, such as RTP/AVP, are identified as special words only in TRANSPORT_MODE but not in default mode. Without that differentiation, you could not write a URL with the string RTP/AVP in it.
- When the parser has identified a message type (SETUP, DESCRIBE, OK, ...), it uses a class called HeaderFactory to create a command object. We want three different reactions to commands: servers', proxies' and clients' reactions. For that reason, there are three different header factories, in komssys/rtsp/server/Admin/ServerHeaderFactory.h, komssys/rtsp/server/ProxyAdmin/ProxyHeaderFactory.h and komssys/rtsp/client/lower/rtsp/Admin/ClientHeaderFactory.h, respectively. Each creates different command objects. For each little bit of information that the parser finds in the RTSP message, the command object is updated. When the header is parsed completely, the parser returns.
- When the parser has returned without an error, it is checked whether the RTSP header had a "Content-length:" line. If yes, a body is expected. If the body has no arrived yet, we wait for more data. The RTSP message is not processed yet. Note that this is not efficient and should be changed. It must be changed for in-band streaming.
- If the type of the content is application/sdp, the SDP scanner and parser are called. They work roughly like the RTSP parser. In fact they have a lot of code in common but unfortunately code can't be shared among lex files. The other type is application/vcstream but that is deprecated. All other kinds of content are ignored for now.
- When all parsing is done, the function "call()" in the command object is called. This function is pure virtual, so in fact, you get calls to objects such as RTSPDescribeHeader::call() in komssys/rtsp/server/Admin or to RTSPProxyDescribeHeader::call() in komssys/rtsp/server/ProxyAdmin depending on the RTSP message and the kind of header factory that is in use.
- The calls with generally search for an appropriate session object and redirect the call to that object. This is where the real processing takes place.
Generated on Sun Mar 6 13:36:23 2005 for Komssys by
1.3.8