中文字幕无码久久精品,13—14同岁无码A片,99热门精品一区二区三区无码,菠萝菠萝蜜在线观看视频高清1

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

說話人驗證資源的請求、事件和headers詳解

--MRCP協(xié)議學習筆記

2018-08-07 10:35:15   作者:   來源:CTI論壇   評論:0  點擊:


  在前面的講座中,我們介紹了MRCP媒體資源的幾個主要類型,它們分別是語音合成資源,語音識別資源和錄音資源的所有請求,事件和headers的細節(jié)。今天的講座中,我們介紹MRCP媒體資源的最后一個資源類型-說話人驗證資源(speaker verification resource-speakverify)。
  1、說話人驗證資源對MRCP客戶端提供說話人的驗證和確認功能。說話人驗證主要關心的是說話人應該是誰。通常情況下,說話人驗證是通過他們自己聲明的身份數(shù)據(jù)來驗證。說話人通過一系列的驗證方式來關聯(lián)身份驗證。這一系列的驗證方式包括輸入密碼,客戶ID,或者呼叫號碼綁定的方式來加以驗證。說話人的語句可以和其保存的聲紋語句進行對比來確認其身份,然后執(zhí)行通過或者拒絕的流程。而說話人確認功能則處理的是通過從多人的說話語句中識別出其身份,它通過已錄制的語句對比一組存儲的說話人聲紋來確認說話人身份。簡單來說,說話人確認就是一個已錄制的語音和一組或者多組存儲的聲紋進行對比,識別出其身份。事實上,如果從MRCP說話人驗證資源的角度來討論的話,說話人確認可以看作為多組聲紋的說話人驗證方式。因此,為了討論方便,我們通常使用說話人驗證來表示驗證和確認步驟。另外,MRCP驗證資源的處理方式和基于文本方式的處理方式是相似的,它也借用了自然語言語義標識語音的語法格式來封裝說話人驗證和確認的結(jié)果。
  2、MRCP驗證資源可以在兩種工作模式下執(zhí)行,它可以配合語音識別資源或錄音資源來工作,也可以獨立工作。當獨立工作時,它在媒體會話中通過實時傳輸?shù)姆绞将@得的語音數(shù)據(jù),然后對語音數(shù)據(jù)進行分析。當結(jié)合其他媒體資源工作時,驗證資源會通過驗證資源的緩沖和語音識別資源或錄音資源共享緩沖數(shù)據(jù)。通過設定Ver-Buffer-Utterance header,語音識別資源和錄音資源可以對緩沖進行數(shù)據(jù)寫入的操作。在語音識別或錄音過程中,這個緩沖中的語音數(shù)據(jù)可以后續(xù)支持說話人驗證或者確認的分析任務。
  MRCP驗證資源支持十一個請求消息,兩個事件消息,二十個headers和一個狀態(tài)機。狀態(tài)機可支持兩種工作模式:訓練模式和驗證模式。狀態(tài)機的狀態(tài)改變是通過VERIFY或VERIFY-FROM-BUFFER method來實現(xiàn)。驗證資源的狀態(tài)機的工作流程圖如下:
  3、START-SESSION method 是用來啟動一個訓練或驗證會話。Verification-Mode header可以用來表示其啟動的會話模式。這個會話類型值包括:train和verify。如果設置為驗證會話的話,它會綁定聲紋的數(shù)據(jù)倉庫,其路徑通過Repository-URI來表示。每個會話可以綁定一個或多個聲紋,他們通過各自的聲紋ID Voiceprint-Identifier header表示。這里需要讀者注意,結(jié)合本章節(jié)前面談到的關于驗證資源和確認資源的區(qū)別,他們的使用方式在在這里得到了體現(xiàn)。如果是驗證資源的話,指定的是一個聲紋資源URL。如果是說話人確認的話,可以支持多個聲紋路徑,通過分號分開多個聲紋資源。在訓練期間的話,如果聲紋不存在的話,系統(tǒng)會自動創(chuàng)建。其請求的圖例如下:
  現(xiàn)在,我們看一下此請求的消息流程:
  F1 (client → speakverify):
  • MRCP/2.0 194 START-SESSION 00001
  • Channel-Identifier: 1cd3ee59@speakverify
  • Verification-Mode: train
  • Repository-URI: http://example.com/voiceprintdatabase
  • Voiceprint-Identifier: dave.burke
  F2 (speakverify → client):
  • MRCP/2.0 76 00001 200 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  END-SESSION請求支持結(jié)束訓練或驗證會話。在Abort-Model header創(chuàng)建聲紋,這個聲紋則反映更新狀態(tài)。如果聲紋更新,則可能是訓練會話被激活,或者驗證會話被激活,同時聲紋狀態(tài)信息也會更新。聲紋更新是通過START-SESSION會話中設置 header Adapt-Model 為true來實現(xiàn)。如果Abort-Model設置為false,則會導致聲紋的任何修改都最終保存到數(shù)據(jù)庫中。如果此header設置為true,則會丟棄任何對聲紋的修改。以下是結(jié)束會話的圖例:
  其具體的消息流程如下:
  F1 (client → speakverify):
  • MRCP/2.0 95 END-SESSION 10000
  • Channel-Identifier: 1cd3ee59@speakverify
  • Abort-Model: false
  F2 (speakverify → client):
  • MRCP/2.0 76 10000 200 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  4、VERIFY method是驗證資源對實時語音通過媒體會話進行傳輸,啟動聲紋訓練,或啟動驗證,并且對比多組聲紋數(shù)據(jù)。具體的操作模式是在START-SESSION的header Verification-Mode中設置。當VERIFY 請求完成后,驗證資源會生成一個VERIFICATION-COMPLETE事件消息。NLSML數(shù)據(jù)會包含在這個事件消息中,包括訓練狀態(tài)和驗證狀態(tài)數(shù)據(jù)。以下圖例是一個訓練模式下的流程圖:
  具體的訓練流程消息如下:
  F1 (client → speakverify):
  • MRCP/2.0 194 START-SESSION 20000
  • Channel-Identifier: 1cd3ee59@speakverify
  • Verification-Mode: train
  • Repository-URI: http://example.com/voiceprintdatabase
  • Voiceprint-Identifier: dave.burke
  F2 (speakverify → client):
  • MRCP/2.0 76 20000 200 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  F3 (client → speakverify):
  • MRCP/2.0 70 VERIFY 20001
  • Channel-Identifier: 1cd3ee59@speakverify
  F4 (speakverify → client):
  • MRCP/2.0 79 20001 200 IN-PROGRESS
  • Channel-Identifier: 1cd3ee59@speakverify
  F5 (speakverify → client):
  • MRCP/2.0 90 START-OF-INPUT 20001 IN-PROGRESS
  • Channel-Identifier: 1cd3ee59@speakverify
  F6 (speakverify → client):
  • MRCP/2.0 921 VERIFICATION-COMPLETE 20001 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  • Completion-Cause: 000 success
  • Content-Type: application/nlsml+xml
  • Content-Length: 737
  • cellular-phone
  • male
  • 751
  •  
  • 0.93
  • cellular-phone
  • male
  • 1522
  • false
  •  
  •  
  •  
  •  
  F7 (client → speakverify):
  • MRCP/2.0 95 END-SESSION 20002
  • Channel-Identifier: 1cd3ee59@speakverify
  • Abort-Model: false
  F8 (speakverify → client):
  • MRCP/2.0 76 20002 200 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  5、VERIFY-FROM-BUFFER 請求的和VERIFY的工作方式相同,但是VERIFY-FROM-BUFFER的語音流源來自于驗證緩沖而不是來自于實時的語音數(shù)據(jù)。驗證緩沖數(shù)據(jù)寫入的方式支持通過說話人驗證資源寫入數(shù)據(jù),通過VERIFY請求的頭中設置Ver-Buffer-Utterance為true來獲得支持,也可以通過語音識別資源分配同樣的SIP dialog,通過RECOGNIZE請求中設置Ver-Buffer-Utterance為true的方式寫入,還可以通過錄音資源分配同樣的SIP dialog,通過RECORD請求中設置Ver-Buffer-Utterance為true來獲得支持。這里,需要讀者注意,系統(tǒng)不會為VERIFY-FROM-BUFFER 請求生成START-OF-INPUT事件消息。
  使用從驗證緩沖中驗證說話人有幾個方面的理由。語音識別資源可以用來驗證其用戶身份(例如通過識別客戶賬戶),然后,緊接著此語音數(shù)據(jù)可以和其相應的聲紋進行匹配。另外,如果VERIFY請求驗證用戶失敗的話,但是MRCP客戶端希望使用同樣的語音數(shù)據(jù)匹配其他不同的聲紋資源,這個資源可以被重復使用。這里我們假設,初始的VERIFY已傳輸了Ver-Buffer-Utterance為true的header,驗證緩沖將被寫入,START-SESSION 創(chuàng)建了一個新的會話支持了不同的聲紋,VERIFY-FROM-BUFFER請求也已經(jīng)啟動。以下是一個VERIFY-FROM-BUFFER圖例:
  具體的消息流程如下:
  F1 (client → speakverify):
  • MRCP/2.0 82 VERIFY-FROM-BUFFER 30000
  • Channel-Identifier: 1cd3ee59@speakverify
  F2 (speakverify → client):
  • MRCP/2.0 79 30000 200 IN-PROGRESS
  • Channel-Identifier: 1cd3ee59@speakverify
  F3 (speakverify → client):
  • MRCP/2.0 986 VERIFICATION-COMPLETE 30000 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  • Completion-Cause: 000 success
  • Content-Type: application/nlsml+xml
  • Content-Length: 802
  • 0.85
  • carbon-button-phone
  • male
  • 751
  •  
  • 0.81
  • carbon-button-phone
  • male
  • accepted
  • 801
  •  
  •  
  •  
  •  
  6、VERIFY-ROLLBACK 請求時回滾到前面VERIFY或VERIFY-FROM-BUFFER的請求,因此,前面已處理的語音數(shù)據(jù)不再用于聲紋訓練(訓練會話中)和聲紋的調(diào)整環(huán)境中(驗證會話)。如果多次發(fā)起VERIFY-ROLLBACK請求,則會導致無效回滾。以下是一個回滾請求的圖例:
  VERIFY-ROLLBACK 的消息流程:
  F1(client→speakverify):
  • MRCP/2.0 79 VERIFY-ROLLBACK 40000
  • Channel-Identifier:1cd3ee59@speakverify
  F2(speakverify→client):
  • MRCP/2.0 76 40000 200 COMPLETE
  • Channel-Identifier:1cd3ee59@speakverify
  START-INPUT-TIMERS請求用來支持對驗證資源啟動定時器。啟動默認環(huán)境下,當發(fā)起一個VERIFY請求時,系統(tǒng)會自動啟動No-Input-Timeout的定時器。如果在定時器時間范圍內(nèi),驗證資源沒有檢測到任何輸入的話,VERIFY請求會結(jié)束這個請求,并且生成VERIFICATION-COMPLETE消息,消息中說明了Completion-Cause,其值為002 no-input-timeout。通常情況下,如果用戶完成輸入的話,MRCP 客戶端會馬上發(fā)起VERIFY請求。但是,在有一些應用場景中,我們需要用戶輸入的同時在同一時間內(nèi)啟動訓練或驗證流程。因此,它可以支持熟悉的用戶可以打斷輸入,并且盡早啟動訓練或驗證資源。有時,在提示回放的同時,訓練/驗證資源也同時啟動,如果用戶不想啟動No-Input-Timeout 定時器,他/她需要讓系統(tǒng)完成提示回放以后,才開始啟動定時器。用戶可以VERIFY消息中設置Start-Input-Timers header為false來實現(xiàn)以上要求。如果在稍后的處理過程中,MRCP客戶端知道提示回放已經(jīng)完成的話,客戶端可以對驗證資源發(fā)起START-INPUT-TIMERS啟動No-Input-Timeout定時器。 以下是一個START-INPUT-TIMERS圖例:
  START-INPUT-TIMERS 的消息流程:
  F1(client→speakverify):
  • MRCP/2.0 70 VERIFY 50000
  • Channel-Identifier:1cd3ee59@speakverify
  F2(speakverify→client):
  • MRCP/2.0 79 50000 200 IN-PROGRESS
  • Channel-Identifier:1cd3ee59@speakverify
  F3(client→speakverify):
  • MRCP/2.0 82 START-INPUT-TIMERS 50001
  • Channel-Identifier:1cd3ee59@speakverify
  F4(speakverify→client):
  • MRCP/2.0 76 5000 1200 COMPLETE
  • Channel-Identifier:1cd3ee59@speakverify
  F5(speakverify→client):
  • MRCP/2.0 90 START-OF-INPUT 50000 IN-PROGRESS
  • Channel-Identifier:1cd3ee59@speakverify
  F6(speakverify→client):
  • MRCP/2.0 920 VERIFICATION-COMPLETE 50000 COMPLETE
  • Channel-Identifier:1cd3ee59@speakverify
  • Completion-Cause: 000 success
  • Content-Type:application/nlsml+xmlContent-Length:736
  •  
  • cellular-phone
  • male
  • 751
  •  
  • 0.53
  • cellular-phone
  • male
  • 1522
  • true
  •  
  •  
  •  
  •  
  當VERIFY或VERIFY-FROM-BUFFER請求正在處理中時,MRCP客戶端可以發(fā)出GET-INTERMEDIATE-RESULT請求要求獲得更多累計的驗證資源。這里讀者要注意,GET-INTERMEDIATE-RESULT的響應消息中包含NLSML數(shù)據(jù),因為請求仍然進行中,還沒有完成,所以響應消息中沒有Completion-Cause header。當驗證資源在空閑狀態(tài)時,MRCP客戶端發(fā)送GET-INTERMEDIATE-RESULT請求時,它會收到402 Method not valid in this state 響應碼。以下是GET-INTERMEDIATE-RESULT圖例:
  消息流程如下:
  F1 (client → speakverify):
  • MRCP/2.0 87 GET-INTERMEDIATE-RESULT 60000
  • Channel-Identifier: 1cd3ee59@speakverify
  F2 (speakverify → client):
  • MRCP/2.0 934 60000 200 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  • Content-Type: application/nlsml+xml
  • Content-Length: 799
  • 0.53
  • cellular-phone
  • male
  • 751
  •  
  • 0.67
  • cellular-phone
  • male
  • 1522
  • true
  •  
  •  
  •  
  •  
  STOP method用來支持正在進行的訓練驗證資源,資源狀態(tài)返回到空閑狀態(tài)。STOP 的響應消息中會包含Active-Request-Id-List 列表,表示結(jié)束的ID。在STOP請求method中可以包含一個Abort-Verification 頭,此header可以用來表示訓練驗證結(jié)果是否丟棄(true)或者保持(false)。 如果是false的話,STOP請求的響應消息中包含驗證結(jié)果。以下是STOP 請求的圖例:
  具體的消息流程圖:
  F1 (client → speakverify):
  • MRCP/2.0 70 VERIFY 70000
  • Channel-Identifier: 1cd3ee59@speakverify
  F2 (speakverify → client):
  • MRCP/2.0 79 70000 200 IN-PROGRESS
  • Channel-Identifier: 1cd3ee59@speakverify
  F3 (client → speakverify):
  • MRCP/2.0 95 STOP 70001
  • Channel-Identifier: 1cd3ee59@speakverify
  • Abort-Verification: true
  F4 (speakverify → client):
  • MRCP/2.0 108 70001 200 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  • Active-Request-Id-List: 70000
  CLEAR-BUFFER method用來清除驗證緩沖數(shù)據(jù)。在前面的討論中,我們已經(jīng)介紹了如何實現(xiàn)緩沖數(shù)據(jù)寫入。這里,使用CLEAR-BUFFER來清除緩沖數(shù)據(jù)。具體的緩沖清除圖例如下:
  清除驗證緩沖數(shù)據(jù)的消息流程如下:
  F1 (client → speakverify):
  • MRCP/2.0 76 CLEAR-BUFFER 80000
  • Channel-Identifier: 1cd3ee59@speakverify
  F2 (speakverify → client):
  • MRCP/2.0 76 80000 200 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  QUERY-VOICEPRINT method用來支持MRCP客戶端對驗證資源進行聲紋數(shù)據(jù)查詢。聲紋數(shù)據(jù)是通過Repository-URI和Voiceprint-Identifier 來確定。在給定的URL資源中,每個Voiceprint-Identifier 設定了一個唯一的ID。QUERY-VOICEPRINT 響應消息中會包含一個布爾值Voiceprint-Exists來表示此聲紋是否存在。如果Repository-URI 不存在,則返回響應消息,并且相當Completion-Cause: 007 repository-uri-failure header。 以下是一個查詢聲紋資源的圖例:
  查詢聲紋消息流程:
  F1 (client → speakverify):
  • MRCP/2.0 171 QUERY-VOICEPRINT 90000
  • Channel-Identifier: 1cd3ee59@speakverify
  • Repository-URI: http://example.com/voiceprintdatabase
  • Voiceprint-Identifier: dave.burke
  F2 (speakverify → client):
  • MRCP/2.0 102 90000 200 COMPLETE
  • Channel-Identifier: 1cd3ee59@speakverify
  • Voiceprint-Exists: true
  DELETE-VOICEPRINT method用來支持MRCP客戶端刪除聲紋,具體的聲紋身份確認由Repository-URI 和Voiceprint-Identifier構(gòu)成。 這里,讀者要注意,如果指定的需要刪除的聲紋不存在的話,不會會任何返回錯誤。圖例是刪除聲紋的流程:
  具體的刪除聲紋的消息流程如下:
  F1 (client → speakverify):
  • MRCP/2.0 173 DELETE-VOICEPRINT 100000
  • Channel-Identifier: 1cd3ee59@speakverify
  • Repository-URI: http://example.com/voiceprintdatabase
  • Voiceprint-Identifier: dave.burke
  F2 (speakverify → client):
  • MRCP/2.077100000200COMPLETE
  • Channel-Identifier:1cd3ee59@speakverify
  7、驗證資源包括兩個消息事件,兩個事件分別是START-OF-INPUT和VERIFICATION-COMPLETE。這兩個事件在前面的章節(jié)中都有完整的消息示例,讀者可以參考那些示例來進一步了解這兩個事件。
  START-OF-INPUT事件是由說話人驗證資源生成,通知MRCP客戶端已經(jīng)收到輸入數(shù)據(jù)。MRCP客戶端使用此事件來進行語音打斷檢測或者停止語音回放。
  VERIFICATION-COMPLETE是由說話人驗證資源生成來對MRCP客戶端說明訓練/驗證流程已經(jīng)完成,正在消息體中傳輸訓練或驗證結(jié)果。Completion-Cause和可選Completion-Reason header來表示訓練或驗證的完成狀態(tài)。
  8、MRCP協(xié)議的驗證資源支持了二十個headers,F(xiàn)在,我們逐一介紹這些headers的使用方式。
  • Completion-Cause,此header總是出現(xiàn)在VERIFICATION-COMPLETE的響應事件中,用來表示VERIFY或VERIFY-FROM-BUFFER請求完成的原因。注意,它也可能出現(xiàn)在VERIFY,VERIFY-FROM-BUFFER或QUERY-VOICEPRINT請求中,包含失敗狀態(tài)碼。名稱等消息。示例:Completion-Cause:005 buffer-empty。
  • Completion-Reason,此header是可選的header,通常伴隨著Completion-Cause header一起出現(xiàn),為MRCP客戶端排查提供更多l(xiāng)og消息。示例:Completion-Reason:Out of memory。
  • Verification-Mode,此header用來表示在START-SESSION的驗證類型,是訓練模式(train)還是驗證模式(verify)。示例:Verification-Mode:train。
  • Repository-URI,此header用來表示在START-SESSION,QUERY-VOICEPRINT或DELETE-VOICEPRINT中的聲紋,此聲紋所存儲的數(shù)據(jù)庫中的URL地址。示例:Repository-URI:file://host/voiceprintdb/。
  • Voiceprint-Identifier,此header在說話人驗證資源中已聲明的確認身份。對于說話人確認來說,此header可以包含單個聲紋或者一組說話人聲紋。此header在START-SESSION,QUERY-VOICEPRINT或DELETE-VOICEPRINT請求中設定。此header的值的格式必須是兩組字符串,通過句號分開。示例:Voiceprint-Identifier:joe.bloggs。
  • Adapt-Model, 此header使用在START-SESSION請求中,表示當驗證資源成功執(zhí)行后,是否可以對聲紋進行調(diào)整,通過調(diào)整可以提高驗證的準確率。默認為false。示例:Adapt-Model:true。
  • Abort-Model,此header可以在END-SESSION請求中設定,它用來表示任何聲紋的修改結(jié)果可以被丟棄或保存在數(shù)據(jù)庫。如果在header中設置為true,表示丟棄修改結(jié)果;false則表示保存修改結(jié)果。示例為:Abort-Model:true。
  • Min-Verification-Score,此header表示驗證評分最小值,驗證資源決定可接受范圍。其取值范圍在-1.0-1.0之間。示例為:Min-Verification-Score:0.75。
  • Num-Min-Verification-Phrases, 此header設定的最小語句,此最小語句值是認證資源要求的可接受的最小數(shù)值。默認值為1,示例為:Num-Min-Verification-Phrases:2。
  • Num-Max-Verification-Phrases,此header設定的最大語句數(shù)量,在驗證結(jié)果決定之前所接受的最大語句數(shù)量。示例:Num-Max-Verification-Phrases: 3。
  • No-Input-Timeout,此header用來設定的檢測輸入超時的時長。此取值以毫秒為單位。無默認值設置。示例:No-Input-Timeout: 3000。
  • Save-Waveform,此header為一個布爾值,用來表示說話讓驗證資源是否在驗證過程中保存捕捉到語音。如果設置為true,生成的事件VERIFICATION-COMPLETE中包含Waveform-URI來提示保存文件的路徑,MRCP客戶端可以通過此URL獲取到捕捉到語音數(shù)據(jù)。默認值為false,示例為:Save-Waveform: true。
  • Media-Type,此header表示捕捉到的語音數(shù)據(jù)的格式。示例為:Media-Type: audio/x-wav。MRCP不會強制使用某種特定的語音格式。
  • Waveform-URI,此header表示在實時驗證中捕捉到語音數(shù)據(jù)URL地址,用來和MRCP客戶端進行通信。如果Save-Waveform設定為true,此header會出現(xiàn)在VERIFICATION-COMPLETE事件中。此取值會追加數(shù)據(jù)大。╞ytes)和時長(毫秒)參數(shù)設置。在存活的會話過程中,此URL必須是可訪問的。如果錄音時產(chǎn)生錯誤的話,Waveform-URI為空。示例:Waveform-URI: ;size=8000;duration=1000。
  • Input-Waveform-URI,此header是為VERIFY請求method提供語音數(shù)據(jù),而不是使用媒體會話的方式。此header在某些環(huán)境下非常有用,當需要前面的資源提供識別時,語音識別資源和語音驗證資源都是獨立分離的狀態(tài),可能各自在不同的會話。示例:Input-Waveform-URI: http://10.0.0.1/utt01.wav。
  • Voiceprint-Exists,此header是一個布爾值,表示聲紋URL是否存在。它存在于QUERY-VOICEPRINT 和 DELETE-VOICEPRINT響應消息中。示例:Voiceprint-Exists: false。
  • Ver-Buffer-Utterance, 此header可以通過VERIFY請求中設定。如果此值設定為true, 則表示驗證資源可以支持對捕捉到錄音作為緩沖,以支持會話的后期使用。這里,讀者要注意,在同一SIP dialog中的語音識別資源或錄音資源可以通過其各自的請求方式對緩沖進行寫入操作。默認值為false。示例是:Ver-Buffer-Utterance: true。
  • New-Audio-Channel,此header可以通過VERIFY請求來設定。如果此header設置為true,則對驗證資源表示,從此刻起,新通道會接收語音數(shù)據(jù)。說話人驗證資源通常會以請求的方式打斷現(xiàn)在的通道,重新對終端設置新的算法,丟棄前面通道中的歷史數(shù)據(jù)。默認值為false,示例:New-Audio-Channel: true。
  • Abort-Verification,此header在STOP請求中出現(xiàn),表示是否丟棄或保留已訓練或驗證的結(jié)果。如果設置為true,則表示丟棄訓練結(jié)果。示例:Abort-Verification: true。
  • Start-Input-Timers,此header可能出現(xiàn)在VERIFY請求中,通知說話人驗證資源是否啟動No-Input-Timeout 定時器。默認為true。示例:Start-Input-Timers: false。
  9、在本講座中,我們首先介紹了說話人驗證資源的背景知識,驗證資源和確認資源的區(qū)別,然后分別介紹了驗證資源的請求方式,事件和所有驗證資源的headers。在每個請求方式的介紹過程中,筆者結(jié)合具體的流程圖和消息流程做了非常詳細的解釋,以及需要讀者特別注意到對方。另外,對headers也做了非常詳細的解釋,這樣可以幫助讀者能夠完全掌握MRCP協(xié)議中說話人驗證資源的所有相關細節(jié)。
  到目前為止,我們已經(jīng)基本上介紹了整個MRCP協(xié)議的主體部分。在后續(xù)的章節(jié)中,筆者會根據(jù)時間安排等實際情況,更多討論MRCP相關的安全方面的話題和其應用實踐。
 
 
  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)容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

專題