ISO/IEC IEC 29341-15-10:2011 — UPnP AV ConnectionManager Service

Introduction to the ConnectionManager Service

ISO/IEC 29341-15-10:2011 defines the ConnectionManager:2 service, the component responsible for establishing and managing the data transport connections between media sources and sinks in the UPnP Audio/Video architecture. The ConnectionManager service acts as the middle layer between the content discovery functions of the ContentDirectory service and the playback control functions of the AVTransport and RenderingControl services. It provides the critical function of negotiating mutually supported transport protocols and media formats, allocating the necessary resources, and tracking the lifecycle of each media stream.

The service is identified by the service type urn:schemas-upnp-org:service:ConnectionManager:2. It introduces a formal connection model where each streaming session is represented by a ConnectionID integer. The service maintains an ordered list of active connections through the CurrentConnectionIDs state variable. The SourceProtocolInfo and SinkProtocolInfo state variables enumerate all transport formats that the device can originate or receive, respectively. Each protocol info entry follows the format: protocol:network:contentFormat:additionalInfo. For example, http-get:*:video/mpeg:DLNA.1.5 indicates HTTP GET transport for MPEG video with DLNA 1.5 extensions.

The ConnectionManager:2 revision introduced the concept of feature lists — XML documents that describe device capabilities beyond basic protocol negotiation. This allows devices to advertise support for specific codecs, resolutions, DRM systems, and transport enhancements. Feature lists are exchanged during the PrepareForConnection() negotiation phase, enabling intelligent matching of source capabilities to sink requirements. This is particularly important in heterogeneous environments where media servers and renderers from different vendors may support different subsets of the same base protocol.

Connection Lifecycle and Protocol Negotiation

The connection lifecycle in ConnectionManager:2 follows a well-defined sequence: (1) resource reservation via PrepareForConnection(), (2) data transport with optional monitoring, and (3) resource release via ConnectionComplete(). The PrepareForConnection() action takes the remote device’s protocol information, the peer ConnectionManager URL, and the direction of the media flow (Input or Output). The service then checks its capability table, selects a mutually compatible protocol, allocates internal resources, and returns a unique ConnectionID along with the negotiated protocol information.

Protocol negotiation in ConnectionManager:2 uses a two-phase matching algorithm. In Phase 1, the service compares the intersection of local and remote protocol info sets to identify common transport protocols and content formats. In Phase 2, for each compatible protocol, the service checks whether sufficient resources (bandwidth, decoder instances, memory) are available to support the connection. If multiple compatible protocols exist, the service selects the one that maximizes a preference metric (e.g., the protocol with the highest bitrate capability or lowest latency). The selected protocol’s complete info string is returned to the caller, which then uses it to configure the actual transport channel.

The GetCurrentConnectionInfo() action enables control points to query the status of an individual connection by its ConnectionID. The returned information includes the RenderingControlServiceID and AVTransportServiceID associated with the connection, enabling the control point to discover which playback services are managing the stream. It also returns the ProtocolInfo actually in use and the current Status (OK, ContentFormatMismatch, InsufficientBandwidth, etc.). This diagnostic information is invaluable for troubleshooting streaming failures in multi-vendor environments.

Resource Management and Eventing

Resource management is a central responsibility of the ConnectionManager service. The PrepareForConnection() action must check the availability of: (a) network bandwidth sufficient for the requested stream, (b) free connection slots (a device-specific maximum), (c) available hardware decoder instances for the requested format, and (d) memory buffers for the transport pipeline. If any resource is unavailable, the service returns an appropriate error code: 703 (InsufficientResources), 704 (IncompatibleProtocol), or 705 (ConnectionNotSupported).

The ConnectionManager:2 service uses GENA eventing to notify subscribed control points of changes in connection state. The CurrentConnectionIDs variable is evented — any change triggers a notification containing the updated list of active connection IDs. Control points that subscribe to this variable can maintain a real-time view of all active media streams. The CurrentProtocolInfo variable provides per-connection protocol details and is evented to support monitoring applications that need to track which formats are in use across the network.

Event notification optimization deserves careful attention in resource-constrained environments. During rapid state changes (e.g., when a control point quickly creates and tears down multiple connections), the ConnectionManager should coalesce event notifications within a 200ms window to avoid flooding the network with redundant GENA messages. The LastChange event payload should use an XML structure that aggregates all changes within the window into a single notification. Implementors should also support event key sequencing to help control points detect missed notifications during high-frequency update periods.

Engineering Insights for Implementation

Implementing a robust ConnectionManager:2 service requires addressing several practical challenges. The protocol info string parsing must be implemented as a state machine that handles edge cases such as empty fields (e.g., http-get:*:*:*), escaped characters, and malformed entries from non-compliant devices. Use a tokenizer that splits on commas while respecting quoted strings, and validate each token against the protocol:network:contentFormat:additionalInfo format. Reject entries that do not conform with a 402 (Invalid Args) error rather than silently ignoring them.

Another critical aspect is handling the scenario where a control point crashes or disconnects without calling ConnectionComplete(). The ConnectionManager should implement an inactivity watchdog that monitors each connection for transport activity. If no data flows through a connection for a configurable timeout period (typically 60 seconds), the service should automatically release the connection resources and update the CurrentConnectionIDs state variable. This self-healing mechanism prevents resource leaks that would otherwise degrade system performance over time in multi-user environments.

Interoperability testing with the UPnP AV certification test suite reveals several recurring issues. The most common compliance failure is incorrect propagation of the RenderingControlServiceID and AVTransportServiceID in GetCurrentConnectionInfo() responses. These service IDs must exactly match the service IDs advertised in the device description XML. Any mismatch causes control points (especially DLNA-certified ones) to fail when attempting to bind playback controls to the stream. Implement a self-test that verifies service ID consistency across the device description, ConnectionManager, and associated service instances during device initialization.

Frequently Asked Questions