问题：
各地市级视频及环境监控系统客户端中，预览站端相机A的视频时，正常情况下应仅显示该通道的监控画面。然而，当前出现异常现象：同一预览窗口内，除了相机A的视频外，还会间歇性播放下级站端相机B的视频画面，导致画面在相机A和相机B之间频繁切换。这种视频通道间的串流问题，严重影响了现场的正常使用。
排查：
2.1未看到对方上级的停止命令
1）【无预览停止命令情况】通过抓包和日志分析，站端收到预览开始命令，进行推送码流给地市平台的某个收流端口，此时预览正常。地市平台停止预览命令下发给站端，但是站端低概率收不到预览停止命令。地市平台即使关闭了udp端口，但是站端无法感知udp链路断开端口（udp不像tcp，不可靠的网络链路），站端会继续推流。此时地市平台又将此udp收流端口监听起来，并用于其他相机的取流，此时会出现同一个端口收到了两个相机的码流，故而导致串流。
解决方案：
由上级第三方来解决
2.2未处理上级的码流ACK回复
上级会回复码流ACK，28字节。
协议规范：码流心跳ACK回复
地市平台收到站端udp码流后，会在原链路回应相关数据给站端，此时站端未处理好此数据。当上级地市短时间内大批量的预览不同的相机，会高概率出现串流。正确的做法是当长时间收不到相关数据，则认为上级已经不需要此码流数据，我们作为下级应该关闭推流，这样可以解决串流问题。
解决方案：
和ncg框架组协商，由ncg_media将码流ack数据包利用对讲接口，回调给ncg信令驱动。我们信令驱动根据收到首次的ack回复进行计时，超时则，调用关闭预览接口。
2.2 频繁取流
通过信令日志发现，同一个监控点频繁开始和停止，且使用不同的端口。另外，还存在主子码流切换问题。
地市平台给每个下级平台分配二十个左右的端口，每个端口来收一路码流。当不再预览，则此端口重新分配给其他监控点预览使用。如果下级某个预览未及时关闭推流给上级，很容易出现同一个端口收到多路码流，这就会出现串流问题。
解决方案：
调整预览会话的管理机制，考虑到上级只有一个，同一个监控点只会取一路。将原先的map的key从 '监控点_收流端口'>改为'监控点_主子码流'
且当上级重复取流，则关闭之前的相同监控点的预览会话。（上一路很可能已经异常，可能是因为出码流慢，未收到上级的停止命令等）。
2.4 码流ACK计时超时失效
发现05秒506毫秒才返回预览成功，才会--udp--26144发流给上级10040端口，也才会记录此次的成功预览会话。
然而05秒482毫秒上级已经开始停止取流了，但是此时预览会话还在进行中，下级也无法将进行中预览会话进行关闭成功。如下图：
上级认为05秒482毫秒之前是没有取流成功的，所以05秒482毫秒后下发停止预览。因为中间的出码流慢，存在时间差，导致我们下级05秒506毫秒推送码流给上级，上级也不会回码流ack给我们，进而无法触发我们的码流ACK计时超时机制。
抓包也证明我们的推断：
有码流推送，但不回码流ack
解决方案：
将原先的收到首次ack回复作为起始时间，改为码流首次出流进行计时开始，避免上级未发ACK的。
备注：原先考虑可能有其他地市（其他厂家的上级）本身就不会回复码流ACK给下级，所以将首次ack回复作为起始时间。当其他厂家不支持回复，则不影响。但是，和现场进一步沟通确认，之前沟通有误，按规范来，要求上级一定要回复ACK。