某地市消防救援支队如何通过iSoftCall实现全媒体智能呼叫中心

引言：2023年秋，某地市消防救援支队的指挥大厅里，一场静悄悄的变革正在发生。没有停机割接的惊心动魄，没有推倒重来的大动干戈，一套运行了8年的119接处警系统，在保留原有硬件和业务逻辑的前提下，完成了向全媒体智能呼叫中心的蜕变。

本文以该项目为蓝本，深度还原一个典型的三线城市消防支队，如何用45天时间、不到原预算30%的成本，实现信创合规、AI赋能、全媒体接入三大目标。希望能为正在寻求存量系统升级路径的集成商和消防信息化负责人，提供一个可复制的参考样本。

一、项目背景：老旧系统的三重困境

1.1 系统概况

该支队119接处警系统建于2016年，采用某厂商基于CTI板卡的方案：

硬件：工控机+数字中继板卡

软件：C/S架构，Windows Server 2008 + SQL Server 2008

功能：语音接警、GIS定位、短信通知

终端：模拟话机坐席

1.2 面临的困境

困境一：硬件老化，备件难寻

运行7年的工控机多次出现死机，原厂商已停止技术支持，关键板卡一旦损坏，系统将陷入瘫痪。

困境二：政策合规压力

根据上级要求，2025年前必须完成国产化替代，现有Windows+SQL Server架构无法满足信创要求。

困境三：业务需求升级

上级部门推广“全媒体接警”，要求支持微信报警、视频通话；同时要求引入AI辅助接警，提升效率。老系统显然无力支撑。

1.3 初始方案碰壁

支队最初调研了两家头部厂商的替换方案：

方案A：全套新建，预算280万，工期6个月

方案B：软硬件升级，预算190万，工期4个月

财政审核意见：预算超限，暂缓。

项目陷入僵局。

二、转机：中间件方案的引入

2.1 第三方建议

在一次技术交流中，本地一家集成商提出了“中间件改造方案”：

保留现有坐席终端、保留现有业务数据库、保留现有中继线路

仅增加一台服务器部署智能中间件

通过中间件实现国产化适配和AI能力注入

预估成本：60-80万，工期：2个月

2.2 方案评估

支队组织专家对中间件方案进行技术论证，重点关注三个问题：

Q1：能否实现信创合规？

中间件方案采用分层适配：

•新增服务器部署麒麟系统+达梦数据库

•原业务系统数据通过中间件同步至达梦库

•上层应用逐步改造，最终实现全栈国产化

专家结论：技术上可行，且风险可控。

Q2：AI能力是否够用？

中间件集成能力清单：

•实时语音转写+要素提取

•视频接入（微信小程序/短信链接）

•智能辅助弹屏

•离线录音质检

专家结论：满足当前需求，且支持扩展。

Q3：与原系统如何对接？

中间件通过SIP协议与原交换机对接，业务系统只需修改少量API调用，无需改动核心代码。

专家组最终通过方案，建议试点。

三、项目实施：45天的“微创手术”

3.1 第一阶段：环境准备（10天）

硬件就位：新增2台国产服务器（鲲鹏920芯片），预装麒麟操作系统

软件部署：部署iSoftCall智能呼叫中心中间件

网络打通：中间件服务器与原有交换机、业务服务器网络连通

3.2 第二阶段：信创适配（15天）

•数据库迁移：

原SQL Server中历史数据通过ETL工具同步到达梦数据库

业务系统修改数据库连接配置，读写分离（读原库+写新库逐步过渡）

•应用服务器适配：

业务系统从Tomcat迁移至东方通TongWeb

修改部分JDBC驱动和SQL方言（如分页语法差异）

•中间件配置：

配置SIP trunk对接原交换机

配置ASR引擎（选用讯飞消防专用模型）

配置质检规则和实体词库

3.3 第三阶段：AI能力上线（12天）

•智能接警模块：

配置实时语音转写通道

训练实体词提取模型（基于本地历史录音优化）

开发自动填单接口，对接原业务系统

•视频接入模块：

部署视频网关，支持H5页面和小程序接入

配置视频流存储策略（7天循环覆盖）

•智能辅助弹屏：

开发弹屏接口，根据识别结果自动调取周边资源信息

配置GIS图层叠加

3.4 第四阶段：联调测试（8天）

功能测试：模拟各类警情，验证语音识别准确率、视频流畅度、弹屏响应时间

压力测试：模拟10路并发通话，同时开启质检和视频，系统CPU峰值65%

业务验证：原系统厂商配合验证，确保原功能100%正常

3.5 正式割接

选择一个业务量较低的周末，切换语音中继至中间件，观察2小时后无异常，宣布上线。整个过程平滑无感，坐席端甚至没察觉到系统已经变了。

四、实施效果：三个“超出预期”

4.1 信创合规：一次通过测评

上线后第三方测评机构进场，逐项验证：

芯片：鲲鹏920（通过）

操作系统：麒麟V10（通过）

数据库：达梦V8（通过）

应用服务器：东方通TongWeb（通过）

测评结论：符合信创替代要求。

4.2 效率提升：数据说话

上线三个月后，支队统计对比数据：

指标

改造前

改造后

变化

平均接警填单时间

71秒

28秒

缩短60.6%

关键信息遗漏率

6.8%

2.1%

下降69%

视频接入率

23%

新增能力

坐席培训周期

坐席培训周期

3个月

缩短50%

4.3 成本控制：省下真金白银

实际支出：76万（硬件15万+软件授权32万+集成服务29万）

对比新建方案280万：节省73%

对比常规升级190万：节省60%

五、为什么能成？——关键成功要素复盘

5.1 技术选型：中间件模式

核心是选对了iSoftCall智能呼叫中心中间件。它的价值在于：

•蔽底层差异：统一封装通信协议、AI引擎、数据库适配

•模块化集成：可分步引入AI能力，避免一次性投入过大

•兼容存量：全面兼容原有IVR、ACD、坐席监控、API接口

5.2 实施策略：分步走，不贪大

项目分为四阶段，每阶段目标明确、风险可控：

先做信创适配，保障合规底线

再做AI赋能，创造业务价值

最后平滑割接，确保业务连续

5.3 团队配合：原厂商+集成商+中间件三方协同

原厂商：开放接口，配合联调

集成商：统筹项目，负责实施

中间件厂商（朗深）：提供底层能力和技术支持

六、经验总结：给类似项目三个建议

6.1 不要把“信创”和“智能化”做成两件事

很多单位先做信创替换，再做智能化升级，耗时耗力。本项目的启示是：中间件可以一次完成两者——适配国产化底层的同时，注入AI能力。

6.2 存量改造，先问三个问题

硬件还能用吗？（本案例中坐席终端利旧）

业务逻辑复杂吗？（本案例中原业务系统改动小）

预算有多少？（本案例中不足百万）

如果答案符合“硬件尚可、业务复杂、预算有限”，中间件模式是优先选项。

6.3 选中间件，看三点

兼容性：是否支持多种国产芯片、操作系统、数据库

开放性：是否支持对接多家AI引擎（避免被单一厂商绑定）

案例积累：是否有同行业成功案例（本案例参考了四川、攀枝花等地实践）

这个案例告诉我们，消防呼叫中心的智能化升级，未必需要伤筋动骨的大手术。在合适的场景下，一场精准的“微创手术”——通过iSoftCall这样的智能呼叫中心中间件——同样可以达到根治顽疾、焕发新生的目的。

对于全国数百个面临同样困境的地市级消防支队，这条路或许值得认真考虑。