Revitalizing Pion development

[Sean-Der]

Pion development in the last year has slowed down. I spent most
of time working on WebRTC in OBS[0] and libdatachannel[1] to support
it. Now that these things are in a more stable spot I am excited to do
more great things with Pion.

I have some goals and things I want to improve. I would love to hear from
others as well. Contributors, users or even outside observers. I always love
hearing new voices.

What can be better/what should we not lose?

Better Communication

I feel overwhelmed with direct communication. Many talented and motivated
people are trying to contribute and build with Pion. I want to respond and
work with everyone. I have so many messages across different platforms I can't
keep up anymore.

Going forward I would like to have all conversations in the Pion Slack.
If you @ Sean-Der I would love to discuss in the #pion channel. Others in the project
are active in the channel. It will let others get involved and make the community
more vibrant.

It is also possible that Slack isn't the best place for Pion discussions. We could
investigate alternatives like Discourse?

Support big contributions

Pion has some great improvements being worked on.

• Dynamic JitterBuffer - A JitterBuffer that adapts to the network. Instead of setting
  a static wait period it will evaluate the network conditions. By @thatsnotright

• SFU Congestion Control - Pion has a GCC algorithm thanks to @mengelbart. This works well
  for clients. However has shortcomings with servers. @aalekseevx is working on a Congestion
  Control algorithm and implementation that is designed for forwarding a collection of pre-encoded
  streams.

• FlexFEC - This would allow users to have the lowest latency streams possible, even in lossy networks.
  Pion could send/receive media with redundancy so even if packet loss was encountered it
  wouldn't cause a drop in media quality. @pougetat is the author.

• SCTP - SCTP is the technology that powers WebRTC's Datachannel. @enobufs has a lot of great improvements
  he is trying to land. Things like RACK. He also has other interesting projects like making
  Pion a monorepo to reduce the developer/user pain.

I have noticed that all these projects have hit road bumps because I haven't supported them enough.
Sometimes I have a lack of enthusiasm because of distrations, and other times I am slow to merge.
I am hoping to move conversations about these projects to the Pion Slack. Hopefully if these projects
get more visibility maybe others can get involved, or at least get quicker approvals and feedback!

Issues/PRs to 0

The numbers of issues/PRs has really grown lately. I am sorry to everyone that has taken the time to report issues
and contribute code. I will make sure your time wasn't wasted!

Personally I will work across all the repos on this. If anyone is interested in getting involved I would
really appreciate the help! I would like to make sure we treat every issue with respect. No auto-closing or
short responses. Take our time to understanding and explain the issue no matter what.

Support all of WebRTC

So many unique problems get solved with WebRTC. This flexbility is why I continue
to work with WebRTC. You can use it across so many different platforms and languages.

We should continue to make Pion the best it can be, but recommend alternatives when
they make sense. We should continue to recommend alternatives like aiortc,
webrtc-rs, str0m, libdatachannel etc... If a user is building something better served by a
SFU we should recommend one.

Pion is not about making the best 'Go WebRTC'. It is about making WebRTC as accessible
as possible. I encourage as much off-topic conversation in Pion communities as long as
it is helping people.

---

Concrete things I would like to accomplish in the next 4 months.

• Resolve all actionable issues/PRs
• Release pion/dtls@v3
• Release pion/webrtc@v4
• Merge all the 'Big Contributions' mentioned in the PR

[0] https://github.com/obsproject/obs-studio
[1] https://github.com/paullouisageneau/libdatachannel

[Sean-Der]

@enobufs @at-wat @stv0g @edaniels @hasheddan @daenney

Any other shortcomings/things you would like to see improved with Pion?

[edaniels]

FWIW, I think pion is great. The shortcoming that I think I faced the most with it at my last job was around performance of data channels. There was a lot of headache around debugging and finding out that the issue was around SCTP backpressure in a way that one wouldn't expect with an OS controlled TCP stack. Personally that's an area I'd both like to see be worked on and that I'd be willing to contribute time and code to!

[daenney]

My main involvement has always been DTLS and not even from a WebRTC point of view but from the IoT world. For me, the library just kinda works and it does what I need from it. But there's probably a bunch of things we could improve, and add DTLS 1.3 support, for folks using it in other contexts. It's proven incredibly useful for a lot of random experiments I've done to have a non-CGO DTLS option. I'm sure there's also plenty we can do to make it easier for the WebRTC use cases.

I'm happy to help shepherd small PRs through, but since I can't make a living from working on open source things, the time I have to spend on it is going to continue to be very limited. So unfortunately my availability to help with these things is going to ebb and flow a lot based on whatever else is going on.

[stv0g]

Two topics, I think we can and should improve are:

• IPv6 support
• TCP candidates

Both for srflx and relay candidates.

[enobufs]

I'd also like to see all the Pion modules truly pluggable using interfaces. This will give us more flexibility in swapping layers, mocking, new feature development. Here's a sketch of what I have in mind:

classDiagram
    `webrtc.API` --> `webrtc.CustomFactories` : newXxx()
    `webrtc.API` --> `webrtc.CustomFactories` : Replace factory
    `webrtc.CustomFactories` --> `ice.Agent` : &lt&ltcreate&gt&gt
    `ice.Agent` --> `ice.Conn` : &lt&ltcreate&gt&gt
    `webrtc.CustomFactories` --> `dtls.StreamRTP` : &lt&ltcreate&gt&gt
    `dtls.StreamRTP` --> `dtls.ReadStreamRTP` : &lt&ltcreate&gt&gt
    `dtls.StreamRTP` --> `dtls.WriteStreamRTP` : &lt&ltcreate&gt&gt
    `dtls.StreamRTCP` --> `dtls.ReadStreamRTCP` : &lt&ltcreate&gt&gt
    `dtls.StreamRTCP` --> `dtls.WriteStreamRTCP` : &lt&ltcreate&gt&gt
    `webrtc.CustomFactories` --> `dtls.StreamRTCP` : &lt&ltcreate&gt&gt
    `webrtc.CustomFactories` --> `sctp.Association` : &lt&ltcreate&gt&gt
    `sctp.Association` --> `sctp.Stream` : &lt&ltcreate&gt&gt
    `webrtc.CustomFactories` --> `datachannel.DataChannel` : &lt&ltcreate&gt&gt
    <<interface>>`ice.Agent`
    <<interface>>`ice.Conn`
    <<interface>>`dtls.StreamRTP`
    <<interface>>`dtls.ReadStreamRTP`
    <<interface>>`dtls.WriteStreamRTP`
    <<interface>>`dtls.StreamRTCP`
    <<interface>>`dtls.ReadStreamRTCP`
    <<interface>>`dtls.WriteStreamRTCP`
    <<interface>>`sctp.Association`
    <<interface>>`sctp.Stream`
    <<interface>>`datachannel.DataChannel`