This fixes a race condition where the remote participant could receive the
offer, create & set its answer locally, send it back, and then try to set the
answer before the local set completed. Observed intermittently in loopback
calls when setLocalDescription is intentionally delayed (debugging something
else).
R=henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9249004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5625 4adac7df-926f-26a2-2b94-8c16560cd09d
Also:
- Make PeerConnectionObserver::OnRenegotiationNeeded() pure virtual to avoid
this sort of mistake in the future.
- Sprinkle @Override annotations on some callback definitions that were missing
them.
- Fix a JNI method-signature-lookup typo (s/(V)V/()V/) in PCOJava::OnError()
- Add an explicit ScopedLocalFrameRef to PCOJava::OnError() to match all other
C++-fired callbacks, for consistency.
BUG=2771
R=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6829004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5376 4adac7df-926f-26a2-2b94-8c16560cd09d
Otherwise, the PeerConnection remembers the channel enough to include an
m=application line in its offer SDP, causing connection to chrome to fail, since
apprtc.appspot.com doesn't include an RtpDataChannels:true constraint in its
RTCPeerConnection constructor call.
R=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6729005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5354 4adac7df-926f-26a2-2b94-8c16560cd09d
In r4665 I went a bit crazy with the manual reinterpretation of a pointer to a
jlong (to avoid undefined behavior) but that's what reinterpret_cast<> is for.
So use it directly now.
Added a do-nothing DataChannel to AppRTCDemo to regression test this, since the
only repro I've found of the original bug requires ARM ABI (PeerConnectionTest
on ia32 fails to repro).
BUG=2302
R=henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/5489004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5269 4adac7df-926f-26a2-2b94-8c16560cd09d
- TCPPort::~TCPPort() was leaking incoming_ sockets; now they are deleted.
- PeerConnection::RemoveStream() now removes streams even if the
PeerConnection::IsClosed(). Previously such streams would never get removed.
- Gave MediaStreamTrackInterface a virtual destructor to ensure deletes on base
pointers are dispatched virtually.
- VideoTrack.dispose() delegates to super.dispose() (instead of leaking)
- PeerConnection.dispose() now removes streams before disposing of them.
- MediaStream.dispose() now removes tracks before disposing of them.
- VideoCapturer.dispose() only unowned VideoCapturers (mirroring C++ API)
- AppRTCDemo.disconnectAndExit() now correctly .dispose()s its
VideoSource and PeerConnectionFactory.
- CHECK that Release()d objects are deleted when expected to (i.e. no ref-cycles
or missing .dispose() calls) in the Java API.
- Create & Return webrtc::Traces at factory birth/death to be able to assert
that _all_ threads started during the test are collected by the end.
- Name threads attached to the JVM more informatively for debugging.
- Removed a bunch of unnecessary scoped_refptr instances in
peerconnection_jni.cc whose only job was messing with refcounts.
RISK=P2
TESTED=AppRTCDemo can be ended and restarted just fine instead of crashing on camera unavailability. No more post-app-exit logcat lines. PCTest.java now asserts that all threads are collected before exit.
BUG=2183
R=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2005004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4534 4adac7df-926f-26a2-2b94-8c16560cd09d
