More Architecture

Architecture-WebRTC.md

@@ -6,7 +6,7 @@ We also will explain why certain design decisions were made. Some of our designs
 made with incorrect assumptions. These could serve as good projects for modernization
 of the code base.
 
-## Components that make up the PeerConnection
+## Exploring 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
@@ -21,7 +21,9 @@ pion/ice <----> pion/webrtc <--> github.com/pion/webrtc/internal/mux
 
 ```
 
-`pion/ice` implements [RFC 8445](https://tools.ietf.org/html/rfc8445). This is where all network traffic flows through.
+### Receiving Data
+
+`pion/ice` implements [RFC 8445](https://tools.ietf.org/html/rfc8445). This is where all network traffic arrives.
 
 `pion/webrtc` gets all dtls and srtp traffic in one stream, and is in charge of demuxing it. [muxfunc](https://github.com/pion/webrtc/blob/master/internal/mux/muxfunc.go#L32)
 inspects each packet that flows through the system and routes it as needed. We later can create handlers and route into specific components.
@@ -39,7 +41,30 @@ The handling of media streams is broken into two parts. We have explicit media s
 For each SSRC we explicitly request the stream [srtpSession.OpenReadStream](https://github.com/pion/webrtc/blob/master/rtpreceiver.go#L299). Later we added support for Simulcast where the SSRCes aren't known ahead of time. This is done in
 [handleUndeclaredSSRC](https://github.com/pion/webrtc/blob/master/peerconnection.go#L1303) where each new SSRC emits a callback. **Having these two code paths is a good candidate for refactoring**
 
+### Sending Data
+`pion/datachannel` wraps a `sctp.Client` and encodes the messages properly to send. You can see data enter this package in [Send](https://github.com/pion/webrtc/blob/master/datachannel.go#L353). From here
+[WriteDataChannel](https://github.com/pion/datachannel/blob/master/datachannel.go#L254) encodes and sends into the SCTP subsystem. The SCTP subsystem has a direct route out `pion/dtls -> pion/ice` as explained above.
+
+`pion/srtp` allows you to open a [WriteStreamSRTP](https://github.com/pion/webrtc/blob/master/srtp_writer_future.go#L53). These are opened on the SRTP/SRTCP session objects in the `DTLSTransport`.
+
+
 ## FAQ
 
 ### RTCP/RTCP pipeline and pion/interceptor
+A Interceptor is a pluggable RTP/RTCP processor. Via a public API users can easily add and customize operations that are run on inbound/outbound RTP.
+Interceptors are an interface this means A user could provide their own implementation. Or you can use one of the interceptors Pion will have in-tree.
+You define an interceptor per SSRC, and you have the following [methods](https://github.com/pion/interceptor/blob/master/interceptor.go#L16-L36) you can define.
+
 ### What is packetio.Buffer, why do we need it?
+Inside `pion/ice` and `pion/srtp` we have these buffers. These buffers give us the following behaviors.
+
+##### They allow packets to be processed out of order and ignore streams
+Today a user can ignore a `OnTrack` callback and the packets if they want. This is because we provide a buffer for each `RTP` and `RTCP` stream.
+If we only had one buffer a user would have to accept buffer 0 before they could buffer 1 and 2. Even if they didn't want buffer 0.
+
+##### It allows fast reading from the network
+If the user had code that was slow it could block the network. We want a really fast `Read` from the UDP socket into a buffer. The user then can pull
+from that buffer later.
+
+##### It allows users to control buffering rules easily
+The buffers can be size or count based. It is important that users who care about performance have access to all of these things.