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

Question

How do you send a UDP Packet using Web RTC?

Answer 1

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.

Answer 2

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

Answer 3

@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;

1. Why is TCP traversal not problematic?
2. 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

1. For Audio, Video Channels, WebRtc uses combinations of RTP, RTCP, SRTP over DTLS.
2. 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