Media Session: video conferencing actions

[mounirlamouri]

Ya ya yawm TAG!

I'm requesting a TAG review of Media Session: video conferencing actions.

Make Media Session useful for video conferencing use cases. This addition to the Media Session specification allows websites to handle microphone, camera, and hangup via new actions and states.

• Explainer¹ (minimally containing user needs and example code): Add new actions to support video conferencing websites w3c/mediasession#264
• Security and Privacy self-review²: nothing new here, the one for the main spec applies.
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/mediasession/
• Primary contacts (and their relationship to the specification):
  • Tommy Steimel (@steimelchrome), Google, editor for the change
  • Mounir Lamouri (@mounirlamouri), Google, co-chair Media WG
  • Jer Noble (@jernoble), Apple, co-chair Media WG
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): TBD

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): Media WG
• The group where standardization of this work is intended to be done ("unknown" if not known): Media WG
• Existing major pieces of multi-stakeholder review or discussion of this design: N/A but GH issue is meant for that
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: N/A

You should also know that...

This is a small addition of the Media Session specification that has already launched in Chrome and (afaik) Firefox. Safari expressed interest and has a WIP implementation. Apple mentioned that they want to add a hangup action to the Media Session specification during the Media WG meeting in January.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @steimelchrome @mounirlamouri

[kenchris]

Considering that people are asking about the use-cases (w3c/mediasession#264 (comment)) it probably makes sense to write a minimal explainer with those

[mounirlamouri]

Considering that people are asking about the use-cases (w3c/mediasession#264 (comment)) it probably makes sense to write a minimal explainer with those

We are going to update the issue to be clearer. Having everything scoped into that issue would be better than having documents around for a change so small. We will update the original explainer to take into account the new actions.

However, the use cases are fairly obvious: when you are on a call, you could mute/unmute yourself, stop/start your camera, and hang up from another location than the website where the video call is happening. Accessing these actions from a notification or some media centre or from a Picture-in-Picture window are usage we are considering. Those are very similar use cases than the media playback ones: controlling your media from outside the scope of the page.

[mounirlamouri]

The issue has been updated to include the use cases.

[cynthia]

Design-wise, I think this looks fine.Two things are a bit confusing:

1. muted / turnedon naming - would be nice to have a generic name to indicate enabled/activeness of the underlying device.
2. muted is negative while turnedon is positive, feels like this should be both positive or negative?

[torgo]

Are there any additional privacy issues that need to be discussed in the explainer, considering that we are talking about muting / unmuting a user's microphone and activating / deactivating the user's camera? Even if not, it might be good to document why not.

[mounirlamouri]

Are there any additional privacy issues that need to be discussed in the explainer, considering that we are talking about muting / unmuting a user's microphone and activating / deactivating the user's camera? Even if not, it might be good to document why not.

There is no privacy implications here. The Media Session API allows websites to register actions. If example.com registers a given action, the UA will notify them when that action should be triggered. The UA is only the middle person in this and no third party is involved. If you are not familiar with Media Session, I understand that it can be unclear.

Design-wise, I think this looks fine.Two things are a bit confusing:

1. muted / turnedon naming - would be nice to have a generic name to indicate enabled/activeness of the underlying device.
2. muted is negative while turnedon is positive, feels like this should be both positive or negative?

The naming isn't great, I agree. @kenchris suggested a naming in the issue that I'm fine with. I will let @steimelchrome make the last call as he is the one actually driving this.

[kenchris]

Thanks for taking our feedback into consideration. We are fine with this feature

[steimelchrome]

Thanks for reviewing! For the record, we made a gist version of the explainer in response to your earlier comment