摘要

  • RFC 3524 为 SDP 定义了 SRF 语义，使多个由 mid 标识的媒体行可以请求共用一个资源预留流。
  • 分组只表达映射意图；逐节点准入、策略许可、分类与调度状态、软状态刷新、数据包待遇和最终播放仍是彼此独立的证据。

a=group:SRF 1 2 看起来很有完成感。两个数字引用音频与视频的 mid，SRF 又明确说它们属于 Single Reservation Flow。远端因此不必猜测发送方究竟想建一个 RSVP 会话还是两个。

然而 RFC 3524 开篇就把“媒体流”与“资源预留流”分开。一个多媒体会话可以让全部媒体共用一个预留，可以为每种媒体单独预留，也可以让其中两种共用、另一种独立。SRF 选择的是这三类关系之一；它没有分配容量，没有挑选路径，也没有写入任何路由器的队列。

规范使用 SHOULD 与 SHOULD NOT，边界很清楚：组内媒体行应当映射到同一个预留流，组外媒体行不应混入该流。一个 SRF 组甚至可以只有一行。这里规定的是端点如何构造后续请求，而不是宣布网络已经接受请求。

分组框架提供了可核验的引用结构。每个媒体描述的 mid 必须在当前 SDP 会话中唯一；group 行在特定语义下列出这些标识。如果标识找不到相应媒体行，它不会因被写进列表就获得实体。RFC 5888 后来保留了这套框架。现代 SDP 仍允许接收方忽略不理解的属性，所以“收到合法文本”与“实现理解并执行”从来不是同一事实。

RFC 3524 特别指出，只有当远端需要参与资源预留时，这个机制才有用。如果生成 SDP 的一方能够自行分配双向资源，它可以本地决定映射，无须发送 SRF。示例中的远端若收到同样的音频、视频描述却没有 group 行，便可自由建立两个 RSVP 会话。

示例用 SIP 传送 SDP，用 RSVP 建立预留；RFC 又明确允许其他协议与机制。也就是说，SRF 被故意放在描述层。它携带一个可移植的选择，却不垄断实现该选择的手段。

RSVP 说明后续工作有多长。接收方要发送 Resv，其中 flowspec 描述期望的 QoS，filter spec 指定哪些数据包获得这种待遇。每个参与节点都要分别执行准入控制与策略控制：前者判断资源是否足够，后者判断请求是否获准。任一检查失败，该节点就不能安装所请求的状态。只有通过以后，分类器与调度器才可能被设置。

状态还不是永久资产。RSVP 依靠 Path 与 Resv 周期刷新软状态。路由变化时，新路径逐步建立状态，旧路径的无人使用状态随后超时。SDP 分组可以保持字节不变，而它曾经指向的资源现实已经消失。

RFC 2205 对确认也保持克制：收到 ResvConf 不提供保证。一个请求可能先得到确认，随后因其他请求、合并结果或某节点的资源变化而收到错误。既然预留协议自己的确认都有时间与范围边界，更早一步的 SRF 声明更不能被当作服务完成证明。

RFC 3312 又把 QoS 的 current status 与 desired status 分开。若“写出期望”就能制造当前状态，这两个字段便没有存在必要。SRF 回答的是“哪些媒体应共同尝试预留”，不是“两个方向的资源是否已经满足”。

安全章节揭示了这行文字的真实控制力。攻击者若插入 SRF 分组，可迫使端点建立过多或过少的预留流。过多会浪费端点资源，过少会降低会话质量。因此 RFC 强烈建议保护 SDP 完整性，并在 SIP 场景下把 S/MIME 作为自然选择。

完整性解决的是作者与内容是否被改写。它不能凭空产生带宽，不能越过本地策略，不能让不支持 SRF 的端点突然支持它，也不能保持 RSVP 刷新、保证数据包符合 filter，或证明用户听见声音、看见画面。

IANA 登记 SRF 也只完成一个窄任务：给实现一个共同的标记与规范引用。登记表没有看见任何现场 offer、预留请求、队列状态或媒体结果。发布能协调含义，采用与执行仍由运行代码的参与者完成。

因此，RFC 3524 留下的历史不是“SDP 获得了资源权力”，而是相反：一个薄的共同表达层让端点交流映射选择，同时不冒充实际资源的拥有者。可靠运营应逐层保留凭据：SDP 合法、mid 可解析、分组意图已认证、映射被采用、请求已发出、每跳准入通过、状态已安装、刷新仍存活、数据包被正确分类、媒体确实呈现。把这些压缩成“SRF 存在”，只是把计划写成了虚构的容量。

来源