Parts of WebRTC require generating RTP to test

[foolip]

See discussion starting at w3c/webrtc-pc#1734 (comment).

And MCU is a Multipoint Conferencing Unit.

In that issue, the underlying problem is that https://w3c.github.io/webrtc-pc/#dom-rtcrtpcontributingsource-audiolevel depends on https://tools.ietf.org/html/rfc6465 and a particular header in RTP being used.

To test this would require something similar in concept to wptserve (HTTP server) or pywebsocket (WebSockets server), i.e. controlling what gets sent to the browser on the network. Possibly it would also be required to first support some other bits around STUN/TURN, DTLS, etc., to even get the browser to a point where it would send RTP.

[foolip]

For why this matters, in w3c/webrtc-pc#1734 some changes were made that weren't really possible to test well, and as a result the tests that did exist were also not updated.

[foolip]

What is the list of stuff that happens on the network before media data is being sent over RTP, at minimum? My guesses from afar:

• Not TURN, in case the clients can make a direct connection
• STUN? If not trying to test STUN itself, could one construct a RTCIceCandidateInit by some other, simpler means?
• DTLS handshakery
• SDP goes over some protocol presumably? RTP?
• RTP media data flows

@alvestrand @agouaillard?

[alvestrand]

STUN in peer to peer mode (getting your own and each other's addresses) is exercised as part of the peer-to-peer connection, so it's not a problem.
Testing STUN in simple NAT mode requires a NAT (so that external and internal addresses are different) and a STUN server. You can generate 127.0.0.1 candidates "by hand", but have to know your own port number - that would require looking at stats to find your own addresses, but that's quite feasible, I think.
Testing TURN requires a TURN server, and preferably the ability to block direct connectivity (having tests that drop candidates that don't go via the TURN server may be enough).
DTLS handshake generates lots of data (certificates and stuff) that shows up both as stats and as transport properties, so it's not a problem to test. (of course testing interoperability is good)
RTP media flows are the same - lots of data generated that shows RTP is flowing, not much more needed there.
I'm assuming that testing the actual protocol implementation details is out of scope for WPT - only properties that affect what's visible at the API are interesting.

In media flows, testing handling of versions of flow that the implementation doesn't generate natively (such as H.264 in packetization mode 0) may not be trivial. We don't have a good API for injecting already encoded data.

[fippo]

web-platform-tests/rfcs#169 is our latest thinking on this

(yes, going through old issues)