Anybody here with some experience in websockets and webRTC using TURN/STUN servers?
Requirement:
Send real-time video feed from local IP to browser in an external network and I need some help implementing via raspberry pi 3b+. My camera source is android device, and using 3rd party apps I am able to generate the video feed over local network. Using the same app I can stream via Youtube Live,but getting a latency of about 2 secs in ultra low latency mode and dvr enabled. And I am trying to reduce the latency of the stream.
Q1. Do the semi-public TURN server provide a one to one peer. Or anyone can just jump into the URL and view and override what I am streaming?Please provide few list of service providers.
Just for information there would be 1-2 users browser connected at max.
Q2. Do I need Janus gateway to send webRTC/websockets data into the TURN/STUN server? Since my raspberry is connected to a different network and I cannot port forward due to carrier constraints.
Q3. Do I need both STUN/TURN servers or do I even need webRTC instead of websockets to send my video stream over the internet. Is websockets not sufficient?
Q4. Since we are not implementing over local network do we need to install coTURN too on raspberry pi?
Q5. Is there any android app that can publish the data from camera to websocket/werRTC server with a public ws URL?
Any help would be really helpful.
Q1. TURN servers relay media. They do this by allocating for every connecting peer a relay port between 49152–65535. This relay port will then be used to transmit the media to the second peer. The peers will know which relay ports to use automatically since this is part of the ice gathering process. To get back to your question: Other Peers cannot write to that relay port, it is 1 to 1 with handshakes, there is no chance of someone else overwriting it.
Q2. You definitely do not need a Janus Gateway to use TURN. TURN and STUN will probably work fine for NAT-Traversal without port forwarding.
Q3. You need at least a TURN server (but you ideally want to use 1 STUN server and 1 TURN server). STUN will work in most cases, but will fail if there are firewalls or complicated NATs, which block inbound udp connections. TURN is just the fallback for those cases.
Needing WebRTC? For just streaming videos, it depends on the use case. A sequence of images can be transmitted over websockets, they can handle Blobs fine. But you won't have a very fluent, high fps AND high resolution video stream this way. And of course, I know of no usable way to transmit audio over websocket.
Q4. The raspberry pi is a Peer that transmits media? Peers do not need a local TURN server installation, you will only need 1 TURN server (which should not be behind a NAT, probably running on some web server). The TURN server is a separate instance.
EDIT
For your private testing and development purposes, you may use https://numb.viagenie.ca/ . I don't know much about commercial turn server hosters, except that some exist. For someone who owns a v-server or root server, installing coTURN may be an option, this Tutorial might be helpful. To check if the server is working, I also found this snippet to be very useful.
END EDIT
Q5. There is no android app that publishes webRTC streams to a ws URL since websocket
messages are used by webrtc only for signalling (that is, telling peers their host candidates, those are the IP adresses and ports learned by the ice gathering process, this includes the TURN and STUN ip and port combinations).
Related
So I've seen projects like trojan-go,v2ray-go
They are making their own proxy protocols in user space level. I am trying to do the same thing but I don't know how to redirect network traffic from clients to proxy server.
Basically I don't understand how those tools (or any tool) can redirect internet traffic of the device to a certain server, so when the packets are going to the internet they go to the proxy server first instead of their destination ip address.
How can I do it in golang without dealing with netlink and Iptables?
I know apps like wireguard do this by dealing with layer 3-4 stuff using netlink API but I need to know how apps do it without adding a new network interface.
[This post has been updated with a possible approach, which is added to the bottom]
I am trying to create a web socket connection between two devices((A). chrome in different computer and (B) a raspberry pi) in different networks. Thus, i can send video data over websockets. However, I cannot port forward the network of my router to expose my local IP to the network, thus, I can't send the data right away.
Figure below explains the architechture.
Thus ,I am trying to implement a logic so that Device A websockets the public ws of the cloud while, the cloud actually gets the data from Device B.So Device A websockets device B indirectly.
Device A<==>Cloud Server<==>Device B
The cloud could be something like a proxy or a relay websocket server.
The video feed needs to be sent in real time,
Please suggest how can i proceed with it.
Additional note, i have acquired an instance of digitalocean as VPS, following the blog Accessing home services from anywhere, without port forwarding! but not sure how to proceed.
Update(11th Nov,2019):
I am planning to use a websocket server on DigitalOcean instance(droplet),which would be listening to my local IP/port of my raspberry pi.And this VPS would act as a websocket server,which would redirect the traffic.
However, I am unsure how to use the same.And need your kind suggestions.
I have a concox GT06 device from which I want to send tracking data to my AWS Server.
The coding protocol manual that comes with it only explains the data structure and protocol.
How does my server receive the GPS data collected by my tracker?
Verify if your server allows you to open sockets, which most low cost solutions do NOT allow for security reasons (i recommend using an Amazon EC2 virtual machine as your platform).
Choose a port on which your application will listen to incoming data, verify if it is open (if not open it) and code your application (i use C++) to listen to that port.
Compile and run your application on the server (and make sure that it stays alive).
Configure your tracker (usually by sending an sms to it) to send data to your server's IP and to the port which your application is listening to.
If you are, as i suspect you are, just beginning, consider that you will invest 2 to 3 weeks to develop this solution from scratch. You might also consider looking for a predeveloped tracking platform, which may or may not be acceptable in terms of data security.
You can find examples and tutorials online. I am usually very open with my coding and would gladly send a copy of the socket server, but, in this case, for security reasons, i cannot do so.
Instead of direct parsing of TCP or UDP packets you may use simplified solution putting in-between middleware backends specialized in data parsing e.g. flespi.
In such approach you may use HTTP REST API to fetch each new portion of data from trackers sent to you dedicated IP:port (called channel) or even send standardized commands with HTTP REST to connected devices.
At the same time it is possible to open MQTT connection using standard libraries and receive converted into JSON messages from devices as MQTT in real time, which is even better then REST due to almost zero latency.
If you are using python you may take a look at open-source flespi_receiver library. In this approach with 10 lines of code you may have on your EC2 whole parsed into JSON messages from Concox GT06.
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 4 years ago.
Improve this question
So I'm looking to build a chat app that will allow video, audio, and text. I spent some time researching into Websockets and WebRTC to decide which to use. Since there are plenty of video and audio apps with WebRTC, this sounds like a reasonable choice, but are there other things I should consider?
Feel free to share your thoughts.
Things like:
Due to being new WebRTC is available only on some browsers, while WebSockets seems to be in more browsers.
Scalability - Websockets uses a server for session and WebRTC seems to be p2p.
Multiplexing/multiple chatrooms - Used in Google+ Hangouts, and I'm still viewing demo apps on how to implement.
Server - Websockets needs RedisSessionStore or RabbitMQ to scale across multiple machines.
WebRTC is designed for high-performance, high quality communication of video, audio and arbitrary data. In other words, for apps exactly like what you describe.
WebRTC apps need a service via which they can exchange network and media metadata, a process known as signaling. However, once signaling has taken place, video/audio/data is streamed directly between clients, avoiding the performance cost of streaming via an intermediary server.
WebSocket on the other hand is designed for bi-directional communication between client and server. It is possible to stream audio and video over WebSocket (see here for example), but the technology and APIs are not inherently designed for efficient, robust streaming in the way that WebRTC is.
As other replies have said, WebSocket can be used for signaling.
I maintain a list of WebRTC resources: strongly recommend you start by looking at the 2013 Google I/O presentation about WebRTC.
Websockets use TCP protocol.
WebRTC is mainly UDP.
Thus main reason of using WebRTC instead of Websocket is latency.
With websocket streaming you will have either high latency or choppy playback with low latency. With WebRTC you may achive low-latency and smooth playback which is crucial stuff for VoIP communications.
Just try to test these technology with a network loss, i.e. 2%. You will see high delays in the Websocket stream.
WebSockets:
Ratified IETF standard (6455) with support across all modern browsers and even legacy browsers using web-socket-js polyfill.
Uses HTTP compatible handshake and default ports making it much easier to use with existing firewall, proxy and web server infrastructure.
Much simpler browser API. Basically one constructor with a couple of callbacks.
Client/browser to server only.
Only supports reliable, in-order transport because it is built On TCP. This means packet drops can delay all subsequent packets.
WebRTC:
Just beginning to be supported by Chrome and Firefox. MS has proposed an incompatible variant. The DataChannel component is not yet compatible between Firefox and Chrome.
WebRTC is browser to browser in ideal circumstances but even then almost always requires a signaling server to setup the connections. The most common signaling server solutions right now use WebSockets.
Transport layer is configurable with application able to choose if connection is in-order and/or reliable.
Complex and multilayered browser API. There are JS libs to provide a simpler API but these are young and rapidly changing (just like WebRTC itself).
webRTC or websockets? Why not use both.
When building a video/audio/text chat, webRTC is definitely a good choice since it uses peer to peer technology and once the connection is up and running, you do not need to pass the communication via a server (unless using TURN).
When setting up the webRTC communication you have to involve some sort of signaling mechanism. Websockets could be a good choice here, but webRTC is the way to go for the video/audio/text info. Chat rooms is accomplished in the signaling.
But, as you mention, not every browser supports webRTC, so websockets can sometimes be a good fallback for those browsers.
Security is one aspect you missed.
With Websockets the data has to go via a central webserver which typically sees all the traffic and can access it.
With WebRTC the data is end-to-end encrypted and does not pass through a server (except sometimes TURN servers are needed, but they have no access to the body of the messages they forward).
Depending on your application this may or may not matter.
If you are sending large amounts of data, the saving in cloud bandwidth costs due to webRTC's P2P architecture may be worth considering too.
Comparing websocket and webrtc is unfair.
Websocket is based on top of TCP. Packet's boundary can be detected from header information of a websocket packet unlike tcp.
Typically, webrtc makes use of websocket. The signalling for webrtc is not defined, it is upto the service provider what kind of signalling he wants to use. It may be SIP, HTTP, JSON or any text / binary message.
The signalling messages can be send / received using websocket.
Webrtc is a part of peer to peer connection.
We all know that before creating peer to peer connection, it requires handshaking process to establish peer to peer connection.
And websockets play the role of handshaking process.
Websocket and WebRTC can be used together, Websocket as a signal channel of WebRTC, and webrtc is a video/audio/text channel, also WebRTC can be in UDP also in TURN relay, TURN relay support TCP HTTP also HTTPS.
Many projects use Websocket and WebRTC together.
I am trying to understand the difference between WebRTC and WebSockets so that I can better understand which scenario calls for what. I am curious about the broad idea of two parties (mainly web based, but potentially one being a dedicated server application) talking to each other.
Assumption:
Clearly in regards to ad-hoc networks, WebRTC wins as it natively supports the ICE protocol/method.
Questions:
Regarding direct communication between two known parties in-browser, if I am not relying on sending multimedia data, and I am only interested in sending integer data, does WebRTC give me any advantages over webSockets other than data encryption?
Regarding a dedicated server speaking to a browser based client, which platform gives me an advantage? I would need to code a WebRTC server (is this possible out of browser?), or I would need to code a WebSocket server (a quick google search makes me think this is possible).
There is one significant difference: WebSockets works via TCP, WebRTC works via UDP.
In fact, WebRTC is SRTP protocol with some additional features like STUN, ICE, DTLS etc. and internal VoIP features such as Adaptive Jitter Buffer, AEC, AGC etc.
So, WebSockets is designed for reliable communication. It is a good choice if you want to send any data that must be sent reliably.
When you use WebRTC, the transmitted stream is unreliable. Some packets can get lost in the network. It is bad if you send critical data, for example for financial processing, the same issue is ideally suitable when you send audio or video stream where some frames can be lost without any noticeable quality issues.
If you want to send data channel via WebRTC, you should have some forward error correction algorithm to restore data if a data frame was lost in the network.
WebRTC specifies media transport over RTP .. which can work P2P under certain circumstances. In any case to establish a webRTC session you will need a signaling protocol also .. and for that WebSocket is a likely choice. In other words: unless you want to stream real-time media, WebSocket is probably a better fit.
Question 1: Yes. The DataChannel part of WebRTC gives you advantages in this case, because it allows you to create a peer to peer channel between browsers to send and receive any raw data you want. Websockets forces you to use a server to connect both parties.
Question 2 Like I said in the previous response, Websockets are better if you want a server-client communication, and there are many implementations to do this (i.e. jWebSocket). To add support in a server to establish a connection with a WebRTC DataChannel, it may take you some days of life and health. :)