Skip to content


Subversion checkout URL

You can clone with
Download ZIP


WebRTC project proposal #510

jsam opened this Issue · 1 comment

2 participants


I have asked this question on chat but I din't really got an answer and since I don't see who is mentor on this project I'm posting it here in hope you guys can help me to make outstanding application. You have posted WebRTC project proposal on GSOC2014 page in which I am very interested and I am writing a proposal for it. Also you marked it as easy but I don't see all the major issues which would make this project easy addressed. So I would love to know which solution should I endorse in my proposal. Thank you in advance.

  • 1. Issue: Which network architecture CodeCombat need/want?

There are two viable architectures of communication – fully mesh and centralized also known as MCU (multipoint control unit) architecture.

• Fully mesh architecture does not require server (besides for signaling) and is optimal for low number of participants in session because session bandwidth which is required to sustain the overall session grows for each new participant. To implement this inside CodeCombat we can consider 2 open source libraries: PeerJS and EasyRTC

• Centralized – multipoint control unit is a centralized server component which is responsible of decoding, mixing and encoding back to specific users inside session. All users sustain peer connection object towards the MCU and through it they send and receive media objects which are then displayed on screen. The advantage of this architecture over full mesh is that it is more viable for conference sessions with high number of participants and it can record the media objects (which is awesome for education purpose) and the flaw is that it requires the centralized server component through all the traffic goes. To implement this inside CodeCombat we can consider 2 open source MCU server’s: Licode and Jitsi Videobridge – both of those projects are very active and still heavily under development due to the unstabilized status of WebRTC standard.

o Licode comes with its own client side library which is known as ErizoJS, which is true WebRTC wrapper for all browsers and its own communication with ErizoController which is part of MCU server. Also, it comes with PaaS controller called NuveJS which helps to scale the server up to multiple instances on server farm.
o Jitsi Videobridge is viable alternative to Licode. As a client side library it is compatible with couple of softphone libraries like JSSIP, Colibri and Strophe.jingle.

  • 2. Issue: NAT traversal and enterprise firewalls?

One more problem which we have to consider is NAT traversal. A lot of computers which are connected to the internet still use IPv4 and therefore a lot of users are still behind NAT (network address translators). To cope with NAT traversal we have to use STUN/TURN/ICE technology. Best solution out there currently is rfc5766-turn-server ( which not only is TURN server itself but also has STUN support. The entire story and connectivity problem is explained here: . The installation, configuration and testing of rfc5766-turn-server could be tricky and therefore it is recommended to install it on specialized server instance and define its listening ports on 80 and 443 with valid SSL certificate. The reason for this is enterprise firewall. For example student campus network is behind 2 NAT’s and enterprise firewall is blocking all outgoing ports besides 80 and 443. In this case entire student campus will not be able to use new CodeCombat RTC feature if rfc5766-turn-server is not properly configured and since is using those ports this server has to have its own instance and different IP address. Also, there are couple of tricks with mobile networks which require special attention in configuration.

  • 3. Issue: Quality insurance, sharing desktop, recording?

Different libraries have different ways to ensure quality and some of the completely don’t have it simple because WebRTC in a lot of cases automatically handle quality according to user network upload speed. ErizoJS and EasyRTC have good manual quality insurance which are easy configurable inside a script. In production ready WebRTC application this is still an issue because heterogeneous real world networks have very dynamic behavior when RTC applications comes to question. How important quality is for CodeCombat and is full HD or ultra HD needed?
Sharing screen is one of the additional features inside WebRTC which is still in begging stages and therefore very buggy and not viable for production use. Also it does require a valid SSL certificate and enabled flag inside Chrome to share it. This feature would be very useful for educational platform. Therefore we have to decide does CodeCombat need it?
Recording feature is currently viable only in MCU architecture. Since all media object comes and goes through peer connection to MCU, it enables the server to save them. In current stage Licode – very good MCU server for WebRTC saves the stream to mkv format which sadly is not reproducible inside browser. For that need, after recording the transcoding phase is needed, where we use avconv or ffmpeg library to transcode the video from mkv format to webm, or some other browser friendly container.

  • 4. Issue: User partitioned chat - data channel or websocket?

As third main component of WebRTC, data channels represent a viable solution for textual chat inside a room (where room presents user partitioning per level playing or level construction session). However, a lot of libraries still use websocket on signaling or MCU server for textual chat. Now to clarify the issue here, both of the solutions are good but the question here is what CodeCombat really needs. Websocket solution with publisher/subscriber design pattern is very good way to do user partitioning and chat overall due to the caching and possibility to do push notification over the same socket, but data channels have performance advantage if fully mesh architecture is selected. Does CodeCombat need data channel textual chat or endorsing websocket solution is better?

Thank you for all the support in making better proposal.

Sincerely Sam.


We had a chat. Basically, it sounds like the way to go will be the decentralized architecture, and we don't need high res, screensharing, textual chat (it's through Firebase), or recording.

@nwinter nwinter closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.