asterisk users - Oct 2012 - monitor application, file name change on attended transfer

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

Hi,

You are using b flag in monitor command. This means don't begin recording
untill call is bridged.
So what you get if you delete this flag ? 


// Binan


________________________________
 Fr?n: Grzegorz Pycia <grzegorz.pycia at thulium.pl>
Till: asterisk-users at lists.digium.com 
Skickat: l?rdag, 20 oktober 2012 23:49
?mne: [asterisk-users] monitor application, file name change on attended
transfer
 
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

--
_____________________________________________________________________
-- 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/20121021/ca865bdd/attachment.htm>

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