Add intro section

index.html

@@ -818,6 +818,32 @@ <h3>
       The {{RTCRtpContributingSource}} dictionary is defined in [[WEBRTC]]. This
       document extends that dictionary by adding two additional data.
     </p>
+    <p>
+      In this section, the <dfn>capture system</dfn> refers to the system where
+      media is sourced from and the <dfn>sender system</dfn> refers to the
+      system that is sending RTP and RTCP packets to the
+      <dfn>receiver system</dfn> where {{RTCRtpContributingSource}} data is
+      populated.
+    </p>
+    <p>
+      In a direct connection, the <a>capture system</a> is the same as the
+      <a>sender system</a>. But when one or more RTCP-terminating intermediate
+      systems (e.g. mixers) are involved this is not the case. In such cases,
+      media is sourced from the <a>capture system</a>, may be relayed through a
+      number of intermediate systems and is then finally sent from the
+      <a>sender system</a> to the <a>receiver system</a>. The
+      <a>sender system</a>-<a>receiver system</a> path only represents the
+      "last hop".
+    </p>
+    <p>
+      Despite <a><code>RTCRemoteInboundRtpStreamStats.roundTripTime</code></a>
+      measurements only accounting for the "last hop", one-way delay from the
+      <a>capture system</a>'s time of capture to the <a>receiver system</a>'s
+      time of playout can be estimated if the
+      <a>RTP Header Extension for Absolute Capture Time</a> is used all hops of
+      the way, where each RTCP-terminating intermediate system appropriately
+      updates the <a>estimated capture clock offset</a>.
+    </p>
     <pre class="idl">partial dictionary RTCRtpContributingSource {
       DOMHighResTimeStamp captureTimestamp;
       DOMHighResTimeStamp senderCaptureTimeOffset;
@@ -845,14 +871,14 @@ <h2>Dictionary {{RTCRtpContributingSource}} Members</h2>
       <dd>
         <p>The {{senderCaptureTimeOffset}} is the sender's estimate of
         the offset between its own NTP clock and the capture system's NTP clock,
-        for the same frame that the <code>captureTimestamp</code> was originated
+        for the same frame that the {{captureTimestamp}} was originated
         from. The sender is referred to as the system that owns the NTP clock
         that is used to generate the NTP timestamps for the RTCP sender reports
         on this stream. The sender can be different from the capture system, when
         RTCP-terminating intermediate systems (e.g. mixers) are involved. The
-        <code>senderCaptureTimeOffset</code> can be used to estimate one-way delay
+        {{senderCaptureTimeOffset}} can be used to estimate one-way delay
         for the most recent frame.</p>
-        <p class="note"> One way to estimate one-way delay is to translate the
+        <p class="note">One way to estimate one-way delay is to translate the
         {{captureTimestamp}}, which was generated by the capture
         system's NTP clock, into the local NTP clock that generated
         <a><code>RTCRtpContributingSource.timestamp</code></a>,
@@ -864,8 +890,8 @@ <h2>Dictionary {{RTCRtpContributingSource}} Members</h2>
         and an estimated offset between the sender's NTP clock and the local NTP clock.
         The latter can be based on {{RTCRemoteInboundRtpStreamStats}}
         and {{RTCRemoteOutboundRtpStreamStats}} as:
-        <a><code>RTCRemoteOutboundRtpStreamStats.timestamp</code></a> - (
-        <a><code>RTCRemoteOutboundRtpStreamStats.remoteTimestamp</code></a> +
+        <a><code>RTCRemoteOutboundRtpStreamStats.timestamp</code></a> -
+        (<a><code>RTCRemoteOutboundRtpStreamStats.remoteTimestamp</code></a> +
         <a><code>RTCRemoteInboundRtpStreamStats.roundTripTime</code></a> / 2).</p>
         <p>The {{senderCaptureTimeOffset}} MUST be either sourced from the
         <a>estimated capture clock offset</a> field of the