How to send a UDP Packet with Web RTC - Javascript? - javascript

How do you send a UDP Packet using Web RTC?

You can't send a UDP packet directly with WebRTC. That would violate the basic security constraints required by the browser.
You can send SRTP to an ICE-enabled host. That is probably not what you are looking for.
If a browser permitted sending arbitrary UDP packets, then malicious applications could send packets to any host.
This might not sound so bad, after all, hosts on the Internet need to be able to deal with that right? The problem is that some browsers are in protected environments where access to the network is restricted. Within those networks, some hosts are far less protected than a host on the public Internet might be. This would be OK, since access to the network is controlled.
If it were possible for a browser to send arbitrary packets, a user on a browser in that environment could be convinced to send specifically crafted packets to one of these poorly protected hosts. Likely, that would result in the network operator banning the browser, which is something browser-makers want very much to avoid.
WebRTC only sends certain types of UDP packet under specific conditions. If the host that you are interested in talking to understands ICE and is able to consume RTP with SRTP or SCTP over DTLS (unlikely methinks). Then perhaps you could force the browser to send something.

You should check sipml5, http://code.google.com/p/sipml5/
get the code and look into the folder:
sipml5/src/tinySIP/src/transports

#Martin Thomson has explained the problem very well. By taking
motivation from his post, this post might provide guidance to some
geeks and newbies.
It is being said that WebRtc is Real-time, Bi-directional, Secure communication between two or more peers. I will more focus on the word: Secure.
Security policies of enterprise networks typically require filtering of incoming unsolicited traffic, blocking certain protocols, and doing application-level filtering and scanning for spam, malware, and intellectual property.
Now two new questions come to mind;
Why is TCP traversal not problematic?
Why is UDP traversal problematic?
Why is TCP traversal not problematic?
TCP clearly indicates two things;
The beginning of a flow (SYN) and,
The end of a flow (FIN or RST).
This is used by firewalls to open and close pinholes. Exceptionally, a TCP connection that has received no traffic for a long time also has its pinhole closed (to accommodate network topology changes or failure of both TCP peers). Firewalls also perform protocol validation to clean up problems with
Out-of-window TCP segments and,
Overlapping TCP segments
This allows the firewall to protect the network and protect hosts from
several attack vectors (replay attacks, host IP address probing, DDOS
attack, etc.).
Why is UDP traversal problematic?
For UDP flows, the first outgoing packet on a 5-tuple will be used by the firewall as a start-of-session indicator. But UDP does not have an end-of-session indicator, so the firewall has only two ways to close a pinhole:
Timing out the pinhole after the interior host does not send traffic
for several seconds or
The interior host generates a fatal ICMP error.
Because there is no reliable way to determine that a session is being stopped, the firewall has a much harder job. It could implement an Application-level Gateway (ALG) and be aware of whatever semantics are imposed by the higher-level code on top of UDP.
It could also rely on a set of well-known application servers to inform it of sessions as they start and end, but that suffers from many challenges as application servers are hosted independently of the network on which they are used.
Using an ALG, a firewall can determine when the call is terminated and
close any dynamic mappings created for the media session. But the
problem is session signaling between the WebRTC application running in
the browser and the Web server that could be using TLS, in which case
the ALG no longer has access to the signaling.
Conclusion:
So, at the Application-Level Gateway, Webrtc utilizes a combination of SDP and ICE. WebRtc basically wraps UDP in such a way that
For Audio, Video Channels, WebRtc uses combinations of RTP, RTCP, SRTP over DTLS.
For Data Channels, webrtc uses the Stream Control Transmission Protocol (SCTP), defined in RFC 2960.
SCTP is a transport layer protocol that was intended as an alternative
to TCP or UDP. For WebRtc, we use it as an application layer
protocol that runs over our DTLS connection.
These protocols also come with some new protocols such as STUN, TURN. For the basic implementations of WebRtc Please follow;
WebRtc Experiments by Mauz Khan
WebRtc Experiments by Muhammad Usman Bashir
I hope this explanation might help some of the geeks. Thanks

Related

Will http3 support UDP from javascript within browser

As browsers and servers implement Http3, a lot of TCP communication will move over to UDP (QUIC).
However, it is not clear to me whether the UDP based communication primitives will be available from within the browser itself. Meaning, like one can do Ajax requests today through javascript, will browser javascript support UDP requests? Or better, large messages over UDP reliably (with necessary encryption built on top of UDP via the wrapping QUIC of course)?
This will simplify peer to peer browser communication and open up many innovative applications. Today these need to take the cumbersome STUN/TURN and WebRTC (which also uses UDP underneath) routes.
But then direct UDP has other issues, especially security concerns.
Thanks in advance.
... like one can do Ajax requests today through javascript, will browser javascript support UDP requests?
Ajax is still HTTP and not plain TCP. Ajax will continue to work and will transparently use HTTP/3 if available.
... Or better, large messages over UDP reliably (with necessary encryption built on top of UDP via the wrapping QUIC of course)?
Similar, large messages which until now used HTTP/1 or HTTP/2 over TCP will now transparently use HTTP/3 over UDP.
This will simplify peer to peer browser communication and open up many innovative applications. Today these need to take the cumbersome STUN/TURN and WebRTC (which also uses UDP underneath) routes.
No, it will not help with this. HTTP/3 will not provide plain UDP connections the same as HTTP/1 and HTTP/2 did not provide plain TCP connections.

Is it possible to make p2p chat using javascript without server?

Recently i've been choosen as backend lider for course on my studies. We are suppossed to write BE for chat app that will allow users to communicate p2p without any server code (i know it means that there's no BE, but my proffessor isn't technical person). I've asked him if it could use webrtc, but he didn't like the idea of using STUN and TURN servers. So my main question is, is this possible at all? We are talking about an app that will run in browser, not directly in OS. And if it is, what protocols/apis can we use to achieve that?
I am not sure if I get your question right, so here are some general informations:
WebRTC as a P2P API relies heavily on servers.
"ICE":
To connect one Peer to the other Peer, the peers need to know their IP address to exchange data. They can "ask" their OS for the registered IP, but this will only yield 127.0.0.1 and their local Network IP. This works for connections on the same computer or between computers in the same local network, but it will fail for everything else.
The ICE Servers STUN and TURN are necessary, since your browser clients are behind your Routers Network Address Translation (NAT). STUN gets the NATs IP Address and Port and TURN forwards Packets as a known, public IP Address if STUN fails.
"Signaling":
Let's assume, that your Peers know their own reachable IP-Addresses (- probably the NATs IP and Port by using STUN and maybe even TURN). Even IF (!) they know their reachable IP, they have to tell the other Peer that this IP is in fact, their IP and the IP to use to contact them. They also have to tell the other Peer some other technical information to make the transmission of data work. To use WebRTC, you need to have a WebSocket-Server (or a combination of Server-Sent-Events and HTTP Post Messages), which forward this information.
After everything is established (they know their respective IPs and Ports, technical information, etc.), you can then send data over WebRTCs DataChannels.
My Advice:
Do not use WebRTC for the given use case. If you do not want to use a Backend-Server, you have to search for "serverless" Web-Apps. P2P will always rely on some sort of server to start the connection. If you use a "serverless" architecture, someone else is hosting the server / chat service you want to use (also commonly referred as "cloud based"). If it is about hosting costs for a prototype app, you may have a look at heroku.com, aws.amazon.com, zeit.co, firebase.google.com or other hosting providers with free, limited (test) plans.

Webrtc on fails on local network without internet connectivity [duplicate]

WebRTC signalling is driving me crazy. My use-case is quite simple: a bidirectional audio intercom between a kiosk and to a control room webapp. Both computers are on the same network. Neither has internet access, all machines have known static IPs.
Everything I read wants me to use STUN/TURN/ICE servers. The acronyms for this is endless, contributing to my migraine but if this were a standard application, I'd just open a port, tell the other client about it (I can do this via the webapp if I need to) and have the other connect.
Can I do this with WebRTC? Without running a dozen signalling servers?
For the sake of examples, how would you connect a browser running on 192.168.0.101 to one running on 192.168.0.102?
STUN/TURN is different from signaling.
STUN/TURN in WebRTC are used to gather ICE candidates. Signaling is used to transmit between these two PCs the session description (offer and answer).
You can use free STUN server (like stun.l.google.com or stun.services.mozilla.org). There are also free TURN servers, but not too many (these are resource expensive). One is numb.vigenie.ca.
Now there's no signaling server, because these are custom and can be done in many ways. Here's an article that I wrote. I ended up using Stomp now on client side and Spring on server side.
I guess you can tamper with SDP and inject the ICE candidates statically, but you'll still need to exchange SDP (and that's dinamycally generated each session) between these two PCs somehow. Even though, taking into account that the configuration will not change, I guess you can exchange it once (through the means of copy-paste :) ), stored it somewhere and use it every time.
If your end-points have static IPs then you can ignore STUN, TURN and ICE, which are just power-tools to drill holes in firewalls. Most people aren't that lucky.
Due to how WebRTC is structured, end-points do need a way to exchange call setup information (SDP) like media ports and key information ahead of time. How you get that information from A to B and back to A, is entirely up to you ("signaling server" is just a fancy word for this), but most people use something like a web socket server, the tic-tac-toe of client-initiated communication.
I think the simplest way to make this work on a private network without an internet connection is to install a basic web socket server on one of the machines.
As an example I recommend the very simple https://github.com/emannion/webrtc-web-socket which worked on my private network without an internet connection.
Follow the instructions to install the web socket server on e.g. 192.168.1.101, then have both end-points connect to 192.168.0.101:1337 with Chrome or Firefox. Share camera on both ends in the basic demo web UI, and hit Connect and you should be good to go.
If you need to do this entirely without any server, then this answer to a related question at least highlights the information you'd need to send across (in a cut'n'paste demo).

Send text between two peers each in a browser without 3rd party server (or server only at the beginning to make peers know each other)

Note: I've already read this question, its main answer and all the linked questions given there (more than 8 questions, such as this one but it talks about Flash, etc.). They are all ~ 2011, and things might have changed, thanks to new tech like WebRTC, etc.
Question:
If I give my IP to a friend, and he gives me his IP, can we send bytes to each other directly in the browser, with Javascript? (both users not in the same local network but connected via internet)
If possible, without any 3rd party server. In this case we would both load a local HTML file containg the Javascript code allowing connection to each other. It seems possible to do such things with "chownat":
allows clients behind NATs to communicate with a server behind a separate NAT with no port forwarding no DMZ setup, and no 3rd party involvement.
If not possible without any server, then is it possible with a server involved just at the beginning of the process? (to make peers meet / know each other / to initiate the connection). Then once connection is established, the server would not be needed anymore: the 2 peers send bytes to each other, without server.
Is 1. or 2. possible nowadays with a standard browser (Firefox, Chrome, etc.) and without any router port configuration? With WebRTC for example?
Note: I've read about RTCDataChannel and tried this Simple_RTCDataChannel_sample but I don't see how two distant people can use this to connect to each other, this sample doesn't cover that. Here is the live demo. I don't see how it can be turned into a connection between two peers on internet.
If I give my IP to a friend, and he gives me his IP, can we send bytes to each other directly in the browser, with Javascript? [...] If possible, without any 3rd party server.
No, WebRTC uses session establishment tokens which cannot be reused, they must be generated anew for each connection. The IP address is not sufficient to establish a connection, at least such a token must also be generated and exchanged, either manually or...
If not possible without any server, then is it possible with a server involved just at the beginning of the process?
Yes, the server would act as rendezvous point to exchange tokens and optionally as STUN server.
Is 1. or 2. possible nowadays with a standard browser (Firefox, Chrome, etc.) and without any router port configuration?
That depends on your router(s), more specifically behind what types and how many layers of NAT each party is. But if they are well-behaved then the browsers will attempt NAT traversal with the help of a STUN server to establish a direct connection.
But generally browsers are less powerful when it comes to NAT traversal than native applications since native applications can talk to the firewall, UPnP/PMP/PCP routers and may also try NAT traversal techniques (e.g. TTL-based punching, linear port guessing) that are not part of the standard ICE/STUN approach.

Establish connection with WebSocket

I begin with this technology. I want to establish a TCP/IP connection with an electronic card that has an IP address (the server's map).
I wonder if the WebSocket allow me to make this connection, knowing that at present my interface communicates with the card through a socket implanted in an applet.
Does anyone know the syntax to connect with WebSocket as a parameter an IP address: 135.120.138.105
Thank you
WebSockets are not raw TCP sockets. They have many of the same characteristics (low overhead, persistent, bidirectional, full-duplex) as raw TCP sockets, but they have an initial HTTP-like handshake to implement CORS security and allow easier integration with web servers and existing firewall policies. WebSockets are also message based and have a small header on each frame (2 bytes overhead for small payloads).
You have a couple of options. You can use a program that bridges/proxies between WebSockets and raw TCP sockets such websockify (Disclaimer: I made websockify) or you can implement the server side of the WebSocket protocol in your server.
WebSockets won't work in your case. While they use TCP/IP, WebSockets have a different API that's designed for higher-level messages to be passed between server and client and it requires support on the server as well, so unless the card contains a WebSocket-enabled web server I think you're out of luck and you'll have to continue with your applet-based design.

Categories