Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parts of WebRTC require generating RTP to test #9213

Open
foolip opened this issue Jan 27, 2018 · 4 comments
Open

Parts of WebRTC require generating RTP to test #9213

foolip opened this issue Jan 27, 2018 · 4 comments

Comments

@foolip
Copy link
Member

foolip commented Jan 27, 2018

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
Copy link
Member Author

foolip commented Jan 27, 2018

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
Copy link
Member Author

foolip commented Jan 27, 2018

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
Copy link
Contributor

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
Copy link
Contributor

fippo commented Jan 19, 2024

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

(yes, going through old issues)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants