We used to label tracks individually, in a view to using the labelling
for simulcast. Since then, the WebRTC community has converged on a
different strategy, where multiple tracks share a single mid and
are labelled with the rid extension.
We now label whole streams, which is simpler, and use the track's
kind (and, in the future, the rid) to disambiguate. This changes the
protocol in two ways:
* in offers, the "labels" dictionary is replaced by a single "label"
field; and
* the syntax of the "request" message has changed.
We used to destroy and recreate down streams whenever something changed,
which turned out to be racy. We now properly implement renegotiation,
as well as atomic replacement of a stream by another one.
We used to signal connection replacement by reusing the same connection
id. This turned out to be racy, as we couldn't reliably discard old
answers after a connection id was refused.
We now use a new id for every new connection, and explicitly signal
stream replacement in the offer message. This requires maintaining a
local id on the client side.
Split the id field into id and source, where source indicates the sender
of the message and id the entity being sent. Remove the label request,
just use the offerer's username. Maintain the username within the
ServerConnection, this removes a parameter from some methods.
This could be solved by simply reordering the fields, but it
is more robust to move the atomics into their own structure,
and the extra indirection should not cost much.
It is now possible to specify codecs other than VP8 and Opus. This
turns out not to be very useful, since VP8 is the only codec supported
by all browsers (in violation of the WebRTC spec, which mandates support
for H.264), and there is no good reason to use anything other than Opus
for audio.
We used to push a connection when we got all tracks. However, it may
happen that some tracks fail; in that case, the connection would never
get pushed.
We already send NACKs when a packet is missing. Under high packet loss,
however, the recovery packet might get lost two. Forward receiver NACKs
to the sender, but only after a delay and after checking that the packet
has not arrived in the meantime.
