[Asterisk-Dev] Re: Asterisk-Dev Digest, Vol 4, Issue 58

[Darren Sessions]

> Message: 3
> Date: Wed, 24 Nov 2004 09:02:23 -0600
> From: Steven Critchfield <critch at basesys.com>
> Subject: Re: [Asterisk-Dev] Perl AGI + MySql Audio
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <1101308543.3574.31.camel at critch>
> Content-Type: text/plain
> 
> On Wed, 2004-11-24 at 09:42 -0500, Darren Sessions wrote:
>> Steve - Is it your goal in life to be a jerk? - it's all I've ever seen come
>> out of your mouth. Just wondering. Maybe it's that big "I think I know it
>> all" head of yours.
> 
> Maybe you should remove your ego from the equation for a second and
> realize I don't give a shit about what you think. I give you advice
> based on experience and good database design.
> 

No ego - just not much for getting flamed by one person all the time.

>> In any case...
>> 
>> Here is the situation. I have a 4 asterisk servers and one database/storage
>> server. When a call comes in (forwarded from one of my SER servers) to one
>> of the servers, no matter which one, it has to be able to pull unique
>> customer information (audio files etc.).
> 
>> All the servers have 1000BaseT network connectivity.
>> 
>> NFS is problematic because if the server dies, it seems to lock up the
>> clients until it starts responding again.
> 
> Don't you get the EXACT same problem if your DB goes down? You have the
> exact same problematic issue and fewer tools to deal with a DB crash
> that corrupts your data.
> 

The database is clustered.

>> The "Database/Storage" server has over 4GB of ram, 14x146GB 10k hard drives,
>> and a high end RAID controller - so speed really isn't an issue just yet.
> 
> But the efficiency of a DB transfer of files or a NFS transfer of files
> will be significant. You do have a nice subsystem there though.
> 

I see what you're saying. I think I'm screwed no matter which way I do it -
just trying to go after the method that doesn't screw me as hard.

>> The logical choice was to use a database to store the audio files - that's
>> all that server would be doing essentially. We've got a quad processor box
>> to do real DB stuff. But... It makes sense to have the ability to pull the
>> audio data in a variable. With the WAV49 format, the byte count is much
>> lower (obviously) than standard wav files and it still retains compatibility
>> if I mail an audio file to a customer.
> 
> Maybe you need to look at coding a C app for asterisk instead of an AGI.
> You can then stuff raw audio frames into the stream and not worry as
> much about from where.
> 
> -- 
> Steven Critchfield <critch at basesys.com>

I'm just learning C. I understand the concepts, but can't code anything
beyond basic stuff yet. I'm still not as familiar with *'s internal code and
the nuts and bolts of how * does RTP to do anything near stuffing raw audio
frames.

- Darren