W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > May 2019

Re: [webrtc-pc] Permission API for receive-only media and data use cases (#2175)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Thu, 09 May 2019 12:59:56 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-490893534-1557406794-sysbot+gh@w3.org>
I think this proposal addresses a problem we've had for a long time: the unfortunate tight coupling of initial connection with `getUserMedia`.

Right now, WebRTC connections are effectively behind permission prompts. Every major WebRTC site gets camera and mic first, when there's really no (other) reason connection couldn't have been established ahead of this, for an overall speedier connection experience. I even see code blocking `createAnswer` on `getUserMedia`, which design-wise is hacky, actually slows down initial connection, and leads people down the wrong path, away from healthy patterns like `negotiationneeded`.

Now, UX is hard. This is a second-tier category of permission, not good for a modal prompt.

But defining the `"direct-connection"` permission here is the key and the right step IMHO. It opens up ideas like e.g. have gamer web extensions control this, or—for browsers that don't implicitly persist gum permission after first use—implementations might want to automatically enable this permission for sites that have been granted `getUserMedia` once in the past.

I also like the API design, which purposely encourages apps to go ahead and not block on permission, and lets browsers "upgrade" the connection later.

Ironically, adding this permission might actually help free initial connection from being behind a permission prompt.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2175#issuecomment-490893534 using your GitHub account
Received on Thursday, 9 May 2019 12:59:58 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:47 UTC