Re: [rtcweb] Consent freshness - interaction with SDP direction attributes

[Martin Thomson <[e-mail]>]

On 8 May 2012 03:20, Muthu Arul Mozhi Perumal (mperumal)
<[e-mail]> wrote:
> My thought is that the direction attributes in
> SDP should have no impact on the generation of consent freshness. As far as
> the media connection address and port are valid, the browser should continue
> to generate consent freshness requests, irrespective of whether the stream
> is sendonly, recvonly, sendrecv or inactive, analogous to RTCP.

I tend to agree.

Where I disagree: consent freshness does not require a new mechanism.
If a Binding request is used, it's trivial to maintain consent with
ICE-lite endpoints and I don't see any significant advantage in
avoiding a simple SHA-1.

> - Eliminate the need for the browser to depend on the (untrusted) JS to tell
> it when to stop/start generating consent requests.

This isn't a problem.  The browser needs to have consent freshness
when it sends a packet, simple.  The only possible concern is
clipping, where consent freshness has expired, causing the browser to
drop packets instead of sending them.  If consent freshness wasn't
maintained, then an unmute on a stream would force the browser to
refresh consent prior to sending packets.  Add packet loss and this
could be annoying.

--Martin