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

Issue 677550 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment

webrtc: setRemoteDescriptionOnFailure doesn't show up webrtc-internals if SDP parsing fails

Reported by fi...@appear.in, Dec 29 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce the problem:
1. join appr.tc room with Firefox
2. join appr.tc room with Chrome Canary 57.0.2966.0
3. call gets established

What is the expected behavior?
due to https://bugzilla.mozilla.org/show_bug.cgi?id=1326288 the remote offer SDP is rejected with an operations error. This should show up in chrome://webrtc-internals

What went wrong?
Neither the setRemoteDescription call nor the failure showed up

Did this work before? Yes 

Does this work in other browsers? N/A

Chrome version: 53.0.2785.143  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 16.0 r0
 

Comment 1 by fi...@appear.in, Dec 29 2016

probably something for deadbeef@ assuming you'll deal with the chrome side of the interop issue
Cc: deadbeef@chromium.org
Components: Blink>WebRTC>Tools
Components: -Blink>WebRTC>Tools Blink>WebRTC>Network
Labels: Needs-Milestone

Comment 5 by fi...@appear.in, Jan 4 2017

some failures like https://jsfiddle.net/vy74r1yt/2/ still show up.

Repro fiddle for this failure: https://jsfiddle.net/0cmbwea3/1/

The fiddle might work again in a canary that does has https://bugs.chromium.org/p/webrtc/issues/detail?id=4674#c15 but I think itis still worth investigating why this didn't show up.
Summary: webrtc: setRemoteDescriptionOnFailure doesn't show up webrtc-internals if SDP parsing fails (was: webrtc: setRemoteDescriptionOnFailure doesn't show up webrtc-internals in Canary)
It sounds like, more generally, the issue is that SDP parse failures aren't tracked as "setRemoteDescription" failures. Notice that the code block for "if SDP parsing failed" doesn't do anything with peer_connection_tracker_: https://cs.chromium.org/chromium/src/content/renderer/media/rtc_peer_connection_handler.cc?sq=package:chromium&rcl=1483532378&l=1307

I don't know if this is intentional or not.
Project Member

Comment 7 by bugdroid1@chromium.org, Jan 9 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/36722c63d70844654fc8d04a2aca71729c7365e5

commit 36722c63d70844654fc8d04a2aca71729c7365e5
Author: philipp.hancke <philipp.hancke@googlemail.com>
Date: Mon Jan 09 10:40:30 2017

track SDP parse errors

SDP parse errors were not tracked in chrome://webrtc-internals

BUG= 677550 

Review-Url: https://codereview.chromium.org/2622453002
Cr-Commit-Position: refs/heads/master@{#442228}

[modify] https://crrev.com/36722c63d70844654fc8d04a2aca71729c7365e5/content/renderer/media/rtc_peer_connection_handler.cc

Comment 8 by fi...@appear.in, Jan 9 2017

Micro-test case:
  var pc = new webkitRTCPeerConnection(null);
  pc.setRemoteDescription(new RTCSessionDescription({type: 'offer', sdp: 'blob'}))

should show up both with the SRD call and the failure.

Comment 9 by fi...@appear.in, Jan 9 2017

similarly, when there is an error with addIceCandidate, both addIceCandidate and addIceCandidateOnFailure should show up (and I think I am to blame for this not being true :-))
Components: -Blink>WebRTC>Network Blink>WebRTC>PeerConnection
Owner: deadbeef@chromium.org
Status: Started (was: Unconfirmed)
Technically we should also do the same thing for local descriptions, and it would be nice to have unit tests. I'll take care of that.
Status: Fixed (was: Started)
Just tested, looks fixed.
Labels: -Needs-Milestone M-57

Sign in to add a comment