CN101111006A - 一种群组会话中的媒体传送方法和参与群组会话的客户端 - Google Patents

Abstract

本发明提供了一种群组会话中的媒体传送方法和参与群组会话的客户端。所述方法包括：服务器收到主叫客户端发送传送媒体的请求消息；服务器根据所述传送媒体的请求消息判断需要被叫客户端确认，并向参与群组会话的被叫客户端发送传送媒体的请求消息；被叫客户端确认，服务器向已确认的被叫客户端传送所述媒体。所述客户端包括：用于接收服务器发送的传送媒体的请求消息和根据服务器发送的接收媒体的指示消息接收服务器传送的媒体的输入端；用于根据服务器发送的传送媒体的请求消息判断是否接收媒体的处理单元；用于根据处理单元的判断结果向服务器发送确认接收消息或拒绝接收消息的输出端。利用本发明，可以增加用户体验以及节省网络资源。

Description

一种群组会话中的媒体传送方法和参与群组会话的客户端

技术领域

本发明涉及移动通信领域，尤其涉及一种群组会话中的媒体传送方法和参与群组会话的客户端。

背景技术

无线一键通系统(Push-to-Talk Over Cellular，简称“PoC”)是开放移动联盟(Open Mobile Alliance，简称“OMA”)定义的在分组网络上实现的PTT(Push to Talk)业务，采用分组语音(Voice over IP，简称“VoIP”)技术以及半双工的方式，低成本、高效率地满足客户端的实时通信需求。通过这种业务，客户端可以向单个客户端或群组发起PoC会话，实现一对一或一对多的会话方式。

OMA是基于互联网工程任务组(Internet Engineering Task Force，简称“IETF”)所定义的会话发起协议(Session Initiation Protocol，简称“SIP”)和实时传输协议(Real-Time Transfer Protocol，简称“RTP”)来定义PoC。随着PoC业务的发展，在PoC2.0中出现了新的媒体内容，除了PoC1.0中支持的语音外，这些新的媒体内容还包括视频、图片、文件等。在OMA定义的使能部件中，IM(Instant Message)也涉及在群组中传送文件的问题。PoC和IM采用了相同的传输文件的协议MSRP(Message Session Relay Protocol：消息中继协议)，而语音和视频信息则采用RTP协议传送。

在PoC系统中，通常在发起会话时，协商好各种媒体(包括语音、视频、文件传送等)参数，包括媒体类型、IP地址、端口号、编码方式等等。在会话过程中，客户端申请发言权即传送文件的请求，获得发言权之后即可以发言即传送文件。其中，申请发言权并不是必须的，各系统可以选择性的实现这个功能。在需要申请发言权的情况下，客户端先向服务器提出传送文件请求，获得许可后才可以传送文件；在不需要申请发送权限的情况下，客户端可以直接传送文件，即不需要服务器获得许可。在群组会话过程中，客户端获得传送文件许可之后即可传送文件，文件传送送完毕后传送文件的会话并不马上结束，传送文件会话中的其他客户端可以继续在传送文件的会话中传送文件。

目前，参与PoC群组会话的群组成员传送媒体的方法如图1所示，具体流程如下：

步骤101、PoC群组会话建立，并协商好媒体参数；

步骤102-103、主叫客户端向控制功能服务器发送传送媒体的请求，该请求消息中包含了将要发送的媒体类型；

步骤104、控制功能服务器对收到的请求进行发言权判断；

步骤105-106、若主叫客户端的传送媒体的请求成功，控制功能服务器向主叫客户端发送传送媒体确认消息，允许传送媒体；

步骤107-108、控制功能服务器向被叫客户端发送接收媒体的消息。当然，步骤105-106与107-108之间没有严格的时间顺序，控制功能服务器可以同时向主叫客户端和被叫客户端分别发送消息，也可以分先后发送。

步骤109-112、主叫客户端向被叫客户端传送媒体A。

从上可以看出，在PoC系统中是先协商会话媒体参数，再传送会话内容，会话过程中，可以多次传送，但一旦传送，用户必须接收会话中的信息。实际上，用户参与群组会话并不代表用户就愿意接收所有会话中的文件。用户存在拒绝接收某特定用户发送过来的某个特定内容的需求，如用户A想发送给用户B一首歌，用户B听过这首歌，他于是拒绝接收。另外，因为一个SIP会话中包含了多种媒体，使得一个语音RTP会话可以和多个文件传送的MSRP会话并存，在物理资源一定的情况下，如不对MSRP的会话个数进行限制，必然会导致语音会话质量大幅度下降，从而影响通话质量。因此，现有技术中存在以下缺点：较差的用户体验和网络资源的浪费。

发明内容

本发前提供了一种群组会话中媒体的传送方法，以使在群组会话过程中传送媒体时用户有较好的体验。该方法包括以下步骤：A、服务器收到主叫客户端发送传送媒体的请求消息；B、服务器根据所述传送媒体的请求消息判断需要被叫客户端确认，并向参与群组会话的被叫客户端发送传送媒体的请求消息；C、被叫客户端确认，服务器向已确认的被叫客户端传送所述媒体。

优选的，步骤B之前还应执行：服务器获取所述请求消息中的信息，并利用所述信息与服务器存储的策略进行比较，判断需所述请求需要被叫客户端确认。

优选的，步骤A中所述请求消息携带媒体的描述信息和/或主叫客户端标识和/或群组会话标识，步骤B中服务器根据所述描述信息或主叫客户端标识或群组会话标识判断所述请求需要参与群组会话的被叫客户端确认。

优选的，服务器预定义群组会话中允许传送媒体的个数和正在传送的媒体的个数，步骤B之前还应执行如下步骤：B1：服务器判断正在传送的媒体的个数是否大于群组会话中允许传送媒体的个数，如果是，执行步骤B2，否则执行步骤B；B2、服务器缓存所述请求消息，并且当群组会话中传送的媒体的个数值小于预定义值时执行步骤B。

优选的，服务器预设首次收到被叫客户端确认消息的时间，步骤C之前还应执行：服务器判断在其预设的时间内首次收到被叫客户端的确认消息。优选的，步骤C中被叫客户端回复确认消息后，执行以下步骤：C1、服务器向主叫客户端发送传送媒体的确认响应消息；C2、主叫客户端向服务器传送媒体；C3、服务器向回复确认消息的被叫客户端传送所述媒体。

优选的，步骤C3包括：C31、服务器将所述媒体缓存；C32、服务器将缓存的媒体传送给向服务器回复确认消息的被叫客户端。

优选的，服务器设置媒体的缓存时间，服务器在所述缓存时间内收到被叫客户端的确认消息后，向所述被叫客户端传送所述媒体。

优选的，该方法还包括如下步骤：服务器记录被叫客户端是否接收所述媒体，并将结果传送给主叫客户端。

此外，本发明还提供一种参与群组会话的客户端，其特征在于该客户端包括输入端、处理单元、输出端；所述输入端用于接收服务器发送的传送媒体的请求消息和根据服务器发送的接收媒体的指示消息接收服务器传送的媒体；所述处理单元用于根据服务器发送的传送媒体的请求消息判断是否接收媒体；所述输出端用于根据处理单元的判断结果向服务器发送确认接收消息或拒绝接收消息。

优选的，所述传送媒体的请求消息包括主叫客户端标识和/或群组会话标识和/或媒体描述信息，所述处理单元存储是否接收媒体的策略，并根据请求消息中的主叫客户端标识和/或群组会话标识和/或媒体描述信息与所述策略判断是否接收媒体。

优选的，所述输出端还用于向服务器发送传送媒体的请求消息；所述输入端接收到服务器发送的确认消息后，输出端向服务器传送媒体。

由以上方案可以看出，本发明的有益效果如下：

1)当服务器判断主叫客户端需要传送的媒体需被叫客户端确认是否接收时，由被叫客户端确认是否接收，使被叫客户端只接收所确定的媒体，增加被叫客户端的用户体验；以及服务器只向需要接收的被叫客户端传送所述媒体，从而可以节省网络资源。

2)服务器限制了群组会话中传送媒体的个数，当正在传送的媒体的数值大于群组会话中传送媒体的个数，则拒绝主叫客户端传送媒体的请求或将此请求缓存，从而保证群组会话的质量。

附图说明

1.图1为现有技术中传送媒体的流程图；

2.图2所示为PoC的架构图。

3.图3为本发明提供的传送媒体的流程图；

4.图4为本发明提供的群组会话中传送媒体的具体实施例的流程图；

5.图5为本发明提供的被叫客户端接收媒体的具体实施例的流程图；

6.图6为本发明提供的传送媒体的系统示意图

具体实施方式

下面结合附图和具体实施例对本发明再作进一步详细的说明。

图2所示为PoC的架构图。

从PoC架构图中可以看出，PoC功能部件主要包括PoC客户端、PoC服务器、XML文档管理客户端、PoC XML文档管理服务器。其中PoC服务器可按逻辑划分为控制功能服务器和参与功能服务器，当然这两种逻辑功能服务器也可以同时由一个物理PoC服务器来执行。

在本发明中，主要涉及到了PoC客户端与PoC服务器间的媒体及媒体控制信令流，即媒体发送请求和媒体内容的传送以及应答消息的传送，这些过程均通过客户端和服务器利用PoC-3接口交互完成。

当PoC服务器执行控制功能时，则该服务器为控制功能服务器，媒体发送请求的判断和媒体内容的缓存均在执行控制功能的控制服务器中完成；当PoC服务器执行参与功能时，则该服务器为参与功能服务器，本发明中的参与功能服务器主要是用来中转媒体和媒体控制信令。

如图3所示，本发明所提供在群组会话中的传送媒体的流程如下：

步骤301、主叫客户端向服务器发送发言权请求消息，该消息中还携带所请求的具体媒体类型及即将传送的媒体的描述信息。

步骤302、服务器收到主叫客户端发送的发言权请求消息后，根据请求消息中的媒体描述信息，判断是否需要被叫客户端的确认，如果需要被叫客户端确认则执行步骤303；否则直接执行步骤305；

步骤303、服务器向被叫客户端发送携带媒体的描述信息的媒体传送的请求消息。

步骤304、被叫客户端根据收到的请求消息，判断接收主叫客户端将要传送的文件，并向客户端返回确认消息；

步骤305、服务器向主叫客户端发送发言权确认消息，并向被叫客户端发送接收媒体的指示消息；

步骤306、主叫客户端向被叫客户端传送媒体。

如图4所示，本发明提供的在群组会话中传送媒体的具体实施例，其中群组会话建立，且参与群缓会话的群组成员(即主被叫)可用，其具体的流程如下：

步骤401-402、主叫客户端向控制功能服务器发送媒体请求消息，该消息中携带将要传送的媒体的描述信息(如文件的大小、类型等)。

步骤403，控制功能服务器判断收到主叫客户端的请求消息后的正在传送的媒体的个数值是否大于控制功能服务器的预定义的群组会话中允许的媒体传送的个数值，如果是，顺序执行步骤404-405或执行步骤406，否则直接执行步骤407；

其中，控制功能服务器记录了正在传送的媒体的个数值(简称第一数值)以及群组会话中允许传送的媒体的个数的数值(简称第二数值)，当控制功能服务器收到主叫客户端发送的媒体发言权请求消息时，便将第一数值加1，而如果一个媒体传送完毕，控制功能服务器便将第一数值减1。并且，控制功能服务器预定义了当第一数值大于第二数值时的策略，因此当第一数值大于第二数值时，控制功能服务器根据其自身是否支持媒体发送请求消息的缓存功能，如果控制功能服务器支持请求消息的缓存，则执行步骤404-405；否则执行步骤406。

步骤404-405，控制功能服务器向主叫客户端返回请求失败的消息，即不允许主叫客户端传送媒体，并结束流程。

步骤406、控制功能服务器将主叫客户端的请求消息缓存，并等到群组会话中传送的媒体的个数小于预定义值时，执行步骤407。

步骤407、控制功能服务器设置是否将媒体传送请求发送给被叫客户端确认的策略(例如对文件和图片等需要被叫确认而对于语音则不需要被叫确认等)，并根据主叫的媒体发送请求消息进行判断：1.控制服务器获取主叫客户端的媒体发送请求消息中的用户ID值、会话ID值、媒体类型等信息；2.控制服务器将从请求消息中获取的信息与控制服务器策略相比较；3.控制服务器根据比较结果进行判断。判断是否将该请求消息发送给被叫客户端确认，如果是，执行步骤408；否则直接执行步骤410；

步骤408、控制功能服务器向参与群组会话的其它客户端(被叫客户端)传送媒体请求消息。

其中，控制功能服务器预设收到被叫客户端首次回复同意接收所述媒体的确认消息的时间，以及控制功能服务器设置接收主叫客户端传送的媒体后缓存所述媒体的时间并且为了描述方便，将参与群组会话的接收传送媒体请求消息的客户端统称被叫客户端，而在控制功能服务器预设的首次收到被叫客户端回复同意接收所述媒体的确认消息的时间范围内收到所述确认消息的被叫客户端称为第一类被叫客户端。

在第一类被叫客户端回复确认消息后，在服务器缓存主叫客户端传送的所述媒体的时间范围内回复确认消息的客户端统称为第二类被叫客户端。

超过服务器缓存主叫客户端传送的所述媒体的时间范围向服务器回复确认消息的被叫客户端统称为第三类被叫客户端。

在控制功能服务器预设的首次收到被叫客户端回复同意接收所述媒体的确认消息的时间范围，回复拒绝接收媒体消息的客户端称为第四类被叫客户端。

下面将针对四种不同类型的被叫客户端的流程分别介绍。

一、控制功能服务器在预设时间范围内首次收到被叫客户端的确认消息后，执行以下步骤：

步骤409、第一类被叫客户端判断接收该消息中的媒体，并向控制功能服务器发送确认响应消息；

步骤410、控制功能服务器预设一个时间值，在此时间范围内(从控制功能服务器向被叫客户端传送媒体请求消息开始计算)，控制功能服务器判断收到第一类被叫客户端的确认响应消息；

步骤411-412、控制功能服务器向主叫客户端发送媒体发言权确认响应消息，即同意主叫客户端传送多媒体；

步骤413、控制功能服务器向第一类被叫客户端发送接收媒体发言权的指示消息；当然，该消息也可以与步骤311同时进行；

步骤414-415、主叫客户端向控制功能服务器传送媒体。

步骤416、控制功能服务器将主叫客户端发送过来的媒体缓存，并且设定缓存时间，对于超时缓存的媒体将会被丢弃。

步骤417、控制功能服务器将缓存的媒体分发给向控制功能服务器发送给第一类被叫客户端，并结束流程。

二、服务器没有在预设时间内收到被叫客户端的确认消息或只收到第四类被叫客户端的拒绝消息，执行以下步骤：

步骤409’、第四类被叫客户端判断拒绝接收该消息中的媒体，并向控制功能服务器发送拒绝接收媒体的消息；

当然，被叫客户端并不是必须要向控制功能服务器回复消息，如果客户端不愿接收所述媒体以及没有及时获知控制功能服务器发送的媒体发言权请求消息，还可以不作任何动作。

步骤410’、控制功能服务器预设一个时间值，在此时间范围内(从控制功能服务器向被叫客户端发送媒体发言权请求消息开始计算)，控制功能服务器判断没有收到被叫客户端的确认响应消息，可以是没有收到被叫客户端的任何消息，或只收到第四类被叫客户端的拒绝接收的消息；

步骤411’-412’、控制功能服务器向主叫客户端返回发言权请求失败的消息，并结束该流程。在该流程中，服务器向主叫客户端回复请求失败的消息，主叫客户端就不向服务器发送媒体，从而节省网络资源。

三、控制功能服务器在预设的首次收到被叫客户端回复的确认消息时间内收到第一类被叫客户端的确认消息，并在其设置的缓存主叫客户端传送的媒体的时间范围内收到第二类被叫客户端回复的同意接收所述媒体的确认消息，执行如下步骤：

步骤409”、第二类被叫客户端向控制功能服务器回复确认消息，表示同意接收所述媒体；

步骤410”，控制功能服务器判断该确认响应消息在控制功能服务器缓存媒体的时间范围内。

步骤411”、控制功能服务器向第二类被叫客户端发送接收媒体的指示消息；

步骤412”、控制功能服务器向第二类被叫客户端传送所缓存的媒体并结束流程。

四、控制功能服务器在预设的首次收到被叫客户端回复的确认消息时间内收到第一类被叫客户端的确认消息，但超过了其设置的缓存主叫客户端传送的媒体的时间范围而收到了第三类被叫客户端回复的同意接收所述媒体的确认消息，执行如下步骤：

409，第三类被叫客户端向控制功能服务器回复确认消息，表示同意接收所述媒体；

步骤410，控制功能服务器判断该确认响应消息超过了控制功能服务器缓存媒体的时间范围。

步骤411，控制功能服务器向第三类被叫客户端发送时间超时的指示信息，或不执行任何动作，不再向该被叫客户端发送媒体，并结束流程。

步骤418，当媒体传送流程结束，控制服务器记录记录每个被叫客户端的媒体接收情况，例如被叫是否收到该媒体。

步骤419-420，PoC控制服务器将记录被叫客户端接收情况的报告发送给主叫客户端。

当然，图4所示几种类型的客户端对于是否接收媒体的情况并非在同一会话中同时出现。

如图5所示，本发明提供的被叫客户端接收主叫客户端传送的媒体的具体实施例的流程如下：

步骤501-504、控制功能服务器收到主叫客户端发送的传送媒体的请求消息，并依据该消息判断需要经过参与群组会话的所有其它群组成员确认后，向参与群组会话的所有其它成员的客户端(即：被叫客户端)发送传送媒体的请求消息；

步骤505-506、被叫客户端A(即第一类被叫客户端)同意接收请求消息中描述的媒体，并向控制功能服务器发送确认响应消息，该确认消息可由用户选择发出也可以通过客户端设置自动发出；或者，

步骤506’、第一类被叫客户端的参与功能服务器(即被叫参与功能服务器)根据用户预先设置的策略对控制功能服务器发送来的请求消息进行判断，并自动返回接收该媒体的应答消息；

步骤507-508、控制功能服务器向第一类被叫客户端发送接收媒体的指示消息；

步骤509、控制功能服务器将主叫客户端发送来的媒体缓存起来。

步骤510-511、控制功能服务器向第一类被叫客户端传送媒体。

步骤512-513、被叫客户端X(第二类被叫客户端)同意接收请求消息中描述的媒体，并向控制功能服务器发送确认响应消息，该确认消息可由用户选择发出也可以通过客户端设置自动发出；(当然，此步骤可与步骤510-511同时进行)。

步骤514-515、控制功能服务器向第二类被叫客户端发送接收媒体的指示消息；

步骤516-517、控制功能服务器向被叫客户端X传送媒体，并结束流程。

如果被叫客户端X超过控制功能服务器缓存媒体的时间向控制功能服务器回复确认消息，则被叫客户端X担任前述的第三类被叫客户端的角色，并执行如下流程：

步骤514’-515’、因为控制服务器收到被叫客户端X(即第三类被叫客户端)发来的接收媒体确认消息已经超时，则控制服务器向被叫客户端X返回确认超时指示消息或不执行任何动作，并且不再向被叫客户端X发送媒体，结束流程。

如图6所示，本发明提供的一种传送媒体的系统包括：客户端与服务器。所述客户端包括输入端、输出端和处理单元；

所述输入端用于接收服务器发送的传送媒体的请求消息和根据服务器发送的接收媒体的指示消息接收服务器传送的媒体；其中，所述传送媒体的请求消息包括主叫客户端标识和/或群组会话标识和/或媒体描述信息；

所述处理单元所述处理单元存储是否接收媒体的策略，并根据请求消息中的主叫客户端标识和/或群组会话标识和/或媒体描述信息与所述策略判断是否接收媒体；

所述输出端用于根据处理单元的判断结果向服务器发送确认接收消息或拒绝接收消息。

如果客户端承担的是主叫的角色，所述输出端还用于向服务器发送传送媒体的请求消息；所述输入端接收到服务器发送的确认消息后，输出端向服务器传送媒体。

从以上方案可以看出，本发明通过当服务器判断主叫客户端需要传送的媒体需被叫客户端确认是否接收时，由被叫客户端确认是否接收，使第被叫客户端只接收所确定的媒体，增加被叫客户端的用户体验；以及服务器只向需要接收的被叫客户端传送所述媒体，从而可以节省网络资源。

虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (12)

1.一种群组会话中媒体传送方法，其特征在于该方法包括如下步骤：

A、服务器收到主叫客户端发送传送媒体的请求消息；

B、服务器根据所述传送媒体的请求消息判断需要被叫客户端确认，并向参与群组会话的被叫客户端发送传送媒体的请求消息；

C、被叫客户端确认，服务器向已确认的被叫客户端传送所述媒体。

2.如权利要求1所述的群组会话中媒体传送方法，其特征在于：步骤B之前还应执行：服务器获取所述请求消息中的信息，并利用所述信息与服务器存储的策略进行比较，判断需所述请求需要被叫客户端确认。

3.如权利要求1所述的群组会话中媒体传送方法，其特征在于：步骤A中所述请求消息携带媒体的描述信息和/或主叫客户端标识和/或群组会话标识，步骤B中服务器根据所述描述信息或主叫客户端标识或群组会话标识判断所述请求需要参与群组会话的被叫客户端确认。

4.如权利要求1所述的群组会话中媒体传送方法，其特征在于：服务器预定义群组会话中允许传送媒体的个数和正在传送的媒体的个数，步骤B之前还应执行如下步骤：

B1：服务器判断正在传送的媒体的个数是否大于群组会话中允许传送媒体的个数，如果是，执行步骤B2，否则执行步骤B；

B2、服务器缓存所述请求消息，并且当群组会话中传送的媒体的个数值小于预定义值时执行步骤B。

5.如权利要求1所述的群组会话中媒体传送方法，其特征在于：服务器预设首次收到被叫客户端确认消息的时间，步骤C之前还应执行：服务器判断在其预设的时间内首次收到被叫客户端的确认消息。

6.如权利要求1所述的群组会话中媒体传送方法，其特征在于步骤C中被叫客户端回复确认消息后，执行以下步骤：

C1、服务器向主叫客户端发送传送媒体的确认响应消息；

C2、主叫客户端向服务器传送媒体；

C3、服务器向回复确认消息的被叫客户端传送所述媒体。

7.如权利要求6所述的群组会话中媒体的传送方法，其特征在于步骤C3包括：

C31、服务器将所述媒体缓存；

C32、服务器将缓存的媒体传送给向服务器回复确认消息的被叫客户端。

8.如权利要求7所述的群组会话中媒体的传送方法，其特征在于服务器设置媒体的缓存时间，服务器在所述缓存时间内收到被叫客户端的确认消息后，向所述被叫客户端传送所述媒体。

9.如权利要求1所述的群组会话中媒体的传送方法，其特征在于该方法还包括如下步骤：服务器记录被叫客户端是否接收所述媒体，并将结果传送给主叫客户端。

10.一种参与群组会话的客户端，其特征在于该客户端包括输入端、处理单元、输出端；

所述输入端用于接收服务器发送的传送媒体的请求消息和根据服务器发送的接收媒体的指示消息接收服务器传送的媒体；

所述处理单元用于根据服务器发送的传送媒体的请求消息判断是否接收媒体；

所述输出端用于根据处理单元的判断结果向服务器发送确认接收消息或拒绝接收消息。

11.如权利要求10所述的参与群组会话的客户端，其特征在于所述传送媒体的请求消息包括主叫客户端标识和/或群组会话标识和/或媒体描述信息，所述处理单元存储是否接收媒体的策略，并根据请求消息中的主叫客户端标识和/或群组会话标识和/或媒体描述信息与所述策略判断是否接收媒体。

12.如权利要求10所述的参与群组会话的客户端，其特征在于：

所述输出端还用于向服务器发送传送媒体的请求消息；

所述输入端接收到服务器发送的确认消息后，输出端向服务器传送媒体。

Images