这部分的内容大多来源于网络及官方文档,按照自己的翻译理解整理所成。东西比较多,从头慢慢看还是可以懂个大概的。
目录:
一、DNLA的建立
二、DLNA的成员
三、DLNA标准的制定
四、DLNA的设备
五、DLNA的架构
六、云时代的数字家庭(待填坑)
扩展阅读I: UPnP的工作过程------------DLNA基础协议框架
扩展阅读II UPnP AV(Audio/Video) Architecture---------------DLNA媒体应用框架)
一、DNLA的建立
DLNA 成立于2003 年6 月24 日, 其前身是DHWG (Digital Home Working Group 数字家庭工作组),由Sony、Intel、Microsoft等发起成立、旨在解决个人PC ,消费电器,移动设备在内的无线网络和有线网络的互联互通,使得数字媒体和内容服务的无限制的共享和增长成为可能。DLNA的口号是Enjoy your music, photos and videos, anywhere anytime。该组织的官方网站是http://www.dlna.org . 页面主色调green,black,white,silver和gray,后面要讲到的UPnP的主业也是同样的调调,这两个关系挺大的,后面讲。
二、DLNA的成员
这个组织将加入者分为两个层次,最高层次为promoter, 其次为contributor。promoter制定标准和协议,contributor可以分享这个组织的资源,也可以提交标准,参与讨论。现在绝大多数的电子制造商都加入了该组织,至少是contributor,而且年费还很贵。成员名单可以从http://www.dlna.org/about_us/roster/中可以找到。
下图是2008年DLNA的promoter:
下图是2011年的promoter:
从上面两个图我们可以看见,DLNA的骨干成员包括以Intel为首的芯片制造商;以HP为首的PC制造商,以Sony,Panasonic,Sharp,Samsung,LG 为首的家电、消费电子制造商;以CISCO,HUWEI,MOTOROLA,ERICSSON为首的电信设备/移动终端/标准商;一家独大的Microsoft软件/操作系统商等等。
值得注意的有几点:
1.DLNA这个东西基本Intel,Microsoft两个领域巨头在推,一个搞芯片,一个搞系统。AMD没出现在2011的promoter名单中;Google来年会不会掺一脚不好说。还有QUALCOMM也参加进来了,这几年的智能手机芯片处理器他家的也比较多,而且他家还有很多专利可以吃。
2.2011就剩HP一个大PC商了,其他大PC商如Acer,Asus都还不是promoter,他们肯定要抢着加入的。lenovo不仅从promotor名单中消失了,自然也不会是contributor了,和AMD一样。最开始时lenovo是很积极的,在DHWG的时候也是骨干成员,回来中国搞了一个“IGRS闪联”,退出的原因不知道和这个有没有关系。IGRS在很大程度上和DLNA是比较类似的,框架协议和UPnP也是比较像的。
3.Awox和Cablelabs都是做互联多媒体设备的。Broadcom主要是做移动消费电子,有硬件solution,也有产芯片。
4.ACCESS(爱可视)是做软件的。现在软件的需求很大,给第三方提供软件solution是一块很大的蛋糕。cyberlink和arcsoft也在做这方面,已经有些成熟的软件solution了,像EMC,NeuSoft也有在做。
5.运营商开始加入了,像at&t美国电报电话公司,at&t也挺厉害的,到处搞签约机,像是跟PSP VITA也签了。以后中国移动联通不知道会不会也跑来参加(有点难...)。
6.dts和dolby都是做音视频标准的,他们基本是跑来收钱的,你机器上到他们的专利你就得付钱,跟以后肯定其他人也会跑来收钱。
三、DLNA标准的制定
该组织旨在建立一个基于开放的工业标准的互操作平台,并将确立技术设计规则,供企业开发数字家庭有关的产品。其工作目标是根据开放工业标准制定媒体格式,传输和协议互操作性的指南和规范,和其他工业标准化组织进行联络,提供互操作性测试,并进行数字家庭市场计划的制定和实施。
DLNA并不是创造技术,而是形成一种解决的方案,一种大家可以遵守的规范。所以DLNA选择的各种技术和协议都是目前所应用很广泛的技术和协议。所以很多家都要参加,希望DLNA采纳自己的协议和标准,以后自己好办事,可以的话顺便吃点专利费。大方向上肯定打不过Intel和Microsoft的,只能跟着他们走,可以提起其他方面的协议和标准。DLNA的标准写在DLNA GUIDELINES里面,就是大家开会一起写出来的,再开会不停修改的一个standard,一个specification。参加DLNA的商家必须按这个标准走,这样大家的设备才能相互通信。
四、DLNA的设备
在讲DLNA的架构之前先讲一下DLNA规定的设备分类,这些设备就是DLNA标准执行的物理和逻辑对象。
这是一个DLNA 设备的类图。
1.Home NetWork Device(HND)。这类设备指家庭设备,具有比较大的尺寸及较全面的功能,主要与移动设备区别开来,下属5类设备:
(1)Digital Media Server(DMS)。数字媒体服务器,提供媒体获取、记录、存储和输出功能。同时,内容保护功能是对DMS的强制要求。DMS总是包含DMP的功能,并且肯能包含其他智能功能,包括设备/用户服务的管理;丰富的用户界面;媒体管理/收集和分发功能。DMS的例子有PC、数字机顶盒(附带联网,存储功能)和摄像机等等。
(2)DMP。数字媒体播放器。能从DMS/M-DMS上查找并获取媒体内容并播放和渲染显示。比如智能电视、家庭影院等。
(3)DMC。数字媒体控制器,查找DMS的内容并建立DMS与DMR之间的连接并控制媒体的播放。如遥控器。
(4)DMR。数字媒体渲染设备。通过其他设备配置后,可以播放从DMS上的内容。与DMP的区别在于DMR只有接受媒体和播放功能,而没查找有浏览媒体的功能。比如显示器、音箱等。
(5)DMPr。数字媒体打印机,提供打印服务。网络打印机,一体化打印机就属于DMPr。
2.Mobile Handheld Devices(MHD)手持设备。相比家庭设备,手持设备的功能相对简化一些,支持的媒体格式也会不同。
(1)M-DMS。与DMS类似,如移动电话,随身音乐播放器等。
(2)M-DMP。与DMP类似。比如智能移动电视。
(3)M-DMD。移动多媒体下载设备。如随身音乐播放器,车载音乐播放器和智能电子相框等
(4)M-DMU。移动多媒体下载设备。如摄像设备和手机等。
(5)M-DMC。与DMC类似。P如DA,智能遥控器。 手持设备没有定义M-DMR,因为手持设备会讲究便利性,会附加查找控制功能,
要不然就只是普通的移动电视或收音机了。
3.Networked Infrastructure Devices (NID) 联网支持设备。
(1)Mobile Network Connectivity Function (M-NCF)。移动网络连接功能设备。提供各种设备接入移动网络的物理介质。 DLNA的希望是全部实现无线化。
(2)Interoperability Unit (MIU)媒体交互设备。提供媒体格式的转换以支持各种设备需要。
设想一下这样一个scenario:你下了班回到家,掏出手机拨到家庭模式,然后就在手机上遥控打开了等离子电视和PC,然后把订阅的新闻通过PC下载完成后打到等离子电视上播放。这时手机就是一个DMC/M-DMC,等离子电视是一个DMR,PC就是DMS。然后你手机上收到一张朋友从巴西传来的照片,你看完之后把它同步到PC上存储起来,这样手机现在的身份是M-DMU,然后你把这张图片放到电子相框里面。这个电子相框就是一个M-DMD,相框也有play的能力,所以他又是一个M-DMP。所以说这些设备的功能角色都是不定的,界限也不是那么严格。在DLNA Guidelines v1.0的时候还没有智能手机,后来在v1.5加入了。这个设备分类只是定义了功能,而且功能也会变的。以后还会出其它新设备,像pad,tab,touch各种各样,到时候标准也会变的。
五、DLNA的架构
DLNA架构是个互联系统,因此在逻辑上它也类似OSI(Open System Interconnection,开放系统互连)七层网络模型。
DLNA架构分为如下图7个层次:
DLNA ARCHITECTURE
(1) NetWorking Connectivity 网络互联方式:包括物理连接的标准,有有线的,比如符合IEEE802.3标准的Ethernet,;有无线
的 ,比如符合IEEE802.11a/g标准的WiFi,能做到54Mbps,蓝牙(802.15)等,技术都很成熟。现在OFDM和MIMO(802.11n)已经能做到300Mbps了,早就超过比较普及的100Mbps的Ethernet了,只不过产品还没有普及,以后肯定会用到。
(2) NetWorking Stack 网络协议栈:DLNA的互联传输基本上是在IPV4协议簇的基础上的。用TCP或者UDP来传都可以。这一层相当于OSI网络层。
(3)Device Discovery&Control 设备发现和控制。
这个层次是比较essential的,是DLNA的基础协议框架。DLNA用UPnP协议来实现设备的发现和控制。下面重点看一下UPnP。
这一部分可以看一下http://upnp.org/sdcps-and-certification/standards/device-architecture-documents/里的文档。UPnP的工作过程 一文也做了详细说明。下面概括总结性地说一说。
UPnP,英文是Universal Plug and play,翻译过来就是通用即插即用。UPnP最开始Apple和Microsoft在搞,后来Apple不做了,Microsoft还在继续做,Intel也加进来做,Sony,Moto等等也有加入。UPnP有个网站http://www.upnp.org/,我们发现DLNA的网页和UPnP的网页很像,颜色也差不多,就可以知道他们关系很好了。DNLA主要是在推UPnP。
微软官方网站对UPnP的解释:通用即插即用 (UPnP) 是一种用于 PC 机和智能设备(或仪器)的常见对等网络连接的体系结构,尤其是在家庭中。UPnP 以 Internet 标准和技术(例如 TCP/IP、HTTP 和 XML)为基础,使这样的设备彼此可自动连接和协同工作,从而使网络(尤其是家庭网络)对更多的人成为可能。
举个例子。我们在自己的PC(win7)里面打开网络服务的UPnP选项,然后再家庭网络中共享一个装着视频的文件夹,然后买一台SmartTV回来打开就可以找到这台PC的共享文件夹,然后就直接在电视上选文件播放了。
UPnP的另外一个作用是给家庭网内的devices做自动的网络地址转换NAT(NAT,Network Address Translation)和端口映射(Port Mapping),因为家庭网络里面没有那么多IP,所有的devices可能都要通过同一个ip出去。转换映射之后,家庭网络内外的devices就可以通过internet自由地相互连接,而不受内网地址不可访问的阻碍。
UPnP Device Architecture 1.0中会说明设备是怎样通过UPnP来相互发现和控制,以及传递消息的。我们会专门用一章的篇幅来讲一下UPnP Device Architecture,可见下文中的扩展阅读I: UPnP的工作过程
(4)Media Management媒体管理。媒体管理包括媒体的识别、管理、分发和记录(保存),UPnP AV Architecture:1 and UPnP Printer Architecture:1这两个属于UPnP的文档会说明如何进行媒体管理。我将在 扩展阅读II:UPnP AV Architecture 一文中稍微详细介绍UPnP AV设备和CP之间的交互模型及媒体的控制。
UPnP AV Architecture 定义了UPnP AV设备间媒体传送以及和CP间的交互。UPnP AV也定义了两种UPnP AV设备:UPnP AV MediaServer(MS)和UPnP AV MediaRender(MR),以及他们具有的4种服务:
1)Content Directory Service(CDS):能将可访问的媒体内容列出。
2)Connection Manager Service(CMS):决定媒体内容可以通过何种方式由UPnP AV Media Server传送至UPnP AV MediaRender。
3)AVTransport Service:控制媒体内容,比如播放、停止、暂停、查找等。
4)Rendering Control Service:控制以何种方式播放内容,比如音量、静音、亮度等。
UPnP Printer Architecture:1 定义了打印设备和CP的交互模型,这将不再细说。
(5) Media Transport 媒体传输:这一层用HTTP(HyperText Transfer Protocol)超文本传输协议。就是平时我们上网用的媒体传输协议。HTTP用TCP可靠传输,也有混合UDP方式的HTTP。现在HTTP的最新版本是HTTP1.1。可选协议是RTP。
exsample:我们输入一个网址,回车,给server发一个request,用TCP我们就可以等server给我们消息,说明server收到我们的消息了,否则我们就重发;接着server给我们TCP包,我们收一个就给server回信说我们收到了,要是server收不到回信,他就认为包丢掉了,会再传一个同样的包过来。不停地回信就是会比较慢。
那如果我们用UDP会怎样?就是说我们不给server回信说我们收到编号是x的包了,server也就不给我们重发丢掉的包了,这样我们就丢包了。
但是我们传stream的时候,比如视频流,不用存,看完就完了,这种时候就可以用UDP来传。加上局域网里面QoS本来就很高,丢包都是不太可能的。所以UDP肯定会用。局域网多播的时候也用UDP,这个在后面讲。
媒体的传输方案如下:
1)从DMS/M-DMS至DMP/M-DMP,即使不立即播放。
2)从一个DMS到另一个DMS,这时接收方DMS播放接收媒体内容,表现为一个DMP;也可以不立即播放,可能只是存储或者处理。
媒体传输 模式有三种:
1)流传输。当DMR/DMP需要实时渲染接收媒体,媒体具时序性。
2)交互传输。不包含时序的媒体,如图片传输。
3)后台传输。非实时的媒体传输,比如上传下载等。
(6)Media Formats媒体格式。格式Formats在这里等同于编码格式Codec,平时我们说的编码格式比如Mpeg-2,AVC,x264就是视频编码格式;PCM,mp3(MPEG-2 Layer 3),aac,flac就是音频编码格式。而avi,rmvb,mkv这些是媒体封装格式,包含视频音频可能还有字幕流。比如一个常见的后缀为mkv的文件,它的视频Codec是x264,音频是aac,它的视音频编码属于Mpeg-4 Codec Family。
我们知道不同设备对编码格式的支持能力不同,Media Formats这一部分规定了设备应该具有的格式支持能力。下面的表是DLNA支持的所有编码格式:
DLNA-proved format
Video | Audio | Images | |
MPEG-1 MPEG-2 H.263 MPEG-4 Part 2 MPEG-4 Part 10 WMV9 VC-1 |
LPCM MPEG-1/2 L2 MPEG-1/2 L3 MPEG-4 AAC LC MPEG-4 AAC LTP MPEG-4 HE AAC MPEH-4 BSAC | AC-3 ATRAC3plus WMA WMA Professional AMR AMR-WB+ G.726 | JPEG PNG GIF TIFF
|
针对家庭设备和手持设备,DLNA有不同的格式规定:
(7)Remote UI 远程用户接口。说白了就是遥控器。比如说有个TV,我们说不管是用遥控器还是直接在TV上按按钮,效果是一样的。不过两者按钮的排列布局是不一样的。好了,现在到DLNA了,我想用手机当遥控器可不可以?当然可以,只要获得TV上按钮的功能,传到手机上来,模拟一个遥控器就好了。DLNA现在想用浏览器的方式,TV给你一个XML,手机上就出现遥控器界面了,有点像webQQ,webOS那种,这样在手机上就不需要客户端了,TV功能更新了,手机直接跟TV要新的XML,很方便。
-------------------------------------------------------------------------------------------------------------------------------
扩展阅读I: UPnP的工作过程
UPnP的工作过程分为6步:
(1)寻址(Addressing)。
地址是整个UPnP系统工作的基础条件,每个设备都应当是DHCP(Dynamic Host Configuration Protocol 动态主机配置协议)的客户。当设备首次与网络建立连接后,利用DHCP服务,使设备得到一个IP地址。这个IP地址可以是DHCP系统指定的,也可以是由设备选择的。当局域网内没有提供DHCP服务时,UPnP设备将按照Auto-IP的协议,从169.254/169.16地址范围获取一个局域网内唯一的IP地址。设备还可以使用friendly name,这就需要域名解析服务(DNS)来转换name和IP。这个过程用到的东西都是现存的,而且是很普及的,市面上买的路由器都会有。
(2)发现(Discovery)。
发现是 UPnP工作第一步。 当一个设备被添加到网络后,UPnP的发现协议允许该设备向网络上的Control Points(CPs)通知(advise)自己拥有的服务。同样,当一个CP被添加到网络后,UPnP发现协议允许该CP搜索网络上可用的设备。这两种情况下的组播消息一般是设备和服务的基本信息,如它的类型,唯一标识符,当前状态参数等等。要注意设备信息和服务信息都是要组播出去的。发现的过程可以用下面Figure 1-1来描述。
下面详细叙述UPnP发现设备用到的协议:SSDP(Simple Service Discovery Protocol,简单服务发现协议),说明设备是怎样向网络通知或者撤销自己可以提供的服务;CP是如何搜索设备以及设备是如何回应搜索的。
SSDP格式套用HTTP1.1的部分消息头字段,但是和HTTP不同,SSDP是采用UDP传输的,而且SSDP没有Message Body,就是说SSDP只有信头而没有信件内容的。
SSDP第一个要填充的字段是star - line,说明这是个什么类型的消息。
比如填"NOTIFY * HTTP/1.1/r/n",就说明这个SSDP消息是个通知消息,一般设备加入网络或者离开网络都要NOTIFY,更新自己的服务后也要NOTIFY一下。别的设备看见这个消息的star - line就知道有设备状态变了,自己就打开这个消息看一下有没有需要更新的。如果填"NOTIFY * HTTP/1.1/r/n",就要填LOCATION字段,填一个description URL,CP可以通过这个地址来取得设备的详细信息。
填"M-SEARCH * HTTP/1.1/r/n"就是要搜索了;respone别人的搜索就填"HTTP/1.1 200 OK/r/n"。
SSDP第二个要填充的字段是目的地址HOST。比如填上"HOST: 239.255.255.250:1900",就是组播(multicast)搜索,这里239.255.255.250是组播地址,就是说这条消息会给网络里面该组地址的设备发,1900是SSDP协议的端口号。如果HOST地址是特定地址,那这就是单播(unicast)。Respone不填这个字段,他会在ST字段里面填respone address,就是发来搜索信息的设备的地址,Respone消息的话还会发送一个包含自己地址URL的字段,Respone的意思就是跟Searcher说:我好像是你要找的人,我的电话是XXX,详细情况请CALL我。Respone也是UDP单播。
往后的字段就不细说了。通过字段的组合可以发送很多不同的信息。
(3)描述(Description)
前面我们说了CP想要一个device更详细的信息,就打给它的URL跟它要。返回来的东西一般是个XML(Extensible Markup Language,是种结构化的数据。和HTML比较像,有tag和data,具体不说了自己去查),描述分为两部分:一个是device description,是device的物理描述,就是说这个device是什么;还有一个是service descriptions,就是device的服务描述了,就是device能干些什么。这些device和device service的描述的格式也是有要求的,开发商也可以自定义,只要符合UPnP Forum的规范。
这里稍微解释一下设备描述和服务描述。
首先说设备,比如一个家庭影院,有显示屏,有功放音响,还有蓝光机。那么这个家庭影院home threatre,就是一个根设备(root device),它下属有Screen,Amplifier,BDplayer这些从设备。home threatre的描述XML中会有一个device list,列出Screen,Amplifier,BDplayer这些设备的基本信息及这些设备描述的URL,以及设备的presentationURL(这类似于web服务器,通过访问presentationURL,本地会加载一个网页,在这个网页上可以操作设备及其它拥有的服务);还会有一个sevice list,里面列出home threatre可调用的服务基本信息及服务描述URL。
再来是服务,通过访问服务描述URL,可以取得服务描述XML,里面会详细介绍服务的信息,包括干什么用的,属于哪个设备,有哪些action,需要哪些参数,怎么调用等等。
(4)控制(Control)
拿到device description和service descriptions以后,那我们怎么去遥控这些设备呢?
在设备描述部分,device description还有关于如何控制device的描述,会给出一个Control URL,CP可以向这个URL发送不同的控制信息就可以控制device了,然后device也可以返回一个信息反馈。
这种CP和device之间沟通信息按照Simple Object Access Protocol (SOAP)的格式来写。SOAP通过HTTP来传,现在的版本是1.1,叫做SOAP 1.1 UPnP Profile。这个Profile把控制/反馈信息分成三种:UPnP Control Request,UPnP Control Response和UPnP Control Error Response,都比较好理解。SOAP协议是有信内容Body的,和SSDP不一样。消息Body里面就可以写想调用的动作了,叫做Action invocation,可能还要传参数,比如想播放一个视频,要把视频的URL传过去;device收到后要respone,表示能不能执行调用,出错的话会返回一个错误代码。
(5)事件(Eventing)
在服务进行的整个时间内,只要变量值发生了变化或者模式的状态发生了改变,就产生了一个事件,该事件服务提供者(某设备的某个服务)会把该事件向整个网络进行多播(multicast)。而且,CP也可以事先向事件服务器订阅事件信息,就像RSS订阅一样,保证将该CP感兴趣的事件及时准确地单播传送过来(unicast)。
下面是一个Unicast eventing 的architecture图,CP是subscriber,服务器是publisher。
subscriber(通常是个CP)向publisher(通常是个service)发送订阅消息(subscribe),更新订阅消息(renewal),退订消息(cancel)。publisher向subscriber推送订阅(event:SIDX)。
事件的订阅和推送这块用的通信协议是GENA(General Event Notification Architecture) ,通过HTTP/TCP/IP传送。GENA的格式就不细说了,详细请参阅UPnP-arch-DeviceArchitecture-v1.1。下面列出订阅过程供参考:
1.订阅。subscriber发送订阅消息主要包含事件URL(evenURL),服务ID号(service identifier),这两个可以在设备服务描述信息中找到,以及寄送地址(delivery URL)。还会包含一个订阅期限(duration)。
2.成功订阅。publisher收到订阅信息,如果同意订阅的话就会为每个新subscriber 生成一个唯一的subscriber identifier并记录subscriber 的duration和delivery URL。还会记录一个顺序增长event key用来保证事件确实推送到subscriber那里。比如说有个新事件,key是6,然后把这个事件推送给某个subscriber那里,subscriber那里记录的event key是4,现在收到的事件key是6,他就知道他没收到key为5的事件,这样他就向publisher索要漏收的事件,从而保证双方变量值或状态的一致。
3.首次推送。订阅同意订阅之后还会向subscriber发送一组初始变量或状态值,进行首次同步。
4.续订。subscriber必须在订阅到期前发送renewal续订。
5.订阅到期。订阅到期后publisher会把subscriber的信息删除,subscriber又回到订阅前的状态。
6.退订。subscriber发送cancel信息将会取消订阅。subscriber因非正常退出网络的话,则不会退订直到订阅到期。
7.订阅操作失败信息。当订阅、续订和退订不能被publisher接收或者出现错误时,publisher会发送一个错误代码。
再简单说下多播(multicast,或者叫组播,本文中两者等同)和单播。even的组播采用UDP/IP,和SSDP一样,就是端口号变成了7900。下图是几个协议的所处层的位置,可以清楚地看到它们之间的差别。首先关于IP多播,要知道只存在UDP多播,没有TCP多播这回事。为什么呢?多播的重点是提高网络效率,将同一数据包发送给尽可能多的可能未知的计算机。像这种对网内所有设备的频繁消息通知采用多播是为了减小网络负担,SSDP也是一样。
但是SSDP和multicast这种采用UDP方式的协议存在一个问题,就是可靠性不够。解决的办法就是多次通知,但是一般不会超过三次以免增加网络负担,这样就得不偿失了。像SSDP的话会采用定期广播advertice的方式,使各种各样原因而没收到advertice的CP重新获得advertice,又解决了UDP丢包的问题。
前面在寻址的时候用到的DHCP用的是UDP广播(broadcast)。当一个新的设备加入网络时,他想要分个IP,但又不知道DHCP服务器的IP地址,所以他就在网内广播,用255.255.255.255地址来通知所有计算机。DHCP服务器收到请求后会为他申请并返回一个IP地址。
(6)表达(Presentation)
只要得到了设备的URL,就可以取得该设备表达的URL,取得该设备表达的HTML,然后可以将此HTML纳入CP的本地浏览器上。这部分还包括与用户对话的界面,以及与用户进行会话的处理。因此设备表达可以理解成“遥控器”。这部分定义描述界面,规范界面以及传输界面内容。远程界面是供CP用户使用的,CP用户通过远程界面完成设备描述的获取,控制设备,订阅收取设备事件等等。
好了, 到此,UPnP的工作过程的讲解就结束了。总结一下:
UPnP分为6个步骤:
先是Addressing,设备加入网络,通过DHCP或者Auto-IP获得IP;这部分在闪联IGRS中是没有定义的。
然后是Discovery,采用SSDP协议(UDP),用multicast/unicast可以完成设备的上线和离线通知和组播搜索设备,设备用unicast(单播,UDP)响应CP的搜索。
往下是Description,通过HTTP协议(TCP)取回来是一个XML文档,包含物理描述和服务描述;
再来是Control,采用SOAP协议(HTTP/TCP),完成CP和devices之间的交互;
Eventing,采用GENA协议(HTTP/TCP),完成设备事件消息的订阅和推送,为保证可靠性,故是TCP传输;事件的推送还有multicast (UDP)。
最后是Presentation。UPnP并没有定义Presentation应该有哪些东西。一个HTML嘛,哪样写得好哪样来!
扩展阅读II UPnP AV(Audio/Video) Architecture
1.概述
下面是讲解UPnP AV的会用到的一些对象术语。
Table1-1: Default Short Names for the AV Specifications
AV Specification Name | Short Name |
AVTransport | AVT |
ConnectionManager | CM |
ContentDirectory | CD |
MediaRenderer | MR |
MediaServer | MS |
RenderingControl | RCS |
ScheduledRecording | SRS |
在UPnP AV Architecture:1 (Document Version: 1.1) 文档最开始的是这样介绍的UPnP AV的:
本文档描述了整体的UPnP AV 架构。该架构是UPnP AV设备和服务范例的基础架构。
该架构定义了 UPnP 控制端与 UPnP AV设备基本交互,并且与特定设备类型,媒体内容格式与传输协议无关。它支持如电视机,录像机和 CD / DVD 播放机 / 自动点唱机,机顶盒,音响系统,MP3播放器,静止图像照相机,摄像机,电子相框,以及PC 等各种设备,。该AV 架构允许设备支持不同格式的多媒体格式(如MPEG2, MPEG4 和 JPEG 格式, MP3, Windows 媒体架构( WMA ),位图(BMP ), NTSC 制式, PAL 制式, ATSC标准等)和多种类型的传输协议,如 IEC-61883/IEEE-1394,HTTP GET, RTP 协议, HTTP 的 PUT/邮政, TCP / IP 协议等)。以下各节描述了AV架构,以及如何各种UPnP AV设备和服务协同工作,使各种最终用户的情况。
“与特定设备类型,媒体内容格式与传输协议无关”的内在含意是UPnP AV Architecture只是提供了某种机制、模型,并没有规定采用
何种技术来实现。技术的实现部分在 UPnP Device Architecture中有说明。
UPnP AV Architecture 定义了UPnP AV设备间媒体传送以及和CP间的交互。 UPnP AV 也定义了两种 UPnP AV 设备:UPnP AV MediaServer( MS)和 UPnP AV MediaRender(MR ),以及他们具有的 4 种服务:
1)Content Directory Service(CDS):能将可访问的媒体内容列出。
2)Connection Manager Service(CMS):决定媒体内容可以通过何种方式由UPnP AV Media Server传送至 UPnP AV MediaRender 。
3)AVTransport Service:控制媒体内容,比如播放、停止、暂停、查找等。
4)Rendering Control Service:控制以何种方式播放内容,比如音量、静音、亮度等。
2.UPnP AV 设备的交互模型
在设备交互中, CP 是最重要的,因为 Action 通常是由CP发出的。UPnP AV 架构对 CP 的功能要求有 10条:发现 AV设备,获得所需的内容列表,获得渲染器支持的协议/ 格式,比较/匹配协议 / 格式,配置服务器/渲染器,选择所需的内容,开始内容传输,调整渲染参数,重复:选择下一个内容,断开服务器和渲染器连接。
CP可以是MediaServer,也可以是MediaRenderer,也可能只是遥控器remote control。根据CP的角色,归纳出下面三种常见的AV设备交互模型:
(1)2-Box Pull Model
这种情况下CP是MediaRenderer,它可以是一个智能手机。CP主动向MediaServer索取媒体内容,获得内容之后播放媒体,是拉(pull)的方式。
CP要做的是 获得媒体列表>选取所需内容>匹配协议 / 格式,MediaServer需要 选取所需内容>匹配协议/格式>开始传输。
(2)2-Box Push Model
这种情况下CP是MediaServer,它可以是一个一体机。CP主动向MediaRenderer推送(push)媒体。
CP要做的是 本地选取所需内容>匹配协议 / 格式>传输;MediaRenderer需要仅仅需要 匹配协议/格式>接收媒体。
(3)3-box model
在 3-box model中,CP仅仅作为一个遥控器。也分为pull和push两种方式。
当pull方式时,CP向Renderer发送Server及Server上所需媒体内容的URL,让Renderer去取;
当push方式时,CP向Server发Renderer的URL,让Server去向Renderer推送媒体内容。