On this page you will find the results from an investigation into WebRTC conducted by the Service Activity 8 (SA8), Task 2 team of the GN4-1 project. Both the end report (WebRTC roadmap) and the internal deliverables (reports, proof of concepts, code) leading up to the end report are available here.
Reading guide:
The WebRTC roadmap report builds on the combined result of discussions within the task, observations done through-out the task period and the results of various technology scouts. Please note we provide the individual tech scout reports as a service to the community. They don't necessarily contain all results and observations but will definitely help anyone interested in the particular topic. The WebRTC roadmap report went through several external reviews. The individual tech scouts went through an internal Task 2 review and are rougher at the edges.
The WebRTC roadmap report
is available here: (make into link once published)
The individual WebRTC technology scouts
| Technology scout | Topic | Rationale | Result |
|---|---|---|---|
| ICE, STUN and TURN: How WebRTC deals with firewalls and NAT | Addressing NAT and firewall traversal with peer-to-peer WebRTC communication | Investigation into important infrastructure component that could be offered by NRENs | Report: GN4-1-SA8T2 - Tech scout ICE STUN TURN.pdf Demo: Screencast demoing PoC PoC service URL: https://brain.lab.vvc.niif.hu Source code of different components on github: |
| RENdez-Vous: One year of operational experience | Describes experiences of the French nationally deployed WebRTC desktop videoconferencing service | Harvest experience from first national deployment of a native WebRTC desktop videoconferencing service | |
| Distributed RENdez-Vous: An investigation into scale-out Jitsi | Assess possibilities for Jitsi software to scale out to a distributed deployment supporting all of EU R&E | RENdez-Vous would be a possible candidate for a shared EU R&E desktop videoconference system, if the choice is build-your-own. | |
| WebTut | A proof of concept implementation of an online web tutoring service | Possible lower integration cost for in-context communication, possible infrastructure component in NREN infrastructure | FCCN deployment: https://webtut.fccn.pt UNINETT test deployment: https://webrtc.uninett.no/webtut/home Source code of different components on github: https://gitlab.fccn.pt/sa8-webrtc/webtut-frontend/tree/develop |
| Service proposal for a Media API Service | Proposes a service offering high-level, real-time communication building blocks for contextual communication | Possible lower integration cost for in-context communication, possible infrastructure component in NREN infrastructure | |
| Screencast: Stream and record lectures with WebRTC | Investigate recording with WebRTC | Opportunity for simplification of lecture/screencast recording and streaming, new services possible | |
| Unified Communication and WebRTC | Assessment of impact of WebRTC on Unified Communication in R&E | R&E trend is towards UC deployments at every R&E institution | |
| SIP2webrtc gateway | Explore opening the legacy world of SIP for browser-based communication | Address interaction of new technology with installed base |
Useful links and information
Accessing WebRTC debug information in browsers
FireFox: about:webrtc
Chrome: chrome://webrtc-internals
ICE, STUN and TURN links
Interesting links
- http://www.slideshare.net/EyeballNetworks/any-firewall-eyeball-networks
- http://www.eyeball.com/standards/stun-turn-ice/
STUN/TURN implementations
- http://sourceforge.net/projects/stun/
- http://turnserver.sourceforge.net/
- https://www.resiprocate.org/ReTurn_Overview
- https://github.com/coturn/rfc5766-turn-server/
- https://github.com/coturn/coturn
Google REST API
Google STUN/TURN REST API via APPRTC:
https://computeengineondemand.appspot.com/turn?username=1234&key=5678
{"username": "1449668921:1234", "password": "lOG0FK45ggYwEclHMlQ1bcipATE=", "uris": ["turn:104.155.26.71:3478?transport=udp", "turn:104.155.26.71:3478?transport=tcp", "turn:104.155.26.71:3479?transport=udp", "turn:104.155.26.71:3479?transport=tcp"]}
Debug FireFox
Firefox:
export NSPR_LOG_FILE=/home/ehugg/tmp/nspr.log
export NSPR_LOG_MODULES=signaling:5,mtransport:5,timestamp:1
export R_LOG_LEVEL=9
export R_LOG_DESTINATION=stderr
ICE media log:
For ICE/STUN/TURN:
Set R_LOG_DESTINATION=stderr
Set R_LOG_LEVEL=3 (can be anything between 1 and 9)
Set R_LOG_VERBOSE=1 if you want to include the module name
generating the message
For "signaling" (SDP offer/answer handling) and media transport, we use
the normal Mozilla logging infrastructure, which uses a comma-separated
list of modules, each one with its indicated log level; for WebRTC,
you'll be most interested in these:
Set NSPR_LOG_MODULES=signaling:5,mtransport:5
message to include timestamps.
Debug Chrome
google-chrome --enable-logging=stderr --v=4 --vmodule=*libjingle/*=9 --vmodule=*media/*=9
linux log file:
.config/chromium/chrome_debug.log
Basic info: https://www.chromium.org/for-testers/enable-logging
a) --vmodule=*source*/talk/*=3
b) --vmodule=*third_party/libjingle/*=3
c) --vmodule=*libjingle/source/talk/*=3
--enable-logging=stderr --log-level=3 --vmodule=*libjingle/*=3,*=0