首頁(yè)>>廠(chǎng)商>>IVR系統平臺廠(chǎng)商>>Voxeo

Voxeo平臺構建VoiceXML驅動(dòng)的SIP會(huì )議系統

2008/12/02

1. Alice撥打瀏覽器的電話(huà)號碼(212-9397137)或SIP URI (sip:7137@server.com)。


2. 瀏覽器接受呼叫，提示主叫方輸入PIN標識。


3. Alice鍵入她的PIN號碼1-2-3-4，后面跟著(zhù)一個(gè)終結鍵“#”。DTMF數字在RTP中發(fā)送。


4. 瀏覽器查詢(xún)數據庫，把主叫方標識為Alice。


5. 基于使用權限，瀏覽器向她提示一個(gè)會(huì )議列表供她選擇。


6. Alice選擇標識符為23的會(huì )議。


7. 瀏覽器再次核對Alice是否允許加入標識為23的會(huì )議，在本例中是sip:staffmeet@conference.com。


8. 一旦認證完成，瀏覽器將使用SIP REFER方法把呼叫轉移給實(shí)際的會(huì )議服務(wù)器，該方法攜帶了會(huì )議SIP URI。


9. Alice的電話(huà)接受轉移，并向會(huì )議服務(wù)器發(fā)起一個(gè)新的呼叫。


10. Alice的電話(huà)與會(huì )議服務(wù)器直接交換音頻，不必再經(jīng)過(guò)瀏覽器。

圖1. 方法一：在盲目轉移模式中加入會(huì )議

　　注意：用戶(hù)認證、會(huì )議查詢(xún)和轉移實(shí)際上由會(huì )議服務(wù)器CGI腳本調用，而瀏覽器只是解釋腳本生成的VoiceXML頁(yè)面來(lái)完成實(shí)際的轉移或提示主叫方。例如，業(yè)務(wù)腳本可能在第(9)步為呼叫轉移生成以下轉移標簽：

　　<block><prompt>Your call is being transferred,
　　please wait.</prompt></block>
　　<transfer dest="sip:staffmeet@conference.com" bridge="false" />

　　轉移有兩種模式：盲目轉移和橋接轉移。前者是不查閱服務(wù)器的呼叫轉移，而后者是查閱后轉移，從而瀏覽器可以選擇進(jìn)入媒體路徑。

圖2. 方法二：使用橋接模式加入會(huì )議

　　圖2顯示了橋接轉移情形，其中瀏覽器作為一個(gè)“背靠背用戶(hù)代理”在用戶(hù)電話(huà)和會(huì )議服務(wù)器之間橋接音頻路徑。步驟1～7與盲目轉移情形相同，所不同的是，瀏覽器并非發(fā)送REFER，而是向會(huì )議服務(wù)器發(fā)送一個(gè)新的呼叫請求，在SIP INVITE消息的Request-URI中標識會(huì )議sip:staffmeet@conference.com。瀏覽器為雙向RTP/RTCP媒體流量充當了應用級包轉發(fā)器。

　　橋接轉移的優(yōu)點(diǎn)在于，瀏覽器逗留在媒體路徑中，可以接受隨后來(lái)自用戶(hù)電話(huà)(使用DTMF)的控制命令。對于會(huì )議來(lái)說(shuō)，這一點(diǎn)可能是有用的，例如將DTMF 6-6-#解釋為關(guān)閉你的音頻或者6-8-#表示加入另一個(gè)虛擬聊天或會(huì )議室。其次，瀏覽器也需要給會(huì )議服務(wù)器轉發(fā)其它的信令消息，例如來(lái)自主叫方的re-INVITE。而且，維持會(huì )議期間的數據包轉發(fā)狀態(tài)在可以同時(shí)處理的主叫數目方面限制了瀏覽器的可擴展性。瀏覽器可以向主叫方和會(huì )議服務(wù)器發(fā)布帶更新的RTP/RTCP傳輸地址的re-INVITE，以便媒體路徑是直接的。但是，這依然需要維持呼叫期間的信令狀態(tài)。另一方面，盲目轉移在會(huì )議期間無(wú)須瀏覽器的任何呼叫狀態(tài)，不過(guò)它期望主叫IP電話(huà)支持REFER方法。

三、安全性

　　每一個(gè)因特網(wǎng)應用都應該處理安全性。我們的體系結構有三個(gè)方面需要考慮安全性：電話(huà)網(wǎng)關(guān)、SIP信令與RTP媒體傳輸和對后臺服務(wù)器的HTTP/RTSP訪(fǎng)問(wèn)。

　　在橋接轉移情形，VoiceXML瀏覽器使用PIN認證主叫方，并在SIP認證中提供自己的機密信息給會(huì )議服務(wù)器。而在盲目轉移情形，如果主叫方使用通過(guò)網(wǎng)關(guān)連接的傳統電話(huà)，那么SIP認證將包含網(wǎng)關(guān)的機密信息。為了防止惡意用戶(hù)連接到受限會(huì )議，我們在REFER消息中把機密信息從瀏覽器傳遞給主叫方網(wǎng)關(guān)，隨即用于主叫方網(wǎng)關(guān)呼叫會(huì )議服務(wù)器。機密信息可以是瀏覽器或主叫方的。例如，Refer-To頭可能包含sip:staffmeet-@conference.com，這里是base-64編碼的，hash是browser-host:timestamp:shared-secret的MD5哈希值。這種方案只在會(huì )議服務(wù)器能解釋該URI時(shí)起作用。如果時(shí)間戳老化了，服務(wù)器應該拒絕呼叫，以防重播攻擊。

　　瀏覽器應該使用HTTP POST方法，而不是GET方法，以避免在Web服務(wù)器日志中保存CGI輸入。

四、功能擴充

　　除了安全性，我們還可以對會(huì )議系統進(jìn)行功能擴充，比如控制會(huì )議音量和增強系統魯棒性。

　　不同聲音設備的異構客戶(hù)機之間的多方音頻會(huì )議常常導致惱人的音頻失真，一些參與者聽(tīng)起來(lái)太大聲，而另一些可能根本聽(tīng)不見(jiàn)。理想狀態(tài)下，會(huì )議服務(wù)器應該在混音前平衡來(lái)自所有參與者的輸入音量，但是這將在服務(wù)器上為每一個(gè)音頻數據包帶來(lái)額外處理要求。另一個(gè)辦法是告訴參與者調整他的麥克風(fēng)和揚聲器的音量。參與者在加入會(huì )議之前連接到一個(gè)“音量反饋”的系統，并且對它說(shuō)話(huà)。該系統宣布用戶(hù)的麥克風(fēng)音量是可接受、太高或太低。它也播放一個(gè)預先錄制好的音頻文件，允許用戶(hù)調整其揚聲器音量。這個(gè)處理過(guò)程由一個(gè)服務(wù)器側腳本建立，VoiceXML瀏覽器可以訪(fǎng)問(wèn)它。

　　在過(guò)去幾年，開(kāi)發(fā)人員已經(jīng)日益使用CCXML給他們的電話(huà)系統增加強健的呼叫控制特性。圖3展示了如何在VoiceXML與SIP環(huán)境中運用CCXML平臺進(jìn)行高級會(huì )議控制[4]。在這里CCXML作為SIP的“背靠背用戶(hù)代理”，面向呼叫者和網(wǎng)絡(luò )資源(比如VoiceXML瀏覽器和會(huì )議混合器)執行基于SIP的呼叫控制職能，可以基于開(kāi)放式的行業(yè)標準方式創(chuàng )建健壯可靠的多方會(huì )議系統。Voxeo Prophecy 8.0是一個(gè)強大的完全基于標準的IVR和SIP VoIP應用平臺，它捆綁了業(yè)界第一個(gè)(也是目前唯一的) 100% 通過(guò)VoiceXML官方規定的全部兼容性測試(全部強制性和可選功能)的VoiceXML瀏覽器和世界上目前最完整CCXML實(shí)現，同時(shí)它還與任意網(wǎng)絡(luò )開(kāi)發(fā)語(yǔ)言(包括ASP, CGI, C#, Java,PERL, PHP, Python 和 Ruby)或服務(wù)器兼容，給VoIP語(yǔ)音應用開(kāi)發(fā)與部署人員提供了有力的工具和平臺。

圖3. CCXML SIP體系結構

五、小結

　　本文講述了SIP會(huì )議系統的兩種轉移模式，以及體系安全性的一些考慮，最后簡(jiǎn)單介紹了可以采用VoiceXML服務(wù)器側編程邏輯和CCXML腳本來(lái)擴充會(huì )議服務(wù)器的功能，并推薦了一款完全基于標準的開(kāi)發(fā)工具和平臺――Voxeo Prophecy 8.0。

參考資料：

　　[1] VoiceXML 2.1: http://www.w3.org/TR/voicexml21/
　　[2] SIP: Session Initiation Protocol: http://www.ietf.org/rfc/rfc3261.txt
　　[3] CCXML 1.0: http://www.w3.org/TR/ccxml/
　　[4] Using Call Control XML (CCXML) as a SIP Softswitch: http://www.voicexml
.org/Review/Apr2005/features/softswitch.html

CTI論壇編輯