请求形态
我们向你注册的cb_url 发 POST 请求，事件名同时出现在查询参数与请求体里：
data，外层三个字段恒定。time 是事件发生的秒级时间戳。
验签（务必做）
回调请求头带的签名与调用服务端 API 时的算法完全一致（见概览）， 只是方向相反：这次是我们用你的app_key 签名，你来验。请求头为 app_id / nonce / timestamp / signature。
不验签意味着任何人只要知道你的回调地址就能伪造事件，请不要跳过这一步。
应答要求
- HTTP 状态码必须为
200 - 响应体必须是标准 JSON：
{"code": 0} - 我们的请求超时为 10 秒，你的处理逻辑要在此之内返回（重活请异步化）
code 非 0，都会被记为一次失败。
事件一览
user_enter — 用户进入会议
role：0 普通成员、1 主持人、2 联席主持人。
同一个 user_id 在多端进会时，每一端都会触发一次。
user_exit — 用户离开会议
比 user_enter 多两个字段：
reason：1主动离开、2被踢、3被顶号、4心跳超时、5会议销毁、6身份变成观众online是该用户离开后会中的在线人数，0意味着人走空了
online == 0 判断「会议实际空了」比自己维护计数可靠。
meeting_status_change — 会议状态变化
1 未开始、2 进行中、3 已结束。带上 from_status 是为了让你能区分
「正常开始」（1→2）与「异常重开」这类情况。
mcu_status_change — 录制任务状态变化
task_type按位组合，取值见云录制与直播接入指南task_status：0待开始、1进行中、2待结束、3异常结束、4正常结束err_desc只在task_status=3时有内容record_count/total_duration/total_size是本次录制产出的文件数、总时长（秒）、总字节
0 和 2 是过渡状态，业务侧一般只需要关心 1（开始了）、3（出错了）、4（结束了）。
任务结束时这条事件里的 record_count 往往还是 0：录像文件要等任务结束后才开始转码上传。
全部文件传完后会再补发一条本事件，那一条的计数才完整。
mcu_record_done — 一个录像文件已就绪
task_status 变成 4（正常结束）时文件
往往还在转码上传，此时取地址可能拿不到东西。
一场会议的一次录制会产出多个文件，本事件按文件推送。 录制超过分片上限（默认 1 小时）
会按时长切段，录制中途中断后被续上也会另起一段。因此：
- 取播放地址用
record_id，不是task_id，见单个录像文件的点播地址 seq从 1 开始，按它排序即播放顺序；offset_ms是相对整场录制开始的偏移（毫秒），做连播用reason：1按时长切段、2中断后续录（与上一片之间有时间空洞）、3结束收尾、0未知is_last为true表示本次录制的文件已全部就绪
duration 是本片时长（秒），vod_size 是本片字节数。
mcu_alarm — 录制任务异常
gw 是任务所在的网关节点，排查时告诉我们这个值能快很多。注意告警不代表任务已终止 ——
以 mcu_status_change 的 task_status 为准。
幂等与重试
网络抖动可能导致同一事件送达多次，业务侧请按event + 业务主键（meeting_id、task_id、
user_id）做幂等。不要用 time 去重 —— 同一秒内可以有多个同类事件。