What are the limitations of WebRTC's APIs, if any?
What is the maximum number of peers that can be connected at a time? I mean, since webRTC is peer-to-peer, hardware and bandwidth resources are divided among peers, a single server is not responsible for handling media streams, then how many maximum users can we connect by using webRTC?
Related
I'd like to implement a simple video chat system for students to tutor each other. I'm a one man show, and would like a system I can run in a cost effective way starting with 10 users, and hopefully scale up as needed.
WebRTC seems like a great, low latency, and cheap option to build this feature. However, if clients are communicating, then they must know each other's public IP. Is this a significant privacy or security issue?
What is the worst case scenario of somebody getting my IP address? Wouldn't any malicious actor have to get through my ISP to get my specific location?
Thanks!
If you host it yourself, WebRTC can be extremely cost-effective. I've been running the SFU at galene.org (disclaimer: I'm the main developer), which is used for multiple lectures with up to a hundred students. Even though this is a full-fledged SFU (and not a mere TURN server), hosting amounts to just over €6/month.
If your tutoring sessions involve just two or three people, then peer-to-peer WebRTC might be enough, but even then a TURN server will be required, especially if some of your users are on university networks. For larger groups, you will need to push your traffic through an SFU.
If you do peer-to-peer WebRTC, then any user can learn the IP of any user they are communicating with; this is most probably not an issue, since the IP addresses are most probably already being disclosed (e.g. in mail headers). If you go though an SFU, then the IP addresses are not deliberately disclosed, but they might still leak; for example, the SFU implementation mentioned above (Galene) discloses IP addresses when a user initiates a file transfer since file transfers happen directly between clients, in a peer-to-peer fashion. (It may be possible to avoid this disclosure by setting the iceTransportPolicy field to relay in the PeerConnection constructor, but I haven't tested how effective it is.)
WebRTC doesn't have to be P2P. You could run a SFU. Each user will upload their video to your server, and the server will distribute via WebRTC. Then the users will never know each others IPs.
I don't have any exact numbers, but it isn't expensive either. Your biggest expense will probably be bandwidth. Lots of Open Source SFUs exist, this is a good list to get started.
I need to build infrastructure for video streaming service, that will be able to handle >100 live streams with average of 50 viewers, where top stream can have up to 5000 viewers. All streams will be served as multicast, not extra transcoding will be required (input and output will be h.264), no recording will be made. I'm curious how many streams can handle simple red5 server and how to calculate max of users.
Recently, I have tried to gain a better understanding of VOIP. I have a good enough understanding of what the phone does in terms of converting audio signals to UDP packets and I develop embedded firmware for a living so I'm no stranger to internet protocols or data formats. My question is: how does a VOIP server go about delivering that audio information to say a land line or wireless carrier? Is there some kind of DNS for phone numbers that gives you an IP address of a server where you can send the data? if so, what is the name of the protocol that is used to determine that information, and the protocol for transmitting the audio data once you know where to send it. I've tried to search for the information, but of course my searches are all swamped with irrelevant results. Also, where can I find documentation for implementing these protocols?
The most popular protocol for this is SIP/RTP (SIP for signaling and RTP for media).
You will need a SIP server (softswitch) to handle this.
To be able to route the calls to landline or mobile numbers, you will have to "interconnect" with carriers from your softswitch. Then you will just send the traffic to their server (the address what they told) again with SIP/RTP since most carriers have SIP support. Alternatively you can send the traffic to traditional PSTN (you will need a hardware for this: either a dedicated gateway or just a PCI slot in your softswitch).
Practical situation, we have a lecture/webinar and I want lecturer to broadcast online 1 way to 100 students at the same time, how would I do that with WebRTC?
I have tried Youtube Live Event today - their concept is similar to my needs and they seems to be using WebRTC as well, but there should be some re-broadcasting server to keep one connection from broadcaster and deliver it to many clients.
Well, I tried to ask this question as a comment on this question, but I thought that maybe no one will notice it, so I decided to ask it as a separate one.
The question is about how to do real-time GPS tracking system things; if we have the following scenario:
Rather than connecting a GPS receiver to a PC, the user will have a mobile device with an integrated GPS receiver.
Location data will be sent over mobile network using GPRS data connection to a server side.
The data will be processed and a KML path file will be created and updated on time intervals and used to track the user using Google Earth.
The question is: what is the best method to accomplish this scenario for the server side; is it a web service, a web application, a windows service, a windows application or what exactly? Taking into account that the system will serve a number of users simultaneously, and that more users may use the system in the future(scalability issues).
Thank you in advance and I highly appreciate any help :)
What kind of device are you using exactly, something like this or something more sophisticated / configurable? If we assume that the device sends its data over TCP, I would consider the following approach with separate input/output processes:
Input: a process listening specific TCP port and storing incoming coordinates to database with a device id. Preferably, your listening loop must be able to handle simultaneous connections without them blocking each other.
Output: web application reading coordinates from database for a given device id and displaying them through the Google Earth API.
Use whatever programming language(s) you are familiar with.
For me there is a technical limitation/risk here -> the mobile device, and its connectivity.
1) What are your requirements? Do you need to support various mobile devices or will you focus on only one platform ?
2) More importantly, you have to understand that GPRS data connections differ from a PC connected to the Internet. There are various connection restrictions imposed by different mobile operators.
If I was to design such a system in order to minimise those risks I would go with a web server running on port 80 which the mobile devices would upload their Long/Lat through POST (or even GET to simplify things).
EDIT: Regarding scalability, it would be very easy to scale things up in the future using tried&tested load-balancing techniques.
EDIT2: Whichever technology you decide to use, i would HIGHLY recommend that the first thing you do is to mock up a prototype. Those connection restrictions could be show-stoppers. Ideally you need to explore them before you have made any serious investment.