Summary:	ASTERISK-17545: Conference menu does not wait after playing message
Reporter:	Matt Lehner (mlehner)	Labels:
Date Opened:	2011-03-12 13:47:46.000-0600	Date Closed:	2013-01-21 08:57:10.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_confbridge
Versions:	1.8.3	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	After the system is done playing the menu audio to the user, it does not wait for the user to input their choice. As a result they must enter their choice while the message is playing, which is unexpected behavior when dealing with an IVR. ****** ADDITIONAL INFORMATION ****** I know very little information about the internals of Asterisk, but the function that gets all to read the digits is ast_waitstream. I didn't see anywhere that there is a timeout defined for this function. The only way I know how to affect the timeout in the dial plan is using the TIMEOUT function. It appears to do nothing so I can only assume it does not affect the above mentioned C function.    Set(TIMEOUT(response)=10);    ConfBridge(${ccontext}-${number}, scMa);
Comments:	By: Matt Jordan (mjordan) 2013-01-21 08:56:52.368-0600 A workaround is available for this in Asterisk 10+. When streaming IVR files to a bridge participant, a 'silence' file can be appended to the DTMF menu option that plays the various options: {noformat} [user_menu] *=playback_and_continue(conf-usermenu&silence) ... {noformat} The silence file could be of any duration someone wanted. This will extend the period of time that DTMF collection occurs. As ConfBridge is in extended support in Asterisk 1.8, and since ConfBridge was heavily revamped in Asterisk 10+, I do not forsee any development effort being expended on this in Asterisk 1.8. As such, I'm going to close this out as "workaround available". If you'd like to discuss this issue further, please contact a bug marshal in #asterisk-bugs and we'd be happy to reopen this.