Recognizer START-INPUT-TIMERS
START-INPUT-TIMERS lets the client control when the recognizer’s input timers begin, decoupling that moment from when the RECOGNIZE request was issued. This matters in the kill-on-barge-in scenario—particularly when the recognizer and synthesizer are not in the same session.
While a kill-on-barge-in prompt is playing, the client typically wants a RECOGNIZE request active so it can detect barge-in, but it does not want the recognizer to start the No-Input timer until the prompt has finished. The Start-Input-Timers header field on the RECOGNIZE request controls this: set it to false and the recognizer holds the timers until told otherwise.
| MRCP/2.0 435 RECOGNIZE 3 Channel-Identifier: 1e244a68-426a-4780-c@speechrecog Content-Type: text/uri-list Cancel-If-Queue: false Start-Input-Timers: false Dtmf-Term-Char: # No-Input-Timeout: 15000 Dtmf-Interdigit-Timeout: 2000 Speech-Complete-Timeout: 1200 Dtmf-Term-Timeout: 2000 Recognition-Timeout: 20000 Clear-Dtmf-Buffer: true Speech-Incomplete-Timeout: 3000 Content-Length: 36 session:grammar-0 session:grammar-1 |
With Start-Input-Timers set to false as above, the recognizer will not start the No-Input timer until the client sends a START-INPUT-TIMERS request—normally once the client knows the prompt has finished playing.
If instead the client wants the timers to start as soon as the RECOGNIZE request is processed, it sets the header to true:
| Start-Input-Timers: true |
This is an MRCPv2 method. It should not be confused with the MRCPv1 RECOGNITION-START-TIMERS method, which performs the same function under the older protocol.
MRCPv2 example
Once the prompt has finished, the client sends START-INPUT-TIMERS to start the timers:
| C->S: MRCP/2.0 ... START-INPUT-TIMERS 543260 Channel-Identifier:32AECB23433801@speechrecog S->C: MRCP/2.0 ... 543260 200 COMPLETE Channel-Identifier:32AECB23433801@speechrecog |