Remove mid from sender/receiver

[stefhak]

Has been proposed it belongs to the Transceiver and could be removed from Senders/Receivers.

[pthatcherg]

Originally I said that without the mid, it would be impossible to know which sender matched with which transceiver, but I realized that it wrong. We could always just do "transceiver.sender === sender" or "transceiver.receiver === receiver" if we mark these as "same object", as Martin suggested we do.

So, I agree we should remove the mid and mark transceiver.receiver and .sender as "same object".

[alvestrand]

The only issue with that that I can see is that the mid is also a configuration value for RTPsender - it tells it what to put into the "mid" header extension.
It would be OK for the transceiver to have the "master copy" of the mid value, and configure the RTPSender on creation - and there's actually no need to expose this value at the API for 1.0, so after this conversation, I conclude that we can remove it from the API in version 1.0.

[pthatcherg]

By the way, ORTC has an MID (called muxId) on the RtpSender.getParameters/setParameters. We could easily have the same thing, but I don't see a need for it.

[juberti]

So how does RtpSender learn the mid? Through the ctor?

[pthatcherg]

If it needs it, it can iterate over the transceivers and find the one with
transceiver.sender === sender.

On Thu, Oct 29, 2015 at 10:05 PM, Justin Uberti notifications@github.com
wrote:

So how does RtpSender learn the mid? Through the ctor?

—
Reply to this email directly or view it on GitHub
#358 (comment).

[stefhak]

mid is now gone from the sender and receiver APIs (this change has not yet propagated into the Editor's draft though).