Re: Asterisk DTMF recognizer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 21 January 2014 02:53, Matthew Jordan <mjordan@xxxxxxxxxx> wrote:
On Mon, Jan 20, 2014 at 10:17 PM, Matthew Jordan <mjordan@xxxxxxxxxx> wrote:
> On Mon, Jan 13, 2014 at 9:12 AM, Ben Langfeld <ben@xxxxxxxxxxx> wrote:

<snip>

> 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.
>

Disregard this point - what you are writing *is* the correct thing,
that is, the shim that sits between res_speech and cspeech. I think
the name just threw me for a bit.

Happy to use some other name. The logic here was that it was to be the core/default DTMF recognizer for res_speech.
 
That, and I probably shouldn't look
at unfamiliar code past 10.

As a follow up question: how do you envision res_speech_dtmf - which
will convert an Asterisk DTMF frame into an appropriate
SSML/SRGS/NLSML representation - working with another speech engine?
Does it have value as a stand-alone piece of functionality?

The idea is that it'll be a full recognizer implementation. It would be the default engine registered with res_speech in the absence of any other external implementation (eg UniMRCP). An application would either invoke the default recognizer, or some other (eg UniMRCP), and the two would not necessarily have any interaction at all.

I also envision that this recognizer would be implemented as a UniMRCP Server plugin so that it is available more widely.
 
Regardless, I'd be happy to assist with the Asterisk module development.

Excellent! Right now I'm waiting on news from Chris that he is done with his current work on cspeech (https://github.com/crienzo/cspeech/commits/master).
 


--
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

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux