so now that hangouts uses webrtc, one can do a little reverse engineering using chrome://webrtc-internals

A couple of technical observations:
- the SDPs have a=crypto lines. That is SDES which is makes this technically not webrtc. 
- the a=ice-ufrag is 12345... as is the ice-pwd
- it still uses RTP data channels
- it uses a single port for audio, video and data without using BUNDLE
- this doesn't use error correction like red or ulpfec. We hit some problems with that in the jitsi video bridge (rtp replay attack style). It probably explains why the video quality is mediocre
- it seems to use "Plan B" for signaling new streams
- there are some undocumented but highly interesting flags passed to the peerconnection constructor.

So it looks like their video router is somewhat behind in terms of features. Note that this is just a first step and I do expect to see DTLS -- but this is tricky to get right on the server as +Emil Ivov can tell. 

Politically this is quite interesting. To me it means they care more about solving problems people using webrtc (like talky or jitsi meet) than investing in their own infrastructure.
Thanks +WebRTC -- oh, and dev response times of nine minutes after reporting a webrtc related crash are awesome
Shared publiclyView activity