[asterisk-users] monitor application, file name change on attended transfer

[Grzegorz Pycia]

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" <jrose at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121022/d49a7824/attachment.htm>