Best fit framework for webRTC

[Rishi Khandelwal]

Hello

I want to know that which framework or library is best to use WebRTC.

Is easyRTC is best or something else ?

[Alexandre GOUAILLARD]

Here is a small and incomplete list of libraries/SDK out there. Any lib that I forgot, feel free to let me know, I can maintain a public version of the list for the community.

You might want to try out by yourself what works best in your case.

We like rtc.io for the modularity, and the academia/gov-driven community, but it's only us, and other libs might fit better your case:

• simpleRTC (http://simplewebrtc.com)
• talky.io (http://talky.io) (uses simpleRTC)
• crocodileRTC (https://www.crocodilertc.net)
  
• lynckia/licode (http://lynckia.com/licode/) (This is more interesting for their server side, MCU)
• holla (http://wearefractal.com/holla/) (used by twelephone)
• easyRTC (http://easyrtc.com) (priologic)
• tawk (https://tawk.com) (uses easyRTC, priologic)
• peerjs (http://peerjs.com) (data channel)
• with tutorial for the above: http://badassjs.com/post/43090030238/peerjs-a-peer-to-peer-networking-library-in-javascript
• webrtc.io (https://github.com/webRTC/webRTC.io) (no changes for almost a year)
• webrtc-data.io (https://github.com/erbbysam/webrtc-data.io) (stripped down, data only version of webrtc.io)
• rtccopy (https://rtccopy.com) (uses webrtc-data.io)
  
• rtc.io (http://www.rtc.io)
• voice and SMS, no video (http://plivo.com/)

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jawaid Ekram]

Thanks Alex.

Has somebody done a compare of all the frameworks. It would help for people who are new to WebRTC.

Thanks

[Alexandre GOUAILLARD]

I guess most have done such a comparison, but publishing it does not make a lot of sense, for two reasons:

- the obsolescence of such comparison is high: webrtc is still a moving target, and whatever is done needs to be maintained. Recent changes on stream vs track, and/or changes in GetUserMedia and constraints being discussed right now will break existing code.  easyRTC's github repository hasn't been updated for 4 months, webrtc.io 7~9 months. a comparison made then might list them as state of the art, a comparison today will very likely rank them differently.

- sdk/api are biased toward a special use case. If you want to make it simple to use (the two-lines-hello-world), then you have to assume and hardcode a lot. If you want to give maximum flexibility, then eventually, you're down to the original JS API. Where you decide to place the cursor between those two extremes, the granularity of your API depends on arbitrary choices that are case-dependant. Some toolkit are also wrapping access to underlying pay-for-use infrastructure, which could be fine for you, but you might want to install your own STUN/TURN/signalling server, or use a public one for a quick demo. So the result of a comparison depends on what you want to do with it.

For all those reasons, starting with a list is, IMHO, the best way.

--

[Lorenzo Miniero]

Good points... the SDK I'm working on tries to address those points exactly, in fact: that is, trying to provide different layers of abstraction, to allow you to either "make assumptions" and go the easy way (for different scenarios), or go deeper and have more control. Now I just have to hurry up and make it available soon enough. :-)

Lorenzo

[Alexandre GOUAILLARD]

from my experiments, rtc.io provides that. The Glue/HelloWorld/ provides a few command lines auto installation of the node server fully configured for a local host to play with. The media/core/mesh components are targeted at more advance audience.

I like their modular approach, where a private company like ours can contribute back some of the code in the core modules and help the community, while keeping proprietary modules on the side for our products. win-win.

[andy424]

easyrtc beta repository has more recent updates and was demoed by Priologic (a Canadian company) at the recently concluded WebRTC Expo in SantaClara two weeks ago.

https://github.com/priologic/easyrtc/tree/beta

It incorporates an EasyRTC server install(using nodejs and express) and client API, and working, HTML5 and Javascript, application source code under a BSD 2 license and was an quick and easy set of setup instructions to get the initial samples working in your own local subnet.

[Priologic Victoria]

We're biased... Priologic won the Easiest to Apply WebRTC Award at the WebRTC Expo in Santa Clara a few weeks ago for EasyRTC and tawk.com.

We are near to releasing a new version of the code base with many new features. This new version is in the Beta branch now in GitHub ( https://github.com/priologic/easyrtc/tree/beta ) and will become master (https://github.com/priologic/easyrtc ) in the next few weeks.

We are also close to releasing commercial mobile SDKs for EasyRTC.  They will be affordable and should be out in January.

Doug Pelton

On Friday, November 29, 2013 12:12:19 AM UTC-8, Rishi Khandelwal wrote:

[Jawaid Ekram]

Doug:

The mobile SDK would be for Android or iPhone? 

Your comment suggest it would not be open source? Is that correct.

Thanks

Jawaid 

[Alexandre GOUAILLARD]

jawaid, 

open does not mean free ;-) free as in beer (you don't pay, but you can't make your own beer)? free as in freedom (you might pay for it, but you do whatever you want with it)?  There are a lot of pages that address this point: http://en.wikipedia.org/wiki/Gratis_versus_libre

Then, SDK/API that leverages infrastructure usually include some kind of price for you to use the infrastructure. They can be open source, they can be free (no cost) but the service provided by the infrastructure is not, get an API key to use it:

- http://developers.bistri.com/pricing/

- https://vline.com/developer/docs/developer_faq

- http://www.addlive.com/authentication/

- https://www.tropo.com/pricing/

- http://tokbox.com/pricing

and so on and so forth …..

So inherently you have two kinds of sdk/API, those that simplify the client side (reps. server side) coding by providing a higher level API tailored to some use case, and/or smooth the discrepancies between browsers (a-la jquery). Example: webrtc.io. Those are most of the time free, as you wouldn't be able to control who use it anyway. Then you have the SDK/API that are hiding the infrastructure for you. Those can be open, free, whatever you want, but you cannot use it without using the underlying infrastructure (which is not under your control, and certainly not free). You have a small list above, but there are many more.

Then, some libraries provide entire solutions, including client and server side, not locking you into any proprietary infrastructure (it's not always a good thing… you have to handle the maintenance and deployment of a possibly global infrastructure yourself). Client side code, server side code, signaling server, web server, turn server, stun server, with example showing how to set everything up together.

Again, there is no one-suits-all solution. Don't believe anyone ("talk is cheap, show me the code", linus torvald), download, test, and then decide.

Cheers,

Alex.

PS: doug, congrats on the award, great job on easyRTC, impressive to see the progress since Atlanta.

--

[Lisa Larson-Kelley]

Great list and helpful discussion! There were a few in there that weren't yet on my radar.

I'm putting together an intro workshop and online course for WebRTC right now, and I'm struggling with the best solution to get started. Tempted to use a framework with a simple helloworld, but really want people to understand what's going on under the hood too, so they are equipped to go on and build something real. 

Would love to hear suggestions for the best approach.

// Lisa Larson-Kelley

[Alexandre GOUAILLARD]

dear lisa, 

great to see some are working on the education part of the equation. I'm giving up some courses at university, and here is the feedback I think can be useful for you. It might not, in which case, please accept my apologies for the noise.

In any case (graduate/undergraduate), going through everything, especially the infrastructure part is *hard*. For undergrad especially, you might want to skip the TURN, STUN, ICE practicalities. REST API to TURN, TURN TCP, ICE TCP, web socket TURN and all other cutting edge, being developed might be better left aside even if used in chrome / apprtc.

Be explicit about what is standard and what is not (signaling), or students end up confused about what can be modified and what can not. We are also being very explicit about what would be missing at the end of the course (authentication, session, TURN, state machine, unroll of failure, ….) for a "product".

You might want to stay in browser-land and only touch W3C's webRTC API. That keeps native apps and desktop app out of the equation, but it makes your life simpler. Addressing native apps would require going into the internals of webrtc and touching at least the streams, videoCapturer, videoRenderer, quite an additional load for students (unless you go for a two semester course).

For an advance course, we touch on the underlying implementation, and you start digging into webrtc and either libjingle or a cisco sip stack depending on you using chrome or firefox source. We found it interesting (on an educational point of view) for end of master students to illustrate not only the webrtc implementation but also the fact that interoperable API could be implemented quite differently under the hood.

Eventually, the example course set up by google's sam duton is a great start:

https://bitbucket.org/webrtc/codelab

HTH,

alex.

[Lisa Larson~Kelley]

Thank you for the comprehensive reply, Alex. I agree, getting into the 'weeds' of ICE/STUN/TURN/Websockets/etc. can intimidating. I think it's important to give students a big-picture understanding of how all of the pieces fit, and then give them some hands on with the basic flow of a webrtc app. I'll also bring in frameworks such as SimpleWebRTC to show them a wider array of options for deployment. I'll be sure to let them know at the end what pieces are missing and give them some references to getting there.

Thanks again,

// Lisa Larson-Kelley

Kelley Green Consulting

Writing  •  Consulting  •  Training

blog    :: LearnFromLisa.com

book   :: Flash Video for Professionals
twitter :: lisamarienyc 

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/6MSiBZd_N_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.