[asterisk-dev] ast_monitor_start has no effect.... sometimes

[Richard Mudgett]

On Fri, Mar 23, 2018 at 3:00 PM, Steve Murphy <murf at parsetree.com> wrote:

> Hello--
>
> I guess I have a weird situation, in that we use a separate process to
> turn on call recording for a channel. It gets bridge join events via AMI
> and send a StartMonitor action via AMI back to asterisk.
>
> The trouble is, that depending on the machine, the phase of the moon, and
> who knows what else, the request takes longer cometimes, and the
> ast_monitor_start has no effect.
>
> On a good day, the channels are both Locally RTP bridged, and the
> native_rtp technology is started, the res_monitor start comes in and then
> "switching from native_rtp to simple_bridge gets done, I see both channels
> put in a dummy bridge, the native_rtp is stopped, the
> ast_channel_make_compatible_helper chooses ulaw,  and the simple_bridge
> technology is started.
>  I see 3 more messages about "Bridge xxxxx is already using the new
> technology (simple_bridge), and I see __ast_read() copying packets into the
> recording files.
>
> On a bad day, I see the channels are both Locally RTP bridged, and the
> native_rtp technology is started. I see the "Bridge xxxxx is already using
> the new technology (native_rtp) twice, then the __ast_monitor_start is run,
> and that's it. The packets are forwarded without any __ast_read() calls,
> and no packets are copied to the recording files. (They are in WAV format,
> with only the 60-byte header in the files)
>
> Is there something I need to do to get the bridge into simple_bridge tech
> when we start the monitor?
>

This is a bug with res_monitor.  Please file an issue.

The ast_monitor_start() function needs to check if the channel is in a
bridge after it has set the monitor
structure on the channel and set the unbridged flag to have the bridging
system reevaluate the bridge
technology.

In res_monitor.c:ast_monitor_start():

  ast_channel_monitor_set(chan, monitor);
  ast_monitor_set_state(chan, AST_MONITOR_RUNNING);
+
+ if (ast_channel_is_bridged(chan)) {
+     ast_channel_set_unbridged_nolock(chan, 1);
+ }
+
  /* so we know this call has been monitored in case we need to bill for it
or something */
  pbx_builtin_setvar_helper(chan, "__MONITORED","true");

MixMonitor does not have this problem.  When MinMonitor attaches its
audiohook
existing code that I've added above for Monitor causes the bridge to
reevaluate.

I think a better place is in channel_internal_api.c instead as it will
happen for starting, stopping,
and masquarading channels with monitor:

  void ast_channel_monitor_set(struct ast_channel *chan, struct
ast_channel_monitor *value)
  {
      chan->monitor = value;
+     if (ast_channel_internal_bridge(chan)) {
+        ast_channel_set_unbridged_nolock(chan, 1);
+     }
  }


Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180327/f92ee3d4/attachment.html>