你可能會認為語音質(zhì)量問題是過去的事情了，因為我們已經(jīng)知道延遲、抖動和數(shù)據(jù)包丟失是在幾十年內(nèi)損害VoIP質(zhì)量的因素。但隨著網(wǎng)絡基礎(chǔ)設施和流量的變化，聲音質(zhì)量也會隨之改變。你在網(wǎng)上發(fā)送語音信息嗎？你使用的是基于云的通信嗎？你需要一次又一次地測量，以確保聲音的質(zhì)量仍然是可以接受和一致的。問題是，你想擁有這項技術(shù)還是使用云服務來進行語音質(zhì)量測試？

　　關(guān)于這個主題的新觀點，我采訪了Nick Kephart，他是ThousandEyes的高級產(chǎn)品主管，該公司為監(jiān)控網(wǎng)絡基礎(chǔ)設施、故障排除應用程序交付以及映射網(wǎng)絡性能提供了工具，所有這些都是從一個基于SaaS的平臺上完成的。如下圖所示。

　　Kephart：考慮到語音通信的實時特性，其尤其容易受到延遲和抖動的影響。聲音是一種高度可見的、關(guān)鍵的服務，員工、客戶和管理人員會迅速注意到性能問題。然而，大多數(shù)監(jiān)控產(chǎn)品只關(guān)注端到端呼叫細節(jié)記錄【CDRs】。他們忽略了網(wǎng)絡細節(jié)，在某種程度上足以定位容量問題、抖動、丟失、延遲和DSCP（QoS）。隨著基于云計算的UC和VoIP被采用，對網(wǎng)絡端到端連接和服務交付的依賴只會使監(jiān)控方式的轉(zhuǎn)變更加關(guān)鍵。

　　Kephart：傳統(tǒng)的VoIP監(jiān)測技術(shù)依賴于CDRs和數(shù)據(jù)包捕獲，經(jīng)常是反應性的，發(fā)現(xiàn)問題的時候已經(jīng)為時太晚。它們也幾乎沒有提供在企業(yè)網(wǎng)絡之外的任何可見性。這些技術(shù)可以通過對語音流量的主動監(jiān)控來補充，這些流量既測試了VoIP呼叫的設置，也測試了語音流的質(zhì)量。這意味著要積極地監(jiān)控語音呼叫的所有部分，從SIP信號到RTP流。

　　每個網(wǎng)絡段都是至關(guān)重要的�？梢酝ㄟ^將SIP事務、語音質(zhì)量和QoS度量與底層網(wǎng)絡性能相關(guān)聯(lián)的能力來加速故障診斷，以便更好地理解端到端服務體驗。

　　Kephart：SIP到模擬PSTN電話系統(tǒng)，從私有到公共領(lǐng)域，會增加另一層復雜性，因為它們需要互連網(wǎng)關(guān)，將VoIP流翻譯成模擬信號。然而，這種情況越來越少，大多數(shù)公共和私有部署都轉(zhuǎn)移到了基于IP的系統(tǒng)。

　　是否存在常見的服務器問題--客戶與供應商者？

　　Kephart：隨著UCaaS的部署，在企業(yè)之外，語音通信遍歷的大部分網(wǎng)絡都在這個網(wǎng)絡中。我們的客戶經(jīng)常遇到影響語音質(zhì)量和交付的ISP（服務提供商）運行中斷。由于DSCP在客戶和ISP網(wǎng)絡中都存在，因此遇到QoS問題也是很常見的�？蛻艟W(wǎng)絡可以有各種各樣的問題，從DNS解析到擁塞到糟糕的內(nèi)聯(lián)設備性能。

　　Kephart：一些UCaaS提供者為性能數(shù)據(jù)提供一個API，但是這些都集中在調(diào)用后的度量集合上。最終用戶（企業(yè)）希望是積極主動的，對基于云的UC和VoIP服務的性能進行實時觀察，以評估供應商，正確決定SLA性能，并解決問題。

　　Kephart：通常，當基于云的VoIP流量在互聯(lián)網(wǎng)上傳輸時，只有聽天由命了，這是因為互聯(lián)網(wǎng)是一個由他人的第三方基礎(chǔ)設施組成的公共“盡力而為服務”的網(wǎng)絡。大多數(shù)UCaaS供應商都有自己的數(shù)據(jù)中心和服務的可用性，而不是來自于客戶位置的連接性。

　　Kephart：當流量橫貫公司網(wǎng)絡或互聯(lián)網(wǎng)時，了解問題的原因和發(fā)生的地方將有助于更快地解決問題。方法可以包括進行路由和連接性更改，向服務提供商提供更開放的數(shù)據(jù)，或者在長期內(nèi)考慮對架構(gòu)的更改或?qū)Ψ�務提供商的另行選擇。

　　我們從測試和改進VoIP質(zhì)量中學到的經(jīng)驗可以應用于視頻傳輸。主要的區(qū)別在于，視頻比聲音消耗更多的帶寬。因此，視頻傳輸更容易受到損害，問題立即可見。有時我們還能理解受損的聲音，因為我們知道這個主題，或者知道說話者，但當視頻被打斷時，很難想象屏幕上發(fā)生了什么。