pthatcherg

There is no WebRTC 1.1 yet. 1.0 isn't even done yet. Once 1.0 is done, then work on 1.1 will start. ORTC maybe be adopted in whole or in parts as 1.1, but the future isn't written yet.

ORTC and WebRTC are separate groups in the W3C. You can think of the ORTC "Community Group" doing more exploratory work on a future version of the API while the WebRTC "Working Group" is finishing the 1.0 version. The work the ORTC Community Group is doing may or may not be adopted by the WebRTC working group as a future version someday, or maybe it will adopt some parts but not all.

The currently drafted ORTC API still allows all of the power to the Javascript apps to interoperate with "legacy stuff", but it also allows the JS to bypass most of it.

(I'm a member of both the WebRTC Working Group and the ORTC Community Group)

If you can get a peer-to-peer connection, it's irrelevant whether you're behind a NAT or not. That's what ICE is for: to get a peer-to-peer connection even if you're behind a NAT. Having publicly routable IPv6 addresses may increase the likelihood of getting a peer-to-peer connection, but it's not a prerequisite.

ORTC doesn't really have anything to do here, except nicer control over some configurations that you can already control with SDP munging.

Simulcast/SVC, for example, are irrelevant outside of multiway video. And you can already do simulcast with WebRTC.

Think of WebRTC 1.1 as a slightly lower-level API with more controls for the same components that exist in WebRTC 1.0. For advanced applications, this additional control is very important. For basic applications, the differences in the APIs aren't as significant. One is not more secure than the other.

The WebRTC 1.0 API can be implemented on top of WebRTC 1.1. The wire-level protocols are the same, and so a WebRTC 1.1 client should be able to connect to a WebRTC 1.0 client (modulo all the normal interop issues that exist regardless of the API version). It's just a matter of which API the JS sees. It may be that by the time IE implements WebRTC 1.1, there will be JS libraries that implement 1.0 on top of 1.1, so that you could continue using the 1.0 API if you want, even in IE.

TL;DR: Cisco's solution to binary plugins in Firefox is a "binary module" downloaded from Cisco.

Snippets from the text:

"One big barrier remains: users can’t collaborate directly from their web browser without downloading cumbersome plugins" ... one of the major stumbling blocks in adoption of this technology is a common codec for real-time video ... Cisco ... providing ... a binary module that can be downloaded ... today’s latest release of Firefox, which will automatically download and use Cisco’s OpenH264 binary module ... The topic of a standardized codec will once again be addressed by the IETF in its November meeting. It is our hope that announcements like the one today will ... pave the way for a decision."

A decision that requires an open source web browser to download a binary module from a third party?

Another option would be to use the free and open source video codec that's already in every WebRTC-enabled browser, without any binary modules.

You can't have video chat with audio, video, codecs, p2p, the whole thing. The only piece you can remove from the whole and still have video chat work is the data channel.

If all you want is the data channel, then you can ignore the audio/video part, and just use the data channel separately. It doesn't do you any harm.

While we don't provide a build target for compiling the data channel without the audio and video parts, it's not that hard to remove from the build. It's just some build file hacking (basically remove webrtcvideoengine.cc and webrtcvoiceengine.cc).

Would you mind filing an issue at https://code.google.com/p/webrtc/issues/list to ask us to make a nicer build target? It won't be top priority, but we get around to it. Or better yet, if you get it working, send a patch. We'd probably include such a build target.

There are a few different layers to the WebRTC stack. I believe they use the lower layer which does the video and audio processing. But they don't use the higher layers from which do ICE, SCTP, and SDP.

That would be news to me. They aren't listed in the AUTHORS file:

https://code.google.com/p/webrtc/source/browse/trunk/AUTHORS

It's on my TODO list to try and make Go bindings for WebRTC :).

I'm pretty sure this RFC draft qualifies as defining the SDP for an independent implementation:

http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-07#section...

I applied to Google. They hired me. I worked on Google Talk and Hangouts for many years. WebRTC was related and interesting, so I worked on various parts (such as the data channels) in my 20% time. After a while, I liked it so much I chose to make it my 100% time.

We put some WebRTC things on github, like AppRTC:

https://github.com/GoogleChrome/webrtc/tree/master/samples/w...

Signalling is already removed from the WebRTC API. ORTC doesn't change that. All would change is not needing to use SDP as the API surface. But that's API surface, not signalling.

Chrome WebRTC developer here. Two quick thoughts:

1. A better headline would be "Ericsson open-sources another WebRTC implementation". WebRTC is a set of standards, and they are implementing them, which is one of the purposes of having standards: to have multiple implementations.

2. One of the purposes listed by Ericsson for having another implementation is to "transcend the pure browser environment and that native apps ... would become an important part of the WebRTC ecosystem". What I would like to point out is that the implementation of WebRTC found at webrtc.org (ie Chrome's implementation) already supports mobile and native apps. In fact, the documentation is linked to right from the front page:

http://www.webrtc.org/reference/native-apis

And there are lots of native/mobile apps that already use it.

Chrome has not said it will support H264 in WebRTC.

That's correct. I updated my comment.

By the way, someone else commented further down that Apple doesn't allow third party apps to use it for realtime (video chat). But I can't verify if that's true or not.

Is it usable for realtime video? Are there any video chat iOS apps that use it?

Edit: I mean usable by apps other than Apple-owned apps such as Facetime.

I sure hope he's wrong. Personally, I think a patent-encumbered MTI codec for WebRTC would be a very bad, especially for the open source community:

- You can't have a spec-compliant implementation of WebRTC by compiling and running Firefox yourself. You need to download extra binaries from Cisco.

- You can't have a spec-compliant implementation of WebRTC in your Linux distro, without including binaries from Cisco.

- You can't write an Android app that uses the library from webrtc.org to interop with WebRTC in the browsers without downloading binaries from Cisco (unless you pay the MPEG-LA).

- You can't write an iOS app to interop with WebRTC in the browsers, at all, because you can't download binaries from Cisco (unless you pay the MPEG-LA).

- You can't build open source projects that fully interop with WebRTC, without dancing around all the lingering patent issues.

In all these situations, having h264 as the MTI is worse than having no MTI at all.

Only if you use the binary module, not the source code.

That's the "Good News". Now for the rest of the story:

The open source part of this is nearly useless, if not completely so, as evidenced by the fact that Firefox won't be using the source code. The "you don't have to pay the MPEG-LA" part only applies to the binary module. If you want to pick up this code and ship it in your own software, you'll still need to pay the MPEG-LA.

The reason they are doing this is to put more weight behind H264 in the political battle in the IETF over the MTI video codec for WebRTC. But if they succeed in making H264 the MTI, and you want to write a mobile app that interops with WebRTC for doing some form of realtime video, you'll won't be able to use their source code without paying the MPEG-LA. You'd have to use their binary module, downloaded from their servers, which, as they mention in the Q&A, is impossible on iOS.

The announcement seems to try hard to smudge this distinction and push it into the fine print, but there's still a patent "elephant in the room".

TL;DR: This doesn't solve the patent issues surrounding h264, and doesn't make it anymore suitable as an MTI for WebRTC.

FYI, there is no official standard video codec for WebRTC. For audio, the MTI codec is opus. For video, none has been chosen. So far, the two browsers that implement the WebRTC API have choose to support VP8, but that's not mandated by the standard.

If you have enough upload bandwidth to send HD and they have enough download bandwidth to receive HD, at least they'll be able to see you in HD.

As for if they have enough bandwidth for HD, there's only one way to find out :)

Hangouts works with all of the major browsers, including IE. What exactly is your complaint?

As far as I know, the only issue with large messages is that while they are being sent, they'll reside in memory. But that's true even if you break up the message into smaller pieces and call send() in smaller chunks all at once. So, it's really a matter how much data you pass to the browser via send() calls at any time. The more you do, the more gets buffered in memory.

I'm not really sure what is optimal for chunk size, but I think the real target is about keeping the buffered amount low, but non-zero. Lower means less memory used, but zero means you missed out on bandwidth you could have used. Choosing a chunk size probably doesn't have a large impact on that, but you won't know for sure until you try different sizes. It would be interesting to see an article that experiments with different sizes and different buffered amounts and tests the results.

Thank you for your excitement for data channels and willingness to use the bleeding-edge stuff. I'm the author of the RTP-based data channels in Chrome, and I've been working hard to update those to be SCTP-based data channels. We now have SCTP-based data channels in Chrome M30 behind a flag, which will hopefully graduate to "not behind a flag" in M31. I apologize that it's taken so long and that you've had to do so much to work around the RTP-based data channels. Such is the bleeding edge, I suppose.

Also, I think it might be a good idea for readers to update the article with a few notes and fixes. For example:

- SCTP-based data channels don't require messages to be less than 1200 bytes. The RTP-based data channels do. In other words, SCTP-based data channels will break up your message in chunks for you, so you don't have to when using SCTP-based data channels.

- SCTP-based data channels support binary data, so you don't need that base64 encoding when using SCTP-based data channels.

- SCTP-based data channels always do congestion control, so any "flow control" in JS is really just controlling how much data gets buffered by the browser. It's a good idea not to make that grow too large, but it doesn't effect what is sent on the network, unless you let the buffer go empty.

- It is not correct to say "to optimize transfer speeds, unreliability is key". Doing reliability yourself on top of unreliabile mode in JS will not be any faster. In fact, it will probably be slower. What you may want is unordered data, meaning you can get the file chunks out of order. But that won't speed up getting the whole file; it will just speed up getting a particular chunk. If I were you, I would use reliable, but perhaps unordered mode, which SCTP-based data channels support.

- The bandwidth hack for sending more than 30kpbs with RTP-based data channels is probably a bug, and I wouldn't recommend relying on it.

- WebRTC always uses ICE, so it's not accurate to say "ICE or just STUN", it's more like "ICE with TURN or ICE without TURN". Either way, it's still using ICE.

I was only guessing about the chrome tab mirroring feature. Are the other features limited to the Pixel?

It's probably because of CPU power. Encoding high resolution video take a lot of CPU power, and the Pixel has more CPU power than other Chromebooks.

To do p2p without C++, you have to implement ICE or the equivalent. Sounds like a fun thing to do, especially but it's going to take a lot of work. Then once you're done with that, you'll need to implement reliable delivery with congestion control on top, which also would be a lot of fun but a fair amount of work to do properly. Finally, you'll want to add encryption in there; luckily, Go has good crypto libraries, but getting crypto right is still really hard and it's easy to mess up and have an insecure system. At the very least, you could use libjingle as your guide.

By the way, what do you mean by "not to use C++"? Do you mean write it in it, or do you mean use libraries written in it? I can understand the former, but the latter seems a bit extreme. Go makes it pretty easy to link to C libraries. Why not use libjingle from Go? That sounds fun and a lot less work.