- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Apr 2017 23:05:50 +0000
- To: public-webrtc-logs@w3.org
> Not sure what you mean with "very different" and "two offer/answer exchanges". My point is that `addTrack` will try to latch onto existing m= sections, while `addTransceiver` will always create a new m= section. So here's what would happen: 1. Alice calls `addTransceiver` 2. Bob calls `addTransceiver` 3. Alice initiates the offer/answer exchange 4. Offer/answer exchange completes. Alice can send a track to Bob, but Bob can't, because it's attached to a transceiver that's not negotiated yet. 5. Bob initiates second offer/answer exchange adding the second m= section I don't imagine this will be a common scenario. Anyway, I agree with the rest of your comment. If an application is optimized for early media (or is just transceiver-aware), it has no use for track or stream IDs. -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1128#issuecomment-295484498 using your GitHub account
Received on Wednesday, 19 April 2017 23:05:56 UTC