- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Apr 2019 14:57:35 +0000
- To: public-webrtc-logs@w3.org
Due to https://github.com/w3c/webrtc-pc/issues/2176 I no longer think there's a way to make `stop()` work safely with the offerer-tagged m-line being one of the exposed transceivers.
The BUNDLE spec [says](https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-54#section-7.2.1): *"It is RECOMMENDED that the suggested offerer tagged "m=" section is a bundled "m=" section that the offerer believes it is unlikely that the answerer will reject, or move out of the BUNDLE group."*
**I see a couple of remaining options**:
1. Live with it. Ironically, the problem seems easily worked around in JS, like this:
```js
const pc = new RTCPeerConnection(config);
const dummy = pc.addTransceiver("audio", {direction: "inactive"});
```
2. Have webrtc-pc solve this, by creating an implicit inactive m-line dedicated to BUNDLE, either
- when the `"max-bundle"` bundle policy is used, or
- create some new `"safe-bundle"` policy.
2. Some variation of (2) where the implicit m-line is the data channel m-line (currently disallowed). Assumes all BUNDLE-aware non-browser end-points also support data channel.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2150#issuecomment-484126414 using your GitHub account
Received on Wednesday, 17 April 2019 14:57:41 UTC