URLs in emails is part of our future. Don’t waste time complaining about it.
Each blog has a subtopic that when written about – all hell breaks loose – it brings the comments in. For most technology blogs that would be saying something bad about Apple. For my previous blog, it was definitely XMPP. And here? Probably federation. Who would have thought that a post outlining the options of federation with WebRTC will bring so many comments.
This being the case, I had no choice but to write about this topic yet again. We’ll see what happens next.
–
Philipp Hancke, who commented on my post, and is very involved in the realm of XMPP, wrote a post about the fact that sending URLs isn’t a signaling protocol. While I agree to this statement, I think it is irrelevant. And I had to somehow comment.
Essentially, there are four reasons Philipp gives:
- Sending emails isn’t real-time. There is a need for an acknowledgement of receipt
- Due to lack of feedback, the caller might hang up, and then how the callee gets notified?
- The callee might reject. How is the caller get notified?
- What happens to the URL after the call? Is it an identity? Does it become invalid?
Somehow, these reasons are unsatisfying. They assume that the basis of communication is a telephone session. While that may be true, it isn’t necessarily the case. They also assume naively that the URL is the only mechanism in the proprietary signaling protocol, and it ends with the assumption that there needs to be an identity of sorts.
Here’s how this doesn’t match reality.
Acknowledgement of receipt
Emails can do acknowledgement of receipt. Nobody uses that, but they do. At least Outlook does.
I can also acknowledge the press of the link if the URL being sent has some identifying key/hash/whatever in it that is unique to the participant I invited.
Thinking about it, even when I dial someone, I can’t really know if he missed my call because he didn’t hear the ring, was just busy doing something else and couldn’t pick up or something malfunctioned on his end.
Besides – I can always ask – or place the email in a calendar invite and wait for an acceptance, which is an acknowledgement of sorts.
Notifying on rejections and hang ups
What this is all about? Handling rejections and hang ups can be done once the URL is browsed. It is up to the application developer to figure this one out and to build it into his solution, which is the whole idea of proprietary – let the developer of the service decide what fits into his scenario and don’t bog him down with all sorts of modals that might not even fit what he wants to achieve.
Identity
Identity who? Why is that needed exactly? I do a lot of different types of calls. The business ones often times end up on one service or another at a virtual space, either a static one or an ad-hoc allocated one – with a one time URL.
Who cares?
When I care, I select an identifiable service – with our without a URL attached to it.
–
Signaling protocols are no essentially irrelevant. They are needed and necessary, but they are by no means important or at the heart of a solution. What I am seeing is a large number of vendors forgoing treating signaling as some Holy Grail and just packing it into the application logic layer – where it should really reside if you are trying to deal with customized business processes.
Need SIP or XMPP? By all means use it, but why force it on the rest of humanity?
Why is this such a recurring topic? What’s the point in trying to convince people that federation is either all good or all bad? Same for mailing URLs?
Isn’t the whole point about WebRTC to allow every developer to make the choice for themselves?
WebRTC can work with federating protocols or it could also be very convenient for building silos or meetme pages where URLs have to be mailed. Both models would have pros and cons in different situations.
Insisting on picking a winner is so unnecessarily religious!
Emil,
I am fully in agreement with you here. My gripe is with those who see standardized signaling in the form of SIP or IMS as the all-encompassing solution – suggesting it as a critical addition to WebRTC that will save it from itself. This is a narrow minded view of the world.
Well, what you just said here is not exactly the same as what you have been blogging lately :). You often come out as meaning “doing [standard protocol here] and federation over WebRTC is the dumbest thing one could come up with” … this is quite different from “there are many, many use cases where [standard protocol here] and federation over WebRTC would not be required.”
For services that do decide to integrate federation, one could only hope that we can do better than “just go over the PSTN, so that we can get a buck”.
Going to PSTN in order to get a buck is admirable – and a smart move. Integrating any other federation solution requires a good reason to do so – mainly the fact that you already have that signaling stuff somewhere in your solution, so adding it on the WebRTC side of the house makes sense.
The only other reason I can think of is if you are comfortable with XMPP or SIP and just want to integrate it.
> Going to PSTN in order to get a buck is admirable –
> and a smart move.
I suppose you are saying this because all the OTT providers who rely on this for revenue are doing so well these days and are just flushed with money.
> Integrating any other federation solution requires a
> good reason to do so
Right, I guess that’s because “wideband audio”, “video”, “media encryption” and such are not good enough?
You should see what my email footer has been containing for a couple of weeks 🙂
I assume it has something to do with WebRTC 😉
So to summarize, your answers are:
1. Acknowledgement of receipts and real-time:
Email can (via DSN/MDN) give you some feedback, as can payload protocols like iMip. You’ve not commented on whether these should be real-time or not, there’s an implication throughout the post that real-time isn’t important to real-time communications.
Now I entirely agree that for some modes of communication, such as arranging a business meeting or “webcast” at a specific time, realtime signalling, and feedback, isn’t required. But if I want a quick chat with my mother, then I don’t want to be reliant on her checking her email with a MDN-capable client, or worse an iMip one. You’re seriously suggesting that if I want to call my wife from the supermarket to ask whether we need milk, I’ve got to schedule an appointment? My wife *is* organized, I grant you, but not that bad.
2. Notifications of rejections and other signalling feedback.
So your answer here is that to reject a call, you’d accept the call, and then reject it.
I suspect in practise, people would ignore it rather than explicitly rejecting it. Nobody picks up the landline phone right now and says “Hey, sorry, can’t talk” and dumps it. People do, though, hit the reject call button on mobiles – because it’s there at the call request time.
You also note that signalling can be done in an ad-hoc way. I refer you to your post on why we’re largely stuck with SDP.
3. Identity.
Sometimes, you say, you don’t need identity. Therefore we should never have it.
Yes, it’s true that in some cases, you don’t need identity. In some, you don’t need federation. In the vast majority, you don’t need to make a voice or video call at all. Let’s forget this WebRTC stuff, it’s obviously unimportant.
Use-cases are not democratic – if you assume that in the majority of cases, a particular feature is not needed, it doesn’t follow that it can be done without under all circumstances. In any case, by suggesting you want to send URIs via email, you’re basically acknowledging that identity in some form is actually tremendously important.
The fact is that signalling, federation, identity and all these things are – sometimes – of paramount importance. And for those cases, you don’t want to try to reinvent something that’s hard to get right – you want to stand on the shoulders of giants, to paraphrase Newton, and build something awesome without having to reinvent the wheel.
The important thing to recognise is that you really shouldn’t be caring at all about signalling. Just grab a library that does it for you. XMPP is a protocol, implemented by a number of web-friendly libraries, that’ll do signalling for you in a federated manner. There’s no particular magic here, and it’s possible to reinvent all of XMPP and Jingle if you’re willing to put the hours in, but the technology already works well enough that Hangouts is built around Jingle – so honestly, you’d need a seriously impressive set of reasons to *not* want to use it.
Dave,
While I do agree to most of your arguments, they can be refuted by implementations and hacks around the issues. As for why I don’t think XMPP is that interesting – it isn’t because of my own experience with it, but rather with how developers are currently implementing their real life WebRTC use cases: out of the 38 interviews on this blog, only 3 stated they actually use XMPP signaling for their WebRTC implementation.
Tsahi, I think you should see all this hubbub as a WebRTC feature! Obviously the point of having signaling be undefined in the standards is to enable massive amounts of argument, debate and faux-rage as everyone pitches their carrier pigeons as being better than XMPP, SIP, SS7 or whatever :)! Meanwhile it doesn’t matter. What matters are compelling WebRTC-enabled applications, dramatically better user value, and new disruptive ideas that no-one else has thought of yet. Whoever accomplishes this gets a free “win” because they can then say “Look at my great app with many users, and by the way I used chicken soup for signaling so it must be good”. I happen to now believe there is a greater chance of XMPP and/or SIP being in that soup because I am observing a number of really smart developers (present commentators included, of course) arriving into WebRTC who happen to have those tools is their weathered kit-bags. If it works for them and they then build great apps, then their approach wins. But if all they do is waste time arguing about the theory, then they lose. Great feature!