What steps will reproduce the problem?
1. In peerconnection_client::conductor.cc OnAddStream, rather than sending an
event to a separate thread, take the code from the NEW_STREAM_ADDED handler in
UIThreadCallback and put it in OnAddStream.
2. Run two clients on the same machine attached to the same server.
3. The connection will fail.
What is the expected output? What do you see instead?
The logging reports the following two errors:
Error(webrtcsession.cc:241): SetLocalDescription called with action in wrong
state, action: 0 state: 2
Error(webrtcsession.cc:141): StartIce called before SetLocalDescription
Digging into it, it appears that roapsignalling.cc in the
ProcessSignalingMessage method has odd behavior. It will call out to
ProcessRemoteDescription which, in turn, will invoke the OnAddStream handler.
If you then call AddStream and CommitStreamChanges while inside this handler
rather than pushing the response out on a seperate thread (as peerconnection
does), the internal state of roapsignalling is invalid.
In the correct case, the state_ variable of RoapSignalling is kNew. In the
incorrect case, the state is kInitializing. This will eventually cause the
offer to be refused.
As there are no other relevant callbacks until the OK ROAP message arrives, it
is unclear how to properly handle the addition of "my" streams when brokering a
connection with "their" streams. I suspect that thread message methodology of
peerconnection sample works only by luck and that there is actually a race
condition here. At the very least the calling logic should handle the usage
pattern I am trying.
What version of the product are you using? On what operating system?
Using Windows 7
Please provide any additional information below.
Original issue reported on code.google.com by shaunk...@gmail.com on 25 Jun 2012 at 6:04
Original issue reported on code.google.com by
shaunk...@gmail.com
on 25 Jun 2012 at 6:04