【正文】 音卡必須在停止運行狀態(tài)方可進行配置），選擇“Misc”頁面，找到“FirmwareFile2”項，將其值改為“”。l 看放音識別時的放音文件是否為8k8bit Wave音，放音識別時不支持放其他格式的音。(2) 如果未顯示“對語音卡操作失敗”則，則檢查VP臺進行識別的語法在服務器端是否已加載。如果語法已加載，則檢查語法是否匹配（即語種和網(wǎng)絡類型是否匹配）。3. 現(xiàn)象： ASR識別長時間沒有反應。解決辦法：(1) 對于InfoTalk系統(tǒng)而言，檢查ASR配置文件中“[asrclient]. server_config”項配置的語法分布描述文件，看該文件中描述的語法存放服務器地址配置是否正確，是否可達。(2) 如果配置項中配置的語法分布描述文件正確。此時查看網(wǎng)絡狀況是否良好。TTS/ASR特性系統(tǒng)要求網(wǎng)絡連接必須使用100M Switch Hub。(3) 檢查Infotalk ASR Server是否啟動。4. 現(xiàn)象：VP臺顯示ASR已經(jīng)上報了識別結(jié)果，但上層業(yè)務并不進行下一步后繼操作。解決方法：只要VP臺上報了結(jié)果，上層一定能夠收到，如果沒有下一步后繼操作，請在業(yè)務側(cè)進行檢查，尋找原因。5. 現(xiàn)象：當用聲音方式進行ASR收號時，語法設(shè)置最大收5位，VP臺設(shè)置最大只收4位，測試結(jié)果為可以收號最大位數(shù)為5。解決方法：系統(tǒng)無故障，理解有誤解，語音數(shù)字收號是由語法設(shè)置決定的。6. 現(xiàn)象：操作系統(tǒng)為Windows2000，數(shù)據(jù)配置正確。系統(tǒng)放音正常，但用戶輸入無法識別，而且有語音打斷功能；VoiceIE日志顯示沒有識別出結(jié)果；VP臺顯示語音識別結(jié)果上報：“QueryASRResult NULL!!識別結(jié)果為空!”；ASR編譯服務器沒有“收到語法編譯請求”的顯示；ASR識別服務器顯示“沒有查找到相應的語法數(shù)據(jù)庫記錄”。解決辦法：因為ASR的各個服務器均為DOS終端程序，在Windows2000操作系統(tǒng)中，DOS終端上有選定功能，可以將終端中的內(nèi)容進行選定拷貝，在拷貝完成之前，應用程序處于等待狀態(tài)，不進行運算和處理。當ASR的識別服務器或者編譯服務器處于選定狀態(tài)時，就會出現(xiàn)無法識別或者語法編譯失敗的問題。因此如果在Windows2000環(huán)境下使用ASR系統(tǒng)請注意不要選定運行程序。7. 現(xiàn)象：在撥打業(yè)務流程電話到進行語音識別測試時，發(fā)現(xiàn)語音識別無效。解決步驟：(1) 檢查ASR的服務端、客戶端Nuance版本是否一致以及 ASR Server 端和 VP 臺的配置是否正確：ASR Server端：主要看各個批處理文件，看語法包是否用的是同一個，路徑是否正確，編譯參數(shù)是否正確；VP 臺端：，看語法包是否用的是同一個，各個配置項是否正確。(2) 檢查Dialogic卡的設(shè)置：檢查卡后面的指示燈顯示是否正確，指示燈顯示正常為綠色；檢查Dialogic提供的軟件 DCM 中，Misc配置項中的設(shè)置是否正確；檢查“EC_Resource”最好應該置為“On”，否則會影響識別效果。(3) 懷疑是VP臺中繼線路單通（在保證局間中繼正常的情況下），驗證是否是VP臺中繼線路問題有2個方法：l 軟件測試方法：使用一個VP放音收號流程（注意不能用SPT收號流程），放音正常，收不上號；將使用的那對中繼線上下倒換，再撥打該流程，放不出音來；l 硬件檢查方法：用萬用表分別檢查收和發(fā)2根線是否有短路情況?？梢詳喽ㄊ侵欣^線問題，更換VP臺中繼線，換線之后，進行演示流程測試，識別正常。總結(jié)：在定位環(huán)境問題時，第一步應該是先確認使用的硬件是正常的，否則會耽誤很多時間來定位。所以維護人員在解決問題時，先仔細檢查硬件如線路是否正常。A.附錄A CallLog收集方法及注意事項CallLog是Nuance方的軟件所記錄的日志信息，主要包含每次識別輸入的語音信息及與此次識別相關(guān)的諸如識別采用的動態(tài)語法項、識別耗費的時間等信息。這些日志信息可用于分析整個系統(tǒng)的識別率及識別性能，進而為優(yōu)化系統(tǒng)性能提供依據(jù)。 CallLog收集方法介紹為保證分析的準確一般在進行CallLog收集時需要收集三個方面的數(shù)據(jù)，分別為CallLog、動態(tài)語法文件和動態(tài)語法數(shù)據(jù)庫。下面分別介紹三個方面數(shù)據(jù)的收集方法。CallLog是在識別客戶端記錄的，就是我們的語音臺（VP），缺省情況下VP并不記錄CallLog，因為CallLog記錄產(chǎn)生的數(shù)據(jù)量比較大，讀寫磁盤操作頻繁，會占用一定的系統(tǒng)資源。如果要記錄CallLog，首先需要更改VP的識別配置文件，這個配置文件放在VP的安裝目錄下， [ASR PARAMETER] 中的配置子項CONFIG_FILE的配置信息。缺省情況下。為記錄CallLog，修改后配置情況如下：=timeout,calllog=1=1=huaweivp=d:\vp_calllog ，并且參數(shù)設(shè)置內(nèi)容也要與上面保持一致。，可根據(jù)實際的磁盤空間占用情況來更改配置的路徑。缺省不記CallLog的情況下，配置文件中的參數(shù)配置情況如下：=timeout=0=0。在修改配置文件后，必須重新啟動VP臺程序才能生效。重起VP臺之后，如果該VP臺接收到識別請求，可觀察配置的記錄CallLog文件的路徑下是否生成新的文件夾及文件，一般在指定路徑下會創(chuàng)建一個以年份命名的日志記錄文件夾，如“2002”。建議收集日志大小在900MB到1GB之間，這樣用winzip壓縮之后，在600MB左右，剛好可以刻錄一張光盤。收集完成之后，并重起VP臺，以防止CallLog記錄占用過多磁盤空間。注意，在收集CallLog過程中，必須保證UIScript Server不重起，這樣我們提供的語法文件、動態(tài)語法數(shù)據(jù)庫中的語法ID和CallLog日志記錄中的動態(tài)語法信息才能保證一致，只有這三方信息保持一致，后續(xù)的分析才能更有效。 收集動態(tài)語法文件根據(jù)CallLog進行分析時，還必須提供對應的動態(tài)語法文件，這些語法文件的路徑可從文件服務器的動態(tài)語法路徑中獲得。：[FILE_PATH]……DYNAGRAMMAR_FILE_PATH=X:\grammar可把該路徑下的語法文件打包之后與CallLog刻到同一張光盤上。 收集動態(tài)語法數(shù)據(jù)庫后續(xù)分析還需要動態(tài)語法數(shù)據(jù)庫中的信息，該信息有以下兩種方式可以獲得：1. 通過數(shù)據(jù)庫備份工具，將數(shù)據(jù)庫備份。使用這種方法的優(yōu)點是備份數(shù)據(jù)庫的操作簡單，但分析人員進行分析時還必須安裝數(shù)據(jù)庫并將備份文件進行恢復。2. 把動態(tài)語法數(shù)據(jù)庫中數(shù)據(jù)導入一個文件形式的數(shù)據(jù)庫中，之后打包整個文件數(shù)據(jù)庫目錄。這種方法的好處是不需要分析人員去安裝數(shù)據(jù)庫，也省去了恢復備份的過程。采用第二種方式備份數(shù)據(jù)庫信息首先要另建一個文件數(shù)據(jù)庫，建立這種類型的數(shù)據(jù)庫需要用到Nuance提供的一個命令行工具： nuancedatabaseadmin。執(zhí)行這個命令之前，需先為這個文件數(shù)據(jù)庫建立一個目錄，如e:\dgdbfs 。之后執(zhí)行以下命令行（機器必須安裝有Nuance軟件）：nuancedatabaseadmin dbinteractivedatabase operation:createdatabase provider:fsdatabase root:e:\dgdbfsdatabase class:dgdbdatabase name:aipvpfs （創(chuàng)建的文件數(shù)據(jù)庫名稱）操作成功后會提示 Succesfully create database.查看e:\dgdbfs目錄，會發(fā)現(xiàn)該目錄下已生成名為dgdbaipvpfs這樣一個目錄，也即創(chuàng)建好的文件數(shù)據(jù)庫。假設(shè)我們已使用的動態(tài)語法數(shù)據(jù)庫中語法相關(guān)的三張表的名字為“dgdb_bin_dbtoaipvp”“dgdb_src_dbtoaipvp”“dgdb_timestamp_dbtoaipvp”，并且本機的ODBC數(shù)據(jù)源中已創(chuàng)建好一個名為aipvp的指向保存這三張表的數(shù)據(jù)庫（如果沒有，必需增加該數(shù)據(jù)源），則在命令行執(zhí)行以下命令，實現(xiàn)動態(tài)語法信息從SQL數(shù)據(jù)庫向文件數(shù)據(jù)庫的備份：nuancedatabaseadmin dbinteractivedatabase operation:copysource database provider:odbcsource database server:aipvp (odbc數(shù)據(jù)源名)source database class:dgdbsource database name:dbtoaipvp （輸入SQL數(shù)據(jù)庫中三張表名的最后一個字符串）source uname:pwd [hit RET to use default nuance:nuance]: (直接回車不用輸入)source data format [hit RET to use default longraw]:imagesource custom provider string [hit RET to use default none]: (直接回車不用輸入)destination database provider:fsdestination database root:e:\dgdbfsdestination database class:dgdbdestination database name:aipvpfs之后就會顯示拷貝的動態(tài)語法信息：DG1010001……DG1030071Total of 515 records copied至此，完成了動態(tài)語法數(shù)據(jù)庫信息從SQL數(shù)據(jù)庫向文件數(shù)據(jù)庫的備份。壓縮打包整個“e:\dgdbfs”目錄，就可以把壓縮包與CallLog和動態(tài)語法文件一起提供給分析人員。如果重起了UIScript Server，再收集CallLog，則需要重復上述備份動態(tài)語法數(shù)據(jù)庫和動態(tài)語法文件的過程，保證三者的一致性。 CallLog日志收集注意事項為方便CallLog日志的收集，提供以下注意事項供參考：(1) 總共需要收集三部分內(nèi)容，即CallLog、動態(tài)語法文件及動態(tài)語法數(shù)據(jù)庫。在收集過程中注意保持三者的一致性，不要重新啟動UIScript。(2) 在某個固定的VP臺上（如VP6）進行收集CallLog的操作，這樣可便于管理，還可以避免忘記關(guān)日志造成硬盤空間不夠的問題。(3) 在CallLog收集之前及收集完成并壓縮以后，注意將CallLog所在的目錄清空，以免磁盤空間不夠影響系統(tǒng)正常運行。(4) 為避免頻繁修改配置文件，。收集完后關(guān)閉VP臺，并將該臨時文件夾刪除，不再收集CallLog。(5) 動態(tài)語法數(shù)據(jù)庫的收集建議采用第二種方法。