The unreasonable phenomenon of the docking of the video surveillance security platform - the national standard 28181 platform and the Haikang national standard 28181 platform
The problems encountered recently when connecting the project with the Haikang platform: 1. The video will be disconnected after 30s of requesting the video. 2. The error of 488 was not queried and answered when on-demand or downloading.
First of all, let's talk about the problem that the request video will be disconnected within 30 seconds: because of this problem when connecting with Hikvision in the past few years, it is no problem to directly ask Hikang to turn off rtcp. Kang has fixed this issue. It appeared again this time, and I have communicated with Hikvision R&D for a long time. I have never figured out why Hikvision uses rtcp as the streaming media saturation standard. The national standard 28181 is the standard that clearly stipulates the streaming media keep alive, so Hikvision must be allowed to Modify this question.
Let me first talk about the reasons why I object to using rtcp as the streaming media keep-alive mechanism: 1. Since rtcp is used, both parties must agree on the rtcp streaming media port in the invite protocol (the national standard only uses one port, the national standard 28181 must be 2. There is no rtcp package for a national standard 28181 detection tool in a public security institution. 3. The standard of the national standard 28181 standard clearly stipulates the standard of the streaming media keep-alive mechanism as shown below:
Therefore, I suggest that the manufacturers of the national standard should follow the standard of national standard 28181.
The second question is that historical video on demand and download must be queried before downloading. I have also argued with Hikvision's technology for a long time about this issue. The national standard 28181 does not require inquiries before on-demand and download, and it is useless. It means to first determine whether the video exists (when I raised an objection, I carried the start time and end time, why can't I use this time).
So I think every manufacturer should follow the national standard 28181 standard. Although the standard is not very complete, the national standard 28181 standard has become more and more perfect. In order to implement and comprehensively standardize, you must first follow the standards.
Let's talk about the pit that recently appeared in the docking between City Bureau B and Uniview's national standard 28181 platform: when requesting video, the tcp stream is used to request the video, and the tcp stream sent by Uniview is as follows:
Looking at the packet capture, the sent tcp stream follows the RFC2326 standard (rtsp's tcp stream standard), and the national standard 28181 tcp stream standard follows the RFC4571 standard. Currently, we are still communicating with Uniview Technologies about this matter. ...
Briefly talk about the difference between the two standards:
RFC2326 standard format: $+length+RTP header+data
RFC4571 standard format: length + RTP header + data