1 / 5

MRCPv2 Status 11/08/2005

MRCPv2 Status 11/08/2005. Sarvi Shanmugham Cisco Systems Inc. Status. At version 08. Edits from the last meeting added. Grammar-Ref-List weight parameter added. Language for a future direction in EMMA added. Header Usage tables removed. Speed-Vs-Accuracy inconsistency – Corrected

michael-kemp
Download Presentation

MRCPv2 Status 11/08/2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MRCPv2Status11/08/2005 Sarvi Shanmugham Cisco Systems Inc.

  2. Status • At version 08. • Edits from the last meeting added. • Grammar-Ref-List weight parameter added. • Language for a future direction in EMMA added. • Header Usage tables removed. • Speed-Vs-Accuracy inconsistency – Corrected • Obsolete references to START-TIMERS removed. • Type of Barge-In recognition – Updated based on Email thread. • Media files support for length/size - Added

  3. Open IssueRecognition-Timeout – Andrew Wahbe If we really want to describe what happened, then I think we need to communicate to the client 1) why the recognition was stopped and 2) if the result a no-match, a partial match, or a complete match when it stopped. 1) The recognition can stop for the following reasons (the related cause codes in parens): • no-input timeout (002) • complete timeout (000) • incomplete timeout (001 013) • recognition timeout (003 and 008) • speech too early (007) • cancelled (011) • various errors (004, 005, 006, 009, 010, 012) 2) The result is irrelevant for no-input, speech too early, cancelled, and the errors. This leaves complete timeout, incomplete timeout, and recognition timeout. By the definition of complete timeout, this is always a complete match (000). Also by definition, incomplete timeout could result in a no match (001) or a partial match (013) -- though VoiceXML will likely throw nomatch for either. So we are left with recognition timeout. It could be a complete match (008 by the definition in section 9.4.7) or a partial match (013 by the definition in section 9.4.7), or a no-match... well if it was a hotword recognition we have 003; for the normal case, we have nothing. So hopefully I have clarified my earlier point that Recognition Complete Cause codes 003 and 008 need revisiting. Sorry to be so long winded but I think it's important that VoiceXML be implementable using MRCPv2; it is a very common use case for the specification. Proposed Solution: • 003 recognition-timeout: RECOGNIZE completed without a match due to a recognition-timeout

  4. Resolved issues pending update to 09 • Accept header to be added to MRCP for specifying result format. • SIP Endpoint Capability RFC 3840 to be used to communicate MRCP preferences such as result format support. Propose to go Last Call with -09

  5. Whats next for SpeechSC • Some topics suggested earlierControl of Persistent Grammars on the Server.MRCP server capability discovery and routing.Session Independent MRCP Server ControlOpen for Suggestions/Discussion.

More Related