RE: Issue #4 (Need API to read the CSRC on received tracks) and Issue #6 (Need API to receive mixer to client audio level information for a track)

Some questions: 

1. What is the purpose of the timestamp? 

If the RTCRtpContributingSource dictionary only provides information on RTP packets received in the last second this isn't clear to me.  Do we really care how many ms ago the last RTP packet arrived?   

The timestamp was originally put in when the RTCRtpContributingSource dictionary contained only source and timestamp attributes, and the dictionary was to provide information on sources that might have been received over a much longer interval (e.g. since the RtpReceiver was created).  In that formulation, the timestamp enabled the application to filter out sources that had not spoken recently (with the interval defined by the application).  

2. Does it really make sense to include both SSRC and CSRC RTCRtpContributingSource dictionary entries? 

In the case with a centralized mixer, the goal is to provide information on contributing sources and levels taken from the mixer-client (RFC 6465) extension.  The overall (mixed) audio level (calculated as per RFC 6464) and the SSRC does not seem relevant, since this relates to the mixer, and not to an individual participant.  

In the case of a P2P mesh, the SSRC and client-mixer extension (RFC 6464) provides the information that can be used in the UI.  In that case there are no CSRCs or mixer-client header extensions, since there is no mixer. 


________________________________________
From: Harald Alvestrand [harald@alvestrand.no]
Sent: Sunday, September 13, 2015 1:08 PM
To: public-webrtc@w3.org
Subject: Re: Issue #4 (Need API to read the CSRC on received tracks) and   Issue #6 (Need API to receive mixer to client audio level information for  a track)

On 09/11/2015 12:37 PM, Martin Thomson wrote:
> On 11 September 2015 at 12:07, Bernard Aboba
> <Bernard.Aboba@microsoft.com> wrote:
>
<snip>
> 3.    How is the timestamp value obtained?  Is this the timestamp value from
> the RTP packet?  Or is it an NTP timestamp?
> That's a good question.  And part of why I wasn't particularly happy
> with the timestamp.  HighResTimestamp is usually something that is
> local to the browser, so some translation would be required if the
> time was based on the NTP time.  That said, the NTP time from the
> packet isn't going to relate well to the playback time, but it might
> be the best option, since packet arrival time doesn't really match to
> anything of use.  Do we have any way to determine what the difference
> is between the NTP times used in RTP and the playback time?
The RTP timestamp value is a reasonable choice because it is:
- Defined for all packets
- Universally known to not have global meaning

The second alternative is the NTP translation of the RTP timestamp.
This is:
- Only defined for packets for which an RTCP SR has been received and parsed
- Related to the global "NTP time" through the sender's clock
configuration - which means that it will have its obvious meaning *most*
of the time (not a good thing).

The third alternative is that it's the HighResTimestamp of the time the
browser thinks it received the packets. This is:
- Defined for all packets
- Related to the local system clock, which makes it consistent with most
APIs the client is likely to access
- Somewhat variable offset from the time the sender thinks it sent the
packet - so it's not likely to be meaningful to send it to other clients
(if there was ever a reason for that).

I'm leaning towards going with the third option. It's simplest to implement.



--
Surveillance is pervasive. Go Dark.

Received on Saturday, 19 September 2015 20:45:08 UTC