"We see a lot of threads on VoIP User from people who want to be the next Niklas Zennstrom (and fair enough, we hope you succeed) asking what is required to build a VoIP network.
Often these questions are from users who have a basic technical understanding of how it all works, but no real experience of building networks, or telcoms experience with the good old PSTN.
And that's fine. As John will no doubt drill into you if I don't, the current VoIP space, in a business sense, is fundamentally about marketing. In fact if you really don't understand the basic elements of networking or telcoms, don't let it stop a brilliant idea if you have one. The technical expertise can be hired in. A number of our own moderators here do exactly that - build networks to your specifications. And thus we discover our first rule.
| Rule 1 : |
| if you're a marketing genius, you have a greater chance of success with your new VoIP company than if you are a technical genius. |
A technical genius can still make a success but will require a marketing genius to make it happen (example : how many of you have heard of Iotum, or understand exactly what their software does?).
Made it past that rule and still reading? OK, now we need to take a look at what equipment you need and what it's likely to cost.
Hardware Requirements
The backbone of any network is in its hardware infrastructure. Hardware, essentially, has to do two things:-
- It must run the software that you need to run.
- It must be reliable.
The first point is straightforward, but it does require some attention. Historically, a lot of developers in the Telco space favoured one architecture over others. There are some systems (TransNexus NexSRS server for example) which are fundamentally designed to run on SUN SPARC servers, not Intel/AMD servers. I say fundamentally because many of these software houses are actually porting to *nix on the Intel (or compatible) platform at the moment. But when you've got a decades old pedigree piece of software for a SUN server which has proved to be stable, that's probably your first choice over a port which was built 12 months ago.
So my advice in that instance would be to bite the bullet and buy the SUN server for that particular application.
Herein lies rule 2:-
| Rule 2 : |
| Using the internet to route calls does not mean that everything in the VoIP world runs on Intel *nix. |
In respect of reliability, truly nothing is "bombproof". Personally I believe that Google, the absolute benchmark example of how to build a scalable network, got it right. Lots and lots of very cheap and disposable servers. Don't buy single super-computers - buy lots of low spec ones. Servers will fail. Power supplies pack up, fans break. The best model of reliability is to understand failure and legislate/program for as near instantaneous recovery as you possibly can.
In general, this means running everything as a load-balanced redundant pair. So the heart of your network, a server of some kind, has just become two servers. Bearing in mind that your network will not require Layer 3 routing of any kind, those two servers do not necessarily have to be in the same geographic location or on the same switch. There is an advantage to be had in geographic distribution and you need to consider that. If a router fails in your datacentre, what is going to happen? If the nameservers fail just outside your datacentre, what is going to happen? Two servers in different datacentres (even different countries) offer a lot of flexibility when creating your failsafe systems.
If legislation changes in your country and you suddenly need to provide emergency services routing (999/911), is your network likely to pass the required standards of uptime and redundancy? Are your customers going to require Service Level Agreements? Would any of your business customers be happy knowing that you have a single point of failure?
At this point another rule can be drafted:-
| Rule 3 : |
| It is going to break at some point. Ensure you have redundancy. |
Registration Duties
Let's obliterate the first myth right here and now. No, you cannot use Asterisk at the hub of your VoIP network. It amazes me that people still think they can do this. Asterisk is a PBX, and for that it's fabulous. But it is not a VoIP network server. It does not scale. Think about it, let's say you become the next Vonage and within a couple of years you have 1 million subscribers. Asterisk will not load-balance, so you're stuck to one machine. One million subscribers logged in, making calls and you're proxying all of the audio streams. On one server, with no redundancy. It doesn't work.
The good news is that the best registration server out there is open-source and therefore free. openSER on a reasonably specified server should be good for many tens of thousands of users.
Given the low cost of server hardware these days there's not a lot of point in skimping below that, so buckle up ladies and gentlemen, credit cards out for your first purchase:-
| Code: |
| 2 x Intel PIV 2.8ghz, 2gb RAM 1u Servers : £1,400 plus VAT |
Two for redundancy, remember?
Session Border Control and NAT Traversal
I believe this is the most misunderstood aspect of VoIP networks and really deserves a thread of it's own, but I'll do my best on the basics at this stage for the purpose of this article.
A Session Border Controller ("SBC") controls what goes into, and out of, your VoIP "cloud". I use the word "cloud" rather than "network" deliberately. A network border controller is a firewall (packet level inspection), and an SBC is not a firewall because, in OSI terms, it is a Layer 5 device and not a Layer 3 device. If I lost you there, you need to read up on networking and I suggest you read this and come back.
A Session Border Controller therefore represents the very edge of your VoIP cloud and in 2007 this will actually be the most critical part of your network. Why? Well, let's get the marketing director back into the room.
Ask any Vonage customer what would make him switch service to Comcast? He'll tell you immediately - "price". Yes, sorry to say this, but it's still the case that VoIP, from the consumer point of view, is 100% about price. 100%. A lot of people are shaking their heads about that statement. They think that it shouldn't be the case (and they're right) and they wish it wasn't but just at the moment that's exactly what it's about. The mass market has not yet adopted concepts of voice 2.0 - we're still at voice 1.0. Average Joe wants to be able to phone his girlfriend in Australia for the cheapest possible rate from his handset.
So that's your current mass market right there. Yes, it is transitioning, and yes the result of that transition will be away from a per-minute billing model to flat-fee and towards an application driven system; that is to say it's inevitable that voice networks will be chosen by feature-set and not price.
But we're not there yet. And you want to build a network now and establish your brand and reputation so you're going to have to manage that transition.
| Rule 4 : |
| The transition from voice 1.0 to voice 2.0 will be managed at the cloud edge. |
To explain this one futher, let's have a look at some basic concepts that will make VoIP so important in the future, both in terms of things that need to happen, and feature set:-
- Peering
- Presence
- WiFi Roaming
- Hard Roaming (user plugs phone into hotel room socket)
- Intelligent call routing (eg Iotum)
- Codec transcoding/decision making
All of the control mechanisms for the above reside on the cloud edge and it will be up to your Session Border Controller to determine what to do.
Not only that, but just imagine how important NAT traversal is going to become. If you have a customer roaming with his WiFi handset you can't really ask him to tell Starbucks to forward port 5060 to his phone while he has his Latte. He just needs to be able to power up his phone, sit down and make calls. It needs to be plug and play.
SBC's make networks plug and play. Their importance now and for the future (we don't have IPv6 yet) is completely misunderstood by the majority of people who want to build a VoIP network.
Yes, there is another option for NAT traversal - you can proxy everything. In fact this is exactly what TruPhone do with their WiFi network. But you're still going to require an SBC for all other duties. And if you do decide to proxy everything you need to consider scalability - the location of the proxy becomes important. If your customer is in Australia calling a "local" Australian number and the proxy is in London, think about the length of audio path (Australia - London - Australia) and how that affects Quality of Service. With an SBC in place, over 90% of all calls will go directly peer to peer. In this example, the audio will not leave Australia.
SBC's are important.
Now the bad news. There is no open source "intelligent" SBC that I know of (if I'm wrong, please please let me know - I'd love to see an open-source SBC project - if I had time I'd build one myself) and they are therefore expensive devices.
So that's two more things to add to your shopping list:-
| Code: |
| 2 x Ditech C100's : £11,000 plus VAT |
... and rule #5
| Rule 5 : |
| Network considerations made at design stage must include Quality of Service, audio path length and NAT traversal |
Billing Server
Yes, you could run this on the openSER server machines, so they don't represent an additional hardware requirement. However, that said, it's advisable that you build your network with a view to moving the billing engine/CDR generator to a dedicated machine(s) at some point. Purely for scalability reasons.
Call timing, assuming, at least for the moment, that you're stuck with a per-minute model, will be done at the session edge by your SBC. Your billing engine will communicate directly with the SBC.
You are almost certainly going to be writing your own billing engine, and there are plenty of open source systems out there to chose from as a base starting point.
Miscellaneous Services
For now you're only going to be concerned with basic testing features (echo test), possibly a speaking clock and such other features traditionally found on voice 1.0 networks. People are used to having them and your network should have them.
This is where an Asterisk box can become a valued element in a VoIP network. It's not likely to be pushed very hard (unless you want to offer conferencing facilities, but that's out of scope here).
And I guess you'll be wanting some kind of a website, although that's up to the marketing folks really.
So there are a number of little services that need to run on something. You don't need high specification servers here.
| Code: |
| 2 x PIV 2ghz 1gb RAM 1u servers : £1,000 plus VAT |
PSTN Breakout
This used to be such an easy one to answer a year or two ago : buy a couple of TDM switches, two E1/T1 lines, shove it into a rack in Telehouse. Join Linx, get a licence from Ofcom, get some range allocations from Ofcom, load them into the switches and hey presto we have a PSTN gateway (for those that do wish to go this route, budget on about £30k).
It's a trickier decision process now because (a) there are existing PSTN suppliers out there who will route to/from your SIP/IAX based systems for you and (b) you would normally amortise that £30k expenditure over 5 years, but it's hard to know exactly where the PSTN will be in 5 years time and how much will be routed through it.
Further difficulties arise with a third party supplier because you're stuck with their pricing plan, making it harder to undercut your competitors without subsidising call costs.
Owning your own TDM equipment makes pricing structures easier to control and increasess your ability to be more competitive in the per minute billing model. The downside is the initial capital outlay.
I'd suggest the third party option. After all, primarily you need to have your marketing hat on and your business is going to be built on top of the secret sauce that you've invented and patented. That is what is going to make your network better than anyone elses in the long term. In the short term you may need to compete on price by subsidising and that'll just have to come out of the marketing budget.
Hosting
So far you've collected 4 servers and 2 Session Border Controllers and have a total of 6u that needs to be allocated in racks somewhere.
It's important to remember that you're building a layer 5 network and you can therefore distribute servers geographically.
Your openSER based SIP servers are simply dealing with registration and lookup duties. They respond with messages when a user wants to do something like pick up the phone and dial a number. No audio passes through them. So quality of service from a bandwidth point of view is not all that important - these servers can be stuck on a 2mb backwater network somewhere. That kind of hosting is usually pretty cheap - you can pick a couple of cheap datacentres and put one server in each.
| Code: |
| 2 x 1u hosting on a fixed 2mb pipe : £100 plus VAT per month |
Your SBC's must be on top quality backbones as RTP media traffic may be going through these. I'd recommend at this stage getting some space with a little room to spare in a carrier grade datacentre (Telehouse/Redbus/Level3). Get 6u of rack space. That allows you to house your SBC's, two servers running Asterisk and your website, with a couple of units spare for expansion.
| Code: |
| 6u hosting at Telehouse + networking & bandwidth : £1,400 per month plus VAT |
I have introduced a single point of failure right there and breached rule #3 - if Telehouse goes down, you're a dead network. You will have to take a view with your redundancy and disaster recovery. It is not financially viable to build a competitive network capable of dealing with all eventualities. One has to take a view at some point and draw a line. What you can do is split that 6u over 2 lots of 3u on different floors, networked through 2 different ISP's. That requires some further thought on your part.
| Rule 6 : |
| Choose your hosting according to needs of each individual server, not the entire network. A Layer 5 network, such as a SIP network, can be distributed geographically. |
DNS
DNS can (and should) be handled by a third party. VoIP User has had pretty good experience with DNSMadeEasy. They have a good redundant network and operate 7 nameservers in different datacentres. If you're not processing more than 10 million transactions per month, their service only runs at a few dollars a year so I'm not even going to include that in the budget, but it is something that needs to be arranged and purchased. It's the DNS servers that ultimately will be front-ending your dual server redundancy. When one server fails, the DNS resolution must be to the operating server only.
Software
We've managed to cover most of the bases with open source software. In the VoIP world we are definitely spoiled for choice - open source is everywhere.
That said, you are going to have to custom write a lot of the "glue" that holds your network together in terms of billing and management. A lot of that development is in the creation and management of configuration files (which I define as being just as much about application programming as coding something in C is). It takes expertise and experience and the top guys at this job are not cheap. Accordingly you need a 5 figure budget for it and I'm being conservative with the following estimate.
| Code: |
| Software development and Network Configuration : £10,000 |
Let's have a tally up:-
Capital Outlay
| Code: |
2 x Intel PIV 2.8ghz, 2gb RAM 1u Servers : £ 1,400 2 x Ditech C100's : £11,000 2 x PIV 2ghz 1gb RAM 1u servers : £ 1,000 Software development and Network Configuration : £10,000 Capital Total : £23,400 plus VAT |
Monthly Running Costs
| Code: |
2 x 1u hosting on a fixed 2mb pipe : £ 100 6u hosting at Telehouse + networking & b/w : £ 1,400 Monthly Total : £ 1,500 plus VAT |
So there you have it. Let's amortise the capital outlay over 3 years and add it into the monthly costings:-
| Code: |
23,400 / 36 = £ 650.00 Monthly with VAT £1,762.50 ____________ £2,412.50 |
£2,500 per month.
At a marketing price point of, say, £4.99 per customer per month (ignoring per minute charges for the moment) means your VoIP network would break even with about 500 paying customers.
Of course, this doesn't include customer support and support staff answering the phone or hiring a call centre and that's where your costs start escalating rapidly (and you will need support staff).
And then there's the marketing budget. And that moment of inspiration that produces the idea for your VoIP network in the first place - your Unique Selling Point. The patent-pending bit of technology that says "I'm different, I'm not another Vonage, look at me!".
This is a really tricky business. What I've done my best to describe above is the practical side of building a scalable network, and this is the really easy part.
It's a moment of creative genius that makes the next Niklas Zennstrom. The final piece of the puzzle lies in that Unique Selling Point. If you have that, then I wish you the best of luck in your venture and I hope that you've found this post useful in organising what you need to do next. I'll leave you with my final rule #7.
This rule is not meant to put you off, but it serves as a reminder of reality - the majority of people that build VoIP networks as a business fail because they either do not have a Unique Selling Point, or they over-value the one that they do have. Don't let it be you.
| Rule 7 : |
| Don't bet the house on it. |
see this forum at : http://www.voipuser.org/forum_topic_8289.html
0 comments:
Post a Comment