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

ISO/IEC 29341-9-10 defines the ConnectionManager v3 service, a critical component of the UPnP AV architecture responsible for managing streaming connections between MediaServers and MediaRenderers. ConnectionManager acts as the negotiation broker: it determines whether a proposed connection between a source and sink is feasible given their respective protocol and format capabilities, manages active connection state, and provides event notifications when connection topology changes.

Version 3 of the specification introduces several important enhancements over v2, including support for multiple simultaneous connections per device, improved protocolInfo format strings with extended capability fields, and a new PrepareForConnection() action that enables advanced connection scenarios such as buffered streaming and content adaptation. These improvements reflect the growing complexity of home AV networks, where a single MediaRenderer may need to manage concurrent streams for picture-in-picture display or multi-room audio synchronization.

1. Overview of ConnectionManager v3 Architecture

The ConnectionManager v3 architecture centers around the concept of a “connection” — a unicast or multicast stream from a source (MediaServer) to a sink (MediaRenderer). Each connection is identified by a ConnectionID (integer) and maintains state including: AVTransportID (identifying the transport instance on the source), RcsID (identifying the rendering control instance on the sink), ProtocolInfo (describing the streaming protocol and content format), and Direction (input or output). The service maintains a ConnectionManager table that lists all active connections.

The core negotiation mechanism is the GetProtocolInfo() action, which returns three lists: Source (protocols/formats the device can send), Sink (protocols/formats the device can receive), and CurrentConnectionIDs (currently active connections). Each entry uses the protocolInfo format string: “protocol:network:contentFormat:additionalInfo”. For example, “http-get:*:video/mpeg:*” indicates the device can receive MPEG video over HTTP GET. The v3 specification extends the additionalInfo field to carry capability flags such as DRM requirements, resolution limits, and codec profiles.

Key Parameters

2. Protocol and Format Negotiation

The protocol negotiation in ConnectionManager v3 follows a intersect-and-match algorithm. When a Control Point requests a connection between a source and sink, ConnectionManager retrieves both devices’ protocolInfo lists, computes the intersection of compatible protocols and formats, selects the most preferred entry based on a configurable preference order (typically: highest quality, lowest latency, least resource consumption), and establishes the connection using the selected protocol. If the intersection is empty, the connection fails with error code 704 (format not supported).

The v3 specification introduces protocolInfo grouping through the “additionalInfo” field. Devices can declare capability flags such as: “DLNA.ORG_PS=1” (parameterized seek support), “DLNA.ORG_OP=1” (time-based seek), “DLNA.ORG_FLAGS=01700000000000000000000000000000” (DLNA media flags for playback capabilities). These flags allow fine-grained capability matching. For example, a MediaRenderer that supports H.264 video but only at 30 fps can declare “video/mpeg” with a capability constraint in additionalInfo, preventing a Control Point from sending 60 fps content that the renderer cannot handle.

The PrepareForConnection() action, new in v3, provides enhanced connection setup compared to the basic GetCurrentConnectionInfo() approach. It allows the Control Point to specify desired quality of service parameters, preferred transport protocol, and content format. The ConnectionManager can then pre-allocate resources (buffer memory, decoder instances) and return a ConnectionID immediately, while the actual stream setup proceeds asynchronously. This enables features like gapless playback and seamless source switching.

3. Implementation Strategies

Implementing ConnectionManager v3 efficiently requires careful resource management. Each active connection consumes system resources: socket descriptors, memory buffers (typically 64 KB to 2 MB per stream for jitter buffering), decoder instances, and bandwidth. The implementation must enforce configurable limits on concurrent connections — a typical home MediaRenderer might support 2-4 concurrent connections, while a MediaServer could handle 10-20. Exceeding these limits should return error code 501 (action failed) with a descriptive message.

The protocolInfo format string parsing is a frequent source of interoperability issues. The format is: protocol:network:contentFormat:additionalInfo, where protocol is one of “http-get”, “rtsp”, “rtp”, “internal” (vendor-specific), “iec61883” (for IEEE 1394), or vendor-defined strings. The contentFormat should use MIME types when possible (e.g., “video/mpeg”, “audio/L16;rate=44100;channels=2”). Implementations must be tolerant of whitespace variations and unknown capability flags — they should ignore unrecognized additionalInfo tokens rather than rejecting the entire protocolInfo entry.

For advanced deployments, ConnectionManager v3 supports connection monitoring through the CurrentConnectionIDs state variable and per-connection eventing. When a connection is added or removed, the service updates CurrentConnectionIDs and sends an event. Control Points can then query GetCurrentConnectionInfo() for details of each active connection. This mechanism is essential for implementing user interfaces that display “Now Playing” information or multi-room audio group management.

FAQ