‍    ‍政务信息化项目上呼叫中心，最常卡住的不是功能，而是边界。

    ‍    ‍方案评审时，安全部门的问题往往只有一个：语音流走哪里？呼叫信令存在哪？话单数据落在哪？坐席要不要在每台云内终端装客户端？只要有一条数据流出了政务云边界，评审就可能被打回重来。

    ‍    ‍这篇文章介绍我们的政务云呼叫中心集成方案：全部系统部署在政务云内，语音流、呼叫信令、话单数据全程在云内闭环，不出云。

一、方案总览：两大区域，云内闭环

    ‍    ‍整个方案分为外部运营商侧与政务云部署区两部分。

    ‍    ‍外部仅涉及电信运营商线路——固话与手机用户的呼入呼出通道。线路进入政务云后，与云内的呼叫中心完成对接，此后所有语音、信令、话单交互全部在政务云内部完成。

    ‍    ‍政务云部署区包含三个核心模块：

    ‍    ‍呼叫中心：呼叫业务的调度核心，承载软交换、CTI/ACD 智能排队、IVR 语音导航、通话录音、话单存储、jsSDK 下发与 API 服务；

    ‍    ‍甲方业务系统：甲方既有系统，继续负责业务办理与坐席管理；

    ‍    ‍坐席端：坐席通过浏览器登录业务系统前端办公，不需要单独的客户端软件。

二、三个核心设计

1. 单机部署，全部能力集中在一台服务器

    ‍    ‍呼叫中心仅需一台服务器，即可承载软交换、排队、导航、录音、话单存储全部能力。对于政务云内资源审批严格、扩容流程长的项目环境，集中式部署意味着更简单的资源申请，和更清晰的安全评估对象。

2. 运营商线路两种接入模式，按实施条件二选一

    ‍    ‍方式一：运营商线路以 SIP 协议直连呼叫中心，信令与语音同链路传输，链路最短；

    ‍    ‍方式二：线路先接入部署在政务云内的中继网关，由网关完成线路汇聚与协议转换，再以 SIP 转接至呼叫中心，适用于需要线路汇聚或协议转换的场景。

    ‍    ‍两种模式按实际实施条件启用其一，接入点均落在政务云边界之内。

3. 坐席零客户端，浏览器即用

    ‍    ‍呼叫中心能力以 jsSDK 形式嵌入甲方业务系统前端页面。坐席用浏览器登录业务系统，即可直接接听、外呼：

    ‍    ‍语音通道采用 WebRTC：SRTP 加密承载语音流，WSS 加密承载呼叫信令，坐席与呼叫中心之间全双向通话；

    ‍    ‍呼叫、挂断、迁入、迁出、休息五类坐席操作，全部在页面内完成；

    ‍    ‍云内终端不需要安装、维护任何客户端软件。

三、与甲方业务系统的前后端双通道对接

    ‍    ‍集成方和甲方最关心的问题往往是"要不要改业务系统"。这套方案的答案是：不需要大改。

    ‍    ‍前端，jsSDK 随业务系统前端页面下发，坐席在熟悉的业务界面里完成通话与操作；后端，呼叫中心通过 HTTP API 将话单、呼叫记录主动推送同步至甲方业务系统，呼叫数据自动回流。业务办理、坐席管理仍留在甲方既有系统中，呼叫中心只做它擅长的事。

四、这套架构带来的业务价值

    ‍    ‍安全评审有清晰的边界可讲。 语音流、信令、话单数据全程不出政务云，线路接入点也在云内——方案的设计目标就是满足安全合规要求。数据流向一目了然，在安全评审、合规检查环节，不必为"数据去了哪里"反复解释。

    ‍    ‍集成改造成本低。 前端嵌 SDK、后端调 API，两条标准通道完成对接，不需要重构甲方业务系统。

    ‍    ‍终端运维负担轻。 坐席浏览器即用，免装免维护客户端，云内终端的管理压力小。

    ‍    ‍架构简单，评估对象清晰。 一台服务器承载全部呼叫能力，资源申请、安全评估、后续维护的对象都足够聚焦。

五、写在最后

    ‍    ‍政务云环境下的呼叫中心建设，难的不是功能堆叠，而是在严格的安全边界内，把通话、排队、录音、话单这些能力完整地"装进去"，同时让甲方的业务系统少动、坐席的终端轻下来。