Integrating ONVIF, RTSP and GB/T 28181: Differences and Debugging Notes (2026)

Key takeaway: RTSP moves the stream, ONVIF discovers and configures the device, GB/T 28181 connects it to a national-standard platform. These are layers, not alternatives. When "the platform shows no picture", the cause is almost never the encoder — it is one of these three layers being out of alignment.

1. Who does what

Protocol	Problem solved	Typical user	Common misuse
RTSP / RTP	Streaming: deliver H.264/H.265 and audio on demand	Players, NVR recording, secondary development	Assuming RTSP alone makes a device discoverable
ONVIF	Discovery, capability negotiation, media config, PTZ, events	Third-party NVR, VMS, security platforms	Implementing discovery but not media or events
GB/T 28181	SIP-based access to a national-standard platform, unified cataloguing and dispatch	Public security, transport, campus platforms	Treating it as "another kind of RTSP"

A typical delivery requirement is all three at once: ONVIF for third-party NVRs, RTSP for integrators, GB28181 for the upper-level platform. Verify each link separately — a working web preview proves none of them.

2. RTSP: details decide whether the picture breaks up

• URL structure: rtsp://user:pass@ip:554/Streaming/Channels/101, with vendor-specific paths. Provide the exact main/sub-stream URL rules, not just "RTSP supported";
• Transport: UDP gives low latency but any packet loss shows as artefacts; TCP survives loss at the cost of latency and buffering. UDP on LAN, TCP across the internet is the usual compromise;
• RTP packetisation: H.264 FU-A fragmentation and SPS/PPS delivery (in-band or via SDP) must be correct. Get this wrong and the decoder has no parameter sets — stream present, picture absent;
• Timestamps: RTP timestamps must derive from the capture clock and increase monotonically. Faking them from wall time causes stutter and A/V desync;
• Session management: maintain DESCRIBE/SETUP/PLAY/TEARDOWN state correctly and reap abandoned sessions, or zombie sessions will exhaust the concurrent-stream budget.

3. ONVIF: more than being discoverable

• Discovery: WS-Discovery multicast (239.255.255.250:3702) answers Probe with service addresses. Multi-NIC devices must answer on the right interface, or platforms on another subnet never see them;
• Profiles: Profile S covers mainstream video and PTZ; Profile T adds H.265, dynamic streams and richer analytics events; Profile G covers recording playback. Confirm which profile the platform requires before implementing — shipping S when T is expected wastes a cycle;
• Media configuration: GetProfiles → GetVideoEncoderConfigurations → GetStreamUri is the canonical path. Resolution, frame rate, bitrate, GOP and codec must be configurable and take effect immediately;
• Authentication: support both WS-Security UsernameToken (with Digest) and HTTP Digest. Many platforms use only one; missing it looks like "discovered but cannot be added";
• Time: ONVIF is time-sensitive — large clock skew causes authentication failures and scrambled event timestamps. Support NTP and allow the platform to set time when there is no internet;
• Events: motion, tampering and alarm inputs must be reported through the event service, otherwise platform-side linkage and recording rules never trigger;
• PTZ: continuous move, absolute/relative positioning and presets are three separate interfaces — implement all three for PTZ products.

4. GB/T 28181: integration is the hard part

• SIP registration: the device acts as a SIP UA registering to the platform, handling expiry, refresh and Digest authentication. If registration fails, first check the device ID format and transport (UDP/TCP) against the platform;
• Device ID: the 20-digit national code has a strict structure (centre code, industry, type, sequence). One wrong digit and the platform rejects enrolment, often with a vague error;
• Catalog query: the platform sends Catalog; the device returns channel entries and status. Multi-channel devices (NVRs) must use channel IDs that are contiguous and match platform expectations;
• Live view: the platform sends INVITE, SDP is negotiated, and the device pushes RTP carrying PS. Program Stream encapsulation is the key difference — not raw H.264, but PES packets with system headers;
• Keepalive: periodic messages maintain online status; timeouts mark the device offline. Provide re-registration logic for network jitter;
• NAT and public networks: when the device is private and the platform public, SIP and RTP address mapping must be handled — TCP streaming or a signalling gateway may be required;
• Two-way audio and PTZ: these are extension capabilities. Confirm each per project; never assume "national standard means everything is supported".

5. Multi-platform compatibility in practice

• Implementation differences: the same ONVIF stack may work on platform A and fail on platform B due to optional fields, namespace versions or auth details. Packet captures are the only reliable way to localise it;
• Stream negotiation: platforms may force their own resolution/bitrate combinations; the device must switch without restarting the encoder;
• Do not leak proprietary behaviour into standard interfaces: returning private URLs or fields is convenient now and breaks on some platform later;
• Concurrency and bandwidth: simultaneous NVR recording, platform live view and client preview needs headroom in both encoder and network, otherwise "one channel stutters" becomes the field complaint.

6. What the system must provide

• Encoding capacity: plan concurrency from the SoC's real encode capability, not single-channel specs. Resolution, frame rate, GOP and rate control all consume budget;
• Network: even a gigabit port gets tight with several high-bitrate streams; RTP burstiness stresses switch buffers;
• Storage: NVR recording shares CPU and IO with the protocol stack; watch filesystem fragmentation and bad blocks over long runs;
• Stability: the stack must tolerate malformed packets, half-open connections and frequent reconnects — the most common long-run failure source.

7. Debugging

• Layer by layer: first confirm RTSP pulls in VLC/ffmpeg, then that ONVIF tools discover the device, then that GB28181 registers. Do not start by suspecting the encoder;
• Packet capture: Wireshark for SIP registration exchanges, RTSP method sequences, RTP sequence numbers and timestamp continuity. Artefacts almost always trace back to loss and sequence gaps;
• ONVIF tools: ONVIF Device Manager or the platform's own test tool separates "device problem" from "platform problem" quickly;
• Logs: stack logs must be levelled and carry timestamps and peer addresses — during integration this log is worth more than any verbal description.

8. Common pitfalls

• UDP only. Guaranteed artefacts across the internet, and impossible to explain on site;
• SPS/PPS only in SDP, never repeated in-band. Clients joining mid-stream get no parameter sets and show a black screen;
• Implementing only the ONVIF Device service. Discovered but not addable, because Media is incomplete;
• Device clock not synchronised. Auth failures, wrong recording timestamps and mismatched events all trace back to it;
• Guessing the national device code. The 20-digit format is structured; one wrong digit blocks enrolment, and platform errors are rarely explicit.

9. FAQ

• Q1: Does ONVIF support imply RTSP support? Not necessarily. GetStreamUri usually returns an RTSP URL, but implementations can be incomplete. Put both links in the acceptance criteria;
• Q2: Can RTSP replace GB28181? No. The national standard is a complete SIP signalling plus PS-over-RTP system; platforms catalogue and dispatch by it, and RTSP cannot substitute;
• Q3: Why does the same device behave differently across platforms? Standards mandate a minimum; optional fields and tolerance vary by vendor. Packet comparison localises it fastest, and platform-specific adaptation is sometimes necessary;
• Q4: How long does GB28181 integration take? It depends on platform cooperation and feature scope. Basic registration plus live view is comparatively quick; catalog, two-way audio, PTZ and cascade lengthen it noticeably — schedule it as its own line item;
• Q5: Can you handle the protocol integration? Yes. Hongyin Technology provides complete RTSP/ONVIF/GB28181 implementations and integration support on RK3588/RK3576/RV1126 platforms, including multi-platform compatibility validation. Send your target platforms and feature list for an assessment within 48 hours.

10. Related solutions & contact

Related solutions: Security NVR Recording、Camera Module Customization、Edge AI Box. Further reading: RK3588 Video Encoding & Streaming、NVR Channel Count & SoC Selection、IPC Customization Process.

Shenzhen Hongyin Technology Co., Ltd. (HONGYIN TECH) provides embedded project customization on RK3588/RK3576/RK3568 platforms — free requirement review, engineer-direct communication and low-volume ordering. Send your requirement list and receive selection advice and quotes within 48 hours.
phone +86 13728726926 | email sales@hoyin-tech.com | website www.hoyin-tech.com | address: Room 301, Building A, Fanrong Science Park, Sanwei Community, Hangcheng Street, Bao'an District, Shenzhen, China.