本人在傳統的語音通信公司做過手機和IP電話上的語音軟件開發，也在移動互聯網公司做過APP上的語音軟件開發。現在帶實時語音通信功能的APP有好多，主流的有微信語音、QQ電話、釘釘等，當然也包括我開發過的那款APP（那款APP在實時通信APP排名中一直靠前）。既然都做語音軟件開發，那肯定有很多共同的地方，比如需要相同的語音專業知識，都有語音前處理、編解碼、傳輸等。通過自己的觀察，也有一些不同的地方。我們今天主要聊聊這些不同點。
1，在傳統語音通信公司都是在具體硬件上開發音頻軟件。有了硬件就要有相應的驅動，在Linux/Android上就是ALSA相關的驅動軟件開發。對於前處理、編解碼、傳輸等模塊，既可以在底層做也可以在偏上面的層次做，這取決於軟件架構。我曾經在Linux平台上硬件一樣軟件需求一樣的情況下由於軟件架構不一樣開發過兩套語音方案。一套方案是驅動在kernel space做，前處理、編解碼、傳輸等在user space做。另一套方案是驅動和前處理、編解碼、傳輸等全部在kernel space做。之所以要做兩套方案是因為第一套方案的性能不夠好，尤其表現在one way delay上。
在移動互聯網公司做APP上的語音軟件都是在上層做開發。驅動等對開發人員是黑盒子，開發人員要做的有前處理、編解碼、傳輸等，用好系統提供的API就可以了。以Android為例，對做APP來說用好media framework里提供的audio相關的（AudioRecord/AudioTrack等）API 就可以了。
2，上面說過在傳統語音通信公司里都是在具體硬件上開發軟件，一些音頻相關的參數就只有一套，在這個硬件上調好了就可以了。而在APP上做語音軟件開發，不針對具體的硬件。但是一些音頻參數要依賴於硬件，不同的硬件上參數不一樣，一個手機上調的效果很好的參數到另一個是手機上可能效果就很糟糕，所以在APP上做音頻軟件開發一個很重要的工作就是硬件適配。在不同的機型上用不同的參數，最起碼也要把主流的機型適配好，一些用戶量大的APP要適配上百款甚至幾百款機型。以回聲消除為例，它的一個很重要的參數就是從speaker（遠端）出來到mic（近端）進去的時延，不同的機型時延不一樣，這主要因為兩點：1）硬件不一樣，2）做APP都是在上層做，它要從底層拿到遠端和近端的PCM數據，不同的手機底層實現不一樣，時延也會不一樣。開發時就要把盡可能多的機型上的時延得到保存起來，用戶使用時根據不同的機型給出不同的時延值。
3，在傳統通信公司開發語音軟件，如果做有線產品，codec一般選用ITU-T的G系列（G711/G722/G726/G729等），如果做無線產品，codec一般選用3GPP的AMR系列（AMR-NB/AMR-WB等）。在APP上做語音軟件開發，codec更多的會選用互聯網陣營里提出來的iLBC/OPUS等。現在做語音通信，基本上形成了兩大陣營，即以ITU-T/3GPP為代表的傳統陣營和互聯網陣營，在codec上都有各自的演進策略。傳統陣營會演進到EVS（支持語音和音樂，最高48K采樣），互聯網陣營會演進到OPUS（支持語音和音樂，最高96K采樣）。中國移動已要求移動終端17年底可選支持EVS，18年中必須支持EVS，傳統陣營要求這么快演進也是被形勢所逼。前幾天微信語音功能進行了更新，可以像系統電話那樣來接聽微信語音電話，又要革電話的命了，以前革了短信的命。個人覺得互聯網公司在語音codec上選擇iLBC/OPUS還有一個原因是因為他們的語音方案多基於開源的來做，比如webRTC，而這些codec是開源方案里天然支持的，互聯網又要求快，他們必然會選擇這些已經調試適配好的codec。
4，在傳統通信公司開發語音軟件，一定要嚴格遵守各種協議（主要有3GPP/ITU-T/RFC的），不能有自己私有的協議，因為要過互通性測試。運營商在采購通信設備時一般會采購多家設備商的（采購多家設備商的設備有多方面原因，其中之一就是不想讓一家設備商一家獨大形成壟斷從而受制於他），通信終端更是多種多樣，大家必須遵守相同的協議才能互通，所以一定要嚴格遵守各種協議。
在移動互聯網公司開發APP上的語音軟件，客戶端（前台）是自己開發維護，服務器（后台）也是自己開發維護，即所有都是自己開發維護，不存在跟其他廠家的產品互通。這樣就會用很多私有協議。我開發過的那款APP就用了好多私有協議，有的是自己提出來的，有的是對已有公開協議的改造。這些協議如果有文檔還好，如果沒文檔在看代碼時就會特別累。
5，在語音通信過程中，一般有一半左右的時間在講話，剩下的時間在聽。在傳統通信公司開發語音軟件，為了節省帶寬和降低功耗，會對采集到的聲音做能量檢測（叫靜音檢測VAD），當聲音能量低於設定的門限值時就不發語音包給對法，取而代之的是發SID（Silence Insertion Descriptor）包給對方，通常是每隔一段時間發一個這樣的SID包，比如AMR-WB中的160ms，而且這種包的payload size很小。這相對於每隔20ms發一個的語音包來說大大的節省了帶寬。接收端收到SID后就會做CNG，產生舒適噪聲。由於不需要再做編解碼，這也一定程度上降低了功耗。在移動互聯網公司開發APP上的語音軟件，通常不考慮這些，所有采集到的語音數據都編碼用RTP打包發給對方。我開發過的以及微信都是這么做的。
6，傳統語音通信都是有QoS保障的，語音包的優先級是高於一般數據包的，會有一些措施來做丟包補償，但是措施不會特別多，常見的有PLC等。APP上的語音又叫OTT（Over The Top，是指互聯網公司越過運營商發展基於開放互聯網的各種音視頻及數據服務業務）語音，沒有QoS保障，為了保證語音質量，通常會采取多種補償方法，常見的有重傳、FEC等。在弱網情況下這些方法雖然會提高音質，但是要增加流量。如果幾種補償方法同時用，可能會成倍或者幾倍的增加流量。
7，傳統通信網絡通常會划分為終端、接入網、核心網等不同的網元，如下圖：
作為語音通信，終端會把采集到的語音編碼后打包經過attached的接入網設備核心網設備到對方attached的接入網設備再到對方終端播放出來。一般接入網設備和核心網設備只會透傳語音數據不會修改語音數據。
在APP上開發語音軟件，一般采用client-server機制，如下圖。
Client A 與Client B進行語音通信，A把語音數據發給B。A先把語音數據發給server的PORT A，server會把PORT A的數據路由到PORT B，再由PORT B把語音數據發給Client B。為了保證語音質量，一般會做兩次補償，先在server的PORT A上根據丟包率等做一次補償，盡可能復原出Client A發出的語音數據。再在Client B上做補償，盡可能復原出PORT B發出的語音數據。也就是說server會對客戶端發過來的語音數據做修改的，而不是透傳的。
8，在傳統通信公司做語音軟件開發，一定要過運營商的入網認證，包括各種場景下的語音質量（MOS值）、one-way-delay、round-trip-delay等指標。這些指標一定要過，不然拿不到入網證，拿不到入網證也就不能賣產品了。這些指標通常都是拿儀器測是否通過，要想過運營商的指標，公司一般都會有音頻實驗室，里面放着運營商指定的各種儀器，來模擬指定的各種場景。自己公司實驗室里指標測過了才有信心拿到運營商指定的實驗室去測。過認證是一個很痛苦的過程，因為這些都是系統性的問題，解決起來都是不容易的，有可能某個指標花了很長時間解決都不達標。話說回來，解決這些系統性問題的過程也是自己能力提高的過程，整個指標一遍做下來，能力會有一個大的提高。
在移動互聯網公司做APP上的語音軟件開發，不會有入網認證，任何時候都可以發布產品。一般公司也不會建音頻實驗室，因為建一個音頻實驗室花費較大（像騰X這樣的巨頭是有的，它做的很專業，它的兩款APP產品這么大的用戶量要求它必須做的很專業，做的不專業音質不好會把產品口碑做差的，而且這點花費對它來說不算什么）。各種場景下的語音質量等指標沒有一個確切的數據。用戶下載了APP用后覺得語音質量好就會繼續用，覺得語音質量不好的話就會卸掉不會再用了。
以上就是我基於做過的公司觀察到的一些不同點，有可能有遺漏，后面想到了再補上。也有可能其他移動互聯網公司做法有不同的地方，歡迎大家補充。