WebRTC is great, but it isn’t for everyone.
[I am off for vacation, but decided to schedule posts this week in advance. Feel free to comment and share while I am enjoying Italy with my family]
Here are 5 things I suggest you seriously consider stop doing if you are into WebRTC.
1. Build another generic video conferencing system
I get it. Video is still something of an innovative idea. Especially for those developing with it for the first time. The idea of jotting down a few lines of code and having a talking headz experience may seem novel, but it isn’t.
It is tiring to watch yet-another-free-groundbreaking-web-based-video-system. There are literally a hundred of those around. Most of them free.
Now ask yourself: why would anyone use your service and not someone else’s?
It won’t be because you have a nicer design, support a different layout or think you have this cool screen casting feature baked it. Newsflash – many others do.
If you are into this kind of a thing, then start with the use case. Once you nail that down, check if there are already players in that use case, and explain why you will succeed better. Be harsh on yourself in the comparison and not too optimistic. It is a good mindset at the planning stage.
2. Use WebRTC to connect your state of the art RCS system
Got RCS lying around somewhere, based on your beloved IMS network? Great.
Found out that WebRTC can do miracles for browsers and you think of adding that to your RCS service? Great.
Just do everyone a favor and don’t think that can compete with a WebRTC service that has no IMS in it. It can’t.
OTT services are moving so fast these days, that literally every month they change their behavior, user experience and business models. New messaging services come and go with interesting paradigm. Should I say Yo to make a point here?
Using IMS mentality for WebRTC is bad for your health.
IMS and RCS aren’t designed for such a fast paced world. By all means – build these systems if you must – add WebRTC as access points to them. But make sure you compartmentalize that properly. They are not OTT killers.
A better suggestion I have for you is to think how you can use WebRTC without forcing it to fit into your existing architecture. Use whatever legacy systems you have only if you must.
3. Use G.711 in WebRTC
If you plan on rolling out WebRTC with G.711 and skip Opus, then think again. This is what you should expect from such an implementation:
- Narrowband voice (phone quality = poor experience)
- Interference, since there’s no FEC baked into G.711
- High bandwidth use (compared to Opus)
All the above boils down to bad media quality, and something that may not fit at all into mobile and places where bandwidth is limited.
Don’t be lazy and make sure Opus is part of your implementation.
4. Use HTTP with WebRTC
WebRTC is secure. It is the most secure option out there. Why kill that with HTTP?
If you develop a WebRTC service, then know in advance that this is how Chrome is going to treat your service:
| Local file | HTTP | HTTPS | |
|---|---|---|---|
| Access to microphone | None | Ask permission each time | Ask permission once |
| Access to camera | None | Ask permission each time | Ask permission once |
| Access to screen capture | None | Not allowed | Requires a Chrome extension |
When you start a WebRTC session, the browser will ask permission to access the camera and microphone. This is a added friction which means it is another barrier between the user and your service. Since we want to reduce as many barriers as we can, it makes sense to adopt HTTPS.
HTTPS has its own advantages in a service – up to the point that I am contemplating on adding it to this blog of mine just to practice using it.
Want to learn more about HTTPS and why it is important? Check out these Google I/O videos:
5. Deploy without TURN
I know. You are a web developer. The most you are comfortable with besides writing a great SPA experience is whipping up a Node.js server for that signaling you must add. WebRTC requires traversing NATs to operate. While checking WebRTC locally will work without TURN, I promise you that there will be those complaining your service just doesn’t work. This will happen because they will see it on a mobile network or from an enterprise with a restrictive NAT.
Better take the time to implement and integrate TURN properly, and if you are lazy, just use a SaaS option – check out XirSys for example.
Anything I missed?
WebRTC is a great technology, but it may not fit everywhere and you should understand what you are doing if you decided to use it.
Your turn now. Are there other suggestions you can give on where not to use WebRTC?