Closed Bug 1477043 Opened 8 years ago Closed 8 years ago

[wpt-sync] Sync PR 12069 - Implement & ship: RTCPeerConnection.addTransceiver()

Categories

(Core :: WebRTC, enhancement, P4)

enhancement

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

()

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 12069 into mozilla-central (this bug is closed when the sync is complete). PR: https://github.com/web-platform-tests/wpt/pull/12069 Details from upstream follow. Henrik Boström <hbos@chromium.org> wrote: > Implement & ship: RTCPeerConnection.addTransceiver() > > Intent: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yC_UowCRnaY > Spec: https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-addtransceiver > > This method is only supported if sdpSemantics:'unified-plan' is used, > for more information see intent to ship which explains the background. > > In "Unified Plan", this creates a transceiver. Otherwise, this throws an > kInvalidStateError. > > Bug: 777617 > Change-Id: Icb37e4f0934592f0e334a8f07f1dc1f55e2ca8f2 > Reviewed-on: https://chromium-review.googlesource.com/1143478 > WPT-Export-Revision: cfb25b7ac0ba984bcf234cbbfd1ac41b83474040
Component: web-platform-tests → WebRTC
Product: Testing → Core
Ran 2 tests and 56 subtests OK : 2 PASS : 23 FAIL : 33 New tests that have failures or other problems: /webrtc/RTCPeerConnection-transceivers.https.html Can setup two-way call using a single transceiver: FAIL Closing the PC stops the transceivers: FAIL addTrack reuses reusable transceivers: FAIL addTrack(0 streams): ontrack fires with no stream: FAIL addTrack(2 streams): ontrack fires with corresponding two streams: FAIL addTrack: "transceiver == {sender,receiver}": FAIL addTrack: creates a transceiver for the sender: FAIL addTrack: transceiver is not associated with an m-section: FAIL addTrack: transceiver is not stopped: FAIL addTrack: transceiver's currentDirection is null: FAIL addTrack: transceiver's direction is sendrecv: FAIL addTrack: transceiver.receiver has its own track: FAIL addTrack: transceiver.receiver's track is muted: FAIL addTrack: transceiver.sender is associated with the track: FAIL addTransceiver(2 streams): ontrack fires with corresponding two streams: FAIL addTransceiver(track, init): initialize sendEncodings[0].active to false: FAIL setLocalDescription(answer): transceiver.currentDirection is recvonly: FAIL setLocalDescription(answer): transceiver.currentDirection is sendonly: FAIL setLocalDescription(offer): transceiver gets associated with an m-section: FAIL setLocalDescription(offer): transceiver.mid matches the offer SDP: FAIL setRemoteDescription(offer): "transceiver == {sender,receiver}": FAIL setRemoteDescription(offer): ontrack fires with a track: FAIL setRemoteDescription(offer): ontrack fires with a transceiver.: FAIL setRemoteDescription(offer): ontrack's track.id is the same as track.id: FAIL setRemoteDescription(offer): transceiver.currentDirection is null: FAIL setRemoteDescription(offer): transceiver.direction is recvonly: FAIL setRemoteDescription(offer): transceiver.mid is the same on both ends: FAIL setRemoteDescription(offer): transceiver.stopped is false: FAIL
Pushed by james@hoppipolla.co.uk: https://hg.mozilla.org/integration/mozilla-inbound/rev/d320c6abfc3e [wpt PR 12069] - Implement & ship: RTCPeerConnection.addTransceiver(), a=testonly
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.