|Summary:||ASTERISK-18863: Call hang-up when issuing "mixmonitor start" just after "bridge" through AMI|
|Reporter:||Fabrice CAHEN (cahen)||Labels:|
|Date Opened:||2011-11-14 11:47:13.000-0600||Date Closed:||2011-11-15 10:26:06.000-0600|
|Environment:||Linux 2.6 amd64||Attachments:|
|Description:||A software connected through AMI issues the following commands :|
- Bridge (bridging 2 channels coming from a trunk)
- Command (mixmonitor start <channel> <filename>,a)
When those 2 commands are issued one after the other, Asterisk hang-up the mixmonitored channel (and the bridged channel also).
But, introducing a 500ms delay between "Bridge" and "mixmonitor start" commands works better...
...But loosing 500ms of call-recording
Note that when having the same situation, but with one channel coming from a trunk, and the second one from a sip phone (mixmonitor on the sip-phone channel), the problem doesn't occur.
|Comments:||By: Matt Jordan (mjordan) 2011-11-15 09:11:52.799-0600|
Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions. After testing with Asterisk 1.8, if you find this problem has not been resolved, please change the version of the bug against Asterisk 1.8.
By: Fabrice CAHEN (cahen) 2011-11-15 09:23:59.334-0600
Unfortunately, switching to 1.8 is too much work right now, and we do not have enough ressources to rewrite our softwares for 1.8.
This is planned for next summer...
I've found a quick & dirty workaround, which is to wait for the "Bridge" event subsequent to the "Bridge" AMI command, and which AFAIK occurs once the bridge/masquerade operations are all completed, then send the mix monitor command...
This gives me good results.
By: Matt Jordan (mjordan) 2011-11-15 10:25:45.717-0600
Good to hear. For now we will close this issue; however, once you've transitioned over to 1.8 if the same behavior exists, please feel free to reopen the issue against 1.8.