<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 27, 2018 at 1:29 PM, Richard Mudgett <span dir="ltr"><<a href="mailto:rmudgett@digium.com" target="_blank">rmudgett@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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_he<wbr>lper 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></span><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_<wbr>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_<wbr>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(<wbr>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(<wbr>chan)) {<br></div><div>+ ast_channel_set_unbridged_<wbr>nolock(chan, 1);<br></div><div>+ }<br></div><div> }<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Richard<br></div></font></span></div><br></div></div></blockquote><div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">I added the lines in almost the exact same spot in my res_monitor.c file, and we ran<br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">it 28 times with perfect recordings. Then we ran a set of 110 tests with perfect recording<br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">results, where normally we would see about 45% of the recordings would be empty.<br><br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">Now, we have put the new code on a few production machines, and we will test <br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">a couple days more before distributing to all our systems.<br><br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">As to add this instead to ast_channel_monitor_set, this is an intriguing idea. I will see if<br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">it still works with the same efficacy on our servers. I need to know more about the situations<br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">where it will prevent null recordings.<br><br></div><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">murf<br></div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Steve Murphy<br>✉ murf at parsetree dot com<br></div></div></div></div></div></div></div></div>
</div></div>