MCVideo 呼叫流程：视频通话的"秒开"与"断开"

在应急指挥或专业执法场景中，MCVideo（任务关键视频）是不可或缺的“千里眼”。它不同于普通社交软件的视频通话，而是介于“对讲机”、“视频监控”与“应急广播”之间的融合体。要想让视频画面在复杂网络下实现“秒开”且有序传输，核心在于其信令层面的标准化约定。本文将基于 3GPP TS 24.281（Rel-20 v20.1.0）规范，用生活化的隐喻拆解 MCVideo 视频通话如何建立、传输画面及断开连接。

一、 协议定位：从“需求”到“执行”

在 3GPP MCX（任务关键通信）家族中，规范分为三个层级，切勿混淆：

• Stage 1 (TS 22.281)：定义“要什么”，即用户需求，如“我要看高清画面”。
• Stage 2 (TS 23.281)：定义“怎么架构”，即系统由哪些网元组成，谁负责什么。
• Stage 3 (TS 24.281)：定义“怎么跑”，即具体的信令协议。本文聚焦于此，它是规定视频组呼、私呼、拉取、推送等每一步“发什么消息、消息里写什么”的执行手册。

TS 24.281 的核心价值在于标准化信令交互，确保不同厂商的设备与服务器能像默契的舞伴一样配合。它不直接规定视频编解码（那是 TS 26.281 的事），也不负责底层安全算法（那是 TS 33.180 的事），它只专注信令层的“对话规则”。

二、 视频“秒开”的秘密：信令握手

视频通话的“秒开”并非魔法，而是高效信令交互的结果。以在线预安排组呼为例，流程如同餐厅点餐：

1. 身份认证（注册与归属）：
   在发起呼叫前，UE（用户设备）必须先完成注册和业务授权，确认自己“有资格”使用 MCVideo 服务。同时，用户需与特定群组建立归属关系（Affiliation），就像员工必须拥有工牌才能进入特定办公区。

2. 发起邀请（SIP INVITE）：
   用户点击呼叫，客户端生成 SIP INVITE 消息。这里有个关键细节：消息头中必须携带g.3gpp.mcvideo媒体特征标签和 ICSI 引用（urn:urn-7:3gpp-service.ims.icsi.mcvideo）。

   • 隐喻：这就像你在打电话时，除了说“我要开会”，还必须明确声明“我是 MCVideo 用户，我偏好此业务，请服务器按 MCVideo 标准处理”。如果缺少这些标识，服务器可能将其误判为普通 IMS 呼叫，导致功能异常。
   • 预检查：若群组配置为<preconfigured-group-use-only>为 true，客户端会直接提示“该组不允许呼叫”，避免无效信令浪费资源。

3. 服务器处理与传输控制：
   网络侧收到 INVITE 后，并非直接放行，而是介入处理。TS 24.281 引用 TS 24.581 的传输控制程序（Transmission Control）。

   • 隐喻：这如同课堂点名。前端设备想传画面（举手），必须等待控制方（老师/服务器）批准。
   • 流程：UE 发送传输控制请求 -> 服务器决定授予、拒绝或排队 -> 授权后媒体才上行。这种机制防止了多人同时上传导致网络拥塞，实现了有序的“秒开”体验。

三、 画面传输：拉取与推送的两种模式

MCVideo 支持灵活的视频获取方式，主要分为“拉取”和“推送”：

1. 视频拉取（Video Pull）：

   • 场景：调度台平时不监控某前端，但突发情况需要查看。
   • 流程：调度台发送 SIP MESSAGE 请求拉取，前端收到后按需上传。这是一种“按需获取”的模式，节省带宽。

2. 视频推送（Video Push）：

   • 场景：前端设备主动将画面推给调度台或其他 UE。
   • 细节：
     • 一对一推送：类似私呼流程，但 SIP 消息体中需包含application/vnd.3gpp.mcvideo-info+xml，并将<session-type>设为 “one-to-one video push”。
     • 推送到服务器：<session-type>设为 “one-to-server video push”，且使用自动开始模式（automatic commencement mode），无需额外确认即可开始传输，确保紧急情况下画面即时可见。

3. 多方收看与广播：
   在线组呼中，网络可使用单播承载（Unicast）或 MBMS/MBS 广播传输。若大量用户观看同一路视频，广播模式可显著降低核心网负载，实现高效分发。

四、 关键时刻：紧急呼叫与位置服务

MCVideo 专为关键任务设计，具备独特的应急响应机制：

1. 紧急视频呼叫：
   与普通 IMS 紧急呼叫不同，MCVideo 紧急呼叫不使用专用的 Emergency Bearers，而是将普通承载的 EPS bearer priority 调高，利用现有资源优先保障视频流。在离线场景下，则依赖 ProSe 直接通信（TS 24.334）实现设备间直连。

2. 环境查看（位置报告）：
   规范定义了两种 SIP MESSAGE 请求：

   • 配置请求：A 要求 B 配置位置上报参数（如频率、方式）。
   • 实时请求：A 要求 B 立即上报当前位置。
     这在救援场景中至关重要，调度台可实时掌握救援人员位置，无需对方主动发送。

3. 临时组紧急警报：
   支持 Ad-hoc Group Emergency Alert。客户端收到请求后，若授权通过，会生成带有<adhoc-alert-ind>为 true 的 SIP MESSAGE，并附带位置信息和优先级，迅速通知临时组建的群组。

五、 优雅断开：资源释放

视频通话的结束同样需要标准化流程，确保资源彻底释放：

1. 用户主动结束：
   用户点击挂断，客户端发送 SIP BYE 消息。
2. 传输释放：
   媒体面停止数据传输后，信令层需执行传输控制释放流程。TS 24.281 规定，无论是一对一推送还是组呼，释放流程均遵循相应的信令约定，确保服务器和 UE 的会话状态同步清除。
3. 业务连续性：
   在移动切换过程中，TS 24.281 引用 TS 24.237 的 PS-PS 接入转移程序，确保视频会话在基站切换时尽量保持连续，避免因信号波动导致画面中断。

六、 协议边界：它不管什么

明确 TS 24.281 的边界有助于正确理解其作用：

• 不管编解码：H.264/H.265 等编码细节由 TS 26.281 规定。
• 不管安全算法：加密、鉴权由 TS 33.180 定义。
• 不管接入层细节：E-UTRAN/NG-RAN 接入信令由 TS 24.301/24.501 规定。
• 不管群管理：群组创建、成员管理由 TS 24.481 规定。

TS 24.281 是信令层的“指挥官”，协调各方按标准动作执行，但不介入具体技术实现。

七、 总结与阅读建议

MCVideo 的“秒开”与“有序”源于 Stage 3 协议对信令交互的精细定义。从 SIP INVITE 中的能力标识，到传输控制的授权机制，再到紧急场景下的优先级调整，每一步都经过标准化设计。

建议阅读顺序：

1. TS 24.281：建立信令消息层整体感，理解 SIP 消息结构与流程。
2. TS 23.281：理解 MCVideo 系统架构，明确在线/离线、组呼/私呼的系统级组织。
3. TS 24.581：深入理解传输控制程序，掌握“谁先传、怎么传”的控制逻辑。
4. TS 33.180：了解信令与媒体的安全保护机制。

3GPP MCX 共包含 25 条相关规范，中国侧有 8 条对应标准。理解 TS 24.281 是掌握 MCVideo 核心流程的关键一步。

本文是《MCX关键任务通信自学体系》连载之一，完整体系（含标准清单/架构详解/中国专网映射）已整理为知识库：zhuoyue2019.github.io（直达链接暂不公开，私信获取）