Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am developing a video conferencing application for education purposes that uses WebRTC. It needs to be done in a star topology as it connects up to 20 participants.
Conceptually it is easy to understand, but I don’t know how to start, as I do not have any examples.
All clients will connect to a server using WebRTC, and the server will mix the video streams in a specific layout and send it back to all clients. Here are my questions/difficulties:
How to implement the server part? What’s the best technology (e.g. NodeJS)? Are there simple examples of a star topology application like that?
How can we start writing the MCU code? Are there examples? Or is it easier to customize an open source MCU like Licode/Lynckia?
How can I estimate the right AWS EC2 instance type that we will use as the MCU server?
How can I estimate the data transfer cost (the size, in GB/TBs) which will be transferred in 1h of conference?
Thanks a lot in advance,
Carlos
My two cents on your various doubts:
Personally, I prefer NodeJS, but from what I have seen, application server does not play much of a role in WebRTC communication other than passing messages between peers/ media servers, so go with a technology you are comfortable with.
That said, for examples, you can check out kurento's Tutorials in both Java and Node.js, Licode example(using NodeJS) and Jitsi Meet in Java.
Yes, I think going with existing MCU is good idea, better one is SFU, difference being SFU justs forwards streams not mixes them, mixing streams is a costly process thus MCU needs to have high processing power. SFUs are comparitively light, all you need is a good bandwidth for the server.
About last two points, not much idea, depends on your use case, what is video resolution of streams, how many people, you needs to run some tests and guage it.
simulcast is another interesting idea, unfortunately I believe it is still in development.
We build solution based on NodeJS on WebRTC. With this technology is one big problem - everyone is sending video stream to everyone. If you have 20 participants then every computer sends and recives video 19 streams.
We created restriction "up to 4 participants" per room and it works fine.
So in my opinion if you have enought time - you can mix two technologies (up to 4-5 users) WebRTC to save server time, and something different for bigger meetings.
Related
We've made an application where two people can video chat with each other using TokBox, but are running into a lot of technical issues surrounding WebRTC and TokBox itself. I know that Twilio recently launched a Javascript version for their video service, but both TokBox and Twilio seem to be aiming for larger scale publish/subscribe operations. It also isn't as far along as TokBox.
Are there other services out there that can do web video 1 on 1's? Perhaps some that don't use WebRTC and therefore don't have the problems we are facing?
I can't help but to think back to ChatRoulette and similar apps.
If what you need is an application that needs to run within the context of a browser, then WebRTC is your only choice when it comes to the technology to use. There's just nothing else there now that Flash is officially dead.
If you need it to run purely inside a packaged PC/mobile application, then you can use something other than WebRTC, but I don't really see the need for that.
When using real time video technologies, one aspect to look at closely is the quality of the network you are using. The questions I usually ask myself are things like does Skype/Hangouts/FaceTime run any better? If the answer is "yes they do", then the problem is in the implementation you have done/used. If the answer is "no, they are just as bad" then you probably can't do a lot better either.
For alternatives, you can check out the vendors listed in this WebRTC Develoepr Tools Landscape: https://bloggeek.me/webrtc-developer-tools-landscape/
I don't know what you mean with "a lot of technical issues surrounding WebRTC and Tokbox itself", but I do know Tokbox handles millions of 1:1 streaming minutes every day, without issues, and it can even handle sessions with 1 publisher and 3000 subscribers at the same time, so, maybe the technical issues are not there, but in another place...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to develop real time web application like chatting & real time message conversion. I searched the internet and got confused with few technology
erlang ejabberd nodejs openfire
Right now im in java domain but won't hesitate to learn new things. So can anyone explain what is these technology in a very simple words and what technology i will need to achieve my target ? Does all these do the same thing ? and new technology suggestion from your side will be appriciated.
These are entirely different things :)
At the lowest level you have:
Erlang/OTP is piece of technology, that lets you built low latency, fault tolerant systems. It includes Erlang programming language, Erlang VM and OTP, which is set of patterns, libraries and good practices for writing those systems.
nodejs is a platform, that lets you code JavaScript on server side. It makes your life a little bit easier, when dealing with events, but Erlang is still better saving you from callback hell with actors and messages between them.
At the higher level you have xmpp:
xmpp is eXtensible Messaging and Presence Protocol. This is great for implementing chats like facebook chat, but because it is extensible, you can use it for any kind of messaging.
ejabberd is implementation of xmpp in erlang. There is also fork of ejabberd called MongooseIM. Those will give you great start at developing your messaging application. They implement not only basic xmpp, but also couple of extensions (called xeps in xmpp community).
openfire is solution based on xmpp, so it is even higher level. For chatting and message conversion, this might be overkill, but it depends on your specific needs.
Totally an opinion post:
Erlang: Doing this from scratch with yaws and Erlang is the most straightforward way (its even a code sample in "Programming Erlang" 2nd ed.).
Ejabberd is famously undocumented (and overkill for most webchat services), but it and its better documented/saner cousin (MongooseIM) are robust and already written.
node.js is a cosmic joke played on monolingual ex-frontend web developers.
I've never heard of openfire.
None of these things are bad to learn -- but that's because nothing is ever bad to learn (though some things aren't worth the time you would spend learning them).
The basic problem, I think, is that your goal is probably more broad than you realize, at least in terms of methods by which you can achieve the goal of "develop a web-based chat and communication service". There are a hundred web servers out there, each with its own way of doing active content service, each with a hundred more back-end plugins to a thousand more chat/conversation/comments/blather service frameworks. Any given "technology stack" will often involve a dozen languages throughout it (consider service pages written in PHP from an Apache server which proxies to a Tomcat webserver for pluggable content which calls out to a tiny scheme chat service which stores data in Postgres...).
The situation with most web stacks is, in my opinion, laughable. That is at the core of the Node.js idea, actually: pick a language most people know and stick with it throughout. The problem there is that not every language is well suited to every task (or any task...). But the basic idea that cutting the web tech clutter down is quite sound.
That said, I sincerely think the easiest place to get started is with a relatively tiny language with a small, hyper-knowledgable community around it, and focus on doing everything you can in that language. For this particular task (live web comms) I prefer Erlang and Yaws, writing the service from scratch until some element of it obviously is in need of some pre-written framework treatment. (That is not the right choice of tools for everything, though, so keep an open mind and learn to hate every language, at least a little -- they all suck, just some less than others.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am trying to understand what is the right tools for creating an app with text, audio and video exchange. As server-side tool i want to use node.js.
There is a lots of examples which shows you client-side code, but what about server-side? I know, that for WebRTC server is needed only for signaling purposes, but i cant find a descriptive giude helping me to find out how to say:"Hey, here is this guy, he wants to talk to you, so here's his IP" or something simmilar.
How to make sure that i am establishing direct conection? How to establish the most performant kind of connection? I know that there is some NAT traversal protocols, but how i can explicitly use/enable them?
Can i create distributed Skype-like network by connecting many-to-many peers and having some signaling/auth servers? Or maybe use some peers as servers for signaling only?
All the above can be obtained with software such as Flash Media Server (or Red5 for open source). If you want to use Node.JS, you will need to either create your Node services (message queue, media server), or use some already available, and have Node.JS handle the interaction between them. So all of these will be needed:
Node web service(s) with web sockets
Node / other message broker (mq)
Node / other media server (FMS, Red5)
Optional, a caching service for multiple Node web services (Redis)
You can choose Flash, it has great support for RTMFP/RTMP. If you really want WebRTC, you will have to create a STUN node service for p2p discovery, which is connected to the caching service to handle authorizations.
RTMFP is an option, webrtc too. Most performant depends on how you define performance: quality? latency? how should it be biased? If you want low latency, go for p2p. If you want recording capabilities, either rtmp or a node webrtc relay.
Yes, but you will most likely need a team to do that :)
Found almost all of the answers :)
There are no any restrictions for server-side tools, so you can use whatever you want. Node.js fits great. For communication purposes WebSockets or XHR can be used, but there is no restrictions for any others.
In the process of creating connections browser will generate some events with all needed data. You just need to send it to both sides and process it there. There is also offer/answer system, so connection can be made only with agreement from both sides.
Browser will try to establish best connection possible by default. If it's can't be done it will fallback to TURN, which translates data through server.
It will be possibe when DataChannels will be implemented.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I work on studying the development of a medium web application intended for hotlines. So I've real time, concurent access, big datamodel and CTI constraints.
Originaly I'm a php and Java EE developper, but like many of us, I've read a lot of news about node.js and I tested it with small apps. The possibilities of node.js are awesome, but I felt that it's very difficult to only use this technology in a medium/big web app. Indeed frameworks like express are minimalistic compared to productive framework like symfony, play or ROR, etc. Moreover, the node.js ecosystem progresses very fast and might be difficult to maintain.
I'm not experienced enough in nodejs, so I want to know; is choosing only node.js to develop a medium/big business web app with some real time problematics crazy or not? Don't you think that coupling a productive framework with nodejs only for specific features (real time) is a better way ?
Thanks,
Regards
Eric
I'm working on a large real-time business web app that requires some real-time interaction and what we are doing is using django for just about everything, and handling the real-time stuff using the now.js library. Originally we planned on using node.js for everything, but to alleviate some time constraints, we decided it would be quicker to use django.
One thing we have noticed since we've started is that there are a lot of changes, and that some of these changes break what we've done. For the most part, keeping up with the changes hasn't really made it difficult to maintain, however it has made it difficult to follow tutorials and such.
I'm going to answer this quickly, before the question is closed for only being answerable via opinions, not facts.
So, I'm going to answer with my opinion ;)
I think node.js's focus currently is on building small things that respond very quickly. I sense a lot of pushback in the node community against "too complicated abstractions". (It's possible I'm misreading the community, but I don't think so).
To me, building a business app (example: some of my past Rails projects have been 10ish man years) I want an ORM abstraction layer, etc. I think you'd want this building even an app with more than a few man-months of effort in it.
Unless something changes (the node community runs into problems when their code bases grow too large, for example) I suspect the "place" for node.js in medium to big applications is for small hyper responsive things (websockets, retrieving data from external sources and doing small things with it), etc.... not for building an entire big business workflow app.
It's 2016. Recently I decided to go with Sails / Node instead of CakePHP. Today I decided to go back to CakePHP. Lucky enough, I just coded one small module ( kinda of indexing inside a db some filesystem content ). The amount of callbacks and promises It's just annoying to me. The simple task of getting a file's metadata, searching it on Postgres, creating the record only if it doesn't exists, take me more than 20 lines of code and I almost have to drink a bottle of Dramamine lol
This time I am highly determinated to maintain an extreme layer's separation. So my front-end is fully static html/js/css, coded in Angular. Postgres DB also don't require any changes. And CakePHP 3 is almost factory's ready to easily serve json/xml.
Also there's a possibility of me being somehow stupid... lol
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I would like to build a service that allows a user to listen to a call live from their browser.
I have some experience with Asterisk and this seems to be flexible enough to do what I have described.
Node.js sounds good because it is purported to handle concurrency well, and, I like JavaScript.
In the browser I figure that the HTML5 audio tag, since it handles playing from a streaming source, would be fine to play the sound.
A colleague of mine worked together a demo of this concept using Icecast, but was not able to finish it. There were also significant latency isssues.
My question is this:
How should I go about getting started on this?
Any help is appreciated!
Update:
I found a presentation discussing implementing SIP on top of WebSockets via a SIP proxy on the backend:
http://sip-on-the-web.aliax.net/
Once I have this up and running, the next step would be implementing the streaming. It seems like I should be able to proxy the audio output that would normally go to the sip client, through a secondary server that then streams it to the browser. I wonder why this couldn't be done all in memory? Then there is no need to write and read the file as the call proceeds.
If you're willing to wait for Asterisk 11, we're currently working on implementing support for WebSockets directly in Asterisk. More on it here:
Asterisk 11 WebRTC/RTCWeb Support
I'll just quote Kevin here, since he summarizes it better then I can:
"Today, the in-progress development branches have support for the WebSocket transport protocol (used for communicating signaling messages between the browser and Asterisk), SIP over WebSocket (currently being standardized by the IETF) and ICE/STUN/TURN (media handling mechanisms for NAT traversal and connection setup security). In addition, there’s a new Jingle/Google Talk/Google Voice channel driver, and we plan to support Jingle over WebSocket as well. At this point, we don’t have a quite complete solution (a new Canary build of the Google Chrome browser is needed with a few small changes), but each of the pieces has been tested and we’re anxious to see it all work together. We’d like to thank Iñaki and José from the SIP-on-the-Web project for providing us their JavaScript SIP stack to use during our testing, and we’ll probably be testing with the PhonoSDK as well for Jingle support."
This seems a nice guide
Remote call-center solution using Node.js
I've built a similar solution here. In this post I'm talking a little about it:
http://www.igorescobar.com/blog/2014/08/13/working-with-asterisk-and-node-js/
I built a call center solution using Node.js (Express/Socket.io), Javascript, HTML5 and CSS3.
I think trying to stream an audio file while it is being recorded will have extreme latency issues that you will not be able to get around. If you want to get real-time listening to a phone conversation I would suggest looking into Phono. It is a JQuery plugin that turns your web browser into a phone. Then you would just have the listener conferenced in to the conversation with it on mute.
If you don't mind the latency (caused by buffering of the Icecast stream), Asterisk is able to stream to Icecast (configure Asterisk's Ices application).
If you can't tolerate the latency, you'll need a browser-based SIP client. Unfortunately, there's not many of them that aren't locked to someone else's phone system. You might try red5phone (http://code.google.com/p/red5phone/) but that requires that you set up a Red5 server.