CN110233856A

CN110233856A - 报文处理方法、装置及计算机可读存储介质

Info

Publication number: CN110233856A
Application number: CN201910577471.1A
Authority: CN
Inventors: 丛晓; 杜立召; 杨攀
Original assignee: Beijing Cloud In Faith Network Technology Co Ltd
Current assignee: Beijing Cloud In Faith Network Technology Co Ltd
Priority date: 2019-06-28
Filing date: 2019-06-28
Publication date: 2019-09-13
Anticipated expiration: 2039-06-28
Also published as: CN110233856B

Abstract

本申请实施例提供一种报文处理方法、装置及计算机可读存储介质，涉及音视频实时通信技术领域。其中，报文处理方法包括根据预设时长内接收到的多个RTP报文中的非重传报文判断在该预设时长内进行的报文传输中是否存在丢包问题；当存在丢包问题时，根据所述多个RTP报文中的非重传报文的报文序列号确定第一丢包数，该第一丢包数是指在所述预设时长内进行的报文传输中丢失的RTP报文的数量；反馈携带有所述第一丢包数的第一RTCP报文给第二终端，使得所述第二终端根据所述第一丢包数确定第一发包量，以及根据该第一发包量向所述第一终端发送RTP报文。本申请能够提高计算得到的丢包数的准确性。

Description

报文处理方法、装置及计算机可读存储介质

技术领域

本申请涉及音视频实时通信技术领域，具体而言，涉及一种报文处理方法、装置及计算机可读存储介质。

背景技术

在当今的互联网时代，随着4G(the 4th Generation mobile communicationtechnology，第四代移动通信技术)、5G(the 5th Generation mobile communicationtechnology，第五代移动通信技术)等网络通信技术的不断发展以及智能终端的不断普及，音视频实时业务形态以及音视频实时通信技术也得到了越来越多的重视和发展，但因网络不佳等因素的影响，现有的音视频实时通信过程中依然存在着严重的丢包问题，影响了用户的会话体验。

发明内容

为改善上述问题之一，本申请实施例提供一种报文处理方法、装置及计算机可读存储介质，如下。

一方面，本申请实施例提供一种报文处理方法，应用于部署有Webrtc框架的第一终端，该报文处理方法包括：

根据预设时长内接收到的多个RTP(Real-time Transport Protocol，实时传输协议)报文中的非重传报文判断在该预设时长内进行的报文传输中是否存在丢包问题；

当存在丢包问题时，根据所述多个RTP报文中的非重传报文的报文序列号确定第一丢包数，该第一丢包数是指在所述预设时长内进行的报文传输中丢失的RTP报文的数量；

反馈携带有所述第一丢包数的第一RTCP(Real-timeTransportControlProtocol，实时传输控制协议)报文给第二终端，使得所述第二终端根据所述第一丢包数确定第一发包量，以及根据该第一发包量向所述第一终端发送RTP报文。

在本申请实施例的选择中，所述报文处理方法还包括检测出在所述预设时长内接收到的多个RTP报文中的非重传报文的步骤，该步骤包括：

针对所述预设时长内接收到的每个所述RTP报文，检测该RTP报文的报文头是否包含用于表征RTP报文为重传报文的报文标识信息，若不包含所述报文标识信息，则判定该RTP报文为非重传报文。

在本申请实施例的选择中，所述根据预设时长内接收到的多个RTP报文中的非重传报文判断在该预设时长内进行的报文传输中是否存在丢包问题的步骤，包括：

基于RTP协议中的RTP报文序列号检测所述多个RTP报文中的非重传报文对应的报文序列号之间是否存在序列号缺失，若存在，则判定在所述预设时长内进行的报文传输中存在丢包问题。

在本申请实施例的选择中，所述方法还包括：

接收第三终端反馈的第二RTCP报文，该第二RTCP报文中携带有第二丢包数；

根据已发送RTP报文的数量以及所述第二丢包数计算自身与所述第三终端进行报文传输时的丢包率；

根据所述丢包率确定进行报文发送时的第二发包量，并按照所述第二发包量发送RTP报文给所述第三终端。

在本申请实施例的选择中，所述按照所述第二发包量发送RTP报文给所述第三终端的步骤，包括：

按照所述第二发包量从报文缓存队列中读取相应数量个RTP报文，作为待发送报文发送给所述第三终端，其中，所述相应数量个RTP报文分别对应的各序列号不连续。

在本申请实施例的选择中，所述相应数量个RTP报文分别对应的各序列号之间具有相同步进值。

在本申请实施例的选择中，所述按照所述第二发包量发送RTP报文给所述第三终端的步骤，还包括：

判断读取的所述相应数量个RTP报文中是否存在所述报文缓存队列中缓存的已发送RTP报文；

若存在已发送RTP报文，则将预设的扩展头添加在所述已发送RTP报文的报文头中，其中，所述预设的扩展头中包括用于表征该RTP报文为重传报文的报文标识信息；

将完成扩展头添加的已发送RTP报文以及所述相应数量个RTP报文中除所述已发送RTP报文之外的其他RTP报文共同作为所述待发送报文。

在本申请实施例的选择中，所述方法还包括：

检测所述报文缓存队列中的各所述已发送RTP报文中是否存在缓存时长超过预设值的已发送RTP报文，若存在，则将缓存时长超过预设值的已发送RTP报文从所述报文缓存队列中删除，并将未发送报文添加至所述报文缓存队列中。

另一方面，本申请实施例还提供一种报文处理装置，应用于部署有Webrtc框架的第一终端，所述报文处理装置包括：

丢包判断模块，用于根据预设时长内接收到的多个RTP报文中的非重传报文判断在该预设时长内进行的报文传输中是否存在丢包问题；

丢包数确定模块，用于在存在丢包问题时，根据所述多个RTP报文中的非重传报文的报文序列号确定第一丢包数，该第一丢包数是指在所述预设时长内进行的报文传输中丢失的RTP报文的数量；

丢包数反馈模块，用于反馈携带有所述第一丢包数的第一RTCP报文给第二终端，使得所述第二终端根据所述第一丢包数确定第一发包量，以及根据该第一发包量向所述第一终端发送RTP报文。

又一方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机执行指令，在所述计算机执行指令被调用时可执行上述的报文处理方法。

本申请实施例提供的上述报文处理方法、装置及计算机可读存储介质中，是基于去除接收到的RTP报文中的重传报文来实现报文传输过程中的丢包数的计算，能够有效提高计算得到的丢包数的准确性，进而使得第二终端在根据第一终端反馈的丢包数进行后续RTP报文传输时，能够大幅提高报文传输过程中的抗丢包性能。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的第一终端的方框结构示意图。

图2为本申请实施例提供的报文处理方法的流程示意图。

图3为本申请实施例提供的报文处理方法的另一流程示意图。

图4为图3中所示的步骤S16的子流程示意图。

图标：10-第一终端；11-报文处理装置；110-丢包判断模块；120-丢包数确定模块；130-丢包数反馈模块；12-处理器；13-计算机可读存储介质。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

首先需要说明的是，本申请实施例给出的报文处理方法和装置应用于部署有Webrtc(Web Real-Time Communication，网络实时通信)框架的第一终端。其中，所述Webrtc框架是一种在Web(World WideWeb，全球广域网)应用间进行实时媒体数据通信的技术，更是一种可用于提供视频会议等的核心技术，能够提供如视频会议等场景中的音视频数据的采集、编解码、传输以及展示等功能。此外，所述Webrtc框架还支持如Linux平台、Windows平台、Mac平台、Android平台等跨平台之间的数据通信。实际实施时，可通过在第一终端10等终端设备中的浏览器上集成RTC协议等，使得Web应用之间无需插件支持也能实现点到点之间的实时多媒体数据通信，如音频通信、视频通信等。

但在现有技术中，由于原生WebRTC框架是基于RTX模式实现重传报文的发送，即发送端需要基于原有的SSRC(Synchronization Source，同步源)进行重传报文的简单重传，且接收端只能根据时间戳以及估算的RTT(Round-Trip Time，往返时延)来判断接收到的报文是否为重传报文，使得接收端在计算丢包数时容易将重传报文也统计在接收到报文的总数内，导致计算得到的丢包数准确性差，进而使得基于丢包数确定的报文发送策略也存在抗丢包性能差的问题，尤其在音视频实时通信场景下，严重影响用户体验。对此，本申请实施例提供一种报文处理方法、装置及计算机可读存储介质，以改善前述问题，下面对本申请给出的技术方案进行详细介绍。

如图1所示，为本申请实施例提供的第一终端10的方框结构示意图，该第一终端10可以包括，但不限于报文处理装置11、处理器12和计算机可读存储介质13。其中，所述处理器12和所述计算机可读存储介质13均位于第一终端10中且二者分离设置。然而，应当理解的是，所述计算机可读存储介质13也可以是独立于第一终端10之外，且可以由所述处理器12通过总线接口来访问。可替换地，所述计算机可读存储介质13也可以集成到所述处理器12中，例如，可以是高速缓存和/或通用寄存器。

另外，所述计算机可读存储介质13还用于存储与报文处理装置11对应的计算机可执行程序指令，该计算机可执行程序指令被所述处理器12读取并运行时，能够执行本申请实施例中给出的报文处理方法。

可以理解的是，图1所示的第一终端10的结构仅为示意，所述第一终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。此外，在本实施例中，所述第一终端10可以是，但不限于计算机、手机、IPad、服务器、移动上网设备(MID，Mobile Internet Device)等。应注意的是，下述实施例部分中介绍的第二终端、第三终端可以具有与所述第一终端10相同或相应的组件，如所述第二终端、第三终端中也部署有Webrtc框架等。也就是说，在本申请实施例中，第一、第二、第三并无实际含义，仅仅是用于区分不同应用场景下的终端设备。例如，在音视频实时通信过程中，所述第一终端10可以作为报文传输过程中的接收端，也可以作为报文传输过程中的发送端，另外，所述第一终端10还可以单独与第二终端实现音视频通信，也可以同时与第二终端、第三终端等多个终端实现音视频通信等，本实施例在此不做限制。

进一步地，请结合参阅图2，为本申请实施例提供的一种报文处理方法的流程示意图，该报文处理方法应用于在音视频实时通信场景中作为接收端的第一终端10。所应说明的是，本申请给出的报文处理方法并不以图2以及以下所述的具体顺序为限制。应当理解，本申请所述的报文处理方法中的部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。

步骤S11，根据预设时长内接收到的多个RTP报文中的非重传报文判断在该预设时长内进行的报文传输中是否存在丢包问题，若是，则执行步骤S12，若否，则继续按照当前报文传输方式进行RTC报文的传输。

步骤S12，根据所述多个RTP报文中的非重传报文的报文序列号确定第一丢包数，该第一丢包数是指在所述预设时长内进行的报文传输中丢失的RTP报文的数量。

步骤S13，反馈携带有所述第一丢包数的第一RTCP报文给第二终端，使得所述第二终端根据所述第一丢包数确定第一发包量，以及根据该第一发包量向所述第一终端10发送RTP报文。

上述步骤S11至步骤S13中给出的报文处理方法中，是基于去除接收到的RTP报文中的重传报文来实现报文传输过程中的丢包数的计算，能够有效提高计算得到的丢包数的准确性。

详细地，在执行步骤S11之前，所述报文传输方法还可包括检测出在所述预设时长内接收到的多个RTP报文中的非重传报文的步骤，该步骤可以包括：针对所述预设时长内接收到的每个所述RTP报文，检测该RTP报文的报文头是否包含用于表征RTP报文为重传报文的报文标识信息，若不包含所述报文标识信息，则判定该RTP报文为非重传报文。可选地，所述预设时长可以根据实际需求进行灵活设定，本实施例在此不做限制。在一种实现方式中，所述检测出在所述预设时长内接收到的多个RTP报文中的非重传报文的步骤可通过伪代码“receive_statistics_impl.cc的方法CalculateRtcpStatistics()中rec_since_last+＝retransmitted_packets”实现，本实施例在此不做限制。

另外，所述报文标识信息的实际内容可以根据需求进行灵活设定，例如，所述报文标识信息可以是kRtpExtensionresendpacket等，又例如，所述报文标识信息还可以是1或0，如，当1代表非重传报文时，0代表重传报文。

进一步地，步骤S11和步骤S12中关于如何判断是否存在报文缺失问题以及如何计算第一丢包数的具体实现方式有多种。例如，在本实施例中，由于基于Webrtc框架实现的RTP报文中携带有对应的报文序列号，因此，本实施例中可基于RTP协议中的RTP报文序列号判断在预设时长的报文传输过程中是否存在报文缺失问题。该判断过程可以包括：所述第一终端10基于RTP协议中的RTP报文序列号检测所述多个RTP报文中的非重传报文对应的报文序列号之间是否存在序列号缺失，若存在，则判定在所述预设时长内进行的报文传输中存在丢包问题。

作为一种实施方式，假设所述第二终端在向所述第一终端10发送RTP报文时，各RTP报文携带的序列号为连续的，那么，当所述多个RTP报文中的非重传报文分别对应的序列号为1、2、4、5时，可以看出报文序列号2和报文序列号4不连续，那么可判定所述第一终端10接收到的多个RTP报文中的非重传报文对应的报文序列号之间存在序列号缺失，进而可以判定所述第一终端10接收到的多个RTP报文中的非重传报文中存在报文丢失问题(丢包问题)，同时由于报文序列号2和报文序列号4之间缺失一个序列号3，那么可以确定所述第一丢包数为1。

作为另一种实施方式，假设所述第二终端在向所述第一终端10发送RTP报文时，各RTP报文携带的报文序列号之间是不连续的，且各报文序列号之间的步进值为2，那么，当所述多个RTP报文中的非重传报文分别对应的报文序列号为1、3、7、9、13时，可以看出报文序列号3和报文序列号7之间缺失了序列号5，报文序列号9和报文序列号13之间缺失了报文序列号11，那么可判定所述第一终端10接收到的多个RTP报文中的非重传报文对应的报文序列号之间存在序列号缺失，进而可以判定所述第一终端10接收到的多个RTP报文中的非重传报文中存在丢包问题。同时，由于报文序列号1、3、7、9、13之间总共缺失了5和11这两个报文序列号，因此可以确定所述第一丢包数为2。

进一步地，在Webrtc框架中，所述RTCP报文与所述RTP报文配合使用，一起提供用于音视频实时通信过程中的流量控制和拥塞控制服务，例如，在RTP会话期间，各参与者(如第一终端10)可以周期性地反馈RTCP报文给第二终端，该RTCP报文中携带有已发送的数据包的数量、丢失的数据包的数量(如第一丢包数)等统计资料，使得第二终端可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。

因此，在本实施例中，步骤S13中所述的第二终端在接收到第一终端10反馈的RTCP报文后，可根据自身已发送给第一终端10的RTP报文的数量以及所述RTCP报文中携带的第一丢包数计算自身与所述第一终端10进行报文传输时的丢包率，进而根据所述丢包率确定后续进行报文发送时的第一发包量，并按照所述第一发包量发送RTP报文给所述第三终端，以动态地改变传输速率，提高传输过程中的抗丢包性能。

例如，当所述丢包率(loss_rate)大于10％时，可设置第一发包量(packet_resend_cnt_)等于3；当丢包率大于5％小于等于10％时，可设置第一发包量等于2；当丢包率大于3％小于等于5％时，设置第一发包量等于1；当丢包率小于3％时，设置第一发包量等于0等。

可以理解的是，在所述第二终端根据所述第一丢包数确定所述第一发包量之后，在后续的RTP报文发送过程中，无论待发送的所述RTP报文是否为重传报文或非重传报文，均可根据所述第一发包量发送RTP报文给所述第一终端10。在另一种实现方式中，也可以只有在待发送的RTP报文为重传报文时才采用第一发包量进行发送，本实施例在此不做限制。

进一步地，根据实际需求，由于在音视频实时通信过程中，相互通信的两个终端既可以作为接收端也可以作为发送端，因此，在本实施例中，所述第一终端10除作为音视频实时通信过程中的接收端执行上述步骤S11至步骤S13中的报文处理方法之外，还可执行如图3中给出的步骤S14至步骤S16，下面将结合步骤S14至步骤S16对所述第一终端10作为发送端执行报文处理方法的过程进行详细介绍，具体如下。应注意的是，所述第三终端作为接收端所执行的步骤与上述第一终端10作为接收端在步骤S11至步骤S13中所执行的步骤可以相同，也可以不同，例如，所述第三终端作为接收端在确定发包量时的确定过程可以与步骤S11至步骤S13给出的第一发包量的确定过程相同等。上述第二终端作为发送端所执行的步骤与所述第一终端10作为发送端在步骤S14至步骤S16中所述执行的相关步骤也可以相同或不同等，本实施例在此不做限制。

步骤S14，接收第三终端反馈的第二RTCP报文，该第二RTCP报文中携带有第二丢包数。

步骤S15，根据已发送RTP报文的数量以及所述第二丢包数计算自身与所述第三终端进行报文传输时的丢包率。

步骤S16，根据所述丢包率确定进行报文发送时的第二发包量，并按照所述第二发包量发送RTP报文给所述第三终端。

与现有技术相比，上述步骤S14至步骤S16中是根据作为接收端的第三终端反馈的第二丢包数来确定后续进行实时通信时向第三终端发送RTP报文的发包量，从而提高计算得到的丢包率的准确性，并在音视频实时通信过程中实现较优的抗丢包性能。

示例性地，在步骤S14中，所述第二丢包数是所述第三终端根据在预设时长内接收到的所述第一终端10发送的多个RTP报文中的非重传报文确定的，其计算过程与步骤S11至步骤S13中所记载的所述第一丢包数的计算过程类似，因此，本实施例在此不再赘述。此外，需要理解的是，所述第一丢包数与所述第二丢包数中的第一、第二仅仅是为了区分所述丢包数可以是由不同接收端确定并反馈的，并无实际含义。例如，当所述第三终端与所述第二终端相同时，那么，所述第二丢包数与所述第一丢包数相同，又例如，当所述第三终端与所述第二终端不相同时，那么，所述第二丢包数与所述第一丢包数可能不相同，但第一丢包数与第二丢包数的确定方法可以相同。

在步骤S15中，假设在预设时长内，所述第一终端10已发送给所述第三终端的RTP报文的数量为50，而所述第三终端反馈的在预设时长内的第二丢包数为5，那么所述丢包率可以为(5/50＝10％)。其中，所述预设时长可以根据实际需求进行设定，例如，所述预设时长为1分钟、30秒等，本实施例在此不做限制。

在步骤S16中，在根据所述丢包率确定所述第二发包量时，所述第二发包量可以是在RTP报文发送时，需要重发的RTP报文的数量，也可以是重传报文与非重传报文的数量之和，本实施例在此不做限制。

作为一种实施方式，当所述第二发包量为在进行RTP报文发送时需要重发的RTP报文的数量时，那么所述第一终端10在根据所述丢包率确定所述第二发包量时，所述第一终端10中可根据预先设置的丢包率与发包量之间的对应关系确定，例如，在本实施例中，所述第一终端10中可预先设置有如下信息：

(1)当丢包率(loss_rate)大于10％时候，设置第二发包量(packet_resend_cnt_)等于3；(2)当丢包率loss_rate大于5％小于等于10％时，设置packet_resend_cnt_等于2；(3)当丢包率loss_rate大于3％小于等于5％时，设置packet_resend_cnt_等于1；(4)当丢包率loss_rate小于3％时候，设置packet_resend_cnt_等于0。应注意的是，由于所述第一终端10在将RTP报文发送给第三终端后会对已发送的RTP报文进行一定时长的缓存，因此，在所述第一终端10发送RTP报文给第三终端时，可根据重传报文的个数设定不同的发包倍率，packet_resend_cnt_越大，第一终端10中缓存的已发送RTP报文的数量越多，对应重发报文的次数也就越多。

进一步地，在步骤S16中，所述第一终端10在按照所述第二发包量发送RTP报文给所述第三终端的过程可以如图4中所示的步骤S161实现，如下。

步骤S161，按照所述第二发包量从报文缓存队列中读取相应数量个RTP报文，作为待发送报文发送给所述第三终端。

其中，所述相应数量个RTP报文分别对应的各报文序列号之间不连续。例如，所述相应数量个RTP报文分别对应的各报文序列号之间具有不同的步进值或相同的步进值。

作为一种实施方式，假设各报文序列号之间的步进值相同，且步进值为2，那么，各所述报文序列号可以是1、3、5、7……，或2、5、8、11……等，本实施例在此不做限制。

作为另一种实施方式，假设各报文序列号之间的步进值不相同，那么，各所述报文序列号可以是1、3、4、6、7……，或2、3、5、6、8……等，本实施例在此不做限制。

另外，为了改善现有技术中存在作为接收端的所述第三终端无法快速识别接收到的RTP报文是否为重传报文的问题，在本实施例中，所述步骤S16还可以包括如图4所示的步骤S162至步骤S164，具体如下。

步骤S162，判断读取的所述相应数量个RTP报文中是否存在所述报文缓存队列中缓存的已发送RTP报文，若存在已发送RTP报文，则执行步骤S163；反之，则直接将所述待发送报文发送给所述第三终端。

步骤S163，将预设的扩展头添加在所述已发送RTP报文的报文头中，其中，所述预设的扩展头中包括用于表征该RTP报文为重传报文的报文标识信息。

步骤S164，将完成扩展头添加的已发送RTP报文以及相应数量个RTP报文中除所述已发送RTP报文之外的其他RTP报文共同作为所述待发送报文。

实际实施时，所述RTP报文的报文头可以如下表1所示，其中，V代表报文头的版本位，P代表填充位，X代表扩展位，当所述报文头中添加有扩展头时，该扩展位X为1，CC代表计数位，M代表标志位，该标志为可根据实际的RTP协议设定，PT代表负载类型位，SequenccNumber代表报文序列号，TimeStamp代表时间戳，SSRC Identifier用于识别同步源，SSRCIdentifier List用于识别在此RTP报文中的负载的所有共享源。

表1

另外，所述预设的扩展头结构可以如下表2所示，在实际实施时，可将表2中所示的扩展头添加在表1所示的报文头结构之后，以表征对应的RTP报文为重传报文，其中，Headerextension代表扩展头。步骤S164中添加了预设的扩展头后的相关文件可如表3所示。

与现有技术相比，上述步骤S162-S164中给出的报文处理方法中，是通过在RTP报文的报文头中增加用于重传报文识别的扩展头，一方面可使得接收到该RTP报文的终端能够快速、准确地识别其是否为重传报文，避免在进行丢包数的统计时将重传报文统计在内的问题。另一方面，相对于现有技术中在基于RTX模式进行重传报文的发送时，需要在Webrtc框架中额外引入针对RTX通道中的数据进行单独处理的响应模块以及相应的处理模块，势必会破坏Webrtc框架的原有结构，导致实现过程过于复杂，同时还加大了在Webrtc框架版本升级时的代码移植难度。而本申请仅仅是通过在RTP报文的报文头中引入用于表征该RTP报文为重传报文的扩展头(报文标识信息)，便可实现基于非RTX模式下的报文重传，大大降低了实现难度，也不会造成对Webrtc框架原有结构的破坏，还可降低重传报文处理过程中的功耗。

表2

表3

进一步地，由于在报文发送过程中，所述第一终端10中的报文缓存队列中会缓存多个已发送的RTP报文，因此，为了避免由于缓存的已发送RTP报文过多导致资源浪费等问题出现，在本实施例中，可根据已发送RTP报文在报文缓存队列中的缓存时长或者已发送RTP报文是否已进行重发等标准来删除所述缓存队列中的对应报文。

作为一种实施方式，在本实施例中，可将已发送RTP报文的缓存时长作为判断标准来删除所述报文缓存队列中的已发送RTP报文，例如，检测所述报文缓存队列中的各所述已发送RTP报文中是否存在缓存时长超过预设值的已发送RTP报文，若存在，则将缓存时长超过预设值的已发送RTP报文从所述报文缓存队列中删除，并将未发送报文添加至所述报文缓存队列中。其中，所述预设值可根据需求进行设定，如所述预设值可以为1毫秒、5毫秒等。

基于上述步骤S14至步骤S16中给出的报文处理方法，下面以第一终端10为客户端，第三终端为流媒体服务器、第二发包量为重传报文的数量为例，对步骤S14至步骤S16中给出的报文处理方法进行举例说明。

假如所述流媒体服务器反馈给客户端的RTCP报文中携带的第二丢包数为4，所述客户端在预设时长内发送给所述流媒体服务器的已发送RTP报文的数量为50，那么计算得到的丢包率为(4/50＝8％)，也就是说丢包率大于5％，根据该丢包率确定的第二发包量(即重传报文的个数)等于2，所述报文缓冲队列中在预设时长内缓存的已发送RTP报文的序列号SequenceNumber分别为5、6、7、8、9，当发送SequenceNumber为10的RTP报文(未发送报文)时，首先需要进行已发送RTP报文队列检测，移除缓存时长超过预设值的SequenceNumber为5的RTP报文，然后将SequenceNumber为10的未发送报文(RTP报文)添加至报文缓存队列中，并发送一次该SequenceNumber为10的RTP报文，再对SequenceNumber为8、6的已发送的RTP报文进行重传。当发送SequenceNumber为11的音频RTP报文时，可移除SequenceNumber为6的已发送RTP报文，并发送一次SequenceNumber为11的RTP报文，再对SequenceNumber为9、7的音频RTP报文进行重传，依次类推。其中，在进行SequenceNumber为8、6或SequenceNumber为7、9的已发送的RTP报文的重传时，需要对RTP报文的报文头进行扩展，如将预设的扩展头kRtpExtensionAudioResend添加在所述报文头中，以标志所述RTP报文为重传报文。

进一步地，请再次参阅图1，本实施例中给出的报文处理装置11可包括丢包判断模块110、丢包数确定模块120和丢包数反馈模块130。

所述丢包判断模块110，用于根据预设时长内接收到的多个RTP报文中的非重传报文判断在该预设时长内进行的报文传输中是否存在丢包问题；本实施例中，关于所述丢包判断模块110的描述具体可参考上述步骤S11的详细描述，也即，所述步骤S11可以由丢包判断模块110执行，因而在此不作更多说明。

所述丢包数确定模块120，用于在存在丢包问题时，根据所述多个RTP报文中的非重传报文的报文序列号确定第一丢包数，该第一丢包数是指在所述预设时长内进行的报文传输中丢失的RTP报文的数量；本实施例中，关于所述丢包数确定模块120的描述具体可参考上述步骤S12的详细描述，也即，所述步骤S12可以由丢包数确定模块120执行，因而在此不作更多说明。

所述丢包数反馈模块130，用于反馈携带有所述第一丢包数的第一RTCP报文给第二终端，使得所述第二终端根据所述第一丢包数确定第一发包量，以及根据该第一发包量向所述第一终端10发送RTP报文。本实施例中，关于所述丢包数反馈模块130的描述具体可参考上述步骤S13的详细描述，也即，所述步骤S13可以由丢包数反馈模块130执行，因而在此不作更多说明。

综上所述，本申请实施例给出的上述报文处理方法、装置及计算机可读存储介质13中，是基于去除接收到的RTP报文中的重传报文来实现报文传输过程中的丢包数的计算，能够有效提高计算得到的丢包数的准确性。同时，当第二终端在根据第一终端10反馈的丢包数进行后续RTP报文传输时，能够大幅提高报文传输过程中的抗丢包性能。

以上所述，仅为本申请的各种实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims

1.一种报文处理方法，其特征在于，应用于部署有Webrtc框架的第一终端，该报文处理方法包括：

根据预设时长内接收到的多个RTP报文中的非重传报文判断在该预设时长内进行的报文传输中是否存在丢包问题；

反馈携带有所述第一丢包数的第一RTCP报文给第二终端，使得所述第二终端根据所述第一丢包数确定第一发包量，以及根据该第一发包量向所述第一终端发送RTP报文。

2.根据权利要求1所述的报文处理方法，其特征在于，所述报文处理方法还包括检测出在所述预设时长内接收到的多个RTP报文中的非重传报文的步骤，该步骤包括：

3.根据权利要求1所述的报文处理方法，其特征在于，所述根据预设时长内接收到的多个RTP报文中的非重传报文判断在该预设时长内进行的报文传输中是否存在丢包问题的步骤，包括：

4.根据权利要求1所述的报文处理方法，其特征在于，所述方法还包括：

5.根据权利要求4所述的报文处理方法，其特征在于，所述按照所述第二发包量发送RTP报文给所述第三终端的步骤，包括：

6.根据权利要求5所述的报文处理方法，其特征在于，所述相应数量个RTP报文分别对应的各序列号之间具有相同步进值。

7.根据权利要求5所述的报文处理方法，其特征在于，所述按照所述第二发包量发送RTP报文给所述第三终端的步骤，还包括：

8.根据权利要求7所述的报文处理方法，其特征在于，所述方法还包括：

9.一种报文处理装置，其特征在于，应用于部署有Webrtc框架的第一终端，所述报文处理装置包括：

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机执行指令，在所述计算机执行指令被调用时可执行上述权利要求1-8中任意一项所述的报文处理方法。