I can use play_and_detect_speech app and set Recognition-Mode=hotword to do the hotword barge-in. This is working. I am still trying detect_speech and speak for simultaneous speech recognition. I can receive the events like DETECTED_SPEECH or BEGIN_SPEAKING if I speak after the TTS finishes The problem is that I can not receive those events in my ESL client if I speak during the TTS is playing, but I can see there are some recognition results from FS console. Tried various things, didn't get it work. Does anybody have any clue on this? Thanks! Xing On 02/13/2013 03:44 PM, x.liu wrote:

Hello,

I am trying to do simultaneous speech recognition and TTS via mod_unimrcp using detect_speech and speak.

What I want to achieve is to enable a user to say something like "shut up" to stop TTS rather than using standard barge-in to stop TTS.

When I spoke something during playing a sentence, I noticed there were some recognition results from FS log, but my ESL app didn't get any DETECTED_SPEECH or BEGIN_SPEAKING events.

Has any body had similar experiences before?

From Arsen Chaloyan's comments at 11 July 2011:

"If I'm not mistaken, neither Asterisk nor FreeSWITCH are currently capable to play a TTS prompt while making a recognition. However, I don't see any conceptual problem here. This is somewhat not implemented yet for those open source projects. Other UniMRCP based implementations do this job very well."

I am wondering if the current mod_unimrcp does not support concurrent recognition and tts or if I am not using it properly?

Thanks!

Xing

------------------------------------------------------------------------

Sunday Times Scottish University of the Year 2011-2013 Top in the UK for student experience Fourth university in the UK and top in Scotland (National Student Survey 2012)

We invite research leaders and ambitious early career researchers to join us in leading and driving research in key inter-disciplinary themes. Please see www.hw.ac.uk/researchleaders for further information and how to apply.

Heriot-Watt University is a Scottish charity registered under charity number SC000278.

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

----- Sunday Times Scottish University of the Year 2011-2013 Top in the UK for student experience Fourth university in the UK and top in Scotland (National Student Survey 2012) We invite research leaders and ambitious early career researchers to join us in leading and driving research in key inter-disciplinary themes. Please see www.hw.ac.uk/researchleaders for further information and how to apply. Heriot-Watt University is a Scottish charity registered under charity number SC000278.

Steve, yes I use hangup_after_bridge=true in my dialplan. Probably you are correct and it looks like that it is really a reason of "NORMAL_CLEARING". Um... I don't want ignore the remote cause. Actually I want to use remote cause and ignore "NORMAL_CLEARING". May be I should not use hangup_after_bridge. Also may be I understand you not correctly. At present I fixed my issue by means of http://wiki.freeswitch.org/wiki/Variable_disable_q850_reason Thanks a lot for your response. From: steveayre@gmail.com Date: Wed, 13 Feb 2013 17:19:29 +0000 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] 486 Busy Here with Reason: Q.850; cause=16; text="NORMAL_CLEARING" Please post a debug-level log of the call. How are you hanging up the call? If with the 'hangup' app what parameters do you use? In particular if you bridge and it fails with 486 then hangup then the SIP code sent may be from the last bridge cause while the Q.850 cause is the one given to hangup. If that's the case try setting sip_ignore_remote_cause=true before the bridge and it'll only send the Q.850->SIP mapping (https://tools.ietf.org/html/rfc3398). Note there's no SIP code mapping for 16 though. If hanging up without answering the call use a different cause. -Steve On 13 February 2013 15:17, Yuriy Nasida <nasida@live.ru> wrote: Hi guys, I see that my FS sends sip message "486 Busy Here" with Reason: Q.850; cause=16;text="NORMAL_CLEARING". Why 16 and "NORMAL_CLEARING ? Probably it should be 17 "user busy". One of my carrier play a "fast busy" (number not available) and blames Q.850 field. Any advice are welcome.Thanks. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org