In the final part of this WebRTC disruption blog, I will explore the impacts of moving to WebRTC on the network some more and finish the discussion I started last week about interconnecting WebRTC to the “real world”.
One interconnect to the real world that needs to occur is regarding the use of functions like IVRs and conferencing. If a browser-to-browser experience is more the norm, what if the recipient of a call cannot (or doesn’t want to) answer the phone? This happens to me on Skype today since I have various ways to talk – desk phone, Lync, cell phone, and Skype – and sometimes I’m getting pinged on Skype (or Lync or cell phone) and I’m on one of the other devices I’m not ignoring you folks, I’m just busy! Well, sometimes I am ignoring you. You know who you are…
Anyway, just because my Skype profile says I’m available doesn’t mean I’m actually “available”! And what about speech enabled IVRs that enable a caller to “talk” to a computer? These IVRs will still likely be similar to today’s IVRs- it’s just the phone call coming in that will be different. IVRs still need media servers! Even if IVRs become cloud-based systems, they still need media servers. What about conferencing, which is a very potent use case for WebRTC? Multiple people can point their browsers at a website, thereby enabling a “conference”, but conferencing (such as loudest talker algorithm, call recording and echo cancellation) is hard. Thereby, yes, you guessed it - media servers will need to be involved in conferencing as well.
Going to the next level- what about those “millions” of Java developers who can simply enable phone and video calling now? Yes, I believe there will be massive amounts of innovation, and communications I cannot even fathom coming out of WebRTC. These “millions” of developers can initiate all kinds of voice and video calls, and do it much easier and quicker. But for the calls that don’t go through or morph into something more complicated, a media server will most likely be involved somewhere in the equation to sufficiently complete the calls. (Yes, I think you are getting my point. Media servers will still be required!)
From a transport perspective, Secure RTP (SRTP) is the RTP transport for WebRTC. However, if the application connects outside the WebRTC realm, SRTP may not be supported. Translation will have to occur. This could be done either in the media server or in the border element, which is likely to be in the Session Border Controller. Other changes to the SBC will be the need for additional firewalls (WebRTC firewalls) to protect enterprises and also translations to the security mechanisms. I would harken this to the need for SBCs to protect the enterprise to/from other IP networks interacting with the enterprise.
Ultimately, WebRTC will be disruptive. Communications applications could be created by millions of developers. We will see applications in the market that we can’t even dream about now. And, all of this will elevate the way and speed at which we communicate. Dialogic will be there- behind this disruption and subsequent elevation. And we can’t wait!
