Subject: [rtcweb] Assigning MediaStreamTracks to media sections (with LS)

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Jul 2015 18:15:42 +0200

Warning: This may be pretty incomprehensible to anyone who wasn't in the
room for the discussion of the LS handling in Prague.

Initial offer handling is pretty trivial. The one who creates the offer
creates the LS groups (or not).
The below is the algorithm for the initial answer. The algorithm for
subsequent answers will have to take into account what assignments are
already in effect (this is the same as for the before-LS case).

When generating an initial answer, execute the following algorithm:

A - Make a list of all the LS groups in the offer. If any media section
is shared by two LS groups, merge the groups (they are all
synchronized). If there are media sections not in any LS group, put them
in the last group in the list.

B - Make a list of all the MediaStreamTracks the answererer wants to
send, grouped by MediaStream the MediaStreamTrack belongs to. If any
track occurs in multiple MediaStreams, merge the groups.

C - For each group "SG" in the MediaStreamTrack list:
   For each group "LSG" in the LS group list:
      If all MediaStreamTracks in SG can be sent using the media
sections in LSG:
          Mark "SG" as being sent using "LSG"
          Mark all media sections that are assigned for use by "SG" as
"in use".
          If all media sections in LSG are "in use":
             Remove "LSG" from the list of LS groups
          endif
      endif
   endfor
   If "SG" is not marked as being sendable
      set "must negotiate" flag
   endif
endfor

D - Generate the answer using the assignment above. All LS groups in the
answer are
the same as those in the offer.

If the "must negotiate" flag is set:
   When the PC reaches a stable negotiation state, fire a
"negotiationneeded" event.
endif

Note: When there are no LS groups, the algorithm trivially reduces to
what we have already (there is only one group in that case). We still
have to figure out what to do with leftover tracks, which may cause the
need to send "negotiationneeded". So the only added complexity is the
consideration of multiple LS groups.

Note: When there is only one LS group consisting of an audio stream and
a video stream, and the answerer only wants to send an audio stream and
a video stream, this algorithm produces the right result. This may be
its most important feature.

Note: This algorithm doesn't generate LS groups for stuff that is sent
using non-grouped
media sections from the offer. If that's desired, we need to set the
"must negotiate" flag
when using media sections from that group.

Note: For subsequent offers, if the offerer starts changing the LS
groups, this will invalidate the assignment of MediaStreamTracks to
media sections - something we have not contemplated in any other
context. I suggest that we forbid changing LS groups at the offerer (he
can only add new ones), and reject all modified LS groups if a
subsequent offer from a non-WebRTC sender starts changing LS groups on
us. This will keep media flowing, but will lose synchronization
signalling - this is (hopefully) an edge case.

Note: My preference is still to not do LS groups. But if we use them, we
must define how.
This is the least complicated algorithm I can see working.

-- 
Surveillance is pervasive. Go Dark.