移动端实时通信（RTC）支持

快速阅读

移动端 RTC 让 App、移动 H5、微信或企业微信里的页面发起和接听实时语音，并留下呼叫中心的话单。座席不一定坐在电脑前的座席工作台。

接入前先选一种鉴权：AccessToken 按 userId，AgentToken 按座席工号。两种不要混在同一次初始化里。

• 原生 Android、iOS 适合深度集成。小程序跳转适合轻量外呼。移动端 JS SDK 用于 H5。
• 初始化要用企业标识、userId 或座席工号、rtcEndpoint 和对应 Token。
• 登录并发是已登录 RTC 的用户数，通话并发是正在进行的 RTC 通话数。容量按企业开通核对。

阅读地图

一、文档说明

本文说明移动端 RTC 的产品接入：平台、鉴权、事件和并发。SDK 方法名、参数和错误码以当前版本文档为准，这里保留业务对象和页面上会看到的标识。

电脑浏览器里的软电话仍是座席工作台的一种绑定类型，见 座席绑定电话与外显设置。

二、产品总览

客户把 RTC 放进自有 App 或小程序后，用户或座席可以外呼、接受回呼邀请、静音、切换扬声器，并收到呼叫发起、接听、失败、挂断和网络变化。

通话结束后仍进入呼叫中心的记录、录音和统计。座席工号在使用 AgentToken、小程序跳转和报表时继续作为业务标识。

三、接入形态

各端的事件细节和版本要分别验证。一个端打通，不代替其它端的验收。

userId 在同一业务里保持稳定，并与签发 AccessToken 的逻辑一致。它不是座席工号。需要和员工、座席对应时，在客户侧维护映射。

rtcEndpoint 是连接 RTC 服务的访问地址，初始化时传入。

四、通话过程

原生 App 外呼：

服务端签发 AccessToken
→ App 用 userId、企业标识、rtcEndpoint、AccessToken 初始化客户端
→ 注册事件
→ 发起外呼
→ 收到呼叫发起、响铃、接通、失败、挂断
→ 话单和录音沉淀

接听回呼邀请：客户端已初始化并在听邀请 → 用户接受或拒绝 → 接受后进入通话 → 结束后释放会话。

小程序跳转：页面取得 AgentToken 或 AccessToken，带上企业、座席或用户、被叫号码、外显等参数，进入 RTC 外呼页完成鉴权和发起。使用 AgentToken 时传入座席工号。使用 AccessToken 时按 userId 识别。通话中避免长时间切到后台或锁屏。

静音、挂断、扬声器切换是通话中的客户端动作，和座席工作台通话条上的同名操作对应到移动端。

五、生命周期

AccessToken 有有效期，并和 userId 一起使用。有效期过短时，初始化或通话中刷新会失败。部分平台在即将过期时回调，由服务端签发新 Token，App 再刷新。过期后未刷新的，需要按平台能力重新初始化。

RTC 客户端是初始化之后的运行实例。经常使用的 App 可以在应用生命周期内复用；偶尔使用的，用完销毁。销毁之后要重新初始化才能再呼。

六、协同

移动端通话要进座席报表和录音时，优先使用带座席工号的 AgentToken，或保证 userId 与座席的映射在话单里能还原。

PC 座席工作台、分机、软电话可以和移动端并存。同一座席多端同时在线时，按企业的登录策略可能触发强制下线或「已在其他地方登录」。上线前约定哪一端是当前绑定。

外显号码、客户号码校验、录音开关仍走呼叫中心原有配置，不在 RTC 初始化参数里单独发明一套规则。

七、验收