See also: IRC log
<vivien> [recording now in progress]
<dom> Issue 1128
<dom> PR 1567 Adding `remoteTrackId` attribute to represent SDP-signaled track ID
fluffy: Why doesn't the track id change?
taylor: Other stuff rely on track
id's being constant
... Before, you got a new track (with a new id)
jib: An other option would be to allow changing the track id in mediacap spec
fluffy: I don't like adding something that you can't use in this case, and this case and this other case
jib: There's also no guarantee that remote track ids are unique anyhow
fluffy: Suggests to fix the issue on both sides. This solution only addresses the problem on one side
RESOLUTION: We revert the PR (1567) also, we close 1128 with a comment
taylor: Should we always generate track id so it doesn't work in some situations, but not in others
Note from the chairs: People seemed supportive of that idea
<vivien> Issue 1161
<vivien> Issue 1181
jib: I think this is fine
RESOLUTION: is to accept the current state after PR 1402 and we close 1161 and 1181
<vivien> Issue 1207
<vivien> PR 1592
RESOLUTION: is to accept the changes proposed by PR 1592
<vivien> Issue 1178
RESOLUTION: is to go for the "one object" approach proposed by Taylor
<vivien> Issue 1406
RESOLUTION: is to reuse the same RTCDtlsTransport object when a new DTLS association is started as proposed by Taylor
<vivien> Issue 1563
RESOLUTION: is that we are waiting for the mmuisc feedback
<vivien> Issue 1520
<vivien> PR 1560
RESOLUTION: is that there are no objections to the model proposed in PR 1560
<vivien> Issue 1564
<vivien> PR 1577
RESOLUTION: is to floor instead ceil and document what happens if the result is zero (PR 1577 to be updated)
RESOLUTION: is that we allow aspect ratios to change due to integer width and height rounding
<vivien> Issue 1259
<vivien> PR 1553
RESOLUTION: is that no one objects to the proposed PR but it needs review