RTSP and RTMP are routes for video to travel between the camera and the platform; the difference is direction. In RTSP, the platform goes to the camera to fetch the stream — which is why the camera has to be reachable over the internet. In RTMP, the camera pushes the video to the platform — which is why it works without a public IP, behind CGNAT. P2P is something else: a tunnel between the camera and the manufacturer cloud, built for the manufacturer app, which some platforms can use for specific manufacturers.
RTSP: the platform fetches the video from the camera
RTSP (Real Time Streaming Protocol) is the common language of CCTV: practically every professional IP camera, DVR and NVR speaks it. It works by "pull" — the platform opens the connection to the camera address (a URL in the form rtsp://user:password@address:554/path) and requests the stream. On recorders, the URL path says which channel you want.
The practical consequence defines everything: the camera needs an address reachable from outside. That means a static IP or DDNS at the site, plus a forwarded port on the router — or a VPN between the site and the platform. When that route exists, RTSP is excellent: low latency, exactly the quality the camera delivers and, because the connection is two-way, PTZ commands (pan, zoom, presets) travel back the same way.
Where it fails: CGNAT and dynamic IPs. Residential fibre, 4G and many ISPs hand out shared addresses, or ones that change constantly — the port rule looks right on the router and still the platform "calls" and nobody answers. It also fails where there is no router access (a sealed ISP box, third-party IT). And there is a security cost: a forwarded port is a customer port open to the internet, which calls for a strong password and extra care.
RTMP: the camera pushes the video to the platform
RTMP (Real Time Messaging Protocol) flips the direction. Born in live streaming — it is the classic way of pushing to broadcast platforms — it was adopted by cameras, DVRs and encoders as a "push" route: instead of waiting for someone to request the stream, the device sends the video to an address the platform generates, with a key unique to that camera.
Because the connection is outbound (TCP, port 1935), and practically every network allows outbound traffic, RTMP needs no public IP, no DDNS and no open port. It is the protocol that saves the install behind CGNAT, on 4G links and at sites where nobody has the router password. Latency sits slightly above RTSP but stays low; quality, as with RTSP, is whatever the camera is configured to send.
The limitations are just as concrete. First, not every device has RTMP — look in the camera interface for a menu called "RTMP", "Push stream", "Streaming platform" or "Live broadcast"; if it is not there, the model does not push. Second, it is one-way: the platform receives video but sends no commands — PTZ over RTMP does not exist. Third, many cameras accept only one push destination at a time. And because it streams continuously, RTMP consumes upload 24 hours a day, whether anyone is watching or not.
P2P: the camera talks to the manufacturer cloud
P2P is not a video transport protocol you register on a platform — it is the mechanism that lets the manufacturer app find the camera with no network configuration. As soon as it has internet, the camera opens an outbound tunnel to the manufacturer servers; the app reads a QR code or serial number and the cloud joins the two ends. That is why it became standard on consumer cameras: zero configuration.
The tunnel, though, is closed between the camera and that manufacturer cloud — by default only their app sees the video. Third-party platforms get in two ways: by enabling the RTSP many of those cameras also offer (buried in menus like "local protocol" or "third-party access"), or through the platform own P2P route when the manufacturer is supported — at Xeqmate, P2P registration uses the camera serial number, the RTSP port and the credentials, and a P2P-enabled server pulls the video through the tunnel, with no public IP. If the camera has neither RTSP nor RTMP and the manufacturer is not supported, it will not join any platform — the way out is replacing the device or wiring it to an NVR that exposes RTSP.
And ONVIF?
A frequent confusion: ONVIF is not a fourth video protocol. It is a standard for discovery and control — finding the camera on the network, listing the available streams, moving PTZ, reading events. The video itself travels over RTSP; in practice, "it has ONVIF" nearly always means "it has RTSP and tells me the right URL". So when evaluating platforms, treat "ONVIF support" as a configuration shortcut, not a video ingestion channel.
The three side by side
| RTSP | RTMP | P2P | |
|---|---|---|---|
| Who opens the connection | The platform goes to the camera | The camera pushes to the platform | The camera opens a tunnel to the manufacturer cloud |
| Needs a public IP / open port? | Yes (static IP or DDNS + port) or a VPN | No — outbound internet only | No |
| Works behind CGNAT / 4G? | No (without a public IP or VPN) | Yes | Yes |
| Commands (PTZ) | Yes — two-way | No — push only | Through the manufacturer app; on the platform, where supported |
| Device support | Practically every IP camera, DVR and NVR | Some models — check for an RTMP menu | Nearly all consumer models; many professional ones |
| Watch out for | A port exposed to the internet; requires router access | Continuous upload; one destination at a time | A tunnel controlled by the manufacturer; depends on platform support |
Which to choose in each scenario
- A site with a static IP or DDNS and router access → RTSP. Two-way, PTZ working, fine for any professional camera and for a DVR/NVR channel by channel.
- Residential fibre, CGNAT, 4G or an inaccessible router → RTMP, if the camera or recorder has the feature. You register the camera, the platform generates the push URL and you paste it into the device configuration — without touching the network.
- A camera that only talks to the manufacturer app → look for the option to enable RTSP in the firmware and go back to the first scenario; if the manufacturer is supported by the platform P2P registration, use that. With neither way out, the device cannot join.
- A DVR or NVR with several cameras → RTSP per channel, pointing at the recorder address, or RTMP per channel when the recorder offers push.
Notice that the choice is per install, not per platform: the same operation uses RTSP in the building with a static IP and RTMP in the shop on residential fibre. That is why it matters that the platform accepts both (and P2P for supported manufacturers) — as Xeqmate does in cloud video surveillance. The protocol changes the path of the video, not the image: recording, AI analytics and alerts work the same either way, and the events flow to your system over webhooks and integrations.
Not sure about your camera? In the free Xeqmate demo we connect one of your cameras live — RTSP, RTMP or P2P — and you see the video in the platform before deciding. Explore cloud video surveillance and the available integrations.