Calls: Update API diagram to Mermaid and Improve DataChannel page

src/content/docs/calls/datachannels.mdx

@@ -3,10 +3,32 @@ pcx_content_type: get-started
 title: DataChannels
 sidebar:
   order: 8
-
 ---
 
-Since Cloudflare Calls is basically a pub/sub server for WebRTC that can scale up to many subscribers per publisher, it's fit for arbitrary data besides media too.
+DataChannels are a way to send arbitrary data, not just audio or video data, between client in low latency. DataChannels are useful for scenarios like chat, game state, or any other data that doesn't need to be encoded as audio or video but still needs to be sent between clients in real time.
+
+While it is possible to send audio and video over DataChannels, it's not optimal because audio and video transfer includes media specific optimizations that DataChannels do not have, such as simulcast, forward error correction, better caching across the Cloudflare network for retransmissions.
+
+```mermaid
+graph LR
+    A[Publisher] -->|Arbitrary data| B[Cloudflare Calls SFU]
+    B -->|Arbitrary data| C@{ shape: procs, label: "Subscribers"}
+```
+
+DataChannels on Cloudflare Calls can scale up to many subscribers per publisher, there is no limit to the number of subscribers per publisher.
+
+### How to use DataChannels
+
+1. Create a two Calls sessions, one for the publisher and one for the subscribers.
+2. Create a DataChannel by calling /datachannels/new with the location set to "local" and the dataChannelName set to the name of the DataChannel.
+3. Create a DataChannel by calling /datachannels/new with the location set to "remote" and the sessionId set to the sessionId of the publisher.
+4. Use the DataChannel to send data from the publisher to the subscribers.
+
+### Unidirectional DataChannels
+
+Cloudflare Calls SFU DataChannels are one way only. This means that you can only send data from the publisher to the subscribers. Subscribers cannot send data back to the publisher. While regular MediaStream WebRTC DataChannels are bidirectional, this introduces a problem for Cloudflare Calls because the SFU does not know which session to send the data back to. This is especially problematic for scenarios where you have multiple subscribers and you want to send data from the publisher to all subscribers at scale, such as distributing game score updates to all players in a multiplayer game.
+
+To send data in a bidirectional way, you can use two DataChannels, one for sending data from the publisher to the subscribers and one for sending data the opposite direction.
 
 ## Example
 

src/content/docs/calls/https-api.mdx

@@ -3,23 +3,22 @@ pcx_content_type: get-started
 title: Connection API
 sidebar:
   order: 5
-
 ---
 
 Cloudflare Calls simplifies the management of peer connections and media tracks through HTTPS API endpoints. These endpoints allow developers to efficiently manage sessions, add or remove tracks, and gather session information.
 
 ## API Endpoints
 
-* **Create a New Session**: Initiates a new session on Cloudflare Calls, which can be modified with other endpoints below.
-  * `POST /apps/{appId}/sessions/new`
-* **Add a New Track**: Adds a media track (audio or video) to an existing session.
-  * `POST /apps/{appId}/sessions/{sessionId}/tracks/new`
-* **Renegotiate a Session**: Updates the session's negotiation state to accommodate new tracks or changes in the existing ones.
-  * `PUT /apps/{appId}/sessions/{sessionId}/renegotiate`
-* **Close a Track**: Removes a specified track from the session.
-  * `PUT /apps/{appId}/sessions/{sessionId}/tracks/close`
-* **Retrieve Session Information**: Fetches detailed information about a specific session.
-  * `GET /apps/{appId}/sessions/{sessionId}`
+- **Create a New Session**: Initiates a new session on Cloudflare Calls, which can be modified with other endpoints below.
+  - `POST /apps/{appId}/sessions/new`
+- **Add a New Track**: Adds a media track (audio or video) to an existing session.
+  - `POST /apps/{appId}/sessions/{sessionId}/tracks/new`
+- **Renegotiate a Session**: Updates the session's negotiation state to accommodate new tracks or changes in the existing ones.
+  - `PUT /apps/{appId}/sessions/{sessionId}/renegotiate`
+- **Close a Track**: Removes a specified track from the session.
+  - `PUT /apps/{appId}/sessions/{sessionId}/tracks/close`
+- **Retrieve Session Information**: Fetches detailed information about a specific session.
+  - `GET /apps/{appId}/sessions/{sessionId}`
 
 [View full API and schema (OpenAPI format)](/calls/static/calls-api-2024-05-21.yaml)
 
@@ -31,24 +30,62 @@ It is vital to manage App ID and its secret securely. While track and session ID
 
 Cloudflare Calls is designed to operate efficiently without the need for TURN servers in most scenarios, as Cloudflare exposes a publicly routable IP address for Calls. However, integrating a STUN server can be necessary for facilitating peer discovery and connectivity.
 
-* **Cloudflare STUN Server**: `stun.cloudflare.com:3478`
+- **Cloudflare STUN Server**: `stun.cloudflare.com:3478`
 
 Utilizing Cloudflare's STUN server can help the connection process for Calls applications.
 
 ## Lifecycle of a Simple Session
 
 This section provides an overview of the typical lifecycle of a simple session, focusing on audio-only applications. It illustrates how clients are notified by the backend server as new remote clients join or leave, incorporating video would introduce additional tracks and considerations into the session.
 
-<div class="full-img">
+```mermaid
+sequenceDiagram
+    participant WA as WebRTC Agent
+    participant BS as Backend Server
+    participant CA as Calls API
+
+    Note over BS: Client Joins
+
+    WA->>BS: Request
+    BS->>CA: POST /sessions/new
+    CA->>BS: newSessionResponse
+    BS->>WA: Response
+
+    WA->>BS: Request
+    BS->>CA: POST /sessions/<ID>/tracks/new (Offer)
+    CA->>BS: newTracksResponse (Answer)
+    BS->>WA: Response
+
+    WA-->>CA: ICE Connectivity Check
+    Note over WA: iceconnectionstatechange (connected)
+    WA-->>CA: DTLS Handshake
+    Note over WA: connectionstatechange (connected)
+
+    WA<<->>CA: *Media Flow*
+
+    Note over BS: Remote Client Joins
 
-![Example Lifecycle](~/assets/images/calls/lifecycle-of-a-session.png)
+    WA->>BS: Request
+    BS->>CA: POST /sessions/<ID>/tracks/new
+    CA->>BS: newTracksResponse (Offer)
+    BS->>WA: Response
 
-</div>
+    WA->>BS: Request
+    BS->>CA: PUT /sessions/<ID>/renegotiate (Answer)
+    CA->>BS: OK
+    BS->>WA: Response
 
-There is also a previously used, but now deprecated way to use the API illustrated below. If you are using this style please consider upgrading to the newer version illustrated above.
+    Note over BS: Remote Client Leaves
 
-<div class="full-img">
+    WA->>BS: Request
+    BS->>CA: PUT /sessions/<ID>/tracks/close
+    CA->>BS: closeTracksResponse
+    BS->>WA: Response
 
-![Deprecated Lifecycle](~/assets/images/calls/deprecated-lifecycle-of-a-session.png)
+    Note over BS: Client Leaves
 
-</div>
+    WA->>BS: Request
+    BS->>CA: PUT /sessions/<ID>/tracks/close
+    CA->>BS: closeTracksResponse
+    BS->>WA: Response
+```