本發(fā)明涉及信息技術(shù)領(lǐng)域，特別涉及一種VOLTE視頻電話傳輸方法及其系統(tǒng)。

背景技術(shù)：

VOLTE(Voice over LTE，LTE網(wǎng)絡視頻電話)視頻電話業(yè)務是4G通信的核心業(yè)務之一，也是區(qū)別于傳統(tǒng)通話服務的一大功能進步，其中，VOLTE一種IP數(shù)據(jù)傳輸技術(shù)，視頻數(shù)據(jù)使用RTP(Real-time Transport Protocol，實時傳輸協(xié)議)傳輸，控制信息通過RTCP(RTP Control Protocol，實時傳輸控制協(xié)議)傳輸，使用SIP(Session Initiation Protocol，會話初始協(xié)議)協(xié)商視頻傳輸參數(shù)。與一般的視頻流媒體服務不同的是，視頻電話業(yè)務的重點在于實時交互性，這就意味著必須嚴格控制傳輸延時，不能像流媒體那樣建立較長的數(shù)據(jù)緩沖區(qū)，否則會明顯影響用戶體驗。另外由于視頻數(shù)據(jù)對丟包很敏感，如果出現(xiàn)丟包則無法正確解碼圖像，而圖像錯誤會累積，直到下一個關(guān)鍵幀出現(xiàn)。因此對于VOLTE視頻電話業(yè)務來說，數(shù)據(jù)的傳輸質(zhì)量對圖像效果有直接影響。

目前針對丟包的的處理方式主要分為通過帶外信息反饋實現(xiàn)丟包重傳，或者直接通過帶內(nèi)信息反饋實現(xiàn)丟包重傳。帶外重傳主要是采用RTP/AVPF(Audio-Visual Profile with Feedback，音視頻傳輸反饋)機制，通過RTCP反饋NACK(非應答)消息，通知發(fā)送端重傳丟失的數(shù)據(jù)包。帶內(nèi)重傳主要是將反饋信息加入RTP包中，通過視頻傳輸通道反饋給發(fā)送端，發(fā)送端解析出該信息后重傳數(shù)據(jù)。但是這些方法仍然有局限性：

第一，重傳延時過長。對于RTP來說沒有明確的丟包指示，通常由接收端進行統(tǒng)計。如果發(fā)現(xiàn)數(shù)據(jù)包超過規(guī)定時間仍未收到則判定為丟包，會造成當發(fā)現(xiàn)丟包時已經(jīng)接近或超過該數(shù)據(jù)包的正常播放時間了，再加上反饋消息等待數(shù)據(jù)重傳，導致視頻延時過大(可能達到幾秒)；如果一發(fā)現(xiàn)數(shù)據(jù)包序列號錯誤就立即反饋重傳，那么，這樣看似可以減少重傳延時，但是由于數(shù)據(jù)包僅僅是亂序而不是丟包，從而產(chǎn)生過多的反饋消息，最終導致發(fā)送端發(fā)起很多不必要數(shù)據(jù)重傳，反而會造成帶寬緊張，進一步產(chǎn)生丟包，最終花費更多的時間在數(shù)據(jù)重傳上。

第二，丟包信息不能可靠地反饋。帶外重傳使用RTCP，在VOLTE視頻電話業(yè)務中RTCP帶寬需要事先協(xié)商，而且通常很低，意味著不能隨意發(fā)送RTCP消息，實際需要反饋多少信息很難預估，有可能導致RTCP丟包，而丟包信息通常只反饋一次，一旦丟包就會影響重傳效果。對于帶內(nèi)重傳來說，雖然使用視頻通道回傳消息不存在帶寬問題，但是RTP本身也會丟包，所以反饋消息還是可能因為數(shù)據(jù)丟包而無法傳遞到發(fā)送端。

第三，系統(tǒng)開銷大。無論是帶內(nèi)還是帶外反饋，接收端通常僅在出現(xiàn)丟包后反饋信息，所以發(fā)送端只能知道接收端丟了哪些數(shù)據(jù)，而無法得知收到了哪些數(shù)據(jù)，或已經(jīng)播放了哪些數(shù)據(jù)。導致發(fā)送端只能盡可能多的把已經(jīng)發(fā)送的視頻數(shù)據(jù)包緩存起來，以保證收到丟包反饋消息時能夠重傳對應的數(shù)據(jù)包。但是由于視頻碼流高、數(shù)據(jù)量大，大量緩存數(shù)據(jù)會占用過多系統(tǒng)內(nèi)存，特別是在嵌入式環(huán)境中內(nèi)存容量本來就很有限，可能因為內(nèi)存不足導致運行錯誤。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于提供一種VOLTE視頻電話傳輸方法及其系統(tǒng)，使得發(fā)送端能夠及時檢查是否丟包，并在丟包時，實現(xiàn)可靠快速的數(shù)據(jù)重傳，降 低總體延時、降低系統(tǒng)開銷。

為解決上述技術(shù)問題，本發(fā)明的實施方式提供了一種VOLTE視頻電話傳輸方法，包含以下步驟：

接收端接收VOLTE視頻電話數(shù)據(jù)包，向發(fā)送端發(fā)送反饋信息；其中，所述反饋信息為所述數(shù)據(jù)包的接收狀態(tài)；所述發(fā)送端根據(jù)所接收到的反饋信息判斷是否存在丟包；如果存在，則重傳丟失的數(shù)據(jù)包。

本發(fā)明的實施方式還提供了一種VOLTE視頻電話傳輸系統(tǒng)，包含：接收端和發(fā)送端；所述接收端包含：通信模塊，用于接收VOLTE視頻電話數(shù)據(jù)包；向發(fā)送端發(fā)送反饋信息；其中，所述反饋信息為所述數(shù)據(jù)包的接收狀態(tài)；所述發(fā)送端包含：丟包判定模塊，用于根據(jù)所接收到的反饋信息判斷是否存在丟包；并在判定為存在丟包時，重傳丟失的數(shù)據(jù)包。

本發(fā)明實施方式相對于現(xiàn)有技術(shù)而言，本發(fā)明實施方式相對于現(xiàn)有技術(shù)而言，主要區(qū)別及效果在于：接收端通過向發(fā)送端反饋VOLTE視頻電話數(shù)據(jù)包的接收狀態(tài)，使發(fā)送端快速了解數(shù)據(jù)包是否發(fā)送成功，從而由發(fā)送端確定是否存在丟包。即使反饋信息被丟包，也可以通過后續(xù)的反饋信息進一步確定是否存在丟包，大大提高丟包判定的可靠性，從而使得本發(fā)明實施方式實現(xiàn)可靠快速的數(shù)據(jù)重傳，減少時延，避免增加帶寬負擔。

另外，在所述向發(fā)送端發(fā)送反饋信息的步驟中，通過實時傳輸協(xié)議RTP包向所述發(fā)送端進行帶內(nèi)反饋。通過RTP包向發(fā)送端進行帶內(nèi)反饋，不會占用RTCP傳輸消息的帶寬，也不會影響帶內(nèi)視頻碼流傳輸，使得即使頻繁發(fā)送也不會對現(xiàn)有數(shù)據(jù)傳輸造成影響，從而保證發(fā)送反饋信息穩(wěn)定。

另外，所述數(shù)據(jù)包對應有唯一序列號；在所述向發(fā)送端發(fā)送反饋信息的步驟中，通過發(fā)送已接收數(shù)據(jù)包的序列號指示所述數(shù)據(jù)包的接收狀態(tài)為已接收；在所述判斷是否存在丟包的步驟中，如果所述發(fā)送端已發(fā)送的數(shù)據(jù)包所對應的序列號不在所接收到的反饋信息中，則判定所述數(shù)據(jù)包丟失。通過 該步驟，可以使本發(fā)明實施方式中的發(fā)送端，無需等待接收端的報告，通過判斷發(fā)送端已發(fā)送的數(shù)據(jù)所對應的序列號在不在所接收到的反饋信息中，實現(xiàn)通過反饋信息自身就能判斷數(shù)據(jù)包是否丟失，進一步降低總體延時。

另外，在所述發(fā)送已接收數(shù)據(jù)包的序列號的步驟中，將需發(fā)送的序列號進行編碼后再發(fā)送；在所述判斷是否存在丟包的步驟中，還包含以下子步驟：解碼接收到的反饋信息，獲得所述狀態(tài)為已接收狀態(tài)的數(shù)據(jù)包對應的序列號。通過該步驟，可以減少反饋信息在RTP擴展包頭中所占的數(shù)據(jù)開銷，從而增加本發(fā)明實施方式的實用性，有利于本發(fā)明實施方式的推廣。

另外，在所述發(fā)送已接收數(shù)據(jù)包的序列號的步驟前，還包含以下步驟：檢測待發(fā)送序列號對應的數(shù)據(jù)包的播放狀態(tài)；在所述發(fā)送已接收數(shù)據(jù)包的序列號的步驟中，發(fā)送未播放的數(shù)據(jù)包所對應的序列號。通過該步驟，可以進一步降低反饋信息在RTP擴展包頭中所占的數(shù)據(jù)開銷。

另外，所述發(fā)送端發(fā)送所述VOLTE視頻電話數(shù)據(jù)包時，將所發(fā)送的數(shù)據(jù)包備份至發(fā)送端緩存；在所述發(fā)送端在接收到所述反饋信息后，還包含以下步驟：所述發(fā)送端根據(jù)所接收到的反饋信息確定所述接收端已接收到的數(shù)據(jù)包，將所述接收端已接收到的數(shù)據(jù)包從所述發(fā)送端緩存中釋放。通過該步驟，可以使本發(fā)明實施方式中的發(fā)送端能根據(jù)所接收到的反饋信息確定接收端已接收到的數(shù)據(jù)包，并且將已接收到的數(shù)據(jù)包從發(fā)送端緩存中釋放，從而減小了緩存量，降低了系統(tǒng)開銷。

附圖說明

圖1是根據(jù)本發(fā)明第一實施方式一種VOLTE視頻電話傳輸方法的流程示意圖；

圖2是根據(jù)本發(fā)明第二實施方式一種VOLTE視頻電話傳輸方法的流程示意圖；

圖3是根據(jù)本發(fā)明第三實施方式一種VOLTE視頻電話傳輸方法的流程示意圖；

圖4是根據(jù)本發(fā)明第三實施一種VOLTE視頻電話傳輸方法的丟包重傳流程示意圖；

圖5是根據(jù)本發(fā)明第四實施方式一種VOLTE視頻電話傳輸系統(tǒng)的方框示意圖；

圖6是根據(jù)本發(fā)明第五實施方式一種VOLTE視頻電話傳輸系統(tǒng)的丟包判定模塊的方框示意圖；

圖7是根據(jù)本發(fā)明第六實施方式一種VOLTE視頻電話傳輸系統(tǒng)的方框示意圖；

圖8是是根據(jù)本發(fā)明第一實施方式一種VOLTE視頻電話傳輸方法中反饋消息的格式示意圖；

圖9是根據(jù)本發(fā)明第一實施方式一種VOLTE視頻電話傳輸方法中反饋消息的另一種格式示意圖；

圖10是根據(jù)本發(fā)明第一實施方式一種VOLTE視頻電話傳輸方法中反饋消息的另一中格式示意圖；

圖11是是根據(jù)本發(fā)明第一實施方式一種VOLTE視頻電話傳輸方法中反饋消息的另一中格式示意圖。

具體實施方式

為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā)明的各實施方式進行詳細的闡述。然而，本領(lǐng)域的普通技術(shù)人員可以理解，在本發(fā)明各實施方式中，為了使讀者更好地理解本申請而提出了許多技術(shù)細節(jié)。但是，即使沒有這些技術(shù)細節(jié)和基于以下各實施方式的種種變化和 修改，也可以實現(xiàn)本申請各權(quán)利要求所要求保護的技術(shù)方案。

本發(fā)明的第一實施方式涉及一種VOLTE視頻電話傳輸方法。其流程如圖1所示，具體如下：

步驟101，接收端接收VOLTE視頻電話數(shù)據(jù)包，向發(fā)送端發(fā)送反饋信息。

具體而言，接收端接收VOLTE視頻電話數(shù)據(jù)包，可以是VOLTE語音傳輸和VOLTE視頻傳輸，可以通過實時傳輸協(xié)議RTP包向發(fā)送端發(fā)送反饋信息。其中，反饋信息為數(shù)據(jù)包的接收狀態(tài)。數(shù)據(jù)包的接收狀態(tài)，可以有已接收和未收到狀態(tài)。

值得一提的是，反饋信息的發(fā)送頻率可以自由控制，不需要每個RTP包都攜帶反饋信息，可以只在接收端數(shù)據(jù)緩沖狀態(tài)發(fā)生變化時，向發(fā)送端反饋信息。比如說，當接收端新收到數(shù)據(jù)包，或數(shù)據(jù)包被播放時，接收端就可以向發(fā)送端反饋信息。

在本實施方式中，由于數(shù)據(jù)包對應有唯一序列號，所以接收端通過發(fā)送已接收數(shù)據(jù)包的序列號指示數(shù)據(jù)包的接收狀態(tài)為已接收。

步驟102，發(fā)送端根據(jù)所接收到的反饋信息判斷是否存在丟包。若判斷為是，則進入步驟103；若判斷為否，則結(jié)束本流程。

步驟103，發(fā)送端重傳丟失的數(shù)據(jù)包。

具體的說，發(fā)送端可以根據(jù)接收到的反饋信息，獲得狀態(tài)為已接收狀態(tài)的數(shù)據(jù)包對應的序列號，然后根據(jù)判斷發(fā)送端已發(fā)送的數(shù)據(jù)包所對應的序列號是否在所接收到的反饋信息中，判斷是否丟包。若判斷丟包，發(fā)送端重傳丟失的數(shù)據(jù)包。也就是說，反饋信息以RTP包序列號來表示，發(fā)送端將接收端已接收的RTP數(shù)據(jù)區(qū)段逐個列出，各個區(qū)段之間的空洞區(qū)域即為丟包區(qū)域。而且，由于是發(fā)送端將接收端已接收的RTP數(shù)據(jù)區(qū)段逐個列出來判斷是 否丟包，所以當發(fā)送端反饋接收端時再次丟包，發(fā)送端也可以通過后續(xù)消息得知所有的丟包情況，不會因為丟包導致反饋信息遺漏。

比如說，反饋信息可以表示為：Seq0-Seq1，Seq3-Seq4，……。通過這個反饋消息可以得知：由于后續(xù)數(shù)據(jù)包已經(jīng)接收，Seq1至Seq3之間處于空洞區(qū)域，所以Seq1至Seq3之間的數(shù)據(jù)包可能丟包了，發(fā)送端重傳Seq1-Seq3的數(shù)據(jù)包；如果Seq4之后沒有其他反饋信息了，則說明接收端尚未接收到Seq4之后的數(shù)據(jù)包。當發(fā)送端重傳Seq1-Seq3數(shù)據(jù)包后，接收到的反饋信息依然為：Seq0-Seq1，Seq3-Seq4，……，那么發(fā)送端可以判斷傳Seq1-Seq3數(shù)據(jù)包再次丟包，會再次重傳Seq1-Seq3數(shù)據(jù)包，直到根據(jù)接收到反饋信息確定Seq1-Seq3數(shù)據(jù)包被接收端接收為止。

需要說明的是，在本實施方式中，接收端只負責將數(shù)據(jù)包的接收狀態(tài)反饋給發(fā)送端，不進行是否丟包的判斷，而是由發(fā)送端根據(jù)判斷發(fā)送端已發(fā)送的數(shù)據(jù)包所對應的序列號是否在所接收到的反饋信息中，判斷是否丟包，無需等待接收端的報告，從而可以降低總體延時，控制重傳節(jié)奏，在不影響正常數(shù)據(jù)的情況下使接收端盡快收到丟失的數(shù)據(jù)包，不會造成明顯的解碼播放延時；而且，不會如接收端那樣，數(shù)據(jù)包只會重傳一次，而是根據(jù)所接收到的反饋信息確定某數(shù)據(jù)包丟包后，多次重傳，直至確定某數(shù)據(jù)包已被接收端接收為止，從而能保證丟包信息可靠傳達。

較佳的，接收端可以將需發(fā)送的序列號進行編碼后再發(fā)送，發(fā)送端會先解碼接收到的反饋信息，然后進行丟包判斷。其中，反饋信息由RTP擴展包頭攜帶傳遞。其編碼過程如下所示：

反饋消息通過RTP Header Extension傳遞，RTP Header格式為如圖8所示，待將圖8中的X比特置位后，可以啟用Header Extension，其格式如圖9所示。

圖9中的defined by profile用于區(qū)分不同的RTP Header Extension，該字段可以根據(jù)實際使用環(huán)境來約定，如果遇到不支持本方法的終端，可以跳過反饋信息，不影響解碼；length表明Header Extension的具體長度；header extension為信息具體內(nèi)容。

在本實施方式中，具體的反饋信息填寫在header extension中，格式如圖10所示。

圖10中的SSRC為發(fā)送端RTP數(shù)據(jù)流的SSRC，以便發(fā)送端區(qū)分不同的反饋信息；sequence number表示起始RTP包序列號，固定占用16比特；len和delta表示后續(xù)的RTP包序列號，長度可變，序列號要成對出現(xiàn)，用來指示一個序列號區(qū)段，但區(qū)段總數(shù)不限；end marker表示序列號區(qū)段結(jié)束，固定為“11111110”；最后為pad部分(填充0)，以保持32比特對齊。

RTP包序列號為16位無符號數(shù)，所以表示一個序列號區(qū)段就要占用32比特，為了提高傳輸效率需要盡量減少反饋信息長度。在實時系統(tǒng)中，緩存的視頻包數(shù)量不會很大，所以反饋信息中的RTP包序列號通常上集中在一個小范圍內(nèi)，因此只要完整傳遞第一個序列號值(sequence number字段)，后續(xù)僅僅傳遞序列號增量即可(len和delta字段)。為了進一步壓縮數(shù)據(jù)量，len和delta字段為可變長度。解碼時首先從數(shù)據(jù)流中解碼len字段(len應當與end marker區(qū)分開)，可以得到delta的比特長度，然后讀取該長度數(shù)據(jù)即為delta，最后根據(jù)len和delta的值合成序列號。

len編碼規(guī)則為：當len為0至6時，直接轉(zhuǎn)換為3比特數(shù)據(jù)；len為7至16時，先填寫3比特前綴“111”,然后跟隨n個“1”，最后為“0”，中間“1”的個數(shù)與len數(shù)值相關(guān)。

序列號增量的計算方法為：當len>0時，序列號增量＝1<<(len-1)+delta；當len＝0時，序列號增量＝0。上一個序列號加上當前序列號增量，即可得到當前序列號值。

具體編碼如下，序列號增量越小碼字越短，大多數(shù)情況下RTP包序列號集中在小范圍內(nèi)，因此可以得到較高的傳輸效率，如下表格1所示。

表格1

例如，如果反饋消息為Seq103-Seq210，Seq212-Seq215，Seq220-Seq240，則用序列號增量表示為：103(起始序列號)、107、2、3、5、20。具體數(shù)值和對應碼字為：

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所示。

當然，在實際應用中，還有其他實現(xiàn)方式，此處不再列舉。

通過本實施方式，接收端通過向發(fā)送端反饋VOLTE視頻電話數(shù)據(jù)包的 接收狀態(tài)，使發(fā)送端快速了解數(shù)據(jù)包是否發(fā)送成功，從而由發(fā)送端確定是否存在丟包。即使反饋信息被丟包，也可以通過后續(xù)的反饋信息進一步確定是否存在丟包，大大提高丟包判定的可靠性，從而使得本發(fā)明實施方式實現(xiàn)可靠快速的數(shù)據(jù)重傳，減少時延，避免增加帶寬負擔。

本發(fā)明的第二實施方式涉及一種VOLTE視頻電話傳輸方法。第二實施方式與第一實施方式大致相同，主要區(qū)別之處在于：如圖2所示，在本發(fā)明第二實施方式中，接收端增加檢測待發(fā)送序列號對應的數(shù)據(jù)包的播放狀態(tài)，以便只發(fā)送未播放的數(shù)據(jù)包對應的序列號，這樣，可以減小接收端發(fā)送的序列號的數(shù)量，從而減少數(shù)據(jù)傳輸量，提高傳輸效率。

不同之處在于：步驟201，檢測待發(fā)送序列號對應的數(shù)據(jù)包的播放狀態(tài)。

具體而言，接收端可以將數(shù)據(jù)包的接收狀態(tài)，分為已接收且已播放的RTP包序列號、未接收到的RTP包序列號、已接收但未播放的RTP包序列號，然后將已接收但未播放的RTP包序列號反饋給發(fā)送端，已接收且已播放的RTP包序列號不再反饋給發(fā)送端。

本實施方式中的步驟202至204與第一實施方式中的步驟101至103相同，此處不做贅述。

通過本實施方式，可以減小接收端發(fā)送的序列號的數(shù)量，從而減少數(shù)據(jù)傳輸量，提高傳輸效率，進而提高用戶的使用體驗。

本發(fā)明的第三實施方式涉及一種VOLTE視頻電話傳輸方法。第三實施方式與第二實施方式大致相同，主要區(qū)別之處在于：如圖3所示，在本發(fā)明第三實施方式中，發(fā)送端根據(jù)所接收到的反饋信息確定接收端已接收到的數(shù)據(jù)包，然后將這些數(shù)據(jù)包從發(fā)送端緩存中釋放，以減小緩存量，降低系統(tǒng)開銷。

本實施方式中的步驟301、302與第二實施方式中的步驟201、202相同，此處不做贅述。不同之處在于：

步驟303，發(fā)送端根據(jù)所接收到的反饋信息確定接收端已接收到的數(shù)據(jù)包，將接收端已接收到的數(shù)據(jù)包從發(fā)送端緩存中釋放。

具體而言，接收端可以將數(shù)據(jù)包的接收狀態(tài)，分為已接收且已播放的RTP包序列號、未接收到的RTP包序列號、已接收但未播放的RTP包序列號，然后將已接收但未播放的RTP包序列號反饋給發(fā)送端。發(fā)送端接收到反饋信息后，可以判斷已接收但未播放的RTP包序列號之前的RTP序列號是已接收且已播放的，已接收但未播放的RTP包序列號之后的RTP序列號是未接收到的。由于發(fā)送端在發(fā)送VOLTE視頻電話數(shù)據(jù)包時，會將所發(fā)送的數(shù)據(jù)包備份至發(fā)送端緩存，占用相當大的系統(tǒng)內(nèi)存，所以將已接收的數(shù)據(jù)包從發(fā)送端緩存中釋放，可以減小緩存量，降低系統(tǒng)開銷。

舉例說明本實施方式丟包重傳流程如圖4所示：

起始狀態(tài)，終端A的視頻緩存中保存著Seq90至Seq100的數(shù)據(jù)包，終端B的接收緩存已收到Seq90至Seq99的數(shù)據(jù)包。

終端A發(fā)送Seq100的數(shù)據(jù)包。

終端B收到Seq100后，反饋已收到Seq90至Seq100的數(shù)據(jù)包。

終端A收到反饋消息后，從視頻緩存中釋放Seq90至Seq100的數(shù)據(jù)包，同時新編碼的數(shù)據(jù)包Seq101加入視頻緩存，然后發(fā)送Seq101，傳輸中出現(xiàn)丟包。

終端A將新編碼的數(shù)據(jù)包Seq102加入視頻緩存，然后發(fā)送Seq102。

終端B收到Seq102后，反饋已收到Seq90至Seq100、Seq102。

終端A收到反饋消息后，發(fā)現(xiàn)終端B未收到Seq101，于是重傳Seq101，同時已收到的Seq102被釋放。

終端B收到Seq101后，反饋已收到Seq90至Seq102。

終端A收到反饋消息后，得知終端B已收到Seq101，然后釋放視頻緩 存的數(shù)據(jù)。

本實施方式中的步驟304、305與第二實施方式中的步驟203、204相同，此處不做贅述。

通過本實施方式，發(fā)送端能根據(jù)所接收到的反饋信息確定接收端已接收到的數(shù)據(jù)包，并且將已接收到的數(shù)據(jù)包從發(fā)送端緩存中釋放，從而減小了緩存量，降低了系統(tǒng)開銷，有利于本發(fā)明的推廣。

上面各種方法的步驟劃分，只是為了描述清楚，實現(xiàn)時可以合并為一個步驟或者對某些步驟進行拆分，分解為多個步驟，只要包含相同的邏輯關(guān)系，都在本專利的保護范圍內(nèi)；對算法中或者流程中添加無關(guān)緊要的修改或者引入無關(guān)緊要的設計，但不改變其算法和流程的核心設計都在該專利的保護范圍內(nèi)。

本發(fā)明第四實施方式涉及一種VOLTE視頻電話傳輸系統(tǒng)，如圖5所示，包含：接收端和發(fā)送端。

接收端包含：通信模塊，用于接收VOLTE視頻電話數(shù)據(jù)包；還用于向發(fā)送端發(fā)送反饋信息。在本實施方式中，通信模塊通過實時傳輸協(xié)議RTP包向發(fā)送端進行帶內(nèi)反饋。其中，反饋信息為數(shù)據(jù)包的接收狀態(tài)，通信模塊利用RTP擴展包頭攜帶反饋信息，

發(fā)送端包含：丟包判定模塊，用于根據(jù)所接收到的反饋信息判斷是否存在丟包；并在判定為存在丟包時，重傳丟失的數(shù)據(jù)包。

值得一提的是，數(shù)據(jù)包對應有唯一序列號。接收端的通信模塊通過發(fā)送已接收數(shù)據(jù)包的序列號指示數(shù)據(jù)包的接收狀態(tài)為已接收；發(fā)送端的丟包判定模塊，在發(fā)送端已發(fā)送的數(shù)據(jù)包所對應的序列號不在所接收到的反饋信息中時，判定數(shù)據(jù)包丟失。

通過本實施方式，增加了本發(fā)明實施方式的實用性，有利于在實際應用 中實現(xiàn)，從而有利于本發(fā)明實施方式的推廣。

不難發(fā)現(xiàn)，本實施方式為與第一實施方式相對應的系統(tǒng)實施例，本實施方式可與第一實施方式互相配合實施。第一實施方式中提到的相關(guān)技術(shù)細節(jié)在本實施方式中依然有效，為了減少重復，這里不再贅述。相應地，本實施方式中提到的相關(guān)技術(shù)細節(jié)也可應用在第一實施方式中。

值得一提的是，本實施方式中所涉及到的各模塊均為邏輯模塊，在實際應用中，一個邏輯單元可以是一個物理單元，也可以是一個物理單元的一部分，還可以以多個物理單元的組合實現(xiàn)。此外，為了突出本發(fā)明的創(chuàng)新部分，本實施方式中并沒有將與解決本發(fā)明所提出的技術(shù)問題關(guān)系不太密切的單元引入，但這并不表明本實施方式中不存在其它的單元。

本發(fā)明第五實施方式涉及一種VOLTE視頻電話傳輸系統(tǒng)。第五實施方式與第四實施方式大致相同，主要區(qū)別之處在于：通信模塊將需發(fā)送的序列號進行編碼后再發(fā)送。并且如圖6所示，在本發(fā)明第五實施方式中，丟包判定模塊進一步包含以下子模塊：接收子模塊、解碼子模塊、判定子模塊。

接收子模塊，用于接收反饋信息；

解碼子模塊，用于解碼接收子模塊接收到的反饋信息，獲得狀態(tài)為已接收狀態(tài)的數(shù)據(jù)包對應的序列號；

判定子模塊，用于根據(jù)解碼子模塊所獲得的序列號判斷是否存在丟包；并在判定為存在丟包時，重傳丟失的數(shù)據(jù)包。

由于第二實施方式與本實施方式相互對應，因此本實施方式可與第二實施方式互相配合實施。第二實施方式中提到的相關(guān)技術(shù)細節(jié)在本實施方式中依然有效，在第二實施方式中所能達到的技術(shù)效果在本實施方式中也同樣可以實現(xiàn)，為了減少重復，這里不再贅述。相應地，本實施方式中提到的相關(guān)技術(shù)細節(jié)也可應用在第二實施方式中。

本發(fā)明第六實施方式涉及一種VOLTE視頻電話傳輸系統(tǒng)。第六實施方式與第五實施方式大致相同，主要區(qū)別之處在于：如圖7所示，發(fā)送端包含發(fā)送端緩存器。

發(fā)送端緩存器，用于在發(fā)送端發(fā)送VOLTE視頻電話數(shù)據(jù)包時，存儲所發(fā)送的數(shù)據(jù)包的備份；還用于在發(fā)送端接收到反饋信息時，根據(jù)所接收到的反饋信息確定接收端已接收到的數(shù)據(jù)包，將接收端已接收到的數(shù)據(jù)包從發(fā)送端緩存中釋放。

由于第三實施方式與本實施方式相互對應，因此本實施方式可與第三實施方式互相配合實施。第三實施方式中提到的相關(guān)技術(shù)細節(jié)在本實施方式中依然有效，在第三實施方式中所能達到的技術(shù)效果在本實施方式中也同樣可以實現(xiàn)，為了減少重復，這里不再贅述。相應地，本實施方式中提到的相關(guān)技術(shù)細節(jié)也可應用在第三實施方式中。

本領(lǐng)域的普通技術(shù)人員可以理解，上述各實施方式是實現(xiàn)本發(fā)明的具體實施例，而在實際應用中，可以在形式上和細節(jié)上對其作各種改變，而不偏離本發(fā)明的精神和范圍。