I want to make/experiment with a P2P network running on browsers (WebSocket and WebRTC for inter-browser communication) as well as on servers for signaling using WebSockets.
I read online that the max WebRTC connection is theoretically 256 on Chromium, but only around 6 practically. Most resources mentioned WebRTC with video calls, therefore, what is the practical limit using RTCDataChannel which consumes less bandwidth, at least in my use case?
Related
Having read the announcement about google nearby 2.0 it's clear that WiFi connections are supported.
Nearby Connections uses WiFi, Bluetooth LE & Classic Bluetooth under the hood to discover and establish connections to nearby devices.
Or from the docs overview page
Under the hood, the API uses a combination of Bluetooth, BLE, and Wifi hotspots
What I'm not clear on is whether the WiFi support is exclusively when devices are connected to the same WiFi router, or whether the service will also use WiFi P2P (aka WiFi Direct) to establish connections when possible.
My experience using similar services on other platforms is that bluetooth connections can often be too slow for fast paced multiplayer games. My title already supports connections over WiFi routers, so ideally I'd want the service to add WiFi play in the absence of a router.
I think my question is answered in the I/O talk about Nearby Connections refresh (link).
We connect over bluetooth and start transferring data instantly, but
in the background we also bring up a WiFi hotspot, and when that's
ready we seamlessly transfer your connection from bluetooth to WiFi
with absolutely no work required by the app developer
I'm reasonably confident from the context that the WiFi hotspot they're talking about is an Adhoc/Direct/P2P one (not sure of the correct terminology, but mobile to mobile WiFi of some sort) rather than a physical router.
The announcement says
At I/O this year, we spoke about a refresh to the Nearby Connections API that can provide high bandwidth, low latency, encrypted data transfers between nearby devices in a fully-offline P2P manner. Today we're announcing the availability of this API across all Android devices running Google Play services 11.0 and up.
Its fully offline and P2P so it looks like that there is no need for them to be connected to the same wifi router.
Is WebRTC going to be free for web developers to set up video calls on web pages?
why does Twilio having pricing 25c per mins for video calls,
is it going to be too expensive for the small guy to mange video calls on web hosting servers?
any advice from anyone deep into WebRTC already?
Some of the comments above are not well informed.
Someone wrote, since the bandwidth needed in case of media relay is higher as well. This is not entirely true, transmission happens between Peers(Browsers), servers are used just for signalling(relaying IP addresses of connecting peers and some more info), you can ROUTE your transmission from central server(for fail overs), but can surely do without it for free.
WebRTC is Free and you can setup the whole thing on your own without having to shell out even a penny. It is a bit hard and mitigating fail-overs is really difficult, but you can certainly do it for free.
Tokbox or Twilio charge money because these tools abstract some very rigid complexities of setting up, running and managing fail-overs in a WebRTC application.
In TokBox's Case:
You don't need to setup STUN, TURN servers, you don't have to worry
about integration with android or IOS clients, they provide a plugin
for IE too, so out of box you get everything and you just have to
concentrate on your application logic rather than WebRTC nuances.
This is a big plus.
Both RELAY and ROUTED schemes came in the box hence you can write
fail-over scenarios if RELAY communication fails. Although there are
some good JavaScript based frameworks that do this in a much cleaner
manner.
It adds slew of other goodies which help in building android and IOS
clients without any pain.
STUN or TURN Servers are used only for Signalling Purpose, and this signalling happens before any actual transmission. This signal is very small and carries the IP address of both the browsers(machines running browsers). For Transmission the communication is done between Browsers(Peer to Peer) themselves, so no server is involved.
Your relay is not happening from a central server so you don't have
to pay for the outgoing bandwidth cost.
To Setup Turn Server,
Use this server, build it and put it into a Rackspace/Amazon Web
Services instance and you are Good with your TURN
Server. That is It, setup your application and have fun with WebRTC
for FREE.
rfc5766-turn-server
If you wish to Use some more free framework to ease yourself more, check out: EasyRTC and PeerJS
Enjoy Developing with WebRTC....
Twilio developer evangelist here.
Your link at the end of your question points to our WebRTC page, which currently talks about the product Twilio Client. Twilio Client briefly is a way that, using WebRTC within browsers and mobile applications you can make phone calls to real phone numbers. This product does not allow you to conduct video calls.
Twilio Client has a cost because of the ability to call out from a browser to a telephone number. The cost is not in the WebRTC portion, but delivering those minutes to the other leg of the call.
Notably, it's not 25 cents ($0.25) a minute, instead it is just a quarter of a cent ($0.0025) a minute.
With regards to video calls with WebRTC, you can now access the public beta of Twilio Video, a platform to make setting up WebRTC calls much easier.
Twilio Video costs for the signalling infrastructure and you can see the prices here. If a WebRTC connection requires a TURN server to relay the media, that also costs per gigabyte of transfer. Usage of the STUN server is free, the costs for the TURN relay are available here.
Please get in touch with me at philnash#twilio.com if you have any other questions about WebRTC.
WebRTC is a technology placed in a browser. It requires backend infrastructure to support it - specifically, STUN and TURN servers as well as signaling servers.
This boils down to the fact that you pay for WebRTC - same as you pay for hosting your website on a server. The price is higher, since the bandwidth needed in case of media relay is higher as well.
To understand more about WebRTC and how it works (as well as why there's a price tag associated with services such as Twilio for it), you can check this free report: https://bloggeek.me/webrtc-business-people/
WebRTC is already free for developers to use. When we added WebRTC to our product, we used this example code, which made it very simple to build a WebRTC client:
https://shanetully.com/2014/09/a-dead-simple-webrtc-example/
Google and Mozilla provide free STUN servers, and it is easy to set up a TURN server. Most clients will be able to connect via STUN, so you won't end up using too much bandwidth on your TURN server.
To set up your own TURN server, coturn seems to be the easiest to set up:
https://github.com/coturn/coturn
Make sure you read the "WEBRTC USAGE" section in the README.turnserver file.
"STUN or TURN Servers are used only for Signalling Purpose, and this signalling happens before any actual transmission. This signal is very small and carries the IP address of both the browsers(machines running browsers). For Transmission the communication is done between Browsers(Peer to Peer) themselves, so no server is involved."
if that is the case, then you should be able to do this on a standard web server using Java/php. PHP will get the IP address of the guys connected to it. Then its just a matter of storing them in MySQL, then making a javascript that would run when the user go to that page in the site.
I've been looking for a solution around using a VPS because running a dedicated server for signaling is like golfing with a Ferrari instead of a golf cart. I still don't think node is efficient. Its single threaded. so node's fararri can only go 5mph.
Since they went to the web site, the php service already can get their ip address what else does it need? All of the above solutions so far require you to pay for a dedicated app to run on a server connected to the web separately for what 5k of data? What a waste of electrons.
But I'm going to start a new thread that is going to be based on getting webrtc without the buy a "VPS" because we want a VPS-less solution.
can anyone help me what is the technical difference between WebRTC communication and the VoIP communication?
The question doesn't exactly make sense because it makes the assumption that VoIP is a technical stack, but it's not - it's a concept. The concept of sending Voice (V) over (o) Internet Protocols (IP). This means that different technology stacks can be used for accessing/capturing the media, establishing connections, negotiating streams, and transmitting streams.
WebRTC is one such stack (set of APIs, methods, and standards) for VoIP.
VOIP - Voice over Internet Protocol was a concept which came with popularity of internet. This involved using the internet to route voice telephony data, basically using existing IP infrastructure to transport audio streams without having dedicated circuit switched telephony. Over the time popular VOIP applications like Skype, Vonage and many in enterprise telephony came in.
VOIP had two parts one signalling , basically controller part and other actual media.
Actual media usually but not necessarily followed RTP (Real Time) protocol. RTP could carry both voice and video. Problem with RTP has been that browsers don't support it natively and it is not secure. You usually needed some sort of plugin to have VOIP work inside browser.
With WebRTC now popular browsers like FF, Chrome and Opera support a variation of RTP which is secure and can be natively invoked. Using WebRTC and browser Javascript you can send Voice, Video and Screen (it's video only) data to any other browser, which is cool.
VOIP : Voice over internet protocol uses DSL/Cable Modem voice over Wi-Fi/3G (VoWiFi/3G), voice over LTE (VoLTE), and Rich Communication Suite (RCS). VoIP is cloud-based, calls are sent as digital data and no cables are needed to send the call so any kind of Internet connection can be used to make calls and from a plethora of devices.
Web RTC: Web Real time communication use only OS browsers to communicate.
WebRTC requires the use of two main component JavaScript APIs.
WebRTC is an extension of VoIP to the browser world. It can reuse the existing VoIP infrastructure with incremental upgrades. This is good news for VoIP, as adoption of WebRTC only serves to increase overall VoIP proliferation.
Also, WebRTC is ideal for low-cost browser-based contact center applications. VoIP can serve embedded operator-driven VoLTE applications. Consequently, between WebRTC and VoIP, they can support wide range of consumer and enterprise applications.
I've got WebRTC peer to peer working but when I want to broadcast a single camera to multiple clients obviously peer to peer isn't suitable.
I've found solutions like
http://lynckia.com
and
http://www.medooze.com/products/mcu/webrtc-support.aspx
But the first I can't get setup (and it seems to have cross browser issues)
the second just feels like we're hitting a nail with a nuclear missile.
All I need is a relay, I don't need to decode / recode streams.
I just need
The Broadcaster to connect to the server (peer to peer)
The clients to connect to the server (peer to peer)
The server to relay the stream from the broadcaster to the clients.
Is there any software out there that offers this solution that I've missed? is there an alternative working and scalable alternative?
Thanks
Jitsi Video Bridge works pretty much exactly how you describe.
On your server you can run Janus, to which your broadcaster can provide a stream via RTP.
Have a look at an example configuration file.
After writing a configuration file which defines how the server receives stream from the broadcaster, you should be able to launch janus in the background via a command line interface tool:
$ janus --daemon --config=config_file.conf
Also, see streaming test demo.
Note: I have not tested this thoroughly.
Have a look at this github-repo inspired from muaz khan's WebRTC p2p scalable broadcast. This can work great on LAN. On internet, I am not sure how well it can work as of now though we are improving it on the go.
If you just want to broadcast from a peer to a set of peers, if they don't care about the latency, the best solution is to covert WebRTC to live streaming, without transcoding just muxing:
Peer(Publisher) ---WebRTC--> Server --RTMP/HLS/DASH--> Peers/Players
If this works good for you, SRS is able to covert WebRTC to live streaming.
Because live streaming allows you to use CDN or TCP to deliver the streams, and the latency is about 3~5s, so this solution is only available when Peers/Players never need to communicate to the Peer(Publisher).
If you want all those peers to talk to each other, it's very complex and need a WebRTC SFU cluster to do this, there will be a huge number of streams. For example, if allows 100 peers to talk to each other, there will be 100x100 = 10k streams.
It's too complicated, so I don't think there is good open-source solution right now(at 2022.02).
I'm testing Audio/Video P2P connection between mobile devices.
Studying WebRTC, I've noticed NAT traversal(uses STUN server) and UDP-hole-punching is the key to make P2P possible.
On the other hand, I've noticed HLS(HttpLiveStreaming) on iOS devices is very optimized for A/V live streaming, and widely available even with Android4.x(3.x unstable)
So, here is my question if I use HLS for mobile P2P:
a) HLS is a protocol on TCP(HTTP) not UDP, so isn't there a performance drawback?
See: TCP vs UDP on video stream
b) How about NAT traversal? Will it be easier since HLS is HTTP(port:80)?
I have read wikipedia http://en.wikipedia.org/wiki/HTTP_Live_Streaming
Since its requests use only standard HTTP transactions, HTTP Live
Streaming is capable of traversing any firewall or proxy server that
lets through standard HTTP traffic, unlike UDP-based protocols such as
RTP. This also allows content to be delivered over widely available
CDNs.
c) How about android device compatibility? Is there a lot of problems to invoke StreamingLive distribution?
Thanks.
The reason why firewalls are not an issue for HLS is that it's a client-server protocol where all requests are done via HTTP on port 80. If you are implementing a P2P application, you won't be able to attach it to a port below 1024 unless you have root privileges.
This means that exchanging data via HLS (port 80) won't work for P2P. Unless you have a translation server in the middle, which defeats the purpose of P2P.
Comparing HTTP Live Streaming to P2P video streaming over UDP/RTP is almost like comparing apples and oranges. More like oranges and tangerines... read on.
HTTP Live Streaming was designed as client-server protocol without P2P or NAT traversal consideration. The idea being that the streaming server is already over HTTP/TCP and accessible from the public internet as if it was just an ordinary web server. The key features of HLS is its ability to dynamically switch the bitrate based on how well the client receives the stream. If the client connection to the server hiccups trying to stream down a 1080p video, it can transparently switch to sending a lower bitrate video (and likely switch back to streaming at higher bitrate if network conditions improve). Good example: Netflix.
WebRTC and ICE were designed to stream real time video bidirectionally between devices that might both behind NATs. As such, traversing a NAT through UDP is much easier than TCP. UDP lends itself to real-time (less latency) than TCP. Most video-chat clients (ala Skype) have dynamic bandwidth adjustments built in to their codecs and protocols to achieve something similar to what HLS does.
I suppose you could combine TCP NAT traveral and HLS together. Doing HLS over UDP implies that you build a TCP like reliability layer on top of your UDP stream.
Hope this helps
http://www.garymcgath.com/streamingprotocols.html
HTTP Live Streaming
The new trend in streaming is the use of HTTP with protocols that
support adaptive bitrates. This is theoretically a bad fit, as HTTP
with TCP/IP is designed for reliable delivery rather than keeping up a
steady flow, but with the prevalence of high-speed connections these
days it doesn't matter so much. Apple's entry is HTTP Live Streaming,
aka HLS or Cupertino streaming. It was developed by Apple for iOS and
isn't widely supported outside of Apple's products. Long Tail Video
provides a testing page to determine whether a browser supports HLS.
Its specification is available as an Internet Draft. The draft
contains proprietary material, and publishing derivative works is
prohibited.
The only playlist format allowed is M3U Extended (.m3u or .m3u8), but the format of the streams is restricted only by the implementation.
I could achieve P2P on top of HLS using WebRTC on a Android with a Mozilla Firefox browser and two others desktop browsers (Chrome and Firefox) on the same swarm.
Here's a screenshot of a presentation that I've made on the University: https://www.dropbox.com/s/zyfgs4o8al9ovd0/Screenshot%202014-07-17%2019.58.15.png
This screenshot was made by acessing http://bem.tv/demo.html.
If you want to know more about, this is my masters project and I'm publishing my advances on http://bem.tv and http://github.com/bemtv.