Summary:ASTERISK-20601: Confbridge recording does not work
Reporter:Vilius (vilius365)Labels:
Date Opened:2012-10-24 10:05:11Date Closed:2012-10-30 10:04:56
Versions:10.10.0 11.0.0-beta2 Frequency of
must be completed before resolvingASTERISK-20529 Asterisk 10.10.0 Blockers
Environment:Attachments:( 0) confbridge_mixmonitor.diff
Description:Confbridge recording does not work neither through CLI nor AMI.





exten => 3000,1,ConfBridge(3000,conf_bridge,conf_user)

Asterisk CLI

confbridge list 3000

Channel                       User Profile     Bridge Profile   Menu             CallerID
============================= ================ ================ ================ ================
SIP/toLab106-00000000         conf_userq conf_bridge                 <unknown>
SIP/toLab106-00000001         conf_userq conf_bridge                 <unknown>

LAB105*CLI> confbridge record start 3000
Recording started

LAB105*CLI> confbridge record stop 3000
Recording could not be stopped.

LAB105*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/toLab106-0000000 3000@InVADEDialler:1 Up      ConfBridge(3000,conf_bri
SIP/toLab106-0000000 3000@InVADEDialler:1 Up      ConfBridge(3000,conf_bri
ConfBridgeRecorder/c s@default:1          Up      (None)


Action: ConfbridgeStartRecord
Conference: 3000

Response: Success
Message: Conference Recording Started.

Action: ConfbridgeStopRecord
Conference: 3000

Response: Error
Message: Internal error while stopping recording.

Comments:By: Jonathan Rose (jrose) 2012-10-24 11:34:49.268-0500

I'm checking this out right now.  I can already confirm that this configuration doesn't work in current checkouts of 10 and 11 and that it worked in 10.0, so this is a somewhat serious regression.

By: Jonathan Rose (jrose) 2012-10-24 12:14:46.133-0500

Ok, I've isolated the issue to the big confbridge patch that Terry wrote to give conferences a state machine to determine their operational status in regard to marked/unmarked users.


By: Jonathan Rose (jrose) 2012-10-24 14:15:11.783-0500

This might be the wrong approach, but here is a quick fix that appears to work.

By the by, I think this startup code should be refactored since a lot of logic is shared between the AMI and CLI methods of starting the MixMonitor on confbridge.

By: Vilius (vilius365) 2012-10-25 03:59:19.327-0500

Thanks Jonathan, I can confirm it works now.
I have also noticed a minor discrepancy the default confbridge recording path is /var/spool/asterisk/monitor however in /var/spool/asterisk I can see confbridge folder. Shouldn't it be in the confbridge folder?
Also I believe there should be an option to select what type of recording someone want to make, because at the moment it defaults to .wav.

By: Jonathan Rose (jrose) 2012-10-25 10:11:26.189-0500

Well, as far as selecting the recording format, if it wasn't already a feature of Confbridge, then that should be filed as a separate issue.

When you say that the confbridge recording is being placed into /var/spool/asterisk/monitor, is this behavior actually different from how the recordings worked prior to the patch which caused this issue, or is this an improvement you are suggesting?  I was under the impression these recordings were actually supposed to end up in /var/spool/asterisk/monitor/confbridge, but I'll acknowledge I didn't pay a whole lot of attention to the paths of the recordings while working on this patch.

By: Vilius (vilius365) 2012-10-25 10:23:16.853-0500

OK, I will check the feature request list for recording format, if its not there I will fill in the request.

Before the patch you provided I wasn't able to do any recordings hence I can not confirm where it was/should've been going. As I said the successful recording (after the patch) appeared in /var/spool/asterisk/monitor. As confbridge is separate from meetme that the recording should go to different location (again I will check if this is already not in the feature request list). Also just to mention I have noticed that there was folder /var/spool/asterisk/confbringe created by default, hence I thought that it must be used for confbridge recordings.

By: Jonathan Rose (jrose) 2012-10-26 15:23:39.887-0500

Oh, you weren't reporting this as a regression then and it just turned out to be one.  Well, all the same I don't actually have a confbridge folder in my spool directory for Asterisk, so I would currently assume that is somewhat coincidental... or perhaps that's for other files or recordings made under different circumstances. It could be worth looking into though.