This removes code from DataChannelController that exposes
an internal vector of data channels and puts the onus of
returning stats for a data channel, on the data channel
object itself. This will come in handy as we make threading
changes to the data channel object.
Change-Id: Ie164cc5823cd5f9782fc5c9a63aa4c76b8229639
Bug: webrtc:11547, webrtc:11687
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177244
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31533}
This unblocks injecting platform-specific resources, such as power
usage signals in Chrome.
This CL adds AddAdaptationResource to PeerConnectionInterface and
integration tests verifying that if an injected resource is overusing,
resolution will soon be reduced.
To aid testing, some testing-only classes have been updated.
Bug: webrtc:11525
Change-Id: I820099e79f18d910fd641ee1412ad064b99ebce9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177003
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31505}
The PacketSocketFactory dependency (if present on the object passed to
CreatePeerConnection(...)) is given as a raw pointer to the
PortAllocator, but the unique_ptr remains in the dependencies object
which is destroyed at the end of the Initialize call.
Bug: webrtc:11467
Change-Id: I2ccb22b6313fc6b2887bb581704f73a703092af3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172043
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Cr-Commit-Position: refs/heads/master@{#30953}
Split the sctp_mid_ variable into two variables,
sctp_mid_n_ and sctp_mid_s_, each of which is only accessed
by one thread.
Bug: webrtc:9987
Change-Id: I4dce944b920f4698e2606a7b85776791cbf55c28
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168243
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30503}
This accessor seems to be unused, and has a name that we don't
want to support ("content_name").
Bug: none
Change-Id: I2f332176429dd8e1895f821d30e4beaaa4650ec2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168195
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30460}
I could find no reason for the extra complexity of doing messaging
in order to schedule a task to be done after the current cycle.
It also simplifies the peerconnection/datachannelcontroller coupling.
Bug: webrtc:11146
Change-Id: I68f45059b9f4a6869fb44b856e05a480f4652365
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161232
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29997}
This CL:
- Moved HasDataChannel and data_channel_type_
- Moved rtp_data_channels_
- Moved sctp_data_channels_
- Moved data_channel_controller to its own .h file
- Various changes to reduce the coupling between the classes
- Removed friendship between DataChannelController and PeerConnection
Bug: webrtc:11146
Change-Id: Ib8c395e4c90ce34baf40812d1dade0ffa79f2438
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161094
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29987}
This is the same as the existing version, except it uses the Operations
Chain. As such, if an asynchronous operation that uses the chain is
currently pending, such as CreateOffer() or CreateAnswer(),
AddIceCandidate() will not happen until the previous operation
completes.
Bug: chromium:1019222
Change-Id: Ie6e5fc386fa9c29b5e2f8e3f65bfbaf9837d351c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158741
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29704}
This is a reland of 1dddaa1a84330091ca083c950ef2e24a85a48fc8
The regression that caused the original CL to be reverted was the fact that
invoking SetLocalDescription() inside of the CreateOffer() callback was no
longer executing synchronously and immediately.
In this CL, the original CL is patched so that the CreateOffer() operation
is marked as completed just before invoking the CreateOffer() callback
(versus doing it just afterwards). This ensures that the OperationsChain is
popped before the callback runs. The same applies for CreateAnswer().
See diff between Patch Set 1 (Original CL) and the latest Patch Set.
Original change's description:
> [PeerConnection] Use an OperationsChain in PeerConnection for async ops.
>
> For background, motivation, requirements and implementation notes, see
> https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
>
> Using the OperationsChain will unblock future CLs from chaining multiple
> operations together such as implementing parameterless
> setLocalDescription().
>
> In this CL, the OperationsChain is used in existing signaling operations
> with little intended side-effects. An operation that is chained onto an
> empty OperationsChain will for instance execute immediately, and
> SetLocalDescription() and SetRemoteDescription() are implemented as
> "synchronous operations".
>
> The lifetime of the PeerConnection is not indended to change as a result
> of this CL: All chained operations use a WeakPtr to the PC to ensure
> use-after-free does not happen.
>
> There is one notable change though: CreateOffer() and CreateAnswer() will
> asynchronously delay other signaling methods from executing until they
> have completed.
>
> Drive-by fix: This CL also ensures that early failing
> CreateOffer/CreateAnswer operation's observers are invoked if the
> PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
> is pending.
>
> Bug: webrtc:11019
> Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29605}
TBR=steveanton@webrtc.org
Bug: webrtc:11019
Change-Id: I57b4496e63378c91c24679ee496e21f5cb6a0e59
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158524
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29630}
This reverts commit 1dddaa1a84330091ca083c950ef2e24a85a48fc8.
Reason for revert: Breaks downstream projects :(
Original change's description:
> [PeerConnection] Use an OperationsChain in PeerConnection for async ops.
>
> For background, motivation, requirements and implementation notes, see
> https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
>
> Using the OperationsChain will unblock future CLs from chaining multiple
> operations together such as implementing parameterless
> setLocalDescription().
>
> In this CL, the OperationsChain is used in existing signaling operations
> with little intended side-effects. An operation that is chained onto an
> empty OperationsChain will for instance execute immediately, and
> SetLocalDescription() and SetRemoteDescription() are implemented as
> "synchronous operations".
>
> The lifetime of the PeerConnection is not indended to change as a result
> of this CL: All chained operations use a raw pointer to the PC that is
> ensured not to be used-after-free using an "IsAlive" object.
>
> There is one notable change though: CreateOffer() and CreateAnswer() will
> asynchronously delay other signaling methods from executing until they
> have completed.
>
> Drive-by fix: This CL also ensures that early failing
> CreateOffer/CreateAnswer operation's observers are invoked if the
> PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
> is pending.
>
> Bug: webrtc:11019
> Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29605}
TBR=steveanton@webrtc.org,hbos@webrtc.org
Change-Id: Ie540dcc8ecdc48ad0c65d23645fbc3ad5f99592b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11019
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158405
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29611}
For background, motivation, requirements and implementation notes, see
https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
Using the OperationsChain will unblock future CLs from chaining multiple
operations together such as implementing parameterless
setLocalDescription().
In this CL, the OperationsChain is used in existing signaling operations
with little intended side-effects. An operation that is chained onto an
empty OperationsChain will for instance execute immediately, and
SetLocalDescription() and SetRemoteDescription() are implemented as
"synchronous operations".
The lifetime of the PeerConnection is not indended to change as a result
of this CL: All chained operations use a raw pointer to the PC that is
ensured not to be used-after-free using an "IsAlive" object.
There is one notable change though: CreateOffer() and CreateAnswer() will
asynchronously delay other signaling methods from executing until they
have completed.
Drive-by fix: This CL also ensures that early failing
CreateOffer/CreateAnswer operation's observers are invoked if the
PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
is pending.
Bug: webrtc:11019
Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29605}
Adds a field trial and configuration parameter to control whether
datagram transport may be used for data channels in a receive-only
manner. By default, if use_datagram_transport_for_data_channels is
enabled, PeerConnection will create a datagram transport and offer its
use for outgoing calls as well as accept incoming offers with compatible
datagram transport parameters.
With this change, a receive_only mode is added for datagram transport
data channels. When receive_only is set, the PeerConnection will not
create or offer datagram transports for outgoing calls, but will accept
incoming calls that offer compatible datagram transport parameters.
Bug: webrtc:9719
Change-Id: I35667bcc408ea4bbc61155898e6d2472dd262711
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154463
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29327}
This is a reland of 487f9a17e426fd14bb06b13e861071b3f15d119b
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}
PeerConnection now watches when data channels become ready to send
through its implementation of DataChannelSink, and no longer needs to
monitor the MediaTransport state.
Bug: webrtc:9719
Change-Id: I3e17747eb03926a3791c204bf5a1d2dc67855c09
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154001
Commit-Queue: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29261}
Previously, each RTCP packet was handled several times in a row, once
per m-section. This caused various weirdness and log warning spam, in
particular when using unified plan.
The cause was that the packets were wired trough each BaseChannel
instance up to the Call class. With this fix, the RTCP packets are wired
once per RtpTransportInternal via the common peer connection class.
Bug: chromium:1002875
Change-Id: I41c4eb3b68e215ebe0f2c6fb93ae0ee73335b89a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152668
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29226}
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 487f9a17e426fd14bb06b13e861071b3f15d119b.
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 4c85828ab272d9bd58789bad7b135b6287395f97.
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}
This is a reland of 7c6f74ab0344e9c6201de711d54026e9990b8e6c
Compared to the previous commit, new bits are added to log calls of
AddIceCandidate, and the gathering and reception of IPv6 candidates.
Original change's description:
> Set the usage pattern bits for adding remote ICE candidates from SDP.
>
> Currently these bits are only set when a remote ICE candidate is
> successfully added via addIceCandidate. For non-trickled sessions in
> which the remote candidates are added via the remote description, these
> bits are lost. This also happens for trickled sessions, though a rare
> case, when addIceCandidate does not succeed because the peer connection
> is not ready to add any remote candidate.
>
> Bug: webrtc:10868
> Change-Id: Ib2f199f9ffc936060473934d25ba397ef31131a3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148880
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28844}
Bug: webrtc:10868
Change-Id: Ifac0593dcfb64d88619fd24b4ab61c14a0810beb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149024
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28904}
First, the existing configuration parameter (use_datagram_transport) is
now optional.
The new field trial has two flag values:
1. Whether to enable the datagram transport (enabled)
2. Whether to use the datagram transport by default (default_value)
The first is a kill-switch. It disables the datagram transport, even
for applications which inject a datagram transport factory and specify
use_datagram_transport = true. This allows applications which hard-code
a datagram transport to switch it off via field trials.
This flag defaults to true, to avoid breaking downstream projects which
already inject and configure a datagram transport. It may be changed to
false after updating downstream to set this field trial flag to true
when required.
The second provides a default value to be used in case the
aforementioned use_datagram_transport parameter is unset. Applications
which explicitly set use_datagram_transport will use that value.
Applications which do not explicitly specify whether or not to use the
datagram transport will use it (or not) according to the default_value
flag.
One goal of this flag is to simplify rollout in applications which
already set field trials based on configuration, but require code
changes for new RTCConfiguration parameters. A second goal is to
provide platforms with a knob to control whether datagram transport is
"opt-in" or "opt-out".
This flag defaults to false, to prevent downstream projects from
unintentionally enabling the datagram tranpsort.
Bug: webrtc:9719
Change-Id: I521a5fa61c992e76e5081118678a1812a261d672
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144184
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28435}
