Summary:ASTERISK-19727: MixMonitor does not work on local channels
Reporter:Mark Murawski (kobaz)Labels:
Date Opened:2012-04-15 13:41:35Date Closed:2012-04-27 14:28:19
Versions:SVN Frequency of
is related toASTERISK-19426 Mixmonitor does not create file and record anything
is related toASTERISK-19497 ConfBridge recording does not work reliably
Environment:Attachments:( 0) 32-bit-time-overflow-2012-04-27.diff
( 1) ASTERISK-19727-2012-04-26.diff
( 2) mixmonitor_debug_trunk.txt
( 3) scrollback-kobaz-1BUC
Description:I don't recall which version this used to work on, but it doesn't on 1.8-svn r362145

context services {
 7060 => {

 8070 => {

 8080 => {

[2012-04-15 14:34:36]     -- <SIP/6200-00000000> Executing [7060@services:2] MeetMe(112,d)
[2012-04-15 14:34:39]     -- <SIP/6850-00000001> Executing [7060@services:2] MeetMe(112,d)

channel originate Local/8070@services extension 8080@services

[2012-04-15 14:35:12]     -- <Local/8070@services-6301;2> Executing [8070@services:1] Answer()
[2012-04-15 14:35:12]     -- <Local/8070@services-6301;1> Executing [8080@services:1] Answer()
[2012-04-15 14:35:12]     -- <Local/8070@services-6301;1> Executing [8080@services:2] MixMonitor(1334514912.3.WAV)
[2012-04-15 14:35:12]     -- <Local/8070@services-6301;1> Executing [8080@services:3] Wait(1000)
[2012-04-15 14:35:12]   == <Local/8070@services-6301;1> Begin MixMonitor Recording: /var/spool/asterisk/monitor/1334514912.3.WAV
[2012-04-15 14:35:12]     -- <Local/8070@services-6301;2> Executing [8070@services:2] MeetMe(112,d)

# ls -al /var/spool/asterisk/monitor/1334514912.3.WAV
ls: cannot access /var/spool/asterisk/monitor/1334514912.3.WAV: No such file or directory

Using Monitor() in the same fashion does work.

I did some poking around and MixMonitor gets hung up in mixmonitor_thread
doing  if (!(fr = ast_audiohook_read_frame(&mixmonitor->audiohook, SAMPLES_PER_FRAME, AST_AUDIOHOOK_DIRECTION_BOTH, AST_FORMAT_SLINEAR))) {

fr is always null, MixMonitor never gets a frame when using a local channel.

MixMonitor in this fashion works fine:
Comments:By: Matt Jordan (mjordan) 2012-04-20 12:48:44.506-0500


I set up a similar test and wasn't able to reproduce this.  Do you mind attaching a DEBUG log?

I'm curious to see if it looks similar to some of the other MixMonitor related issues as well.



By: Mark Murawski (kobaz) 2012-04-20 13:18:12.067-0500

debug log

By: Mark Murawski (kobaz) 2012-04-20 13:24:20.082-0500

If you want access to the box in question, I can set that up for you.

By: Matt Jordan (mjordan) 2012-04-26 11:16:37.354-0500

Mark -

I've attached a patch (ASTERISK-19727-2012-04-26) for 1.8 that may fix this problem, although it contains a bunch of debug stuff, and is *not* the correct solution.  Its mostly just to verify that what I think is happening is actually happening.

Let me know what happens with this one - the extra DEBUG stuff should help clarify exactly what the audiohook is doing if it chooses to ignore samples from the read/write factories.


By: Michael L. Young (elguero) 2012-04-27 09:56:23.779-0500

I applied your patch to a 32 bit machine running trunk since I am curious as to what is going on as well.  I had to make two changes to the debug string format placeholders,   write_diff and read_diff needed %lld since they are int64_t.  I have things setup like what was mentioned in a comment in the related issue, ASTERISK-19426, https://issues.asterisk.org/jira/browse/ASTERISK-19426?focusedCommentId=189761&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-189761.

I will attach some of the debug info.  Hope this helps in tracking down the issue.

By: Matt Jordan (mjordan) 2012-04-27 10:30:09


Yeah, that patch might have trouble compiling due to machine dependent interpretations as to what an int64_t actually is.

That patch was merely to confirm the behavior that was happening - (I posted a long description of it on ASTERISK-19497) - I've attached a patch that should fix this for 1.8 on this issue.


By: Matt Jordan (mjordan) 2012-04-27 10:30:40.269-0500

I should note - the patch that fixes the root cause of the problem is 32-bit-time-overflow-2012-04-27.diff.

By: Michael L. Young (elguero) 2012-04-27 14:03:02.428-0500

I can confirm that the patch appears to solve the problem.

It is great when things work out "positively" instead of "negatively" :)

The times are now positive numbers and the recording is created with audio being written to it.

By: Mark Murawski (kobaz) 2012-05-02 09:34:47.202-0500

Confirmed fixed for me too.