您當(dāng)前的位置是:  首頁 > 新聞 > 國內(nèi) >
 首頁 > 新聞 > 國內(nèi) >

SIP系列講座-SIP和QoS-1

2018-01-16 16:11:12   作者:james.zhu   來源:Asterisk   評論:0  點(diǎn)擊:


  SIP網(wǎng)絡(luò)環(huán)境中語音質(zhì)量是一個最重要的技術(shù)要點(diǎn)。如果語音質(zhì)量不好的話,用戶就會完全摒棄SIP網(wǎng)絡(luò)服務(wù)。因?yàn)椋琒IP網(wǎng)絡(luò)的發(fā)展也是根據(jù)網(wǎng)絡(luò)技術(shù)的發(fā)展而發(fā)展來的,SIP不可能脫離現(xiàn)在的技術(shù),它結(jié)合和采用了很多基礎(chǔ)技術(shù)和相關(guān)的技術(shù)協(xié)議,例如PSTN網(wǎng)絡(luò),傳輸方式,編碼,網(wǎng)絡(luò)管理和技術(shù)手段等方面的內(nèi)容。
  今天,為了更好地結(jié)合VOIP網(wǎng)絡(luò)來解釋QOS相關(guān)技術(shù)的重要性,我們重點(diǎn)討論以下幾個方面的內(nèi)容:
  1、VOIP網(wǎng)絡(luò)的概念回顧。VOIP網(wǎng)絡(luò)中的網(wǎng)絡(luò)傳輸方式的不同,IPPBX場景應(yīng)用,編碼格式問題。
  UDP和TUP。在VOIP網(wǎng)絡(luò)中,我們經(jīng)常會看到UDP和TCP的技術(shù)討論。簡單區(qū)別在于:UDP是一種實(shí)時傳輸?shù)姆绞剑瑳]有ACK確認(rèn),如果在發(fā)送過程中數(shù)據(jù)包丟失,系統(tǒng)也不會重新傳輸。TCP則不同,發(fā)送方每次發(fā)送一個數(shù)據(jù)包,它需要拿到ACK確認(rèn),如果在進(jìn)行下一次發(fā)送。所以,TCP可以保證數(shù)據(jù)的可靠性,但是傳輸速度和UDP相比,有所下降。在以下圖例中,Voice 3 在傳輸過程中已經(jīng)丟失,發(fā)送方仍然繼續(xù)發(fā)送Vocie 4. 所以,對端聽到的語音可能不是完整的語音,但是可以滿足雙方之間的基本溝通。在一般的應(yīng)用場景中,我們通話時,突然語音丟失或者失真,雙方可以接受這種狀態(tài)。但是,如果是數(shù)據(jù)的話,傳輸過程中有數(shù)據(jù)丟失,那可能對端完全不能打開這個文件。這是完全不能接受的應(yīng)用服務(wù)。
  目前很多應(yīng)用環(huán)境中,UDP的使用范圍仍然很普遍,但是隨著SIP技術(shù)的應(yīng)用越來越多,SIP header數(shù)據(jù)越來越大,UDP已經(jīng)很難滿足這些應(yīng)用的需求。所以,很多廠家的產(chǎn)品更多則支持了TCP傳輸方式。在剛才的討論中,我們已經(jīng)談到了TCP支持更多的交互和數(shù)據(jù)重組,因此,TCP的傳輸方式被很多廠家慢慢采用,最典型的例子就是微軟的Skype for Business。
  以下圖表匯總了TCP/UDP各種的工作環(huán)境和特點(diǎn):
  用戶可以根據(jù)應(yīng)用場景來使用相應(yīng)的傳輸協(xié)議。
  企業(yè)IPPBX是VOIP應(yīng)用中最為典型的應(yīng)用環(huán)境,同時又充分利用了TDM的語音優(yōu)勢和傳統(tǒng)資源。用戶可以通過TDM設(shè)備或者網(wǎng)關(guān)接入到IPPBX,也可以實(shí)現(xiàn)全國或者全世界分支機(jī)構(gòu)之間的互通。以下討論就是一個簡單的北京分公司和深圳分公司之間的互相連方式。


  企業(yè)IPPBX具有自己的優(yōu)勢,我們簡單羅列幾個方面的優(yōu)勢:
  • 一根網(wǎng)線解決所有問題。
  • 設(shè)備可以靈活控制,添加。
  • 完全I(xiàn)P化的應(yīng)用場景。
  • 集成語音郵箱,接線員,隊列,振鈴組,電話錄音等等應(yīng)用。
  • 融合通信的其他功能,例如及時消息發(fā)送。
  • 可支持SIP中繼或IMS。
  目前,隨著云計算的普及,企業(yè)通信已經(jīng)實(shí)現(xiàn)了云化,支持的功能更加廣泛。我們在未來的系列講座中會介紹基于云的融合通信的一些特點(diǎn)。
  2、語音編碼和編碼采樣率討論。在以前的文章中,我們已經(jīng)介紹過語音數(shù)模轉(zhuǎn)換的基本原理和相關(guān)的技術(shù),今天,我們再簡單回顧一下數(shù)模轉(zhuǎn)換的簡單過程。在以下的三個圖例說明了模擬信號輸入,通過數(shù)模轉(zhuǎn)換以后,變成網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù),然后到另外一個終端,終端最后再輸出模擬信號,這樣,接聽者就可以聽到對方的語音。




  事實(shí)上,在目前的應(yīng)用場景中,因?yàn)榛ヂ?lián)網(wǎng)技術(shù)的不斷發(fā)展,已經(jīng)發(fā)展出很多其他的編碼,這些編碼能夠更好地為某些特定環(huán)境提供更好的語音質(zhì)量,同時占用更低的帶寬,網(wǎng)絡(luò)適應(yīng)性也很好。為了對語音質(zhì)量做一個判斷,通常情況下,我們使用MOS來作為一個參考值。MOS 5 為最高分,G.711是最理想的編碼。


  關(guān)于高清語音的需求。因?yàn)樵絹碓蕉嗟膽?yīng)用場景,例如劇場,音樂會等環(huán)境更加注重語音質(zhì)量好壞,和以前傳統(tǒng)TDM時代的語音相比,用戶更加希望得到更加清晰的語音。用戶不僅僅要求只是能夠聽到語音,要求語音更加飽滿,更加逼真,發(fā)音時每個單詞的字母都可以聽的非常清楚。運(yùn)營商同樣也需要提供更加優(yōu)質(zhì)的語音質(zhì)量和服務(wù)。以下圖例說明了運(yùn)營商對用戶提供的手機(jī)高清語音服務(wù)的數(shù)據(jù)報告。
  一般電話系統(tǒng)可能感受不到高清語音和普通語音的區(qū)別,用戶可以訪問一些相關(guān)的技術(shù)網(wǎng)站播放語音文件來判別它們之間的不同,包括各種語音編碼的窄帶語音,寬帶語音的不同。




  因?yàn)閃ebRTC的逐漸普及,Opus也是一種非常流行的編碼。它支持了語音呼叫,視頻會議等場景。用戶可以自己下載測試不同bitrate的語音質(zhì)量。我們這里不做過多解釋。
  通過以上的介紹,大家可能都了解了一些基本的概念和相關(guān)的帶寬要求。為了保證合理的語音質(zhì)量,選擇什么樣的編碼是一個比較復(fù)雜的問題。這個問題涉及了公司帶寬,終端支持能力,語音質(zhì)量等因素。筆者建議大家,如果在一般的語音環(huán)境中,為了保證語音質(zhì)量和兼容性的問題,最好選擇G.711編碼。當(dāng)然,如果客戶要求不同,網(wǎng)絡(luò)環(huán)境不同則可能需要用戶自己做出一個合理的選擇來達(dá)到一個平衡。很多公司提供各種編碼占用帶寬的計算公式,大家可以在網(wǎng)上查找,通過準(zhǔn)確地計算來部署自己的帶寬。送大家一句老話,選擇是需要付出成本的。
  編碼打包時長對網(wǎng)絡(luò)帶寬的要求也是不同的。通常情況下,運(yùn)營商或設(shè)備提供商支持兩種打包時長。打包時長的不同也產(chǎn)生了不同的數(shù)據(jù)流量,這樣對路由器處理能力的要求也有所不同。大家可以在下面的圖例中看到,如果調(diào)整了打包時長,無論是G.711編碼還是G.729編碼產(chǎn)生的數(shù)據(jù)流量有明顯的不同。
  3、RTP協(xié)議是一種實(shí)時網(wǎng)絡(luò)傳輸協(xié)議,它支持音頻和視頻的應(yīng)用傳輸。網(wǎng)絡(luò)上有很多關(guān)于RTP的介紹。因?yàn)槠年P(guān)系,我們僅介紹和QoS相關(guān)的部分。RTP可以在單播或多播的應(yīng)用場景,它提供的服務(wù)中可以包含幾種消息:
  • Payload 類型確認(rèn)
  • Sequence Number
  • 時間戳
  • 其他傳輸消息
  這里需要和讀者說明的是,RTP使用中幾個需要注意:
  • RTP不提供任何服務(wù)來實(shí)時保證RTP payload 傳輸。
  • RTP不提供任何QoS服務(wù)。
  • RTP需要依賴其他協(xié)議來保證額外的服務(wù)。
  在前面的討論中,我們討論的大部分的語音或視頻傳輸仍然使用的是UDP傳輸方式,很少有廠家產(chǎn)品完全僅使用TCP傳輸視頻或者語音。如果傳輸視頻的話,因?yàn)門CP的傳輸機(jī)制中,為了保證數(shù)據(jù)傳輸?shù)目煽啃,有時需要大量的重傳數(shù)據(jù),所以很可能會是影響已傳輸?shù)囊曨l數(shù)據(jù)或數(shù)據(jù)損壞。如果是語音的話,用戶可能還能接受,但是視頻圖像的話,這樣可能導(dǎo)致視頻效果不佳的問題。如果是HTTP中涉及了數(shù)據(jù)傳輸?shù)脑,則需要TCP傳輸。
  RTP通過接入的數(shù)據(jù),對數(shù)據(jù)進(jìn)行封裝,然后經(jīng)過Layer 5到Layer1 的層層處理和創(chuàng)新封裝,最后在物理層把數(shù)據(jù)發(fā)送出去。
  我們通過消息體的簡單對照說明來解釋一下RTP中的頭消息內(nèi)容。以下是RTP頭的格式消息體:
  RTP 跟蹤消息的說明:
  這里,我們不做過多的關(guān)于RTP協(xié)議的介紹,如果大家有興趣的話,可以查閱RFC3550來做進(jìn)一步的研究。
  RTCP是對應(yīng)TCP協(xié)議來說的,全稱是實(shí)時傳輸控制協(xié)議,其主要目的就是控制RTP數(shù)據(jù)的傳輸。它主要有五個任務(wù):
  • 提供QoS 檢測數(shù)據(jù)
  • 數(shù)據(jù)包計數(shù)
  • 丟失數(shù)據(jù)包計數(shù)
  • Jitter
  • Round-trip delay time
  • 這里用戶一定要注意,RTP和RTCP的端口是相應(yīng)增加的。
  在RTCP中還有一個RTCP-XR拓展協(xié)議, RTCP-XR協(xié)議定義了一系列關(guān)于定義語音質(zhì)量和語音問題的參數(shù)設(shè)置。RTCP XR 消息中包含了多種關(guān)于語音質(zhì)量的要素指標(biāo):
  • Packet lost, discard rate, distribution of lost 和Discarded packets
  • Round-trip Delay
  • Signal, noise和echo 級別
  • R factor和MoS
  • 設(shè)備配置中的jitter buffer size,設(shè)備的丟包算法等相關(guān)參數(shù)。
  以上各種指標(biāo)包含了大約20多個參數(shù),這些參數(shù)在RFC3611中有非常詳細(xì)的定義和解釋說明,用戶可以查閱RFC做進(jìn)一步的研究。
  本講座其實(shí)是一個以往知識點(diǎn)的回顧。在本講座中,我們介紹了TCP/UDP的使用環(huán)境和一些區(qū)別,重點(diǎn)對TCP支持語音或視頻的問題做了解釋。另外,我們還介紹了企業(yè)IPPBX的應(yīng)用案例,語音編碼中會影響QoS的幾個核心概念,高清語音,還有RTP,RTCP,RTCP XR中對于QoS的管理機(jī)制。以上因素都會影響到QoS的數(shù)據(jù)質(zhì)量。在本講座的基礎(chǔ)上,筆者會在后續(xù)的講座中會逐步探討更多關(guān)于QoS的因素。筆者希望經(jīng)過對整個SIP中QoS的討論為讀者提供一個對語音質(zhì)量的要素有一個比較全面的認(rèn)識。
  關(guān)注公眾號:asterisk-cn獲得有價值的技術(shù)分享,訪問www.issabel.cn/forum 獲得論壇技術(shù)幫助。
  參考資料:
  http://www.voiceage.com/Audio-Samples-Listening-Room.html
  https://www.rfc-editor.org/rfc/rfc3550.pdf
  https://www.ietf.org/rfc/rfc3611.txt
【免責(zé)聲明】本文僅代表作者本人觀點(diǎn),與CTI論壇無關(guān)。CTI論壇對文中陳述、觀點(diǎn)判斷保持中立,不對所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔(dān)全部責(zé)任。

專題