Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-9-13: UPnP AV ConnectionManager v3 — Media Stream Connection Management
A detailed guide to ConnectionManager:3 — protocol negotiation, multi-connection support, connection lifecycle, enhanced error reporting, and streaming best practices.
Introduction to UPnP AV ConnectionManager v3
ISO/IEC 29341-9-13 defines version 3 of the UPnP AV ConnectionManager service, the component responsible for managing media stream connections between UPnP AV devices. While media servers and renderers handle content storage and playback, the ConnectionManager service is the orchestrator that establishes, maintains, and tears down the streaming connections. Version 3 extends the protocol with enhanced connection features: support for multiple simultaneous connections per direction, protocol-independent connection parameter negotiation, and improved error reporting for streaming failures.
The ConnectionManager service acts as a broker between a media server (source) and a media renderer (sink). It abstracts the transport protocol details — whether the stream uses HTTP, RTP, RTSP, or a proprietary protocol — from the control point, allowing a single control interface to manage diverse streaming technologies. The service exposes the available transfer protocols and data formats via the GetProtocolInfo action and manages active connections via the PrepareForConnection and ConnectionComplete actions.
Always call
GetProtocolInfo on both the source and sink devices before attempting to establish a connection. This ensures that the control point selects a protocol and content format that both devices support, avoiding unnecessary connection failures and retries.Protocol and Format Negotiation
The GetProtocolInfo action returns two key pieces of information from each device: the list of protocols it supports for receiving (sink capabilities) and the list for sending (source capabilities). Each protocol is described using a protocol information string that includes the network protocol, the content format MIME type, and additional transport parameters. The control point compares the source’s send capabilities with the sink’s receive capabilities to find compatible protocol-format pairs.
| Field | Description | Example (HTTP streaming) |
|---|---|---|
| Protocol | Network transport protocol | http-get |
| MIME Type | Content format identifier | video/mpeg |
| Additional Info | Protocol-specific parameters | *.mpeg, *.mpg |
In v3, the protocol information string has been extended to support advanced parameters such as streaming bitrate limits, encryption requirements, and DRM scheme identifiers. This allows a media server to indicate, for example, that a particular content can only be streamed over HTTPS with a minimum bitrate of 2 Mbps using AES-128 encryption. The control point must then find a sink that can meet all these requirements, or select a different content item with less restrictive requirements.
The extended protocol information in v3 increases the complexity of the matching algorithm. A naive implementation that performs simple string matching on the basic protocol field may incorrectly deem incompatible streams as compatible. Always parse the full protocol information structure, including the additional parameters, before making a compatibility determination.
Connection Lifecycle Management
The connection lifecycle in ConnectionManager:3 follows a well-defined sequence. First, the control point invokes PrepareForConnection on the sink device, which allocates internal resources and returns a connection ID and a CurrentConnectionIDs update. The control point similarly prepares the source device, though in some cases the source preparation is implicit (e.g., when using HTTP GET streaming, the source only needs to serve the content when the renderer requests it). Once both peers are ready, the actual data transfer begins through the negotiated protocol. Finally, ConnectionComplete is called on each device to release resources.
| Phase | Action(s) | Description |
|---|---|---|
| Preparation | PrepareForConnection | Allocate resources, assign ConnectionID, return transfer parameters |
| Transfer | (protocol-specific) | Actual media streaming via the negotiated protocol |
| Teardown | ConnectionComplete | Release resources, remove connection from active list |
| Query | GetCurrentConnectionInfo | Retrieve status and parameters of an active connection |
A key enhancement in v3 is the ability to have multiple active connections per direction. A media renderer can now receive multiple simultaneous streams — for example, a main video stream and an alternative audio commentary track — and blend them internally. The AVTransportID and RcsID returned by PrepareForConnection allow the control point to associate each connection with the appropriate AV Transport and RenderingControl service instances.
Take advantage of the v3 multi-connection support to implement picture-in-picture (PiP) functionality. Open one connection for the primary video stream and a second connection for the PiP stream, each associated with its own AV Transport service instance on the renderer.
Design Insights for Robust Streaming
One of the most valuable additions in ConnectionManager:3 is the enhanced error reporting via the ConnectionError state variable. When a connection fails mid-stream, the service sets this variable to a machine-readable error code and a human-readable description. Common error codes include NETWORK_FAILURE, PROTOCOL_MISMATCH, RESOURCE_UNAVAILABLE, and DRM_AUTHENTICATION_FAILED. This structured error reporting enables control points to implement intelligent retry logic and provide meaningful feedback to users.
For engineers designing AV streaming systems, the ConnectionManager service should be implemented with careful attention to resource limits. Each active connection consumes memory for buffering, potentially a network socket, and possibly hardware decoder resources on the renderer. The GetCurrentConnectionInfo action should be used by control points to monitor resource utilization and avoid exceeding capacity.
Failing to call
ConnectionComplete after a stream ends will leak resources on both the source and sink devices. Over time, this can exhaust available connections and prevent new streams from being established. Always implement a timeout or watchdog mechanism that tears down orphaned connections.Frequently Asked Questions
Q:
How does ConnectionManager:3 handle DRM-protected content?
A:
Version 3 extends the protocol information string to include DRM scheme identifiers. The control point is responsible for ensuring that both source and sink support the same DRM scheme before establishing the connection. If they do not, the connection will fail with a DRM_AUTHENTICATION_FAILED error.
Q:
Can I use ConnectionManager:3 for pure audio-only connections?
A:
Absolutely. The service is media-type agnostic. The protocol information negotiation covers audio MIME types such as audio/mpeg, audio/aac, and audio/flac just as effectively as video types. The same connection lifecycle applies.
Q:
What is the maximum number of simultaneous connections supported?
A:
This is device-dependent. The standard does not specify a maximum, but devices typically support between 8 and 64 simultaneous connections. The GetCurrentConnectionInfo action can be used to query the current connection count and detect when limits are approaching.
Q:
Does v3 support peer-to-peer connections between two media servers?
A:
No, the ConnectionManager service is designed for server-to-renderer connections. Peer-to-peer media transfer between servers would require a separate UPnP service or direct application-level implementation outside the scope of this standard.
