Ever wanted to whine about federation in WebRTC? Here’s how it gets done.
While I no longer believe in ubiquity and federation in the way the telecom world sees it, I do see a lot of questions around this area. During one of the sessions at the Expo event last week, a question was raised by the audience: “how do you federate all of these scalable services you’ve just talked about?” The speakers didn’t really provide an answer to it, so I’ll start off with what options are there for federation in WebRTC, and then move on to the real question.
1. SIP / XMPP
The obvious way is to have SIP or XMPP signaling with WebRTC. These VoIP protocol are used to federating, so whenever a vendor WANTS to federate, he can just head towards that direction. I made a distinction of WANT, because federations require both networks that get federated to first want that to happen.
2. Open Peer
Open Peer is a new specification proposed by Hookflash for… peering WebRTC services. While I know of no other vendor who is planning/promoting/developing/launching anything in this area, it is something that is out there and can be picked up and adopted. I don’t see this happening any time soon, but I have been wrong before.
3. URL
This is how WebRTC does federation. You’re logged in to a service – be it is friction free as Talky.io, lightweight as Tawk.com, social as Bistri or Twelephone, or closed like Regroup Therapy – and now, if there’s a need to get someone to the meeting, just send him a URL somehow – over email, instant messaging service, SMS – anyway you want. The end result? A user that isn’t a part of that specific service, can join a session – based on the policy set out by the service. He gets federated into the discussion in the most natural way. That doesn’t work for you? Think about it as “the URL is your phone number” if it makes you feel any better.
Why at all would you want to federate?
Is there any reason to federate Jocly games with Vonage? What would be the reason? How about Wello and TruClinic? How about Vonage and Bistri? There might be some need here, but then the two vendors can just sit together and make it happen – if they WANT and see value in it. With a URL option available, the is little need to federate:
- For voice calls, you can just gateway back into PSTN or mobile and be done with it
- For video calls, well… go use Vidtel or Blue Jeans or one of the others out there. Or just use a pure WebRTC solution. The future of video in the enterprise in my view is in browser and WebRTC enabled room systems and not in the closed and creaky H.323 and SIP systems we have today – that’s just darn limiting
Next time you ask about federation, first ask yourself what the reason you need that at all is.
> just send him a URL somehow – over email
E-mail being the most successful federated system today, this line kind of contradicts your point about how federation is not necessary 😉
> 3. URL
> This is how WebRTC does federation.
Well technically not. That’s how WebRTC simplifies silo access.
> Why at all would you want to federate?
How about: So that I don’t have to open an account with every network in the world that gets beyond 20M subscribers and still be able to know who is calling me and make myself reliably known that those that I am caling?
> Is there any reason to federate Jocly games with Vonage?
> How about Wello and TruClinic?
> How about Vonage and Bistri?
Do walkie talkies need to federate with the PSTN? Does the huffpost forum need to federate with the one in Le Monde?
No.
Does this decrease the importance of federation between AT&T and Vodafone, or between Gmail and Hotmail?
Well… we’re talking about WebRTC here, and the complaints that it doesn’t come with a signaling protocol or a federation solution.
And it doesn’t need it. It is the telcos that need it, but they already have it in the form of PSTN or IMS. The vendors trying to sell them are pitching having WebRTC as just an access point to IMS, so there’s no issue.
> Well… we’re talking about WebRTC here, and the complaints that it
> doesn’t come with a signaling protocol or a federation solution.
Those are indeed your 1 and 2 optoins. Your point 3 kind of sounds like: “But why on earth would you need the crap from 1 and 2 anyway”.
That’s what I was trying to respond to :).
> And it doesn’t need it.
The tech doesn’t need it, because you can build it on top. This is very different from your point 3 which is that it’s not necessary at all.
> It is the telcos that need it,
No actually the telcos are exactly the people that DON’T need it just because lack of decent federation mechanisms on top of WebRTC, would mean that we will end up in the SIP situation where everyone federates through the PSTN, making money for the telcos.
Emil, I already have multiple Internet identities, whether I like it or not, but they are all appropriate ways to find me and communicate with me – be it Twitter, LinkedIn, Facebook, G+, About or whatever. To the extent I want these identities connected, it is going to be quite appropriate for me to simply LINK these to whatever WebRTC Portal I choose to use and that becomes my real-time “federation” point just for me. Yours may be different. For example, via my Twitter handle you can already easily find me on Twelephone, and I can link to that exact same WebRTC portal from other services. This is not hard and there is no extra overhead for me here apart from having to manage my separate online identities, which I have to do anyway if I choose to be on them, quite independently of WebRTC. I wrote some thoughts on this myself at http://bit.ly/1d8fw52 and in a previous Portals article.
Lawrence, what you describe is mostly “aggregation” rather than “federation”. Aggregation is a good thing especially if you want to use three different identities for your family, tennis club and professional contacts.
Lack of “federation” means that you need to have these same three accounts on FB, G+, Twitter, LinkedIn, GitHub, identi.ca, etc.. It’s either that or you have to make one of the following compromises:
a) accept that you can be contacted anonymously by anyone in the entire world who knows or guesses your URL
b) limit incoming communication to only your favourite social net identities (with all the dependencies that this implies) and accept that you will not be reachable to people not on them.
A second very important point of federation is a persistent user interface. I’d reasonably annoyed if every time I call a different person I have access to a different sent of features and need to use a different UI. While this is simply annoying to me, it would make WebRTC outright prohibitive as a default means of communication for a large subset of the population.
Now all that said I have to admit that I am wondering why we need to be arguing about this. Federation is perfectly implementable over WebRTC. If you don’t want to do it for your service, that’s your choice. Just don’t go telling people that it’s because it doesn’t serve a purpose. 🙂
I think we are precisely debating “what is the purpose” of federation in many (although certainly not all, yes it’s a choice) WebRTC use case settings :)! I agree I am talking about aggregation rather than federation, but that with Tsahi’s URL is all I need for you to find me and communicate with me.
On your “a)” and “b)” aggravation (rather than aggregation) topic, traditional PSTN federation has certainly never been enough to stop arbitrary cold-callers from finding my phone number and calling me with cruises to the Bahamas, carpet cleaning, and worse!! So what has this to do with federation? To seriously deploy a WebRTC portal I am going to need much more control about who and how people can access me and I am expecting such tools to appear (I happened to write on this at http://bit.ly/Byrd-WebRTC-3). Google Voice was a good early example of providing a question and ask me option that greatly reduces crank calls and I believe there is a wealth of innovation possible in this area for WebRTC portals, and this can certainly include your proximity in certain social graphs (as it does for forms of text messaging today). And since it’s my portal I will get to choose how this all works for me (given the tools).
On your “different UI for everyone annoyance” point …uuurrh… tough :)! I agree with Phil Edholm that this is what’s going to happen and is not different getting a different experience at every person’s web site I visit! Now coming to real-time communications too! Sorry. Although normalization of embedded widgets in my social sites may perhaps reduce this a bit.
> 3. URL
> This is how WebRTC does federation.
[…]
> A user that isn’t a part of that specific service, can join a session – based on the policy set out by the service.
You’re right, except that this isn’t really “federation” when only a single service is involved. There is no identity here unless you create one on that service. That is what true federation solves – the freedom to be me across multiple services, while I can still reliably identify you, who isn’t registered on the same service as me.
It is in the eye of the end user. Federation just enables me to contact you.
If I can press a URL and contact you, then what else do I need?
As for identity – a WebRTC service can do that by placing that information in the URL, ask for a name, email, pressing a Facebook Connect button or any other means that we are already used to use in the brave new world of the internet and the web.
Only requirement for federation is being part of a platform based on DNS + IP transport; I think it’s called Internet. And yes, on top of that you can federate identities.
So i’m using (1) to solve (3). Where does that put me?
This has the advantage that implementing stuff like presence is a complete no-brainer. Took an hour to implement on the website and it’s absolutely worth it from the user experience point of view.
I still leave the choice how you contact me to you. Either use my JID (and your system) or the portal page. If we’re compatible, yay, use your client. If we aren’t… well, use the portal page.
I still prefer 4 (alternative to 2 I guess):
https://air.mozilla.org/intern-presentation-seys/
Draft is written by someone actually involved in the standardization process:
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07
The presentation uses Persona/BrowserID. The draft is made so it even works with oAuth. oAuth, you know what is already supported by: Google/Gmail, Yahoo, Facebook, Twitter and Microsoft/Outlook.com/Hotmail/Live.com/whatever.
Not sure if I view identity the same way I do federation… you can have either one of them exclusively without the other or both in the same service.
Both OpenPeer and the draft try to do similar things. Tie an identity to the call. WebRTC uses (D)TLS for encryption.
Encryption is pretty much useless if you don’t know who you are talking to, because you can’t know if there is a man-in-the-middle*. Any security professional will gladly explain this to you.
Also Identity isn’t binary. Many people have many identities.
For example, if properly set up, you could make it so multiple people can identity themselves as:
[email protected]
The advantages I see for the draft in comparison to OpenPeer:
– supports a model where it is natively integrated in the browser, for proper security (still allows for the use of/by apps of course).
– there is very little to set up at the domain being used, BrowserID/Persona even has a fallback method where they just do email address validation. In that case there is nothing to set up at the domain. While the domain still controls their identities, because email address validation is only used if there is nothing set up at the domain. And there is even a fast-track identity bridge with oAuth for certain domains like gmail.com (no need to wait for validation emails).
– BrowserID protocol also is privacy preserving. The domain owners don’t know who is talking to who. Just someone from my domain X is talking to domain Y.
What is really important for adoption of a standard: app developers don’t need to put in a lot of work, it’s already part the browser and hopefully available as a library.
Even more important: Identity providers don’t need to do anything. As Persona/BrowserID has support for just doing email address verification.
So adoption is easy. Especially if multiple browsers will support it natively.
* I wonder why it never is a woman ? 😉