With 726,  729 or ILBC 60-70 calls will be reasonable. Also, probably if all
the music on hold and system voicemail recordings were converted to your
used codec beforehand and the apps modified a bit, it would help alot and
you could push it up a bit. I don't know much about how voicemail or moh
work in asterisk so I could be totally wrong here. But it's a thaught.

Mike, with GSM for sure 100 calls on your server would be possible. Even
with the robo effects it would be more consistent than g729, quality wise.

And definitely Leif,  you won't be able to max out your channels with those
specs.

G729 doesnt suck its amazing, its the asterisk and most cheap phone and ATA
(specially linksys) implementations that are really bad. If you have a g729
call on a cisco or polycom phone using corporate soft switches it will sound
very lively and not dead like GSM. Packet losses really affect G729 much
more than other codecs as well. On the other hand ILBC is amazing with
asterisk, too bad most phones don't support it. (But most good softphones
do)

--------
Shidan


On 3/17/06, Mike Ashton <[EMAIL PROTECTED]> wrote:
>
> First question would be what is the customers quality expectation. If it
> is to use for business and not always sound like VOIP G729 won't cut it.
>
> The other issue with G729 that I have found is DTMF. We do a lot of DTMF
> transmission during the call and have had nothing but headaches. By going to
> uLaw and dtmfmode=auto that issue went away. Seems issue is that some where
> along the line, when the calls were going from 729 to ulaw for termination
> they wanted inband ( which doesn't work in 729 as far as I can tell) and the
> outofband either wasn't being passed or utilized to insert into the inband
> stream.
>
> Just to give you heads up it seems to be in the termination end and from
> our experience happens in Alberta and the east coast. US and Ontario never
> really had a problem.
>
> Only other possibility which I haven't played with yet is 726, but looks
> promising. From what I've read quality is there, and half the bandwidth of
> ulaw. Just don't see a ton of support in devices. But since your controlling
> the 2 end points and not using SIP hardware ( I've not seen any phones w 726
> support ) it could give the quality, a compromise on bandwidth and
> transcoding overhead is a lot less then 729.
>
> My main server is a dual xeon 2.4 GHz, 1GB ram, w SATA Raid 0+1 (
> 4x120GB), with 5 concurrent calls in as 729 transcoding to ulaw and
> recording the calls as wavs was taking about 7% CPU utilization (fluctuates
> between 5.5-7.9). I think fluctuation peaks are due to  IO bursts. At
> idle  system utilizes 0.2% CPU. We're anticipating that this server should
> be able to handle 60-70 concurrent calls with recording enabled (will be
> hitting limits CPU or Disk) or , but will probably in reality only have
> 30-40. We're just waiting on some other software to finish development
> before ramping it up.
>
> Hope some pieces of my ramblings are of use.
>
> Mike
>
> Ian Service wrote:
>
> What do you mean by horrible?  CPU-wise, quality-wise?  Just curious,
> because I got my licenses all set up a while back and found the call quality
> wasn't great and blamed my endpoints, but could it have been asterisk's
> fault?  Should g729 sound almost as good as ulaw?
>
> - Ian
>
> On 3/17/06, Shidan <[EMAIL PROTECTED]> wrote:
> >
> > Dude I thaught the diagram was reversed. Do you really have to go out
> > thru your G729 provider, if you tell me where your gateway is, im sure you
> > can find someone tier-1 voip who
> > terminates close to your gateway striaght ulaw. G729 is absolutely
> > horrible with asterisk.
> >
> > ----
> >  Shidan
> >
> >
> > On 3/17/06, Leif Madsen <[EMAIL PROTECTED]> wrote:
> > >
> > > On 3/16/06, Leif Madsen <[EMAIL PROTECTED]> wrote:
> > > > I need to take 4x T1's into an Asterisk box (92B + 4D) and transcode
> > >
> > > > them from G.711 (ulaw) to G.729, terminating via SIP. I've been at
> > > VON
> > > > this week in SJ, talking to the Digium guys, and opinions seem to
> > > > hover around a box with 2x Intel Xeon CPUs running at 3.0GHz or
> > > > higher.
> > >
> > > Just as some added information, which doesn't really affect the
> > > original question, but will help you visualize the topology I'm
> > > dealing with. The box will be sitting at a customers side and acting
> > > as a "transcoding gateway". The customer will be the one filling the
> > > physical T1 ports with their equipment, where the streams will be
> > > transcoded by Asterisk to G.729, then sent via SIP to my gateway
> > > servers where I will terminate his traffic to the PSTN.
> > >
> > > Customer -- [4x T1 ( G.711)] --> Asterisk -- [SIP (G.729)] -->
> > > Internet
> > > --> GW --> PSTN
> > >
> > > Hope that helps clear up any confusion as to how this is being
> > > implemented.
> > >
> > > This also allows me to bring up another part of the scenario -- have I
> > >
> > > calculated correctly that with all protocol overhead (SIP, RTP, UDP,
> > > IP + codec media) that I'm looking at around 2.12 Mbps of databit rate
> > > for all 92 simultaneous G.729 calls?
> > >
> > > --
> > > Leif Madsen.
> > > http://www.leifmadsen.com
> > > http://www.oreilly.com/catalog/asterisk
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> ------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.2.4/282 - Release Date: 3/15/2006
>
>
>
> --
> Mike Ashton
>
> Quality Track Intl
>
> Ph:   647-722-2092 x 251
> Cell: 416-527-4995
> Fax:  416-352-6043
>
> QTI CONFIDENTIAL AND PROPRIETARY INFORMATION
>
> The contents of this material are confidential and proprietary to Quality 
> Track  International, Inc.
> and may not be reproduced, disclosed, distributed or used without the express 
> permission of an authorized representative of QTI.
> Use for any purpose or in any manner other than that expressly authorized is 
> prohibited.
> If you have received this communication in error, please immediately delete 
> it and all copies, and promptly notify the sender.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>

Reply via email to