DLNA guidelines

June 2016 release

Part 1-1: Architecture and protocols

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-1: Architecture and protocols

 i

CONTENTS
1 Scope ............................................................................................................................... 3
2 Normative references ....................................................................................................... 3
3 Terms, definitions, symbols and abbreviations ................................................................ 10
3.1 Terms and definitions ............................................................................................ 10
3.2 Symbols and abbreviations .................................................................................... 19
3.3 Conventions .......................................................................................................... 31
4 DLNA home network architecture ................................................................................... 31
4.1 General ................................................................................................................. 31
4.2 Networking and connectivity .................................................................................. 32
4.3 Device discovery and control ................................................................................. 33
4.4 Media management ............................................................................................... 33
4.5 Media formats ....................................................................................................... 34
4.6 Media transport ..................................................................................................... 34
4.7 Remote UI ............................................................................................................. 34
5 DLNA device model ........................................................................................................ 34
5.1 Overview ............................................................................................................... 34
5.2 Device model elements ......................................................................................... 34
5.3 Device Functions ................................................................................................... 36
5.4 Device Categories ................................................................................................. 37
5.5 Device Classes and roles ...................................................................................... 37
5.6 Device Capabilities and roles ................................................................................ 38
5.7 System usages ...................................................................................................... 38
5.8 Interoperability guidelines usage ........................................................................... 48
6 Guideline terminology and conventions .......................................................................... 50
6.1 Guideline compliance classifiers ............................................................................ 50
6.2 Standard or specification usage classifiers ............................................................ 51
6.3 Guideline font usage conventions .......................................................................... 51
6.4 Guideline syntax notation conventions ................................................................... 51
6.5 Guideline normative and informative text conventions ........................................... 52
6.6 DLNA XML namespaces and schemas .................................................................. 52
6.7 General rules on XML documents and fragments ................................................... 52
7 Guideline requirements overview .................................................................................... 52
7.1 General ................................................................................................................. 52
7.2 Conditions for measuring time in message exchanges ........................................... 55
8 Networking and connectivity ........................................................................................... 56
8.1 General ................................................................................................................. 56
8.2 Networking and connectivity: General capability requirements ............................... 56
8.3 Networking and connectivity: QoS requirements .................................................... 60
8.4 Networking and connectivity: device requirements ................................................. 66
9 Device discovery and control .......................................................................................... 71
9.1 General ................................................................................................................. 71
9.2 Device discovery and control guidelines ................................................................ 72
10 Media management ...................................................................................................... 114
10.1 AV media management ....................................................................................... 114
10.2 Content synchronization MM/CM guidelines ........................................................ 352
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 ii

10.3 Scheduled Recording Media Management guidelines .......................................... 365

10.4 Extended Tuner media management guidelines ................................................... 415
10.5 EPG Media management guidelines .................................................................... 443
11 Media Transport ........................................................................................................... 480
11.1 General ............................................................................................................... 480
11.2 Uniform Client Data Availability Model ................................................................. 482
11.3 Media Operations ................................................................................................ 484
11.4 Media Transport protocols ................................................................................... 485
12 Content transformation device virtualization ................................................................. 680
12.1 Theory of operations ........................................................................................... 680
12.2 Virtual device implementation .............................................................................. 682
12.3 Virtual device, Device Discovery and Control (DDC) ............................................ 683
12.4 Virtual device Media Management (MM) .............................................................. 687
12.5 Virtual device Media Formats (MF) ...................................................................... 703
12.6 Virtual device Media Transport (MT) .................................................................... 704
13 3D media rendering guidelines ..................................................................................... 705
13.1 705
13.2 705
13.3 705
13.4 706
13.5 706
Annex A (informative) Network Infrastructure Device (NID) recommendations .................. 707
A.1 General ............................................................................................................... 707
A.2 NID Functions ..................................................................................................... 707
A.3 NID recommendations ......................................................................................... 707
Annex B (informative) Basic Tuner representation ............................................................ 725
B.1 General ............................................................................................................... 725
B.2 Tuner objects ...................................................................................................... 725
B.3 Channel objects .................................................................................................. 725
B.4 Accessing a tuner channel................................................................................... 726
B.5 Tuner example .................................................................................................... 727
Annex C (informative) UPnP devices with multiple network interfaces ............................... 730
C.1 Representation at the UPnP Device level ............................................................ 730
C.2 Representation at the CDS level .......................................................................... 732
C.3 Understanding the "treated as or assumed to be routable" clause ....................... 733
C.4 Multiple <res> elements ....................................................................................... 733
Annex D (informative) Example applications of the Uniform Client Data Availability
Model ........................................................................................................................... 735
D.1 Uniform Client Data Availability Model definitions ................................................ 735
D.2 UCDAM and media operations............................................................................. 738
Annex E (informative) Auto-IP developer guidance ........................................................... 741
E.1 Goal .................................................................................................................... 741
E.2 Overview ............................................................................................................. 741
E.3 Suggested solution .............................................................................................. 742
E.4 Validation example using UPnP AV applications .................................................. 743
E.5 Installing routes during address transitions .......................................................... 746
Annex F (informative) RTP Protocol Stack and SDP/RTSP/RTCP Parameters .................. 748
Annex G (informative) Guidance on address conflict resolution in Auto-IP ........................ 751
DLNA guidelines; Part 1-1: Architecture and protocols
 iii

Annex H (informative) Wi-Fi Direct for DLNA .................................................................... 752

H.1 Wi-Fi Direct introduction ...................................................................................... 752
H.2 Wi-Fi Direct with system usages .......................................................................... 756
Annex I (informative) EPG Theory of Operation ................................................................ 765
I.1 Goal .................................................................................................................... 765
I.2 Usage scenarios.................................................................................................. 765
I.3 The model ........................................................................................................... 765
I.4 Implementation considerations ............................................................................ 767
Annex J (normative) Rating systems ................................................................................. 772
Annex K (normative) 3D media rendering guidelines for HDMI signal ................................ 781
K.1 Overview ............................................................................................................. 781
K.2 MPEG-2 3DFC format output mapping ................................................................. 781
K.3 MPEG-4 part 10 3DFC format output mapping ..................................................... 781
K.4 3D-capable renderer HDMI format conversion ..................................................... 783
K.5 HDMI backward compatible output signalling ....................................................... 783
Annex L Bibliography .......................................................................................................... 784
Annex M Live content use cases (Informative) .................................................................... 785
M.1 Introduction ......................................................................................................... 785
M.2 Live content use cases ........................................................................................ 785
M.3 Guidelines clarifications ...................................................................................... 786
M.4 Association with protocolInfo guidelines .............................................................. 787

Figures:
Figure 1 – DLNA functional components ............................................................................... 32
Figure 2 – DLNA device model terms hierarchy..................................................................... 36
Figure 3 – 2-box Pull system usage interaction model ........................................................... 40
Figure 4 – 2-box Push system usage interaction model ......................................................... 41
Figure 5 – 3-box system usage interaction model ................................................................. 41
Figure 6 – Download system usage interaction model ........................................................... 42
Figure 7 – Upload system usage interaction model ............................................................... 43
Figure 8 – Download Synchronization system usage interaction model ................................. 44
Figure 9 – Upload Synchronization system usage interaction model ..................................... 45
Figure 10 – Scheduled Recording system usage interaction model ....................................... 46
Figure 11 – EPG system usage interaction model ................................................................. 47
Figure 12 – Guideline layout and definitions ......................................................................... 53
Figure 13 – Visual map of possible values for the attribute tables ......................................... 55
Figure 14 – DLNA QoS visual organization ........................................................................... 60
Figure 15 – UPnP discovery robustness ................................................................................ 79
Figure 16 – DLNA PlayContainer URI example ................................................................... 238
Figure 17 – Recording conflict behavior .............................................................................. 392
Figure 18 – CDS and SRS object lifetimes .......................................................................... 410
Figure 19 – Extended Tuner and its containers ................................................................... 416
Figure 20 – Modeling DLNA Extended Tuner ...................................................................... 418
Figure 21 – UCDAM summary ............................................................................................. 483
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 iv

Figure 22 – Example of a valid and invalid pipelined POST transaction............................... 582

Figure 23 – Calculated Line ................................................................................................ 598
Figure 24 – Wall Clock Time sample accuracy distribution .................................................. 599
Figure 25 – Packet with Wall Clock Time Sample header extension .................................... 602
Figure 26 – Packet with another header extension following Wall Clock Time Sample......... 602
Figure 27 – BFR packet format ........................................................................................... 610
Figure 28 – Content transformation with a virtual MediaServer............................................ 682
Figure 29 – Content transformation with a virtual MediaRenderer ....................................... 682
Figure C.1 – UPnP Device representation ........................................................................... 730
Figure C.2 – UPnP device on multiple networks .................................................................. 731
Figure C.3 – Content URIs over multiple networks .............................................................. 733
Figure D.1 – Abstract representation of a stream ................................................................ 735
Figure D.2 – A stored content stream .................................................................................. 736
Figure D.3 – Stream with no random access support .......................................................... 736
Figure D.4 – Stream with random access support ............................................................... 736
Figure D.5 – Live stream with growing buffer and no random access .................................. 737
Figure D.6 – Live stream with growing buffer and random access ....................................... 737
Figure D.7 – Live stream with sliding buffer and random access support ............................. 738
Figure D.8 – Time-delayed live stream with sliding buffer and random access support ........ 738
Figure E.1 – IP mixed network (Auto-IP and DHCPv4) ........................................................ 742
Figure E.2 – Communication in mixed IP network. .............................................................. 744
Figure E.3 – New routes in address transition flow .............................................................. 747
Figure F.1 – Overview of the protocol stack for RTP transport ............................................ 748
Figure F.2 – SDP and RTSP Parameters ............................................................................ 749
Figure F.3 – RTCP Parameters ........................................................................................... 750
Figure H.1 – P2P Group ...................................................................................................... 753
Figure H.2 – Group formation simplified diagram ................................................................ 753
Figure H.3 – Device discovery procedure ............................................................................ 754
Figure H.4 – Intra-BSS distribution and Cross-connection ................................................... 756
Figure H.5 – 2-box system usage: Step 1............................................................................ 757
Figure H.6 – 2-box system usage: Step 2a .......................................................................... 758
Figure H.7 – 2-box system usage: Step 2b.1 ....................................................................... 759
Figure H.8 – 2-box system usage: step 2b.2 ....................................................................... 760
Figure H.9 – 3-box system usage: Step 1............................................................................ 761
Figure H.10 – 3-box system usage: Step 2a ........................................................................ 762
Figure H.11 – 3-box system usage: Step 2b.1 ..................................................................... 763
Figure H.12 – 3-box system usage: Step 2b.2 ..................................................................... 764
Figure M.1 – Live position to a TSB available data range .................................................... 786

Tables:
Table 1 – Key technology ingredients ..................................................................................... 1
Table 2 – DLNA Device Classes in the HND Device Category ............................................... 49
Table 3 – DLNA Device Capabilities ..................................................................................... 49
DLNA guidelines; Part 1-1: Architecture and protocols
 v

Table 4 – DLNA Device Classes in the MHD Device Category .............................................. 50

Table 5 – DLNA namespace values ...................................................................................... 52
Table 6 – Allowed values for change indicator fields in attribute tables ................................. 54
Table 7 – Normative priorities for DLNA traffic types ............................................................. 61
Table 8 – Color depth of device icons ................................................................................. 109
Table 9 – DMR serviceType and serviceID values............................................................... 119
Table 10 – DMS/M-DMS serviceType and serviceID values ................................................ 122
Table 11 – CDS and UPnP maximum byte length ................................................................ 124
Table 12 – Namespace prefixes .......................................................................................... 134
Table 13 – Recommended metadata properties .................................................................. 135
Table 14 – Required res@ metadata properties .................................................................. 135
Table 15 – Conditionally Required ResExt metadata properties .......................................... 136
Table 16 – Conditionally Required ResExt metadata properties .......................................... 136
Table 17 – CDS:Search minimum support of operators ....................................................... 217
Table 18 – UPnP:class for searching all CDS objects ......................................................... 219
Table 19 – Capability ID syntax .......................................................................................... 231
Table 20 – DLNA state variables for Controller-byte seek operations .................................. 282
Table 21 – Arguments for AVT:X_DLNA_GetBytePositionInfo ............................................. 284
Table 22 – Error codes for AVT:X_DLNA_GetBytePositionInfo ............................................ 285
Table 23 – Capability IDs for AnyContainer support ............................................................ 304
Table 24 – Required Media Class UPnP values .................................................................. 314
Table 25 – Required UPnP createClass elements ............................................................... 320
Table 26 – Capability ID syntax .......................................................................................... 356
Table 27 – UPnP AV MediaServer Metadata SearchCriteria ................................................ 358
Table 28 – dlna:objectType values ...................................................................................... 367
Table 29 – Guidelines for recorded CDS properties based on srs:class values ................... 368
Table 30 – Recommended recorded CDS properties based on srs:class value .................... 369
Table 31 – dlna:openDuration Property Type and Multi Value ............................................. 402
Table 32 – dlna:desiredPN property type and multi value .................................................... 405
Table 33 – dlna:PN property type and multi value ............................................................... 406
Table 34 – Capability ID syntax .......................................................................................... 413
Table 35 – Modulation format values .................................................................................. 424
Table 36 – CDS:X_DLNA_SelectChange action parameters................................................ 437
Table 37 – CDS:X_DLNA_SelectChange action error codes ............................................... 437
Table 38 – A_ARG_TYPE_DLNAChannelID state variable .................................................. 439
Table 39 – A_ARG_TYPE_DLNAConnectionID state variable ............................................. 440
Table 40 – DLNA Media Transfer modes ............................................................................. 480
Table 41 – Permitted combinations of DLNAQOS_UP and Transfer Mode per Media
Class .................................................................................................................................. 481
Table 42 – DLNA Streaming Media Operation definitions .................................................... 484
Table 43 – MT Media Class Transfer Modes ....................................................................... 486
Table 44 – HTTP prohibited operations references ............................................................. 560

Copyright © 2016 Digital Living Network Alliance.

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

Table A.1 – NID functions ................................................................................................... 707

Table A.2 – WMM Access Category mapping ...................................................................... 711
Table A.3 – WMM access and IEEE 802.1D priority ............................................................ 711
Table A.4 – MoCA Priority mapping .................................................................................... 715
Table A.5 – MoCA Access and IEEE 802.1D Priority ........................................................... 715
Table A.6 – HPNA Priority mapping .................................................................................... 717
Table A.7 – HPNA Access and IEEE 802.1D Priority ........................................................... 718
Table A.8 – Homeplug AV Priority mapping ......................................................................... 721
Table A.9 – HD-PLC PHY Priority mapping ......................................................................... 721
Table A.10 – Homeplug AV PHY access and IEEE 802.1 D priority ..................................... 722
Table A.11 – HD-PLC PHY access and IEEE 802.1 D priority ............................................. 723
Table E.1 – Auto-IP route ................................................................................................... 743
Table E.2 – DHCPv4 route .................................................................................................. 743
Table E.3 – Windows routing table example for device w/DHCP address ............................ 744
Table E.4 – Windows routing table example for device w/Auto-IP address. ......................... 745
Table E.5 – Linux routing table example for device w/DHCP address .................................. 745
Table E.6 – Linux routing table example for device w/Auto-IP address ................................ 746
Table L.1 – Rating sytems .................................................................................................. 780
Table K.1 – Examples of mapping of S3D_video_format_type information to HDMI VSI ...... 781
Table K.2 – Examples of mapping of SEI 3D format type information to HDMI VSI .............. 782

DLNA guidelines; Part 1-1: Architecture and protocols

 –1–

INTRODUCTION
Overview

Consumers are acquiring, viewing, and managing an increasing amount of digital media (photos,
music, and video) on devices in the Consumer Electronics (CE), Mobile Device, and Personal
Computer (PC) domains. Consumers want to conveniently enjoy that content, regardless of the
source, across different devices and locations in their homes. The digital home vision integrates the
Internet, mobile, and broadcast networks through a seamless, interoperable network, which will
provide a unique opportunity for manufacturers and consumers alike. In order to deliver on this
vision, it was recognized that a common set of industry design guidelines would be required to allow
companies to participate in a growing marketplace, leading to more innovation, simplicity, and value
for consumers.

The Digital living network alliance answered this challenge by taking the initiative to develop a
workable framework for interoperable product design. The DLNA Home Networked Device
interoperability guidelines have been created in a unique cross-industry effort that combined the
efforts of over 100 Consumer Electronics, PC-industry and Mobile Device companies from around
the world that worked together with the aim of achieving the world's first substantial platform for true
interoperability between personal computer and consumer electronic devices. The interoperability
guidelines provide product developers with a long-term architectural view, plus specific guidance for
IP-networked platforms, devices and applications in the home. The interoperability guidelines will
be introduced in phases over several years to accompany the market adoption of usages and the
availability of needed technology and standards.

The interoperability guidelines that are the object of this standard are based on an architecture (see
Clause 4) that defines interoperable components for devices and software infrastructure. It covers
physical media, network transports, device discovery and control, media management and control,
media formats, media transport protocols, and remote user interfaces. Table 1 shows a summary of
the key functional components and technology ingredients that are covered by these interoperability
guidelines.

Table 1 – Key technology ingredients

Functional components Technology ingredients

Connectivity Ethernet*, IEEE 802.11 (including Wi-Fi Direct), MoCA,

HD-PLC, HomePlug-AV, and HPNA
Networking IPv4 Suite, IPv6 Suite

Device Discovery and Control UPnP* Device Architecture

Media Management and Control UPnP AV, EnergyManagement, DeviceManagement

Media Formats Required and Optional Format Profiles

Media Transport HTTP (Mandatory), HTTP Adaptive Delivery (DASH) and

RTP
Remote User Interfaces HTML5, RVU

Device Profiles CVP-2

The protocols defined in this standard are based on the DLNA interoperability guidelines version 4.0.
Device implementations advertise adherence to the protocols selecting value 4.0 in the fields and
flags designed to expose the DLNA protocol version.

The interoperability guidelines are intended for the following audiences:

• Marketing professionals who specify requirements for home networked media products.

Copyright © 2016 Digital Living Network Alliance.

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

• Developers who design and build home networked media products.

• Quality assurance personnel who test and validate home networked media products.

DLNA guidelines; Part 1-1: Architecture and protocols

 –3–

Digital living network alliance (DLNA) guidelines

Part 1-1: Architecture and protocols
1 Scope
This part of DLNA guidelines specifies the core architecture and protocols of DLNA
implementations.

The interoperability guidelines consist of five parts covering Architecture and Protocols, Media
Formats, Link Protection, DRM Interoperability Systems and Device Profiles. This part of DLNA
guidelines provides vendors with the information needed to build interoperable networked platforms
and devices for the digital home. The necessary standards and technologies are now available to
enable products to be built for networked entertainment centric usages. However, standards and
technologies need to be clarified and options limited to ensure interoperability. The five parts of the
DLNA Home Networked Device interoperability guidelines fulfill that role.

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 60169-24, Radio-frequency connectors – Part 24: Radio-frequency coaxial connectors with
screw coupling, typically for use in 75 ohm cable distribution systems (Type F)

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-6-1, Digital living network alliance (DLNA) guidelines – Part 6-1: Remote User
Interface – HTML5

IEC 62481-6-2, Digital living network alliance (DLNA) guidelines – Part 6-2: RVU

IEC 62481-8, Digital living network alliance (DLNA) guidelines – Part 8: Diagnostics

IEC 62481-10, Digital living network alliance (DLNA) guidelines – Part 10: Low Power ModeI

ISO/IEC 13818-1, Information technology – Generic coding of moving pictures and associated
audio information: Systems

ISO/IEC 13818-2, Information technology—Generic coding of moving pictures and associated

audio (MPEG): Video.

ISO/IEC 13818-9, Information technology – Generic coding of moving pictures and associated
audio information – Part 9: Extension for real time interface for systems decoders, International
Standards Organization.

ISO/IEC 29341-1, Information technology – UPnP Device Architecture – Part 1-1: UPnP Device
Architecture

ISO/IEC 29341-1-2, Information technology — UPnP Device Architecture — Part 1-2: UPnP
Device Architecture Version 2.0

Copyright © 2016 Digital Living Network Alliance.

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

ISO/IEC 29341-3-2, Information technology – UPnP Device Architecture – Part 3-2: Audio Video
Device Control Protocol – Media Renderer Device 1

ISO/IEC 29341-20-3, Information technology – UPnP Device Architecture – Part 20-3: Audio
Video Device Control Protocol – Level 4 – Media Server Device 2

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

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

ISO/IEC 29341-20-12, Information technology – UPnP Device Architecture – Part 20-12: Audio
Video Device Control Protocol – Level 4 – Content Directory Service 2

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

ISO/IEC 29341-4-2, Information technology – UPnP Device Architecture – Part 4-2: Audio Video
Device Control Protocol – Level 2 – Media Renderer Device 3

ISO/IEC 29341-4-3, Information technology – UPnP Device Architecture – Part 4-3: Audio Video
Device Control Protocol – Level 2 – Media Server Device 4

ISO/IEC 29341-4-4, Information technology – UPnP Device Architecture – Part 4-4: Audio Video
Device Control Protocol – Level 2 – Audio Video Data Structures 3

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

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

ISO/IEC 29341-4-12, Information technology – UPnP Device Architecture – Part 4-12: Audio
Video Device Control Protocol – Level 2 – Content Directory Service 4

ISO/IEC 29341-4-13, Information technology – UPnP Device Architecture – Part 4-13: Audio
Video Device Control Protocol – Level 2 – Rendering Control Service 3

ISO/IEC 29341-4-14, Information technology – UPnP Device Architecture – Part 4-14: Audio
Video Device Control Protocol – Level 2 – Scheduled Recording Service 3

ISO/IEC 29341-14-3, Information technology – UPnP Device Architecture – Part 14-3: Audio
Video Device Control Protocol – Level 3 – Media Server Device 5

ISO/IEC 29341-14-12, Information technology – UPnP Device Architecture – Part 14-12: Audio
Video Device Control Protocol – Level 3 – Content Directory Service 5
___________

1 In this International Standard also referred to as AVv1.

2 In this International Standard also referred to as AVv4.
3 In this International Standard also referred to as AVv2, AVv3.
4 In this International Standard also referred to as AVv2.
5 In this International Standard also referred to as AVv3.

DLNA guidelines; Part 1-1: Architecture and protocols

 –5–

ISO 3166, Codes for the representation of names of countries and their subdivisions

ISO 8601, Data elements and interchange formats – Information interchange – Representation of
dates and times, International Standards Organization.

ITU-T G.9954, Recommendation, Home networking transceivers – Enhanced physical, media

access, and link layer specifications. ITU-T SG15/Q4 T-REC-G.9954-200701-I, Geneva,
Switzerland.
http://www.itu.int/rec/T-REC-G.9954-200701-I

ETSI TS 102 822-3, Broadcast and On-line Services: Search, select, and rightful use of content
on personal storage systems ("TV-Anytime"), Part 3: Metadata

ETSI TS 102 822-4, Broadcast and On-line Services: Search, select, and rightful use of content
on personal storage systems ("TV-Anytime"); Part 4: Content referencing

ETSI EN 300 468, Specification for Service Information (SI) in DVB systems, Digital Video
Broadcasting (DVB)

IEEE 802.1D, Annex G, IEEE Standard for Information technology – Telecommunications and
information exchange between systems – IEEE standard for local and metropolitan area networks –
Common specifications – Media access control (MAC) Bridges.
http://standards.ieee.org/getieee802/index.html

IEEE 802.1Q, IEEE Standard for Information Technology – Telecommunications and information
exchange between systems – IEEE standard for local and metropolitan area networks – Media
Access Control (MAC) Bridges and Virtual Bridged Local Area Networks--Corrigendum 2: Technical
and editorial corrections.
http://standards.ieee.org/getieee802/index.html

IEEE 802.3, IEEE Standard for Ethernet – Telecommunications and information exchange
between systems – Local and metropolitan area networks – Specific requirements – Part 3: Carrier
sense multiple access with collision detection (CSMA/CD) access method and physical layer
specification.
http://standards.ieee.org/getieee802/index.html

IEEE 802.11, System Interoperability Wi-Fi CERTIFIED™ Test Plan Version 2,0,36, Wi-Fi
CERTIFIED™ ac Interoperability Test Plan v1.0.5 Wi-Fi Alliance
http://www.wi-fi.org/testing_information.php

IEEE 1901, Standard for Broadband Over Power Line Networks: Medium Access Control and
Physical Layer Specifications
http://www.IEEE.org

IETF RFC 768, User Datagram Protocol, J. Postel.

http://www.ietf.org/rfc/rfc0768.txt

IETF RFC 791, Internet Protocol, J. Postel.

http://www.ietf.org/rfc/rfc0791.txt

IETF RFC 792, Internet Control Message Protocol, J. Postel.

http://www.ietf.org/rfc/rfc0792.txt

IETF RFC 793, Transmission Control Protocol, J. Postel.

http://www.ietf.org/rfc/rfc0793.txt

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 –6–

IETF RFC 826, An Ethernet Address Resolution Protocol – or – Converting Network Protocol
Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware, David C. Plummer.
http://www.ietf.org/rfc/rfc0826.txt

IETF RFC 1122, Requirements for Internet Hosts – Communications Layers, R. Braden.
http://www.ietf.org/rfc/rfc1122.txt

IETF RFC 1123, Requirements for Internet Hosts – applications and support.
http://www.ietf.org/rfc/rfc1123.txt

IETF RFC 1191, Path MTU Discovery, J. Mogul, DECWRL, S. Deering, Stanford University.
http://www.ietf.org/rfc/rfc1191.txt

IETF RFC 1305, Network Time Protocol (Version 3), Specification, Implementation and Analysis,
David L. Mills, University of Delaware.
http://www.ietf.org/rfc/rfc1305.txt

IETF RFC 1738, Uniform Resource Locators (URL), T. Berners-Lee, CERN, L. Masinter, Xerox
Corporation, M. McCahill, University of Minnesota.
http://www.ietf.org/rfc/rfc1738.txt

IETF RFC 1812, Requirements for IP version 4 Routers, F. Baker.

http://www.ietf.org/rfc/rfc1812.txt

IETF RFC 1945, Hypertext Transfer Protocol – HTTP/1.0, T. Berners-Lee, MIT/LCS, R. Fielding,
UC Irvine, H. Frystyk.
http://www.ietf.org/rfc/rfc1945.txt

IETF RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies, N Freed, N. Borenstein, November 1996
http://www.ietf.org/rfc/rfc2045.txt

IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
http://www.ietf.org/rfc/rfc2119.txt

IETF RFC 2131, Dynamic Host Configuration Protocol, R. Droms.

http://www.ietf.org/rfc/rfc2131.txt

IETF RFC 2145, Use and Interpretation of HTTP Version Numbers, J. C. Mogul, DEC, R. Fielding,
UC Irvine, J. Gettys, DEC, H. Frystyk, MIT/LCS.
http://www.ietf.org/rfc/rfc2145.txt

IETF RFC 2181, Clarifications to the DNA Specifications.

http://www.ietf.org/rfc/rfc2181.txt

IETF RFC 2234, Augmented BNF for Syntax Specifications: ABNF, Ed D. Crocker, Internet Mail
Consortium, P. Overell, Demon Internet Ltd.
http://www.ietf.org/rfc/rfc2234.txt

IETF RFC 2250, RTP Payload Format for MPEG1/MPEG2 Video, D. Hoffman, G. Fernando, Sun
Microsystems, Inc., V. Goyal, Precept Software, Inc. M. Civanlar, AT&T Labs – Research.
http://www.ietf.org/rfc/rfc2250.txt

IETF RFC 2279, UTF-8, a transformation format of ISO 10646, F. Yergeau, Alis Technologies.
http://www.ietf.org/rfc/rfc2279.txt

IETF RFC 2326, Real Time Streaming Protocol (RTSP), H. Schulzrinne, Columbia U., A. Rao,
Netscape, R. Lanphier, RealNetworks.
http://www.ietf.org/rfc/rfc2326.txt
DLNA guidelines; Part 1-1: Architecture and protocols
 –7–

IETF RFC 2327, SDP: Session Description Protocol, M. Handley, V. Jacobson, ISI/LBNL.
http://www.ietf.org/rfc/rfc0791.txt

IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, MIT/LCS, R.
Fielding, U.C. Irvine, L. Masinter, Xerox Corporation.
http://www.ietf.org/rfc/rfc2396.txt

IETF RFC 2429, RTP Payload Format for the 1988 Version of ITU-T Rec. H.263 Video (H.263+).
http://www.ietf.org/rfc/rfc2429.txt

IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers, K. Nichols, Cisco Systems, S. Blake, Torrent Networking Technologies, F. Baker, Cisco
Systems, D.Black, EMC Corporation.
http://www.ietf.org/rfc/rfc2474.txt

IETF RFC 2616, Hypertext Transfer Protocol – HTTP/1.1, R. Fielding, UC Irvine, J. Gettys,
Compaq/W3C, J. Mogul, Compaq, H. Frystyk, W3C/MIT, L. Masinter, Xerox, P. Leach, Microsoft, T.
Berners-Lee.
http://www.ietf.org/rfc/rfc2616.txt

IETF RFC 2766, Network Address Translation – Protocol Translation (NAT-PT), G. Tsirtsis, P.
Srisuresh.
http://www.ietf.org/rfc/rfc2766.txt

IETF RFC 2822, Internet Message Format, P. Resnick, QUALCOMM Incorporated.

http://www.ietf.org/rfc/rfc2822.txt

IETF RFC 2929, Domain Name System (DNS) IANA Considerations, D. Eastlake, E.
Brunner-Williams, B. Manning.
http://www.ietf.org/rfc/rfc2929.txt

IETF RFC 3066, Tags for the Identification of Languages.

http://www.ietf.org/rfc/rfc3066.txt

IETF RFC 3261, SIP: Session Initiation Protocol, J. Rosenberg, dynamicsoft, H. Schulzrinne,
Columbia U., G. Camarillo, Ericsson, A. Johnston, Worldcom, J. Peterson, Neustar, R. Sparks,
dynamicsoft, M. Handley, ICIR, E. Schooler, AT&T.
http://www.ietf.org/rfc/rfc3261.txt

IETF RFC 3267, Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for
the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs, J.
Sjoberg, M. Westerlund, Ericsson, A. Lakaniemi, Nokia, Q. Xie, Motorola.
http://www.ietf.org/rfc/rfc3267.txt

IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne, Columbia
University, S. Casner, Packet Design, R. Frederick, Blue Coat Systems Inc., V. Jacobson, Packet
Design.
http://www.ietf.org/rfc/rfc3550.txt

IETF RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control, H.
Schulzrinne, Columbia University, S. Casner, Packet Design.
http://www.ietf.org/rfc/rfc3551.txt

IETF RFC 3555, MIME Type Registration of RTP Payload Formats, S. Casner, Packet Design, P.
Hoschka, W3C/INRIA/MIT.
http://www.ietf.org/rfc/rfc3555.txt

Copyright © 2016 Digital Living Network Alliance.

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

IETF RFC 3556, Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control
Protocol (RTCP) Bandwidth, S. Casner, Packet Design.
http://www.ietf.org/rfc/rfc3556.txt

IETF RFC 3640, RTP Payload Format for Transport of MPEG-4 Elementary Streams, J. van der
Meer, Philips Electronics, D. Mackie, Apple Computer, V. Swaminathan, Sun Microsystems Inc., D.
Singer, Apple Computer, P. Gentric, Philips Electronics.
http://www.ietf.org/rfc/rfc3640.txt

IETF RFC 3927, Dynamic Configuration of IPv4 Link-Local addresses, Stuart Cheshire, Apple
Computer, B. Aboba, Microsoft Corporation, E.Guttman, Sun Microsystems.
http://www.ietf.org/rfc/rfc3927.txt

IETF RFC 3984, RTP Payload Format for H.264 Video, S. Wenger, M. M. Hannuksela, T.
Stockhammer, M. Westerlund, D. Singer.
http://www.ietf.org/rfc/rfc3984.txt

IETF RFC 3986, Uniform Resource Identifier (URI): General Syntax.

http://www.ietf.org/rfc/rfc3986.txt

IETF RFC 4184, RTP Payload Format for AC-3 Audio, B. Link T. Hager, Dolby Laboratories, J.
Flanks, Microsoft.
http://www.ietf.org/rfc/rfc4184.txt

IETF RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification.
http://www.ietf.org/rfc/rfc4343.txt

IETF RFC 4352, RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+)
Audio Codec, Johan Sjoberg, Magnus Westerlund, Ericsson, Ari Lakaniemi, Stephan Wenger,
Nokia.
http://www.ietf.org/rfc/rfc4352.txt

IETF RFC 4585, Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-based
Feedback (RTP/AVPF), Joerg Ott, Uni Bremen TZI, Stephan Wenger, TU Berlin, Noriyuki Sato, Oki,
Carsten Burmeister, Matsushita, Joe Rey, Matsushita.
http://www.ietf.org/rfc/rfc4585.txt

IETF RFC 4588, RTP Retransmission Payload Format, J. Rey, Panasonic, D. Leon, Nokia, A.
Miyazaki, Panasonic, V. Varsa, Nokia, R. Hakenberg, Panasonic.
http://www.ietf.org/rfc/rfc4588.txt

IETF RFC 4646, Tags for the Identification of Languages.

http://www.ietf.org/rfc/rfc4646.txt

IETF RFC 5452, Measures for Making DNS More Resilient against Forged Answers.
http://www.ietf.org/rfc/rfc5452.txt

IETF RFC 5952, A Recommendation for IPv6 Address Text Representation.

http://www.ietf.org/rfc/rfc5952.txt

IETF RFC 5966, DNS Transport over TCP – Implementation Requirements, Internet Engineering
Task Force (IETF).
http://www.ietf.org/rfc/rfc5966.txt

ANSI/CEA-766-C, U.S. and Canadian Rating Region Tables (RRT) and Content Advisory
Descriptors for Transport of Content Advisory Information Using ATSC Program and System
Information Protocol (PSIP).

ANSI/CEA-2033 A, Specification for Electronic Program Guide Data Interchange. ANSI/CEA.

DLNA guidelines; Part 1-1: Architecture and protocols
 –9–

ANSI/ICEA S-90-661, Category 3, 5, & 5e Individually Unshielded Twisted Pair Indoor Cable for
Use In General Purpose and LAN Communication Wiring Systems, Insulated Cable Engineers
Association.
http://www.icea.net/

ANSI/SCTE 128, AVC Video Systems and Transport Constraints for Cable Television
http://www.scte.org/documents/pdf/Standards/ANSI_SCTE%20128%202010-a.pdf

ANSI/SCTE 187-1, Stereoscopic 3D Formatting and Coding for Cable

http://www.scte.org/documents/pdf/Standards/ANSI_SCTE%20187-1%202012.pdf

AHRA, U.S. Audio Home Recording Act of 1992, United States Public Law 102-563, Subchapter D,
Section 1008.
http://thomas.loc.gov/cgi-bin/query/z?c102:S.1623.ENR:

ARIB TR B-14, Operational guidelines for Digital Terrestrial Television Broadcasting.

ARIB TR B-15, Operational guidelines for Digital Satellite Broadcasting.

ASF, Advanced System Format (ASF) Specification, Microsoft Corporation.

http://www.microsoft.com/windows/windowsmedia/format/asfspec.aspx

ATSC Standard A/52B, Digital Audio Compression (AC-3) Rev B, Advanced Television Systems
Committee.
http://www.atsc.org/standards/a_52b.pdf

CEA-708, Digital Television (DTV) Closed Captioning: 3D Extensions.

http://www.ce.org/Standards/Standard-Listings/R4-3-Television-Data-Systems-Subcommittee/CE
A-708-1.aspx

HD-PLC Connectivity Verification, Test Guide (111001)

HDMI, High-Definition Multimedia Interface, Specification, HDMI LLC,

http://www.hdmi.org/manufacturer/specification.aspx

HomePlug AV Specification, HomePlug Alliance

http://www.homeplug.org/

HomePlug AV Compliance, HomePlug Alliance

http://www.homeplug.org/

HomePlug AV Interoperability, HomePlug Alliance

http://www.homeplug.org/

MoCA MAC/PHY Specification, Multimedia over Coax Alliance

http://www.mocalliance.org/

MoCA Certification Test Plan, Multimedia over Coax Alliance

http://www.mocalliance.org/

OC-SP-CEP3.0-I04, OpenCableTM Specifications Content Encoding Profiles 3.0 Specification,

Cable Television Laboratories, Inc.
http://www.cablelabs.com/specifications/OC-SP-CEP3.0-I04-121210.pdf

RTP Payload format, RTP Payload Format for Windows Media Audio (WMA) and Video (WMV),
Microsoft Corporation.
http://download.microsoft.com/download/5/5/a/55a7b886-b742-4613-8ea8-d8b8b5c27bbc/RTPPa
yloadFormat_for_WMAandWMV_v1.doc
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 10 –

Universal Unique Identifier, DCE 1.1 Appendix for Universal Unique Identifiers, The Open Group.
http://www.opengroup.org/onlinepubs/9629399/apdxa.htm

Wi-Fi IEEE 802.11, with WPA2™, WPA™, and WEP System Interoperability Test Plan with ASD
Test Engine for IEEE 802.11a, b, and g Devices, Wi-Fi Alliance.
http://www.wi-fi.org/testing_information.php

Wi-Fi Simple Configuration, Wi-Fi Protected Test Plan, Wi-Fi Alliance

http://www.wi-fi.org/testing_information.php

Wi-Fi Direct System Interoperability, Test Plan, Wi-Fi Alliance

http://www.wi-fi.org/testing_information.php

WMM Specification, Wi-Fi WMM (Wireless Multimedia) Specification, Wi-Fi Alliance.

http://www.wi-fi.org

WMM Test Plan, Wi-Fi WMM System Interoperability Test Plan, Wi-Fi Alliance.
http://www.wi-fi.org/testing_information.php

W3C Namespaces, Namespaces in XML 1.0 (Third Edition)

http://www.w3.org/TR/xml-names/

W3C XML, Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation.
http://www.w3.org/TR/REC-xml

W3C XQuery, XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition)
http://www.w3.org/TR/2010/REC-xpath-functions-20101214/

XML Schema, for ContentDirectory:3 LastChange Event CDS:event-v1-2007

(cds-event-v3-20071128.xsd)
http://www.upnp.org/schemas/specs/av/av3.asp

3GPP TS 23.107, 3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Quality of Service (QoS) concept and architecture.
http://www.3gpp.org/ftp/Specs/archive/23_series/23.107/23107-620.zip

3GPP TS 26.244, 3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects;Transparent end to end packet switched streaming service (PSS); 3GPP file
format (3GP).
http://www.3gpp.org/ftp/Specs/archive/26_series/26.244/26244-640.zip

3 Terms, definitions, symbols and abbreviations

3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply. Abbreviations used in
this subclause are defined in 3.2.

3.1.1
Background Transfer
media transfer mode where the target content binary is transferred at any rate up to the maximum
achievable rate for the communication channel and the two communicating parties
Note 1 to entry: This mode is typically used for example when downloading or uploading content.
3.1.2
Basic Tuner
minimal DLNA tuner implementation based on ISO/IEC 29341-20-12.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 11 –

3.1.3
Bearer
physical and link-level network transport, such as IEEE 802.11

3.1.4
Byte-based Seek Operations
identify the rendering endpoint request and the content source response that allows the former to
obtain a segment of the content for playback, where such a segment is specified in units of bytes

3.1.5
Cacheable Content
content binaries whose binary representations remain static over time and are considered
cacheable content
Note 1 to entry: By default HTTP allows intermediate HTTP caches to store such items and respond to similar HTTP
requests as a means to accelerate the interaction with the user.
Note 2 to entry: In these interoperability guidelines cacheable content includes (but it is not limited to)
• Image, Audio, AV content that exists as stored files,
• content resulting from transcoding or encoding operations when the output binaries can be preserved over time.

3.1.6
Channel
one or more media streams that, together, constitute a unique entity for the purpose of
announcement, selection, and rendering
Note 1 to entry: For example, for digital television sources, a Channel is equivalent to an ATSC "virtual channel", a DVB
"service", or an MPEG-2 "Program". For digital radio sources, a Channel is equivalent to a single "station".
3.1.7
Channel Lineup Container
available tuner channels exposed in a CDS container for an Extended Tuner
Note 1 to entry: The content may or may not be streamed over the network.
3.1.8
Channelized Content
content that is available via a particular distribution channel such as a tuner and that is available on
that channel according to a schedule

3.1.9
Content
aggregation of one or more works

3.1.10
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 must be
specifically noted. "Comply with" can be used interchangeably with "conform to" (includes variations
of complies, complying, compliant, compliance).

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

3.1.12
Content Binary
binary representation of content for the purpose of storage or transfer over communication links

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 12 –

3.1.13
Content Transformation
transcoding, transrating, or scaling of a content binary

3.1.14
Content Source
endpoint that places content onto the network for transfer to another endpoint

3.1.15
Content Receiver
endpoint that consumes content received via a network transfer from another endpoint

3.1.16
Controller-byte Seek Operations
identifies the Control Point request and the UPnP AV MediaRenderer response that allows the
former to specify a segment of the content to be rendered by the latter, where such a segment is
specified in units of bytes

3.1.17
Controller-time Seek Operations
identifies the Control Point request and the UPnP AV MediaRenderer response that allows the
former to specify a segment of the content to be rendered by the latter, where such a segment is
specified in units of time

3.1.18
Converted Content
content that is either transcoded, transcripted, remuxed, or transformed in any other way

3.1.19
Decoder Friendly Point
point in the stream where the decoder can begin to process data without any other internal state
information about the stream
Note 1 to entry: The decoder can begin processing at that point and create a valid output rendering.
3.1.20
Device Capability
set of Device Functions (at least 1) aggregated to support a system usage
Note 1 to entry: A Device Capability cannot stand alone, and shall be deployed in conjunction with an implementation of
a valid DLNA Device Class. Since a Device Capability does not stand alone, it is not required to have components in all
layers of the DLNA architecture. A Device Capability can have a one to one correspondence to a Device Function. A
Device Capability is a certifiable entity only when it is implemented as an addition to at least one Device Class.
3.1.21
Device Category
group of Device Classes with the same environmental characteristics and sharing common system
usages that are enabling home networking use case scenarios.
Note 1 to entry: Examples of device categories used within this standard (IEC 62481-1-1) are HND (Home Network
Device), and MHD (Mobile Handheld Device).
Note 2 to entry: While Device Classes are grouped within a Device Category, a single physical device can support Device
Classes that fall into multiple Device Categories.

3.1.22
Device Class
set of Device Functions
Note 1 to entry: A Device Class specifies the features supported on a device regardless of its physical attributes.
Note 2 to entry: Examples used within this standard (IEC 62481-1-1) are DMS (Digital Media Server) and DMP (Digital
Media Player).

DLNA guidelines; Part 1-1: Architecture and protocols

 – 13 –

Note 3 to entry: A single device can support multiple Device Classes. A DLNA device shall support at least one Device
Class and can support one or more Device Capabilities.
Note 4 to entry: A Device Class is the certifiable entity in DLNA.
3.1.23
Device Function
non-decomposable operational property
EXAMPLE IP Connectivity
Note 1 to entry: Device Functions should be supported by existing standards.

3.1.24
Device Option
optional extensibility to existing DLNA architecture
Note 1 to entry: A Device Option can add optional extensibility to an existing Device Function or add new optional Device
Function to the DLNA architecture
3.1.25
Device Type
device defined by its realization and its usage models
EXAMPLES DVD players, TVs, DVRs, Mobile Phones, Cameras, Picture Frames, etc.
Note 1 to entry: Device Types are primarily used for marketing descriptions, and they should not be used in guideline
definitions.

3.1.26
DLNA Recognized Metatadata Format
valid content metadata that is recognized and accepted by DNLA
Note 1 to entry: DLNA recognizes three formats of content metadata (OpenEPG, TV-Anytime, and DVB-SI).
Note 2 to entry: Mappings for elements of each of these formats are provided for certain native DLNA EPG data items.
3.1.27
DLNA Recognized Rating Authorities
authorities referenced and recogized by DNLA
Note 1 to entry: DLNA recognizes certain rating authorities and their associated rating codes.
Note 2 to entry: These Rating Athorities and their codes are listed in Annex J.

3.1.28
DLNAQOS
DLNA defined QoS model used in this standard (IEC 62481-1-1)

3.1.29
EPG Item
CDS item that describes a piece of content that usually does not reside on the local server
Note 1 to entry: It refers to a broadcast item that is available through a tuner, or it can be content accessible via a URL.
Note 2 to entry: In general there is a time associated with an EPG item that describes the broadcast time and duration of
the content or the time period in which it is available for on demand retrieval via an URL. Items described by an EPG item
can be recorded with the SRS service and can then actually reside on a local server.
3.1.30
Exposed
content that is listed by a UPnP AV ContentDirectory Service (CDS)
Note 1 to entry: Content does not necessarily exist at the time that it is exposed (for example, needs transcoding or
conversion).

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 14 –

3.1.31
Extended Tuner
DLNA tuner implementation based upon the TUNER Feature defined in ISO/IEC 29341-4-12 and
higher specifications

3.1.32
Full TS
piece-wise constant rate MPEG-2 Transport Stream that is fully compliant with ISO/IEC 13818-1,
2.4.2.2
Note 1 to entry: A Full TS is characterized by a consistent temporal relationship (or "even spacing") between any two
adjacent TS Packets.
3.1.33
HD Capable Device
a DLNA Device Class that is certified for a DLNA AV Media Format Profile that has an HD video
component
Note 1 to entry: For example an AV Media Format Profile with a resolution greater than or equal to 1280x720p.
3.1.34
Ideal Network Conditions
network state used only for testing and validation of guideline compliance
Note 1 to entry: The effective network capacity shall be substantially greater than the aggregate bandwidth of the content
under test, and there are no additional devices competing for available network resources at the time of test.
3.1.35
Instance State Variable
state variable defined by AVTransport and RenderingControl services
Note 1 to entry: Instance State Variables are state variables associated with a virtual instance of a service. Both services
use an evented state variable by the name of LastChange, to report a value change of an instance state variable.

3.1.36
Interactive Transfer
media transfer mode where the target content binary is transferred at the maximum achievable rate
for the communication channel and the two communicating parties
Note 1 to entry: This mode is typically used when sending images for immediate display.
3.1.37
Link-level Bearer
restricts the bearer concept to include only the physical layer and link-layers as described for the
ISO's OSI model

3.1.38
Link Protection
protection of a content stream between two devices on a DLNA network from illegitimate
observation or interception

3.1.39
Media Class
type of media a Device Type or Device Class supports
Note 1 to entry: The Media Classes used in this standard are Image, Audio only, and Video with Audio (AV).

3.1.40
Media Collection File
content binary whose purpose is to reference other content binaries usually for sequenced playback
Note 1 to entry: Media collection files are often used for audio or AV playlists or image slideshows.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 15 –

3.1.41
Media Format
format type for content of a Media Class that is exposed by a UPnP AV MediaServer contained in a
device that acts as a DMS
Note 1 to entry: Examples for the Media Classes are: Image – JPEG; Audio – LPCM; AV – MPEG-2.
3.1.42
Media Stream
single elementary stream or MPEG-2 TS or MPEG-2 PS multiplex
Note 1 to entry: This definition applies to Media Stream as used for the RTP Media Transport.
3.1.43
Media Transfer Mode
type of transfer used to deliver content from a Content Source to a Content Receiver
Note 1 to entry: There are three types of DLNA media transfer modes: Streaming Transfer, Interactive Transfer, and
Background Transfer.

3.1.44
Native Device
device that creates a virtual server and adds functionality to an existing server in the network
Note 1 to entry: The existing server in the network is known as the Native Server.
Note 2 to entry: Either a Native Server or Native Renderer is known as a Native Device. These Native Devices are in
contrast to a Virtual Server or Renderer (see 3.1.76 and 3.1.77).
3.1.45
Native Device
device that creates a virtual renderer and adds functionality to an existing renderer in the network
Note 1 to entry: The existing renderer in the network is known as the Native Renderer.
Note 2 to entry: Either a Native Server or Native Renderer is known as a Native Device. These Native Devices are in
contrast to a Virtual Server or Renderer (see 3.1.76 and 3.1.77).
3.1.46
Network De-Jitter Buffer
Buffer space that is used to store data for de-jittering and de-interleaving, including RTP header and
payload
Note 1 to entry: This definition applies to Network De-Jitter Buffer as used for the RTP Media Transport.
3.1.47
Non-Cacheable Content
content binaries whose binary representations are valid only for one particular transaction at a
particular instant of time
Note 1 to entry: Intermediate HTTP caches need directives to prevent the default caching of such content. In the IEC
62481 series of standards the non-cacheable content includes (but it is not limited to):
• live TV streams;
• content resulting from transcoding or encoding operations when the output binaries have been optimized for a
particular transaction (e.g. encoding to match the channel conditions for a given transaction).
3.1.48
Non-Streamable Channel Object
non-streamable CDS objects (i.e. no <res> property value) which represent a single channel of a
broadcast source that presents content in a “channelized” format
Note 1 to entry: Since these CDS items are not streamable, a <res> property value is not needed. But having a <res>
property without a URI value can be useful by UPnP AV MediaServer control points in determining the Media Format
Profile for the Non-Streamable Channel Object by examining the res@protocolInfo property’s DLNA.ORG_PN value in the
fourth field.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 16 –

3.1.49
Open-end Recording
recording which the scheduled duration is not specified for
Note 1 to entry: The duration of an open-end recording is determined by the UPnP AV MediaServer.
3.1.50
Partial SPTS
partial MPEG-2 Transport Stream which is also a Single Program Transport Stream (SPTS)

3.1.51
Post-decoder Buffer
buffer space used to store decompressed data before rendering.
Note 1 to entry: This definition applies to Post-decoder Buffer as used for the RTP Media Transport.
3.1.52
Power Save Operation
Support for intermediate power consumption states between zero (power OFF) to nominal power
consumption during active use of a device.

3.1.53
Pre-decoder Buffer
hypothetical reference decoder buffer that is used to contain a media (audio/video) stream after it
has arrived from the network and before it is decoded into a renderable frame
Note 1 to entry: This definition applies to Pre-decoder Buffer as used for the RTP Media Transport.
3.1.54
Primary ProtocolInfo Set
first, second, and third fields of protocolInfo plus the additional DLNA.ORG_PN value which
appears in the fourth field
Note 1 to entry: In other words, the primary set defines a transport method (first value), a mime type (third value), and a
DLNA Media Format Profile.
3.1.55
Receiver Buffer
total buffer space used to store data received from the server before the decoding
Note 1 to entry: This definition applies to Receiver Buffer as used for the RTP Media Transport.
3.1.56
Receiving Endpoint
defined specifically through guideline 11.4.4.5, which requires an RTP client and an RTSP client

3.1.57
Rendering Endpoint
Content Receiver devices with the capability of rendering the content they receive
Note 1 to entry: These devices could play the content at the time of the transfer, right after the transfer has finished, or
at a later time after the transfer has finished.
Note 2 to entry: For the purposes of this standard, devices in the following Device Classes constitute the only known
Rendering Endpoints: DMP, DMR, M-DMP.
3.1.58
Remote UI
user interface provided by an application on a server device, that can be rendered by one or more
client devices

3.1.59
RTP Media Transport
mechanism for real-time media streams between DLNA device classes and capabilities
DLNA guidelines; Part 1-1: Architecture and protocols
 – 17 –

Note 1 to entry: This transport mechanism uses RTP, RTCP, RTSP, SDP protocols, and RTP payload formats with their
associated media profiles.
3.1.60
RTP Session
one or more RTP Streams that are transmitted to the same destination IP address and UDP port
Note 1 to entry: Typically, there is a one-to-one mapping between RTP Streams and RTP Sessions, but it is possible for
multiple RTP Streams to use the same RTP Session (port multiplexing). Note that associated RTCP traffic is also part of
that RTP Session although the packets are sent to the next higher UDP port number.
3.1.61
RTP Stream
Media Stream that is encapsulated in RTP
Note 1 to entry: All of the RTP packets have the same SSRC and are transmitted on the same RTP Session.
3.1.62
RTSP Session
complete RTSP "transaction", for example the viewing of a movie
Note 1 to entry: A session typically consists of a client creating one or more RTP Sessions (SETUP), starting the stream
with PLAY or RECORD, and closing the RTSP Session with TEARDOWN. RTSP Sessions are identified using the RTSP
"Session" header.
3.1.63
Scaling
changing the visual extent of an image or video portion of an AV media stream

3.1.64
Serving Endpoint
defined specifically through guideline 11.4.4.4, which includes the RTP server and RTSP server

3.1.65
Streamable Channel Object
Non-Streamable Channel Object with one or more <res> properties containing valid URI values for
an Extended Turner
Note 1 to entry: This enables content for a tuner channel to be streamed over the network.
3.1.66
Streaming Transfer
for Audio and AV streams the packets are transferred minimally at a rate sufficient for real-time
rendering
Note 1 to entry: This definition does not imply that the receiving endpoint will always render content exchanged using
Streaming Transfer (e.g., it might store the content).
3.1.67
System Usage
device interaction model between Device Classes and/or Device Capabilities
Note 1 to entry: System Usages are derived when enabling home networking use case scenarios.

3.1.68
Test Conditions
implies that all of the following conditions are satisfied:

• there is only 1 Content Receiver and only 1 Content Source;

• there is only 1 active connection at any given time;
• both devices (Content Receiver and Content Source) are configured by vendors before testing
begins to have sufficient resources to successfully complete the stated test requirements;

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 18 –

• devices interact with each other under Ideal Network Conditions

3.1.69
Thrashing
occurs in a synchronization system that consists of a server and multiple clients
Note 1 to entry: Thrashing is a deadlocked system state where the clients are changing items on the server multiple times
in the same way without user intervention. For example, in a system with a server (S) containing a single item (I) and two
clients (A and B), if client A makes a change to I and that change causes client B to change I, thrashing can occur if A and
B now continue to make the same changes that they had previously made to item I without user intervention or
authorization. Because the change from A generates the automatic change from B which generates a repeat of the change
from A, the system is deadlocked.
3.1.70
Time-based Seek Operations
identifies the Rendering Endpoint request and the Content Source response that allows the former
to obtain a segment of the content for playback, where such a segment is specified in units of time

3.1.71
Transcoding
changing of the coding system used for a content binary

3.1.72
Transrating
changing the rate or compression parameters used within the coding system for a content binary

3.1.73
UHD Capable Device
a DLNA Device Class that is certified for a DLNA AV Media Format Profile that has an UHD video
component
Note 1 to entry: For example an AV Media Format Profile with a resolution greater than 1920x1080p.
3.1.74
UPnP
architecture for pervasive peer-to-peer network connectivity of devices of all form factors
Note 1 to entry: It is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged
networks whether in the home, in a small business, public spaces, or attached to the Internet. It is a distributed, open
networking architecture that leverages TCP/IP and Web technologies to enable seamless proximity networking in addition
to control and data transfer among networked devices in the home, office, and public spaces.

3.1.75
Virtual Instance
mechanism by which a UPnP device can have multiple instances of the same UPnP service
Note 1 to entry: Control points that interact with the AVTransport and RenderingControl services shall interact with a
virtual instance of the service. Each virtual instance is identified by a non-negative InstanceID value.

3.1.76
Virtual Renderer
DMR that accepts content and sends it to another DMR within the network for rendering
Note 1 to entry: A Virtual Renderer accepts a wider range of content types, formats, rates, or sizes than the Native
Device.
3.1.77
Virtual Server
DMS or M-DMS which exposes content existing on another DMS or M-DMS, possibly containing
additional media types, through content transformation

DLNA guidelines; Part 1-1: Architecture and protocols

 – 19 –

3.1.78
Virtual Tuner Container
CDS container for an Extended Tuner that contains only CDS items (Virtual Tuner Objects) that
allow channels to be streamed using a single connection (i.e. switch the content stream from one
channel to another over the same URI connection)

3.1.79
Virtual Tuner Object
CDS item in an Extended Tuner that allow channels to be streamed using a single connection (i.e.
switch the content stream from one channel to another over the same URI connection)

3.1.80
VLAN Tag
field on a layer-2 packet header defined by IEEE 802.1Q

3.2 Symbols and abbreviations

For the purposes of this document, the following symbols and abbreviated terms apply.

3.2.1
∆T PCR
as used for the RTP Media Transport, this value is the difference in time, measured in 90 kHz clock
units, between successive PCR values in the TS stream. It is represented mathematically as:

∆T PCR = PCR n + 1 – PCR n

This value is utilized in timestamp equations in 11.4.4.77.

3.2.2
3DFC
3D Frame Compatible

3.2.3
ADU
Application Data Unit

as used for the RTP Media Transport: The definition of an ADU is different for each media stream.
For audio media streams, an ADU is typically an audio frame. For video media streams, an ADU is
typically a "slice" (e.g. an NAL unit) or in some cases a complete video picture. Also, as a special
case when MPEG-2 TS encapsulation is used, each TS packet is an ADU.

3.2.4
ACK
Acknowledge

typically used to describe an action following a network packet being successfully received

3.2.5
AFD
Active Format Descriptor

3.2.6
AP
Access Point

a specially configured Network Infrastructure Device on a wireless local area network (WLAN).
Access point acts as a central transmitter and receiver of WLAN radio signals. APs used in home

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 20 –

networks are generally small, dedicated hardware devices featuring a built-in network adapter,
antenna, and radio transmitter. These APs support Wi-Fi wireless communication standards.

3.2.7
ARP
Address Resolution Protocol

protocol in the TCP/IP family that resolves an IPv4 address to a hardware address, such as an
Ethernet address

3.2.8
ATSC
Advanced Television Systems Committee

one of the standard bodies for digital television broadcasting

3.2.9
AV
Audio with Video

media content that contains both moving picture and sound

3.2.10
AVP
Audio/Visual Profile

as used for the RTP Media Transport

3.2.11
AVPF
Extended Audio/Visual Profile for RTCP-based Feedback

as used for the RTP Media Transport

3.2.12
AVT
AVTransport Service

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.13
BK
Background User Priority

priority-based QoS level for Background User Priority

3.2.14
BE
Best-Effort User Priority

priority-based QoS level for Best-Effort User Priority

3.2.15
CDB
Coded Data Buffer

DLNA guidelines; Part 1-1: Architecture and protocols

 – 21 –

as used for the RTP Media Transport. Buffer space that is used to store compressed data before
decoding.

3.2.16
CDS
ContentDirectory Service

UPnP service that provides network-based discovery of content. The ContentDirectory Service
specification is a standard UPnP DCP.

3.2.17
CE
Consumer Electronics

class of devices used in the home, such as DVD, DVR, PVR, PDA, TV, set top box, cellular phones,
etc.

3.2.18
CMS
ConnectionManager Service

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 DCP.

3.2.19
CNAME
Canonical Name

as used for the RTP Media Transport

3.2.20
CP
UPnP Control Point

generic reference to any UPnP Control Point

3.2.21
CSRC
Contributing Source

as used for the RTP Media Transport

3.2.22
CSS
Cascading Style Sheets

format defined by W3C to add style information to documents

3.2.23
DA
Device Architecture 1.0

UPnP Device Architecture version 1.0 document

3.2.24
DCP
Device Control Protocol

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 22 –

specification that is standardized by the UPnP Forum. Related specifications produced by a UPnP
working committee are often identified by the working committee name. For example, UPnP AV 1
DCP.

3.2.25
DDC
Device Discovery and Control

subclause heading in the interoperability guidelines that defines the underlying interoperability
architecture for the discovery and control devices

3.2.26
DHCPv4
Dynamic Host Configuration Protocol for IPv4

protocol to automatically provide IPv4 addresses and other network configuration information to
network nodes

3.2.27
DIDL
Digital Item Declaration Language

XML schema for representing the metadata of digital content

3.2.28
DIDL-Lite
Digital Item Declaration Language - Lite

XML schema used by the UPnP Forum for representing the metadata of digital content. The XML
schema uses a subset of the DIDL schema with additional metadata properties defined by the UPnP
Forum.

3.2.29
DLNA
Digital Living Network Alliance

the organization that created these guidelines

3.2.30
DLNAQOS_UP
DLNA QoS User Priority

DLNA-defined QoS label used to correlate an underlying IEEE 802.1Q User Priority and WMM
Access Category, HomePlug AV Channel Access Priority, or HD-PLC Priority to a DLNA Traffic
Type(s)

3.2.31
DMC
Digital Media Controller

DLNA Device Class having home network environmental characteristics, with the role of finding
content exposed by a DMS or M-DMS and matching it to the rendering capacities of a DMR and
setting up the connections between the DMS and the DMR

3.2.32
DMP
Digital Media Player

DLNA guidelines; Part 1-1: Architecture and protocols

 – 23 –

DLNA Device Class having home network environmental characteristics, with the role of finding
content exposed by a DMS or M-DMS and rendering the content locally

3.2.33
DMR
Digital Media Renderer

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.34
DMS
Digital Media Server

DLNA Device Class having home network environmental characteristics, with the role of exposing
and distributing content throughout the home

3.2.35
DNS
Domain Name System

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.36
DSCP
Differentiated Services (DiffServ) Code Point

QoS field, defined by the DiffServ discipline IETF RFC 2326, found in the layer 3 header of IP
packets

3.2.37
DVB
Digital Video Broadcasting

one of the standard bodies for digital television broadcasting

3.2.38
DVD
Digital Versatile Disc

high capacity multimedia data storage medium

3.2.39
DVR
Digital Video Recorder

a consumer electronic device

3.2.40
ES
Elementary Stream

general term for a coded video, coded audio or other coded bitstream

3.2.41
GOP
Group Of Pictures
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 24 –

represents a group of successive pictures within a coded video stream and the associated structure
(GOP structure) that specifies the order in which intra- and inter-frames are arranged in MPEG

3.2.42
HD
High Definition

picture quality at an HDTV level

3.2.43
HDTV
High Definition Television

higher quality display, with a vertical resolution display from 720p to 1080i and higher and an aspect
ratio (the width to height ratio of the screen) of 16:9, for a viewing experience similar to watching a
movie.

3.2.44
HND
Home Network Device

Device Category that groups together all the applicable DLNA Device Classes with home network
environmental characteristics (requirements). Device Classes in this Device Category are: DMS,
DMP, DMR and DMC.

3.2.45
HTTP
Hyper Text Transfer Protocol

protocol for transferring files across the Internet. Requires an HTTP client program on one end, and
an HTTP server program on the other end

3.2.46
ICMP
Internet Control Message Protocol

protocol in the TCP/IP family that is used for out-of-band messages related to network operation

3.2.47
IGD
Internet Gateway Device

multifunction Network Infrastructure Device that routes and/or bridges global internet with the local
area network

3.2.48
IP
Internet Protocol

3.2.49
IPv4
Internet Protocol version 4

an OSI network layer 3 protocol

3.2.50
IPv6
Internet Protocol Version 6

DLNA guidelines; Part 1-1: Architecture and protocols

 – 25 –

an OSI network layer 3 protocol intended to replace IPv4

Note 1 to entry: In the DLNA architecture IPv4 and Ipv6 are mandatory, with preference given to IPv4. They will run in a
dual stack model.
3.2.51
JPEG
Joint Photographic Experts Group

3.2.52 coding standard for compression of still images (pictures)

LAN
Local Area Network

closely administered network segment(s) such as within the home or office

3.2.53
LPCM
Linear Pulse Code Modulation

uncompressed audio encoding

3.2.54
M-DMC
Mobile Digital Media Controller

DLNA Device Class having mobile handheld environmental characteristics, with the role of finding
content exposed by a DMS or M-DMS and matching it to the rendering capacities of a DMR and
setting up the connections between the DMS or M-DMS and the DMR

3.2.55
M-DMP
Mobile Digital Media Player

DLNA Device Class having mobile handheld environmental characteristics, with the role of finding
content exposed by DMS or M-DMS and rendering the content locally

3.2.56
M-DMS
Mobile Digital Media Server

DLNA Device Class having mobile handheld environmental characteristics, with the role of exposing
and distributing content throughout the home

3.2.57
MF
Media Formats

collection of Media Format Profiles defined in IEC 62481-2

3.2.58
MHD
Mobile Handheld Device

Device Category that groups together all the applicable DLNA Device Classes with mobile handheld
environmental characteristics (requirements). Device Classes in this Device Category are: M-DMS,
M-DMP and M-DMC.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 26 –

3.2.59
MIME
Multipurpose Internet Mail Extension

standard system for identifying the type of data contained in a file. MIME is an Internet protocol that
allows sending binary files across the Internet as attachments to e mail messages. This includes
graphics, photos, sound, video files, and formatted text documents.

3.2.60
MM
Media Management

subclause heading in the interoperability guidelines

3.2.61
MPEG
Moving Picture Experts Group

name of an organization for developing standards related to audiovisual information

3.2.62
MRCP
MediaRenderer Control Point

UPnP control point that issues actions to an MRD

3.2.63
MRD
MediaRenderer Device (also known as MediaRenderer)

UPnP device that provides network-based control for the rendering of content. Minimally, a
MediaRenderer will have a RenderingControl Service and a ConnectionManager service. The
MediaRenderer specification is a standard UPnP DCP.

3.2.64
MSCP
MediaServer Control Point

UPnP AV control point that issues actions to an MSD

3.2.65
MSD
MediaServer Device (also known as MediaServer)

UPnP device that provides network-based discovery of content. Minimally, a MediaServer will have
a ConnectionManager Service and a ContentDirectory Service. The MediaServer specification is a
standard UPnP DCP.

3.2.66
MT
Media Transport

subclause heading in the interoperability guidelines

3.2.67
NC
Networking and connectivity

subclause heading in the interoperability guidelines

DLNA guidelines; Part 1-1: Architecture and protocols
 – 27 –

3.2.68
NID
Network Infrastructure Device

devices which provide supporting functionality in the home network such as access points, bridges,
Internet gateways, routers, and switches. These devices facilitate a good user experience with
DLNA devices but are only covered at this time in this standard by informative recommendations in
Annex A.

3.2.69
NTSC*
National Television Systems Committee

standard for broadcast and reception of analog television signals

3.2.70
OSD
On Screen Display

3.2.71
OSI
Open Systems Interconnection

networking stack model (7 layers)

3.2.72
PAL*
Phase Alternating Line

standard for broadcast and reception of analog television signals

3.2.73
PC
Personal Computer

general-purpose computer equipped with a microprocessor and designed to run commercial

software (such as a word processor or World Wide Web browser) for an individual user

3.2.74
PCR
Program Clock Reference

refer to MPEG-2 standard ISO/IEC 13818-1

3.2.75
PNG
Portable Network Graphics

coding standard for compression of still images (pictures)

3.2.76
PS
Program Stream

usually in reference to an MPEG-2 AV stream format

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 28 –

3.2.77
PVR
Personal Video Recorder

consumer electronic device

3.2.78
QoS
Quality of Service

provide guarantees on the ability of a network to deliver predictable results

3.2.79
RCS
RenderingControl Service

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 DCP.

3.2.80
RTP
Real Time Protocol

media transport that provides end-to-end network transport functions for transmitting real-time data,
such as AV. It provides services such as payload type identification, sequence numbering,
time-stamping, and delivery monitoring

3.2.81
RTCP
Real Time Control Protocol

3.2.82
RTSP
Real Time Streaming Protocol

3.2.83
RUI
Remote User Interface

user interface provided by an application on a server device, that can be rendered by one or more
client devices

3.2.84
S3D
Stereoscopic 3D

3.2.85
SAR
Sample Aspect Ratio

3.2.86
SCPD
Service Control Protocol Description

XML-encoded file describing a UPnP service. This is also known as a service description file

DLNA guidelines; Part 1-1: Architecture and protocols

 – 29 –

3.2.87
SDES
Session Description Item

3.2.88
SDP
Session Description Protocol

3.2.89
SEI
Supplemental Enhancement Information

message format carried in the 3D media content to inform decoders about any special attributes of
the compressed video

3.2.90
SOAP
Simple Object Access Protocol

XML based messaging protocol used to exchange service requests and responses over a network

3.2.91
SPTS
Single Program Transport Stream

3.2.92
SSDP
Simple Service Discovery Protocol

UPnP device discovery protocol

3.2.93
SSRC
Synchronization Source

3.2.94
TCP
Transmission Control Protocol

protocol in the TCP/IP family used for the reliable exchange of data over a network

3.2.95
TS
Transport Stream

usually in reference to an MPEG-2 AV stream format

3.2.96
TTS
Timestamped Transport Stream

Transport Stream which is composed of timestamped TS packet. The timestamped TS packet is a

192-byte packet consisting of a 188-byte ISO MPEG-2 TS packet plus a 4-byte timestamp in
advance of the TS packet.

3.2.97
UDP
User Datagram Protocol
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 30 –

protocol in the TCP/IP family used for the unreliable exchange of data over a network

3.2.98
UP
User Priority

3-bit field of the QoS Control field in the WMM Specification WMM Specification and a Tag control
information field in the VLAN tag header of IEEE 802.1Q that defines the relative priority of a packet

3.2.99
URI
Uniform Resource Identifier

W3C's codification of the name and address syntax of present and future objects on the Internet. In
its most basic form, a URI consists of a scheme name (such as file, http, ftp, news, mailto, gopher)
followed by a colon, followed by a path whose nature is determined by the scheme that precedes it.
URI is the umbrella term for URNs, URLs, and all other Uniform Resource Identifiers.

3.2.100
URL
Uniform Resource Locator

type of URI

3.2.101
UTF
Unicode Transformation Format

3.2.102
VI
VIdeo user priority

priority-based QoS level for Video User Priority

3.2.103
VLAN
Virtual Local Area Network

3.2.104
VO
VOice user priority

priority-based QoS level for Voice User Priority

3.2.105
VSI
Vendor-Specific Infoframe

message sent from the HDMI source to inform the display device that the video signal is 3D and the
type of 3D delivery format.

3.2.106
WAN
Wide Area Network

network outside the home or office. Typically in reference to the entire global Internet.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 31 –

3.2.107
WMM
Wi-fi MultiMedia

describes the QoS guidelines and associated test plans published by the Wi-Fi alliance for
IEEE 802.11 wireless networks

3.2.108
XML
eXtensible Markup Language

text-based declarative language used to describe structured data for information exchange

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 DLNA home network architecture

4.1 General
To achieve interoperability between connected digital media devices in the home, a common set of
building blocks based on existing standards is needed as a basis to develop the DLNA Home
Networked Device interoperability guidelines. Table 1 shows the specific functional components
and technology ingredients that are covered in the interoperability guidelines. Figure 1 illustrates
these functional components within the networking architecture of the interoperability guidelines.
The interoperability guidelines define usage of these functional components to ensure
interoperability among Device Classes defined in Clause 5. A brief overview of each functional
component follows in the subsequent subclauses.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 32 –

Figure 1 – DLNA functional components

4.2 Networking and connectivity

4.2.1 General
The Internet Protocol suites (IPv4 and IPv6) are the foundation for networking and connectivity for
DLNA devices in the digital home. The general term IP refers to all versions of the Internet Protocol.
DLNA requires support for IPv4 to ensure compatibility with a wide range of IPv4-only devices and
defines an IPv6 device function to allow DLNA devices to interoperate with new IPv6-only devices
going forward.

IP provides the underlying network communications for applications on the Internet. Based on
industry-standard specifications from the IETF, IP is implemented and supported in a wide range of
devices. IP has several advantages for use by DLNA devices:

• IP has demonstrated that it allows applications to run over different network topologies
transparently;
• IP allows connecting every device in the home to the Internet;
• IP connectivity solutions are widely used and are cost effective. The most common ones are
Ethernet (IEEE 802.3i and IEEE 802.3u) and wireless technologies (IEEE 802.11a,
IEEE 802.11b, IEEE 802.11g and IEEE 802.11n) for devices in the home networking
environment. In the mobile handheld environment, Wi-Fi is the prevalent wireless technology in
use.
Subclause 8 specifies the detailed guidelines to enable interoperability between DLNA devices in
the digital home. In addition, the home environment requires supporting network infrastructure,
such as access points, bridges, Internet gateways, routers, and switches. These non-normative
devices are referred to in this standard as Network Infrastructure Devices (NID). Annex A provides
DLNA guidelines; Part 1-1: Architecture and protocols
 – 33 –

informative recommendations for Network Infrastructure Devices to facilitate a good user

experience and interoperability with DLNA devices.

4.2.2 Network quality of service

Multimedia applications on IP networks benefit from Quality of Service (QoS) functionality to
optimize the way shared network resources are allocated among different applications. Without
QoS, all applications running on different devices have an equal opportunity to transmit data frames.
Multimedia applications such as video streaming and music streaming are sensitive to excessive
latency variations and throughput reductions. With prioritized QoS, application label (tag) packets
indicate the User Priority (UP). UP dictates how the packets are allowed to access network
resources.

The DLNA QoS model is intended to allow DLNA applications that wish to take advantage of User
Priority to have common usage rules for tagging. Devices that do not wish to use QoS shall be
tolerant of tagging. In addition to interoperability, the DLNA QoS model promotes fair and consistent
usage of priorities and balanced performance across all DLNA traffic types, thus enhancing the
overall user experience.

4.3 Device discovery and control

Device discovery and control enables a device on the home network to discover the presence and
capabilities of other devices on the network and collaborate with these devices in a uniform and
consistent manner. The UPnP Device Architecture, version 1.0 (ISO/IEC 29341-1), addresses all of
these needs and simplifies device networking in the home. For this reason, UPnP Device
Architecture is the device discovery and control solution for DLNA devices. Subclause 9 specifies
the detailed guidelines to enable interoperability between DLNA devices in the digital home.

4.4 Media management

Media management enables devices and applications to identify, manage, and distribute media
content across the home network devices. UPnP Audio/Video (AV) technology addresses all of
these needs for the home network and is the media management solution for DLNA devices.

The UPnP AV architecture defines the interaction model between UPnP AV devices and associated
control point applications. UPnP AV devices can instantiate themselves in a variety of form factors,
including (but not limited to) TVs, VCRs, DVD players, Set-Top Boxes, stereo systems, still-image
cameras, portable media players, cell phones, and PCs. The UPnP AV architecture allows devices
to support entertainment content in any format using any media transfer protocol. The UPnP AV
specification defines two types of UPnP devices on the home network: UPnP AV MediaServers and
UPnP AV MediaRenderers. The specifications also define four services hosted by UPnP AV
MediaServers and UPnP AV MediaRenderers, as stated below. The existence of UPnP control
points that interact with UPnP AV devices and services is implied.

a) Content Directory Service: Exposes the available content.

b) Connection Manager Service: Determines how the content can be transferred from the UPnP AV
MediaServer to the UPnP AV MediaRenderer devices.
c) AV Transport Service: Controls the flow of the content.
d) Rendering Control Service: Controls how the content is played.
See Clause 5 for further information on how UPnP technology components are mapped into DLNA
Device Classes.

Subclause 9.2.37 specifies the detailed guidelines to enable interoperability between DLNA devices
in the digital home.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 34 –

4.5 Media formats

Media formats describe how content is encoded and formatted for transport and how it is rendering
on the home network. The DLNA media format model is intended to achieve a baseline for network
interoperability while encouraging continued innovation in media codec technology. For each
Device Category, the DLNA media format model defines a set of mandatory and optional Media
Format Profiles for each of the three classes of media: imaging, audio, and AV. A Media Format
Profile is a set of attributes, parameters, and system and compression level details sufficient to
describe the media format of a content binary to enable interoperability between DLNA devices in
each Device Category. In order to support interoperability between devices of different Device
Categories, the Media Interoperability Unit performs basic translation between the required Media
Format Profiles of different Device Categories. In addition, the DLNA media format model specifies
rules about conversion between optional and mandatory formats to ensure that content can be
enjoyed on all devices. The interoperability guidelines Media Formats, IEC 62481-2, specify the
detailed guidelines to enable interoperability between DLNA devices in the digital home.

4.6 Media transport

Media transport defines how content travels across the home network. DLNA devices that source or
receive media content across the home network shall support HTTP as the baseline transport
mechanism for the transfer of content. In addition, the RTP transport can optionally be used as a
media transport; but the mandatory requirements for HTTP shall always be supported. Subclause
11 specifies the detailed guidelines to enable interoperability between DLNA devices in the digital
home.

4.7 Remote UI
Remote UI defines how UI content is described, formatted, and transported from one device to
another over the network. This also includes mechanisms for sending events and UI updates
between different devices.

5 DLNA device model

5.1 Overview
These guidelines address the requirements of devices with differing environmental characteristics,
such as home network and mobile handheld devices. Home Network Devices (HNDs) and Mobile
Handheld Devices (MHDs) are Device Categories that have a differing set of requirements in media
formats and network connectivity. This clause provides a device model with consistent terms and
usages for these Device Categories.

In summary, the key points about Device Categories are:

• each is uniquely optimized for the requirements of a particular environment;

• the device guidelines focus on interoperability of devices within a Device Category;
• there are guidelines for devices which facilitate interoperability between Device Categories;
• a device can choose to be a member of multiple Device Categories.
5.2 Device model elements
As described in Clause 4, devices adhering to the DLNA Home Networked Device interoperability
guidelines have six architectural layers. In summary, they are Media Formats for describing
conformant content, Media Management for describing how content is found and controlled to
achieve different system usages, Device Discovery and Control for device control, Media Transport
for the transfer of content, Network Stack for IPv6 and IPv4 protocol requirements, and Network
Connectivity for supporting different network physical layers. The following are terms used within
this clause and throughout the guidelines. Their interdependence is illustrated in Figure 2.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 35 –

A Device Category is an aggregation of Device Classes with common environmental characteristics

(e.g. mobile devices) and sharing system usages that enable home networking use case scenarios.
An example of a Device Category is the set of all Device Classes with system usages that solve
requirements in media formats and network connectivity in a home network environment, such as a
HND. Device Classes are grouped within a Device Category, but a single physical device can fall
into multiple Device Categories.

A system usage describes a device interaction model between Device Classes and/or Device
Capabilities. system usages are derived when enabling home networking use case scenarios. An
example is a rendering device with a dedicated user interface that is browsing, selecting, and
playing content from a media server on the home network, such as the 2-box Pull system usage, see
5.7.2.

A Device Class is a set of Device Functions (at least one) aggregated to be used in a system usage
that enables home networking AV use case scenarios. A Device Class shall provide support for all
layers in the DLNA architecture except when defined within the Home Infrastructure Device
Category which is providing interoperability between one or more layers in the DLNA architecture. A
Device Class is a certifiable entity by DLNA and is derived from system usages. It specifies the
capabilities supported by a device regardless of the device's physical attributes. An example of a
Device Class is a device with the role of exposing and distributing content throughout the home such
as a "DMS". A single physical device can support multiple Device Classes.

A Device Capability is a set of Device Functions (at least one) aggregated to be used in a system
usage that is enabling home networking AV use case scenarios. A Device Capability does not
provide support for all layers in the DLNA architecture. It typically contains Device Functions at the
Device Discovery and Control, Media Management, and Media Transport layers only. A Device
Capability is not a Device Class and cannot stand alone. It shall always be deployed in conjunction
with an implementation of a valid Device Class. A Device Class might already contain some of the
Device Functions required to provide a Device Capability. An example of a Device Capability is any
DLNA device that incorporates the additional feature (capability) of pushing content to a rendering
device, such as a "Push Controller".

A Device Function is a non-decomposable operational property. Device Functions should be

supported by existing standards or specifications. A Device Function usually applies to a single
layer within the DLNA architecture. An example of a Device Function is an operational component at
the Device Discovery and Control layer of the DLNA architecture such as a "UPnP Device". Device
Classes and Device Capabilities are composed of a set of Device Functions. Device Functions are
the building blocks of DLNA devices.

A Device Option provides optional extensibility to an existing Device Class definition, such as
upload or scheduled recording functionality added to a MediaServer Device (MSD), or it provides a
new optional Device Function to the DLNA architecture, such as RTP. A Device Option differs from
a Device Class or Device Capability in that it normally enables a Device Class or Device Capability
to perform an existing system usage in a different way (e.g., RTP). In the case where a Device
Option achieves a new system usage, it adds functionality to an existing Device Class or Device
Capability to support a new interaction such as the Upload system usage.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 36 –

Figure 2 – DLNA device model terms hierarchy

5.3 Device Functions

For the interoperability guidelines and system usages, the Device Functions below are defined for
the DLNA architecture.

• IP Connectivity – Network Connectivity and Network stack (8). This incorporates Ethernet
(IEEE 802.3) and IEEE 802.11, with IP networking using the IPv4 protocol suite.
• IPv6 Connectivity – a Device Function that builds upon the basic connectivity of IP Connectivity
by adding IPv6 to the Network Connectivity and Network stack.
• UPnP Device and UPnP Control Point (UPnP CP) – Device Discovery and Control based upon
the UPnP Device Architecture (9). This incorporates the baseline device architecture used by all
Device Classes and Device Capabilities.
• UPnP AV MediaServers (MSD), UPnP AV MediaServer control point (MSCP), UPnP AV
MediaRenderer (MRD) and UPnP AV MediaRenderer control point (MRCP) – Media
Management (9.2.37). This incorporates the control functionality that is layered on top of a
UPnP Device or a UPnP control point to fulfill a role for a Device Class or a Device Capability in
a system usage. An MSD provides methods to access content. An MSCP is a controller that can
browse and select content provided by an MSD. An MRD provides methods to render content.
An MRCP is a controller that selects the content to be rendered by an MRD.
• Media Transport Server and Media Transport Client – Media Transport (11). These are the
Device Functions for the transport of content. The mandatory transport for content is HTTP
which has the components of an HTTP Server and an HTTP Client. An optional transport for
content is RTP which has the components of an RTP Serving Endpoint and an RTP Receiving
Endpoint. RTP is an example of a Device Option which provides optional extensibility to system
usages utilizing a Media Transport.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 37 –

• Content – interoperability guidelines Media Formats, IEC 62481-2, defines the DLNA mandatory
and optional Media Format Profiles for content.
• Generic HTTP URLs (GENURL) – Media Management (7.4). This incorporates the DNS Client
functionality which resolves domain names into IPv4 addresses. A GENURL Device Function
provides support or HTTP protocol messages to request and receive media resources from
servers internal or external to the home network.
5.4 Device Categories
Device Categories are a grouping of Device Classes that share common environmental
characteristics (requirements) with system usages. There were no Device Categories explicitly
defined in version 1.0 of the interoperability guidelines, as all of the Device Classes operated in the
same environment. All of the version 1.0 guidelines were defined as if the following Device Category
applied:

• Home Network Devices (HNDs) are a group of Device Classes that share system usages in the
home network with the same media format and network connectivity requirements.
In these interoperability guidelines, the following two additional Device Categories are defined:

• Mobile Handheld Devices (MHDs) are a group of Device Classes that share the same system
usages as the HND Device Category, but have different requirements for media format and
network connectivity.
5.5 Device Classes and roles
In version 1.0 of the interoperability guidelines, the following two Device Classes were defined to
support the 2-box Pull system usagefor the HND Device Category.

• A Digital Media Server (DMS) with the role of exposing and distributing content.
• A Digital Media Player (DMP) with the role of finding content exposed by a DMS and playing the
content locally on the DMP.
In these interoperability guidelines, the following three additional Device Classes are defined for the
HND Device Category.

• A Digital Media Renderer (DMR) with the role of playing content it receives after being setup by
another network entity.
• A Digital Media Controller (DMC) with the role of finding content exposed by a DMS and
matching it to the rendering capacities of a DMR and setting up the connections between the
DMS and DMR.
The following Device Classes are defined for MHD Device Category.

• A Mobile Digital Media Server (M-DMS) with the role of exposing and distributing content.
• A Mobile Digital Media Player (M-DMP) with the role of finding content exposed by an M-DMS
and playing the content locally on the M-DMP.
• A Mobile Digital Media Controller (M-DMC) with the role of finding content exposed by an
M-DMS and matching it to the rendering capabilities of a DMR and setting up the connections
between the server and renderer.
Many of these mobile Device Classes have counterparts in the HND Device Category; however,
they differ from their counterpart at the network connectivity layer and at the media format layer in
the DLNA architecture. For example, an M-DMC can be connected via mobile specific network
connectivity while a DMC has to meet the HND network connectivity requirements. This should not
be taken to imply that MHD and HND devices cannot interact directly. The discussion above and in
the definition of terms of the MHD and HND Device Classes, mobile Device Classes interact with
other mobile Device Classes, such as an M-DMP interacting with an M-DMS. However, if the mobile
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 38 –

and home devices have compatible network connectivity, and can exchange compatible Media
Format Profiles, nothing in these statements should be taken to imply that an M-DMP cannot directly
connect to a DMS to complete a system usage. See Table 2, and Table 4 for a listing of the required
device interoperations and those that are only possible in consideration of compatible network and
Media Format Profile capabilities.

The Device Functions that are incorporated in these Device Classes are illustrated in the figures
that provide the details for system usages and their respective device interaction models in 5.7.2
through 5.7.10.

5.6 Device Capabilities and roles

In these interoperability guidelines, the following Device Capabilities are defined.

• A Push Controller (+PU+) with the role of pushing its local content to a DMR.
• An Upload Controller (+UP+) with the role of sending content to a DMS or M-DMS with upload
functionality.
• A Download Controller (+DN+) with the role of downloading content from a DMS or M-DMS to
itself.
• An Upload Synchronization Controller (+UPSYNC+) with the role of keeping locally changing
content synchronized with a DMS or M-DMS supporting the Content Synchronization Device
Option.
• A Download Synchronization Controller (+DNSYNC+) with the role of keeping remotely
changing content synchronized with the local system. The remotely changing content shall be
located on a DMS or M-DMS supporting the Content Synchronization Device Option.
• A Scheduled Recording Controller (+SR+) with the role of instructiong a DMS or M-DMS to
browse, create, modify, and/or cancel scheduled recordings of content.
• An EPG Controller (+EPG+) with the role of fetching EPG metadata from a DMS or M-DMS.
The Device Functions that are incorporated in these Device Capabilities are illustrated in the figures
that provide the details for system usages and their respective device interaction models in 5.7.2
through 5.7.10.

5.7 System usages

5.7.1 General
In describing the flow of content in the system usages, indicated by the largest arrow in the system
usage diagrams in 5.7.2 through 5.7.10, the terms push and pull are used. The terms push and pull
are used in system usages to characterize the user's perception of the source or sink location in the
process of content transfer. That is, pull means that the content is traveling to the user, while push
means that the content is traveling from the user. This perception is not a reflection of the technical
underling transport mechanism utilized to perform the transfer the content from the source to the
sink (e.g. HTTP and RTP).

In these interoperability guidelines, the following system usages are defined that map to all of the
use case scenarios being enabled by the detailed guidelines.

• 2-box Pull system usage

This usage involves a user at a DMP or an M-DMP, which enables the user to find and play
content that is advertised and distributed by a DMS or M-DMS.
• 2-box Push system usage
This usage involves a user at a Push Controller, which enables the user to distribute content to
a DMR for playback purposes.
• 3-box system usage
DLNA guidelines; Part 1-1: Architecture and protocols
 – 39 –

This usage involves a user at a DMC or an M-DMC, which enables the user to find content on a
DMS or M-DMS that in turn will be played on a user selected DMR.
• Upload Synchronization system usage
This usage involves a user at an Upload Synchronization Controller, which enables the user to
reflect any changes to the local store of content into a DMS or an M-DMS with the Content
Synchronization Device Option so that the DMS or the M-DMS can receive and distribute the
new or changed content to other endpoints.
• Download Synchronization system usage
This usage involves a user at a Download Synchronization Controller, which enables the user to
obtain any changes to the store of content on a DMS or an M-DMS supporting the Content
Synchronization Device Option.
• Scheduled Recording system usage
This usage involves a user at a Scheduled Recording Controller, which enables the user to
instruct a media server (DMS/M-DMS) to browse, create, modify, and cancel scheduled
recordings.
• EPG system usage
This usage involves a user at an EPG Controller, which enables the user to view EPG metadata
exposed by a DMS or M-DMS.
Subclauses 5.7.2 through 5.7.10 will briefly describe each of the system usages and their respective
device interaction models. For clarity, the device interaction model diagrams in 5.7.2 through 5.7.10
show HND and MHD devices interacting directly. All these system usages are shown with Device
Functions that are media transport agnostic. All of these system usages imply HTTP as the
mandatory media transport and other optional media transports, such as RTP, can be substituted.

5.7.2 2-box Pull system usage

The 2-box Pull system usage pulls DLNA compliant content from a media server (DMS/M-DMS) to
be rendered locally by the device pulling the content (DMP, M-DMP). The user perspective is that
content is being pulled to the DMP or the M-DMP for immediate rendering on the device. The user
is browsing and selecting content on the DMS or the M-DMS. This usage between a DMS and a
DMP was the only system usage supported in the v1.0 interoperability guidelines. Note that the
rendering function is not exposed onto the network in a DMP or an M-DMP implementation. Also
note that in all of the following system usage diagrams, the Media Transport Client/Server is for the
media transport layer only. The UPnP Device/CP has HTTP functions independent of the media
transport layer and is implied as being part of the UPnP Device/CP Device Functions. Figure 3
illustrates this device interaction model. The following steps are performed in this system usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 and
5.7.11.2 for description of impacts to these steps.

1) Invoke UPnP actions to browse and select content.

2) Request the content for playback.
3) Transport the content to the DMP or the M-DMP.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 40 –

Figure 3 – 2-box Pull system usage interaction model

5.7.3 2-box Push system usage

The 2-box Push system usage pushes DLNA compliant content to a rendering device (DMR). The
user perspective is that content is being pushed to the DMR even though content might actually be
transported in a "pull" manner depending on the media transport used. The user is selecting content
at the device where the content is resident. Figure 4 illustrates this device interaction model. The
following steps are performed in this system usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 and
5.7.11.3 for description of impacts to these steps.

1) Invoke UPnP actions to browse and select content.

2) Request the content for playback.
3) Transport the content to the DMR.
Note that the Push Controller Device Capability functionality can only be incorporated as part of any
physical device with a valid DLNA Device Class. It shall never appear as a stand-alone device. This
is how the Push Controller Device Capability inherits other Device Functions (e.g. IP Connectivity)
at other layers in the DLNA Device Architecture. This is applicable to Device Classes in both the
HND and MHD Device Categories.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 41 –

Figure 4 – 2-box Push system usage interaction model

5.7.4 3-box system usage

The 3-box system usage uses a device controller (DMC/M-DMC) to browse content on a media
server (DMS/M-DMS) and to select a rendering device (DMR) to play the selected content. The
DMC or the M-DMC is responsible for making sure a DMR can render the selected DLNA content.

Figure 5 illustrates this device interaction model. The following steps are performed in this system
usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 and
5.7.11.4 for description of impacts to these steps.

1) Invoke UPnP actions to browse and select content.

2) Invoke UPnP actions to verify that the DMR has the capability to render the selected content and
then set up a connection for the selected content between the DMR and the DMS or the M-DMS.
3) Request the content for playback.
4) Transport the content to the DMR.

Figure 5 – 3-box system usage interaction model

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 42 –

5.7.5 Download system usage

The Download system usage allows a Download Controller to transfer and store DLNA content from
a media server (DMS or M-DMS).

Figure 6 illustrates this device interaction model. The following steps are performed in this system
usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 and
5.7.11.2 for description of impacts to these steps.

1) Invoke UPnP actions to find content to download.

2) Request the content that needs to be downloaded.
3) Transport content to the Download Controller.
Note that the Download Controller Device Capability functionality can only be incorporated as part
of any physical device with a valid DLNA Device Class. It can never appear as a stand-alone device.
This is how the Download Controller Device Capability inherits other Device Functions (e.g. IP
connectivity) at other layers in the DLNA Device Architecture.

Figure 6 – Download system usage interaction model

5.7.6 Upload system usage

The Upload system usage has an Upload Controller Device Capability to instruct a media server
(DMS/M-DMS) to accept some new content to be added to its list of available content.

Figure 7 illustrates this device interaction model. The following steps are performed in this system
usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 and
5.7.11.2 for description of impacts to these steps.

1) Invoke UPnP actions to create a CDS entry for the content to be uploaded.
2) Transport the content being uploaded to the DMS or the M-DMS.
Note that the Upload Controller Device Capability functionality can only be incorporated as part of
any physical device with a valid DLNA Device Class. It shall never appear as a stand-alone device.
This is how the Upload Controller Device Capability inherits other Device Functions (e.g. IP
connectivity) at other layers in the DLNA Device Architecture.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 43 –

Figure 7 – Upload system usage interaction model

5.7.7 Download Synchronization system usage

The Download Synchronization system usage has a Download Synchronization Controller Device
Capability receive changes in the content or metadata stored on a media server (DMS/M-DMS) and
apply those changes to the local storage. Figure 6 illustrates this device interaction model. The
Media Server tracks changes within its metadata database and makes that information available to
the controller. The controller decides which elements to download to the local storage. The following
steps are performed in this system usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 and
5.7.11.2 for description of impacts to these steps.

1) The Download Synchronization Controller invokes UPnP actions to obtain a list of changes on
the Media Server since the last synchronization.
2) The Download Synchronization Controller receives the resulting information from the Media
Server on the changes that have occurred in the database.
3) The Download Synchronization Controller decides what actions to carry out to synchronize its
local storage with the changes present on the Media Server.
4) The Download Synchronization Controller obtains the information necessary to download the
required information (URLs and metadata)
5) If necessary, the Download Synchronization Controller transfers the relevant content from the
Media Server to the controller.
Note that the Download Synchronization Controller Device Capability functionality can only be
incorporated as part of any physical device with a valid DLNA Device Class. It shall never appear as
a stand-alone device. This is how the Download Synchronization Controller Device Capability
inherits other Device Functions (e.g. IP connectivity) at other layers in the DLNA Device
Architecture. Figure 8 shows a model of a Download Synchronization.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 44 –

Figure 8 – Download Synchronization system usage interaction model

5.7.8 Upload Synchronization system usage

The Upload Synchronization system usage has an Upload Synchronization Controller Device
Capability propagate changes in the local content or metadata to a media server (DMS/M-DMS) to
be added to its list of available content. Figure 7 illustrates this device interaction model. The
Upload Synchronization Controller tracks changes in the local storage and uploads those changes
to a DMS or M-DMS with the CDS Tracking Changes Option. The following steps are performed in
this system usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 and
5.7.11.2 for description of impacts to these steps.

1) The Upload Synchronization Controller determines that changes have been made in the local
content storage area.
2) The Upload Synchronization Controller invokes UPnP actions on the media server to obtain a list
of changes since the last synchronization.
3) The Upload Synchronization Controller receives the resulting information from the media server
on the changes that have occurred in the CDS.
4) The Upload Synchronization Controller determines what changes need to occur on the DMS or
M-DMS to properly represent the local changes.
5) The Upload Synchronization Controller performs OCM operations to reflect the local changes
onto the media server.
6) If necessary the Upload Synchronization Controller tranfers the relevant content from the
controller to the media server.
Note that the Upload Synchronization Controller Device Capability functionality can only be
incorporated as part of a physical device with a valid DLNA Device Class. It shall never appear as
a stand-alone device. This is how the Upload Synchronization Controller Device Capability inherits
other Device Functions (e.g. IP connectivity) at other layers in the DLNA Device Architecture.
Please note that the Upload Synchronization Controller Device Capability contains the ability to use
the OCM operations on the server to carry out the actions required for synchronization. Figure 9
shows a model of a Upload Synchronization.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 45 –

Figure 9 – Upload Synchronization system usage interaction model

5.7.9 Scheduled Recording system usage

The Scheduled Recording system usage has a Scheduled Recording (SR) Controller Device
Capability to instruct a media server (DMS/M-DMS) to create, modify, and cancel a scheduled
recording. Figure 10 illustrates this device interaction model. The following steps are performed in
this system usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 for
description of impacts to establishing UPnP Communications.

1) Invoke UPnP actions to obtain some or all of the values for the input parameters needed for
setting up a scheduled recording.
2) Invoke UPnP actions to create a scheduled recording using the input parameters obtained in
step 1.
3) Invoke UPnP actions to allow for the browsing, modification, and cancellation of existing
scheduled recordings.
Note that the SR Controller Device Capability functionality can only be incorporated as part of any
physical device with a valid DLNA Device Class. It shall never appear as a stand-alone device. This
is how the SR Controller Device Capability inherits other Device Functions (e.g. IP connectivity) at
other layers in the DLNA Device Architecture. Also note that the UPnP Scheduled Recording
Service Device Option is a UPnP service integrated into a UPnP MediaServer Device. The SR
Controller includes a MSCP with functionality for scheduled recording.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 46 –

+ Indicates additional functionality from previous versions of the Interoperability Guide lines for a Device Function to
implement this system usage.

Figure 10 – Scheduled Recording system usage interaction model

5.7.10 EPG system usage

The EPG system usage allows an EPG Controller to search EPG metadata exposed by a UPnP AV
MediaServer (DMS/M-DMS). The EPG Controller Device Capability consists of an UPnP AV
MediaServer control point with EPG client functionality. The following independent operations are
performed in the system usage.

Where IPv6 Connectivity Device Function is present in addition to IP Connectivity, see 5.7.11.1 for
description of impacts to establishing UPnP Communications.

1) Invoke UPnP actions to search EPG metadata in the CDS based on certain criteria.
2) Optionally invoke UPnP actions to obtain channel line-up information.
Note that the EPG Controller Device Capability functionality can only be incorporated as part of any
physical device with a valid DLNA Device Class. It shall never appear as a stand-alone device. This
is how the EPG Controller Device Capability inherits other Device Functions (e.g. IP connectivity) at
other layers in the DLNA Device Architecture.

To enable this system usage the EPG Server Device Option shall be implemented in a DMS or an
M-DMS. The EPG Server obtains EPG metadata from an external source, and maps a set of
mandatory properties to the Server’s Content Directory Service. Mapping definitions are provided
for OpenEPG, TV-Anytime, and DVB-SI. Servers can choose to export rich data provided by an
OpenEPG, or TV-Anytime service by exposing such XML based information as Foreign Metadata
embedded in EPG Items in the CDS. Figure 11 shows a EPG system usage interaction model.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 47 –

+ Indicates additional functionality from previous versions of the Interoperability Guide lines for a Device Function to
implement this system usage.

Figure 11 – EPG system usage interaction model

5.7.11 IPv6 Connectivity system usage impacts

5.7.11.1 Impacts common to all system usages
The logic for determining which address to use for UPnP Communications in all system usages is as
follows:

A UPnP CP that contains the IPv6 Connectivity Device Function will search for and discover the
(M-)DMS using both IPv4 and IPv6 addresses.

If the (M-)DMS responds with only an IPv4 address, the IPv4 address will be used for future UPnP
Communication.
If the (M-)DMS responds with both IPv4 and IPv6 addresses, the IPv4 address will be used for future
UPnP Communication.
If the (M-)DMS responds with only an IPv6 address, the IPv6 address will be used for future UPnP
Communication.
5.7.11.2 Impacts to 2-box Pull, Download, Upload, Download Sync, Upload Sync
These system usages involve a UPnP Device that serves (and stores) content and a UPnP CP that
renders (but may also store) content.

If the IPv6 Connectivity Device Function is present on the DMP (2-box Pull), Download
Synchronization Controller (Download Sync), or Upload Synchronization Controller (Upload Sync),
then additional steps are required to ensure that any IP addresses in URIs provided by the DMS or
M-DMS match the IP address family used for UPnP Connectivity between the UPnP CP and
(M-)DMS.

The logic for determining which URIs will be returned by the (M-)DMS in these system usages are as
follows:
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 48 –

1) If an IPv4 address is used for UPnP Communications and no filters (ALLIP, ALLINTIP) are
specified, the (M-)DMS will respond to Browse/Search requests with URIs containing IPv4
addresses.
2) If an IPv6 address is used for UPnP Communications, the (M-)DMS will respond to
Browse/Search requests with URIs containing IPv6 addresses.
5.7.11.3 Impacts to 2-box Push
These system usages involve a UPnP Device that renders content and a UPnP CP that serves
content.

If the IPv6 Connectivity Device Function is present on the Push Controller (2-box Push), then
additional steps are required to ensure that any IP addresses in URIs provided by the DMR or
XDMR match the IP address family used for UPnP Connectivity between the UPnP CP and UPnP
Device.

The logic for determining which URIs to send in these system usages is as follows:

The UPnP CP invokes UPnP actions that involve the sending of URIs that point to content on the CP.
URIs with literal IP addresses will include an IP address consistent with the IP address used for
UPnP communications.

5.7.11.4 Impacts to 3-box

These system usages involve a UPnP CP that is instructing a UPnP device (that is also a renderer
of content) to acquire content from a third device (a content server).

If the IPv6 Connectivity Device Function is present on the DMC or M-DMC (3-box), then additional
steps are required to ensure that any IP addresses in URIs provided by the (M-)DMC match the IP
address family used for UPnP Connectivity between the UPnP CP and rendering UPnP Device
(DMR or XDMR).

The logic for determining which URIs to send to the rendering device in these system usages is as
follows:

1) If an IPv4 address is used for UPnP Communications between the UPnP CP and the content
server UPnP Device and no filters (ALLIP, ALLINTIP) are specified, the content server UPnP
Device will respond to Browse/Search requests with URIs containing IPv4 addresses.
3) If an IPv6 address is used for UPnP Communications, the content server UPnP Device will
respond to Browse/Search requests with URIs containing IPv6 addresses.
4) The UPnP CP invokes UPnP actions that involve the sending of URIs to the rendering UPnP
device that point to content on the serving UPnP device. URIs with literal IP addresses will
include an IP address consistent with the IP address used for UPnP communications with the
rendering device.
5.8 Interoperability guidelines usage
The guideline requirements' tables presented in Clause 7 contain a column that specifies which
Device Classes apply to a requirement. For the v1.0 interoperability guidelines, only DMS and DMP
were applicable. For these interoperability guidelines, two new Device Classes are defined in
addition to the two above for the HND Device Category. They are a DMC and DMR. The MHD
Device Category with four new Device Classes is introduced in this version of the guidelines. Table
2 summarizes all of the Device Classes in the HND Device Category and the mnemonics used within
these interoperability guidelines. Table 3 summarizes all of the Device Capabilities that can be
deployed with any Device Class and the mnemonics used within these interoperability guidelines.
Table 4 summarizes all of the Device Classes in the MHD Device Category and the mnemonics used
for these Device Classes..

DLNA guidelines; Part 1-1: Architecture and protocols

 – 49 –

Table 2 – DLNA Device Classes in the HND Device Category

DLNA Device Media Media Functional Device Classes Device Classes

Class Management Transport description or Capabilities interacted with
components components interacted with given
for defined compatible
system usages networking and
Media Formats
profiles

v1.0 Device Classes

DMS (Digital MSD Media Transport Serves up media DMP, DMC, M-DMP, M-DMC
Media Server) Server DMR, other
endpoints with
+UP+or +DN+
capabilities
DMP (Digital MSCP Media Transport Selects, controls DMS M-DMS
Media Player) Client and renders the
selected media
Device Classes new to v1.5
DMC (Digital MSCP MRCP n/a Controls the DMS, DMR M-DMS
Media content selection
Controller) and content
rendering
between
networked
devices
DMR (Digital MRD Media Transport Renders content DMC, DMS, M-DMC, M-DMS
Media Client other endpoints
Renderer) with +PU+
capabilities

A new concept introduced in this version of the interoperability guidelines is a Device Capability. A
Device Capability can be applied to any valid DLNA Device Class from any Device Category. Device
Capabilities inherit the IP connectivity from the Device Category of the Device Classes it is
combined with. There are no baseline (i.e. mandatory) Media Format interoperability requirements
for Device Capabilities, unless otherwise specified by explicit guidelines. Table 3 summarizes all of
the Device Capabilities used in the system usages and the mnemonics used within these
interoperability guidelines to specify which requirements apply to them.

Table 3 – DLNA Device Capabilities

DLNA Device Device Capability Media Media Transport Device Classes

Capability Controller identifier Management components interacted with for
components defined system
usages

Push Controller +PU+ MRCP Media Transport DMR

Server
Download +DN+ MSCP Media Transport DMS. M-DMS
Controller Client
Upload Controller +UP+ MSCP Media Transport DMS, M-DMS
Client
Upload +UPSYNC+ MSCP Media Transport DMS, M-DMS
Synchronization Client
Controller
Download +DNSYNC+ MSCP Media Transport DMS, M-DMS
Synchronization Client
Controller

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 50 –

DLNA Device Device Capability Media Media Transport Device Classes

Capability Controller identifier Management components interacted with for
components defined system
usages

Scheduled +SR+ MSCP n/a DMS, M-DMS

Recording
Controller
EPG Controller +EPG+ MSCP n/a DMS, M-DMS

The MHD Device Category has different media format and network connectivity requirements
because of various device constraints. Table 4 summarizes all of the Device Classes in the MHD
Device Category and the mnemonics used within these interoperability guidelines.

Table 4 – DLNA Device Classes in the MHD Device Category

DLNA Device Media Media Functional Device Classes Device Classes

Class Management Transport description interacted with or Capabilities
components components for defined interacted with
system usages given
compatible
networking
and Media
Formats
profiles

M-DMS (Mobile MSD Media Transport Serves up M-DMP, DMP, DMC,

Digital Media Server media M-DMC, DMR, other
Server) endpoints with
+UP+ or +DN+
capabilities
M-DMP (Mobile MSCP Media Transport Selects, M-DMS DMS
Digital Media Client controls and
Player) renders the
selected media
M-DMC (Mobile MSCP MRCP n/a Controls the M-DMS, DMR DMS
Digital Media content
Controller) selection and
content
rendering
between
networked
devices

6 Guideline terminology and conventions

6.1 Guideline compliance classifiers
Reference IETF RFC 2119 provides a description of terminology conventions used in all IETF RFC
documents. The terminology and conventions used by the DLNA Home Networked Device
interoperability guidelines are adapted from this reference. The details of each guideline will carry a
compliance classifier from the following set.

[M] Required, Shall: This is the minimum set of requirements that will ensure interoperability and/or
robust operation between devices. All devices are expected to comply with these requirements
when expressed in unconditional form. A conditional requirement expressed in the form, "If X, then
Y shall be implemented", means that the requirement "Y" shall be met when the conditional aspect
"X" applies to a given implementation.

[S]hould, Recommended: Recommended items are optional items that are strongly recommended
for inclusion in products. The difference between "recommended" items and "optional" items, below,

DLNA guidelines; Part 1-1: Architecture and protocols

 – 51 –

is one of priority. When considering features for inclusion in a product, recommended items should
be included first.

[O]ptional, May: Optional items are suggestions for features that will enhance the user experience
or are offered as a less preferred choice relative to another recommended feature. If optional
features are included, they shall comply with the requirement to ensure interoperability with other
implementations.

6.2 Standard or specification usage classifiers

When specifying guideline details, it is often useful to reiterate or clarify certain aspects of a
standard or specification that are often violated or misunderstood. Furthermore, there might be
guidelines that intentionally contradict or restrict implementation of certain aspects of a standard or
specification in order to ensure interoperability between DLNA devices. The following classifiers are
used in the DLNA Home Networked Device interoperability guidelines to indicate the relationship of
a specific guideline to a source standard or specification.

[A]dding: A guideline that adds to or supplements a standard or specification to enhance

interoperability. A guideline that does not reference a standard or specification also uses this
classifier.

[C]larifying: A guideline that addresses vague or ambiguous aspects of a standard or specification.

[F]ixing: A guideline that intentionally supersedes and fixes aspects of a standard or specification
that is incorrect and would otherwise provide a poor user experience or prevent device
interoperability.

[L]imiting: A guideline that narrows or specifies an exact behavior in areas where a standard or
specification provides for greater degrees of latitude in implementation.

[R]epeating: A guideline that repeats what is already in a standard or specification because of

observed and repeated problems with implementations. Whenever a guideline with this usage
classifier seems to be in conflict with the actual standard, the standard prevails over the guideline.

6.3 Guideline font usage conventions

The following font usage conventions are used within the DLNA Home Networked Device
interoperability guidelines to provide additional clarity.

• Hyperlinks to reference citations are indicated as [reference number or text].

• UPnP action names are indicated as: [Service acronym]:[action name], such as CDS:Browse.
• Special terms are sometimes italicized. Sometimes a guideline will define a term for use within
that guideline and the term will be italicized.
6.4 Guideline syntax notation conventions
The following are syntax (BNF) notation conventions used within the DLNA interoperability
guidelines to provide readability.

• Linear whitespace (LWS) characters, such as carriage returns, spaces, tabs, or line feeds, are
not implied anywhere in any of the syntax (BNF) definitions used within the interoperability
guidelines.
• The use of LWS characters is restricted within the interoperability guideline unless explicitly
specified in any of the syntax definitions with reference to UPnP HTTP communications.
• By default, text tokens and values have a case-sensitive treatment unless explicitly noted in the
guidelines. This convention also applies to BNF definitions, XML tag names, XML tag values,
capability IDs, and HTTP header values for HTTP headers used by the DLNA guidelines. One of

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 52 –

the exceptions to this rule applies to the names of HTTP headers. HTTP header names have a
case-insensitive treatment. For example TimeSeekRange.dlna.org is the same as
timeseekrange.dlna.org. (See 11.4.3.7)). Other exceptions are described in each guidelines
which define BNF syntax.
6.5 Guideline normative and informative text conventions
All text that appears in the DLNA interoperability guidelines is to be considered normative unless
explicitly stated otherwise, such as informative references and informative annexes. Normative text
includes text before guideline attribute tables, but testable guidelines are only contained within
subclause guideline attribute tables.

6.6 DLNA XML namespaces and schemas

The DLNA interoperability guidelines make numerous references to XML elements and attributes
that are defined for DLNA Device Classes and Device Capabilities. However, these namespaces
are intentionally not defined through a formal DLNA XML schema. This allows the DLNA
interoperability guidelines to define new XML elements and attributes in the future, without having to
define a new namespace or schema definition. DLNA Devices Classes and Device Capabilities are
expected to exhibit tolerant behavior when encountering XML elements or attributes that are
defined in the future, as required by existing guidelines 9.2.23 and 10.1.3.1. Table 5 lists the
namespace values that are used by DLNA guidelines and the context for their usage.

Table 5 – DLNA namespace values

Namespace value Usage context

urn:schemas-dlna-org:device-1-0 Used for XML elements and attributes defined by DLNA interoperability
guidelines for use in UPnP device description files.
urn:schemas-dlna-org:metadata-1-0/ Used for XML elements and attributes defined by DLNA interoperability
guidelines for use in DIDL-Lite documents and fragments.

6.7 General rules on XML documents and fragments

The DLNA interoperability guidelines use XML documents and fragments in UPnP communications.
To clarify the responsibility of each DLNA Device Class and DLNA Device Capability, this subclause
specifies the following general rules for XML documents and fragments.

• DLNA Device Classes and DLNA Device Capabilities that source XML documents or fragments
have the responsibility to provide valid (semantically and syntactically correct) and well-formed
XML documents and fragments. This also includes DLNA Device Classes and DLNA Device
Capabilities that receive XML documents or fragments and modify them syntactically,
semantically, or both.
• DLNA Device Classes and DLNA Device Capabilities that receive XML documents or fragments
from DLNA Device Classes and DLNA Device Capabilities can assume that the received XML
documents or fragments are valid and can forward them to other devices without validation.

7 Guideline requirements overview

7.1 General
This clause covers the guidelines that enable vendors to build interoperable products. Devices built
to the DLNA Home Networked Device interoperability guidelines will be able to manage, transfer,
and play personal media over a home network.

These guidelines are in a clause/subclause format as shown in Figure 12.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 53 –

Figure 12 – Guideline layout and definitions

The following list describes the content of Figure 12.

a) Name: A label for the guideline set. The label is preceded with a sequentially increasing number
to allow easy lookup.
b) Guidelines: The actual normative text of a guideline. A guideline is preceded with a sequentially
increasing number in each part to allow easy lookup and the beginning of the paragraph starts
with “[G UIDELINE ]”.
c) Attribute table: A summary of the essential attributes of a guideline. The table is preceeded with
the paragraph text “[ATTRIBUTES ]” and is a single row with the following definitions for the
columns:
• Compliance classifier: M/S/O (See 6.1 for the definition of guideline compliance classifiers).

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 54 –

• The specification usage classifier: A/C/F/L/R: for the guideline. (See 6.2 for the definition of
specification usage classifiers.)
• HND Device Classes and Device Capabilities (see Table 2 and Table 3 for definitions).
Device Capabilities are always listed in the HND column of the attribute table. Device
Capabilities can also apply equally to the MHD Device Category but have been omitted from
the MHD column in the attribute table to provide for better readability.
• MHD Device Classes(see Table 4 for definitions).
• Standards citation: Standards that are referenced by the guideline. Standards citations are
declared in Clause 2 and Bibliography.
• Guideline unique number: an alpha-numeric string that uniquely identifies a guideline in all
parts of this series of International Standards.
• Change indicator: documents that indicate the change in the guideline that occurred since
the last edition of the guideline (see Table 6 for definitions).
• Guideline attribute columns that do not have a value have the designation "n/a" (not
applicable). A visual map of possible values for the attribute tables is in Figure 13.
d) Add supplementary informative information about a guideline such as a justification for the
guideline, the specific interoperability issue that is addressed, etc. The first paragraph is
preceeded by the text “[C OMMENT]”.
Table 6 – Allowed values for change indicator fields in attribute tables

Value Meaning

<blank> No changes in the text or figures from the immediately-preceding version of this guideline.
A Attribute table itself, excluding the change indicator, has changed. For example, a new device class
was added.
C Changes made to the guideline modify the testing, intent, or other normative behavior relative to the
immediately-preceding version of this guideline.
D Guideline has been deleted.
E Changes made that do not modify testable guideline, intent, or other normative behavior.
N New. guideline did not exist in previous versions.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 55 –

Figure 13 – Visual map of possible values for the attribute tables

7.2 Conditions for measuring time in message exchanges

These guidelines define in certain cases time constraints for the exchange of messages between
two communicating endpoints. These time constraints have been defined as a means to provide
some operational consistency between the two communicating endpoints. However, in best-effort
networks, actual time measurements for exchanging messages show wide variations depending on
perturbations derived from network conditions, traffic, available bandwidth, and others. For this
reason, this subclause includes recommendations for conditions at the time of making these
measurements.

• The two communicating endpoints should establish communications under Ideal Network
Conditions.
• Time measurements at a given layer assume that the underlying layers preserve the
communication channel. For example, time measurements at the HTTP layer cannot be valid if
the underlying TCP/IP channel breaks during the measurements.
• Unless specified otherwise, time measurements assume that the communicating devices are
both in active mode. This means that time measurements should not include transitions from
sleep mode to active mode.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 56 –

8 Networking and connectivity

8.1 General
Networking and connectivity between devices is fundamental to the DLNA Home Networked Device
interoperability guidelines. The family of protocols known as the Internet Protocol (IP) is the
backbone for home network connectivity. Clusters of devices in the home can use other
interconnect technologies, but IP ties these clusters together within the home, and provides
connectivity outside the home to the global Internet. IP is independent of physical media and
therefore there are a variety of connectivity options for DLNA devices.

The Networking and connectivity guidelines are organized in the following subclauses.

• Networking and connectivity general capability requirements 8.2.

• Networking and connectivity QoS requirements 8.3
• Networking and connectivity device requirements 8.4
8.2 Networking and connectivity: General capability requirements
8.2.1 General
The guidelines in this subclause provide requirements for general capabilities. For example, these
requirements describe the baseline capabilities of any Ethernet or Wi-Fi implementation.

8.2.2 General capability requirements for Ethernet

8.2.2.1 NC Ethernet: Base
[G UIDELINE ] If Ethernet is supported, IEEE 802.3i (10BASE-T) and IEEE 802.3u (100BASE TX)
with auto negotiation capability and a connection to the network provided by an RJ45 connector
shall be required.

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.3 2B2RQ

8.2.2.2 NC Ethernet: Cabling

[G UIDELINE ] If Ethernet is supported, any supplied network cabling should have a rating of
Category 5e or better.

[ATTRIBUTES ]

S R n/a n/a n/a ANSI/ICEA I8GV6

8.2.2.3 NC Ethernet: Gigabit

[G UIDELINE ] If Ethernet is supported, IEEE 802.3ab (1000BASE T) is recommended in addition to
8.2.2.1. An implementation shall support auto negotiation of gigabit operation with a similarly
capable link partner and drop down to a lower speed as appropriate.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.3 79WPW

[C OMMENT] Gigabit Ethernet is becoming available and affordable for home networks.

8.2.2.4 NC Ethernet: QoS tolerance

[G UIDELINE ] If Ethernet is supported, incoming tagged packets shall be tolerated. Tagged packets
are Ethernet packets that include priority tags conformant with IEEE 802.3, 3.5, entitled Elements of

DLNA guidelines; Part 1-1: Architecture and protocols

 – 57 –

the Tagged MAC Frame. Here, tolerate means that the packet payload of any received tagged or
untagged packet shall be properly passed up to the higher layers in the network stack.

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.3 U7GZE

[C OMMENT] Packet tagging is the only QoS mechanism available on Ethernet at the link layer.
Many devices on home networks are already capable of sending tagged frames, so all devices need
to be able to tolerate them. For guidelines on tagging, see 8.3.2.1 and 8.3.2.2.

8.2.3 General capability requirements for IEEE 802.11

8.2.3.1 NC IEEE 802.11: Base
8.2.3.1.1
[G UIDELINE ] If IEEE 802.11 is supported, one or more of the following radio selections is allowed:

• IEEE 802.11a
• IEEE 802.11b
• IEEE 802.11g
• IEEE 802.11n
• Wi-Fi Direct
For example, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11a/b, IEEE 802.11b/g, and
IEEE 802.11a/b/g all meet this requirement.

[ATTRIBUTES ]

M R n/a n/a n/a Wi-Fi T4RMV

IEEE 802.11
IEEE 802.11
Wi-Fi Direct
System
Interoperabili
ty

[C OMMENT] There is no implied requirement that a device needs to support multiple radios nor is it
prohibited.
See Annex A for recommendations on Wireless Access Points and how they will help enable
interoperability between products with different radio selections.

8.2.3.1.2
[G UIDELINE ] If IEEE 802.11 is supported, the implementation shall support infrastructure mode
operation.

[ATTRIBUTES ]

M R n/a n/a n/a Wi-Fi PB3QQ

IEEE 802.11
IEEE 802.11
Wi-Fi Direct
System
Interoperabili
ty

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 58 –

[C OMMENT] Some DLNA Device Classes might be required to support Ad-hoc (IBSS) mode for
Wi-Fi conformance. However, the interoperability guidelines do not provide any requirements for
Ad-hoc (IBSS) operation. Devices can assume infrastructure mode as the default.

8.2.3.2 NC IEEE 802.11: Wi-Fi and Wi-Fi protected setup conformance

8.2.3.2.1
[G UIDELINE ] If an IEEE 802.11 radio interface is supported, the implementation shall conform to
one or more of the WFA test plans for IEEE 802.11 a/b/g Wi-Fi IEEE 802.11, IEEE 802.11n
IEEE 802.11, or Wi-Fi Direct Wi-Fi Direct System Interoperability at the time the product is offered
to the market.

[ATTRIBUTES ]

M R n/a n/a n/a Wi-Fi YSXRI

IEEE 802.11
IEEE 802.11
Wi-Fi Direct
System
Interoperabili
ty

[C OMMENT] WFA is the industry consortium that does IEEE 802.11 compatibility testing. Wi-Fi
interoperability requirements are increasing with time as new capabilities and features are specified
by IEEE 802.11.

Wi-Fi Direct devices that pass the P2P System Interoperability Test Plan Wi-Fi Direct System
Interoperability will pass one or more of the following: IEEE 802.11 a/g Interoperability Test Plan
Wi-Fi IEEE 802.11, or IEEE 802.11n System Interoperability Test Plan IEEE 802.11. Additional
Wi-Fi Direct perquisites include Wi-Fi WSC Test Plan Wi-Fi Simple Configuration and WMM Test
Plan WMM Test Plan. IEEE 802.11b is not supported by Wi-Fi Direct.

8.2.3.2.2
[G UIDELINE ] If Wi-Fi Direct is a supported radio interface, then the device will be WFA Wi-Fi Direct
certified to support Intra-BSS Distribution.

[ATTRIBUTES ]

M A n/a n/a n/a Wi-Fi Direct JWF45

System
Interoperabili
ty

[C OMMENT] Wi-Fi Intra-BSS Distribution is the name of the feature for bridging between members
of the group.

8.2.3.2.3
[G UIDELINE ] If Wi-Fi Simple Config is supported, the implementation shall conform to Wi-Fi Simple
Config test plan requirements at the time the product is offered to the market.

[ATTRIBUTES ]

M R n/a n/a n/a Wi-Fi Simple X4RS9

Configuration

DLNA guidelines; Part 1-1: Architecture and protocols

 – 59 –

8.2.4 General capability requirements for MoCA

8.2.4.1 NC MoCA: Connector
[G UIDELINE ] If MoCA is supported, then a 75 Ω Female F-Connector is required.

[ATTRIBUTES ]

M R n/a n/a n/a IEC 60169-24 HWWTE

8.2.4.2 NC MoCA: MoCA conformance

[G UIDELINE ] If MoCA is supported, the implementation shall conform to the MoCA Specification
and MoCA Certification Test Plan requirements at the time the product is offered to the market.

[ATTRIBUTES ]

M R n/a n/a n/a MoCA M6GKZ

MAC/PHY
MoCA
Certification

[C OMMENT] MoCA is the Multimedia over Coax Alliance – an industry consortium that defines
specifications for networking over the in-home coaxial cable MoCA MAC/PHY.

8.2.5 General capability requirements for HPNA

8.2.5.1 NC HPNA: Connector
[G UIDELINE ] If HPNA is supported, then a 75 Ω Female F-Connector is required.

[ATTRIBUTES ]

M R n/a n/a n/a IEC 60169-24 STTML

8.2.5.2 NC HPNA: HPNA conformance

[G UIDELINE ] If HPNA is supported, the implementation shall conform to the HPNA Specification
and HPNA Certification Test Plan requirements at the time the product is offered to the market.

[ATTRIBUTES ]

M R n/a n/a n/a ITU-T G.9954 V5HT4

8.2.6 General capability requirements for HomePlug AV and HD-PLC

8.2.6.1 NC HomePlug AV: HomePlug AV Conformance
[G UIDELINE ] If Homeplug AV PHY is supported, the implementation must conform to the HomePlug
AV Specification, HomePlug AV Compliance and HomePlug AV Interoperability requirements at the
time the product is offered to the market.

[ATTRIBUTES ]

M R n/a n/a n/a HomePlug AV V92Y2

Specification
HomePlug AV
Compliance
HomePlug AV
Interoperability

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 60 –

8.2.6.2 NC HD-PLC: HD-PLC conformance

[G UIDELINE ] If HD-PLC PHY is supported, the implementation must conform to the applicable
mandatory HD-PLC PHY based sections of the IEEE 1901and HD-PLC Connectivity Verification
requirements at the time the product is offered to the market.

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 1901 G4AR9

HD-PLC
Connectivity
Verification

8.3 Networking and connectivity: QoS requirements

8.3.1 General
The guidelines in this subclause provide requirements for priority-based QoS, hereinafter referred
to as DLNAQOS. With DLNAQOS, applications label (tag) packets with the User Priority (UP) that
dictates how the packets are allowed to access the network media and device queues. The
DLNAQOS guidelines are contained in several subclauses as illustrated in Figure 14. Table 7
summarizes the default DLNAQOS (User Priority) tag correlation between specific DLNA traffic
types and different network media types. In this table, streaming, interactive, and background
transfers are as defined in Table 40. The default priorities, or lower, are used if DLNAQOS is
implemented. It is not permitted to use priorities above the default stated.

Figure 14 – DLNA QoS visual organization

While there are eight priority categories defined by IEEE 802.1D, Annex G, HPNA (ITU-T G.9954),
Wi-Fi (WMM Specification, WMM Test Plan) and HomePlug AV only defines four categories and
MoCA MAC/PHY only defines three. Table 7 directly correlates IEEE 802.1Q, WMM, MoCA, HPNA,
HomePlug AV, HD-PLC and DSCP IETF RFC 2474 tags without any overlap, i.e. multiple
IEEE 802.1Q/DSCP values for a single WMM access class or MoCA Priority, or HomePlug AV
priority, but single 802.1Q/DSCP values for single HD-PLC priority.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 61 –

Table 7 – Normative priorities for DLNA traffic types

DLNAQO DLNA traffic IEEE WMM MoCA HPN HomePlu HD-PLC DSCP Subclause
S_UP types 802.1Q Access priority A g AV Priority details
User Category Channel
Priority Access
Priority

DLNAQO TCP 7 VO High 6 CA3 7 0x38 11.4.4.19

S_3 messages 8.3.2 (GUN
(Highest) generated by
TDFW2) in
Content
Receivers IEC 62481-3
DLNA Link 9.2.2 in
Protection key IEC 62481-3
exchange
messages
DLNAQO Audio-only or 5 VI Mediu 5 CA2 5 0x28 11.4.2.12
S_2 A/V Streaming m 10.1.6.22
Transfers 11.4.4.19
UPnP 11.4.4.209
AVTransport
stream control
RTCP
messages
generated by
Content
Sources
RTSP
messages
DLNAQO Default 0 BE Low 2 CA1 0 0x00 9.2.36
S_1 priority for any 11.4.2.11
traffic defined
by DLNA
guidelines,
unless
specified
otherwise
Interactive
transfers
Remote User
Interface
messages
DLNAQO Background 1 BK Low 0 CA0 1 0x08 11.4.2.10
S_0 transfers
(Lowest)

8.3.2 DLNAQOS requirements: Ethernet

8.3.2.1 NC Ethernet DLNAQOS: Conformance
[G UIDELINE ] If DLNAQOS is supported on an Ethernet network interface, then it shall be compliant
with all mandatory requirements for tagging where Tagged packets are Ethernet packets that
include priority tags conformant with IEEE 802.3, 3.5, entitled Elements of the Tagged MAC Frame
and Clause 9 of IEEE 802.1Q.

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q QQ463

IEEE 802.3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 62 –

[C OMMENT] Packet tagging is the QoS mechanism used for wired networks.

8.3.2.2 NC Ethernet DLNAQOS: Tagging

8.3.2.2.1
[G UIDELINE ] If DLNAQOS is supported on an Ethernet network interface, then the implementation
shall apply both the IEEE 802.1Q VLAN priority tag (except as noted in 8.3.2.2.4) as well as the
DSCP tag to outgoing traffic in accordance with the DLNAQOS_UP value in Table 7 or a lower
DLNAQOS_UP value (where "or a lower" is defined by 8.3.2.2.2 and 8.3.2.2.3).

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q RIP7M

IEEE 802.3

[C OMMENT] This guideline indicates that priorities above the values specified in Table 7 are not to
be used.
For exchanges involving a request and response, the implementation returning a response might
not know the required DLNAQOS_UP value until it has parsed the request. It is at that time when it
needs to apply the appropriate DLNAQOS_UP value.

There can be TCP network traffic during connection establishment that uses an inappropriate
DLNAQOS_UP value.

For an HTTP streaming operation, the server needs to ensure the appropriate DLNAQOS_UP value
(or lower) is used for the Entity Body.

8.3.2.2.2
[G UIDELINE ] The phrase "or a lower DLNAQOS_UP" value means that the highest permitted
DLNAQOS_UP value should be used.

[ATTRIBUTES ]

S A n/a n/a n/a n/a 5NZMS

8.3.2.2.3
[G UIDELINE ] The phrase "or a lower DLNAQOS_UP" value also means that a lower DLNAQOS_UP
value (indicated in the guideline) may be used.

[ATTRIBUTES ]

O A n/a n/a n/a n/a V64Y4

8.3.2.2.4
[G UIDELINE ] For best-effort traffic on Ethernet, the implementation may omit the IEEE 802.1Q
VLAN tag because frames with no tag are handled best-effort by default.

[ATTRIBUTES ]

O R n/a n/a n/a IEEE 802.1Q 6AZSX

IEEE 802.3

DLNA guidelines; Part 1-1: Architecture and protocols

 – 63 –

8.3.3 DLNAQOS requirements: IEEE 802.11

8.3.3.1 NC IEEE 802.11 DLNAQOS: Conformance
[G UIDELINE ] If DLNAQOS is supported on an IEEE 802.11 network interface, then it shall conform
to all mandatory requirements in the WiFi WMM Test Plan WMM Test Plan and specification WMM
Specification.

[ATTRIBUTES ]

M R n/a n/a n/a WMM VUO2Z

Specification
WMM Test
Plan

[C OMMENT] WMM provides the base level QoS specification for IEEE 802.11 network devices.

8.3.3.2 NC IEEE 802.11 DLNAQOS: Tagging

[G UIDELINE ] If DLNAQOS is supported on an IEEE 802.11 network interface, then the
implementation shall apply both the WMM tag as well as the DSCP tag to outgoing traffic in
accordance with the appropriate DLNAQOS_UP value in Table 7 or a lower DLNAQOS_UP value
(where "or a lower" is defined by 8.3.2.2.2 and 8.3.2.2.3).

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q FGY4S

IEEE 802.3
WMM Test
Plan
IETF RFC
2474

[C OMMENT] IEEE 802.1Q and DSCP correlation is in agreement with the WMM test plan
recommendation.

This guideline indicates that priorities above the values specified in Table 7 are not to be used.
For exchanges involving a request and response, the implementation returning a response might
not know the required DLNAQOS_UP value until it has parsed the request. It is at that time when it
needs to apply the appropriate DLNAQOS_UP value.

There can be TCP network traffic during connection establishment that uses an inappropriate
DLNAQOS_UP value.

8.3.4 DLNAQOS requirements: MoCA

8.3.4.1 NC MoCA DLNAQOS: Conformance
[G UIDELINE ] If DLNAQOS is supported on a MoCA network interface, then it shall be compliant with
all mandatory requirements for Ethernet tagging where Tagged packets are Ethernet packets that
include priority tags conformant with IEEE 802.3, 3.5, entitled Elements of the Tagged MAC Frame
and Clause 9 of IEEE 802.1Q.

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q TOVH8

MoCA
MAC/PHY

[C OMMENT] Packet tagging is the QoS mechanism used for wired networks. MoCA requires an
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 64 –

Ethernet convergence layer so that Ethernet packets are transported transparently across the
MoCA network.

8.3.4.2 NC MoCA DLNAQOS: Tagging

[G UIDELINE ] If DLNAQOS is supported on an MoCA network interface, then the implementation
shall apply both the IEEE 802.1Q VLAN priority tag (except as noted in 8.3.2.2.4) as well as the
DSCP tag to outgoing traffic in accordance with the DLNAQOS_UP value in Table 7 or a lower
DLNAQOS_UP value (where "or a lower" is defined by 8.3.2.2.2 and 8.3.2.2.3).

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q Z4L9V

MoCA
MAC/PHY

[C OMMENT] This guideline indictes that priorities above the values specified in Table 7 are not to
be used.
For exchanges involving a request and response, the implementation returning a response might
not know the required DLNAQOS_UP value until it has parsed the request. It is at that time when it
is expected to apply the appropriate DLNAQOS_UP value.

There can be TCP network traffic during connection establishment that uses an inappropriate
DLNAQOS_UP value.

For an HTTP streaming operation, the server needs to ensure the appropriate DLNAQOS_UP value
(or lower) is used for the Entity Body.

8.3.5 DLNAQOS requirements: HPNA

8.3.5.1 NC HPNA DLNAQOS: Conformance
[G UIDELINE ] If DLNAQOS is supported on an HPNA network interface, then it shall be compliant
with all mandatory requirements for Ethernet tagging where Tagged packets are Ethernet packets
that include priority tags conformant with IEEE 802.3, 3.5, entitled Elements of the Tagged MAC
Frame and Clause 9 of IEEE 802.1Q.

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q 39U8A

ITU-T G.9954

[C OMMENT] Packet tagging is the QoS mechanism used for wired networks. HPNA requires an
Ethernet convergence layer so that Ethernet packets are transported transparently across the
HPNA network.

8.3.5.2 NC HPNA DLNAQOS: Tagging

[G UIDELINE ] If DLNAQOS is supported on an HPNA network interface, then the implementation
shall apply both the IEEE 802.1Q VLAN priority tag (except as noted in 8.3.2.2.4) as well as the
DSCP tag to outgoing traffic in accordance with the DLNAQOS_UP value in Table 7 or a lower
DLNAQOS_UP value (where "or a lower" is defined by 8.3.2.2.2 and 8.3.2.2.3).

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q XQ6OB

ITU-T G.9954

[C OMMENT] This guideline indicates that priorities above the values specified in Table 7 are not to
DLNA guidelines; Part 1-1: Architecture and protocols
 – 65 –

be used.
For exchanges involving a request and response, the implementation returning a response might
not know the required DLNAQOS_UP value until it has parsed the request. It is at that time when it
is expected to apply the appropriate DLNAQOS_UP value.

There can be TCP network traffic during connection establishment that uses an inappropriate
DLNAQOS_UP value.

For an HTTP streaming operation, the server needs to ensure the appropriate DLNAQOS_UP value
(or lower) is used for the Entity Body.

8.3.6 DLNAQOS requirements: HomePlug AV

8.3.6.1 NC HomePlug AV DLNAQOS: Conformance
[G UIDELINE ] If DLNAQOS is supported on a Homeplug AV PHY network interface, then it must be
compliant with all mandatory requirements for Ethernet tagging where Tagged packets are Ethernet
packets that include priority tags conformant with IEEE 802.3, section 3.5, entitled 'Elements of the
Tagged MAC Frame' and section 9 of IEEE 802.1Q.

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q J44NP

IEEE 802.3
HomePlug AV
Specification

[C OMMENT] Packet tagging is the QoS mechanism used for wired networks. Homeplug AV requires
an Ethernet convergence layer so that Ethernet packets are transported transparently across the
Powerline network

8.3.6.2 NC HomePlug AV DLNAQOS: Tagging

[G UIDELINE ] If DLNAQOS is supported on a Homeplug AV PHY network interface, then the
implementation must apply both the 802.1Q VLAN priority tag (except as noted in Requirement
8.3.2.2.4) as well as the DSCP tag to outgoing traffic in accordance with the DLNAQOS_UP value in
Table 7 or a lower DLNAQOS_UP value (where "or a lower" is defined by Requirement 8.3.2.2.2 and
8.3.2.2.3).

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q 5O32M

HomePlug AV
Specification

[C OMMENT]

a) It is not permitted to use priorities above the values specified in Table 7.

b) For exchanges involving a request and response, the implementation returning a response may
not know the required DLNAQOS_UP value until it has parsed the request. It is at that time when
it should apply the appropriate DLNAQOS_UP value. Note: There may be TCP network traffic
during connection establishment that uses an inappropriate DLNAQOS_UP value.
c) For an HTTP streaming operation, the server must ensure the appropriate DLNAQOS_UP value
(or lower) is used for the Entity Body

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 66 –

8.3.7 DLNAQOS requirements: HD-PLC

8.3.7.1 NC HD-PLC DLNAQOS: Conformance
[G UIDELINE ] If DLNAQOS is supported on an HD-PLC PHY network interface, then it must be
compliant with all mandatory requirements for Ethernet tagging where Tagged packets are Ethernet
packets that include priority tags conformant with IEEE 802.3, section 3.5, entitled 'Elements of the
Tagged MAC Frame' and section 9 of IEEE 802.1Q .

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q GR28V

IEEE 802.3
IEEE 1901

[C OMMENT] Packet tagging is the QoS mechanism used for wired networks. HD-PLC requires an
Ethernet convergence layer so that Ethernet packets are transported transparently across the
Powerline network

8.3.7.2 NC HD-PLC DLNAQOS: Tagging

[G UIDELINE ] If DLNAQOS is supported on an HD-PLC PHY network interface, then the
implementation must apply both the 802.1Q VLAN priority tag (except as noted in Requirement
8.3.2.2.4) as well as the DSCP tag to outgoing traffic in accordance with the DLNAQOS_UP value in
Table 7 or a lower DLNAQOS_UP value (where "or a lower" is defined by Requirement 8.3.2.2.2 and
8.3.2.2.3).

[ATTRIBUTES ]

M R n/a n/a n/a IEEE 802.1Q IVHTK

IEEE 1901

[C OMMENT]

a) It is not permitted to use priorities above the values specified in Table 7.

b) For exchanges involving a request and response, the implementation returning a response may
not know the required DLNAQOS_UP value until it has parsed the request. It is at that time when
it should apply the appropriate DLNAQOS_UP value. Note: There may be TCP network traffic
during connection establishment that uses an inappropriate DLNAQOS_UP value.
c) For an HTTP streaming operation, the server must ensure the appropriate DLNAQOS_UP value
(or lower) is used for the Entity Body
8.4 Networking and connectivity: device requirements
8.4.1 General
The guidelines in this subclause specify the capabilities or combination of capabilities that DLNA
devices specifically support. These specific device requirements reference the guidelines defined in
8.2 , Table 7, and 8.2.6. For example, a specific requirement for DLNA HND devices is that they shall
support either Ethernet or IEEE 802.11 connectivity. Ethernet and IEEE 802.11 capabilities are
described in 8.2 and are referenced by name. Correspondingly, a specific requirement for DLNA
MHD devices is that they shall support Ethernet, IEEE 802.11 connectivity where Ethernet,
IEEE 802.11 is described in 8.2 and referenced by name.

8.4.2 Device requirements: common

8.4.2.1 NC Devices: IP stack
[G UIDELINE ] DLNA Device Classes shall support a TCP/IP stack that includes IPv4, TCP, UDP,
ARP, and ICMP components conformant to all required client aspects of IETF RFC 1122.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 67 –

[ATTRIBUTES ]

M R HND MHD n/a IETF RFC 768 64Y4F

IETF RFC 791
IETF RFC 792
IETF RFC 793
IETF RFC 826
IETF RFC 1122

[C OMMENT] A DNS client is omitted because it is not strictly needed for UPnP operations on the
network. Native IP addresses actually simplify the use of UPnP. Inclusion of DNS clients is
out-of-scope for DLNA. This means that vendors are not prohibited from including a DNS client, but
DLNA guidelines will not specify how to use DNS clients nor will the certification process test such
behaviors.

8.4.2.2 NC Devices: IPv6 stack and address acquisition

[G UIDELINE ] If a DLNA Device Class incorporates IPv6 Connectivity then it shall support IPv6
according to ISO/IEC 29341-1-2 Annex A.

[ATTRIBUTES ]

M R HND MHD n/a ISO/IEC UB9W4 N

29341-1-2

[C OMMENT] UPnP ISO/IEC 29341-1-2 Annex A references a number of IETF RFCs that specify
IPv6 behavior.

8.4.2.3 NC Devices: IPv4 address acquisition

8.4.2.3.1
[G UIDELINE ] DLNA Device Classes shall support DHCPv4 client functionality IETF RFC 2131 and
obtain an IPv4 address and subnet mask from a home network DHCPv4 server if present. They shall
implement Auto IP as defined by the UPnP Device Architecture v1.0 specification (ISO/IEC 29341-1)
so that if a DHCPv4 server is not present on the home network, a link-local network address can be
automatically acquired.

[ATTRIBUTES ]

M R HND MHD n/a IETF RFC 2131 NZMSY

ISO/IEC 29341-1

[C OMMENT] This guideline includes an assumption that devices need to transition from DHCPv4 to
Auto-IP, when devices fail to renew an expired IPv4 address (that was assigned by a DHCPv4
server). Likewise, Auto-IP requires the devices to make periodic attempts (once every 5 min) to
acquire a DHCPv4-assigned IP address, when operating with a self-assigned IP address.

Although it is desirable for a device using a DHCPv4-assigned IP address to exhibit interoperability

with a device using an Auto-IP address, DLNA states no requirement that full interoperability will
occur in such scenarios.

8.4.2.3.2
[G UIDELINE ] DLNA Device Classes that allocate addresses with the Auto-IP link local address
allocation system of ISO/IEC 29341-1 should adhere to all aspects of 2.7 of IETF RFC 3927. No
packet generated by a DLNA Device Class with an Auto-IP allocated address as the source or
destination address should be sent to a router for forwarding.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 68 –

[ATTRIBUTES ]

S R HND MHD n/a IETF RFC 3927 IP7MK

ISO/IEC 29341-1

[C OMMENT] Subclause 2.7 of IETF RFC 3927 contains information how Auto-IP addresses are
impacted by routed subnets.

8.4.2.3.3
[G UIDELINE ] DLNA Device Classes that allocate addresses with the DHCP address allocation
system should adhere to all aspects of 2.7 of IETF RFC 3927. No packet generated by a DLNA
Device Class with an Auto-IP allocated address as the destination address should be sent to a
router for forwarding.

[ATTRIBUTES ]

S R HND MHD n/a IETF RFC 3927 Q463H

[C OMMENT] Subclause 2.7 of IETF RFC 3927 contains information how Auto-IP addresses are
impacted by routed subnets.

8.4.2.3.4
[G UIDELINE ] DLNA Device Classes that allocate addresses with the Auto-IP link local address
allocation system of ISO/IEC 29341-1 should attempt to interoperate with DLNA Device Classes
that have allocated DHCPv4 addresses as indicated in Clause 3 of IETF RFC 3927 as to the
interaction between link-local and non-link-local addresses. A DLNA Device Class should attempt to
send all packets on the local link.

[ATTRIBUTES ]

S R HND MHD n/a IETF RFC 3927 VW6Y8

ISO/IEC 29341-1

8.4.2.3.5
[G UIDELINE ] DLNA Device Classes that allocate addresses with the DHCPv4 address allocation
system should attempt to interact with endpoints that have allocated link-local Auto-IP addresses as
indicated in Clause 3 of IETF RFC 3927. A DLNA Device Class should attempt to send all packets
bound to a link-local address on the local link.

[ATTRIBUTES ]

S R HND MHD n/a IETF RFC 3927 EENJB

8.4.2.3.6
[G UIDELINE ] When the lease on an IPv4 address expires, and the DLNA Device Class is unable to
renew the lease on that IPv4 address, or obtain a lease on a new IPv4 address, the Device Class
shall use an Auto-IP address. The Auto-IP address can be acquired before or after the DHCPv4
lease expires.

[ATTRIBUTES ]

M A HND MHD n/a IETF RFC 3927 W7RVO

IETF RFC 2131
ISO/IEC 29341-1

DLNA guidelines; Part 1-1: Architecture and protocols

 – 69 –

[C OMMENT] This guideline specifies that a DLNA Device Class will not utilize an expired DHCPv4
IPv4 address. The Auto-IP address can be previously obtained and defended while the DHCPv4
lease was active. Alternatively the Device Class can obtain a new Auto-IP address as defined in
8.4.2.3.1.

8.4.2.4 NC Devices: DLNAQOS support

8.4.2.4.1
[G UIDELINE ] DLNA Device Classes should support DLNAQOS on all network interfaces.

[ATTRIBUTES ]

S A HND MHD n/a n/a 6YK2S

8.4.2.4.2
[G UIDELINE ] If DLNAQOS is supported on an Ethernet network interface by a DLNA Device Class,
then it shall be conformant to all [NC Ethernet DLNAQOS:] labeled requirements in 8.3

[ATTRIBUTES ]

M A HND MHD n/a n/a QFZZ7

8.4.2.4.3
[G UIDELINE ] If DLNAQOS is supported on an IEEE 802.11 network interface by a DLNA Device
Class, then it shall be conformant to all [NC IEEE 802.11 DLNAQOS:] labeled requirements in 8.3

[ATTRIBUTES ]

M A HND MHD n/a FZZ7O

8.4.2.4.4
[G UIDELINE ] If DLNAQOS is supported on a MoCA network interface by a DLNA Device Class, then
it shall be conformant to all [NC MoCA DLNAQOS:] labeled requirements in 8.3

[ATTRIBUTES ]

M A HND MHD n/a n/a 6UAFT

8.4.2.4.5
[G UIDELINE ] If DLNAQOS is supported on an HPNA network interface by a DLNA Device Class,
then it shall be conformant to all [NC HPNA DLNAQOS:] labeled requirements in 8.3

[ATTRIBUTES ]

M A HND MHD n/a n/a 7L9NB

8.4.2.4.6
[G UIDELINE ] If DLNAQOS is supported on a HomePlug AV PHY network interface by a DLNA
Device Class, then it must be conformant to all [NC HomePlug AV DLNAQOS:] labeled
requirements in the Networking and connectivity: QoS Requirements

[ATTRIBUTES ]

M A HND MHD n/a n/a QAR95

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 70 –

8.4.2.4.7
[G UIDELINE ] If DLNAQOS is supported on an HD-PLC PHY network interface by a DLNA Device
Class, then it must be conformant to all [NC HD-PLC DLNAQOS:] labeled requirements in the
Networking and connectivity: QoS Requirements

[ATTRIBUTES ]

M A HND MHD n/a n/a J8HST

8.4.3 Device requirements: HND

8.4.3.1 NC HND devices: required/optional connectivity
8.4.3.1.1
[G UIDELINE ] DLNA Device Classes shall support at least one of the following connectivity
selections:

• Ethernet conformant to all [NC Ethernet:] labeled requirements in the General Capability
Requirements subclause of 8.2.
• IEEE 802.11 conformant to all [NC IEEE 802.11:] labeled requirements in the General
Capability Requirements subclause of 8.2.
[ATTRIBUTES ]

M R HND n/a n/a n/a 7RVON

8.4.3.1.2
[G UIDELINE ] DLNA Device Classes may support the following connectivity selections:

• MoCA conformant to all [NC MoCA:] labeled requirements in the General Capability
Requirements subclause of 8.2.
• HPNA conformant to all [NC HPNA:] labeled requirements in the General Capability
Requirements subclause of 8.2.
• Homeplug AV PHY conformant to all [NC HomePlug AV:] labeled requirements in the General
Capability Requirements subclause of 8.2
• HD-PLC PHY conformant to all [NC HD-PLC:] labeled requirements in the General Capability
Requirements subclause of 8.2.
[ATTRIBUTES ]

O R HND n/a n/a n/a CD695

[C OMMENT] MoCA, HPNA, HomePlug AV and HD-PLC are optional networks and connectivity for
DLNA Device Classes in the HND Device Category.

8.4.3.2 NC HND devices: recommended connectivity

[G UIDELINE ] DLNA Device Classes should support all of the following connectivity selections:

• Ethernet conformant to all [NC Ethernet:] labeled requirements in the General Capability
Requirements subclause of 8.2.
• IEEE 802.11 conformant to all [NC IEEE 802.11:] labeled requirements in the General
Capability Requirements subclause of 8.2.
Any of the above selections can be supported via an add on card, dongle, or equivalent.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 71 –

[ATTRIBUTES ]

S R HND n/a n/a n/a ZSXKY

[C OMMENT] This guideline is intended to ensure that a consumer does not have to understand the
different network connectivity types when purchasing a DLNA product. A consumer will be assured
a newly purchased product will work with other previously purchased DLNA products.

8.4.4 Device requirements: MHD

8.4.4.1 NC MHD devices: required/optional connectivity
8.4.4.1.1
[G UIDELINE ] DLNA Device Classes shall support at least one of the following connectivity
selections:

• Ethernet conformant to all [NC Ethernet:] labeled requirements in the General Capability
Requirements subclause of 8.2.
• IEEE 802.11 conformant to all [NC IEEE 802.11:] labeled requirements in the General
Capability Requirements subclause of 8.2.
[ATTRIBUTES ]

M R MHD n/a n/a n/a O2ZUW

8.4.4.1.2
[G UIDELINE ] DLNA Device Classes may support the following connectivity selections:

• MoCA conformant to all [NC MoCA:] labeled requirements in the General Capability
Requirements subclause of 8.2.
• HPNA conformant to all [NC HPNA:] labeled requirements in the General Capability
Requirements subclause of 8.2.
• Homeplug AV PHY conformant to all [NC HomePlug AV:] labeled requirements in the General
Capability Requirements subclause of 8.2
• HD-PLC PHY conformant to all [NC HD-PLC:] labeled requirements in the General Capability
Requirements subclause of 8.2.
[ATTRIBUTES ]

O R MHD n/a n/a n/a F855B

[C OMMENT] MoCA, HPNA, HomePlug Av and HD-PLC are optional networks and connectivity for
DLNA Device Classes in the HND Device Category.

9 Device discovery and control

9.1 General
This subclause of the DLNA Home Networked Device Interoperability Guidelines covers the
guidelines for implementing device discovery and control using the UPnP device architecture.
These guidelines balance the needs for both devices and control points, and specify rules for a
variety of protocol areas, such as SSDP, GENA events, SOAP actions, and HTTP transports for
UPnP communications. It should be noted that HTTP guidelines in this subclause apply only to
UPnP-related transactions and not to content transfer transactions.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 72 –

In this subclause, the following terms are used.

• UPnP endpoints: Refers to both UPnP devices and UPnP control points.
• HTTP clients: Refers to the HTTP clients used for UPnP communications. HTTP client
guidelines in this subclause do not apply to HTTP transport for content transfers or playback.
• HTTP servers: Refers to the HTTP servers used for UPnP communications. HTTP server
guidelines in this subclause do not apply to HTTP transport for content transfers or playback.
The general rules for handling XML documents and fragments are specified in 6.7.

9.2 Device discovery and control guidelines

9.2.1 DDC UPnP Device Architecture
9.2.1.1
[G UIDELINE ] DLNA Device Classes and Device Capabilities shall fully support the applicable
mandatory portions of the UPnP Device Architecture v1.0 (UPnP DA) for discovery, description,
control, eventing, and presentation.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a ISO/IEC YH2P3

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

[C OMMENT] DLNA specifies UPnP Device Architecture 1.0 (UPnP DA) as the basic protocol
framework for Device Classes.

9.2.1.2
[G UIDELINE ] A UPnP control point designed for a version of a UPnP Device Architecture, shall also
be able to interoperate with later versions of the UPnP Device Architecture that have the same
major versions.

"Interoperate" means that a control point that has certain capabilities for older devices can at least
provide the same capabilities for newer devices. For example, a control point that can discover an
older UPnP device, parse its device and service description files, and invoke its UPnP actions shall
be able to do those same things with a UPnP device with a newer minor revision of the UPnP Device
Architecture.

[ATTRIBUTES ]

M C DMP DMC M-DMP M-DMC n/a ISO/IEC TT4PY

+DN+ +PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] Clause 1 of ISO/IEC 29341-1 indicates that advances in minor version of the UPnP
Device Architecture are a superset of earlier (minor) versions with the same major version. This
means that future UPnP devices with a newer minor revision will implement all of the behavior
required of the previous device architectures.
Although not explicitly stated by the UPnP Device Architecture, the intent of such backwards
compatibility rules is to enable forward compatibility of control points with newer, minor revisions of
the UPnP device architecture. Guidelines 9.2.1.2 and 9.2.1.3 formally require forward compatibility
of control points, which is necessary for future interoperability.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 73 –

Version of the UPnP Device Architecture appears in the <specVersion> element of the device and
service descriptions and the SERVER header in SSDP, SOAP, and GENA messages.

One way to implement 9.2.1.2 is for the UPnP control point to treat the minor version a UPnP device
architecture as 0 (i.e. ignore the minor version).

9.2.1.3
[G UIDELINE ] A UPnP control point designed for a version of a UPnP device type or service type
shall be able to interoperate with later versions of the same device type or service type.

"Interoperate" means that a control point that has certain capabilities for an older device can at least
provide the same capabilities for a newer device of the same type and services. For example, a
control point that can discover an older UPnP AV MediaServer and invoke its CDS:Browse action
shall be able to discover and invoke CDS:Browse on a newer UPnP MediaServer. The newer UPnP
device can be newer because the device type and/or one of its associated UPnP services are of a
newer version.

[ATTRIBUTES ]

M C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC GZJXU

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] 2.1 of ISO/IEC 29341-1states that standardized device types and service types are
required to be a superset of all previous versions of the same device/service type. This means that
future UPnP device and service types will require all of the behavior defined for previous versions.

Device version appears as part of the value in a <deviceType> element of a device description file.
Similarly, the service version appears as part of the value in a <serviceType> element of a service
description file. Version numbers also appear in NT, ST, and USN headers of SSDP messages.
Furthermore, a service version appears in the xmlns namespace attributes of SOAP messages.

Older control points that interact with newer UPnP device/service types are not expected to
interoperate with conventions established for the newer device or service type, but they will still use
parts of the UPnP device/service that are compatible with the older conventions.

9.2.1.4
[G UIDELINE ] If a SOAP action was defined in the specification of a previous service version, a
UPnP control point may specify the xmlns namespace attribute for the service type and the SOAP
ACTION header in the SOAP request with the earlier service version.

[ATTRIBUTES ]

O C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC 6S95W

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] In other words, if a SOAP action was defined in the specification of a previous service
version (e.g. version 1), then a UPnP control point can invoke the SOAP action with the earlier
service version regardless of the service version described in the device description.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 74 –

9.2.1.5
[G UIDELINE ] If a DLNA Device Class and Device Capability implements the IPv6 Connectivity
Optional Device Function then it shall conform to the ISO/IEC 29341-1-2 Annex A for discovery,
description, control, eventing and presentation.

[ATTRIBUTES ]

M R HND MHD n/a ISO/IEC 6TRHC N

29341-1-2

[C OMMENT] ISO/IEC 29341-1-2 Annex A references a number of IETF RFCs that specify IPv6
behavior.

9.2.1.6
[G UIDELINE ] If a UPnP Control Point that incorporates the IPv6 Connectivity Device Function is
presented with both IPv4 and IPv6 addresses for UPnP Communications, then it shall use the IPv4
address for subsequent communications.

[ATTRIBUTES ]

M A DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC C5RCV N

+PU+ +UP+ 29341-1-2
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.1.7
[G UIDELINE ] DLNA Device Classes and Device Capabilities shall implement the IPv6 Connectivity
Device Function.

[ATTRIBUTES ]

M R HND MHD n/a n/a 9RQFP N

9.2.2 DDC UPnP Auto IP support

9.2.2.1
[G UIDELINE ] UPnP devices and control points shall implement the Auto-IP behavior defined in
ISO/IEC 29341-1 even if they implement a DHCPv4 server.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a ISO/IEC G55WU

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

[C OMMENT] DLNA Device Classes that do not properly support DHCPv4 and AutoIP as required by
the UPnP DA can cause IPv4 addressing problems for other UPnP entities.

9.2.2.2
[G UIDELINE ] Whenever a UPnP device switches to a new IPv4 address (whether assigned through
Auto-IP or DHCPv4), the device should send an ssdp:byebye message for (and on) the old IPv4
address.

For (and on) the old IPv4 address means that the IPv4 address indicated in the (UDP header of the)
ssdp:byebye matches the old IPv4 address of the UPnP device.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 75 –

[ATTRIBUTES ]

S L DMS DMR M-DMS n/a ISO/IEC WANFQ

29341-1

[C OMMENT] This allows control points that discovered the UPnP device on the old IPv4 address to
know that the UPnP device is no longer available at the old address. However, this behavior is not
always possible for implementations built on some platforms.

9.2.2.3
[G UIDELINE ] If UPnP devices and control points use a self-assigned IPv4 address, then they shall
implement duplicate address detection before assigning the address.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a ISO/IEC WS55I

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This guideline repeats a UPnP DA requirement that prevents the assignment of
conflicting IPv4 addresses (see subclauses 0.2 and 0.3 of ISO/IEC 29341-1).

9.2.2.4
[G UIDELINE ] If a DLNA device class implements a DHCPv4 server, it shall provide a mechanism to
disable and enable the DHCPv4 server.

[ATTRIBUTES ]

M A HND MHD n/a ISO/IEC JCPVD

29341-1

[C OMMENT] This guideline clarifies the condition for DHCPv4 server support in a DLNA device. The
user needs to be able to disable the DHCPv4 server function to avoid the presence of multiple
DHCPv4 servers providing different network configurations on the same home network.

9.2.3 DDC UPnP SSDP default port

9.2.3.1
[G UIDELINE ] UPnP devices shall receive and process M-SEARCH messages on port 1900.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC 4NBO8

29341-1

[C OMMENT] This requirement ensures that devices always listen on port 1900. Devices respond to
M-SEARCH messages according to ISO/IEC 29341-1.

9.2.3.2
[G UIDELINE ] UPnP control points should receive and process NOTIFY messages on port 1900.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 76 –

[ATTRIBUTES ]

S C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC DEPDO

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This guideline encourages UPnP control points to listen on port 1900 and use the
information from NOTIFY messages (ssdp:alive and ssdp:byebye). However, some UPnP control
points rely on M-SEARCH messages instead of NOTIFY messages to keep track of UPnP devices.
For example, if UPnP control points connect sporadically to the network to perform media-related
tasks.

9.2.3.3
[G UIDELINE ] UPnP devices shall always explicitly specify port 1900 in every HOST header tag for
every SSDP message.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a ISO/IEC 9MI39

29341-1

9.2.3.4
[G UIDELINE ] UPnP control points receiving an SSDP message without the port number in the
HOST header tag, shall infer the port number is 1900.

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC GQ888

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.3.5
[G UIDELINE ] UPnP control points shall send M-SEARCH messages using a source port greater
than 1024 and not 1900.

[ATTRIBUTES ]

M L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC Q888R

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] These guidelines are based on a Microsoft technical advisory regarding security
concerns for UPnP.

9.2.3.6
[G UIDELINE ] UPnP devices may ignore M-SEARCH messages if the originating source port is less
than or equal to 1024 or equal to 1900.

[ATTRIBUTES ]

O L DMS DMR M-DMS n/a ISO/IEC MI39Y

29341-1

DLNA guidelines; Part 1-1: Architecture and protocols

 – 77 –

9.2.4 DDC UPnP discovery robustness

9.2.4.1
[G UIDELINE ] UPnP endpoints (devices and control points) should wait a random amount of time,
between 0 ms and 100 ms after acquiring a new IP address, before sending advertisements or
initiating searches on the new IP address.

[ATTRIBUTES ]

S L HND +DN+ +PU+ MHD n/a ISO/IEC NBO8C

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This suggestion avoids SSDP discovery flooding on home networks that contain a
large number of UPnP endpoints.

9.2.4.2
[G UIDELINE ] UPnP network devices shall not send more than 10 ssdp:alive messages from a single
IP address in any given 200 ms period.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC CPVDX

29341-1

[C OMMENT] This guideline prevents lost packets caused by buffer overflow of Ethernet drivers by
UPnP devices with many services or embedded devices in the device hierarchy.

9.2.4.3
[G UIDELINE ] UPnP devices shall send each advertisement set more than once on a single network
interface. It is recommended that UPnP devices send a total of 2 or 3 advertisement sets.

An advertisement set refers to the set of 3+2d+k ssdp:alive messages that UPnP device sends as
part of its periodic advertisements.

The repeated advertisement sets are referred to as duplicate sets.

The transmission windows for advertisement sets and duplicate sets cannot overlap in time.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC S55IQ

29341-1

[C OMMENT] This guideline clarifies how a UPnP device needs to retransmit its advertisements.
However, implementers are reminded that advertising too frequently runs the risk of flooding the
SSDP channel.

9.2.4.4
[G UIDELINE ] A UPnP device that uses the same UDN on multiple network interfaces, shall send
each individual ssdp:alive message (from an advertisement set) on all interfaces within a 10 s
transmission window.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 78 –

Time intervals between individual ssdp:alive messages on a single interface are not restricted by
this requirement.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC ANFQT

29341-1

[C OMMENT] Control Points need a way to determine the most reliable network route to the UPnP
device. This guideline ensures that control points will receive an individual ssdp:alive message on
all network interfaces within a 10 s transmission window.

9.2.4.5
[G UIDELINE ] The interval of sending these advertisement groups on a single network interface
shall be less than half of the CACHE-CONTROL value.

The first advertisement set and the duplicate sets (transmitted on a single network interface) make
up an advertisement group.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC 55WUY

29341-1

[C OMMENT] For consistency and interoperability, devices need to advertise more often than their
notification cycle. However, implementers are reminded that advertising too frequently runs the risk
of flooding the SSDP channel.

9.2.4.6
[G UIDELINE ] The CACHE-CONTROL value should be at least 1800, as recommended in the UPnP
device architecture.

[ATTRIBUTES ]

S R DMS DMR M-DMS n/a ISO/IEC S95WV

29341-1

[C OMMENT] Most devices that remain on the network for long periods have a CACHE-CONTROL
value of 1800. However, some devices (mobile, wireless, etc.) might want a smaller
CACHE-CONTROL value.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 79 –

Key
A One or more ssdp:alive messages, within advertisement sets and duplicate sets.
B Advertisement set of 3+2d+k ssdp:alive messages.
C Duplicate set of 3+2d+k ssdp:alive messages. (see 9.2.4.3)
D Combined advertisement set and duplicate sets make an advertisement group (see 9.2.4.5).
E Delay between advertisement groups on same network is less than half of a CACHE-CONTROL value (see 9.2.4.5).
F Any arbitrary window of 200 ms have 10 or fewer ssdp:alive messages (see 9.2.4.2). An entire advertisement set need
not fit inside the 200 ms window.
G An individual ssdp:alive message shall have all corresponding ssdp:alive sent within a 10 s transmission window (see
9.2.4.4).
H This delay is not drawn to scale.

Figure 15 – UPnP discovery robustness

9.2.4.7
[G UIDELINE ] Due to the unreliable nature of UDP, control points should send each M-SEARCH
message more than once, not to exceed 10 M-SEARCH requests in a 200 ms period. An
M-SEARCH message and its repeated duplicates should all be sent within a 10 s period. See Figure
15 for an example of UPnP discovery robustness.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 80 –

[ATTRIBUTES ]

S R DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC ZJXUT

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] Wireless access points do not retry multicast traffic and can cause UPnP discovery
problems. This recommendation repeats advice from the UPnP DA.

The 10 M-SEARCH messages per 200 ms period is consistent with maximum saturation limit of 10
ssdp:alive messages per 200 ms period for UPnP devices (9.2.4.2). Likewise, the sending of all the
M-SEARCH messages in a window of 10 s is consistent with the requirement where all duplicates of
an individual ssdp:alive message are sent within 10 s (9.2.4.4).

9.2.4.8
[G UIDELINE ] The control point should wait at least the amount of time specified in the MX header
for responses to arrive from devices. The time waited for responses should be extended by
additional time (a second or two) to allow for network propagation and processing delays.

[ATTRIBUTES ]

S R DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC T4PYW

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.4.9
[G UIDELINE ] Upon startup, UPnP devices should broadcast an ssdp:byebye before sending the
initial ssdp:alive onto the local network.

[ATTRIBUTES ]

S L DMS DMR M-DMS n/a ISO/IEC H2P3Y

29341-1

[C OMMENT] The UPnP device architecture specification does not account for devices that reset
without sending an ssdp:byebye. If devices do not send an ssdp:byebye when returning to the
network after such an event, control points cannot tell if the received announcement is for a new
device instance, or is merely a periodic announcement for the same device instance.

Sending an ssdp:byebye as part of the normal start up process for a UPnP device ensures that
UPnP control points with information about the previous device instance will safely discard state
information about the previous device instance before communicating with the new device instance.

9.2.4.10
[G UIDELINE ] UPnP control points after acquireing a new IP address shall initiate searches (e.g.
M-SEARCH) from the new IP address.

[ATTRIBUTES ]

M A DMP DMC +UP+ M-DMP M-DMC n/a ISO/IEC SSV9L

+DN+ +PU+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

DLNA guidelines; Part 1-1: Architecture and protocols

 – 81 –

[C OMMENT] This guideline ensures a Control Point always discovers the available UPnP devices
after the acquisition of the new IP address, independent of whether the IP address is IPv4 or IPv6.
The timing of issuing M-SEARCH is as specified in guideline 9.2.4.1 as guidance.

9.2.5 DDC UPnP HTTP support and general rules

9.2.5.1
[G UIDELINE ] UPnP endpoints (devices and control points) shall support at least HTTP/1.0
(IETF RFC 1945) for performing UPnP communications, excluding SSDP communications.

For SSDP communications, UPnP endpoints shall use the HTTP/1.1 message format defined in
ISO/IEC 29341-1.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC SV9LG

+UP+ +DNSYNC+ 1945
+UPSYNC+ +SR+ ISO/IEC
+EPG+ 29341-1

[C OMMENT] SSDP messages are based on the HTTP/1.1 message format with method and header
extensions.

9.2.5.2
[G UIDELINE ] UPnP devices shall support HTTP/1.1.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a IETF RFC 2P3YZ

2616
ISO/IEC
29341-1

[C OMMENT] Although HTTP/1.0 is the baseline for UPnP communications, HTTP/1.1 is

encouraged.

9.2.5.3
[G UIDELINE ] HTTP servers of UPnP control points shall support HTTP/1.1.

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a IETF RFC 4PYWQ

+PU+ +UP+ 2616
+DNSYNC+ ISO/IEC
+UPSYNC+ +SR+ 29341-1
+EPG+

9.2.5.4
[G UIDELINE ] HTTP clients of UPnP control points should use and support HTTP/1.1.

[ATTRIBUTES ]

S C DMP DMC +DN+ M-DMP M-DMC n/a IETF RFC JXUT6

+PU+ +UP+ 2616
+DNSYNC+ ISO/IEC
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 82 –

+UPSYNC+ +SR+ 29341-1

+EPG+

9.2.5.5
[G UIDELINE ] The message format of HTTP responses (sent by HTTP servers of both devices and
control points) shall be compliant with the version number specified by the request.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC 95WVR

+UP+ +DNSYNC+ 2145
+UPSYNC+ +SR+
+EPG+

[C OMMENT] The clarifying IETF specification (IETF RFC 2145) states that HTTP/1.1 servers
should return HTTP/1.1 even if the HTTP server receives a request marked with HTTP/1.0. The
robustness rules, specified by the HTTP specification, enables clients and servers that employ
different HTTP version numbers to coexist properly.

9.2.5.6
[G UIDELINE ] HTTP/1.1 servers of UPnP endpoints (devices and control points) should return HTTP
version 1.1 in the response header, regardless of the version specified in the HTTP client's request.

[ATTRIBUTES ]

S R HND +DN+ +PU+ MHD n/a IETF RFC 5WUY7

+UP+ +DNSYNC+ 2145
+UPSYNC+ +SR+
+EPG+

9.2.5.7
[G UIDELINE ] HTTP servers of UPnP endpoints (devices and control points) shall not report a higher
version of HTTP than is actually supported by the implementation.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC NFQTX

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

9.2.5.8
[G UIDELINE ] The HTTP servers and clients of UPnP endpoints (devices and control points) shall be
able to properly parse all HTTP headers provided to them. In particular, they shall support HTTP
header tags in any order and accept the tag name in a case insensitive manner and associated data
in a case sensitive manner. If a header tag is not recognized by a UPnP endpoint, it shall ignore the
header and continue parsing the packet.

This guideline applies to all HTTP headers, regardless of whether the DLNA guidelines define a
BNF syntax for the HTTP header value. In other words, all endpoints shall implement a "parse and
interpret" or "parse and ignore" when parsing an HTTP header field.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 83 –

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC 55IQI

+UP+ +DNSYNC+ 1945
+UPSYNC+ +SR+ IETF RFC
+EPG+ 2616

[C OMMENT] This guideline specifies a minimal robustness level for parsing HTTP headers. The
HTTP headers include both HTTP headers defined in IETF RFC 2616 and other headers, such as
DLNA defined and vendor defined headers, used for DLNA interoperability.

9.2.5.9
[G UIDELINE ] The HTTP servers and clients of UPnP endpoints (devices and control points) shall
include the Content-Type header tag in every UPnP-related TCP-based HTTP transaction (SOAP,
GENA, and device/service description) that contains an XML body. This content type shall always
be marked as the following:

• text/xml; charset="utf-8"
Note that charset parameter value is case insensitive and double quotations may be omitted.

Furthermore, the XML shall be encoded in UTF-8.

UPnP endpoints (devices and control points) that receive a content type of text/xml shall infer UTF-8
character set encoding.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC PVDXI

+UP+ +DNSYNC+ 1945
+UPSYNC+ +SR+ IETF RFC
+EPG+ 2616

[C OMMENT] Restricting UPnP communications to UTF-8 simplifies implementations so that

devices need not implement a separate parsing engine for every local region.

9.2.5.10
[G UIDELINE ] If the DLNA guidelines define a BNF syntax for an HTTP header, then the HTTP
servers and clients of UPnP endpoints shall not include white spaces in the header-value of HTTP
headers unless SP and LWS are explicitly specified in the syntax (BNF) definitions.

If the DLNA guidelines do not define a BNF syntax for an HTTP header, then the header shall
conform to the message-header syntax in 4.2 of IETF RFC 2616, regardless of whether the HTTP
header is defined in IETF RFC 2616 or if the HTTP header is vendor-defined. Note that the syntax
for field-value permits LWS to separate tokens and other data in the field-value.

Implied LWS between the HTTP header-name and the HTTP header-value are permitted as
specified in IETF RFC 2616, regardless of whether the DLNA guidelines specify a BNF syntax for
the HTTP header.

[ATTRIBUTES ]

M A HND +DN+ +PU+ MHD n/a IETF RFC BO8CA

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 84 –

[C OMMENT] Conformance to 6.4, the restriction on the use of SP and LWS characters, is applied in
UPnP HTTP communications. White spaces between header-name and header-value are still
acceptable.
The header-name and header-value are defined by the field-name and field-value tokens of the
message-header syntax in 4.2 of IETF RFC 2616.

9.2.6 DDC UPnP HTTP/1.0 rules

9.2.6.1
[G UIDELINE ] For all HTTP/1.0 transactions, the HTTP server shall close the TCP connection after
sending the complete HTTP response. This guideline covers both kinds of HTTP/1.0 transactions:

• HTTP/1.1 server responds to an HTTP/1.0 request, and

• HTTP/1.0 server responds to an HTTP/1.1 request.
[ATTRIBUTES ]

M C HND +DN+ +PU+ MHD n/a IETF RFC I39YP

+UP+ +DNSYNC+ 1945
+UPSYNC+ +SR+ IETF RFC
+EPG+ 2616

[C OMMENT] The use of the Content-Length field greatly reduces the parsing complexity of HTTP
message bodies on a UPnP control point.

When an HTTP server responds to an HTTP/1.0 request without closing the socket, the
Content-Length field is the only method that a client can use to determine that the entire response
was received.

9.2.6.2
[G UIDELINE ] If a UPnP device's HTTP server responds to a SOAP request as part of an HTTP/1.0
transaction, then the UPnP device shall close the TCP connection after the response has been sent.

This guideline covers both kinds of HTTP/1.0 transactions:

• HTTP/1.1 server responds to an HTTP/1.0 request, and

• HTTP/1.0 server responds to an HTTP/1.1 request.
Also note that in both of the above cases, the UPnP device has the HTTP server and the UPnP
control point issues the HTTP request.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a IETF RFC 39YPQ

1945
IETF RFC
2616

[C OMMENT] This is the proper behavior for a UPnP device, as it follows standard HTTP rules.

9.2.6.3
[G UIDELINE ] If a UPnP control point's HTTP server responds to a GENA event as part of an
HTTP/1.0 transaction, then the control point shall close the TCP connection after the response has
been sent.

This guideline covers both kinds of HTTP/1.0 transactions:

DLNA guidelines; Part 1-1: Architecture and protocols
 – 85 –

• HTTP/1.1 server responds to an HTTP/1.0 request, and

• HTTP/1.0 server responds to an HTTP/1.1 request.
Also note that in both of the above cases, the UPnP control point has a HTTP server and the UPnP
devices issue the HTTP request.

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a IETF RFC 88RDT

+PU+ +UP+ 1945
+DNSYNC+ IETF RFC
+UPSYNC+ +SR+ 2616
+EPG+

[C OMMENT] This is the proper behavior for a UPnP control point.

9.2.7 DDC UPnP HTTP/1.1 transaction rules

9.2.7.1
[G UIDELINE ] A UPnP device's HTTP server shall close the TCP connection after responding to a
SOAP request with the CONNECTION: CLOSE token.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a IETF RFC O8CA7

2616

9.2.7.2
[G UIDELINE ] A UPnP control point's HTTP server shall close the TCP connection after responding
to an event that was sent with the CONNECTION: CLOSE token.

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a IETF RFC VDXID

+PU+ +UP+ 2616
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.7.3
[G UIDELINE ] HTTP clients of UPnP endpoints (devices and control points) shall not report support
for HTTP/1.1 unless they also support Chunked Transfer Coding and correctly parse a 100
(Continue Response), as required by the HTTP/1.1 specification.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC 5IQI5

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

[C OMMENT] Only HTTP clients that support Chunked Transfer Coding and 100 (Continue
Response) messages can initiate HTTP/1.1 transactions.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 86 –

9.2.7.4
[G UIDELINE ] The HTTP servers of UPnP endpoints (devices and control points) shall use the
Content-Length HTTP header tag at all times, unless the connection will be closed after the
response is sent or Chunked Transfer Coding is used.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC FQTXQ

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

[C OMMENT] When an HTTP/1.1 server sends a response back to the client without closing the
socket afterwards, the client will not know when the entire response was received, unless the
response was encoded with Chunked Transfer Coding, without interpreting the Content-Length
header.

9.2.7.5
[G UIDELINE ] The HTTP clients of UPnP endpoints (devices and control points) may issue
HTTP/1.1 requests encoded with Chunked Transfer Coding.

[ATTRIBUTES ]

O R HND +DN+ +PU+ MHD n/a IETF RFC WUY7P

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

[C OMMENT] These guidelines repeat the HTTP specification by noting the permitted use of
Chunked Transfer Coding for HTTP/1.1 requests. HTTP clients of UPnP devices can use Chunked
Transfer Coding for delivery of UPnP GENA events. HTTP clients of UPnP control points can use
Chunked Transfer Coding for delivery of UPnP SOAP actions. As such, HTTP/1.1 servers of UPnP
endpoints are required to support HTTP/1.1 requests encoded with Chunked Transfer Coding.

9.2.7.6
[G UIDELINE ] The HTTP servers of UPnP endpoints (devices and control points) shall accept,
decode, and respond to HTTP/1.1 requests encoded with Chunked Transfer Coding.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC 5WVR8

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

9.2.8 DDC UPnP HTTP persistent connections

9.2.8.1
[G UIDELINE ] The HTTP clients and servers of UPnP endpoints (devices and control points) should
support persistent HTTP/1.1 connections and pipelining.

[ATTRIBUTES ]

S R HND +DN+ +PU+ MHD n/a IETF RFC PYWQP

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

DLNA guidelines; Part 1-1: Architecture and protocols

 – 87 –

[C OMMENT] Persistent HTTP connections allow devices and control points to use fewer resources
when communicating. Pipelining adds the ability for control points to queue requests onto an
existing session.

9.2.8.2
[G UIDELINE ] The HTTP clients of UPnP endpoints should use persistent HTTP/1.1 connections.

[ATTRIBUTES ]

S R HND +DN+ +PU+ MHD n/a IETF RFC P3YZ8

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

[C OMMENT] The default behavior for HTTP/1.1 is a persistent connection. Persistent connections
result in no accumulation of TCP TIME-WAIT because the originator of the connection closes the
socket.

9.2.8.3
[G UIDELINE ] The HTTP clients of UPnP endpoints shall fall back to non-pipelining if the connection
is closed after the first request and a second (or more) request from the same network entity is
pending.

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a IETF RFC V9LGQ

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This guideline ensures consistent and correct behavior between mixes of UPnP
endpoints that might or might not support HTTP pipelining.

9.2.8.4
[G UIDELINE ] The HTTP servers of UPnP endpoints (devices and control points) that do not support
persistent connections shall answer the first HTTP request from the requesting UPnP control point
and close the TCP connection to correctly ignore other requests.

[ATTRIBUTES ]

M C HND +DN+ +PU+ MHD n/a IETF RFC 9LGQX

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

9.2.8.5
[G UIDELINE ] The HTTP clients of UPnP endpoints that send multiple requests in a single HTTP
session shall be ready to open new HTTP sessions if the device does not respond to all requests on
the initial HTTP session.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 88 –

[ATTRIBUTES ]

M C HND +DN+ +PU+ MHD n/a IETF RFC 3YZ8Z

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

9.2.8.6
[G UIDELINE ] The HTTP clients of UPnP endpoints shall close a persistent connection (HTTP/1.1)
within 60 s of inactivity (i.e., no traffic and no pending requests).

This guideline applies to both UPnP devices and control points. Context of this guideline is specific
to UPnP related communications, excluding SSDP communications. This guideline does not apply
to the transport layer communications for media content transfers.

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a IETF RFC YWQPE

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This prevents control points and devices from holding network sockets for an
unnecessarily long period.

9.2.9 DDC UPnP device responsiveness

9.2.9.1
[G ENERAL ] UPnP Device Architecture specification requires UPnP devices to complete the SOAP
response in 30 s. However, this can be difficult to guarantee at the implementation layer for all types
of UPnP actions. These guidelines attempt to strike a balance between ideal goals and practical
implementation needs for both devices and control points.

That being stated, the original inspiration for these guidelines is that some UPnP AV MediaServer
devices cannot guarantee that a response will complete within 30 s for a variety of reasons. Network
bandwidth, query complexity, and hardware performance can vary. This being the case, such
devices shall still begin their response within 30 s.

Also note that a UPnP AV MediaServer can reduce a long transmission time for a SOAP response
(for a CDS:Browse or CDS:Search action) by reducing the number of returned items in the result.
See guideline 10.1.4.10.7 for more information.

9.2.9.2
[G UIDELINE ] UPnP devices shall begin the transmission of a SOAP response within 27 s of
receiving a complete SOAP request.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC UT6RC

29341-1

9.2.9.3
[G UIDELINE ] UPnP devices should begin the transmission of SOAP responses as soon as possible.

[ATTRIBUTES ]

S C DMS DMR M-DMS n/a ISO/IEC WVR8Q

29341-1

DLNA guidelines; Part 1-1: Architecture and protocols

 – 89 –

9.2.9.4
[G UIDELINE ] UPnP devices should complete the transmission of a SOAP response within 29 s.

[ATTRIBUTES ]

S C DMS DMR M-DMS n/a ISO/IEC UY7PT

29341-1

9.2.9.5
[G UIDELINE ] A UPnP control point may terminate the TCP connection for a SOAP response
transmission that exceeds 30 s.

[ATTRIBUTES ]

O C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC QTXQ7

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.10 DDC UPnP device description rules

9.2.10.1
[G UIDELINE ] The total byte size of a device description file shall not exceed 20 480 B (20 KiB). This
byte limit includes the HTTP headers.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC DXIDH

29341-1

[C OMMENT] Provides a known maximum size for device description documents.

9.2.10.2
[G UIDELINE ] DLNA UPnP devices shall employ the <dlna:X_DLNADOC> XML element inside the
<device> element of the device description document to indicate adherence to a particular DLNA
Home Networked Device interoperability guidelines document version. The value of this element is
the DLNA Device Class or DLNA Device Capability, a dash character, followed by the numeric
version value of the interoperability guidelines document.

The <dlna:X_DLNADOC> element indicates DLNA compliance for a specific <device>, excluding its
embedded devices listed in <deviceList>.

The value of the <dlna:X_DLNADOC> element is a string as defined below. Linear white spaces
(LWS) are not implied in this definition below.

• dlnadoc-value = dlna-dev-class | [ dlna-dev-capability “/“ capability-host ] "-" dlna-version

• dlna-dev-class = "DMS" | "DMR" | "M-DMS" | other-dev-class
• other-dev-class = *<"A" - "Z", "a" - "z", "-">
• dlna-dev-capability = "+RUIHSNK+" | "+RUIHSRC+" | other-dev-capability
• other-dev-capability = *<"A" - "Z", "a" - "z", "+">
• capability-host = "DMS" | "DMR" | "M-DMS" | "DMP" | "M-DMP" | "DMC" | "M-DMC"
• dlna-version = major-version "." minor-version

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 90 –

• major-version = DIGIT
• minor-version = DIGIT DIGIT
The dlna-dev-class represents a Device Class of a DLNA device.

The dlna-dev-capability represents a (discoverable) Device Capability.

The capability-host represents a DLNA Device Class that hosts a DLNA Device Capability.

The dlna-version represents a version of interoperability guidelines (defined in the Introduction,

Version Number clause) supported by the DLNA Device Class.

An example of <dlna:X_DLNADOC> element is shown as follows:

<dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0">
DMS-4.0
</dlna:X_DLNADOC>

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC 8CA7M

29341-1

[C OMMENT] Provides an easy way of distinguishing UPnP devices that are claimed as being DLNA
Device Classes or DLNA Device Capabilities.
This guideline specifies the scoping rules for the <dlna:X_DLNADOC> element. Essentially, UPnP
devices (in a device hierarchy) are to be marked explicitly as being DLNA devices. Although the
subject matter is technically out of the scope of this guideline, the device hierarchy permits a non
DLNA UPnP device to be listed in a device hierarchy that has DLNA devices.

The <dlna:X_DLNADOC> element can appear multiple times such as is the case for a DMS and
M-DMS combination device.

The value of capability_host can be a discoverable DLNA Device Class as well as a

non-discoverable DLNA Device Class, since also non-discoverable DLNA Device Classes can host
a discoverable DLNA Device Capability.

9.2.10.3
[G UIDELINE ] The<dlna:X_DLNADOC> element may appear multiple times.

[ATTRIBUTES ]

O A DMS DMR M-DMS n/a ISO/IEC 9YPQX

29341-1

9.2.10.4
[G UIDELINE ] UPnP control points shall be matched against multiple <dlna:X_DLNADOC> elements.
Specifically, a control point that claims to discover a particular type DLNA device class or device
capability shall be able to discover that type of DLNA device class or device capability, even if the
specific <dlna:X_DLNADOC> element of interest is not the first <dlna:X_DLNADOC> in the device
description document.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 91 –

[ATTRIBUTES ]

M A DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC 8RDTJ

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.10.5
[G UIDELINE ] The namespace "urn:schemas-dlna-org:device-1-0" shall be specified in the <root>
element or the <dlna:X_DLNADOC> element and the namespace prefix shall be "dlna:".

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC RDTJ6

29341-1

9.2.10.6
[G UIDELINE ] UPnP control points shall ignore the element value of <dlna:X_DLNADOC>. For
example, DLNA control points shall not filter out a DLNA device because the version value is
different from what is expected.

[ATTRIBUTES ]

M A DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC YPQX5

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] In the near-term, the <dlna:X_DLNADOC> version number is useful for testing
purposes. Future guidelines will specify behavior for interoperability between newer and older
DLNA devices and the purpose of this field might change.

9.2.10.7
[G UIDELINE ] If a vendor builds an implementation of a Device Class (with zero or more Device
Capabilities or Device Options) or a discoverable Device Capability, then the implementation shall
comply with all mandatory portions of the interoperability guidelines for the specified dlna-version
token 9.2.10.2. If a vendor implements an older version of the interoperability guidelines, then the
vendor shall not implement guidelines defined in newer versions of interoperability guidelines with
the following exception:

• Devices that implement older versions of the interoperability guidelines may support Media
Format Profiles defined in newer versions.
[ATTRIBUTES ]

M C HND MHD n/a ISO/IEC CA7MF

29341-1

[C OMMENT] This guideline specifies that Vendors are not to selectively implement portions of
newer versions of DLNA's interoperability guidelines.
For example, if a vendor wants to build a DMS that supports RTP in the DLNA-defined manner, then
the vendor will implement the DMS according to the 1.50 (or newer) version of the interoperability
guidelines, which includes using a value of "1.50" for the dlna-version token. A DMS implementation

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 92 –

that uses a "1.00" value for the dlna-version but implements guidelines that are specific to newer
versions of interoperability guidelines is a violation of this guideline.

The primary reason for this guideline is to ensure that newer implementations participate in the
DLNA networking ecosystem in a manner that is consistent with the assumptions of those guidelines.
Newer versions of interoperability guidelines are drafted with compatibility for previous versions,
but newer versions sometimes have new mandatory requirements. The new mandatory guidelines
often ensure the robustness of the network, which is needed when interoperability guidelines
increase network complexity through new usages.

This guideline makes no claim on policy decisions about granting a DLNA logo/certification to
implementations that use older versions of interoperability guidelines. DLNA reserves the right to
require a baseline version of interoperability guidelines for future implementations.

9.2.11 DDC UPnP embedded device support

9.2.11.1
[G UIDELINE ] DLNA UPnP devices shall not have more than 6 total UPnP devices in the device
hierarchy with a maximum depth of 4. Root devices have a depth of 1.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC XIDHZ

29341-1

[C OMMENT] A UPnP control point will handle DLNA devices that include a combination or an
aggregate of devices and services. A specific limit sets a bound on memory and processing
requirements for control points.

9.2.11.2
[G UIDELINE ] UPnP control points shall support device hierarchies that have up to a total of 6 DLNA
devices with a maximum depth of 4. Root devices have a depth of 1.

[ATTRIBUTES ]

M L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC QI57Q

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.11.3
[G UIDELINE ] DLNA UPnP devices shall be functionally independent even if they are in the same
device hierarchy. In other words,

• a DLNA UPnP device is identified as a <device> with the <dlna:X_DLNADOC> element,

• a DLNA UPnP device has no functional dependency with other UPnP devices in the device
hierarchy,
• a DLNA UPnP device has no functional dependency with other DLNA UPnP devices in the
device hierarchy.
A DLNA UPnP device (Device-A) is functionally independent if it does not require a control point to
invoke a UPnP action of another UPnP device (Device-B) in order to put Device-A in a state for use
with a DLNA compliant UPnP control point. Also note that the definition assumes Device-A and
Device-B are in the same device hierarchy. Furthermore, Device-B might or might not be a DLNA
device, as indicated by the presence of the <dlna:X_DLNADOC> element.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 93 –

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC TXQ7Y

29341-1

[C OMMENT] These guidelines simplify control point implementations by not requiring them to know
about any functional dependencies between DLNA UPnP devices found in a device hierarchy.

Although the subject matter is technically out of scope, this guideline does not prohibit the use of a
UPnP device that has functional dependence on another UPnP device. However, a device that has
a functional dependence cannot be marked with a <dlna:X_DLNADOC> element.

9.2.11.4
[G UIDELINE ] DLNA control points shall not assume any functional dependency between embedded
devices that contain the <dlna:X_DLNADOC> element.

For example, a control point that requires UPnP actions to be called on one of the UPnP devices
before calling UPnP actions on another UPnP device (both UPnP devices belong to the same
hierarchy and have the <dlna:X_DLNADOC> element) is in violation with this requirement.

[ATTRIBUTES ]

M L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC Y7PTR

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.11.5
[G UIDELINE ] UPnP devices may be implemented as a descendent of a UPnP root device, which
might or might not be a standard UPnP device type.

[ATTRIBUTES ]

O C DMS DMR M-DMS n/a ISO/IEC VR8QA

29341-1

9.2.11.6
[G UIDELINE ] UPnP control points shall interoperate with embedded DLNA devices that exist in
device hierarchies where the root happens to be a non-standard UPnP device type (i.e.
vendor-defined UPnP device type).

[ATTRIBUTES ]

M L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC T6RCX

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.11.7
[G UIDELINE ] UPnP devices that are not DLNA-compliant may be listed in a device hierarchy.

These non-DLNA UPnP devices count against the maximum number of 6 total UPnP devices in the
device hierarchy, indicated in 9.2.11.1.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 94 –

[ATTRIBUTES ]

O L DMS DMR M-DMS n/a ISO/IEC WQPE7

29341-1

[C OMMENT] This guideline permits that a device hierarchy to have UPnP devices that do not have
the <dlna:X_DLNADOC> element.

9.2.12 DDC UPnP service description rules

9.2.12.1
[G UIDELINE ] Optional actions listed in the SCPD shall be supported and not return the
NOT_IMPLEMENTED UPnP error in response to an invocation. Optional actions that are not
implemented shall not be listed in the SCPD.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC YZ8ZI

29341-1

[C OMMENT] UPnP devices fully and accurately reflect capabilities required by the standardized
Device Control Protocol (DCP) and listed in the UPnP device's service control protocol document
(SCPD).

9.2.12.2
[G UIDELINE ] A UPnP state variable shall not be present unless it meets at least one of the following
characteristics.

• The UPnP state variable is actually used by the device, either as an evented state variable or as
an action parameter.
• The UPnP state variable is normatively defined by a UPnP service to neither be evented nor
used for an action parameter.
[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC LGQXH

29341-1

[C OMMENT] This guideline is in consideration of the fact that control points can run on a platform
with limited resources.

9.2.12.3
[G UIDELINE ] If an allowed value list or value range is specified, UPnP devices should accept all
values in the state variable range, regardless of the stepping (as indicated by a <step> element of
the UPnP state variable).

[ATTRIBUTES ]

S L DMS DMR M-DMS n/a ISO/IEC GQXHV

29341-1

[C OMMENT] Although it is preferable for control points to employ logic for correctly checking an
argument for compliance against a device's stepping, this is not always the case. For broader
interoperability, this guideline is suggested for UPnP devices, but it is not mandatory. Note that the

DLNA guidelines; Part 1-1: Architecture and protocols

 – 95 –

AVTransport, ContentDirectory, and ConnectionManager services do not have state variables that
use stepping by default.

9.2.12.4
[G UIDELINE ] Services with evented state variables shall support SUBSCRIBE and UNSUBSCRIBE
operations.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a ISO/IEC Z8ZIU

29341-1

[C OMMENT] Specifies normative behavior for services with evented state variables.

9.2.12.5
[G UIDELINE ] DCP-required or SCPD-specified state variables with the attribute SendEvent="Yes"
shall actually be evented.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a ISO/IEC QPE7G

29341-1

9.2.12.6
[G UIDELINE ] Service description files shall not exceed 51 200 B (50 KiB). This byte limit includes
the HTTP headers.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC 6RCXP

29341-1

[C OMMENT] This provides a reasonable maximum length for service description files.

9.2.13 DDC UPnP XML namespace

[G UIDELINE ] Default namespace defined by the UPnP DA shall be used in device and service
descriptions.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC R8QAV

29341-1

[C OMMENT] All standard elements in device and service descriptions do not use a namespace
prefix.

9.2.14 DDC UPnP action argument encoding

9.2.14.1
[G UIDELINE ] The number, names and ordering of arguments of SOAP actions in an SCPD shall be
identical to what is specified in the standardized DCP.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 96 –

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC 7PTRW

29341-1

9.2.14.2
[G UIDELINE ] A UPnP device shall parse and interpret a SOAP action request in which the number,
names and ordering of input arguments are identical to what is specified in the corresponding SCPD
(which is the same as specified in the standardized DCP).

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC RW8QR

29341-1

9.2.14.3
[G UIDELINE ] A UPnP device response to a SOAP action shall contain the number, name, and
ordering of output arguments that are identical to what is specified in the corresponding SCPD
(which is the same as specified in the standardized DCP).

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC 9TZAV

29341-1

9.2.15 DDC UPnP SOAP packet size

9.2.15.1
[G UIDELINE ] UPnP devices shall be able to accept SOAP requests that are up to 20 480 B (20 KiB)
in size. This byte limit includes the HTTP headers.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC XQ7YM

29341-1

[C OMMENT] This guideline provides control points with a minimal SOAP packet size (total size for
headers and body). It is understood that the support of larger SOAP requests is permitted.

9.2.15.2
[G UIDELINE ] UPnP control points shall be able to accept SOAP responses that are up to 204 800 B
(200 KiB) in size. This byte limit includes the HTTP headers.

[ATTRIBUTES ]

M L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC I57Q8

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] Security recommendations call out 200 KiB as a reasonable upper bound for SOAP
responses (total size for headers and body).

9.2.15.3
[G UIDELINE ] UPnP control points may refuse SOAP responses that are more than 204 800 B
(200 KiB) in size. This byte limit includes the HTTP headers.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 97 –

Control points may implement the not accept SOAP response behavior by terminating the TCP
connection after 200 KiB is reached.

[ATTRIBUTES ]

O L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC IDHZS

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.16 DDC UPnP error codes

9.2.16.1
[G UIDELINE ] Unless otherwise specified, UPnP endpoints (devices and control points) should use
and return the proper error code when encountering an error condition for a UPnP operation. This
includes using the proper HTTP error codes and method error codes for UPnP actions. In some
extreme circumstances, it might be necessary to simply close a UPnP initiated connection upon
encountering an error condition.

[ATTRIBUTES ]

S R HND +DN+ +PU+ MHD n/a ISO/IEC A7MFW

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This requirement covers the proper expected behavior for any UPnP endpoint and is
repeated here due to its importance in gracefully recovering from error conditions on a distributed
home network.

9.2.16.2
[G UIDELINE ] UPnP control points shall be able to tolerate unknown method error codes for UPnP
actions

[ATTRIBUTES ]

M A DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC PQX5U

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] Ideally, UPnP control points treat all unknown method error codes for UPnP actions as
a generic error condition.

9.2.16.3
[G UIDELINE ] HTTP clients for UPnP endpoints (devices and control points) are not required to
understand unknown HTTP status code values, but they shall understand the class of the status
code. The class of the status code is indicated by the first digit of the status code numeric value.
HTTP clients shall treat unrecognized status code values as equivalent to the x00 code of the class.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 98 –

[ATTRIBUTES ]

M C HND +DN+ +PU+ MHD n/a IETF RFC DTJ6V

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

9.2.16.4
[G UIDELINE ] UPnP devices should not use the UPnP error code value of 402 when a received
SOAP action request contains arguments with unknown argument names.

[ATTRIBUTES ]

S L DMS DMR M-DMS n/a ISO/IEC WC47X

29341-1

[C OMMENT] The proper way of handling a SOAP action request that contains arguments with
unknown argument names is to ignore those arguments (9.2.23) and process the request as if those
arguments have never existed.

The UPnP DA 1.0 requires devices to ignore unknown elements in all XML fragments, including
unknown arguments in SOAP requests. However, the UPnP DA 1.0 also allows the use of the UPnP
error code value of 402 (Invalid Args) to indicate that unknown arguments are found in SOAP
requests. This error in the specification has since been acknowledged and corrected in the draft
version of the UPnP DA v1.1. As a result of this ambiguity, certain existing devices issue the UPnP
error code value of 402 (Invalid Args) in the event of unknown arguments. This behavior is
discouraged, but it does enable backward compatibility.

9.2.17 DDC UPnP GENA packet size

9.2.17.1
[G UIDELINE ] UPnP control points shall be able to accept GENA event transmissions that are up to
20 480 B (20 KiB) in size. This byte limit includes the HTTP headers.

[ATTRIBUTES ]

M L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC TJ6VJ

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This guideline specifies the minimum capability of control points to receive events of
20 KiB in size (for headers and body). Control points are permitted to support larger GENA events.

9.2.17.2
[G UIDELINE ] UPnP control points may choose not to accept GENA event transmissions that are
more than 20 KiB in size.

Control points may implement the not accept GENA event behavior by terminating the TCP
connection after 20 KiB is reached.

[ATTRIBUTES ]

O L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC QX5U5

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+

DLNA guidelines; Part 1-1: Architecture and protocols

 – 99 –

+EPG+

9.2.18 DDC UPnP subscription handling

9.2.18.1
[G UIDELINE ] The SUBSCRIBE response shall include the Content-Length: 0 HTTP header/value
pair, if the response is not encoded with Chunked Transfer Coding.

The only exception to this rule is if the device can guarantee that a TCP FIN packet is sent before
the initial event message is sent to the subscribing control point.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC 7MFWJ

29341-1

[C OMMENT] In order for a control point to receive the initial event from a UPnP device, a control
point needs to know the Subscription ID (SID) value.
The SID is obtained in the response to a SUBSCRIBE request.
Therefore, a control point will receive the entire SUBSCRIBE response before it receives the first
event.
The HTTP clients of control points only have two ways to know when the SUBSCRIBE response has
finished. The first is to complete the transaction when the Content-Length:0 values are specified.
The second is to receive the TCP FIN flag in the TCP stream.

9.2.18.2
[G UIDELINE ] UPnP devices shall assign a globally unique SID, where the global context is defined
as the UPnP network. The format for the uuid is as specified in 9.2.19.

[ATTRIBUTES ]

M C DMS DMR + M-DMS n/a ISO/IEC DHZSM

29341-1

[C OMMENT] See 9.2.20 for a way to generate a globally unique SID.

9.2.19 DDC UPnP UUID format

[G UIDELINE ] The format of the SID is "uuid:" followed by a UUID, which is a 128-bit value
represented in hexadecimal form, with optional hyphens throughout the encoding. The maximum
length is 68 B, including the "uuid:" portion.

Example:
uuid:00000000-0000-0000-0000-000000000000

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC 57Q8X

29341-1

9.2.20 DDC UPnP UUID generation

[G UIDELINE ] UPnP devices should use the DCE 1.1 methodology for generating a globally unique
UUID value.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 100 –

[ATTRIBUTES ]

S R DMS DMR M-DMS n/a Universal Q7YMT

Unique
Identifier

[C OMMENT] There are several ways to generate a UUID value. The best way to generate a UUID
involves using some form of a network address and the current time, such as the algorithm
described in Universal Unique Identifier.

9.2.21 DDC UPnP event subscription renewals

9.2.21.1
[G ENERAL ] This guideline instructs developers that the control point is responsible for renewing
subscriptions in a timely manner.

9.2.21.2
[G UIDELINE ] If UPnP control points want to continue receiving UPnP events, then they shall renew
their subscriptions before the negotiated subscription TIMEOUT expires.

[ATTRIBUTES ]

M C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC PTRWR

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.22 DDC UPnP event notification handling

9.2.22.1
[G UIDELINE ] UPnP devices shall send events to all properly subscribed UPnP control points. The
device shall enforce a subscription TIMEOUT value of 5 min.

The UPnP device behavior of enforcing this 5 min TIMEOUT value is implemented by specifying
"TIMEOUT: second-300" as an HTTP header/value pair.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a ISO/IEC 8QAVJ

29341-1

[C OMMENT] A UPnP control point that subscribes to events and then subsequently leaves the
UPnP network will cause a UPnP device to possess an event subscription to an invalid address. The
device will not hold up events to other subscribing control points while, for example, the HTTP
session with the absent UPnP control point times out. This scenario has been a major cause of
UPnP control point disruption and usability problems. UPnP control points that stop receiving
events might incorrectly indicate to the user that a device is stalled or is malfunctioning.

9.2.22.2
[G UIDELINE ] UPnP devices should monitor their subscription lists and remove control points that
fail to renew their subscription within the negotiated time.

[ATTRIBUTES ]

S R DMS DMR M-DMS n/a ISO/IEC RCXPQ

29341-1

DLNA guidelines; Part 1-1: Architecture and protocols

 – 101 –

9.2.23 DDC UPnP unknown header/tag/field robustness rule

[G UIDELINE ] UPnP endpoints (devices and control points) shall be tolerant of unknown headers,
tags, fields, attributes, and values for HTTP, SSDP, XML, SOAP, and GENA. Specifically, this
tolerance guideline applies to

• HTTP headers, tokens, values,

• SSDP headers, tokens, values,
• unknown XML elements and attributes of SOAP or GENA fragments,
• unknown XML elements and attributes in device description files or service description files.
Tolerant behavior is defined as being able to successfully "parse and interpret" or "parse and
ignore" the unknown text.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC PE7GO

+UP+ +DNSYNC+ 1945
+UPSYNC+ +SR+ IETF RFC
+EPG+ 2616
ISO/IEC
29341-1

[C OMMENT] This guideline addresses forward compatibility and also ensures broader
interoperability between implementations that employ vendor extensions in the manner described
by the guideline.

9.2.24 DDC URI rules

9.2.24.1
[G UIDELINE ] All absolute URIs used for UPnP communications shall use IP addresses (not host
names).

UPnP communications specifically refers to the following areas.

• SOAP actions
• GENA events
• Device description files
• Service description (SCPD) files
• UPnP presentation files
• SSDP messages
[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a ISO/IEC 8ZIUM

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

[C OMMENT] These guidelines are mandatory because DLNA Device Classes cannot depend on
DNS infrastructure within a home network environment.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 102 –

9.2.24.2
[G UIDELINE ] The a.b.c.d format for IPv4 addresses shall be used for UPnP communications, using
IPv4, where each quad represents a byte in network byte order form.

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a ISO/IEC QXHV3

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

9.2.24.3
[G UIDELINE ] IPv6 addresses used for UPnP communications shall be formatted according to
guidance in ISO/IEC 29341-1-2 Annex A Clause A.4.

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD ISO/IEC Y27W4

+UP+ +DNSYNC+ 29341-1-2
+UPSYNC+ +SR+
+EPG+

9.2.24.4
[G UIDELINE ] HTTP URI escaping is always performed according to the URI specification IETF RFC
1738 as required in 3.2.1 of the HTTP/1.1 specification IETF RFC 2616.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC XHV3H

+UP+ +DNSYNC+ 1738
+UPSYNC+ +SR+ IETF RFC
+EPG+ 2616

[C OMMENT] This guideline specifies how to escape URI values.

9.2.24.5
[G UIDELINE ] All URIs used for UPnP communications shall not exceed 256 B in URI-escaped
UTF-8 encoded form. This guideline applies to both absolute URIs and complete URIs (relative
URIs combined with a base path).

UPnP communications does not cover informational URIs for the manufacturer or product/model
used inside UPnP Device Descriptions. It also does not cover indirectly referenced content, such as
URIs inside the presentation files.

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a ISO/IEC ZIUM5

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

[C OMMENT] These guidelines provide a maximum URI length for the UPnP layer. See guideline
10.1.3.10 subguideline 10.1.3.10.4 for the maximum URI length at the UPnP AV layer.

According to 2.10 of W3C XML, white spaces are significant (i.e. non-markup characters) in XML
elements that contain character data. Therefore XML elements that contain a single (absolute or
relative) URI value cannot have preceding or trailing white spaces.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 103 –

9.2.24.6
[G UIDELINE ] All URIs (not used for UPnP communications) shall not exceed 1 024 B, in the
URI-escaped UTF-8 encoded form. This guideline covers URIs, such as (but not limited to)

• URIs inside UPnP presentation files,

• URIs in the device description for product, model, or manufacturer information,
[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a ISO/IEC E7GO8

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

9.2.24.7
[G UIDELINE ] UPnP devices should not use the <URLBase> element in the device description
document.

[ATTRIBUTES ]

S L DMS DMR M-DMS n/a IETF RFC CXPQK

2396
ISO/IEC
29341-1

[C OMMENT] These requirements have several benefits. Since the device description and service
description documents will no longer include IP addresses and port numbers, UPnP devices are
simplified. The document can be sent even if the IP address changes or the device is multi homed.
UPnP control points will have an easier time dealing with UPnP devices that meet these
requirements, and will be able to handle any situation that arises.

The terms Base URI, Relative URI, and Absolute URI are used here in a manner consistent with
their definitions introduced in IETF RFC 2396.

9.2.24.8
[G UIDELINE ] If a URI in a device description is used for SOAP actions, GENA events, SCPD files,
or UPnP presentation files, then the URI may be a Relative URI as defined in IETF RFC 2396 with
its Base URI as defined in guideline 9.2.24.12.

[ATTRIBUTES ]

O R DMS DMR M-DMS n/a IETF RFC QAVJB

2396
ISO/IEC
29341-1

9.2.24.9
[G UIDELINE ] UPnP control points shall work with UPnP devices that use a <URLBase> element and
with those that do not use a <URLBase> element. Control points shall also work with UPnP devices
that use Absolute or Relative URIs.

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a IETF RFC TRWRA

+PU+ +UP+ 2396
+DNSYNC+ ISO/IEC
+UPSYNC+ +SR+ 29341-1

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 104 –

+EPG+

9.2.24.10
[G UIDELINE ] UPnP devices shall use the CALLBACK URI value sent by control points for event
delivery, provided that the CALLBACK URI value is consistent with guidelines 9.2.24.1 to 9.2.24.5.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a ISO/IEC 7YMTP

29341-1

9.2.24.11
[G UIDELINE ] UPnP control points shall not specify more than one CALLBACK URI value for the
CALLBACK header in a request with the SUBSCRIBE method.

[ATTRIBUTES ]

M L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC 7Q8XF

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] Simplifies a UPnP device's implementation for GENA eventing.

9.2.24.12
[G UIDELINE ] If the <URLBase> element is used, it shall define the Base URI to be used for
declaring Relative URIs. When this element is omitted, the LOCATION value (URL) in the device
advertisement shall define the Base URI.

[ATTRIBUTES ]

M R DMS DMR M-DMS IETF RFC XZ95C

2396
ISO/IEC
29341-1

9.2.24.13
[G UIDELINE ] Relative URI and a Base URI shall be resolved into an Absolute URI according to the
process defined in IETF RFC 3986.

Examples.

• The ssdp:alive message has LOCATION value of http://172.16.0.2/MyDir/devicedesc.xml

• The ssdp:alive message has LOCATION value of http://[fe80:1]:2869/MyDir/devicedesc.xml
• The device description file does not have the <URLBase> element.
• One of the services has these element values.
– <SCPDURL> has "/service_desc.xml"
– <controlURL> has "control"
– <eventSubURL> has "http://172.16.0.2:3000/sub"

DLNA guidelines; Part 1-1: Architecture and protocols

 – 105 –

• The Absolute URL for that service is as follows:

– SCPDURL: http://172.16.0.2/service_desc.xml
– controlURL: http://172.16.0.2/MyDir/control
– eventSubURL: http://172.16.0.2:3000/sub
[ATTRIBUTES ]

M R DMP +SR+ +EPG+ n/a IETF RFC W8QR3

3986
ISO/IEC
29341-1

[C OMMENT] In terms of syntax, reference IETF RFC 3986 defines an Absolute URI and a Relative
URI. A Relative URI is further classified as belonging to one of three types:

• Network path (net_path);

• Absolute path (abs_path);
• Relative path (rel_path).
These 3 types of Relative URIs can be resolved into Absolute URIs following the procedures
defined in IETF RFC 3986.

In the example introduced in guideline 9.2.24.13, the <SCPDURL> value is an example of a Relative
URI with an Absolute path. The <controlURL> value is an example of a Relative URI with a Relative
path. The <eventSubURL> value is an example of an Absolute URI.

9.2.25 DDC UPnP device description usage

9.2.25.1
[G UIDELINE ] If a DLNA UPnP device wants to change a device description or service description
files, then the UPnP device shall

• first leave the UPnP network by sending an ssdp:byebye message,

• then change the desired device description or service description files, and
• finally join the UPnP network with the new XML files using an ssdp:alive message.
[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC HZSMF

29341-1

[C OMMENT] UPnP control points often bind UDN values to device representations. Therefore, a
device that changes its logical representation causes problems if it uses the same UDN. This
guideline does not apply if the device sends an ssdp:byebye message. In such cases, the device
can still keep its UDN value and change its logical representation before rejoining the UPnP
network.

9.2.25.2
[G UIDELINE ] A DLNA UPnP control point that removes a UPnP device from its list of active devices
shall also invalidate its local representation of the device.

The control point removes a device for a variety of reasons, such as a CACHE-CONTROL timeout.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 106 –

Invalidating the local representation of the device means that the control point shall reload the
device description and service description files.

[ATTRIBUTES ]

M C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC MFWJU

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This guideline obligates a control point to refresh device description and service
description documents the next time the device is discovered. This, for example, allows a device to
add additional supported actions or services (via firmware update), without having to change the
UDN of the device.

9.2.26 DDC UPnP UDN usage

9.2.26.1
[G UIDELINE ] UPnP devices should not change the UDN between reboots or application
launch/shutdown.

[ATTRIBUTES ]

S A DMS DMR M-DMS n/a ISO/IEC X5U5G

29341-1

[C OMMENT] Implementing this guideline enables usages such as my favorite devices. Preferably,
UPnP device UDN values will be long-lived.
UPnP DA states as follows:

UDN: Shall be the same over time for a specific device instance (i.e., shall survive reboots).

9.2.26.2
[G UIDELINE ] UPnP devices shall not change the UDN if only the <friendlyName> or IP addresses
values are changed.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC J6VJQ

29341-1

[C OMMENT] UPnP control point can identify UPnP devices even if FriendlyName or IP addresses
are changed.

9.2.26.3
[G UIDELINE ] In conjunction with the restrictions in 9.2.26.2, UDN may be changed if a UPnP device
changes its device description or any of its supported services.

[ATTRIBUTES ]

O A DMS DMR M-DMS n/a ISO/IEC 6VJQP

29341-1

DLNA guidelines; Part 1-1: Architecture and protocols

 – 107 –

9.2.26.4
[G UIDELINE ] If a UPnP device UDN changes, it shall re-advertise on the network using the new
UDN.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC 5U5GU

29341-1

[C OMMENT] Control Points that receive the advertisement know that a new UPnP device is
available. This is required by guideline 9.2.15.2.

9.2.26.5
[G UIDELINE ] If a UPnP device UDN changes, it shall send an ssdp:byebye for the old UDN.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC FWJUQ

29341-1

[C OMMENT] Without this guideline, UPnP control points will have no idea that the old UDN is no
longer valid. This is required by guideline 9.2.15.2.

9.2.26.6
[G UIDELINE ] A UPnP device shall limit their UDN to a UTF-8 encoded string value containing
"uuid:" followed by a UUID as specified in 9.2.19.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC ZSMFB

29341-1

[C OMMENT] See 9.2.20 for a way to generate a globally unique 128-bit value for the UDN.

9.2.27 DDC UPnP multi homing rules

9.2.27.1
[G ENERAL ] Multiple home network segments, wireless networking, and Auto IP can combine to
create usability problems that can be avoided by following the specified rules.

9.2.27.2
[G UIDELINE ] When a UPnP device has multiple IP addresses, the device may advertise on those IP
addresses with the same or different UDN.

[ATTRIBUTES ]

O C DMS DMR M-DMS n/a ISO/IEC Q8XFC

29341-1

[C OMMENT] Multiple home network segments, wireless networking, and Auto IP can combine to
create usability problems that can be avoided by following the specified rules.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 108 –

9.2.27.3
[G UIDELINE ] The LOCATION URL value in a UPnP device advertisement shall contain the source
IP address of the advertisement.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC YMTPX

29341-1

9.2.27.4
[G UIDELINE ] Upon receiving multiple advertisements for the same UPnP device UDN, a UPnP
control point should select the vendor-defined preferred advertisement as the route to the device.

[ATTRIBUTES ]

S C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC RWRAB

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.27.5
[G UIDELINE ] When a UPnP control point gets an advertisement for a UPnP device UDN on a
different IP address from the one it has previously selected, it may continue to use its selected IP
address provided that it has received an advertisement on the selected IP address in the last 10 s.
Otherwise, if the UPnP control point does not receive an advertisement for its selected IP address
in the next 10 s, it may change its selection to the new IP address. Even if the control point keeps
the selected IP address in this case, it should change its selection to the new IP address when an
access to the selected IP address fails.

[ATTRIBUTES ]

O L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC AVJBK

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

[C OMMENT] The "selected IP address" is as specified in guideline 9.2.27.3 and 9.2.27.4.

9.2.28 DDC UPnP device icons

9.2.28.1
[G UIDELINE ] If a UPnP device provides a device icon, the UPnP device shall provide two JPEG
icons that conform to the 7.1.8 (GUN OFWYD) of IEC 62481-2 and 7.1.9 (GUN VVWJZ) of IEC
62481-2 Media Format Profiles and two PNG icons that conform to the 7.2.2 (GUN 6AXLT) of IEC
62481-2 and 7.2.3 (GUN SMM78) of IEC 62481-2 Media Format Profiles.

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC XPQKE

29341-1
IEC 62481-2

[C OMMENT] This requirement will ensure device icon compatibility and good authoring practices.
The reason for requiring PNG icons is that the lossless compression is much better for small size
images. Furthermore, alpha-blending makes it possible to present better user interfaces.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 109 –

9.2.28.2
[G UIDELINE ] UPnP devices may provide additional icons in other formats besides PNG and JPEG.

[ATTRIBUTES ]

O R DMS DMR M-DMS n/a ISO/IEC 7GO8Q

29341-1

9.2.28.3
[G UIDELINE ] UPnP devices shall use <mimetype>, <width>, <height>, <depth>, and <url>
sub-elements for an <icon> element within its device description.

The value of <mimetype>, <width>, and <height> elements for DLNA device icons shall conform to
the DLNA icon Media Format Profiles 7.1.8 (GUN OFWYD) of IEC 62481-2, 7.1.9 (GUN VVWJZ) of
IEC 62481-2, 7.2.2 (GUN 6AXLT) of IEC 62481-2 and 7.2.3 (GUN SMM78) of IEC 62481-2,
respectively.

Values in Table 8 are recommended for the <depth> element which indicates color bits per pixel for
PNG and JPEG device icons.

Table 8 – Color depth of device icons

Icon image data <depth>

Values

PNG Grayscale: 8 bits 8

Grayscale: 16 bits 16
Truecolor: 24 bits (triplet of 8 bits R/G/B samples) 24
Indexed – color bits 24 bits (palette entry is a triplet of 8 bits R/G/B 24
samples)
Grayscale w/ alpha: 8 bits (with matching alpha channel depth) 8
Grayscale w/ alpha: 16 bits (with matching alpha channel depth) 16
Truecolor w/ alpha: 24 bits (triplet of 8 bit R/G/B samples, alpha 24
channel shall be 8 bits)
JPEG (8 bits Y/Cr/Cb samples) 24

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a ISO/IEC IUM5G

29341-1
IEC 62481-2

[C OMMENT] UPnP defines the way to indicate profiles for icon images.

Since <depth> value is unclear for PNG grayscale/index colored /alpha blending and JPEG, this
guideline encourages use of the values for <depth> element required by the UPnP DA. Note that the
values for PNG do not help to identify color types.

9.2.29 DDC UPnP UTF-8 support

[G UIDELINE ] UPnP endpoints (devices and control points) shall use UTF-8 encoding of all XML
fragments. UPnP endpoints shall be tolerant of the UTF-8 maximum of 4 B of Unicode character as
required by XML processors.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 110 –

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a IETF RFC HV3HU

+UP+ +DNSYNC+ 2279
+UPSYNC+ +SR+ ISO/IEC
+EPG+ 29341-1
W3C XML

[C OMMENT] Specifying UTF-8 as the encoding method for UPnP communications provides the
right balance for supporting a wide variety of languages without necessarily requiring devices to
support all languages.

Although UTF-8 has characters that are encoded in 6 B, W3C XML spec states that XML processors
accept any character in Unicode. This means XML parsers will decode up to 4 B of character.
Specifically, see 2.2 of W3C XML for more information. It calls out any Unicode character, excluding
the surrogate blocks, FFFE, and FFFF.

9.2.30 DDC UPnP XML comments

9.2.30.1
[G ENERAL ] XML comments normally have to be skipped by XML parsers. This guideline ensures
that comments do not prevent interoperation.

9.2.30.2
[G UIDELINE ] UPnP endpoints (devices and control points) shall never source XML with comments.

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a ISO/IEC V3HUN

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

9.2.30.3
[G UIDELINE ] UPnP endpoints (devices and control points) may reject any XML provided with
comments.

[ATTRIBUTES ]

O C HND +DN+ +PU+ MHD n/a ISO/IEC UM5G6

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

9.2.31 DDC UPnP boolean types

[G UIDELINE ] UPnP endpoints (devices and control points) shall use "0" for false and "1" for true
when using the UPnP Boolean type.

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a ISO/IEC GO8Q5

+UP+ +DNSYNC+ 29341-1
+UPSYNC+ +SR+
+EPG+

[C OMMENT] This simplifies control point implementations and also reduces the size of some UPnP
traffic.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 111 –

9.2.32 DDC CP versioning

9.2.32.1
[G UIDELINE ] UPnP action requests (sent by a control point) shall include a DLNA-CP-version in a
USER-AGENT HTTP header value.

[ATTRIBUTES ]

M A DMP DMC +DN+ M-DMP M-DMC n/a IETF RFC PQKEA

+PU+ +UP+ 1945
+DNSYNC+ IETF RFC
+UPSYNC+ +SR+ 2616
+EPG+ ISO/IEC
29341-1

[C OMMENT] The HTTP specifications specify the format of the USER-AGENT HTTP header and
header value.

USER-AGENT HTTP header is not used exclusively for DLNA information.

9.2.32.2
[G UIDELINE ] The syntax of DLNA-CP-version is a subset of the product token syntax (defined by
HTTP) and is described below.

• DLNA-CP-version = "DLNADOC/" dlna-version

The dlna-version token is defined in guideline 9.2.10.2.

Examples:

• USER-AGENT: DLNADOC/4.0
• USER-AGENT: UPnP/1.0 DLNADOC/4.0
• USER-AGENT: CERN-LineMode/2.15 libwww/2.17b3 DLNADOC/4.0 UPnP/1.0
[ATTRIBUTES ]

M A DMP DMC +DN+ M-DMP M-DMC n/a IETF RFC VJBKF

+PU+ +UP+ 1945
+DNSYNC+ IETF RFC
+UPSYNC+ +SR+ 2616
+EPG+

[C OMMENT]

a) The DLNA-CP-version token uses the syntax of a product token (as defined in the HTTP
specifications) to identify the DLNA guidelines version.
b) Space and separators cannot be used in a token, and the USER-AGENT header field uses the
token syntax. For example, "My DLNA Device / 1234" does not comply with the token syntax
because spaces are used in the string that is supposed to follow the token syntax.
9.2.32.3
[G UIDELINE ] UPnP devices shall be tolerant of UPnP action requests that specify a newer
dlna-version in the DLNA-CP-version token.

Tolerance means that the UPnP device responds according to the version indicated by the device's
<dlna:X_DLNADOC> value.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 112 –

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC WRABY

29341-1

[C OMMENT] This guideline is another clarification of the 9.2.23 in that it requires tolerance of
unknown HTTP headers and values.

This guideline essentially requires a DLNA-compliant UPnP device to respond to newer control
points using the DLNA-defined rules employed by the UPnP device.

9.2.33 DDC absolute and relative URI requests

9.2.33.1
[G UIDELINE ] The HTTP server of UPnP endpoints (devices and control points) shall accept an
HTTP request that specifies an absolute or relative URI in the HTTP request.

[ATTRIBUTES ]

M R HND +DN+ +PU+ MHD n/a IETF RFC MTPX7

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

[C OMMENT] The HTTP specification indicates that this behavior is required.

Absolute URIs are permitted in HTTP requests.

9.2.33.2
[G UIDELINE ] The HTTP client of UPnP endpoints (devices and control points) should specify a
relative URI in the HTTP request.

[ATTRIBUTES ]

S R HND +DN+ +PU+ MHD n/a IETF RFC 8XFCS

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

9.2.34 DDC maximum HTTP header size

[G UIDELINE ] HTTP clients and servers of UPnP endpoints (devices and control points) shall
generate and parse HTTP messages that have a total HTTP header size that is equal to or less than
4 096 B (4 KiB) in all HTTP requests and responses.

The total HTTP header size is the total number of bytes from the first byte in the start-line token and
the last byte of the CRLF token, as used in the generic-message token defined in 4.1 of IETF RFC
2616: 1998, as quoted in the syntax below.

• generic-message = start-line *(message-header CRLF) CRLF [ message-body ]

[ATTRIBUTES ]

M L HND +DN+ +PU+ MHD n/a IETF RFC SMFBW

+UP+ +DNSYNC+ 2616
+UPSYNC+ +SR+
+EPG+

DLNA guidelines; Part 1-1: Architecture and protocols

 – 113 –

[C OMMENT] This provides a reasonable assumption as to how much memory is necessary for all
HTTP headers used in a single transaction related to UPnP communication.

9.2.35 DDC Device Capabilities

9.2.35.1
[G UIDELINE ] The <dlna:X_DLNACAP> is a comma-separated list of Capability ID values that
appears at most once for each <device> element in the device description document. The syntax of
the <dlna:X_DLNACAP> value, dlnacap-value, is defined as follows;

• dlnacap-value = capID *("," capID)

• capID= *<"a"-"z", "A"-"Z", "0"-"9", "_","-">
The capID token shall always be a value defined by the DLNA guidelines and the length of the token
shall not exceed 512 B.

The name space for the <dlna:X_DLNACAP> shall be "urn:schemas-dlna-org:device-1-0" and the
namespace prefix shall be "dlna:".

Example:

<dlna:X_DLNACAP
xmlns:dlna="urn:schemas-dlna-org:device-1-0">av-upload,image-upload,audio-upload</dlna:
X_DLNACAP>

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC WJUQC

29341-1

[C OMMENT] Other guidelines define the Capability ID values that are permitted in the
<dlna:X_DLNACAP> element. The discovery of DLNA RUI Device Capabilities uses element
<dlna:X_DLNADOC> defined in IEC 62481-6-1.

9.2.35.2
[G UIDELINE ] UPnP control points shall be tolerant of unknown Capability ID values.

Tolerant behavior is defined as being able to successfully "parse and interpret" or "parse and
ignore" the unknown text.

[ATTRIBUTES ]

M A DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC U5GUW

+PU+ +UP+ 29341-1
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.36 DDC DLNAQOS support

[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, all UPnP Device and Control Point traffic
shall be tagged with DLNAQOS_1, or a lower DLNAQOS_UP value (where "or a lower" is defined by
8.3.2.2.2 and 8.3.2.2.3), in accordance with Table 7.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 114 –

[ATTRIBUTES ]

M A HND +DN+ +PU+ MHD n/a n/a VJQP3

+UP+ +DNSYNC+
+UPSYNC+ +SR+
+EPG+

9.2.37 DDC Power Save Operations support

[G UIDELINE ] If a UPnP Device supports Power Save Operations then it shall comply with the
guidelines for an +LPE+ as indicated in IEC62481-10.

[ATTRIBUTES ]

M A DMR, DMS M-DMS n/a IEC 62481-10 DDG5V N

[C OMMENT] This guideline enables a UPnP AV MediaRenderer control point or UPnP AV

MediaServer control point to query Power Save Operations supported by a UPnP AV
MediaRenderer or a UPnP AV MediaServer device by implementing the Low Power Controller
(+LPC+) Device Capability and take appropriate steps to utilize available energy management
functionality on the device, if needed, when its services are required.

9.2.38 DDC Diagnostics support

[G UIDELINE ] A UPnP Device shall comply with the guidelines for an +DIAGE+ as indicated in
IEC62481-8.

[ATTRIBUTES ]

M A DMR, DMS M-DMS n/a IEC 62481-8 HC2DO N

[C OMMENT] This guideline enables a UPnP AV MediaRenderer control point or UPnP AV

MediaServer control point to query Diagnostics supported by a device by implementing the
Diagnostics Controller (+DIAGC+) Device Capability to collect diagnostics data through test actions
and queries.

10 Media management
10.1 AV media management
10.1.1 General
This subclause of the DLNA Home Networked Device interoperability guidelines covers the
guidelines for implementing media management using the UPnP AV architecture.

DLNA Home Networked Device interoperability guidelines version 1.0 had requirements for
metadata that is distributed on the home network. These guidelines are now updated with new
language for new Device Classes and Capabilities that implement the new system usages of DLNA
v1.5.

It is important to note that DIDL-Lite can be used in multiple contexts such as the following items.

• Some UPnP AV action request can carry DIDL-Lite metadata as input argument values (e.g.
CDS:CreateObject and AVT:SetAVTransportURI requests).
• Some UPnP AV action responses can carry DIDL-Lite metadata as output argument values (e.g.
CDS:CreateObject, AVT:GetMediaInfo, and AVT:GetPositionInfo request).
• Some UPnP AV events can carry DIDL-Lite metadata (e.g. AVT.LastChange and virtual instance
state variables such as AVT.CurrentTrackMetaData).

DLNA guidelines; Part 1-1: Architecture and protocols

 – 115 –

The general rules for handling XML documents and fragments are specified in 6.7.

AV media management guidelines is organized into multiple subclauses.

• 10.1.2 specifies the UPnP AV components that are needed for a DLNA Device Class or a DLNA
Device Capability. For example, this subclause provides the guideline that specifies that a DMP
shall implement a UPnP AV MediaServer control point.
• 10.1.3 specifies general UPnP AV requirements that are used by a variety of UPnP AV devices
and control points. Guidelines that dictate rules for items like DIDL-Lite metadata, protocolInfo
values, and DLNA-defined parameters for the 4th field of protocolInfo values are in this
subclause.
• 10.1.4 provides guidelines that are specific to UPnP AV MediaServer devices. Occasionally, a
related guideline that specifies behavior for a UPnP AV MediaServer control point will also
appear in this subclause.
• 10.1.6 provides guidelines that are specific to UPnP AV MediaRenderer devices. Occasionally,
a related guideline that specifies behavior for a UPnP AV MediaRenderer control point will also
appear in this subclause.
• 10.1.7 provides UPnP AV guidelines that are related to the Upload system usage. Guidelines
that specify behavior for CDS:CreateObject and CDS:DestroyObject transactions appear in this
subclause.
10.1.2 Device Classes and Device Capabilities requirements
10.1.2.1 MM UPnP AV compliance
10.1.2.1.1
[G ENERAL ] The following requirements define which version of the UPnP AV specifications are
required to implement one or more DLNA system usages by DLNA Device Classes and Device
Capabilities.

10.1.2.1.2
[G UIDELINE ] The DLNA Device Classes and Device Capabilities that implement one or more of the
MSCP, MSD, MRCP, and MRD Device Functions, as defined in 5.3, shall be compliant to the
appropriate version of UPnP AV specifications as defined in guidelines 10.1.2.1.3 through
10.1.2.1.7.

[ATTRIBUTES ]

M R DMS DMP DMR DMC M-DMS M-DMP n/a n/a JQP33

+DN+ +UP+ +PU+ M-DMC
+DNSYNC+
+UPSYNC+ +SR+
+EPG+

10.1.2.1.3
[G UIDELINE ] The DLNA Device Classes and Device Capabilities that implement one or more of the
MSCP, MSD, MRCP, and MRD Device Functions, as defined in 5.3, shall implement at a minimum
all of the mandatory portions for the appropriate ISO/IEC 29341-3-2 and ISO/IEC 29341-20-3
specifications to implement the Device Functions of the following system usages, as defined in 5.7,
unless overridden by 10.1.2.1.6.

• 2-box Pull,
• 2-box Push,
• 3-box,
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 116 –

• Download,
• Upload.
[ATTRIBUTES ]

M R DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC 8IAT3

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC 29341-3-2
ISO/IEC 29341-20-3
ISO/IEC 29341-3-13

[C OMMENT] ISO/IEC 29341-3-2 and ISO/IEC 29341-20-3 specifications are the baseline
architecture for the specified DLNA system usages.

10.1.2.1.4
[G UIDELINE ] The DLNA Device Classes and Device Capabilities that implement one or more of the
MSCP and MSD Device Functions, as defined in 5.3, shall implement at a minimum all of the
mandatory portions for the ISO/IEC 29341-4-3 specification to implement the Device Functions of
the following system usage, as defined in 5.7, unless overridden by 10.1.2.1.6.

• Scheduled Recording.
[ATTRIBUTES ]

M R DMS +SR+ M-DMS n/a ISO/IEC 29341-4-10 AT3QS

ISO/IEC 29341-4-11
ISO/IEC 29341-4-12
ISO/IEC 29341-4-3
ISO/IEC 29341-4-14
ISO/IEC 29341-4-4

[C OMMENT] ISO/IEC 29341-4-3 is the baseline architecture for the specified DLNA system usage.

10.1.2.1.5
[G UIDELINE ] The DLNA Device Classes and Device Capabilities that implement one or more of the
MSCP and MSD Device Functions, as defined in 5.3, shall implement at a minimum all of the
mandatory portions for the ISO/IEC 29341-14-3 specification to implement the Device Functions of
the following system usages, as defined in 5.7:

• Upload Synchronization;
• Download Synchronization;
• EPG.
[ATTRIBUTES ]

M R DMS +UPSYNC+ M-DMS n/a ISO/IEC 29341-4-10 N7DWU

+DNSYNC+ +EPG+ ISO/IEC 29341-4-11
ISO/IEC 29341-14-12
ISO/IEC 29341-14-3
ISO/IEC 29341-4-14
ISO/IEC 29341-4-4

[C OMMENT] ISO/IEC 29341-14-3 is the baseline architecture for the specified DLNA system usage.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 117 –

10.1.2.1.6
[G UIDELINE ] The DLNA Device Classes and Device Capabilities that implement the MSD Device
Function, as defined in 5.3, to participate in more than one of the system usages, as defined in 5.7,
shall implement at a minimum all of the mandatory portions for the highest UPnP AV version
baseline requirement as defined in guidelines 10.1.2.1.3 through 10.1.2.1.5.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 29341-14-10 4RS9F

ISO/IEC 29341-4-10
ISO/IEC 29341-14-11
ISO/IEC 29341-4-11
ISO/IEC 29341-20-12
ISO/IEC 29341-4-12
ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-4-3
ISO/IEC 29341-14-3
ISO/IEC 29341-4-14
ISO/IEC 29341-4-4
ISO/IEC 29341-3-2
ISO/IEC 29341-4-2
ISO/IEC 29341-3-13
ISO/IEC 29341-4-13

[C OMMENT] The baseline AV architecture for a UPnP AV MediaServer is the highest mandated
baseline for all of the system usages implemented on a UPnP AV MediaServer. For example, a DMS
that implements the 2-box Pull, 3-box and the Upload Synchronization system usages, will need to
implement to the ISO/IEC 29341-14-3 specification (i.e. cannot implement to a mixture of AV
specification versions on a UPnP AV MediaServer).

10.1.2.1.7
[G UIDELINE ] The DLNA Device Classes and Device Capabilities that implement one or more of the
MSCP, MSD, MRCP, and MRD Device Functions, as defined in 5.3 and 5.7, may implement the
mandatory portions of the UPnP AV specifications above its required baseline (i.e. higher version)
for any of the DLNA system usages.

[ATTRIBUTES ]

O R DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC 29341-14-10 JZ3X6
+DN+ +UP+ +PU+ M-DMC ISO/IEC 29341-4-10
+UPSYNC+ ISO/IEC 29341-14-11
+DNSYNC+ +SR+ ISO/IEC 29341-4-11
+EPG+ ISO/IEC 29341-20-12
ISO/IEC 29341-4-12
ISO/IEC 29341-14-12
ISO/IEC 29341-3-2
ISO/IEC 29341-4-2
ISO/IEC 29341-20-3
ISO/IEC 29341-4-3
ISO/IEC 29341-14-3
ISO/IEC 29341-3-13
ISO/IEC 29341-4-13
ISO/IEC 29341-4-14
ISO/IEC 29341-4-4

[C OMMENT] Any of the DLNA system usages can be implemented using a version of the UPnP AV
specification beyond its baseline. For example, devices implementing the 2-box Pull system usage
need to implement to ISO/IEC 29341-3-2 and ISO/IEC 29341-20-3 at a minimum. But they are

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 118 –

allowed to implement to the ISO/IEC 29341-4-2, ISO/IEC 29341-4-3 and ISO/IEC 29341-14-3, or
any future versions of the UPnP AV specifications.

10.1.2.2 MM DMP/M-DMP UPnP AV MediaServer control point definition

[G UIDELINE ] A DMP and M-DMP shall implement a UPnP AV MediaServer control point for
browsing a ContentDirectory service on a DMS and M-DMS respectively.

[ATTRIBUTES ]

M R DMP M-DMP n/a ISO/IEC 5GUWH

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline indicates that a DMP Device Class will use a UPnP control point that
controls a UPnP AV MediaServer for browsing content.

10.1.2.3 MM DMP implies DMR

[G UIDELINE ] Rendering Endpoints that claim to support the DLNA DMP Device Class shall also
support the DLNA DMR Device Class.

[ATTRIBUTES ]

M A DMP n/a n/a n/a HV5E4

10.1.2.4 MM Download Controller definition

10.1.2.4.1
[G UIDELINE ] A DLNA Device Class may implement the Download Controller Device Capability.

[ATTRIBUTES ]

O A DMS DMP DMR DMC M-DMS M-DMP n/a n/a 96QAD

M-DMC

10.1.2.4.2
[G UIDELINE ] A Download Controller shall implement a UPnP AV MediaServer control point for
browsing a ContentDirectory service on a DMS or M-DMS.

[ATTRIBUTES ]

M R +DN+ n/a n/a ISO/IEC JUQCY

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline indicates that a Download Controller Device Capability will use a UPnP
control point that controls a UPnP AV MediaServer for browsing content.

10.1.2.5 MM Upload Controller definition

10.1.2.5.1
[G UIDELINE ] An Upload Controller shall implement a UPnP AV MediaServer control point for
uploading content to a DMS and M-DMS respectively.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 119 –

[ATTRIBUTES ]

M R +UP+ n/a n/a n/a MFBWX

[C OMMENT] This guideline indicates that an Upload Controller Device Capability will use a UPnP
control point that controls a UPnP AV MediaServer for sending content to the MediaServer.
See 10.1.8.3.2 and 10.1.8.3.3 for the functionality that needs to be implemented.

10.1.2.5.2
[G UIDELINE ] An Upload Controller that only implements the upload AnyContainer operation may
implement the CDS:Browse action as mandated in ISO/IEC 29341-20-12. This guideline overrides
the CDS:Browse action mandate for a UPnP AV MediaServer control point in 10.1.2.1.3.

[ATTRIBUTES ]

O C +UP+ n/a n/a ISO/IEC 87Y4Q N

29341-20-12

[C OMMENT] An Upload Controller (+UP+) is not obligated to implement the CDS:Browse action
when only implementing the upload AnyContainer operation.

10.1.2.6 MM DMR UPnP AV MediaRenderer device definition

10.1.2.6.1
[G UIDELINE ] A DMR shall implement a UPnP AV MediaRenderer device that shall have one
AVTransport service, one RenderingControl service, and one ConnectionManager service.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC XFCS3

29341-3-2

[C OMMENT] DMR device will implement the baseline services for a UPnP AV MediaRenderer. This
is in conjunction with the requirements for Rendering Endpoints described in 11.

10.1.2.6.2
[G UIDELINE ] A UPnP AV MediaRenderer shall identify in the Device Description Document the
AVTransport service, the RenderingControl service, and the ConnectionManager service using
serviceType and serviceId elements with the values given in Table 9.

Table 9 – DMR serviceType and serviceID values

Service Element Value

serviceType urn:schemas-upnp-org:service:ConnectionManager:V a
ConnectionManager service
serviceID urn:upnp-org:serviceId:ConnectionManager
serviceType urn:schemas-upnp-org:service:AVTransport:V a
AVTransport service
serviceID urn:upnp-org:serviceId:AVTransport
serviceType urn:schemas-upnp-org:service:RenderingControl:V a
RenderingControl service
serviceID urn:upnp-org:serviceId:RenderingControl
a where V is the version number of the service.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 120 –

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC N3DAH

29341-1
ISO/IEC
29341-3-2

[C OMMENT] The serviceType and serviceId values uniquely identify the type of service. The table
above lists the element values in compliance with the related UPnP specifications.

10.1.2.7 MM DMR AVTransport rules

[G UIDELINE ] A DMR shall support the mandatory actions and state variables for a AVTransport
service.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC TPX7T

29341-14-10

[C OMMENT] This guideline specifies the minimum requirements for a DMR's AVTransport service.

10.1.2.8 MM DMR ConnectionManager rules

[G UIDELINE ] A DMR shall support the mandatory actions and state variables for a
ConnectionManager service.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC RABYC

29341-14-11

[C OMMENT] This guideline specifies the minimum requirements for a DMR's ConnectionManager
service.

10.1.2.9 MM DMR RenderingControl rules

[G UIDELINE ] A DMR shall support the mandatory actions and state variables for a
RenderingControl service.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC JBKFB

29341-3-13

[C OMMENT] This guideline specifies the minimum requirements for a DMR's RenderingControl
service.

10.1.2.10 MM DMC/M-DMC UPnP AV MediaServer and AV MediaRenderer control point

definition
[G UIDELINE ] A DMC and M-DMC shall implement a UPnP AV MediaServer control point and a
UPnP AV MediaRenderer control point. The MediaServer control point interacts with the
ContentDirectory service for browsing content. The MediaRenderer control point interacts with the
AVTransport service and the ConnectionManager service to verify that the MediaRenderer can play
the content and to start and stop the playback.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 121 –

[ATTRIBUTES ]

M R DMC M-DMC n/a ISO/IEC QKEAC

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-3-2
ISO/IEC
29341-20-3

[C OMMENT] This guideline indicates that the DMC and M-DMC Device Classes will use a UPnP
control point that controls a UPnP AV MediaServer and a UPnP AV MediaRenderer.

10.1.2.11 MM Push Controller definition

10.1.2.11.1
[G UIDELINE ] A DLNA Device Class may implement the Push Controller Device Capability.

[ATTRIBUTES ]

O A DMS DMP DMR DMC M-DMS M-DMP n/a n/a KK4QV

M-DMC

10.1.2.11.2
[G UIDELINE ] A Push Controller shall implement a UPnP AV MediaRenderer control point that
interacts with the AVTransport service and the ConnectionManager service to verify that the
MediaRenderer can play the content and to start and stop the playback.

[ATTRIBUTES ]

M R +PU+ n/a n/a ISO/IEC O8Q5K

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-3-2

[C OMMENT] A Push Controller is a capability that controls a DMR and serves the content directly to
the DMR. In addition to this guideline, a Push Controller needs to implement additional guidelines
related to MediaRenderer control points and Content Source endpoints.

10.1.2.12 MM DMS/M-DMS UPnP AV MediaServer device definition

10.1.2.12.1
[G UIDELINE ] A DMS and M-DMS shall implement a UPnP AV MediaServer device that shall have
one ContentDirectory service and one ConnectionManager service.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC M5G6Y

29341-20-3

[C OMMENT] DMS and M-DMS devices implement the minimum baseline services for a UPnP AV
MediaServer.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 122 –

10.1.2.12.2
[G UIDELINE ] A UPnP AV MediaServer shall identify in the Device Description Document the
ContentDirectory service and the ConnectionManager service using serviceType and serviceId
elements with the values given in Table 10.

Table 10 – DMS/M-DMS serviceType and serviceID values

Service Element Value

ContentDirectory serviceType urn:schemas-upnp-org:service:ContentDirectory:V a

service
serviceID urn:upnp-org:serviceId:ContentDirectory

ConnectionManager serviceType urn:schemas-upnp-org:service:ConnectionManager:V a

service
serviceID urn:upnp-org:serviceId:ConnectionManager

a where V is the version number of the service.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC MDNOR

29341-1
ISO/IEC
29341-20-3

[C OMMENT] These serviceType and serviceId values uniquely identify the type of service. Table 10
above lists the element values in compliance with the related UPnP specifications.

10.1.2.12.3
[G UIDELINE ] A DMS and M-DMS may have a ScheduledRecording service in the UPnP AV
MediaServer device.

[ATTRIBUTES ]

O R DMS M-DMS n/a ISO/IEC LPXZY

29341-20-3
ISO/IEC
29341-4-14

[C OMMENT] When a UPnP AV MediaServer Device contains a ScheduledRecording service it’s

indicating that it has implemented the DLNA ScheduledRecording Device Option as specified in
10.3.

10.1.2.12.4
[G UIDELINE ] If a DMS or an M-DMS contains a ScheduledRecording service then it shall implement
the DLNA ScheduledRecording Device Option as specified in 10.3.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC YR8Q6

29341-20-3
ISO/IEC
29341-4-14

10.1.2.13 MM DMS/M-DMS ContentDirectory rules

[G UIDELINE ] A DMS and M-DMS shall support the mandatory actions and state variables for a
ContentDirectory service.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 123 –

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC HUNQQ

29341-20-12

10.1.2.14 MM DMS/M-DMS ConnectionManager rules

[G UIDELINE ] A DMS and M-DMS shall support the mandatory actions and state variables for a
ConnectionManager service.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 5G6YN

29341-14-11

[C OMMENT] This guideline specifies the minimum requirements for a DMS's and M-DMS's
ConnectionManager service.

10.1.3 General UPnP AV requirements

10.1.3.1 MM UPnP AV control point tolerance of unknown property
[G UIDELINE ] UPnP AV control points shall be tolerant of all properties that appear in a DIDL-Lite
XML fragment. Properties are as defined in Annex B of ISO/IEC 29341-20-12.

Tolerant behavior is defined as being able to successfully "parse and interpret" or "parse and
ignore" the DIDL-Lite XML elements and attributes.

[ATTRIBUTES ]

M C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC PX7T9

+PU+ +UP+ 29341-20-12

[C OMMENT] This guideline ensures that a UPnP AV MediaServer control point will continue to
behave properly even if a UPnP AV MediaServer device improperly implements its support of the
Filter argument for CDS:Browse and CDS:Search.

10.1.3.2 MM DIDL-Lite restrictions

[G UIDELINE ] UPnP AV endpoints (devices and control points) shall never source the following in
DIDL-Lite documents or fragments:

• [CDATA] payloads
• <!...> XML comments
DIDL-Lite documents and fragments are always assumed to have a UTF-8 encoding. The XML for
DIDL-Lite documents and fragments shall never contain XML comments. UPnP AV endpoints may
reject any XML that is not encoded with these restrictions.

[ATTRIBUTES ]

M L DMS DMR DMC +PU+ M-DMS M-DMC n/a ISO/IEC FCS3V

+UP+ 29341-20-12

[C OMMENT] The flexibility of XML can cause problems for a number of XML parsers, especially
those on resource-limited platforms. These requirements balance the needs of control points with
the limitations of some devices.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 124 –

The assumption of using only UTF-8 encoded DIDL-Lite documents and fragments enables wide
language support without requiring control points to handle multiple encoding formats.

10.1.3.3 MM DIDL-Lite max metadata length

10.1.3.3.1
[G UIDELINE ] Unless specified in another DLNA guideline, element values and attribute values,
appearing in DIDL-Lite documents or fragments, that are length-unlimited shall not exceed 1 024 B
each, in their XML-escaped form, encoded in UTF-8.

Length-unlimited data types are the data types with an unspecified maximum length in string form.
These include string, URI, bin.hex, and base64 values.

[ATTRIBUTES ]

M L DMS DMR DMC +PU+ M-DMS M-DMC n/a ISO/IEC FBWX6

+UP+ 29341-20-12

[C OMMENT] This guideline puts a worst-case limit on all other metadata values found in a DIDL-Lite
document or fragment. This allows for smaller limits to be specified, but that at this time this is a true
maximum.

This guideline applies only to simple element values that are string, URI, bin.hex and base64 values.
It does not apply to element values of other data types. It also does not apply to complex elements
that contain sub-elements.

10.1.3.3.2
[G UIDELINE ] In DIDL-Lite documents or fragments, element and attribute values that are
length-limited shall not exceed their implied lengths.

Length-limited data types are the data types with an implied maximum length in string form. These
include signed/unsigned integers, floating point numbers, Boolean values, etc. Table 11 defines the
maximum byte length for these data types that are used by the CDS and UPnP device architecture.

Table 11 – CDS and UPnP maximum byte length

Data type in CDS Data type in UpnP device architecture Maximum byte
length

boolean boolean 5
unsigned integer ui4 10
integer i4 11
unsigned long n/a 20
long n/a 21
n/a ui1 3
n/a ui2 5
n/a i1 4
n/a i2 6
n/a int 11
n/a r4 14
n/a r8 22
n/a number 22
n/a fixed.14.4 20

DLNA guidelines; Part 1-1: Architecture and protocols

 – 125 –

Data type in CDS Data type in UpnP device architecture Maximum byte
length

n/a float
110 a
n/a char 1
n/a date 10
n/a dateTime 19
n/a dateTime.tz 29
n/a time 8
n/a time.tz 18
a Float shall be in the canonical representation.

[ATTRIBUTES ]

M L DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC UQCYR

+DN+ +PU+ +UP+ M-DMC 29341-20-12

[C OMMENT] A float value is m × 2^e, where m is an integer whose absolute value is less than 2^24,
and e is an integer between −149 and 104, inclusive.

Lexical representation is as follows:

float-value:= mantissa [("E" | "e") exponent] | "0" | "-0" | "INF" | "-INF" | "NaN"
mantissa:= [“+" | "-"] 1*DIGIT ["." 1*DIGIT]
exponent:= ["+" | "-"] 1*DIGIT
The canonical representation is defined; but in the non-canonical representation, the byte length
can be infinite. In the canonical representation, the maximum byte length is 110.
For example, −1E4, 1267.43233E12, 12.78e − 2, 12 and INF are all legal literals for float.
See: http://www.w3.org/TR/xmlschema-2/#float.

A boolean value can be either "0", "1", "true", or "false". The maximum length is set to 5 which is the
size for the value "false". Even though guideline 9.2.31 restricts using boolean values to "0" and "1"
for DLNA Device Classes, it needs to be tolerant that "true" or "false" might be encountered for non
DLNA devices. Hence the reason for setting the maximum length to 5.

10.1.3.3.3
[G UIDELINE ] The dc:title metadata property should not exceed 256 B in the XML-escaped form
encoded in UTF-8.

[ATTRIBUTES ]

S L DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC GUWHV

+DN+ +PU+ +UP+ M-DMC 29341-20-12

[C OMMENT] Although the maximum length for the dc:title is 1 024 B, many titles can fit in 256 B.
The primary reason why title values are allowed to exceed 256 B is to accommodate the guideline
10.1.4.19.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 126 –

10.1.3.3.4
[G UIDELINE ] The following metadata properties shall not exceed 256 B each in the XML-escaped
form encoded in UTF-8.

• upnp:class
• Any length-unlimited metadata property in Table 13. Recommended Metadata Properties.
• All length-unlimited DIDL-Lite schema defined attributes for <res>, except for the following:
o URI properties (The length for URI is governed by guideline 10.1.3.10.)
o res@protocolInfo property (The length is governed by 10.1.3.3.1) unless limited by
guideline 10.1.3.3.5
[ATTRIBUTES ]

M L DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC QP334

+DN+ +PU+ +UP+ M-DMC 29341-20-12

[C OMMENT] This guideline provides devices and control points that receive metadata with some
information about how much memory will be needed to represent a CDS object.
For example URIs include res@importUri, res@dlna:ifoFileURI, and res@dlna:importIfoFileURI.

10.1.3.3.5
[G UIDELINE ] The res@protocolInfo metadata property shall not exceed 256 B when interacting (i.e.
action request, action response, eventing state variables) with UPnP devices or UPnP control points
implemented to a version of the DLNA protocol before 1.51. A UPnP Device implemented to a
version of the DLNA protocol shall be as defined in 9.2.10.2. A UPnP control point implemented to
a version of the DLNA protocol shall be as defined in 9.2.32.2.

[ATTRIBUTES ]

M L DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC A3LXJ

+DN+ +PU+ +UP+ M-DMC 29341-20-12

[C OMMENT] To maintain backwards compatibility with older DLNA Certified devices the size for
res@protocolInfo is limited to 256 B. For example when a DMP browses a DMS for CDS objects, a
DMC issues a AVT:SetAVTransportURI action with metadata to a DMR, a DMR events track
metadata to a DMC. To limit the size of res@protocolInfo property value when sending to a device
with a DLNA protocol version before 1.51, parameters such as other-param, ps-param,
maxsp-param, and ci-param can be omitted or modified from the 4th field of res@protocolInfo until
the size of the res@protocolInfo metadata property is 256 B or less.

10.1.3.4 MM DIDL-Lite non-empty metadata values

10.1.3.4.1
[G ENERAL ] UPnP AV endpoints that provide DIDL-Lite metadata with empty values or values
composed entirely of white-spaces can cause problems for other endpoints that receive them. More
importantly, a user has little idea on how to interpret such values.

10.1.3.4.2
[G UIDELINE ] UPnP AV endpoints (devices and control points) shall use non-empty and
non-whitespace values for metadata properties in a DIDL-Lite XML fragment. The term, metadata
properties, refers specifically to elements and attributes defined by the DIDL-Lite schema and
applies only to guideline entries of 10.1.3.3.5.

Exceptions are explicitly allowed in other guidelines, such as 10.1.8.19 and 10.1.8.23.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 127 –

[ATTRIBUTES ]

M L DMS DMR DMC +UP+ M-DMS M-DMC n/a ISO/IEC P334S

29341-20-12

10.1.3.4.3
[G UIDELINE ] UPnP AV endpoints (devices and control points) shall be tolerant of DIDL-Lite
attributes and elements (whether defined by DIDL-Lite schema or not) that have empty values.

[ATTRIBUTES ]

M C DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC QCYRU

+DN+ +PU+ +UP+ M-DMC 29341-20-12

10.1.3.5 MM DIDL-Lite Boolean values

10.1.3.5.1
[G UIDELINE ] DIDL-Lite Boolean values shall use "0" for false and "1" for true.

[ATTRIBUTES ]

M L DMS DMR DMC +PU+ M-DMS M-DMC n/a ISO/IEC BWX6P

+UP+ 29341-20-12

[C OMMENT] This simplifies control point implementations and also reduces the size of some UPnP
traffic.

10.1.3.5.2
[G UIDELINE ] UPnP AV endpoints (devices and control points) may parse and interpret DIDL-Lite
Boolean values of "yes" and "true" as true ("1"), and "no" and "false" as false ("0"). Such values are
interpreted in a case-sensitive manner.

[ATTRIBUTES ]

O A DMS DMR DMC +PU+ M-DMS M-DMC n/a ISO/IEC YYZDP

+UP+ 29341-20-12

10.1.3.6 MM upnp:class values

10.1.3.6.1
[G UIDELINE ] UPnP AV MediaServer control point shall minimally treat derived classes in the same
way as its ancestor class(es).

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC CS3V5

+UP+ 29341-20-12

[C OMMENT] As an example, a UPnP AV MediaServer control point needs to be able to recognize a

CDS object marked as an object.item.audioItem.vendorXYZ as an object.item.audioItem even
though the UPnP AV MediaServer control point implementation does not understand the meaning
behind the vendorXYZ extension. It is not the intent of DLNA to require UPnP AV MediaServer
control points to show all CDS objects to a user because some UPnP AV MediaServer control points
can be interested in certain types of content classes.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 128 –

10.1.3.6.2
[G UIDELINE ] A UPnP AV MediaServer control point shall be tolerant ("parse and interpret" or
"parse and ignore") of unknown upnp:class values.

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC X7T96

+UP+ 29341-20-12

[C OMMENT] Tolerance of unknown values is required, regardless of whether the control point
intends to show the CDS objects to a user.

10.1.3.7 MM DIDL-Lite dc:date format

[G UIDELINE ] The syntax for the DIDL-Lite <dc:date> element value shall conform to the following
subset profile of ISO 8601.

• date-value = date [%x54 time [ time-offset]]

• date = 4 DIGIT "-" 2 DIGIT "-" 2 DIGIT; CCYY-MM-DD
• time = 2 DIGIT ":" 2 DIGIT ":" 2 DIGIT ["." 3 DIGIT"]; hh:mm:ss(.sss)
• time-offset = %x5a | ("+" | "-") 2 DIGIT ":" 2 DIGIT; Z or +hh:mm or -hh:mm
Essentially, the following combinations are permitted

• CCYY-MM-DD
• CCYY-MM-DDThh:mm:ss
• CCYY-MM-DDThh:mm:ssZ
• CCYY-MM-DDThh:mm:ss+hh:mm
• CCYY-MM-DDThh:mm:ss-hh:mm
• CCYY-MM-DDThh:mm:ss.sss
• CCYY-MM-DDThh:mm:ss.sssZ
• CCYY-MM-DDThh:mm:ss.sss+hh:mm
• CCYY-MM-DDThh:mm:ss.sss-hh:mm
When the offset of local time to UTC cannot be determined, the <dc:date> string shall have no
characters for the <time-offset> part of the date grammar.

[ATTRIBUTES ]

M R DMS DMR DMC +UP+ M-DMS M-DMC ISO 8601 BYCT4

IETF RFC
2234

10.1.3.8 MM DIDL-Lite res@duration format

[G UIDELINE ] The syntax of the res@duration shall be compliant to the following definition.

• duration = hours ":" minutes ":" seconds

• hours = 1*5 DIGIT; 0 to 99999
• minutes = 2 DIGIT; 00 to 59
• seconds = 2 DIGIT ["." 3 DIGIT]; 00 to 59 (.000 to .999)

DLNA guidelines; Part 1-1: Architecture and protocols

 – 129 –

[ATTRIBUTES ]

M R DMC DMS DMR +UP+ M-DMS M-DMC n/a IETF RFC KFB4S
+PU+ 2234

10.1.3.9 MM DIDL-Lite desc element use

10.1.3.9.1
[G UIDELINE ] The text in the <desc> element , when included in a DIDL-Lite document, shall contain
XML-based metadata. This includes the requirement that both the id and nameSpace attributes be
included in the <desc> element. The nameSpace attribute shall identify the namespace of the
contained XML-based metadata within the <desc> element.

[ATTRIBUTES ]

M R DMS DMR DMC +PU+ M-DMS M-DMC n/a ISO/IEC EACYX

+UP+ 29341-20-12

10.1.3.9.2
[G UIDELINE ] The XML-based metadata contained within a <desc> element shall have its XML
namespace defined within the containing DIDL-Lite document and its value shall be the same as
that of the nameSpace attribute.

Shown below are some examples of proper <desc> usage.

EXAMPLE 1:
<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/">
<container id="0000000000000016" searchable="1"
parentID="000000000000000A" restricted="0" childCount="1">
<dc:title>some title</dc:title>
<upnp:class>
object.item
</upnp:class>
<desc id="someid" nameSpace="http://some.example.org/foobar/"
xmlns="http://some.example.org/foobar/">
<yada>
some desc data
</yada>
</desc>
</container>
</DIDL-Lite>

EXAMPLE 2:
<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
xmlns:ve="http://some.example.org/foobar/">
<container id="0000000000000016" searchable="1"
parentID="000000000000000A" restricted="0" childCount="1">
<dc:title>
some title
</dc:title>
<upnp:class>object.item</upnp:class>
<desc id="someid" nameSpace="http://some.example.org/foobar/">
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 130 –

<ve:yada>
some desc data
</ve:yada>
</desc>
</container>
</DIDL-Lite>

[ATTRIBUTES ]

M C DMS DMR DMC +PU+ M-DMS M-DMC n/a ISO/IEC 9O4R8

+UP+ 29341-20-12
W3C XML

10.1.3.10 MM URI rules

10.1.3.10.1
[G UIDELINE ] When a Server Endpoint provides a reference to a content binary it serves that
conforms to a DLNA Media Format Profile, the Server Endpoint shall provide absolute URIs, with
IPv4 or IPv6 literal addresses formatted according to IETF RFC 3986 and IETF RFC 5952.

[ATTRIBUTES ]

M L DMS +PU+ +UP+ M-DMS n/a ISO/IEC Q5KY2 C

29341-20-3
IETF RFC
3986
IETF RFC
5952

[C OMMENT] This guideline mandates that content URIs will use absolute URIs that use IPv4 or
IPv6 addresseswhen the content is located within the home network.

Content Binaries that are located on a device with an IP address outside the LAN can use a domain
name in the URI, however legacy DMPs and DMRs with a version less than 1.6 might not support the
GENURL requirements so might not be able to resolve domain names.

10.1.3.10.2
[G UIDELINE ] URIs shall be properly URI-escaped in a UTF-8 encoded form.

[ATTRIBUTES ]

M L DMS DMC +PU+ +UP+ M-DMS M-DMC n/a IETF RFC G6YNK
1738
ISO/IEC
29341-20-12

[C OMMENT] This guideline requires UPnP AV endpoints to provide URI values that are
URI-escaped in a UTF-8 encoded form. This guideline also allows a UPnP AV MediaServer control
point to assume that URIs obtained from a UPnP AV MediaServer do not need any escaping.

10.1.3.10.3
[G UIDELINE ] HTTP URI escaping shall be performed according to the URI specification IETF RFC
1738 as required in 3.2.1 of the HTTP/1.1 specification IETF RFC 2616.

[ATTRIBUTES ]

M L DMS DMC +PU+ +UP+ M-DMS M-DMC n/a IETF RFC UNQQR
1738

DLNA guidelines; Part 1-1: Architecture and protocols

 – 131 –

IETF RFC
2616

10.1.3.10.4
[G UIDELINE ] URI values that appear in DIDL-Lite documents or fragments shall not exceed 1 024 B,
in the URI-escaped UTF-8 encoded form.

URI values shall not have preceding or trailing white space characters.

[ATTRIBUTES ]

M L DMS DMC +PU+ +UP+ M-DMS M-DMC n/a IETF RFC NQQRV
1738
ISO/IEC
29341-20-12
W3C XML

[C OMMENT] URI values are theoretically infinite in length. This guideline puts a reasonable limit on
the length of advertised content URI values.

10.1.3.10.5
[G UIDELINE ] If a content binary does not conform to a DLNA Media Format Profile, then the URI
value may be a URI, with a domain name.

[ATTRIBUTES ]

O L DMS DMC +PU+ +UP+ M-DMS M-DMC n/a ISO/IEC 6YNKQ

29341-20-3

[C OMMENT] This guideline permits the use of content URIs that use domain names when content is
not marked as conformant to a DLNA Media Format Profile. Content sourced from the Internet is
considered out of range for DLNA. However, a ContentDirectory service still has a way of
advertising Internet content in a DLNA manner using IP addresses. Rendering Endpoints that wish
to support these types of URIs will need a DNS client. Inclusion of DNS clients is out-of-scope for
DLNA. This means that vendors are not prohibited from including a DNS client, but DLNA guidelines
will not specify how to use DNS clients nor will the certification process test such behaviors.

10.1.3.10.6
[G UIDELINE ] All IP addresses appearing in a <res> element shall have the same address family.

[ATTRIBUTES ]

M L DMS +PU+ DMC M-DMS M-DMC n/a n/a KGK7T N

[C OMMENT] For example if the <res> value is an IPv4 address, then the ifoFile value should be an
IPv4 address as well. This guideline ensures address family consistency within a <res> element.

10.1.3.11 Generic HTTP URLs (GENURL) Device Function

10.1.3.11.1 Uniform Resource Identifiers (URI) support
[G UIDELINE ] DLNA Device Classes and Device Capabilities shall be capable of using the HTTP
GET and HEAD methods to request a resource or its header respectively identified by the following
types of URIs:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 132 –

• URI values that comply with guideline 10.1.3.10 (MM URI Rules), and
• Generic HTTP URL values defined in section 3.2.2 of IETF RFC 3986
[ATTRIBUTES ]

M A DMR DMP M-DMP n/a IETF RFC 9GXZQ

3986

[C OMMENT] This guideline indicates that a DMR is designed to work with URIs constrained to
numeric IP addresses (as defined in guideline 10.1.3.10), but also with any type of URI that
complies with HTTP URL specifications defined in IETF RFC 3986. Generic HTTP URLs can be
located anywhere in the local network or outside the local network.

10.1.3.11.2 Domain Name System (DNS) resolution

[G UIDELINE ] DLNA Device Classes and Device Capabilities shall implement a DNS resolver and a
mechanism to use the DNS resolver to convert host names to IP addresses (as defined in Section
6.1 in IETF RFC 1123 and as updated in IETF RFC 2181, IETF RFC 4343, IETF RFC 5452 and
IETF RFC 5966).

[ATTRIBUTES ]

M A DMR DMP M-DMP n/a IETF RFC IIBXF

1123
IETF RFC
2181
IETF RFC
4343
IETF RFC
5452
IETF RFC
5966

[C OMMENT]

a) All Device Classes and Device Capabilities that implements the GENURL Device Function,
implement a DNS resolver and a mechanism to use this resolver to convert host names to IP
addresses. A DNS resolver communicates with a DNS server as explained in IETF RFC 1123.
b) The class of Digital Media Renderers does not need to implement DNS resolver functionality
(see for example the notes for guidelines 8.4.2.1 and 9.2.24.1). Consequently, DLNA-compliant
Control Points always send HTTP URLs that include numeric IPv4 address to DMR devices not
implementing the GENURL Device Function. A UPnP Control Point that interacts with an DMR
can send non-numeric URLs because a DMR implementing the GENURL Device Function is
designed to resolve the URLs into numeric addresses using DNS.
10.1.3.11.3 DNS Server IPv4 address
[G UIDELINE ] The DHCPv4 client for DLNA Device Classes and Device Capabilities shall support
DHCPv4 Option 6 IETF RFC 2131 and obtain DNS server IPv4 address(es) from a home network
DHCPv4 server if present.

[ATTRIBUTES ]

M A DMR DMP M-DMP n/a IETF RFC URK4D

2131

[C OMMENT] This guideline indicates the protocol that a DMR uses to obtain the IPv4 address (or
addresses) for a DNS server.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 133 –

10.1.3.11.4 Tolerance to unavailable transferMode.dlna.org

[G UIDELINE ] If a Rendering Endpoint sends an HTTP HEAD or GET request using generic HTTP
URLs, and the response omits the transferMode.dlna.org HTTP header, then the Rendering
Endpoint shall accept the response with the default transfer modes.

As described in guideline 11.4.3.32.2), the default transfer modes are ‘streaming’ for the audio and
AV Media Classes, and ‘interactive’ for all other content binaries.

[ATTRIBUTES ]

M L DMR DMP M-DMP n/a IETF RFC MMIKL

3986

[C OMMENT] The DLNA guidelines indicate that client endpoints need to tolerate the absence of the
transferMode.dlna.org header for DMS v1.0 servers. This guideline says that DMRs need to tolerate
this omission for any type of server. Some of the HTTP URLs could point to servers located in the
Internet, which are not capable of including this header in response messages.

10.1.3.11.5 QoS level for a response that omits transferMode.dlna.org

[G UIDELINE ] If a Rendering Endpoint sends an HTTP HEAD or GET request using generic HTTP
URLs, and the response omits the transferMode.dlna.org HTTP header, then the Rendering
Endpoint shall accept the response using a best effort QoS level.

[ATTRIBUTES ]

M L DMR DMP M-DMP n/a IETF RFC H4WRY

3986

[C OMMENT] The DLNA guidelines indicate that client endpoints need to tolerate the absence of the
transferMode.dlna.org header for DMS v1.0 servers and use the best effort QoS level. This
guideline indicates that DMRs need to use the same approach for all servers that omit the
transferMode.dlna.org header in the response.

10.1.3.11.6 Tolerance to unavailable contentFeatures.dlna.org header

[G UIDELINE ] If a Rendering Endpoint sends an HTTP HEAD or GET request using generic HTTP
URLs including a valid getContentFeatures.dlna.org HTTP header, and if the response omits the
contentFeatures.dlna.org HTTP header, then the Rendering Endpoint shall accept the response as
if it included the header.

[ATTRIBUTES ]

M L DMR DMP M-DMP n/a IETF RFC XWJCH

3986

[C OMMENT]

a) Some legacy devices have been designed to retrieve res@protocolInfo information using the
contentFeatures.dlna.org header instead of using the available resource metadata. Generic
HTTP URLs could point to servers located in the Internet, which are not capable of including this
header in a response message.
b) The contentFeatures.dlna.org HTTP header carries the same information as the
res@protocolInfo property, which is always available for a Rendering Endpoint.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 134 –

10.1.3.12 MM DIDL-Lite recommended metadata properties

10.1.3.12.1
[G UIDELINE ] Content that conforms to the DLNA "Image" Media Class shall use
object.item.imageItem or a derived class for the upnp:class value.

Content that conforms to the DLNA "Audio" Media Class shall use object.item.audioItem or a
derived class for the upnp:class value.

Content that conforms to the DLNA "AV" Media Class shall use object.item.videoItem or a derived
class for the upnp:class value.

[ATTRIBUTES ]

M A DMS +UP+ M-DMS n/a ISO/IEC 5KY2U

29341-20-12
IEC 62481-2

10.1.3.12.2
[G UIDELINE ] Metadata properties defined in Annex B of ISO/IEC 29341-20-12 (ContentDirectory
Service specification) shall use the following namespace prefixes, see Table 12.

Table 12 – Namespace prefixes

Namespace Prefix

DIDL-Lite n/a
Dublin Core dc:
UPnP upnp:

[ATTRIBUTES ]

M L DMS +UP+ M-DMS n/a ISO/IEC ACYXD

29341-20-12

[C OMMENT] "n/a" means that the prefix is not used.

10.1.3.12.3
[G UIDELINE ] A UPnP AV MediaServer device should provide non-empty and non-whitespace
values for metadata properties as shown in Table 13 for the purpose of content selection.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 135 –

Table 13 – Recommended metadata properties

upnp:class value Property names

object.item.audioItem dc:creator, upnp:album, upnp:genre,

res@duration, res@size

object.item.imageItem dc:date, res@size

object.item.videoItem dc:date, upnp:genre, res@duration, res@size

object.container.album.musicAlbum dc:creator, upnp:genre, @childCount

object.item.videoItem.videoBroadcast upnp:genre, upnp:channelName,

object.item.audioItem.audioBroadcast upnp:channelNr (Applicability of
upnp:channelNr depends on region)

This guideline also applies to classes derived from those listed in Table 13.

As a note, the dc:creator property is understood to contain a value representing the artist name or
some equivalent content creator. Whenever possible, the original artist name or content creator
should be used for dc:creator. In some cases, such as an audio playlist, a user is the original content
creator of the media collection. While it might be appropriate to specify the user's name as the
dc:creator for a playlist, it is not recommended to specify the user's name as the dc:creator value for
individual audio items in the playlist.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC FB4S5

29341-20-12

[C OMMENT] This guideline recommends that some additional metadata properties be used for
different Media Classes. Although not required, providing the user with an information-rich user
experience is desirable.

When an Upload Controller creates an object on the MediaServer it will preferably provide these
values as part of the DIDL-Lite in the CDS:CreateObject request, see guidelines 10.1.8.23.4 and
10.1.8.24.2 for this requirement.

10.1.3.12.4
[G UIDELINE ] A UPnP AV MediaServer device shall provide non-empty and non-whitespace values
for metadata properties as shown in Table 14 that represent the maximum combined value for that
parameter for the item for the purpose of content selection.

Table 14 – Required res@ metadata properties

upnp:class value Property names

object.item.audioItem res@bitRate, res@sampleFrequency,

res@nrAudioChannels
object.item.imageItem res@colorDepth, res@resolution
object.item.videoItem res@bitRate, res@frameRate, res@resolution

This guideline also applies to classes derived from those listed in Table 14.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 136 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC F4CM8 N

29341-20-12

[C OMMENT] This metadata is supplied for the overall content item.

10.1.3.12.5
[G UIDELINE ] A UPnP AV MediaServer device shall, in response to a CDS
"upnp:resExt::componentInfo#" value (case sensitive) included as part of the Filter argument (in a
CDS:Browse or CDS:Search request), provide a upnp:resExt::componentInfo metadata property as
shown in Table 15 for the purpose of content selection for Media Format Profiles containing two or
more audio streams, video streams or audio plus video streams. If the
"upnp:resExt::componentInfo#" value is not included in the CDS:Browse or CDS:Search then the
upnp:resExt::componentInfo metadata shall not be returned.

Table 15 – Conditionally Required ResExt metadata properties

upnp:class value Property names

object.item.audioItem upnp:resExt::componentInfo
object.item.videoItem upnp:resExt::componentInfo

This guideline also applies to classes derived from those listed in Table 15.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC GBOX3 N

29341-20-12

[C OMMENT] This guideline restricts the return of the upnp:resExt::componentInfo metadata to

CDS:Browse and CDS:Search request that specifically ask for it in order to reduce the size of the
typical response for control points that cannot use the metadata.It also restricts the use of
upnp:resExt::componentInfo metadata to content items that have metadata associated with
alternative streams that are not easily derived from the top-level content item metadata of Media
Format Profile.

10.1.3.12.6
[G UIDELINE ] A UPnP AV MediaServer device shall, in response to a CDS
"upnp:resExt::componentInfo#" value (case sensitive) included as part of the Filter argument (in a
CDS:Browse or CDS:Search request), provide non-empty and non-whitespace values for metadata
properties as shown in Table 16.

Table 16 – Conditionally Required ResExt metadata properties

All stream types Property names

For each audio or upnp:resExt::componentInfo::componentGroup
video stream in the upnp:resExt::componentInfo::componentGroup@groupID
object.item.audioIte upnp:resExt::componentInfo::componentGroup@required
m or upnp:resExt::componentInfo::componentGroup::component
object.item.videoItem upnp:resExt::componentInfo::componentGroup::component@componentID
upnp:resExt::componentInfo::componentGroup::component::componentClass
upnp:resExt::componentInfo::componentGroup::component::contentType
upnp:resExt::componentInfo::componentGroup::component::contentType@MIMEType
upnp:resExt::componentInfo::componentGroup::component::contentType@extendedType

specific stream Property names

types (resExt::compontntInfo::ComponentGroup::component::ComponentClass value)

DLNA guidelines; Part 1-1: Architecture and protocols

 – 137 –

• "Audio" • upnp:resExt::componentInfo::componentGroup::component::contentType@bitrate
• upnp:resExt::componentInfo::componentGroup::component::contentType@sampleFrequency
• upnp:resExt::componentInfo::componentGroup::component::contentType@nrAudioChannels
• "Video" • upnp:resExt::componentInfo::componentGroup::component:: contentType@bitrate
• upnp:resExt::componentInfo::componentGroup::component::contentType@resolution
• upnp:resExt::componentInfo::componentGroup::component:: contentType@framerate

This guideline also applies to classes derived from those listed in Table 16.

The res@sampleFrequency, res@nrAudioChannels, res@frameRate and res@resolution attributes

may be absent when the upnp:resExt:componentInfo element is provided.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC F434U N

29341-20-12

[C OMMENT] An example of a upnp:resExt::componentInfo metadata returned for a

object.item.videoItem with two video streams and three audio streams is given below. All streams
are embedded in an “.mp4” container resource as indicated by the <res> element.
<item id="100" parentID="200" restricted="0">
<dc:title>KBS Sports</dc:title>
<upnp:class>object.item.videoItem</upnp:class>
<res id="100-res-1" protocolInfo="http-get:*:video/mp4:*" bitRate="11000100"
frameRate="30p"
resolution="1920x1080">
http://10.0.0.1/content/content?id=100-res
</res>
<upnp:resExt id="100-res-1">
<upnp:componentInfo>
<upnp:componentGroup groupID="vg1" required="0">
<upnp:component componentID="vid_comp_0">
<upnp:componentClass>Video</upnp:componentClass>
<upnp:contentType MIMEType="mime/x-video; codecs=avc1.4D4029"
extendedType="*" resolution="1920X1080" framerate="30p"
bitrate="3300000"/>
</upnp:component>
<upnp::componentGroup>
<upnp::componentGroup groupID="vg2" require="0">
<upnp:component componentID="vid_comp_1">
<upnp:componentClass>Video</upnp:componentClass>
<upnp:contentType MIMEType="mime/x-video; codecs=avc1.42E01E"
extendedType="*" resolution="720X480" framerate="30p"
bitrate="800000"/>
</upnp:component>
</upnp:componentGroup>
<upnp:componentGroup groupID="ag1" required="0">
<upnp:component componentID="aud_comp_1">
<upnp:componentClass>Audio</upnp:componentClass>
<upnp:language>en-US</upnp:language>
<upnp:contentType MIMEType="mime-x-audio; codecs=mp4a"
extendedType="*" nrAudioChannels="2" bitrate="50000"/>
</upnp:component>
</upnp:componentGroup>
<upnp:componentGroup groupID="ag2" required="0">
<upnp:component componentID="aud_comp_2">
<upnp:componentClass>Audio</upnp:componentClass>
<upnp:language>en-US</upnp:language>
<upnp:contentType MIMEType="mime/x-audio; codecs=ac-3"
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 138 –

extendedType="*" nrAudioChannels="2" bitrate="500000"/>

</upnp:component>
</upnp:componentGroup>
<upnp:componentGroup groupID="ag3" required="0">
<upnp:component componentID="aud_comp_3">
<upnp:componentClass>Audio</upnp:componentClass>
<upnp:language>en-US</upnp:language>
<upnp:contentType MIMEType="mime/x-audio; codecs=dtsh"
extendedType="*" nrAudioChannels="6" bitrate="5000000"/>
</upnp:component>
</upnp:componentGroup>
</upnp:componentInfo>
</upnp:resExt>

</item>

10.1.3.12.7
[G UIDELINE ] If a UPnP AV MediaServer control point lists CDS objects with a particular base-class
upnp:class value to users, then it shall also list CDS objects that have a upnp:class value that is
derived from the supported base-class.

For example, a MediaServer control point displays content listings for images with a upnp:class
value object.item.imageItem needs also to display CDS objects with a upnp:class value of
object.item.imageItem.xyz.

[ATTRIBUTES ]

M C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC YCT43

+UP+ 29341-20-12

[C OMMENT] Control Points will not match exclusively on base-class values because guideline
10.1.3.12.1 allows MediaServers to use derived-class values. Derived-class values allow a DMS to
provide more information about a CDS object. Control points can use this additional information in
a variety of ways, but using the upnp:class value to prevent users accessing valid content is not
acceptable behavior.

10.1.3.12.8
[G UIDELINE ] CDS objects that use either object.item.videoItem or object.item.imageItem or a
derived class value from either class may include <res> elements that describe image-based
thumbnails

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 7XW9Y

29341-20-12
IEC 62481-2

[C OMMENT] Guideline 10.1.4.7.3 describes the mandatory requirements for thumbnails if a device
chooses to use them

10.1.3.12.9
[G UIDELINE ] If a Content Source declares res@colorDepth for media resources of the Image Media
Class the value shall be one of the values defined in Table 8.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC I78Q2 N

DLNA guidelines; Part 1-1: Architecture and protocols

 – 139 –

29341-20-12
IEC 62481-2

10.1.3.12.10
[G UIDELINE ] If a Content Source declares res@resolution for media resources of the Image or AV
Media Classes the device shall use the two-number format “HxV” described in ISO/IEC 29341-20-12,
whereby the first number (H) defines the horizontal frame resolution and the second number (V)
defines the vertical frame resolution of the encoded raw-data stream.

The encoded raw-data stream is defined as the byte stream that represents the compressed image
or video carried as payload in a file or transport format. The horizontal and vertical values in
res@resolution describe values applicable to the raw-data stream before performing any
transformations specified as file metadata.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC J5N79

29341-20-12

[C OMMENT] This guideline defines the concept of resolution for images or video resources. The
resolution is defined as two integer numbers represented jointly as HxV. The H value indicates the
number of scanned pixels in the horizontal dimension. The V value indicates the number of scanned
pixels in the vertical dimension. For example, the maximum size of a JPEG_SM image is 640 x 480,
a typical size for HD video is 1 920 x 1 080, etc.

This guideline clarifies that the resolution is always computed from the encoded raw-data stream.
The raw-data stream represents the compressed image or video carried as the payload of some file
or transport format. Some file or transport formats include additional metadata to perform
transformations on the raw-data stream. For example, a JPEG image of size 600 x 400 (raw-data)
can have Exif orientation metadata to rotate the image 90 degrees.

Even though the Exif metadata leads to a final image displayed with a resolution of 400 x 600, the
Content Source declares the image resolution as:

res@resolution=”600x400”

Similarly, MP4 files include a transformation matrix that can be used to rotate the video frames at
the time of rendering

10.1.3.12.11
[G UIDELINE ] A Content Source must use the resolution or the encoded raw-data stream, as defined
in 10.1.3.12.9, in order to assign a Profile ID to a media resource of the image or AV Media Classes.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC XVMH6

29341-20-12

[C OMMENT] Many of the DLNA-defined Media Format Profiles include constraints on the resolution
of image or video resources. This guideline clarifies that the resolution of an image or an A/V
resource is defined in a manner consistent with the definition of res@resolution.

10.1.3.12.12
[G UIDELINE ] A Content Source may use the res@dlna:rotation property to advertise a rotation
angle to be applied at the time of rendering a resource of the image or AV Media Class

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 140 –

[ATTRIBUTES ]

O A DMS +PU+ +UP+ M-DMS n/a ISO/IEC HVHYH

29341-20-12

[C OMMENT] JPEG/Exif images and MP4 files can include a file property that indicates the rotation
angle that should be applied at the time of rendering the resource. This guideline gives Content
Sources the option to expose such an angle as a CDS property

10.1.3.12.13
[G UIDELINE ] The res@dlna:rotation property value must be of type ui4, between 0 and 359. This
value represents the rotation angle in degrees such that when applied to an image or to video
frames, it results in an image or video displayed with the correct orientation. The angle is measured
using a counterclockwise direction.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC NPGDX

29341-20-12

[C OMMENT] This guideline defines an optional property used to advertise the rotation angle that
Content Receivers need to apply to an image or to video frames in order to display an image or
video with the correct orientation.

For example, consider the case of a UPnP AV MediaServer that exposes an image with a resolution
of 640 x 480. If the raw-data image is:

E
And, if the correct orientation for this image is:

L
Then the Content Source exposes a rotation angle of 90 degrees. The rotation angle is always
measured counterclockwise.

Some Content Sources will read the rotation metadata and perform rotation of the frame(s) before
sending a resource across the network. These Content Sources do not expose the
res@dlna:rotation property because the resource no longer needs to be rotated by the Content
Receiver.

10.1.3.12.14
[G UIDELINE ] If a Content Source uses the res@dlna:rotation property, its value must be compatible
with the value of the rotation (or orientation) angle described as a property in the file format.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC N9T4Y

29341-20-12

[C OMMENT] JPEG/Exif images and MP4 files can include a file property that indicates the rotation
angle that should be applied at the time of rendering the resource. The value in the file property
needs to be compatible with the value exposed in the CDS property

DLNA guidelines; Part 1-1: Architecture and protocols

 – 141 –

10.1.3.12.15
[G UIDELINE ] If a Content Source declares res@bitRate for media resources of the Audio or AV
Media Classes then the value of res@bitRate shall correspond to the sum of the individual video
component bitrate + audio component bitrate + average system overhead bitrate.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC CGXI6 N

29341-20-12

[C OMMENT] This guideline defines the concept of bitrate. An example of a maximum combined
value for a bitrate parameter for an object.item.videoitem containing a video component of 5 Mbps,
an audio track of 1 Mbps, and system overhead bitrate of 30 Kbps would be 6030000.

10.1.3.12.16
[G UIDELINE ] If a Content Source declares res@sampleFrequency for media resources of the Audio
Class or AV Media Class then the value of res@sampleFrequency shall correspond to the highest
sample rate value of the individual audio tracks and shall be expressed in Hertz.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC OQ7N4 N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of sampleFrequency. For example an audio
raw-data stream encoded at a sample rate of 44,1 kHz would have
res@sampleFrequency="44100".

If a content binary has multiple audio tracks then this guideline clarifies that the
res@sampleFrequency represents the highest, eg if there are two audio tracks, one with a sample
frequency of 44,1 kHz and another with 48 kHz then the value would be
res@sampleFrequency=”48000”.

10.1.3.12.17
[G UIDELINE ] If a Content Source declares res@nrAudioChannels for media resources of the Audio
Class or AV Media Class then the value of res@ nrAudioChannels shall correspond to the highest
"number of channels" value of the individual audio tracks for the raw audio stream.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC NXYPY N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of nrAudioChannels. For example, if the audio
raw-data stream is encoded as Dolby 6.1 then res@nrAudioChannels="7", or if the audio raw-data
stream is encoded as 2 channel stereo then res@nrChannels="2".

If a content binary has multiple audio tracks then this guideline clarifies that the
res@nrAudioChannels represents the highest, eg if there are two audio tracks, one with 2 audio
channels and another with 2 audio channels then the value would be res@nrAudioChannels=”6”.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 142 –

10.1.3.12.18
[G UIDELINE ] If a Content Source declares res@frameRate for media resources of the AV Media
Class then the value of res@frameRate shall correspond to the maximum frame rate of the
individual video tracks for the encoded video raw-data stream.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC O66SO N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of frameRate for video bit streams. For example, if
the videoraw-data stream is encoded at 29,97 Hz interlaced then res@frameRate="29.97i", or if the
video raw-data stream is 60 Hz progressive then res@frameRate="60p".

If a content binary has multiple video tracks then this guideline clarifies that the res@frameRate
represents the highest, eg if there are two video tracks, one with 29,97 Hz interlace and another
with 60 Hz progressive then the value would be res@frameRate=”60p”.

10.1.3.12.19
[G UIDELINE ] For CDS items exposed with a upnp:resExt::componentInfo element, one
upnp:resExt::componentInfo::componentGroup element shall be exposed for each Audio or Video
stream included in the content.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC ZK2NR N

29341-20-12
IEC 62481-2

[C OMMENT] The upnp:resExt::componentInfo metadata only describes the individual streams

present in a container type file format such as MP4 in a flat heirachy style and does not describe
other playback scenarios possible with [CDS:4 ref].

10.1.3.12.20
[G UIDELINE ] For each upnp:resExt::componentInfo::componentGroup element the following
attributes shall be included:

• upnp:resExt::componentInfo::componentGroup@groupID,
• upnp:resExt::componentInfo::componentGroup@required.
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 3M22S N

29341-20-12
IEC 62481-2

[C OMMENT] These attributes are mandated by ISO/IEC 29341-20-12, IEC 62481-2.

10.1.3.12.21
[G UIDELINE ] The value of the upnp:resExt::componentInfo::componentGroup@groupID attribute
shall be unique within the containing upnp:resExt:componentInfo element and shall not exceed 32
characters.

[ATTRIBUTES ]

DLNA guidelines; Part 1-1: Architecture and protocols

 – 143 –

M A DMS M-DMS n/a ISO/IEC 9BAJK N

29341-20-12
IEC 62481-2

[C OMMENT] This is a unique identifier for groups within a multi-component <res> element.

10.1.3.12.22
[G UIDELINE ] For each upnp:resExt::componentInfo::componentGroup element exposed one
upnp:resExt::componentInfo::componentGroup::component sub-element shall be exposed.

Exposure in a flat heirachy is only required for devices exposing a dlna-version of "1.6". Future
versions could enable other hierarchies.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC QQOFT N

29341-20-12
IEC 62481-2

[C OMMENT] Currently only one raw-data stream is included per

upnp:resExt::componentInfo::componentGroup, thereby there is a 1-to-1-to-1 mapping between a a
audio or video raw-data stream, a upnp:resExt::componentInfo::componentGroup, and a
upnp:resExt::componentInfo::componentGroup::component.

10.1.3.12.23
[G UIDELINE ] For each upnp:resExt::componentInfo::componentGroup::component element the
following attributes shall be included:

• upnp:resExt::componentInfo::componentGroup::component@componentID.
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC DTDFR N

29341-20-12
IEC 62481-2

[C OMMENT] These attributes are mandated by ISO/IEC 29341-20-12.

10.1.3.12.24
[G UIDELINE ] The value of the
upnp:resExt::componentInfo::componentGroup::component@componentID attribute shall be
unique within the containing upnp:resExt:componentInfo element and shall not exceed 32
characters.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC PK5XP N

29341-20-12
IEC 62481-2

[C OMMENT] This is a unique identifier for groups within a multi-component <res> element.

10.1.3.12.25
[G UIDELINE ] For each upnp:resExt::componentInfo::componentGroup::component element
exposed one each of the following required sub-elements shall be exposed:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 144 –

• upnp:resExt::componentInfo::componentGroup::component::componentClass,
• upnp:resExt::componentInfo::componentGroup::component::contentType.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC SCEVZ N

29341-20-12
IEC 62481-2

[C OMMENT] These elements are mandated by ISO/IEC 29341-20-12.

10.1.3.12.26
[G UIDELINE ] For CDS items exposed with a upnp:resExt::componentInfo element one
upnp:resExt::componentInfo::componentGroup element and its required sub- elements shall be
exposed for each Audio or Video stream included in the content item, The required sub-elements
are:

• upnp:resExt::componentInfo::componentGroup::component::contentType@MIMEType,
• upnp:resExt::componentInfo::componentGroup::component::contentType@extendedType
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC LQREA N

29341-20-12
IEC 62481-2

[C OMMENT] These attributes are mandated by ISO/IEC 29341-20-12.

10.1.3.12.27
[G UIDELINE ] The value of the
upnp:resExt::componentInfo::componentGroup::contentType@MIMEType attribute shall be
"mime/x-audio" and "mime/x-video" for audio raw-data streams and video raw-data streams
respectively. It shall also include the codec extension parameter in the @MIMEType string as
defined in IETF RFC 2045.

See example in 10.1.3.12.6.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC Q9QWE N

29341-20-12
IEC 62481-2
IETF RFC 2045

10.1.3.12.28
[G UIDELINE ] The value of the
upnp:resExt::componentInfo::componentGroup::componentType@extended attribute shall be "*".

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC Z3JVU N

29341-20-12
IEC 62481-2

10.1.3.12.29
[G UIDELINE ] The value of the upnp:resExt::componentInfo::componentGroup::component::class
element shall be either "Audio" if the upnp:resExt::componentInfo::componentGroup::component
DLNA guidelines; Part 1-1: Architecture and protocols
 – 145 –

element corresponds to an audio raw-data stream or "Video" if it corresponds to a video raw-data

stream.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC E4WVD N

29341-20-12
IEC 62481-2

[C OMMENT] Only audio and video multi-component <res> information is defined in ISO/IEC
29341-20-12.

10.1.3.12.30
[G UIDELINE ] If the value of the upnp:resExt::componentInfo::componentGroup::component::class
element is "Audio" then the following attributes shall be provided:

• upnp:resExt::componentInfo::componentGroup::component::contentType@bitrate,
• upnp:resExt::componentInfo::componentGroup::component::contentType@sampleFrequency,
• upnp:resExt::componentInfo::componentGroup::component::contentType@nrAudioChannels.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 3EBUI N

29341-20-12
IEC 62481-2

[C OMMENT] These are the attributes required to describe audio raw-data streams.

10.1.3.12.31
[G UIDELINE ] In the case where the
upnp:resExt::componentInfo::componentGroup::component::contentClass is "Audio" the value of
the upnp:resExt::componentInfo::componentGroup::component::contentType@bitRate shall
correspond to the bitrate of the audio raw-data stream which is highest (system overhead is not
included).

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC 2XK4I N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of bitrate for individual audio raw-data streams
inside a multi-component <res> element.

See example in.10.1.3.12.6

10.1.3.12.32
[G UIDELINE ] If a Content Source declares
upnp:resExt::componentInfo::componentGroup::component::contentType@sampleFrequency for
media resources of the Audio Class then the value of
upnp:resExt::componentInfo::componentGroup::component::contentType@sampleFrequency
shall correspond to the sample rate value described in IEC 62481-2 and shall be expressed in Hertz.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 146 –

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC Z9WUV N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of sampleFrequency for individual audio raw-data
streams inside a multi-component <res> element.

See example in 10.1.3.12.6.

10.1.3.12.33
[G UIDELINE ] If a Content Source declares
upnp:resExt::componentInfo::componentGroup::component::contentType@nrAudioChannels for
media resources of the Audio Class then the value of
upnp:resExt::componentInfo::componentGroup::component::contentType@nrAudioChannels shall
correspond to the "number of channels" value described in IEC 62481-2 for the audio raw-data
stream.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC V5BI7 N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of nrAudioChannels for individual audio raw-data
streams inside a multi-component <res> element. See example in 10.1.3.12.6.

10.1.3.12.34
[G UIDELINE ] If the value of the upnp:resExt::componentInfo::componentGroup::component::class
element is "Audio" then the following sub-element shall be provided:

• upnp:resExt::componentInfo::componentGroup::component::language.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 3NWAT N

29341-20-12
IEC 62481-2

10.1.3.12.35
[G UIDELINE ] If the value of the upnp:resExt::componentInfo::componentGroup::component::class
element is "Video" then the following attributes shall be provided:

• upnp:resExt::componentInfo::componentGroup::component::contentType@bitrate,
• upnp:resExt::componentInfo::componentGroup::component::contentType@resolution,
• upnp:resExt::componentInfo::componentGroup::component::contentType@frameRate.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC LLBKI N

29341-20-12
IEC 62481-2

[C OMMENT] These are the attributes required to describe video raw-data streams. See examples in
10.1.3.12.6.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 147 –

10.1.3.12.36
[G UIDELINE ] In the case where the
upnp:resExt::componentInfo::componentGroup::component::contentClass is "Video" the value of
the upnp:resExt::componentInfo::componentGroup::component::contentType@bitRate shall
correspond to the bitrate of the video raw-data stream which is highest. If the actual bitrate is not
known (e.g., live content), then the maxium bit rate for the video raw data streams as defined for the
Media Format Profile shall be used.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC NI88X N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of bitrate for individual video raw-data streams
inside a multi-component <res> element. See examples in 10.1.3.12.6.

10.1.3.12.37
[G UIDELINE ] If a Content Source declares
upnp:resExt::componentInfo::componentGroup::component::contentType@resolution then the
value of the upnp:resExt::componentInfo::componentGroup::component::contentType@resolution
shall correspond to the HxV value of the video track having the highest HxV pixel count.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC UK8QD N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of resolution for individual video raw-data streams
inside a multi-component <res> element. See example in 10.1.3.12.6.

10.1.3.12.38
[G UIDELINE ] If a Content Source declares
upnp:resExt::componentInfo::componentGroup::component::contentType@frameRate then the
value of upnp:resExt::componentInfo::componentGroup::component::contentType@frameRate
shall correspond to the maximum frame rate described in IEC 62481-2 for the video raw-data
stream.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a ISO/IEC K7DVB N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline defines the concept of frameRate for individual video raw-data streams
inside a multi-component <res> element. See example in 10.1.3.12.6.

10.1.3.13 MM protocolInfo context

10.1.3.13.1
[G UIDELINE ] For all guidelines related to protocolInfo values, the following interpretation shall be
applied when applying a context for the protocolInfo value. Additions, exceptions, and other
clarifications to these baseline interpretation rules shall be indicated in other guidelines on a
per-parameter basis.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 148 –

[ATTRIBUTES ]

M C DMP DMS DMR DMC M-DMP n/a ISO/IEC 7T96Y

+DN+ +PU+ +UP+ M-DMS 29341-14-10
M-DMC ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

10.1.3.13.2
[G UIDELINE ] The phrase “match by protocolInfo format” shall mean the following.

Given two protocolInfo values, the values shall match if both protocolInfo values have the same
values as follows:

• first field of protocolInfo, except as noted below.

– In order to match, equality for the first field is required for all scenarios, except for those
involving upload AnyContainer or other optional content management (OCM) operations.
DLNA.ORG_PN parameter in the fourth field of protocolInfo If the two protocolInfo values fail to
match above, then given two protocolInfo values, the value shall match if both protocolInfo values
have the same values as follows:

• first field of protocolInfo, except as noted below.

– In order to match, equality for the first field is required for all scenarios, except for those
involving upload AnyContainer or other optional content management (OCM) operations.
• third field of protocolInfo
[ATTRIBUTES ]

M C DMP DMS DMR DMC M-DMP n/a ISO/IEC S3V59 C

+DN+ +PU+ +UP+ M-DMS 29341-14-10
M-DMC ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT]

a) This phrase is used throughout the guidelines related to protocolInfo values. The phrase applies
to any protocolInfo value, regardless from where the values were obtained. ProtocolInfo values
can be found on DMS and DMR devices, typically associated with res@protcolInfo metadata or
UPnP AV connection information.
b) If the DLNA.ORG_PN parameter in the fourth field of protocolInfo matches then there is a
greater chance that the content will be able to be played back.
c) This guideline is to require Rendering Endpoints to try and render a content binary if it supports
just the underlying protocol and MIME type in protocolInfo. This will enable DLNA Rendering
Endpoints to match and play content not advertised with the DLNA profile ID, a DLNA Profile ID
that’s not supported, or a new DLNA Profile ID defined in the future.
d) This requirement is also on a controller (e.g. application) to try and ask a UPnP AV
MediaRenderer to play content where the UPnP AV MediaRenderer indicates it supports just the
MIME type and protocol.
10.1.3.13.3
[G UIDELINE ] If a UPnP AV MediaServer or UPnP AV MediaRenderer exposes a res@protocolInfo
with a <res> element that includes a URI value, then the context of the protocolInfo shall be to
describe the content and/or transport layer features for the indicated <res> URI value.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 149 –

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC WX6PS

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] DMS devices report res@protocolInfo values when responding to

ContentDirectoryService requests, including those related to the Upload system usage or optional
content management operations.

A DMR can create DIDL-Lite metadata to describe what it is currently rendering. See 10.1.3.13.16
for more information.

10.1.3.13.4
[G UIDELINE ] If a UPnP AV MediaServer exposes a res@protocolInfo with a <res> element that
omits the URI value but includes a res@importUri property, then the context of the protocolInfo shall
be to describe the content that MediaServer expects to receive in a content transfer process.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC CYRUW

29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] When used with a <res> element that omits a URI value but includes a res@importUri
property, the DLNA.ORG_PN parameter identifies the DLNA Media Format Profile that the DMS
expects to receive for that particular <res> element. In some cases, DMS implementations will
specify various parameters and flags in the 4th field that will become applicable after the content is
uploaded and the DMS can serve the content.

10.1.3.13.5
[G UIDELINE ] If a UPnP AV MediaServer exposes a res@protocolInfo with a <res> element that
omits both the URI value and the res@importUri property in a CDS object with the upnp:class
property value of object.item.epgItem,object.item.epgItem, object.item.video.videoBroadcast,
object.item.audio.audioBroadcast or any of their derived classes, then the context of the
protocolInfo shall be to describe the content and/or transport layer features of the content item
associated with the CDS object, or of the media resource that the MediaServer expects to expose at
a future time.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC W8JTY

29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] When used with a <res> element that omits both the URI value and the res@importUri
property, the DLNA.ORG_PN parameter identifies the DLNA Media Format Profile of the content
resource that the DMS expects to become available later for that particular <res> element. The
additional information can allow controllers to make advance arrangements or decisions regarding

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 150 –

the content even before it is available. For example, a +SR+ controller can utilize this information to
set up a future recording.

10.1.3.13.6
[G UIDELINE ] If a UPnP AV MediaServer exposes a res@protocolInfo with a <res> element that
omits the URI value but includes a res@importUri property, then the protocolInfo 4th field may
contain parameters and flags intended for use when the <res> URI value is finally created by the
MediaServer.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC WHVV8

29341-14-11
ISO/IEC
29341-20-12

10.1.3.13.7
[G UIDELINE ] A UPnP AV MediaServer’s list of protocolInfo values in the CMS.SourceProtocolInfo
state variable shall contain an additonal protocolInfo value with only an “*” in the fourth field (wildcard)
for each supported protocolInfo value with a DLNA.ORG_PN parameter in the fourth field.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-11 LVOXT N

ISO/IEC 29341-20-12

[C OMMENT] Having a UPnP AV MediaServer advertise supported CMS.SourceProtocolInfo values

with “*” in the fourth field will enable matching with only MIME type (third field) and protocol (first
field) for legacy DLNA devices. For example, a CMS.SourceProtocolInfo value of
"http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=01;DLNA.ORG_FLAG
S=AD500000000000000000000000000000" will cause a value of “http-get:*:video/mpeg:*” to be
included in the comma-separated values of the CMS.SourceProtocolInfo state variable as well.

10.1.3.13.8
[G UIDELINE ] A UPnP AV MediaServer’s list of protocolInfo values in the CMS.SourceProtocolInfo
state variable shall be condensed into a single protocolInfo value for duplicate protocolInfo values in the
CMS.SourceProtocolInfo state variable.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-11 3MEAB N

ISO/IEC 29341-20-12

[C OMMENT] Guideline 10.1.3.13.7 could potentially create duplicate protocolInfo values and this
guideline requires that they are condensed into a single protocolInfo value in the
CMS.SourceProtocolInfo state variable.

10.1.3.13.9
[G UIDELINE ] If a UPnP AV MediaServer lists a protocolInfo in the CMS.SourceProtocolInfo state
variable, then the context of the protocolInfo shall be to describe the MediaServer's ability to
support the described feature or content for the following:

• serving content to other endpoints on the network.

(That is, the parameters and flags represent a union of the MediaServer's features/capabilities for
the specified DLNA Media Format Profile.)

DLNA guidelines; Part 1-1: Architecture and protocols

 – 151 –

This guideline works in conjunction with 10.1.3.14.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 334SX

29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The phrase “MediaServer's ability to support the described feature or content” means
that the UPnP AV MediaServer is capable of serving content binaries that are characterized by the
protocolInfo. More specifically, for each protocolInfo listed in SourceProtocolInfo the UPnP AV
MediaServer exposes zero or more content binaries that “match by protocolInfo format”. In practice,
UPnP AV MediaServers in some cases expose a static list of protocolInfo values to indicate all
possible Media Format Profiles that they can serve. In other cases UPnP AV MediaServers will
expose a dynamic list of protocolInfo values to indicate the Media Format Profiles that they can
currently serve.
For example, if a MediaServer lists
"http-get:*:audio/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=01;DLNA.ORG_FLAGS=
AD500000000000000000000000000000" then the MediaServer is capable of serving MPEG_PS_NTSC content with the
following characteristics.

• Some of that content might support the Range HTTP header under the "Full Random Access
Data Availability" model due to the DLNA.ORG_OP value.
• Some of that content might support the Range HTTP header under the "Limited Random Access
Data Availability" model because the lop-bytes flag is true.
• Some of that content might have the sp-flag set to true.
• Some of the content might have beginning point that increases with time (e.g. live content)
because the s 0 -increasing flag is true.
• Some of the content might have an ending point that increases with time (e.g. infinitely long live
content or live content that is currently being saved to disk and will eventually reach a finite
length) because the s N -increasing flag is true.
• Some of the content might support Streaming and Background Transfer modes because the
tm-s and tm-b flags are true.
The pn-param (DLNA.ORG_PN) is the only required parameter for DLNA Media Format Profiles. All
other parameters and flags are optional for the syntax. (See also 10.1.3.15.3.)

10.1.3.13.10
[G UIDELINE ] A UPnP AV MediaRenderer’s list of protocolInfo values in the CMS.SinkProtocolInfo
state variable shall contain an additional protocolInfo value with only an “*” in the fourth field (wildcard)
for each supported protocolInfo values with a DLNA.ORG_PN parameter in the fourth field. Duplicate
protocolInfo values in the CMS.SinkProtocolInfo state variable can be condensed to a single protocolInfo
value.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 29341-14-10 AEJZ7 N

ISO/IEC 29341-14-11

[C OMMENT] Having a UPnP AV MediaRenderer advertise supported CMS.SinkProtocolInfo values

with “*” in the fourth field will enable matching with only MIME type (third field) and protocol (first
field) for legacy DLNA devices. For example, a CMS.SinkProtocolInfo value of

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 152 –

"http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS" will cause a value of “http-get:*”video/mpeg:*”

to be included in the comma separated values of the CMS.SinkProtocolInfo state variable as well.

10.1.3.13.11
[G UIDELINE ] A UPnP AV MediaRenderer’s list of protocolInfo values in the CMS.SinkProtocolInfo
state variable shall be condensed into a single protocolInfo value for duplicate protocolInfo values in the
CMS.SourceProtocolInfo state variable.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 29341-14-10 KJONU N

ISO/IEC 29341-14-11

[C OMMENT] Guideline 10.1.3.13.10 could potentially create duplicate protocolInfo values and this
guideline requires that they are condensed into a single protocolInfo value in the
CMS.SinkProtocolInfo state variable.

10.1.3.13.12
[G UIDELINE ] If a UPnP AV MediaRenderer lists a protocolInfo in the CMS.SinkProtocolInfo state
variable, then the context of the protocolInfo shall be to describe the MediaRenderer's ability to
support that the indicated feature or content.

(That is, the parameters and flags represent a union of the MediaRenderer's features/capabilities
for the specified DLNA Media Format Profile).

This guideline works in conjunction with 10.1.3.14.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 34SXQ

29341-14-10
ISO/IEC
29341-14-11

[C OMMENT] The phrase “MediaRenderer's ability to support that the indicated feature or content”
means that the DMR can use the specified feature when rendering content that is a “match by
protocolInfo format”. It is not a guarantee that the DMR will use that feature when rendering such
content. Each DMR implementation determines when and how features are used to deliver a
playback experience.
For example, if a MediaRenderer lists
"http-get:*:audio/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=01;DLNA.ORG_FLAGS=BD1000000000000
00000000000000000" then the MediaRenderer is capable of rendering MPEG_PS_NTSC content for a variety of
scenarios.

• It can render MPEG_PS_NTSC content regardless of whether the sp-flag, s 0 -increasing, or

s N -increasing flags are set to true or false for that content.
• If the Content Source makes the Range HTTP header available, the Content Receiver is able to
use the Range HTTP header for both "Full Random Access Data Availability" and "Limited
Random Access Data Availability" models because the op-param and the lop-bytes flag.
• If given a PlayContainer URI, the DMR will also play MPEG_PS_NTSC content found during the
traversal of the DMS because the playcontainer-param is set to true.
• The DMR uses Streaming transfers for the MPEG2_PS_NTSC content, as required for
immediate rendering.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 153 –

The pn-param (DLNA.ORG_PN) is the only required parameter for DLNA Media Format Profiles. All
other parameters and flags are optional for the syntax.

10.1.3.13.13
[G UIDELINE ] If a UPnP AV MediaServer or UPnP AV MediaRenderer uses a protocolInfo value in
the ProtocolInfo output argument of a CMS:GetCurrentConnectionInfo response, then the context of
the protocolInfo shall describe the content and the transport layer capabilities of the UPnP AV
connection.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC HVV8S

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] In this context, the protocolInfo value describes the content and/or transport layer
capabilities of the UPnP AV connection from the server-side.
For example, if a UPnP AV connection indicates
"http-get:*:audio/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=01;DLNA.ORG_FLAGS=0510000000000000
0000000000000000" then the transport layer associated with the UPnP AV connection is configured to work in the
following ways.

• The MPEG_PS_NTSC content has the sp-flag set to false and the tm-s flag is set to true to
indicate that transport layer is using a Streaming transfer where the Content Source is not the
Clock Source. This means the Content Source will ensure that it transmits at a throughput
necessary for rendering but will also preserve the entire content bitstream even for lower
transmission throughputs when network conditions are not able to support the bandwidth
needed for the Streaming transfer.
• The Range HTTP header is available only under the "Full Random Access Data Availability"
model.
• The content is growing with a fixed beginning because the s 0 -increasing flag is false and the
s N -increasing flag is true.
The phrase “describe the content and the transport layer capabilities of the UPnP AV connection”
does not imply that actual data is actually being transported on the UPnP AV connection at the
current moment because the Content Receiver endpoint might be in a playback state (such as stop
or pause) that does not involve the ongoing transmission of content data.

10.1.3.13.14
[G UIDELINE ] If a UPnP AV MediaServer control point creates a res@protocolInfo value for use with
a CDS:CreateObject request that qualifies as one of the listed operations, then the context of the
protocolInfo shall be to describe the content that is going to be uploaded to the MediaServer through
a content transfer process.

• upload AnyContainer
• OCM: upload content
Furthermore, the default behavior of the control point shall be to exclude 4th field parameters
(except the DLNA.ORG_PN parameter, described in 10.1.3.18) or specify the parameter with a false
value (such as in the case of the lop-npt flag, described in 10.1.3.28.4).

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 154 –

[ATTRIBUTES ]

M C +UP+ n/a n/a ISO/IEC YRUW7

29341-20-12

[C OMMENT] Unless specified otherwise, 4th field parameters do not apply to what the Upload
Controller can do. Rather, the DMS will provide the appropriate 4th field parameters during the
course of an Upload system usage or an optional content management operation. See 10.1.3.13.4
and 10.1.3.13.6 for more information.

10.1.3.13.15
[G UIDELINE ] If a UPnP AV MediaRenderer control point creates a protocolInfo or res@protocolInfo
value, then the context of the protocolInfo shall be to describe the Content Source's capabilities for
the associated UPnP AV connection or <res>.

[C OMMENT] “MediaRenderer control point creates a protocolInfo or res@protocolInfo” specifically

refers to the following scenarios. This phrase is used in other guidelines related to protocolInfo.

• res@protocolInfo values that appear in CDS or DIDL-Lite metadata used as input arguments for
AVT:SetAVTransportURI, or other UPnP AV actions.
[ATTRIBUTES ]

M C DMC +PU+ M-DMC n/a ISO/IEC X6PSO

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] In the case of AVT:SetAVTransportURI, the res@protocolInfo can appear in the

DIDL-Lite metadata of the CurrentURIMetaData input argument.

10.1.3.13.16
[G UIDELINE ] A UPnP AV MediaRenderer may use res@protocolInfo values in the following ways.

• res@protocolInfo values may appear in any AVTransport virtual instance state variable,
including but not limited to: AVT.NextAVTransportURIMetaData, AVT.CurrentTrackMetaData,
and AVT.AVTransportURIMetaData.
• res@protocolInfo values may appear in output arguments of any AVTransport actions, including
but not limited to:
– CurrentURIMetaData of AVT:GetMediaInfo
– NextURIMetaData of AVT:GetMediaInfo, or
– TrackMetadata of AVT:GetPositionInfo.
[ATTRIBUTES ]

O C DMR n/a n/a ISO/IEC 3V59O

29341-14-10

[C OMMENT] This guideline clarifies where a DMR can use res@protocolInfo values.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 155 –

10.1.3.14 MM consistency of protocolInfo state variables and output arguments

[G UIDELINE ] If the listed values for the CMS.SinkProtocolInfo or CMS.SourceProtocolInfo state
variables' change, then the ConnectionManager service shall report the change through the GENA
event mechanism, as defined by ISO/IEC 29341-1.

CMS:GetProtocolInfo shall return the same protocolInfo list for SinkProtocolInfo output argument as
the current list indicated by the CMS.SinkProtocolInfo state variable.

CMS:GetProtocolInfo shall return the same protocolInfo list for SourceProtocolInfo output argument
as the current list indicated by the CMS.SourceProtocolInfo state variable.

[ATTRIBUTES ]

M R DMS DMR M-DMS n/a ISO/IEC T96YP

29341-1
ISO/IEC
29341-14-11

[C OMMENT] Many 4th_field DLNA guidelines refer to CMS:GetProtocolInfo arguments, without

referring specifically to the associated ConnectionManager service state variables. This guideline
repeats the ConnectionManager service's requirement that CMS:GetProtocolInfo accurately
represent the data in the associated state variables, which in turn allows the DLNA syntax rules to
apply to CMS state variables.

10.1.3.15 MM CMS:GetProtocolInfo rules

10.1.3.15.1
[G UIDELINE ] The ConnectionManager service of a UPnP AV MediaServer shall list the union set of
protocolInfo values supported by the device for protocolInfo values that share the same values in
the first three fields and the same pn-param (DLNA.ORG_PN) value in the fourth field, but have
different values in the additional parameters in the fourth field. This means that the
ConnectionManager service shall list only one protocolInfo value to represent all such profiles.

The first three fields of the listed protocolInfo value shall be identical to the first three fields of the
individual protocolInfo values. The pn-param (DLNA.ORG_PN) value in the fourth field shall be
identical to the pn-param (DLNA.ORG_PN) value in the fourth fields of these protocolInfo values.

If additional parameters are included in the fourth field of the listed protocolInfo value, they shall
appear in the order defined in 10.1.3.17, and their values shall be obtained as defined in
10.1.3.15.5.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC CT43W

29341-14-11

[C OMMENT] This guideline makes it easier for control points to find servers that provide content for
a given profile.

Use of the http-get:*:*:* protocolInfo does not sufficiently communicate the supported Media Format
Profiles. This guideline also requires implementations to explicitly list the individual protocolInfo
values for supported DLNA Media Format Profiles.

10.1.3.15.2
[G UIDELINE ] The sets of protocolInfo values returned in CMS:GetProtocolInfo shall list the
protocolInfo values that use the http-get media transport and DLNA Media Format Profiles first.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 156 –

[ATTRIBUTES ]

M L DMS DMR M-DMS n/a ISO/IEC B4S5U

29341-14-11

[C OMMENT] Although the number of returned protocolInfo values might be large, control points can
use this guideline to capture the subset of relevant DLNA protocolInfo values.

10.1.3.15.3
[G UIDELINE ] The fourth field of the protocolInfo values (obtained from the ConnectionManager
service) that have the pn-param parameter in the fourth field shall follow one of the formatting
conventions.

• In addition to pn-param, provide one or more of the additional parameters as defined in guideline
10.1.3.17.1 (HTTP), or guideline 10.1.3.17.2 (RTP/RTSP).
• Provide only the pn-param parameter, as defined in guideline 10.1.3.18
[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC Y8Y9W

29341-14-11

[C OMMENT] This guideline allows UPnP AV MediaServer implementations to employ a verbose

listing that includes trick/seek mode capabilities or simply provide a listing based on Media Format
Profiles.

This guideline also allows UPnP AV MediaRenderer implementations to employ only primary
protocolInfo sets (non-verbose listing), or in addition, to extend the list of declared 4th field
parameters (verbose listing).

10.1.3.15.4
[G UIDELINE ] If a CSV (Comma Separated Value) list contained in a CMS:GetProtocolInfo response
has one or more embedded comma(s) in the individual substring entries of the CSV list, then those
embedded commas shall be escaped as "\," in ISO/IEC 29341-20-12, 2.3.1.

[ATTRIBUTES ]

M A DMS DMR M-DMS ISO/IEC WYAJV

29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] There is no embedded comma escaping rules in ISO/IEC 29341-14-11. This guideline
applies embedded comma escaping rules in CSV lists defined in ISO/IEC 29341-20-12 to
CMS:GetProtocolInfo response values.

10.1.3.15.5
[G UIDELINE ] If a UPnP AV MediaServer lists additional parameters (besides the pn-param) in the
4th field of protocolInfo when combining multiple protocolInfo values as defined in 10.1.3.15.1, then
they shall be obtained as follows.

• op-param: If none of the individual protocolInfo values contain an op-param value, the combined
protocolInfo value shall omit the op-param value. If the a-val of the op-param in any of the
individual protocolInfo values is "1", the a-val of the op-param in the combined protocolInfo
value shall be "1". Otherwise, the a-val of the op-param in the combined protocolInfo value shall

DLNA guidelines; Part 1-1: Architecture and protocols

 – 157 –

be "0". Similarly, if the b-val of the op-param in any of the individual protocolInfo values is "1",
the b-val of the op-param in the combined protocolInfo value shall be "1". Otherwise, the b-val of
the op-param in the combined protocolInfo value shall be "0".
• ps-param: If none of the individual protocolInfo values contain a ps-param value, the combined
protocolInfo value shall omit the ps-param value. Otherwise, the ps-param value of the
combined protofocolInfo value shall be a comma-separated list of all the distinct ps-param
values of the individual protocolInfo values.
• ci-param: If none of the individual protocolInfo values contain a ci-param value, the combined
protocolInfo value shall omit the ci-param value. If the ci-param value in any of the individual
protocolInfo values is "1", the ci-param value in the combined protocolInfo value shall be "1".
Otherwise, the ci-param value in the combined protocolInfo value shall be "0".
• flags-param: If none of the individual protocolInfo values contain a flags-param value, the
combined protocolInfo value shall omit the flags-param value. For each bit in the flags-param
value, if the corresponding bit in any of the individual protocolInfo values is "1", that bit in the
combined protocolInfo value shall be "1". Otherwise, that bit shall be "0".
• maxsp-param: If none of the individual protocolInfo values contain a maxsp-param value, the
combined protocolInfo value shall omit the maxsp-param value. Otherwise, the maxsp-param
value of the combined protocolInfo value shall be the maximum of all the maxsp-param values of
the individual protocolInfo values.
• other-param: If none of the individual protocolInfo values contain an other-param value, the
combined protocolInfo value shall omit the other-param value. Otherwise, the combined
protocolInfo value shall contain the concatenated list of all the distinct other-param values in
individual protocolInfo values.
Note that the combined protocolInfo value might not be a valid res@protocolInfo value for content
items in a content directory. For example, it might contain contradicting flags which are prohibited
by the DLNA guidelines.

For example, the union set of the following protocolInfo values:

• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=01;
DLNA.ORG_PS=2
• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=10
• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_PS=4
is either one of the following (depending on whether additional fourth-field parameters are included)

• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC
• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=11;
DLNA.ORG_PS=2,4
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 928RT

29341-14-11

10.1.3.15.6
[G UIDELINE ] The ConnectionManager service of a UPnP AV MediaRenderer shall list the collection
of distinct Primary protocolInfo Sets that it is capable of rendering.

If one or more of the declared Primary protocolInfo Sets include additional 4th field parameters, they
shall appear in the order defined in 10.1.3.17, and their values shall be as defined in 10.1.3.15.7.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 158 –

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC ETV64

29341-14-11

10.1.3.15.7
[G UIDELINE ] If a UPnP AV MediaRenderer lists additional parameters (besides the pn-param) in
the 4th field of protocolInfo when declaring the Primary protocolInfo Sets as defined in 10.1.3.15.6,
then they shall comply with the following rules:

• op-param: This parameter shall not be included.

• ps-param: This parameter shall not be included.
• ci-param: This parameter shall not be included.
• flags-param: This parameter shall be included when the UPnP AV MediaRenderer is capable of
rendering this type of content in a PlayContainer URI operation.
• maxsp-param: This parameter shall not be included.
• other-param: The inclusion or omission of this vendor-defined parameter is vendor dependent.
[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC TV648

29341-14-11

10.1.3.16 MM DIDL-Lite protocolInfo values

10.1.3.16.1
[G UIDELINE ] If the <res> value contains an HTTP URL, then the first field of the res@protocolInfo
value shall be as shown below.

• http-get
[ATTRIBUTES ]

M R DMS DMR +PU+ M-DMS n/a ISO/IEC KY2U3

29341-20-12

[C OMMENT] Guidelines in 10.1.3.16 provide requirements on the protocolInfo values in DIDL-Lite

documents.

For requirements around protocolInfo values used in the upload process, see guideline 10.1.8.19.1.

Reiterates the protocol string value for DLNA content transported across HTTP. Note that the
converse is not always true. Some scenarios involving upload operations can result with a <res>
element that has no value (i.e. empty URI) but the res@protocolInfo value has "http-get" in the first
field.

10.1.3.16.2
[G UIDELINE ] If the <res> value contains an RTP URL, then the first field of the res@protocolInfo
value shall be as shown below.

• rtsp-rtp-udp
[ATTRIBUTES ]

M R DMS DMR +PU+ M-DMS n/a ISO/IEC YNKQ9

29341-20-12

DLNA guidelines; Part 1-1: Architecture and protocols

 – 159 –

10.1.3.16.3
[G UIDELINE ] The third field of a protocolInfo value shall use the MIME types specified in Clause 5
of IEC 62481-2 for DLNA normative Media Format Profiles when the protocol is "http-get" or
"rtsp-rtp-udp".

[ATTRIBUTES ]

M F DMS DMR DMC +PU+ M-DMS M-DMC n/a ISO/IEC QQRVR

29341-20-12
IEC 62481-2

[C OMMENT] This guideline is consistent with the UPnP AV specifications for the case of "http-get",
but this guideline also conflicts in the case of "rtp-rtsp-udp".
The UPnP AV specification indicates that the 4th field for RTP URIs is the payload type, but such a
model fails to take into account that streaming of AV content with RTP generally requires multiple
RTP payload types. For this reason, the DLNA guidelines require that the 3rd field is populated with
the DLNA-specified mime-type of the Media Format Profile indicated in the pn-param.

10.1.3.16.4
[G UIDELINE ] UPnP AV endpoints (devices and control points) shall use the DLNA.ORG_PN
parameter (10.1.3.18) in the 4th field of protocolInfo for the following operations

• to identify content conforming to a DLNA Media Format Profile, or

• to specify that a UPnP device is capable of receiving, distributing, or rendering content
conforming to a DLNA Media Format Profile.
[ATTRIBUTES ]

M L DMS DMP DMR DMC M-DMP M-DMS n/a ISO/IEC QRVR5

+DN+ +PU+ +UP+ M-DMC 29341-20-12

[C OMMENT] The MIME-type in the 3rd field of res@protocolInfo alone is not always sufficient to
identify DLNA content.

10.1.3.16.5
[G UIDELINE ] If a protocolInfo value has the first value of "http-get" and the 4th field includes the
DLNA.ORG_PN parameter (10.1.3.18), then the binary data conformant to a DLNA Media Format
Profile identified by the DLNA.ORG_PN parameter shall be transmitted via the HTTP Media
Transport, without transport layer encryption.

[ATTRIBUTES ]

M L DMS DMP DMR DMC M-DMP M-DMS n/a ISO/IEC NKQ9V

+DN+ +PU+ +UP+ M-DMC 29341-14-11

[C OMMENT] This means that the binary data via the HTTP Media Transport is not encrypted unless
the guidelines of the DLNA Media Format Profile explicitly states it.
EXAMPLE 1: The following are example scenarios of creating 4th field values, and the DLNA device classes capabilities
that apply to them.
[C1] DMS, M-DMS: These endpoints populate res@protocolInfo in metadata responses and protocolInfo used in
CMS:GetProtocolInfo.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 160 –

[C2] DMS, M-DMS, +PU+: These endpoints populate values for contentFeatures.dlna.org at the transport layer, either
by creating a brand new 4th field value or modifying from existing 4th field value.
[C3] DMC, M-DMC, +PU+: The control points of these endpoints can create a 4th field value for metadata given to a
DMR, either by creating a brand new 4th field value or modifying an existing 4th field value.
[C4] DMR: When reporting metadata of content that is currently playing, these endpoints can create a new 4th field
value by modifying an existing 4th field value acquired from a DMS, DMC, or +PU+.
[C5] +UP+: These endpoints create res@protocolInfo values in CDS:CreateObject requests and also create the
contentFeatures.dlna.org value during the content transfer process.
EXAMPLE 2: The following are example scenarios of parsing 4th field values, and the DLNA device classes capabilities
that apply to them.
[P1] DMP, M-DMP DMR, DMC, M-DMC, +UP+, +DN+: Control points of these endpoints parse 4th field values in
metadata responses obtained from a DMS or M-DMS.
[P2] DMP, M-DMP, DMR, +DN+: These endpoints parse 4th field values from contentFeatures.dlna.org, at the
transport layer.
[P3] DMR: These endpoints can receive 4th field values in DIDL-Lite metadata, provided by a control point.
[P4] DMC, M-DMC, +PU+: The control points of these endpoints can receive 4th field values in DIDL-Lite metadata
that is exposed by a DMR.
[P5] DMS, M-DMS: These endpoints parse res@protocolInfo values in CDS:CreateObject requests and also parse the
contentFeatures.dlna.org value during the content transfer process.
10.1.3.17 MM protocolInfo values: 4th field
10.1.3.17.1
[G UIDELINE ] If a protocolInfo value has "http-get" as the first field value and the 4th field includes
the pn-param token, then the following syntax shall be used for the fourth field.

• 4th_field = pn-param [op-param] [ps-param] [ci-param] [flags-param] [ *(other-param)]

NOTE In all guidelines that relate to the syntax of the 4th field, the relative order of pn-param, op-param, ps-param,
ci-param, flags-param, and *(other-param) used in 4th_field is mandatory. For example, pn-param cannot appear after
op-param, ps-param, ci-param, flags-param, or *(other-params).

The syntax and definition of pn-param, op-param, ps-param, ci-param, flags-param, and
*(other-param) are defined in the guidelines below.

[ATTRIBUTES ]

M A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC Y2U3H

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline defines the syntax of the fourth field for a res@protocolInfo value that
indicates content that is transported across HTTP.

This syntax prohibits the use of the "*" value for content that conforms to a DLNA Media Format
Profile. Content that does not conform to a DLNA Media Format Profile can use the "*" value in the
4th field.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2] , [C3], [C4], [P1], [P2],
[P3], and [P4].
Examples [C5] and [P5] do not apply to this guideline because 10.1.8.19 covers these cases.

10.1.3.17.2
[G UIDELINE ] If a protocolInfo value has "rtsp-rtp-udp" as the first field value and the 4th field
includes the pn-param token, then the following syntax shall be used for the fourth field.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 161 –

• 4th_field-rtp = pn-param [op-param] [ps-param] [ci-param] [flags-param] [maxsp-param]

[*(other-param)]
[ATTRIBUTES ]

M A DMS DMP DMR DMC MHD n/a ISO/IEC YXD3U

+DN+ +PU+ +UP+ 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The 4th field syntax for rtsp-rtp-udp URIs is the same as for http-get URIs.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] , [C2], [C3], [C4], [P1], [P2],
[P3], and [P4].

+DN+ is listed because the associated control point is required to tolerate <res> elements that use
the RTP Media Transport when browsing a MediaServer.

10.1.3.17.3
[G UIDELINE ] If a protocolInfo value has the first field value that is neither equal to "http-get" nor
"rtsp-rtp-udp", then the fourth field may have a syntax that differs from 10.1.3.17.1 and 10.1.3.17.2.

[ATTRIBUTES ]

O A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC 4S5UX

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline permits a different syntax for the fourth field of a protocolInfo value
when the content is not transported over a DLNA-specified transport.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [P1], [P2],
[P3], and [P4].

CDS:CreateObject syntax has restrictions on the 4th field syntax, as described in 10.1.8.19.

Examples of protocolInfo values that include the 4th field are shown below:

• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC
• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_PAL;DLNA.ORG_OP=10
• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=10;
DLNA.ORG_PS=-1,30,-30
• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_PAL;DLNA.ORG_PS=-1,30,-30
• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_PAL;
DLNA.ORG_PS=-1,30,-30;VENDORXYZ.COM_FOO=bar
• http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_PAL;DLNA.ORG_CI=1;
VENDORXYZ.COM_FOO=bar
• rtsp-rtp-udp:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=10;
DLNA.ORG_PS=-1,2/3,4;DLNA.ORG_FLAGS=03100000000000000000000000000000;
DLNA.ORG_MAXSP=9.75
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 162 –

10.1.3.18 MM pn-param (DLNA.ORG_PN parameter)

[G UIDELINE ] The syntax definition of pn-param shall be as follows:

• pn-param = "DLNA.ORG_PN=" pn-value

• pn-value = *<"a"-"z", "A"-"Z", "0"-"9", "_">
The pn-value shall identify the DLNA Media Format Profile ID that is applicable for the context of the
protocolInfo. (See 10.1.3.12.8 for determining an appropriate context for the protocolInfo.)

The pn-param is reserved for use with contexts where content conforms to a DLNA Media Format
Profile. Use of pn-param for content not conformant with a DLNA Media Format Profile is expressly
prohibited.

[ATTRIBUTES ]

M A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC T43WJ

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline defines the syntax of the DLNA.ORG_PN parameter. This parameter is
used to identify DLNA content. This parameter cannot be used for non-DLNA content.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] , [C2] , [C3], [C4], [C5], [P1], [P2],
[P3], [P4], and [P5].

10.1.3.19 MM op-param (Operations Parameter – Common guidelines)

10.1.3.19.1
[G UIDELINE ] The syntax definition of op-param shall be as follows:

• op-param = [op-param-delim] "DLNA.ORG_OP=" op-value

• op-param-delim = ";"
• op-value = a-val b-val
• a-val = Boolean
• b-val = Boolean
• Boolean = "1" | "0"
The op-value is a string composed of two characters: a-val and b-val. The meaning of these values
is described in these guidelines, depending on whether the context is for the HTTP Media Transport
or RTP Media Transport.

• 10.1.3.20 MM op-param (Operations Parameter for HTTP)

• 10.1.3.21 MM op-param (Operations Parameter for RTP)
If the first field of protocolInfo is neither "http-get" nor "rtsp-rtp-udp" then the fourth field shall omit
the op-param.

[ATTRIBUTES ]

M A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC 96YPS

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
DLNA guidelines; Part 1-1: Architecture and protocols
 – 163 –

29341-20-12

[C OMMENT] This guideline defines the DLNA.ORG_OP parameter.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [P1], [P2],
[P3], and [P4].

10.1.3.19.2
[G UIDELINE ] If the op-param is present and if either a-val or b-val is "1", then the "Full Random
Access Data Availability" model shall be the data access model that applies in the context of the
protocolInfo value.

Specifically, this means that the transport operation (that is indicated by the a-val or b-val) shall be
supported for the entire content binary, as defined in 11.4.2.15.1.

If the flags-param token is included in the 4th field, then the s 0 -increasing, lop-npt, and lop-bytes
bits of the primary-flags token shall be set to false.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a ISO/IEC V59OT

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The DLNA.ORG_OP parameter indicates support for transport layer headers
responsible that facilitate random access operations on content binaries, under the "Full Random
Access Data Availability" model.
For more information on the "Full Random Access Data Availability" model, see the following
guidelines:

• 11.4.2.14 MT normative random access data availability models

• 11.4.2.15 MT Full Random Access Data Availability model
The "Full Random Access Data Availability" model is mutually exclusive with the "Limited Random
Access Data Availability" model, which is why lop-npt/lop-bytes cannot be used with the op-param.
For more information, see the following guidelines:

• 10.1.3.29 MM lop-npt, lop-bytes and lop-cleartextbytes (limited operations flags): Common

• 11.4.2.16 MT Limited Random Access Data Availability model
The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.19.3
[G UIDELINE ] In conjunction with the rules defined in 10.1.3.19.1 and 10.1.3.19.2, the fourth field of
a protocolInfo may use the op-param for non-DLNA Media Format Profiles.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 164 –

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a ISO/IEC 6PSOW

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline permits the use of DLNA.ORG_OP for both DLNA and non-DLNA
content, provided the DLNA-defined syntax and semantics are used.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.19.4
[G UIDELINE ] If the b-val token is true and s N -increasing flag is false, then the Content Source shall
provide content length information in the res@size value of the CDS object.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a ISO/IEC RUW7R

29341-20-12

[C OMMENT] This guideline helps resolve dependency issues that Content Receivers have on
knowing the content length, and where Content-Length is not provided in a chunked response.
Content Sources are also encouraged to provide a res@size value even in scenarios where byte
Range is not supported.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.19.5
[G UIDELINE ] If the a-val token is true and s N -increasing flag is false, then the Content Source shall
provide duration information in the res@duration value of the CDS object.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a ISO/IEC VV8SU

29341-20-12

[C OMMENT] This guideline resolves dependency issues that Content Receivers have on knowing
the content duration. If Content Sources support TimeSeekRange.dlna.org, duration information is
important, and Content Sources are urged to provide it.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.19.6
[G UIDELINE ] If the Pause media operation is supported, Rendering Endpoints shall support the
Pause Release media operation even in the absence of Content-Length, res@size, or res@duration
information.

[ATTRIBUTES ]

M L DMR DMP M-DMP n/a ISO/IEC 4SXQQ

29341-20-12

DLNA guidelines; Part 1-1: Architecture and protocols

 – 165 –

[C OMMENT] Rendering Endpoints can issue a Range request using the "beginrange-" notation so
as to avoid specifying an invalid range. Rendering Endpoints can issue a TimeSeekRange.dlna.org
request using the "begintime-" notation so as to avoid specifying an invalid range.

The variants of examples [P1] and [P2] (see 10.1.3.16.5) that involve rendering of audio or AV
content apply to this guideline.

10.1.3.20 MM op-param (Operations Parameter for HTTP)

10.1.3.20.1
[G UIDELINE ] If the 4th field is associated with the "http-get" transport protocol, then the a-val and
b-val tokens (of the op-param token) mean the following.

• a-val: indicates support of the TimeSeekRange.dlna.org HTTP header (see 11.4.3.23) for the
context of the protocolInfo under the "Full Random Access Data Availability" model.
• b-val: indicates support of the Range HTTP header (see 11.4.3.22) for the context of the
protocolInfo under the "Full Random Access Data Availability" model.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC SXQQ6

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline defines the op-param token's a-val and b-val tokens when HTTP is the
transport protocol.

When used with a context involving HTTP, the DLNA.ORG_OP parameter identifies if the server
supports the TimeSeekRange.dlna.org or Range HTTP headers for the associated content binary
under the "Full Random Access Data Availability" model.
For more information on the "Full Random Access Data Availability" model for HTTP and these
HTTP headers, see the following guidelines:

• 11.4.2.14 MT normative random access data availability models

• 11.4.2.15 MT Full Random Access Data Availability model
• 11.4.3.18 MT HTTP common random access data availability requirements
• 11.4.3.19 MT HTTP data range of Full Random Access Data Availability
The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.20.2
[G UIDELINE ] If the associated HTTP Server Endpoint returns HTTP error code 406 (Not Acceptable)
because an HTTP specifies one of the above HTTP headers, then the op-param shall indicate that
the HTTP header is not supported by using a value of "0" for the appropriate a-val or b-val.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC V8SUN

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 166 –

[C OMMENT] HTTP Server Endpoints use the 406 (Not Acceptable) status code to indicate that an
HTTP request can never be satisfied with the specified HTTP headers.

The following examples apply to this guideline: 9.2.11.1 and 9.2.11.6.

10.1.3.20.3
[G UIDELINE ] If the associated HTTP Server Endpoint always returns 406 (Not Acceptable) in
response to requests that use either HTTP header for the context of the protocolInfo, then the 4th
field shall omit the op-param.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC UW7RA

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] Including an op-param with a value of "00" is prohibited. In cases where neither the
TimeSeekRange.dlna.org nor the Range header are supported, the op-param is omitted.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2] .

10.1.3.20.4
[G UIDELINE ] If the associated HTTP Server Endpoint is capable of responding with a Target
Response that appropriately corresponds to the data range indicated in the HTTP request's
TimeSeekRange.dlna.org header value, then the a-val token shall be true.

(That is, the associated HTTP Server Endpoint does not return error code 406 (Not Acceptable),
unless other HTTP headers are the cause of the error.)

Lastly, the Content Source shall be able to support TimeSeekRange.dlna.org on the entire content
binary, as required by 10.1.3.19.2.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC PSOWQ

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] An HTTP Server that can respond with content data occupying a particular npt time
range needs to advertise this capability in the 4th field.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

“Appropriately corresponds” is clarified by 11.4.3.23.5 (MT HTTP Time-Based Seek (Server)),

which permits eturning data from a decoder-friendly point.

10.1.3.20.5
[G UIDELINE ] If the associated HTTP Server Endpoint is capable of responding with a Target
Response that corresponds exactly to the data range indicated in the HTTP request's Range header
value, then the b-val token shall be true.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 167 –

(That is, the associated HTTP Server Endpoint does not return error code 406 (Not Acceptable),
unless other HTTP headers are the cause of the error.)

Lastly, the Content Source shall support Range on the entire content binary, as required by
10.1.3.19.2.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 59OTH

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] An HTTP Server that can respond with content data occupying a particular byte range
needs to advertise this capability in the 4th field.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.20.6
[G UIDELINE ] If the associated HTTP Server Endpoint supports the realTimeInfo.dlna.org HTTP
header with a finite max-lag-time value (as described in 11.4.3.56.2), then

• the op-param shall be omitted,

• sp-flag = true,
• lop-bytes = false,
• lop-npt = false.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 6YPST

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2] .

10.1.3.21 MM op-param (Operations Parameter for RTP)

10.1.3.21.1
[G UIDELINE ] If the 4th field is associated with the "rtsp-rtp-udp" transport protocol, then the a-val
and b-val tokens (of the op-param token) mean the following.

• a-val: indicates support of the Range header (see 11.4.4.168 and 11.4.4.169) for the context of
the protocolInfo under the "Full Random Access Data Availability" model.
• b-val: In scenarios involving the RTP Media Transport, the b-val shall have a value of "0".
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 43WJU

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 168 –

[C OMMENT] For more information about the RTP Media Transport and the "Limited Random
Access Data Availability" model, see the following guidelines:

• 11.4.2.14 MT normative random access data availability models

• 11.4.2.15 MT Full Random Access Data Availability model
• 11.4.4.168 MT RTP Receiving Endpoint Range header
• 11.4.4.169 MT RTP Serving Endpoint Range header
The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.21.2
[G UIDELINE ] If the Content Source assigns "0" to both a-val and b-val of the op-param, then the
op-param shall be omitted from the 4th field.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC S5UX6

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.22 MM ps-param (Server-Side play-speeds parameter)

10.1.3.22.1
[G UIDELINE ] The definition of ps-param shall be as follows:

• ps-param = [ps-param-delim] "DLNA.ORG_PS=" ps-value

• ps-param-delim = ";"
• ps-value = [server-speed *("," server-speed)]
• server-speed = <conforms to the TransportPlaySpeed string, as specified in the AVTransport
specification>
The ps-value shall be a comma-delimited list of play-speed values. The ps-value shall exclude the
play-speed of "1" from its list. If the media transport component (either for a server, client) does not
support additional server-side play-speeds beyond "1" for the context of the protocolInfo, then the
fourth field shall omit the ps-param (i.e. "DLNA.ORG_PS=1" is prohibited).

The format of each play-speed value shall conform to the TransportPlaySpeed string, as specified in
ISO/IEC 29341-14-10, 2.2.8.

If used in conjunction with a protocolInfo indicating "http-get" in the first field, then the use of the
PlaySpeed.dlna.org HTTP header applies to the context of the protocolInfo. See 11.4.3.53 for more
information.

If used in conjunction with a protocolInfo indicating "rtsp-rtp-udp" in the first field, then the use of the
RTSP Scale header applies to the context of the protocolInfo. See 11.4.4.170 for more information.

If using the 4th_field syntax defined in 10.1.3.17.1 or 10.1.3.17.2 and if ps-param follows another
parameter, then the ps-param shall include the ps-param-delim.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 169 –

[ATTRIBUTES ]

M A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC XD3U5

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline defines the DLNA.ORG_PS parameter. The parameter indicates the
transport layer's supported play-speeds.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [P1], [P2],
[P3], and [P4]. The ps-param is not used for image content.

A ps-value can have "," characters as delimiters for supporting server-side play-speeds and the
DLNA guidelines defines a embedded comma escaping rule for a value of a CMS:GetProtocolInfo
response. Refer to 10.1.3.15.4 for more information.

Each of the play-speed values in ps-param is listed as an integer or as a ratio of two integer values.
It is highly recommended that implementers list play-speed values as close as possible to the actual
speed used in the distribution of the content. Specifically, implementers need to avoid the use of
rounding. For example, a speed value of 1,8× is represented as 9/5 and not rounded to 2. UPnP
control points use the speed value in ps-param to compute elapsed time. Rounding errors
accumulate quickly resulting in differences between the actual playtime and the value computed by
the UPnP control point. The computed value is typically displayed in the control point UI.

10.1.3.22.2
[G UIDELINE ] If the ps-param token appears in a res@protocolInfo or a protocolInfo of a UPnP AV
connection, and if the first field of protocolInfo is "http-get", then the Content Source shall be
capable of responding (with a Target Response) to requests that indicate a valid and supported
play-speed for the content binary.

(That is, the associated HTTP Server Endpoint does not return error code 406 (Not Acceptable),
unless other HTTP headers are the cause of the error.)

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a ISO/IEC 2U3HI

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] When used with a <res> element or UPnP AV connection, the DLNA.ORG_PS
parameter identifies whether the server supports one or more optional server-side play-speed
operations.

Guideline 11.4.3.53 describes more information about responding to HTTP requests that use the
PlaySpeed.dlna.org HTTP header.

Variants of the [C1] and [C2] examples that involve sources of audio and/or AV content apply to this
guideline.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 170 –

10.1.3.22.3
[G UIDELINE ] In conjunction with the rules defined in 10.1.3.22.1 and 10.1.3.22.2, the fourth field of
a res@protocolInfo may use the ps-param for non-DLNA Media Format Profiles.

[ATTRIBUTES ]

O A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC KQ9VQ

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline permits the use of DLNA.ORG_PS for both DLNA and non-DLNA
content. This guideline also permits the parameter to be used for HTTP and RTP and other
transports not specified by DLNA.

The following examples (see 10.1.3.16.5) apply to this guideline row: [C1], [C2], [C3], [C4], [P1],
[P2], [P3], and [P4]. Although the download usage does not employ play-speeds to achieve the
system usage in a normative way, control points that parse 4th field parameters need to tolerate the
presence of the ps-param.

CDS:CreateObject syntax has restrictions on the 4th field syntax, as described in 10.1.8.19.

10.1.3.23 MM ci-param (conversion indicator flag)

10.1.3.23.1
[G UIDELINE ] The syntax definition of ci-param shall be as follows:

• ci-param = ci-param-delim "DLNA.ORG_CI=" ci-value

• ci-param-delim = ";"
• ci-value = Boolean
• Boolean = "1" | "0"
If the context of the protocolInfo involves a content binary that is converted from a different content
binary, then ci-value is "1". Otherwise, the ci-value is "0". (See 10.1.3.12.8 for determining an
appropriate context.)

[ATTRIBUTES ]

M A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC RVR5L

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The ci-param is a conversion indicator parameter.

An MSCP uses this parameter to select the most relevant resource from the available resources of
a CDS object. If "1" is specified for this parameter value, then the resource is converted from a
different content binary. Converted content usually has equal or worse quality.
Examples of conversion include transcoding, system layer conversion, timestamps (e.g. TTS, PCR,
PTS), scaling, and decoding.

This guideline also applies in upload AnyContainer and optional content management (OCM)
operations. In those cases, a control point is responsible for setting this parameter when it knows
the content related to the operation is a converted content binary. This applies to content that is
DLNA guidelines; Part 1-1: Architecture and protocols
 – 171 –

intended for a content transfer process, as well as operations that involve a URI specified by the
control point.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [C5], [P1],
[P2], [P3], [P4], and [P5].

10.1.3.23.2
[G UIDELINE ] In conjunction with the rules defined in 10.1.3.23.1, the fourth field of a
res@protocolInfo may use ci-param for the following scenarios.

• The content is conformant to a DLNA Media Format Profile.

• The content is conformant to a non-DLNA Media Format Profile.
• The first field of protocolInfo is "http-get" or "rtsp-rtp-udp "
• The first field of protocolInfo is not "http-get" or "rtsp-rtp-udp "
[ATTRIBUTES ]

O A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC VR5L6

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline permits the use of DLNA.ORG_CI for both DLNA and non-DLNA content.
This guideline also permits the parameter to be used for HTTP and RTP and other transports not
specified by DLNA.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [C5], [P1],
[P2], [P3], [P4], and [P5].

10.1.3.23.3
[G UIDELINE ] If the UPnP MediaServer knows that the content of a <res> element is a converted
content binary, then the MediaServer should use the ci-param in the protocolInfo value.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC Q9VQY

29341-20-12

[C OMMENT] The ci-param is not mandatory, but its use is strongly encouraged, especially for
converted content.

How a Content Source knows if content is converted is out of scope for the guidelines. In some
cases, the Content Source knows because it is the entity that actually converts the content. In other
cases, the Content Source might know because the Content Source was informed in an
implementation-specific manner.

This guideline applies to MediaServers because of examples [C1] and [C2] (see 10.1.3.16.5).

10.1.3.23.4
[G UIDELINE ] The ci-param may be omitted.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 172 –

[ATTRIBUTES ]

O A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC U3HIZ

+DN+ +UP+ +PU+ M-DMC 29341-20-12

[C OMMENT] The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4],
[C5], [P1], [P2], [P3], [P4], and [P5].

10.1.3.23.5
[G UIDELINE ] If a protocolInfo value omits the ci-param, then UPnP MediaServer control points shall
infer that the associated content is not converted content.

[ATTRIBUTES ]

M A DMP DMC DMR +DN+ M-DMP M-DMC n/a ISO/IEC D3U5P

+UP+ +PU+ 29341-20-12

[C OMMENT] The following examples (see 10.1.3.16.5) apply to this guideline: [P1], [P2], [P3], [P4].

10.1.3.24 MM flags-param (flags parameter)

10.1.3.24.1
[G UIDELINE ] The syntax definition of the flags-param shall be as follows

• flags-param = flags-param-delim "DLNA.ORG_FLAGS=" flags-value

• flags-param-delim = ";"
• flags-value = primary-flags reserved-data
• primary-flags = 8 hexdigit
• reserved-data = 24 reserved-hexdigit
• hexdigit = <hexadecimal digit: "0"-"9", "A"-"F", "a"-"f">
• reserved-hexdigit = "0"
If the protocolInfo value omits the flags-param, then the default meaning for individual flags and
values embedded in flags-param is determined by default value policies or is unknown (in the case
where default values are not defined). As new flags and values are defined for flags-param, those
guidelines will clarify the meaning for when flags-param is omitted or when "0" is used.

Example

• DLNA.ORG_FLAGS=03100000000000000000000000000000.
[ATTRIBUTES ]

M A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC 5UX6U

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] Many DLNA binary-value flags that belong in the fourth field are encapsulated in this

DLNA guidelines; Part 1-1: Architecture and protocols

 – 173 –

parameter. This helps reduce the length of the 4th field as the number of binary-value parameters
increases in the future. In a simple usage, a single bit in the binary representation of flags-value
maps to a single binary-value parameter. In some cases, DLNA might choose to define that a series
of bits represents a small integer.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [P1], [P2],
[P3], and [P4].

10.1.3.24.2
[G UIDELINE ] The primary-flags token shall be exactly 8 hexadecimal digits, and it shall represent a
value composed of 32 binary bits. Each bit shall represent a binary flag. The least significant bit
corresponds to bit-0 and the most significant bit corresponds to bit-31 (e.g.
10000000000000000000000000000000b = 0x80000000 where bit-31 is the only bit set to true).

The bit mapping of primary-flags shall be as follows:

• Bit-31: sp-flag (Sender Paced flag)

– Applies to all DLNA transport protocols.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have a value of
unknown because sender-paced content and non sender paced content is permitted by
previous versions of the DLNA guidelines. Content Receivers that fail to transfer and/or
render content because they use transport flow control mechanisms are in violation of this
guideline.
– See the following for more information.
• 10.1.3.28 MM sp-flag (sender paced flag).
• Bit-30: lop-npt (Limited Operations flag: Time-Based Seek)
– Applies to all DLNA transport protocols.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have an inferred
value of false.
– See the following for more information.
• 10.1.3.29 MM lop-npt, lop-bytes and lop-cleartextbytes (limited operations flags):
Common.
• Bit-29: lop-bytes (Limited Operations flag: Byte-Based Seek)
– Applies to all DLNA transport protocols.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have an inferred
value of false.
– See the following for more information.
• 10.1.3.29 MM lop-npt, lop-bytes and lop-cleartextbytes (limited operations flags):
Common.
• Bit-28: playcontainer-param (DLNA PlayContainer flag)
– Applies to all DLNA transport protocols.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have an inferred
value of false because this flag applies only to DMR devices and the DLNA PlayContainer
URI operation is optional for DMR devices.
– See the following for more information.
• 10.1.3.32 MM playcontainer-param (DLNA PlayContainer flag)
• 10.1.4.26 MM rendering media collection files
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 174 –

• 10.1.4.29 MM DLNA PlayContainer URI

• 10.1.4.30 MM control point rules for DLNA PlayContainer URI.
• Bit 27: s 0 -increasing (UCDAM s 0 Increasing flag)
– Applies to all DLNA transport protocols.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then the s 0 -increasing flag shall
have an inferred value of unknown. The previous guidelines do permit s 0 -increasing behavior,
but the previous version of the DLNA guidelines (i.e. v1.0) do not define normative rules for
using the Seek media operation (or the Range or TimeSeekRange.dlna.org headers) with
such content.
– See the following for more information.
• 10.1.3.33 MM s0-increasing (UCDAM s0 increasing flag).
• Bit 26: s N -increasing (UCDAM s N Increasing flag)
– Applies to all DLNA transport protocols.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have an inferred
value of unknown because previous versions of the DLNA guidelines permit content that
grows with time or has a fixed ending.
– See the following for more information.
• 10.1.3.34 MM sN-increasing (UCDAM sN increasing flag).
• Bit-25: rtsp-pause (Pause media operation support for RTP Serving Endpoints)
– Applies only to RTP Media Transport
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have an inferred
value of false because previous versions of the DLNA guidelines do not support the RTP
Media Transport.
• Bit 24: tm-s (Streaming mode flag)
– Applies to all DLNA transport protocols.
– AV and Audio Media Class content shall set at least the tm-s flag equal to true.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have an inferred
value of true only for Audio-only and AV content. For all other content, the inferred value is
false.
– See the following for more information.
• 10.1.3.35 MM tm-s (Streaming Mode Transfer flag).
• Bit 23: tm-i (Interactive mode flag)
– Applies to all DLNA transport protocols.
– Image Media Class content shall set at least the tm-i flag equal to true.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have an inferred
value of true only for Image content and media collection files. For all other content, the
inferred value shall be false.
– See the following for more information.
• 10.1.3.36 MM tm-i (Interactive Mode Transfer flag).
• Bit 22: tm-b (Background mode flag)
– Applies to all DLNA transport protocols, except RTP.
– If the flags-param is omitted or the dlna-v1.5-flag is false, then this flag shall have an
unknown value.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 175 –

– See the following for more information.

• 10.1.3.37 MM tm-b (Background Mode Transfer flag)
• Bit 21: http-stalling (HTTP Connection Stalling flag)
– Applies only to the HTTP Media Transport.
– If the flags-param is omitted, then this flag shall have an inferred value of false.
– See the following for more information.
• 10.1.3.38 MM http-stalling (HTTP Connection Stalling flag)
• 10.1.4.7 MM DIDL-Lite Multiple Res: thumbnails.
• Bit 20: dlna-v1.5-flag (DLNA v1.5 versioning flag)
– Applies to all DLNA transport protocols.
– If the flags-param is omitted, then this flag shall have an inferred value of false.
– See the following for more information.
• 10.1.3.25 MM dlna-v1.5-flag (DLNAv1.5 version flag)
• Bit 16: LP-flag (Link Protected content flag)
– Applies to all DLNA transport protocols.
– If the flags-param is omitted then this flag shall have an inferred value of false.
– If the cleartextbyteseek-full flag or the lop-cleartextbytes-flag are set then this flag shall be
set to true
– See the following for more information.
• 7.5.3.5 in IEC 62481-3.
• Bit 15: cleartextbyteseek-full flag (Cleartext Byte Full Data Seek flag)
– Applies to all DLNA transport protocols.
– If the content described by this protocolInfo does not use a Link Protection system (i.e. the
LP-flag is false or omitted), the cleartextbyteseek-full flag shall be omitted or set to false.
– If the flags-param is omitted then the cleartextbyteseek-full flag shall have an inferred value
of false.
– See the following for more information.
• 7.5.3.6 (GUN TLQ89) in IEC 62481-3
(Byte based full seek data availability with the Cleartext Byte Seek Request Header).
• Bit 14: lop-cleartextbytes flag (Cleartext Limited Data Seek flag)
– Applies to all DLNA transport protocols.
– If the content described by this protocolInfo does not use a Link Protection System (i.e. the
LP-flag is false or omitted), the lop-cleartextbytes flag shall be omitted or set to false.
– If the dlna-v1.5 flag is false, then the lop-cleartextbytes flag shall have a value of false.
– If the flags-param is omitted then the lop-cleartextbytes flag shall have an inferred value of
false.
– See the following for more information.
• 7.5.3.7 (GUN RKJVW) in IEC 62481-3
(Byte based limited seek data availability with Cleartext Byte Seek Request Header).
All other bits in primary-flags are reserved for future use and shall have a value of false.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 176 –

[ATTRIBUTES ]

M C DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC 3WJUU

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The first 8 hexadecimal digits represent 32 binary flags. DLNA defines meaning for
some of these bits. Other bits are reserved for future definition and are required to have a value of
false at this time.
The usages of defined bits are defined in other DLNA guidelines.

When a protocolInfo represents the capabilities of a content binary, the bits are intended to be a
representation of the applicability to the content binary, not on the current conditions of the network
or the server's ability to stream data at the current time. When a stream is attempted on a content
binary with the tm-s flag set, the DMS is still free to return an error that the stream cannot be
completed at the current time due to internal conditions.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [P1], [P2],
[P3], and [P4]. In some cases, the flags-param will provide information that is of no use to certain
endpoints. However, endpoints that parse the 4th field are required to tolerate the presence of the
flags-param.

10.1.3.24.3
[G UIDELINE ] The reserved-data shall be exactly 24 hexadecimal digits. These hexadecimal digits
are reserved for future use and shall have a value "0".

[ATTRIBUTES ]

M C DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC YPSTR

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The first 8 hexadecimal digits are used for primary-flags and the rest are reserved and
undefined at this time.

When DLNA defines new normative flags and/or parameters for the 4th field, those flags and
parameters are expected to be defined here. The alternative of declaring a new 4th field parameter
is strongly discouraged for future authors of DLNA guidelines.

In general, definitions of new flags or parameters (that will occupy the current space allocated for
reserved-bytes) need to define a syntax and semantics for DMS, DMR, DMC, and Push Controllers.
Furthermore, parameter values that have short hexadecimal representations (such as new binary
flags) preferably occupy hexadecimal digits that are more significant while parameter values that
have longer hexadecimal representations occupy the less significant hexadecimal digits.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [P1], [P2],
[P3], and [P4].

10.1.3.24.4
[G UIDELINE ] UPnP AV MediaServer control points shall be tolerant of reserved-data tokens that do
not have "0" value hexadecimal digits.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 177 –

[ATTRIBUTES ]

M C DMP DMC DMR +DN+ M-DMP M-DMC n/a ISO/IEC 9OTHY

+UP+ +PU+ 29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The following examples (see 10.1.3.16.5) apply to this guideline: [P1], [P2], [P3], and
[P4].

10.1.3.25 MM dlna-v1.5-flag (DLNAv1.5 version flag)

[G UIDELINE ] If the dlna-v1.5-flag of the primary-flags token is true, then it shall mean the following.

• Bits [31,21] and Bits [16,14] (inclusive) of the primary-flags token are valid for use (i.e. those bits
are valid for use).
• Bits [19,17] and Bits [13,0] of the primary-flags token have undefined values.
If the dlna-v1.5-flag of the primary-flags token is false, then it shall mean the following.

• Only Bit-21 of the primary-flags token is defined for use.

• All other bits in the primary-flags token have inferred values as described in 10.1.3.24.2 (MM
flags-param (Flags Parameter)).
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a SOWQ7

[C OMMENT] Bits [31,22] and Bits [16,14] are not defined for previous versions of the DLNA
guidelines.
Bit-21 is the only bit defined in an erratum for the DLNA v1.0 guidelines.

10.1.3.26 MM maxsp-param (maximum RTSP Speed header value)

[G UIDELINE ] The definition of maxsp-param shall be as follows:

• maxsp-param = maxsp-param-delim "DLNA.ORG_MAXSP=" maxsp-param-value

• maxsp-param-delim = ";"
• maxsp-param-value = 1*DIGIT [ "." *DIGIT ]
The value of maxsp-param-value shall be greater than or equal to 1.

If maxsp-param is specified, then the RTP Serving Endpoint shall support the Speed header in a
RTSP PLAY request if the value of the "Speed" header is less than or equal to the attribute value of
maxsp-param. The RTSP "Speed" header is defined in IETF RFC 2326, 12.35.

[ATTRIBUTES ]

M A DMP DMS DMC DMR M-DMP M-DMS n/a IETF RFC W7RAO
+DN+ +UP+ +PU+ M-DMC 2326
ISO/IEC
29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 178 –

[C OMMENT] Excluding the variants that involve download, the following examples (see 10.1.3.16.5)
apply to this guideline: [C1] , [C2], [C3], [C4], [P1], [P2], [P3], and [P4]. Endpoints that parse 4th field
parameters need to tolerate the presence of this parameter.

10.1.3.27 MM other-param (vendor-defined 4th field parameters)

10.1.3.27.1
[G UIDELINE ] The definition of other-param is as follows:

• other-param = other-param-delim IANA-name "_" other-param-name "=" other-param-value

• other-param-delim = ";"
• IANA-name = <IANA-registered name, with top level domain (e.g. .net, .org, .com)>
• other-param-name = *<"a"-"z", "A"-"Z", "0"-"9">
• other-param-value = *<"a"-"z", "A"-"Z", "0"-"9", "_", ",", "+", "-">.
[ATTRIBUTES ]

M A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC 8SUNZ

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This defines the syntax for vendor extensions in the fourth field of protocolInfo values.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2] , [C3] , [C4], [P1], [P2], [P3],
and [P4].

10.1.3.27.2
[G UIDELINE ] Vendors may use other-param for vendor-specific parameters in the fourth field of a
protocolInfo value.

[ATTRIBUTES ]

O A DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC XQQ6Y

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline permits the use of vendor extensions in the fourth field.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [C5], [P1],
[P2], [P3], and [P4].

10.1.3.27.3
[G UIDELINE ] A UPnP AV MediaServer that receives a CDS:CreateObject request to create a <res>
element with a res@protocolInfo that has optional and/or vendor-defined 4th field parameters and if
the MediaServer returns a success response, then the MediaServer shall omit the unsupported 4th
field parameters from the created <res> element.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 179 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC QQ6YX

29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] DMS devices are not required to interpret, understand, store, or maintain
vendor-defined parameters in the 4th field.

This guideline is an extension of guideline 10.1.8.24.3, which requires a DMS to return only the
supported metadata properties in a success response.

The following examples (see 10.1.3.16.5) apply to this guideline: [P5]. As a corollary, control points
involved in example [C5] are expected to tolerate responses that omit unsupported 4th field
parameters.

10.1.3.28 MM sp-flag (sender paced flag)

10.1.3.28.1
[G UIDELINE ] The sp-flag indicates if the Content Source will act as the Clock Source, for the
context of the protocolInfo.

• False = The Content Source is not the Content Clock Source

• True = The Content Source is the Content Clock Source
[ATTRIBUTES ]

M C DMP DMS DMC DMR M-DMP M-DMS n/a ISO/IEC SUNZV

+DN+ +UP+ +PU+ M-DMC 29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The sp-flag provides a way for the Content Source to indicate that it will send packets
at the rate of the normal Clock Source.

In normal HTTP operation the Content Receiver endpoint is the source for the Playback Clock which
controls the pace of the rendering. The Content Receiver endpoint uses TCP flow control to match
the pace of the transfer of content to the pace of the playback. In some cases, the Content Source
might be the Content Clock Source, such as in the case of live broadcast content. This means that
if the actual throughput (including any transmission delays caused by additional transmission loads
on the network) is not sufficient for the Content Clock Source, then the Content Source will take
steps to ensure that the transmitted content binary matches the indicated Media Format Profile, but
the bitstream can show discontinuities such as dropped frames.
Likewise, in RTP the Serving Endpoint is typically the Clock Source and controls the rate at which
the content is sent to the network.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1], [C2], [C3], [C4], [P1], [P2],
[P3], and [P4].

10.1.3.28.2
[G UIDELINE ] In the context of SourceProtocolInfo values obtained from CMS:GetProtocolInfo for a
UPnP AV MediaServer, the sp-flag shall mean the following.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 180 –

• False = The Content Source is never the Content Clock Source for a protocolInfo when there is
a “match by protocolInfo format”.
• True = The Content Source is capable of being the Content Clock Source for a protocolInfo when
there is a “match by protocolInfo format”.
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 7RAO4

29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] Variants of the [C1] and [C2] examples that involve MediaServers apply to this
guideline (see 10.1.3.16.5).

10.1.3.28.3
[G UIDELINE ] In the context of SinkProtocolInfo values obtained from CMS:GetProtocolInfo for a
UPnP AV MediaRenderer, the sp-flag shall always be true or the flags-param shall be omitted.

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC OWQ7V

29341-14-10
ISO/IEC
29341-14-11

[C OMMENT] Like DMP devices, DMR devices are required to support rendering of content,
regardless of whether the Content Clock Source is determined by the Content Source.

10.1.3.28.4
[G UIDELINE ] When a Content Source streams live content and does not support any UCDAM
random access modes for that content, the Content Source shall set the sp-flag (Sender Paced Flag,
described in 10.1.3.28.1) to “true”.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 3HNHL N

[C OMMENT] Setting the sp-flag indicates that a Content Source will send packets based on the
clock of the live content source when streaming from the “live position” (see 10.1.3.33.2 or
11.4.2.16.2 for more information). Live content refers to content that is available only up to the “live
position” at any given time.

10.1.3.29 MM lop-npt, lop-bytes and lop-cleartextbytes (limited operations flags): Common

10.1.3.29.1
[G UIDELINE ] If the flags-param is present and any of the the lop-npt, lop-bytes, or
lop-cleartextbytes bits are true, then the "Limited Random Access Data Availability" model shall be
the data access model that applies in the context of the protocolInfo value and the op-param shall
be omitted from the 4th field of the protocolInfo value. In addition, for link protected content, the
cleartextbyteseek-full flag shall be false.

Specifically, this means that the transport operation (that is indicated by the lop-npt or lop-bytes or
lop-cleartextbytes) shall be supported for a limited data range for the context of the protocolInfo, as
defined in 11.4.2.16.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 181 –

The meaning of the lop-npt bit and the lop-bytes and lop-cleartextbytes flags are described in these
guidelines, depending on whether the context is for the HTTP Media Transport or the RTP Media
Transport.

• 10.1.3.30 MM lop-npt lop-bytes, and lop-cleartextbytes (limited operations flags): HTTP

• 10.1.3.31 MM lop-npt and lop-bytes (limited operations flags): RTP
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC OTHY2

29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] The lop-npt indicates that the transport layer supports random access on a limited
range of npt playback positions. Likewise the lop-bytes indicate that the transport layer supports
random access on a limited range of byte positions.The lop-cleartextbytes flag indicates that the
transport layer supports random access on a limited range of byte positions within the cleartext byte
domain.

A fundamental difference between lop-npt/lop-bytes/ lop-cleartextbytes and the op-param is that

lop-npt/ lop-bytes / lop-cleartextbytes assumes that s 0 can change, while op-param only permits
changes to s N . For additional information on the assumptions for the "Limited Random Access Data
Availability" model, see 11.4.2.16.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.29.2
[G UIDELINE ] Content Receiver endpoints or UPnP AV MediaServer control points that acquire
content data from a limited random access data range (defined in 11.4.2.16.1 shall be able to
properly request a valid range, even if the limited data range continuously changes with time.

[ATTRIBUTES ]

M A DMP DMR +DN+ M-DMP n/a ISO/IEC PSTRZ

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] Content receiver endpoints and control points cannot assume anything special about
the data range because the absolute beginning can change and the content can have no end (i.e.
live content). See the following for more general information and examples of how this guideline
applies to HTTP:

• 11.4.2.16 MT Limited Random Access Data Availability model

• 11.4.3.20 MT HTTP: data range of Limited Random Access Data Availability, Guidelines
11.4.3.20.2 and 11.4.3.20.10
The [P1], [P2], and [P3] examples (see 10.1.3.16.5) apply to the Content Receivers that are
governed by this guideline.

The server defines when "Limited Random Access Data Availability" applies to the scenario using
one or more of the lop-npt, lop-bytes and/or lop-cleartextbytes flags (see 10.1.3.24.2) in a content
binary’s res@protocolInfo 4th field
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 182 –

An HTTP Client Endpoint is required to support seek operations (see 10.1.6.31.1) on all supported
Media Format Profiles (see 11.4.3.52.1) regardless of the data availability model.

10.1.3.30 MM lop-npt lop-bytes, and lop-cleartextbytes (limited operations flags): HTTP

[G UIDELINE ] If the 4th field is associated with the "http-get" transport protocol, then the lop-npt,
lop-bytes and lop-cleartextbytes bits mean the following.

• lop-npt: indicates support of the TimeSeekRange.dlna.org HTTP header for the context of the
protocolInfo under the "Limited Random Access Data Availability" model.
• lop-bytes: indicates support of the Range HTTP header for the context of the protocolInfo under
the "Limited Random Access Data Availability" model.
• lop-cleartextbytes: indicates support of the Cleartext Byte Seek Request Header for the context
of the protocolInfo under the "Limited Random Access Data Availability" model.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC WJUUP

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] This guideline defines the lop-npt, lop-cleartextbytes and lop-bytes bits, when HTTP is
the transport protocol.
When used with a context involving HTTP, these bits identify if the server supports the
TimeSeekRange.dlna.org or Range HTTP headers or the Cleartext Byte Seek Request Header for
the associated content binary under the "Limited Random Access Data Availability" model.

For more information on the "Limited Random Access Data Availability" model for HTTP and these
HTTP headers, see the following guidelines:

• 11.4.2.16 MT Limited Random Access Data Availability model

• 11.4.3.18 MT HTTP common random access data availability requirements
• 11.4.3.20 MT HTTP: data range of Limited Random Access Data Availability
And the following guideline in IEC 62481-3:

• Clause A.5.
The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.31 MM lop-npt and lop-bytes (limited operations flags): RTP

[G UIDELINE ] If the 4th field is associated with the "rtsp-rtp-udp" transport protocol, then the lop-npt
and lop-bytes bits mean the following.

• lop-npt: indicates support of the Range header for the context of the protocolInfo under the
"Limited Random Access Data Availability" model.
• lop-bytes: In scenarios involving the RTP Media Transport, the lop-bytes bit shall be set to false.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC UX6UW

2616
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
DLNA guidelines; Part 1-1: Architecture and protocols
 – 183 –

[C OMMENT] This guideline defines the lop-npt and lop-bytes bits, when RTP is the transport
protocol.
When used with a context involving RTP, these bits identify if the server supports the Range header
for the associated content binary under the "Limited Random Access Data Availability" model.

For more information on the "Limited Random Access Data Availability" model for RTP and these
RTP headers, see the following guidelines:

• 11.4.2.16 MT Limited Random Access Data Availability model

• 11.4.4.181 MT RTP current limited data range indication
The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.32 MM playcontainer-param (DLNA PlayContainer flag)

10.1.3.32.1
[G UIDELINE ] The playcontainer-param flag indicates support for a DLNA PlayContainer URI
operation. If the flag is true for a protocolInfo, then it means that the UPnP AV MediaRenderer can
play that type of content in a DLNA PlayContainer URI operation.

The playcontainer-param flag shall be false when the context of the protocolInfo involves media
collection binaries (e.g. DIDL_S and DIDL_V playlist files). Furthermore, when performing a DLNA
PlayContainer URI, the MediaRenderer shall not render media collection binaries when traversing
the CDS hierarchy. Note that this restriction against playing media collection binaries applies only to
media collection binaries defined by the DLNA guidelines.

[ATTRIBUTES ]

M A DMR DMC +PU+ M-DMC n/a ISO/IEC 3U5PA

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] A DLNA PlayContainer URI allows a control point to instruct a DMR to browse a DMS
and play content from it.
The playcontainer-param is used on a per-profile basis. For example, if the protocolInfo for
"http-get" and "MPEG2_PS_NTSC" has playcontainer-param set to true, then MPEG2_PS_NTSC
content will be played in playcontainer operation.

Example [C4] also applies to this guideline.

This guideline also applies to DMR devices because they can expose protocolInfo that has the
playcontainer-param set to true through CMS:GetProtocolInfo.

This guideline also applies to control points that invoke CMS:GetProtocolInfo on a DMR because
they have to parse 4th field values.

Since the res@dlna:trackTotal attribute is not required, there is not a consistent way to represent
the individual tracks of media collection binaries. Furthermore, DLNA has no interoperability
guidelines for navigating the tracks within a media collection binary. Therefore, these guidelines
prohibit playback of media collection binaries until a future set of DLNA guidelines can adequately
address these issues.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 184 –

10.1.3.32.2
[G UIDELINE ] In the context of the Source argument's protocolInfo values obtained from
CMS:GetProtocolInfo for a UPnP AV MediaServer, the playcontainer-param flag shall always be
false if the flags-param is included for a protocolInfo value.

Likewise, 4th field values provided by a Content Source shall set the playcontainer-param flag to
false if the flags-param is included in the protocolInfo value.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC 3HIZ9

29341-14-11

[C OMMENT] The DMR device class is the only device class that sets the playcontainer-param to
true.

The following examples (see 10.1.3.16.5) apply to this guideline: [C1] and [C2].

10.1.3.33 MM s 0 -increasing (UCDAM s 0 increasing flag)

10.1.3.33.1
[G UIDELINE ] The s 0 -increasing indicates if the UCDAM s 0 boundary is increasing.

• True = The s 0 data boundary increases with time.

• False = The s 0 data boundary is fixed.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC 9VQYF

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] If true, then the content does not have a fixed beginning. Otherwise, the content does
have a fixed beginning (i.e. npt=0 and byte-pos=0 map to the beginning). Note that the s 0 data
boundary can reset, as described in the comments 11.4.2.16 guideline 11.4.2.16.3.

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

10.1.3.33.2
[G UIDELINE ] If the s 0 -increasing flag is true then the following shall apply to the context of the
protocolInfo.

• The op-param shall be omitted.

• If lop-npt and lop-bytes are both false, then the following shall also apply:
o The s 0 data boundary shall map to a beginning that is not static.
o The data range of [s 0 , s N ] shall map to the npt range of [npt-start-time, npt-last-time]
and the byte range of [first-byte-pos, last-byte-pos], where npt-start-time and
npt-last time are in units of npt and first-byte-pos and last-byte-pos are in bytes.
o There exists a "live position" that shall be equal to the s N data boundary.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 185 –

• If the s N data boundary is changing with time, then the "live position" shall shift forward in
real-time.
• If the Content Source receives a transport layer request that is not a random access request (e.g.
HTTP request that omits Range and TimeSeekRange.dlna.org) then the Content Source shall
respond with content data from the "live point".
• If either lop-npt or lop-bytes is true, then the "Limited Random Access Data Availability" model
shall apply. See 11.4.2.16 for more information.
The rules in this guideline shall apply even in scenarios where the transport server does not support
random access requests (e.g. HTTP requests with Range or TimeSeekRange.dlna.org) for a
content binary.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC R5L6Y

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] When s 0 -increasing is true, then the content binary has a beginning that can change.
Since it is possible to set the s 0 -increasing flag to true and not support random access requests, it
is necessary for this guideline to be applied in all scenarios.
For HTTP, this means that omitting the Range and TimeSeekRange.dlna.org headers in an HTTP
GET request results in the HTTP Server Endpoint returning content data bytes from a "live position"
(as described in 11.4.3.20.9). Furthermore npt = 0 or byte-pos = 0 has no meaning (as described by
11.4.3.20.16).

If lop-npt or lop-bytes is true, then the access model is governed by what is returned by
availableSeekRange.dlna.org (as described in 11.4.3.19.10).

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

10.1.3.33.3
[G UIDELINE ] If the s 0 -increasing flag is false, then the following shall apply to the context of the
protocolInfo.

• The s 0 data boundary shall map to a fixed and non-changing beginning.

• The data range of [s 0 , s N ] shall occupy an npt range of [0, npt-last-time] and a byte range of [0,
last-byte-pos], where npt-last-time is in npt and last-byte-pos is in bytes.
• The content binary's zero position (i.e. npt-time = 0 and byte-pos = 0) shall map to the UCDAM's
data position of s 0 .
• The last-byte-pos and npt-last-time shall map to the UCDAM's s N data position and the s N data
boundary shall map to the end of the available content data.
This guideline shall apply even in scenarios where the transport server does not support random
access requests (e.g. HTTP requests with Range or TimeSeekRange.dlna.org) for a content binary.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 5L6YK

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 186 –

[C OMMENT] When s 0 -increasing is false, then the content binary has a fixed beginning. Since it is
possible to set the s 0 -increasing flag to false and not support random access requests, it is
necessary for this guideline to be applied in all scenarios.
For HTTP, this guideline means that HTTP requests that omit the Range and
TimeSeekRange.dlna.org headers results in the HTTP Server Endpoint returning content data from
the absolute beginning of the content (as described in 11.4.3.19).

These assumptions and the required behavior are consistent with assumptions of previous versions
of the DLNA guidelines.

s 0 -increasing = false permits mutually exclusive use of either the op-param or the lop-npt/lop-bytes
with values of true, while s 0 -increasing = true prohibits use of the op-param but allows use of lop-npt
and lop-bytes.

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

10.1.3.33.4
[G UIDELINE ] In the context of Sink argument's protocolInfo values obtained from
CMS:GetProtocolInfo for a UPnP AV MediaRenderer, the s 0 -increasing flag shall always be true or
the flags-param shall be omitted.

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC VQYFH

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] Like DMP devices, DMR devices are required to support normal playback rendering of
content, regardless of the server's buffering model.

10.1.3.34 MM s N -increasing (UCDAM s N increasing flag)

10.1.3.34.1
[G UIDELINE ] The s N -increasing indicates if the UCDAM s N boundary is increasing.

• True = The s N data boundary increases with time.

• False = The s N data boundary is fixed.
This flag applies regardless of whether the "Full Random Access Data Availability" or "Limited
Random Access Data Availability" model is being used.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC HIZ9G

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12

[C OMMENT] If true, then the content does not have a fixed ending. Otherwise, the content has a
fixed ending.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 187 –

In conjunction with 10.1.3.33, it is possible to determine whether the server exhibits a growing or
sliding buffering model.

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

10.1.3.34.2
[G UIDELINE ] In the context of SinkProtocolInfo values obtained from CMS:GetProtocolInfo for a
UPnP AV MediaRenderer, the s N -increasing flag shall always be true or the flags-param shall be
omitted.

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC U5PAG

29341-14-10
ISO/IEC
29341-14-11

[C OMMENT] Like DMP devices, DMR devices need to support normal playback rendering of content,
regardless of the server's buffering model.

10.1.3.35 MM tm-s (Streaming Mode Transfer flag)

10.1.3.35.1
[G UIDELINE ] If the tm-s flag is true, then the associated Media Transport Content Source shall be
capable of supporting the Streaming Mode Transfer for the context of protocolInfo.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a X6UW9

[C OMMENT] See Table 40 for more information about Streaming Mode Transfer.

Content Sources can generate an error response if it does not have the resources to respond at the
current time.

The tm-s flag is not equivalent to the sp-flag. When the tm-s flag is true, it means that the Content
Source is able to transmit fast enough for immediate rendering. If the sp-flag is false and the
sustained throughput is less than what is needed for immediate rendering, then the Content Source
will preserve the content binary's bitstream because the Content Source does not act as the Clock
Source.

When the sp-flag is also true, it means that the Content Source is also the Clock Source for the
content, which means that the Content Source will take steps to ensure that the content binary
meets the expectations of the Media Format Profile, but the rendering stream can have
discontinuities (such as dropped frames).

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

10.1.3.35.2
[G UIDELINE ] The tm-s flag shall be set to true for protocolInfo values where the pn-param indicates
a Media Format Profile for audio-only or AV Media Class. Setting the tm-s flag to true for Images or
media collection binaries is expressly prohibited.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 188 –

This requirement does not apply in scenarios where a res@protocolInfo value exists for a <res>
element that does not have a URI value. (That is, a CDS object that was created in an upload
AnyContainer operation and has yet to receive the actual content binary.)

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a JUUPX

[C OMMENT] This ensures backwards compatibility with earlier DMP devices that always assume
that audio-only and AV content is available for streaming.

See guideline 11.4.2.3.1 (MT Transfer Mode Support) for information on the transfer modes that a
Content Receivers can specify when issuing requests.

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

10.1.3.36 MM tm-i (Interactive Mode Transfer flag)

10.1.3.36.1
[G UIDELINE ] If the tm-i flag is true, then the associated Media Transport Content Source shall be
capable of supporting the Interactive Mode Transfer for the context of protocolInfo.

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a STRZQ

[C OMMENT] See Table 40 for more information about Interactive Mode Transfer.

Content Sources can generate an error response if it does not have the resources to respond at the
current time.

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

10.1.3.36.2
[G UIDELINE ] The tm-i flag shall be set to true for protocolInfo values where the pn-param indicates
a Media Format Profile for the Image Media Class or a media collection binary. Setting the tm-i flag
to true for Audio-only or AV content is expressly prohibited.

This requirement does not apply in scenarios where a res@protocolInfo value exists for a <res>
element that does not have a URI value. (That is, a CDS object that was created in an upload
AnyContainer operation and has yet to receive the actual content binary.)

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a THY23 C

[C OMMENT] This ensures backwards compatibility with earlier DMP devices that always assume
that image content is available for immediate rendering.

See guideline 11.4.2.3.1 (MT Transfer Mode Support) for information on the transfer modes that
Content Receivers can specify when issuing requests.

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 189 –

10.1.3.37 MM tm-b (Background Mode Transfer flag)

[G UIDELINE ] If the tm-b flag is true, then the associated HTTP server shall be capable of supporting
the Background Mode Transfer for the context of the protocolInfo.

In the context of a UPnP AV Connection, a res@protocolInfo value, or contentFeatures.dlna.org

value, the following restrictions shall also apply.

• If the http-stalling flag is true, then tm-b flag shall be set to true.
• If the sp-flag is true, then tm-b flag shall be false.
[ATTRIBUTES ]

M A DMS M-DMS n/a n/a WQ7V6

[C OMMENT] See Table 40 for more information about Background Mode Transfer.

Content Sources can generate an error response if it does not have the resources to respond at the
current time.

Unlike the tm-s and tm-i flags, the tm-b flag can be used with all Media Classes.

A server that supports the http-stalling flag will also support the tm-b flag because a device that
supports indefinite stalling implicitly supports lower transmission throughputs that can result from
actively managing TCP flow control for a Background transfer. The converse is not true becase the
ability to support a Background transfer does not necessarily imply the ability to support indefinite
stalling via TCP flow control.

Background transfer cannot be used in conjunction with server-paced content. Lower transmission
throughputs resulting from a Background transfer can cause the server's buffer to overflow. Content
Receivers that want to download content that have sp-flag = true need to use the streaming
download media operation.

See guideline 11.4.2.3.1 (MT Transfer Mode Support) for information on the transfer modes that a
Content Receivers can specify when issuing requests.

The [C1] and [C2] examples (see 10.1.3.16.5) apply to this guideline.

10.1.3.38 MM http-stalling (HTTP Connection Stalling flag)

[G UIDELINE ] If the http-stalling flag is true, then the associated HTTP server shall be capable of
supporting the Connection Stalling method for the Pause and Pause-Release media operations on
the content binary and in addition the sp-flag shall be false.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a RAO4V

[C OMMENT] The Connection Stalling is a mechanism where a Content Receiver and a Content
Source cooperatively use standard TCP flow control to temporarily pause the transmission of data.

HTTP Server Endpoints are not to misinterpret HTTP-level transport inactivity as a symptom of a
TCP disconnect because a properly stalled HTTP Client Endpoint will use standard TCP flow control
to keep the TCP connection alive. HTTP Server Endpoints also need to be careful to not overflow
their local network buffers when theConnection Stalling method is being used.

The [C1] and [C2] examples apply to this guideline when the scenario involves audio or AV content.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 190 –

10.1.3.39 MM UPnP AV connection behaviors

10.1.3.39.1
[G UIDELINE ] A UPnP AV MediaServer shall have a connection with a ConnectionID "0" to represent
all transport layer connections that cannot be mapped to a particular transport layer connection.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC UNZVD

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] A UPnP AV MediaServer that implements this type of behavior uses ConnectionID "0"
to represent one or more transport layer connections. Specifically, UPnP AV MediaServers are
required to have at least one UPnP AV connection with ConnectionID of "0" to represent an
unknown number of connections (zero or more) to Content Receivers.

10.1.3.39.2
[G UIDELINE ] A UPnP AV MediaRenderer shall have a connection with a ConnectionID value of "0"
to represent the default connection whose access is always available to any UPnP AV
MediaRenderer control point in the network.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC RBWYA

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] UPnP AV MediaRenderers maintain a default connection that can be accessed at any
time by any networked UPnP AV MediaRenderer control point (DMC, M-DMC, +PU+). A
ConnectionID value of "0" identifies this default connection.

10.1.3.40 MM Context of ConnectionID=0

10.1.3.40.1
[G UIDELINE ] UPnP AV MediaServer control points shall not rely on the accuracy of the ProtocolInfo
and PeerConnectionManager output parameters from a CMS:GetCurrentConnectionInfo request to
a UPnP AV MediaServer with a value of "0" for the ConnectionID input.

[ATTRIBUTES ]

M A DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC Q6YXR

+UP+ 29341-14-11

[C OMMENT] In the case of the UPnP AV connection "0", the information is assumed to be
inaccurate because the context of ConnectionID = "0" represents numerous requests for different
content. For example, the same ConnectionID of value "0" can be used for simultaneously serving
an image and an audio stream. Each of the media resources served in this scenario will have its own
protocolInfo.

10.1.3.40.2
[G UIDELINE ] When a UPnP AV MediaRenderer responds to a CMS:GetCurrentConnectionInfo
request, the value of the ProtocolInfo output argument shall contain information that corresponds to
the URI in the AVT.CurrentTrackURI virtual instance state variable of the corresponding
DLNA guidelines; Part 1-1: Architecture and protocols
 – 191 –

AVTransport virtual instance. The corresponding AVTransport virtual instance has an InstanceID
equal to the value of the AVTransportID output argument of the same response.

If content has been assigned to the AVTransport virtual instance (i.e. the corresponding
AVT.CurrentTrackURI virtual instance state variable is not equal to the empty string), the value of
the ProtocolInfo output argument to the CMS:GetCurrentConnectionInfo request shall at least
include the Primary protocolInfo Set that describes the content.

If content has not been assigned yet to the AVTransport virtual instance (i.e. the corresponding
AVT.CurrentTrackURI virtual instance state variable equals the empty string), the value of the
ProtocolInfo output argument to the CMS:GetCurrentConnectionInfo request shall be an empty
string.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC R2JS7

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] UPnP AV MediaRenderers always include the proper ProtocolInfo value when
responding to CMS:GetCurrentConnectionInfo requests.

10.1.3.41 MM UPnP AV Connection ID and Instance ID assignment rules

10.1.3.41.1
[G UIDELINE ] UPnP AV MediaServers and UPnP AV MediaRenderers may include non-zero
ConnectionID values in addition to the zero value in the CMS.CurrentConnectionIDs state variable.

[ATTRIBUTES ]

O C DMS DMR M-DMS n/a ISO/IEC 6YXRZ

29341-14-11
ISO/IEC
29341-3-2
ISO/IEC
29341-20-3

[C OMMENT] Typically, UPnP AV MediaServers and UPnP AV MediaRenderers include only the
value of 0 when responding to CMS:GetCurrentConnectionIDs. However, devices that implement
CMS:PrepareForConnection and/or DLNA BCM guidelines will respond with a list that includes
additional non-zero ConnectionID values.

10.1.3.41.2
[G UIDELINE ] If a UPnP AV MediaServer does not implement the AVTransport service, then it shall
return the value of "−1" for the AVTransportID argument in the CMS:GetCurrentConnectionInfo
action.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC AO4VF

29341-14-10
ISO/IEC
29341-14-11

[C OMMENT] This is normative per the UPnP AV specifications. The CMS:PrepareForConnection

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 192 –

and CMS:GetCurrentConnectionInfo actions return the AVTransport service virtual instance ID

value through the AVTransportID output argument.

10.1.3.41.3
[G UIDELINE ] A UPnP AV MediaRenderer shall return the value of "0" in the AVTransportID and
RcsID arguments in response to a CMS:GetCurrentConnectionInfo request where the ConnectionID
argument has the value of "0".

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC Q7V6G

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-3-2

[C OMMENT] Guidelines 10.1.6.2 and 10.1.6.3 require the "default" virtual instances to be always
present in the AVTransport and RenderingControl services. This guideline further requires these
"default" virtual instances to be always associated with the "default" connection of the Connection
Manager service.

10.1.3.41.4
[G UIDELINE ] UPnP AV MediaServer and UPnP AV MediaRenderer value for the
CMS.CurrentConnectionIDs state variable shall be a comma-separated list of all current
ConnectionID values.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC B8T5G

29341-14-11
ISO/IEC
29341-3-2
ISO/IEC
29341-20-3

[C OMMENT] Implementing support for the action CMS:GetCurrentConnectionIDs is a requirement

for UPnP AV MediaServers and UPnP AV MediaRenderers. By default, one connection is always
available. This default connection is identified with a ConnectionID value of 0.

10.1.3.41.5
[G UIDELINE ] A UPnP AV MediaServer and a UPnP AV MediaRenderer shall respond to
CMS:GetCurrentConnnectionIDs requests. The ConnectionIDs output argument value shall have
the same value as the CMS.CurrentConnectionsIDs state variable.

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC I9O4R

29341-14-11
ISO/IEC
29341-3-2
ISO/IEC
29341-20-3

10.1.3.41.6
[G UIDELINE ] UPnP AV MediaServers and UPnP AV MediaRenderers shall include a ConnectionID
value of zero in the CMS.CurrentConnectionIDs state variable.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 193 –

[ATTRIBUTES ]

M C DMS DMR M-DMS n/a ISO/IEC BWYAJ

29341-14-11
ISO/IEC
29341-3-2
ISO/IEC
29341-20-3

[C OMMENT] Guideline requirements 10.1.3.39.1 and 10.1.3.39.2 require that UPnP AV

MediaServers and UPnP AV MediaRenderers always have a default connection with ConnectionID
"0". This guideline indicates that this value needs to be included in the CMS.CurrentConnectionIDs
state variable.

10.1.3.41.7
[G UIDELINE ] A UPnP AV MediaServer shall return the value of "−1" for the RcsID argument in the
CMS:GetCurrentConnectionInfo action.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 2JS7H

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] This guideline is a requirement repeated from ISO/IEC 29341-14-11. The

CMS:PrepareForConnection and CMS:GetCurrentConnectionInfo actions return the
RenderingControl service virtual instance ID value through the RcsID output argument.

10.1.4 MediaServer requirements

10.1.4.1 MM ObjectID usage
10.1.4.1.1
[G UIDELINE ] UPnP AV MediaServers shall assign a unique object ID for each entry in their
ContentDirectory service (CDS). This rule applies to both container and item objects in a CDS
metadata hierarchy.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC TRZQR

29341-20-12

[C OMMENT] This guideline is a requirement repeated from ISO/IEC 29341-20-12. This guideline's
scope for uniqueness is for the entire CDS hierarchy.

10.1.4.1.2
[G UIDELINE ] UPnP AV MediaServers should maintain the object ID value on a persistent basis.

[ATTRIBUTES ]

S L DMS M-DMS n/a ISO/IEC UUPXM

29341-20-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 194 –

[C OMMENT] The purpose of this recommendation is to allow control points to implement features
like "my favorite content". Although control points cannot assume that object ID values are persisted,
this recommendation allows a control point to easily check if a CDS object is still available on the
network.

The reason why this is not mandatory is that some embedded devices can have difficulty in
persisting object ID values across device reboots.

10.1.4.1.3
[G UIDELINE ] A UTF-8 encoded object ID shall not exceed 256 B in the XML escaped form encoded
in UTF-8.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC 6UW9O

29341-20-12

[C OMMENT] Provides a reasonable maximum length for objectID values, which are essential for
CDS object declarations.

This guideline only applies to the creation of object ID values.

10.1.4.1.4
[G UIDELINE ] DIDL-Lite documents or fragments that contain one or more CDS objects (i.e. <item>
or <container> element) shall have a unique value for each object's @id attribute.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC IZ9GG

29341-20-12

[C OMMENT] This is a requirement of the CDS specification. This guideline's scope for uniqueness
is limited to the DIDL-Lite document or fragment. For example, a UPnP AV MediaRenderer that
reports metadata for a media collection cannot use the same object ID for each of the items in the
media collection.

10.1.4.2 MM CDS:Browse unsorted order

[G UIDELINE ] If a UPnP AV MediaServer responds to a CDS:Browse request that specifies
BrowseFlag = BrowseDirectChildren and an empty SortCriteria argument, then the MediaServer
shall preserve the indexed order of returned CDS objects for a given UpdateID output argument
value.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC QYFH2

29341-20-12

[C OMMENT] This requirement is implied in the CDS specification because the StartingIndex and
RequestedCount input arguments are designed for incrementally browsing a CDS container. The
only time when the unsorted order can be different between two CDS:Browse requests will be when
the UpdateID output argument values are different in the two responses.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 195 –

10.1.4.3 MM Exposing CDS Content Rule

[G UIDELINE ] A UPnP AV MediaServer shall not expose a CDS object for a content binary that it
cannot identify as a Mandatory Media Format Profile or expose as Converted Content into a
Mandatory Media Format Profile (per 10.1.4.4.2) except when the UPnP AV MediaServer is
interacting with a UPnP AV MediaServer control point implemented to a version of the DLNA
protocol before 4.0.

A UPnP AV MediaServer control point implemented to a version of the DLNA protocol shall be as
defined in 9.2.32.2.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC F8SCI N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline mandates that at least one <res> element in the CDS object is identified
with a Mandatory Media Format Profile ID. An exception is to this guideline is when interacting with
legacy UPnP AV MediaServer control points.

This guideline allows a UPnP AV MediaServer to expose a <res> element of a CDS object in a
format for which there is no matching DLNA Media Format Profile provided that for interoperability
purpose this CDS object also features at least one other <res> element in a Mandatory Media
Format Profile.

As an example, an audio asset for which there is no matching DLNA Media Format Profile could be
exposed through a CDS object featuring the two following <res> elements:

• A <res> element using the LPCM DLNA Media Format Profile, for interoperability purpose
• A <res> element without any DLNA Media Format Profile, featuring the appropriate MIME type
for the audio asset.
10.1.4.4 MM DIDL-Lite Multiple Res: Formats
10.1.4.4.1
[G UIDELINE ] If exposing the same content in different Media Format Profiles, then the different
Media Format Profiles shall be exposed through multiple <res> elements in a single CDS object.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC L6YK5 C

29341-20-12

[C OMMENT] This guideline mandates a UPnP AV MediaServer device to expose multiple <res>
elements for a single CDS object. This allows a UPnP AV MediaServer control point to present a
single CDS object to the user, without necessarily presenting each variant of the same content.

This guideline will enable a UPnP AV MediaRenderer to have access to all <res> elements during
content playback to selected an alternative content variant that it can actually playback.

This guideline applies when the DMS can determine that content binaries contain the same content.
The following are some examples of how multiple <res> elements can be used.

• The DMS acquired the content binaries in such a way that it knows that they are the same
content.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 196 –

• The DMS has transcoded locally stored content to other formats.

• The DMS advertises tuner-sourced content in multiple Media Format Profiles.
• The DMS has a single, locally stored file that is advertised with multiple Media Format Profiles,
without any conversions.
• The DMS advertise the same video or image content (even when the Media Format Profile is the
same) but in different resolutions.
This requirement does not require a DMS to determine whether separate, locally stored files contain
actually the same content because this is difficult to do computationally and relying on embedded
metadata is not always accurate. Furthermore, a DMS is not required to determine that content
binaries uploaded through multiple upload AnyContainer or OCM: upload content operations
requests comprise the same content.

This guideline is required because the MediaServer can always determine if it is providing a content
transformation (Converted Content).

10.1.4.4.2
[G UIDELINE ] A CDS object item marked as an object.item.imageItem or any of its derived classes
shall contain at least one <res> element that represents an Image Media Class Mandatory Media
Format Profile. Within the context of this guideline the Image Media Class DLNA Mandatory Media
Format Profiles shall be as defined in guideline 6.2.1 (GUN 69K5T) in IEC 62481-2

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 6RDIF N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline mandates that a UPnP AV MediaServer exposes an alternate <res>
element in an Image Media Class Mandatory Media Format Profile to improve content playback
interoperability.

10.1.4.4.3
[G UIDELINE ] A CDS object item marked as an object.item.audioItem or any of its derived classes
shall contain at least one <res> element that represents an Audio Media Class Mandatory Media
Format Profile.

Within the context of this guideline the Audio Media Class DLNA Mandatory Media Format Profiles
shall be as defined in guideline 6.2.3 (GUN Q77AY) in IEC 62481-2

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC U7XHF N

29341-20-12
IEC 62481-2

[C OMMENTS ] This guideline mandates that a UPnP AV MediaServer exposes an alternate <res>
element in an Audio Media Class Mandatory Media Format Profile to improve content playback
interoperability.

10.1.4.4.4
[G UIDELINE ] A CDS object item marked as an object.item.videoItem or any of its derived classes
shall contain at least one <res> element that represents an AV Media Class Mandatory Media
Format Profile.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 197 –

Within the context of this guideline the AV Media Class DLNA Mandatory Media Format Profiles
shall be as defined in guideline 6.2.5.2 (GUN QOSMM), 6.2.5.3 (GUN FHMVO), 6.2.5.4 (GUN
OMCJY), 6.2.5.5 (GUN ZV5D5) and 6.2.5.6 (GUN E6DI6) in IEC 62481-2.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC O6RKQ N

29341-20-12
IEC 62481-2

[C OMMENTS ] This guideline mandates that a UPnP AV MediaServer exposes an alternate <res>
element in an AV Media Class Mandatory Media Format Profile to improve content playback
interoperability.

10.1.4.4.5
[G UIDELINE ] If the native content binary contains an HD video component, then a CDS object
exposing AV Media Class content shall contain at least one <res> element that represents an HD
Mandatory Media Format Profile as defined in guideline 6.2.5.3 (GUN FHMVO) and 6.2.5.5 (GUN
ZV5D5) in IEC 62481-2.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 377QS N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline mandates that a UPnP AV MediaServer expose an alternate <res>
element in an HD Mandatory Media Format Profile for any HD native content so an HD mandatory
variant is available to an HD Capable Device for rendering.

This is in addition to exposing the content in the Mandatory Media Format Profile as defined in
10.1.4.4.2

10.1.4.4.6
[G UIDELINE ] If the native content binary contains an UHD video component, then a CDS object
exposing AV Media Class content shall contain at least one <res> element that represents an UHD
Mandatory Media Format Profile as defined in guideline 6.2.5.6 (GUN E6DI6) in IEC 62481-2.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC Y62MY N

29341-20-12
IEC 62481-2

[C OMMENTS ]

a) This guideline mandates that a UPnP AV MediaServer expose an alternate <res> element in
an UHD Mandatory Media Format Profile for any UHD native content so an UHD mandatory
variant is available to an UHD Capable Device for rendering.

b) This is in addition to exposing the content in the Mandatory Media Format Profile as defined
in 10.1.4.4.2.

c) This is in addition to exposing the content in the HD Mandatory Media Format Profile as
defined in 10.1.4.4.3.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 198 –

10.1.4.4.7
[G UIDELINE ] When a UPnP AV MediaServer is interacting with a UPnP AV MediaRenderer that
belongs to the HND Device Category and is implemented to a version of the DLNA protocol before
4.0, a CDS object item marked as an object.item.audioItem or any of its derived classes shall
contain at least one <res> element that conforms to the LPCM Audio Format Profile as defined in
guideline 8.5 of IEC 62481-2.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC LQURR N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline mandates that a UPnP AV MediaServer exposes an alternate <res>
element in an Audio Media Class Media Format Profile supported by UPnP AV MediaRenderers that
belong to the HND Device Category and implement to a version of the DLNA protocol before 4.0, to
improve content playback interoperability.

10.1.4.4.8
[G UIDELINE ] When a UPnP AV MediaServer is interacting with a UPnP AV MediaRenderer that
belongs to the MHD Device Category and is implemented to a version of the DLNA protocol before
4.0, a CDS object item marked as an object.item.audioItem or any of its derived classes shall
contain at least one <res> element that conforms to either:

a) the MP3 Audio Format Profile as defined in guideline 8.8 of IEC 62481-2, or

b) the AAC_ISO_320 Audio Format Profile as defined in guideline 8.9 of IEC 62481-2.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 9TYS9 N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline mandates that a UPnP AV MediaServer exposes an alternate <res>
element in an Audio Media Class Media Format Profile supported by UPnP AV MediaRenderers that
belong to the MHD Device Category and implement to a version of the DLNA protocol before 4.0, to
improve content playback interoperability.

10.1.4.4.9
[G UIDELINE ] When a UPnP AV MediaServer is interacting with a UPnP AV MediaRenderer that
belongs to the HND Device Category and is implemented to a version of the DLNA protocol before
4.0, a CDS object item marked as an object.item.videoItem or any of its derived classes shall
contain at least one <res> element that conforms to a Regional AV Format Profile as defined in
Table 21 of IEC 62481-2 for each geographical region supported by the UPnP AV MediaServer.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC N5NXN N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline mandates that a UPnP AV MediaServer exposes an alternate <res>
element in an AV Media Class Media Format Profile supported by UPnP AV MediaRenderers that

DLNA guidelines; Part 1-1: Architecture and protocols

 – 199 –

belong to the HND Device Category and implement to a version of the DLNA protocol before 4.0, to
improve content playback interoperability.

10.1.4.4.10
[G UIDELINE ] When a UPnP AV MediaServer is interacting with a UPnP AV MediaRenderer that
belongs to the MHD Device Category and is implemented to a version of the DLNA protocol before
4.0, a CDS object item marked as an object.item.videoItem or any of its derived classes shall
contain at least one <res> element that conforms to the AVC_MP4_BL_CIF15_AAC_520 AV Format
Profile as defined in guideline 9.3 of IEC 62481-2.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC Y8N5X N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline mandates that a UPnP AV MediaServer exposes an alternate <res>
element in an AV Media Class Media Format Profile supported by UPnP AV MediaRenderers that
belong to the MHD Device Category and implement to a version of the DLNA protocol before 4.0, to
improve content playback interoperability.

10.1.4.4.11
[G UIDELINE ] If a CDS Object contains multiple <res> elements, then the URI values shall be such
that the UPnP AV MediaServer will correctly return the contentFeatures.dlna.org HTTP header (see
11.4.3.11.6) for each <res> element.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC GRRKZ N

29341-20-12

[C OMMENT] This is to prevent issues for content binaries that match multiple Media Format Profiles
and expose a <res> element for each matching Media Format Profile. This can be accomplished by
having unique URIs for each <res> element.

10.1.4.4.12
[G UIDELINE ] A UPnP AV MediaServer, in addition to exposing a Mandatory Media Format Profile in
a CDS object, may concurrently expose additional optional Media Format Profiles in the CDS object.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC Z4JR6 N

29341-20-12
IEC 62481-2

[C OMMENT] This guideline is to provide implementation guidance that a single CDS object could
contain additional DLNA Optional Media Format Profiles which could also be Converted Content
(e.g. transcoded content).

10.1.4.5 MM DIDL-Lite Multiple Res: Transports

[G UIDELINE ] A CDS object (identified through an <item> or <container> element) that has the same
content available for different media transport protocols shall expose the content through multiple
<res> elements.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 200 –

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 6YK54

29341-20-12

[C OMMENT] See the comments in 10.1.4.4.1 for more information.

10.1.4.6 MM DIDL-Lite Content: Multiple points of reachability

10.1.4.6.1
[G UIDELINE ] A UPnP AV MediaServer that does not receive the ALLIP value (case sensitive) as
part of the Filter argument (in a CDS:Browse or CDS:Search request) shall return only the URIs that
are associated with (or treated as or assumed to be routable from) the network interface that
received the SOAP request.

URIs with domain names may appear in these types of SOAP responses, according to the rules
specified in 10.1.3.10.

This guideline applies to URIs in <res>.

This guideline applies to any URI value that uses an IP network address, regardless of whether the
content conforms to a DLNA Media Format Profile.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC YFH2V

29341-20-12

[C OMMENT] These guidelines explain how a UPnP AV MediaServer is to handle the reporting of
<res> elements when the UPnP AV MediaServer has multiple network interfaces.

Essentially, the default behavior is that a UPnP AV MediaServer will only return <res> elements
where the URIs are known (or assumed to be) routable from the network interface that received the
request. However, if a UPnP AV MediaServer control point wants to receive URIs for all network
interfaces, then the DMP can specify the ALLIP value as part of the Filter argument. In such a
scenario, a UPnP AV MediaServer is obliged to return all of the <res> elements for all of the active
network interfaces that the UPnP AV MediaServer uses for media transport.

Because the guidelines language uses the UPnP AV MediaServer of a given UDN, a UPnP AV
MediaServer device that uses a different UDN for each network interfaces (equivalent to multiple
UPnP AV MediaServers for a single UPnP AV MediaServer device) does not need to return the
<res> elements that are accessible on a different network interface (e.g., res element found on a
different logical UPnP AV MediaServer).

Annex C describes the subtleties of multiple network interfaces and the role of these guidelines in
more detail.

10.1.4.6.2
[G UIDELINE ] A UPnP AV MediaServer that receives the ALLIP value in the Filter argument of a
CDS:Browse or CDS:Search request shall return all URIs associated with the UPnP AV
MediaServer of a given UDN, regardless of whether the URI is thought to be routable from the
network interface that received the SOAP request.

A UPnP AV MediaServer shall expose all URI values either through multiple <res> elements for
each CDS object or multiple CDS objects. Please see guidelines 10.1.4.6.3 and 10.1.4.6.4 for how
all URI values are exposed through multiple <res> elements or multiple CDS objects.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 201 –

URIs with domain names may appear in these types of SOAP responses, according to the rules
specified in 10.1.3.10.

This guideline applies to URIs in <res>.

This guideline applies to any URI value that uses an IPv4 or IPv6 network address, regardless of
whether the content conforms to a DLNA Media Format Profile.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC Z9GG5

29341-20-12

10.1.4.6.3
[G UIDELINE ] In conjunction with guideline 10.1.4.6.2, a UPnP AV MediaServer that receives the
ALLIP value should return CDS objects with multiple <res> elements, such that some of these <res>
elements are URI values that point to the same content available on different network interfaces.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC PAGPN

29341-20-12

[C OMMENT] This guideline allows a UPnP AV MediaServer to report content availability on multiple
networks through multiple <res> elements. The presence of multiple <res> elements is still
governed by 10.1.4.6.2.

10.1.4.6.4
[G UIDELINE ] A UPnP AV MediaServer that does not receive the ALLIP value (possibly with other
filter values, including the asterisk,*, value) may return CDS objects with zero or more <res>
elements.

Note that it is generally true that a UPnP AV MediaServer may return CDS objects with zero or more
<res> elements.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC UW9OG

29341-20-12

[C OMMENT] Although it is implied that a UPnP AV MediaServer is not required to provide a <res>
element for a CDS object, this guideline states it explicitly. This guideline allows implementations
that rely on multiple CDS objects (instead of multiple <res> elements to represent different versions
of the same content) to comply with 10.1.4.6.1.

10.1.4.6.5
[G UIDELINE ] A UPnP AV MediaServer that receives the ALLINTIP value in the Filter argument of a
CDS:Browse or CDS:Search request shall return all URIs (both IPv4 and IPv6) associated with the
network interface of the UPnP AV MediaServer that received the SOAP request.

A UPnP AV MediaServer shall expose all URI values through multiple <res> elements for each CDS
object.

URIs with domain names may appear in these types of SOAP responses, according to the rules
specified in 10.1.3.10.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 202 –

This guideline applies to URIs in <res>.

This guideline applies to any URI value that uses an IPv4 or IPv6 network address, regardless of
whether the content conforms to a DLNA Media Format Profile.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC BO8OX N

29341-20-12

[C OMMENT] This guideline introduces a new Filter argument, ALLINTIP that is designed to support
IPv6 URIs. A DMS will respond with IPv6 URIs associated with a network interface in addition to any
IPv4 URIs associated with the same network interface when it receives the ALLINTIP Filter
argument in a CDS:Browse or CDS:Search request. This functionality is being implemented to
protect legacy IPv4-only devices from receiving IPv6 URIs that may not be supported.

This ALLINTIP filter differs from the ALLIP filter in that the ALLINTIP filter is relevant to a single
network interface whereas the ALLIP filter is applicable to all network interfaces on a device. IPv6
support brings with it the new concept of network interfaces now supporting multiple IP addresses.
This was not the case with IPv4 in which multiple IPv4 addresses referencing the same element in
URIs implied a single UPnP MediaServer instance was functioning on multiple network interfaces.

The inclusion of other values in a filter argument such as an asterisk *, are not prohibited when the
ALLINTIP filter is present, but these arguments would typically not be used in conjunction with this
new Filter argument.

10.1.4.6.6
[G UIDELINE ] If the DMC negotiates an IPv6 address for UPnP Communications with a DMS, the
DMC shall use an IPv6 address for UPnP Communication with a DMR.

[ATTRIBUTES ]

M A DMC M-DMC n/a ISO/IEC AHGDQ N

29341-20-12

[C OMMENT] In a 3-box system usage, the DMC is responsible for negotiating the address family
needed to communicate between the DMS and the DMR. If the DMC determines that the DMS is
only reachable using an IPv6 address, it must attempt UPnP Communications with the DMR using
an IPv6 address to support communication between the DMS and DMR. If the DMR is not accessible
using an IPv6 address, then it is not possible to provide a URI to the DMR.

10.1.4.6.7
[G UIDELINE ] If the DMC negotiates an IPv6 address for UPnP Communications with a DMR, the
DMC shall use an IPv6 address for UPnP Communication with a DMS.

[ATTRIBUTES ]

M A DMC M-DMC n/a ISO/IEC 93PGX N

29341-20-12

[C OMMENT] In a 3-box system usage, the DMC is responsible for negotiating the address family
needed to communicate between the DMS and the DMR. If the DMC determines that the DMR is
only reachable using an IPv6 address, this guideline ensures that the DMC will perform UPnP
Communications with the DMS using an IPv6 address to support communication between the DMS
and DMR. This guideline overrides the default guideline to prefer IPv4 over IPv6 for UPnP
DLNA guidelines; Part 1-1: Architecture and protocols
 – 203 –

Communications (9.2.1.6). If the DMS is not accessible using an IPv6 address, then it is not
possible to provide a URI to the DMR.

10.1.4.6.8
[G UIDELINE ] When communicating with a DMR, the DMC’s UPnP control point shall only send URIs
containing IP addresses that are consistent with the IP address used for UPnP communication
between the DMC and DMR.

[ATTRIBUTES ]

M A DMC M-DMC n/a ISO/IEC ER848 N

29341-20-12

[C OMMENT] This guideline adds support for the IPv6 Connectivity function in a 3-box usage. The
DMC in this usage needs to verify that the URIs being sent to the DMR contain an IP address that is
reachable by the DMR.

10.1.4.6.9
[G UIDELINE ] Rendering and Serving Endpoints shall use the <dlna:X_DLNACAP> element in the
Device Description Document (as a child of the <device> element that represents the
MediaRenderer or MediaServer Device) and include a Capability ID value of “IPv6” as described in
9.2.35.1 if they support the IPv6 Connectivity Device Function.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC PZZ8R N

29341-20-12

10.1.4.6.10
[G UIDELINE ] If a UPnP AV MediaServer receives a CDS:Search or CDS:Browse action, and the
action does not include the ALLIP or ALLINTIP filter parameter, then the response shall only include
URIs using the same IP address family (and for IPv6, the same IPv6 prefix) as was used to invoke
the UPnP action.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC E5599 N

29341-20-12

[C OMMENT] This means that when browsing a DMS using IPv4, it only returns IPv4 addresses, and
when browsing a DMS using IPv6, it only returns IPv6 addresses, unless the request includes the
ALLIP or ALLINTIP filter parameters.

10.1.4.6.11
[G UIDELINE ] A UPnP AV MediaRenderer that supports the IPv6 Connectivity Device Function shall
tolerate URIs with IPv4 and IPv6 addresses regardless of which IP address family is used when
invoking an AVTransport service action.

[ATTRIBUTES ]

M A DMR n/a ISO/IEC R9PO2 N

29341-20-12

[C OMMENT] This means that when a DMR receives a SetAVTransportURI request or a

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 204 –

SetNextAVTransportURI request, it shall tolerate IPv6 URIs even if the request was received over
IPv4, and vice versa.

10.1.4.7 MM DIDL-Lite Multiple Res: thumbnails

10.1.4.7.1
[G UIDELINE ] If a UPnP AV MediaServer exposes a CDS object with a <upnp:class> designation of
object.item.imageItem (or any class derived from it), then the UPnP AV MediaServer should provide
a <res> element for the thumbnail resource. (Multiple thumbnail <res> elements are also allowed.)

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC UPXML

29341-20-12

[C OMMENT] UPnP AV MediaServer devices that implement thumbnail support reduce the network
load for themselves and for control points that display thumbnails to the user.

10.1.4.7.2
[G UIDELINE ] If a UPnP AV MediaServer exposes a CDS object with a <upnp:class> designation of
object.item.videoItem (or any class derived from it), then the UPnP AV MediaServer should provide
a <res> element for the thumbnail resource. (Multiple thumbnail <res> elements are also allowed.)

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC RZQRD

29341-20-12

10.1.4.7.3
[G UIDELINE ] If a UPnP AV MediaServer exposes thumbnail images for image or video content,
then a UPnP AV MediaServer shall provide a thumbnail that conforms to guideline 7.1.7 (GUN
6SXDY) in IEC 62481-2 Media Format Profile and be declared with the JPEG_TN designation in the
fourth field of the res@protocolInfo attribute.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC Y23HQ

29341-20-12
IEC 62481-2

[C OMMENT] When thumbnails are provided, the minimal expectation is to provide JPEG thumbnails.
However, vendors can also provide additional thumbnails using the JPEG_TN or PNG_TN profiles.

10.1.4.7.4
[G UIDELINE ] If a UPnP AV MediaServer exposes thumbnail images for image or video content,
then a UPnP AV MediaServer may provide additional <res> elements for thumbnail images.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC 7V6GS

29341-20-12

10.1.4.7.5
[G UIDELINE ] A UPnP A/V Media Server shall not expose a <res> element with a thumbnail Media
Format Profile ID (i.e. JPEG_TN, PNG_TN), without exposing at least one additional <res> element
that is not one of the thumbnail Media Format Profile IDs.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 205 –

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC O4VF4

29341-20-12

[C OMMENT] Thumbnails are designed to augment other content items of any Media Class (Audio,
AV, or Images) which can include non-DLNA content. They are not meant to represent standalone
images.

Images that will not be used as thumbnails but which match the thumbnail resolution will preferably
be exposed using the appropriate smallest image Media Format Profile ID (e.g. JPEG_SM).

10.1.4.7.6
[G UIDELINE ] If an UPnP AV MediaServer exposes video content, then the <item> element that
describes the video content may include zero or more <res> elements that reference companion
images of any size.

[ATTRIBUTES ]

O L DMS M-DMS n/a ISO/IEC RL6MB

29341-20-12
IEC 62481-2

[C OMMENT] UPnP AV MediaServers that expose a video item can include in the <item> element
zero or more <res> elements referencing companion images that provide additional descriptive
information. Examples of companion images include larger versions of thumbnails, posters
describing a movie, and others.

10.1.4.8 MM DIDL-Lite AudioItem album art

10.1.4.8.1
[G UIDELINE ] If a UPnP AV MediaServer exposes a CDS object with a <upnp:class> designation of
object.item.audioItem or object.container.album.musicAlbum (or any class derived from either
class), then the UPnP AV MediaServer should provide a <upnp:albumArtURI> element to present
the URI for the album art.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC ZVDY7

29341-20-12

[C OMMENT] Unlike image or video content, thumbnails for audio content will preferably be
presented through the <upnp:albumArtURI> element.

10.1.4.8.2
[G UIDELINE ] If a UPnP AV MediaServer exposes one or more <upnp:albumArtURI> elements for a
single CDS object, then at least one of the URI values should point to thumbnail album art
conforming to guideline 7.1.7 (GUN 6SXDY) in IEC 62481-2.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC YXRZ4

29341-20-12
IEC 62481-2

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 206 –

[C OMMENT] If album art thumbnails are provided, the desired expectation is to have JPEG
thumbnails. Additional thumbnails can also be provided.

10.1.4.8.3
[G UIDELINE ] If a UPnP AV MediaServer exposes a <upnp:albumArtURI> element with a URI
pointing to a thumbnail conforming to a DLNA Media Format Profile, then the <upnp:albumArtURI>
shall have the albumArtURI@dlna:profileID attribute that identifies the DLNA profile ID of the
thumbnail.

The namespace for DLNA defined properties shall be "urn:schemas-dlna-org:metadata-1-0/" and

the namespace prefix shall be "dlna:".
EXAMPLE:

<upnp:albumArtURI dlna:profileID="JPEG_TN"
xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">
http:/192.168.1.1/album/albumArt1.jpg
</upnp:albumArtURI>

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC XRZ4Y

29341-20-12

[C OMMENT] This guideline allows control points a convenient way to identify thumbnails that
conform to a DLNA Media Format Profile.

10.1.4.9 MM IFO file

10.1.4.9.1
[G UIDELINE ] If a UPnP AV MediaServer exposes a content binary profiled according to MPEG-2 AV
Format, Usage of Profile IDs, Profiles: MPEG_PS_NTSC and MPEG_PS_PAL, IEC 62481-2,
(MPEG_PS_NTSC or MPEG_PS_PAL profiles), then the UPnP AV MediaServer shall either ensure
that there are no SCR and/or PTS discontinuities (as defined in 10.1.4.9.8) or generate an IFO file
if it detects discontinuity.

Note that this guideline does not apply in the scenario where a DMS exposes a content binary that
was imported by the DMS, except when such content is received from a DLNA source.

All guidelines in 10.1.4.9 do not apply in scenarios involving URIs and/or <res> elements for RTP
Media Transport because RTP encapsulation and padding make the offsets in the IFO file
inaccurate.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VDY7V

29341-20-12
IEC 62481-2

[C OMMENT] Some decoders cannot handle the SCR/PTS discontinuous PS stream without proper
additional decoder-specific control. This guideline provides the method that allows the DMP to
obtain the information about the SCR/PTS discontinuous regions in program stream-profiled
content.
The following are examples of content where a UPnP AV Media Server needs to comply with this
guideline when exposing such content.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 207 –

• A DMS application running on an open platform, such as a PC, that directly records, generates,
or edits content.
The following are examples of content where a UPnP AV Media Server does not have to comply with
this guideline when exposing such content:

• A DMS application running on an open platform, such as a PC, that receives or copies content
from a non-DLNA source (e.g. Internet)
• A DMS application running on an open platform, such as a PC, which has other separate
applications that record, create, or edit content or that import content from non-DLNA sources
(e.g. Internet).
Although the above comments give examples where this guideline does not apply, it is still strongly
encouraged that vendors provide IFO files in all cases when exposing mandatory format profiles as
specified in IEC 62481-2 that have a discontinuity.

10.1.4.9.2
[G UIDELINE ] If a UPnP AV MediaServer exposes a content binary profiled according to
MPEG_PS_NTSC or MPEG_PS_PAL profiles (IEC 62481-2), along with an associated IFO file, then
it shall also expose the IFO file through the res@dlna:ifoFileURI attribute to present the URI for the
IFO file as defined in 10.1.4.9.9.

The namespace for DLNA defined properties is "urn:schemas-dlna-org:metadata-1-0/" and the

namespace prefix is "dlna:".

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC 4VF4V

2616
ISO/IEC
29341-20-12
ISO/IEC
29341-3-2
IEC 62481-2

10.1.4.9.3
[G UIDELINE ] If a Push Controller serves a content binary profiled according to MPEG_PS_NTSC or
MPEG_PS_PAL profiles (IEC 62481-2), along with an associated IFO file, directly to a UPnP AV
MediaRenderer, then the Push Controller shall include the res@dlna:ifoFileURI attribute in the
CurrentURIMetaData input argument for the AVT:SetAVTransportURI request as defined in
10.1.6.8.3. The res@dlna:ifoFileURI attribute contains the URI for the IFO file as defined in
10.1.4.9.9.

The namespace for DLNA defined properties is "urn:schemas-dlna-org:metadata-1-0/" and the

namespace prefix is "dlna:".

[ATTRIBUTES ]

M A +PU+ n/a n/a IETF RFC LQ8HI

2616
ISO/IEC
29341-20-12
ISO/IEC
29341-3-2
IEC 62481-2

10.1.4.9.4
[G UIDELINE ] If a UPnP AV MediaServer exposes a content binary profiled according to
MPEG_PS_NTSC or MPEG_PS_PAL profiles (IEC 62481-2), without SCR or PTS discontinuities,
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 208 –

the UPnP AV MediaServer may provide a res@ dlna:ifoFileURI attribute to present the URI for the
IFO file as defined in 10.1.4.9.9.

The namespace for DLNA defined properties is "urn:schemas-dlna-org:metadata-1-0/" and the

namespace prefix is "dlna:".

[ATTRIBUTES ]

O A DMS M-DMS n/a IETF RFC V6GS6

2616
ISO/IEC
29341-20-12
ISO/IEC
29341-3-2
IEC 62481-2

[C OMMENT] An IFO file can contain other metadata which might be useful to the Rendering
Endpoint.

10.1.4.9.5
[G UIDELINE ] If a Push Controller serves a content binary, profiled according to MPEG_PS_NTSC
or MPEG_PS_PAL profiles (IEC 62481-2), without SCR or PTS discontinuities, directly to a
MediaRenderer, then the Push Controller may include the res@dlna:ifoFileURI attribute in the
CurrentURIMetaData input argument for the AVT:SetAVTransportURI request as defined in
10.1.6.8.3. The res@dlna:ifoFileURI attribute contains the URI for the IFO file as defined in
10.1.4.9.9.

The namespace for DLNA defined properties is "urn:schemas-dlna-org:metadata-1-0/" and the

namespace prefix is "dlna:".

[ATTRIBUTES ]

O A +PU+ n/a n/a IETF RFC PAHZ5

2616
ISO/IEC
29341-20-12
ISO/IEC
29341-3-2
IEC 62481-2

10.1.4.9.6
[G UIDELINE ] If an IFO file is provided for a MPEG_PS_NTSC or MPEG_PS_PAL profiled content
binary via an associated res@dlna:ifoFileURI attribute and/or the transport layer (such as described
in 11.4.3.12), Rendering Endpoints shall render the content item even if the MPEG stream contains
discontinuous SCR and/or PTS.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a 23HQ6

[C OMMENT] If a MediaServer does not provide an IFO file (e.g. res@dlna:ifoFileURI is omitted) and
a content binary, profiled according to MPEG-2 AV Format, usage of Profile IDs, Profiles:
MPEG_PS_NTSC and MPEG_PS_PAL, IEC 62481-2, has discontinuities, then the Rendering
Endpoint can choose not to render the content binary.

10.1.4.9.7
[G UIDELINE ] If a Rendering Endpoint attempts to render a content binary that is profiled according
to MPEG-2 AV Format, usage of Profile IDs, Profiles: MPEG_PS_NTSC and MPEG_PS_PAL, IEC
DLNA guidelines; Part 1-1: Architecture and protocols
 – 209 –

62481-2 that has discontinuities and no IFO file is available, then the Rendering Endpoint shall
gracefully recover from the failure condition caused by any discontinuity.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IEC 62481-2 ZQRDX

10.1.4.9.8
[G UIDELINE ] An SCR or PTS discontinuity is defined as the occurrence of one of the following
conditions in an MPEG2 PS (IEC 62481-2) content binary.

Condition1:

If SCR(0) + SCRMaxValue - SCR(-1) <= 0.7 (to cover wrap-around case)

SCR(0) + SCRMaxValue < SCR(-1) + PackDuration
Otherwise SCR(0) < SCR(-1) + PackDuration

Or

Condition2:

If PTS(-1) > PTS(0) (to cover wrap-around case)

PTS(0) + PTSMaxValue - PTS(-1) > 0.61sec
Otherwise PTS(0) - PTS(-1) > 0.61sec

where

• SCR(0) is the SCR of the current pack.

• SCR(-1) is the SCR of the preceding pack.
• SCRMaxValue is 2^32 *300
• PackDuration is int((PackSize * 27000000) / (program_mux_rate * 50) =
int((2048*27000000)/(25200 * 50)) = 43885
• PTS(0) is the PTS of the first picture of current GOP.
• PTS(-1) is the PTS of the first picture of preceding GOP.
• PTSMaxValue is 2^32
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a ISO/IEC PXMLN

13818-1
ISO/IEC
13818-9

[C OMMENT] ISO/IEC 13818-1, 2.7.1, gives the following definition:

"The Program Stream shall be constructed such that the time interval between the bytes
containing the last bit of system_clock_refrence_base fields in successive packs shall be less
than or equal to 0,7s."

SCR_base and PTS are limited to 32 bits in the guideline.

All the mathematical equations on calculating SCR/PTS discontinuity are expected to be performed
using unsigned integer arithmetic as described in ISO/IEC 13818-1: 2.4.3.7.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 210 –

10.1.4.9.9
[G UIDELINE ] If a UPnP AV MediaServer provides an IFO file, then the URI of the IFO file shall be
specified.

IFO file URIs are governed by guidelines in 10.1.3.10, except that the maximum length for an IFO
file URI is 900 B.

Example:

<res protocolInfo="http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC" duration="02:45:00"

dlna:ifoFileURI="http://192.168.0.1:8080/IFO_101.ifo"
xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">
http://192.168.0.1:8080/MPEG/ntsc001.mpg
</res>

In this case , the URI of the IFO file is http://192.168.0.1:8080/IFO_101.ifo

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC W9OGW

29341-20-12

[C OMMENT] Content Receivers can get the IFO file by issuing HTTP GET requests using this URI.
The reason for a shorter IFO file URI is because they are included in HTTP headers where the
length is constrained.

10.1.4.10 MM CDS Browse/Search action: Filter argument

10.1.4.10.1
[G UIDELINE ] A UPnP AV MediaServer must respond to a CDS:Browse or CDS:Search request with
the following five metadata properties in the DIDL-Lite response, even if the metadata properties
are not specified in the Filter argument of a CDS:Browse or CDS:Search request:

• @id
• @parentID
• @restricted
• dc:title
• upnp:class
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC AGPNV

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The Filter argument of the CDS:Browse and CDS:Search action instructs a UPnP AV
MediaServer ContentDirectory to return only the specified metadata properties in the DIDL-Lite
response of the Result output argument. This guideline clarifies that some metadata properties are
required to be present even if they are not specified in the Filter argument.

10.1.4.10.2
[G UIDELINE ] If an element of metadata property is specified, then the required attributes of the
metadata element shall be presented.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 211 –

For example:

• If a control point specifies "res" in the Filter, then res@protocolInfo is returned.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 9GG5U

29341-20-12

10.1.4.10.3
[G UIDELINE ] A UPnP AV MediaServer control point should explicitly specify the desired metadata
properties in the Filter input argument of a CDS:Browse or CDS:Search request.

[ATTRIBUTES ]

S R DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC FH2V5

+UP+ 29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline recommends control points to limit the requested metadata to only the
metadata that will be used by the control point. A Filter value of asterisk "*" will likely cause the
UPnP AV MediaServer to send more metadata than what the control point can actually use.

10.1.4.10.4
[G UIDELINE ] A UPnP AV MediaServer in conjunction with 10.1.4.10.1 and 10.1.4.10.7, shall not
return metadata properties unless specified in the Filter argument.

For example:

• If a control point does not specify res@importUri in the Filter, then it is not returned.
Note that having an attribute property in the Filter automatically requires the MediaServer to return
the element to which the attribute belongs.

For example:

• If the control point specifies res@importUri (without "res"), then the "res" is also returned.
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC YK54Y

29341-20-12
ISO/IEC
29341-20-3

10.1.4.10.5
[G UIDELINE ] A UPnP MediaServer shall return DLNA metadata (i.e. attributes or elements with the
dlna: prefix) only when the Filter argument indicates a request for the particular DLNA attribute(s) or
element(s).

An "*" indicates a request for all attributes and elements.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC K54YH

29341-20-3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 212 –

[C OMMENT] This behavior is required by the ContentDirectory specification and is consistent with
the guideline 10.1.4.10.4.

Guidelines that require DLNA-defined metadata do not overrule underlying rules specified by the
UPnP AV ContentDirectory service.
For example, guideline 10.1.4.8.3 requires albumArtURI@dlna:profileID, but a MediaServer only
includes albumArtURI@dlna:profileID in a response when the Filter argument indicates a request
for it.

10.1.4.10.6
[G UIDELINE ] A UPnP MediaServer should declare the dlna: namespace (i.e.
"urn:schemas-dlna-org:metadata-1-0/") only when the Filter argument indicates a request for one or
more DLNA attributes or elements and one or more DLNA attributes are included in the DIDL-Lite
response.

An "*" indicates a request for all attributes and elements.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC H2V52

29341-20-3

[C OMMENT] This guideline reduces the computational requirements of control points that employ
validating schemas.

Although some guidelines require DLNA-defined elements and attributes in certain situations, the
DLNA schema does not play a syntax enforcement role as all DLNA-defined elements and attributes
are considered optional from the schema's perspective.
For example, guideline 10.1.4.8.3 albumArtURI@dlna:profileID when the associated URI points to
an image that is compliant to a DLNA Media Format Profile. Since it is impossible for the DLNA
schema to determine if a URI points to a DLNA Media Format Profile, the
albumArtURI@dlna:profileID is considered optional attribute (from a schema perspective) even
though it is required from a guidelines perspective.

10.1.4.10.7
[G UIDELINE ] A UPnP AV MediaServer should respond to a CDS:Browse or CDS:Search request
with any additional mandatory metadata properties above those required in requirement 10.1.4.10.1
in the DIDL-Lite response when required by the value in the upnp:class property or derived classes
for that value, even if the metadata properties are not specified in the Filter argument of a
CDS:Browse or CDS:Search request.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC FVTKX

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The UPnP CDS specification ISO/IEC 29341-20-3 defines some additional classes
through the upnp:class property that contains mandatory CDS properties above the 5 required in
requirement 10.1.4.10.1. For example, there are derived classes of object.container that increases
the number of required properties beyond the 5 basic properties defined in 10.1.4.10.1 as follows:

• upnp:class property value of object.container.storageSystem defines 5 additional required

properties.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 213 –

• upnp:class property value of object.container.storageVolume defines 4 additional required

properties.
• upnp:class property value of object.container.storageFolder defines 1 additional required
property.
This guideline is recommended instead of mandatory to maintain interoperability with
implementations prior to this guideline addition, but have new implementations to be forward
looking with this new recommendation

10.1.4.11 MM CDS Browse/Search action: Reduced response behavior

10.1.4.11.1
[G UIDELINE ] A UPnP AV MediaServer device may reduce the number of CDS objects (<item> and
<container> elements) in a response to a CDS:Browse or CDS:Search for the following scenarios
only.

• The transmission of a SOAP response with a huge byte length (>204 800 B).
• The transmission of a SOAP response that exceeds 30 s for the transmission time.
[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC GG5U7

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline allows a UPnP AV MediaServer to limit the number of CDS objects
returned in the SOAP response, even if the control point specified a desire for more CDS objects in
the RequestedCount input argument. The reason for permitting such behavior is to allow UPnP AV
MediaServer implementations to comply with other guidelines: 9.2.15 and 9.2.9.

10.1.4.11.2
[G UIDELINE ] The number of CDS object entries (total <item> and <container> elements) in the
Result output argument (containing the DIDL-Lite metadata) shall match the value specified in the
NumberReturned output argument.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC GPNVY

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline will be followed, even if a UPnP AV MediaServer reduces the number of
CDS objects returned in the SOAP response.

10.1.4.11.3
[G UIDELINE ] If a UPnP AV MediaServer device reduces the number of CDS objects in a
CDS:Browse(BrowseDirectChildren) or CDS:Search response then the number of returned CDS
objects (as parsed in Result) shall be equal to the value of NumberReturned, which is less than
RequestedCount.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 9OGWH

29341-20-12
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 214 –

ISO/IEC
29341-20-3

[C OMMENT] A UPnP AV MediaServer that limits the number of CDS objects is obligated to return a
NumberReturned value that is consistent with the RequestedCount input argument.

10.1.4.11.4
[G UIDELINE ] If a UPnP AV MediaServer control point uses a CDS:Browse with the
BrowseMetadata option, then it shall use a RequestedCount of 0 or 1 and StartingIndex of 0.

This guideline does not apply to an Upload Controller that only implements the CDS:CreateObject
action for only the upload AnyContainer operation..

[ATTRIBUTES ]

M L DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC QRDX5 C

+UP+ 29341-20-12
ISO/IEC
29341-20-3

[C OMMENT]

a) Improves expectations for CDS:Browse scenarios with BrowseMetadata.

b) An Upload Controller (+UP+) is not obligated to implement the CDS:Browse action when only
implementing the upload AnyContainer operation.
10.1.4.11.5
[G UIDELINE ] A UPnP AV MediaServer device shall always return one CDS object (as indicated in
TotalMatches and Result) when successfully responding to a CDS:Browse request with the
BrowseMetadata option, regardless of the RequestedCount value.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 3HQ6W

29341-20-12
ISO/IEC
29341-20-3

10.1.4.11.6
[G UIDELINE ] If the UPnP AV MediaServer device returns more than zero CDS objects in a response
to a CDS:Browse or CDS:Search query and if the UPnP AV MediaServer device does not provide an
accurate value for the TotalMatches output argument, then the TotalMatches output value shall be
set to zero.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 6GS6Q

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline allows control points to conclude that a TotalMatches == 0 condition
indicates that the UPnP AV MediaServer could not accurately calculate the value in cases where the
UPnP AV MediaServer actually returned CDS objects.

Although some UPnP AV MediaServer implementations might choose to report the accurate
TotalMatches value, at the expense of violating the 30 s timeout rule, DLNA does not encourage
DLNA guidelines; Part 1-1: Architecture and protocols
 – 215 –

that implementation option. The 9.2.9 guideline indicates that a control point is permitted to
terminate a SOAP response that exceeds a 30 s transmission time.

10.1.4.11.7
[G UIDELINE ] If a UPnP AV MediaServer device cannot find more than zero CDS objects (in 27 s, as
described in 9.2.9.2), for a response to a CDS:Browse or CDS:Search query and if the UPnP AV
MediaServer cannot calculate an accurate value for the TotalMatches output argument, then the
UPnP AV MediaServer should return a SOAP error response code of 720 (Cannot process the
request).

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC VF4V2

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline covers the scenario where a UPnP AV MediaServer can neither find any
CDS objects that satisfy the query nor calculate the TotalMatches output argument accurately.
Although some UPnP AV MediaServer implementations might choose to report the accurate
TotalMatches value, at the expense of violating the 27 s timeout rule, such behavior is not
encouraged for the same reason stated in the previous guideline.

10.1.4.11.8
[G UIDELINE ] A UPnP AV MediaServer control point should specify the desired number of CDS
objects in the RequestedCount input argument of a CDS:Browse or CDS:Search query.

[ATTRIBUTES ]

S C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC DY7V3

+UP+ 29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline recommends control points to request a reasonable number of CDS
objects in a single CDS query. The number of CDS objects that can be displayed to the user at a
single time is a good measure of reasonableness. Using a RequestedCount of zero might cause the
transmission of a huge SOAP response, which is undesirable.

10.1.4.11.9
[G UIDELINE ] A UPnP AV MediaServer control point should specify smaller (about 10 to 30)
RequestedCount input values for CDS:Browse and CDS:Search requests to receive a faster
response time.

[ATTRIBUTES ]

S C DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC RZ4YU

+UP+ 29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Generally speaking, control points that specify smaller RequestedCount values will
receive the response from the device sooner than if a larger value were specified.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 216 –

10.1.4.11.10
[G UIDELINE ] A UPnP AV MediaServer control point shall not assume that a UPnP MediaServer will
return all of the CDS objects requested in a Browse request.

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC Z4YU4

+UP+ 29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This places requirements on an AV MediaServer control point to not assume that its
Browse request will return all of the CDS objects it requested.

10.1.4.11.11
[G UIDELINE ] If a UPnP AV MediaServer control point wants to retrieve the remaining items in a
reduced response, the UPnP AV MediaServer control point shall issue additional Browse requests
to complete the original Browse request for CDS objects.

[ATTRIBUTES ]

M R DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC Y7V3Y

+UP+ 29341-20-12
ISO/IEC
29341-20-3

10.1.4.12 MM Container Update IDs event

[G UIDELINE ] UPnP AV MediaServer devices should implement behavior for the
CDS.ContainerUpdateIDs state variable.

[ATTRIBUTES ]

S L DMS M-DMS n/a ISO/IEC F4V2V

29341-20-12

[C OMMENT] This guideline is a benefit to both devices and control points, although lightweight
UPnP AV MediaServer ContentDirectory Service (CDS) implementations might have difficulty
implementing it. The rationale for this guideline stems from the fact that UPnP AV MediaServer
control points can rely on the CDS.ContainerUpdateIDs state variable to minimize the number of
CDS:Browse requests. A control point that relies solely on the CDS.SystemUpdateID state variable
will browse the entire CDS hierarchy. Use of the CDS.ContainerUpdateIDs state variable can limit
the browse requests to the container objects that observed the metadata changes.

10.1.4.13 MM Search capabilities

10.1.4.13.1
[G UIDELINE ] A UPnP AV MediaServer shall implement CDS:Search with support for search queries
with the following metadata properties:

• dc:title
• upnp:class
• res@protocolInfo
• @refID
• @parentID

DLNA guidelines; Part 1-1: Architecture and protocols

 – 217 –

• @id
[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC GS6QV

29341-20-12

[C OMMENT] This guideline mandates support for CDS:Search and describes the search
capabilities for a UPnP AV MediaServer that supports search operations.

10.1.4.13.2
[G UIDELINE ] All searchable properties shall be listed in the return value of
CDS:GetSearchCapabilities if the device implements CDS:Search.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC HQ6WO

29341-20-12

[C OMMENT] This guideline mandates that supported search properties be discoverable.

10.1.4.13.3
[G UIDELINE ] If a UPnP AV MediaServer supports CDS:Search for an indicated property or a
property with an indicated type, then it shall minimally support the operators as indicated in Table 17
for the specified property types. Note that rows in the table are not additive.

Table 17 – CDS:Search minimum support of operators

Property Operators

@id =, exists

@refID =, exists

@parentID =, exists

upnp:class =, derivedfrom, exists

Any date, time, duration-based property types < , <= , >= , > , = , !=, exists

All other string-based property types other than contains, =, exists

those listed in previous table entries

All URI-based property types contains, =, exists

Integer or numerical property types < , <= , >= , > , = , !=, exists

Boolean-based property types =, !=, exists

All other attributes and elements exists

Vendors are free to apply additional CDS-normative operators for these properties or property
types.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC RDX57

29341-20-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 218 –

[C OMMENT] This guideline specifies the minimum behavior and capabilities for various query
operators.

Vendors cannot change (overrule) the default behavior of these required operations as specified;
but additions of standard operators are allowed.

The existing operator only allows a value of "true" or "false" and those values are not quoted when
used.

• VALID: @refID exists false

• INVALID: @refID exists 0
• INVALID: @refID exists "false"
10.1.4.13.4
[G UIDELINE ] If a UPnP AV MediaServer reports a searchable property for a particular data type,
then a UPnP AV MediaServer shall implement the associated operators for that data type.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC MLNQA

29341-20-12

[C OMMENT] For example, if a UPnP AV MediaServer reports its search capabilities to be only
dc:title, then it only needs to implement the exists, contains, and = operators.

10.1.4.13.5
[G UIDELINE ] In response to a CDS:Search action a UPnP AV Media Server may return CDS objects
that represent content binaries that cannot be identified as a DLNA Mandatory Media Format Profile
or converted in to a DLNA Mandatory Media Format Profile.

[ATTRIBUTES ]

O R DMS M-DMS n/a ISO/IEC 3JW2N N

29341-20-12

[C OMMENT]

a) This guideline provides a method for UPnP AV MediaServers to expose content that is not
accessable by the noramal CDS:Browse due to 10.1.4.3.
b) A UPnP AV MediaServer control point can override this behaviour (as defined in 10.1.4.13.6) as
mandated by a combination of 10.1.4.13.1and 10.1.4.13.3.
10.1.4.13.6
[G UIDELINE ] If a UPnP AV MediaServer controll point only supports DLNA Media Format Profiles
then it shall include ‘upnp:res@protocolInfo contains “DLNA.ORG_PN”’ in the SearchCriteria
argument when invoking CDS:Search action

[ATTRIBUTES ]

M R DMP DMC M-DMP n/a ISO/IEC GB5KZ N

29341-20-12

[C OMMENT] This ensures that the UPnP AV MediaServer will only return content that is in a DLNA
Media Format Profile in response to a CDS:Search request, as with CDS:Browse.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 219 –

10.1.4.14 MM Search all CDS Objects for a Media Class

10.1.4.14.1
[G UIDELINE ] A UPnP AV MediaServer that implements the CDS:Search action should support the
search with the following input parameters.

• ContainerID: 0
• SearchCriteria: upnp:class derivedfrom "[a upnp class for a supported Media Class]" and
@refID exists false.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC OGWHP

29341-20-12

[C OMMENT] A ContentDirectory service can expose CDS objects in different collections, such as,
lists by genres, lists by artists, lists of favorite items, etc. In such cases, reference items, which have
@refID are used to represent CDS items that are references to other CDS items in the CDS
hierarchy.

In some use case scenarios, a UPnP AV MediaSerer control point wants to locate a set of CDS
objects, excluding their duplicate references. For example, a UPnP AV MediaServer control point
regenerates another presentation of CDS objects by using metadata properties of CDS objects. In
this case, this search can be used.

Live AV and audio tuner content are also located by searching for
object.item.videoItem.videoBroadcast and object.item.audioItem.audioBroadcast (and their
derived classes). Note that the search results do not include the CDS container (i.e. ContainerID)
that was specified in the request.

10.1.4.14.2
[G UIDELINE ] If the UPnP AV MediaServer supports a DLNA Media Class, it shall support a
corresponding object class as indicated in Table 18.

Table 18 – UPnP:class for searching all CDS objects

Media Class upnp:class value

Audio object.item.audioItem

Image. object.item.imageItem

AV object.item.videoItem

The following is an example to search all video items which are stored in the ContentDirectory
service.

request:
Search( "0", "upnp:class derivedfrom "object.item.videoItem" and @refID exists false",
"dc:date,upnp:genre,res@duration", 0, 40, "" )

response:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 220 –

Search("<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">
<item id="10" parentID="4" restricted="0">
<dc:title>Desire stones</dc:title>
<dc:date >2004-07-04T20:00:00</dc:date>
<upnp:genre>Movie</upnp:genre>

<upnp:class>object.item.videoItem</upnp:class>
<res protocolInfo="http-get:*:
video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_FLAGS=01100000000000000000000000000000"
duration="0:59:53">http://192.168.1.1/res?id=10
</res>
</item>
<item id="13" parentID="12" restricted="0">
<dc:title>Music Street in Asia</dc:title>
<dc:date>2004-07-04T23:30:00</dc:date>
<upnp:genre>Music</upnp:genre>

<upnp:class>object.item.videoItem</upnp:class>
<res protocolInfo="http-get:*:
video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_FLAGS=01100000000000000000000000000000"
duration="0:29:54">http://192.168.1.1/res?id=13</res>
</item>
</DIDL-Lite>",
2, 2, 10434)

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a PNVYT

10.1.4.14.3
[G UIDELINE ] UPnP AV MediaServer responses for CDS:Search should only list CDS containers
once. Duplicate CDS containers should be omitted from the results set.

Duplicate CDS containers are CDS containers that provide the same set of child CDS items.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC G5U7Z

29341-20-12

[C OMMENT] Duplicate CDS containers can be implemented in a ContentDirectory service which

exposes the same content in different groupings.
For example, a music library can expose the same set of music tracks in two different CDS
containers. In this example, the CDS containers could have a hypothetical path from the root as
follows:

"0" => "All Albums" => "The Doors Greatest Hits"

"0" => "All Artists" => "The Doors" => "The Doors Greatest Hits"
This guideline recommends the MediaServer to return either of these containers rather than both of
them in the CDS:Search response where the SearchCriteria is "upnp:class derivedfrom
"object.container.musicAlbum"".

DLNA guidelines; Part 1-1: Architecture and protocols

 – 221 –

10.1.4.14.4
[G UIDELINE ] The UPnP AV MediaServer that supports the recommended search criteria of
guideline 10.1.4.14.1 shall return a SearchCaps output value (from CDS:GetSearchCapabilities)
that includes upnp:class and @refID.

Example:

• request: GetSearchCapabilities
• response: GetSearchCapabilities("upnp:class,@refID")
The ContentDirectory service of this MediaServer shall provide the following properties and the
values as metadata of the root Container.

• @searchable="1"
• <upnp:searchClass includeDerrived="1">[upnp class]</upnp:class> or <upnp:searchClass
includeDerrived="0">[upnp class]</upnp:class>
The following DIDL-Lite fragment is an example of metadata for a root Container in the
ContentDirectory service that supports Audio, Image and AV Media Classes.

Example:

<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">
<container id="0" parentID="-1" childCount="3" restricted="1" searchable="1">
<dc:title>Root Container</dc:title>
<upnp:class>object.container</upnp:class>
<upnp:searchClass
includeDerived="1">object.item.audioItem</upnp:searchClass>
<upnp:searchClass
includeDerived="1">object.item.imageItem</upnp:searchClass>
<upnp:searchClass
includeDerived="1">object.item.videoItem</upnp:searchClass>
</container>
</DIDL-Lite>

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 2V52H

29341-20-12

[C OMMENT] A UPnP AV MediaServer control point can know whether a ContentDirectory service
supports the search defined in guideline 10.1.4.14.1 by checking the search capabilities and the
metadata of the root container.

10.1.4.15 MM keyword search templates

[G UIDELINE ] A UPnP AV MediaServer that implements the CDS:Search action should support the
following types of CDS:Search requests, with the ContainerID input parameter set to "0".

• "dc:title contains " val1 " and @refID exists false"

• "dc:creator contains " val1 " and @refID exists false"
• "upnp:album contains " val1 " and @refID exists false"

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 222 –

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 54YHU

29341-20-12

[C OMMENT] Some control points with an alphanumeric input mechanism (keyboards, virtual
keyboards, cell phone keypad, etc.) can benefit from keyword searching capabilities.

10.1.4.16 MM/BT Basic Tuner container

10.1.4.16.1
[G ENERAL ] DLNA defines two tuner implementations. They are indicated as either a Basic Tuner or
an Extended Tuner. The Basic Tuner guidelines, as defined in 10.1.4.16 to 10.1.4.23 by the initial
publishing of the design guidelines, are based upon the UPnP AV MediaServer:1 specifications and
those guidelines have been relabeled as “MM/BT Basic Tuner”. The Extended Tuner guidelines, as
defined in 10.4, are based upon the TUNER Feature defined in UPnP AV MediaServer:2 and higher
specifications.

10.1.4.16.2
[G UIDELINE ] If a UPnP AV MediaServer implements a Basic Tuner, then it shall conform to all of the
requirements for a Basic Tuner as defined in 10.1.4.16.3 to 10.1.4.16.6 and 10.1.4.17 to 10.1.4.23.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 4BI9R

29341-20-3

[C OMMENT] It is optional for a UPnP AV MediaServer to implement a Basic Tuner. The Basic Tuner
implementation can be implemented by any version of the UPnP AV specifications.

10.1.4.16.3
[G UIDELINE ] A UPnP AV MediaServer tuner should be represented as a container with a class of
object.container or any derived class. A Basic Tuner container should have an associated name.
The name is given by property dc:title.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 4YHUX

29341-20-12

[C OMMENT] This guideline allows multiple tuners to be represented in CDS with a friendly name.
Tuner channel ordering allows the control point to implement up/down by selecting the next item in
the container.
See Annex B for recommendations on how to represent a turner container.

Control Points: note that in compliance with UPnP guidelines (10.1.4.10), conformant DMS devices
will not return the dlna:containerType property unless it is specifically requested as part of a
CDS:Browse Filter argument.

10.1.4.16.4
[G UIDELINE ] A UPnP AV MediaServer Basic Tuner container shall have a dlna:containerType
property and the property shall have a value of Tuner_1_0.

The name space for DLNA defined properties shall be "urn:schemas-dlna-org:metadata-1-0/" and
the namespace prefix shall be "dlna:".

DLNA guidelines; Part 1-1: Architecture and protocols

 – 223 –

The following is an example.

<dlna:containerType
xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">Tuner_1_0</dlna:containerType>

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC V52H7

29341-20-12

10.1.4.16.5
[G UIDELINE ] A UPnP AV MediaServer Basic Tuner container shall contain object items of class
object.item.videoItem.videoBroadcast or object.item.audioItem.audioBroadcast or both. (Objects
derived from either class also qualify.)

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 5U7ZK

29341-20-12

10.1.4.16.6
[G UIDELINE ] The order of the object items (order of <item> elements in a CDS:Browse response) in
a UPnP AV MediaServer Basic Tuner container should correspond to the tuner up/down operation.
For example, channel number or channel preset order.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC NVYTV

29341-20-12

10.1.4.17 MM/BT Basic Tuner audio tuner

[G UIDELINE ] If a UPnP AV MediaServer provides live audio content from a tuner, the UPnP AV
MediaServer should use object.item.audioItem.audioBroadcast or any derived class as the
upnp:class value.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC GWHPZ

29341-20-12

[C OMMENT] These guidelines allow control points to identify content sourced from a tuner.

10.1.4.18 MM/BT Basic Tuner video tuner

[G UIDELINE ] If a UPnP AV MediaServer provides live video or audio/video content from a tuner, the
UPnP AV MediaServer should use object.item.videoItem.videoBroadcast or any derived class as
the upnp:class value.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC LNQA9

29341-20-12

[C OMMENT] See comment text for 10.1.4.17.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 224 –

10.1.4.19 MM/BT Basic Tuner properties: Channel Title

[G UIDELINE ] A UPnP AV MediaServer tuner dc:title property should describe the program content
if available otherwise should contain the contents of the upnp:channelName CDS property. If
upnp:channelName CDS property is not available the upnp:channelNr property should be used.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC DX57C

29341-20-12

[C OMMENT] This is to clarify the meaning of a title in context of a tuner. Some vendors might
interpret the title as channel name.

10.1.4.20 MM/BT Basic Tuner properties: Channel Number

10.1.4.20.1
[G UIDELINE ] A UPnP AV MediaServer broadcast object item should have the associated property
upnp:channelNr.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC Q6WOI

29341-20-12

[C OMMENT] This guideline clarifies the intended usage of upnp:channelNr.

10.1.4.20.2
[G UIDELINE ] If a UPnP AV MediaServer CDS object contains the upnp:channelNr property, then
each upnp:channelNr number shall be unique within the context of its container.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC S6QVG

29341-20-12

[C OMMENT] For usages where the same upnp:channelNr number indicates different media formats
for the same content (e.g. SD and HD content), this would be realized by using the recommended
practice in DLNA to use multiple <res> elements in the same CDS object 10.1.4.4.1.

10.1.4.21 MM/BT Basic Tuner properties: Channel Name

[G UIDELINE ] If a UPnP AV MediaServer broadcast object item has the associated property
upnp:channelName, then each upnp:channelName string should be unique within the context of its
container. The upnp:channelName should be used to identify the channels, not the program
content.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 4V2VO

29341-20-12

[C OMMENT] This guideline clarifies the intended usage of upnp:channelName.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 225 –

10.1.4.22 MM/BT Basic Tuner content URI

[G UIDELINE ] The channel selection and the connection to the tuner are invoked through the
connection establishment to the URI of the resource associated with the broadcast object item.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 7V3YS

29341-20-12

[C OMMENT] This guideline essentially requires tuner content to be advertised and accessible
through a URI.

10.1.4.23 MM/BT Basic Tuner Control Point assumptions

[G UIDELINE ] The UPnP AV MediaServer control point should not assume that the currently viewed
channel is the channel that it previously selected. Due to possible sharing of the tuner by multiple
clients the channel can change without the client being aware of the change.

[ATTRIBUTES ]

S A DMP DMC +DN+ M-DMP M-DMC n/a ISO/IEC 4YU4Z

29341-20-12

[C OMMENT] Because there is no feed back mechanism between the tuner and the control point, it
is not possible to know the current channel when there are multiple Content Receivers connected as
clients or if the tuner is being used by a local output device.

10.1.4.24 MM TakeOut contents

10.1.4.24.1
[G UIDELINE ] A UPnP AV MediaServer may provide the DLNA defined property<dlna:takeOut> for a
CDS object that belongs to a group of objects intended for unidirectional synchronization (from the
server to a downloading endpoint).

The <dlna:takeOut > is a non-empty string value with a maximum length of 256 B.

The name space for DLNA defined properties shall be "urn:schemas-dlna-org:metadata-1-0/" and
the namespace prefix shall be "dlna:".

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC YU4ZM

29341-20-12

[C OMMENT] The guidelines for takeOut enable unidirectional synchronization scenarios. This
allows a device to easily find a group of content that is intended for download. Control points find
groups by using CDS:Search and specifying the <dlna:takeOut> property with the desired group
name.

The general assumption is that a control point (bundled with a Download Controller) will find content
with a particular group name and download it (unless it has already acquired it). The <dlna:takeOut>
tag will generally persist on the DMS or M-DMS, such that if a CDS object is no longer part of a
group, then the control point will know to remove the content from its local storage during the
synchronization operation.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 226 –

The process of assigning the value of the <dlna:takeOut> tag is vendor defined. One way is for the
DMS or M-DMS to assign the value for a user when the user creates the group. Another way is to
allow the user to name the group. An extremely simple way is to assign the same group name to all
CDS objects.

DLNA suggests that DMS or M-DMS implementations provide a way for a user to specify a maximum
storage quota when creating a group. This type of user interface feature is useful because users are
generally aware that downloading endpoints have storage limitations for downloading groups.

This guideline does not imply any requirement that the downloader mirrors the CDS hierarchy when
it downloads content from the CDS. This is especially true when the takeOut group includes CDS
containers (i.e. the CDS container has the <dlna:takeOut> element).

10.1.4.24.2
[G UIDELINE ] A CDS object (advertised by a UPnP AV MediaServer) may contain more than one
<dlna:takeOut> element.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC V3YS5

29341-20-12

[C OMMENT] A CDS object can belong to multiple groups.

This guideline provides for basic unidirectional synchronization of content from a DMS to UPnP
Control Points. The primary mechanism used by a control point to identify content between reboots
or application launches is through the object ID. The mechanism to indicate if content has been
modified is to change the object ID but to change the value of the URI (i.e. value of the <res>
element).

10.1.4.24.3
[G UIDELINE ] If a UPnP AV MediaServer provides the <dlna:takeOut> property to a CDS object and
wants to indicate that the content is identical between reboots or application launch/shutdown, then
it shall not change the object ID of the CDS object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC V2VOM

29341-20-12

10.1.4.24.4
[G UIDELINE ] If a UPnP AV MediaServer control point is synchronizing a particular take-out group,
then under normal test conditions the control point should only transfer content binaries belonging
to CDS objects that are part of the take-out group.

(That is, if a UPnP AV MediaServer control point is not able to find a take-out CDS object that was
synchronized on a previous session or if the CDS object of the same @id value no longer has the
<dlna:takeOut> property with the same group name, then the control point should assume that the
CDS object is no longer part of the take-out group.)

[ATTRIBUTES ]

S A +DN+ n/a n/a ISO/IEC 6QVGY

29341-20-12

[C OMMENT] The phrase under normal test conditions means no resource and network limitations.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 227 –

10.1.4.24.5
[G UIDELINE ] If a UPnP AV MediaServer control point is synchronizing a particular take-out group
and finds a take-out CDS object that was not synchronized on a previous session, then under
normal test conditions it should attempt to transfer at least one content binary from the associated
CDS object.

(That is, if a UPnP AV MediaServer control point finds a take-out CDS object that was not
synchronized on a previous session, then it should assume that the CDS object is a new member of
the take-out group.)

[ATTRIBUTES ]

S A +DN+ n/a n/a ISO/IEC 6WOIW

29341-20-12

[C OMMENT] The phrase under normal test conditions means no resource and network limitations.

10.1.4.24.6
[G UIDELINE ] If a UPnP AV MediaServer provides the <dlna:takeOut> property to a CDS object and
wants to indicate that a content binary is modified (e.g. editing), it shall change the @id value to a
new and unique value, relative to the entire CDS hierarchy.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC X57CY

29341-20-12

10.1.4.24.7
[G UIDELINE ] If a UPnP AV MediaServer supports the <dlna:takeOut> property, then it shall support
the DLNA- defined CDS:X_GetTakeOutGroupNames action.

The action's definition in the service description is:

<action>
<name>X_GetTakeOutGroupNames</name>
<argumentList>
<argument>
<name>GroupNames</name>
<direction>out</direction>
<relatedStateVariable>
X_A_ARG_Type_GroupNames
</relatedStateVariable>
</argument>
</argumentList>
</action>

The X_A_ARG_TYPE_GroupNames state variable is defined:

<stateVariable sendEvents="no">
<name>X_A_ARG_Type_GroupNames</name>
<dataType>string</dataType>
</stateVariable>

The GroupNames output argument is a comma-separated value list of all take-out group names.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 228 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC NQA9W

29341-20-12

[C OMMENT] The CDS:GetTakeOutGroupNames action allows a control point to easily acquire the
list of group names for use in a CDS:Search request. DLNA has two normative search templates for
finding groups. The only difference between the two is that vendors can specify a upnp:class value
if desired.

10.1.4.24.8
[G UIDELINE ] If a UPnP AV MediaServer supports the <dlna:takeOut> property, then it shall support
searching the CDS as defined in guideline 10.1.4.14 and the additional searches with the following
input parameters.

• Additional Search #1 input parameters::

– ContainerID = 0
– SearchCriteria: @refID exists false and dlna:takeOut="[group name]"
• Additional Search #2 input parameters::
• ContainerID = 0
• SearchCriteria: upnp:class derivedfrom "[a upnp class for a supported Media Class]" and
@refID exists false and dlna:takeOut="[group name]"
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WHPZV

29341-20-12

10.1.4.24.9
[G UIDELINE ] A UPnP AV MediaServer that supports the search defined in guideline 10.1.4.24.8
shall return the SearchCaps that includes the <dlna:takeOut> element to the
CDS:GetSearchCapablities action.

Example:

• request: CDS:GetSearchCapabilities()
• response: CDS:GetSearchCapabilities("upnp:class,@refID, dlna:takeOut")
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC VYTV3

29341-20-12

[C OMMENT] A UPnP AV MediaServer control point can know whether a ContentDirectory service
supports the search defined in guideline 10.1.4.24.8 by checking the search capabilities.

10.1.4.25 MM CDS containers and media collection binaries

10.1.4.25.1
[G UIDELINE ] Whenever possible a UPnP AV MediaServer should use a container object with a set
of child item objects to indicate a media collection.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 229 –

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC U7ZKE

29341-20-12

[C OMMENT] Using this model for media collections allows rendering devices to render media
collections. Media collection file formats are useful in various ways, but v1.0 DMPs might lack the
ability to parse media collection files.

10.1.4.25.2
[G UIDELINE ] A UPnP AV MediaServer may associate a <res> element with a CDS container or item
such that the <res> element's URI value points to a media collection file conforming to a Media
Format Profile defined in Media Collection Profile guidelines, see Clause 10 of IEC 62481-2 (e.g.
DIDL_S, DIDL_V).

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 52H79

29341-20-12
IEC 62481-2

[C OMMENT] Media collection files are a convenient way to allow a rendering device (e.g. DMR) to
play a media collection.

10.1.4.25.3
[G UIDELINE ] A UPnP AV MediaServer that advertises a <res> element for a media collection file
should also use the res@dlna:trackTotal attribute, which is a ui4 value.

This guideline applies only to media collection files that are normative to the DLNA guidelines (e.g.
DIDL_S and DIDL_V).

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC YHUXA

29341-20-12

[C OMMENT] Controlling devices (e.g. DMC, M-DMC) can use this value when the calculating track
index for the currently playing content in a DLNA PlayContainer URI operation.

10.1.4.25.4
[G UIDELINE ] If present, the value of res@dlna:trackTotal shall equal the number of content entries
(also known as sequenced tracks) in the media collection file.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC HUXAV

29341-20-12

10.1.4.25.5
[G UIDELINE ] If a UPnP AV MediaServer wants to convey that the items (or tracks) in a media
collection file have a 1:1 mapping to the child CDS objects in a particular container, then the UPnP
AV MediaServer should associate the <res> element (for the media collection file) with the CDS
container that has the child CDS objects. The ordering of the 1:1 mapping is the same for both the

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 230 –

media collection file and the CDS objects in the CDS container (as obtained from a CDS:Browse
request with an unspecified sorting criteria).

This methodology should be used even when the media collection file uses or references content
intended for presentation-layer details. A UPnP AV MediaServer that uses this methodology claims
an intent that the content in the media collection file maps to the child objects of the associated
container.

Note that CDS container in this guideline means any CDS object with the object.container or
similarly derived upnp:class designation.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 2H79M

29341-20-12

[C OMMENT] This guideline urges UPnP AV MediaServer that wants to represent the child CDS
objects encapsulated by a CDS container to associate a playlist file with the parent CDS container.

This guideline is only a recommendation because the file format of the media collection file could
reference things intended for the presentation layer. For example, a slideshow file might have URI
values that point to proprietary background music instructions and transitions. In such a case, the
MediaServer associates the slideshow file with a container that was the parent of image items
because the general intent is to have a 1:1 mapping.

10.1.4.25.6
[G UIDELINE ] If a UPnP AV MediaServer wants to convey that the items (or tracks) in media
collection file do not have a direct mapping to a particular container, then the MediaServer should
associate the <res> element (for the media collection file) with a CDS item that has the
object.item.playlistItem (or similarly derived upnp:class) designation.

This methodology should be used whenever the media collection file has an intentional mapping of
content in multiple CDS containers. Likewise, this methodology should be used when the media
collection file references content (that is not associated with presentation-layer details).

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 7ZKEU

29341-20-12

[C OMMENT] In cases where a vendor wants to provide a playlist file without implying any intent
about the mapping of that content to a particular CDS container, then the vendor is encouraged to
associate the media collection file with a CDS item object. This particular model (while easier for the
DMS or M-DMS) can disadvantage rendering devices (e.g. DMP) that do not support media
collection files because they rely solely on the CDS hierarchy to provide the rendering experience.

10.1.4.26 MM rendering media collection files

10.1.4.26.1
[G UIDELINE ] A Rendering Endpoint may support rendering of media collection files.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a ISO/IEC YTV3Y

29341-3-2

DLNA guidelines; Part 1-1: Architecture and protocols

 – 231 –

[C OMMENT] DMP, M-DMP and DMR devices are not required to render media collection files.

10.1.4.26.2
[G UIDELINE ] A UPnP AV MediaRenderer should support playback of a DLNA PlayContainer URI.

[ATTRIBUTES ]

S A DMR n/a n/a ISO/IEC HPZV4

29341-3-2

[C OMMENT] DMR devices are not required to support rendering of a DLNA PlayContainer URI
because the feature requires the DMR to have a MediaServer control point. However, this feature is
recommended for a DMR because DLNA recommends that DMS devices expose media collections
through CDS container objects that have a set of child CDS item objects.

Implementing this feature implies adherence to additional guidelines, such as those in 10.1.6.10
and 10.1.4.29.

10.1.4.26.3
[G UIDELINE ] If a UPnP AV MediaRenderer supports the DLNA PlayContainer URI operation, then
it shall specify the <dlna:X_DLNACAP> element (as a child of the <device> element that represents
the MediaRenderer) with the playcontainer-depth-strict token.

More formally, the syntax of the capability ID is as defined in Table 19.

Table 19 – Capability ID syntax

Capability ID Description

playcontainer-depth-strict The UPnP AV MediaRenderer supports the DLNA PlayContainer

URI operation.

• "playcontainer-capability-id = "playcontainer" "-" depth-token "-" strict-token

• "depth-token = < ui4 value >
• "strict-token = "0" | "1"
The "playcontainer" portion of the capability ID is a literal, string value.
The depth-token shall be a ui4 value, indicating the maximum depth the MediaRenderer will traverse when
rendering a PlayContainer URI operation. A value of "0" means that no sibling containers of first-item-id-arg will
be traversed.
The strict-token portion of the capability shall be a "0" or "1". If the value is "1" then MediaRenderer supports a
URI syntax where first-item-id-arg shall be a an immediate child of container-id. If the value is "0" then
MediaRenderer supports a URI syntax where first-item-id-arg shall be a descendent of container-id-arg and the
parent of first-item-id-arg shall have a container depth that is less than or equal to depth.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC QA9W8

29341-3-2

[C OMMENT] Guideline 9.2.35.1 provides the syntax for the <dlna:X_DLNACAP> element.

In addition to indicating that the DLNA PlayContainer URI operation is supported by the
MediaRenderer, the capability ID also indicates the URI limitations that are imposed by the
MediaRenderer. The depth portion of the syntax allows the MediaRenderer to restrict the CDS

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 232 –

container depth of a media collection. The strict portion of the syntax allows the MediaRenderer to
require the first played CDS item to be an immediate child of the media collection's top CDS
container. 10.1.4.29 gives more information on the DLNA PlayContainer URI syntax.

10.1.4.27 MM CDS DLNA PlaySingle URI values

10.1.4.27.1
[G UIDELINE ] A UPnP AV MediaServer may have CDS item objects that have a <res> element with
a DLNA PlaySingle URI.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 57CYQ

29341-20-12

[C OMMENT] A DLNA PlaySingle URI is a URI that allows a DMS or M-DMS to reference a CDS
object on the same or different DMS or M-DMS. This can be used for a variety of things, including a
media collection composed of content from multiple DMS or M-DMS devices or for DMS
virtualization.

10.1.4.27.2
[G UIDELINE ] A <res> element with a DLNA PlaySingle URI value shall have a similar
res@protocolInfo value as one of the <res> elements of the referenced CDS object.

A similar res@protocolInfo value has the following characteristics.

• The first field shall be a string in the form of "playsingle-"<transport>, where the transport shall
be the DLNA transport identifier of the referenced <res> element.
• The 2nd, 3rd, and 4th fields shall be copied identically from the referenced <res> element.
Examples:
playsingle-http-get:*:audio/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;
DLNA.ORG_OP=01;DLNA.ORG_FLAGS=01100000000000000000000000000000
playsingle-rtsp-rtp-udp:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;
DLNA.ORG_OP=10;DLNA.ORG_PS=-1,2/3,4;
DLNA.ORG_FLAGS=03100000000000000000000000000000;DLNA.ORG_MAXSP=9.75

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WOIWZ

29341-20-12

[C OMMENT] DLNA PlaySingle URI values can only have a single protocolInfo value. Therefore, a
single CDS object can have more than one <res> element with the same DLNA PlaySingle URI
value and the different protocolInfo values. This allows UPnP AV MediaServer control points to
know the media formats that are available on the referenced CDS object.

10.1.4.27.3
[G UIDELINE ] A UPnP AV MediaServer may have more than one <res> element with the same DLNA
PlaySingle URI associated with a CDS item object.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC QVGY4

29341-20-12

DLNA guidelines; Part 1-1: Architecture and protocols

 – 233 –

10.1.4.27.4
[G UIDELINE ] A CDS item that has one or more DLNA PlaySingle URI <res> elements may have
other <res> elements that do not have a DLNA PlaySingle URI as a value.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 2VOMJ

29341-20-12

[C OMMENT] A MediaServer's CDS item can mix <res> elements that have different types of URI
values. For example, a virtual DMS might have DLNA PlaySingle URI values for original content
served by a different DMS while using RTP and HTTP URI values for the converted content that the
virtualizing DMS will serve.

10.1.4.27.5
[G UIDELINE ] A UPnP AV MediaServer shall only associate DLNA PlaySingle URI <res> elements
with CDS item objects. DLNA PlaySingle URI <res> elements shall not be associated with CDS
container objects. DLNA PlaySingle URI <res> elements shall not reference CDS container objects.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 3YS5B

29341-20-12

[C OMMENT] DLNA PlaySingle URI values are allowed only when used in conjunction with audio,
audio/video, or image content. Using DLNA PlaySingle URI <res> elements to reference CDS
containers, media collection files, or other CDS objects with a DLNA PlaySingle URI <res> element
can result in circular references.

10.1.4.27.6
[G UIDELINE ] The res@protocolInfo value of a DLNA PlaySingle URI <res> element shall reference
content that qualifies as audio, audio/video, or image content.

A res@protocolInfo value that identifies a media collection file is prohibited. Similarly, a <res> DLNA
PlaySingle URI value that references a media collection file is also prohibited.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC U4ZMV

29341-20-12

10.1.4.27.7
[G UIDELINE ] A DLNA PlaySingle URI shall only reference a CDS item object that does not have a
DLNA PlaySingle URI <res> element.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 4ZMVW

29341-20-12

10.1.4.27.8
[G UIDELINE ] A DLNA PlaySingle URI shall only reference a CDS item object with a upnp:class that
is the same or derived from one of the following:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 234 –

• object.item.audioItem.
• object.item.videoItem.
• object.item.imageItem.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC YS5BS

29341-20-12

10.1.4.27.9
[G UIDELINE ] A CDS item that has a DLNA PlaySingle URI <res> element shall have the same
upnp:class value as the CDS object that is referenced or one of its super classes.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VOMJU

29341-20-12

10.1.4.27.10
[G UIDELINE ] A DLNA PlaySingle URI may be used with Media Format Profiles that are not defined
by DLNA.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC VGY43

29341-20-12

[C OMMENT] The DLNA PlaySingle URI values can be used with undefined media formats. In such
scenarios, the DLNA PlaySingle URI value still needs to comply with all the rules declared in
guidelines of 10.1.4.27.

10.1.4.27.11
[G UIDELINE ] The syntax of DLNA PlaySingle URI is as follows.

• dlna-playsingle-uri = "dlna-playsingle://" cds-udn "?" service-id-arg item-id-arg

• cds-udn = <the UDN of the UPnP AV MediaServer device>
• service-id-arg = "sid=" service-id-val
• service-id-val = <service ID of the CDS belonging to the MediaServer>
• item-id-arg = "&iid=" item-id-val
• item-id-val = <The @id string value of the CDS item to be referenced. The CDS item shall comply
with guidelines 10.1.4.27.6 to 10.1.4.27.8>
PlaySingleURI values shall be case-sensitive values, even though the general URI syntax is a
case-insensitive value. The URI shall also be escaped as described by 10.1.3.10.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC OIWZO

29341-20-12

10.1.4.28 MM control point rules for DLNA PlaySingle URIs

10.1.4.28.1
[G UIDELINE ] A UPnP AV MediaRenderer control point shall not invoke AVT:SetAVTransportURI
with the CurrentURI input argument set to a DLNA PlaySingle URI.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 235 –

[ATTRIBUTES ]

M A DMC +PU+ M-DMC n/a ISO/IEC 7CYQB

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] See 10.1.4.28.3 for more information.

10.1.4.28.2
[G UIDELINE ] DLNA device classes and capabilities with a UPnP AV MediaServer control point and
appropriate transport layer components may support the rendering or transporting of content
referenced by DLNA PlaySingle URI values.

[ATTRIBUTES ]

O A DMP DMR +DN+ M-DMP n/a ISO/IEC A9W8G

29341-20-3

[C OMMENT] DMP, DMR, and Download Controllers are not required to render or transport DLNA
PlaySingle URIs.

10.1.4.28.3
[G UIDELINE ] A UPnP AV MSCP+MRCP that wants to instruct a UPnP AV MediaRenderer to play a
DLNA PlaySingle URI shall resolve the DLNA PlaySingle URI to a URI for the actual audio,
audio/video, or image content for use with the AVT:SetAVTransportURI request.

[ATTRIBUTES ]

M A DMC M-DMC n/a ISO/IEC PZV4Y

29341-14-10
ISO/IEC
29341-3-2
ISO/IEC
29341-20-3

[C OMMENT] Prior to invoking a AVT:SetAVTransportURI, the control point will set up a UPnP AV
connection between the DMR and the Content Source. Since a DLNA PlaySingle URI is a URI
pointer to a CDS object (and is not a pointer to an actual content binary), the MediaRenderer control
point does not have sufficient information to create the logical connection prior to invoking
AVT:SetAVTransportURI.

10.1.4.29 MM DLNA PlayContainer URI

10.1.4.29.1
[G UIDELINE ] The syntax of a DLNA PlayContainer URI shall be as described in the BNF notation.
Assume no linear white space.

• dlna-playcontainer-uri = "dlna-playcontainer://" cds-udn "?" service-id-arg container-id-arg

first-item-id-arg first-item-index-arg [sort-arg] [max-depth-arg]
• cds-udn = <the UDN of the UPnP AV MediaServer device>
• service-id-arg = "sid=" service-id-val
• service-id-val = <service ID of the CDS belonging to the MediaServer>
• container-id-arg = "&cid=" container-id-val
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 236 –

• container-id-val = <The @id string value of the CDS container that represents the top container
of the media collection.>
• first-item-id-arg = "&fid=" first-item-id-val
• first-item-id-val = <The @id string value of the first CDS item that will be played as part of the
PlayContainer URI operation. Note that 10.1.4.26.3 (MM Rendering Media Collection Files)
places restrictions on first-item-id-val. Specifically, if the strict-token (defined in 10.1.4.26.3) is
"1", then first-item-id-val shall be a CDS item that is an immediate child of container-id-val. If
strict-token is "0", then first item-id-val shall be a CDS item that is descended from
container-id-val, whose parent container has a container depth that is less than or equal to the
depth-token (defined in 10.1.4.26.3).>
• first-item-index-arg = "&fii=" first-item-index-val first-item-index-val = <a ui4 value, as used in a
CDS:Browse request. This value shall represent the zero-based index of the first-item-id-val
CDS item, such that a CDS:Browse request where the following argument values will result in a
response where the first returned CDS item has @id = first=item-id-val.
– ObjectID = parent container of first-item-id-val
– BrowseFlag = "BrowseDirectChildren",
– SortCriteria = sort-arg, and
– StartingIndex = first-item-index-val
• sort-arg = "&sc=" sort-val
• sort-val = <A SortCriteria string, as defined for a CDS:Browse request. Equivalently, the value
shall comply with the A_ARG_TYPE_SortCriteria syntax, defined by the ContentDirectory
service. If sort-arg is omitted, then assume an effective value of an empty string.>
• max-depth-arg = "&md=" max-depth-val
• max-depth-val = <A ui4 value that specifies the maximum descent level in the container. If
max-depth-arg is omitted, then the value infers an effective value of "0". Note that 10.1.4.26.3
(MM Rendering Media Collection Files) places restrictions on max-depth-arg. Specifically the
max-depth-val shall be less than or equal to the depth-token, as defined in 10.1.4.26.3.>
The cds-udn, service-id-val, object-id-val, sort-val, object-index-val, and max-depth-val tokens
shall be URI-escaped according to IETF RFC 2396.

Ordering of tokens is significant.

The maximum length of a DLNA PlayContainer URI is 1 024 B.

[ATTRIBUTES ]

M A DMC +PU+ M-DMC n/a IETF RFC TV3Y4

2396
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline defines the syntax of a DLNA PlayContainer URI.

10.1.4.29.2
[G UIDELINE ] If a UPnP AV MediaRenderer supports the DLNA PlayContainer URI operation, then
the MediaRenderer shall support the sort-arg and max-depth-arg portions of the
dlna-playcontainer-uri syntax.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 237 –

• sort-arg: This value determines the playback order, such that the playback order matches the
order as observed from an equivalent CDS:Browse response.
• max-depth-arg: This value determines the maximum depth the MediaRenderer traverses when
encountering child/descendent containers. A value of "0" means that child/descendent are not
traversed.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC ZKEU4

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] These guidelines clarify that control points are not required to specify all parameters in
a DLNA PlayContainer URI, but a DMR will operate correctly if a control point does provide the
optional parameters.

A DLNA PlayContainer URI does not necessarily mean that the DMR will issue a single type of
CDS:Browse request. For example, the DMR's control point might progressively issue multiple
CDS:Browse requests that result in fewer results to ensure that the 200 KiB response limit is not
exceeded by the DMS.

10.1.4.29.3
[G UIDELINE ] If a UPnP AV MediaRenderer supports the DLNA PlayContainer URI operation and
the URI specifies a max-depth-val that is greater than depth-token, as defined in 10.1.4.26.3, then
the MediaRenderer shall return a UPnP AV error code of 716 (Resource not found) in the
AVT:SetAVTransportURI response.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC H79M4

29341-20-3

10.1.4.29.4
[G UIDELINE ] If performing a DLNA PlayContainer URI operation, a UPnP AV MediaRenderer shall
only play CDS items as part of the DLNA PlayContainer URI and shall only render <res> elements
of images, Audio-only, and AV content. This guideline works in conjunction with 10.1.3.32.1 (MM
playcontainer-param (DLNA PlayContainer Flag), which prohibits the playcontainer-param from
having a value of true for <res> elements of media collection binaries.

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC UXAV4

29341-3-2
ISO/IEC
29341-20-3

10.1.4.29.5
[G UIDELINE ] MediaRenderer control points may omit the sort-arg, and max-depth-arg tokens in the
dlna-playcontainer-uri syntax.

[ATTRIBUTES ]

O C DMC +PU+ M-DMC n/a ISO/IEC XAV44

29341-3-2
ISO/IEC
29341-20-3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 238 –

[C OMMENT]

Figure 16 below provides an implementation example for this guideline.

Collection, container- First-item First-item max-depth Default Track Index:

start at id-arg id-arg index-arg -arg Ordered tracks item-AVT.CurrentT
in collection e rack Index
“i1” “c3” “i1” “0” Value >= i1, i2, i3, i4 “i1”à1, “i2”à2,
“0” or “i4”à4
omitted
“i6” “c4” “i6” “1” Value .= i6, i7, i8, i5 a “i6”à2, “i8”à4,
“0” or “i5”à1
omitted
“c3” This is not permitted because first-item-id-arg shall be a CDS item
If first-item-id-arg was “i1”, then playcontainer-strict shall be false (see next line/playlist)
“i1” “c2” “i1” “0” Value .= i1, i2, …i4, i5, … “i1”à1, “i8”à8
“1” i8; a
“i12” “c1” “i12” “4” b Value = “0” i12, i9, i10, i11 “i12”à4, “i9”à1,
or omitted “i11”à3
“i1” “c1” “i1”; c “0” Value >= i1, i2, i3, i4, i5, “i1”à1, “i4”à14,
“2” i6, i7, i8, i9, i10, “i5”à5, “i8”à8,
11, i12 “i9”à10, “i12”à13;
d

“i9” “c1” “i9” “1” Value .>= i9, i10, i11, i12, “i9”à10, “i12”à13,
“2” i1, i2, i3, i4, i5, “i1”à1, “i4”à4,
i6, i7, i8 “i5”à5, “i8”à8; d
a Although “p1” is child of “c4”, it is a CDS object with DIDL playlist file so it is automatically skipped.
b “c2” is a child of “c1” that appears before “i9” when browsing the DMS.
c This scenario is only permitted when playcontainer-strict is false.
d Tracks after “i9” have an index number that is off by one because of p1, which is a CDS object with a
DIDL-Lite playlist file. Also note that CDS containers are not rendered during a PlayContainer URI operation.
e DMR shall follow the current AVT.PlayMode (i.e. in case of NORMAL play mode, it shall stop after playing the
track of maximum AVT.CurrentTrack).

Figure 16 – DLNA PlayContainer URI example

10.1.4.30 MM control point rules for DLNA PlayContainer URI

10.1.4.30.1
[G UIDELINE ] A UPnP AV MediaRenderer control point may invoke AVT:SetAVTransportURI with
the CurrentURI input argument set to a DLNA PlayContainer URI.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 239 –

[ATTRIBUTES ]

O A DMC +PU+ M-DMC n/a ISO/IEC 79M4Q

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] The usage of the DLNA PlayContainer URI requires the existence of a CDS at the
content source. For this reason, a +PU+ can send the DLNA PlayContainer URI when its hosting
Device Class contains a CDS or can interact with a CDS on the network.

10.1.4.30.2
[G UIDELINE ] If a UPnP AV MediaRenderer control point that invokes AVT:SetAVTransportURI with
the CurrentURI input argument set to a DLNA PlayContainer URI, then the UPnP AV
MediaRenderer control point shall only do so with UPnP AV MediaRenderer devices that have at
least one protocolInfo value in the SinkProtocolInfo that has the playcontainer-param flag set to
true.

SinkProtocolInfo refers specifically to the Sink output argument of CMS:GetProtocolInfo responses

and the CMS.SinkProtocolInfo state variable.

[ATTRIBUTES ]

M A DMC +PU+ M-DMC n/a ISO/IEC KEU4V

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-3-2

[C OMMENT] See 10.1.3.24.2 and 10.1.3.32 for more information.

10.1.5 Basic Connection Management (BCM) guidelines

10.1.5.1 MM/BCM UPnP AV connection rules
10.1.5.1.1
[G UIDELINE ] UPnP AV MediaServers may provide support for basic connection management
(BCM).

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC V3Y4Y

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] DMS devices are not required to support basic connection management (BCM). A
DMS with BCM reports the existence of transport layer connections by using UPnP AV connections,
which might be enumerated and terminated. This feature helps 3rd party controllers and DMPs offer
the users the ability to manage the connections according to their own desires (mainly for
termination). This feature does not require any control point to support Basic Connection
Management in order to operate basic browse/play operations. This feature does not require a
control point to interact with the user.

Transport clients are encouraged to implement these guidelines to allow MediaServers with BCM
support to properly deliver BCM functionality:
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 240 –

• 11.4.3.35 MT/BCM HTTP header:peerManager.dlna.org

• 11.4.3.36 MT/BCM HTTP header:friendlyName.dlna.org
• 11.4.4.155 MT RTP/BCM RTSP peerManager.dlna.org
• 11.4.4.156 MT RTP/BCM RTSP friendlyName.dlna.org
The DLNA guidelines use the AVT:Stop action to terminate streams on a DMR instead of using
CMS:ConnectionComplete.

10.1.5.1.2
[G UIDELINE ] If a UPnP AV MediaServer supports the BCM, then it shall create a UPnP AV
Connection with a unique ConnectionID for each new Transport Layer request corresponding to a
content request, including Background, Interactive, and Streaming requests. (Creating UPnP AV
Connections for upload-related content transfer process is out-of-scope.)

The list of Transport Layer requests corresponding to a media stream request includes HTTP GET
requests and the RTSP SETUP command. The list of Transport Layer requests excludes HTTP
HEAD and HTTP POST requests and all HTTP requests not related to a content URI (i.e. URI for a
<res> element exposed by a UPnP AV MediaServer).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC ZV4YE

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] The creation of UPnP AV Connection is a result of a Transport Layer (HTTP or RTSP)
connection request for a new media stream. (See 10.1.5.2 for request for an existing media stream).
All other non media stream connection requests do not require the creation of UPnP AV Connection.
The media stream is identified by the content URI in the transport layer request.

CMS:PrepareForConnection is not required for the creation of a UPnP AV Connection. However,

using CMS:PrepareForConnection in conjunction with the creation of a transport layer is a
permissible way to create UPnP AV Connection. Note that a UPnP AV MediaServer control point is
not required to call the optional CMS:PrepareForConnection. Hence a DMS with BCM that also
implements CMS:PrepareForConnection will also be able to create the UPnP AV Connection
without requiring a control point to call CMS:PrepareForConnection execution.

The UPnP AV Media Server preferably stores internally all necessary information along with the
newly created ConnectionID for later actions (CMS:ConnectionComplete and
CMS:GetCurrentConnectionInfo). For example, relevant information is, but is not limited to,
protocolInfo, URI, and TCP/IP socket handles. The protocolInfo is already available in the DMS to
satisfy 11.4.3.11.

10.1.5.1.3
[G UIDELINE ] A UPnP AV MediaServer that assigns a ConnectionID value in the range from "1" to
"2147483647" should assign the value in an increasing manner with a rollover value of "1" when the
vendor-defined-maximum-value is exceeded.

The vendor-defined-maximum-value is a vendor-defined value that is greater than or equal to

"65535" and less than or equal to "2147483647".

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 9W8GK

29341-14-11

DLNA guidelines; Part 1-1: Architecture and protocols

 – 241 –

ISO/IEC
29341-20-3

10.1.5.1.4
[G UIDELINE ] A UPnP AV MediaServer that assigns a ConnectionID value in the range from "1" to
"2147483647" should start value assignment with a random value.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC CYQBA

29341-14-11
ISO/IEC
29341-20-3

10.1.5.1.5
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall expose the UPnP AV
Connections using CMS:GetCurrentConnectionIDs.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC IWZOH

29341-14-11
ISO/IEC
29341-20-3

10.1.5.1.6
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall remove the ConnectionID from
the list of connections provided in CMS:GetCurrentConnectionIDs, when all transport layer
connections (associated with the ConnectionID) are closed/terminated.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC GY43Y

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] The guideline clarifies the life-cycle of a ConnectionID. An active and advertised
ConnectionID will be associated with at lease one active media transport connection.

10.1.5.1.7
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall maintain the
CMS.CurrentConnectionIDs state variable and deliver an event for the ConnectionManager service
to signal that an update to the connection information has occurred.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC OMJU4

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] The guideline repeats the UPnP AV requirements.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 242 –

10.1.5.1.8
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall implement
CMS:GetCurrentConnectionInfo for all UPnP AV Connections reported by
CMS:GetCurrentConnectionIDs.

The following arguments and values are returned by CMS:GetCurrentConnectionInfo:

• RemoteProtocolInto contains the res@protocolInfo of the transported content on the given

connection. The value corresponds to the protocolInfo used to set the contentFeatures.dlna.org
HTTP header or RSTP header according to 11.4.3.11 and 11.4.4.194.
• PeerConnectionManager contains
• an empty string if the information is not available, or
• the PeerConnectionManager value provided by a DMR using the peerManager.dlna.org
HTTP header (defined in 11.4.3.35) or the peerManager.dlna.org RTSP header (defined in
11.4.4.155),
• the friendly name value provided by a DMP or M-DMP (that implements this version or a
newer version of the DLNA interoperability guidelines) using the friendlyName.dlna.org
HTTP header (defined in 11.4.3.36) or the friendlyName.dlna.org RTSP header (defined in
11.4.4.156).
• PeerConnectionID is set to "−1".
• Direction is set to "OUT".
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC S5BS2

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] This guideline specifies the values returned by CMS:GetCurrentConnectionInfo for a

given ConnectionID. Most arguments are compliant with the UPnP AV Architecture with the
exeption of PeerConnectionManager, which is not available for M-DMP implementations that
adheres to v1.0 of the DLNA interoperability guidelines.

CMS:PrepareForConnection can also provide the PeerConnectionManager value when executed

previously for the specifed UPnP AV Connection.

10.1.5.1.9
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall use the following notation to
advertise a DMP or M-DMP user friendly name (when provided) in the PeerConnectionManager
parameter, returned by CMS:GetCurrentConnectionInfo.

• peerconnectionmanager_arg = "fnam" ":" friendly-name "/"

• friendly-name = <string, limited to 128 B in its UTF-8 encoded form>
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC ZMVW7

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] The DMP user friendly name is provided on the Media Transport layer connection (see

DLNA guidelines; Part 1-1: Architecture and protocols

 – 243 –

11.4.3.36 or 11.4.4.156) and is used to identify the Content Receiver connected to the DMS or
M-DMS.

The format of the PeerConnectionManager is different from the UPnP Architecture in such a way
that it cannot be confused with a non-existing CMS Service (i.e: no CMS on DMP).
Example: "fnam:LivingRoom TV/" where "fnam" replaces "uuid" and the ServiceId token is left
empty.

10.1.5.1.10
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall implement
CMS:ConnectionComplete.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC MVW74

29341-14-11
ISO/IEC
29341-20-3

[C OMMENT] The requirement for CMS:ConnectionComplete does not imply to support and
implement CMS:PrepareForConnection in the ConnectionManager service.

CMS:ConnectionComplete is the UPnP action that instructs a UPnP MediaServer to tear down a
UPnP AV Connection (and its underlying transport layer connection) when it is no longer required.
When CMS:ConnectionComplete is executed for a given ConnectionID, the device is expected to
respond with a success and terminate the associated HTTP or RTSP transport connections related
to the UPnP AV Connection. Subsequently, all resources related to the connection are released.
This behavior is similar to a termination initiated by the connection creator on the Content Receiver
endpoint. When a connection is terminated (e.g. DMP performs a Stop media operation, AVT:Stop
is invoked on a DMR, the transport layer connection is broken, CMS:ConnectionComplete is called,
etc.) it is expected that proper resource clean up takes place.

10.1.5.2 MM/BCM UPnP AV connection rules for HTTP

[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall not create a new UPnP AV
Connection when the ConnectionID is provided in the HTTP Request using the scid.dlna.org header.
Instead it shall reuse the provided ConnectionID.

[ATTRIBUTES ]

M L DMS M-DMS n/a n/a 5BS2H

[C OMMENT] This guideline provides a mechanism to identify a multiple transport layer request
separated in time but related to the same media stream (identified by the URI). For example, during
a pause operation and/or consecutive random access requests the HTTP Client might indicate in
the HTTP Get request that all transport layer requests are related to the same media stream which
does not require a new ConnectionID. With such mechanism the UPnP AV MediaServer is not
required to maintain a local table containing the most recent requested URI with the associated
ConnectionID per HTTP client. It is the HTTP client's responsibility to indicate the relationship
between HTTP requests.

10.1.5.3 MM/BCM UPnP AV connection rules for RTP

[G UIDELINE ] If a UPnP AV MediaServer supports BCM and it supports RTP Media Transport, then
it shall not create a new UPnP AV Connection when the ConnectionID is provided in the RTSP
session-id header. Instead it shall reuse the provided ConnectionID.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 244 –

[ATTRIBUTES ]

M L DMS M-DMS n/a n/a MJU4Z

10.1.5.4 MM/BCM-DMS CMS:ConnectionComplete and closing transport connections

10.1.5.4.1
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then when it responds successfully to a
CMS:ConnectionComplete request for a valid ConnectionID it shall close all related Transport Layer
connections.

Likewise, the corresponding ConnectionID shall be removed from the list of connections provided in
CMS:GetCurrentConnectionIDs.

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a Y43YT

[C OMMENT] This guideline clarifies the expected behavior when UPnP MediaServers responds
successfully to a CMS:ConnectioComplete. The guideline does not prohibit a UPnP MediaServer to
return an error code (for example 704 Local Restriction) to indicate the impossibility to close the
Transport Layer connections.

10.1.5.4.2
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall return 704 Local Restriction to
the CMS:ConnectionComplete request if it does not accept to close all related Transport Layer
connections.

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a WZOH4

10.1.6 MediaRenderer device requirements

10.1.6.1 MM UPnP AV MediaRenderer CMS:GetProtocolInfo behavior
10.1.6.1.1
[G UIDELINE ] A UPnP AV MediaRenderer that lists a protocolInfo in its SinkProtocolInfo shall be
able to render that type of content when given a URI for that type of content.

SinkProtocolInfo refers specifically to the Sink output argument of CMS:GetProtocolInfo responses

and the CMS.SinkProtocolInfo state variable.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC YQBA6

29341-14-11
ISO/IEC
29341-3-2

[C OMMENT] DMR devices that claim support for a DLNA Media Format Profile will be able to render
that content when instructed to do so by a DMC. A DMR device that supports playback of content but
requires a control point to send a URI to a media collection file or a DLNA PlayContainer URI in the
AVT:SetAVTransportURI request is not permissible.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 245 –

10.1.6.1.2
[G UIDELINE ] A UPnP AV MediaRenderer that supports playback of media collection files shall
include the media collection file's protocolInfo value in its list of SinkProtocolInfo (as observed from
the Sink output argument in CMS:GetProtocolInfo responses and its CMS.SinkProtocolInfo state
variable).

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC W8GKW

29341-14-11
ISO/IEC
29341-3-2

[C OMMENT] DMR uses protocolInfo values to report support for media collection files. Media
collection files have mime types and Media Format Profile IDs. DMR devices are not required to
support playback of media collection files because the feature requires a DMR to implement a
MediaServer control point.

10.1.6.2 MM AVTransport default instance

[G UIDELINE ] A UPnP AV MediaRenderer shall always have an AVTransport virtual instance
identified with an InstanceID equal to "0".

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC 3Y4Y3

29341-14-10

[C OMMENT] This represents the "default" instance of the AVTransport service. This allows UPnP
AV MediaServer control points to assume that the virtual instance with InstanceID value of "0" is
always available. There is no need to invoke CMS:PreparForConnection when using default
instances.

10.1.6.3 MM RenderingControl default instance

[G UIDELINE ] A UPnP AV MediaRenderer shall always have a RenderingControl virtual instance
identified with an InstanceID equal to "0".

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC 9M4Q9

29341-3-13

[C OMMENT] This represents the "default" instance of the RenderingControl service. This allows
UPnP AV MediaRenderer control points to assume that the virtual instance with InstanceID value of
"0" is always available. There is no need to invoke CMS:PrepareForConnection when using default
instances.

10.1.6.4 MM AVTransport multiple instances

[G UIDELINE ] A UPnP AV MediaRenderer may have multiple virtual instances of the AVTransport
service.

[ATTRIBUTES ]

O R DMR n/a n/a ISO/IEC V44KU

29341-14-11

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 246 –

[C OMMENT] Multiple virtual instances of the AVTransport service will include the default instance
(InstanceID = 0) as per guideline 10.1.6.2. Multiple virtual instances of the AVTransport service are
permitted but DLNA defines no interoperability guidelines for InstanceIDs that are not equal to "0".

10.1.6.5 MM RenderingControl multiple instances

[G UIDELINE ] A UPnP AV MediaRenderer may have multiple virtual instances of the
RenderingControl service.

[ATTRIBUTES ]

O R DMR n/a n/a ISO/IEC M4Q9J

29341-14-11

[C OMMENT] Multiple virtual instances of the RenderingControl service will include the default
instance (ID = 0) as per guideline 10.1.6.3. Multiple virtual instances of the RenderingControl
service are permitted, but DLNA defines no interoperability guidelines for InstanceIDs that are not
equal to 0.

10.1.6.6 MM LastChange
10.1.6.6.1
[G UIDELINE ] UPnP MediaRenderers shall implement the AVT.LastChange and RCS.LastChange
evented state variables as specified in ISO/IEC 29341-14-10 and ISO/IEC 29341-3-13.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC U4VW4

29341-14-10
ISO/IEC
29341-3-13

[C OMMENT] All AVT and RCS state variables, except AVT.RelativeTimePosition,

AVT.AbsoluteTimePosition, AVT.RelativeCounterPosition and AVT.AbsoluteCounterPosition, are
evented indirectly through the AVT.LastChange and RCS.LastChange state variables as described
in ISO/IEC 29341-3-13.

10.1.6.6.2
[G UIDELINE ] If any of the instance state variables in the AVTransport Service or Rendering Control
Service, except AVT.RelativeTimePosition, AVT.AbsoluteTimePosition,
AVT.RelativeCounterPosition and AVT.AbsoluteCounterPosition, have changed, a UPnP
MediaRenderer shall send an event containing the corresponding LastChange state variable. The
content of the LastChange state variable shall contain the latest value of the state variables updated
since the last event. The event shall be sent immediately, or 0,2 s after the last event was sent,
whichever is later.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 95C3Y

29341-14-10
ISO/IEC
29341-3-13

[C OMMENT] This guideline enables control points to rely on UPnP events to track the playback
status of the MediaRenderer device.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 247 –

The Max Event Rate of the AVT.LastChange and RCS.LastChange state variables is one event
every 0,2 s, which translates to a maximum of five events per second, or a minimum of 0,2 s
between successive events.
As an example, if the values of AVT.TransportState and AVT.TransportURI instance state variables
of instance 0 of the AVTransport service change to "TRANSITIONING" and
"http://192.168.0.1:8080/MPEG/ntsc001.mpg" respectively, the value of the AVT.LastChange state
variable in an event sent by the AVTransport service contains the following text (prior to
XML-escaping).

<Event xmlns="urn:schemas-upnp-org:metadata-1-0/AVT/">
<InstanceID val="0">
<TransportState val="TRANSITIONING" />
<AVTransportURI val="http://192.168.0.1:8080/MPEG/ntsc001.mpg" />
</InstanceID>
</Event>
Similarly, if the values of RCS.Brightness and RCS.Contrast instance state variables of instance 0
of the Rendering Control service change to "20" and "50" respectively, the value of the
RCS.LastChange state variable in an event sent by the Rendering Control service contains the
following text (prior to XML-escaping).

<Event xmlns="urn:schemas-upnp-org:metadata-1-0/RCS/">
<InstanceID val="0">
<Brightness val="20 " />
<Contrast val="50" />
</InstanceID>
</Event>
10.1.6.6.3
[G UIDELINE ] UPnP MediaRenderers shall not send AVT or RCS events with empty values for the
LastChange state variable, except when sending the first event after a subscription.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC QR39T

29341-14-10
ISO/IEC
29341-3-13

[C OMMENT] Sending empty events is a waste of both network and device resources.

10.1.6.7 MM LastChange frequency

[G UIDELINE ] UPnP MediaRenderers should send no more than one AVT.LastChange or
RCS.LastChange event for a single AVTransport or RenderingControl service action.

[ATTRIBUTES ]

S A DMR n/a n/a ISO/IEC Y4Y37

29341-14-10
ISO/IEC
29341-3-13

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 248 –

[C OMMENT] Although UPnP AV has a maximum frequency for sending AVTransport and
RenderingControl events, the preference is to send fewer events to reduce the load on control
points.

10.1.6.8 MM AVT:SetAVTransportURI
10.1.6.8.1
[G UIDELINE ] If a UPnP AV MediaRenderer receives an AVT:SetAVTransportURI request and the
current value of the AVT.TransportState virtual instance state variable is not "STOPPED" or
"NO_MEDIA_PRESENT", then the UPnP AV MediaRenderer may return an error 705 (Transport is
Locked) in addition to other errors defined in ISO/IEC 29341-14-10.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC 4YEOC

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline requirement is an addition to ISO/IEC 29341-14-10.

If a UPnP AV MediaRenderer control point encounters the 705 error code, then it can invoke
AVT:Stop to stop the transport layer and then retry the AVT:SetAVTransportURI request followed by
the AVT:Play request.

There can be reasons for the UPnP AV MediaRenderer to return an error, when the transport state
is changed to STOPPED following the AVT:Stop or AVT:Play requests.

10.1.6.8.2
[G UIDELINE ] A UPnP AV MediaRenderer control point shall provide an empty string or a valid URI
value, as defined in 10.1.3.10, in the CurrentURI input argument for an AVT:SetAVTransportURI
request.

[ATTRIBUTES ]

M C DMC +PU+ M-DMC n/a ISO/IEC QQ8QS

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This clarifies that an empty string can be used as a URI value in the CurrentURI input
argument to clear the rendering state.

10.1.6.8.3
[G UIDELINE ] If the CurrentURI input argument for the AVT:SetAVTransportURI request is not an
empty string or a DLNA PlayContainer URI, then the CurrentURIMetaData input argument of the
same request shall be a valid value, as defined in 10.1.6.14.8.

[ATTRIBUTES ]

M A DMC +PU+ M-DMC n/a ISO/IEC USRWQ

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This is a mandate over what UPnP normally allows as optional behavior.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 249 –

For a Push Controller (+PU+) that does not contain a CDS, the DIDL-Lite metadata can typically be
created from a DIDL-Lite XML fragment template containing only the minimal properties as
described in 10.1.6.14.8 or example, since the @id property value only needs to be unique within
the scope of the DIDL-Lite XML fragment, the @id property value can be any value chosen by the
Push Controller; the @parent property can have a value of −1, and the @restricted property value
can be either 0 or 1.

10.1.6.8.4
[G UIDELINE ] If the CurrentURI input argument for the AVT:SetAVTransportURI request contains
the URI of a media collection file, then the CurrentURIMetaData input argument of the same request
shall contain only one <res> element and its URI value shall be the same as the value contained in
the CurrentURI input argument.

[ATTRIBUTES ]

M A DMC +PU+ M-DMC n/a ISO/IEC G3HWW

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] Metadata for a media collection is only meaningful for a single <res> CDS object.

10.1.6.8.5
[G UIDELINE ] If the CurrentURI input argument for the AVT:SetAVTransportURI request contains a
DLNA PlayContainer URI, then the CurrentURIMetaData input argument of the same request shall
be an empty string.

[ATTRIBUTES ]

M A DMC +PU+ M-DMC n/a ISO/IEC OVM6G

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] Metadata has no meaning for the DLNA PlayContainer URI case.

10.1.6.8.6
[G UIDELINE ] If the CurrentURI input argument for the AVT:SetAVTransportURI request is an empty
string, then the CurrentURIMetaData input argument of the same request should be an empty string.

[ATTRIBUTES ]

S A DMC +PU+ M-DMC n/a ISO/IEC 3HWWT

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] Metadata has no meaning when the CurrentURI input argument is an empty string (i.e.
no content to be rendered). The behavior for the UPnP AV MediaRenderer is vendor dependent
when metadata is provided (some UPnP AV MediaRenderers will select a <res> element from the
metadata to render as per guideline requirement 10.1.6.9.1; other UPnP AV MediaRenderers will
reset the rendering state.)

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 250 –

10.1.6.9 MM UPnP AV MediaRenderer selects a different <res> element

10.1.6.9.1
[G UIDELINE ] A UPnP AV MediaRenderer that receives an AVT:SetAVTransportURI request may
override the CurrentURI input argument by selecting one of the <res> elements specified in the
CurrentURIMetaData input argument.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC 8GKWS

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] The general purpose is to allow a UPnP AV MediaRenderer control point to

recommend a URI using the CurrentURI input argument while providing alternate choices to the
UPnP AV MediaRenderer through the CurrentURIMetaData input argument of the
AVT:SetAVTransportURI action.

If a UPnP AV MediaServer exposes multiple <res> elements, the UPnP AV MediaRenderer control
point might not be able to determine the preferred <res> element for a given server/renderer pair.
Examples of multiple <res> elements include:

• HTTP and RTP Media Transports;

• Transcoded content;
• Multi-homed content;
• PS and ES versions of content (RTP Media Transport only);
• Transrated content available at different bitrates.
The CMS:GetProtocolInfo action alone does not provide sufficient information for a UPnP AV
MediaRenderer control point to always select the most appropriate URI to pass to
AVT:AVTransportSetURI.

10.1.6.9.2
[G UIDELINE ] A UPnP AV MediaRenderer that receives an AVT:SetAVTransportURI request shall
continue selecting one of the <res> elements specified in the CurrentURIMetaData input argument
until it selects one it can render.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 6NFSA N

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline requires a DMR to automatically select an alternate <res> element for
rendering when it fails to render the content. This is to prevent having the DMR return an error and
have the controlling application to select an alternate <res> element to render to improve playback
latency.

10.1.6.9.3
[G UIDELINE ] A Rendering Endpoint that fails to render the selected content shall try selecting and
rendering the content in a different media format profile if available.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 251 –

[ATTRIBUTES ]

M A DMP M-DMP n/a ISO/IEC SFN5U N

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline requires a DMP/M-DMP to automatically select an alternate <res>

element for rendering when it initially fails to render the content.

10.1.6.9.4
[G UIDELINE ] If a UPnP AV MediaRenderer control point calls AVT:SetAVTransportURI and
provides a DIDL-Lite XML fragment for the CurrentURIMetaData argument, then the DIDL-Lite
fragment shall include all of the <res> elements associated with the object represented by the
DIDL-Lite XML fragment in the initial request to play the content.

[ATTRIBUTES ]

M L DMC +PU+ M-DMC n/a ISO/IEC ZOH44

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] The DIDL-Lite XML fragment will at least requiredhave the <res> element for the URI
specified in request, as required by 10.1.6.14.8. Additional <res> elements are encouraged to allow
the UPnP AV MediaRenderer to choose a different URI for playback. In addition, the DIDL-Lite XML
fragment when sourced from a UPnP AV MediaServer is from a CDS object.

10.1.6.9.5
[G UIDELINE ] If the initial request to play content fails as defined in 10.1.6.9.4, then the UPnP AV
MediaRenderer control point shall reinvoke the AVT:SetAVTransportURI action after removing <res>
elements associated with the object represented by the DIDL-Lite XML fragment in the
CurrentURIMetaData argument.

[ATTRIBUTES ]

M A DMC +PU+ M-DMC n/a ISO/IEC YCGKU N

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline allows a UPnP AV MediaRenderer control point to remove <res>
elements from the DIDL-Lite XML fragment to help aid in the playability of the content associated
CDS object if the initial attempt in guideline 10.1.6.9.4 fails. <res> elements that could be first
removed are unsupported MIME types and content that renderer could not play. Failures could
occur if the the metadata contained in the CurrentURIMetaData argument is too large.

10.1.6.9.6
[G UIDELINE ] A UPnP AV MediaServer control point shall select a <res> element from a CDS object
that is compatible with the capabilities of the Rendering Endpoint.

[ATTRIBUTES ]

M A DMC DMP M-DMC M-DMP n/a ISO/IEC A6OKQ N

29341-20-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 252 –

[C OMMENT]

a) This guideline is to prevent implementations from always selecting the first <res> element in a
CDS object for playback which might not be playable.
b) The best user experience would be achieved with the <res> element with the best match (e.g.
best resolution).
10.1.6.10 MM UPnP AV MediaRenderer and DLNA PlayContainer URI
10.1.6.10.1
[G UIDELINE ] A UPnP AV MediaRenderer that supports playback of a DLNA PlayContainer URI
shall use a playcontainer-param set to true in the 4th field protocolInfo parameter of individual
protocolInfo to indicate that the UPnP AV MediaRenderer will render that type of content when given
a DLNA PlayContainer URI. This guideline specifically applies to the protocolInfo values listed in the
Sink output argument of CMS:GetProtocolInfo responses and the CMS.SinkProtocolInfo state
variable.

All guideline requirements in 10.1.6.10 apply in the context of a UPnP AV MediaRenderer that
supports the rendering of DLNA PlayContainer URIs.

All guideline requirements in 10.1.6.10 apply in conjunction with all other guideline requirements
that govern a UPnP AV MediaServer control point.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 43YT3

29341-14-11
ISO/IEC
29341-3-2

[C OMMENT] A UPnP AV MediaRenderer indicates support for DLNA PlayContainer URI values by
using the playcontainer-param flag. ProtocolInfo values that omit this parameter indicate that the
UPnP AV MediaRenderer will not play that type of content as part of a DLNA PlayContainer URI
operation.

Setting the playcontainer-param flag to true does not mean that a UPnP AV MediaRenderer
requires the media type to be played only through a DLNA PlayContainer URI operation. (That is,
the UPnP AV MediaRenderer control point can specify a URI that points to content of the specified
protocolInfo, or the UPnP AV MediaRenderer control point can specify a DLNA PlayContainer URI
that will result in the playback of content with the specified protocolInfo.)

10.1.6.10.2
[G UIDELINE ] If a UPnP AV MediaRenderer supports playback of a DLNA PlayContainer URI, then
it shall support playback of a DLNA PlaySingle URI as part of the DLNA PlayContainer URI
operation.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC JU4ZA

29341-3-2

[C OMMENT] A UPnP AV MediaRenderer that can play a DLNA PlayContainer URI already has a
UPnP AV MediaServer control point that enables it to browse a UPnP AV MediaServer.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 253 –

10.1.6.10.3
[G UIDELINE ] A UPnP AV MediaRenderer that supports rendering of DLNA PlayContainer URIs
shall support rendering of a CDS object, if the CDS object meets the following criteria.

• The CDS object falls into the media collection that is defined by the DLNA PlayContainer URI.
• The CDS object has a <res> element with a res@protocolInfo that indicates a supported Media
Format Profile, as described by 10.1.6.1.2.
[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC BS2HV

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline essentially says that a UPnP AV MediaRenderer will render content that
is supported by the UPnP AV MediaRenderer and can be found by traversing the CDS in the manner
prescribed for a DLNA PlayContainer URI.

10.1.6.11 MM UPnP AV MediaRenderer AVT state variables

10.1.6.11.1
[G UIDELINE ] A UPnP AV MediaRenderer that renders a content binary that is not part of a DLNA
PlayContainer URI or media collection file shall use the following mapping for virtual instance state
variables.

• The AVT.AVTransportURI value shall be the URI provided in the CurrentURI input argument of
the AVT:SetAVTransportURI request or it shall be a URI obtained from a <res> element in the
CurrentURIMetaData input argument of the same request.
• The AVT.CurrentTrackURI value shall be equal to the AVT.AVTransportURI value.
• The AVT.CurrentTrack and AVT.NumberOfTracks values shall be "1".
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC W74MV

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] In conjunction with other DLNA guidelines that define general rules for ensuring
consistency between different AVTransport state variables, this guideline clarifies how those other
guidelines apply specifically, in the case where a control point instructs a UPnP AV MediaRenderer
to render a single content binary.

Guideline requirement 10.1.6.9.1 permits a UPnP AV MediaRenderer to override the CurrentURI

input argument with a URI from the CurrentURIMetaData input argument.

10.1.6.11.2
[G UIDELINE ] A UPnP AV MediaRenderer that renders a media collection file shall use the following
mapping for virtual instance state variables.

• The AVT.AVTransportURI value shall be the URI provided in the CurrentURI input argument of
the AVT:SetAVTransportURI request.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 254 –

• The AVT.CurrentTrackURI value shall be the URI for the track that is currently being rendered.
(That is, the URI for the actual audio-only, audio/video, or image content that is actually
rendered.)
• The AVT.CurrentTrack value shall be the index within the media collection file, where the URI for
the track can be found. This value is 1 for the first track URI in the media collection file and is
incremented by one for each successive track even if the track cannot be rendered.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC S2HVW

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] In conjunction with other DLNA guidelines that define general rules for ensuring
consistency between different AVTransport state variables, this guideline clarifies how those other
guidelines apply specifically, in the case of media collection files. There could be some tracks in the
media collection file that might not be able to be rendered by the UPnP AV MediaRenderer (e.g.
unsupported Media Format Profile for a track URI).

The AVT.CurrentTrackURI virtual instance state variable value is never the URI of the media
collection file.

10.1.6.11.3
[G UIDELINE ] A UPnP AV MediaRenderer that renders a DLNA PlayContainer URI shall use the
following mapping for virtual instance state variables.

• The AVT.AVTransportURI value shall be the URI provided in the CurrentURI input argument of
the AVT:SetAVTransportURI request.
• The AVT.CurrentTrackURI shall be the URI for the track that is currently being rendered. (i.e. the
URI for the actual audio-only, audio/video, or image content that is being rendered).
PlayContainerTrackIndex is defined as the index of a rendered content, relative to the sequenced
set of content, represented by the DLNA PlayContainer URI.

PlayContainerTotalTracks is defined as the last index of rendered content in the sequenced set of
content, represented by the DLNA PlayContainer URI.

PlayContainerTrackIndex and PlayContainerTotalTracks shall be calculated in a manner consistent

with these rules.

• Index calculation shall always be done with a preorder traversal of the CDS hierarchy, such that
the first CDS object that is played shall have an index of "1". A preorder traversal means that for
a given CDS:Browse request (with sort-args applied), left subtrees and leaves (i.e. CDS objects
that appear earlier in the CDS:Browse response) are processed before right subtrees and
leaves (i.e. CDS objects that appear later in the CDS:Browse response).
• If encountered during traversal, CDS items shall always have a count of "1", regardless of
whether they are played or skipped. A skipped CDS item is one where none of the CDS item's
<res> elements are rendered by the UPnP AV MediaRenderer. If the CDS item has zero <res>
elements, it shall be considered skipped.
• A CDS item with a media collection binary shall always have a count of "1". Furthermore, these
CDS items shall be skipped. (See 10.1.4.29.4 MM DLNA PlayContainer URI for information on
the prohibition of playing media collection binaries.)
• If rendered, a CDS item shall automatically render at least one <res> elements associated with
the CDS item. If multiple <res> elements are rendered, then they shall be rendered

DLNA guidelines; Part 1-1: Architecture and protocols

 – 255 –

simultaneously. (That is, a UPnP AV MediaRenderer does not render the same content (in
different profiles or transports) multiple times, but a UPnP AV MediaRenderer is permitted to
render an image in conjunction with an audio at the same time.)
• If encountered during traversal, a CDS container shall have a count of "0" because <res>
elements of a CDS container shall never be played. (See 10.1.4.29.4 MM DLNA PlayContainer
URI for information on the restriction for playing only CDS items.)
A CDS object shall be counted if and only if there are max-depth-val or fewer CDS containers
between the CDS object and the CDS container identified by container-id-val, as defined in
10.1.4.29. (That is, these are the CDS objects that are traversed.)

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC U4ZAU

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] In conjunction with other DLNA guidelines that define general rules for ensuring
consistency between different AVTransport state variables, this guideline clarifies how those other
guidelines apply specifically, in the case of DLNA PlayContainer URI values.

The AVT.NumberOfTracks virtual instance state variable is often updated progressively because it
is often difficult to count the number of tracks for all types of media collections, whether they be
represented through a DLNA PlayContainer URI or a media collection file.

The AVT.CurrentTrackURI virtual instance state variable value is never the DLNA PlayContainer
URI.

10.1.6.11.4
[G UIDELINE ] A UPnP AV MediaRenderer that renders a media collection file should use the
following mapping for virtual instance state variables.

• The AVT.NumberOfTracks value should be the number of content entries in the media collection
file (which is often progressively calculated).
[ATTRIBUTES ]

S C DMR n/a n/a ISO/IEC Q8QS5

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] Some UPnP AV MediaRenderers might not be able to immediately provide a count of
the playback items in a media collection file. The AVTransport specification takes this into account
and permits UPnP AV MediaRenderers to update the value in a progressive manner.

This guideline strongly recommends that a UPnP AV MediaRenderer provide the number of
playback items in the current media collection file. Sometimes the final value is acquired in an
immediate fashion; other times, the value has to be acquired through a counting process. The
manner in which the UPnP AV MediaRenderer acquires the total track count is up to the
implementer, but the obligation to provide an accurate value exists according to the intentions of the
AVTransport specification.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 256 –

10.1.6.11.5
[G UIDELINE ] A UPnP AV MediaRenderer that renders a DLNA PlayContainer URI should use the
following mapping for virtual instance state variables.

• The AVT.NumberOfTracks value should be the PlayContainerTotalTracks (which is often

progressively calculated).
[ATTRIBUTES ]

S C DMR n/a n/a ISO/IEC SRWQV

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] The AVT.NumberOfTracks virtual instance state variable is often updated

progressively because it is often difficult to count the number of tracks for all types of media
collections, whether they be represented through a DLNA PlayContainer URI or a media collection
file.

This guideline strongly recommends that a UPnP AV MediaRenderer provide the number of
playback items in the current DLNA PlayContainer URI. Sometimes the final value is acquired in an
immediate fashion; other times, the value has to be acquired through a counting process. The
manner in which the UPnP AV MediaRenderer acquires the total track count is up to the
implementer, but the obligation to provide an accurate value exists according to the intentions of the
AVTransport specification.

10.1.6.11.6
[G UIDELINE ] A UPnP AV MediaRenderer that renders a DLNA PlayContainer URI shall use one of
the following values for AVT.CurrentTrack virtual instance state variable.

• The value of PlayContainerTrackIndex as defined in 10.1.6.11.3.

• A value of “0” to indicate that the PlayContainerTrackIndex is being calculated.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC Q8ON2

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] A UPnP AV MediaRenderer cannot be able to immediately calculate the

PlayContainerTrackIndex, as the calculation process could involve multiple interactions with the
target UPnP AV MediaServer to traverse the CDS. This guideline states that a UPnP AV
MediaRenderer uses a value of “0” for the AVT.CurrentTrack virtual instance state variable to
indicate that the correct value of PlayContainerTrackIndex is not yet available.

10.1.6.11.7
[G UIDELINE ] If no content has been assigned to the UPnP AV MediaRenderer for rendering or the
UPnP AV MediaRenderer receives an AVT:SetAVTransportURI action with both the CurrentURI and
CurrentURIMetaData input arguments set to an empty string, then the UPnP AV MediaRenderer
shall use the following mapping for virtual instance state variables.

• The AVT.AVTransportURI and AVT.CurrentTrackURI values shall be "".

• The AVT.CurrentTrack and AVT.NumberOfTracks values shall have a value of "0".
• The AVT.TransportState shall have a value of "NO_MEDIA_PRESENT".

DLNA guidelines; Part 1-1: Architecture and protocols

 – 257 –

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC VM6GK

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This is for the situation after a reset condition for a UPnP AV MediaRenderer or by a
UPnP AV MediaRenderer control point through the AVT.SetAVTransportURI action (10.1.6.8.2) to
clear the rendering state.

10.1.6.12 MM GetMediaInfo behavior

10.1.6.12.1
[G UIDELINE ] The CurrentURI output argument of the AVT:GetMediaInfo action shall return the
value of the AVT.AVTransportURI virtual instance state variable.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 3YT3F

29341-14-10

[C OMMENT] This requirement repeats what is already stated in the AVTransport specification.
Some implementations have accidentally mistaken the CurrentURI output argument and the
AVT.AVTransportURI values to be always equivalent to the TrackURI output argument of
AVT:GetPositionInfo and the AVT.CurrentTrack URI virtual instance state variable.

10.1.6.12.2
[G UIDELINE ] The NrTracks output argument of the AVT:GetMediaInfo action shall return the same
value as the AVT.NumberOfTracks virtual instance state variable.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC OH44W

29341-14-10

[C OMMENT] These guidelines specify the behavior for reporting the value for NrTracks (and
AVT.NumberOfTracks).

10.1.6.12.3
[G UIDELINE ] In conjunction with 10.1.6.11.2, 10.1.6.11.3, 10.1.6.11.4, and 10.1.6.11.5, a UPnP AV
MediaRenderer that progressively updates the value of AVT.NumberOfTracks should provide the
total count within 10 s of the previous call to AVT:SetAVTransportURI.

[ATTRIBUTES ]

S L DMR n/a n/a ISO/IEC 4Q9J4

29341-14-10

[C OMMENT] DLNA recommends that UPnP AV MediaRenderers provide the count in a timely
manner. Control points often display such information to a user and sometimes use the track count
information to determine what a user can or cannot do.

This guideline is not required because media collection files can be very large and, in the case of
DLNA PlayContainer URIs, CDS hierarchies can be very complex.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 258 –

10.1.6.12.4
[G UIDELINE ] The MediaDuration output argument of the AVT:GetMediaInfo action shall return the
value of the AVT.CurrentMediaDuration virtual instance state variable.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC 44KUE

29341-14-10

10.1.6.12.5
[G UIDELINE ] In conjunction with 10.1.6.12.9, a UPnP AV MediaRenderer may progressively update
the value of AVT.CurrentMediaDuration, such that the total sum is not provided immediately.

The definition of update progressively is that the UPnP AV MediaRenderer updates the state
variable (and appropriately sends GENA events) at a rate that does not exceed one GENA event
every 0,2 s.

[ATTRIBUTES ]

O R DMR n/a n/a ISO/IEC Q9J4K

29341-14-10

[C OMMENT] Some UPnP AV MediaRenderers might not be able to immediately provide the
duration sum for all playback items in a media collection. The AVTransport specification takes this
into account and permits UPnP AV MediaRenderers to update the value in a progressive manner.

10.1.6.12.6
[G UIDELINE ] In conjunction with 10.1.6.12.5, a UPnP AV MediaRenderer that progressively
updates the value of AVT.CurrentMediaDuration should provide the total sum within 10 s of the
previous call to AVT:SetAVTransportURI.

[ATTRIBUTES ]

S L DMR n/a n/a ISO/IEC VW4BW

29341-14-10

[C OMMENT] DLNA recommends that UPnP AV MediaRenderers provide the duration sum in a
timely manner.

10.1.6.12.7
[G UIDELINE ] Information returned by AVT:GetMediaInfo should be as accurate as possible. The
output arguments that UPnP AV MediaRenderer control points will rely on most will be: NrTracks,
CurrentURI, CurrentURIMetaData, and MediaDuration.

This also includes the following possibilities and assumptions.

• Some output arguments can be progressively updated as the device acquires more information
(e.g., NrTracks).
• Some output arguments can have values to indicate that the information cannot be provided
(e.g., NOT_IMPLEMENTED value for MediaDuration as defined in requirement 10.1.6.12.8).
• CurrentURIMetaData can have values as defined in guideline requirements 10.1.6.14.
• Some output arguments can have placeholder values to indicate information is not yet available.
(That is, DIDL-Lite document with schema-compliant placeholder values.)

DLNA guidelines; Part 1-1: Architecture and protocols

 – 259 –

[ATTRIBUTES ]

S C DMR n/a n/a ISO/IEC Y37DW

29341-14-10

[C OMMENT] This suggestion permits devices to use placeholder values where appropriate,
although the guideline strongly encourages information be as accurate as possible.

10.1.6.12.8
[G UIDELINE ] A UPnP AV MediaRenderer shall do one of the following.

• Never set the value of the AVT.CurrentMediaDuration virtual instance state variable to
"NOT_IMPLEMENTED".
• Always set the value of the AVT.CurrentMediaDuration virtual instance state variable to
"NOT_IMPLEMENTED".
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 8QS58

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] UPnP AV MediaRenderers are not allowed to selectively use the string
"NOT_IMPLEMENTED" for some contents but not others.

10.1.6.12.9
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the AVT.CurrentMediaDuration
virtual instance state variable to "NOT_IMPLEMENTED", the AVT.CurrentMediaDuration virtual
instance state variable should be the total duration for the content specified in AVT.AVTransportURI.
When the AVT.AVTransportURI is a media collection or a DLNA PlayContainer URI, the
AVT.CurrentMediaDuration virtual instance state variable is the sum of all known playback
durations for each item in the media collection or DLNA PlayContainer URI.

[ATTRIBUTES ]

S R DMR n/a n/a ISO/IEC RWQV7

29341-14-10

[C OMMENT] UPnP AV MediaRenderers often know the playback duration, of items in a media
collection or DLNA PlayContainer URI, through summing the durations progressively or by using
some metadata within the media collection or through the PlayContainer URI that provides the value
in an immediate fashion.

This guideline places no mandatory requirement on the accuracy of the total media duration. If the
UPnP AV MediaRenderer is not able to provide a value, then the value of the virtual instance state
variable is vendor-dependent.

10.1.6.12.10
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the AVT.CurrentMediaDuration
virtual instance state variable to “NOT_IMPLEMENTED”, but the UPnP AV MediaRenderer cannot
compute the duration of the associated content, then the value of state variable shall be set to either
“0:00:00” or “00:00:00” to indicate an unknown duration.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 260 –

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC VHOQE

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] this guideline clarifies that a value of “0:00:00” or “00:00:00” in state variable
AVT.CurrentMediaDuration indicates unknown duration for the content associated with
AVT.AVTransportURI virtual instance state variable. For example, if the 5 th entry in a media
collection does not have a duration, then the duration for the entire media collection will be unknown.
Another example: If the UPnP AV MediaRenderer is playing an image that is not part of a media
collection or a PlayContainer operation, then the value of AVT.CurrentMediaDuration is the same as
AVT.CurrentTrackDuration.

10.1.6.13 MM GetPositionInfo behavior

10.1.6.13.1
[G UIDELINE ] The AVT:GetPositionInfo shall return values in the following manner.

• The Track output argument shall be equal to AVT.CurrentTrack value.

• The TrackURI output argument shall be equal to AVT.CurrentTrackURI value.
Note that there can be a time period where the URI and track values are temporarily
non-synchronized for transitioning purposes.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC A68VL

29341-14-10

[C OMMENT] When the UPnP AV MediaRenderer is in the TRANSITIONING state, the URI values
and track index values can be non-synchronized. When the UPnP AV MediaRenderer enters a
non-transitional state (e.g. PLAYING, STOPPED, etc.), the URI and track values are expected to be
accurate as described in the guideline.

10.1.6.13.2
[G UIDELINE ] Information returned by AVT:GetPositionInfo should be as accurate as possible. The
output arguments that control points will rely on most will be: RelTime , TrackDuration, Track, and
TrackURI.

[ATTRIBUTES ]

S C DMR n/a n/a ISO/IEC 74MVR

29341-14-10

[C OMMENT] This suggestion permits devices to use placeholder values where

appropriate-although the guideline strongly encourages information be as accurate as possible.

10.1.6.13.3
[G UIDELINE ] The TrackDuration output argument of the AVT:GetPositionInfo action shall return the
value of the AVT.CurrentTrackDuration virtual instance state variable.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC XTD3B

DLNA guidelines; Part 1-1: Architecture and protocols

 – 261 –

29341-14-10
ISO/IEC
29341-3-2

10.1.6.13.4
[G UIDELINE ] A UPnP AV MediaRenderer shall do one of the following:

• Never set the value of the AVT.CurrentTrackDuration virtual instance state variable to
"NOT_IMPLEMENTED".
• Always set the value of the AVT. CurrentTrackDuration virtual instance state variable to
"NOT_IMPLEMENTED".
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 59RRB

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] UPnP AV MediaRenderers are not allowed to selectively use the string
"NOT_IMPLEMENTED" for some tracks but not others.

10.1.6.13.5
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the AVT.CurrentTrackDuration
virtual instance state variable to "NOT_IMPLEMENTED", then the AVT.CurrentTrackDuration
virtual instance state variable should be the duration for the track specified in
AVT.CurrentTrackURI.

[ATTRIBUTES ]

S R DMR n/a n/a ISO/IEC 8EII9

29341-14-10

[C OMMENT] Provides baseline expectations for reporting the playback duration of the track that is
currently being rendered. This guideline does not impose any mandatory accuracy requirements
because methodologies for determining the playback duration varies between implementations and
often has a dependency on the media formats. If the UPnP AV MediaRenderer is not able to provide
a value, then the value of the virtual instance state variable is vendor-dependent.

10.1.6.13.6
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the AVT.CurrentTrackDuration
virtual instance state variable to “NOT_IMPLEMENTED”, but the UPnP AV MediaRenderer cannot
compute the duration of the track (for example, if the track is an image), then the value of this state
variable shall be set to either “0:00:00” or “00:00:00” to indicate an unknown duration.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC Y6LY5

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline clarifies that a value of “0:00:00” or “00:00:00” in state variable
AVT.CurrentTrackDuration indicates unknown track duration for the current media resource.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 262 –

10.1.6.13.7
[G UIDELINE ] The RelTime output argument of the AVT:GetPositionInfo action shall return the value
of the AVT.RelativeTimePosition virtual instance state variable.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC P5VR2

29341-14-10
ISO/IEC
29341-3-2

10.1.6.13.8
[G UIDELINE ] A UPnP AV MediaRenderer shall do one of the following:

• Never set the value of the AVT.RelativeTimePosition virtual instance state variable to
"NOT_IMPLEMENTED".
• Always set the value of the AVT.RelativeTimePosition virtual instance state variable to
"NOT_IMPLEMENTED".
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC TD3B8

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] UPnP AV MediaRenderers are not allowed to selectively use the string
"NOT_IMPLEMENTED" for some tracks but not others.

10.1.6.13.9
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the AVT.RelativeTimePosition
virtual instance state variable to "NOT_IMPLEMENTED", the AVT.RelativeTimePosition virtual
instance state variable shall indicate the current playback position in terms of time for the content
indicated by AVT.CurrentTrackURI. The value of the AVT.RelativeTimePosition virtual instance
state variable shall not be "END_OF_MEDIA".

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC 9RRBW

29341-14-10

[C OMMENT] This guideline specifies the correct behavior for reporting the RelTime output
arguments. Reporting an empty string is not acceptable.

Reporting "END_OF_MEDIA" is not acceptable in the DLNA context.

DLNA only defines the usage of AVT.RelativeTimePosition. The use of AVT.AbsoluteTimePosition

and the AbsTime output argument of the AVT:GetPositionInfo action is vendor dependent.

10.1.6.13.10
[G UIDELINE ] The TrackMetaData output argument of the AVT:GetPositionInfo action shall return
the value of the AVT.CurrentTrackMetaData virtual instance state variable.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC EII9O

29341-14-10
DLNA guidelines; Part 1-1: Architecture and protocols
 – 263 –

ISO/IEC
29341-3-2

10.1.6.13.11
[G UIDELINE ] A UPnP AV MediaRenderer shall do one of the following:

• Never set the value of the AVT.CurrentTrackMetaData virtual instance state variable to
"NOT_IMPLEMENTED".
• Always set the value of the AVT.CurrentTrackMetaData virtual instance state variable to
"NOT_IMPLEMENTED".
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 5VR2J

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] UPnP AV MediaRenderers are not allowed to selectively use the string
"NOT_IMPLEMENTED" for some tracks but not others.

10.1.6.13.12
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the AVT.CurrentTrackMetaData
virtual instance state variable to "NOT_IMPLEMENTED", the AVT.CurrentTrackMetaData virtual
instance state variable shall be formatted in one of the following ways:

• The value shall specify a valid DIDL-Lite XML fragment as defined in 10.1.6.14.8, with a single
<item> element that describes the track indicated by the AVT.CurrentTrackURI instance state
variable.
• The value shall be an empty string when no metadata is available for the current track indicated
by the AVT.CurrentTrackURI virtual instance state variable, or when the AVT.CurrentTrackURI
virtual instance state variable is also an empty string (e.g. no content is set up for rendering).
[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC D3B8T

29341-14-10

10.1.6.14 MM Metadata reporting

10.1.6.14.1
[G UIDELINE ] If a UPnP AV MediaRenderer always sets the value of the
AVT.AVTransportURIMetaData virtual instance state variable to "NOT_IMPLEMENTED", then the
UPnP AV MediaRenderer shall accept an AVT:SetAVTransportURI request as though an empty
value was sent for the CurrentURIMetaData.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 4MVRM

29341-14-10

[C OMMENT] This guideline essentially requires UPnP AV MediaRenderers to discard the

CurrentURIMetaData value if the input argument is not supported. This guideline allows control
points to use the CurrentURIMetaData input argument when invoking AVT:SetAVTransportURI,
without having to implement logic for retrying the request without metadata.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 264 –

Requirement 9.2.15.1 only requires UPnP devices to accept SOAP requests up to 20 480 B (20 KiB)
in size.

10.1.6.14.2
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the
AVT.AVTransportURIMetaData virtual instance state variable to "NOT_IMPLEMENTED", then the
UPnP AV MediaRenderer may choose not to validate the CurrentURIMetaData input argument
specified by the UPnP AV MediaRenderer control point in the AVT:SetAVTransportURI request.

[ATTRIBUTES ]

O C DMR n/a n/a ISO/IEC HVW39

29341-14-10

[C OMMENT] This guideline absolves UPnP AV MediaRenderers from having to parse or validate
the DIDL-Lite metadata sent by a control point.

10.1.6.14.3
[G UIDELINE ] The value of the CurrentURIMetaData output argument for the AVT:GetMediaInfo
action shall be the same as the value of the AVT.AVTransportURIMetaData virtual instance state
variable.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC T3FQL

29341-14-10

10.1.6.14.4
[G UIDELINE ] A UPnP AV MediaRenderer shall update the AVT.AVTransportURI virtual instance
state variable to indicate the current URI prior to changing the AVT.TransportState virtual instance
state variable to "PLAYING".

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC 44WMJ

29341-14-10

[C OMMENT] This allows control points to know when the UPnP AV MediaRenderer has selected a
different <res> element.

Control Points can rely on the GENA event to indicate when the UPnP AV Media Renderer has
chosen an alternate URI.

This guideline applies generally, including these scenarios:

• The UPnP AV MediaRenderer uses the URI specified in the CurrentURI argument of the
AVT:SetAVTransportURI request.
• The DMR overrides the specified URI (in the CurrentURI argument) with another one (from the
CurrentURIMetaData argument) in the AVT:SetAVTransportURI request (as described in
10.1.6.9.1).
10.1.6.14.5
[G UIDELINE ] UPnP AV MediaRenderers may specify a value for the
AVT.AVTransportURIMetaData virtual instance state variable (and hence the CurrentURIMetaData
output argument of AVT:GetMediaInfo) that is different from the value of the CurrentURIMetaData
argument of the last AVT:SetAVTransportURI request.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 265 –

[ATTRIBUTES ]

O C DMR n/a n/a ISO/IEC 68VLX

29341-14-10

[C OMMENT] UPnP AV MediaRenderers can have different values because of a variety of reasons.

• The device can parse different metadata from within the content file.
• The device can remove elements and attributes from the DIDL-Lite XML fragment (while
remaining schema-compliant) to reduce memory use.
• The device can truncate values of elements and attributes to reduce memory use.
10.1.6.14.6
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the
AVT.AVTransportURIMetaData virtual instance state variable to "NOT_IMPLEMENTED" and it
specifies a value for the AVT.AVTransportURIMetaData virtual instance state variable (and hence
the CurrentURIMetaData output argument of AVT:GetMediaInfo) that is different from the value of
the CurrentURIMetaData argument of the last AVT:SetAVTransportURI request, then the UPnP AV
MediaRenderer shall impose the following restrictions on the metadata.

• The provided metadata shall represent the metadata of the content indicated by the
AVT.AVTransportURI virtual instance state variable.
• If the AVT.AVTransportURI virtual instance state variable points to a media collection, then the
provided metadata shall be limited to the media collection. The provided metadata shall not
include metadata for items within the media collection.
• The provided metadata shall specify a valid DIDL-Lite XML fragment as defined in 10.1.6.14.8.
[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC WSV39

29341-14-10

[C OMMENT] Many control points have problems accepting large metadata values. This guideline
limits the metadata for AVT.AVTransportURIMetaData and CurrentURIMetaData to refer
specifically to the content indicated by the AVT.AVTransportURI virtual instance state variable. This
guideline prohibits the general practice of collectively using the metadata of each item in a media
collection to represent the metadata of a media collection.

10.1.6.14.7
[G UIDELINE ] If a UPnP AV MediaRenderer is capable of playing a media collection and if the UPnP
AV MediaRenderer has access to metadata of individual items in the collection, then the UPnP AV
MediaRenderer should report these metadata through the AVT.CurrentTrackMetaData virtual
instance state variable.

[ATTRIBUTES ]

S C DMR n/a n/a ISO/IEC OC6RF

29341-14-10

[C OMMENT] Control Points often use metadata provided by the UPnP AV MediaRenderer in user
interfaces. UPnP AV MediaRenderers are strongly encouraged to provide such metadata whenever
possible.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 266 –

10.1.6.14.8
[G UIDELINE ] If a UPnP AV MediaRenderer control point specifies a value for the
CurrentURIMetaData argument of an AVT:SetAVTransportURI request, then the control point shall
follow these restrictions for the value of the CurrentURIMetaData argument, as follows:

• compliant with the DIDL-Lite schema;

• exactly one <DIDL-Lite> element;
• exactly one <item> or <container> element;
• exactly one <dc:title> element and value;
• a minimum of zero and a maximum of one <dc:creator> element and value;
• exactly one <upnp:class> element and value;
• a minimum of one <res> element.
All other XML elements are permitted as long as they are properly declared with their namespaces.

The provided metadata shall represent the metadata of the content indicated by the CurrentURI
input argument.

One of the <res> elements shall be the <res> element that contains the URI specified in the
CurrentURI input argument.

If the CurrentURI input argument points to a media collection, then the provided metadata shall be
limited to the media collection. The provided metadata shall not include metadata for items within
the media collection.

[ATTRIBUTES ]

M L DMC +PU+ M-DMC n/a ISO/IEC 37DW6

29341-14-10

[C OMMENT] This guideline limits the scope of the CurrentURIMetaData to the metadata directly
associated with the CurrentURI input argument. Metadata for a media collection is permitted, so
long as value does not provide metadata for each of the individual items in the collection.

Many UPnP AV MediaRenderers have problems storing a large amount of metadata provided in the
CurrentURIMetaData. Equally problematic is the fact that many control points cannot support a
scenario where a UPnP device transmits a UPnP event or an AVT:GetMediaInfo response with a
large amount of metadata.

The expected metadata to be sent in the CurrentURIMetaData argument is best described by the
CDS:Browse response for the following request:

• ObjectID: The CDS object ID of that provided the URI specified in the CurrentURI input
argument of AVT:SetAVTransportURI.
• BrowseFlag: BrowseMetadata.
• Filter: One or more of the following: ALLIP, res (and or any res attribute), dc:creator, and any
other metadata that the control point wants to provide.
Whenever possible, control points are encouraged to provide all of the available <res> attributes
that are normative for DIDL-Lite. Likewise, UPnP AV MediaRenderers are encouraged to accept
and preserve these attributes.

The guideline permits control points to specify a single <res> element in the metadata, on behalf of
a user request. In such cases, the CurrentURIMetaData argument only includes the <res> element
DLNA guidelines; Part 1-1: Architecture and protocols
 – 267 –

that corresponds to the URI specified in the CurrentURI argument.

However, control points are encouraged to provide all available <res> elements. This allows UPnP
AV MediaRenderers the opportunity to choose a <res> element that might provide a better rendering
experience. See 10.1.6.9 for more information about UPnP AV MediaRenderers that select
alternate URIs from the CurrentURIMetaData argument.

10.1.6.14.9
[G UIDELINE ] UPnP AV MediaRenderer control points that receive metadata from a UPnP AV
MediaRenderer shall be tolerant of DIDL-Lite metadata that is valid and conformant to DLNA
restrictions.

Tolerant behavior is defined as being able to parse-and-accept or parse-and-ignore the metadata.

Failing to parse a DLNA-compliant UPnP action response or event because of metadata is
unacceptable behavior.

[ATTRIBUTES ]

M C DMC +PU+ M-DMC n/a ISO/IEC W4BWN

29341-14-10

[C OMMENT] Control Points that invoke UPnP actions or subscribe to UPnP events that involve
metadata needs to be prepared for the presence of metadata, even if metadata is not always
provided.

10.1.6.14.10
[G UIDELINE ] UPnP AV MediaRenderer control points that receive metadata from a UPnP AV
MediaRenderer should be tolerant of DIDL-Lite metadata that is invalid or not conformant to DLNA
restrictions.

Tolerant behavior is defined as being able to parse-and-ignore the metadata.

[ATTRIBUTES ]

S C DMC +PU+ M-DMC n/a ISO/IEC 9J4K4

29341-14-10

[C OMMENT] UPnP AV MediaRenderer control points that can handle DIDL-Lite metadata that is not
schema compliant exhibit a good level of robustness in an environment where DLNA UPnP AV
MediaRenderer control points can be interacting with non-DLNA UPnP AV MediaRenderer devices.

10.1.6.14.11
[G UIDELINE ] The UPnP AV MediaRenderer shall do one of the following:

• Never set the value of the AVT.AVTransportURIMetaData virtual instance state variable to
"NOT_IMPLEMENTED".
• Always set the value of the AVT.AVTransportURIMetaData virtual instance state variable to
"NOT_IMPLEMENTED".
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC RRBWY

29341-14-10

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 268 –

[C OMMENT] UPnP AV MediaRenderers are not allowed to selectively use the string
"NOT_IMPLEMENTED" for some contents but not others.

10.1.6.14.12
[G UIDELINE ] If a UPnP AV MediaRenderer never sets the value of the
AVT.AVTransportURIMetaData virtual instance state variable to "NOT_IMPLEMENTED", then the
AVT.AVTransportURIMetaData virtual instance state variable shall be formatted in one of the
following ways.

• The value shall specify a valid DIDL-Lite XML fragment as defined in 10.1.6.14.8, with a single
<item> element that describes the content indicated by the AVT.AVTransportURI virtual
instance state variable.
• The value shall be an empty string when no metadata is available for the content indicated by the
AVT.AVTransportURI virtual instance state variable, or when the AVT.AVTransportURI virtual
instance state variable is also an empty string (e.g. no content is set up for rendering) or a DLNA
PlayContainer URI.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC VR2JS

29341-14-10

[C OMMENT] The UPnP AV MediaRenderer can obtain the metadata from the CurrentURIMetaData
input argument in the AVT:SetAVTransportURI action, or by using other means (see also
10.1.6.14.5).

10.1.6.15 MM reporting transport information

10.1.6.15.1
[G UIDELINE ] UPnP MediaRenderers that respond to an AVT:GetTransportInfo request shall reflect
the play/transport state in the following manner.

• The CurrentTransportState output argument shall match the AVT.TransportState instance state
variable.
• The CurrentTransportStatus output argument shall match the AVT.TransportStatus instance
state variable.
• The CurrentSpeed output argument shall match the AVT.TransportPlaySpeed instance state
variable.
[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC KUEXL

29341-14-10

[C OMMENT] This guideline makes it so that control points can safely assume that UPnP actions and
instance state variables report the same transport state information.

10.1.6.15.2
[G UIDELINE ] UPnP MediaRenderers that respond to an AVT:GetTransportSettings request shall
accurately reflect the PlayMode output argument to match the AVT.CurrentPlayMode instance state
variable.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 269 –

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC UEXLS

29341-14-10

10.1.6.16 MM normative MediaRenderer state transitions

10.1.6.16.1
[G UIDELINE ] If a UPnP MediaRenderer enters the TRANSITIONING state, it shall change to the
state desired by the control point within 30 s.

The longest period of time that a MediaRenderer device is permitted to remain in the
TRANSITIONING state is 30 s.

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC J4K4Z

29341-14-10

[C OMMENT] The TRANSITIONING state is a way for a device to indicate that it is attempting to
change into a different state, such as PLAYING or STOPPED.

10.1.6.16.2
[G UIDELINE ] UPnP MediaRenderers may enter the TRANSITIONING state at any time.

[ATTRIBUTES ]

O C DMR n/a n/a ISO/IEC 4BWN9

29341-14-10

[C OMMENT] The AVTransport specification has an informative diagram that describes

TRANSITIONING to be used only between STOPPED and PLAYING states. This diagram is not
restrictive, and it allows new transitions.

The TRANSITIONING provides a useful cue to the user that the device is trying to do something. For
example, entering the TRANSITIONING state after a call to AVT:SetAVTransportURI acknowledges
the user's request to change content even if playback has not yet begun. Likewise, if a device is in
the PLAYING state and network problems interrupt playback, the device can go into the
TRANSITIONING state during the interruption.

10.1.6.16.3
[G UIDELINE ] UPnP MediaRenderers shall not define a new intermediate state.

An intermediate state is a state that the device enters temporarily before entering the state
requested by the control point.

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC 7DW6X

29341-14-10

[C OMMENT] Defining a new intermediate state can confuse control points into believing other
control points are trying to use the device. A control point that encounters a vendor-defined state of
BUFFERING has no idea that this state is an intermediate state. Likewise, a control point that
encounters a vendor-defined state of LOCKED has no idea that the device might remain in this state

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 270 –

indefinitely. This guideline allows control points to always assume that vendor-defined states can
last indefinitely and that TRANSITIONING is the only intermediate state.

10.1.6.16.4
[G UIDELINE ] UPnP MediaRenderers may define new non-intermediate states.

[ATTRIBUTES ]

O L DMR n/a n/a ISO/IEC C6RFR

29341-14-10

[C OMMENT] For example, defining a LOCKED state to indicate that the DMR cannot accept
AVTransport requests is acceptable due to its current state (e.g. a local user is using the device
directly).
However, creating a new state called BUFFERING to represent that the device is busy buffering
data in preparation for rendering is not permitted.
The LOCKED and BUFFERING states are only examples. The key distinction between the
examples is the former involves an out-of-scope scenario and the latter involves an in-scope
scenario. In the case of LOCKED, an external stimulus (i.e. out-of-scope scenario) caused the
device to enter the LOCKED state. In the case of BUFFERING, the DMR entered the BUFFERING
state after a control point requested a normative state change request (e.g. play state change, track
change, URI change, etc.).

10.1.6.16.5
[G UIDELINE ] UPnP MediaRenderers may define new allowed values for the AVT.TransportStatus
instance state variable.

[ATTRIBUTES ]

O C DMR n/a n/a ISO/IEC SV393

29341-14-10

[C OMMENT] In lieu of defining new intermediate states, vendors are permitted to use the
TransportStatus instance state variable to convey additional information about the transport layer.

10.1.6.16.6
[G UIDELINE ] UPnP MediaRenderers that define new allowed values for the AVT.TransportStatus
instance state variable should begin the allowed value with "ERROR_" to indicate the value
represents an error condition.

[ATTRIBUTES ]

S L DMR n/a n/a ISO/IEC 8VLXY

29341-14-10

[C OMMENT] This guideline allows control points to mark status values as being informative or
error-related. The normative error value for AVT.TransportStatus is ERROR_OCCURRED.

10.1.6.16.7
[G UIDELINE ] If a UPnP AV MediaRenderer responds to an AVT:Seek action with the 200 (OK)
response code and the value of the AVT.TransportState virtual instance state variable is
PAUSED_PLAYBACK or STOPPED, then it shall set the AVT.TransportState virtual instance state
variable to a value of TRANSITIONING. After the seek operation is completed (i.e. the desired
playback position is reached), the UPnP AV MediaRenderer shall set the AVT.TransportState virtual
instance state variable to the value before the transition to TRANSITIONING.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 271 –

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 76CN7

29341-14-10

[C OMMENT] This guideline allows UPnP AV MediaRenderer control points to detect a change to the
transport state (AVT.TransportState) on the UPnP AV MediaRenderer through the eventing of the
AVT.LastChange virtual state variable and could be used to trigger an invocation of the
AVT.GetPositionInfo action. This guideline applies even when performing an instantaneous seek on
cached content and remaining in the same transport state.

10.1.6.16.8
[G UIDELINE ] A UPnP AV MediaRenderer control point should always invoke the
AVT:GetPositionInfo action when the AVT.LastChange evented state variable contains an update to
the AVT.TransportState virtual instance state variable with a value of PAUSED_PLAYBACK or
STOPPED even when the AVT.TransportState virtual instance state variable value is the same as
currently cached in the UPnP AV MediaRenderer control point.

[ATTRIBUTES ]

S A DMC +PU+ M-DMC n/a ISO/IEC VQ7SL

29341-14-10

[C OMMENT] This guideline gives guidance to UPnP AV MediaRenderer control points to refresh
their current position information when a UPnP AV MediaRenderer reports a transport state change
to PAUSED_PLAYBACK or STOPPED.
For example, when a UPnP AV MediaRenderer control point, not actively controlling a UPnP AV
MediaRenderer, observes over the network that a UPnP AV MediaRenderer is currently in the
PAUSED_PLAYBACK or STOPPED state, then seeks to a new position where it enters the
TRANSITIONING state, and then transitions back to the PAUSED_PLAYBACK or STOPPED state
when the seek completes, the UPnP AV MediaRenderer control point needs to invoke an
AVT:GetPositionInfo action to the UPnP AV MediaRenderer after each transport state change
including when the seek completes (i.e. returns to the PAUSED_PLAYBACK or STOPPED state) to
refresh the current position.

10.1.6.16.9
[G UIDELINE ] If a UPnP AV MediaRenderer receives an AVT.Play request to play an image, then it
shall transition into a “PLAYING” state as soon as it successfully decodes and starts rendering the
image.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 6GN3G

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline together with 10.1.6.16.10 and 10.1.6.16.11 define the use of the
“PLAYING” state for UPnP AV MediaRenderers that play image content.

10.1.6.16.10
[G UIDELINE ] If a UPnP AV MediaRenderer is currently playing an image, it shall remain in the
“PLAYING” state until it receives a new action that changes its state, or until some third-party

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 272 –

application forces the UPnP AV MediaRenderer to adopt a different state using means outside the
scope of DLNA.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC CFWQ5

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline together with 10.1.6.16.7 and 10.1.6.16.11 define the use of the
“PLAYING” state for UPnP AV MediaRenderers that play image content.
For example, if a TV that is operating as a UPnP AV MediaRenderer receives a request to display a
picture, the TV will change its state into “PLAYING” as soon as it starts displaying the picture on the
screen. The TV will remain in this state, and will remain displaying the picture, until one of two things
happen:

a) the TV receives a request to change its state from a UPnP AV MediaRenderer Control Point in
the network. The request source could be the original UPnP AV MediaRenderer Control Point or
a different one;
b) a different application forces the TV to change its state. Examples of the latter are: a user tunes
to some channel for watching TV, or the TV starts a screen saver application after some time of
inactivity.
10.1.6.16.11
[G UIDELINE ] If a UPnP AV MediaRenderer that has been playing an image stops displaying the
image due to the intervention of a third-party application, it shall enter into the “STOPPED” or
“NO_MEDIA_PRESENT” states.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 93BWN

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline together with 10.1.6.16.7 and 10.1.6.16.10 define the use of the
“PLAYING” state for UPnP AV MediaRenderers that play image content.
For example, if a TV operating as a UPnP AV MediaRenderer is displaying a picture and changes
the picture due to some screen saver application, the TV will change its state into “STOPPED” or
“NO_MEDIA_PRESENT” as long as the TV can still respond successfully to requests to play media
from the network. Notice that some third-party applications do not allow the TV to receive control
actions as long as the third-party application is controlling the device. For example, a TV that is
currently used for watching broadcast channels could block action requests from the network to play
media.

10.1.6.16.12
[G UIDELINE ] If a UPnP AV MediaRenderer is currently playing an image, and it receives an
AVT:Stop action, then it shall transition into the “STOPPED” state.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC GWEVN

29341-14-10
ISO/IEC
29341-3-2

DLNA guidelines; Part 1-1: Architecture and protocols

 – 273 –

10.1.6.16.13
[G UIDELINE ] If in a UPnP AV MediaRenderer the value of the AVT.CurrentTrackURI virtual
instance state variable is an image URI, and if the UPnP AV MediaRenderer is in the “STOPPED”
state, then the UPnP AV MediaRenderer shall not display the image.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC FAINZ

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline clarifies that when a UPnP AV MediaRenderer is in the “STOPPED”
state, and the currently available content is an image, the UPnP AV MediaRenderer needs to clear
the screen and not show the image.

10.1.6.17 MM transport actions

10.1.6.17.1
[G UIDELINE ] The comma-separated list of values listed in the AVT.CurrentTransportActions virtual
instance state variable may change depending on what the device is doing and what content the
device is accessing.

[ATTRIBUTES ]

O R DMR n/a n/a ISO/IEC VLXYX

29341-14-10

[C OMMENT] This guideline requirement references the permitted and expected behaviors of a
device that dynamically enables/disables its AVTransport actions.

10.1.6.17.2
[G UIDELINE ] The value returned in the Actions output argument of an
AVT:GetCurrentTransportActions request shall match the value of the
AVT.CurrentTransportActions virtual instance state variable.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC V393O

29341-14-10

10.1.6.17.3
[G UIDELINE ] A UPnP AV MediaRenderer control point should provide a UI indicator to inform a user
of disabled transport actions.

[ATTRIBUTES ]

S C DMC +PU+ M-DMC n/a n/a 6RFRG

[C OMMENT] This guideline requires control points to provide UI indications to inform users that a
playback feature is disabled. Without this information, a user can be misled into believing that the
device is not working properly. Examples of user indicators include the following:

• gray-out the button for the disabled operation;

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 274 –

• an icon that flashes on the screen to indicate the disabled state when the user pushes the
button.
Depending on UI form factor this guideline can be difficult to implement, such as a handheld remote
with physical buttons.

10.1.6.17.4
[G UIDELINE ] A UPnP AV MediaRenderer shall report the disabling of the Pause operation by
excluding the value “Pause” from the Actions output argument of an
AVT:GetCurrentTransportActions and the AVT.CurrentTransportActions virtual instance state
variable.

[ATTRIBUTES ]

M C DMR n/a n/a n/a DW6X6

10.1.6.17.5
[G UIDELINE ] If a UPnP AV MediaRenderer's AVT.NumberOfTracks value is greater than 1, then the
AVT:Next/AVT:Previous actions shall have the behavior of incrementing/decrementing the
AVT:CurrentTrack virtual instance state variable (and likewise properly reflecting other state
change information required by the AVTransport specification).

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC BWN9C

29341-14-10

[C OMMENT] This guideline defines the behavior of AVT:Next and AVT:Previous in the context of
playing a media collection. Behavior for AVT:Next and AVT:Previous is not defined for other cases.

10.1.6.17.6
[G UIDELINE ] If a UPnP AV MediaRenderer's AVT.NumberOfTracks value is equal to 1, then a
UPnP AV MediaRenderer control point should not issue the AVT:Next and AVT:Previous actions, as
the behavior performed by a UPnP AV MediaRenderer is implementation dependent.

[ATTRIBUTES ]

S C DMC +PU+ M-DMC n/a ISO/IEC 3B8T5

29341-14-10

[C OMMENT] The behavior is not defined in ISO/IEC 29341-14-10 and preferably will not be used in
this particular situation.

10.1.6.17.7
[G UIDELINE ] If in a UPnP AV MediaRenderer, the value of the AVT.TransportURI virtual instance
state variable is an image URI, then the value of the AVT.CurrentTransportActions virtual instance
state variable should not include the value “Pause”.

[ATTRIBUTES ]

S C DMR n/a n/a ISO/IEC B2JKO

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] If a UPnP AV MediaRenderer plays an image, the relevant transport actions are “Play”
DLNA guidelines; Part 1-1: Architecture and protocols
 – 275 –

and “Stop. The UPnP AV MediaRenderer could also accept “Pause”, but the behavior is
vendor-dependent.

10.1.6.17.8
[G UIDELINE ] If in a UPnP AV MediaRenderer, the value of the AVT.TransportURI virtual instance
state variable is a DLNA PlayContainer URI, or a URI of a media collection file, and the
AVT.CurrentTrackURI virtual instance state variable is an image URI, then the value of
AVT.CurrentTransportActions virtual instance state variable may include the value “Pause”.

[ATTRIBUTES ]

O C DMR n/a n/a ISO/IEC B5DWR

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] If a UPnP AV MediaRenderer plays an image within a playlist, it could accept “Pause”.
The behavior is described in 10.1.6.17.9.

10.1.6.17.9
[G UIDELINE ] If in a UPnP AV MediaRenderer the value of the AVT.CurrentTrackURI virtual
instance state variable is an image URI, and if the UPnP AV MediaRenderer lists “Pause” in the
AVT.CurrentTransportActions virtual instance state variable, then upon receiving an AVT:Pause
action, the UPnP AV MediaRenderer shall transition into the “PAUSED_PLAYBACK” state.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC MFW38

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] Some UPnP AV MediaRenderers will support Pause as a transport operation available
when the current track is an image. This transport action is useful only when the
AVT.AVTransportURI virtual instance state variable contains the URI of a media collection file or is
a DLNA PlayContainer URI.

10.1.6.17.10
[G UIDELINE ] If in a UPnP AV MediaRenderer the value of the AVT.CurrentTrackURI virtual
instance state variable is an image URI, and if the UPnP AV MediaRenderer is in the
“PAUSED_PLAYBACK” state, then the UPnP AV MediaRenderer may display the image.

[ATTRIBUTES ]

O C DMR n/a n/a ISO/IEC O9GZ4

29341-14-10
ISO/IEC
29341-3-2

[C OMMENT] This guideline clarifies that when a UPnP AV MediaRenderer is in the

“PAUSED_PLAYBACK” state, and the current track is an image, the UPnP AV MediaRenderer may
continue displaying the image.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 276 –

10.1.6.18 MM Play mode behavior

10.1.6.18.1
[G UIDELINE ] UPnP MediaRenderers that implement AVT:SetPlayMode shall implement the
method such that changes to the current play mode are applied immediately.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 4K4ZY

29341-14-10

[C OMMENT] An example of bad behavior is a MediaRenderer that requires a control point to invoke
AVT:Play after a call to AVT:SetPlayMode in order for the requested play mode to be applied.

10.1.6.18.2
[G UIDELINE ] UPnP MediaRenderers that change the play mode may change the transport state so
long as the new state is not STOPPED.

[ATTRIBUTES ]

O C DMR n/a n/a ISO/IEC EXLSF

29341-14-10

10.1.6.18.3
[G UIDELINE ] UPnP MediaRenderers should keep the same play mode after a call to
AVT:SetAVTransportURI.

[ATTRIBUTES ]

S C DMR n/a n/a ISO/IEC XLSFB

29341-14-10

[C OMMENT] Automatically changing an unrelated portion of the device's state is not a good
practice.

10.1.6.19 MM Play modes

10.1.6.19.1
[G UIDELINE ] UPnP MediaRenderers that implement the "NORMAL" play mode shall implement it
the following manner.

• An AVT:Next request results in AVT.CurrentTrack being incremented by one.

• AVT:Next requests that attempt to change the track number beyond the last track shall result
with no state change (i.e. request accepted and ignored) or a response with a UPnP AV error
code 711 (illegal seek target).
• An AVT:Previous request results in AVT.CurrentTrack being decremented by one.
• AVT:Previous requests that attempt to change the track number before the first track shall result
with no state change (i.e. request accepted and ignored) or a UPnP AV error code 711 illegal
seek target).
• If a new value is applied to AVT.CurrentTrack, then AVT.CurrentTrackURI is updated
appropriately.
• If the play state before an AVT:Next or AVT:Previous request is PLAYING and a new track is
applied, then the device continues playback with the new track.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 277 –

• If the device is in the PLAYING state, with AVT.CurrentTrack = AVT.NumberOfTracks, and

playback finishes for the content indicated by AVT.CurrentTrackURI, then the MediaRenderer
enters the STOPPED state and AVT.CurrentTrack is reset to 1. AVT.CurrentTrackURI is
appropriately updated, but AVT.AVTransportURI remains the same. This bulleted item does not
apply when AVT.NextAVTransportURI is set as a result of AVT:SetNextAVTransportURI.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC K4ZYS

29341-14-10

[C OMMENT] The AVTransport specification does not specify the behavior of different play modes.
These guidelines specify the basic expectations, inspired largely from traditional consumer
electronics devices that play optical media content. The AVTransport specification can require
additional behaviors of the MediaRenderer.

10.1.6.19.2
[G UIDELINE ] UPnP MediaRenderers that implement the "REPEAT_ONE" play mode shall
implement it in the same manner as 10.1.6.19.1, except in the following manners.

• If the device is in the PLAYING state and playback reaches the end for the content indicated by
AVT.CurrentTrackURI, then the MediaRenderer changes the playback position to "00:00:00"
and continues playing the same content from the beginning.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC WN9C8

29341-14-10

10.1.6.19.3
[G UIDELINE ] UPnP MediaRenderers that implement the "REPEAT_ALL" play mode shall
implement it in the same manner as 10.1.6.19.1, with the following exceptions.

• AVT:Next requests that attempt to change the track number beyond the last track shall result
with AVT.CurrentTrack set to "1".
• AVT:Previous requests that attempt to change the track number before the first track shall result
with AVT.CurrentTrack set to AVT.NumberOfTracks.
• If the device is in the PLAYING state, with AVT.CurrentTrack = AVT.NumberOfTracks, and
playback finishes for the content indicated by AVT.CurrentTrackURI, then the MediaRenderer
resets AVT.CurrentTrack to 1 and AVT.CurrentTrackURI is appropriately updated.
AVT.AVTransportURI remains unchanged and content playback continues with the new track.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC W6X6H

29341-14-10

10.1.6.19.4
[G UIDELINE ] UPnP MediaRenderers that implement the "RANDOM" play mode shall implement it in
the following manner.

• AVT:Next and AVT:Previous requests shall result with AVT.CurrentTrack set to a random value
from "1" to AVT.NumberOfTracks, with the AVT.CurrentTrackURI getting updated appropriately.
If the play state is PLAYING, then content playback continues with the new track.
• If a new value is applied to AVT.CurrentTrack, then AVT.CurrentTrackURI getting updated
appropriately.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 278 –

• If the play state before an AVT:Next or AVT:Previous request is PLAYING and a new track is
applied, then the device continues playback with the new track.
• If the device is in the PLAYING state and playback finishes for the content indicated by
AVT.CurrentTrackURI, then the MediaRenderer sets a new random value for AVT.CurrentTrack
and AVT.CurrentTrackURI is appropriately updated. AVT.AVTransportURI remains unchanged
and content playback continues with the new track.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC RFRGK

29341-14-10

10.1.6.19.5
[G UIDELINE ] UPnP MediaRenderers that implement the "SHUFFLE" play mode shall implement it
in the same manner as "RANDOM" (see 10.1.6.19.4) except for the following manners.

• The device shall track the value history of AVT.CurrentTrack so that the new track value is not a
repeat of a previously played track.
• When the MediaRenderer has played all of the items (i.e. all tracks have been played), then the
device enters the STOPPED state and the AVT.CurrentTrack changes to "1".
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 393O8

29341-14-10

10.1.6.19.6
[G UIDELINE ] UPnP MediaRenderers should support the "REPEAT_ONE", "REPEAT_ALL" and
either "SHUFFLE" or "RANDOM" play modes.

[ATTRIBUTES ]

S L DMR n/a n/a ISO/IEC LXYXC

29341-14-10

[C OMMENT] The "NORMAL" play mode is required, but these additional play modes are only
recommended.

10.1.6.20 MM play-speed
10.1.6.20.1
[G UIDELINE ] UPnP AV MediaRenderers may include element <allowedValueList> to specify a list
of allowed values for AVT.TransportPlaySpeed in the service description document as defined by
the AVTransport specification ISO/IEC 29341-14-10.

[ATTRIBUTES ]

O R DMR n/a n/a ISO/IEC 4WMJW

29341-14-10

[C OMMENT] This guideline indicates that listing play-speed values in the service description
document is optional.

Some UPnP AV MediaRenderers will only support a play-speed value of "1". These UPnP AV
MediaRenderers could publish this value in the allowed-value list of the service description
document.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 279 –

Some UPnP AV MediaRenderers will rely on a UPnP AV MediaServer to provide support for
play-speed operations. These UPnP AV MediaRenderers do not know a-priori the speed values that
the servers will support. These UPnP AV MediaRenderers cannot list any values in the service
description document.

Some UPnP AV MediaRenderers could rely only on themselves to provide play-speed support. In
this case, these UPnP AV MediaRenderers could publish an exhaustive list of play-speed values in
the service description document.

Finally, a fourth class of UPnP AV MediaRenderers will support both server-driven and
renderer-driven play-speed operations. In this case, the UPnP AV MediaRenderers cannot publish
an exhaustive list of speed values in the service description document and consequently, these
UPnP AV MediaRenderers would also omit the allowed-value list.

If a UPnP AV MediaRenderer chooses not to specify a list of allowed play-speed values, then
AVT.TransportPlaySpeed is defined in the service description document as follows:

<stateVariable sendEvents="no">
<name>TransportPlaySpeed</name>
<dataType>string</dataType>
</stateVariable>

10.1.6.20.2
[G UIDELINE ] If a UPnP AV MediaRenderer includes the <allowedValueList> element for the
AVT.TransportPlaySpeed state variable in the service description, the element shall contain all the
play-speed values that the UPnP AV MediaRenderer accepts as the value of the Speed input
argument in an AVT:Play action. In addition, each value shall be represented as a rational fraction
in accordance with the UPnP AVTransport specification.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC 28RT5

29341-14-10

[C OMMENT] If a DMR specifies a list of values in the service description document, then UPnP AV
MediaRenderer control points know a priori which speed values can never be used because they
are unlisted. Notice that having a value in the list does not automatically indicate that the DMR will
provide support for this value for a particular content resource. For any given content resource, the
DMR will implement a subset of the allowed values published in the service description. The
implemented values will be available to the controllers, as defined in 10.1.6.29.1.

Specifying allowed values like "NORMAL", "2x" or "Backwards Slow 0.25" are not allowed.
Examples of correct representations are "1", "2", and "−1/4".

This guideline imposes no requirement on a control point to represent play-speeds on a user

interface as a rational fraction.
For example, if a UPnP AV MediaRenderer that supports speeds 1 and 4 chooses to specify a list of
allowed values, then AVT.TransportPlaySpeed will be defined in the service description document
as follows:

<stateVariable sendEvents="no">
<name>TransportPlaySpeed</name>
<dataType>string</dataType>
<allowedValueList>
<allowedValue>1</allowedValue>
<allowedValue>4</allowedValue>
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 280 –

</allowedValueList>
</stateVariable>

10.1.6.20.3
[G UIDELINE ] If a UPnP AV MediaRenderer specifies a list of allowed values for
AVT.TransportPlaySpeed in the service description, then each of the speed values subsequently
used in the X_DLNA_PS option of AVT.CurrentTransportActions virtual instance state variable shall
be one of the listed values.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC J7LP5

29341-14-10

[C OMMENT] The list of play-speed values exposed by a DMR in the AVT.CurrentTransportActions

virtual instance state variable has to be included in the list of allowed values exposed by the DMR
in the service description document. The following examples explain better this requirement:
Example 1 (correct use)
• Allowed value list = -2, 1, 3, 5, 7, 10, 15, 20, 40
• AVT.CurrentTransportActions includes the option X_DLNA_PS=-2\,3\,40 during playback of the 1st resource.
• AVT.CurrentTransportActions includes the option X_DLNA_PS=7\,10\,15\,40 during playback of the 2nd
resource.
• AVT.CurrentTransportActions includes the option X_DLNA_PS=-2\,3\,5\,7\,10\,15\,20\,40 during playback of the
3rd resource.
Example 2 (incorrect use)
• Allowed value list = -2, 1, 5, 10, 20.
• AVT.CurrentTransportActions includes the option X_DLNA_PS=-8\,3\,40 during playback of the 1st resource.
• AVT.CurrentTransportActions includes the option X_DLNA_PS=1/2\,5\,20 during playback of the 2nd resource.
UPnP AV MediaRenderer control points obtain the list of speed values defined by X_DLNA_PS
using the AVT:GetCurrentTransportActions action or via AVT.LastChange events.

10.1.6.21 MM Renderer volume control

10.1.6.21.1
[G UIDELINE ] UPnP MediaRenderers that support volume control shall implement the RCS.Volume
instance state variable with a range of 0 to 100, where 0 is audibly equivalent to mute and 100 is the
maximum loudness. The stepping for the variable shall be 1.

A MediaRenderer implements volume control when it implements the RCS.Volume instance state
variable.

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC 3FQLR

29341-3-13

[C OMMENT] This guideline provides baseline expectations on how a control point can change the
volume on a MediaRenderer.

The stepping of the RCS.Volume value does not have to correspond to that of actual sound volume.
That is, the actual heard volume stepping can change per five steppings of the RCS.Volume
instance state variable.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 281 –

10.1.6.21.2
[G UIDELINE ] UPnP MediaRenderers that support volume control shall implement RCS:SetVolume,
RCS:GetVolume, RCS:SetMute, and RCS:GetMute.

[ATTRIBUTES ]

M L DMR n/a n/a ISO/IEC AU8BQ

29341-3-13

10.1.6.22 MM DLNAQOS support

[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, AVTransport SOAP actions shall be
tagged with DLNAQOS_2, or a lower DLNAQOS_UP value (where "or a lower" is defined by
8.3.2.2.2 and 8.3.2.2.3), for both requests and responses in accordance with Table 7.

[ATTRIBUTES ]

M A DMR DMC +PU+ M-DMC n/a n/a VW39V

[C OMMENT] All other forms of UPnP AV traffic described in this subclause (e.g. CDS, Rendering
Service) are tagged as per the default DLNAQOS_UP value in Table 7.

10.1.6.23 MM usage of AVT.CurrentTransportActions

10.1.6.23.1
[G UIDELINE ] If a UPnP AV MediaRenderer implements controller-time, controller-byte or
play-speed operations for some content types, it shall implement AVT.CurrentTransportActions
virtual instance state variable, and AVT:GetCurrentTransportActions action.

"UPnP AV MediaRenderers implementing a controller-time seek operation" means: A request from

a UPnP AV MediaRenderer control point to seek to some time instant "t" causes playback to re-start
from time "t" (where "t" has a value larger than or equal to 0 and less than or equal to the duration
of the track).

"UPnP AV MediaRenderers implementing a controller-byte seek operation" means: A request from

a UPnP AV MediaRenderer control point to seek to some byte value "b" causes playback to re-start
from approximately byte "b" in the stream (where "b" has a value larger than or equal to 0 and less
than the track size in bytes).

"UPnP AV MediaRenderers implementing a play-speed operation" means: A request from a UPnP

AV MediaRenderer control point to play at speed "s" causes playback at approximately the speed of
"s", where "s" is any value other than 1.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC V648E

29341-14-10

10.1.6.23.2
[G UIDELINE ] If a UPnP AV MediaRenderer implements the AVT.CurrentTransportActions virtual
instance state variable then it shall always list the available transport actions in this state variable
including any of the DLNA-defined values (as indicated in guidelines 10.1.6.27.1 and 10.1.6.29.1)

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC M76XT

29341-14-10

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 282 –

[C OMMENT] UPnP AV MediaRenderers that support controller-time seek, controller-byte seek, or

play-speed operations have to implement AVT.CurrentTransportActions according to guideline
10.1.6.23.1. When these UPnP AV MediaRenderers play some content for which none of such
operations are available, then the device still needs to show the proper list of transport actions in the
state variable. For example, the available transport actions for an audio track could be: Play, Stop,
Pause.

10.1.6.23.3
[G UIDELINE ] If no content is currently being rendered (i.e. AVT.AVTransportURI is an empty string),
then a UPnP AV MediaRenderer that implements AVT.CurrentTransportActions shall use an empty
string ("") as the value of the AVT.CurrentTransportActions virtual instance state variable.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 8RT59

29341-14-10

10.1.6.24 MM DLNA state variables for renderer control operations

10.1.6.24.1
[G UIDELINE ] If a UPnP AV MediaRenderer implements the controller-byte seek operation for some
content as defined in 10.1.6.23.1, then it shall include the X_DLNA_RelativeBytePosition,
X_DLNA_AbsoluteBytePosition and X_DLNA_CurrentTrackSize state variables in the AVTransport
service description, and shall implement the state variables.

These state variables are defined in Table 20.

Table 20 – DLNA state variables for Controller-byte seek operations

Variable name Data Allowed Evented Moderated

type value event

X_DLNA_RelativeBytePosition string Empty string (""), or a string representing No No

an integer number in the inclusive
interval:
[0, (2^64) − 1]
X_DLNA_AbsoluteBytePosition string Empty string (""), or a string representing No No
an integer number in the inclusive
interval:
[0, (2^64) − 1]
X_DLNA_CurrentTrackSize string Empty string (""), or a string representing No No
an integer number in the inclusive
interval:
[0, (2^64) − 1]

The AVT.X_DLNA_RelativeBytePosition, AVT.X_DLNA_AbsoluteBytePosition, and

AVT.X_DLNA_CurrentTrackSize state variables shall not be evented via AVT.LastChange.

The X_DLNA_RelativeBytePosition state variable shall be defined in the service description

document using the following XML fragment:

<stateVariable sendEvents="no">
<name>X_DLNA_RelativeBytePosition</name>
<dataType>string</dataType>
</stateVariable>

The X_DLNA_AbsoluteBytePosition state variable shall be defined in the service description

document using the following XML fragment:
DLNA guidelines; Part 1-1: Architecture and protocols
 – 283 –

<stateVariable sendEvents="no">
<name>X_DLNA_AbsoluteBytePosition</name>
<dataType>string</dataType>
</stateVariable>

The X_DLNA_CurrentTrackSize state variable shall be defined in the service description document
using the following XML fragment:

<stateVariable sendEvents="no">
<name>X_DLNA_CurrentTrackSize</name>
<dataType>string</dataType>
</stateVariable>

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC SM76X

29341-14-10
ISO/IEC
29341-1

[C OMMENT] This guideline defines new state variables for the UPnP AV MediaRenderer's
AVTransport service. These state variables are implemented by renderers that support
controller-byte seek operations.

The first state variable, X_DLNA_RelativeBytePosition, provides the playback position in bytes
during playback. Controllers that implement controller-byte seek operations can poll this state
variable to determine the current byte processed by the renderer.

The second state variable, X_DLNA_AbsoluteBytePosition, is for future use. DLNA does not
currently define the behavior of this state variable. Its value is vendor-dependent, as long as it
conforms to the syntax defined in this guideline.

The third state variable, X_DLNA_CurrentTrackSize provides the file size information for the track
currently being rendered. Controllers can poll this state variable to determine the file size.

10.1.6.24.2
[G UIDELINE ] If a UPnP AV MediaRenderer implements the AVT.X_DLNA_RelativeBytePosition
virtual instance state variable, its value shall indicate approximately the current byte in the stream
processed for rendering (the current playback position measured in bytes). Byte 0 represents the
first byte in the sequence. If L represents the file size in bytes, then byte L − 1 represents the final
byte in the sequence. If no content is currently being rendered (i.e. AVT.AVTransportURI is an
empty string), the value of the AVT.X_DLNA_RelativeBytePosition virtual instance state variable
shall be an empty string ("").

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 76XTD

29341-14-10
ISO/IEC
29341-1

10.1.6.24.3
[G UIDELINE ] If a UPnP AV MediaRenderer implements the AVT.X_DLNA_CurrentTrackSize virtual
instance state variable then its value shall be one of the following:

• an integer value indicating the size (in bytes) of the track currently being rendered;

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 284 –

• 0 to indicate that the size (in bytes) of the track currently being rendered is unknown;
• an empty string ("") when no track is currently being rendered (i.e. AVT.AVTransportURI is an
empty string).
[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC RT59R

29341-14-10
ISO/IEC
29341-1

10.1.6.24.4
[G UIDELINE ] If a UPnP AV MediaRenderer does not implement the controller-byte seek operation
for any type of resources, then it may omit the X_DLNA_RelativeBytePosition state variable from
the AVTransport service description.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC 48EII

29341-14-10
ISO/IEC
29341-1

10.1.6.24.5
[G UIDELINE ] If a UPnP AV MediaRenderer does not implement the controller-byte seek operation
for any type of resources, then it may omit the X_DLNA_AbsoluteBytePosition state variable from
the AVTransport service description.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC 7LP5V

29341-14-10
ISO/IEC
29341-1

10.1.6.24.6
[G UIDELINE ] If a UPnP AV MediaRenderer does not implement the controller-byte seek operation
for any type of resources, then it may omit the X_DLNA_CurrentTrackSize state variable from the
AVTransport service description.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC 648EI

29341-14-10
ISO/IEC
29341-1

10.1.6.25 MM DLNA actions for renderer control operations

[G UIDELINE ] If a UPnP AV MediaRenderer implements the controller-byte seek operation for some
content as defined in 10.1.6.23.1, then it shall implement the AVT:X_DLNA_GetBytePositionInfo
action.

This action is defined in Table 21.

Table 21 – Arguments for AVT:X_DLNA_GetBytePositionInfo

Argument Direction relatedStateVariable

DLNA guidelines; Part 1-1: Architecture and protocols

 – 285 –

Argument Direction relatedStateVariable

InstanceID IN A_ARG_TYPE_InstanceID
TrackSize OUT X_DLNA_CurrentTrackSize
RelByte OUT X_DLNA_RelativeBytePosition
AbsByte OUT X_DLNA_AbsoluteBytePosition

This action does not have any effect on the state. The error codes defined for this action are
indicated in Table 22.

Table 22 – Error codes for AVT:X_DLNA_GetBytePositionInfo

ErrorCode errorDescription Description

402 Invalid Args Could be any of the following: not enough "in" args, too many "in" args, no
"in" arg by that name, one or more "in" args are of the wrong data type.
712 Invalid InstanceID The specified instanceID is invalid for this AVTransport.

This action shall be defined in the service description document using the following XML fragment:

<action>
<name>X_DLNA_GetBytePositionInfo</name>
<argumentList>
<argument>
<name>InstanceID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable>
</argument>
<argument>
<name>TrackSize</name>
<direction>out</direction>
<relatedStateVariable>X_DLNA_CurrentTrackSize</relatedStateVariable>
</argument>
<argument>
<name>RelByte</name>
<direction>out</direction>
<relatedStateVariable>
X_DLNA_RelativeBytePosition
</relatedStateVariable>
</argument>
<argument>
<name>AbsByte</name>
<direction>out</direction>
<relatedStateVariable>
X_DLNA_AbsoluteBytePosition
</relatedStateVariable>
</argument>
</argumentList>
</action>

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 6XTD3

29341-14-10
ISO/IEC
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 286 –

29341-1

[C OMMENT] This guideline defines a new action for the UPnP AV MediaRenderer AVTransport
service. This action is implemented by renderers that support controller-byte seek operations.
During media playback, UPnP AV MediaRenderer control points can invoke this action against the
UPnP AV MediaRenderer to determine approximately the current byte position in the stream.

10.1.6.26 MM Seek behavior (control points)

10.1.6.26.1
[G UIDELINE ] If a UPnP AV MediaRenderer control point issues an AVT:Seek request with the Unit
input argument equal to REL_TIME, then the value specified in the Target input argument shall be
a time value with the same syntax and semantics defined for res@duration in guideline 10.1.3.8.
The value shall be greater than or equal to 0.

[ATTRIBUTES ]

M A DMC, +PU+ M-DMC n/a ISO/IEC T59RR

29341-14-10

[C OMMENT] In DLNA, UPnP AV MediaRenderer control points can issue AVT:Seek requests using
controller-time and controller-byte variables in addition to seek operations searching for a particular
track (required by ISO/IEC 29341-14-10). This guideline specifies the range of values that can be
used for the controller-time variables.

In DLNA the use of ABS_TIME is not specified. A UPnP AV MediaRenderer control point that needs
to provide fast access in the case of playlists could jump between tracks (using the "seek track"
mode of an AVT:Seek action), and then use controller-time, or controller-byte seek requests on the
resource.

10.1.6.26.2
[G UIDELINE ] If a UPnP AV MediaRenderer control point issues an AVT:Seek request with the Unit
input argument equal to X_DLNA_REL_BYTE then the value specified in the Target input argument
shall be a byte value with the same syntax and semantics defined for
X_DLNA_RelativeBytePosition in guidelines 10.1.6.24.1 and 10.1.6.24.2 to indicate a byte position
to seek. The value shall be greater than or equal to 0.

[ATTRIBUTES ]

M A DMC, +PU+ M-DMC n/a ISO/IEC LP5VR

29341-14-10

[C OMMENT] In DLNA, UPnP AV MediaRenderer control points can issue AVT:Seek requests using
controller-time, and controller-byte variables in addition to seek operations searching for a
particular track (required by ISO/IEC 29341-14-10). This guideline specifies the range of values that
can be used for the controller-byte variables.

In DLNA the use of a hypothetical X_DLNA_ABS_BYTE is not specified. A UPnP AV MediaRenderer

control point that needs to provide fast access in the case of media collections could jump between
tracks (using the "seek track" mode of an AVT:Seek action), and then use controller-time, or
controller-byte-based seek requests on the resource.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 287 –

10.1.6.26.3
[G UIDELINE ] If a UPnP AV MediaRenderer does not specify support for the controller-time
operation as defined in guideline 10.1.6.27.1 then UPnP AV MediaRenderer control points should
not issue an AVT:Seek request with the Unit input argument equal to REL_TIME.

[ATTRIBUTES ]

S A DMC, +PU+ M-DMC n/a ISO/IEC GY633

29341-14-10

[C OMMENT] This guideline recommends UPnP AV MediaRenderer control points to verify first if a
DMR supports the controller-time seek operation before actually issuing a request.

10.1.6.26.4
[G UIDELINE ] If a UPnP AV MediaRenderer does not specify support for the controller-byte
operation as defined in guideline 10.1.6.27.1 then UPnP AV MediaRenderer control points should
not issue an AVT:Seek request with the Unit input argument equal to X_DLNA_REL_BYTE.

[ATTRIBUTES ]

S A DMC, +PU+ M-DMC n/a ISO/IEC 4T7UO

29341-14-10

[C OMMENT] This guideline recommends UPnP AV MediaRenderer control points to verify first if a
DMR supports the controller-byte seek operation before actually issuing a request.

10.1.6.26.5
[G UIDELINE ] If a UPnP AV MediaRenderer provides the track duration according to 10.1.6.27.2,
then when a UPnP AV MediaRenderer control point issues an AVT:Seek request with the Unit input
argument equal to REL_TIME, the value of the Target input argument should be less than the track
duration.

[ATTRIBUTES ]

S A DMC, +PU+ M-DMC n/a ISO/IEC 9Z83X

29341-14-10

10.1.6.26.6
[G UIDELINE ] If a UPnP AV MediaRenderer provides the track size (in bytes) according to
10.1.6.27.5, then when a UPnP AV MediaRenderer control point issues an AVT:Seek request with
the Unit input argument equal to X_DLNA_REL_BYTE, the value of the Target input argument
should be less than the track size (in bytes).

[ATTRIBUTES ]

S A DMC, +PU+ M-DMC n/a ISO/IEC U48W2

29341-14-10

10.1.6.27 MM Seek behavior (renderers)

10.1.6.27.1
[G UIDELINE ] If a UPnP AV MediaRenderer implements controller-time seek operations for the track
currently being rendered as defined in 10.1.6.23.1, a UPnP AV MediaRenderer shall include "Seek"
and "X_DLNA_SeekTime" in the list of comma-separated values of the
AVT.CurrentTransportActions virtual instance state variable.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 288 –

If a UPnP AV MediaRenderer implements controller-byte seek operations for the track currently
being rendered as defined in 10.1.6.23.1, a UPnP AV MediaRenderer shall include "Seek" and
"X_DLNA_SeekByte" in the list of comma-separated values of the AVT.CurrentTransportActions
virtual instance state variable.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC Y633R

29341-14-10

[C OMMENT] In DLNA, UPnP AV MediaRenderer control points can issue AVT:Seek requests using
controller-time and controller-byte seek operations. However, a UPnP AV MediaRenderer might or
might not support some of these operations for a given media resource. This guideline requires
UPnP AV MediaRenderers to use specific text entries in AVT.CurrentTransportActions virtual
instance state variable to indicate support for these controller seek operations. UPnP AV
MediaRenderer control points check the value of this state variable using action
AVT.GetCurrentTransportActions or via AVT.LastChange events to determine if a UPnP AV
MediaRenderer supports the respective seek operations.

10.1.6.27.2
[G UIDELINE ] If a UPnP AV MediaRenderer implements controller-time seek operations for the track
currently being rendered as defined in 10.1.6.23.1, it should provide the track duration in the
AVT.CurrentTrackDuration virtual instance state variable.

[ATTRIBUTES ]

S A DMR n/a n/a ISO/IEC T7UOE

29341-14-10

[C OMMENT] This guideline recommends UPnP AV MediaRenderers to provide the track duration
for controller-time seek operations. Certain control points will be unable to use controller-time seek
operations unless they know the playback duration.

10.1.6.27.3
[G UIDELINE ] If a UPnP AV MediaRenderer includes the res@duration property in the <res>
element that describes the resource currently being rendered, then the value of this property should
be equal to the value of the AVT.CurrentTrackDuration virtual instance state variable. The <res>
element that describes the resource currently being rendered is included in the
AVT.CurrentTrackMetaData virtual instance state variable.

[ATTRIBUTES ]

S A DMR n/a n/a ISO/IEC Z83XO

29341-14-10

[C OMMENT] Providing a playback duration value is a recommendation (not a requirement) for

UPnP AV MediaRenderers. Although in general res@duration and AVT.CurrentTrackDuration have
the same value, in some cases there could be some differences due to distinct algorithms for
computing duration, etc. The res@duration property is provided by a device external to the UPnP
AV MediaRenderer and AVT.CurrentTrackDuration is provided by the UPnP AV MediaRenderer.

10.1.6.27.4
[G UIDELINE ] If a UPnP AV MediaRenderer control point detects different values for the same
media resource in the AVT.CurrentTrackDuration virtual instance state variable and the

DLNA guidelines; Part 1-1: Architecture and protocols

 – 289 –

res@duration property in the AVT.CurrentTrackMetaData virtual instance state variable, the UPnP
control point should use the former in any interactions with the UPnP AV MediaRenderer.

[ATTRIBUTES ]

S A DMC +PU+ M-DMC n/a ISO/IEC FZL57

29341-14-10

[C OMMENT] Guideline 10.1.6.27.3 indicates that the values in res@duration and

AVT.CurrentTrackDuration could be different because they are calculated by different devices
using different algorithms. This guideline recommends UPnP control points to use the value in
AVT.CurrentTrackDuration for interactions with the UPnP AV MediaRenderer; for example, sending
an action to perform a controller-time seek operation.

10.1.6.27.5
[G UIDELINE ] If a UPnP AV MediaRenderer implements controller-byte seek operations for the track
currently being rendered as defined in 10.1.6.23.1, it should provide the track size (in bytes) in the
AVT.X_DLNA_CurrentTrackSize virtual instance state variable.

[ATTRIBUTES ]

S A DMR n/a n/a ISO/IEC 48W2W

29341-14-10

10.1.6.27.6
[G UIDELINE ] If a UPnP AV MediaRenderer includes the res@size property in the <res> element
that describes the resource currently being rendered, then the value of this property should be equal
to the value of the AVT.X_DLNA_CurrentTrackSize virtual instance state variable. The <res>
element that describes the resource currently being rendered is included in the
AVT.CurrentTrackMetaData virtual instance state variable.

[ATTRIBUTES ]

C A DMR n/a n/a ISO/IEC 633RQ

29341-14-10

[C OMMENT] Providing the resource size is a recommendation (not a requirement) for UPnP AV
MediaRenderers. Although in general res@size and AVT.X_DLNA_CurrentTrackSize have the
same value, in some cases there could be some differences due to content transformation, file
modifications, etc. The res@size property is provided by a device external to the UPnP AV
MediaRenderer and AVT.X_DLNA_CurrentTrackSize is provided by the UPnP AV MediaRenderer.

10.1.6.27.7
[G UIDELINE ] If a UPnP AV MediaRenderer control point detects different values for the same
media resource in the AVT.X_DLNA_CurrentTrackSize virtual instance state variable and the
res@size property in the AVT.CurrentTrackMetaData virtual instance state variable, the UPnP
control point should use the former in any interactions with the UPnP AV MediaRenderer.

[ATTRIBUTES ]

S A DMC +PU+ M-DMC n/a ISO/IEC R6BBG

29341-14-10

[C OMMENT] Guideline 10.1.6.27.6 indicates that the values in res@size and

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 290 –

AVT.X_DLNA_CurrentTrackSize could be different because of possible modifications to the media

resource. This guideline recommends UPnP control points to use the value in
AVT.X_DLNA_CurrentTrackSize for interactions with the UPnP AV MediaRenderer; for example,
sending an action to perform a controller-byte seek operation.

10.1.6.27.8
[G UIDELINE ] UPnP AV MediaRenderers shall not include the value X_DLNA_SeekTime in the
AVT.CurrentTransportActions virtual instance state variable when rendering a track that does not
belong to the Audio or AV Media Classes.

UPnP AV MediaRenderers shall not include the value X_DLNA_SeekByte in the

AVT.CurrentTransportActions virtual instance state variable when rendering a track that does not
belong to the Audio or AV Media Classes.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 7UOEU

29341-14-10

[C OMMENT] Controller-time and controller-byte seek operations can only be used with audio or AV
media resources. They cannot be used with other types of resources like images.

10.1.6.27.9
[G UIDELINE ] If a UPnP AV MediaRenderer implements controller-byte seek operations, then it
shall include X_DLNA_REL_BYTE in the allowed value list for the A_ARG_TYPE_SeekMode state
variable in the AVTransport service description document.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 83XOG

29341-14-10

[C OMMENT] DLNA defines a new type of seek mode for controller-byte seek operations. This new
seek mode is triggered by using the value X_DLNA_REL_BYTE in the Unit argument of the
AVT:Seek action. This guideline requires UPnP AV MediaRenderers that support controller-byte
seek to add this value to the allowed values of AVT.A_ARG_TYPE_SeekMode.

10.1.6.27.10
[G UIDELINE ] If a UPnP AV MediaRenderer implements controller-byte seek operations, and it
receives an AVT:Seek request with a Unit value of X_DLNA_REL_BYTE and a Target value greater
than or equal to the track size, then it shall respond with error code 711 (Illegal Seek Target).

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 8W2WO

29341-14-10

[C OMMENT] This guideline applies regardless of whether the UPnP AV MediaRenderer exposes
the track size or not.

10.1.6.27.11
[G UIDELINE ] If a UPnP AV MediaRenderer implements controller-time seek operations, and it
receives an AVT:Seek request with a Unit value of REL_TIME and a Target value greater than the
track duration, then it shall respond with error code 711 (Illegal Seek Target).

DLNA guidelines; Part 1-1: Architecture and protocols

 – 291 –

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 33RQQ

29341-14-10

[C OMMENT] This guideline applies regardless of whether the UPnP AV MediaRenderer exposes
the track duration or not.

10.1.6.27.12
[G UIDELINE ] If a UPnP AV MediaRenderer does not indicate support for controller-byte seek
operations (as defined in guideline 10.1.6.27.1), and if it receives an AVT:Seek request with a Unit
value of X_DLNA_REL_BYTE, then the UPnP AV MediaRenderer shall respond with error code 710
(Seek Mode Not Supported).

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC UOEUS

29341-14-10

[C OMMENT] This guideline defines the error code to be used when the UPnP AV MediaRenderer
Control Point requests controller-byte seek operations for the current track but the UPnP AV
MediaRenderer did not advertise support for this operation.

10.1.6.27.13
[G UIDELINE ] If a UPnP AV MediaRenderer does not indicate support for controller-time seek
operations (as defined in guideline 10.1.6.27.1), and if it receives an AVT:Seek request with a Unit
value of REL_TIME, then the UPnP AV MediaRenderer shall respond with error code 710 (Seek
Mode Not Supported).

[ATTRIBUTES ]

M DMR n/a n/a ISO/IEC 3XOG3

29341-14-10

[C OMMENT] This guideline defines the error code to be used when the UPnP AV MediaRenderer
Control Point requests controller-time seek operations for the current track but the UPnP AV
MediaRenderer did not advertise support for this operation.

10.1.6.28 MM play-speed behavior (renderers)

[G UIDELINE ] A UPnP AV MediaRenderer Control Point that issues an AVT:Play action shall use a
Speed argument with a value of "1" or one of the values specified by the UPnP AV MediaRenderer
in the play-speed-list value (identified by X_DLNA_PS as defined in 10.1.6.29.2) of
AVT.CurrentTransportActions virtual instance state variable.

[ATTRIBUTES ]

M A DMC, +PU+ M-DMC n/a ISO/IEC W2WOV

29341-14-10

[C OMMENT] UPnP AV MediaRenderer Control Points monitor AVT.CurrentTransportActions to

determine the list of available play-speeds for the track currently being rendered. For example, if a
UPnP AV MediaRenderer exhibits the following values:

Play, Stop, Pause, Seek, X_DLNA_SeekTime, X_DLNA_PS=1/2\,4

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 292 –

then, the UPnP AV MediaRenderer Control Point knows that it is possible to issue an AVT:Play
action with speed values of 1, ½, or 4.

10.1.6.29 MM play-speed behavior (renderers)

10.1.6.29.1
[G UIDELINE ] If a UPnP AV MediaRenderer implements play-speed operations for the track
currently being rendered, it shall include the value "Play" and the list of available play-speeds in the
AVT.CurrentTransportActions virtual instance state variable in accordance with guideline
10.1.6.29.2.

When including the list of available play-speeds into AVT.CurrentTransportActions virtual instance
state variable, each comma (",") in the play-speed list shall be escaped as "\,".

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 3RQQ8

29341-14-10

[C OMMENT] In DLNA, some UPnP AV MediaRenderers are capable of playback at different speeds
without the help of a server (renderer-driven play-speeds). Other UPnP AV MediaRenderers are
capable of playback at different speeds only if the server will generate such streams (server-driven
play-speeds). Other UPnP AV MediaRenderers will be able to use both renderer- and server-driven
play-speeds.

A UPnP AV MediaRenderer informs potential controllers of its ability to operate at play-speeds other
than 1 for the track currently being rendered by entering an X_DLNA_PS field in the
comma-separated list of AVT.CurrentTransportActions virtual instance state variable.

10.1.6.29.2
[G UIDELINE ] A UPnP AV MediaRenderer that supports play-speeds other than "1" shall include a
play-speed-list value in the comma-separated list of AVT.CurrentTransportActions. The syntax and
semantics for the play-speed-list value is defined as follows:

• play-speed-list="X_DLNA_PS="speed-list;
• speed-list=speed*(","speed);
• speed=<conforms to the TransportPlaySpeed string, as specified in the AVTransport
specification>;
The value "1" shall not be included.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC OEUSR

29341-14-10

[C OMMENT] UPnP AV MediaRenderers advertise support for play-speeds by adding the list of
play-speeds to the available transport actions indicated in AVT.CurrentTransportActions virtual
instance state variable. For example, a UPnP AV MediaRenderer that supports speeds of ½ and 4
for the current track will set AVT.CurrentTransportActions as follows:

Play, Stop, Pause, Seek, X_DLNA_SeekTime, X_DLNA_PS = 1/2\,4

DLNA guidelines; Part 1-1: Architecture and protocols

 – 293 –

10.1.6.29.3
[G UIDELINE ] UPnP AV MediaRenderers shall not include the play-speed-list value (identified by
X_DLNA_PS as defined in 10.1.6.29.2) in the AVT.CurrentTransportActions virtual instance state
variable for a track that does not belong to the Audio or AV Media Classes.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC XOG3H

29341-14-10

[C OMMENT] The list of play-speed values exposed by a UPnP AV MediaRenderer via X_DLNA_PS
in AVT.CurrentTransportActions can only be used with audio or AV media resources. The list cannot
be used with other types of resources like images.

10.1.6.30 MM usage of AVT.PossiblePlaybackStorageMedia

[G UIDELINE ] A UPnP AV MediaRenderer shall implement minimally the values "None" and
"Network" for the AVT.PossiblePlaybackStorageMedia virtual instance state variable and the
PlayMedia output parameter for the AVT:GetDeviceCapabilities action.

[ATTRIBUTES ]

M R DMR n/a n/a ISO/IEC II9O4

29341-14-10

[C OMMENT] This is the minimal requirement to achieve the DLNA system usages.

10.1.6.31 MM mandatory media operations (renderers)

10.1.6.31.1
[G UIDELINE ] A Rendering Endpoint implementing audio or AV Media Classes shall implement all of
the following media operations:

• Play (guideline 11.4.3.39 GUN:U6498);

• Stop (guideline 11.4.3.40.2 GUN:CWCV2);
• Pause (guideline 11.4.3.41.2 GUN: CZ794);
• Seek (guideline 11.4.3.44.2 GUN: PHT47));
• Pause-Release (guideline 11.4.3.42.1 GUN:3W5QP).
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC S4HXE

2616

[C OMMENT] An HTTP Client is required to support media operations on all supported Media Format
Profiles (see 11.4.3.52.1) regardless of the data availability model (see 10.1.3.29.2).

10.1.6.31.2
[G UIDELINE ] A Rendering Endpoint implementing AV Media Class shall implement all of the
following media operations:

• Fast Forward Scan (guideline 11.4.3.45.2 GUN: T24LR);

• Slow Forward Scan (guideline 11.4.3.46.2 GUN: Z9BD2);
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 294 –

• Fast Backward Scan (guideline 11.4.3.47.2 GUN: V46LS);

• Slow Backward Scan (guideline 11.4.3.48.2 GUN: A89O5).
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC XDI2P

2616

[C OMMENT]

a) An operation might not always invoke the corresponding Media Operation due to buffering on
the Rendering Endpoint.
b) An HTTP Client is required to support media operations on all supported Media Format Profiles
(see 11.4.3.52.1) regardless of the data availability model (see 10.1.3.29.2)
10.1.6.32 MM mandatory media operations (servers)
10.1.6.32.1
[G UIDELINE ] For every AV content binary not using DLNA Link Protection that supports “Limited
Random Access Data Availability” Mode 1 or “Full Random Access Data Availability” model (see
11.4.2.16 for details on mode), an HTTP Server Endpoint shall indicate support in the fourth field of
the ProtocolInfo for at least one of the following:

• time-based seek;
• byte-based seek.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 22FAG

2616

[C OMMENT] A content binary that is restricted to "Limited Random Access Data Availability" Mode
0 is considered live content and might have limited ability to support scan modes. (See 11.4.2.16.2).

10.1.6.32.2
[G UIDELINE ] For every AV content binary not using DLNA Link Protection that supports “Limited
Random Access Data Availability” Mode 1 or “Full Random Access Data Availability” model (see
11.4.2.16 for details on mode), an HTTP Server Endpoint should indicate support in the fourth field
of the ProtocolInfo for the following:

• play-speed.
[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC T8DBH

2616

[C OMMENT] A content binary that is restricted to "Limited Random Access Data Availability" Mode
0 is considered live content and might have limited ability to support scan modes. (See 11.4.2.16.2.)

10.1.7 AVT SetNextAVTransportURI action

10.1.7.1 General Requirements
10.1.7.1.1 Implementation of the SetNextAVTransportURI action
[G UIDELINE ] A UPnP AV MediaRenderer shall implement the AVT:SetNextAVTransportURI action.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 295 –

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 9W968

29341-14-10

[C OMMENT] A DMR always implements the ability to receive and process this action..

10.1.7.1.2 Implementation of the SetNextAVTransportURI action

[G UIDELINE ] If a UPnP AV MediaRenderer receives a valid non-empty
AVT:SetNextAVTransportURI action, then the renderer shall transfer the values in the NextURI and
NextURIMetadata arguments to the corresponding AVT instance state variables
AVT.NextAVTransportURI and AVT.NextAVTransportURIMetaData respectively. A valid non-empty
AVT:SetNextAVTransportURI action is defined as an action for which:

• The action format is syntactically correct; as defined in guideline 10.1.7.1.3.

• The content referenced by the action has a protocolInfo value that matches one of the
protocolInfo values supported by the UPnP AV MediaRenderer.
This guideline applies to a UPnP AV MediaRenderer in the PLAYING, STOPPED, and
PAUSED_PLAYBACK states.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC H8UI6

29341-14-10

[C OMMENT] This guideline describes the conventional way of setting the “Next URI” state variables
in compliance with the UPnP AVT service specifications ISO/IEC 29341-14-10. This guideline also
defines the conditions necessary to accept the action.

10.1.7.1.3 Syntactically correct AVT:SetNextAVTransportURI

[G UIDELINE ] An AVT:SetNextAVTransportURI action is a syntactically correct action if it complies
with the following requirements:

• The action shall comply with the syntax requirement defined in ISO/IEC 29341-14-10 and
ISO/IEC 29341-1.
• The NextURI argument shall carry an empty string or a URI.
• If the NextURI argument is not an empty string or a DLNA PlayContainer URI, then the
NextURIMetaData argument shall be a valid, non-empty value, as defined in 10.1.6.14.8.
• If the NextURI argument is an empty string or a DLNA PlayContainer URI, then the
NextURIMetaData argument shall be an empty string.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC SUBBH

29341-14-10
ISO/IEC
29341-1

[C OMMENT] This guideline describes the correct syntax for the AVT:SetNextAVTransportURI. In
particular this guideline indicates that the same metadata conditions available for
AVT:SetAVTransportURI apply to the use of AVT:SetNextAVTransportURI.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 296 –

10.1.7.1.4 Responding to requests that set the next URI

[G UIDELINE ] If a UPnP AV MediaRenderer receives a valid non-empty
AVT:SetNextAVTransportURI action, then the renderer shall perform at least one of the following
two tasks before providing a response to the action request:

• The renderer sends an HTTP HEAD request using one of the URIs available in the
NextURIMetaData argument to validate availability of the server hosting the resource.
• The renderer sends a partial HTTP GET request using one of the URIs available in the
NextURIMetaData argument to validate availability of the server hosting the resource.
This guideline applies to a UPnP AV MediaRenderer in the PLAYING, STOPPED, and
PAUSED_PLAYBACK states.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC XU5PW

29341-14-10

[C OMMENT] This guideline describes the expected behavior for DMR devices when they receive an
AVT:SetNextAVTransportURI action.

10.1.7.1.5 Replacing the next URI

[G UIDELINE ] If a UPnP AV MediaRenderer already includes a “next URI” and receives a valid
non-empty AVT:SetNextAVTransportURI action, then the renderer shall replace the values in state
variables related to the “next URI” with the values received in the recent
AVT:SetNextAVTransportURI action.

This guideline applies to a UPnP AV MediaRenderer in the PLAYING, STOPPED, and

PAUSED_PLAYBACK states.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC D8B4X

29341-14-10

[C OMMENT] This guideline describes the process to replace the existing “next URI” data with
different values received in a recent AVT:SetNextAVTransportURI action.

10.1.7.1.6 Clearing the next URI

[G UIDELINE ] If a UPnP AV MediaRenderer already includes a “next URI” and receives an empty
AVT:SetNextAVTransportURI action, then the renderer shall clear the state variables related to the
“next URI”.

This guideline applies to a UPnP AV MediaRenderer in the PLAYING, STOPPED, and

PAUSED_PLAYBACK states.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC A6KYE

29341-14-10

[C OMMENT] This guideline describes a method that UPnP MediaServer Control Points can use to
clear the values included in the AVT.NextAVTransportURI and AVT.NextAVTransportURIMetaData
instance state variables.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 297 –

10.1.7.1.7 Resetting the current URI

[G UIDELINE ] If a UPnP AV MediaRenderer already includes a “current URI” and a “next URI” and
receives an AVT:SetAVTransportURI action carrying a valid non-empty URI, then the renderer shall
replace the information in the “current URI” state variables with the information received in the
AVT:SetAVTransportURI action. Simultaneously, the renderer shall clear the state variables related
to the “next URI”.

This guideline applies to a UPnP AV MediaRenderer in the PLAYING, STOPPED, and

PAUSED_PLAYBACK states.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 3YCD4

29341-14-10

[C OMMENT] This guideline describes the DMR behavior in the following conditions: The DMR
includes values for the current and next URI. This DMR receives a new SetAVTransportURI action
from the network with a non-empty and valid URI. The DMR accepts the SetAVTransportURI
request, replaces the current URI, and clears all state variables related to the next URI.

10.1.7.1.8 Effect of an empty AVT:SetAVTransportURI

[G UIDELINE ] If a UPnP AV MediaRenderer includes a “current URI” and a “next URI” and receives
an AVT:SetAVTransportURI action with an empty URI, then the renderer shall behave as described
in guideline 10.1.6.11.7 In addition, the renderer shall clear the state variables related to the “next
URI”.

This guideline applies to a UPnP AV MediaRenderer in the PLAYING, STOPPED, and

PAUSED_PLAYBACK states.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC GH5GB

29341-14-10

[C OMMENT] This guideline describes the DMR behavior upon receiving an

AVT:SetAVTransportURI action with an empty URI. As described in these guidelines, the DMR
clears the state variables related to the “current URI”. This guideline clarifies that the DMR also
clears the state variables related to the “next URI”. After clearing the state variables, the DMR
enters the NO_MEDIA_PRESENT state.

10.1.7.1.9 Prefetching content

[G UIDELINE ] If a UPnP AV MediaRenderer receives a valid, non-empty
AVT:SetNextAVTransportURI action, then the renderer shall comply with the following behaviors:

• If the URI in the action identifies content of the image class, and if the renderer has not cached
the image resource, then the renderer shall issue an HTTP GET request using this URI (or one
of the alternative URIs from the NextURIMetaData argument) to prefetch the image resource.
• If the URI in the action identifies content of the audio or A/V class, and if the renderer has not
cached the media resource, then the renderer shall issue an HTTP GET request using this URI
(or one of the alternative URIs from the NextURIMetaData argument) during playback of the
“current URI” to prefetch partially or completely the media resource.
[ATTRIBUTES ]

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 298 –

M A DMR n/a n/a ISO/IEC JGXCT

29341-14-10

[C OMMENT] This guideline indicates that an DMR needs to prefetch content when it receives an
AVT:SetNextAVTransportURI request. Prefetching the next resource becomes necessary to
provide a smooth transition when an DMR switches from the current to the next URI. Image content
is prefetched as soon as the DMR receives the action request. Audio or A/V content can be
prefetched partially or completely at any time while the “current URI” plays.

10.1.7.2 State Management

10.1.7.2.1 Transitions from the current to the next URI
[G UIDELINE ] If a UPnP AV MediaRenderer is playing the “current URI” and playback reaches the
end of the stream, then the renderer shall start playing one of the resources of the media item
associated with the “next URI” (if available). During the transition from the current to the next URI,
the renderer shall change its state using one of the following two options:

• From PLAYING into PLAYING.

• From PLAYING into TRANSITIONING and then into PLAYING.
[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC THURY

29341-14-10

[C OMMENT] This guideline describes the expected transition procedures when an DMR moves
from the “current URI” to the “next URI”.

10.1.7.2.2 Stopping playback

[G UIDELINE ] If a UPnP AV MediaRenderer is playing the “current URI” and it receives a request to
stop playback, then the renderer shall enter the STOPPED state. The renderer shall not
automatically play the media item associated with the “next URI” (if available)

This guideline applies to all cases where the “current URI” describes a resource of the Audio, Image,
or AV class.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC Y8FA9

29341-14-10

[C OMMENT]

a) This guideline describes the expected behavior if a user stops playing the content. If a user
stops playing the content, the user normally assumes that playback will stop. The user does not
know if the DMR has already stored information for the next URI or not.
b) This guideline does not apply to cases where the “current URI” describes collections of
resources (i.e., Media Collections or PlayContainerURI).
10.1.7.2.3 Implementation of the AVT:Next action in the PLAYING and STOPPED states
[G UIDELINE ] If a UPnP AV MediaRenderer is in the PLAYING or STOPPED states, and if the
renderer has a “current URI” and a “next URI”, then the renderer shall allow the use of the AVT:Next
action.

[ATTRIBUTES ]

DLNA guidelines; Part 1-1: Architecture and protocols

 – 299 –

M A DMR n/a n/a ISO/IEC 2CUUX

29341-14-10

[C OMMENT] This guideline indicates that an DMR allows the AVT:Next action whenever the DMR
has a “current URI” and a “next URI” in the PLAYING or STOPPED states.

10.1.7.2.4 Implementation of the AVT:Next action in the PAUSED_PLAYBACK state

[G UIDELINE ] If a UPnP AV MediaRenderer is in the PAUSED_PLAYBACK state, and if it has a
“current URI” and a “next URI”, then the renderer may allow the use of the AVT:Next action.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC 8S5WZ

29341-14-10

[C OMMENT] This guideline indicates that the AVT:Next action is an option in the
PAUSED_PLAYBACK state.

10.1.7.2.5 Advertising the implementation of the AVT.Next action

[G UIDELINE ] If a UPnP AV MediaRenderer allows the use of the AVT.Next action, then the renderer
shall list the keyword ‘Next’ in the AVT.CurrentTransportActions instance state variable.

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC 57Y7B

29341-14-10

[C OMMENT] This guideline clarifies the need to advertise an implementation of AVT:Next using the
AVT.CurrentTransportActions state variable.

10.1.7.2.6 Forced transition from the current to the next URI (PLAYING state)
[G UIDELINE ] If a UPnP AV MediaRenderer has a “current URI” and a “next URI” in the PLAYING
state, and if this renderer receives an AVT:Next action, then the renderer shall start playing one of
the resources of the media item associated with the “next URI”.

During the transition from the current to the next URI, a UPnP AV MediaRenderer shall change its
state using one of the following two options:

• From PLAYING into PLAYING.

• From PLAYING into TRANSITIONING and then into PLAYING.
This guideline applies to all cases where the “current URI” describes a resource of the Audio, Image,
or AV Media Class.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC DDXT5

29341-14-10

[C OMMENT]

a) This guideline describes the use of the AVT:Next action as a method to force a transition from
the current URI to the next URI.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 300 –

b) Images do not have playback duration like audio or A/V resources. For images, the only way to
trigger a transition from the current to the next URI is by invoking the AVT.Next action.
c) This guideline does not apply to cases where the “current URI” describes collections of
resources (i.e., Media Collections or PlayContainerURI).
10.1.7.2.7 Forced transition from the current to the next URI (STOPPED state)
[G UIDELINE ] If a UPnP AV MediaRenderer has a “current URI” and a “next URI” in the STOPPED
state, and if the renderer receives an AVT:Next action, then the renderer shall do the following:

• Transfer the values from the “next URI” state variables to the “current URI” state variables.
• Clear the “next URI” state variables.
• Remain in the STOPPED state.
This guideline applies to all cases where the “current URI” describes a resource of the Audio, Image,
or AV Media Class.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC IXULC

29341-14-10

[C OMMENT]

a) This guideline describes the use of the AVT:Next action as a method to force a transition from
the current URI to the next URI. Specifically, this guideline describes the DMR behavior when
the AVT:Next action is used in the STOPPED state.
b) This guideline does not apply to cases where the “current URI” describes collections of
resources (i.e., Media Collections or PlayContainerURI).
10.1.7.2.8 Forced transition from the current to the next URI (PAUSED_PLAYBACK state)
[G UIDELINE ] If a UPnP AV MediaRenderer has a “current URI” and a “next URI” in the
PAUSED_PLAYBACK state, and if the renderer allows the use of the AVT:Next action in this state,
and if the renderer receives an AVT:Next action, then the renderer shall do the following:

• Transfer the values from the “next URI” state variables to the “current URI” state variables.
• Clear the “next URI” state variables.
• Remain in the PAUSED_PLAYBACK state.
This guideline applies to all cases where the “current URI” describes a resource of the Audio, Image,
or AV Media Class.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC OIVUH

29341-14-10

[C OMMENT]

a) This guideline describes the use of the AVT:Next action as a method to force a transition from
the current URI to the next URI. Specifically, this guideline describes the DMR behavior when
the AVT:Next action is used in the PAUSED_PLAYBACK state.
b) This guideline does not apply to cases where the “current URI” describes collections of
resources (i.e., Media Collections or PlayContainerURI).

DLNA guidelines; Part 1-1: Architecture and protocols

 – 301 –

10.1.7.2.9 Disallowed AVT:Next action

[G UIDELINE ] If a UPnP AV MediaRenderer does not advertise support for the AVT:Next action in
the AVT.CurrentTransportActions instance state variable, and if the renderer receives an AVT:Next
action, then the renderer shall respond with error 711 (transition not available).

[ATTRIBUTES ]

M C DMR n/a n/a ISO/IEC VTJ8F

29341-14-10

[C OMMENT] This guideline describes the case of an DMR that does not advertise support for the
AVT:Next action but it receives an AVT:Next action , the DMR returns the error code specified in this
guideline.

10.1.8 Upload and Optional Content Management requirements

10.1.8.1 MM/CM: DMS with Upload Device Option support definition
10.1.8.1.1
[G UIDELINE ] A UPnP AV MediaServer may support the Upload Device Option by implementing the
baseline upload AnyContainer (defined in 10.1.8.11) and optionally the optional content
management operations (OCM operations, as defined in 10.1.8.2).

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC MVRMU

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline means that a DMS or M-DMS can implement the Upload Device Option
(i.e. can receive uploaded content from an +UP+).

If the DMS or M-DMS implements the Upload Device Option, then it also implements upload
AnyContainer. It can additionally support various OCM operations.

10.1.8.1.2
[G UIDELINE ] If a UPnP AV MediaServer supports the Upload Device Option, it shall support the
upload AnyContainer operation.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WMJW5

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The baseline requirement for a DMS or M-DMS that supports the Upload Device
Option is to be able to receive a CDS:CreateObject request that specifies the
"DLNA.ORG_AnyContainer" as the parent container for a new CDS item. The DMS or M-DMS needs
to be able to receive the content through an HTTP POST request.
The following is an example sequence of events for an upload scenario.

• The Upload Controller invokes CDS:CreateObject on the DMS. The metadata describes an
image to be created in "DLNA.ORG_AnyContainer".

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 302 –

• The DMS approves the metadata from the CDS:CreateObject request to determine if it is valid.
Since the parent container specifies "DLNA.ORG_AnyContainer", then the DMS decides that
the new image object belongs in an existing CDS container (title of "New Photos") for all image
uploads.
• The DMS sends the CDS:CreateObject response to the Upload Controller. The response
indicates the object will be in the "New Photos" container. The response also includes a <res>
element that omits a URI value but has a URI value for res@importUri.
• The Upload Controller uses an HTTP POST request to transfer the image file to the DMS.
When the DMS is able to serve the new image, it provides a URI value for the <res> element.

10.1.8.2 MM/CM: Optional Content Management operation definitions

[G UIDELINE ] If a UPnP AV MediaServer supports optional content management (OCM) operations,
it may support one or more of the following OCM operations.

• OCM: upload content. Use this to upload content to a specific CDS container. This operation has
2 steps: use CDS:CreateObject to create a CDS item and use HTTP POST to transfer the
content.
• OCM: create child container. Use this to create a new CDS container in a specified CDS
container. This operation has one step: use CDS:CreateObject to create a CDS container. This
operation is generally used as a preceding step to an OCM: upload content operation.
• OCM: destroy object. Use this to destroy a CDS object. This operation has one step: use
CDS:DestroyObject to destroy a CDS object.
• OCM:change metadata. Use this to alter the metadata of an existing CDS item. This operation
has one step: use CDS:UpdateObject to update the CDS metadata. Note that this operation can
be used to add, delete, or change an existing metadata element of an item.
[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC FQLR9

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The guidelines define interoperability specifically for the described usages. Vendors
need to always implement behavior that is consistent with the DLNA guidelines, even if the
implementation will be used for an operation that has different preconditions. For example, a DMS
that supports the OCM: create child container can allow control points to create CDS containers. In
such a scenario, the DMS and control point need to abide by appropriate syntax rules for
CDS:CreateObject.

The guideline also permits other forms of management operations, although the guidelines do not
define interoperability rules for them.

OCM: destroy item has been replaced by OCM: destroy object. All original functionality on items is
retained; however, revision to guidelines now allows Destroy operations on containers.

10.1.8.3 MM/CM: Upload Controller and Mobile Digital Media Uploader

10.1.8.3.1
[G UIDELINE ] A DLNA device class may implement the Upload Controller Device Capability.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 303 –

[ATTRIBUTES ]

O A DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC U8BQB

M-DMC 29341-20-12
ISO/IEC
29341-20-3

10.1.8.3.2
[G UIDELINE ] An Upload Controller shall implement a UPnP AV MediaServer control point capable
of invoking the following actions.

• CDS:CreateObject.
[ATTRIBUTES ]

M C +UP+ n/a n/a ISO/IEC W39VI

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] CDS:CreateObject is the action that allows an Upload Controller to upload content.
The guidelines specify that the normative content transfer methodology involves HTTP POST, as
described in guideline 11.4.3.65.1.

10.1.8.3.3
[G UIDELINE ] An Upload Controller shall support the upload AnyContainer operation.

[ATTRIBUTES ]

M C +UP+ n/a n/a ISO/IEC VRMUZ

29341-20-12
ISO/IEC
29341-20-3

10.1.8.3.4
[G UIDELINE ] An Upload Controller may implement a UPnP AV MediaServer control point capable
of invoking the following actions.

• CDS:DestroyObject
By supporting these actions, an Upload Controller can be capable of supporting additional optional
content management operations.

See 10.1.8.2 for more information about optional content management operations.

[ATTRIBUTES ]

O C +UP+ n/a n/a ISO/IEC MJW54

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] CDS:DestroyObject is the action that allows an Upload Controller to destroy a CDS
object when a content transfer failed or when the user wants to remove uploaded content from the
DMS.

Upload Controllers are allowed to implement support for other CDS actions, but the DLNA
guidelines do not specify the interoperability behavior for other actions.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 304 –

10.1.8.4 MM/CM: Determining Upload AnyContainer support

10.1.8.4.1
[G UIDELINE ] A UPnP MediaServer shall use the <dlna:X_DLNACAP> element (as a child of the
<device> element that represents the MediaServer) in the device description document and use the
Capability IDs as indicated in Table 23 in the element's comma-separated value list to indicate
support for uploading a Media Class.

Table 23 – Capability IDs for AnyContainer support

Capability ID Description

audio-upload The UPnP AV MediaServer supports the upload AnyContainer operation

for the Audio Media Class.
image-upload The UPnP AV MediaServer supports the upload AnyContainer operation
for the image Media Class.
av-upload The UPnP AV MediaServer supports the upload AnyContainer operation
for the AV Media Class.
create-child-container The UPnP AV MediaServer supports the OCM: create child container
opperation.
create-item-with-OCM-destroy-item The UPnP AV MediaServer supports to create a CDS item with OCM:
destroy object capability for the upload AnyContainer operation. This
Capability ID shall coexist with at least one of audio-upload,
image-upload or av-upload.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC QLR9B

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DMS devices use the <dlna:X_DLNACAP> element to indicate support for the upload
AnyContainer operation. The element is a comma separated value list that indicates whether the
DMS can receive uploads of images, audio-only, or audio/video content.

A DMS that supports the upload AnyContainer operation is different from a DMS with an Upload
Controller. The former is a DMS that can receive uploaded content. The latter is a DMS that can
upload to a different DMS. It is possible to implement a DMS that supports the upload AnyContainer
operation and the Upload Controller capability.

A DMS that supports OCM: create child container need to also support the creation of child
containers where the DMS chooses the parent container (because the Upload Controller specified
DLNA.ORG_AnyContainer as the parent). This guideline explains how Upload Controllers
determine if OCM: create child container is supported for the DMS.

Guideline 9.2.35.1 gives the formal syntax of the <dlna:X_DLNACAP> element.

10.1.8.4.2
[G UIDELINE ] A UPnP AV MediaServer may implement the CDS:X_GetDLNAUploadProfiles action
to indicate the DLNA Media Format Profiles that it will accept in the CDS:CreateObject action.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 8BQBA

29341-20-12
ISO/IEC

DLNA guidelines; Part 1-1: Architecture and protocols

 – 305 –

29341-20-3

10.1.8.4.3
[G UIDELINE ] The CDS:X_GetDLNAUploadProfiles action's definition in the service description
shall be defined as indicated below.

<action>
<name>X_GetDLNAUploadProfiles</name>
<argumentList>
<argument>
<name>UploadProfiles</name>
<direction>in</direction>
<relatedStateVariable>
X_A_ARG_Type_UploadProfiles
</relatedStateVariable>
</argument>
<argument>
<name>SupportedUploadProfiles</name>
<direction>out</direction>
<relatedStateVariable>
X_A_ARG_Type_SupportedUploadProfiles
</relatedStateVariable>
</argument>
</argumentList>
</action>

The X_A_ARG_TYPE_UploadProfiles and X_A_ARG_Type_SupportedUploadProfiles state

variables are defined below.

<stateVariable sendEvents="no">
<name>X_A_ARG_Type_UploadProfiles</name>
<dataType>string</dataType>
</stateVariable>
<stateVariable sendEvents="no">
<name>X_A_ARG_Type_SupportedUploadProfiles</name>
<dataType>string</dataType>
</stateVariable>

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 39VIY

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The UploadProfiles input argument is an unordered, comma separated list of DLNA
Media Format Profile names.

The SupportedUploadProfiles output argument is an unordered, comma separated list of DLNA

Media Format Profile names, as described below:

• are listed in the UploadProfiles input argument and this MediaServer is willing to accept at the
action is invoked;

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 306 –

• or, in case of an empty UploadProfiles input argument, the SupportedUploadProfiles list will
contain the complete list of DLNA Media Format Profiles that this MediaServer is willing to
accept at the time the action is invoked.
The DLNA media profile IDs that appear in SupportedUploadProfiles shall comply with these
restrictions.

• Needs to be AV, Audio, or Image Media Classes.

• Media Format Profile IDs for icons, thumbnails and media collection files are expressly
prohibited.
The response behavior is summarized in the following way.

• If UploadProfiles is empty, then SupportedUploadProfiles contains a complete list of profiles

that the MediaServer is willing to accept at the current time. Control points specify an empty
value for UploadProfiles when they want to get a full list of profiles that the MediaServer will
accept for uploads.
• If UploadProfiles contains one or more profiles, then SupportedUploadProfiles contains the
subset of UploadProfiles that the MediaServer is willing to accept at the current time. Control
points specify one or more profiles for UploadProfiles when they are interested in uploading
specific formats to a MediaServer.
10.1.8.4.4
[G UIDELINE ] If a UPnP AV MediaServer does not accept upload of all the DLNA Media Format
Profiles that it lists in the CMS.SourceProtocolInfo state variable, then it shall implement the
CDS:X_GetDLNAUploadProfiles action to indicate the DLNA Media Format Profiles that it will
accept in the CDS:CreateObject action.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC N7IEV

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] A UPnP AV MediaServer does not need to implement the optional

CDS:X_GetDLNAUploadProfiles action if it supports the same set of DLNA Media Format Profiles
for upload and for content serving.

A UPnP AV MediaServer control point needs to realize that the presence of this action is the first
indicator that there are restrictions in the uploadable Media Format Profiles.

Some UPnP AV MediaServers implement CMS.SourceProtocolInfo to expose the profiles of the

currently available content instead of listing a fixed collection of profiles. In other words, at some
time this state variable can show 0 profiles and at a different time it can show N profiles. In this case
this guideline still applies. For this reason, it is good practice if a DMS that changes dynamically the
entries in CMS.SourceProtocolInfo implements the CDS.X_GetDLNAUploadProfiles to advertise
the set of uploadable profiles.

This guideline applies when a UPnP AV MediaServer does not accept the upload of a Media Class
(see guideline 10.1.8.4.1) but the CMS.SourceProtocolInfo state variable lists profiles in that Media
Class.

10.1.8.4.5
[G UIDELINE ] If a UPnP MediaServer supports the upload AnyContainer operation or OCM:create
child container, then it shall adhere to the following guidelines (10.1.8.4 through 10.1.8.4.4).

DLNA guidelines; Part 1-1: Architecture and protocols

 – 307 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 4R8S6

29341-20-12
ISO/IEC
29341-20-3

10.1.8.5 MM/CM: operations that need CDS:CreateObject

[G UIDELINE ] If a UPnP AV MediaServer supports one or more of these operations, then it shall
implement CDS:CreateObject, as follows:

• upload AnyContainer operation;

• OCM: upload content;
• OCM: create child container.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC RMUZ5

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The CDS:CreateObject action is used to create a CDS object that will represent the
uploaded content.

In addition to these guidelines, a DMS or M-DMS with the ability to receive uploaded content needs
to implement an HTTP server capable of processing HTTP POST requests, as described in
11.4.3.65 guidelines.

10.1.8.6 MM/CM: operations that need CDS:DestroyObject

[G UIDELINE ] If a UPnP AV MediaServer supports this operation, then it shall implement
CDS:DestroyObject.

• OCM: destroy object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC MUZ56

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The CDS:DestroyObject action is used for a variety of OCM operations related to
removing CDS objects from a DMS.

10.1.8.7 MM/CM: other CDS actions

[G UIDELINE ] A UPnP AV MediaServer may implement CDS:DeleteResource,
CDS:CreateReference, CDS:ImportResource, CDS:ExportResource, or
CDS:StopTransferResource.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 9VIYY

29341-20-12
ISO/IEC
29341-20-3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 308 –

[C OMMENT] These are normative UPnP AV CDS actions, but the DLNA guidelines do not define
interoperability rules for them.

10.1.8.8 MM/CM: baseline Media Formats

10.1.8.8.1
[G UIDELINE ] A UPnP AV MediaServer that belongs to the HND Device Category and implements
the upload AnyContainer operation for the DLNA A/V Media Class (as indicated by guideline
10.1.8.4.1) shall accept content uploads of at least one of the Mandatory Media Format Profiles for
each geographical region supported by the device.

A UPnP AV Media Server supports a geographical region when it is capable of exposing and
streaming content (mandatory profiles) per region according to guideline 6.1.2.2 (GUN VEJX7) of
IEC 62481-2.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC BQBAR

29341-20-12
ISO/IEC
29341-20-3
IEC 62481-2

[C OMMENT] DLNA guidelines for HND Device Classes have an expressed goal to facilitate
uploading of baseline media formats for exposing and rendering content. A DMS that only supports
uploads of optional media formats detracts from the guidelines' interoperability message.

For example, consider the case of a DMS that exposes and streams content (mandatory profiles) for
North America and Japan in the HND category. If this DMS implements the upload AnyContainer
operation, it needs to support upload for at least one mandatory profile in the North American region
and at least one mandatory profile in the Japanese region

10.1.8.8.2
[G UIDELINE ] A UPnP AV MediaServer that belongs to the MHD Device Category and implements
the upload AnyContainer operation for a DLNA Media Class (as indicated by guideline 10.1.8.4.1)
shall accept the uploading of content uploads of all the Mandatory Media Format Profiles for that
DLNA Media Class in the MHD Device Category.

[ATTRIBUTES ]

M A n/a M-DMS n/a ISO/IEC SR7JJ

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DLNA guidelines for MHD Device Classes have an expressed goal to facilitate
uploading of baseline media formats for exchanging content and exposing and rendering content.
An M-DMS that only supports uploads of optional media formats detracts from the guidelines'
interoperability message.

10.1.8.8.3
[G UIDELINE ] A UPnP AV MediaServer control point that belongs to one of the DLNA-defined
Device Categories and implements the upload AnyContainer operation for a DLNA Media Class
shall be able to upload content items of at least one of the mandatory DLNA Media Format Profiles
for that DLNA Media Class in its Device Category.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 309 –

Being able to upload a content item of a DLNA Media Format Profile means that, given a content
item of that DLNA Media Format Profile, the UPnP AV MediaServer control point shall be able to
issue the CDS:CreateObject request with the correct DLNA.ORG_PN parameter in the fourth field of
ProtocolInfo value of the <res> element to represent the DLNA Media Format Profile of the content
item (see 10.1.3.18).

[ATTRIBUTES ]

M A +UP+ n/a n/a ISO/IEC ZRERW

29341-20-12

10.1.8.8.4
[G UIDELINE ] A UPnP AV MediaServer that belongs to the DLNA-defined DMS Device Class and
implements the Content Synchronization Device Option (as indicated by 10.2.5.2) shall support the
upload of the mandatory DLNA Media Format Profiles in both the HND and MHD Device Categories
for the supported DLNA Media Classes.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC XLZ4X

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Facilitates the content synchronization process between MHD devices and HND
devices (e.g. DMS). The guideline is not applicable to M-DMS devices.

See IEC 62481-2, 6.2.

10.1.8.8.5
[G UIDELINE ] A UPnP AV MediaServer that belongs to the DLNA-defined M-DMS Device Class and
implements the Content Synchronization Device Option (as indicated by 10.2.5.2) shall support the
upload of the mandatory DLNA Media Format Profiles in only the MHD Device Categories for the
supported DLNA Media Classes.

[ATTRIBUTES ]

M A n/a M-DMS n/a ISO/IEC 8CGDS

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] MHD devices are only expected to Synchronize with other MHD devices.

See IEC 62481-2, 6.2.

10.1.8.8.6
[G UIDELINE ] A UPnP AV MediaServer that belongs to the HND Device Category and implements
the upload AnyContainer operation for the DLNA Image class (as indicated by guideline
Requirement 10.1.8.4.1) must accept content uploads of at least one Mandatory Media Format
Profile in that class..

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC NPJOF

29341-20-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 310 –

ISO/IEC
29341-20-3
IEC 62481-2

[C OMMENT] Currently there is only one Mandatory Media Format Profile defined in the Image class,
but this guideline will apply if that changes in the future.

10.1.8.8.7
[G UIDELINE ] A UPnP AV MediaServer that belongs to the HND Device Category and implements
the upload AnyContainer operation for the DLNA Audio Class (as indicated by guideline
Requirement 10.1.8.4.1) must accept content uploads of at least one Mandatory Media Format
Profile in that class..

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC ZOQNJ

29341-20-12
ISO/IEC
29341-20-3
IEC 62481-2

[C OMMENT] Currently there is only one Mandatory Media Format profile in the Audio Class, but
this guideline will apply if that changes in the future.

10.1.8.8.8
[G UIDELINE ] A UPnP AV Media Server that implements the upload AnyContainer operation (as
indicated by guideline Requirement 10.1.8.4.1) must expose and stream any content acquired using
the upload operation..

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC KJYGN

29341-20-12
ISO/IEC
29341-20-3
IEC 62481-2

[C OMMENT] This guideline clarifies the connection between upload operations and the act of
exposing and streaming content to the network. A UPnP AV MediaServer that acquires content
using an upload operation always exposes and streams the content to the network. This behavior
applies to devices in the HND and MHD categories.

10.1.8.9 MM/CM: indicating support for OCM operations

10.1.8.9.1
[G UIDELINE ] If a UPnP AV MediaServer supports one or more OCM operations, then the UPnP AV
MediaServer may have one or more CDS objects with the @dlna:dlnaManaged attribute.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC LR9BX

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The @dlna:dlnaManaged attribute indicates the OCM operations that the DMS or
M-DMS is able to support for a given CDS object.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 311 –

10.1.8.9.2
[G UIDELINE ] If a UPnP AV MediaServer supports one or more OCM operations on a CDS object,
then the UPnP AV MediaServer shall use the @dlna:dlnaManaged attribute to indicate support for
those OCM operations on a CDS object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC JW54B

29341-20-12
ISO/IEC
29341-20-3

10.1.8.9.3
[G UIDELINE ] If a CDS object allows one or more OCM operations, then the CDS object shall have
a @restricted value of "0".

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC XYXC6

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] For CDS objects that do not allow OCM operations, the @restricted attribute can have
a value of "0" or "1" to indicate that the object allows or disallows modifications through non-OCM
operations respectively.

10.1.8.9.4
[G UIDELINE ] The syntax definition for the value of @dlna:dlnaManaged attribute shall be as
follows:

• dlnaManaged-value = 8 hexdigit;
• hexdigit = <hexadecimal digit: "0"-"9", "A"-"F", "a"-"f">.
The @dlna:dlnaManaged attribute is a 32-bit unsigned integer encoded into exactly 8 hexadecimal
digits, with the following bit definitions. Bit-0 is the least significant bit. If a bit supports a particular
operation, then the bit value is true. Otherwise, the bit value is false to indicate the operation is not
supported (e.g. 00000000000000000000000000000001b = 0x00000001 where bit-0 is set to true).

Example:

• dlna:dlnaManaged="00000001"
The hexadecimal encoded form shall consist only of hexadecimal digits. The value shall omit the
"0x" string that often precedes hexadecimal notation.

• Bit-0: indicates support for OCM: upload content

– If true then the MediaServer allows a control point to create child CDS items in the container
for the OCM: upload content operation.
– Shall be false when used with a CDS item.
• Bit-1: indicates support for OCM: create child container
– If true on a CDS container, then the MediaServer allows a control point to create child CDS
containers that can support the OCM: upload content.
– Shall be false when used with a CDS item.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 312 –

• Bit-2: indicates support for OCM: destroy object operation

– If true then the MediaServer allows a control point to perform an OCM: destroy object
operation on the object.
• Bit-3: indicates support for OCM: upload content with OCM:destroy object operation capability
– If true on a CDS container, then the MediaServer allows a control point to create CDS items
for OCM:upload content operation that can support the OCM: destroy object.
– If true on a CDS container, then Bit-0 value on the CDS container shall be true.
– Shall be false when used with a CDS item.
• Bit 4: indicates support for OCM: change metadata operation
– If true then the MediaServer allows a control point to change, add or delete metadata on an
existing CDS Object.
• All other bits shall be false. All other bits are reserved for future use.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 93O8Z

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline defines the syntax for the @dlna:dlnaManaged value. This attribute
describes the DMS implementation's ability to support operations that affect the CDS object as a
whole.

A false value for a bit means that the DMS or M-DMS does not claim support for the described
operation. Control points are expected to honor the interpretation of these bits to maximize
interoperability because when invoking a CDS action that is related to an unsupported OCM
operation, this action is likely to receive respond with an error. CDS failure responses are not
mandatory when a DMS or M-DMS detects a deviation because vendors are permitted to use
normative CDS actions for vendor-defined operation.

There can be cases where a DMS (that is normally able to destroy the CDS item) is not able to
destroy a CDS item at the time of the request. For example, the actual content binary file might be
locked or a local management policy prevents the CDS item from being destroyed at the current
moment.

10.1.8.9.5
[G UIDELINE ] If the @restricted attribute is set to 1 all bits of the @dlna:dlnaManaged attribute shall
be false, that is, no OCM operations are allowed .

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC B73OL

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Enforce consistency between the @restricted and the @dlna:dlnaManaged attributes.

10.1.8.9.6
[G UIDELINE ] If a CDS object has “0” value for all hexadecimal digits in the @dlna:dlnaManaged
attribute, then UPnP AV MediaServer should omit the @dlna:dlnaManaged attribute of the CDS
object.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 313 –

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC YHXEF

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline provides guidance to UPnP AV MediaServer implementations to not

assign the @dlna:dlnaManaged=“00000000” attribute to a CDS object.

10.1.8.10 MM/CM: parallel upload AnyContainer and OCM operations

10.1.8.10.1
[G UIDELINE ] If a MediaServer control point attempts to do multiple upload AnyContainer or multiple
OCM operations in parallel, and if the MediaServer fails one or more of the parallel attempts, then
the MediaServer control point shall be able to perform the upload operations in a serialized manner.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 6X6HM

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] DMS devices are not required to support parallel attempts to upload or destroy content.
Control points that attempt to do so are responsible for retrying in a serialized manner in the event
of a failure. The exact user's process for retrying serialized uploads is a user interface issue and is
out of scope of this standard.

10.1.8.10.2
[G UIDELINE ] If a UPnP AV MediaServer supports the upload AnyContainer or other OCM
operations, then it shall be capable of performing at least one upload AnyContainer or OCM
operation at a time.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC N9C8F

29341-20-12
ISO/IEC
29341-20-3

10.1.8.11 MM/CM: Upload AnyContainer operation

10.1.8.11.1
[G UIDELINE ] If a UPnP AV MediaServer supports the upload AnyContainer operation, then it shall
allow control points to specify a "DLNA.ORG_AnyContainer" value for the ContainerID input
argument in a CDS:CreateObject request.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 4ZYSH

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The "DLNA.ORG_AnyContainer" allows an Upload Controller to upload content to a

UPnP AV MediaServer without having specific knowledge of where the content will be listed in the
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 314 –

CDS hierarchy.
Where the MediaServer creates the new object is dependent on the MediaServer implementation.

The "DLNA.ORG_AnyContainer" is a magic container ID which is used only in the request and a
container of this container ID does not actually exist.

A control point can attempt to deviate slightly from the restrictions listed in 10.1.8.11, but the result
can be an error. For example, if the Upload Controller tries to use
object.item.audioItem.audioBroadcast instead of object.item.audioItem, then the DMS can choose
to fail the request.

10.1.8.11.2
[G UIDELINE ] If a UPnP AV MediaServer supports the upload AnyContainer operation, then the @id
value for each container shall be a value that is not equal to "DLNA.ORG_AnyContainer".

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC LSFB4

29341-20-12
ISO/IEC
29341-20-3

10.1.8.11.3
[G UIDELINE ] If a UPnP AV MediaServer control point is going to start an upload AnyContainer
operation, then it shall invoke CDS:CreateObject with the following rules.

• The ContainerID input argument shall be "DLNA.ORG_AnyContainer".

• The Elements input argument shall specify a CDS item with a single <res> element that does not
have a URI value. The <res> element shall also conform to guideline 10.1.8.19. The <item>
element shall also have a <upnp:class> value, see Table 24, (or similarly derived value) that
corresponds to the Media Class of the content that is going to be uploaded.
Table 24 – Required Media Class UPnP values

Media Class Required UPnP:class value

Audio object.item.audioItem

Image object.item.imageItem

AV object.item.videoItem

[ATTRIBUTES ]

M A +UP+ n/a n/a ISO/IEC SFB47

29341-20-12
ISO/IEC
29341-20-3

10.1.8.11.4
[G UIDELINE ] If a UPnP AV MediaServer receives an upload AnyContainer request with a
<upnp:class> value that is derived from a supported base class value, then the DMS may change
the <upnp:class> value to the supported base class or to a similarly derived class, as indicated in
the Result output argument of the CDS:CreateObject.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 315 –

For example, if the request specifies object.item.audioItem.audioBroadcast, then the MediaServer

can change the value to object.item.audioItem. Likewise, if the request specified
object.item.imageItem, the MediaServer can change it to object.item.imageItem.photo.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC ZYSHA

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DMS devices are not required to support the full range of derived values for the
<upnp:class> element.

10.1.8.11.5
[G UIDELINE ] If a UPnP AV MediaServer returns a success response to an Upload Controller's
request to start an upload AnyContainer operation, then the MediaServer shall do the following.

• The DMS or M-DMS device shall determine an appropriate CDS container where the new CDS
object will be created.
• The MediaServer shall specify the object ID of the parent container as the <item> element's
@parentID attribute value, which is returned in the Result output argument.
• The <res> element (found in the Result output argument) that provides the res@importUri value
intended for the content transfer process shall comply with the guidelines in 10.1.8.19.2.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 9C8FT

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline describes the proper DMS or M-DMS behavior in a success scenario.
The DMS needs to use an appropriate DMS error in the case of a failure.

10.1.8.11.6
[G UIDELINE ] A UPnP AV MediaServer that supports the Upload AnyContainer operation shall be
capable of participating in a content transfer process, as described in guideline 10.1.8.26.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC X6HMR

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] These guidelines introduce the second step to the Upload AnyContainer operation.

10.1.8.11.7
[G UIDELINE ] A UPnP AV MediaServer control point that supports the Upload AnyContainer
operation shall be capable of participating in a content transfer process, as described in guidelines
10.1.8.26.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 316 –

[ATTRIBUTES ]

M A +UP+ n/a n/a ISO/IEC RGKUS

29341-20-12
ISO/IEC
29341-20-3

10.1.8.11.8
[G UIDELINE ] A UPnP AV MediaServer that creates a new CDS item in an upload AnyContainer
operation may create the CDS item in a CDS container with the @dlna:dlnaManaged attribute.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC 3O8ZS

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DMS or M-DMS devices can create the new CDS item in a CDS container that has the
@dlna:dlnaManaged attribute.

10.1.8.11.9
[G UIDELINE ] A UPnP AV MediaServer control point shall tolerate scenarios where the MediaServer
changes values to metadata properties specified in a CDS:CreateObject request.

Tolerate means that the UPnP AV MediaServer control point is able to complete the necessary
content transfer process (including the transfer of IFO files, if necessary) after creating the CDS
object.

[ATTRIBUTES ]

M C +UP+ n/a n/a ISO/IEC YXC6T

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The following are some examples of what a MediaServer is permitted to do.

• The @parentID changes from "DLNA.ORG_AnyContainer" to a different @parentID value.

• The <upnp:class> value changes to a derived class or to a base class of the current value.
• <dc:title>, <dc:creator>, and other string-based user-informational metadata properties are
truncated to fit the maximum length supported by the MediaServer.
10.1.8.11.10
[G UIDELINE ] A UPnP AV MediaServer that creates a new CDS item in an upload AnyContainer
operation may change metadata values to indicate the support or unsupported nature of OCM
operations.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC W54BN

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] MediaServers are permitted to change metadata values at any time. This behavior is
also permissible when the MediaServer actually creates the new CDS object.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 317 –

10.1.8.12 MM/CM OCM: Upload content operation

10.1.8.12.1
[G UIDELINE ] If a UPnP AV MediaServer supports the OCM: upload content operation on a CDS
container, then it shall specify one or more <upnp:createClass> elements to indicate the types of
CDS objects that can be created in the container. The values of these upnp:createClass elements
shall be equal to or derived from object.item.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC R9BXN

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline ensures that control points will know what type of CDS objects can be
created in the container.
For example, if a container supports the creation of image and audio-only objects, then it would use
a <upnp:createClass> element with object.item.imageItem and a <upnp:clreateClass> element with
object.item.audioItem.

The CDS container can have <upnp:createClass> that are derived from object.container, as
described in 10.1.8.13.

10.1.8.12.2
[G UIDELINE ] If a UPnP AV MediaServer control point is going to start an OCM: upload content
operation, then it shall invoke CDS:CreateObject with the following rules.

• The ContainerID input argument shall indicate a CDS container that supports the OCM: upload
content operation.
• The Elements input argument shall be a DIDL-Lite XML fragment that has a CDS item whose
<upnp:class> value matches one of the values in the set of <upnp:createClass> elements
associated with the CDS container identified by the ContainerID input argument. If the
upnp:createClass@includeDerived attribute has a value of "1", then the <upnp:class> value also
matches against the classes derived from the <upnp:createClass> value. The <item> element
shall also have a single <res> element that does not specify a URI value. The <res> element
shall also conform with guidelines in 10.1.8.19.
[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 QBARR

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] If a MediaServer supports the operation, Upload Controllers can choose to upload
content to specific CDS containers using the OCM: upload content operation.

A control point can attempt to deviate slightly from the restrictions listed in 10.1.8.12.2, but the
result can be an error. For example, if the Upload Controller tries to specify multiple <res> elements,
then the DMS can choose to fail the request.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 318 –

10.1.8.12.3
[G UIDELINE ] If a UPnP AV MediaServer responds with a success to a CDS:CreateObject request
for an OCM: upload content operation, then the created CDS item (as returned in the Result output
argument) shall comply with the following rules.

• The @parentID of the created CDS item shall match the request's specified ContainerID input
argument.
• The <res> element that provides the res@importUri value intended for the content transfer
process shall comply with the guidelines in 10.1.8.19.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VIYY4

29341-20-12
ISO/IEC
29341-20-3

10.1.8.12.4
[G UIDELINE ] A UPnP AV MediaServer that supports the OCM: upload content operation shall be
capable of participating in a content transfer process, as described in guideline 10.1.8.26.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC UZ56H

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] These guidelines introduce the second step to the OCM: content upload operation.

10.1.8.12.5
[G UIDELINE ] A UPnP AV MediaServer control point that supports the OCM: content upload
operation shall be capable of participating in a content transfer process, as described in guideline
10.1.8.26.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 Z56HE

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

10.1.8.12.6
[G UIDELINE ] A UPnP AV MediaServer that creates a new CDS item in an OCM: upload content
operation may change metadata values to indicate the support or unsupported nature of OCM
operations.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC IYY4H

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] For example, the DMS can automatically create the @dlna:dlnaManaged attribute or
change the @restricted value to indicate support for one or more OCM operations.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 319 –

10.1.8.13 MM/CM: OCM: Create child container operation

10.1.8.13.1
[G UIDELINE ] If a UPnP AV MediaServer supports the OCM: create child container operation on a
CDS container, then it shall specify one or more <upnp:createClass> elements to indicate the types
of CDS objects that can be created in the container.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC YY4H4

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline ensures that control points will know what type of CDS containers can
be created in an existing container.

Destroying containers is out of scope for this version of DLNA guidelines. DLNA assumes that DMS
have ownership of their CDS hierarchy, which includes the ability to remove containers through
out-of-band mechanisms.

10.1.8.13.2
[G UIDELINE ] If a UPnP AV MediaServer supports the OCM: create child container operation, then
it shall allow control points to specify a "DLNA.ORG_AnyContainer" value for the ContainerID input
argument in a CDS:CreateObject request.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 56HEF

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The "DLNA.ORG_AnyContainer" allows an Upload Controller to create a container on

a UPnP AV MediaServer without having specific knowledge of where the content will be listed in the
CDS hierarchy.

10.1.8.13.3
[G UIDELINE ] A UPnP AV MediaServer that supports OCM: create child container shall also
implement support for OCM: upload content.

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a BXNX4

10.1.8.13.4
[G UIDELINE ] If a UPnP AV MediaServer control point is going to start an OCM: create child
container operation, then it shall invoke CDS:CreateObject with the following rules.

• The ContainerID input argument shall indicate "DLNA.ORG_AnyContainer" or a CDS container

that supports the OCM: create child container operation.
• The Elements input argument shall be a CDS container whose <upnp:class> value matches one
of the values in the set of <upnp:createClass> elements associated with the CDS container
identified by the ContainerID input argument. If specifying "DLNA.ORG_AnyContainer" as the

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 320 –

value for the ContainerID input argument, then the value shall be object.container or a similarly
derived class.
• The Elements input argument shall include one or more <upnp:createClass> values that
describe the types of CDS objects that will be created in the new container. If specifying
"DLNA.ORG_AnyContainer" as the value for the ContainerID input argument, then the
corresponding <upnp:createClass> (or similarly derived values) shall be used, see Table 25.
Table 25 – Required UPnP createClass elements

Media Class Required upnp:class value

(for upnp:createClass elements)

Audio object.item.audioItem
Image object.item.imageItem
AV object.item.videoItem

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 9BXNX

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] If a MediaServer supports the operation, Upload Controllers can choose to create new
CDS containers that can receive uploaded content in an organized way.

The <upnp:createClass> values that are declared in the CDS:CreateObject request indicate the
types of media that the Upload Controller intends to upload into the new container.

The following conditions can cause the DMS to return an error because specific aspects of the
syntax are optional.

• The <upnp:class> value is derived from object.container. DMS can fail this request because
object.container is the only value that is mandatory.
• The <upnp:createClass> value is unsupported, even if it is derived from a supported type. DMS
can fail this request because only the upnp:createClass values listed in the table are mandatory.
• There is more than one <upnp:createClass> value in the request. DMS can fail this request
because only a single <upnp:createClass> is required.
10.1.8.13.5
[G UIDELINE ] A UPnP AV MediaServer may change a <upnp:createClass> or <upnp:class> value to
one of the supported base classes or one of the derived classes if the value is derived from that
base class.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 54BN6

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] For example, if the Upload Controller specified a <upnp:createClass> value of

object.item.imageItem.photo and a <upnp:class> value of object.container.album, then the DMS
can automatically change the values of those elements to object.item.imageItem and

DLNA guidelines; Part 1-1: Architecture and protocols

 – 321 –

object.container, respectively. Similarly, a DMS can change object.container to a derived value,

such as object.container.storageFolder.

Creating a container that has <upnp:createClass> values derived from object.container are out of
scope of this standard.

Guideline 10.1.8.25.3 instructs a DMS to return error code 712 if the specified value is not
acceptable to the DMS.

10.1.8.13.6
[G UIDELINE ] A UPnP AV MediaServer control point creates a new CDS container with intent to
follow up with an OCM: upload content operation the new container, then the control point shall
specify the @dlna:dlnaManaged attribute with bit-0 set to true.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 4BN6R

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] In conjunction with the <upnp:createClass> elements, this guideline ensures that a
DMS knows the intent of the Upload Controller to upload content to the new container.

10.1.8.13.7
[G UIDELINE ] A UPnP AV MediaServer that creates a new CDS container in an OCM: create child
container operation may change the @restricted and/or @dlna:dlnaManaged metadata values to
indicate the support or unsupported nature of OCM operations.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC XC6TY

29341-20-12
ISO/IEC
29341-20-3

10.1.8.13.8
[G UIDELINE ] If a UPnP AV MediaServer receives an OCM: create child container request and one
or more of the <upnp:createClass> values specified in the request are unsupported, then the
MediaServer shall return error code 712 (Bad Metadata).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC C6TY8

29341-20-12
ISO/IEC
29341-20-3

10.1.8.13.9
[G UIDELINE ] If a UPnP AV MediaServer responds with a success to a CDS:CreateObject request
for an OCM: create child container operation, then the created CDS container shall have the
@dlna:dlnaManaged attribute. Furthermore, the @parentID of the created CDS container (as
returned in the Result output argument) shall match the request's specified ContainerID input
argument.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 322 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC O8ZSQ

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The @dlna:dlnaManaged attribute is always present in a recursive manner. However,

the individual bits on the attribute value can have different true/false values.

Guideline 10.1.8.9.4 requires the created container to support the OCM:upload contents operation.

10.1.8.14 MM/CM: OCM: Destroy object operation

10.1.8.14.1
[G UIDELINE ] If a UPnP AV MediaServer control point is going to start an OCM: destroy object
operation, then it shall invoke CDS:DestroyObject with the following rules.

• The ObjectID input argument shall indicate a CDS object that supports the OCM: destroy object
operation.
• This ObjectID shall be for a CDS object that is to be removed from the CDS.
[ATTRIBUTES ]

M R +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 8ZSQB

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] The primary usage of this operation is to allow an Upload Controller or

Synchronization Controller to remove CDS objects from a MediaServer. A control point can make no
assumptions about whether any content files will actually be removed.

10.1.8.14.2
[G UIDELINE ] If a UPnP AV MediaServer responds with a success to a CDS:DestroyObject request
for an OCM: destroy object operation, then the DMS shall remove the CDS item indicated by the
request's ObjectID input argument. A MediaServer that cannot remove the indicated CDS item from
the CDS hierarchy shall return a SOAP error response.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 6HMRW

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DLNA does not specify any mandatory behavior for whether or not actual content
binaries are removed from the local storage of the DMS. The primary expectation of this guideline is
that the destroyed CDS item no longer appears in the CDS hierarchy.

10.1.8.14.3
[G UIDELINE ] If a UPnP AV MediaServer supports the OCM:destroy object Operation and the
control point invokes CDS:DestroyObject on a container where the container and all of its
descendent objects have bit 2 of the @dlna.dlnaManaged attribute true, then the container and all
of its descendent objects are removed.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 323 –

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC GAMUR

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Bit 2 of the @dlna.dlnaManaged attribute is the bit that defines whether the OCM:
destroy object operation is allowed on an object. This guideline makes OCM:destroy object
operation recursive on containers. Any object that has bit 2 of the @dlna.dlnaManaged attribute true,
will have the @restricted property set to "0".

10.1.8.14.4
[G UIDELINE ] If a UPnP AV MediaServer supports the OCM: destroy object Operation and a control
point invokes CDS:DestroyObject on a container with bit 2 of the @dlna.dlnaManaged attribute true
and where any of that container's descendant objects have bit 2 of the @dlna.dlnaManaged
attribute false then the following shall occur.

a) The UPnP AV Media Server shall destroy all descendent objects that have bit 2 of the
@dlna.dlnaManaged attribute true, except those preserved by c).
b) The UPnP AV Media Server shall not destroy an object that has bit 2 of the @dlna.dlnaManaged
attribute false.
c) The UPnP AV Media Server shall not destroy any ancestor containers of an object from b) even
if those ancestor containers have bit 2 of the @dlna.dlnaManaged attribute true.
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC ZV8WT

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] If an object exists within the subtree to be deleted that has bit 2 of the
@dlna.dlnaManaged attribute false, it cannot be deleted. In order to preserve the containers
between the root of the subtree and that object, all of the containers leading from the root to that
object will be retained. Those containers leading from the root of the subtree to that object are the
ancestor containers of that object.

10.1.8.14.5
[G UIDELINE ] If a server encounters objects within the subtree that cannot be deleted because they
have bit 2 of the @dlna.dlnaManaged attribute false, the server shall return a success response to
a call of the CDS:DestroyObject that was initiated by the OCM: destroy object operation and SHALL
behave according to 10.1.8.14.4.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 29341-20-12 5BVYZ

ISO/IEC 29341-20-3

[C OMMENT] The return of success is required by UPnP AV, the control point will need to perform a
CDS:Browse() operation to determine if the entire subtree was deleted.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 324 –

10.1.8.14.6
[G UIDELINE ] A control point shall not invoke a OCM: destroy object on an object if a bit 2 of the
@dlna.dlnaManaged attribute is false for that object.

[ATTRIBUTES ]

M R +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 AMURA

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

10.1.8.15 MM/CM: Use of valid values

[G UIDELINE ] A UPnP AV MediaServer control point shall always specify values for XML attributes
and elements in a manner that conforms with the XML attribute's or element's schema.

[ATTRIBUTES ]

M C +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 C8FTM

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] This is a general rule that applies whenever a control point creates or changes a
metadata property.

10.1.8.16 M/CM: General use of 7xx error codes

[G UIDELINE ] If a UPnP AV MediaServer responds to a CDS:CreateObject or CDS:UpdateObject
request with a UPnP AV error code in the 700 to 799 range, then the UPnP AV MediaServer may use
a localized, human-readable error message in the errorDescription tag of the SOAP response.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC HMRW8

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The ContentDirectory service specification does not provide adequate granularity for
many error scenarios. This guideline allows DMS or M-DMS vendors to provide an error message
that can be used by a user for error recovery and/or troubleshooting.

10.1.8.17 MM/CM: general use of error code 720

[G UIDELINE ] Unless a different error code is mandatory, if a UPnP AV MediaServer receives a CDS
action request for a particular upload AnyContainer or any OCM operation that is not supported or
invalid, then the UPnP AV MediaServer may return a UPnP error code of 720 (Cannot process the
request). The errorDescription tag in the SOAP response may contain a localized, human-readable
error message.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 8FTMQ

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The ContentDirectory service specification does not provide adequate granularity for
many error scenarios. As a workaround, DLNA allows implementations to return the error code 720

DLNA guidelines; Part 1-1: Architecture and protocols

 – 325 –

with a detailed error message. This error message can be used by a consumer for error recovery
and/or troubleshooting.

10.1.8.18 MM/CM: invalid 4th field parameters

[G UIDELINE ] A UPnP AV MediaServer that receives a CDS:CreateObject that conflicts with the
guideline in 10.1.3.13.14 may return a UPnP AV error code 712 (Bad Metadata) or it may return a
success response and change the conflicting flag to an appropriate value.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC YSHAB

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] In content upload usages, the DMS (not the Upload Controller) determines the
transport layer options.

10.1.8.19 MM/CM: general rule for creating <res> elements: Content Transfer process
10.1.8.19.1
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject and specifies the
creation of a <res> element that omits a URI value, then the control point shall specify a <res>
element that conforms to the following rules.

• The first field of the res@protocolInfo value shall be "*".

• The second field of the res@protocolInfo value shall be "*".
• The third field of the res@protocolInfo value shall be a valid DLNA mime-type that correlates
with the DLNA.ORG_PN value in the fourth field.
• The fourth field of the res@protocolInfo value shall have the DLNA.ORG_PN parameter and
value. The value shall identify the DLNA Media Format Profile of the content binary that will be
used in the content transfer process.
The fourth field of the res@protocolInfo value shall omit 4th field parameters defined by the DLNA
guidelines, other than the required DLNA.ORG_PN and permitted DLNA.ORG_CI and other-param.

The <res> element shall omit the res@importUri attribute.

[ATTRIBUTES ]

M C +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 FB477

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] A control point that specifies a <res> element without a URI value indicates that it
wants to upload content to the MediaServer. A control point can deviate from the restrictions
described in this guideline, but the result might be an error. For example, if the control point does
not specify a DLNA.ORG_PN parameter, then the MediaServer can return an error.

10.1.8.19.2
[G UIDELINE ] If a UPnP AV MediaServer creates a <res> element as a result of a CDS:CreateObject
and the <res> element specified in the CDS request omits a URI value, then the created <res>
element shall comply with the following rules.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 326 –

• The <res> element shall omit a URI value.

• The <res> element shall have a res@importUri attribute and value. The res@importUri value
shall indicate a URI that supports a content-transfer process. The length of the URI shall be less
than or equal to 1 024 B.
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC B4773

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] If a MediaServer creates a <res> element intended to receive uploaded content, then
it needs to provide a res@importUri attribute and value. This URI tells an Upload Controller which
URI to perform an HTTP POST operation.

The value of the <res> element needs to be empty until the content is actually available for serving
as described in 10.1.8.27.4.

See 10.1.3.27.3 (GUN QQ6YX) for information on handling other-param.

It is permissible for the UPnP AV MediaServer to ignore or preserve a DLNA.ORG_CI and

other-param parameters in the 4th field of the res@protocolInfo if the request specifies it

10.1.8.19.3
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject and specifies the
creation of a <res> element without a URI value and the content is profiled as MPEG_PS_NTSC or
MPEG_PS_PAL and it has discontinuous SCR and/or PTS, then the MediaServer control point shall
specify a res@dlna:ifoFileURI attribute with an empty value.

The prefix for res@dlna:ifoFileURI shall be "dlna:" and the namespace shall be
"urn:schemas-dlna-org:metadata-1-0/".

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 4773Q

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] Upload Controllers might need to upload an IFO file. Providing an empty
res@dlna:ifoFileURI signals the MediaServer to provide a URI value for it. In many cases, the
MediaServer will include the res@dlna:importIfoFileURI attribute in the CDS:CreateObject
response to indicate that the MediaServer will receive the IFO file. Upload Controllers then perform
a content transfer process to this URI in the same manner as a res@importUri.

10.1.8.19.4
[G UIDELINE ] If a UPnP AV MediaServer creates a <res> element in response to a
CDS:CreateObject request that has a res@dlna:ifoFileURI attribute with an empty value, then the
UPnP AV MediaServer shall do one of the following to make the response.

• Preserve the res@dlna:ifoFileURI attribute with an empty value and add the
res@dlna:importIfoFileURI attribute with a URI value that supports the content transfer process
for the IFO file associated with the content binary. (Note that if a MediaServer implements this
behavior, the MediaServer is permitted to generate a new content binary without discontinuities
and generate a new IFO file for the new content binary. Similarly, a MediaServer is permitted to
expose the uploaded content binary without modifications and generate a new IFO file.)
DLNA guidelines; Part 1-1: Architecture and protocols
 – 327 –

• Omit the res@dlna:ifoFileURI attribute and add the res@dlna:importIfoFileURI attribute with a
URI value that supports the content transfer process for the IFO file associated with the content
binary to indicate that the MediaServer will automatically generate an equivalent content binary
without discontinuities after receiving both the IFO file and the content binary.
• Preserve the res@dlna:ifoFileURI attribute with an empty value and omit the
res@dlna:importIfoFileURI attribute to indicate that the MediaServer will automatically create an
IFO file (and expose it through the res@dlna:ifoFileURI) after a successful content transfer
process on the res@importUri.
• Omit the res@dlna:ifoFileURI attribute and omit the res@dlna:importIfoFileURI attribute to
indicate that the MediaServer will automatically generate an equivalent content binary without
discontinuities after a successful content transfer process on the res@importUri.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC HABYL

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] If a UPnP AV MediaServer will expose an IFO file, the res@dlna:ifoFileURI attribute
remains an empty value until the MediaServer is ready to serve the IFO file, such as described in
10.1.8.27.7. If a CDS object has a <res> URI value for discontinuous SCR and/or PTS MPEG2, then
URI values for <res> and res@dlna:ifoFileURI will be provided after the content transfer process.
Ideally, both URIs are provided within 30 s of completing the content transfer process of the content
binary, but some implementations can take longer (e.g. MediaServer performs validation or
post-processing on the uploaded content binary.)

10.1.8.19.5
[G UIDELINE ] If a UPnP AV MediaServer provides res@dlna:importIfoFileURI and a control point
has intention to transmit a MPEG_PS_NTSC/PAL content and an associated IFO file to the
MediaServer, then the control point shall completely transmit the IFO file before sending the
MPEG_PS_NTSC/PAL content.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 FTMQ2

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] In the typical case, MediaServer uses the IFO file before receiving the content data to
check its data size and boundary information in it.

10.1.8.19.6
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject and specifies the
creation of a <res> element without a URI value, then the MediaServer control point should specify
res@size attribute with a value equal to the byte length or equal to an estimated byte length of the
content that will be sent during the content transfer process.

[ATTRIBUTES ]

S A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 MRW8N

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 328 –

[C OMMENT] This allows a DMS or M-DMS to know how large the uploaded content will be and gives
it the opportunity to reserve local storage space for the content.

d) The size of the content binary that is sent during the content transfer process can be different
from the res@size value. For example, an Upload Controller can upload a content binary that is
actually a conversion from another media format. In such a scenario, it can be very difficult to
anticipate the exact size, so the Upload Controller specifies a res@size value that is a bit larger
than the estimated size. During the content transfer process, the DMS will be able to determine
the correct size of the content.
10.1.8.19.7
[G UIDELINE ] If a UPnP AV MediaServer successfully completes a content transfer processs for the
<res> element (and if res@size is present), then the MediaServer shall correct the res@size value
to match the length of the content binary, if the indicated value does not match the byte length of the
uploaded content binary.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 6TY85

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline specifies that once content has been uploaded and the DMS or M-DMS
can serve the content to other endpoints, the res@size value needs to be accurate. Estimated
values will cause problems for Rendering Endpoints that rely on that metadata.

10.1.8.19.8
[G UIDELINE ] If a UPnP AV Media Server which supports the upload AnyContainer operation or
OCM: upload content operation for a content item profiled as MPEG_PS_NTSC/PAL receives a
CDS:CreateObject request, it shall be able to accept the request regardless of whether it contains
the res@dlna:ifoFileURI attribute.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC BN6RG

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The UPnP AV Media Server can fail the CDS:CreateObject for normal exceptions such
as unavailable resources

10.1.8.19.9
[G UIDELINE ] If a UPnP AV MediaServer creates a <res> element in response to a
CDS:CreateObject request that omits the res@dlna:ifoFileURI attribute, then the UPnP AV
MediaServer shall omit the res@dlna:importIfoFileURI attribute to indicate that the MediaServer is
not expecting a content transfer process for an IFO file.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC XNX4I

29341-20-12
ISO/IEC

DLNA guidelines; Part 1-1: Architecture and protocols

 – 329 –

29341-20-3

[C OMMENT] An IFO file can contain metadata not related to SCR and/or PTS discontinuities. A
UPnP AV MediaServer can create an IFO file and expose it as described in 10.1.4.9. The
MediaServer's response can also omit the res@dlna:ifoFileURI attribute.

10.1.8.20 MM/CM: general rule for creating <res> elements: Resume Content Transfer
process
10.1.8.20.1
[G UIDELINE ] A UPnP AV MediaServer control point may support the resume content transfer
operation. MediaServer control points may also make multiple resume content transfer operations.

The resume content transfer operation is a retry attempt for a failed content transfer process such
that the content transfer starts from the point of transfer failure from a previous attempt.

[ATTRIBUTES ]

O A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 Y4H43

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] This guideline specifies that Upload Controllers and Upload Synchronization
Controllers are not required to support the ability to retry or resume a failed content transfer.

e) The DLNA guidelines provide interoperability rules for resume content transfer. The DLNA
guidelines do not provide any normative mechanism for a retry attempt such that the content
transfer process retries from the beginning of the content binary.
10.1.8.20.2
[G UIDELINE ] If resume content transfer is supported, then retry IFO attempt shall also be
supported.

For MediaServers, this means that returning a CDS:CreateObject response that has
res@dlna:resumeUpload="1" shall mean that resume content transfer and retry IFO attempt are
supported.

For MediaServer control point, this means that issuing a CDS:CreateObject request with
res@dlna:resumeUpload="1" shall mean the MediaServer control point is capable of using resume
content transfer and retry IFO attempt if an error occurs during the transmission of the content
binary or IFO file.

A retry IFO attempt is defined as a retry attempt for a failed content transfer process attempt for an
IFO file, such that the transfer begins from byte index 0 of the IFO file and the correspond HTTP
POST request omits the CONTENT-Range HTTP header.

[ATTRIBUTES ]

M A DMS +UP+ M-DMS n/a ISO/IEC 29341-20-12 6HEFW

+UPSYNC+ ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 330 –

10.1.8.20.3
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject and wants to
create a <res> element that supports the resume content transfer operation, then it shall specify a
res@dlna:resumeUpload attribute with "1" value in a call to CDS:CreateObject.

The prefix for res@dlna:resumeUpload shall be "dlna:" and the namespace shall be
"urn:schemas-dlna-org:metadata-1-0/".

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 4H438

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] Upload and Upload Synchronization Controllers create <res> elements with a
res@dlna:resumeUpload="1" to determine if the MediaServer supports the resume content transfer
operation. These Controllers will not specify res@dlna:resumeUpload="1" unless they intend to
recover from a failed content transfer process by using the CONTENT-Range HTTP header in an
HTTP POST request (i.e. using resume content transfer). The only other normative recovery
mechanism for failed content uploads is to restart from a new upload AnyContainer or OCM: upload
content operation.

10.1.8.20.4
[G UIDELINE ] If a UPnP AV MediaServer creates a new <res> element as a result of a
CDS:CreateObject request that specified the res@dlna:resumeUpload attribute with a value of "1"
and if the MediaServer supports the resume content transfer operation for the created item, then the
MediaServer shall preserve the value "1" for the res@dlna:resumeUpload attribute.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC HEFWQ

29341-20-12
ISO/IEC
29341-20-3

10.1.8.20.5
[G UIDELINE ] If the MediaServer creates the <res> element, it will confirm the support of the resume
content transfer operation by preserving the res@dlna:resumeUpload="1" attribute and value.

A MediaServer respond res@dlna:resumeUpload="1" should keep 30 min the object when upload
has failed.

If a UPnP AV MediaServer receives a CDS:CreateObject that specifies

res@dlna:resumeUpload="0" or omits res@dlna:resumeUpload, then the MediaServer's
CDS:CreateObject response shall specify res@dlna:resumeUpload="0" or omit
res@dlna:resumeUpload.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC EFWQZ

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] MediaServers will never enable resume content transfer unless the Control Point
requests that the feature apply to the upload operation because a control point can intentionally
DLNA guidelines; Part 1-1: Architecture and protocols
 – 331 –

choose to rely on the required Auto-Destroy behavior when resume content transfer is not
supported.

f) See 10.1.8.28.2 (MM/CM: Auto-Destroy Behavior for a Failed or Partial Content Transfer
Process) for more information on MediaServer behavior when resume content transfer is not
supported.
10.1.8.20.6
[G UIDELINE ] If a UPnP AV MediaServer creates a new <res> element as a result of a
CDS:CreateObject request that specified the res@dlna:resumeUpload attribute with a value of "1"
and if the MediaServer cannot support the resume content transfer operation for the created item,
then the MediaServer shall do one of the following:

• set the res@dlna:resumeUpload attribute to "0" in the created <res> element;

• omit the res@dlna:resumeUpload attribute in the created <res> element.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC H4382

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DMS implementations that do not support the resume content transfer operation will
specify a value of "0" or omit the res@dlna:resumeUpload attribute to inform Upload and Upload
Synchronization Controllers that the operation is not supported.

10.1.8.20.7
[G UIDELINE ] If a UPnP AV MediaServer control point attempts to recover from a failed content
transfer process and both of the following conditions are true, then the Upload Controller or Upload
Synchronization Controller shall use the resume content transfer operation as the initial recovery
attempt.

• MediaServer control point specified res@dlna:resumeUpload="1" in a CDS request.

• MediaServer preserved res@dlna:resumeUpload="1" in the CDS response that created the
<res> element.
[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 OS33F

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] An Upload or Upload Synchronization Controller that specifies

res@dlna:resumeUpload="1" will use an HTTP POST request with the CONTENT-Range HTTP
header whenever possible. As a fallback, a Control Point is permitted to restart the upload process
by restarting with an OCM: upload content operation. Some example scenarios using the fallback
process are listed here.

• The CDS object or <res> element no longer exists on the DMS (e.g. the suspend period is too
long).
• The resume content transfer attempt has failed for some reason. In this case, a Control Point
can use an OCM: destroy object operation before restarting with an OCM: upload content
operation.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 332 –

10.1.8.20.8
[G UIDELINE ] If a UPnP AV MediaServer control point attempts to recover from a failed content
transfer process and at least one of the conditions are true, then the Control Point may attempt the
recovery by starting over with an upload AnyContainer or OCM: upload content operation and follow
up with a new content transfer process.

• MediaServer control point did not specify res@dlna:resumeUpload="1" in the CDS request that
created the <res> element.
• MediaServer control point received a CDS response with res@dlna:resumeUpload=0 or
response omits res@dlna:resumeUpload attribute from the created <res> element.
[ATTRIBUTES ]

O A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 ROS33

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] Usually the res@dlna:uploadedSize is omitted, but it is not mandatory because it can
simplify the MediaServer implementation. There is no normative use for this property in such
scenarios.

10.1.8.21 MM res@dlna:uploadedSize
10.1.8.21.1
[G UIDELINE ] If a UPnP AV MediaServer supports the resume content transfer operation for a <res>
element, then the <res> element shall have a res@dlna:uploadedSize attribute which has the same
syntax and type as the res@size attribute.

The value of res@dlna:uploadedSize is the byte length of the content binary (not including the size
of an uploaded IFO file) that was received during a content transfer process that failed.

The prefix for res@dlna:uploadedSize shall be "dlna" and the namespace shall be
"urn:schemas-dlna-org:metadata-1-0/".

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC X4IVO

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] An Upload Controller can perform a resume content transfer by using an HTTP POST
request with the CONTENT-Range header.

g) The res@dlna:uploadedSize does not represent the number of bytes that have been uploaded
for an IFO file.
10.1.8.21.2
[G UIDELINE ] If a UPnP AV MediaServer does not support the resume content transfer operation for
a <res> element, then it may omit the res@dlna:uploadedSize attribute.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC NX4IV

29341-20-12
ISO/IEC
29341-20-3
DLNA guidelines; Part 1-1: Architecture and protocols
 – 333 –

[C OMMENT] Usually the res@dlna:uploadedSize is omitted, but it is not mandatory because it can
simplify the MediaServer implementation. There is no normative use for this property in such
scenarios.

10.1.8.22 MM/CM: General rules for <res> elements

10.1.8.22.1
[G UIDELINE ] If a UPnP AV MediaServer creates a CDS object with a upnp:class value that is not
equal to object.item.epgItem, object.item.video.videoBroadcast, object.item.audio.audioBroadcast,
or any of their derived classes, then it shall have at least one of the following URI values for each
<res> element.

• URI value for the <res> element.

• URI value for the res@importUri attribute.
[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC 6RGWV

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] If both URI values are present, then the DMS indicates that uploading endpoints can
overwrite the binary for a specific <res> element.

This guideline does not apply to CDS objects that represent EPG items or channel items, as these
items can be available for streaming only at designated times, or might never be available for
streaming at all.

10.1.8.22.2
[G UIDELINE ] If a UPnP AV MediaServer creates a <res> element in response to a
CDS:CreateObject, then the created <res> element may change the set of metadata attributes that
were specified in the request.

[ATTRIBUTES ]

O L DMS M-DMS n/a ISO/IEC N6RGW

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline allows a control point to create <res> elements without knowledge of
attributes supported by the MediaServer.

For example, a control point can specify a new <res> element with the res@size attribute but the
created <res> element can omit res@size because the attribute is not supported.

Another example is, when the DMS creates a <res> element that omits the res@dlna:ifoFileURI
attribute when the request originally specified one. In this situation, the DMS created the <res>
element because the DMS will create and serve an IFO file after it receives the movie file or the DMS
will modify the movie file so that it does not have any discontinuities.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 334 –

10.1.8.22.3
[G UIDELINE ] If a <res> element of a CDS object with a upnp:class value that is equal to
object.item.epgItem, object.item.video.videoBroadcast, object.item.audio.audioBroadcast, or any
of their derived classes is not available for streaming, then a UPnP AV MediaServer shall omit the
URI value from the <res> element.element.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 8YMDF

29341-20-12

[C OMMENT] In certain systems, a piece of content is available only at designated times. The URI
pointing to the content will also only be valid at the designated times. This guideline specifies that a
DMS will not expose the URI when the content is not available.

10.1.8.22.4
[G UIDELINE ] If a <res> element of a CDS object with a upnp:class value that is equal to
object.item.epgItem, object.item.video.videoBroadcast, object.item.audio.audioBroadcast, or any
of their derived classes is available for streaming, then a UPnP AV MediaServer shall include the
URI value in the <res> element.element.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VIUA9

29341-20-12

[C OMMENT] In certain systems, a piece of content is available only at designated times. The URI
pointing to the content will also only be valid at the designated times. This guideline specifies that a
DMS will expose the URI when the content becomes available.

10.1.8.23 MM/CM: General rules for CDS:CreateObject request syntax

10.1.8.23.1
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject, then it shall apply
the mandatory metadata encoding rules for the following guidelines in the Elements input argument.

• 10.1.3.1 MM UPnP AV control point tolerance of unknown property

• 10.1.3.2 MM DIDL-Lite restrictions
• 10.1.3.3 MM DIDL-Lite max metadata length
• 10.1.3.5 MM DIDL-Lite Boolean values
• 10.1.3.6 MM upnp:class values
• 10.1.3.7 MM DIDL-Lite dc:date format
• 10.1.3.9 MM DIDL-Lite desc element use
• 10.1.3.10 MM URI rules
• 10.1.3.12 MM DIDL-Lite recommended metadata properties
• 10.1.3.13 MM protocolInfo context
• 10.1.3.16 MM DIDL-Lite protocolInfo values
• 10.1.3.17 MM protocolInfo values: 4th field
• 10.1.3.18 MM pn-param (DLNA.ORG_PN parameter)
• 10.1.3.23 MM ci-param (conversion indicator flag)
DLNA guidelines; Part 1-1: Architecture and protocols
 – 335 –

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 Y855L

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] This guideline specifies that control points honor basic metadata restrictions that
govern CDS metadata.

10.1.8.23.2
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject, then it shall apply
the rules specified in 10.1.3.4.2 (in MM DIDL-Lite Non-empty Metadata Values) to all metadata,
except the <res> element and @id attribute.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 TY855

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] The <res> element in a CDS:CreateObject is exempt from the non-empty value
conventions because Upload Controllers do not specify the <res> URI value for some tasks, such as
the upload AnyContainer or OCM: upload content operations.

10.1.8.23.3
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject, then it shall
adhere to the following rules when specifying the Elements input argument.

• The XML shall exclude the <?xml> declarator and use UTF-8 encoding.
• The <DIDL-Lite> element shall be the top-most element.
• The <DIDL-Lite> element shall have a single <item> or a single <container> child element.
• At minimum, the <item> or <container> element shall specify the @id, @parentID, @restricted,
dc:title, and upnp:class metadata properties.
• The @id value shall be an empty string ("").
• The @parentID value shall match the ContainerID input argument.
• The @restricted value shall be "0".
• The dc:title value shall comply with all DLNA-specified metadata restrictions.
Example request:

CDS:CreateObject("10","<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite"> <item id="" restricted="0"
parentID="10"> <dc:title>A picture in the park</dc:title>
<upnp:class>object.item.imageItem</upnp:class> <res
protocolInfo="*:*:image/jpeg:DLNA.ORG_PN=JPG_LRG"></res> </item> </DIDL-Lite>")

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 QBLX4

ISO/IEC 29341-14-12
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 336 –

ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] This guideline specifies the baseline requirements for the metadata specified in a
CDS:CreateObject request.

h) Control Points need to be aware that the created object can have metadata that is slightly
different from what is sent. For example:
The @id value of the new object will be set.
The @parentID of the new object will be set (in the case where DLNA.ORG_AnyContainer is
used).
Informative metadata, such as dc:title and dc:creator, can be truncated.
The @restricted value can be changed.
The returned object can include @dlna:dlnaManaged attribute.
upnp:class or upnp:createClass values can be changed to a derived or a base class value for
audio, image, audio/video, and container objects.
10.1.8.23.4
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject, then it should
provide all metadata defined in 10.1.3.10.6 for the given upnp:class.

[ATTRIBUTES ]

S C +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 SQBLX

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] Control Points are encouraged to provide recommended metadata, because they are
useful for a user. If the MediaServer does not support the specified metadata, the
CDS:CreateObject response will omit the unsupported metadata, as described in this guideline.

10.1.8.23.5
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject, then it may
specify additional metadata properties in a call to CDS:CreateObject, than those specified in
10.1.8.23.3.

[ATTRIBUTES ]

O R +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 ERZ5I

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT]

a) Control Points are allowed to specify more than just the minimal metadata.
b) Control Points are expected to handle a possible outcome described in 10.1.8.24.3.
10.1.8.23.6
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject with optional
metadata, then the control point shall ensure that all necessary namespaces are properly declared.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 337 –

[ATTRIBUTES ]

M R +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 SERZ5

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

10.1.8.23.7
[G UIDELINE ] A UPnP AV MediaServer that allows the creation of <dc:date> elements shall allow
the control point to specify any valid form of <dc:date>, as defined by 10.1.3.7.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC W8N9T

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline allows the control point to specify any valid form for <dc:date>. Control
points are not to assume that the format they specified in the request will be the final form of the
<dc:date>.

10.1.8.23.8
[G UIDELINE ] A UPnP AV MediaServer that allows the creation of <dc:date> elements may change
the form of the <dc:date> value to match any valid form, as defined by 10.1.3.7.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC RW8N9

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline allows MediaServers the flexibility of using a consistent <dc:date> form
for all of their CDS objects.

10.1.8.23.9
[G UIDELINE ] If a UPnP AV MediaServer control point invokes CDS:CreateObject and the created
object needs to support one or more OCM operations, then the MediaServer control point should
specify the appropriate value for the @dlna:dlnaManaged attribute in the request.

[ATTRIBUTES ]

S A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 MQ22G

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] For example, if a Control Point requires a created container to support the OCM:
upload content operation, then the control point needs to specify a CDS container that supports the
OCM: upload content operation in the CDS:CreateObject request by specifying the
@dlna:dlnaManaged attribute with the appropriate bits set.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 338 –

10.1.8.24 MM/CM: general rules for CDS:CreateObject response syntax

10.1.8.24.1
[G UIDELINE ] If a UPnP AV MediaServer that implements CDS:CreateObject, then it shall be able to
support a request that specifies the properties specified in 10.1.8.23.3.

Example response:

CDS:CreateObject("12","<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"> <item id="12" parentID="10"
restricted="0"> <dc:title>A picture in the park</dc:title> <res
importUri="http:/192.168.1.1/item?id=12"
protocolInfo="*:*:image/jpeg:DLNA.ORG_PN=JPEG_LRG""/>
<upnp:class>object.item.imageItem</upnp:class> <upnp:album>Photo
Folder1</upnp:album> </item> </DIDL-Lite>")

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC BYLU6

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] A UPnP AV MediaServer is not required to support the creation of container objects. In
such cases, the proper behavior is to return UPnP error code 712, as described in guideline
10.1.8.23.2.

10.1.8.24.2
[G UIDELINE ] If a UPnP AV MediaServer implements CDS:CreateObject, then it should accept the
creation of recommended properties corresponding to the specified upnp:class, which are defined
in the guideline 10.1.3.10.6

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC TMQ22

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Although not required, metadata such as dc:creator and upnp:album can be useful to
a user.

10.1.8.24.3
[G UIDELINE ] If a UPnP AV MediaServer creates a new CDS object in response to a
CDS:CreateObject request (that conforms to DLNA guidelines) and the request specifies metadata
properties that are unsupported by the MediaServer, then the MediaServer shall return a success
response with the Result output that includes the metadata supported by the MediaServer.

Furthermore, if the MediaServer is able to return a success for a CDS:CreateObject request that
specifies only the baseline metadata properties, then it shall also return a success for a
CDS:CreateObject request that specifies the same baseline metadata properties and values with
additional optional metadata properties.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC ABYLU

DLNA guidelines; Part 1-1: Architecture and protocols

 – 339 –

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The general approach for CDS:CreateObject is that a DMS tolerate the presence of
optional metadata properties (XML elements and attributes). The tolerance requirement also
extends to 4th field parameters of protocolInfo, as required by 10.1.3.27.3 (MM other-param
(Vendor-defined 4th field Parameters)).

i) The general exception to this approach is that a DMS is not required to tolerate <upnp:class> or
<upnp:createClass> values that are unacceptable to a DMS. The primary reason for this
exception is that derived classes can often imply a semantic difference. For example
object.item.audioItem.audioBroadcast is not equivalent to an object.item.audioItem because the
former implies that the stream is live. It is permissible for a DMS to tolerate a diversity of
<upnp:createClass> and <upnp:class> values by automatically changing the specified values,
but such behavior is not required.
j) A UPnP AV MediaServer that returns unsupported metadata in the Result but responds to
CDS:Search and CDS:Browse without that metadata is behaving inconsistently. Returning with
an error makes it difficult for control points to provide an information-rich experience. For this
reason, DLNA requires that the CDS:CreateObject response includes only the metadata
supported by the MediaServer as specified in this guideline. In this case, metadata supported by
the MediaServer has the following characteristics:
• needs to minimally include the MediaServer's supported metadata properties (XML elements
and attributes) that was specified in the request,
• and can optionally include additional metadata properties (XML elements and attributes) that the
MediaServer added as part of the success CDS:CreateObject response.
10.1.8.24.4
[G UIDELINE ] A UPnP AV MediaServer that creates a new CDS object, in response to a
CDS:CreateObject request, may add additional metadata properties (XML elements or attributes) in
the CDS:CreateObject response.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC 73QLR

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The following are some examples of cases when a DMS might add additional metadata
properties.

• The DMS adds the @dlna:dlnaManaged attribute to indicate the supported OCM operations for
a created CDS object.
• The DMS adds one or more upnp:createClass elements (in addition to those specified in the
CDS:CreateObject request) to indicate additional objects that can be created in a new CDS
container.
10.1.8.24.5
[G UIDELINE ] A UPnP AV MediaServer that receives a CDS:CreateObject request may change the
value of the @restricted attribute.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 340 –

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 3QLRK

29341-20-12
ISO/IEC
29341-20-3

10.1.8.24.6
[G UIDELINE ] If a UPnP AV MediaServer that indicates support for OCM operations (as defined in
guideline 10.1.8.8.4) receives a CDS:CreateObject request that specifies the creation of a CDS
object with support for one or more OCM operations that cannot be supported for the specified
object, then the MediaServer shall return a failure with UPnP AV error code 712 (Bad Metadata).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 773QL

29341-20-12
ISO/IEC
29341-20-3

10.1.8.24.7
[G UIDELINE ] If a UPnP AV MediaServer that indicates support for OCM operations (as defined in
guideline 10.1.8.8.4) receives a CDS:CreateObject request, it may change the value of the
@dlna:dlnaManaged attribute as long as the new value indicates a superset of the requested OCM
operation.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC EY8ZB

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DMS or MDMS devices are always allowed to increase the set of supported operations
on a created object. Otherwise, the DMS is required to return an error when the requested OCM
operations cannot be provided for the CDS object described in the CDS:CreateObject request.

10.1.8.24.8
[G UIDELINE ] If a UPnP AV MediaServer that does not indicate support for any OCM operations (as
defined in guideline 10.1.8.8.4) receives a CDS:CreateObject request that specifies the creation of
a CDS object with support for one or more OCM operations, and if the server creates a CDS object
as a result of the CDS:CreateObject request, it shall ignore the @dlna:dlnaManaged attribute in the
request and omit the @dlna:dlnaManaged attribute from the created object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 8Y9WS

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DMS or M-DMS devices that do not support OCM operations might not understand
@dlna:dlnaManaged attribute, and are required to drop the OCM flags from the created object
regardless of the validity of the attribute in the request.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 341 –

10.1.8.25 MM/CM: general rules for CDS:CreateObject errors

10.1.8.25.1
[G UIDELINE ] If a UPnP AV MediaServer rejects a CDS:CreateObject request due to invalid
metadata values in the request, then the MediaServer shall return UPnP AV error code 712 (Bad
metadata).

Invalid values are values that are not valid for the data type (as defined by the appropriate schema)
or values that are not supported by the MediaServer implementation.

Valid, non-empty values are values that are valid for the data type specified for the metadata
property and also not composed entirely of white space characters.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC QLRK8

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] A UPnP MediaServer might choose to accept a CDS:CreateObject request despite

invalid metadata values. For example, a MediaServer that always replaces a certain metadata value
with a preset value can simply ignore that metadata value contained in the request.

k) A UPnP AV MediaServer that removes the entire metadata property from the Result output is
informing the control point that the specified property is not supported, rather than informing the
control point that the value is invalid. This is described in 10.1.8.24.3.
l) Although this guideline applies to the MediaServer, control points are expected to provide valid
metadata values, as required by 10.1.8.15 and 10.1.8.24.
10.1.8.25.2
[G UIDELINE ] If a UPnP AV MediaServer returns a CDS:CreateObject response with a UPnP error
code, it shall not result in the creation of a new CDS object.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC YLU6X

29341-20-12
ISO/IEC
29341-20-3

10.1.8.25.3
[G UIDELINE ] If the UPnP AV MediaServer does not support the CDS:CreateObject action because
the specified upnp:class or res@protocolInfo is not acceptable to the MediaServer, it shall respond
with an error code 712 (Bad Metadata).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC LU6X9

29341-20-12
ISO/IEC
29341-20-3

10.1.8.25.4
[G UIDELINE ] If a UPnP AV MediaServer receives a CDS:CreateObject request with multiple <res>
elements and the UPnP AV MediaServer does not allow the creation of objects with multiple <res>
elements, then it shall return a UPnP AV error code of 712 (Bad Metadata).

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 342 –

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC Q22GR

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] MediaServers are not required to support multiple <res> elements.

10.1.8.25.5
[G UIDELINE ] If a UPnP AV MediaServer rejects a CDS:CreateObject request because the <res>
element specifies a URI value or a res@importUri value, then it shall return a UPnP AV error code
of 712 (Bad Metadata).

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 22GRN

29341-20-12
ISO/IEC
29341-20-3

10.1.8.25.6
[G UIDELINE ] If a UPnP AV MediaServer cannot accept a CDS:CreateObject request due to the
processing capacity or current state of the device, then it shall respond with error code 720 (Cannot
process the request).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC 8N9TA

29341-20-12
ISO/IEC
29341-20-3

10.1.8.25.7
[G UIDELINE ] If a UPnP AV MediaServer cannot accept a CDS:CreateObject request due to the lack
of storage capacity, then the MediaServer shall return a UPnP error response with error code of 720
(Cannot process the request).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC N9TA4

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] A MediaServer can return this error code as a result of a res@size value specified in a
CDS:CreateObject request. A DMS can also return this value when the upload capacity for the DMS
has been reached.

10.1.8.25.8
[G UIDELINE ] If a UPnP AV MediaServer receives a CDS:CreateObject request with zero <res>
elements and the UPnP AV MediaServer does not allow the creation of objects with zero <res>
elements, then it shall return a UPnP AV error code of 712 (Bad Metadata).

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 3Y33M

29341-20-12
DLNA guidelines; Part 1-1: Architecture and protocols
 – 343 –

ISO/IEC
29341-20-3

[C OMMENT] This behavior is conditionally mandatory because a UPnP AV MediaServer might be

able to support the creation of a container object with zero <res> elements.

10.1.8.26 MM/CM: content transfer process

10.1.8.26.1
[G UIDELINE ] If a UPnP AV MediaServer control point is going to initiate a content transfer process
for the first file (either the IFO file or the actual content binary) of a CDS object, then it shall do so
within 30 s of the last event described below.

• The CDS:CreateObject response from a Upload AnyContainer or an OCM: upload content

operation.
If a UPnP AV MediaServer control point uploads an IFO file, then the IFO file shall be uploaded first
and the transfer of the actual content binary shall be started within 30 s of completing the IFO file
transfer.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 RZ5I6

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] Within 30 s of creating the CDS object, the Control Point begins its first content
transfer for the CDS object.

10.1.8.26.2
[G UIDELINE ] A UPnP AV MediaServer control point shall utilize the URI provided in a
res@importUri or a res@dlna:importIfoFileURI as the destination URI for a content transfer
process.

UPnP AV MediaServer control points shall only upload content binaries to the res@importUri.

UPnP AV MediaServer control points shall only upload IFO files to the URI value of
res@dlna:importIfoFileURI.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 Z5I6Y

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] The CDS specification is ambiguous as to whether a <res> element's URI value can be
used to overwrite content. These guidelines limit the control to using import URI values for both
initial and overwriting content transfers. See 11.4.3.65 for HTTP client implications.

m) IFO files are not considered content binaries, so uploading an IFO file to a res@importUri file is
expressly prohibited.
n) For additional information on performing a content transfer process for either a content binary or
an IFO file, see 11.4.3.65.
o) For additional information on creating a <res> element for uploading IFO files, see 10.1.8.19.3.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 344 –

10.1.8.26.3
[G UIDELINE ] If a UPnP AV MediaServer control point fails to completely upload an IFO file and if
res@dlna:resumeUpload="1" and if the control point initiates a retry IFO attempt, then the control
point shall initiate the retry IFO attempt within 30 min of the failure.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 BLX49

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] Retry attempts to transfer the IFO file needs to start within 30 min of the time of failure
because the MediaServer will destroy the CDS object 35 min after the failure has occurred.

10.1.8.26.4
[G UIDELINE ] If a UPnP AV MediaServer control point fails to completely upload a content binary
and if res@dlna:resumeUpload="1" and if the control point initiates a resume content transfer, then
the control point shall initiate the resume content transfer within 30 min of the failure.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 LX49K

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] Resume attempts to transfer the content binary file needs to start within 30 min of the
time of failure because the MediaServer will destroy the CDS object 35 min after the failure has
occurred.

10.1.8.26.5
[G UIDELINE ] A UPnP AV MediaServer control point shall not attempt to use retry IFO transfer or
resume content transfer unless res@dlna:resumeUpload="1".

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 855LC

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

10.1.8.26.6
[G UIDELINE ] A UPnP AV MediaServer shall facilitate a content transfer process by supporting an
HTTP POST request on a URI for a res@importUri or a res@dlna:importIfoFileURI.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 55LC5

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] DLNA defines HTTP POST as the only mechanism for a content transfer process.
DLNA might define additional mechanisms for a content transfer process in the future.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 345 –

10.1.8.27 MM/CM: general rules after a successful content transfer process

10.1.8.27.1
[G UIDELINE ] If a UPnP AV MediaServer successfully completes a content transfer process, then
the MediaServer may keep or remove the res@importUri attribute.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC RGWVX

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] A MediaServer that keeps the res@importUri attribute is informing the network that an
Upload Controller can overwrite the content that was uploaded.

10.1.8.27.2
[G UIDELINE ] If a UPnP AV MediaServer keeps the res@importUri attribute and creates a URI value
for the <res> element (to signal that the Content Source will serve the URI), then the MediaServer
may specify the same URI value for both the res@importUri and the URI value of a <res> element.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC 4IVOE

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] MediaServers are permitted to use the same URI for both the <res> URI value and the
res@importUri value. In such cases, MediaServers need to ensure that the <res> value is not
exposed until after the content has been received, as described in guideline 10.1.8.27.4.

10.1.8.27.3
[G UIDELINE ] If a UPnP AV MediaServer keeps the res@dlna:ifoFileURI attribute and creates a
res@dlna:importIfoFileURI value for the <res> element (to signal that the Content Source will serve
the URI), then the MediaServer may specify the same URI value for both the
res@dlna:importIfoFileURI and the res@dlna:ifoFileURI value of a <res> element.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC GWVX7

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] MediaServers are permitted to use the same URI for both the <res> URI value and the
res@importUri value. In such cases, MediaServers need to ensure that the <res> value is not
exposed until after the content has been received, as described in guideline 10.1.8.27.4.

10.1.8.27.4
[G UIDELINE ] If a UPnP AV MediaServer is going to serve uploaded content to other endpoints, then
the DMS shall provide the URI value of the <res> element only after the DMS can serve the content.

Example of <res> before content is uploaded to the DMS:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 346 –

<res protocolInfo="http-get:*:image/jpeg:*:DLNA.ORG_PN=JPEG_LRG"
importUri="http://192.168.1.10/upload?file=content-data-1234.jpg"/>

Example of <res> after content is uploaded to the DMS:

<res protocolInfo="http-get:*:image/jpeg:*:DLNA.ORG_PN=JPEG_LRG">
http://192.168.1.10/content-data-1243.jpg</res>

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC IVOE5

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] A UPnP AV MediaServer that advertises a <res> URI value before the content can
actually be served is making a false claim that the content is available.

p) A DMS that serves partially uploaded content is responsible for conforming to the guidelines
related to the Media Format Profile.
10.1.8.27.5
[G UIDELINE ] A UPnP AV MediaServer may automatically create additional <res> elements (with
network-accessible URI values and protocolInfo values) after a successful content transfer process.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC S33FG

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] MediaServers might want to provide additional <res> elements to support content
transformations or additional transport protocols.

10.1.8.27.6
[G UIDELINE ] If a UPnP AV MediaServer is going to serve uploaded content that has an IFO file,
then the MediaServer shall provide the URI value of the <res> element after the Content Source can
provide the IFO file.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 33FGH

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Advertising content with SCR/PTS discontinuities without providing an IFO file is a
violation of guideline 10.1.4.9.2.

10.1.8.27.7
[G UIDELINE ] If a UPnP AV MediaServer is going to serve uploaded content that has an IFO file, and
successfully receives an IFO file in a content transfer process, then the MediaServer shall provide
a res@dlna:ifoFileURI attribute with a URI value for the IFO file. Until the MediaServer has the IFO
file, the res@dlna:ifoFileURI shall have an empty value.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 347 –

Example timeline (with additional comments for other hypothetical situations after ***) Letters in
angle brackets, <n>, refer to steps in this timeline.

a) Upload Controller invokes CDS:CreateObject with a <res> element for MPEG_PS_NTSC. The
request includes res@dlna:ifoFileURI="" to indicate that it will also upload an IFO file. The
request also includes res@dlna:resumeUpload="1" to indicate that the Upload Controller will
use resume features if a failure occurs during a transfer. *** If the Upload Controller is not
uploading an IFO file, it would have omitted res@dlna:ifoFileURI. If the Upload Controller was
not going to use resume, it would have omitted res@dlna:resumeUpload.
b) The DMS or M-DMS responds with success. The response includes a res@importUri and
res@dlna:importIfoFileURI, with URI values that will receive the uploaded content. The
response preserves the res@dlna:resumeUpload="1" to indicate resume is supported. *** If the
DMS/M-DMS does not support resume, it would have omitted res@dlna:resumeUpload or set
the value to "0". A DMS/M-DMS never returns res@dlna:resumeUpload="1" unless requested to
do so.
c) The Upload Controller begins uploading the IFO file.
d) During the transfer from <c>, an error occurs and the transfer fails.
e) Within 30 min of the error in <d>, the Upload Controller issues an HTTP POST to retry the
transfer of the IFO file. The Upload Controller does not use CONTENT-Range when retrying an
IFO transfer. *** If the Upload Controller does not do the retry, then the DMS/M-DMS would
automatically destroy the new CDS object (from <a>). The DMS/M-DMS waits at least 35 min
from the failure time in <d> before automatically destroying the CDS object. In scenarios where
resume is not enabled, the DMS/M-DMS would destroy the CDS object (from <a>) at any time
after the error in <d> occurred.
f) After completing the retry IFO transfer from <e>, the Upload Controller initiates the transfer of
the content binary within 30 s. *** If the Upload Controller is not uploading an IFO, then it would
have started the content transfer within 30 s of receiving the CDS:CreateObject response.
g) During the transfer from <f>, an error occurs and the transfer fails.
h) Within 30 min of the error in <g>, the Upload Controller issues an HTTP POST with the
CONTENT-Range header to resume the transfer from the byte position where the failure
occurred. *** If the Upload Controller does not do the resume, then the DMS/M-DMS would
automatically destroy the new CDS object (from <a>). The DMS/M-DMS waits at least 35 min
from the failure time in <g> before automatically destroying the CDS object. In scenarios where
resume is not enabled, the DMS/M-DMS would destroy the CDS object (from <a>) at any time
after the error in <g> occurred.
i) The content transfer from <f> succeeds and the DMS/M-DMS advertises URI values for the
<res> element and the res@ifoFileURI.
j) The DMS or M-DMS also automatically creates a new <res> element for its locally converted
version of MPEG_PS_NTSC_XAC3
[A TTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 43829

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Just as a MediaServer uses the <res> URI value to indicate that the content is
available for Content Receivers, the MediaServer also uses the res@dlna:ifoFileURI attribute to
indicate that the IFO file is available for Content Receivers.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 348 –

10.1.8.28 MM/CM: Auto-Destroy behavior for a failed or partial content transfer process
10.1.8.28.1
[G UIDELINE ] If a UPnP AV MediaServer implements CDS:CreateObject for use with the listed
operations, then it shall implement Auto-Destroy behavior.

Listed operations:

• upload AnyContainer;
• OCM: upload content.
The Auto-Destroy behavior shall be defined as removing the created CDS object from the CDS
hierarchy exposed by the MediaServer, such that the CDS object cannot be found when browsing or
searching the MediaServer.

The time when the CDS object is actually removed from the CDS hierarchy is not entirely defined by
the guidelines. However, other guidelines in 10.1.8.28 have restrictions when the CDS object is
automatically removed.

All guidelines in 10.1.8.28 assume Ideal Network Conditions and interoperability is not guaranteed
in scenarios involving user-initiated or out-of-scope system events.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC FWQZZ

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] A DMS that supports the Upload system usage needs to automatically destroy CDS
objects when the files are not properly received by the MediaServer.

k) The guidelines guarantee interoperability only under Ideal Network Conditions. Scenarios that
involve user-initiated events or out-of-scope system events do not guarantee interoperability.
Examples include:
• another control point invoking CDS:DestroyObject causes a failure during an upload
AnyContainer operation;
• the MediaServer product canceling all active uploads because it is starting to record a video
broadcast to local storage.
l) The actual time when the MediaServer destroys such CDS items is not defined by DLNA. Some
examples include a 35 min timer mechanism, a clean-up mechanism that executes when the
device has been idle for an extended period of time, or a cleanup operation that only executes
when certain CDS actions are called.
10.1.8.28.2
[G UIDELINE ] If res@dlna:resumeUpload="0" or res@dlna:resumeUpload is omitted, a UPnP AV
MediaServer shall perform Auto-Destroy behavior on CDS objects (created through upload
AnyContainer or OCM: upload content) under these conditions:

• 35 s has elapsed since the CDS:CreateObject response was completely sent and the first
content transfer process (for either the IFO file or the content binary) has not started;
• 35 s has elapsed since the CDS object's IFO was completely received and the content transfer
process for the content binary has not started;
• the content transfer process of the content binary or the IFO file has failed.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 349 –

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 38293

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline explains when a MediaServer needs to automatically destroy CDS
objects that were created from upload AnyContainer or OCM: upload content.

The guideline explicitly covers the case where resume content transfer, as described in 10.1.8.20,
is not supported.

10.1.8.28.3
[G UIDELINE ] If res@dlna:resumeUpload="1", a UPnP AV MediaServer shall perform Auto-Destroy
behavior on CDS objects (created through upload AnyContainer or OCM: upload content) under
these conditions:

• 35 s has elapsed since the CDS:CreateObject response was completely sent and the first
content transfer process (for either the IFO file or the content binary) has not started;
• 35 s has elapsed since the CDS object's IFO was completely received and the content transfer
process for the content binary has not started;
• 35 min has elapsed since the failure of a content transfer process for the CDS object's IFO and
retry IFO attempt has not started;
• 35 min has elapsed since the failure of a content transfer process for the CDS object's content
binary and resume content transfer process has not started.
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC WQZZF

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline explains when a MediaServer needs to automatically destroy CDS
objects that were created from upload AnyContainer or OCM: upload content.

m) The guideline explicitly covers the case where resume content transfer, as described in
10.1.8.20, is supported.
10.1.8.28.4
[G UIDELINE ] A UPnP AV MediaServer shall not automatically destroy a CDS object or any of its
<res> element when the MediaServer is doing a content transfer process for the CDS object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC QZZFP

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline requires MediaServer implementations not to destroy CDS objects or
<res> elements involved in an Upload system usage.

n) As implied from the comment for 10.1.8.28.1, a MediaServer might choose to destroy such an
object as a result of a CDS:DestroyObject request that was invoked from another control point.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 350 –

This type of a scenario is an unexpected user-initiated and is outside the scope of the Ideal
Network Conditions assumption.
10.1.8.28.5
[G UIDELINE ] If a UPnP AV MediaServer partially completes a content transfer process for a <res>
element and res@dlna:resumeUpload="1", then the MediaServer shall keep all res@importUri and
res@dlna:importIfoFileURI that are associated with the CDS object valid for at least another 35 min.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 293RE

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This guideline clarifies that MediaServers needs to preserve the validity of URI values
that are used for uploaded IFO files and content binaries.

o) After a MediaServer partially receives a content binary, the device needs to extend the validity
of the URI values (that have not completed a content transfer process) for at least 35 min. This
provides a reasonable amount of time for an Upload Controller to retry or set up the next content
transfer process.
p) See 10.1.8.20.4 to 10.1.8.20.8 and 11.4.3.67 for more information about resuming a failed
content transfer process.
10.1.8.28.6
[G UIDELINE ] A UPnP AV MediaServer control point may use an OCM: destroy object operation to
cancel the following operations: upload AnyContainer or OCM: upload content.

[ATTRIBUTES ]

O C +UP+ +UPSYNC+ n/a n/a ISO/IEC 29341-20-12 ZZFPW

ISO/IEC 29341-14-12
ISO/IEC 29341-20-3
ISO/IEC 29341-14-3

[C OMMENT] A Control Point uses this operation to signal the DMS to undo its previous operations
that resulted in the creation of a CDS object.

10.1.8.29 MM/CM: Content validation and advertisement

10.1.8.29.1
[G UIDELINE ] If a UPnP AV MediaServer successfully completes a content transfer process for a
CDS resource that was created with the DLNA.ORG_PN parameter in the 4th field, then the
MediaServer may advertise that content using the supplied DLNA Media Format Profile.

Advertise that content is meant specifically that the MediaServer provides a URI value for the <res>
element. Before the MediaServer receives the content binary, the <res> element (without a URI
value) will be advertised along with the res@importUri.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 8293R

29341-20-12
ISO/IEC
29341-20-3

DLNA guidelines; Part 1-1: Architecture and protocols

 – 351 –

[C OMMENT] DLNA UPnP AV MediaServers that support the Upload Device Option can assume that
control points that claim content conforms to DLNA are actually going to upload DLNA-conformant
content. However, it is still good practice for a UPnP AV MediaServer to examine the uploaded
content against the profile definition before advertising the content as being DLNA conformant.

10.1.8.29.2
[G UIDELINE ] If a UPnP AV MediaServer receives a content binary for a CDS resource that does not
have the DLNA.ORG_PN parameter, and it intends to advertise the content, then the MediaServer
shall validate the content before advertising it with the DLNA.ORG_PN parameter.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC FGH9D

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Although an algorithm for validation is not specified, a UPnP AV MediaServer that
determines that uploaded content is conformant to a DLNA Media Format Profile is permitted to
advertise it as such. The guideline does not obligate a DMS to either support uploading or
advertising of non-DLNA content.

10.1.8.29.3
[G UIDELINE ] A UPnP AV MediaServer may change the value of a res@protocolInfo as part of the
content validation process.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC 3FGH9

29341-20-12
ISO/IEC
29341-20-3

10.1.8.29.4
[G UIDELINE ] If a UPnP AV MediaServer exposes uploaded content, then it should examine the
uploaded content binaries to ensure that the metadata reported through the CDS is consistent with
the content binary. In cases where a conflict is found, a UPnP AV MediaServer should appropriately
correct the metadata reported through CDS.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC OE52V

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This is a good behavioral practice and helps to prevent interoperability problems.

10.1.8.30 MM/CM: general rules for CDS:DestroyObject

[G UIDELINE ] If a UPnP AV MediaServer implements CDS:DestroyObject, then a
CDS:DestroyObject request on a CDS item, with the @dlna:dlnaManaged attribute, shall result in
the complete removal of the CDS item.

If the CDS:DestroyObject is a success, then the CDS item is removed from the CDS hierarchy.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 352 –

If the CDS:DestroyObject is a failure, then the CDS item remains unaltered.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC VOE52

29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Partially destroying a CDS item (such as some metadata or <res> elements) is
problematic because control points have no way to recover the partially lost information.

q) The related question of whether the actual content binaries are deleted from the local storage is
vendor-defined.
r) Information for developers: this guideline applies only to CDS Content Items (object.item) and
not CDS Containers (object.container).
10.2 Content synchronization MM/CM guidelines
10.2.1 General
The guidelines contained in 10.2 apply only when the Upload or Download Synchronization
Controller system usages are implemented by a UPnP AV MediaServer control point and a UPnP
AV MediaServer.

10.2.2 MM/CM: Download Synchronization Controller

10.2.2.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The following conditionally mandatory
requirements are adhered to only when supporting the Upload or Download Synchronization system
usages.

10.2.2.2
[G UIDELINE ] A Download Synchronization Controller shall implement a UPnP AV MediaServer
control point for synchronizing content from a DMS or M-DMS respectively.

[ATTRIBUTES ]

M A +DNSYNC+ n/a n/a ISO/IEC 29341-14-12 73OLY

ISO/IEC 29341-14-3

[C OMMENT] This guideline indicates that a Download Synchronization Controller Device Capability
will use a UPnP control point that controls a UPnP AV MediaServer for browsing, searching and
synchronizing content from the Media Server.

10.2.2.3
[G UIDELINE ] A Download Synchronization Controller shall implement a UPnP AV MediaServer
control point capable of invoking the following actions.

• CDS:Search
• CDS:Browse
[ATTRIBUTES ]

M A +DNSYNC+ n/a n/a ISO/IEC 29341-14-12 V8WTG

ISO/IEC 29341-14-3

DLNA guidelines; Part 1-1: Architecture and protocols

 – 353 –

[C OMMENT] This guideline clarifies the UPnP CDS actions a Download Synchronization Controller
needs to be able to invoke with a UPnP AV MediaServer.

10.2.2.4
[G UIDELINE ] A Download Synchronization Controller may maintain synchronization of some or all
of the metadata, items, and resources exposed by a DMS/M-DMS implementing Content
Synchronization Device Option.

[ATTRIBUTES ]

O C +DNSYNC+ n/a n/a ISO/IEC 29341-14-12 BVYZW

ISO/IEC 29341-14-3

[C OMMENT] This guideline clarifies that it is the role of the Download Synchronization Controller to
decide whether some or all of the items, metadata, and resources need to be tracked to constitute
a completed synchronization.

10.2.3 MM/CM: Upload Synchronization Controller

10.2.3.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The following conditionally mandatory
requirements are adhered to only when supporting the Upload or Download Synchronization system
usages.

10.2.3.2
[G UIDELINE ] An Upload Synchronization Controller shall implement a UPnP AV MediaServer
control point for synchronizing content to a DMS or M-DMS respectively.

[ATTRIBUTES ]

M A +UPSYNC+ n/a n/a ISO/IEC 29341-14-12 3OLY3

ISO/IEC 29341-14-3

[C OMMENT] This guideline indicates that an Upload Synchronization Controller Device Capability
will use a UPnP control point that controls a UPnP AV MediaServer for sending content to the
MediaServer.

10.2.3.3
[G UIDELINE ] An Upload Synchronization Controller shall implement a UPnP AV MediaServer
control point capable of invoking the following actions.

• CDS:CreateObject
• CDS:UpdateObject
• CDS:DestroyObject
• CDS:GetFeatureList
• CDS:Search
• CDS:Browse
• CDS:GetServiceResetToken

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 354 –

[ATTRIBUTES ]

M L +UPSYNC+ n/a n/a ISO/IEC 29341-14-12 MURA8

ISO/IEC 29341-14-3

[C OMMENT] The capability of invoking these actions is required for performing the following
optional content management operations: OCM: upload content, OCM: create child container, OCM:
destroy object and OCM: change metadata.

10.2.3.4
[G UIDELINE ] An Upload Synchronization Controller shall be capable of invoking the OCM: upload
content operation.

See 10.1.8.2 for more information about optional content management operations.

[ATTRIBUTES ]

M L +UPSYNC+ n/a n/a ISO/IEC 29341-14-12 8WTGH

ISO/IEC 29341-14-3

[C OMMENT] Allows an Upload Synchronization Controller to synchronize (add) new content to an

AV MediaServer.

10.2.3.5
[G UIDELINE ] An Upload Synchronization Controller shall be capable of invoking the OCM: create
child Container operation.

See 10.1.8.2 for more information about optional content management operations.

[ATTRIBUTES ]

M L +UPSYNC+ n/a n/a ISO/IEC 29341-14-12 VYZW3

ISO/IEC 29341-14-3

[C OMMENT] Allows an Upload Synchronization Controller to invoke a necessary synchronization

(adding new containers) with an AV MediaServer.

10.2.3.6
[G UIDELINE ] An Upload Synchronization Controller shall be capable of invoking the OCM: destroy
object Operation.

See 10.1.8.2 for more information about optional content management operations.

[ATTRIBUTES ]

M L +UPSYNC+ n/a n/a ISO/IEC 29341-14-12 URA8J

ISO/IEC 29341-14-3

[C OMMENT] Allows an Upload Synchronization Controller to invoke a necessary synchronization

(removing non-restricted content or containers) from an AV Media Server.

10.2.3.7
[G UIDELINE ] An Upload Synchronization Controller shall be capable of invoking the OCM: change
metadata operation.

See 10.1.8.2 for more information about optional content management operations.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 355 –

[ATTRIBUTES ]

M L +UPSYNC+ n/a n/a ISO/IEC 29341-14-12 OLY3A

ISO/IEC 29341-14-3

[C OMMENT] Allows and Upload Synchronization Controller to invoke a necessary synchronization

(modifying content) on an AV MediaServer.

10.2.3.8
[G UIDELINE ] An Upload Synchronization Controller may upload some or all of the optional items,
metadata, and resources it decides to track on a DMS/M-DMS implementing the Content
Synchronization Device Option.

[ATTRIBUTES ]

O C +UPSYNC+ n/a n/a ISO/IEC 29341-14-12 WTGHW

ISO/IEC 29341-14-3

[C OMMENT] This guideline clarifies that it is the role of the Upload Synchronization Controller to
decide what optional items, metadata and resources need to be uploaded and tracked to constitute
a completed synchronization.

10.2.4 MM/CM general rules for thrashing avoidance

10.2.4.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The conditionally mandatory requirements in
this subclause are adhered to only when supporting the Upload or Download Synchronization
system usages.

10.2.4.2
[G UIDELINE ] An Upload Synchronization Controller shall not propagate without external input the
local stored metadata or content to the Media Server for objects that have changed on the server but
not on the client since the last synchronization.

[ATTRIBUTES ]

M A +UPSYNC+ n/a n/a ISO/IEC 29341-14-12 YZW3Y

ISO/IEC 29341-14-3

[C OMMENT] Limits the number of times competing Synchronization Controllers can change content
on an AV Media Server without external input, such as user intervention.

10.2.5 MM/CM: DMS or M-DMS with Content Synchronization Device Option support
definition
10.2.5.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The conditionally mandatory requirements in
this subclause are adhered to only when supporting the Upload or Download Synchronization
system usages.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 356 –

10.2.5.2
[G UIDELINE ] A UPnP AV MediaServer shall advertise the Content Synchronization Device Option
by specifying the <dlna:X_DLNACAP> element (as a child of the <device> element that represents
the MediaServer) with the content-synchronization token. Table 26 describes the Capability ID
syntax.

Table 26 – Capability ID syntax

Capability ID Description

content-synchronization The UPnP AV MediaServer supports the DLNA Content Synchronization

Device option.

The "content-synchronization" portion of the capability ID is a literal, string value.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 29341-14-12 LY3AY

ISO/IEC 29341-14-3

[C OMMENT] An Upload/Download synchronization controller uses this method to determine if it can

synchronize with a particular DMS/M-DMS.

10.2.5.3
[G UIDELINE ] A UPnP AV MediaServer shall implement the following optional content management
operations:

• OCM: update content

• OCM: create child container
• OCM: destroy object
• OCM: change metadata
as defined in 10.1.8.2.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 RA8JY

ISO/IEC 29341-14-3

[C OMMENT] These OCM operations allow content to be synchronized between an AV MediaServer

and the +UPSYNC+ or +DNSYNC+ client capabilities.

10.2.5.4
[G UIDELINE ] A UPnP AV MediaServer shall implement the Tracking Changes Option of the
ContentDirectory service.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 TGHWY

ISO/IEC 29341-14-3

[C OMMENT] As well as changes that occur as the result of UPnP Actions when the Content
Directory service is in the on-line state, changes to the underlying schema can occur through other
mechanisms both in the online and off-line state. If, for example, a user deletes files manually from

DLNA guidelines; Part 1-1: Architecture and protocols

 – 357 –

the schema that the Content Directory service is representing while it is in the off-line state, these
changes will be visible to Control Points when the Content Directory Service comes back on line.
Similarly, if a user deletes files manually from the schema when the Content Directory Service is
on-line, these changes will be handled as if the changes occurred via UPnP Actions.

10.2.5.5
[G UIDELINE ] A UPnP AV MediaServer shall implement the LastChange evented state variable.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 29341-14-12 ZW3YH

ISO/IEC 29341-14-3

[C OMMENT] The LastChange state variable allows the accumulation (buffering) and delivery
(eventing) of all changes to an AV MediaServer's content. The LastChange state variable is a
required feature of the Tracking Changes Option of the ContentDirectory service.

10.2.5.6
[G UIDELINE ] A UPnP AV MediaServer shall form a LastChange state variable consisting of a
properly formed XML document as indicated in XML Schema.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 29341-14-12 Y3AY5

ISO/IEC 29341-14-3
XML Schema

10.2.5.7
[G UIDELINE ] A UPnP AV MediaServer shall send the LastChange event message within 10 s of a
change occurring on the CDS.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 A8JYO

ISO/IEC 29341-14-3

10.2.5.8
[G UIDELINE ] All UPnP AV MediaServer CDS container objects shall include the @searchable
attribute with a value of "1".

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 W3YHF

ISO/IEC 29341-14-3

[C OMMENT] All containers on the CDS need to be searchable. A search can start from any
container in the CDS.

10.2.5.9
[G UIDELINE ] A UPnP AV Media Server shall list at least the following metadata items in the
SearchCapabilities state variable.

• upnp:containerUpdateID
• upnp:objectUpdateID

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 358 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 3AY53

ISO/IEC 29341-14-3

[C OMMENT] These values are the minimal set to allow searching for changes.

10.2.5.10
[G UIDELINE ] A UPnP AV Media Server shall list at least the following metadata items in the
SortCapabilities state variable.

• upnp:containerUpdateID
• upnp:objectUpdateID
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 8JYO5

ISO/IEC 29341-14-3

[C OMMENT] These allow ordering of changes in the CDS:Search() results.

10.2.5.11
[G UIDELINE ] A UPnP AV MediaServer shall implement at least the operators stated in Table 27 on
the indicated metadata items within the SearchCriteria of the CDS:Search() operation.

Table 27 – UPnP AV MediaServer Metadata SearchCriteria

Metadata Item Operator(s)

upnp:containerUpdateID >,=,>=,<,<=,!=, exists

upnp:objectUpdateID >,=,>=,<,<=,!=, exists

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 HWYRV

ISO/IEC 29341-14-3

10.2.5.12
[G UIDELINE ] A UPnP AV Media Server shall implement in the SearchCriteria argument of the
CDS:Search() action the logical "and" and "or" operators on at least 5 clauses containing the
metadata and operators specified in 10.2.5.11.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 3YHFF

ISO/IEC 29341-14-3

10.2.5.13
[G UIDELINE ] A UPnP AV MediaServer shall implement AV CDS Tracking Changes Option for all
items and therefore the following metadata attributes for all CDS items.

• upnp:objectUpdateID
• upnp:res@updateCount

DLNA guidelines; Part 1-1: Architecture and protocols

 – 359 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 AY533

ISO/IEC 29341-14-3

[C OMMENT] These metadata items allow tracking of CDS content entries. There is no partial
support of content tracking for some content on the server and not for other content.

10.2.5.14
[G UIDELINE ] A UPnP AV MediaServer shall implement AV CDS Tracking Changes Option for all
containers and therefore the following metadata attributes for all CDS containers.

• upnp:objectUpdateID
• upnp:totalDeletedChildCount
• upnp:containerUpdateID
• upnp:childCount
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 29341-14-12 JYO5N

ISO/IEC 29341-14-3

[C OMMENT] These metadata items allow tracking of CDS container level changes. There is no
partial support of content tracking for some content on the server and not for other content.

10.2.6 MM/CM: support for res@dlna:estimatedSize

10.2.6.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The conditionally mandatory requirements in
this subclause are adhered to only when supporting the Upload or Download Synchronization
system usages.

The res@dlna:estimatedSize is used by the server to advertise an estimate of the size of a content
binary in those cases where the exact size is not known. For example, if the content requires
transcoding that will not be performed until a request for the content is received, the exact length of
the transcoded version cannot be known. However, it can be useful for downloading or
synchronizing endpoints to have an estimate of the size of a content binary to determine whether it
is generally possible for that content to fit within the available storage.

10.2.6.2
[G UIDELINE ] A UPnP AV Media Server may include the res@dlna:estimatedSize attribute for any
resource within a content object returned as part of the result of a CDS:Browse() or CDS:Search()
operation.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC WYRVV

29341-14-12
ISO/IEC
29341-14-3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 360 –

10.2.6.3
[G UIDELINE ] A UPnP AV Media Server Upload Controller may include the res@dlna:estimatedSize
attribute for any resource created as part of the CDS:CreateObject() call within an OCM: create
object operation.

[ATTRIBUTES ]

O A +UP+ n/a n/a ISO/IEC YHFF8

29341-14-12
ISO/IEC
29341-14-3

10.2.6.4
[G UIDELINE ] A UPnP AV Media Server Upload Synchronization Controller may include the
res@dlna:estimatedSize attribute for any resource created as part of the CDS:CreateObject() call
within an OCM: create object operation.

[ATTRIBUTES ]

O A +UPSYNC+ n/a n/a ISO/IEC Y5337

29341-14-12
ISO/IEC
29341-14-3

10.2.6.5
[G UIDELINE ] If present the res@dlna:estimatedSize attribute shall have the same syntax and type
as the res@size attribute.

[ATTRIBUTES ]

M A DMS +UP+ M-DMS n/a ISO/IEC YO5NQ

+UPSYNC+ 29341-14-12
ISO/IEC
29341-14-3

10.2.6.6
[G UIDELINE ] If the res@Size attribute is present for any resource then the res@estimatedSize
attribute shall not be present for the same resource.

[ATTRIBUTES ]

M A DMS +UP+ M-DMS n/a ISO/IEC YRVVM

+UPSYNC+ 29341-14-12
ISO/IEC
29341-14-3

10.2.7 MM/CM: operations that need CDS:UpdateObject

10.2.7.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The conditionally mandatory requirements in
this subclause are adhered to only when supporting the Upload or Download Synchronization
system usages.

10.2.7.2
[G UIDELINE ] A UPnP AV MediaServer shall implement the OCM: change metadata operation and
therefore shall implement CDS:UpdateObject action.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 361 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC HFF8I

29341-14-12
ISO/IEC
29341-14-3

[C OMMENT] The CDS:UpdateObject action is used to change metadata on an existing CDS object.

10.2.8 MM/CM: general rules for CDS:UpdateObject request syntax

10.2.8.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The conditionally mandatory requirements in
this subclause are adhered to only when supporting the Upload or Download Synchronization
system usages.

10.2.8.2
[G UIDELINE ] A UPnP AV MediaServer control point invoking CDS:UpdateObject shall apply the
mandatory metadata encoding rules for the following guidelines in the NewTagValue input
argument.

• 10.1.3.1 MM UPnP AV control point tolerance of unknown property

• 10.1.3.2 MM DIDL-Lite restrictions
• 10.1.3.3 MM DIDL-Lite max metadata length
• 10.1.3.5 MM DIDL-Lite Boolean values
• 10.1.3.6 MM upnp:class values
• 10.1.3.7 MM DIDL-Lite dc:date format
• 10.1.3.9 MM DIDL-Lite desc element use
• 10.1.3.10 MM URI rules
• 10.1.3.12 MM DIDL-Lite recommended metadata properties
• 10.1.3.13 MM protocolInfo context
• 10.1.3.16 MM DIDL-Lite protocolInfo values
• 10.1.3.17 MM protocolInfo values: 4th field
• 10.1.3.18 MM pn-param (DLNA.ORG_PN parameter)
• 10.1.3.23 MM ci-param (conversion indicator flag)
[ATTRIBUTES ]

M A +UPSYNC+ n/a n/a ISO/IEC 5337Q

29341-14-12
ISO/IEC
29341-14-3

10.2.8.3
[G UIDELINE ] A UPnP MediaServer Control Point invoking CDS:UpdateObject shall not include the

• @dlna:dlnaManaged
• res@dlna:ifoFileURI
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 362 –

• res@dlna:importIfoFileURI
• albumArtURI@dlna:profileID
• res@dlna:trackTotal
• res@dlna:resumeUpload
• @dlna:containerType
• res@dlna:uploadedSize
metadata properties in the NewTagValue input argument.

[ATTRIBUTES ]

M A +UPSYNC+ n/a n/a ISO/IEC O5NQX

29341-14-12
ISO/IEC
29341-14-3

[C OMMENT] These values are set by the MediaServer capabilities and are defined as read-only
attributes.

10.2.8.4
[G UIDELINE ] A UPnP AV MediaServer control point invoking CDS:UpdateObject shall apply the
rules specified in 10.1.3.4.1 and 10.1.3.4.2 to all metadata.

[ATTRIBUTES ]

M A +UPSYNC+ n/a n/a ISO/IEC RVVM7

29341-14-12
ISO/IEC
29341-14-3

10.2.8.5
[G UIDELINE ] A UPnP AV MediaServer control point invoking CDS:UpdateObject, should not delete
metadata properties as defined in guideline 10.1.3.10.6 for the given upnp:class.

[ATTRIBUTES ]

S A +UPSYNC+ n/a n/a ISO/IEC FF8IA

29341-14-12
ISO/IEC
29341-14-3

[C OMMENT] The Control Point will preferably not delete metadata recommended for a given
upnp:class.

10.2.8.6
[G UIDELINE ] A UPnP AV MediaServer control point invoking CDS:UpdateObject with optional
metadata shall properly declare all namespaces.

[ATTRIBUTES ]

M A +UPSYNC+ n/a n/a ISO/IEC 337QN

29341-14-12
ISO/IEC
29341-14-3

DLNA guidelines; Part 1-1: Architecture and protocols

 – 363 –

10.2.8.7
[G UIDELINE ] A UPnP AV MediaServer allowing an update to the <dc:date> elements shall allow the
MediaServer control point to specify any valid form of <dc:date>, as defined by guideline 10.1.3.7.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 5NQX4

29341-14-12
ISO/IEC
29341-14-3

[C OMMENT] This guideline allows the control point to specify any valid form for <dc:date>. Control
points are not to assume that the format they specified in the request will be the final form of the
<dc:date>.

10.2.8.8
[G UIDELINE ] A UPnP AV MediaServer implementing the OCM: change metadata operation shall
ignore attempts to add unsupported metadata and only generate an error response if some other
error occurs or there were no successful modifications to the target object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VVM7J

29341-14-12
ISO/IEC
29341-14-3

[C OMMENT] The UPnP CDS behavior allows error conditions to be generated when attempting to
add unsupported metadata. Since the CP does not currently have a reliable method for determining
which metadata is actually supported by the DMS/M-DMS, restricting this error response allows
supported metadata to be accepted while simultaneously allowing unsupported metadata to have
no effect.

10.2.9 MM/CM: general rules for server behavior for CDS:UpdateObject

10.2.9.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The conditionally mandatory requirements in
this subclause are adhered to only when supporting the Upload or Download Synchronization
system usages.

10.2.9.2
[G UIDELINE ] A UPnP AV MediaServer implementing the OCM: change metadata operation for a
particular object should accept the creation of recommended properties corresponding to the
specified upnp:class, which are defined in the guideline 7.3.25 MM DIDL-Lite Recommended
Metadata Properties.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC F8IAT

29341-14-12
ISO/IEC
29341-14-3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 364 –

10.2.9.3
[G UIDELINE ] A UPnP AV MediaServer implementing the OCM: change metadata operation for a
particular object shall be able to accept CDS:UpdateObject requests that specify changes to
multiple properties.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 37QN7

29341-14-12
ISO/IEC
29341-14-3

10.2.9.4
[G UIDELINE ] A UPnP AV MediaServer implementing the OCM: change metadata operation for a
particular object and receiving a request where the CurrentTagValue does not match the current
state of the CDS, shall respond with an error code 702 (Invalid currentTagValue).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC NQX4R

29341-14-12
ISO/IEC
29341-14-3

10.2.10 MM/CM: OCM: change metadata operation

10.2.10.1
[G ENERAL ] The Content Synchronization MM/CM guidelines subclause defines the DLNA Upload
and Download Synchronization Controller system usage requirements for a UPnP AV MediaServer
and a Synchronization Controller Device Capability. The conditionally mandatory requirements in
this subclause are adhered to only when supporting the Upload or Download Synchronization
system usages.

10.2.10.2
[G UIDELINE ] A UPnP AV Media Server Control Point invoking an OCM: change metadata operation,
shall invoke CDS:UpdateObject with the following rules.

• The ObjectID shall identify the CDS object that is to receive the metadata change and the CDS
object shall support the OCM: change metadata operation.
[ATTRIBUTES ]

M A +UPSYNC+ n/a n/a ISO/IEC 7GY63

29341-14-12
ISO/IEC
29341-14-3

10.2.10.3
[G UIDELINE ] A UPnP AV MediaServer implementing the OCM: change metadata operation, shall
ignore all <res> elements received in a NewTagValue argument of the CDS:UpdateObject request.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 84T7U

29341-14-12
ISO/IEC
29341-14-3

[C OMMENT] The resource data defines the nature of the content and cannot be changed without
DLNA guidelines; Part 1-1: Architecture and protocols
 – 365 –

also changing the binary data. Creating a new <res> element is not supported, if the control point
desires to upload content, it needs to create a new object with the Upload AnyContainer or OCM:
upload content operations. Additionally, the OCM: change metadata operation is not used for
changing the binary data of a <res> element, the object will be deleted and re-created.

10.3 Scheduled Recording Media Management guidelines

10.3.1 MM/SR system usage feature support
10.3.1.1
[G ENERAL ] Subclause 10.3 defines the DLNA Scheduled Recording system usage requirements
for a UPnP AV MediaServer and a Scheduled Recording Controller Device Capability. The
guidelines in 10.3 are mandatory if the Scheduled Recording system usage is implemented.

10.3.1.2
[G UIDELINE ] If a DMS or M-DMS contains a UPnP ScheduledRecording service in the UPnP AV
MediaServer device, then it shall conform to all of the guidelines for a UPnP AV MediaServer in 10.3
as defined in 10.3.1 through 10.3.30 inclusive.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 59OVP

29341-4-3
ISO/IEC
29341-4-14

[C OMMENT] This guideline classifies the group of guideline requirements that a DMS and M-DMS
implements to support the Scheduled Recording Device Option for the Scheduled Recording system
usage.

10.3.1.3
[G UIDELINE ] A DLNA device class may implement the Scheduled Recording Controller Device
Capability.

[ATTRIBUTES ]

O A DMS DMP DMR DMC M-DMS M-DMP n/a ISO/IEC AIOZ5

M-DMC 29341-4-12
ISO/IEC
29341-4-3
ISO/IEC
29341-4-14

10.3.1.4
[G UIDELINE ] A Scheduled Recording Controller shall implement a UPnP AV MediaServer control
point that interacts with the ContentDirectory service for browsing content and with the
ScheduledRecording service for creating and managing recordings. It shall also conform to all of the
guidelines for a Scheduled Recording Controller in 10.3 as defined in 10.3.1 through 10.3.30
inclusive.

[ATTRIBUTES ]

M A +SR+ n/a n/a ISO/IEC D7M8R

29341-4-12
ISO/IEC
29341-4-3
ISO/IEC
29341-4-14

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 366 –

[C OMMENT] This guideline classifies the group of guideline requirements that a Scheduled
Recording Controller implements to support the Scheduled Recording system usage.

10.3.2 MM/SR exposing recorded content

10.3.2.1
[G UIDELINE ] A UPnP AV MediaServer should expose its recorded content in a ContentDirectory
service for DLNA consumption.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC K7CVW

29341-4-12
ISO/IEC
29341-4-3

[C OMMENT] Recording devices are ultimately built to offer consumption of their recorded content.
There are cases where the content consumption method is not defined by DLNA system usages.

10.3.2.2
[G UIDELINE ] If a UPnP AV MediaServer exposes recorded content in a ContentDirectory service,
then the recorded content shall be exposed in the ContentDirectory service co-located with the
ScheduledRecording service.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC OATA6

29341-4-12
ISO/IEC
29341-4-3

10.3.2.3
[G UIDELINE ] If a UPnP AV MediaServer exposes recorded content in a ContentDirectory service,
then at least one res property of the recorded content shall be conformant to a DLNA Media Format
Profile as defined in 10.1.3.16.4.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WZAIZ

29341-4-12
ISO/IEC
29341-4-3

10.3.2.4
[G UIDELINE ] If a UPnP AV MediaServer supports simultaneous streaming and recording, then the
recorded content CDS object with a res property should exist in the CDS as soon as the recordTask
starts recording.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 55MW8

29341-4-12
ISO/IEC
29341-4-3

10.3.2.5
[G UIDELINE ] If a UPnP AV MediaServer supports simultaneous streaming and recording, then the
recorded content CDS object should follow the DLNA UCDAM buffer model guidelines 10.1.3.33,
DLNA guidelines; Part 1-1: Architecture and protocols
 – 367 –

10.1.3.34 and Annex D to allow a UPnP AV MediaServer control point to interact with the dynamic
content binary size.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC ZR24T

29341-4-12
ISO/IEC
29341-4-3

10.3.2.6
[G UIDELINE ] A UPnP AV MediaServer shall expose the arib:objectType property in the Japan
region or dlna:objectType property in other geographical regions in the recorded content CDS item
with a value of the applicable broadcast system, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
The namespace "urn:schemas-arib-or-jp:elements-1-0/" shall be specified in the <item> element or
the <arib:objectType> element and the namespace prefix shall be "arib" when exposing the
arib:objectType property.

The namespace "urn:schemas-dlna-org:device-1-0" shall be specified in the <item> element or the

<dlna:objectType> element and the namespace prefix shall be "dlna" when exposing the
dlna:objectType property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 9M53Q

29341-4-12

[C OMMENT] This requirement provides UPnP AV MediaServer implementations with a CDS

property which can be used by control points to identify content items that were created as a result
of an execution of a recordTask. Values for the arib:objectType property need to be as specificed in
ARIB TR B-14 and ARIB TR B-15. Values for the dlna:objectType will need to something meaningful
for the applicable broadcast systems. Table 28 provides some initial guidance that can be updated
and added to in future.

Table 28 – dlna:objectType values

Broadcast Systems dlna:objectType Values

US Terrestrial Broadcast Systerm ATSC_TB
US Cable Broadcast Systems TBD
European Broadcast Systems TBD

10.3.2.7
[G UIDELINE ] A UPnP AV MediaServer shall expose the dc:date property in the recorded content
CDS item with a non-empty and non-whitespace value, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The CDS item of the recorded content exposes a upnp:class property with a value of
object.item.audioItem or object.item.videoItem.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 368 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC LRZI6

29341-4-12

10.3.2.8
[G UIDELINE ] A UPnP AV MediaServer shall set the value of the dc:date property in the recorded
content CDS item with a value which indicates the actual start date and time of the recorded content,
when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The CDS item of the recorded content exposes the dc:date property.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC HK2ET

29341-4-12

[C OMMENT] This is the CDS property that is recommended for containing the actual date and time
of the recorded content instead of using the upnp:recordedStartDateTime property. Usage of this
property makes this consistent for all types of CDS items contained in the CDS.

10.3.2.9
[G UIDELINE ] A UPnP AV MediaServer shall set the value of the res@duration property in the
recorded content CDS item with a value which indicates the recorded duration of the recorded
content after the completion of the recording, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The CDS item of the recorded content exposes the dc:duration property.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC HMUQV

29341-4-12

[C OMMENT] This is the CDS property that is recommended for containing the actual duration of the
recorded content instead of using the upnp:recordedDuration property. Usage of this property
makes this consistent for all types of CDS items contained in the CDS.

10.3.2.10
[G UIDELINE ] A UPnP AV MediaServer shall conform to the guidelines listed in Table 29 when all
the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The CDS srs:class property value is from the recordSchedule object that spawned the
recordTask.
Table 29 – Guidelines for recorded CDS properties based on srs:class values

srs:class value Guidelines for recorded CDS properties

DLNA guidelines; Part 1-1: Architecture and protocols

 – 369 –

OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG 10.3.9.5 to 10.3.9.11

OBJECT.RECORDSCHEDULE.DIRECT.MANUAL 10.3.10.5 to 10.3.10.7
OBJECT.RECORDSCHEDULE.DIRECT.CDSEPG 10.3.11.7 to 10.3.11.12
OBJECT.RECORDSCHEDULE.QUERY.CONTENTNAME 10.3.12.5
OBJECT.RECORDSCHEDULE.QUERY.CONTENTID 10.3.13.5

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC SXEVC

29341-4-12

[C OMMENT] Depending on the record class used to schedule a recording, these conformance
guidelines provide the recommended CDS property values for the recorded content CDS item. Note
that the same CDS properties defined for each class are semantically equivalent, but guidelines are
duplicated for each applicable record class (e.g. upnp:channelID). Table 30 summarizes the
recommended CDS properties for the recorded content for each srs:class.

Table 30 – Recommended recorded CDS properties based on srs:class value

srs:class value Recommended recorded CDS properties

OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG res@dlna:scheduledRecordedContent, dc:date,
res@duration, dc:title, upnp:channelName,
upnp:channelNr, upnp:genre, upnp:channelID,
upnp:scheduledStartTime,
upnp:scheduledEndTime
OBJECT.RECORDSCHEDULE.DIRECT.MANUAL res@dlna:scheduledRecordedContent, dc:date,
res@duration, dc:title, upnp:channelID,
upnp:scheduledStartTime,
upnp:scheduledEndTime
OBJECT.RECORDSCHEDULE.DIRECT.CDSEPG res@dlna:scheduledRecordedContent, dc:date,
res@duration, dc:title, upnp:channelName,
upnp:channelNr, upnp:genre, upnp:channelID,
upnp:scheduledStartTime,
upnp:scheduledEndTime
OBJECT.RECORDSCHEDULE.QUERY.CONTENTNAME res@dlna:scheduledRecordedContent, dc:date,
res@duration, dc:title
OBJECT.RECORDSCHEDULE.QUERY.CONTENTID res@dlna:scheduledRecordedContent, dc:date,
res@duration, dc:title

10.3.3 MM/SR UPnP ScheduledRecording service

[G UIDELINE ] A UPnP AV MediaServer shall implement the mandatory actions and state variables
of a ScheduledRecording service.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC UQXT8

29341-4-3
ISO/IEC
29341-4-14

10.3.4 MM/SR CDS association

10.3.4.1
[G ENERAL ] This set of guidelines defines the association between the UPnP ScheduledRecording
service and the UPnP ContentDirectory service.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 370 –

10.3.4.2
[G UIDELINE ] A UPnP AV MediaServer shall implement the DLNA Basic Tuner guidelines defined in
10.1.4.16 to 10.1.4.23 or the DLNA Extended Tuner guidelines defined in 10.4 to expose the
device’s channel lineup.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC TYFVG

29341-4-12
ISO/IEC
29341-4-3

10.3.5 MM/SR SRS:GetSortCapabilities action

10.3.5.1
[G UIDELINE ] A UPnP AV MediaServer shall respond to the SRS:GetSortCapabilities action with the
SortCaps output argument containing the entire list of values that are allowed as defined in ISO/IEC
29341-4-14 in the SortCriteria input argument for any UPnP ScheduledRecording action request.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC DCI2Z

29341-4-14

[C OMMENT] The UPnP ScheduledRecording service only supports a single mechanism for UPnP
AV MediaServers to advertise their support for sorting across the actions defined in the service.
Consequently, the UPnP AV MediaServer has to provide a consistent level of implementation
across all actions which accept a SortCriteria input argument so that a ScheduledRecording
Controller can rely on the output values of the SRS:GetSortCapabilities across all actions.

10.3.5.2
[G UIDELINE ] If a UPnP AV MediaServer does not implement sorting in the UPnP
ScheduledRecording service, it shall return an empty string in the SortCaps and “0” (zero) in the
SortLevelCap output arguments of the SRS:GetSortCapabilities action.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC EAOOX

29341-4-14

10.3.5.3
[G UIDELINE ] If a UPnP AV MediaServer includes the value of “srs-conflict-resolution” in the
<dlna:X_DLNACAP>, then it shall include the property srs:priority@orderedValue in the SortCaps
output argument in response to a SRS:GetSortCapabilities request.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC JJOSD

29341-4-14

10.3.6 MM/SR SRS:BrowseRecordSchedules action

10.3.6.1
[G UIDELINE ] If a UPnP AV MediaServer receives one or more property names in the Filter input
argument which are not implemented by the UPnP AV MediaServer for the
SRS:BrowseRecordSchedules action, then the request shall be processed as if these properties
were not included in the Filter input argument. If this results in an empty string, the UPnP AV
DLNA guidelines; Part 1-1: Architecture and protocols
 – 371 –

MediaServer shall only return the required properties as defined in ISO/IEC 29341-4-14 in the
result.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC M8LZZ

29341-4-14

[C OMMENT] This guideline clarifies UPnP AV MediaServer behavior when invalid properties are
included in the Filter input argument. A ScheduledRecording Controller can obtain the list of
properties supported by the UPnP AV MediaServer using the SRS:GetPropertyList action.

10.3.6.2
[G UIDELINE ] If a UPnP AV MediaServer receives one or more property names in the SortCriteria
input argument for the SRS:BrowseRecordSchedules action which are not returned in the SortCaps
output argument in the SRS:GetSortCapabilities action, then it shall return an Error Code 709
(Unsupported or invalid sort criteria).

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC GB2EJ

29341-4-14

[C OMMENT] This guideline clarifies the UPnP AV MediaServer response to an invalid SortCriteria
input argument. A ScheduledRecording Controller can obtain the sort capabilities of the UPnP AV
MediaServer by making a SRS:GetSortCapabilities request.

10.3.6.3
[G UIDELINE ] A UPnP AV MediaServer device may reduce the number of recordSchedule objects in
a response to a SRS:BrowseRecordSchedules action for the following scenarios only.

• The transmission of a SOAP response with a huge byte length (>204 800 B).
• The transmission of a SOAP response that exceeds 30 s for transmission time
[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC KOO7Z

29341-4-14

[C OMMENT] This requirement is to align with the requirement for a SOAP response in CDS:Browse
action and CDS:Search action defined in 10.1.4.11.1.

10.3.6.4
[G UIDELINE ] The number of recordSchedule object entries in the Result output argument
(containing the XML escaped srs XML Document) shall match the value specified in the
NumberReturned output argument.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 98W4S

29341-4-14

[C OMMENT] This guideline needs to be followed, even if a UPnP AV MediaServer reduces the
number of recordSchedule objects returned in the SOAP response. This requirement is to align with
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 372 –

the requirement for a SOAP response in CDS:Browse action and CDS:Search action defined in
10.1.4.11.2.

10.3.6.5
[G UIDELINE ] If the UPnP AV MediaServer device cannot find more than zero recordSchedule
objects (in 27 s, as described in 9.2.9.2), for a response to SRS:BrowseRecordSchedules request
and if UPnP AV MediaServer cannot calculate an accurate value for the TotalMatches output
argument, then the UPnP AV MediaServer should return a SOAP error response code of 720
(Cannot process the request).

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC ZJHU2

29341-4-14

[C OMMENT] This guideline covers the scenario where a UPnP AV MediaServer can neither find any
recordSchedule objects that satisfy the query nor calculate the TotalMatches output argument
accurately. Although some UPnP AV MediaServer implementations may choose to report the
accurate TotalMatches value, at the expense of violating the 27 s timeout rule, such behavior is not
recommended for the same reason stated in guideline 10.1.4.11.6. This guideline is to align with the
guideline for a SOAP response in CDS:Browse action and CDS:Search action defined in
10.1.4.11.7.

10.3.6.6
[G UIDELINE ] A UPnP AV MediaServer control point should specify the desired number of
recordSchedule objects in the RequestedCount input argument of a SRS:BrowseRecordSchedules
request.

[ATTRIBUTES ]

S C +SR+ n/a n/a ISO/IEC BYNOM

29341-4-14

[C OMMENT] This guideline recommends control points to request a reasonable number of

recordSchedule objects in a single query. The number of recordSchedule objects that can be
displayed to the user at a single time is a good measure of reasonableness. Generally speaking,
control points that specify smaller RequestedCount values will receive the response from the device
sooner than if a larger value were specified. Using a RequestedCount of zero is prohibited by ARIB
TR B-14. This guideline is to align with the guideline for a SOAP response in CDS:Browse action
and CDS:Search action defined in 10.1.4.11.8.

10.3.6.7
[G UIDELINE ] A UPnP AV MediaServer control point shall tolerate a response with less
recordSchedule objects than requested in a SRS:BrowseRecordSchedules request.

[ATTRIBUTES ]

M C +SR+ n/a n/a ISO/IEC 5ZXZL

29341-4-14

[C OMMENT] This guideline provides implementation guidance to a UPnP AV MediaServer control

point to not assume that its SRS:BrowseRecordSchedules request will return all of the
recordSchedule objects it requested. This requirement is to align with the requirement for a SOAP
response in CDS:Browse action and CDS:Search action defined in 10.1.4.11.10.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 373 –

10.3.6.8
[G UIDELINE ] A UPnP AV MediaServer control point should retrieve the remaining items in a
reduced response to a SRS:BrowseRecordSchedules request, when the value of TotalMatches is
greater than the value of NumberReturned, by issuing additional SRS:BrowseRecordSchedules
requests to complete the original SRS:BrowseRecordSchedules request for recordSchedule
objects.

[ATTRIBUTES ]

S C +SR+ n/a n/a ISO/IEC I7UFV

29341-4-14

[C OMMENT] This guideline requirement provides implementation guidance to UPnP AV

MediaServer control points when a UPnP AV MediaServer returns more than zero recordSchedule
objects in a response to a SRS:BrowseRecordSchedules action request with a reduced response.
This requirement is to align with the requirement for a SOAP response in CDS:Browse action and
CDS:Search action defined in 10.1.4.11.11.

10.3.7 MM/SR BrowseRecordTasks action

10.3.7.1
[G UIDELINE ] If a UPnP AV MediaServer receives one or more property names in the Filter input
argument which are not implemented by the UPnP AV MediaServer for the
SRS:BrowseRecordTasks action, then the request shall be processed as if these properties were
not included in the Filter input argument. If this results in an empty string, the UPnP AV MediaServer
shall only return the required properties as defined in ISO/IEC 29341-4-14 in the result.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC RRNYM

29341-4-14

[C OMMENT] This guideline clarifies UPnP AV MediaServer behavior when invalid properties are
included in the Filter input argument. A ScheduledRecording Controller can obtain the list of
properties supported by the UPnP AV MediaServer using the SRS:GetPropertyList action.

10.3.7.2
[G UIDELINE ] If a UPnP AV MediaServer receives one or more property names in the SortCriteria
input argument for the SRS:BrowseRecordTasks action which are not returned in the SortCaps
output argument in the SRS:GetSortCapabilities action, then it shall return an Error Code 709
(Unsupported or invalid sort criteria).

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC RUICO

29341-4-14

[C OMMENT] This guideline clarifies the UPnP AV MediaServer response to an invalid SortCriteria
input argument. A ScheduledRecording Controller can obtain the sort capabilities of the UPnP AV
MediaServer by making a SRS:GetSortCapabilities request.

10.3.7.3
[G UIDELINE ] A UPnP AV MediaServer device may reduce the number of recordTask objects in a
response to a SRS:BrowseRecordTasks action for the following scenarios only.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 374 –

• The transmission of a SOAP response with a huge byte length (>204 800 B).
• The transmission of a SOAP response that exceeds 30 s for transmission time.
[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC 572H8

29341-4-14

[C OMMENT] This guideline is to align with the requirement for a SOAP response in CDS:Browse
action and CDS:Search action defined in 10.1.4.11.1.

10.3.7.4
[G UIDELINE ] The number of recordTask object entries in the Result output argument (containing
the XML escaped srs XML Document) shall match the value specified in the NumberReturned
output argument.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 6YLEZ

29341-4-14

[C OMMENT] This guideline needs to be followed, even if a UPnP AV MediaServer reduces the
number of recordTask objects returned in the SOAP response. This guideline is to align with the
guideline for a SOAP response in CDS:Browse action and CDS:Search action defined in
10.1.4.11.2.

10.3.7.5
[G UIDELINE ] If the UPnP AV MediaServer device cannot find more than zero recordTask objects (in
27 s, as described in 9.2.9.2), for a response to SRS:BrowseRecordTasks request and if UPnP AV
MediaServer cannot calculate an accurate value for the TotalMatches output argument, then the
UPnP AV MediaServer should return a SOAP error response code of 720 (Cannot process the
request).

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC 683H9

29341-4-14

[C OMMENT] This guideline covers the scenario where a UPnP AV MediaServer can neither find any
recordTask objects that satisfy the query nor calculate the TotalMatches output argument
accurately. Although some UPnP AV MediaServer implementations may choose to report the
accurate TotalMatches value, at the expense of violating the 27 s timeout rule, such behavior is not
recommended for the same reason stated in guideline 10.1.4.11.6. This guideline is to align with the
requirement for a SOAP response in CDS:Browse action and CDS:Search action defined in
10.1.4.11.7.

10.3.7.6
[G UIDELINE ] A UPnP AV MediaServer control point should specify the desired number of
recordTask objects in the RequestedCount input argument of a SRS:BrowseRecordTasks request.

[ATTRIBUTES ]

S C +SR+ n/a n/a ISO/IEC 9QCYT

29341-4-14

DLNA guidelines; Part 1-1: Architecture and protocols

 – 375 –

[C OMMENT] This guideline recommends control points to request a reasonable number of

recordTask objects in a single query. The number of recordTask objects that can be displayed to the
user at a single time is a good measure of reasonableness. Generally speaking, control points that
specify smaller RequestedCount values will receive the response from the device sooner than if a
larger value were specified. Using a RequestedCount of zero is prohibited by ARIB TR B-14. This
requirement is to align with the guideline for a SOAP response in CDS:Browse action and
CDS:Search action defined in 10.1.4.11.8.

10.3.7.7
[G UIDELINE ] A UPnP AV MediaServer control point shall tolerate a response with less recordTask
objects than requested in a SRS:BrowseRecordTasks request.

[ATTRIBUTES ]

M C +SR+ n/a n/a ISO/IEC OICAS

29341-4-14

[C OMMENT] This quideline requirementprovides implementation guidance to a UPnP AV

MediaServer control point to not assume that its SRS:BrowseRecordTasks request will return all of
the recordTask objects it requested. This requirement is to align with the requirement for a SOAP
response in CDS:Browse action and CDS:Search action defined in 10.1.4.11.10.

10.3.7.8
[G UIDELINE ] A UPnP AV MediaServer control point should retrieve the remaining items in a
reduced response to a SRS:BrowseRecordTasks request, when the value of TotalMatches is
greater than the value of NumberReturned, by issuing additional SRS:BrowseRecordTasks
requests to complete the original SRS:BrowseRecordTasks request for recordTask objects.

[ATTRIBUTES ]

S C +SR+ n/a n/a ISO/IEC 9AXKX

29341-4-14

[C OMMENT] This guideline requirement provides implementation guidance to UPnP AV

MediaServer control points when a UPnP AV MediaServer returns more than zero recordSchedule
objects in a response to a CDS:BrowseRecordTasks action request with a reduced response. This
requirement is to align with the requirement for a SOAP response in CDS:Browse action and
CDS:Search action defined in 10.1.4.11.11.

10.3.8 MM/SR representation of allowed values description

10.3.8.1
[G ENERAL ] These guideline allow a UPnP AV MediaServer to reduce the allowed values
description returned in the PropertyInfo output argument from SRS:GetAllowedValues action. The
allowed values description is described as an XML document with the format (syntax) specified in
ISO/IEC 29341-4-4.

10.3.8.2
[G UIDELINE ] The allowed values returned by the UPnP AV MediaServer in response to a
SRS:GetAllowedValues request may contain <allowedValueDescriptor> elements which omit some
<dependentField> sub-elements.

[ATTRIBUTES ]

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 376 –

O C DMS M-DMS n/a ISO/IEC BXUSP

29341-4-14
ISO/IEC
29341-4-4

[C OMMENT] The dependencies between certain properties are defined in the UPnP SRS
Specification ISO/IEC 29341-4-14. Therefore the <dependentField> sub-element is not always
necessary in the <allowedValueDescriptor> elements for these properties. Vendors are strongly
encouraged to omit unnecessary <dependentField> sub-elements to minimize the length of the
output argument to SRS:GetAllowedValues.
The following examples show two cases in which some <dependentField> sub-elements could be
omitted:

This example illustrates the allowed values description for the srs:scheduledCDSObjectID property.

<field>
<name>srs:scheduledCDSObjectID</name>
<dataType maxSize="1024">xsd:string</dataType>
<allowedValueDescriptor>
<dependentField>
<name>srs:class</name>
<valueList>
<value>OBJECT.RECORDSCHEDULE.DIRECT.CDSEPG</value>
<value>OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG</value>
</valueList>
</dependentField>
<minCount>1</minCount>
<allowAny/>
</allowedValueDescriptor>
</field>

The SRS specification ISO/IEC 29341-4-14 defines the srs:scheduledCDSObjectID property to be

used only with the cdsNonEPG and cdsEPG record classes. Therefore the above XML fragment can
be reduced to the following:

<field>
<name>srs:scheduledCDSObjectID</name>
<dataType maxSize="1024">xsd:string</dataType>
<allowedValueDescriptor>
<minCount>1</minCount>
<allowAny/>
</allowedValueDescriptor>
</field>

This example illustrates the allowed values description for the srs:desiredPriority@type property.

<field>
<name>srs:desiredPriority@type</name>
<dataType maxSize="16">xsd:string</dataType>
<allowedValueDescriptor>
<dependentField>
<name>srs:desiredPriority</name>
<anyValue/>
</dependentField>
<minCount>1</minCount>
<allowedValueList>

DLNA guidelines; Part 1-1: Architecture and protocols

 – 377 –

<allowedValue>PREDEF</allowedValue>
<allowedValue>OBECTID</allowedValue>
</allowedValueList>
</allowedValueDescriptor>
</field>

An XML attribute can only exist in the context of its parent element. Therefore the above XML
fragment can be reduced to the following:

<field>
<name>srs:desiredPriority@type</name>
<dataType maxSize="16">xsd:string</dataType>
<allowedValueDescriptor>
<minCount>1</minCount>
<allowedValueList>
<allowedValue>PREDEF</allowedValue>
<allowedValue>OBECTID</allowedValue>
</allowedValueList>
</allowedValueDescriptor>
</field>

10.3.8.3
[G UIDELINE ] A UPnP AV MediaServer control point shall be able to parse and interpret
<allowedValueDescriptor> elements that omit the <dependentField> sub-element.

[ATTRIBUTES ]

M C +SR+ n/a n/a ISO/IEC 55STS

29341-4-14
ISO/IEC
29341-4-4

[C OMMENT] Guideline requirement 10.3.8.2 allows UPnP AV MediaServers to omit the

<dependentField> sub-elements.

10.3.9 MM/SR cdsNonEPG record class

10.3.9.1
[G ENERAL ] This defines the guidelines for a UPnP AV MediaServer when implementing the
mandatory cdsNonEPG record class for the ScheduledRecording service.

10.3.9.2
[G UIDELINE ] A UPnP AV MediaServer shall respond at a minimum with the value of
“OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG” to the SRS:GetAllowedValues action for
the srs:class property when the DataTypeID input argument is the value
A_ARG_TYPE_RecordScheduleParts or A_ARG_TYPE_RecordSchedule.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 9JGNA

29341-4-14

[C OMMENT] This reiterates the mandatory record class that is implemented by a UPnP AV
MediaServer with a ScheduledRecording service.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 378 –

10.3.9.3
[G UIDELINE ] A UPnP AV MediaServer shall respond to the SRS:GetAllowedValues action for the
srs:scheduledCDSObjectID property when the DataTypeID input argument is the value
A_ARG_TYPE_RecordScheduleParts or A_ARG_TYPE_RecordSchedule with either the following.

• A list of all of the CDS @id values, that are available to setup a RecordSchedule
• A value of “<allowAny></allowAny>
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC I9VW2

29341-4-14

[C OMMENT] The UPnP AV MediaServer uses the value “<allowAny></allowAny>” to indicate that it
allows any CDS object with the upnp:recordable property set to "1".

10.3.9.4
[G UIDELINE ] If a UPnP AV MediaServer responds to the SRS:GetAllowedValues action for the
srs:scheduledCDSObjectID property with a list of the CDS @id values, then the corresponding CDS
items shall exist and shall have the upnp:recordable property set to “1”

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC OEABB

29341-4-14

10.3.9.5
[G UIDELINE ] A UPnP AV MediaServer should set the value of the dc:title property in the recorded
content CDS item with the same value as the dc:title property contained in the CDS item specified
by the srs:scheduledCDSObjectID property, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC YTG5V

29341-4-12

[C OMMENT] This guideline requirement is semantically equivalent to guideline 10.3.11.5 for the
cdsEPG record class.

10.3.9.6
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:channelName property in the
recorded content CDS item with the same value as the upnp:channelName property contained in the
CDS item specified by the srs:scheduledCDSObjectID property, when all of the following conditions
are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 379 –

• The CDS item specified by the srs:scheduedCDSObjectID property exposes the

upnp:channelName property.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC SUQGU

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guideline 10.3.11.7 for the cdsEPG record
class.

10.3.9.7
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:channelNr property in the recorded
content CDS item with the same value as the upnp:channelNr property contained in the CDS item
specified by the srs:scheduledCDSObjectID property, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
• The CDS item specified by the srs:scheduedCDSObjectID property exposes the
upnp:channelNr property.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 72MV6

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guideline 10.3.11.8 for the cdsEPG record
class.

10.3.9.8
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:genre property in the recorded
content CDS item with the same value as the upnp:genre property contained in the CDS item
specified by the srs:scheduledCDSObjectID property, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
• The CDS item specified by the srs:scheduedCDSObjectID property exposes the upnp:genre
property.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC GMGFV

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guideline 10.3.11.9 for the cdsEPG record
class.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 380 –

10.3.9.9
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:channelID and
upnp:channelID@type properties in the recorded content CDS item with the same values as the
upnp:channelID and upnp:channelID@type properties contained in the CDS item specified by the
srs:scheduledCDSObjectID property, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
• The CDS item specified by the srs:scheduedCDSObjectID property exposes the upnp:channelID
and upnp:channelID@type properties.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC GPARX

29341-4-12

[C OMMENT] This guideline requirement is semantically equivalent to guideline requirements

10.3.10.5 and 10.3.11.10 for the Manual and cdsEPG record classes respectively.

10.3.9.10
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:scheduledStartTime property in the
recorded content CDS item with the same value as the srs:scheduledStartDateTime property
contained in the recordSchedule object, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledStartDateTime property is from the recordSchedule object that spawned the
recordTask.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC RZSWF

29341-4-12

[C OMMENT] This value is not necessarily the actual start time of the recording, that value would be
contained in the dc:date property.

s) This guideline is semantically equivalent to guidelines 10.3.10.6 and 10.3.11.11 for the Manual
and cdsEPG record classes respectively.
10.3.9.11
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:scheduledEndTime property in the
recorded content CDS item with the same value as the sum of the srs:scheduledStartDateTime and
srs:scheduledDuration properties contained in the recordSchedule object, when all of the following
conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledStartDateTime and srs:scheduledDuration properties are from the
recordSchedule object that spawned the recordTask.
[ATTRIBUTES ]
DLNA guidelines; Part 1-1: Architecture and protocols
 – 381 –

S A DMS M-DMS n/a ISO/IEC 9N6I9

29341-4-12

[C OMMENT] This value is not necessarily the actual end time of the recording, that value can be
calculated by summing the dc:date and res@duration properties.

t) This guideline is semantically equivalent to guidelines 10.3.10.7 and 10.3.11.12 for the Manual
and cdsEPG record classes respectively.
10.3.10 MM/SR manual record class
10.3.10.1
[G ENERAL ] This defines the requirements for a UPnP AV MediaServer when implementing the
optional manual record class for the ScheduledRecording service.

10.3.10.2
[G UIDELINE ] If a UPnP AV MediaServer implements the manual record class, then it shall include
in the response the value of “OBJECT.RECORDSCHEDULE.DIRECT.MANUAL” to the
SRS:GetAllowedValues action for the srs:class property when the DataTypeID input argument is
the value A_ARG_TYPE_RecordScheduleParts or A_ARG_TYPE_RecordSchedule.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 8UMKG

29341-4-14

10.3.10.3
[G UIDELINE ] If a UPnP AV MediaServer indicates support for the manual record class as defined in
guideline 10.3.10.2, then a UPnP AV MediaServer shall respond to the SRS:GetAllowedValues
action for the srs:scheduledChannelID property when the DataTypeID input argument is the value
A_ARG_TYPE_RecordScheduleParts or A_ARG_TYPE_RecordSchedule with either of the
following.

• A list of all of the CDS channelID values, that are available to setup a RecordSchedule.
• A value of “<allowAny></allowAny>”.
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC C4QMW

29341-4-14

[C OMMENT] The UPnP AV MediaServer uses the value “<allowAny></allowAny>” to indicate that it
allows any upnp:channelID value obtained from a Tuner channel item with the upnp:recordable
property set to "1".

10.3.10.4
[G UIDELINE ] If a UPnP AV MediaServer indicates support for the manual record class as defined in
guideline requirement 10.3.10.2 and responds to the SRS:GetAllowedValues action for the
srs:scheduledChannelID property with a list of the channelID values, then the corresponding CDS
items containing those upnp:channelID properties shall have the upnp:recordable property set to
“1”.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC D2XAU

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 382 –

29341-4-14

10.3.10.5
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:channelID and
upnp:channelID@type properties in the recorded content CDS item with the same values as the
srs:scheduledChannelID and srs:scheduledChannelID@type properties contained in the
recordSchedule object, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledChannelID and srs:scheduledChannelID@type properties are from the
recordSchedule object that spawned the recordTask.
[ATTRIBUTES ]

S A DMS M-DMS n/s ISO/IEC W5Q29

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guidelines 10.3.9.9 and 10.3.11.10 for the
cdsNonEPG and cdsEPG record classes respectively.

10.3.10.6
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:scheduledStartTime property in the
recorded content CDS item with the same value as the srs:scheduledStartDateTime property
contained in the recordSchedule object, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledStartDateTime property is from the recordSchedule object that spawned the
recordTask.
[ATTRIBUTES ]

S A DMS M-DMS n/s ISO/IEC YSN9Y

29341-4-12

[C OMMENT] The value is not necessarily the actual start time of the recording, that value would be
contained in the dc:date property.

u) This guideline requirement is semantically equivalent to guideline requirements 10.3.9.10 and

10.3.11.11 for the cdsNonEPG and cdsEPG record classes respectively.
10.3.10.7
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:scheduledEndTime property in the
recorded content CDS item with the same value as the sum of the srs:scheduledStartDateTime and
srs:scheduledDuration properties contained in the recordSchedule object, when all of the following
conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledStartDateTime and srs:scheduledDuration properties are from the
recordSchedule object that spawned the recordTask.
[ATTRIBUTES ]

DLNA guidelines; Part 1-1: Architecture and protocols

 – 383 –

S A DMS M-DMS n/s ISO/IEC RYLAY

29341-4-12

[C OMMENT] This value is not necessarily the actual end time of the recording, that value can be
calculated by summing the dc:date and res@duration properties.

v) This guideline requirement is semantically equivalent to guideline requirements 10.3.9.11 and

10.3.11.12 for the cdsNonEPG and cdsEPG record classes respectively.
10.3.11 MM/SR cdsEPG record class
10.3.11.1
[G ENERAL ] This defines the requirements for a UPnP AV MediaServer when implementing the
optional cdsEPG record class for the ScheduledRecording service.

10.3.11.2
[G UIDELINE ] If a UPnP AV MediaServer implements the cdsEPG record class as defined in
guidelines 10.3.11.3 to 10.3.11.5 respectively, then it shall implement the EPG Server Device
Option, as defined in 10.5.2.3, by including a <Feature> element with the Feature@name attribute
equal to “EPG” in the FeatureList output argument in response to the CDS:GetFeatureList action.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WE94G

29341-4-12
ISO/IEC
29341-4-14

10.3.11.3
[G UIDELINE ] If a UPnP AV MediaServer implements the cdsEPG record class, then it shall respond
with the value of “OBJECT.RECORDSCHEDULE.DIRECT.CDSEPG” to the SRS:GetAllowedValues
action for the srs:class property when the DataTypeID input argument is the value
A_ARG_TYPE_RecordScheduleParts or A_ARG_TYPE_RecordSchedule.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 74ODB

29341-4-14

10.3.11.4
[G UIDELINE ] If a UPnP AV MediaServer indicates support for the cdsEPG record class as defined
in guideline 10.3.11.3, then a UPnP AV MediaServer shall respond to the SRS:GetAllowedValues
action for the srs:scheduledCDSObjectID property when the DataTypeID input argument is the
value A_ARG_TYPE_RecordScheduleParts or A_ARG_TYPE_RecordSchedule with either of the
following.

• A list of all of the CDS @id values, that are available to setup a recordSchedule.
• A value of “<allowAny></allowAny>”.
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC D92QI

29341-4-14

[C OMMENT] The UPnP AV MediaServer uses the value “<allowAny></allowAny>” to indicate that it

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 384 –

allows any CDS object with the upnp:class property set to object.item.epgItem or its derived classes
and the upnp:recordable property set to "1".

10.3.11.5
[G UIDELINE ] If a UPnP AV MediaServer indicates support for the cdsEPG record class as defined
in guideline 10.3.11.3 and responds to the SRS:GetAllowedValues action for the
srs:scheduledCDSObjectID property with a list of the CDS @id values, then the corresponding CDS
items shall exist, shall have the upnp:class property set to object.item.epgItem or its derived
classes, and shall have the upnp:recordable property set to “1”.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC NO8L4

29341-4-14

10.3.11.6
[G UIDELINE ] A UPnP AV MediaServer should set the value of the dc:title property in the recorded
content CDS item with the same value as the dc:title property contained in the CDS item specified
by the srs:scheduledCDSObjectID property, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC HPIW2

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guideline 10.3.9.5 for the cdsNonEPG
record class.

10.3.11.7
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:channelName property in the
recorded content CDS item with the same value as the upnp:channelName property contained in the
CDS item specified by the srs:scheduledCDSObjectID property, when all of the following conditions
are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
• The CDS item specified by the srs:scheduedCDSObjectID property exposes the
upnp:channelName property.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC G3MOE

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guideline 10.3.9.6 for the cdsNonEPG
record class.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 385 –

10.3.11.8
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:channelNr property in the recorded
content CDS item with the same value as the upnp:channelNr property contained in the CDS item
specified by the srs:scheduledCDSObjectID property, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
• The CDS item specified by the srs:scheduedCDSObjectID property exposes the
upnp:channelNr property.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 5H8V6

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guideline 10.3.9.7 for the cdsNonEPG
record class.

10.3.11.9
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:genre property in the recorded
content CDS item with the same value as the upnp:genre property contained in the CDS item
specified by the srs:scheduledCDSObjectID property, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
• The CDS item specified by the srs:scheduedCDSObjectID property exposes the upnp:genre
property.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 5K399

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guideline 10.3.9.8 for the cdsNonEPG
record class.

10.3.11.10
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:channelID and
upnp:channelID@type properties in the recorded content CDS item with the same values as the
upnp:channelID and upnp:channelID@type properties contained in the CDS item specified by the
srs:scheduledCDSObjectID property, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 386 –

• The CDS item specified by the srs:scheduedCDSObjectID property exposes the upnp:channelID
and upnp:channelID@type properties.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 32SPN

29341-4-12

[C OMMENT] This guideline is semantically equivalent to guidelines 10.3.9.9 and 10.3.10.5 for the
cdsNonEPG and Manual record classes respectively.

10.3.11.11
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:scheduledStartTime property in the
recorded content CDS item with the same value as the upnp:scheduledStartTime property
contained in the CDS item specified by the srs:scheduledCDSObjectID property, when all of the
following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
• The CDS item specified by the srs:scheduedCDSObjectID property exposes the
upnp:scheduledStartTime property.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 4UDNI

29341-4-12

[C OMMENT] This value is not necessarily the actual start time of the recording, that value would be
contained in the dc:date property.

This guideline is semantically equivalent to guidelines 10.3.9.10 and 10.3.10.6 for the cdsNonEPG
and Manual record classes respectively.

10.3.11.12
[G UIDELINE ] A UPnP AV MediaServer should expose the upnp:scheduledEndTime property in the
recorded content CDS item with the same value as the upnp:scheduledEndTime property contained
in the CDS item specified by the srs:scheduledCDSObjectID property, when all of the following
conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
• The srs:scheduledCDSObjectID property is from the recordSchedule object that spawned the
recordTask.
• The CDS item specified by the srs:scheduedCDSObjectID property exposes the
upnp:scheduledEndTime property.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC VF9KL

29341-4-12

DLNA guidelines; Part 1-1: Architecture and protocols

 – 387 –

[C OMMENT] This value is not necessarily the actual end time of the recording, that value can be
calculated from by summing the dc:date and res@duration properties.

This guideline is semantically equivalent to guidelines 10.3.9.11 and 10.3.10.7 for the cdsNonEPG
and Manual record classes respectively.

10.3.12 MM/SR query content name record class

10.3.12.1
[G ENERAL ] This defines the guidelines for a UPnP AV MediaServer when implementing the
optional query contentName record class for the ScheduledRecording Service

10.3.12.2
[G UIDELINE ] If a UPnP AV MediaServer implements the query content name record class, then it
shall respond with the value of “OBJECT.RECORDSCHEDULE.QUERY.CONTENTNAME” to the
SRS:GetAllowedValues action for the srs:class property when the input parameter DataTypeID is
the value A_ARG_TYPE_RecordScheduleParts or A_ARG_TYPE_RecordSchedule.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC YXJ47

29341-4-14

10.3.12.3
[G UIDELINE ] If a UPnP AV MediaServer indicates support for the query content name record class
as defined in guideline requirement 10.3.12.2, then a UPnP AV MediaServer shall respond to the
SRS:GetAllowedValues action for the srs:matchingName property when the input parameter
DataTypeID contains the value A_ARG_TYPE_RecordScheduleParts or
A_ARG_TYPE_RecordSchedule with the following:

• A value of “<allowAny></allowAny>”
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC ZVPQ5

29341-4-14

10.3.12.4
[G UIDELINE ] If a UPnP AV MediaServer indicates support for the query content name record class
as defined in guideline requirement 10.3.12.2, then a UPnP AV MediaServer shall respond to the
SRS:GetAllowedValues action for the srs:matchingName@type property when the input parameter
DataTypeID contains the value A_ARG_TYPE_RecordScheduleParts or
A_ARG_TYPE_RecordSchedule with at least one of the following:

• A value of “PROGRAM”
• A value of “SERIES”
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC RCX7F

29341-4-14

10.3.12.5
[G UIDELINE ] A UPnP AV MediaServer should set the value of the dc:title property in the recorded
content CDS item with the title of the program recorded, when all of the following conditions are met.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 388 –

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC TZUF6

29341-4-12

[C OMMENT] For the OBJECT.RECORDSCHEDULE.QUERY.CONTENTNAME record class, the

existence of the name of the program depends on the external databases (like Service Information)
and it might not be available in a CDS item.

This guideline requirement is semantically equivalent to guideline requirement 10.3.13.5 for the
Query Content ID record class.

10.3.13 MM/SR query content ID record class

10.3.13.1
[G ENERAL ] This defines the requirements for a UPnP AV MediaServer when implementing the
optional query contentID record class for the ScheduledRecording Service.

10.3.13.2
[G UIDELINE ] If a UPnP AV MediaServer implements the query content ID record class, then it shall
respond with the value of “OBJECT.RECORDSCHEDULE.QUERY.CONTENTID” to the
SRS:GetAllowedValues action for the srs:class property when the input parameter DataTypeID is
the value A_ARG_TYPE_RecordScheduleParts or A_ARG_TYPE_RecordSchedule.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC GTDQA

29341-4-14

10.3.13.3
[G UIDELINE ] If a UPnP AV MediaServer indicates support for the query content ID record class as
defined in guideline requirement 10.3.13.2, then a UPnP AV MediaServer shall respond to the
SRS:GetAllowedValues action for the srs:matchingID property when the input parameter
DataTypeID contains the value A_ARG_TYPE_RecordScheduleParts or
A_ARG_TYPE_RecordSchedule with the following:

• A value of “<allowAny></allowAny>”
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC L8ZJP

29341-4-14

10.3.13.4
[G UIDELINE ] If a UPnP AV MediaServer indicates support for the query content name record class
as defined in guideline requirement 10.3.13.2, then a UPnP AV MediaServer shall respond to the
SRS:GetAllowedValues action for the srs:matchingID@type property when the input parameter
DataTypeID contains the value A_ARG_TYPE_RecordScheduleParts or
A_ARG_TYPE_RecordSchedule with at least one of the following:

• A value of “SI_PROGRAMID”
• A value of “SI_SERIESID”
[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC G5O6J

29341-4-14

DLNA guidelines; Part 1-1: Architecture and protocols

 – 389 –

10.3.13.5
[G UIDELINE ] A UPnP AV MediaServer should set the value of the dc:title property in the recorded
content CDS item with the title of the program recorded, when all of the following conditions are met.

• The UPnP AV MediaServer exposes recorded content in a ContentDirectory service.

• The recorded content is a result of the execution of a recordTask.
[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 23T7R

29341-4-12

[C OMMENT] For the OBJECT.RECORDSCHEDULE.QUERY.CONTENTID record class, the

existence of the name of the program depends on the external databases (like Service Information),
and it might not be available in a CDS item.

w) This guideline is semantically equivalent to guideline 10.3.12.5 for the Query Content Name
record class.
10.3.14 MM/SR query record class and EPG
10.3.14.1
[G ENERAL ] This defines the guidelines for a UPnP AV MediaServer when implementing the
optional query contentName or contentID record classes and its interaction with the EPG Server
Device Option.

10.3.14.2
[G UIDELINE ] If a UPnP AV MediaServer implements the query contentName or query contentID
record class as defined in guideline requirements 10.3.12 and 10.3.13 respectively, then it should
implement the EPG Server Device Option, as defined 10.5.2.3, by including a <Feature> element
with the Feature@name attribute equal to “EPG” in the FeatureList output argument in response to
the CDS:GetFeatureList action

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC CIZ2D

29341-4-12
ISO/IEC
29341-4-14

[C OMMENT] It is also possible for a UPnP AV MediaServer to have internally maintained EPG
information that is not exposed by the CDS. In such a case this <Feature> element is not used.

10.3.14.3
[G UIDELINE ] If a UPnP AV MediaServer implements the EPG Server Device Option as defined in
10.3.14.2 and returns the value of “PROGRAM” in the response to the SRS:GetAllowedValues
action for the srs:matchingName@type property as defined in 10.3.12.4, then it should expose the
upnp:programTitle property for one or more current or future EPG Program Items.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 6KBDC

29341-4-14

[C OMMENT] The object.recordSchedule.query.ContentName recording class requires a Series or

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 390 –

Program Title as the match string input. The query is done by matching the upnp:programTitle
property, and that there is no way a matching EPG program item would be found if the property is
not exposed. Hence, it is strongly recommended that upnp:programTitle property be exposed.

10.3.14.4
[G UIDELINE ] If a UPnP AV MediaServer implements the EPG Server Device Option as defined in
10.3.14.2 and returns the value of “SERIES” in the response to the SRS:GetAllowedValues action
for the srs:matchingName@type property as defined in 10.3.12.4, then it should expose the
upnp:seriesTitle property for one or more current or future EPG Program Items.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC IQ7RP

29341-4-14

[C OMMENT] The object.recordSchedule.query.ContentName recording class requires a Series or

Program Title as the match string input. The query is done by matching the upnp:seriesTitle
property, and that there is no way a matching EPG program item would be found if the property is
not exposed. Hence, it is strongly recommended that upnp:seriesTitle property is exposed as
specified in this guideline.

10.3.14.5
[G UIDELINE ] If a UPnP AV MediaServer implements the EPG Server Device Option as defined in
10.3.14.2 and returns the value of “SI_PROGRAMID” in the response to the SRS:GetAllowedValues
action for the srs:matchingID@type property as defined in 10.3.13.4, then it should expose the
upnp:programID property for one or more current or future EPG Program Items.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC SBZCD

29341-4-14

[C OMMENT] The object.recordSchedule.query.ContentID recording class requires a Series or

Program ID as the match string input. The query is done by matching the upnp:programID property,
and that there is no way a matching EPG program item would be found if the property is not exposed.
Hence, it is strongly recommended that upnp:programID property is exposed as specified in this
guideline.

10.3.14.6
[G UIDELINE ] If a UPnP AV MediaServer implements the EPG Server Device Option as defined in
10.3.14.2 and returns the value of “SI_SERIESID” in the response to the SRS:GetAllowValues
action for the srs:matchingID@type property as defined 10.3.13.4, then it should expose the
upnp:seriesID property for one or more current or future EPG Program Items.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC SETOI

29341-4-14

[C OMMENT] The object.recordSchedule.query.ContentID recording class requires a Series or

Program ID as the match string input. The query is done by matching the upnp:SeriesID property,
and that there is no way a matching EPG program item would be found if the property is not exposed.
Hence, it is strongly recommended that upnp:seriesID property is exposed as specified in this
guideline.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 391 –

10.3.15 MM/SR conflict resolution

10.3.15.1
[G ENERAL ] This describes the general guidelines for supporting Conflict Resolution.

10.3.15.2
[G UIDELINE ] If a UPnP AV MediaServer allows the ScheduledRecording control points to resolve
conflicts, then it shall use the <dlna:X_DLNACAP> element (as a child of the <device> element that
represents the UPnP AV MediaServer) in the device description document and include the
Capability ID “srs-conflict-resolution” in the element's comma-separated value list.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 48KL9

29341-4-14

[C OMMENT] DMS devices use the <dlna:X_DLNACAP> element to indicate support for SRS conflict
resolution operation. The element is a comma separated value list that indicates whether the DMS
can resolve schedule conflicts, receive uploads of images, audio-only, or audio/video content, etc.
See guideline 9.2.35.1 for the formal syntax of the <dlna:X_DLNACAP> element. A sample
description is given below.

<dlna:X_DLNACAP
xmlns:dlna="urn:schemas-dlna-org:device-1-0">image-upload,audio-upload,srs-conflict-res
olution,srs-cr-partial-recording</dlna:X_DLNACAP>

10.3.15.3
[G UIDELINE ] A UPnP AV MediaServer shall implement the SRS:GetRecordScheduleConflicts and
SRS:GetRecordTaskConflicts actions.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 625J2

29341-4-14

[C OMMENT] Since there is guideline 10.3.16.7 that mandates the creation of conflicting
recordSchedule(s), the UPnP AV MediaServer needs to implement these two actions.

10.3.15.4
[G UIDELINE ] If a UPnP AV Media Server contains the value of “srs-conflict-resolution” in the
<dlna:X_DLNACAP> then it shall implement the following actions:

• SRS:EnableRecordSchedule;
• SRS:DisableRecordSchedule;
• SRS:DeleteRecordTask;
• SRS:EnableRecordTask;
• SRS:DisableRecordTask;
• SRS:ResetRecordTask.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC J3E9B

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 392 –

29341-4-14

10.3.15.5
[G UIDELINE ] A UPnP AV MediaServer should enable partial recording of a conflict loser
recordTask for the duration that is not conflicting with any other recordTask or a program winner for
that duration.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 8RV4U

29341-4-14

[C OMMENT] A UPnP AV MediaServer should record the portions of the programs described in the
shaded regions in Figure 17.

Figure 17 – Recording conflict behavior

10.3.15.6
[G UIDELINE ] If a UPnP AV MediaServer allows partial recordings as described in 10.3.15.5, then it
shall use the <dlna:X_DLNACAP> element (as a child of the <device> element that represents the
UPnP AV MediaServer) in the device description document and include the Capability ID
“srs-cr-partial-recording” in the element's comma-separated value list.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 3DN2V

29341-4-14

[C OMMENT] Partial recordings can also result from other reasons, such as for example,
SRS:DisableRecordTask or SRS:DeleteRecordTask actions on a recordTask that is in “ACTIVE”
state. Those are not covered by this attribute.

DMS devices use the <dlna:X_DLNACAP> element to indicate support for SRS partial recording
operation. The element is a comma separated value list that indicates whether the DMS can create
partial recordings, receive uploads of images, audio-only, or audio/video content, etc. See guideline
9.2.35.1 for the formal syntax of the <dlna:X_DLNACAP> element. A sample description is given
below.

<dlna:X_DLNACAP
xmlns:dlna="urn:schemas-dlna-org:device-1-0">image-upload,audio-upload,srs-conflict-
resolution,srs-cr-partial-recording</dlna:X_DLNACAP>

DLNA guidelines; Part 1-1: Architecture and protocols

 – 393 –

10.3.15.7
[G UIDELINE ] A UPnP AV MediaServer that includes a value of “srs-conflict-resolution” in the
<dlna:X_DLNACAP> shall implement and expose the property srs:priority@orderedValue.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC SSUI7

29341-4-14

10.3.15.8
[G UIDELINE ] When a UPnP AV MediaServer creates or modifies a recordTask and if that results in
conflict(s) with one or more recordTask(s), then the UPnP AV MediaServer should add the value
402 (Conflicting Program Winner) to the winning recordTask’s srs:taskState@infoList property.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC VHRPT

29341-4-14

10.3.15.9
[G UIDELINE ] If a UPnP AV Media Server creates or modifies a recordTask and if that results in
conflict(s) with one or more recordTask(s), then the UPnP AV MediaServer shall add the value 401
(Conflicting Program Loser) to the srs:taskState@pendingErrors property of each of the losing
recordTask(s). In addition, for each of the recordTask(s) that will be partially recorded, the UPnP AV
MediaServer that includes “srs-cr-partial-recording” in <dlna:X_DLNACAP> shall add the value 450
(DLNA Conflicting Partial Program Loser) to the srs:taskState@infoList property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 4HIEY

29341-4-14

10.3.15.10
[G UIDELINE ] When a UPnP AV MediaServer creates or modifies a recordTask and if that causes
one or more active recordTask(s) to be stopped or suspended due to the conflict, then for each of
those recordTask(s) the UPnP AV MediaServer shall add the value 401 (Conflicting Program Loser)
to the srs:taskState@currentErrors property. In addition, for each of the recordTask(s) that will be
partially recorded, the UPnP AV MediaServer that includes “srs-cr-partial-recording” in
<dlna:X_DLNACAP> shall add the value 450 (DLNA Conflicting Partial Program Loser) to the
srs:taskState@infoList property.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC MOWUH

29341-4-14

10.3.15.11
[G UIDELINE ] If a UPnP AV MediaServer creates or modifies a recordSchedule, it should create
recordTask object(s) from the point it has all the necessary information in a reasonable time.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC HLLHB

29341-4-14

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 394 –

10.3.16 MM/SR SRS:CreateRecordSchedule action

10.3.16.1
[G UIDELINE ] If a UPnP AV MediaServer control point sends a SRS:CreateRecordSchedule request
where the Elements input argument has the srs:class property with a value of
“OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG” or
“OBJECT.RECORDSCHEDULE.DIRECT.CDSEPG”, then the srs:scheduledCDSObjectID property
value shall contain the @id value for a CDS item with the upnp:recordable property value of “1”.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC NPXUH

29341-4-14

[C OMMENT] The CDS object id values used to create a recordSchedule for either the cdsNonEPG
or cdsEPG record classes needs to have the upnp:recordable property set to “1”.

10.3.16.2
[G UIDELINE ] If a UPnP AV MediaServer control point sends a SRS:CreateRecordSchedule request
where the Elements input argument has the srs:class property with a value of
“OBJECT.RECORDSCHEDULE.DIRECT.MANUAL”, then the srs:scheduledChannelID property
value shall contain the upnp:channelID property value for a CDS item with the upnp:recordable
property value of “1”.

[ATTRIBUTES ]

M C +SR+ n/a n/a ISO/IEC Y75P3

29341-4-14

[C OMMENT] The channelID values used to create a recordSchedule for the manual record class
needs to have the upnp:recordable property set to “1”.

10.3.16.3
[G UIDELINE ] A UPnP AV MediaServer ScheduledRecording service shall return a success
response to a SRS:CreateRecordSchedule request when the Elements input argument satisfies the
following conditions.

• srs:class property has a value of "OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG" or

“OBJECT.RECORDSCHEDULE.DIRECT.CDSEPG”.
• There exists a CDS object which meets the following criteria:
– the @id property is equal to the srs:scheduledCDSObjectID property value of the request;
– the upnp:recordable property has a value of “1”.
This guideline only applies when other error conditions are not satisfied (e.g. syntax errors,
resource constraints, or content recording permissions).

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC SO5WC

29341-4-14

10.3.16.4
[G UIDELINE ] A UPnP AV MediaServer ScheduledRecording service shall return a success
response to a SRS:CreateRecordSchedule request when the Elements input argument satisfies the
following conditions.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 395 –

• srs:class property has a value of OBJECT.RECORDSCHEDULE.DIRECT.MANUAL".

• There exists a CDS object which meets the following criteria:
– the @id property is equal to the srs:scheduledCDSObjectID property value of the request;
– the upnp:recordable property has a value of “1”.
This guideline only applies when other error conditions are not satisfied (e.g. syntax errors,
resource constraints, or content recording permissions).

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC ONPRA

29341-4-14

10.3.16.5
[G UIDELINE ] If a UPnP AV MediaServer receives a SRS:CreateRecordSchedule action in which
the Elements input argument is consistent with the set of allowed values returned by the
SRS:GetAllowedValues action, then it may respond with 703 (Invalid Value) to indicate that the
UPnP AV MediaServer is unable to create a recordSchedule using the requested input values.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC NCQ8F

29341-4-14

[C OMMENT] The allowed values description returned by the SRS:GetAllowedValues action is static
and does not reflect the internal real time constraints of the UPnP AV MediaServer. The UPnP AV
Datastructure Template (AVDT) description cannot completely describe the semantics of a property.
A UPnP AV MediaServer and a ScheduledRecording control point need to understand this
limitation.

10.3.16.6
[G UIDELINE ] If a UPnP AV MediaServer responds to a SRS:CreateRecordSchedule request with a
UPnP AV error code, then the UPnP AV MediaServer should use a localized, human-readable error
message in the <errorDescription> element of the SOAP response.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC QCK4X

29341-4-14

[C OMMENT] The Elements input argument is an XML document and complex. Error description is
helpful to identify which property generated the error response.

10.3.16.7
[G UIDELINE ] A UPnP AV MediaServer shall not respond to SRS:CreateRecordSchedule request
with 730 (Conflict).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC DZFPW

29341-4-14

[C OMMENT] DLNA requires a UPnP AV MediaServer to always create a recordSchedule even in

the event of a conflict.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 396 –

10.3.16.8
[G UIDELINE ] A UPnP AV MediaServer shall create a new recordSchedule and its associated
recordTask(s) as per UPnP SRS priority model 2.8 of [ISO/IEC 29341-4-14].

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 4W7K9

29341-4-14

10.3.16.9
[G UIDELINE ] If a UPnP AV MediaServer implements the srs:priority@orderedValue, then it shall
implement the additional priority model as described in the UPnP SRS priority model for
orderedPriority in 2.8.2 of [ISO/IEC 29341-4-14].

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC EHZ4X

29341-4-14

10.3.16.10
[G UIDELINE ] If a UPnP AV MediaServer creates a recordSchedule in response to a
SRS:CreateRecordSchedule request, it shall set new conflict winning and losing recordTask(s) as
per UPnP priority model.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC YR2SY

29341-4-14

[C OMMENT] The identification of the newly set conflict winning and losing recordTask(s) are
described in guideline requirements 10.3.15.3 and 10.3.15.4.

10.3.17 MM/SR adjustment of property values for a recordSchedule or recordTask

10.3.17.1
[G ENERAL ] This defines the guidelines for a UPnP AV MediaServer when the UPnP AV
MediaServer adjusts a recordSchedule or recordTask due to the device specific reasons.

10.3.17.2
[G UIDELINE ] If a UPnP AV MediaServer creates a recordSchedule in response to the
SRS:CreateRecordSchedule request, then any supported properties specified in the Elements input
argument shall have the same values in the Result output argument.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC OSGDD

29341-4-14

[C OMMENT] This guideline reiterates the behavior described in 2.6.7.1.3 of ISO/IEC 29341-4-14.

10.3.17.3
[G UIDELINE ] A UPnP AV MediaServer may adjust the values of the following properties of the
recordSchedule:

• srs:scheduledStartDateTime

DLNA guidelines; Part 1-1: Architecture and protocols

 – 397 –

• srs:scheduledDuration
after the UPnP AV MediaServer response to the SRS:CreateRecordSchedule request has been
sent and a recordSchedule object has been created by the UPnP AV MediaServer.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC 6FRXA

29341-4-14

[C OMMENT] As described in 2.4.4 of ISO/IEC 29341-4-14, the SRS.StateUpdateID state variable is

incremented when a recordSchedule or recordTask is modified. The reasons of the object
modification are not restricted only to any ScheduledRecording service action invocations. A
ScheduledRecording control point needs to monitor the changes via the SRS.StateUpdateID state
variable or the SRS.LastChange evented state variable.

10.3.17.4
[G UIDELINE ] If a UPnP AV MediaServer adjusts the srs:scheduledStateDateTime or
srs:scheduledDuration property values as defined in 10.3.17.3, then any adjustment shall be by a
maximum of one minute.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC BZOPF

29341-4-14

10.3.17.5
[G UIDELINE ] A UPnP AV MediaServer may adjust the value of the following properties of a
recordTask to a value that is different from that of the parent recordSchedule object.

• srs:taskStartDateTime
• srs:taskDuration
[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC 84MAY

29341-4-14

[C OMMENT] As described in 2.4.4 of ISO/IEC 29341-4-14, the SRS.StateUpdateID state variable is

incremented when a recordSchedule or recordTask is modified. The reasons of the object
modification are not restricted only to any ScheduledRecording service action invocations. A
ScheduledRecording control point needs to monitor the changes via the SRS.StateUpdateID state
variable or the SRS.LastChange evented state variable.

10.3.17.6
[G UIDELINE ] If a UPnP AV MediaServer creates a recorded content based on a recordTask and
succeeds the recording of the recordTask, then the actual recorded start date and time and duration
of the recorded content (i.e. upnp:recordedStartDateTime and upnp:recordedDuration properties of
the resulting CDS object) may be different from the actual scheduled start date and time and
duration (i.e. srs:taskStartDateTime and srs:taskDuration properties) of the recordTask.

[ATTRIBUTES ]

O C DMS M-DMS n/a ISO/IEC MZOBH

29341-4-14

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 398 –

[C OMMENT] As described in 2.2.2.22 and 2.2.2.25 of ISO/IEC 29341-4-14, the actual start date and
time and duration of the recordTask may include any device specific latencies of record startup
and/or teardown. A ScheduledRecording control point may not be able to retrieve the latencies from
any properties of the recordTask.

10.3.17.7
[G UIDELINE ] A UPnP AV MediaServer should start the recording at or before the value of
srs:taskStartDateTime of a recordTask and should stop the recording at or after the scheduled end
time of the recordTask.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC KTCGR

29341-4-14

[C OMMENT] The scheduled end time of the recordTask is the result of combination of
srs:taskStartDateTime and srs:taskDuration of the recordTask.

10.3.18 MM/SR SRS:GetPropertyList action

[G UIDELINE ] If a UPnP AV MediaServer includes the value of “srs-conflict-resolution” in the
<dlna:X_DLNACAP>, then it shall include the property srs:priority@orderedValue in the
PropertyList output argument in response to a SRS:GetPropertyList request.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC TUOEG

29341-4-14

10.3.19 MM/SR SRS:DeleteRecordSchedule action

10.3.19.1
[G UIDELINE ] If a UPnP AV MediaServer that includes the value of “srs-conflict-resolution” in the
<dlna:X_DLNACAP> cannot ensure that all the intended recordTask(s) are deleted within 27 s in
response to the SRS:DeleteRecordSchedule request then it shall respond with 720 (cannot process
the request).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC GO7PJ

29341-4-14

[C OMMENT] A UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5), so in
order to have a consistent behavior, the UPnP AV MediaServer needs to return this error within
27 s.

10.3.19.2
[G UIDELINE ] If a UPnP AV MediaServer that does not include the value of “srs-conflict-resolution”
in the <dlna:X_DLNACAP> cannot ensure that all the intended recordTask(s) are deleted within
27 s in response to the SRS:DeleteRecordSchedule request then it should respond with 720
(cannot process the request).

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 7A2UX

29341-4-14

DLNA guidelines; Part 1-1: Architecture and protocols

 – 399 –

UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5), so in order to have
a consistent behavior, the UPnP AV MediaServer needs to return this error within 27 s.

10.3.20 MMSR SRS:GetRecordSchedule action

[G UIDELINE ] If a UPnP AV MediaServer cannot process a SRS:GetRecordSchedule request within
27 s, then it shall respond with 720 (cannot process the request).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC MCWTT

29341-4-14

[C OMMENT] A UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5), so in
order to have a consistent behavior, the UPnP AV MediaServer needs to return this error within
27 s.

10.3.21 MM/SR SRS:EnableRecordSchedule action

[G UIDELINE ] If a UPnP AV MediaServer cannot ensure that the enabled recordTask(s) that resulted
from SRS:EnableRecordSchedule action, and are in “ACTIVE” phase, cannot start within 60 s, then
the SRS:EnableRecordSchedule action shall return with 720 (cannot process the request). The
UPnP AV MediaServer shall return this error within 27 s.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC KZXAY

29341-4-14

[C OMMENT] A UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5), so in
order to have a consistent behavior, the UPnP AV MediaServer needs to return this error within
27 s.

10.3.22 MM/SR SRS:DisableRecordSchedule action

[G UIDELINE ] If a UPnP AV MediaServer, in response to SRS:DisableRecordSchedule action,
cannot ensure that all the intended recordTask(s) are disabled within 27 s, then the
SRS:DisableRecordSchedule action shall fail with a return error code 720 (cannot process the
request).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC VH55K

29341-4-14

[C OMMENT] A UPnP AV MediaServer can take a long time to disable all intended recordTask(s),
but the UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5). So, in order
to ensure a consistent UPnP AV MediaServer behavior, a status response from the UPnP AV
MediaServer within 30 s is useful for the UPnP control point.

10.3.23 MM/SR SRS:GetRecordTask action

[G UIDELINE ] If a UPnP AV MediaServer cannot process SRS:GetRecordTask within 27 s, then the
SRS:GetRecordTask action shall fail with a return error code 720 (cannot process the request).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC VUU6G

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 400 –

29341-4-14

[C OMMENT] A UPnP control point may terminate the TCP connection after 30 s (see 9.2.9.5), so in
order to have a consistent behavior, the UPnP AV MediaServer needs to return this error within
27 s.

10.3.24 MM/SR SRS:EnableRecordTask action

[G UIDELINE ] If the target recordTask specified in the SRS:EnableRecordTask request is in the
“ACTIVE” phase and if the UPnP AV MediaServer cannot ensure that the enabled recording start
within 60 s, then the SRS:EnableRecordTask action shall return with error code 720 (cannot
process the request).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC A2QKT

29341-4-14

[C OMMENT] A UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5), so in
order to have a consistent behavior, the UPnP AV MediaServer needs to return this error within
27 s.

10.3.25 MM/SR SRS:ResetRecordTask action

[G UIDELINE ] If a UPnP AV MediaServer can not process SRS:ResetRecordTask request within
27 s, then this request shall return with error code 720 (cannot process the request).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC C787G

29341-4-14

[C OMMENT] A UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5), so in
order to have a consistent behavior, the UPnP AV MediaServer needs to return this error within
27 s.

10.3.26 MM/SR SRS:GetRecordScheduleConflicts action

[G UIDELINE ] If a UPnP AV MediaServer cannot process SRS:GetRecordScheduleConflicts request
within 27 s, then it shall respond with 720 (cannot process the request).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC 4SOLH

29341-4-14

[C OMMENT] A UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5), so in
order to have a consistent behavior, the UPnP AV MediaServer needs to return this error within
27 s.

10.3.27 MM/SR SRS:GetRecordTaskConflicts action

[G UIDELINE ] If a UPnP AV MediaServer cannot process SRS:GetRecordTaskConflicts request
within 27 s, then it shall respond with 720 (cannot process the request).

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC TWZDX

DLNA guidelines; Part 1-1: Architecture and protocols

 – 401 –

29341-4-14

[C OMMENT] A UPnP control point can terminate the TCP connection after 30 s (see 9.2.9.5), so in
order to have a consistent behavior, the UPnP AV MediaServer needs to return this error within
27 s.

10.3.28 MM/SR open-end recording

10.3.28.1
[G ENERAL ] This defines the guidelines for a UPnP AV MediaServer when an open-end recording is
requested by a ScheduledRecording control point. Duration of an “open-end” recording is
determined by the UPnP AV MediaServer.

10.3.28.2
[G UIDELINE ] A UPnP AV MediaServer may implement Open-end Recording.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 44YZR

29341-4-14

10.3.28.3
[G UIDELINE ] If a UPnP AV MediaServer implements Open-end Recording, then the UPnP AV
MediaServer shall implement Open-end Recording for at least one of the following record classes:

• OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG
• OBJECT.RECORDSCHEDULE.DIRECT.MANUAL
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC TV55X

29341-4-14

10.3.28.4
[G UIDELINE ] The UPnP AV MediaServer shall not implement Open-end Recording for record
classes other than the following:

• OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG
• OBJECT.RECORDSCHEDULE.DIRECT.MANUAL
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC D97BI

29341-4-14

10.3.28.5
[G UIDELINE ] If a UPnP AV MediaServer implements Open-end Recording, it shall include the value
of dlna:openDuration in response to the SRS:GetPropertyList action when the DataTypeID input
argument is the value A_ARG_TYPE_RecordScheduleParts, A_ARG_TYPE_RecordSchedule or
A_ARG_TYPE_RecordTask.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC KJSNG

29341-4-14

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 402 –

10.3.28.6
[G UIDELINE ] If a UPnP AV endpoint includes a dlna:openDuration element in
A_ARG_TYPE_RecordScheduleParts, A_ARG_TYPE_RecordSchedule and
A_ARG_TYPE_RecordTask, then it shall use the semantics and syntax as stated in Table 31.

Table 31 – dlna:openDuration Property Type and Multi Value

Property Name Property Type Multiple Value

dlna:openDuration xsd:boolean No

The value of dlna:openDuration element shall be one of the following. The default value is “0”.

• “1” when the recording is Open-end recording.

• “0” when the recording is not Open-end recording.
The prefix for dlna:openDuration shall be “dlna” and the namespace shall be
“urn:schemas-dlna-org:metadata-1-0/”.

[ATTRIBUTES ]

M A DMS +SR+ M-DMS n/a ISO/IEC IDGSQ

29341-4-14

10.3.28.7
[G UIDELINE ] If a UPnP AV MediaServer implements Open-end Recording, the UPnP AV
MediaServer shall respond to the SRS:GetAllowedValues action for the dlna:openDuration property
with the PropertyInfo output argument which contains an AVDT description for dlna:openDuration
that is consistent with guidelines 10.3.28.3, 10.3.28.4, and 10.3.28.6.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC YU6OF

29341-4-14

[C OMMENT] In case that the Open-end Recording is available for cdsNonEPG and manual class
recordings, the concrete examples of <field> element in the AVDT description are as follows:

When the DataTypeID input argument is the value A_ARG_TYPE_RecordScheduleParts,

<field>
<name>dlna:openDuration</name>
<dataType>xsd:boolean</dataType>
<allowedValueDescriptor>
<defaultValue>0</defaultValue>
<dependentField>
<name>srs:class</name>
<valueList>
<value>OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG</value>
<value>OBJECT.RECORDSCHEDULE.DIRECT.MANUAL</value>
</valueList>
</dependentField>
<allowedValueList>
<allowedValue>0</allowedValue>
<allowedValue>1</allowedValue>
</allowedValueList>

DLNA guidelines; Part 1-1: Architecture and protocols

 – 403 –

</allowedValueDescriptor>
</field>

When the DataTypeID input argument is the value A_ARG_TYPE_RecordSchedule,

<field>
<name>dlna:openDuration</name>
<dataType>xsd:boolean</dataType>
<allowedValueDescriptor>
<minCount>1</minCount>
<dependentField>
<name>srs:class</name>
<valueList>
<value>OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG</value>
<value>OBJECT.RECORDSCHEDULE.DIRECT.MANUAL</value>
</valueList>
</dependentField>
<allowedValueList>
<allowedValue>0</allowedValue>
<allowedValue>1</allowedValue>
</allowedValueList>
</allowedValueDescriptor>
</field>

When the DataTypeID input argument is the value A_ARG_TYPE_RecordTask,

<field>
<name>dlna:openDuration</name>
<dataType>xsd:boolean</dataType>
<allowedValueDescriptor>
<minCount>1</minCount>
<allowedValueList>
<allowedValue>0</allowedValue>
<allowedValue>1</allowedValue>
</allowedValueList>
</allowedValueDescriptor>
</field>

10.3.28.8
[G UIDELINE ] If a UPnP AV MediaServer control point creates a recordSchedule in which the
dlna:openDuration property has a value of “1” , then it shall specify “P00:00:00” as the value of the
srs:scheduledDuration element in the request of SRS:CreateRecordSchedule action.

[ATTRIBUTES ]

M A +SR+ n/a n/a ISO/IEC KKQRH

29341-4-14

[C OMMENT] ISO/IEC 29341-4-14 requires a ScheduledRecording control point to always specify a

value for the srs:scheduledDuration property when creating a cdsNonEPG or manual record class
recordSchedule. This guideline defines the value to be used in the request when an Open-end
Recording is desired.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 404 –

10.3.28.9
[G UIDELINE ] If a UPnP AV MediaServer implements Open-end Recording, the UPnP AV
MediaServer shall return a success response to a SRS:CreateRecordSchedule request when the
Elements input argument satisfies the following conditions.

• srs:class property has a value of "OBJECT.RECORDSCHEDULE.DIRECT.CDSNONEPG" or

"OBJECT.RECORDSCHEDULE.DIRECT.MANUAL".
• srs:scheduledDuration has a value of “P00:00:00”.
• dlna:openDuration property has a value of “1”.
This guideline only applies when error conditions are not satisfied (e.g. syntax errors, resource
constraints, or content recording permissions).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VCTAV

29341-4-14

10.3.28.10
[G UIDELINE ] If a UPnP AV MediaServer creates a recordTask based on a recordSchedule in which
the dlna:openDuration property has a value of “1”, the value of srs:taskDuration property of the
recordTask shall be “P00:00:00” until the UPnP AV MediaServer determines the exact duration.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC JPYH6

29341-4-14

10.3.29 MM/SR media format specified recording

10.3.29.1
[G ENERAL ] This contains guidelines which define the optional media format specified recording
scheme using a DLNA Media Format Profile.

10.3.29.2
[G UIDELINE ] A UPnP AV MediaServer may accept dlna:desiredPN as an element in
A_ARG_TYPE_RecordScheduleParts for media format specified recording. The semantics and
syntax of dlna:desiredPN element is defined in 10.3.29.4.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 4L8AD

29341-4-14

[C OMMENT] DLNA introduces optional media format specified recording mechanism in this
requirement. If a UPnP AV MediaServer control point uses this mechanism, then it can improve the
playback of the recorded contents with its supported DLNA Media Format Profile.

10.3.29.3
[G UIDELINE ] If a UPnP AV MediaServer accepts dlna:desiredPN element in
A_ARG_TYPE_RecordScheduleParts, then it shall implement dlna:PN as an element in
A_ARG_TYPE_RecordTask state variable for media format specified recording. The semantics and
syntax of dlna:PN element is defined in 10.3.29.6.

[ATTRIBUTES ]

DLNA guidelines; Part 1-1: Architecture and protocols

 – 405 –

M A DMS M-DMS n/a ISO/IEC LESSU

29341-4-14

10.3.29.4
[G UIDELINE ] If a UPnP AV MediaServer or UPnP AV MediaServer control point includes a
dlna:desiredPN element in A_ARG_TYPE_RecordScheduleParts, A_ARG_TYPE_RecordSchedule
or A_ARG_TYPE_RecordTask, then it shall use the following semantics and syntax.

The syntax definition of dlna:desiredPN element shall be as stated in Table 32.

Table 32 – dlna:desiredPN property type and multi value

Property name Property type Multiple value

dlna:desiredPN CSV(String) No

The value of dlna:desiredPN element shall be one of the following.

• One DLNA Media Format Profile.

• “AUTO” (This meaning is that the UPnP AV MediaServer is free to use any DLNA Media Format
Profiles.).
• One CSV list which includes “AUTO” and/or DLNA Media Format Profile(s).
If the value of dlna:desiredPN is a CSV list, then the DLNA Media Format Profiles in the CSV list
shall be ordered in the preferred formats for the recording, where the first format is the most
preferred. If “AUTO” is included in the list, it shall appear as the last value in the list and it indicates
that if none of the preceding values are available, then the UPnP AV MediaServer is free to use any
DLNA Media Format Profiles to maximize the probability that the recording actually takes place.

In addition, the DLNA Media Format Profile shall omit the DLNA Link Protection prefix, e.g. “DTCP_”
for DTCP-IP and “WMDRM_” for WMDRM-ND.

The prefix for dlna:desiredPN shall be "dlna" and the namespace shall be
“urn:schemas-dlna-org:metadata-1-0/”.

[ATTRIBUTES ]

M A DMS +SR+ M-DMS n/a ISO/IEC T9VRU

29341-4-14

[C OMMENT] Example usages for dlna:desiredPN would be as follows:

• <dlna:desiredPN>MPEG_TS_JP_T</dlna:desiredPN>
• <dlna:desiredPN>AUTO</dlna:desiredPN>
• <dlna:desiredPN> MPEG_TS_JP_T,MPEG_PS_NTSC,AUTO</dlna:desiredPN>

10.3.29.5
[G UIDELINE ] A UPnP AV MediaServer shall accept the value “AUTO” for the dlna:desiredPN
element.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC XYGA5

29341-4-14

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 406 –

[C OMMENT] The value and semantics for “AUTO” needs to be implemented by a UPnP AV
MediaServer.

10.3.29.6
[G UIDELINE ] If a UPnP AV MediaServer includes a dlna:PN element in A_ARG_TYPE_RecordTask,
then it shall use the following semantics and syntax.

The syntax definition of a dlna:PN element shall be as stated in Table 33.

Table 33 – dlna:PN property type and multi value

Property name Property type Multiple value

dlna:PN String No

The value of dlna:PN element shall be one DLNA Media Format Profile which will be used the
recording. When the recordTask is in the “IDLE” phase, this property shall contain a best-known
estimate of DLNA Media Format Profile for the recording. When the recordTask is in the “ACTIVE”
or “DONE” phase, this property shall contain one of the DLNA Media Format Profiles supported by
the UPnP AV MediaServer for the actual recording.

In addition, the property value shall not include any profile that has the DLNA Link Protection prefix,
e.g. “DTCP_” for DTCP-IP and “WMDRM_” for WMDRM-ND.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 9K9SU

29341-4-14

[C OMMENT] “AUTO” is not allowed for the value of this element. An example usage for the dlna:PN
element would be as follows:

• <dlna:PN>MPEG_PS_NTSC</dlna:PN>

10.3.29.7
[G UIDELINE ] If a UPnP AV MediaServer control point does not specify DLNA Media Format
Profile(s), then it shall omit a dlna:desiredPN element or specify only “AUTO” as the value of the
dlna:desiredPN element in the request of SRS:CreateRecordSchedule action.

[ATTRIBUTES ]

M A +SR+ n/a n/a ISO/IEC FZIUX

29341-4-14

[C OMMENT] If a UPnP AV MediaServer control point omits a dlna:desiredPN element or specifies

only “AUTO” as the value of the dlna:desiredPN element, then the UPnP AV MediaServer is free to
select a DLNA Media Format Profile for the recording.

10.3.29.8
[G UIDELINE ] If a UPnP AV MediaServer control point requests to record a content using one DLNA
Media Format Profile from the CSV list of the dlna:desiredPN element, then it shall not include
“AUTO” in the CSV list of dlna:desiredPN element on the request of SRS:CreateRecordSchedule
action.

[ATTRIBUTES ]

DLNA guidelines; Part 1-1: Architecture and protocols

 – 407 –

M A +SR+ n/a n/a ISO/IEC JUP3C

29341-4-14

[C OMMENT] This guideline enables a UPnP AV MediaServer control point to request to record a
content using the DLNA Media Format Profile which it specified on the request of
SRS:CreateRecordSchedule action.

10.3.29.9
[G UIDELINE ] If a UPnP AV MediaServer accepts dlna:desiredPN element, then it shall create one
or more recordTask(s) with dlna:PN element regardless of whether the UPnP AV MediaServer
control point specifies the dlna:desiredPN element or not.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC ZI2N7

29341-4-14

[C OMMENT] A UPnP AV MediaServer control point can retrieve the selected DLNA Media Format
Profile for the recording via the response of SRS:BrowseRecordTasks action which has the dlna:PN
element in advance.

10.3.29.10
[G UIDELINE ] If a UPnP AV MediaServer accepts a dlna:desiredPN element, then it shall adhere to
the following rules for selecting a DLNA Media Format Profile for a dlna:PN element and a level of
recording quality for a srs:recordQuality element.

• If a UPnP AV MediaServer control point omits dlna:desiredPN element or specifies only “AUTO”
in the dlna:desiredPN element, then the UPnP AV MediaServer shall select the acceptable and
most preferable level of recording quality from CSV list of a srs:desiredRecordQuality element
and the corresponding DLNA Media Format Profile.
• If there are some acceptable combinations that the selected value of dlna:desiredPN is not
“AUTO”, then the UPnP AV MediaServer shall select the acceptable and the best combination of
level of recording quality from the CSV list of the srs:desiredRecordQuality element and DLNA
Media Format Profile from the CSV list of dlna:desiredPN element with an acceptable and most
preferable DLNA Media Format Profile.
• If a UPnP AV MediaServer control point doesn’t include “AUTO” in a dlna:desiredPN element
and there is no acceptable combination, then the UPnP AV MediaServer shall select the
acceptable and most preferable specified DLNA Media Format Profile from the CSV list of
a dlna:desiredPN element and the corresponding level of recording quality from CSV list of
srs:desiredRecordQuality.
• If a UPnP AV MediaServer control point omits a srs:desiredRecordQuality element or specifies
only “AUTO” in the srs:desiredRecordQuality element, then the UPnP AV MediaServer shall
select the acceptable and most preferable specified DLNA Media Format Profile from the CSV
list of a dlna:desiredPN element and the corresponding level of recording quality.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 73XFC

29341-4-14

[C OMMENT] This requirement for a UPnP AV MediaServer provides selection criteria of recording
quality and the DLNA Media Format Profile that a UPnP AV MediaServer control point specified.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 408 –

In this guideline, there are four criteria according to the following combination of specified recording
qualities and DLNA Media Format Profiles.

1. Only recording qualities are specified.

2. Both recording qualities and DLNA Media Format Profiles are specified
– A UPnP AV MediaServer will be able to record using one of the requested recording
qualities and one of the DLNA Media Format Profiles.
– A UPnP AV MediaServer will not be able to record using one of the requested recording
qualities and one of DLNA Media Format Profiles.
3. Only DLNA Media Format Profiles are specified.
4. If a UPnP AV MediaServer control point specifies DLNA Media Format Profiles, then the DLNA
Media Format Profiles take precedence of the recording qualities since the control point wants
to play back the recorded content with the specified DLNA Media Format Profiles. The timing of
the selection is vendor dependent.
10.3.29.11
[G UIDELINE ] If a UPnP AV MediaServer implements dlna:desiredPN property, it shall include the
value of dlna:desiredPN in response to the SRS:GetPropertyList action when the DataTypeID input
argument is the value A_ARG_TYPE_RecordScheduleParts, A_ARG_TYPE_RecordSchedule or
A_ARG_TYPE_RecordTask.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 36UYV

29341-4-14

10.3.29.12
[G UIDELINE ] If a UPnP AV MediaServer implements dlna:PN property, it shall include the value of
dlna:PN in response to the SRS:GetPropertyList action when the DataTypeID input argument is the
value A_ARG_TYPE_RecordTask.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC HWUAU

29341-4-14

10.3.29.13
[G UIDELINE ] If a UPnP AV MediaServer implements dlna:desiredPN property, then it shall respond
to the SRS:GetAllowedValues action for the dlna:desiredPN property with the PropertyInfo output
argument which contains an AVDT description for dlna:desiredPN that is consistent with guideline
10.3.29.4. The allowed values in the AVDT description shall be listed in order of quality from highest
quality to lowest. The value “AUTO” shall always be present and appear as the last item in the list.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC TKB45

29341-4-14

[C OMMENT] DLNA does not define the ordering of quality between DLNA Media Format Profiles.
The specific ordering is vendor-dependent, and is communicated through the AVDT description. For
example, if the vendor defines the ordering of the recording quality for DLNA Media Format Profiles
to be MPEG_TS_JP_T > MPEG_PS_NTSC and the DataTypeID input argument value is
A_ARG_TYPE_RecordScheduleParts, the concrete example of the AVDT description that adheres
to this requirement is as follows:

DLNA guidelines; Part 1-1: Architecture and protocols

 – 409 –

<?xml version="1.0" encoding="UTF-8"?>

<AVDT
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns="urn:schemas-upnp-org:av:avdt"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schemas-upnp-org:av:avdt
http://www.upnp.org/schemas/av/avdt-v1-20060531.xsd">
<contextID>
uuid:device-UUID::urn:schemas-upnp-org:service:ScheduledRecording:1
</contextID>
<dataStructType>A_ARG_TYPE_RecordScheduleParts</dataStructType>
<fieldTable>
<field>
<name>dlna:desiredPN</name>
<dataType csv="xsd:string" maxSize="256">xsd:string</dataType>
<maxListSizeTotal>UNBOUNDED</maxListSizeTotal>
<allowedValueDescriptor>
<defaultValue>AUTO</defaultValue>
<allowedValueList>
<allowedValue>MPEG_TS_JP_T</allowedValue>
<allowedValue>MPEG_PS_NTSC</allowedValue>
<allowedValue>AUTO</allowedValue>
</allowedValueList>
</allowedValueDescriptor>
</field>
</fieldTable>
</AVDT>

10.3.29.14
[G UIDELINE ] If a UPnP AV MediaServer implements dlna:PN property, then it shall respond to the
SRS:GetAllowedValues action for the dlna:PN property with the PropertyInfo output argument
which contains an AVDT description for dlna:PN that is consistent with guideline requirement
10.3.29.6. The allowed values in the AVDT description shall be listed in order of quality from highest
quality to lowest.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC ORUDT

29341-4-14

[C OMMENT] In case that the ordering of the recording quality of DLNA Media Format Profile is
MPEG_TS_JP_T > MPEG_PS_NTSC, the concrete example of the AVDT description that adheres
to this requirement is as follows:

<?xml version="1.0" encoding="UTF-8"?>

<AVDT
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns="urn:schemas-upnp-org:av:avdt"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schemas-upnp-org:av:avdt
http://www.upnp.org/schemas/av/avdt-v1-20060531.xsd">
<contextID>
uuid:device-UUID::urn:schemas-upnp-org:service:ScheduledRecording:1
</contextID>
<dataStructType>A_ARG_TYPE_RecordTask</dataStructType>
<fieldTable>
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 410 –

<field>
<name>dlna:PN</name>
<dataType maxSize="256">xsd:string</dataType>
<allowedValueDescriptor>
<minCount>1</minCount>
<allowedValueList>
<allowedValue>MPEG_TS_JP_T</allowedValue>
<allowedValue>MPEG_PS_NTSC</allowedValue>
</allowedValueList>
</allowedValueDescriptor>
</field>
</fieldTable>
</AVDT>

10.3.30 EPG, SRS, and CDS object lifespan guidelines

10.3.30.1 General
Subclause 10.3.30 defines the guidelines for a UPnP AV MediaServer when implementing the
optional EPG Server Device Option and the Scheduled Recording Device Option. It defines the
“lifespan” requirements for recordSchedule and recordTask of cdsEPG record class, CDS objects
generated by a recordTask, and EPG Program Items, see Figure 18.

T1 T2 8:00PM 9:00PM T3
epgItem and recordTask
will not be deleted
before the CDS item is
CDS epgItem available over the
network & metadata has
Channel been transferred

Lineup
CDS
Object
channelItem
**

SRS recordTask (and

recordSchedule)
Has <res> element
CDS item and mandatory metadata

Might not include <res> element or full metadata

EPG Item Program Program Program Program
comes in scope selected for Starts Ends Playback
recording

CDS Mandatory Lifespan Optional Lifespan SRS Mandatory Lifespan Optional Lifespan

Figure 18 – CDS and SRS object lifetimes

10.3.30.2 MM/SR EPG Program Items lifetime

10.3.30.2.1
[G UIDELINE ] An EPG Program Item shall exist until the upnp:scheduledEndTime.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 411 –

[ATTRIBUTES ]

M A DMS M-MDS n/a ISO/IEC VRL2U

29341-4-12

[C OMMENT] An EPG Program Item could be assumed to exist before the

upnp:scheduledStartTime.

10.3.30.2.2
[G UIDELINE ] If an EPG Program Item has a upnp:channelID property value which refers to a CDS
channel item, then the CDS channel item shall exist in a Tuner container.

[ATTRIBUTES ]

M A DMS M-MDS n/a ISO/IEC SPUWB

29341-4-12

10.3.30.3 MM/SR recordTask lifespan

10.3.30.3.1
[G ENERAL ] 10.3.30.3 defines the guidelines for a UPnP AV MediaServer when implementing the
Scheduled Recording Device Option. It defines the “lifespan” requirements for recordTask.

10.3.30.3.2
[G UIDELINE ] For the purposes of these guidelines, if the UPnP AV MediaServer does not expose
the recorded content in the CDS, then an SRS recordTask is considered “Completed” when the
srs:taskState property is set to one of the following values.

• DONE.FULL
• DONE.PARTIAL
• DONE.EMPTY
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 9SQV4

29341-4-14

[C OMMENT] This guideline defines the meaning of “Completed” for an SRS recordTask. The
completion of a recordTask is a key event for guidelines defining the lifespan of EPG, SRS, and
CDS objects.

10.3.30.3.3
[G UIDELINE ] For the purposes of these guidelines, if the UPnP AV MediaServer exposes the
recorded content in the CDS, an SRS recordTask is considered “Completed” when one of the
following two conditions are met.

• The srs:taskState property value is set to DONE.EMPTY.

• The srs:taskState property value is set to DONE.FULL or DONE.PARTIAL and
– the CDS object associated with the recordTask exists, and
– res property with a URI for streaming playback is available.
[ATTRIBUTES ]

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 412 –

M A DMS M-DMS n/a ISO/IEC U8MPL

29341-4-14

[C OMMENT] This guideline defines the meaning of “Completed” for an SRS recordTask. The
completion of a recordTask is a key event for guidelines defining the lifespan of EPG, SRS, and
CDS objects.

10.3.30.3.4
[G UIDELINE ] A UPnP AV MediaServer shall retain the recordTask object that is in “ACTIVE” phase
until the scheduled endtime of the recordTask, regardless of whether errors, conflicts, or other
conditions that allow the recordTask to complete successfully or not.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 4OZNM

29341-4-14

[C OMMENT] UPnP AV MediaServer control points need to retrieve the current status of a
recordTask via the SRS:BrowseRecordTasks action during the expected recording time.

10.3.30.3.5
[G UIDELINE ] When a UPnP AV MediaServer receives an SRS:DeleteRecordTask action on a
recordTask, it shall delete the recordTask object. This guideline overrides the guideline 10.3.30.3.4
for the SRS:DeleteRecordTask case.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 7OTK7

29341-4-14

10.3.30.3.6
[G UIDELINE ] A UPnP AV MediaServer shall retain a recordSchedule object until all its associated
recordTask objects have been deleted.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 84KL6

29341-4-14

[C OMMENT] A recordTask can only exist with a parent recordSchedule and when it is never
orphaned. The recordScheduleID property contains the value of the @id property of the
recordSchedule that generated the recordTask. A SRS:DeleteRecordSchedule action on a
recordSchedule object with one or more associated recordTask objects in the “ACTIVE” phase will
generate error 705.

10.3.30.3.7
[G UIDELINE ] A UPnP AV MediaServer should retain a recordTask after the associated recording is
completed, where “completed” is defined in 10.3.30.3.2 and 10.3.30.3.3.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC CT53F

29341-4-14

[C OMMENT] When a recordTask’s end time is reached (that is: the content is no longer available) or
DLNA guidelines; Part 1-1: Architecture and protocols
 – 413 –

a fatal error is detected, the associated recording finishes. If the UPnP AV MediaServer retains a
recordTask after the associated recording finishes, the srs:taskState@phase attribute of the
recordTask has the value of “DONE”. A recordTask in which the srs:taskState@phase attribute has
the value of “DONE” may have information about a recorded content and/or error(s). Some UPnP
AV MediaServers may not be able to retain a recordTask in which the srs:taskState@phase
attribute has the value of “DONE” due to the device specific reasons. Furthermore, some UPnP AV
MediaServers may not be able to retain a recordSchedule in which the srs:scheduleState property
has the value of “COMPLETED” due to the device specific reasons.

10.3.30.3.8
[G UIDELINE ] If a UPnP AV MediaServer always retains a recordTask which has the
srs:taskState@phase attribute with a value of “DONE”, then it shall use the <dlna:X_DLNACAP>
element (as a child of the <device> element that represents the UPnP AV MediaServer) in the
device description document and include the CapabilityID “srs-rt-done-retained” in the element’s
comma-separated value list. Conversely, if a UPnP AV MediaServer does not always retain a
recordTask which has the srs:taskState@phase attribute with a value of “DONE”, it shall not include
the Capability ID “srs-rt-done-retained” in the <dlna:X_DLNACAP> element’s comma-separated
value list in the device description document.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC EXKO4

29341-4-14

[C OMMENT] A UPnP MediaServer control point can understand that it may be able to retrieve the
result of a recordTask in the UPnP AV MediaServer.

10.3.30.3.9
[G UIDELINE ] If a UPnP AV MediaServer can always indicate the unsuccessful completion of a
recordTask by retaining the recordTask after the srs:scheduledEndDateTime, then it shall use the
<dlna:X_DLNACAP> element 9.2.35.1 in the device description document and include the
Capability ID “srs-rt-can-report-unsuccessful-completion” in the element’s comma-separated value
list.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 8NYC7

29341-4-14

10.3.30.3.10
[G UIDELINE ] If a UPnP AV MediaServer always retains a recordTask as per 10.3.30.3.8 or
10.3.30.3.9 then it shall use the <dlna:X_DLNACAP> element (as a child of the <device> element
that represents the UPnP AV MediaServer) in the device description document and include the
capability ID and its value in the element’s comma-separated value list in the format
“srs-rt-retention-period-duration” where “srs-rt-retention-period-” is a literal string. The duration
portion shall be a ui4 value or “infinity”, indicating the number of seconds the recordTask is retained
by the device after the recording is completed or aborted. The duration portion cannot be zero.

More formally, the syntax of the capability ID is defined in Table 34.

Table 34 – Capability ID syntax

Capability ID Description
srs-rt-retention-period-duration The UPnP AV MediaServer supports retaining
recordTask for a specific duration after “ACTIVE” state.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 414 –

• srs- retention- capability-id = “srs-rt-retention-period-” duration

• duration = <ui4 value> | “infinity”
• The “srs-rt-retention-period-” is a literal.
The duration shall have a non-zero ui4 value or the literal “infinity”. If it is ui4 value, then it represents the number
of seconds the recordTask will be retained by the device. The literal “infinity” represents that the device will retain
the recordTask until it is explicitly deleted.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC CJ6IL

29341-4-14

[C OMMENT] AV MediaServer devices use the <dlna:X_DLNACAP> element to indicate to control

points their recordTask retention periods. See guideline 9.2.35.1 for the formal syntax of the
<dlna:X_DLNACAP> element. Sample descriptions are given below.

<dlna:X_DLNACAP xmlns:dlna="urn:schemas-dlna-org:device-1-0">
srs-rt-retention-period-100
</dlna:X_DLNACAP>

<dlna:X_DLNACAP xmlns:dlna="urn:schemas-dlna-org:device-1-0">
srs-rt-retention-period-128
</dlna:X_DLNACAP>

<dlna:X_DLNACAP xmlns:dlna="urn:schemas-dlna-org:device-1-0">
srs-rt-retention-period-infinity
</dlna:X_DLNACAP>

10.3.30.3.11
[G UIDELINE ] If a UPnP AV MediaServer returns a <Feature> element in response to the
CDS:GetFeatureList request with the Feature@name attribute set to a value of
“DLNA.ORG_SRS_CONTENT”, then it should implement srs:recordedCDSObjectID property for
recordTask(s).

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC 6VDID

29341-4-14

[C OMMENT] This guideline is a clarification that a recordTask is able to have a

srs:recordedCDSObjectID property value.

10.3.30.3.12
[G UIDELINE ] If a UPnP AV MediaServer returns a <Feature> element in response to the
CDS:GetFeatureList request with the Feature@name attribute set to a value of
“DLNA.ORG_SRS_CONTENT”, and the srs:recordedCDSObjectID property of a recordTask exists,
then the srs:recordedCDSObjectID property shall have the value of the @id property of a CDS
object which exists in the CDS and represents the content recorded by the recordTask.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC CHAAK

29341-4-14

DLNA guidelines; Part 1-1: Architecture and protocols

 – 415 –

10.3.30.3.13
[G UIDELINE ] If a UPnP AV MediaServer returns a <Feature> element in response to the
CDS:GetFeatureList request with the Feature@name attribute set to a value of
“DLNA.ORG_SRS_CONTENT”, and the srs:recordedCDSObjectID property of a recordTask exists,
then the value of srs:recordedCDSObjectID property of a recordTask should be set in 27 s after the
recordTask is created.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC MDYI4

29341-4-14

[C OMMENT] It is recommended to create the srs:recordedCDSObjectID as early as possible

(possibly before the recording starts) so that it can be tracked. However it is possible for some
implementations to set this property after the recording is complete.

10.3.30.3.14
[G UIDELINE ] A UPnP AV MediaServer may change the values of the srs:taskStartDateTime and/or
srs:taskDuration properties of a recordTask due to the updates of the associated program
information in the device internal program information source in the case of cdsEPG record class.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC PT2EL

29341-4-14

[C OMMENT] A ScheduledRecording control point may be able to know the occurrence of changes
via the event notifications.

10.4 Extended Tuner media management guidelines

10.4.1 General
The Basic Tuner guidelines were based on initial version of the DLNA interoperability guidelines and
were not based on the UPnP TUNER feature. DLNA is aligning devices that implement to UPnP AV
MediaServer:2 and above to implement the UPnP TUNER feature.

The UPnP TUNER feature allows UPnP AV MediaServers to implement one or more tuner
containers and each of these container’s CDS object ids as listed in the UPnP TUNER feature. In
the DLNA Extended Tuner these tuner containers are modeled as Channel Lineup Containers,
Presets Containers, and Virtual Tuner Containers. An Extended Tuner will contain at least one
Channel Lineup Container. The Presets Container and Virtual Tuner Containers are optional. Figure
19 illustrates an Extended Tuner and its containers.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 416 –

Figure 19 – Extended Tuner and its containers

10.4.2 MM/ET Extended Tuner guidelines

10.4.2.1
[G UIDELINE ] A UPnP AV MediaServer that implements to ISO/IEC 29341-4-3 may implement an
Extended Tuner.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC UCVFO

29341-4-3

[C OMMENT] Implementation of the DLNA Extended Tuner guidelines is optional in DLNA.

10.4.2.2
[G UIDELINE ] If a UPnP AV MediaServer implements the EPG Server Device Option, as defined in
10.5.2.3, by including a <Feature> element with the Feature@name attribute equal to “EPG” in the
FeatureList output argument in response to the CDS:GetFeatureList action and the
ScheduledRecording Device Option, then it shall implement an Extended Tuner.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC MNH6T

29341-4-3

[C OMMENT] Implementation of the DLNA Extended Tuner guidelines is mandated when

implementing both the ScheduedRecording Device Option and EPG Server Device Options in
DLNA.

10.4.2.3
[G UIDELINE ] If a UPnP AV MediaServer implements an Extended Tuner, then it shall implement to
ISO/IEC 29341-4-3 (i.e. UPnP AV MediaServer:2 or higher) and conform to guidelines 10.4.3 to
10.4.9.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC JAUDH

29341-4-3

DLNA guidelines; Part 1-1: Architecture and protocols

 – 417 –

[C OMMENT] Tuners implemented on a UPnP AV MediaServer:2 or higher are recommended to

implement the Extended Tuner.

10.4.2.4
[G UIDELINE ] A UPnP AV MediaServer control point that interacts with a UPnP AV MediaServer
tuner, shall be able to browse CDS items for both the DLNA Basic Tuner (defined in guidelines
(10.1.4.16 through 10.1.4.23) and the DLNA Extended Tuner (defined in guidelines 10.4.3 through
10.4.5 and 10.4.7 through 10.4.8.

[ATTRIBUTES ]

M A DMP DMC +SR+ M-DMP M-DMC n/a ISO/IEC DC6OF

29341-4-3

[C OMMENT] UPnP AV MediaServers are allowed to select which DLNA Tuner (Basic or Extended)
to implement. To maintain a minimum level of interoperability a UPnP AV MediaServer control point
needs to work with both of the DLNA Tuner implementations. UPnP AV MediaServer control points
are not required to interact with Presets Containers (10.4.6) or Virtual Tuners Containers (10.4.9).

10.4.3 MM/ET Extended Tuner common guidelines

10.4.3.1
[G ENERAL ] These common guideline requirements for an Extended Tuner define the relationship
between the DLNA Extended Tuner and the UPnP AV MediaServer ContentDirectory service
TUNER feature. They define Channel Lineup Containers which expose the available channels to
UPnP AV MediaServer control points. In addition, they define the common guidelines for CDS items
(i.e. Non-Streamable Channel Objects and Streamable Channel Objects) that represent available
channels. Non-Streamable Channel Objects in a Channel Lineup Container would be used for
Extended Tuners that do not stream their content over the network, but provide CDS object IDs for
internal Tuner resources that can be used to setup a Scheduled Recording with identifying channel
information (cdsNonEPG record class). Optionally, Non-Streamable Channel Objects in a Channel
Lineup Container could be used for Extended Tuners that implement Virtual Tuner Objects in a
Virtual Tuner Container to stream selected channel content over the network through a single
connection. Figure 20 illustrates a Channel Lineup Container.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 418 –

Figure 20 – Modeling DLNA Extended Tuner

10.4.3.2
[G UIDELINE ] A UPnP AV MediaServer shall conform to all of the requirements of the TUNER
Feature defined in Clause E.2 of ISO/IEC 29341-4-12.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC BOAGO

29341-4-12

[C OMMENT] The DLNA Tuner requirements are built upon the UPnP TUNER feature defined in the
ContentDirectory service of ISO/IEC 29341-4-12.

10.4.3.3
[G UIDELINE ] A UPnP AV MediaServer shall return a <Feature> element indicating the TUNER
feature is implemented in response to the CDS:GetFeatureList action.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC RMIPF

29341-4-12

[C OMMENT] The TUNER feature allows a UPnP AV MediaServer control point to determine
whether a device supports the Extended Tuner functionality, and where the Channel Lineup
Containers are located in the larger ContentDirectory service Container hierarchy.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 419 –

10.4.3.4
[G UIDELINE ] A UPnP AV MediaServer shall expose at least one Channel Lineup Container in the
ContentDirectory service which conforms to the requirements for Channel Lineup Containers as
defined in 10.4.3.5 to 10.4.3.10.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 7TB6O

29341-4-12

[C OMMENT] Implementation of the DLNA Extended Tuner guidelines requires at least one Channel
Lineup Container be exposed by a UPnP AV MediaServer.

10.4.3.5
[G UIDELINE ] A UPnP AV MediaServer shall set the upnp:class property value of a Channel Lineup
Container to one of the following:

• object.container.channelGroup;
• object.container.channelGroup.audioChannelGroup;
• object.container.channelGroup.videoChannelGroup;
• class derived from any of the above classes.
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC PI9Z2

29341-4-12

[C OMMENT] ISO/IEC 29341-20-12 requires channel containers to have the upnp:class of

object.container.channelGroup or any of its derived classes, which gives more precise guidance on
upnp:class usage than the requirement in the guideline 10.1.4.16.3 for a Basic Tuner.

x) ISO/IEC 29341-4-12, C.2.2.5 specifies that

object.container.channelGroup.audioChannelGroup only contains
object.item.audioItem.audioBroadcast items and
object.container.channelGroup.videoChannelGroup only contains
object.item.videoItem.videoBroadcast items.
10.4.3.6
[G UIDELINE ] A UPnP AV MediaServer with a Channel Lineup Container that contains both
audioBroadcast and videoBroadcast items shall set the upnp:class property value to
object.container.channelGroup or a derived class of object.container.channelGroup.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC RBSWW

29341-4-12

[C OMMENT] ISO/IEC 29341-20-12 provides this guidance.

10.4.3.7
[G UIDELINE ] A UPnP AV MediaServer Channel Lineup Container should include a value for the
upnp:channelGroupName property. The value represents the user-friendly name of the Channel
Lineup Container.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 420 –

[ATTRIBUTES ]

S R DMS M-DMS n/a ISO/IEC CPID4

29341-4-12

[C OMMENT] A channel group defines a group of channels. A device that has multiple tuners can
provide multiple channel groups. Moreover, a physical tuner device can provide multiple channel
groups (for example, a set-top-box that contains a single tuner but supports three different input
connections: terrestrial, cable, and satellite).

10.4.3.8
[G UIDELINE ] A UPnP AV MediaServer Channel Lineup Container that includes a value for the
upnp:channelGroupName property shall include the upnp:channelGroupName@id property. The
upnp:channelGroupName@id property contains the ID of a channel group to differentiate it from
other channel groups implemented in a ContentDirectory service. The format of the
upnp:channelGroupName@id property is as follows:

<ICANN registered domain> “_” <channel group id defined in the domain>

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC G9RUP

29341-4-12

[C OMMENT] Vendors are allowed to utilize the DLNA.ORG_DefaultChannelGroup if there is no

external registered domain reference available. An example for a valid value for the
upnp:channelGroupName@id property is “megaserviceprovider.com_DigitalSatellite”. The
datatype defined in ISO/IEC 29341-4-12 for the upnp:channelGroupName@id property is xsd:string,
so any characters allowed by xsd:string can be used within <channel group id defined in this
domain>. For example, “DLNA.ORG_Any valid characters-+&23” would be valid syntax though not
semantically useful.

10.4.3.9
[G UIDELINE ] A UPnP AV MediaServer Channel Lineup Container dc:title property should be set to
the value of the upnp:channelGroupName property when included.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 3E7UL

29341-4-12

[C OMMENT] The upnp:channelGroupName property contains the user-friendly name for the
Channel Lineup Container. Duplicating this value in the dc:title will provide a user-friendly (and
hopefully informative) name to UPnP MediaServer control points that do not understand the
upnp:channelGroupName property.

10.4.3.10
[G UIDELINE ] A UPnP AV MediaServer Channel Lineup Container shall contain CDS Items that are
either all streamable (Streamable Channel Object) or all non-streamable (Non-Streamable Channel
Object).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 8N7XW

29341-4-12

DLNA guidelines; Part 1-1: Architecture and protocols

 – 421 –

[C OMMENT] This requirement clarifies that a Channel Lineup Container cannot contain a mixture of
both streamable and non-streamable CDS items. Non-Streamable Channel Objects in a Channel
Lineup Container would be used for Extended Tuners that do not stream their content over the
network, but provides a CDS object IDs for internal Tuner resources that can be used to setup a
Scheduled Recording with identifying channel information (cdsNonEPG record class). Optionally,
Non-Streamable Channel Objects in a Channel Lineup Container could be used for Extended
Tuners that implement Virtual Tuner Objects in a Virtual Tuner Container 10.4.9 to stream selected
channel content over the network through a single connection.

10.4.3.11
[G UIDELINE ] A UPnP AV MediaServer CDS Item (i.e. Non-Streamable Channel Objects or
Streamable Channel Objects) contained within a Channel Lineup Container shall conform to the
requirements as defined in 10.4.3.12 to 10.4.3.22.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC BC57O

29341-4-12

[C OMMENT] This defines the common requirements for CDS Items that represent available
channels whether they are non-streamble (Non-Streamable Channel Objects) or streamable
(Streamable Channel Objects).

10.4.3.12
[G UIDELINE ] A UPnP AV MediaServer shall set the upnp:class property value of a Non-Streamable
Channel Object or Streamable Channel Object to one of the following:

• object.item.videoItem.videoBroadcast;
• object.item.audioItem.audioBroadcast;
• class derived from either of the above classes.
The upnp:class value shall match the DLNA Media Class of the content carried by either the
Non-Streamable Channel Object or the Streamable Channel Object (i.e. supports content streaming)
as defined in 10.4.5 of these guidelines.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 4I38R

29341-4-12

[C OMMENT] A UPnP AV MediaServer needs to select a upnp:class value consistent with the
defined DLNA Media Classes (Audio Only or Audio Video).

10.4.3.13
[G UIDELINE ] A UPnP AV MediaServer should expose at least one upnp:channelID property for
each Non-Streamable Channel Object or Streamable Channel Object.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC T3WE7

29341-4-12

[C OMMENT] A UPnP AV MediaServer Non-Streamable Channel Object or Streamable Channel

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 422 –

Object would expose the upnp:channelID property whether the upnp:class property is
object.item.videoItem.videoBroadcast, object.item.audioItem.audioBroadcast, or their derived
classes.

10.4.3.14
[G UIDELINE ] A UPnP AV MediaServer Non-Streamable Channel Object or Streamable Channel
Object that includes a value for the upnp:channelID property shall include the
upnp:channelID@type property.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC NYKYZ

29341-4-12

10.4.3.15
[G UIDELINE ] If a UPnP AV MediaServer exposes a upnp:channelID property and a
upnp:channelID@type property for a Non-Streamable Channel Object or Streamable Channel
Object, then the combination of the upnp:channelID, upnp:channelID@type, and
upnp:channelID@distriNetworkID (if exposed) property values shall be unique within all the
exposed Channel Lineup Containers.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC U4XE8

29341-4-12

[C OMMENT] The upnp:channelID property, together with the upnp:channelID@type and optionally
the upnp:channelID@distriNetworkID property, uniquely identifies a Non-Streamable Channel
Object or Streamable Channel Object. Per ISO/IEC 29341-14-12, when the
upnp:channelId@distriNetworkID property is exposed it needs to be exposed for every
upnp:channelID property in the CDS. Therefore uniqueness will be determined by either
upnp:channelID and upnp:channelID@type property pairs or upnp:channelID,
upnp:channelID@type, and upnp:channelID@distriNetworkID property triplets The upnp:channelID
property is used to identify a video broadcast channel within the Extended Tuner. It is also used in
the CDS Items in the EPG Server Device Option to identify the associated Non-Streamable Channel
Object or Streamable Channel Object and in the recordSchedule and recordTask objects in the
Scheduled Recording Device Option to identify the associated Non-Streamable Channel Object or
Streamable Channel Object.

The upnp:channelID@distriNetworkID property was defined in ISO/IEC 29341-14-12 as an

additional channelID qualifier.

10.4.3.16
[G UIDELINE ] If a UPnP AV MediaServer exposes a upnp:channelID property for a Non-Streamable
Channel Object or Streamable Channel Object, and the upnp:channelID@type property value is
either “ANALOG” or “DIGITAL”, then it should expose the upnp:channelNr property.

[ATTRIBUTES ]

S C DMS M-DMS n/a ISO/IEC CWJWS

29341-4-12

[C OMMENT] This maintains compatibility with the DLNA Basic Tuner guideline 10.1.4.20.1.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 423 –

10.4.3.17
[G UIDELINE ] If a UPnP AV MediaServer exposes a upnp:channelID property for a Non-Streamable
Channel Object or Streamable Channel Object, and the upnp:channelID@type property is not
“ANALOG” or “DIGITAL”, then it shall not expose the upnp:channelNr property.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC KRMVP

29341-4-12

[C OMMENT] This is repeating a clarification from ISO/IEC 29341-20-12.

10.4.3.18
[G UIDELINE ] If a UPnP AV MediaServer exposes the upnp:channelNr property, upnp:channelID
property, and a upnp:channelID@type property with the value of “DIGITAL” for a Non-Streamable
Channel Object or Streamable Channel Object, then the upnp:channelNr property value shall be set
to the same value as the major channel number in the upnp:channelID property.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 5BXZZ

29341-4-12

[C OMMENT] This is repeating a clarification from ISO/IEC 29341-20-12.

10.4.3.19
[G UIDELINE ] If a UPnP AV MediaServer exposes the upnp:channelNr property, upnp:channelID
property, and a upnp:channelID@type property with the value of “ANALOG” for a Non-Streamable
Channel Object or Streamable Channel Object, then the upnp:channelNr property value shall be set
to the same value as the upnp:channelID property.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC Z3YWP

29341-4-12

[C OMMENT] This is repeating a clarification from ISO/IEC 29341-20-12.

10.4.3.20
[G UIDELINE ] If a UPnP AV MediaServer exposes the upnp:channelID property with a value of “SI”
for the upnp:channelID@type property, then the following definitions shall apply to the value for the
upnp:channelID property.

• The <Network ID> term is a non-negative numerical value with a range of 0 to 0xFFFF. The value
is network specific and shall be represented as a decimal or hexadecimal value. The value shall
be omitted (i.e. empty string) to indicate an unknown <network ID> term.
• The <Transport Stream ID> term is a non-negative numerical value with a range of 0 to 0xFFFF.
The value is network specific and shall be represented as a decimal or hexadecimal value. The
value shall be omitted (i.e. empty string) to indicate an unknown <Transport Stream ID> term.
• The <Service ID> term is a non-negative numerical value with a range of 0 to 0xFFFF. The value
is network specific and can be represented as a decimal or hexadecimal value.
[ATTRIBUTES ]
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 424 –

M C DMS M-DMS n/a ISO/IEC Z6TAR

29341-4-12

[C OMMENT] This guideline provides clarification for the values contained within the
upnp:channelID property for the “SI” type that’s lacking in ISO/IEC 29341-20-12. Examples of valid
values for the upnp:channelID are as follows:

• <upnp:channelID type=”SI”>0x1234,0xFEDC,0x0102</upnp:channelID>
• <upnp:channelID type=”SI”>12345,23456,32109</upnp:channelID>
• <upnp:channelID type=”SI”>,1,0x0102</upnp:channelID>
• <upnp:channelID type=”SI>,,0x0102</upnp:channelID>

10.4.3.21
[G UIDELINE ] If a UPnP AV MediaServer exposes the upnp:channelID property with the
upnp:channelID@type property with a value of “DLNA.ORG_FPF”, then the value of the
upnp:channelID property shall contain a CSV (Comma Separated Value List) triplet containing
values for frequency, program number, and modulation format respectively, where the frequency
value contains the channel frequency in hertz, the program number value is a 16-bit value as
defined in ISO/IEC 13818-1 and shall be represented as a decimal or hexadecimal value, and the
modulation format value contains a vendor defined string representing the modulation format being
used. Valid values for the modulation format are defined in Table 41.

Table 35 – Modulation format values

Broadcast systems Modulation format values

US Terrestrial System ATSC-8VSB
US Cable System SCTE65-QPSK
SCTE65-BPSK
SCTE65-OQPSK
SCTE65-VSB8
SCTE65-VSB16
SCTE65-QAM16
SCTE65-QAM32
SCTE65-QA64M
SCTE65-QAM80
SCTE65-QAM96
SCTE65-QAM112
SCTE65-QAM128
SCTE65-QAM160
SCTE65-QAM192
SCTE65-QAM224
SCTE65-QAM256
SCTE65-QAM320
SCTE65-QAM384
SCTE65-QAM448
SCTE65-QAM512
SCTE65-QAM640
SCTE65-QAM768
SCTE65-QAM896
SCTE65-QAM1024

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WNKRA

13818-1
ISO/IEC
29341-4-12

[C OMMENT] This is a DLNA extension to the upnp:channelID@type property values as defined in

DLNA guidelines; Part 1-1: Architecture and protocols

 – 425 –

B.8.5 of ISO/IEC 29341-4-12.

Examples for upnp:channelID values are as follows:

• <upnp:channelID type=”DLNA.ORG_FPF”>867000000,0x0002, SCTE65-QAM32</upnp:channelID>

• <upnp:channelID type=”DLNA.ORG_FPF”>867000000,20,ATSC-8VSB</upnp:channelID>

10.4.3.22
[G UIDELINE ] A UPnP AV MediaServer should implement Basic Tuner guideline requirement
10.1.4.16.6 which returns Non-Streamable Channel Objects or Streamable Channel Objects in the
order that corresponds to the up / down operation.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC YH5P3

29341-4-12

[C OMMENT] The order of the <item> elements in a CDS:Browse response (without a Sort input
specified) should represent the order of an up / down “channel surfing” action to allow UPnP AV
MediaServer control points to provide this functionality.

10.4.4 MM/ET Non-Streamable Extended Tuner guidelines

10.4.4.1
[G ENERAL ] These guidelines define the baseline requirements for Non-Streamable Channel
Objects. Non-Streamable Channel Objects are non-streamable CDS objects (i.e. no res property
value) which represent a single channel of a broadcast source which presents content in a
“channelized” format. Implementers should note that Non-Streamable Channel Objects are not
restricted to representing traditional terrestrial, cable, or satellite broadcast channels and can be
used to represent Webcasts, so called “Internet Radio” and “Internet TV” stations, and other
emerging content delivery mediums, so long as the content is organized or presented to the user
through the upnp:channelID property.

10.4.4.2
[G UIDELINE ] If a UPnP AV MediaServer exposes Non-Streamable Channel Objects (i.e.
non-streamable), then it shall conform to guideline requirements 10.4.4.3 and 10.4.4.4.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC JUT5C

29341-4-12

10.4.4.3
[G UIDELINE ] A UPnP AV MediaServer that advertises support for the TUNER Feature as defined in
10.4.3.2 through 10.4.3.4 shall not include the dlna:containerType property (10.1.4.16.4) in any
Channel Lineup Containers that contain only Non-Streamable Channel Objects.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC N4X7P

29341-4-12

[C OMMENT] UPnP AV MediaServer control points can differentiate between implementation levels
by looking for the presence or absence of the dlna:containerType property.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 426 –

10.4.4.4
[G UIDELINE ] A UPnP AV MediaServer Non-Streamable Channel Object shall omit the URI value
from all the res properties.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC A9D7O

29341-4-12

[C OMMENT] Since these CDS items are not streamable, a res property is not needed. But having
res properties without a URI value (a non streamable Channel Object can have multiple res
elements) can be useful by UPnP AV MediaServer control points in determining the DLNA Media
Format Profile for the Non-Streamable Channel Object by examining the res@protocolInfo
property’s DLNA.ORG_PN value in the fourth field.

10.4.5 MM/ET Streamable Extended Tuner guidelines

10.4.5.1
[G UIDELINE ] These guidelines define the baseline requirements for Streamable Channel Objects.
Streamable Channel Objects are streamable CDS objects which represent a single channel of a
broadcast source which presents content in a “channelized” format. Implementers should note that
Streamable Channel Objects are not restricted to representing traditional terrestrial, cable, or
satellite broadcast channels and can be used to represent Webcasts, so called “Internet Radio” and
“Internet TV” stations, and other emerging content delivery mediums, so long as the content is
organized or presented to the user through the upnp:channelID property. Streamable Channel
Objects expose one or more res properties with URI values. Content Receivers establish a
connection to the URI to initiate a streaming session. This connection implicitly attempts to change
the channel of the underlying broadcast source to the channel represented by the Streamable
Channel Object. Whether the channel is changed and the streaming connection established is
ultimately determined by the vendor-specific arbitration logic which is outside the scope of these
guidelines. UPnP AV MediaServer control points can switch the channel of the broadcast source by
establishing a connection to the URI in a different Streamable Channel Object.

10.4.5.2
[G UIDELINE ] If a UPnP AV MediaServer exposes Streamable Channel Objects, then it shall
conform to guideline requirements 10.4.5.3 to 10.4.5.8.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC FIDAZ

29341-4-12

10.4.5.3
[G UIDELINE ] A UPnP AV MediaServer Streamable Channel Object shall expose one or more res
properties. Each res property shall include a valid URI value.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 4DHUP

29341-4-12

[C OMMENT] A Streamable Channel Object is identified as a CDS Item with one or more res
properties with a valid URI value.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 427 –

10.4.5.4
[G UIDELINE ] A UPnP AV MediaServer that advertises support for the TUNER Feature as defined in
10.4.3.2 through 10.4.3.4 shall include the dlna:containerType property and conform to guideline
10.1.4.16.4 in any Channel Lineup Container that contains only Streamable Channel Objects.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VJFVP

29341-4-12

[C OMMENT] UPnP AV MediaServer control points can differentiate between implementation levels
by looking for the presence or absence of the dlna:containerType property. This is to ensure
backwards compatibility with UPnP AV MediaServer control points that will only interoperate with
Basic Tuners.

10.4.5.5
[G UIDELINE ] A UPnP AV MediaServer implementation for a Streamable Extended Tuner shall
conform to Basic Tuner guidelines defined in 10.1.4.16 to 10.1.4.22.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC M5B39

29341-4-12

[C OMMENT] This is to ensure backwards compatibility with UPnP AV MediaServer control points
that will only interoperate with Basic Tuners. This implies that a Streamable Extended Tuner is a
superset of a Basic Tuner.

10.4.5.6
[G UIDELINE ] A UPnP AV MediaServer shall support at least one streaming connection for a
Streamable Channel Object. A UPnP AV MediaServer can refuse a connection if the underlying
broadcast source is unavailable due to resource limitations associated with other active streaming
connections or local playback operations.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC UTQBZ

29341-4-12

[C OMMENT] A UPnP AV MediaServer will not have sufficient resources sometimes to support
multiple streaming connections to a single Streamable Channel Object. If a UPnP AV MediaServer
cannot accept a new streaming connection it can refuse the connection as defined in the relevant
Media Transport guideline (e.g.11.4.3.5.2).

10.4.5.7
[G UIDELINE ] A UPnP AV MediaServer shall terminate all streaming connections if the channel of
the underlying broadcast source changes and is no longer represented by the Streamable Channel
Object.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC N6C39

29341-4-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 428 –

[C OMMENT] A UPnP AV MediaServer control point establishes a connection to a Streamable

Channel Object for purposes of steaming that channel. If the UPnP AV MediaServer is no longer
able to stream that channel’s content, it needs to terminate any active streaming connections.

10.4.5.8
[G UIDELINE ] If a UPnP AV MediaServer implements a “time shift buffer” or similar feature on the
broadcast source associated with a Streamable Channel Object, then this buffer should be exposed
using the DLNA UCDAM model.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC JRP9S

29341-4-12

[C OMMENT] The DLNA UCDAM buffer model is designed to allow a UPnP AV MediaServer control
point to interoperate with “time shift buffers” and similar features. Vendors should pay particular
attention to guidelines in 10.1.3.33 regarding the UCDAM s 0 boundary increasing, and guideline in
10.1.3.34 describing the UCDAM s N boundary increasing requirements.

10.4.6 MM/ET Presets Containers

10.4.6.1
[G ENERAL ] These guidelines define the optional Presets Containers. Many broadcast receivers
utilize objects which can be described as “Favorites”, “Presets”, or other terms, which associate a
user-defined set of channel identifiers with channel objects. Vendors can utilize one or more
Presets Containers to communicate these mappings or associations to a UPnP AV MediaServer
control point. A Presets Container needs to have ContentDirectory service Reference Items which
associate channel identifiers with channel objects.

10.4.6.2
[G UIDELINE ] A UPnP AV MediaServer may expose a Presets Container.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC DSZKQ

29341-4-12

10.4.6.3
[G UIDELINE ] If a UPnP AV MediaServer exposes a Presets Container, then it shall conform to the
guidelines in 10.4.6.4 to 10.4.6.10.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC PYVZ5

29341-4-12

10.4.6.4
[G UIDELINE ] A UPnP AV MediaServer shall set the upnp:class property value of a Presets
Container to one of the following:

• object.container.channelGroup;
• object.container.channelGroup.audioChannelGroup;
• object.container.channelGroup.videoChannelGroup;
• class derived from any of the above classes.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 429 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 7X69R

29341-4-12

[C OMMENT] ISO/IEC 29341-20-12 requires channel containers to have the upnp:class of

object.container.channelGroup or any of its derived classes, which gives more precise guidance on
upnp:class usage than the requirements in the guideline 10.1.4.16.3 for a Basic Tuner.

ISO/IEC 29341-4-12, C.2.2.5 specifies that

object.container.channelGroup.audioChannelGroup only contains
object.item.audioItem.audioBroadcast items and
object.container.channelGroup.videoChannelGroup only contains
object.item.videoItem.videoBroadcast items.

10.4.6.5
[G UIDELINE ] A UPnP AV MediaServer Presets Container that contains @refID properties to CDS
Items (10.4.6.10) that are both audioBroadcast and videoBroadcast items shall set the upnp:class
property value to object.container.channelGroup or a derived class of
object.container.channelGroup.

[ATTRIBUTES ]

M C DMS M-DMS n/a ISO/IEC 7ZYLU

29341-4-12

[C OMMENT] ISO/IEC 29341-20-12 profiles this guidance.

10.4.6.6
[G UIDELINE ] A UPnP AV MediaServer Presets Container shall include a value for the
upnp:channelGroupName property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 5IQ4C

29341-4-12

[C OMMENT] A channel group defines a group of channels. A device that has multiple tuners may
provide multiple channel groups. Moreover, a physical tuner device may provide multiple channel
groups (for example, a set-top-box that contains a single tuner, but supports three different input
connections: terrestrial, cable, and satellite). Note that this mandates a similar requirement for
Channel Lineup Container. The upnp:channelGroupName property value represents the
user-friendly name of the Presets Container, as decribed in B.9.1 of ISO/IEC 29341-4-12.

10.4.6.7
[G UIDELINE ] A UPnP AV MediaServer Presets Container shall include the
upnp:channelGroupName@id property which shall be set to the value DLNA.ORG_ Presets for
Presets Containers.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 7CB26

29341-4-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 430 –

[C OMMENT] The value “DLNA.ORG_ Presets” identifies the channelGroup container as a Presets
Container to UPnP AV MediaServer control points.

10.4.6.8
[G UIDELINE ] A UPnP AV MediaServer Presets Container dc:title property should be set to the
value of the upnp:channelGroupName property.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 6JR4D

29341-4-12

[C OMMENT] The upnp:channelGroupName property contains the user-friendly name for the
Presets Container. Duplicating this value in the dc:title will provide a user-friendly (and hopefully
informative) name to UPnP MediaServer control points that do not understand the
upnp:channelGroupName property.

10.4.6.9
[G UIDELINE ] A UPnP AV MediaServer Presets Container shall not include the dlna:containerType
property (10.1.4.16.4).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC UA9XW

29341-4-12

10.4.6.10
[G UIDELINE ] A UPnP AV MediaServer Presets Container shall expose a @refID property in each
CDS Item contained in a Presets Container. The @refID property shall contain a value equal to the
@id property value of a Non-Streamable Channel Object or Streamable Channel Object exposed in
the same ContentDirectory service.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC V8GLU

29341-4-12

[C OMMENT] The purpose of a Preset reference is to associate a user-friendly “channel identifier”

with a Non-Streamable Channel Object or Streamable Channel Object. The UPnP AV MediaServer
exposes this user-friendly identifier in the upnp:channelName of a videoBroadcast or
audioBroadcast item and associates this with the Non-Streamable Channel Object or Streamable
Channel Object using the @refID property.

10.4.7 MM/ET EPG Server Device Option additional tuner guidelines

10.4.7.1
[G ENERAL ] These guidelines are additional requirements on an Extended Tuner when a UPnP AV
MediaServer implements the EPG Server Device Option.

10.4.7.2
[G UIDELINE ] If a UPnP AV MediaServer implements the EPG Server Device Option, as defined in
10.5.2.3, by including a <Feature> element with the Feature@name attribute equal to “EPG” in the
FeatureList output argument in response to the CDS:GetFeatureList action, then it shall conform to
guideline requirements 10.4.7.3 and 10.4.7.4.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 431 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC MNO39

29341-4-12

10.4.7.3
[G UIDELINE ] A UPnP AV MediaServer Channel Lineup Container shall include a value for the
upnp:channelGroupName property. The value represents the user-friendly name of the Channel
Lineup Container.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC PCLAV

29341-4-12

[C OMMENT] For the EPG Server Device Option, Channel Lineup Containers have to expose the
upnp:channelGroupName property.

10.4.7.4
[G UIDELINE ] A UPnP AV MediaServer shall expose at least one upnp:channelID property for each
Non-Streamable Channel Object or Streamable Channel Object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 4OQNX

29341-4-12

[C OMMENT] For the EPG Server Device Option, Non-Streamable Channel Objects and Streamable
Channel Objects have to expose the upnp:channelID property.

10.4.8 MM/ET Scheduled Recording Device Option additional tuner guidelines

10.4.8.1
[G ENERAL ] These guidelines are additional requirements on an Extended Tuner when a UPnP AV
MediaServer implements the Scheduled Recording Device Option.

10.4.8.2
[G UIDELINE ] If a UPnP AV MediaServer implements the Scheduled Recording Device Option, then
it shall conform to guideline 10.4.8.3.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 9EJWK

29341-4-12

10.4.8.3
[G UIDELINE ] A UPnP AV MediaServer shall implement guideline 10.4.3.13 (i.e. upnp:channelID
property) as mandatory instead of recommended.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC I4Z7F

29341-4-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 432 –

[C OMMENT] For the Scheduled Recording Device Option, Non-Streamable Channel Objects and
Streamable Channel Objects have to expose the upnp:channelID property.

10.4.9 MM/ET Virtual Tuners

10.4.9.1
[G ENERAL ] These optional guidelines for an Extended Tuner implementing a Virtual Tuner feature
allow modeling a physical tuner through a single connection. A Virtual Tuner Object is capable of
streaming the output of multiple channels over a single URI (res property URI) connection.

10.4.9.2
[G UIDELINE ] A UPnP AV MediaServer may implement a Virtual Tuner as defined in guidelines
requirements 10.4.9.3 to 10.4.9.35.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC AFKWK

29341-4-12

10.4.9.3
[G UIDELINE ] If a UPnP AV MediaServer implements a Virtual Tuner, then it shall conform to the
guidelines requirements 10.4.9.4 to 10.4.9.35.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC KUQR9

29341-4-12

10.4.9.4
[G UIDELINE ] A UPnP AV MediaServer shall set the upnp:class property value of a Virtual Tuner
Container to one of the following:

• object.container.virtualStreamGroup;
• class derived from the above class.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC Z4AG6

29341-4-12

10.4.9.5
[G UIDELINE ] A UPnP AV MediaServer Virtual Tuner Container shall include a value for the
upnp:channelGroupName property. The value represents the user-friendly name of the Virtual
Tuner Container.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC DA6UG

29341-4-12

10.4.9.6
[G UIDELINE ] A UPnP AV MediaServer Virtual Tuner Container shall include the
upnp:channelGroupName@id property which shall be set to the value DLNA.ORG_VirtualTuner for
Virtual Tuner Containers.

[ATTRIBUTES ]

DLNA guidelines; Part 1-1: Architecture and protocols

 – 433 –

M A DMS M-DMS n/a ISO/IEC 927R6

29341-4-12

[C OMMENT] The value “DLNA.ORG_VirtualTuner” identifies the UPnP container as a Virtual Tuner
Container to UPnP AV MediaServer control points.

10.4.9.7
[G UIDELINE ] A UPnP AV MediaServer Virtual Tuner Container dc:title property should be set to the
value of the upnp:channelGroupName property.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC TB9HA

29341-4-12

[C OMMENT] The upnp:channelGroupName property contains the user-friendly name for the Virtual
Tuner Container. Duplicating this value in the dc:title will provide a user-friendly (and hopefully
informative) name to UPnP AV MediaServer control points that do not understand the
upnp:channelGroupName property.

10.4.9.8
[G UIDELINE ] A UPnP AV MediaServer Virtual Tuner Container shall not include the
dlna:containerType property (10.1.4.16.4).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 6LRLP

29341-4-12

[C OMMENT] This allows UPnP AV MediaServer control points to differentiate that this is not a Basic
Tuner.

10.4.9.9
[G UIDELINE ] CDS items (Virtual Tuner Objects) as defined in guideline 10.4.9.10 contained in a
UPnP AV MediaServer Virtual Tuner Container shall be streamable through a single connection and
shall reflect in the res@protocolInfo 4th field value for the Virtual Tuner Object the content currently
being streamed over the connection as defined in 10.1.3.16.4 and 10.1.3.17.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC SLJVJ

29341-4-12

[C OMMENT] This requirement clarifies that a Virtual Tuner Container contains CDS items that
stream tuner channels through a single connection.

10.4.9.10
[G UIDELINE ] A UPnP AV MediaServer CDS Item (i.e. Virtual Tuner Object) contained within a
Virtual Tuner Container shall conform to the requirements as defined in 10.4.9.11 to 10.4.9.35.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC RSZXO

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 434 –

29341-4-12

[C OMMENT] This defines the requirements for a CDS Item that represents the current streamed
output of a tuner (Virtual Tuner Objects).

10.4.9.11
[G UIDELINE ] A UPnP AV MediaServer shall set the upnp:class property value of a Virtual Tuner
Object to one of the following:

• object.item.videoItem.virtualTuner;
• object.item.audioItem.virtualTuner;
• class derived from either of the above classes.
The upnp:class value shall match the DLNA Media Class of the content carried by the Virtual Tuner
Object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VDBHA

29341-4-12

[C OMMENT] A UPnP AV MediaServer needs to select a upnp:class value consistent with the
defined DLNA Media Classes (Audio Only or Audio Video).

10.4.9.12
[G UIDELINE ] A UPnP AV MediaServer shall expose the dlna:channelGroupList property for each
Virtual Tuner Object. The value of the dlna:channelGroupList property is a CSV (Comma Separated
Value) list containing one or more upnp:channelGroup@id values, where each
upnp:channelGroup@id value corresponds to a Channel Lineup Container that the Virtual Tuner
Object can use for access to a Tuner.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC XU9MQ

29341-4-12

[C OMMENT] This guideline provides UPnP AV MediaServer control points a method to determine
which Channel Lineup Container(s) are associated with which Virtual Tuner Object.

10.4.9.13
[G UIDELINE ] A UPnP AV MediaServer shall expose at least one upnp:channelID property for each
Virtual Tuner Object. The upnp:channelID property value represents the channel last selected by
the Virtual Tuner Object. When more than one upnp:channelID property is exposed, they shall each
resolve to the same underlying channel, but represented differently (i.e. different
upnp:channelID@type property values as defined in 10.4.9.14).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC BTGLV

29341-4-12

[C OMMENT] The values for multiple instances of the upnp:channelID property represent the same
underlying channel currently being selected.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 435 –

10.4.9.14
[G UIDELINE ] A UPnP AV MediaServer Virtual Tuner Object that includes a value for the
upnp:channelID property shall include the upnp:channelID@type property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VRLN5

29341-4-12

10.4.9.15
[G UIDELINE ] If a UPnP AV MediaServer exposes more than one upnp:channelID property for a
Virtual Tuner Object then each upnp:channelID property shall have a distinct upnp:channelID@type
property value.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC KXMVM

29341-4-12

[C OMMENT] Each upnp:channelID property exposed in a Virtual Tuner Object will always have
different upnp:channelID@type values.

10.4.9.16
[G UIDELINE ] If a UPnP AV MediaServer’s upnp:channelID@type property value is either “ANALOG”
or “DIGITAL” for a Virtual Tuner Object, then it should expose the upnp:channelNr property.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC Y49CI

29341-4-12

[C OMMENT] This is aligning with a clarification from ISO/IEC 29341-4-12.

10.4.9.17
[G UIDELINE ] If a UPnP AV MediaServer’s upnp:channelID@type property is not “ANALOG” or
“DIGITAL” for a Virtual Tuner Object, then it shall not expose the upnp:channelNr property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC OYZ6Q

29341-4-12

[C OMMENT] This is aligning with a clarification from ISO/IEC 29341-4-12.

10.4.9.18
[G UIDELINE ] If a UPnP AV MediaServer exposes the upnp:channelNr property, upnp:channelID
property, and a upnp:channelID@type property with the value of “DIGITAL” for a Virtual Tuner
Object, then the upnp:channelNr property value shall be set to the major channel number from that
upnp:channelID property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC YKSPG

29341-4-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 436 –

[C OMMENT] This is aligning with a clarification from ISO/IEC 29341-4-12.

10.4.9.19
[G UIDELINE ] If a UPnP AV MediaServer exposes the upnp:channelNr property, upnp:channelID
property, and a upnp:channelID@type property with the value of “ANALOG” for a Virtual Tuner
Object, then the upnp:channelNr property value shall be set to the value of that upnp:channelID
property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 723RJ

29341-4-12

[C OMMENT] This is aligning with a clarification from ISO/IEC 29341-4-12.

10.4.9.20
[G UIDELINE ] A UPnP AV MediaServer should implement the DLNA defined value of
“DLNA.ORG_OBJECT_ID” for the upnp:channelID@type property as defined in 10.4.9.21.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC QUV45

29341-4-12

10.4.9.21
[G UIDELINE ] If a UPnP AV MediaServer Virtual Tuner Object exposes the upnp:channelID property
with the upnp:channelID@type property with a value of “DLNA.ORG_OBJECT_ID”, then the value
of the upnp:channelID property shall contain the @id property value of a Streamable Channel
Object as defined in guideline requirements 10.4.3.11 and 10.4.5.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC L943V

29341-4-12

[C OMMENT] This is a DLNA extension to the upnp:channelID@type property values as defined in

B.8.5 of ISO/IEC 29341-4-12.

10.4.9.22
[G UIDELINE ] A UPnP AV MediaServer Virtual Tuner Object shall expose the following physical
tuner status-related properties:

• upnp:tuned;
• upnp:signalStrength;
• upnp:signalLocked.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC YACS6

29341-4-12

[C OMMENT] These UPnP properties are mandated for all Virtual Tuner Objects.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 437 –

10.4.9.23
[G UIDELINE ] A UPnP AV MediaServer that exposes a Virtual Tuner Object shall implement the
CDS:X_DLNA_SelectChannel action with the following syntax:

The action is defined as stated in Table 42.

Table 36 – CDS:X_DLNA_SelectChange action parameters

Argument Direction relatedStateVariable

VirtualTunerObjectID In A_ARG_TYPE_ObjectID
ChannelID In A_ARG_TYPE_DLNAChannelID
ClientConnectionID In A_ARG_TYPE_DLNAConnectionID
ServerConnectionID Out A_ARG_TYPE_DLNAConnectionID

The value of the VirtualTunerObjectID input argument shall be the object ID of a Virtural Tuner
Object.

The value of the ChannelID input argument shall be a upnp:channelID XML Fragment. See B.8.5 of
ISO/IEC 29341-20-12 for details with the exception that only a single instance is allowed (i.e. not
multi-valued). The ChannelID input argument shall be in escaped XML when used with this action.

The value of the ClientConnectionID input argument shall be a value obtained by any of the
following methods.

• The ServerConnecrtionID output argument value from a previous CDS:X_DLNA_SelectChannel

action response.
• The ConnectionID output argument value from a CMS:PrepareForConnection action response.
• -1 when this action is used to establish a new connection.
The value of the ServerConnectionID output argument shall be the same value as the
ClientConnectionID unless the ClientConnectionID input argument value is −1, in which case the
UPnP AV MediaServer shall respond with a ServerConnectionID value that is unique to the
connection.

When the ClientConnectionID input argument is −1 the UPnP AV MediaServer control point is
initiating a new connection and requesting a unique connection ID in the ServerConnectionID output
argument in the action response. If the action succeeds the UPnP AV MediaServer shall use the
value returned in the ServerConnectionID output argument for BCM operations.

The error codes defined for this action are defined in Table 37.

Table 37 – CDS:X_DLNA_SelectChange action error codes

ErrorCode errorDescription Description

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 438 –

400-499 TBD See UPnP Device Architecture section on Control [].

500-599 TBD See UPnP Device Architecture section on Control.
600-699 TBD See UPnP Device Architecture section on Control.
701 No such object The X_DLNA_SelectChannel action failed because the specified
VirtualTunerObjectID does not exist or is not a Virtual Tuner
Object.
712 Bad metadata The X_DLNA_SelectChannel action failed because the
ChannelID input argument is an invalid XML Fragment.
715 Source resource access denied The X_DLNA_SelectChannel action failed because a specified
ChannelID resource is busy.
720 Cannot process the request The X_DLNA_SelectChannel action failed because it will not be
able to tune to the channel specified in the ChannelID resource.
801 Invalid connection reference The X_DLNA_SelectChannel action failed because the
connection reference argument does not refer to a valid
connection established by the Connection Manager Service
(CMS).

This action shall be defined in the service description document using the following XML fragment:

<action>
<name> X_DLNA_SelectChannel </name>
<argumentList>
<argument>
<name>VirtualTunerObjectID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_ObjectID</relatedStateVariable>
</argument>
<argument>
<name>ChannelID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_DLNAChannelID</relatedStateVariable>
</argument>
<argument>
<name>ClientConnectionID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_DLNAConnectionID</relatedStateVariable>
</argument>
<argument>
<name>ServerConnectionID</name>
<direction>out</direction>
<relatedStateVariable>A_ARG_TYPE_DLNAConnectionID</relatedStateVariable>
</argument>
</argumentList>
</action>

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC UDADM

29341-4-12

[C OMMENT] This guideline defines a new action for the UPnP AV MediaServer ContentDirectory
service. This action is implemented by servers that expose Virtual Tuner Objects. Semantic
behavior for this action is defined in 10.4.9.24 to 10.4.9.32.
Examples of valid values for the ChannelID input argument are as follows:

DLNA guidelines; Part 1-1: Architecture and protocols

 – 439 –

<upnp:channelID xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
type=”ANALOG”>5</upnp:channelID>

<upnp:channelID xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
type=”DLNA.ORG_OBJECT_ID”>TunerObj_001</upnp:channelID>

y) The values of the ClientConnectionID input argument and the ServerConnectionID output
argument allow the CDS:X_DLNA_SelectChannel action to be used as a new connection
initiator or to be associated with an existing connection.
10.4.9.24
[G UIDELINE ] A UPnP AV MediaServer control point should first verify if the Virtual Tuner Object is
currently in use in an active session with another UPnP AV MediaRenderer (e.g. dlna:peerManager
property as defined in 10.4.9.35) before executing the X_DLNA_SelectChannel action.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC 2KYHG

29341-4-12

[C OMMENT] This guideline provides implementation guidance for UPnP AV MediaServer control
points to not interrupt an existing session before executing the action.

10.4.9.25
[G UIDELINE ] A UPnP AV MediaServer that exposes a Virtual Tuner Object shall include the
A_ARG_TYPE_DLNAChannelID state variable in the ContentDirectory service description. This
state variable shall be defined as type information for the ChannelID input argument in the
CDS:X_DLNA_SelectChannel action.

This state variable is defined in Table 38.

Table 38 – A_ARG_TYPE_DLNAChannelID state variable

Variable name Data Allowed value Evented Moderated

type event
A_ARG_TYPE_DLNAChannelID string upnp:channelID XML Fragment No No
See B.8.5 of ISO/IEC 29341-4-12 with
the exception that only a single instance
is allowed

The A_ARG_TYPE_DLNAChannelID state variable shall be defined in the service description

document using the following XML fragment:

<stateVariable sendEvents=”no”>
<name>A_ARG_TYPE_DLNAChannelID</name>
<dataType>string</dataType>
</stateVariable>

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC YEMMQ

29341-4-12

[C OMMENT] This guideline defines a new state variable for the UPnP AV MediaServer
ContentDirectory service. This state variable is used by the new CDS:X_DLNA_SelectChannel
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 440 –

action for the ChannelID input argument.

Example values for this state variable are as follows:

<upnp:channelID xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
type=”ANALOG”>5</upnp:channelID>

<upnp:channelID xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
type=”DLNA.ORG_OBJECT_ID”>TunerObj_001</upnp:channelID>

10.4.9.26
[G UIDELINE ] A UPnP AV MediaServer that exposes a Virtual Tuner Object shall include the
A_ARG_TYPE_DLNAConnectionID state variable in the ContentDirectory service description. This
state variable shall be defined as type information for the ClientConnectionID input argument and
the ServerConnectionID output argument in the CDS:X_DLNA_SelectChannel action.

This state variable is defined in Table 39.

Table 39 – A_ARG_TYPE_DLNAConnectionID state variable

Variable name Data Allowed value Evented Moderated

type event
A_ARG_TYPE_DLNAConnectionID i4 Connection ID value established by a No No
UPnP AV MediaServer. The value −1 is
a special value indicating an unsolicited
action requesting a new connection.

The A_ARG_TYPE_DLNAConnectionID state variable shall be defined in the service description

document using the following XML fragment:

<stateVariable sendEvents=”no”>
<name>A_ARG_TYPE_DLNAConnectionID</name>
<dataType>i4</dataType>
</stateVariable>

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC GVCIJ

29341-4-12

[C OMMENT] This guideline defines a new state variable for the UPnP AV MediaServer
ContentDirectory service. This state variable is used by the new CDS:X_DLNA_SelectChannel
action for the ClientConnectionID input argument and ServerConnectionID output argument.

10.4.9.27
[G UIDELINE ] If a UPnP AV MediaServer has successfully executed the
CDS:X_DLNA_SelectChannel action and the content is being streamed or available to be streamed,
then it shall expose the upnp:tuned property with a value of “1” for the Virtual Tuner Object,
otherwise the value shall be “0”

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC GFP9J

29341-4-12

[C OMMENT] This provides UPnP AV MediaServer control points a method to determine if content
(e.g. channel) is currently being streamed or available to be streamed by the Virtual Tuner Object.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 441 –

10.4.9.28
[G UIDELINE ] If a UPnP AV MediaServer has successfully executed the
CDS:X_DLNA_SelectChannel action, then it should only return a success response after it has
stopped streaming content for the previously selected channel.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC TNROB

29341-4-12

[C OMMENT] This allows UPnP AV MediaServer control points to know that content from the
previously selected channel has completed streaming content to a rendering device.

If a DLNA Media Format Profile supports DIT (Discontinuity Information Table), then the DIT is
inserted into the content stream at the discontinuity point as defined in Media Format guidelines IEC
62481-2. This provides a mechanism for a UPnP AV MediaRenderer to detect a change in channel
content.

10.4.9.29
[G UIDELINE ] If a UPnP AV MediaServer control point has successfully executed the
CDS:X_DLNA_SelectChannel action, then its co-located UPnP AV MediaRenderer control point
should execute the AVT:SetAVTransportURI action with the CurrentURIMetadata input parameter
containing the updated CDS metadata of the Virtual Tuner Object resulting from the
CDS:X_DLNA_SelectChannel action to the UPnP AV MediaRenderer that is rendering the content
being streamed as defined in 10.4.9.27.

[ATTRIBUTES ]

S A DMC M-DMC n/a ISO/IEC UWUZ3

29341-4-12

[C OMMENT] In the 3-box system usage, the UPnP AV MediaRenderer needs to have knowledge of
the updated metadata (i.e. channelID value) when the CDS:X_DLNA_SelectChannel action is
successfully executed. The updated CDS metadata is obtained by executing a CDS:Browse action
on the Virtual Turner Object after executing the CDS:X_DLNA_SelectChannel action.

A possible implementation of a 3-box system usages scenario to achieve a channel change user
experience that is consistent with the commercial TV services offered by content service providers
is as follows: Upon a user’s request for a channel change, the UPnP AV control point (i.e. UPnP AV
MediaRenderer + UPnP AV MediaServer control point) invokes the AVT:Stop action to a UPnP AV
MediaRenderer (e.g. DMR), followed by the CDS:X_SelectChannel action to a UPnP AV
MediaServer (e.g. DMS) to tune to a new channel. After the UPnP AV MediaServer returns a
successful response, the UPnP AV control point invokes the CDS:Browse action on the Virtual
Tuner Object to obtain the updated CDS metadata, followed by invoking the
AVT:SetAVTransportURI action to the UPnP AV MediaRender with the updated content item
metadata, and then finally invokes the AVT:Play action to the UPnP AV MediaRenderer.

10.4.9.30
[G UIDELINE ] If a UPnP AV MediaServer has successfully executed the
CDS:X_DLNA_SelectChannel action, then it shall remove all instances of the upnp:channelID
property for the Virtual Tuner Object as specified in the VirtualTunerObjectID input parameter, and
it shall expose a upnp:channelID property with the value in the ChannelID input parameter.

[ATTRIBUTES ]

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 442 –

M A DMS M-DMS n/a ISO/IEC GV22A

29341-4-12

[C OMMENT] This exposes the new channel that has been selected in the Virtual Tuner Object.

10.4.9.31
[G UIDELINE ] If a UPnP AV MediaServer has successfully executed the
CDS:X_DLNA_SelectChannel action, then it may expose additional upnp:channelID property
values that conforms to guideline 10.4.9.13.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 633AS

29341-4-12

[C OMMENT] This allows a UPnP AV MediaServer to expose additional instances of the

upnp:channelID property when it resolves to the same underlying channel as the ChannelID input
parameter.

10.4.9.32
[G UIDELINE ] If a UPnP AV MediaServer has successfully executed the
CDS:X_DLNA_SelectChannel action, then it shall update the res@protocolInfo 4th field value for
the Virtual Tuner Object as specified in the VirtualTunerObjectID input parameter to identify the
content for the selected channel as defined in 10.1.3.16.4 and 10.1.3.17.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC J7NPO

29341-4-12

[C OMMENT] This requires the res@protocolInfo property to reflect the correct Media Format Profile
for the content on the newly selected channel as specified in the ChannelID input parameter.

10.4.9.33
[G UIDELINE ] A UPnP AV MediaServer that exposes a Virtual Tuner Object shall implement the
BCM (Basic Connection Management) feature as defined in guidelines in 10.1.5.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC A4FJW

29341-4-12

[C OMMENT] This guideline requires a UPnP AV MediaServer to implement the BCM feature when
implementing Virtual Tuners.

10.4.9.34
[G UIDELINE ] A UPnP AV MediaServer that exposes the dlna:peerManager property shall have the
following definition.

• Namespace: dlna
• Property data type: xsd:string
• Multi-Value: NO

DLNA guidelines; Part 1-1: Architecture and protocols

 – 443 –

• The dlna:peerManager property semantic behavior is defined and exposed as defined in

10.4.9.35.
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC JO94M

29341-4-12

[C OMMENT] This guideline describes a new DLNA namespace property for CDS items.

10.4.9.35
[G UIDELINE ] If a UPnP AV MediaServer exposes a Virtual Tuner Object that is being used for
content transfers, then it shall expose the dlna:peerManager property with one of the following
values.

• The PeerConnectionManager value provided by a UPnP AV MediaRenderer (i.e. DMR) using

the peerManager.dlna.org HTTP header (defined in 11.4.3.35) when the Virtual Tuner Object is
currently being used for content transfer.
• The PeerConnectionManager value provided by a UPnP AV MediaRenderer (i.e. DMR) using
the peerManager.dlna.org RTSP header (defined in 11.4.4.155) when the Virtual Tuner Object is
currently being used for content transfer.
• An empty value if the information is not available (i.e. the UPnP AV MediaRenderer or UPnP AV
MediaRenderer control point does not implement BCM).
• The friendly name value provided by a UPnP AV MediaServer control point with embedded
rendering (i.e. DMP and M-DMP) using the friendlyName.dlna.org HTTP header (defined in
11.4.3.36) when the Virtual Tuner Object is currently being used for content transfer.
• The friendly name value provided by a UPnP AV MediaServer control point with embedded
rendering (i.e. DMP and M-DMP) using the friendlyName.dlna.org RTSP header (defined in
11.4.4.156) when the Virtual Tuner Object is currently being used for content transfer.
Otherwise, the UPnP AV MediaServer shall not expose the dlna:peerManager property for the
Virtual Tuner Object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC CBPIN

29341-4-12

[C OMMENT] This allows a UPnP AV MediaRenderer control point to know which device is currently
rendering the content being transferred by the Virtual Tuner Object.

10.5 EPG Media management guidelines

10.5.1 MM/EPG foreign metadata feature advertisement
10.5.1.1
[G UIDELINE ] If one or more CDS items exposes foreign metadata using the upnp:ForeignMetadata
property, a UPnP AV MediaServer shall include a <Feature> element with the @name attribute
equal to “FOREIGN_METADATA” in the FeatureList output argument in response to the
CDS:GetFeatureList action. The @version attribute of the same <Feature> element shall have a
value of “1”.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC EDCBT

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 444 –

29341-14-12

10.5.2 MM/EPG Server Device Option advertisement

10.5.2.1
[G ENERAL ] This subclause defines the DLNA Electronic Program Guide system usage guidelines
for a UPnP AV MediaServer that implements the EPG Server Device Option.

10.5.2.2
[G UIDELINE ] A UPnP AV MediaServer that implements the EPG Server Device Option shall
implement all mandatory requirements of the UPnP EPG Feature as defined in Clause E.1 of
ISO/IEC 29341-14-12.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC NU8GR

29341-14-12

10.5.2.3
[G UIDELINE ] A UPnP AV MediaServer shall include a <Feature> element with the @name attribute
equal to “EPG” or “DLNA.ORG_EPGDataOnly” in the FeatureList output argument in response to
the CDS:GetFeatureList action. If the EPG Server Device Option is being implemented solely for
purpose of providing EPG metadata to other devices, then the Feature@name attribute shall be
“DLNA.ORG_EPGDataOnly”. Otherwise, the Feature@name attribute shall be “EPG”. In both cases
the @version attribute of the same <Feature> element shall have a value of “1”. The <Feature>
element shall include an <objectIDs> element.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 3JAIN

29341-14-12

[C OMMENT] DLNA.ORG_EPGDataOnly usage is encouraged in cases where a DLNA EPG Server

Device Option is used solely as a mechanism for supplying ancillary metadata to control points on
the home-network.

10.5.2.4
[G UIDELINE ] If a UPnP AV MediaServer exposes one or more CDS containers with a upnp:class
value of object.container.epgContainer, the object@id attribute value of the root of each EPG
subtree shall be exposed in the <objectIDs> element of the <Feature> element.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC IZOWC

29341-14-12

[C OMMENT] UPnP AV MediaServer control points can use the objectID to initiate a query starting
from that subtree to obtain EPG data.

10.5.2.5
[G UIDELINE ] If a UPnP AV MediaServer implements the CDS:FreeFormQuery action, it shall
include a <Feature> element with the @name attribute equal to “FFQ” in the FeatureList output
argument of the CDS:GetFeatureList action. The @version attribute of the same <Feature> element
shall have a value of “1”. This <Feature> element shall contain one or more <ObjectID> elements.
Each <ObjectID> element shall contain the @id property of a CDS container which satisfies both of
the following conditions:
DLNA guidelines; Part 1-1: Architecture and protocols
 – 445 –

• the CDS:FreeFormQuery action is supported for the CDS container and each of its descendant
containers;
• the CDS:FreeFormQuery action is not supported for the parent of the CDS container.
Additionally the @level attribute of each <ObjectID> element shall indicate the support level for
XQuery requests for the container represented by that <ObjectID> element as defined in 10.5.7.

[ATTRIBUTES ]

M R DMS n/a n/a ISO/IEC XXZDZ

29341-14-12

[C OMMENT] This guideline repeats the UPnP requirements for the FFQ <Feature>. In ISO/IEC
29341-20-12.

10.5.2.6
[G UIDELINE ] If a UPnP AV MediaServer exposes EPG Program items that represent channelized
content, it shall implement the DLNA Extended Tuner to expose the device’s channel lineup as
specified in 10.4.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC JEKB7

29341-14-12

[C OMMENT] The channel lineup provides UPnP AV MediaServer control points with the values
which can be used to search the EPG items using the channelID property. The channels are
represented as a collection of videoBroadcastItems or audioBroadcast Items. These
videoBroadcastItems and audioBroadcast items do not need to provide a URL in their
<res>-elements. If the channelID@type of an EPG item is “NETWORK” then the channelID contains
the actual URL of the content. If the channelID@type is not “NETWORK” then channelID contains a
identifier that is resolved to a tuner item. Therefore, a device which implements the UPnP AV Media
Server EPG Device Option does not need to stream content from a physical tuner. Such a device
might not even have a physical tuner.

10.5.3 MM/EPG EPG object persistence guidelines

10.5.3.1
[G ENERAL ] This subclause defines the object persistence requirements for a UPnP AV
MediaServer when implementing the optional EPG Server Device Option as defined in guideline
10.5.2.

10.5.3.2
[G UIDELINE ] A UPnP AV MediaServer should use the same CDS Program Item (i.e. a CDS
Program Item with the same @id property) to represent an EPG event throughout the lifetime of that
EPG event, except when executing the Service Reset Procedure described in 2.3.7.1 of ISO/IEC
29341-14-12.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC VVDED

29341-14-12

[C OMMENT] Some UPnP AV MediaServer implementations delete a CDS object representing an

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 446 –

EPG event and recreate a new CDS object for that same event when an update is received from an
EPG source. Such behavior makes it difficult for UPnP AV MediaServer control points to keep track
of EPG events of interest, and it is discouraged by DLNA.

10.5.3.3
[G UIDELINE ] If a UPnP AV MediaServer implements the ScheduledRecording Device Option and
indicates support for the cds EPG record class as defined in guideline 10.3.11, then it shall use the
same CDS Program Item (i.e. a CDS Program Item with the same @id property) to represent an
EPG event throughout the lifetime of that EPG event, except when executing the Service Reset
Procedure described in 2.3.7.1 of ISO/IEC 29341-14-12.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 58U9B

29341-14-12

10.5.3.4
[G UIDELINE ] If a UPnP AV MediaServer always uses the same CDS Program Item to represent an
EPG event throughout the lifetime of that EPG event (except when executing the Service Reset
Procedure described in 2.3.7.1 of ISO/IEC 29341-14-12), then it shall use the <dlna:X_DLNACAP>
element (as a child of the <device> element that represents the UPnP AV MediaServer) in the
device description document and include the Capability ID “epg-object-persistence” in the element’s
comma-separated value list.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC JGDW8

29341-14-12
ISO/IEC
29341-14-3

10.5.4 MM/EPG EPG Controller definition

10.5.4.1
[G UIDELINE ] A DLNA device class may implement the EPG Controller Device Capability.

[ATTRIBUTES ]

O A DMS DMP DMR DMC M-DMS M-DMP n/a n/a BG2YK

10.5.4.2
[G UIDELINE ] An EPG Controller shall implement a UPnP AV MediaServer control point for
interacting with a ContentDirectory service on a DMS or M-DMS.

[ATTRIBUTES ]

M R +EPG+ n/a n/a ISO/IEC DKIL9

29341-14-12
ISO/IEC
29341-14-3

[C OMMENT] This guideline indicates that an EPG Controller Device Capability will use a UPnP
control point that controls a UPnP AV MediaServer for browsing content.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 447 –

10.5.5 MM/EPG mandatory EPG program item properties

10.5.5.1 MM/EPG general
This defines the mandatory properties that a UPnP AV MediaServer needs to expose for EPG
Program Items.

10.5.5.2 MM/EPG upnp:class property

10.5.5.2.1
[G UIDELINE ] A UPnP AV MediaServer shall utilize the object.item.epgItem class or a derived class
thereof for all EPG Program Items exposed in an EPG Container. The specific value of the
upnp:class property shall conform to the requirements defined in 10.5.5.2.2 to 10.5.5.2.4.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 426J3

29341-14-12

[C OMMENT] All EPG Program Items will be derived from the object.item.epgItem base class.

10.5.5.2.2
[G UIDELINE ] If a UPnP AV MediaServer is unable to determine the DLNA Media Class to which the
Content Binary associated with the EPG Program Item conforms, it shall set the value of the
upnp:class property to object.item.epgItem.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 7VCPH

29341-14-12

[C OMMENT] A UPnP AV MediaServer might not be able to determine the Media Format of the
Content Binary associated with an EPG Program Item when that EPG Program Item is initially
exposed, or even during the entire lifespan of the EPG Program Item. In that case, a UPnP AV
MediaServer will set the upnp:class value to object.item.epgItem, and will not use one of the media
format-specific derived classes. If the Media Format becomes known during the lifespan of the EPG
Program Item, the UPnP AV MediaServer will update the value of the upnp:class property as
specified in 10.5.5.2.3 and 10.5.5.2.4.

10.5.5.2.3
[G UIDELINE ] If a UPnP AV MediaServer determines that the Content Binary associated with an
EPG Program Item conforms to the DLNA AV Media Class, the value of the upnp:class property
shall be set to object.item.epgItem.videoProgram.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 3CGXD

29341-14-12

[C OMMENT] A UPnP AV MediaServer will utilize the object.item.epgItem.videoProgram class for all
EPG Program Items whose associated Content Binaries conform to the DLNA AV Media Class. It is
not required that the DLNA Media Format Profile ID be exposed in the <res> element of the EPG
Program Item.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 448 –

10.5.5.2.4
[G UIDELINE ] If a UPnP AV MediaServer determines that the Content Binary associated with an
EPG Program Item conforms to the DLNA Audio Only Media Class, the value of the upnp:class
property shall be set to object.item.epgItem.audioProgram.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 8WDPK

29341-14-12

[C OMMENT] A UPnP AV MediaServer will utilize the object.item.epgItem.audioProgram class for all
EPG Program Items whose associated Content Binaries conform to the DLNA Audio Only Media
Class.

10.5.5.2.5
[G UIDELINE ] If a UPnP AV MediaServer determines that the Content Binary associated with an
EPG Program Item does not conform to a DLNA Media Format Profile in the AV or Audio Only Media
Classes, then it shall not expose the dlna.org_PN parameter in the 4th Field of the protocolInfo
property.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC N6QVH

29341-14-12

[C OMMENT] In order to support the DLNA mission of interoperability, EPG Program Items whose
content is not currently supported by the DLNA ecosystem will not be identified as DLNA content.

10.5.5.2.6
[G UIDELINE ] If a UPnP AV MediaServer determines that the Content Binary associated with an
EPG Program Item conforms to a DLNA Media Format Profile in the AV or Audio Only Media
Classes, then it should expose the dlna.org_PN parameter in the 4th Field of the protocolInfo
property.

[ATTRIBUTES ]

S A DMS n/a n/a ISO/IEC UHE9C

29341-14-12

10.5.5.3 MM/EPG dc:title property

10.5.5.3.1
[G UIDELINE ] A UPnP AV MediaServer shall provide a value for the dc:title property that identifies
the EPG Program Item.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC TDXMQ

29341-14-12

[C OMMENT] The value of the dc:title property will represent the program or title of the EPG Program
Item.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 449 –

10.5.5.3.2
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item that does not have a DLNA
Recognized Metadata Source, the value of dc:title should be set to best represent a user-friendly
title for the contents represented by the EPG Program Item.

[ATTRIBUTES ]

S A DMS n/a n/a ISO/IEC 4FBKE

29341-14-12

10.5.5.3.3
[G UIDELINE ] If the EPG Program Item metadata source is OpenEPG, the value of the dc:title
property shall be set to the value of the highest priority metadata (as listed below in order of
decreasing priority) available for that EPG Program Item in the source metadata.

• Content.ContentTitle
• ContentServiceSource.Name
• ContentService.ContentServiceMapping.Channel
• ContentService.ContentServiceMapping.URLSource
[ATTRIBUTES ]

M A DMS n/a n/a ANSI/CEA-20 LY378

33 A

[C OMMENT] At least one of the above-mentioned OpenEPG metadata elements will be present so
that there will always be a value available to populate the dc:title property.

10.5.5.3.4
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime, the value of the dc:title
property shall be set to the value of the highest priority metadata (as listed below in order of
decreasing priority) available for that EPG Program Item in the source metadata.

• ProgramLocation.InstanceDescription.Title
• ProgramInformation.BasicDescription.Title
[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS IWD2N

102 822-3

[C OMMENT] At least one of the above-mentioned TV-Anytime metadata elements will be present so
that there will always be a value available to populate the dc:title property.

10.5.5.3.5
[G UIDELINE ] If the EPG Program Item metadata source is DVB-SI, the value of the dc:title property
shall be set to the value of the highest priority metadata (as listed below in order of decreasing
priority) available for that EPG Program Item in the source metadata.

• short_event_descriptor.event_name
• service_descriptor.service_name
If neither the event_name nor the service_name are available, a vendor defined value shall be
assigned.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 450 –

[ATTRIBUTES ]

M A DMS n/a n/a ETSI EN LADLI

300 468

[C OMMENT] At least one of the above-mentioned DVB-SI metadata elements will be present so that
there will always be a value available to populate the dc:title property.

10.5.5.4 MM/EPG upnp:longDescription property

10.5.5.4.1
[G UIDELINE ] If a detailed description of the EPG Program Item is available, a UPnP AV
MediaServer shall expose the upnp:longDescription property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC XR6OP

29341-14-12

[C OMMENT] The value of the upnp:longDescription property provides a summary or synopsis for
the EPG Program Item. If a suitable source for this property is not present in the source metadata,
this property is omitted in the EPG Program Item.

10.5.5.4.2
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item that does not have a DLNA
Recognized Metadata Source, the value of the upnp:longDescription property shall provide the most
descriptive summary of the EPG Program Item contents.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 74NJM

29341-14-12

10.5.5.4.3
[G UIDELINE ] If the EPG Program Item metadata source is OpenEPG, the value of the
upnp:longDescription property shall be set to the value of the highest priority metadata (as listed
below in order of decreasing priority) available for that EPG Program Item in the source metadata.

• Content.LongDescription
• Content.ShortDescription
If neither of these metadata elements are present in the source metadata, then the
upnp:longDescription property shall be omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ANSI/CEA-20 LC78K

33 A

10.5.5.4.4
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime, the value of the
upnp:longDescription property shall be set to the value of the highest priority metadata (as listed
below in order of decreasing priority) available for that EPG Program Item in the source metadata.

• (ProgramLocation.)InstanceDescription.Synopsis
• ProgramInformation.BasicDescription.Synopsis
DLNA guidelines; Part 1-1: Architecture and protocols
 – 451 –

If neither of these metadata elements are present in the source metadata, then the
upnp:longDescription property shall be omitted from the EPG Program Item.

If multiple descriptions with different length attributes (“short”, “medium”, or “long”) exist in the
source metadata, the instance with the highest length attribute (“long” > “medium” > “short”) shall be
assigned to the upnp:longDescription property.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS DBUAV

102 822-3

10.5.5.4.5
[G UIDELINE ] If the EPG Program Item metadata source is DVB-SI, the value of the
upnp:longDescription property shall be set to the value of the metadata listed below for that EPG
Program Item in the source metadata.

• short.event.descriptor.text_char
If this metadata element is not present in the source metadata, then the upnp:longDescription
property shall be omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI EN JMW5D

300 468

10.5.5.5 MM/EPG dc:language property

10.5.5.5.1
[G UIDELINE ] If a list of languages is available (as different audio tracks of the EPG Program Item),
each of these languages shall be exposed using an instance of the multi-valued dc:language
property. Languages shall be represented in conformance with IETF RFC 3066, for example,
“en-US”.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC Q477D

29341-14-12
IETF RFC
3066

[C OMMENT] The dc:language property is a multi-valued property allowing all languages to be

represented (as separate instances of the dc:language property) when an EPG Program Item has
multiple audio tracks, each in a different language.

10.5.5.5.2
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item which does not have a
DLNA Recognized Metadata Source, the EPG Program Item shall provide an instance of the
dc:language property, set to the appropriate value, for each of the languages of the audio tracks of
the associated Content Binary.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC V2ALV

29341-14-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 452 –

10.5.5.5.3
[G UIDELINE ] If the EPG Program Item metadata source is OpenEPG, then the following applies (in
order of decreasing priority).

• If the OpenEPG Event.AudioLanguages metadata is present, a dc:language property instance

shall be exposed and appropriately populated for each of the languages available in the
OpenEPG Event.AudioLanguages metadata.
• If the OpenEPG Content.PrimaryLanguage is present, an instance of the dc:language property
shall be exposed and appropriately populated with that value. In addition, for each
Content.Alternative.Language that is present, an instance of the dc:language property shall be
exposed and appropriately populated with each respective value.
• If the DistributionNetwork.ContentService.ContentServiceMapping.ServiceAudioLanguages
metadata is present, a dc:language property instance shall be exposed and appropriately
populated for each of the languages available in the OpenEPG
DistributionNetwork.ContentService.ContentServiceMapping.ServiceAudioLanguages
metadata.
In this guideline, “appropriately populated” means a conversion from IETF RFC 4646 language
code used in the OpenEPG metadata to language representations in conformance with IETF RFC
3066 is required.

If none of these metadata elements are present in the source metadata the dc:language, then
property shall be omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ANSI/CEA-20 58A9O

33 A
IETF RFC
4646
IETF RFC
3066

10.5.5.5.4
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime, then the following applies
(in order of decreasing priority).

• If one or more TV-Anytime

(ProgramLocation.)InstanceDescription.AVAttributes.AudioAttributes.AudioLanguage
metadata elements are present, a dc:language property instance shall be exposed and
appropriately populated for each of the languages available in the TV-Anytime
ProgramLocation.)InstanceDescription.AVAttributes.AudioAttributes.AudioLanguage metadata
elements. This requires a conversion from the ISO_639-1 language code, used in the
TV-Anytime metadata to language representations in conformance with IETF RFC 3066.
• If one or more TV-Anytime
ProgramInformation.AVAttributes.AudioAttributes.AudioLanguage metadata elements are
present, an instance of the dc:language property shall be exposed and appropriately populated
for each of the TV-Anytime
BasicDescription.AVAttributes.AudioAttributes.AudioLanguage metadata elements. This
requires a conversion from the ISO_639-1 language code, used in the TV-Anytime metadata to
language representations in conformance with IETF RFC 3066.
• If the TV-Anytime ProgramInformation.BasicDescription.Language metadata is present, an
instance of the dc:language property shall be exposed and populated with that value. This
requires a conversion from the ISO_639-1 language code, used in the TV-Anytime metadata to
language representations in conformance with IETF RFC 3066.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 453 –

• If the TV-Anytime ServiceInformation.ServiceLanguage metadata is present, a dc:language

property instance shall be exposed and populated with that value. This requires a conversion
from the ISO_639-1 language code, used in the TV-Anytime metadata to language
representations in conformance with IETF RFC 3066.
In this guideline, “appropriately populated” means a conversion from IETF RFC 4646 language
code used in the TV-Anytime metadata to language representations in conformance with IETF RFC
3066 is required.

If none of these metadata elements are present in the source metadata the dc:language property
shall be omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS F5TY7

102 822-3
IETF RFC
4646

10.5.5.5.5
[G UIDELINE ] If the EPG Program Item metadata source is DVB-SI, then the following applies (in
order of decreasing priority).

• If one or more DVB-SI event_information_section.component_descriptor metadata elements

are present, a dc:language property instance shall be exposed and appropriately populated for
each of the DVB-SI event_information_section.component_descriptor metadata elements. This
requires a conversion from the ISO_639 language code, used in the DVB-SI metadata to
language representations in conformance with IETF RFC 3066.
• If one or more DVB-SI service_description_section.component_descriptor metadata elements
are present, a dc:language property instance shall be exposed and appropriately populated for
each of the DVB-SI service_description_section.component_descriptor metadata elements.
This requires a conversion from the ISO_639 language code, used in the DVB-SI metadata to
language representations in conformance with IETF RFC 3066.
In this guideline, “appropriately populated” means a conversion from IETF RFC 4646 language
code used in the DVB-SI metadata to language representations in conformance with IETF RFC
3066 is required.

If none of these metadata elements are present in the source metadata the dc:language property
shall be omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI EN P2K7P

300 468
IETF RFC
4646

10.5.5.6 MM/EPG upnp:rating property

10.5.5.6.1
[G UIDELINE ] If Content Rating information is available for an audioProgram or videoProgram EPG
Program Item, it shall be exposed using the upnp:rating property. The property shall include the
upnp:rating@type property. DLNA recognized rating systems are listed in Annex J. When metadata
source systems contain rating information that conforms to one of the DLNA recognized systems
defined in Annex J the upnp:rating@type property shall be populated with a Domain name from
Annex J and the upnp:rating property shall be populated with a rating value from Annex J that
corresponds to the domain in the upnp:rating@type property. If the source metadata does not

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 454 –

include Content Rating information, the upnp:rating property shall be omitted from the EPG
Program Item.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC JMC5Q

29341-14-12
IETF RFC
3066

10.5.5.6.2
[G UIDELINE ] If the rating domain exposed by a metadata schema is one of the systems listed in
Annex J, then the properties shall be filled out as follows.

• If the system makes a parental rating available, and the <domain> is listed in the “Domain”
column of Annex J then the rating@type property shall be <domain>.
• If the system makes a parental rating available, the rating property shall be rating, where rating
is one of the valid ratings listed in the “Valid Ratings” column of Annex J for the appropriate
<domain>.
• If the rating specified in the system has an age equivalence, the device shall expose a second
rating@equivalentAge property with the value of age, where age is the age listed in the “Age
Equivalence” column of Annex J for the appropriate <domain>.
• If the rating also includes advice, the device should expose a rating@advice property with the
value of advice, where advice is a comma separated list of all the advice values that apply to this
rating, as listed in the “Valid Advice” column of Annex J for the appropriate <domain>.
Example:

<rating type=”ACMA.GOV.ORG” equivalentAge =”15” advice=”V,L,S”>MA15+</rating>

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC V9QX3

29341-14-12

[C OMMENT] The age column is intended to be used programmatically.

10.5.5.6.3
[G UIDELINE ] If there is more than one rating for an individual rating authority then only the most
restrictive rating should be exposed.

[ATTRIBUTES ]

S A DMS n/a n/a ISO/IEC AHP4I

29341-14-12

10.5.5.6.4
[G UIDELINE ] If the rating system does not match any of the ratings systems listed in Annex J, but
the rating system can be recognized by a unique and valid ICANN domain, then the device shall
expose the rating system using the rules in 10.5.5.6.2 with a <domain> value that is a valid ICANN
domain. The values of rating, equivalentAge and advice are set to any values that are specified for
that domain, where the valid values are outside the scope of these DLNA guidelines.guidelines. The
rating@type property shall be:

<domain> + “_PR” or <domain> + “_MA”

DLNA guidelines; Part 1-1: Architecture and protocols

 – 455 –

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC A23TJ

29341-14-12

10.5.5.6.5
[G UIDELINE ] If the rating system does not match any of the ratings systems listed in Annex J, and
the rating system cannot be recognized by a unique and valid ICANN domain, then the device shall
use the value “DLNA.ORG_UNKNOWN_PR:<rating system>” as the upnp:rating@type value.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 83AX3

29341-14-12

[C OMMENT] The age column is intended to be used programmatically.

10.5.5.6.6
[G UIDELINE ] If the value of rating@type is one of the following:

• “cbsc.ca/english”
• “cbsc.ca/french”
• “mpaa.org”
• “kbc.go.kr”
• “gio.gov.tw”
The rating and rating@advice property should be exposed as defined in ANSI/CEA-766-C.

[ATTRIBUTES ]

S A DMS n/a n/a ISO/IEC N66VU

29341-14-12
ANSI/CEA-76
6-C

[C OMMENT] In order to program the V-Chip, content will maintain its CEA-766 rating. This CEA-766
rating requires that all advice fields be maintained in the EPG, so that they can be translated back
to the appropriate V-Chip bits. For more information, refer to ANSI/CEA-766-C.

10.5.5.6.7
[G UIDELINE ] If the rating authority is listed in Annex J and the <rating> property value is a valid
value in the Valid Ratings column for that domain then if the rating@equivalentAge property is
empty, the device shall use the associated Age Equivalence value from Annex J as the value of
rating@equivalentAge.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC Q6UBE

29341-14-12

10.5.5.6.8
[G UIDELINE ] If the rating authority is listed in Annex J and the rating@equivalentAge value is a
valid value in the Age Equivalent column for that domain then if the rating property is empty, the
device shall use the associated rating value from Annex J as the value of the rating property.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 456 –

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 8YGTV

29341-14-12

10.5.5.6.9
[G UIDELINE ] If the EPG Program Item metadata source is OpenEPG, then the following applies (in
order of decreasing priority).

• Rating metadata in OpenEPG is found in three places. It may be associated with the Event, the
Content, or the Service. If rating data is found in more than one of these elements associated
with a single Event only the most specific metadata should be exposed. If there is Rating
metadata in the Event object then the Event Rating metadata shall be used. If there is no
metadata in the Event and there is Rating metadata in the Content object then the Content
object Rating metadata shall be used. If neither the Event nor the Content object has Rating
metadata then the rating metadata in the service object shall be used. Once the source of the
rating metadata has been determined by the above rules then the mapping is done according to
the following rules where <OpenEPGObject> is one of Event.EventContentAdvisory,
Content.ContentAdvisory, or
DistributionNetwork.ContentService.ContentServiceMapping.ContentAdvisory as determined
above.
• If the OpenEPG RatingAuthority metadata conforms to one of the DLNA recognized rating
authorities, in Annex J, then the upnp:rating@type property instance shall be exposed and
populated as follows. The <domain> parameter shall be set to the
<OpenEPGObject>.RatingAuthority metadata value as described in 10.5.5.6.2 through
10.5.5.6.6.
– upnp:rating@type = <domain>
• If the OpenEPG RatingAuthority metadata does not conform to one of the DLNA recognized
rating authorities but a valid ICANN domain name can be established that uniquely identifies
that rating authority, a upnp:rating@type property instance shall be exposed and the following
syntax and assignment shall be used:
– upnp:rating@type = <OpenEPGObject>.RatingAuthority + “_PR”
• If the OpenEPG RatingAuthority metadata does not conform to one of the DLNA recognized
rating authorities and no valid ICANN domain name can be established that uniquely identifies
that rating authority, a upnp:rating@type property instance shall be exposed and the following
syntax and assignment shall be used:
– upnp:rating@type = “DLNA.ORG_UNKNOWN_PR:” +
<OpenEPGObject>.RatingAuthority
• If the OpenEPG RatingAuthority metadata conforms to one of the DLNA recognized rating
authorities, in Annex J, then the upnp:rating property shall be exposed and populated as follows.
The <OpenEPGObject>.ParentalRating metadata value shall be mapped to the appropriate
Rating Value in Annex J.
– upnp:rating = mapped Rating Value
• If the OpenEPG RatingAuthority metadata does not conform to one of the DLNA recognized
rating authorities in Annex J, then the upnp:rating shall be set to the ParentalRating value
– upnp:rating =<OpenEPGObject>.ParentalRating
• If the OpenEPG <OpenEPGObject>.ContentAdvisory metadata is present and contains
MinimumAge then, a upnp:rating@ equivalentAge instance shall be exposed and assigned the
minimum age value.
– upnp:rating@equivalentAge = <OpenEPGObject>.MinimumAge

DLNA guidelines; Part 1-1: Architecture and protocols

 – 457 –

[ATTRIBUTES ]

M A DMS n/a n/a ANSI/CEA-20 UNCGW

33 A

10.5.5.6.10
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime, then the following applies
(in order of decreasing priority).

• If the
tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva:Ba
sicDescription/tva:ParentalGuidance metadata is present and indicates that the Program Item
conforms to one of the DLNA recognized rating authorities listed in Annex J, then a upnp:rating
and upnp:rating@type property pair instance shall be exposed and appropriately populated: the
rating@type property shall be set to the DOMAIN value in Annex J that maps to the
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva:Ba
sicDescription/tva:ParentalGuidance/mpeg7:Region metadata value and the <rating> property
shall be set to the Annex J “Valid Ratings” value that maps to the
tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva:Ba
sicDescription/tva:ParentalGuidance.ParentalRating metadata value.
• If the TV-Anytime BasicDescription/tva:ParentalGuidance/mpeg7:ParentalRating metadata is
present and indicates that the Program Item does not conform to one of the DLNA recognized
rating authorities but a valid ICANN domain name can be established that uniquely identifies
that rating authority, then a upnp:rating and upnp:rating@type property pair instance shall be
exposed and the following syntax and assignments shall be used:
– upnp:rating =
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:ParentalRating
– upnp:rating@type = <valid ICANN domain name> + “_PR”
• If the TV-Anytime BasicDescription.ParentalGuidance .ParentalRating metadata is present and
indicates that the Program Item does not conform to one of the DLNA recognized rating
authorities and no valid ICANN domain name can be established that uniquely identifies that
rating authority, then a upnp:rating and upnp:rating@type property pair instance shall be
exposed and the following syntax and assignments shall be used:
– upnp:rating =
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:ParentalRating
– upnp:rating@type = “DLNA.ORG_UNKNOWN_PR:” +
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:Region
• If the TV-Anytime BasicDescription.ParentalGuidance metadata is present and contains
MinimumAge metadata and a valid ICANN domain name can be established that uniquely
identifies that rating authority, then a upnp:rating and upnp:rating@type property pair instance
shall be exposed and the following syntax and assignments shall be used:
– upnp:rating@equivalentAge =
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:MinimumAge
– upnp:rating =
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:MinimumAge
– upnp:rating@type = < domain name> + “_MA”

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 458 –

• If the TV-Anytime
tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva:Ba
sicDescription/tva:ParentalGuidance metadata is present and contains MinimumAge metadata
and indicates that the Program Item conforms to one of the DLNA recognized rating authorities
listed in Annex J, then a upnp:rating and upnp:rating@type property pair instance shall be
exposed and the following syntax and assignments shall be used:
– upnp:rating@equivalentAge =
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:MinimumAge
– upnp:rating@type = <domain name> (from Annex J)
• If the TV-Anytime BasicDescription.ParentalGuidance metadata is present and contains
MinimumAge metadata and no valid ICANN domain name can be established that uniquely
identifies that rating authority, then a upnp:rating and upnp:rating@type property pair instance
shall be exposed and the following syntax and assignments shall be used:
– upnp:rating@equivalentAge =
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:MinimumAge
– upnp:rating =
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:MinimumAge
– upnp:rating@type = “DLNA.ORG_UNKNOWN_MA:” +
/tva:TVAMain/tva:ProgramDescription/tva:GroupInformationTable/tva:GroupInformation/tva
:BasicDescription/tva:ParentalGuidance/mpeg7:Region
If none of these metadata elements are present in the source metadata, then the upnp:rating
property shall be omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS F7NL9

102 822-3

10.5.5.6.11
[G UIDELINE ] If the EPG Program Item metadata source is DVB-SI, then the following applies (in
order of decreasing priority).

• If the DVB-SI event_information_section.parental_rating_descriptor metadata is present, then a

upnp:rating and upnp:rating@type property pair instance shall be exposed. The 24-bit country
code metadata shall be converted according to ISO 3166 and the resulting <Country> code shall
be used as follows:
• If a rating system in Annex J can be determined from the country code then
– upnp:rating@type = <domain>
– If the value of the <Rating> metadata is less than 16 then
• <Rating> = <Rating> + 3
• upnp:rating@equivalentAge= <Rating>
• upnp:rating = rating that matches the equivalentAge value
• If the rating can be mapped to a valid rating value for the specified domain then
– rating = rating value from Annex J
– upnp:rating = rating

DLNA guidelines; Part 1-1: Architecture and protocols

 – 459 –

• If a rating system in Annex J cannot be determined from the country code then the value shall be
used in the assignments below. Likewise, the 8-bit <Rating> code shall be used as follows:
– If the value of the <Rating> metadata is less than 16 then
• <Rating> = <Rating> + 3
• upnp:rating@equivalentAge= <Rating>
• upnp:rating@= <Rating>
• upnp:rating@type = “DLNA.ORG_UNKNOWN” + “_MA:” + <Country>
– else
• upnp:rating = “Broadcaster Defined:” + <Rating>
• upnp:rating@type = “DLNA.ORG_UNKNOWN” +”_PR:” + <Country>
If the metadata element is not present in the source metadata, then the upnp:rating property shall be
omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI EN LIPFO

300 468
ISO 3166

10.5.5.7 MM/EPG upnp:channelID property

10.5.5.7.1
[G UIDELINE ] An EPG Program Item CDS object may expose one or more instances of the
upnp:channelID property.

[ATTRIBUTES ]

O L DMS M-DMS n/a ISO/IEC F953R

29341-20-12

[C OMMENT] The upnp:channelID property is used across the SRS and EPG system usages as the
common identifier for channels.

10.5.5.7.2
[G UIDELINE ] If a UPnP AV MediaServer exposes one or more instances of the upnp:channelID
property, each shall have a value that identifies the channel source of the EPG Program Item. Each
upnp:channelID property shall include the upnp:channelID@type property. The upnp:channelID
property is multi-valued so that different formats can be used to identify a particular channel. When
multiple instances of the upnp:channelID property are exposed, they shall refer to the same channel
item in the CDS channel lineup. The value of the upnp:channelID@type property shall conform to
the guidelines in 10.5.5.7.3 to 10.5.5.7.11.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC WW3W8

29341-14-12

10.5.5.7.3
[G UIDELINE ] If a UPnP AV MediaServer exposes a vendor-specific channel type, then the
upnp:channelID@type value shall incorporate a valid ICANN registered domain name that uniquely
identifies the vendor.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 460 –

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC BFQIE

29341-14-12

10.5.5.7.4
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item with a
upnp:channelID@type value of “ANALOG”, then the value of the upnp:channelID property shall be
a positive integer.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC GZNAJ

29341-14-12

[C OMMENT] This enumerated type is potentially misleading as the source is not required to be an
analog broadcast source. Vendors are encouraged to use this enumerated type for any channel
items which are represented by a channel identifier consisting of a single integer.

10.5.5.7.5
[G UIDELINE ] A UPnP AV MediaServer shall not use the upnp:channelID@type value of “ANALOG”
to represent a major / minor channel number using “aliasing” (such as multiplying the major channel
number by 1 000 then adding the minor channel number). Channel numbers with a major / minor
channel number shall be exposed using the upnp:channelID@type value of “DIGITAL” as defined in
10.5.5.7.6.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC E7I45

29341-14-12

[C OMMENT] The terms analog and digital do not refer to the broadcast system. The meaning is only
distinguishing the numbering system.

10.5.5.7.6
[G UIDELINE ] If a UPnP AV Media Server exposes an EPG Program Item with a
upnp:channelID@type value of “DIGITAL”, then the value of the upnp:channelID property shall
consist of a “major” and “minor” channel number pair in the format.

• <Major Channel Number>,<Minor Channel Number>

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC LI5G3

29341-14-12

[C OMMENT] Implementers need to note that UPnP utilizes a comma to separate the major and
minor channel numbers while they are often separated with a period.

10.5.5.7.7
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item with a
upnp:channelID@type value of “SI”, then the value of the upnp:channelID property shall consist of
a Service Information Triplet in the format.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 461 –

• The <Network ID> term is a non-negative numerical value with a range of 0 to 0xFFFF. The value
is network specific and shall be represented as a decimal or hexadecimal value. The value shall
be omitted (i.e. empty string) to indicate an unknown <network ID> term.
• The <Transport Stream ID> term is a non-negative numerical value with a range of 0 to 0xFFFF.
The value is network specific and shall be represented as a decimal or hexadecimal value. The
value shall be omitted (i.e. empty string) to indicate an unknown <Transport Stream ID> term.
• The <Service ID> term is a non-negative numerical value with a range of 0 to 0xFFFF. The value
is network specific and can be represented as a decimal or hexadecimal value.
[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 3C6H7

29341-14-12

[C OMMENT] This provides clarification for the values contained within the upnp:channelID property
for the “SI” type that is lacking in ISO/IEC 29341-14-12. Examples of valid values for the
upnp:channelID are as follows:

• <upnp:channelID type=”SI”>0x1234,0xFEDC,0x0102</upnp:channelID>
• <upnp:channelID type=”SI”>12345,23456,32109</upnp:channelID>
• <upnp:channelID type=”SI”>,1,0x0102</upnp:channelID>
• <upnp:channelID type=”SI>,,0x0102</upnp:channelID>
10.5.5.7.8
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item with a
upnp:channelID@type value of “NETWORK”, then the value of the upnp:channelID property shall
consist of a properly formatted URI.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC CDIET

29341-14-12

[C OMMENT] The NETWORK type is utilized for non-traditional broadcast sources which present
content to the consumer using a “channel metaphor”.

10.5.5.7.9
[G UIDELINE ] If the EPG Program Item metadata source is OpenEPG, then the values of the
upnp:channelID and the upnp:channelID@type properties shall be obtained from the metadata as
defined below (in order of decreasing priority).

• If the OpenEPG DistributionNetwork.ContentService.ContentServiceMapping is present and

contains both the Channel and MinorChannel metadata elements, then:
– upnp:channelID = Channel + “,” + MinorChannel
– upnp:channelID@type = “DIGITAL”
• If the OpenEPG DistributionNetwork.ContentService.ContentServiceMapping is present and
contains only the Channel metadata element, then:
– upnp:channelID = Channel
– upnp:channelID@type = “ANALOG”

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 462 –

• If the OpenEPG DistributionNetwork.ContentService.ContentServiceMapping is present and

contains the URLSource metadata element, then:
– upnp:channelID = URLSource
– upnp:channelID@type = “NETWORK”
[ATTRIBUTES ]

M A DMS n/a n/a ANSI/CEA-20 X6ZPW

33 A

10.5.5.7.10
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime, then the values of the
upnp:channelID and the upnp:channelID@type properties shall be obtained from the metadata as
defined below (in order of decreasing priority).

• If the TV ProgramLocationTable.ProgramURL is present and its value starts with the string
“dvb://”, then:
– upnp:channelID = <Network ID> + “,” + <Transport Stream ID> + “,” + <Service ID> as parsed
from the ProgramURL metadata according to ETSI TS 102 822-3 and ETSI TS 102 822-4
– upnp:channelID@type = “SI”
• If the TV ProgramLocationTable.ProgramURL is present and its value starts with the string
“PAL://”, “NTSC://”, or “SECAM://” then:
– upnp:channelID = <channel> as parsed from the ProgramURL metadata according to
ETSI TS 102 822-3 and ETSI TS 102 822-4
– upnp:channelID@type = “ANALOG”
If none of these properties are present in the source metadata the upnp:channelID property shall be
omitted for the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS EAR7P

102 822-3
ETSI TS
102 822-4

10.5.5.7.11
[G UIDELINE ] If the EPG Program Item metadata source is DVB-SI, then the value of the
upnp:channelID shall be obtained from the SDT table metadata as defined below.

• upnp:channelID = original_network_id + “,” + transport_stream_id + “,” + service_id

• upnp:channelID@type = “SI”
[ATTRIBUTES ]

M A DMS n/a n/a ETSI EN TDN6K

300 468

10.5.5.7.12
[G UIDELINE ] If a UPnP AV MediaServer exposes a Channelized EPG Program Item, then it shall
include one or more instances of the upnp:channelID property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC FBS7S

29341-14-12

DLNA guidelines; Part 1-1: Architecture and protocols

 – 463 –

[C OMMENT] The upnp:channelID property identifies the channel through which the Program Item
will be delivered through for channelized content.

10.5.5.8 MM/EPG upnp:channelID@distriNetworkID property

10.5.5.8.1
[G UIDELINE ] A UPnP AV MediaServer EPG Program Item shall include the
upnp:channelID@distriNetworkID property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC W5EQB

29341-14-12

[C OMMENT] The upnp:channelID@distriNetworkID property identifies the Distribution Network

from which the channel is sourced.

10.5.5.8.2
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item which does not have a
DLNA Recognized Metadata Source, then the value of the upnp:channelID@distriNetworkID
property shall reflect the distribution source of the channel.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 2PPZ2

29341-14-12

[C OMMENT] The upnp:channelID@distriNetworkID property is used by the user/application to

determine which server/service will provide the content.

10.5.5.8.3
[G UIDELINE ] If the EPG Program Item metadata source is OpenEPG, then the value of the
upnp:channelID@distriNetworkID property shall be set to the value of the OpenEPG
DistributionNetwork.DistributionNetworkID metadata.

[ATTRIBUTES ]

M A DMS n/a n/a ANSI/CEA-20 LA35C

33 A

10.5.5.8.4
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime, then the
upnp:channelID@distriNetworkID property shall contain information that allows the user/application
to determine the server/service providing the content identified by the EPG metadata.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS ANNC2

102 822-3

10.5.5.8.5
[G UIDELINE ] If the EPG Program Item metadata source is DVB-SI, then the value of the
upnp:channelID@distriNetworkID property shall be set to the network_id of the NIT table

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 464 –

[ATTRIBUTES ]

M A DMS n/a n/a ETSI EN J3BRD

300 468

10.5.5.9 MM/EPG upnp:channelID@distriNetworkName property

10.5.5.9.1
[G UIDELINE ] A UPnP AV MediaServer EPG Program Item should include the
upnp:channelID@distriNetworkName property.

[ATTRIBUTES ]

S A DMS M-DMS Na ISO/IEC NZF7S

29341-14-12

[C OMMENT] The upnp:channelID@distriNetworkName property identifies the Distribution Network

from which the channel is sourced.

10.5.5.9.2
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item which does not have a
DLNA Recognized Metadata Source, the value of the upnp:channelID@distriNetworkName
property should reflect the distribution source of the channel.

[ATTRIBUTES ]

S A DMS n/a n/a ISO/IEC W7ETL

29341-14-12

10.5.5.9.3
[G UIDELINE ] If the EPG Program Item metadata source is OpenEPG, then the value of the
upnp:channelID@distriNetworkName property shall be set to the value of the highest priority
metadata (as listed below in order of decreasing priority) available for the specific EPG Program
Item in the source metadata.

• DistributionNetwork.Name
• DistributionNetwork.DistributionNetworkID
[ATTRIBUTES ]

M A DMS n/a n/a ANSI/CEA-20 7XVTL

33 A

10.5.5.9.4
[G UIDELINE ] If the EPG Program Item metadata source is DVB-SI, then the value of the
upnp:channelID@distriNetworkName property shall be set to the

• Network_name_descriptor in the NIT

If this property is not present in the source metadata the upnp:channelID@distriNetworkName
property shall be omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI EN HUM35

300 468

DLNA guidelines; Part 1-1: Architecture and protocols

 – 465 –

10.5.5.10 MM/EPG time related properties

10.5.5.10.1
[G UIDELINE ] An EPG Program Item should include the upnp:scheduledStartTime,
upnp:scheduledStartTime@usage, upnp:scheduledEndTime, and upnp:scheduledDuration
properties.

[ATTRIBUTES ]

S A DMS M-DMS n/a ISO/IEC CGDZ5

29341-20-12

[C OMMENT] The upnp:scheduledStartTime property indicates the time the Program Item is
scheduled to start or become available. The upnp:scheduledEndTime property indicates the time
the Program Item is scheduled to end or cease to be available. The upnp:scheduledDuration
property indicates the actual duration of the program content. Control points need to examine the
upnp:scheduledStartTime@usage property to obtain the context of the time values.

10.5.5.10.2
[G UIDELINE ] If an EPG Program Item exposes the upnp:scheduledStartTime or
upnp:scheduledEndTime property, the property value shall represent local time.

[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC O3SSH

29341-14-12

10.5.5.10.3
[G UIDELINE ] If a UPnP AV MediaServer exposes an EPG Program Item which does not have a
DLNA Recognized Metadata Source, then the values of the upnp:scheduledStartTime,
upnp:scheduledStartTime@usage, upnp:scheduledEndTime, and upnp:scheduledDuration
properties shall be set as follows.

• If the Program Item refers to scheduled program content, then the value of the
upnp:scheduledStartTime property shall reflect the time the program content is scheduled to
start. The value of the upnp:scheduledEndTime property shall reflect the time the program
content is scheduled to end. The upnp:scheduledStartTime@usage property shall be set to
“SCHEDULED_PROGRAM”. The value of the upnp:scheduledDuration property shall reflect the
duration of the program content. One of the fields, upnp:scheduledDuration or
upnp:scheduledEndTime, could be empty. Its value can be calculated from the other field and
upnp:scheduledStartTime.
• If the Program Item refers to on-demand program content, then the value of the
upnp:scheduledStartTime property shall indicate the beginning of the time window during which
the on-demand content is available for consumption. The value of the upnp:scheduledEndTime
property shall indicate the end of the time window during which the on-demand content is
available for consumption. The upnp:scheduledStartTime@usage property shall be set to
“ON_DEMAND”. The value of the upnp:scheduledDuration property shall reflect the duration of
the program content and never the length of the time window during which the on-demand
content is available for consumption.
[ATTRIBUTES ]

M A DMS n/a n/a ISO/IEC 3GTOF

29341-14-12

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 466 –

10.5.5.10.4
[G UIDELINE ] If the EPG Program Item metadata source is OpenEPG, then the values of the
upnp:scheduledStartTime, upnp:scheduledStartTime@usage, upnp:scheduledEndTime, and
upnp:scheduledDuration properties shall be set as follows.

• If the OpenEPG Event.StartTime is present, then:

– upnp:scheduledStartTime = Event.StartTime
– upnp:scheduledStartTime@usage = “SCHEDULED_PROGRAM”
• If the OpenEPG Event.EndTime metadata is present, then:
– upnp:scheduledEndTime = Event.EndTime
– upnp.scheduledDuration = Event.Duration or Event.EndTime – Event.StartTime
• If the OpenEPG Event.Duration metadata is present, then:
– upnp:scheduledEndTime = Event.EndTime or Event.StartTime + Event.Duration
– upnp.scheduledDuration = Event.Duration
• If the OpenEPG Event.VODStartTime and Event.VODEndTime metadata are present, then:
– upnp:scheduledStartTime = Event.VODStartTime
– upnp:scheduledStartTime@usage = “ON_DEMAND”
– upnp:scheduledEndTime = Event.VODEndTime
– upnp.scheduledDuration = Event.Duration
• If both OpenEPG Event.Duration and OpenEPG Event.scheduledEndTime are missing:
– upnp:scheduledEndTime = OpenEPG Event.StartTime (of the following Event)
– upnp.scheduledDuration = OpenEPG Event.StartTime (of the following Event) – OpenEPG
Event.StartTime (of this Event)
[ATTRIBUTES ]

M A DMS n/a n/a ANSI/CEA-20 2Z8FJ

33 A

[C OMMENT] If one of the fields, Event.Duration or Event.scheduledEndTime, is empty its value

needs to be calculated from the other field and Event.StartTime. If both are missing the
Event.StartTime of the following event can be used as the Event.EndTime for this event.

10.5.5.10.5
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime, then the values of the
upnp:scheduledStartTime, upnp:scheduledStartTime@usage, upnp:scheduledEndTime, and
upnp:scheduledDuration properties shall be set or omitted as follows in 10.5.5.10.6 and
10.5.5.10.7.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS Z2FIY

102 822-3

10.5.5.10.6
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime and the programURL is
published with the schedule metadata and

• it is a ScheduleEvent then:

DLNA guidelines; Part 1-1: Architecture and protocols

 – 467 –

– upnp:scheduledStartTime =
/tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:Schedule/tva:Schedu
leEvent/tva:PublishedStartTime
– upnp:scheduledEndTime =
/tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:Schedule/tva:Schedu
leEvent/tva:PublishedEndTime
– upnp:scheduledDuration =
/tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:Schedule/tva:Schedu
leEvent/tva:PublishedDuration
– upnp:scheduledStartTime@usage property = “SCHEDULED_PROGRAM”
• it is a BroadcastEvent then:
– upnp:scheduledStartTime =
/tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:BroadcastEvent/tva:
PublishedStartTime
– upnp:scheduledEndTime =
/tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:BroadcastEvent/tva:
PublishedEndTime
– upnp:scheduledDuration =
tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:BroadcastEvent/tva:P
ublishedDuration
– upnp:scheduledStartTime@usage property = “SCHEDULED_PROGRAM”
• it is a OnDemandProgram then:
– upnp:scheduledStartTime =
/tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:OnDemandProgram/t
va:StartOfAvailability
– upnp:scheduledEndTime =
/tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:OnDemandProgram/t
va:EndOfAvailability
– upnp:scheduledDuration =
/tva:TVAMain/tva:ProgramDescription/tva:ProgramLocationTable/tva:OnDemandProgram/t
va:PublishedDuration
– upnp:scheduledStartTime@usage property = “ON DEMAND”
[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS G5BHR

102 822-3

10.5.5.10.7
[G UIDELINE ] If the EPG Program Item metadata source is TV-Anytime and the programURL is the
result of resolving a CRID into a locator then:

• upnp:scheduledStartTime@usage =
/cr:ContentReferencingTable/cr:Result/cr:LocationsResult/cr:DecomposedLocator@mode
(scheduled or ondemand) -> upnp:scheduledStartTime@usage
– A broadcast event, which is a non-scheduled event (e.g. a news flash) is not concerned by
CRID resolution.
• upnp:scheduledStartTime =
/cr:ContentReferencingTable/cr:Result/cr:LocationsResult/cr:DecomposedLocator@start ->

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 468 –

• upnp:scheduledDuration =
/cr:ContentReferencingTable/cr:Result/cr:LocationsResult/cr:DecomposedLocator@duration
• upnp:scheduledEndTime =
/cr:ContentReferencingTable/cr:Result/cr:LocationsResult/cr:DecomposedLocator@end
If neither of these properties are present in the source metadata, then the upnp:scheduledStartTime,
upnp:scheduledStartTime@usage, upnp:scheduledEndTime, and upnp:scheduledDuration
properties shall be omitted from the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI TS IYW6R

102 822-3

[C OMMENT] The programURL can be available from different sources. It is published with the
schedule metadata and TV-Anytime addresses three types of programmes: Broadcast events (for
instance an unscheduled news announcement), schedule events (or SCHEDULED PROGRAMME)
and on-demand programmes. The mode upnp:scheduledStartTime@usage is derived from the root
(inc. onDemand).

10.5.5.10.8
[G UIDELINE ] If the EPG Program Item metadata source is DVB-SI, then the values of the
upnp:scheduledStartTime, upnp:scheduledStartTime@usage, upnp:scheduledEndTime, and
upnp:scheduledDuration properties shall be set as follows:

• upnp:scheduledStartTime = event.information.section.start_time
+time_offset_section.local_time
• upnp:scheduledStartTime@usage = “SCHEDULED_PROGRAM”
• upnp:scheduledEndTime = event.information.section.start_time +
event.information.section.duration +time_offset_section.local_time
• upnp:scheduledDuration = event.information.section.duration
If one or more of the properties are not present in the source metadata, then the
upnp:scheduledStartTime, upnp:scheduledStartTime@usage, upnp:scheduledEndTime, and
upnp:scheduledDuration properties shall be omitted for the EPG Program Item.

[ATTRIBUTES ]

M A DMS n/a n/a ETSI EN ZSIPA

300 468

10.5.5.11 MM/EPG @daylightSaving properties

[G UIDELINE ] A EPG Program Item shall include the upnp:scheduledStartTime@daylightSaving
and upnp:scheduledEndTime@daylightSaving properties. Both properties shall have the same
value and this property. The value of the property shall indicate whether the time values are
expressed in Standard Time or Daylight Saving Time, and shall accurately reflect the application of
Daylight Saving Time to the local time of the EPG Server.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC NHECC

29341-14-12
IETF RFC
3066

[C OMMENT] The upnp:scheduledStartTime property will be expressed in local time including the
DLNA guidelines; Part 1-1: Architecture and protocols
 – 469 –

indication of Daylight Saving Time. When an EPG Server is in a location where Daylight Saving
Time is not observed, this property is still needed and all times will indicate Standard Time.

10.5.6 MM/EPG exposing foreign metadata

10.5.6.1
[G UIDELINE ] The upnp:foreignMetadata::fmEmbeddedXML property of an EPG Item shall only
contain information pertaining to the single program event that this EPG Item represents. The
property value shall be a valid XML document in the format indicated by the
upnp:foreignMetadata@type property.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WJLQV

29341-14-12

10.5.6.2
[G UIDELINE ] For foreign metadata from TVAnytime the @type property of a::fmEmbeddedXML
property in a CDS Event object shall have the value of “tv-anytime.org_1” to indicate TV-Anytime
based metadata.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC EHTZM

29341-14-12

10.5.6.3
[G UIDELINE ] If the value of the @type property of a::fmEmbeddedXML property in a CDS Event
object is “tv-anytime.org_1”, then the::TVAMain property shall include a::ProgramInformationTable
property which shall include a BasicDescription property for the current EPG Item. TV-Anytime
information from different tables shall be integrated into a single <TVAMain> element.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 889NO

29341-14-12

[C OMMENT] An example of an EPGItem with TV-Anytime foreign metadata is provided below. It

contains a single program description as well as a location description of this program.

<upnp:foreignMetadata type="tv-anytime.org_1">
<upnp:fmId></upnp:fmId>
<upnp:fmClass></upnp:fmClass>
<upnp:fmProvider>dlna.examples.com</upnp:fmProvider>
<upnp:fmBody xmlFlag="1" mimeType="text/xml">
<upnp:fmEmbeddedXML>
<TVAMain xmlns='urn:tva:metadata:2005' xmlns:mpeg7='urn:tva:mpeg7:2005'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xml:lang='en'>
<ProgramDescription>
<ProgramInformationTable>
<ProgramInformation programId="crid://dlna.examples.com
/8730311156">
<BasicDescription>
<Title><Hot tech></Title>
<Synopsis length="short">Popular science program explaining the
wonders of DLNA home networks.</Synopsis>
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 470 –

<Genre href="urn:tva:metadata:cs:IntentionCS:2004:1.2">
<Name>Information</Name>
</Genre>
</BasicDescription>
<AVAttributes>
<AudioAttributes>
<NumOfChannels>2</NumOfChannels>
</AudioAttributes>
<VideoAttributes>
<AspectRatio>16:9</AspectRatio>
</VideoAttributes>
</AVAttributes>
</ProgramInformation>
</ProgramInformationTable>
<ProgramLocationTable>
<Schedule serviceIDRef='HotSci' start='2007-06-01T00:00:00Z'
end='2007-06-01T23:59:59Z'>
<ScheduleEvent>
<Program crid="crid://dlna.examples.com/8730311156"></Program>
<ProgramURL>dvb://277f.ff00.2250;787@2007-06-01T21:00:00Z/PT01H45M</ProgramURL>
<PublishedStartTime>2007-061T21:00:00Z</PublishedStartTime>
<PublishedDuration>PT01H45M00S</PublishedDuration>
</ScheduleEvent>
</Schedule>
</ProgramLocationTable>
</ProgramDescription>
</TVAMain>
</upnp:fmEmbeddedXML>
</upnp:fmBody>
</upnp:foreignMetadata>

10.5.6.4
[G UIDELINE ] If the value of the @type property of a::fmEmbeddedXML property in a CDS Event
object is “tv-anytime.org_1”, then the <ProgramDescription> element of::TVAMain property may
contain other tables having with information related to the current EPG Item (such as the
ProgramLocationTable).

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC C3FU7

29341-14-12

10.5.6.5
[G UIDELINE ] For foreign metadata from OpenEPG the @type property of a::fmEmbeddedXML
property in a CDS Event object shall have the value of “openepg.org_v1” to indicate
OpenEPG-based metadata.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC OFZPQ

29341-14-12

10.5.7 MM/EPG search guidelines

10.5.7.1
[G ENERAL ] This defines the search requirements for UPnP AV MediaServers that implement the
EPG Server Device Option. The mechanism to obtain EPG data from a server is based on search
DLNA guidelines; Part 1-1: Architecture and protocols
 – 471 –

queries using the CDS:FreeFromQuery() action. A subset of the XQuery language is defined to
allow for efficient implementations.

10.5.7.2
[G UIDELINE ] A UPnP AV MediaServer implementing the EPG Server Device Option shall
implement the CDS:FreeFormQuery action.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 9TP5W

29341-14-12

[C OMMENT] UPnP AV MediaServer control points rely on FreeFormQuery searches to select

EPGItems exposed by the CDS.

10.5.7.3
[G UIDELINE ] If the full XQuery language is supported for a certain sub-tree, its ObjectID@level
attribute as defined in 10.5.2.5 shall be set to “0”. If a subset of XQuery is supported, the
ObjectID@level shall be a comma separated value list containing values that identify the subset(s)
being supported. The comma separated value list shall not contain the value “0”. The first value in
the comma separated value list shall be “DLNA_EPG”.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 6ZJXJ

29341-14-12

[C OMMENT] Control points can use the ObjectID@level to check what level of XQuery complexity
this server can handle. Vendors can define additional values to indicate support of additional
XQuery subsets. The definition and usage of these vendor-defined values are out of scope.

10.5.7.4
[G UIDELINE ] If a UPnP AV MediaServer includes the @id attribute of a CDS container in the
<ObjectIDs> element of the <Feature> element defined in 10.5.2.3 (i.e. the EPG, EPGDataOnly
<Feature> element), then one of the <ObjectID> elements of the <Feature> element defined in
10.5.2.5 (i.e. the FFQ <Feature> element) shall contain the @id attribute of that CDS container or
one of its ancestor containers.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC EC7BH

29341-14-12

[C OMMENT] DLNA requires the CDS:FreeFormQuery action to be at least supported for all
exposed EPG Containers. For example, when a UPnP AV MediaServer exposes two EPG trees, the
ObjectIDs are listed in the result of the CDS:GetFeatureList action for the EPG feature. The FFQ
<Feature> element indicates that CDS:FreeFormQuery is supported for these two EPG containers.
This means that the FFQ <Feature> element can list these two ObjectIDs, one of the listed
ObjectIDs plus an ancestor ObjectID, two different ancestors, or one common ancestor. An example
of the latter case is a UPnP AV MediaServer which allows CDS:FreeFormQuery actions on all
containers. In this case the FFQ <Feature> element will contain the root ObjectID.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 472 –

10.5.7.5
[G UIDELINE ] A UPnP AV MediaServer that implements the EPG Server Device Option shall support
the XQuery language subset defined by the following EBNF notation. This subset is referred to as
the “DLNA_EPG” level XQuery.

This level of XQuery uses the constructor to produce a DIDL-Lite compliant document.

• Query ::= ConstructorSTag EnclosedExpression ConstructorETag

The DIDL-Lite fragment is specified as a constructor. The start tag shall have namespace
declarations for the specified properties used in the query body.

• ConstructorSTag::= ‘<DIDL-Lite’ DidlliteNSAttName DcNSAttName? UpnpNSAttName?

OtherNSAttName* ‘>
• DidlliteNSAttName ::= 'xmlns= "urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/ "’
• DcNSAttName ::= ‘xmlns:dc=”http://purl.org/dc/elements/1.1/”’
• UpnpNSAttName ::= ’xmlns:upnp=“urn:schemas-upnp-org:metadata-1-0/upnp/“’
• OtherNSAttName ::= <Any other namespaces used in the query body shall be declared. See
http://www.w3.org/TR/REC-xml-names/ for the syntax definitions.>
The main query body uses a Flwor expression. Like StartCount and RequestedCount arguments of
a CDS::Browse action, an EPG Controller can limit the returned items to the specified range from
the entire result with “fn:position”.

• EnclosedExpression ::= ‘{‘ SingleMainExpr ‘}’

• SingleMainExpr ::= FlworExpr | ‘(‘ FlworExpr ‘)’ ‘[‘ ‘fn:position()’ ‘=’ ‘(‘ Integer “to” Integer ‘)’ ‘]’
• FlworExpr ::= ForClause WhereClause? OrderByClause? ReturnClause
The For clause is static. Only items of epgItem or its derived class can be queried. DIDL-Lite is
always specified as a root document even if the query is scoped in an EPG tree of the CDS. The
UPnP AV MediaServer that implements the EPG Server Device Option shall limit the search scope
within the subtree specified in the CDS::FreeFormQuery action. NoRef shall be specified in this
level. This removes all duplicated epgItems from the result.

• ForClause ::= ‘for’ ‘$x’ ‘in’ ‘DIDL-Lite//item’ ‘[‘ EPGItem ‘AND’ NoRef ‘]’
• EPGItem ::= ‘fn:starts-with(upnp:class,’object.item.epgItem’)’
• NoRef ::= ’fn:not(fn:exists(@refID))’
An EPG Controller can request filtering of the epgItems out by time range, channel, title and long
description. Channel line up can be structured per distribution network.

• WhereExpr ::= ‘where’ TimeExpr (‘AND’ ChannelExpr)? (‘AND’ StringExpr)?

• TimeExpr ::= ‘$x/upnp:scheduledStartTime’ ‘>=’ TimeLiteral ‘AND’
‘$x/upnp:scheduledEndTime ‘ ‘<’ TimeLiteral
• TimeLiteral ::= <search value. see x.x.x.x for the syntax of timeliteral properties.>
• ChannelExpr ::= Channel | ‘(‘ ChannelList ‘)’ | ChannelDistr | ‘(‘ChannelDistriList ‘)’
• ChannelList ::= Channel (‘OR’ Channel)*
• ChannelDistriList ::= ChannelDistri (‘OR’ ChannelDistri)*
• Channel ::= ‘$x/upnp:channelID’ ‘=’ Identifier
• ChannelDistri ::= ‘$x/upnp:channelID/@distriNetworkID’ ‘=’ Identifier ‘AND’ ( Channel |
‘(‘ ChannelList ‘)’ )

DLNA guidelines; Part 1-1: Architecture and protocols

 – 473 –

• Identifier ::= <search target value>

• StringExpr ::= StrCmpANDList | ‘(‘StrCmpORList ‘)’
• StrCmpANDList ::= StrCmp (‘AND’ StrCmp)*
• StrCmpORList ::= StrCmp (‘OR’ StrCmp)*
• StrCmp ::= ‘fn:contains(‘ ‘$x/’ StrCmpProp ‘,’ ‘"’ Identifier ‘"’ ‘)’
• StrCmpProp ::= ‘dc:title’ | ‘upnp:longDescription’
An EPG Controller can request sorting of the result by start time and channel. Channel line up can
be structured per distribution network. Only ascending order is allowed.

• OrderByClause ::= ‘order by’ SortList

• SortList ::= ((SortDistriNetworkID “,”)? SortChannelID “,”)? SortStartTime
• SortDistriNetworkID ::= ‘$x/upnp:channelID/@distriNetworkID’ ‘ascending’
• SortChannelID ::= ‘$x/upnp:channelID’ ‘ascending
• SortStartTime ::= ‘$x/upnp:scheduledStartTime’ ‘ascending’
When the FilterPropList notation is used, the specified properties will return like the Filter argument
of CDS::Browse action. When “$x” is specified, all properties in each epgItem will return like the “*”
specification in the argument. In the former case, the UPnP AV MediaServer that implements the
EPG Server Device Option shall complement mandatory properties (i.e. @id, @parentID, etc) in the
result document to keep the returned DIDL-Lite document valid. In the latter case, when the retuned
item includes properties whose namespaces are not declared in the requested ConstructorSTag,
the UPnP AV MediaServer that implements the EPG Server Device Option shall add appropriate
namespace declarations in the returned DIDL-Lite start tag.

• ReturnClause::= ‘return’ (‘<item>’ ‘{‘ FilterPropList ‘}’ ‘</item>’ | ‘$x’ )

• FilterPropList::= FilterProp (‘,’ FilterProp)*
• FilterProp::= elem-spec | att-spec
• elem-spec::= direct-elem-spec | nested-elem-spec
• direct-elem-spec::= ‘$x/’element-name
• element-name::= char*
• nested-elem-spec::= ‘{‘ nested-elem-constBegin ‘{‘ nested-elem-val-spec ‘}’
nested-elem-constEnd ‘}’
• nested-elem-constBegin::= elemBegin*
• elemBegin::= ‘<’ element-name ‘>’
• nested-elem-constEnd::= elemEnd*
• elemEnd::= ‘</’ element-name ‘>’
• nested-elem-val-spec::= ‘$x/’element-name’/’(element-name’/’)*’text()’
• att-spec::= item-att-spec | property-att-specs
• item-att-spec::= ‘$x/@’attribute-name
• attribute-name::= char*
• property-att-specs::= ‘{‘ nested-elem-constBegin ‘{‘ nested-elem-val-spec
nested-elem-att-spec* ‘}’ nested-elem-constEnd ‘}’
• nested-elem-att-spec::= ‘$x/’element-name’/’(element-name’/’)*’@’attribute-name

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 474 –

• ConstructorETag ::= ’</DIDL-Lite>’

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC GHIF3

29341-14-12

[C OMMENT] A UPnP AV MediaServer that implements the EPG Server Device Option does not
need to support the full XQuery language. This guideline defines a subset of the XQuery language
ISO/IEC 29341-14-12. The goal of this subset is to allow for efficient implementations (on
embedded platforms). This subset is referred to as level “DLNA_EPG”. In Annex I further
explanation of this subset is provided.

10.5.7.6
[G UIDELINE ] A UPnP AV MediaServer that implements the EPG Server Device Option may support
the XQuery language subset defined by the following EBNF notation. This subset is referred to as
the “DLNA_EPG_EXPANDED” XQuery level.

• QueryBody::= NameSpaceDecl EnclosedExpression| prologConstructor

• NameSpaceDecl::= DidlliteNSDecl DcNSDecl? UpnpNSDecl? OtherNSDecl*
• DidlliteNSDecl::= ‘declare’ ‘default’ ‘namespace’DidlliteNSAttName;
• DcNSDecl::= ‘declare’ ‘namespace’ DcNSAttName;
• UpnpNSDecl::= ‘declare’ ‘namespace’ UpnpNSAttName;
• OtherNSDecl::= ‘declare’ ‘namespace’ OtherNSAttName;
Some of definitions are from 10.5.7.5.

• prologConstructor::= ConstructorSTagEnclosedExpressionConstructorETag
• EnclosedExpression ::= ‘{‘ SingleMainExpr ‘}’
• SingleMainExpr::= FlworExpr | ( ‘(‘ FlworExpr ‘)’ ‘[‘ ‘fn:position()’ ‘=’ Integer ‘to’ Integer ‘)’ ‘]’ )
• FlworExpr::= ForClause WhereClause? OrderByClause? ReturnClause
• ForClause::= ‘for’ Variable ‘in’ ForExpr
• Variable::= ‘$’ ‘VarName’
• VarName::= QName
• QName::= PrefixedName | UnprefixedName
• PrefixName::= Prefix ‘:’ LocalPart
• UnprefixedName::= LocalPart
[C OMMENT] “Prefix” and “LocalPart” are from the XML specification. The detail definitions are
defined in W3C Namespaces.

• ForExpr::= (PathStart PathExpr) | ‘fn:distinct-values’ ‘(‘ PathStart PathExpr ‘)’

• PathStart::= ‘DIDL-Lite//item’ | ‘DIDL-Lite//container’
• PathExpr::= ((‘/’ Pname) | (‘//’ Pname) | Predicate)*
• Predictate::= ‘[‘ Expr* ‘]’
• Pname::= QName | (‘@’ UnprefixedName
• WhereClause::= ‘where’ Expr
• Expr::= Property | Comparison | (Expr ‘or’ Expr) | (Expr ‘and’ Expr) | (‘(’ Expr ‘)’) | Function
DLNA guidelines; Part 1-1: Architecture and protocols
 – 475 –

• Property::= (Variable PathExpr) | PathExpr

• Comparison ::= Property CompOperator Literal
• CompOperator::= ‘=’ | ‘!=’ | ‘<’ | ‘<=’ | ‘>’ | ‘>=’
“Function” is defined in W3C XQuery.

• OrderByClause::= ‘order by’ SortList

• SortList::= (Property SortDirection?) | (‘,’ Property SortDirection?)*
• SortDirection::= ‘Ascending’ | ‘Descending’
• ReturnClause::= (‘return’ Variable PathExpr?) | (‘return’ Constructor)
• Constructor ::= (‘<’ UnprefixedName DirAttributeList? ‘/>’) | (‘<’ UnprefixedName
DirAttributeList? ‘>’ DirElemContent ‘</’ UnprefixedName ‘>’ ReturnExpression?
• DirAttributeList::= (UnprefixedName ‘=’ ‘"’ Literal ‘"’)+
• DirElemContent::= ‘{‘ Expr (“,” Expr)* ‘}’
• ReturnExpression::= ‘[‘ Expr* ‘]’
• Literal::=NumericLiteral | StringLiteral
• NumericLiteral::=IntegerLiteral | DecimalLiteral | DoubleLiteral
• IntegerLiteral::=Digits [195] DecimalLiteral::=("." Digits) | (Digits "." [0-9]*)
• DoubleLiteral::=(("." Digits) | (Digits ("." [0-9]*)?)) ("e" | "E") ("+" | "-")? Digits
• StringLiteral::=('"' (('"' '"') |[^"])* '"') | ("'" (("'" "'") | [^'])* "'")
[ATTRIBUTES ]

O R DMS M-DMS n/a ISO/IEC PIUCS

29341-14-12
W3C
Namespaces
W3C XQuery

[C OMMENT] A UPnP AV MediaServer that implements the EPG Server Device Option does not
need to support the full XQuery language. This requirement defines a subset of the XQuery
language ISO/IEC 29341-14-12. The goal of this subset is to allow for searching and retrieval of
most typically needed EPG items. This subset is referred to as level “DLNA_EPG_ EXPANDED”. In
Annex I further explanation of this subset is provided.

10.5.7.7
[G UIDELINE ] A UPnP AV MediaServer that implements the EPG Server Device Option shall support
the following properties in the ForClause, WhereClause, OrderByClause, and ReturnClause of the
XQuery expression.

• dc:title
• upnp:channelName
• upnp:channelID
• upnp:scheduledStartTime
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC Q66BU

29341-14-12
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 476 –

[C OMMENT] The CDS:GetFreeFormQueryCapabilities action returns an XML-based capability list

in the FFQCapabilities argument. This list defines which properties are allowed in the XQuery,
hence it defines the minimum set of properties which can be used for searching, sorting, and
filtering.

10.5.7.8
[G UIDELINE ] A UPnP AV MediaServer that implements the “DLNA_EPG” level XQuery subset shall
support the following additional properties in the ForClause, WhereClause and ReturnClause of the
XQuery expression.

• dc:class
• upnp:channelID/@type
• upnp:scheduledEndTime
• upnp:scheduledDuration
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 74T34

29341-14-12

[C OMMENT] Sorting of these properties is optional.

10.5.7.9
[G UIDELINE ] A UPnP AV MediaServer that implements the “DLNA_EPG_ EXPANDED” level
XQuery subset shall support the following additional properties in the ForClause, WhereClause and
ReturnClause of the XQuery expression.

• didl-lite:item/@id
• didl-lite:item/@parentid
• didl-lite:container/@id
• didl-lite:container/@parentid
• didl-lite:res/@protocolInfo
• didl-lite:res/@refID
• dc:creator
• upnp:class
• upnp:channelID/@type
• upnp:channelID/@distriNetworkName
• upnp:scheduledEndTime
• upnp:scheduledDuration
• upnp:longDescription
[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 8DWDW

29341-14-12

[C OMMENT] Sorting of these properties is optional.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 477 –

10.5.7.10
[G UIDELINE ] A UPnP AV MediaServer that implements the EPG Server Device Option shall
implement the CDS:GetFreeFormQueryCapabilities action as defined in ISO/IEC 29341-14-12.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC 85U35

29341-14-12

10.5.7.11
[G UIDELINE ] If the UPnP AV MediaServer supports a subset of XQuery the
CDS:GetFreeFormQueryCapabilities action, and there are properties that are allowed anywhere in
the XQuery except the “order-by” clause, it shall return a list defined by <searchOnlyPropertyList>.
This list shall at least contain the <propertyName> elements, defined in 10.5.7.5 unless that
property is already listed in the <propertyList> (see ISO/IEC 29341-20-12).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC OXGLO

29341-14-12

[C OMMENT] This list defines the properties that can be used for searching, but not for sorting, and
complements the list defined in ISO/IEC 29341-14-12. When a UPnP AV MediaServer allows
sorting on more properties than the minimal required set, e.g. sorting on upnp:class, these
properties will be added to the <propertyList> and will not appear in the <searchOnlyPropertyList>.

10.5.7.12
[G UIDELINE ] If a UPnP AVMediaServer allows for searching and sorting using foreign-metadata
properties in an XQuery, then these properties shall be listed in the <propertyList> as defined in
ISO/IEC 29341-14-12. Each property shall be fully qualified as defined in ISO/IEC 29341-14-12.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC TOUKX

29341-14-12

10.5.7.13
[G UIDELINE ] If a UPnP AVMediaServer allows for searching but not sorting using foreign-metadata
properties in an XQuery, then these properties shall be listed in the <searchOnlyPropertyList> as
defined in 10.5.7.11. Each property shall be fully qualified as defined in ISO/IEC 29341-14-12.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC YFF39

29341-14-12

10.5.7.14
[G UIDELINE ] The <namespaceList> element in the FFQCapabilities argument returned by the
CDS:GetFreeFormQueryCapabilities action shall list the namespaces used for the properties in the
<propertyList> and the <searchOnlyPropertyList>. This includes the namespaces of
foreign-metadata properties that are present in the <propertyList> or the <searchOnlyPropertyList>.
It shall at least contain the following <namespaceName> elements:

• dc=http://purl.org/dc/elements/1.1/

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 478 –

• upnp=urn:schemas-upnp-org:metadata-1-0/upnp/
• didl-lite=urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/
[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 3MRW2

29341-14-12

10.5.7.15
[G UIDELINE ] If a UPnP AV MediaServer that implements the “DLNA_EPG” level XQuery subset
cannot process a query because it does not conform to the subset defined in 10.5.7.5, it shall return
the UPnP error 728 (Unsupported Query Request Instruction(s)).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC A42Y2

29341-14-12

[C OMMENT] UPnP AV MediaServer implementing more than the required “DLNA_EPG” level
subset can execute a query it can understand. In this case no error is reported.

10.5.7.16
[G UIDELINE ] If a UPnP AV MediaServer that implements the “DLNA_EPG_EXPANDED” level
XQuery subset cannot process a query because it does not conform to the subset defined in
10.5.7.6, it shall return the UPnP error 726 (Unsupported Query Request Instruction(s)).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC I5TEA

29341-14-12

[C OMMENT] UPnP AV MediaServer implementing more than the required “DLNA_EPG” level
subset can execute a query it can understand. In this case no error is reported.

10.5.7.17
[G UIDELINE ] If the QueryRequest input argument of the CDS:FreeFormQuery action contains an
XQuery that specifies a property that is not listed in neither the <propertyList> nor the
<searchOnlyPropertyList> as defined in 10.5.7.11, a UPnP AV MediaServer shall return the UPnP
error 708 (Unsupported or invalid search criteria).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC DKXM4

29341-14-12

10.5.7.18
[G UIDELINE ] If the QueryRequest input argument of the CDS:FreeFormQuery action contains an
XQuery that specifies in the “order by”-clause a property that is not listed in the
<searchOnlyPropertyList> as defined in 10.5.7.11, a UPnP AV MediaServer shall return the UPnP
error 708 (Unsupported or invalid search criteria).

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WYN2C

29341-14-12

DLNA guidelines; Part 1-1: Architecture and protocols

 – 479 –

10.5.7.19
[G UIDELINE ] The CDSView input argument passed to the CDS:FreeFormQuery action shall be set
to “0” indicating DIDL-Lite view.

[ATTRIBUTES ]

M R DMS M-DMS n/a ISO/IEC XF9K8

29341-14-12

10.5.8 MM/EPG event moderation

10.5.8.1
[G UIDELINE ] A UPnP AV MediaServer that implements the EPG Server Device Option shall
implement the ContainerUpdateIDs state variable.

[ATTRIBUTES ]

M L DMS M-DMS n/a ISO/IEC KJNK4

29341-14-12

[C OMMENT] Control points can subscribe to CDS events. The ContainerUpdateIDs state variable
signals changes to containers. This means that a subscribed control point will be notified in case of
changes in the EPG container. The ContainerUpdateIDs state variable is a CSV list of ordered pairs,
where each pair contains the @id of a container and its ContainerUpdateIDValue. The @id
indicates the container in which a change occurred. If multiple changes occurred in a container
since the last event was sent, there will be only one occurrence of the container’s @id and the
ContainerUpdateIDValue will reflect the most recent change.

10.5.8.2
[G UIDELINE ] When a large number of EPG items are changed, a UPnP AV MediaServer should not
send ContainerUpdateIDs events before completion of the update.

[ATTRIBUTES ]

S L DMS M-DMS n/a ISO/IEC 5MGBH

29341-14-12

[C OMMENT] A large EPG update that sends interim update events can trigger UPnP AV control
points to prematurely issue a search to obtain updated EPG information. To further reduce the
chance of issuing searches while an EPG update is in progress, UPnP AV control points can wait a
reasonable amount of time (to ensure a smooth user experience), before requesting new EPG data.

10.5.8.3
[G UIDELINE ] A UPnP AV MediaServer that implements the EPG Server Device Option may
implement the Track Changes Option as defined in ISO/IEC 29341-14-12.

[ATTRIBUTES ]

O L DMS M-DMS n/a ISO/IEC ENS95

29341-14-12

[C OMMENT] A UPnP AV MediaServer can choose to event changes to individual objects. A UPnP
AV control point can use such an event to take action when, for example, the broadcast time of an
EPGItem was changed. When a large number of EPGItems are modified, added or deleted, the
UPnP AV MediaServer can set the stUpdate attribute of individual objects to 1. A control point can
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 480 –

make use of this information to ignore individual changes and only take action when it sees the
stDone event.

11 Media Transport
11.1 General
This subclause of the DLNA Home Networked Device interoperability guidelines covers the
requirements for the media transport layer. In the DLNA interoperability guidelines v1.0 there was a
single transport protocol (HTTP) available for the transfer of media across a home network and all
media transfers were assumed to be for the purpose of immediate playback. In addition, all media
transfers under DLNA interoperability guidelines v1.0 occurred with a default, best effort, quality of
service specification. With the increase in the system usages in v1.5, the introduction of
priority-based QoS, and the addition of another transport protocol (RTP), there exists a need to
define different modes of media transfer and other protocol-agnostic requirements for the transport
layer. Table 40 summarizes the types of media transfer now available. The DLNA transfer mode
terms are consistent with those found in 6.3 of 3GPP TS 23.107.

Table 40 – DLNA Media Transfer modes

Transfer mode Transfer rate Example usages Default DLNAQOS level

Streaming Transfer For Audio and AV streams Immediate rendering by DLNAQOS_2

the Content Source and the Content Receiver of
Content Receiver content binaries with an
maintain under Ideal inherent time base (e.g.
Network Conditions an Audio or AV media).
average transfer rate Real time generated AV
equal to or higher than the media transfer followed by
rate sufficient for store/record at the
real-time rendering. Content Receiver.
Interactive Transfer The transfer rate is limited Immediate rendering by DLNAQOS_1
to the lesser of the the Content Receiver of
maximum transfer rate of content binaries with no
the Content Source and inherent time base (e.g.
the maximum transfer rate images).
of the Content Receiver
without degrading any
Streaming Transfer
originating from the
Content Source.
Background Transfer The Content Source Transfer and store of DLNAQOS_0 (Lowest
transfers the content file-based media. Priority)
binary at a rate
determined by the
Content Source, but no
faster than the rate at
which the Content
Receiver can accept the
content binary from the
network.

Table 41 summarizes the combinations of permitted DLNAQOS priorities and transfer modes for
each Media Class. The relationship between the different columns is described here.

• Media Class: Indicates a Media Class.

• Transfer Mode: Indicates a transfer mode.
• Combination Permitted: Indicates if the indicated Media Class and Transfer Mode values can be
combined. The "Yes" and "No" values indicate if the combination is permitted. A "Default" value
means that Content Sources are required to support the combination. The permissible
combinations are described in the following guidelines:
DLNA guidelines; Part 1-1: Architecture and protocols
 – 481 –

– 10.1.3.35 MM tm-s (Streaming Mode Transfer flag)

– 10.1.3.36 MM tm-i (Interactive Mode Transfer flag)
– 10.1.3.37 MM tm-b (Background Mode Transfer flag)
• Permitted DLNAQOS_UP: Indicates the DLNAQOS_UP values that the Content Source is
permitted to use when responding to transport requests. The guidelines do not require Content
Sources to always respond with the highest DLNAQOS_UP value that is listed in this column.
The following guidelines describe the permitted DLNAQOS_UP values for a given Media Class.
– 11.4.2.3.1 in 11.4.2.3 MT Transfer Mode support
– 11.4.2.10 MT DLNAQOS Background Transfer
– 11.4.2.11 MT DLNAQOS Interactive Transfer
– 11.4.2.12 MT DLNAQOS Streaming
Table 41 – Permitted combinations of DLNAQOS_UP
and Transfer Mode per Media Class

Media Class Transfer mode Combination permitted Permitted DLNAQOS_UP

Image or Media Collection Streaming No n/a

File.
Interactive Default DLNAQOS_1,
DLNAQOS_0
Background Yes DLNAQOS_0
Audio Streaming Default DLNAQOS_2,
DLNAQOS_1,
DLNAQOS_0
Interactive No n/a
Background Yes DLNAQOS_0
AV Streaming Default DLNAQOS_2,
DLNAQOS_1,
DLNAQOS_0
Interactive No n/a
Background Yes DLNAQOS_0

A Streaming Transfer supports two media usages. The first case is where a content binary is being
immediately rendered for a user and contains inherent timing that shall be met. The second case is
where a content binary is being generated in real time at a fixed rate (such as a live broadcast
stream), regardless of whether the item is being immediately rendered or stored for later use. In
either of these cases, a delay in packet delivery can adversely impact the user's perception of the
system. If the content binary contains inherent timing information (such as Audio or AV content) and
is being immediately rendered, a delay in packet delivery can cause data to not be available on the
Content Receiver at the time it needs to be played. This can lead to a dropout in the playback of the
media. If a real time stream is being generated on the Content Source and the throughput across the
network (which can be affected by the Content Receiver's use of flow control) is not equal to the
data rate of the generated content, a buffer overrun can occur on the Content Source. This can lead
to a loss of data in the content binary.
NOTE If the content is being generated at an average fixed rate, such as the capture of audio or AV content from an
external source, and the network has a period where the throughput is less than the rate of generation of the content, the
Content Source will typically buffer the data for sending at a later time. However, if this period lasts long enough, the
Content Source may exhaust its ability to buffer the captured content. At this point, some data samples will be lost. If the
Content Receiver is rendering the stream immediately, the user will perceive the loss of the data as skipped content
samples. If the Content Receiver is storing the stream for later use, such as in a download operation, the stored content
will have missing samples. Content Sources and Receivers may have any amount of buffering to mitigate this situation and
the network cannot be controlled to guarantee a bandwidth for the transfer. Any content that is transitory (i.e. not stored

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 482 –

on disk) and may cause a buffer overrun on the Content Source due to network delays should always be sent as a
Streaming Transfer.

An Interactive Transfer is used for the case where a content binary is being immediately rendered
for a user but it does not have any inherent timing information, such as image media. In this case,
a delay in packet delivery of a few milliseconds will not cause an adverse impact for rendering, but
sufficiently long delays will adversely impact the user's perception of the system.

A Background Transfer is used for the case where the content binary is not being transferred for
immediate rendering or where the user might be satisfied with a transfer executed at the lowest
priority. It is typically reserved for the download or upload of content that is not being generated in
real time by the Content Source. For example, this transfer mode would be used for downloading a
content binary that has been stored in a file on the Content Source. The Content Source is free to
internally prioritize the Background Transfer lower than other transfer modes.

The DLNA QoS levels are shown in the above tables as an indication that each of the transfer
modes are handled at a different QoS level. Further discussion of QoS can be found in section 8.

Each of the Transfer Modes is implemented differently for the transport chosen (HTTP versus RTP).
In addition, a transport may choose to not allow a particular Transfer Mode. For instance, RTP will
not support Background Transfers. The Transfer Modes available to a particular content resource
are specified in 9.2.37.

For most transfers, the Content Receiver issues a request for the content binary with a specific
Transfer Mode and Media Transport based on the type of usage involved. An Upload content
transfer is the exception to this rule. It is initiated by the Content Source.

However, the choice of Transfer Mode is made in the same way, based on the type of usage and the
content binary to be transferred.

The definitions of the Transfer Modes introduced in this subclause apply only to a state of the
network referred to as Ideal Network Conditions. Under Ideal Network Conditions no congestion
from other communicating parties or from bandwidth restrictions on the network exists. Furthermore,
under Ideal Network Conditions, Content Sources and Content Receivers have moved away from
the startup conditions, and have reached steady-state transfers. From the perspective of
measurements, Ideal Network Conditions can be approximated by having a single Content Source
send data to a single Content Reveiver over a high-speed link with bandwidth equal to or exceeding
the bandwidth required by the transmission.

This system provides a robust set of Transfer Modes that support streaming for immediate
rendering or download of content for later consumption. It also provides a structure for fine grained
QoS control. A DLNA interoperability guidelines v1.0 transfer most closely maps to a Streaming
Transfer Mode in terms of functionality. However, the Streaming Transfer Mode allows for higher
QoS priority than the default best effort of the DLNA interoperability guidelines v1.0.

11.2 Uniform Client Data Availability Model

The Uniform Client Data Availability Model (UCDAM) provides a mechanism for describing the data
available for a content stream. It defines a content stream in mathematical terms, with special
attention focused on the data range that can be transmitted by the Content Source. The model
applies regardless of whether the content is stored, converted (e.g. transcoded, transrated,
transscaled, etc.), or "live". Although the DLNA guidelines do not specify buffering implementations
or requirements for either the Content Source or the Content Receiver, the uniform data availability
model takes into account the diversity of buffering models that are available to implementers. These
guidelines can then focus on normative high level behaviors that are common, regardless of details
at the transport layer. Figure 21 graphically shows the UCDAM model.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 483 –

Figure 21 – UCDAM summary

The list below specifies the various aspects of the UCDAM.

• The first aspect of the UCDAM is the definition of a content stream. A content stream is media
with a beginning (d X ) and end (d Y ), where both values are defined by the Content Source. In
some cases, a content stream never ends (d Y increases with time). This data range is an
assumed condition but is not referenced in the guidelines.
• The second aspect of the UCDAM is the data range available from the Content Source for
transport to the Content Receiver. This range is defined as [s 0 , s N ]. For content stored within a
file on the Content Source, s 0 could be equal to d X and s N could be equal to d Y . For content
captured by the Content Source from a live AV or audio feed, the range represents the amount
of data buffered by the Content Source. This data range is normative and is referenced in the
guidelines.
• The third aspect of the UCDAM is the data range available to the Content Receiver. The range
of data available to the Content Receiver, defined inclusively as [d 0 , d N ], is determined by two
aspects: what the Content Source can transmit (i.e. some data range of [s 0 , s N ]) and, in addition,
what might be buffered on the Content Receiver in a local manner. This data range is an
assumed condition, but is not referenced in the guidelines.
NOTE Neither the UCDAM model, nor the DLNA Media Transport guidelines specify how clients have access to data
in a local manner as implementers may use a variety of memory-based and disk-based mechanisms to define the
range of data that a Content Receiver can access without the Content Source having to transfer data.

• The fourth aspect of the UCDAM is the Content Source's data range that supports random
access requests. The [r 0 , r N ] data range represents the data range where random access
operations are supported. If this capability is supported, then the [r 0 , r N ] interval is always equal
to the [s 0 , s N ] data range. If the Content Source does not allow random access within the content
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 484 –

stream, then a Content Receiver can only request content starting from s 0 . This data range is
normative and is referenced in the guidelines.
• The fifth aspect of the UCDAM is that the data range available to the Content Receiver can
change with time. This is really a clarification of the third aspect. As time passes, the data range
that the Content Source can provide to the Content Receiver can also change. There are three
aspects that determine how the data range available to the Content Receiver will change.
– Does the Content Source guarantee that s 0 is fixed or can s 0 increase with time? If s 0 is fixed,
then the Content Source is characterized as operating under a fixed s 0 model. Otherwise, the
Content Source is characterized as operating under an increasing s 0 model. An example of
a possible fixed s 0 model is content data read from a file on the Content Source. An
increasing s 0 model.can be used to represent content being captured from an incoming AV
feed.
– Does the Content Source guarantee that s N is fixed or can s N increase with time? If s N is
fixed, then the Content Source is characterized as operating under a fixed s N model.
Otherwise, the Content Source is characterized as operating under an increasing s N model.
The same examples as above can be used in this case. An example of a fixed s N model is
content data read from a file on the Content Source. An increasing s N model can be used to
represent content being captured from an incoming AV feed. 3
– Does the Content Receiver save data 4 such that (d 0 < s 0 )? (i.e. the Content Receiver has
accessible data that the Content Source can no longer provide.)
NOTE This model is very flexible in that it can easily represent all of the common types of media streams. For example,
a media stream originating from a file can be represented as d 0 = d x and d N = d Y – the entire extent of the content is
available to the user. An unbuffered live stream can be represented as d 0 = d N , so that only the current moment in time is
available. In addition to above simple examples, many more complex buffering systems can be represented by UCDAM.
Please see Annex D for more details.

Keep in mind that most of the UCDAM model is conceptual and outside the scope of the DLNA
guidelines. However, the [s 0 , s N ] and [r 0 , r N ] data ranges describe what data can be requested in
Media Transfer operations over the network, and as such are within the scope of these guidelines.
Therefore, those data ranges will be utilized in the following guidelines where appropriate to define
the range of content that can be transferred using DLNA defined Media Operations.

11.3 Media Operations

A Media Operation is the network level operation that supports a user interaction with a content
binary. At a high level, they define the network operations that shall occur in order to support a
Streaming Transfer mode data transfer. The core set of Media Operations that an endpoint can
perform are defined in Table 42.

Table 42 – DLNA Streaming Media Operation definitions

Term Definition

Play Initiate a Streaming Transfer for playback of media. The transfer occurs at a rate that
supports normal playback of the content binary. The transfer begins at s 0 and proceeds
at a rate sufficient to support normal (1x) playback of the content binary. The operation
completes after transfer of a fixed s N value. Under the increasing s N model the transfer
does not complete.
Stop Terminate a Streaming Transfer.
Pause Temporarily suspend a Streaming Transfer.
Pause-Release A Pause media operation has suspended a Streaming Transfer, complete the Pause
media operation and re-establish the flow of data over the network to support the
Streaming Transfer.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 485 –

Term Definition

Seek Move the transfer point to a particular point in a stream in the range [r 0 , r N ], that
represents the seek-able range. (The seek-able data range is the same random access
data range, although the former term is used for Streaming transfers and the latter term
applies to Streaming, Interactive, and Background transfers.) If a seek-able range
exists, it shall equal [s 0 , s N ]. The next set of transferred data will be from the indicated
point in the content binary. DLNA defines two types of seek operations:
• byte-based seek: a seek operation where the transfer point is specified in bytes;
• time-based seek: a seek operation where the transfer point is specified in units of
time.

Fast Forward Scan Perform data transfers that will support a positive play-speed greater than 1x.
Slow Forward Scan Perform data transfers that will support a positive play-speed greater than 0 but less
than 1x.
Fast Backward Scan Perform data transfers that will support a negative play-speed less than −1x.
Slow Backward Scan Perform data transfers that will support a negative play-speed less than 0 but greater
than −1x.
Streaming Download Initate a Streaming Transfer for the purpose of storing media for later playback. The
transfer begins at s 0 and proceeds at a rate defined by the internal timing information of
the content. The operation completes after transfer of a fixed s N value. Under the
increasing s N model the transfer does not complete until the Content Receiver
terminates the transaction.

The listed media operations are defined in terms of how the media transfer occurs over the network
for a given transport protocol in the guidelines below.

11.4 Media Transport protocols

11.4.1 General
The following subclauses contain guidelines for the use of media transports in DLNA devices. The
guidelines are organized as a table that covers requirements common among all media transports
and then subclauses/tables that cover requirements for specific media transport protocols such as
HTTP and others.

11.4.2 Media Transport common guidelines

11.4.2.1 MT mandatory transport support
[G UIDELINE ] Content Sources and Content Receivers shall support HTTP as the mandatory
transport as specified in the following subclauses.

• 11.4.3.2 through 11.4.3.37: HTTP transport: common requirements

• 11.4.3.38 through 11.4.3.58: HTTP transport: Streaming Transfer guidelines
• 11.4.3.59 through 11.4.3.61: HTTP transport: Interactive Transfer guidelines
• 11.4.3.62 through 11.4.3.64: HTTP transport: Background Transfer guidelines
• 11.4.3.65 through 11.4.3.69: HTTP transport: POST guidelines
[ATTRIBUTES ]

M A DMP DMR DMS +PU+ M-DMS M-DMP n/a n/a H9DD7

+UP+ +DN+
+DNSYNC+
+UPSYNC+

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 486 –

11.4.2.2 MT optional transport support

[G UIDELINE ] Content Sources and Content Receivers may support RTP as an optional transport as
specified in subclause 11.4.4.

[ATTRIBUTES ]

O A DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a FPWW5

11.4.2.3 MT Transfer Mode support

11.4.2.3.1
[G UIDELINE ] A content binary shall be transferred using one of the Transfer Modes indicated in
Table 43 for its Media Class.

The list of available Transfer Modes for a Media Class is as specified below. This may be further
limited by the transport protocol chosen.

Table 43 – MT Media Class Transfer Modes

Media Class Transfer Mode

Media Collection Binary: Background, Interactive

Image: Background, Interactive
Audio-only: Background, Streaming
AV: Background, Streaming

[ATTRIBUTES ]

M A DMP DMR +UP+ M-DMP n/a n/a PWW5H

+DN+ +DNSYNC+
+UPSYNC+

[C OMMENT] This can be either a Content Receiver requesting a particular Transfer Mode for
content that it will receive, or it can be a Content Source specifying the Transfer Mode when
performing an upload operation.

11.4.2.3.2
[G UIDELINE ] A Content Source may constrain the transfer of audio-only or AV content binaries to
Streaming Transfer only if it is not able to support the Background Transfer mode for that content
binary and transport protocol.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a n/a RE5VM

[C OMMENT] For example, a Content Source might do this because it is capturing content from a live
stream and could potentially overflow its buffer if the network transfer is handled below the nominal
rate of the content.

11.4.2.3.3
[G UIDELINE ] A Content Source shall indicate the Media Transfer Modes that are available for a
content binary by setting the tm-s, tm-i, and tm-b flags in the 4th field of the protocolInfo.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 487 –

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 2V7PF

[C OMMENT] See guidelines 10.1.3.24.2, 10.1.3.35.1, 10.1.3.36.1, and 10.1.3.37 for more
information.

11.4.2.3.4
[G UIDELINE ] An endpoint responding to the initiation of a media transfer shall generate an
appropriate transport protocol error response if the requested Transfer Mode is not currently
available for the given content binary.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a E5VMH

[C OMMENT] This can be either the Content Source responding to an incorrectly requested Transfer
Mode by a Content Receiver or in the case of an upload operation it can be the Content Receiver
responding to an incorrectly requested Transfer Mode by a Content Source. See guideline
11.4.3.32.4 for HTTP error codes used in various scenarios.

Guideline 11.4.2.3.1 defines the possible transfer mode given the media type and guideline
11.4.2.3.2 allows Content Sources to constrain the available transfer mode for a given item (for
example if RTP is used as the transport protocol). This guideline requires an endpoint to generate
an error if the request for the content is not of the allowed modes for the media item.

11.4.2.4 MT Transfer Mode support for Device Classes

11.4.2.4.1
[G UIDELINE ] A DMS, M-DMS, or +PU+ that supports the AV or Audio Media Classes shall support
acting as a Content Source for Streaming Transfers as defined in this subclause.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a DD7KP

11.4.2.4.2
[G UIDELINE ] A DMS, M-DMS, or +PU+ that supports the Image Media Class shall support acting as
a Content Source for Interactive Mode Transfers as defined in this subclause.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a V7PF7

11.4.2.4.3
[G UIDELINE ] A DMS or M-DMS that supports the download system usage shall support acting as a
Content Source for Background Mode Transfers as defined in this subclause.

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a 7YPY8

[C OMMENT] The requirement is not that background will be used for the transfer. Rather, the
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 488 –

guideline states that the Background Transfer mode needs to be supported for one or more Content
Binaries. See guideline 10.1.3.37 for more information about reporting Background transfer mode
support for a Content Binary.

11.4.2.4.4
[G UIDELINE ] A DMS or M-DMS that supports the upload AnyContainer or OCM: upload content
operations shall support acting as a Content Receiver for Background Mode Transfers as part of the
Content transfer process as defined in this subclause.

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a W7YPY

11.4.2.4.5
[G UIDELINE ] A DMS or M-DMS that supports the upload AnyContainer or OCM: upload content
operations should support acting as a Content Receiver for Streaming and Interactive Mode
Transfers as part of the Content transfer process as defined in this subclause.

[ATTRIBUTES ]

S A DMS M-DMS n/a n/a HC83V

[C OMMENT] Allows the server to support the upload of content that cannot be sent via Background
Transfer Mode such as live content captured from a tuner.

11.4.2.4.6
[G UIDELINE ] A DMP, M-DMP, or DMR that supports the Audio or AV Media Classes shall support
acting as a Content Receiver for Streaming Mode Transfers as defined in this subclause.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a BHC83

11.4.2.4.7
[G UIDELINE ] A DMP, M-DMP, or DMR that supports the Image Media Class shall support acting as
a Content Receiver for Interactive Mode Transfers as defined in this subclause.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a 78IWW

11.4.2.4.8
[G UIDELINE ] An +DN+, or +DNSYNC+ shall support acting as a Content Receiver for Background
Mode Transfers as defined in this subclause.

[ATTRIBUTES ]

M A +DN+ +DNSYNC+ n/a n/a n/a M93FM

[C OMMENT] The requestor isn't obliged to use background transfer if the server defines that only
streaming of this content is supported.

11.4.2.4.9
[G UIDELINE ] An +DN+, or +DNSYNC+ may support acting as a Content Receiver for Streaming
Mode Transfers as defined in this subclause.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 489 –

[ATTRIBUTES ]

O A +DN+ +DNSYNC+ n/a n/a n/a TQPSF

[C OMMENT] Supports the download of content that cannot be sent via Background Transfer Mode.

11.4.2.4.10
[G UIDELINE ] An +UP+, or +UPSYNC+ shall support acting as a Content Source for Background
Mode Transfers as defined in this subclause.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a n/a 8IWW3

11.4.2.5 MT low throughput tolerance

[G UIDELINE ] Content Receivers shall tolerate scenarios where the Content Source is not able to
sustain a particular transmission throughput.

Tolerate means that the Content Receiver is able to do one of the following actions gracefully (i.e.
without crashing or requiring the user to power-cycle or reset the device)

• continue receiving content data despite the low throughput, or

• terminate the transport layer connection.
[ATTRIBUTES ]

M A DMP DMR DMS +DN+ M-DMS M-DMP n/a n/a 93FM8

+DNSYNC+

[C OMMENT] This guideline is mandatory because a home network does not always operate under
Ideal Network Conditions (i.e. the transmission rate remains dependent on the network throughput
between the server and client). Products that crash, require a reset, or a similar type of power-cycle
operation due to low transmission throughput rate violate this guideline.

DLNA devices are permitted to have user interactions in meeting the tolerance portion of this
requirement. For example, a DMP is permitted to report to ask the user if they want to stop rendering
or download because the throughput is extremely slow.

11.4.2.6 MT requirements for Background Transfer

[G UIDELINE ] If Background Transfer is available for a given content binary, a downloading
endpoint (an +DN+, or +DNSYNC+) shall use the Background Transfer Mode when performing a
download operation.

[ATTRIBUTES ]

M A +DN+ +DNSYNC+ n/a n/a n/a XAZ2Z

[C OMMENT] Examples of where this wouldn't be the case are the downloading of live media
streams. On download, the server will mark them as only transportable with Streaming Transfer
mode.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 490 –

11.4.2.7 MT Streaming Transfer rate assumptions

11.4.2.7.1
[G UIDELINE ] A Content Receiver operating in Streaming Transfer mode shall be able to receive
content from the network at rates required to sustain Streaming Transfer for the profiles that the
Content Receiver supports.

[ATTRIBUTES ]

M A DMP DMR +DN+ M-DMP n/a n/a 5YE9G

+DNSYNC+

[C OMMENT] A Content Receiver needs to be able to receive and consume content at a rate that will
allow it to render the content in real-time. This guideline does not apply where the Content Source
and Content Receiver have negotiated transfer characteristics within the transport protocol, such as
negotiated buffer agreements within RTP. This guideline applies only in the absence of an existing
agreement between the Content Receiver and the Content Source.

11.4.2.7.2
[G UIDELINE ] A Content Source operating in Streaming Transfer mode shall be able to send content
to the network at rates required to sustain Streaming Transfer for the content binary.

[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a n/a 3KP2E

+UPSYNC+

11.4.2.8 MT Interactive Transfer rate assumptions

11.4.2.8.1
[G UIDELINE ] Content Sources and Content Receivers using an Interactive Transfer should tolerate
all transmission throughputs.

In this case, tolerate means that Content Sources and Content Receivers do not terminate the
transport connection simply because the throughput is too low, unless user intervention has caused
it to happen.

[ATTRIBUTES ]

S A DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a Z5YE9

+DN+ +DNSYNC+

[C OMMENT] This guideline covers the case of sending an image over the network for rendering;
and it indicates that the transfer can occur at any rate depending on the network and server load.
This guideline recommends that devices support a wide range of throughputs but the actual
maximum and minimum depend on external factors.

11.4.2.8.2
[G UIDELINE ] Content Sources and Content Receivers using an Interactive Transfer may affect the
actual rate of data delivery using transport layer flow control, regardless of the content's internal
timing information.

[ATTRIBUTES ]

O C DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a 83KP2

+DN+ +DNSYNC+

DLNA guidelines; Part 1-1: Architecture and protocols

 – 491 –

11.4.2.9 MT Background Transfer rate assumptions

11.4.2.9.1
[G UIDELINE ] Content Sources and Content Receivers using a Background Transfer should tolerate
all transmission throughputs.

In this case, tolerate means that Content Sources and Content Receivers do not terminate the
transport connection simply because the throughput is too low, unless user intervention has caused
it to happen.

[ATTRIBUTES ]

S A DMS +PU+ +DN+ M-DMS n/a n/a E9GK5

+UP+ +UPSYNC+
+DNSYNC+

[C OMMENT] This guideline covers the case of downloading content sourced from a file on the
Content Source; and it indicates that the transfer can occur at any rate (e.g. higher or lower than the
internal timing information of the content data for audio and A/V content). This guideline
recommends that devices support a wide range of throughputs but the actual maximum and
minimum depend on external factors.

11.4.2.9.2
[G UIDELINE ] Content Sources and Content Receivers using a Background Transfer may affect the
actual rate of data delivery using transport layer flow control, regardless of the content's internal
timing information.

[ATTRIBUTES ]

O C DMS +PU+ +DN+ M-DMS n/a n/a 3FM8E

+UP+ +UPSYNC+
+DNSYNC+

11.4.2.10 MT DLNAQOS Background Transfer

11.4.2.10.1
[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, Background Transfer requests shall be
tagged with DLNAQOS_0 in accordance with Table 7.

[ATTRIBUTES ]

M R DMS +DN+ M-DMS n/a n/a Z2ZFW

+DNSYNC+

11.4.2.10.2
[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, Background Transfers of content
binaries shall be tagged with DLNAQOS_0 in accordance with Table 7.

[ATTRIBUTES ]

M R DMS +UP+ M-DMS n/a n/a 2ZFW6

+UPSYNC+

11.4.2.10.3
[G UIDELINE ] If DLNAQOS as defined in 8 is implemented by a Content Source and it receives a
Background Transfer request for content that it cannot transfer at DLNAQOS_0, then it shall
respond with an error within the transport used, at DLNAQOS_0, in accordance with Table 7.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 492 –

For HTTP as a transport, see guideline 11.4.3.63 for the specific error.

[ATTRIBUTES ]

M R DMS M-DMS n/a n/a P2EZ3

[C OMMENT] For example, a Content Receiver that tries to use a Background Transfer to acquire a
live stream might receive an error response from the Content Source because it cannot transmit a
live stream at DLNAQOS_0.

11.4.2.11 MT DLNAQOS Interactive Transfer

11.4.2.11.1
[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, Interactive Transfer requests shall be
tagged with DLNAQOS_1, or a lower DLNAQOS_UP value (where "or a lower" is defined by
8.3.2.2.2 and 8.3.2.2.3), in accordance with Table 7, independent of the transport used. Note that
this guideline applies only when the transfer request is not marked as a Background Transfer.

[ATTRIBUTES ]

M R DMP DMR M-DMP n/a n/a YE9GK

[C OMMENT] This transfer is part of an interactive experience and therefore the default is a higher
QoS level than a Background Transfer.

11.4.2.11.2
[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, Interactive Transfers of content binaries
shall be tagged with DLNAQOS_1, or a lower DLNAQOS_UP value (where "or a lower" is defined by
8.3.2.2.2 and 8.3.2.2.3), in accordance with Table 7, independent of the transport used.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a n/a FM8EP

11.4.2.12 MT DLNAQOS Streaming Transfer

11.4.2.12.1
[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, Streaming Transfer requests shall use
DLNAQOS_2, or a lower DLNAQOS_UP value (where "or a lower" is defined by 8.3.2.2.2 and
8.3.2.2.3), in accordance with Table 7.

[ATTRIBUTES ]

M R DMP DMR +DN+ M-DMP n/a n/a C83VQ

+DNSYNC+

[C OMMENT] For example, a Client Endpoint issues an HTTP GET request for AV content with
DLNAQOS_2. The Content Source will then respond to the request with media that is tagged with
DLNAQOS_2. The Content Source response (transfer of the actual media) will be tagged with
DLNAQOS_2. Subsequent TCP ACK messages will use the existing TCP connection and therefore
be tagged with DLNAQOS_2.

For the RTP transport, this priority is applicable to both audio and video streams encompassing TS,
PS, and ES formats.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 493 –

See 8.3.2.2 for considerations around the TCP connection establishment phase.

11.4.2.12.2
[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, Streaming Transfer of content binaries
shall use DLNAQOS_2, or a lower DLNAQOS_UP value (where "or a lower" is defined by 8.3.2.2.2
and 8.3.2.2.3), in accordance with Table 7.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a n/a WW3DT

11.4.2.13 MT normative syntax for npt-time

[G UIDELINE ] The syntax of the npt-time token shall be as follows:

• npt time = npt sec | npt hhmmss

• npt sec = 1*DIGIT [ "." 1*3DIGIT ]
• npt hhmmss = npt hh ":" npt mm ":" npt ss [ "." 1*3DIGIT ]
• npt hh = 1*DIGIT ; any positive number
• npt mm = 1*2DIGIT ; 0-59
• npt ss = 1*2DIGIT ; 0-59
[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 83VQW
2326

[C OMMENT] This guideline provides a consistent syntax for NPT time positions for both DLNA's
extensions to HTTP and RTP Media Transport.

11.4.2.14 MT normative random access data availability models

11.4.2.14.1
[G UIDELINE ] If a Content Source supports random access requests on a content binary, then the
Content Source shall use only one of the following random access data availability models.

• “Full Random Access Data Availability" model, as defined in 11.4.2.15.

• "Limited Random Access Data Availability" model, as defined in 11.4.2.16.
These random access data availability models shall be used in a mutually exclusive manner.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a YPY8R

[C OMMENT] Previous versions of the DLNA guidelines do not formally define either random access
data model, but the "Full Random Access Data Availability" model has been defined to match the
assumptions used in previous versions of the DLNA guidelines.

Other guidelines explain how to detect which random access data availability model is being used.
Specifically, the op-param is tied solely to the "Full Random Access Data Availability" model and the
lop-npt/lop-bytes flags are tied solely to the "Limited Random Access Data Availability". For more
information, see the following guidelines:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 494 –

• 10.1.3.19 MM op-param (Operations Parameter – Common guidelines)

• 10.1.3.29 MM lop-npt, lop-bytes and lop-cleartextbytes (limited operations flags): Common
The "Full Random Access Data Availability" model is the only model that can be used for Content
Sources when serving image content. This limitation is inherent to the nature of such content, which
neither have changing [s 0 , s N ] data boundaries nor have any sender-pacing requirements.

11.4.2.14.2
[G UIDELINE ] The UCDAM data range of [s 0 , s N ] shall represent the entire data range that the
Content Source can serve to other network endpoints.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 7PF7U

[C OMMENT] Although not testable by itself, these guidelines repeat normative portions Figure 21.
Other DLNA guidelines can normatively refer to the [s 0 , s N ] data range.

Considering how the s 0 and s N boundaries change, other DLNA guidelines explain how to represent
these abstract data boundaries in terms of zero-based byte indices or npt playback positions.

Generally, the s 0 and s N data boundaries increase with time, although in some scenarios the values
can reset, as is sometimes necessary when the integer value rolls over. Other guidelines specify the
details on how these data boundaries can change.

11.4.2.14.3
[G UIDELINE ] The [s 0 , s N ] may change with time. Specifically, the following can happen.

• The s 0 data boundary may change with time.

• The s N data boundary may change with time.
How these data boundaries change with time is undefined by the guidelines because these data
boundaries are abstract. In some cases, other DLNA guidelines will impose restrictions that require
a data boundary to remain fixed.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a n/a PY8RW

11.4.2.14.4
[G UIDELINE ] If a Content Source supports random access requests on content data, then the
following rules shall apply.

• The UCDAM data range of [r 0 , r N ] shall represent the data range where random access
operations are permitted.
• The [r 0 , r N ] data range shall be equal to the [s 0 , s N ] data range.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a PF7UZ

[C OMMENT] If random access requests are supported, then they need to be supported for the entire
range that the Content Source can access.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 495 –

This guideline is consistent with the following introductory material:

• Figure 21 – UCDAM summary

• The prerequisites used for the Seek Media Operation definition, in Table 40.
11.4.2.15 MT Full Random Access Data Availability model
11.4.2.15.1
[G UIDELINE ] If a Content Source uses the Full Random Access Data Availability model, then
following rules shall apply.

• The entire content binary shall be defined as the [s 0 , s N ] data range.

• The s 0 data boundary shall map to a fixed and non-changing beginning. This requirement is a
restriction of 11.4.2.14.3.
• The data range of [s 0 , s N ] shall occupy an npt range of [0, npt-last-time] and a byte range of [0,
last-byte-pos], where npt-last-time is in units of npt and last-byte-pos is in bytes.
• The content binary's zero position (i.e. npt-time=0 and byte-pos=0) shall map to the UCDAM's
data position of s 0 .
• The last-byte-pos and npt-last-time shall map to the UCDAM's s N data position and the s N data
boundary shall map to the end of the available content data. (This requirement works in
conjunction with 11.4.2.14.3.)
• The [r 0 , r N ] and [s 0 , s N ] data ranges shall have the same equality.
• Responses to random access requests on the [r 0 , r N ] data range shall be timely under Ideal
Network Conditions.
Timely means that the Content Source (under Ideal Network Conditions) is able to begin responding
with the requested content data within 27 s of receiving the request.

Note that the npt-last-time, last-byte-pos, and byte-pos tokens for this guideline are relative to the
complete content binary that is currently available, rather than being relative to the content data
returned in response.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a D7KPW

[C OMMENT] This guideline defines the behavioral model for the Full Random Access Data
Availability model.

For guidelines on the data range for HTTP under Full Random Access Data Availability, see the
following guidelines:

• 11.4.3.18 MT HTTP common random access data availability requirements

• 11.4.3.19 MT HTTP data range of Full Random Access Data Availability
The “relative to the complete content binary” phrase means that the tokens apply in the context of
the whole content binary. It is incorrect to interpret these tokens as they are used in actual response
data. For example, if last-byte-pos=100 then it is correct to conclude that the complete content
binary currently has 101 B. It is not necessarily true that a response with the Content-Range
header's last-byte-pos=50 means that the complete content binary has 51 B because the
last-byte-pos token in this context simply means that the last byte in the entity body is the 51st byte
of the complete content binary.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 496 –

11.4.2.15.2
[G UIDELINE ] The values for npt-last-time and last-byte-pos (as specifically used in 11.4.2.15.1)
may increase with time.

[ATTRIBUTES ]

O A DMS, +PU+ M-DMS n/a n/a 5VMHZ

[C OMMENT] The concept of entire content range is relative to the current moment in time, in the
context for the op-param. This means the s N position can increase with time, causing the duration
of the content binary to also increase (although the beginning has to remain fixed).

This model can apply when streaming content that is being recorded to local storage. The absolute
beginning (s 0 ) never changes and as time passes, the end (s N ) increases.

11.4.2.16 MT Limited Random Access Data Availability model

11.4.2.16.1
[G UIDELINE ] If a Content Source uses the Limited Random Access Data Availability model, then
only one of the two modes of operation shall be used.

• Mode=0
• Mode=1
Furthermore, the following rules shall be true for both Mode=0 and Mode=1.

• The [r 0 , r N ] and [s 0 , s N ] data ranges shall have the same equality.

• The [r 0 , r N ] data range shall be the limited data range.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 7KPWX

[C OMMENT] This guideline explains the behavior of the s 0 data boundary when it is used with the
Limited Random Access Data Availability model.

For guidelines on the data range for HTTP under Limited Random Access Data Availability, see the
following guidelines:

• 11.4.3.18 MT HTTP common random access data availability requirements

• 11.4.3.20 MT HTTP: data range of Limited Random Access Data Availability
The limited data range is the data range that supports seek media operations, as clarified in the
other rows of this guideline.

11.4.2.16.2
[G UIDELINE ] If a Content Source uses the Limited Random Access Data Availability model under
Mode=0, then the following shall be true.

• The s 0 data boundary shall map to a beginning that shall change with time.
• The data range of [s 0 , s N ] shall map to the npt range of [npt-start-time, npt-last-time] and the
byte range of [first-byte-pos, last-byte-pos], where npt-start-time and npt-last-time are in units of
npt and first-byte-pos and last-byte-pos are in units of bytes.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 497 –

• There exists a "live position" that shall be equal to the s N data boundary.
• If the s N data boundary is changing with time, then the "live position" shall shift forward in
real-time.
• Responses to random access requests on the [r 0 , r N ] data range shall be timely under Ideal
Network Conditions.
• If the Content Source receives a transport layer request that is not a random access request (e.g.
HTTP request that omits Range and TimeSeekRange.dlna.org) then the Content Source shall
respond with content data from the "live position". (See 11.4.3.20.9 for an example of how this
guideline applies specifically to HTTP.)
Timely means that the Content Source (under Ideal Network Conditions) is able to begin responding
with the requested content data within 27 s of receiving the request.

Real-time is the data rate necessary for immediate rendering.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a W5HZV

[C OMMENT] This guideline defines Mode=0 behaviors for the Limited Random Access Data
Availability model. This mode of operation is generally useful for live content streams that use a
fixed data buffer that map to the [s 0 , s N ] and [r 0 , r N ] data ranges. Live television broadcast streams
are ideal candidates for this data availability model.

The reason why [r 0 , r N ] is a limited data range in this context is that the values for npt-start-time,
npt-last-time, first-byte-pos, and last-byte-pos change over time. For example, the value of
first-byte-pos changes

– at time-0, the first-byte-pos is 1024. Random access requests that attempt to access before byte
position 1024 will not work.
– at time-60, the first-byte-pos becomes 14749767106. Random access requests that attempt to
access before byte position 14749767106 will not work, even though byte position 1024 was
valid at time-60.
See the comment in 11.4.2.15.1 of 11.4.2.15 for help with interpreting the “relative to the complete
content binary” phrase.

The npt-start-time, npt-last-time, first-byte-pos, last-byte-pos, and byte-pos tokens for this guideline
are relative to the complete content binary that is currently available, rather than being relative to
the content data returned in response.

11.4.2.16.3
[G UIDELINE ] If using Limited Random Access Data Availability Mode=0, then a Content Source
shall use increasing values for npt-start-time and first-byte-pos when reporting the available random
access data range, unless one of the following conditions is true.

• 180 min has elapsed since the last transport layer request for the content binary.
• The value of last-byte-pos or npt-last-time causes a rollover because the maximum permitted
value defined for the data type has been exceeded.
This guideline only applies when Limited Random Access Data Availability mode is applied to the
scenario.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 498 –

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a KPWXV

[C OMMENT] As time passes, the data range that is accessible can also change with time because
the server's s 0 position can change.
Furthermore, the s N position can increase with time, usually causing the duration of the content
binary to either temporarily increase when s 0 is temporarily non-changing or remain relatively
constant over time when s 0 slides with s N .

Given the nature of infinite streams (e.g. live content), Content Sources are permitted to use a
lesser values for first-byte-pos and npt-start-time.
The following example is an example timeline that exhibits this behavior.

– At time-0, the first-byte-pos is 0.

– Content requests occur for 180 min.
– At time-180, the first-byte-pos is 1474976710655.
– No content requests for 180 min.
– At time-360, the first-byte-pos is 0.
– Content requests occur for 360 min.
– At time-720, the last-byte-pos exceeds 281474976710655, so the server changes first-byte-pos
to 0.
A Content Receiver endpoint cannot seek to a position which it remembers if it does not request the
content for over 180 min.

11.4.2.16.4
[G UIDELINE ] If a Content Source uses the Limited Random Access Data Availability model under
Mode=1, then the following shall be true.

• The s 0 data boundary shall map to a fixed and non-changing beginning. This requirement is a
restriction of 11.4.2.14.3.
• The s 0 data position shall be the static and absolute beginning for the content. (i.e. The s 0
position is the beginning of the content that does not change with time.)
• The data range of [s 0 , s N ] shall map to the npt range of [0, npt-last-time] and the byte range of [0,
last-byte-pos], where npt-last time is in units of npt and last-byte-pos is in units of bytes.
• The content binary's zero position (i.e. npt-time=0 and byte-pos=0) shall map to the UCDAM's
data position of s 0 .
• The last-byte-pos and npt-last-time shall map to the UCDAM's s N data position and the s N data
boundary shall map to the end of the available content data. (This requirement works in
conjunction with 11.4.2.14.3.)
• Random access operations on [r 0 , r N ], where units are in npt, shall be timely for the entire range
of [r 0 , r N ].
• Random access operations on [r 0 , r N ], where units are in bytes, shall be timely only for a limited
subset of [r 0 , r N ]. Random access operations outside this subset are guaranteed to be satisfied
but timeliness is not guaranteed.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 499 –

• If the Content Source receives a transport layer request that is not a random access request (e.g.
HTTP request that omits Range and TimeSeekRange.dlna.org) then the Content Source shall
respond with content data from the beginning (i.e. npt=0 or byte-pos=0).
Timely means that the Content Source (under Ideal Network Conditions) is able to begin responding
with the requested content data within 27 s of receiving the request.

Note that the npt-last-time, npt-time, last-byte-pos, and byte-pos tokens for this guideline are
relative to the complete content binary that is currently available, rather than being relative to the
content data returned in response.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a VMHZL

[C OMMENT] This guideline defines Mode=1 behaviors for the Limited Random Access Data
Availability model. Mode=1 is most useful for converted content, where Content Sources have
access to a fixed beginning for the content, but can lack the computational power to respond in a
timely manner to byte-based random access positions. In such cases, the Content Source's
indicated values for bytes-range represent the range where the server can provide a fast response,
which is often the portion of converted content that is available at the current moment. Content
Receivers are permitted to request data outside those ranges (assuming the requested data falls
within the [s 0 , s N ] data range, but the server might have a significant delay before responding.

Live broadcast streams are generally not ideal candidates for using this data availability model. Live
broadcast streams will likely favor a sliding s 0 data boundary. For implementations that can support
live broadcast streams where the s 0 data boundary is fixed (e.g. by buffering/recording the data to
a local hard disk), the Full Random Access Data Availability model is more appropriate when the
buffered content is served without having to go through a content transformation.

See the comment in 11.4.2.15.1 of 11.4.2.15 for help with interpreting the “relative to the complete
content binary” phrase.

11.4.3 HTTP transport

11.4.3.1 General
There are many possible transport protocols that can be used for the transfer of content. The
baseline mandatory media transport protocol for DLNA devices is HTTP. For HTTP the following
terms are used:

• HTTP Client Endpoint – the DLNA entity that issues the HTTP GET or POST request;
• HTTP Server Endpoint – the DLNA entity that receives the HTTP GET or POST request and
issues an HTTP response (possibly including data);
• Streaming HTTP (Client/Server) Endpoint – An HTTP Client or Server Endpoint that processes
Streaming Transfers;
• Target Response: When a client makes a GET request to obtain a certain resource from the
server, the server normally responds with a message that includes a representation of the
resource as its entity body. This type of response is called here a Target Response to
differentiate it from other equally valid responses that do not involve transferring the requested
resource (e.g., redirections, authorization requests, error messages, etc). Similarly, for HEAD
requests, a Target Response is the same response that servers would form to satisfy the
matching GET request, but without carrying the resource representation as its entity body.
The generic term "HTTP endpoint" is used to represent either an HTTP Client Endpoint or an HTTP
Server Endpoint.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 500 –

Also note that the guidelines specified in this subclause apply to DLNA content transactions
between DLNA Device Classes or Device Capabilities. These guidelines do not specify behavior for
non-DLNA devices. A DLNA Device Class or Device Capability may be implemented by software
running on a more general-purpose device/platform. For example, the HTTP server of a DMS may
be used to serve DLNA and non-DLNA content. These guidelines apply only when the DLNA content
is being served to a DLNA device.

This subclause is organized into the following subclauses.

• 11.4.3.2 through 11.4.3.37: contains guidelines that are common to all HTTP transfers. These
guidelines are independent of the Transfer Mode.
• 11.4.3.38 through 11.4.3.58: contains guidelines that are specific to the use of HTTP for
Streaming Transfers.
• 11.4.3.59 through 11.4.3.61: contains guidelines that are specific to the use of HTTP for
Interactive Transfers.
• 11.4.3.62 through 11.4.3.64: contains guidelines that are specific to the use of HTTP for
Background Transfers.
• 11.4.3.65 through 11.4.3.69: contains guidelines that are specific to HTTP POST transactions.
HTTP POST transactions always work in conjunction with all other applicable HTTP guidelines.
11.4.3.2 MT baseline transport: HTTP
11.4.3.2.1
[G UIDELINE ] A DLNA device shall implement HTTP as the mandatory media transport with
constraints and extensions defined in subsequent entries of this subclause.

Guidelines 11.4.3.8 and 11.4.3.25 define the HTTP version expectations for HTTP servers and
clients.

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 5HZVT
+DN+ +UP+ 2616
+DNSYNC+
+UPSYNC+

[C OMMENT] DLNA specifies HTTP as the baseline media transport.

11.4.3.2.2
[G UIDELINE ] DLNA devices shall follow the syntax rules for HTTP headers defined in IETF RFC
2616 unless DLNA defines syntax for the HTTP header value.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC MHZLQ
+DN+ +UP+ 2616
+DNSYNC+
+UPSYNC+

[C OMMENT] The BNF rules used in IETF RFC 2616 is slightly different from that in DLNA. For
example, the default treatment of literals in IETF RFC 2616 is case-insensitive. Furthermore,
IETF RFC 2616 uses implied LWS between tokens and separator.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 501 –

11.4.3.2.3
[G UIDELINE ] If the DLNA guidelines define a BNF syntax for an HTTP header, then DLNA devices
shall not include white spaces in the header-value of HTTP headers unless SP and LWS are
explicitly specified in the syntax (BNF) definitions.

If the DLNA guidelines do not define a BNF syntax for an HTTP header, then the header shall
conform to the message-header syntax in 4.2 of IETF RFC 26161999, regardless of whether the
HTTP header is defined in IETF RFC 2616 or if the HTTP header is vendor-defined. Note that the
syntax for field-value permits LWS to separate tokens and other data in the field-value.

Implied LWS between the HTTP header-name and the HTTP header-value are allowed as specified
in IETF RFC 2616, regardless of whether the DLNA guidelines specify a BNF syntax for the HTTP
header.

The following cases are allowed examples:

• Range: bytes=1539686400-
• Content-Range:bytes 21010-47021/47022
• TimeSeekRange.dlna.org: npt=00:05:35.3-00
The following examples are not allowed:

• Range: bytes = 1539686400-

• Content-Range:bytes 21010-47021/47022
• TimeSeekRange.dlna.org: npt = 00 : 05 : 35.3-00
[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC HZVTL
+DN+ +UP+ 2616
+DNSYNC+
+UPSYNC+

[C OMMENT] IETF RFC 2616 allows, including white spaces, between any two adjacent words
(token or quoted-string), and between adjacent words and separators, e.g. "=", SP, "/", ":" (See
"implied *LWS" in the 2.1 of IETF RFC 2616), but this guideline restricts "implied *LWS" to simplify
white space rules for HTTP headers.

White spaces can still be included between header-name and header-value. The header-name and
header-value are defined in the 4.2 of IETF RFC 2616.

This guideline applies to HTTP headers defined in IETF RFC 2616 and other HTTP headers, e.g,
DLNA and vendor defined headers, with the DLNA guidelines. At least one LWS will be inserted
between tokens in case of the "* rule" syntax (e.g. USER-AGENT and SERVER headers).

11.4.3.3 MT HTTP graceful recovery

[G UIDELINE ] HTTP Client or Server Endpoints should not require a hardware reset or a power cycle
to return to normal operating conditions after encountering improperly terminated HTTP
connections.

[ATTRIBUTES ]

S A DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a ZVTLZ

+DN+ +UP+
+DNSYNC+

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 502 –

+UPSYNC+

[C OMMENT] This guideline specifies that a media endpoint needs to be able to handle scenarios
where an HTTP connection is not properly terminated. Network conditions and/or HTTP Server
Endpoint behavior can cause this scenario to occur. Although a full definition for graceful recovery
is not provided, a baseline expectation is that users will not need to reset or power cycle the device
simply because a content transfer was interrupted.

11.4.3.4 MT HTTP DLNA URI usage

[G UIDELINE ] HTTP Client Endpoints that issue HTTP requests on DLNA URIs (such as those
obtained from a UPnP AV ContentDirectory service implementation) may assume that the URI value
is properly URI escaped. No additional URI escaping logic is required of a client endpoint.

[ATTRIBUTES ]

O C DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 8RWS4

+DN+ +UP+ 2396
+DNSYNC+ IETF RFC
+UPSYNC+ 2616
ISO/IEC
29341-20-3

[C OMMENT] This guideline permits an endpoint to use URI values (obtained from a DLNA endpoint)
without having to implement logic for escaping the URI. This guideline is a clarification of 10.1.3.10,
which states that DMS devices will advertise URI values that are URI escaped. Although an
endpoint can implement additional logic for validating a URI, such logic is useful only for
interoperation with non DLNA devices.

This guideline applies generally, including HTTP GET, HEAD, and POST requests.

11.4.3.5 MT valid HTTP response

11.4.3.5.1
[G UIDELINE ] If an HTTP Server Endpoint receives an HTTP request, then the endpoint shall send
a valid HTTP response provided it has sufficient platform resources (network sockets, stored file in
readable state, available tuner hardware, etc.) for sending the response.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC HZLQD

2616
IETF RFC
2396

[C OMMENT] This guideline essentially obliges an endpoint to send an HTTP response to an HTTP
request.
Also, the HTTP specification already obliges a server to return a valid HTTP response for each
received HTTP request. Valid HTTP responses include among others: content byte data responses,
requests for authorization, HTTP error responses, etc.

11.4.3.5.2
[G UIDELINE ] If an HTTP Server Endpoint cannot respond to an HTTP request by sending or
receiving content byte data due to the server capacity, network capacity, or current state of the
device (such as a tuner locked in a recording state), then the HTTP server should respond with an
HTTP error response code of 503 (Service Unavailable).
DLNA guidelines; Part 1-1: Architecture and protocols
 – 503 –

[ATTRIBUTES ]

S R DMS +PU+ M-DMS n/a IETF RFC F7UZS

2616

[C OMMENT] This guideline covers the case where the endpoint has the resources to send an error
response but lacks the resources to send or accept content data. Sending an HTTP error is better
than denying the TCP connection request because it explicitly tells the requesting endpoint that
content cannot be handled at this moment. HTTP servers will respond with other HTTP error codes
when responding to other error scenarios, as indicated in the HTTP specification.

11.4.3.5.3
[G UIDELINE ] If an HTTP Server Endpoint cannot respond to an HTTP request by sending or
receiving content byte data due to the device's lack of available network sockets, then the endpoint
may refuse to create new TCP connections for answering content requests.

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a IETF RFC PWXV6

793
IETF RFC
2616

[C OMMENT] This guideline permits an HTTP server to refuse the creation of new TCP connections
when it lacks the resources for transporting content. Although this behavior is allowed by standard
convention, endpoints can continue to retry the creation of a TCP connection. Therefore, whenever
the situation is both appropriate and possible, HTTP servers are encouraged to respond with an
HTTP 503 error.

11.4.3.5.4
[G UIDELINE ] HTTP Client Endpoints that issue requests (e.g. for playback, download operation, or
any normative system usage) shall be capable of performing such operations even if the HTTP
Server Endpoint accepts only a single open HTTP connection at any given time.

HTTP Client Endpoints that claim support for a media operation for a particular content binary shall
be capable of perfoming such operations even if the HTTP Server Endpoint accepts only a single
open HTTP connection an any given time.

[ATTRIBUTES ]

M C DMP DMR +DN+ M-DMP n/a IETF RFC 3DTU5

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] Some HTTP Server Endpoints can accept multiple simultaneous HTTP connections,
but others can accept only one. This guideline ensures that HTTP Client Endpoints provide reliable
services even with the most constrained case (only one HTTP connection available).
For example, the following procedures in HTTP Client Endpoints will not work with HTTP Server
Endpoints that support a single HTTP connection:

• obtaining an IFO file in parallel to a content transfer connection;

• playback transitions between normal speed playback and trick mode playback with multiple
HTTP sessions that overlap in time, and

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 504 –

• tuner channel changes where one HTTP connection is used for the current channel and another
time-overlapping HTTP connection is used for the new channel selection.
11.4.3.5.5
[G UIDELINE ] HTTP Server Endpoints should support more than one simultaneous HTTP media
transport connection.

[ATTRIBUTES ]

S C DMS +PU+ M-DMS n/a IETF RFC 7UZS4

2616

[C OMMENT] It is a good practice for an HTTP Server Endpoint to support multiple HTTP Client
Endpoints simultaneously.

11.4.3.5.6
[G UIDELINE ] If an HTTP Server Endpoint has not completed the transmission of an HTTP response
and the HTTP Client Endpoint wants to stop the current data flow to issue a new request, then the
HTTP Client Endpoint should close the existing TCP connection and then create a new TCP
connection for the new HTTP request.

[ATTRIBUTES ]

S C DMP DMR +DN+ M-DMP n/a IETF RFC Y8RWS

+DNSYNC+ 2616

[C OMMENT] Since clients cannot assume that endpoints can support multiple HTTP connections,
this guideline recommends that clients use one TCP connection. Implementers of HTTP servers and
clients should also consider this guideline in conjunction with guidelines 11.4.3.49.1 and
11.4.3.49.2, which deal with scan operation playback (also known as trick-modes) for streaming
transfers.

11.4.3.5.7
[G UIDELINE ] An HTTP Server Endpoint shall begin sending a response message to an HTTP
requests within 27 s of receiving the request. Valid response messages shall be either the response
with content byte data, or appropriate error messages.

[ATTRIBUTES ]

M L DMS +PU+ MDMS n/a IETF RFC VQWR3

2616

[C OMMENT] This guideline defines the maximum response time for an HTTP Server Endpoint for a
request for content.

in conjunction with 11.4.3.5.9, these guidelines ensure HTTP transactions for media transport.

The time-out value is for the worst case. HTTP Server Endpoints are urged to respond to a request
as soon as possible.

11.4.3.5.8
[G UIDELINE ] An HTTP Client Endpoint shall wait at least 30 s before closing the TCP connection if
it has not received any response from the HTTP Server Endpoint to an HTTP GET request for
content.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 505 –

[ATTRIBUTES ]

M L DMP DMR +DN+ M-DMP n/a IETF RFC 3VQWR

+DNSYNC+ 2616

[C OMMENT] This guideline is not subject to scenarios involving user cancellation. A connection can
be cancelled through user intervention at any time.

This does not imply that the entire content binary will be received within the 30 s, only that it has
started.

11.4.3.5.9
[G UIDELINE ] HTTP Server Endpoints shall be capable of providing at least one media transport
HTTP connection and it shall also be capable of processing sequential HTTP requests without
responding with an HTTP error response code 503 (Service Unavailable).

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC W3DTU

2616

[C OMMENT] This guideline ensures that rendering endpoints are capable of rendering a content
binary using one media transport HTTP connection (see 11.4.3.5.4).

This guideline is not subject to preventing Content Sources to respond with 503 (Service
Unavailable) when it currently is unable to process a HTTP request (see 11.4.3.5.2). But a Content
Source will never return 503 (Service Not Available) under "Test Conditions".

11.4.3.5.10
[G UIDELINE ] An HTTP Server Endpoint shall use the HTTP status code of 503 (Service Unavailable)
for an HTTP request only on the conditions that the Content Source does not have sufficient
platform resources (network sockets, stored file in readable state, available tuner hardware, etc.)
for sending the response with content byte data. On other conditions, the HTTP Server Endpoint
shall not use the HTTP status code of 503 (Service Unavailable) for an HTTP request.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC FHYQ8

2616

[C OMMENT] This guideline defines the maximum response time for an HTTP Server Endpoint for a
request for content.

In conjunction with 11.4.3.5.9, these guidelines ensure HTTP transactions for media transport.

Time-out value is for the worst case. HTTP Server Endpoints are urged to respond to a request as
soon as possible.

11.4.3.5.11
[G UIDELINE ] An HTTP Client may treat HTTP Status code 503 (Service Unavailable) as equivalent
to HTTP Status code 500 (Internal Server Error).

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 506 –

[ATTRIBUTES ]

O C DMP DMR +DN+ M-DMP n/a IETF RFC M8EP7

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] The guideline clarifies a Content Receiver behavior for response message 503 with or
without Retry-After. Hence, no retry is required.

11.4.3.6 MT HTTP header tolerance

11.4.3.6.1
[G UIDELINE ] HTTP Client and Server Endpoints shall be tolerant of unknown HTTP headers.

Tolerant behavior is defined as being able to successfully "parse and interpret" or "parse and
ignore" the HTTP headers and their values.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 8EP7N
+DN+ +UP+ 1945
+DNSYNC+ IETF RFC
+UPSYNC+ 2616

[C OMMENT] This guideline addresses forward compatibility and allows for broader interoperability
with implementations that employ transport layer vendor extensions by way of HTTP headers.

11.4.3.6.2
[G UIDELINE ] Each HTTP header line (including the header's name and value but excluding the last
carriage-return/line-feed sequence, CRLF) shall not exceed 998 B.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC SFHYQ
+DN+ +UP+ 2616
+DNSYNC+ IETF RFC
+UPSYNC+ 2822

[C OMMENT] These guidelines limit the length of an HTTP header line according to 2.2.1 of
IETF RFC 2822. The guidelines also specify the normative way to encode HTTP headers that span
multiple lines.

Multi-line HTTP headers are always split at LWS characters.

11.4.3.6.3
[G UIDELINE ] If an HTTP header line (header's name and value but excluding the last CRLF)
exceeds 998 B, then the HTTP header shall span multiple lines. HTTP headers that span multiple
lines shall prefix the additional lines with at least one space (SP) or horizontal tab (HT) as described
in 4.2 of IETF RFC 2616.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 9GK5S
+DN+ +UP+ 2616
+DNSYNC+ IETF RFC
+UPSYNC+ 2822

DLNA guidelines; Part 1-1: Architecture and protocols

 – 507 –

11.4.3.7 MT HTTP header case-sensitivity

[G UIDELINE ] Names of HTTP headers shall be treated as case insensitive tokens.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC FW6L8
+DN+ +UP+ 1945
+DNSYNC+ IETF RFC
+UPSYNC+ 2616

[C OMMENT] This is normative according to the HTTP specification.

11.4.3.8 MT baseline transport: HTTP Server Endpoints

11.4.3.8.1
[G UIDELINE ] HTTP Server Endpoints used for media transport purposes shall be compliant with
HTTP/1.1, which also requires HTTP/1.0 compliance.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 2EZ3F

2616

[C OMMENT] HTTP servers need to support both HTTP/1.0 and HTTP/1.1 requests to ensure wide
interoperability.

11.4.3.8.2
[G UIDELINE ] HTTP/1.1 Server Endpoints used for media transport should return HTTP version 1.1
in the response header, regardless of the version specified in the HTTP client's request.

[ATTRIBUTES ]

S R DMS +PU+ M-DMS n/a IETF RFC ZFW6L

2145

[C OMMENT] IETF RFC 2145 clarifies that HTTP/1.1 servers are expected to return HTTP/1.1 even
if the HTTP server receives a request marked with HTTP/1.0. The robustness rules, specified by the
HTTP specification, enables clients and servers that employ different HTTP version numbers to
coexist properly.

Message format refers to both the HTTP headers and HTTP response body. As described by
IETF RFC 2145, the version field in a response message header indicates the protocol level that the
server is capable of understanding. However, a server that understands protocol version 1.1 can
generate messages compatible with version 1.0 in order to communicate with clients capable of
handling only the lower 1.0 version. When this happens, the response message has a version
header equal to 1.1, but the format of the message contains only version 1.0 headers. Reference
IETF RFC 2145 provides more details for interoperability between hosts with different HTTP
versions.

11.4.3.8.3
[G UIDELINE ] When responding to a request of version 1.0, an HTTP Server Endpoint shall format
the response message in such a way that the result of decoding and processing the message does
not depend on headers outside the scope of the HTTP 1.0 specification.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 508 –

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC GK5S4

2145
IETF RFC
2616

11.4.3.8.4
[G UIDELINE ] HTTP Server Endpoints shall not report a higher version of HTTP than is actually
supported by the implementation.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC EZ3F6

2616

11.4.3.8.5
[G UIDELINE ] Interoperability between HTTP Client and Server Endpoints that implement different
versions of the HTTP protocol shall follow the provisions and recommended actions defined in
IETF RFC 2145.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC Z3F6V
+DN+ +UP+ 2145
+DNSYNC+
+UPSYNC+

[C OMMENT] Reference IETF RFC 2145 defines the significance of HTTP version numbers, the
rules for interoperability between hosts with different version numbers, and rules for the actual
version number to be included when creating messages.

11.4.3.8.6
[G UIDELINE ] HTTP Server Endpoints should support persistent HTTP/1.1 connections and
pipelined HTTP/1.1 requests.

[ATTRIBUTES ]

S R DMS +PU+ M-DMS n/a IETF RFC 3F6V6

2616

[C OMMENT] The default behavior for HTTP servers responding to HTTP/1.1 requests is to support
persistent connections, which means that the HTTP server can respond to multiple HTTP/1.1
requests on one HTTP session. Pipelined requests can be used to facilitate seek operations. See
11.4.3.69 for more information.

11.4.3.9 MT HTTP header: scmsFlag.dlna.org

11.4.3.9.1
[G UIDELINE ] HTTP Client and Server Endpoints may use the scmsFlag.dlna.org HTTP header,
which indicates copyright assertion and copy status flags when transporting audio only content.
HTTP Server Endpoints that serve DLNA media content and non-DLNA media content may also use
this flag for the latter. HTTP Client Endpoints that encounter this HTTP header may implement
behavior to enforce regional copyright provisions.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 509 –

[ATTRIBUTES ]

O A DMS DMP +PU+ +UP+ M-DMS M-DMP n/a IETF RFC L8OUB
+DN+ +DNSYNC+ 2616
+UPSYNC+ AHRA

[C OMMENT] These guidelines make it possible to comply with regional legal requirements, such as
in AHRA. The flag is to be used with both DLNA and non DLNA audio only content. The syntax of the
value is strictly defined by these guidelines.

11.4.3.9.2
[G UIDELINE ] The notation of scmsFlag.dlna.org header field is defined as follows.

• scmsFlag.dlna.org = "scmsFlag.dlna.org" *LWS ":" *LWS flagValue

• flagValue = "00" | "01" | "10" | "11"
The value of the scmsFlag.dlna.org header shall be a two letter string from the following list: "00",
"01", "10" or "11". The first and second characters can be set to 0 or 1 independently according to
the rules below:

Definition of the value of the 1st character (i.e. left most) of the scmsFlag.dlna.org HTTP header:

• 0: copyright is asserted
• 1: no copyright is asserted
Definition of the value of the 2nd character of scmsFlag.dlna.org HTTP header:

• 0: Original recording
• 1: First generation or higher recording
The following example means copyright is asserted and first-generation or higher recording.

• scmsFlag.dlna.org: 01
[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a IETF RFC F6V65

+UPSYNC+ 2616
AHRA

11.4.3.10 MT HTTP header: Content-Type

11.4.3.10.1
[G UIDELINE ] HTTP Server Endpoints shall specify the Content-Type HTTP header in the HTTP
response header fields whenever it returns a Target Response to an HTTP GET operation.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC S4NTS

2616

[C OMMENT] It is imperative that endpoints specify the Content-Type field to allow the receiver to
know the MIME TYPE for the content that is to be sent in the HTTP response message.

MIME-TYPE values appear in the Content-Type HTTP header.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 510 –

11.4.3.10.2
[G UIDELINE ] The MIME-TYPE values that appear in Clause 5 of IEC 62481-2 shall be used as
values for Content-Type when an HTTP message describes DLNA media contents.

[ATTRIBUTES ]

M L DMS +PU+ +UP+ M-DMS n/a IEC 62481-2 K5S4N

+UPSYNC+

[C OMMENT] This guideline specifies the correct mime type values for use with the Content-Type
header field when transporting content encoded in a DLNA media format.

11.4.3.10.3
[G UIDELINE ] HTTP Client Endpoints shall specify the Content-Type HTTP header in the HTTP
request if using a POST operation to send data.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a IETF RFC 6L8OU

2616

11.4.3.11 MT HTTP header: contentFeatures.dlna.org

11.4.3.11.1
[G UIDELINE ] If an HTTP Server Endpoint receives an HTTP GET or HEAD request with the
getcontentFeatures.dlna.org HTTP header, then the HTTP server shall use the
contentFeatures.dlna.org HTTP header if it responds with a Target Response.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 7NKR8

2616
ISO/IEC
29341-20-3

[C OMMENT] As noted, this guideline permits an HTTP Server endpoint o use the
contentFeatures.dlna.org in an HTTP response.

11.4.3.11.2
[G UIDELINE ] An HTTP Server Endpoint may respond with the contentFeatures.dlna.org HTTP
header to an HTTP GET or HEAD request that does not have the getcontentFeatures.dlna.org HTTP
header.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC 5S4NT

2616
ISO/IEC
29341-20-3

11.4.3.11.3
[G UIDELINE ] HTTP Client Endpoints may use the getcontentFeatures.dlna.org when issuing GET
or HEAD requests.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 511 –

[ATTRIBUTES ]

O A DMP DMR +DN+ M-DMP n/a IETF RFC Q868P

+UP+ +DNSYNC+ 2616
+UPSYNC+ ISO/IEC
29341-20-3

[C OMMENT] These guidelines describe how an HTTP client endpoint can request an HTTP server
to use the contentFeatures.dlna.org in the response.

11.4.3.11.4
[G UIDELINE ] The notation of getcontentFeatures.dlna.org header field is defined as follows:

• getcontentFeatures.dlna.org = "getcontentFeatures.dlna.org" *LWS ":" *LWS "1"

The only value possible is "1".

Example:

• getcontentFeatures.dlna.org: 1
[ATTRIBUTES ]

M A DMS DMP DMR +DN+ M-DMS M-DMP n/a IETF RFC W6L8O
+UP+ +PU+ 2616
+DNSYNC+ ISO/IEC
+UPSYNC+ 29341-20-3

11.4.3.11.5
[G UIDELINE ] If an HTTP Server Endpoint receives any value except "1" in the
getcontentFeatures.dlna.org header it shall return an error code response of 400 (Bad Request).

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC EP7NK

2616
ISO/IEC
29341-20-3

11.4.3.11.6
[G UIDELINE ] The value of the contentFeatures.dlna.org HTTP header shall be the same value as
the fourth field of the content's res@protocolInfo value, as described in the 10.1.3.17 MM
protocolinfo values: 4th Field guideline.

The notation of contentFeatures.dlna.org header field for DLNA media transport is defined as
follows:

• contentFeatures-line = "contentFeatures.dlna.org" *LWS ":" *LWS 4th-field;

• 4th-field = <case sensitive 4th field value defined in guideline 10.1.3.17.1>.
[ATTRIBUTES ]

M A DMS +PU+ +UP+ M-DMS n/a IETF RFC TU5R3

+UPSYNC+ 2616
ISO/IEC
29341-20-3

[C OMMENT] This guideline allows HTTP transport transactions to carry information (that is
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 512 –

normally only accessible at the UPnP AV ContentDirectory service layer) about the requested
content (and the server capabilities for that content).

This header can be used by Content Sources for non-DLNA content.

11.4.3.11.7
[G UIDELINE ] HTTP Client Endpoints shall not include the following headers in HTTP requests,
unless the appropriate protocolInfo 4th field parameters indicate support for them.

• Range
• TimeSeekRange.dlna.org
• PlaySpeed.dlna.org
• getAvailableSeekRange.dlna.org
[ATTRIBUTES ]

M A DMP DMR +DN+ M-DMP n/a IETF RFC P7NKR

+UP+ +DNSYNC+ 2616
+UPSYNC+ ISO/IEC
29341-20-3

[C OMMENT] The 4th field of a protocolInfo is obtained from contentFeatures.dlna.org. Devices can
also directly check metadata in the CDS, without using contentFeatures.dlna.org.

These guidelines do not define interoperability guidelines for a scenario where an HTTP Client
Endpoint attempts to use an optional transport layer feature when the 4th field does not indicate
support for the transport layer feature.

11.4.3.11.8
[G UIDELINE ] An HTTP client that issues a POST request for uploading DLNA-conformant content
shall use the contentFeatures.dlna.org HTTP header. The value sent shall match the 4th field that
was sent in the CDS:CreateObject request, as defined in 10.1.8.19.6.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC YQ868

2616
ISO/IEC
29341-20-3

[C OMMENT] These guidelines explain how contentFeatures.dlna.org is used in POST transactions.

11.4.3.11.9
[G UIDELINE ] If an HTTP Server Endpoint receives a POST request

• without the contentFeatures.dlna.org HTTP header, or

• with a DLNA.ORG_PN parameter that is inconsistent with guideline 11.4.3.11.8,
then the HTTP Server Endpoint may respond with an HTTP error.

[ATTRIBUTES ]

O C DMS M-DMS n/a IETF RFC U5R3P

2616
ISO/IEC

DLNA guidelines; Part 1-1: Architecture and protocols

 – 513 –

29341-20-3

[C OMMENT] This guideline allows an HTTP Server Endpoint to accept upload of non-DLNA content
or allow it to reject such content.

11.4.3.12 MT HTTP header: dlna pragma-directive (ifoFileURI.dlna.org)

11.4.3.12.1
[G UIDELINE ] If an HTTP Server Endpoint provides a res@dlna:ifoFileURI for a resource (see
10.1.4.9) and the HTTP Server Endpoint receives an HTTP GET or HEAD request with the
Pragma-with-getIfoFileURI-pragma-directive in the HTTP request, then the HTTP Server Endpoint
shall provide the Pragma-with-ifoFileURI-pragma-directive (with the res@dlna:ifoFileURI value
associated with the target URI) if it responds with a Target Response.

If an HTTP Server Endpoint does not provide a res@dlna:ifoFileURI for a resource, then the HTTP
server shall not provide the Pragma-with-ifoFileURI-pragma-directive in the HTTP response.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC HYQ86

2616
ISO/IEC
29341-20-3

[C OMMENT] Subclause 14.32 of IETF RFC 2616 defines the Pragma as a general-header for
implementation-specific directives.

The DLNA.ORG_PN parameter in the contentFeatures.dlna.org header field indicates the DLNA
Media Format Profile ID. Furthermore, as described in 10.1.4.9, content profiled as
MPEG_PS_NTSC or MPEG_PS_PAL can have an IFO file. If the HTTP response to a request with
the Pragma-with-getIfoFileURI-pragma-directive does not include the
Pragma-with-ifoFileURI-pragma-directive, then the HTTP client endpoint needs to be aware that the
AV content does not have an IFO file.

Implementers need to be careful not to exceed the maximum 998 B limit for HTTP header lines when
using the Pragma-with-IfoFileURI-pragma-directive.

11.4.3.12.2
[G UIDELINE ] HTTP Client Endpoints may use the Pragma-with-getIfoFileURI-pragma-directive
when issuing GET or HEAD requests.

[ATTRIBUTES ]

O A DMP DMR +DN+ M-DMP n/a IETF RFC R368A

+DNSYNC+ 2616
ISO/IEC
29341-20-3

11.4.3.12.3
[G UIDELINE ] The notation of the PRAGMA header field with the getIfoFileURI-pragma-directive is
defined as follows:

• Pragma-with-getIfoFileURI-pragma-directive = "PRAGMA" *LWS ":" *LWS

*(pragma-directive *LWS "," *LWS) getIfoFileURI-pragma-directive *(*LWS "," *LWS
pragma-directive)
• pragma-directive = "no-cache" | extension-pragma
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 514 –

• extension-pragma = token [ "=" (token | quoted-string) ]

• getIfoFileURI-pragma-directive = "getIfoFileURI.dlna.org"
Note that the PRAGMA header name, pragma-directive token, and the
getIfoFileURI-pragma-directive token are case insensitive.

Examples:

• PRAGMA: getIfoFileURI.dlna.org
• PRAGMA: getIfoFileURI.dlna.org, no-cache
[ATTRIBUTES ]

M A DMP DMR +DN+ M-DMP n/a IETF RFC QWR36

+DNSYNC+ 2616
ISO/IEC
29341-20-3

[C OMMENT] The "1#token" syntax means a comma separated list including one or more elements.
LWS can appear before and after the separator comma ',' in this syntax. See 2.1 of IETF RFC 2616.

The Pragma-with-getIfoFileURI-pragma-directive can be used by endpoints issuing an HTTP

request on non-DLNA content.

11.4.3.12.4
[G UIDELINE ] The notation of the PRAGMA header field with the ifoFileURI-pragma-directive is
defined as follows

• Pragma-with-ifoFileURI-pragma-directive = "PRAGMA" *LWS ":" *LWS *(pragma-directive

*LWS "," *LWS) ifoFileURI-pragma-directive *(*LWS "," *LWS pragma-directive)
• pragma-directive = "no-cache" | extension-pragma
• extension-pragma = token [ "=" (token | quoted-string) ]
• ifoFileURI-pragma-directive = "ifoFileURI.dlna.org" "=" quoted-absolute-uri-string
• quoted-absolute-uri-string = <same value as the corresponding res@dlna:ifoFileURI attribute
value, as described in 10.1.4.9. It shall be quoted by """.>
Example:

• PRAGMA: ifoFileURI.dlna.org="http://192.168.0.1:8080/IFO_101.ifo"
The PRAGMA HTTP header name, the pragma-directive token, and the ifoFileURI-pragma-directive
token are case insensitive.

A Content Source that provides the Pragma-with-ifoFileURI-pragma-directive with non-DLNA

content shall also provide an IFO file that conforms to the guidelines 9.3.2.7 through 9.3.2.9 (GUNs
UDJLP, IT8C6, RDA5X) in IEC 62481-2.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC DTU5R

2616
ISO/IEC
29341-20-3
IEC 62481-2

DLNA guidelines; Part 1-1: Architecture and protocols

 – 515 –

11.4.3.13 MT HTTP HEAD requests

11.4.3.13.1
[G UIDELINE ] HTTP Server Endpoints (HTTP/1.1 and HTTP/1.0) shall respond to HTTP HEAD
requests, using the guidelines described below.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC WR368

2616

[C OMMENT] There are several interpretations to the format of HEAD responses. These guidelines
provide consistent interpretation.

11.4.3.13.2
[G UIDELINE ] A Target Response to a HEAD request shall be composed of only HTTP headers and
a zero-length response entity body.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC RWS43

2616

11.4.3.13.3
[G UIDELINE ] Target Responses to identical HTTP version HEAD and GET requests for a given
content binary shall use consistent transfer encoding headers. For example, if Content-Length is
included in a HEAD Target Response then Content-Length shall also be present in the GET Target
Response for the same content binary.

This guideline assumes that the content binary has not changed between the different HTTP
requests.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC S4397

2616

[C OMMENT] This guideline forbids HTTP Server Endpoints from responding to a GET request using
a different encoding method than the HEAD Target Response. For example, a DMS could not
respond to a HEAD request with Content-Length and respond to a GET request using chunked
encoding.

11.4.3.13.4
[G UIDELINE ] If an HTTP server does not know the length of a requested resource, such as in the
case when Chunked Transfer Coding is employed in HTTP/1.1, the Content-Length field shall be
omitted from the HEAD Target Response.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC WS439

2616

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 516 –

11.4.3.13.5
[G UIDELINE ] If an HTTP Server Endpoint (HTTP/1.1 and HTTP/1.0) responds to an HTTP GET
request with a non-error response, the HTTP server should respond to the equivalent HEAD request
with a non-error response.

A successful response is defined as an HTTP response with a status code in the 1xx or 2xx range.

[ATTRIBUTES ]

S C DMS +PU+ M-DMS n/a IETF RFC ZS4J4

2616

[C OMMENT] HTTP specification requires HTTP servers to respond to HEAD requests. This
guidelines clarifies that HTTP servers cannot respond with an error code for HEAD requests that
target a valid URI for the HTTP server.

This is not mandatory because conditions can be different than for those of the GET request (e.g.
server saturation, etc).

11.4.3.13.6
[G UIDELINE ] The HTTP headers of a HEAD Target Response shall include the Content-Type HTTP
header.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC S4J4Y

2616

[C OMMENT] Ideally, an HTTP server can know all of the HTTP headers (for requests that use
TimeSeekRange.dlna.org, Range, PlaySpeed.dlna.org, or other HTTP headers) that will be sent in
an HTTP response without doing any of the computational work to buffer content data, but some
scenarios (such as those involving transcoding, live streams, random access requests, etc.) require
a lot of computational cycles. For these reasons, these guidelines specify minimal expectations for
HEAD responses while recommending the ideal expectations.

11.4.3.13.7
[G UIDELINE ] HTTP HEAD Target Responses should have the exact same HTTP headers as those
in the equivalent HTTP GET Target Response.

[ATTRIBUTES ]

S R DMS +PU+ M-DMS n/a IETF RFC UZS4J

2616

11.4.3.13.8
[G UIDELINE ] An HTTP client should not issue an HTTP HEAD request to a URI intended for a file
upload (e.g. res@importUri, res@dlna:importIfoFileURI).

[ATTRIBUTES ]

S C +UP+ +UPSYNC+ n/a n/a IETF RFC V6QW5

2616

[C OMMENT] The MediaServers behavior of a HEAD request is undefined because implementations

DLNA guidelines; Part 1-1: Architecture and protocols

 – 517 –

that use the same URI value for res@importUri and the <res> value might choose to only respond in
the manner of a GET request.

11.4.3.14 MT image file size acquisition via HTTP HEAD

[G UIDELINE ] An HTTP Server that serves an image content binary should respond to HTTP/1.0
HEAD requests with the Content-Length header to indicate the length of the image content binary.

[ATTRIBUTES ]

S L DMS +PU+ M-DMS n/a IETF RFC XV6QW

2616

[C OMMENT] HTTP/1.0 HEAD requests allow control points to query a server for the length of an
image file, when res@size metadata is not available. The reason why HTTP/1.0 is used for this
purpose is that chunked transfer coding and Content-Length are used in a mutually exclusive
manner. Since HTTP servers are required to support HTTP/1.1, many servers use chunked transfer
coding. Furthermore, DLNA guidelines require HTTP headers to be the same for equivalent GET
and HEAD requests. Therefore, using HTTP/1.0 for the HEAD request improves the odds of
success.

11.4.3.15 MT HTTP header parsing (server)

[G UIDELINE ] HTTP Server Endpoints shall gracefully skip over unsupported HTTP header fields.
Under no circumstances can an HTTP server fail to process a properly formatted HTTP request
because of an unrecognized or unsupported HTTP header field.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC LZU6X

2616

[C OMMENT] Incorrect HTTP header parsing has been the source of numerous compatibility issues
during plugfest events.

11.4.3.16 MT HTTP header: Content-Length

11.4.3.16.1
[G UIDELINE ] If the Content-Length HTTP header is present in an HTTP message with a message
body, then the message shall not use Chunked Transfer Coding.

[ATTRIBUTES ]

M C DMS +PU+ +UP+ M-DMS n/a IETF RFC WXV6Q

+UPSYNC+ 2616

[C OMMENT] The usage of Content-Length is not allowed under 4.4 of the HTTP spec in IETF RFC
2616.

Applies to both HTTP GET response messages and POST request messages.

11.4.3.16.2
[G UIDELINE ] If the Content-Length HTTP header is omitted from an HTTP GET response, then the
HTTP Server Endpoint shall do one of the following.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 518 –

• The HTTP server will close the TCP connection after sending the last byte of the response
message. Furthermore, if the HTTP server is responding to an HTTP/1.1 transaction, then the
HTTP server shall also use the CONNECTION: CLOSE header and value to explicitly indicate
that it will close the connection. Lastly, any additional byte sequence following the headers shall
be treated as entity-body bytes until the instant when the connection is closed.
• The HTTP/1.1 server will use chunked transfer-coding for the response when communicating
with an HTTP/1.1 client.
This guideline applies in all scenarios with the following exceptions.

• Response messages that are prohibited from having an entity-body (such as the 1xx, 204, and
304 responses).
• The HTTP server returns an HTTP/1.1 response with no entity-body, Chunked Transfer Coding
is not used, and the CONNECTION:CLOSE header is not used (i.e. persistent connection).
[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC VTLZU

2616

[C OMMENT] These guidelines clarify the expected behavior regarding Content-Length usage for
response messages.

For pipelined requests, if the server decides to close a TCP connection for some response, any
additional requests submitted afterwards will not be processed by the server.

If the Content-Length is used in messages with no entity body, then the accurate value of "0" is
required per guideline 11.4.3.16.5. Likewise messages encoded with Chunked Transfer Coding will
use the accurate value of "0" for the chunk-size.

11.4.3.16.3
[G UIDELINE ] If the Content-Length HTTP header is omitted from an HTTP POST request, then the
HTTP Client Endpoint shall use Chunked Transfer Coding for the request.

[ATTRIBUTES ]

M C +UP+ +UPSYNC+ n/a n/a IETF RFC ZLQDW

2616

[C OMMENT] See 4.4 of IETF RFC 2616.

11.4.3.16.4
[G UIDELINE ] An HTTP message that carries no content binary data in the entity body, and which
uses Chunked Transfer Coding shall use a single chunk with chunk-size indicator equal to 0.

[ATTRIBUTES ]

M R DMS +PU+ +UP+ M-DMS n/a IETF RFC LQDWQ

+UPSYNC+ 2616

[C OMMENT] Some response messages do not carry content binary data in the message payload. If
the HTTP Server Endpoint is using Chunked Transfer Coding to produce this message, then the
message has a single one-line chunk-size indicator with a value of 0.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 519 –

11.4.3.16.5
[G UIDELINE ] When operating under persistent connections (including pipelining), an HTTP/1.1
client shall detect the existence of a message entity body when it receives a message with

• a non-zero Content-Length header,

• non-zero chunk-size values when using Chunked Transfer Coding,
• non-zero content bytes following the message headers when the HTTP server declares that it
will close the connection. (An HTTP server declares that it will close the connection by using the
"CONNECTION: CLOSE" header in the response.)
If the Content-Length header and the CONNECTION:CLOSE header are not provided and Chunked
Transfer Coding is not used in the HTTP/1.1 response, then the message has no entity body.

[ATTRIBUTES ]

M C DMP DMR +DN+ M-DMP n/a IETF RFC TLZU6

+DNSYNC+ 2616

[C OMMENT] This guideline clarifies the process used by a client to parse and extract the body (if
any) of received response messages.

Response messages that do not carry a Content-Length, and do not use transfer encoding, could
carry content bytes if the server closes the connection after sending the last byte. The server needs
to explicitly announce that the connection will be closed by using the adequate header.

11.4.3.16.6
[G UIDELINE ] When operating under persistent connections (including pipelining), an HTTP/1.1
Server shall detect the existence of a message entity body when it receives a POST message with

• a non-zero Content-Length header,

• non-zero chunk-size values when using Chunked Transfer Coding.
[ATTRIBUTES ]

M C DMS M-DMS n/a IETF RFC 6XJSB

2616

[C OMMENT] This guideline clarifies the process used by a server to parse and extract the body (if
any) of a request messages.

11.4.3.16.7
[G UIDELINE ] If an HTTP Server Endpoint knows the byte length of a response body, then the HTTP
server should use the Content-Length HTTP header in the HTTP Target Response.

[ATTRIBUTES ]

S C DMS +PU+ M-DMS n/a IETF RFC ZU6XJ

2616

[C OMMENT] As a general rule, the Content-Length provides useful information to HTTP clients.
However, the Content-Length HTTP header is not required because it is difficult to provide an
accurate byte length in some scenarios. For example, HTTP servers that are transmitting live
content (and some transcoded content) might not know the value for the Content-Length HTTP
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 520 –

header field. In cases when the Content-Length is provided, the value needs to match the byte
length of the response body.

11.4.3.16.8
[G UIDELINE ] If the HTTP Server Endpoint does not know the byte length of the response entity
body or if Content-Length cannot be used due to some exceptions listed in IETF RFC 2616, 4.4,
then HTTP servers shall omit the Content-Length HTTP header from HEAD, and GET Target
Responses.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC U6XJS

2616

11.4.3.16.9
[G UIDELINE ] If an HTTP Server Endpoint sends an HTTP GET Target Response with the
Content-Length HTTP header, then the byte length of the response entity body shall match the
value of the Content-Length HTTP header.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC DWQ3K

2616

11.4.3.16.10
[G UIDELINE ] If an HTTP Server Endpoint receives an HTTP/1.0 GET request and sends an HTTP
Target Response that does not have a Content-Length HTTP header, then the HTTP server shall
close the TCP connection when all data is transferred.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC QW58V

2616

[C OMMENT] The HTTP server is required to close the TCP connection in this scenario because only
the HTTP server knows when it has finished sending the bytes for the requested URI.

11.4.3.16.11
[G UIDELINE ] If an HTTP Client Endpoint knows the byte length of the entity-body in a POST request,
then the HTTP client should use the Content-Length HTTP header in the HTTP request.

[ATTRIBUTES ]

S R +UP+ +UPSYNC+ n/a n/a IETF RFC Q3KYV

2616

11.4.3.16.12
[G UIDELINE ] If the HTTP Client Endpoint does not know the byte length of the entity-body in a
POST request or if Content-Length cannot be used, the HTTP Client Endpoint shall omit the
Content-Length HTTP header from the POST request and use the Chunked Transfer Coding as
specified in IETF RFC 2616, 4.4.

[ATTRIBUTES ]

M R +UP+ +UPSYNC+ n/a n/a IETF RFC 6QW58

2616

DLNA guidelines; Part 1-1: Architecture and protocols

 – 521 –

11.4.3.16.13
[G UIDELINE ] If an HTTP Client Endpoint sends an HTTP POST Request with the Content-Length
HTTP header, then the byte length of the entity-body shall match the value of the Content-Length
HTTP header.

[ATTRIBUTES ]

M R +UP+ +UPSYNC+ n/a n/a IETF RFC WQ3KY

2616

11.4.3.17 MT maximum byte size transfers

11.4.3.17.1
[G UIDELINE ] HTTP Client and Server Endpoints shall not use values that exceed
281474976710655 (i.e. 2^48 - 1) for the following HTTP fields:

• Content-Length header;
• first byte pos and last byte pos (as defined in 14.35.1 and 14.16 of IETF RFC 2616 and guideline
11.4.3.22.2);
• instance-length (as defined in 14.16 of IETF RFC 2616);
• chunk-size (as defined in 3.6.1 of IETF RFC 2616).
[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 4J4YC
+DN+ +UP+ 2616
+DNSYNC+
+UPSYNC+

[C OMMENT] The HTTP specification, IETF RFC 2616, does not limit the maximum content length.
Note that a 32 bit integer is not sufficient, especially, for a 2 hour MPEG-2 stream that exceeds
4 GiB. The specified range covers the maximum size of a DLNA content binary.

Chunk-size is in hexadecimal form, while the other fields are in decimal form.

11.4.3.17.2
[G UIDELINE ] An HTTP Client or Server Endpoint shall parse and interpret values up to
281474976710655 (i.e. 2^48 - 1) for the Content-Length header field, Range Units in bytes, and
chunk-size field that are represented in HTTP requests/responses.

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC W58V5
+DN+ +UP+ 2616
+DNSYNC+
+UPSYNC+

11.4.3.18 MT HTTP common random access data availability requirements

11.4.3.18.1
[G UIDELINE ] If an HTTP Server Endpoint supports the Range header field or
TimeSeekRange.dlna.org header fields for a content binary, it should support and process an HTTP
HEAD request to get the current random access data range for the content binary while it is
processing the HTTP GET request to transmit the Target Response.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 522 –

The process for acquiring the random access data ranges for Full Random Access Data Availability
and Limited Random Access Data Availability model are described in 11.4.3.19 and 11.4.3.19.10,
respectively.

All guidelines in this subclause apply for both Full Random Access Data Availability and Limited
Random Access Data Availability models.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC J4YC9

2616

[C OMMENT] Guideline 11.4.3.5.4 states that HTTP clients will not assume that HTTP servers
accept more than one media transport HTTP connection at a time. Although an HTTP client will not
assume that the HTTP server accepts more than one HTTP GET request simultaneously, this
guideline clarifies the intent for HEAD requests. In cases where a random access data range is
updated while an HTTP client is receiving streaming data from a HTTP GET request, it is useful for
the HTTP client to use an HTTP HEAD request to get the current random access data range
simultaneously.

11.4.3.18.2
[G UIDELINE ] If an HTTP Server Endpoint supports the TimeSeekRange.dlna.org header field for
the specified URI, it shall process any requested range in the random access data range at the time.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 97ES2

2616

[C OMMENT] This is a general requirement that random access requests be supported on the entire
[r 0 , r N ] data range.

11.4.3.18.3
[G UIDELINE ] If an HTTP Server Endpoint supports the Range header field for the specified URI, it
shall process any requested range in the random access data range at the time.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 397ES

2616

[C OMMENT] This is a general requirement that random access requests be supported on the entire
[r 0 , r N ] data range.

11.4.3.19 MT HTTP data range of Full Random Access Data Availability

11.4.3.19.1
[G UIDELINE ] When using the Full Random Access Data Availability model, the byte position
corresponding to the npt value of 0 and for the TimeSeekRange.dlna.org header field shall refer to
one of the following:

• Byte position 0;
• The decoder friendly position (see 11.4.3.23.5, GUN ES2RR).

DLNA guidelines; Part 1-1: Architecture and protocols

 – 523 –

All guidelines in this subclause apply only in the case of Full Random Access Data Availability
model.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 4397E
2616

[C OMMENT]

a) These guidelines clarify guidelines 11.4.2.15 by explaining how npt values and byte indices are
used with the TimeSeekRange.dlna.org and Range headers.
b) For some media formats the decoder friendly position is not byte position 0. For example, in the
case of DLNA-compliant MP4 files, the GOP for time 0 could be located up to 1 MB away from
the beginning of the file
11.4.3.19.2
[G UIDELINE ] If the end position is not specified in a GET request with Range or
TimeSeekRange.dlna.org, then the HTTP Server Endpoint's transmission of the Target Response
shall include the content data that is currently available and the content data that will be available in
the future for the current stream. (That is, assuming s N is changing with time, the server keeps
transmitting data until s N becomes permanently fixed.)

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 8A57U

2616

11.4.3.19.3
[G UIDELINE ] The byte position of 0 for the Range header field shall refer to the beginning of the
content binary.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 3PU8U
+DN+ +DNSYNC+ 2616

11.4.3.19.4
[G UIDELINE ] If an HTTP Server Endpoint receives an HTTP GET request that omits the Range and
TimeSeekRange.dlna.org HTTP headers, then the HTTP Server Endpoint shall infer a byte-pos of 0
(i.e. respond from the beginning of the content binary).

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC 368A5

2616

[C OMMENT] This guideline ensures that HTTP clients will receive content in a manner consistent
with the conventions established by HTTP.

11.4.3.19.5
[G UIDELINE ] If an HTTP Server Endpoint supports the Range HTTP header (as defined in the
11.4.3.22) with the Full Random Access Data Availability model, the HTTP Server Endpoint should

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 524 –

specify the instance-length in the Content-Range HTTP header field of the Target Response to a
HTTP GET/HEAD request with the Range HTTP header field.

[ATTRIBUTES ]

S C DMS +PU+ M-DMS n/a IETF RFC R3PU8

2616

[C OMMENT] This guideline clarifies 14.16 of IETF RFC 2616. The asterisk "*" can be used instead
of the instance-length if the instance-length is unknown at the time when the response was
generated or when s N increasing is true. However, DLNA recommends that HTTP servers provide
an instance-length.

11.4.3.19.6
[G UIDELINE ] If an HTTP Client Endpoint wants to get the instance-length of a content binary, then
it should use an HTTP HEAD request with the Range HTTP header that specifies 0 for the
first-byte-position and omits the end byte-position.

[ATTRIBUTES ]

S C DMP DMR +DN+ M-DMP n/a IETF RFC 68A57

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] The response will include the Content-Range header. If the instance length is known,
then it will be number of bytes in the UCDAM [s 0 , s N ] data range. Otherwise, the instance-length
token will be "*".

11.4.3.19.7
[G UIDELINE ] If an HTTP Server Endpoint is serving stored content it shall provide the
instance-length in the Content-Range header.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 5R3PU

+UPSYNC+ 2616

11.4.3.19.8
[G UIDELINE ] If an HTTP Server Endpoint supports the TimeSeekRange.dlna.org HTTP header (as
defined in guideline 11.4.3.23) with the Full Random Access Data Availability model, the HTTP
Server Endpoint shall specify the duration of the entire content binary in the instance-duration field
of the TimeSeekRange.dlna.org HTTP header sent in response to an HTTP GET/HEAD request with
the TimeSeekRange.dlna.org HTTP header field.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 8PW38

2616

[C OMMENT] This guideline clarifies guideline 11.4.3.23.2.

11.4.3.19.9
[G UIDELINE ] In conjunction with the guideline 11.4.3.19.8, if an HTTP Server Endpoint supports
both byte-based seek and time-based-seek operations for a resource, it shall specify the byte length

DLNA guidelines; Part 1-1: Architecture and protocols

 – 525 –

of the entire content binary in the instance-length field of the TimeSeekRange.dlna.org HTTP
header field sent in response to an HTTP GET/HEAD request with the TimeSeekRange.dlna.org
HTTP header field.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 6V65V

2616

11.4.3.19.10
[G UIDELINE ] If an HTTP Client Endpoint wants to get the instance-duration of a content binary,
then it should use an HTTP HEAD request with the TimeSeekRange.dlna.org HTTP header that
specifies 0 for the npt-start-time and omits the npt-end-time.

[ATTRIBUTES ]

S C DMP DMR +DN+ M-DMP n/a IETF RFC QHQQZ N

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] The response will include the TimeSeekRange.dlna.org header. If the instance
duration is known, then it will be the duration of the UCDAM [s 0 , s N ] data range. Otherwise, the
instance-duration token will be "*".

11.4.3.20 MT HTTP: data range of Limited Random Access Data Availability

11.4.3.20.1
[G UIDELINE ] If the end position is not specified in a GET request with Range or
TimeSeekRange.dlna.org, then the HTTP Server Endpoint's transmission of the Target Response
shall include the content data that is currently available and the content data that will be available in
the future for the current stream. (That is, assuming s N is changing with time, the server keeps
transmitting data until s N becomes permanently fixed.)

All guidelines in this subclause apply only in the case of Limited Random Access Data Availability
model.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC OUBZ3

2616

[C OMMENT] In the case of live content, the end of the content binary is undefined. If the end
position is not specified in the request, it means the client wants to continue receiving data until the
absolute end of the stream.

11.4.3.20.2
[G UIDELINE ] Since the random access data range of [r 0 , r N ] is able to change at any time, the HTTP
Client Endpoint should not assume that a GET request (with either Range or
TimeSeekRange.dlna.org) that specifies a range with a previous random access data range will
always return the requested data range when mode-flag is “0”.

[ATTRIBUTES ]

S C DMP DMR M-DMP n/a IETF RFC KR8WA

2616

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 526 –

[C OMMENT]

a) When mode-flag is 0, an HTTP byte seek or time seek request canreturn a range response
that differs from the requested range due to the continuously changing random access data
range. So long as there is some overlap between the seek request and the currently
available content, the Client Endpoint can determine the effective range of a seek via the
Content-Range or TimeSeekRange.dlna.org response headers.

b) A seek request that falls completely outside the random access data range will return error
code 416 (Requested Range Not Satisfiable), (see 11.4.3.22.5)

c) Note that if sN is increasing, and an end position is not specified in the range request, the
end position and content length/duration will not be provided in the seek response header.
(see 11.4.3.20.1)

11.4.3.20.3
[G UIDELINE ] If the HTTP Client Endpoint includes both the TimeSeekRange.dlna.org HTTP header
field and the PlaySpeed.dlna.org HTTP header field in an HTTP GET request for a content binary in
case of the Limited Random Access Data Availability model, it shall specify the end position of the
request range in the range specifier of the TimeSeekRange.dlna.org HTTP header. This guideline
applies to both positive speed value (forward scan mode) and negative speed value (backward scan
mode).

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 68PW3

2616

[C OMMENT] Even if the HTTP server supports the PlaySeed.dlna.org HTTP header field for server
side's trick mode, it cannot process it beyond the current available data in case of Limited Random
Access Data Availability.

11.4.3.20.4
[G UIDELINE ] If an HTTP Server Endpoint supports either the Range HTTP header (as defined in
guideline 11.4.3.22) or the TimeSeekRange.dlna.org HTTP header (as defined in guideline
11.4.3.23) with the Limited Random Access Data Availability model for a content binary, the HTTP
Server Endpoint shall support the getAvailableSeekRange.dlna.org HTTP header field and
availableSeekRange.dlna.org HTTP header field in HTTP GET/HEAD requests for the content
binary.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 868PW

2616

[C OMMENT] Essentially, a server that supports the Limited Random Access Data Availability model
for HTTP needs to implement support for the getAvailableSeekRange.dlna.org and
availableSeekRange.dlna.org HTTP headers. These headers allow clients to request the random
access data range and allow servers to respond with that information.

11.4.3.20.5
[G UIDELINE ] If an HTTP Server Endpoint that supports the availableSeekRange.dlna.org HTTP
header field (for a content binary) receives an HTTP HEAD/GET request with the

DLNA guidelines; Part 1-1: Architecture and protocols

 – 527 –

getAvailableSeekRange.dlna.org HTTP header, it shall respond with the

availableSeekRange.dlna.org HTTP header field to return the current random access data range.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC NKR8W

2616

11.4.3.20.6
[G UIDELINE ] The notation of getAvailableSeekRange.dlna.org header field shall be as follows:

• getAvailableSeekRange-line = "getAvailableSeekRange.dlna.org" *LWS ":" *LWS "1"

The only value possible is "1". Any other values sent shall result in the HTTP server responding with
an error code of 400 (Bad Request).

Example:

• getAvailableSeekRange.dlna.org: 1
[ATTRIBUTES ]

M A DMS DMP DMR +DN+ M-DMS M-DMP n/a IETF RFC R8WAA
+PU+ +DNSYNC+ 2616

11.4.3.20.7
[G UIDELINE ] If an HTTP Server Endpoint receives any value except "1" in the
getAvailableSeekRange.dlna.org header it shall return an error code response of 400 (Bad
Request).

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 8OUBZ

2616

11.4.3.20.8
[G UIDELINE ] The notation of the availableSeekRange.dlna.org header field for DLNA media
transport shall be as follows:

• availableSeekRange-line = "availableSeekRange.dlna.org" *LWS ":" *LWS mode-flag SP range

specifier
• mode-flag = "0" | "1"
• range specifier = npt range [SP byte-range] | byte-range
• npt range = "npt" "=" npt time "-" npt time
• npt time = <syntax defined in 11.4.2.13>
• byte range = "bytes" "=" first byte pos "-" last byte pos
• first byte pos = 1*DIGIT
• last byte pos = 1*DIGIT
Note that literals, "npt" and "bytes", are case sensitive.

Examples:

• availableSeekRange.dlna.org: 0 bytes=214748364-224077003
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 528 –

• availableSeekRange.dlna.org: 0 npt=00:05.30.12-00:10:34
• availableSeekRange.dlna.org:1npt=00:05.30.12-00:10:34 bytes=214748364-224077003
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC UBZ33

2616

11.4.3.20.9
[G UIDELINE ] If mode-flag is "0", then the following behaviors shall be implemented by the HTTP
Server Endpoint when responding with the availableSeekRange.dlna.org HTTP header.

• The HTTP Server Endpoint shall implement rules in 11.4.2.16, guideline 11.4.2.16.2 and
guideline 11.4.2.16.3 for Mode=0.
• The range-specifier (i.e. npt-range and/or bytes-range) shall indicate the [r 0 , r N ] data range,
effective at the time the response with the availableSeekRange.dlna.org header is generated.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC NTSXZ

2616

[C OMMENT] This guideline clarifies the Mode=0 rules described in 11.4.2.16, Requirement
11.4.2.16.2, by explaining how specific syntax tokens refer to the UCDAM data boundaries.

The npt and byte positions provided in the range-specifier indicate the available data range for
Range or TimeSeekRange.dlna.org seek requests.

11.4.3.20.10
[G UIDELINE ] An HTTP Client Endpoint operating on Limited Random Access Data Availability
model content with mode-flag set to “0” may specify a value for the first-byte-pos or the
npt-start-time tokens in a request that precedes the available seek range and expect a seek
response so long as the last-byte-pos or npt-end-time do not also precede the available seek range.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC V65V8 C

2616

[C OMMENT]

a) While a Client Endpoint can use the getAvailableSeekRange.dlna.org request to establish

the available seek range on the Server Endpoint at an instant in time, the available range
may change on the Server by the time a byte-seek or time-seek request based on the
available seek range is received. The Client Endpoint can still expect a seek response so
long as there’s some overlap between the requested range and the available range.

b) A client can expect a Range request with “bytes=0-“ or TimeSeekRange.dlna.org request

with “npt=0-“ to return all the data in the available seek range. When sN is increasing, these
requests will return all the data in the available seek range and additional data as it becomes
available. (see 11.4.3.20.1)

c) A GET request with no Range or TimeSeekRange.dlna.org header will return data as the
data becomes available (“live”) when sN is increasing. (see 11.4.2.16.2)

DLNA guidelines; Part 1-1: Architecture and protocols

 – 529 –

11.4.3.20.11
[G UIDELINE ] If mode-flag is "1", then the following behaviors shall be implemented by the HTTP
Server Endpoint when responding with the availableSeekRange.dlna.org HTTP header.

• The HTTP Server Endpoint shall implement rules in 11.4.2.16.4 (MT Limited Random Access
Data Availability model) for Mode=1.
• If present, the npt-range shall map to [r 0 , r N ] such that if the HTTP Server Endpoint receives a
request that specifies an npt-range that is inclusively within the server's range-specifier (as
indicated in availableSeekRange.dlna.org), then the HTTP Server Endpoint shall be able to
serve the requested data bytes in a timely manner.
• If present, the bytes-range map to a subset of [r 0 , r N ] such that if an HTTP Server Endpoint
receives a request that specifies a bytes-range that is inclusively within the server's
range-specifier (as indicated in availableSeekRange.dlna.org), then the HTTP Server Endpoint
shall be able to serve the requested data bytes in a timely manner.
• The npt-pos and byte-pos of "0" shall be valid and shall point to the beginning of the content.
• Servers that receive a GET request that omits both Range and TimeSeekRange.dlna.org shall
respond with content data from the absolute beginning (i.e. s 0 ) of the content.
A timely response is defined in 11.4.2.16.4.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 4NTSX

2616

[C OMMENT] This guideline clarifies the Mode=1 rules described in 11.4.2.16 , Requirement
11.4.2.16.4, by explaining how syntax tokens refer to the UCDAM data boundaries.

The byte range in the range-specifier indicate the data range for use in requests that use Range
where the response will return in a timely manner.

Unlike Range, responses with TimeSeekRange.dlna.org are timely for the entire content binary.

Unlike Mode=0, a request that omits the Range and TimeSeekRange.dlna.org headers results with
content data from the beginning of the content binary, which is required to be static and
non-changing.

11.4.3.20.12
[G UIDELINE ] If mode-flag is "1", then the HTTP Server Endpoint shall be able to respond with the
requested data bytes, even if the request specifies a bytes-range (in the HTTP request) that is not
inclusively within the server's range-specifier (as indicated in the HTTP server's responses with
availableSeekRange.dlna.org).

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC TSXZZ

2616

[C OMMENT] The content data mapped by range-specifier is where timely responses are
mandatory.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 530 –

The content data for [s 0 , s N ] is always available for transmission although the computational
complexity to perform responses for the portions outside of the server's indicated range-specifier (in
the availableSeekRange.dlna.org header value) can cause in responses that are not timely.

11.4.3.20.13
[G UIDELINE ] If mode-flag is "1" and the HTTP Server Endpoint responds with data bytes that is not
inclusively within the server's range-specifier (as indicated in the HTTP server's responses with
availableSeekRange.dlna.org), then the HTTP server, may begin its response with content data
after 27 s.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC 65V8D

2616

11.4.3.20.14
[G UIDELINE ] If an HTTP Server Endpoint supports the TimeSeekRange.dlna.org HTTP header for
a content binary that operates under the Limited Random Access Data Availability model, it shall
provide the npt-range in the availableSeekRange.dlna.org HTTP header field of the Target
Response to an HTTP request with the getAvailableSeek.Range.dlna.org header HTTP header
field.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC ZZXWQ

2616

[C OMMENT] The availableSeekRange.dlna.org and getAvailableSeekRange.dlna.org HTTP

headers apply in scenarios where the HTTP server and content are governed by the Limited
Random Access Data Availability model. Using these HTTP headers for other scenarios (such as
those involving Full Random Access Data Availability model) is out-of-scope of this standard.

11.4.3.20.15
[G UIDELINE ] If an HTTP Server Endpoint supports the Range HTTP header for a content binary
that operates under the Limited Random Access Data Availability model, it shall provide the
bytes-range in the availableSeekRange.dlna.org HTTP header field of the Target Response to an
HTTP request with the getAvailableSeek.Range.dlna.org header HTTP header field.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC SXZZX

2616

11.4.3.20.16
[G UIDELINE ] If the mode-flag=0, then an HTTP Client Endpoint shall not assume an npt value 0 or
a byte position of 0 returned in an availableSeekRange.dlna.org HTTP header has any special
significance.

[ATTRIBUTES ]

M C DMP DMR +DN+ M-DMP n/a IETF RFC 8DU64

+DNSYNC+ 2616

[C OMMENT] When the mode-flag is zero, then the "beginning of the content" becomes undefined.
Clients are not to assume that npt or byte positions of 0 map to the beginning of the content or that

DLNA guidelines; Part 1-1: Architecture and protocols

 – 531 –

the same content will be associated with time/byte 0. See 10.1.3.33.2 for conditions that can cause
the Content Source to reset the s0 position.

11.4.3.20.17
[G UIDELINE ] If an HTTP Server Endpoint receives an HTTP GET request when s 0 increasing is
false and neither Range nor TimeSeekRange.dlna.org are supported by the HTTP Server Endpoint,
then the HTTP Server Endpoint shall infer a byte-pos of 0 (i.e. respond from the beginning of the
content binary).

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC 5V8DU

2616

[C OMMENT] This guideline ensures that HTTP clients will receive content in a manner consistent
with the conventions established by HTTP.

11.4.3.21 MT HTTP mapping for byte-based seek and time-based seek

11.4.3.21.1
[G UIDELINE ] The Range HTTP header shall be used as the mechanism for byte-based seek
operations on the HTTP transport protocol. The seek-able data range shall be equivalent to the
random access data range of [r 0 , r N ].

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC BZ33H
2616

[C OMMENT] Byte-based seek is a generic, transport layer term that applies only to Streaming
Transfer. The Range header is a specific transport layer mechanism for HTTP.

Range header is valid for Interactive Transfer and Background Transfer, as described in 11.4.3.61
and 11.4.3.64. However, the byte-based seek operation is only valid for Streaming Transfer.

11.4.3.21.2
[G UIDELINE ] The TimeSeekRange.dlna.org HTTP header shall be used as the mechanism for
time-based seek operations on the HTTP transport protocol. The seek-able data range shall be
equivalent to the random access data range of [r 0 , r N ].

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC XZZXW
2616

[C OMMENT]

a) Time-based seek is a generic, transport layer term that applies only Streaming Transfer. The
TimeSeekRange.dlna.org header is a specific transport layer mechanism for HTTP.
b) Time-based seek operation is valid only for Streaming Transfer. Using the
TimeSeekRange.dlna.org header is expressly prohibited for Background Transfer and
Interactive Transfer.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 532 –

11.4.3.22 MT HTTP header: Range (server)

11.4.3.22.1
[G UIDELINE ] If the Content Source indicates support for the Range HTTP header for a content
binary (as defined in guidelines 10.1.3.20.1 and 10.1.3.28.4), then the HTTP Server Endpoint shall
respond to Range HTTP requests for that content binary as defined in IETF RFC 2616 with
clarifications and constraints defined in guidelines 11.4.3.22.2 to 11.4.3.22.8.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC V8DU6

2616

[C OMMENT] HTTP Server Endpoints that receive an HTTP request with a Range header field are
expected to respond in a specific manner. The rules below describe what an HTTP server needs if
the URI can or cannot support requests with a specified Range.

11.4.3.22.2
[G UIDELINE ] The notation of Range header field for DLNA media transport shall be as defined in
IETF RFC 2616 with the restriction that only one interval is allowed.

The restricted syntax is as defined below:

• range-line = "Range" *LWS ":" *LWS range specifier

• range specifier = byte range specifier
• byte range specifier = bytes unit "=" byte range set
• bytes unit = "bytes"
• byte range set = byte range spec
• byte range spec = first byte pos "-" [last byte pos]
• first byte pos = 1*DIGIT
• last byte pos = 1*DIGIT
Note that the literal, "bytes", is case sensitive.

Examples:

• Range: bytes=1539686400-
• Range: bytes=1539686400-1540210688
[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC Z33H5
+UP+ +DN+ 2616
+DNSYNC+
+UPSYNC+

[C OMMENT] This guideline simplifies the implementation of HTTP Server Endpoints by requiring
only a subset of the allowed Range syntax afforded by IETF RFC 2616. Essentially, DLNA
implementations of HTTP clients can only assume that a DLNA implementation of an HTTP server
will support Range values that indicate the first byte index and an optional last byte index. In
summary, this restriction means that only a single range will be used within the Range header field.

While this guideline limits the number of range intervals to a single one, any other rules on syntax or
semantics from IETF RFC 2616 remain applicable.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 533 –

11.4.3.22.3
[G UIDELINE ] If an HTTP Server Endpoint returns data including the requested range (Target
Response) with the HTTP response code 206 (Partial Content), then it shall specify the
Content-Range header field.

Example of Content-Range header.

• Content-Range: bytes 1539686400-1540210688/9238118400

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 8WAAX

2616

[C OMMENT] This guidelines obliges an HTTP Server Endpoint to respond with a 206 response code
for a request thatis satisfiable according to IETF RFC 2616 10.4.7 and 14.35.1. This allows HTTP
Client Endpoints to depend on the availability of this response header, simplifying their
implementations.

Subclause 14.16 in IETF RFC 2616 has examples on this guideline usage.

This guideline does not explain the relationship between first-byte-pos and last-byte-pos and the s 0
and s N data boundaries. For example, if first-byte-pos=50 and last-byte-pos=200, then the
response entity body will contain 151 B. The first byte of the entity-body will correspond to the 51st
byte of the complete file and the last byte of the entity body will correspond to the 201st byte,
relative to the complete content binary. This scenario does not at all imply that the 51st or 201st
bytes (of the complete content binary) have any specific relationship to the s 0 or s N data boundaries.
Building on this example, if the s N increasing flag is true, then the complete binary is still increasing
size. This results in a scenario where the 201st byte does not map to the s N data boundary.

11.4.3.22.4
[G UIDELINE ] If the HTTP Server Endpoint uses the Content-Range HTTP header, then the
provided values shall be accurate with respect to the entity response body. Specifically,

• the value indicating the first-byte-pos shall properly match the first byte of the response entity
body;
• the first-byte-pos in the response shall match the first-byte-pos in the request message;
• the value indicating the last-byte-pos shall properly match the last byte of the response entity
body;
• the value indicating the instance-length shall indicate the length of the entire content binary or
asterisk (*) if unknown.
Note that "accurate with respect to the entity response body" means that the guideline explains that
the values used for the Content-Range header's first-byte-pos and last-byte-pos tokens need to
correspond to the actual content data that is returned in the response entity body.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 38J7V

2616

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 534 –

11.4.3.22.5
[G UIDELINE ] If the requested range does not overlap the available content for the resource with a
URI specified in the HTTP request, the HTTP Server Endpoint shall respond with the HTTP
response code of 416 (Requested Range Not Satisfiable).

When encountering syntax errors with the Range HTTP header as defined in IETF RFC 2616, the
HTTP server shall respond using one of the following:

• sending an HTTP response code 400 (Bad Request), or

• ignoring the erroneous RANGE header
If the requested range is syntactically correct as defined in IETF RFC 2616 but does not comply with
guideline 11.4.3.22.2, the HTTP server shall respond using one of the following:

• sending an HTTP response code 400 (Bad Request), or

• ignoring the erroneous RANGE header, or
• sending an HTTP response, as defined in IETF RFC 2616.
[ATTRIBUTES ]

M F DMS +PU+ M-DMS n/a IETF RFC AAX28

2616

[C OMMENT] Ignoring the erroneous RANGE header means that the server will process the request
as if such a header were not present in the request.

IETF RFC 2616, 14.35.1 defines what constitutes a valid range request and when the request is
invalid. For example, for a file of size 500, a request for bytes 200 to 800 is valid. A request for bytes
700 to 800 is invalid. Similarly, when a resource is operating under the Limited Data Availability
model in mode “0” with an available byte range of 200-500, a request for bytes 100-400 is valid. But
a request for bytes 0-100 is invalid.

11.4.3.22.6
[G UIDELINE ] If an HTTP Server Endpoint can support HTTP requests with a specified Range for a
particular URI, then the HTTP Server Endpoint should support persistent connections (HTTP/1.1)
for that URI.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC WAAX2

2616

[C OMMENT] Content that is requested with the Range option can often get many Range requests in
a short period of time, potentially causing content serving devices to run out of available sockets.

11.4.3.22.7
[G UIDELINE ] An HTTP Server Endpoint should accept and honor an HTTP/1.0 GET or HEAD
requests for media transfers with the Range header field.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC PW38J

2616

DLNA guidelines; Part 1-1: Architecture and protocols

 – 535 –

[C OMMENT] Although the Range option is not covered in the HTTP/1.0 specification, HTTP/1.0
clients can still benefit from having the ability to issue GET requests with a specified Range.

11.4.3.22.8
[G UIDELINE ] If the Content Source does not indicate support for the Range HTTP header for a
content binary (as defined in guidelines 10.1.3.20.1 and 10.1.3.28.4), then the HTTP Client
Endpoint shall not issue HTTP GET and HEAD requests with the Range HTTP header.

[ATTRIBUTES ]

M L DMP DMR +DN+ M-DMP n/a IETF RFC A57UJ

+DNSYNC+ 2616

[C OMMENT] This prohibition includes HTTP GET and HEAD requests with Range: bytes=0-.

11.4.3.22.9
[G UIDELINE ] If the Range request is syntactically correct and the requested range is valid, and if
the HTTP Server Endpoint returns data including the requested range (Target Response), then it
shall respond to the HTTP GET request with the 206 (Partial Content) HTTP response code.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 7XZ95

2616

[C OMMENT] Comment in requirement 11.4.3.22.3 also applies to this requirement.

11.4.3.23 MT HTTP time-based seek (server)

11.4.3.23.1
[G UIDELINE ] If the Content Source indicates support for the TimeSeekRange.dlna.org HTTP
header for a content binary (as defined in guidelines 10.1.3.20.1 and 10.1.3.28.4), then the HTTP
Server Endpoint shall respond to the TimeSeekRange.dlna.org HTTP requests for that content
binary with clarifications and constraints defined in guidelines 11.4.3.23.2 to 11.4.3.23.12.

[ATTRIBUTES ]

M A DMS +PU+. M-DMS n/a IETF RFC U8UZX

2616

[C OMMENT] HTTP requests with the Range header field do not provide a very accurate experience
when seeking to playback positions in variable bitrate encoded content. This HTTP header provides
a way for DLNA HTTP clients to request an HTTP server to send the content bytes for a specified
range of time.

HTTP clients can also use seek operations to implement a forward/backward variable speed
playback capability.

11.4.3.23.2
[G UIDELINE ] The notation of the TimeSeekRange.dlna.org header field is defined as follows.

• TimeSeekRange-line = "TimeSeekRange.dlna.org" *LWS ":" *LWS range specifier

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 536 –

• range specifier = npt range [SP bytes-range]

• npt range = "npt" "=" npt-start- time "-" [ npt-end- time ] [instance-duration]
• npt-start-time = npt-time
• npt-end-time = npt-time
• instance-duration = "/" (npt-time | "*")
• npt time = <syntax as defined in 11.4.2.13>
• bytes range = "bytes" "=" first byte pos "-" last byte pos instance-length
• first byte pos = 1*DIGIT
• last byte pos = 1*DIGIT
• instance-length = "/" (1*DIGIT | "*")
Note that literals, "npt" and "bytes", are case sensitive.

The npt-range specifies the range in normal playing time as found in 3.6 of IETF RFC 2326 with the
exception of the concept of the "now" literal. It is used in the request and response.

The bytes-range specifies the range in bytes and it is used only in the response. Refer to
11.4.3.23.4.

The instance-duration specifies the duration of an entire content binary and is mandatory in the
response and prohibited in the request. The asterisk "*" character indicates that the
instance-duration is unknown at the time the response is generated. Refer to 11.4.3.23.6 for more
information.

The instance-length specifies the byte length of an entire content binary and bytes-range shall
include instance-length in the response. The asterisk "*" character indicates that the
instance-length is unknown at the time the response is generated. Refer to 11.4.3.23.4 for more
information.

Examples:

• TimeSeekRange.dlna.org: npt=335.11-336.08
• TimeSeekRange.dlna.org: npt=00:05:35.3-00:05: 37.5
Specifying the range value in the combination of npt-sec and npt-hhmmss, e.g. 335.11-00:05:37.5,
is allowed, but not recommended.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC S2RRM
2616
IETF RFC
2326

[C OMMENT] The field value specifies the requested range of a resource in absolute time. The range
is specified by the start point and the endpoint. When both points are specified, the range value
adopts the form:

TimeSeekRange.dlna.org: npt=time1-time2
The first value (time1) defines the start time, while the second value (time 2) defines the end
time.
In forward scan mode (positive play-speed values): time1 <= time2 (as defined in 11.4.3.23.10).

DLNA guidelines; Part 1-1: Architecture and protocols

 – 537 –

In backward scan mode (negative play-speed values): time1 >= time2 (as defined in
11.4.3.23.10).
The end time can be omitted resulting in a expression of the form:
TimeSeekRange.dlna.org: npt=time1-
If the end time is omitted in forward scan mode, it means the end of the resource is specified. If the
end time is omitted in backward scan mode, it means the beginning of the resource is specified.

11.4.3.23.3
[G UIDELINE ] If an HTTP Server Endpoint returns data in forward scan mode including the
requested time range (Target Response), then it shall return the content bytes for a time-range that
starts at or before the requested start time and ends at or after the requested end time.

If an HTTP Server Endpoint returns data in backward scan mode including the requested time-range
(Target Response), then it shall return the content bytes for a time-range that starts at or after the
requested start time and ends at or before the requested end time.

The following exceptions are allowed for the Full Random Access Data Availability model.

• In forward scan mode an HTTP Server Endpoint may ignore the requested end time and return
the range data up to the end of the content data.
• In backward scan mode an HTTP Server Endpoint may ignore the requested end time and return
the range data up to the beginning of the content data.
The following exceptions are allowed for the Limited Random Access Data Availability model when
the mode-flag is 0.

• In forward scan mode an HTTP Server Endpoint may ignore the requested start time if it
precedes the available seek range and return the range data from the start of the available
content data.
• In backward scan mode an HTTP Server Endpoint may ignore the requested end time if it
precedes the available seek range and return the range data up to the start of the available
content data.
The following exception is allowed for both the Full Random Access Data Availability model and the
Limited Random Access Data Availability model.

• HTTP Server Endpoint may round up or down to one decimal place, the npt time values specified
in the HTTP response TimeSeekRange.dlna.org, compared to the actual returned data in the
response body.
Examples

• TimeSeekRange.dlna.org: npt=335.1-336.1/40445.4
• TimeSeekRange.dlna.org: npt=00:05:35.2-00:05:38.1/*
In forward scan mode, if the requesting endpoint specifies an end time beyond the end of the
content data, then the HTTP Server Endpoint shall return the range data to the end of the content
data.

In backward scan mode, if the requesting endpoint specifies a start time beyond the end of the
content data, then the HTTP Server Endpoint shall return the range data to the end of the content
data.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 538 –

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 57UJY C

2616

[C OMMENT] This guideline obliges an HTTP server to respond with a time range (of bytes) that is
close to the time range specified in the request.

11.4.3.23.4
[G UIDELINE ] If an HTTP Server Endpoint supports both byte-based seek and time-based-seek
operations for a resource, then in addition to an npt-range value the byte range corresponding with
the npt time range and the byte length of an entire content binary shall be provided in the
bytes-range value of the HTTP Target Response to the HTTP request with the
TimeSeekRange.dlna.org header field, unless one of the following exceptions apply.

Exceptions

• The data access model is the Limited Random Access Data Availability model and the mode-flag
(as indicated in availableSeekRange.dlna.org) is “1”.
• The HTTP request includes a valid PlaySpeed.dlna.org header.
• The Media Format Profile corresponding to the requested resource requires a modified form of
the content binary in a time-seek response (e.g. MP4 container-based media profiles).
Examples

• TimeSeekRange.dlna.org: npt=335.1-336.1/40445.4
bytes=1539686400-1540210688/304857907200
• TimeSeekRange.dlna.org: npt=00:05:35.2-00:05:38.1/* bytes=1539686400-1540210688/*
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 7UJYL C

2616

[C OMMENT] The time-based-seek capability is useful for seeking to playback positions in variable
bit rate encoded content; but it is not useful to retrieve subsequent data blocks. For Trick Mode
playback after an initial time-based-seek, use of multiple HTTP GET requests with the Range
header field to retrieve subsequent content data is encouraged. To support this functionality, byte
range value is also specified in addition to time range value for the response to a time-based-seek
only when byte-seek is also supported for the resource.

This functionality requires an HTTP server (that supports both TimeSeekRange.dlna.org and Range)
to specify both the time-range and a byte-range in the HTTP response's headers.

11.4.3.23.5
[G UIDELINE ] If an HTTP Server Endpoint returns data (Target Response) from a GET request with
time range, then the response entity body data should start at a decoder friendly point (for example
the start of the GOP in a video sequence).

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC ES2RR

2616

[C OMMENT] This guideline recommends that stream segments returned by servers start, if possible,
DLNA guidelines; Part 1-1: Architecture and protocols
 – 539 –

with a recognizable decoding entry point, such as the headers in a group of pictures (GOP) in
MPEG-2.

11.4.3.23.6
[G UIDELINE ] If an HTTP Server Endpoint returns data including the requested time range (Target
Response) with the HTTP response code 200 (OK), then it shall specify the
TimeSeekRange.dlna.org header field to indicate the time range of the content data that is returned
in the HTTP response.

The npt-range shall include the instance-duration.

Examples

• TimeSeekRange.dlna.org: npt=335.10-336.10/40445.4
• TimeSeekRange.dlna.org: npt=00:05:35.3-00:05: 37.5/*
• For a response in backward scan mode: TimeSeekRange.dlna.org: npt=897.5-241.5/3966.3
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC YC9LA

2616

[C OMMENT] These guidelines oblige an HTTP server to respond with either a 200 response code
(for a time range request that can be honored) or a 416 response code (for time range requests that
cannot be honored). The guideline simplifies HTTP client implementations as it makes limits the
behavior of the HTTP server more predictable.

11.4.3.23.7
[G UIDELINE ] If the requested time range is not valid for the resource with URI specified in the HTTP
GET request, then the HTTP streaming server shall respond with the HTTP response error code of
416 (Requested Range Not Satisfiable).

Interpretation of not valid includes the following types of errors.

• The requested time range does not overlapthe time boundaries of the actual content.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 9LACX

2616

[C OMMENT] The HTTP server indicates support for the TimeSeekRange.dlna.org header in the
DLNA.ORG_OP parameter in guideline 10.1.3.20.1. IETF RFC 2616 reserves the definition for error
416 (Requested Range Not Satisfiable) to cases where none of the range request values overlap
the current extent of the content. This requirement clarifies the IETF RFC 2616 definition of this
error for time range requests.

11.4.3.23.8
[G UIDELINE ] If the requested time range is not syntactically correct, then the HTTP streaming
server shall return the HTTP response error code of 400 (Bad Request).

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC YV45Z

2616

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 540 –

11.4.3.23.9
[G UIDELINE ] If the Content Source does not indicate support for the TimeSeekRange.dlna.org
HTTP header for a content binary (as defined in guidelines 10.1.3.20.1 and 10.1.3.28.4), then the
HTTP Client Endpoint shall not issue HTTP GET and HEAD requests with the
TimeSeekRange.dlna.org HTTP header.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC 8V5NG

2616

11.4.3.23.10
[G UIDELINE ] In forward scan mode (positive play-speed values) the start time in the range defined
by the TimeSeekRange.dlna.org header shall be smaller than or equal to the end time.

In backward scan mode (negative play-speed values) the start time in the range defined by the
TimeSeekRange.dlna.org header shall be larger than or equal to the end time.

Non-compliance with these requirements results in a syntax error in the TimeSeekRange.dlna.org

header. See guideline 11.4.3.23.8 for behavior in the presence of a syntactically wrong
TimeSeekRange.dlna.org header.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a ENIDK

11.4.3.23.11
[G UIDELINE ] If the TimeSeekRange.dlna.org request is syntactically correct and the requested
time range is valid, and if the HTTP Server Endpoint returns data including the requested time range
(Target Response) then it shall respond to the HTTP GET request with the 200 (OK) HTTP response
code.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC WS9TZ

2616

11.4.3.23.12
[G UIDELINE ] If an HTTP Content Source returns data (Target Response) from a GET request with
time range, then the response entity body data shall be compliant with the Media Format Profile
indicated in the corresponding <res> element

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC X8GZD N

2616

[C OMMENT] This guideline requires an HTTP Content Source to respond to a

TimeSeekRange.dlna.org request with data that is compliant with the profile associated with the
resource being requested. This may require the Content Source to add headers and other metadata
not present in the raw content binary necessary for the client to properly process the response data.

11.4.3.24 MT HTTP Chunked Transfer Coding

11.4.3.24.1
[G UIDELINE ] HTTP Servers Endpoints may use Chunked Transfer Coding in response to HTTP/1.1
GET requests.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 541 –

[ATTRIBUTES ]

O R DMS +PU+ M-DMS n/a IETF RFC 58V5N

2616

[C OMMENT] Chunked Transfer Coding is an HTTP response encoding methodology that can only
be used in response to HTTP/1.1 requests by HTTP/1.1 servers.

11.4.3.24.2
[G UIDELINE ] HTTP Server Endpoints shall not use Chunked Transfer Coding in response to
HTTP/1.0 GET requests.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC 3KYV4

2616

11.4.3.24.3
[G UIDELINE ] HTTP Client Endpoints may use Chunked Transfer Coding in HTTP/1.1 POST
requests.

[ATTRIBUTES ]

O R +UP+ +UPSYNC+ n/a n/a IETF RFC XJSB3

2616

11.4.3.25 MT baseline transport: HTTP Client Endpoints

11.4.3.25.1
[G UIDELINE ] HTTP Client Endpoints used for Media Transport purposes shall implement HTTP/1.0,
HTTP/1.1, or both.

[ATTRIBUTES ]

M L DMP DMR +DN+ M-DMP n/a IETF RFC KYV45

+DNSYNC+ 2616

[C OMMENT] HTTP client endpoints are restricted to HTTP versions that HTTP server endpoints are
prepared to support.

11.4.3.25.2
[G UIDELINE ] HTTP Client Endpoints shall not report a higher version of HTTP than is actually
supported by the implementation.

[ATTRIBUTES ]

M R DMP DMR +DN+ M-DMP n/a IETF RFC TF57C

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] For example an HTTP client endpoint that does not support Chunked Transfer Coding
responses will never issue an HTTP/1.1 GET request.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 542 –

11.4.3.25.3
[G UIDELINE ] HTTP/1.1 Client endpoints shall be able to process HTTP/1.1 Chunked Transfer
Coding responses.

[ATTRIBUTES ]

M R DMP DMR +DN+ M-DMP n/a IETF RFC GAA77

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] When making HTTP/1.1 requests, it is important that HTTP client endpoints properly
handle responses encoded with Chunked Transfer Coding.

11.4.3.25.4
[G UIDELINE ] HTTP/1.1 Client Endpoints shall be prepared to properly handle an HTTP response
code of 1xx from HTTP servers, even when not expected.

[ATTRIBUTES ]

M R DMP DMR +DN+ M-DMP n/a IETF RFC 3TF57

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] A 1xx can be generated by the server regardless of whether or not the client issued an
HTTP request encoded with Chunked Transfer Coding.

See 10.1 of IETF RFC 2616 for more information.

11.4.3.26 MT HTTP header: range (client)

[G UIDELINE ] HTTP Client Endpoints shall not use multiple range specifiers nor use suffix byte
range spec (as defined in IETF RFC 2616) in HTTP requests.

[ATTRIBUTES ]

M L DMP DMR +DN+ M-DMP n/a IETF RFC B3TF5

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] This guideline simplifies the implementation of HTTP servers by not requiring support
of multiple ranges or suffix byte range specification.

11.4.3.27 MT HTTP persistent connection usage for clients

[G UIDELINE ] HTTP/1.1 Client Endpoints should use HTTP/1.1 persistent connections.

[ATTRIBUTES ]

S R DMP DMR +DN+ M-DMP n/a IETF RFC 45Z8H

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] Implementing this guideline reduces the setup/teardown load on HTTP Server
Endpoints. Furthermore, HTTP Server Endpoints will be able to reserve the allocated socket for the
requesting client. Clients that do not use HTTP/1.1 persistent connections can encounter a scenario
where an HTTP Server Endpoint does not answer the subsequent requests because it has run out
of sockets.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 543 –

11.4.3.28 MT HTTP inactivity timeout

11.4.3.28.1
[G UIDELINE ] HTTP Client Endpoints should close persistent (HTTP/1.1) connections after
completing all outstanding HTTP transactions and within 30 s of inactivity has passed.

[ATTRIBUTES ]

S A DMP DMR +DN+ M-DMP n/a IETF RFC V45Z8

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] This ensures that sockets do not remain consumed after a content transfer has
successfully completed.

11.4.3.28.2
[G UIDELINE ] If an HTTP server detects 5 min of inactivity after a POST transaction, then the HTTP
server should close persistent (HTTP/1.1) connections.

[ATTRIBUTES ]

S A DMS M-DMS n/a IETF RFC NGAA7

2616

[C OMMENT] This ensures that sockets do not remain consumed by an Upload Controller.

11.4.3.29 MT HTTP header parsing (client)

[G UIDELINE ] HTTP Client Endpoints shall gracefully skip over unsupported HTTP header fields.
Under no circumstances can an HTTP client fail to process a properly formatted HTTP response
because of an unrecognized or unsupported HTTP header field.

[ATTRIBUTES ]

M R DMP DMR +DN+ M-DMP n/a IETF RFC 5NGAA

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] Incorrect HTTP header parsing has been the source of numerous compatibility issues
during plugfest events.

11.4.3.30 MT HTTP maximum header size

[G UIDELINE ] HTTP Client and Server Endpoints shall use a total HTTP header size that is less than
or equal to 8 192 B (8 KiB) when sending an HTTP request or HTTP response.

The total HTTP header size is the total number of bytes from the first byte in the start-line token and
the last byte of the CRLF token, as used in the generic-message token defined in 4.1 of IETF RFC
2616, as quoted in the syntax below.

• generic-message = start-line *(message-header CRLF) CRLF [ message-body ]

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC CX7UF
+DN+ +UP+ 2616
+DNSYNC+
+UPSYNC+
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 544 –

[C OMMENT] This provides a reasonable assumption as to how much memory is necessary is for all
HTTP headers in an HTTP request or response.

If determined to be necessary, future DLNA guidelines can define a parameter in the USER-AGENT
to indicate a DLNA version for governing total HTTP header sizes.

11.4.3.31 MT HTTP status code precedence

[G UIDELINE ] If a DLNA guideline specifies an HTTP status code that involves a DLNA defined
HTTP header, then the DLNA guideline's HTTP status code shall take precedence over those
specified in IETF RFC 2616.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC ACX7U

2616

[C OMMENT] As a general rule, HTTP status codes for DLNA defined HTTP headers take
precedence over HTTP status codes. For standard HTTP headers, IETF RFC 2616 status codes
apply. For HTTP responses that involve DLNA defined HTTP headers, the DLNA specified status
code applies when there exists an ambiguity between using a DLNA-specified error code and an
error code made by IETF RFC 2616. Whenever possible, DLNA guidelines align with IETF RFC
2616.

11.4.3.32 MT transfer mode indication

11.4.3.32.1
[G UIDELINE ] The syntax for the transferMode.dlna.org HTTP header value is as follows.

• transferMode-line= "transferMode.dlna.org" *LWS ":" *LWS mode

• mode = "Streaming" | "Interactive" | "Background"
A value of "Background" for an HTTP request indicates that the HTTP client would like the transfer
of content to be a Background Transfer.

A value of "Interactive" for an HTTP request indicates that the HTTP client is requesting an
Interactive Transfer.

A value of "Streaming" for an HTTP request indicates that the HTTP client wishes a Streaming
Transfer of the content.

A value of "Background" for an HTTP response indicates that the HTTP server is attempting a
Background Transfer of the content.

A value of "Interactive" for an HTTP response indicates that the HTTP server is attempting an
Interactive Transfer of the content.

A value of "Streaming" for an HTTP response indicates that the HTTP server is attempting a
Streaming Transfer of the content.

Note that the mode token values ("Streaming", "Interactive", and "Background") are case sensitive
values.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 545 –

Example

• transferMode.dlna.org: Interactive
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC LACX7
+DN+ +UP+ 2616
+DNSYNC+
+UPSYNC+

[C OMMENT] This header carries the transfer mode as listed in the introduction.

11.4.3.32.2
[G UIDELINE ] An HTTP server that receives an HTTP request from an HTTP client of a DLNA
endpoint that omits the transferMode.dlna.org header shall treat it as equivalent to the header-value
pair of transferMode.dlna.org:Streaming for content binaries of the AV or Audio Media Classes or
transferMode.dlna.org:Interactive for all other content binaries.

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC RRM6T

2616

[C OMMENT] HTTP transfers that do not include this header are treated as Streaming Transfers for
AV or Audio Media Classes and as Interactive Transfers for all other content binaries.

11.4.3.32.3
[G UIDELINE ] The transferMode.dlna.org header may be used by HTTP clients and servers in
requests and responses. The transferMode.dlna.org header is used to convey the transfer mode
information as specified in guideline 11.4.2.3.

[ATTRIBUTES ]

O C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC YL6RN
+DN+ +UP+ 2616
+UPSYNC+
+DNSYNC+

[C OMMENT] This guideline clarifies the use of the transferMode.dlna.org, according to guideline
11.4.2.3.

11.4.3.32.4
[G UIDELINE ] If an HTTP Client Endpoint requests a transfer mode that is not valid for the Media
Class of data that is being exchanged or is not supported by an HTTP Server Endpoint for the given
content binary, the HTTP Server Endpoint shall respond with error code 406 (Not Acceptable).

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 2RRM6

2616

[C OMMENT] The list of transfer modes for the given Media Class is given in guideline 11.4.2.3.1.
However, a server might restrict the list further if the content warrants it. For example, for live
captured content, Background Transfer might not be available. For details on the Media Transfer
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 546 –

Modes that are available for a particular content binary within a DMS structure, see guideline
10.1.3.24.2.

11.4.3.32.5
[G UIDELINE ] All DLNA endpoints communicating with a v1.0 DMS shall tolerate HTTP responses
that omit the transferMode.dlna.org HTTP header.

Tolerate means that the HTTP client shall "parse and ignore" or "parse and interpret" the HTTP
response.

(That is, all DLNA endpoints communicating with a v1.0 DMS shall assume that the media will be
returned without the transferMode.dlna.org HTTP header and using a best effort QoS level.)

[ATTRIBUTES ]

M C DMP DMR +DN+ M-DMP n/a IETF RFC RM6TQ

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] All v1.0 DMS media transfers were assumed to be for immediate rendering and at a
default best effort QoS level. A v1.5 entity communicating with a v1.0 DMS needs to allow any media
transfer to have these parameters.

11.4.3.33 MT caching directives for HTTP 1.0

11.4.3.33.1
[G UIDELINE ] If applicable-http-endpoints want to modify the default caching behavior of
intermediate HTTP caches, they shall do so in a manner compliant with IETF RFC 1945.

Applicable-http-endpoints specifically refers to HTTP Server and Client Endpoints participating in

transfer operations of cacheable content using

• HTTP/1.0, and
• GET requests and responses.
This definition of applicable-http-endpoints is valid only for this guideline.

[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC JYL6R
+DN+ +UP+ 1945
+DNSYNC+
+UPSYNC+

[C OMMENT] Per HTTP/1.0 specifications, intermediate caching operations are allowed by default
when content is transferred using the GET method.

11.4.3.33.2
[G UIDELINE ] If an HTTP Server Endpoint transfers non-cacheable content using HTTP/1.0 GET
responses, then the HTTP Server Endpoint shall prevent intermediate caching by including this
directive amongst the HTTP headers in the response.

• Pragma: no-cache

DLNA guidelines; Part 1-1: Architecture and protocols

 – 547 –

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC J7V9I

1945

[C OMMENT] Non-cacheable content includes the following:

• live content and other forms of broadcast streams;

• content data that includes the TimeSeekRange.dlna.org or PlaySpeed.dlna.org HTTP headers;
• content binaries that are dynamically generated in such a way that the content binary streams
can differ on 2 different transactions (e.g. smart transcoding engines that perform transrating
based on network throughput).
11.4.3.33.3
[G UIDELINE ] If HTTP Server Endpoints transfer Audio or AV content binaries and the response
includes one or both of listed HTTP headers, then the responses shall prevent caching, per
guidelines 11.4.3.34.1 and 11.4.3.34.2.

• TimeSeekRange.dlna.org
• PlaySpeed.dlna.org
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a UJYL6

[C OMMENT] In HTTP 1.0 no method exists to signal the different bit stream variations that result
from the use of Time Seek and play-speed operations. For this reason, intermediate caching
operations have to be avoided.

11.4.3.34 MT caching directives for HTTP 1.1

11.4.3.34.1
[G UIDELINE ] If applicable-http-endpoints want to modify the default caching behavior of
intermediate HTTP caches, they shall do so in a manner compliant with IETF RFC 2616.

Applicable-http-endpoints specifically refers to HTTP Server and Client Endpoints participating in

transfer operations of cacheable content using the following:

• HTTP/1.1, and
• GET requests and responses.
This definition of applicable-http-endpoints is valid only for this guideline.

[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC XTY7C
+DN+ +UP+ 2616
+DNSYNC+
+UPSYNC+

[C OMMENT] Per HTTP/1.1 specifications, intermediate caching operations are allowed by default
when content is transferred using the GET method.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 548 –

11.4.3.34.2
[G UIDELINE ] HTTP Server Endpoints that transfer non-cacheable content using HTTP/1.1 GET
responses shall prevent intermediate caching by including among the HTTP response headers both
of the following directives.

• Pragma: no-cache
• Cache-control: no-cache
[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC ZXTY7

2616

11.4.3.34.3
[G UIDELINE ] If an HTTP Server Endpoint transfers Audio or AV content binaries using HTTP/1.1
GET responses that include one or both of these HTTP headers, then such transfers should be
marked as cacheable.

• TimeSeekRange.dlna.org
• PlaySpeed.dlna.org
[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a X28MG

[C OMMENT] Unlike HTTP/1.0, the newer version HTTP/1.1 includes caching directives that, when
used, enable transparent caching even when the transferred objects include headers that modify
the object's binary representation. In DLNA, Time Seek and play-speed headers modify the binary
representation of the object that is transferred using the HTTP protocol. The "Vary" header
described below can be used to restore transparent caching for these objects.

11.4.3.34.4
[G UIDELINE ] If an HTTP Server Endpoint transfers Audio or AV content binaries that permit
variable play-speed and time-based seek operations for cacheable content transported in an
HTTP/1.1 GET response, then the HTTP Server Endpoint shall include a "Vary" HTTP header as
defined in IETF RFC 2616.

The "Vary" header shall list either or both of the following two arguments to inform caches of the
corresponding supported operations:

• TimeSeekRange.dlna.org
• PlaySpeed.dlna.org
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC UZXTY

2616

[C OMMENT] The “Vary” header serves to indicate potential intermediate caches that certain
headers create variants of the object binaries defined by its URI. For example, a 30 min media
stream requested in full is a different object variant when only the first 3 min of the stream are
requested using Time Seek operations.

Per IETF RFC 2616 the “Vary” header has to be included whenever the server responds to a client
request for the CDS object. The “Vary” header has to be included even if the request does not
include Time Seek or play-speed headers.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 549 –

11.4.3.34.5
[G UIDELINE ] If applicable-http-endpoints want to supersede the default caching prohibition for
POST transfers, they shall do so in a manner compliant with IETF RFC 2616.

Applicable-http-endpoints specifically refers to HTTP Server and Client Endpoints participating in

upload transaction using

• HTTP/1.1 and
• POST requests and responses.
[ATTRIBUTES ]

M C DMS +UP+ M-DMS n/a IETF RFC 8J7V9

+UPSYNC+ 2616

[C OMMENT] Per HTTP/1.1 specifications, intermediate caching operations are prohibited by

default when content is transferred using the POST method.

11.4.3.35 MT/BCM HTTP header:peerManager.dlna.org

11.4.3.35.1
[G UIDELINE ] HTTP Client Endpoints may use the peerManager.dlna.org HTTP header to
communicate the identity of the UPnP AV ConnectionManager service to the Content Source
Endpoint in HTTP GET requests.

[ATTRIBUTES ]

O A DMR n/a n/a IETF RFC AX28M

2616

[C OMMENT] The peerManager.dlna.org HTTP Header is not required. However, this feature is
useful for HTTP Clients that want to facilitate BCM on DMS with BCM support.

11.4.3.35.2
[G UIDELINE ] The value of the peerManager.dlna.org HTTP header shall be the same value as the
PeerConnectionManager, as described in the UPnP AV Architecture.

The notation of the peerManager.dlna.org HTTP header field is defined as follows:

• peerManager-line = "peerManager.dlna.org" *LWS ":" *LWS peer-connection-manager

• peer-connection-manager = udn-token "/" serviceId-token
• udn-token = <case-insensitive UDN of the UPnP AV MediaRenderer device>
• serviceId-token = <case-sensitive ServiceID of the ConnectionManager service, associated with
the MediaRenderer device identified by udn-token>
Example

• peerManager.dlna.org:
uuid:12345678123456781234567812345678/urn:schemas-upnp-org:serviceId:ConnectionMan
ager
[ATTRIBUTES ]

M A DMR n/a n/a IETF RFC 7V9I4

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 550 –

2616

11.4.3.36 MT/BCM HTTP header:friendlyName.dlna.org

11.4.3.36.1
[G UIDELINE ] HTTP Client Endpoints may use the friendlyName.dlna.org HTTP header to
communicate a user-friendly name to the Content Source Endpoint in HTTP GET requests.

[ATTRIBUTES ]

O A DMP +UP+ +DN+ n/a n/a IETF RFC H53W5

+DNSYNC+ 2616
+UPSYNC+

[C OMMENT] The friendlyName.dlna.org HTTP Header is not required. However, this feature is
useful for HTTP Clients that want to facilitate BCM on DMS with BCM support.

11.4.3.36.2
[G UIDELINE ] The notation of the friendlyName.dlna.org header field is defined as follows:

• friendlyName-line = "friendlyName.dlna.org" *LWS ":" *LWS "friendly-name-token

• friendlyName-token = <case sensitive string, limited to 128 B in its UTF-8 encoded form>
[ATTRIBUTES ]

M A DMP +UP+ +DN+ n/a n/a IETF RFC 28MG8

+DNSYNC+ 2616
+UPSYNC+

11.4.3.37 MT/BCM scid.dlna.org HTTP header

11.4.3.37.1
[G UIDELINE ] If a UPnP AV MediaServer supports BCM, then it shall use the scid.dlna.org HTTP
header in HTTP responses to identify the ConnectionID associated with the underlying transport
layer connection.

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC 3H53W

2616

11.4.3.37.2
[G UIDELINE ] The syntax of the scid.dlna.org HTTP header shall be as follows:

• scidheader = "scid.dlna.org" *LWS ":" *LWS connection-id

• connection-id = <the ConnectionID value associated with the underlying transport connection>
[ATTRIBUTES ]

M A DMS DMP DMR +UP+ M-DMS n/a IETF RFC ZXWQG

+DN+ +DNSYNC+ 2616
+UPSYNC+

11.4.3.37.3
[G UIDELINE ] HTTP Client Endpoints may use scid.dlna.org in subsequent HTTP requests to
identify a known and associated UPnP AV Connection only if the HTTP requests are for the same
URI.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 551 –

[ATTRIBUTES ]

O A DMP DMR +UP+ M-DMP n/a IETF RFC 53W5Q

+DN+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] This guideline allows Content Receivers to provide the ConnectionID in the transport
layer requests. This guideline assumes the HTTP client of the Content Receiver acquired the
ConnectionID in an earlier HTTP response. This mechanism can be used to combine logically
related, but separated transport layer requests for the same content URI.

11.4.3.38 MT streaming transferMode.dlna.org HTTP header

11.4.3.38.1
[G UIDELINE ] If an HTTP Client Endpoint requests a streaming transfer of data, then it shall specify
the transferMode.dlna.org HTTP header and the header shall have a value of "Streaming".

[ATTRIBUTES ]

M A DMP DMR +DN+ M-DMP n/a IETF RFC DU649

+DNSYNC+ 2616

[C OMMENT] Legacy clients will still request streaming transfers without using the
transferMode.dlna.org HTTP header. Guideline 11.4.3.32.2 requires that servers that receive such
a request treat it as equivalent to a request for a streaming transfer for Audio and AV Media
Classes.

11.4.3.38.2
[G UIDELINE ] Unless a streaming HTTP Server Endpoint responds with an error response code, it
shall respond to HTTP HEAD or GET requests for a streaming transfer (as defined in 11.4.3.38.1 )
by sending a response that contains the transferMode.dlna.org HTTP header and gives it a value of
"Streaming".

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 6498V

2616

11.4.3.39 MT HTTP Play media operation

[G UIDELINE ] A streaming HTTP Client Endpoint shall use the HTTP GET method when using the
HTTP transport protocol for initiating the Play media operation.

[ATTRIBUTES ]

M L DMP DMR +DN+ M-DMP n/a IETF RFC U6498

+DNSYNC+ 2616

[C OMMENT] This guideline specifies the normative way to request content.

11.4.3.40 MT HTTP Stop media operation

11.4.3.40.1
[G UIDELINE ] A streaming HTTP Client Endpoint should implement the Stop media operation by
disconnecting the TCP connection of the HTTP transaction.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 552 –

[ATTRIBUTES ]

S A +DN+ +DNSYNC+ n/a n/a IETF RFC XWQGT

2616

[C OMMENT] This guideline recommends the way to stop a media stream. Although HTTP clients
can technically stall the TCP connection, that technique is discouraged. The preferred technique
makes better use of an HTTP Server Endpoint's platform resources, which can be limited.

This guideline specifies that HTTP Client endpoints visually and/or aurally stop rendering of content,
although the continuation of data streaming from the HTTP Server Endpoint is permissible for data
buffering/caching purposes.

11.4.3.40.2
[G UIDELINE ] An audio or AV streaming HTTP Client Endpoint shall implement the Stop media
operation by disconnecting the TCP connection of the HTTP transaction.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC CWCV2

2616

[C OMMENT] This technique makes better use of an HTTP Server Enpoint’s platform resources,
which can be limited.

This guideline specifies that HTTP Client endpoints visually and/or aurally stop rendering of content,
although the continuation of data streaming from the HTTP Server Endpoint is permissible for data
buffering/caching purposes.

11.4.3.41 MT HTTP Pause/Pause-Release media operation

11.4.3.41.1
[G UIDELINE ] A streaming HTTP Client Endpoint should implement the Pause media operation by
the following method.

• Connection Stalling: Suspending the reading of data from the HTTP connection. Resuming the
reading of data from the HTTP connection is the mechanism for Pause-Release.
[ATTRIBUTES ]

S L DMP DMR M-DMP n/a IETF RFC WQGTQ

2616

11.4.3.41.2
[G UIDELINE ] If a streaming HTTP Client Endpoint performs a Pause media operation, then the
HTTP Client Endpoint shall support all of the following Pause media operation methods.

• Disconnecting and Seeking: Disconnecting the HTTP connection and using byte-base seek
transport layer features as the mechanism for Pause-Release.
• Disconnecting and Seeking: Disconnecting the HTTP connection and using time-based seek
transport layer features as the mechanism for Pause-Release.
[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC CZ794

DLNA guidelines; Part 1-1: Architecture and protocols

 – 553 –

2616

[C OMMENT] This guideline is applicable to audio Media Class and AV Media Class.

11.4.3.41.3
[G UIDELINE ] If a streaming HTTP Client Endpoint wants to pause the current media stream, it shall
first ensure that all of the necessary media operations and information are available to resume the
play (Pause-Release) of the media stream.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 498VR

2616

[C OMMENT] The ability to do a Pause-Release media operation depends on both the Content
Receiver and the Content Source sharing support for at least one of the following HTTP transport
features: byte-based seek, time-based seek, or Connection Stalling.

11.4.3.42 MT HTTP Pause/Pause-Release media operation: Disconnecting and Seeking

Method
11.4.3.42.1
[G UIDELINE ] If a streaming HTTP Client Endpoint performs a Pause media operation using the
Disconnecting and Seeking method, it shall support the Pause-Release operation by using
byte-based seek or time-based seek transport layer features. Before using this form of
Pause/Pause-Release mechanism, the streaming HTTP Client Endpoint shall verify that the
Content Source supports the necessary transport layer feature.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 3W5QP

2616

[C OMMENT] The HTTP connection can be closed for different reasons. If the connection is
disconnected, the streaming HTTP Client Endpoint can use a Seek media operation (see
11.4.3.44.1) to Pause-Release the playback.

11.4.3.42.2
[G UIDELINE ] If a streaming HTTP Client Endpoint supports the Pause media operation using the
Disconnecting and Seeking method, it should support the byte-based seek transport layer feature.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC 98VRE

2616

[C OMMENT] This guideline recommends that a Content Source supports byte-based seek, as
defined in 11.4.3.22.

11.4.3.42.3
[G UIDELINE ] If a streaming HTTP Client Endpoint supports the Pause media operation using the
Disconnecting and Seeking method, it may perform the Pause media operation by first suspending
the reading of data from the HTTP connection (as described for the Connection Stall method). When

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 554 –

the streaming HTTP Client Endpoint detects a TCP-layer disconnect, it may perform the
Pause-Release media operation using the time-based seek or byte-based seek transport layer
feature that is supported by the Content Source.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a IETF RFC W5QPO

2616

[C OMMENT] Using TCP flow control to stall/pause the flow of data can enable quick Pause-Release
behavior. Content Sources are recommended to support the Connection Stalling method, in
addition to byte-based seek or time-based seek transport layer features.

11.4.3.43 MT HTTP Pause/Pause-Release media operation: Connection Stalling method

11.4.3.43.1
[G UIDELINE ] If a streaming HTTP Client Endpoint performs a Pause media operation using the
Connection Stalling method it shall verify the http-stalling parameter in the 4th field of the
res@protocolInfo is present and set to true for a content binary.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 8MG85

2616

[C OMMENT] A Pause media operation initiated by the Connection Stalling method does not require
the use of time-based seek or byte-based seek since the Content Source maintains the TCP
connection, using standard TCP flow control. Content Sources can choose to support only the
Connection Stalling method for some content binaries, such as those created by dynamic, real-time
transcoding.

11.4.3.43.2
[G UIDELINE ] When the HTTP connection is lost for any reason, the streaming HTTP Client
Endpoint may attempt to use time-based seek or byte-based seek transport layer features to
Pause-Release the media stream.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a IETF RFC MG857

2616

[C OMMENT] This guideline assumes that both the Content Receiver and Content Source support
the same transport layer features.

11.4.3.43.3
[G UIDELINE ] If the http-stalling flag is true for a content binary, then the streaming HTTP Server
Endpoint shall allow Connection Stalling for an indefinite amount of time on that content binary.

Equivalently, streaming HTTP Server Endpoints that support the Connection Stalling method for a
content binary shall be able to maintain the HTTP connection and shall not use an HTTP connection
inactivity timeout to terminate the HTTP connection.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC V9I4U

2616

DLNA guidelines; Part 1-1: Architecture and protocols

 – 555 –

[C OMMENT] This guideline prohibits using an HTTP-inactivity timeout to terminate HTTP

connections that are being paused through Connection Stalling.

The guideline permits the streaming HTTP Server Endpoint to terminate HTTP connections for the
following scenarios:

• when the Content Receiver terminates the HTTP connection;

• the underlying TCP transport session is broken or disconnected;
• system events on the streaming HTTP Server Endpoint (user-initiated termination of streams,
scheduled recording events, configurable policies for idle connections, etc.).
Although this guideline requires a streaming HTTP Server Endpoint to allow Connection Stalling for
an indefinite period of time, a streaming HTTP Server Endpoint can provide users with the ability to
terminate the HTTP connections. Many details in this area are out of scope, but this guideline
accounts for the following types of possibilities:

• a local UI, associated with the Content Source, allows the user to manually terminate the HTTP
connections;
• the Content Source has user-configurable policies that can overrule the default behavior of
indefinite connection stalling by terminating HTTP connections that have been inactive for a
lengthy time. These guidelines do not define a minimum time but the suggested minimum HTTP
inactivity timeout is 5 min;
• UPnP AV MediaServer control points invoke CMS (ConnectionComplete to terminate
connections).
11.4.3.43.4
[G UIDELINE ] If the http-stalling flag is true for a content binary, then the streaming HTTP Server
Endpoint shall not change encoding rate based on the HTTP throughput.

[ATTRIBUTES ]

M A DMS +PU+ M_DMS n/a IETF RFC OBPDK

2616

[C OMMENT] If a Rendering Endpoint has already opened a normal (1x) GET request, then it does
not need to inform the server of the slow-motion playback since the Rendering Endpoint could
simply consume the data more slowly. This is similar to the connection stalling approach to
pause/resume, except that the client does not completely pause, it continues to consume and
decode the content, but configures its decoder to do so at a slower rate. If the server supports
stalling, then this is indistinguishable on the server side from a client that is doing pause/resume.

11.4.3.43.5
[G UIDELINE ] If the http-stalling flag is true for a content binary, then the streaming HTTP Server
Endpoint shall allow streaming at rates slower than real-time, while in streaming transfer mode, to
support a Slow Forward Scan media operation using Connection Stalling to accommodate slower
decode and display of the streamed content.

[ATTRIBUTES ]

M A DMS +PU+ M_DMS n/a IETF RFC Q5ABD

2616

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 556 –

11.4.3.44 MT HTTP Seek media operation

11.4.3.44.1
[G UIDELINE ] An HTTP Client Endpoint should implement the Seek media operation by using the
Range header fields, if those header fields are supported by the HTTP Server for the content binary.

[ATTRIBUTES ]

S A +DN+ +DNSYNC+ n/a n/a IETF RFC 9I4UN

2616

[C OMMENT] This guideline recommends two ways to implement the seek operation on content. The
method used by the client is conditional on whether or not the HTTP server supports the capability
for that content.

See guideline 10.1.3.19 and 10.1.3.28.4 for information on discovering server seek capabilities.

See 11.4.3.22 guidelines for more information on Range header fields.

11.4.3.44.2
[G UIDELINE ] For every content binary not using DLNA Link Protection, if a streaming HTTP Client
Endpoint performs a Seek media operation, then the HTTP Client Endpoint shall support all of the
following Seek media operation methods:

• the Range header field;

• the TimeSeekRange.dlna.org header field.
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC PHT47

2616

[C OMMENT] This guideline is applicable to Audio Media Class and AV Media Class.

11.4.3.45 MT HTTP Fast Forward Scan media operation

11.4.3.45.1
[G UIDELINE ] If an audio streaming HTTP Client Endpoint wants to perform a Fast Forward Scan
media operation (positive play-speed greater than 1x), then it should use one of these methods,
provided that the given header fields are supported by the server.

• Issuing multiple HTTP GET requests with a specified Range header field.
• Issuing multiple HTTP GET requests with a specified TimeSeekRange.dlna.org header field.
• Issuing a single HTTP GET request with a specified PlaySpeed.dlna.org header field.
[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC TY7CW

2616

[C OMMENT] Forward Scan and backward Scan operations fall into a category of playback
capabilities referred to as trick modes. These guidelines specify three general techniques for
implementing trick modes:

DLNA guidelines; Part 1-1: Architecture and protocols

 – 557 –

• The first technique is to issue multiple HTTP requests with specified byte ranges, such that the
byte data can be rendered sequentially, giving the effect of a trick mode playback. With this
technique, the HTTP Client endpoint is responsible for specifying the appropriate byte ranges
that will achieve the desired effect.
• The second technique is a variant of the first, and it works by requesting the HTTP server to
return time ranges (instead of byte ranges). In this technique, the HTTP Client endpoint is
responsible for choosing the appropriate time ranges that achieve the desired effect.
• The third technique works by having the HTTP Client endpoint instruct the HTTP Server
Endpoint to return byte data that is already time scaled for a particular play-speed.
See 11.4.3.22, 11.4.3.23, and 11.4.3.53 guidelines for more information on Range,
TimeSeekRange.dlna.org, and PlaySpeed.dlna.org header fields.

11.4.3.45.2
[G UIDELINE ] For every AV content binary not using DLNA Link Protection, if a streaming HTTP
Client Endpoint performs a Fast Forward Scan media operation (positive play-speed greater than
1x), then the HTTP Client Endpoint shall support all of the following methods.

• Issuing multiple HTTP GET requests with a specified Range header field.
• Issuing multiple HTTP GET requests with a specified TimeSeekRange.dlna.org header field.
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC T24LR

2616

11.4.3.45.3
[G UIDELINE ] For every AV content binary not using DLNA Link Protection, if a streaming HTTP
Client Endpoint performs a Fast Forward Scan media operation (positive play-speed greater than
1x), then the HTTP Client Endpoint should support the following method.

• Issuing a single HTTP GET request with a specified PlaySpeed.dlna.org header field.
[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC TYB9P

2616

11.4.3.46 MT HTTP Streaming Slow Forward Scan media operation

11.4.3.46.1
[G UIDELINE ] If an audio streaming HTTP Client Endpoint wants to perform a Slow Forward Scan
media operation (positive play-speed less than 1x), then it should use one of these methods:

• issuing multiple HTTP GET requests with a specified Range header field;
• issuing a single HTTP GET request with a specified PlaySpeed.dlna.org header field.
[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC L6RNZ

2616

11.4.3.46.2
[G UIDELINE ] For every AV content binary not using DLNA Link Protection, if a streaming HTTP
Client Endpoint performs a Slow Forward Scan media operation (positive play-speed less than 1x),
then the HTTP Client Endpoint shall support all of the following methods:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 558 –

• issuing multiple HTTP GET requests with a specified Range header field;
• issuing a single HTTP GET request and subsequently using Connection Stalling Method (see
11.4.3.43) to accommodate slower decode and display of the streamed content.
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC Z9BD2

2616

11.4.3.46.3
[G UIDELINE ] For every AV content binary not using DLNA Link Protection, if a streaming HTTP
Client Endpoint performs a Slow Forward Scan media operation (positive play-speed less than 1x),
then the HTTP Client Endpoint should support the following method:

• issuing a single HTTP GET request with a specified PlaySpeed.dlna.org header field.
[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC 3W8KS

2616

11.4.3.47 MT HTTP Streaming Fast Backward Scan media operation

11.4.3.47.1
[G UIDELINE ] If an audio streaming HTTP Client Endpoint wants to perform a Fast Backward Scan
operation (negative play-speed less than −1x), then it should use one of these methods:

• issuing multiple HTTP GET requests with a specified Range header field;
• issuing multiple HTTP GET requests with a specified TimeSeekRange.dlna.org header field;
• issuing a single HTTP GET request with a specified PlaySpeed.dlna.org header field.
[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC Y7CWO

2616

11.4.3.47.2
[G UIDELINE ] For every AV content binary not using DLNA Link Protection, if a streaming HTTP
Client Endpoint performs a Fast Backward Scan media operation (negative play-speed less than
−1x), then the HTTP Client Endpoint shall support all of the following methods:

• issuing multiple HTTP GET requests with a specified Range header field;
• issuing multiple HTTP GET requests with a specified TimeSeekRange.dlna.org header field.
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC V46LS

2616

11.4.3.47.3
[G UIDELINE ] For every AV content binary not using DLNA Link Protection, if a streaming HTTP
Client Endpoint performs a Fast Backward Scan media operation (negative play-speed less than
−1x), then the HTTP Client Endpoint should support the following method:

• issuing a single HTTP GET request with a specified PlaySpeed.dlna.org header field.
[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC ZHSFA

DLNA guidelines; Part 1-1: Architecture and protocols

 – 559 –

2616

11.4.3.48 MT HTTP Streaming Slow Backward Scan media operation

11.4.3.48.1
[G UIDELINE ] If an audio streaming HTTP Client Endpoint wants to perform a Slow Backward Scan
media operation (negative play-speed greater than or equal to −1x), then it should use one of these
methods:

• issuing multiple HTTP GET requests with a specified Range header field; or
• issuing a single HTTP GET request with a specified PlaySpeed.dlna.org header field.
[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC 6RNZ6

2616

11.4.3.48.2
[G UIDELINE ] For every AV content binary not using DLNA Link Protection, if a streaming HTTP
Client Endpoint performs a Slow Backward Scan media operation (negative play-speed less than
zero and greater than or equal to −1x), then the HTTP Client Endpoint shall support the following
methods:

• issuing multiple HTTP GET requests with a specified Range header field.
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC A89O5

2616

11.4.3.48.3
[G UIDELINE ] For every AV content binary not using DLNA Link Protection, if a streaming HTTP
Client Endpoint performs a Slow Backward Scan media operation (negative play-speed less than
zero and greater than or equal to −1x), then the HTTP Client Endpoint should support the following
method:

• issuing a single HTTP GET request with a specified PlaySpeed.dlna.org header field.
[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC 2DQOQ

2616

11.4.3.49 MT HTTP streaming scan media operations

11.4.3.49.1
[G UIDELINE ] If a streaming HTTP Client Endpoint wants to stop a normal playback stream in order
to start a scan operation playback using the Range header under conditions where 11.4.3.5.6
applies, then it should close the original HTTP connection before issuing a GET request with the
Range header to perform scan operations (also known as trick modes). After closing the original
connection, the streaming HTTP Client Endpoint should open a new HTTP connection for the scan
operation. Please observe that the new HTTP connection might be a persistent connection, which
allows the client to issue multiple GET requests on a single HTTP connection.

[ATTRIBUTES ]

S A DMP DMR +DN+ M-DMP n/a IETF RFC 6TQT3

+DNSYNC+ 2616

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 560 –

[C OMMENT] Transitions from scan operations to normal playback can be achieved by making open
ended (i.e. last-byte-pos value in Range header is absent) GET requests with the Range option.

11.4.3.49.2
[G UIDELINE ] If a streaming HTTP Client Endpoint wants to stop a normal playback stream in order
to start a scan operation playback using the PlaySpeed.dlna.org header under conditions where
11.4.3.5.6 applies, then it should close the original HTTP connection before issuing a GET request
with the PlaySpeed.dlna.org header to perform scan operations (also known as trick modes). After
closing the original connection, the streaming HTTP Client should open a new HTTP connection for
the scan operation. Please observe that the new HTTP connection might be a persistent connection,
which allows the client to issue multiple GET requests on a single HTTP connection.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC M6TQT

2616

[C OMMENT] Transitions from scan operations to normal playback can be achieved by closing the
HTTP connection that provides scan operations and opening a new HTTP connection for normal
playback speed.

11.4.3.50 MT HTTP streaming download media operation

[G UIDELINE ] An HTTP Client Endpoint shall initiate a streaming download media operation with the
HTTP GET method when using the HTTP transport protocol for content, and it shall specify the
transferMode.dlna.org HTTP header with a value of "Streaming".

[ATTRIBUTES ]

M L +DN+ +DNSYNC+ n/a n/a IETF RFC X7UF4

2616

11.4.3.51 MT HTTP prohibited operations for streaming download

[G UIDELINE ] An HTTP Client Endpoint performing a streaming download media operation shall not
use any of the following media operations as specified in these guidelines, see Table 44.

Table 44 – HTTP prohibited operations references

Operation Reference

Pause 11.4.3.41 MT HTTP Pause/Pause-Release media operation

Fast Forward Scan 11.4.3.45 MT HTTP Fast Forward Scan media operation

Slow Forward Scan 11.4.3.46 MT HTTP Streaming Slow Forward Scan media operation

Fast Backward Scan 11.4.3.47 MT HTTP Streaming Fast Backward Scan media operation

Slow Backward Scan 11.4.3.48 MT HTTP Streaming Slow Backward Scan media operation

[ATTRIBUTES ]

M L +DN+ +DNSYNC+ n/a n/a IETF RFC AA772

2616

DLNA guidelines; Part 1-1: Architecture and protocols

 – 561 –

11.4.3.52 MT HTTP media operation support within a profile

11.4.3.52.1
[G UIDELINE ] If the following conditions are true, then the HTTP Client Endpoint shall support that
media operation on all content with that Media Format Profile.

• The HTTP Client Endpoint supports a media operation on a DLNA Media Format Profile.
• The HTTP Server Endpoint supports the necessary protocol elements to support the media
operation.
[ATTRIBUTES ]

M A DMP DMR +DN+ M-DMP n/a n/a 8H8X2

+DNSYNC+

[C OMMENT] Necessary protocol elements can include optional parameters such as byte Range
and TimeSeekRange.dlna.org.

11.4.3.52.2
[G UIDELINE ] If an HTTP Server Endpoint supports byte Range and/or TimeSeekRange.dlna.org
capabilities on the content for a particular DLNA Media Format Profile, it should support that on all
content with that Media Format Profile.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a Z8H8X

[C OMMENT] In some cases, such as transcoded or live content, it can be difficult to support byte
Range and/or TimeSeekRange.dlna.org.

11.4.3.53 MT HTTP PlaySpeed.dlna.org header

11.4.3.53.1
[G UIDELINE ] If the Content Source indicates support for the PlaySpeed.dlna.org HTTP header for a
content binary (as defined in guideline 10.1.3.22), then the HTTP Server Endpoint shall respond to
PlaySpeed.dlna.org HTTP requests for that content binary with the clarifications and constraints
defined in guidelines 11.4.3.53.2 to 11.4.3.53.10.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC F57CP

2616

[C OMMENT] The PlaySpeed.dlna.org HTTP header allows HTTP clients to request the HTTP server
to return content in a time scaled form.
For example, a DLNA HTTP client can request a DLNA HTTP server to return DLNA content in a 4x
playback speed. The HTTP server's response would send content that gives the appearance of 4x
playback speed.

This HTTP header can be used by DLNA servers for content conforming to DLNA Media Format
Profiles and content that does not conform to DLNA Media Format Profiles.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 562 –

11.4.3.53.2
[G UIDELINE ] If a streaming HTTP Server Endpoint receives the PlaySpeed.dlna.org HTTP header
in a HEAD request, then the HTTP server may respond without the PlaySpeed.dlna.org HTTP
header.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC 7UF4F

2616

[C OMMENT] HTTP servers are required to support the HEAD method. When an HTTP server gets a
HEAD request with this option, the HTTP server can omit it from the response.

If HTTP clients need to determine if the PlaySpeed.dlna.org is supported for a URI, then the client
are supposed to use the mandatory getcontentFeatures.dlna.org HTTP header and examine the
DLNA.ORG_PS parameter.

The reason why HEAD responses do not require the use of PlaySpeed.dlna.org is that the
computational effort to respond with only the headers for a request that includes
PlaySpeed.dlna.org is significant.

11.4.3.53.3
[G UIDELINE ] If the streaming HTTP Endpoint uses the PlaySpeed.dlna.org HTTP header, then the
Endpoint shall use the following syntax for the HTTP header and its value.

• play-speed-line = "PlaySpeed.dlna.org" *LWS ":" *LWS play-speed specifier

• play-speed specifier = "speed" "=" transport-play-speed
• transport-play-speed = <use the same notation for the AVT.TransportPlaySpeed state variable
defined in the UPnP AV Transport service type>
NOTE The "speed" token is case sensitive.

Examples:

• PlaySpeed.dlna.org: speed=10
• PlaySpeed.dlna.org: speed=-1/2
When encountering syntax errors with the PlaySpeed.dlna.org HTTP header, the HTTP server shall
use the HTTP response code 400 (Bad Request).

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC A772R
2616

[C OMMENT] The field value specifies a play-speed to scale content data of a resource. The value is
represented as same as TransportPlaySpeed state variable defined by AV Transport service type
(e.g. 5, 10, -1/2. -10, -3/2, etc.).

11.4.3.53.4
[G UIDELINE ] If the streaming HTTP Server Endpoint returns data (Target Response) for scaled
content to be decoded for a scan operation (also known as variable play-speed) with the HTTP
response code 200 (OK), then the HTTP response message shall specify the PlaySpeed.dlna.org
HTTP header field to indicate the play-speed of the scaled content.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 563 –

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 57CPW

2616

[C OMMENT] This guideline requires the HTTP server to indicate if content bytes in the HTTP
response represent content that has been time scaled.

11.4.3.53.5
[G UIDELINE ] If the requested play-speed is not valid for the resource with the URI specified in the
HTTP GET request, then the HTTP server shall respond with the HTTP response error code 406
(Not Acceptable). Interpretation of not valid includes the following types of errors.

If an HTTP server supports the PlaySpeed.dlna.org header and the requested play-speed is not
valid for the resource with the URI specified in the HTTP GET request, then the HTTP server shall
respond with the HTTP response error code 406 (Not Acceptable). Interpretation of not valid
includes the following types of errors:

• the requested TransportPlaySpeed is not supported for the content.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC H8X2Y

2616

[C OMMENT] This guideline specifies the error code to be used in scenarios where the HTTP server
cannot accommodate a request to time scale content.

The HTTP Server Endpoint indicates support for the PlaySpeed.dlna.org header in the
DLNA_ORG_PS parameter which is in the contentFeatures.dlna.org in guideline 10.1.3.22.

11.4.3.53.6
[G UIDELINE ] The scaled data (returned by the streaming HTTP Server Endpoint as a Target
Response) shall be compliant the Media Format Profile associated with the requested resource.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 7CPWA

2616
ISO/IEC
29341-20-3

[C OMMENT] This guideline obliges an HTTP Server Endpoint to return content bytes that are
conformant to the characteristics described for that content by its Media Format Profile. For
example, if the content is exposed as MPEG2_PS_NTSC content, the returned content shall
conform to the MPEG syntax defined for that Media Format Profile. For example, if the content is
exposed as MPEG2_PS_NTSC content, the returned content conforms to the MPEG syntax defined
for that Media Format Profile, or, if the Media Format Profile definition calls for MPEG-2 video
compression, that same media format applies during trick modes

11.4.3.53.7
[G UIDELINE ] The scaled data stream (returned by the streaming HTTP Server Endpoint as a Target
Response) may utilize different media format parameters than the original (unscaled) stream, as
long as these differences do not impact its compliance with the Media Format Profile of the original

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 564 –

(unscaled) content binary. Generating scaled data streams by dropping or adding frames to the
stream is called Decimation and Augmentation

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC CSWJC

2616
ISO/IEC
29341-20-3

[C OMMENT] This guideline provides considerable leeway in the Serving Endpoint’s implementation
of scaled content. For example, consider a Serving Endpoint A that implements a Scale value of 2
by dropping every other frame in a 30 frames per second stream resulting in a content stream that
still contains 30 frames per second, but that appears to be playing at twice the normal speed. Next ,
consider Serving Endpoint B that implements the same Scale value of 2 by sending 4 I-Frames a
second with a presentation time of 250 ms per frame, which will also appear to be playing twice as
fast. Finally, consider a Serving Endpoint C that implements a Scale value of 2 by transcoding the
original stream into a new stream with the same Format Profile, and which gives the appearance of
playing twice as fast. For slow speed trick modes, consider a serving endpoint D that implements a
Scale value of ½ by duplicating each I-Frame in a 30 fps stream playing at 30 frames per second
thus appearing to play at half speed. The technique of dropping or adding frames to generate scaled
streams is called Decimation and Augmentation. Such streams may contain partial “P” frames for
MPEG-2 content and non-conformant values for Presentation Time Stamp (PTS). In addition to
using Decimation and Augmentation, servers may also choose to omit audio tracks, in order to
minimize the bitrate of scaled streams.

11.4.3.53.8
[G UIDELINE ] If the Content Source does not indicate support for the PlaySpeed.dlna.org HTTP
header for a content binary (as defined in guideline 10.1.3.22), then the HTTP Client Endpoint shall
not issue HTTP GET and HEAD requests with the PlaySpeed.dlna.org HTTP header.

[ATTRIBUTES ]

M L DMP DMR +DN+ M-DMP n/a IETF RFC ZAVEC

+DNSYNC+ 2616

11.4.3.53.9
[G UIDELINE ] If the PlaySpeed.dlna.org request is syntactically correct and the requested
play-speed is valid, and if the HTTP Server Endpoint returns data including the requested
play-speed (Target Response) then it shall respond to the HTTP GET request with the 200 (OK)
HTTP response code.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 9WS9T

2616

11.4.3.53.10
[G UIDELINE ] An HTTP Client Endpoint should mute audio content when rendering scaled data
streams requested using the PlaySpeed.dlna.org header.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC 9C9YV

2616

[C OMMENT] While the requirements for AV stream formats mandate that there be an audio
DLNA guidelines; Part 1-1: Architecture and protocols
 – 565 –

component in the stream, the actual playback of audio from scaled streams requested using the
PlaySpeed.dlna.org header would be problematic and likely to result in a poor user experience. It is
preferable that client devices mute audio when rendering scaled streams.

11.4.3.54 MT HTTP play-speed position

[G UIDELINE ] If the Content Source indicates support for the PlaySpeed.dlna.org HTTP header for a
content binary (as defined in guidelines 10.1.3.22), then the HTTP Server Endpoint may provide
NPT and byte-pos (byte offset) information in chunk header when transferring data in chunked
transfer when play-speed is not equal to 1x. The NPT and byte-pos values in a chunk header should
correspond to the chunk data. The format of chunk extension to provide NPT and byte-pos
information shall be

• chunk extension to pass NPT information

npt=npt-time as defined in guideline 11.4.2.13 (npt sec | npt hhmmss),
• chunk extension to pass byte offset:
byte-pos=byte-offset-value
The format of chunk header with the above two chunk extensions is as follows:

• chunk-size“; npt=”npt-time“; byte-pos=”byte-offset-value CRLF.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC 6U8UB

2616

[C OMMENT] The client endpoint uses this information to keep track of elapsed time accurately. This
is specifically useful when there are discontinuities in PTS. One possible scenario where PTS
discontinuities are expected is segmented recordings.

11.4.3.55 MT HTTP header: chunckEncodingMod.dlna.org

11.4.3.55.1
[G UIDELINE ] If a serving endpoint receives an HTTP Get request with
ChunkEncodingMode.dlna.org header and play-speed different than 1, the serving endpoint may
send the response using HTTP chunked transfer coding.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC J25AL

2616

11.4.3.55.2
[G UIDELINE ] The notation for the ChunkEncodingMode.dlna.org header is defined as follows:

• ChunkEncodingMode -line = "ChunkEncodingMode.dlna.org” * LWS":" 1.

The only value possible is "1".

[ATTRIBUTES ]

M A DMS +PU+ DMP DMR M-DMS n/a IETF RFC ES67D

2616

[C OMMENT] An example is

• ChunkEncodingMode:1.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 566 –

11.4.3.55.3
[G UIDELINE ] A receiving endpoint may use the ChunkEncodingMode.dlna.org header to request
chunked transfer encoding from a serving endpoint.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a IETF RFC EUYJG

2616

11.4.3.56 MT combined range, time based seek, and play-speed HTTP requests
11.4.3.56.1
[G UIDELINE ] If a streaming HTTP Server Endpoint receives an HTTP GET request with both the
PlaySpeed.dlna.org and the TimeSeekRange.dlna.org header fields, the endpoint shall understand
that a scan operation is requested for the specified time range.

If the streaming HTTP Server Endpoint can never process either or both time-scaling and time-seek,
the error code for time-scaling, 406 (Not Acceptable) shall be returned.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC PWAEV

2616

[C OMMENT] This guideline covers what a streaming HTTP server endpoint needs to do if it receives
an HTTP request for both time based seek and play-speed. This guideline also infers how a
streaming HTTP Client endpoint can expect an HTTP Server Endpoint to behave.

11.4.3.56.2
[G UIDELINE ] If a streaming HTTP Server Endpoint receives an HTTP GET request with Range and
(TimeSeekRange.dlna.org or PlaySpeed.dlna.org) header fields, then the Range header field shall
take the highest precedence and the server shall ignore the other time seek and play-speed fields.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC CPWAE

2616

[C OMMENT] This guideline covers what a streaming HTTP Server Endpoint needs to do if it
receives an HTTP request with Range and other DLNA fields for play-speed or time based seek.
This guideline also infers how a streaming HTTP Client endpoint can expect an HTTP Server
Endpoint to behave.

11.4.3.57 MT HTTP header: realTimeInfo.dlna.org

11.4.3.57.1
[G UIDELINE ] HTTP Client Endpoints may use realTimeInfo.dlna.org in GET or HEAD requests to
specify the desired policy for content delivery.

[ATTRIBUTES ]

O A DMP DMR +DN+ M-DMP n/a IETF RFC WAEVZ

+DNSYNC+ 2616

[C OMMENT] By using this header, an HTTP Client Endpoint (e.g. DMP) informs an HTTP Server

DLNA guidelines; Part 1-1: Architecture and protocols

 – 567 –

Endpoint (e.g. DMS) the way it wants to receive content byte data (unmodified or in a real-time
manner). In the second case, the loss of content quality (i.e. drop data bytes) is possible.

In the case of real-time delivery, it provides a hint to an HTTP Client Endpoint on how long to
pre-buffer content data bytes before beginning the playback.

11.4.3.57.2
[G UIDELINE ] If an HTTP Client Endpoint request contains the realTimeInfo.dlna.org header, then
the HTTP Server Endpoint reply should include the realTimeInfo.dlna.org header.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC 2Y963

2616

[C OMMENT] An HTTP Client Endpoint (e.g. DMP) shall be ready to receive an undesired value for
the max-delay-time from an HTTP Server Endpoint (e.g. DMS).

It is worth to mention that for a live content the max-lag-time value can't be set as infinite.

11.4.3.57.3
[G UIDELINE ] If an HTTP Server Endpoint responds with a realTimeInfo.dlna.org header with an
infinite max-lag-time (i.e. with value of "*"), then it shall not drop and/or modify any portion of content
byte data.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC X2Y96

2616

11.4.3.57.4
[G UIDELINE ] If an HTTP Server Endpoint responds with a realTimeInfo.dlna.org header with a finite
max-lag-time, then it shall not send stale data when the delay time is more than the max-lag-time. In
this case an HTTP Server Endpoint shall omit the Content-Length header from HTTP response.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 2R2GY

2616

11.4.3.57.5
[G UIDELINE ] An HTTP Server Endpoint should include the realTimeInfo.dlna.org header in each
HTTP reply.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC 8X2Y9

2616

[C OMMENT] It is desirable to provide an HTTP Client Endpoint (e.g. DMP) the information for the
delivery manner each time.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 568 –

11.4.3.57.6
[G UIDELINE ] If an HTTP Server Endpoint receives an HTTP GET or HEAD request with a Range
and realTimeInfo.dlna.org header, then an HTTP Server Endpoint shall never reply with a finite
max-lag-time parameter value.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC R2GYQ

2616

[C OMMENT] This guideline obliges an HTTP Server Endpoint to not change the content data bytes
in a reply to a request with a Range header.

11.4.3.57.7
[G UIDELINE ] The notation for the realTimeInfo.dlna.org HTTP header is defined as follows:

• realTimeInfo-line = "realTimeInfo.dlna.org" *LWS ":" *LWS max-lag-time

• max-lag-time= "DLNA.ORG_TLAG" "=" duration
• duration = npt-sec | "*"
• ntp-sec= 1*DIGIT["."1*3DIGIT]
Note that the literal, "DLNA.ORG_TLAG" is case sensitive.

The max-lag-time is the maximum allowed delay between the current time and the time at which a
particular portion of content data shall be sent in order to meet the real-time delivery requirements
for content. If the delay for a particular portion of content data exceeds the max-lag-time, then an
HTTP Server Endpoint shall drop it instead of sending it. The value "*" indicates that the content
data bytes will never expire. This guarantees that an HTTP Client Endpoint will receive all of the
content data bytes.

Duration shall be given in seconds.

Example:

• realTimeInfo.dlna.org: DLNA.ORG_TLAG=1.75
• realTimeInfo.dlna.org: DLNA.ORG_TLAG=*
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 72R2G
+DN+ +DNSYNC+ 2616

[C OMMENT] The max-lag-time value provides information to an HTTP Client Endpoint (e.g. DMP)
on how the content will be delivered. When it is infinite, all requested bytes of the original content
will be delivered without any modifications (i.e. data loss). Otherwise, an HTTP Client Endpoint (e.g.
DMP) can’t expect to receive the content unmodified (i.e. it can contain some data loss).

In the case for real-time delivery of content, the max-lag-time negotiation aids an HTTP Client
Endpoint (e.g. DMP) to adjust its pre-buffering time and for an HTTP Server Endpoint (e.g. DMS) its
delay buffer. This negotiation aids an HTTP Server Endpoint from sending stale content data bytes
instead of up-to-date ones.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 569 –

11.4.3.58 MT HTTP media operations support

11.4.3.58.1
[G UIDELINE ] If a media operation (play, stop, pause/release, seek, scan operations) is supported
for a content binary, Content Receivers shall support the media operation for the entire known
length of the content binary.

[ATTRIBUTES ]

M A DMP DMR +DN+ M-DMP n/a n/a 772R2

+DNSYNC+

11.4.3.58.2
[G UIDELINE ] If an op-param (10.1.3.19.1) capability (for play, stop, pause/release, seek, scan
operations) is supported for a content binary, Content Sources shall support the media operation for
the entire length of the content binary.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IEC 62481-2 F658Q

[C OMMENT] In the case of time seek range, HTTP Server Endpoints are still allowed to align
responses to frame boundaries as specified in IEC 62481-2, 9.3.2.7.1 (GUN UDJLP)

11.4.3.59 MT HTTP Interactive Transfer initiation

11.4.3.59.1
[G UIDELINE ] An HTTP Client Endpoint requesting a content binary from an HTTP Server Endpoint
with an Interactive Transfer shall use the HTTP GET method.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC QT357

2616

[C OMMENT] Interactive Transfers with GET are used to get Image content for immediate rendering.

11.4.3.59.2
[G UIDELINE ] If an HTTP Client Endpoint requests an Interactive Transfer, then it shall specify the
transferMode.dlna.org HTTP header and the header shall have a value of "Interactive".

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC NZ6EY

2616

[C OMMENT] Version 1.0 clients will still request Interactive Transfer of images without using the
transferMode.dlna.org HTTP header. Guideline 11.4.3.32.2 requires that servers that receive such
a request treat it as equivalent to a request for an Interactive Transfer for image Media Classes.

11.4.3.59.3
[G UIDELINE ] If an HTTP Server Endpoint receives an HTTP GET or HEAD request with a
transferMode.dlna.org HTTP header with the value of "Interactive" and the requested URI supports

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 570 –

Interactive Transfer mode (as defined in 10.1.3.36.1), then the Target Response shall replicate this
HTTP header.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC UF4F6

2616

11.4.3.60 MT Interactive Transfer headers interactions

[G UIDELINE ] An HTTP Client Endpoint shall not use the following headers when requesting an
Interactive Transfer:

• TimeSeekRange.dlna.org
• PlaySpeed.dlna.org
• realTimeInfo.dlna.org
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 4F658

2616

[C OMMENT] See 11.4.3.23, and 11.4.3.53 guidelines for more information on the operations of
these headers

11.4.3.61 MT range behavior for Interactive Transferred content

[G UIDELINE ] The Range HTTP header may be used for Interactive Transfers.

[ATTRIBUTES ]

O C DMS DMR DMP +PU+ M-DMS M-DMP n/a IETF RFC F4F65
2616

[C OMMENT] The behavior and usage model for the Range header are governed by other guidelines.
Specifically:

• 10.1.3.19 describes how the op-param indicates whether the Range header is supported under
the "Full Random Access Data Availability" model.
• 10.1.3.28.4 describes how lop-bytes indicates whether the Range header is supported under the
"Limited Random Access Data Availability" model.
• 11.4.3.18, 11.4.3.19, and 11.4.3.19.10 explain details about both models.
Interactive Transfers involving stored content generally fall under the category of Full Random
Access Data Availability model. In some cases, an Interactive Transfer involving converted content
will fall under the Limited Random Access Data Availability model when the mode-flag is 1.The
Limited Random Access Data Availability model when the mode-flag is 0 does not apply to content
that is transferred with Interactive Mode because that content is not time based.

11.4.3.62 MT HTTP Background Transfer initiation

11.4.3.62.1
[G UIDELINE ] An HTTP Client Endpoint downloading a content binary from an HTTP Server
Endpoint with a Background Transfer request shall use the HTTP GET method.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 571 –

[ATTRIBUTES ]

M A +DN+ +DNSYNC+ n/a n/a IETF RFC 3577T

2616

11.4.3.62.2
[G UIDELINE ] An HTTP Client Endpoint uploading a content binary to an HTTP Server Endpoint with
a Background Transfer request shall use the HTTP POST method.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC Z6EYR

2616

11.4.3.62.3
[G UIDELINE ] If an HTTP Client Endpoint requests a Background Transfer, then it shall specify the
transferMode.dlna.org HTTP header and the header shall have a value of "Background".

[ATTRIBUTES ]

M A +DN+ +UP+ n/a n/a IETF RFC RNZ6E

+DNSYNC+ 2616
+UPSYNC+

11.4.3.62.4
[G UIDELINE ] If an HTTP Server Endpoint receives an HTTP GET or HEAD request with a
transferMode.dlna.org HTTP header with the value of "Background" and the requested URI
supports the Background Transfer mode (as defined in 10.1.3.37), then the Target Response shall
replicate this HTTP header.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 6EYR3

2616

11.4.3.63 MT Background Transfer header interactions

[G UIDELINE ] An HTTP Client Endpoint shall not use the following headers when requesting a
Background Transfer with either the GET or POST methods.

• TimeSeekRange.dlna.org
• PlaySpeed.dlna.org
• realTimeInfo.dlna.org
[ATTRIBUTES ]

M A +DN+ +UP+ n/a n/a IETF RFC 7CWOV

+DNSYNC+ 2616
+UPSYNC+

[C OMMENT] See 11.4.3.23, and 11.4.3.53 guidelines for more information on the operations of
these headers.

11.4.3.64 MT range behavior for Background Transferred content

[G UIDELINE ] The Range HTTP header may be used for Background Transfers.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 572 –

[ATTRIBUTES ]

O C DMS +PU+ +DN+ M-DMS n/a IETF RFC CWOVY

+UP+ +DNSYNC+ 2616
+UPSYNC+

[C OMMENT] The behavior and usage model for the Range header are governed by other guidelines.
Specifically:

• 10.1.3.19 describes how the op-param indicates whether the Range header is supported under
the "Full Random Access Data Availability" model;
• 10.1.3.28.4 describes how lop-bytes indicates whether the Range header is supported under the
"Limited Random Access Data Availability" model;
• 11.4.3.18, 11.4.3.19, and 11.4.3.19.10 explain details about both models.
Background Transfers involving stored content generally fall under the category of "Full Random
Access Data Availability" model. In some cases, a Background Transfer involving converted content
will fall under the "Limited Random Access Data Availability" model when the mode-flag is 1. The
"Limited Random Access Data Availability" model when the mode-flag is 0 is not recommended for
content that is transferred with the Background Mode since the server response cannot be
guaranteed to be accurate for "live contents" when using the Range HTTP header, as described in
11.4.2.16.2.

11.4.3.65 MT content management HTTP POST content acqusition

11.4.3.65.1
[G UIDELINE ] An Upload Controller or Upload Synchronization Controller shall implement a content
transfer process by using an HTTP/1.1 POST request.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a IETF RFC I4UNM

2616

[C OMMENT] See 10.1.8.26 for more information.

11.4.3.65.2
[G UIDELINE ] HTTP Client Endpoints shall not use HTTP POST with an HTTP/1.0 indicator.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a IETF RFC 57N7M

2616

[C OMMENT] HTTP POST is defined only for HTTP/1.1.

11.4.3.65.3
[G UIDELINE ] An Upload Controller or Upload Synchronization Controller requesting a content
transfer process by using the HTTP/1.1 POST request, should set the transferMode.dlna.org HTTP
header to a value of "Background" in the request.

[ATTRIBUTES ]

S L +UP+ +UPSYNC+ n/a n/a IETF RFC UNMYS

2616

DLNA guidelines; Part 1-1: Architecture and protocols

 – 573 –

[C OMMENT] Values other than "Background" can be used when uploading certain contents, such
as "live" content.

11.4.3.65.4
[G UIDELINE ] A DMS or M-DMS that implements the Upload Device Option (i.e. the upload
AnyContainer) as indicated by the <dlna:X_DLNACAP> element described in guideline 10.1.8.4.1),
shall accept HTTP POST requests for receiving content in a content transfer operation.

[ATTRIBUTES ]

M R DMS M-DMS n/a IETF RFC NMYS5

2616

[C OMMENT] This is required by the ContentDirectory specification as the baseline manner of

transferring content to a UPnP AV MediaServer.

11.4.3.65.5
[G UIDELINE ] The HTTP Client Endpoint shall issue its first HTTP POST request (to upload content)
within 30 s of the CDS:CreateObject response.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a IETF RFC POVK7

2616

[C OMMENT] See 10.1.8.26 for more information.

11.4.3.65.6
[G UIDELINE ] If an HTTP Client Endpoint is using a persistent connection to perform multiple
content transfer processes, then the HTTP client should issue subsequent HTTP POST requests
within 5 min of the previous HTTP POST request's completion.

[ATTRIBUTES ]

S C +UP+ +UPSYNC+ n/a n/a IETF RFC 4UNMY

2616

[C OMMENT] Upload Controllers, or Upload Synchronization Controllers are urged to use persistent
HTTP connections to upload multiple content binaries. Ideally, these content transfers happen with
little delay between them. However, HTTP clients are discouraged from exceeding 5 min of
inactivity between transfers.

11.4.3.65.7
[G UIDELINE ] The HTTP Server Endpoint that is receiving an HTTP POST request is free to
terminate the connection at any time by closing the TCP connection.

[ATTRIBUTES ]

O C DMS M-DMS n/a IETF RFC 7N7MB

2616

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 574 –

[C OMMENT] DMS or M-DMS devices implement this behavior to indicate an error during the content
transfer. For example, if the DMS no longer has enough space, it can terminate the TCP connection.

A DMS that does a TCP disconnection can automatically destroy CDS objects or <res> elements.
However, if possible and appropriate, the DMS is encouraged to allow an Upload Controller to retry
a content transfer process, by not destroying the CDS object or <res> element.

11.4.3.65.8
[G UIDELINE ] The HTTP Server Endpoint that supports HTTP POST requests shall support
requests that are encoded with Chunked Transfer Coding.

[ATTRIBUTES ]

M R DMS M-DMS n/a IETF RFC G857N

2616

[C OMMENT] HTTP clients can use either the default HTTP message encoding or Chunked Transfer
Coding.

11.4.3.65.9
[G UIDELINE ] The HTTP Client Endpoint shall provide the EXPECT HTTP header field with the
value of "100-continue" in the request.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC 857N7

2616

[C OMMENT] Subclause 8.2.3 Use of the 100 (Continue) Status in IETF RFC 2616 defines the
behavior when a HTTP client uses "Expect: 100-continue" in the request.

The HTTP client waits to send POST message body, i.e. a content binary, until it receives a
response to the request.

11.4.3.65.10
[G UIDELINE ] If an HTTP Server Endpoint receives a POST request without the "EXPECT:
100-continue", then it should return an HTTP error of 400 (Bad Request) and terminate the TCP
connection.

[ATTRIBUTES ]

S A DMS M-DMS n/a IETF RFC QPOVK

2616

11.4.3.65.11
[G UIDELINE ] If an HTTP Server Endpoint that receives a POST request's HTTP headers and the
HTTP server cannot accept the POST request's message body, then the HTTP Server Endpoint
shall not return an HTTP status code of 100 (Continue).

[ATTRIBUTES ]

M R DMS M-DMS n/a IETF RFC 5QPOV

2616

DLNA guidelines; Part 1-1: Architecture and protocols

 – 575 –

[C OMMENT] The guideline 11.4.3.65.13 and 11.4.3.65.14 provides examples of error cases.

11.4.3.65.12
[G UIDELINE ] An HTTP Client Endpoint that uses Chunked Transfer Coding shall use a zero-length
chunk to indicate the end of the content binary.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC T6KSW

2616

[C OMMENT] DMS and M-DMS devices look for the zero-length chunk to know if the content binary
was completely sent.

11.4.3.65.13
[G UIDELINE ] If the HTTP Server Endpoint cannot accept an HTTP POST request due to the
processing capacity or current state of the device, then the HTTP Server Endpoint should respond
with an HTTP status code of 503 (Service Unavailable).

[ATTRIBUTES ]

S R DMS M-DMS n/a IETF RFC OVK7Y

2616

11.4.3.65.14
[G UIDELINE ] If the HTTP Server Endpoint cannot accept an HTTP POST request due to the lack of
storage capacity, then the HTTP Server Endpoint should respond with an HTTP status code 507
(Insufficient Storage).

[ATTRIBUTES ]

S A DMS M-DMS n/a IETF RFC TQT6K

2616

[C OMMENT] This error code aligns with IETF RFC 2518. DLNA does not use WebDAV as a
normative reference.

11.4.3.65.15
[G UIDELINE ] If the HTTP Server Endpoint receives an entire entity body, then the HTTP Server
Endpoint shall respond with either an HTTP status code of 200 (OK) or an HTTP status code of 201
(Created).

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC QT6KS

2616

11.4.3.65.16
[G UIDELINE ] If an HTTP Server Endpoint rejects a POST entity body in the middle of data transfer
(due to the processing capacity, current status of the device, storage capacity, etc.) then the HTTP
server may terminate the TCP connection.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 576 –

[ATTRIBUTES ]

O R DMS M-DMS n/a IETF RFC 8VREB

2616

[C OMMENT] Vendors can determine whether or not data is actually stored.

11.4.3.65.17
[G UIDELINE ] If an HTTP Server Endpoint rejects a POST entity body in the middle of data transfer,
then it should also send an HTTP error response right before terminating the TCP connection.

[ATTRIBUTES ]

S A DMS M-DMS n/a IETF RFC EBUTB

2616

[C OMMENT] HTTP error responses allow the HTTP server to provide more details on the cause of
the error. It is imperative that the HTTP server close the TCP connection after sending the error
response because the error can interfere with the logic associated with pipelined HTTP requests.

The requirement for HTTP clients to be tolerant of these scenarios means that the HTTP client can
gracefully handle the TCP disconnect. (i.e. devices that crash as a result of a TCP disconnect
exhibit bad behavior) There is no requirement that the HTTP client make the HTTP error response
available to the user.

HTTP clients can use pipelined POST requests, but these guidelines do not recommend their usage
because the Upload system usage model favors a model where an Upload Controller uses a set of
CDS:CreateObject and HTTP POST transactions, rather than a set of CDS:CreateObject requests
followed by a set of HTTP POST transactions.

Clients are encouraged to terminate the connection after receiving the POST response from the
server because HTTP/1.1 POST transactions operate under persistent connection rules.

11.4.3.65.18
[G UIDELINE ] If an HTTP Server Endpoint rejects a POST entity body in the middle of data transfer
by sending an HTTP error response, then it shall terminate the TCP connection after sending the
error response.

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC VREBU

2616

11.4.3.65.19
[G UIDELINE ] HTTP Client Endpoints shall be tolerant of a TCP layer disconnect during an HTTP
POST transaction, including those scenarios where the HTTP Server Endpoint sends an HTTP error
response before the HTTP Client Endpoint has finished transmitting the POST request's
message-body.

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a IETF RFC BUTB4

2616

DLNA guidelines; Part 1-1: Architecture and protocols

 – 577 –

11.4.3.65.20
[G UIDELINE ] If the HTTP Server Endpoint detects or initiates a TCP disconnect during a content
transfer process that does not support the resume content transfer option, then the MediaServer
shall be capable of accepting the same upload AnyContainer or OCM: upload content request that
created the CDS object, which has the failed content transfer.

[ATTRIBUTES ]

M A DMS M-DMS n/a n/a KSWAC

[C OMMENT] In other words, the DMS is expected to not return an UPnP error in response to a new
CDS:CreateObject request when the Upload Controller attempts to retry a failed upload
AnyContainer or OCM: upload content operation.

A DMS can implement a variety of behaviors to comply with this guideline.

• The DMS can immediately destroy the CDS object associated with the failed content transfer.
• The DMS can leave the CDS object in the CDS hierarchy for 30 min or less, from the point of the
failure. The CDS:CreateObject response returns a new CDS object.
• The DMS can leave the CDS object in the CDS hierarchy for 30 min or less, from the point of
failure. The CDS:CreateObject response returns the same CDS object because the metadata
specified in the request is exactly the same.
11.4.3.65.21
[G UIDELINE ] When the HTTP Client Endpoint detects a TCP disconnection before receiving the
final response to the HTTP POST request, it shall not assume that the HTTP Server Endpoint will
store the transferred portion of the entity body. Specifically, this means the following.

• If the HTTP Client Endpoint wants to retry an upload process without using the resume content
transfer or retry IFO attempt features, it shall start completely over by doing the
CDS:CreateObject request (as part of the upload AnyContainer or OCM: upload content
operation) and following up with a new content transfer process. (Note that retry IFO attempt
applies only to the transfer of IFO files and only is available when resume content transfer is also
available.)
• If the HTTP Client Endpoint wants to use the resume content transfer operation, then it shall
specify a first-byte-pos of res@dlna:uploadedSize for the Content-Range header in an HTTP
POST request. In this case, CDS:CreateObject is not invoked.
[ATTRIBUTES ]

M C +UP+ +UPSYNC+ n/a n/a IETF RFC VK7YF

2616

[C OMMENT] If resume content transfer is not supported and the HTTP Client attempts to retry the
HTTP POST transaction without invoking CDS:CreateObject again, then the retry attempt can fail.
This type of a retry attempt is not covered by the DLNA guidelines.

11.4.3.66 MT HTTP content transfer error detection during HTTP POST

11.4.3.66.1
[G UIDELINE ] If an HTTP Server Endpoint observes a TCP disconnect under all of the following
conditions, then the HTTP server shall assume that the HTTP Client Endpoint failed to transfer the
content.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 578 –

• HTTP POST request does not use Chunked Transfer Coding

• The number of received bytes is less than the specified Content-Length.
If an HTTP Server Endpoint detects that the HTTP Client Endpoint failed to transfer the content and
more than 35 min has elapsed since the end of the failed transfer attempt, then the MediaServer is
obliged by 10.1.8.28 to automatically destroy the created CDS object.

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC N7MBJ

2616

[C OMMENT] HTTP Client Endpoints are required to use the Content-Length in HTTP POST
requests that do not use Chunked Transfer Coding.

Guideline 11.4.3.16 clarifies the uses of Content-Length for media transfers.

11.4.3.66.2
[G UIDELINE ] An HTTP Server Endpoint receiving a POST request shall observe at least 30 s of
data inactivity before closing the TCP connection and assuming that the HTTP Client Endpoint
failed to transfer the content.

Data inactivity is defined as the HTTP Server Endpoint not receiving content data from the HTTP
Client Endpoint even though there is an established TCP connection.

This guideline works in conjunction with 11.4.3.65.7 because this guideline assumes Ideal Network
Conditions and also assumes that neither user-initiated causes nor out-of-band system events
cause the connection to be closed.

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC MYS54

2616

[C OMMENT] These guidelines specify a 5 min timeout for stalled content transfer.

11.4.3.65.7 permits HTTP Servers to close the connection at any time.

11.4.3.67 MT client Content-Range

11.4.3.67.1
[G UIDELINE ] An HTTP Client Endpoint that uses the resume content transfer operation shall
specify the Content-Range HTTP header field in a POST request to specify the range of content
data sent in the request.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC VY6R4

2616

[C OMMENT] The Content-Range header is defined in IETF RFC 2616, 14.16.

11.4.3.67.2
[G UIDELINE ] An HTTP Client Endpoint that uses the resume content transfer operation shall
include and specify the instance-length parameter on the Content-Range HTTP header and
last-byte position on the Content-Range HTTP header shall be instance-length −1.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 579 –

[ATTRIBUTES ]

M L +UP+ +UPSYNC+ n/a n/a IETF RFC EYR3R

2616

[C OMMENT] The instance-length parameter (see IETF RFC 2616, 14.16) specifies the total size of
the object being uploaded.

The instance-length parameter shall specify a valid value, so "*" shall not be used for the
instance-length parameter.

This guideline applies even when the HTTP client uses chunked transfer coding.

11.4.3.67.3
[G UIDELINE ] If an HTTP Client Endpoint specifies the Content-Range HTTP header the
first-byte-pos shall be equal to the content length already stored in a peer HTTP server.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC 577T6

2616

[C OMMENT] Length of already stored data (on a peer HTTP server) can be known through the
res@dlna:uploadedSize in a CDS:Browse response.

The first-byte-pos parameter is defined in IETF RFC 2616, 14.16.

11.4.3.67.4
[G UIDELINE ] An HTTP client shall use the Content-Range HTTP header only with POST requests
that are part of a resume content transfer operation (i.e. use with GET nor HEAD request is
prohibited).

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC 658QX

2616

11.4.3.67.5
[G UIDELINE ] An HTTP Client Endpoint shall not specify the Content-Range HTTP header for a
POST request addressed to res@importUri included in an object that does not support the resume
content transfer functionality.

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC 2GYQ2

2616

[C OMMENT] An Upload Controller or Upload Synchronization Controller is able to know if the

MediaServer supports resume functionality by res@dlna:resumeUpload in CDS:CreateObject.

11.4.3.67.6
[G UIDELINE ] An HTTP Client Endpoint shall not specify the Content-Range HTTP header for a
POST request addressed to res@dlna:importIfoFileURI.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 580 –

[ATTRIBUTES ]

M A +UP+ +UPSYNC+ n/a n/a IETF RFC Y9634

2616

[C OMMENT] The resume content transfer operation can be supported for res@importUri and
cannot be used for res@dlna:importIfoFileURI. To recover from a failed transfer of an IFO file, the
HTTP client simply does a retry IFO attempt, which is an HTTP POST request without the
Content-Range HTTP header. Please note that type of transfer recovery is out of scope for
res@importUri values.

11.4.3.68 MT server receiving Content-Range

11.4.3.68.1
[G UIDELINE ] If an HTTP Server Endpoint has resume functionality and receives a POST request
with Content-Range addressed to res@importUri which includes a syntax error, it should respond
an HTTP response which status code is 400 (Bad Request).

[ATTRIBUTES ]

S A DMS M-DMS n/a IETF RFC VZ5SV

2616

[C OMMENT] If an instance-length is "*", in the Content-Range, DMS is expected to respond with an

HTTP response with a status code of 400.

11.4.3.68.2
[G UIDELINE ] If an HTTP Server Endpoint has resume functionality and receives a POST request
with the Content-Range header in which the content-range-spec has a first-byte-pos value that is
equal to the object byte size already stored (i.e. res@dlna:uploadedSize), then the HTTP Server
Endpoint shall append the incoming uploaded data to the stored one.

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC 96343

2616

[C OMMENT] The Content-Range header and the first-byte-pos parameter are defined in IETF RFC
2616, 14.16.

A client can get the value of res@dlna:uploadedSize from a browse operation after the failure.

11.4.3.68.3
[G UIDELINE ] If an HTTP Server Endpoint has resume functionality and receives a POST request
with the Content-Range header in which the content-range-spec has a first-byte-pos value that is
not equal to the object byte size already stored, then the HTTP server shall send an HTTP response
which status code is 409 (Conflict).

This guideline is applied only when another error condition is not satisfied.

[ATTRIBUTES ]

M A DMS M-DMS n/a IETF RFC 6343S

2616

DLNA guidelines; Part 1-1: Architecture and protocols

 – 581 –

11.4.3.69 MT HTTP POST pipelining

11.4.3.69.1
[G UIDELINE ] If an HTTP Client Endpoint initiates pipelined HTTP POST transactions, a subsequent
pipelined POST request shall happen after the previous message-body has been sent completely.

[ATTRIBUTES ]

M C +UP+ +UPSYNC+ n/a n/a IETF RFC YQ2KA

2616

[C OMMENT] An Upload Controller or Upload Synchronization Controller that starts a subsequent

POST transaction before having sent the message-body for the previous POST transaction will
confuse the HTTP Server Endpoint into thinking the subsequent POST transaction is the
message-body for the first POST transaction.

11.4.3.69.2
[G UIDELINE ] An HTTP Server Endpoint may terminate the HTTP session after responding to a
POST request with the 200 (OK) or 201 (Created) responses.

[ATTRIBUTES ]

O C DMS M-DMS n/a IETF RFC GYQ2K

2616

[C OMMENT] DMS devices are not required to support pipelined HTTP POST transactions.
Therefore, it remains the responsibility of the Upload Controller to retry an attempted pipelined
POST transacations when the HTTP server does not support pipelined POST transactions, see
Figure 22.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 582 –

Figure 22 – Example of a valid and invalid pipelined POST transaction

11.4.4 RTP Media Transport

11.4.4.1 General
The Real-time Transport Protocol (RTP) IETF RFC 3550 together with its companion protocol
(RTCP) constitutes the basis of a transport mechanism for real-time media streams. In DLNA, RTP
is used in combination with the RTSP protocol IETF RFC 2326, SDP protocol IETF RFC 2327, RTP
payload formats and their associated Media Format Profiles. These protocols define the DLNA RTP
media transport which is optionally supported in DLNA, in addition to the required HTTP transport.

The subclauses in 11.4.4 define guidelines for the implementation of the RTP Media Transport in
the context of home networking. These apply to the playback of DLNA content and the streaming
transactions between DLNA device classes. These guidelines do not specify behavior for non-DLNA
device entities. A device class can be implemented by software running on a more general-purpose
device/platform. For example, the RTP server of a Serving Endpoint can be used to serve DLNA and
non-DLNA content. These guidelines would apply only when the DLNA-content is being served.

For these DLNA guidelines, RTP/RTCP is a protocol which is carried over UDP/IP for unicast
connections. A graphical representation of the reference protocol stack for the RTP Media
Transport is shown in Annex F. The RTP Media Transport is enriched with the support of advanced
features. For example, RTP retransmission can be used to increase reliability of media delivery. The
RTP Media Transport also supports mechanisms for adaptive media delivery to improve continuous
playback even in adverse network conditions. These guidelines also cover the RTSP protocol,
which is carried over TCP connections. RTSP supports pause, seek and scan media operations
(fast forward, slow forward, fast backward and slow backward).

Lastly, the DLNA guidelines do not specify interoperability for the transfer of content for either the
Upload system usage or the Download system usage. Likewise, the DLNA guidelines also assume
that the RTP Media Transport applies only to the Streaming Transfer Mode. The Interactive and
Background Transfer modes do not apply to the RTP Media Transport.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 583 –

The guidelines for RTP are organized as follows.

• RTP/RTCP Protocols: 11.4.4.2 through 11.4.4.19 provides general RTP media transport
guidelines. 11.4.4.20 through 11.4.4.42 provides RTP Serving Endpoints guidelines, while
11.4.4.43 through 11.4.4.58 provides RTP guidelines for Receiving Endpoints. These
subclauses also include guidelines for RTCP.
• Adaptation of Media Format Profiles 11.4.4.60 through 11.4.4.127 provides guidelines on
adaptating several Media Format Profiles for use with RTP and RTP payload formats.
• RTSP/SDP Protocols: 11.4.4.129 through 11.4.4.211 includes guidelines for the support of the
Real-Time Streaming Protocol IETF RFC 2326 and the support for the Session Description
Protocol IETF RFC 2327.
The terms Serving Endpoint and Receiving Endpoint are specific to RTP, and they are defined
specifically in 11.4.4.4 and 11.4.4.5. Respectively, they represent the different RTP, RTCP, RTSP,
and SDP server/client components needed for a Content Source or Content Receiver using RTP.

[C OMMENT] In v1.0 of the DLNA guidelines, Serving Endpoint and Receiving Endpoint were used.
Since the system usages for v1.5 is greatly expanded, those terms were deemed insufficient to
represent the different content roles on the network.

11.4.4.2 MT RTP optional transport: RTP

[G UIDELINE ] DLNA devices may implement RTP over UDP as an optional media transport.
guidelines in

• 11.4.4.2 through 11.4.4.19: RTP Media Transport: RTP/RTCP protocols

• 11.4.4.20 through 11.4.4.42: RTP Serving Endpoint requirements
• 11.4.4.43 through 11.4.4.58: RTP Receiving Endpoint requirements
• 11.4.4.60 through 11.4.4.65: A/V Media Format Profiles in the context of RTP transmission
• 11.4.4.66 through 11.4.4.76: Adaptation of Audio-only and Audio component of A/V Media
Format
• 11.4.4.77 through 11.4.4.83: Guidelines for encapsulation of MPEG-2 streams
• 11.4.4.84 through 11.4.4.90: Guidelines for encapsulation of WMA and WMV elementary
streams
• 11.4.4.91 through 11.4.4.98: Guidelines for the encapsulation for AVC elementary streams
• 11.4.4.99 through 11.4.4.103: Guidelines for the encapsulation for MPEG-4 part 2 elementary
streams
• 11.4.4.104 through 11.4.4.113: Guidelines for the encapsulation of MPEG-4 AAC streams
• 11.4.4.114 through 11.4.4.117: Guidelines for the encapsulation of H.263 streams
• 11.4.4.118 through 11.4.4.121: Guidelines for the encapsulation AMR streams
• 11.4.4.122 through 11.4.4.127: Guidelines for the encapsulation AMR-WBplus streams, and
• 11.4.4.129 through 11.4.4.211: RTP Media Transport: RTSP/SDP
only when the RTP Media Transport is implemented.

[ATTRIBUTES ]

O A DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a 8QX8V

[C OMMENT] RTP is an optional media transport. If RTP is optionally implemented by Serving

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 584 –

Endpoints and Receiving Endpoints, the guidelines that follow in these Tables shall be implemented
as described.

RTP is recommended for certain applications, e.g. Streaming Transfer of live content.

11.4.4.3 MT RTP applicable Media Class

[G UIDELINE ] Serving Endpoints and Receiving Endpoints using this media transport shall use it
only for Audio or Audio/Video Media Classes

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a 58QX8

11.4.4.4 MT RTP on Serving Endpoints

[G UIDELINE ] Serving Endpoints shall comply with required features of RFC 3550 with constraints
and additions as specified in 11.4.4.20 through 11.4.4.42: RTP Serving Endpoint requirements .

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 7T63U

3550

[C OMMENT] Serving Endpoints in DLNA have no need to receive RTP packets.

11.4.4.5 MT RTP on Receiving Endpoints

11.4.4.5.1
[G UIDELINE ] Receiving Endpoints shall comply with required features of IETF RFC 3550 (RFC
3550) with constraints and additions as specified in 11.4.4.43 through 11.4.4.58: RTP Receiving
Endpoint requirements.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC R3RVS

3550

[C OMMENT] Receiving Endpoints in DLNA have no need to transmit RTP packets.

11.4.4.6 MT RTP RTSP/SDP

11.4.4.6.1
[G UIDELINE ] Serving Endpoints and Receiving Endpoints shall use RTSP and SDP as defined in
11.4.4.129 through 11.4.4.211: RTP Media Transport: RTSP/SDP.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a 77T63

[C OMMENT] Certain RTP session parameters, such as UDP port, RTP clock frequency and RTP
payload type, shall be communicated before RTP packets can be exchanged. These parameters
shall be communicated using RTSP and SDP as defined in 11.4.4.129 through 11.4.4.211: RTP
Media Transport: RTSP/SDP.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 585 –

11.4.4.7 MT RTP profile support

11.4.4.7.1
[G UIDELINE ] The following RTP profile shall be supported by Serving Endpoints and Receiving
Endpoints:

RTP Profile for Audio and Video Conferences with Minimal Control as defined in IETF RFC 3551,
also called RTP/AVP.

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC YR3RV
3550
IETF RFC
3551

11.4.4.7.2
[G UIDELINE ] The following RTP profile may optionally be supported by Serving Endpoints and
Receiving Endpoints:

Extended audio/visual profile for RTCP based feedback as defined in IETF RFC 4585 also called
RTP/AVPF.

[ATTRIBUTES ]

O L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 6R47M
4585

11.4.4.8 MT RTP Serving Endpoint DLNA Media Format Profile support

11.4.4.8.1
[G UIDELINE ] A Serving Endpoint shall support at least one "RTP support level" as detailed below
(in the rest of 11.4.4.8).

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a Y6R47

[C OMMENT] RTP support levels (A or B) enable better understanding of the extent to which Serving
Endpoints support RTP.

11.4.4.8.2
[G UIDELINE ] If a Serving Endpoint claims "RTP support level A" it shall support transmitting at least
one Media Format Profile over RTP.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a S5486

[C OMMENT] This is a very basic requirement: an RTP-capable Serving Endpoint shall be able to
stream at least something over RTP (otherwise it is simply not an RTP-capable Serving Endpoint).

11.4.4.8.3
[G UIDELINE ] If a Serving Endpoint claims "RTP support level B" for each Media Format Profile that
it supports transmitting over HTTP, it shall also support transmitting that Media Format Profile over
RTP.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 586 –

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a YS548

[C OMMENT] All devices of level B also satisfy level A.

This level of support avoids confusion by the end-user. If a level B Serving Endpoint supports a
certain set of media formats and it supports RTP, then RTP is supported for all these media formats.

11.4.4.9 MT RTP Receiving Endpoint DLNA Media Format Profile support

11.4.4.9.1
[G UIDELINE ] A Receiving Endpoint shall support at least one "RTP support level", as detailed
below.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a MBJYV

[C OMMENT] RTP support levels (A or B) enable better understanding of the extent to which a
Receiving Endpoint supports RTP.

RTP support levels are not signaled between the serving endpoints and the Receiving Endpoints.

11.4.4.9.2
[G UIDELINE ] If a Receiving Endpoint claims "RTP support level A", it shall support receiving at least
one Media Format Profile over RTP.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a 7MBJY

[C OMMENT] This is a very basic requirement: an RTP-capable Receiving Endpoint shall be able to
receive at least something over RTP (otherwise it is simply not an RTP-capable Receiving
Endpoint).

11.4.4.9.3
[G UIDELINE ] If a Receiving Endpoint claims "RTP support level B" for each Media Format Profile
that it supports receiving over HTTP, it shall also support receiving that Media Format Profile over
RTP.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a 7YFSY

[C OMMENT] All devices of level B are also satisfying level A.

This level of support avoids confusion by the end-user. If a level B Receiving Endpoint supports a
certain set of media formats and it supports RTP, then RTP is supported for all these media formats.

11.4.4.9.4
[G UIDELINE ] If a Receiving Endpoint claims "RTP support level B" and supports a Program Stream
based Media Format Profile (over RTP), then it shall also support the corresponding Elementary
Stream based Media Format Profile for transport over RTP. In particular:
DLNA guidelines; Part 1-1: Architecture and protocols
 – 587 –

• if Receiving Endpoint supports MPEG_PS_PAL, then it shall also support MPEG_ES_PAL;

• if Receiving Endpoint supports MPEG_PS_NTSC, then it shall also support MPEG_ES_NTSC;
• if Receiving Endpoint supports MPEG_PS_PAL_XAC3, then it shall also support
MPEG_ES_PAL_XAC3;
• if Receiving Endpoint supports MPEG_PS_NTSC_XAC3, then it shall also support
MPEG_ES_NTSC_XAC3.
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a K7YFS

[C OMMENT] This enables a Serving Endpoint to choose PS or ES encapsulation depending on

application requirements.

The ES based Media Format Profiles are defined for the RTP media transport only (not for HTTP
media transport).

11.4.4.10 MT RTP payload type definitions

[G UIDELINE ] Serving Endpoints shall use the payload type(s) defined in 11.4.4.60 through
11.4.4.65 when transmitting DLNA Media Format Profile content over RTP.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a WACXX

[C OMMENT] For each Media Format Profile exactly one RTP encapsulation is defined, except for
full TS with zero TTS. This implies that the RTP encapsulation can be inferred from the Media
Format Profile as carried in the 4th protocolInfo field except for full TS with zero TTS. Full TS with
zero TTS encapsulation can be determined using a=rtpmap in SDP.

Transport Stream and Program Stream based Media Format Profiles are encapsulated as a single
RTP stream, whereas other file formats (e.g. MP4, 3GPP) are encapsulated as two separate RTP
streams for AV.

11.4.4.11 MT RTP header timestamps during PLAY requests with Speed or Scale headers
11.4.4.11.1
[G UIDELINE ] A Serving Endpoint shall maintain RTP Header Timestamp values that correspond to
playback timing during scaled playback (i.e. a PLAY request with a Scale header with a value not
equal to 1) as defined in IETF RFC 2326, Appendix B. The output of the Serving Endpoint during
scaled playback shall be compliant with the syntax rules of the Media Format Profile. The values of
the RTP Header timestamps shall be compliant with the requirements for the RTP payload format in
use (e.g. video/MP2P, video/MP2T, or video/MPV).

For example, a Receiving Endpoint requests a Scale value of 2 for a PLAY request. The Serving
Endpoint could comply by dropping every other video frame (or utilize some other algorithm) while
maintaining the original frame rate of the content. Assuming a 90 kHz RTP Header timestamp clock
timebase and PS encapsulation, the RTP Header timestamp values would increase by 90 000 for
each second of playback, even though the NPT time reference would increase by 2 000 each
second.

As a further example, if the Scale value was −4 (backwards at 4 times the nominal playback rate),
the RTP Header timestamp values will also increase by 90 000 for each second, but the NPT time
reference would decrease by −4 000 during the same time period.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 588 –

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC SWACX

2326

[C OMMENT] This guideline clarifies the relationship between the RTP Header Timestamps and the
temporal scale of the content being transmitted when the Scale value is not equal to 1. (A Scale
value of 1 implies normal playback scale and direction). The output produced by scaling is
essentially a "normal" 1X sequence of RTP packets which would have RTP Header Timestamps that
are equivalent to a non-scaled content stream. This is expected be true regardless of the algorithm
used by the Serving Endpoint to generate the content.

For example, consider a Serving Endpoint A which implements a Scale value of 2 by dropping every
other frame in a 30 frames per second stream resulting in a content stream which still contains 30
frames per second, but which appears to be playing at twice the normal speed. Next consider
Serving Endpoint B which implements the same Scale value of 2 by sending 4 I-Frames a second
with a presentation time of 250 ms per frame, which will also appear to be playing twice as fast. In
both cases the RTP Header Timestamp values would increase by 90 000 each second.

11.4.4.11.2
[G UIDELINE ] A Serving Endpoint shall not change the RTP Header Timestamp values that
correspond to playback timing in response to a PLAY request with a Speed Header.

For example, a Receiving Endpoint requests a Speed value of 2 for a PLAY request. The Serving
Endpoint would transmit the content at twice the nominal playback rate while maintaining the
nominal RTP header timestamp values within each packet.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC TB44G

2326

[C OMMENT] This only applies to the RTP header timestamp and not to the wall clock as carried
within the RTP extension header.

11.4.4.11.3
[G UIDELINE ] If a PLAY request includes both Speed and Scale headers, the Serving Endpoint shall
satisfy the parameters of the Scale header, and then deliver the resultant sequence of RTP packets
to the network as specified in the Speed header.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC UTB44

2326

[C OMMENT] This guideline clarifies the order operations if both Scale and Speed headers are
included in a PLAY request. Details on the Scale and Speed headers can be found in 11.4.4.170
through 11.4.4.173.

11.4.4.12 MT RTP/RTCP shall use UDP transport

[G UIDELINE ] Serving Endpoints and Receiving Endpoints shall send and receive any RTP and
RTCP packets as UDP packets.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 589 –

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC B44G2
3550

11.4.4.13 MT RTP unicast support

[G UIDELINE ] Serving Endpoints and Receiving Endpoints shall support the transmission of RTP
and RTCP packets to unicast IP addresses.

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a ACXX8

11.4.4.14 MT RTP RTCP support required

[G UIDELINE ] RTCP shall be implemented as specified in RFC 3550 and as specified by the RTP
profile in use with the constraints defined in 11.4.4.2 through 11.4.4.58, and 11.4.4.129 through
11.4.4.211.

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC CXX84
3550

[C OMMENT] RTCP is necessary for rate control and synchronization of RTP streams.

11.4.4.15 MT RTP/RTCP UDP port number usage

[G UIDELINE ] RTP Media transport shall be done over an even RTP/UDP port number (i.e. 2n).
RTCP control shall be done over the next incremented UDP port number (i.e. 2n+1)

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 44G2V
3550

11.4.4.16 MT RTP unknown RTCP packet types

[G UIDELINE ] Serving Endpoints and Receiving Endpoints shall tolerate unknown RTCP packet
types.

Tolerate means that the endpoints shall be able to parse and interpret or parse and ignore such
packets.

[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC XX84R
3550

11.4.4.17 MT RTP RTCP simplified report interval calculation

11.4.4.17.1
[G UIDELINE ] RTCP reports shall be sent at the rate that is in accordance with the SDP provisions
(if any).

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 590 –

[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC YFSYN
3550

[C OMMENT] If SDP specifies an RTCP reporting rate, then this rate has the highest precedence.
(See 11.4.4.199.)

11.4.4.17.2
[G UIDELINE ] In the absence of SDP provisions any RTCP reports shall be generated and sent at
the rate that is in accordance to one of the following:

• the RTP profile (AVP or AVPF) in use;

• once every 5 s randomized within the interval [0,5, 1,5] times, such that the resulting RTCP
transmission interval is a random number in the interval [2,5, 7,5] s.
[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 4G2VZ
3550

[C OMMENT] The rules for calculating RTCP report intervals in RFC 3550 are complex to
accommodate large multicast sessions.

11.4.4.18 MT RTP version number

[G UIDELINE ] Serving Endpoints and Receiving Endpoints shall set the version number in the RTP
header to be 2. Serving Endpoints and Receiving endpoints shall accept RTP packets with versions
of 2.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC SYN4F
3550

11.4.4.19 MT RTP DLNAQOS RTCP traffic

11.4.4.19.1
[G UIDELINE ] If DLNAQOS as defined 8 is implemented, all RTCP messages generated by a
Serving Endpoint shall be tagged with DLNAQOS_2, or a lower DLNAQOS_UP value (where "or a
lower" is defined by 8.3.2.2.2 and 8.3.2.2.3), in accordance Table 7.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a n/a FSYN4

[C OMMENT] Because RTP is defined only for UDP, RTCP messages are not subject to the same
constraints as HTTP messages sent over TCP. RTCP requests do not have to be the same priority
that the server will use to deliver the content.

RTCP packets from a DMS will contain Sender Report (SR) messages when the server is streaming,
or Receiver Report (RR) messages when the server is idle. The SR and RR messages are important,
but arguably not any more important than the RTP packets, because if the network is experiencing
congestion, then the RTP stream has more serious problems than any information lost in these
messages (e.g. clock sync).

DLNA guidelines; Part 1-1: Architecture and protocols

 – 591 –

11.4.4.19.2
[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, all RTCP messages generated by a
Receiving Endpoint shall be tagged with DLNAQOS_3, or a lower DLNAQOS_UP value (where "or
a lower" is defined by 8.3.2.2.2 and 8.3.2.2.3), in accordance Table 7.

[ATTRIBUTES ]

M R DMP DMR M-DMP n/a n/a YV47A

[C OMMENT] All feedback messages are time critical, and especially important at times when the
DLNAQOS_2 RTP traffic is suffering from congestion.

RTCP messages sent by a DMP include Receiver Report (RR) messages and RTCP payload types
of 205 and 206. In the RTP/AVPF profile, RTCP payload type 205 is defined as a transport-layer
feedback message and 206 is defined as a payload-specific feedback message. This will cover not
only RTCP NACK messages, but also other kinds of RTCP-based feedback that we might want to
add in the future.

RTCP RR messages contain statistics about lost RTP packets, so they are time critical if the server
makes any decisions based on those statistics. Also, all RTCP packets that the client sends shall
include a RR message. Even if the client just wants to send a NACK, the RTCP packet shall also
include a RR message.

11.4.4.20 MT RTP timestamp offset

11.4.4.20.1
[G UIDELINE ] All RTP Timestamp values should have an Offset component which is a fixed 32-bit
value which is added to the RTP clock value as each RTP Timestamp is created.

[ATTRIBUTES ]

S C DMS +PU+ M-DMS n/a IETF RFC JYV47

3550

11.4.4.20.2
[G UIDELINE ] The Serving Endpoint may select an Offset value at the start of the RTP stream, and
this value shall be maintained throughout the RTP stream unless a Timestamp Discontinuity is
indicated.

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a IETF RFC 86GVI

3550

[C OMMENT] Some RTP payload formats allow a Timestamp Discontinuity to be indicated using the
"M" bit in the RTP packet header, or through other means.

11.4.4.21 MT RTP SSRC uniqueness: Serving Endpoints

[G UIDELINE ] Serving Endpoints shall ignore SSRC collisions.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 5486G

3550

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 592 –

[C OMMENT] RTP was designed for large multicast conferencing-type of applications.

SSRC collisions can occur in large conferences where multiple receivers/senders choose their own
SSRC.

In a unicast environment, the RTP Serving Endpoint shall ignore SSRC collisions and continue the
session with the negotiated SSRC values.

11.4.4.22 MT RTP Serving Endpoint RTP retransmission support

[G UIDELINE ] A Serving Endpoint may retransmit RTP packets if it and the Receiving Endpoint both
are using the RTP/AVPF profile.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC BJYV4

4585

11.4.4.23 MT RTP Serving Endpoint RTP retransmissions

11.4.4.23.1
[G UIDELINE ] A Serving Endpoint that retransmits RTP packets shall use one of the following two
retransmission methods.

• The retransmitted packet is formatted using the RTP payload format audio/rtx or video/rtx, in
accordance with IETF RFC 4588.
• The retransmitted packet is sent as an identical copy of the original packet and is sent to the
same UDP port as the original RTP packet.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 486GV

4588

[C OMMENT] For interoperability reasons, it is suggested that the Serving Endpoint implement both
transmission methods and chooses the one supported by the Receiving Endpoint, as announced in
11.4.4.158.

Implementation suggestion: If Serving Endpoint implements a buffering scheme for retransmissions,

any encoding rate adaptation techniques, such as bit stream switching, trans-rating and frame
skipping, it is recommended not to flush the retransmission buffer, as it can be difficult to
reconstruct the original data.

11.4.4.23.2
[G UIDELINE ] A Serving Endpoint that retransmits RTP packets should format the retransmitted
packet using the RTP payload format audio/rtx or video/rtx, in accordance with IETF RFC 4588.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC 7MJSW

4588

11.4.4.23.3
[G UIDELINE ] A Serving Endpoint that retransmits RTP packets may send the retransmitted packet
as an identical copy of the original packet, and it is sent to the same UDP port as the original RTP
packet.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 593 –

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC RVS55

4588

11.4.4.24 MT RTP packet size

11.4.4.24.1
[G UIDELINE ] A Serving Endpoint should limit the size of the RTP packet so that the size of the
entire packet including protocol headers will not exceed the Maximum Transmission Unit (MTU)
used in the home network.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC T63U3

1191

[C OMMENT] The purpose of this recommendation is to avoid IP Packet fragmentation and the
performance penalty associated with this.

A Serving Endpoint can determine the maximum MTU size for a given connection dynamically using
the algorithm described in RFC 1191. If the Serving Endpoint chooses not to, or is unable to
determine the size dynamically, it can assume an MTU of size of 1 492 B is safe.

11.4.4.24.2
[G UIDELINE ] A Serving Endpoint shall not select an RTP packet size in excess of 4 096 B.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 47MJS

1191

[C OMMENT] This provides the Receiving Endpoint with an upper limit on the size of an incoming
RTP packet.

11.4.4.25 MT RTP UDP port usage

11.4.4.25.1
[G UIDELINE ] If an RTP Media Format Profile encapsulation (see 11.4.4.60 through 11.4.4.65)
mandates that content be sent as multiple RTP streams, the Serving Endpoint shall support sending
them to the same (2n, 2n+1) UDP port pair, even if the Receiving Endpoint requests them to be the
same.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 3RVS5

3550

[C OMMENT] When RTSP is used, the Receiving Endpoint selects the UDP ports for each RTP
stream, and although not recommended by IETF RFC 3550, it can choose the same UDP port pair
for multiple RTP streams.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 594 –

11.4.4.25.2
[G UIDELINE ] If an RTP Media Format Profile encapsulation (see 11.4.4.60 through 11.4.4.65)
mandates that content be sent as multiple RTP streams, the Serving Endpoint shall support sending
them to different (2n, 2n+1) UDP port pairs.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC R47MJ

3550

[C OMMENT] This results in each RTP stream being sent on a different RTP session, which is
recommended by IETF RFC 3550.

11.4.4.26 MT RTP RTCP first sender report

[G UIDELINE ] A Serving Endpoint should transmit a sender report as soon as possible after sending
the first RTP packet of an RTP stream.

[ATTRIBUTES ]

S L DMS +PU+ M-DMS n/a IETF RFC 8VQ94

3550

[C OMMENT] This allows Receiving Endpoints to synchronize RTP streams.

11.4.4.27 MT RTP required RTCP SDES items

[G UIDELINE ] The only RTCP SDES item required is CNAME.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC VS556

3550

[C OMMENT] The CNAME item is required as per IETF RFC 3550, 6.1.

11.4.4.28 MT RTP RTCP BYE packets recommended

[G UIDELINE ] Serving endpoints should send an RTCP BYE packet when leaving an RTP session.

[ATTRIBUTES ]

S L DMS +PU+ M-DMS n/a IETF RFC Q2KAJ

3550

11.4.4.29 MT RTP RTCP Receiver Reports tolerance

[G UIDELINE ] Serving Endpoint shall tolerate RTCP Receiver Reports.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC X8VQ9

3550

11.4.4.30 MT RTP RTCP transmission interval in case of RTP translators

[G UIDELINE ] If a Serving Endpoint acts as an RTP translator, each received RTCP packet shall be
forwarded immediately upon packet arrival. The rule 11.4.4.17.2 shall not be applied.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 595 –

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 3U3AZ

3550

[C OMMENT] This rule is compliant to IETF RFC 3550 (RTCP processing in translators).

11.4.4.31 MT RTP uniqueness of RTP SSRC

[G UIDELINE ] Each RTP stream shall use a different SSRC.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC QX8VQ

3550

[C OMMENT] This is especially helpful to the Receiving Endpoint if multiple RTP streams are sent to
the same UDP port.

11.4.4.32 MT RTP Buffer Fullness Report processing

11.4.4.32.1
[G UIDELINE ] The Serving Endpoint may use Buffer Fullness Reports (BFRs) to compute the
average rate of depletion of the Receiving Endpoint's buffer.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a n/a 63U3A

[C OMMENT] This information can be used to detect network congestion and transrate the media
stream.

11.4.4.32.2
[G UIDELINE ] If BFRs indicate that the Receiving Endpoint's buffer levels are low, then the Serving
Endpoint may temporarily increase the transmission rate to fill the Receiving Endpoint's buffer.

Low buffer level is defined as being below the Target Buffer Duration value.

Temporarily increase the transmission rate means that the transmission rate increases until the
Serving Endpoint gets a report indicating the buffer level is equal to or greater than the Target Buffer
Duration value.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a n/a KAJB3

[C OMMENT] This can be used for faster startup and to make the Receiving Endpoint more tolerant
to network jitter.

11.4.4.32.3
[G UIDELINE ] If the Serving Endpoint changes the transmission rate in response to a BFR, RTP
timestamps shall not be adjusted to reflect the changed transmission rate.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 596 –

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 43SYB

11.4.4.33 MT RTP transmission rate adaptation

11.4.4.33.1
[G UIDELINE ] If the SETUP request included the Buffer-Info.dlna.org header (guideline 11.4.4.145),
and the parameter "BFR=1" was specified on that header, then the Serving Endpoint may perform
transmission rate adaptation.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a n/a 2KAJB

11.4.4.33.2
[G UIDELINE ] If the Serving Endpoint has indicated that transmission rate adaptation is possible
(guideline 11.4.4.208.1) and the Receiving Endpoint specified a Target Buffer Duration for an RTP
stream using the Buffer-Info.dlna.org header (guideline 11.4.4.145), then the Serving Endpoint may
perform transmission rate adaptation for the first Target Buffer Duration of NPT.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a n/a 3SYBK

[C OMMENT] Example: If the SETUP request included "TD=5000" on the Buffer-Info.dlna.org

header, the Serving Endpoint does not need to pace the data when transmitting the first 5 s worth of
data.

11.4.4.34 MT RTP Wall Clock Time samples

[G UIDELINE ] If a Receiving Endpoint requests the Serving Endpoint to add Wall Clock Time
samples using the RTSP header WCT.dlna.org, as described in guideline 11.4.4.166.1, then it is
strongly recommended for the Serving Endpoint to add Wall Clock Time samples to RTP packets
conforming to the guidelines 11.4.4.35 through 11.4.4.40 below.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a SVX64

[C OMMENT] The Wall Clock Time Sample denotes the actual transmission time of the RTP packet
very accurately.
This enables Receiving Endpoints to perform clock recovery to enable seamless A/V rendering.

It is up to the Receiving Endpoint whether it chooses to perform clock recovery or not. These
guidelines just strongly recommend that the Serving Endpoint does the minimum necessary to make
it possible.

For MPEG-2 TS or PS encapsulation, the RTP time stamps provide an alternate means for clock
recovery. However, RTP time stamps only denote the actual moment of transmission as accurately
as the pacing has been (i.e. 35 ms worst case), whereas the Wall Clock Time Sample is within
2,5 ms accurate. This enables more reliable clock recovery.

For encapsulation of elementary streams the RTP timestamps denote sample time and not
transmission time, making them unsuitable for clock recovery.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 597 –

11.4.4.35 MT RTP Wall Clock Time sample source

11.4.4.35.1
[G UIDELINE ] The Wall Clock Time samples in the RTP packets shall be obtained from the Wall
Clock Time source that is used for generating the NTP timestamp in the RTCP SR messages.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 5SVX6

1305
IETF RFC
3550

[C OMMENT] The RTCP SR contains a sample of the Wall Clock Time – "NTP timestamp" – when
the RTCP packet was sent, along with a sample of the clock generating the RTP timestamps for the
RTP stream involved.

This means that the respective RTCP Sender Reports for the different RTP streams (for this media
format) can be used to relate all RTP timestamps to the common Wall Clock Time.

This can in turn be used for inter-media synchronization (i.e. "lip sync").

Guidelines 11.4.4.34 through 11.4.4.40 effectively enable reconstruction of the serving endpoint
Wall Clock Time at the Receiving Endpoint, and thereby serve the same role as e.g. NTP in more
conventional RTP implementations.

11.4.4.35.2
[G UIDELINE ] The Wall Clock Time source shall be at least as accurate as specified by the System
Clock specification (if any) of the RTP payload content concerned.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 343SY

[C OMMENT] For example, with MPEG-2 content the 90 kHz clock source shall be accurate to within
± 30 parts per million (ppm) and have a slew rate of less than 0,075 Hz per second as defined in
13818-1.

11.4.4.36 MT RTP Wall Clock Time samples for all packets

[G UIDELINE ] If a Serving Endpoint adds Wall Clock Time samples, then they shall be added to each
RTP packet of each RTP stream associated with the media format being served.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a Z5SVX

[C OMMENT] Sampling the Wall Clock Time for each packet of each RTP stream results in the
largest number of clock samples per second.

For proper clock reconstruction it is advantageous to have as many samples per second as
possible.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 598 –

11.4.4.37 MT RTP Wall clock Time sample accuracy

[G UIDELINE ] The Wall Clock Time sample in an RTP packet shall represent the moment that the
packet is handed over to the network. The standard deviation of the distribution of the errors shall be
less than 2,5 ms.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC 64JRV

13818-9

[C OMMENT] Puts upper bound on additional jitter imposed by the serving endpoint's
implementation (i.e. "OS jitter"). Typically, network jitter will dominate over "OS jitter".

The RTP timestamps (Y axis) versus the actual arrival time on the network (X axis) will be plotted
against each other, and a line calculated using a [simple average / least mean squares] fitting
algorithm. The slope of the Calculated Line will be unity if the clock source is accurate. A positive or
negative slope will indicate a frequency error or "drift". The second derivative or "curve" of the line
represents the slew rate of the clock source.

For testing suggestions, this guideline needs to be tested by connecting a packet capturing device
directly to the Device Under Test (DUT) using a crossover Ethernet cable for IEEE 802.3 interfaces
and/or an IEEE 802.11 station or another access point in close proximity with no observable radio
interference. This will allow the arrival time on the network to be measured as accurately as possible
by minimizing the effect of network jitter. However, it needs to be noted that presence of network
jitter does not invalidate the accuracy of this test with respect to clock source accuracy.

The accuracy of the Wall Clock Time samples will be determined by comparing each Wall Clock
Time sample with the actual time the RTP packet is placed on the network as described in ISO/IEC
13818-9 over a period of 10 min. The slope of the Calculated Line (see Figure 23) using a least
mean squares will be used to determine accuracy of the Wall clock time samples.

The distribution of the distance between the observed samples and the Calculated Line (see Figure
23) shall be such that 2 standard deviations of the distribution is ±2,5 ms as shown below in Figure
24.

Figure 23 – Calculated Line

DLNA guidelines; Part 1-1: Architecture and protocols

 – 599 –

Figure 24 – Wall Clock Time sample accuracy distribution

11.4.4.38 MT RTP Wall Clock Time sample unaffected by Speed, Scale, and BFR
11.4.4.38.1
[G UIDELINE ] Wall Clock Time samples shall represent the "Actual" transmission time, irrespective
of whether the nominal transmission rate is used or not.

Transmission rates other than nominal can occur when

a) a rate other than 1,0 is requested by the use of the Speed header, or
b) transmission rate adaptation is performed as described in guidelines 11.4.4.208.2 and
11.4.4.208.4.
[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a n/a VX64J

[C OMMENT] The Wall Clock Time Sample will be unaffected by Scale header, Speed header, or
BFR, as it is not tied to the media stream in any way.

c) When the transmission rate is increased the Wall Clock Time samples of adjacent packets will
have smaller temporal distance compared to normal rate. When the transmission rate is
decreased the temporal distances will increase.
11.4.4.38.2
[G UIDELINE ] Wall Clock Time samples shall represent the "Actual" transmission time, irrespective
of whether the content is scaled (Scale header not 1) or not.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a n/a YBKM5

11.4.4.39 MT RTP Wall Clock Time sample representation

[G UIDELINE ] The middle 32 bits of the Wall Clock Time sample shall be stored in the RTP packet.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC B3TYK

1305
IETF RFC
3550

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 600 –

[C OMMENT] Use of the middle 32 bits reduces packet header overhead and is more commonly
used in IETF RFC 3550. It still features a resolution of about 65 kHz (same order of magnitude as
90 kHz RTP timestamps used for PS/TS encapsulation) and a wrap around time of about 18 h.

From IETF RFC 3550: Wall Clock Time (absolute date and time) is represented using the timestamp
format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January
1900. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer
part in the first 32 bits and the fractional part in the last 32 bits. In some fields where a more compact
representation is appropriate, only the middle 32 bits are used; that is, the low 16 bits of the integer
part and the high 16 bits of the fractional part. The high 16 bits of the integer part is determined
independently.

11.4.4.40 MT RTP Wall Clock Time Sample RTP header extension

11.4.4.40.1
[G UIDELINE ] The 32-bit Wall Clock Time sample in an RTP packet shall be encoded by means of a
header extension.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a X64JR

[C OMMENT] Header extensions offer full backward compatibility: an implementation that does not
recognize a header extension shall silently ignore it.

11.4.4.40.2
[G UIDELINE ] The X bit in the RTP header shall be set to "1" to indicate the presence of a header
extension.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC SYBKM

3550

11.4.4.40.3
[G UIDELINE ] For RTP streams using the RTP/AVP profile the "defined by profile" field in the header
extension header shall be set to 0x2356 to uniquely define this DLNA "Wall Clock Time Sample"
header extension.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a BKM5V

11.4.4.40.4
[G UIDELINE ] For RTP streams using the RTP/AVPF profile the "defined by profile" field in the
header extension header shall be set to 0x2356 to uniquely define this DLNA "Wall Clock Time
Sample" header extension.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a Q94XX

DLNA guidelines; Part 1-1: Architecture and protocols

 – 601 –

11.4.4.40.5
[G UIDELINE ] If no additional header extensions (in addition to Wall Clock Time Sample) are
required in the RTP packet header, the "length" field in the header extension header shall be set to
1 to indicate a single 32-bit word in the header extension contents.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a JB3TY

[C OMMENT] To cater to future needs, optionally, another header extension can follow the Wall
Clock Time Sample header extension. In this case the "length" field shall indicate the total length of
the header extension(s) following the header of the Wall Clock Time Sample header extension. Note
that future DLNA guidelines might apply this rule recursively. The case of a single Wall Clock Time
Sample header extension is illustrated in Figure 23. The case of another header extension following
it, is illustrated in Figure 24.

11.4.4.40.6
[G UIDELINE ] Another RTP header extension may follow the Wall Clock Time Sample header
extension, as described in IETF RFC 3550.

[ATTRIBUTES ]

O R DMS +PU+ M-DMS n/a IETF RFC AJB3T

3550

11.4.4.40.7
[G UIDELINE ] If another header extension follows the Wall Clock Time Sample header extension,
the "length" field in the Wall Clock Time Sample header extension header shall be set to the total
size of the header extension following it (including its header) plus 1 to indicate the single 32-bit
word in the Wall Clock Time Sample header extension contents as shown in Figure 25 and Figure
26.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a VQ94X

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 602 –

Figure 25 – Packet with Wall Clock Time Sample header extension

Figure 26 – Packet with another header extension following

Wall Clock Time Sample

DLNA guidelines; Part 1-1: Architecture and protocols

 – 603 –

11.4.4.41 MT RTP pacing of RTP packets

11.4.4.41.1
[G UIDELINE ] In the absence of network congestion, the Serving Endpoint shall be capable of
delivering individual RTP packets to the network within 35 ms of a valid "Target Transmission Time".
"Target Transmission Time" is defined in guideline 11.4.4.41.2 below.

The above does not apply when the Serving Endpoint performs transmission rate adaptation as
described in guidelines 11.4.4.208.2 and 11.4.4.208.4.

The accuracy of the RTP packet delivery will be determined by capturing the Observed Network
Arrival Time as defined in 11.4.4.37 and comparing it to a valid Target Transmission Time.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 566IS

[C OMMENT] The pace with which RTP packets are delivered to the network shall be such that no
pre-decoder buffer overflow can occur at the Receiving Endpoint.
This means that RTP packets shall be paced in accordance with the standard decoder buffer model
of the media format concerned. The standard decoder buffer model determines which are valid
delivery times – "Target Transmission Times" – for packets.

For TS/PS encapsulation a valid "Target Transmission Time" is present in the RTP timestamp (see
guideline 11.4.4.83).

For ES encapsulation the "Target Transmission Time" is not explicit in the packet, but can be
derived from the multiplex of the source material (if present).

35 ms is a hard limit, no packets are allowed to exceed these bounds.

11.4.4.41.2
[G UIDELINE ] For payload types other than the ones mentioned in 11.4.4.83, the "Target
Transmission Time" of an RTP packet shall be defined as the intended delivery time of the first byte
of its payload into the pre-decoder buffer of the Receiving Endpoint in a way that is consistent with
the standard decoder buffer model applicable to the payload type.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a U3AZW

11.4.4.42 MT RTP maximum reception packet rates

11.4.4.42.1
[G UIDELINE ] Upon reception of the header Max-Prate.dlna.org (see guideline 11.4.4.83), the
Serving Endpoint should understand this header and adjust (if necessary) the packet rate based on
the max-packet-rate parameter, in order to conform to the maximum packet rate capability of the
Receiving Endpoint.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a 94XXR

[C OMMENT] This rule recommends the Serving Endpoint not to exceed the maximum packet rate
specified by the Receiving Endpoint. Otherwise, the Receiving Endpoint might not be able to play all
packets
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 604 –

11.4.4.42.2
[G UIDELINE ] A Serving Endpoint that supports the Max-Prate.dlna.org header shall also
understand the feature tag dlna.Max-Prate (see guideline 11.4.4.157.2) in a Require header.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC AZWPN

2326

11.4.4.43 MT RTP interpret the P and X bits in the RTP header

[G UIDELINE ] Receiving Endpoints shall correctly interpret P bit and the X bit in the RTP packet
header.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 3AZWP

3550

[C OMMENT] If the P bit is 1, the Receiving Endpoint shall remove the padding before processing
the packet.

If the X bit is 1, the Receiving Endpoint shall correctly parse the packet and process any headers
that it understands, and tolerate any other headers.

11.4.4.44 MT RTP tolerate CSRC fields in the RTP header

[G UIDELINE ] Receiving Endpoints shall tolerate contributing sources (CSRCs) in the RTP packet
header.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 5566I

3550

[C OMMENT] Contributing sources are created only by RTP mixers, which are not required by DLNA.

11.4.4.45 MT RTP SSRC uniqueness: Receiving Endpoints

[G UIDELINE ] Receiving Endpoints shall ignore SSRC collisions.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC MJSWV

3550

[C OMMENT] RTP was designed for large multicast conferencing-type of applications.

SSRC collisions can occur in large conferences where multiple receivers/senders choose their own
SSRC.

In a unicast environment, the RTP Receving Endpoint shall ignore SSRC collisions and continue the
session with the negotiated SSRC values.

11.4.4.46 MT RTP expect random starting RTP sequence number

[G UIDELINE ] A Receiving Endpoint shall accept an arbitrary starting sequence number.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 605 –

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC S5566

3550

[C OMMENT] Subclause 5.1 of IETF RFC 3550 recommends random starting sequence numbers, so
Receiving Endpoints shall expect a random starting sequence number.

11.4.4.47 MT RTP expect random starting RTP timestamp

[G UIDELINE ] A Receiving Endpoint shall accept an arbitrary starting RTP timestamp.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC JSWVF

3550

[C OMMENT] Subclause 5.1 of IETF RFC 3550 recommends random starting RTP timestamps, so
Receiving Endpoints shall expect a random starting timestamp.

11.4.4.48 MT RTP required RTCP SDES items

[G UIDELINE ] The only RTCP SDES item required is CNAME.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC VIW5Y

3550

[C OMMENT] The CNAME item is required as per IETF RFC 3550, 6.1.

11.4.4.49 MT RTP robust handling of RTCP BYE packet

[G UIDELINE ] A Receiving Endpoint shall either accept or gracefully discard RTP data packets
received after the reception of the RTCP BYE packet.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 6GVIW

3550

[C OMMENT] BYE packets can be received before or after the transmission of RTP packets has
actually ended because of network reordering or retransmission.

11.4.4.50 MT RTP unknown RTP extensions

[G UIDELINE ] Receiving Endpoints shall tolerate RTP header extensions they do not support.

Tolerate means that the Receiving Endpoint is able to "parse and interpret" or "parse and ignore"
header extensions.

[ATTRIBUTES ]

M R DMP DMR M-DMP n/a IETF RFC SWVFR

3550

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 606 –

11.4.4.51 MT RTP out of order RTP packets and jitter conditions

11.4.4.51.1
[G UIDELINE ] Receiving Endpoints receiving RTP packets shall accept out-of-order packets.

"Shall accept" means that the Receiving Endpoint is able to "receive and reorder" or "receive and
ignore" header extensions.

[ATTRIBUTES ]

M R DMP DMR M-DMP n/a IETF RFC 47AI8

3550

11.4.4.51.2
[G UIDELINE ] A Receiving Endpoint should be capable of processing RTP packets that arrive with
up to 200 ms of total jitter.

[ATTRIBUTES ]

S C DMP DMR M-DMP n/a IETF RFC GVIW5

3550

[C OMMENT] This jitter is the sum of the OS jitter (which is 35 ms) plus the network induced jitter.

11.4.4.51.3
[G UIDELINE ] If a Receiving Endpoint sends Buffer Fullness Reports, it shall tolerate variable rate
transmission of RTP packets for a period up to the duration of the Receiving Endpoint's buffer.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC YN4FN

3550

11.4.4.52 MT RTP/AVPF support

[G UIDELINE ] A Receiving Endpoint may use the RTP/AVPF profile, and send RTCP-based
feedback messages of the types that Serving Endpoint has indicated are acceptable.

[ATTRIBUTES ]

O C DMP DMR M-DMP n/a IETF RFC V47AI

4585

[C OMMENT] The Serving Endpoint uses SDP to indicate if RTP/AVPF is used, and which feedback
message types are acceptable.

11.4.4.53 MT RTP retransmission requests

[G UIDELINE ] If the RTP/AVPF profile is used, and if the Serving Endpoint has indicated that RTCP
nack feedback messages are acceptable, then the Receiving Endpoint shall use RTCP nack
feedback message to request any desired RTP packet retransmissions.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 7AI8E

4585

DLNA guidelines; Part 1-1: Architecture and protocols

 – 607 –

11.4.4.54 MT RTP audio/rtx and video/rtx support

11.4.4.54.1
[G UIDELINE ] A Receiving Endpoint which requests retransmission of RTP packets should support
the audio/rtx and video/rtx RTP payload formats for retransmitted packets.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC 4FNJE

4588

11.4.4.54.2
[G UIDELINE ] A Serving Endpoint that supports the audio/rtx and video/rtx RTP payload formats for
retransmitted packets shall use the SSRC-multiplexing method described in Clause 5 of IETF RFC
4588 and shall not use the session-multiplexing method (also described in Clause 5 of IETF RFC
4588).

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 84R9I

4588

11.4.4.55 MT RTP packets that are retransmitted as identical copies

[G UIDELINE ] A Receiving Endpoint which requests retransmission of RTP packets may support
that RTP packets are retransmitted as identical copies of the original RTP packets.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a n/a N4FNJ

11.4.4.56 MT RTP rules for counting RTP packets when retransmission requests are
supported
11.4.4.56.1
[G UIDELINE ] A Receiving Endpoint which requests the retransmission of an RTP packet using an
RTCP nack feedback message, shall count that packet as a lost packet in RTCP Receiver Reports,
even if the RTP packet is subsequently received.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a X84R9

11.4.4.56.2
[G UIDELINE ] A Receiving Endpoint which requests the retransmission of an RTP packet using an
RTCP nack feedback message, shall not include that packet when computing the value for the
"interarrival jitter" field in RTCP Receiver Reports, even if the RTP packet is subsequently received.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a 4R9IZ

11.4.4.57 MT RTP Buffer Fullness Reports

11.4.4.57.1
[G UIDELINE ] If the RTP/AVPF profile is used, and if the Serving Endpoint has indicated that RTCP
bfr feedback messages are acceptable, then the Receiving Endpoint should include Buffer Fullness
Reports (BFR's) with all RTCP Receiver Reports that it sends.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 608 –

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC VZTX5

4585

[C OMMENT] BFR's can be used to detect network congestion and ensure the RENEDERING
ENDPOINTS jitter buffer remains full.

11.4.4.57.2
[G UIDELINE ] A Receiving Endpoint that sends BFR's shall send them at the rate that is in
accordance with SDP provisions (if any).

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC G2VZT

3556

[C OMMENT] See guideline 11.4.4.204.2 for SDP provisions that define the rate at which BFRs shall
be sent. The Serving Endpoint requires BFR's to be sent at this rate to detect congestion.

11.4.4.57.3
[G UIDELINE ] A Receiving Endpoint that sends BFRs shall use the following syntax.

• An RTCP feedback message as defined in RTP/AVPF IETF RFC 4585, 6.1 shall be used.
• The FMT field shall be set to 3 indicating the BFR feedback message type.
• The PT field shall be set to 205 indicating a transport layer feedback message.
• The feedback control information (FCI) section consists of ten fields. The fields shall occur in the
FCI in the order listed below.
• N1: (32 bits) shall be set to the number of free bytes in the Receiving Endpoint's network de-jitter
buffer.
• N2: (32 bits) shall be set to the current size, in bytes, of the Receiving Endpoint's network
de-jitter buffer. The current size is the current maximum size and not the current utilization or
amount of data in the buffer.
• N3: (16 bits) shall be set to the amount of data queued in the Receiving Endpoint's network
de-jitter buffer counted in milliseconds. If this information is not available, this field shall be set
to 0xFFFF. If the amount of data is more than 65 534 ms, the fields shall be set to 0xFFFE.
• Playout Delay: (16 bits) Shall be set to the difference between the scheduled playout time of the
next ADU (Application Data Unit) to be transferred to the coded data buffer or decoded if coded
data buffer is not presented and the time of sending the BFR, as measured by the media playout
clock, expressed in milliseconds. If this information is not available, the Receiving Endpoint
shall set this value to 0xFFFF. In case of an empty buffer, the playout delay is not defined and
the field shall be set to 0xFFFF.
• NSN: (16 bits) shall be set to the RTP sequence number of the next ADU to be transferred or
decoded for the SSRC reported on. In the case where the buffer does not contain any packets
for this SSRC, the next not yet received RTP sequence number shall be reported, i.e. an NSN
value that is one larger than the least significant 16 bits of the RTCP SR or RR report block's
"extended highest sequence number received".
• NUN: (16 bits) shall be set to the unit number (within the RTP packet) of the next ADU to be
transferred or decoded as defined in the payload format subclause of these guidelines,
11.4.4.60 through 11.4.4.65, for the given RTP payload format. The first unit in a packet has a
unit number equal to zero. The unit number is incremented by one for each ADU in an RTP
DLNA guidelines; Part 1-1: Architecture and protocols
 – 609 –

packet. In the case of RTP payload formats where each packet carries a single ADU, or where
the ADU is not defined, the NUN field shall be set to zero.
• D1: (32 bits) shall be set to the number of free bytes in the Receiving Endpoint's coded data
buffer, or 0 if the pre-decoder buffer is combined with the network de-jitter buffer. The field shall
be set to 0 if the RTSP Buffer-Info.dlna.org header did not provide a size for the coded data
buffer.
• D2: (32 bits) shall indicate the current size, in bytes, of the Receiving Endpoint's coded data
buffer, or 0 if the pre-decoder buffer is combined with the network de-jitter buffer. The field shall
be set to 0 if the RTSP Buffer-Info.dlna.org header did not provide a size for the coded data
buffer.
• D3: (16 bits) shall be set to the amount of data queued in the Receiving Endpoint's coded data
buffer counted in milliseconds. If this information is not available, this field shall be set to
0xFFFF. If the amount of data is more than 65 534 ms, the fields shall be set to 0xFFFE.
• TD: (16 bits) shall be set to the current value of Target Buffer Duration, as defined in guideline
11.4.4.145. The field shall be set to 0 if the Buffer-Info.dlna.org header was not included in the
RTSP SETUP request, or if the "TD" parameter on that header was not present.
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC ZTX53

4585

[C OMMENT] The fields N2 and D2 are necessary because the Receiving Endpoint can decide to
increase the sizes of these buffers as a result of headers in the PLAY response, or as a result of
network congestion, for example.
See Figure 26 for more information.

The definition of Application Data Unit is specific to each RTP payload format. See definitions in
11.4.4.60 through 11.4.4.65, and the comments about the NUN field, below.

In the two-buffer model where no RTP header is available in the coded data buffer, the reported
NSN and the associated playout delay and NUN shall use the next to be transferred RTP packet's
sequence number in the transmission (network) jitter buffer.

For the NUN field:

for example in the case of H.264 (AVC), an ADU is defined as a NAL unit and for audio profiles, an
ADU is an audio frame.

In the case of RTP payload formats where each packet carries a single ADU (for example H.263 and
MPEG-4 Visual Simple Profile) the NUN field will be set to zero.

MPEG-2 PS streams consist of a stream of bytes without payload-level framing. Therefore NUN
shall always be 0 for such streams.

Future additions of media encoding or transports capable of having more than one ADU in each RTP
payload shall define what shall be counted as an ADU for this format.

A BFR packet format is shown in Figure 27.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 610 –

Figure 27 – BFR packet format

11.4.4.58 MT RTP tolerate Wall Clock Time Sample RTP header extension
[G UIDELINE ] Receiving Endpoint shall tolerate the Wall Clock Time sample RTP header extension
as defined in guidelines 11.4.4.34 through 11.4.4.40.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 5398X

3550

[C OMMENT] IETF RFC 3550 already mandates RTP header extensions be silently ignored if they
cannot be interpreted.

The aim of the referenced guidelines is for a Receiving Endpoint to actively use the Wall Clock Time
samples to perform clock recovery. As stated before, this is not mandatory.

11.4.4.59 RTP Media Transport: adaptation of Media Format Profiles – General

Reference IEC 62481-2 specifies audio, video, and encapsulation characteristics for media content
that conforms to the list of DLNA mandatory and optional Media Format Profiles when the transport
protocol is HTTP. 11.4.4.60 through 11.4.4.65 uses reference IEC 62481-2 as the basis, and
defines additional constraints and requirements necessary to reuse the Profile ID values and
exchange content using RTP. This subclause describes an adaptation layer or filtering layer to tailor
the Media Format Profiles defined in IEC 62481-2 for usage over RTP.

11.4.4.60 MT RTP Profile ID usage

[G UIDELINE ] For transport over RTP, A/V content shall use the same Profile ID values defined in
IEC 62481-2.

[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 IZ5XA

DLNA guidelines; Part 1-1: Architecture and protocols

 – 611 –

11.4.4.61 MT RTP MPEG-2 Media Format Profiles

11.4.4.61.1
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-2 video with any type of companion audio;

• Full Single Program Transport Stream encapsulation;
• DLNA Transport Packets without Timestamp fields (188 byte ISO profiles).
The RTP encapsulation shall use either

• the payload format MP2T as defined in IETF RFC 2250 and IETF RFC 3555 with constraints in
guideline 11.4.4.78, or
• the payload format vnd.dlna.mpeg-mp2t as defined in guideline 11.4.4.79.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 NJEQX
IETF RFC
2250

[C OMMENT] Full Single Program Transport Streams with zero TTS carrying MPEG-2 Media Format
Profiles.

11.4.4.61.2
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-2 video with any type of companion audio;

• Partial Single Program Transport Stream encapsulation;
• DLNA Transport Packets without Timestamp fields (188 byte ISO profiles).
The RTP encapsulation shall use payload format vnd.dlna.mpeg-mp2t as defined in guideline
11.4.4.79.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 AI8EX

[C OMMENT] Partial Single Program Transport Streams with zero TTS carrying MPEG-2 Media
Format Profiles.

11.4.4.61.3
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-2 video with any type of companion audio;

• Partial or Full Single Program Transport Stream encapsulation;
• Non-zero TTS.
The RTP encapsulation shall use payload format vnd.dlna.mpeg-tts as defined in guideline
11.4.4.80.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 612 –

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 X5398

[C OMMENT] Partial or Full Single Program Transport Streams with non-zero TTS carrying MPEG-2
Media Format Profiles.

11.4.4.61.4
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-2 video with any type of companion audio;

• Program Stream encapsulation.
The RTP encapsulation shall use payload format MP2P as defined in IETF RFC 2250 and IETF RFC
3555.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 9IZ5X
IETF RFC
2250
IETF RFC
3555

[C OMMENT] Program Streams carrying MPEG-2 Media Format Profiles.

11.4.4.61.5
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-2 video with any type of companion audio;

• MPEG-2 Elementary Stream encapsulation IETF RFC 2250.
The RTP encapsulation for video shall use payload format MPV as defined in IETF RFC 2250 and
the RTP encapsulation for audio shall comply with 11.4.4.66 through 11.4.4.76.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 FNJEQ
IETF RFC
2250

[C OMMENT] MPEG-2 Elementary Streams carrying MPEG-2 Media Format Profiles.

11.4.4.62 MT RTP AVC Media Format Profiles

11.4.4.62.1
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• AVC video with any type of companion audio;

• Full Single Program Transport Stream encapsulation;
• DLNA Transport Packets without Timestamp fields (188 byte ISO profiles).
The RTP encapsulation shall use either

DLNA guidelines; Part 1-1: Architecture and protocols

 – 613 –

• the payload format MP2T as defined in IETF RFC 2250 and IETF RFC 3555 with constraints in
guideline 11.4.4.78, or
• the payload format vnd.dlna.mpeg-mp2t as defined in guideline 11.4.4.79.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 TX539
IETF RFC
2250

[C OMMENT] Full Single Program Transport Streams with zero TTS carrying AVC Media Format
Profiles.

11.4.4.62.2
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• AVC video with any type of companion audio;

• Partial Single Program Transport Stream encapsulation;
• DLNA Transport Packets without Timestamp fields (188 B ISO profiles).
The RTP encapsulation shall use payload format vnd.dlna.mpeg-mp2t as defined in guideline
11.4.4.79 with the following additional constraints. The TS packet size shall be 188 B and the 4 B
TTS defined in IEC 62481-2 shall be excluded.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 R9IZ5

[C OMMENT] Partial Single Program Transport Streams with zero TTS carrying AVC Media Format
Profiles.

11.4.4.62.3
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• AVC video with any type of companion audio;

• Partial or Full Single Program Transport Stream encapsulation;
• Non-zero TTS.
The RTP encapsulation shall use payload format vnd.dlna.mpeg-tts as defined in guideline
11.4.4.80.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 Z5XAW

[C OMMENT] Partial or Full Single Program Transport Streams with non-zero TTS carrying AVC
Media Format Profiles.

11.4.4.62.4
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 614 –

• AVC video with any type of companion audio;

• Profile ID indicating MP4 or 3GPP encapsulation.
When these Profile ID values are used in conjunction with RTP all of the following shall apply.

• Audio and Video shall be encapsulated as elementary streams (no use of the MPEG-4 file format
or 3GPP file format).
• The RTP encapsulation for video shall use payload format H264 IETF RFC 3984 with
constraints in 11.4.4.91 through 11.4.4.98.
• The RTP encapsulation for audio shall comply with 11.4.4.66 through 11.4.4.76.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 JEQXQ
IETF RFC
3984

[C OMMENT] AVC Media Format Profiles that indicate MP4 or 3GPP encapsulation.

11.4.4.63 MT RTP MPEG-4 Part 2 Media Format Profiles

11.4.4.63.1
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-4 Part 2 video with any type of companion audio;

• Full Single Program Transport Stream encapsulation;
• DLNA Transport Packets without Timestamp fields (188 byte ISO profiles).
The RTP encapsulation shall use either

• the Payload format MP2T (IETF RFC 2250, IETF RFC 3555) with constraints in 11.4.4.78, or
• the Payload format vnd.dlna.mpeg-mp2t as defined in guideline 11.4.4.79.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 I8EXF
IETF RFC
2250

[C OMMENT] Full Single Program Transport Streams with zero TTS carrying MPEG-4 Part 2 Media
Format Profiles.

11.4.4.63.2
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-4 Part 2 video with any type of companion audio;

• Partial Single Program Transport Stream encapsulation;
• DLNA Transport Packets without Timestamp fields (188 B ISO profiles).
The RTP encapsulation shall use payload format vnd.dlna.mpeg-mp2t as defined in guideline
11.4.4.79.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 615 –

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 IW5Y5

[C OMMENT] Partial Single Program Transport Streams with zero TTS carrying MPEG-4 Part 2
Media Format Profiles.

11.4.4.63.3
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-4 Part 2 video with any type of companion audio;

• Partial or Full Single Program Transport Stream encapsulation;
• Non-zero TTS.
The RTP encapsulation shall use payload format vnd.dlna.mpeg-tts as defined in guideline
11.4.4.80 with the following additional constraints. The TS packet size shall be 192 B and the 4 B
TTS defined in IEC 62481-2 shall be included.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 EQXQ6

[C OMMENT] Partial or Full Single Program Transport Streams with non-zero TTS carrying MPEG-4
Part 2 Media Format Profiles.

11.4.4.63.4
[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• MPEG-4 Part 2 video with any type of companion audio;

• Profile ID indicating MP4 or ASF encapsulation.
When these Profile ID values are used in conjunction with RTP all of the following shall apply.

• Audio and Video shall be encapsulated as elementary streams (no use of the MPEG-4 or ASF
file format).
• The RTP encapsulation for video shall use payload format mpeg4-generic IETF RFC 3640 with
constraints in 11.4.4.99 through 11.4.4.103: Guidelines for the encapsulation for MPEG-4 part 2
elementary streams.
• The RTP encapsulation for audio shall comply with 11.4.4.66 through 11.4.4.76.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 8EXFY
IETF RFC
3640

[C OMMENT] MPEG-4 Part 2 Media Format Profiles that indicate MP4 or ASF encapsulation.

11.4.4.64 MT RTP H.263 Media Format Profiles

[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 616 –

• H.263 video with any type of companion audio;

• Profile ID indicating MP4 encapsulation.
When these Profile ID values are used in conjunction with RTP all of the following shall apply.

• Audio and Video shall be encapsulated as elementary streams (no use of the MPEG-4 file
format).
• The RTP encapsulation for video shall use payload format H263-2000 IETF RFC 3555,
IETF RFC 2429 with constraints in 11.4.4.114 through 11.4.4.117: Guidelines for the
encapsulation of H.263 streams.
• The RTP encapsulation for audio shall comply with 11.4.4.66 through 11.4.4.76.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC W5Y5T
3555
IEC 62481-2
IETF RFC
2429

[C OMMENT] H.263 Media Format Profiles that indicate MP4 encapsulation.

11.4.4.65 MT RTP WMV Media Format Profiles

[G UIDELINE ] For A/V Profile ID values in IEC 62481-2 for which the following holds:

• WMV video with any type of companion audio;

• Media Format Profiles indicating use of ASF encapsulation.
When these Profile ID values are used in conjunction with RTP all of the following shall apply.

• Audio and Video shall be encapsulated as elementary streams (no use of the ASF file format).
• The RTP encapsulation for video shall use payload format WMV RTP Payload format with
constraints in guideline 11.4.4.84 through 11.4.4.90.
• The RTP encapsulation for audio shall comply with 11.4.4.66 through 11.4.4.76.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 Y5T9R
RTP Payload
format

[C OMMENT] WMV Media Format Profiles.

11.4.4.66 MT RTP Media Format Profile ID usage

[G UIDELINE ] For transport over RTP, Audio-only content shall use the same Profile ID values
defined in IEC 62481-2.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 EXFYZ

11.4.4.67 MT RTP Audio Elementary Streams of A/V Media Format Profiles

[G UIDELINE ] Audio components of A/V profiles in IEC 62481-2 transmitted over RTP as separate
elementary streams shall follow the adaptation guidelines defined in 11.4.4.66 through 11.4.4.76.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 617 –

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 5Y5T9

11.4.4.68 MT RTP Elementary Streams of Audio-only Media Format Profiles

[G UIDELINE ] Audio content of Audio-only profiles in IEC 62481-2 shall be transmitted over RTP as
elementary streams using the adaptation guidelines defined in 11.4.4.66 through 11.4.4.76.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IEC 62481-2 RXG3B

11.4.4.69 MT RTP LPCM Media Format Profiles

[G UIDELINE ] The RTP encapsulation for LPCM shall use payload format L16 IETF RFC 3551.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC ISH26
3551

11.4.4.70 MT RTP MP3,MP3X, MPEG-2 L2 Media Format Profiles

[G UIDELINE ] The RTP encapsulation for MP3, MP3X, and MPEG-2 L2 shall use payload format
MPA IETF RFC 2250.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC WPN9Z
2250

11.4.4.71 MT RTP AC3, XAC3 Media Format Profiles

[G UIDELINE ] The RTP encapsulation for AC-3 and XAC3 shall use payload format ac3 IETF RFC
4184.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a ATSC 4XXRY

Standard
IETF RFC
4184

11.4.4.72 MT RTP AAC, HE-AAC Media Format Profiles

[G UIDELINE ] The RTP encapsulation for AAC and HE-AAC shall use payload format
mpeg4-generic IETF RFC 3640 with constraints in 11.4.4.104 through 11.4.4.113: Guidelines for
the encapsulation of MPEG-4 AAC streams.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC FRXG3
3640

11.4.4.73 MT RTP G726 Media Format Profiles

[G UIDELINE ] The RTP encapsulation for G726 shall use payload format G726-32 IETF RFC 3551.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 618 –

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 6ISH2
3551

11.4.4.74 MT RTP WMA Media Format Profiles

[G UIDELINE ] The RTP encapsulation for WMA shall use payload format WMA RTP Payload format
with constraints in 11.4.4.84 through 11.4.4.90.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a RTP Payload ZWPN9
format

11.4.4.75 MT RTP AMR Media Format Profiles

[G UIDELINE ] The RTP encapsulation for AMR shall use payload format AMR IETF RFC 3267 with
constraints in 11.4.4.118 through 11.4.4.121.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC VFRXG
3267
IEC 62481-2

11.4.4.76 MT RTP AMR- WBPlus Media Format Profiles

[G UIDELINE ] The RTP encapsulation for AMR-WBplus shall use payload format AMR-WB+
IETF RFC 4352 with constraints in 11.4.4.122 through 11.4.4.127.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 66ISH
4352
IEC 62481-2

11.4.4.77 MT RTP Payload Formats for MPEG TS encapsulated content

11.4.4.77.1
[G UIDELINE ] The guidelines in 11.4.4.77 apply to guidelines 11.4.4.78, 11.4.4.79 and 11.4.4.80.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a ISO/IEC WVFRX

13818-1
IETF RFC
2250

11.4.4.77.2
[G UIDELINE ] All RTP Timestamps for MPEG TS encapsulated content will be in 90 kHz clock units.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC SH26Q

2250

11.4.4.77.3
[G UIDELINE ] The 90 kHz clock utilized as the basis for the RTP Header Timestamp field shall be
synchronized with the MPEG System Clock of the content.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 619 –

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a ISO/IEC PN9ZA

13818-1
IETF RFC
2250

11.4.4.77.4
[G UIDELINE ] The RTP Timestamp values may differ from the MPEG
program_clock_reference_base value in the PCR field.

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a IETF RFC XXRYP

2250

11.4.4.77.5
[G UIDELINE ] An ADU (Application Data Unit) shall be one complete TS packet as specified in the
guidelines for the RTP payload format in use.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 3TYKK
2250

[C OMMENT] The size of a TS packet differs depending on the RTP payload format in use.

11.4.4.78 MT RTP MP2T RTP Payload format definition

11.4.4.78.1
[G UIDELINE ] The MP2T RTP Payload format can only be used to transfer Full SPTS streams in
RTP. If this RTP Payload format definition is used, the RTP packets shall meet the following
guidelines.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC N9ZAL

2250

[C OMMENT] This RTP payload format definition is a strict definition of IETF RFC 2250 using Full
SPTS streams.

11.4.4.78.2
[G UIDELINE ] Each MPEG TS Packet shall be 188 B in length and conform to the requirements of
ISO/IEC 13818-1. The MP2T Payload format can only be utilized with DLNA Media Format Profiles
that utilize MPEG2 TS encapsulation and have 188 byte TS Packets. Specifically MP2T is not a
valid RTP payload format for DLNA Media Format Profiles utilizing the 192 byte TS packet syntax.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a ISO/IEC XRYPY

13818-1

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 620 –

11.4.4.78.3
[G UIDELINE ] The RTP Timestamp shall represent the ideal transmission time of the first byte of the
first MPEG TS Packet contained within the RTP Payload as defined in IETF RFC 2250 and further
clarified below.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC KM5VI

2250

11.4.4.78.4
[G UIDELINE ] The ideal transmission time of the first byte of an MPEG2 TS Packet shall be
calculated as follows:

TSTimestampY = Offset + 90KHZX + ((∆T PCR / N) × I)

where

I is the Index value of the TS Packet relative to the last TS Packet containing a PCR value. The first
TS Packet after a PCR value will have an Index of 1, the second TS Packet an Index of 2, and so on.

N is the Number of TS Packets between TS Packets with PCR values plus one for the TS Packet
with the PCR value. For example, if a SPTS has 2 000 TS Packets per second, and PCR values
occur every 100 ms, the value of N would be 200.

90KHZX is the value of the 90 kHz clock associated with the last TS Packet containing a PCR value.

∆T PCR is the Delta time value between PCR values as defined in 3.2.

Offset is the RTP Timestamp Offset as defined in 11.4.4.20.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a n/a YKK6T

11.4.4.78.5
[G UIDELINE ] The Serving Endpoint shall utilize either a static Payload ID of "33" or a dynamic
Payload Format of "MP2T" in the SDP Media Description Fields as defined in 11.4.4.195.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a n/a M5VI8

11.4.4.79 MT RTP vnd.dlna.mpeg-mp2t RTP Payload format definition

11.4.4.79.1
[G UIDELINE ] The vnd.dlna.mpeg-mp2t RTP Payload format definition can be used to transfer
Partial or Full SPTS streams in RTP. If this TS Payload definition is used, the RTP packets shall
meet the following guidelines 11.4.4.79.2, 11.4.4.79.3 and 11.4.4.79.4.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a n/a 4JRVZ

[C OMMENT] This RTP TS Payload format definition is a looser definition of IETF RFC 2250 MP2T
that allows both Partial and Full SPTS streams. The RTP Timestamp calculations are identical even
though the temporal relationship between any two adjacent TS Packets is not always the same.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 621 –

11.4.4.79.2
[G UIDELINE ] This payload format definition is identical to MP2T as defined in guideline 11.4.4.78.2,
except for the name, and that it can also be used to carry partial SPTS streams.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a n/a RYPY6

11.4.4.79.3
[G UIDELINE ] The RTP Packet Timestamp shall be calculated in the same manner as described in
11.4.4.78.3 and 11.4.4.78.4 for the MP2T Payload format definition.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a n/a KK6T3

11.4.4.79.4
[G UIDELINE ] The Serving Endpoint shall utilize a dynamic Payload Format of vnd.dlna.mpeg-mp2t
in the SDP Media Description Fields as defined in 11.4.4.195.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a n/a 5VI84

11.4.4.79.5
[G UIDELINE ] To reduce jitter on the transmission of PCR timestamps, the Serving Endpoint should
send RTP packets as soon as it contains a TS packet with a PCR, without waiting for the maximum
payload size to be reached.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a JRVZQ

11.4.4.80 MT RTP vnd.dlna.mpeg-tts RTP Payload format definition

11.4.4.80.1
[G UIDELINE ] The vnd.dlna.mpeg-tts RTP Payload format definition can be used to transfer Partial
or Full SPTS streams in RTP. If this RTP Payload format definition is used, the RTP packets shall
meet guidelines 11.4.4.80.2, 11.4.4.80.7 and 11.4.4.80.8.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a VI84D

[C OMMENT] This RTP Payload format definition is designed to preserve individual TS Packet
timing references in a Partial SPTS stream.

11.4.4.80.2
[G UIDELINE ] The vnd.dlna.mpeg-tts RTP Payload format definition can only be utilized with DLNA
Media Format Profiles that utilize MPEG2 TS encapsulation and have 192 byte TS Packets. It shall
be used for DLNA Media Format Profiles utilizing the DLNA-defined 192 byte TS packet format with
timestamp.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 622 –

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC RVZQ5

13818-1

[C OMMENT] The individual timestamps in each TS Packet are designed to preserve the temporal
relationship between each TS packet and its two adjacent packets.

11.4.4.80.3
[G UIDELINE ] Each TS Packet shall be 192 B in length consisting of a 4 byte TTS Timestamp field
followed by a 188 byte MPEG TS packet conforming to the requirements of ISO/IEC 13818-1.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC VZQ5R

13818-1

11.4.4.80.4
[G UIDELINE ] The TTS Timestamp field shall be in 27 MHz clock units. The 27 MHz clock utilized as
the basis for the TTS Timestamps shall be synchronized with the MPEG System Clock of the
content.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC RMVJ9

13818-1

11.4.4.80.5
[G UIDELINE ] The TTS Timestamp value is a 32-bit binary counter and is not defined using the same
syntax as the PCR field. If this TS Definition is utilized, the Serving Endpoint shall ensure that the
individual TTS Timestamp values have an accuracy of ±500 ns.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC Q5RMV

13818-1

11.4.4.80.6
[G UIDELINE ] The TTS Timestamp field shall contain valid timestamp values.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a ISO/IEC 5RMVJ

13818-1

[C OMMENT] This is different from how the TTS Timestamps are used in HTTP.

11.4.4.80.7
[G UIDELINE ] The RTP Timestamp shall be derived from the TTS Timestamp of the first TS Packet
in the RTP Payload using the following equations.

For the first RTP Timestamp (TSRTP) in the RTP stream, or after a Program System Clock
discontinuity:

TSRTP = Offset + (TSTTS / 300)

DLNA guidelines; Part 1-1: Architecture and protocols

 – 623 –

where

Offset is the RTP Offset defined in 11.4.4.77 and

TSTTS is the 27 MHz TTS 32-bit Timestamp.

For subsequent RTP Timestamps:

TSRTP N = TSRTP N-1 + ((TSTTS N – TSTTS N-1 ) / 300)

where
TSRTP N is the RTP time stamp of the Nth RTP packet;
and
TSTTS N is the TTS time stamp of the first TS packet in the payload of the Nth RTP packet.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a ZQ5RM

[C OMMENT] These equations compensate for the difference in time base between the TTS
Timestamp (27 MHz) and the RTP Timestamp (90 kHz). It allows the RTP Timestamp to reach its
full value (roll over at 232). Implementers shall account for roller in the TSTTS N − TSTTS N-1
expression.

11.4.4.80.8
[G UIDELINE ] The Serving Endpoint shall utilize a dynamic Payload Format of vnd.dlna.mpeg-tts in
the SDP Media Description Fields as defined in 11.4.4.194.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a n/a I84D8

11.4.4.81 MT RTP payload format support for TS without TTS

[G UIDELINE ] If a Receiving Endpoint claims to support TS without TTS then it shall support both
RTP payload format definitions MP2T and vnd.dlna.mpeg-mp2t.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a 6T3VG

[C OMMENT] For full TS its up to the serving endpoint whether MP2T or vnd.dlna.mpeg-mp2t is used,
this implies the Receiving Endpoint shall be able to accept either one.

11.4.4.82 MT RTP clock accuracy for MPEG-2 TS and MPEG-2 PS

[G UIDELINE ] The RTP timestamps applied to MPEG-2 TS and PS encapsulated content shall utilize
a 90 kHz clock source that is accurate to within ± 30 parts per million (ppm) and have a slew rate of
less than 0,075 Hz per second as defined in ISO/IEC 13818-1.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a ISO/IEC Y6YTG

13818-1
IETF RFC
2250

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 624 –

[C OMMENT] Only that way the clock recovered by the Receiving Endpoint can meet the
specifications needed for decoding.

11.4.4.83 MT RTP Target Transmission Time for MPEG TS and PS encapsulated content
[G UIDELINE ] For payload types MP2P, MP2T, vnd.dlna.mpeg-mp2t, and vnd.dlna.mpeg-tts, the
"Target Transmission Time" of an RTP packet is defined by its RTP Timestamp field.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a LCW9F

11.4.4.84 MT RTP ADU usage

[G UIDELINE ] An ADU (Application Data Unit) shall be one complete MAU (Media Access Unit) as
specified in RTP Payload format.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a RTP Payload 84D89
format

11.4.4.85 MT RTP WMA time stamps in ASF are presentation time stamps
11.4.4.85.1
[G UIDELINE ] The "Timestamp" field in the RTP header shall be set to a value reflecting the
presentation time of the first payload in the RTP packet. The "Presentation Time" field of a WMA
Media Object in ASF specifies the presentation time of the WMA Media Object.

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a ASF T3VG6

RTP Payload
format

11.4.4.85.2
[G UIDELINE ] The "Decode Time" field shall not be included in the RTP Payload Format header,
unless the decode time of the WMA media object is known.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a ASF 6YTGX

RTP Payload
format

[C OMMENT] When WMA is stored in an ASF container, decode times of WMA Media Objects are
not available.

11.4.4.86 MT RTP WMV time stamps in ASF are decode time stamps
11.4.4.86.1
[G UIDELINE ] The "Timestamp" field in the RTP header shall be set to a value reflecting the decode
time of the first payload in the RTP packet The "Presentation Time" field of a WMV Media Object in
ASF specifies the decode timeof the WMV Media Object.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 625 –

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a ASF 4D898

RTP Payload
format

11.4.4.86.2
[G UIDELINE ] The a=fmtp line in SDP shall specify ts=DTS to indicate this usage.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a RTP Payload D898O

format

11.4.4.86.3
[G UIDELINE ] The "Presentation Time" field of a WMV media object in ASF shall not be used as the
Presentation Time field of the RTP packet.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a ASF 3VG6O

RTP Payload
format

[C OMMENT] When WMV is stored in an ASF container, presentation times of WMV Media Objects
are not explicitly available.

11.4.4.87 MT RTP determining the value of the SDP "profile" parameter for WMV
[G UIDELINE ] If the ASF Meta Data Object exists, and if it contains a
"DeviceConformanceTemplate" attribute for the WMV media stream, then that attribute may be
used to determine the value for the "profile" parameter in the WMV SDP syntax.

The first two characters in the "DeviceConformanceTemplate" value determine the SDP "profile"
parameter as follows:

• SP: profile=0;
• MP: profile=1.
[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a ASF QS3WN

RTP Payload
format

11.4.4.88 MT RTP determining the value of the SDP "level" parameter for WMV
[G UIDELINE ] If the ASF Meta Data Object exists, and if it contains a
"DeviceConformanceTemplate" attribute for the WMV media stream, then that attribute may be
used to determine the value for the "level" parameter in the WMV SDP syntax.

The last two characters in the "DeviceConformanceTemplate" value determine the SDP "level"
parameter as follows:

• LL: level=0;
• ML: level=1;
• HL: level=2.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 626 –

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a ASF ALCW9

RTP Payload
format

11.4.4.89 MT RTP determining the value of the SDP "aspect" parameter for WMV
[G UIDELINE ] If the ASF Meta Data Object exists, and if it contains both an "AspectRatioX" attribute
and an "AspectRatioY" attribute for the WMV media stream, then those attributes can be used to
determine the value for the "aspect" parameter in the WMV SDP syntax.

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a ASF PY6YT

RTP Payload
format

11.4.4.90 MT RTP determining the value of the SDP "profile" parameter for WMA
[G UIDELINE ] If the ASF Meta Data Object exists, and if it contains a
"DeviceConformanceTemplate" attribute for the WMA media stream, then that attribute may be
used to determine the value for the "profile" parameter in the WMA SDP syntax.

If the first character in the "DeviceConformanceTemplate" value is "L", then the second character
may be used as the value for the SDP "profile" parameter.

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a ASF K6T3V

RTP Payload
format

11.4.4.91 MT RTP H.264 RTP Payload format

[G UIDELINE ] If H.264/AVC elementary streams are transmitted over RTP, then IETF RFC 3984
shall be used as specified in 11.4.4.92 to 11.4.4.98 inclusive.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 6QS3W
3984

11.4.4.92 MT RTP H.264 ADU usage

[G UIDELINE ] An ADU shall be a complete a NAL unit.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC ZALCW
3984

11.4.4.93 MT RTP H.264 packetization

[G UIDELINE ] A Serving Endpoint shall use one of the following packetization modes:

• single NAL unit mode;

• non-interleaved mode;
• interleaved mode.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 627 –

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC YPY6Y

3984

[C OMMENT] For the single NAL unit mode, non-interleaved mode, and interleaved mode, the
values of the packetization-mode MIME/SDP parameter are equal to 0, 1, and 2, respectively.

11.4.4.94 MT RTP H.264 interleaved mode

11.4.4.94.1
[G UIDELINE ] If rtp-h264-deint-buf-cap.dlna.org header (see guideline 11.4.4.97) is not present in
the RTSP DESCRIBE request, then a Serving Endpoint shall set the value of
sprop-interleaving-depth parameter in the a=fmtp line of the SDP equal to 0.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 9ZALC

3984

[C OMMENT] When sprop-interleaving-depth equals 0, the interleaved packetization mode can be

used to encapsulate coded data from multiple coded pictures into the same RTP payload, without
incurring any implementation complexity associated with interleaving of data. For low bit-rate media
streams, this aggregation mechanism can help in avoiding a drop in the available bit rate for the
whole WLAN segment and decreases the RTP/UDP/IP header overhead for the RTP stream.

11.4.4.94.2
[G UIDELINE ] A Receiving Endpoint shall support the interleaved packetization mode with the value
of the sprop-interleaving-depth parameter in the a=fmtp line of the SDP equal to 0.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC H26QS

3984

11.4.4.95 MT RTP H.264 single NAL unit mode

[G UIDELINE ] A Receiving Endpoint shall support the single NAL unit packetization mode.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 26QS3

3984

11.4.4.96 MT RTP H.264 non-interleaved mode

[G UIDELINE ] A Receiving Endpoint shall support the non-interleaved packetization mode.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC BWT85

3984

11.4.4.97 MT RTP H.264 de-interleaving buffer capability

[G UIDELINE ] If a Receiving Endpoint supports the interleaved packetization mode and a value of
the sprop-interleaving-depth MIME/SDP parameter greater than 0, then the Receiving Endpoint
shall include the rtp-h264-deint-buf-cap.dlna.org header in the DESCRIBE request. The syntax of
the header is specified as follows:
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 628 –

• rtp-h264-deint-buf-cap.dlna.org = "rtp-h264-deint-buf-cap.dlna.org" *LWS ":" *LWS 1*DIGIT.

The value of rtp-h264-deint-buf-cap.dlna.org shall be in the range of 0 to 4294967295, inclusive.

The value of the rtp-h264-deint-buf-cap.dlna.org header is interpreted identically to the

deint-buf-cap MIME/SDP parameter specified in IETF RFC 3984.

Example:

• rtp-h264-deint-buf-cap.dlna.org: 32768
This specifies that the Receiving Endpoint is capable of supporting such RTP streams that require
a de-interleaving buffer up to 32 768 B (inclusive).

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC ZVEJZ

3984

[C OMMENT] This indicates how big a buffer a Receiving Endpoint can allocate for the
de-interleaving process of interleaved H.264 RTP streams.

11.4.4.98 MT RTP H.264 de-interleaving buffer requirement

[G UIDELINE ] A serving endpoint shall set the value of the sprop-deint-buf-req parameter of
H.264/AVC in the a=fmtp line of the SDP equal to or less than the value of the
rtp-h264-deint-buf-cap.dlna.org header in the RTSP DESCRIBE request.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 9RX99

3984

11.4.4.99 MT RTP payload format for MPEG-4 Part 2 elementary streams

[G UIDELINE ] If MPEG-4 Part 2 elementary streams are transmitted over RTP, then the RTP
payload format mpeg4-generic shall be used as specified in guidelines 11.4.4.100 to 11.4.4.103,
inclusive.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC G3BWT
3640

[C OMMENT] "mpeg4-generic" is defined in IETF RFC 3640.

11.4.4.100 MT RTP MPEG-4 Part 2 uses generic mode

[G UIDELINE ] A Serving Endpoint that transmits MPEG-4 Part 2 elementary streams over RTP shall
only use the "generic" mode of the RTP payload format mpeg4-generic.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC RX99P

3640

[C OMMENT] Generic mode is the only mode defined in IETF RFC 3640 that is applicable to
MPEG-4 Part 2.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 629 –

The usage of generic mode is signaled by "mode=generic" on the a=fmtp line in SDP. See IETF RFC
3640, 3.3.2.

11.4.4.101 MT RTP MPEG-4 Part 2 ADU usage

[G UIDELINE ] An ADU (Application Data Unit) shall be a complete AU (Access Unit) as specified in
IETF RFC 3640.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 3BWT8
3640

11.4.4.102 MT RTP MPEG-4 Part 2 concatenation and fragmentation of Access Units

[G UIDELINE ] A Serving Endpoint may concatenate and fragment MPEG-4 Access Units as defined
in 2.3 and 2.4 of IETF RFC 3640.

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a IETF RFC W9NQT

3640

11.4.4.103 MT RTP MPEG-4 Part 2 interleaving of Access Units

[G UIDELINE ] A Serving Endpoint shall not interleave MPEG-4 Access Units as defined in 2.5 of
IETF RFC 3640. This means that if the "AU-Index-delta" field is present in the AU Header, then its
value shall be set to 0. Additionally, if the SDP parameter maxDisplacement is present on the
a=fmtp line, then its value shall be 0.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC Q6Y3Q

3640

[C OMMENT] Setting "AU-Index-delta" to 0 means that the index number of the Access Unit is equal
to the previous index number plus one.

11.4.4.104 MT RTP payload format for MPEG-4 AAC and HE-ACC streams
[G UIDELINE ] If MPEG-4 AAC or HE-ACC streams are transmitted over RTP, then the RTP payload
format IETF RFC 3640 shall be used as specified in guidelines 11.4.4.105 to 11.4.4.113 inclusive.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 6Y3QA

3640

[C OMMENT] This guideline applies irrespective of the encoding tools used in the bit stream, such as
AAC LC, LTP, BSAC, etc.

11.4.4.105 MT RTP MPEG-4 AAC

[G UIDELINE ] A Serving Endpoint that transmits MPEG-4 AAC streams over RTP shall use the High
Bit-rate AAC mode of the RTP payload format IETF RFC 3640.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC YZVEJ

3640
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 630 –

[C OMMENT] The usage of High Bit-rate AAC mode is signaled by "mode=AAC-hbr" on the a=fmtp
line in SDP. See IETF RFC 3640, 3.3.5.

Alternative, low Bit-rate AAC mode could have been used only when AAC frame length is at most 63
octets, i.e., corresponding such a low bit rates that are used rarely in DLNA. Therefore low bit-rate
mode is not allowed.

11.4.4.106 MT RTP MPEG-4 AAC concatenation and fragmentation of Access Units

11.4.4.106.1
[G UIDELINE ] A Serving Endpoint may concatenate and fragment MPEG-4 AAC Access Units as
defined in 2.4 of IETF RFC 3640.

[ATTRIBUTES ]

O R DMS +PU+ M-DMS n/a IETF RFC T9RX9

3640

11.4.4.106.2
[G UIDELINE ] If a Serving Endpoint concatentates or fragments MPEG-4 AAC Access units, RTP
packets shall not contain fragments of multiple Access Units.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC 5T9RX

3640

11.4.4.107 MT RTP MPEG-4 AAC non-interleaving of Access Units

[G UIDELINE ] A Serving Endpoint shall support non-interleaved packetization mode.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC FYZVE

3640

11.4.4.108 MT RTP MPEG-4 AAC interleaving of Access Units

[G UIDELINE ] If a Serving Endpoint supports interleaving then it shall apply interleaving when
rtp-aac-deint-buf-cap.dlna.org header is present in the RTSP DESCRIBE request.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC XFYZV

3640

11.4.4.109 MT RTP MPEG-4 AAC RTP interleaving in SDP

[G UIDELINE ] A Serving Endpoint shall set the value of the maxDisplacement parameter in the
a=fmtp line of the SDP equal to or less than the value of the rtp-aac-deint-buf-cap.dlna.org header
in the RTSP DESCRIBE request.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC XV7QD

3640

[C OMMENT] The value of the SDP maxDisplacement parameter in a=fmtp can be 0.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 631 –

11.4.4.110 MT RTP MPEG-4 AAC non-interleaving of Access Units

[G UIDELINE ] When a serving endpoint uses non-interleaved mode then if the "AU-Index-delta" field
is present in the AU Header, then its value shall be 0. Additionally, if the SDP parameter
maxDisplacement is present on the a=fmtp line, then its value shall be 0.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC AW9NQ

3640

[C OMMENT] Setting "AU-Index-delta" to 0 means that the index number of the Access Unit is equal
to the previous index number plus one.

11.4.4.111 MT RTP MPEG-4 AAC non-interleaved mode

[G UIDELINE ] A Receiving Endpoint shall support the non-interleaved packetization mode.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC XQ6Y3

3640

11.4.4.112 MT RTP MPEG-4 AAC interleaved mode

[G UIDELINE ] A Receiving Endpoint may support the interleaved packetization mode.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a IETF RFC 398XV

3640

11.4.4.113 MT RTP MPEG-4 AAC RTP interleaving indication

[G UIDELINE ] If a Receiving Endpoint supports interleaving then it shall include the
rtp-aac-deint-buf-cap.dlna.org header in the DESCRIBE request.

The syntax of this header is specified as follows:

• rtp-aac-deint-buf-cap-line = "rtp-aac-deint-buf-cap.dlna.org" *LWS ":" *LWS 1*DIGIT.

The value of the rtp-aac-deint-buf-cap.dlna.org header is interpreted identically to the
maxDisplacement SDP parameter, specified in IETF RFC 3640.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC QXQ6Y

3640

11.4.4.114 MT RTP H.263 RTP Payload

[G UIDELINE ] If H.263 streams are transmitted over RTP, then the RTP payload format H263-2000
as defined in IETF RFC 3555, and IETF RFC 2429 shall be used with the constraints listed in
guidelines 11.4.4.115 through 11.4.4.117, below.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 8XV7Q

3555
IETF RFC
2429

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 632 –

11.4.4.115 MT RTP H.263 profile and level

[G UIDELINE ] A Serving Endpoint shall specify the profile and level in the a=fmtp line of SDP.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 98XV7

2429

[C OMMENT] The H.263 profile and level included in the a=fmtp line shall follow the H263-2000
MIME media type specified in IETF RFC 3555.

11.4.4.116 MT RTP H.263 frame size attribute at SDP media level

11.4.4.116.1
[G UIDELINE ] A Serving Endpoint shall specify the a=framesize attribute at the SDP media level for
each H.263 stream in SDP.

The syntax is defined as

• a-framesize = "a=framesize:" payload-type SP width "-" height,

• payload-type = 1*DIGIT; (shall be between 0 and 127),
• width = 1*DIGIT,
• height = 1*DIGIT.
Example:

• a=framesize:96176-144
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 5XAW9

11.4.4.116.2
[G UIDELINE ] Receiving Endpoints may support the a=framesize SDP attribute.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a n/a XAW9N

11.4.4.117 MT RTP H.263 ADU usage

[G UIDELINE ] An ADU (Application Data Unit) shall be a complete video slice. Each RTP packet
shall carry a single ADU.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC XG3BW
3555

11.4.4.118 MT RTP AMR RTP payload

[G UIDELINE ] If AMR streams are transmitted over RTP, then the RTP payload format IETF RFC
3267 shall be used as specified in guidelines 11.4.4.119 to 11.4.4.121, inclusive.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC V7QD3
3267

DLNA guidelines; Part 1-1: Architecture and protocols

 – 633 –

11.4.4.119 MT RTP AMR RTP encapsulation

11.4.4.119.1
[G UIDELINE ] A Serving Endpoint shall support encapsulation of one or more AMR speech frames
into a single RTP packet and shall include maxptime attribute in SDP.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 7QD33

3267

[C OMMENT] Subclause 8.1 of IETF RFC 3267 explains the SDP "maxptime" attribute.

11.4.4.119.2
[G UIDELINE ] The recommended value for the SDP maxptime attribute is 200 ms.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC D33EI

3267

11.4.4.120 MT RTP AMR RTP interleaving

11.4.4.120.1
[G UIDELINE ] A Serving Endpoint may support interleaving.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC QD33E

3267

11.4.4.120.2
[G UIDELINE ] If a Serving Endpoint supports interleaving then it shall apply interleaving when the
rtp-amr-deint-buf-cap.dlna.org header is present in the RTSP DESCRIBE request.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC VEJZD

3267

11.4.4.120.3
[G UIDELINE ] A Serving Endpoint shall set the value of the interleaving parameter in the a=fmtp line
of the SDP equal to or less than the value of the rtp-amr-deint-buf-cap.dlna.org header in the RTSP
DESCRIBE request.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC TIMZ3

3267

[C OMMENT] Subclause 8.1 of IETF RFC 3267 explains the SDP interleaving parameter.

The value of the SDP interleaving parameter in a=fmtp can be 0.

11.4.4.120.4
[G UIDELINE ] A Receiving Endpoint may support interleaving.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 634 –

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a IETF RFC QARG4

3267

11.4.4.120.5
[G UIDELINE ] If a Receiving Endpoint supports interleaving then it shall include the
rtp-amr-deint-buf-cap.dlna.org header in the DESCRIBE request.

The syntax of this header is specified as follows:

• rtp-amr-deint-buf-cap-line = "rtp-amr-deint-buf-cap.dlna.org" *LWS ":" *LWS 1*DIGIT

The value of the rtp-amr-deint-buf-cap.dlna.org header is interpreted identically to the "interleaving"
SDP parameter, specified in IETF RFC 3267.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC EJZDY

3267

[C OMMENT] Subclause 8.1 of IETF RFC 3267 explains the SDP "interleaving" parameter.

11.4.4.121 MT RTP AMR RTP decapsulation

11.4.4.121.1
[G UIDELINE ] A Receiving Endpoint shall be able to decapsulate an RTP packet having one or more
AMR speech frames.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC X99PE

3267

11.4.4.121.2
[G UIDELINE ] A Receiving Endpoint should be able to support values of the SDP maxptime attribute
of at least 200 ms.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC Y3QAR

3267

[C OMMENT] Subclause 8.1 of IETF RFC 3267 explains maxptime attribute.

11.4.4.122 MT RTP Payload format for AMR-WBplus streams

[G UIDELINE ] If AMR-WBplus streams are transmitted over RTP, then the RTP Payload format as
specified in IETF RFC 4352 shall be used as specified in guidelines 11.4.4.123 to 11.4.4.127
inclusive.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC QTIMZ
4352

DLNA guidelines; Part 1-1: Architecture and protocols

 – 635 –

11.4.4.123 MT RTP AMR-WBplus encapsulation

11.4.4.123.1
[G UIDELINE ] A Serving Endpoint shall support encapsulation of one or several AMR-WBplus
frames into a single RTP packet and shall include maxptime attribute in SDP.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 3QARG

4352

11.4.4.123.2
[G UIDELINE ] The recommended value for the SDP maxptime attribute is 200 ms.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC 9NQTI

4352

11.4.4.124 MT RTP AMR-WBplus basic mode

11.4.4.124.1
[G UIDELINE ] A Serving Endpoint shall support basic mode.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC NQTIM

4352

11.4.4.124.2
[G UIDELINE ] A Receiving Endpoint shall support basic mode.

[ATTRIBUTES ]

M R DMP DMR M-DMP n/a IETF RFC ARG45

4352

11.4.4.125 MT RTP AMR-WBplus interleaving mode

11.4.4.125.1
[G UIDELINE ] A Serving Endpoint may support interleaving mode.

[ATTRIBUTES ]

O L DMS +PU+ M-DMS n/a IETF RFC ZDYQA

4352

[C OMMENT] This is limitation to IETF RFC 4352 that mandates to support both basic and
interleaving modes.

11.4.4.125.2
[G UIDELINE ] If a Serving Endpoint supports interleaving mode then it shall use interleaving when
the rtp-amrwbplus-deint-buf-cap.dlna.org header is present in the RTSP DESCRIBE request.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC 9PESQ

4352
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 636 –

11.4.4.125.3
[G UIDELINE ] A Serving Endpoint shall set the value of the "interleaving" parameter in the a=fmtp
line of the SDP equal to or less than the value of the rtp-amrwbplus-deint-buf-cap.dlna.org header
in the RTSP DESCRIBE request.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC JZDYQ

4352

[C OMMENT] Subclauses 4.4 and 7.2.1 of IETF RFC 4352 explain the use of SDP parameters for
interleaving.

11.4.4.125.4
[G UIDELINE ] If a Receiving Endpoint supports interleaving mode then it shall include
rtp-amrwbplus-deint-buf-cap.dlna.org header in the DESCRIBE request.

The syntax of this header is specified as follows:

• rtp-amrwbplus-deint-buf-cap-line = "rtp-amrwbplus-deint-buf-cap.dlna.org" *LWS ":" *LWS

1*DIGIT
The value of this header is interpreted identically to the "interleaving" SDP parameter, specified in
IETF RFC 4352.

[ATTRIBUTES ]

M R DMP DMR M-DMP n/a IETF RFC 99PES

4352

[C OMMENT] The value of interleaving parameter shall be greater than zero (see 7.2.1 of IETF RFC
4352). If it is not present, interleaving mode shall not be used.

Subclauses 4.4 and 7.2.1 of IETF RFC 4352 explain the use of SDP parameters for interleaving.

11.4.4.126 MT RTP AMR-WBplus RTP decapsulation

11.4.4.126.1
[G UIDELINE ] A Receiving Endpoint shall be able to decapsulate an RTP packet having one or more
AMR-WBplus frames.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 8592P

4352

11.4.4.126.2
[G UIDELINE ] A Receiving Endpoint should be able to support values of the SDP maxptime attribute
of at least 200 ms.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC 3WNRR

4352

DLNA guidelines; Part 1-1: Architecture and protocols

 – 637 –

11.4.4.127 MT RTP AMR-WBplus channels

[G UIDELINE ] A Receiving Endpoint that is only capable of playout of monophonic audio shall still
accept signals originally encoded and transmitted as stereo.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC CW9FJ

4352

[C OMMENT] The AMR-WBplus decoder has the capability of stereo to mono downmixing as part of
the decoding process.

11.4.4.128 RTP Media Transport: RTSP for control of RTP streams – General
The Real Time Streaming Protocol (RTSP) provides a standard protocol for controlling media
streams, including starting, stopping and pausing. Media operations such as fast forward scan, slow
backward scan, etc., can also be implemented in a standard way using RTSP. RTSP is the required
protocol for controlling streams for RTP transport.

The Session Description Protocol (SDP) provides a standard method of communicating RTP
session parameters. It is used as the format of the description of the media that is sent from the
Serving Endpoint to the Receiving Endpoint in the response to the RTSP DESCRIBE method.

The DLNA RTSP and SDP signaling in 11.4.4.129 through 11.4.4.211 specifies a minimal strict
subset of RTSP (IETF RFC 2326) and SDP (IETF RFC 2327) to be implemented by DLNA Serving
Endpoints and Receiving endpoints.

11.4.4.129 MT RTP RTSP support

[G UIDELINE ] A DLNA device shall implement RTSP version 1.0 as the mandatory media transport
control protocol as described in Appendix D of IETF RFC 2326 with constraints and extensions
defined in subsequent entries of this table. Specifically serving endpoints shall implement RTSP
servers and Receiving Endpoints shall implement RTSP clients.

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC PESQI
2326

[C OMMENT] RTSP controls the RTP media transport.

11.4.4.130 MT RTP RTSP SDP support

[G UIDELINE ] A DLNA device shall implement SDP as the mandatory format used in the RTSP
DESCRIBE method.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC T8592
2327

[C OMMENT] SDP declares the properties of the media streams that can be present in the RTSP
session.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 638 –

11.4.4.131 MT RTP RTSP TCP transport

11.4.4.131.1
[G UIDELINE ] Both Serving Endpoint and Receiving Endpoint devices shall use TCP to transport
RTSP.

[ATTRIBUTES ]

M L DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC WT859
2326

[C OMMENT] RTSP/UDP usage is not allowed.

11.4.4.131.2
[G UIDELINE ] A Serving Endpoint should support persistent TCP connections. This means that the
TCP connection should not be closed by Serving Endpoint until after all RTSP sessions using the
TCP connection have been terminated.

[ATTRIBUTES ]

S C DMS +PU+ M-DMS n/a IETF RFC S3WNR

2326

11.4.4.131.3
[G UIDELINE ] A Receiving Endpoint should use a persistent TCP connection for each RTSP session.
This means that the TCP connection should not be closed by Receiving Endpoint until after the
RTSP session has been terminated.

[ATTRIBUTES ]

S C DMP DMR M-DMP n/a IETF RFC 592PB

2326

11.4.4.132 MT RTP RTSP pipelined requests

[G UIDELINE ] Serving Endpoint shall accept pipelined RTSP requests, and shall respond to RTSP
requests in the order that they were received.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC NRRAN

2326

11.4.4.133 MT RTP multiple RTSP sessions

[G UIDELINE ] Serving endpoints should support more than one simultaneous RTSP session.

[ATTRIBUTES ]

S C DMS +PU+ M-DMS n/a IETF RFC 9FJ7Y

2326

[C OMMENT] It is a good practice for a serving endpoint to support multiple Receiving Endpoints
simultaneously.

11.4.4.134 MT RTP RTSP session multiplexing

[G UIDELINE ] Receiving Endpoint shall use a separate TCP connection for each RTSP session.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 639 –

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC GXOS9

2326

11.4.4.135 MT RTP receive RTSP requests from a Serving Endpoint

11.4.4.135.1
[G UIDELINE ] A Receiving Endpoint shall support receiving RTSP requests from the Serving
Endpoint over the same TCP connection that the Receiving Endpoint is using for sending requests
to the Serving Endpoint.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC WNRRA

2326

11.4.4.135.2
[G UIDELINE ] If a Receiving Endpoint does not implement support for an RTSP request type, it shall
respond to a Serving Endpoint with a "501 Not Implemented" status code.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC TGXOS

2326

11.4.4.136 MT RTP indication of supported RTSP version

11.4.4.136.1
[G UIDELINE ] Serving Endpoints and Receiving Endpoints should specify the highest RTSP version
number that they are compliant with when sending a RTSP response regardless of which RTSP
version number was specified in the corresponding RTSP request.

[ATTRIBUTES ]

S C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC G6O7W
2326

11.4.4.136.2
[G UIDELINE ] If a Serving Endpoint or a Receiving Endpoint receives a RTSP request that specifies
a higher version of RTSP than is supported, then it shall respond with status code 505 ("RTSP
version not supported").

[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC W9FJ7
2326

11.4.4.136.3
[G UIDELINE ] Serving Endpoints and Receiving Endpoints shall accept RTSP responses that
specify a RTSP version number higher than the highest supported RTSP version.

[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC YTGXO
2326

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 640 –

11.4.4.137 MT RTP tolerate unknown RTSP headers and SDP attributes

[G UIDELINE ] Receiving Endpoints and Serving Endpoints shall be tolerant of unknown RTSP
headers and SDP attributes.

Tolerant behavior is defined as being able to successfully "parse and interpret" or "parse and
ignore" the RTSP headers, their values and SDP attributes and their values.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 6O7W7
2326
IETF RFC
2327

[C OMMENT] This guideline addresses forward compatibility and allows for broader interoperability
with implementations that employ transport layer vendor extensions by way of RTSP headers.

11.4.4.138 MT RTP RTSP case-sensitivity

[G UIDELINE ] Names of RTSP methods shall be treated as case sensitive tokens, while the RTSP
headers shall be treated as case-insensitive tokens.

[ATTRIBUTES ]

M C DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC VG6O7
2326

[C OMMENT] This is normative according to the RTSP specification.

11.4.4.139 MT RTP RTSP required requests

11.4.4.139.1
[G UIDELINE ] A Serving Endpoint shall support receiving the following RTSP requests:

• DESCRIBE;
• SETUP;
• PLAY;
• OPTIONS;
• TEARDOWN.
A Serving Endpoint need not support receiving any other RTSP requests.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC FJ7YD

2326

11.4.4.139.2
[G UIDELINE ] A Receiving Endpoint shall not depend on the support of any RTSP request not listed
in guideline 11.4.4.139.1.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC XOS9X

2326

DLNA guidelines; Part 1-1: Architecture and protocols

 – 641 –

11.4.4.139.3
[G UIDELINE ] A Receiving Endpoint shall support sending the following RTSP requests:

• DESCRIBE;
• SETUP;
• PLAY;
• OPTIONS;
• TEARDOWN.
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 98OYB

2326

11.4.4.140 MT RTP DLNA Media Operations summary

[G UIDELINE ] The DLNA Streaming Media Operations (in Table 40) shall be implemented as defined
in the following guidelines:

• Play: 11.4.4.164 MT RTP Play Media Operation

• Stop: 11.4.4.183 MT RTP Stop Media Operation
• Pause: 11.4.4.175 MT RTP Pause Media Operation
• Pause-Release: 11.4.4.177 MT RTP Pause-Release Media Operation
• Seek: 11.4.4.167 MT RTP Seek Media Operation
• Fast Forward Scan11.4.4.171 MT RTP Scan Media Operations
• Slow Forward Scan: 11.4.4.171 MT RTP Scan Media Operations
• Fast Backward Scan: 11.4.4.171 MT RTP Scan Media Operations
• Slow Backward Scan: 11.4.4.171 MT RTP Scan Media Operations
• Streaming Download: n/a
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a O7W77

11.4.4.141 MT RTP CSeq header

[G UIDELINE ] A Serving Endpoint shall include the CSeq header in all RTSP responses, and in any
RTSP requests that it sends.

The CSeq header in requests sent by the Serving Endpoint shall be independent of the CSeq
header in requests sent by the Receiving Endpoint.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC 898OY

2326

11.4.4.142 MT RTP Supported header

[G UIDELINE ] The Supported header field shall comply with the following syntax:

• supported-line = "Supported" *LWS ":" *LWS [feature-tag *(*LWS "," *LWS feature-tag)];
• feature-tag = token.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 642 –

Examples:

• Supported: dlna.announce
• Supported: dlna.announce, rtsp.basic
The RTSP header name is the "Supported" string and the header value is zero or more
comma-separated tokens. Both header name and value are treated as case insensitive strings.

Note that the Supported header can be used by Serving Endpoints and Receiving Endpoints issuing
an RTSP request on non-DLNA content.

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC VJ9KN
3261

[C OMMENT] The Supported header is currently defined for the SIP protocol (see IETF RFC
32612002, 20.37).

11.4.4.143 MT RTP Event-Type.dlna.org header

[G UIDELINE ] The Event-Type.dlna.org header shall comply with the following syntax:

• event-type-line = "Event-Type.dlna.org" *LWS ":" *LWS event code;

• event-code = 4DIGIT; 0-9999.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a J9KNJ

[C OMMENT] This header is used with the ANNOUCE request (guideline 11.4.4.180.1) to indicate an
event that has occurred at the Serving Endpoint.

The event code consists of exactly 4 numerical digits.

11.4.4.144 MT RTP Available-Range.dlna.org header

11.4.4.144.1
[G UIDELINE ] The Available-Range.dlna.org header shall comply with the following syntax:

• available-range-line = "Available-Range.dlna.org" *LWS ":" *LWS "npt" "=" npt-time "-" npt-time;
• npt-time = <syntax as defined in 11.4.2.13>.
[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 8OYB8
2326

11.4.4.144.2
[G UIDELINE ] The first npt-time parameter should correspond to the smallest NPT time value that
Receiving Endpoint may specify as the start time in a Range header.

The second npt-time parameter should correspond to the largest NPT time value that Receiving
Endpoint may specify as the start time in a Range header.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 643 –

[ATTRIBUTES ]

S A DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a MVJ9K

11.4.4.145 MT RTP Buffer-Info.dlna.org header

[G UIDELINE ] The Buffer-Info.dlna.org header shall comply with the following syntax:

• buffer-info-line = "Buffer-Info.dlna.org" *LWS ":" *LWS "dejitter" "=" 1*10DIGIT [";" cdb-params]
[";" td-params] [";"bfr-params]
• cdb-params = "CDB" "=" 1*10DIGIT ";" "BTM" "=" "0" | "1" | "2"
• td-params = "TD" "=" 1*10DIGIT
• bfr-params = "BFR" "=" "0" | "1"
Note that the literals, "dejitter", "CDB", "BTM", "TD", and "BFR", are case sensitive.

The first parameter, "dejitter", specifies the size, in bytes, of the network de-jitter buffer.

If cdb-params is present, the "CDB" parameter specifies the size of the Coded Data Buffer in bytes.
The BTM parameter specifies the buffer transfer mechanism between the network de-jitter buffer
and the coded data buffer. The BTM parameter shall comply with the following syntax.

• 0: When the coded data buffer has empty space then the de-jitter buffer will transfer the data
immediately.
• 1: The data is transferred according to packet's timestamp.
• 2: Other transfer mechanism than the above.
If td-params is present, the TD (Target Buffer Duration) parameter specifies the minimal amount of
data that is required for interrupt free playback in the combination of the Receiving Endpoint's
network de-jitter buffer and the Coded Data Buffer (if any). The value of the TD parameter is
represented in millisecond time units.

If bfr-params is present, the BFR parameter specifies if the Receiving Endpoint will transmit Buffer
Fullness Reports.The value 1 means that the Receiving Endpoint will transmit Buffer Fullness
Reports and the value 0 indicates that the Receiving Endpoint will not transmit Buffer Fullness
Reports.

Example:

• Buffer-Info.dlna.org: dejitter=65536;CDB=98302;BTM=0;TD=1000;BFR=1
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a 9KNJD

[C OMMENT] The Coded Data Buffer (CDB) contains only raw compressed data bit stream without
RTP headers.

If the CDB is present on the Receiving Endpoint and the buffer transfer mechanism is not signaled,
the input to the coded data buffer shall follow an appropriate buffering model. In other words, when
a Receiving Endpoint maintains a coded data buffer for an audio elementary stream, coded audio
frames are moved to the CDB according to their RTP timestamp. When a Receiving Endpoint
maintains a coded data buffer for a video elementary stream, the input to the CDB is done as
specified in the Hypothetical Reference Decoder specification of the video coding profile in use.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 644 –

When a Receiving Endpoint maintains a coded data buffer for a MPEG-2 TS or MPEG-2 PS, RTP
payloads are input to the CDB according to their RTP timestamps.

The Target Buffer Duration indicated by a Receiving Endpoint informs the Serving Endpoint to fill up
the receiver buffer (network de-jitter buffer + Coded Data Buffer) to a minimum amount of data to
prevent buffer underflow.

If the amount of data associated with the Target Buffer Duration is larger than the size of the
receiver buffer, then it does not imply that the Serving Endpoint is allowed to exceed size of the
receiver buffer.

The Serving Endpoint shall not intentionally overflow the Receiving Endpoint's receiver buffer at any
time.

The Serving Endpoint might need to adjust the encoding rate to fulfill the Target Buffer Duration
indication while maintaining the Receiving Endpoint's receiver buffer.

11.4.4.146 MT RTP WCT.dlna.org header

[G UIDELINE ] The WCT.dlna.org header shall comply with the following syntax:

• wct-line = "WCT.dlna.org" *LWS ":" *LWS <val>

• <val> = "0" | "1'"
Example:

• WCT.dlna.org: 1
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a A

[C OMMENT] This header is used to request Serving Endpoint to add Wall Clock Time samples.

11.4.4.147 MT RTP Max-Prate.dlna.org header

[G UIDELINE ] The Max-Prate.dlna.org RTSP header shall comply with the following syntax:

• max-prate-line = "Max-Prate.dlna.org" *LWS ":" *LWS max-packet-rate;

• max-packet-rate = 1*DIGIT;
• max-packet-rate is expressed in units of packets per second (pps).
Example:

• Max-Prate.dlna.org: 200
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a ULNQC

[C OMMENT] The Receiving Endpoint can include the header Require: dlna.Max-Prate in a request
to determine if the Serving Endpoint takes the Max-Prate.dlna.org header into account. (See
guideline 11.4.4.157.2.)

11.4.4.148 MT RTP RTSP Require header

[G UIDELINE ] If the Serving Endpoint receives a request with a Require header and that header lists
at least one unrecognized feature tag, then the Serving Endpoint shall respond with a status code
551 (Option Not Supported).
DLNA guidelines; Part 1-1: Architecture and protocols
 – 645 –

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC D24UR

2326

11.4.4.149 MT RTP RTSP aggregate control

11.4.4.149.1
[G UIDELINE ] The Serving Endpoint shall support aggregate control. This implies that error code
459 shall not be returned by PAUSE, PLAY and TEARDOWN methods.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 75Y4A

2326

[C OMMENT] For RTSP sessions consisting of multiple RTP streams, the RTSP protocol supports
most methods at both the presentation (= aggregate) and at the individual RTP stream (=
non-aggregate) level.
However, PLAY, PAUSE and TEARDOWN is most appropriately done at the aggregate level.

11.4.4.149.2
[G UIDELINE ] The Receiving Endpoint shall support aggregate control for PAUSE, PLAY, and
TEARDOWN commands.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC X3TVQ

2326

11.4.4.150 MT RTP send RTCP reports when in RTSP Ready state

11.4.4.150.1
[G UIDELINE ] If a Receiving Endpoint is sending RTCP reports, it shall do so while the RTSP
session is in the Ready and Playing states if at least one RTP packet has been received.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC DHHKD

2326

[C OMMENT] When the RTSP session is paused, RTSP enters Ready state. (The RTSP state
machine is defined in IETF RFC 2326.) RTCP reports shall be sent even when the RTSP session is
paused.

11.4.4.150.2
[G UIDELINE ] If a Serving Endpoint is sending RTCP reports, it shall do so while the RTSP session
is in the Ready and Playing states if at least one RTP packet has been transmitted.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 775Y4

2326

[C OMMENT] RTCP reports shall be sent even when the RTSP session is paused.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 646 –

If a Serving Endpoint is relaying an RTP stream, it might not know the SSRC of the RTP stream (and
will be unable to send an RTCP Sender Report) until it has relayed the first RTP packet for that
stream.

11.4.4.151 MT RTP Serving Endpoint timeout (keep alive)

11.4.4.151.1
[G UIDELINE ] A Serving Endpoint shall terminate the RTSP session if it has received neither an
RTCP Receiver Report nor an RTSP request within a timeout interval.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC NDS9M

2326

11.4.4.151.2
[G UIDELINE ] The recommended timeout interval for receiving RTCP Receiver Reports or RTSP
requests is 30 s.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a JD24U

11.4.4.151.3
[G UIDELINE ] For timeout interval values other than 60 s the Serving Endpoint shall use the
"timeout" parameter in the RTSP Session header to communicate the value of the timeout interval
to the Receiving Endpoint.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC B8ULN

2326

[C OMMENT] If the "timeout" parameter is not specified, the timeout interval defaults to 60 s.

11.4.4.151.4
[G UIDELINE ] A Receiving Endpoint shall send at least one RTSP request with the Session header
per timeout interval.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC NJD24

2326

[C OMMENT] Commands such as SETUP, PLAY and PAUSE alter the RTSP session state, while
OPTIONS does not.

The recommended "keep alive" method is to send a RTSP OPTIONS request with Session header.
RTCP can also be used if implemented.

11.4.4.151.5
[G UIDELINE ] A Receiving Endpoint should send an OPTIONS request with the Session header per
timeout interval if no other RTSP request needs to be sent during a given timeout interval.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 647 –

[ATTRIBUTES ]

S L DMP DMR M-DMP n/a IETF RFC 8ULNQ

2326

11.4.4.152 MT RTP Receiving Endpoint timeout (keep alive)

11.4.4.152.1
[G UIDELINE ] If a Receiving Endpoint has not received an RTP or RTCP packet from the Serving
Endpoint within a timeout interval and the RTSP session is in the Playing state, the Receiving
Endpoint should terminate the RTSP session as described in guideline 11.4.4.183.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC KNJD2

2326

[C OMMENT] Some RTSP servers might not send RTCP packets while in Paused state, so this
guideline applies to Playing state only.

When choosing a timeout interval, a Receiving Endpoint is exptected to consider the streaming bit
rate and the bit rate used for RTCP reports. (Low bit rates might require a larger timeout interval.)

11.4.4.152.2
[G UIDELINE ] A Receiving Endpoint should assume that the RTSP session has been terminated if it
has not received an RTSP command response within a timeout interval.

The recommended value for this timeout interval is 30 s.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC YB8UL

2326

11.4.4.152.3
[G UIDELINE ] If the RTSP session is assumed to have been terminated, the Receiving Endpoint
should close the RTSP TCP connection to the Serving Endpoint.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC W775Y

2326

11.4.4.153 MT RTP session description format used in DESCRIBE

11.4.4.153.1
[G UIDELINE ] A Receiving Endpoint shall specify the MIME content type "application/sdp" in the
Accept header of a DESCRIBE request.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC 7W775

2326

[C OMMENT] The Receiving Endpoint can request additional content types using the Accept header,
but the Serving Endpoint might not support any additional content types.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 648 –

11.4.4.153.2
[G UIDELINE ] If the Serving Endpoint receives a DESCRIBE request and the request does not
contain an Accept header, then the Serving Endpoint shall infer that "application/sdp" is the only
MIME content type supported by the Receiving Endpoint.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC ANDS9

2326

11.4.4.153.3
[G UIDELINE ] If the Serving Endpoint responds to a DESCRIBE request with status code 200 ("OK"),
then the response shall include the following:

• an entity body in one of the formats specified in the Accept header of the DESCRIBE request, or
in SDP format if no Accept header was included;
• a Content-Type header, and this header shall specify the MIME content type of the entity body.
[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 7YDHH

2326

[C OMMENT] Since Receiving Endpoints always specify "application/sdp" as one of the MIME
content types, this means that the Serving Endpoint shall always support respdonding with an entity
body in SDP format.

11.4.4.154 MT RTP Available-Range.dlna.org header in DESCRIBE response

11.4.4.154.1
[G UIDELINE ] If a Serving Endpoint supports the Limited Random Access Data Availability model for
a content binary (defined in 10.1.3.28.4), then it shall include the Available-Range.dlna.org header
(guideline 11.4.4.144) in the DESCRIBE response.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a n/a OS9X3

11.4.4.154.2
[G UIDELINE ] If the Available-Range.dlna.org header is included in the DESCRIBE response, the
first npt-time parameter in that header should be set to the UCDAM's data position of of r 0 , and the
second npt-time parameter should be set to the UCDAM's data position of r N .

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a 9X3TV

[C OMMENT] The variables r 0 and r N , represent the earliest time and latest time, respectively, in the
RTP stream (or media stream) that the Receiving Endpoint can seek to.

11.4.4.155 MT RTP/BCM RTSP peerManager.dlna.org

11.4.4.155.1
[G UIDELINE ] A Receiving Endpoint should include the header peerManager.dlna.org in an RTSP
DESCRIBE request to communicate the identity of the UPnP AV ConnectionMananger service to
the Serving Endpoint.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 649 –

[ATTRIBUTES ]

S A DMR n/a n/a ISO/IEC S9X3T

29341-14-11

[C OMMENT] The header peerManager.dlna.org is not required. However, this feature is

recommended to help a Serving Endpoint that implements BCM.

11.4.4.155.2
[G UIDELINE ] The value of the header peerManager.dlna.org shall be the same value as the
PeerConnectionManager, as described in the UPnP AV Architecture.

The notation of the peerManager.dlna.org RTSP header is the same as peerManager-line, defined
in 11.4.3.35.2.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC YDHHK

29341-14-11

11.4.4.156 MT RTP/BCM RTSP friendlyName.dlna.org

11.4.4.156.1
[G UIDELINE ] A Receiving Endpoint should include the header friendlyName.dlna.org in an RTSP
DESCRIBE request to communicate a user-friendly name to the Serving Endpoint.

[ATTRIBUTES ]

S A DMP M-DMP n/a n/a J7YDH

[C OMMENT] The header friendlyName.dlna.org is not required. However, this feature is

recommended to help a Serving Endpoint that implements BCM.

11.4.4.156.2
[G UIDELINE ] The notation of the friendlyName.dlna.org RTSP header is the same as the
friendlyName-line, defined in 11.4.3.36.2 (MT/BCM HTTP Header:friendlyName.dlna.org).

[ATTRIBUTES ]

M A DMP M-DMP n/a n/a RANDS

11.4.4.157 MT RTP maximum reception packet rates

11.4.4.157.1
[G UIDELINE ] A Receiving Endpoint may include the header Max-Prate.dlna.org (defined in
guideline 11.4.4.147) in an RTSP DESCRIBE request.

The header Max-Prate.dlna.org declares the maximum packet data rate capability of the Receiving
Endpoint.

The header may be included in any subsequent RTSP request, in case the Receiving Endpoint
wants to update its maximum reception packet rate capability during a RTSP session.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a n/a A6ZWY

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 650 –

[C OMMENT] This rule enables the signaling of the maximum Receiving Endpoint reception packet
rate to inform the Serving Endpoint.
It avoids a lightweight Receiving Endpoint having performance problems or losing packets in case
the incoming packet rate is too high to be sustained.

This guideline does not enable a Receiving Endpoint to change/override the supported and/or
negotiated media profile(s) for a particular RTSP session.

11.4.4.157.2
[G UIDELINE ] If a Receiving Endpoint includes the Max-Prate.dlna.org in an RTSP request, then it
should also include the Require: dlna.Max-Prate header in the same RTSP request.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC QIR34

2326

[C OMMENT] This allows the Receiving Endpoint to get an acknowledgment from the Serving
Endpoint.

11.4.4.158 MT RTP supported header when RTP packet retransmission is supported

11.4.4.158.1
[G UIDELINE ] If a Receiving Endpoint supports retransmitted packets formatted using the RTP
payload formats audio/rtx and video/rtx, as defined in IETF RFC 4588 ,then Receiving Endpoint
shall include the Supported header with feature-tag dlna.rtx in the DESCRIBE request.

Example:

• Supported: dlna.rtx
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 2PBOY

4588

[C OMMENT] The indication of which retransmission methods, if any, are supported, allows Serving
Endpoint to decide if it will accept RTCP nack feedback messages, and allows it to indicate this
decision in the SDP a=rtcp-fb parameter.

11.4.4.158.2
[G UIDELINE ] If a Receiving Endpoint supports retransmitted packets sent as an identical copy of
the original packet to the same UDP port as the original packet, then the Receiving Endpoint shall
include the Supported header with feature-tag dlna.rtx-dup in the DESCRIBE request.

Example:

• Supported: dlna.rtx-dup
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a RRAND

11.4.4.159 MT RTP SETUP request clarifications

[G UIDELINE ] While in Playing state, a Serving Endpoint shall support the SETUP method, to allow
a Receiving Endpoint to change RTP and RTCP ports of the RTP Session.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 651 –

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC BOYV9

2326

[C OMMENT] The RTSP protocol state machine is described in IETF RFC 2326, Clause A.1.

11.4.4.160 MT RTP Transport header when RTP/AVPF is used

[G UIDELINE ] If the RTP/AVPF profile is used, the Receiving Endpoint and the Serving Endpoint
shall specify the transport field in the Transport header as "RTP/AVPF".

[ATTRIBUTES ]

M A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC 92PBO
4585
IETF RFC
2326

11.4.4.161 MT RTP tolerate RTP/AVP when RTP/AVPF is expected

11.4.4.161.1
[G UIDELINE ] A Serving Endpoint shall accept Transport headers that specify the transport field as
"RTP/AVP" when "RTP/AVPF" is expected.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC SQIR3

4585
IETF RFC
2326

[C OMMENT] Receiving Endpoints that do not support RTP/AVPF can specify RTP/AVP in the
Transport header.

11.4.4.161.2
[G UIDELINE ] A Receiving Endpoint shall accept Transport headers that specify the transport field
as "RTP/AVPF" when "RTP/AVP" is expected.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC PBOYV

4585
IETF RFC
2326

11.4.4.162 MT RTP buffer headers in SETUP

11.4.4.162.1
[G UIDELINE ] If the Serving Endpoint indicates that bfr is an acceptable RTCP feedback message
type for an RTP stream, and the Receiving Endpoint will transmit Buffer Fullness Reports for that
RTP stream, then it shall include the Buffer-Info.dlna.org header (guideline 11.4.4.145) in the RTSP
SETUP request. Furthermore, the BFR parameter shall be present on the Buffer-Info.dlna.org
header, and its value shall be set to 1.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a ESQIR

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 652 –

[C OMMENT] The Serving Endpoint can use the network de-jitter buffer size and the pre-decoder
buffer size along with buffer fullness reported in the bfr RTCP feedback message to compute buffer
levels at the RENEDERING ENDPOINT. See also guideline 11.4.4.32.

11.4.4.162.2
[G UIDELINE ] A Receiving Endpoint may send the Buffer-Info.dlna.org header (guideline 11.4.4.145)
in the RTSP SETUP request.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a n/a IR346

[C OMMENT] Even if BFRs will not be used, the Receiving Endpoint can still include the
Buffer-Info.dlna.org header in the SETUP request. This is particularly useful if the size of the
pre-decoder buffer is smaller than specified in the a=predecbufsize.dlna.org SDP attribute, because
it can allow Serving Endpoint to adapt the encoding rate to match the smaller pre-decoder buffer
size.

11.4.4.163 MT RTP PLAY requests shall not be sent in Playing state

11.4.4.163.1
[G UIDELINE ] A Receiving Endpoint shall send a PAUSE request between each PLAY request in an
RTSP session.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC 45P7Q

2326

[C OMMENT] The PAUSE request is required to bring the RTSP protocol state machine from the
Playing state to the Ready state. (A PLAY request sent while in the Playing state would cause the
serving endpoint to interpret it as a "queued PLAY" request, as defined in 10.5 of IETF RFC 2326.)

11.4.4.163.2
[G UIDELINE ] If the response to a PAUSE request indicates error code 455 ("Method Invalid in the
current state"), then this error should be ignored by the Receiving Endpoint.

[ATTRIBUTES ]

S L DMP DMR M-DMP n/a IETF RFC IAT8S

2326

[C OMMENT] Some Serving Endpoints can enter Ready state at the end of the RTP stream. In that
case they might respond to a PAUSE request with a 455 error. This can be safely ignored by the
Receiving Endpoint.

11.4.4.163.3
[G UIDELINE ] If the response to a PAUSE request indicates error code 501 ("Not Implemented"),
then the Receiving Endpoint shall send a TEARDOWN request to destroy the RTSP session,
followed by creating a new RTSP session.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC Z3MS6

DLNA guidelines; Part 1-1: Architecture and protocols

 – 653 –

2326

[C OMMENT] If PAUSE is not supported by the Serving Endpoint, the only way to bring the RTSP
protocol state machine to Ready state is by sending a TEARDOWN, followed by a new DESCRIBE
and new SETUP requests.

11.4.4.164 MT RTP Play Media Operation

11.4.4.164.1
[G UIDELINE ] If the RTSP protocol state machine of the Receiving Endpoint is in the Ready state,
then it shall implement the Play Media Operation by sending an RTSP PLAY request.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC QA6ZW

2326

[C OMMENT] The RTSP protocol state machine is described in IETF RFC 2326, Clause A.1.

11.4.4.164.2
[G UIDELINE ] If the RTSP protocol state machine of the Receiving Endpoint is not in the Ready state,
then it shall implement the Play Media Operation by bringing the RTSP protocol state machine into
the Ready state, followed by sending a PLAY request as described in guideline 11.4.4.164.1.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC YQA6Z

2326

[C OMMENT] To bring the state machine into Ready state, it might be necessary to send one or more
SETUP requests. In order to be able to send SETUP requests, the Receiving Endpoint might have
to send a DESCRIBE request. If the state machine is in Playing state, guideline 11.4.4.164.1
describes how to reach Ready state.

11.4.4.165 MT RTP Rtp-Info header

[G UIDELINE ] If valid seq and rtptime parameters are available or can be determined, the Serving
Endpoint shall include an Rtp-Info header with those parameters in the response to the PLAY
request.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC DYQA6

2326

11.4.4.166 MT RTP Wall Clock Time sample request

11.4.4.166.1
[G UIDELINE ] If a Receiving Endpoint wants Wall Clock Time samples to be included in the RTP
packets, then it shall include the header WCT.dlna.org: 1 (defined in guideline 11.4.4.146) in the
RTSP PLAY request.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a RG45P

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 654 –

[C OMMENT] Wall Clock Time samples are defined in guideline 11.4.4.34.

11.4.4.166.2
[G UIDELINE ] If a Serving Endpoint supports Wall Clock Time samples in accordance with guideline
11.4.4.34, then it shall understand the WCT.dlna.org header (defined in guideline 11.4.4.146) in a
RTSP PLAY request.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 3EIAT

11.4.4.166.3
[G UIDELINE ] A Serving Endpoint is strongly recommended to include Wall Clock Time samples as
defined in 11.4.4.34. If all of the following conditions are met:

• the RTSP PLAY request contains the WCT.dlna.org header (defined in guideline 11.4.4.146);
• the <val> parameter of the WCT.dlna.org header is 1.
[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a G45P7

11.4.4.166.4
[G UIDELINE ] A Serving Endpoint shall not include Wall Clock Time samples as defined in 11.4.4.34
if all of the following conditions are met:

• the RTSP PLAY request contains the WCT.dlna.org header;

• the <val> parameter of the WCT.dlna.org header is 0.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a MZ3MS

11.4.4.167 MT RTP Seek Media Operation

11.4.4.167.1
[G UIDELINE ] If a Receiving Endpoint supports the Seek Media Operation and the RTSP protocol
state machine is in the Ready state, then it shall implement it by sending an RTSP PLAY request
with the RTSP Range header.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 33EIA

2326

[C OMMENT] RTSP provides seeking capability by the inclusion of the RTSP Range header into the
RTSP PLAY request. This enables random access within the RTSP session.

11.4.4.167.2
[G UIDELINE ] If a Receiving Endpoint supports the Seek Media Operation and the RTSP protocol
state machine is not in the Ready state, then it shall implement it by first bringing the RTSP protocol
state machine into the Ready state, as described in guideline 11.4.4.164.2, and then by sending a
PLAY request, as described in guideline 11.4.4.167.1.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 655 –

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC EIAT8

2326

11.4.4.167.3
[G UIDELINE ] If the Serving Endpoint has specified a limited data range using the
Available-Range.dlna.org header (guideline 11.4.4.144), then the values on the Range header in
the PLAY request should be within the range specified by the Serving Endpoint.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC IMZ3M

2326

[C OMMENT] The Receiving Endpoint is discouraged from seeking outside the limited data range
that was specified by the Serving Endpoint, even though it can do so.

11.4.4.167.4
[G UIDELINE ] A Serving Endpoint that supports the Seek Media Operation shall advertise this
feature using the range SDP attribute (see guideline 11.4.4.192) and by setting the a-val parameter
of the op-param field (defined in 10.1.3.19) or the lop-npt flag of the flags-param field (defined in
10.1.3.24) of the protocolInfo to 1. The Serving Endpoint shall also support the RTSP Range header
in RTSP PLAY requests.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 5P7QQ

2326

11.4.4.167.5
[G UIDELINE ] If a Serving Endpoint supports the Seek Media Operation, it shall implement the
PAUSE method.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 3MS6J

2326

11.4.4.167.6
[G UIDELINE ] RTP sequence numbers and RTP timestamps shall be continuous across jumps of
NPT.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC Y2ZP8

2326

[C OMMENT] As noted in guideline 11.4.4.165, the Serving Endpoint includes the Rtp-Info header
with the seq parameter in the PLAY response, if the value of the seq parameter is known at the time
of issuing the response.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 656 –

11.4.4.168 MT RTP Receiving Endpoint Range header

11.4.4.168.1
[G UIDELINE ] If the Range header is included in a RTSP PLAY request, the header shall use "npt"
range units. ("npt" range units are as indicated in 3.6 of IETF RFC 2326.)

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC 73UE8

2326

11.4.4.168.2
[G UIDELINE ] A Receiving Endpoint shall include no more than 1 Range header in the RTSP PLAY
request.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC QSPMX

2326

11.4.4.168.3
[G UIDELINE ] The Range header shall include exactly 1 range specifier.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC YUFRH

2326

11.4.4.169 MT RTP Serving Endpoint Range header

11.4.4.169.1
[G UIDELINE ] A Serving Endpoint shall support the Range header in RTSP PLAY requests.

If the Range header requests a range that cannot be satisfied (for example, because the Serving
Endpoint does not support the Seek Media Operation), the Serving Endpoint shall respond with
status code 457 ("Invalid Range").

Note that if the Range header specifies a start time that is equal to the start time specified on the
a=range attribute at the SDP session level (see guideline 11.4.4.192) the Range header shall be
considered valid, and the Serving Endpoint shall not respond with status code 457 even if does not
support the Seek Media Operation.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 6W93G

2326

[C OMMENT] This entry applies even if Serving Endpoint does not support the Seek Media
Operation.
Example:

If the Serving Endpoint specifies "a=range:npt=0-" at the SDP session level, then the header
"Range: npt=0-" is always valid, even if Serving Endpoint does not support the Seek Media
Operation.

The Serving Endpoint that does not support the Seek Media Operation can simply do a string
compare of the value specified on the Range header and the value indicated in SDP, and reject all
other range strings with status code 457.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 657 –

11.4.4.169.2
[G UIDELINE ] A Serving Endpoint shall include the Range header in the response to RTSP PLAY
requests. The Range header shall use "npt" range units.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC V9K2V

2326

[C OMMENT] This guideline applies even if Serving Endpoint does not support the Seek Media
Operation.

11.4.4.169.3
[G UIDELINE ] If the Serving Endpoint is unable to determine the starting NPT time value of the
content, such as for live captured content, then the npt range units may be specified as "now-".

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a IETF RFC S9MDT

2326

[C OMMENT] When streaming live content, the Serving Endpoint might be unable to provide
numerical values for the Range header.

11.4.4.170 MT RTP Scale header

[G UIDELINE ] If a Scale header is included in the PLAY request then the Serving Endpoint shall
indicate the scale value that it chose using a Scale header in the PLAY response.

The RTP Serving Endpoint shall support the Scale header in a RTSP PLAY request if the value of
the Scale header is numerically identical to the one of the scale-param values in the scale-value
token. Furthermore, the RTP Serving Endpoint shall support all scale-value tokens that are listed in
the ps-param of the 4th field protocolInfo. The RTSP Scale header is defined in subclause 12.34 of
IETF RFC 2326.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC HHKDS

2326

[C OMMENT] If Receiving Endpoint uses a scale value that is not included in the server-speed
parameter of the maxsp-param (defined in 10.1.3.26) in the 4th field of the protocolInfo then Serving
Endpoint can choose an alternate scale value at its discretion.

11.4.4.171 MT RTP Scan Media Operations

11.4.4.171.1
[G ENERAL ] Fast Forward Scan, Slow Forward Scan, Fast Backward Scan, Slow Backward Scan.

11.4.4.171.2
[G UIDELINE ] Serving Endpoints and Receiving Endpoints that implement the RTP Media Transport
may support any of the Scan Media Operations

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 658 –

[ATTRIBUTES ]

O A DMS DMP DMR +PU+ M-DMS M-DMP n/a IETF RFC JY2ZP
2326

11.4.4.171.3
[G UIDELINE ] A Receiving Endpoint should use the Scale header of the PLAY method to signal any
of the Scan Media Operations.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC O73UE

2326

[C OMMENT] The Scale header is recommended over the Speed header, because Scale allows the
Fast Forward Scan Media Operation to occur using less bandwidth than with the Speed header.

11.4.4.171.4
[G UIDELINE ] A Receiving Endpoint may use the Speed header of the PLAY method to signal a Fast
Forward Scan or Slow Forward Scan media operation.

[ATTRIBUTES ]

O R DMP DMR M-DMP n/a IETF RFC 6QSPM

2326

11.4.4.172 MT RTP Serving Endpoint Scan Media Operations support

11.4.4.172.1
[G UIDELINE ] If Scan Media Operations are supported, the Serving Endpoint shall support the Scale
and Range headers of the PLAY method.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC YYUFR

2326

11.4.4.172.2
[G UIDELINE ] If Scan Media Operations are supported, the Serving Endpoint shall implement the
PAUSE method.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 46W93

2326

11.4.4.173 MT RTP Speed header support

11.4.4.173.1
[G UIDELINE ] A Serving Endpoint may support the Speed header of the PLAY method.

[ATTRIBUTES ]

O R DMS +PU+ M-DMS n/a IETF RFC YV9K2

2326

DLNA guidelines; Part 1-1: Architecture and protocols

 – 659 –

11.4.4.173.2
[G UIDELINE ] If a Speed header is included in the PLAY request then the Serving Endpoint shall
indicate the speed value that it chose using a Speed header in the PLAY response

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC DS9MD

2326

[C OMMENT] If Receiving Endpoint uses a speed value that exceeds the attribute value of the
maxsp-param (10.1.3.26) in the 4th field of the protocolInfo then Serving Endpoint can choose an
alternate Speed value at its discretion

11.4.4.173.3
[G UIDELINE ] If the Receiving Endpoint uses a value of the Speed header that is not included in the
4th field of the protocolInfo then the Serving Endpoint may choose an alternate value of the Speed
header.

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a IETF RFC WYYUF

2326

11.4.4.173.4
[G UIDELINE ] A Receiving Endpoint shall be prepared to receive a different value of the Speed
header in the PLAY response than what it requested in the PLAY request.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC Q6QSP

2326

11.4.4.173.5
[G UIDELINE ] If Receiving Endpoint specifies the Speed header in a PLAY request, its value shall be
greater than zero.

[ATTRIBUTES ]

M R DMP DMR M-DMP n/a IETF RFC ZO73U

2326

[C OMMENT] The guideline clarifies that the Speed Header value cannot be zero or negative.

11.4.4.174 MT RTP buffer parameters in PLAY response

11.4.4.174.1
[G UIDELINE ] The Serving Endpoint may indicate updated buffer parameters required for playback
of the media stream by using the following RTSP headers in the response to the PLAY request:

• predec-buffer-size-line = "Predec-Buffer-Size.dlna.org" *LWS ":" *LWS url-size-pair *(*LWS ","

*LWS url-size-pair);
• url-size-pair = "url" "=" stream-url ";" "size" "=" size-val;
• stream-url = <case sensitive, HTTP-escaped URL string, with a maximum length of 1 024 B in its
UTF-8 encoded form>;
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 660 –

• size-val = value;
• value = 1*DIGIT.
Note that the literals, "url" and "size" are case sensitive.

The size-val parameter specifies the minimum pre-decoder buffer size, in bytes, required for the
RTP stream identified by stream-url for the specified play-speed/scale setting.

• initial-buffering-line = "Initial-Buffering.dlna.org" *LWS ":" *LWS "url-time-pair *(*LWS "," *LWS

url-time-pair)
• url-time-pair = "url" "=" stream-url ";" "time" "=" time-val
• stream-url = stream-url = <case sensitive, HTTP-escaped URL string, with a maximum length of
1 024 B in its UTF-8 encoded form>
• time-val = value
• value = 1*DIGIT
Note that the literals, "url" and "time", are case sensitive.

The time-val parameter specifies the minimum initial buffering in NPT milliseconds the Receiving
Endpoint may use for the media stream identified by stream-url. NPT and its relationship to units of
time are defined in 3.6 of IETF RFC 2326.

stream-url is the URL for the RTP stream that the value tokens apply to. It may be either an absolute
URL or a relative URL. (See IETF RFC 2326, C.1.1, for rules for how to convert a relative URL to an
absolute URL.)

Example:

• Predec-Buffer-Size.dlna.org: url=audio;size=11200, url=video;size=243250

Initial-Buffering.dlna.org: url=audio;time=500, url=video;time=1000
[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC OJY2Z

2326

[C OMMENT] The Serving Endpoint can specify the minimum pre-decoder buffer size required to
avoid pre-decoder buffer overflow and underflow when receiving an RTP stream as a result of RTSP
PLAY request.

If the values of the RTSP headers Speed and Scale are both 1, then Pre-Decoder Buffer Size will be
less than or equal to the value of the a=predecbufsize.dlna.org attribute signaled in the SDP. For
Speed or Scale values not equal to 1, Pre-Decoder Buffer Size can be larger than the value of the
a=predecbufsize.dlna.org attribute in SDP.

The NPT time can be derived from the decode time of the RTP payload.

11.4.4.174.2
[G UIDELINE ] If the Predec-Buffer-Size.dlna.org header is specified in the response to a PLAY
request, then the Receiving Endpoint should use a pre-decoder buffer that is at least as large as the
value specified by this header in order to avoid decoder underflow during Streaming Transfer.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a n/a 346W9

DLNA guidelines; Part 1-1: Architecture and protocols

 – 661 –

[C OMMENT] If the pre-decoder buffer is combined with the network de-jitter buffer, this guideline
refers to the size of the combined buffer.

11.4.4.175 MT RTP Pause Media Operation

11.4.4.175.1
[G UIDELINE ] If the Serving Endpoint and the Receiving Endpoint support the Pause Media
Operation, then the Receiving Endpoint should implement it by sending an RTSP PAUSE request.

[ATTRIBUTES ]

S C DMP DMR M-DMP n/a IETF RFC OYV9K

2326

[C OMMENT] RTSP PAUSE request simply stops the RTP media data transport, but keeps the RTSP
session alive for future requests.

Serving Endpoint indicates support for Pause media operation by setting the rtsp-pause flag in the
DLNA.ORG_FLAGS param (defined in 10.1.3.24) in the 4th field of the protocolInfo.

11.4.4.175.2
[G UIDELINE ] If the response to a PAUSE request indicates error code 455 ("Method Invalid in the
current state"), then this error should be ignored by the Receiving Endpoint.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a IETF RFC BOJY2

2326

[C OMMENT] Some serving endpoints can enter Ready state at the end of the RTP stream. In that
case they might respond to a PAUSE request with a 455 error. This can be safely ignored by the
Receiving Endpoint.

11.4.4.175.3
[G UIDELINE ] When a RTSP session is paused, then the Serving Endpoint shall stop transmiting
RTP packets for all RTP streams in the RTSP session.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC JZO73

2326
IETF RFC
3550

[C OMMENT] It is not acceptable to force the Receiving Endpoint to drop packets.

11.4.4.176 MT RTP PAUSE requests with a Range header

11.4.4.176.1
[G UIDELINE ] A Receiving Endpoint should not include the Range header in a PAUSE request.

[ATTRIBUTES ]

S L DMP DMR M-DMP n/a IETF RFC QQ6QS

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 662 –

2326

[C OMMENT] The Range header in the PLAY request can be used to accomplish a similar function
as a Range header in a PAUSE request.

11.4.4.176.2
[G UIDELINE ] A Serving Endpoint may respond to a PAUSE request that contains a Range header
with error 457 ("Invalid Range").

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a IETF RFC ZWYYU

2326

[C OMMENT] Serving Endpoints are not required to implement "queued PAUSE".

11.4.4.177 MT RTP Pause-Release Media Operation

[G UIDELINE ] If the Serving Endpoint and the Receiving Endpoint both support the Pause-Release
Media Operation, then the Receiving Endpoint shall implement the Pause Media Operation by
sending a PLAY request. The PLAY request shall not include the Range header.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC R346W

2326

[C OMMENT] Serving Endpoint indicates support for Pause media operation by setting the
rtsp-pause flag in the DLNA.ORG_FLAGS param (defined in 10.1.3.24) in the 4th field of the
protocolInfo.

11.4.4.178 MT RTP time stamp clock is not paused while in RTSP Paused state
11.4.4.178.1
[G UIDELINE ] If a Serving Endpoint transitions from RTSP Paused state into the RTSP Playing state,
then the RTP time stamps shall be incremented by the amount of NPT (measured in RTP time stamp
units) that the Serving Endpoint spent in RTSP Paused state.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC SBOJY

2326

[C OMMENT] The RTP time stamp "clock" is not paused when the Serving Endpoint is in Paused
state. After a Pause-Release or Seek Media operation, the RTP time stamps shall be increased by
an amount corresponding to the length of time that the server was paused.

11.4.4.178.2
[G UIDELINE ] If a Serving Endpoint transitions from RTSP Paused state into RTSP Playing state,
then it shall support that the RTP time stamps of the RTP packets received after entering Playing
state may not be continous with time stamps of RTP packets received prior to entering Paused
state.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 663 –

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 6JZO7

2326

[C OMMENT] A Receiving Endpoint might need to recompute the mapping between NPT time and
RTP timestamp each time it receives a PLAY response.

11.4.4.179 MT RTP End Of Stream indication support

[G UIDELINE ] If a Receiving Endpoint wants to receive an ANNOUNCE request when the Serving
Endpoint has reached the end of the requested play range, then the Receiving Endpoint shall
include the Supported header with the feature-tag dlna.announce in the PLAY request.

Example:

• Supported: dlna.announce
[ATTRIBUTES ]

M A DMP DMR M-DMP n/a IETF RFC 7QQ6Q

2326

11.4.4.180 MT RTP end of stream indication

11.4.4.180.1
[G UIDELINE ] If a PLAY request includes the Supported header with the feature tag dlna.announce,
then the Serving Endpoint should send an ANNOUNCE request to the Receiving Endpoint when the
last RTP packet has been sent.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC 6ZWYY

2326

[C OMMENT] The purpose of the ANNOUNCE request is to indicate that Serving Endpoint has
reached the end of the requested play range, and to indicate the last RTP sequence number for
each RTP stream.

11.4.4.180.2
[G UIDELINE ] The ANNOUNCE request for the purpose of sending an end of stream indication shall
include the following RTSP headers:

• Session;
• CSeq;
• Rtp-Info;
• Event-Type.dlna.org.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 8SBOJ

2326

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 664 –

11.4.4.180.3
[G UIDELINE ] The Rtp-Info header shall specify the seq parameter for each selected RTP stream.
The value of the seq parameter shall be equal to the RTP sequence number of the last RTP packet
plus one.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC S6JZO

2326

[C OMMENT] The Rtp-Info header indicates the "next" RTP sequence number for each RTP stream.
The "next" sequence number is the same as the last sequence number plus one.

11.4.4.180.4
[G UIDELINE ] The Event-Type.dlna.org header shall specify the event-code 2000.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a P7QQ6

[C OMMENT] Event code 2000 indicates that Serving Endpoint has reached the end of the requested
play range.

11.4.4.181 MT RTP current limited data range indication

11.4.4.181.1
[G UIDELINE ] A Serving Endpoint may send an ANNOUNCE request to indicate the current limited
data range (seekable range) if all of the following conditions are met.

• A PLAY request included the Supported header with the feature tag dlna.announce.
• The Available-Range.dlna.org header was included in the DESCRIBE response.
• The current limited seekable range, which is defined as the closed range bounded by the
UCDAM's data positions of r 0 and r N , has changed since the last time Serving Endpoint included
the Available-Range.dlna.org header in any of the following RTSP methods: An ANNOUNCE
request to indicate the current limited seekable range, a DESCRIBE response, an OPTIONS
response
• Serving Endpoint has not sent an ANNOUNCE request to indicate the current limited seekable
range in the last N seconds. (The parameter N is defined in guidelines 11.4.4.181.5 and
11.4.4.181.6.)
[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC T8SBO

2326

[C OMMENT] See guideline 10.1.3.28.4 for a definition of limited data range.

11.4.4.181.2
[G UIDELINE ] If a Serving Endpoint sends an ANNOUNCE request to indicate the current limited
seekable range, then the request shall include the following RTSP headers:

• Session;
• CSeq;
DLNA guidelines; Part 1-1: Architecture and protocols
 – 665 –

• Event-Type.dlna.org (guideline 11.4.4.143);

• Available-Range.dlna.org (guideline 11.4.4.144).
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a AT8SB

11.4.4.181.3
[G UIDELINE ] If the Available-Range.dlna.org header is included in an ANNOUNCE request, the
parameters on that header should be set as described in guideline 11.4.4.154.2.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a MS6JZ

11.4.4.181.4
[G UIDELINE ] If a Serving Endpoint sends an ANNOUNCE request to indicate the current limited
seekable range, the Event-Type.dlna.org header in that request shall specify the event-code 9000.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a PMX34

[C OMMENT] Event code 9000 indicates that the purpose of the ANNOUNCE request is to indicate
the current limited seekable range.

11.4.4.181.5
[G UIDELINE ] The recommended value for N in guideline 11.4.4.181.1 is 20.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a FRHZG

11.4.4.181.6
[G UIDELINE ] The value for N in guideline 11.4.4.181.1 shall not be less than 1.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a 93GF2

11.4.4.182 MT RTP OPTIONS request

11.4.4.182.1
[G UIDELINE ] A Serving Endpoint shall support the Session header in an OPTIONS request.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC K2V43

2326

[C OMMENT] A Receiving Endpoint can send an OPTIONS request with a Session header as a way
to keep the RTSP session alive, or to query the current limited seekable range.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 666 –

11.4.4.182.2
[G UIDELINE ] If the Session header in an OPTIONS request identifies an RTSP session for which
the Serving Endpoint supports the Seek Media Operation, and if the Serving Endpoint supports the
Limited Random Access Data Availability model this content binary (see guideline 10.1.3.28.4) for
the RTSP session, then the Available-Range.dlna.org header (guideline 11.4.4.144) shall be
included in the OPTIONS response.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC MDTQF

2326

11.4.4.182.3
[G UIDELINE ] If the Available-Range.dlna.org header is included in an OPTIONS response, the
parameters on that header should be set as described in guideline 11.4.4.154.2.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a KDS6Y

11.4.4.182.4
[G UIDELINE ] If the DESCRIBE response included the Available-Range.dlna.org header, then the
Receiving Endpoint may query the Serving Endpoint about the current limited seekable range by
sending an OPTIONS request with the Session header.

[ATTRIBUTES ]

O A DMP DMR M-DMP n/a n/a TVQUZ

11.4.4.183 MT RTP Stop Media Operation

11.4.4.183.1
[G UIDELINE ] A Receiving Endpoint shall implement the Stop Media Operation by sending a RTSP
TEARDOWN request for the aggregate control URI.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC 5Y4A5

2326

[C OMMENT] The RTSP TEARDOWN request ends the RTSP session, but the same TCP
connection can be used to start another RTSP session.

11.4.4.183.2
[G UIDELINE ] A Receiving Endpoint should wait for the response from the Serving Endpoint after
sending a TEARDOWN request.

[ATTRIBUTES ]

S C DMP DMR M-DMP n/a IETF RFC 3TVQU

2326

11.4.4.184 MT RTP SDP Character Set

[G UIDELINE ] The SDP description shall be encoded in the ISO 10646 character set in UTF-8.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 667 –

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC HKDS6

2327

[C OMMENT] RTSP also uses this character set.

11.4.4.185 MT RTP SDP case sensitivity

[G UIDELINE ] The SDP protocol is a case-sensitive protocol.

[ATTRIBUTES ]

M A DMS DMP DMR DMC M-DMS M-DMP n/a IETF RFC 9MDTQ
M-DMC 2327

11.4.4.186 MT RTP SDP optional values

[G UIDELINE ] A Receiving Endpoint shall ignore (or tolerate) any SDP attributes that it does not
support.

[ATTRIBUTES ]

M R DMP DMR M-DMP n/a IETF RFC UFRHZ

2327

11.4.4.187 MT RTP SDP field order

11.4.4.187.1
[G UIDELINE ] SDP fields shall be specified in the order defined by IETF RFC 2327, Appendix A.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC 9K2V4

2327

11.4.4.187.2
[G UIDELINE ] If SDP fields are not in the defined order, the Receiving Endpoint should accept and
process those fields.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a IETF RFC W93GF

2327

11.4.4.188 MT RTP SDP session description fields

11.4.4.188.1
[G UIDELINE ] The following SDP fields are required for the SDP session:

• version field (v=);

• origin field (o=);
• session name field (s=);
• time field (t=);
• control URL attribute field (a=control);
• range attribute field (a=range);
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 668 –

• DLNA contentFeatures field (a=contentFeatures.dlna.org).

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC SPMX3

2326
IETF RFC
2327

11.4.4.188.2
[G UIDELINE ] The following SDP fields are optional for the SDP session:

• Bandwidth modifier field (b=);

• Connection field (c=);
• DLNA scmsFlag field (a=scmsFlag.dlna.org).
[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC 3UE86

2327

11.4.4.188.3
[G UIDELINE ] If the connection field is not specified in the SDP session, then it shall be specified in
each SDP media description section.

[ATTRIBUTES ]

M R DMS +PU+ M-DMS n/a IETF RFC GF288

2327

11.4.4.189 MT RTP contents of SDP origin field

11.4.4.189.1
[G UIDELINE ] The SDP origin field (o=) shall have the following format:

• sdp-origin-field = "o=" <username> SP <session id> SP <version> SP <network type> <address

type> SP <address>.
The literal, "o=", is case sensitive.

<username>, <session id>, <network type>, <address type>, and <address> shall be set in
accordance to IETF RFC 2327 with the exceptions mentioned in the next guideline entry.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC V43RH

2327

11.4.4.189.2
[G UIDELINE ] Allowed exceptions:

• <username> may be set to "-".

• <address> may be unspecified ("0.0.0.0" when IPv4 is used or “::” when IPv6 is used).
[ATTRIBUTES ]

O L DMS +PU+ M-DMS n/a n/a TQF9O

[C OMMENT] Recommendations address privacy concerns.

DLNA guidelines; Part 1-1: Architecture and protocols
 – 669 –

11.4.4.190 MT RTP contents of SDP session name field

11.4.4.190.1
[G UIDELINE ] The SDP session name field (s=) shall be present. It has the following format:

• sdp-session-name-field = "s="<session name>.

Note that the literal, "s=", is case sensitive.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC S6YJS

2327

11.4.4.190.2
[G UIDELINE ] <session name> may be set to a single space character (' ') when session name is not
available.

[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a n/a QUZYZ

11.4.4.191 MT RTP SDP control attribute

11.4.4.191.1
[G UIDELINE ] The a=control attribute shall refer to a resource on the Serving Endpoint. The scheme
of the URL in the control attribute, if any, shall be "rtsp". The host element, if any, of the URL in the
a=control attribute shall belong to the Serving Endpoint. This URL shall be a case sensitive
HTTP-escaped string, with a maximum length of 1 024 B in its UTF-8 encoded form.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 4A5ZG

2326

[C OMMENT] It is not allowed to use a=control as a way to redirect the Receiving Endpoint to a
different Serving Endpoint or as a way to replace RTSP with another protocol.

Subclause 3.2 of IETF RFC 2326 defines the syntax of RTSP URLs.

11.4.4.191.2
[G UIDELINE ] Receiving Endpoint shall support the use of relative URLs in the a=control attribute.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC NQCR9

2326

[C OMMENT] The following are examples of a=control attributes that specify relative URLs:

• a=control:stream=1
• a=control:*
The use of relative URLs is described in C.1.1 of IETF RFC 2326.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 670 –

11.4.4.192 MT RTP SDP range attribute at the SDP session level

11.4.4.192.1
[G UIDELINE ] The a=range attribute at the SDP session level shall use "npt" range units.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC 24UR4

2326

[C OMMENT] "npt" range units are defined in 3.6 of RFC 2326.

11.4.4.192.2
[G UIDELINE ] If a Serving Endpoint supports the Full Random Access Data Availability model for a
content binary, then the seekable range shall be indicated using the a=range attribute at the SDP
session level. In this case, the a=range attribute shall include both a start time and a stop time.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC LNQCR

2326

[C OMMENT] The a=range attribute specifies the start and stop time only if the seekable range never
changes.

11.4.4.192.3
[G UIDELINE ] If a Serving Endpoint supports Limited Random Access Data Availability model for a
content binary, then the a=range attribute at the SDP session level shall specify an open-ended
interval. The start time shall be specified as a value that falls within the current seekable range,
defined as the closed range bounded by the UCDAM's data positions of r 0 and r N , or as "now".

Examples:

• a=range:npt=now-
• a=range:npt=0-
[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a IETF RFC Y4A5Z

2326

11.4.4.193 MT RTP SDP scmsFlag.dlna.org attribute

[G UIDELINE ] If used, the format of the scmsFlag.dlna.org SDP attribute field shall comply with the
following syntax:

• scmsFlag.dlna.org = "a=scmsFlag.dlna.org:" flagValue;

• with syntax and symantics of flagValue as defined in guideline 11.4.3.9 of HTTP MT.
[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a VQUZY

11.4.4.194 MT RTP SDP contentFeatures.dlna.org attribute

[G UIDELINE ] The format of the contentFeatures.dlna.org SDP attribute field shall be as follows:

• contentFeatures.dlna.org = "contentFeatures.dlna.org:" 4th_field;

DLNA guidelines; Part 1-1: Architecture and protocols
 – 671 –

• note that 4th_field is defined in guideline 10.1.3.17.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a DS6YJ

[C OMMENT] The 4th_field is the 4th field of the protocolInfo value supplied by the serving endpoint
for this content binary as defined in guideline 10.1.3.17.

11.4.4.195 MT RTP SDP media description fields

11.4.4.195.1
[G UIDELINE ] The following SDP fields are required for each media description:

• media field ('m=');

• control URL attribute field (a=control).
[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC DTQF9

2326
IETF RFC
2327

11.4.4.195.2
[G UIDELINE ] The following SDP fields are optional for each media description:

• rtpmap attribute field (a=rtpmap), only required if conditions described in guideline 11.4.4.197
apply;
• fmtp attribute field (a=fmtp), only required if mandated by the Media Format Profile;
• Bandwidth modifier field (b=);
• connection field (c=);
• range attribute field (a=range);
• acceptable RTP/AVPF feedback message types (a=rtcp-fb);
• DLNA pre-decoder buffer size (a=predecbufsize.dlna.org);
• DLNA minimum required pre-decoder buffer size (a=adaptation-predecbufsize.dlna.org);
• DLNA transmission rate adaptation field (a=trans-rate-adapt.dlna.org).
[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a IETF RFC 2V43R

2326
IETF RFC
2327

11.4.4.196 MT RTP contents of SDP media field

[G UIDELINE ] The SDP media field (m=) shall have the following format:

• sdp-media-field = "m=" media SP port SP transport SP payload-format;

• port = "0";
• transport = "RTP/AVP" | "RTP/AVPF";
• payload-format = 1*DIGIT; valid RTP payload type numbers.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 672 –

Note that the literals, "m=", "RTP/AVP", and "RTP/AVPF", are case sensitive.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 3GF28

2326
IETF RFC
2327

[C OMMENT] <port> shall be zero because the Receiving Endpoint will select a different port using
the RTSP SETUP method.

11.4.4.197 MT RTP SDP Rtpmap attribute field

[G UIDELINE ] The SDP rtpmap attribute is required for RTP dynamic payload types, or for static
payload types if a non-standard clock speed or other RTP parameters need to be communicated to
the Receiving Endpoint.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC RHZG5

2327

[C OMMENT] See Clause 6 of IETF RFC 2327 for an example on using the rtpmap attribute.

11.4.4.198 MT RTP SDP range attribute at the SDP media level

11.4.4.198.1
[G UIDELINE ] If the start and stop times of all media streams are readily available, and all media
streams do not have an identical start time, or do not have an identical stop time, then the Serving
Endpoint is strongly recommended to include the a=range attribute at the SDP media level for each
media stream.

[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a IETF RFC 43RHS

2326

[C OMMENT] If media streams are stored in a file which is compliant with the file format defined in
3GPP TS 26.244, then the start and stop times of each media stream are usually readily available as
fields in the file format.

11.4.4.198.2
[G UIDELINE ] The a=range attribute at the SDP media level shall use "npt" range units.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC 6GKZQ

2326

11.4.4.198.3
[G UIDELINE ] The a=range attributes at the SDP media level shall all be subranges of the range
indicated by the a=range attribute at the SDP session level.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC F9OV4

DLNA guidelines; Part 1-1: Architecture and protocols

 – 673 –

2326

11.4.4.199 MT RTP SDP b= field

11.4.4.199.1
[G UIDELINE ] A Serving Endpoint should include a SDP b= field with the AS bandwidth modifier for
each RTP stream.

[ATTRIBUTES ]

S L DMS +PU+ M-DMS n/a IETF RFC YJSWA

2327

[C OMMENT] This bandwidth modifier specifies the maximum bit rate of the RTP stream.

11.4.4.199.2
[G UIDELINE ] A Serving Endpoint should include a SDP b= field with the RR bandwidth modifier for
each RTP stream.

[ATTRIBUTES ]

S L DMS +PU+ M-DMS n/a IETF RFC ZYZLT

3555

[C OMMENT] This bandwidth modifier allows the Serving Endpoint to specify the bit rate used for
RTCP Receiver Reports.

11.4.4.199.3
[G UIDELINE ] A Serving Endpoint should include a SDP b= field with the RS bandwidth modifier for
each RTP stream.

[ATTRIBUTES ]

S L DMS +PU+ M-DMS n/a IETF RFC 5ZGPK

3555

11.4.4.199.4
[G UIDELINE ] A Receiving Endpoint shall support the AS bandwidth modifier for the SDP b= field.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC CR9YS

2327

[C OMMENT] The bit rate allowed for RTCP Receiver Reports is 2,5 % of the value on the b=AS field,
unless overruled by a b=RR field.

11.4.4.199.5
[G UIDELINE ] A Receiving Endpoint shall support the RR bandwidth modifier for the SDP b= field.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC UR4XV

3555

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 674 –

[C OMMENT] b=RR:0 means that Receiving Endpoint shall not send any RTCP Receiver Reports.

11.4.4.200 MT RTP/AVPF support in SDP

11.4.4.200.1
[G UIDELINE ] A Serving Endpoint may use the RTP/AVPF profile for RTCP-based feedback in one
or more of the media descriptions in SDP.

[ATTRIBUTES ]

O C DMS +PU+ M-DMS n/a IETF RFC ZLTOT

4585

11.4.4.200.2
[G UIDELINE ] If the Serving Endpoint uses the RTP/AVPF profile for an RTP stream, this shall be
indicated by setting the <transport> field in the media field to "RTP/AVPF" and by using the
a=rtcp-fb attribute to specify the permitted RTCP feedback messages types.

[ATTRIBUTES ]

M C DMS +PU+ M-DMS n/a IETF RFC GPK9T

4585

[C OMMENT] The following is a sample media description, which indicates support for RTP/AVPF
and which specifies that the nack feedback message type is supported:

• m=audio 0 RTP/AVPF 14;

• a=rtcp-fb:14 nack.
11.4.4.201 MT RTP Tolerate RTP/AVPF in SDP
[G UIDELINE ] A Receiving Endpoint shall tolerate media descriptions that specify the RTP/AVPF
profile. If a Receiving Endpoint does not support the RTP/AVPF profile, it shall treat the media
description as if it specified the RTP/AVP profile.

[ATTRIBUTES ]

M C DMP DMR M-DMP n/a IETF RFC 9YSY6

4585

11.4.4.202 MT RTP/AVPF nack feedback message type in SDP

[G UIDELINE ] A Receiving Endpoint should support the nack RTCP feedback message type in the
RTP/AVPF profile.

[ATTRIBUTES ]

S L DMP DMR M-DMP n/a IETF RFC 4XV7O

4585

11.4.4.203 MT RTP bfr feedback message type in SDP

[G UIDELINE ] A Receiving Endpoint should support the bfr RTCP feedback message type.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a n/a SY6VW

[C OMMENT] Guideline 11.4.4.57.3 describes the syntax of the bfr RTCP feedback message.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 675 –

11.4.4.204 MT RTP buffer fullness support indication in SDP

11.4.4.204.1
[G UIDELINE ] If the Serving Endpoint expects to receive Buffer Fullness Reports (BFRs) from the
Receiving Endpoint, it shall use the RTP/AVPF profile for the RTP stream, and it shall specify bfr as
one of the acceptable feedback message types, as described in guideline 11.4.4.200.2.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a V7O96

11.4.4.204.2
[G UIDELINE ] When the rtcp-fb-id parameter of the rtcp-fb attribute is set to "bfr", the corresponding
rtcp-fb-param parameter shall be set to a byte string representation of the maximum interval
between BFRs sent from the Receiving Endpoint to the Serving Endpoint.

Example:

• a=rtcp-fb:96 bfr 500

In this example, "500" indicates that a BFR shall be sent at least once every 500 ms.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a IETF RFC 7O96E

4585

[C OMMENT] ”rtcp-fb-id” and “rtcp-fb-param" are defined in IETF RFC 4585.

11.4.4.205 MT RTP support trr-int SDP parameter if RTP/AVPF is supported

[G UIDELINE ] A Receiving Endpoint which supports the RTP/AVPF profile shall implement support
for the trr-int parameter in the a=rtcp-fb attribute.

[ATTRIBUTES ]

M L DMP DMR M-DMP n/a IETF RFC PK9TG

4585

[C OMMENT] The trr-int parameter allows the Serving Endpoint to specify a minimal time interval
between full (complete) RTCP Receiver Reports.

11.4.4.206 MT RTP pre-decoder buffer size indication in SDP

11.4.4.206.1
[G UIDELINE ] The Serving Endpoint should indicate the minimum pre-decoder buffer size that is
required for the media stream using the following SDP media-level attribute:

• predecbufsize-attribute = "a=predecbufsize.dlna.org:" value;

• value = 1*DIGIT.
Note that the literal, "a=predecbufsize.dlna.org:", is case sensitive.

The value token specifies the required minimum pre-decoder buffer size in bytes for the media
stream that the Receiving Endpoint shall have for normal speed playback (speed=1, scale=1).

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 676 –

Example:

• a=predecbufsize.dlna.org:480750
[ATTRIBUTES ]

S A DMS +PU+ M-DMS n/a n/a YSY6V

[C OMMENT] The Serving Endpoint can specify the required minimum pre-decoder buffer size for
the media stream to avoid the Receiving Endpoint (pre-decoder) buffer underflow.

11.4.4.206.2
[G UIDELINE ] The attribute predecbufsize.dlna.org shall not exceed the size of the pre-decoder
buffer defined in the Media Format Profile used.

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a XV7O9

[C OMMENT] DLNA Media Format Profile refers to underlying standards (codecs or system layer)
which in turn define the size of pre-decoder buffer.

11.4.4.206.3
[G UIDELINE ] If the a=predecbufsize.dlna.org SDP attribute is specified, then the Receiving
Endpoint should use a pre-decoder buffer that is at least as large as the value specified by this
attribute in order to avoid decoder underflow.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a n/a QF9OV

11.4.4.207 MT RTP Minimum required pre-decoder buffer size indication in SDP

11.4.4.207.1
[G UIDELINE ] The Serving Endpoint that supports encoding rate adaptation mechanisms may
indicate absolute minimum required pre-decoder buffer size for the media stream based on its
encoding rate adaptation capabilities using the following SDP media-level attribute:

• adaptation-predecbufsize-attribute = "a=adaptation-predecbufsize.dlna.org:" value;

• value = 1*DIGIT.
Note that the literal, "a=adaptation-predecbufsize.dlna.org:", is case sensitive.

This specifies the absolute minimum pre-decoder buffer size in bytes that the Receiving Endpoint
shall have to be able to render this media stream.

Example:

• a=adaptation-predecbufsize.dlna.org:84752
[ATTRIBUTES ]

O A DMS +PU+ M-DMS n/a n/a 6YJSW

[C OMMENT] The Serving Endpoint can support adapting the encoding rate of the media stream to
support a pre-decoder buffer size at the Receiving Endpoint that is smaller than the minimum

DLNA guidelines; Part 1-1: Architecture and protocols

 – 677 –

required pre-decoder buffer size. The absolute minimum pre-decoder buffer size when the encoding
rate is adapted, can be signaled by the Serving Endpoint using this SDP attribute.

Examples of encoding rate adaptation mechanisms are trans-rating, trans-coding and live encoding
at different bit rates.

11.4.4.207.2
[G UIDELINE ] Exceed the value of the attribute predecbufsize.dlna.org.

[ATTRIBUTES ]

M L DMS +PU+ M-DMS n/a n/a UZYZL

11.4.4.207.3
[G UIDELINE ] If the a=adaptation-predecbufsize.dlna.org SDP attribute is specified then the
Receiving Endpoint should use a pre-decoder buffer of a size that is at least as large as the value
specified by this attribute.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a n/a A5ZGP

11.4.4.208 MT RTP SDP transmission rate adaptation field

11.4.4.208.1
[G UIDELINE ] If the Serving Endpoint supports adapting the transmission rate of the RTP stream
without also adapting the encoding rate by the same amount, then it shall include the
a=trans-rate-adapt.dlna.org:1 attribute at the SDP media-level. The syntax for the
a=trans-rate-adapt.dlna.org attribute is as follows:

• trans-rate-adapt-attribute = "a=trans-rate-adapt.dlna.org:" bin

• bin = "0" | "1"
Note that the literal, "a=trans-rate-adapt.dlna.org:", is case sensitive.

The bin token is 0 if no transmission rate adaptation will be performed, 1 if transmission rate
adaptation is possible.

Note that even if the a=trans-rate-adapt.dlna.org SDP attribute indicates that transmission rate
adaptation is possible, the Serving Endpoint is not allowed to perform transmission rate adaptation
unless additional requirements are satisfied (see guideline 11.4.4.33).

[ATTRIBUTES ]

M A DMS +PU+ M-DMS n/a n/a QCR9Y

[C OMMENT] If the Serving Endpoint supports transmission rate adaptation, i.e., speed up or slow
down the transmission rate of the RTP packets, it indicates this by specifying 1 on the <bin> field of
the a=trans-rate-adapt.dlna.org SDP attribute.

11.4.4.208.2
[G UIDELINE ] If the Receiving Endpoint is transmitting Buffer Fullness Reports and the <bin> field of
the a=trans-rate-adapt.dlna.org attribute is equal to 1, then the Receiving Endpoint shall decide the
rate at which content is presented.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 678 –

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a 4UR4X

11.4.4.208.3
[G UIDELINE ] If the Receiving Endpoint is transmitting Buffer Fullness Reports and the <bin> field of
the a=trans-rate-adapt.dlna.org attribute is equal to 1, then a Receiving Endpoint is recommended
not to recover Serving Endpoints clock.

[ATTRIBUTES ]

S A DMP DMR M-DMP n/a n/a JSWA5

[C OMMENT] Furthermore, clock recovery based on Target Transmission Timestamps (e.g. RTP
time stamps for PS/TS encapsulation) is not possible when transmission rate adaptation is
performed.

11.4.4.208.4
[G UIDELINE ] If the Receiving Endpoint specifies a Target Buffer Duration using the
Buffer-Info.dlna.org header (guideline 11.4.4.145) and the <bin> field of the
a=trans-rate-adapt.dlna.org attribute is equal to 1, then Receiving Endpoint shall not attempt to
recover the Serving Endpoint's clock from the RTP time stamp until the amount of data (in NPT)
specified by the Target Buffer Duration has been received.

[ATTRIBUTES ]

M A DMP DMR M-DMP n/a n/a YZLTO

[C OMMENT] Example: If the SETUP request included "TD=5000" on the Buffer-Info.dlna.org

header, then the Receiving Endpoint does not attempt to recover the clock until it has received the
first 5 s worth of data in NPT time.

The NPT time can be derived from the decode time of the RTP payload.

Receiving Endpoint can still recover the Serving Endpoints clock during this time period from the
Wall Clock Time in the RTP packet (if available).

11.4.4.209 MT RTP DLNAQOS RTSP traffic

[G UIDELINE ] If DLNAQOS as defined in 8 is implemented, RTSP traffic in both directions (from
Serving Endpoint to Receiving Endpoint and vice versa) shall be tagged with DLNAQOS_2, or a
lower DLNAQOS_UP value (where "or a lower" is defined by 8.3.2.2.2 and 8.3.2.2.3), in accordance
with Table 7.

[ATTRIBUTES ]

M R DMS DMP DMR +PU+ M-DMS M-DMP n/a n/a R9YSY

[C OMMENT] PAUSE and TEARDOWN are important RTSP commands to stop the stream of a
congested network. RTSP messages use their own TCP connection, i.e. media is not transferred by
the DMS on the same connection. Because of this separate connection, RTSP request messages do
not have to be at the same priority that the server will use to deliver the media.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 679 –

11.4.4.210 MT HTTP transport conditions for seek and play-speed operations

11.4.4.210.1
[G UIDELINE ] A UPnP AV MediaRenderer that receives a request from a UPnP AV MediaRenderer
Control Point to play at a valid speed of s some media resource whose first field of protocolInfo is
"http-get" may send HTTP requests with PlaySpeed.dlna.org, Range, and/or
TimeSeekRange.dlna.org headers against the UPnP AV MediaServer.

A valid speed s is one whose value is "1" or is included by the UPnP AV MediaRenderer in the
play-speed-list (identified by X_DLNA_PS as defined in 10.1.6.29.2) of
AVT.CurrentTransportActions virtual instance state variable.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC 2WOVM

29341-14-10

[C OMMENT] When a UPnP AV MediaRenderer Control Point sends the UPnP AV MediaRenderer a
request to play content at some speed, the UPnP AV MediaRenderer decides the best way to satisfy
the request. The UPnP AV MediaRenderer could send HTTP time/byte seek requests to the UPnP
AV MediaServer, or it could perform the operation locally using cached content, or both.

11.4.4.210.2
[G UIDELINE ] If a UPnP AV MediaRenderer indicates support for controller-time seek operations for
a resource whose first field of protocolInfo is "http-get", then upon receiving an AVT:Seek request to
perform such operations, the UPnP AV MediaRenderer may issue HTTP time-based seek requests
against the UPnP AV MediaServer.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC RQQ8Q

29341-14-10

[C OMMENT] This guideline clarifies that upon receiving a request from a UPnP AV MediaRenderer
Control Point to perform a controller-time seek operation (on a resource associated with "http-get"),
the UPnP AV MediaRenderer will decide the best way to satisfy the request. Some UPnP AV
MediaRenderers might have cached the entire file and consequently, will be able to perform the
request locally. Other UPnP AV MediaRenderers will send time-based seek requests to the UPnP
AV MediaServer. Other UPnP AV MediaRenderers will send byte-range requests to the UPnP AV
MediaServer. The UPnP AV MediaRenderer determines any necessary means to satisfy the
request.

11.4.4.210.3
[G UIDELINE ] If a UPnP AV MediaRenderer indicates support for controller-byte seek operations for
a resource whose first field of protocolInfo is "http-get", then upon receiving an AVT:Seek request to
perform such operations, the UPnP AV MediaRenderer may issue HTTP byte-based seek requests
against the UPnP AV MediaServer.

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC EUSRW

29341-14-10

[C OMMENT] This guideline clarifies that upon receiving a request from a UPnP AV MediaRenderer

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 680 –

Control Point to perform a controller-byte seek operation (on a resource associated with "http-get"),
the UPnP AV MediaRenderer will decide the best way to satisfy the request. Some UPnP AV
MediaRenderers might have cached the entire file and consequently, will be able to perform the
request locally. Other UPnP AV MediaRenderers will send time-based seek requests to the UPnP
AV MediaServer. Other UPnP AV MediaRenderers will send byte-range requests to the UPnP AV
MediaServer. The UPnP AV MediaRenderer determines any necessary means to satisfy the
request.

11.4.4.211 MT RTP transport conditions for seek and play-speed operations

11.4.4.211.1
[G UIDELINE ] A UPnP AV MediaRenderer that receives a request from a UPnP AV MediaRenderer
Control Point to play at a valid speed of s some media resource whose first field of protocolInfo is
"rtsp-rtp-udp" may send an RTSP request to the UPnP AV MediaServer.

A valid speed s is one whose value is "1" or is included by the UPnP AV MediaRenderer in the
play-speed-list (identified by X_DLNA_PS as defined in 10.1.6.29.2) of
AVT.CurrentTransportActions virtual instance state variable.

[ATTRIBUTES ]

O A DMR n/a n/a IETF RFC OG3HW

2326
ISO/IEC
29341-14-10

[C OMMENT] This guideline indicates that upon receiving a request to play some resource at a
speed of s, a UPnP AV MediaRenderer could pass the request to the UPnP AV MediaServer, or it
could satisfy the request using a cached copy (if available). If the UPnP AV MediaRenderer sends
a request to the UPnP AV MediaServer, the UPnP AV MediaRenderer could use the RTSP Scale
header, or the Speed header in RTSP Play as defined in the RTP subclause of the guidelines.

11.4.4.211.2
[G UIDELINE ] If a UPnP AV MediaRenderer indicates support for controller-time seek operations for
a resource whose first field of protocolInfo is "rtsp-rtp-udp", then upon receiving an AVT:Seek
request to perform such operations, the UPnP AV MediaRenderer may issue a request for an RTP
Seek Media Operation against the UPnP AV MediaServer.

[ATTRIBUTES ]

O A DMR n/a n/a IETF RFC WOVM6

2326ISO/IEC
29341-14-10

[C OMMENT] This guideline clarifies that upon receiving a request from a UPnP AV MediaRenderer
Control Point to perform a controller-time seek operation (on a resource associated with
"rtsp-rtp-udp"), the UPnP AV MediaRenderer could issue a seek request against the server, or it
could satisfy the request using a cached copy (if available).

12 Content transformation device virtualization

12.1 Theory of operations
Media requirements are different depending on whether they are home networked devices, or
mobile or handheld devices. Typically, the mobile devices have smaller screens, lower capability
processors, less storage, and lower communications bandwidth. Therefore, media profiles which
are tailored to this environment are especially important to mobile devices. Media servers in the
home might not have content in profiles that are optimized for the handheld, and renderers within
DLNA guidelines; Part 1-1: Architecture and protocols
 – 681 –

the digital home might not accept the handheld optimized profiles. In addition, media servers might
not be able to interpret bitstreams of content formats that are important to the handheld devices,
and hence, cannot stream that content. In order to increase the interoperability between mobile and
home devices, content transformation is an important consideration of the interface between
handheld devices and the digital home. Content transformation can include transcoding, transrating,
or scaling of a content binary. There should exist within the network, a device that accepts media
from the handheld device and makes it available in common home networking profiles, and it shall
accept media from the home network and make it available to the handheld device in a profile
appropriate to that environment. Within the DLNA guidelines, media is made available through the
use of a Digital Media Server and consumed through Digital Media Player or Digital Media Renderer
devices. Content transformation can be accomplished by making use of these same concepts to
make media available in and consume media in alternate profiles. We define a "virtual" device as
one that encapsulates and extends the capabilities of another device on the network. The existing
device on the network is known as the "native" device. A virtual device can extend the functionality
of a native device without any special relationship with that device. It uses the existing public
interface to control the device when necessary. Other devices on the network can connect to the
virtual device as if it were the native device, and the virtual device will control the native device to
create any intermediate results or operations necessary. A virtual renderer does not have the
capability to display the media itself but it encapsulates and extends a native renderer. For example,
if there is a renderer available that can accept MPEG2 content (such as an HND television) a virtual
media renderer can be created that can accept MPEG4 content and displays it on the television.
When a control point sends an MPEG4 URL to the virtual renderer, the media is transcoded from
MPEG4 to MPEG2 and the virtual renderer uses a control point to drive the real renderer to actually
display the transcoded MPEG2 content. Figure 29 shows an example of a virtual renderer for an
audio renderer.

A similar action can be performed for media servers. If content is available on a home DMS, a virtual
server can be created which uses knowledge of content transformation that it can perform to make
available that same content in alternate DLNA Media Format Profiles. For example as shown in
Figure 28, when a CDS:Browse request comes in to the virtual server, it will use a control point to
perform a CDS:Browse on the same container of the native server. Once it receives the metadata of
the content on the native server, it can add <res> fields to the metadata representing content
transformations that it can perform. The URLs of these <res> fields can point to different systems
than the native server.

To allow a control point to determine if it is communicating with a virtual device, the virtual device
shall specify the DLNAVIRT tag in its device description document and specify the native device
that it is a virtual copy of. This will allow the control point to sort out the relationships between virtual
and native devices on the network. A control point will then see a number of servers and renderers
on the network with different capabilities. The control point should be aware of the concept of virtual
devices and should never present to the user an interface to both the virtual device and the
underlying real device. The virtual device should expose all of the capabilities of the underlying
devices and make it unnecessary for the user to access the underlying device.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 682 –

Figure 28 – Content transformation with a virtual MediaServer

Figure 29 – Content transformation with a virtual MediaRenderer

12.2 Virtual device implementation

12.2.1 General
Any device can choose to implement or not implement virtual device functionality. This initial set of
guidelines defines that for any implementation that supports virtual instances, it shall fully support
the guidelines within this subclause.

12.2.2 Virtual device conformance to guidelines

12.2.2.1
[G UIDELINE ] A device may optionally implement virtual server or renderer functionality.

[ATTRIBUTES ]

O A DMS DMR M-DMS n/a n/a ZGPK9

[C OMMENT] A virtual server or renderer is one which encapsulates the functionality of another
device. A virtual server does not manage its own container hierarchy, but relies on an underlying
DLNA guidelines; Part 1-1: Architecture and protocols
 – 683 –

native server. A virtual renderer does not have direct rendering capabilities, but relies on another
device in the network to render content.

12.2.2.2
[G UIDELINE ] If a device implements virtual server or renderer functionality, it shall adhere to all
guidelines in this subclause for the appropriate virtual device.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a n/a R4XV7

12.2.2.3
[G UIDELINE ] A virtual DMS server shall adhere to all mandatory and conditionally mandatory
guidelines for a DMS in addition to the guidelines contained in this subclause that are for virtual
servers.

[ATTRIBUTES ]

M A DMS n/a n/a n/a 8V7VH

12.2.2.4
[G UIDELINE ] A virtual M-DMS server shall adhere to all mandatory guidelines for an M-DMS in
addition to the guidelines contained in this subclause that are for virtual servers.

[ATTRIBUTES ]

M A n/a M-DMS n/a n/a X34I7

12.2.2.5
[G UIDELINE ] A virtual DMR shall adhere to all mandatory guidelines for a DMR in addition to the
guidelines contained in this subclause that are for virtual renderers.

[ATTRIBUTES ]

M A DMR n/a n/a n/a HZG5L

12.3 Virtual device, Device Discovery and Control (DDC)

12.3.1 General
A virtualized device is any UPnP device that extends and encapsulates another device. For example
a virtual server may extend an existing, native, server in the network by offering additional content.
A virtual renderer may extend a native renderer by offering additional input protocols and formats
that are transformed on the fly to a format that the native renderer can use. This subclause of the
guidelines defines how virtual devices respond to device description actions.

12.3.2 DDC UPnP device description of virtualized device

12.3.2.1
[G UIDELINE ] A virtual device shall define the device(s) that it is virtualizing through the use of the
<dlna:X_DLNAVIRT> XML element inside the <device> element of the device description document.
The value of this element is a UUID of the original device that is being virtualized, or it is the value
"*".

An example of <dlna:X_DLNAVIRT> element is shown as follows:

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 684 –

<dlna:X_DLNAVIRT xmlns:dlna="urn:schemas-dlna-org:device-1-0">
14EF6B21-7130-4525-B8C8-93FBFCF8C1A8
</dlna:X_DLNAVIRT>

The format of a UUID is as specified in 9.2.19.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC 86LYX

29341-1

[C OMMENT] This tag allows a control point to determine that this is a virtual device and specifies
the native device that it is operating on.

12.3.2.2
[G UIDELINE ] The urn:schemas-dlna-org:device-1-0 namespace shall be specified for the
<dlna:X_DLNAVIRT> element and the namespace prefix shall be "dlna:"

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC 6LYXI

29341-1

12.3.2.3
[G UIDELINE ] The namespace prefix declaration for the dlna: namespace may be specified in the
<root> element of the device description.

[ATTRIBUTES ]

O A DMS DMR M-DMS n/a ISO/IEC 34I77

29341-1

12.3.2.4
[G UIDELINE ] The value of the UUID in the <dlna:X_DLNAVIRT> element shall match the UUID of
the device that is being virtualized. This value is as specified in that device's SSDP advertisement
message.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC ZG5L7

29341-1

12.3.2.5
[G UIDELINE ] The value of "*" in the <dlna:X_DLNAVIRT> XML element represents "all servers
currently on the network".

Note that this is a dynamic set and if a native server leaves the network, the aggregate virtual server
does not have to leave the network as well.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 288O9

29341-1

[C OMMENT] This will allow aggregation. It is possible to create one virtual server which represents
all content currently available on the network.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 685 –

12.3.2.6
[G UIDELINE ] The value of "*" in the <dlna:X_DLNAVIRT> XML element shall not be used for
renderers.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 3RHST

29341-1

[C OMMENT] There is no way to virtualize multiple renderers because there is no way to choose
where the content is to be actually played.

12.3.2.7
[G UIDELINE ] A virtual device that represents a single native device should have a device name that
contains the native device's name and informs the user that this is a virtual device based upon the
given native device.

[ATTRIBUTES ]

S A DMS DMR M-DMS n/a ISO/IEC F288O

29341-1

[C OMMENT] If the DLNAVIRT tag is not understood, the device name can direct the user to realize
that this is a virtual device. For example, if the name of the native server is "My_Media_Server" the
virtual device could have a name such as "Mobile ready My_Media_Server". This guideline does not
specify how the virtual server transforms the device name.

If this is an aggregating virtual server, it could have a name such as "Mobile Media Server".

Since this is only given to the user and is not interpreted by software, having various mechanisms
does not cause an interoperability issue.

12.3.2.8
[G UIDELINE ] A virtual server that aggregates content from multiple native servers shall have a
unique name on the network that represents its function as an aggregating virtual server performing
content transformation.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC P8V7V

29341-1

12.3.2.9
[G UIDELINE ] The virtual device's name shall allow localized native device names to be included as
part of the text of the virtual device's name.

This does not require the virtual device's name to match the language of the native device's name,
only that the portion of the native device's name that is included in the virtual device's name, shall
be able to be in a localized language, and that language shall be preserved in the portion of the
copied name.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC E86LY

29341-1

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 686 –

12.3.3 DDC UPnP actions

12.3.3.1
[G UIDELINE ] The virtual device shall receive actions and relay them to the native device by use of
a control point implemented in the device hosting the virtual server or renderer.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC MX34I

29341-1

[C OMMENT] If the native device is a 1.0 device, the control point shall adhere to 1.0 calling
conventions and requirements, if a 1.5 device, it shall adhere to that specification, etc. The
requirements are set by the underlying native device.

12.3.3.2
[G UIDELINE ] When relaying an action, the control point implemented in the device hosting the
virtual server or renderer shall adhere to all guidelines for the version and types of the device that
it is calling.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC UE86L

29341-1

12.3.4 DDC UPnP device description ssdp:byebye of virtual device

12.3.4.1
[G UIDELINE ] A virtual server or renderer bound to a single native device shall issue its own
ssdp:byebye message within 5 s of receiving the native device's ssdp:byebye.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC ZP8V7

29341-1

12.3.4.2
[G UIDELINE ] A virtual server or renderer bound to a single native device shall issue a ssdp:byebye
if it fails to receive advertisements from the native device within a CACHE-CONTROL interval. It
shall issue this ssdp:byebye within 5 s of the end of the CACHE-CONTROL interval.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC 2ZP8V

29341-1

12.3.4.3
[G UIDELINE ] A virtual server that aggregates content from multiple native servers shall issue its
own ssdp:byebye message within 5 s of the last native device that it is virtualizing issuing a
ssdp:byebye.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC V7VHR

29341-1

DLNA guidelines; Part 1-1: Architecture and protocols

 – 687 –

12.3.4.4
[G UIDELINE ] A virtual server that aggregates content from multiple native servers shall issue its
own ssdp:byebye message within 5 s of recognizing that all native servers' CACHE-CONTROL
intervals have expired without receiving an advertisement set.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC LYXIA

29341-1

12.3.4.5
[G UIDELINE ] A virtual device which has any pending UPnP requests at the time that the virtual
device receives the ssdp:byebye from the native device should respond to the UPnP requests with
an error 503 (Service Unavailable).

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC 4I77T

29341-1

12.3.5 DDC virtual devices

[G UIDELINE ] An endpoint shall never create a virtual server or renderer for a device that is itself a
virtual device.

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a n/a I77T3

[C OMMENT] This could create a loop in the graph of network devices.

12.4 Virtual device Media Management (MM)

12.4.1 General
This subclause of the guidelines defines how virtual servers and renderers interact at the media
management layer.

12.4.2 CMS action requirement for virtual devices

12.4.2.1
[G UIDELINE ] A virtual device shall define the input Media Format Profiles that it can accept through
the use of the CMS:X_GetDLNAInputProfiles action.

The action's definition in the service description is defined below.

• <action>
• <name>X_GetDLNAInputProfiles</name>
• <argumentList>
• <argument>
• <name>InputProfiles</name>
• <direction>in</direction>
• <relatedStateVariable>X_A_ARG_Type_InputProfiles</relatedStateVariable>
• </argument>

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 688 –

• <argument>
• <name>SupportedInputProfiles</name>
• <direction>out</direction>
• <relatedStateVariable>X_A_ARG_Type_SupportedInputProfiles</relatedStateVariable>
• </argument>
• </argumentList>
• </action>
The X_A_ARG_TYPE_InputProfiles and X_A_ARG_TYPE_SupportedInputProfiles state variables
are defined below.

• <stateVariable sendEvents="no">
• <name>X_A_ARG_Type_InputProfiles</name>
• <dataType>string</dataType>
• </stateVariable>
• <stateVariable sendEvents="no">
• <name>X_A_ARG_Type_SupportedInputProfiles</name>
• <dataType>string</dataType>
• </stateVariable>
[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC G5L7T

29341-14-11

[C OMMENT] The use of the CMS:X_GetDLNAInputProfiles or CMS:X_GetDLNAOutputProfiles

actions do not guarantee that all content on a native server can be made available in all of the media
profiles listed, nor that a virtual renderer can accept any of the listed input profiles for transformation
to any native renderer in the network.

These guidelines are intended to allow control points to quickly find virtual servers and renderers
that might have content optimized for the device at the time that the UPnP device discovery occurs.
It is not intended to imply that all content will be available in these formats from a virtual server or
that the virtual renderer can accept these formats for all native renderers in the network.

It is intended as a general description of the types of media that a control point can expect to find on
this server. This is useful when a control point attempts to locate a virtual server with a particular
type of specialized Media Format Profiles, which it will then explore in more detail for the supported
media formats for each content binary.

The InputProfiles input argument is an unordered, comma separated list of DLNA Media Format
Profile names.

The SupportedInputProfiles output argument is an unordered, comma separated list of DLNA Media
Format Profile names.

• If the InputProfiles input argument is not empty, then SupportedInputProfiles contains all DLNA
Media Format Profiles that this virtual server can support as input for transformation that are
also listed in the InputProfiles input argument.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 689 –

• Or, in case of an empty InputProfiles value, the SupportedInputProfiles list shall contain the
complete list of DLNA Media Format Profiles that this virtual device can accept as input for
transformation.
For a virtual renderer SupportedInputProfiles will be the profiles that it can accept from a control
point for transforming. For a virtual server, SupportedInputProfiles will be the profiles that can be
read from a native server for transformation.

The response behavior is summarized in the following way.

• If InputProfiles is empty, then SupportedInputProfiles contains a complete list of profiles that the
virtual device is able to transform. Control points specify an empty value for InputProfiles when
they want to acquire the full profile set.
• If InputProfiles contains one or more profiles, then SupportedInputProfiles contains the subset
of InputProfiles that the virtual device is able to transform. Control points specify one or more
profiles for InputProfiles when they are interested finding out if the virtual device is able to
transform certain profiles.
12.4.2.2
[G UIDELINE ] A virtual device shall define the output Media Format Profiles that it supports through
the use of the CMS:X_GetDLNAOutputProfiles action.

The action's definition in the service description is:

<action>
<name>X_GetDLNAOutputProfiles</name>
<argumentList>
<argument>
<name>OutputProfiles</name>
<direction>in</direction
<relatedStateVariable>
X_A_ARG_Type_OutputProfiles
</relatedStateVariable>
</argument>
<argument>
<name>SupportedOutputProfiles</name>
<direction>out</direction>
<relatedStateVariable>
X_A_ARG_Type_SupportedOutputProfiles
</relatedStateVariable>
</argument>
</argumentList>
</action>

The X_A_ARG_TYPE_OutputProfiles and X_A_ARG_Type_SupportedOutputProfiles state

variables are defined:

<stateVariable sendEvents="no">
<name>X_A_ARG_Type_OutputProfiles</name>
<dataType>string</dataType>
</stateVariable>
<stateVariable sendEvents="no">
<name>X_A_ARG_Type_SupportedOutputProfiles </name>
<dataType>string</dataType>
</stateVariable>

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 690 –

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC L7TSG

29341-14-11

[C OMMENT] The OutputProfiles intput argument is an unordered, comma separated list of DLNA
Mmedia Format Profile names.

The SupportedOutputProfiles output argument is an unordered, comma separated list of DLNA

Media Format Profile names.

• If the OutputProfiles input argument is not empty, then SupportedOutputProfiles contains all
DLNA Media Format Profiles that this virtual server can support as output from transformation
that are also listed in the OutputProfiles input argument.
• Or, in case of an empty OutputProfiles value, the SupportedOutputProfiles list shall contain the
complete list of DLNA Mmedia Format Profiles that this virtual device can support as output from
transformation.
For a virtual renderer SupportedOutputProfiles will be the profiles that it can transform content to for
output to a native renderer. For a virtual server, SupportedOutputProfiles will be the profiles that
can be made available as alternate Media Format Profiles.

The response behavior is summarized in the following way.

• If OutputProfiles is empty, then SupportedOutputProfiles contains a complete list of profiles that

the virtual device is able to create during a transformation from one or more profiles. Control
points specify an empty value for OutputProfiles when they want to acquire the full profile set.
• If OutputProfiles contains one or more profiles, then SupportedOutputProfiles contains the
subset of OutputProfiles that the virtual device is able to create during a transformation from one
or more profiles. Control points specify one or more profiles for OutputProfiles when they are
interested finding out if the virtual device creates those profiles.
12.4.2.3
[G UIDELINE ] A virtual device may optionally define the content transformations that it can perform
through the use of the CMS:X_GetDLNATransformProfiles action.

[ATTRIBUTES ]

O A DMS DMR M-DMS n/a n/a 88O9X

12.4.2.4
[G UIDELINE ] The CMS:X_ GetDLNATransformProfiles action's definition in the service description
shall be as follows:

<action>
<name>X_GetDLNATransformProfiles</name>
<argumentList>
<argument>
<name>TransformProfiles</name>
<direction>in</direction>
<relatedStateVariable>
X_A_ARG_Type_TransformProfiles
</relatedStateVariable>
</argument>
<argument>
<name>SupportedTransformProfiles</name>

DLNA guidelines; Part 1-1: Architecture and protocols

 – 691 –

<direction>out</direction>
<relatedStateVariable>
X_A_ARG_Type_SupportedTransformProfiles
</relatedStateVariable>
</argument>
</argumentList>
</action>

The X_A_ARG_TYPE_TransformProfiles and X_A_ARG_TYPE_SupportedTransformProfiles state

variables are defined as follows:

<stateVariable sendEvents="no">
<name>X_A_ARG_Type_TransformProfiles</name>
<dataType>string</dataType>
</stateVariable>
<stateVariable sendEvents="no">
<name>X_A_ARG_Type_SupportedTransformProfiles</name>
<dataType>string</dataType>
</stateVariable>

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a ISO/IEC 5L7TS

29341-14-11

[C OMMENT] The TransformProfiles input argument is an unordered, comma separated list of

ordered pairs of DLNA Media Format Profile names.

The SupportedTransformProfiles output argument is an unordered, comma separated list of

ordered pairs of DLNA Media Format Profile names.

The SupportedTransformProfiles list contains the ordered pairs of DLNA Media Format Profile
names that is described by this boolean statement of (([a] AND [b]) OR ([c])).

• If the ordered pairs listed in the TransformProfiles input argument is not empty, then
SupportedTransformProfiles contains all ordered pairs that this virtual server can support as
transformations that are also listed in the TransformProfiles input argument.
• Or, in case of an empty TransformProfiles value, the SupportedTransformProfiles list shall
contain the complete list of ordered pairs that this virtual device can support for transformations.
An ordered pair is a pair of DLNA Media Format Profile names such that the first profile (i.e.
transform-from) can be transformed into the second Media Format Profile (i.e. transform-to).
Formally, it is defined with this syntax:

• order-pair = transform-from ":" transform-to;

• transform-from = pn-value;
• transform-to = pn-value;
• pn-value = <syntax defined in 10.1.3.18>.
The response behavior is summarized in the following way.

• If TransformProfiles is empty, then SupportedTransformProfiles contains a complete list of

ordered pairs that the virtual device is able to transform. Control points specify an empty value
for TransformProfiles when they want to acquire the full set of possible transforms.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 692 –

• If TransformProfiles contains one or more ordered pairs, then SupportedTransformProfiles

contains the subset of TransformProfiles that the virtual device is able to transform. Control
points specify one or more ordered pairs for TransformProfiles when they are interested in
finding out if the virtual device supports a particular set of transforms.
12.4.3 MM virtual server
12.4.3.1
[G UIDELINE ] If a virtual server aggregates content from multiple native servers, it shall aggregate
content from all native servers currently on the network and shall specify the "*" flag in the
<dlna:X_DLNAVIRT> XML element of its device description.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 8O9XK

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.2
[G UIDELINE ] All virtual servers shall support the required UPnP components of a DMS or M-DMS,
including all required actions and state variables.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC STLPO

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] Specifically, it shall adhere to the following guideline requirements for components.

• 10.1.2.12 MM DMS/M-DMS UPnP AV MediaServer device definition

• 10.1.2.13 MM DMS/M-DMS ContentDirectory rules
• 10.1.2.14 MM DMS/M-DMS ConnectionManager rules
12.4.3.3
[G UIDELINE ] A virtual server that does not aggregate content from multiple native servers shall
support all actions that the underlying native server supports.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC O9XKH

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The reason for this guideline is, the situation where the control point goes to the virtual
DLNA guidelines; Part 1-1: Architecture and protocols
 – 693 –

server and finds that it can't perform a critical action shall be avoided. It then shall locate the native
server and perform that action on the native server. It is a better solution for the control point to be
assured that it can perform all actions by just working with the virtual server.

12.4.3.4
[G UIDELINE ] A virtual server that does not aggregate content from multiple native servers shall
make available all of the events of the native server.

The control point on the virtual server shall subscribe for events on the native server, and when the
event occurs on the native server, it shall be forwarded as if it had occurred on the virtual server.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC HSTLP

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.5
[G UIDELINE ] A virtual server that aggregates content from multiple native servers may limit the
actions and events that it supports.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 9OV47

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] If some of the native servers do not support optional actions, such as Search, it is
impossible for the virtual server to supply the necessary functionality.

12.4.3.6
[G UIDELINE ] A UPnP action on a virtual server shall fail if it cannot meet the timing restrictions for
UPnP actions even if the underlying UPnP action on the native server succeeds. See guideline 9.2.9
for UPnP device responsiveness.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC TLPOH

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.7
[G UIDELINE ] A virtual server shall return a result that is within the size limit of UPnP results. See
guideline 9.2.17 for UPnP SOAP packet size.
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 694 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 7SMU8

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The virtual server is free to truncate the response from the native server at an
appropriate boundary so that the final return value from the virtual server will fit within the space
constraints.

12.4.3.8
[G UIDELINE ] The CMS.SourceProtocolInfo variable of a virtual server shall comprise the
protocolInfos listed in the CMS.SourceProtocolInfo of the native server(s) and protocolInfos
corresponding to the profiles listed in the SupportedOutputProfiles output argument of the virtual
server's CMS: X_GetDLNAOutputProfiles when the OutputProfiles argument is set to an empty
string.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC RHSTL

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] See 12.4.2.2 for more information about CMS:X_GetDLNAOutputProfiles.

12.4.3.9
[G UIDELINE ] If the virtual server supports optional content management (OCM) operations, see
guideline 10.1.8.2, it shall control the native server as a valid UPnP AV MediaServer Control point
for the given operation. Specifically, it shall adhere to the control point portions of the following
guidelines.

• 10.1.8.11 MM/CM: Upload AnyContainer operation

• 10.1.8.12 MM/CM OCM: Upload content operation
• 10.1.8.13 MM/CM: OCM: Create child container operation
• 10.1.8.14 MM/CM: OCM: Destroy object operation
• 10.1.8.15 MM/CM: Use of valid values
• 10.1.8.19 MM/CM: general rule for creating <res> elements: Content Transfer process
• 10.1.8.20 MM/CM: general rule for creating <res> elements: Resume Content Transfer process
• 10.1.8.23 MM/CM: General rules for CDS:CreateObject request syntax
• 10.1.8.26 MM/CM: content transfer process
• 10.1.8.28 MM/CM: Auto-Destroy behavior for a failed or partial content transfer process

DLNA guidelines; Part 1-1: Architecture and protocols

 – 695 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 47SMU

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.10
[G UIDELINE ] Any action on a virtual server shall fail if the corresponding operation on the native
server fails and the virtual server shall return the same error message as the native server.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC WA5NX

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] An operation in this context might consist of a number of UPnP actions, for example an
implementation of an action on a virtual server is free to call multiple actions on the native server.
Some of these actions on the native server might fail. However, taken as a whole, all of the calls to
the native server represent a single operation.
For example, the virtual server can make several calls to the native server to test the level of support
for media profiles. Some of these calls might fail if the native server does not support a format, but
overall, the operation will succeed when a compatible format is found.

12.4.3.11
[G UIDELINE ] Any action on a virtual server will be declared successful only if the native server
operation succeeds.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC V47SM

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.12
[G UIDELINE ] If an operation occurs on the DLNA.ORG_AnyContainer on the virtual server, the
virtual server shall map that to a corresponding operation on the DLNA.ORG_AnyContainer of one
of the native servers that it is virtualizing.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC NXTOX

29341-14-10
ISO/IEC
29341-14-11
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 696 –

ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] If the virtual server is aggregating multiple native servers, it shall choose one to apply
the operation to. If it is not aggregating, there is a 1-to-1 mapping to the native server.

12.4.3.13
[G UIDELINE ] If the native server can accept the incoming Media Format Profile of an upload
operation, then the ImportURI returned by the virtual server shall point to the native server and the
upload content transfer process shall occur directly to the native server.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC OV47S

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.14
[G UIDELINE ] If the native server cannot accept the incoming Media Format Profile of an upload
operation, then the Import URI shall point to the virtual server. It shall accept the content through a
content transfer process and transform it to a format that the native server can support, and place
the transformed content on the native server.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC SWA5N

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.15
[G UIDELINE ] The upload of content to the virtual server shall fail if the virtual server cannot upload
transformed content to the native server or the native server cannot accept the transformed content.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC A5NXT

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.16
[G UIDELINE ] If a virtual server receives content that it cannot place on the native server it shall fail
the Media Transport operation with the same error response as returned from the native server.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 697 –

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC T6L4F

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.17
[G UIDELINE ] If a virtual server receives content via an HTTP POST operation, the virtual server
shall delay the final response on the final chunk of received data until the media is (possibly
transformed) and stored on the native server.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 5NXTO

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This ensures that all incoming media is correctly received and accepted by the native
server before sending a final acceptance.

12.4.3.18
[G UIDELINE ] If a virtual server is aggregating content from a number of native servers, and one of
the native servers leaves the network, any query issued more than 1 s after the native server leaves
the network shall not show that content in the hierarchy.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 6L4FE

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] A native server can leave the network by issuing a ssdp:byebye message or
CACHE-CONTROL seconds can elapse without seeing an advertisement set.

12.4.3.19
[G UIDELINE ] For every CDS object on the native server, the virtual server shall advertise that
content with the original content format, scaling, and rate available through a direct URL reference
to the native server.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC LTOT6

29341-14-10
ISO/IEC
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 698 –

29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] This is required so that a user doesn't have to manipulate one profile of content on one
server and switch to a different server to manipulate a different format of the same content. A v1.0
DMP will only be able to use direct URL references.

12.4.3.20
[G UIDELINE ] For every CDS object on the native server, the virtual server may advertise that
content with the original content format, scaling, and rate available through an indirect URL
reference to the native server, using the PlaySingleURI mechanism as specified in 10.1.4.27.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC B73N2

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.21
[G UIDELINE ] A virtual server shall use additional <res> elements on a CDS object to advertise
alternate profiles or alternate data rates, or alternate media scalings.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC OT6L4

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The virtual server will not create new content entries to represent the transcoded
content.

12.4.3.22
[G UIDELINE ] New <res> elements shall not be advertised until the virtual server can correctly
respond to a request for the content in the indicated media parameters.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC TOT6L

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

DLNA guidelines; Part 1-1: Architecture and protocols

 – 699 –

[C OMMENT] There are no static reasons why the content cannot be served when requested. For
instance, if offline content transformation is performed and the transformed file is not available, a
<res> element would not be published.

Do not use dynamic conditions, such as network bandwidth, processor resources, etc. that can
change rapidly, to determine whether a <res> field is provided or not.

12.4.3.23
[G UIDELINE ] If offline transformation of content is performed, the <res> element shall not be
published in the response to a CDS:Browse or CDS:Search until the transformation is complete and
the content binary is available.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC DUTU4

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.24
[G UIDELINE ] If real time conversion of content is performed, the <res> element shall not be
published in the response to a CDS:Browse or CDS:Search until the transformation subsystem is
ready to respond to requests for content binaries.

The request for content binaries may fail due to dynamic reasons. However, the transformation
service shall be ready to respond with an appropriate failure condition.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 3V6TC

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.25
[G UIDELINE ] If a real time transformation cannot be completed when requested due to dynamic
conditions on the virtual server, the media transport layer shall issue an appropriate error message
within the transport protocol requested

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC W3V6T

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 700 –

12.4.3.26
[G UIDELINE ] New <res> elements shall advertise URI values that allow for the virtual server to
setup the requested content transformation.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC GB73N

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] If a realtime transform is performed, information in the URI can be used to define the
server and URI of the original content.

12.4.3.27
[G UIDELINE ] If a virtual server cannot create a URI value for content that meets the above guideline
and also meets the maximum allowable URI size restriction, it shall not publish a <res> element for
this content transformation

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC TGB73

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.28
[G UIDELINE ] A virtual server shall retain all recommended metadata (as specified by guideline
10.1.3.12.3) that is available for a CDS object.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC EDUTU

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The virtual server can choose to delete other metadata entries at its discretion.

12.4.3.29
[G UIDELINE ] A virtual server shall specify the available media operations in the 4th field of a
protocolInfo on a <res> element to transformed content.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC VW3V6

29341-14-10

DLNA guidelines; Part 1-1: Architecture and protocols

 – 701 –

ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] For example, the native server might be able to support fast forward playback, while
the transformed ontent cannot, so for the new <res> elements, they shall have the correct
corresponding set of media operations that the virtual server can support.

12.4.3.30
[G UIDELINE ] A virtual server may reduce the set of media operations in the 4th field of a
protocolInfo for a <res> element added for transformed content.

[ATTRIBUTES ]

O A DMS M-DMS n/a ISO/IEC 6EDUT

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

12.4.3.31
[G UIDELINE ] The virtual server shall copy the entire protocolInfo unaltered for a <res> element
where the URI is a direct reference to the native server's content.

[ATTRIBUTES ]

M A DMS M-DMS n/a ISO/IEC 96EDU

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-20-12
ISO/IEC
29341-20-3

[C OMMENT] The URI still points to the native server. The availability of that server’s media
operations is independent of the source of the content directory.

12.4.4 MM virtual renderer

12.4.4.1
[G UIDELINE ] A virtual renderer shall support the required UPnP components of a DMR, including all
required actions and state variables.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC O96ED

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-3-2

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 702 –

[C OMMENT] Specifically, it shall adhere to the following guideline requirements for components.

• 10.1.2.6 MM DMR UPnP AV MediaRenderer device definition

• 10.1.2.8 MM DMR ConnectionManager rules
• 10.1.2.9 MM DMR RenderingControl rules
12.4.4.2
[G UIDELINE ] A virtual renderer shall make available all of the events of the native renderer.

The control point on the virtual renderer shall subscribe to the events on the native and when the
event occurs on the native renderer, it shall be forwarded as if it had occurred on the virtual
renderer.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC Y6VW3

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-3-2

12.4.4.3
[G UIDELINE ] The CMS.SinkProtocolInfo variable of a virtual renderer shall comprise the
protocolInfos listed in the CMS.SinkProtocolInfo of the native renderer and protocolInfos
corresponding to the profiles listed in the SupportedInputProfiles output argument of the virtual
renderer's CMS:X_GetDLNAInputProfiles response when the InputProfiles argument is set to an
empty string.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC 9TGB7

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-3-2

[C OMMENT] See 12.4.2.1 for the more information about CMS:X_GetDLNAInputProfiles.

12.4.4.4
[G UIDELINE ] A virtual renderer shall be bound to a single real renderer.

[ATTRIBUTES ]

M A DMR n/a n/a ISO/IEC K9TGB

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-3-2

12.4.4.5
[G UIDELINE ] A virtual renderer may buffer any reasonable amount of data for a transformation
before starting the playback on the native renderer.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 703 –

[ATTRIBUTES ]

O A DMR n/a n/a ISO/IEC 4BSTW

29341-14-10
ISO/IEC
29341-14-11
ISO/IEC
29341-3-2

[C OMMENT] Due to items like network bandwidth, jitter, or capabilities of the content transformation
engine, the virtualizer might need to buffer a substantial portion of the content before starting the
playback.

12.5 Virtual device Media Formats (MF)

12.5.1 MF virtual HND server media types
12.5.1.1
[G UIDELINE ] A virtual DMS server shall support at least one HND required Media Format Profiles
for the Media Classes that it supports.

[ATTRIBUTES ]

M A DMS n/a n/a IEC 62481-2 C5K83

[C OMMENT] See 6.2 of IEC 62481-2.

12.5.1.2
[G UIDELINE ] A virtual DMS server shall make additional Media Format Profiles available as DLNA
Media Format Profiles.

[ATTRIBUTES ]

M A DMS n/a n/a IEC 62481-2 24N2G

12.5.2 MF virtual MHD server media types

12.5.2.1
[G UIDELINE ] A virtual M-DMS server shall support at least one MHD required Media Format Profile
for the Media Classes that it supports.

[ATTRIBUTES ]

M A n/a n/a M-DMS IEC 62481-2 EV3PV

[C OMMENT] See 6.2 in IEC 62481-2.

12.5.2.2
[G UIDELINE ] A virtual M-DMS server shall make additional Media Format Profiles available as
DLNA Media Format Profiles

[ATTRIBUTES ]

M A n/a n/a M-DMS IEC 62481-2 XVALG

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 704 –

12.5.3 MF virtual HND HND renderer media types

[G UIDELINE ] A virtual DMR shall support all required Media Format Profiles for the Media Classes
that it consumes.

[ATTRIBUTES ]

M A n/a DMR n/a IEC 62481-2 86X5J

[C OMMENT] See 6.2 of IEC 62481-2.

12.6 Virtual device Media Transport (MT)

12.6.1 MT virtual HND server media transport
[G UIDELINE ] A virtual DMS server shall support transport of the media over all HND required media
transport protocols.

[ATTRIBUTES ]

M A DMS n/a n/a n/a HR6EO

[C OMMENT] This reiterates the requirement that a virtual DMS shall implement all of the mandatory
requirements for a native DMS.

12.6.2 MT virtual MHD server media transport

[G UIDELINE ] A virtual M-DMS server shall support transport of the media over all required MHD
media transport protocols.

[ATTRIBUTES ]

M A n/a M-DMS n/a n/a UTU4B

[C OMMENT] This reiterates the requirement that a virtual M-DMS shall implement all of the
mandatory requirements for a native M-DMS.

12.6.3 MT virtual HND renderer media types

[G UIDELINE ] A virtual DMR shall accept content over all required HND media transport protocols.

[ATTRIBUTES ]

M A DMR n/a n/a n/a 6TC5K

[C OMMENT] This reiterates the requirement that a virtual DMR shall implement all of the mandatory
requirements for a native DMR.

12.6.4 MT virtual device control

[G UIDELINE ] A virtual device shall control the native device with the version of HTTP that is
supported by the native device (1.0 or 1.5).

[ATTRIBUTES ]

M A DMS DMR M-DMS n/a IETF RFC N24N2

1945
IETF RFC
2145

DLNA guidelines; Part 1-1: Architecture and protocols

 – 705 –

IETF RFC
2616

[C OMMENT] This reiterates the requirement that a virtual device shall interact with the native
device using the appropriate HTTP version.

13 3D media rendering guidelines

This clause contains 3D media rendering guidelines that are applicable to DMP, DMR and XDMR
Device Classes as well as RUI clients that include +RUIHPL+/+RUIHSINK+ and
+RVUPL+/+RVUSINK+ Device Capabilities as defined in IEC 62481-6-1 and IEC 62481-6-2.

13.1
[G UIDELINE ] When decoding Stereoscopic 3D (S3D) content, the Rendering Endpoint or the RUI
client shall render all overlaid non-stereoscopic graphics, as duplicated images on each
"half-frame" to match the decoded frame-compatible S3D format, including the
frame_grid_alignment data provided in the Supplemental Enhancement Information (SEI) message.

[ATTRIBUTES ]

M A DMP DMR XDMR n/a n/a n/a VGWAI

+RUIHPL+
+RUIHSINK+
+RVUPL+
+RVUSINK+

[C OMMENT] A 3D-media-capable Rendering Endpoint/RUI client is required to display graphics

appropriately when overlaying stereoscopic 3D media with optionally a depth offset between the L/R
frames in order to place them properly in z-space. The overlaid non-stereoscopic graphics can
include closed captioning and on-screen displays (OSD).

13.2
[G UIDELINE ] A 3D-media-capable Rendering Endpoint or a 3D-media-capable RUI client shall
respond to the format changes at Group of Picture (GOP) boundaries indicated by
S3D_video_format_type data by rendering the indicated formats ISO/IEC 13818-2

[ATTRIBUTES ]

M A DMP DMR XDMR n/a n/a ISO/IEC BGUZ9

+RUIHPL+ 13818-2
+RUIHSINK+
+RVUPL+
+RVUSINK+

13.3
[G UIDELINE ] A 3D-media-capable Rendering Endpoint or a 3D-media-capable RUI client shall
respond to the format changes indicated by the SEI Format Values at random access points by
rendering the indicated formats.ANSI/SCTE 128

[ATTRIBUTES ]

M A DMP DMR XDMR n/a n/a ANSI/SCTE UC4SD

+RUIHPL+ 128
+RUIHSINK+
+RVUPL+
+RVUSINK+

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 706 –

13.4
[G UIDELINE ] After any change from an S3D media content to a 2D media content, a
3D-media-capable Rendering Endpoint or a 3D-media-capable RUI client shall not display 2D
media content in 3D mode for more than 500 ms

[ATTRIBUTES ]

M A DMP DMR XDMR n/a n/a n/a 5ODET

+RUIHPL+
+RUIHSINK+
+RVUPL+
+RVUSINK+

13.5
[G UIDELINE ] If a Rendering Endpoint or a RUI client that supports 3D media uses any provided
depth offset (disparity) metadata to render closed captions CEA-708, it shall establish the z-space
placement without exceeding video frame boundaries.

[ATTRIBUTES ]

M R DMP DMR XDMR n/a n/a CEA-708 QABRQ

+RUIHPL+
+RUIHSINK+
+RVUPL+
+RVUSINK+

DLNA guidelines; Part 1-1: Architecture and protocols

 – 707 –

Annex A
(informative)

Network Infrastructure Device (NID) recommendations

A.1 General
Network Infrastructure Devices (NID) are outside the scope of the DLNA Home Networked Device
interoperability guidelines. However, since DLNA devices interact with each other on a home
network, that network and its infrastructure greatly influence the user experience. Network
Infrastructure Devices that abide by the recommendations in this subclause will contribute to and
facilitate interoperability and a good user experience with DLNA devices. Although this International
Standard lists recommendations, a NID can not be said to conform to this annex, unless it
implements all the items that apply to it marked with the "S" compliance classifier.

A.2 NID Functions

The recommendations in Table A.2 refer to different types of NID functionality. A NID can be a single
function device, such as a switch, or it can be a combination device that implements multiple
functions such as a wireless access point that also provides Ethernet ports with bridging between
wired and wireless interfaces. The NID functions referenced in the recommendations are defined in
Table A.1.

Table A.1 – NID functions

Device function Descriptions

Access Point (AP) APs are IEEE 802.11 hubs, the central points of contact in IEEE 802.11 wireless
networks. APs typically include bridges (see Bridge below) between IEEE 802.11 and
IEEE 802.3 network segments or between IEEE 802.11 and HomePlug AV or HD-PLC
network segments.
Bridge Bridges connect two networks of different physical media types with translation between
formats of the media types occurring at layer 2 of the ISO model.
Interconnect Interconnects are device functions such as switches or hubs that connect two network
segments of the same type (e.g. Ethenet segments). This annex recommends that all
interconnects be switches. Hub functionality should be avoided on the home network.
Internet Gateway IGDs interface the home network to the public Internet. IGDs present different interfaces
Device (IGD) with different characteristics to their LAN side-the home network-and their WAN side-the
public Internet.
Router Routers pass traffic between two or more IP subnets and, within a single subnet, perform
address resolution of IP addresses. Routers can be considered to do translation between
networks at layer 3 of the ISO model.
Switch Switches route network traffic by MAC address, layer 2 of the ISO model, within a single
subnet.

A.3 NID recommendations

A.3.1 General capability recommendations: Ethernet
A.3.1.1 NC NID Ethernet: Base
[G UIDELINE ] If Ethernet is supported, IEEE 802.3u (100BASE TX) with auto negotiation capability
and a connection to the network provided by an RJ45 connector is recommended.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.3 POHR6

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 708 –

A.3.1.2 NC NID Ethernet – Cabling

[G UIDELINE ] If Ethernet is supported, any supplied network cabling should have a rating of
Category 5e or better.

[ATTRIBUTES ]

S R n/a n/a n/a ANSI/ICEA KHP8F

A.3.1.3 NC NID Ethernet – Gigabit

[G UIDELINE ] If Ethernet is supported, IEEE 802.3ab (1000BASE T) is optionally recommended in
addition to Clause A.2. An implementation should support auto negotiation of gigabit operation with
a similarly capable link partner and drop down to a lower speed, as appropriate.

[ATTRIBUTES ]

O R n/a n/a n/a IEEE 802.3 OHR6E

A.3.1.4 NC NID Ethernet – QoS tolerance

[G UIDELINE ] If Ethernet is supported, tagged packets should be tolerated. Tagged packets are
Ethernet packets that include priority tags conformant with IEEE 802.3, 3.5 entitled "Elements of the
Tagged MAC Frame". Here, "tolerate" means passing the packet, including the packet tag, without
alteration, and without appreciable performance penalty. In cases where a tagged packet is passed
to a higher network layer, the packet payload should be passed up identically to the way it would be
if the packet were not tagged. Devices may also honor the priority indication in a packet tag, passing
the packet in priority order with respect to other packets in the traffic load.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1DI XKHP8

EEE 802.3

A.3.2 Device recommendations: IGD

A.3.2.1 NC NID IGD – LAN side IPv4 stack
[G UIDELINE ] On their LAN side interface, IGDs should support a TCP/IP stack that includes IPv4,
TCP, UDP, ARP, and ICMP components conformant to all required protocol aspects defined in
IETF RFC 1122 and IETF RFC 1812.

[ATTRIBUTES ]

S R n/a n/a n/a IETF RFC 9XKHP

768
IETF RFC
791
IETF RFC
792
IETF RFC
793
IETF RFC
826
IETF RFC
1122
IETF RFC
1812

A.3.2.2 NC NID IGD – LAN side DHCPv4

[G UIDELINE ] On their LAN side interface, IGDs should support a DHCPv4 service that provides
home network clients with an IPv4 address, a subnet mask, a DNS server address, and a default
gateway address. On power up, the DHCPv4 server should send a network advertisement of
DHCPv4 service.
DLNA guidelines; Part 1-1: Architecture and protocols
 – 709 –

[ATTRIBUTES ]

S R n/a n/a n/a IETF RFC SGKWD

2131

A.3.2.3 NC NID IGD – LAN side DNS

[G UIDELINE ] On their LAN interface, IGDs should support a DNS service capable of resolving DNS
references or allow pass through of DNS requests to an external DNS server.

[ATTRIBUTES ]

S R n/a n/a n/a IETF RFC HP8F3

2929

A.3.2.4 NC NID IGD – IPv4 NAT

[G UIDELINE ] IGDs should support IPv4 NAT functionality between their LAN side and WAN side
interfaces.

[ATTRIBUTES ]

S R n/a n/a n/a IETF RFC 7TSGK

2766

A.3.2.5 NC NID IGD – Upgradeability

[G UIDELINE ] IGDs should be firmware updatable by the end user.

[ATTRIBUTES ]

S ? n/a n/a n/a n/a TSGKW

A.3.2.6 NC NID IGD – IPv6 Customer Edge Router Requirements

[G UIDELINE ] IGDs should support all of the mandatory requirements as specified in RFC7084,
Basic Requirements for IPv6 Customer Edge Routers.

[ATTRIBUTES ]

S R n/a n/a n/a IETF RFC H8MYR N

7084

[C OMMENT] RFC7084 defines the basic requirements needed to provision a Customer Edge
Router with IPv6 addresses, an IPv6 Prefix, and necessary options such as an IPv6 DNS server to
serve the needs of IPv6 devices operating in the home network. The mandatory requirements in this
RFC represent the minimum feature set needed to route and offer IPv6 services for an IGD device.

A.3.2.7 NC NID IGD – LAN side Multicast

[G UIDELINE ] On their LAN interface, IGDs should support forwarding UPnP multicast traffic
directed to address 239.255.255.250:1900 between all LAN interfaces

[ATTRIBUTES ]

S R n/a n/a n/a ISO/IEC ASTFB N

29341-1

[C OMMENT] UPnP SSDP uses messages directed to address 239.255.255.250 port 1900 for DLNA
device discovery.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 710 –

A.3.3 Device recommendations – AP

A.3.3.1 NC NID AP – Connectivity
[G UIDELINE ] APs should support either IEEE 802.11n or both IEEE 802.11a and IEEE 802.11g,
with concurrent operation (both 2,4 GHz and 5 GHz clients simultaneously) and bridging between
the two wireless segments. APs should include Ethernet connectivity conformant to all [NC NID
Ethernet:] labeled requirements in this table with bridging between the Ethernet and IEEE 802.11
segments.

[ATTRIBUTES ]

S R n/a n/a n/a Wi-Fi IA9O6

IEEE 802.11
IEEE 802.11

[C OMMENT] IEEE 802.11g also includes support for IEEE 802.11b.

A.3.3.2 NC NID AP – Wi-Fi conformance

[G UIDELINE ] APs should conform to Wi-Fi test plan requirements at the time the product is offered
to the market.

[ATTRIBUTES ]

S R n/a n/a n/a Wi-Fi 77T3R

IEEE 802.11
WMM Test
Plan
IEEE 802.11

[C OMMENT] Wi-Fi interoperability requirements are increasing with time as new capabilities and
features are specified by IEEE 802.11. When these capabilities are added to the Wi-Fi certification
test plans, wireless implementations are encouraged to conform to them.

A.3.3.3 NC NID AP – Upgradeability

[G UIDELINE ] APs should be firmware updatable by the end user.

[ATTRIBUTES ]

S A n/a n/a n/a n/a T3RKJ

A.3.3.4 NC NID AP – QoS support

[G UIDELINE ] APs should support DLNAQOS on all their network interfaces in accordance with the
recommendations in guidelines A.2.14 through A.2.16.

[ATTRIBUTES ]

S A n/a n/a n/a n/a YXIA9

A.3.3.5 NC NID AP – IEEE 802.11 QoS support

[G UIDELINE ] If DLNAQOS is supported on an IEEE 802.11 network interface by an AP, it should
conform to all Wi-Fi WMM mandatory requirements.

[ATTRIBUTES ]

S R n/a n/a n/a WMM 7T3RK

Specification
WMM Test

DLNA guidelines; Part 1-1: Architecture and protocols

 – 711 –

Plan

[C OMMENT] QoS support is optional, but if supported, conformance to Wi-Fi requirements is

encouraged.

WMM provides the base level QoS specification for IEEE 802.11 network devices.

A.3.3.6 NC NID AP – WMM Access Category mapping

A.3.3.6.1
[G UIDELINE ] If WMM is supported on an IEEE 802.11 network interface by an AP and it is bridging
between the IEEE 802.11 network interface and an IEEE 802.3 network interface, packets received
on the IEEE 802.11 network interface and transmitted on the IEEE 802.3 network interface should
include the IEEE 802.1D user priority value in the IEEE 802.1Q header and the DSCP tag
corresponding to the WMM Access Category of the received IEEE 802.11 packets in accordance
with Table A.2.

Table A.2 – WMM Access Category mapping

WMM Access IEEE 802.1D priority DSCP

Category

AC_BK 1 BK 0x08
AC_BE 0 BE 0x00
AC_VI 5 VI 0x28
AC_VO 7 NC 0x38

[ATTRIBUTES ]

S A n/a n/a n/a IEEE 802.1D XIA9O

IEEE 802.1Q
WMM
Specification
IETF RFC
2474

[C OMMENT] In the case of bridging IEEE 802.3 traffic onto IEEE 802.11, the WMM test plan defines
mapping from DSCP and IEEE 802.1Q into WMM priorities. However, Wi-Fi does not mandate
which approach to implement. This yields an interoperability problem that is addressed by this
guideline.

A.3.3.6.2
[G UIDELINE ] If WMM is supported on an IEEE 802.11 network interface by an AP and it is bridging
between the IEEE 802.11 network interface and an IEEE 802.3 network interface, packets received
on the IEEE 802.3 network interface and transmitted on the IEEE 802.11 network interface should
include the WMM Access Category corresponding to the IEEE 802.1D user priority value in the
IEEE 802.1Q header tag of the received IEEE 802.3 packets in accordance with Table A.3.

Table A.3 – WMM access and IEEE 802.1D priority

IEEE 802.1D priority DSCP WMM Access

Category

1 BK 0x08 AC_BK
2 – 0x10

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 712 –

IEEE 802.1D priority DSCP WMM Access

Category

0 BE 0x00 AC_BE
3 EE Ox18
4 CL 0x20 AC_VI
5 VI 0x28
6 VO 0x30 AC_VO
7 NC 0x38

[ATTRIBUTES ]

S A n/a n/a n/a IEEE 802.1D GKWDR

IEEE 802.1Q
WMM
Specification
IETF RFC
2474

A.3.3.6.3
[G UIDELINE ] If WMM is supported on an IEEE 802.11 network interface by an AP that is bridging
between the IEEE 802.11 network interface and an IEEE 802.3 network interface and an
IEEE 802.3 packet is received that does not contain an IEEE 802.1Q tag, the AP should look at the
DSCP tag and map that to a WMM Access Category in accordance with the Table A.2 and preserve
the DSCP tag across the IEEE 802.3 and IEEE 802.11 segments.

[ATTRIBUTES ]

S A n/a n/a n/a IEEE 802.1D 3RKJV

WMM
Specification
IETF RFC
2474

A.3.3.6.4
[G UIDELINE ] If an AP receives an IEEE 802.3 packet that does not contain an IEEE 802.1Q or a
DSCP tag, the packet should be passed through to the IEEE 802.11 interface unmodified without
the addition of any priority tagging.

[ATTRIBUTES ]

S A n/a n/a n/a IEEE 802.1D A9O67

WMM
Specification
IETF RFC
2474

A.3.3.6.5
[G UIDELINE ] If an AP receives an IEEE 802.11 packet that is not tagged with a WMM Access
Category, the packet should be passed through to the IEEE 802.3 interface unmodified without the
addition of any priority tagging.

[ATTRIBUTES ]

S A n/a n/a n/a IEEE 802.1D 7VHRU

WMM
Specification
IETF RFC
2474
DLNA guidelines; Part 1-1: Architecture and protocols
 – 713 –

A.3.3.7 NC NID AP – WMM admission control

[G UIDELINE ] An AP should not require an admission control procedure for any access category (AC)
on an IEEE 802.11 network interface. The AP should advertise that admission control is not
required in the ACM flags of the WMM parameter elements.

[ATTRIBUTES ]

S ? n/a n/a n/a WMM HRUVW

Specification

[C OMMENT] This guideline allows DLNA Device Classes with IEEE 802.11 network interfaces to
properly use AC_VO and AC_VI for DLNAQOS_3 and DLNAQOS_2 respectively.

A.3.3.8 NC NID AP – Wi-Fi Simple Config conformance

[G UIDELINE ] APs should conform to Clause 4 of Wi-Fi Simple Configuration test plan requirements
at the time the product is offered to market.

[ATTRIBUTES ]

S R n/a n/a n/a Wi-Fi Simple 7JZ3X

Configuration

A.3.4 Device recommendations – Bridge

NC NID bridge – Addressability
[G UIDELINE ] All bridges should be IP addressable and have a unique IP address (layer 3), so they
can be managed through IP or higher layer protocols.

[ATTRIBUTES ]

S ? n/a n/a n/a n/a 9O67G

[C OMMENT] This recommendation does not call out specific methods or protocols for managing a
bridge. The choice of management solution is left to vendors, but all bridges need to be IP
addressable so that the specific management solution can be invoked over the network.

A.3.5 Device recommendations – Interconnect

NC NID Ethernet interconnect
[G UIDELINE ] Network devices that interconnect Ethernet segments should provide switching of
Ethernet frames and be compliant with IEEE 802.1D.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D UVWWT

[C OMMENT] Ethernet switches forward Ethernet frames from one port to a single port based on the
destination MAC address of the frame. This operating characteristic is highly desirable for QoS
because the Ethernet frame will only be transmitted on the path necessary to reach its destination.

Devices that do not perform frame forwarding based on destination MAC address (some times
called Ethernet Hubs) cause unnecessary collisions.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 714 –

A.3.6 Device recommendations – MoCA Bridge

A.3.6.1 NC NID MoCA Bridge – Connectivity
[G UIDELINE ] MoCA Bridges should include Ethernet or IEEE 802.11 connectivity conformant to all
[NC NID Ethernet:] or A.3.3.1/A.3.3.2 labeled requirements with bridging between the Ethernet,
IEEE 802.11 and MoCA segments.

[ATTRIBUTES ]

S R n/a n/a n/a MoCA 9XQ5T

MAC/PHY

A.3.6.2 NC NID MoCA Bridge – MoCA conformance

[G UIDELINE ] MoCA Bridges should conform to MoCA Intermediate Device test plan requirements
at the time the product is offered to the market.

[ATTRIBUTES ]

S R n/a n/a n/a MoCA S4RFJ

Certification

[C OMMENT] MoCA interoperability requirements will increase with time as new capabilities and
features are specified by MoCA. When these capabilities are added to the MoCA certification test
plans, MoCA implementations are expected to conform to them.

A.3.6.3 NC NID MoCA Bridge –Upgradeability

[G UIDELINE ] MoCA Bridges should be firmware updatable by the end user.

[ATTRIBUTES ]

S R n/a n/a n/a n/a XQ5T6

A.3.6.4 NC NID MoCA Bridge – QoS support

[G UIDELINE ] MoCA Bridges should support DLNAQOS on all their network interfaces in
accordance with the recommendations in A.3.6.5 and A.3.6.6.

[ATTRIBUTES ]

S R n/a n/a n/a n/a 4RFJA

A.3.6.5 NC NID MoCA Bridge – MoCA QoS support

[G UIDELINE ] If DLNAQOS is supported on a MoCA network interface by a MoCA Bridge, it should
conform to all MoCA mandatory requirements.

[ATTRIBUTES ]

S R n/a n/a n/a MoCA Q5T6Z

MAC/PHY

A.3.6.6 NC NID MoCA Bridge – MoCA Priority mapping

A.3.6.6.1
[G UIDELINE ] When bridging between the MoCA network interface and an IEEE 802.3 network
interface, packets received on the MoCA network interface and transmitted on the IEEE 802.3
network interface should include the IEEE 802.1D user priority value in the IEEE 802.1Q header
and the DSCP tag corresponding to the Priority of the received MoCA packets in accordance with
Table A.4.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 715 –

Table A.4 – MoCA Priority mapping

MoCA Priority IEEE 802.1D Priority DSCP

(low) 0 BE 0x00
(medium) 5 VI 0x28
(high) 7 NC 0x38

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D RFJA4

IEEE 802.1Q
IETF RFC
2474
MoCA
MAC/PHY

A.3.6.6.2
[G UIDELINE ] When bridging between the MoCA network interface and an IEEE 802.3 network
interface, packets received on the IEEE 802.3 network interface and transmitted on the MoCA
network interface should include the MoCA Priority corresponding to the IEEE 802.1D user priority
value in the IEEE 802.1Q header tag of the received IEEE 802.3 packets in accordance with Table
A.5.

Table A.5 – MoCA Access and IEEE 802.1D Priority

IEEE 802.1D Priority DSCP MoCA Priority

1 BK 0x08 low
2- 0x10 low
0 BE 0x00 low
3 EE 0x18 low
4 CL 0x20 medium
5 VI 0x28 medium
6 VO 0x30 high
7 NC 0x38 high

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D 5T6ZG

IEEE 802.1Q
IETF RFC
2474
MoCA
MAC/PHY

A.3.6.6.3
[G UIDELINE ] When bridging between the MoCA network interface and an IEEE 802.3 network
interface and an IEEE 802.3 packet is received that does not contain an IEEE 802.1Q tag, the
MoCA bridge should look at the DSCP tag and map that to a MoCA Priority in accordance with Table
A.5 in A.3.6.6.2 and preserve the DSCP tag across the IEEE 802.3 and MoCA segments.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D FJA4S

Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 716 –

IEEE 802.1Q
IETF RFC
2474
MoCA
MAC/PHY

A.3.6.6.4
[G UIDELINE ] If a MoCA Bridge receives an IEEE 802.3 packet that does not contain an
IEEE 802.1Q or a DSCP tag, the packet should be passed through to the MoCA interface
unmodified without the addition of any priority tagging.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D T6ZGL

IEEE 802.1Q
IETF RFC
2474
MoCA
MAC/PHY

A.3.6.6.5
[G UIDELINE ] If a MoCA Bridge receives a MoCA packet that is not tagged with a MoCA Priority, the
packet should be passed through to the IEEE 802.3 interface unmodified without the addition of any
priority tagging.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D JA4S9

IEEE 802.1Q
IETF RFC
2474
MoCA
MAC/PHY

A.3.7 Device recommendations – HPNA Bridge

A.3.7.1 NC NID HPNA Bridge – Connectivity
[G UIDELINE ] HPNA Bridges should include Ethernet or IEEE 802.11 connectivity conformant to all
[NC NID Ethernet:] or A.3.3.1/A.3.3.2 labeled requirements with bridging between the Ethernet,
IEEE 802.11 and HPNA segments.

[ATTRIBUTES ]

S R n/a n/a n/a ITU-T G.9954 Q7INV

A.3.7.2 NC NID HPNA Bridge – HPNA conformance

[G UIDELINE ] HPNA Bridges should conform to HPNA Intermediate Device test plan requirements
at the time the product is offered to the market.

[ATTRIBUTES ]

S R n/a n/a n/a n/a RZ3LO

[C OMMENT] HPNA interoperability requirements will increase with time as new capabilities and
features are specified by HPNA. When these capabilities are added to the HPNA certification test
plans, HPNA implementations are expected to conform to them.

A.3.7.3 NC NID HPNA Bridge: upgradeability

[G UIDELINE ] HPNA Bridges should be firmware updatable by the end user.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 717 –

[ATTRIBUTES ]

S R n/a n/a n/a n/a DJTQH

A.3.7.4 NC NID HPNA Bridge: QoS support

[G UIDELINE ] HPNA Bridges should support DLNAQOS on all their network interfaces in
accordance with the recommendations in A.3.7.5 and A.3.7.6.

[ATTRIBUTES ]

S R n/a n/a n/a n/a H45A3

A.3.7.5 NC NID HPNA Bridge – HPNA QoS support

[G UIDELINE ] If DLNAQOS is supported on a HPNA network interface by a HPNA Bridge, it should
conform to all HPNA mandatory requirements.

[ATTRIBUTES ]

S R n/a n/a n/a ITU-T G.9954 I2BVZ

[C OMMENT] QoS support is optional, but if supported should conform to HPNA requirements. The
HPNA specification provides the base level QoS specification for HPNA network devices.

A.3.7.6 NC NID HPNA Bridge – HPNA Priority mapping

A.3.7.6.1
[G UIDELINE ] When bridging between the HPNA network interface and an IEEE 802.3 network
interface, packets received on the HPNA network interface and transmitted on the IEEE 802.3
network interface should include the IEEE 802.1D user priority value in the IEEE 802.1Q header
and the DSCP tag corresponding to the Priority of the received HPNA packets in accordance with
Table A.6.

Table A.6 – HPNA Priority mapping

HPNA Priority IEEE 802.1D Priority DSCP

0 1 BK 0x08
1 2- 0x10
2 0 BE 0x00
3 3 EE 0x18
4 4 CL 0x20
5 5 VI 0x28
6 7 NC 0x38
7 6 VO 0x30

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D NBBZC

IEEE 802.1Q
IETF RFC
2474
ITU-T G.9954

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 718 –

A.3.7.6.2
[G UIDELINE ] When bridging between the HPNA network interface and an IEEE 802.3 network
interface, packets received on the IEEE 802.3 network interface and transmitted on the HPNA
network interface should include the HPNA Priority corresponding to the IEEE 802.1D user priority
value in the IEEE 802.1Q header tag of the received IEEE 802.3 packets in accordance with Table
A.7.

Table A.7 – HPNA Access and IEEE 802.1D Priority

IEEE 802.1D Priority DSCP HPNA Priority

1 BK 0x08 0
2- 0x10 1
0 BE 0x00 2
3 EE 0x18 3
4 CL 0x20 4
5 VI 0x28 5
6 VO 0x30 7
7 NC 0x38 6

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D PY994

IEEE 802.1Q
IETF RFC
2474
ITU-T G.9954

A.3.7.6.3
[G UIDELINE ] When bridging between the HPNA network interface and an IEEE 802.3 network
interface and an IEEE 802.3 packet is received that does not contain an IEEE 802.1Q tag, the
HPNA bridge should look at the DSCP tag and map that to a HPNA Priority in accordance with Table
A.7 in A.3.7.6.2 and preserve the DSCP tag across the IEEE 802.3 and HPNA segments.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D J67A4

IEEE 802.1Q
IETF RFC
2474
ITU-T G.9954

A.3.7.6.4
[G UIDELINE ] If a HPNA Bridge receives an IEEE 802.3 packet that does not contain an
IEEE 802.1Q or a DSCP tag, the packet should be passed through to the HPNA interface
unmodified without the addition of any priority tagging.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D NJT3K

IEEE 802.1Q
IETF RFC
2474
ITU-T G.9954

DLNA guidelines; Part 1-1: Architecture and protocols

 – 719 –

A.3.7.6.5
[G UIDELINE ] If a HPNA Bridge receives a HPNA packet that is not tagged with a HPNA Priority, the
packet should be passed through to the IEEE 802.3 interface unmodified without the addition of any
priority tagging.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D WAACF

IEEE 802.1Q
IETF RFC
2474
ITU-T G.9954

A.3.8 Device recommendations – HomePlug AV and HD-PLC Bridge

A.3.8.1 NC NID HomePlug AV and HD-PLC Bridge – Connectivity
A.3.8.1.1
[G UIDELINE ] Homeplug AV PHY Bridges should include Ethernet or IEEE 802.11 connectivity
conformant to all [NC NID Ethernet:] or A.3.3.1/A.3.3.2 labeled requirements with bridging between
the Ethernet, IEEE 802.11 and Homeplug AV PHY segments.

[ATTRIBUTES ]

S R n/a n/a n/a HomePlug AV BIY9M

Specification

A.3.8.1.2
[G UIDELINE ] ]: HD-PLC PHY Bridges should include Ethernet or IEEE 802.11 connectivity
conformant to all [NC NID Ethernet:] or A.3.3.1/A.3.3.2 labeled requirements with bridging between
the Ethernet, IEEE 802.11 and HD-PLC PHY segments.

[ATTRIBUTES ]

S R n/a n/a n/a HomePlug AV FE6G2

Compliance

A.3.8.2 NC NID HomePlug AV and HD-PLC Bridge – Conformance

A.3.8.2.1
[G UIDELINE ] Homeplug AV PHY Bridges should conform to the Homeplug AV PHY Intermediate
Device test plan requirements at the time the product is offered to the market..

[ATTRIBUTES ]

S R n/a n/a n/a HomePlug AV TWKRQ

Compliance
HomePlug AV
Interoperabili
ty

[C OMMENT] HomePlug AV PHY interoperability requirements will increase with time as new
capabilities and features are specified by HomePlug AV. When these capabilities are added to the
applicable HomePlug AV PHY certification test plans, HomePlug AV PHY implementations should
conform to them

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 720 –

A.3.8.2.2
[G UIDELINE ] HD-PLC PHY Bridges should conform to the HD-PLC PHY Intermediate Device test
plan requirements at the time the product is offered to the market.

[ATTRIBUTES ]

S R n/a n/a n/a HD-PLC 7UW9V

Connectivity
Verification

[C OMMENT] HD-PLC PHY interoperability requirements will increase with time as new capabilities
and features are specified by HD-PLC. When these capabilities are added to the applicable HD-PLC
PHY certification test plans, HD-PLC PHY implementations should conform to them.

A.3.8.3 NC NID HomePlug AV and HD-PLC Bridge – Upgradeability

A.3.8.3.1
[G UIDELINE ] Homeplug AV PHY Bridges should be firmware updatable by the end user.

[ATTRIBUTES ]

S R n/a n/a n/a n/a HRMHF

A.3.8.3.2
[G UIDELINE ] HD-PLC PHY Bridges should be firmware updatable by the end user.

[ATTRIBUTES ]

S R n/a n/a n/a n/a VGOJD

A.3.8.4 NC NID HomePlug AV and HD-PLC Bridge – QoS support

A.3.8.4.1
[G UIDELINE ] Homeplug AV PHY Bridges should support DLNAQOS on all their network interfaces
in accordance with the Homeplug AV PHY recommendations in Section A.3.8.5 and Section A.3.8.6.

[ATTRIBUTES ]

S R n/a n/a n/a n/a 945CL

A.3.8.4.2
[G UIDELINE ] HD-PLC PHY Bridges should support DLNAQOS on all their network interfaces in
accordance with the HD-PLC PHY recommendations in Section A.3.8.5 and Section A.3.8.6.

[ATTRIBUTES ]

S R n/a n/a n/a n/a OHVYA

A.3.8.5 NC NID HomePlug AV and HD-PLC Bridge – QoS support

A.3.8.5.1
[G UIDELINE ] If DLNAQOS is supported on a Homeplug AV PHY network interface by a Homeplug
AV PHY Bridge, the Homeplug AV PHY interface should conform to all Homeplug AV PHY
mandatory requirements.

[ATTRIBUTES ]

S R n/a n/a n/a HomePlug AV 3U3DC

DLNA guidelines; Part 1-1: Architecture and protocols

 – 721 –

Specification

A.3.8.5.2
[G UIDELINE ] If DLNAQOS is supported on an HD-PLC PHY network interface by an HD-PLC PHY
Bridge, the HD-PLC PHY interface should conform to all HD-PLC PHY mandatory requirements.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 1901 76RWO

A.3.8.6 NC NID HomePlug AV and HD-PLC Bridge – Priority Mapping

A.3.8.6.1
[G UIDELINE ] When bridging between the Homeplug AV PHY network interface and an IEEE 802.3
network interface, packets received on the Homeplug AV PHY network interface and transmitted on
the IEEE 802.3 network interface should include the IEEE 802.1D user priority value in the
IEEE 802.1Q header and the DSCP tag corresponding to the Priority of the received Homeplug AV
PHY packets in accordance with Table A.8:.

Table A.8 – Homeplug AV Priority mapping

HomePlug AV IEEE 802.1D Priority DSCP

Channel Access Priority

CA0 1 BK 0x08
2- 0x10
CA1 0 BE 0x00
3 EE 0x18
4 CL 0x20
CA2 5 VI 0x28
6 VO 0x30
CA3 7 NC 0x38

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D SM4LG

IEEE 802.1Q
IETF RFC
2474
HomePlug AV
Specification

A.3.8.6.2
[G UIDELINE ] When bridging between the HD-PLC PHY network interface and an IEEE 802.3
network interface, packets received on the HD-PLC network interface and transmitted on the
IEEE 802.3 network interface should include the IEEE 802.1D user priority value in the
IEEE 802.1Q header and the DSCP tag corresponding to the Priority of the received HD-PLC PHY
packets in accordance with Table A.9.

Table A.9 – HD-PLC PHY Priority mapping

HD-PLC IEEE 802.1D Priority DSCP

Channel Access Priority

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 722 –

HD-PLC IEEE 802.1D Priority DSCP

Channel Access Priority

1 1 BK 0x08
2 2- 0x10
0 0 BE 0x00
3 3 EE 0x18
4 4 CL 0x20
5 5 VI 0x28
6 6 VO 0x30
7 7 NC 0x38

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D GH6B5

IEEE 802.1Q
IETF RFC
2474
IEEE 1901

A.3.8.6.3
[G UIDELINE ] When bridging between the Homeplug AV PHY network interface and an IEEE 802.3
network interface, packets received on the IEEE 802.3 network interface and transmitted on the
Homeplug AV PHY network interface should include the Homeplug AV PHY Priority corresponding
to the IEEE 802.1D user priority value in the IEEE 802.1Q header tag of the received IEEE 802.3
packets in accordance with Table A.10.

Table A.10 – Homeplug AV PHY access and IEEE 802.1 D priority

IEEE 802.1D Priority DSCP HomePlug AV

Channel Access Priority

1 BK 0x08
CA0
2- 0x10
0 BE 0x00
CA1
3 EE 0x18
4 CL 0x20
CA2
5 VI 0x28
6 VO 0x30
CA3
7 NC 0x38

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D UONY2

IEEE 802.1Q
IETF RFC
2474
HomePlug AV
Specification

A.3.8.6.4
[G UIDELINE ] When bridging between the HD-PLC PHY network interface and an IEEE 802.3
network interface, packets received on the IEEE 802.3 network interface and transmitted on the
HD-PLC PHY network interface should include the HD-PLC PHY Priority corresponding to the
IEEE 802.1D user priority value in the IEEE 802.1Q header tag of the received IEEE 802.3 packets
in accordance with Table A.11.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 723 –

Table A.11 – HD-PLC PHY access and IEEE 802.1 D priority

IEEE 802.1D Priority DSCP HD-PLC

Channel Access Priority

1 BK 0x08 1
2- 0x10 2
0 BE 0x00 0
3 EE 0x18 3
4 CL 0x20 4
5 VI 0x28 5
6 VO 0x30 6
7 NC 0x38 7

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D 83SLG

IEEE 802.1Q
IETF RFC
2474
IEEE 1901

A.3.8.6.5
[G UIDELINE ] When bridging between the Homeplug AV PHY network interface and an IEEE 802.3
network interface and an IEEE 802.3 packet is received that does not contain an IEEE 802.1Q tag,
the Homeplug AV PHY bridge should look at the DSCP tag and map that to a Homeplug AV PHY
Priority in accordance with the Table A.10 and preserve the DSCP tag across the IEEE 802.3 and
Homeplug AV PHY segments.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D A8A86

IEEE 802.1Q
IETF RFC
2474
HomePlug AV
Specification

A.3.8.6.6
[G UIDELINE ] When bridging between the HD-PLC PHY network interface and an IEEE 802.3
network interface and an IEEE 802.3 packet is received that does not contain an IEEE 802.1Q tag,
the HD-PLC PHY bridge should look at the DSCP tag and map that to a HD-PLC PHY Priority in
accordance with Table A.11 and preserve the DSCP tag across the IEEE 802.3 and HD-PLC PHY
segments.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D MZXY6

IEEE 802.1Q
IETF RFC
2474
IEEE 1901

A.3.8.6.7
[G UIDELINE ] If a Homeplug AV PHY Bridge receives an IEEE 802.3 packet that does not contain an
IEEE 802.1Q or a DSCP tag, the packet should be passed through to the Homeplug AV PHY
interface unmodified without the addition of any priority tagging.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 724 –

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D D3DII

IEEE 802.1Q
IETF RFC
2474
HomePlug AV
Specification

A.3.8.6.8
[G UIDELINE ] If an HD-PLC PHY Bridge receives an IEEE 802.3 packet that does not contain an
IEEE 802.1Q or a DSCP tag, the packet should be passed through to the HD-PLC PHY interface
unmodified without the addition of any priority tagging.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D L9D6B

IEEE 802.1Q
IETF RFC
2474
IEEE 1901

A.3.8.6.9
[G UIDELINE ] If a Homeplug AV PHY Bridge receives a Homeplug AV PHY packet that is not tagged
with a Homeplug AV PHY Priority, the packet should be passed through to the IEEE 802.3 interface
unmodified without the addition of any priority tagging.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D X7OMG

IEEE 802.1Q
IETF RFC
2474
HomePlug AV
Specification

A.3.8.6.10
[G UIDELINE ] If an HD-PLC PHY Bridge receives a HD-PLC PHY packet that is not tagged with a
HD-PLC PHY Priority, the packet should be passed through to the IEEE 802.3 interface unmodified
without the addition of any priority tagging.

[ATTRIBUTES ]

S R n/a n/a n/a IEEE 802.1D 94ETY

IEEE 802.1Q
IETF RFC
2474
IEEE 1901

DLNA guidelines; Part 1-1: Architecture and protocols

 – 725 –

Annex B
(informative)

Basic Tuner representation

B.1 General
A Tuner is a component of a server device that makes audio and video content available to a
Rendering Endpoint. This content can come from an audio or AV tuner. A key characteristic of a
Tuner is the ability to decode or demultiplex a single media stream from a number of available audio
or AV streams. Note that in this annex we refer to the abstract entity represented on the home
network as a Tuner (capitalized) and the physical building block inside the server doing the
decoding and demultiplexing as a tuner (without capitalization).

B.2 Tuner objects

The Tuner is represented as a CDS container (object.container) object. If a Content Source has two
or more identical tuners (for example a device with two NTSC analog tuners), each tuner can be
represented as a separate container object, or these tuners can be represented as a single
container. However, a single Tuner can present content from multiple sources (e.g., an STB that
provides Satellite and Terrestrial broadcast content), provided each channel can be uniquely
selected. A Basic Tuner container should have an informative name that enables a consumer to
easily distinguish the tuner. This could be based on the type of tuner. A Basic Tuner container shall
have a <dlna:containerType> property with a value of "Tuner_1_0" to allow control points to
differentiate them from other Container types.

B.3 Channel objects

B.3.1 General
A Tuner makes its content discoverable as one or more channels that are represented as CDS
videoBroadcast (object.item.videoItem.videoBroadcast) or audioBroadcast
(object.item.audioItem.audioBroadcast) items. Each Basic Tuner container should contain a
videoBroadcast or audioBroadcast item to represent each tunable (or selectable) channel. A Basic
Tuner container should contain only videoBroadcast or audioBroadcast items, or both. It may also
contain other objects that are directly related to the Tuner device or a specific channel. Control
points should gracefully ignore any items that they do not understand.

B.3.2 Channel order

These CDS Broadcast items should be presented in the order that best represents the order that
channels are typically presented to users. This allows a control point to perform "up channel" and
"down channel" operations by selecting the next or previous CDS Broadcast item, respectively. The
control point should utilize the order of the Broadcast items within the Container's XML element to
determine this order. Depending on the type of Tuner, this might be ascending broadcast frequency,
logical channel number assigned by a cable operator or satellite providers, etc. In certain regions,
channels are typically selected by the user from a set or list of user assigned channels, often called
"presets". In these applications the Server Device can choose to present the CDS Broadcast items
in the order the user has configured the presets (see guideline 10.1.4.16.6).

B.3.3 Channel Number

Wherever possible, the Server Device should present a Channel Number for each CDS Broadcast
item using the channelNr (upnp:channelNr) property. This allows the user to directly select the
desired channel by direct entry, rather than relying solely on "channel up" and "channel down"
actions.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 726 –

The UPnP namespace currently does not provide a subChannelNr property that makes
representation of some channel numbers difficult because the fact that the channelNr property is
restricted to integer values. Digital Television broadcasts commonly provide a multiple-program
Transport Stream within a single radio-frequency channel, and these programs are commonly
referred to as "subchannels". At this time, it is up to the implementer to decide how to best represent
subchannel numbers as there is no subChannelNr property in the upnp namespace. In the case of
broadcast sources where there exists a "primary" subchannel, an implementer could create a CDS
Broadcast item representing the "primary" subchannel using the main channel number (to preserve
the user expected channel number order), then a set of CDS Broadcast items representing the
subchannels, can be exposed by the DMS using channel numbers that are vendor specific. For
example, an over-the-air ATSC broadcast on radio-frequency Channel 40 with four subchannels,
with licensed Channel Number 7, could have a primary CDS Broadcast Item with a channelNr value
of 7 and four additional CDS Broadcast Items with channelNr values of 900, 901, 902, and 903 for
each subchannel.

If the Channel Number represents a preset number, the range should reflect the numbering scheme
normally presented to the user. This will typically be an ordinal number sequence (see guideline
10.1.4.20.1).

B.3.4 Channel Name

Wherever possible, the Server Device should present a Channel Name for each CDS Broadcast
item using the channelName (upnp:channelName) property. Examples of recommended names are
station identification (KOIN, FM 101.9, etc.) or network affiliation. The channelName property
should not represent program content. In addition, the channelName property should be unique
across all CDS Broadcast items in the Basic Tuner container. For example, if a tuner was able to
present both a Standard Definition and a High Definition broadcast of the National Cartoon Network
(NCN) channel, they should be named "NCN" and "NCN HD", respectively to preserve uniqueness.
The Channel Name should reflect the subchannel number where appropriate. For example, a
channelName of "Channel 40-1", "NCN-1", or "KGW-1", etc. would be appropriate for an
over-the-air ATSC CDS Broadcast item (see guideline 10.1.4.21).

B.3.5 Channel Title

The Channel Title is represented in the dc:title property, which all CDS items shall have. In
decreasing order of preference it should describe the program contents (i.e. "History of Cartoons"),
the channelName information ("NCN"), or channelNr information ("Channel 6") (see guideline
10.1.4.19).

B.4 Accessing a tuner channel

A Rendering Endpoint accesses a tuner channel by establishing a connection to the URI of the
resource associated with the CDS Broadcast item. If the Content Source accepts the connection, it
tunes to the channel represented by the CDS Broadcast item, and the channel's content is streamed
to the Rendering Endpoint. A Content Source may allow more than one Rendering Endpoint to
connect to a single CDS Broadcast item (streaming identical content to all connections). If multiple
connections to a tuner are allowed, it is up to the implementers to define arbitration logic to handle
multiple Rendering Endpoints attempting to establish connections to different CDS Broadcast items
(requesting two or more different channels simultaneously). A Content Source should refuse such
connection requests that cannot be accommodated and return an error code of 503 (Service
Unavailable) for either the HTTP transport or the RTP transport using RTSP. A separate transport
connection shall be established between each Serving and Rendering Endpoint even though
identical content will be sent over each connection.

A typical scenario for a device incorporating both a Rendering Endpoint and control point
component that interacts with a tuner occurs in the following manner. The control point component
presents the available channels to the user as they are exposed by a CDS. When the user selects
a specific channel for viewing, the Rendering Endpoint component issues an HTTP Get to the
Content Source for the URI of the selected channel's content to initiate streaming. When the user
DLNA guidelines; Part 1-1: Architecture and protocols
 – 727 –

wishes to change channels, the Rendering Endpoint component closes the existing HTTP
connection, and then issues a new HTTP GET to the Content Source for the URI of the new
channel's content.

Implementers should note that there is no feedback mechanism to notify a control point or
Rendering Endpoint that the current tuner channel has been changed by another control point or a
local user. Once a Rendering Endpoint has established an HTTP connection with the Content
Source to stream the Channel content, and later the Content Source changes the "current" channel,
the Content Source should stop streaming content and close the HTTP connection to indicate to the
Rendering Endpoint that the channel is no longer the "current" channel. A Rendering Endpoint may
terminate an HTTP connection at any time that it no longer wishes to receive the broadcast content.

Rendering Endpoints should be aware of the buffering requirements that live broadcast content
places on the Content Source. Due to the possible network congestion, the server will need to buffer
any temporary differences in the streaming rates between the incoming broadcast stream and the
rate that the Rendering Endpoint accepts data over the network. If the server is unable to buffer any
difference in rates, some of the data in the incoming broadcast stream will be lost. To avoid such
data loss, Rendering Endpoints should be designed to accept data from network with an average
rate equal to the live broadcast. Rendering Endpoints should also be designed to accept live
broadcast content as a continuous stream, rather than a series of burst transfers. Note that this
does not prevent a Rendering Endpoint from buffering content at the beginning of the streaming
session, or changing the amount of content buffered at the Rendering Endpoint during the session,
to account for the normal (and often dynamic) delays in HTTP network traffic.

B.5 Tuner example

The following XML document fragment shows a Server Device with two tuners, an NTSC TV Tuner
and an FM Radio Tuner. Note that the NTSC Basic Tuner container utilizes channel numbers based
on broadcast channels while the FM Basic Tuner container illustrates ordinal channel numbers
representing presets.

<DIDL-Lite
xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"
xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">
<!-- Root Container -->
<!--(
NOTE XML Comments prohibited per 9.2.30 and are only included for clarity) -->
<container id="0" parentID="-1" restricted="1" childCount="2">
<dc:title>DLNA Device</dc:title>
<upnp:class>object.container</upnp:class>
<!-- NTSC TV Basic Tuner container -->
<container id="1" parentID="0" restricted="1" childCount="2">
<dc:title>NTSC TV Tuner</dc:title>
<upnp:class>object.container</upnp:class>
<dlna:containerType>Tuner_1_0</dlna:containerType>
<!-- NTSC TV Channels -->

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 728 –

<item id="1-1" parentID="1" restricted="1">

<!-- Full Description -->
<dc:title>Cartoons, Cartoons, Cartoons</dc:title>
<upnp:class>object.item.videoItem.videoBroadcast</upnp:class>
<upnp:genre>Movie</upnp:genre>
<upnp:channelNr>2</upnp:channelNr>
<upnp:channelName>PBS</upnp:channelName>
<res protocolInfo="http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC">
http://192.168.0.20:58849/Tuner1/ch2.mpg
</res>
</item>
<item id="1-2" parentID="1" restricted="1">
<!-- Minimal Description -->
<dc:title>Channel 4</dc:title>
<upnp:class>object.item.videoItem.videoBroadcast</upnp:class>
<upnp:channelNr>4</ upnp:channelNr>
<res protocolInfo="http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC";
DLNA.ORG_FLAGS=85100000000000000000000000000000>
http://192.168.0.20:58849/Tuner1/ch4.mpg
</res>
</item>
</container>
<!-- FM Radio Basic Tuner container -->
<container id="2" parentID="0" restricted="1" childCount="3">
<dc:title>FM Radio Tuner</dc:title>
<upnp:class>object.container</upnp:class>
<dlna:containerType>Tuner_1_0</dlna:containerType>
<!-- FM Radio Channels -->
<item id="2-1" parentID="2" restricted="1">
<!-- Preset #1 -->
<dc:title>FM 89.9</dc:title>
<upnp:class>object.item.audioItem.audioBroadcast</upnp:class>
<upnp:channelNr>1</upnp:channelNr>
<upnp:channelName>FM 89.9</upnp:channelName>
<res protocolInfo="http-get:*:audio/L16:DLNA.ORG_PN=LPCM;
DLNA.ORG_FLAGS=85100000000000000000000000000000">
http://192.168.0.20:58849/Tuner2/ch1.L16
</res>
</item>
<item id="2-2" parentID="2" restricted="1">
<!-- Preset #2 -->
<dc:title>FM 101.9</dc:title>
<upnp:class>object.item.audioItem.audioBroadcast</upnp:class>
<upnp:channelNr>2</upnp:channelNr>
<res protocolInfo="http-get:*:audio/L16:DLNA.ORG_PN=LPCM">
http://192.168.0.20:58849/Tuner2/ch2.L16
</res>
</item>

DLNA guidelines; Part 1-1: Architecture and protocols

 – 729 –

<item id="2-3" parentID="2" restricted="1">

<!-- Preset #3 -->
<dc:title>FM 95.5</dc:title>
<upnp:class>object.item.audioItem.audioBroadcast</upnp:class>
<upnp:channelNr>3</upnp:channelNr>
<res protocolInfo="http-get:*:audio/L16:DLNA.ORG_PN=LPCM">
http://192.168.0.20:58849/Tuner2/ch3.L16
</res>
</item>
</container>
</container>
</DIDL-Lite>

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 730 –

Annex C
(informative)

UPnP devices with multiple network interfaces

C.1 Representation at the UPnP Device level
This annex describes the subtleties and the intent behind the DLNA Home Networked Device
interoperability guidelines for DLNA devices that simultaneously use multiple network interfaces or
multiple addresses (e.g. IPv4 and IPv6) for the same interface. Readers should be familiar with the
language of the following guidelines: 9.2.27 and 10.1.4.6. This annex summarizes two problems:
how to represent a UPnP device on multiple network interfaces and how to represent content
available on multiple network interfaces 6. Although they are separate issues, the way a vendor
solves the second problem will depend largely on how the first problem is solved. In the paragraphs
below, much of the text will describe scenarios with two network interfaces for example purposes.
The number of supported interfaces for UPnP devices may be more than two.

Previously, there were two primary techniques for representing UPnP device on multiple network
interfaces. Both techniques were allowed for IPv4 deployments, but for devices that support IPv6,
now only a single technique is recommended. The first technique is for the UPnP device to
represent itself as multiple UPnP devices at the UPnP network layer, by using different UDN values
for each discoverable UPnP device, with each UPnP device bound to a specific network interface.
Figure C.1 describes this concept, with one logical UPnP device advertising two UPnP AV
MediaServers (DMS devices). Each UPnP AV MediaServer also has a different UDN. Furthermore,
through guideline 9.2.27.4, control points also obtain the correct IP address for each logical UPnP
device.

Figure C.1 – UPnP Device representation

___________

6 Throughout the DLNA Home Networked Device interoperability guidelines, the terms “network interface”, “home network
segment”, or “home network interface” are used to denote one of the layer-2 connectivity technologies such as Wi-Fi,
Ethernet, MoCA, etc.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 731 –

An important observation is that Network A and Network B can be bridged or completely separate
networks. Another important clarification is that MS-1 and MS-2 are not part of he same UPnP
device hierarchy. Similarly, control points find MS-1 and MS-2 in separate device description files.
For all intents and purposes, a control point that discovers MS-1 and MS-2 will not be able to
conclude that both UPnP devices are part of the same product. Regardless of the topology, the only
conclusions that a control point can make about the two UPnP devices is whether the (logical) UPnP
devices are on the same UPnP network.

• If the control point sees UDN-1 and UDN-2 on the same network interface, then MS-1 and MS-2
are on the same UPnP network.
• If the control point sees UDN-1 and UDN-2 on different network interfaces, then MS-1 and MS-2
are on different UPnP networks.
Although a control point might not be able to identify the discoverable UPnP devices as part of a
common logical UPnP device, additional meta-information might allow the user to make such a
conclusion. For example, DMS-1 might have a UPnP friendly name of "Living Room Server (Wired)"
and DMS-2 might have a friendly name of "Living Room Server (Wireless)". Of course, the friendly
name for both UPnP devices could be identical, such as "Living Room Server". The interoperability
guidelines do not make any recommendations or set requirements about the friendly names of
UPnP devices because rules on meta-information depend more on philosophy and are less about
protocol interoperability.

Lastly, even though the interoperability guidelines do not specifically state guidelines describing
this type of behavior, the implementation technique is understood to be acceptable. The guidelines
are worded to allow representation of a logical UPnP device through multiple, discoverable UPnP
devices. The primary reason why this implementation technique is not described in guidelines is that
it is virtually impossible for a UPnP control point to detect that two discoverable UPnP devices
represent a logical UPnP device.

The second and reccomended technique for representing UPnP devices on multiple IPv4 network
interfaces or an IPv6 network interface is to have the UPnP device report the same UDN on multiple
network interfaces or the same interface with multiple addresses. Figure C.2 describes this concept.

Figure C.2 – UPnP device on multiple networks

Just like Figure C.1, Network A and Network B may be bridged or separate networks, for IPv4, IPv6
or both. In this type of implementation, a control point discovers only one UPnP device instead of

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 732 –

multiple UPnP devices. However, the control point might see multiple IP addresses, depending on
the network topology, allowing the control point to generally conclude one or more of the following.

• If the control point sees IP address 1 and IP address 2 on the same network interface, then the
UPnP device is on one network with two different addresses. This includes the case of IPv4 and
IPv6 addresses on the same interface.
• If the control point sees IP address 1 and IP address 2 on separate network interfaces (within
10 s of each other), then the UPnP device is on two different UPnP networks.
• If the control point sees IP address 1 and sees IP address 2 within 10 s, then the control point
can conclude that the UPnP device has two IP destinations that seem equally reliable.
The advantage of using this technique is that the control point knows for sure that there is only one
UPnP device. This allows the user interface of a control point to report one UPnP device instead of
reporting multiple UPnP devices.

The interoperability guidelines focus mostly on what the UPnP devices can or shall do about
multiple network interfaces. The interoperability guidelines do not specify any mandatory behavior
for a control point because vendors believe that a variety of techniques can be used to present
UPnP devices to a user. Guidelines 9.2.27.4 and 9.2.27.5 provide some ideas about what a control
point can do, but vendors will need to design their control point taking into account many factors that
are not discussed in the interoperability guidelines.

C.2 Representation at the CDS level

The reccomended technique shown in Figure C.3 for representing content available on multiple
network interfaces builds on the reccomended technique for representing UPnP devices.
Essentially, the DMS implementation uses one DMS representation, and the URI values that are
reported depend on the Filter argument and on the network interface or the IP address that received
the SOAP request, as described below.

• The logical UPnP AV MediaServer represents itself with a single discoverable UPnP AV
MediaServer (DMS device).
• The discoverable UPnP AV MediaServer is associated with all available network interfaces and
IP addresses.
• The discoverable UPnP AV MediaServer reports the same UDN value on each network
interface.
• If the discoverable UPnP AV MediaServer receives a CDS:Browse or CDS:Search request and
the Filter argument does not have the ALLIP value, then it returns all URI values for the network
interface that received the SOAP request. Essentially, a control point can assume that there
exists a network route from the control point to any of the URI values' network addresses, which
are returned by the DMS.
• If the discoverable UPnP AV MediaServer receives a CDS:Browse or CDS:Search request and
the Filter argument has the ALLIP value, then the UPnP AV MediaServer responds with all URI
values, regardless of whether the URI is associated with the interface that received the SOAP
request.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 733 –

Figure C.3 – Content URIs over multiple networks

For this type of implementation, a control point that does not use the ALLIP value in the Filter
argument can safely assume that a network route exists between the control point and each of the
returned URI values. This assumption can be made because of guideline 10.1.4.6.1, which requires
DMS-1 to never report URI values that have a Network B address, unless ALLIP is used. Likewise,
DMS-2 can never report URI values that have a Network A address, unless ALLIP is used.

However, when the ALLIP value is used in the Filter argument, a control point will get all of the URI
values, regardless of their network address values. Although not important for transactions between
a DMS and DMP, this capability becomes important for future use cases such as supporting both
IPv4 and IPv6.

C.3 Understanding the "treated as or assumed to be routable" clause

To build on the examples in the previous subclause, MS-1 is on Network A with IP Address 1. When
a control point finds content on MS-1, the control point will receive <res> URI values with IP Address
1. The control point will never see a <res> URI value with IP Address 2 when communicating with
MS-1 because that would be a violation of guideline 10.1.4.6.1. One interesting aspect of the clause
occurs when content is not served by the DMS implementation (i.e. it is advertised by the DMS but
stored elsewhere). Technically, an Internet-sourced URI is not prohibited so long as the URI is
routable from the Internet to the local network and the URI is an absolute URI with an IP address in
a.b.c.d (quad-form network byte order). Since this condition is difficult to guarantee (e.g. an Internet
service is down) and many see the value of Internet-sourced content for the future, the DLNA Home
Networked Device interoperability guidelines use this clause instead of explicitly stating "all URI
values shall have the same network address." In the case where ALLIP is used, control points need
to be careful about non-routable addresses.

Lastly, this clause applies to any IP URI regardless of whether the content complies with a DLNA
Media Format Profile. In the case of non-IP URI values, a DMS should always publish non-IP URI
values (e.g. IEEE 1394, etc.) because a DMP can determine routability from the ProtocolInfo value.

C.4 Multiple <res> elements

On the issue of multiple network interfaces, guidelines 10.1.4.6.3 and 10.1.4.6.4 recommend that a
DMS publishes multiple <res> elements (of each CDS object) instead of duplicate CDS objects. The
DLNA Home Networked Device interoperability guidelines do not specifically mention the use of
multiple CDS objects because this behavior is legal for UPnP AV. However, building a DMS to report
multiple CDS objects might result in a user interface displaying multiple entries, with duplicate
metadata. Since lower resolution television screens have limited space, the DLNA recommends that
vendors avoid this type of implementation. The use of multiple <res> elements is a better approach
because it allows control points to determine that the same content is accessible on different

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 734 –

networks, in different formats, or via different transports. Furthermore, control points can build
better user interfaces.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 735 –

Annex D
(informative)

Example applications of the Uniform

Client Data Availability Model
D.1 Uniform Client Data Availability Model definitions
D.1.1 General
This annex clarifies the general applicability of the Uniform Client Data Availability Model (UCDAM).
The annex describes the data accessibility assumptions for both Content Sources and Content
Receivers. The UCDAM model strives for completeness by using examples derived from stored,
converted, and live content streams. The model also accounts for caching of data by Content
Receivers.

D.1.2 The stream

In the most abstract sense, a stream is simply a data range of content, defined as [d X , d Y ]. For
content stored within a file, the data range for a content stream is fixed. This means that d X and d Y
remain fixed over time. In some cases, the stream never ends, such that d Y increases with time. For
example, content described as "being sourced from a tuner" or "an infinite broadcast stream" are
examples of infinite data streams, as represented in Figure D.1.

Figure D.1 – Abstract representation of a stream

Given a stream, there is one data range of primary interest: [s 0 , s N ]. This data range represents
what a Content Source can transmit. A secondary data range of interest is [r 0 , r N ], which is a data
range that supports random access operations on the Content Source. If enabled, this data range is
always an equal [s 0 , s N ].

Tangential to these data ranges is the [d 0 , d N ] data range. This is the range of data that the Content
Receiver has available to it from either local buffering or directly from the Content Source. This data
range is not referenced in transport layer guidelines because Content Receivers have a wide range
of options for local buffering techniques. Ultimately, the [d 0 , d N ] data range is neither discoverable
nor of any interest to Content Sources, so the focus of the guidelines remains on the Content Source
data ranges.

Since the DLNA guidelines primarily focus on network transactions, the guidelines generally avoid
distinctions between stored, converted, or live content. The guidelines focus more on a Content
Receiver's ability to determine the Content Source's transport layer behaviors. Therefore, it is
important to remember that implementation details that are discussed in this annex are for
information only. The examples serve to illustrate how vendors can implement against the
guidelines based on the UCDAM. Although examples might cite a specific context (such as stored
content versus live content) actual implementations may deviate from these examples while
conforming to the normative guidelines.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 736 –

D.1.3 Stored content

D.1.3.1 General
In the simplest cases involving Streaming Transfer Mode operations on stored content (Audio-only
or AV Media Class), Content Sources are generally able to access the entire stream and provide the
entire data range to the Content Reciever. This means that the [s 0 , s N ] data range is equal to the [d X ,
d Y ] data range, and both are fixed data ranges, see Figure D.2.

Figure D.2 – A stored content stream

D.1.3.2 Random access

There is a subtle aspect to consider regarding random access for all content, including stored
content. The UCDAM makes no claims regarding a Content Source's ability to perform random
access operations on the [s 0 , s N ] data range. Consider a DMS that does not advertise content with
the DLNA.ORG_OP parameter. This type of a DMS claims that the Range HTTP header is not
supported at the transport layer. Although the DMS is able to transmit all of the data in [d X , d Y ], the
ability for the Content Receiver to randomly access the data is not available, see Figure D.3 and
Figure D.4. This limitation can affect the ability for a DMP or DMR to support media operations like
pause, pause-release, seek, and forward and backward scanning with the DMS.

Figure D.3 – Stream with no random access support

Figure D.4 – Stream with random access support

Random access operations are not limited to HTTP requests that involve the Range header, see
Figure D.4. Other examples include HTTP requests with the TimeSeekRange.dlna.org header. The
guidelines for RTP seek operations might also have dependencies on being able to do some form of
random access.

D.1.4 Converted content

Some DMS implementations are able to offer multiple versions of the same content. For purposes of
discussion, assume that the original version of the content is a native version stored on the DMS.
The additional formats made available by the DMS are called converted versions. Converted
content is a convenient way for a DMS to provide support for baseline Media Format Profiles when

DLNA guidelines; Part 1-1: Architecture and protocols

 – 737 –

the original version is in an optional Media Format Profile. Common forms of conversions include
transcoding, transscaling, and transrating.

A Content Source that claims support for [r 0 , r N ] data range is required to support random access on
the entire range of [s 0 , s N ]. The only time where this is computationally difficult is when performing
random access operations and when responding to requests with the Range header. This difficulty
manifests itself primarily in the server having a (long) delay when responding to such requests. To
assist Content Receivers in making intelligent decisions about using such requests, the guidelines
allow the server to report a byte range that is a subset of [r 0 , r N ].

D.1.5 Live content

Live content is more complex than stored or converted content because it opens up the possibility of
infinite streams (increasing d Y value) and introduces the concept that portions of a stream might
never be available after a certain point in time (increasing s 0 and s N values). This subclause
describes a few variations that Content Sources could use when distributing a live stream. Please
note that figures in this subclause are not drawn to scale.

During the initialization phase, the buffer exhibits the behavior of a growing buffer. In this phase, the
Content Source has fixed values for d X , s 0 , r 0 , and r N , while having an increasing value for d Y = s N ,
see Figure D.5.

Figure D.5 – Live stream with growing buffer and no random access

If the Content Source is able to handle random access requests, then the model is slightly different.
Given the UCDAM, it is possible for a Content Source to change the [r 0 , r N ] range after the
transmission starts. In Figure D.6, the Content Source supports random access requests on the
same range as the [s 0 , s N ] data range.

Figure D.6 – Live stream with growing buffer and random access

Since this is an infinite stream, the Content Source will eventually run out of local memory or storage
for buffering. When this happens, the Content Source may exhibit a sliding window behavior, as
shown in Figure D.7.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 738 –

Figure D.7 – Live stream with sliding buffer and random access support

The last variant is really an implementation detail that is hidden. Some live streams might be time
delayed. Some implementations can use time delaying as a way of having sliding buffer from the
very beginning of stream. In practice, there is no way to distinguish between a time-delayed live
stream and other live streams. Therefore, it is functionally identical to the previous case. The only
difference is the relationship between the normative s N data position and the theoretical d Y data
position, see Figure D.8.

Figure D.8 – Time-delayed live stream with sliding buffer and random access support

D.2 UCDAM and media operations

D.2.1 General
This annex is an examination of the media operations and how Content Sources and Content
Receivers need to account for data ranges.

D.2.2 Data ranges

The DLNA guidelines do not mandate a particular buffering model on either Content Sources or
Content Receivers. As a corollary, the guidelines do not prohibit Content Receiver implementations
that cache content data. In practice, this means Content Sources have complete control over the
behavior of their accessible content data range (i.e. [s 0 , s N ]) and Content Receivers have complete
control over the behavior of their accessible content data range (i.e. [d 0 , d N ]).

For numerous Content Receivers, the [s 0 , s N ] and [d 0 , d N ] are effectively identical. This means that
the Content Receiver only accesses data that the Content Source can provide at any given time.
However, some Content Receivers are able to expand their [d 0 , d N ] data range by caching data. For
example, a Content Receiver might be able to display data to the user that is no longer available
from the Content Source.

Although the UCDAM takes data caching into account, DLNA guidelines do not specify how a
Content Receiver determines its [d 0 , d N ] data range because it is considered an implementation
detail that is out-of-scope. (This is the same reason why DLNA guidelines do not specify how a
Content Source determines its [s 0 , s N ] buffer, relative to the theoretical [d X , d Y ] data range.

However, the role of guidelines is specifying interoperable behavior. To meet this objective, the
DLNA guidelines define media operations in terms of the [d 0 , d N ] data range because that is the data
range that affects what a user will perceive. Simultaneously, the guidelines specify syntax and
transport protocol requirements that govern transactions between Content Sources and Content
Receivers.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 739 –

D.2.3 Play data flow

The most basic streaming operation is the Play media operation. When a Content Receiver initiates
a Play media operation with a Content Source, the Content Source has to choose a starting
playback position (dPlayStart), which is in the [s 0 , s N ] data range. In the stored content scenario,
this maps to the first byte of the actual content file. The converted content scenario is very similar,
except the converted content may be dynamically generated in response to a request.

In the case of live content, the Content Source generally uses the dLive position (at the time of
receiving the Play request) as the dPlayStart value. Generally, the dLive position moves forward
with time by being attached to an original broadcast source's live position. However, the DLNA
guidelines do not define a mandatory rate for updating the dLive position, so two Play requests
could have the same dPlayStart even though they were made at different times. This leads to a
corollary that dLive might be a time-shifted stream, although it is impossible for Content Receivers
to know the size of the time-shift. The DLNA guidelines do not define a normative time-range for
time-shifting, so it is theoretically possible for a Content Source (with a lot of local storage) to
always choose the first byte of an always-increasing [s 0 , s N ] data range as the dPlayStart.

In summation, vendors can assume two things. Content Sources have a lot of flexibility when
choosing a dPlayStart position when responding to a Play request. Content receivers can rely on a
convention that the first received byte maps to the "beginning of content" but the convention is not
generally applicable to live content. Without precise, formal definitions for stored, converted, or live
content, the guidelines can only rely on conventions, which might be sufficient since the typical
convention for stored content is already in widespread use by both computing and consumer
electronics devices.

D.2.4 Stop data flow

By convention, a device that can play can also stop. The Stop operation means that a user sees a
stop in the playback. Devices implement a Stop operation by stopping the data flow at the network,
with one subtle exception. Since the guidelines do not specify how a Content Receiver maintains its
[d 0 , d N ] data range, Content Receivers are permitted to continue data streaming from the Content
Source. This operational policy is permissible because Content Receivers are the endpoints that
initiate an end to data transmission.

D.2.5 Pause and Pause-release data flow

The DLNA guidelines define the pause and pause-release operations. Just like the case for the Stop
operation, the guidelines have the general expectation that data flow will cease at the network, with
exceptions made for Content Receivers that cache data.

In the cases for stored content, the Pause and Pause-release operations operate consistently by
convention. Generally, a user initiates the Pause operation at some particular playback position
(dPause). When the user initiates the Pause-release operation, playback resumes. The Content
Source and Content Receiver determine the location dResume in the content stream where the
transfer resumes. Depending on user preferences and the type of the stream, the Content Receiver
might wish to continue the stream from where the Pause operation was initiated (i.e. dResume =
dPause). In many cases however, the ability to resume can sometimes be affected by a Content
Source's ability to randomly access data at the dResume position. For example, if the Content
Receiver disconnected the TCP connection as part of a Pause operation, and it wishes to resume
with dResume = dPause, it should reconnect the TCP connection and perform a Seek operation to
move to dPause. In order to satisfy this request, the Content Source would need to have dResume
in the [r 0 , r N ] data range in order to support this request. However, in the case of live or transcoded
content, the Content Source might not be able to satisfy this request. In this case, the Content
Source and Content Receiver, given the knowledge of the Content Source's [s 0 , s N ] data range,
determine an appropriate location in the stream to continue the transfer. For example, for live

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 740 –

content where s 0 = s N the point at which the stream is continued is the current sample of the live
stream.

Regardless of whether the content is stored, converted, or live, Content Receivers are always able
to determine the supported transport layer features for the content. Therefore, the most consistent
behavior is to disable the Pause operation when the Content Receiver detects that it cannot perform
a Pause-release operation from the paused position.

D.2.6 Scan operations

The DLNA guidelines define four types of scan operations: Fast Forward, Fast Backward, Slow
Forward, and Slow Backward.

Since the UCDAM does not mandate a particular buffering model on the content source, there are
no requirements about how the Content Source's [s 0 , s N ] data range changes with time. In the case
for stored and converted content, the [s 0 , s N ] data range generally never changes. It remains fixed
and represents the entire content binary. In the case of live content, the data range can grow,
exhibiting a growing buffer. At other times the data range can appear to slide forward with time
because the content source has a buffering limit. In some cases, the data range can even
temporarily shrink because the content source buffers use a variable bitrate.

Despite the possible diversity of Content Source buffering models, Content Receivers need to
handle one general problem that can happen with any of the scan operations: what does the Content
Receiver do when a scan operation has reached the [d 0 , d N ] boundary? (Usually, this problem is
caused by a limited [s 0 , s N ] data range.)

DLNA guidelines; Part 1-1: Architecture and protocols

 – 741 –

Annex E
(informative)

Auto-IP developer guidance

E.1 Goal
The purpose of this annex is to provide developer guidance on extending Auto-IP support for IP
Stacks that have problems with full conformance to Auto-IP. Auto-IP is a feature that allows a device
the capability of automatically configuring a private IPv4 address when a DHCPv4 server is
unavailable. A device with an Auto-IP address is only able to communicate with other devices that
also have an Auto-IP address on the same physical or logical link

E.2 Overview
The DLNA guidelines support two IPv4 address allocation systems, DHCPv4 and Auto-IP. DHCPv4
supports the allocation of routable IPv4 addresses for network environments that have multiple
subnets, while Auto-IP allocates non-routable, link-local addresses. In various DLNA
interoperability testing, it has been observed that some IPv4 stack implementations have difficulty
communicating between a device that has used DHCPv4 to obtain its IPv4 address and one that has
used Auto-IP. This situation can arise during times when the DHCPv4 server is offline. DHCPv4
address leases expire at randomly spaced times, so some devices might need to renew their
address leases while the DHCPv4 server is offline. Not finding a DHCPv4 server, the device will
assign its own IPv4 address with the Auto-IP protocol. Other devices, whose leases have not
expired, will continue to use their DHCPv4 assigned address. This mix of address allocation
systems will persist until all of the leases have expired and every device has allocated Auto-IP
addresses, or until the DHCPv4 server is online again, and devices sense its presence and revert to
using the DHCPv4 server (as per the mechanism defined in the guidelines). This annex will provide
additional guidance for device implementations to overcome the communication problems during
this transition.

IPv4 Mixed Network (Auto-IP and DHCPv4), as shown in Figure E.1 depicts a simple network
configuration where device A is using an IPv4 address assigned by a DHCPv4 server and device B
has an Auto-IP allocated address. Auto-IP assigned addresses are in the range 169.254.0.0/16
while DHCPv4 assigned addresses use other addressing ranges. Device A has been configured
with IPv4 address 192.168.1.100 and a subnet mask of 255.255.255.0. When it attempts to send a
packet to device B with Auto-IP assigned address 169.254.21.113 it does not recognize that
address as being on the local subnet and sends all IPv4 packets to device B to the default gateway.
Additionally, device B is not configured with a default gateway because it is using a link local
address. When device B attempts to send a packet to device A, it cannot determine if the packet is
bound for the local subnet or elsewhere. Because it does not have a gateway, the observed
behavior for some implementations is for device B to hold all IPv4 packets with a destination IPv4
address different from the Auto-IP subnet. In this situation, device A and device B cannot
communicate.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 742 –

Figure E.1 – IP mixed network (Auto-IP and DHCPv4)

Some IPv4 stack implementations have been observed to exhibit this behavior. While the Auto-IP
specification version used by UPnP ISO/IEC 29341-1 requires that no packet with a link-local
address as either the source or destination be sent to a gateway, it does not strictly require that a
device attempt to send such a packet on the local subnet by default. It is also recognized that device
manufacturers might not have the ability to change the IPv4 stack implementations on their devices
because they obtain the stacks from other third party software vendors. This annex suggests a
simple mechanism to allow communication between devices with two different IPv4 address types
while not requiring software changes on either device.

E.3 Suggested solution

E.3.1 General
To overcome the problem of communication between devices that allocate their IPv4 address with
different systems, it is suggested to add new routes to each device that require packets bound to the
other device to be sent on the local link. The advantage of such a solution is that it limits the effects
of the IPv4 address modification to the device changing its IPv4 address. Note that these additional
routes are correct for the types of traffic being sent on the local address, they make explicit the
requirements of the Auto-IP specification to the routing software. Consequently, they can be used
independent of the OS and system platform employed.

Disclaimer: although this mechanism has been verified on two major

operating systems, this is not an absolute guarantee of success.

E.3.2 Route for an Auto-IP device sending packets

Devices with an Auto-IP address (e.g.: device B) should specify a default IPv4 route for all traffic not
part of the Auto-IP subnet (169.254.0.0/16). In contrast to a regular default route the new route does
not direct default IPv4 traffic to the gateway. Rather, it instructs the IPv4 stack to forward all packets
to an unknown subnet on the local link physical interface.

The consequence of such a route is that traffic to any IPv4 address (Auto-IP allocated, DHCPv4
allocated or other IPv4 addresses) is considered reachable on the local link. While this does not
allow communication between devices that assign addresses with Auto-IP and devices on other
subnets, this is not a limitation of the solution but rather a limitation of Auto-IP itself. The Auto-IP
specification requires that no packet to or from a device using an Auto-IP allocated address is to be
forwarded to a gateway. This route simply makes that requirement explicit in the routing table.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 743 –

Table E.1 shows the new route in bold.

Table E.1 – Auto-IP route

Network destination Netmask Interface Gateway

169.254.0.0 255.255.0.0 [OS dependent] lan0

0.0.0.0 0.0.0.0 [OS dependent] lan0

E.3.3 Route for a DHCPv4 device sending packets

Devices with a DHCPv4 IPv4 address (e.g.: device A) should specify a new IPv4 route for all traffic
bound to addresses within the Auto-IP address range. The expected behavior is to force the device
with DHCPv4 IPv4 address to recognize a new subnet, namely the Auto-IP subnet. This route will be
to specify that all packets bound for the Auto-IP subnet will be sent on the local address interface
and not forwarded to the gateway. This is correct behavior since by definition all Auto-IP allocated
addresses are on the local link.

Table E.2 shows the new route in bold.

Table E.2 – DHCPv4 route

Network Netmask Interface Gateway

destination

192.168.1.0 255.255.255.0 [OS dependent] lan0

169.254.0.0 255.255.0.0 [OS dependent] lan0
0.0.0.0 0.0.0.0 192.168.1.1 lan0

E.4 Validation example using UPnP AV applications

E.4.1 General
Using Microsoft Windows® 2000 Professional, Microsoft Window® XP Professional and Linux
machines the following test has been conducted. Device A has a DHCP IP address with a fairly long
lease time (in order to maintain the assigned IP address during the entire test). Once device A has
received its DHCP IP address, the DHCP server is removed from the network and the second device
(B) is connected and started. Without a discoverable DHCP server, device B assigns itself an
Auto-IP address. The suggested routes are manually added using the appropriate command line
application "route". UPnP AV applications are used to validate the communication between devices
A and B. Device A runs an UPnP AV Media Server and device B runs an UPnP Media Renderer.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 744 –

Figure E.2 – Communication in mixed IP network.

The UPnP AV Media Server on device A and UPnP AV Media Renderer on device B broadcast their
presence with their own IP addresses. With the help of the new routes both applications
communicate correctly and transparently without any problems.

E.4.2 How to add a route on Windows 2000 and Windows XP?

The command line application "route" allows you to manipulate a network IP routing table. The
command "route add" is used to add a new route while "route delete" is used to remove an existing
route. For example, the first command listed below can be used on the Auto-IP device (device B in
Figure E.2) to add a default route for all traffic to be placed on the local link. The second command
listed below can be used on the DHCP device (device A in Figure E.2) to ensure that all traffic bound
for an Auto-IP device also is placed on the local link.

C:\> route add 0.0.0.0 mask 0.0.0.0 169.254.21.113 // device B

C:\> route add 169.254.0.0 mask 255.255.0.0 192.168.1.100 // device A

Please note that under Windows the IP address of the device itself (169.254.21.113 or
192.168.1.100) is used to specify a local link interface. The device's IP address is also used for the
gateway parameter.

And the following commands respectively remove the same routes:

C:\> route delete 0.0.0.0 mask 0.0.0.0 169.254.21.113 // device B

C:\> route delete 169.254.0.0 mask 255.255.0.0 192.168.1.100 // device A

Alternatively, the API functions CreateIpForwardEntry and DeleteIpForwardEntry from the Platform
SDK*: IP Helper can also be used within an application to add and remove routing table entries.

Table E.3 and Table E.4 show Windows routing table examples respectively for a device using an IP
address assigned by a DHCP server (device A) and for a device using an Auto-IP address (device
B).

Table E.3 – Windows routing table example for device w/DHCP address

Active Routes:Network Netmask Gateway Interface Metric

Destination

DLNA guidelines; Part 1-1: Architecture and protocols

 – 745 –

Active Routes:Network Netmask Gateway Interface Metric

Destination

0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 30

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
169.254.0.0 255.255.0.0 192.168.1.100 192.168.1.100 30
192.168.1.0 255.255.255.0 192.168.1.100 192.168.1.100 30
Default Gateway:192.168.1.1

Table E.4 – Windows routing table example for device w/Auto-IP address.

Active Routes:Network Netmask Gateway Interface Metric

Destination

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

169.254.0.0 255.255.0.0 169.254.21.113 169.254.21.113 30
169.254.21.113 255.255.255.255 127.0.0.1 127.0.0.1 30
Default Gateway:169.254.21.113

E.4.3 How to add a route on Linux?

The command line application "route" allows you to manipulate network IP routing tables. The
command "route add –net" is used to add a new network route while "route del –net" is used to
remove an existing network route. For example, the following commands respectively add the
default route for the Auto-IP device and the route to Auto-IP subnet for the device with DHCP IP
address:
user@host-B:# route add -net 0.0.0.0 netmask 0.0.0.0 eth0
user@host-A:# route add -net 169.254.0.0 netmask 255.255.0.0 eth0

And the following commands respectively remove the same routes:

user@host-B:# route del -net 0.0.0.0 netmask 0.0.0.0 eth0
user@host-A:# route del -net 169.254.0.0 netmask 255.255.0.0 eth0

Alternatively, the system ioctl function in combination with socket IO Controls SIOCADDRT and
SIOCDELRT can also be used within an application to add and remove routing table entries.

Table E.5 and Table E.6 show Linux routing table examples respectively for a device using an IP
address assigned by a DHCP server (device A) and for a device using an Auto-IP address (device
B).

Table E.5 – Linux routing table example for device w/DHCP address

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.1.0 * 255.255.255.0 U 0 0 0 eth0

169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 746 –

Table E.6 – Linux routing table example for device w/Auto-IP address

Destination Gateway Genmask Flags Metric Ref Use Iface

169.254.0.0 * 255.255.0.0 U 0 0 0 eth0

default * 0.0.0.0 UG 0 0 0 eth0

E.5 Installing routes during address transitions

Please note that the network routing table shall be dynamically modified each time a new type of IP
address is assigned to a device. When a device allocates a DHCP address, the default route for
Auto-IP devices should be installed in the routing table. This route may remain in place across IP
address transitions. When a device allocates an Auto-IP address, the default route for all traffic
should be installed in the routing table, specifying the local link. This route shall be removed
whenever the device transitions back to a DHCP address, and should be replaced by the gateway
specification obtained via DHCP.

Figure E.3 shows an example of the additional route (grey boxes) in the IP Address assignment
flow.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 747 –

Figure E.3 – New routes in address transition flow

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 748 –

Annex F
(informative)

RTP Protocol Stack and SDP/RTSP/RTCP Parameters

Figure F.1, Figure F.2 and Figure F.3 provide an overview of the RTP transport protocol stack, SDP
and RTSP parameters and RTCP parameters, respectively.

Figure F.1 – Overview of the protocol stack for RTP transport

DLNA guidelines; Part 1-1: Architecture and protocols

 – 749 –

Figure F.2 – SDP and RTSP Parameters

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 750 –

Figure F.3 – RTCP Parameters

DLNA guidelines; Part 1-1: Architecture and protocols

 – 751 –

Annex G
(informative)

Guidance on address conflict resolution in Auto-IP

Autoconf or Zerconf address allocation may be used for DLNA devices in the absence of a DHCP
address server. There are a number of different Internet Draft versions of AutoIP published ending
finally in IETF RFC 3927. The issue at hand is that there are subtle variations in the requirements
from these different drafts. Ideally, all endpoints would implement the requirements of IETF RFC
3927, providing for interoperability.

However, a most popularly implemented draft – draft-cheshire-ipv4-acd-03.txt – published 9th

December 2002, defines the following options in behavior when resolving conflicts in addresses.
The following text is an excerpt from this draft:

“At any time, if a host receives an ARP packet (request *or* reply) where the 'sender IP address' is
(one of) the host's own IP address(es), but the 'sender hardware address' does not match any of the
host's own interface addresses, then this is a conflicting ARP packet, indicating some other host
also thinks it is validly using this address. To resolve the address conflict, a host shall respond to a
conflicting ARP packet as described in either (a), (b) or (c) below:

a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately cease using the
address, and signal an error to the configuring agent as described above, or
b) If a host currently has active TCP connections or other reasons to prefer to keep the same IP
address, and it has not seen any other conflicting ARP packets recently (for Ethernet, within the
last ten seconds) then it MAY elect to attempt to defend its address. To defend its address, the
host first records the time that the conflicting ARP packet was received, and then broadcasts
one single ARP announcement, giving its own IP and hardware addresses. Having done this,
the host can then continue to use the address normally without any further special action.
However, if this is not the first conflicting ARP packet the host has seen, and the time recorded
for the previous conflicting ARP packet is recent (within ten seconds for Ethernet) then the host
SHALL immediately cease using this address and signal an error to the configuring agent as
described above. This is necessary to ensure that two hosts do not get stuck in an endless loop
with both hosts trying to defend the same address.
c) If a host has been configured such that it should not give up its address under any
circumstances (perhaps because it is the kind of device that needs to have a well-known stable
IP address, such as a link's default router, or a DNS server) then it MAY elect to defend its
address indefinitely. If such a host receives a conflicting ARP packet, then it should take
appropriate steps to log useful information such as source Ethernet address from the ARP
packet, and inform an administrator of the problem. The number of such notifications should be
appropriately controlled to prevent an excessive number of error reports being generated. If the
host has not seen any other conflicting ARP packets recently (for Ethernet, within the last ten
seconds) then it SHALL record the time that the conflicting ARP packet was received, and then
broadcast one single ARP announcement, giving its own IP and hardware addresses. Having
done this, the host can then continue to use the address normally without any further special
action. However, if this is not the first conflicting ARP packet the host has seen, and the time
recorded for the previous conflicting ARP packet is recent (within ten seconds for Ethernet) then
the host SHALL NOT send another defensive ARP announcement. This is necessary to ensure
that two misconfigured hosts do not get stuck in an endless loop flooding the network with
broadcast traffic while they both try to defend the same address.”

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 752 –

Annex H
(informative)

Wi-Fi Direct for DLNA

H.1 Wi-Fi Direct introduction
H.1.1 Overview
WFA started certifying Wi-Fi CERTIFIED™ 7 Wi-Fi Direct devices in 2010. Previous to Wi-Fi Direct,
the focus of Wi-Fi, as it relates to DLNA, was a wireless home networking technology. With
traditional Wi-Fi, an Access Point (AP) was required to allow communication within a home network.
Wi-Fi Direct is different in that devices communicate directly amongst each other over Wi-Fi without
an AP. Wi-Fi Direct is a device-to-device communication technology. Removing the dependency on
the AP allows device-to-device communication for sharing, showing and synchronizing in any
location, with or without an AP.

Wi-Fi Direct is an extension to the Wi-Fi transport or link layer technology from a DLNA perspective.
TCP/IP Networking operates over Wi-Fi Direct in the same manner as traditional Wi-Fi. Wi-Fi Direct
Certification requires each Wi-Fi Direct device to support Wi-Fi Simple Config™ enrollee and
Internal Registrar functionality, and also requires a DHCP server and DHCP client in order to
provide devices with a proper IP address.

H.1.2 Terminology
According to the WFA Wi-Fi Direct Certification, a P2P device is capable of two roles.

• P2P Group Owner (GO) role: An “AP-like” capability that controls a Wi-Fi P2P Group and
enables P2P Device connectivity.
• P2P Client role: A Wi-Fi P2P-compliant device that can connect to a P2P Group Owner.
Once created, a P2P Group (see Figure H.1) can be comprised of both P2P devices and legacy
devices. A legacy device can only be a client within a P2P Group. The created P2P Group can be
classified as temporary (single-session) or persistent (multiple sessions) for which credentials are
retained for subsequent sessions’ establishment.

P2P Group Owners can support optional features such as:

• providing intra-BSS distribution enabling communication between members of the group;

• supporting simultaneous (concurrent) connection with an infrastructure network and
cross-connection to provide P2P Clients access to a simultaneous infrastructure connection.

___________

7 Wi-Fi CERTIFIED is a registered trademark of the Wi-Fi Alliance.

This information is given for the convenience of users of this standard and does not constitute an
endorsement by IEC of the product named. Equivalent products may be used if they can be shown
to lead to the same results.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 753 –

Figure H.1 – P2P Group

A P2P Group is uniquely identified by a P2P Group ID, composed of the P2P Device address of the
GO, and an SSID that begins with the ASCII characters “DIRECT-“.

H.1.3 Group formation

Figure H.2 illustrates the procedures by which two P2P devices form a new P2P Group.

The scan phase performed on all channels supported by the P2P device serves two main purposes:

• discover P2P Devices that are currently member of an operational P2P Group;
• collect information about surrounding networks, and identify best potential operating channel(s)
for establishing a new P2P Group.
Scan

Find

Service
P2P Device Found Discovery

Group Owner
Negotiation

Provisioning

Group
Operational

Figure H.2 – Group formation simplified diagram

The Find phase is used for two searching P2P devices to find each other in view of (re-)establishing
a P2P Group using the listen channel of one of the devices for initial signalling. During the Find
phase, a searching P2P device alternates between search and listen state (see Figure H.3).

• In the Search state, the P2P device transmits one or more Probe Request frames on each of the
Social Channels, i.e. channel 1, 6, and 11 in the 2.4 GHz band. The Probe Request contains
both P2P and WSC attributes. To narrow its search, the Probe Request can contain one or more

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 754 –

Requested Device Types or a P2P Device ID. In that case, only devices that match the request
will send a Probe Response.
• In the Listen state, the P2P device tunes to its chosen Listen channel, one among the three
social channels, and responds to received Probe Requests as required. The listen state duration
is randomized to ensure that two searching devices will eventually find each other.
P2P Device 1 P2P Device 2

Discover other Legend

P2P Devices
ch 1
Discover other
scan Scan P2P Devices
ch 6 on all
channels
scan
802.11 Scan ch11

Listen State of
Random duration. 802.11 Scan
listen
ch 1

listen

search
Listen State of
Random duration.
ch 1

Probe Request

Probe Request

ch 6
ch 6

Probe Response
Notify that P2P
Device found
ch11

Probe Request

listen

Figure H.3 – Device discovery procedure

Once a P2P Device has found another P2P Device, it can optionally invoke P2P Service Discovery
to verify that both devices implement compatible services.

During the Group Owner negotiation phase, the two devices use a 3-way handshake to negotiate
which one will take the role of P2P Group Owner based on user preference and/or capabilities,
encoded as GO Intent value (0-15). Group Owner negotiation fails if both devices require to be the
Group Owner (intent value= 15). Other group parameters are also negotiated, such as Group
Operating Channel, Group duration (temporary or persistent), Group credentials, Group
capability…etc.

Group Provisioning takes place after Group Negotiation, all information required to execute
provisioning (e.g., PIN from a label or from the display, etc.) is obtained prior to P2P Group
Formation. The new P2P Group Owner starts the P2P Group session using the credentials
established during Group Owner Negotiation and then allows association by the Wi-Fi Direct device
with which it is in Group Formation.

H.1.4 P2P Group operation

Once a P2P Group has been formed, data is exchanged between the P2P Group Owner and each
connected Client, using WPA2-Personal security with AES-CCMP as the encryption cipher. A P2P
Group Owner can also provide intra-BSS distribution services between P2P Clients in its group.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 755 –

Both devices can employ power savings techniques to address battery-operated devices
requirements.

• A P2P Client uses standard mechanism for indicating that it is using power management and
transiting from doze to awake state, with adapted mechanisms due to GO Power Saving or
unavailability.
• A P2P GO uses Wi-Fi Direct specific mechanisms for power saving or time-sharing other
activities. Such mechanism can be used as long as no legacy stations have joined the group.
Indeed, a legacy device expects the GO to behave just like an AP and, in particular, be always
available. The P2P GO advertises its periods of availability/ unavailability in Beacon. These
periods can be of type “one off” or “periodic” depending on traffic.
P2P Clients can influence the use of P2P Power Save by submitting a P2P Presence Request
when they have specific traffic requirements, such as when transmitting latency-sensitive data.
The duration that communication is unavailable due to power savings is on the order of 10’s of
milliseconds with little impact expected to higher layer protocols and applications.

In addition to arbitrating group access and data communication, the GO also provides client
discovery services, by including device information and available services for each P2P Client
associated to it, in Probe Responses returned to P2P Devices on receiving a Probe Request.

A P2P Group session ends when the GO leaves the group. A persistent Group (consisting of
multiple sessions) ceases to exist when the GO deletes the stored credentials for that group.

H.1.5 Features that are optional in Wi-Fi Direct certification

H.1.5.1 General
Additional procedures and operations are defined to enhance the basic ones, as stated in H.1.5.2 to
H.1.5.7.

H.1.5.2 Service Discovery

This procedure enables the advertisement of services supported by higher layer applications (e.g.
UPnP, Bonjour) to other Wi-Fi Direct devices and prevents two devices from forming a new P2P
group just to discover that they implement incompatible services. Service Discovery can be
performed at any time (e.g. even before a connection is formed) with any other discovered Wi-Fi
Direct device.

H.1.5.3 Persistent Group Re-invocation

One of the advantages of making a P2P Group persistent is that the group can be restarted without
provisioning, thus eliminating the need for user intervention to repeat provisioning, e.g. entering a
PIN. For example, a user can create a persistent group between its mobile phone (DMS) and TV set
(DMR) so that each time it wishes to show/ watch a recorded video or synchronise both music stores,
the P2P Group is restarted. To invoke a Persistent P2P Group, a P2P Client first discovers the P2P
Group Owner, which may then camping for an extended listening period on a listen channel, and
then completes a P2P Invitation exchange with the P2P Group Owner. Alternatively, a P2P Group
Owner can invoke a Persistent P2P Group autonomously at any time (for example, in response to a
request from a higher application layer).

H.1.5.4 Invitation procedure

This procedure allows either a member of a currently operational P2P Group to request another P2P
device to join its group, or a P2P device to re-invoke a persistent group. If a device supports a
persistent group, it also supports the invitation procedure.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 756 –

H.1.5.5 Concurrent operation

This is the capability for a P2P device to “simultaneously” join an infrastructure network and be a
member, i.e. P2P GO or P2P Client, of a P2P Group. An example of a concurrent device is a laptop
participating as a P2P Client and simultaneously using a WLAN connection to access the internet.
Concurrent operation requires support for two distinct MAC entities – one for operation as a
WLAN-STA and one for operating as a Wi-Fi Direct device, and at least two distinct interface
addresses.

H.1.5.6 Intra-BSS distribution (required for DLNA Certification)

In a P2P Group, the GO supports Intra-BSS distribution (bridging) service between all connected
Clients in the P2P Group. Without such feature, communication can only take place on a one-to-one
basis, between the GO and each connected client. If two clients want to communicate, they have to
form another group, possibly leaving the original group unless they support multiple interfaces.
Intra-BSS Distribution within the P2P Group takes place at layer 2.

H.1.5.7 Cross-connection
This is the capability for a concurrent P2P GO to route traffic from the P2P Group to the
infrastructure network, and vice-versa. Cross-connection between a WLAN and a P2P Group uses
mechanisms above layer 2. A P2P Client cannot cross-connect, see Figure H.4.

Figure H.4 – Intra-BSS distribution and Cross-connection

H.2 Wi-Fi Direct with system usages

H.2.1 General
Because Wi-Fi Direct operates just like any other IP-based network, Wi-Fi Direct is a DLNA
network. DLNA 2-box and 3-box system usages work the same over a DLNA Wi-Fi Direct network
and a DLNA Home Network with an AP when devices remain present. However, Wi-Fi Direct has
an ephemeral quality intended to accomplish a specific user task. The user initiates setup of the
Wi-Fi Direct link, performs an action, and then tears down the link. Most of DLNA is designed
around long term network connectivity, which is unlike the temporary design of Wi-Fi Direct. If long
term network connectivity is required, then traditional Wi-Fi communication through an AP is
expected.

H.2.2 and H.2.3 examines how an ephemeral Wi-Fi Direct connection can affect the assumptions
of long term network connectivity within the DLNA 2-box and 3-box system usages. To be more
specific, if a user starts a Wi-Fi Direct task after devices are on a DLNA home network, then
applications assuming the devices are still on the home network might not successfully operate
because IP addresses and IP subnets might change as the Wi-Fi Direct link activates. DLNA
networks today have a similar problem if they are reconfigured by changing cables or installing

DLNA guidelines; Part 1-1: Architecture and protocols

 – 757 –

new networking gear. In both the 2-box and 3-box cases, implementation decisions can be made to
mitigate the problem.

Subclauses H.2.2 and H.2.3 describe specific scenarios of the problems that can occur and
implementation methods to mitigate those problems.

H.2.2 2-box system usage

This subclause examines the 2-box system usage. The Wi-Fi Direct user action in this example is
to connect a camcorder to a video server already on the DLNA home network. The implementation
choices and mitigation methods for the 2-box system usage are illustrated in Figure H.5, Figure H.6,
Figure H.7 and Figure H.8.

Figure H.5 – 2-box system usage: Step 1

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 758 –

Figure H.6 – 2-box system usage: Step 2a

DLNA guidelines; Part 1-1: Architecture and protocols

 – 759 –

Figure H.7 – 2-box system usage: Step 2b.1

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 760 –

Figure H.8 – 2-box system usage: step 2b.2

The video server implementation that allows for multiple network interfaces has no interruption of
service from the DLNA perspective (Step 2a in Figure H.6).

The video server implementation that does not allow for multiple network interfaces can have an
interruption of service between the laptop and video server (Step 2b in Figure H.7 and Figure H.8).
Interruption of service can be mitigated by the video server deciding to disconnect only if the video
server is idle or sending an impending disconnect, and then automatically reconnecting back to the
DLNA Home Network once the camcorder and video server finish synchronization. The video
server implementation has the option to not accept the connection from the camcorder.

H.2.3 3-box system usage

This subclause examines the 3-box system usage. The Wi-Fi Direct user action in this example is
to connect a camcorder to a video server already on the DLNA home network acting as a DMS.
The implementation choices and mitigation methods for the 3-box system usage are illustrated in
Steps 2a and Steps 2b in Figure H.9, Figure H.10, Figure H.11 and Figure H.12.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 761 –

Figure H.9 – 3-box system usage: Step 1

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 762 –

Figure H.10 – 3-box system usage: Step 2a

DLNA guidelines; Part 1-1: Architecture and protocols

 – 763 –

Figure H.11 – 3-box system usage: Step 2b.1

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 764 –

Figure H.12 – 3-box system usage: Step 2b.2

The video server implementation that allows for multiple network interfaces has no interruption of
service from the DLNA perspective (Step 2a in Figure H.10).

The video server implementation that does not allow for multiple network interfaces can have an
interruption of service between the laptop and video server (Step 2b in Figure H.11 and Figure
H.12). Interruption of service can be mitigated by the video server sending an impending
disconnect, and then automatically reconnecting back to the DLNA Home Network once the
camcorder and video server finish synchronization.

DLNA guidelines; Part 1-1: Architecture and protocols

 – 765 –

Annex I
(informative)

EPG Theory of Operation

I.1 Goal
The DLNA EPG device option allows a DMS (UPnP AV Media Server) to provide Electronic Program
Guide data within the home. A Client in the home can access this data to present an Electronic
Program Guide to the user. The client is an EPG Controller (UPnP AV control point) that accesses
the Media Server’s CDS by issuing FreeFormQuery search commands to the server to obtain the
program information. EPG data can be provided for channelized content that is scheduled and
associated with a specific delivery channel such as a tuner. Non Channelized content such as Video
On Demand (VOD) can also be described.

I.2 Usage scenarios

A typical usage scenario of the DLNA EPG device option is a set-top box that acts as a DMS. This
set-top box obtains the EPG data from an external source, and makes it available on the home
network. For example, this set-top box would be connected to a TV in the living room. The EPG is
available on the TV the set-top box is attached to. However, using another DLNA TV with integrated
EPG Controller, the user is able to view the EPG in other rooms as well. Instead of a DLNA TV, a
light-weight set-top box can be used to access the EPG. When the set-top box that provides the
EPG contains storage, it can expose its contents through the DMS (UPnP AV Media Server),
allowing to user to view recorded programs on a client TV. The EPG Extended Tuner enables the
user to watch live content directly from the tuner of the set-top box. Further, if the Scheduled
Recording device option is added to the DMS, and a compatible EPG Controller is available in a
client, the client can provide functionality to the user such as selecting live or recorded content,
viewing the EPG, and scheduling recordings.

Another scenario that is enabled by the EPG device option is the use of an EPG data only server.
The user subscribes to a service which offers more extensive EPG data for a certain set of channels.
The application would retrieve the EPG data offered by such a service and make it available to any
DLNA EPG control point in the home. The advantage is that the clients make use of the DLNA
standard while the EPG service can use a proprietary way of providing the fuller EPG data.

I.3 The model

I.3.1 EPG data
The fundamental mechanism in the DLNA EPG Server device option is to provide a small mandatory
set of properties. The mandatory set allows an EPG control point to render a basic EPG. Today
many services exist that offer a so-called “rich” EPG and these services differ in what type of
metadata they offer to the user. A “rich” EPG service could, for example, provide access to similar
programs, provide options to buy a program, cluster channels, access additional information on the
internet, add advertisements, etc. Since it would be difficult to define new UPnP properties for all
this metadata, the concept of “foreign metadata” is introduced. Using the foreign metadata
approach, any XML based metadata can be added to a CDS object without requiring UPnP CDS
changes (an EPGItem in the case of EPG data).

A DMS (UPnP AV MediaServer) that implements the EPG device option will assign values to the
mandatory properties of EPG elements. The guidelines describe what type of information will be
assigned to each mandatory property. A detailed description for each property is provided for the
following standards: OpenEPG, TV-Anytime, and DVB-SI.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 766 –

For example, consider a DMS implementing the EPG device option that uses an OpenEPG based
EPG description as its source. In this case, the guidelines define which OpenEPG data elements will
be assigned to which CDS properties. If a certain OpenEPG data element is not present, the
guidelines define the information which will be assigned as an alternative. Since the OpenEPG input
format can provide much more information than the small set of mandatory properties, the additional
data can be added to an EPGItem as foreign metadata. A client that is able to parse OpenEPG data
elements can use the OpenEPG based foreign meta-data to provide a richer EPG. A client which
cannot parse the OpenEPG data can still show a basic EPG.

I.3.2 FreeFormQuery
The EPG device option defines how the EPG data is presented as a set of EPGItem objects in the
CDS. Typically, an EPG control point would search the CDS to obtain relevant EPGItems. The
defined mapping of EPG data elements into CDS properties allows the UPnP CDS search action to
have access to the basic EPG information. Access to the additional information stored in foreign
metadata uses FreeFormQuery. The FreeFormQuery search mechanism allows a search to be
specified using the XQuery language. Typically an XQuery would be used to constrain the amount
of EPG data returned to the querier. For example, a query could be constructed which restricts the
EPG data to a limited set of channels and a time window to build an EPG grid screen.

The XQuery Language is a complex language that allows searching (and modifying) any XML based
document. Using a complete XQuery engine, a DLNA EPG Server would need to represent the
EPGItems in the CDS as an XML document, regardless of how the information is actually stored.
The XQuery engine uses this XML document as the source against which the query will be executed.
For a small embedded device it can be preferable to store the EPGItems in a local database. Since
executing an arbitrary XQuery on a database in a compact and efficient way is difficult or impossible,
two levels of XQuery subsets have been defined. The first XQuery subset, which is specified in
10.5.7.5, defines the bare minimum that needs to be implemented in any DLNA EPG Server. This
subset can be used on simple servers and is sufficient for common EPG searches. The second
subset, specified in 10.5.7.6, enables more complex searches while still being able to map an
XQuery to an internal database. The first subset is a subset of the second subset. Using this
approach allows data from an EPG source to be efficiently stored in a local database and each
XQuery is parsed and translated to a local database query. Through the CDS:FreeFormCapabilities
action, a UPnP AV Media Server can indicate which properties it emits in an XQuery. A small list of
mandatory properties is defined in the guidelines. A server can choose to support searching of
foreign metadata properties as well. Using the CDS:FreeFormCapabilities action an EPG control
point can determine, for example, if a server supports an XQuery that returns a list of movies from
a certain director in a certain year using TV-Anytime based foreign-metadata. Likewise, an EPG
control point can determine if a server supports an XQuery that returns a list of genres or other
features that are specified in other foreign-metadata formats.

I.3.3 Channel lineup

To indicate the channels available in an EPG, the DMS exposes a list of channels by implementing
the DLNA Extended Tuner (10.4). The DLNA Extended Tuner defines Channel Lineup Containers,
which are CDS containers that contain a list of channels in the form of videoBroadcast item objects
or audioBroadcast item objects. To determine which channels are available an EPG control point
can search or browse the Channel Lineup Container. Each videoBroadcast item can have a
ChannelName that is used to represent the channel to the user (in contrast, the dc:title property
typically represents the name of the currently available broadcast item). Additionally, each
videoBroadcast or audioBroadcast item will have a upnp:channelID property. The upnp:channelID
property is used as the main mechanism to link EPGItems to Channels. To find EPGItems with a
particular channel name, the EPG Controller first queries the tuner object for the desired channel
name and then uses the resultant upnp:channelID property value to search the EPGItem list.
Searching for all EPGItems with a certain upnp:channelID property value results in a list of all known
programs for the desired channel. Note that a device does not need to have a physical tuner in order
to implement the tuner feature. If no physical tuner is available in the device, or the vendor does not
want to provide direct access to the tuner’s live content from other networked devices, the <res>
DLNA guidelines; Part 1-1: Architecture and protocols
 – 767 –

elements simply do not contain a URL. In this case, the tuner feature merely provides a way to
communicate the channel lineup.

I.3.4 Channel ordering

The preferred method for determining the order of the channels is to use the ordering of the
videoBroadcast items (or audioBroadcast items) in the Channel Lineup Container. When a physical
tuner is exposed through the CDS, each videoBroadcast item will contain a <res> element. Reading
from the URL will produce the video stream corresponding to the selected channel. When the user
presses the channel up button on the remote control, the control point uses the next item in the
Channel Lineup Container.

To distinguish between the cases described above the upnp:channelID property has a @type
attribute. In case of a DVB based system, the value of the channelID@type attribute will be “SI”. The
upnp:channelID property value will contain a DVB triplet consisting of “<Network ID>,<Transport
Stream ID>,<Service ID>”. In other systems where channels are indicated using a major and a minor
number (i.e. used in terrestrial digital broadcast systems), the value of the upnp:channelID@type
property will be “DIGITAL”. The upnp:channelID property will contain the major and minor number
separated by a comma. Finally, in systems where the channel numbering consists of integers only,
the value of the upnp:channelID@type property will be “ANALOG”. The upnp:channelID property
contains the channel number.

I.3.5 channelID@distriNetworkID
The upnp:channelID@distriNetworkID attribute value will contain a value indicating the network
from which a program is distributed and allows channels to be queried by the distribution source.
Note that the upnp:channelID@distriNetworkID attribute was defined in ISO/IEC 29341-14-12 as an
additional channelID qualifier.

I.3.6 Advanced lineup

Digital broadcast systems have the capability of supporting a number of channels in excess of a
thousand. In such systems, channels are often grouped. This can be accomplished by adding
containers to the DLNA Extended Tuner. Each container will contain a set of channels.

Since the DLNA Extended Tuner is intended to expose a channel lineup through the CDS, rather
than expose a physical tuner, the number of Channel Lineup Containers is not necessarily tied to
the number of physical tuners in a system. For example, a device could have two physical tuners
and expose just one Channel Lineup Container representing a single line up. It is also possible to
have a system with no physical tuner, and one or more different lineups. The latter could be used in
the scenario where a PC based EPG Server offers rich EPG descriptions for other devices.

It is also possible to expose multiple views of the channel lineup of a tuner through the use of
Favorites and Presets Containers. For example, while the Channel Lineup Container contains the
list of all channels, a Favorites or Presets Container would show only the channels which the user
subscribes to. Other Favorites or Presets Containers can also be defined to allow users to compile
a list of favorite channels.

I.4 Implementation considerations

I.4.1 General
To clarify the model above, Clause I.4 explains the implementation aspects from the perspective of
an EPG control point.

I.4.2 Discovering features and capabilities

An EPG control point can invoke the CDS:GetFeatureList action to obtain information on the EPG,
the Tuner(s), foreign-metadata, and FreeFormQuery.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 768 –

I.4.3 Discovering EPG Servers

An EPG control point can discover EPG Servers, by invoking the CDS:GetFeatureList action on a
particular server. If the DMS implements the EPG device option, the result of the GetFeatureList
action will contain a Feature-element with its name attribute set to “EPG” or
“DLNA.ORG_EPGDataOnly”.

I.4.4 Discovering Tuners

If a UPnP AV Media Server implements the EPG Server device option, then it will also expose at
least one DLNA Extended Tuner. This tuner is used to provide the channel line-up. The tuner
feature-element returned as a result of the CDS:GetFeatureList action will contain one or more
objectIDs. These objectIDs identify the tuner containers.

I.4.5 Determining FreeFormQuery capabilities

Additionally the CDS:GetFeatureList action will indicate on which containers the
CDS:FreeFromQuery is supported. This is indicated through a list of ObjectId elements.

An EPG Server always supports the CDS:FreeFormQuery action for all EPG containers or an
ancestor container of each EPG container.

For each ObjectId listed as part of the FFQ <Feature> element, the extent of support for the XQuery
language is denoted by the level attribute. If the objectID@level attribute is set to “0” this means that
the full XQuery language is supported for this container. If the objectID@level attribute is set to
“DLNA_EPG” this means that only the minimal subset of XQuery is supported. If the objectID@level
attribute is set to “DLNA_EPG_EXPANDED” the extended XQuery subset is supported.

I.4.6 GetFeatureList example

<?xml version="1.0" encoding="UTF-8"?>
<Features
xmlns="urn:schemas-upnp-org:av:avs"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schemas-upnp-org:av:avs
http://www.upnp.org/schemas/av/avs.xsd">
<Feature name=”EPG” version=”1”>
<objectIDs>
xxx,yyy,zzz
</objectIDs>
</Feature>
Feature name=”TUNER” version=”1”>
<objectIDs>
T1
</objectIDs>
</Feature>
<Feature name=”FFQ” version=”1”>
<objectID level =”DLNA_EPG_EXPANDED”>
yyy
</objectID>
<objectID level =”DLNA_EPG_EXPANDED”>
yyy
</objected>
<objected level =”DLNA_EPG”>
zzz
</objectID>
</Feature>
<Feature name="FOREIGN_METADATA" version="1">
<type id=”openepg.org_v1" provider="dish.org"></type>
<type id="tv-anytime.org" provider="tribune.org"></type>

DLNA guidelines; Part 1-1: Architecture and protocols

 – 769 –

</Feature>
</Features>

I.4.7 Determining FreeFormQuery capabilities

To discover which properties can be used in CDS:FreeFromQuery action, a control point invokes
the CDS:GetFreeFormCapabilities action. This action returns a <propertyList> element containing
<propertyName>-elements. The element lists the names of the properties that can be used in the
XQuery. Optionally the CDS:GetFreeFormCapabilities action will return a
<searchOnlyPropertyList> element. This list contains <propertyName> elements that can not be
used in the order-by clause.

I.4.8 Retrieving a channel lineup

To obtain a channel lineup the EPG Server control point issues a browse or search starting at the
root Channel Lineup Container. If the server implements the “DLNA_EPG_Expanded” XQuery
subset or the full XQuery language it is possible to search for videoBroadcast items in a Channel
Lineup Container. If the CDS:GetFreeFormCapabilities action indicates that it supports the use the
ChannelID property and the channelID@distriNetworkID property in the XQuery, the following
example shows a way to obtain the first 10 channels. (In a system that makes use of DVB, the “order
by” clause could list the channelNr for sorting.)

FreeFromQuery (xquery, channel lineup container id)

<DIDL-Lite
xmlns=“urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/”
xmlns:upnp=“urn:schemas-upnp-org:metadata-1-0/upnp/”
xmlns:dc=“http://purl.org/dc/elements/1.1/”>
{
(
for $x in DIDL-Lite//item[fn:starts-with(upnp:class,
“object.item.VideoBroadcast”) and fn:not(fn:exists(@refID))]
order by $x/upnp:channelID/@distriNetworkID ascending,
$item/upnp:channelID ascending
return $x
)
[fn:position()= (1 to 10)]
}
</DIDL-Lite>

If the DLNA_EPG query subset is supported, it is not possible to search for video broadcast items.
In that case, the EPG Server control point can revert to the CDS:Browse action to obtain the channel
lineup.

I.4.9 Obtaining an EPG grid

(These are examples of EPG_EXPANDED queries)

Searches on EPG data should pass an ObjectID (see 10.5.2) to restrict the search to the EPG tree
only.

Retreiving EpgItem(s) constrained to specific range of channels and times:

<DIDL-Lite
xmlns=“urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/”
xmlns:upnp=“urn:schemas-upnp-org:metadata-1-0/upnp/”
xmlns:dc=“http://purl.org/dc/elements/1.1/”>
{
(

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 770 –

for $item in DIDL-Lite//item[fn:starts-with(upnp:class, “object.item.epgItem”) and

fn:not(fn:exists(@refID))]
where $item/upnp:scheduledStartTime >= “2008-08-10T14:30:00” and
$item/upnp:scheduledEndTime < “2008-08-10T13:00:00” and
$item/upnp:channelID/@distriNetworkID = “example-tv“ and
($item/upnp:channelID = “201“ OR $item/upnp:channelID = “202“
OR $item/upnp:channelID = “203“)
order by $item/upnp:scheduledStartTime ascending
return <item>{$item/@id, $item/dc:title, $item/scheduledStartTime,
$item/scheduledEndTime }</item>
)
[fn:position()= (1 to 10)]
}
</DIDL-Lite>

Retrieving longDescription for 1 EpgItem:

<DIDL-Lite
xmlns=“urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/”
xmlns:upnp=“urn:schemas-upnp-org:metadata-1-0/upnp/”
xmlns:dc=“http://purl.org/dc/elements/1.1/”>
{
(
for $item in DIDL-Lite//item[fn:starts-with(upnp:class, “object.item.epgItem”) and
fn:not(fn:exists(@refID))]
where $item/@id = “current epg item”
return <item>{$item/@id, $item/upnp:longDescription }</item>
)
[fn:position()= (1 to 10)]
}
</DIDL-Lite>

Alternative for retrieving longDescription

<DIDL-Lite
xmlns=“urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/”
xmlns:upnp=“urn:schemas-upnp-org:metadata-1-0/upnp/”
xmlns:dc=“http://purl.org/dc/elements/1.1/”> {
(
for $item in DIDL-Lite//item
where $item/@id = “current epg item”
return <descr>{$item/@id, $item/upnp:longDescription }</descr>
)
}
</DIDL-Lite>

Retreiving EpgItem(s) by Keyword search on all channels: (search for TV programs containing
keyword in title or description in the coming two days)

<DIDL-Lite
xmlns=“urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/”
xmlns:upnp=“urn:schemas-upnp-org:metadata-1-0/upnp/”
xmlns:dc=“http://purl.org/dc/elements/1.1/”>
{
(
for $item in DIDL-Lite//item[fn:starts-with(upnp:class, “object.item.epgItem”) and
fn:not(fn:exists(@refID))]
where $item/upnp:scheduledStartTime >= “2008-08-10T00:00:00” and
$item/upnp:scheduledEndTime < “2008-08-12T00:00:00”
(

DLNA guidelines; Part 1-1: Architecture and protocols

 – 771 –

fn:contains($item/dc:title,”keyword”) or
fn:contains($item/upnp:longDescription,”keyword”) order by $item/upnp:scheduledStartTime
ascending
return <item>{$item/@id, $item/dc:title, $item/upnp:longDescription}</item>
)
[fn:position()= (5 to 10)]
}
</DIDL-Lite>

Retreiving EpgItem(s) by Keyword search on a set of channels:

<DIDL-Lite
xmlns=“urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/”
xmlns:upnp=“urn:schemas-upnp-org:metadata-1-0/upnp/”
xmlns:dc=“http://purl.org/dc/elements/1.1/”>
{
(
for $i in DIDL-Lite//item[fn:starts-with(upnp:class, “object.item.epgItem”) and
fn:not(fn:exists(@refID))]
where $i/upnp:scheduledStartTime >= “2008-08-10T00:00:00” and
$item/upnp:scheduledEndTime < “2008-08-12T00:00:00” and
$i/upnp:channelID/@distriNetworkID = “example-tv“
AND
($i/upnp:channelID = “201“ OR $i/upnp:channelID = “202“ OR $i/upnp:channelID = “203“)
AND fn:contains($i/dc:title,”keyword”) or
fn:contains($i/upnp:longDescription,”keyword”)
order by $i/upnp:scheduledStartTime ascending
return <item>{$i/@id, $i/dc:title, $i/scheduledStartTime,
$i/scheduledEndTime }</item>
)
[fn:position()= (1 to 10)]
}
</DIDL-Lite>

Retreiving EpgItem(s) by current and next program for a channel.

<DIDL-Lite
xmlns=“urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/”
xmlns:upnp=“urn:schemas-upnp-org:metadata-1-0/upnp/”
xmlns:dc=“http://purl.org/dc/elements/1.1/”>
{
(
for $item in DIDL-Lite//item[fn:starts-with(upnp:class, “object.item.epgItem”) and
fn:not(fn:exists(@refID))]
where $item/upnp:scheduledStartTime >= “time 1” and $item/upnp:scheduledEndTime <
“time 2” and
$item/upnp:channelID/@distriNetworkID = “example-tv“ and $item/upnp:channelID =
“201“
order by $item/upnp:scheduledStartTime ascending
return <item>{$item/dc:title, $item/scheduledStartTime,
$item/scheduledEndTime }</item>
)
[fn:position()= (1 to 2)]
}
</DIDL-Lite>

• Time 1 can be the current time

• Time 2 is sufficiently in the future. It cannot be omitted in the EPG subset. (It can be omitted in
EPG_Expanded.)
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 772 –

Annex J
(normative)

Rating systems
This annex lays out all the currently recognized rating systems and their attributes. These are
summarized in Table L.1. The columns labeled “domain”, “valid ratings”, “age equivalence” and
“valid advice” are all normative fields, and their use is prescribed by the guidelines in 10.5.5.6. All
other columns are informative.

The column labeled “rating descriptions” is intended as an informational field, to be interpreted as

follows:

• all audiences – this rating indicates that the media is generally unrestricted and appropriate for
all ages and groups;
• X or over – this rating indicates that the media shall only be viewed by persons over the age of
“X”;
• X or over, supervised – this rating indicates that the media shall only be viewed by persons over
the age of “X”, but may be viewed by persons under the age of “X” with parental or adult
supervision;
• parental guidance – this rating indicates that the media may be viewed by persons of any age,
but parental or adult supervision may be recommended for children;
• exempt – this rating indicates that the media is exempt from classification, as may commonly be
the case for sports media or documentary films;
• banned – this rating indicates that the media has been banned in this country, and is not
appropriate for viewing by persons of any age or group;
• sexual – this item contains themes of a sexual nature;
• graphic – this item contains graphic violence;
• special – this content has a special rating, where special is defined by the local government or
domain;
• children – this rating indicates that the media may be viewed by persons of any age, and is noted
to be especially friendly or informative to young children;
• young adults – this content is appropriate for “young adults”, where the age range for young
adults is not defined;
• professional use – this content is intended for professional use;
• adult – this content is only appropriate for “adults”, where the age range for adults is not defined;
• under X – friendly to all ages, but especially intended for children under the age of X;
• film only – in some domains where ratings apply to both film and TV, this rating only applies to
movies;
• restricted – may only be shown under certain (government specific) restrictions;
• not for public viewing – these films may only be viewed in private residences;
• rating pending – this content has not yet been rated, and is currently under review.
The column labeled “age equivalence” is intended to be used programmatically to limit the viewing
of programs. Note that this field is not guaranteed to be accurate, or reflects local laws where the
EPG is being used or deployed, but is simply meant to be a best effort due to the lack of a global
rating system. This column should be interpreted as follows:

• X – this content should not be viewed by persons under the age of X;

DLNA guidelines; Part 1-1: Architecture and protocols
 – 773 –

• XPG – this content should be freely available to persons that are of the age X or over, and may
be viewed by persons under the age of X with parental or adult supervision;
• X-YPG – this content should not be viewed by persons under the age of X, and may be viewed
freely by persons over the age of Y; persons that are at least X and younger than Y may view the
content with parental or adult supervision;
• <all ages valid> – this domain has age ratings for any integer that is equal to or larger than zero.
Note that due to the way that various countries rate their films, the ratings from one country may not
be transferrable to another country, despite the fact that some countries use common notations for
their rating systems. As a hypothetical example, one country could allow limited nudity and adult
language in a film that is rated for "all audiences", while another country may have an "all
audiences" rating that does not allow for any nudity and language. It would be especially
problematic if the second country banned nudity altogether, and an EPG developer allowed a film
from the first country to be shown to children. The same applies to the age ratings of various
counties, where moral and ethical judgments vary of which age group should be exposed to various
adult themes.

Unfortunately, there is no way of translating from one parental control system to another, so the task
of figuring out which film can be shown to which age group in which country is something that is left
to the judgment of the system implementer.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 Authority / Media Domain Valid Rating Age Valid Advice
Locale Type Ratings Description Equivalence Advice Description
INCAA / Film incaa.gov.ar ATP all audiences 0
Argentina 13 13 or over 13
16 16 or over 16
– 774 –
18 18 or over 18
X explicit
E exempt
ACMA / TV acma.gov.au P pre-school A adult
Australia C children V violence
G all audiences 0 L language
PG parental guidance S sex
M mature H horror
MA15+ 15 or over 15 D drugs
AV15+ 15 or over 15 N nudity
SN supernatural
M medical
W war
B colorful
behavior
Classification Film classification.gov. E exempt
Review Board au G all audiences
/ Australia
PG parental guidance
M mature
MA15 15 or over 15
R18+ 18 or over 18
X18+ 18 or over, sexual 18
RC banned
BMUKK / Film bmukk.gv.at Alters- all audiences 0
Austria stufen
6 6 or over 6
10 10 or over 10
12 12 or over 12
14 14 or over 14
16 16 or over 16
E exempt
Brazil Film mj.gov.br ER children 0
and TV L all audiences 0
10 10 or over 10
12 12 or over 12
14 14 or over 14
16 16 or over 16
18 18 or over 18
E exempt
Canada TV- cbsc.ca/english E exempt
English C children, under 8 0
C8 children, 8 or over 8
G all audiences 0
PG parental guidance
14+ 14 or over 14
18+ 18 or over 18
Canada TV- cbsc.ca/french E exemptées
French G général 0
8 ans+ Général-Décon- 8
seillé aux jeunes
enfants

DLNA guidelines; Part 1-1: Architecture and protocols

 – 775 –

13 ans+ Cette émission 13

peut ne pas
convenir aux
enfants de moins
de 13 ans
16 ans+ Cette émission ne 16
convient pas aux
moins de 16 ans
18 ans+ Cette émission est 18
réservée aux
adultes
Chile TV www.anatel.cl I children
17 children, 7 or over 7
I12 children, 12 or 12
over
F all audiences 0
R adult supervision
A adult 18
Chile Film filmnacional.cl TE all audiences 0 18/S sex
14 14 or over 14 18/V violence
18 18 or over 18
E exempt
Columbia Film mincultura.gov.co T all audiences 0
7 7 or over 7
12 12 or over 12
16 16 or over 16
18 18 or over 18
X sexual
Banned banned
E exempt
Denmark TV .dk_UNOFFICIAL Green all audiences 0 No
Yellow parental guidance governing
body.
Red adult These
terms are
common
usage.
Denmark Film medieraadet.dk A all audiences 0
7 7 or over 7
11 11 or over 11
15 15 or over 15
E exempt
European Games pegi.info 3+ 3 or over 3 Bad
Union / PEGI language
7+ 7 or over 7 Discrimi-
nation
12+ 12 or over 12 Drugs
16+ 16 or over 16 Fear
18+ 18 or over 18 Sex
4+ 4 or over 4 Violence
(Portugal)
6+ 6 or over 6 Gambling
(Portugal)
Finland Film vet.fi K-3 3 or over 3
K-7 7 or over 7

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 776 –

K-11 11 or over 11
K-13 13 or over 13
K-15 15 or over 15
K-18 18 or over 18
K-E exempt
France TV csa.fr -10 10 or over 10
-12 12 or over 12
-16 16 or over 16
-18 18 or over 18
France Film culture.gouv.fr U all audiences 0
-12 12 or over 12
-16 16 or over 16
-18 18 or over 18
-E Exempt
Germany Film spio.de FSK 0 all audiences 0
FSK 6 6 or over 6
FSK 12 12 or over 12
FSK 16 16 or over 16
FSK 18 18 or over 18
Germany Games usk.de ohne all audiences 0
ab 6 6 or over 6
ab 12 12 or over 12
ab 16 16 or over 16
ab 18 18 or over 18
Hong Kong Film tela.gov.hk I all audiences 0
IIA children,
supervised
IIB young adults,
supervised
III 18 or over 18
IV exempt
Iceland Film smais.is L all audiences 0
7 7 or over 7
12 12 or over 12
14 14 or over 14
16 16 or over 16
18 18 or over 18
India Film cbfcindia.tn.nic.in U all audiences 0
U/A 12 or over, 12PG
supervised
A 18 or over 18
S special
Indonesia Film lsf.go.id SU all audiences 0
A children
BO parental guidance
R teen 13
D mature
Ireland TV rte.ie GA all audiences 0
CH children
YA young adults
PS parental guidance

DLNA guidelines; Part 1-1: Architecture and protocols

 – 777 –

MA mature
Ireland Film ifco.ie G all audiences 0
PG parental guidance
12A 12 or over, 12PG
supervised
15A 15 or over, 15PG
supervised
16 16 or over 16
18 18 or over 18
Japan Film eirin.jp G all audiences 0
PG-12 12 or over, 12PG
supervised
R-15 15 or over 15
R-18 18 or over 18
Japan / CERO Games cero.gr.jp A all audiences 0
B 12 or over 12
C 15 or over 15
D 17 or over 17
Z 18 or over 18
Latvia Film nfc.lv V all audiences 0
VP-10 10 or over, 10PG
supervised
VP-12 12 or over, 12PG
supervised
N-12 12 or over 12
N-14 14 or over 14
N-16 16 or over 16
N-18 18 or over 18
Maldives Film nbc.gov.mv G all audiences 0
and TV PG parental guidance
12+ 12 or over 12
15+ 15 or over 15
18+ 18 or over 18
18+R 18 or over, graphic 18
PU professional use
Mexico Film rtc.gob.mx AA children, under 7 0
and TV A all audiences 0
B 12 or over 12
B-15 15 or over, film 15
only
C 18 or over 18

D adult 0
Netherlands Film kijkwijzer.nl AL all audiences 0 Violence
and TV 6 6 or over 6 Scary
Sex
9 9 or over 9
Discrimin
12 12 or over 12 ation
16 16 or over 16 Drugs
Language
New Zealand Film censorship.govt.n E exempt
z G all audiences 0
PG parental guidance

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 778 –

M13 13 or over 0
M mature 0
R13 13 or over 13
R15 15 or over 15
R16 16 or over 16
R18 18 or over 18
RP16 16 or over 16
Nigeria Film nfvcb.gov.ng G all audiences 0
PG parental guidance
12 12 or over 12
12A 12 or over, 12PG
supervised
15 15 or over 15
18 18 or over 18
RE restricted 0
Norway Film medietilsynet.no A all audiences 0
7 7 or over 7
11 11 or over 11
15 15 or over 15
18 18 or over 18
Philippines / TV .ph_MTRCB_TV General all audiences 0
MTRCB Patronage
Parental parental guidance
Guidance
Philippines / Film .ph_MTRCB_FILM G all audiences 0
MTRCB GP all audiences 0
PG-13 13 or over, 13PG
supervised
R 17 or over 17
R-13 13 or over 13
R-18 18 or over 18
X not for public
viewing
Poland TV krrit.gov.pl Green all ages
Circle
Yellow parental guidance
Circle
Red Circle adult
Yellow 7 7 or over 7
Yellow 12 12 or over 12
Yellow 16 16 or over 16
Poland Film .po_ FILM BO all audiences 0
6 6 or over 6
12 12 or over 12
15 15 or over 15
18 18 or over 18
21 21 or over 21
Green all audiences 0
Circle
Yellow 7 7 or over 7
Yellow 12 12 or over 12
Yellow 16 16 or over 16
Red Circle 18 or over 18

DLNA guidelines; Part 1-1: Architecture and protocols

 – 779 –

Portugal Film cce.org.pt M/4 4 or over 4 -Q quality

M/6 6 or over 6
M/12 12 or over 12
M/16 16 or over 16
M/18 18 or over 18
M/18-P 18 or over, sexual 18
Serbia Film rra.org.yu <age> <age> or over <all ages
valid>
Singapore Film mda.gov.sg G all audiences 0
PG parental guidance
NC16 16 or over 16
M18 18 or over 18
R18 18 or over 18
R21 21 or over 21
South Africa TV fpb.gov.za_TV Family all audiences 0 V violence
PG parental guidance N nudity
13 13 or over 13 S sex
15 15 or over 15 L language
18 18 or over 18
R18 adult
South Africa Film fpb.gov.za_FILM A all audiences 0
PG parental guidance
10M 10 or over, 10PG
supervised
10 10 or over 10
13 13 or over 13
16 16 or over 16
R18 18 or over 18
X18 18 or over, sexual 18
Sweden Film statensbiografbyra Btl all audiences 0
.se 7 years 7 or over 7
11 years 11 or over 11
15 years 15 or over 15
Prohibited banned
Taiwan Film gio.gov.tw General all audiences 0
audiences
Protected 6 to 12, supervised 6-12PG
Parental 12 to 18, 12-18PG
guidance supervised
Restricted 18 or over 18
United Film bbfc.co.uk Uc all audiences, 0
Kingdom / and TV children
British Board U all audiences 0
of Film
Classification PG parental guidance 12PG
12A 12 or over, 12
supervised
12 12 or over 15
15 15 or over 18
18 18 or over 18
R18 18 or over, sexual
G adult
United Games elspa.com 3-10 3 or over 3
Copyright © 2016 Digital Living Network Alliance.
Any form of reproduction and/or distribution of these works is prohibited.
 – 780 –

Kingdom / 11-14 11 or over 11

ELSPA
15-17 15 or over 15
18+ 18 or over 18
United States Film mpaa.org G all audiences 0
/ MPAA PG parental guidance 13PG
PG-13 13 or over, 17PG
supervised
R 17 or over, 17
supervised
NC-17 17 or over
NR not rated
United States Film filmadvisoryboard. F all audiences 0
/ Film org PD parental guidance
Advisory
Board PD-M 13 or over 13
EM 17 or over 17
AO 18 or over 18
United States Music riaa.com PAL Parental Advisory
/ RIAA (explicit content)
United States Games esrb.org EC children 0
/ ESRB E all audiences 0
E10+ 10 or over 10
T teen 13
M mature
AO adults only
RP rating pending
Venezuela TV leyresorte.gob.ve A
B
C
D
E sexual

Table L.1 – Rating sytems

DLNA guidelines; Part 1-1: Architecture and protocols

 – 781 –

Annex K
(normative)

3D media rendering guidelines for HDMI signal

K.1 Overview
This Annex provides recommendations for 3D-media-capable Rendering Endpoints or RUI clients
that connect to a 3D-media-capable TV via HDMI interface.

K.2 MPEG-2 3DFC format output mapping

Rendering Endpoints or RUI clients that support MPEG-2 3DFC Media Format Profiles and that are
equipped with an HDMI output should map the 3D format type of the MPEG-2 3DFC video
elementary stream (stored in the S3D_video_format_type information field in picture header user
data (as specified in ANSI/SCTE 187-1) to the HDMI VSIs as specified in HDMI.

Examples of mapping are shown in Table K.1

Table K.1 – Examples of mapping of S3D_video_format_type information to HDMI VSI

S3D_video_format_type Resolution HDMI VSI Values

SbS 0000011 1920 x 1080i60 24 bit IEEE Registration Identifier = 0x000C03
HDMI_Video_Format [3bits] = 010
HDMI_VIC [1byte] = (not present)
3D_Structure [4bits] = 1000
3D_Ext_Data [4bits] = 0000
3D_Meta_present [1bit] = 0
TaB 0000100 1920 x 1080p24 24 bit IEEE Registration Identifier = 0x000C03
HDMI_Video_Format [3bits] = 010
HDMI_VIC [1byte] = (not present)
3D_Structure [4bits] = 0110
3D_Ext_Data [4bits] = (not present)
3D_Meta_present [1bit] = 0
TaB 0000100 1280 x 720p60 24 bit IEEE Registration Identifier = 0x000C03
HDMI_Video_Format [3bits] = 010
HDMI_VIC [1byte] = (not present)
3D_Structure [4bits] = 0110
3D_Ext_Data [4bits] = (not present)
3D_Meta_present [1bit] = 0

K.3 MPEG-4 part 10 3DFC format output mapping

3D-media-capable Rendering Endpoints or 3D-media-capable RUI clients that support MPEG-4
AVC 3DFC Media Format Profiles and that are equipped with an HDMI output should map the 3D
format type of the MPEG-4 AVC video elementary stream (as indicated by the
frame_packing_arrangement_type in SEI message) to the HDMI Vendor-Specific Infoframe (VSI)
as specified in HDMI.

Table K.2 shows examples of mapping of SEI 3D format type information to HDMI VSI values. Note
that correct signalling through use of the HDMI VSI is necessary to ensure that the 3D-capable
display automatically detects the active 3D format.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 782 –

Table K.2 – Examples of mapping of SEI 3D format type information to HDMI VSI

SEI Format Values HDMI VSI Values

SbS (1920 x 1080i60) 24 bit IEEE Registration Identifier = 0x000C03
• frame_packing_arrangement_type = 0000011 (3 decimal) HDMI_Video_Format [3bits] = 010
• quincunx_sampling_flag = 0 HDMI_VIC [1byte] = (not present)
• frame0_grid_position_x: 0100 (4 decimal) 3D_Structure [4bits] = 1000
• frame0_grid_position_y: 1000 (8 decimal) 3D_Ext_Data [4bits] = 0000
• frame1_grid_position_x: 0100 (4 decimal) 3D_Meta_present [1bit] = 0
• frame1_grid_position_y: 1000 (8 decimal)
• frame_packing_arrangement_id: 0
• content_interpretation_type: 000001 (frame 0: L, frame 1: R)
• spatial_flipped_flag: 0
• frame0_flipped_flag: 0
• field_views_flag: 0
• current_frame_is_frame0_flag: 0
• frame0_self_contained_flag: 0
• frame1_self_contained_flag: 0
• frame_packing_arrangement_reserved_byte: 00000000
• frame_packing_arrangement_repetition_period: 1
• frame_packing_arrangement_extension_flag: 0
TaB (1920 x 1080p24) 24 bit IEEE Registration Identifier = 0x000C03
• frame_packing_arrangement_type = 0000100 (4 decimal) HDMI_Video_Format [3bits] = 010
• quincunx_sampling_flag = 0 HDMI_VIC [1byte] = (not present)
• frame0_grid_position_x: 1000 (8 decimal) 3D_Structure [4bits] = 0110
• frame0_grid_position_y: 0100 (4 decimal) 3D_Ext_Data [4bits] = (not present)
• frame1_grid_position_x: 1000 (8 decimal) 3D_Meta_present [1bit] = 0
• frame1_grid_position_y: 0100 (4 decimal)
• frame_packing_arrangement_id: 0
• content_interpretation_type: 000001 (frame 0: L, frame 1: R)
• spatial_flipped_flag: 0
• frame0_flipped_flag: 0
• field_views_flag: 0
• current_frame_is_frame0_flag: 0
• frame0_self_contained_flag: 0
• frame1_self_contained_flag: 0
• frame_packing_arrangement_reserved_byte: 00000000
• frame_packing_arrangement_repetition_period: 1
• frame_packing_arrangement_extension_flag: 0
TaB (1280 x 720p60) 24 bit IEEE Registration Identifier = 0x000C03
• frame_packing_arrangement_type = 0000100 (4 decimal) HDMI_Video_Format [3bits] = 010
• quincunx_sampling_flag = 0 HDMI_VIC [1byte] = (not present)
• frame0_grid_position_x: 1000 (8 decimal) 3D_Structure [4bits] = 0110
• frame0_grid_position_y: 0100 (4 decimal) 3D_Ext_Data [4bits] = (not present)
• frame1_grid_position_x: 1000 (8 decimal) 3D_Meta_present [1bit] = 0
• frame1_grid_position_y: 0100 (4 decimal)
• frame_packing_arrangement_id: 0
• content_interpretation_type: 000001 (frame 0: L, frame 1: R)
• spatial_flipped_flag: 0
• frame0_flipped_flag: 0
• field_views_flag: 0
• current_frame_is_frame0_flag: 0
• frame0_self_contained_flag: 0
• frame1_self_contained_flag: 0
• frame_packing_arrangement_reserved_byte: 00000000
• frame_packing_arrangement_repetition_period: 1
DLNA guidelines; Part 1-1: Architecture and protocols
 – 783 –

• frame_packing_arrangement_extension_flag: 0

K.4 3D-capable renderer HDMI format conversion

If a 3D-meida-capable Rendering Endpoint or a 3D-meida-capable RUI client includes an HDMI
output, but does not support the 3D frame packing ability of HDMI HDMI or is connected to an HDMI
Sink device that does not support input of 3D frame packed video, the Rendering Endpoint or the
RUI client should not perform automated format conversion, frame-rate conversion, stretching or
zooming on any decoded S3D media based on bar-data, Active Format Descriptor (AFD), or any
other content stream identification, even if so directed by Sample Aspect Ratio (SAR)
OC-SP-CEP3.0-I04 ANSI/SCTE 128 values of 1:2 or 2:1. Instead, the device should operate in
pass-through mode unless this operating mode is overridden by some user action.

Note that this does not preclude other post-decode operations such as scaling of the video to fit in
a quarter-screen GUI window. The purpose is to prevent obliteration of the intentional 3D floating
window effects that may be added by the content producer.

K.5 HDMI backward compatible output signalling

When a 3D-media-capable Rendering Endpoint or a 3D-media-capable RUI client is decoding a
S3D media content and is connected to an HDMI sink device that does not report support for any of
the S3D formats identified in 3D A/V Media Format Profiles defined in IEC 62481-2, the following
recommendations should be implemented:

• The Rendering Endpoint or the RUI client should output the S3D content via HDMI if the value of
the diagnostic parameter: DVIHDMI3DIncompatibilityControl is set to passthru3D(1). If any user
message is generated in this condition, it must be displayed in the same panelization
arrangement as the detected S3D content.
• The Rendering Endpoint or the RUI client should block the output of S3D content if the value of
the diagnostic parameter: DVIHDMI3DIncompatibilityControl is set to block3D. If any user
message is generated in this condition, it must be displayed in 2D.
Note that certain DTVs may support S3D formats but are not capable of reporting 3D support in the
Enhanced EDID (E-EDID) where EDID stands for Extended Display Identification Data). These
requirements only apply to user messages generated by the DMR/DMP. The default setting for the
DVIHDMI3DIncompatibilityControl is “block3D” to prevent panelized 3D from showing on 2D
displays, while the ability to change the parameter to “pass-through” is necessary to support certain
legacy 3D displays such as Samsung and Mitsubishi.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 784 –

Annex L
Bibliography
ISO 639-1, Language code

IEEE 1394, High Performance Serial Bus

IETF Draft draft-cheshire-ipv4-acd-03.txt, IPv4 Address Conflict Detection, Stuart Chashire,

December 9, 2002
http://tools.ietf.org/html/draft-cheshire-ipv4-acd-03

IETF RFC 2518, HTTP Extensions for Distributed Authoring – WEBDAV, Februaty 1999
http://www.ietf.org/rfc/rfc2518.txt

Nielsen Norman Group: Response Times: The 3 Important Limits, January 1, 1993
http://www.nngroup.com/articles

Shneiderman, Ben: Designing the User Interface: Strategies for Effective Human-Computer
Interaction
http://www.nngroup.com/articles/

DLNA guidelines; Part 1-1: Architecture and protocols

 – 785 –

Annex M Live content use cases

(Informative)
M.1 Introduction
The term “live content” is defined as a content that is available only up to the “live position” (see
11.4.2.16.2 for more information), such that the Content Receiver is not able to seek the content
beyond the “live position”. Live content is streamed to a Content Receiver at a pace that normally
matches the pace required for a Rendering Endpoint to present the content.

Traditionally live content is closely tied with broadcast content so is very often linked to a tuner as
the Content Source. Guideline in 10.1.4.16.1 identifies the set of guidelines for Basic and Extended
Tuner Representation. However, the source of live content is no longer limited to a local tuner. For
example, IPTV delivery of broadcast content does not require use of a tuner.

This Annex is to provide a consistent and explicit association between implementations of live
content delivery and DLNA guidelines for protocolInfo. This association is to help avoid confusion in
implementing DLNA guidelines for live content support as well as to help avoid running into
interoperability issues between the servers and the clients.

M.2 Live content use cases

This section describes three live content use cases that are commonly implemented by Service
Providers. These three use cases are associated with different Random Access Data Availability
models.

M.2.1 Streaming from time shift buffer (TSB)

In a typical live content use case, upon receiving a client’s request for live content, an in home
server streams the live content from an external content source. (e.g. cable or satellite tuner). The
live content, upon delivery, can be stored for a finite amount of time on the server for the clients to
perform trick modes. The server with this feature, namely, “time shift buffer” (TSB) or “circular
buffer”, normally allocates a local storage space of a fixed size to store the live content and
eventually overwrites the buffer after some duration, typically, the length of the current program or
movie. In this case, the server needs to support the Limited Random Access Data Availability model
Mode 0 for the content binary.

Various implementations exist for the TSB feature. Two common implementations exhibit different
behaviours in terms of updating seek-able time or byte range. One implementation increases the
starting data boundary s0 periodically while the other implementation updates the starting data
boundary s0 when the playback point enters the next event/program. In the latter case, s0 is fixed
for a period of time such as the duration of the current event or program, and then jumps to the
starting point of the next event.

Both of these implementations need to be considered as legitimate scenarios for supporting the
Limited Random Access Data Availability Mode 0 defined in DLNA guidelines.

Specifically, one of the characteristics of the Limited Random Access Data Availability model under
mode 0, as defined in 11.4.2.16.2, is:

“The s0 data boundary shall map to a beginning that shall change with time”

Both of these implementations, i.e., s0 data boundary increases continuously and s0 increases
stepwise with time, is consistent with this characteristic.

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 786 –

M.2.2 Streaming from in-progress recording

The live content can also be stored or recorded for future playback while being streamed to the
clients. This server feature, namely, “in-progress recording”, allocates a persistent storage space to
store the content, therefore will support the Full Random Access Data Availability model as defined
in clause 11.4.2.15. The in-progress recording content is in transition to a complete recording.

M.2.3 Live streaming

The “live streaming” use case refers to live content delivery using a buffer that is only large enough
for the server to package the received content into HTTP/TCP segments for streaming to clients.
This type of implementation does not support random access or DLNA trick modes.

M.3 Guidelines clarifications

M.3.1 The live position
All of the use cases described above require the s N -increasing flag to be set to “true” and can result
in streaming “from the live position".

For the live streaming or TSB cases, streaming from the live position is initiated in response to a
client HTTP request that is not a random access request (e.g. an HTTP request that omits the
Range and TimeSeekRange.dlna.org header), according to 10.1.3.33.2 and 11.4.2.16.2.

In either the TSB or in-progress recording cases, streaming from the live position can also occur
if/when the client consumes all buffered content returned in response to a request that includes the
live position (according to 11.4.3.19.2 and 11.4.3.20.1). A client can establish the range of the
buffered content by issuing a HTTP HEAD request containing a type-specific random access
request (e.g. "Range: bytes=0-" or "TimeSeekRange.dlna.org: npt=0-"). The server response will
contain the random access range (s 0 -s N ) - with s N indicating the effective live position (described in
11.4.3.23.3 and 11.4.3.20.5).

Figure M.1 illustrates the relationship of the live position to a TSB available data range.

Live content feed

Live streaming Live streaming

buffer (No support for
random access)

Streaming from live position

Content Time Shift Buffer Content to be

discarded (content randomly accessible/seek-able) received

S0 SN ~ live position
S0 increasing SN increasing

Figure M.1 – Live position to a TSB available data range

Note that the diagram uses s 0 and s N to represent r 0 and r N in the Uniform Client Data Availability Model (UCDAM).

M.3.2 Content pacing

At the live position, the client's consumption of the HTTP response body data (the Target Response)
will be limited to the rate at which the content is received and how it's packaged on the server.
Attempts by the client to read data beyond the live point will be blocked via TCP flow control until
additional data is made available. In this state the server is considered the "clock source" since
DLNA guidelines; Part 1-1: Architecture and protocols
 – 787 –

Target Response consumption is being regulated by the server instead of the client's on-demand
processing of the stream (described in 10.1.3.28.1(b)).

For the TSB or in-progress recording cases, the client may "fall behind" the live position due to
network bandwidth disruptions or for pausing via Connection Stalling (described in 11.4.3.43). Once
behind the live position, the client may continue reading the Target Response without any
expectation of data loss since the source data can be returned from the data in the TSB or
in-progress recording.

In the live streaming case, however, the server’s ability to buffer source content is limited. And
if/when the client falls sufficiently behind in its consumption of the Target Response, the server will
have no choice but to drop source data. The server needs to set the sp-flag (the Sender Paced flag)
in this case, indicating to the client that all Target Response data returned is from the live position
and discontinuities will be introduced (in a profile-compliant fashion) if/when the client falls behind
(described in 10.1.3.28.1 and 10.1.3.35.1). A client streaming content with sp-flag set to “true”
should read the content data as quickly as possible to avoid creating discontinuities unnecessarily.
A client still needs to be tolerant of discontinuities, however, since they can be introduced by the
server when the client falls behind due to conditions outside the client’s control (e.g. network
disruptions).

Since the Sender Paced flag expresses the inability for the server to support transfer rates lower
than the source content delivery rate (due to limited buffering resources), the http-stalling (HTTP
Connection Stalling) and tm-b (Background Transfer) flags cannot be set in conjunction with the
Sender Paced flag (described in 10.1.3.38 and 10.1.3.37, respectively).

M.3.3 Server termination for live content transfer

Live content such as a broadcast will most likely not have a known length. Consequently, the
Content-Length header can be omitted in a response to a HTTP HEAD or GET message sent by a
client that includes the live position, for example, an HTTP HEAD message with a URI to the content
and that includes the getContentFeatures.dlna.org header.

A client can make a HTTP HEAD or GET request using HTTP 1.1 and the server could respond with
Chunked Transfer Coding in which case the Content-Length header is not allowed via 11.4.3.13.4.
In this case the server will indicate a size for each chunk during HTTP transfer and terminate the
transfer by sending a chunk of zero size.

Alternatively, the client could send an HTTP HEAD or GET message using HTTP 1.0 in which case
the server cannot respond with Chunked Transfer Coding because it’s not supported by HTTP 1.0.
In this case the server needs to support HTTP 1.0 requests according to 11.4.3.8.1 and close the
HTTP connection when the last byte of the response message has been sent (according to
11.4.3.16.2).

M.4 Association with protocolInfo guidelines

M.4.1 4 th field signalling related to live content
M.4.1.1 to M.4.1.4 summarizes the DLNA defined parameters in the 4 th field that are related to live
content delivery.

M.4.1.1 Full random access flags

Guideline 10.1.3.19.1 defines how the server indicates support for the Full Random Access Data
Availability model.

• The op-param a-val indicates support of the TimeSeekRange.dlna.org HTTP header (see
11.4.3.23) for the context of the protocolInfo under the "Full Random Access Data Availability"
model

Copyright © 2016 Digital Living Network Alliance.

Any form of reproduction and/or distribution of these works is prohibited.
 – 788 –

• The op-param b-val indicates support of the Range HTTP header (see 11.4.3.22) for the context
of the protocolInfo under the "Full Random Access Data Availability" model
• If link protection is supported, as indicated by bit 16, the lp-flag, the flags-param
cleartextbyteseek-full (Bit-15) indicates support for cleartext byte seek on the resources under
the “Full Random Access Data Availability” model.
If the Content Source assigns "0" to both a-val and b-val of the op-param, then the op-param is
omitted from the 4th field as specified in 10.1.3.20.2.

M.4.1.2 Limited random access flags

Guideline 10.1.3.28.1 defines Limited Operation Parameters that are used to indicate the support
for the Limited Random Access Data Availability model.

The limited operation flags, including lop-npt, lop-bytes and lop-cleartextbytes, are part of
flags-param:

• lop-npt (Bit-30 of flags-param) indicates support for TimeSeekRange.dlna.org HTTP header

(see 11.4.3.23) for the context of the protocolInfo under the "Limited Random Access Data
Availability" model
• lop-bytes (Bit-29 of flags-param) indicates support of the Range HTTP header (see 11.4.3.22)
for the context of the protocolInfo under the "Limited Random Access Data Availability" model
• lop-cleartextbytes (Bit-14 of flags-param) indicates support for limited cleartext byte seek on
link-protected resources (with link protection indicated by bit 16 - the lp-flag)
M.4.1.3 s 0 -increasing and s N -increasing
The s0-increasing and sN-increasing flags are used to indicate whether s0 and sN are increasing.
These two flags are part of the flags-param:

• s 0 -increasing – Bit-27 of flags-param

• s N -increasing – Bit-26 of flags-param
M.4.1.4 sp-flag
The sp-flag is used to indicate whether the server will pace the packets for transmission. The sp-flag
is part of the flags-param:

• sp-flag – Bit-31 of flags-param

M.4.2 Values of 4 th field for various live content and DVR use cases
M.4.2.1 to M.4.2.3 describe recommended 4 th field values for the live content use cases. For
comparison, M.4.2.4 describes the values for a completed DVR recording.

M.4.2.1 Content with Time Shift Buffer

• Limited Random Access Data Availability Mode 0
o op-param to be omitted
o flags-param with the lop-npt, lop-bytes, or lop-cleartextbytes set according to the
access modes supported for the buffered content and cleartextbyteseek-full set to
zero
• s 0 -increasing=true; s N -increasing=true
• sp-flag=false
M.4.2.2 In-progress recording content
• Full Random Access Data Availability

DLNA guidelines; Part 1-1: Architecture and protocols

 – 789 –

o op-param to be present with a-val and b-val set according to the access modes
supported for the recorded content
o flags-param with lop-npt, lop-bytes, and lop-cleartextbytes set to zeroes and
cleartextbyteseek-full set if cleartext byte seek is supported for the link-protected
(lp-flag set) recorded content
• s 0 -increasing=false; s N -increasing=true
• sp-flag=false
M.4.2.3 Live streaming content
• No random access
o op-param to be omitted
o flags-param with lop-npt, lop-bytes, lop-cleartextbytes, and cleartextbyteseek-full
bits set to zeroes
• s 0 -increasing=true; s N -increasing=true
• sp-flag=true
M.4.2.4 Complete DVR recording content
• Full Random Access Data Availability
o op-param to be present
o flags-param with lop-npt, lop-bytes and lop-cleartextbytes set to zeroes
• s 0 -increasing=false; s N -increasing=false
• sp-flag=false
• Note: Once completed, instance-length and instance-duration needs to be returned in all
response headers and res@size and res@duration needs to be set.

Copyright © 2016 Digital Living Network Alliance.

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