What can the Pion team do to make WebRTC easier

[Sean-Der]

This issue is for everyone to vote and suggest different ideas on how we can make WebRTC better. The ideas don't have to relate to Pion at all. Try to think of ideas that don't just help you today. Things you wish existed when learning WebRTC.

If you see a project that looks like something you would find interesting you should go build it!

[Sean-Der]

Zero Configuration TURN Server

Many users get turned away from WebRTC because setting up a TURN server is too difficult. They can be difficult to install, and if configured incorrectly can be hard to debug.

To improve things we should provide A TURN server that a single binary that configures itself. It would run health checks and make sure everything works without user configuration. It would have features like the following.

• Provide static binaries for every platform. No building required.
• Automatically determine your 'world routable'/'public ip' via STUN to popular public servers.
• Enable UDP/TCP
• Optional JSON configuration file. The server should be able to start without one though.
• If FQDN is set in config enable TLS/DTLS listeners. Generate a certificate with LetsEncrypt.
• Flexible auth. Allow username/passwords, Long-Term Credential Mechanism or a custom callback to integrate with databases/LDAP etc..

[Sean-Der]

WebRTC State Explainer

Debugging WebRTC is hard for new and old users. So many different things can go wrong and users aren't even sure where to look. This happens at all stages of WebRTC usage. From the first days when learning, all the way to massive production deployments.

We should provide a utility that analyzes a PeerConnection and getStats and gives users a useful diagnostic output in a single page. I would like to see details like.

• How many tracks exists in each SessionDescription
• How many recvonly/sendrecv Transceivers exist for each SessionDescription
• What codecs/header extensions are in each SessionDescription
• Did ICE Pass/Fail
• What candidate types did each side emit
• Did DTLS Pass/Fail
• What CipherSuite is being used
• TODO

We should level things. We don't want to burden users with informational details if an error was encountered.

[jtestard]

Zero-Configuration WebRTC Stats Gathering

Determining the quality of WebRTC connections is a difficult process. Answer questions like:

• For a given call, how did it go?
• How often does signaling succeed?
• What was the latency, frame rate...

Having a way for Pion to release stats which can be easily collected by a third party server (promotheus?) for monitoring or historical analysis.

TODO:

• Determine the right stats to collect.
• Determine a single format that is shared by a sufficient count third party tools.

[tomandersen]

Zero Configuration TURN Server - Not important - to me that is a whole project - I just went to Xirsys - free or low end plan.

WebRTC State Explainer - SOUNDS GREAT

Zero-Configuration WebRTC Stats Gathering - Would be cool. Could even be used to see what percentage of minutes are billed, etc.

[projetoarduino]

For me, the hardest thing is to find consistent and easy examples. The best way to learn is through examples, and many of the pion examples don't apply to real life others try to do too much and don't work like this one https://github .com/pion/mediadevices,

here is a good example that you look at and immediately understand how it works
https://github.com/ashellunts/ffmpeg-to-webrtc

Until today there is no example of audio and video communication, input and output

The decision to use gstreamer and the gst.go library makes the job more difficult because gstreamer has many plugins, and when using the examples it doesn't tell you which plugin is missing, you should reconsider and create examples with ffmpeg.

This is my opinion, but I would also like to congratulate you because the pion is an excellent tool and your work is very important to me.

[gitautas]

To me the importance of ICE candidate exchange was difficult to grasp, I feel like none of the documentation really explains it very well.

[dsteinman]

Is there an example of how to use Pion as BOTH the server and the client (for audio only calls, and no web browser involved)?

I've just about exhausted all other languages and webrtc frameworks that are capable of doing this and I have yet to see any examples of them. (I also need this to work on Raspberry Pi Zero W)

[gitautas]

Is there an example of how to use Pion as BOTH the server and the client (for audio only calls, and no web browser involved)?

I've just about exhausted all other languages and webrtc frameworks that are capable of doing this and I have yet to see any examples of them. (I also need this to work on Raspberry Pi Zero W)

https://github.com/pion/webrtc/tree/master/examples/pion-to-pion

[dsteinman]

Is there an example of how to use Pion as BOTH the server and the client (for audio only calls, and no web browser involved)?
I've just about exhausted all other languages and webrtc frameworks that are capable of doing this and I have yet to see any examples of them. (I also need this to work on Raspberry Pi Zero W)

https://github.com/pion/webrtc/tree/master/examples/pion-to-pion

This looks like only data exchange, no audio or video?

[ivelin]

peerfetch port to Go and Pion

One of the recurring request themes for webrtc adoption is simplicity.
A common use case is direct browser to IoT device (or private web server) connectivity. peerfetch tries to make that simple with a p2p http API over webrtc datachannel. From the client's point of view, the API looks similar to HTML fetch(). On the server side, it's a standalone proxy that allows on-device REST API to be accessed by remote peerfetch clients. Workshop video available.

Hello World example here.

It is built on top of PeerJS (browser client) and peerjs-python (server).

Basic working implementation available here:
https://github.com/ambianic/peerfetch

There is a Go port of PeerJS by @muka and early work on dhttp, which has similar goals as peerfetch.

With a little more community support, we could move towards a multi-platform interoperable implementation that allows browser apps on mobile and desktop to directly access private web servers without a trusted cloud intermediary.

[fotiDim]

Zero Configuration TURN Server

Many users get turned away from WebRTC because setting up a TURN server is too difficult. They can be difficult to install, and if configured incorrectly can be hard to debug.

To improve things we should provide A TURN server that a single binary that configures itself. It would run health checks and make sure everything works without user configuration. It would have features like the following.

• Provide static binaries for every platform. No building required.
• Automatically determine your 'world routable'/'public ip' via STUN to popular public servers.
• Enable UDP/TCP
• Optional JSON configuration file. The server should be able to start without one though.
• If FQDN is set in config enable TLS/DTLS listeners. Generate a certificate with LetsEncrypt.
• Flexible auth. Allow username/passwords, Long-Term Credential Mechanism or a custom callback to integrate with databases/LDAP etc..

@Sean-Der I am trying to understand if this proposal is related to the comment made here: "You don't need to run servers to bridge the media or get a world routable IP even.". Was something like that used by Formant? Or were you simply referring to the inherent traits of WebRTC (P2P and NAT traversal)?

[Sean-Der]

Hey @fotiDim

I was just referring to the inherent traits of WebRTC. I am not familiar with how formant exactly works!

[mohammadne]

I think #1998 can help