commit 71c6482baf0ff17141c635e6a7639493db68a65c
author Bjorn A Mellem <mellem@webrtc.org> Fri Jun 07 00:26:32 2019
committer Commit Bot <commit-bot@chromium.org> Fri Jun 07 01:09:04 2019
tree 6380b77881c6e990572cbef01b592ff45d0120b6
parent 9e78458b3f15d320f309fbb904513d4cc12c8fa8

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}