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.

[mohammadne]

I think #1998 can help

[hariprasath2603]

UI based configuration setup.

[flyqie]

@projetoarduino

According to my practical experience, gstreamer is indeed more complicated than ffmpeg.

I personally think that examples of both gstreamer and ffmpeg should be provided, ffmpeg is suitable for beginners, and gstreamer is suitable for advanced users.

There are areas where ffmpeg is excellent, but there are areas where gstreamer is the obvious choice.

For example, I am currently developing a device remote control project. When collecting audio and video, I found that gstreamer is easier than ffmpeg to configure parameters that may change at any time, and it also allows me to customize many behaviors (of course, gstreamer is in some areas use is still a nightmare).

I will help improve the examples in my free time, let more people know and use ffmpeg, gstreamer, webrtc, these are very useful tools, they can help us achieve many things that were previously powerless faster and better, which is very exciting Excited.

[vipcxj]

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

Using pending candidate, It's cumbersome and awkward, I think the pion can hide it for the user. I found a solution from stackoverflow which calling setRemoveDescription using the offer creating locally. It seems counter-intuitive, so I haven't try it.
By the way it seems that pion not support rollback, so it's impossible to use pion to achieve perfect negotiation. Though perfect negotiation is not necessity, I need a standary way to isolation negotiation logic. My code rarely trigger a negotiation error which says wrong state: stable -> setremotedescription -> stable.

[frbrno]

I would like to see an http server example with authentication necessary to view the streams.

[Sean-Der]

@frbrno Does https://github.com/glimesh/broadcast-box fit that need?

[bradleypeabody]

I'm new to this project but one of the first things I ran into was wanting to run some of the code myself (e.g. copying code from https://github.com/pion/webrtc/tree/master/examples/play-from-disk and running into use of internal package github.com/pion/webrtc/v4/examples/internal/signal not allowed). I'm trying to figure out how to implement a live stream server that uses WebRTC as the transport and I'm not sure where to start and can't make any changes to the examples to tinker with things. As a new user of this library, that's first major thing I ran into. EDIT: seems like that signal package is very small and simple and easy to copy out - makes me wonder what the intent of making it internal was...

[Sean-Der]

Thanks for the feedback @bradleypeabody !

That exists so we can have shared code in the examples, but not have it a public API

I am going to undo that. The examples will be more verbose, but you don’t have to deal with internal problems.

does that sound like a good idea/would have been a better experience

[bradleypeabody]

Thanks @Sean-Der and great. As another suggestion, renaming the "examples/internal" to be something like "examples/exampleutil" would be an easy fix, solve the problem, and also help communicate the concept that the signaling code there is just for examples and intended to be re-implemented according to each application's needs.

[Sean-Der]

@bradleypeabody I just merged the change! When you get a chance mind checking it out? See if that was a experience you would prefer

[bradleypeabody]

@Sean-Der Yeah, it looks great now, thanks! Definitely more new-user-friendly :)