Draft: draft-ietf-rtcweb-jsep

Commentary: I decided it was worth defining m= section , etc . m= line is properly defined already . I decided ICE generation was clear enough . JSEP endpoint etc . are in PR 
 Juberti , because I removed the note , I left the parenthetical in the same place . 
 FYI that line 3140 was supposed to say " media sections " - suggest changing that before landing
Paragraph (version A):
In addition, various RFCs put different conditions on the format of
offers versus answers.  For example, an offer may propose an
arbitrary number of media streams (i.e. m= sections), but an answer
must contain the exact same number as the offer.
Paragraph (version B):
In addition, various RFCs put different conditions on the format of
offers versus answers.  For example, an offer may propose an
arbitrary number of m= sections (i.e., media descriptions as
described in RFC4566, Section 5.14), but an answer must contain the
exact same number as the offer.
Paragraph (version A):
The application can specify its preferred policy regarding use of
bundle, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp-
bundle-negotiation.  Regardless of policy, the application will
always try to negotiate bundle onto a single transport, and will
offer a single bundle group across all media section; use of this
single transport is contingent upon the answerer accepting bundle.
However, by specifying a policy from the list below, the application
can control exactly how aggressively it will try to bundle media
streams together, which affects how it will interoperate with a non-
bundle-aware endpoint.  When negotiating with a non-bundle-aware
endpoint, only the streams not marked as bundle-only streams will be
established.
Paragraph (version B):
The application can specify its preferred policy regarding use of
bundle, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp-
bundle-negotiation.  Regardless of policy, the application will
always try to negotiate bundle onto a single transport, and will
offer a single bundle group across all m= sections; use of this
single transport is contingent upon the answerer accepting bundle.
However, by specifying a policy from the list below, the application
can control exactly how aggressively it will try to bundle media
streams together, which affects how it will interoperate with a non-
bundle-aware endpoint.  When negotiating with a non-bundle-aware
endpoint, only the streams not marked as bundle-only streams will be
established.
Paragraph (version A):
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.  When acting as
answerer, if there is no bundle group in the offer, the
implementation will reject all but the first m= section of each
type.
Paragraph (version A):
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 A):
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.  When acting as answerer, the implementation will
reject any m= sections other than the first m= section, unless
they are in the same bundle group as that m= section.
Paragraph (version B):
The first m= 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 m= 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.  When acting as answerer, if there is
no bundle group in the offer, the implementation will reject all
but the first m= section of each type.
Paragraph (version B):
All m= 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 m= 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.  When acting as answerer, the implementation will
reject any m= sections other than the first m= section, unless
they are in the same bundle group as that m= section.
Paragraph (version A):
The removeTrack method removes a MediaStreamTrack from the
PeerConnection, using the RtpSender argument to indicate which sender
should have its track removed.  The sender's track is cleared, and
the sender stops sending.  Future calls to createOffer will mark the
media description associated with the sender as recvonly (if
transceiver.currentDirection is sendrecv) or as inactive (if
transceiver.currentDirection is sendonly).
Paragraph (version B):
The removeTrack method removes a MediaStreamTrack from the
PeerConnection, using the RtpSender argument to indicate which sender
should have its track removed.  The sender's track is cleared, and
the sender stops sending.  Future calls to createOffer will mark the
m= section associated with the sender as recvonly (if
transceiver.currentDirection is sendrecv) or as inactive (if
transceiver.currentDirection is sendonly).
Paragraph (version A):
Once all the session-level lines have been parsed, processing
continues with the lines in media sections.
Paragraph (version A):
Like the session-level lines, the media session lines MUST occur in
the specific order and with the specific syntax defined in RFC4566,
Section 5.
Paragraph (version B):
Once all the session-level lines have been parsed, processing
continues with the lines in m= sections.
Paragraph (version B):
Like the session-level lines, the media section lines MUST occur in
the specific order and with the specific syntax defined in RFC4566,
Section 5.
Paragraph (version A):
Next, media sections are processed.  For each media section, the
following steps MUST be performed; if any parameters are out of
bounds, or cannot be applied, processing MUST stop and an error MUST
be returned.
Paragraph (version A):
If this media section is new, begin gathering candidates for it,
as defined in RFC5245, Section 4.1.1, unless it has been marked as
bundle-only.
Paragraph (version A):
Or, if the ICE ufrag and password values have changed, and it has
not been marked as bundle-only, trigger the ICE Agent to start an
ICE restart, and begin gathering new candidates for the media
section as described in RFC5245, Section 9.1.1.1.  If this
description is an answer, also start checks on that media section
as defined in RFC5245, Section 9.3.1.1.
Paragraph (version B):
Next, m= sections are processed.  For each m= section, the following
steps MUST be performed; if any parameters are out of bounds, or
cannot be applied, processing MUST stop and an error MUST be
returned.
Paragraph (version B):
If this m= section is new, begin gathering candidates for it, as
defined in RFC5245, Section 4.1.1, unless it has been marked as
bundle-only.
Paragraph (version B):
Or, if the ICE ufrag and password values have changed, and it has
not been marked as bundle-only, trigger the ICE Agent to start an
ICE restart, and begin gathering new candidates for the m= section
as described in RFC5245, Section 9.1.1.1.  If this description is
an answer, also start checks on that media section as defined in
RFC5245, Section 9.3.1.1.
Paragraph (version A):
If the MID header extension is supported, prepare to demux RTP
streams intended for this media section based on the MID header
extension, as described in I-D.ietf-mmusic-sdp-bundle-
negotiation, Section 14.
Paragraph (version B):
If the MID header extension is supported, prepare to demux RTP
streams intended for this m= section based on the MID header
extension, as described in I-D.ietf-mmusic-sdp-bundle-
negotiation, Section 14.
Paragraph (version A):
For each media section, the following steps MUST be performed; if any
parameters are out of bounds, or cannot be applied, processing MUST
stop and an error MUST be returned.
Paragraph (version B):
For each m= section, the following steps MUST be performed; if any
parameters are out of bounds, or cannot be applied, processing MUST
stop and an error MUST be returned.
Paragraph (version A):
If the media section has been rejected (i.e. port is set to zero
in the answer), stop any reception or transmission of media for
this section, and, unless a non-rejected media section is bundled
with this media section, discard any associated ICE components, as
described in Section 9.2.1.3 of RFC5245.
Paragraph (version B):
If the m= section has been rejected (i.e. port is set to zero in
the answer), stop any reception or transmission of media for this
section, and, unless a non-rejected m= section is bundled with
this m= section, discard any associated ICE components, as
described in Section 9.2.1.3 of RFC5245.
Paragraph (version A):
If the media section references any media formats, RTP header
extensions, or RTCP feedback mechanisms that were not present
in the corresponding media section in the offer, this indicates
a negotiation problem and MUST result in an error.
Paragraph (version A):
If the media section has RTCP mux enabled, discard the RTCP ICE
component, if one exists, and begin or continue muxing RTCP
over the RTP ICE component, as specified in RFC5761,
Section 5.1.3.  Otherwise, prepare to transmit RTCP over the
RTCP ICE component; if no RTCP ICE component exists, because
RTCP mux was previously enabled, this MUST result in an error.
Paragraph (version A):
If the media section has reduced-size RTCP enabled, configure
the RTCP transmission for this media section to use reduced-
size RTCP, as specified in RFC5506.
Paragraph (version B):
If the m= section references any media formats, RTP header
extensions, or RTCP feedback mechanisms that were not present
in the corresponding m= section in the offer, this indicates a
negotiation problem and MUST result in an error.
Paragraph (version B):
If the m= section has RTCP mux enabled, discard the RTCP ICE
component, if one exists, and begin or continue muxing RTCP
over the RTP ICE component, as specified in RFC5761,
Section 5.1.3.  Otherwise, prepare to transmit RTCP over the
RTCP ICE component; if no RTCP ICE component exists, because
RTCP mux was previously enabled, this MUST result in an error.
Paragraph (version B):
If the m= section has reduced-size RTCP enabled, configure the
RTCP transmission for this m= section to use reduced-size RTCP,
as specified in RFC5506.