[吐槽]GB28181这个破协议

1、码流

1.1）ps码流

ps码流大华、海康部分机型不按照标准ps协议封包，导致协议解析困难，进而影响到服务稳定性。徒增工作复杂度。耗费大家资源和精力。

1.2）ssrc

ssrc各家在级联平台中有的直接默认为0，无法使用ssrc校验码流，导致串流问题频发

1.3）sdp

主动被动 tcp/udp多方式、多协议连接码流。但是GB21818就不想想在CS模式下，服务器主动连接设备有个屁用，导致部分机型对讲不好用或者只能在内网使用。无法统一产品行为。

1.4）rtp码流

1.4.1）无法避免的串流

rtp码流无法避免串流和异常码流攻击，即使采用ssrc校验也不能完全避免。

媒体服务可能接收不同上线服务下发的推流请求，导致ssrc可能一样。

ssrc存在设备上报和实际码流ssrc不一致的情况。ssrc也存在位0的情况，根本无法校验。

即使开启ssrc校验，ip校验也无法防止串流发生

启动大范围端口随机分配模式降低串流概率，例如：40000~50000端口范围，媒体服务器开放10000个端口，可以同时支持5000路推流(rtp、rtcp各占一个端口的情况)。但是在百万级设备场景下，每半年串流一次。

国标媒体协议风险过大，开放端口范围过大，容易收到异常码流攻击和端口扫描攻击。这个太垃圾了。

1.4.2）级联平台各家的坑

海康国标级联平台对接大华国标设备，rtp打包的是大华的私协码流，我吐血

海康、大华平台首个rtp包非流媒体包，应该是私自扩展的协议需要滤除，我尼玛

1.4.3）媒体保活

GB28181文档中，附录M提到了媒体保活，但是又没有规定媒体保活的形式，难道是不言自明的吗。我明的和你明的一样吗。导致各家保活方式各不相同，甚至连开不开其媒体保活都需要做个专门的开关。这不是浪费这是什么，这不是混乱这是什么，完全没有起到协议的作用

2、信令

2.1）setup:passive active

国标协议中指明是TCP连接方式；难道就不想想udp有没有主动被动。CS模式下，udp该平台如何建立和设备的连接呢？recvonly sendrecv recvonly只是表明数据的流向，并没有规定连接的建立方式

2.2）recvonly  sendrecv  recvonly

没有方向性，没有指明谁主动谁被动。谁发送的就代表谁的状态

3、加密

gb35114协议，初版在2009~2010年提出来。难道不能参照人家ssl协议用信道加密的方式传输信令和码流。对业务侵入尽量减小。现在看gb35114协议和原gb28181的信令对比，尼玛这是全新的交互协议了。

证书配置太过繁复，大大增加了开发和实装工作量和设备成本。

安全大家都需要，但是协议能不能考虑一下兼容性，能不能不要这么任性

gb25724协议基本上全篇说的都是SVAC，但是我们不能不承认SVAC和H264、H265系列有差距。ffmpeg中没有包含SVAC并且从开放的编解码库接口看目前也不支持GPU加速。我们所处的是什么时代，4K已经到来了，你让我用cpu去解码，我。。。。市场是抢来的，不是别人施舍来的，接地气很重要

总之国标协议造成的资源浪费惊人，造成的安全问题更惊人。协议本来是方便大家使用，提升流媒体对接效率的，但是现在看来这个协议达不到要求