- Channel-Identifier: 此頭域在請求，響應和我事件消息中是必須強制支持的。此值用來確認通道對消息的唯一性。標準格式為：MRCP會話@媒體類型：Channel-Identifier: 466453af837@speechrecog
- Active-Request-Id-List：此值可能出現(xiàn)在請求或響應中，但是沒有在事件消息中出現(xiàn)。此列表可以列出多項請求的ID。此值會經(jīng)常出現(xiàn)在響應的事件消息中，它可能表示某些請求要被停止或已經(jīng)完成。例如，SPEAK請求中的SPEAK-COMPLETE或RECOGNIZE中的RECOGNITION-COMPLETE可選消息。此值也可能出現(xiàn)在語音合成的媒體類型中，例如PAUSE等。例如，MRCP客戶端可以發(fā)出一個STOP請求，要求某些請求停止：
- Content-Base：此頭可以包含一個相對的URL地址，此地址包含在請求中的可能需要解析的Content-Base，用來支持某些語法。語法格式：
- Content-Encoding：此值定義對內(nèi)容解析解析。如果有多個解析列表支持時。語法格式示例：Content-Encoding: gzip。
- Content-ID:此值是對消息內(nèi)容在消息體中進行識別的ID號，或作為多個消息中的單個ID號。如果此值出現(xiàn)在請求中，它要求媒體資源服務器在一定會話時間內(nèi)保存媒體內(nèi)容數(shù)據(jù)，將來通過MRCP的URL獲取此值。其格式示例為：Content-ID: menu@example.com。
- Content-Length：此值表示消息體的長度。
- Content-Location：此值表示消息體中的資源定位。其語法格式為：
這里支持了相對路徑和絕對路徑。媒體資源服務器可以通過此設置來優(yōu)化某些操作。用戶可以通過緩存來獲取歷史記錄值，而不需要每次通過媒體資源服務器來獲取。
- Content-Type：MRCP支持了一系列非常嚴格的MIME媒體類型來表示其內(nèi)容，例如，speech synthesis markup，speech 語法和識別結果。其語法格式示例為：Content-Type: application/ssml+xml。
- Proxy-Sync-Id：通過媒體服務器結合事件來此值用來提供一種協(xié)調(diào)功能，當在媒體資源中發(fā)生DTMF輸入或語音合成后，系統(tǒng)檢測到了一個打斷行為，通過添加一個事件ID來跟蹤消息。當媒體資源服務器第一次在媒體流中遇到語音或DTMF輸入時，媒體資源服務器端會檢測到一個打斷的檢測消息，那么MRCP客戶端就會從事件中收到一個START-OF-INPUT。然后，MRCP客戶端會馬上發(fā)送一個BARGE-IN-OCCURRED請求到語音合成服務器端，服務器端則決定是否停止語音數(shù)據(jù)的回放。這里，是否回放還要取決于SPEAK請求中設置了參數(shù)Kill-On-Barge-In為true。在一些部署應用環(huán)境中，語音合成服務器和輸入檢測功能結合非常緊密，檢測響應的速度非�？�，檢測協(xié)調(diào)功能是通過其內(nèi)部進行的。為了實現(xiàn)其類似的部署環(huán)境，在START-OF-INPUT的事件消息中，媒體資源服務器需要添加一個識別碼來確認此事件，這樣就構成了一個Proxy-Sync-Id。MRCP 客戶端會在接下來的BARGE-IN-OCCURRED請求中轉發(fā)同樣的ID，這樣媒體資源會使用同樣的打斷檢測事件中的ID來協(xié)調(diào)這個請求。其格式為：proxy-sync-id = "Proxy-Sync-Id" ":" 1*VCHAR CRLF。
- Accept：通常情況下，表示在響應消息中，指定的某些媒體類型是可以接受的。此頭域也用來說明在客戶端的請求中限定了某些媒體類型。例如：Accept: application/sdp。
- Accept-Charset：此頭域用來設置請求中可接受的字符設置方式。它在某些環(huán)境中是非常有用的，例如指定在RECOGNITION-COMPLETE事件中的結果（NLSML）中的字符設置。
- Fetch-Timeout：此值支持MRCP客戶端通過URL來訪問媒體資源服務器的超時設置。默認以毫秒為單位。
- Cache-Control:此頭值用來定義緩存獲取的控制方式。在上面的頭域設置中，我們?nèi)绻褂昧司彺娴脑O置。這里，的設置會控制緩存的獲取規(guī)則。它實際上繼承了HTTP請求中的Cache-Control方式，一般都支持了刷新時間，存活時長等參數(shù)。具體的語法格式為：
這里，我們通常會設置cache-directive 的訪問機制。max-age 表示MRCP客戶端會容許媒體資源服務器端在一定的時間內(nèi)使用此內(nèi)容數(shù)據(jù)。max-stale表示MRCP客戶端允許媒體資源服務器端使用緩存的數(shù)據(jù)，此數(shù)據(jù)訪問超時設置已經(jīng)超過了限定的值（max-stale）。min-fresh表示MRCP客戶端允許的HTTP服務器最小的響應時間設置。
Set-Cookie / Set-Cookie2：此值用來跟蹤MRCP客戶端的訪問狀態(tài)，它實際上繼承了HTTP的Cookies 使用方式。系統(tǒng)可以通過SET-PARAMS和GET-PARAMS來獲取當前的數(shù)據(jù)，例如：
Vendor-Specific：此值支持MRCP客戶端獲取具體的參數(shù)信息內(nèi)容。獲取到的數(shù)據(jù)可能是多個參數(shù)，參數(shù)之間通過分號加以區(qū)分。
Logging-Tag：此頭域僅使用在SET-PARAMS和GET-PARAMS中。此頭域會和會話消息所關聯(lián)。媒體資源服務器可以此標簽來標注一個特別的會話內(nèi)容，支持管理員對特定的會話進行排查。
在本章節(jié)，我們僅對MRCP中會話的16個頭域值逐一進行了介紹。這16個頭值也是MRCP 的標準頭值。這些頭值有的可以支持set方式，有的可以支持get方式。具體的應用我們將在未來的講座中會做更加詳細地介紹。
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
