E2EME with sframes in chrome

mediasoup libraries
1

I appreciate all the work you guys are putting into Mediasoup, and I understand its hard to keep up with newly released technology. I’m curious if you have any plans to support the new sframes based end to end media encryption support recently released in Chrome? Our product is based on electron, so we can happily avoid the whole cross browser support issues and would love to support end to end encryption in our product. Inspiration for my question is coming from a recent article by Dr. Alex Gouaillard.

Best Regards,

James Pellow

1 Like
2

Will eventually do it, yes. But we are not gonna become “Google Beta testers” again, so will wait until it becomes much more mature (and we get some time to investigate it properly).

1 Like
3

Thanks for your quick reply. I totally understand. You had mentioned once that PERC was on the horizon. Any timeline for that?

4

if i said that then I lied. Anaway, AFAIK SFRAMES deprecates PERC.

5

Well, I’m glad you are aiming to stay relevant rather than stick to comments in obscure threads :slight_smile: The conversation was at:

https://groups.google.com/forum/#!topic/mediasoup/tufJ4ppIOxo

Its my understanding as well that SFRAMES deprecate PERC. Looking forward to better e2e encryption when the dust all settles. Thanks again for all your efforts. You guys are incredible!

Thanks,

James

6

Well, I said “when PERC” becomes a standard". And that has never happened :slight_smile:

2 Likes
7

Well unfortunately it happened two days ago. https://datatracker.ietf.org/doc/rfc8723/

Jitsi, Janus and Medooze had a sightly different implementation (since PERC does not work as is), known as PERC_lite, but media soup did not exist at the time. We all threw PERC out as fast as we can, but if you like archaeology, the client side modified version of libwebrtc is here for you to play … alone … You can even choose between libwebrtc version 57, 61, 65 and 69 :slight_smile:

Thanksfully, it is only the media encryption, but that s exactly what SFrame is.
The SFRame IETF document should be available this month.

NOTE: the problem is not with the media encryption, the problem is with the key exchange, and that part is not ready for the web yet. I think ibc is smart not to get involved into this yet.

1 Like
8

Being completely honest, I hope we don’t even need to deal with SFrame in mediasoup, but just add support for the new AV1 RTP header extension and let the application developer implement SFrame without having to add anything else into mediasoup and mediasoup-client. And AFAIU it will be that way.

9

Yes, this is the plan.

There might be a subtlety on rtp payload type but we re trying to make everything as transparent to SFUs as possible.

That s why waiting a little bit For both AV1 Generic dependency descriptor and sframe to be both sync’ed and implemented make sense for you. The easiest path might be AV1 single layer => av1 SVC and then sframe comes for free / would be a client-side feature.

1 Like
10

Is that RTP extension supposed to also work with other audio/video codecs? And how is it related to already existing frame-marking extension? Will it be deprecated in favour of this new one?

Thanks.

11

Is that RTP extension supposed to also work with other audio/video codecs?

yes, it would be codec agnostic, and so will the packetise / depacketizer.

And how is it related to already existing frame-marking extension? Will it be deprecated in favour of this new one?

well, people implements what they want, but my understanding is that frame marking cannot handle all SVC modes.

We are discussing this at AOMedia:

https://github.com/AOMediaCodec/av1-rtp-spec/issues/97

1 Like