一種語音通話處理方法、系統(tǒng)和云端服務(wù)器的制造方法
【專利摘要】本發(fā)明公開了一種語音通話處理方法，語音通話的流控引擎部署在云端服務(wù)器，所述方法包括：所述流控引擎接收參與語音通話的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息；所述流控引擎根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器下發(fā)所述流控策略給所述客戶端執(zhí)行。本發(fā)明還公開了一種語音通話處理系統(tǒng)和云端服務(wù)器。
【專利說明】
一種語音通話處理方法、系統(tǒng)和云端服務(wù)器
技術(shù)領(lǐng)域
[0001] 本發(fā)明涉及基于互聯(lián)網(wǎng)的語音通話技術(shù)領(lǐng)域，尤其涉及一種語音通話處理方法、 系統(tǒng)和云端服務(wù)器。
【背景技術(shù)】
[0002] 對于語音通話業(yè)務(wù)而言，語音數(shù)據(jù)中轉(zhuǎn)系統(tǒng)不僅需要將音頻數(shù)據(jù)從發(fā)送端轉(zhuǎn)發(fā)到 接收端，還要盡量保證語音通話的高質(zhì)量。如果將兩人語音通話中雙方的上下行數(shù)據(jù)流視 作一個全雙工通訊信道，那么這個通道中任意一方的網(wǎng)絡(luò)質(zhì)量發(fā)生波動，都會引發(fā)控制策 略的動態(tài)調(diào)整，從而對通話質(zhì)量產(chǎn)生正面/負面的影響。這些控制策略的集合稱為流控引 擎。
[0003] 從抽象層面上來看，有Μ路語音發(fā)送方和N路語音收聽方的多人語音通話可以視 作ΜΧΝ個兩人全雙工通訊信道相互關(guān)聯(lián)而形成的通訊網(wǎng)絡(luò)。由于這個通訊網(wǎng)絡(luò)中的任何 一環(huán)出現(xiàn)質(zhì)量問題都會對整個多人會話的語音質(zhì)量造成影響，因此多人語音通話服務(wù)的流 控引擎不但要能有效對抗通訊信道網(wǎng)絡(luò)的質(zhì)量波動，還要兼顧整體通話質(zhì)量，從而比兩人 通話的控制策略更為復(fù)雜，實現(xiàn)起來的難度和成本也更大。
[0004] 雖然流控引擎對于多人語音通話數(shù)據(jù)中轉(zhuǎn)系統(tǒng)的重要性不言而喻，但除了需要控 制好復(fù)雜交織的通訊信道網(wǎng)絡(luò)之外，還需要解決多人通話特有的一些問題，比如：通話參與 人數(shù)越多，上下行的語音路數(shù)也就越多，而多人通話的擴散效應(yīng)導(dǎo)致的前后臺帶寬和處理 器計算壓力就越明顯，這也會間接地影響語音通話質(zhì)量。以上也為本發(fā)明要解決的技術(shù)問 題。

【發(fā)明內(nèi)容】

[0005] 為解決現(xiàn)有存在的技術(shù)問題，本發(fā)明實施例提供一種語音通話處理方法、系統(tǒng)和 云端服務(wù)器。
[0006] 本發(fā)明實施例提供了一種語音通話處理方法，語音通話的流控引擎部署在云端服 務(wù)器，所述方法包括：
[0007] 所述流控引擎接收參與語音通話的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀態(tài)信 息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息；
[0008] 所述流控引擎根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器 上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器下發(fā)所述流控 策略給所述客戶端執(zhí)行。
[0009] 上述方案中，語音通話的混音引擎也部署在云端服務(wù)器，所述方法還包括：
[0010] 所述混音引擎對接收的多路上行語音數(shù)據(jù)進行混音，并將混音所獲得的語音數(shù)據(jù) 發(fā)送到語音通話的所有收聽方客戶端。
[0011] 上述方案中，所述方法還包括：所述混音引擎和流控引擎之間通過共享內(nèi)存完成 數(shù)據(jù)交互。
[0012] 上述方案中，所述流控策略包括對應(yīng)所述客戶端的上行通道流控策略和下行通道 流控策略，所述客戶端的上行通道是所述客戶端作為語音發(fā)送方時到中轉(zhuǎn)服務(wù)器之間的通 訊通道，所述客戶端的下行通道是所述客戶端作為語音接收方時到中轉(zhuǎn)服務(wù)器之間的通訊 通道；
[0013] 其中，所述客戶端的上行通道流控策略和下行通道流控策略分離。
[0014] 上述方案中，所述流控引擎中存儲流控策略集合，所述流控策略集合中包括至少 一項流控策略；
[0015] 相應(yīng)的，所述云端服務(wù)器根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述 中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，包括：
[0016] 所述云端服務(wù)器根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù) 器上報的狀態(tài)信息，查找所述流控引擎中的流控策略集合，獲得與所述云端服務(wù)器接收的 信息相匹配的流控策略。
[0017] 本發(fā)明實施例還提供了一種云端服務(wù)器，所述云端服務(wù)器中部署有語音通話的流 控引擎，所述流控引擎用于，接收參與語音通話的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀 態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息；根據(jù)接收的所述客戶端的能力和狀態(tài)信 息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，并通過所述 中轉(zhuǎn)服務(wù)器下發(fā)所述流控策略給所述客戶端執(zhí)行。
[0018] 上述方案中，所述云端服務(wù)器中還部署有語音通話的混音引擎，所述混音引擎用 于，對接收的多路上行語音數(shù)據(jù)進行混音，并將混音所獲得的語音數(shù)據(jù)發(fā)送到語音通話的 所有收聽方客戶端。
[0019] 上述方案中，所述云端服務(wù)器還包括共享內(nèi)存，所述混音引擎和流控引擎之間通 過共享內(nèi)存完成數(shù)據(jù)交互。
[0020] 上述方案中，所述流控策略包括對應(yīng)所述客戶端的上行通道流控策略和下行通道 流控策略，所述客戶端的上行通道是所述客戶端作為語音發(fā)送方時到中轉(zhuǎn)服務(wù)器之間的通 訊通道，所述客戶端的下行通道是所述客戶端作為語音接收方時到中轉(zhuǎn)服務(wù)器之間的通訊 通道；
[0021] 其中，所述客戶端的上行通道流控策略和下行通道流控策略分離。
[0022] 上述方案中，所述流控引擎中存儲流控策略集合，所述流控策略集合中包括至少 一項流控策略；
[0023] 所述流控引擎進一步用于，根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所 述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，查找所述流控引擎中的流控策略集合，獲得與接收的信息 相匹配的流控策略。
[0024] 本發(fā)明實施例還提供了一種語音通話處理系統(tǒng)，所述系統(tǒng)包括：云端服務(wù)器和中 轉(zhuǎn)服務(wù)器，其中，
[0025] 所述云端服務(wù)器中部署有語音通話的流控引擎，所述流控引擎接收參與語音通話 的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信 息；根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，計 算對應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器下發(fā)所述流控策略給所述客戶端執(zhí) 行；
[0026] 所述中轉(zhuǎn)服務(wù)器用于，為客戶端提供接入和數(shù)據(jù)中轉(zhuǎn)、擴散通道，接收客戶端的能 力和狀態(tài)信息上報到所述流控引擎，接收所述流控引擎的流控策略并下發(fā)到相應(yīng)的客戶 端。
[0027] 上述方案中，所述云端服務(wù)器中還部署有語音通話的混音引擎，所述混音引擎用 于，對接收的多路上行語音數(shù)據(jù)進行混音，并將混音所獲得的語音數(shù)據(jù)發(fā)送到語音通話的 所有收聽方客戶端。
[0028] 上述方案中，所述云端服務(wù)器還包括共享內(nèi)存，所述混音引擎和流控引擎之間通 過共享內(nèi)存完成數(shù)據(jù)交互。
[0029] 上述方案中，所述流控策略包括對應(yīng)所述客戶端的上行通道流控策略和下行通道 流控策略，所述客戶端的上行通道是所述客戶端作為語音發(fā)送方時到中轉(zhuǎn)服務(wù)器之間的通 訊通道，所述客戶端的下行通道是所述客戶端作為語音接收方時到中轉(zhuǎn)服務(wù)器之間的通訊 通道；
[0030] 其中，所述客戶端的上行通道流控策略和下行通道流控策略分離。
[0031] 上述方案中，所述流控引擎中存儲流控策略集合，所述流控策略集合中包括至少 一項流控策略；
[0032] 所述流控引擎進一步用于，根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所 述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，查找所述流控引擎中的流控策略集合，獲得與接收的信息 相匹配的流控策略。
[0033] 本發(fā)明實施例提供的一種語音通話處理方法、系統(tǒng)和云端服務(wù)器，在云端部署流 控引擎和混音引擎，使多人語音通話在單個會話規(guī)模上擁有了極強的擴展性，可以輕而易 舉地支持單會話數(shù)千人同時在線的體驗。相對于Skype單會話最多25人、且對發(fā)起方軟硬 件和網(wǎng)絡(luò)環(huán)境要求及其嚴苛的限制而言是一個巨大的進步。與此同時，"上下行通道流控策 略分離"與"流控、混音雙引擎"架構(gòu)也在最大程度上降低了上下行通道之間的相互干擾，保 證了多人語音通話的最優(yōu)服務(wù)體驗。本發(fā)明實施例通過強化和提升多人音視頻通話系統(tǒng)的 云端服務(wù)能力，實現(xiàn)在用戶網(wǎng)絡(luò)質(zhì)量不穩(wěn)定、上下行帶寬受限等不利因素的干擾下，仍然能 夠持續(xù)、穩(wěn)定地提供清晰流暢的高質(zhì)量多人語音通話服務(wù)。
【附圖說明】
[0034] 圖1為本發(fā)明實施例一的語音通話處理系統(tǒng)的結(jié)構(gòu)示意圖；
[0035] 圖2為本發(fā)明實施例一的音頻編碼分組與帶外FEC的示意圖一；
[0036] 圖3為本發(fā)明實施例一的音頻編碼分組與帶外FEC的示意圖二；
[0037] 圖4為本發(fā)明實施例一的上下行通道流控策略分離的示意圖；
[0038] 圖5為本發(fā)明實施例三的語音通話處理方法的流程示意圖。
【具體實施方式】
[0039] 下面結(jié)合附圖和具體實施例對本發(fā)明的技術(shù)方案進一步詳細闡述。
[0040] 實施例一
[0041] 為強化和提升多人音視頻通話系統(tǒng)的云端服務(wù)能力，本發(fā)明實施例一提供一種語 音通話處理系統(tǒng)，如圖1所示，該系統(tǒng)主要包括：云端服務(wù)器和中轉(zhuǎn)服務(wù)器；其中，
[0042] 云端服務(wù)器中部署有語音通話的流控引擎，所述流控引擎用于接收參與語音通話 的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信 息；根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，計 算對應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器下發(fā)所述流控策略給所述客戶端執(zhí) 行；
[0043] 所述中轉(zhuǎn)服務(wù)器用于，為客戶端提供接入和數(shù)據(jù)中轉(zhuǎn)、擴散通道，接收客戶端的能 力和狀態(tài)信息上報到所述流控引擎，接收所述流控引擎的流控策略并下發(fā)到相應(yīng)的客戶 端。
[0044] 在一實施方式中，云端服務(wù)器中還可部署語音通話的混音引擎，所述混音引擎用 于，對接收的多路上行語音數(shù)據(jù)進行混音，并將混音所獲得的語音數(shù)據(jù)發(fā)送到語音通話的 所有收聽方客戶端。
[0045] 其中，所述云端服務(wù)器還可包括共享內(nèi)存，所述混音引擎和流控引擎之間通過共 享內(nèi)存完成數(shù)據(jù)交互。
[0046] 下面再結(jié)合圖1詳細介紹語音通話處理系統(tǒng)的各部分功能。
[0047] 圖1中的虛線箭頭線代表信令通道，實線箭頭線代表音頻數(shù)據(jù)通道?？蛻舳伺c云 端服務(wù)器、客戶端與客戶端之間的數(shù)據(jù)交互都需要通過中轉(zhuǎn)服務(wù)器進行轉(zhuǎn)發(fā)。出于效率方 面的考慮，流控引擎與混音引擎可以同機部署也可以不同機部署，雙引擎之間數(shù)據(jù)交互通 過共享內(nèi)存來實現(xiàn)；所述共享內(nèi)存中可用于存儲用戶信息、客戶端上報信息、語音通話的房 間信息等等，以上信息都可以為所述混音引擎和流控引擎所用。
[0048] 圖1所示系統(tǒng)中的中轉(zhuǎn)服務(wù)器負責(zé)為客戶端提供接入和數(shù)據(jù)中轉(zhuǎn)、擴散通道，該 通道不僅能夠傳輸音頻數(shù)據(jù)，還肩負著客戶端能力（是否有攝像頭/麥克風(fēng)、CPU/I0性能 評分等）與狀態(tài)（網(wǎng)絡(luò)類型切換、丟包率、時延、CPU占用等）信息上報和流控策略下發(fā)等 重要責(zé)任。需要說明的是，在本發(fā)明實施例中，語音數(shù)據(jù)中轉(zhuǎn)和擴散都是通過由中轉(zhuǎn)服務(wù)器 完成的，客戶端之間并不會有直接的數(shù)據(jù)交互。
[0049] 圖1所示系統(tǒng)中的流控引擎是部署在云端的，主要負責(zé)根據(jù)客戶端的能力信息和 當(dāng)前的網(wǎng)絡(luò)狀況，周期性地為其計算并下發(fā)有針對性的流控策略，以幫助客戶端對抗網(wǎng)絡(luò) 抖動、提高通話質(zhì)量等。在多人語音通話中，一路上行語音數(shù)據(jù)會被中轉(zhuǎn)服務(wù)器擴散給相同 會話內(nèi)的所有用戶，所以上行語音用戶的網(wǎng)絡(luò)質(zhì)量和冗余策略將會影響所有收聽的用戶的 通話效果。進一步地，當(dāng)會話中存在多路上行語音時，收聽方的通話效果取決于所有上行語 音質(zhì)量和收聽方客戶端到中轉(zhuǎn)服務(wù)器之間網(wǎng)絡(luò)狀況的疊加，這就要求流控引擎的控制策略 不但要實時、精細化，而且要有會話級別的大局觀。這也是多人語音通話與兩人通話流控引 擎最大的差別所在。
[0050] 圖1所示系統(tǒng)中的混音引擎是部署在云端的，即由云端來執(zhí)行多路上行語音數(shù)據(jù) 的混音處理，這也是區(qū)別于現(xiàn)有技術(shù)的。在多人語音通話中，由于每一路上行語音都會擴散 給相同會話內(nèi)的所有用戶，因此，上行語音路數(shù)越多，收聽方客戶端的帶寬壓力和混音的系 統(tǒng)開銷也就越大。此外，如果采用收聽方客戶端混音的做法也不利于流控引擎針對低帶寬 用戶的調(diào)控。例如，當(dāng)個別收聽方下行帶寬不夠時，降低所有上行方的音頻碼率會導(dǎo)致會話 內(nèi)所有其他收聽方通話質(zhì)量下降；而如果針對該低帶寬收聽方停止中轉(zhuǎn)某些數(shù)據(jù)將會使其 通話信息接收不完整。所以，如果沒有云端的混音引擎，流控引擎此時將陷入兩難的境地， 最終只能放棄對這些低帶寬用戶的調(diào)控，任其下行通道撐爆。再有，現(xiàn)有技術(shù)如Skype將 混音的責(zé)任放到會話發(fā)起方客戶端，即多人語音通話的發(fā)起方客戶端負責(zé)接收所有被叫方 的上行語音數(shù)據(jù)，將多路數(shù)據(jù)混音和重新編碼之后再轉(zhuǎn)發(fā)給所有被叫方客戶端播放；而在 流控策略方面，如果發(fā)起方網(wǎng)絡(luò)上下行質(zhì)量變差，則所有被叫方收到的語音碼率都會隨之 下調(diào)，以減少發(fā)起方的網(wǎng)絡(luò)帶寬壓力。發(fā)起方客戶端負責(zé)混音的方案，對發(fā)起方的網(wǎng)絡(luò)質(zhì)量 和計算能力要求頗高，這會成為制約整個多人通話質(zhì)量的瓶頸，同時嚴重影響會話規(guī)模的 擴展。因此，綜合考慮了上述發(fā)起方客戶端負責(zé)混音的方案、以及收聽方客戶端負責(zé)混音的 方案，本發(fā)明實施例選擇采用云端負責(zé)混音的方案，即將混音引擎部署在云端服務(wù)器中；本 發(fā)明實施例選擇在云端部署混音引擎不僅可以規(guī)避上述發(fā)起方客戶端負責(zé)混音、以及收聽 方客戶端負責(zé)混音方案中的缺陷，而且，當(dāng)有參與者通過公共交換電話網(wǎng)絡(luò)（PSTN，Public Switched Telephone Network)或WEB的形式接入多人語音通話時，也需要混音引擎為其混 音和轉(zhuǎn)碼，以保證PSTN/WEB接入用戶的正常使用，混音引擎部署在云端更能從容應(yīng)對PSTN 或WEB參與者的接入。
[0051] 關(guān)于能力信息上報，需要說明的是，在用戶創(chuàng)建或進入多人通話之前，需要對用戶 所在客戶端本地的能力信息（如是否有攝像頭/麥克風(fēng)、CPU能力評分等）進行收集，并通 過中轉(zhuǎn)服務(wù)器上報給流控引擎，以備流控引擎在計算針對該客戶端的流控策略時參考。例 如：如果客戶端是2G/3G網(wǎng)絡(luò)，則流控引擎會命令客戶端使用較低的采樣率以節(jié)省帶寬；如 果客戶端CPU評分過低，則流控引擎會控制客戶端使用復(fù)雜度較低的編碼方式以減少CPU 消耗；對于某些參與用戶非常多的超大規(guī)模多人語音通話，在計算單個用戶流控策略時，對 于無上行能力（既沒有攝像頭、也沒有麥克風(fēng)）的收聽用戶，可以適當(dāng)拉長計算間隔。在用 戶通話過程中，如果客戶端能力信息發(fā)生變化（比如熱拔插攝像頭/麥克風(fēng)等），客戶端也 需要及時向流控引擎上報其能力變更信息，以備流控引擎及時調(diào)整針對該客戶端的流控策 略。
[0052] 關(guān)于狀態(tài)信息上報，需要說明的是，作為多人通話的收聽方的客戶端需要根據(jù)收 到數(shù)據(jù)包的序列號和時間間隔來統(tǒng)計中轉(zhuǎn)服務(wù)器與收聽方客戶端之間的網(wǎng)絡(luò)丟包和延遲 的情況，并周期性地（出于調(diào)控及時性考慮，周期通常很短）將這些信息上報給流控引擎， 作為流控引擎進行策略計算和動態(tài)調(diào)整的依據(jù)。而由于本發(fā)明實施例中所有數(shù)據(jù)都需要通 過中轉(zhuǎn)服務(wù)進行傳輸，所以語音數(shù)據(jù)發(fā)送方客戶端到中轉(zhuǎn)服務(wù)之間網(wǎng)絡(luò)的丟包和延遲情況 就只能由中轉(zhuǎn)服務(wù)負責(zé)計算并上報給流控引擎了。因此，本發(fā)明實施例中，作為多人通話的 收聽方客戶端需要周期性地向流控引擎上報其與中轉(zhuǎn)服務(wù)器之間的網(wǎng)絡(luò)丟包和延遲等狀 態(tài)信息；而中轉(zhuǎn)服務(wù)器也需要周期性地向流控引擎上報其與發(fā)送方客戶端之間的網(wǎng)絡(luò)丟包 和延遲等狀態(tài)信息。
[0053] 在本發(fā)明實施例中，將語音發(fā)送方客戶端到中轉(zhuǎn)服務(wù)之間的通訊信道稱為上行通 道、將中轉(zhuǎn)服務(wù)與收聽方客戶端之間的通訊信道稱為下行通道。通道帶寬預(yù)測結(jié)果作為一 種狀態(tài)信息，是指根據(jù)歷史和當(dāng)前的通道帶寬觀測值、利用特定的算法來預(yù)測下一時刻的 可用帶寬大小。對于流控引擎而言，通道的可用帶寬是最重要的調(diào)控參考指標之一，所以準 確、及時的通道帶寬預(yù)測對于語音通話業(yè)務(wù)的服務(wù)質(zhì)量至關(guān)重要。帶寬預(yù)測有很多成熟且 高效的算法，引擎實現(xiàn)者可以根據(jù)實際情況選擇適合業(yè)務(wù)特點的算法。由于帶寬預(yù)測的結(jié) 果通常是由通道的接收方負責(zé)計算的，所以上行通道的帶寬預(yù)測是由中轉(zhuǎn)服務(wù)器計算并通 過內(nèi)網(wǎng)上報給流控引擎的，而下行通道的預(yù)測則是由客戶端計算并通過中轉(zhuǎn)服務(wù)器上報給 流控引擎的。在多人語音通話業(yè)務(wù)中，每個上行通道只有一路數(shù)據(jù)，所以帶寬預(yù)測的實現(xiàn)方 式和兩人通話區(qū)別不大；但對于下行通道而言，由于每個收聽用戶會接收多路語音數(shù)據(jù)，所 以語音上行用戶說話與否將會導(dǎo)致收聽用戶下行語音路數(shù)和流量的劇烈變化，從而嚴重影 響帶寬預(yù)測算法的準確性，進而影響流控策略的計算。因此本發(fā)明實施例引入了混音引擎， 在服務(wù)端進行音頻選路和混音，使每個收聽用戶的下行通道也只有一路數(shù)據(jù)，從而降低了 上行用戶的多寡對收聽用戶下行通道流量和帶寬預(yù)測算法的影響，提升了整體通話質(zhì)量。
[0054] 綜上所述，流控引擎會根據(jù)多人通話的收聽方客戶端上報的狀態(tài)信息，計算和動 態(tài)調(diào)整針對相應(yīng)收聽方客戶端的流控策略；會根據(jù)中轉(zhuǎn)服務(wù)器上報的其與發(fā)送方客戶端之 間狀態(tài)信息，計算和動態(tài)調(diào)整針對相應(yīng)發(fā)送方客戶端的流控策略。
[0055] 由此可見，本發(fā)明實施例中，流控策略包括對應(yīng)所述客戶端的上行通道流控策略 和下行通道流控策略，所述客戶端的上行通道是所述客戶端作為語音發(fā)送方時到中轉(zhuǎn)服務(wù) 器之間的通訊通道，所述客戶端的下行通道是所述客戶端作為語音接收方時到中轉(zhuǎn)服務(wù)器 之間的通訊通道；
[0056] 其中，所述客戶端的上行通道流控策略和下行通道流控策略采用分離的方式。
[0057] 下面以前向糾錯編碼（FEC，F(xiàn)orward Error Correction)策略的上下行通道隔離 來具體說明上行通道流控策略和下行通道流控策略隔離的實現(xiàn)。
[0058] FEC是通信領(lǐng)域常用的一種信道差錯控制方法，大多數(shù)實時語音通話服務(wù)都采用 了 FEC來對抗網(wǎng)絡(luò)抖動、提高服務(wù)質(zhì)量，本發(fā)明實施例中提到的FEC是指Outbound-FEC，即 所謂帶外FEC。在多人語音通話中，每個發(fā)言用戶的語音數(shù)據(jù)（包括FEC)都被擴散并轉(zhuǎn)發(fā) 至所有收聽用戶，而上行通道與各個下行通道之間的網(wǎng)絡(luò)狀況差異又很大，所以上行用戶 用以對抗網(wǎng)絡(luò)抖動所加的FEC數(shù)量難以兼顧到多個下行通道的實際狀況。如果只是簡單粗 暴地在上行通道加大FEC比例來覆蓋最差下行通道的網(wǎng)絡(luò)抖動，則上行語音的核心碼率將 被多余的FEC擠占，導(dǎo)致最差下行通道拖累了整體通話質(zhì)量；對于大多數(shù)網(wǎng)絡(luò)狀況很好、不 需要那么多FEC的下行通道而言，多余的FEC只會浪費客戶端流量、加大服務(wù)端帶寬成本壓 力。綜上所述，上行通道不應(yīng)、也無法很好地兼顧下行通道的抗抖動策略。因此，本發(fā)明實 施例將上行通道和下行通道的控制策略完全隔離，杜絕了上下行通道相互影響的弊端，從 而進一步節(jié)省前后臺帶寬成本、降低了流控引擎控制策略的復(fù)雜度。
[0059] -個實時的語音通話數(shù)據(jù)流的編碼分組通常如圖2所示，若干個音頻包構(gòu)成了一 個編碼分組，音頻數(shù)據(jù)包之間的發(fā)送間隔是固定的（比如60ms)，在分組的最后一個音頻數(shù) 據(jù)包發(fā)出之后會立即再發(fā)送這個編碼分組所對應(yīng)的FEC包，F(xiàn)EC包的數(shù)量與設(shè)定的冗余率 相關(guān)。
[0060] 于是，一個實時的語音通話數(shù)據(jù)流如圖3所示，由一個個連續(xù)的音頻編碼分組構(gòu) 成，每個編碼分組根據(jù)當(dāng)時上下行通道的網(wǎng)絡(luò)狀況攜帶了不同數(shù)量的FEC。
[0061] 上下行通道流控策略分離的基本思想是：發(fā)送方只對上行通道的網(wǎng)絡(luò)質(zhì)量負責(zé)， 即發(fā)送方上行的FEC數(shù)量只夠?qū)股闲卸秳蛹纯?；而中轉(zhuǎn)服務(wù)器在轉(zhuǎn)發(fā)上行數(shù)據(jù)之前，會 按編碼分組對上行的FEC進行重編，即使用音頻分組數(shù)據(jù)重新生成與音頻數(shù)據(jù)包數(shù)量相同 的FEC (50%冗余率）；然后在下行擴散音頻分組數(shù)據(jù)時，根據(jù)每一個下行通道的丟包率，動 態(tài)計算應(yīng)該下發(fā)的FEC數(shù)量（即對于網(wǎng)絡(luò)質(zhì)量好的下行通道，跳過一些FEC包的下發(fā)），使 每一個下行通道都能實現(xiàn)合理的冗余率，從而實現(xiàn)上下行通道流控策略的分離。完整的通 道控制分離和FEC重編與按需跳過的整體架構(gòu)如圖4所示。
[0062] 下面再詳細介紹流控策略的計算。
[0063] 參與多人通話的每個客戶端和中轉(zhuǎn)服務(wù)器都會將客戶端能力變化、網(wǎng)絡(luò)丟包狀況 和帶寬預(yù)測結(jié)果等重要信息周期性地上報給流控引擎，從而觸發(fā)流控引擎周期性地計算針 對每個客戶端的流控策略并下發(fā)給客戶端執(zhí)行。得益于混音引擎和上下行通道控制策略的 分離技術(shù)，消弭了多人語音通話上、下行通道的本質(zhì)差異（即收聽方本應(yīng)接收多路下行語 音數(shù)據(jù)），使得上下行通道控制可以用統(tǒng)一的方式來進行，從而簡化了流控引擎的復(fù)雜度。
[0064] 流控引擎包括流控策略集合，其表現(xiàn)形式可以是如下所示的一個表格，表格中的 每一行代表一條流控策略。
[0065]
[0066] 流控引擎只需要根據(jù)客戶端的當(dāng)前狀態(tài)、網(wǎng)絡(luò)丟包率、帶寬預(yù)測值等信息查找對 應(yīng)的表項（也可稱為檔位）下發(fā)給客戶端即可。上述表格中，RateTH表示可用帶寬預(yù)測檔 位值（Kbps)，F(xiàn)EC表示是否需要加帶外FEC (其值只有0 = False，1 = True)，Kernel表示 核心碼率（Kbps)，Span表示發(fā)包間隔（ms)，而FECUP則表示冗余率。
[0067] 下面舉例來說明流控引擎是如何工作的。對于一個語音上行通道，其初始狀態(tài)的 檔位是LINE_1 ;在一個上報周期之后，假設(shè)該上行通道網(wǎng)絡(luò)質(zhì)量不錯，丟包率很低（低于某 個預(yù)定的閥值）且?guī)掝A(yù)測結(jié)果高于當(dāng)前檔位閥值，那么流控引擎就會對其做"升檔"處 理，即將核心碼率更大、發(fā)包間隔更小的LINE_2下發(fā)給客戶端；假定這段時間網(wǎng)絡(luò)情況一 直不錯，帶寬預(yù)測結(jié)果也一直高于當(dāng)前檔位閥值，則流控引擎就會一直做升檔處理，直到丟 包率增大、帶寬預(yù)測值低于當(dāng)前檔位閥值或已經(jīng)升到最高檔位為止（當(dāng)然，升降檔的速度 需要另外調(diào)控）。如果丟包率超過閥值但帶寬預(yù)測結(jié)果變化不大，則引擎會升檔到一個核 心碼率不變、但FEC冗余率變大的檔位來抵抗網(wǎng)絡(luò)波動；而如果帶寬預(yù)測結(jié)果小于當(dāng)前檔 位，則流控引擎需要降檔到一個符合帶寬預(yù)測值且FEC冗余足夠多的檔位來緩解帶寬壓力 并對抗過載。這個過程就好比駕駛一輛手動擋的汽車，車多擁擠時需要降檔緩行，車少通暢 時可以升檔提速（但不能超過限速閥值）；遠遠看到（預(yù)測）到前面車多擁堵時需要盡快 降檔減速；相反地，如果看到（預(yù)測）前面擁堵緩解時則需要緩慢提速避免發(fā)生事故。
[0068] 對于語音下行通道，除了 FEC重編和跳過策略之外，如果下行通道帶寬不足，流控 引擎還可以通知混音引擎調(diào)整該通道混音后數(shù)據(jù)的采樣率和編碼復(fù)雜度來達到以質(zhì)量換 帶寬的目的。但如果上行的采樣率已經(jīng)是系統(tǒng)設(shè)定的最小值，那么流控引擎也沒有更多辦 法做進一步處理，畢竟下行通道的調(diào)控余地比上行通道要小一些。
[0069] 綜上所述，通過本發(fā)明實施例一，在云端部署流控引擎和混音引擎，使多人語音通 話在單個會話規(guī)模上擁有了極強的擴展性，可以輕而易舉地支持單會話數(shù)千人同時在線的 體驗。相對于Skype單會話最多25人、且對發(fā)起方軟硬件和網(wǎng)絡(luò)環(huán)境要求及其嚴苛的限制 而言是一個巨大的進步。與此同時，"上下行通道流控策略分離"與"流控、混音雙引擎"架 構(gòu)也在最大程度上降低了上下行通道之間的相互干擾，保證了多人語音通話的最優(yōu)服務(wù)體 驗。
[0070] 實施例二
[0071] 基于本發(fā)明實施例一所提供的語音通話處理系統(tǒng)，本發(fā)明實施例二介紹一種云端 服務(wù)器。如圖1所示，該系統(tǒng)中的云端服務(wù)器中部署有語音通話的流控引擎，所述流控引擎 用于，接收參與語音通話的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀態(tài)信息、和/或所述中 轉(zhuǎn)服務(wù)器上報的狀態(tài)信息；根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服 務(wù)器上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器下發(fā)所述 流控策略給所述客戶端執(zhí)行。
[0072] 在一實施方式中，所述云端服務(wù)器中還部署有語音通話的混音引擎，所述混音引 擎用于，對接收的多路上行語音數(shù)據(jù)進行混音，并將混音所獲得的語音數(shù)據(jù)發(fā)送到語音通 話的所有收聽方客戶端。
[0073] 在一實施方式中，所述云端服務(wù)器還包括共享內(nèi)存，所述混音引擎和流控引擎之 間通過共享內(nèi)存完成數(shù)據(jù)交互。
[0074] 在一實施方式中，所述流控策略包括對應(yīng)所述客戶端的上行通道流控策略和下行 通道流控策略，所述客戶端的上行通道是所述客戶端作為語音發(fā)送方時到中轉(zhuǎn)服務(wù)器之間 的通訊通道，所述客戶端的下行通道是所述客戶端作為語音接收方時到中轉(zhuǎn)服務(wù)器之間的 通訊通道；
[0075] 其中，所述客戶端的上行通道流控策略和下行通道流控策略分離。
[0076] 在一實施方式中，所述流控引擎中存儲流控策略集合，所述流控策略集合中包括 至少一項流控策略；
[0077] 所述流控引擎進一步用于，根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所 述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，查找所述流控引擎中的流控策略集合，獲得與接收的信息 相匹配的流控策略。
[0078] 實施例三
[0079] 基于本發(fā)明實施例一所提供的語音通話處理系統(tǒng)，以及實施例二所提供的云端服 務(wù)器，本發(fā)明實施例三提供一種語音通話處理方法，將語音通話的流控引擎部署在云端服 務(wù)器。如圖5所示，所述方法包括：
[0080] 步驟501，流控引擎接收參與語音通話的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀 態(tài)信息、和/或中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息。
[0081] 步驟502,流控引擎根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服 務(wù)器上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器下發(fā)所述 流控策略給所述客戶端執(zhí)行。
[0082] 在一實施方式中，語音通話的混音引擎也部署在云端服務(wù)器，所述方法還包括：
[0083] 所述混音引擎對接收的多路上行語音數(shù)據(jù)進行混音，并將混音所獲得的語音數(shù)據(jù) 發(fā)送到語音通話的所有收聽方客戶端。
[0084] 其中，混音引擎和流控引擎之間通過共享內(nèi)存完成數(shù)據(jù)交互，所述共享內(nèi)存中可 用于存儲用戶信息、客戶端上報信息、語音通話的房間信息等等，以上信息都可以為所述混 音引擎和流控引擎所用。
[0085] 其中，所述流控策略包括對應(yīng)所述客戶端的上行通道流控策略和下行通道流控策 略，所述客戶端的上行通道是所述客戶端作為語音發(fā)送方時到中轉(zhuǎn)服務(wù)器之間的通訊通 道，所述客戶端的下行通道是所述客戶端作為語音接收方時到中轉(zhuǎn)服務(wù)器之間的通訊通 道；
[0086] 所述客戶端的上行通道流控策略和下行通道流控策略分離。
[0087] 所述流控引擎中存儲流控策略集合，所述流控策略集合中包括至少一項流控策 略；
[0088] 相應(yīng)的，所述云端服務(wù)器根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述 中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，包括：
[0089] 所述云端服務(wù)器根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù) 器上報的狀態(tài)信息，查找所述流控引擎中的流控策略集合，獲得與所述云端服務(wù)器接收的 信息相匹配的流控策略。
[0090] 綜上所述，本發(fā)明實施例在云端部署流控引擎和混音引擎，使多人語音通話在單 個會話規(guī)模上擁有了極強的擴展性，可以輕而易舉地支持單會話數(shù)千人同時在線的體驗。 相對于Skype單會話最多25人、且對發(fā)起方軟硬件和網(wǎng)絡(luò)環(huán)境要求及其嚴苛的限制而言是 一個巨大的進步。與此同時，"上下行通道流控策略分離"與"流控、混音雙引擎"架構(gòu)也在 最大程度上降低了上下行通道之間的相互干擾，保證了多人語音通話的最優(yōu)服務(wù)體驗。本 發(fā)明實施例通過強化和提升多人音視頻通話系統(tǒng)的云端服務(wù)能力，實現(xiàn)在用戶網(wǎng)絡(luò)質(zhì)量不 穩(wěn)定、上下行帶寬受限等不利因素的干擾下，仍然能夠持續(xù)、穩(wěn)定地提供清晰流暢的高質(zhì)量 多人語音通話服務(wù)。
[0091] 還需要說明的是，本發(fā)明實施例的流控策略并不僅包括FEC策略，還可以包括自 動重傳請求（ARQ，Automatic Repeat-reQuest)等其他策略。流控策略的計算也不僅限于 本發(fā)明實施例中描述的查表方式，還可以使用其他任何智能、動態(tài)的策略計算和調(diào)控方式。 "FEC重編與按需FEC跳過"中說明的音頻編碼分組內(nèi)的FEC的存在方式，可以不必嚴格放在 分組內(nèi)最后一個音頻包后面，而是可以根據(jù)實際需要放在分組內(nèi)任意的位置。流控引擎和 混音引擎可以同機部署，也可以不同機部署；流控引擎和混音引擎的交互方式也不僅限于 本發(fā)明實施例的共享內(nèi)存實現(xiàn)方式，還可以根據(jù)實際需要選擇采用其他可行的替代方式。
[0092] 本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實施例可提供為方法、系統(tǒng)、或計算機程序 產(chǎn)品。因此，本發(fā)明可采用硬件實施例、軟件實施例、或結(jié)合軟件和硬件方面的實施例的形 式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲 介質(zhì)（包括但不限于磁盤存儲器和光學(xué)存儲器等）上實施的計算機程序產(chǎn)品的形式。
[0093] 本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設(shè)備（系統(tǒng)）、和計算機程序產(chǎn)品的流程 圖和/或方框圖來描述的。應(yīng)理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一 流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計算 機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理設(shè)備的處理 器以產(chǎn)生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生 用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能 的裝置。
[0094] 這些計算機程序指令也可存儲在能引導(dǎo)計算機或其他可編程數(shù)據(jù)處理設(shè)備以特 定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指 令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或 多個方框中指定的功能。
[0095] 這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計 算機或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或 其他可編程設(shè)備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖 一個方框或多個方框中指定的功能的步驟。
[0096] 以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
【主權(quán)項】
1. 一種語音通話處理方法，其特征在于，語音通話的流控引擎部署在云端服務(wù)器，所述 方法包括： 所述流控引擎接收參與語音通話的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀態(tài)信息、和 /或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息； 所述流控引擎根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報 的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器下發(fā)所述流控策略 給所述客戶端執(zhí)行。2. 根據(jù)權(quán)利要求1所述語音通話處理方法，其特征在于，語音通話的混音引擎也部署 在云端服務(wù)器，所述方法還包括： 所述混音引擎對接收的多路上行語音數(shù)據(jù)進行混音，并將混音所獲得的語音數(shù)據(jù)發(fā)送 到語音通話的所有收聽方客戶端。3. 根據(jù)權(quán)利要求2所述語音通話處理方法，其特征在于，所述方法還包括：所述混音引 擎和流控引擎之間通過共享內(nèi)存完成數(shù)據(jù)交互。4. 根據(jù)權(quán)利要求1至3任一項所述語音通話處理方法，其特征在于，所述流控策略包括 對應(yīng)所述客戶端的上行通道流控策略和下行通道流控策略，所述客戶端的上行通道是所述 客戶端作為語音發(fā)送方時到中轉(zhuǎn)服務(wù)器之間的通訊通道，所述客戶端的下行通道是所述客 戶端作為語音接收方時到中轉(zhuǎn)服務(wù)器之間的通訊通道； 其中，所述客戶端的上行通道流控策略和下行通道流控策略分離。5. 根據(jù)權(quán)利要求1至3任一項所述語音通話處理方法，其特征在于，所述流控引擎中存 儲流控策略集合，所述流控策略集合中包括至少一項流控策略； 相應(yīng)的，所述云端服務(wù)器根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn) 服務(wù)器上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，包括： 所述云端服務(wù)器根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上 報的狀態(tài)信息，查找所述流控引擎中的流控策略集合，獲得與所述云端服務(wù)器接收的信息 相匹配的流控策略。6. -種云端服務(wù)器，其特征在于，所述云端服務(wù)器中部署有語音通話的流控引擎，所 述流控引擎用于，接收參與語音通話的客戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀態(tài)信息、和/ 或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息；根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所 述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，計算對應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器 下發(fā)所述流控策略給所述客戶端執(zhí)行。7. 根據(jù)權(quán)利要求6所述云端服務(wù)器，其特征在于，所述云端服務(wù)器中還部署有語音通 話的混音引擎，所述混音引擎用于，對接收的多路上行語音數(shù)據(jù)進行混音，并將混音所獲得 的語音數(shù)據(jù)發(fā)送到語音通話的所有收聽方客戶端。8. 根據(jù)權(quán)利要求7所述云端服務(wù)器，其特征在于，所述云端服務(wù)器還包括共享內(nèi)存，所 述混音引擎和流控引擎之間通過共享內(nèi)存完成數(shù)據(jù)交互。9. 根據(jù)權(quán)利要求6至8任一項所述云端服務(wù)器，其特征在于，所述流控策略包括對應(yīng)所 述客戶端的上行通道流控策略和下行通道流控策略，所述客戶端的上行通道是所述客戶端 作為語音發(fā)送方時到中轉(zhuǎn)服務(wù)器之間的通訊通道，所述客戶端的下行通道是所述客戶端作 為語音接收方時到中轉(zhuǎn)服務(wù)器之間的通訊通道； 其中，所述客戶端的上行通道流控策略和下行通道流控策略分離。10. 根據(jù)權(quán)利要求6至8任一項所述云端服務(wù)器，其特征在于，所述流控引擎中存儲流 控策略集合，所述流控策略集合中包括至少一項流控策略； 所述流控引擎進一步用于，根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中 轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，查找所述流控引擎中的流控策略集合，獲得與接收的信息相匹 配的流控策略。11. 一種語音通話處理系統(tǒng)，其特征在于，所述系統(tǒng)包括：云端服務(wù)器和中轉(zhuǎn)服務(wù)器， 其中， 所述云端服務(wù)器中部署有語音通話的流控引擎，所述流控引擎接收參與語音通話的客 戶端通過中轉(zhuǎn)服務(wù)器上報的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息；根 據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，計算對 應(yīng)所述客戶端的流控策略，并通過所述中轉(zhuǎn)服務(wù)器下發(fā)所述流控策略給所述客戶端執(zhí)行； 所述中轉(zhuǎn)服務(wù)器用于，為客戶端提供接入和數(shù)據(jù)中轉(zhuǎn)、擴散通道，接收客戶端的能力和 狀態(tài)信息上報到所述流控引擎，接收所述流控引擎的流控策略并下發(fā)到相應(yīng)的客戶端。12. 根據(jù)權(quán)利要求11所述語音通話處理系統(tǒng)，其特征在于，所述云端服務(wù)器中還部署 有語音通話的混音引擎，所述混音引擎用于，對接收的多路上行語音數(shù)據(jù)進行混音，并將混 音所獲得的語音數(shù)據(jù)發(fā)送到語音通話的所有收聽方客戶端。13. 根據(jù)權(quán)利要求12所述語音通話處理系統(tǒng)，其特征在于，所述云端服務(wù)器還包括共 享內(nèi)存，所述混音引擎和流控引擎之間通過共享內(nèi)存完成數(shù)據(jù)交互。14. 根據(jù)權(quán)利要求11至13任一項所述語音通話處理系統(tǒng)，其特征在于，所述流控策略 包括對應(yīng)所述客戶端的上行通道流控策略和下行通道流控策略，所述客戶端的上行通道是 所述客戶端作為語音發(fā)送方時到中轉(zhuǎn)服務(wù)器之間的通訊通道，所述客戶端的下行通道是所 述客戶端作為語音接收方時到中轉(zhuǎn)服務(wù)器之間的通訊通道； 其中，所述客戶端的上行通道流控策略和下行通道流控策略分離。15. 根據(jù)權(quán)利要求11至13任一項所述語音通話處理系統(tǒng)，其特征在于，所述流控引擎 中存儲流控策略集合，所述流控策略集合中包括至少一項流控策略； 所述流控引擎進一步用于，根據(jù)接收的所述客戶端的能力和狀態(tài)信息、和/或所述中 轉(zhuǎn)服務(wù)器上報的狀態(tài)信息，查找所述流控引擎中的流控策略集合，獲得與接收的信息相匹 配的流控策略。
【文檔編號】H04L29/08GK105991577SQ201510073420
【公開日】2016年10月5日
【申請日】2015年2月11日
【發(fā)明人】薛笛
【申請人】騰訊科技（深圳）有限公司