我们在实现一套EasyNVR无插件直播方案时，选择了采用行业标准的通用协议RTSP/Onvif接入摄像机IPC摄像机 / NVR硬盘录像机设备，众所周知，Onvif是摄像机的发现与控制管理协议，Onvif用到的流媒体协议也是RTSP，那么，我们在摄像机NVR流媒体接入上，就是直接采用统一的RTSP协议接入；
然而，在RTSP协议上，由于各个厂家都有不同的处理方法，比如海康、大华、雄迈、宇视、天地伟业等厂家的RTSP地址规则就不一样，在有Onvif协议支持的设备还好一些，可以通过Onvif将摄像机的RTSP地址发现出来，但是遇到不支持Onvif的设备，就要自己拼接各个厂家的RTSP地址规则了，例如：海康、大华IpCamera RTSP地址和格式，雄迈/巨峰摄像机RTSP地址格式；
接入RTSP方面，目前市面上兼容性最强的两个组件：live555和ffmpeg，各有利弊，live555结构复杂、ffmpeg整体庞大，最终我们选择了以live555作为摄像机RTSP接入的方案，能非常方便实现部分功能的定制，例如本文重点提到的OPTIONS发送的问题：
当我们采用RTP over UDP/TCP方式在取流的过程中，RTSPClient（live555）可能长时间都在从RTSPServer（IPC/NVR）取流，但缺没有向RTSPServer发送保活报文，如果服务器端启动了Session保活检测机制（参看live555中RTSPServer中noteliveness实现），服务器端长时间没有收到客户端发送的数据包，就会认为客户端连接是假连接，主动断开与客户端的连接（不管客户端是否正在取流）；
所以，我们为了解决上述的问题，我们大部分的RTSPClient客户端都会定时（例如30s）向RTSPServer发送OPTIONS（有的也有可能发送的是GET_PARAMETER）命令，类似于保活报文，这样服务器端就能正常地发送直播数据流了；
然而，并不是所有的RTSPServer都做的那么好，就比如海康的某些IPC/NVR型号，当RTSPClient在拉流的过程中，突然发送OPTIONS保活报文，就像是发送了一个垃圾数据一样，RTSPServer自动就将整条RTSP连接断开了，导致RTP取流也随着停止了，我们只能在这类设备中，选择不发送OPTIONS保活包；
