[Asterisk-Users] RE: [Asterisk-Dev] Several patches, including recording and music -on-hold

[Benjamin Miller]

Mahmut,
First of all, I'd like to reiterate what a great patch this has been.
I'd also like to voice support for having an option to mix the files on
the fly, and name them uniquely.  While I was able to smoothly put the
files together with soxmix, I see on the fly mixing as hugely beneficial
to an automated solution to saving/delivering the messages without
intervention.

One feature, that would be very useful (and hopefully trivial) to add
would be to send a manager event when monitoring is started on a channel
and then when it is stopped.  This would allow external threads to do
things like send the recording to a user via e-mail or auto-delete it if
the end user does not want it.

On one other note.  I was testing the monitoring thread and it seems to
die when a call is parked.  All other transfer's etc, work fine, but
when I had the call parked, the recording ended.  I know call parking
does a masquerade, so I don't know if this is fooling the monitoring
thread into thinking the call has ended or what.  I just thought I'd
mention it for you to possible look into.

Thanks again for this great addition.
Ben


-----Original Message-----
From: Fettahlioglu, Mahmut [mailto:Mahmut.Fettahlioglu at oa.com.au] 
Sent: Monday, April 14, 2003 7:23 AM
To: 'asterisk-users at lists.digium.com'
Cc: 'weppler at wwworks-inc.com'
Subject: RE: [Asterisk-Users] RE: [Asterisk-Dev] Several patches,
including recording and music -on-hold


Hi Wade,

Sorry for replying so late. I had been sucked into other tasks for a
while and only now can catch up with the list.

> When I dial my iaxtel number from my extension on channel
> Zap/15, I get two
> files recorded in /var/spool/asterisk/monitor:
> 
> Zap-15-1-in.wav and Zap-15-1-out.wav and they sound fine.
> 
> When I dial again, it overwrites the same two files.  A nice
> option would be
> to append to the current files (with an audible *break*), or 
> create another
> unique filename (timestamp?).  I realize the latter could be done with
> variables and the former could be done with AGI, but it might 
> be nice to
> have it part of the Monitor resource?

The reason I was using channel names for file names was to make file
names as unique as possible. In my setup I only used SIP and IAX which
generate unique channel names as long as asterisk is not restarted. This
is apparently not the case for Zap channels.

Appending to the files to solve the issue doesn't sound very right,
individual recordings will not be easily accessible this way. I think
the timestamp approach is pretty good. Maybe having an option for the
Monitor resource that causes the files to be renamed to
channelName_recordStartTime_recordStopTime can be used for this?
Variables could be used for having start time in file names, but the
resource itself will need to support it if we want to put stop time as
well.
 
> It would also be great to see only one file.  A mix can be
> done later, but
> it looks like the two files start and stop at different times 
> so it would be
> pretty tough to sync the two files up after the fact.  
> Another option might
> be a logfile with start/stop times of each file to assist 
> with syncing?  The
> times would have to be pretty accurate (at least within 
> milliseconds) to
> work well...

What I experienced is unless silence suppression is used by one of the
endpoints (I know MS Messenger has silence suppression to name one), the
files sync very easily and accurately using something like soxmix.

Initially I was testing with MS Messenger, and what I ended up doing was
writing voice packets to specific positions in the files calculated from
packet receive times. The rest were filled with silence characters. I
saw, however, that this results in a poorer file quality if the
endpoints do not use silence suppression. In these cases the output
files, depending on voice packet arrival times, sometimes had silences
inserted between voice packets, causing audible glitches. It is likely
that these silence regions will be less in the mixed output file, but
some of them will possibly be left. So I #ifdef'ed out this code. Maybe
repeating the last value received rather than writing silence characters
could have produced a better result.

I think it is quite sensible to optionally have the logfiles you are
suggesting, and having the Monitor mix files by itself using these log
files. This would be optional so we do not lose the ability to have
single direction files which can be useful as well. I think these
changes will probably take 1 day or so. Currently I am working towards a
quite tight deadline and will not have much time in the next couple of
weeks, but if there is interest I would be happy to make these changes
later in my own time. 

> 
> I haven't tried it yet, but when recording a meetme
> conference, there are
> probably a set of files for every incoming channel.  Syncing 
> those up into a
> single WAV could be a serious nightmare.  ;)

This record funtionality in Monitor is geared towards recording a single
channel, not recording what an application plays to all the channels. I
think the easiest way to record a conference is to have the Meetme
application record its output itself. In the channel based approach of
the Monitor resource, you would need to record all the participant
channels and mix them later somehow, probably using some external
application which takes into account different joining and leaving
times, etc.

Cheers

Mahmut
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users