CTI論壇（ctiforum）（編譯/鄧旭）： WebRTC與呼叫中心：就像巧克力和花生醬一樣，二者加起來(lái)總是比其中之一香甜。
WebRTC（一種網(wǎng)絡(luò )技術(shù)，擴大了網(wǎng)絡(luò )瀏覽器的本地功能，可以實(shí)現語(yǔ)音、視頻和數據共享，而且無(wú)需單獨的客戶(hù)端或插入軟件）最近正在引起人們的高度重視。在IETF和W3C標準化過(guò)程中，這一技術(shù)的領(lǐng)先地位大部分來(lái)自于谷歌的開(kāi)發(fā)團隊，他們將這種技術(shù)看作是革命性的通信技術(shù)。創(chuàng )新的網(wǎng)絡(luò )應用程序包括協(xié)作系統（比如谷歌公司的Hangouts）、遠程學(xué)習、游戲等等。
呼叫中心可能是WebRTC技術(shù)的最大受益者。WebRTC最初為網(wǎng)絡(luò )用戶(hù)提供點(diǎn)擊通話(huà)功能，這種技術(shù)將給幾乎每一臺PC機、平板電腦和手機帶來(lái)零安裝體驗，用戶(hù)可以很方便的提問(wèn)題、獲得支持或者與呼叫中心互動(dòng)。
這種技術(shù)不是現有呼叫中心的替代品，人們普遍認為，WebRTC將是呼叫中心領(lǐng)域的一場(chǎng)重大變革--給現有呼叫中心業(yè)務(wù)增加新的能力，網(wǎng)民可以使用瀏覽器打電話(huà)，而且遵循如今的來(lái)電者所采用的相同的呼叫程序/隊列。 這一技術(shù)可以使座席人員能夠互換地接聽(tīng)來(lái)自網(wǎng)絡(luò )或PSTN的來(lái)電--這對于呼叫中心經(jīng)理而言再好不過(guò)了。
但是，這一圖景也存在一些技術(shù)障礙。 一個(gè)迫在眉睫的難題就是解碼編碼器支持。由于許多非常切實(shí)的網(wǎng)絡(luò )性能原因，WebRTC將Opus高清解碼編碼器定義為互聯(lián)網(wǎng)上語(yǔ)音傳輸途徑。 憑借增強的數據包損失隱藏、糾錯和卓越的語(yǔ)音質(zhì)量，Opus從設計之初就專(zhuān)門(mén)用于處理常見(jiàn)的網(wǎng)絡(luò )錯誤，也就是在開(kāi)放互聯(lián)網(wǎng)上通信時(shí)發(fā)生的錯誤。
Opus編碼器 是一個(gè)有損聲音編碼的格式，由互聯(lián)網(wǎng)工程任務(wù)組（IETF）進(jìn)來(lái)開(kāi)發(fā)，適用于網(wǎng)絡(luò )上的實(shí)時(shí)聲音傳輸，標準格式為RFC 6716。Opus 格式是一個(gè)開(kāi)放格式，使用上沒(méi)有任何專(zhuān)利或限制。
那么，呼叫中心講如何支持Opus？
有許多廣為人知的方法將WebRTC和Opus添加到呼叫中心。
會(huì )話(huà)邊界控制器、網(wǎng)關(guān)和轉碼--第一種方法是采用基于WebRTC的會(huì )話(huà)邊界控制器來(lái)結束來(lái)自網(wǎng)絡(luò )的會(huì )話(huà)和媒體流，將會(huì )話(huà)轉碼為一種當前呼叫中心能夠處理的格式（通常是G.711）。這種方法被認為是干擾性最小的方法，足以滿(mǎn)足某些應用程序的需要，或者作為臨時(shí)的過(guò)渡技術(shù)，但是轉碼不能靈活擴展，而且給網(wǎng)絡(luò )來(lái)電增加了等待時(shí)間，這會(huì )降低客戶(hù)滿(mǎn)意度。
Opus端到端--第二種方法，同時(shí)也是更受歡迎的方法，就是將Opus解碼編碼器的使用一直擴展到座席人員，使得終端設備能夠同時(shí)支持來(lái)自PSTN的G.711來(lái)電，以及來(lái)自網(wǎng)絡(luò )呼叫者的Opus。這種方法比轉碼的效率高很多，座席人員對Opus的支持實(shí)現了高清通話(huà)，提升了用戶(hù)體驗和滿(mǎn)意度。
因為任何兩個(gè)呼叫中心之間總是存在差異，而且現有投資將決定著(zhù)大多數決策，所以AudioCodes的策略是支持兩種方法--首先利用我們的呼叫中心400HD IP電話(huà)來(lái)支持Opus。 此外，AudioCodes還計劃在會(huì )話(huà)邊界控制器產(chǎn)品中支持Opus，在適當的時(shí)候促進(jìn)轉碼。
有了這些重要的技術(shù)之后，我們認為WebRTC和呼叫中心是天生的一對--就像巧克力和花生醬一樣，二者的結合肯定比其中任何一者更香甜。
聲明：版權所有 非合作媒體謝絕轉載
