DLNA guidelines

June 2016 release

Part 1-2: Architecture and protocols –

eXtended Digital Media Renderer
An industry guide for
building interoperable
platforms, devices
and applications

Fulfilling the promise of the digital home requires a cross-industry effort to develop and promote
a common industry framework for interoperability. This industry framework is expressed
through the DLNA guidelines document that has been developed to provide Consumer
Electronic, Mobile Device and PC companies with the information needed to build interoperable
platforms, devices, and application for the digital home.

Do Not Copy
DIGITAL LIVING NETWORK ALLIANCE (DLNA) HAS BEEN DISSOLVED. THESE GUIDELINES ARE MADE
AVAILABLE TO YOU BY SPIRESPARK INTERNATIONAL, INC. WITH PERMISSION FROM DLNA

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 Legal Disclaimer
NOTHING CONTAINED IN THIS DOCUMENT SHALL BE DEEMED AS GRANTING YOU ANY
KIND OF LICENSE IN ITS CONTENT, EITHER EXPRESSLY OR IMPLIEDLY, OR TO ANY
INTELLECTUAL PROPERTY OWNED OR CONTROLLED BY ANY OF THE AUTHORS OR
DEVELOPERS OF THIS DOCUMENT. THE INFORMATION CONTAINED HEREIN IS
PROVIDED ON AN "AS IS" BASIS, AND TO THE MAXIMUM EXTENT PERMITTED BY
APPLICABLE LAW, THE AUTHORS AND DEVELOPERS OF THIS SPECIFICATION HEREBY
DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER EXPRESS OR IMPLIED,
STATUTORY OR AT COMMON LAW, INCLUDING, BUT NOT LIMITED TO, IMPLIED
WARRANTIES OF MERCHANTABILITY OF FITNESS FOR A PARTICULAR PURPOSE. DLNA
FURTHER DISCLAIMS ANY AND ALL WARRANTIES OF NONINFRINGEMENT, ACCURACY
OR LACK OF VIRUSES.

DLNA, DLNA CERTIFIED, and the logo are trademarks, registered trademarks, or servicemarks
of Digital Living Network Alliance in the United State or other countries.

*Other names and brands may be claimed as the property of others.

Copyright © 2007-2016 Digital Living Network Alliance. All rights reserved.

Copying or other form of reproductions and/or distribution of these works is strictly prohibited

DLNA guidelines; Part 1-2: Architecture and protocols - XDMR

 i

CONTENTS
1 Scope ............................................................................................................................... 1
2 Normative references ....................................................................................................... 1
3 Terms, definitions, symbols and abbreviated terms ........................................................... 1
3.1 General terms ......................................................................................................... 1
3.2 Symbols and abbreviated terms............................................................................... 2
3.3 Conventions ............................................................................................................ 3
4 Networking architecture, device models and guideline conventions .................................. 3
4.1 DLNA home networking architecture ........................................................................ 3
4.2 DLNA system usages .............................................................................................. 4
4.3 Document conventions and conventions .................................................................. 5
5 XDMR guidelines .............................................................................................................. 5
5.1 General ................................................................................................................... 5
5.2 Combined renderer-player functionality ................................................................... 5
Annex A (informative) Evolution of DMR and DMP device classes into an XDMR .................. 9

Figures:
Figure 1 — Main components in the XDMR Device Class........................................................ 4
Figure 2 — 2-box Pull usage model for an XDMR ................................................................... 4
Figure 3 — 2-box Push usage model for an XDMR ................................................................. 5
Figure 4 — 3-box usage model for an XDMR .......................................................................... 5
Figure A.1 — DMP protocol layers ........................................................................................ 10
Figure A.2 — DMR protocol layers ........................................................................................ 10
Figure A.3 — Protocols layers for the XDMR......................................................................... 10

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 -1-

Digital living network alliance (DLNA) guidelines

Part 1-2: Architecture and protocols – extended digital media renderer
1 Scope
The DLNA Guidelines Parts 1 to 3 introduce a number of device classes to identify specific roles
that connected endpoints implement in the network. Devices can act as content sources (e.g.,
Digital Media Servers, Push Controllers), and as content sinks (Digital Media Renderers or
Digital Media Players).

Having two types of content sinks has been a useful strategy to accelerate the initial deployment
phase. However, many of the modern receiver devices now include both types. Consequently,
there is a need to define a receiver device that combines both types. This document addresses
this issue and specifically, it describes a device class for an Extended Digital Media Renderer
(XDMR) and implementation guidelines for combining a Digital Media Renderer and an UPnP
Media Server Control Point.

2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.

IEC 62481-1-1, Digital living network alliance (DLNA) Guidelines - Part 1-1: Architecture and
protocols

IEC 62481-2, Digital living network alliance (DLNA) Guidelines - Part 2: Media format profiles

IEC 62481-3, Digital living network alliance (DLNA) Guidelines - Part 3: Link Protection

IEC 62481-4, Digital living network alliance (DLNA) Guidelines - Part 4: DRM Interoperability
Solutions

ISO/IEC 29341-3-10, Information Technology – UPnP Device Architecture – Part 3-10: Audio
Video Device Control Protocol – Audio Video Transport Service

ISO/IEC 29341-3-11, Information Technology – UPnP Device Architecture – Part 3-11: Audio
Video Device Control Protocol – Connection Manager Service

ISO/IEC 29341-1, Information Technology - UPnP Device Architecture - Part 1-1: UPnP Device
Architecture Version 1.0

ISO/IEC 29341-3-13, Information Technology - UPnP Device Architecture - Part 3-13: Audio
Video Device Control Protocol - Rendering Control Service

3 Terms, definitions, symbols and abbreviated terms

For the purposes of this document, the terms, definitions, symbols and abbreviated terms in
IEC 62481-1-1 and the following apply.

3.1 General terms

3.1.1
Comply
to be in accordance with referenced requirements. Where the reference includes both
mandatory and optional requirements, only the mandatory elements are considered necessary
for compliance. Optional requirements continue to be optional. Any variation from these
expectations shall be specifically noted. "Comply with" can be used interchangeably with
"conform to" (includes variations of complies, complying, compliant, compliance).

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 -2-

3.1.2
Conform
see "Comply" (includes variations of conforms, conforming, conformant, conformance).

3.1.3
Extended Digital Media Renderer
XDMR
a Digital Media Renderer (DMR) that also implements a Media Server Control Point (MSCP).
This device class defines the combined implementation of a Digital Media Renderer and a Digital
Media Player.

The guidelines established in this document define the requirements for implementing an
Extended Digital Media Renderer (XDMR) device class.

3.2 Symbols and abbreviated terms

3.2.1
AVT
"AVTransport Service" The AVTransport Service is a UPnP service that provides network-based
control for common transport operations such as play, stop, pause, next, previous, and seek.
The AVTransport Service specification is a standard UPnP DCP.

3.2.2
CDS
"ContentDirectory Service" The ContentDirectory Service is a UPnP service that provides
network-based discovery of content. The ContentDirectory Service specification is a standard
UPnP Device Control Protocol.

3.2.3
CMS
"ConnectionManager Service" The ConnectionManager Service is a UPnP service that provides
information about the supported transport protocols and media formats of a UPnP device. The
ConnectionManager Service specification is a standard UPnP Device Control Protocol.

3.2.4
DMP
"Digital Media Player" A DLNA Device Class having home network environmental characteristics
with the role of finding content exposed by a DMS and rendering the content locally.

3.2.5
DMR
"Digital Media Renderer" A DLNA Device Class having home network environmental
characteristics, with the role of rendering content it receives after being setup by another
network entity.

3.2.6
DMS
"Digital Media Server" A DLNA Device Class having home network environmental
characteristics, with the role of exposing and distributing content throughout the home.

3.2.7
DNS
“Domain Name System” A protocol that enables hierarchical names for Internet domains and
addresses. The protocol includes the means to translate between numerical IP addresses and
text host names.

3.2.8
MRCP
"MediaRenderer Control Point" A UPnP control point that issues actions to a DMR or and XDMR.

3.2.9
MSCP
"MediaServer Control Point" A UPnP AV control point that issues actions to a DMS.
DLNA guidelines; Part 1-2: Architecture and protocols - XDMR
 -3-

3.2.10
RCS
"RenderingControl Service" The RenderingControl Service is a UPnP service that provides
network-based control for the adjustment of rendering attributes such as volume, brightness,
contrast, and mute. The RenderingControl Service specification is a standard UPnP Device
Control Protocol.

3.2.11
XDMR
“Extended DMR” A device class defined to combine the functionality of a Digital Media Renderer
(DMR) and a Media Server Control Point (MSCP). This device class is equivalent to combining
previous device classes known as a DMR and a DMP.

3.3 Conventions
In this International Standard a number of terms, conditions, mechanisms, sequences,
parameters, events, states, or similar terms are printed with the first letter of each word in
uppercase and the rest lowercase (e.g., Move). Any lowercase uses of these words have the
normal technical English meaning.

4 Networking architecture, device models and guideline conventions

4.1 DLNA home networking architecture
See clause 4 in IEC 62481-1-1 for a full description of the DLNA home networking architecture
and is augmented as follows:

This document describes a device model referred to as an Extended Digital Media Renderer
(XDMR) matching the following DLNA classification:

• An XDMR is a Device Class that belongs to the Home Network Device (HND) category.
The XDMR Device Class unifies previous Device Classes known as Digital Media Renderer
(DMR) and Digital Media Player (DMP). Consequently, an XDMR behaves as a Content
Receiver for the following system usages: 2-box Pull, 2-box Push, and 3-box. These system
usages are defined in 5.7 of IEC 62481-1-1.

The XDMR Device Class includes the following functionality:

• A UPnP AV MediaRenderer combined with a UPnP AV MediaServer control point.

Sub-clause 5.2 of this standard specifies the corresponding implementation guidelines.
• A DNS Client that resolves domain names into IPv4 addresses as defined in IEC 62481-1-1.
• Support for HTTP protocol messages to request and receive media resources from servers
internal or external to the home network as defined in IEC 62481-1-1.
• Support for the AVT:SetNextAVTransportURI action as defined in IEC 62481-1-1.
Because an XDMR implements a UPnP AV MediaRenderer, any UPnP Control Point can send
AVT, RCS, and CMS actions to the XDMR and transfer URIs (and HTTP URLs) for playback.
Because an XDMR implements a UPnP AV MediaServer Control Point, an XDMR can send CDS
actions to UPnP AV MediaServers. Using terminology defined in IEC 62481-1-1, an XDMR
integrates previous functionality from the DMR device class and from the DMP device class.
Figure 1 shows the main components that characterize the XDMR device class.

Because an XDMR implements a DNS Client, the XDMR can process HTTP URLs that include
textual domain names. The DNS Client is used to resolve domain names into IPv4 addresses. As
defined in IEC 62481-1-1., an XDMR is capable of using generic HTTP URLs that identify media
resources located inside or outside the home network.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 -4-

Figure 1 — Main components in the XDMR Device Class

4.2 DLNA system usages

Figure 2, Figure 3, and Figure 4 illustrates the XDMR Device Class interactions with other
Device Classes according to the 2-box Pull, 2-box Push, and 3-box system usages respectively
and as defined in 5.7 of IEC 62481-1-1. The connection protocols identified by abbreviations in
Figure 2, Figure 3, and Figure 4 correspond to the following messages:

• B/S: Invoke UPnP actions to browse and/or search for content.

• RQ: Request content for playback.
• TR: Transfer the content binary data to the XDMR.
• SET: Invoke UPnP actions to determine the XDMR supported formats and to set up a
playback session.

Figure 2 — 2-box Pull usage model for an XDMR

DLNA guidelines; Part 1-2: Architecture and protocols - XDMR

 -5-

Figure 3 — 2-box Push usage model for an XDMR

Figure 4 — 3-box usage model for an XDMR

4.3 Document conventions and conventions

See clause 6 in IEC 62481-1-1 for a full description of the DLNA document conventions.

5 XDMR guidelines
5.1 General
See clause 7.1.1 in IEC 62481-1-1, for guideline and attribute table layout descriptions.

5.2 Combined renderer-player functionality

5.2.1 Architecture and protocols
5.2.1.1 Baseline rendering functionality
[G UIDELINE ] An Extended Digital Media Renderer shall comply with all the guidelines for the
DMR Device Class defined in IEC 62481-1-1, IEC 62481-2, IEC 62481-3, and IEC 62481-4.

[ATTRIBUTES ]

M R XDMR n/a n/a IEC 62481-1- 8ARO3

1
IEC 62481-2
IEC 62481-3
IEC 62481-4

[C OMMENT] An Extended DMR Device Class is simply a DMR as defined in IEC 62481-1-1 that
additionally implements an AV Media Server Control Point (MSCP). The MSCP component
brings the ability to do browse/search operations to the DMR. The original DLNA Guidelines
IEC 62481-1-1 leaves the MSCP component as an optional function for any DMR. This
document simply clarifies the expected behaviour for DMR devices that implement the MSCP
component.

5.2.1.2 Baseline Control Point functionality

[G UIDELINE ] An Extended Digital Media Renderer shall comply with all the guidelines for a
UPnP control point and UPnP AV MediaServer control point defined in IEC 62481-1-1,
IEC 62481-2, IEC 62481-3, and IEC 62481-4.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 -6-

[ATTRIBUTES ]

M R XDMR n/a n/a IEC 62481-1- 6B5AM

1
IEC 62481-2
IEC 62481-3
IEC 62481-4

[C OMMENT] An Extended DMR includes functionality for a DMR and for a Media Server Control
Point (MSCP). The MSCP allows an XDMR to communicate with DMS or M-DMS devices using
the Content Directory and Connection Manager Services.

5.2.1.3 Root device

[G UIDELINE ] The root device in a device description document may describe an Extended
Digital Media Renderer.

[ATTRIBUTES ]

O R XDMR n/a n/a IEC 62481-1- IRWDP

1
ISO/IEC
29341-1

[C OMMENT] An Extended DMR is simply a more complex DMR. An implementation can declare
a DMR or an XDMR as the root device in the device description document.

5.2.1.4 Embedded device

[G UIDELINE ] An embedded device in a device description document may describe an Extended
Digital Media Renderer.

[ATTRIBUTES ]

O R XDMR n/a n/a IEC 62481-1- LRQAA

1
ISO/IEC
29341-1

[C OMMENT] An Extended DMR is simply a more complex DMR. An implementation can declare
a DMR or an XDMR as one of the embedded devices in the device description document.

5.2.1.5 Identifier in device description document

[G UIDELINE ] An XDMR shall advertise a DMR implementation using <dlna:X_DLNADOC> in
the device description document with a value of DMR-1.50.

In addition, an XDMR shall use a second instance of the same element to advertise the
implementation of the Guidelines described in this document with a value of XDMR-1.50.

[ATTRIBUTES ]

M A XDMR n/a n/a IEC 62481-1- EQ5D7

1
ISO/IEC
29341-1

[C OMMENT] An Extended DMR advertises the implementation of a DMR in the device

description document. This is necessary for backward compatibility. Control Points access the
device description document to determine essential device characteristics. In addition to
advertising the DMR function, an Extended DMR advertises adherence to the XDMR guidelines.
Hence, the XDMR includes the following XML fragment in its device description document:
<dlna:X_DLNADOC xmlns:dlna=”urn:schemas-dlna-org:device-1-0”>DMR-1.50</dlna:X_DLNADOC>
DLNA guidelines; Part 1-2: Architecture and protocols - XDMR
 -7-

<dlna:X_DLNADOC xmlns:dlna=”urn:schemas-dlna-org:device-1-0”>XDMR-1.50</dlna:X_DLNADOC>

5.2.1.6 Value of protocolInfo for selected content

[G UIDELINE ] An XDMR shall be able to play any content with a protocolInfo value matching one
of the values listed in the CMS.SinkProtocolInfo instance state variable.

[ATTRIBUTES ]

M A XDMR n/a n/a IEC 62481-1- JGNTH

1
ISO/IEC
29341-3-11

[C OMMENT] An Extended DMR obtains content for playback using two methods. In one method
the XDMR receives an action request to play content from a UPnP Control Point. In the second
method, the XDMR can browse or search for external content using the UPnP AV MediaServer
Control Point component. This guideline indicates that regardless of the method used to obtain
content, the CMS.SinkProtocolInfo state variable describes the complete list of playable
protocolInfo values in an XDMR.

5.2.1.7 CMS state variables

[G UIDELINE ] The XDMR shall describe, expose, and update the CMS instance state variables
as a result of interactions in either mode of operation:

• The state variables are updated if the XDMR is externally controlled by a UPnP control point.
• The state variables are updated if the XDMR uses its UPnP AV MediaServer control point to
browse/search for content and then acquire the content directly from a UPnP AV
MediaServer.
[ATTRIBUTES ]

M A XDMR n/a n/a IEC 62481-1- LL5G6

1
ISO/IEC
29341-3-11

5.2.1.8 AVT state variables

[G UIDELINE ] The XDMR shall describe, expose, and update the AVT instance state variables
as a result of interactions in either mode of operation:

• The state variables are updated if the XDMR is externally controlled by a UPnP control point.
• The state variables are updated if the XDMR uses its UPnP AV MediaServer control point to
browse/search for content and then acquire the content directly from a UPnP AV
MediaServer.
[ATTRIBUTES ]

M A XDMR n/a n/a IEC 62481-1- 3NKWF

1
ISO/IEC
29341-3-10

5.2.1.9 RCS state variables

[G UIDELINE ] The XDMR shall describe, expose, and update the RCS instance state variables
as a result of interactions in either mode of operation:

• The state variables are updated if the XDMR is externally controlled by a UPnP control point.
• The state variables are updated if the XDMR uses its UPnP AV MediaServer control point to
browse/search for content and then acquire the content directly from a UPnP AV
MediaServer.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 -8-

[ATTRIBUTES ]

M A XDMR n/a n/a IEC 62481-1- 7IR4T

1
ISO/IEC
29341-3-13

5.2.1.10 Current track URI

[G UIDELINE ] As a corollary of guideline 5.2.1.8, the AVT.CurrentTrackURI instance state
variable shall describe the URI of the track currently playing in an XDMR. The XDMR obtains the
URI from a UPnP AV MediaRenderer control point or from a UPnP AV MediaServer.

[ATTRIBUTES ]

M A XDMR n/a n/a IEC 62481-1- FOQQM

1
ISO/IEC
29341-3-10

[C OMMENT]
a) The AVT.CurrentTrackURI state variable always includes the URI of the track that is
currently playing. This guideline simply clarifies that for an XDMR, the URI could have been
obtained from interactions with a UPnP AV MediaRenderer Control Point or from interactions
with a UPnP AV MediaServer.
b) If an XDMR interacts with a UPnP AV MediaRenderer control point, the track URI is obtained
from action arguments included in AVT:SetAVTransportURI and
AVT:SetNextAVTransportURI. The track URI can also be obtained from entries in media
collections. If an XDMR interacts with a DMS or M-DMS, the Media Server control point
(MSCP) component in an XDMR makes CDS:Browse or CDS:Search requests against the
server. The track URI is obtained from <res> elements included in the response to
CDS:Browse or CDS:Search actions.
5.2.2 Media Format profiles
[G UIDELINE ] An XDMR shall select content for playback with a Media Format Profile value that
matches one of the values included in the CMS.SinkProtocolInfo instance state variable.

[ATTRIBUTES ]

M R XDMR n/a n/a IEC 62481-1- LANIR

1
IEC 62481-2
IEC 62481-3
ISO/IEC
29341-3-11

[C OMMENT] An Extended DMR obtains content for playback using two methods. In one method
the XDMR receives an action request to play content from a UPnP Control Point. In the second
method, the XDMR can browse or search for external content using the UPnP AV MediaServer
Control Point component. This guideline indicates that regardless of the method used to obtain
content, the CMS.SinkProtocolInfo state variable describes the complete list of playable Media
Format Profiles in an XDMR.

This guideline applies to all Media Format Profiles including those defined for Link Protection

DLNA guidelines; Part 1-2: Architecture and protocols - XDMR

 -9-

Annex A (informative)

Evolution of DMR and DMP device classes into an XDMR

The DLNA Guidelines define two Device Classes that act as media sinks for the Device Category
of Home Networked Devices (HND). These two Device Classes are a Digital Media Renderer
(DMR) and a Digital Media Player (DMP).

Implementing a DMP is less complex than implementing a DMR. This is the reason why DLNA
Guidelines defines two separate Device Classes for media sinks. However, after several years
of successful deployments, it is now common that many devices implement both Device Classes.
There are several strategies that can be used to combine DMR and DMP devices but not all
strategies lead to interoperable solutions. This document describes the preferred strategy;
defining solutions that interoperate with legacy and future devices.

A DMP implementation uses the protocol layers shown in Figure A.1. Similarly, a DMR
implementation uses the protocol layers shown in Figure A.2. Notice that the two Device Classes
share many common components.

Figure A.3 shows a diagram of the combined DMP/DMR device described in this document.
Notice that this combined device includes a single instance for each of the common components
(blue boxes in Figs. A1-A3) plus all the specific components that belong exclusively to the DMP
or DMR.

If you compare the DMR (Figure A.2) with the combined DMP/DMR (Figure A.3), it is easy to
notice that they are very similar. In fact, the two figures show that the combined DMP/DMR can
be formed as follows:

• combined DMP/DMR = DMR + MSCP

For this reason, in this document the combined DMP/DMR is called an Extended DMR (XDMR)
described as follows:

• XDMR = DMR + MSCP

The published DLNA Guidelines IEC 62481-1-1 already acknowledges that DMRs can optionally
implement an MSCP component. Consequently, an XDMR is simply a DMR for which the MSCP
component becomes mandatory.

This document defines implementation guidelines for an XDMR Device Class. This document
also describes certain functionality applicable to controllers that interact with an XDMR. Most of
the functionality in an XDMR can be inferred from existing DLNA Guidelines and UPnP
specifications; hence this document mainly clarifies such behaviour.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 - 10 -

Figure A.1 — DMP protocol layers

Figure A.2 — DMR protocol layers

Figure A.3 — Protocols layers for the XDMR

DLNA guidelines; Part 1-2: Architecture and protocols - XDMR