New issue
Advanced search Search tips

Issue 901663 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Dec 3
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug


Participants' hotlists:
WebRTC-Unified-Plan


Sign in to add a comment

unified plan: order of m-lines with legacy offerToReceive is different from plan-b

Reported by fi...@appear.in, Nov 4

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce the problem:
Create a peerconnection, add a video stream, call createOffer({offerToReceiveAudio: true})
var pc = new RTCPeerConnection({sdpSemantics: 'unified-plan'});
navigator.mediaDevices.getUserMedia({video: true})
.then(stream => {
  pc.addTrack(stream.getTracks()[0], stream);
  return pc.createOffer({offerToReceiveAudio: true})
})
.then((offer) => console.log(offer.sdp))

What is the expected behavior?
that depends on your opinion about SDP. The behaviour is probably correct but this is going to break applications. This should be added to the doc at least.

What went wrong?
the order of m-lines is video-audio which is different from plan-b (audio-video)

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 71.0.3578.20 (Offizieller Build) dev (64-Bit)  Channel: canary
OS Version: 
Flash Version: 

(did i file this one before?)
 
Components: -Blink>WebRTC Blink>WebRTC>PeerConnection
hbos/hta: PTAL and decided if there is more action needed than updating the document. This was breaking an application I was testing.
Labels: Needs-Triage-M71
Cc: hta@chromium.org huib@chromium.org
Owner: hbos@chromium.org
Status: Assigned (was: Unconfirmed)
According to JSEP 5.2.1:

   An m= section is generated for each RtpTransceiver
   that has been added to the PeerConnection, excluding any stopped
   RtpTransceivers; this is done in the order the RtpTransceivers were
   added to the PeerConnection.

addTrack creates the first transceiver (video).
createOffer({offerToReceiveAudio: true}) calls addTransceiver which creates the second transceiver (audio).

So the implementation is behaving as specified.
fippo@ will you file a webrtc-pc issue or should I?
hbos: the spec is clear -- also Firefox behaves the same way. Happy to add a suggestion to the doc if you allow me
Should we add a notice in the transition guide and close this issue then, without updating the spec?
yes. Feel free to copy the example from above :-)
Status: WontFix (was: Assigned)
Filed related bug: https://crbug.com/911090 and WontFixing this since it works as intended. I didn't update the transition guide though.

Sign in to add a comment