Fettahlioglu, Mahmut
2003-Apr-15 03:17 UTC
[Asterisk-Users] RE: [Asterisk-Dev] Several patches, includin g recording and music -on-hold
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@dccinc.com] > Sent: Tuesday, 15 April 2003 1:12 > To: asterisk-users@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@oa.com.au] > Sent: Monday, April 14, 2003 7:23 AM > To: 'asterisk-users@lists.digium.com' > Cc: 'weppler@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@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users >
Seemingly Similar Threads
- RE: [Asterisk-Dev] Several patches, including recording and music -on-hold
- RE: [Asterisk-Dev] Several patches, including recording and music -on-hold
- RE: [Asterisk-Dev] Several patches, includin g recording and music -on-hold
- Asterisk left in a bad state
- Re: Asterisk-Users digest, Vol 1 #286 - 14 msgs