背景
- 客户在打电话给客服（坐席）时需要保护自己的隐私（客户电话号码不能透传给客服）
- 客服在打电话给客户时可根据实际对应业务来设定是否进行号码透传（大部分场景是透传）
- 对一些业务提供基础数据的支撑（通话开始时间、结束时间、录音等）
- 不建立真正的实体呼叫中心，而是接入多个第三方提供的云通话服务完成实际通话过程，降低成本和风险
为此我们需要实现一个能够能够支撑业务实现并能够接入多个云通话服务渠道的系统，命名为 CC（Call Center，呼叫中心）。
架构设计
从呼叫模式上看，目前业界大多数采用的是“回拨”模式，即由呼叫中心发起两路呼叫，然后将两路进行连通。提供回拨服务的厂商比较多，比如玖云、华为、吉亚等，下面以玖云和华为为例进行架构设计。（选择玖云和华为主要是因为他们正好使用了不同的两种通话状态获取模式，玖云是回调，而华为是轮询）
（图片看不清的话请另存为后查看）
子模块
- Callback Logging：玖云事件回调持久化，实现上使用 NGINX 写文件日志
- Scheduled Task：华为事件轮询
- Dispatch & Handle：处理来自 Callback Logging 和 Scheduled Task 的通话事件
- Unified Call Records：统一格式的通过记录持久化存储
- Channel：提供给应用调用，完成“用户-坐席-渠道”的关联管理功能
- User-Agent-Channel：“用户-坐席-渠道”持久化存储
- Call：提供给应用调用，完成“回拨”功能
- Call Query：提供给应用调用，完成通话数据查询功能
- Health：渠道及回调日志健康状态检查，以及渠道故障时让 Channel 自动切换渠道
- Aliyun OSS：将获取到的通话录音上传到阿里云 OSS 进行存储
通话记录表
| 列名 | 类型 | 长度 | 备注 |
|---|---|---|---|
| id | bigint | 20 | 主键 |
| tenant | varchar | 32 | 租户标识 |
| main_num | varchar | 16 | 400 商户号码 |
| ext_num | varchar | 8 | 400 商户分机号码 |
| agent | varchar | 64 | 坐席标识 |
| call_id | varchar | 64 | 由渠道返回的话单 id |
| caller | varchar | 16 | 主叫（A 路）号码 |
| called | varchar | 16 | 被叫（B 路）号码 |
| biz_data | text | 业务数据 | |
| channel | varchar | 8 | 渠道标识：（玖云：e9；华为：hw；吉亚：jy） |
| ch_state | varchar | 32 | 渠道返回的话单当前状态 |
| state | varchar | 8 | 话单当前状态。初始化（发起呼叫 A 路）：init；双通：conn；关闭：close |
| a_call_time | bigint | 20 | 呼叫 A 路时间 |
| b_call_time | bigint | 20 | 呼叫 B 路时间 |
| a_offhook_time | bigint | 20 | A 路摘机（接通）时间 |
| b_offhook_time | bigint | 20 | B 路摘机（接通）时间 |
| conn_time | bigint | 20 | 双通时间 |
| close_time | bigint | 20 | 关闭通话时间 |
| duration | int | 11 | 通话时长（秒） |
| ch_audio_url | varchar | 512 | 渠道录音文件 URL |
| audio_url | varchar | 512 | 外部存储录音文件 URL |
| ivr_url | varchar | 512 | IVR 语音文件 URL |
| ivr_text | text | IVR 文本内容 | |
| close_type | varchar | 32 | 0：正常挂断；1：A 路无法接通；2：B 路无法接通；3：A 路目标忙；4：B 路目标忙；5：通话达到最大时长；6：渠道服务器错误；7：渠道网络错误；255：其他错误 |
| updated | bigint | 20 | 记录更新时间 |
| created | bigint | 20 | 记录创建时间 |
回拨流程
- 应用发起回拨请求，调用 Call
- Call 调用 Channel，有 Channel 选择适合的渠道，并通过公网 HTTP(S) 进行回拨请求
- 由渠道通过 PSTN 实现电话呼叫：
3.1 呼叫 A 路（客服），A 路摘机
3.2 呼叫 B 路（客户），客户摘机
3.3 A-B 接通进行通话
3.4 通话结束（A/B 挂断或异常）
- 在此期间需要接收事件回调（玖云）或进行事件轮询（华为）并持久化通话状态，最终形成统一格式的通话记录
- 回拨接口参数中可以带上业务实体标识，以便将通话记录和业务实体进行关联对应
- 回拨接口的返回值中会返回一个 callId，用来表示该次回拨，以便将通话记录和业务实体进行关联对应
- 在通话期间，应用可以使用 callId 来轮询 CC 查看通话状态
用户-坐席-渠道
这个模型用于描述业务系统中的用户实体以及坐席（可以理解为渠道提供的通话线路，同一时刻同一个线路只能有一通电话在拨打）的关联，并却定了这个用户所使用的通话渠道。
- 对于玖云，坐席对应的是电话号码
- 对于华为，坐席对应的是坐席号
默认情况下并不需要指定关联，CC 会自动选择渠道，只有在某些业务场景下需要应用来指定渠道。
以上都是我瞎扯的，实在编不下去了，欢迎大家分享真正的经验 :-p
PS：欢迎加入开源技术 Q 群 13139268，让学习和分享成为一种习惯！
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于