[asterisk-users] My Phone Review- Large Scale Corp Deployment.

[RR]

On 11/8/06, Steve Edwards <asterisk.org at sedwards.com> wrote:
> All calls come in from a Tekelec 7000 via SIP.
>
> Out of a peak of 200 calls, probably around 100 are in meetme, others are
> listening to recorded messages or bouncing around in the menus.

Sounds exactly like what people in my system would be doing.

>
> No OS tweaks, no Asterisk source tweaks.
>
> A TE410p is used as a timing source. The sound quality was not acceptable
> with ztdummy.

Aha, so that's something I don't have and most prob. can't have (no
empty PCI slots left on the 1U servers). Hmmm maybe that might make
the difference between how many conferences my boxes will handle
before it starts to sound bad!

> I stripped down /etc/asterisk/modules.conf just 'cause "parts left out
> don't get broken" :)

Agreed, I have even removed non-used conf files so the size of (*) in
memory is significantly smaller.

> My sip.conf only allows ulaw, but "show channel" shows some using ulaw and
> some using slin. This may be changing as the calls bounce from meetme to
> recorded wav messages. The Zap pseudo channels show ulaw -- I would have
> expected slin. Somebody who understands codec switching could help out and
> explain it to both of us :)

Think you would only see slin if some system playback needs to access
non-ulaw encoded files or users come on a different codec than others.
Since the latter isn't happening, there's no need for your system to
convert anything to slin, which is why your systems shows the Zap
pseudo channels as ulaw and playback of recorded messages doesn't use
the Zap pseudo channels. So unless my understanding is wrong, what
your systems shows is consistent with your description of the settings
you have there :)

> "top" refreshing every 3 seconds shows the asterisk process consuming from
> 10% to 70% of the CPU. "top" refreshing every 30 seconds shows around 30%.
> Does anybody know what causes the "spikes."

Yeah I'd be interested to know as well. I wonder if creation/tear-down
of sessions does that. A conference in session should eventually get
to a stable CPU consumption. You might want to have a test system and
either through sipsak or manually create a bunch of conferences and
watch the CPU. If you're playing the entry/exit sounds, recoding and
announcing names, playing participant counts and all of these are
non-ulaw encoded prompts etc. you will get those spikes as that's
where codec-translation will happen.