No, it is not like that, call pursuing, status also changing to unmute but unmute not functioning, I tried also with .sh file for execution but result same, but when I execute same commad from cli, its works. pls see.
My guess would be that it is because the channel is taken out of the bridge in order to run the dialplan, and the designers didn’t consider that anyone might want to issue a command that changed the state of the channel, in the bridge, whilst the channel was in the application, but out of the bridge.
I wouldn’t like to say whether that is a bug, but would note that, if the designers would have wanted a busy lockout feature, they would have implemented it within the code.
I have a suspicion that this is an attempted engineering solution to a social problem.
This is not something I would consider safe to do here, but I’d need to do some careful code reading to be sure exactly what the impact would be. I’m wondering if there is some misunderstanding here that you can be talking in the conference at the same time as executing dialplan, which seems very unlikely. I’d think you would have to return from the dialplan to re-establish the conference bridge.
It looks like any user who uses this feature will be locked out of the conference, as there seems to be no way back, except, possibly, through some subtlety of WaitExten.
We want that participant would remain unmute for a certain time, after a time it will become mute. Would you suggest to use here ami confbridge event if it works.
to modify the confbridge source code to add a suitable new feature.
to write an AMI application that monitors DTMF (or at a push, use exec_dialplan to generate a custom event), and does all the interlocking and time limit logic, and uses ConfbridgeMute and ConfbridgeUnmute actions to control the muting.
PS your original logic doesn’t seem to decrement the group count until the user finally leaves the conference, so one someone gets the right to speak everyone else is locked out until that person finally leaves.