首頁>>廠商>>IVR系統(tǒng)平臺廠商>>Voxeo

Voxeo平臺構建VoiceXML驅動的SIP會議系統(tǒng)

2008/12/02

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


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


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


4. 瀏覽器查詢數(shù)據(jù)庫，把主叫方標識為Alice。


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


6. Alice選擇標識符為23的會議。


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


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


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


10. Alice的電話與會議服務器直接交換音頻，不必再經過瀏覽器。

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

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

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

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

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

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

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

三、安全性

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

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

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

四、功能擴充

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

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

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

圖3. CCXML SIP體系結構

五、小結

　　本文講述了SIP會議系統(tǒng)的兩種轉移模式，以及體系安全性的一些考慮，最后簡單介紹了可以采用VoiceXML服務器側編程邏輯和CCXML腳本來擴充會議服務器的功能，并推薦了一款完全基于標準的開發(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論壇編輯