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

[Fettahlioglu, Mahmut]

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