專利名稱：實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法及其系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)，特別涉及實(shí)時(shí)傳輸協(xié)議相關(guān)的通信技術(shù)。
背景技術(shù)：
基于網(wǎng)際互連協(xié)議(Internet Protocol，簡稱“IP”)的分組交換網(wǎng)絡(luò)在近幾十年來得到了蓬勃的發(fā)展，成為覆蓋全球的通信網(wǎng)。IP網(wǎng)絡(luò)具有低成本等優(yōu)勢，隨著通信的發(fā)展，包括語音業(yè)務(wù)在內(nèi)的傳統(tǒng)的電信業(yè)務(wù)也越來越多地使用IP網(wǎng)絡(luò)承載，承載實(shí)時(shí)語音業(yè)務(wù)的IP網(wǎng)絡(luò)也稱為分組語音(Voice overIP，簡稱“VoIP”)網(wǎng)絡(luò)。例如，H.323網(wǎng)絡(luò)、下一代網(wǎng)絡(luò)(Next GenerationNetwork，簡稱“NGN”)和第三代移動(dòng)通信(The Third Generation，簡稱“3G”)的分組交換核心網(wǎng)等都是VoIP網(wǎng)絡(luò)。
VoIP網(wǎng)絡(luò)可以承載實(shí)時(shí)性要求較高的業(yè)務(wù)，例如實(shí)時(shí)語音、實(shí)時(shí)視頻、實(shí)時(shí)數(shù)據(jù)等業(yè)務(wù)，一般使用實(shí)時(shí)傳輸協(xié)議(Real-Time Transfer Protocol，簡稱“RTP”)協(xié)議作為實(shí)時(shí)業(yè)務(wù)的承載協(xié)議。RTP是針對IP網(wǎng)絡(luò)上多媒體數(shù)據(jù)流的一個(gè)傳輸協(xié)議，在《RTPA Transport Protocol for Real-TimeApplications》(RFC3550)(中文可譯為《實(shí)時(shí)傳輸協(xié)議一種實(shí)時(shí)應(yīng)用的傳輸協(xié)議》(請求評注標(biāo)準(zhǔn)3550))中被定義。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時(shí)間信息和媒體流同步。RTP的典型應(yīng)用建立在用戶數(shù)據(jù)報(bào)協(xié)議(User Datagram Protocol，簡稱“UDP”)上，但也可以在傳輸控制協(xié)議(Transfer Control Protocol，簡稱“TCP”)或異步傳輸模式(Asynchronous Transfer Mode，簡稱“ATM”)等其他協(xié)議之上工作。典型的VoIP網(wǎng)絡(luò)上語音報(bào)文格式為物理鏈路層+IP協(xié)議層+UDP協(xié)議層+RTP協(xié)議層+語音數(shù)據(jù)。
RTP本身只保證實(shí)時(shí)數(shù)據(jù)的傳輸，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，同時(shí)IP網(wǎng)絡(luò)是面向無連接的不可靠網(wǎng)絡(luò)，但實(shí)時(shí)業(yè)務(wù)又要求網(wǎng)絡(luò)服務(wù)質(zhì)量(Quality of Service，簡稱“QoS”)達(dá)到一定要求。例如，典型要求為丟包率低于1％、延時(shí)低于100毫秒(ms)、網(wǎng)絡(luò)抖動(dòng)小于20ms，因此，還需要使用其他技術(shù)以保證QoS。在IP網(wǎng)絡(luò)上承載語音等實(shí)時(shí)業(yè)務(wù)時(shí)，為減少IP網(wǎng)絡(luò)中實(shí)時(shí)業(yè)務(wù)報(bào)文的丟包率，除了優(yōu)化IP承載網(wǎng)絡(luò)外，還可以通過冗余機(jī)制抵抗網(wǎng)絡(luò)丟包。本領(lǐng)域的技術(shù)人員理解，冗余即為額外傳輸?shù)某龢I(yè)務(wù)信息以外的信息，可以用來抵抗傳輸中出現(xiàn)的錯(cuò)誤，冗余信息在總的傳輸信息中的比例稱為冗余度。
RTP報(bào)文冗余機(jī)制就是利用RTP業(yè)務(wù)報(bào)文的冗余發(fā)送，減少實(shí)時(shí)業(yè)務(wù)報(bào)文的丟包率。一般情況下，RTP報(bào)文冗余機(jī)制有兩種，它們分別在《RTPPayload for Redundant Audio Data》(RFC2198)中文可譯為《支持冗余語音數(shù)據(jù)的實(shí)時(shí)傳輸協(xié)議的有效載荷》(請求評注標(biāo)準(zhǔn)2198)和《An RTP PayloadFormat for Generic Forward Error Correction》(RFC2733)中文可譯為《一種支持普通前向糾錯(cuò)編碼的實(shí)時(shí)傳輸協(xié)議有效載荷格式》(請求評注標(biāo)準(zhǔn)2733)中定義。
RFC2198定義的冗余機(jī)制的基本原理是每個(gè)當(dāng)前RTP報(bào)文攜帶前一個(gè)或者前幾個(gè)RTP報(bào)文的內(nèi)容，當(dāng)RTP報(bào)文丟失時(shí)，可以從后續(xù)的RTP報(bào)文攜帶的冗余中恢復(fù)丟失的RTP報(bào)文。例如，在發(fā)送時(shí)，如果沒有冗余包，報(bào)文傳送序列為RTP1、RTP2、RTP3、RTP4；如果每個(gè)RTP報(bào)文攜帶一個(gè)冗余包，則報(bào)文傳送序列為RTP1、RTP2/RTP1、RTP3/RTP2、RTP4/RTP3；如果每個(gè)RTP報(bào)文攜帶兩個(gè)冗余包，則報(bào)文傳送序列為RTP1、RTP2/RTP1、RTP3/RTP2/RTP1、RTP4/RTP3/RTP2。其中，RTPi表示第i個(gè)RTP報(bào)文，報(bào)文中第一個(gè)“/”后的部分稱為冗余包，第一個(gè)“/”前的部分稱為主包。若網(wǎng)絡(luò)沒有丟包，則接收方只把主包作為有效業(yè)務(wù)報(bào)文，丟棄冗余包；若網(wǎng)絡(luò)有丟包，在每個(gè)RTP報(bào)文攜帶一個(gè)冗余包情況時(shí)，若報(bào)文RTP2/RTP1丟失，則接收方會(huì)從報(bào)文RTP3/RTP2中解出主包RTP2，進(jìn)行丟包補(bǔ)償，形成完整的報(bào)文序列RTP1、RTP2、RTP3、RTP4。
RFC2733協(xié)議定義的冗余機(jī)制的基本原理是在發(fā)送報(bào)文序列中增加攜帶前向糾錯(cuò)(Forward Error Correction，簡稱“FEC”)信息的冗余報(bào)文，接收方可以使用冗余報(bào)文恢復(fù)丟失的RTP報(bào)文。在具體實(shí)現(xiàn)時(shí)，可以從媒體數(shù)據(jù)流中抽取若干個(gè)RTP報(bào)文，并對它們做異或操作，生成一個(gè)包含F(xiàn)EC信息的冗余報(bào)文，這個(gè)冗余報(bào)文可以被接收端用來恢復(fù)任何一個(gè)用來產(chǎn)生它的RTP報(bào)文。例如，沒有冗余報(bào)文時(shí)的報(bào)文發(fā)送序列為a、b、c、d。攜帶了FEC冗余信息的報(bào)文發(fā)送序列為a、b、f(a，b)、c、d、f(c，d)，可以補(bǔ)償連續(xù)一個(gè)報(bào)文的丟失，其中，f(a，b)是冗余報(bào)文，表示報(bào)文a和報(bào)文b異或的結(jié)果。在接收方，如果沒有報(bào)文丟失，則直接丟棄冗余報(bào)文f(a，b)和f(c，d)；如果報(bào)文b丟失，則將報(bào)文a和報(bào)文f(a，b)異或后即可以恢復(fù)報(bào)文b，從而實(shí)現(xiàn)了丟包補(bǔ)償。如果報(bào)文發(fā)送序列為a、f(a，b)、b、f(b，c)、c、f(c，d)、d，可以補(bǔ)償連續(xù)兩個(gè)報(bào)文的丟失。在接收方，如果報(bào)文b、c丟失，則可以將a和f(a，b)異或恢復(fù)b，將b和f(b，c)異或恢復(fù)c。
RTP協(xié)議和實(shí)時(shí)傳輸控制協(xié)議(Real-Time Transport Control Protocol，簡稱“RTCP”)協(xié)議一般是配合使用的。RTP協(xié)議傳送業(yè)務(wù)報(bào)文，RTCP協(xié)議用于監(jiān)控和反饋RTP報(bào)文在IP網(wǎng)絡(luò)上的傳輸情況。在RTP會(huì)話期間，各參與者周期性地傳送RTCP報(bào)告報(bào)文，報(bào)文中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。例如，接收方的RTCP報(bào)告報(bào)文格式如下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”(中文可譯為“累計(jì)報(bào)文丟失數(shù)”)字段表示通話過程中總的丟失報(bào)文數(shù)；“extended highest sequencenumber received”(中文可譯為“擴(kuò)展的接收最高序列號”)表示這個(gè)丟包數(shù)統(tǒng)計(jì)截至的序列號；“profile-specific extensions”(中文可譯為“草案特有的擴(kuò)展”)表示RTCP協(xié)議的可擴(kuò)展部分。
關(guān)于RTCP的詳細(xì)說明可以參照《RTP Profile for Audio and VideoConferences with Minimal Control》(RFC3551)，中文可譯為《支持語音視頻會(huì)議具有最小控制能力的實(shí)時(shí)傳輸協(xié)議草案》(請求評注標(biāo)準(zhǔn)3551)。
在雙方RTP業(yè)務(wù)報(bào)文相互發(fā)送的過程中，一端定時(shí)向另一端反饋RTCP報(bào)文，另一端可分析出在IP網(wǎng)絡(luò)上RTP報(bào)文的丟包率。在上一個(gè)RTCP報(bào)文發(fā)送周期內(nèi)的丟包率A＝(當(dāng)前RTCP報(bào)文報(bào)告的總的丟失報(bào)文數(shù)-上一個(gè)RTCP報(bào)文報(bào)告的總的丟失報(bào)文數(shù))/(當(dāng)前RTCP報(bào)文報(bào)告的序列號-上一個(gè)RTCP報(bào)文報(bào)告的序列號)。其中，RTCP報(bào)文報(bào)告的總的報(bào)文丟失數(shù)即為“cumulative number of packets lost”字段的內(nèi)容，RTCP報(bào)文報(bào)告的序列號即為“extended highest sequence number received”字段的內(nèi)容。
現(xiàn)有技術(shù)方案實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制時(shí)，使用固定的冗余度進(jìn)行傳輸。
使用RFC2198定義的RTP冗余機(jī)制時(shí)，現(xiàn)有技術(shù)方案一般是在呼叫建立時(shí)確定每個(gè)RTP報(bào)文攜帶的冗余包個(gè)數(shù)即冗余度，呼叫過程中每個(gè)報(bào)文都攜帶固定的冗余包個(gè)數(shù)，發(fā)送方確定了冗余包個(gè)數(shù)后，接收方可以自動(dòng)識別處理；使用RFC2733定義的RTP冗余機(jī)制時(shí)，現(xiàn)有技術(shù)方案一般在呼叫建立時(shí)確定呼叫使用的冗余糾錯(cuò)方式即冗余度，并在呼叫過程中一直使用，發(fā)送方確定了冗余糾錯(cuò)方式后，接收方可以自動(dòng)識別處理。
在實(shí)際應(yīng)用中，上述方案存在以下問題現(xiàn)有技術(shù)方案會(huì)對網(wǎng)絡(luò)帶寬造成浪費(fèi)或無法滿足業(yè)務(wù)QoS需求。
造成這種情況的主要原因在于，現(xiàn)有技術(shù)方案使用固定冗余度進(jìn)行傳輸，而在實(shí)際情況中網(wǎng)絡(luò)傳輸環(huán)境的變化會(huì)造成冗余度的富余或不足，冗余度富余會(huì)浪費(fèi)網(wǎng)絡(luò)帶寬，冗余度不足則導(dǎo)致傳輸?shù)膩G包率大于業(yè)務(wù)丟包門限，從而無法滿足業(yè)務(wù)QoS需求。
例如，以G.711編解碼20ms打包為例，不考慮靜音檢測，不攜帶冗余包的帶寬約為(78字節(jié)IP頭+160字節(jié)語音幀)*50包/秒*8位＝95.2Kbps；如果使用RFC2198的冗余機(jī)制，在呼叫建立時(shí)，需要每個(gè)報(bào)文攜帶一個(gè)冗余包才能滿足業(yè)務(wù)的丟包率需求，額外還需要(5字節(jié)冗余報(bào)文頭+160字節(jié)冗余幀)*50包/秒*8位＝66Kbps的帶寬；如果使用RFC2733的冗余機(jī)制，在呼叫建立時(shí)，需要使用恢復(fù)連續(xù)一個(gè)報(bào)文出錯(cuò)的糾錯(cuò)方法才能滿足業(yè)務(wù)的丟包率需求，每兩個(gè)業(yè)務(wù)報(bào)文后會(huì)產(chǎn)生一個(gè)FEC冗余報(bào)文，假設(shè)冗余報(bào)文和業(yè)務(wù)報(bào)文大小相同，則額外還需要95.2Kbps*50％＝47.5Kbps的帶寬。但在呼叫進(jìn)行中，可能由于網(wǎng)絡(luò)傳輸環(huán)境的好轉(zhuǎn)，不需要額外的冗余即可以滿足業(yè)務(wù)的丟包率需求，此時(shí)仍然使用呼叫建立時(shí)的冗余度進(jìn)行傳輸則會(huì)造成帶寬的浪費(fèi)。同樣，在呼叫建立時(shí)可能不需要使用冗余傳輸即可以滿足，但在呼叫進(jìn)行中，可能由于網(wǎng)絡(luò)傳輸環(huán)境的惡化，需要使用冗余才能滿足業(yè)務(wù)的丟包率需求，此時(shí)仍然使用呼叫建立時(shí)的冗余度進(jìn)行傳輸就會(huì)造成丟包率過高，無法滿足業(yè)務(wù)QoS需求。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法及其系統(tǒng)，使得使用RTP冗余機(jī)制時(shí)既可以避免帶寬的浪費(fèi)也可以滿足業(yè)務(wù)丟包率需求。
為實(shí)現(xiàn)上述目的，本發(fā)明提供了一種實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，包含以下步驟A呼叫建立時(shí)確定當(dāng)前業(yè)務(wù)的最大冗余度、最小冗余度以及丟包門限；C呼叫進(jìn)行時(shí)，統(tǒng)計(jì)利用冗余進(jìn)行丟包補(bǔ)償后的第一丟包率，并在所述最大冗余度和最小冗余度范圍內(nèi)根據(jù)網(wǎng)絡(luò)傳輸質(zhì)量調(diào)整實(shí)時(shí)傳輸協(xié)議報(bào)文的冗余度，將該冗余度調(diào)整為滿足所述第一丟包率小于所述丟包門限條件下的最小值。
其中，在所述步驟A與C之間還包含以下步驟B判斷當(dāng)前業(yè)務(wù)是否支持動(dòng)態(tài)調(diào)整所述實(shí)時(shí)傳輸協(xié)議報(bào)文的冗余度，如果是則進(jìn)入步驟C，否則使用固定的冗余度進(jìn)行所述實(shí)時(shí)傳輸協(xié)議報(bào)文的傳輸。
此外在所述方法中，所述步驟C還包含以下子步驟C1判斷第一丟包率是否大于所述丟包門限，如果是則進(jìn)入步驟C2，否則進(jìn)入步驟C3；C2在小于等于最大冗余度的前提下增加所述冗余度；
C3在大于等于最小冗余度的前提下減小或維持所述冗余度。
此外在所述方法中，所述步驟C3還包含以下子步驟C31判斷不進(jìn)行丟包補(bǔ)償?shù)牡诙G包率連續(xù)小于等于所述丟包門限的次數(shù)是否超過閾值，如果是則進(jìn)入步驟C32，否則進(jìn)入步驟C33；C32在大于等于最小冗余度的前提下減小所述冗余度；C33維持所述冗余度。
此外在所述方法中，所述步驟C32中，一次性將所述冗余度減小為最小冗余度。
此外在所述方法中，所述步驟C3還包含以下子步驟C34判斷不進(jìn)行丟包補(bǔ)償?shù)牡诙G包率連續(xù)小于等于所述丟包門限的次數(shù)是否超過閾值，如果是則進(jìn)入步驟C35，否則進(jìn)入步驟C36；C35在大于等于所述最小冗余度的前提下減小所述冗余度；C36判斷第一丟包率連續(xù)小于所述丟包門限的次數(shù)是否超過閾值，且當(dāng)前的所述冗余度是否大于最小冗余度且不為0，且前一次減小所述冗余度后第一丟包率是否沒有上升，如果均是則減小所述冗余度，否則維持所述冗余度。
此外在所述方法中，所述步驟C35中，一次性將所述冗余度減小為最小冗余度。
此外在所述方法中，通過實(shí)時(shí)傳輸控制協(xié)議的擴(kuò)展部分?jǐn)y帶進(jìn)行丟包補(bǔ)償后的累計(jì)丟包數(shù)。
此外在所述方法中，還包含以下步驟E呼叫建立時(shí)，使用最小冗余度進(jìn)行所述實(shí)時(shí)傳輸協(xié)議報(bào)文的傳輸。
本發(fā)明還提供了一種實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的系統(tǒng)，包含，參數(shù)解析模塊、丟包率統(tǒng)計(jì)模塊和冗余度調(diào)整模塊，其中，所述參數(shù)解析模塊，用于解析當(dāng)前業(yè)務(wù)的最大冗余度、最小冗余度、丟包門限，并輸出到所述冗余度調(diào)整模塊；所述丟包率統(tǒng)計(jì)模塊，用于統(tǒng)計(jì)利用冗余進(jìn)行丟包補(bǔ)償后的第一丟包率，并輸出到所述冗余度調(diào)整模塊；所述冗余度調(diào)整模塊，用于在所述最大冗余度和最小冗余度范圍內(nèi)根據(jù)網(wǎng)絡(luò)傳輸質(zhì)量調(diào)整實(shí)時(shí)傳輸協(xié)議報(bào)文的冗余度，將該冗余度調(diào)整為滿足所述第一丟包率小于所述丟包門限條件下的最小值。
通過比較可以發(fā)現(xiàn)，本發(fā)明的技術(shù)方案與現(xiàn)有技術(shù)的主要區(qū)別在于，在呼叫進(jìn)行中根據(jù)網(wǎng)絡(luò)傳輸環(huán)境動(dòng)態(tài)調(diào)整冗余度。在最大、最小冗余度范圍內(nèi)，將冗余度動(dòng)態(tài)調(diào)整為滿足進(jìn)行丟包補(bǔ)償后的第一丟包率小于丟包門限條件下的最小值。呼叫建立時(shí)使用最小冗余度。
這種技術(shù)方案上的區(qū)別，帶來了較為明顯的有益效果，即由于本發(fā)明方案可以在呼叫過程中動(dòng)態(tài)調(diào)整RTP報(bào)文的冗余度。首先，可以避免現(xiàn)有技術(shù)方案使用固定冗余度時(shí)，由于網(wǎng)絡(luò)傳輸質(zhì)量的好轉(zhuǎn)造成的網(wǎng)絡(luò)帶寬被浪費(fèi)的情況，最大限度的節(jié)省了網(wǎng)絡(luò)的帶寬資源；第二，可以避免現(xiàn)有技術(shù)方案使用固定冗余度時(shí)，由于網(wǎng)絡(luò)傳輸質(zhì)量的惡化造成的業(yè)務(wù)丟包率上升，無法滿足QoS需求的情況，可以最大限度的保證業(yè)務(wù)QoS需求，提高用戶的使用體驗(yàn)；第三，RTP報(bào)文冗余度的動(dòng)態(tài)調(diào)整和帶寬的相應(yīng)調(diào)整，也有效提高了網(wǎng)絡(luò)帶寬的有效利用率，降低了傳輸成本。


圖1是根據(jù)本發(fā)明第一較佳實(shí)施方式的實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制的流程示意圖；圖2是根據(jù)本發(fā)明第二較佳實(shí)施方式的實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制的流程示意圖；圖3是根據(jù)本發(fā)明第四較佳實(shí)施方式的實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制的系統(tǒng)結(jié)構(gòu)示意圖。
具體實(shí)施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面將結(jié)合附圖對本發(fā)明作進(jìn)一步地詳細(xì)描述。
本發(fā)明方案在呼叫過程中根據(jù)網(wǎng)絡(luò)質(zhì)量動(dòng)態(tài)調(diào)整RTP報(bào)文冗余度，在滿足業(yè)務(wù)丟包門限的前提下盡量使用低冗余度進(jìn)行傳輸。
本發(fā)明方案主要包含以下步驟A呼叫建立時(shí)確定最大冗余度、最小冗余度當(dāng)前業(yè)務(wù)丟包門限；B判斷當(dāng)前業(yè)務(wù)是否支持冗余度的動(dòng)態(tài)調(diào)整，如果是則進(jìn)入步驟C，否則進(jìn)入步驟D；C呼叫進(jìn)行時(shí)在滿足所述丟包門限的前提下根據(jù)網(wǎng)絡(luò)傳輸質(zhì)量調(diào)整所述冗余度使其在最大冗余度和最小冗余度范圍內(nèi)盡可能??；D使用介于最大冗余度和最小冗余度之間的固定冗余度進(jìn)行傳輸。
為了在呼叫建立時(shí)節(jié)省網(wǎng)絡(luò)帶寬，本發(fā)明方案還在呼叫建立時(shí)使用最小冗余度進(jìn)行傳輸。
本發(fā)明還提供了一種實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制的系統(tǒng)，包含參數(shù)解析模塊、丟包率統(tǒng)計(jì)模塊、冗余度調(diào)整模塊和RTP報(bào)文發(fā)送模塊。冗余度調(diào)整模塊分別和參數(shù)解析模塊、丟包率統(tǒng)計(jì)模塊以及RTP報(bào)文發(fā)送模塊連接。
其中，參數(shù)解析模塊用于在呼叫建立時(shí)解析當(dāng)前業(yè)務(wù)的最大冗余度、最小冗余度、丟包門限，并確定當(dāng)前業(yè)務(wù)是否支持冗余度動(dòng)態(tài)調(diào)整。
丟包率統(tǒng)計(jì)模塊用于統(tǒng)計(jì)利用冗余進(jìn)行丟包補(bǔ)償后的第一丟包率和不利用冗余進(jìn)行丟包補(bǔ)償?shù)牡诙G包率。
冗余度調(diào)整模塊在不支持冗余度動(dòng)態(tài)調(diào)整時(shí)輸出固定的冗余度；在支持冗余度動(dòng)態(tài)調(diào)整時(shí)，調(diào)整輸出的冗余度為滿足第一丟包率小于所述丟包門限條件下的最小值。
RTP報(bào)文發(fā)送模塊用于根據(jù)所述冗余度調(diào)整模塊輸出的冗余度和當(dāng)前業(yè)務(wù)使用的RTP報(bào)文冗余機(jī)制輸出攜帶了冗余的RTP報(bào)文。
為了更好的說明本發(fā)明方案，下面結(jié)合本發(fā)明較佳實(shí)施方式和附圖進(jìn)行說明。
根據(jù)本發(fā)明第一較佳實(shí)施方式的實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制的流程如圖1所示。該較佳實(shí)施方式使用RFC2198定義的冗余機(jī)制。
首先進(jìn)入步驟110，在呼叫建立時(shí)，進(jìn)行參數(shù)解析確定最大冗余包個(gè)數(shù)、最小冗余包個(gè)數(shù)和當(dāng)前業(yè)務(wù)的丟包門限。其中，丟包門限由當(dāng)前業(yè)務(wù)的類型決定，一般來說，實(shí)時(shí)語音、視頻業(yè)務(wù)的丟包門限為1％，實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)的丟包門限為0％，為了便于說明，設(shè)丟包門限為C。在本發(fā)明第一較佳實(shí)施方式中，最大冗余度對應(yīng)的冗余包個(gè)數(shù)即為最大冗余包個(gè)數(shù)，最小冗余度對應(yīng)的冗余包個(gè)數(shù)即為最小冗余包個(gè)數(shù)。
接著進(jìn)入步驟120，根據(jù)最小冗余包個(gè)數(shù)進(jìn)行RTP冗余傳輸。在本發(fā)明第一較佳實(shí)施方式中，該步驟使得呼叫建立時(shí)對于網(wǎng)絡(luò)帶寬資源的消耗降到了最少，但可以理解，也可以使用任何介于最小冗余包個(gè)數(shù)和最大冗余包個(gè)數(shù)之間的冗余包個(gè)數(shù)進(jìn)行RTP冗余傳輸。
接著進(jìn)入步驟130，判斷當(dāng)前業(yè)務(wù)是否支持動(dòng)態(tài)調(diào)整冗余包個(gè)數(shù)，如果是則進(jìn)入步驟140，否則進(jìn)入步驟190。如果當(dāng)前業(yè)務(wù)不支持動(dòng)態(tài)調(diào)整冗余度，在本發(fā)明第一較佳實(shí)施方式中，即當(dāng)前業(yè)務(wù)不支持動(dòng)態(tài)調(diào)整冗余包個(gè)數(shù)，則在呼叫進(jìn)行過程中，按照呼叫建立時(shí)確定的冗余度也即冗余包個(gè)數(shù)進(jìn)行傳輸。
在步驟140中，估計(jì)當(dāng)前網(wǎng)絡(luò)利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率。當(dāng)前網(wǎng)絡(luò)利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率可以通過丟包檢測協(xié)議返回的信息獲得，在本發(fā)明第一較佳實(shí)施方式中，擴(kuò)充RTCP協(xié)議，在“profile-specificextensions”字段攜帶進(jìn)行了丟包補(bǔ)償后的累計(jì)丟包數(shù)，從而實(shí)現(xiàn)丟包檢測協(xié)議的功能。這樣，發(fā)送方就可以根據(jù)接收方反饋的RTCP報(bào)文計(jì)算利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率B，B＝(當(dāng)前RTCP報(bào)文報(bào)告的利用冗余進(jìn)行了丟包補(bǔ)償后的丟包數(shù)-上一個(gè)RTCP報(bào)文報(bào)告的利用冗余進(jìn)行了丟包補(bǔ)償后的丟包數(shù))/(當(dāng)前RTCP報(bào)文報(bào)告的序列號-上一個(gè)RTCP報(bào)文報(bào)告的序列號)。由前文介紹還知，通過RTCP報(bào)文還可以獲取上一個(gè)RTCP報(bào)文發(fā)送周期內(nèi)的丟包率A，可以理解，B≤A，這是由于利用冗余進(jìn)行了丟包補(bǔ)償后的丟報(bào)數(shù)肯定不大于利用冗余進(jìn)行了丟包補(bǔ)償后的丟報(bào)數(shù)。例如，一個(gè)帶一個(gè)冗余包的序列RTP1、RTP1/RTP2、RTP2/RTP3、RTP3/RTP4，如果“RTP1/RTP2”報(bào)文丟失，則RTCP反饋只接收到三個(gè)有效報(bào)文，丟失一個(gè)報(bào)文，計(jì)算出丟包率A＝1/4＝25％，而利用冗余進(jìn)行了丟包補(bǔ)償后，可生成完整序列RTP1，RTP2，RTP3，RTP4，擴(kuò)展后RTCP報(bào)文反饋的結(jié)果為收到四個(gè)有效報(bào)文，計(jì)算出的利用冗余進(jìn)行丟包補(bǔ)償后的丟包率B＝0/4＝0％。
接著進(jìn)入步驟150，判斷步驟140得到的丟包率是否滿足當(dāng)前業(yè)務(wù)的丟包門限，如果是則進(jìn)入步驟160，否則進(jìn)入步驟180。其中，如果B＞C，則說明即使利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率無法滿足當(dāng)前業(yè)務(wù)的丟包門限。
在步驟160中，判斷是否可以減少冗余包個(gè)數(shù)，如果是則進(jìn)入步驟170，否則進(jìn)入步驟190。如果丟包率A≤C，則說明不需要冗余也可以滿足當(dāng)前業(yè)務(wù)的丟包門限，此時(shí)可以降低冗余度，在本發(fā)明第一較佳實(shí)施方式中即減少冗余包個(gè)數(shù)。在本發(fā)明第一較佳實(shí)施方式中，為了防止頻繁抖動(dòng)，在連續(xù)多次A≤C后，才允許減小冗余包個(gè)數(shù)。如果丟包率A＞C，說明此時(shí)冗余仍在起作用，有冗余則無法滿足當(dāng)前業(yè)務(wù)的丟包門限，此時(shí)是否減小冗余度，則可使用不同策略，在本發(fā)明第一較佳實(shí)施方式中，此時(shí)不可以降低冗余度即不減少冗余包個(gè)數(shù)。
在步驟170中，在不小于最小冗余包個(gè)數(shù)的前提下減少冗余包個(gè)數(shù)。其中，該步驟中每次減少的冗余包個(gè)數(shù)可以固定設(shè)定為1。在本發(fā)明第一較佳實(shí)施方式中，為了更快的實(shí)現(xiàn)冗余包個(gè)數(shù)的穩(wěn)定，在連續(xù)多次A≤C后，直接減小冗余包個(gè)數(shù)為最小冗余包個(gè)數(shù)。
在步驟180中，在不大于最大冗余包個(gè)數(shù)的前提下增加冗余包個(gè)數(shù)。此時(shí)，由于即使利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率仍無法滿足當(dāng)前業(yè)務(wù)的丟包門限，因此需要增加冗余度，即增加冗余包個(gè)數(shù)。
在步驟190中，判斷當(dāng)前業(yè)務(wù)是否結(jié)束，如果是則結(jié)束整個(gè)流程，否則返回步驟130。
根據(jù)本發(fā)明第二較佳實(shí)施方式的實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制的流程如圖2所示，該較佳實(shí)施方式使用RFC2733定義的冗余機(jī)制。
先進(jìn)入步驟210，在呼叫建立時(shí)，進(jìn)行參數(shù)解析確定最大冗余度、最小冗余度和當(dāng)前業(yè)務(wù)的丟包門限。其中，丟包門限由當(dāng)前業(yè)務(wù)的類型決定，一般來說，實(shí)時(shí)語音、視頻業(yè)務(wù)的丟包門限為1％，實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)的丟包門限為0％，為了便于說明，設(shè)丟包門限為C。在本發(fā)明第二較佳實(shí)施方式中，冗余糾錯(cuò)方案能夠糾正的連續(xù)丟包數(shù)越多冗余度越大。
接著進(jìn)入步驟220，根據(jù)最小冗余度對應(yīng)的糾錯(cuò)方案進(jìn)行RTP冗余傳輸。在本發(fā)明第二較佳實(shí)施方式中，該步驟使得呼叫建立時(shí)對于網(wǎng)絡(luò)帶寬資源的消耗降到了最少，但可以理解，也可以使用任何介于最小冗余度和最大冗余度之間的冗余度對應(yīng)的糾錯(cuò)方案進(jìn)行RTP冗余傳輸。
接著進(jìn)入步驟230，判斷當(dāng)前業(yè)務(wù)是否支持動(dòng)態(tài)調(diào)整冗余糾錯(cuò)方案，如果是則進(jìn)入步驟240，否則進(jìn)入步驟290。如果當(dāng)前業(yè)務(wù)不支持動(dòng)態(tài)調(diào)整冗余度，在本發(fā)明第二較佳實(shí)施方式中，即當(dāng)前業(yè)務(wù)不支持動(dòng)態(tài)調(diào)整冗余糾錯(cuò)方案，則在呼叫進(jìn)行過程中，按照呼叫建立時(shí)確定的冗余度也即冗余糾錯(cuò)方案進(jìn)行傳輸。
在步驟240中，估計(jì)當(dāng)前網(wǎng)絡(luò)利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率。當(dāng)前網(wǎng)絡(luò)利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率可以通過丟包檢測協(xié)議返回的信息獲得，在本發(fā)明第二較佳實(shí)施方式中，擴(kuò)充RTCP協(xié)議，在“profile-specificextensions”字段攜帶進(jìn)行了丟包補(bǔ)償后的累計(jì)丟包數(shù)。這樣，發(fā)送方就可以根據(jù)接收方反饋的RTCP報(bào)文計(jì)算利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率B，B＝(當(dāng)前RTCP報(bào)文報(bào)告的利用冗余進(jìn)行了丟包補(bǔ)償后的丟包數(shù)-上一個(gè)RTCP報(bào)文報(bào)告的利用冗余進(jìn)行了丟包補(bǔ)償后的丟包數(shù))/(當(dāng)前RTCP報(bào)文報(bào)告的序列號-上一個(gè)RTCP報(bào)文報(bào)告的序列號)。由前文介紹還知，通過RTCP報(bào)文還可以獲取上一個(gè)RTCP報(bào)文發(fā)送周期內(nèi)的丟包率A，可以理解，B≤A，這是由于利用冗余進(jìn)行了丟包補(bǔ)償后的丟報(bào)數(shù)肯定不大于利用冗余進(jìn)行了丟包補(bǔ)償后的丟報(bào)數(shù)。
接著進(jìn)入步驟250，判斷步驟240得到的丟包率是否滿足當(dāng)前業(yè)務(wù)的丟包門限，如果是則進(jìn)入步驟260，否則進(jìn)入步驟280。其中，如果B＞C，則說明即使利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率仍無法滿足當(dāng)前業(yè)務(wù)的丟包門限。
在步驟260中，判斷是否可以減小冗余度，如果是則進(jìn)入步驟270，否則進(jìn)入步驟290。如果丟包率A≤C，則說明不需要冗余也可以滿足當(dāng)前業(yè)務(wù)的丟包門限，此時(shí)可以降低冗余度，在本發(fā)明第二較佳實(shí)施方式中即降低糾錯(cuò)方案的冗余度。在本發(fā)明第二較佳實(shí)施方式中，為了防止頻繁抖動(dòng)，在連續(xù)多次A≤C后，才允許減小冗余度。如果丟包率A＞C，說明此時(shí)冗余仍在起作用，有冗余則無法滿足當(dāng)前業(yè)務(wù)的丟包門限，此時(shí)是否減小冗余度，則可使用不同策略，在本發(fā)明第二較佳實(shí)施方式中，不降低冗余度即不改變?nèi)哂嗉m錯(cuò)方案。
在步驟270中，使用不小于最小冗余度但冗余度更小的糾錯(cuò)方案。在本發(fā)明第二較佳實(shí)施方式中，為了更快的實(shí)現(xiàn)冗余糾錯(cuò)方案的穩(wěn)定，在連續(xù)多次A≤C后，直接將冗余糾錯(cuò)方案改變?yōu)榕c最小冗余度對應(yīng)的糾錯(cuò)方案。
在步驟280中，使用不大于最大冗余度但冗余度更大的糾錯(cuò)方案。此時(shí)，由于即使利用冗余進(jìn)行了丟包補(bǔ)償后的丟包率仍無法滿足當(dāng)前業(yè)務(wù)的丟包門限，因此需要增加冗余度，使用冗余度更大的糾錯(cuò)方案。
在步驟290中，判斷當(dāng)前業(yè)務(wù)是否結(jié)束，如果是則結(jié)束整個(gè)流程，否則返回步驟230。
可以看出，本發(fā)明第二較佳實(shí)施方式的流程和本發(fā)明第一較佳實(shí)施方式的流程類似。它們的不同之處在于，本發(fā)明第一較佳實(shí)施方式的冗余度通過冗余包個(gè)數(shù)體現(xiàn)，冗余包個(gè)數(shù)越多冗余度越大；而本發(fā)明第二較佳實(shí)施方式的冗余度則通過不同的糾錯(cuò)方案體現(xiàn)，糾錯(cuò)方案能夠糾正的連續(xù)丟包數(shù)越多則冗余度越大。
本發(fā)明第三較佳實(shí)施方式的步驟和本發(fā)明第一較佳實(shí)施方式的步驟完全相同，只是在步驟160中，在連續(xù)多次A＞C≥B情況下，如果當(dāng)前冗余包個(gè)數(shù)大于最小冗余包數(shù)且大于1，并且前一次減少冗余包個(gè)數(shù)后B沒有變大，則減少冗余包個(gè)數(shù)。可以理解，本發(fā)明第一較佳實(shí)施方式是一種比較保守的策略，雖然可能造成帶寬的浪費(fèi)，但避免了由于冗余度的減少可能造成的丟包率上升的情況；本發(fā)明第三較佳實(shí)施方式則是一種比較激進(jìn)的策略，其目的是盡量使用最小的帶寬，但可能造成冗余度的反復(fù)調(diào)整。
根據(jù)本發(fā)明第四較佳實(shí)施方式的實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制的系統(tǒng)組成如圖3所示。
實(shí)現(xiàn)RTP報(bào)文冗余機(jī)制的系統(tǒng)包含以下模塊參數(shù)解析模塊10、丟包率統(tǒng)計(jì)模塊20、冗余度調(diào)整模塊30和RTP報(bào)文發(fā)送模塊40。冗余度調(diào)整模塊30分別和參數(shù)解析模塊10、丟包率統(tǒng)計(jì)模塊20以及RTP報(bào)文發(fā)送模塊40連接。
其中，參數(shù)解析模塊10用于在呼叫建立時(shí)解析當(dāng)前業(yè)務(wù)的最大冗余度、最小冗余度、丟包門限，并確定當(dāng)前業(yè)務(wù)是否支持冗余度動(dòng)態(tài)調(diào)整。其中，當(dāng)前業(yè)務(wù)的丟包門限由業(yè)務(wù)類型決定，一般來說，實(shí)時(shí)語音、視頻業(yè)務(wù)的丟包門限為1％，實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)的丟包門限為0％。
丟包率統(tǒng)計(jì)模塊20用于統(tǒng)計(jì)利用冗余進(jìn)行丟包補(bǔ)償后的第一丟包率和不利用冗余進(jìn)行丟包補(bǔ)償?shù)牡诙G包率?？梢岳斫?，第一丟包率不大于第二丟包率，這是由于利用冗余進(jìn)行了丟包補(bǔ)償后的丟報(bào)數(shù)肯定不大于利用冗余進(jìn)行了丟包補(bǔ)償后的丟報(bào)數(shù)。第一丟包率和第二丟包率可以通過丟包檢測協(xié)議返回的信息獲得，在本發(fā)明第四較佳實(shí)施方式中，擴(kuò)充RTCP協(xié)議，在“profile-specific extensions”字段攜帶進(jìn)行了丟包補(bǔ)償后的累計(jì)丟包數(shù)，這樣，發(fā)送方就可以根據(jù)接收方反饋的RTCP報(bào)文計(jì)算利用冗余進(jìn)行了丟包補(bǔ)償后的第一丟包率，由前文介紹還知，通過RTCP報(bào)文還可以獲取上一個(gè)RTCP報(bào)文發(fā)送周期內(nèi)的第二丟包率。
冗余度調(diào)整模塊30在不支持冗余度動(dòng)態(tài)調(diào)整時(shí)輸出固定的冗余度，在支持冗余度動(dòng)態(tài)調(diào)整時(shí)，調(diào)整輸出的冗余度為滿足第一丟包率小于所述丟包門限條件下的最小值。其中，當(dāng)前業(yè)務(wù)是否支持冗余度動(dòng)態(tài)調(diào)整可以通過參數(shù)解析模塊10的輸出獲得。如果當(dāng)前業(yè)務(wù)不支持冗余度動(dòng)態(tài)調(diào)整，在本發(fā)明第四較佳實(shí)施方式中，為了盡量少占用網(wǎng)絡(luò)帶寬資源，輸出的冗余度等于最小冗余度。如果當(dāng)前業(yè)務(wù)支持冗余度動(dòng)態(tài)調(diào)整，在第二丟包率門限大于丟包門限時(shí)，本發(fā)明第四較佳實(shí)施方式中，冗余度調(diào)整模塊30在不大于最大冗余度的前提下增加冗余度；在第二丟包率連續(xù)多次小于等于丟包門限時(shí)，本發(fā)明第四較佳實(shí)施方式中，冗余度調(diào)整模塊30直接輸出冗余度為最小冗余度，這是由于此時(shí)不使用冗余進(jìn)行丟包補(bǔ)償?shù)牡诙G包率也可以滿足丟包門限的要求，因此可以不使用冗余，即可以將冗余度降低為最小冗余度，之所以連續(xù)多次出現(xiàn)才調(diào)整，是為了避免冗余度的頻繁調(diào)整和抖動(dòng)；在第二丟包率大于丟包門限，但第一丟包率小于等于丟包門限時(shí)，如果連續(xù)多次出現(xiàn)這種情況且上一次減小冗余度沒有造成第一丟包率的上升，本發(fā)明第四較佳實(shí)施方式中，冗余度調(diào)整模塊30減小輸出的冗余度。需要說明的是，冗余度調(diào)整模塊30輸出的冗余度要介于最大冗余度和最小冗余度之間；在本發(fā)明第四較佳實(shí)施方式中，為了盡量減少對于網(wǎng)絡(luò)帶寬的使用，在呼叫開始時(shí)，冗余度調(diào)整模塊30輸出的冗余度為最小冗余度。
RTP報(bào)文發(fā)送模塊40用于根據(jù)所述冗余度調(diào)整模塊30輸出的冗余度和當(dāng)前業(yè)務(wù)使用的RTP報(bào)文冗余機(jī)制輸出攜帶了冗余的RTP報(bào)文。在本發(fā)明第四較佳實(shí)施方式中，當(dāng)前業(yè)務(wù)使用的RTP報(bào)文冗余機(jī)制包含RFC2198和RFC2733定義的冗余機(jī)制?？梢岳斫?，不同的冗余機(jī)制通過不同的特征體現(xiàn)冗余度的大小。例如，對于RFC2198，每個(gè)RTP報(bào)文攜帶的冗余包個(gè)數(shù)越多則冗余度越大；而對于RFC2733，冗余糾錯(cuò)方案能夠糾正的連續(xù)丟包數(shù)越多冗余度越大。
雖然通過參照本發(fā)明的某些優(yōu)選實(shí)施方式，已經(jīng)對本發(fā)明進(jìn)行了圖示和描述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細(xì)節(jié)上對其作各種改變，而不偏離本發(fā)明的精神和范圍。
權(quán)利要求
1.一種實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，包含以下步驟A呼叫建立時(shí)確定當(dāng)前業(yè)務(wù)的最大冗余度、最小冗余度以及丟包門限；C呼叫進(jìn)行時(shí)，統(tǒng)計(jì)利用冗余進(jìn)行丟包補(bǔ)償后的第一丟包率，并在所述最大冗余度和最小冗余度范圍內(nèi)根據(jù)網(wǎng)絡(luò)傳輸質(zhì)量調(diào)整實(shí)時(shí)傳輸協(xié)議報(bào)文的冗余度，將該冗余度調(diào)整為滿足所述第一丟包率小于所述丟包門限條件下的最小值。
2.根據(jù)權(quán)利要求1所述的實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，在所述步驟A與C之間還包含以下步驟B判斷當(dāng)前業(yè)務(wù)是否支持動(dòng)態(tài)調(diào)整所述實(shí)時(shí)傳輸協(xié)議報(bào)文的冗余度，如果是則進(jìn)入步驟C，否則使用固定的冗余度進(jìn)行所述實(shí)時(shí)傳輸協(xié)議報(bào)文的傳輸。
3.根據(jù)權(quán)利要求1所述的實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，所述步驟C還包含以下子步驟C1判斷第一丟包率是否大于所述丟包門限，如果是則進(jìn)入步驟C2，否則進(jìn)入步驟C3；C2在小于等于最大冗余度的前提下增加所述冗余度；C3在大于等于最小冗余度的前提下減小或維持所述冗余度。
4.根據(jù)權(quán)利要求3所述的實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，所述步驟C3還包含以下子步驟C31判斷不進(jìn)行丟包補(bǔ)償?shù)牡诙G包率連續(xù)小于等于所述丟包門限的次數(shù)是否超過閾值，如果是則進(jìn)入步驟C32，否則進(jìn)入步驟C33；C32在大于等于最小冗余度的前提下減小所述冗余度；C33維持所述冗余度。
5.根據(jù)權(quán)利要求4所述的實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，所述步驟C32中，一次性將所述冗余度減小為最小冗余度。
6.根據(jù)權(quán)利要求3所述的實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，所述步驟C3還包含以下子步驟C34判斷不進(jìn)行丟包補(bǔ)償?shù)牡诙G包率連續(xù)小于等于所述丟包門限的次數(shù)是否超過閾值，如果是則進(jìn)入步驟C35，否則進(jìn)入步驟C36；C35在大于等于所述最小冗余度的前提下減小所述冗余度；C36判斷第一丟包率連續(xù)小于所述丟包門限的次數(shù)是否超過閾值，且當(dāng)前的所述冗余度是否大于最小冗余度且不為0，且前一次減小所述冗余度后第一丟包率是否沒有上升，如果均是則減小所述冗余度，否則維持所述冗余度。
7.根據(jù)權(quán)利要求6所述的實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，所述步驟C35中，一次性將所述冗余度減小為最小冗余度。
8.根據(jù)權(quán)利要求3所述的實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，通過實(shí)時(shí)傳輸控制協(xié)議的擴(kuò)展部分?jǐn)y帶進(jìn)行丟包補(bǔ)償后的累計(jì)丟包數(shù)。
9.根據(jù)權(quán)利要求1至8中任一項(xiàng)所述的實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法，其特征在于，還包含以下步驟E呼叫建立時(shí)，使用最小冗余度進(jìn)行所述實(shí)時(shí)傳輸協(xié)議報(bào)文的傳輸。
10.一種實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的系統(tǒng)，其特征在于，包含，參數(shù)解析模塊、丟包率統(tǒng)計(jì)模塊和冗余度調(diào)整模塊，其中，所述參數(shù)解析模塊，用于解析當(dāng)前業(yè)務(wù)的最大冗余度、最小冗余度、丟包門限，并輸出到所述冗余度調(diào)整模塊；所述丟包率統(tǒng)計(jì)模塊，用于統(tǒng)計(jì)利用冗余進(jìn)行丟包補(bǔ)償后的第一丟包率，并輸出到所述冗余度調(diào)整模塊；所述冗余度調(diào)整模塊，用于在所述最大冗余度和最小冗余度范圍內(nèi)根據(jù)網(wǎng)絡(luò)傳輸質(zhì)量調(diào)整實(shí)時(shí)傳輸協(xié)議報(bào)文的冗余度，將該冗余度調(diào)整為滿足所述第一丟包率小于所述丟包門限條件下的最小值。
全文摘要
本發(fā)明涉及通信技術(shù)，公開了一種實(shí)現(xiàn)實(shí)時(shí)傳輸協(xié)議報(bào)文冗余機(jī)制的方法及其系統(tǒng)，使得使用RTP冗余機(jī)制時(shí)既可以避免帶寬的浪費(fèi)也可以滿足業(yè)務(wù)丟包率需求。本發(fā)明中，在呼叫進(jìn)行中根據(jù)網(wǎng)絡(luò)傳輸環(huán)境動(dòng)態(tài)調(diào)整冗余度。在最大、最小冗余度范圍內(nèi)，將冗余度動(dòng)態(tài)調(diào)整為滿足進(jìn)行丟包補(bǔ)償后的第一丟包率小于丟包門限條件下的最小值。呼叫建立時(shí)使用最小冗余度。
文檔編號H04L29/06GK101030832SQ20061002434
公開日2007年9月5日 申請日期2006年3月3日 優(yōu)先權(quán)日2006年3月3日
發(fā)明者陳誠, 劉振華 申請人:華為技術(shù)有限公司