diff --git a/index.html b/index.html
index 3dc2f0b..6b1a240 100644
--- a/index.html
+++ b/index.html
@@ -295,9 +295,29 @@ <h4>Game streaming</h4>
         <tr>
            <td>N38</td>
            <td>The application must be able to control the jitter buffer and rendering
-           delay. This requirement is addressed by jitterBufferTarget, defined in
+           delay as well as rendering delay variation speed. NOTE: The "control the jitter
+           buffer" part of this requirement is addressed by jitterBufferTarget, defined in
            [[?WebRTC-Extensions]] Section 6.</td>
         </tr>
+        <tr>
+           <td>N48</td>
+           <td>The application must be able to control video decoding to continue even
+           after a frame-loss without waiting for a key frame. This helps the application recover
+           faster from lossy network conditions.</td>
+        </tr>
+        <tr>
+           <td>N49</td>
+           <td>The application must be able to generate signals that indicate to the encoder
+           the loss of encoder-decoder synchronicity (DPB buffers) and the sequence
+           of frame loss using the platform-agnostic protocols. This helps the application recover
+           faster from lossy network conditions.</td>
+        </tr>
+        <tr>
+           <td>N50</td>
+           <td>The application must be able to configure RTCP feedback transmission
+           interval (e.g., Transport-wide RTCP Feedback Message). This helps the application adapt
+           the video quality to the varying network and maintain consistent latency.</td>
+        </tr>
     </tbody>
 </table>
 <p>Experience: Microsoft's Xbox Cloud Gaming and NVIDIA's GeForce NOW are examples of this use case, with media
@@ -1010,9 +1030,10 @@ <h3>Requirements Summary</h3>
         <tr id="N38">
            <td>N38</td>
            <td>The application must be able to control the jitter buffer and rendering
-           delay. This requirement is addressed by jitterBufferTarget, defined in
-           [[?WebRTC-Extensions]] Section 6.</td>
-        </tr>
+            delay as well as rendering delay variation speed. NOTE: The "control the jitter
+            buffer" part of this requirement is addressed by jitterBufferTarget, defined in
+            [[?WebRTC-Extensions]] Section 6.</td>
+         </tr>
         <tr id="N39">
            <td>N39</td>
            <td>A user-agent must be able to forward media received from a peer
@@ -1065,9 +1086,28 @@ <h3>Requirements Summary</h3>
            <td>The WebRTC connection can generate signals indicating demands
            for keyframes, and surface those to the application.</td>
         </tr>
+        <tr id="N48">
+           <td>N48</td>
+           <td>The application must be able to control video decoding to continue even
+           after a frame-loss without waiting for a key frame. This helps the application recover
+           faster from lossy network conditions.</td>
+        </tr>
+        <tr id="N49">
+           <td>N49</td>
+           <td>The application must be able to generate signals that indicate to the encoder
+           the loss of encoder-decoder synchronicity (DPB buffers) and the sequence
+           of frame loss using the platform-agnostic protocols. This helps the application recover
+           faster from lossy network conditions.</td>
+        </tr>
+        <tr id="N50">
+           <td>N50</td>
+           <td>The application must be able to configure RTCP feedback transmission
+           interval (e.g., Transport-wide RTCP Feedback Message). This helps the application adapt
+           the video quality to the varying network and maintain consistent latency.</td>
+        </tr>
     </tbody>
 </table>
-<p class="note">Requirements N40-N47 have unresolved comments from a Call for Consensus (CfC).</p>
+<p class="note">Requirements N40-N50 have unresolved comments from a Call for Consensus (CfC).</p>
 </section>
 </body>
 </html>