[asterisk-bugs] [JIRA] (ASTERISK-21094) MixMonitorMute mutes through stream if already slinear (e.g. Originate)

[David Woolley (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Woolley updated ASTERISK-21094:
-------------------------------------

    Reference Notes: 
My analysis of the problem is that this is a problem in audiohook.c that has existed as long as MixMonitorMute has existed.

If a frame is received by audio_audiohook_write_list and is already in slinear format (by default Originate will use this format), part 1 of the processing does nothing, and in particular, does not run frdup.

Stage two therefore receives the actual frame that will eventually be passed through.  It passes this to ast_audiohook_write_frame, which checks for the mute options and clearing the frame contents, before passing it ast_slinfactory_feed.  Only when it gets there is the frame actually duplicated.

Although you can consider muting an extreme case of volume reduction, this does not happen for volume reduction, because that is done in the audiohook read logic, which is on the far side of the slinfactory, and therefore using a copy of the frame.

I'm now going to investigate moving the mute logic to the same place as the volume logic.

We actually used the branch SVN version.  I have quoted the most recent tag version as I couldn't find a branch SVN option, and it looks to me as though the problem is not new.

Edited for typos.

  was:
My analysis of the problem is that this is a problem in audiohook.c that has existed as long as MixMonitorMute has existed.

If a frame is received by audio_audiohook_write_list and is already in slinear format (by default Originate will use this format), part 1 of the processing does nothing, and in particular, does not run frdup.

Stage two therefore receives the actual frame that will eventually passed through.  I passes this to ast_audiohook_write_frame, which checks for the mute options and clearing the frame contents, before passing it ast_slinfactory_feed.  Only when it gets there is the frame actually duplicated.

Although you can consider muting an extreme case of volume reduction, this does not happen for volume reduction, because that is done in the audiohook read logic, which is on the far side of the slinfactory, and therefore using a copy of the frame.

I'm now going to investigate moving the mute logic to the same place as the volume logic.

We actually used the branch SVN version.  I have quoted the most recent tag version as I couldn't find a branch SVN option, and it looks to me as though the problem is not new.

    
> MixMonitorMute mutes through stream if already slinear (e.g. Originate)
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-21094
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21094
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_mixmonitor
>    Affects Versions: 1.8.20.1
>         Environment: CentOS 5.3.  VMWare.
>            Reporter: David Woolley
>            Severity: Minor
>
> We backported MixMonitorMute to 1.6.1 and found a problem that, according to my code reading still exists in the 1.8 branch SVN version, namely that, if the codec is already slinear, using MixMonitorMute causes the orignal media stream to be silenced, as well as the monitored stream.
> We are using MixMonitor on queues.  If the incoming call on the queue arrives from a normal channel (in our case a local channel instantiated from a normal channel), MixMonitorMute works correctly, and replaces the audio on the recording by an equivalent period of silence.
> If the call on the queue is initiated by AMI Originate (again via a local channel), the through media in both directions is also replaced by equivalent silence.  For the avoidance of doubt, these are frames containing silence, not the absence of frames.
> MixMonitorMute is applied in both directions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira