请求形态
我们向你注册的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时有内容
0 和 2 是过渡状态，业务侧一般只需要关心 1（开始了）、3（出错了）、4（结束了）。
mcu_record_done — 录像转码完成
task_status 变成 4（正常结束）时转码
往往还没做完，此时调录像播放地址可能拿不到东西。
mcu_dur 是录像时长（秒），vod_size 是文件字节数。
mcu_alarm — 录制任务异常
gw 是任务所在的网关节点，排查时告诉我们这个值能快很多。注意告警不代表任务已终止 ——
以 mcu_status_change 的 task_status 为准。
幂等与重试
网络抖动可能导致同一事件送达多次，业务侧请按event + 业务主键（meeting_id、task_id、
user_id）做幂等。不要用 time 去重 —— 同一秒内可以有多个同类事件。