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

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