- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Jul 2018 19:39:13 +0000
- To: public-webrtc-logs@w3.org
We still have the problem about about not knowing which is the "offerer tagged" special "m=" section that causes stopping all other transceivers. In fact, this might not have been decided yet if an offer has not been created. I thought about [this comment](https://github.com/w3c/webrtc-pc/issues/1858#issuecomment-391187810): > That still doesn't tell you which is the special one that can't be rejected, but you could tell by parsing the "a=group:BUNDLE" in the offer. [...] We should just reject all bundled m= sections if this happens, because that's simpler. If we want to reject all bundled ones, as to not have to worry about which one is "offerer tagged", then we have to either: 1. Update one of the JSEP specs to say that createOffer() should create SDP where all "m=" sections are rejected when bundling is used. 2. Munge the resulting createOffer() SDP to reject all "m=" section when bundling is used. 3. Influence the state of the PC such that createOffer() generates an offer where all "m=" sections are rejected. That is, we stop the transceivers before createOffer(). I think doing 3) means manually stopping all the transceivers if one of them are stopped. But this doesn't even cut it - we'd have to predict which transceivers would be bundled for any transceiver that is created. I think we would have to make addTrack() and addTransceiver() create already-stopped-transceivers. 2) and 3) does not seem feasible. I don't know about 1). -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1919#issuecomment-407871007 using your GitHub account
Received on Wednesday, 25 July 2018 19:39:41 UTC