一種VOLTE視頻電話傳輸方法及其系統與流程

2023-10-19 23:29:27

本發明涉及信息技術領域，特別涉及一種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視頻電話數據包時，存儲所發送的數據包的備份；還用於在發送端接收到反饋信息時，根據所接收到的反饋信息確定接收端已接收到的數據包，將接收端已接收到的數據包從發送端緩存中釋放。

由於第三實施方式與本實施方式相互對應，因此本實施方式可與第三實施方式互相配合實施。第三實施方式中提到的相關技術細節在本實施方式中依然有效，在第三實施方式中所能達到的技術效果在本實施方式中也同樣可以實現，為了減少重複，這裡不再贅述。相應地，本實施方式中提到的相關技術細節也可應用在第三實施方式中。

本領域的普通技術人員可以理解，上述各實施方式是實現本發明的具體實施例，而在實際應用中，可以在形式上和細節上對其作各種改變，而不偏離本發明的精神和範圍。