{"@attributes":{"version":"2.0"},"channel":{"title":"Introduction on WebRTC for the Curious","link":"https:\/\/webrtcforthecurious.com\/","description":"Recent content in Introduction on WebRTC for the Curious","generator":"Hugo","language":"en","item":[{"title":"What, Why and How","link":"https:\/\/webrtcforthecurious.com\/docs\/01-what-why-and-how\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/01-what-why-and-how\/","description":"What, Why and How # What is WebRTC? # WebRTC, short for Web Real-Time Communication, is both an API and a Protocol. The WebRTC protocol is a set of rules for two WebRTC agents to negotiate bi-directional secure real-time communication. The WebRTC API then allows developers to use the WebRTC protocol. The WebRTC API is specified only for JavaScript.\nA similar relationship would be the one between HTTP and the Fetch API."},{"title":"Signaling","link":"https:\/\/webrtcforthecurious.com\/docs\/02-signaling\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/02-signaling\/","description":"Signaling # What is WebRTC Signaling? # When you create a WebRTC agent, it knows nothing about the other peer. It has no idea who it is going to connect with or what they are going to send! Signaling is the initial bootstrapping that makes a call possible. After these values are exchanged, the WebRTC agents can communicate directly with each other.\nSignaling messages are just text. The WebRTC agents don’t care how they are transported."},{"title":"Connecting","link":"https:\/\/webrtcforthecurious.com\/docs\/03-connecting\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/03-connecting\/","description":"Connecting # Why does WebRTC need a dedicated subsystem for connecting? # Most applications deployed today establish client\/server connections. A client\/server connection requires the server to have a stable well-known transport address. A client contacts a server, and the server responds.\nWebRTC doesn’t use a client\/server model, it establishes peer-to-peer (P2P) connections. In a P2P connection the task of creating a connection is equally distributed to both peers. This is because a transport address (IP and port) in WebRTC can not be assumed, and may even change during the session."},{"title":"Securing","link":"https:\/\/webrtcforthecurious.com\/docs\/04-securing\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/04-securing\/","description":"Securing # What security does WebRTC have? # Every WebRTC connection is authenticated and encrypted. You can be confident that a 3rd party can’t see what you are sending or insert bogus messages. You can also be sure that the WebRTC Agent that generated the Session Description is the one you are communicating with.\nIt is very important that no one tampers with those messages. It is ok if a 3rd party reads the Session Description in transit."},{"title":"Real-time Networking","link":"https:\/\/webrtcforthecurious.com\/docs\/05-real-time-networking\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/05-real-time-networking\/","description":"Real-time Networking # Why is networking so important in Real-time communication? # Networks are the limiting factor in Real-time communication. In an ideal world we would have unlimited bandwidth and packets would arrive instantaneously. This isn’t the case though. Networks are limited, and the conditions could change at anytime. Measuring and observing network conditions is also a difficult problem. You can get different behaviors depending on hardware, software and the configuration of it."},{"title":"Media Communication","link":"https:\/\/webrtcforthecurious.com\/docs\/06-media-communication\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/06-media-communication\/","description":"Media Communication # What do I get from WebRTC’s media communication? # WebRTC allows you to send and receive an unlimited amount of audio and video streams. You can add and remove these streams at anytime during a call. These streams could all be independent, or they could be bundled together! You could send a video feed of your desktop, and then include audio and video from your webcam."},{"title":"Data Communication","link":"https:\/\/webrtcforthecurious.com\/docs\/07-data-communication\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/07-data-communication\/","description":"Data Communication # What do I get from WebRTC’s data communication? # WebRTC provides data channels for data communication. Between two peers you can open 65,534 data channels. A data channel is datagram based, and each has its own durability settings. By default, each data channel has guaranteed ordered delivery.\nIf you are approaching WebRTC from a media background data channels might seem wasteful. Why do I need this whole subsystem when I could just use HTTP or WebSockets?"},{"title":"Applied WebRTC","link":"https:\/\/webrtcforthecurious.com\/docs\/08-applied-webrtc\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/08-applied-webrtc\/","description":"Applied WebRTC # Now that you know how WebRTC works it is time to build with it! This chapter explores what people are building with WebRTC, and how they are building it. You will learn all the interesting things that are happening with WebRTC. The power of WebRTC comes at a cost. Building production grade WebRTC services is challenging. This chapter will try to explain those challenges before you hit them."},{"title":"Debugging","link":"https:\/\/webrtcforthecurious.com\/docs\/09-debugging\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/09-debugging\/","description":"Debugging # Debugging WebRTC can be a daunting task. There are a lot of moving parts, and they all can break independently. If you aren’t careful, you can lose weeks of time looking at the wrong things. When you do finally find the part that is broken, you will need to learn a bit to understand why.\nThis chapter will get you in the mindset to debug WebRTC. It will show you how to break down the problem."},{"title":"History","link":"https:\/\/webrtcforthecurious.com\/docs\/10-history-of-webrtc\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/10-history-of-webrtc\/","description":"History # When learning WebRTC developers often feel frustrated by the complexity. They see WebRTC features irrelevant to their current project and wish WebRTC was simpler. The issue is that everyone has a different set of use cases. Real-time communications has a rich history with lots of different people building many different things.\nThis chapter contains interviews with the authors of the protocols that make up WebRTC. It gives insight into the designs made when building each protocol, and finishes with an interview about WebRTC itself."},{"title":"FAQ","link":"https:\/\/webrtcforthecurious.com\/docs\/11-faq\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/11-faq\/","description":"FAQ # Why does WebRTC use UDP? NAT Traversal requires UDP. Without NAT Traversal establishing a P2P connection wouldn’t be possible. UDP doesn’t provide “guaranteed delivery” like TCP, so WebRTC provides it at the user level.\nSee Connecting for more info.\nHow many DataChannels can I have? 65534 channels as stream identifier has 16 bits. You can close and open a new one at any time. Does WebRTC impose bandwidth limits?"},{"title":"Glossary","link":"https:\/\/webrtcforthecurious.com\/docs\/12-glossary\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/12-glossary\/","description":"Glossary # ACK: Acknowledgment AVP: Audio and Video profile B-Frame: Bi-directional Predicted Frame. A partial picture, is a modification of previous and future pictures. DCEP: Data Channel Establishment Protocol defined in RFC 8832 DeMux: Demultiplexer DLSR: Delay since last sender report DTLS: Datagram Transport Layer Security defined in RFC 6347 E2E: End-to-End FEC: Forward Error Correction FIR: Full INTRA-frame Request G.711: A narrowband audio codec GCC: Google Congestion Control defined in draft-ietf-rmcat-gcc-02 H."},{"title":"Reference","link":"https:\/\/webrtcforthecurious.com\/docs\/13-reference\/","pubDate":"Mon, 01 Jan 0001 00:00:00 +0000","guid":"https:\/\/webrtcforthecurious.com\/docs\/13-reference\/","description":"Reference # WebRTC(W3C) # WebRTC 1.0: Real-Time Communication Between Browsers [26 January 2021] (Status: Recommendation) Web Real-Time Communications Working Group - Publications WebRTC(RFC) # RFC8825: Overview: Real-Time Protocols for Browser-Based Applications H. Alvestrand [January 2021] (Status: PROPOSED STANDARD) RFC8826: Security Considerations for WebRTC E. Rescorla [January 2021] (Status: PROPOSED STANDARD) RFC8836: Congestion Control Requirements for Interactive Real-Time Media R. Jesup, Z. Sarker [January 2021] (Status: INFORMATIONAL) RFC8854: WebRTC Forward Error Correction Requirements J."}]}}