New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 4158 link

Starred by 8 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

With native webrtc, the description in callback argument couldn't be passed into SRD but work for SLD

Project Member Reported by braveyao@webrtc.org, Jan 8 2015

Issue description

What steps will reproduce the problem?
1. In peerconnection_client example conduct.cc, add a second peerconnection as a receiver for a loopback test.
2. After pc2 creates Answer, try to set it to pc1 directly in next step.
3. In OnSuccess() callback, after SLD, try to call SRD with the 'desc' argument passed in the callback

What is the expected result?
The call from pc1 to pc2 is setup successfully and remote video flows.

What do you see instead?
The call is setup successfully but not remote video. No error in the logs.

Please use labels and text to provide additional information.
After investigating into it, it's because that pc1's onAddStreams() callback is unexpectedly triggered by the RECVONLY answer from pc2. The reason is when we call SRD in the onSuccess() callback with the passed-in description argument, some fields get unexpected value, such as the direction in description is RECVONLY, but it gets SENDRECV in the SRD.

 
Project Member

Comment 1 by braveyao@webrtc.org, Jan 8 2015

The workaround is to create a session description from the passed-in argument before SRD as below:
void Conductor::OnSuccess(webrtc::SessionDescriptionInterface* desc) {
  if (loopback_) {
    peer_connection_2_->SetLocalDescription(
      DummySetSessionDescriptionObserver::Create(), desc);

    // We have to create the description explicitly from the argument.
    // Otherwise SRD would cause some unexpected values.
    std::string sdp;
    desc->ToString(&sdp);
    webrtc::SessionDescriptionInterface* session_description(
      webrtc::CreateSessionDescription(desc->type(), sdp));

    peer_connection_->SetRemoteDescription(
      DummySetSessionDescriptionObserver::Create(), session_description);
    return;
  }

  ......

}

It should be a problem that SLD could work, but not SRD, to the same argument.
According the jiay@, "It sounds like a bug where some fields are not populated correctly unless it's serialized and de-serialized."
Project Member

Comment 2 by braveyao@webrtc.org, Jan 9 2015

Cc: braveyao@webrtc.org juberti@webrtc.org
Labels: Area-PeerConnection
Owner: pthatcher@webrtc.org
Status: Untriaged
@peter, please help to arrange.

It's kind of Blocking  issue3872 . (Can't edit the Blocking field after filing the issue...)
Project Member

Comment 3 by pthatcher@webrtc.org, Jan 12 2015

Labels: Mstone-44 EngTriaged
If we can work around it by serializing/deserializing, let's just do that.  
Project Member

Comment 4 by juberti@webrtc.org, Jan 12 2015

Brave, do you understand whether the problem is the fact that you call setRD from the callback? Or the fact that you don't serialize the session description? Try Posting the description to SetRD and see if that fixes it.
Project Member

Comment 5 by braveyao@webrtc.org, Jan 13 2015

Calling setRD from the callback should be no problem, since the serialized description works inside callback.
If I understand you right, I tried below:
void Conductor::OnSuccess(webrtc::SessionDescriptionInterface* desc) {
if (loopback_) {
    peer_connection_2_->SetLocalDescription(
      DummySetSessionDescriptionObserver::Create(), desc);

    main_wnd_->QueueUIThreadCallback(SRD_READY, desc); // Posting desc here and SRD in the Conductor::UIThreadCallback().

    return;
  }
  ......

}
Then there is same problem. So I suppose the problem should still be "the fact that you don't serialize the session description".
Project Member

Comment 6 by juberti@webrtc.org, Feb 1 2016

Status: Available (was: Untriaged)
Project Member

Comment 7 by tnakamura@webrtc.org, Feb 17 2016

Cc: pthatcher@webrtc.org
Labels: -Mstone-44 Mstone-51
Owner: ----
Available == "triaged, but no owner assigned", so I'm moving pthatcher@ to the cc: list and changing the milestone label to M51.
Project Member

Comment 8 by kjellander@webrtc.org, Oct 5 2016

Labels: M-51
Project Member

Comment 9 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 10 by anatolid@webrtc.org, Nov 11 2016

Labels: -Mstone-51 -M-51
Project Member

Comment 11 by sheriffbot@chromium.org, Sep 6

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.


Project Member

Comment 12 by anatolid@webrtc.org, Nov 1

Status: Available (was: Untriaged)
[bulk-edit] Setting status to Available since it's likely that this issue shouldn't be archived yet. Also changing Pri to 3 due to long period of inactivity (indicating low priority).

Sign in to add a comment