Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-9-1 — UPnP AV Device Template v1
UPnP AV Architecture: Device Template
ISO/IEC 29341-9-1 establishes the foundational device template for UPnP Audio/Video (AV) devices, defining the core architecture that all UPnP AV components follow. As the cornerstone of the UPnP AV specification suite, this standard describes how Media Servers, Media Renderers, and Control Points interact to enable seamless streaming of audio and video content across a home network. The template defines mandatory embedded services, state variables, and action sets that every compliant AV device must implement.
The AV Device Template adopts a modular design philosophy. Rather than prescribing a monolithic device definition, it defines a framework of reusable service components that can be combined to create Media Servers (content sources), Media Renderers (playback devices), and specialized AV devices. This flexibility has enabled the standard to remain relevant across multiple hardware generations, from early DLNA-certified media players to modern smart TVs and streaming boxes.
1. Overview of AV Device Template Architecture
The AV Device Template defines three fundamental device types: MediaServer (urn:schemas-upnp-org:device:MediaServer), MediaRenderer (urn:schemas-upnp-org:device:MediaRenderer), and AVControlPoint (a logical device with no physical device type UDN). Each device type embeds specific required services. The MediaServer must implement ContentDirectory (for content browsing), ConnectionManager (for connection management), and AVTransport (for transport control). The MediaRenderer must implement RenderingControl (for volume/picture adjustment), ConnectionManager, and AVTransport.
The template specifies the device description document format using XML, defining standard elements such as friendlyName, manufacturer, modelName, UDN (Unique Device Name), and serviceList. All AV devices must include the UPnP Device Architecture v1.1 mandatory fields while also publishing the AV-specific service capabilities via the device description. This enables Control Points to discover and interact with AV devices without prior knowledge of their capabilities.
Key Parameters
| Device Type | Required Services | Optional Services |
|---|---|---|
| MediaServer | ContentDirectory, ConnectionManager, AVTransport | RenderingControl, ScheduledRecording |
| MediaRenderer | RenderingControl, ConnectionManager, AVTransport | ContentDirectory (for local playback queues) |
| AVControlPoint | No required services (logical device) | All services are optional based on use case |
When implementing Browse(), always support the “BrowseDirectChildren” and “BrowseMetadata” modes. The “BrowseMetadata” mode is essential for Control Points to discover item properties without enumerating containers.
Do not advertise a format in the protocolInfo field unless it has been fully tested. A failed streaming attempt due to unsupported formats degrades user experience more than simply not offering the format.
The modular design of the AV Device Template allows incremental implementation: a basic MediaServer with just ContentDirectory + HTTP GET streaming can be built and certified, then extended with AVTransport for full transport control.
Implementing AVTransport without proper synchronization of the InstanceID state variable will cause race conditions in multi-renderer scenarios. Always lock InstanceID during state-modifying actions.
2. Service Integration Patterns
The service integration pattern in the AV Device Template follows a layered architecture. At the base layer, the UPnP Device Architecture provides discovery (SSDP), description (XML device/service schemas), control (SOAP), and eventing (GENA). Above this, the AV template defines the service hierarchy: mandatory services (required for all AV devices), conditional services (required when specific hardware capabilities exist), and optional services (enhancements like DLNA features).
A key design decision in the AV Device Template is the separation of transport control from content management. AVTransport handles play, pause, stop, seek, and speed control operations, while ContentDirectory manages content browsing, search, and metadata retrieval. This separation allows a single MediaServer to serve multiple independent streams to different Renderers simultaneously, each with independent transport state. The ConnectionManager service acts as the bridge, negotiating the streaming protocol (HTTP GET, RTSP, RTP) and data format between the source and sink.
The template also defines the concept of “AV scenarios” — predefined interaction patterns such as “two-box push” (Control Point commands MediaServer to send content to MediaRenderer) and “three-box” (Control Point orchestrates communication between separate MediaServer and MediaRenderer). These scenarios are not protocol extensions but documented usage patterns that guide application developers in implementing consistent user experiences.
The modular design of the AV Device Template allows incremental implementation: a basic MediaServer with just ContentDirectory + HTTP GET streaming can be built and certified, then extended with AVTransport for full transport control.
Implementing AVTransport without proper synchronization of the InstanceID state variable will cause race conditions in multi-renderer scenarios. Always lock InstanceID during state-modifying actions.
3. Implementation Guidance
Implementing a UPnP AV device based on this template requires careful attention to several engineering aspects. First, the device description XML must accurately reflect the device capabilities — under-reporting capabilities limits functionality, while over-reporting leads to failed connections when Control Points attempt unsupported operations. The recommended approach is to implement all mandatory services first (ContentDirectory, ConnectionManager, AVTransport), then add optional services incrementally.
For MediaServer implementations, the ContentDirectory service is the most performance-critical component. Its Browse() and Search() actions must handle large media collections efficiently. Implementing container-level caching, paginated results (with the requestedCount and startingIndex parameters), and incremental metadata updates through the SystemUpdateID state variable are essential for responsive user experiences. The template recommends using object-oriented container hierarchies with up to 16 levels of nesting for organizing content.
Interoperability testing is crucial because different vendors implement varying subsets of the AV specification. The standard provides conformance guidelines but does not mandate every optional feature. Device manufacturers should publish a Device Compatibility Matrix listing which AV scenarios, transport protocols (HTTP GET, RTSP, IEC 61883), and media formats (MPEG2, H.264, AAC, LPCM) their devices support. The UPnP AV certification program provides formal validation of baseline interoperability.
FAQ
Q: Can a single device implement both MediaServer and MediaRenderer?
A: Yes, the template allows a device to implement multiple device types. Such a device would expose two separate UDNs and device descriptions — one as MediaServer and one as MediaRenderer. This is common in smart TVs that both serve content to mobile devices and render content from network sources.
A: Yes, the template allows a device to implement multiple device types. Such a device would expose two separate UDNs and device descriptions — one as MediaServer and one as MediaRenderer. This is common in smart TVs that both serve content to mobile devices and render content from network sources.
Q: What transport protocols does the template mandate?
A: The template requires support for at least HTTP GET streaming. RTSP/RTP, IEC 61883 (for IEEE 1394), and vendor-specific protocols are optional but must be declared in the ConnectionManager protocolInfo field for Control Point discovery.
A: The template requires support for at least HTTP GET streaming. RTSP/RTP, IEC 61883 (for IEEE 1394), and vendor-specific protocols are optional but must be declared in the ConnectionManager protocolInfo field for Control Point discovery.
Q: How does the template handle digital rights management (DRM)?
A: DRM is handled through the Extended Capabilities framework rather than the core template. Devices supporting protected content must advertise DRM capabilities via the extendedProtocolInfo field in ConnectionManager and implement the appropriate license acquisition protocols.
A: DRM is handled through the Extended Capabilities framework rather than the core template. Devices supporting protected content must advertise DRM capabilities via the extendedProtocolInfo field in ConnectionManager and implement the appropriate license acquisition protocols.
