Architecture WebRTC

The Architecture of Pion WebRTC

This document describes in the details the architecture of Pion WebRTC. It shows how data flows through the system and points of importance in the code base.

We also will explain why certain design decisions were made. Some of our designs were made with incorrect assumptions. These could serve as good projects for modernization of the code base.

Components that make up the PeerConnection

At a highlevel the components that make up a PeerConnection look like this. At the far left you have public APIs and how data flows to/from them.

                                                                   <---> pion/srtp ---> OnTrack
                                                                   |         ^
                                                                   |         | --------- AddTrack
pion/ice <----> pion/webrtc <--> github.com/pion/webrtc/internal/mux
                                                                   |
                                                                   <---> pion/dtls <--> pion/sctp -> OnDataChannel
                                                                                             ^
                                                                                             |---- CreateDataChannel

pion/ice implements RFC 8445. This is where all network traffic flows through.

pion/webrtc gets all dtls and srtp traffic in one stream, and is in charge of demuxing it. muxfunc inspects each packet that flows through the system and routes it as needed. We later can create handlers and route into specific components.

pion/srtp encrypts/decrypts all media traffic. a muxfunc is created in the DTLSTransport. This muxfunc then passes all media into a srtp.SessionSRTP or srtp.SessionSRTCP. pion/webrtc later will later interact with these sessions.

pion/dtls encrypts/decrypts all encrypted data traffic. a muxfunc is created in the DTLSTransport. This muxfunc then passes all data into pion/dtls.

pion/sctp then handles all decrypted data traffic. dtls.Conn that was created is passed into the sctp.Client. We then call acceptDataChannels and a callback is fired everytime a new SCTP stream is seen. A STCP stream is created for every new DataChannel.

The handling of media streams is broken into two parts. We have explicit media streams for SSRCes that are declared in the Offer/Answer. Those are handled in startRTPReceivers. For each SSRC we explicitly request the stream srtpSession.OpenReadStream. Later we added support for Simulcast where the SSRCes aren't known ahead of time. This is done in handleUndeclaredSSRC where each new SSRC emits a callback. Having these two code paths is a good candidate for refactoring

FAQ

RTCP/RTCP pipeline and pion/interceptor

What is packetio.Buffer, why do we need it?