Refactoring Erizo Client!

#1

Hi all!

We’re planning to refactor Erizo Client (all the code that runs in the Browsers / clients) for the next days/weeks, and we’re gathering a list of things to be modified/added/removed.

So, please, if you have any proposal or there’s anything you’ve always wanted to change in Erizo Client (e.g. adding adapter.js or removing socket.io have been always recurrent topics), now it’s a really good time to give us feedback, ideas. You can take a look at the link above, see what we’ve already added to the list and comment anything into this topic with your own ideas or proposals.

Cheers,
Javier.

Using adapter.js
#2

Wow! What a great news and what a wonderful list!! :ok_hand:. I just got surprised :grinning:. Thank you team.

It’s a big surgery and I’m not sure can be discussed here in one topic. My be better to create individual topics per subject.

#3

Hello Javier,

Quick question about WebSockets, what is the reason behind go plain
WebSockets instead of upgrade SocketIO or simple choose another sockets
library?

#4

The list looks good.

But I suggest that you should aim for compatibility with Apache Cordova https://cordova.apache.org/

I know that us and many other users of Licode use Cordova for mobile clients. The support for the latest language features etc lacks a bit in Cordova (especially with iOS).

On Apple iOS the most common webrtc library is cordova-plugin-iosrtc (https://github.com/BasqueVoIPMafia/cordova-plugin-iosrtc), which should work quite well with adapter.js

Addition: On Android Cordova uses very up-to-date version of Chromium APIs. On Android Cordova should be almost one-to-one compatible with Chrome.

I am willing to test things with Cordova as you proceed.

#5

@mkh you’re right, but we prefer to see the most controversial subjects to avoid having too many topics.

@zevarito IMO main reason to go for plain WS is to remove dependencies if we don’t need them (currently we’re not using anything too special from the library), but I’m not sure whether Socket.IO has more features to offer us, such as reconnections. We can investigate and play with the latest versions and decide from there.

@jjahifi don’t be afraid of using latest language features because we convert all the code to previous versions when we run the Closure Compiler. That way we improve code readability while keeping support to multiple clients. Btw, using adapterjs is a really good option to improve client compatibility, so it would be awesome if you can test it with Apache Cordova once we add it, thanks!

#6

Hi guys,
this is a great news!

I really like the idea of change socket.io 0.9x
I suggest to upgrade to socket.io 1.x and make the inclusion in the client optional during the compile.sh
I used this way in my production environment and seems to be comfortable.
Since socket.io is already included in my angular main project, I simply don’t include it in the erizo.js client.
For my develop environment, I compile erizo.js with socket.io 1.x included to use in the basicexample.
I think this is more flexible and can help a lot during custom integration.

Regarding adapter, I was in the first line when the community requested this feature but when I tried to integrate it myself, I personally dindn’t noticed any benefit (same sdps generated).
Maybe is useful for older browser but we have to differentiate the stacks anyway… (opus nacks, simulcast, etc. >> chrome only)
Can someone explain what would be the pros and cons?

My only though is that edge and safari are in the scene right now, so is it sensated to refactor right now the client when maybe we would make some important change to make them compatible?
webrtc 1.0 is never been so close, and reading bugzilla and monorail seems that everyone’s thinking to be standard compliant before the end of the year.
I feel the erizo client quite reliable and stable right now, i wouldn’t put too much effort to refactor a piece of code that probably would be rewrited the first half of 2018.

OT:
I’d love to have a similar post discussing about the new features you plan to add and what parts of the code you plan to rewrite/optimize in the short/long term.
I personally feel to have lots of suggestion to express!

Have a great day guys!
And very happy to see the community such active!

#7

@Francesco_Durighetto, I am most concerned with the mobile clients. In my honest opinion it is quite likely that most of the Licode clients will be mobile in the future (most likely already are mobile). That means somewhere like 80% Android and 20% iOS (Apple), depending on the market (in our country it is something like 40% iOS). The most important thing with adapter.js or something is to make the integration to mobile platform a lot easier with the existing tools (if adapter.js does not break too many things).

The aim of using a cross-client tool is not to generate a different set of sdps (I would be at least a bit upset if the set was radically different). The aim is, IMHO, to be able to seamlessly use mobile clients like Android, iOS, and Sailfish (mostly compatible with Android) and desktop clients. The most common tool with mobile is currently Apache Cordova. But in addition to the mobile side we have to consider desktop issues like Eletron and WS.js

In many cases the users are in a private network or are not using a browser.

#8

Regarding Socket.IO vs native WebSockets, one of the useful features of Socket.IO is namespaces. Using namespaces and sharing the socket instance between EC and application we would be able to minimize the number of server ports (e.g. 8080 and 3000 in basic example).

#9

@jjahifi I think we must prioritize the backend work than “mobile” work.
And I think we must have an h264 support before a mobile api.
We (my company) implemented from scratch both iOS and Android solutions that connect to Licode and with vp8 on old device the experience is quite laggy (mainly android).
I personally don’t think that Cordova could lead to better results.

When I say backend work I’m referring for example:

  • better congestion control algo
  • reliable recorder with in-sync video/audio
  • open to edge browser which is the most used by companies
  • wait for webrtc 1.0 standard and move to these specs
  • consider pros and cons of switching to unified plan
  • erizo_tree (which was a GREAT, GREAT idea but apparently paused) -> this can make a real-time webinar with thousand of people possible, without the need to transcode the video and pass it to a CDN that broadcast to the people and it’s the final piece of scalability missing
  • consider to make erizo h264 compatible in every aspect to be able to open to mobile world.

@mkh Totally agree, I had to use them in my prod environment. when you treat with companies you have to consider that you probably have only 80 and 443 at disposal

#10

@Francesco_Durighetto, no disagreement on the backend/frontend. But if we consider refactoring the client now (i.e. the topic of this thread), then I suggest compatibility with Cordova. Making client development easier is not a bad thing, and Cordova allows you to create clients that do not suffer from the limitations of browser-based clients.

In any case, the variability of mobile Android devices is huge. There are fairly recent phones etc which have so underpowered processing capability and substandard networking capability (cost-cutting with obvious results), that they are not really suitable for videoconferencing of any type. Obvious hardware limitations. Some of those devices are still actively marketed. I do not believe h264 would solve the problem of devices with poor networking or missing processing power.

The same goes for older iPhones (the iPhones supported by the latest released version of iOS are decent in that sense).

Discussion on backend issues deserves a thread of its own.

Addition: I agree with you that it is a real alternative to postpone the refactoring of the client until webrct 1.0 is out.

#11

I am very much aligned with the idea that SFU work must be prioritized over client’s work.
Client API works, is dead simple and haven’t changed for a big while, should not bother too much how crappy it is, specially since you can write better clients at the top of it or directly at the top of ErizoController protocol in a fairly easy way. Except for the socketIO mess, adding/updating stacks I’d rather not touch the client much.
In which parts to work and how is a great another discussion.

#12

Honestly most of us have our own applications developed which are working well with the current code. But let’s think of new users joining the project and want to try Licode then find the client code mess. I personally spent a lot of hours struggling with video constraints stuff (video size, frame rate, device id, etc) and differences between browsers to get it to work while adapter.js does the job easily.

In the other hand there is no end for SFU developing and optimization while the client code can be refactored in a few weeks. I don’t think we would expect a huge change in WebRTC 1.0.

#13

Hi Team,

Current licode uses mongodb “2.4”. Can we consider to upgrade it?

In our case, we are deploying the both licode and application in same instance.
And our application needs 2.6 … Hence we are upgrading the mongodb manually.

Is there any specific reason in sticking to mongodb 2,4 version?
I suggest, at-least we can use 2.6 … which has newer features.

Thanks & Regards,
Hemanth

#14

Are there any views to support centos also?

#15

The discussion just moved to a different topic IMO. By refactoring client we’re not saying client is most important than server, but we’ve found some time to spend on it and, given that we received some feedback related to Erizo Client in the past and we didn’t have the time to apply it, we wanted to hear again about ideas or comments about the current code.

We don’t aim to create clients or put a lot of effort on mobile clients now, but if we can improve the support by just including adapter.js it could be a big win for people who work for those native apps. We’ve found out that by using adapter.js we can reduce code in the stacks.

Besides, there are still some connectivity issues that are not being logged or handled properly, so we’re taking the opportunity to improve it in the client side.

It seems like socket.io can introduce incompatibilities in apps, so we think it makes sense to add an option to skip it during erizo client bundling. And we’ll update it to a newer version too. We’re also considering to improve the way we execute tasks to build Erizo Client, and will probably adopt Gulp, Grunt or any other task runner.

As you might have noticed we’ve started to refactor the client already. We’re now using eslint to check code style! As in other situations, this work is in progress right now in the master branch so I’m afraid we might introduce temporary bugs during the process, once we finish the work we’ll start testing all features again. Anyway, we don’t aim to introduce breaking changes in the API to reduce the impact on your apps. If we feel like there’s some thing we need to change there we’ll let you know properly in this thread too.

WRT the other feedback you commented here, in general we agree on all the things (webrtc 1.0, erizo trees, new browsers, h264, upgrading mongodb, etc.), we’ll try to include them whenever we think they are a priority and we can spend time on them.

#16

@Javier, Good to hear. Please drop a comment to this thread when the work is finished (or finished enough). I will start testing the new client with Cordova after that.

#17

Would it be possible to add an API in erizoClient for establishing RTCDataChannel between two room participants? This would be super helpful in solving a problem I posted earlier.

Also, consider publishing an npm package for ease of use

Cheers