告警之后，养老应急真正缺的是确认和接手
很多养老平台已经能做异常识别。比如跌倒检测、离床异常、烟感报警、长时间未活动、紧急呼叫等，都会把事件推送给家属或服务人员。
但告警只是开始。
老人跌倒后可能无法操作手机，也可能听不清电话铃声。AI 检测可能误报，需要人工快速核实。家属可能离线、静音、占线，或者看到消息时已经过了几分钟。监控中心即使看见画面，也未必能立即和老人沟通，确认意识、疼痛、位置和现场环境。
所以，应急系统不能只停在"推送一条告警"。它要回答更具体的问题：
- 告警是真是假
- 老人现在能不能回应
- 家属是否接通
- 谁是当前处置责任人
- 是否需要护理人员上门
- 处置过程有没有记录
养老监控是"设备到人"的单向提醒，养老应急需要的是"事件到服务"的闭环。
一次居家养老应急，关键在前五分钟
真正有价值的设计，不是把流程画得很长，而是把告警后的前几分钟做清楚。
一个可落地的应急事件，可以这样流转：
| 环节 | 系统要做什么 | 目的 |
|---|---|---|
| 触发告警 | 摄像头、雷达、手环或呼叫器上报异常 | 发现可能风险 |
| 生成事件 | 平台生成事件编号、判断等级和老人信息 | 让事件可追踪 |
| 视频核实 | 呼叫老人端陪护屏、摄像头终端或智能设备 | 快速确认现场 |
| 通知家属 | 向家属 App 或护理坐席发送呼叫邀请 | 找到第一响应人 |
| 协同处置 | 必要时邀请第二位家属、医生或护理人员加入 | 共同判断是否救援 |
| 线下跟进 | 无人接听或高风险时升级到社区、护理员或线下救援 | 防止事件悬空 |
| 结果留痕 | 写回接通结果、处置人员、耗时和处理结论 | 便于复盘和责任交接 |
这里最重要的是"不要让告警停在消息通知"。消息通知可以提醒人，但视频通话能更快确认老人状态。多人协同能让家属、护理人员和服务机构在同一个事件里沟通，而不是各自打电话、截图、转述。
监控继续做监控，RTC 只在事件中接管沟通
养老场景不需要把所有监控画面都改成 RTC，这样也会抬高成本。
日常查看、录像、回放、巡检，继续交给原有摄像头监控链路更合适。监控链路擅长长期在线、设备管理、录像留存和低成本查看。
RTC 更适合在事件发生时介入。比如跌倒告警、一键呼叫、烟感报警、长时间无响应，平台需要快速建立一个实时沟通房间，让老人端、家属端、护理坐席按权限进入。
这两条链路可以这样分工：
| 链路 | 适合做什么 | 不建议承担什么 |
|---|---|---|
| 监控链路 | 日常查看、录像、设备管理、异常检测 | 不适合承担复杂多人沟通 |
| RTC 链路 | 事件核实、双向沟通、多人协同、临时处置 | 不适合全天替代监控画面 |
| IM / 信令链路 | 呼叫邀请、离线通知、状态同步、超时处理 | 不适合直接传输音视频 |
| 业务事件系统 | 告警分级、责任人、处置记录、升级路径 | 不适合只做前端提示 |
以即构科技能力为例，Express Video 音视频 SDK 可以承载一对一或多人音视频通话，ZIM 呼叫邀请可以处理发起、接受、拒绝、取消、超时和离线用户通知。Token 可以用于控制老人、家属、护理人员的进房和推拉流权限。星图质量工具可以帮助监测接通率、进房耗时、首帧耗时和通话流畅度。
养老应急最怕三件事：听不见、接不上、没人接手
养老视频通话和普通视频通话不一样，它首先是一个应急服务入口。
第一，弱网时要优先保证声音可用。画质可以下降，但不能轻易中断沟通。老人可能只需要听到"您先别动，我们已经联系家属"，这句话比高清画面更重要。
第二，呼叫要有多级兜底。家属不接时，系统不能只提示失败，而要继续通知备用联系人、社区坐席或护理人员。ZIM 呼叫邀请这类能力的价值，就在于能把接受、拒绝、取消、超时、离线等状态纳入流程设计。
第三，处置必须有人接手。视频只是核实手段，真正的结果要落到护理或救援服务上。事件结束后，接通结果、参与人、处理时长、处置结论要回写到养老平台，而不是停留在一通电话里。
还要注意授权边界。比如自动接通老人端设备，只能在明确授权和特定告警条件下使用；是否录制通话，也要提前定义规则、告知范围和保存期限。
养老平台如何接入呼叫和视频通话能力
在养老场景里，跌倒告警后的系统能力可以拆成两部分：一部分由开发者或养老平台自己建设，另一部分由 RTC SDK 厂商提供底层通信能力。
开发者或业务方通常负责业务闭环：告警规则、老人档案、设备绑定、联系人关系、服务派单、护理记录、权限策略和线下救援。谁需要被服务、谁负责接手、事件是否完成、记录如何回写，都应该由养老平台或机构系统来决定。
RTC SDK 厂商负责把关键角色实时连接起来：在告警触发后，让家属 App、护理端、坐席端或负责人端能够收到呼叫，进入音视频通话，必要时多人协同，并持续观察通话质量和权限边界。当开发者已经明确业务链路后，底层实时通信能力可以交给即构科技这类 RTC SDK 厂商承接，对应到产品能力上，就是 ZIM 呼叫邀请、实时音视频 RTC SDK、RTC 房间和角色控制、网络质量回调、星图和 Token 鉴权。
| 链路位置 | 可以接入的即构能力 | 能力说明 |
|---|---|---|
| 告警后要先找到家属或坐席 | ZIM 呼叫邀请 | 从养老平台向家属 App、坐席端或护理端发起呼叫，并处理接听、拒绝、取消、超时和离线通知 |
| 需要快速确认老人状态 | 实时音视频 RTC SDK | 支持一对一或多人音视频通话，用于查看现场、确认老人意识状态、持续安抚和沟通 |
| 护理人员、家属、负责人需要同时接入 | RTC 房间、角色和流控制 | 以事件为粒度创建临时房间，让不同角色按权限进入同一处置现场 |
| 平台要判断这次通话是否顺畅 | 网络质量回调、星图 | 观察进房耗时、首帧耗时、卡顿、丢包等指标，帮助平台做运维监控和事件复盘 |
| 老人端设备和家属端需要权限边界 | Token 鉴权 | 约束谁能进房、谁能推流、谁能观看，配合平台自己的账号、设备和授权规则 |
如果正在做居家养老设备、养老院护理平台或应急呼叫系统，可以结合实时音视频 RTC SDK 文档和ZIM 呼叫邀请文档拆分老人端、家属端和服务调度系统的接入方式。
FAQ
摄像头已经能语音对讲，为什么还要接 RTC？
摄像头语音对讲通常适合点对点沟通。养老应急往往需要呼叫邀请、多人协同、家属离线通知、护理坐席加入、事件状态回写和质量监测，RTC 和 IM 能把这些能力做成完整处置链路。
家属不在线时如何保证呼叫能够被看到？
需要设计多级通知和超时升级。比如先呼叫第一联系人，超时后通知备用联系人、护理坐席或社区服务人员，同时把离线、拒接、超时状态写入事件系统。
是否需要全天使用 RTC 传输监控画面？
通常不需要。日常查看和录像可以继续使用监控链路，RTC 更适合在告警、一键呼叫和应急处置时按需建立实时沟通房间。
老人没有智能手机能不能使用？
可以考虑陪护屏、养老摄像头、智能音箱、呼叫器或带屏终端。关键是老人端操作要足够简单，家属端和护理端则可以通过 App 或工作台接入。
告警视频和通话内容是否需要录制？
要看业务规则、授权范围和隐私要求。养老场景涉及老人居室、健康状态和家庭信息，录制、保存期限、查看权限都应提前设计，并经过合规复核。
小结
居家养老除了把监控换成通话，也需要告警之后补上一条能接通、能沟通、能升级、能留痕的应急链路。即构的 RTC、ZIM 呼叫邀请、Token 权限和星图监测，可以作为这条链路里的实时互动底座，但最终仍要和养老平台的事件、人员、护理和救援服务打通。