|
12 | 12 | //! [WebRTC for the Curious](https://webrtcforthecurious.com/) book is a free |
13 | 13 | //! resource that provides a great introduction to the topic. |
14 | 14 | //! |
15 | | -//! ## Features |
| 15 | +//! # Features |
16 | 16 | //! |
17 | 17 | //! - Connections to remote peers using NAT-traversal technologies (STUN, TURN, and ICE) |
18 | 18 | //! - Streaming of audio and video media via RTP and RTCP |
|
22 | 22 | //! - Support for Multicast DNS (mDNS) |
23 | 23 | //! - Interceptors for RTP, RTCP, and DataChannel packets |
24 | 24 | //! |
25 | | -//! ## Key Concepts |
| 25 | +//! # Key Concepts |
26 | 26 | //! |
27 | 27 | //! The WebRTC API, as defined by the W3C specification, is composed of a number of |
28 | 28 | //! constructs and interfaces that provide a rich set of functionality, including |
|
36 | 36 | //! The following section provides a brief overview of the key concepts and constructs |
37 | 37 | //! that are used throughout the WebRTC API. |
38 | 38 | //! |
39 | | -//! ### RTCConfiguration |
| 39 | +//! ### Configuration |
40 | 40 | //! |
41 | 41 | //! The [`RTCConfiguration`] struct defines the set of parameters that are used to configure |
42 | 42 | //! how peer-to-peer communication via [`RTCPeerConnection`] is established or re-established. |
|
46 | 46 | //! Configurations may be reused across multiple [`RTCPeerConnection`]s, and are treated as read-only |
47 | 47 | //! once constructed. |
48 | 48 | //! |
49 | | -//! ### RTCPeerConnection |
| 49 | +//! ### Peer Connections |
50 | 50 | //! |
51 | 51 | //! The [`RTCPeerConnection`] is the primary entry point to the WebRTC API. It represents an |
52 | 52 | //! individual connection between a local device and a remote peer. |
|
66 | 66 | //! passing a FnMut closure that accepts the corresponding enum type and returns a |
67 | 67 | //! `Pin<Box<dyn Future<Output = ()> + Send + 'static>` future to be awaited. |
68 | 68 | //! |
69 | | -//! #### Sync vs. Async |
| 69 | +//! ### Event Handling |
70 | 70 | //! |
71 | 71 | //! For clarity, the event handler methods run synchronously and accept a (synchronous) closure |
72 | 72 | //! that returns a future. Any async work that you need to do as part of an event handler should |
|
80 | 80 | //! |
81 | 81 | //! **This will be a common source of confusion for new users of the crate.** |
82 | 82 | //! |
83 | | -//! #### Session Descriptions |
| 83 | +//! ### Session Descriptions |
84 | 84 | //! |
85 | 85 | //! In the WebRTC protocol, session descriptions serve as the mechanism for exchanging |
86 | 86 | //! information about media capabilities, network addresses, and other metadata between |
|
95 | 95 | //! ([Session Description Protocol](https://en.wikipedia.org/wiki/Session_Description_Protocol)) |
96 | 96 | //! documents. |
97 | 97 | //! |
98 | | -//! #### Signaling |
| 98 | +//! ### Signaling |
99 | 99 | //! |
100 | 100 | //! In order to establish a connection, both peers must exchange their session descriptions |
101 | 101 | //! with each other. The process of exchanging of session descriptions between peers is |
|
136 | 136 | //! As signaling is an application-specific concern, this crate does not provide any |
137 | 137 | //! built-in signaling functionality or guidance on how to implement. |
138 | 138 | //! |
| 139 | +//! ### ICE Agent |
| 140 | +//! |
| 141 | +//! The [`Agent`](ice::agent::Agent) struct implements the ICE ([Interactive Connectivity Establishment](https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment)) |
| 142 | +//! protocol, which is used to gather local ICE candidates, as well as manage the state of the |
| 143 | +//! ICE transport for a given peer connection. |
| 144 | +//! |
| 145 | +//! ICE agent's configuration parameters are defined by the [`RTCConfiguration`] struct. |
| 146 | +//! |
| 147 | +//! Certain [`RTCPeerConnection`] methods interact with the ICE agent, including: |
| 148 | +//! |
| 149 | +//! - [`add_ice_candidate()`](crate::peer_connection::RTCPeerConnection::add_ice_candidate) |
| 150 | +//! - [`set_local_description()`](crate::peer_connection::RTCPeerConnection::set_local_description) |
| 151 | +//! - [`set_remote_description()`](crate::peer_connection::RTCPeerConnection::set_remote_description) |
| 152 | +//! - [`close()`](crate::peer_connection::RTCPeerConnection::close) |
| 153 | +//! |
| 154 | +//! These interactions are described in [RFC8829](https://tools.ietf.org/html/rfc8829). The ICE |
| 155 | +//! agency also provides indications when the state of an ICE transport changes via the event |
| 156 | +//! handler methods that are available within [`RTCPeerConnection`]. |
| 157 | +//! |
139 | 158 | //! ### MediaStream |
140 | 159 | //! |
141 | 160 | //! ### DataChannel |
|
144 | 163 | //! |
145 | 164 | //! ### RTCSessionDescription |
146 | 165 | //! |
147 | | -//! ## Examples |
| 166 | +//! # Examples |
148 | 167 | //! |
149 | 168 | //! The `examples/` directory contains a range of examples, from basic peer connections to |
150 | 169 | //! advanced data channel usage. |
151 | 170 | //! |
152 | | -//! ## Compatibility |
| 171 | +//! # Compatibility |
153 | 172 | //! |
154 | 173 | //! This crate aims to stay up-to-date with the latest W3C WebRTC specification. However, |
155 | 174 | //! as WebRTC is a rapidly evolving standard, there might be minor discrepancies. Always |
156 | 175 | //! refer to the official W3C WebRTC specification for authoritative information. |
157 | 176 | //! |
158 | | -//! ## License |
| 177 | +//! # License |
159 | 178 | //! |
160 | 179 | //! This project is licensed under either of the following, at your option: |
161 | 180 | //! - [Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0) |
|
0 commit comments