笔记 - UMAI:一种标识媒体资产对象的方法

申请（专利）号：200710140536.3

摘要　

本发明揭示了一种在IPTV产业通过使用统一媒体资产标识符(UMAI) 在多内容供应子系统、多网络运营子系统和多IPTV设备组成的全局系统内唯一地标识不同的媒体资产对象的方法。所述方法主要通过以下步骤来实现：不同的内容供应子系统向网络运营子系统的内容管理装置提供带有UMAI 的内容；网络运营子系统的内容管理装置根据UMAI来区分不同内容供应子系统所提供的内容，并将其提供给IPTV设备；IPTV设备基于客户的请求，根据UMAI来确定所请求的内容所属的内容供应子系统以及媒体资产对象类型，并向相应的内容供应子系统提出授权请求和获取密钥请求。进一步，UMAI 定义为″umai：″Asset-Type″/″Sequence″@″Domain。根据本发明的方法，可以有效地在不同的IPTV系统间以及IPTV系统内部标识媒体资产内容所属的供应系统及媒体资产类型。

背景:

中国IPTV市场主要有5类参与者：内容供应商，增值运营商，电信运营商，设备供应商和用户。在内容供应商的内容供应子系统与电信运营商的网络运营子系统间需要众多接口完成复杂的内容信息传送，其中包括大量参数用于标识媒体资产信息，比如点播节目，电视频道，电视节目单，内容套餐包，演职人员，EPG栏目，图片，信息页面等。

传统技术局限：

传统IPTV系统通常采用递增ID来标识媒体资产对象。实际的运营中通常包括多个内容供应子系统，多个网络运营子系统和多IPTV设备。递增的ID容易在各个系统中重复。不适合跨系统的标识一个唯一对象。

发明内容：

UMAI可以在IPTV产业中标识不同的媒资对象，网络运营子系统可以个根据UMAI来区分内容的不同CP子系统，IPTV设备可以根据不同的CP子系统来分别进行授权获取密钥等操作。

UMAI = "umai: <Asset-Type>/ <Seq>@<Domain>?<Param-List>

Asset-Type 为媒体资产类型, 比如VOD/Channel/Schedule/Package等，Asset-Type最好为节目在电视界面上的分类

Seq为自增的编号(这个我觉得无所谓吧，只要能够在Domain内保持唯一就可以)

Domain为IPTV对象归属的域名，用来区分不同的媒体资产对象归属的内容供应子系统

Param-List 用来标识媒资对象的进一步信息

例子：

心得：

一个统一的交换格式标准在IPTV系统内是非常重要的，这个专利是相应的媒资ID标识的标准，我们可以看到它和RFC2396的URI规范，平常的电子邮件格式的一些相似之处。

对于文广而言，需要建设一个全国的内容平台，该平台可以跨越系统的边界，一个基本的要求是不同CP的内容可以唯一的标识，这对它很重要。

从CDN本身来讲，它不应该需要一个类似于统一的文广的内容平台，必须降低接入CDN系统的CP的门槛。

对于CDN来说，假如需要实现跨系统的内容交换，如何在不同的平台间唯一的标识内容是很重要的。

一般来讲，CDN只需要内容的物理属性和一些service属性，不需要媒资的信息如演员等，但是假如CDN要开展一些增值服务，就需要更多的媒资信息了。

跨CDN系统的互联互通需要Content标识具有哪些信息呢？

Content_ID 在 CDN系统里面同一个CP的命名空间内的ID

Content 的SP-CP ID

Content 的 SP_CP 的 portal 信息，这个是由 SP-CP的ID同时就决定了，所以不必放到 Content 标识里面

Content 可以用于哪些服务，比如 rtsp , http ，vod , time-shift , 这个可以在SP-CP的channel信息里面决定。其实协议只能标注最简单的service类型，比如时移等不太好在这里面标识清楚

Content 的 CDN 系统归属信息，但是一个Content可能同时注入了多个CDN系统

排除最后的CDN子系统的要求，

该ID最原始的可以采用双ID的方式，即 Content_ID@SP_CP_ID ,

假如要更灵活的话，应该是类似于电子邮件的 Content_ID@Domain_Name，

假如要有Service标识，应该是类似于URL  :  比如 rtsp://domain/vod/content_id ？Param-list 的格式。 这个满足了上述几乎所有的要求，但是还不够，既要考虑Internet的一些惯例，也要考虑电信运营的一些要求。