應急指揮排程的應用場景有許多，如：消防指揮排程、交通指揮排程、應急救援等等。每個場景對功能的需求也略不相同，但是平台設計都有一個參照标準《根據國家應急平台體系技術要求》，以應急通信、應急處置為核心，預案數字化和應急分析為依據；系統設計遵循“平急結合，講求實效”、“統籌規劃，統一标準”、“分級實施，資源共享”、“技術先進，智能靈活”四大原則理念；
應急指揮排程平台大多包含了以下的系統功能：
- 靈活分組管理。根據内部組織架構或事件關聯人，可在排程台上對成員進行快速分組，建立固定頻道和臨時會話，随時選擇對應頻道/會話發起音視訊呼叫、視訊監看、地圖位置查詢等操作；
- 無線叢集。實作無線電台、網絡電話、PSTN網絡、智能手機、視訊監控平台等音視訊系統的語音排程、音視訊群呼、廣播排程、實時語音排程。
- 支援多級協同排程。提供上下級排程平台的權限配置設定及管理，可動态配置設定人員權限，滿足分等級、分權限、多級指揮排程的需求。
- GIS 基礎子產品。具有檢視終端使用者的地圖位置、設定自定義地圖示注、地圖基礎工具包。
- GIS 排程子產品。具有畫圈成組，對圈中的終端使用者進行呼叫、強插、強拆、視訊監看、群呼等操作。
- 實時語音對講。實時公網對講，支援低延時、高并發、AI 降噪能力，支援群組/點對點。
- 實時視訊。視訊加密傳輸、支援檢視終端使用者上報的實時視訊、實時監看終端使用者視訊、具有大屏呈現能力。
- 事件備案。支援視訊監看、音視訊錄制、抓拍、支援視訊分享、呼叫、群呼入會等操作。
- 裝置綁定。實作帳号與裝置綁定，背景支援裝置搖斃、搖停等操作。
- 多媒體/實時視訊上報。檢視終端實時上傳的多媒體資訊，根據上報事件的類别，排程員協調處理事件。
- IM 子產品。支援文字、視訊、語音、圖檔、地圖位置等消息類型。
- 等等
具體平台需要哪些功能取決于平台的需求了，下面我們就以排程平台的實時對講、實時視訊、IM/信令核心功能子產品為例，講解一下核心功能需要哪些技術支援？
實時語音對講
首先，我們講講指揮排程中必不可少的對講，再過去對講幾乎都是使用的無線信号的對講機，由于信号不穩定、使用有距離限制等等，慢慢的由公網對講技術所取代。盡管如此，在選擇公網對講時我們需要考慮的因素也有許多：
- 語音是否支援加密傳輸。語音内容是否易截獲。
- 實時性是否有保障。是否支援 WebRTC。
-
是否支援弱網通訊。在網絡信号不好時，抗丢包能力強不強。
這些都是選擇語音對講方案的性能名額。
在有了技術選擇的性能名額、我們還需要支援：強插，強拆，這也就意味這，對講還需要有對講等級，等級高的可以打斷等級低的使用者。
同時，我們還需要對對講語音進行錄音備案，将錄制的語音上傳伺服器，也可以将其作為一條語音消息發送到指定的群組，以便記錄、防止消息丢失。
音視訊呼叫
在應急指揮排程中，面對突發事件，我們可以選擇事件關聯人或者選擇行動分隊等前線人員，同時也可以邀請技術專家快速發起的音視訊呼叫、對技術難題進行專項讨論分析并制定處理方案，進而大幅提高了應對突發事件的處理效率。
也就是說，在選擇音視訊呼叫解決方案時，我們需要從這幾個方面考慮：
- 是否支援點對點發起音視訊呼叫
- 是否支援一對多發起音視訊呼叫
- 是否支援視訊錄制
- 是否支援音/視訊開關
- 是否支援檢視遠端使用者的音視訊狀态
- 支援視訊轉音頻。（這裡作為加分項）
上面介紹的這些需求包含了大多數應用場景，從平台的角度看，放佛沒有任何問題，但是從程式的角度來看，耦合度太高，那麼站在程式的角度，我們可以将以上方案拆分成兩個方案：
一套呼叫邀請流程（非音視訊呼叫）
我們可以使用 IM 或者信令封裝一套呼叫流程，用于協助音視訊通訊，在邀請發起到對方應答或者逾時視為一次完整的生命周期，每次呼叫邀請隻能使用一次，對方響應或者逾時既毀。
一套音視訊通訊方案
在應急指揮排程平台中，音視訊通訊能力必須具備實時能力，在直播時代還未崛起之時，RTMP 作為主流的實時通訊協定，熱度居高不下，直到 WebRTC 技術的崛起與應用，已然成為了實時通訊的首選。由于 WebRTC 隻支援 P2P 通訊，為了讓 WebRTC 支援多人通訊，WebRTC 也衍生出了三種：MCU、SFU、Mesh技術架構，其中 SFU 對網絡帶寬的限制以及對機器性能的要求最低，是以大受追捧。（至于這三大架構的利弊，本處不做過多闡述，感興趣的同學可以自行查詢。）
在選擇音視訊通訊方案的時候，我們需要考慮：
- 低延時。對比實時效果是否達到預期
- 視訊分辨率是否可以調整。根據不同對應用場景，對實時視訊的分辨率要求各不相同，比如在看人員時，可以檢視該使用者小流，大屏顯示時檢視使用者大流。
- 音視訊開關。在特殊負責的環境下，考慮到音視訊是否要停止傳輸等。
- 硬體要求。軟體或者服務對硬體的要求是否在預算之内。
- 房間人數是否滿足需求。一個會議中可以多少人進行互動、允許多少人參與？
- 服務叢集是否滿足需求。服務是否地域覆寫，是否支援動态擴容等等？
IM / 信令服務
IM 想必大家都很熟悉了，除了支援文本、圖檔、視訊、音頻等類型以外，我們還可以自定義一些消息類型，大多時候我們自定義消息類型時都是友善業務的串聯，是以上面我們提到的呼叫要求流程，也可以封裝在其中。
在選擇通訊方案的時候，我們需要考慮：
- 低延時
- 是否支援點對點消息、頻道消息
- 服務叢集是否滿足需求。服務是否地域覆寫，是否支援動态擴容等等？
- 呼叫邀請流程。是否内置呼叫邀請流程？或者是否支援封裝一套呼叫邀請流程?
GIS 地圖
關于地圖可以做的事情有很多了，常見的有：
- 實時定位。檢視線上終端使用者的地理位置，或者離線使用者最後一次的地理位置。
- 自定義标注。在地圖上添加一下自定義标注，例如：醫院、學校、消防栓等等。
- 自定義工具：測距、面積
- 自定義圖層：衛星地圖、路網、3D、地圖的主題等
進階的有：
- 電子圍欄。使用圓圈或者自定義形狀繪制一塊區域，該地區人員進出會發出警報。
- 軌迹回放。用戶端定時上報地理逆編碼位置以及經緯度，排程台按規矩還原出來。
- 畫圈成組。使用圓圈或者自定義形狀繪制一塊區域，然後将該區域的人員選中并建立臨時群組，或者進行群呼。
這裡常用的有高德、百度地圖、特定需求的還可以選擇北鬥。
總結
除了上面介紹的技術支撐，我們還需要提供一個強有力、安全可靠的服務，它基本需要具備：
- 叢集部署、動态擴容
- 服務可靠，服務需要具備熱備、容災能力，以保證平台穩定性
- 實效性（實時），《根據國家應急平台體系技術要求》參照标準，發揮排程平台實效性，及時響應複雜突發急事件
- 靈活性，各個子產品互相獨立，友善業務拓展，要求代碼耦合度低
- 事件存檔，需要對突發事件或日常事件進行備案記錄，保證排程台事件可溯性，友善後期工作分析