[asterisk-app-dev] Asterisk DTMF recognizer
Matthew Jordan
mjordan at digium.com
Mon Jan 20 22:17:45 CST 2014
On Mon, Jan 13, 2014 at 9:12 AM, Ben Langfeld <ben at langfeld.me> wrote:
> An update on where this issue got to:
>
> I've begun to extract the SRGS and NLSML libraries created by Chris Rienzo
> as part of the mod_rayo implementation for FreeSWITCH into a standalone
> library at https://github.com/mojolingo/cspeech. There's some outstanding
> work to do on this to get it to compile since it uses a few pieces from
> FreeSWITCH such as memory pools and FreeSWITCH hashes. I'm replacing some of
> these things with C++ types for simplicity. If this is going to be a problem
> for incorporating into Asterisk core, please someone shout and educate me
> about how this should work instead. This library is supposed to be
> reasonably portable, and I'll likely also use it for this issue:
> https://github.com/adhearsion/punchblock/issues/204, so I'd like to avoid
> using Asterisk or FreeSWITCH specifics.
>
> I also half-heartedly began an implementation of res_speech_dtmf here:
> https://github.com/mojolingo/asterisk/pull/1.
>
> I'd love any assistance people could lend in this effort (particularly
> cspeech right now, it's a prerequisite to any further work on the
> recognizer) if there is any interest, since my C experience is rather
> limited.
>
Hey Ben -
Sorry for the late reply. It took a couple of evenings of looking over
cspeech and the module on github for me to coalesce some thoughts on
the work. A few of them - and some questions - below.
1) It's certainly possible to use a C++ library from Asterisk - for an
example of doing this, see chan_h323. There are however some
complexities that this will create. We faced a similar situation when
evaluating SIP stacks for Asterisk. reSIProcate - a fantastic SIP
stack that is written in C++, was one of the candidates. In the end,
we opted to go with PJSIP partially because it was written instead of
C and not C++, partially due to some of those technical complexities.
Brent Eagles wrote up a lot of the hurdles you can face when
incorporating a C++ library into a C application - see
https://wiki.asterisk.org/wiki/display/AST/Investigation+of+a+reSIProcate+Based+SIP+Channel+Driver+in+Asterisk
for some more information. While we opted to not go down that road,
none of the problems are completely insurmountable, but they can get
pretty tricky. Of particular note is handling of exceptions between
the C++/C boundary. For speech applications this is of particular
importance, as I suspect you'll have a fair number of callbacks that
the C++ library will call - this can create a lot of C++ -> C -> C++
calls, which can complicate the flow of errors.
2) I do have some questions about the necessity of res_speech_dtmf.
res_speech typically acts as the 'generic' speech API for Asterisk -
that is, it is 1/2 of a shim that sits between Asterisk and a speech
engine. The other half translates the generic function calls into the
specific library calls, and vice versa.
In the case of DTMF, ast_speech_dtmf will already be called when a
DTMF frame is received in a speech-enabled application/API. If the
grammar loaded by ast_speech_grammar_load/ast_speech_grammar_activate
supports DTMF, it should work.
I would suspect what needs to be written is a res_speech_cspeech -
that is, an adapter from res_speech to Chris's cspeech library. Such a
shim would provide an implementation of the ast_speech_engine virtual
table in speech.h, and register itself with res_speech via
ast_speech_register.
If my thoughts are wrong on this - or there's a reason why an
alternative implementation of res_speech is needed for DTMF - please
let me know.
Either way, if you'd like, I can help put together such a module that
will bridge between Asterisk and cspeech.
3) MIT license for cspeech is thankfully compatible with GPLv2. Yay!
Matt
--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
More information about the asterisk-app-dev
mailing list