[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] ast_monitor_start has no effect.... sometimes
From: Steve Murphy <murf () parsetree ! com>
Date: 2018-03-29 3:00:14
Message-ID: CAPPCp8Hwb-+-kBqp_wVuFbrF9u2ezUp9cQSbwMEf9XoU1BJN2A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Mar 27, 2018 at 1:29 PM, Richard Mudgett <rmudgett@digium.com>
wrote:
>
>
> On Fri, Mar 23, 2018 at 3:00 PM, Steve Murphy <murf@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
>
> I added the lines in almost the exact same spot in my res_monitor.c file,
and we ran
it 28 times with perfect recordings. Then we ran a set of 110 tests with
perfect recording
results, where normally we would see about 45% of the recordings would be
empty.
Now, we have put the new code on a few production machines, and we will
test
a couple days more before distributing to all our systems.
As to add this instead to ast_channel_monitor_set, this is an intriguing
idea. I will see if
it still works with the same efficacy on our servers. I need to know more
about the situations
where it will prevent null recordings.
murf
--
Steve Murphy
✉ murf at parsetree dot com
[Attachment #5 (text/html)]
<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>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic