CN101771623A - 一种融合ip消息业务中消息和媒体的存储系统及方法 - Google Patents

Abstract

本发明公开了一种融合IP消息业务中消息和媒体的存储系统及方法，存储系统包括会话服务器和存储服务器，所述会话服务器包括会话控制单元和存储操作单元；相应的存储方法为：在用户之间进行基于IP的音频/视频会话过程中，所述各个用户所属的会话服务器的存储操作单元对当前音频/视频会话过程中用户间所交互的连续媒体信息及离散消息分别存储至存储服务器。与现有技术相比，本发明能够在用户交互过程中对并发的离散消息和连续媒体内容同时进行存储，可供用户后续对存储内容进行访问和管理，使用户获得良好的业务体验。

Description

一种融合IP消息业务中消息和媒体的存储系统及方法

技术领域

本发明涉及通信技术领域，尤其涉及一种融合IP消息业务中消息和媒体的存储系统及方法。

背景技术

随着通信技术的发展，人与人之间交互的手段越来越丰富；仅消息类业务在不同时期涌现了多种不同的业务类型以满足用户不同层次的通信需求，这些消息业务包括：短消息业务(Short Message Service，SMS)、多媒体消息业务(MultimediaMessage Service，MMS)和即时消息业务(Instant Messaging，IM)等等。在连续媒体交互方面，随着电信网络IP化的发展趋势，一些基于IP的连续媒体交互也逐渐被更多的用户使用，包括：基于IP的语音通话(Voice over IP，VoIP)、基于蜂窝网络的一键通业务(Push-to-Talk over Cellular，PoC)，以及基于IP的视频通话(Video over IP)等等。这些众多的业务，从用户使用角度、运营商的业务建设和运营的角度，以及网络技术发展的角度，都有进行业务融合的需求。目前开放移动联盟(Open MobileAlliance，OMA)标准组织正在进行融合IP消息业务相关标准的制订。融合的IP消息业务要求用户之间的交互，既可以是文本、图片、动画等离散的多媒体消息，也可以是语音、视频等连续媒体信息；并且这些离散消息和连续媒体信息可以在用户之间交互的同一个会话中并存。

对于历史会话中交互的消息，用户会希望在后期可以进行浏览、编辑、转发等操作；因此对于历史会话中交互的消息，具有进行存储以供后期进行访问和操作的需求。传统的消息存储系统和方法，往往只针对于离散消息(如文本消息、图片、动画、声音等多媒体消息)。例如，对于短消息业务，一般采用在终端上对用户所接收或者发送的短消息进行存储的方法，用户可以在本地的收件箱和发件箱中浏览和处理这些消息；对于多媒体消息业务，运营商往往在网络侧存储用户的多媒体消息，这样如果用户的手机终端不支持多媒体消息业务的话，用户可以通过其它方式，如Web浏览的方式获取自己的多媒体消息；而对于IP消息业务，目前一般只对会话过程中交互的离散消息进行保存，而对于会话过程中的连续媒体信息不能保存，这样便不能满足用户的需要，不能给用户提供良好的业务体验。

发明内容

本发明所要解决的技术问题是提供一种融合IP消息业务中的消息和媒体存储系统，以及一种融合IP消息业务的消息和媒体存储方法，使得在用户交互过程中对并发的离散消息和连续媒体信息同时进行存储，以供用户在会话之后进行浏览等操作。

为解决上述技术问题，本发明是通过以下技术方案实现的：

一种融合IP消息业务中消息和媒体的存储方法，包括：在用户之间进行基于IP的音频/视频会话过程中，所述各个用户所属的会话服务器对当前音频/视频会话过程中用户间所交互的连续媒体信息及离散消息进行分别存储。

其中，所述连续媒体信息为语音信息或视频信息。

其中，所述离散消息为文本、图片、动画或者声音片段。

其中，所述会话服务器存储所述语音信息的方法为：

A、生成音频文件，用以存储当前会话中的语音信息；

B、根据相应的语音压缩算法，对当前会话过程中两个方向的语音媒体流分别进行解码，得到两个方向的语音数据；

C、将所述两个方向的语音数据进行混音，再将混音后的语音数据写入所述音频文件中。

其中，所述会话服务器存储所述视频信息的方法为：

a、生成视频文件，用以存储当前会话中的视频信息；

b、根据相应的语音压缩算法对会话过程中两个方向的语音媒体流分别进行解码，得到两个方向的语音数据；并根据相应的视频编解码算法，对当前会话中位于本会话服务器域内的用户所接收到的视频媒体流进行解码，得到视频数据；

c、将所述两个方向的语音数据进行混音，再将混音后的语音数据与所述视频数据同步写入所述视频文件中。

其中，所述会话服务器在存储所述连续媒体信息及离散消息时，还对该连续媒体信息的相关信息及离散消息的相关信息进行存储；

所述连续媒体信息的相关信息包括：当前呼叫建立信令的Call-ID值、通话双方的用户名、开始时间、通话时长、文件保存路径和文件名；

所述离散消息的相关信息包括：本消息的Call-ID值、发送方/接收方、发送时间、消息类型。

该方法中，在进行音频/视频会话之前，所述用户预先设置存储标识，用以向其所属会话服务器指示是否对其会话过程中交互的连续媒体信息或离散消息进行存储；同时，所述会话服务器根据所述存储标识来判断是否进行存储操作。

一种融合IP消息业务中消息和媒体的存储系统，包括会话服务器和存储服务器，所述会话服务器包括会话控制单元和存储操作单元；

所述会话控制单元，用于对用户间基于IP的音频/视频会话进行控制，对所述用户在会话过程中所交互的连续媒体信息及离散消息进行转发；

所述存储操作单元，用于在所述用户的音频/视频会话过程中，对用户间交互的连续媒体信息及离散消息进行解码并存储至所述存储服务器；

所述存储服务器，用于存储所述连续媒体信息及其相关信息、离散消息及其相关信息。

其中，所述存储服务器包括：

数据库存储单元，用于存储所述用户在会话过程中所交互的连续媒体信息的相关信息及离散消息的相关信息；

文件存储单元，用于存储所述用户在会话过程中所交互的连续媒体信息及离散信息的具体内容。

其中，所述会话服务器还包括用户设置单元，为用户提供访问界面，用以设置交互过程中的连续媒体信息及离散消息的存储标识；

同时，所述存储操作单元还用于根据所述存储标识来判断是否对该用户的当前会话过程中的连续媒体信息或者离散消息进行存储，进而根据判断结果来执行存储操作。

本发明具有以下有益效果：

与现有技术相比，本发明能够在用户交互过程中对并发的离散消息和连续媒体内容同时进行存储，可供用户后续对存储内容进行访问和管理，使用户获得良好的业务体验。

附图说明

图1是本发明的融合IP消息业务中消息和媒体的存储系统的结构示意图；

图2是实施例一中，用户间进行语音通话并交互文本消息时的信令交互示意图；

图3是实施例一中，会话服务器对用户在语音通话过程中交互的语音信息进行存储的方法流程图；

图4是实施例二中，用户间进行视频通话并交互多媒体消息时的信令交互示意图；

图5是实施例二中，会话服务器对用户在视频通话过程中交互的视频信息进行存储的方法流程图。

具体实施方式

下面将结合附图及具体实施例对本发明作进一步详细的描述：

请参阅图1，该图所示为本发明的融合IP消息业务中消息和媒体的存储系统的结构，包括会话服务器和存储服务器，所述会话服务器进一步包括会话控制单元、存储操作单元和用户设置单元，所述存储服务器进一步包括数据库存储单元和文件存储单元；

会话控制单元，用于对用户间基于IP的会话进行控制，对所述用户在会话过程中所交互的连续媒体信息及离散消息进行转发；

存储操作单元，用于在所述用户的会话过程中，对用户间交互的连续媒体信息及离散消息进行解码并存储至所述存储服务器；

数据库存储单元，用于存储所述用户在会话过程中所交互的连续媒体信息的相关信息及离散消息的相关信息，该相关信息包括本消息的发送方和接收方的信息、发送时间、消息ID；

文件存储单元，用于存储所述用户在会话过程中所交互的连续媒体信息及离散信息的具体内容。

请参阅图2，是本发明所述方法的实施例一，是一个经简化的应用环境：U1和U2是两个用户，图中所示会话服务器和存储服务器部署在用户U1所在的域，为用户U1提供会话控制和消息及媒体的存储业务。用户U2与U1既可以在同一个域，此时为U2提供会话控制和消息及媒体的存储业务的服务器与U1是一样的；也可以在不同的域，此时由U2所在域的服务器提供会话控制和消息及媒体的存储业务。

在本实施例中，用户U1首先通过会话服务器发起与U2的语音呼叫，呼叫建立后交换语音媒体，并且该媒体流经过会话服务器；媒体交换开始后，会话服务器查询用户设置单元，判断用户U1是否设置了通话中保存连续媒体信息；如果需要保存则由会话服务器对用户U1发出和收到的语音媒体信息进行保存；通话一段时间后，用户之间进行文本消息交互，类似地，该消息经过会话服务器，由会话服务器保存该文本消息；最后，通话结束，会话服务器把保存的语音文件，以及本次语音通话过程中交互的文本消息保存到存储服务器中。

具体来说，以上交互流程分为以下步骤：

步骤201，用户U1通过SIP协议发起与用户U2的语音呼叫，呼叫控制功能由会话服务器中的会话控制单元完成；其中通过会话描述协议(Session DescriptionProtocol，SDP)协商确定交互的语音媒体的编解码算法；

步骤202，U1和U2之间以步骤201协商的编码算法交互语音媒体流，此双向的媒体流都经过会话服务器；媒体流的传输基于实时传输协议(Real-time TransportProtocol，RTP)；

步骤203，进一步细分为以下子步骤，请参阅图3：

子步骤203.a，媒体交互开始后，会话服务器中的存储操作单元查询用户设置单元获知用户预先设置的媒体存储选项，判断是否对交互的媒体进行存储，如果需要存储则进行以下子步骤，否则转步骤204；

子步骤203.b，存储操作单元生成本次存储的音频文件，文件的命名按照一定的规则进行，例如文件名可以包含与本次通话相关的一些信息；

子步骤203.c，存储操作单元对两个方向的语音媒体流按照前面确定的压缩算法进行解码，分别得到两个方向的语音数据；

子步骤203.d，对解码后的两个方向的语音数据进行混音，并将混音后的语音数据写入子步骤203.b生成的文件；

步骤204，通话一段时间后，用户U1通过SIP MESSAGE发送文本消息给用户U2，作为应答，U2返回200OK；如果是会话内的消息，则MESSAGE消息的Call-ID字段与前述呼叫建立信令的Call-ID取值相同；

步骤205，存储操作单元查询用户预先设置的消息存储选项，判断是否对交互的消息进行存储：如果需要则把MESSAGE的消息体内容存储至文件存储单元，并将该消息的相关信息：Call-ID值、发送/接收方、发送时间、消息类型等存储到数据库存储单元，否则转到下一步骤；

步骤206，用户U1与U2之间通话结束，通过SIP BYE/200OK实现；

步骤207，如果子步骤203.a中对媒体进行了存储，则关闭语音文件并存储到服务器中的文件存储单元；同时记录该文件对应的一些信息：如呼叫建立信令的Call-ID值、通话方用户名、开始时间、通话时长、语音文件保存路径和文件名等，把这些信息作为一条记录保存到数据库存储单元。

以上是实施例一的完整步骤。

用户设置媒体和消息存储选项的时候，可以对连续媒体和离散消息分别设置是否进行存储；设置操作可以在任何时候进行，服务器应该提供接口让用户在客户端进行设置，也可以提供接口使用户能够用WEB的方式进行设置。

存储服务器中的文件存储单元在存储媒体文件的时候，可以对不同的用户设置不同的存储目录，与该用户相关的所有媒体文件都存储在该用户的存储目录下。

在本实施例中，只有一次语音通话和一次文本消息交互作为示例，在实际的应用场景，可能有多次的通话和多次的消息交互，这些通话和消息都具有Call-ID属性，可以据此判断它们是否属于同一个会话。

图4所示的实施例二交互流程与实施例一基本类似，有以下不同之处：

用户之间的通话是视频通话，双向交互的媒体流包括语音媒体和视频媒体；媒体协商的时候要对这两种媒体分别进行协商，进行存储操作的时候同时需要存储这两种类型的媒体。

用户之间交互的是多媒体消息，而非文本消息；多媒体消息交互也需要进行reINVITE媒体协商，然后用MSRP进行传输，对多媒体消息进行存储需要对消息可能携带的图片、动画、音视频片段等同时进行存储。

下面给出实施例二的完整步骤。

步骤401，用户U1通过SIP协议发起与用户U2的视频呼叫，呼叫控制功能由会话服务器中的会话控制单元完成；其中通过会话描述协议(Session DescriptionProtocol，SDP)协商确定交互的语音和视频媒体的编解码算法；

步骤402，U1和U2之间以步骤401协商的编码算法交互语音和视频媒体流，此双向的两种类型媒体流都经过会话服务器；媒体流的传输基于实时传输协议(Real-time Transport Protocol，RTP)；

步骤403，进一步细分为以下子步骤(请参阅图5)：

子步骤403.a，媒体交互开始后，会话服务器中的存储操作单元查询用户设置单元获知用户预先设置的媒体存储选项，判断是否对交互的媒体进行存储：如果需要存储则进行以下子步骤，否则转步骤404；

子步骤403.b，存储操作单元生成本次存储的视频文件，文件的命名按照一定的规则进行，例如文件名可以包含与本次通话相关的一些信息；

子步骤403.c，存储操作单元对两个方向的语音媒体流按照前面确定的语音压缩算法进行解码，分别得到两个方向的语音数据；

子步骤403.d，存储操作单元对用户U1接收的视频媒体流按照前面确定的视频编解码算法进行解码，得到用户U1接收到的视频数据；

子步骤403.e，对解码后的两个方向的语音进行混音，并将混音后的语音数据与用户U1接收到的视频数据同步写入子步骤403.b生成的视频文件；

步骤404，视频通话一段时间后，用户U1准备发送多媒体消息给用户U2，通过SIP reINVITE/200OK/ACK流程进行MSRP的SDP协商；Call-ID字段与前述视频呼叫建立信令的Call-ID取值相同；

步骤405，协商完成后，通过MSRP SEND/200OK交互多媒体消息；

步骤406，存储操作单元查询用户预先设置的消息存储选项，判断是否对交互的多媒体消息进行存储：如果需要则把多媒体消息的文本内容，携带的图片、动画等附件存储到文件存储单元；以及该多媒体消息的相关信息：Call-ID值、发送/接收方、发送时间、消息类型等存储到服务器的数据库存储单元，否则转到下一步骤；

步骤407，用户U1与U2之间视频通话结束，通过SIP BYE/200OK实现；

步骤408，如果子步骤403.a中对连续媒体进行了存储，则关闭视频文件并存储到服务器中的文件存储单元；同时记录该文件对应的一些信息：如呼叫建立信令的Call-ID值、通话方用户名、开始时间、通话时长、文件保存路径和文件名等，把这些信息作为一条记录保存到服务器的数据库存储单元。

同样需要说明的是，在实施例二中，只有一次视频通话和一次多媒体消息交互作为示例；在实际的应用场景，可能有多次的通话和多次的消息交互，这些通话可以是语音或视频通话，消息交互可以是文本或多媒体消息，即两种实施例结合应用的场景。

以上实施例仅用以说明本发明的技术方案而非限制，仅仅参照较佳实施例对本发明进行了详细说明。本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围，均应涵盖在本发明的权利要求范围当中。

Claims (10)

1.一种融合IP消息业务中消息和媒体的存储方法，其特征在于，

在用户之间进行基于IP的音频/视频会话过程中，所述各个用户所属的会话服务器对当前音频/视频会话过程中用户间所交互的连续媒体信息及离散消息进行分别存储。

2.如权利要求1所述的融合IP消息业务中的消息和媒体存储方法，其特征在于，所述连续媒体信息为语音信息或视频信息。

3.如权利要求1所述的融合IP消息业务中消息和媒体的存储方法，其特征在于，所述离散消息为文本、图片、动画或者声音片断。

4.如权利要求2所述的融合IP消息业务中消息和媒体的存储方法，其特征在于，所述会话服务器存储所述语音信息的方法为：

A、生成音频文件，用以存储当前会话中的语音信息；

B、根据相应的语音压缩算法，对当前会话过程中两个方向的语音媒体流分别进行解码，得到两个方向的语音数据；

C、将所述两个方向的语音数据进行混音，再将混音后的语音数据写入所述音频文件中。

5.如权利要求2所述的融合IP消息业务中消息和媒体的存储方法，其特征在于，所述会话服务器存储所述视频信息的方法为：

a、生成视频文件，用以存储当前会话中的视频信息；

b、根据相应的语音压缩算法对会话过程中两个方向的语音媒体流分别进行解码，得到两个方向的语音数据；并根据相应的视频编解码算法，对当前会话中位于本会话服务器域内的用户所接收到的视频媒体流进行解码，得到视频数据；

c、将所述两个方向的语音数据进行混音，再将混音后的语音数据与所述视频数据同步写入所述视频文件中。

6.如权利要求1所述的融合IP消息业务中消息和媒体的存储方法，其特征在于，所述会话服务器在存储所述连续媒体信息及离散消息时，还对该连续媒体信息的相关信息及离散消息的相关信息进行存储；

所述连续媒体信息的相关信息包括：当前呼叫建立信令的Call-ID值、通话双方的用户名、开始时间、通话时长、文件保存路径和文件名；

所述离散消息的相关信息包括：本消息的Call-ID值、发送方/接收方、发送时间、消息类型。

7.如权利要求1所述的融合IP消息业务中消息和媒体的存储方法，其特征在于，该方法中，在进行音频/视频会话之前，所述用户预先设置存储标识，用以向其所属会话服务器指示是否对其会话过程中交互的连续媒体信息或离散消息进行存储；同时，所述会话服务器根据所述存储标识来判断是否进行存储操作。

8.一种融合IP消息业务中消息和媒体的存储系统，包括会话服务器和存储服务器，其特征在于，所述会话服务器包括会话控制单元和存储操作单元；

所述会话控制单元，用于对用户间基于IP的音频/视频会话进行控制，对所述用户在会话过程中所交互的连续媒体信息及离散消息进行转发；

所述存储操作单元，用于在所述用户的音频/视频会话过程中，对用户间交互的连续媒体信息及离散消息进行解码并存储至所述存储服务器；

所述存储服务器，用于存储所述连续媒体信息及其相关信息、离散信息及其相关信息。

9.如权利要求8所述的融合IP消息业务中消息和媒体的存储系统，其特征在于，所述存储服务器包括：

数据库存储单元，用于存储所述用户在会话过程中所交互的连续媒体信息的相关信息及离散消息的相关信息；

文件存储单元，用于存储所述用户在会话过程中所交互的连续媒体信息及离散信息的具体内容。

10.如权利要求8或9所述的融合IP消息业务中消息和媒体的存储系统，其特征在于，所述会话服务器还包括用户设置单元，为用户提供访问界面，用以设置交互过程中的连续媒体信息及离散消息的存储标识；

同时，所述存储操作单元还用于根据所述存储标识来判断是否对该用户的当前会话过程中的连续媒体信息或者离散消息进行存储，进而根据判断结果来执行存储操作。

Images