騰訊會議去年推出，疫情期間兩個月急速擴容，日活躍賬戶數已超過1000萬，成為了當前中國最多人使用的視頻會議應用。騰訊會議突圍背后，是如何通過端到端實時語音技術保障交流通暢的？本文是騰訊多媒體實驗室音頻技術中心高級總監商世東老師在「雲加社區沙龍online」的分享整理，從實時語音通信的發展歷程，到5G下語音通信體驗的未來，為你一一揭曉。
一、通信系統的衍變
1. 從模擬電話到數字電話
說到騰訊會議背后的實時語音端到端解決方案，大家可能第一時間就想到了PSTN電話，從貝爾實驗室創造模擬電話開始，經過一百多年的發展，整個語音通信、語音電話系統經歷了很大一部分變化。尤其是最近三十年來，語音通話由模擬信號變為數字信號，從固定電話變為移動電話，從電路交換到現在的分組交換。
以前的PSTN電話系統，用的都是老式模擬話機。然后數字相對模擬電話的優勢是顯而易見的，尤其在通話語音質量上抗干擾，抗長距離信號衰減的能力明顯優於模擬電話和系統，所以電話系統演進的第一步就是從終端從模擬電話升級到了數字電話，網絡也升級到了ISDN(綜合業務數字網)，可以支持數字語音和數據業務。
ISDN的最重要特征是能夠支持端到端的數字連接，並且可實現話音業務和數據業務的綜合，使數據和話音能夠在同一網絡中傳遞。但是本質上，ISDN還是電路交換網絡系統。
所謂的電路交換，就是兩個電話之間有一條專有的電路連接。基於專有電路連接的好處就是通話質量穩定。保證了鏈路的穩定性和通信的質量，同時也保證了整個通信的私密性。但是，這種基於電路交換的PSTN電話系統帶來的弊端也很明顯，尤其是打長途電話的時候。長途電話是基於專有線路，所以價格會非常昂貴。
同時，這一階段，基於IP的互聯網開始蓬勃發展，已通話為目的的通信終端也開始了從電路交換到分組交換的演進。如上圖所示，分組交換的好處就是：可以分享帶寬，整個鏈路連接並不是通話雙方專享，而是很多電話共享的。共享帶來的好處就是成本大幅度下降，同時，也進一步推動了整個電話語音通信技術的不斷發展。
2. 從數字電話到IP電話
從2000年左右，當網絡開始經歷開始從電路交換到IP分組交換這樣的衍進過程當中，近十年大家又開始面臨一個新的挑戰：整個網絡、通信的終端較以前變得紛繁復雜，更加多樣化。
以前主要就是電話與電話之間的通話，現在大家可以使用各種基於IP網絡的客戶端，比如PC、移動App，電話等通話，電話到電話間可以通過傳統的電路交換，也可以是基於IP網絡的數字電話。這樣就導致了一個很顯著的問題：整個網絡開始變得異常復雜，異常多樣化，終端也變成異樣多樣化。
在這樣一個衍進過程當中，如何保證它們之間的互通性？傳統的電話終端，跟不同互聯網電話終端之間怎樣解決互聯互通的問題，又如何保證通話的質量和通話的體驗呢？
3. H323與SIP協議
對於語音通話，不管是基於VoIP技術，還是基於傳統的電路交換的電話，都有兩個問題需要解決：首先需要注冊到電話網里去，注冊進去以后，在撥打電話的過程中，還需要弄清以下這些問題：怎樣建立一個電話、怎樣維護這個電話，以及最后怎樣關閉這個電話？
電話建立起來以后還要進行能力協商，如果是IP電話，能力協商的本質就是雙方交換彼此的IP和端口地址，建立邏輯通道才能進行通話。
在PSTN電話網絡向IP電話網絡衍進的過程當中，出現了兩個非常有意思的協議族，第一個是H323協議。這個協議來自國際電信聯盟ITO，它是傳統制定電報電信標准的國際化組織。還有一個協議來自於互聯網IETF（互聯網工作組）制定的有關Internet各方面的很多標准。這兩個標准協議的國際化組織各自推出相應的面對互聯網通話的一整套解決方案。
H323協議族解決方案貫徹了ITO組織一貫的嚴謹，大包大攬的作風，整個協議族定義的非常完整和詳細。從應用層到下面的傳輸層，使用H.225協議注冊電話，用H225.0協議建立和維護電話，以及用H245在整個電話過程當中進行各種能力協商，進行IP地址的交換......這樣一整套協議的制定，包括下面傳輸音視頻使用RTP協議進行碼流的傳輸，用RTCP協議進行整個碼流的帶寬控制，統計信息的上報，以及整個RTP協議上的音視頻編碼格式設置。整個H323協議族定義得非常詳細而又完整，可以用做互聯網上進行音視頻通話的標准。
這個標准被很多大公司采用，像思科和微軟的產品都遵循過H323標准。但是即使H323標准定義得如此完整和詳細，它的市場推進速度卻依然很慢。
而SIP協議來自IETF互聯網工作組，互聯網工作組的風格是開放和靈活的，所以他的整個協議也完全繼承了其一貫的開放與靈活的思路。整體架構非常簡單，SIP協議相對於H.323來說，並不規定媒體流具體是什么，只規定信令。整個SIP是利用互聯網上已有的被廣泛采用的像HTPP協議進行傳輸，整個message包全部都是用文本格式寫的。所以在它各個不同的Entity之間，包括電話、Prosy、DNS、Location servier之間的通信是開放而又靈活的。
它不規定具體內容，只規定整個SIP協議有什么框架，什么樣的網絡結構，SIP模塊之間互相通信遵循什么協議，例如用SDP協議來進行通信。通信格式也不是二進制，而H323協議就是二進制格式，非常難以擴展和閱讀。
SIP協議非常開放和靈活，於是被很多公司和產品廣泛采用，用在互聯網通話過程中的通話建立，通話維護。但是它也有自身的弊端，那就是各個廠商之間的SIP解決方案往往難以互聯互通。
H232和SIP協議，由於它們之間的定位不同，兩家國際標准化組織的風格不同，在市場上也沒有絕對的一家獨大，各自都保留相應的市場份額。也正是因為有了H323或者SIP協議的出現，才使互聯網上基於IP音視頻的通話有了可能。
騰訊會議系統里面的音頻解決方案正是這兩個協議族和框架，在整個信令的解決方案上采用了H323協議，跟PSTN電話進行互聯互通。在互聯網和VoIP客戶端之間采用SIP協議進行互聯互通。
4. VoIP技術面臨的困難和挑戰
VoIP技術是基於當前這樣復雜IP網絡環境中，同樣面臨很多挑戰。在電路交換中，因為資源是獨占的，雖然貴但是質量可以得到保證。但是基於VoIP的解決方案是分組網絡，不是獨占資源，就會面臨很多網絡架構上的挑戰，以及來自聲學方面的挑戰。
（1）丟包挑戰
網絡架構上的第一挑戰是丟包，因為不是獨有，而且整個UDP協議也不保證整個包一定送達目的地。
（2）延時挑戰
第二個挑戰是延時。整個IP網絡存在很多交換機、存在各種中間交換節點，在各交換節點會產生延時。
（3）Jitter
第三個挑戰是分組交換獨有的一個概念：Jitter。就是對於延時的變化，雖然從發送的時間上來看，第一個包發出的時間比第二個包要早，但是到達目的地卻可能是第二個包先到，導致就算收到第二個包，但是沒有收到第一個包，語音也不能放出來。
（4）回聲問題
VoIP電話相對於PSTN電話，會面臨延時帶來的挑戰，導致我們在Echo的處理上也和傳統大為不同。
傳統電話很多時候不用考慮Echo，因為本地電話基本延時都能控制在50毫秒以內，人眼是分辨不出來到底是回聲還是自己的講話聲音。但是互聯網上因為Delay增大，甚至可能超過150毫秒，所以必須要把回聲問題很好地解決，否則人耳聽起來會感覺非常不舒服。
（5）帶寬問題
另外整個網絡的帶寬，也跟通話質量息息相關。如果容量不夠，對於VoIP通話路數和質量也會有很大的影響。
5. 騰訊會議的音視頻解決方案
下圖所示的是VoIP協議棧里面的一個主要框架，H323協議、SIP協議，它們各自在整個OSI集成網絡模型中對應什么樣的Layer，不同Layer之間是怎樣進行交互的。
在整個騰訊會議語音通信里，H323和SIP信令怎樣才能把呼叫建立起來，建立起來以后最重要的音視頻媒體流在網上又是怎么傳輸的呢？
（1）實時語音通信：RTP協議
業界對於實時語音通信普遍采用的是RTP協議，RTP協議是基於UDP協議。因為它是UDP協議，所以跟TCP不太一樣，它並不能保證無丟包，它是只要有包就想盡辦法傳送目的地。
RTP在語音通訊的過程中肯定不能直接跑在UDP上，因為語音通話對於丟包，抖動導致的語音卡頓非常敏感，但是也不能采用TCP協議，因為帶來的延時太大。
所以目前大家都會采用RTP協議。RTP協議有一些機制，有兩個典型的字段：Sequence Number 和 Time Stamp。通過這兩個字段保證到達接收端的語音包在不連續或者亂序的情況下依然能通過一定的機制解決這個問題，在抖動不過大、丟包不過大的情況下不至於使語音通信的質量過低。
同時RTP協議里面，對於電話系統來說，語音通話存在多路流的情況。多人講話，有音頻、有視頻，所以RTP定義了SRSC Identifier，不同的SRSC對應不同的音頻流，不管是客戶端還是服務器都可以根據情況進行混音或者混流的操作。
（2）Opus語音引擎
基於互聯網的VoIP解決方案其實有很多選擇，從最早的H323、G.711系列開始前前后后二三十年有幾十種標准出現，但是目前Opus大有一統江湖的趨勢。
從下圖可以看出，整個Opus 覆蓋了很寬的bite rate，從幾kbps到幾十kbps，Opus不光支持語音，也可以很好的支持到音樂場景，將來騰訊會議業務范圍在音樂場景上也會占有一定的比例。
同時Opus還是一個低延時的語音引擎，因為在實時語音通訊中延時顯得相當重要，延時超過200毫秒對於實時語音通信來說是顯然不行的。
二、騰訊會議用戶痛點和技術難點
在真正使用技術解決騰訊會議當中的音頻問題的時候，還是能碰到很多的難點和痛點。我們在騰訊會議開發過程當中發現，用戶在實際的使用體驗過程中，由於各種各樣的原因，導致出現許多問題。
1. 常見聲音問題
（1）無聲問題
首先是無聲問題，例如通過VoIP客戶端或者通過電話入會過程當中就能碰到無聲問題，像驅動異常，硬件設備異常，無麥克風權限，設備初始化，電話打斷等也能造成無聲問題。
（2）漏回聲
在實時語音過程當中還會出現漏回聲的問題，在傳統的PSTN電話系統中基本不存在回聲，因為延時比較低，而且大部分電話都是話筒模式，很少使用外放。但是使用VoIP客戶端，比如說PC和手機終端，越來越多的人喜歡使用外放，而不需要把耳機放在耳朵，這樣就容易產生回聲問題。
（3）聲音嘈雜
同樣還有聲音嘈雜的問題，比如在移動場景，室外，或者是辦公室里辦公，大家使用VoIP客戶端會經常聽到辦公室里的敲鍵盤聲音、水杯喝水的聲音，這些嘈雜聲在以前使用普通電話話筒模式下並不明顯。
（4）音量小，飄忽不定
還會有音量小，音量飄忽不定的情況出現，這也是跟使用的外設和使用的場景相關。像基於PC、Mac或者移動設備的系統播放回調過高，系統CPU載入過高，手持麥克風姿勢不對，音樂語音判斷錯誤，還有網絡Jitter導致加減速，這些情況都會導致會議語音過程中碰到各種各樣的問題，而在以前的通話里面基本上沒有這些問題。
（5）聲音渾濁，可懂度差
還有聲音渾濁，可懂度差的問題，現在的實時通話場景比以前復雜的多，假如是在重混響的場景下，或者采集設備很差的環境下面通話，就容易導致聲音的音質比較差。
（6）音頻卡頓
還有像聲音卡頓的問題，這個是所有使用VoIP通話過程當中大家都容易經歷到的。聲音卡頓大家第一時間會想到是和網絡相關，但是實際解決問題的過程當中，我們發現有很多的原因都有可能導致音頻卡頓。網絡雖然占了很大一塊，但不是所有的原因。
比如在信源質量差的時候進行聲音信號處理的過程中會出現卡頓，因為一些很小的語音會被當成噪聲消掉。同樣，CPU過載，播放線程同步失效也會導致卡段，處理回聲采集播放不同步的時候，導致漏回聲的現象也會出現卡頓。所以在會議過程當中，會有來自很多方面的原因，導致最后的音質受損。
（7）寬帶語音變窄帶語音
另外我們還發現了一個很有意思的現象，我們公司內部很多在使用IP電話，話機和話機之間的通信音質通常比較好，但是一旦切入到騰訊會議就會發現話音由原來寬帶的變成了窄帶。
為什么會這樣？很多時候是跟我們公司IP系統采用的網絡拓撲結構有很大關系。因為很多公司內部很多網段並不能實現互聯互通，這個時候往往需要經過轉碼，提供轉碼服務的語音網關為了保證最大的兼容性，往往會將原來高品質的語音通話直接轉碼成G.711，這個是三四十年前使用的窄帶標准，能保證最大的兼容性，所有話機和系統都支持，但是音質相應的也會變成窄帶的了。
寬帶的語音、窄帶語音，以及房間的重混響，都會導致音質受損，而且我們發現重混響對人耳的影響跟整個音量大小有關系，當你覺得音量不適合或者過響的時候，那么在重混響的房間里音質可能會進一步受損，再加上卡頓或者嘈雜聲等多種因素聚合一塊兒的時候，基於VoIP的通話音質就會受到很大挑戰。
2. 同地多設備入會挑戰
在使用騰訊會議的過程當中，還會出現同地多設備的問題。在以前使用電話的場景下，大家基本不會碰到這樣的問題，因為一個房間就一個電話，不存在多個電話、多個聲學設備在同一個地方入會的情形。現在隨着會議解決方案的普及，每個人電腦上面都能安裝一個協同會議的客戶端，大家習慣性帶着電腦參加會議，分享屏幕和PPT內容。每個人都進入會議，把他的屏幕分享打開，一下子會發現，在一個會議室里面出現了很多個終端在同一個房間入會，同樣多個聲學設備在同一個地方入會，立刻帶來問題就是有回聲。
對於單個設備來說，可以捕捉到播放信號作為參考，進而解決回聲問題。但是對於多個設備來說，比如我這台筆記本的麥克風處理程序是怎么也不可能拿到另外一個人的揚聲器播放出來的聲音參考信號的，由於網絡延時和當時CPU的情況不一樣，這么做是不現實的。所以通常只能在本機解決簡單的回聲問題，對同樣房間多個聲源設備播放的聲音沒有很好辦法處理。稍微好一點的情況就是產生漏回聲，差一點的就會直接產生嘯叫。
騰訊會議有一個檢測方案，我們利用多個設備互相存在的相關性，解決這樣一個同地多設備入會的問題，下文還會詳細展開。
三、AI技術提升會議音頻體驗
在騰訊會議里面，我們還采用了什么樣方法，來提高用戶的通話體驗呢？
1. 音頻領域的超分—頻寬拓展
第一，我們在通訊會議里針對一些窄帶語音，特別是來自PSTN的窄帶語音，做了窄帶到寬帶超分辨率擴展。
因為傳統的PSTN電話，音質頻率上限是3.4KHZ，人耳的直接聽感就是聲音不夠明亮，聲音細節不夠豐富，跟VoIP電話比起來，顯得差強人意。借助AI技術，根據低頻的信息進行預測生成，把高頻的分量很好的補償出來，讓原來聽起來比較沉悶，不夠豐富的語音變得更加明亮，聲音音質變得更加豐滿。
2. 丟包隱藏技術
第二，借助人工智能解決IP網絡里面臨的丟包挑戰，丟包這個問題本身有很多種解決方案，在傳輸層面可以解決，通過FEC方案在網絡層面都可以解決。但是網絡層面解決丟包問題本身局限性，不管是ARQ還是FEC方案都會伴隨着帶寬的增加或者是延時的增加，造成不好的體驗。
在聲學層面上，語音信號或者是語言幀之間是存在一定的相關性的。正常人說話的時候，一個字節大概時長為200毫秒，假設一秒最多說五個字，每個字段時長為200毫秒，對於我們語音幀來說，以20毫秒為單位時長進行編包。通過丟包隱藏技術，並不需要每一個包都要收到，丟的語音包只要不是特別多的像突發大批量的丟包，而只是零星的丟包，或者是網絡抖動帶來的丟包情況，都可以在聲學上通過數字信號處理技術和機器深度學習的技術把這些丟包彌補還原出來。
這樣在對語音幀的參數進行編碼的時候，我們可以通過一些數字信號處理技術和深度學習技術把丟失的參數預測出來，在信號層面通過各種濾波器把丟失掉的信號合成出來，再跟網絡傳輸層本身的FEC或者AIQ技術結合起來，可以很好解決網絡上丟包和抖動的挑戰。
3. 降噪語言增強
語音通信另外一個很強的需求就是降噪，大家都不想聽到環境噪聲，最想關注的就是語音本身。傳統的降噪技術，經過了三四十年的發展，不管是基於統計學或者是其他的方法已經可以很好的解決傳統平穩噪聲的降噪，能夠准確估計出平穩噪聲。
但是對於現在常見的非平穩，突發的聲音的降噪，經典的語音處理技術就相形見絀了。騰訊會議音頻解決方案是利用機器學習方法來訓練模型，不斷學習突發噪聲本身具有的特性，如噪聲頻譜特性等，最終很好的把這些傳統的數字信號技術解決不了的如鍵盤聲、鼠標聲、喝水水杯聲、手機震動聲等等這些突發的聲音消除掉。
4. 語音音樂分類器
另外會議需要考慮音樂的存在場景，比如老師給學生講課，時常會做一些視頻內容的分享，這個時候就會存在高品質的背景音樂出現。如果我們的方案僅僅能處理語音，卻不能處理音樂，對我們的一些應用場景就會有比較大的限制，所以如下圖所示，我們研發了這樣的語音音樂分類器，能夠很好的將背景音樂集成到會議音頻中去。
四、音頻質量評估體系
對於像騰訊會議這樣支持上千萬DAU的互聯網產品來說，對於音頻的實時監控和音質評估是非常重要的。我們在整個騰訊會議開發期間，很大程度上借鑒實施了基於ITO國際電信聯盟對於通信音質的測試評估方案，如下圖所示，在音質測試評估方案中，我們配備了標准的人工頭，標准的參考設備，來對整體語音通話的音質進行測試和評估。
整套評估方案我們參考了ITU，3GPP的標准，對在不同的聲源環境，不同的測試碼流，不同的聲源條件下，各種不同的測試場景都有完整的定義，對於單向的語音通話，雙講，消除漏回聲，降噪，評估語音SMOS和NMOS分數都有相應的標准。
如何對騰訊會議處理過的音質信號進行打分，怎樣判斷音質是否滿足要求？我們已經形成了一整套完整的語音質量評估體系，來對整個端到端的語音通信質量進行評估。
以前在整個語音通話過程當中，無參考的音質評估普遍基於QoS參數模型的評估方案，更多是從使用的編碼器類型，通話過程當中是否有丟包，延遲多少，整個音質使用的碼流是多少，這些點出發，再根據參數推導出整個通話過程中的音質是怎樣的。
這種方案對於運營商或者網絡規划部門比較有用，因為他可以拿到這些參數。對於用戶來說，就沒有那樣的直觀感受了。
對於用戶來說，能直觀感受到的就是：是否存在漏回聲，語音通話是否連續，通話音質是否自然等等。對於用戶來說更多會關注QoE角度，從個人體驗角度來看整個通話體驗是否得到滿意。我們把QoE指標進一步細化，主要看通話過程中的嘈雜聲程度，整個通話語音的色彩度（通話語音的自然度），是否有變聲和機械音，或者其他聽起來不自然的聲音，以及整個通話過程中語音是否存在卡頓？
人講話本身是有卡頓的，我說一個字后會短暫停一下再說下一個字。這種卡頓跟網絡丟包和網絡抖動帶來的卡頓是有明顯區別的，我們通過數字信號處理方案和機器學習技術從QoE這三個不同維度，對音頻進行無參考語音通信打分，這樣就能從現網上得知，用戶使用的通信會議效果是怎樣的。如下圖所示，用我們的無參考打分模型，跟有參考的數據進行擬合，可以看出，擬合的程度非常高。
基於無參考語音通話模型我們對現網通話質量可以有較好的把握，不需要拿到具體某一個語音的參考信號，僅僅根據播放端收到的信號，就能知道通話質量現在是否正常，如果不正常問題大概出現在什么地方。
五、會議音頻系統的未來展望
在會議音頻領域，除了通話以外，還有關於會議轉錄的需求。
微軟2019年年初宣布—Project Denmark，可以用手機和Pad采集不同會議講話人的聲音，並且把不同講話人聲音進行分離。我們知道，在一個會議室多個人同時說話，講話人聲音單純用ASR進行語音識別是無法實現的。最理想方法是把不同講話人分離出來，再分別接ASR的后端進行語音到文字的轉換。
一旦語音轉成文字以后，后面就可以做很多事情，比如生成會議紀要，對內容進行檢索，可以郵件發出來給沒有參加會議的人瀏覽觀看等等。
思科也在做同樣的事情，思科近期收購了一家公司，這個公司也是做會議內容轉錄。
但是會議人聲轉錄這里面會存在幾個問題：ASR識別。ASR識別提供了很多很好的語言識別解決方案，比如對方言的識別，對基礎的專有名詞的識別，ASR也提供了比較好的方案前后端進行調試。
對於同一房間多人開會的會議音頻轉錄來說最大挑戰是：如何在多人會議場景下對連續說話人進行檢測和切換?假如我說話的時候被別人打斷了，或者是兩個人講話的聲音重疊在一起，這個時候怎么有效把聲音進行切割分離呢?如果多人說話在時間線上不相關，這個時候切割相對是比較容易的，通過聲音識別把不同講話人識別出來就可以了。
但是如果他們說話有重疊的時候怎么進一步分離呢？包括切割出來信號怎么進行聚類，剛才講了幾句，后面又講幾句，中間又插進來一些別的人說話，怎么把我之前講的和之后講的話聚合到一起?這些相關的技術對於整個會議轉錄來說都是非常重要的，目前有很多公司也在這方面加大投入，騰訊也有在做這樣的事情。
除了會議轉錄需求之外，整個VoIP技術也是在不斷的演進過程當中。常常聽到有人問:整個5G對於語音通訊意味着什么?有人覺得語音5G帶寬那么大，語音通話帶寬這么小，沒有太大意義。
其實不然，5G其實會為VoIP技術提供更大更好的舞台。首先是帶寬對於會議語音通訊的推動作用，雖然語音本身的帶寬很小，只有幾十kbps，但是對於會議音頻來說情況遠比這個復雜。會議當中除了傳輸語音之外，還可以傳輸高品質的音頻，高品質的音頻就不是十幾K可以搞定的。會議講話人也可能不只是一路，會議當中同時開麥就會有好幾路產生，這種情況下對於會議音頻的帶寬消耗是很快的，在網絡條件不允許的情況下就有可能導致網絡擁塞。而5G一旦把帶寬上限拉大以后，會為會議音頻提供更大更好的舞台，我們可以提供更優質和更高品質的音質。
5G也可以極大改善延時，幾百毫秒的延時其實很大一部分都是消耗在傳輸延時上，但是5G可以令傳輸延時降低到原來的十分之一，對於整個實時可交互性體驗是很大的提高。
所以5G技術的發展，能為語音通話更好的聲音體驗，更沉浸式的體驗。只要帶寬不受限制，讓在會議音頻上實現基於AR、VR帶來的沉浸式體驗成為可能，當延時大幅度縮減以后，會議交互性也會更好。如果交互性能更進一步提高，其實跟人面對面溝通就沒有太大的區別了，這就是技術帶來的發展。
從整個商業角度來說，我們看到很多的變化正在發生。像融合通信，更多是作為service被越來越多場景使用，現在越來越少的人采用電話設備，都是采用雲的方式，因為帶來的初始成本降低是非常顯著的。
人工智能技術未來也會為語音通訊帶來越來越好的體驗，如前文提到的智能降噪、智能丟包補償技術就可以很好解決原來的一些問題，進而提供比原來PSTN網絡更好的音質體驗。
WebRTC技術也將會得到普及，WebRTC也有一整套的協議族，在瀏覽器里得到普遍支持以后，VoIP技術借助WebRTC能在很多場景里得到廣泛的應用。因為VoIP技術得到廣泛的普及，在In-app communications里的應用也會越來越多。
IoT領域VoIP技術也出現了上升趨勢，家里的智能音箱、智能冰箱等設備未來都會帶一些通訊功能，通過IP網絡進行連接。
Smarter VoIP assistants技術也會得到更多的發展， Smarter VoIP assistants是基於VoIP通話過程中提供的人工智能語音助手，來解決通訊過程中的語音問題。
六、Q&A
Q：老師關於實時音視頻通信可以推薦經典的書和開源項目嗎？
A：WebRTC就是很好的開源項目，基於WebRTC書籍也有，在網絡上搜索WebRTC也有很好的博客，關於WebRTC架構，里面核心的技術都有比較好的介紹，上網可以搜到。
Q：關於本地多設備的解決方案，能詳細講解一下嗎？
A：本地多設備是這樣，雖然本機的采集可以拿到本機的信號，從而可以做回聲抵消，但是本地的采集是不可能拿到房間里面另外一個設備的播放信號的，這是同地多設備問題的核心所在。我們雖然不能拿到另外一個設備的播放信號作為參考，但是這個本地播放設備，跟同房間另外一個播放設備之間存在很強的相關性。因為他們都來自於同樣的聲源，只是經過不同的網絡，不同的設備播放出來的時候，會有不同的失真和延時。所以我們不一定能做到同地多設備導致的嘯叫或者回聲抑制，但是一定做到同地多設備的檢測，一旦檢測同地多設備的時候，就可以用不同的產品策略來解決這個問題。因為同地多設備消除是非常困難，假如有三五個設備同時入會，打開麥克風，這簡直就是災難，要解決這個問題帶來聲學挑戰對於CPU消耗會非常大，很不值得，所以做好檢測就可以了。
Q：很多直播間都在使用WebRTC,老師談談WebRTC是否有發展前景？
A：WebRTC很有發展前景，它首先是開源項目。WebRTC在實時音視頻傳輸的時候，特別是對於網絡NAT技術，網絡穿越技術解決方案上都有很獨到的地方。WebRTC對於音視頻本身的編解碼，音頻的前處理都有一些相關的方案，WebRTC在很多場景都是很不錯的解決方案。
Q：重混響失音，怎么樣提高語音清晰度?
A：第一是多通道采集。使用麥克風陣列技術，通過方向性，比如說我在這個房間講話，我的聲音經過牆壁和桌子反射以后會被麥克風采集，造成干擾。如果麥克風是陣列形式，就可以很好對講話人進行聲源追蹤，盡量只采集我的直達聲，而屏蔽掉來自牆壁和桌面的反射聲，這樣可以很好的解決重混響問題。對於單通道麥克風的聲音采集，不管是經典的數字信號處理技術，還是機器學習都可以解決這個問題，但因為畢竟是一個過濾處理，有可能會導致音質受損，所以在單通道條件下去做混響處理，並不是一件很容易的事。
Q：VoIP和VoLTE相比，有什么優缺點？
A：VoIP和VoLTE走的思路不一樣。VoLTE傳輸的音視頻流，需要QoS保障，語音比較高，發生網絡擁塞優先傳輸語音，數據可以等等，差幾十毫秒沒有關系。所以VoLTE一定是保證帶寬，保證低延時的。從QoS角度來講，VoLTE有一定優勢，但是當5G帶寬高速公路越來越好之后，會發現VoLTE和VoIP相比就沒有太多優勢了。隨着未來5G的大規模普及，VoIP質量可以做得非常好。
Q：老師，出現卡頓時的具體解決的方法是什么？
A：出現卡頓具體解決方案有很多，關鍵要看卡頓的具體原因是什么。是網絡導致的卡頓，還是設備本身導致的卡頓，如果是網絡導致的卡頓就要看是網絡丟包導致還是抖動導致的，FEC技術可以解決一定的丟包問題，如果是抖動過大，就把Jitter包放大一點，雖然延時受損，但是可以解決抖動帶來的卡頓。如果是設備本身有問題，可能是CPU占用率過高，調度不過來。有時候信源也會導致卡頓，比如我突然轉過頭說話，麥克風定向采集我的講話聲音和原先聲音不匹配，這個時候就會突然聽到聲音變小，后台音效處理也會出現卡頓，所以卡頓原因比較復雜，需要分析原因有針對性的加以解決。
Q：大型直播，比如賽事比賽，發布會等直播，主要是用hls、flv等，5G時代是否可以用WebRTC技術呢？
A：兩個場景不一樣，直播的時候可能會跳動，或者VOD播放的時候如果延時比較大也沒有關系，延時超過200毫秒，500毫秒，甚至1秒都沒事，直播雖然晚一秒也不妨礙觀看和體驗。但是實時語音通信就不可以，超過300毫秒，甚至打電話1秒之后才回過來這肯定不行。我不覺得它們會用RTC技術，它們還是會用RTMP推流，或者HLS切包發送這樣的技術，因為雖然會帶來延時，但是在網絡抖動處理，包括其他很多方面都能處理得更好。所以適用的場景不一樣，未來做不同技術的考慮點也會不一樣。
Q：同地多設備沒有辦法拿到其他設備的參考聲音，通過什么辦法做到回聲消除？
A：同地多設備是沒有拿到其他設備的參考聲音，但是實際上采集聲音之間還是存在一定的相關性的，在算法上可以做出判斷和處理。
Q：深度學習算法對於音頻前處理相對於以前傳統的方法有什么區別？
A：有區別，傳統的數字信號處理方法在不同的場景下很難做到精准的定位，比如一些傳統的數字信號處理技術，對於突發的噪聲沒有很好的處理辦法。但是這種非線性的聲音用深度學習算法可以處理得很好，在擬合的時候能夠把傳統方式處理不好的問題，如殘留回聲、突發噪聲、降噪問題包括聚合的問題更好的解決。
Q：騰訊會議是在WebRTC框架嗎？
A：不是，騰訊會議不是在WebRTC框架下開發的。
Q：IoT應用就是智能家具產品應用嗎？
A：是，越來越多智能家具會使用IoT技術，如智能音箱等未來更多也會集成語音通信的技術。
Q：語音問題是一直存在的，很好奇騰訊會議是通過什么來收集和了解到那些問題的？一個在線的視頻語音產品怎么監測用戶語音的視頻質量？
A：我們需要無參考語音評估系統，有了無參考語音評估系統，就可以知道現網通信當中的語言質量是怎么樣的，是否存在問題，是什么樣的問題，問題出現在哪個區域、哪個時間段，或者發生在哪個外設上等等。
Q：對聲源定位，麥克風陣列有什么好的分享嗎？
A：聲源定位，麥克風陣列上有很多技術可以做，如DOA技術，麥克風陣列技術，傳統算法都是用來做語音信號處理的，上面有很多引申的技術發展出來，具體可以參考谷歌上的詳細介紹，回答得更有深度，我這里粗粗介紹一下。
Q：音頻質量的主觀、客評估手段用哪個參數來評估比較合適？
A：主觀評估就是召集人來打分，對於客觀評估，ITO對應有一個P863標准，參考這樣的語音標准對客觀指標進行打分，可以更進一步評估噪聲卡頓，語音質量等。
Q：老師，關於丟包處理補償處理，之前學校通信課程上老師有講過交叉幀處理的方式然后讓丟失的包分布在各個幀，利用幀數據之間的關聯來補償丟包？騰訊會議的丟包處理也是類似這樣的處理嗎，深度學習處理的大體思路是什么呢？
A：學校老師在課堂講的是針對突發大丟包的情況，把包分散到各個不同分組里面，收到組里面突發丟失的那一塊以后可以通過FEC技術將收到包復原出來。和這里不太一樣，分組交織可以解決一定的丟包問題，但是代價是延時過大，你把一個包或者多個包分到不同組，交織開來，收集的時候必須等所有包都收集完以后，才能把語音流復原出來，這樣就會帶來語言延時過大的問題。
Q：穿透轉發服務器搭建方面，騰訊能提供服務嗎？
A：關於WebRTC提供的穿越技術，騰訊雲也提供解決方案，但是騰訊會議使用的相關技術是供騰訊會議使用的，如果在你的解決方案里需要騰訊雲提供針對網絡穿越的NAT相關技術，是可以做到的。
Q：請問質量評估是否可以這樣做：本地進行抽樣，然后異步傳送（因為不需要實時，所以可以直接用TCP發送）給服務端，服務端對同樣區間的實時音頻流的數據進行抽樣，來作對比。
A：在測試過程當中可以做，在現網當中當然也可以做，但是本身抽樣會有很大局限性。像騰訊會議這樣千萬級DAU的產品，不太可能進行抽樣，抽樣對於評價現網也有很大局限性，我們更多建議通過無參考質量評估的手段搭建模型，對現網所有的數據進行實時評估。
講師簡介
商世東，騰訊多媒體實驗室高級總監，於2019年初加入騰訊多媒體實驗室，擔任多媒體實驗室音頻技術中心高級總監。加入騰訊前，商世東於2010年組建了杜比北京工程團隊，任職杜比北京和悉尼工程團隊高級總監9年。加入騰訊后，帶領多媒體實驗室音頻技術中心，負責實時音視頻SDK中的音頻引擎，音頻處理的設計和開發工作。
關注雲加社區公眾號，回復“在線沙龍”，即可獲取老師演講PPT~