You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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 scoutTopicRationaleResult
ICE, STUN and TURN:  How WebRTC deals with firewalls and NATAddressing NAT and firewall traversal with peer-to-peer WebRTC communicationInvestigation into important infrastructure component that could be offered by NRENs

Report: test report.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 experienceDescribes experiences of the French nationally deployed WebRTC desktop videoconferencing serviceHarvest experience from first national deployment of a native WebRTC desktop videoconferencing service 
Distributed RENdez-Vous:  An investigation into scale-out JitsiAssess possibilities for Jitsi software to scale out to a distributed deployment supporting all of EU R&ERENdez-Vous would be a possible candidate for a shared EU R&E desktop videoconference system, if the choice is build-your-own. 
WebTutA proof of concept implementation of an online web tutoring servicePossible 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 ServiceProposes a service offering high-level, real-time communication building blocks for contextual communicationPossible lower integration cost for in-context communication, possible infrastructure component in NREN infrastructure 
Screencast: Stream and record lectures with WebRTCInvestigate recording with WebRTC Opportunity for simplification of lecture/screencast recording and streaming, new services possible 
Unified Communication and WebRTCAssessment of impact of WebRTC on Unified Communication in R&ER&E trend is towards UC deployments at every R&E institution 
SIP2webrtc gatewayExplore 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

STUN/TURN implementations

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 

You can also add ",timestamp:1" to that list if you want each log 
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
  • No labels