Building A Voip Network
Submitted by admin on 3. January 2008 - 9:34.
Building a voip network to make money with it is all about marketing.
You don't need to have all the technical scills, you can hire someone.
But it's essential to know how to market it.
I'd recommend to have the 2 servers in two different geographic areas. If a router fails in one data centre, the other will do the job.
If a nameservers fails the other will do it?
Two servers in two different data centres (maybe different countries) offer the flexibility when creating a failsafe system. Don't use Asterisk as hub of your VoIP network, it is a marvelous PBX, but not a VoIP network server, it's not scalable.
You're restricted in growing your business, subscribers are limited.
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. Reply from gray on Jan 07, 2007 - 09:15 AM
... as an adendum to Deans excellent and comprehensive post I just wanted to remind prospective new entrants to the 'provision of service' market that they need to set aside quite a lot of time and consideration to their method of 'revenue collection'. It really can be a minefield of problems. The real cost of collecting and administering the allocation of small amount of money to individual client accounts can prove to be so much of a nightmare that it can challenge the viability of the overall project if not tackled correctly. Collection costs, chargebacks and fraud eat into the profit margins you calculated to a signficant extent, to my mind this has to be an element of the project that should be researched and costed before writing bespoke software or commiting to any hardware - it's a fundamental part of the initial reasearch that cannot be overlooked.
Reply from dean on Jan 07, 2007 - 11:40 AM
Good point John - and actually one of the major reasons for the downfall of Gossiptel. The level of fraud they experienced was horrific - I remember they actually had to stop taking credit cards for a period. Any low value services supply that doesn't require a delivery address is high risk. The other pseudo-financial aspect that hasn't been touched on of course is customer churn. When you don't own that last mile of copper, there is nothing that ties your customer to you. Switching provider is so easy that people jump around like jack rabbits seeking out the best deals. That's one of the reasons I believe you shouldn't seek to be competitive solely on price as you manage the transition from voice 1.0 to voice 2.0, but instead seek to offer a service that no-one else does (and preferably that no-one else can - see patents point). Unique Selling Points are as strong a customer tie as you can get without owning last mile copper. Dean
Reply from jgarland79 on Jan 07, 2007 - 02:38 PM
Here is your opensource SBC: http://www.opensourcesip.org/opensbc.php Or you could just use Mediaproxy and OpenSER. Very good writeup by the way. Most of it sounds familiar. I recently setup an ITSP where we resold Level3 VoIP. We used a Ditech C1000, OpenSER, OpenPBX, Asterisk, FreeSwitch(My favorite for conferencing servers so far; No zaptel garbage required and it runs great in Xen) Oh yea.. and we used the hell out of Xen for hosted PBXes. Think 30 PBXes per server. It does require some SPECIAL modifications to the xen kernel to get OpenPBX or Asterisk working smoothly, but it can work. Nevertheless, with all this great technology our dream VoIP provider went under because of lousy management. I'd love to try again someday. Maybe with better funding and better marketing and management.
Reply from dean on Jan 07, 2007 - 02:49 PM
Hey jgarland79, many thanks for the headsup and link to the opensource SBC, and welcome to VoIP User. I'll go and have a look at that a little later and see if there's something that we can do with it. Quote:
Or you could just use Mediaproxy and OpenSER You can, and that's the "proxy everything" approach that I alluded to as a possibility. The issue is one of bandwidth and QoS. On the bandwidth front you'll probably remember from playing with the Ditech C1000 that it will use all manner of technologies (STUN, TURN/ICE) to circumvent any NAT devices in the first instance, and will try to route audio traffic peer to peer. It will only proxy if it absolutely has to. That's why they cost $10k. MediaProxy proxies everything at the cloud edge, which means your QoS can only be as good as the distance between users and that cloud edge... It's a case of striking a balance. What I'm really looking for is an open source SBC that is equivilent to the Ditech in terms of its level of "intelligence" and ability to route peer to peer wherever possible. Quote:
because of lousy management I'm sorry to hear it went belly up, but at least you're not alone
Reply from p2pvoice on Jan 08, 2007 - 04:22 PM
Dean: Excellent article that clarifies a lot of fuzzies about some key issues like SBC and SER. Given all that needs to be done to make it work - time amd money, I wonder if some marketing types would comment on the alternative approach to "white labeling" a third party provider. True, there may not be any patentable secret sauce but, for now, one can compete on price. Also, if some of you have any favorite providers - and your personal experience with those who offer "white label" packages, I would appreciate if they would share it. Thanks and Regards, -p2pvoice
Reply from dean on Jan 08, 2007 - 07:06 PM
Hi p2pvoice - long time no see (or maybe you've been lurking!). Quote:
True, there may not be any patentable secret sauce but, for now, one can compete on price. Where do you go once you can no longer compete on price? If you take current trends to their ultimate conclusion, voice as a commodity is heading to price point zero. Perhaps we should start another thread to deal with some of the more marketing-orientated issues?
Reply from gray on Jan 08, 2007 - 11:55 PM
p2pvoice : Given all that needs to be done to make it work - time amd money, I wonder if some marketing types would comment on the alternative approach to "white labeling" a third party provider. True, there may not be any patentable secret sauce but, for now, one can compete on price. Also, if some of you have any favorite providers - and your personal experience with those who offer "white label" packages, I would appreciate if they would share it. -p2pvoice Speaking as a 'marketing type' I think it has to be said that what you are asking for is commercially very valuable information, expensive to gather but none the less vital to have correct in order to complete 'due diligence' and make a valid business decision. I can certainly see why you are asking the question. What we don't want to encourage now is for every white label provider to follow your post with a 'me' 'me' that is neither impartial or valid (we will delete them anyway if they try that). The information that Dean provided freely was in part to make the many hundreds of people who visit here thinking that setting up as a commercial VOIP provider is something that anyone can do with a spare 200 bucks to spend on some odd bits from ebay. You and I know that not to be the case (and if they read Deans info they now do too). If you are sincerely looking for a commercial/technical review of providers followed by a recommendation for your needs then a good consultant will certainly be able to tackle that for a fee that is somewhere between sizeable and realistic.
Reply from bluebox on Jan 09, 2007 - 02:24 AM
Dean, Nicely done piece. Thanks for taking the time to write it. I would just caution potential new entrants to also think about security when they are looking to set up their service provider network. In the rush for $$$, many folks are gathering the type of equipment you outline, setting up an upstream SIP trunk and... ta da... they are a VoIP Service Provider! However, there are several layers of security that need to be thought about beyond the SBCs, NAT traversal and fraud mentioned above in earlier comments. More details can be found in the VoIP Threat Taxonomy over at the VoIP Security Alliance, but here are some basic ones to think about: 1. Authentication - How are you authenticating the SIP connections to your network? 2. Call control - How are protecting the call control signaling for your network? Could an attacker inject bogus messages or nasty commands? Could the attacker view your call control stream and learn who is calling who? 3. Voice security - Given that your callers are probably going across the public Internet, what are you doing to protect the confidentiality of those calls? If someone is calling their bank over your network, could someone else conceivably listen in? 4. Availability - If an attacker launches a Distributed Denial of Service attack against your call servers, will they handle it? Or will all your customers be offline? There are more issues, but these are some of the basic ones... Some, like #2 and #3, can be easily addressed by using the commonly available encryption methods for SIP (typically TLS) and RTP (usually SRTP/Secure RTP). But you have to do it. The number of tools out there to attack VoIP systems is only going to continue to increase. Ultimately, there are going to be VoIP service providers who networks are compromised at great financial cost to themselves and their customers. Don't let it be you! My 2 cents, Dan York
Reply from tanglero on Jan 09, 2007 - 08:54 AM
Here is some Marketing feedback as requested... The general assumption that just placing your brand on-top of a white-label service as the simplistic way to launching a service is wrong. From a marketing point of view, how do we then solve the issues with homes that run P2P traffic all day long and have no local resident QOS for VoIP? Our company will be inundated with phone calls and we can not go to our out-sourced VoIP provider because they will only confirm that the problem is at the local node. Hence, this problem is ours...the marketing people. Another challenging problem for marketing which is similar, as people migrate to ADSL2+ they no longer have dedicated bandwidth as they had when they had normal ADSL. With ADSL2+, they share bandwidth at the DSLAM. And again, if one or more customers are running P2P traffic, that DSLAM's QOS for VoIP is non-existent. Once again, the marketing people who thought they could simply white-label the service will own the problem, not the 3rd party VoIP provider. There are many more of these type scenarios that put the credibility of the VoIP service at risk. It is not simply putting a brand on a service. Thats as insulting as telling a developer to right code for 15 minutes and just get the job done...same level of insult, same level of disrespect! Within today's VoIP maturity and prevalance, identifying or aligning your VoIP service with the publics mental influences is mandatory. Seek for market events, public trends, and things, places or people that have created the latest buzz. If your a true master, create your own buzz from scratch. This is the most rewarding and seen by many as the most difficult because it takes your own unique thoughts not a "copy & paste" approach to marketing. There are many market opportunities to stand out from the other VoIP services. Look at your national demographic, understand why it is unique, what makes your culture different from others, play to this. What is the breakdown of men and woman, children and adults, rich and poor, rural or urban, etc. It is not that you should know the answers to these questions, but that you should be living within the consequences of having all this data and acting upon it in the best interest of your VoIP company. VoIP marketing should not be about price, but so far it is, and has been since 1994. It doesn't have to be, just reward yourself and your company by thinking different and leveraging the uniqueness of each individual market. Lastly, you must be recognized as one of the most knowledgeable on technical VoIP issues, 2nd only to your CTO. No excuses and I'm not kidding! How do you do this? Attend meetings and discussions that your developers are having on networking, redundancy, scalability, peering, proxy protocols, SIP codecs, almost everything they speak about (except for pure code talk...your forgiven here). Your developers will find it uncomfortable that you are there, they will even ask you why. Tell them your just interested. Keep attending these meetings. You are ready when you can interrupt their discussions and contribute. There is no excuse. You must know and understand your VoIP technology environment completely. When a new architecture is announced or a new product category that changes the current paradigm is revealed, you must be the one who can provide that instantaneous priceless thought that will differentiate your company from the competition and in doing so, elevate your company above all others. This is VoIP Marketing. Take care!
Reply from dean on Jan 09, 2007 - 10:28 AM
Dan - I actually believe that security will become the single most important factor in any VoIP network from enterprise to carrier. In fact, from a marketing perspective, you could probably argue that secure VoIP is the niche to be in right now. Quote:
the VoIP Threat Taxonomy That's a great resource that everybody reading this thread should probably read:- http://www.voipsa.org/Activities/taxonomy.php Remember I underscored the importance of the Session Border Controller? From a security perspective, that's where everything enters your cloud. Quote:
In the rush for $$$, many folks are gathering the type of equipment you outline, setting up an upstream SIP trunk and... ta da... they are a VoIP Service Provider! This is the reason so many people ask me the question "what equipment do I need?" and that's in part why I wanted to write a basic guide and outline of what goes where in a Session Layer SIP network. It wasn't my intention to encourage everyone with £20k spare to go and setup a (unsecured) pure-voice ISP. You've highlighted some really important security implications (thank you) - most of which are tackled with hardware/software in the SBC. I may go back and introduce that into the budget. For the moment your post clearly highlights the fact that securing your network is stage 2 and will require an additional round of money spending. And readers here can go and listen to your BlueBox podcasts and read the information at the Security Alliance to learn more. Thomas - excellent points - ADSL2+ does indeed present some big QoS problems. Let's say for the moment that ADSL2+ ruins service for VoIP completely. What's the answer to the problem, or will that herald the day the inbumbents have been waiting for? For entrants to this business looking for pedigree, Dan is a regular contributor to the VoIPSA Security Alliance and broadcasts on VoIP Security over at BlueBox. Thomas is the former CEO of FreeWorldDialup and author of http://anglero.blogspot.com
Reply from tanglero on Jan 09, 2007 - 11:24 AM
Dean - ADSL2+ improves ISP margins because their OPEX decreases as subscribers to their ADSL2+ increase. As a VoIP consumer, upgrade your ADSL to the highest level below ADSL2+ or get a SDSL subscription which is dropping in price quickly in certain countries (Nordics, for example). It's funny (or not funny). ADSL2+ is a perfect example of good marketing, but not good VoIP marketing. Actually, the VoIP aspects are not being spoken of and the operators will receive more support calls do to this non-publicized issue. The cable companies do not have this problem. They uses DOCSIS which sets up a separate private channel for VoIP calls. So another recommendation would be to switch to a cable ISP, if available.
Reply from dean on Jan 09, 2007 - 12:13 PM
Thomas - this is such a spot-on point that I'm going to quote it again:- Quote:
When a new architecture is announced or a new product category that changes the current paradigm is revealed, you must be the one who can provide that instantaneous priceless thought that will differentiate your company from the competition This is the reason there is such a large overlap in the VoIP space between technology and marketing. Overall, successful VoIP companies must have a CEO that is a marketing genius, but that also has a technical background (or is intelligent enough to know that he has to learn about the underlying technology). Dean
Reply from martyndavies on Jan 10, 2007 - 03:05 PM
Firstly I’d like to say that I enjoyed your piece very much, and it’s great to get this kind of information from someone that actually runs a VoIP network, and is willing to share such hard-won knowledge. I'd like to zoom in on the Session Border Controller (SBC) issue, because it is quite a contraversial topic for people across the board in signalling, media, architecture and security. From my perspective you’re right, there’s not much going on in the field of open source Session Border Controllers, but I think this shows the state that the technology is in today. VoIP is not as well understood as many other IP applications, and the state of SBCs is comparable to the state of firewalls perhaps seven/eight years ago. Today, firewalls are taken for granted: you can get source code, and if you are making an embedded device (using for example a box from an ODM manufacturer) you can buy a firewall component as an off-the-shelf item at a low cost. However, back a few years ago a handful of expert companies dominated the firewall business, and each had their own proprietary tricks to make their product work better in one way or another. So it is today with SBCs: there’s no strict definition of what an SBC should do, and many companies have collections of proprietary tricks that they use to differentiate their product. Not much of this knowledge has leaked out into the public domain to allow open source teams to replicate the SBC functionality. Naturally, in time this will happen, so perhaps now would be a good time to launch the OpenSBC project! Actually, SBCs are even presented in different ways and pointed at different applications. SBCs can be useful in NAT traversal, and they certainly do have security applications like the ability to stop malformed SIP packets or defend against flooding attacks. Because the media and the signalling converges in this one edge gateway, some vendors have decided to position their products as Lawful Intercept (LI) gateways, that can ‘tap’ all the necessary data streams and forward them to the appropriate authorities. In the US, VoIP telco services have already been mandated to implement LI, so that all phone services (however implemented) can intercept calls if asked by the security services to do so. You mention in your article that rule changes for 999/E911 might be important for VoIP telcos, and this is also true for LI. At the drop of a hat you could be expected to tap calls, provide dialled digits, and so on. You will know that in IMS (IP Multimedia Subsystem) a central goal is to remove the current “intelligent network” core of a telco and replace it with a core that uses SIP and VoIP. It could be that SBCs have an important role in these next generation networks too. In IMS, when you call from a phone ‘terminal’, the first gateway you hit is called (rather uninspiringly) the P-CSCF. Now people have criticised the IMS specifications for not talking very much about security aspects, but this has led to a plethora of different ideas about how IMS security could be implemented. Some say that a security box (or software/server solution) should stand in front of the P-CSCF, and protect it from packet storms, buffer overflows etc; while some say that the P-CSCF itself should do this job. At least one company I know of have had an SBC product for some time, but they now prefer to describe it as a P-CSCF, which is a clever marketing move, no? A ready-made IMS-compliant product that already implements security, lawful intercept and core proxy and authentication functions. Many do not like the idea of funnelling all the signalling and media through the one place, because of the reason you touch on: each hop you go through increases the latency, and risks making the phone system unusable. There are no easy answers to these questions, though since there are often are legal constraints that we need to comply with whether we like it or not. You mention IPv6, so perhaps I should too. Many hope that universal IPv6 could be the panacea to the NAT traversal problem, and I have heard estimates that perhaps today 45% of the World’s IP users are behind a NAT/PAT device of some kind, so it is a huge problem to solve for VoIP. Unfortunately, for IPv6, a variety of solutions (including NAT) have temporarily taken the pressure off the number of available IPv4 addresses, and so the economic reasons to change to IPv6 are not compelling. IPv6 means not only changing the network architecture, but also the applications: just think about all the configurator programs that will need to be changed. It’s hard to know what could trigger the necessary changeover on large enough scale to make it work. Also, even if we switched to IPv6, would the security guys be happy to "go naked", when they were used to using firewalls and SBCs with IPv4? Probably not, just an opportunity for vendors to sell a lot of 'next generation' FW/SBC boxes which could easily bring their own problems. Thanks again for a thought-provoking article, and your well-deserved Digg rating.
Reply from rmccharles on Jan 12, 2007 - 07:21 PM
I also enjoyed reading your post especially since my experience has been with commercial products rather than open source. Here in Canada I've seen several VoIP services start and fail. It is a very competitive market and I have yet to think of a way of truly differentiating oneself from the competition. So far it's all about price; except for the cable operators who simplify the installation process and can make legitimate claims about the superior reliability of voice quality. As an aside, I think the Vonage and other similar services' business models are fundamentally flawed. Imagine that your company makes widgets. You take great care in making a quality product but when it comes to shipping, you have no control whatsoever. Your product may or may not arrive at your customer in good working order and there's nothing you can do about it. Your shipper does not care and in fact the shipper may be a direct competitor! Unless you own the communications path (i.e. the last mile) you can't guarantee quality. Also, I believe that in general the public does not understand the security and reliability risks. Traditional PSTN services are extremely reliable. At some point, I don't know when, but perhaps when we have a power disruption like we did in 03 (my power was off for 2 days) people will be outraged that an essential service that could always be depended-on in the past was not available. Rick McCharles
You don't need to have all the technical scills, you can hire someone.
But it's essential to know how to market it.
Hardware Requirements
The backbone of any voip network is a reliable hardware infrastructure.Redundancy
Run a load-balanced redundant PC pair.I'd recommend to have the 2 servers in two different geographic areas. If a router fails in one data centre, the other will do the job.
If a nameservers fails the other will do it?
Two servers in two different data centres (maybe different countries) offer the flexibility when creating a failsafe system. Don't use Asterisk as hub of your VoIP network, it is a marvelous PBX, but not a VoIP network server, it's not scalable.
You're restricted in growing your business, subscribers are limited.
Session Border Controller SBC
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. Reply from gray on Jan 07, 2007 - 09:15 AM
... as an adendum to Deans excellent and comprehensive post I just wanted to remind prospective new entrants to the 'provision of service' market that they need to set aside quite a lot of time and consideration to their method of 'revenue collection'. It really can be a minefield of problems. The real cost of collecting and administering the allocation of small amount of money to individual client accounts can prove to be so much of a nightmare that it can challenge the viability of the overall project if not tackled correctly. Collection costs, chargebacks and fraud eat into the profit margins you calculated to a signficant extent, to my mind this has to be an element of the project that should be researched and costed before writing bespoke software or commiting to any hardware - it's a fundamental part of the initial reasearch that cannot be overlooked.
Reply from dean on Jan 07, 2007 - 11:40 AM
Good point John - and actually one of the major reasons for the downfall of Gossiptel. The level of fraud they experienced was horrific - I remember they actually had to stop taking credit cards for a period. Any low value services supply that doesn't require a delivery address is high risk. The other pseudo-financial aspect that hasn't been touched on of course is customer churn. When you don't own that last mile of copper, there is nothing that ties your customer to you. Switching provider is so easy that people jump around like jack rabbits seeking out the best deals. That's one of the reasons I believe you shouldn't seek to be competitive solely on price as you manage the transition from voice 1.0 to voice 2.0, but instead seek to offer a service that no-one else does (and preferably that no-one else can - see patents point). Unique Selling Points are as strong a customer tie as you can get without owning last mile copper. Dean
Reply from jgarland79 on Jan 07, 2007 - 02:38 PM
Here is your opensource SBC: http://www.opensourcesip.org/opensbc.php Or you could just use Mediaproxy and OpenSER. Very good writeup by the way. Most of it sounds familiar. I recently setup an ITSP where we resold Level3 VoIP. We used a Ditech C1000, OpenSER, OpenPBX, Asterisk, FreeSwitch(My favorite for conferencing servers so far; No zaptel garbage required and it runs great in Xen) Oh yea.. and we used the hell out of Xen for hosted PBXes. Think 30 PBXes per server. It does require some SPECIAL modifications to the xen kernel to get OpenPBX or Asterisk working smoothly, but it can work. Nevertheless, with all this great technology our dream VoIP provider went under because of lousy management. I'd love to try again someday. Maybe with better funding and better marketing and management.
Reply from dean on Jan 07, 2007 - 02:49 PM
Hey jgarland79, many thanks for the headsup and link to the opensource SBC, and welcome to VoIP User. I'll go and have a look at that a little later and see if there's something that we can do with it. Quote:
Or you could just use Mediaproxy and OpenSER You can, and that's the "proxy everything" approach that I alluded to as a possibility. The issue is one of bandwidth and QoS. On the bandwidth front you'll probably remember from playing with the Ditech C1000 that it will use all manner of technologies (STUN, TURN/ICE) to circumvent any NAT devices in the first instance, and will try to route audio traffic peer to peer. It will only proxy if it absolutely has to. That's why they cost $10k. MediaProxy proxies everything at the cloud edge, which means your QoS can only be as good as the distance between users and that cloud edge... It's a case of striking a balance. What I'm really looking for is an open source SBC that is equivilent to the Ditech in terms of its level of "intelligence" and ability to route peer to peer wherever possible. Quote:
because of lousy management I'm sorry to hear it went belly up, but at least you're not alone
Reply from p2pvoice on Jan 08, 2007 - 04:22 PM
Dean: Excellent article that clarifies a lot of fuzzies about some key issues like SBC and SER. Given all that needs to be done to make it work - time amd money, I wonder if some marketing types would comment on the alternative approach to "white labeling" a third party provider. True, there may not be any patentable secret sauce but, for now, one can compete on price. Also, if some of you have any favorite providers - and your personal experience with those who offer "white label" packages, I would appreciate if they would share it. Thanks and Regards, -p2pvoice
Reply from dean on Jan 08, 2007 - 07:06 PM
Hi p2pvoice - long time no see (or maybe you've been lurking!). Quote:
True, there may not be any patentable secret sauce but, for now, one can compete on price. Where do you go once you can no longer compete on price? If you take current trends to their ultimate conclusion, voice as a commodity is heading to price point zero. Perhaps we should start another thread to deal with some of the more marketing-orientated issues?
Reply from gray on Jan 08, 2007 - 11:55 PM
p2pvoice : Given all that needs to be done to make it work - time amd money, I wonder if some marketing types would comment on the alternative approach to "white labeling" a third party provider. True, there may not be any patentable secret sauce but, for now, one can compete on price. Also, if some of you have any favorite providers - and your personal experience with those who offer "white label" packages, I would appreciate if they would share it. -p2pvoice Speaking as a 'marketing type' I think it has to be said that what you are asking for is commercially very valuable information, expensive to gather but none the less vital to have correct in order to complete 'due diligence' and make a valid business decision. I can certainly see why you are asking the question. What we don't want to encourage now is for every white label provider to follow your post with a 'me' 'me' that is neither impartial or valid (we will delete them anyway if they try that). The information that Dean provided freely was in part to make the many hundreds of people who visit here thinking that setting up as a commercial VOIP provider is something that anyone can do with a spare 200 bucks to spend on some odd bits from ebay. You and I know that not to be the case (and if they read Deans info they now do too). If you are sincerely looking for a commercial/technical review of providers followed by a recommendation for your needs then a good consultant will certainly be able to tackle that for a fee that is somewhere between sizeable and realistic.
Reply from bluebox on Jan 09, 2007 - 02:24 AM
Dean, Nicely done piece. Thanks for taking the time to write it. I would just caution potential new entrants to also think about security when they are looking to set up their service provider network. In the rush for $$$, many folks are gathering the type of equipment you outline, setting up an upstream SIP trunk and... ta da... they are a VoIP Service Provider! However, there are several layers of security that need to be thought about beyond the SBCs, NAT traversal and fraud mentioned above in earlier comments. More details can be found in the VoIP Threat Taxonomy over at the VoIP Security Alliance, but here are some basic ones to think about: 1. Authentication - How are you authenticating the SIP connections to your network? 2. Call control - How are protecting the call control signaling for your network? Could an attacker inject bogus messages or nasty commands? Could the attacker view your call control stream and learn who is calling who? 3. Voice security - Given that your callers are probably going across the public Internet, what are you doing to protect the confidentiality of those calls? If someone is calling their bank over your network, could someone else conceivably listen in? 4. Availability - If an attacker launches a Distributed Denial of Service attack against your call servers, will they handle it? Or will all your customers be offline? There are more issues, but these are some of the basic ones... Some, like #2 and #3, can be easily addressed by using the commonly available encryption methods for SIP (typically TLS) and RTP (usually SRTP/Secure RTP). But you have to do it. The number of tools out there to attack VoIP systems is only going to continue to increase. Ultimately, there are going to be VoIP service providers who networks are compromised at great financial cost to themselves and their customers. Don't let it be you! My 2 cents, Dan York
Reply from tanglero on Jan 09, 2007 - 08:54 AM
Here is some Marketing feedback as requested... The general assumption that just placing your brand on-top of a white-label service as the simplistic way to launching a service is wrong. From a marketing point of view, how do we then solve the issues with homes that run P2P traffic all day long and have no local resident QOS for VoIP? Our company will be inundated with phone calls and we can not go to our out-sourced VoIP provider because they will only confirm that the problem is at the local node. Hence, this problem is ours...the marketing people. Another challenging problem for marketing which is similar, as people migrate to ADSL2+ they no longer have dedicated bandwidth as they had when they had normal ADSL. With ADSL2+, they share bandwidth at the DSLAM. And again, if one or more customers are running P2P traffic, that DSLAM's QOS for VoIP is non-existent. Once again, the marketing people who thought they could simply white-label the service will own the problem, not the 3rd party VoIP provider. There are many more of these type scenarios that put the credibility of the VoIP service at risk. It is not simply putting a brand on a service. Thats as insulting as telling a developer to right code for 15 minutes and just get the job done...same level of insult, same level of disrespect! Within today's VoIP maturity and prevalance, identifying or aligning your VoIP service with the publics mental influences is mandatory. Seek for market events, public trends, and things, places or people that have created the latest buzz. If your a true master, create your own buzz from scratch. This is the most rewarding and seen by many as the most difficult because it takes your own unique thoughts not a "copy & paste" approach to marketing. There are many market opportunities to stand out from the other VoIP services. Look at your national demographic, understand why it is unique, what makes your culture different from others, play to this. What is the breakdown of men and woman, children and adults, rich and poor, rural or urban, etc. It is not that you should know the answers to these questions, but that you should be living within the consequences of having all this data and acting upon it in the best interest of your VoIP company. VoIP marketing should not be about price, but so far it is, and has been since 1994. It doesn't have to be, just reward yourself and your company by thinking different and leveraging the uniqueness of each individual market. Lastly, you must be recognized as one of the most knowledgeable on technical VoIP issues, 2nd only to your CTO. No excuses and I'm not kidding! How do you do this? Attend meetings and discussions that your developers are having on networking, redundancy, scalability, peering, proxy protocols, SIP codecs, almost everything they speak about (except for pure code talk...your forgiven here). Your developers will find it uncomfortable that you are there, they will even ask you why. Tell them your just interested. Keep attending these meetings. You are ready when you can interrupt their discussions and contribute. There is no excuse. You must know and understand your VoIP technology environment completely. When a new architecture is announced or a new product category that changes the current paradigm is revealed, you must be the one who can provide that instantaneous priceless thought that will differentiate your company from the competition and in doing so, elevate your company above all others. This is VoIP Marketing. Take care!
Reply from dean on Jan 09, 2007 - 10:28 AM
Dan - I actually believe that security will become the single most important factor in any VoIP network from enterprise to carrier. In fact, from a marketing perspective, you could probably argue that secure VoIP is the niche to be in right now. Quote:
the VoIP Threat Taxonomy That's a great resource that everybody reading this thread should probably read:- http://www.voipsa.org/Activities/taxonomy.php Remember I underscored the importance of the Session Border Controller? From a security perspective, that's where everything enters your cloud. Quote:
In the rush for $$$, many folks are gathering the type of equipment you outline, setting up an upstream SIP trunk and... ta da... they are a VoIP Service Provider! This is the reason so many people ask me the question "what equipment do I need?" and that's in part why I wanted to write a basic guide and outline of what goes where in a Session Layer SIP network. It wasn't my intention to encourage everyone with £20k spare to go and setup a (unsecured) pure-voice ISP. You've highlighted some really important security implications (thank you) - most of which are tackled with hardware/software in the SBC. I may go back and introduce that into the budget. For the moment your post clearly highlights the fact that securing your network is stage 2 and will require an additional round of money spending. And readers here can go and listen to your BlueBox podcasts and read the information at the Security Alliance to learn more. Thomas - excellent points - ADSL2+ does indeed present some big QoS problems. Let's say for the moment that ADSL2+ ruins service for VoIP completely. What's the answer to the problem, or will that herald the day the inbumbents have been waiting for? For entrants to this business looking for pedigree, Dan is a regular contributor to the VoIPSA Security Alliance and broadcasts on VoIP Security over at BlueBox. Thomas is the former CEO of FreeWorldDialup and author of http://anglero.blogspot.com
Reply from tanglero on Jan 09, 2007 - 11:24 AM
Dean - ADSL2+ improves ISP margins because their OPEX decreases as subscribers to their ADSL2+ increase. As a VoIP consumer, upgrade your ADSL to the highest level below ADSL2+ or get a SDSL subscription which is dropping in price quickly in certain countries (Nordics, for example). It's funny (or not funny). ADSL2+ is a perfect example of good marketing, but not good VoIP marketing. Actually, the VoIP aspects are not being spoken of and the operators will receive more support calls do to this non-publicized issue. The cable companies do not have this problem. They uses DOCSIS which sets up a separate private channel for VoIP calls. So another recommendation would be to switch to a cable ISP, if available.
Reply from dean on Jan 09, 2007 - 12:13 PM
Thomas - this is such a spot-on point that I'm going to quote it again:- Quote:
When a new architecture is announced or a new product category that changes the current paradigm is revealed, you must be the one who can provide that instantaneous priceless thought that will differentiate your company from the competition This is the reason there is such a large overlap in the VoIP space between technology and marketing. Overall, successful VoIP companies must have a CEO that is a marketing genius, but that also has a technical background (or is intelligent enough to know that he has to learn about the underlying technology). Dean
Reply from martyndavies on Jan 10, 2007 - 03:05 PM
Firstly I’d like to say that I enjoyed your piece very much, and it’s great to get this kind of information from someone that actually runs a VoIP network, and is willing to share such hard-won knowledge. I'd like to zoom in on the Session Border Controller (SBC) issue, because it is quite a contraversial topic for people across the board in signalling, media, architecture and security. From my perspective you’re right, there’s not much going on in the field of open source Session Border Controllers, but I think this shows the state that the technology is in today. VoIP is not as well understood as many other IP applications, and the state of SBCs is comparable to the state of firewalls perhaps seven/eight years ago. Today, firewalls are taken for granted: you can get source code, and if you are making an embedded device (using for example a box from an ODM manufacturer) you can buy a firewall component as an off-the-shelf item at a low cost. However, back a few years ago a handful of expert companies dominated the firewall business, and each had their own proprietary tricks to make their product work better in one way or another. So it is today with SBCs: there’s no strict definition of what an SBC should do, and many companies have collections of proprietary tricks that they use to differentiate their product. Not much of this knowledge has leaked out into the public domain to allow open source teams to replicate the SBC functionality. Naturally, in time this will happen, so perhaps now would be a good time to launch the OpenSBC project! Actually, SBCs are even presented in different ways and pointed at different applications. SBCs can be useful in NAT traversal, and they certainly do have security applications like the ability to stop malformed SIP packets or defend against flooding attacks. Because the media and the signalling converges in this one edge gateway, some vendors have decided to position their products as Lawful Intercept (LI) gateways, that can ‘tap’ all the necessary data streams and forward them to the appropriate authorities. In the US, VoIP telco services have already been mandated to implement LI, so that all phone services (however implemented) can intercept calls if asked by the security services to do so. You mention in your article that rule changes for 999/E911 might be important for VoIP telcos, and this is also true for LI. At the drop of a hat you could be expected to tap calls, provide dialled digits, and so on. You will know that in IMS (IP Multimedia Subsystem) a central goal is to remove the current “intelligent network” core of a telco and replace it with a core that uses SIP and VoIP. It could be that SBCs have an important role in these next generation networks too. In IMS, when you call from a phone ‘terminal’, the first gateway you hit is called (rather uninspiringly) the P-CSCF. Now people have criticised the IMS specifications for not talking very much about security aspects, but this has led to a plethora of different ideas about how IMS security could be implemented. Some say that a security box (or software/server solution) should stand in front of the P-CSCF, and protect it from packet storms, buffer overflows etc; while some say that the P-CSCF itself should do this job. At least one company I know of have had an SBC product for some time, but they now prefer to describe it as a P-CSCF, which is a clever marketing move, no? A ready-made IMS-compliant product that already implements security, lawful intercept and core proxy and authentication functions. Many do not like the idea of funnelling all the signalling and media through the one place, because of the reason you touch on: each hop you go through increases the latency, and risks making the phone system unusable. There are no easy answers to these questions, though since there are often are legal constraints that we need to comply with whether we like it or not. You mention IPv6, so perhaps I should too. Many hope that universal IPv6 could be the panacea to the NAT traversal problem, and I have heard estimates that perhaps today 45% of the World’s IP users are behind a NAT/PAT device of some kind, so it is a huge problem to solve for VoIP. Unfortunately, for IPv6, a variety of solutions (including NAT) have temporarily taken the pressure off the number of available IPv4 addresses, and so the economic reasons to change to IPv6 are not compelling. IPv6 means not only changing the network architecture, but also the applications: just think about all the configurator programs that will need to be changed. It’s hard to know what could trigger the necessary changeover on large enough scale to make it work. Also, even if we switched to IPv6, would the security guys be happy to "go naked", when they were used to using firewalls and SBCs with IPv4? Probably not, just an opportunity for vendors to sell a lot of 'next generation' FW/SBC boxes which could easily bring their own problems. Thanks again for a thought-provoking article, and your well-deserved Digg rating.
Reply from rmccharles on Jan 12, 2007 - 07:21 PM
I also enjoyed reading your post especially since my experience has been with commercial products rather than open source. Here in Canada I've seen several VoIP services start and fail. It is a very competitive market and I have yet to think of a way of truly differentiating oneself from the competition. So far it's all about price; except for the cable operators who simplify the installation process and can make legitimate claims about the superior reliability of voice quality. As an aside, I think the Vonage and other similar services' business models are fundamentally flawed. Imagine that your company makes widgets. You take great care in making a quality product but when it comes to shipping, you have no control whatsoever. Your product may or may not arrive at your customer in good working order and there's nothing you can do about it. Your shipper does not care and in fact the shipper may be a direct competitor! Unless you own the communications path (i.e. the last mile) you can't guarantee quality. Also, I believe that in general the public does not understand the security and reliability risks. Traditional PSTN services are extremely reliable. At some point, I don't know when, but perhaps when we have a power disruption like we did in 03 (my power was off for 2 days) people will be outraged that an essential service that could always be depended-on in the past was not available. Rick McCharles
