Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-18-11: UPnP AV ConnectionManager Service v2
UPnP Audio/Video — Part 18-11: ConnectionManager Service Version 2 Specification
1. ConnectionManager v2 Architecture and Multi-Stream Capabilities
ISO/IEC 29341-18-11 specifies version 2 of the ConnectionManager service, evolving the connection management framework originally defined in Part 17-11 (ConnectionManager v1). Version 2 addresses several limitations encountered in large-scale and complex UPnP AV deployments: the single-connection-per-session model, limited protocol negotiation expressiveness, and the absence of a policy framework for connection resource allocation. V2 introduces multi-stream connections, enhanced protocolInfo semantics, and a connection policy system that gives control points and devices greater flexibility in managing media pipelines.
The most significant architectural change in v2 is the introduction of multi-stream connections. In v1, each PrepareForConnection call established a single media stream between a source and sink. In v2, a single connection can carry multiple streams, each with potentially different protocols and formats. For example, a connection between a MediaServer and a MediaRenderer might simultaneously carry a primary video stream (MPEG-4 AVC), a secondary audio commentary stream (MP3), and a subtitle stream (text/plain) — all within a single connection identified by a single ConnectionID. This multiplexed model more accurately reflects the structure of modern multimedia content, where a movie file contains multiple elementary streams that need synchronized delivery to the renderer.
The multi-stream capability in v2 ConnectionManager is particularly valuable for applications requiring synchronized auxiliary content, such as director commentary tracks, multi-angle video, or accessibility audio descriptions. Instead of establishing separate connections for each auxiliary stream, a single multiplexed connection handles them all, ensuring synchronous delivery.
2. Enhanced Protocol Negotiation and Content Format Resolution
The protocolInfo semantics are significantly extended in v2. The v1 protocolInfo tuple (protocol:network:contentFormat:additionalInfo) remains the foundation, but v2 adds the concept of protocol preference levels. A device can now indicate not just which protocols it supports, but which it prefers, enabling more intelligent connection establishment. For example, a MediaRenderer might list both “http-get” and “rtsp” as supported protocols but indicate a preference for RTSP when the content format supports it, because RTSP provides better stream control (pause/resume at the transport level) for certain content types.
Content format resolution is enhanced with the GetCompatibleFormats action. Given a set of source formats and renderer capabilities, this action returns the intersection — formats that are compatible with both endpoints. This eliminates the trial-and-error approach that v1 control points often had to employ, where they would attempt to establish a connection with a guessed format and handle failure by trying the next format in their compatibility list. GetCompatibleFormats returns the definitive list in a single action invocation, reducing connection setup latency and improving user experience.
| Feature | ConnectionManager v1 (17-11) | ConnectionManager v2 (18-11) | Benefit |
|---|---|---|---|
| Stream Model | Single stream per connection | Multi-stream per connection | Synchronized audio/video/subtitle delivery |
| Protocol Preference | Not supported | Weighted protocol preferences | Optimal protocol selection for each content type |
| Format Resolution | Control point trial-and-error | GetCompatibleFormats action | Single-step format negotiation; reduced latency |
| Connection Policy | None (best-effort) | Policy-based resource allocation | Guaranteed resource availability for priority streams |
| Connection Events | Basic status change | Per-stream status events, quality metrics | Real-time connection health monitoring |
| Direction Control | Input/Output/Direction | Added BiDirectional, MultiPoint, Broadcast | Supports conferencing, multi-room, and live event scenarios |
| Resource Reservation | Implicit (no feedback) | Explicit with GetResourceStatus action | Control points can check resource availability before connecting |
While multi-stream connections are powerful, they introduce complexity in error handling. When one stream in a multiplexed connection fails (e.g., audio decoder error), the device must decide whether to continue delivering the remaining streams (video without audio) or terminate the entire connection. The standard recommends configurable behavior through the ConnectionPolicy state variable, allowing the control point or user to specify the preferred failure mode.
3. Connection Policy Framework and Resource Management
V2 introduces a formal connection policy framework that governs how connection resources are allocated and managed. The ConnectionPolicy state variable holds a set of policy rules that define: the maximum number of concurrent connections, the maximum number of streams per connection, the bandwidth allocation policy (equal sharing, priority-based, or reserved), and the connection admission control rules. These policies can be configured by an administrator through the SetConnectionPolicy action or queried by control points through GetConnectionPolicy.
Resource management is enhanced with explicit resource reservation and status reporting. The GetResourceStatus action returns detailed information about the device’s current resource utilization, including: the number of active connections versus the maximum allowed, total and per-connection bandwidth consumption, decoder/encoder utilization (as a percentage), and memory buffer pool status. This information enables control points to make intelligent decisions about which MediaRenderer to use for a new stream, based on current load rather than just static capability advertisement.
Connection eventing is significantly enhanced in v2. The CurrentConnectionIDs event variable now includes per-stream status information, enabling control points to monitor the health of individual streams within a multiplexed connection. The ConnectionQuality event variable provides real-time quality metrics — packet loss rate, jitter buffer level, decoding error count, and average bitrate — for each stream. These metrics enable adaptive streaming scenarios where the control point can adjust source encoding parameters in response to changing network conditions or renderer load.
The explicit resource reservation capability in v2 ConnectionManager is a game-changer for quality-sensitive applications. A live video streaming application can check resource availability via GetResourceStatus before initiating a connection, ensuring that the renderer has sufficient decoder capacity and bandwidth to handle the stream. If resources are insufficient, the application can select an alternative renderer or negotiate a lower-quality stream rather than attempting a connection that would fail mid-stream.
Policy-based connection management must account for the interaction between v1 and v2 control points. A v2 device that imposes strict policy limits may reject connection requests from v1 control points that do not understand the policy framework. Implement a backward-compatibility mode that applies default (lenient) policies for v1-originated connections, reserving strict policy enforcement for v2-aware interactions where the control point can properly handle policy responses.
4. Frequently Asked Questions
Q: Can a v1 control point connect to a v2 ConnectionManager?
A: Yes, v2 ConnectionManager devices are required to implement the v1 service interface as a compatibility layer. The v2 device exposes both the v1 service URN (urn:schemas-upnp-org:service:ConnectionManager:1) and the v2 service URN (urn:schemas-upnp-org:service:ConnectionManager:2). V1 control points interact through the v1 interface and are limited to single-stream connections, while v2-aware control points access the enhanced features through the v2 interface.
A: Yes, v2 ConnectionManager devices are required to implement the v1 service interface as a compatibility layer. The v2 device exposes both the v1 service URN (urn:schemas-upnp-org:service:ConnectionManager:1) and the v2 service URN (urn:schemas-upnp-org:service:ConnectionManager:2). V1 control points interact through the v1 interface and are limited to single-stream connections, while v2-aware control points access the enhanced features through the v2 interface.
Q: How does the multi-stream connection handle stream synchronization?
A: The connection’s stream synchronization is governed by the stream’s timing model. For real-time streams (RTP/RTSP), synchronization uses RTCP sender reports. For HTTP-based streams, synchronization relies on the container format’s internal timing (MP4 timestamps, MPEG-PTS). The ConnectionManager provides the StreamSyncInfo state variable per stream, indicating the synchronization source and method in use.
A: The connection’s stream synchronization is governed by the stream’s timing model. For real-time streams (RTP/RTSP), synchronization uses RTCP sender reports. For HTTP-based streams, synchronization relies on the container format’s internal timing (MP4 timestamps, MPEG-PTS). The ConnectionManager provides the StreamSyncInfo state variable per stream, indicating the synchronization source and method in use.
Q: What happens when a control point requests a connection that exceeds the device’s policy limits?
A: The PrepareForConnection action returns error code 702 (No Such Connection) with a detailed error message indicating which policy limit was exceeded (e.g., “Maximum connections reached” or “Insufficient bandwidth for requested stream”). The control point can then query GetResourceStatus to understand the current utilization and either retry with reduced requirements or select a different renderer.
A: The PrepareForConnection action returns error code 702 (No Such Connection) with a detailed error message indicating which policy limit was exceeded (e.g., “Maximum connections reached” or “Insufficient bandwidth for requested stream”). The control point can then query GetResourceStatus to understand the current utilization and either retry with reduced requirements or select a different renderer.
Q: Can the ConnectionManager v2 support connection bridging between different network interfaces?
A: Yes, the enhanced direction model in v2 includes support for bridge connections that forward streams between different network interfaces. This is useful for devices that serve as UPnP proxies or gateways, allowing a MediaServer on a wired Gigabit Ethernet segment to stream to a MediaRenderer on a wireless 5 GHz segment through the bridging device’s ConnectionManager.
A: Yes, the enhanced direction model in v2 includes support for bridge connections that forward streams between different network interfaces. This is useful for devices that serve as UPnP proxies or gateways, allowing a MediaServer on a wired Gigabit Ethernet segment to stream to a MediaRenderer on a wireless 5 GHz segment through the bridging device’s ConnectionManager.
