diff --git a/webrtc-explained.md b/webrtc-explained.md
index 93bb4844a..7c47bef5e 100644
--- a/webrtc-explained.md
+++ b/webrtc-explained.md
@@ -64,10 +64,10 @@ Protocol used by WebRTC Data Channels.
 
 Provides:
 - multiple streams
-- partial reliability
+- configurable reliability
 - no head-of-line blocking
 
-Runs inside DTLS.
+Runs inside DTLS. Can be configured to be TCP-like or UDP-like or anything in between.  
 
 ## DTLS (Datagram TLS)
 TLS over UDP.
@@ -78,6 +78,8 @@ Used for:
 - securing SCTP
 - securing SRTP
 
+DTLS does not typically go through CA Root Verification in WebRTC; it is verified in the signalling phase using the key fingerprint. 
+
 ## mDNS
 Masks local LAN IP addresses for privacy (e.g. *.local hostnames).
 
@@ -126,3 +128,13 @@ Commonly includes:
 - timers
 - UUID helpers
 
+
+## Interoperability 
+Check [WebRTC interoperability tests](https://github.com/sipsorcery/webrtc-interop) for samples in other WebRTC libraries like libwebrtc, pion, SipSorcery and whether they can interoperate with each other. 
+
+## Extras
+### Selective Forwarding Unit (SFU)
+This is not peer-to-peer WebRTC; a central server manages the media streams. This is how certain "mute" functions or noise detection is implemented in multiuser video conferencing. Used to restrict audio/video flow from users, due to administrative controls or due to being "idle" in a video/audio call.  
+
+### Multipoint Control Unit (MCU)
+This is an alternate architecture to the above, still not peer to peer but the central server itself takes the responsibility to mix/re-encode the streams.  
diff --git a/webrtc-signaling-explained.md b/webrtc-signaling-explained.md
index b66d28e36..b9d4f745a 100644
--- a/webrtc-signaling-explained.md
+++ b/webrtc-signaling-explained.md
@@ -16,7 +16,7 @@ This includes exchanging:
 WebRTC peers cannot discover each other on their own.
 
 They need to:
-- agree on codecs and media setup
+- agree on codecs, media and datachannel setup
 - share network information
 - exchange security fingerprints
 
@@ -75,7 +75,7 @@ Contain:
 6. Peer B sends Answer back via signaling channel
 7. Both sides exchange ICE Candidates
 8. ICE finds a working route
-9. Peers connect directly
+9. Peers connect directly (or through a TURN relay, but still end-to-end encrypted)
 
 
 ## Signaling Server Responsibilities
@@ -95,7 +95,7 @@ It does *not*:
 
 Once the WebRTC connection is established:
 - the signaling server is no longer required
-- peers communicate directly (unless TURN is used)
+- peers communicate directly (unless TURN is used when the peers are behind restrictive NAT)
 
 
 ## Simplified Diagram