Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 Holding my review until Martin 's comments are addressed 
 lgtm with comments above 
 1 seems clear that there is one : Once all m= sections have been generated , a session - level " a = group " attribute MUST be as specified in [ RFC5888 ] . This attribute MUST have semantics " BUNDLE " , and MUST include the mid identifiers of each m= section . The effect of this is that the browser offers all m= sections as one BUNDLE group . However , whether the m= sections are bundle - only or not depends on the BUNDLE policy . 1 seems clear that " balanced " means 1 The application will BUNDLE all media streams of the same type together . That is , if there are multiple audio and multiple video MediaStreamTracks attached to a PeerConnection , all but the first audio and video tracks will be marked as bundle - only , and candidates will only be gathered for N media streams , where N is the number of distinct media types . When talking to a non - BUNDLE - aware endpoint , only the non - bundle - only streams will be negotiated . This policy balances desire to multiplex with the need to ensure basic audio and video still works in legacy cases . Data channels will be in a separate bundle group . Justin and EKR believe the number should always be 1 . Need to fix the text to make this clear . 
 Right , seems like we need to change 4.1.1 to say the application will try to BUNDLE all media streams , but can fall back to the unbundled case where audio , video , and data are on separate transports . We should also have a sentence somewhere that indicates that only a single bundle group is ever offered . 
 Control of # of bundle groups is left as something for the future ; we would need an additional policy , or some other thing to frob , perhaps on rtpsender . 
 First I think browsers need to be able to correctly respond to more than one bundle ( which may mean rejecting the bundle ) , but I want to leave it open that an browser impelmetion is allowed to create more than one bundle . If you read the mux atributes draft you will see there are many cases where the browser might choose to create more than one bundle . 
 Which section ? 
 Well if you ever want to do any of things that are not allowed to be in the same bundle , you end up wanting two bundles .
Paragraph (version A):
The application will BUNDLE all media streams of the same type
together.  That is, if there are multiple audio and multiple video
MediaStreamTracks attached to a PeerConnection, all but the first
audio and video tracks will be marked as bundle-only, and
candidates will only be gathered for N media streams, where N is
the number of distinct media types.  When talking to a non-BUNDLE-
aware endpoint, only the non-bundle-only streams will be
negotiated.  This policy balances desire to multiplex with the
need to ensure basic audio and video still works in legacy cases.
Data channels will be in a separate bundle group.
Paragraph (version A):
The application will offer BUNDLE, but mark none of its streams as
bundle-only.  This policy will allow all streams to be received by
non-BUNDLE-aware endpoints, but require separate candidates to be
gathered for each media stream.
Paragraph (version A):
The application will BUNDLE all of its media streams, including
data channels, on a single transport.  All streams other than the
first will be marked as bundle-only.  This policy aims to minimize
candidate gathering and maximize multiplexing, at the cost of less
compatibility with legacy endpoints.
Paragraph (version B):
The first media section of each type (audio, video, or
application) will contain transport parameters, which will allow
an answerer to unbundle that section.  The second and any
subsequent media section of each type will be marked bundle-only.
The result is that if there are N distinct media types, then
candidates will be gathered for for N media streams.  This policy
balances desire to multiplex with the need to ensure basic audio
and video can still be negotiated in legacy cases.
Paragraph (version B):
All media sections will contain transport parameters; none will be
marked as bundle-only.  This policy will allow all streams to be
received by non-BUNDLE-aware endpoints, but require separate
candidates to be gathered for each media stream.
Paragraph (version B):
Only the first media section will contain transport parameters;
all streams other than the first will be marked as bundle-only.
This policy aims to minimize candidate gathering and maximize
multiplexing, at the cost of less compatibility with legacy
endpoints.