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

Tue Apr 15 03:17:19 MST 2003

Thanks Ben, Adam and Petr for the feedback!

So currently things that need to be done for the Monitor resource are:

1. Name files uniquely. Adam, your naming suggestion is great. I think we
should stick with that, with a minor change: I don't think we should put
destination channel name in the file names. In some instances there will be
no destination channels (plain IVR: play, record, dtmf), or there will be
more than one destination channels (call transfer, etc.). So I suggest using
<start-date>.<start-time>.<end-date>.<end-time>.<channel>.<file-suffix>

2. Add an option to have mixing done automatically. Possibly use log files
as suggested by Wade to help the mixing process.

3. Generate manager events for monitoring start/stop. That should be very
easy to add.

4. Investigate and fix why monitoring does not continue after a call is
parked.

As for solving the conference issue, because of the way monitoring works,
everything "heard" by a channel is recorded. So your solution would already
work Adam: recording a single channel would record the conference as well,
while this channel is in the conference.

Cheers

Mahmut
> -----Original Message-----
> From: Benjamin Miller [mailto:BGMiller at dccinc.com]
> Sent: Tuesday, 15 April 2003 1:12
> To: asterisk-users at lists.digium.com
> Subject: RE: [Asterisk-Users] RE: [Asterisk-Dev] Several patches,
> including recording and music -on-hold
> 
> 
> 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
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> 