I'm using latest 1.8, althought I did check and this behaviour is the same since 1.6.2.11. I will file a bug report about it in 1.8.17.0. Auto Mixing would not bother me, i will check the Mix monitor.
Regards. 22 paź 2012 17:22, "Jonathan Rose" <jr...@digium.com> napisał(a): > Grzegorz Pycia wrote: > > Hi > > > > I have some problem with monitor application when call i transferred > > in > > attended mode and the transfer occurs before call is answered. > > > > Here is how it looks: > > > > A calls ----> B(let's assume ${UNIQUEUEID}=1) > > > > exten => _XXXX,1,NoOp > > seme => n,Set(MONITOR_FILENAME=call-${UNIQUEID}) > > same => > > n,monitor(alaw,/var/spool/asterisk/monitor/${MONITOR_FILENAME},bm) > > > > When B answers the call, files call-1-in* and call1-out* are created. > > During The call, B tries to make attended transfer A is put on hold > > and > > B calls C using the same dialplan logic: > > > > B calls ----> C(let's assume ${UNIQUEUEID}=2) > > > > At the time off invoking monitor application none off the call-2 > > channels are monitored so the monitor application starts without > > errors, > > if B waits till C answers, everything is OK monitor starts recording > > and > > files call-2-in* and call-2-out* are created, When B transfers the > > call > > call-2 monitor is stopped. And call-2 files contain only the call > > between B and C. > > > > But there is problem when B does not wait until C answers the call, > > if > > transfer is done before C answers the call, the call-2* are not > > created > > and the call is still recorded to the call-1* files, but when the > > transferred call between A and C ends, the call-1* files get renamed > > to > > call-2* and the MONITOR_EXEC application is called with call-2* file > > names as parameters. > > > > This makes it impossible to locate the call record since the file > > names > > get changed, can someone tell if I should file a BUG report or is it > > intended to act like this? > > > > Regards > > Are you using Asterisk 1.8 or higher? A good way to mitigate this > would be to use MixMonitor. It applies as an audiohook which should > persist through transfers like the one you described, so you would > just need to set AUDIOHOOK_INHERIT for MixMonitor in order to use it > that way. One difference with this approach though would be that > MixMonitor will automatically mix audio from both ends of the call > into a single recording. That behavior can be worked around starting > with Asterisk 10 by using the r and t options. > > I guess it's worth noting that if you aren't using 1.8 or higher > there isn't really any point in filing a bug report since earlier > versions aren't supported anymore. > > -- > Jonathan R. Rose > Digium, Inc. | Software Engineer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US > direct +1 256 428 6139 > > Check us out at: http://digium.com & http://asterisk.org > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users