阅读说明：本技术 视频组呼的丢包重传方法及系统 (Packet loss retransmission method and system for video group call ) 是由 方伟 张光伟 陈国斌 王亮 于 2018-06-29 设计创作，主要内容包括：本发明提供一种视频组呼的丢包重传方法及系统,服务器接收群组中的第一终端发送的视频RTP包,通过组播承载将所述视频RTP包转发给群组中的多个第二终端,并将所述视频RTP包放入重传缓存队列；当第二终端根据接收到的视频RTP包,判断存在丢失的RTP包时,通过单播承载向服务器发送RTCP包,并携带群组号和待重传RTP包的序号,服务器在重传缓存队列中找到所述待重传的RTP包,则通过单播承载向第二终端重发该RTP包；通过上述过程,解决了视频组呼业务中容易出现的数据包丢失的问题,避免了视频组呼中出现花屏、卡顿等现象,提升了用户体验。(The invention provides a packet loss retransmission method and a system of a video group call.A server receives a video RTP packet sent by a first terminal in a group, forwards the video RTP packet to a plurality of second terminals in the group through a multicast bearer, and places the video RTP packet into a retransmission cache queue; when the second terminal judges that a lost RTP packet exists according to the received video RTP packet, an RTCP packet is sent to the server through a unicast bearer and carries a group number and a serial number of the RTP packet to be retransmitted, and the server finds the RTP packet to be retransmitted in a retransmission cache queue and retransmits the RTP packet to the second terminal through the unicast bearer; through the process, the problem that data packets are easy to lose in the video group call service is solved, the phenomena of screen splash, blockage and the like in the video group call are avoided, and the user experience is improved.)

视频组呼的丢包重传方法及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种视频组呼的丢包重传方法及系统。

背景技术

在宽带集群通信(Broadband Trunking Communication，B-Trunc)协议中，定义了视频组呼业务，该业务的工作方式为：一个群组内多个用户之间进行点对多点视频通话，主讲者将视频画面上传给网络侧，网络侧同时给多个接收用户传输相同的视频画面，这种方式可明显降低无线传输带宽消耗。

由于视频实时性要求，视频组呼采用用户数据包协议(User Datagram Protocol，UDP)传输方式，而UDP协议的传输并不可靠，在无线网络质量差时，容易出现数据包丢失，导致视频出现花屏、卡顿等现象，影响用户感知。

发明内容

本发明提供一种视频组呼的丢包重传方法及系统，能够解决视频组呼中容易出现数据包丢失的问题，避免视频组呼中出现花屏、卡顿等现象，提升用户体验。

第一方面，本发明提供的视频组呼的丢包重传方法，应用于服务器，包括：

接收群组中的第一终端发送的视频实时传输协议RTP包，通过组播承载将所述视频RTP包转发给群组中的至少一个第二终端，并将所述视频RTP包放入重传缓存队列；

接收所述第二终端通过单播承载发送的实时传输控制协议RTCP包，对所述RTCP包进行解析得到群组号和待重传的RTP包的序号；

若重传缓存队列中存在所述待重传的RTP包，则通过单播承载向所述第二终端重发对应的RTP包。

可选的，所述将所述视频RTP包放入重传缓存队列之后，还包括：

若所述视频RTP包在所述重传缓存队列中的等待时间超出预设的等待时长，则将所述视频RTP包从所述重传缓存队列中删除。

可选的，所述接收群组中的第一终端发送的视频RTP包之前，还包括：

为群组中的所述至少一个第二终端分别建立一条单播承载。

第二方面，本发明提供的视频组呼的丢包重传方法，应用于第二终端，包括：

接收服务器通过组播承载和/或单播承载发送的视频实时传输协议RTP包；

根据所述视频RTP包的序号，判断是否存在丢失的RTP包；

若存在，则通过单播承载向服务器发送实时传输控制协议RTCP包，所述RTCP包中包括群组号和丢失的RTP包的序号。

可选的，所述向服务器发送RTCP包之前，还包括：

将所述丢失的RTP包的序号放入重传队列；

当重传队列中的RTP包的满足下述条件中的至少一个时，将所述RTP包的序号从所述重传队列中删除：所述RTP包在所述重传队列中的等待时间超出预设的等待时长、所述RTP包对应的请求重传次数超出预设的次数、所述RTP包已被收到。

可选的，所述向服务器发送RTCP包之后，还包括：

若在预设的第二等待时长内，未接收到所述丢失的RTP包，则向服务器重发RTCP包。

第三方面，本发明提供的服务器，包括：

接收模块，用于接收群组中的第一终端发送的视频实时传输协议RTP包；

发送模块，用于通过组播承载将所述视频RTP包转发给群组中的至少一个第二终端；

处理模块，用于将所述视频RTP包放入重传缓存队列；

所述接收模块，还用于接收所述第二终端通过单播承载发送的实时传输控制协议RTCP包；

所述处理模块，还用于对所述RTCP包进行解析得到群组号和待重传的RTP包的序号；

发送模块，还用于若重传缓存队列中存在所述待重传的RTP包，则通过单播承载向所述第二终端重发对应的RTP包。

可选的，所述处理模块，还用于若所述视频RTP包在所述重传缓存队列中的等待时间超出预设的等待时长，则将所述视频RTP包从所述重传缓存队列中删除。

可选的，所述处理模块，还用于为群组中的所述至少一个第二终端分别建立一条单播承载。

第四方面，本发明提供的终端，作为第二终端时，包括：

接收模块，用于接收服务器通过组播承载和/或单播承载发送的视频实时传输协议RTP包；

处理模块，用于根据所述视频RTP包的序号，判断是否存在丢失的RTP包；

发送模块，用于若存在丢失的RTP包，则通过单播承载向服务器发送实时传输控制协议RTCP包，所述RTCP包中包括群组号和丢失的RTP包的序号。

可选的，所述处理模块，还用于将所述丢失的RTP包的序号放入重传队列；

当重传队列中的RTP包的满足下述条件中的至少一个时，将所述RTP包的序号从所述重传队列中删除：所述RTP包在所述重传队列中的等待时间超出预设的等待时长、所述RTP包对应的请求重传次数超出预设的次数、所述RTP包已被收到。

可选的，所述发送模块，还用于若在预设的第二等待时长内，未接收到所述丢失的RTP包，则向服务器重发RTCP包。

第五方面，本发明提供的服务器，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如第一方面任一项所述的方法。

第六方面，本发明提供的终端，作为第二终端时，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如第二方面任一项所述的方法。

第七方面，本发明提供的计算机可读存储介质，其上存储有计算机程序；所述计算机程序被处理器执行，以实现如第一方面任一项所述的方法，或者，如第二方面任一项所述的方法。

第八方面，本发明提供的视频组呼的丢包重传系统，包括如第五方面任一项所述的服务器和至少一个如第六方面任一项所述的终端。

本发明提供的视频组呼的丢包重传方法及系统，服务器接收群组中的第一终端发送的视频RTP包，通过组播承载将所述视频RTP包转发给群组中的多个第二终端，并将所述视频RTP包放入重传缓存队列；当第二终端根据接收到的视频RTP包，判断存在丢失的RTP包时，通过单播承载向服务器发送RTCP包，并携带群组号和待重传RTP包的序号，服务器在重传缓存队列中找到所述待重传的RTP包，则通过单播承载向第二终端重发该RTP包；通过上述过程，解决了视频组呼业务中容易出现的数据包丢失的问题，避免了视频组呼中出现花屏、卡顿等现象，提升了用户体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明提供的视频组呼的丢包重传方法实施例一的流程图；

图2为本发明提供的视频组呼的丢包重传方法实施例二的流程图；

图3为本发明提供的视频组呼的丢包重传方法实施例三的流程图；

图4为本发明实施例三中第二终端判断丢包过程的示意图；

图5为本发明提供的服务器实施例一的结构示意图；

图6为本发明提供的终端实施例一的结构示意图；

图7为本发明提供的服务器实施例二的结构示意图；

图8为本发明提供的终端实施例二的结构示意图；

图9为本发明提供的视频组呼的丢包重传系统实施例的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

如前所述，在B-Trunc协议定义的视频组呼业务中，一个群组内多个用户之间进行点对多点视频通话，主讲者将视频画面上传给网络侧，网络侧同时给多个接收用户传输相同的视频画面，这种方式可明显降低无线传输带宽消耗。

由于视频实时性要求，视频组呼采用UDP传输方式，而UDP协议的传输并不可靠，在无线网络质量差时，容易出现数据包丢失，导致视频出现花屏、卡顿等现象，影响用户感知。

本发明提供一种视频组呼的丢包重传方法及系统，解决了视频组呼中容易出现数据包丢失的问题，避免视频组呼中出现花屏、卡顿等现象，提升用户体验。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

首先，本发明提供的视频组呼的丢包重传方法及系统，可适用于公网或者专网中的集群通信系统中。实际应用中，集群通信系统可以包括终端、基站、核心网以及服务器，终端为用户使用的终端设备，基站可以采用LTE网络，终端通过基站接入核心网中，核心网与服务器连接，由服务器提供媒体分发、话语权控制等业务。需要说明的是，本发明提供的视频组呼的丢包重传方法，主要涉及终端和服务器，其中终端和服务器之间的通信数据可以通过基站与核心网进行转发，本发明实施例对此不作详细描述。

图1为本发明提供的视频组呼的丢包重传方法实施例一的流程图，本实施例的执行主体可以为组呼业务的服务器。如图1所示，本实施例的方法，可以包括：

S11：接收群组中的第一终端发送的视频实时传输协议RTP包，通过组播承载将所述视频RTP包转发给群组中的至少一个第二终端，并将所述视频RTP包放入重传缓存队列。

可以理解的，上述的第一终端和第二终端是根据终端在群组中的角色的不同进行区分，本实施例以及后续实施例中，将群组中的业务发起者对应的终端称为第一终端，将群组中的其他终端称为第二终端，在同一群组中，某个终端可能在某个时间段作为第一终端，而在另一时间段作为第二终端。

在视频组呼业务中，第一终端将视频画面上传给网络侧服务器，网络侧服务器将该视频画面同时转发给该群组中的多个第二终端。其中，第一终端与网络服务器之间为单播承载，第二终端与网络服务器之间为组播承载。并且，终端与网络之间进行通信采用的是实时传输协议(Real-time Transport Protoco，RTP)协议，即视频数据通过RTP包进行传输。

本实施例中，为了解决视频组呼中常见的丢包问题，在服务器侧设置了重传缓存队列。当服务器接收到第一终端发送的视频RTP包后，通过组播承载将所述视频RTP包转发给群组中的多个第二终端，同时，将该视频RTP包放入重传缓存队列中，以备该视频RTP包未被第二终端接收到时，可以将该视频RTP包进行重发。

可以理解的，根据群组设置情况，服务器侧可以同时存在多个重传缓存队列，例如：每个群组对应一个重传缓存队列，所述多个重传缓存队列可以通过群组号进行区别。当然，还可以有其他的设置重传缓存队列的方式，本发明对此并不做具体限定。

可选的，视频RTP包中可以携带群组号、RTP包的序号等信息，其中，群组号用于区分该RTP包中的视频数据对应的群组，由于在组呼业务中，同一个终端有可能同时监听多个群组的消息，在视频RTP包中携带群组号，可以使终端识别出该RTP包对应的群组。另外，在视频RTP包中携带RTP包的序号可以使得终端能够根据该序号判断是否发生丢包。

第二终端通过组播承载接收到视频RTP包后，根据该视频RTP包的序号的连续性，可以判断出是否存在丢失的RTP包。

现有技术中，为了降低终端的功耗，当终端处于监听状态时，终端与网络服务器之间只存在下行的组播承载，终端与网络服务器之间不存在上行的状态反馈通道，使得即使第二终端判断出丢包问题，也无法反馈给网络侧服务器，从而网络侧服务器无法获取各链路的丢包情况。

为了解决该问题，本实施例中网络侧服务器为第二终端还预建立了单播承载，当第二终端判断出现丢失的RTP包时，可以通过单播承载向服务器发送实时传输控制协议(Real-time Transport Control Protocol，RTCP)包，并携带群组号和该丢失的RTP的序号。

其中，每个终端可能会签约多个群组，由于每个视频组呼业务建立时对应的群组号唯一，所以通过在RTCP包中携带群组号可以使得网络侧间接获取到该第二终端当前正在监听的群组。

S12：接收所述第二终端通过单播承载发送的实时传输控制协议RTCP包，对所述RTCP包进行解析得到群组号和待重传的RTP包的序号。

S13：若重传缓存队列中存在所述待重传的RTP包，则通过单播承载向所述第二终端重发对应的RTP包。

网络侧服务器接收到第二终端通过单播承载发送的RTCP包后，解析得到群组号和待重传的RTP包的序号，并根据群组号和待重传的RTP包的序号在对应的重传缓存队列中进行查找，若找到所述待重传的RTP包，则将该RTP包通过单播承载重新发送给第二终端。

本实施例中，服务器接收群组中的第一终端发送的视频RTP包，通过组播承载将所述视频RTP包转发给群组中的多个第二终端，并将所述视频RTP包放入重传缓存队列；当第二终端根据接收到的视频RTP包，判断存在丢失的RTP包时，通过单播承载向服务器发送RTCP包，并携带群组号和待重传RTP包的序号，服务器在重传缓存队列中找到所述待重传的RTP包，则通过单播承载向第二终端重发该RTP包；通过上述过程，解决了视频组呼业务中容易出现的数据包丢失的问题，避免了视频组呼中出现花屏、卡顿等现象，提升了用户体验。

图2为本发明提供的视频组呼的丢包重传方法实施例二的流程图，在上述实施例的基础上，本实施例结合服务器与终端之间交互过程详细描述丢包重传的具体实施方法。如图2所示，本实施例的方法，可以包括：

S21：服务器为群组中的所述至少一个第二终端分别建立一条单播承载。

具体的，当第一终端发起视频组呼业务时，服务器为群组中第二终端建立组播承载时，还可以为每个第二终端建立一条单播承载，该单播承载用于终端向服务器反馈丢包情况，以及服务器向终端重发丢失的数据包。

S22：服务器接收群组中的第一终端发送的视频RTP包，通过组播承载将所述视频RTP包转发给群组中的至少一个第二终端，并将所述视频RTP包放入重传缓存队列，若所述视频RTP包在所述重传缓存队列中的等待时间超出预设的等待时长，则将所述视频RTP包从所述重传缓存队列中删除。

具体的，服务器在将视频RTP包放入重传缓存队列之后，还可以为该视频RTP包启动缓存定时器，并设置缓存定时器的时长为预设的等待时长。当定时器超时后，则将该视频RTP包从重传缓存队列中删除。

另外，如果群组中发生抢权导致第一终端发生变更，则将重传缓存列队中的RTP包清空，并重启缓存定时器。

S23：第二终端接收服务器通过组播承载发送的视频RTP包。

S24：第二终端根据所述视频RTP包的序号，判断是否存在丢失的RTP包；若存在，则通过单播承载向服务器发送RTCP包，所述RTCP包中包括群组号和丢失的RTP包的序号。

具体的，第二终端根据接收到的视频RTP包的序号的连续性，可以判断出是否存在丢失的RTP包。可以理解的，具体的判断方式可以有多种。一种可选的实施方式中，只要接收到的RTP包的序号不连续，则确定存在丢失的RTP包，例如，上一次接收的RTP包的序号为2，当前期望接收的RTP包的序号为3，若接收到了RTP包的序号为5，则确定序号为3和4的RTP包被丢失。另一种可选的实施方式中，当检测到RTP包的序号不连续时，例如：上一次接收的RTP包的序号为2，当前期望接收的RTP包的序号为3，若接收到了RTP包的序号为5，则确定RTP包得序号不连续，再等待一定的时间段，若该时间段内，收到了序号为4的RTP包，但仍然没有收到序号为3的RTP包，则认为序号为3的RTP包丢失。

S25：服务器接收所述第二终端发送的RTCP包，对所述RTCP包进行解析得到群组号和待重传的RTP包的序号；若重传缓存队列中存在对应的RTP包，则通过单播承载向所述第二终端发送对应的RTP包。

其中，重发的RTP包中携带的内容与原始发送的RTP包的内容一样。

S26：第二终端接收服务器通过组播承载和/或单播承载发送的视频RTP包。

第二终端同时从组播承载和单播承载接收视频RTP包，并对接收到的RTP包进行合并排序处理，若有重复的RTP包，则删除。将成功接收的RTP包送往高层进行解码。可以理解的，若合并接收后，还存在丢失的RTP包，还可以重复执行S24-S26。

本实施例中，服务器接收群组中的第一终端发送的视频RTP包，通过组播承载将所述视频RTP包转发给群组中的多个第二终端，并将所述视频RTP包放入重传缓存队列；当第二终端根据接收到的视频RTP包，判断存在丢失的RTP包时，通过单播承载向服务器发送RTCP包，并携带群组号和待重传RTP包的序号，服务器在重传缓存队列中找到所述待重传的RTP包，则通过单播承载向第二终端重发该RTP包；通过上述过程，解决了视频组呼业务中容易出现的数据包丢失的问题，避免了视频组呼中出现花屏、卡顿等现象，提升了用户体验。

图3为本发明提供的视频组呼的丢包重传方法实施例三的流程图，本实施例的执行主体可以为群组中的第二终端，在上述实施例的基础上，本实施例针对第二终端对丢包的检测和控制过程进行详细描述。如图3所示，本实施例的方法，可以包括：

S31：接收服务器通过组播承载和/或单播承载发送的视频RTP包。

S32：根据所述视频RTP包的序号，判断是否存在丢失的RTP包。

S33：若存在，则将所述丢失的RTP包的序号放入重传队列。

图4为本发明实施例三中第二终端判断丢包过程的示意图，结合图4，第二终端对接收到的视频RTP包进行检测，检测机制如下：

记SN为期望接收的RTP包的序号，若SN被成功接收，则SN＝SN+1。假设当前期望接收的RTP包的序号SN未收到，而收到了序号为SN+2的RTP包，记录序号为SN+2的RTP包的接收时间为T(SN+2)。若(当前时间-T(SN+2))大于“RTP丢包门限”，则认为序号SN和SN+1的RTP包丢失，将这些丢失RTP包的序列号放入重传队列，同时将SN+2及之后接收到的顺序RTP包均递交到高层，如图4所示。

经过上述的检测过程，第二终端的重传队列中包括两个RTP包的序号，分别为SN和SN+1。

S34：当重传队列中的RTP包的满足下述条件中的至少一个，将所述RTP包的序号从所述重传队列中删除：所述RTP包在所述重传队列中的等待时间超出预设的等待时长、所述RTP包对应的请求重传次数超出预设的次数、所述RTP包已被收到。

S35：通过单播承载向服务器发送RTCP包，所述RTCP包中包括群组号和丢失的RTP包的序号。

S36：若在预设的第二等待时长内，未接收到所述丢失的RTP包，则向服务器重发RTCP包。

具体的，可以在重传队列中，为每个RTP包的序号，分别记录该RTP包对应的请求重传次数以及放入重传队列的时间。当重传队列中的RTP包在重传队列中的等待时间超出预设的等待时长时，将该RTP包从重传队列中删除。另外，当第二终端向服务器发送RTCP包后，根据RTCP包中携带的丢失的RTP包的序号，更新重传队列中对应的RTP包的请求重传次数，以便当重传队列中的RTP包对应的请求重传次数超出预设的次数时，将该RTP包从重传队列中删除。

需要说明的是，第二终端可以根据网络链路的实际情况，确定是否执行S36，例如，当网络链路状态较好、时延较小的情况下，若向服务器发送RTCP包后，在预设的第二等待时长内，依然未收到丢失的RTP包，则可以向服务器重新重发RTCP包。当网络链路状态较差、时延较大的情况下，则可以不执行S36。

图5为本发明提供的服务器实施例一的结构示意图，如图5所示，本实施例的服务器500，可以包括：接收模块501、处理模块502和发送模块503。

其中，接收模块501，用于接收群组中的第一终端发送的视频实时传输协议RTP包。

发送模块503，用于通过组播承载将所述视频RTP包转发给群组中的至少一个第二终端。

处理模块502，用于将所述视频RTP包放入重传缓存队列。

接收模块501，还用于接收所述第二终端通过单播承载发送的实时传输控制协议RTCP包。

处理模块502，还用于对所述RTCP包进行解析得到群组号和待重传的RTP包的序号。

发送模块503，还用于若重传缓存队列中存在所述待重传的RTP包，则通过单播承载向所述第二终端重发对应的RTP包。

可选的，处理模块502，还用于若所述视频RTP包在所述重传缓存队列中的等待时间超出预设的等待时长，则将所述视频RTP包从所述重传缓存队列中删除。

可选的，处理模块502，还用于为群组中的所述至少一个第二终端分别建立一条单播承载。

本实施例的服务器，可用于执行上述任一方法实施例中服务器侧的技术方案，其实现原理和技术效果类似，此处不再赘述。

图6为本发明提供的终端实施例一的结构示意图，如图6所示，本实施例的终端600，作为第二终端时，可以包括：接收模块601、处理模块602和发送模块603。

其中，接收模块601，用于接收服务器通过组播承载和/或单播承载发送的视频实时传输协议RTP包。

处理模块602，用于根据所述视频RTP包的序号，判断是否存在丢失的RTP包。

发送模块603，用于若存在丢失的RTP包，则通过单播承载向服务器发送实时传输控制协议RTCP包，所述RTCP包中包括群组号和丢失的RTP包的序号。

可选的，处理模块602，还用于将所述丢失的RTP包的序号放入重传队列；当重传队列中的RTP包的满足下述条件中的至少一个时，将所述RTP包的序号从所述重传队列中删除：所述RTP包在所述重传队列中的等待时间超出预设的等待时长、所述RTP包对应的请求重传次数超出预设的次数、所述RTP包已被收到。

可选的，发送模块603，还用于若在预设的第二等待时长内，未接收到所述丢失的RTP包，则向服务器重发RTCP包。

本实施例的终端，可用于执行上述任一方法实施例中的第二终端侧的技术方案，其实现原理和技术效果类似，此处不再赘述。

图7为本发明提供的服务器实施例二的结构示意图，如图7所示，本实施例的服务器700，可以包括：存储器701、处理器702以及计算机程序，其中，所述计算机程序被存储在存储器701中，并被配置为由处理器702执行，可以实现上述任一方法实施例中服务器侧的技术方案，其实现原理和技术效果类似，此处不再赘述。

图8为本发明提供的终端实施例二的结构示意图，如图8所示，本实施例的终端800，可以包括：存储器801、处理器802以及计算机程序，其中，所述计算机程序被存储在存储器801中，并被配置为由处理器802执行，可以实现上述任一方法实施例中第二终端侧的技术方案，其实现原理和技术效果类似，此处不再赘述。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被处理器执行时，可以实现上述任一方法实施例中服务器侧的技术方案，或者实现上述任一方法实施例中第二终端侧的技术方案，其实现原理和技术效果类似，此处不再赘述。

图9为本发明提供的视频组呼的丢包重传系统实施例的结构示意图，如图9所示，本实施例的视频组呼的丢包重传系统900，可以包括：服务器901和至少一个终端902，其中，服务器901可以采用如图7所示的结构，终端902可以采用如图8所示的结构。

本实施例的视频组呼的丢包重传系统，可以实现上述任一方法实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取存储器(英文：Random Access Memory，简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

在上述网络设备或者终端设备的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：ApplicationSpecific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。