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...
Related
I want to know the real difference between Agora and Webrtc? What did I know Agora provides you SDK for different platforms for video, audio calls, and chats and it charges you accordingly, it provides 10,000 minutes free monthly and charges you if you exceed, Webrtc is a Web Real-Time communication that provides you different API to implememt in your app or web to have video, audio or chats in free & unlimited? Am I Right? If yes then why people would use agora and pay money when they have free WebRTC with unlimited audio videos calls and chats for a long time? pls guide your help will be appreciated
I do not know much about WebRTC pls help me out thanks in advance
This is similar to saying that you can use HTML5 to build websites but still people pay AWS to host machines, databases, storage, application logic, etc.
WebRTC is a web technology that is part of HTML5 and is implemented by all modern browser. To make it work, you will need to create websites, install servers, pay for media traffic, optimize your code - you can do it on your own (and pay the cloud hosting vendors for their service) or you can use a third party that offers that as a managed service for you - like Agora and others that do it, where you end up paying to them for their efforts.
To decide which approach is for you, I can suggest two things:
Build a simple demo app with WebRTC. One where you understand what the code does. If you are happy with it and truly understand what goes on - make the decision if you want to continue in that route or use a 3rd party
Just go use Agora or other 3rd parties and pay them. WebRTC isn't rocket science but it isn't simple either
Agora and similar APIs provide a layer on top of WebRTC. They aim to make it easier for developers to leverage WebRTC capabilities without having to build everything themselves from scratch.
Devs who are fine getting into the nitty gritty of WebRTC can indeed do everything themselves, like you say. I recommend trying it! But often, a team or single dev might just want a straightforward way to integrate video/audio into their product without necessarily knowing what an SFU is, how a TURN server works, how to ensure certain data privacy standards, etc. So these kinds of APIs help make WebRTC easier to leverage by doing most of the heavy lifting and letting people focus on all the other important parts of their app. Pricing-wise, there are a few different very good API options that might be more or less affordable depending on the use case.
We're building a video chatroom experience using OpenTok and while we have the fundamentals working, I'm finding that the noise floor is super high when we have many participants in the room publishing audio. Off-browser solutions like Zoom do not seem to have this high level of "white noise", but we seem to still be able to hear each participant immediately.
A secondary problem we're attempting to solve is that of the sheer number of subscriptions required: we're capped by OpenTok's limit of 3000 subscriptions per room. Currently, every client subscribes to every publisher's feed.
While experimenting with different approaches, it occurred to me that this is something all video chat applications would have to solve. Is there an optimal way to approach this currently? I can see the following solutions:
Mute the stream on the publisher side, essentially streaming silence until our voice activity detection (VAD) algorithm triggers.
Mute the stream on the subscriber side until VAD triggers. Because VAD is done on the publisher side, we risk losing the start of their audio.
Only subscribe to streams when VAD triggers. This is like the previous solution, but helps reduce our subscription count. However, I believe the latency and non-determinism here (each client would be individually subscribing, and this likely will be faster for some clients than others) would mean we'd certainly lose the start of speech.
What's the best way to approach this currently with WebRTC? We're targeting Chrome, Firefox, and Safari.
OpenTok Developer Advocate here.
What timing... I literally just wrote a blog post about this: Best Practices for Multi-Party Video Conferencing with the Vonage Video API
I think it covers most, if not all, your questions. Also, be sure to join the Vonage Community Slack where our entire team & community can help.
A one place solution to your problem is OBS,( https://obsproject.com/ ) I guess you know it.
If you dont or if you have used it less, I would like to tell you that, it has immense feature if you explore it correctly and i feel that It will solve your need.
Do use and let me know if your problem is solved, or comment if its not solved.
I'd like to either 1) Stream my camera+mic or 2) Stream my desktop+mic (or OBS) to many people (1 to many) watching from a web browser. Since I'd like to communicate with people in real time low latency is highly preferred (1 second or less would be great).
What's the standard way of doing this today? I have no idea what twitch uses but from playing with rtmp (using the nginx rtmp module) there seems to be a 4+second delay (or maybe I configured it poorly) and doesn't seem to have native browser support. People watching will use their desktop computers but some may be watching from their phones.
Am I to use webrtc somehow (does it support 1 to many? what software do I use)? Or HLS (which seems to want recordings, what config do I want for a live video)? What are my options?
This is an extremely difficult question. If you only need a hand full of viewers (around 10 or less), WebRTC the way to go. If there is a lot of viewers, and you can spend a lot of money, WebRTC is still a good choice, but the bandwidth cost can add up. If you don’t have a lot of money, but need a lot of viewers, you need cheeper bandwidth, this means using an HTTP CDN, and HLS or DASH which adds latency, but is cheeper to operate. If you have 100+ million dollars, you can build your own WebRTC cdn and have the best of both.
So to answer your question, there is no standard way. It depends on your circumstance, use cases and budget.
I have a very general question on how to implement VoIP for our current mobile & Web App. (we have an Android+iOS App and a Web Application based on AngularJS/NodeJS).
What we want to achieve
In the first step we want to achieve inter Application Voice and Video Calls. Later on we might expand into outbound calls into the normal telephone network. But this post is mainly for getting info on how to implement only our first step.
general thoughts
We had some experiences with Asterisk before which turned out to be far from easy. So for this project we wanted to get some feedback before actually implementing anything.
thoughts on technology
At first I thought it might be a good idea to use WebRTC, but since it's only supported on Chrome, FF and Opera for the moment and pretty much is unsupported for native mobile Apps we think that WebRTC is probably out of the picture for now. (or do you think otherwise?)
After searching the web a bit more we found this: http://www.webrtc.org/native-code
Has anyone experience with this libs? It seems to us, that this could be the best solution for a modern voip solution (and also would allow us to skip the asterisk server)
The second idea would be to setup an Asterisk Server for ourselves. Every time a user logs into the App we would connect him as a SIP Client to the asterisk. If one user calls the other one we think we should be able to make the call for example with the node package Asterisk Manager API (https://github.com/pipobscure/NodeJS-AsteriskManager).
The third idea would be to use a SIP Provider, but at the moment I'm not sure if that's really the best idea.
Since we're no VoIP experts, are there any other possibilities for VoIP integration into our apps?
Any thoughts on that subject would be very appreciated! Thank you!
The main factor is the network configuration that you app will be working with. Given you're using mobile clients and web apps it's almost certain that you're using the internet and also likely that you'll have 3G and 4G mobile networks in the mix (3G/4G cause a lot more problems for VoIP than WiFi).
Given the above assumption holds the biggest challenge your app will have is establishing media (audio and/or video) connections between mobile clients which are behind different NATs and in a lot of cases multiple NATs. There is almost no chance you'd be able to get by without a server here. The server will be needed to act as a relay point for the media streams for the mobile clients. You will use the RTP protocol for the media and working out how to get it reliably from client A to client B is your biggest obstacle. The signalling side - whether it be SIP, web sockets or something else - will be secondary (note both SIP and WebRTC use RTP to carry the media).
If I were in your shoes the steps I'd take would be:
Install and try out some softphones (blink, bria, zoiper et al) on your own mobile devices, find a SIP provider that supports video calls and get some experience with calls. It may not be the experience you anticipated...
Once you are comfortable with the softphone experience you would then need to make two decisions:
Whether to deploy your own server or use an existing provider,
Whether to write your own client, find an existing one or something in between.
I can answer the deploy your own server question. You don't want to do that unless the VoIP part of your app is going to be something you charge for and make a good margin off. Running a VoIP server and all the security and network considerations that go along with it is a full time job. It may start out being easy but once a few customers start connecting and the fraudsters come along it will take on a life of its own. In the decade I've been messing around with SIP I'd estimate 75% of providers have gone out of business and it was their full time job.
Besides all that I'd be surprised if there wasn't a SIP provider that suited your needs. These days there are highly sophisticated services available that led you control every aspect of your call flow with your own code (anveo, tropo, twilio) right down to free services (sip2sip, sipbroker) that may be all you need to get started.
For the client software there are various SIP SDK's you'll be able to leverage (pjsip).
i'm starting to develop a web application for which I need real-time capability. In particular, as result of a server-side event (without client request), the client must refresh the view. The best solution seems to be a websocket communication.
My doubt is mainly between Node.js and JavaEE 7. Which language do you recommend for development? And with which framework?
The main requirements are:
Interoperability with browsers
Support for mobile devices
Availability of tools for the creation of the graphical interface
Thanks
The question is a bit broad and leads to opinion-based results - that's why it is likely to get close votes, so don't be surprised if it happens ;-)
Nevertheless, I would generally state, that "web application" and "real time" won't work together, because you have components like the network or containers in between which you don't control and thus cannot guarantee real-time requirements.
But I assume, that you are more looking for an "instant" reaction, so that your clients get informed instead of having to ask for something. In that case, web sockets are the state of the art for doing so.
Regarding technology selection, I don't think one is better than the other, it is more a question about available skills or your general programming model or customer requirements. I would think you can perfectly use Java EE 7 for that.
As a reference on that topic, I visited Adam Bien's workshops last year and he talked about an example, where he had a huge number of clients which communicated with a Java EE app server using web sockets.