CN101299829A

CN101299829A - 一种实现统一存储中管理媒体内容的方法和消息系统

Info

Publication number: CN101299829A
Application number: CNA2007101071644A
Authority: CN
Inventors: 许国军
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-04-30
Filing date: 2007-04-30
Publication date: 2008-11-05
Anticipated expiration: 2027-04-30
Also published as: US20100049817A1; CN101299829B; WO2008131628A1; US8176147B2

Abstract

本发明公开了一种实现统一存储中管理媒体内容的方法，在消息系统网络侧存储媒体内容以及与所述媒体内容对应的媒体内容元数据，用户客户端根据所述媒体内容元数据对所述媒体内容进行管理操作。本发明还公开了一种实现统一存储中管理媒体内容的消息系统，该消息系统包括用户客户端和网络统一存储实体，所述用户客户端用于向网络统一存储实体发出对媒体内容的管理请求；所述网络统一存储实体用于存储媒体内容以及媒体内容元数据，根据所存储的媒体内容元数据，执行来自用户客户端的管理请求所对应的操作。本发明方案可以实现用户客户端对消息系统网络侧存储的媒体内容进行多种管理操作，增强用户体验。

Description

一种实现统一存储中管理媒体内容的方法和消息系统

技术领域

本发明涉及移动通信网络、互联网络上的消息业务领域，特别涉及一种实现统一存储中管理媒体内容的方法和消息系统。

背景技术

消息业务属于基于在线的个人对个人、个人对群组的消息类的移动数据业务，消息通信系统除了应具备基本信息交互能力外，还应为用户提供基于定制的增强业务体验，譬如：在用户使用消息业务的过程中，用户发送、接收的消息可以作为历史消息统一存储下来，而且也可以将用户使用消息业务过程中发送和接收的媒体内容分别保存下来，允许用户以后有选择地管理统一存储所保存的消息及媒体内容；或者允许用户将自己感到有价值的媒体内容上传到网络侧的存储区。

即时消息(Instant Messaging，IM)业务支持会话历史业务功能和离线消息存储功能，为参与会话的各方用户之间收发的消息提供网络存储，每一位消息业务的签约用户都将可以拥有对应于自身会话历史记录的网络备份，所述网络备份包括会话历史消息(Conversation History Messages)和会话历史元数据(Conversation History Metadata)。会话历史消息记录了会话过程中，参会的各方用户收发的所有消息，是会话历史信息的主要载体，并且允许用户在会话结束后重新取回其中感兴趣的内容；会话历史元数据作为会话历史功能管理信息存在，是消息业务提供者定义的结构化内容，可以看作是会话历史记录的摘要。

融合消息业务(CPM)支持统一存储功能。业务的统一存储可以包括如下方面：根据用户或运营商的设置为用户保存会话历史消息，每一位消息业务的签约用户都拥有对应于自己历史消息记录的网络备份；当用户对其中的消息或媒体内容感兴趣时，可以根据某些关键词搜索并取回感兴趣的内容；用户也可以将自己感兴趣的媒体内容单独存储。所述媒体内容可以来自于消息，也可以是用户自己上载到统一存储设备的。

开放移动联盟(Open Mobile Alliance，OMA)标准组织制定了相关标准来规范消息业务中的统一存储功能。如图1所示，在当前的标准规范中，消息系统中的统一存储功能组件分布在消息业务服务器(Messaging SeverServer，MS)150和扩展标识语言(Extensible Markup Language，XML)文档管理服务器(XDMS)140，并利用聚合代理(Aggregation Proxy，AP)、搜索代理(Search Proxy，SP)为消息业务用户客户端(User Agent，UA)110提供统一存储业务功能。

图2为图1所示的消息系统实现将用户之间的会话消息或者离线消息统一存储为离线消息或会话元数据的示意图。所述会话元数据包括会话历史消息列表(history list)，每个会话历史消息列表包括大小(size)、到期时间(expiry)、标题(subject)、历史消息(pager or conference)、会话开始时间(date)和保存路径(history reference)。

现有的会话历史和离线消息技术方案提供了会话过程中历史消息和离线消息的存储能力，可以实现存储用户会话历史记录这个基本需求，或利用离线消息存储方式存储其他历史消息。但是该方案仅存储了诸如会话起止时间、会话主题等整体概要性元数据，或离线消息的相关信息；而没有包含会话过程中出现的具体会话消息的元数据，及相关媒体内容的元数据，譬如媒体名称、大小、类型等，在离线消息中也没有包含消息中相关媒体内容的元数据。因此，现有的统一存储的技术方案限制了用户将来在历史消息中检索媒体内容和管理媒体内容的能力，用户无法有选择地从统一存储设备中直接获取感兴趣的消息或媒体内容，其根本原因在于，现有的统一存储方案在会话历史和离线消息的网络存储中缺乏必要的媒体内容的元数据信息。

综上所述，现有技术的缺点在于，现有的消息技术方案虽然提供了历史消息的存储能力，但是，由于该存储的消息元数据处理上不够细致，没有给出消息中媒体内容的存储位置、大小、标题等信息，因此不能满足用户想单独保存媒体内容或上载媒体内容到统一存储实体的需求，更难以满足在此基础上的用户对历史消息中的媒体内容的管理需求。

发明内容

有鉴于此，本发明实施例提出一种实现统一存储中管理媒体内容的方法，能够实现对统一存储的媒体内容进行管理。该方法包括：

在消息系统网络侧存储媒体内容以及与所述媒体内容对应的媒体内容元数据，用户客户端根据所述媒体内容元数据对所述媒体内容进行管理操作。

本发明实施例还提出一种用于实现统一存储中管理媒体内容的消息系统，该消息系统包括用户客户端和网络统一存储实体，所述用户客户端用于向网络统一存储实体发出对媒体内容的管理请求；

所述网络统一存储实体用于存储媒体内容以及媒体内容元数据，根据所存储的媒体内容元数据，执行来自用户客户端的管理请求所对应的操作。

从以上技术方案可以看出，本发明针对网络统一存储增加了媒体内容元数据信息，基于所述媒体内容元数据，用户可以深入历史消息记录检索、删除媒体内容，也可以上传或者单独存储来自消息的媒体内容并对该媒体内容管理，从而丰富了消息系统的签约用户的消息业务体验。

附图说明

图1为消息系统中实现统一存储功能的架构图；

图2为现有技术实现将用户之间的会话消息或者离线消息统一存储为离线消息或会话元数据的示意图；

图3为本发明实施例中的历史消息元数据的存储结构示意图；

图4为本发明实施例一进行媒体内容检索的处理流程图；

图5为本发明实施例一用户获取会议会话历史元数据的信令交互以及处理流程图；

图6为本发明实施例一用户客户端获取媒体内容的流程图；

图7为本发明实施例一用户通过消息业务服务器主动请求删除媒体内容的处理流程图；

图8为本发明实施例一用户通过聚合代理主动请求删除媒体内容的处理流程图；

图9为本发明实施例二用户主动上传媒体内容的处理流程图。

具体实施方式

在详细描述本发明方案之前，首先明确几个概念。历史消息(Pager/Conference History Messages)，其中历史消息记录的是用户发送和接收到的过程性信息，形式上可能是普通文本消息，也可以是包含图片、音频、视频的多媒体消息。媒体内容泛指消息中所包括的除普通文本以外的部分，包括图片、音频、视频部分，或者是生成的音频或视频文件，或者是用户上传的媒体文件。历史消息元数据(Conference/Chat History Metadata)是历史消息管理中用户特定的结构化信息。用户特定，是指会话历史功能服务的每一用户都有与己相关的元数据。为了维护会话历史管理所依赖的各种有用信息，这些元数据大都具有统一的层次化结构。所述管理，包括存储、检索、更新、删除等各种操作。

通常，现有消息系统包括历史消息管理所定义的历史消息元数据，或者，会话历史元数据层次结构中不包含媒体内容部分，也不包括独立的媒体内容元数据信息。现有的元数据结构记录的是消息的发送者、接受者、时间等信息，这导致现有消息系统赋予用户的历史消息管理功能只能是针对每条消息或会话历史内容本身，无法对其中感兴趣的图片、声音、视频等媒体内容做进一步地检索和维护，或单独存放或处理媒体内容。

为了解决消息系统中上述历史消息管理功能的局限性，提升用户历史消息业务体验，本发明扩展了历史消息元数据和会话历史元数据的结构化定义，为历史消息元数据和会话历史元数据增添了媒体内容元数据(media metadata)相关内容，并支持对媒体内容进行管理操作。所述扩展包括以下三个方面：

1)、采用任何能够反映元数据层次结构的数据存储形式，譬如符合XML Schema语法规范的XML文档进行消息系统中历史消息元数据和媒体内容元数据的网络存储；

2)、采用任何适当通信协议，譬如互联网工程任务组(The Internet Engineering Task Force，IETF)定义下的XML配置访问协议(XCAP)来访问和操作消息系统网络存储下的媒体内容元数据或历史消息中媒体内容元数据；

3)、采用上述存储形式和通信协议针对媒体内容元数据或历史消息元数据和会话历史元数据进行各种媒体内容处理操作，包括：媒体内容元数据信息的存储、检索(如Xquery查询)、删除、权限设置等。

图3为本发明实施例中的历史消息元数据的存储结构示意图。在元数据的XML结构化定义中，消息元数据可以单独存在，或是作为会话历史消息列表元数据的子元素共同存储于同一个XML文档之中。媒体内容元数据作为消息或会话历史消息的子元素存在。

以下给出历史消息元数据XML文档的XML Schema语法架构定义的一个范例：

<xs:schema attributeFormDefault＝″unqualified″elementFormDefault＝″qualified″

targetNamespace＝″urn:oma:xml:history-list″

xmlns＝″urn:oma:xml:history-list″

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xmlns:xs＝″http://www.w3.org/2001/XMLSchema″

xmlns:ns2＝″http://www.w3org/1999/xhtml″

xmlns:ns＝″urn:oma:xml:history-list″

xmlns:hfp＝″http://www.w3org/2001/XMLSchema-hasFacetAndProperty″>

<xs:element name＝history-list″>

<xs:complexType>

<xs:sequence maxOccurs＝″unbounded″minOccurs＝″0″>

<xs:element name＝″history″type＝″historyType″/>

</xs:sequence>

<xs:anyAttribute namespace＝″##other″processContents＝″lax″/>

</xs:complexType>

</xs:element>

<xs:complexType name＝″historyType″>

<xs:sequence>

<xs:element name＝″size″type＝″xs:positiyeInteger″/>

<xs:element name＝″expiry″ type＝″xs:dateTime″minOccurs＝″0″/>

<xs:element name＝″subject″type＝″xs:string″ minOccurs＝″0″/>

<xs:choice>

<xs:element name＝″pager″type＝″pagerModeType″/>

<xs:element name＝″conference″type＝″conferenceModeType″/>

<xs:element name＝″media″type＝″MediaType″/>

</xs:choice>

<xs:any namespace＝″##other″processContents＝″lax″minOccurs＝″0″maxOccurs＝″unbounded″/>

</xs:sequence>

<xs:attribute name＝″date″type＝″xs:date″use＝″required″/>

<xs:attribute name＝″history-reference″type＝″xs:anyURI″use＝″required″/>

<xs:anyAttribute namespace＝″##other″processContents＝″lax″/>

</xs:complexType>

<xs:complexType name＝″pagerModeType″>

<xs:sequence>

<xs:element name＝″time-stamp″type＝″xs:dateTime″/>

<xs:element name＝″from″type＝″xs:string″/>

<xs:element name＝″to″type＝″xs:string″/>

<xs:element name＝″auth-id″type＝″xs:string″minOccurs＝″0″/>

<xs:element name＝″pm-list″type＝″confListType″minOccurs＝″0″/>

<xs:element name＝″media″type＝″mediaType″minOccurs＝″0″/>

</xs:sequence>

</xs:complexType>

<xs:complexType name＝″conferenceModeType″>

<xs:sequence>

<xs:element name＝″time-start″type＝″xs:dateTime″/>

<xs:element name＝″time-end″type＝″xs:dateTime″/>

<xs:element name＝″recording-name″type＝″xs:string″minOccurs＝″0″/>

<xs:element name＝″conf-list″type＝″confListType″minOccurs＝″0″/>

</xs:complexType>

<xs:complexType name＝“msgType″>

<xs:sequence>

<xs:element name＝″title″ type＝″subjectType″minOccu rs＝″0″/>

<xs:element name＝“sender″type＝″contactType″minOccurs＝″0″/>

<xs:element name＝“receiver″type＝″contactType″minOccurs＝″0″/>

<xs:element name＝″size″type＝″xs:decimal″minOccurs＝″1″/>

<xs:element name＝″sequence″type＝″xs:int″minOccurrs＝″1″/>

</xs:sequence>

<xs:attribute name＝“id″type＝″xs:anyURI″use＝″required″/>

<xs:element name＝″medid″type＝″media Type″/>

<xs:attribute name＝“time″type＝″xs:dateTime″use＝″required″/>

<xs:anyAttribute namespace＝″##any″processContents＝″lax″/>

</xs:complexType>

<xs:anynamespace＝″##other″processContents＝″lax″minOccurs＝″0″maxOccurs＝″unbounded″/>

</xs:sequence>

</xs:complexType>

<xs:complexType name＝″mediaType″>

<xs:sequence maxOccurs＝″unbounded″>

<xs:sequence>

<xs:element name＝″title″type＝″subjectType″minOccurs＝″0″/>

<xs:element name＝″msg id″type＝″xs:anyURI″minOccurs＝″0″/>

<xs:element name＝″size″type＝″xs:decimal″minOccurs＝″0″/>

<xs:element name＝″sequence″type＝″xs:int″minOccurs＝″1″/>

</xs:sequence>

<xs:attribute name＝“id″type＝″xs:anyURI″use＝″required″/>

<xs:attribute name＝“time″type＝″xs:dateTime″use＝″required″/>

<xs:attribute name＝″type″use＝″required″>

<xs:choice>

<xs:element name＝″file-transfer″type＝″mTyPe″/>

<xs:element name＝″audio″type＝″duplex″/>

<xs:element name＝″video″type＝″duplex″/>

<xs:element name＝″image″type＝″image″/>

<xs:any namespace＝″##other″processContents＝″lax″/>

</xs:choice>

</xs:attribute>

</xs:sequence>

<xs:anyAttribute namespace＝″##other″processContents＝″lax″/>

</xs:complexType>

<xs:complexType name＝″confListType″>

<xs:sequence maxOccurs＝″unbounded″minOccurs＝″0″>

<xs:element name＝″entry″type＝″entryType″/>

</xs:sequence>

</xs:complexType>

<xs:complexType name＝″entryType″>

<xs:sequence>

<xs:element minOccurs＝″0″name＝″display-name″

type＝″xs:string″/>

</xs:sequence>

<xs:attribute name＝″uri″type＝″xs:anyURI″use＝″required″/>

</xs:complexType>

</xs:schema>

示例1

从示例1中可以看出，历史消息元数据XML元素层次结构可以表述如下：

根元素为历史消息列表(history-list)；

消息元数据元素为会话历史(history)，代表用户一个消息记录或一次会话记录，具有主题(subject)，期限(expiry)，大小(size)等子元素，及消息或会话的发生日期(date)，消息或会话历史文档存储路径(history-reference)等属性。本实施例为每个消息元素XML Schema定义中添加了媒体信息，为会话元数据的XML Schema定义中增加了隶属与该会话的消息元数据(msg)及媒体信息元数据，也增加了单独存放媒体时的元数据信息。

会话历史消息元数据元素为消息(msg)，代表用户会话中收发的消息，具有其标识(id)属性，所述标识属性用来在会话存储中定位消息。

媒体内容元数据包括单独存放的媒体内容或消息中包含的媒体内容或本次会话中发送和接收的媒体内容。描述了媒体的大小、类型、建立时间等信息，如果是单独存储也可以包括其归属的消息标识。媒体内容元数据的″id″属性用来单独或在消息或会话存储中定位媒体内容。

历史消息元数据XML元素类型定义如下：

本实施例历史消息中的媒体内容元数据可以是用于描述消息细节，包括如下元素：消息标题(subject)，到期时间(expiry)，消息发送者(from)接收者(to)，消息大小(size)，消息中的媒体内容标识(media ID)，消息的唯一标识(id)，消息发送时间(time)。

或者，媒体内容元数据用于描述会议会话中历史消息细节的消息元数据及媒体内容，包括如下元素：消息标题(title)，消息发送者(sender)和接收者(receiver)，消息序列号(sequence)，消息大小(size)，会话历史中的消息标识(id)，消息发送时间(time)，消息中所包含的媒体内容标识(media ID)。

或者，是独立媒体内容元数据，包括如下元素：媒体内容标题(subject)，到期时间(expiry)，媒体大小(size)，媒体发送者(sender)，媒体内容标识(media ID)，发送时间(time)。

通过在消息系统中的媒体内容及消息历史记录中增加上述针对媒体内容的媒体内容元数据信息，系统不仅允许用户浏览所保存的媒体内容的描述信息，还为用户提供管理媒体内容的手段。

根据消息业务运营商网络设备配置的不同，媒体内容和历史消息，以及媒体内容元数据和消息历史元数据可以在消息业务服务器和后台数据存储设备(诸如XML文档管理服务器等)之间灵活存放：

媒体内容和历史消息及媒体内容和历史消息元数据全部存储在消息业务服务器；

媒体内容和历史消息及媒体内容和历史消息元数据全部存储在数据存储设备；

媒体内容和历史消息存储在消息业务服务器而媒体内容和历史消息元数据存储在数据存储设备；

媒体内容和历史消息存储在数据存储设备而媒体内容和历史消息元数据存储在消息业务服务器

尽管媒体内容和历史消息在网络中可以有不同的存储位置，但消息系统应该独立于媒体内容和会话历史信息的物理位置而为消息用户客户端提供统一的媒体内容和历史消息功能访问接口，支持一致的消息业务体验。以下，将存储媒体内容、历史信息和/或媒体内容和历史消息元数据的网络存储实体统称为网络统一存储实体。

网络统一存储实体除了对搜索代理提供媒体内容以及历史消息的搜索功能外，还需要包括：

上载模块，用于接收并存储用户客户端所上载的媒体内容，并生成与所述媒体内容对应的媒体内容元数据；

删除模块，用于根据来自用户客户端的删除请求，删除对应的媒体内容，包含媒体内容的历史消息或与包含媒体内容的历史消息属于同一会话的其它历史消息。

以下给出历史元数据的示例文档，并描述本发明实施例针对该示例文档是如何实现对历史消息的媒体内容进行各种管理操作的。

实施例一：对历史消息中包含的媒体内容的检索以及其他管理功能。

历史消息元数据的XML格式的示例文档如下：

HTTP/1.1 200 OK

Etag:″etu 15″

Content-Type:application/vnd.oma.history+xml

<？xml version＝″1.0″encoding＝″UTF-8″？>

<history-list xmlns＝″urn:oma:xml:his tory-list″>

<subject>Soccer</subject>

<pager>

<time-stamp>2006-08-13T19:13:00.0Z</time-stamp>

<from>sip:merlin@example.com</from>

<to>sip:Bob@example.com</to>

</media>

<auth-id>sip:medlin@example.com</auth-id>

</pager>

</history>

</media>

<auth-id>sip:medlin@example com</auth-id>

</history>

<subject>″friends″</subject>

<time-start>2006-08-14T 15:05:00.0Z</time-start>

<time-end>2006-08-14T15:15:000Z</time-end>

<recording-name>friends</recording-name>

<title>Holiday</title>

<name>Alice</name>

<uri>alice@example.com</uri>

</sender>

<uri>bob@example com</uri>

</reciever>

<title>Holiday Picture</title>

</media>

</msg>

<conf-list>

<display-name>Boby</display-name>

</entry>

</conf-list>

</conference>

</history>

</history-list>

示例2

针对示例2所示文档，进行媒体内容检索的处理流程如图4所示，包括如下步骤：

步骤401：用户在用户客户端输入针对自己感兴趣的媒体内容的查询条件，用户客户端将所述查询条件发送至消息系统的网络侧。所述查询条件可以是历史消息元数据或媒体内容元数据的任一元素或元素的任意组合；例如，查询条件可以是发送者、发送时间、媒体标识或消息标识等等，或者上述的元素的组合，查询条件可以是精确的也可以是模糊的，例如查询大小大于1M的媒体内容，或是查询发送时间在2006年8月13日的媒体内容等。

步骤402：消息系统根据所存储的媒体内容元数据、会话历史元数据或会话历史消息元数据中查找符合查询条件的媒体内容，向用户客户端返回所找到的媒体内容的摘要信息。所述摘要信息包括媒体内容元数据的部分或全部元素，还可以包括媒体内容元数据标识。

步骤403：用户根据所述摘要信息，向消息系统的网络侧发送获取感兴趣的媒体内容的请求。

步骤404：消息系统根据所述请求，将对应的媒体内容发送至用户客户端。

步骤403中，用户也可根据媒体内容的摘要信息中所包含的消息标识，向消息系统的网络侧发送获取相应的消息内容的请求；则步骤404中，消息系统根据所述请求，将所存储的对应的历史消息内容发送至用户客户端。

用户获取会议会话历史元数据的信令交互以及处理流程如图5所示，其中用户客户端(User Client)表示想要检索会议会话历史的用户客户端；聚合代理是消息系统中为用户提供访问消息系统存储的代理实体；搜索代理是消息系统中负责会话历史元数据搜索的代理实体。该流程包括如下步骤：

步骤501：用户客户端向聚合代理发送含有XQuery查询语句的XCAPPOST请求。本实施例中，消息用户Bob想要检索主题为“Weekend Meet”的会话中所有由Alice发送的历史消息，查询请求具体如下：

POSTHTTP://xcap example com/org.openmobilealliance search HTTP/1.1

……

X-3GPP-lntended-Identity:″sip:bob@example.com″

Content-Type:application/conv-hist+xml

Content-Length:{...}

…

<？xml version＝″1.0″encoding＝″UTF-8″？>

<search id＝″1234″

xmlns＝″urn:oma:params:xml:ns:search″

xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″>

<！[CDATA[

for $x in doc(″org.openmobilealliance/global/conversation″)/history-list

where$x/subject＝“Weekend Meet”

if($x/msg/meida type＝“image”or$x/media/meida type＝“image”)

return <history-list＝″{data($x/@db-ref)}″>

<media id＝″{data($x/msg/@id)}″>{$x/msg/title}</msg></conv>

</request>

</search>

示例3

该请求中需要包含用户客户端的标识信息，在示例3中即为查询者的统一资源定位符(URL)：sip:bob@example.com。URL中包含OMA组织字符串：“org.openmobilealliance.search”，用于表明此为XCAP查询请求。

步骤502：聚合代理发起用户身份鉴别过程，判断用户客户端是否合法，若是，则继续执行后续流程，否则，退出本流程。本步骤可以作为可选步骤。

步骤503：聚合代理通过所收到的POST请求URL中的″org.openmobilealliance.search″字符串判断出该请求的类型为XCAP查询请求。

步骤504：聚合代理将所述XCAP POST请求转发至搜索代理。

步骤505：搜索代理根据查询请求中的AUID：“org.openmobilealliance/global/history message″，判断出此为针对历史信息的查询请求，结合用户URL：sip:bob@example.com，定位出查询对象即历史消息元数据的网络存储位置。

步骤506：搜索代理根据定位的网络存储位置，将所述查询请求转发至网络统一存储实体。

步骤507：网络统一存储实体执行所收到的查询请求中的XQuery查询语句，获得匹配的媒体内容元数据；

步骤508至步骤510：网络统一存储实体将所匹配到的媒体内容元数据携带在200OK响应消息中，将所述200OK消息发送至搜索代理；所述200OK消息经搜索代理、聚合代理的转发，最后发送至用户客户端。本实施例中的200OK响应消息具体如下：

HTTP/1.1200OK

……

Content-Type:application/conv-hist-set+xml

Content-Length:{...}

<？xml version＝″1.0″encoding＝″UTF-8″？>

<history-list＝″storage01@example.com″><media id＝″52789Syt845″>Holiday Picture002</media><msg id＝

″12435Ret565″/msg></conv>

<history-list＝″storage01@example.com″><media id＝″52789Syt845″>Holiday Picture002</media>

</response>

示例4

用户客户端收到检索响应后，用户客户端将获得符合检索条件的媒体引用，即示例中″media id″和其他媒体特征信息，如主题、大小、创立时间等。接下来，一方面，用户客户端将为用户呈现上述有助用户作出媒体检索选择判断的媒体特征信息；另一方面，用户客户端还要根据用户所作的选择，抽取对应媒体特征信息以生成媒体下载请求列表，并以此构造和发送媒体内容获取请求。

图6示出了本发明实施例一用户客户端获取媒体内容的流程，包括如下步骤：

步骤601：用户客户端向消息业务服务器发送会话初始协议邀请(SIPINVITE)请求，其中包含由用户想要下载的媒体标识的媒体下载请求列表。

步骤602：消息业务服务器向网络统一存储实体转发所述SIP INVITE请求。

步骤603至步骤604：网络统一存储实体向消息业务服务器返回SIP OK消息，消息业务服务器将所述SIP OK消息转发给用户客户端。随后，用户客户端向消息业务服务器发送响应消息(ACK)，消息业务服务器将所述响应消息转发给网络统一存储实体。

步骤605：网络统一存储实体从所述SIP INVITE请求中的下载请求列表中抽取媒体标识，并据此检索所存储的媒体内容，得到用户所需的媒体内容。

步骤606至步骤607：网络统一存储实体将检索到的媒体内容发送至消息业务服务器，消息业务服务器再将所述媒体内容转发至用户客户端。不失一般性假设发送的是承载媒体内容的消息会话中继协议(Message SessionRelay Protocol，MSRP)发送(SEND)消息。

步骤608至步骤609：用户客户端向消息业务服务器返回MSRP 200 OK响应消息，消息业务服务器将所述MSRP 200 OK响应消息转发至网络统一存储实体。

根据检索到的媒体内容多少的不同，以上步骤607至步骤609可能只执行一次，也可能执行多次，直到所有检索到的媒体内容都发送至用户客户端。

步骤610至步骤611：媒体内容传送完毕后，网络统一存储实体向消息业务服务器发送SIP BYE消息断开与用户客户端的连接，消息业务服务器将所述SIP BYE消息转发至用户客户端。

步骤612至步骤613：用户客户端向消息业务服务器返回SIP 200 OK响应，消息业务服务器将所述SIP 200 OK响应转发至网络统一存储实体。

在获得媒体内容以后，用户有可能想进一步了解与这些媒体内容相关联的消息，这些消息可能包含有对相关媒体内容的说明。

如果用户想获得媒体内容所在的历史消息，则可以在用户客户端的显示界面上点击该历史消息的标识，则用户客户端向消息业务服务器发送包含所述消息标识的SIP INVITE请求，本领域技术人员可以很容易参照图6所示流程得到获取消息的流程。

如果用户想获取媒体内容所在消息之前或之后的历史消息，则用户客户端根据已检索消息序列号(sequence)及其所属会话标识(db-ref)，构造相应的会话历史消息元数据检索请求。例如，媒体内容所在消息的序列号为N，想检索之前的一条消息，则检索该会话中序列号为N-1的会话历史消息元数据；若想检索之后的第n条消息，则检索该会话中序列号为N+n的会话历史消息元数据。具体检索流程则可以依据图5所示流程。当检索已至会话历史消息上下文首尾或者超出本次会话范围时，应向用户客户端给予提示。

本发明实施例还提供对统一存储的媒体内容进行删除操作。媒体内容的删除分为用户主动请求删除和根据存储策略自动删除两种情形。

其中，用户主动请求删除媒体内容，可以通过消息业务服务器或聚合代理来完成。通过消息服务器删除媒体内容的流程如图7所示，包括如下步骤：

步骤701：用户客户端根据用户的意愿需要删除媒体内容，客户端需要获取要删除的媒体标识等信息。

步骤702：客户端发送一个媒体删除请求消息给消息业务服务器。消息中携带要删除的媒体内容的媒体标识。

媒体删除请求消息可以使用SIP REFER消息的形式，或者使用其它方式完成删除媒体的功能。

如果是SIP REFER消息，该消息简单例子如下：

REFER sip:Deletemedia@hostname SIP/2.0 //指明是让服务器进行删除媒体处理

Refer-To:<”media id”:method＝REFER> //指明是让服务器进行删除媒体处理，及要删除的媒体名称(含路径)

示例5

步骤703：消息业务服务器根据所述媒体删除请求，删除网络统一存储实体中存储的指定媒体内容以及对应的媒体元数据信息。

步骤704：消息业务服务器向用户客户端回媒体删除成功响应消息，通知客户端删除媒体成功。

图8所示为通过聚合代理实现用户主动请求删除媒体内容的处理流程，包括如下步骤：

步骤801：用户客户端向聚合代理发送媒体删除请求，其中包括：媒体内容元数据XCAP访问URI(xcap.example.com/conv-hist-set)，媒体拥有者URI(sip:bob@example.com)以及将要被删除的媒体内容元数据标识。

以下给出一个具体示例：针对如示例1所示的历史元数据文档，消息用户Bob请求删除会话主题为″Weekend Meet″，且消息标题为″Holiday Picture001″的媒体内容，用户终端将根据用户的上述指示，构造如下XCAP删除请求消息：

DELETE HTTP://xcap.example.com/conv-hist-set/users/sip:bob@example.com/history.xml/～～/conv-hist-set/

conv[@db-ref＝″storage01@exampl com″]/msg[@id＝″d93kswow″]/media [@id＝”12345db”HTTP/1.1

Content-Length:0

示例5

从示例5的删除请求消息中可以看出，用户Bob仅请求删除对应的媒体内容。如果该媒体内容与历史消息或会话历史相关联时，也可以删除历史消息或会话历史中的一条或多条消息，更一般的情况是删除整个会话内容，此时的删除请求消息与示例5类似，区别在于其中的“HTTP URI”包括所要删除的消息标识，或者仅包括所要删除的会话历史元数据标识。

步骤802：可选的用户身份鉴别过程。如果选用该步骤，身份鉴别为合法用户则继续后续步骤，否则退出本流程。

步骤803：根据媒体内容元数据XCAP访问URI，聚合代理将删除请求转发到存储对应媒体内容的网络统一存储实体。

步骤804：网络统一存储实体根据用户URI检查用户的操作权限，若操作权限合法，则按照媒体内容元数据标识(conv[@db-ref]/msg[@id])执行对应媒体内容的删除操作；

步骤805至步骤806：网络统一存储实体向聚合代理返回HTTP 200 OK响应，聚合代理将所述200 OK响应转发至用户客户端。

根据存储策略自动删除则是根据媒体内容元数据结构定义中含有的到期时间(expiry)元素，其值用以限定媒体记录的存储期限。一旦消息系统时钟超过到期时间的设定值，相应的媒体记录将被视为过期，此时网络存储实体将会自动删除该媒体内容。

实施例二：独立于消息的媒体内容的管理。

消息系统中独立于消息的媒体内容，其来源可以分为：用户主动请求上传到网络统一存储实体中的媒体内容，或者将多媒体消息中的媒体内容单独保存到网络统一存储实体。

用户主动上传媒体内容的处理流程如图9所示，包括如下步骤：

步骤901：用户客户端向消息业务服务器的URI发送SIP消息(SIP MESSAGE)或SIP INVITE请求，要求上载媒体内容。

步骤902：可选的用户身份验证过程。

步骤903：消息业务服务器将所述要求上载媒体内容的SIP消息或SIPINVITE请求发送至网络统一存储实体。

步骤904：网络统一存储实体检查用户操作权限，若用户具有该操作权限，则继续执行后续步骤。

步骤905至步骤906：网络统一存储实体通过消息业务服务器向用户客户端返回200 OK消息。

步骤907：用户客户端和网络统一存储实体之间建立会话通道。

步骤908：网络统一存储实体接收并存储用户客户端上传的媒体内容，生成并存储与所述媒体内容相应的媒体内容元数据。

步骤909：网络统一存储实体向用户客户端返回携带用户客户端所上传的媒体内容所对应的媒体内容元数据的响应消息。

用户客户端一次可能上载一条或多条媒体内容，步骤909至步骤909可能重复执行多次，直到所有媒体内容上载完毕。

步骤910至步骤911：媒体内容上载完毕后，用户客户端通过消息业务服务器向网络统一存储实体发送SIP BYE消息，要求断开与网络统一存储实体的连接。

步骤912至步骤913：网络统一存储实体通过消息业务服务器向用户客户端返回SIP 200 OK消息。

用户接收到多媒体消息后，针对其中感兴趣的媒体内容，向网络统一存储实体发送保存媒体内容的请求，然后可依照类似图9所示流程将媒体内容保存在网络统一存储实体中。

当用户通过搜索代理搜索到所保存的多媒体消息时，对其感兴趣的媒体内容可以通过该多媒体标识，将该标识通过SIP message消息发送到服务器，指示服务器将该多媒体内容单独保存在网络存储中。

本发明方案针对网络统一存储，增加了历史消息中的媒体内容的元数据信息或者单独的媒体内容元数据信息。从本发明实施例可以看出，用户可以深入历史消息记录检索、删除媒体内容，也可以上传或者单独存储来自消息的媒体内容并对该媒体内容管理，从而丰富了消息系统的签约用户的消息业务体验。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims

1、一种实现统一存储中管理媒体内容的方法，其特征在于，在消息系统网络侧存储媒体内容以及与所述媒体内容对应的媒体内容元数据，用户客户端根据所述媒体内容元数据对所述媒体内容进行管理操作。

2、根据权利要求1所述的方法，其特征在于，所述消息系统网络侧存储的媒体内容包括：历史消息元数据和/或会话历史元数据中的媒体内容元数据，和/或单独保存的媒体内容的元数据。

3、根据权利要求1所述的方法，其特征在于，所述用户客户端根据所述媒体内容元数据对所述媒体内容进行管理操作包括：

消息系统的网络侧接收到来自用户客户端的携带媒体内容元数据的查询条件，根据所存储的媒体内容元数据，查找符合查询条件的媒体内容，并向用户客户端返回所找到的媒体内容的摘要信息。

4、根据权利要求3所述的方法，其特征在于，所述向用户客户端返回所找到的媒体内容的摘要信息之后，进一步包括：

用户客户端根据所述摘要信息，向消息系统网络侧发送获取媒体内容的请求；

消息系统网络侧根据所述请求，将对应的媒体内容发送至用户客户端。

5、根据权利要求3所述方法，其特征在于，所述媒体内容的摘要信息进一步包括消息标识，则所述向用户客户端返回所找到的媒体内容的摘要信息之后，进一步包括：

用户客户端根据所述摘要信息中的消息标识，向消息系统网络侧发送获取对应的历史消息的请求；

消息系统网络侧根据所述请求，将所存储的对应的历史消息内容发送至用户客户端。

6、根据权利要求5所述的方法，其特征在于，所述媒体内容的摘要信息进一步包括消息序列号以及所述媒体内容所述的会话标识，则所述用户客户端根据所述摘要信息中的消息标识，向消息系统网络侧发送获取对应的历史消息的请求包括：

用户客户端根据所述摘要信息中的序列号和会话标识，构造属于该会话标识的其它历史消息的序列号，并向消息系统网络侧发送包括所构造的历史消息序列号的获取历史消息的请求。

7、根据权利要求6所述的方法，其特征在于，所述消息系统网络侧根据所述请求，将所存储的对应的历史消息内容发送至用户客户端之前，进一步包括：消息系统网络侧判断所收到的获取历史消息请求中的消息序列号已达会话历史消息上下文首位或者超出会话历史消息范围，则向用户客户端发出提示消息。

8、根据权利要求1所述的方法，其特征在于，所述用户客户端根据所述媒体内容元数据对所述媒体内容进行管理操作包括：

消息系统网络侧接收来自用户客户端的要求查询媒体内容元数据的查询请求，根据所述查询请求定位所要查询的媒体内容元数据的网络存储位置，并将所述查询请求转发至相应的网络统一存储实体；

网络统一存储实体执行所收到的查询请求对应的查询操作，获得匹配的媒体内容元数据，并将携带所匹配到的媒体内容元数据的响应消息发送至用户客户端。

9、根据权利要求1所述的方法，其特征在于，所述媒体内容元数据包括以下元素之一或其任意组合：消息标题、媒体内容标题、到期时间、消息发送者、接收者、消息大小、媒体大小、消息序列号、媒体内容标识、消息标识、发送时间。

10、根据权利要求9所述方法，其特征在于，该方法进一步包括：若消息系统时钟超过媒体内容元数据中的到期时间，则删除网络侧所存储的相应媒体内容。

11、根据权利要求1所述的方法，其特征在于，所述用户客户端根据所述媒体内容元数据对所述媒体内容进行管理操作包括：

网络侧接收到包含媒体内容元数据标识的媒体删除请求，根据其中的媒体内容元数据标识删除对应的媒体内容。

12、根据权利要求11所述方法，其特征在于，所述网络侧接收到包含媒体内容元数据标识的媒体删除请求之后，进一步包括：网络侧对用户客户端进行用户身份鉴别，若鉴别为合法用户则继续执行所述后续步骤，否则结束本流程。

13、根据权利要求1至12任一项所述方法，其特征在于，所述用户客户端根据所述媒体内容元数据对所述媒体内容进行管理操作包括：

网络侧接收到来自用户客户端的要求上载媒体内容的上载请求，建立用户客户端与网络统一存储实体的会话通道；

网络统一存储实体接收并存储用户客户端上传的媒体内容，生成并存储与所述媒体内容相应的媒体内容元数据。

14、根据权利要求13所述的方法，其特征在于，所述生成并存储与所述媒体内容相应的媒体内容元数据之后，进一步包括：网络统一存储实体向用户客户端返回携带用户客户端所上传的媒体内容所对应的媒体内容元数据的响应消息。

15、一种实现统一存储中管理媒体内容的消息系统，其特征在于，该消息系统包括用户客户端和网络统一存储实体，

所述用户客户端用于向网络统一存储实体发出对媒体内容的管理请求；

16、根据权利要求15所述的消息系统，其特征在于，所述消息系统进一步包括：搜索代理，用于接收来自用户客户端的查询条件，根据所述查询请求定位查询对象，并根据所述定位，将查询请求发送至网络统一存储实体；还用于将来自网络统一存储实体的媒体内容摘要信息转发至用户客户端；

则所述网络统一存储实体用于查找符合来自搜索代理的查询条件的媒体内容，向搜索代理返回符合所述查询条件的媒体内容的摘要信息。

17、根据权利要求15所述的消息系统，其特征在于，所述消息系统进一步包括聚合代理，用于接收来自用户客户端的查询请求，判断所述查询请求的类型，根据判断结果将所述查询请求发送至搜索代理。

18、根据权利要求17所述的消息系统，其特征在于，所述聚合代理进一步用于接收来自用户客户端的删除/上载请求，判断所述删除/上载请求的类型，根据判断结果将所述删除/上载请求发送至网络统一存储实体。

19、根据权利要求15所述的消息系统，其特征在于，所述网络统一存储实体进一步用于存储历史消息以及历史消息元数据。

20、根据权利要求15所述的消息系统，其特征在于，所述网络统一存储实体进一步包括上载模块，用于接收并存储用户客户端所上载的媒体内容，并生成与所述媒体内容对应的媒体内容元数据。

21、根据权利要求15所述的消息系统，其特征在于，所述网络统一存储实体进一步包括删除模块，用于根据来自用户客户端的删除请求，删除对应的媒体内容，包含媒体内容的历史消息或与包含媒体内容的历史消息属于同一会话的其它历史消息。

22、根据权利要求15至21任一项所述的消息系统，其特征在于，所述网络统一存储实体分布于消息业务服务器和/或后台数据存储设备，并对外提供统一的接口。