UPnP AV Architecture:1
`
`For UPnPT"ll Version 1.0
`
`Status: Approved Design Document
`Date: June 25, 2002
`Document Version: 1.00
`
`This design document is being made available to UPan Forum Members pursuant to Section 2.1(c)(ii) of
`the UPan Forum Membership Agreement for review and comment by Members to the UPnP“l Forum
`Steering Committee regarding the Steering Committee‘s consideration of the Proposed template as a
`Standardized service. Pursuant to Section 3.1 of the UPan Fomm Membership Agreement. Member has
`limited rights to use or reproduce the Proposed template during the cormnent period and only in
`furtherance of this review and comment. All such use is subject to all of the provisions of the UPnPm
`Forum Membership Agreement.
`
`THE UPNPTM FORUIVI TAKES NO POSITION AS TO WHETHER ANY INTELLECTUAL
`
`PROPERTY RIGHTS EXIST IN THE PROPOSED TEMPLATES, [MPLEMENTA'IIONS OR IN ANY
`ASSOCIATED TEST SUITES. THE DESIGN DOCUMENT IS PROVIDED "AS IS" AND "WITH ALL
`
`FAULTS". THE U'P‘NPTM FORUIVI MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY,
`OR OTHERWISE WITH RESPECT TO THE PROPOSED DESIGN DOCUMENT 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.
`
`© 2000-2002 Contributing Members of the UPan Forum. All rights Reserved.
`
`Microsoft Corporation
`
`Company
`
`Intel Corporation
`
`Author
`
`John Ritchie
`
`Thomas Kuehnel
`
`Page 1 0f 22
`
`LG EXHIBIT 1012
`
`Page 1 of 22
`
`LG EXHIBIT 1012
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`Conte nts
`
`l .
`
`INTRODUCTION .................................................................................................................................3
`
`3. NON—GOALS .........................................................................................................................................3
`
`U
`
`5.1.
`5.1.1.
`5.1.2.
`
`Content Directorv Sem'ice"
`ConnectionManager SenIce
`5.]. 3.
`AVTransportSen ice.
`5.2.
`MEDIARENDERER...
`5.2.1.
`
`RendermgControfSen‘Ice
`5.2.2. ConnectwnManagerSen'zce
`5.2.3.
`AVTransportSenrice
`5.3.
`CONTROLPOINT
`
`wooooboi-wakq'mu:
`
`6.1.
`6.2.
`6.3.
`6.4.
`6.5.
`6.6.
`6.7.
`6.8.
`
`12
`ISOCHRONOUS-PUSH TRANSFER PROIOOOLS (IEC61883IIEEE1394)..........................................
`13
`ASYNCHRONOUS-PUILTRANSPER PRUI‘OCOIS (EG. HTTP GET)
`...16
`NO CM: :PREPAREFORCONNECIIONO ACIION...
`18
`RENDERER COMBODEVICEUSINGISOCHRDNOUS-PUSH (EG."IEEE-1394)
`19
`RENDER COMBO DEVICE USING ASYNCHRDNOUS—PUSH (EG. HTTPGET)
`19
`SERVER COMBO DEVICE USING ASYNCHRONOUS—PUSH (EG. HTTPGET)
`.21
`SERVERCOMBO DEVICE USINGISOCHRONOUS-PUSH (E.G. [BEE—1394)
`SIMPLESI‘ INTERACI'IONMODI-lSUPPORTED
`.22
`
`7. RECORDING ARCHITECTURE..................................................................................................... 22
`
`H N
`
`Copyright © 2002, Contributing Members of the UPIJPTM Forum. All rights Reserved.
`
`Page 2 of 22
`
`Page 2 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`3
`
`1.
`
`Introduction
`
`This document describes the overall UPnP AV Architecture, which forms the foundation for the UPnP AV
`Device and Service templates. The AV Architecture defines the general interaction between UPnP Control
`Points and UPnP AV devices. It is independent of any particular device type, content format, and transfer
`protocol. It supports a variety of devices such as TVs, VCRs, CDfDVD playersfjukeboxes, settop boxes,
`stereos systems, MP3 players, still-image cameras. camcorders, electronic picture frames (EPFs), and the
`PC. The AV Architecture allows devices to support different types of formats for the entertainment
`content (such as MPEG2, MPEG4, JPEG, MP3, Windows Media Architecture (WMA), bitmaps (BMP),
`NTSC, PAL, ATSC, etc.) and multiple types of transfer protocols (such as IEC-61883flEEE—1394, HTI'P
`GET, RTP, HTTP PUTIPOST, TCPflP, etc). The following sections describe the AV Architecture and
`how the various UPnP AV devices and services work together to enable various end-user scenarios.
`
`2. Goals
`
`The UPnP AV Architecture was explicitly defined to meet the following goals:
`
`I
`
`I
`
`I
`
`I
`
`To support arbitrary transfer protocols and content formats.
`
`To enable the AV content to flow directly between devices without any intewention fi'om the
`Control Point.
`
`To enable Control Points to remain independent of any particular transfer protocol and content
`format. This allows Control Points to transparently support new protocols and formats.
`
`Scalability, i.e. support of devices with vely low resources, especially memmy and processing
`power as well as full-featured devices.
`
`3. Non-Goal s
`
`The UPnP AV Architecture does not enable any of the following:
`
`I
`
`Two—way Interactive Communication, such as audio and video conferencing, Internet gaming, etc.
`
`0 Access Control, Content Protection, and Digital Rights Management
`
`I
`
`Synchronized playback to multiple rendering devices.
`
`4. Overview
`
`In most (non-AV) UPnP scenarios, 3 Control Point controls the operation of one or more UPnP devices in
`order to accomplish the desired behavior. Although the Control Point is managing multiple devices, all
`interactions occur in isolation between the Control Point and each device. The Control Point coordinates
`
`the operation of each device to achieve an overall, synchronized, end-user effect. The individual devices
`do not interact directly with each another. All of the coordination between the devices is performed by the
`Control Point and not the devices themselves.
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reselved.
`
`Page 3 of 22
`
`Page 3 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`4
`
`
`
`Control Point
`
`
`
`
`
`
`
`.
`DeVIce 1
`
`
`
`
`
`UPnP Actions
`
`.
`DeVIce 2
`
`
`
`
`
`
`
`Figure 1: Typical UPnP Device Interaction Model
`
`
`
`AV
`
`Control Point
`
`
`
`
`
`
`
`AV
`Device 1
`
`
`
`
`
`-
`UPnP muons
`
`AV
`Device 2
`
`
`
`
`
`(Source)
`(Sink)
`
`
`
` Out-of-Band
`Transfer Protocol
`
`
`Figure 2: UPnP AV Device Interaction Model
`
`Most AV scenarios involve the flow of (entertainment) content (i.e. a movie, song, picture, etc.) from one
`device to another. As shown in Figure 2, an AV Control Point interacts with two or more UPnP devices
`acting as source and sink, respectively. Although the Control Point coordinates and synchronizes the
`behavior of both devices, the devices themselves interact with each other using a non-UPnP (“out-of-
`band”) communication protocol. The Control Point uses UPnP to initialize and configure both devices so
`that the desired content is transferred from one device to the other. However, since the content is
`transferred using an “out-of—ban ” transfer protocol, the Control Point is not directly involved in the actual
`transfer of the content. The Control Point configures the devices as needed, triggers the flow of content,
`then gets out of the way. Thus, after the transfer has begun, the Control Point can be disconnected without
`disrupting the flow of content.
`In other words, the core task (i.e. transferring the content) continues to
`function even without the Control Point present.
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reserved.
`
`Page 4 of 22
`
`Page 4 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`5
`
`As described in the above scenario, three distinct entities are involved: the Control Point, the source of the
`media content (called the “MediaServer”), and the sink for the content (called the “MediaRenderer”).
`Throughout the remainder of the document, all three entities are described as if they were independent
`devices on the network. Although this configuration may be common (i.e. a remote control, a VCR, and a
`TV), the AV Architecture supports arbitrary combinations of these entities within a single physical device.
`For example, a TV can be treated as a rendering device (e.g. a display). However, since most TVs contain
`a built-in tuner, the TV can also act as a server device because it could tune to a particular channel and
`send that content to a MediaRenderer (e.g. its local display or some remote device such as a tuner-less
`display).
`Similarly, many MediaServers andfor MediaRenderers may also include Control Point
`functionality. For example, an MP3 Renderer will likely have some UI controls (e.g. a small display and
`some buttons) that allow the user to control the playback of music.
`
`5.
`
`Playback Architecture
`
`
`
`Control Point
`53$
`m (Ul Application)
`
`
`
`
`
`
`
`
`
`
`Contenflitirectoryr
`RenderingControl
`ConnectionManager
`ConnecfionManager
`
`AVTransport
`AVTransport
`
`lsochronous or Asychronous
`Push or Pull
`
`MediaServer
`
`
`
`MediaRenderer
`
`
`
`Figure 3
`
`The most common task that end-users want to perform is to render (i.e. play) individual items of content on
`a specific rendering device. As shown in,
`
`Figure 3, a content playback scenario involves three distinct UPnP components: a MediaSelver, a
`MediaRenderer, and a UPnP Control Point. These three components (each with a well-defined role) work
`together to accomplish the task. In this scenario, the MediaServer contains (entertainment) content that the
`user wants to render (e.g. display or listen to) on the MediaRenderer. The user interacts with the Control
`Point’s UI to locate and select the desired content on the MediaServer and to select the target
`MediaRenderer.
`
`The MediaSelver contains or has access to a variety of entertainment content, either stored locally or stored
`on an external device that is accessible via the MediaServer. The MediaServer is able to access its content
`
`and transmit it to another device via the network using some type of transfer protocol. The content
`exposed by the MediaServer may include arbitraly types of content including video, audio, andfor still
`images. The content is transmitted over the network using a transfer protocol and data format that is that is
`understood by the MediaSelver and MediaRenderer. MediaServers may support one or multiple transfer
`protocols and data formats for each content item or be able to convert the format of a given content item
`into another formats on the fly. Examples of a MediaServer include a VCR, CDIDVD playerfjukebox,
`camera, camcorder, PC, set-top box, satellite receiver, audio tape player, etc.
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reselved.
`
`Page 5 of 22
`
`Page 5 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`6
`
`The MediaRenderer obtains content from a MediaServer via network. Examples of a MediaRenderer
`include TV. stereo, network-enabled speakers, MP3 players, Electronic Picture Frame (EPF), a music-
`controlled water fountain, etc. The type of content that a MediaRenderer can receive depends on the
`transfer protocols and data fonnats that it supports. Some MediaRenderers may only support one type of
`content (e.g. audio or still images), where as other MediaRenderers may support a wide variety of content
`including video, audio, still images.
`
`The Control Point coordinates and manages the operation of the MediaServer and MediaRenderer as
`directed by the user (e. g. play. stop, pause) in order to accomplish the desired task (e. g. play “MyFavorite”
`music). Additionally. the Control Point provides the UI (if any) for the user to interact with in order to
`control the operation of the device(s) (e. g. to select the desired content). The layout of the Control Point’s
`UI and the functionality that it exposes is implementation depenth and determined solely by the Control
`Point’s manufacturer. Some examples of a Control Point might include a TV with a traditional remote
`control or a wireless PDA-like device with a small display.
`
`Note: The above descriptions talk about devices “sending/receiving content to"from the home network.” In
`the context of the AV Architecture, this includes point-to-point connections such as an RCA cable that is
`used to connect a VCR to a TV. The AV Architecture treats this type of connection as a small part (e.g.
`segment) of the home network. Refer to the ConnectionManager Service Template for more details [?].
`
`As described above, the AV Architecture consists of three distinct components that perform well-defined
`roles. In some cases, these components will exist as separate, individual UPnP devices. However, this
`need not be the case. Device manufacturers are free to combine any of these logical entities into a single
`physical device. In such cases, the individual components of these combo devices may interact with each
`other using either the standard UPnP control protocols (e.g. SOAP over HTTP) or using some private
`communication mechanism. In either case, the flmction of each logical entity remains unchanged.
`However, in the later case, since the communication between the logical entities is private, the individual
`components will not be able to communicate with other UPnP AV devices that do not implement the
`private protocol.
`
`As shown in Figure 3, the Control Point is the only component that initiates UPnP actions. The Control
`Point requests to configure the MediaServer and MediaRenderer so that the desired content flows hour the
`MediaServer to the MediaRenderer (using one of the transfer protocols and data formats that are supported
`by both the MediaServer and MediaRenderer). The MediaServer and MediaRenderer do invoke any UPnP
`actions to the Control Point. However, if needed, the MediaServer andt’or MediaRenderer may send event
`notifications to the Control Point in order to inform the Control Point of a change in the
`MediaServer’sfMediaRenderer’s internal state.
`
`The MediaServer and MediaRenderer do not control each other via UPnP actions. However, in order to
`transfer the content, the MediaServer and MediaRenderer use an “out-of-ban " (e.g. a non-UPnP) transfer
`protocol to directly transmit the content. The Control Point is not involved in the actual transfer of the
`content. It simply configures the MediaServer and MediaRenderer as needed and initiates the transfer of
`the content. Once the transfer begins, the Control Point “gets out of the way” and is no longer needed to
`complete the transfer.
`
`However, if desired by the user, the Control Point is capable of controlling the flow of the content by
`invoking various AVTransport actions such as Stop, Pause, FF, REW, Skip, Scan, etc. Additionally, the
`Control Point is also able to control the various rendering characteristics on the Renderer device such as
`Brightness, Contrast, Volume, Balance, etc.
`
`5.1. Media Server
`
`The MediaServer is used to locate content that is available via the home network. MediaServers include a
`
`wide variety of devices including VCRs, DVD players, satellitefcable receivers, TV tuners, radio tuners,
`CD players, audio tape players, MP3 players, PCs, etc. A MediaServer’s primary purpose is to allow
`
`Copyright © 2002, Contributing Members of the UPan Forum. All rights Reserved.
`
`Page 6 of 22
`
`Page 6 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`7
`
`Control Points to enumerate (i.e. browse or search for) content items that are available for the user to
`render. The MediaServer contains a ContentDirectoryService, a ConnectionManager Service, and an
`optional AVTransport Service (depending on the supported transfer protocols).
`
`Some MediaServers are capable of transferring multiple content items at the same time, e.g. a hard-disk-
`based audio jukebox may be able to simultaneously stream multiple audio files to the network. In order to
`support this type of MediaServer, the ConnectionManager assigns a unique Connection 1]) to each
`“connection” (i.e. each stream) that is made. This ConnectionlD allows a third-party Control Points to
`obtain information about active connections of the MediaServer.
`
`5.1.1. Content Directory Service
`
`This service provides a set of actions that allow the Control Point to enumerate the content that the Server
`can provide to the home network. The primary action of this selvice is Browseo. This action allows
`Control Points to obtain detailed information about each Content Item that the Server can provide. This
`information (i.e. meta-data) includes properties such as its name, artist, date created, size, etc.
`Additionally, the returned meta-data identifies the transfer protocols and data formats that are supported by
`the Server for that particular Content Item. The Control Point uses this information to determine if a g'ven
`MediaRenderer is capable of rendering that content in its available format.
`
`5.1.2. ConnectionManager Service
`
`This service is used to manage the connections associated with a particular device. The primary action of
`this service (within the context of a MediaServer) is PrepareForConnectionO. When implemented, this
`optional action is invoked by the Control Point to give the Server an opportunity to prepare itself for an
`upcoming transfer. Depending on the specified transfer protocol and data format, this action may return
`the InstancelD of an AVTransport service that the Control Point can use to control the flow of this content
`(e.g. Stop, Pause, Seek, etc). As described below, this InstancelD is used to distinguish multiple (virtual)
`instances of the AVTransport service, each of which is associated with a particular connection to Renderer.
`Multiple (virtual) instances of the AVTransport selvice allow the MediaServer to support multiple
`Renderers at the same time. When the Control Point wants to terminate this connection, it should invoke
`the MediaServer’s ConnectionCompleteO action (if implemented) to release the connection.
`
`If the PrepareForConnectionO action is not implemented, the Control Point is only able to support a
`single Renderer at an given time. In this case, the Control Point should use Instance]D=0.
`
`5.1.3. AVTransport Service
`
`This (optional) service is used by the Control Point to control the “playback” of the content that is
`associated with the specified AVTransport. This includes the ability to Stop, Pause, Seek, etc. Depending
`on the supported transfer protocols andfor data formats, a MediaServer may or may not implement this
`service. If supported, the MediaSelver can distinguish between multiple instances of the service by using
`the InstancelD that is included in each AVTransport action. New instances of the AVTransport service
`are created via the ConnectionManager’s PrepareForConnectionO. A new Instance Id is allocated for
`each new Service Instance.
`
`5.2. MediaRenderer
`
`The MediaRenderer is used to render (e.g. display and/or listen to) content obtained from the home
`network. This includes a wide variety of devices including TVs, stereos, speakers, hand-held audio
`players, music controlled water-fountain, etc. Its main feature is that it allows the Control Point to control
`how content is rendered (e.g. Brightness, Contrast, Volume, Mute, etc). Additionally, depending on the
`transfer protocol that is being used to obtain the content from the network, the MediaRenderer may also
`allow the user to control the flow of the content (e.g. Stop, Pause, Seek, etc). The MediaRenderer includes
`
`Copyright © 2002, Contributing Members of the UPan Forum. All rights Reserved.
`
`Page 7 of 22
`
`Page 7 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`8
`
`a Rendering Control Service, a ConnectionManager Service, and an optional AVTransport Service
`(depending on which transfer protocols are supported).
`
`In order to support rendering devices that are capable of handling multiple content items at the same time
`(e.g. an audio mixer such as a Karaoke device), the Rendering Control and AVTransport Sewices contain
`multiple independent (logical) instances of these services. Each (logical) instance of these services is
`bound to a particular incoming connection. This allows the Control Point to control each incoming content
`independently from each other.
`
`Multiple logical instances of these services are distinguished by a unique ‘InstancelD’ which references
`the logical instance. Each action invoked by the Control Point contains the Instance ID that identifies the
`correct instance.
`
`5.2.1. RenderingControlService
`
`This service provides a set of actions that allow the Control Point to control how the Renderer renders a
`piece of incoming content. This includes rendering characteristics such as Brightness, Contrast, Volume,
`Mute, etc. The Rendering Control sewice supports multiple, dynamic instances, which allows a Renderer
`to “mix togethei” one or more content items (e g. a Picture-in—Picture window on a TV or an audio mixer
`device). New instances of the service are created by the ConnectionManager’s PrepareForConnectionO
`action.
`
`5.2.2. ConnectionManagerService
`
`This service is used to manage the connections associated with a device. Within the context of a
`MediaRenderer, the primary action of this sewice is the GetPl‘otocolInfoO action. This action allows a
`Control Point to enumerate the transfer protocols and data formats that are supported by the
`MediaRenderer. This information is used to predetermine if a MediaRenderer is capable of rendering a
`specific content item. A MediaRenderer may also implement the optional PrepareForConnectionO
`action. This action is invoked by the Control Point to give the Render an opportunity to prepare itself for
`an upcoming transfer. Additionally, this action assigns a unique Connectionfl) that can be used by a 3rd-
`party Control Point to obtain information about the connections that the MediaRenderer is using. Also,
`depending on the specified transfer protocol and data format being used, this action may return a unique
`AVTransport InstancelD that the Control Point can use to control the flow of the content (e g. Stop, Pause,
`Seek, etc). (Refer to the AVTransport section below for additional details). Lastly,
`PrepareForConnectionO also returns a unique Rendering Control InstancelD which can be used by the
`Control Point to control the rendering characteristics of the associated content as described above. When
`the Control Point wants to terminate a connection, it should invoke the Renderer’s ConnectionCompleteO
`action (if implemented) to release the connection.
`
`5.2.3. AVTransport Service
`
`This (optional) service is used by the Control Point to control the flow of the associated content. This
`includes the ability to Play, Stop, Pause, Seek, etc. Depending on transfer protocols andJ'or data formats
`that are supported, the Renderer may or may not implement this service. In order to support
`MediaRenderers that can simultaneously handle multiple content items, the AVTransport sewice may
`support multiple logical instances of this service As described above, AVTransport Instancele are
`allocated by the ConnectionManager’s Pl'epareForConnectionO action to distinguish between multiple
`service instances.
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reselved.
`
`Page 8 of 22
`
`Page 8 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`9
`
`5.3. Control Point
`
`Control Points coordinate the operation of the MediaServer and the MediaRenderer, usually in response to
`user interaction with the Control Point’s UT. The following describes a generic Control Point algorithm
`that can be used to interact with a wide variety of MediaServer and MediaRenderer implementations.
`
`l.
`
`Discover AV Devices: Using UPnP‘s Discovery mechanism, MediaServers and MediaRenderers
`in the home network are discovered.
`
`Locate Desired Content: Using the Server’s ContentDirectory::Browse() or SearchO actions, a
`desired Content Item is located. The information returned by BrowseOlSearchO includes the
`transfer protocols and data formats that the MediaSeiver supports to transfer the content to the
`home network.
`
`Get Renderer’s Supported Protocolleormats: Using the MediaRenderer’s
`ConnectionManager: :GetProtocolquoO action a list of transfer protocols and data formats
`supported by the MediaRenderer is returned to the Control Point.
`
`CompareMatch ProtocolsfFormats: The protocolfformat information returned by the
`ContentDirectory for the desired Content Item is matched with the protocolfformat information
`returned by the MediaRenderer’s GetProtocolInfoO action. The Control Point selectsa transfer
`protocol and data format that are supported by both the MediaServer and MediaRenderer.
`
`Configp re ServerlRenderer: The device’s ConnectionManager::PrepareForConnectionO action
`(if implemented) informs the MediaServer and MediaRenderer that an outgoing/incoming
`connection is about to be made using the specified transfer protocol and data format that was
`previously selected. Depending on the selected transfer protocol, either the MediaSeiver or
`MediaRenderer will return an AVTransport InstancelD. This InstancelD is used in conjunction
`with the device’s AVTransport Service (i.e. the device returning the AVTransport InstancelD) to
`control the flow of the content (e.g. Play, Stop, Pause, Seek, etc). Additionally, the Renderer will
`return a Rendering Control InstancelD that is used by the Control Point to control the Rendering
`characteristics of the content.
`
`Note: Since PrepareForConnectionO is an optional action, there may be situations in which either
`the MediaSeiver andfor MediaRenderer do not implement PrepareForConnectionO. When this
`occurs and neither MediaServer nor MediaRenderer return an AVTransport InstancelD, the
`Control Point uses an InstancelD=0 to control the flow of the content. Refer to the
`
`ConnectionManager and AVTransport Service Templates for details [?].
`
`Select Desired Content: Using the AVTransport service (whose InstancelD is returned by either
`the Server or Renderer), invoke the SetAVTransportURIO action to identify the content item that
`needs to be transferred.
`
`Start Content Transfer: Using the AVTransport service, invoke one of the transport control
`actions as desired by the user (e. g. Play, Stop, Seek, etc).
`
`Adjust Rendering Characteristics: Using the MediaRenderer’s Rendering Control service,
`invoke any rendering control actions as desired by the user (e.g. adjust brightness, contrast,
`volume, mute, etc).
`
`Repeat: Select Next Content: Using either the AVTransport: :SetAVTransportURIO or
`AVTransport: : SetNextAVTRansportURIO actions, identify the next content item that is to be
`transferred fi'om the same Selver to the same Renderer. Repeat as needed.
`
`10.
`
`Cleanup ServerfRenderer: When the session is terminated and MediaServer and
`MediaRenderer are no longer needed in the context of the session, the MediaServer’ s and
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reseived.
`
`Page 9 of 22
`
`Page 9 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`10
`
`MediaRenderer’s ConnectionMgr::ConnectionComplete0 action is invoked to close the
`MediaServer’s connection.
`
`Based on the interaction sequence shown above, the following diagram chronologically illustrates the
`typical interaction sequence between the three Control Point and the MediaServer and MediaRenderer.
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reserved.
`
`Page 10 of 22
`
`Page 10 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`11
`
`Playback: General Interaction Diagram
`
`Media
`
`Server
`
`Control
`
`Point
`
`Media
`
`Renderer
`
`ODS::Browse.-'Search
`
`Content Objects
`
`CM::GetProtocollnfo()
`
`
`
`
`ProtocoliFonnat Listl
`
`
`Choose Matching
`
`Protocol and Format
`
`a
`
`
`
`>4
`
`
`CM: :Pre pare ForConnection
`AVT InstancelD
`
`CM : :Pre pare ForConnection()
`
`AVT,RCS Instancele
`
`AVT::SetAVTransportURl()
`
`(will? one>
`I
`/A\/Efly0\
`
`
`
`Any AVT flow control
`operation, as needed
`
`(e.g. stop.pause.seek)
`
`control operation
`(e.g. volume, mute,
`brighlness. contrast)
`
`
`
` Any RCS rendering
`
`Out-Of-Band
`
`Content Transfer
`
`RCS::SetVolume()
`
`Content Transfer
`
`Complete
`
`V! Repeat as Needed
`
`l
`
`‘5.
`
`a
`
`a.
`
`"II.
`
`CMITransferCompleteO
`
`4f
`
`< V
`
`Y
`
`Y
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reserved.
`
`Page 11 of 22
`
`Page 11 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`12
`
`Example Playback Scenarios
`6.
`As described above, the AV Architecture is designed to support arbitrary transfer protocols and data
`formats. However, in some cases, certain devices are intentionally designed to support a single transfer
`protocol andfor data format only. For example, a manufacturer may want to deliver a product that targets a
`paificular price-point andfor market segment. In these cases, some AV devices may combine one or more
`logical entities into a single physical device.
`
`The following sub-sections illustrate the flexibility of the generic Device Interaction Model algorithm.
`Each of the following interaction diagrams are variations of the generic diagram with various steps
`omitted. These omitted steps are not included because the particular scenario does not require them.
`
`6.1.
`
`lsochronous-Push Transfer Protocols (IECB1883 I
`IEEE1394)
`
`When using an isochronous transfer protocol (e.g.IEC61883f IEEE1394), the underlying transfer
`mechanism provides real-time content transfer between the MediaServer and MediaRenderer. This ensures
`that individual packets of content are transferred within a certain (relatively small) period of time. This
`real-time behavior allows the MediaRenderer to provide the user with smooth-flowing rendering of the
`content without implementing a read-ahead buffer. In this environment, the flow of the content is
`controlled by the MediaServer. The MediaRenderer immediately renders the content that it receives from
`the MediaServer. Refer to the diagram below for details.
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reserved.
`
`Page 12 of 22
`
`Page 12 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`13
`
`Media
`
`Same;
`
`Control
`
`Media
`
`Bendecer
`
`CDS::Browser‘Search(
`
`Content Obiects
`
`
`
`Eolnt
`
`
`
`
`
`Choose Matching
`Protocol and Format
`
`
`
`CM ::GetProtocollnfo()
`ProtocollFormat List
`
`CM::PrepareForConnection
`
`AVT InstancelD
`
`AVT::SetAVTransportURl
`
`/'
`
`__
`
`lsochronous—Push
`CM::PrepareForConnection()
`requires Server (not
`Renderer) to return
`RC8 lnstancelD < AVT lnstancelD.
`Renderer only returns
`an RCS InstancelD.
`
`
`
`Any AVT flow control
`
`e.
`
`.seek,sto ,
`
`use
`
`
`
`
`
`
`
`
`
`
`
`/ w/ operation. as needed
`
`
`/ \b
`Out-O -Band
`Content
`ransfer
`RCS::SetVolume()
`
`I
`
`I
`'
`
`\
`
`_
`”‘5' R03 'endenng
`4 oonlrol operation. as
`\ > needed (e.g. volume.
`\
`brighlness, conlrast)
`
`‘\ ”a.
`
`\
`
`a
`
`-
`
`u.
`
`‘Iu.
`
`Content Transfer
`Complete
`
`‘1 Repeat as Needed
`
`l
`
`CM::TransferComplete()
`a
`
`a
`Y
`Y
`
`6.2. Asynchronous-Pull Transfer Protocols (e.g. HTTP GET)
`
`In this example, the transfer protocols that are used do not provide real-time guarantees. The arrival of a
`particular packet of content is unpredictable relative to the previous packets. Unless corrected, this causes
`the content to be rendered with certain undesirable anomalies (e.g. detectable latencies, jitter, etc.). In
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reserved.
`
`Page 13 of 22
`
`Page 13 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`14
`
`order to compensate for these types of transfer mechanisms, at Renderer device typically implements a
`read-ahead storage buffer in which the Renderer reads-ahead of the current output and places the data into
`a buffer until the contents are needed. This allows the MediaRenderer to smooth out any rendering
`anomalies that might otherwise exist. Since the MediaRenderer must control the flow of the content, it is
`obligated to provide the instance of the AVTransport service that will be used.
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reserved.
`
`Page 14 of 22
`
`Page 14 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`15
`
`Media
`
`Server
`
`Control
`
`Point
`
`Media
`
`Renderer
`
`CDSIBrowseISearchO
`
`
`
`
`Content Objects
`
`CM::GetProtocollnfoO
`ProtocollFormat List
`
`
`
`
`
`Choose Matching
`Protocol and Format
`
` i
`
`
`
`
`Asychronous-Pull
`requires Renderer
`
`(not Server) to return
`a AVT lnstaneelD.
`Server does not retum
`
`< Y
`
`Y
`
`CM::PrepareForConnection
`
`
`’
`
`a
`
`I
`
`/
`
`I
`
`Out-
`
`Content
`
` CM::PrepareForConnectionO
`
`aA
`
`VT,RCS lnstancele
`
`AVT::SetAVTransp0|tU RIO
`
`Any AVT flow control
`operation, as needed
`(e.g. seek,stop,pause)
`
`brightness, contrast)
`
`Any RCS rendering
`control operation, as
`needed (e.g. volume,
`
`/ A
`
`VT: :PlayO
`
`\4
`
`/.
`
`-Band
`
`ransfer
`
`RCS::SetVolume()
`
`>
`
`Content Transfer
`
`Complete
`
`Repeat as Needed
`
`CM::TransferCom pleteO
`
`>
`
`CM::TransferCompleteO
`
`Y
`
`Copyright © 2002, Contributing Members of the UPnPTM Forum. All rights Reserved.
`
`Page 15 of 22
`
`
`an AVT lnstanoelD
`
`
`Page 15 of 22
`
`

`

`UPnP AV Architecture: 1 — Document Version 1.00
`
`16
`
`6.3. No CM::PrepareForConnectiono Action
`
`In some circumstances. vendors may choose to not implement the PrepareForConnectionO action, which
`(among other tasks) provides a mechanism for the Control Point to obtain the InstancelD of the
`AVTransport