Knowlegde Through Fun Welcome To Mady's Site.

Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security considerations outlined in apply.
Authentication Mechanisms:
RTSP and HTTP share common authentication schemes, and thus should follow the same prescriptions with regards to authentication.
Abuse of Server Log Information:
RTSP and HTTP servers will presumably have similar logging mechanisms, and thus should be equally guarded in protecting the contents of those logs, thus protecting the privacy of the users of the servers.
Transfer of Sensitive Information:
There is no reason to believe that information transferred via RTSP may be any less sensitive than that normally transmitted via HTTP. Therefore, all of the precautions regarding the protection of data privacy and user privacy apply to implementors of RTSP clients, servers, and proxies.
Attacks Based on File and Path Names:
Though RTSP URLs are opaque handles that do not necessarily have file system semantics, it is anticipated that many implementations will translate portions of the request URLs directly to file system calls. In such cases, file systems SHOULD follow the precautions, such as checking for ".." in path components.
Personal Information:
RTSP clients are often privy to the same information that HTTP clients are (user name, location, etc.) and thus should be equally.
Privacy Issues Connected to Accept Headers:
Since may of the same "Accept" headers exist in RTSP as in HTTP with regards to their use should be followed.
DNS Spoofing:
Presumably, given the longer connection times typically associated to RTSP sessions relative to HTTP sessions, RTSP client DNS optimizations should be less prevalent. Nonetheless, the recommendations provided are still relevant to any implementation which attempts to rely on a DNS-to-IP mapping to hold beyond a single use of the mapping.
Location Headers and Spoofing:
If a single server supports multiple organizations that do not trust one another, then it must check the values of Location and Content-Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority.
The following are added considerations for RTSP implementations.
Concentrated denial-of-service attack:
The protocol offers the opportunity for a remote-controlled denial-of-service attack. The attacker may initiate traffic flows to one or more IP addresses by specifying them as the destination in SETUP requests. While the attacker's IP address may be known in this case, this is not always useful in prevention of more attacks or ascertaining the attackers identity. Thus, an RTSP server SHOULD only allow client- specified destinations for RTSP-initiated traffic flows if the server has verified the client's identity, either against a database of known users using RTSP authentication mechanisms (preferably digest authentication or stronger), or other secure means.
Session hijacking:
Since there is no relation between a transport layer connection and an RTSP session, it is possible for a malicious client to issue requests with random session identifiers which would affect unsuspecting clients. The server SHOULD use a large, random and non-sequential session identifier to minimize the possibility of this kind of attack.
Authentication:
Servers SHOULD implement both basic and digest authentication. In environments requiring tighter security for the control messages, the RTSP control stream may be encrypted.
Stream issues:
RTSP only provides for stream control. RTSP implementations will most likely rely on other protocols such as RTP, IP multicast, RSVP and IGMP, and should address security considerations brought up in those and other applicable specifications.
Persistently suspicious behavior:
RTSP servers SHOULD return error code 403 (Forbidden) upon receiving a single instance of behavior which is deemed a security risk. RTSP servers SHOULD also be aware of attempts to probe the server for weaknesses and entry points and MAY arbitrarily disconnect and ignore further requests clients which are deemed to be in violation of local security policy.