1. The need for Session Border Controller is not to overcome "the gaping chasam of inadequacy that is the SIP architecture". It is needed to handle NAT and Firewalls that customers may have deployed. Even the P2P king Skype has SBC function in its architecture (in the name of Supernodes and relay nodes).
2. You are joining the chorus of "Packet nirvana". Please give us ONE example out of the many "interesting new things you can do with it". VoIP is different from POTS in the following three ways: a. We can assume a sophesticated user interface, what with screen, keyboard, mouse and multiple display window. b. Message oriented signaling. But this is true only when one compares it to POTS, because ISDN has the same signaling capacity. c. Ability to communicate to any third party directly. This is true only for Internet, not necessarily true for all packet networks.
SPs will not consider any feature that exploits (c), lest they lose the monopoly control of the customer. The other two is not dependent on packet network. But then again, since many VoIP providers deploy services based on ATAs, they do not have these two advantages.
So we are left with just imitating POTS and forever lamenting on the unfulfilled promise.
re: Telecom Exec: VOIP Is a PainComrades, OK, everyone knows that VoIP has higher CapEx than POTS because the POTS equipment is already in place, and does the job just fine. In most cases those steam-driven telephone exchanges made by Lucent, Nortel and Ericsson will probably keep throbbing away for the next 100 years or so.
Most of us who've dealt with the equipment side, or have spoken to carriers also know that OpEx is higher for VoIP. The reasons for this revolve around the fact that IP was never intended to be either a real-time transmission mechanism, or a carrier-grade architecture. To make it perform these unnatural acts costs money, and takes time to get right. A good example is the fact that a "carrier grade" VoIP network needs one or more Border Session Controllers to overcome the gaping chasm of inadequacy that is the SIP architecture. These things don't come cheap, and they add a lot of complexity to the network design.
What is interesting is that this chap is willing to talk so openly about higher costs. I know that various organizations I've worked for over the years were very keen to try and put a number on the OpEx side of things.
As a fairly recent (maybe 2 years) convert to the pro-VoIP camp I think the fundamental problem that all of these SPs are facing is that they are simply replicating conventional POTS services using a VoIP infrastructure. What they need to be doing is to realise that, once voice has been packetised it simply becomes another kind of data. And thus there are all sorts of interesting new things you can do with it.
The key is to find a feature, or set of features that appeal to a wide selection of customers, can be easily understood and used by non-technical users. These features have to be attractive enough for them to be willing to pay a premium (compared to a packet-based POTS-lookalike). Ironically a lot of SPs I talk to are already giving up on the idea of broadband subscribers EVER paying a premium for ANYTHING. That's how competitive, and undifferentiated, broadband service delivery in N.America has become. Rather than expecting premiums, all these operators can hope for is to slow down margin erosion, or to reduce customer churn by adding "sticky" features to broadband services (ie. same idea as triple play). They only have themselves to blame for ending up in this position.
European operators are still hoping to catch their customer base at a point where subscribers will pay a premium for genuinely valuable features. If they can establish precedents for that situation there's a chance they can avoid the N.American market pitfalls.
I'm sorry I missed this presentation. It would have been interesting to hear the full context of what he said.
By the way, do folks out there agree with the comment about the SI making all the money in VoIP? My experience is that a lot of channels are making much lower margins these days - even where the channel is adding a lot of value, the work tends to be performed on a time & materials basis. And it's generally not the VoIP equipment manufacturers making money either. If anyone is making money it's the likes of Cisco and Juniper when carriers need to build overlay IP VoIP networks.
One enterprise VoIP manufacturer told me that whenever they win a VoIP deal, they know that Cisco will make between two and four times this revenue for the enterprise customer to upgrade their LAN to run VoIP.
re: Telecom Exec: VOIP Is a PainHi Aswath, Here's a different take on the inadequacy of SIP, and more generally of IP as a carrier technology.
You could say that we wouldnGÇÖt need firewalls at all if IP had been designed as a secure communication technology in the first place. This was one of the major complaints I heard when pitching IP routing into carriers in the early 90s.
If IP had been designed with an adequate addressing scheme we wouldnGÇÖt need NAT. As it turns out there are some architectural advantages to having a public/private address demarcation but we certainly haven't achieved it in a very elegant way!
Of course when the folks came to design SIP they obviously couldnGÇÖt do anything about IP deficiencies. So what could they do? (Note, IGÇÖm not a VoIP expert so I may be using some incorrect terminology in this description, for which I apologise in advance).
The firewall traversal issue with SIP is kind of based on poor design of the protocol, and of timeout interaction between the firewall and the softswitch. The firewall has no way to identify SIP traffic (mistake in the protocol) so we have to create GÇ£pinholesGÇ¥ through which SIP sessions can pass. The pinholes time out after 30 seconds I think. In contrast the softswitch registration (which would refresh the pinhole) only happens every hour by default. Winding down this timer will result in the softswitch being overloaded by refresh traffic GÇô a kind of accidental DDoS attack :-)
So why donGÇÖt H.323-based VoIP systems suffer from this problem? Well like SIP traffic, firewalls canGÇÖt identify H.323 packets easily so the protocol designers kind of screwed up there too. But most edge routers today support Application Layer Gateways for H.323 which take care of the pinhole problem. There are probably some kludges under development to fix the SIP problems.
But remember that BSCs donGÇÖt just do Firewall/NAT traversal. They do other stuff too.
In terms on functions that are needed as a result of SIP deficiencies, then the most obvious is the need for a carrier to create a logical demarcation point in the network. Since SIP was not designed for carrier operation, its diagnostic packets can actually carry detail about one carrierGÇÖs network into another carrier. By placing a BSG as the demarcation point this detail is hidden, but the BSG still provides some diagnostic capabilities within a given carrier network.
A third important BSC function is protocol conversion GÇô typically SIP to H.323.
Finally you have CALEA, or legal intercept capability. In true SIP networks traffic would pass directly between subscriber endpoints, and the spooks would have to install huge numbers of GÇ£intercept probesGÇ¥ in the network. By directing VoIP traffic through BSCs then itGÇÖs easy to comply with CALEA, or the equivalent.
re: Telecom Exec: VOIP Is a PainHi Aswath, I have to admit that my conversion to VoIP was driven entirely by my Skype epiphany. To be able to make free calls with near-hi-fi quality to people around the world was a revelation.
Since then I've found plenty of warts on Skype. Like any service that's based on best-effort delivery, the qualoty can be highly variable. I've had lots of calls with the most amazing echo. I've had calls where the other guy was about 30 miles away, but we managed to generate 5 seconds of delay!!!
But at the end of the day it's free, and so who can complain.
So I cannot give you a single example of how treating voice as data can help carriers make money. If I was able to give you such an example I suspect I'd be a very rich man :-)
re: Telecom Exec: VOIP Is a PainThe point is not whether one can come up with an example. I am suggesting a logical way to deduce that given transport, features are derived at the end. So there is no revenue model for SPs. See materialgirl's previous post.
re: Telecom Exec: VOIP Is a PainYou folks are right. SPs cannot make money in an IP world. Get used to it and don't try to fight it any more. Its like trying to keep winter from coming. Freeing ourselves from the constraints placed on us by 100-year old technology is called PROGRESS.
Transport will foil all attempts to make money until it assumes a utility model. That is okay. We get electricity pretty well, and do not expect the electric company to control our use. We can put electricity into a CPU or a hair dryer and the power vendor does not know, care, tax specific uses or monitor what we do (unless we gum up their line). It works. They get their rate of return and we get our affordable power.
While you fret about how a 100-year old voice service gets preserved in pristine shape, Google amasses a $81B market cap and tries to put the world's information at everyone's finger tips. They are all for radical productivity change and world peace through better communication. They have a huge market cap (and getting bigger) and deserve it. They are looking forward, to what IP can do in a new world of possibilities. Don't look back and miss the boat!
re: Telecom Exec: VOIP Is a PainI've spoken to some providers who want to deliberately misorder packets or slow them down (i.e., don't give them the expected best effort for free) when the traffic is VOIP. For many, best effort is pretty good service.
You can get a free ride on their network if it's data, but if it is eating into their other business, then you don't get that same free ride.
(That's from both those providing VOIP services of their own as well as ILECs who are worried if a venture into VOIP is cannibalizing revenue for no gain.)
Seems to me, this is not an easy thing to do, particularly for P2P voip like skype.
re: Telecom Exec: VOIP Is a Pain""So I cannot give you a single example of how treating voice as data can help carriers make money. If I was able to give you such an example I suspect I'd be a very rich man :-)""
I have seen how Level 3's network makes $5-15 per sub per month on voip. Their network is counting on making money on data. Skype is using LVLT as well.
I agree with most of your points. I do agree that VoIP basically enables voice to be yet another data application. I understand that packetize voice holds promise for new and innovative services that legacy services (POTS) could provide. But what are these services? Has anyone really try to innovate on this front? Or is this just a vapor concept? I've been in the VoIP business for some time now, and I can say that I've heard the new services story over a thousand times. But never have I've seen a clear set of capabilities that anyone is able to talk to . Do you have any thoughts or insight as to what exactly are these new services?
A couple of points of disagreement.
1. The need for Session Border Controller is not to overcome "the gaping chasam of inadequacy that is the SIP architecture". It is needed to handle NAT and Firewalls that customers may have deployed. Even the P2P king Skype has SBC function in its architecture (in the name of Supernodes and relay nodes).
2. You are joining the chorus of "Packet nirvana". Please give us ONE example out of the many "interesting new things you can do with it". VoIP is different from POTS in the following three ways:
a. We can assume a sophesticated user interface, what with screen, keyboard, mouse and multiple display window.
b. Message oriented signaling. But this is true only when one compares it to POTS, because ISDN has the same signaling capacity.
c. Ability to communicate to any third party directly. This is true only for Internet, not necessarily true for all packet networks.
SPs will not consider any feature that exploits (c), lest they lose the monopoly control of the customer. The other two is not dependent on packet network. But then again, since many VoIP providers deploy services based on ATAs, they do not have these two advantages.
So we are left with just imitating POTS and forever lamenting on the unfulfilled promise.
Aswath