欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

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

MRCP學習筆記-語音識別資源的事件和headers詳解

2018-07-23 16:24:06   作者:   來源:CTI論壇   評論:0  點擊:


  在上一節(jié)的分享中,我們介紹了語音識別資源的六個標準的methods和五個語音注冊的methods。今天,我們繼續(xù)介紹語音識別資源中的三個事件,三十三個headers和十二個語音注冊的headers。
  1、在語音識別資源中,MRCP支持了三種事件,它們分別是START-OF-INPUT,RECOGNITION-COMPLETE和INTERPRETATION-COMPLETE。
  START-OF-INPUT事件是由語音識別資源側(cè)回復的事件消息,它通知MRCP客戶端資源服務器已經(jīng)收到了語音輸入或DTMF輸入。具體的輸入數(shù)據(jù)類型通過消息體中的Input-Type來表示。大部分情況下,此事件用來支持MRCP客戶端檢測打斷或停止語音回放。這里讀者要注意,語音識別資源不會對熱詞識別模式生成此事件。具體的事件使用場景在上一講做已經(jīng)介紹,讀者可以查閱歷史文檔來進一步學習。
  RECOGNITION-COMPLETE是語音識別資源生成的事件消息,它用來對MRCP客戶端說明,識別處理已經(jīng)完成,并且通過消息體傳輸了識別結(jié)果。事件消息體中的Completion-Cause和可選的Completion-Reason頭用來表示完成識別的狀態(tài)。在前面的章節(jié)中,我們提供了完整的識別流程消息說明,用戶可以查閱。這里,我們僅簡單列出一個RECOGNITION-COMPLETE示例(服務器端->客戶端):
  
  這里,如果是成功的識別流程,返回的識別結(jié)果通過語音文件格式。
  INTERPRETATION-COMPLETE和前面提到的RECOGNITION-COMPLETE類似,但是它表示的是解析過程完成(不是識別過程),并且傳輸了解析結(jié)果。我們在上一講中也提供了完整的示例流程,讀者可以查閱。這里,我們提供一個響應部分的具體的示例如下(服務器端->客戶端):
  2、現(xiàn)在,我們開始介紹語音識別資源的headers。因為篇幅比較長,筆者盡可能對每個header做出解釋,如果有不詳細的地方,建議讀者查看RFC標準,F(xiàn)在,我們介紹第一個header,也是RECOGNITION-COMPLETE事件消息中總是出現(xiàn)的header-Completion-Cause。因為,此頭涉及了失敗原因碼的完整詳解,所以,筆者專門把此header單獨拿出來做完整的介紹。它用來表示完成的具體原因,如果識別失敗的話,它會支持相關的識別原因碼。注意,Completion-Cause也會出現(xiàn)在DEFINE-GRAMMAR的請求的對應響應消息中,它會說明請求中訪問結(jié)果或編譯的語法結(jié)果。具體的細節(jié)請看如下示例圖(原因碼,原因名稱和具體解釋):
  具體的語法示例:Completion-Cause: 001 no-match
  3、剛才,筆者介紹了事件消息中的第一大“頭”-Completion-Cause,F(xiàn)在我們列出其余的headers和具體的示例說明。
  • Completion-Reason,它是可選的header,出現(xiàn)在Completion-Cause中,說明請求結(jié)束的原因,可用來支持客戶端的日志消息。具體的示例如:Completion-Reason:Recursive grammars not supported。
  • Failed-URI,此頭用來表示攜帶的URL資源訪問失敗。示例:Failed-URI:http://192.168.1.1/numbers.grxml。
  • Failed-URI-Cause,此頭配合Failed-URI使用,表示失敗碼。例如:Failed-URI-Cause:404 Not Found。
  • Recognition-Mode,此header用來表示識別的模式類型,可支持normal或hotword模式。我們已經(jīng)在前面的章節(jié)中介紹過這兩種識別類型,這里不再介紹。示例如:Recognition-Mode:hotword。
  • Input-Type,此header會出現(xiàn)在START-OF-INPUT的事件中,它用來表示檢測到的輸入類型(DTMF或speech),其示例:Input-Type:speech。
  • Confidence-Threshold,此header用來設置一個安全閥值,設置最低的識別級別保證識別的成功率。如果識別結(jié)果攜帶的安全級別低于安全閥值,則返回一個Completion-Cause header,錯誤碼為001 no-match。其取值范圍在0.0–1.0之間。示例:Confidence-Threshold:0.5。
  • Sensitivity-Level,此header用來語音識別檢測的敏感度水平,對其背景噪音進行過濾。敏感度比較低的話,則說明對其語音畢竟噪音不太敏感。此header通常是在per-RECOGNIZE請求設置。示例:Sensitivity-Level:0.65。
  • Speech-Vs-Accuracy,此header用來控制對性能和準確率的調(diào)整設置,其取值范圍從0.0-1.0之間。取值越高,說明要求的準確性越高,但是消耗更多的CPU資源。此header通過per-RECOGNIZE 請求來進行設定。示例:
  • Speed-Vs-Accuracy:0.35。
  • N-Best-List-Length,此header表示MRCP客戶端可以接收多個語音識別資源返回的識別結(jié)果,最大可以支持N個返回的可選識別結(jié)果。這里讀者要注意,不同的返回結(jié)果支持不同的語法路徑,只有安全級別大于安全閥值的才會返回到客戶端。語音設備資源可以返回低于N的結(jié)果,如果返回比較大的數(shù)值N的話,需要語音識別資源增加其處理能力。這也非常容易理解的,它的取值會影響語音識別資源的性能。此header通過per-RECOGNIZE請求設置,默認(最小值)為1。示例:N-Best-List-Length:5。
  • No-Input-Timeout,此header是一個定時器,它用來檢測在一定時間內(nèi),識別流程開始以后,系統(tǒng)沒有檢測到用戶的語音輸入或DTMF。如果No-Input-Timeout超時,語音識別資源會生成一個RECOGNITION-COMPLETE事件,攜帶Completion-Cause,其值為:002 no-input-timeout。其時間取值以毫秒為單位,示例:No-Input-Timeout:3000。
  • Recognition-Timeout,此定時器是用來限定整個識別處理時間。其header也可用來防止背景噪音占用了語音識別資源而導致的識別時間延長。這里要注意,在兩種識別模式下,返回的錯誤碼有所區(qū)別,讀者可以查閱RFC來做進一步的研究。默認設置為10秒,以毫秒為單位,示例:Recognition-Timeout:7000。
  • Speech-Complete-Timeout,此header用來表示說話人已經(jīng)停止說話,語音識別資源成功返回結(jié)果之間所必須消耗的時間。當然,如果此設置太短,則可能導致語句被打斷;如果太長則會導致系統(tǒng)響應變慢。其取值以毫秒為單位,取值范圍從300到1000毫秒之間。示例:Speech-Complete-Timeout:500。
  • Speech-Incomplete-Timeout,此header和上面的Speech-Complete-Timeout的使用方式非常類似,但是它使用的場景有所不同。有的情況下,語音之前的靜音或不正確的語法前綴無法全部匹配活動的語法。如果觸發(fā)了此定時器的話,語音識別資源會生成一個RECOGNITION-RESULT 事件,此事件攜帶Completion-Cause,語言碼設定的值為013 partial-match(部分匹配)。此header也可以使用在另外一種場景中,有可能說話人語音郵件成功匹配了語音識別資源,但是說話人可能呼吸停頓,想繼續(xù)說的時候,仍然需要匹配相應的語音識別資源。通常情況下,此定時器設置的時長會大于Speech-Complete-Timeout的時長,這樣,可以支持說話人短暫的停頓。此取值以毫秒為單位,取值范圍從0到最大值。示例:Speech-Incomplete-Timeout:1000。
  • Hotword-Max-Duration,此header只能使用在hotword的模式下,用來限定需要識別的語句最大長度。此header配合Hotword-Min-Duration來使用,防止識別的語句過長或過短。示例:Hotword-Max-Duration:5000。
  • Hotword-Min-Duration,此header只能使用在hotword的模式下,用來限定需要識別的語句最小長度。此header配合Hotword-Max-Duration來使用,防止識別的語句過長或過短。示例:Hotword-Min-Duration:5000。
  • DTMF-Interdigit-Timeout,此header用來設定在語音識別生成結(jié)果之前,DTMF按鍵輸入之間的時間間隔。此header可能出現(xiàn)在RECOGNIZE,SET-PARAMS,或GET-PARAMS。它以毫秒為單位,默認是5000毫秒,示例:DTMF-Interdigit-Timeout:3000。
  • DTMF-Term-Timeout,此header和以上header類似,但是它應用的場景是成功匹配語法以后,仍然需要進一步的DTMF輸入流程。它用來支持長數(shù)字序列的輸入和進一步的輸入驗證的場景中。示例:DTMF-Term-Timeout:2000。
  • DTMF-Term-Char,此header用來設定某個特定字符來結(jié)束DTMF輸入。例如,大家經(jīng)常使用的“#”。我們按#來表示我們的DTMF結(jié)果輸入完成。示例:DTMF-Term-Char:#。
  • DTMF-Buffer-Time,此header用來表示表示DTMF類型的大小,通過緩沖的方式保存。語音識別資源可以支持在RECOGNIZE請求之間的DTMF按鍵,并且通過緩沖來保存。當發(fā)起新的RECOGNIZE請求時,首先使用緩沖中的數(shù)據(jù)內(nèi)容進行匹配識別,如果緩沖中的數(shù)據(jù)不能完全支持識別資源時,用戶則需要輸入更多的數(shù)字按鍵來匹配活動的語法。這里讀者要注意,因為平臺的不同,可能此header的設置也不同。示例:DTMF-Buffer-Time:10000。
  • Clear-DTMF-Buffer,此header用來清理緩沖中的DTMF數(shù)據(jù)。它通過RECOGNIZE請求來設置。默認設置為false。如果設置為true表示清理緩沖。示例:Clear-DTMF-Buffer:true。
  • Save-Waveform:此header用來表示是否保存識別的語音文件。如果保存,則此值設置為true,捕獲的語音流通過RECOGNITION-COMPLETE事件的Waveform-URI表示。MRCP客戶端可通過此URL獲取到從語音文件。默認值是false,示例:Save-Waveform:true。
  • Waveform-URI,此header用來支持MRCP客戶端通過此header的URL獲取或訪問語音文件。此heade同時支持了size(以bytes為單位)和duration(毫秒)的取值。其示例是:Waveform-URI:;size=8000;duration=1000。
  • Input-Waveform-URI,此header用來為RECOGNITION提供一個語音文件而不是使用媒體會話來提供語音文件。此功能的目的是執(zhí)行一個重新識別的流程,使用不同的語法和和以前捕捉的語音進行對比來測試語法的覆蓋范圍。其示例:Input-Waveform-URI:http://10.0.0.1/utt01.wav。
  • Media-Type,此header表示語音文件支持的媒體類型。其示例:Media-Type:audio/x-wav。
  • Start-Input-Timers,此header會出現(xiàn)在RECOGNIZE請求中,通知語音識別引擎是否啟動No-Input-Timeout定時器。默認值為true。示例是:Start-Input-Timers:false。
  • Speech-Language,此header表示語音識別默認支持的語法語言。其示例:Speech-Language:de-CH。
  • Cancel-If-Queue,此header用來表示多個RECOGNIZE請求是有隊列支持。如果此值為true,則表示沒有使用隊列,IN-PROGRESSRECOGNIZE請求已被取消。已取消的識別請求會帶一個RECOGNITION-COMPLETE事件,這個事件的消息體的header帶Completion-Cause,設置的值為011 cancelled。如果是false,則表示RECOGNIZE請求會加入到隊列中。此header沒有默認值,示例為:Cancel-If-Queue:true。
  • New-Audio-Channel,此header通過RECOGNIZE來設定,如果是true,則表示對語音資源來說,從此刻開始,從一個新的通道中收到了語音流。通常情況下,語音識別資源會解析為一個新的請求,重新設置終端的算法,因此會丟棄任何已執(zhí)行的通道。此功能非常有用,它可使用已存在的會話重用在一個新的電話呼叫的環(huán)境中。默認值為false,示例為:New-Audio-Channel:true。
  • Ver-Buffer-Utterance,此header可以通過RECOGNIZE請求中設置,如果設置為true,則表示語音識別資源可以使用緩沖中的可用的語音數(shù)據(jù),此語音數(shù)據(jù)可用于后期說話人驗證引擎環(huán)境。當然,這里一定要注意,說話人驗證資源一定要和識別請求共享一個會話。其示例是:Ver-Buffer-Utterance:true。
  • Early-No-Match,此header用來表示語音識別引擎是否執(zhí)行語法的早期匹配。它可以無需等待終端提示完成語音輸入然后開始識別的流程。語音識別引擎如果不支持早期匹配的話,可能會忽略此header值。默認值是false。其語法示例為:Early-No-Match:true。
  • Interpret-Text,此header用來支持INTERPRET請求,指示需要解析的文本。INTERPRET請求中攜帶了text/plain消息。其示例為:Interpret-Text:text@example.com。
  • Recognizer-Context-Block,此header用來通過GET-PARAMS取值或通過SET-PARAMS來設置語音識別的內(nèi)容數(shù)據(jù)段。每個識別引擎平臺的內(nèi)容數(shù)據(jù)段都是完全不同的,包括了會話,終端設置等相關數(shù)據(jù)。其示例為:Recognizer-Context-Block:data@vendor-x.com。
  4、語音注冊的headers包括了十二個headers。
  Enroll-Utterance用來表示短語是否被注冊,是通過RECOGNIZE請求中設定。如果RECOGNIZE請求中設置了Enroll-Utterance為true的話,它僅能支持注冊會話。其示例為:Enroll-Utterance:true。
  • Num-Min-Consistent-Pronunciations,此header表示從用戶側(cè)獲得的最少連續(xù)的發(fā)音短語。此短語會成為注冊的短語,最后接納為個人的語法。此header可以通過per-START-PHRASE-ENROLLMENT請求或SET-PARAMS來設置,其示例為:Num-Min-Consistent-Pronunciations:1。
  • Consistency-Threshold,此header應用在語法注冊的過程中,用來表示前面注冊短語的發(fā)音和當前短語的相似性。此值越高,說明介于其句子和短語發(fā)音匹配非常接近。其語法示例為:Consistency-Threshold:0.75。
  • Clash-Threshold,此header用來衡量語句短語和當前個人語法中的短語的相似度或接近程度。例如:兩個不同的拼寫但是它們的發(fā)音困難非常相似:
  “John Smith”和“Jon Smits”。這樣就會導致識別資源發(fā)現(xiàn)他們的不同。較小的取值會降低已檢測到的差異的數(shù)量。取值范圍從0到1,其語法示例:Consistency-Threshold:0.75 。
  • Personal-Grammar-URI,其header表示此URL是一個個人的語法。它會出現(xiàn)在START-PHRASE-ENROLLMENT,MODIFY-PHRASE,或DELETE-PHRASE的請求中。其語法示例為:Personal-Grammar-URI:http://example.com/enroll/user1.dat。
  • Phrase-ID,此header表示的一個短語ID確認消息。在START-PHRASE-ENROLLMENT,MODIFY-PHRASE或者DELETE-PHRASE的請求中使用,表明其特別的ID號,對此ID進行相應的處理。其語法示例為:Phrase-ID:name_joe_bloggs。
  • New-Phrase-ID,此header應用在MODIFY-PHRASE請求中,用來表示對目前存在的ID聲明一個新的短語ID。其語法示例為:New-Phrase-ID:name_joe_bloggs_02。
  • Phrase-NL,此header用來表示注冊語法相應的自然語言或語義解析。當短語識別以后,返回的解析文本結(jié)果。其語法示例為:Phrase-NL:item01。
  • Weight,此header表示一個短語發(fā)生的似然程度。從概念上來說,這個權重值和SRGS語法中的item屬性weight類似。此header可能出現(xiàn)在START-PHRASE-ENROLLMENT請求中來設定一個注冊語法的權重,也可能出現(xiàn)在MODIFY-PHRASE的請求中來修改權重值。其語法示例為:Weight:2.0。
  • Save-Best-Waveform,此header設置為true的話,用來支持客戶端要求語音識別資源在注冊會話的生命周期內(nèi)保存捕捉的語音數(shù)據(jù),此數(shù)據(jù)是最佳的重復短語。語音識別資源必須對識別語音進行錄制,并且通過URL來返回到客戶端,在END-PHRASE-ENROLLMENT中攜帶一個Waveform-URI表示語音URL路徑。如果沒有錄制成功或發(fā)送錯誤的話,語音識別資源必須返回一個空的URL。
  • Confusable-Phrases-URI,此header會出現(xiàn)在RECOGNIZE的請求中用來表示一個語法URL,這個URL中的短語可能沒有注冊或無效的短語。無法注冊的短語也可能是一個命令短語,所以不能注冊。其語法示例為:Confusable-Phrase-URI:file://c:\data\commands.dat。
  • Abort-Phrase-Enrollment,此header會出現(xiàn)在END-PHRASE-ENROLLMENT的請求中。如果其值設置為true,則表示語音識別資源會終止正在被注冊的短語。其語法示例為:Abort-Phrase-Enrollment:true。
  5、在今天的分享中,我們完整地介紹了語音識別資源中的三個事件,三十三個headers和十二個語音注冊的headers。針對每一個header,筆者給出了具體的解釋,使用注意事項和一些必要的語法示例。筆者相信,筆者的解釋也可能出現(xiàn)偏差,雖然完全覆蓋了語音識別資源的所有headers,但這些分享也不一定完全能夠滿足讀者學習的需要,讀者仍然需要在使用過程中不斷測試加深對這些header的學習。到此為止,筆者已經(jīng)完整介紹了語音識別資源所有相關的methods,事件和headers。
  



  unimrcp-MRCP協(xié)議學習分享,QQ群號:208136295
  關注微信公眾號:asterisk-cn,獲得有價值的行業(yè)分享
  freepbx 技術論壇:www.ippbx.org.cn
  Asterisk, freepbx技術文檔: www.freepbx.org.cn
  歐米(Omni)智能客服解決方案
  融合通信商業(yè)解決方案,協(xié)同解決方案首選產(chǎn)品:www.hiastar.com

【免責聲明】本文僅代表作者本人觀點,與CTI論壇無關。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內(nèi)容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

專題