WebRTC doesn’t necessitate n SBC. Your use case might. WebRTC doesn’t need a gateway either.
The Session Border Controller is relatively new. When we first started off with VoIP there was no such entity in the specs. In a way, the SBC is a technical solution to a real problem – SIP had a few major flaws that made it impossible to use:
- It didn’t interoperate well. Different vendors had their own proprietary extensions or just interpreted the standard a bit differently
- NAT traversal was broken in SIP. It was there, but nobody really used it
With these two issues, the SBCs of the world started offering a solution that you as an enterprise can place at the edge of your network and “fix” these issues. The SBC acted as the intermediary between different equipment, and based on its location in the network – it also offered means to traverse firewalls by acting as one for VoIP traffic. Which lead to the SBC being touted as a security measure. With time, transcoding was added as another capability to SBCs.
Fast forward to WebRTC, and we see SBCs adding WebRTC to their bag of protocols and tools. The reason? WebRTC is just another access point into the networks of their customers.
While all this is true, here’s the thing: in my opinion, most use cases in the future are NOT going to be the traditional ones. Our interactions will migrate to the web, and a lot of them won’t really look back at all the telephony and VoIP infrastructure we already have. This greatly reduces the need for an SBC since WebRTC doesn’t suffer from the same issues as SIP:
- Interoperability in WebRTC is between browsers. With only 4 of them (2 implementing WebRTC now), there’s little chance of it not working well
- NAT traversal is a part of WebRTC in a way that doesn’t necessitate any SBC replacement for it
- Security is ingrained into WebRTC, so no need for help from an SBC here
The same applies to gateways. While these are necessary for use cases where you want to connect with an existing telephony network (traditional or VoIP), in many situations this isn’t going to be the case.
If you want to develop a service, you might not need an SBC or a gateway. The question you need to ask is what is your use case and what requirements do you have for it.
The Big Question
And now for the big question.
WebRTC doesn’t need the NAT traversal mechanism originally offered by SBCs.
The more WebRTC gets popular, the more STUN, TURN and ICE gets used; and the more that gets used, the more we will be seeing it with SIP deployments as well.
In such a case, we will be needing less of the SBC… taken to the extreme, are the days of the SBC numbered?
What you are describing is the eventual replacement of the wired PSTN with the wireless IP network and “cloud” based applications and information storage. The migration will, however, take time.
Arthur,
Not really. SBC is pure IP. What I am describing is the migration from “traditional” VoIP network architecture to a web one. And yes – it will take time.
I agree, the reason I first deployed an SBC in 2004 was specifically due to a carrier that had double NATing in their network. So really because one of the 3 big telcos forced us to with our ATA based residential VOIP service. With our free soft phone service we used our own STUN and TURN servers 10 years ago with pretty good success and no SBC.
The reason we use a SBC today is to provide 1 public interface into our cluster of backend media servers, to save on public IP addresses. Perhaps the combination of webRTC, IPv6, and ICE will kill the full featured SBC which is what there are no pure play SBC companies left.
+1
I agree with the statement that pure webRTC application does not necessitate interfacing with telco networks and hence a limited need for a webRTC gateway or an SBC function (in the traditional way it is deployed today). It is use case driven. There will be whole slew of new applications and use cases that will not even touch traditional telecom networks; but at the same time we all should realize that telecom network is the biggest social network we have where anyone can reach anyone and can’t be ignored.
The telcom carriers and enterprise networks are still transitioning from PSTN to SIP based IP network…so SBCs are here to stay for a long time. WebRTC gateway will be key for telcos and enterprises to extend their IP based services to web and embed them in native or web based mobile applications.
In my view it’s not about Web vs Telco. It is the Web+Telco that creates the true value.
Check out my blog where I have put together some analysis on different webRTC implementation approaches and role of SBC in the WebRTC world.
Will the Alchemy Between WebRTC and SBC Create Solid Gold?
http://blog.realtimecommunicationsworld.com/will-the-alchemy-between-webrtc-and-sbc-create-solid-gold.html
Ashish,
I think the value of an SBC is overstated when it comes to WebRTC, but I am feeling that enterprises will buy in to this overstated value of it anyway.