Waldo,
Thanks for the information. If you don't mind answering: are you guys
developing this solution for your internal needs (meaning serving UAs
from within your enterprise) or are you planning on offering services
to the public?
This solution is being developed for our internal needs.
Matt,Thanks for the information. If you don't mind answering: are you guys developing this solution for your internal needs (meaning serving UAs from within your enterprise) or are you planning on offering services to the public?It's not that I'm really interested in your business or business
Hello Matt,
very interesting setup! are you using asteriak queues for inbound or not
at all?
Bye
l.
In data Thu, 22 Sep 2005 06:25:44 +0200, Matt Florell [EMAIL PROTECTED]
ha scritto:
We wrote VICIDIAL(part of the GPL astGUIclient suite
http://astguiclient.sf.net) for our call center
On Sep 21, 2005, at 1:46 AM, Zoa wrote:
True... But i tried several brands of cards, and several drivers, the
dual nic gigabit intel card was a lot better than all the other
combinations i tried.
Fun fact: short of buying a 10gigE card, your best performance will
probably be from a cheap
Hi Matt,Is your solution 100% Asterisk or are you using other "helpers" such as SER or XXXproxy or whatever?Thanks,WaldoOn Sep 21, 2005, at 12:45 PM, Matt Roth wrote:All, This message has generated a lot of responses, so I'm going to address each of them here in an attempt to consolidate the
We are 100% Asterisk on the VOIP side. We use SIP, IAX and Zap(channelbanks) for phones and Zap T1s for telco termination.
MATT---On 9/22/05, Waldo Rubinstein [EMAIL PROTECTED] wrote:
Hi Matt,Is your solution 100% Asterisk or are you using other helpers such as SER or XXXproxy or
- The reason i recommended you to use a ramdisk is because i think the
- problem with recording to disk is saving 20ms of stream 1, then 20 ms of
- stream 2, then 20ms of stream 3 etc etc meaning you write everytime
- very small things. (with a lot of seeking).
I was thinking about
Hi everyone,
This is just another attempt to address everybody in one place and
consolidate the thread.
Zoa,
- I think its the best you can do.
If something pops into your head, even if it's off the wall, don't
hesitate to share
On 9/22/05, Matt Roth [EMAIL PROTECTED] wrote:
Matt,- Have you tried recording directly to GSM format? It will help reduce the
- bottleneck on disk IO although it will use more CPU cycles(in your case- on a RAM drive this may not help at all)We don't want to do any transcoding on the Asterisk
Hey ho,
I suppose you are the person from the digium forum :)
The reason i recommended you to use a ramdisk is because i think the
problem with recording to disk is saving 20ms of stream 1, then 20 ms of
stream 2, then 20ms of stream 3 etc etc meaning you write everytime
very small things.
On Wed, 2005-09-21 at 10:07 +0300, Zoa wrote:
The reason i recommended you to use a ramdisk is because i think the
problem with recording to disk is saving 20ms of stream 1, then 20 ms of
stream 2, then 20ms of stream 3 etc etc meaning you write everytime
very small things. (with a lot of
Also when you do things over the network, disable your onboard network
card, and go for some more expensive network card.
In our tests with small packets, we could increase the throughput with a
factor 2. (related to cpu load).
Zoa.
--
www.asteriskguru.com
trixter
On Wed, 2005-09-21 at 11:11 +0300, Zoa wrote:
Also when you do things over the network, disable your onboard network
card, and go for some more expensive network card.
In our tests with small packets, we could increase the throughput with a
factor 2. (related to cpu load).
I wonder how much
True... But i tried several brands of cards, and several drivers, the
dual nic gigabit intel card was a lot better than all the other
combinations i tried.
zoa
trixter http://www.0xdecafbad.com wrote:
On Wed, 2005-09-21 at 11:11 +0300, Zoa wrote:
Also when you do things over the network,
All,
This message has generated a lot of responses, so I'm going to address
each of them here in an attempt to consolidate the thread.
Matt,
- I'm very interested in the specifics of your setup.
- How much space is on the RAM
In light of the I/O bottleneck problem I'd have to ask why asterisk
can't just buffer incoming audio and then flush a complete audio file to
disk.. I'm assuming that recordings vary in length.. the problem with
this idea is what happens if 50 recordings all complete at the same
time.. a dump
I would think memory would be the limiting factor. A 3-4 minute wav
file is what, 30Meg or so? And there is one for each end of the call,
so that's 60Meg. Now let's say it's a 15 minute call and then are 10 of
them at once. That's 30Meg x 5 (5 times the length of my estimate) x 2
(each
The problem is that then it won't work on systems with little memory. 50
streams would eat memory like crazy.
Zoa
Matt Hess wrote:
In light of the I/O bottleneck problem I'd have to ask why asterisk
can't just buffer incoming audio and then flush a complete audio file
to disk.. I'm assuming
It's true that the average Asterisk implementation doesn't have enough
RAM, but we are replacing a legacy NorTel switch in a call center. If
you look at the cost of traditional PBXs, the cost of additional memory
starts to look a little better. = )
Now for some quick math:
1 minute of PCM
I think its the best you can do.
Maybe there should be some option to be set for the monitor command to
buffer, with a warning that it will eat memory.
Its also not needed to buffer the complete call at once, just buffering
and writing to disk every 10 seconds would already be a big
On 9/21/05, Matt Roth [EMAIL PROTECTED] wrote:
- What format are you recording to?- What codec are the SIP calls being placed over?
We are recording to the PCM format and using the G711 uLaw codec.Highvoice quality is essential to our application (we are a call center) sowe partnered with MCI to
On 9/21/05, Matt Florell [EMAIL PROTECTED] wrote:
We have sevaral call centers as well, and we just restrict a single server
to 50 recordings at once and then we would pass the next recording as an
IAX2 channel to another recording server. It's a scalable system for us that
is relatively
On 9/21/05, izo [EMAIL PROTECTED] wrote:
On 9/21/05, Matt Florell [EMAIL PROTECTED] wrote:We have sevaral call centers as well, and we just restrict a single server to 50 recordings at once and then we would pass the next recording as an
IAX2 channel to another recording server. It's a scalable
List users,
Over the last few days we have been working with MCI's development lab
to test our Asterisk setup. We were using a piece of hardware called an
Abacus 5000 that is capable of creating and terminating thousands of SIP
calls. Initially, we could not get past 64 simultaneous
On Tue, 2005-09-20 at 18:37 -0400, Matt Roth wrote:
List users,
Over the last few days we have been working with MCI's development lab
to test our Asterisk setup. We were using a piece of hardware called an
Abacus 5000 that is capable of creating and terminating thousands of SIP
calls.
Patrick wrote:
On Tue, 2005-09-20 at 18:37 -0400, Matt Roth wrote:
List users,
Over the last few days we have been working with MCI's development lab
to test our Asterisk setup. We were using a piece of hardware called an
Abacus 5000 that is capable of creating and terminating thousands of
Patrick,
Thank you for your suggestions.
Our initial runs were recording directly to an NFS mount and they
experienced the same problems as recording to the local disk. In our
final setup, the copy will be done to an NFS mount as long as it
exists, falling back to local disk only when the
On 9/20/05, Matt Roth [EMAIL PROTECTED] wrote:
Patrick,
Thank you for your suggestions.
Our initial runs were recording directly to an NFS mount and they
experienced the same problems as recording to the local disk. In our
final setup, the copy will be done to an NFS mount as long as
28 matches
Mail list logo
