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}
Static libraries don't guarantee that an exported symbol gets linked
into a shared library (and in order to support Chromium's component
build mode, WebRTC needs to be linked as a shared library).
Source sets always pass all the object files to the linker.
On the flip side, source_sets link more object files in release builds
and to avoid this, this CL introduces a the GN template "rtc_library" that
expands to static_library during release builds and to source_set during
component builds.
See: https://gn.googlesource.com/gn/+/master/docs/reference.md#func_source_set
Bug: webrtc:9419
Change-Id: I4667e820c2b3fcec417becbd2034acc13e4f04fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157168
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#29525}
Merge GlobalLock and GlobalLockPod, make member private.
annotate creation of all GlobalLocks with ABSL_CONST_INIT
Bug: None
Change-Id: I29abcc86796ec0e45b15df7d26392309d1bf7324
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156303
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29447}
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}
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}
There are a few reasons for making this test only:
* The code is only used by tests and utilities.
* The pure interface has only a single implementation so an interface isn't really needed.
(a followup change could remove it altogether)
* The implementation always incorporates locking regardless of how the class gets used.
See e.g. previous use in the Packet class.
* The implementation is a layer on top of RtpUtility::RtpHeaderParser which is
sufficient for most production cases.
Change-Id: Ide6d50567cf8ae5127a2eb04cceeb10cf317ec36
Bug: none
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150658
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29010}
The new target does not depend on libjingle_peerconnection_api, and to
do this, the named "audio" and "video" string literals had to be moved from
media_stream_interface.cc to media_types.cc.
In this cl, the dependency on libjingle_peerconnection_api can be
dropped from a few targets.
No-Presubmit: True
Bug: webrtc:8733
Change-Id: Icc675280d5c3c537f2255a9389ff18a482049921
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/53861
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28998}
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}
1. Propagate sent notification for all packets, including RTCP
2. Add Field Trial to disable datagram => RTCP feedback loop translation (for tests and experiments only, because having two feedback loops add extra overhead).
Bug: webrtc:9719
Change-Id: Ia3143cc79d127ae331210c86d6675d6e778e962b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145460
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28568}
This change removes RTCP Feedback loop if we are using datagram transport by removing transport sequence numbers from RTP packets and recreating RTCP Feedback from Datagram ACKs and Timestamps.
- For outgoing RTP packets, remove transport sequence number and store it with datagram_id. Note that removing transport sequence numbers does not only save 4-8 bytes per packet, but also prevents generation of feedback packets on the receiver side.
- When datagram ACKs, we re-created RTCP feedback with timestamp.
- Replacing previous assumption that datagram_id was the same as packet_id by storing incremental counter of datagram ids (I noticed some packets come without packet_id, which is a bit strange, but easy to support and it's also good not to rely on packet_ids being unique across multiple ssrcs).
Bug: webrtc:9719
Change-Id: Iecfe938ecea1a74e7c9e1484f0e985d72643d4a1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145269
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28542}
Datagram_dtls_adaptor needs access to rtp_rtcp modules and this moves helps to keep p2p/base/ without dependency on rtp_rtcp.
Bug: webrtc:9719
Change-Id: Ic337be3fb9f68106187a84efa815eefbe5b0fcd7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145267
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28533}
instead of using factories for MediaEngine and RtcEventLog that rely on GlobalTaskQueueFactory
Bug: webrtc:10284
Change-Id: Ie1135f70f4ae4d047c4d6bf2db61489a663385aa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/141875
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28328}
Users that would like custom TaskQueueFactory (e.g. chromium) should use
CreateModularPeerConnectionFactory directly
Bug: webrtc:10284
Change-Id: I7ba55a0f21560d4beb71a7f93f6fa70b0fe74931
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142234
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28324}
This change is part of a change to break the dependency between "api:rtp_headers" and "api/video:video_frame". It does so by first creating an empty "api/video:video_rtp_headers" build rule so that downstream projects can be fixed before moving the source files.
Bug: webrtc:10668
Change-Id: I81aa6edfef3639b457a40aa93de048e62cbfd8ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140291
Commit-Queue: Chen Xing <chxg@google.com>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28209}
This will be used to multiplex multiple transports during SDP
negotiation. When the offerer watns to support multiple RTP transports,
it will combine them into a singla CompositeRtpTransport.
CompositeRtpTransport can receive from any of the offered transports
while waiting for an answer to arrive.
The choice of which transport is used to send must be driven by the SDP
answer. If a provisional answer arrives, the composite can be set to
send using the chosen transport, while maintaining other transports in
case the peer changes its mind. When the final answer arrives, the
composite will be deleted and replaced with the chosen transport.
Bug: webrtc:9719
Change-Id: Ib8cea77ef202f37086723bfa2c71e2aa5995a912
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138281
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28093}
This implements the essentials of RTCRemoteInboundRtpStreamStats. This
includes:
- ssrc
- transportId
- codecId
- packetsLost
- jitter
- localId
- roundTripTime
https://w3c.github.io/webrtc-stats/#remoteinboundrtpstats-dict*
The following members are not implemented because they require more
work...
- From RTCReceivedRtpStreamStats: packetsReceived, packetsDiscarded,
packetsRepaired, burstPacketsLost, burstPacketsDiscarded,
burstLossCount, burstDiscardCount, burstLossRate, burstDiscardRate,
gapLossRate and gapDiscardRate.
- From RTCRemoteInboundRtpStreamStats: fractionLost.
Bug: webrtc:10455, webrtc:10456
Change-Id: If2ab0da7105d8c93bba58e14aa93bd22ffe57f1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138067
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28073}
This also refactors some of the code in peerconnection for
handling SCTP transports to be internal to the webrtc::SctpTransport
class, rather than being in peerconnection.
Bug: webrtc:10358, webrtc:10629
Change-Id: I15ecf95c199f56b08909e5a9311d446a412ed162
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/137041
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27960}
This reverts commit 46afbf9481fbcc939c998c898ca1031ce41cc6b1.
Reason for revert: Tightened protocol name handling.
Original change's description:
> Revert "Reland "Version 2 "Refactoring DataContentDescription class"""
>
> This reverts commit 37f2b43274a0d718de53a4cfcf02226356edcf6e.
>
> Reason for revert: fuzzer failures
>
> Original change's description:
> > Reland "Version 2 "Refactoring DataContentDescription class""
> >
> > This is a reland of 14b2758726879d21671a21291dfed8fb4fd5c21c
> >
> > Original change's description:
> > > Version 2 "Refactoring DataContentDescription class"
> > >
> > > (substantial changes since version 1)
> > >
> > > This CL splits the cricket::DataContentDescription class into
> > > two classes: cricket::RtpDataContentDescription (used for RTP data)
> > > and cricket::SctpDataContentDescription (used for SCTP only).
> > >
> > > SctpDataContentDescription no longer inherits from
> > > MediaContentDescriptionImpl, and no longer contains "codecs".
> > >
> > > Due to usage of internal interfaces by consumers, shimming the old
> > > DataContentDescription API is needed.
> > >
> > > A new cricket::DataContentDescription class is defined, which is
> > > a shim over RtpDataContentDescription and SctpDataContentDescription.
> > > It exposes as little functionality as possible, but supports the
> > > concerned consumer's usage
> > >
> > > Design document:
> > > https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
> > >
> > > Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
> > >
Bug: webrtc:10358
Change-Id: Ia9fb8f4679e082e3d18fbbb6b03fc13a08e06110
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/136581
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27933}
This reverts commit 37f2b43274a0d718de53a4cfcf02226356edcf6e.
Reason for revert: fuzzer failures
Original change's description:
> Reland "Version 2 "Refactoring DataContentDescription class""
>
> This is a reland of 14b2758726879d21671a21291dfed8fb4fd5c21c
>
> Original change's description:
> > Version 2 "Refactoring DataContentDescription class"
> >
> > (substantial changes since version 1)
> >
> > This CL splits the cricket::DataContentDescription class into
> > two classes: cricket::RtpDataContentDescription (used for RTP data)
> > and cricket::SctpDataContentDescription (used for SCTP only).
> >
> > SctpDataContentDescription no longer inherits from
> > MediaContentDescriptionImpl, and no longer contains "codecs".
> >
> > Due to usage of internal interfaces by consumers, shimming the old
> > DataContentDescription API is needed.
> >
> > A new cricket::DataContentDescription class is defined, which is
> > a shim over RtpDataContentDescription and SctpDataContentDescription.
> > It exposes as little functionality as possible, but supports the
> > concerned consumer's usage
> >
> > Design document:
> > https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
> >
> > Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
> >
> > Bug: webrtc:10358
> > Change-Id: Icf95fb7308244d6f2ebfdb403aaffc544e358580
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133900
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Steve Anton <steveanton@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#27853}
>
> Bug: webrtc:10358
> Change-Id: Iff45c4694167f0b31b34ff2167c1f4ffa650bcc4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135281
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27896}
TBR=steveanton@webrtc.org,kwiberg@webrtc.org,hbos@webrtc.org,hta@webrtc.org,shampson@webrtc.org
Change-Id: Ied6d9fb96aafe9c957f2658b34b5331b1f359b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10358
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135986
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27917}
Recommended usage is to create copies with Clone() and to
call JsepSessionDescription::Initialize using std::move.
Bug: webrtc:10612
Change-Id: I626a08a35ba8e112471cec0374c944e96f8effbc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135941
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27911}
This is a reland of 14b2758726879d21671a21291dfed8fb4fd5c21c
Original change's description:
> Version 2 "Refactoring DataContentDescription class"
>
> (substantial changes since version 1)
>
> This CL splits the cricket::DataContentDescription class into
> two classes: cricket::RtpDataContentDescription (used for RTP data)
> and cricket::SctpDataContentDescription (used for SCTP only).
>
> SctpDataContentDescription no longer inherits from
> MediaContentDescriptionImpl, and no longer contains "codecs".
>
> Due to usage of internal interfaces by consumers, shimming the old
> DataContentDescription API is needed.
>
> A new cricket::DataContentDescription class is defined, which is
> a shim over RtpDataContentDescription and SctpDataContentDescription.
> It exposes as little functionality as possible, but supports the
> concerned consumer's usage
>
> Design document:
> https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
>
> Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
>
> Bug: webrtc:10358
> Change-Id: Icf95fb7308244d6f2ebfdb403aaffc544e358580
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133900
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27853}
Bug: webrtc:10358
Change-Id: Iff45c4694167f0b31b34ff2167c1f4ffa650bcc4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135281
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27896}
This reverts commit 14b2758726879d21671a21291dfed8fb4fd5c21c.
Reason for revert: Internal import failed.
Original change's description:
> Version 2 "Refactoring DataContentDescription class"
>
> (substantial changes since version 1)
>
> This CL splits the cricket::DataContentDescription class into
> two classes: cricket::RtpDataContentDescription (used for RTP data)
> and cricket::SctpDataContentDescription (used for SCTP only).
>
> SctpDataContentDescription no longer inherits from
> MediaContentDescriptionImpl, and no longer contains "codecs".
>
> Due to usage of internal interfaces by consumers, shimming the old
> DataContentDescription API is needed.
>
> A new cricket::DataContentDescription class is defined, which is
> a shim over RtpDataContentDescription and SctpDataContentDescription.
> It exposes as little functionality as possible, but supports the
> concerned consumer's usage
>
> Design document:
> https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
>
> Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
>
> Bug: webrtc:10358
> Change-Id: Icf95fb7308244d6f2ebfdb403aaffc544e358580
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133900
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27853}
TBR=danilchap@webrtc.org,steveanton@webrtc.org,kwiberg@webrtc.org,hbos@webrtc.org,hta@webrtc.org,shampson@webrtc.org
Change-Id: Ibc16ba14c1cbf50345a9b79151b79df140482539
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10358
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135280
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27855}
(substantial changes since version 1)
This CL splits the cricket::DataContentDescription class into
two classes: cricket::RtpDataContentDescription (used for RTP data)
and cricket::SctpDataContentDescription (used for SCTP only).
SctpDataContentDescription no longer inherits from
MediaContentDescriptionImpl, and no longer contains "codecs".
Due to usage of internal interfaces by consumers, shimming the old
DataContentDescription API is needed.
A new cricket::DataContentDescription class is defined, which is
a shim over RtpDataContentDescription and SctpDataContentDescription.
It exposes as little functionality as possible, but supports the
concerned consumer's usage
Design document:
https://docs.google.com/document/d/1H5LfQxJA2ikMWTQ8FZ3_GAmaXM7knfVQWiSz6ph8VQ0/edit#
Version 1 reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132700
Bug: webrtc:10358
Change-Id: Icf95fb7308244d6f2ebfdb403aaffc544e358580
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133900
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27853}
