ISO/IEC 29341-9-10 — UPnP AV ConnectionManager v3

ConnectionManager v3 服务规范

ISO/IEC 29341-9-10 定义了 ConnectionManager v3 服务,这是 UPnP AV 架构中负责管理 MediaServer 和 MediaRenderer 之间流式传输连接的关键组件。ConnectionManager 充当协商代理:它根据源端和接收端各自的协议和格式能力判断建议的连接是否可行,管理活动连接状态,并在连接拓扑发生变化时提供事件通知。

v3 规范在 v2 的基础上引入了若干重要增强,包括支持每设备多个同时连接、改进的 protocolInfo 格式字符串(带扩展能力字段)以及新的 PrepareForConnection() 操作,可实现缓冲流式传输和内容自适应等高级连接场景。这些改进反映了家庭 AV 网络日益增长的复杂性,其中单个 MediaRenderer 可能需要管理用于画中画显示或多房间音频同步的并发流。

一、ConnectionManager v3 架构

ConnectionManager v3 架构围绕”连接”的概念展开——从源端(MediaServer)到接收端(MediaRenderer)的单播或组播流。每个连接由 ConnectionID(整数)标识,并维护以下状态:AVTransportID(标识源端的传输实例)、RcsID(标识接收端的渲染控制实例)、ProtocolInfo(描述流式传输协议和内容格式)和 Direction(输入或输出)。服务维护一个列出所有活动连接的 ConnectionManager 表。

核心协商机制是 GetProtocolInfo() 操作,它返回三个列表:Source(设备可发送的协议/格式)、Sink(设备可接收的协议/格式)和 CurrentConnectionIDs(当前活动连接)。每个条目使用 protocolInfo 格式字符串:”protocol:network:contentFormat:additionalInfo”。例如,”http-get:*:video/mpeg:*” 表示设备可以通过 HTTP GET 接收 MPEG 视频。v3 规范扩展了 additionalInfo 字段以携带能力标志,如 DRM 要求、分辨率限制和编解码器配置文件。

关键参数

Feature ConnectionManager v2 ConnectionManager v3
Max simultaneous connections Limited (typically 1) Multiple, configurable (2-20 typical)
protocolInfo format Basic 4-field Extended additionalInfo with capability flags
Connection setup GetCurrentConnectionInfo() + PrepareForConnection() async setup
Quality of Service Not supported QoS parameter negotiation
Content adaptation Not supported Transcoding capability advertisement
Error reporting Basic codes (704) Extended codes + descriptive strings
始终发布准确的 protocolInfo 列表。多报会导致连接尝试失败;少报会限制可用性。在认证前使用 DLNA Validator 工具验证你的 protocolInfo 条目。
如果资源不可用,PrepareForConnection() 操作可能失败。始终为异步连接设置实现超时机制(建议:30 秒),以防止孤立连接。
通过使用 DLNA.ORG_FLAGS 进行适当的 protocolInfo 分组,单个 MediaRenderer 可以通告对多个视频配置文件(MPEG2 SD、MPEG2 HD、H.264 SD、H.264 HD)的支持,同时让控制点选择最佳格式。
不要假设支持”http-get”的设备也支持范围请求(字节范围跳转)。始终检查 DLNA.ORG_OP 标志。没有范围支持,HTTP 流中的跳转将静默失败。

二、协议与格式协商

ConnectionManager v3 中的协议协商遵循交集匹配算法。当控制点请求源端和接收端之间的连接时,ConnectionManager 检索两个设备的 protocolInfo 列表,计算兼容协议和格式的交集,根据可配置的偏好顺序(通常:最高质量、最低延迟、最少资源消耗)选择最优先的条目,并使用所选协议建立连接。如果交集为空,连接失败并返回错误码 704(不支持的格式)。

v3 规范通过”additionalInfo”字段引入了 protocolInfo 分组。设备可以声明能力标志,例如:DLNA.ORG_PS=1(参数化跳转支持)、DLNA.ORG_OP=1(基于时间的跳转)、DLNA.ORG_FLAGS=01700000000000000000000000000000(用于播放能力的 DLNA 媒体标志)。这些标志允许精细的能力匹配。例如,支持 H.264 视频但仅支持 30 fps 的 MediaRenderer 可以在 additionalInfo 中声明带有能力约束的”video/mpeg”,防止控制点发送渲染器无法处理的 60 fps 内容。

v3 新增的 PrepareForConnection() 操作提供了比基本的 GetCurrentConnectionInfo() 方法更强的连接设置功能。它允许控制点指定期望的服务质量参数、首选传输协议和内容格式。然后 ConnectionManager 可以预分配资源(缓冲内存、解码器实例)并立即返回 ConnectionID,而实际的流设置则异步进行。这实现了无缝播放和无缝源切换等功能。

通过使用 DLNA.ORG_FLAGS 进行适当的 protocolInfo 分组,单个 MediaRenderer 可以通告对多个视频配置文件(MPEG2 SD、MPEG2 HD、H.264 SD、H.264 HD)的支持,同时让控制点选择最佳格式。
不要假设支持”http-get”的设备也支持范围请求(字节范围跳转)。始终检查 DLNA.ORG_OP 标志。没有范围支持,HTTP 流中的跳转将静默失败。

三、实现策略

高效实现 ConnectionManager v3 需要仔细的资源管理。每个活动连接消耗系统资源:套接字描述符、内存缓冲区(每个流通常为 64 KB 到 2 MB 用于抖动缓冲)、解码器实例和带宽。实现必须对并发连接实施可配置的限制——典型的家庭 MediaRenderer 可能支持 2-4 个并发连接,而 MediaServer 可以处理 10-20 个。超出这些限制应返回错误码 501(操作失败)并附上描述性消息。

protocolInfo 格式字符串解析是互操作性问题的常见来源。格式为:protocol:network:contentFormat:additionalInfo,其中 protocol 为”http-get”、”rtsp”、”rtp”、”internal”(供应商特定)、”iec61883″(适用于 IEEE 1394)或供应商定义的字符串。contentFormat 应尽可能使用 MIME 类型(例如 “video/mpeg”、”audio/L16;rate=44100;channels=2″)。实现必须容空白符变化和未知能力标志——它们应忽略无法识别的 additionalInfo 令牌,而不是拒绝整个 protocolInfo 条目。

对于高级部署,ConnectionManager v3 支持通过 CurrentConnectionIDs 状态变量和每连接事件进行连接监控。当添加或移除连接时,服务更新 CurrentConnectionIDs 并发送事件。控制点随后可以查询每个活动连接的 GetCurrentConnectionInfo() 详细信息。该机制对于实现显示”正在播放”信息或多房间音频组管理的用户界面至关重要。

常见问题

问:ConnectionManager 如何处理协议版本协商?
答:当控制点查询 GetProtocolInfo() 时,服务返回所有支持的协议变体。控制点选择一个互兼容的条目。对于向后兼容性,v3 设备必须在其列表中包含所有 v2 兼容的 protocolInfo 条目,通过省略 v3 特定的 additionalInfo 字段来标识。
问:当连接意外断开时会发生什么?
答:ConnectionManager 通过传输层超时(TCP RST 或 RTSP TEARDOWN)检测断开的连接。它清理连接条目,更新 CurrentConnectionIDs 并发送事件通知。检测断开 HTTP 连接的推荐超时时间为 120 秒无活动。
问:ConnectionManager 能否促进直接点对点连接?
答:可以。虽然典型场景涉及同一子网上的 MediaServer 和 MediaRenderer,但 ConnectionManager 可以协商跨网段的直接连接。protocolInfo 可以指定支持 NAT 穿越或基于 VPN 连接的”rtp”或”internal”协议。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注