一种VOLTE视频电话传输方法及其系统与流程

本发明涉及信息技术领域，特别涉及一种VOLTE视频电话传输方法及其系统。

背景技术：

VOLTE(Voice over LTE，LTE网络视频电话)视频电话业务是4G通信的核心业务之一，也是区别于传统通话服务的一大功能进步，其中，VOLTE一种IP数据传输技术，视频数据使用RTP(Real-time Transport Protocol，实时传输协议)传输，控制信息通过RTCP(RTP Control Protocol，实时传输控制协议)传输，使用SIP(Session Initiation Protocol，会话初始协议)协商视频传输参数。与一般的视频流媒体服务不同的是，视频电话业务的重点在于实时交互性，这就意味着必须严格控制传输延时，不能像流媒体那样建立较长的数据缓冲区，否则会明显影响用户体验。另外由于视频数据对丢包很敏感，如果出现丢包则无法正确解码图像，而图像错误会累积，直到下一个关键帧出现。因此对于VOLTE视频电话业务来说，数据的传输质量对图像效果有直接影响。

目前针对丢包的的处理方式主要分为通过带外信息反馈实现丢包重传，或者直接通过带内信息反馈实现丢包重传。带外重传主要是采用RTP/AVPF(Audio-Visual Profile with Feedback，音视频传输反馈)机制，通过RTCP反馈NACK(非应答)消息，通知发送端重传丢失的数据包。带内重传主要是将反馈信息加入RTP包中，通过视频传输通道反馈给发送端，发送端解析出该信息后重传数据。但是这些方法仍然有局限性：

第一，重传延时过长。对于RTP来说没有明确的丢包指示，通常由接收端进行统计。如果发现数据包超过规定时间仍未收到则判定为丢包，会造成当发现丢包时已经接近或超过该数据包的正常播放时间了，再加上反馈消息等待数据重传，导致视频延时过大(可能达到几秒)；如果一发现数据包序列号错误就立即反馈重传，那么，这样看似可以减少重传延时，但是由于数据包仅仅是乱序而不是丢包，从而产生过多的反馈消息，最终导致发送端发起很多不必要数据重传，反而会造成带宽紧张，进一步产生丢包，最终花费更多的时间在数据重传上。

第二，丢包信息不能可靠地反馈。带外重传使用RTCP，在VOLTE视频电话业务中RTCP带宽需要事先协商，而且通常很低，意味着不能随意发送RTCP消息，实际需要反馈多少信息很难预估，有可能导致RTCP丢包，而丢包信息通常只反馈一次，一旦丢包就会影响重传效果。对于带内重传来说，虽然使用视频通道回传消息不存在带宽问题，但是RTP本身也会丢包，所以反馈消息还是可能因为数据丢包而无法传递到发送端。

第三，系统开销大。无论是带内还是带外反馈，接收端通常仅在出现丢包后反馈信息，所以发送端只能知道接收端丢了哪些数据，而无法得知收到了哪些数据，或已经播放了哪些数据。导致发送端只能尽可能多的把已经发送的视频数据包缓存起来，以保证收到丢包反馈消息时能够重传对应的数据包。但是由于视频码流高、数据量大，大量缓存数据会占用过多系统内存，特别是在嵌入式环境中内存容量本来就很有限，可能因为内存不足导致运行错误。

技术实现要素：

本发明的目的在于提供一种VOLTE视频电话传输方法及其系统，使得发送端能够及时检查是否丢包，并在丢包时，实现可靠快速的数据重传，降 低总体延时、降低系统开销。

为解决上述技术问题，本发明的实施方式提供了一种VOLTE视频电话传输方法，包含以下步骤：

接收端接收VOLTE视频电话数据包，向发送端发送反馈信息；其中，所述反馈信息为所述数据包的接收状态；所述发送端根据所接收到的反馈信息判断是否存在丢包；如果存在，则重传丢失的数据包。

本发明的实施方式还提供了一种VOLTE视频电话传输系统，包含：接收端和发送端；所述接收端包含：通信模块，用于接收VOLTE视频电话数据包；向发送端发送反馈信息；其中，所述反馈信息为所述数据包的接收状态；所述发送端包含：丢包判定模块，用于根据所接收到的反馈信息判断是否存在丢包；并在判定为存在丢包时，重传丢失的数据包。

本发明实施方式相对于现有技术而言，本发明实施方式相对于现有技术而言，主要区别及效果在于：接收端通过向发送端反馈VOLTE视频电话数据包的接收状态，使发送端快速了解数据包是否发送成功，从而由发送端确定是否存在丢包。即使反馈信息被丢包，也可以通过后续的反馈信息进一步确定是否存在丢包，大大提高丢包判定的可靠性，从而使得本发明实施方式实现可靠快速的数据重传，减少时延，避免增加带宽负担。

另外，在所述向发送端发送反馈信息的步骤中，通过实时传输协议RTP包向所述发送端进行带内反馈。通过RTP包向发送端进行带内反馈，不会占用RTCP传输消息的带宽，也不会影响带内视频码流传输，使得即使频繁发送也不会对现有数据传输造成影响，从而保证发送反馈信息稳定。

另外，所述数据包对应有唯一序列号；在所述向发送端发送反馈信息的步骤中，通过发送已接收数据包的序列号指示所述数据包的接收状态为已接收；在所述判断是否存在丢包的步骤中，如果所述发送端已发送的数据包所对应的序列号不在所接收到的反馈信息中，则判定所述数据包丢失。通过 该步骤，可以使本发明实施方式中的发送端，无需等待接收端的报告，通过判断发送端已发送的数据所对应的序列号在不在所接收到的反馈信息中，实现通过反馈信息自身就能判断数据包是否丢失，进一步降低总体延时。

另外，在所述发送已接收数据包的序列号的步骤中，将需发送的序列号进行编码后再发送；在所述判断是否存在丢包的步骤中，还包含以下子步骤：解码接收到的反馈信息，获得所述状态为已接收状态的数据包对应的序列号。通过该步骤，可以减少反馈信息在RTP扩展包头中所占的数据开销，从而增加本发明实施方式的实用性，有利于本发明实施方式的推广。

另外，在所述发送已接收数据包的序列号的步骤前，还包含以下步骤：检测待发送序列号对应的数据包的播放状态；在所述发送已接收数据包的序列号的步骤中，发送未播放的数据包所对应的序列号。通过该步骤，可以进一步降低反馈信息在RTP扩展包头中所占的数据开销。

另外，所述发送端发送所述VOLTE视频电话数据包时，将所发送的数据包备份至发送端缓存；在所述发送端在接收到所述反馈信息后，还包含以下步骤：所述发送端根据所接收到的反馈信息确定所述接收端已接收到的数据包，将所述接收端已接收到的数据包从所述发送端缓存中释放。通过该步骤，可以使本发明实施方式中的发送端能根据所接收到的反馈信息确定接收端已接收到的数据包，并且将已接收到的数据包从发送端缓存中释放，从而减小了缓存量，降低了系统开销。

附图说明

图1是根据本发明第一实施方式一种VOLTE视频电话传输方法的流程示意图；

图2是根据本发明第二实施方式一种VOLTE视频电话传输方法的流程示意图；

图3是根据本发明第三实施方式一种VOLTE视频电话传输方法的流程示意图；

图4是根据本发明第三实施一种VOLTE视频电话传输方法的丢包重传流程示意图；

图5是根据本发明第四实施方式一种VOLTE视频电话传输系统的方框示意图；

图6是根据本发明第五实施方式一种VOLTE视频电话传输系统的丢包判定模块的方框示意图；

图7是根据本发明第六实施方式一种VOLTE视频电话传输系统的方框示意图；

图8是是根据本发明第一实施方式一种VOLTE视频电话传输方法中反馈消息的格式示意图；

图9是根据本发明第一实施方式一种VOLTE视频电话传输方法中反馈消息的另一种格式示意图；

图10是根据本发明第一实施方式一种VOLTE视频电话传输方法中反馈消息的另一中格式示意图；

图11是是根据本发明第一实施方式一种VOLTE视频电话传输方法中反馈消息的另一中格式示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和 修改，也可以实现本申请各权利要求所要求保护的技术方案。

本发明的第一实施方式涉及一种VOLTE视频电话传输方法。其流程如图1所示，具体如下：

步骤101，接收端接收VOLTE视频电话数据包，向发送端发送反馈信息。

具体而言，接收端接收VOLTE视频电话数据包，可以是VOLTE语音传输和VOLTE视频传输，可以通过实时传输协议RTP包向发送端发送反馈信息。其中，反馈信息为数据包的接收状态。数据包的接收状态，可以有已接收和未收到状态。

值得一提的是，反馈信息的发送频率可以自由控制，不需要每个RTP包都携带反馈信息，可以只在接收端数据缓冲状态发生变化时，向发送端反馈信息。比如说，当接收端新收到数据包，或数据包被播放时，接收端就可以向发送端反馈信息。

在本实施方式中，由于数据包对应有唯一序列号，所以接收端通过发送已接收数据包的序列号指示数据包的接收状态为已接收。

步骤102，发送端根据所接收到的反馈信息判断是否存在丢包。若判断为是，则进入步骤103；若判断为否，则结束本流程。

步骤103，发送端重传丢失的数据包。

具体的说，发送端可以根据接收到的反馈信息，获得状态为已接收状态的数据包对应的序列号，然后根据判断发送端已发送的数据包所对应的序列号是否在所接收到的反馈信息中，判断是否丢包。若判断丢包，发送端重传丢失的数据包。也就是说，反馈信息以RTP包序列号来表示，发送端将接收端已接收的RTP数据区段逐个列出，各个区段之间的空洞区域即为丢包区域。而且，由于是发送端将接收端已接收的RTP数据区段逐个列出来判断是 否丢包，所以当发送端反馈接收端时再次丢包，发送端也可以通过后续消息得知所有的丢包情况，不会因为丢包导致反馈信息遗漏。

比如说，反馈信息可以表示为：Seq0-Seq1，Seq3-Seq4，……。通过这个反馈消息可以得知：由于后续数据包已经接收，Seq1至Seq3之间处于空洞区域，所以Seq1至Seq3之间的数据包可能丢包了，发送端重传Seq1-Seq3的数据包；如果Seq4之后没有其他反馈信息了，则说明接收端尚未接收到Seq4之后的数据包。当发送端重传Seq1-Seq3数据包后，接收到的反馈信息依然为：Seq0-Seq1，Seq3-Seq4，……，那么发送端可以判断传Seq1-Seq3数据包再次丢包，会再次重传Seq1-Seq3数据包，直到根据接收到反馈信息确定Seq1-Seq3数据包被接收端接收为止。

需要说明的是，在本实施方式中，接收端只负责将数据包的接收状态反馈给发送端，不进行是否丢包的判断，而是由发送端根据判断发送端已发送的数据包所对应的序列号是否在所接收到的反馈信息中，判断是否丢包，无需等待接收端的报告，从而可以降低总体延时，控制重传节奏，在不影响正常数据的情况下使接收端尽快收到丢失的数据包，不会造成明显的解码播放延时；而且，不会如接收端那样，数据包只会重传一次，而是根据所接收到的反馈信息确定某数据包丢包后，多次重传，直至确定某数据包已被接收端接收为止，从而能保证丢包信息可靠传达。

较佳的，接收端可以将需发送的序列号进行编码后再发送，发送端会先解码接收到的反馈信息，然后进行丢包判断。其中，反馈信息由RTP扩展包头携带传递。其编码过程如下所示：

反馈消息通过RTP Header Extension传递，RTP Header格式为如图8所示，待将图8中的X比特置位后，可以启用Header Extension，其格式如图9所示。

图9中的defined by profile用于区分不同的RTP Header Extension，该字段可以根据实际使用环境来约定，如果遇到不支持本方法的终端，可以跳过反馈信息，不影响解码；length表明Header Extension的具体长度；header extension为信息具体内容。

在本实施方式中，具体的反馈信息填写在header extension中，格式如图10所示。

图10中的SSRC为发送端RTP数据流的SSRC，以便发送端区分不同的反馈信息；sequence number表示起始RTP包序列号，固定占用16比特；len和delta表示后续的RTP包序列号，长度可变，序列号要成对出现，用来指示一个序列号区段，但区段总数不限；end marker表示序列号区段结束，固定为“11111110”；最后为pad部分(填充0)，以保持32比特对齐。

RTP包序列号为16位无符号数，所以表示一个序列号区段就要占用32比特，为了提高传输效率需要尽量减少反馈信息长度。在实时系统中，缓存的视频包数量不会很大，所以反馈信息中的RTP包序列号通常上集中在一个小范围内，因此只要完整传递第一个序列号值(sequence number字段)，后续仅仅传递序列号增量即可(len和delta字段)。为了进一步压缩数据量，len和delta字段为可变长度。解码时首先从数据流中解码len字段(len应当与end marker区分开)，可以得到delta的比特长度，然后读取该长度数据即为delta，最后根据len和delta的值合成序列号。

len编码规则为：当len为0至6时，直接转换为3比特数据；len为7至16时，先填写3比特前缀“111”,然后跟随n个“1”，最后为“0”，中间“1”的个数与len数值相关。

序列号增量的计算方法为：当len>0时，序列号增量＝1<<(len-1)+delta；当len＝0时，序列号增量＝0。上一个序列号加上当前序列号增量，即可得到当前序列号值。

具体编码如下，序列号增量越小码字越短，大多数情况下RTP包序列号集中在小范围内，因此可以得到较高的传输效率，如下表格1所示。

表格1

例如，如果反馈消息为Seq103-Seq210，Seq212-Seq215，Seq220-Seq240，则用序列号增量表示为：103(起始序列号)、107、2、3、5、20。具体数值和对应码字为：

sequence number＝103，码字＝0000000001100111

len0＝7，delta0＝43，码字＝1110|101011

len1＝2，delta1＝0，码字＝010|0

len2＝2，delta2＝1，码字＝010|1

len3＝3，delta3＝1，码字＝011|01

len4＝5，delta4＝4，码字＝101|0100

消息主体(不包括end marker和pad)共30比特，如果不使用本方法压缩而采用16位序列号传输则需要96比特。完整的RTP Header Extension如图11所示。

当然，在实际应用中，还有其他实现方式，此处不再列举。

通过本实施方式，接收端通过向发送端反馈VOLTE视频电话数据包的 接收状态，使发送端快速了解数据包是否发送成功，从而由发送端确定是否存在丢包。即使反馈信息被丢包，也可以通过后续的反馈信息进一步确定是否存在丢包，大大提高丢包判定的可靠性，从而使得本发明实施方式实现可靠快速的数据重传，减少时延，避免增加带宽负担。

本发明的第二实施方式涉及一种VOLTE视频电话传输方法。第二实施方式与第一实施方式大致相同，主要区别之处在于：如图2所示，在本发明第二实施方式中，接收端增加检测待发送序列号对应的数据包的播放状态，以便只发送未播放的数据包对应的序列号，这样，可以减小接收端发送的序列号的数量，从而减少数据传输量，提高传输效率。

不同之处在于：步骤201，检测待发送序列号对应的数据包的播放状态。

具体而言，接收端可以将数据包的接收状态，分为已接收且已播放的RTP包序列号、未接收到的RTP包序列号、已接收但未播放的RTP包序列号，然后将已接收但未播放的RTP包序列号反馈给发送端，已接收且已播放的RTP包序列号不再反馈给发送端。

本实施方式中的步骤202至204与第一实施方式中的步骤101至103相同，此处不做赘述。

通过本实施方式，可以减小接收端发送的序列号的数量，从而减少数据传输量，提高传输效率，进而提高用户的使用体验。

本发明的第三实施方式涉及一种VOLTE视频电话传输方法。第三实施方式与第二实施方式大致相同，主要区别之处在于：如图3所示，在本发明第三实施方式中，发送端根据所接收到的反馈信息确定接收端已接收到的数据包，然后将这些数据包从发送端缓存中释放，以减小缓存量，降低系统开销。

本实施方式中的步骤301、302与第二实施方式中的步骤201、202相同，此处不做赘述。不同之处在于：

步骤303，发送端根据所接收到的反馈信息确定接收端已接收到的数据包，将接收端已接收到的数据包从发送端缓存中释放。

具体而言，接收端可以将数据包的接收状态，分为已接收且已播放的RTP包序列号、未接收到的RTP包序列号、已接收但未播放的RTP包序列号，然后将已接收但未播放的RTP包序列号反馈给发送端。发送端接收到反馈信息后，可以判断已接收但未播放的RTP包序列号之前的RTP序列号是已接收且已播放的，已接收但未播放的RTP包序列号之后的RTP序列号是未接收到的。由于发送端在发送VOLTE视频电话数据包时，会将所发送的数据包备份至发送端缓存，占用相当大的系统内存，所以将已接收的数据包从发送端缓存中释放，可以减小缓存量，降低系统开销。

举例说明本实施方式丢包重传流程如图4所示：

起始状态，终端A的视频缓存中保存着Seq90至Seq100的数据包，终端B的接收缓存已收到Seq90至Seq99的数据包。

终端A发送Seq100的数据包。

终端B收到Seq100后，反馈已收到Seq90至Seq100的数据包。

终端A收到反馈消息后，从视频缓存中释放Seq90至Seq100的数据包，同时新编码的数据包Seq101加入视频缓存，然后发送Seq101，传输中出现丢包。

终端A将新编码的数据包Seq102加入视频缓存，然后发送Seq102。

终端B收到Seq102后，反馈已收到Seq90至Seq100、Seq102。

终端A收到反馈消息后，发现终端B未收到Seq101，于是重传Seq101，同时已收到的Seq102被释放。

终端B收到Seq101后，反馈已收到Seq90至Seq102。

终端A收到反馈消息后，得知终端B已收到Seq101，然后释放视频缓 存的数据。

本实施方式中的步骤304、305与第二实施方式中的步骤203、204相同，此处不做赘述。

通过本实施方式，发送端能根据所接收到的反馈信息确定接收端已接收到的数据包，并且将已接收到的数据包从发送端缓存中释放，从而减小了缓存量，降低了系统开销，有利于本发明的推广。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包含相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第四实施方式涉及一种VOLTE视频电话传输系统，如图5所示，包含：接收端和发送端。

接收端包含：通信模块，用于接收VOLTE视频电话数据包；还用于向发送端发送反馈信息。在本实施方式中，通信模块通过实时传输协议RTP包向发送端进行带内反馈。其中，反馈信息为数据包的接收状态，通信模块利用RTP扩展包头携带反馈信息，

发送端包含：丢包判定模块，用于根据所接收到的反馈信息判断是否存在丢包；并在判定为存在丢包时，重传丢失的数据包。

值得一提的是，数据包对应有唯一序列号。接收端的通信模块通过发送已接收数据包的序列号指示数据包的接收状态为已接收；发送端的丢包判定模块，在发送端已发送的数据包所对应的序列号不在所接收到的反馈信息中时，判定数据包丢失。

通过本实施方式，增加了本发明实施方式的实用性，有利于在实际应用 中实现，从而有利于本发明实施方式的推广。

不难发现，本实施方式为与第一实施方式相对应的系统实施例，本实施方式可与第一实施方式互相配合实施。第一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一实施方式中。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本发明第五实施方式涉及一种VOLTE视频电话传输系统。第五实施方式与第四实施方式大致相同，主要区别之处在于：通信模块将需发送的序列号进行编码后再发送。并且如图6所示，在本发明第五实施方式中，丢包判定模块进一步包含以下子模块：接收子模块、解码子模块、判定子模块。

接收子模块，用于接收反馈信息；

解码子模块，用于解码接收子模块接收到的反馈信息，获得状态为已接收状态的数据包对应的序列号；

判定子模块，用于根据解码子模块所获得的序列号判断是否存在丢包；并在判定为存在丢包时，重传丢失的数据包。

由于第二实施方式与本实施方式相互对应，因此本实施方式可与第二实施方式互相配合实施。第二实施方式中提到的相关技术细节在本实施方式中依然有效，在第二实施方式中所能达到的技术效果在本实施方式中也同样可以实现，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第二实施方式中。

本发明第六实施方式涉及一种VOLTE视频电话传输系统。第六实施方式与第五实施方式大致相同，主要区别之处在于：如图7所示，发送端包含发送端缓存器。

发送端缓存器，用于在发送端发送VOLTE视频电话数据包时，存储所发送的数据包的备份；还用于在发送端接收到反馈信息时，根据所接收到的反馈信息确定接收端已接收到的数据包，将接收端已接收到的数据包从发送端缓存中释放。

由于第三实施方式与本实施方式相互对应，因此本实施方式可与第三实施方式互相配合实施。第三实施方式中提到的相关技术细节在本实施方式中依然有效，在第三实施方式中所能达到的技术效果在本实施方式中也同样可以实现，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第三实施方式中。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。