[MLUG] More Asterisk

[Nathan Odle <EMAIL:PROTECTED>]

Well, after having our Asterisk system up and running for 2 months now, 
perhaps it's time for a little debriefing...

First, our setup:

* Dell PowerEdge 1850 Server
    - Dual-CPU capable, 1 Xeon 3.0GHz installed
    - PERC4/ei SCSI RAID, configured two 18GB 10k RPM drives in RAID 1
    - Gentoo Linux
    - Asterisk CVS-HEAD branch

* Cisco 1760 router w/ T1 CSU/DSU

* Netgear FSM7326P 10/100 24-port Ethernet switch w/ 802.3af 
Power-Over-Ethernet

* Twelve Polycom IP600 VoIP phones, running the SIP software image

* Two Digium IAXY FXS modules w/ Uniden cordless phones

* T1 via Tranquility Internet


Conclusions:

1)  VoIP is *not ready for prime time* in most business usage

We tested voice quality with several providers, and only found two that 
were reasonable.  Of those two, BOTH failed to provide acceptable 
quality once we started using them on an outgoing basis.  The voice 
quality issues are related to Internet latencies, and as such tend to be 
fairly intermittent.  A simple 'traceroute' will not uncover 
deficiencies in this area.  Due to Quality of Service and other factors, 
the only way to determine how good your link is to the provider is to 
run a tcp-style traceroute continually over say, a week, and analyze the 
results.  At the end of the day, NONE of our providers were really 
acceptable. 

Now, this is not necessarily the provider's fault.  They can choose to 
peer with some good, reputable Level 3 networks, but if those don't 
happen to coincide with the guys your ISP chose to peer with, you could 
be S.O.L.  In the end, the only way to guarantee good quality is to 
research both VoIP providers and ISPs, then determine which combination 
leaves you with the best route between your box and the provider.  This 
is a LOT of work, requires significant research, and the complete 
cooperation of both potential providers and ISPs.  Even then, you never 
know - that nice short 5-hop route could still have some bugaboos.  
Evidence one provider (who will remain nameless) who only shows a couple 
hops within their network, but actually has packets banging off of all 
kinds of ATM equipment, causing jitter and intermittent latency issues 
all over the place.

Is it possible to get good VoIP?  Yes.  But here's the kicker - how many 
people, right now, are qualified to set you up with it?  Not too darned 
many will go through all the hoops described above to make sure you get 
something that works.  They want to sell you their service, and move on 
to the next customer.  Good VoIP is NOT as simple as plugging the box 
into your cable modem.  Good enough for a home, probably - but good 
enough for business is a whole other story.  Lord knows I wish it were 
plug-and-play, I'm a civil engineer by education for chrissake, my days 
of network administration (I thought!) are long behind me.


2)  Asterisk over analog TDM lines is not without its problems either.

Having canned the VoIP idea, we moved forward with setting our Asterisk 
box up for use with regular phone lines.  This involved the purchase of 
a Digium TDM400 "Wildcat" card, and several FXO daughterboard modules 
into which you plug the lines.  It was quite simple to get calls coming 
and going, but we had one major problem that until tonight I was 
completely unable to fix:  ECHO.  Echo has a lot of sources, but I've 
determined that the Asterisk world really only has one way to attack the 
problem - digital echo cancellation.  They have some routines built into 
Asterisk that work to create copies of the transmitted sound, then mix 
them out-of-phase with the received audio at whatever the echo delay is 
to cancel it out.  The delay is determined via a training algorithm, 
with the end result that you often get echo at the beginning of the call 
which is tuned out within a minute or so.  This may be OK for home use, 
but again - this is not acceptable in a business environment and was 
driving users absolutely crazy. 

In the midst of the echo debacle, I started thinking about what I knew 
of the TDM network and circuits, and came up with the possibility that 
some sort of impedance mismatch could be causing the echo.  A couple 
Google searches later, and voila!  Lots of general information on 
digital/analog hybrid circuits meant for interfacing with the TDM 
network and mentions of echo problems due to impedance mismatches.  I 
started puzzling this out, and began to look into the driver source 
code.  As the modules are intended for use in several countries, all of 
which have different standards, I reasoned that they had to have some 
sort of software-configurable impedance matching.  I was correct - and 
had gotten a little ways along hacking the drivers to manually adjust 
the impedance for minimal echo...until I came across an interesting 
tidbit in the latest CVS release tonight.  Seems an engineer at Digium 
has worked out the same idea and released a small utility that clears 
the line, sends a "ping", and listens for echo - all the while tuning 
the impedance until the minimum echo is found.  This should allow 
Asterisk users to solve echo problems *at the source*, instead of 
resorting to hackeneyed attempts at digital cancellation.  Overall a 
huge win for Asterisk users - but woefully underpublicized.  Nothing 
really on the mailing lists to speak of, I happened to come across a 
line in the release notes and it took a look at the source to confirm 
this is what I was looking for.   Finally though, I think we may have 
something that works.


3)  VoIP *inside* your network absolutely rocks.

Without Internet latencies added to the mix, VoIP really kicks ass.  The 
sort of tricks you can do with it are not just cool, but useful too.  
Take for example, the need for one project manager to have a cordless 
phone in his project trailer clear across the site.  Without VoIP, we 
would have been relegated to trying to run his cordless out of the main 
building (not likely to work), or running a wire clear out there.  Now, 
some places may be friendly to wires strung all over but a construction 
site is *not* one of them!  Solution?  Run a pair of Linksys 802.11g 
wireless routers with the Sveasoft firmware in bridge mode, one end 
connected to our LAN and the other at the remote site.  Utilize a Digium 
IAXY, which has an analog phone jack and plugs into ethernet and 
interfaces to Asterisk - effectively turning that cordless into a VoIP 
phone.  Voila!  Phone extensions anywhere within the range of the access 
points.  Sound quality is perfect, and the experience is just like being 
plugged into a regular phone line.

Even in situations with Internet latencies, occasional use is 
acceptable.  Take for example, the fact that sometimes I like to spend 
time down at Cherry Street Artisan, where my Sprint phone gets no 
signal.  I can run VoIP software on my laptop, forward my cell phone, 
and take calls over the free wireless.  Works the same way at hotels as 
well.  I also have a VPN set up between my home and office - if I'm 
going to be making a significant long-distance call for business and 
don't want to do it on my cell I can do it over the network the same way.


4)  Cisco is getting way behind with their VoIP phones

I actually ordered in and tested several VoIP phones at the outset of 
this project.  I of course wanted to test the Cisco, thinking that it 
would probably be the most polished of all.  I couldn't have been more 
wrong.  Theirs was by far the most unstable out of the bunch, and was 
lacking some features that are in the very-superior Polycom models.  
Overall, Polycom is the way to go if you need something fairly capable 
for business use.  Their configuration is extremely slick - like the 
Cisco, you put the configs on an FTP server, which via the magic of DHCP 
the phone uses to grab the appropriate file from at boot time.  However, 
the implementation is quite a bit more polished than Cisco and uses some 
pretty readable XML files for the configs.


Anyway, hope this helps someone out - VoIP is so new that it's hard to 
get good info right now and I hope *someone* can get something out of 
all the early-adopter pains we've been going through :)

-N
_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members