W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > April 2019

Re: [webrtc-pc] transceiver.stop() needs more work (avoid BUNDLE footgun) (#2150)

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
Message-ID: <issue_comment.created-484126414-1555513054-sysbot+gh@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:
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

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:47 UTC