RTSP Criticisms

 RTSP suffers from attempting to produce a lowest common denominator standard, using extensions of a stateless protocol. Since the ordering of PLAY requests matters, the sequence numbers must be used to order the PLAY requests. In addition, the sending of a PAUSE request stops the stream, and places the server into a state where it must remember where the current position in the stream is. Allowing the control requests to be sent using UDP in which messages can be lost allows the possibility of the server and client locking when the stream is paused and the server loses a PLAY message. Hopefully these problems can be overcome by the user thinking their way around and repeating requests, but this is not satisfactory. When packets can be lost, there are no real substitutes for building a reliable transport protocol such as TCP.

More importantly, the protocol says nothing about the problems of recovering state over machine or software failure. Imagine the situation where a user is listening to a presentation at home on their PC, and some unlikely event occurs requiring the PC to be rebooted. The client software has now lost state and can no longer send any control messages to turn off the media streams. The media streams are high bandwidth and continue to occupy most of the incoming bandwidth into their home. What can they do? The current protocol doesn't describe how a session identifier can be recovered after state loss as in the soft state approach described above. The authors of the standard hope that implementations use a fail safe mechanism, relying on the media stream to remain live, or using dummy GET_PARAMETER messages to probe the liveness of the client.