本發(fā)明屬于通信技術(shù)領(lǐng)域，尤其涉及一種實時通話過程中基于測速的通道切換方法、客戶端與服務(wù)器。

背景技術(shù)：

隨著網(wǎng)絡(luò)傳輸速度的加快，給互聯(lián)網(wǎng)多媒體應(yīng)用帶來了機(jī)會和挑戰(zhàn)。相對于傳統(tǒng)通訊方式，互聯(lián)網(wǎng)通話更加便捷和廉價。尤其是移動互聯(lián)網(wǎng)日新月異的今天，智能手機(jī)等可聯(lián)網(wǎng)設(shè)備已隨處可見，在選擇通訊方式的時候還可以使用視訊通話。基于互聯(lián)網(wǎng)的音視頻通訊在給人們生活帶來極大便利的同時，也對音視頻通話質(zhì)量提出更高的要求。

然而，中國的互聯(lián)網(wǎng)環(huán)境極其復(fù)雜，大運營商各建網(wǎng)絡(luò)，小運營商租用網(wǎng)絡(luò)，跨運營商丟包嚴(yán)重，在高峰期時段還有連不通的情況。在現(xiàn)有網(wǎng)絡(luò)條件下，如何追求更高質(zhì)量的語音通話和高清視頻通訊，是對互聯(lián)網(wǎng)音視頻通訊的迫切要求。

本發(fā)明主要為了解決在現(xiàn)有互聯(lián)網(wǎng)環(huán)境中，如何選擇更高質(zhì)量的通話，同時減輕網(wǎng)絡(luò)帶寬負(fù)載，從而達(dá)到提高音視頻傳輸質(zhì)量，提高用戶體驗，并且降低網(wǎng)絡(luò)成本。

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

發(fā)明人在研究和實踐過程中發(fā)現(xiàn)，目前的音視頻通信過程，主要依靠服務(wù)器在客戶端之間中轉(zhuǎn)數(shù)據(jù)，數(shù)據(jù)經(jīng)過的通道是客戶端與服務(wù)器之間的中轉(zhuǎn)通道。在一般情況下，中轉(zhuǎn)通道的網(wǎng)絡(luò)狀況是良好的，然而，由于互聯(lián)網(wǎng)運營商出口帶寬以及在不同時段出現(xiàn)的網(wǎng)絡(luò)擁堵等問題，中轉(zhuǎn)通道的網(wǎng)絡(luò)狀況會出現(xiàn)劣化，不僅無法實現(xiàn)高質(zhì)量通話的要求，甚至?xí)霈F(xiàn)丟包嚴(yán)重，誤碼率高，傳輸速度慢，穩(wěn)定性差，安全性低，甚至還存在無法通話無法連通的問題。為解決上述問題，慣常的思路是改善網(wǎng)絡(luò)條件，通過設(shè)置更多數(shù)量的接口機(jī)拓寬網(wǎng)絡(luò)接口帶寬，然而硬件的增加必然帶來網(wǎng)絡(luò)耗費成本和維護(hù)費用的大幅增加。發(fā)明人發(fā)現(xiàn)，客戶終端之間可以建立直連通道，直連通道的網(wǎng)絡(luò)狀況通常劣于中轉(zhuǎn)通道，但是在中轉(zhuǎn)通道網(wǎng)絡(luò)條件劣化的情況下，二者通信條件反轉(zhuǎn)，直連通道的網(wǎng)絡(luò)條件反而要優(yōu)于所述中轉(zhuǎn)通道。

基于發(fā)明人的上述研究，本發(fā)明提出一種實時通話過程中基于測速的通道切換方法，包括如下步驟：

經(jīng)服務(wù)器建立與第二終端間的中轉(zhuǎn)通道；建立與所述第二終端間的直連通道；將所述直連通道上報所述服務(wù)器；接收所述服務(wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，并向服務(wù)器上報所述測速結(jié)果；所述服務(wù)器用于根據(jù)所述通道測速結(jié)果，確定是否切換通話通道。

優(yōu)選地，所述方法還包括檢測所述通話是否跨互聯(lián)網(wǎng)服務(wù)提供商(ISP)。

優(yōu)選地，基于網(wǎng)絡(luò)地址轉(zhuǎn)換穿越(NAT Traversal)建立與所述第二終端間的直連通道。

優(yōu)選地，所述通道測速命令至少包括測速包大小、發(fā)包間隔、發(fā)包數(shù)量和指定測速地址。

優(yōu)選地，所述直連通道測速包括向指定測速地址發(fā)送測速包，基于所述測速包的收發(fā)情況計算所述測速結(jié)果。

優(yōu)選地，所述測速結(jié)果至少包括計算網(wǎng)絡(luò)抖動、丟包率和網(wǎng)絡(luò)延時。

本發(fā)明還提出一種客戶端，所述客戶端包括如下模塊：

中轉(zhuǎn)通道建立模塊，用于經(jīng)服務(wù)器建立與第二終端間的中轉(zhuǎn)通道；

直連通道建立模塊，用于建立與所述第二終端間的直連通道；

通道上報模塊，用于將所述直連通道上報所述服務(wù)器；

測速執(zhí)行模塊，用于接收所述服務(wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，并上報測速結(jié)果；所述服務(wù)器根據(jù)所述通道測速結(jié)果，決策是否切換通話通道。

優(yōu)選地，所述直連通道建立模塊基于網(wǎng)絡(luò)地址轉(zhuǎn)換穿越(NAT Traversal)建立與所述第二終端間的直連通道。

優(yōu)選地，所述測速執(zhí)行模塊包括接收子模塊，用于接收通道測速命令。

優(yōu)選地，所述通道測速命令至少包括測速包大小、發(fā)包間隔、發(fā)包數(shù)量和指定測速地址。

優(yōu)選地，所述測速執(zhí)行模塊包括測速包收發(fā)子模塊，用于向指定測速地址發(fā)送測速包，并獲取所述測速包的收發(fā)情況。

優(yōu)選地，所述測速執(zhí)行模塊包括計算子模塊，基于所述測速包的收發(fā)情況計算網(wǎng)絡(luò)抖動、丟包率和網(wǎng)絡(luò)延時。

本發(fā)明還提出一種服務(wù)器，所述服務(wù)器包括如下模塊：

中轉(zhuǎn)通道建立模塊，用于與客戶端建立中轉(zhuǎn)通道；

測速控制模塊，用于向所述客戶端下發(fā)通道測速命令，并等待所述客戶端上報測速結(jié)果；

測速決策模塊，用于根據(jù)所述通道測速結(jié)果，決策是否切換通話通道類型。

優(yōu)選地，所述測速控制模塊包括網(wǎng)絡(luò)監(jiān)測模塊，用于監(jiān)測是否存在跨互聯(lián)網(wǎng)服務(wù)提供商(ISP)通話或者網(wǎng)絡(luò)質(zhì)量不佳,若是，服務(wù)器進(jìn)入待測速狀態(tài)。

優(yōu)選地，所述測速控制模塊包括第一接收子模塊，用接收客戶端上報的直連通道信息，若存在所述直連通道信息，且服務(wù)器處于所述待測速狀態(tài)，則向所述客戶端下發(fā)通道測速命令，進(jìn)入待接收狀態(tài)。

優(yōu)選地，所述服務(wù)器還包括中斷子模塊，用于判斷服務(wù)器中的模塊是否存在狀態(tài)超時或異常；若存在超時或異常，則結(jié)束通道測速。

本發(fā)明的有益效果：直連通道的使用可以大大降低接口機(jī)網(wǎng)絡(luò)負(fù)載，在客戶端之間網(wǎng)絡(luò)連接很差、或連接失敗的情況下，使用中轉(zhuǎn)通道進(jìn)行數(shù)據(jù)傳輸，可以有效的提高通話質(zhì)量，提升用戶體驗。

附圖說明

下面結(jié)合附圖對本發(fā)明的具體實施方式作進(jìn)一步詳細(xì)的說明；

圖1是本發(fā)明實施一提供的方法流程圖。

圖2是本發(fā)明實施二提供的方法流程圖。

圖3是本發(fā)明實施三提供的裝置原理框圖。

圖4是本發(fā)明實施四提供中轉(zhuǎn)通道模塊原理框圖。

圖5是本發(fā)明實施四提供的切換前后測速結(jié)果對比圖。

圖6是本發(fā)明實施五提供的服務(wù)器與客戶端數(shù)據(jù)交互關(guān)系圖。

圖7是本發(fā)明實施五提供的測速過程中服務(wù)器狀態(tài)圖。

具體實施方式

為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明方案，下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分的實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都應(yīng)當(dāng)屬于本發(fā)明保護(hù)的范圍。

需要說明的是，本發(fā)明的說明書和權(quán)利要求書及上述附圖中的術(shù)語“第一”、“第二”等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。應(yīng)該理解這樣使用的數(shù)據(jù)在適當(dāng)情況下可以互換，以便這里描述的本發(fā)明的實施例能夠以除了在這里圖示或描述的那些以外的順序?qū)嵤?。此外，術(shù)語“包括”和“具有”以及他們的任何變形，意圖在于覆蓋不排他的包含，例如，包含了一系列步驟或單元的過程、方法、系統(tǒng)、產(chǎn)品或設(shè)備不必限于清楚地列出的那些步驟或單元，而是可包括沒有清楚地列出的或?qū)τ谶@些過程、方法、產(chǎn)品或設(shè)備固有的其它步驟或單元。

本發(fā)明涉及的技術(shù)術(shù)語解釋如下：

NAT(network address translation)：NAT是作為一種解決IPv4地址短缺以避免保留IP地址困難的方案而流行起來的。也叫做網(wǎng)絡(luò)掩蔽或者IP掩蔽(IP masquerading)，是一種在IP封包通過路由器或防火墻時重寫來源IP地址或目的IP地址的技術(shù)。這種技術(shù)被普遍使用在有多臺主機(jī)但只通過一個公有IP地址訪問因特網(wǎng)的私有網(wǎng)絡(luò)中。

NAT traversal(network address translation traversal):NAT穿越，其目的在于解決處于使用了NAT設(shè)備的私有TCP/IP網(wǎng)絡(luò)中的主機(jī)之間建立連接的問題。

P2P(peer-to-peer):又稱點對點技術(shù)，是無中心服務(wù)器、依靠用戶群(peers)交換信息的互聯(lián)網(wǎng)體系，他的作用在于，減低以往網(wǎng)絡(luò)傳輸中的節(jié)點，以降低數(shù)據(jù)丟失的風(fēng)險。與有中心服務(wù)器的中央網(wǎng)絡(luò)系統(tǒng)不同，對等網(wǎng)絡(luò)的每個用戶端既是一個節(jié)點，也有服務(wù)器的功能，任何一個節(jié)點無法直接找到其他節(jié)點，必須依靠其戶群進(jìn)行信息交流。

直連通道：客戶端之間實現(xiàn)了NAT穿越，數(shù)據(jù)通過P2P方式傳輸。

中轉(zhuǎn)通道：客戶端之間的數(shù)據(jù)傳輸方式通過后臺服務(wù)器來中轉(zhuǎn)。

通道切換：有直連通道的情況下，數(shù)據(jù)傳輸方式在直連和中轉(zhuǎn)通道中進(jìn)行選擇。

實施例一：

本實施例提供一種實時通話過程中基于測速的通道切換方法，如圖1所示，方法包括如下步驟：

步驟S101,經(jīng)服務(wù)器建立與第二終端間的中轉(zhuǎn)通道。

步驟S102,建立與所述第二終端間的直連通道。

步驟S103,將所述直連通道上報所述服務(wù)器。

步驟S104,接收所述服務(wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，并向服務(wù)器上報所述測速結(jié)果；所述服務(wù)器綜合所述直連通道測速結(jié)果和所述中轉(zhuǎn)通道網(wǎng)絡(luò)狀況，確定是否切換通道。

在步驟S101中，用戶終端與第二終端進(jìn)行通訊，通訊包括音頻、音視頻等，客戶端之間的數(shù)據(jù)經(jīng)過服務(wù)器轉(zhuǎn)發(fā)。在通訊進(jìn)行過程中，由于通話跨互聯(lián)網(wǎng)服務(wù)提供商(ISP)或者網(wǎng)絡(luò)擁塞等造成的網(wǎng)絡(luò)狀況惡化，此時不僅無法實現(xiàn)高質(zhì)量通話的要求，甚至?xí)霈F(xiàn)丟包嚴(yán)重，誤碼率高，傳輸速度慢，穩(wěn)定性差，安全性低，甚至還存在無法通話無法連通的問題。

在步驟S102中，服務(wù)器會指揮用戶終端建立直連通道，直連通道可以使用諸如NAT穿越來實現(xiàn)，如果穿越成功，則用戶之間建立了直連通道。在通常情況下，中轉(zhuǎn)通道的網(wǎng)絡(luò)質(zhì)量是優(yōu)于直連通道的，但當(dāng)中轉(zhuǎn)通道的網(wǎng)絡(luò)劣化到一定程度，中轉(zhuǎn)通道和直連通道之間的網(wǎng)絡(luò)質(zhì)量則發(fā)生了反轉(zhuǎn)，直連通道的網(wǎng)絡(luò)質(zhì)量反而要優(yōu)于中轉(zhuǎn)通道，在此情況下，使用直連通道進(jìn)行通話可以解決中轉(zhuǎn)通道網(wǎng)絡(luò)劣化的問題。但是，究竟選擇中轉(zhuǎn)通道還是選擇直連通道并不容易決定，因為存在雖然中轉(zhuǎn)通道網(wǎng)絡(luò)條件劣化，但是中轉(zhuǎn)通道網(wǎng)絡(luò)情況仍然優(yōu)于直連通道的情況。

在步驟S103中，客戶端將第二通道上報服務(wù)器，服務(wù)器在接收到用戶上報的直連通道情況后，服務(wù)器得知用戶的通道信息，根據(jù)用戶自身的情況，向客戶端發(fā)送測速指令。通道測速命令至少包括測速包大小、發(fā)包間隔、發(fā)包數(shù)量和指定測速地址等測速參數(shù)信息。

在步驟S104中,客戶端接收服務(wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，所述直連通道測速包括向指定測速地址發(fā)送帶時戳的測速包，根據(jù)發(fā)包和收包的時間計算出網(wǎng)絡(luò)抖動、丟包率和網(wǎng)絡(luò)時延。測速結(jié)束后，客戶端向服務(wù)器上報測速結(jié)果；所述服務(wù)器綜合所述直連通道測速結(jié)果和所述中轉(zhuǎn)通道網(wǎng)絡(luò)狀況，確定是否切換通道。

實施例二：

本實施例提供一種實時通話過程中基于測速的通道切換方法，如圖2所示，方法包括如下步驟：

步驟S201,建立與客戶端之間的中轉(zhuǎn)通道，中轉(zhuǎn)客戶端之間的通訊數(shù)據(jù)。

步驟S202,接收客戶端上報的直連通道情況，并下發(fā)測速命令。

步驟S203,接收客戶端上傳的通道測速結(jié)果，根據(jù)測速結(jié)果確定是否切換通話通道。

在步驟S201中，服務(wù)器建立與客戶端之間的中轉(zhuǎn)通道，中轉(zhuǎn)客戶端之間的通訊數(shù)據(jù)。在通訊進(jìn)行過程中，由于通話跨互聯(lián)網(wǎng)服務(wù)提供商(ISP)或者網(wǎng)絡(luò)擁塞等造成的網(wǎng)絡(luò)狀況惡化，此時不僅無法實現(xiàn)高質(zhì)量通話的要求，甚至?xí)霈F(xiàn)丟包嚴(yán)重，誤碼率高，傳輸速度慢，穩(wěn)定性差，安全性低，甚至還存在無法通話無法連通的問題。

在步驟S202中，服務(wù)器會接收客戶端上報的直連通道情況，如果存在直連通道，則下發(fā)通道測速命令。通道測速命令至少包括測速包大小、發(fā)包間隔、發(fā)包數(shù)量和指定測速地址等測速參數(shù)信息。

在步驟S203中，服務(wù)器接收客戶端上傳的通道測速結(jié)果，根據(jù)測速結(jié)果確定是否切換通話通道。

實施例三：

本實施例提供一種客戶端，如圖3所示，所述客戶端包括如下模塊：

中轉(zhuǎn)通道建立模塊，用于經(jīng)服務(wù)器建立與第二終端間的中轉(zhuǎn)通道；

直連通道建立模塊，用于建立與所述第二終端間的直連通道；

通道上報模塊，用于將所述直連通道上報所述服務(wù)器；

測速控制模塊，用于接收所述服務(wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，并上報測速結(jié)果；所述服務(wù)器根據(jù)所述通道測速結(jié)果，決策是否切換通話通道。

中轉(zhuǎn)通道建立模塊，用于客戶端與第二終端建立中轉(zhuǎn)通道，中轉(zhuǎn)通道用于傳輸包括音頻、音視頻等數(shù)據(jù)流，客戶端之間的數(shù)據(jù)經(jīng)過服務(wù)器轉(zhuǎn)發(fā)。在通訊進(jìn)行過程中，由于通話跨互聯(lián)網(wǎng)服務(wù)提供商(ISP)或者網(wǎng)絡(luò)擁塞等造成的網(wǎng)絡(luò)狀況惡化，此時不僅無法實現(xiàn)高質(zhì)量通話的要求，甚至?xí)霈F(xiàn)丟包嚴(yán)重，誤碼率高，傳輸速度慢，穩(wěn)定性差，安全性低，甚至還存在無法通話無法連通的問題。

直連通道建立模塊，用于客戶端與第二終端建立直連通道。直連通道通常是由服務(wù)器指揮用戶終端建立，直連通道可以使用諸如NAT穿越來實現(xiàn)，如果穿越成功，則用戶之間建立了直連通道。在通常情況下，中轉(zhuǎn)通道的網(wǎng)絡(luò)質(zhì)量是優(yōu)于直連通道的，但當(dāng)中轉(zhuǎn)通道的網(wǎng)絡(luò)劣化到一定程度，中轉(zhuǎn)通道和直連通道之間的網(wǎng)絡(luò)質(zhì)量則發(fā)生了反轉(zhuǎn)，直連通道的網(wǎng)絡(luò)質(zhì)量反而要優(yōu)于中轉(zhuǎn)通道，在此情況下，使用直連通道進(jìn)行通話可以解決中轉(zhuǎn)通道網(wǎng)絡(luò)劣化的問題。但是，究竟選擇中轉(zhuǎn)通道還是選擇直連通道并不容易決定，因為存在雖然中轉(zhuǎn)通道網(wǎng)絡(luò)條件劣化，但是中轉(zhuǎn)通道網(wǎng)絡(luò)條件仍然優(yōu)于直連通道的情況，在此情況下，如果將中轉(zhuǎn)通道切換為直連通道，無疑不會改善用戶的通話質(zhì)量，甚至可能會造成不良的用戶體驗。因此，需要對中轉(zhuǎn)通道和直連通道的網(wǎng)絡(luò)狀況進(jìn)行綜合評價，以確定是否進(jìn)行通道的切換操作。

通道上報模塊，用于將所述直連通道上報所述服務(wù)器?？蛻舳藢⒌诙ǖ郎蠄蠓?wù)器，服務(wù)器在接收到用戶上報的直連通道情況后，服務(wù)器得知用戶的通道信息，根據(jù)用戶自身的情況，向客戶端發(fā)送測速指令。通道測速命令至少包括測速包大小、發(fā)包間隔、發(fā)包數(shù)量和指定測速地址等測速參數(shù)信息。

測速執(zhí)行模塊，用于接收所述服務(wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，并上報測速結(jié)果?？蛻舳私邮辗?wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，所述直連通道測速包括向指定測速地址發(fā)送帶時戳的測速包，根據(jù)發(fā)包和收包的時間計算出網(wǎng)絡(luò)抖動、丟包率和網(wǎng)絡(luò)時延。測速結(jié)束后，客戶端向服務(wù)器上報測速結(jié)果；所述服務(wù)器綜合所述直連通道測速結(jié)果和所述中轉(zhuǎn)通道網(wǎng)絡(luò)狀況，確定是否切換通道。

本實施例還提供一種服務(wù)器，配合客戶端使用，如圖3所示，

測速控制模塊，服務(wù)器接收客戶端上報的直連通道情況，在得知用戶的通道信息后，根據(jù)用戶自身的情況，向客戶端發(fā)送測速指令并等待所述客戶端端上報測速結(jié)果。通道測速命令至少包括測速包大小、發(fā)包間隔、發(fā)包數(shù)量和指定測速地址等測速參數(shù)信息。

客戶端用于接收服務(wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，所述直連通道測速包括向指定測速地址發(fā)送帶時戳的測速包，根據(jù)發(fā)包和收包的時間計算出網(wǎng)絡(luò)抖動、丟包率和網(wǎng)絡(luò)時延。

服務(wù)器的測速決策模塊，等待客戶端上報的測速結(jié)果，根據(jù)所述通道測速結(jié)果情況，決策是否切換通話通道類型。

實施例四：

客戶端接收服務(wù)器下發(fā)的通道測速命令，進(jìn)行直連通道測速，所述直連通道測速包括向指定測速地址發(fā)送帶時戳的測速包，根據(jù)發(fā)包和收包的時間計算出網(wǎng)絡(luò)抖動、丟包率和網(wǎng)絡(luò)時延。測速結(jié)束后，客戶端向服務(wù)器上報測速結(jié)果；服務(wù)器用于根據(jù)所述通道測速結(jié)果，確定是否切換通話通道。

網(wǎng)絡(luò)抖動是指數(shù)據(jù)包在網(wǎng)絡(luò)中傳輸延時的變化，如果網(wǎng)絡(luò)出現(xiàn)擁塞，網(wǎng)絡(luò)上的節(jié)點設(shè)備隊列增大，將導(dǎo)致數(shù)據(jù)包的傳輸延時變大，而網(wǎng)絡(luò)條件變好將導(dǎo)致網(wǎng)絡(luò)傳輸延時變小。

實際音視頻通話過程中，網(wǎng)絡(luò)抖動對通話效果影響明顯，嚴(yán)重影響到用戶的體驗。在本實施例中，在中轉(zhuǎn)通道設(shè)置可變的抖動緩沖區(qū)(Jitter Buffer)，這種緩沖區(qū)的大小動態(tài)可變，引入的延時可變化，在抖動小的時候延遲低，抖動大時延時大，這種可變大小的緩沖區(qū)雖然復(fù)雜度高，但是適應(yīng)能力強(qiáng)，能夠動態(tài)適應(yīng)網(wǎng)絡(luò)條件的變化。

如圖4所示的中轉(zhuǎn)通道網(wǎng)絡(luò)結(jié)構(gòu)中，包括如下模塊：

網(wǎng)絡(luò)模塊：負(fù)責(zé)處理網(wǎng)絡(luò)接入，房間邏輯，數(shù)據(jù)收發(fā)。另外ARQ模塊負(fù)責(zé)丟包重傳，F(xiàn)EC模塊負(fù)責(zé)FEC解包處理。經(jīng)過網(wǎng)絡(luò)模塊處理后的數(shù)據(jù)包主動送入Jitter模塊。

Jitter模塊：音頻抗抖動的核心模塊，根據(jù)網(wǎng)絡(luò)延時，緩沖延時，網(wǎng)絡(luò)是否丟包等數(shù)據(jù)，使用PLC、變速算法等，動態(tài)調(diào)整Jitter Buffer的大小，在保證延遲的情況下，確保最好的語音質(zhì)量。

Jitter Buffer：負(fù)責(zé)緩沖網(wǎng)絡(luò)數(shù)據(jù)包，去除亂序處理，提供接口判斷是否丟包。

算法模塊：包括解碼器、PLC(丟包隱藏)、正常、加速、減速處理模塊，解碼器模塊負(fù)責(zé)語音數(shù)據(jù)包的解碼，PLC模塊在丟包時對丟包數(shù)據(jù)進(jìn)行恢復(fù)，變速模塊負(fù)責(zé)對解碼后的語音數(shù)據(jù)進(jìn)行變速處理。變速模塊主要使用平均幅度差函數(shù)(AMDF)算法從短時語音信號中檢測基音周期，如果需要加速則將30ms數(shù)據(jù)中Skip一個基音周期到達(dá)加速效果；如果需要減速，30ms數(shù)據(jù)中Insert一個復(fù)制的基音周期，達(dá)到拉升效果。

Play Buffer：緩存經(jīng)過解碼、PLC、變速處理之后的PCM數(shù)據(jù)，等待播放模塊來取數(shù)據(jù)播放。

網(wǎng)絡(luò)統(tǒng)計：負(fù)責(zé)統(tǒng)計網(wǎng)絡(luò)抖動產(chǎn)生的網(wǎng)絡(luò)延時，參考播放時間戳，統(tǒng)計數(shù)據(jù)包到達(dá)間隔，提前達(dá)到(0)、正常到達(dá)(1)、延時到達(dá)(2、3、4……)，把統(tǒng)計出0、1、2、3、4……到達(dá)間隔的概率分布函數(shù)，計算涵蓋一定百分比概率的最大到達(dá)間隔為網(wǎng)絡(luò)的抖動延時，例如93％。

Buffer統(tǒng)計：負(fù)責(zé)統(tǒng)計Jitter模塊中緩存數(shù)據(jù)延時，使用簡單低通濾波器進(jìn)行統(tǒng)計。

策略決策：它是抗抖動算法的核心模塊，根據(jù)Buffer統(tǒng)計得出的緩存延時、網(wǎng)絡(luò)統(tǒng)計的網(wǎng)絡(luò)抖動延時、當(dāng)前數(shù)據(jù)包接收狀況以及歷史的PLC、加速、減速處理狀態(tài)，決策當(dāng)前是否從Jitter Buffer中提取數(shù)據(jù)進(jìn)行解碼，決策解碼后的數(shù)據(jù)是否需要正常、PLC、加速、加速，從而讓緩存延時趨近于網(wǎng)絡(luò)延時，這就是可變Jitter Buffer的核心原理。

播放模塊：定時20ms從Jitter模塊的播放緩沖區(qū)取數(shù)據(jù)播放，由于播放線程都在系統(tǒng)的播放回調(diào)函數(shù)中實現(xiàn)，由于系統(tǒng)不同，20ms取包的間隔精度也不同。

語音抗抖動算法，在800ms網(wǎng)絡(luò)抖動情況下的延時變化、變速曲線如下，延時變大情況下，進(jìn)行加速處理，延時突然變小情況下進(jìn)行減速，策略決策很快，很好的適應(yīng)了網(wǎng)絡(luò)抖動的變化。

在切換進(jìn)行過程中，中轉(zhuǎn)通道的網(wǎng)絡(luò)條件是重要的參數(shù)，這些網(wǎng)絡(luò)參數(shù)通過，Jitter模塊、Jitter Buffer模塊、網(wǎng)絡(luò)統(tǒng)計模塊、Buffer統(tǒng)計模塊、策略決策模塊、播放模塊來綜合獲得，參數(shù)至少包括：通道用戶數(shù)、接收碼率、發(fā)送碼率、發(fā)送丟包率、接收丟包率和上行時延和總時延。上述網(wǎng)絡(luò)參數(shù)的獲得是實時的，受到用戶總數(shù)量，測速時間段等因素影響。例如，在具體的測試過程中，通話用戶總數(shù)為30萬時與通話用戶總數(shù)為60萬的服務(wù)器拒包率不同，而導(dǎo)致較好的測試結(jié)果。當(dāng)用戶通話跨ISP或者由于網(wǎng)絡(luò)擁塞導(dǎo)致網(wǎng)絡(luò)劣化時，會由接收碼率、發(fā)送碼率、發(fā)送丟包率、接收丟包率和上行時延和總時延都會體現(xiàn)。

當(dāng)中轉(zhuǎn)通道網(wǎng)絡(luò)質(zhì)量劣化時，則服務(wù)器根據(jù)終端上報的直連通道情況發(fā)出測速指令。通道測速命令至少包括測速包大小、發(fā)包間隔、發(fā)包數(shù)量和指定測速地址等測速參數(shù)信息?？蛻舳藙t向指定測速地址發(fā)送帶時戳的測速包，根據(jù)發(fā)包和收包的時間計算出丟包率、上行網(wǎng)絡(luò)抖動、下行網(wǎng)絡(luò)抖動、上行時延和總延時。

此時，根據(jù)中轉(zhuǎn)通道的網(wǎng)絡(luò)狀況和直連通道的測速結(jié)果進(jìn)行綜合判斷，當(dāng)直連通道的測速結(jié)果滿足進(jìn)行音視頻通話質(zhì)量的基本條件，既切換條件時，且測速結(jié)果表明直連通道的網(wǎng)絡(luò)條件接近或者優(yōu)于所述中轉(zhuǎn)通道時，進(jìn)行通道切換。這樣可以節(jié)省中轉(zhuǎn)通道的帶寬并且同時獲得較優(yōu)的通話質(zhì)量，達(dá)到網(wǎng)絡(luò)資源的合理分配，同時在一定程度上解決網(wǎng)絡(luò)擁堵問題。綜合判斷的條件，包括綜合比較切換直連通道與中轉(zhuǎn)通道的用戶數(shù)量，兩通道的丟包率，不同標(biāo)準(zhǔn)差條件下兩通道的網(wǎng)絡(luò)抖動情況，上行時延和總時延。

在具體的判斷過程中，當(dāng)直連通道的丟包率、網(wǎng)絡(luò)抖動和網(wǎng)絡(luò)延時滿足閾值條件時，則可以認(rèn)為滿足了通道切換的基本條件。該閾值條件與網(wǎng)絡(luò)通話質(zhì)量有一定的關(guān)系，例如為了保證一般質(zhì)量的實時音視頻通話，直連通道的測速結(jié)果需滿足：丟包率<5％，上行抖動<200ms，下行抖動<200ms，上行時延<100ms，總時延<200ms，如果直連通道中的某網(wǎng)絡(luò)參數(shù)不滿足上述條件，則不進(jìn)行切換。如果對于通話質(zhì)量要求較高，則丟包率、上行抖動、下行抖動和延時等參數(shù)還要設(shè)定得相對更低。

在具體的比較過程中，各條件之間也存在比較的先后順序，在丟包率相同或者接近的情況下，由于網(wǎng)絡(luò)抖動是影響音視頻通話質(zhì)量的重要因素，因此可以網(wǎng)絡(luò)抖動作為綜合比較的優(yōu)先因素，當(dāng)直連通道與中轉(zhuǎn)通道的網(wǎng)絡(luò)抖動在同一置信區(qū)間接近時，則繼續(xù)比較網(wǎng)絡(luò)時延遲。當(dāng)然，這三項網(wǎng)絡(luò)參數(shù)各有細(xì)分，網(wǎng)絡(luò)抖動包括上行抖動和下行抖動，網(wǎng)絡(luò)延時則包括上行時延和總時延。在某些條件下，還引入中轉(zhuǎn)通道在線用戶數(shù)量作為參考。

在一個具體的切換過程中，需要綜合所述中轉(zhuǎn)通道的網(wǎng)絡(luò)狀況和所述直連通道的測速情況，通過Jitter模塊、Jitter Buffer模塊、網(wǎng)絡(luò)統(tǒng)計模塊、Buffer統(tǒng)計模塊、策略決策模塊獲得中轉(zhuǎn)通道丟包率為3.05％，通話200ms上行抖動，下行抖動0.55標(biāo)準(zhǔn)差區(qū)間用戶數(shù)量為88％，上行網(wǎng)絡(luò)延遲為90ms，總網(wǎng)絡(luò)延遲為190ms。通過直連通道測速獲得的直連通道丟包率為3.0％，通話200ms上行抖動，下行抖動0.55標(biāo)準(zhǔn)差區(qū)間用戶數(shù)量為100％，上行網(wǎng)絡(luò)延遲為90ms，總網(wǎng)絡(luò)延遲為180ms。可見，直連通道的網(wǎng)絡(luò)狀況略優(yōu)于中轉(zhuǎn)通道，因此，服務(wù)器確定進(jìn)行通道切換。

在一個具體的切換過程中，需要綜合所述中轉(zhuǎn)通道的網(wǎng)絡(luò)狀況和所述直連通道的測速情況，通過Jitter模塊、Jitter Buffer模塊、網(wǎng)絡(luò)統(tǒng)計模塊、Buffer統(tǒng)計模塊、策略決策模塊獲得中轉(zhuǎn)通道丟包率為3.05％，通話200ms上行抖動，下行抖動0.55標(biāo)準(zhǔn)差區(qū)間用戶數(shù)量為88％，上行網(wǎng)絡(luò)延遲為90ms，總網(wǎng)絡(luò)延遲為190ms。通過直連通道測速獲得的直連通道丟包率為5.5％，通話200ms上行抖動，下行抖動0.55標(biāo)準(zhǔn)差區(qū)間用戶數(shù)量為100％，上行網(wǎng)絡(luò)延遲為90ms，總網(wǎng)絡(luò)延遲為180ms。雖然，直連通道的其他網(wǎng)絡(luò)參數(shù)優(yōu)于中轉(zhuǎn)通道，但是由于直連通道有較大的丟包率，為了保證通話質(zhì)量，服務(wù)器不對通話通道進(jìn)行切換。

在一個具體的切換過程中，需要綜合所述中轉(zhuǎn)通道的網(wǎng)絡(luò)狀況和所述直連通道的測速情況，通過Jitter模塊、Jitter Buffer模塊、網(wǎng)絡(luò)統(tǒng)計模塊、Buffer統(tǒng)計模塊、策略決策模塊獲得中轉(zhuǎn)通道丟包率為2.05％，通話200ms上行抖動，下行抖動0.55標(biāo)準(zhǔn)差區(qū)間用戶數(shù)量為100％，上行網(wǎng)絡(luò)延遲為50ms，總網(wǎng)絡(luò)延遲為100ms。通過直連通道測速獲得的直連通道丟包率為2.15％，通話200ms上行抖動，下行抖動0.55標(biāo)準(zhǔn)差區(qū)間用戶數(shù)量為75％，上行網(wǎng)絡(luò)延遲為40ms，總網(wǎng)絡(luò)延遲為80ms。直連通道與中轉(zhuǎn)通道的丟包率接近，且直連通道的網(wǎng)絡(luò)延時較小，但是由于中轉(zhuǎn)通道的網(wǎng)絡(luò)抖動較小，具有更好的通話質(zhì)量，服務(wù)器選擇不對通話通道進(jìn)行切換。當(dāng)然，如果延時過大，例如大于200ms的延時，則會嚴(yán)重影響到通話質(zhì)量，此時即使網(wǎng)絡(luò)抖動小，也要對通道進(jìn)行切換。

在一個具體的切換過程中，需要綜合所述中轉(zhuǎn)通道的網(wǎng)絡(luò)狀況和所述直連通道的測速情況，通過Jitter模塊、Jitter Buffer模塊、網(wǎng)絡(luò)統(tǒng)計模塊、Buffer統(tǒng)計模塊、策略決策模塊獲得中轉(zhuǎn)通道丟包率為3.01％，通話200ms上行抖動，下行抖動0.55標(biāo)準(zhǔn)差區(qū)間用戶數(shù)量為88％，上行網(wǎng)絡(luò)延遲為90ms，總網(wǎng)絡(luò)延遲為180ms。通過直連通道測速獲得的直連通道丟包率為3.0％，通話200ms上行抖動，下行抖動0.55標(biāo)準(zhǔn)差區(qū)間用戶數(shù)量為90％，上行網(wǎng)絡(luò)延遲為90ms，總網(wǎng)絡(luò)延遲為180ms?？梢姡边B通道與中轉(zhuǎn)通道的網(wǎng)絡(luò)狀況基本相同，此時，服務(wù)器引中轉(zhuǎn)通道用戶數(shù)作為參考，當(dāng)中轉(zhuǎn)通道用戶數(shù)量較大時，服務(wù)器確定進(jìn)行切換，以減輕中轉(zhuǎn)通道的網(wǎng)絡(luò)負(fù)擔(dān)。

如圖5所示，在對120余萬用戶的線上測試過程中，對跨ISP業(yè)務(wù)的中轉(zhuǎn)通道和直連通道進(jìn)行測速，A為滿足切換條件并切直連通道的用戶，B為滿足切換條件未切直連通道的用戶。兩組用戶數(shù)量分別為674656和67796獲得的，測速結(jié)果表明，切直連的用戶質(zhì)量并沒有因為切換通道影響通話質(zhì)量，并且由中轉(zhuǎn)通道切到直連通道從而節(jié)省了中轉(zhuǎn)通道的帶寬。

實施例五：

本實施例提供一種實時通話過程中基于測速的通道切換方法，包括如下步驟：

步驟UD101，第一終端與服務(wù)器建立第一通道，所述服務(wù)器用于中轉(zhuǎn)第一通道內(nèi)傳輸?shù)臄?shù)據(jù)。

步驟SV101，服務(wù)器響應(yīng)第一終端的請求，與所述第一終端之間建立第一通道，并轉(zhuǎn)發(fā)客戶端之間的數(shù)據(jù)。

步驟UD102，第一終端與所述第二終端建立第二通道，基于所述第二通道與所述第二終端直接交互數(shù)據(jù)。

步驟UD103，第一終端將所述第二通道上報所述服務(wù)器，并接收所述服務(wù)器的測速指令。

步驟SV102，接收所述客戶端上報的第二通道信息，并發(fā)通道測速命令。

步驟UD104，第一終端基于所述測速指令，進(jìn)行第二通道測速。

步驟SV103，接收用戶反饋的第二通道測速結(jié)果。

步驟UD105，第一終端上傳所述測速結(jié)果。

步驟SV104，服務(wù)器根據(jù)所述測速結(jié)果，決策是否切換通道。

步驟UD101描述實時通話中的基礎(chǔ)實現(xiàn)形態(tài)，用戶終端與服務(wù)器建立連接，并通過服務(wù)器與第二終端進(jìn)行數(shù)據(jù)交互，用戶終端與第二終端之間的數(shù)據(jù)通過服務(wù)器中轉(zhuǎn)到達(dá)對方。二者之間的數(shù)據(jù)傳輸方式通過服務(wù)器來中轉(zhuǎn)，二者之間的通道為中轉(zhuǎn)通道。然而，由于互聯(lián)網(wǎng)運營商出口帶寬以及在不同時段出現(xiàn)的網(wǎng)絡(luò)擁堵等問題，中轉(zhuǎn)通道不僅無法實現(xiàn)高質(zhì)量通話的要求，甚至?xí)霈F(xiàn)丟包嚴(yán)重，甚至無法通話無法連通的問題。

步驟UD102中，用戶終端直接與第二終端建立第二通道，基于所述第二通道與所述第二終端直接交互數(shù)據(jù)。

在具體的實施過程中，可以使用包括但不限于NAT traversal技術(shù)(NAT穿越技術(shù))，在不同的私有網(wǎng)絡(luò)之間建立終端之間的聯(lián)系，以及基于Peer to Peer技術(shù)保持用戶終端之間的直接聯(lián)系。

在步驟UD101和步驟UD102中，用戶之間建立了直連通道和中轉(zhuǎn)通道，在通常情況下，中轉(zhuǎn)通道的網(wǎng)絡(luò)平均網(wǎng)絡(luò)質(zhì)量高于直連通道。在此情況下，通話從接通到掛斷的過程中可以僅使用中轉(zhuǎn)通道。但是當(dāng)網(wǎng)絡(luò)帶寬占用多，接口機(jī)服務(wù)器網(wǎng)絡(luò)負(fù)載高時，網(wǎng)絡(luò)質(zhì)量劣化。發(fā)明人發(fā)現(xiàn)，當(dāng)網(wǎng)絡(luò)質(zhì)量劣化時，中轉(zhuǎn)通道質(zhì)量未必優(yōu)于直連通道。此時，使用直連通道進(jìn)行通話會獲得更好通話預(yù)期效果。然而，在何時選擇將中轉(zhuǎn)通道切換為直連通道是一個需要解決的問題，這也就需要了解中轉(zhuǎn)通道和直連通道的通話質(zhì)量。

步驟UD103中，客戶端將第二通道上報服務(wù)器，并接收服務(wù)器的測速指令。

建立了直連通道的用戶會將自身的通道情況上報給服務(wù)器。服務(wù)器得知用戶的通道信息，根據(jù)用戶自身的情況，下發(fā)通道測速命令，該命令包含了測速包的大小、發(fā)包間隔、發(fā)包數(shù)量、待測速地址等參數(shù)信息。

步驟UD104，用戶終端收到指揮通道測速的命令后，根據(jù)參數(shù)，向指定測速地址發(fā)送帶時間戳的測速包，根據(jù)發(fā)包和收包的時間計算出網(wǎng)絡(luò)抖動、丟包率和網(wǎng)絡(luò)時延等網(wǎng)絡(luò)質(zhì)量情況。

在本實施例中，實時通話是指雙方或者多方之間進(jìn)行的音頻、音視頻通話，圖6簡明地示出了服務(wù)器與客戶端之間的數(shù)據(jù)包交互關(guān)系。

第一客戶端接收服務(wù)器發(fā)送的通道預(yù)測命令，并返回確認(rèn)。

第一客戶端響應(yīng)服務(wù)器的通道預(yù)測命令，向第二客戶端發(fā)送探測包，并接收探測回包。

第一客戶端將測速結(jié)果包發(fā)送給服務(wù)器，并接收服務(wù)器發(fā)送的測速結(jié)果回包。

就服務(wù)器側(cè)而言，由于服務(wù)器下發(fā)通道測速命令、通道測速過程、指揮切換通道是異步的。服務(wù)器將建立連接每組客戶端視為一個房間，并維護(hù)了一個狀態(tài)來標(biāo)識每個房間的通道測速情況。如圖7所示，服務(wù)器包括如下狀態(tài)：

初始化狀態(tài)(INIT)：每個房間在初始化時都是INIT狀態(tài)，當(dāng)滿足音視頻通話跨網(wǎng)絡(luò)服務(wù)供應(yīng)商(ISP)時，進(jìn)入READY狀態(tài)，處于待測速狀態(tài)。

預(yù)備狀態(tài)(READY):表示該房間滿足通道測速邏輯條件，當(dāng)用戶上報了直連通道給服務(wù)器時，即可觸發(fā)服務(wù)器下發(fā)通道測速命令，狀態(tài)轉(zhuǎn)換為SEND_CMD并記錄下發(fā)時間戳。

發(fā)送等待狀態(tài)(SEND_CMD)：在該狀態(tài)下的房間，服務(wù)器已經(jīng)下發(fā)了通道測速命令，等待用戶上報通道測速結(jié)果，同時檢測狀態(tài)是否超時。

接收等待狀態(tài)(RECV_CMD)：在該狀態(tài)下的房間，服務(wù)器已經(jīng)收到了用戶支持通道測速的命令，等待用戶上報通道測速結(jié)果，更新狀態(tài)時間戳，同時檢測狀態(tài)是否超時。

收到測速結(jié)果狀態(tài)(GET_INFO)：服務(wù)器收到用戶的通道測速結(jié)果。

在上述狀態(tài)中，如果檢測到超時或者異常，則進(jìn)入中斷，停止通道測速過程。

在上述過程中，如果在SEND_CMD狀態(tài)下提前收到通道測速結(jié)果，則跳過RECV_CMD狀態(tài)，直接進(jìn)入GET_INFO狀態(tài)。

以上所述僅是本發(fā)明的優(yōu)選實施方式，應(yīng)當(dāng)指出，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進(jìn)和潤飾，這些改進(jìn)和潤飾也應(yīng)視為本發(fā)明的保護(hù)范圍。