1304149 - Support WebRTC when using Web Replay

Status: RESOLVED WONTFIX

(Core :: WebRTC, defect, P3)

Description

[Brian Hackett [Laid off!]]

Web Replay (bug 1207696) currently disables WebRTC when recording or replaying a content process' behavior.  See bug 1207696 comment 248.

Comment 1

[Nils Ohlmeier [:drno]]

I guess from my side the question would be if "just" recording and replaying the media elements which got fed from a PeerConnection is good enough?
But that would leave the DataChannels out of the picture.

The other option I see is to record the incoming packets on a lower layer. The problem with that is that we can't record the certificate with its keys which is used for encrypting and decrypting the packets. That means the recording would have to happen after the decryption. Normally I would have suggested to look at the transportlayer code in media/mtransport. But the problem is that the lower part of stack in there hands every single packet to all layers above, because it does not know how to decrypt them. And each of the listeners decrypts in it own way.
I'm assuming that we don't really care about recording the outgoing packets. At least I don't see a big use case for it, as I assume that for example the video from gUM would/could get recorded in it's media element.

Comment 2

[Brian Hackett [Laid off!]]

(In reply to Nils Ohlmeier [:drno] from comment #1)
> I guess from my side the question would be if "just" recording and replaying
> the media elements which got fed from a PeerConnection is good enough?
> But that would leave the DataChannels out of the picture.
> 
> The other option I see is to record the incoming packets on a lower layer.
> The problem with that is that we can't record the certificate with its keys
> which is used for encrypting and decrypting the packets. That means the
> recording would have to happen after the decryption. Normally I would have
> suggested to look at the transportlayer code in media/mtransport. But the
> problem is that the lower part of stack in there hands every single packet
> to all layers above, because it does not know how to decrypt them. And each
> of the listeners decrypts in it own way.
> I'm assuming that we don't really care about recording the outgoing packets.
> At least I don't see a big use case for it, as I assume that for example the
> video from gUM would/could get recorded in it's media element.

I think the main issue here is that Web Replay doesn't handle media elements yet (bug 1304146).  I don't know the WebRTC code at all, but in general we should be recording/replaying the raw data coming in or going out over e.g. a socket (by redirecting low level system APIs like recvmsg and read), as well as all calls and such which produce encryption/decryption keys used by the listeners.  So in principle we should be able to record/replay the data channels with no or minimal instrumentation, but we'll need to test things to make sure there aren't e.g. any new library APIs which need to be redirected.

Comment 3

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 5

[Andrew McCreight [:mccr8]]

WebReplay is being removed.