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

[Steve Murphy]

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?

murf


-- 

Steve Murphy
✉  murf at parsetree dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180323/226dc59e/attachment.html>