7e8de0bf2d
This reverts commit 71c6482baf0ff17141c635e6a7639493db68a65c. Reason for revert: Lands too much at once and breaks downstream tests that need to implement new interfaces first. Original change's description: > Implement true negotiation for DatagramTransport with fallback to RTP. > > In short, the caller places a x-opaque line in SDP for each m= section that > uses datagram transport. If the answerer supports datagram transport, it will > parse this line and create a datagram transport. It will then echo the x-opaque > line into the answer (to indicate that it accepted use of datagram transport). > > If the offer and answer contain exactly the same x-opaque line, both peers will > use datagram transport. If the x-opaque line is omitted from the answer (or is > different in the answer) they will fall back to RTP. > > Note that a different x-opaque line in the answer means the answerer did not > understand something in the negotiation proto. Since WebRTC cannot know what > was misunderstood, or whether it's still possible to use the datagram transport, > it must fall back to RTP. This may change in the future, possibly by passing > the answer to the datagram transport, but it's good enough for now. > > Negotiation consists of four parts: > 1. DatagramTransport exposes transport parameters for both client and server > perspectives. The client just echoes what it received from the server (modulo > any fields it might not have understood). > > 2. SDP adds a x-opaque line for opaque transport parameters. Identical to > x-mt, but this is specific to datagram transport and goes in each m= section, > and appears in the answer as well as the offer. > - This is propagated to Jsep as part of the TransportDescription. > - SDP files: transport_description.h,cc, transport_description_factory.h,cc, > media_session.cc, webrtc_sdp.cc > > 3. JsepTransport/Controller: > - Exposes opaque parameters for each mid (m= section). On offerer, this means > pre-allocating a datagram transport and getting its parameters. On the > answerer, this means echoing the offerer's parameters. > - Uses a composite RTP transport to receive from either default RTP or > datagram transport until both offer and answer arrive. > - If a provisional answer arrives, sets the composite to send on the > provisionally selected transport. > - Once both offer and answer are set, deletes the unneeded transports and > keeps whichever transport is selected. > > 4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP. > > Bug: webrtc:9719 > Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700 > Commit-Queue: Bjorn Mellem <mellem@webrtc.org> > Reviewed-by: Steve Anton <steveanton@webrtc.org> > Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#28182} TBR=steveanton@webrtc.org,mellem@webrtc.org,sukhanov@webrtc.org Change-Id: I0d502c4a6d27516c35ed85154f3fa5869f88b3b7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:9719 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140822 Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28188}
How to write code in the api/ directory
Mostly, just follow the regular style guide, but:
- Note that
api/code is not exempt from the “.hand.ccfiles come in pairs” rule, so if you declare something inapi/path/to/foo.h, it should be defined inapi/path/to/foo.cc. - Headers in
api/should, if possible, not#includeheaders outsideapi/. It’s not always possible to avoid this, but be aware that it adds to a small mountain of technical debt that we’re trying to shrink. .ccfiles inapi/, on the other hand, are free to#includeheaders outsideapi/.
That is, the preferred way for api/ code to access non-api/ code is to call
it from a .cc file, so that users of our API headers won’t transitively
#include non-public headers.
For headers in api/ that need to refer to non-public types, forward
declarations are often a lesser evil than including non-public header files. The
usual rules still apply, though.
.cc files in api/ should preferably be kept reasonably small. If a
substantial implementation is needed, consider putting it with our non-public
code, and just call it from the api/ .cc file.