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

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 8 May 2012 15:50:06 +0530

I was thinking what the interaction between the SDP direction attributes
and the generation of consent freshness (described in
draft-muthu-behave-consent-freshness-00) should be, in response to some
questions posted by Harald. 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.

This would:

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

- Keep the NAT bindings always alive.

Comments?

Muthu

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 May 2012 08:40:44 -0700

On 8 May 2012 03:20, Muthu Arul Mozhi Perumal (mperumal)
<[email-masked]> 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