Synthesizer BARGE-IN-OCCURRED

The BARGE-IN-OCCURRED method lets the client notify the synthesizer that a barge-in event has occurred, so it can stop speaking.

It is used in two scenarios:

1. The client has detected a barge-in-able event—DTMF digits, for example—and wants to communicate it to the synthesizer.
2. The recognizer and synthesizer resources are on different servers. Here the client must act as a proxy: it receives the event from the recognition resource and sends a BARGE-IN-OCCURRED method to the synthesizer, carrying the Proxy-Sync-Id header field received from the resource that generated the original event.

If a SPEAK request is active with kill-on-barge-in enabled and BARGE-IN-OCCURRED is received, the synthesizer stops streaming audio. It also terminates any SPEAK requests queued behind the active one, whether or not they have barge-in enabled. When a barge-in-able prompt is terminated, the response lists the request-ids of all terminated SPEAK requests in its Active-Request-Id-List header field, and no SPEAK-COMPLETE events are generated for them.

When the synthesizer and recognizer are on the same server, they can be optimized for a faster kill-on-barge-in response by interacting directly over a common RTSP session-id. In that case the client still proxies the recognition event through a BARGE-IN-OCCURRED method, but the synthesizer may already have stopped and sent a SPEAK-COMPLETE event with a barge-in completion-cause. If no SPEAK requests were terminated as a result, the response is still a 200 (Success) but contains no Active-Request-Id-List header field.

MRCPv1 example

A SPEAK is in progress when the client proxies a barge-in event (note the Proxy-Sync-Id); the response lists the terminated SPEAK in Active-Request-Id-List:

MRCPv2 example

The same exchange in MRCPv2, with the Channel-Identifier and Speech-Marker headers:

Related articles

• Synthesizer Methods
• Synthesizer SPEAK
• Synthesizer STOP
• MRCP Event Messages