Definition
RTSP (Real-Time Streaming Protocol) is a streaming media control protocol formulated by IETF, used for IP camera video stream pulling and playback control. Video edge analysis devices usually support protocols such as RTSP, ONVIF, GB28181 to connect cameras from brands like Hikvision, Dahua, Uniview, etc., to achieve local decoding and AI inference.
Protocol Features
RTSP is an application layer protocol based on TCP or UDP, with the default port 554. It supports commands such as DESCRIBE (to get SDP), SETUP (to establish transport), PLAY/PAUSE/TEARDOWN, etc. Media transmission usually uses RTP over UDP or RTP over RTSP. Video encoding is mostly H.264/H.265, and audio is G.711/AAC. The RTSP URL format is rtsp://ip:554/stream. Devices can be discovered and RTSP addresses obtained via ONVIF.
Use Cases
Video edge analysis devices pull camera video streams via RTSP, decode them, and send them into AI inference (object detection, behavior analysis, etc.), with results reported or cascaded to the GB28181 platform. NVRs, VMSs, and players all support RTSP. Compared to HTTP-FLV, WebRTC, etc., RTSP is mainstream in traditional security, with good compatibility.
Control Session and Media Transport
The control plane is established before the media plane
The real-time streaming protocol itself carries control commands, not pixels. The client describes what it wants, and the server returns a session description that states the codec, the clock rate, and the media channel. The two sides then agree which port will carry the pictures, and only then does playback start. Pictures are usually carried by the real-time transport protocol. They may travel as datagrams, or they may be embedded in the control connection. A control port that answers does not mean a picture will appear. When a firewall drops the media port, every control command succeeds and the player keeps spinning.
The path in the address corresponds to one configuration inside the camera. The main-stream path and the sub-stream path are different. A wrong path connects to the device and receives another channel, or it is rejected outright. The session is stateful. Sending play before transport has been set up should be refused by the server, according to the protocol. Keepalive depends on a query inside the session or on media packets. After a timeout the server tears the session down. If the client still sends commands to the old port, playback runs for a while and then drops.
The player has to be able to consume the media description
The condition for use is that the player or the analytics end really implements the codec and the transport the other side returned. If the description names a codec the decoder does not have, the session can still be established while the decoded output is a broken picture or silence. When timestamps are not continuous, a player that forces playback by arrival time stutters. An analytics box should confirm resolution and frame rate before pulling the stream, so a main stream is not fed into a process that does not have the compute. When the same path also has to be handed to a VMS for recording, decide whether to pull another stream or to forward from the box. Pulling the main stream twice uses up the camera's concurrent sessions.
It suits a relatively stable pull inside a surveillance LAN. Across several layers of address translation, the address negotiated for the media port may be the camera's private address. A player on the public network connects to that address, control succeeds, and media fails. Change the transport, or forward at the application layer on the boundary. Do not keep restarting the control port.
Authentication, ports, and keepalive
An authentication failure is often treated as a wrong address. Username and password are exchanged as a digest. If the clocks differ by too much, the digest fails and the camera returns 401. If the client only displays "connection failed," maintenance staff edit the path. Record the status code in the log. The second error is a port that is taken. After the default control port is changed, a scan still hits 554. The device is online and there is no session. The third is keepalive in opposite directions. One end expects media packets to refresh the timeout. The other stops media while paused. The session is torn down, and resuming playback has to start the whole sequence over.
Many clients pulling at once hit the camera's session limit. The picture opened later is black, and the one opened earlier becomes jerky as well. Limit the number of paths in the access design, and fix analytics tasks on the sub-stream. If nobody manages multicast addresses, two cameras push to the same group and the pictures cross. Finally, do not treat the control protocol as a file download that can be disconnected and reconnected at will. A reconnect has to describe, set up, and play again. Skip any step and a half-open session remains until the camera reboots and clears it.
Once the session limit is full, a new play request queues or is refused outright, and pictures already up do not report an error. Leave spare capacity in the access design for a maintenance preview, and make the current session list visible on the camera. Otherwise the only way to clear a stuck connection is to remove power.