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
-- _____________________________________________________________________ -- 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
