Aswath Weblog

Who needs Federation in WebRTC

This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.

In a recent post Chris Kranky on the need “to move on” and the need for expediency in wrapping up the first iteration of the API. Personally I would have benefited if the first iteration had been a low level spec. For I could have easily ported a custom Java applet. But given the passage of time, it is more important that there is an agreed standard. But this point is not the objective of this post. Instead I would like to focus on another of his points:

[WebRTC] wasn’t designed to be federated (namely that 2 WebRTC applications aren’t in fact supposed to talk to each other.

He makes this observation to explain the motivation for seeking low level control. My quibble is not with this explanation, but I want to take this sentence in isolation, interpret it literally and discuss it. (It is not fair to Chris, but I am just using his sentence as a prop. So it should be OK with him.)

In my interpretation, if WebRTC is not designed to be federated, then there is some deficiency and need to be addressed. If not immediately, but at some future time. But with WebRTC construct there is no need for federation. Let me explain.

Following are four main reasons why we need federation and how WebRTC handles them without requiring federation:

1. Reachability information is not widely held, except for some selected nodes in both the systems.
   
   Since WebRC address is HTTP URI, the originator’s service provider or system is not needed. The originator can directly access the destination’s system. Indeed, it is not required that the originator be part of any service provider or system.
2. 
   Communication between the systems may need mediation to handle incompatibilities.
   
   Since the app server dynamically downloads the signaling procedures, there are no incomptibility issues on the signaling plane. I further assume that MTI codecs remove incompatibility between the browsers. In any event, any such incompatibility can be solved w/o the two systems federating.
3. 
   Identification and authentication of external nodes need to be mediated.
   
   Since the whole construct is built on HTTP, any of the third party verification systems can be used to identify and authenticate the end-points. In this respect there is a need for federation, which is much less stringent requirement and can be easily waived by the end points depending on the use case.
4. 
   Since the external systems may not be trustworthy, the local system need to protect its users.
   
   WebRTC has builtin security systems to protect the end nodes from malware apps. Specifically, the browser ensures that a rogue app can not assume control of the end node.

In my opinion the fact that WebRTC does away with federation is one of the important benefits and why it is going to disrupt communications industry.