This is a reland of d4089cae47334a4228b69d6bb23f2e49ebb7496e
with the following fix:
Invoke MaybeStartGathering as the last step of DoSetLocalDescription.
This ensures that candidates and onicegatheringstatechange does not
happen before SLD is resolved. This is important for passing
external/wpt/webrtc/RTCPeerConnection-iceGatheringState.html.
Original change's description:
> [Perfect Negotiation] Implement non-racy version of SetLocalDescription.
>
> BACKGROUND
>
> When SLD is invoked with SetSessionDescriptionObserver, the observer is
> called by posting a message back to the execution thread, delaying the
> call. This delay is "artificial" - it's not necessary; the operation is
> already complete. It's a post from the signaling thread to the signaling
> thread. The rationale for the post was to avoid the observer making
> recursive calls back into the PeerConnection. The problem with this is
> that by the time the observer is called, the PeerConnection could
> already have executed other operations and modified its states.
>
> This causes the referenced bug: one can have a race where SLD is
> resolved "too late" (after a pending SRD is executed) and the signaling
> state observed when SLD resolves doesn't make sense.
>
> When implementing Unified Plan, we fixed similar issues for SRD by
> adding a version that takes SetRemoteDescriptionObserverInterface as
> argument instead of SetSessionDescriptionObserver. The new version did
> not have the delay. The old version had to be kept around not to break
> downstream projects that had dependencies both on he delay and on
> allowing the PC to be destroyed midst-operation without informing its
> observers.
>
> THIS CL
>
> This does the old SRD fix for SLD as well: A new observer interface is
> added, SetLocalDescriptionObserverInterface, and
> PeerConnection::SetLocalDescription() is overloaded. If you call it with
> the old observer, you get the delay, but if you call it with the new
> observer, you don't get a delay.
>
> - SetLocalDescriptionObserverInterface is added.
> - SetLocalDescription is overloaded.
> - The adapter for SetSessionDescriptionObserver that causes the delay
> previously only used for SRD is updated to handle both SLD and SRD.
> - FakeSetLocalDescriptionObserver is added and
> MockSetRemoteDescriptionObserver is renamed "Fake...".
>
> Bug: chromium:1071733
> Change-Id: I920368e648bede481058ac22f5b8794752a220b3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179100
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31798}
TBR=hta@webrtc.org
Bug: chromium:1071733
Change-Id: Ic6e8d96afa1c19604762f373716c08dbfa9d178c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180481
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31804}
This reverts commit d4089cae47334a4228b69d6bb23f2e49ebb7496e.
Reason for revert: Breaks chromium WPT that is timing sensitive to onicegatheringstatechanges.
This CL accidentally moved the MaybeStartGatheringIceCandidates to after completing the SLD call. The fix is to move it back. I'll do that in a re-land.
Original change's description:
> [Perfect Negotiation] Implement non-racy version of SetLocalDescription.
>
> BACKGROUND
>
> When SLD is invoked with SetSessionDescriptionObserver, the observer is
> called by posting a message back to the execution thread, delaying the
> call. This delay is "artificial" - it's not necessary; the operation is
> already complete. It's a post from the signaling thread to the signaling
> thread. The rationale for the post was to avoid the observer making
> recursive calls back into the PeerConnection. The problem with this is
> that by the time the observer is called, the PeerConnection could
> already have executed other operations and modified its states.
>
> This causes the referenced bug: one can have a race where SLD is
> resolved "too late" (after a pending SRD is executed) and the signaling
> state observed when SLD resolves doesn't make sense.
>
> When implementing Unified Plan, we fixed similar issues for SRD by
> adding a version that takes SetRemoteDescriptionObserverInterface as
> argument instead of SetSessionDescriptionObserver. The new version did
> not have the delay. The old version had to be kept around not to break
> downstream projects that had dependencies both on he delay and on
> allowing the PC to be destroyed midst-operation without informing its
> observers.
>
> THIS CL
>
> This does the old SRD fix for SLD as well: A new observer interface is
> added, SetLocalDescriptionObserverInterface, and
> PeerConnection::SetLocalDescription() is overloaded. If you call it with
> the old observer, you get the delay, but if you call it with the new
> observer, you don't get a delay.
>
> - SetLocalDescriptionObserverInterface is added.
> - SetLocalDescription is overloaded.
> - The adapter for SetSessionDescriptionObserver that causes the delay
> previously only used for SRD is updated to handle both SLD and SRD.
> - FakeSetLocalDescriptionObserver is added and
> MockSetRemoteDescriptionObserver is renamed "Fake...".
>
> Bug: chromium:1071733
> Change-Id: I920368e648bede481058ac22f5b8794752a220b3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179100
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31798}
TBR=hbos@webrtc.org,hta@webrtc.org
Change-Id: Ie1e1ecc49f3b1d7a7e230db6d36decbc4cbe8c86
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1071733
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180480
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31802}
BACKGROUND
When SLD is invoked with SetSessionDescriptionObserver, the observer is
called by posting a message back to the execution thread, delaying the
call. This delay is "artificial" - it's not necessary; the operation is
already complete. It's a post from the signaling thread to the signaling
thread. The rationale for the post was to avoid the observer making
recursive calls back into the PeerConnection. The problem with this is
that by the time the observer is called, the PeerConnection could
already have executed other operations and modified its states.
This causes the referenced bug: one can have a race where SLD is
resolved "too late" (after a pending SRD is executed) and the signaling
state observed when SLD resolves doesn't make sense.
When implementing Unified Plan, we fixed similar issues for SRD by
adding a version that takes SetRemoteDescriptionObserverInterface as
argument instead of SetSessionDescriptionObserver. The new version did
not have the delay. The old version had to be kept around not to break
downstream projects that had dependencies both on he delay and on
allowing the PC to be destroyed midst-operation without informing its
observers.
THIS CL
This does the old SRD fix for SLD as well: A new observer interface is
added, SetLocalDescriptionObserverInterface, and
PeerConnection::SetLocalDescription() is overloaded. If you call it with
the old observer, you get the delay, but if you call it with the new
observer, you don't get a delay.
- SetLocalDescriptionObserverInterface is added.
- SetLocalDescription is overloaded.
- The adapter for SetSessionDescriptionObserver that causes the delay
previously only used for SRD is updated to handle both SLD and SRD.
- FakeSetLocalDescriptionObserver is added and
MockSetRemoteDescriptionObserver is renamed "Fake...".
Bug: chromium:1071733
Change-Id: I920368e648bede481058ac22f5b8794752a220b3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179100
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31798}
Done in preparation for some threading changes that would be quite
messy if implemented with the class as-is.
This results in some code duplication, but is preferable to
one class having two completely different modes of operation.
RTP data channels are in the process of being removed anyway,
so the duplicated code won't last forever.
Bug: webrtc:9883
Change-Id: Idfd41a669b56a4bb4819572e4a264a4ffaaba9c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178940
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31691}
This ensures with DCHECK-crashes that we don't accidentally do more
blocking invokes than we think.
Remaining blocking invokes FYI:
- PrepareTransceiverStatsInfos_s_w() does 1 blocking invoke (regardless
of the number of transceivers or channels) to the worker thread. This
is because VoiceMediaChannel, VideoMediaChannel and GetParameters()
execute on the worker thread, and the result of these operations are
needed on the signalling thread.
- pc_->GetCallStats() does 1 blocking invoke to the worker thread.
These two blocking invokes can be merged, reducing the total number of
blocking invokes from 2 to 1, but this CL does not attempt to do that.
I filed https://crbug.com/webrtc/11767 for that.
Bug: webrtc:11716
Change-Id: Iebc2ab350d253fd037211cdd283825b4e5b2d446
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178867
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31670}
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}
This patch fixes a minor bug in the implementation of
surface_ice_candidates_on_ice_transport_type_changed. The existing
implementation correctly handles the surfacing, but accidentally also
set the SetNeedsIceRestartFlag, which made _next_ offer contain
a ice restart.
Modified existing testcase to verify this.
Bug: webrtc:8939
Change-Id: If566e3249296467668627e5941495f6036cbd903
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176127
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31363}
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}
This change adds exposure of a new transceiver method for getting
the total set of supported extensions stored as an attribute,
and their direction. If the direction is kStopped, the extension
is not signalled in Unified Plan SDP negotiation.
Note: SDP negotiation is not modified by this change.
Changes:
- RtpHeaderExtensionCapability gets a new RtpTransceiverDirection,
indicating either kStopped (extension available but not signalled),
or other (extension signalled).
- RtpTransceiver gets the new method as described above. The
default value of the attribute comes from the voice and video
engines as before.
https://chromestatus.com/feature/5680189201711104.
go/rtp-header-extension-ip
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/65YdUi02yZk
Bug: chromium:1051821
Change-Id: I440443b474db5b1cfe8c6b25b6c10a3ff9c21a8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/170235
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30800}
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 CL was generated by running:
git ls-files | grep ".cc" | xargs perl -i -ne 'BEGIN {undef $/}; s/("[\s\n]*<<[\s\n]*")/" "/g; print;'; git cl format
After that I manually edited modules/audio_processing/gain_controller2.cc to preserve its original
formatting.
This primary benefit of this change is a small reduction in binary size.
Bug: None
Change-Id: I689fa7ba9c717c314bb167e5d592c3c4e0871e29
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165961
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30251}
from LS_INFO to LS_VERBOSE.
By default, unit tests run with logging at info level.
A random run today produced more than 70.000 lines of
output. This CL would reduce that by approximately 15.000.
Bug: none
Change-Id: Ie62708cebf109510a2443aa5ab5c4e645ffc6707
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161950
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30077}
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}
