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

[webrtc-pc] Nulling mid when m-line is recycled is surprising. (#2238)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Thu, 25 Jul 2019 20:37:31 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-473059263-1564087050-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Nulling mid when m-line is recycled is surprising. ==
Right now [mid](https://w3c.github.io/webrtc-pc/#dom-rtptransceiver-mid) says *"After rollbacks, the value may change from a non-null value to null."*—for good reason: if we kept a `mid` from a remote offer, we'd risk sharing that mid with the transceiver the remote offer ultimately associates with (not unique).

But there's another place it's set to `null` in [JSEP](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-5.10): *"If the m= section is being recycled (see Section 5.2.2), dissociate the currently associated RtpTransceiver by setting its mid property to null"*

Disassociating here may be important to JSEP's logic, but `null`ing the JS observable `transceiver.mid`  after `transceiver` has been stopped and removed from `pc.getTransceivers()` seems surprising and pointless (the mid can't be reused anyway).

In general, removing ids on users seems a bit like neener-neener. Let's not.

We can't touch JSEP, but I think we can work around it with an internal slot we don't touch past stopped.

cc @docfaraday 

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2238 using your GitHub account
Received on Thursday, 25 July 2019 20:37:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:26 UTC