Chris, <br><br>Thank you for your detailed reply.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You need to tell us for what purpose you&#39;re using these numbers? Are you selling them out to the general public? Are you using them in-house? If you&#39;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)?</blockquote>
<div><br>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.</div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
2 PRI lines is only 60 channels, which on a decent, modern specification of server won&#39;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&#39;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.</blockquote>
<div><br>Redundancy would of course be something very important in the near future so thanks for these tips.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>It&#39;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).</blockquote>
<div><br>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. &nbsp;<br>
</div><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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:<br>
<br>
2 x OpenSER boxes handling registrations - initially hot-spare config, in time as load increases you might move to load balanced<br>
2-n x Asterisk boxes with PRIs - you&#39;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&#39;s not doing much else apart from receiving calls on the PRI and firing them out via SIP.<br>

2-n x Asterisk boxes for &quot;extra services&quot; - voicemail, complex dialplan scripting, etc. etc.<br>
</blockquote><div><br>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.&nbsp;<br>
</div><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you&#39;re primarily linking via SIP/IAX to businesses&#39; 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&#39;re mainly to take registration load away from Asterisk.<br>

</blockquote><div><br>I also do not think that going the route of spare registration boxes is necessary - we&#39;re doing this on a small scale for starters but as things get bigger and load increases then yes, this sounds good.<br>
<br>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.<br>
<br>Anything else that you can add would be excellent.<br><br>Thank you so far.<br><br>Dave<br></div></div><br>