<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 23, 2018 at 3:00 PM, Steve Murphy <span dir="ltr"><<a href="mailto:murf@parsetree.com" target="_blank">murf@parsetree.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Hello--<br><br></div><div style="font-family:arial,helvetica,sans-serif">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.<br><br></div><div style="font-family:arial,helvetica,sans-serif">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.<br><br></div><div style="font-family:arial,helvetica,sans-serif">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_<wbr>helper chooses ulaw,  and the simple_bridge technology is started.<br></div><div style="font-family:arial,helvetica,sans-serif"> 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.<br><br></div><div style="font-family:arial,helvetica,sans-serif">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)<br><br></div><div style="font-family:arial,helvetica,sans-serif">Is there something I need to do to get the bridge into simple_bridge tech when we start the monitor?<br></div></div></blockquote><div><br></div><div>This is a bug with res_monitor.  Please file an issue.<br><br>The ast_monitor_start() function needs to check if the channel is in a bridge after it has set the monitor <br>structure on the channel and set the unbridged flag to have the bridging system reevaluate the bridge <br>technology.<br><br>In res_monitor.c:ast_monitor_start():<br><br>  ast_channel_monitor_set(chan, monitor);<br>  ast_monitor_set_state(chan, AST_MONITOR_RUNNING);<br>+<br>+ if (ast_channel_is_bridged(chan)) {<br>+     ast_channel_set_unbridged_nolock(chan, 1);<br>+ }<br>+<br>  /* so we know this call has been monitored in case we need to bill for it or something */<br>  pbx_builtin_setvar_helper(chan, "__MONITORED","true");<br><br></div><div>MixMonitor does not have this problem.  When MinMonitor attaches its audiohook <br>existing code that I've added above for Monitor causes the bridge to reevaluate.<br></div><div><div><br>I think a better place is in channel_internal_api.c instead as it will happen for starting, stopping,<br></div><div>and masquarading channels with monitor:<br><br>  void ast_channel_monitor_set(struct ast_channel *chan, struct ast_channel_monitor *value)<br>  {<br>      chan->monitor = value;<br></div><div>+     if (ast_channel_internal_bridge(chan)) {<br></div><div>+        ast_channel_set_unbridged_nolock(chan, 1);<br></div><div>+     }<br></div><div>  }<br><br></div><br></div><div>Richard<br></div></div><br></div></div>