commit | c85ebbe766bb1bdcb34d806df7d2194310ccd335 | [log] [tgz] |
---|---|---|
author | Bjorn A Mellem <mellem@webrtc.org> | Fri Jun 07 10:28:06 2019 -0700 |
committer | Commit Bot <commit-bot@chromium.org> | Fri Jun 07 20:14:36 2019 +0000 |
tree | 955a4f96fa76ec326fbde473f44fc37160c9cc1b | |
parent | 17031afe184cbeac565d3874c0a6f0f398c3a577 [diff] |
Reland: 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: Ifcc428c8d76fb77dcc8abaa79507c620bcfb31b9 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140920 Reviewed-by: Steve Anton <steveanton@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28198}
WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.
The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.
See http://www.webrtc.org/native-code/development for instructions on how to get started developing with the native code.
Authoritative list of directories that contain the native API header files.