Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC IEC 29341-3-11:2011 — UPnP Connection Manager Service
Managing Data Transport Connections in the UPnP AV Architecture
Role of the Connection Manager Service
ISO/IEC 29341-3-11:2011 defines the ConnectionManager:3 service, the UPnP AV component responsible for establishing, managing, and terminating data transport connections between media servers and renderers. The CMS acts as the negotiation broker — before any media data flows, the control point queries the CMS of both the source and sink devices to find a mutually supported transport protocol and content format. Once a compatible protocol is identified, the CMS allocates connection resources and provides the addressing information needed for the data plane.
Think of the CMS as the “switchboard operator” of the UPnP AV network. It does not handle media data itself; it only sets up the path. The actual streaming happens directly between the source and sink, making the architecture scalable — the CMS is not a bottleneck.
The CMS defines four key functional areas: protocol information exchange (GetProtocolInfo()), connection preparation and release (PrepareForConnection() and ConnectionComplete()), connection status query (GetCurrentConnectionInfo()), and connection enumeration (GetCurrentConnectionIDs()). These actions form a complete lifecycle for data transport management.
Protocol Negotiation and Capability Discovery
The ProtocolInfo Data Structure
The ProtocolInfo state variable is a comma-separated list of protocol information strings, each following the format: protocol:network:contentFormat:additionalInfo. The protocol field specifies the transport protocol (http-get, rtsp, internal, iec61883). The network field identifies the physical network type (* for any). The contentFormat field uses MIME types (video/mpeg, audio/mp3). The additionalInfo field carries protocol-specific parameters such as DLNA profile identifiers.
| Protocol | Typical Use Case | Content Types | Advantages |
|---|---|---|---|
| http-get | On-demand streaming, progressive download | Any file-based media | Firewall-friendly, uses existing HTTP infrastructure |
| rtsp | Live streaming, IPTV, surveillance | MPEG2-TS, RTP payloads | Real-time control, low latency |
| internal | Same-device playback (e.g., HDMI input) | Device-specific | Zero network overhead, hardware-accelerated |
| iec61883 | IEEE 1394 (FireWire) AV connections | DV, MPEG2-TS | Isochronous guaranteed bandwidth |
Connection Lifecycle Management
The PrepareForConnection() action is the central mechanism for connection establishment. It accepts RemoteProtocolInfo (the protocol info of the remote device), PeerConnectionManager (the URL of the remote CMS), and PeerConnectionID (the remote connection identifier). It returns a ConnectionID and AVTransportID (and optionally RcsID). The standard mandates that connections be explicitly released with ConnectionComplete() when no longer needed.
Resource leak warning:
ConnectionComplete() must be called for every successful PrepareForConnection(). Failure to do so depletes the CMS connection table. In embedded systems with limited memory, implement a watchdog timer that automatically releases orphaned connections after a configurable timeout (recommended: 30 minutes of inactivity).Engineering Design Insights for CMS Implementation
Implementing a robust CMS requires careful attention to concurrency. Multiple control points may invoke PrepareForConnection() simultaneously, and the CMS must serialize these requests to prevent double-allocation of the same connection slot. A reader-writer lock pattern is recommended: shared read access for GetCurrentConnectionInfo() and exclusive write access for PrepareForConnection() and ConnectionComplete().
The SourceProtocolInfo and SinkProtocolInfo state variables should be populated at device initialization time by enumerating all available codecs and transport handlers. For extensibility, consider a plugin architecture where third-party protocol handlers can register themselves with the CMS at runtime, updating these state variables dynamically.
Interoperability risk: Some early UPnP implementations use non-standard
ProtocolInfo formats with spaces or incorrect delimiters. When parsing a ProtocolInfo string, use a robust tokenizer that trims whitespace and accepts both comma and semicolon as delimiters. Reject malformed entries gracefully rather than failing the entire negotiation.Frequently Asked Questions
Q: What happens if the CMS runs out of connection slots?
The CMS returns error code 712 (CM_ERROR_OUT_OF_CONNECTIONS) when the maximum number of connections has been reached. The control point should either retry after releasing other connections or degrade gracefully by stopping existing streams.
The CMS returns error code 712 (CM_ERROR_OUT_OF_CONNECTIONS) when the maximum number of connections has been reached. The control point should either retry after releasing other connections or degrade gracefully by stopping existing streams.
Q: Can a single CMS manage connections for multiple media servers?
Yes. Each UPnP device has its own CMS instance, but a control point aggregates protocol capabilities across all CMS instances on the network. The home network may have multiple media servers and renderers, each with their own CMS.
Yes. Each UPnP device has its own CMS instance, but a control point aggregates protocol capabilities across all CMS instances on the network. The home network may have multiple media servers and renderers, each with their own CMS.
Q: How does the CMS handle network topology changes?
The CMS does not actively monitor network topology. When a connection is broken due to network changes, the renderer or server detects the transport failure and the control point should invoke
The CMS does not actively monitor network topology. When a connection is broken due to network changes, the renderer or server detects the transport failure and the control point should invoke
ConnectionComplete() followed by a new PrepareForConnection().Q: Is the internal protocol standardized across devices?
No. The
No. The
internal protocol is device-specific and used when the source and sink reside on the same physical device (e.g., an HDMI input feeding an internal display). The format and behavior are implementation-defined.
