[asterisk-users] Laying out things correctly

Dave dventer at gmail.com
Mon Apr 7 12:45:38 CDT 2008


Chris,

Thank you for your detailed reply.

You need to tell us for what purpose you're using these numbers? Are you
> selling them out to the general public? Are you using them in-house? If
> you're selling access to them, are you selling predominantly to individuals
> (i.e. single SIP devices) or to business (generally multiple devices, but
> often behind one endpoint)?


Ideally as time goes on and considering that we have the facility already in
place with all the DID numbers it would be great to sell them off. Offering
all sorts of business services such as the entire telephone network for a
business including all the numbers, extensions, pbx, phones etc - a typical
setup. A decent pre-paid system for some customers, be it through their
whole in-house system that connects to ours or even dial-in customers
wanting to call long distance at reduces rates etc...basically everything
and anything eventually.

>
>
> 2 PRI lines is only 60 channels, which on a decent, modern specification
> of server won't be a problem on a single box. You may of course want to run
> the PRIs into two boxes for redundancy (one box failing won't take out all
> the numbers) - but this might depend on whether your PRI provider will
> automatically route calls into PRI2 if PRI1 dies, or whether the 2 PRIs have
> independent number ranges on them.


Redundancy would of course be something very important in the near future so
thanks for these tips.


>
> It's up to you - all of these will work. Assuming you have no plans to
> grow beyond the 2 PRIs, then a single box would cope with the load (though,
> as suggested above, a hot spare is never a bad idea).


We do plan on growing extensively so we want to understand the basic
planning for now to ensure that we make the right move as apposed to
figuring things out in the future and having to redo everything due to silly
build mistakes.


> If your long-term plans are for many more PRIs coming into a cluster of
> servers, probably better to plan well now with future growth in mind. That
> might look something like this:
>
> 2 x OpenSER boxes handling registrations - initially hot-spare config, in
> time as load increases you might move to load balanced
> 2-n x Asterisk boxes with PRIs - you'll want to look around the net at
> some of the performance tests with different versions of asterisk -
> theoretically with 1.4 you should be able to push 4 PRIs through each
> server, if the server's not doing much else apart from receiving calls on
> the PRI and firing them out via SIP.
> 2-n x Asterisk boxes for "extra services" - voicemail, complex dialplan
> scripting, etc. etc.
>

The above sounds good, and pretty much exactly what im after - examples. The
reason I asked about a separate box that has the duty of only handling
incoming/outgoing via the PRI is that some customers might want different
setups such as a trixbox in place, but yet still forms part of the PRI
line/numbers - so having this single point would make it easy depending on
where the calls should fire out via SIP.


> If you're primarily linking via SIP/IAX to businesses' PBXs at their local
> site (i.e. fewer clients, but each with more numbers/concurrent calls), you
> may not need the SER boxes at this stage - they're mainly to take
> registration load away from Asterisk.
>

I also do not think that going the route of spare registration boxes is
necessary - we're doing this on a small scale for starters but as things get
bigger and load increases then yes, this sounds good.

The primary function for now would be as you said, connecting to a customers
PBX, where we provide the lines, numbers and send it through to their
internal PBX. We would also do the billing and provide the actual
connection.

Anything else that you can add would be excellent.

Thank you so far.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080407/aabc3883/attachment.htm 


More information about the asterisk-users mailing list