Asterisk Output and Input should assume MRCP

[benlangfeld]

Motivation

These days app_swift is utterly unstable and mostly useless. MRCP is used in the vast majority of TTS and ASR deployments, and is the industry standard interface to a TTS or ASR engine.

Additionally, is is sometimes preferable for an application to be more specific about the renderer/recognizer it wishes to invoke by specifying a particular MRCP client profile. This is currently not possible when the only distinction supported is native|unimrcp|swift.

Changes required

• [ ] Remove support for app_swift - this is superseded by the UniMRCP Server Cepstral plugin.
• [ ] renderer/recognizer attributes should specify the UniMRCP profile.
• [ ] Native output rendering with fallback to UniMRCP (default profile) should be the default when no renderer is supplied.
• [ ] Native DTMF detection should be the default when only DTMF grammars are provided and no recognizer is supplied. If speech grammars are supplied, should fall back to the default UniMRCP profile.
• [ ] If UniMRCP is not available, or if rendering or recognition is not possible, a sensible error should be returned.

  Application impact

Applications will no longer be able to make use of app_swift. This will necessitate a bump to the major version of Punchblock.

[benlangfeld]

@bklang Comments appreciated.

[bklang]

While I am a little disappointed to lose app_swift support, I think this is the right direction. I agree that MRCP is the priority interface to support, especially since Cepstral can be reached via MRCP as well.

Can app_swift functionality be moved to a plugin? It may or may not work, but it would allow others who do use app_swift to contribute to its maintenance more easily.

[benlangfeld]

Punchblock doesn't have plugins, it would be more trouble than its worth to try to support that. We could perhaps move it into adhearsion-asterisk, but I would think we'd be better served by killing it completely and documenting the setup with UniMRCP Server.