专利名称：实现实时传输协议报文冗余机制的方法及其系统的制作方法
技术领域：
本发明涉及通信技术，特别涉及实时传输协议相关的通信技术。
背景技术：
基于网际互连协议(Internet Protocol，简称“IP”)的分组交换网络在近几十年来得到了蓬勃的发展，成为覆盖全球的通信网。IP网络具有低成本等优势，随着通信的发展，包括语音业务在内的传统的电信业务也越来越多地使用IP网络承载，承载实时语音业务的IP网络也称为分组语音(Voice overIP，简称“VoIP”)网络。例如，H.323网络、下一代网络(Next GenerationNetwork，简称“NGN”)和第三代移动通信(The Third Generation，简称“3G”)的分组交换核心网等都是VoIP网络。
VoIP网络可以承载实时性要求较高的业务，例如实时语音、实时视频、实时数据等业务，一般使用实时传输协议(Real-Time Transfer Protocol，简称“RTP”)协议作为实时业务的承载协议。RTP是针对IP网络上多媒体数据流的一个传输协议，在《RTPA Transport Protocol for Real-TimeApplications》(RFC3550)(中文可译为《实时传输协议一种实时应用的传输协议》(请求评注标准3550))中被定义。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和媒体流同步。RTP的典型应用建立在用户数据报协议(User Datagram Protocol，简称“UDP”)上，但也可以在传输控制协议(Transfer Control Protocol，简称“TCP”)或异步传输模式(Asynchronous Transfer Mode，简称“ATM”)等其他协议之上工作。典型的VoIP网络上语音报文格式为物理链路层+IP协议层+UDP协议层+RTP协议层+语音数据。
RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，同时IP网络是面向无连接的不可靠网络，但实时业务又要求网络服务质量(Quality of Service，简称“QoS”)达到一定要求。例如，典型要求为丢包率低于1％、延时低于100毫秒(ms)、网络抖动小于20ms，因此，还需要使用其他技术以保证QoS。在IP网络上承载语音等实时业务时，为减少IP网络中实时业务报文的丢包率，除了优化IP承载网络外，还可以通过冗余机制抵抗网络丢包。本领域的技术人员理解，冗余即为额外传输的除业务信息以外的信息，可以用来抵抗传输中出现的错误，冗余信息在总的传输信息中的比例称为冗余度。
RTP报文冗余机制就是利用RTP业务报文的冗余发送，减少实时业务报文的丢包率。一般情况下，RTP报文冗余机制有两种，它们分别在《RTPPayload for Redundant Audio Data》(RFC2198)中文可译为《支持冗余语音数据的实时传输协议的有效载荷》(请求评注标准2198)和《An RTP PayloadFormat for Generic Forward Error Correction》(RFC2733)中文可译为《一种支持普通前向纠错编码的实时传输协议有效载荷格式》(请求评注标准2733)中定义。
RFC2198定义的冗余机制的基本原理是每个当前RTP报文携带前一个或者前几个RTP报文的内容，当RTP报文丢失时，可以从后续的RTP报文携带的冗余中恢复丢失的RTP报文。例如，在发送时，如果没有冗余包，报文传送序列为RTP1、RTP2、RTP3、RTP4；如果每个RTP报文携带一个冗余包，则报文传送序列为RTP1、RTP2/RTP1、RTP3/RTP2、RTP4/RTP3；如果每个RTP报文携带两个冗余包，则报文传送序列为RTP1、RTP2/RTP1、RTP3/RTP2/RTP1、RTP4/RTP3/RTP2。其中，RTPi表示第i个RTP报文，报文中第一个“/”后的部分称为冗余包，第一个“/”前的部分称为主包。若网络没有丢包，则接收方只把主包作为有效业务报文，丢弃冗余包；若网络有丢包，在每个RTP报文携带一个冗余包情况时，若报文RTP2/RTP1丢失，则接收方会从报文RTP3/RTP2中解出主包RTP2，进行丢包补偿，形成完整的报文序列RTP1、RTP2、RTP3、RTP4。
RFC2733协议定义的冗余机制的基本原理是在发送报文序列中增加携带前向纠错(Forward Error Correction，简称“FEC”)信息的冗余报文，接收方可以使用冗余报文恢复丢失的RTP报文。在具体实现时，可以从媒体数据流中抽取若干个RTP报文，并对它们做异或操作，生成一个包含FEC信息的冗余报文，这个冗余报文可以被接收端用来恢复任何一个用来产生它的RTP报文。例如，没有冗余报文时的报文发送序列为a、b、c、d。携带了FEC冗余信息的报文发送序列为a、b、f(a，b)、c、d、f(c，d)，可以补偿连续一个报文的丢失，其中，f(a，b)是冗余报文，表示报文a和报文b异或的结果。在接收方，如果没有报文丢失，则直接丢弃冗余报文f(a，b)和f(c，d)；如果报文b丢失，则将报文a和报文f(a，b)异或后即可以恢复报文b，从而实现了丢包补偿。如果报文发送序列为a、f(a，b)、b、f(b，c)、c、f(c，d)、d，可以补偿连续两个报文的丢失。在接收方，如果报文b、c丢失，则可以将a和f(a，b)异或恢复b，将b和f(b，c)异或恢复c。
RTP协议和实时传输控制协议(Real-Time Transport Control Protocol，简称“RTCP”)协议一般是配合使用的。RTP协议传送业务报文，RTCP协议用于监控和反馈RTP报文在IP网络上的传输情况。在RTP会话期间，各参与者周期性地传送RTCP报告报文，报文中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。例如，接收方的RTCP报告报文格式如下0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|RC | PT=RR=201 | length|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of packet sender |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_1 (SSRC of first source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1| fraction lost | cumulative number of packets lost |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| extended highest sequence number received |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| interarrival jitter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| last SR (LSR) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| delay since last SR (DLSR) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_2 (SSRC of second source)|block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| profile-specific extensions |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+其中，“cumulative number of packets lost”(中文可译为“累计报文丢失数”)字段表示通话过程中总的丢失报文数；“extended highest sequencenumber received”(中文可译为“扩展的接收最高序列号”)表示这个丢包数统计截至的序列号；“profile-specific extensions”(中文可译为“草案特有的扩展”)表示RTCP协议的可扩展部分。
关于RTCP的详细说明可以参照《RTP Profile for Audio and VideoConferences with Minimal Control》(RFC3551)，中文可译为《支持语音视频会议具有最小控制能力的实时传输协议草案》(请求评注标准3551)。
在双方RTP业务报文相互发送的过程中，一端定时向另一端反馈RTCP报文，另一端可分析出在IP网络上RTP报文的丢包率。在上一个RTCP报文发送周期内的丢包率A＝(当前RTCP报文报告的总的丢失报文数-上一个RTCP报文报告的总的丢失报文数)/(当前RTCP报文报告的序列号-上一个RTCP报文报告的序列号)。其中，RTCP报文报告的总的报文丢失数即为“cumulative number of packets lost”字段的内容，RTCP报文报告的序列号即为“extended highest sequence number received”字段的内容。
现有技术方案实现RTP报文冗余机制时，使用固定的冗余度进行传输。
使用RFC2198定义的RTP冗余机制时，现有技术方案一般是在呼叫建立时确定每个RTP报文携带的冗余包个数即冗余度，呼叫过程中每个报文都携带固定的冗余包个数，发送方确定了冗余包个数后，接收方可以自动识别处理；使用RFC2733定义的RTP冗余机制时，现有技术方案一般在呼叫建立时确定呼叫使用的冗余纠错方式即冗余度，并在呼叫过程中一直使用，发送方确定了冗余纠错方式后，接收方可以自动识别处理。
在实际应用中，上述方案存在以下问题现有技术方案会对网络带宽造成浪费或无法满足业务QoS需求。
造成这种情况的主要原因在于，现有技术方案使用固定冗余度进行传输，而在实际情况中网络传输环境的变化会造成冗余度的富余或不足，冗余度富余会浪费网络带宽，冗余度不足则导致传输的丢包率大于业务丢包门限，从而无法满足业务QoS需求。
例如，以G.711编解码20ms打包为例，不考虑静音检测，不携带冗余包的带宽约为(78字节IP头+160字节语音帧)*50包/秒*8位＝95.2Kbps；如果使用RFC2198的冗余机制，在呼叫建立时，需要每个报文携带一个冗余包才能满足业务的丢包率需求，额外还需要(5字节冗余报文头+160字节冗余帧)*50包/秒*8位＝66Kbps的带宽；如果使用RFC2733的冗余机制，在呼叫建立时，需要使用恢复连续一个报文出错的纠错方法才能满足业务的丢包率需求，每两个业务报文后会产生一个FEC冗余报文，假设冗余报文和业务报文大小相同，则额外还需要95.2Kbps*50％＝47.5Kbps的带宽。但在呼叫进行中，可能由于网络传输环境的好转，不需要额外的冗余即可以满足业务的丢包率需求，此时仍然使用呼叫建立时的冗余度进行传输则会造成带宽的浪费。同样，在呼叫建立时可能不需要使用冗余传输即可以满足，但在呼叫进行中，可能由于网络传输环境的恶化，需要使用冗余才能满足业务的丢包率需求，此时仍然使用呼叫建立时的冗余度进行传输就会造成丢包率过高，无法满足业务QoS需求。
发明内容
有鉴于此，本发明的主要目的在于提供一种实现实时传输协议报文冗余机制的方法及其系统，使得使用RTP冗余机制时既可以避免带宽的浪费也可以满足业务丢包率需求。
为实现上述目的，本发明提供了一种实现实时传输协议报文冗余机制的方法，包含以下步骤A呼叫建立时确定当前业务的最大冗余度、最小冗余度以及丢包门限；C呼叫进行时，统计利用冗余进行丢包补偿后的第一丢包率，并在所述最大冗余度和最小冗余度范围内根据网络传输质量调整实时传输协议报文的冗余度，将该冗余度调整为满足所述第一丢包率小于所述丢包门限条件下的最小值。
其中，在所述步骤A与C之间还包含以下步骤B判断当前业务是否支持动态调整所述实时传输协议报文的冗余度，如果是则进入步骤C，否则使用固定的冗余度进行所述实时传输协议报文的传输。
此外在所述方法中，所述步骤C还包含以下子步骤C1判断第一丢包率是否大于所述丢包门限，如果是则进入步骤C2，否则进入步骤C3；C2在小于等于最大冗余度的前提下增加所述冗余度；
C3在大于等于最小冗余度的前提下减小或维持所述冗余度。
此外在所述方法中，所述步骤C3还包含以下子步骤C31判断不进行丢包补偿的第二丢包率连续小于等于所述丢包门限的次数是否超过阈值，如果是则进入步骤C32，否则进入步骤C33；C32在大于等于最小冗余度的前提下减小所述冗余度；C33维持所述冗余度。
此外在所述方法中，所述步骤C32中，一次性将所述冗余度减小为最小冗余度。
此外在所述方法中，所述步骤C3还包含以下子步骤C34判断不进行丢包补偿的第二丢包率连续小于等于所述丢包门限的次数是否超过阈值，如果是则进入步骤C35，否则进入步骤C36；C35在大于等于所述最小冗余度的前提下减小所述冗余度；C36判断第一丢包率连续小于所述丢包门限的次数是否超过阈值，且当前的所述冗余度是否大于最小冗余度且不为0，且前一次减小所述冗余度后第一丢包率是否没有上升，如果均是则减小所述冗余度，否则维持所述冗余度。
此外在所述方法中，所述步骤C35中，一次性将所述冗余度减小为最小冗余度。
此外在所述方法中，通过实时传输控制协议的扩展部分携带进行丢包补偿后的累计丢包数。
此外在所述方法中，还包含以下步骤E呼叫建立时，使用最小冗余度进行所述实时传输协议报文的传输。
本发明还提供了一种实现实时传输协议报文冗余机制的系统，包含，参数解析模块、丢包率统计模块和冗余度调整模块，其中，所述参数解析模块，用于解析当前业务的最大冗余度、最小冗余度、丢包门限，并输出到所述冗余度调整模块；所述丢包率统计模块，用于统计利用冗余进行丢包补偿后的第一丢包率，并输出到所述冗余度调整模块；所述冗余度调整模块，用于在所述最大冗余度和最小冗余度范围内根据网络传输质量调整实时传输协议报文的冗余度，将该冗余度调整为满足所述第一丢包率小于所述丢包门限条件下的最小值。
通过比较可以发现，本发明的技术方案与现有技术的主要区别在于，在呼叫进行中根据网络传输环境动态调整冗余度。在最大、最小冗余度范围内，将冗余度动态调整为满足进行丢包补偿后的第一丢包率小于丢包门限条件下的最小值。呼叫建立时使用最小冗余度。
这种技术方案上的区别，带来了较为明显的有益效果，即由于本发明方案可以在呼叫过程中动态调整RTP报文的冗余度。首先，可以避免现有技术方案使用固定冗余度时，由于网络传输质量的好转造成的网络带宽被浪费的情况，最大限度的节省了网络的带宽资源；第二，可以避免现有技术方案使用固定冗余度时，由于网络传输质量的恶化造成的业务丢包率上升，无法满足QoS需求的情况，可以最大限度的保证业务QoS需求，提高用户的使用体验；第三，RTP报文冗余度的动态调整和带宽的相应调整，也有效提高了网络带宽的有效利用率，降低了传输成本。
图1是根据本发明第一较佳实施方式的实现RTP报文冗余机制的流程示意图；图2是根据本发明第二较佳实施方式的实现RTP报文冗余机制的流程示意图；图3是根据本发明第四较佳实施方式的实现RTP报文冗余机制的系统结构示意图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。
本发明方案在呼叫过程中根据网络质量动态调整RTP报文冗余度，在满足业务丢包门限的前提下尽量使用低冗余度进行传输。
本发明方案主要包含以下步骤A呼叫建立时确定最大冗余度、最小冗余度当前业务丢包门限；B判断当前业务是否支持冗余度的动态调整，如果是则进入步骤C，否则进入步骤D；C呼叫进行时在满足所述丢包门限的前提下根据网络传输质量调整所述冗余度使其在最大冗余度和最小冗余度范围内尽可能小；D使用介于最大冗余度和最小冗余度之间的固定冗余度进行传输。
为了在呼叫建立时节省网络带宽，本发明方案还在呼叫建立时使用最小冗余度进行传输。
本发明还提供了一种实现RTP报文冗余机制的系统，包含参数解析模块、丢包率统计模块、冗余度调整模块和RTP报文发送模块。冗余度调整模块分别和参数解析模块、丢包率统计模块以及RTP报文发送模块连接。
其中，参数解析模块用于在呼叫建立时解析当前业务的最大冗余度、最小冗余度、丢包门限，并确定当前业务是否支持冗余度动态调整。
丢包率统计模块用于统计利用冗余进行丢包补偿后的第一丢包率和不利用冗余进行丢包补偿的第二丢包率。
冗余度调整模块在不支持冗余度动态调整时输出固定的冗余度；在支持冗余度动态调整时，调整输出的冗余度为满足第一丢包率小于所述丢包门限条件下的最小值。
RTP报文发送模块用于根据所述冗余度调整模块输出的冗余度和当前业务使用的RTP报文冗余机制输出携带了冗余的RTP报文。
为了更好的说明本发明方案，下面结合本发明较佳实施方式和附图进行说明。
根据本发明第一较佳实施方式的实现RTP报文冗余机制的流程如图1所示。该较佳实施方式使用RFC2198定义的冗余机制。
首先进入步骤110，在呼叫建立时，进行参数解析确定最大冗余包个数、最小冗余包个数和当前业务的丢包门限。其中，丢包门限由当前业务的类型决定，一般来说，实时语音、视频业务的丢包门限为1％，实时数据业务的丢包门限为0％，为了便于说明，设丢包门限为C。在本发明第一较佳实施方式中，最大冗余度对应的冗余包个数即为最大冗余包个数，最小冗余度对应的冗余包个数即为最小冗余包个数。
接着进入步骤120，根据最小冗余包个数进行RTP冗余传输。在本发明第一较佳实施方式中，该步骤使得呼叫建立时对于网络带宽资源的消耗降到了最少，但可以理解，也可以使用任何介于最小冗余包个数和最大冗余包个数之间的冗余包个数进行RTP冗余传输。
接着进入步骤130，判断当前业务是否支持动态调整冗余包个数，如果是则进入步骤140，否则进入步骤190。如果当前业务不支持动态调整冗余度，在本发明第一较佳实施方式中，即当前业务不支持动态调整冗余包个数，则在呼叫进行过程中，按照呼叫建立时确定的冗余度也即冗余包个数进行传输。
在步骤140中，估计当前网络利用冗余进行了丢包补偿后的丢包率。当前网络利用冗余进行了丢包补偿后的丢包率可以通过丢包检测协议返回的信息获得，在本发明第一较佳实施方式中，扩充RTCP协议，在“profile-specificextensions”字段携带进行了丢包补偿后的累计丢包数，从而实现丢包检测协议的功能。这样，发送方就可以根据接收方反馈的RTCP报文计算利用冗余进行了丢包补偿后的丢包率B，B＝(当前RTCP报文报告的利用冗余进行了丢包补偿后的丢包数-上一个RTCP报文报告的利用冗余进行了丢包补偿后的丢包数)/(当前RTCP报文报告的序列号-上一个RTCP报文报告的序列号)。由前文介绍还知，通过RTCP报文还可以获取上一个RTCP报文发送周期内的丢包率A，可以理解，B≤A，这是由于利用冗余进行了丢包补偿后的丢报数肯定不大于利用冗余进行了丢包补偿后的丢报数。例如，一个带一个冗余包的序列RTP1、RTP1/RTP2、RTP2/RTP3、RTP3/RTP4，如果“RTP1/RTP2”报文丢失，则RTCP反馈只接收到三个有效报文，丢失一个报文，计算出丢包率A＝1/4＝25％，而利用冗余进行了丢包补偿后，可生成完整序列RTP1，RTP2，RTP3，RTP4，扩展后RTCP报文反馈的结果为收到四个有效报文，计算出的利用冗余进行丢包补偿后的丢包率B＝0/4＝0％。
接着进入步骤150，判断步骤140得到的丢包率是否满足当前业务的丢包门限，如果是则进入步骤160，否则进入步骤180。其中，如果B＞C，则说明即使利用冗余进行了丢包补偿后的丢包率无法满足当前业务的丢包门限。
在步骤160中，判断是否可以减少冗余包个数，如果是则进入步骤170，否则进入步骤190。如果丢包率A≤C，则说明不需要冗余也可以满足当前业务的丢包门限，此时可以降低冗余度，在本发明第一较佳实施方式中即减少冗余包个数。在本发明第一较佳实施方式中，为了防止频繁抖动，在连续多次A≤C后，才允许减小冗余包个数。如果丢包率A＞C，说明此时冗余仍在起作用，有冗余则无法满足当前业务的丢包门限，此时是否减小冗余度，则可使用不同策略，在本发明第一较佳实施方式中，此时不可以降低冗余度即不减少冗余包个数。
在步骤170中，在不小于最小冗余包个数的前提下减少冗余包个数。其中，该步骤中每次减少的冗余包个数可以固定设定为1。在本发明第一较佳实施方式中，为了更快的实现冗余包个数的稳定，在连续多次A≤C后，直接减小冗余包个数为最小冗余包个数。
在步骤180中，在不大于最大冗余包个数的前提下增加冗余包个数。此时，由于即使利用冗余进行了丢包补偿后的丢包率仍无法满足当前业务的丢包门限，因此需要增加冗余度，即增加冗余包个数。
在步骤190中，判断当前业务是否结束，如果是则结束整个流程，否则返回步骤130。
根据本发明第二较佳实施方式的实现RTP报文冗余机制的流程如图2所示，该较佳实施方式使用RFC2733定义的冗余机制。
先进入步骤210，在呼叫建立时，进行参数解析确定最大冗余度、最小冗余度和当前业务的丢包门限。其中，丢包门限由当前业务的类型决定，一般来说，实时语音、视频业务的丢包门限为1％，实时数据业务的丢包门限为0％，为了便于说明，设丢包门限为C。在本发明第二较佳实施方式中，冗余纠错方案能够纠正的连续丢包数越多冗余度越大。
接着进入步骤220，根据最小冗余度对应的纠错方案进行RTP冗余传输。在本发明第二较佳实施方式中，该步骤使得呼叫建立时对于网络带宽资源的消耗降到了最少，但可以理解，也可以使用任何介于最小冗余度和最大冗余度之间的冗余度对应的纠错方案进行RTP冗余传输。
接着进入步骤230，判断当前业务是否支持动态调整冗余纠错方案，如果是则进入步骤240，否则进入步骤290。如果当前业务不支持动态调整冗余度，在本发明第二较佳实施方式中，即当前业务不支持动态调整冗余纠错方案，则在呼叫进行过程中，按照呼叫建立时确定的冗余度也即冗余纠错方案进行传输。
在步骤240中，估计当前网络利用冗余进行了丢包补偿后的丢包率。当前网络利用冗余进行了丢包补偿后的丢包率可以通过丢包检测协议返回的信息获得，在本发明第二较佳实施方式中，扩充RTCP协议，在“profile-specificextensions”字段携带进行了丢包补偿后的累计丢包数。这样，发送方就可以根据接收方反馈的RTCP报文计算利用冗余进行了丢包补偿后的丢包率B，B＝(当前RTCP报文报告的利用冗余进行了丢包补偿后的丢包数-上一个RTCP报文报告的利用冗余进行了丢包补偿后的丢包数)/(当前RTCP报文报告的序列号-上一个RTCP报文报告的序列号)。由前文介绍还知，通过RTCP报文还可以获取上一个RTCP报文发送周期内的丢包率A，可以理解，B≤A，这是由于利用冗余进行了丢包补偿后的丢报数肯定不大于利用冗余进行了丢包补偿后的丢报数。
接着进入步骤250，判断步骤240得到的丢包率是否满足当前业务的丢包门限，如果是则进入步骤260，否则进入步骤280。其中，如果B＞C，则说明即使利用冗余进行了丢包补偿后的丢包率仍无法满足当前业务的丢包门限。
在步骤260中，判断是否可以减小冗余度，如果是则进入步骤270，否则进入步骤290。如果丢包率A≤C，则说明不需要冗余也可以满足当前业务的丢包门限，此时可以降低冗余度，在本发明第二较佳实施方式中即降低纠错方案的冗余度。在本发明第二较佳实施方式中，为了防止频繁抖动，在连续多次A≤C后，才允许减小冗余度。如果丢包率A＞C，说明此时冗余仍在起作用，有冗余则无法满足当前业务的丢包门限，此时是否减小冗余度，则可使用不同策略，在本发明第二较佳实施方式中，不降低冗余度即不改变冗余纠错方案。
在步骤270中，使用不小于最小冗余度但冗余度更小的纠错方案。在本发明第二较佳实施方式中，为了更快的实现冗余纠错方案的稳定，在连续多次A≤C后，直接将冗余纠错方案改变为与最小冗余度对应的纠错方案。
在步骤280中，使用不大于最大冗余度但冗余度更大的纠错方案。此时，由于即使利用冗余进行了丢包补偿后的丢包率仍无法满足当前业务的丢包门限，因此需要增加冗余度，使用冗余度更大的纠错方案。
在步骤290中，判断当前业务是否结束，如果是则结束整个流程，否则返回步骤230。
可以看出，本发明第二较佳实施方式的流程和本发明第一较佳实施方式的流程类似。它们的不同之处在于，本发明第一较佳实施方式的冗余度通过冗余包个数体现，冗余包个数越多冗余度越大；而本发明第二较佳实施方式的冗余度则通过不同的纠错方案体现，纠错方案能够纠正的连续丢包数越多则冗余度越大。
本发明第三较佳实施方式的步骤和本发明第一较佳实施方式的步骤完全相同，只是在步骤160中，在连续多次A＞C≥B情况下，如果当前冗余包个数大于最小冗余包数且大于1，并且前一次减少冗余包个数后B没有变大，则减少冗余包个数。可以理解，本发明第一较佳实施方式是一种比较保守的策略，虽然可能造成带宽的浪费，但避免了由于冗余度的减少可能造成的丢包率上升的情况；本发明第三较佳实施方式则是一种比较激进的策略，其目的是尽量使用最小的带宽，但可能造成冗余度的反复调整。
根据本发明第四较佳实施方式的实现RTP报文冗余机制的系统组成如图3所示。
实现RTP报文冗余机制的系统包含以下模块参数解析模块10、丢包率统计模块20、冗余度调整模块30和RTP报文发送模块40。冗余度调整模块30分别和参数解析模块10、丢包率统计模块20以及RTP报文发送模块40连接。
其中，参数解析模块10用于在呼叫建立时解析当前业务的最大冗余度、最小冗余度、丢包门限，并确定当前业务是否支持冗余度动态调整。其中，当前业务的丢包门限由业务类型决定，一般来说，实时语音、视频业务的丢包门限为1％，实时数据业务的丢包门限为0％。
丢包率统计模块20用于统计利用冗余进行丢包补偿后的第一丢包率和不利用冗余进行丢包补偿的第二丢包率。可以理解，第一丢包率不大于第二丢包率，这是由于利用冗余进行了丢包补偿后的丢报数肯定不大于利用冗余进行了丢包补偿后的丢报数。第一丢包率和第二丢包率可以通过丢包检测协议返回的信息获得，在本发明第四较佳实施方式中，扩充RTCP协议，在“profile-specific extensions”字段携带进行了丢包补偿后的累计丢包数，这样，发送方就可以根据接收方反馈的RTCP报文计算利用冗余进行了丢包补偿后的第一丢包率，由前文介绍还知，通过RTCP报文还可以获取上一个RTCP报文发送周期内的第二丢包率。
冗余度调整模块30在不支持冗余度动态调整时输出固定的冗余度，在支持冗余度动态调整时，调整输出的冗余度为满足第一丢包率小于所述丢包门限条件下的最小值。其中，当前业务是否支持冗余度动态调整可以通过参数解析模块10的输出获得。如果当前业务不支持冗余度动态调整，在本发明第四较佳实施方式中，为了尽量少占用网络带宽资源，输出的冗余度等于最小冗余度。如果当前业务支持冗余度动态调整，在第二丢包率门限大于丢包门限时，本发明第四较佳实施方式中，冗余度调整模块30在不大于最大冗余度的前提下增加冗余度；在第二丢包率连续多次小于等于丢包门限时，本发明第四较佳实施方式中，冗余度调整模块30直接输出冗余度为最小冗余度，这是由于此时不使用冗余进行丢包补偿的第二丢包率也可以满足丢包门限的要求，因此可以不使用冗余，即可以将冗余度降低为最小冗余度，之所以连续多次出现才调整，是为了避免冗余度的频繁调整和抖动；在第二丢包率大于丢包门限，但第一丢包率小于等于丢包门限时，如果连续多次出现这种情况且上一次减小冗余度没有造成第一丢包率的上升，本发明第四较佳实施方式中，冗余度调整模块30减小输出的冗余度。需要说明的是，冗余度调整模块30输出的冗余度要介于最大冗余度和最小冗余度之间；在本发明第四较佳实施方式中，为了尽量减少对于网络带宽的使用，在呼叫开始时，冗余度调整模块30输出的冗余度为最小冗余度。
RTP报文发送模块40用于根据所述冗余度调整模块30输出的冗余度和当前业务使用的RTP报文冗余机制输出携带了冗余的RTP报文。在本发明第四较佳实施方式中，当前业务使用的RTP报文冗余机制包含RFC2198和RFC2733定义的冗余机制。可以理解，不同的冗余机制通过不同的特征体现冗余度的大小。例如，对于RFC2198，每个RTP报文携带的冗余包个数越多则冗余度越大；而对于RFC2733，冗余纠错方案能够纠正的连续丢包数越多冗余度越大。
虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。
权利要求
1.一种实现实时传输协议报文冗余机制的方法，其特征在于，包含以下步骤A呼叫建立时确定当前业务的最大冗余度、最小冗余度以及丢包门限；C呼叫进行时，统计利用冗余进行丢包补偿后的第一丢包率，并在所述最大冗余度和最小冗余度范围内根据网络传输质量调整实时传输协议报文的冗余度，将该冗余度调整为满足所述第一丢包率小于所述丢包门限条件下的最小值。
2.根据权利要求1所述的实现实时传输协议报文冗余机制的方法，其特征在于，在所述步骤A与C之间还包含以下步骤B判断当前业务是否支持动态调整所述实时传输协议报文的冗余度，如果是则进入步骤C，否则使用固定的冗余度进行所述实时传输协议报文的传输。
3.根据权利要求1所述的实现实时传输协议报文冗余机制的方法，其特征在于，所述步骤C还包含以下子步骤C1判断第一丢包率是否大于所述丢包门限，如果是则进入步骤C2，否则进入步骤C3；C2在小于等于最大冗余度的前提下增加所述冗余度；C3在大于等于最小冗余度的前提下减小或维持所述冗余度。
4.根据权利要求3所述的实现实时传输协议报文冗余机制的方法，其特征在于，所述步骤C3还包含以下子步骤C31判断不进行丢包补偿的第二丢包率连续小于等于所述丢包门限的次数是否超过阈值，如果是则进入步骤C32，否则进入步骤C33；C32在大于等于最小冗余度的前提下减小所述冗余度；C33维持所述冗余度。
5.根据权利要求4所述的实现实时传输协议报文冗余机制的方法，其特征在于，所述步骤C32中，一次性将所述冗余度减小为最小冗余度。
6.根据权利要求3所述的实现实时传输协议报文冗余机制的方法，其特征在于，所述步骤C3还包含以下子步骤C34判断不进行丢包补偿的第二丢包率连续小于等于所述丢包门限的次数是否超过阈值，如果是则进入步骤C35，否则进入步骤C36；C35在大于等于所述最小冗余度的前提下减小所述冗余度；C36判断第一丢包率连续小于所述丢包门限的次数是否超过阈值，且当前的所述冗余度是否大于最小冗余度且不为0，且前一次减小所述冗余度后第一丢包率是否没有上升，如果均是则减小所述冗余度，否则维持所述冗余度。
7.根据权利要求6所述的实现实时传输协议报文冗余机制的方法，其特征在于，所述步骤C35中，一次性将所述冗余度减小为最小冗余度。
8.根据权利要求3所述的实现实时传输协议报文冗余机制的方法，其特征在于，通过实时传输控制协议的扩展部分携带进行丢包补偿后的累计丢包数。
9.根据权利要求1至8中任一项所述的实现实时传输协议报文冗余机制的方法，其特征在于，还包含以下步骤E呼叫建立时，使用最小冗余度进行所述实时传输协议报文的传输。
10.一种实现实时传输协议报文冗余机制的系统，其特征在于，包含，参数解析模块、丢包率统计模块和冗余度调整模块，其中，所述参数解析模块，用于解析当前业务的最大冗余度、最小冗余度、丢包门限，并输出到所述冗余度调整模块；所述丢包率统计模块，用于统计利用冗余进行丢包补偿后的第一丢包率，并输出到所述冗余度调整模块；所述冗余度调整模块，用于在所述最大冗余度和最小冗余度范围内根据网络传输质量调整实时传输协议报文的冗余度，将该冗余度调整为满足所述第一丢包率小于所述丢包门限条件下的最小值。
全文摘要
本发明涉及通信技术，公开了一种实现实时传输协议报文冗余机制的方法及其系统，使得使用RTP冗余机制时既可以避免带宽的浪费也可以满足业务丢包率需求。本发明中，在呼叫进行中根据网络传输环境动态调整冗余度。在最大、最小冗余度范围内，将冗余度动态调整为满足进行丢包补偿后的第一丢包率小于丢包门限条件下的最小值。呼叫建立时使用最小冗余度。
文档编号H04L29/06GK101030832SQ20061002434
公开日2007年9月5日 申请日期2006年3月3日 优先权日2006年3月3日
发明者陈诚, 刘振华 申请人:华为技术有限公司