asterisk users - Apr 2003 - RE: [Asterisk-Dev] Several patches, including recording and music -on-hold

Mahmut, excellent summary :-).  I look forward to your next update.
One little thing,
In the manager events that show start/stop monitoring, can you please include a
field
that indicates the filename(s) to which the monitoring was written?
Thanks,
Ben

-----Original Message-----
From: Fettahlioglu, Mahmut [mailto:Mahmut.Fettahlioglu@oa.com.au]
Sent: Tuesday, April 15, 2003 5:17 AM
To: 'asterisk-users@lists.digium.com'
Subject: RE: [Asterisk-Users] RE: [Asterisk-Dev] Several patches,
including 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
> 
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users

I've reviewed the mailing list archives for all hangup detection posts
(numerous) and have tested all kinds of configurations to no avail.

I have two POTS lines using loop start. One is patched straight from my wall
jack to the X100P card in my asterisk box. The second one plugs into an fxo
port on a carrier access bank 1 channel bank (12 fxo, 12 fxs) which is
plugged into a T100P card in the same asterisk box. Channels 1-12 are fxo,
13-24 are fxs, and 25 (X100P) is fxo.

When I plug either POTS line into the X100P, dial in from the outside, and
leave myself a voicemail, hangup detection occurs correctly about 20 seconds
after I hang up. It sucks but at least it works somewhat. However, when I
plug either POTS line into the channel bank, dial in from the outside, and
leave myself a voicemail, hangup detection never occurs. When I hang up and
the channel bank keeps the line open, my telco provider gives a fast-busy
signal that gets captured in the voicemail until the max voicemail size is
reached.

I've tested fxo ports configured as loopstart and kewlstart but neither
configuration seems to correct the situation. I've also tried every
combination of busydetect=yes and callprogress=yes commented out and left in
and nothing seems to correct the situation. I think busydetect is supposed
to work as a last resort, but something about the cadence of the fast-busy I
get from my telco provider doesn't get caught by the busydetect code.

I checked my channel bank dip switches to ensure the fxo ports are set to
loopstart and they are. I'm using the latest cvs code as of midnight.

If the change in CO loop current is sufficient to let the X100P know it got
hung-up, why wouldn't my channel bank/asterisk sense the same change in loop
current to detect the hangup? Alternatively, If the X100P is detecting
hangup via the last resort busydetect, why wouldn't the same cadence on my
channel bank fxo port trigger busydetect as well? It's interesting that even
when I physically disconnect the channel bank fxo port from the CO wall jack
in mid-call, asterisk and the channel bank still don't see a hangup. The
channel bank LED continues to show off-hook indefinitely.

Is anyone else using a T100P card with a CAC Access Bank channel bank? I
don't know what else to try.

Please help.

Dave Carr

On 2003-04-16 at 01:05, David Carr (dac1@drgutah.com) wrote:
> when I plug either POTS line into the channel bank, dial in from the
> outside, and leave myself a voicemail, hangup detection never occurs.
No setting in asterisk will help you here.  This is a defect or
mis-setting of your channel bank.  The channel bank needs to detect the
hangup, and then it will send the right signal (usually via A & B bits)
to asterisk.

Call the company that makes the channel bank and see if they can help
you with this.  Alternatively, get your lines converted to ground
start.  It appears the X100P does not support ground start, so if you
need to make outgoing calls on these lines, they would need to go
through the channel bank.