asterisk users - Aug 2005 - Small office setup/using analog lines w/ Ast erisk

>The Digium cards actually are sharing IRQs with other devices -- the 
>installer mentioned it could be an issue initially, but when he saw that 
>the devices that the cards were sharing with were the network card and 
>the video card, he said to just try and see if it works first. Sounds 
>like some of the problems that we're having could be related to this, 
>and it's probably the first thing I should try changing.
Definitely sort out the IRQ problems first. Absolutely, the TDM cards
require a distinct IRQ. Disable every onboard device if it isn't needed
including USB, sound card, parallel port, serial port, etc (to give you more
IRQ choices). Run /usr/src/zaptel/zttest before and after and see if it
makes any difference. If it does (i.e. ZTTEST yields ~98.X% before and
~99.X% after) then right there that's going to help.

I have used these statements in /etc/rc.d/rc.local to good effect (YMMV)

setpci -v -s 01:04:0 latency_timer=ff <--Specific statement for Digium
TDM04, you will have to do lspci -vv for the pci vendor id of your specific
Digium card

setpci -v -s XX:XX:X latency_timer=0 <-- Replace XX:XX:X with the PCI Vendor
ID of every other card that lspci -vv recognizes. 

What the setpci statements do is allow the Digium cards to hog the bus more
than any other card. It is controversial as to whether this actually does
anything; some guys claim not, however, it worked for me. 
>If the sound quality is poor, I'll try hooking up the phones to 
>a new network card.
Um, yup. In fact, I'd ditch *any* embedded NIC unless it was eepro100 or
3com (not very common these days) 'cause
embedded these days is pretty much crapola. 
>One additional question -- are VoIP lines generally easier to get going 
>w/ good sound quality than POTS lines? 
Yes and no. They are different animals. Asterisk bridges the two, but the
kind of latency/ echos / bad call quality etc issues are on the same order
of magnitude for PSTN and VoIP. They just require different methodologies
and training to troubleshoot. It's easy to set up a crappy VoIP link. 
>Another thing I was wondering is 
>whether we could get hunting to work properly with a mix of VoIP and 
>POTS. I'll call the phone company tomorrow, but if anyone has tried 
>anything like this, I'd like to hear about it.
This is all dialplan stuff. A crude way to do it is to set your
extensions.conf to Dial(ZAP/g0/xxxxxxxx) to use your PSTN lines and to
Dial(IAX2/foo:1111@somewhere.com) as the next priority, so if all of your
ZAP channels are busy, it will dial IAX/SIP after the ZAP priority fails.
Problem there, is for inbound calls. In this scenario, if you have your
inbound number that rings to a ZAP channel, a caller will ring busy if the
zap channel is in use. If that works for you, fine. If not, you could work
with this scenario by having all of your inbound numbers come in thru a VoIP
provider and all your outbound thru ZAP with a failover option to IAX2/your
provider if the zap channels were all busy. If you want to get fancy, some
providers will failover to a PSTN number of your choice if your server is
not responding. 

The nice thing in this scenario is that an IAX or SIP provider changes the
definition of what a "line" is so theoretically you can have hundreds
of
simultaneous inbound "lines" if you want, you just pay per-minute
charge X
number of simultaneous inbound "lines". This functionality is
per-provider,
they all have different policies. 
>Oh, great. ;-) For next time, does anyone have recommendations for a 
>particular motherboard or a particular type of motherboard?
Yup. Intel chip. I know people will say I'm trolling, but I wouldn't use
an
AMD for an Asterisk box. Workstation, yes. I run one myself, they work fine.
Note I said Chip not Chipset. I've had good luck with older Intel chipsets
but from what I understand some other guys have had problems with the new
Intel chipsets. I totally trust Asus though. What I would do were I you is
Asus with no onboard stuff as much as possible with a P4 chip. 
>This is for an office -- I figured that running hardware RAID would be 
>the most likely to avoid downtime if a hard drive failed. How do most 
>people handle this?
You don't. You do not use hardware RAID on an Asterisk box, and if you do,
you try it beforehand. Interrupts. All about the interrupts. As a point of
reference, our extremely expensive Mitel ICP 3300 has a 20 gig Maxtor in it.
That's all. Same hard drive as a friggin Xbox! 

Strategies for recovering that I would look at if you want to try sans RAID
is to do your Asterisk config, then ghost it onto a second HD, then install
the 2nd hard drive as a warm spare with an IDE drive carrier (this is a tray
that is removable like a SCSI hot swap, except not hot) and every night you
cron a 'dd' command to dupe the primary HDD onto the spare (dd
application
note: make damn sure that the spare drive is the exact same model. dd will
not compensate if your drive has different geometry). Primary fails, turn
off the box, yank out the primary, move the spare to the primary, turn on
box. Worst case scenario is that you loose X hours of voice mails and call
logging where X is the number of hours since the last DD command. 

One last comment: TDM04 cards have to be reinitialized periodically
otherwise they sound like crap. And by reinitialized, I mean warm boot.
Maybe Digium fixed this, but mine, I reboot the boxes every night. No more
problems. 

hth, keep the faith. Once it working good you will never go back and laugh
at everything else.

Colin Anderson wrote:
>>Oh, great. ;-) For next time, does anyone have recommendations for a 
>>particular motherboard or a particular type of motherboard?
>>    
>>
>
>Yup. Intel chip. I know people will say I'm trolling, but I wouldn't
use an
>AMD for an Asterisk box. Workstation, yes. I run one myself, they work fine.
>Note I said Chip not Chipset. I've had good luck with older Intel
chipsets
>but from what I understand some other guys have had problems with the new
>Intel chipsets. I totally trust Asus though. What I would do were I you is
>Asus with no onboard stuff as much as possible with a P4 chip. 
>
>  
>
Colin,

Would you possibly explain why you prefer Intel based systems over the
AMD based system for Asterisk?

When you speak of Intel here are you talking about Celerons, Pentium 3,
Pentium 4, Xeon, Pentium D?

When you speak of AMD are you talking XP, MP, Duron, Sempron, 64, 64 FX,
X2, Opteron?

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20050822/560016cc/attachment.htm

Make sure the Sipura's are at a current firmware revision too.  They have
made quite a few improvements with each revision.  And get the asterisk
cards on their own interrupts.  It may help to disable serial ports,
parallel ports, USB, etc. to get some additional interrupts back.

-Nate

-----Original Message-----
From: jennyw [mailto:jennyw@dangerousideas.com] 
Sent: Sunday, August 21, 2005 7:07 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Small office setup/using analog lines w/
Asterisk


Thanks, everyone, for your suggestions. I'm going to stop by the office 
tomorrow to try some of these out.

Here's more info on the setup: We bought a brand new computer for this 
-- I don't have the specifics right now, but will look that up in the 
office tomorrow. We have two Digium cards -- a TDM04B and a TDM01B.  
This system supports two organizations sharing the same office space: 3 
lines go to one org., the other 2 go to the other.

The Digium cards actually are sharing IRQs with other devices -- the 
installer mentioned it could be an issue initially, but when he saw that 
the devices that the cards were sharing with were the network card and 
the video card, he said to just try and see if it works first. Sounds 
like some of the problems that we're having could be related to this, 
and it's probably the first thing I should try changing.

I have tried using ztmonitor to adjust the txgain and rxgain. It was 
very frustrating ... changing the tx to higher or lower values did not 
necessarily change it in the direction you'd think. Also, changing rx 
sometimes affected tx and vice versa. In the end, I gave up because 
nothing I did increased sound quality -- although it wasn't so hard to 
make things worse. Any hints here?

We're using Sipura phones. We realize these aren't has high quality as 
Polycoms, but this was what the manger decided to get based on the 
budget. We're spending more than originally anticipated now because of 
the problems we're having, but it seems like the Digium cards are a more 
likley culprit than the Sipura phones.  However, if there's a way to 
isolate problems, that'd be great. I guess one thing is we could try 
more experiments with one extension calling another -- if the sound 
quality is a lot better, then it's unlikely a problem with the Sipura 
phones. If the sound quality is poor, I'll try hooking up the phones to 
a new network card.

As for interference ... we don't have wireless devices, and the main 
phone we're testing with is about 10' away from the switch. I suppose 
there's still some possibility with interference, but I think it's 
something I'll prioritize a little lower.

One additional question -- are VoIP lines generally easier to get going 
w/ good sound quality than POTS lines? One reason we went with POTS was 
for sound quality. Of course, we also figured it'd be more reliable than 
DSL, which was the main reason for going with POTS lines. Right now we 
use 5 POTS lines ... if VoIP sounds better, we were thinking of dropping 
three of those lines and getting VoIP lines, keeping the POTS lines as 
backup. Any thoughts on that plan? One thing I'm not sure about is how 
to select the POTS lines from the phone sets. I suppose we could assign 
a second extension to the phones (they support 2) and have the second 
one be POTS and the first be VoIP. Another thing I was wondering is 
whether we could get hunting to work properly with a mix of VoIP and 
POTS. I'll call the phone company tomorrow, but if anyone has tried 
anything like this, I'd like to hear about it.

Also, are there any VoIP vendors that work particularly well with 
Asterisk? I've seen Broadvoice mentioned a bit ... are they a good 
company for this?  I'd love a company that could do automatic failover 
-- if the VoIP line cuts out, transfer to an analog phone line (I know 
Vonage has a feature like this, but they're expensive and we don't need 
a lot of the features).

Thanks again for all the suggestions!

Jen


_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

> >>
> > Colin,
> >
> > Would you possibly explain why you prefer Intel based systems over the
> > AMD based system for Asterisk?
> >
> > When you speak of Intel here are you talking about Celerons, Pentium 
> > 3, Pentium 4, Xeon, Pentium D?
> >
> > When you speak of AMD are you talking XP, MP, Duron, Sempron, 64, 64 
> > FX, X2, Opteron?
> >
> 
> 
I'm quite aware that Opterons et al have gained signifigant market share in
the past couple years and AMD and their supporting chipsets have
dramatically improved in quality. I'm actually an AMD fan. However, when you
are spec'ing a system that a business will depend on (and your Asterisk
server is arguably the most important piece of kit in the rack) why would
you introduce an unknown variable in the equation just to save, say, 30% on
the price of the chip and motherboard? Just to throw out some comparative
numbers, let's say for the sake of argument that the Intel chip, a P4, is
$500. The AMD is $300 (not far off actually) The mobo's are the equivalent
from a reputable manufacturer like ASUS or what have you. For some magic,
unknown reason, (who knows, kooky Linux byproduct of using AMD or even user
error in compile flags) the AMD system performs poorly or not at all, and
the intel box runs OK. Now. let's say that this business is dependent on the
phones ( what business isn't?) and it has gross revenues of, say, $10,000 a
day and has regular business hours. In this case, the cost of downtime for
the phones is $20.83 a minute. That means essentially that whatever price
break you got by using AMD for this fictional business will evaporate in the
first 10 mins that an AMD based server doesn't do the job as opposed to an
Intel solution. Plus, fictional Asterisk consultant will tear his hair out
trying to figure out what the issue is and make blind stabs in the dark,
when the whole thing could have been avoided just be being conservative on
the hardware specs.    

The outfit I work for has gross revenues well in excess of $200M a year. Our
calculated cost of downtime is $16 a SECOND. At least 50%  of that can be
directly tied to phones. There is NO DAMN WAY that I would ever put a server
on the rack with specs that I got from TigerDirect or Toms Hardware or a
"consultant". No friggin way. Not even Dell. It's gonna be a Tier
1 box with
Intel. Trust me, you are rolling the dice doing anything else. Ever notice a
common thread with all of the "I'm bringing up a new system and I get
call
disconnects / echo / clicks" posts? It's always whitebox hardware.
Other
than the cursed Dell and the DL380G4, I never see: "I have a Tier 1 server
and I get disconnects / echos / clicks". Of course, it's quite possible
to
*take* a Tier 1 box and make it perform poorly, but that's a different
kettle of fish.

Maybe Coalescent should do a poll on it, I'd be curious to see a matrix that
shows whitebox hardware or tier 1, what chip/chipset and number of users. 

Here's another thing to consider: The value proposition of Asterisk is that
it runs on commodity hardware instead of something specially engineered for
the task. We all agree on that, right? Well, Tier 1 Intel hardware *is* a
commodity product, and a proper Tier 1 Intel based solution, while 30-100%
more expensive than an AMD whitebox, is 3 to 10 times LESS expensive than a
dedicated PBX while giving at least equivalent and (in my case) oodles more
functionality than a traditional solution. It's a friggin steal. However,
there's no steal to be had if the thing desn't work in the first place.
(apologies and props to those running AMD right now)

My box? 4 way Xeon. 120 users, more added every day. 3500-4000 calls a day.
Zero problems. Takes everything I can throw at it and asks for seconds. In
my case, *I* am the weak link in this installation, not the server.

>This smells of the "You never get fired for buying IBM (replace
with Cisco, etc)" quote.  Sure you can take the small gamble >that a
"tier
1" platform will meet your needs, however, nothing beats a full battery of
tests including burn in, capacity and >failure mode tests.  If you don't
know how your system is going to fail and when it will fail, then how are
you going to monitor >it?

Which is why I noted that *I* was the weak link in the chain. It's all about
eliminating the unknown. 80% prep, 20% implementation, and then you have a
fighting chance. Other way around, throwing random hardware at it and not
prepping and beating the hell out of the box before you go live,  you are
toast. 

I'm sure there are users out there running Opteron on white box hdw just
fine. They either know exactly what they are doing or they got lucky. In the
case of former, find out what they did or hire them. In the case of latter,
run. Quickly.

>I've never heard about IO-APIC before, so I just did a Google
search. 
	>The articles I found say that it's an Intel thing, and, since I
have an 
	>AMD processor w/ ASUS motherboard, it's unlikely it'll work, right?


Not Intel thing. Chipset thing:

http://www.amdboard.com/via_k8t400m.html (scroll to the bottom)

Problem is, there is not consistient implementation of the spec across
chipsets so APIC will choke sometimes. That's why there's the
"noapic"
kernel boot option. I use that option myself, all the time, both on Intel
and AMD. 

Give it a try. At this point you need options. Also, keep a detailed log of
what you did, and what the result is. If you change a whole bunch of stuff,
and suddenly it's better, what made it better? With a log you know, and then
it's reproducible. 
>The main regret I have about hardware RAID is that the card is sharing 
>an IRQ with one of the Digium cards. This whole IRQ thing is driving me 
>crazy ... I disabled everything I could in BIOS and that freed up some 
>IRQs, but there's no way to assign a particular IRQ to a particular 
>device. I haven't had to think about IRQs in a long time, and it's
very
>frustrating. I'd still like to hear about hardware suggestions that 
>could avoid this or make this better in the future. Like, are there 
>motherboards that let you assign IRQ to devices?
Yipe. You gotta eliminate that RAID controller. A quick way to eliminate it
would be to yank out the controller, put in a random hard drive off of the
embedded IDE controller and install Asterisk@Home (that way you don't have
to recompile or reinstall the OS, it does it all for you, quickly). If you
try this I found that the new TDM driver included with a@h doesn't work for
jack. Use modprobe wcfxo instead, the old one. 
>Since I get echo and popping noises even when I'm dialing from one 
>extension to another (no Digium card involved), I'm guessing that the 
>problem is at least partly the telephones. Of course, the sound quality 
>is better in other ways (e.g. both sides of the line are clearer), so 
>maybe there are some problems with the Digium cards, too.
Double yipe. Things to look at here in this case include transcoding (i.e.
make sure that you are using the same codec end-to-end, for example all the
phones and Asterisk are using ULAW codec with allow=ulaw statements in
sip.conf and setting ulaw as the preferred codec in your phone setup) the
quality of your LAN (take your LAN out of the picture by cabling a couple of
phones DIRECTLY to the Asterisk server with a crossover cable; some phones
like Snom allow you to daisy chain multiple devices together) and even the
volume of the handset (a cranked handset volume can introduce echo into the
call path simply by the handset microphone picking up audio coming from the
handset speakers. Softphones are notorious for this when you use a crappy
headset or plain old mic and speakers)

Good luck and please keep posting so everyone can learn from your
experience.

>Recompile zaptel with 
>- MMX enabled
>- Enable the AGGRESSIVE_SUPPRESSOR with MARK2
Excellent suggestion, I had forgotten about that. Note to those that try:
Enabling MMX in Zaptel will bugger up SpanDSP, your faxes won't recieve
correctly. Why? Dunno. Just my experience; although I've only tried it on
two different boxes as always YMMV but it's pretty reproducible for me.

Interesting. What version are you running? I may try to update to the
latest.

-----Original Message-----
From: Andrew Kohlsmith [mailto:akohlsmith-asterisk@benshaw.com]
Sent: Tuesday, August 23, 2005 12:56 PM
To: asterisk-users@lists.digium.com
Subject: Re: [Asterisk-Users] Small office setup/using analog lines w/
Ast erisk


On Tuesday 23 August 2005 14:37, Colin Anderson wrote:
> Excellent suggestion, I had forgotten about that. Note to those that try:
> Enabling MMX in Zaptel will bugger up SpanDSP, your faxes won't recieve
> correctly. Why? Dunno. Just my experience; although I've only tried it
on
> two different boxes as always YMMV but it's pretty reproducible for me.
Untrue.  I receive faxes every day with spandsp and MMX enabled in my
driver.  
If you look at the code all it does is save FPU state.

-A.
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users