MediaRenderer:2 Device Template Version 1.01

Transcription

1 MediaRenderer:2 Device Template Version 1.01 For UPnP Version 1.0 Status: Standardized DCP Date: September 30, 2008 Document Version: 1.0 This Standardized DCP has been adopted as a Standardized DCP by the Steering Committee of the UPnP Forum, pursuant to Section 2.1(c)(ii) of the UPnP Forum Membership Agreement. UPnP Forum Members have rights and licenses defined by Section 3 of the UPnP Forum Membership Agreement to use and reproduce the Standardized DCP in UPnP Compliant Devices. All such use is subject to all of the provisions of the UPnP Forum Membership Agreement. THE UPNP FORUM TAKES NO POSITION AS TO WHETHER ANY INTELLECTUAL PROPERTY RIGHTS EXIST IN THE STANDARDIZED DCPS. THE STANDARDIZED DCPS ARE PROVIDED "AS IS" AND "WITH ALL FAULTS". THE UPNP FORUM MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE STANDARDIZED DCPS, INCLUDING BUT NOT LIMITED TO ALL IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OF REASONABLE CARE OR WORKMANLIKE EFFORT, OR RESULTS OR OF LACK OF NEGLIGENCE.

2 MediaRenderer:2 Device Template Version 1.01 Document Version Authors* Alan Presser Gary Langille Gerrie Shults John Ritchie (Co-Chair) Mark Walker Changhyun Kim Sungjoon Ahn Masatomo Hori Matthew Ma Jack Unverferth Wim Bronnenberg Geert Knapen (Co-Chair) Russell Berkoff Irene Shen Norifumi Kikkawa Jonathan Tourzan Company Allegrosoft Echostar HP Intel Intel LG Electronics LG Electronics Matsushita Electric (Panasonic) Matsushita Electric (Panasonic) Microsoft Philips Philips Pioneer Pioneer Yasuhiro Morioka Toshiba *Note: The UPnP Forum in no way guarantees the accuracy or completeness of this author list and in no way implies any rights for or support from those members listed. This list is not the specifications contributor list that is kept on the UPnP Forum s website. Sony Sony

3 MediaRenderer:2 Device Template Version 1.01 Document Version Contents 1 Overview and Scope Introduction Notation Data Types Strings Embedded in Other Strings Extended Backus-Naur Form Derived Data Types Comma Separated Value (CSV) Lists Management of XML Namespaces in Standardized DCPs Namespace Prefix Requirements Namespace Names, Namespace Versioning and Schema Versioning Namespace Usage Examples Vendor-defined Extensions Vendor-defined Action Names Vendor-defined State Variable Names Vendor-defined XML Elements and attributes Vendor-defined Property Names References Device Definitions Device Type Device Model Description of Device Requirements Relationships Between Services Theory of Operation Device Discovery Preparing to Transfer the Content Controlling the Transfer of the Content Controlling How the Content is Rendered XML Device Description Test...26

4 MediaRenderer:2 Device Template Version 1.01 Document Version List of Tables Table 1-1: EBNF Operators...8 Table 1-2: CSV Examples...9 Table 1-3: Namespace Definitions...11 Table 1-4: Schema-related Information...12 Table 1-5: Default Namespaces for the AV Specifications...13 Table 2-6: Device Requirements...21

5 MediaRenderer:2 Device Template Version 1.01 Document Version List of Figures Figure 1: MediaRenderer Functional Diagram...6

6 MediaRenderer:2 Device Template Version 1.01 Document Version Overview and Scope 1.1 Introduction This device specification is compliant with the Universal Plug and Play Device Architecture version 1.0. It defines a device type referred to herein as MediaRenderer. The MediaRenderer specification defines a general-purpose device template that can be used to instantiate any Consumer Electronics (CE) device that is capable of rendering AV content from the home network. It exposes a set of rendering controls in which a control point can control how the specified AV content is rendered. This includes controlling various rendering features such as brightness, contrast, volume, etc. Example instances of a MediaRenderer include traditional devices such as TVs and stereo systems. Some more contemporary examples include digital devices such as MP3 players and Electronic Picture Frames (EPFs). Although most of these examples typically render one specific type of content (for example, a TV typically renders video content), a MediaRenderer is able to support a number of different data formats and transfer protocols. For example, a sophisticated implementation of a TV MediaRenderer could also support MP3 data so that its speakers could be used to play MP3 audio content. The MediaRenderer device specification is very lightweight and is easy to implement on low-resource devices such as an MP3 player. However, it can also be used to expose the high-end capabilities of devices such as a PC. A full-featured MediaRenderer exposes the following capabilities: Control various rendering characteristics Expose the supported transfer protocols and data formats Control the flow of the content (for example, FF, REW, etc), if appropriate depending on the transfer protocol. The MediaRenderer DOES NOT enable control points to: Send AV content to another device Retrieve any type of meta-data associated with the content From Network Content Transfer Subsystem Format Decoder Subsystem Rendering Hardware AVTransport Service (Optional) ConnectionManager Service (Required) RenderingControl Service (Required) MediaRenderer Figure 1: MediaRenderer Functional Diagram The un-shaded blocks represent the UPnP services that are contained by a MediaRenderer. The shaded blocks represent various device-specific modules that the UPnP services might interact with. However, the internal architecture of a MediaRenderer device is vendor specific.

7 MediaRenderer:2 Device Template Version 1.01 Document Version Notation In this document, features are described as Required, Recommended, or Optional as follows: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC 2119]. In addition, the following keywords are used in this specification: PROHIBITED The definition or behavior is prohibited by this specification. Opposite of REQUIRED. CONDITIONALLY REQUIRED The definition or behavior depends on a condition. If the specified condition is met, then the definition or behavior is REQUIRED, otherwise it is PROHIBITED. CONDITIONALLY OPTIONAL The definition or behavior depends on a condition. If the specified condition is met, then the definition or behavior is OPTIONAL, otherwise it is PROHIBITED. These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense. Strings that are to be taken literally are enclosed in double quotes. Words that are emphasized are printed in italic. Keywords that are defined by the UPnP AV Working Committee are printed using the forum character style. Keywords that are defined by the UPnP Device Architecture specification are printed using the arch character style [DEVICE]. A double colon delimiter, ::, signifies a hierarchical parent-child (parent::child) relationship between the two objects separated by the double colon. This delimiter is used in multiple contexts, for example: Service::Action(), Action()::Argument, parentproperty::childproperty Data Types This specification uses data type definitions from two different sources. The UPnP Device Architecture defined data types are used to define state variable and action argument data types [DEVICE]. The XML Schema namespace is used to define property data types [XML SCHEMA-2]. For UPnP Device Architecture defined boolean data types, it is strongly RECOMMENDED to use the value 0 for false, and the value 1 for true. However, when used as input arguments, the values false, no, true, yes may also be encountered and MUST be accepted. Nevertheless, it is strongly RECOMMENDED that all boolean state variables and output arguments be represented as 0 and 1. For XML Schema defined Boolean data types, it is strongly RECOMMENDED to use the value 0 for false, and the value 1 for true. However, when used as input properties, the values false, true may also be encountered and MUST be accepted. Nevertheless, it is strongly RECOMMENDED that all properties be represented as 0 and Strings Embedded in Other Strings Some string variables and arguments described in this document contain substrings that MUST be independently identifiable and extractable for other processing. This requires the definition of appropriate substring delimiters and an escaping mechanism so that these delimiters can also appear as ordinary

8 MediaRenderer:2 Device Template Version 1.01 Document Version characters in the string and/or its independent substrings. This document uses embedded strings in two contexts Comma Separated Value (CSV) lists (see Section 1.3.1, Comma Separated Value (CSV) Lists ) and property values in search criteria strings. Escaping conventions use the backslash character, \ (character code U+005C), as follows: a. Backslash ( \ ) is represented as \\ in both contexts. b. Comma (, ) is 1. represented as \, in individual substring entries in CSV lists 2. not escaped in search strings c. Double quote ( ) is 1. not escaped in CSV lists 2. not escaped in search strings when it appears as the start or end delimiter of a property value 3. represented as \ in search strings when it appears as a character that is part of the property value Extended Backus-Naur Form Extended Backus-Naur Form is used in this document for a formal syntax description of certain constructs. The usage here is according to the reference [EBNF] Typographic conventions for EBNF Non-terminal symbols are unquoted sequences of characters from the set of English upper and lower case letters, the digits 0 through 9, and the hyphen ( - ). Character sequences between 'single quotes' are terminal strings and MUST appear literally in valid strings. Character sequences between (*comment delimiters*) are English language definitions or supplementary explanations of their associated symbols. White space in the EBNF is used to separate elements of the EBNF, not to represent white space in valid strings. White space usage in valid strings is described explicitly in the EBNF. Finally, the EBNF uses the following operators: Table 1-1: Operator EBNF Operators Semantics ::= definition the non-terminal symbol on the left is defined by one or more alternative sequences of terminals and/or non-terminals to its right. alternative separator separates sequences on the right that are independently allowed definitions for the non-terminal on the left. * null repetition means the expression to its left MAY occur zero or more times. + non-null repetition means the expression to its left MUST occur at least once and MAY occur more times. [ ] optional the expression between the brackets is optional. ( ) grouping groups the expressions between the parentheses. - character range represents all characters between the left and right character operands inclusively. 1.3 Derived Data Types This section defines a derived data type that is represented as a string data type with special syntax. This specification uses string data type definitions that originate from two different sources. The UPnP Device Architecture defined string data type is used to define state variable and action argument string data types.

9 MediaRenderer:2 Device Template Version 1.01 Document Version The XML Schema namespace is used to define property xsd:string data types. The following definition applies to both string data types Comma Separated Value (CSV) Lists The UPnP AV services use state variables, action arguments and properties that represent lists or onedimensional arrays of values. The UPnP Device Architecture, Version 1.0 [DEVICE], does not provide for either an array type or a list type, so a list type is defined here. Lists MAY either be homogeneous (all values are the same type) or heterogeneous (values of different types are allowed). Lists MAY also consist of repeated occurrences of homogeneous or heterogeneous subsequences, all of which have the same syntax and semantics (same number of values, same value types and in the same order). The data type of a homogeneous list is string or xsd:string and denoted by CSV (x), where x is the type of the individual values. The data type of a heterogeneous list is also string or xsd:string and denoted by CSV (x, y, z), where x, y and z are the types of the individual values. If the number of values in the heterogeneous list is too large to show each type individually, that variable type is represented as CSV (heterogeneous), and the variable description includes additional information as to the expected sequence of values appearing in the list and their corresponding types. The data type of a repeated subsequence list is string or xsd:string and denoted by CSV ({x, y, z}), where x, y and z are the types of the individual values in the subsequence and the subsequence MAY be repeated zero or more times. A list is represented as a string type (for state variables and action arguments) or xsd:string type (for properties). Commas separate values within a list. Integer values are represented in CSVs with the same syntax as the integer data type specified in [DEVICE] (that is: optional leading sign, optional leading zeroes, numeric US-ASCII) Boolean values are represented in state variable and action argument CSVs as either 0 for false or 1 for true. These values are a subset of the defined boolean data type values specified in [DEVICE]: 0, false, no, 1, true, yes. Boolean values are represented in property CSVs as either 0 for false or 1 for true. These values are a subset of the defined Boolean data type values specified in [XML SCHEMA-2]: 0, false, 1, true. Escaping conventions for the comma and backslash characters are defined in Section 1.2.2, Strings Embedded in Other Strings. White space before, after, or interior to any numeric data type is not allowed. White space before, after, or interior to any other data type is part of the value. Table 1-2: CSV Examples Type refinement of string CSV (string) or CSV (xsd:string) Value +artist,-date Comments List of 2 property sort criteria. CSV (int) or CSV (xsd:integer) CSV (boolean) or CSV (xsd:boolean) 1,-5,006,0,+7 List of 5 integers. 0,1,1,0 List of 4 booleans CSV (string) or CSV (xsd:string) Smith\, Fred,Jones\, Davey List of 2 names, Smith, Fred and Jones, Davey

10 MediaRenderer:2 Device Template Version 1.01 Document Version Type refinement of string CSV (i4,string,ui2) or CSV (xsd:int, xsd:string, xsd:unsignedshort) CSV (i4) or CSV (xsd:int) CSV (string) or CSV (xsd:string) Value Comments , string with leading blanks,0 Note that the second value is string with leading blanks 3, 4 Illegal CSV. White space is not allowed as part of an integer value.,, List of 3 empty string values CSV (heterogeneous) Alice,Marketing,5,Sue,R&D,21,Dave,Finance,7 List of unspecified number of people and associated attributes. Each person is described by 3 elements: a name string, a department string and years-of-service ui2 or a name xsd:string, a department xsd:string and years-of-service xsd:unsignedshort. 1.4 Management of XML Namespaces in Standardized DCPs UPnP specifications make extensive use of XML namespaces. This allows separate DCPs, and even separate components of an individual DCP, to be designed independently and still avoid name collisions when they share XML documents. Every name in an XML document belongs to exactly one namespace. In documents, XML names appear in one of two forms: qualified or unqualified. An unqualified name (or nocolon-name) contains no colon ( : ) characters. An unqualified name belongs to the document s default namespace. A qualified name is two no-colon-names separated by one colon character. The no-colon-name before the colon is the qualified name s namespace prefix, the no-colon-name after the colon is the qualified name s local name (meaning local to the namespace identified by the namespace prefix). Similarly, the unqualified name is a local name in the default namespace. The formal name of a namespace is a URI. The namespace prefix used in an XML document is not the name of the namespace. The namespace name is, or should be, globally unique. It has a single definition that is accessible to anyone who uses the namespace. It has the same meaning anywhere that it is used, both inside and outside XML documents. The namespace prefix, however, in formal XML usage, is defined only in an XML document. It must be locally unique to the document. Any valid XML no-colon-name may be used. And, in formal XML usage, no two XML documents are ever required to use the same namespace prefix to refer to the same namespace. The creation and use of the namespace prefix was standardized by the W3C XML Committee in [XML-NMSP] strictly as a convenient local shorthand replacement for the full URI name of a namespace in individual documents. All AV object properties are represented in XML by element and attribute names, therefore, all property names belong to an XML namespace. For the same reason that namespace prefixes are convenient in XML documents, it is convenient in specification text to refer to namespaces using a namespace prefix. Therefore, this specification declares a standard prefix for all XML namespaces used herein. In addition, this specification expands the scope where these prefixes have meaning, beyond a single XML document, to all of its text, XML examples, and certain string-valued properties. This expansion of scope does not supercede XML rules for usage in documents, it only augments and complements them in important contexts that are out-of-scope for the

11 MediaRenderer:2 Device Template Version 1.01 Document Version XML specifications. For example, action arguments which refer to CDS properties, such as the SearchCriteria argument of the Search() action or the Filter argument of the Browse() action, MUST use the predefined namespace prefixes when referring to CDS properties ( upnp:, dc:, etc). All of the namespaces used in this specification are listed in the Tables Namespace Definitions and Schema-related Information. For each such namespace, Table 1-3, Namespace Definitions gives a brief description of it, its name (a URI) and its defined standard prefix name. Some namespaces included in these tables are not directly used or referenced in this document. They are included for completeness to accommodate those situations where this specification is used in conjunction with other UPnP specifications to construct a complete system of devices and services. For example, since the Scheduled Recording Service depends on and refers to the Content Directory Service, the predefined srs: namespace prefix is included. The individual specifications in such collections all use the same standard prefix. The standard prefixes are also used in Table 1-4, Schema-related Information, to cross-reference additional namespace information. This second table includes each namespace s valid XML document root element(s) (if any), its schema file name, versioning information (to be discussed in more detail below), and a links to the entry in Section 1.4.3, Namespace Usage Examples for its associated schema. The normative definitions for these namespaces are the documents referenced in Table 1-3. The schemas are designed to support these definitions for both human understanding and as test tools. However, limitations of the XML Schema language itself make it difficult for the UPnP-defined schemas to accurately represent all details of the namespace definitions. As a result, the schemas will validate many XML documents that are not valid according to the specifications. The Working Committee expects to continue refining these schemas after specification release to reduce the number of documents that are validated by the schemas while violating the specifications, but the schemas will still be informative, supporting documents. Some schemas might become normative in future versions of the specifications. Table 1-3: Namespace Definitions Standard Namespace Prefix Namespace Name Namespace Description AV Working Committee defined namespaces av urn:schemas-upnp-org:av:av Common data types for use in AV schemas Normative Definition Document Reference [AV-XSD] avs urn:schemas-upnp-org:av:avs Common structures for use in AV schemas [AVS-XSD] avdt urn:schemas-upnp-org:av:avdt Datastructure Template [AVDT] avt-event urn:schemas-upnp-org:metadata-1-0/avt/ Evented LastChange state variable for AVTransport cds-event urn:schemas-upnp-org:av:cds-event Evented LastChange state variable for ContentDirectory [AVT] [CDS] didl-lite urn:schemas-upnp-org:metadata-1-0/didl- Lite/ Structure and metadata for ContentDirectory [CDS] rcs-event urn:schemas-upnp-org:metadata-1-0/rcs/ Evented LastChange state variable for RenderingControl srs urn:schemas-upnp-org:av:srs Metadata and structure for ScheduledRecording srs-event urn:schemas-upnp-org:av:srs-event Evented LastChange state variable for ScheduledRecording [RCS] [SRS] [SRS] upnp urn:schemas-upnp-org:metadata-1-0/upnp/ Metadata for ContentDirectory [CDS]

12 MediaRenderer:2 Device Template Version 1.01 Document Version Standard Namespace Prefix Namespace Name Namespace Description Externally defined namespaces Normative Definition Document Reference dc Dublin Core [DC-TERMS] xsd XML Schema Language 1.0 [XML SCHEMA-1] [XML SCHEMA-2] xsi XML Schema Instance Document schema Sections 2.6 & of [XML SCHEMA-1] xml The xml: Namespace [XML-NS] Table 1-4: Schema-related Information Standard Namespace Prefix av avs avdt avt-event cds-event didl-lite rcs-event srs srs-event Relative URI and File Name 1 Form 1, Form 2, Form3 Valid Root Element(s) Schema Reference av-vn-yyyymmdd.xsd av-vn.xsd av.xsd avs-vn-yyyymmdd.xsd avs-vn.xsd avs.xsd avdt-vn-yyyymmdd.xsd avdt-vn.xsd avdt.xsd avt-event-vn-yyyymmdd.xsd avt-event-vn.xsd avt-event.xsd AV Working Committee Defined Namespaces n/a <Capabilities> <Features> <statevariablevaluepairs> <AVDT> <Event> cds-event-vn-yyyymmdd.xsd <StateEvent> cds-event-vn.xsd cds-event.xsd didl-lite-vn-yyyymmdd.xsd didl-lite-vn.xsd didl-lite.xsd rcs-event-vn-yyyymmdd.xsd rcs-event-vn.xsd rcs-event.xsd srs-vn-yyyymmdd.xsd srs-vn.xsd srs.xsd srs-event-vn-yyyymmdd.xsd srs-event-vn.xsd srs-event.xsd <DIDL-Lite> <Event> <srs> <StateEvent> [AV-XSD] [AVS-XSD] [AVDT] [AVT-EVENT-XSD] [CDS-EVENT-XSD] [DIDL-LITE-XSD] [RCS-EVENT-XSD] [SRS-XSD] [SRS-EVENT-XSD]

13 MediaRenderer:2 Device Template Version 1.01 Document Version Standard Namespace Prefix Relative URI and File Name 1 Form 1, Form 2, Form3 Valid Root Element(s) Schema Reference upnp upnp-vn-yyyymmdd.xsd n/a [UPNP-XSD] upnp-vn.xsd upnp.xsd Externally Defined Namespaces dc Absolute URL: [DC-XSD] xsd n/a <schema> [XMLSCHEMA-XSD] xsi n/a n/a xml n/a [XML-XSD] 1 Absolute URIs are generated by prefixing the relative URIs with " Namespace Prefix Requirements There are many occurrences in this specification of string data types that contain XML names (property names). These XML names in strings will not be processed under namespace-aware conditions. Therefore, all occurrences in instance documents of XML names in strings MUST use the standard namespace prefixes as declared in Table 1-3. In order to properly process the XML documents described herein, control points and devices MUST use namespace-aware XML processors [XML-NMSP] for both reading and writing. As allowed by [XML-NMSP], the namespace prefixes used in an instance document are at the sole discretion of the document creator. Therefore, the declared prefix for a namespace in a document MAY be different from the standard prefix. All devices MUST be able to correctly process any valid XML instance document, even when it uses a non-standard prefix for ordinary XML names. However, it is strongly RECOMMENDED that all devices use these standard prefixes for all instance documents to avoid confusion on the part of both human and machine readers. These standard prefixes are used in all descriptive text and all XML examples in this and related UPnP specifications. Also, each individual specification may assume a default namespace for its descriptive text. In that case, names from that namespace may appear with no prefix. The assumed default namespace, if any, for each UPnP AV specification is given in Table 1-5, Default Namespaces for the AV Specifications. Note: all UPnP AV schemas declare attributes to be unqualified, so namespace prefixes are never used with AV Working Committee defined attribute names. Table 1-5: Default Namespaces for the AV Specifications AV Specification Name AVTransport ConnectionManager ContentDirectory MediaRenderer MediaServer RenderingControl ScheduledRecording Default Namespace Prefix avt-event n/a didl-lite n/a n/a rcs-event srs

14 MediaRenderer:2 Device Template Version 1.01 Document Version Namespace Names, Namespace Versioning and Schema Versioning The UPnP AV service specifications define several data structures (such as state variables and action arguments) whose format is an XML instance document that must comply with one or more specific XML namespaces. Each namespace is uniquely identified by an assigned namespace name. The namespaces that are defined by the AV Working Committee MUST be named by a URN. See Table 1-3, Namespace Definitions for a current list of namespace names. Additionally, each namespace corresponds to an XML schema document that provides a machine-readable representation of the associated namespace to enable automated validation of the XML (state variable or action parameter) instance documents. Within an XML schema and XML instance document, the name of each corresponding namespace appears as the value of an xmlns attribute within the root element. Each xmlns attribute also includes a namespace prefix that is associated with that namespace in order to disambiguate (a.k.a. qualify) element and attribute names that are defined within different namespaces. The schemas that correspond to the listed namespaces are identified by URI values that are listed in the schemalocation attribute also within the root element. (See Section Namespace Usage Examples ) In order to enable both forward and backward compatibility, namespace names are permanently assigned and MUST NOT change even when a new version of a specification changes the definition of a namespace. However, all changes to a namespace definition MUST be backward-compatible. In other words, the updated definition of a namespace MUST NOT invalidate any XML documents that comply with an earlier definition of that same namespace. This means, for example, that a namespace MUST NOT be changed so that a new element or attribute is required. Although namespace names MUST NOT change, namespaces still have version numbers that reflect a specific set of definitional changes. Each time the definition of a namespace is changed, the namespace s version number is incremented by one. Each time a new namespace version is created, a new XML schema document (.xsd) is created and published so that the new namespace definition is represented in a machine-readable form. Since a XML schema document is just a representation of a namespace definition, translation errors can occur. Therefore, it is sometime necessary to re-release a published schema in order to correct typos or other namespace representation errors. In order to easily identify the potential multiplicity of schema releases for the same namespace, the URI of each released schema MUST conform to the following format (called Form 1): Form 1: " schema-root-name "-v" ver "-" yyyymmdd where schema-root-name is the name of the root element of the namespace that this schema represents. ver corresponds to the version number of the namespace that is represented by the schema. yyyymmdd is the year, month and day (in the Gregorian calendar) that this schema was released. Table 1-4, Schema-related Information identifies the URI formats for each of the namespaces that are currently defined by the UPnP AV Working Committee. As an example, the original schema URI for the rcs-event namespace (that was released with the original publication of the UPnP AV service specifications in the year 2002) was When the UPnP AV service specifications were subsequently updated in the year 2006, the URI for the updated version of the rcs-event namespace was However, in 2006, the schema URI for the newly created srs-event namespace was Note the version field for the srs-event schema is v1 since it was first version of that namespace whereas the version field for the rcs-event schema is v2 since it was the second version of that namespace. In addition to the dated schema URIs that are associated with each namespace, each namepace also has a set of undated schema URIs. These undated schema URIs have two distinct formats with slightly different meanings:

15 MediaRenderer:2 Device Template Version 1.01 Document Version Form 2: schema-root-name -v ver where ver is described above. Form 3: schema-root-name Form 2 of the undated schema URI is always linked to the most recent release of the schema that represents the version of the namespace indicated by ver. For example, the undated URI /av/rcs-event-v2.xsd is linked to the most recent schema release of version 2 of the rcs-event namespace. Therefore, on May 31, 2006 ( ), the undated schema URI was linked to the schema that is otherwise known as /av/rcs-event-v xsd. Furthermore, if the schema for version 2 of the rcs-event namespace was ever re-released, for example to fix a typo in the schema, then the same undated schema URI ( /av/rcs-event-v2.xsd ) would automatically be updated to link to the updated version 2 schema for the rcs-event namespace. Form 3 of the undated schema URI is always linked to the most recent release of the schema that represents the highest version of the namespace that has been published. For example, on June 25, 2002 ( ), the undated schema URI /av/rcs-event.xsd was linked to the schema that is otherwise known as /av/rcs-event-v xsd. However, on May 31, 2006 ( ), that same undated schema URI was linked to the schema that is otherwise known as /av/rcs-event-v xsd. When referencing a schema URI within an XML instance document or a referencing XML schema document, the following usage rules apply: All instance documents, whether generated by a service or a control point, MUST use Form 3. All UPnP AV published schemas that reference other UPnP AV schemas MUST also use Form 3. Within an XML instance document, the definition for the schemalocation attribute comes from the XML Schema namespace A single occurrence of the attribute can declare the location of one or more schemas. The schemalocation attribute value consists of a whitespace separated list of values that is interpreted as a namespace name followed by its schema location URL. This pair-sequence is repeated as necessary for the schemas that need to be located for this instance document. In addition to the schema URI naming and usage rules described above, each released schema MUST contain a version attribute in the <schema> root element. Its value MUST correspond to the format: ver - yyyymmdd where ver and yyyymmdd are described above. The version attribute provides self-identification of the namespace version and release date of the schema itself. For example, within the original schema released for the rcs-event namespace ( /rcsevent-v xsd), the <schema> root element contains the following attribute: version=" " Namespace Usage Examples The schemalocation attribute for XML instance documents comes from the XML Schema instance namespace A single occurrence of the attribute can declare the location of one or more schemas. The schemalocation attribute value consists of a whitespace separated list of values: namespace name followed by its schema location URL. This pairsequence is repeated as necessary for the schemas that need to be located for this instance document. Example 1: Sample DIDL-Lite XML Instance Document. Note that the references to the UPnP AV schemas do not contain any version or release date information. In other words, the references follow Form 3 from above. Consequently, this example is valid for all releases of the UPnP AV service specifications. <?xml version="1.0" encoding="utf-8"?> <DIDL-Lite

16 MediaRenderer:2 Device Template Version 1.01 Document Version xmlns:dc=" xmlns="urn:schemas-upnp-org:metadata-1-0/didl-lite/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:xsi=" xsi:schemalocation=" urn:schemas-upnp-org:metadata-1-0/didl-lite/ urn:schemas-upnp-org:metadata-1-0/upnp/ <item id="18" parentid="13" restricted="0">... </item> </DIDL-Lite> 1.5 Vendor-defined Extensions Whenever vendors create additional vendor-defined state variables, actions or properties, their assigned names and XML representation MUST follow the naming conventions and XML rules as specified below Vendor-defined Action Names Vendor-defined action names MUST begin with X_. Additionally, it SHOULD be followed by an ICANN assigned domain name owned by the vendor followed by the underscore character ( _ ). It MUST then be followed by the vendor-assigned action name. The vendor-assigned action name MUST NOT contain a hyphen character ( -, 2D Hex in UTF-8) nor a hash character ( #, 23 Hex in UTF-8). Vendorassigned action names are case sensitive. The first character of the name MUST be a US-ASCII letter ( A - Z, a - z ), US-ASCII digit ( 0-9 ), an underscore ( _ ), or a non-experimental Unicode letter or digit greater than U+007F. Succeeding characters MUST be a US-ASCII letter ( A - Z, a - z ), US- ASCII digit ( 0-9 ), an underscore ( _ ), a period (. ), a Unicode combiningchar, an extender, or a nonexperimental Unicode letter or digit greater than U+007F. The first three letters MUST NOT be XML in any combination of case Vendor-defined State Variable Names Vendor-defined state variable names MUST begin with X_. Additionally, it SHOULD be followed by an ICANN assigned domain name owned by the vendor, followed by the underscore character ( _ ). It MUST then be followed by the vendor-assigned state variable name. The vendor-assigned state variable name MUST NOT contain a hyphen character ( -, 2D Hex in UTF-8). Vendor-assigned action names are case sensitive. The first character of the name MUST be a US-ASCII letter ( A - Z, a - z ), US-ASCII digit ( 0-9 ), an underscore ( _ ), or a non-experimental Unicode letter or digit greater than U+007F. Succeeding characters MUST be a US-ASCII letter ( A - Z, a - z ), US-ASCII digit ( 0-9 ), an underscore ( _ ), a period (. ), a Unicode combiningchar, an extender, or a non-experimental Unicode letter or digit greater than U+007F. The first three letters MUST NOT be XML in any combination of case Vendor-defined XML Elements and attributes UPnP vendors MAY add non-standard elements and attributes to a UPnP standard XML document, such as a device or service description. Each addition MUST be scoped by a vendor-owned XML namespace. Arbitrary XML MUST be enclosed in an element that begins with X_, and this element MUST be a sub element of a standard complex type. Non-standard attributes MAY be added to standard elements provided these attributes are scoped by a vendor-owned XML namespace and begin with X_.

17 MediaRenderer:2 Device Template Version 1.01 Document Version Vendor-defined Property Names UPnP vendors MAY add non-standard properties to the ContentDirectory service. Each property addition MUST be scoped by a vendor-owned namespace. The vendor-assigned property name MUST NOT contain a hyphen character ( -, 2D Hex in UTF-8). Vendor-assigned property names are case sensitive. The first character of the name MUST be a US-ASCII letter ( A - Z, a - z ), US-ASCII digit ( 0-9 ), an underscore ( _ ), or a non-experimental Unicode letter or digit greater than U+007F. Succeeding characters MUST be a US-ASCII letter ( A - Z, a - z ), US-ASCII digit ( 0-9 ), an underscore ( _ ), a period (. ), a Unicode combiningchar, an extender, or a non-experimental Unicode letter or digit greater than U+007F. The first three letters MUST NOT be XML in any combination of case. 1.6 References This section lists the normative references used in the UPnP AV specifications and includes the tag inside square brackets that is used for each such reference: [AVARCH] AVArchitecture:1, UPnP Forum, September 30, Available at: Latest version available at: [AVDT] AV DataStructure Template:1, UPnP Forum, September 30, Available at: Latest version available at: [AVDT-XSD] XML Schema for UPnP AV Datastructure Template:1, UPnP Forum, September 30, Available at: Latest version available at: [AV-XSD] XML Schema for UPnP AV Common XML Data Types, UPnP Forum, September 30, Available at: Latest version available at: [AVS-XSD] XML Schema for UPnP AV Common XML Structures, UPnP Forum, September 30, Available at: Latest version available at: [AVT] AVTransport:2, UPnP Forum, September 30, Available at: Latest version available at: [AVT-EVENT-XSD] XML Schema for AVTransport:2 LastChange Eventing, UPnP Forum, September 30, Available at: Latest version available at: [CDS] ContentDirectory:3, UPnP Forum, September 30, Available at: Latest version available at: [CDS-EVENT-XSD] XML Schema for ContentDirectory:3 LastChange Eventing, UPnP Forum, September 30, Available at: Latest version available at: [CM] ConnectionManager:2, UPnP Forum, September 30, Available at: Latest version available at: [DC-XSD] XML Schema for UPnP AV Dublin Core. Available at:

18 MediaRenderer:2 Device Template Version 1.01 Document Version [DC-TERMS] DCMI term declarations represented in XML schema language. Available at: [DEVICE] UPnP Device Architecture, version 1.0, UPnP Forum, July 20, Available at: Latest version available at: [DIDL] ISO/IEC CD :2001, Information Technology - Multimedia Framework - Part 2: Digital Item Declaration, July [DIDL-LITE-XSD] XML Schema for ContentDirectory:3 Structure and Metadata (DIDL-Lite), UPnP Forum, September 30, Available at: Latest version available at: [EBNF] ISO/IEC 14977, Information technology - Syntactic metalanguage - Extended BNF, December [HTTP/1.1] HyperText Transport Protocol HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June Available at: IEC 61883] IEC Consumer Audio/Video Equipment Digital Interface - Part 1 to 5. Available at: [IEC-PAS 61883] IEC-PAS Consumer Audio/Video Equipment Digital Interface - Part 6. Available at: [ISO 8601] Data elements and interchange formats Information interchange -- Representation of dates and times, International Standards Organization, December 21, Available at: ISO 8601:2000. [MIME] IETF RFC 1341, MIME (Multipurpose Internet Mail Extensions), N. Borenstein, N. Freed, June Available at: [MR] MediaRenderer:2, UPnP Forum, September 30, Available at: Latest version available at: [MS] MediaServer:3, UPnP Forum, September 30, Available at: Latest version available at: [RCS] RenderingControl:2, UPnP Forum, September 30, Available at: Latest version available at: [RCS-EVENT-XSD] XML Schema for RenderingControl:2 LastChange Eventing, UPnP Forum, September 30, Available at: Latest version available at: [RFC 1738] IETF RFC 1738, Uniform Resource Locators (URL), Tim Berners-Lee, et. Al., December Available at: [RFC 2045] IETF RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part 1:Format of Internet Message Bodies, N. Freed, N. Borenstein, November Available at: [RFC 2119] IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, 1997.

19 MediaRenderer:2 Device Template Version 1.01 Document Version Available at: [RFC 2396] IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, Tim Berners-Lee, et al, Available at: [RFC 3339] IETF RFC 3339, Date and Time on the Internet: Timestamps, G. Klyne, Clearswift Corporation, C. Newman, Sun Microsystems, July Available at: [RTP] IETF RFC 1889, Realtime Transport Protocol (RTP), H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January Available at: [RTSP] IETF RFC 2326, Real Time Streaming Protocol (RTSP), H. Schulzrinne, A. Rao, R. Lanphier, April Available at: [SRS] ScheduledRecording:2, UPnP Forum, September 30, Available at: Latest version available at: [SRS-XSD] XML Schema for ScheduledRecording:2 Metadata and Structure, UPnP Forum, September 30, Available at: Latest version available at: [SRS-EVENT-XSD] XML Schema for ScheduledRecording:2 LastChange Eventing, UPnP Forum, September 30, Available at: Latest version available at: [UAX 15] Unicode Standard Annex #15, Unicode Normalization Forms, version 4.1.0, revision 25, M. Davis, M. Dürst, March 25, Available at: [UNICODE COLLATION] Unicode Technical Standard #10, Unicode Collation Algorithm version 4.1.0, M. Davis, K. Whistler, May 5, Available at: [UPNP-XSD] XML Schema for ContentDirectory:3 Metadata, UPnP Forum, September 30, Available at: Latest version available at: [UTS 10] Unicode Technical Standard #10, Unicode Collation Algorithm, version 4.1.0, revision 14, M. Davis, K. Whistler, May 5, Available at: [UTS 35] Unicode Technical Standard #35, Locale Data Markup Language, version 1.3R1, revision 5,.M. Davis, June 2, Available at: [XML] Extensible Markup Language (XML) 1.0 (Third Edition), François Yergeau, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, eds., W3C Recommendation, February 4, Available at: [XML-NS] The xml: Namespace, November 3, Available at: [XML-XSD] XML Schema for the xml: Namespace. Available at:

20 MediaRenderer:2 Device Template Version 1.01 Document Version [XML-NMSP] Namespaces in XML, Tim Bray, Dave Hollander, Andrew Layman, eds., W3C Recommendation, January 14, Available at: [XML SCHEMA-1] XML Schema Part 1: Structures, Second Edition, Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, W3C Recommendation, 28 October Available at: [XML SCHEMA-2] XML Schema Part 2: Data Types, Second Edition, Paul V. Biron, Ashok Malhotra, W3C Recommendation, 28 October Available at: [XMLSCHEMA-XSD] XML Schema for XML Schema. Available at: [XPATH20] XML Path Language (XPath) 2.0. Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernandez, Michael Kay, Jonathan Robie, Jerome Simeon. W3C Recommendation, 21 November Available at: [XQUERY10] XQuery 1.0 An XML Query Language. W3C Recommendation, 23 January Available at:

21 MediaRenderer:2 Device Template Version 1.01 Document Version Device Definitions 2.1 Device Type The following device type identifies a device that is compliant with this specification: urn:schemas-upnp-org:device:mediarenderer:2 The shorthand MediaRenderer is used herein to refer to this device type. 2.2 Device Model MediaRenderer products MUST implement minimum version numbers of all REQUIRED embedded devices and services specified in the table below. A MediaRenderer device can be either a Root device or can be Embedded in another UPnP device (MediaRenderer or other). A MediaRenderer device (Root or Embedded) can in turn contain other standard or non-standard Embedded UPnP devices. Table 2-6: Device Requirements DeviceType Root R/O 1 ServiceType R/O Service ID 2 MediaRenderer:2 Root or Embedded R RenderingControl:2 R RenderingControl ConnectionManager:2 R ConnectionManager AVTransport:2 O AVTransport Standard non-av services defined by UPnP (QoS, Security, etc.) go here. Non-standard services embedded by a UPnP vendor go here. X X TBD TBD Standard devices embedded by a UPnP vendor go here. Non-standard devices embedded by a UPnP vendor go here. Embedded O Services as defined by the corresponding standard UPnP Device Definition go here. Embedded X TBD TBD TBD 1 R = REQUIRED, O = OPTIONAL, X = Non-standard. 2 Prefixed by urn:upnp-org:serviceid: Description of Device Requirements Any instance of a MediaRenderer MUST have a RenderingControl service and a ConnectionManager service. For a given instance (MediaRenderer), there MUST only be one instance of these standard defined services. There MAY be one instance of a standard AVTransport service. The semantics of additional AV services are not defined. Other standard services, such as UPnP QoS, MAY be added with semantics defined by the relevant specifications.

22 MediaRenderer:2 Device Template Version 1.01 Document Version It should be noted that MediaRenderer:2 implementations MUST respond to all SSDP queries that specify MediaRenderer:1 and must respond to all actions defined by the MediaRenderer:1 specification. The RenderingControl service allows control points to control the various rendering capabilities of the device. The ConnectionManager service is used to enumerate and select a particular transfer protocol and data format to be used for transferring the content. Additionally, the ConnectionManager service also allows control points, such as a home network management application, to discover useful information about the content transfers that the device is actively participating in. Such information could be useful to a Quality of Service capability, which may be defined in the future. The existence of the AVTransport service depends on the transfer protocols that are supported by the device. The ConnectionManager service specification includes a table that identifies which transfer protocols REQUIRE an AVTransport service to be implemented on the MediaRenderer. If an implementation of the MediaRenderer supports any of these transfer protocols, then it MUST implement the AVTransport service. However, no AVTransport service instances will be instantiated until a connection is made using one of those transfer protocols Relationships Between Services The ConnectionManager::PrepareForConnection() action provides the trigger point for creating a new virtual instance of the RenderingControl and AVTransport service (refer to the RenderingControl and AVTransport service specifications for a description of virtual instances of those services). When a new connection is established (one that REQUIRES an AVTransport service on the MediaRenderer, which is determined by the selected transfer protocol), the ConnectionManager::PrepareForConnection() action returns the InstanceID of the RenderingControl and AVTransport services that are bound to that connection. The RenderingControl service virtual instance is used by the control point to control how the content from that connection is rendered. The AVTransport service virtual instance is used by the control point to control the flow (for example, AVTransport::Play(), AVTransport::Seek(), etc.) of the content received via that connection. As described in the RenderingControl and AVTransport service specifications, each virtual instance of these services operates independently from all other virtual instances. 2.3 Theory of Operation MediaRenderer devices are used in conjunction with one or more MediaServer device(s) to allow a control point to render entertainment (AV) content (for example, video, music, images, etc.) that is discovered on a MediaServer device within the home network. In general terms, the process begins with the control point(s) discovering MediaServer and MediaRenderer devices within the home network. After a control point locates the desired content on a MediaServer, the control point needs to identify a common transfer protocol and data format that can be used to transfer the content from the MediaServer to the MediaRenderer. After these transfer parameters have been established, the control point controls the flow of the content (for example, AVTransport::Play(), AVTransport::Pause(), AVTransport::Stop(), AVTransport::Seek(), etc.). (Depending on the selected transfer protocol, these flow control operations are sent either to the MediaServer or the MediaRenderer, but not both). The actual transfer of the content is performed directly by the MediaServer and MediaRenderer. The content transfer happens independently from the control point and does not involve UPnP itself. The control point uses UPnP to setup the transfer of the content, but the transfer is performed using an out-of band transfer protocol Device Discovery Control points can discover MediaRenderer devices using the standard UPnP SSDP-based device discovery mechanism to search for any device that is a member of the MediaRenderer device class including Root devices and/or Embedded devices.