Update cascading doc format

Author: qwu16

doc/design/quic-cascading.md

@@ -11,7 +11,7 @@ With this deployment, Rabbitmq will be in the cloud and other region-based modul
 With this deployment, each region will deploy a separate OWT cluster. It’s easier for large deployment and the internal OWT cluster will work independently when region network disconnects with cloud. Here is a comparison for these 2 deployments:
 ![comparison](./pics/cascading/comparison.png) 
 
-We will concentrate on OWT cascading design here.
+We will focus on OWT cascading design here.
 
 ## Cloud Management service
 
@@ -20,8 +20,12 @@ Cloud management service is deployed in a cloud for central management, it shoul
   - Accept client request and assign OWT cluster to client
   -	Record conference info and trigger OWT cluster cascading
   - Maintain OWT cluster info and conference info
-1 OWT cluster register
+
+### OWT cluster register
+
 OWT will register cluster info to cloud management service when the cluster is launched. This cluster registration work will be done in clusterManager. clusterManager will send the register requests to cloud after it gets service key/id info from management_api
+
+```
   object(clusterInfo) {
     id:  string,                               // name of the OWT cluster
     region: string,                       // region of the OWT cluster
@@ -32,36 +36,62 @@ OWT will register cluster info to cloud management service when the cluster is l
     mediabridgeip: string,          // OWT media bridge listener ip
     mediabridgeport: string       //OWT media bridge listener port
   }
+```
+
 OWT cluster manager will update capacity info to cloud if a new purpose agent joins the cluster or no such purpose agent lives in the cluster.
+
+```
   Object (capacityinfo) {
     action: string,        //actions: add, delete
     module: string      //OWT modules: webrtc, streaming, video, audio… 
   }
+```
+
 OWT cluster manager will report room token to cloud for event/media bridge QUIC server to validate QUIC client connection. The token will be generated when room is initialized.
+
+```
   object (tokeninfo) {
     room: string                     // conference room id
     token: string                    // conference room token
   }
-2 Handle client request
+```
+
+### Handle client request
+
 Client will send a join conference request to cloud management service:
 Request body:
-type	content
-json	conferenceInfo
+
+type       | content
+-------------|-----
+json       | conferenceInfo
+
+```
   object(conferenceInfo) {
     id: conferenceId,
     type: conferenceType
   }
+```
+
 Response body:
-type	content
-json	clusterInfo
+
+type       | content
+-------------|-----
+json       | clusterInfo
+
+```
   object(clusterInfo) {
     ip: ip,   //OWT cluster web server ip
     port: port, //OWT cluster web server port
     room:  roomId   //OWT cluster room id
   }
-3 Create room request
+```
+
+### Create room request
+
 Cloud management service will check saved conference info list to see if room has been created for this conference id in the owt cluster, if not, cloud management service will send create room request to owt cluster with room configuration according to client conference type, owt cluster will response with created room info. 
 Users can define several conference templates which includes different room configurations, such as publication limit, SFU only. etc, so client can join specific kinds of room by specifying conference type. If no conference type is specified, then client will be assigned with the default room configuration template.
+
+```
   object(conference) {
     id: conferenceId,
     cluster: [object(cluster)]
@@ -70,7 +100,10 @@ Users can define several conference templates which includes different room conf
     id: clusterId,
     room: roomId
   }
-4 Trigger OWT cascading
+```
+
+### Trigger OWT cascading
+
 Here is the workflow for OWT cascading trigger:
  ![trigger flow](./pics/cascading/triggerflow.png)
 In step 3, cloud management service will send a create room request with room configuration to ensure that different rooms in different OWT clusters serving for one conference will share the same room configuration. When getting a new client joining conference request and assigning owt cluster to client, cloud management service will trigger cascading if there are other OWT clusters in the same conferencing after getting the new client successfully joined room message from the assigned OWT cluster. 
@@ -90,11 +123,13 @@ Request body:
 ---------|------
 json|cascading
 
+```
   object(cascading) {
     connectip: ip,        //quic server ip address of owt cluster to connect
     connectport: port,   // quic server port of owt cluster to connect
     room:  roomId,    // room id of owt cluster to connect
   }
+```
 
 ![multi clusters](./pics/cascading/multicontrol.png)
 
@@ -103,9 +138,12 @@ json|cascading
 ### Overall process
 
  ![event bridge process](./pics/cascading/eventbridgequic.png)
+
 For event cascading, each cluster will setup a quic session with another OWT, that means one quic session will represent one cascading connection between 2 OWT clusters. All the events in cluster rooms will be sent to another cluster through this quic session. Each conference in cascaded cluster will associate with a quic stream.  
 Event bridge signaling process is listed:
- ![event bridge flow](./pics/cascading/eventbridgeflow.png) 
+
+ ![event bridge flow](./pics/cascading/eventbridgeflow.png)
+
 For event bridge, the earlier joined cluster event bridge will work as quic server, and the later joined cluster event bridge will work as quic client and connect to previous joined cluster event bridge. Inside the OWT cluster, room id will be associated with related quic stream id, so every time when new data comes from quic stream, event bridge will check associated room id with this quic stream id and forward coming cascaded event data to specific conference node. Then the event cascading process between clusters will work properly.
 
 ### Forwarded events
@@ -123,17 +161,22 @@ remove|Remove stream event|removeStream
 update|Stream mute/unmute status update|setStreamMute
 initialize|Initialize stream and participant info to cascaded owt cluster|sonNewClusterCascaded
 
-If owt cluster 2 successfully establishes QUIC connection with owt cluster 1, owt cluster 1 will send “initialize” event including all the room objects to owt cluster 2, then in owt cluster 2 event bridge, bridge will parse the message and simulate participant streams actions to owt cluster 2 conference node. 
-Streams: 
+If owt cluster 2 successfully establishes QUIC connection with owt cluster 1, owt cluster 1 will send “initialize” event including all the room objects to owt cluster 2, then in owt cluster 2 event bridge, bridge will parse the message and simulate participant streams actions to owt cluster 2 conference node.
+
+### QUIC streams:
+
 QUIC client will create a bidirectional stream after successfully establishing QUIC connection with QUIC server. QUIC client will associate the created stream id with conference rpcId where startCascading event is from. QUIC client will then send the remote room info to server, server will bind the stream id with roomid retrieved from stream data. 
 When a conference node in the cluster exits, event bridge will check the QUIC stream associated with it and terminate the stream.
 
 ## Media bridge
 
 Overall process:
+
  ![media bridge process](./pics/cascading/mediabridgequic.png)
+
 Media bridge will be used to transfer media streams between 2 OWT clusters. One QUIC connection will be established for each room in the cluster, and each OWT forward stream will be send through QUIC stream. For WebRTC stream, audio and video track of the same OWT forward stream will be sent out separately in different QUIC stream.
 Each media bridge node will be launched as QUIC server listening at the configured port. If the bridge gets a startCascading request, it will work as QUIC client and proactively establish QUIC connection with the QUIC server in another OWT cluster. A QUIC stream for signaling purpose will be created to exchange cluster info and make sure QUIC connection is ready to work for both sides. Here is a workflow for the initial QUIC connection establish process:
+
  ![media bridge flow](./pics/cascading/mediabridgeflow.png)
 
 ## Build OWT server with cascading bridges