Just an example, then:
I have, as my first outside production site, just concluded a very (in my
opinion) interesting and educational install as described below. There are
still many tweaks which need to be done, and if anyone has any suggestions
for improvement, I am always
First, the customer's request:
Connect the three separate offices with voice and data in an inexpensive and
supportable manner. Specifically, the customer requested that there be NO
VOIP.
Next, the hardware used:
1x Digium T400P $1500
2x Digium T100P's $1000
3x Digium TDM400P's each with 4 proSLICs $1050
6x Digium X100P's (workaround for PBX feature problem) $600
3x Athlon 2500+ systems, each with 512MB RAM and software RAID-1 80GB IDE
HDD's, using Gigabyte 7VT600-L motherboards and running Gentoo Linux 1.4
existing KSU at each location: Samsung DCS (series--- one was a DCS compact,
the other two were DCS) $1500
The connections used:
1 PRI from BellSouth with 100 DID numbers(Full 23 channels, which is way
overkill-- not my decision) $950/mo
2 Point-to-point T1s (price varies on distance) $1300/mo
1 Frame relay T1 to Internet $650/mo
PRI, frame, and one end of each of the P2P T1s comes into the T400P
One T100P takes the other end of the P2P T1s at each remote site
1 TDM400P at each site goes to KSU trunk interface
2 X100Ps at each site go to KSU analog station-side interface
P2P T1 dimensioning:
channels 1-4 = E&M trunks for voice
channels 5-24 = nethdlc for data (PPP encapsulation)
KSU interfacing:
Incoming main line calls:
1) PRI -> main T400P
2) Asterisk plays AutoAttendant stuff, then follows the following for DID
Incoming outside DID calls:
1) PRI -> main T400P
2) Asterisk A to either local, Asterisk B, or Asterisk C, based on DID
3) Asterisk -> T400P
4) TDM400P -> DISA trunk on KSU (DID not supported by KSU on analog
trunks...argh)
5) KSU -> Digital Samsung KSU station
Outgoing outside calls:
1) KSU Station -> KSU -> TDM400P -> Asterisk
2) Asterisk B,C -> Asterisk A
3) Asterisk A -> PRI
Local calls:
1) station dials 9+extension
2) KSU -> TDM400P -> Asterisk
3) Asterisk to other Asterisk
3) Asterisk -> TDM400P -> KSU DISA trunk -> KSU Station
To check voicemail from anywhere in-system:
1) station dials 98+extension
2) KSU -> TDM400P -> Asterisk
3) Asterisk to other Asterisk, if necessary
4) Asterisk -> VoicemailMain2(<extension>)
To take voicemail, I had to use X100Ps connected as stations, because the
KSU cannot forward on Busy/NoAnswer to an external number, and because I had
to use DISA instead of DID, asterisk thinks the call is answered when the KSU
picks up... before the station even rings. This wouldn't be a problem in a
native environment, but to scimp on the cost of handsets, the client wanted
to keep the old KSUs.
1) Incoming call creates a Busy or No Answer condition for the KSU
2) KSU forwards the call to an "internal-to-the-KSU" extension
3) this extension is connected to an X100P, which receives the KSU's DTMF
voicemail routing digits (one of the saving graces of the Samsung DCS) and
takes the call to Voicemail(<extension>)
Data setup:
The data side of things seems to be the least documented aspect of
asterisk...probably because it isn't really in asterisk. It is a feature of
the Digium cards and the zaptel drivers for them.
Each location has a separate private subnet and a shared transport private
subnet
nethdlc over T100Ps with PPP encapsulation (this requires sethdlc from zaptel
CVS tree, which doesn't appear to be made by default... just 'make
sethdlc')
sethdlc hdlc0 mode ppp
ifconfig hdlc0 <local transport IP> pointopoint <remote transport
ip> up
route add -net <private supernet> netmask <private supernet mask>
gw <remote
transport ip>
if asterisk b or c, route add default <remote transport ip>
For the frame:
sethdlc hdlc3 mode fr-ansi create 16
ifconfig hdlc3 up
ifconfig pvc0 <local public ip> pointopoint <ISP gateway> up
route add default gw <ISP gateway>
Obviously, this proves the concept for a number of different features the the
most excellect Digium hardware (Thanks, Mark and gang!)
This system has been in production use for a little over a month now, and
although I have had a few problems (one bad DIMM, TDM400P revision
BellSouth fouling up the ownership of the PRI which caused a huge delay in
getting the main telephone numbers ported over to the PRI), Digium has
offered great support and with the source code so wonderfully available, I
have been able to diagnose most of the problems with reasonable effort.
If anyone would like further details, I do not mind sharing.
If anyone would like to offer further suggestions, I do not mind receiving. ;)
On Sunday, 02 November, 2003 15:59, Jose Luis Perez
wrote:> Hi,
>
> I believe the issues raised by this message are the same as mine, more on a
> commercial sense than for self use, but mostly the same. I've seen
posts
> where real-life installations are mentioned, but not a reference to how
> Asterisk is working on production (and productive) environments. Any
> experiences would be very welcome I believe, not only on pure technical,
> but wider, sense.
>
> Thanks Shoval for raising this issue, and to All for keeping this list so
> alive.
>
> Best Regards
>
> Jos? L. Perez
>
> ----- Original Message -----
> From: Shoval Tomer
> To: asterisk-users@lists.digium.com
> Sent: Sunday, November 02, 2003 16:36
> Subject: [Asterisk-Users] a bit frightened, guys
>
>
> Hi,
>
>
>
> I started looking into asterisk cause we're looking for a real-world
> solution.
>
> (when I say we I talk about a 50+ HQ and a 10+ branch office).
>
>
>
> We currently use a Panasonic analog PBX, with home-made IVR and PSTN lines.
>
>
>
> We'd like to deploy most of Asterisk's capabilities through out our
> organization ? to save on long distance and international calls.
>
>
>
> I've been playing with asterisk for a week now, and I am charmed (if
not
> madly in love) with it.
>
>
>
> Today I went on and bragged to my boss about it and how we can implement it
> instead of buying something like Cisco's call manager.
>
>
>
> He got excited too and wants to have an estimate of hardware costs for a
> solution that'll work for us.
>
>
>
> Suddenly I was weak at the knees?
>
>
>
> I have a couple of questions for you guys.
>
>
>
> 1.. Has someone tried this in a real world, production environment?
>
>
> 2.. What is the Asterisk server hardware recommendation for managing
> approx. 75 extensions and 16 analog lines?
>
>
> 3.. What telephony hardware do I need in order to get all these
> extensions and lines connected to Asterisk
>
>
> 4.. Do I need to replace our lines (analog) with a PRI line?
>
>
> 5.. Can I use the existing infrastructure (connecting the existing
> extensions to asterisk, for instance)
>
>
> 6.. What is there to be said for network bandwidth consumption for this
> size of a deployment?
>
>
> 7.. Do I need dedicated bandwidth for it to work properly
>
>
> 8.. Anything else I might have left out?
>
>
> See, I'm not afraid of hard work, and I already started working on
> solutions not embedded into the Asterisk package (like broadening the web
> interface, having a directory application that connects to our internal
> phone directory, etc.).
>
>
>
> I am afraid that since this is not a commercially available product, since
> there's no guaranty it'll work I might find myself holding both
ends of the
> short stick.
>
>
>
> For instance, can I get the hardware and return it after a while if
it's
> not working? Where?
>
> This way, if it's a no go, I'm not stuck with useless hardware that
cost
> thousands of dollars.
>
>
>
> In short, can Asterisk be deployed to a real production environment, like
> ours?
>
>
>
>
>
>
>
> Shoval Tomer, MCSE
>
> IT Manager
>
> Softov Advanced System Ltd.
>
> Email: shoval@softov.co.il
>
> Mobile: 972-55-229220
>
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.532 / Virus Database: 326 - Release Date: 10/27/2003