应急指挥调度的应用场景有许多，如：消防指挥调度、交通指挥调度、应急救援等等。每个场景对功能的需求也略不相同，但是平台设计都有一个参照标准《根据国家应急平台体系技术要求》，以应急通信、应急处置为核心，预案数字化和应急分析为依据；系统设计遵循“平急结合，讲求实效”、“统筹规划，统一标准”、“分级实施，资源共享”、“技术先进，智能灵活”四大原则理念；
应急指挥调度平台大多包含了以下的系统功能：
- 灵活分组管理。根据内部组织架构或事件关联人，可在调度台上对成员进行快速分组，建立固定频道和临时会话，随时选择对应频道/会话发起音视频呼叫、视频监看、地图位置查询等操作；
- 无线集群。实现无线电台、网络电话、PSTN网络、智能手机、视频监控平台等音视频系统的语音调度、音视频群呼、广播调度、实时语音调度。
- 支持多级协同调度。提供上下级调度平台的权限分配及管理，可动态分配人员权限，满足分等级、分权限、多级指挥调度的需求。
- GIS 基础模块。具有查看终端用户的地图位置、设置自定义地图标注、地图基础工具包。
- GIS 调度模块。具有画圈成组，对圈中的终端用户进行呼叫、强插、强拆、视频监看、群呼等操作。
- 实时语音对讲。实时公网对讲，支持低延时、高并发、AI 降噪能力，支持群组/点对点。
- 实时视频。视频加密传输、支持查看终端用户上报的实时视频、实时监看终端用户视频、具有大屏呈现能力。
- 事件备案。支持视频监看、音视频录制、抓拍、支持视频分享、呼叫、群呼入会等操作。
- 设备绑定。实现帐号与设备绑定，后台支持设备摇毙、摇停等操作。
- 多媒体/实时视频上报。查看终端实时上传的多媒体信息，根据上报事件的类别，调度员协调处理事件。
- IM 模块。支持文字、视频、语音、图片、地图位置等消息类型。
- 等等
具体平台需要哪些功能取决于平台的需求了，下面我们就以调度平台的实时对讲、实时视频、IM/信令核心功能模块为例，讲解一下核心功能需要哪些技术支持？
实时语音对讲
首先，我们讲讲指挥调度中必不可少的对讲，再过去对讲几乎都是使用的无线信号的对讲机，由于信号不稳定、使用有距离限制等等，慢慢的由公网对讲技术所取代。尽管如此，在选择公网对讲时我们需要考虑的因素也有许多：
- 语音是否支持加密传输。语音内容是否易截获。
- 实时性是否有保障。是否支持 WebRTC。
- 是否支持弱网通讯。在网络信号不好时，抗丢包能力强不强。
这些都是选择语音对讲方案的性能指标。
在有了技术选择的性能指标、我们还需要支持：强插，强拆，这也就意味这，对讲还需要有对讲等级，等级高的可以打断等级低的用户。
同时，我们还需要对对讲语音进行录音备案，将录制的语音上传服务器，也可以将其作为一条语音消息发送到指定的群组，以便记录、防止消息丢失。
音视频呼叫
在应急指挥调度中，面对突发事件，我们可以选择事件关联人或者选择行动分队等前线人员，同时也可以邀请技术专家快速发起的音视频呼叫、对技术难题进行专项讨论分析并制定处理方案，从而大幅提高了应对突发事件的处理效率。
也就是说，在选择音视频呼叫解决方案时，我们需要从这几个方面考虑：
- 是否支持点对点发起音视频呼叫
- 是否支持一对多发起音视频呼叫
- 是否支持视频录制
- 是否支持音/视频开关
- 是否支持查看远程用户的音视频状态
- 支持视频转音频。（这里作为加分项）
上面介绍的这些需求包含了大多数应用场景，从平台的角度看，放佛没有任何问题，但是从程序的角度来看，耦合度太高，那么站在程序的角度，我们可以将以上方案拆分成两个方案：
一套呼叫邀请流程（非音视频呼叫）
我们可以使用 IM 或者信令封装一套呼叫流程，用于协助音视频通讯，在邀请发起到对方应答或者超时视为一次完整的生命周期，每次呼叫邀请只能使用一次，对方响应或者超时既毁。
一套音视频通讯方案
在应急指挥调度平台中，音视频通讯能力必须具备实时能力，在直播时代还未崛起之时，RTMP 作为主流的实时通讯协议，热度居高不下，直到 WebRTC 技术的崛起与应用，已然成为了实时通讯的首选。由于 WebRTC 只支持 P2P 通讯，为了让 WebRTC 支持多人通讯，WebRTC 也衍生出了三种：MCU、SFU、Mesh技术架构，其中 SFU 对网络带宽的限制以及对机器性能的要求最低，因此大受追捧。（至于这三大架构的利弊，本处不做过多阐述，感兴趣的同学可以自行查询。）
在选择音视频通讯方案的时候，我们需要考虑：
- 低延时。对比实时效果是否达到预期
- 视频分辨率是否可以调整。根据不同对应用场景，对实时视频的分辨率要求各不相同，比如在看人员时，可以查看该用户小流，大屏显示时查看用户大流。
- 音视频开关。在特殊负责的环境下，考虑到音视频是否要停止传输等。
- 硬件要求。软件或者服务对硬件的要求是否在预算之内。
- 房间人数是否满足需求。一个会议中可以多少人进行互动、允许多少人参与？
- 服务集群是否满足需求。服务是否地域覆盖，是否支持动态扩容等等？
IM / 信令服务
IM 想必大家都很熟悉了，除了支持文本、图片、视频、音频等类型以外，我们还可以自定义一些消息类型，大多时候我们自定义消息类型时都是方便业务的串联，因此上面我们提到的呼叫要求流程，也可以封装在其中。
在选择通讯方案的时候，我们需要考虑：
- 低延时
- 是否支持点对点消息、频道消息
- 服务集群是否满足需求。服务是否地域覆盖，是否支持动态扩容等等？
- 呼叫邀请流程。是否内置呼叫邀请流程？或者是否支持封装一套呼叫邀请流程?
GIS 地图
关于地图可以做的事情有很多了，常见的有：
- 实时定位。查看在线终端用户的地理位置，或者离线用户最后一次的地理位置。
- 自定义标注。在地图上添加一下自定义标注，例如：医院、学校、消防栓等等。
- 自定义工具：测距、面积
- 自定义图层：卫星地图、路网、3D、地图的主题等
进阶的有：
- 电子围栏。使用圆圈或者自定义形状绘制一块区域，该地区人员进出会发出警报。
- 轨迹回放。客户端定时上报地理逆编码位置以及经纬度，调度台按规矩还原出来。
- 画圈成组。使用圆圈或者自定义形状绘制一块区域，然后将该区域的人员选中并创建临时群组，或者进行群呼。
这里常用的有高德、百度地图、特定需求的还可以选择北斗。
总结
除了上面介绍的技术支撑，我们还需要提供一个强有力、安全可靠的服务，它基本需要具备：
- 集群部署、动态扩容
- 服务可靠，服务需要具备热备、容灾能力，以保证平台稳定性
- 实效性（实时），《根据国家应急平台体系技术要求》参照标准，发挥调度平台实效性，及时响应复杂突发急事件
- 灵活性，各个模块相互独立，方便业务拓展，要求代码耦合度低
- 事件存档，需要对突发事件或日常事件进行备案记录，保证调度台事件可溯性，方便后期工作分析
