CN102170340A - 一种rtp数据超时重发的方法、系统和视频终端 - Google Patents

Abstract

本发明适用于网络传输技术领域，提供了一种RTP数据超时重发的方法、系统和视频终端，所述数据超时重发的方法包括下述步骤：向接收端发送RTP数据组，以使接收端返回RTCP确认消息。判断是否是在预设超时时间内接收到所述RTCP确认消息。当判断未在预设超时时间内接收到所述RTCP确认消息，则重发所述RTP数据组。并删除所述RTP数据组。本发明通过判断是否是在预设超时时间内接收到RTCP确认消息，当判断未在预设超时时间内接收到所述RTCP确认消息，则重发RTP数据组，使得数据丢包的情况下，也可以重发丢包数据，从而媒体数据在网络传输过程中更加稳定可靠。

Description

一种RTP数据超时重发的方法、系统和视频终端

技术领域

本发明属于网络传输技术领域，尤其涉及一种RTP数据超时重发的方法、系统和视频终端。

背景技术

在IP视讯会议系统中实时的视频和音频信息采用承载在UDP协议上的RTP通道进行传输，而RTP不提供任何机制来确保数据按时发送或保证服务的质量，甚至不能保证分组数据的顺序递交，一旦中间传输网络出现点异常，例如网络拥塞、震荡等就会导致接收端接收到的数据产生丢包、乱序、延时等现象，使得接收终端不能解码出流畅声音与图像，出现声音停顿、图像马赛克等现象。

抗网络丢包技术就是为了解决视频会议系统中，媒体数据通过UDP在网络传输过程中产生网络拥塞、震荡导致图像及声音停顿等问题。现有的抗网络丢包技术利用实时传输控制协议RTCP反馈信息提供丢包重发功能，当接收端检测到有丢包时，记录下来丢包信息，通过RTCP确认消息请求发送端重发丢失的数据包，或者利用差错冗余技术重发网络中的丢掉的数据包，以上两种方式在实际处理过程存在不足之处：

1、传输控制协议RTCP反馈信息提供丢包重发功能，在网络传输过程中丢掉RTCP请求对端重发的确认消息，就不能重发网络丢掉的包。

2、利用差错冗余会增加网络带宽，当连续丢两个或两个以上的数据包时就无法恢复丢掉的数据包。

发明内容

本发明实施例的目的在于提供一种RTP数据超时重发的方法，旨在解决现有技术在网络传输过程中如果丢掉RTCP请求对端重发的确认消息，就不能重发网络丢掉的包的问题。

本发明实施例是这样实现的，一种RTP数据超时重发的方法，所述方法包括下述步骤：

向接收端发送RTP数据组，以使接收端返回RTCP确认消息；

判断是否是在预设超时时间内接收到所述RTCP确认消息；

当判断未预设超时时间内接收到所述RTCP确认消息，则重发所述RTP数据组；

删除所述RTP数据组。

本发明实施例还提供了一种RTP数据超时重发的系统，所述系统包括：

发送单元，用于向接收端发送RTP数据组，以使接收端返回RTCP确认消息；

判断单元，用于判断是否是在预设超时时间内接收到所述RTCP确认消息；

重发单元，用于当所述判断单元判断未在预设超时时间内接收到所述RTCP确认消息时，则重发所述RTP数据组；

删除单元，用于删除所述RTP数据组。

本发明实施例还提供了一种视频终端，所述系统包括所述RTP数据超时重发的系统。

在本发明实施例中，发送端通过向接收端发送RTP数据组，以使接收端返回RTCP确认消息，判断是否是在预设超时时间内接收到RTCP确认消息，当判断未在预设超时时间内接收到RTCP确认消息，则重发RTP数据组，并删除本地存储的RTP数据组，使得数据丢包的情况下，也可以重发丢包数据，从而媒体数据在网络传输过程中更加稳定可靠，从而减少由于网络拥塞、震荡导致的图像、声音停顿，即使出现丢掉请求重传的数据包、连续丢包，也能让图像清晰流畅。

附图说明

图1是本发明实施例一提供的RTP数据超时重发的方法的实现流程图；

图2是本发明实施例二提供的RTP数据超时重发的方法的实现流程图；

图3是本发明实施例二提供的RTP数据超时重发的方法的实现示意图；

图4是本发明实施例四提供的数据接收的方法的实现的流程图；

图5是本发明实施例五提供的抗网络丢包的方法的实现的流程图；

图6是本发明实施例六提供的RTP数据超时重发的系统的结构图；

图7是本发明实施例七提供的RTP数据接收的系统的结构图；

图8是本发明实施例八提供的抗网络丢包的系统的结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在本发明实施例中，接收端在接收到一组数据后，给发送端发送接收RTCP确认消息，如果发送端未在预设超时时间内接收到RTCP确认消息，将自动重发该组数据。同时清除本地保留的数据，使得视频会议中的媒体数据在网络传输过程中更加稳定可靠。

本发明实施例提供了一种RTP数据超时重发的方法，所述方法包括下述步骤：

向接收端发送RTP数据组，以使接收端返回RTCP确认消息；

判断是否是在预设超时时间内接收到所述RTCP确认消息；

当判断未预设超时时间内接收到所述RTCP确认消息，则重发所述RTP数据组；

删除所述RTP数据组。

本发明实施例还提供了一种RTP数据超时重发的系统，所述系统包括：

发送单元，用于向接收端发送RTP数据组，以使接收端返回RTCP确认消息；

判断单元，用于判断是否是在预设超时时间内接收到所述RTCP确认消息；

重发单元，用于当所述判断单元判断未在预设超时时间内接收到所述RTCP确认消息，则重发所述RTP数据组；

删除单元，用于删除所述RTP数据组。

本发明实施例还提供了一种视频终端，所述系统包括所述RTP数据超时重发的系统。

在本发明实施例中，发送端通过向接收端发送RTP数据组，以使接收端返回RTCP确认消息，判断是否是在预设超时时间内接收到RTCP确认消息，当判断未在预设超时时间内接收到所述RTCP确认消息，则重发RTP数据组，并删除本地存储的RTP数据组，使得数据丢包的情况下，也可以重发丢包数据，从而媒体数据在网络传输过程中更加稳定可靠，从而减少由于网络拥塞、震荡导致的图像、声音停顿，即使出现丢掉请求重传的数据包、连续丢包，也能让图像清晰流畅。

以下结合具体实施例对本发明的实现进行详细描述：

实施例一

在本发明实施例中，发送端在发送数据之前，首先要确认对方是否支持超时重发，当对方支持超时重发时才启动超时重发机制，向接收端发送RTP数据，启动超时重发过程具体过程为：

A、设置接收端的接收地址。

B、向上述接收地址对应的接收端发送询问是否支持超时重发的信息；

C、在预设时间间隔内，判断是否接收到接收端发送的支持超时重发的RTCP确认消息，是则启动超时重发，否则循环执行N次步骤B，若在执行N此之后仍未收到支持超时重发的RTCP确认消息，则判定接收端不支持超时重发。

在本发明实施例中，预设时间间隔可以为固定时间间隔，也可以为不等间隔，比如依次递增或者依次递减，在此不用以限制本发明。

在本发明实施例中，循环执行的次数N可以根据实际情况设定，在此不用以限制本发明。

在本发明实施例中，以下步骤的具体应用场景可以是基于实时传输协议(Real-time Transport Protocol，RTP)和实时传输控制协议(Real-time TransportControl Protocol，RTCP)的网络媒体流数据传输过程。

图1示出了本发明实施例一提供的RTP数据超时重发的方法的实现流程图，详述如下：

在步骤S101中，向接收端发送RTP数据组，以使接收端返回RTCP确认消息。

在步骤S102中，判断是否是在预设超时时间内接收到RTCP确认消息。

在步骤S103中，当判断未在预设超时时间内接收到RTCP确认消息时，则重发RTP数据组。

在步骤S104中，删除RTP数据组。

在本发明实施例中，上述方法可以是于IP视讯会议系统的发送端发送数据的过程。

在本发明实施例中，发送端通过向接收端发送RTP数据组，以使接收端返回RTCP确认消息，判断是否是在预设超时时间内接收到RTCP确认消息，当判断未在预设超时时间内接收到RTCP确认消息时，则重发RTP数据组，并删除本地存储的RTP数据组，使得数据丢包的情况下，也可以重发丢包数据，从而媒体数据在网络传输过程中更加稳定可靠，从而减少由于网络拥塞、震荡导致的图像、声音停顿，即使出现丢掉请求重传的数据包、连续丢包，也能让图像清晰流畅。

实施例二

图2示出了本发明实施例二提供的RTP数据超时重发的方法的实现流程图，详述如下：

在步骤S201中，向接收端发送RTP数据组，以使接收端返回RTCP确认消息。

在步骤S202中，判断是否是在预设超时时间内接收到RTCP确认消息，是则执行步骤S203，否则执行步骤S205。

在步骤S203中，判断RTCP确认消息中是否包含丢包信息，是则执行步骤S204，否则执行步骤S206。

在步骤S204中，重发RTP数据组中的丢包数据。

在步骤S205中，重发RTP数据组。

在步骤S206中，删除RTP数据组

在本发明实施例中，预设超时时间可以是固定的时间也可以根据网络情况，动态调整预设超时时间。

为了便于理解，以下以具体实现示例进行说明，但不以本实现示例为限，请参阅图3，该过程为在反馈丢包的RTCP确认消息丢掉了，通过超时重发策略重传了丢掉的包，具体为发送数据包1、2、3、4，其中，顺次发送的数据包1、2均被接收端正常接收，而在数据包3发送的过程中，发生了丢包，且发送端发送请求重传数据包3的指令在发送过程中也发丢失了，当4号数据包接收完成时，发送RTCP确认消息在网络传输过程中发生丢包，此时超时重发缓冲区数据已满，判断仍未收到RTCP确认消息，则重发数据包1、2、3、4，提高了传输过程的可靠性。

在本发明实施例中，在预设超时时间内未接收到RTCP确认消息时，将RTP数据组确定为需要重发的数据，重发RTP数据组，当在预设超时时间内接收到RTCP确认消息，则判断RTCP确认消息中是否包含丢包信息，当判断有丢包时，则重发RTP数据组中的丢包数据，使得在没有收到RTCP确认消息和收到RTCP确认消息及RTCP确认消息中包含丢包数据均可以重发相应的数据组中的数据，并删除相应的数据组，提高了系统的稳定性。

实施例三

在本发明实施例中，可以通过调整预设存储的数据包个数动态调整预设超时时间，具体过程为：

如果在超时缓冲区存储的数据包的个数未达到预设存储的数据包个数N之前收到RTCP确认消息，则减小预设存储的数据包个数N以减小预设超时时间；

如果在超时缓冲区存储的数据包的个数达到预设存储的数据包个数N之后仍未收到RTCP确认消息，则增大预设存储的数据包个数N以增加预设超时时间；

其中，MIN＜N＜MAX，MIN为超时缓冲区能够存储的数据包的最小值，MAX为超时缓冲区能够存储的数据包的最大值。

在本发明实施例中，数据包在发送过程中，数据包的帧率、码率等因素决定了一个数据包发送的时间，因而每一数据包发送的平均时间是基本固定的，发送端每发送一个数据包，超时缓冲区会有新的数据包存储，因此可以根据超时缓冲的存储的数据包的个数动态调整预设超时时间，通常，在初始化过程中，根据经验值，为超时缓冲区设定一个预设存储的数据包的个数，这个值通常大于超时缓冲区能够存储的数据包的最小值，小于超时缓冲区能够存储的数据包的最大值。

在本发明实施例中，为了使缓冲区的存储数据包数量适宜，可以通过每次将超时缓冲区预设存储的数据包个数减小M来实现减小预设存储的数据包数目，且减小后数据包的个数N-M＞MIN，可以通过将超时缓冲区预设存储的数据包个数增加M来增大预设存储的数据包数目，且增加后数据包的个数N+M＜MAX。

在本发明实施例中，一组RTP数据发送完成之后，如果在超时缓冲区存储的数据包的个数未达到预设存储的数据包个数N之前收到RTCP确认消息，则将超时缓冲区预设存储的数据包个数减小M，此时超时缓冲区预设存储的数据包个数为N1＝N-M，而下一组RTP数据发送完成之后，如果在超时缓冲区存储的数据包的个数达到预设存储的数据包个数N1之后仍未收到RTCP确认消息，则将超时缓冲区预设存储的数据包个数增大P，此时超时缓冲区预设存储的数据包个数为N2＝N-M+P，依次类推动态调整缓冲区预存储的数据包的个数，方法灵活简单。

本发明实施例中，根据实际网络变化情况，动态调整了缓冲区中实际能够存储的数据包的个数，从而调整动态超时时间，优化了数据传送过程。

实施例四

图4示出本发明实施例四提供的RTP数据接收的方法的实现的流程图，详述如下：

在步骤S401中，判断当前接收的RTP数据之前指定范围内接收的RTP数据组中是否有丢包，当判断有丢包时，执行步骤S402，当判断当无丢包时，执行步骤S403。

在步骤S402中，检查丢包数据中是否含有重排超时包，当检查丢包中含有重排超时包时，执行步骤S404，重排超时包为丢包数据中超过预设确认时间阈值尚未发送RTCP确认消息的数据包。

在步骤S403中，判断接收缓冲区中接收的数据包的个数是否达到RTCP确认消息分组能够存储的最大数据包个数，是则执行步骤S404。

在本发明实施例中，当判断接收缓冲区中接收的数据包的个数未达到RTCP确认消息分组中能够存储的数据包的个数时，则继续接收数据，直到达到最大分组数。

在步骤S404中，发送上述RTP数据组的RTCP确认消息到发送端。

在本发明实施例中，上述方法可以是于IP视讯会议系统的接收端接收数据的过程。

在本发明实施例中，保证在有无数据丢包的情况下均向发送端发送RTCP确认消息，数据传输更加稳定。

实施例五

图5示出本发明实施例五提供的抗网络丢包的方法的实现的流程图，详述如下：

在步骤S501中，发送端向接收端发送RTP数据组，以使接收端返回RTCP确认消息。

在步骤S502中，发送端判断当前接收发送端发送的RTP数据之前指定范围内接收的RTP数据组中是否有丢包。

当接收端判断有丢包时，检查丢包中是否含有重排超时数据包，当检查丢包中含有重排超时数据包时，发送RTCP确认消息到发送端，重排超时数据包为丢包中超过预设确认时间阈值尚未发送RTCP确认消息的数据包。

当接收端判断无丢包时，判断接收缓冲区中接收的数据包的个数是否达到RTCP确认消息分组中能够存储的最大数据包个数，当判断达到RTCP确认消息分组中能够存储的最大数据包个数，发送RTCP确认消息到发送端。

在步骤S503中，发送端根据预设超时时间内RTCP确认消息的接收情况和RTCP确认消息确定需要重发的RTP数据组中的数据，重发确定的需要重发的RTP数据组中的数据。

在步骤S504中，发送端删除RTP数据组。

实施例六

图6示出了本发明实施例六提供的RTP数据超时重发的系统的结构图，为了便于说明，仅示出了与本发明实施例相关的部分，该系统可以是位于视频终端中的软件单元、硬件单元或者软硬结合单元。

在本发明实施例中，具体应用场景可以是实时传输协议(Real-timeTransport Protocol，RTP)和实时传输控制协议(Real-time Transport ControlProtocol，RTCP)的网络媒体流数据传输过程。

该系统包括发送单元61、判断单元62、重发单元63和删除单元64，其中，

发送单元61向接收端发送RTP数据组，以使接收端返回RTCP确认消息。

判断单元62判断是否是在预设超时时间内接收到RTCP确认消息。

当判断单元62判断未在预设超时时间内接收到RTCP确认消息，则重发单元63重发RTP数据组。

在本发明实施例中，当判断单元62判断在预设超时时间内接收到RTCP确认消息，则判断RTCP确认消息中是否包含丢包信息，当判断RTCP确认消息中包含丢包信息时，则重发单元63重发RTP数据组中的丢包数据。

删除单元64删除上述重发单元63发送的RTP数据组。

在本发明实施例中，重发单元63包括通过调整预设存储的数据包个数动态调整预设超时时间的调整模块631，其中，调整模块631还包括第一调整子模块6311和第二调整子模块6312。

如果在超时缓冲区存储的数据包的个数未达到预设存储的数据包个数N之前收到RTCP确认消息，则第一调整子模块6311减小预设存储的数据包个数N以减小预设超时时间；以及

如果在超时缓冲区存储的数据包的个数达到预设存储的数据包个数N之后仍未收到RTCP确认消息，则第二调整子模块6312增大预设存储的数据包个数N以增加预设超时时间。

其中，MIN＜N＜MAX，MIN为超时缓冲区能够存储的数据包的最小值，MAX为超时缓冲区能够存储的数据包的最大值。

在本发明实施例中，发送端发送单元向接收端发送RTP数据组，以使接收端返回RTCP确认消息，判断单元判断是否是在预设超时时间内接收到RTCP确认消息，当判断单元判断未在预设超时时间内接收到RTCP确认消息时，则重发RTP数据组，并由删除单元删除本地存储的RTP数据组，使得数据丢包的情况下，也可以重发丢包数据，从而媒体数据在网络传输过程中更加稳定可靠，从而减少由于网络拥塞、震荡导致的图像、声音停顿，即使出现丢掉请求重传的数据包、连续丢包，也能让图像清晰流畅。

实施例七

图7示出了本发明实施例七提供的RTP数据接收的系统的结构图，为了便于说明，仅示出了与本发明实施例相关的部分，该系统可以是位于视频设备中的软件单元、硬件单元或者软硬结合单元。

在本发明实施例中，该系统具体包括判断单元71和消息发送单元72，其中，

判断单元71判断当前接收的数据之前指定范围内接收的RTP数据中是否有丢包。

当判断单元71判断有丢包时，消息发送单元72检查丢包中是否含有重排超时数据包，当检查丢包中含有重排超时数据包时，发送RTCP确认消息到发送端，重排超时数据包为丢包中超过预设确认时间阈值尚未发送RTCP确认消息的数据包；

当判断单元71判断无丢包时，消息发送单元72判断接收缓冲区中接收的数据包的个数是否达到RTCP确认消息分组中能够存储的最大数据包个数，当判断达到RTCP确认消息分组中能够存储的最大数据包个数，发送RTCP确认消息到发送端。

实施例八

图八示出了本发明实施例八提供的抗网络丢包的系统的结构图，为了便于说明，仅示出了与本发明实施例相关的部分，该系统可以是位于IP视讯会议系统终端中的软件单元，硬件单元或者软硬结合的单元。

系统包括接收端82和发送端81，其中，发送端81包括：

发送单元811向接收端发送RTP数据组，以使接收端返回RTCP确认消息。

判断单元812判断是否是在预设超时时间内接收到RTCP确认消息。

当判断单元812判断未在预设超时时间内接收到RTCP确认消息时，则重发单元813重发RTP数据组。

删除单元814删除本地保留的上述重发的RTP数据组。

接收端82包括：

判断单元821和消息发送单元822，其中，

判断单元821判断当前接收的数据之前指定范围内接收的RTP数据中是否有丢包。

当判断单元821判断有丢包时，消息发送单元822检查丢包中是否含有重排超时数据包，当检查丢包中含有重排超时数据包时，发送RTCP确认消息到发送端，重排超时数据包为丢包中超过预设确认时间阈值尚未发送RTCP确认消息的数据包；

或者当判断单元821判断无丢包时，消息发送单元822判断接收缓冲区中接收的数据包的个数是否达到RTCP确认消息分组中能够存储的最大数据包个数，当判断达到RTCP确认消息分组中能够存储的最大数据包个数，发送RTCP确认消息到发送端。

综上，本发明实施例通过发送端通过向接收端发送RTP数据组，以使接收端返回RTCP确认消息，判断是否是在预设超时时间内接收到RTCP确认消息，当判断未在预设超时时间内接收到RTCP确认消息时，则重发RTP数据组，并删除本地存储的RTP数据组，使得数据丢包的情况下，也可以重发丢包数据，从而媒体数据在网络传输过程中更加稳定可靠，从而减少由于网络拥塞、震荡导致的图像、声音停顿，即使出现丢掉请求重传的数据包、连续丢包，也能让图像清晰流畅。

值得注意的是，上述装置和系统实施例中，所包括的各个单元只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

另外，本领域普通技术人员可以理解实现上述各实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，相应的程序可以存储于一计算机可读取存储介质中，所述的存储介质，如ROM/RAM、磁盘或光盘等。

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

Claims (8)

1.一种RTP数据超时重发的方法，其特征在于，所述方法包括下述步骤：

向接收端发送RTP数据组，以使接收端返回RTCP确认消息；

判断是否是在预设超时时间内接收到所述RTCP确认消息；

当判断未在预设超时时间内接收到所述RTCP确认消息，则重发所述RTP数据组；

删除所述RTP数据组。

2.如权利要求1所述的方法，其特征在于，所述方法还包括下述步骤：

当判断在预设超时时间内接收到所述RTCP确认消息，则判断RTCP确认消息中是否包含丢包信息；

当判断所述RTCP确认消息中包含丢包信息时，则重发所述RTP数据组中的丢包数据。

3.如权利要求1所述的方法，其特征在于，所述方法还包括通过调整预设存储的数据包个数动态调整预设超时时间的步骤，具体为：

如果在超时缓冲区存储的数据包的个数未达到预设存储的数据包个数N之前收到所述RTCP确认消息，则减小所述预设存储的数据包个数N以减小预设超时时间；

如果在超时缓冲区存储的数据包的个数达到预设存储的数据包个数N之后仍未收到所述RTCP确认消息，则增大所述预设存储的数据包个数N以增加预设超时时间；

其中，MIN＜N＜MAX，MIN为超时缓冲区能够存储的数据包的最小值，MAX为超时缓冲区能够存储的数据包的最大值。

4.如权利要求3所述的方法，其特征在于，减小所述预设存储的数据包个数N的步骤具体为：

将所述超时缓冲区预设存储的数据包个数减小M，且减小后数据包的个数N-M＞MIN；

增大所述预设存储的数据包个数N的步骤具体为：

将所述超时缓冲区预设存储的数据包个数增加M，且增加后数据包的个数N+M＜MAX。

5.一种RTP数据超时重发的系统，其特征在于，所述系统包括：

发送单元，用于向接收端发送RTP数据组，以使接收端返回RTCP确认消息；

判断单元，用于判断是否是在预设超时时间内接收到所述RTCP确认消息；

重发单元，用于当所述判断单元判断未在预设超时时间内接收到所述RTCP确认消息时，则重发所述RTP数据组；

删除单元，用于删除所述RTP数据组。

6.如权利要求5所述的系统，其特征在于，所述重发单元还用于，当所述判断单元判断在预设超时时间内接收到所述RTCP确认消息，则判断RTCP确认消息中是否包含丢包信息，当判断所述RTCP确认消息中包含丢包信息时，则重发所述RTP数据组中的丢包数据。

7.如权利要求6所述的系统，其特征在于，所述重发单元还包括：

调整模块，用于通过调整预设存储的数据包个数动态调整预设超时时间；

所述调整模块还包括第一调整子模块，用于如果在超时缓冲区存储的数据包的个数未达到预设存储的数据包个数N之前收到所述RTCP确认消息，则减小所述预设存储的数据包个数N以减小预设超时时间；

所述调整模块还包括第二调整子模块，用于如果在超时缓冲区存储的数据包的个数达到预设存储的数据包个数N之后仍未收到所述RTCP确认消息，则增大所述预设存储的数据包个数N以增加预设超时时间；

其中，MIN＜N＜MAX，MIN为超时缓冲区能够存储的数据包的最小值，MAX为超时缓冲区能够存储的数据包的最大值。

8.一种视频终端，其特征在于，所述视频终端包括权利要求5至7任一权利要求所述的RTP数据超时重发的系统。

Images