The plugin transport parameters (a=x-opaque: lines) relate to how to create and
set up a plugin transport. When SDP bundle is used, the x-opaque line needs to
be copied into the bundled m= section. This means x-opaque can appear on a
section even if the offerer does not intend to use the transport for the media
described by that section. Consequently, the answerer cannot currently tell
whether the caller is offering an alternate transport for media, data, or both.
This change adds an a=x-alt-protocol: line to SDP. The value following this
line matches the <protocol> part of the x-opaque:<protocol>:<params> line.
However, alt-protocol is not bundled--it only ever applies to the m= section
that contains the line. This allows the offerer to express which m= sections
should actually use an alternate transport, even in the case of bundle.
Note that this is still limited by the available configuration options:
datagram transport can be used for media (audio + video) and/or data. It is
still not possible to use it for audio but not video, or vice versa.
PeerConnection places an alt-protocol line in each media (audio/video) m=
section if it is configured to use a datagram transport for media. It places
an alt-protocol line in each data m= section if it is configured to use a
datagram transport for data channels. PeerConnection leaves alt-protocol in
media (audio/video) m= sections of the answer if it is configured to use a
datagram transport for media, and in data m= sections of the answer if it is
configured to use a datagram transport for data channels.
JsepTransport now negotiates use of the datagram transport independently for
media and data channels. It only uses it for media if the m= sections for
bundled audio/video have an alt-protocol line matching the x-opaque protocol,
and only uses it for data channels if a bundled m= section for data has an
alt-protocol line matching the x-opaque protocol.
Bug: webrtc:9719
Change-Id: I773e4fc10c57d815afcd76a2a74da38dd0c52b3b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154763
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29351}
This fixes a DCHECK during teardown in the case when the primary
DataChannelTranspot (eg. DatagramTransport) is successfully negotiated.
DatagramTransport expects the DataSink to be unset before it's deleted.
This was not caught by existing tests because the fallback transport
(SctpDataChannelTransport) does not have the same DCHECK.
Also adds a regression test for the issue, in which SCTP is available
as a fallback but DataChannelTransport is negotiated successfully.
Bug: webrtc:9719
Change-Id: I414d964d3c85d3d01cdb5e34d6b248659a613c39
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154365
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29292}
This is a reland of 487f9a17e4
Original change's description:
> Reland "Refactor SCTP data channels to use DataChannelTransportInterface."
>
> Also clears SctpTransport before deleting JsepTransport.
>
> SctpTransport is ref-counted, but the underlying transport is deleted when
> JsepTransport clears the rtp_dtls_transport. This results in crashes when
> usrsctp attempts to send outgoing packets through a dangling pointer to the
> underlying transport.
>
> Clearing SctpTransport before DtlsTransport removes the pointer to the
> underlying transport before it becomes invalid.
>
> This fixes a crash in chromium's web platform tests (see
> https://chromium-review.googlesource.com/c/chromium/src/+/1776711).
>
> Original change's description:
> > Refactor SCTP data channels to use DataChannelTransportInterface.
> >
> > This change moves SctpTransport to be owned by JsepTransport, which now
> > holds a DataChannelTransport implementation for SCTP when it is used for
> > data channels.
> >
> > This simplifies negotiation and fallback to SCTP. Negotiation can now
> > use a composite DataChannelTransport, just as negotiation for RTP uses a
> > composite RTP transport.
> >
> > PeerConnection also has one fewer way it needs to manage data channels.
> > It now handles SCTP and datagram- or media-transport-based data channels
> > the same way.
> >
> > There are a few leaky abstractions left. For example, PeerConnection
> > calls Start() on the SctpTransport at a particular point in negotiation,
> > but does not need to call this for other transports. Similarly, PC
> > exposes an interface to the SCTP transport directly to the user; there
> > is no equivalent for other transports.
>
> Bug: webrtc:9719
> Change-Id: I64e94b88afb119fdbf5f22750f88c8a084d53937
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151981
> Reviewed-by: Benjamin Wright <benwright@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Benjamin Wright <benwright@webrtc.org>
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29120}
Bug: webrtc:9719
Change-Id: I28481a3de64a3506bc57748106383eeba4ef205c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152740
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29290}
And move related files into api/transport/ and api/transport/media/.
The moved files are unchanged, except that
congestion_control_interface.h and datagram_transport_interface.h
no longer include media_transport_interface.h, instead, they forward
declare the few MediaTransport* types they reference.
Bug: webrtc:8733
Change-Id: I4f4000d0d111f10d15a54c99af27ec26c46ae652
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152482
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29178}
This reverts commit 487f9a17e4.
Reason for revert: speculative revert
Original change's description:
> Reland "Refactor SCTP data channels to use DataChannelTransportInterface."
>
> Also clears SctpTransport before deleting JsepTransport.
>
> SctpTransport is ref-counted, but the underlying transport is deleted when
> JsepTransport clears the rtp_dtls_transport. This results in crashes when
> usrsctp attempts to send outgoing packets through a dangling pointer to the
> underlying transport.
>
> Clearing SctpTransport before DtlsTransport removes the pointer to the
> underlying transport before it becomes invalid.
>
> This fixes a crash in chromium's web platform tests (see
> https://chromium-review.googlesource.com/c/chromium/src/+/1776711).
>
> Original change's description:
> > Refactor SCTP data channels to use DataChannelTransportInterface.
> >
> > This change moves SctpTransport to be owned by JsepTransport, which now
> > holds a DataChannelTransport implementation for SCTP when it is used for
> > data channels.
> >
> > This simplifies negotiation and fallback to SCTP. Negotiation can now
> > use a composite DataChannelTransport, just as negotiation for RTP uses a
> > composite RTP transport.
> >
> > PeerConnection also has one fewer way it needs to manage data channels.
> > It now handles SCTP and datagram- or media-transport-based data channels
> > the same way.
> >
> > There are a few leaky abstractions left. For example, PeerConnection
> > calls Start() on the SctpTransport at a particular point in negotiation,
> > but does not need to call this for other transports. Similarly, PC
> > exposes an interface to the SCTP transport directly to the user; there
> > is no equivalent for other transports.
>
> Bug: webrtc:9719
> Change-Id: I64e94b88afb119fdbf5f22750f88c8a084d53937
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151981
> Reviewed-by: Benjamin Wright <benwright@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Benjamin Wright <benwright@webrtc.org>
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29120}
TBR=steveanton@webrtc.org,mellem@webrtc.org,benwright@webrtc.org
Change-Id: Ibd1a7f30931c114212c90824fec414d276d3f915
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152421
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29141}
Also clears SctpTransport before deleting JsepTransport.
SctpTransport is ref-counted, but the underlying transport is deleted when
JsepTransport clears the rtp_dtls_transport. This results in crashes when
usrsctp attempts to send outgoing packets through a dangling pointer to the
underlying transport.
Clearing SctpTransport before DtlsTransport removes the pointer to the
underlying transport before it becomes invalid.
This fixes a crash in chromium's web platform tests (see
https://chromium-review.googlesource.com/c/chromium/src/+/1776711).
Original change's description:
> Refactor SCTP data channels to use DataChannelTransportInterface.
>
> This change moves SctpTransport to be owned by JsepTransport, which now
> holds a DataChannelTransport implementation for SCTP when it is used for
> data channels.
>
> This simplifies negotiation and fallback to SCTP. Negotiation can now
> use a composite DataChannelTransport, just as negotiation for RTP uses a
> composite RTP transport.
>
> PeerConnection also has one fewer way it needs to manage data channels.
> It now handles SCTP and datagram- or media-transport-based data channels
> the same way.
>
> There are a few leaky abstractions left. For example, PeerConnection
> calls Start() on the SctpTransport at a particular point in negotiation,
> but does not need to call this for other transports. Similarly, PC
> exposes an interface to the SCTP transport directly to the user; there
> is no equivalent for other transports.
Bug: webrtc:9719
Change-Id: I64e94b88afb119fdbf5f22750f88c8a084d53937
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151981
Reviewed-by: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29120}
This reverts commit 4c85828ab2.
Reason for revert:
Speculatively reverting this because it makes several web platform tests relating to RTCDataChannel flaky, see first failing roll:
https://chromium-review.googlesource.com/c/chromium/src/+/1776711
Original change's description:
> Refactor SCTP data channels to use DataChannelTransportInterface.
>
> This change moves SctpTransport to be owned by JsepTransport, which now
> holds a DataChannelTransport implementation for SCTP when it is used for
> data channels.
>
> This simplifies negotiation and fallback to SCTP. Negotiation can now
> use a composite DataChannelTransport, just as negotiation for RTP uses a
> composite RTP transport.
>
> PeerConnection also has one fewer way it needs to manage data channels.
> It now handles SCTP and datagram- or media-transport-based data channels
> the same way.
>
> There are a few leaky abstractions left. For example, PeerConnection
> calls Start() on the SctpTransport at a particular point in negotiation,
> but does not need to call this for other transports. Similarly, PC
> exposes an interface to the SCTP transport directly to the user; there
> is no equivalent for other transports.
>
> Bug: webrtc:9719
> Change-Id: I0d3151c48c1a511368277981fc4cf818a9f8ebb4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150341
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Reviewed-by: Benjamin Wright <benwright@webrtc.org>
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29012}
TBR=steveanton@webrtc.org,mellem@webrtc.org,benwright@webrtc.org
Change-Id: I074b9e68f298d20d0cabb4239084b4843e76e910
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150944
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29025}
This change moves SctpTransport to be owned by JsepTransport, which now
holds a DataChannelTransport implementation for SCTP when it is used for
data channels.
This simplifies negotiation and fallback to SCTP. Negotiation can now
use a composite DataChannelTransport, just as negotiation for RTP uses a
composite RTP transport.
PeerConnection also has one fewer way it needs to manage data channels.
It now handles SCTP and datagram- or media-transport-based data channels
the same way.
There are a few leaky abstractions left. For example, PeerConnection
calls Start() on the SctpTransport at a particular point in negotiation,
but does not need to call this for other transports. Similarly, PC
exposes an interface to the SCTP transport directly to the user; there
is no equivalent for other transports.
Bug: webrtc:9719
Change-Id: I0d3151c48c1a511368277981fc4cf818a9f8ebb4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150341
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Benjamin Wright <benwright@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29012}
PeerConnection now has a new setting in RTCConfiguration to enable use of
datagram transport for data channels. There is also a corresponding field
trial, which has both a kill-switch and a way to change the default value.
PeerConnection's interaction with MediaTransport for data channels has been
refactored to work with DataChannelTransportInterface instead.
Adds a DataChannelState and OnStateChanged() to the DataChannelSink
callbacks. This allows PeerConnection to listen to the data channel's
state directly, instead of indirectly by monitoring media transport
state. This is necessary to enable use of non-media-transport (eg.
datagram transport) data channel transports.
For now, PeerConnection watches the state through MediaTransport as well.
This will persist until MediaTransport implements the new callback.
Datagram transport use is negotiated. As such, an offer that requests to use
datagram transport for data channels may be rejected by the answerer. If the
offer includes DTLS, the data channels will be negotiated as SCTP/DTLS data
channels with an extra x-opaque parameter for datagram transport. If the
opaque parameter is rejected (by an answerer without datagram support), the
offerer may fall back to SCTP.
If DTLS is not enabled, there is no viable fallback. In this case, the data
channels are negotiated as media transport data channels. If the receiver does
not understand the x-opaque line, it will reject these data channels, and the
offerer's data channels will be closed.
Bug: webrtc:9719
Change-Id: Ic1bf3664c4bcf9d754482df59897f5f72fe68fcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147702
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28932}
DatagramDtlsAdaptor wraps a DatagramTransport in a DtlsTransport. This
is only used by wrapping it again, in an RtpTransport. It is simpler to
just wrap DatagramTransport directly into an RtpTransport.
DatagramTransport is never used as a DtlsTransport, and doesn't support
most of the functionality exposed by the DtlsTransport interface.
However, it supports *all* the functionality of the RtpTransport, making
this a much cleaner fit.
Bug: webrtc:9719
Change-Id: I699e8124ee4cb6c8c187162f9b444ff0431a4902
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149400
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28921}
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}
This reverts commit 71c6482baf.
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}
This fires in downstream tests when re-negotiation of a datagram
transport completes.
Bug: webrtc:9719
Change-Id: Ie7337e7dc33e41a83da37d3ef2fda596d9107256
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140821
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28183}
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}
- This makes it consistent with ICE and MediaTransport ownership.
- Removes unnecessary datagram_transport() getter in DtlsTransportInternal
As a side effect this fixes bug in JsepTransportController, which moved datagram_transport to Dtls after creating it, then checked if (datagram_transport) to decide which RTP transport to create. As a result of this bug we were creating Sded instead of Unencrypted RTP with datagram transport.
Bug: webrtc:9719
Change-Id: Ic5b13a450ce6ac5b2a20d388657e3949aabef079
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139620
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28146}
It does not make sense for DtlsTransport to own ICE, and this arrangement will
not work when negotiating datagram or DTLS transport. During negotiation, both
a DTLS transport and a datagram transport need to be ready to receive from the
same ICE transport, depending on which protocol is chosen by the answerer. Once
the answerer chooses a protocol, the transport that is not chosen must be
deleted, but ICE must be left intact for use by the remaining transport.
Bug: webrtc:9719
Change-Id: Ibab969b574c981e3834ced71f8ff88008cb26a6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139340
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28113}
- Implement datagram transport adaptor, which wraps datagram transport in DtlsTransportInternal. Datagram adaptor owns both ICE and Datagram Transports.
- Implement setup of datagram transport based on RTCConfiguration flag use_datagram_transport. This is very similar to MediaTransport setup with the exception that we create DTLS datagram adaptor.
- Propagate maximum datagram size to video encoder via MediaTransportConfig.
TODO: Currently this CL can only be tested in downstream projects. Once we add fake datagram transport, we will be able to implement unit tests similar to loopback media transport.
Bug: webrtc:9719
Change-Id: I4fa4a5725598dfee5da4f0f374269a7e289d48ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138100
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28047}
This reverts commit caedb5db82.
Reason for revert: Fixed issue (allow SetNeedsIceRestart from off-thread).
Original change's description:
> Revert "Add thread guards to JsepTransport"
>
> This reverts commit 7e1db52c93.
>
> Reason for revert: Breaks downstream.
>
> Original change's description:
> > Add thread guards to JsepTransport
> >
> > This ensures that JsepTransport's methods are either only accessed on the thread
> > that creates it, or using methods that are marked for off-thread use
> > (using a lock to prevent simultaneous access).
> >
> > The intent is to document the existing contract, and to make it easy to find the
> > actions needed to convert the class to a pure single-threaded class.
> >
> > Bug: webrtc:10300
> > Change-Id: Ib5cdc027632c36baec55179937d6eb664bbaf6f5
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/121946
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#27427}
>
> TBR=steveanton@webrtc.org,solenberg@webrtc.org,kwiberg@webrtc.org,hbos@webrtc.org,hta@webrtc.org
>
> Change-Id: I30c65d2161de9376ccd1172e2b261f2280fb1d75
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:10300
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130519
> Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
> Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27429}
Change-Id: Ic32bfc04d96e657fc67c3d3999f77969e55ed994
Bug: webrtc:10300
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130962
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27434}
This reverts commit 7e1db52c93.
Reason for revert: Breaks downstream.
Original change's description:
> Add thread guards to JsepTransport
>
> This ensures that JsepTransport's methods are either only accessed on the thread
> that creates it, or using methods that are marked for off-thread use
> (using a lock to prevent simultaneous access).
>
> The intent is to document the existing contract, and to make it easy to find the
> actions needed to convert the class to a pure single-threaded class.
>
> Bug: webrtc:10300
> Change-Id: Ib5cdc027632c36baec55179937d6eb664bbaf6f5
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/121946
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27427}
TBR=steveanton@webrtc.org,solenberg@webrtc.org,kwiberg@webrtc.org,hbos@webrtc.org,hta@webrtc.org
Change-Id: I30c65d2161de9376ccd1172e2b261f2280fb1d75
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10300
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130519
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27429}
This ensures that JsepTransport's methods are either only accessed on the thread
that creates it, or using methods that are marked for off-thread use
(using a lock to prevent simultaneous access).
The intent is to document the existing contract, and to make it easy to find the
actions needed to convert the class to a pure single-threaded class.
Bug: webrtc:10300
Change-Id: Ib5cdc027632c36baec55179937d6eb664bbaf6f5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/121946
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27427}
This is in preparation for letting Chrome extract DTLSTransport
information after SLD/SRD instead of doing it on-demand.
Bug: chromium:907849
Change-Id: Iac6b174c98d3d14136e1fd25bce4a9292f6c8b41
Reviewed-on: https://webrtc-review.googlesource.com/c/116984
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26289}
