1. Introduction
This section is non-normative.
This specification uses [RFC3550] to send and receive RTP and RTCP packets.
Note: The API presented in this specification represents a preliminary proposal based on work-in-progress within the W3C WEBRTC WG. As a result, the API is likely to change significantly going forward.
2. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.
This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.
Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)
Implementations that use ECMAScript to implement the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL], as this specification uses that specification and terminology.
3. Terminology
Terminology definitions go here.
4. RTCRtpTransport Interface
4.1. Internal slots
4.2. Constructor
4.3. Attributes
4.4. Methods
5. Privacy and security considerations
5.1. Confidentiality of Communications
5.2. State Persistence
5.3. Protocol Security
5.4. Fingerprinting and Tracking
6. Examples
See the explainer document.