webrtc_m130/pc/peer_connection_signaling_unittest.cc

1044 lines
41 KiB
C++
Raw Normal View History

/*
* Copyright 2017 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
// This file contains tests that check the PeerConnection's signaling state
// machine, as well as tests that check basic, media-agnostic aspects of SDP.
Use std::make_unique instead of absl::make_unique. WebRTC is now using C++14 so there is no need to use the Abseil version of std::make_unique. This CL has been created with the following steps: git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \ uniq > /tmp/only_make_unique.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/only_make_unique.txt /tmp/memory.txt | \ xargs grep -l "absl/memory" > /tmp/add-memory.txt git grep -l "\babsl::make_unique\b" | \ xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g" git checkout PRESUBMIT.py abseil-in-webrtc.md cat /tmp/add-memory.txt | \ xargs sed -i \ 's/#include "absl\/memory\/memory.h"/#include <memory>/g' git cl format # Manual fix order of the new inserted #include <memory> cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \ xargs sed -i '/#include "absl\/memory\/memory.h"/d' git ls-files | grep BUILD.gn | \ xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d' python tools_webrtc/gn_check_autofix.py \ -m tryserver.webrtc -b linux_rel # Repead the gn_check_autofix step for other platforms git ls-files | grep BUILD.gn | \ xargs sed -i 's/absl\/memory:memory/absl\/memory/g' git cl format Bug: webrtc:10945 Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29209}
2019-09-17 17:06:18 +02:00
#include <memory>
#include <tuple>
#include "api/audio_codecs/builtin_audio_decoder_factory.h"
#include "api/audio_codecs/builtin_audio_encoder_factory.h"
#include "api/create_peerconnection_factory.h"
#include "api/peer_connection_proxy.h"
#include "api/video_codecs/builtin_video_decoder_factory.h"
#include "api/video_codecs/builtin_video_encoder_factory.h"
#include "pc/peer_connection.h"
#include "pc/peer_connection_wrapper.h"
#include "pc/sdp_utils.h"
#ifdef WEBRTC_ANDROID
#include "pc/test/android_test_initializer.h"
#endif
#include "pc/test/fake_audio_capture_module.h"
#include "pc/test/fake_rtc_certificate_generator.h"
#include "rtc_base/gunit.h"
#include "rtc_base/virtual_socket_server.h"
#include "test/gmock.h"
namespace webrtc {
using SignalingState = PeerConnectionInterface::SignalingState;
using RTCConfiguration = PeerConnectionInterface::RTCConfiguration;
using RTCOfferAnswerOptions = PeerConnectionInterface::RTCOfferAnswerOptions;
using ::testing::Bool;
using ::testing::Combine;
using ::testing::Values;
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
namespace {
const int64_t kWaitTimeout = 10000;
} // namespace
class PeerConnectionWrapperForSignalingTest : public PeerConnectionWrapper {
public:
using PeerConnectionWrapper::PeerConnectionWrapper;
bool initial_offerer() {
return GetInternalPeerConnection()->initial_offerer();
}
PeerConnection* GetInternalPeerConnection() {
auto* pci =
static_cast<PeerConnectionProxyWithInternal<PeerConnectionInterface>*>(
pc());
return static_cast<PeerConnection*>(pci->internal());
}
};
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
class ExecuteFunctionOnCreateSessionDescriptionObserver
: public CreateSessionDescriptionObserver {
public:
ExecuteFunctionOnCreateSessionDescriptionObserver(
std::function<void(SessionDescriptionInterface*)> function)
: function_(std::move(function)) {}
~ExecuteFunctionOnCreateSessionDescriptionObserver() override {
RTC_DCHECK(was_called_);
}
bool was_called() const { return was_called_; }
void OnSuccess(SessionDescriptionInterface* desc) override {
RTC_DCHECK(!was_called_);
was_called_ = true;
function_(desc);
}
void OnFailure(RTCError error) override { RTC_NOTREACHED(); }
private:
bool was_called_ = false;
std::function<void(SessionDescriptionInterface*)> function_;
};
class PeerConnectionSignalingBaseTest : public ::testing::Test {
protected:
typedef std::unique_ptr<PeerConnectionWrapperForSignalingTest> WrapperPtr;
explicit PeerConnectionSignalingBaseTest(SdpSemantics sdp_semantics)
: vss_(new rtc::VirtualSocketServer()),
main_(vss_.get()),
sdp_semantics_(sdp_semantics) {
#ifdef WEBRTC_ANDROID
InitializeAndroidObjects();
#endif
pc_factory_ = CreatePeerConnectionFactory(
rtc::Thread::Current(), rtc::Thread::Current(), rtc::Thread::Current(),
rtc::scoped_refptr<AudioDeviceModule>(FakeAudioCaptureModule::Create()),
CreateBuiltinAudioEncoderFactory(), CreateBuiltinAudioDecoderFactory(),
CreateBuiltinVideoEncoderFactory(), CreateBuiltinVideoDecoderFactory(),
nullptr /* audio_mixer */, nullptr /* audio_processing */);
}
WrapperPtr CreatePeerConnection() {
return CreatePeerConnection(RTCConfiguration());
}
WrapperPtr CreatePeerConnection(const RTCConfiguration& config) {
Use std::make_unique instead of absl::make_unique. WebRTC is now using C++14 so there is no need to use the Abseil version of std::make_unique. This CL has been created with the following steps: git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \ uniq > /tmp/only_make_unique.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/only_make_unique.txt /tmp/memory.txt | \ xargs grep -l "absl/memory" > /tmp/add-memory.txt git grep -l "\babsl::make_unique\b" | \ xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g" git checkout PRESUBMIT.py abseil-in-webrtc.md cat /tmp/add-memory.txt | \ xargs sed -i \ 's/#include "absl\/memory\/memory.h"/#include <memory>/g' git cl format # Manual fix order of the new inserted #include <memory> cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \ xargs sed -i '/#include "absl\/memory\/memory.h"/d' git ls-files | grep BUILD.gn | \ xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d' python tools_webrtc/gn_check_autofix.py \ -m tryserver.webrtc -b linux_rel # Repead the gn_check_autofix step for other platforms git ls-files | grep BUILD.gn | \ xargs sed -i 's/absl\/memory:memory/absl\/memory/g' git cl format Bug: webrtc:10945 Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29209}
2019-09-17 17:06:18 +02:00
auto observer = std::make_unique<MockPeerConnectionObserver>();
RTCConfiguration modified_config = config;
modified_config.sdp_semantics = sdp_semantics_;
auto pc = pc_factory_->CreatePeerConnection(modified_config, nullptr,
nullptr, observer.get());
if (!pc) {
return nullptr;
}
observer->SetPeerConnectionInterface(pc.get());
Use std::make_unique instead of absl::make_unique. WebRTC is now using C++14 so there is no need to use the Abseil version of std::make_unique. This CL has been created with the following steps: git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \ uniq > /tmp/only_make_unique.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/only_make_unique.txt /tmp/memory.txt | \ xargs grep -l "absl/memory" > /tmp/add-memory.txt git grep -l "\babsl::make_unique\b" | \ xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g" git checkout PRESUBMIT.py abseil-in-webrtc.md cat /tmp/add-memory.txt | \ xargs sed -i \ 's/#include "absl\/memory\/memory.h"/#include <memory>/g' git cl format # Manual fix order of the new inserted #include <memory> cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \ xargs sed -i '/#include "absl\/memory\/memory.h"/d' git ls-files | grep BUILD.gn | \ xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d' python tools_webrtc/gn_check_autofix.py \ -m tryserver.webrtc -b linux_rel # Repead the gn_check_autofix step for other platforms git ls-files | grep BUILD.gn | \ xargs sed -i 's/absl\/memory:memory/absl\/memory/g' git cl format Bug: webrtc:10945 Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29209}
2019-09-17 17:06:18 +02:00
return std::make_unique<PeerConnectionWrapperForSignalingTest>(
pc_factory_, pc, std::move(observer));
}
// Accepts the same arguments as CreatePeerConnection and adds default audio
// and video tracks.
template <typename... Args>
WrapperPtr CreatePeerConnectionWithAudioVideo(Args&&... args) {
auto wrapper = CreatePeerConnection(std::forward<Args>(args)...);
if (!wrapper) {
return nullptr;
}
wrapper->AddAudioTrack("a");
wrapper->AddVideoTrack("v");
return wrapper;
}
int NumberOfDtlsTransports(const WrapperPtr& pc_wrapper) {
std::set<DtlsTransportInterface*> transports;
auto transceivers = pc_wrapper->pc()->GetTransceivers();
for (auto& transceiver : transceivers) {
if (transceiver->sender()->dtls_transport()) {
EXPECT_TRUE(transceiver->receiver()->dtls_transport());
EXPECT_EQ(transceiver->sender()->dtls_transport().get(),
transceiver->receiver()->dtls_transport().get());
transports.insert(transceiver->sender()->dtls_transport().get());
} else {
// If one transceiver is missing, they all should be.
EXPECT_EQ(0UL, transports.size());
}
}
return transports.size();
}
bool HasDtlsTransport(const WrapperPtr& pc_wrapper) {
return NumberOfDtlsTransports(pc_wrapper) > 0;
}
std::unique_ptr<rtc::VirtualSocketServer> vss_;
rtc::AutoSocketServerThread main_;
rtc::scoped_refptr<PeerConnectionFactoryInterface> pc_factory_;
const SdpSemantics sdp_semantics_;
};
class PeerConnectionSignalingTest
: public PeerConnectionSignalingBaseTest,
public ::testing::WithParamInterface<SdpSemantics> {
protected:
PeerConnectionSignalingTest() : PeerConnectionSignalingBaseTest(GetParam()) {}
};
TEST_P(PeerConnectionSignalingTest, SetLocalOfferTwiceWorks) {
auto caller = CreatePeerConnection();
EXPECT_TRUE(caller->SetLocalDescription(caller->CreateOffer()));
EXPECT_TRUE(caller->SetLocalDescription(caller->CreateOffer()));
}
TEST_P(PeerConnectionSignalingTest, SetRemoteOfferTwiceWorks) {
auto caller = CreatePeerConnection();
auto callee = CreatePeerConnection();
EXPECT_TRUE(callee->SetRemoteDescription(caller->CreateOffer()));
EXPECT_TRUE(callee->SetRemoteDescription(caller->CreateOffer()));
}
TEST_P(PeerConnectionSignalingTest, FailToSetNullLocalDescription) {
auto caller = CreatePeerConnection();
std::string error;
ASSERT_FALSE(caller->SetLocalDescription(nullptr, &error));
EXPECT_EQ("SessionDescription is NULL.", error);
}
TEST_P(PeerConnectionSignalingTest, FailToSetNullRemoteDescription) {
auto caller = CreatePeerConnection();
std::string error;
ASSERT_FALSE(caller->SetRemoteDescription(nullptr, &error));
EXPECT_EQ("SessionDescription is NULL.", error);
}
// The following parameterized test verifies that calls to various signaling
// methods on PeerConnection will succeed/fail depending on what is the
// PeerConnection's signaling state. Note that the test tries many different
// forms of SignalingState::kClosed by arriving at a valid state then calling
// |Close()|. This is intended to catch cases where the PeerConnection signaling
// method ignores the closed flag but may work/not work because of the single
// state the PeerConnection was created in before it was closed.
class PeerConnectionSignalingStateTest
: public PeerConnectionSignalingBaseTest,
public ::testing::WithParamInterface<
std::tuple<SdpSemantics, SignalingState, bool>> {
protected:
PeerConnectionSignalingStateTest()
: PeerConnectionSignalingBaseTest(std::get<0>(GetParam())),
state_under_test_(std::make_tuple(std::get<1>(GetParam()),
std::get<2>(GetParam()))) {}
RTCConfiguration GetConfig() {
RTCConfiguration config;
config.certificates.push_back(
FakeRTCCertificateGenerator::GenerateCertificate());
return config;
}
WrapperPtr CreatePeerConnectionUnderTest() {
return CreatePeerConnectionInState(state_under_test_);
}
WrapperPtr CreatePeerConnectionInState(SignalingState state) {
return CreatePeerConnectionInState(std::make_tuple(state, false));
}
WrapperPtr CreatePeerConnectionInState(
std::tuple<SignalingState, bool> state_tuple) {
SignalingState state = std::get<0>(state_tuple);
bool closed = std::get<1>(state_tuple);
auto wrapper = CreatePeerConnectionWithAudioVideo(GetConfig());
switch (state) {
case SignalingState::kStable: {
break;
}
case SignalingState::kHaveLocalOffer: {
wrapper->SetLocalDescription(wrapper->CreateOffer());
break;
}
case SignalingState::kHaveLocalPrAnswer: {
auto caller = CreatePeerConnectionWithAudioVideo(GetConfig());
wrapper->SetRemoteDescription(caller->CreateOffer());
auto answer = wrapper->CreateAnswer();
wrapper->SetLocalDescription(
CloneSessionDescriptionAsType(answer.get(), SdpType::kPrAnswer));
break;
}
case SignalingState::kHaveRemoteOffer: {
auto caller = CreatePeerConnectionWithAudioVideo(GetConfig());
wrapper->SetRemoteDescription(caller->CreateOffer());
break;
}
case SignalingState::kHaveRemotePrAnswer: {
auto callee = CreatePeerConnectionWithAudioVideo(GetConfig());
callee->SetRemoteDescription(wrapper->CreateOfferAndSetAsLocal());
auto answer = callee->CreateAnswer();
wrapper->SetRemoteDescription(
CloneSessionDescriptionAsType(answer.get(), SdpType::kPrAnswer));
break;
}
case SignalingState::kClosed: {
RTC_NOTREACHED() << "Set the second member of the tuple to true to "
"achieve a closed state from an existing, valid "
"state.";
}
}
RTC_DCHECK_EQ(state, wrapper->pc()->signaling_state());
if (closed) {
wrapper->pc()->Close();
RTC_DCHECK_EQ(SignalingState::kClosed, wrapper->signaling_state());
}
return wrapper;
}
std::tuple<SignalingState, bool> state_under_test_;
};
TEST_P(PeerConnectionSignalingStateTest, CreateOffer) {
auto wrapper = CreatePeerConnectionUnderTest();
if (wrapper->signaling_state() != SignalingState::kClosed) {
EXPECT_TRUE(wrapper->CreateOffer());
} else {
std::string error;
ASSERT_FALSE(wrapper->CreateOffer(RTCOfferAnswerOptions(), &error));
EXPECT_PRED_FORMAT2(AssertStartsWith, error,
"CreateOffer called when PeerConnection is closed.");
}
}
TEST_P(PeerConnectionSignalingStateTest, CreateAnswer) {
auto wrapper = CreatePeerConnectionUnderTest();
if (wrapper->signaling_state() == SignalingState::kHaveLocalPrAnswer ||
wrapper->signaling_state() == SignalingState::kHaveRemoteOffer) {
EXPECT_TRUE(wrapper->CreateAnswer());
} else {
std::string error;
ASSERT_FALSE(wrapper->CreateAnswer(RTCOfferAnswerOptions(), &error));
EXPECT_EQ(error,
"PeerConnection cannot create an answer in a state other than "
"have-remote-offer or have-local-pranswer.");
}
}
TEST_P(PeerConnectionSignalingStateTest, SetLocalOffer) {
auto wrapper = CreatePeerConnectionUnderTest();
if (wrapper->signaling_state() == SignalingState::kStable ||
wrapper->signaling_state() == SignalingState::kHaveLocalOffer) {
// Need to call CreateOffer on the PeerConnection under test, otherwise when
// setting the local offer it will want to verify the DTLS fingerprint
// against the locally generated certificate, but without a call to
// CreateOffer the certificate will never be generated.
EXPECT_TRUE(wrapper->SetLocalDescription(wrapper->CreateOffer()));
} else {
auto wrapper_for_offer =
CreatePeerConnectionInState(SignalingState::kHaveLocalOffer);
auto offer =
CloneSessionDescription(wrapper_for_offer->pc()->local_description());
std::string error;
ASSERT_FALSE(wrapper->SetLocalDescription(std::move(offer), &error));
EXPECT_PRED_FORMAT2(
AssertStartsWith, error,
"Failed to set local offer sdp: Called in wrong state:");
}
}
TEST_P(PeerConnectionSignalingStateTest, SetLocalPrAnswer) {
auto wrapper_for_pranswer =
CreatePeerConnectionInState(SignalingState::kHaveLocalPrAnswer);
auto pranswer =
CloneSessionDescription(wrapper_for_pranswer->pc()->local_description());
auto wrapper = CreatePeerConnectionUnderTest();
if (wrapper->signaling_state() == SignalingState::kHaveLocalPrAnswer ||
wrapper->signaling_state() == SignalingState::kHaveRemoteOffer) {
EXPECT_TRUE(wrapper->SetLocalDescription(std::move(pranswer)));
} else {
std::string error;
ASSERT_FALSE(wrapper->SetLocalDescription(std::move(pranswer), &error));
EXPECT_PRED_FORMAT2(
AssertStartsWith, error,
"Failed to set local pranswer sdp: Called in wrong state:");
}
}
TEST_P(PeerConnectionSignalingStateTest, SetLocalAnswer) {
auto wrapper_for_answer =
CreatePeerConnectionInState(SignalingState::kHaveRemoteOffer);
auto answer = wrapper_for_answer->CreateAnswer();
auto wrapper = CreatePeerConnectionUnderTest();
if (wrapper->signaling_state() == SignalingState::kHaveLocalPrAnswer ||
wrapper->signaling_state() == SignalingState::kHaveRemoteOffer) {
EXPECT_TRUE(wrapper->SetLocalDescription(std::move(answer)));
} else {
std::string error;
ASSERT_FALSE(wrapper->SetLocalDescription(std::move(answer), &error));
EXPECT_PRED_FORMAT2(
AssertStartsWith, error,
"Failed to set local answer sdp: Called in wrong state:");
}
}
TEST_P(PeerConnectionSignalingStateTest, SetRemoteOffer) {
auto wrapper_for_offer =
CreatePeerConnectionInState(SignalingState::kHaveRemoteOffer);
auto offer =
CloneSessionDescription(wrapper_for_offer->pc()->remote_description());
auto wrapper = CreatePeerConnectionUnderTest();
if (wrapper->signaling_state() == SignalingState::kStable ||
wrapper->signaling_state() == SignalingState::kHaveRemoteOffer) {
EXPECT_TRUE(wrapper->SetRemoteDescription(std::move(offer)));
} else {
std::string error;
ASSERT_FALSE(wrapper->SetRemoteDescription(std::move(offer), &error));
EXPECT_PRED_FORMAT2(
AssertStartsWith, error,
"Failed to set remote offer sdp: Called in wrong state:");
}
}
TEST_P(PeerConnectionSignalingStateTest, SetRemotePrAnswer) {
auto wrapper_for_pranswer =
CreatePeerConnectionInState(SignalingState::kHaveRemotePrAnswer);
auto pranswer =
CloneSessionDescription(wrapper_for_pranswer->pc()->remote_description());
auto wrapper = CreatePeerConnectionUnderTest();
if (wrapper->signaling_state() == SignalingState::kHaveLocalOffer ||
wrapper->signaling_state() == SignalingState::kHaveRemotePrAnswer) {
EXPECT_TRUE(wrapper->SetRemoteDescription(std::move(pranswer)));
} else {
std::string error;
ASSERT_FALSE(wrapper->SetRemoteDescription(std::move(pranswer), &error));
EXPECT_PRED_FORMAT2(
AssertStartsWith, error,
"Failed to set remote pranswer sdp: Called in wrong state:");
}
}
TEST_P(PeerConnectionSignalingStateTest, SetRemoteAnswer) {
auto wrapper_for_answer =
CreatePeerConnectionInState(SignalingState::kHaveRemoteOffer);
auto answer = wrapper_for_answer->CreateAnswer();
auto wrapper = CreatePeerConnectionUnderTest();
if (wrapper->signaling_state() == SignalingState::kHaveLocalOffer ||
wrapper->signaling_state() == SignalingState::kHaveRemotePrAnswer) {
EXPECT_TRUE(wrapper->SetRemoteDescription(std::move(answer)));
} else {
std::string error;
ASSERT_FALSE(wrapper->SetRemoteDescription(std::move(answer), &error));
EXPECT_PRED_FORMAT2(
AssertStartsWith, error,
"Failed to set remote answer sdp: Called in wrong state:");
}
}
INSTANTIATE_TEST_SUITE_P(PeerConnectionSignalingTest,
PeerConnectionSignalingStateTest,
Combine(Values(SdpSemantics::kPlanB,
SdpSemantics::kUnifiedPlan),
Values(SignalingState::kStable,
SignalingState::kHaveLocalOffer,
SignalingState::kHaveLocalPrAnswer,
SignalingState::kHaveRemoteOffer,
SignalingState::kHaveRemotePrAnswer),
Bool()));
// Test that CreateAnswer fails if a round of offer/answer has been done and
// the PeerConnection is in the stable state.
TEST_P(PeerConnectionSignalingTest, CreateAnswerFailsIfStable) {
auto caller = CreatePeerConnection();
auto callee = CreatePeerConnection();
ASSERT_TRUE(caller->ExchangeOfferAnswerWith(callee.get()));
Revert "Reland "Parameterize PeerConnection signaling tests for Unified Plan"" This reverts commit 7b581eb1cab0b2ccd0a2d60163bb2b73c244346a. Reason for revert: Breaks downstream projects Original change's description: > Reland "Parameterize PeerConnection signaling tests for Unified Plan" > > Original change's description: > > Parameterize PeerConnection signaling tests for Unified Plan > > > > This also changes the behavior of CreateAnswer to fail unless > > the signaling state is kHaveRemoteOffer or kHaveLocalPranswer, > > as per the WebRTC specification. > > > > Bug: webrtc:8765 > > Change-Id: I60ac67cd92b17fcbff964afc14d049481e816a28 > > Reviewed-on: https://webrtc-review.googlesource.com/41042 > > Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> > > Commit-Queue: Steve Anton <steveanton@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#21779} > > Bug: webrtc:8813 > Change-Id: I9f608fcd0b7aca00b4c1092e271dbd9cd710c38a > Reviewed-on: https://webrtc-review.googlesource.com/46861 > Commit-Queue: Steve Anton <steveanton@webrtc.org> > Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> > Reviewed-by: Steve Anton <steveanton@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#21860} TBR=steveanton@webrtc.org,deadbeef@webrtc.org,pthatcher@webrtc.org Change-Id: I15490e4db3290a8ab6056cf82959be7a97e6b1c3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:8813 Reviewed-on: https://webrtc-review.googlesource.com/47340 Reviewed-by: Oleh Prypin <oprypin@webrtc.org> Commit-Queue: Oleh Prypin <oprypin@webrtc.org> Cr-Commit-Position: refs/heads/master@{#21865}
2018-02-02 08:42:18 +00:00
ASSERT_EQ(SignalingState::kStable, caller->signaling_state());
EXPECT_FALSE(caller->CreateAnswer());
ASSERT_EQ(SignalingState::kStable, callee->signaling_state());
EXPECT_FALSE(callee->CreateAnswer());
}
// According to https://tools.ietf.org/html/rfc3264#section-8, the session id
// stays the same but the version must be incremented if a later, different
// session description is generated. These two tests verify that is the case for
// both offers and answers.
TEST_P(PeerConnectionSignalingTest,
SessionVersionIncrementedInSubsequentDifferentOffer) {
auto caller = CreatePeerConnection();
auto callee = CreatePeerConnection();
auto original_offer = caller->CreateOfferAndSetAsLocal();
const std::string original_id = original_offer->session_id();
const std::string original_version = original_offer->session_version();
ASSERT_TRUE(callee->SetRemoteDescription(std::move(original_offer)));
ASSERT_TRUE(caller->SetRemoteDescription(callee->CreateAnswer()));
// Add track to get a different offer.
caller->AddAudioTrack("a");
auto later_offer = caller->CreateOffer();
EXPECT_EQ(original_id, later_offer->session_id());
EXPECT_LT(rtc::FromString<uint64_t>(original_version),
rtc::FromString<uint64_t>(later_offer->session_version()));
}
TEST_P(PeerConnectionSignalingTest,
SessionVersionIncrementedInSubsequentDifferentAnswer) {
auto caller = CreatePeerConnection();
auto callee = CreatePeerConnection();
ASSERT_TRUE(callee->SetRemoteDescription(caller->CreateOfferAndSetAsLocal()));
auto original_answer = callee->CreateAnswer();
const std::string original_id = original_answer->session_id();
const std::string original_version = original_answer->session_version();
// Add track to get a different answer.
callee->AddAudioTrack("a");
auto later_answer = callee->CreateAnswer();
EXPECT_EQ(original_id, later_answer->session_id());
EXPECT_LT(rtc::FromString<uint64_t>(original_version),
rtc::FromString<uint64_t>(later_answer->session_version()));
}
TEST_P(PeerConnectionSignalingTest, InitiatorFlagSetOnCallerAndNotOnCallee) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto callee = CreatePeerConnectionWithAudioVideo();
EXPECT_FALSE(caller->initial_offerer());
EXPECT_FALSE(callee->initial_offerer());
ASSERT_TRUE(callee->SetRemoteDescription(caller->CreateOfferAndSetAsLocal()));
EXPECT_TRUE(caller->initial_offerer());
EXPECT_FALSE(callee->initial_offerer());
ASSERT_TRUE(
caller->SetRemoteDescription(callee->CreateAnswerAndSetAsLocal()));
EXPECT_TRUE(caller->initial_offerer());
EXPECT_FALSE(callee->initial_offerer());
}
// Test creating a PeerConnection, request multiple offers, destroy the
// PeerConnection and make sure we get success/failure callbacks for all of the
// requests.
// Background: crbug.com/507307
TEST_P(PeerConnectionSignalingTest, CreateOffersAndShutdown) {
auto caller = CreatePeerConnection();
RTCOfferAnswerOptions options;
options.offer_to_receive_audio =
RTCOfferAnswerOptions::kOfferToReceiveMediaTrue;
rtc::scoped_refptr<MockCreateSessionDescriptionObserver> observers[100];
for (auto& observer : observers) {
observer =
new rtc::RefCountedObject<MockCreateSessionDescriptionObserver>();
caller->pc()->CreateOffer(observer, options);
}
// Destroy the PeerConnection.
caller.reset(nullptr);
for (auto& observer : observers) {
// We expect to have received a notification now even if the PeerConnection
// was terminated. The offer creation may or may not have succeeded, but we
// must have received a notification.
EXPECT_TRUE(observer->called());
}
}
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
// Similar to the above test, but by closing the PC first the CreateOffer() will
// fail "early", which triggers a codepath where the PeerConnection is
// reponsible for invoking the observer, instead of the normal codepath where
// the WebRtcSessionDescriptionFactory is responsible for it.
TEST_P(PeerConnectionSignalingTest, CloseCreateOfferAndShutdown) {
auto caller = CreatePeerConnection();
rtc::scoped_refptr<MockCreateSessionDescriptionObserver> observer =
new rtc::RefCountedObject<MockCreateSessionDescriptionObserver>();
caller->pc()->Close();
caller->pc()->CreateOffer(observer, RTCOfferAnswerOptions());
caller.reset(nullptr);
EXPECT_TRUE(observer->called());
}
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
TEST_P(PeerConnectionSignalingTest,
ImplicitCreateOfferAndShutdownWithOldObserver) {
[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}
2020-07-28 10:39:36 +02:00
auto caller = CreatePeerConnection();
auto observer = MockSetSessionDescriptionObserver::Create();
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
caller->pc()->SetLocalDescription(observer.get());
caller.reset(nullptr);
// The old observer does not get invoked because posted messages are lost.
EXPECT_FALSE(observer->called());
}
TEST_P(PeerConnectionSignalingTest, ImplicitCreateOfferAndShutdown) {
auto caller = CreatePeerConnection();
rtc::scoped_refptr<FakeSetLocalDescriptionObserver> observer(
new FakeSetLocalDescriptionObserver());
Revert "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 09:46:40 +00:00
caller->pc()->SetLocalDescription(observer);
[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}
2020-07-28 10:39:36 +02:00
caller.reset(nullptr);
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
// The new observer gets invoked because it is called immediately.
EXPECT_TRUE(observer->called());
EXPECT_FALSE(observer->error().ok());
}
TEST_P(PeerConnectionSignalingTest,
CloseBeforeImplicitCreateOfferAndShutdownWithOldObserver) {
auto caller = CreatePeerConnection();
auto observer = MockSetSessionDescriptionObserver::Create();
caller->pc()->Close();
caller->pc()->SetLocalDescription(observer.get());
caller.reset(nullptr);
// The old observer does not get invoked because posted messages are lost.
EXPECT_FALSE(observer->called());
}
TEST_P(PeerConnectionSignalingTest, CloseBeforeImplicitCreateOfferAndShutdown) {
auto caller = CreatePeerConnection();
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
rtc::scoped_refptr<FakeSetLocalDescriptionObserver> observer(
new FakeSetLocalDescriptionObserver());
[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}
2020-07-28 10:39:36 +02:00
caller->pc()->Close();
Revert "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 09:46:40 +00:00
caller->pc()->SetLocalDescription(observer);
[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}
2020-07-28 10:39:36 +02:00
caller.reset(nullptr);
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
// The new observer gets invoked because it is called immediately.
EXPECT_TRUE(observer->called());
EXPECT_FALSE(observer->error().ok());
}
TEST_P(PeerConnectionSignalingTest,
CloseAfterImplicitCreateOfferAndShutdownWithOldObserver) {
auto caller = CreatePeerConnection();
auto observer = MockSetSessionDescriptionObserver::Create();
caller->pc()->SetLocalDescription(observer.get());
caller->pc()->Close();
caller.reset(nullptr);
// The old observer does not get invoked because posted messages are lost.
EXPECT_FALSE(observer->called());
}
TEST_P(PeerConnectionSignalingTest, CloseAfterImplicitCreateOfferAndShutdown) {
auto caller = CreatePeerConnection();
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
rtc::scoped_refptr<FakeSetLocalDescriptionObserver> observer(
new FakeSetLocalDescriptionObserver());
caller->pc()->SetLocalDescription(observer);
caller->pc()->Close();
caller.reset(nullptr);
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
// The new observer gets invoked because it is called immediately.
EXPECT_TRUE(observer->called());
EXPECT_FALSE(observer->error().ok());
}
TEST_P(PeerConnectionSignalingTest,
SetLocalDescriptionNewObserverIsInvokedImmediately) {
auto caller = CreatePeerConnection();
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
rtc::scoped_refptr<FakeSetLocalDescriptionObserver> observer(
new FakeSetLocalDescriptionObserver());
caller->pc()->SetLocalDescription(std::move(offer), observer);
// The new observer is invoked immediately.
EXPECT_TRUE(observer->called());
EXPECT_TRUE(observer->error().ok());
}
TEST_P(PeerConnectionSignalingTest,
SetLocalDescriptionOldObserverIsInvokedInAPostedMessage) {
auto caller = CreatePeerConnection();
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
auto observer = MockSetSessionDescriptionObserver::Create();
caller->pc()->SetLocalDescription(observer, offer.release());
// The old observer is not invoked immediately.
EXPECT_FALSE(observer->called());
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
// Process all currently pending messages by waiting for a posted task to run.
bool checkpoint_reached = false;
rtc::Thread::Current()->PostTask(
RTC_FROM_HERE, [&checkpoint_reached] { checkpoint_reached = true; });
EXPECT_TRUE_WAIT(checkpoint_reached, kWaitTimeout);
// If resolving the observer was pending, it must now have been called.
EXPECT_TRUE(observer->called());
}
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
TEST_P(PeerConnectionSignalingTest, SetRemoteDescriptionExecutesImmediately) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto callee = CreatePeerConnection();
// This offer will cause receivers to be created.
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
// By not waiting for the observer's callback we can verify that the operation
// executed immediately.
callee->pc()->SetRemoteDescription(std::move(offer),
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
new FakeSetRemoteDescriptionObserver());
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
EXPECT_EQ(2u, callee->pc()->GetReceivers().size());
}
TEST_P(PeerConnectionSignalingTest, CreateOfferBlocksSetRemoteDescription) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto callee = CreatePeerConnection();
// This offer will cause receivers to be created.
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
EXPECT_EQ(0u, callee->pc()->GetReceivers().size());
rtc::scoped_refptr<MockCreateSessionDescriptionObserver> offer_observer(
new rtc::RefCountedObject<MockCreateSessionDescriptionObserver>());
// Synchronously invoke CreateOffer() and SetRemoteDescription(). The
// SetRemoteDescription() operation should be chained to be executed
// asynchronously, when CreateOffer() completes.
callee->pc()->CreateOffer(offer_observer, RTCOfferAnswerOptions());
callee->pc()->SetRemoteDescription(std::move(offer),
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
new FakeSetRemoteDescriptionObserver());
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
// CreateOffer() is asynchronous; without message processing this operation
// should not have completed.
EXPECT_FALSE(offer_observer->called());
// Due to chaining, the receivers should not have been created by the offer
// yet.
EXPECT_EQ(0u, callee->pc()->GetReceivers().size());
// EXPECT_TRUE_WAIT causes messages to be processed...
EXPECT_TRUE_WAIT(offer_observer->called(), kWaitTimeout);
// Now that the offer has been completed, SetRemoteDescription() will have
// been executed next in the chain.
EXPECT_EQ(2u, callee->pc()->GetReceivers().size());
}
TEST_P(PeerConnectionSignalingTest,
ParameterlessSetLocalDescriptionCreatesOffer) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto observer = MockSetSessionDescriptionObserver::Create();
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
caller->pc()->SetLocalDescription(observer.get());
// The offer is created asynchronously; message processing is needed for it to
// complete.
EXPECT_FALSE(observer->called());
EXPECT_FALSE(caller->pc()->pending_local_description());
EXPECT_EQ(PeerConnection::kStable, caller->signaling_state());
// Wait for messages to be processed.
EXPECT_TRUE_WAIT(observer->called(), kWaitTimeout);
EXPECT_TRUE(observer->result());
EXPECT_TRUE(caller->pc()->pending_local_description());
EXPECT_EQ(SdpType::kOffer,
caller->pc()->pending_local_description()->GetType());
EXPECT_EQ(PeerConnection::kHaveLocalOffer, caller->signaling_state());
}
TEST_P(PeerConnectionSignalingTest,
ParameterlessSetLocalDescriptionCreatesAnswer) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto callee = CreatePeerConnectionWithAudioVideo();
callee->SetRemoteDescription(caller->CreateOffer());
EXPECT_EQ(PeerConnection::kHaveRemoteOffer, callee->signaling_state());
auto observer = MockSetSessionDescriptionObserver::Create();
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
callee->pc()->SetLocalDescription(observer.get());
// The answer is created asynchronously; message processing is needed for it
// to complete.
EXPECT_FALSE(observer->called());
EXPECT_FALSE(callee->pc()->current_local_description());
// Wait for messages to be processed.
EXPECT_TRUE_WAIT(observer->called(), kWaitTimeout);
EXPECT_TRUE(observer->result());
EXPECT_TRUE(callee->pc()->current_local_description());
EXPECT_EQ(SdpType::kAnswer,
callee->pc()->current_local_description()->GetType());
EXPECT_EQ(PeerConnection::kStable, callee->signaling_state());
}
TEST_P(PeerConnectionSignalingTest,
ParameterlessSetLocalDescriptionFullExchange) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto callee = CreatePeerConnectionWithAudioVideo();
// SetLocalDescription(), implicitly creating an offer.
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
auto caller_set_local_description_observer =
MockSetSessionDescriptionObserver::Create();
caller->pc()->SetLocalDescription(
caller_set_local_description_observer.get());
EXPECT_TRUE_WAIT(caller_set_local_description_observer->called(),
kWaitTimeout);
ASSERT_TRUE(caller->pc()->pending_local_description());
// SetRemoteDescription(offer)
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
auto callee_set_remote_description_observer =
MockSetSessionDescriptionObserver::Create();
callee->pc()->SetRemoteDescription(
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
callee_set_remote_description_observer,
CloneSessionDescription(caller->pc()->pending_local_description())
.release());
// SetLocalDescription(), implicitly creating an answer.
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
auto callee_set_local_description_observer =
MockSetSessionDescriptionObserver::Create();
callee->pc()->SetLocalDescription(
callee_set_local_description_observer.get());
EXPECT_TRUE_WAIT(callee_set_local_description_observer->called(),
kWaitTimeout);
// Chaining guarantees SetRemoteDescription() happened before
// SetLocalDescription().
EXPECT_TRUE(callee_set_remote_description_observer->called());
EXPECT_TRUE(callee->pc()->current_local_description());
// SetRemoteDescription(answer)
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
auto caller_set_remote_description_observer =
MockSetSessionDescriptionObserver::Create();
caller->pc()->SetRemoteDescription(
caller_set_remote_description_observer,
CloneSessionDescription(callee->pc()->current_local_description())
.release());
EXPECT_TRUE_WAIT(caller_set_remote_description_observer->called(),
kWaitTimeout);
EXPECT_EQ(PeerConnection::kStable, caller->signaling_state());
EXPECT_EQ(PeerConnection::kStable, callee->signaling_state());
}
TEST_P(PeerConnectionSignalingTest,
ParameterlessSetLocalDescriptionCloseBeforeCreatingOffer) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto observer = MockSetSessionDescriptionObserver::Create();
caller->pc()->Close();
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
caller->pc()->SetLocalDescription(observer.get());
// The operation should fail asynchronously.
EXPECT_FALSE(observer->called());
EXPECT_TRUE_WAIT(observer->called(), kWaitTimeout);
EXPECT_FALSE(observer->result());
// This did not affect the signaling state.
EXPECT_EQ(PeerConnection::kClosed, caller->pc()->signaling_state());
EXPECT_EQ(
"SetLocalDescription failed to create session description - "
"SetLocalDescription called when PeerConnection is closed.",
observer->error());
}
TEST_P(PeerConnectionSignalingTest,
ParameterlessSetLocalDescriptionCloseWhileCreatingOffer) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto observer = MockSetSessionDescriptionObserver::Create();
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
caller->pc()->SetLocalDescription(observer.get());
caller->pc()->Close();
// The operation should fail asynchronously.
EXPECT_FALSE(observer->called());
EXPECT_TRUE_WAIT(observer->called(), kWaitTimeout);
EXPECT_FALSE(observer->result());
// This did not affect the signaling state.
EXPECT_EQ(PeerConnection::kClosed, caller->pc()->signaling_state());
EXPECT_EQ(
"SetLocalDescription failed to create session description - "
"CreateOffer failed because the session was shut down",
observer->error());
}
INSTANTIATE_TEST_SUITE_P(PeerConnectionSignalingTest,
PeerConnectionSignalingTest,
Values(SdpSemantics::kPlanB,
SdpSemantics::kUnifiedPlan));
class PeerConnectionSignalingUnifiedPlanTest
: public PeerConnectionSignalingBaseTest {
protected:
PeerConnectionSignalingUnifiedPlanTest()
: PeerConnectionSignalingBaseTest(SdpSemantics::kUnifiedPlan) {}
};
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
// We verify that SetLocalDescription() executed immediately by verifying that
// the transceiver mid values got assigned. SLD executing immeditately is not
// unique to Unified Plan, but the transceivers used to verify this are only
// available in Unified Plan.
TEST_F(PeerConnectionSignalingUnifiedPlanTest,
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
SetLocalDescriptionExecutesImmediatelyUsingOldObserver) {
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
auto caller = CreatePeerConnectionWithAudioVideo();
// This offer will cause transceiver mids to get assigned.
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
// By not waiting for the observer's callback we can verify that the operation
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
// executed immediately. The old observer is invoked in a posted message, so
// waiting for it would not ensure synchronicity.
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
RTC_DCHECK(!caller->pc()->GetTransceivers()[0]->mid().has_value());
caller->pc()->SetLocalDescription(
new rtc::RefCountedObject<MockSetSessionDescriptionObserver>(),
offer.release());
EXPECT_TRUE(caller->pc()->GetTransceivers()[0]->mid().has_value());
}
Reland "[Perfect Negotiation] Implement non-racy version of SetLocalDescription." 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}
2020-07-29 12:04:00 +02:00
TEST_F(PeerConnectionSignalingUnifiedPlanTest,
SetLocalDescriptionExecutesImmediatelyUsingNewObserver) {
auto caller = CreatePeerConnectionWithAudioVideo();
// This offer will cause transceiver mids to get assigned.
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
// Verify that mids were assigned without waiting for the observer. (However,
// the new observer should also be invoked synchronously - as is ensured by
// other tests.)
RTC_DCHECK(!caller->pc()->GetTransceivers()[0]->mid().has_value());
caller->pc()->SetLocalDescription(std::move(offer),
new FakeSetLocalDescriptionObserver());
EXPECT_TRUE(caller->pc()->GetTransceivers()[0]->mid().has_value());
}
Reland "[PeerConnection] Use an OperationsChain in PeerConnection for async ops." 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}
2019-10-28 12:09:49 +01:00
TEST_F(PeerConnectionSignalingUnifiedPlanTest,
SetLocalDescriptionExecutesImmediatelyInsideCreateOfferCallback) {
auto caller = CreatePeerConnectionWithAudioVideo();
// This offer will cause transceiver mids to get assigned.
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
rtc::scoped_refptr<ExecuteFunctionOnCreateSessionDescriptionObserver>
offer_observer(new rtc::RefCountedObject<
ExecuteFunctionOnCreateSessionDescriptionObserver>(
[pc = caller->pc()](SessionDescriptionInterface* desc) {
// By not waiting for the observer's callback we can verify that the
// operation executed immediately.
RTC_DCHECK(!pc->GetTransceivers()[0]->mid().has_value());
pc->SetLocalDescription(
new rtc::RefCountedObject<MockSetSessionDescriptionObserver>(),
desc);
EXPECT_TRUE(pc->GetTransceivers()[0]->mid().has_value());
}));
caller->pc()->CreateOffer(offer_observer, RTCOfferAnswerOptions());
EXPECT_TRUE_WAIT(offer_observer->was_called(), kWaitTimeout);
}
// Test that transports are shown in the sender/receiver API after offer/answer.
// This only works in Unified Plan.
TEST_F(PeerConnectionSignalingUnifiedPlanTest,
DtlsTransportsInstantiateInOfferAnswer) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto callee = CreatePeerConnection();
EXPECT_FALSE(HasDtlsTransport(caller));
EXPECT_FALSE(HasDtlsTransport(callee));
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
caller->SetLocalDescription(CloneSessionDescription(offer.get()));
EXPECT_TRUE(HasDtlsTransport(caller));
callee->SetRemoteDescription(std::move(offer));
EXPECT_FALSE(HasDtlsTransport(callee));
auto answer = callee->CreateAnswer(RTCOfferAnswerOptions());
callee->SetLocalDescription(CloneSessionDescription(answer.get()));
EXPECT_TRUE(HasDtlsTransport(callee));
caller->SetRemoteDescription(std::move(answer));
EXPECT_TRUE(HasDtlsTransport(caller));
ASSERT_EQ(SignalingState::kStable, caller->signaling_state());
}
TEST_F(PeerConnectionSignalingUnifiedPlanTest, DtlsTransportsMergeWhenBundled) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto callee = CreatePeerConnection();
EXPECT_FALSE(HasDtlsTransport(caller));
EXPECT_FALSE(HasDtlsTransport(callee));
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
caller->SetLocalDescription(CloneSessionDescription(offer.get()));
EXPECT_EQ(2, NumberOfDtlsTransports(caller));
callee->SetRemoteDescription(std::move(offer));
auto answer = callee->CreateAnswer(RTCOfferAnswerOptions());
callee->SetLocalDescription(CloneSessionDescription(answer.get()));
caller->SetRemoteDescription(std::move(answer));
EXPECT_EQ(1, NumberOfDtlsTransports(caller));
ASSERT_EQ(SignalingState::kStable, caller->signaling_state());
}
TEST_F(PeerConnectionSignalingUnifiedPlanTest,
DtlsTransportsAreSeparateeWhenUnbundled) {
auto caller = CreatePeerConnectionWithAudioVideo();
auto callee = CreatePeerConnection();
EXPECT_FALSE(HasDtlsTransport(caller));
EXPECT_FALSE(HasDtlsTransport(callee));
RTCOfferAnswerOptions unbundle_options;
unbundle_options.use_rtp_mux = false;
auto offer = caller->CreateOffer(unbundle_options);
caller->SetLocalDescription(CloneSessionDescription(offer.get()));
EXPECT_EQ(2, NumberOfDtlsTransports(caller));
callee->SetRemoteDescription(std::move(offer));
auto answer = callee->CreateAnswer(RTCOfferAnswerOptions());
callee->SetLocalDescription(CloneSessionDescription(answer.get()));
EXPECT_EQ(2, NumberOfDtlsTransports(callee));
caller->SetRemoteDescription(std::move(answer));
EXPECT_EQ(2, NumberOfDtlsTransports(caller));
ASSERT_EQ(SignalingState::kStable, caller->signaling_state());
}
TEST_F(PeerConnectionSignalingUnifiedPlanTest,
ShouldFireNegotiationNeededWhenNoChangesArePending) {
auto caller = CreatePeerConnection();
EXPECT_FALSE(caller->observer()->has_negotiation_needed_event());
auto transceiver =
caller->AddTransceiver(cricket::MEDIA_TYPE_AUDIO, RtpTransceiverInit());
EXPECT_TRUE(caller->observer()->has_negotiation_needed_event());
EXPECT_TRUE(caller->pc()->ShouldFireNegotiationNeededEvent(
caller->observer()->latest_negotiation_needed_event()));
}
TEST_F(PeerConnectionSignalingUnifiedPlanTest,
SuppressNegotiationNeededWhenOperationChainIsNotEmpty) {
auto caller = CreatePeerConnection();
EXPECT_FALSE(caller->observer()->has_negotiation_needed_event());
auto transceiver =
caller->AddTransceiver(cricket::MEDIA_TYPE_AUDIO, RtpTransceiverInit());
EXPECT_TRUE(caller->observer()->has_negotiation_needed_event());
rtc::scoped_refptr<MockCreateSessionDescriptionObserver> observer =
new rtc::RefCountedObject<MockCreateSessionDescriptionObserver>();
caller->pc()->CreateOffer(observer, RTCOfferAnswerOptions());
// For this test to work, the operation has to be pending, i.e. the observer
// has not yet been invoked.
EXPECT_FALSE(observer->called());
// Because the Operations Chain is not empty, the event is now suppressed.
EXPECT_FALSE(caller->pc()->ShouldFireNegotiationNeededEvent(
caller->observer()->latest_negotiation_needed_event()));
caller->observer()->clear_latest_negotiation_needed_event();
// When the Operations Chain becomes empty again, a new negotiation needed
// event will be generated that is not suppressed.
EXPECT_TRUE_WAIT(observer->called(), kWaitTimeout);
EXPECT_TRUE(caller->observer()->has_negotiation_needed_event());
EXPECT_TRUE(caller->pc()->ShouldFireNegotiationNeededEvent(
caller->observer()->latest_negotiation_needed_event()));
}
TEST_F(PeerConnectionSignalingUnifiedPlanTest,
SuppressNegotiationNeededWhenSignalingStateIsNotStable) {
auto caller = CreatePeerConnection();
auto callee = CreatePeerConnection();
auto offer = caller->CreateOffer(RTCOfferAnswerOptions());
EXPECT_FALSE(caller->observer()->has_negotiation_needed_event());
auto transceiver =
callee->AddTransceiver(cricket::MEDIA_TYPE_AUDIO, RtpTransceiverInit());
EXPECT_TRUE(callee->observer()->has_negotiation_needed_event());
// Change signaling state (to "have-remote-offer") by setting a remote offer.
callee->SetRemoteDescription(std::move(offer));
// Because the signaling state is not "stable", the event is now suppressed.
EXPECT_FALSE(callee->pc()->ShouldFireNegotiationNeededEvent(
callee->observer()->latest_negotiation_needed_event()));
callee->observer()->clear_latest_negotiation_needed_event();
// Upon rolling back to "stable", a new negotiation needed event will be
// generated that is not suppressed.
callee->SetLocalDescription(CreateSessionDescription(SdpType::kRollback, ""));
EXPECT_TRUE(callee->observer()->has_negotiation_needed_event());
EXPECT_TRUE(callee->pc()->ShouldFireNegotiationNeededEvent(
callee->observer()->latest_negotiation_needed_event()));
}
} // namespace webrtc