Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-9-2 — UPnP AV 设备服务 v1
AV 设备服务规范
ISO/IEC 29341-9-2 定义了 AV 设备服务，这是一个通用的服务模板，标准化了 UPnP AV 设备的状态变量模型、操作签名和事件行为。Part 9-1 定义了设备模板（设备是什么），而 Part 9-2 定义了服务模板（服务做什么）。本标准为 ContentDirectory、ConnectionManager、AVTransport 和 RenderingControl 服务提供了基础服务框架，确保所有 AV 服务行为一致。
该服务规范引入了状态变量（表示服务状态的类型化数据）、操作（修改或查询服务状态的操作）和事件通知（状态变化时的异步更新）的正式定义。它建立了所有 AV 服务必须发布的 XML 服务描述模式，使控制点能够在运行时动态发现每个服务的能力、操作和状态变量。
一、AV 设备服务架构
AV 设备服务架构将状态变量分为两类：调节型和非调节型。调节型状态变量以最大速率发送事件通知（如最小 200 毫秒间隔），而非调节型变量在每次变化时立即发送事件。对于 AV 服务，诸如 AVTransport 的 RelativeTimePosition 和 AbsoluteTimePosition 等高频率变量被调节以防止事件风暴，而 AVTransportURI 等连接状态变量是非调节型的，因为它们变化不频繁。
每个服务操作都定义了其输入参数、输出参数和可能的错误码。服务描述模式使用 XML 声明这些元素，每个参数引用一个定义其数据类型的状态变量（string、ui4、i4、boolean、bin.base64 或 AV 规范定义的自定义数据类型）。自定义数据类型包括 A_ARG_TYPE_ProtocolInfo（描述流式传输协议和内容格式的逗号分隔格式字符串）和 A_ARG_TYPE_ObjectID（内容目录项和容器的字符串标识符）。
关键参数
| Service Feature | Mandatory | Optional |
|---|---|---|
| Get actions (e.g., GetTransportInfo) | Yes | – |
| Set actions (e.g., SetAVTransportURI) | Yes | – |
| LastChange state variable | Yes | – |
| Event moderation (<200ms interval) | Yes | – |
| Error code 701-707 reporting | Yes | – |
| A_ARG_TYPE_SeekMode | – | Required if Seek() is supported |
| A_ARG_TYPE_PlayMode | – | Required if PlayMode != NORMAL |
即使你的控制点不使用 LastChange 状态变量也要实现它。许多第三方控制点依赖 LastChange 进行基于轮询的同步，而不是订阅单个事件变量。
切勿在未发送相应事件通知的情况下修改状态变量。服务与订阅控制点之间的不一致状态是互操作性错误的常见来源。
与高更新率场景中的非调节事件相比，对位置相关状态变量（RelativeTimePosition、AbsoluteTimePosition）使用调节事件模型可减少高达 95% 的网络流量。
未在传输状态转换周围实现适当的互斥锁会导致两个控制点同时调用 Play() 和 Stop() 时服务进入无效状态。
二、服务状态变量与操作
AV 设备服务规范定义了一套全面的状态变量数据类型。标准 UPnP 数据类型构成基础：ui4（无符号 32 位整数）用于计数器和标志位，string 用于名称和标识符，boolean 用于二进制状态，bin.base64 用于二进制数据。AV 特定扩展包括：A_ARG_TYPE_SeekMode（枚举：TRACK_NR、ABS_TIME、REL_TIME 等）、A_ARG_TYPE_PlayMode（枚举：NORMAL、SHUFFLE、REPEAT_ONE、REPEAT_ALL、RANDOM）和 A_ARG_TYPE_TransportState（枚举：STOPPED、PAUSED_PLAYBACK、PLAYING、TRANSITIONING、NO_MEDIA_PRESENT）。
服务操作遵循反映其功能的命名约定：Get 操作（查询状态，无副作用）、Set 操作（修改状态，有副作用）以及 Browse、Search、Next、Previous 等操作。每个操作必须声明其修改的状态变量和触发的事件通知。服务描述包括一个”服务控制协议”部分，记录了顺序约束——例如，在正常播放流程中，必须先调用 SetAVTransportURI 再调用 Play。
错误处理通过一组预定义的 UPnP 错误码和 AV 特定错误码实现标准化。常见错误包括 701（转换不可用）、702（无内容）、703（读取错误）、704（不支持的格式）、705（非法跳转目标）、706（无效播放模式）和 707（资源未找到）。实现正确的错误报告至关重要，因为控制点依赖错误码向用户提供有意义的反馈并实现重试逻辑。
与高更新率场景中的非调节事件相比，对位置相关状态变量（RelativeTimePosition、AbsoluteTimePosition）使用调节事件模型可减少高达 95% 的网络流量。
未在传输状态转换周围实现适当的互斥锁会导致两个控制点同时调用 Play() 和 Stop() 时服务进入无效状态。
三、部署模式
在实践中，实现 AV 设备服务模板时需要仔细关注线程安全。UPnP 服务操作和事件通知本质上是异步的——多个控制点可以同时调用操作，而内部状态变化（如曲目完成）也会触发事件。使用适当互斥锁的状态机实现对于防止竞态条件至关重要。标准推荐使用读写锁模式：Get 操作为共享读访问，Set 操作和内部状态转换为排他写访问。
性能优化策略包括：（1）批处理事件通知——如果多个状态变量在单个操作调用中发生变化，发送包含所有更新值的单个事件通知而非单独事件；（2）实现事件键序列化——每个事件携带单调递增的事件键，允许控制点检测丢失的事件；（3）支持 LastChange 状态变量（一种结构化 XML 片段，编码所有最近的状态变化），供偏好轮询而非事件订阅的控制点使用。
不同服务实现之间的互操作性测试需要验证：使用有效和无效参数调用操作、各种负载条件下的事件通知时序、错误条件后的状态变量一致性以及控制点意外取消订阅时的正确清理。UPnP AV 认证测试套件包括这些场景的自动化测试，但建议在认证前使用参考控制点（如 Intel AV Media Controller、Platinum UPnP SDK 测试工具）进行手动测试。
常见问题
问：调节型和非调节型状态变量有什么区别？
答：调节型变量有最小事件间隔（AV 服务通常为 200ms），意味着快速变化被批处理为周期性通知。非调节型变量在每次变化时立即发送事件。位置跟踪变量是调节型的；URI 和连接状态变量是非调节型的。
答：调节型变量有最小事件间隔（AV 服务通常为 200ms），意味着快速变化被批处理为周期性通知。非调节型变量在每次变化时立即发送事件。位置跟踪变量是调节型的；URI 和连接状态变量是非调节型的。
问：如何处理自定义错误码？
答：AV 服务错误码 701-799 保留给 AV 特定错误。供应商可以在 800-899 范围内为专有扩展定义额外代码，但这些必须在供应商的 UPnP 设备兼容性声明中记录。返回未定义的错误码会导致未定义的控制点行为。
答：AV 服务错误码 701-799 保留给 AV 特定错误。供应商可以在 800-899 范围内为专有扩展定义额外代码，但这些必须在供应商的 UPnP 设备兼容性声明中记录。返回未定义的错误码会导致未定义的控制点行为。
问：AV 服务是否可以省略订阅事件机制？
答：不可以。通过 GENA（通用事件通知架构）的事件订阅对 UPnP 服务是强制性的。没有事件通知，控制点无法检测状态变化，必须诉诸轮询，这违背了 UPnP 事件驱动架构的目的。
答：不可以。通过 GENA（通用事件通知架构）的事件订阅对 UPnP 服务是强制性的。没有事件通知，控制点无法检测状态变化，必须诉诸轮询，这违背了 UPnP 事件驱动架构的目的。
