- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Apr 2017 14:30:27 +0000
- To: public-webrtc-logs@w3.org
[addTrack](http://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-addtrack) in step 8 implicitly creates a transceiver, a sender, and [a receiver](http://w3c.github.io/webrtc-pc/#dfn-create-an-rtcrtpreceiver) which in turn creates a remote track (step 2) available immediately. So calling `addTrack` on both sides seems sufficient to render at least `track.id`s moot. I suppose `stream.id` will continue to work for people who ignore the early tracks. But they won't benefit from early media. Once people realize this, they'll instead hook the early tracks up to their own `new MediaStream([videotrack, audiotrack])` with its own `stream.id` as shown in the [spec example](http://w3c.github.io/webrtc-pc/#peer-to-peer-example-with-media-before-signaling). Once this gets copied around the web `stream.id` is effectively moot as well. Not sure what you mean with "very different" and "two offer/answer exchanges". In my experience people don't use `pc.onnegotiationneeded`. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1128#issuecomment-295290126 using your GitHub account
Received on Wednesday, 19 April 2017 14:30:35 UTC