Draft: draft-ietf-rtcweb-jsep

Commentary: I see you also a " , "
Paragraph (version A):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid attribute MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be removed.  However, a
RtpTransceiver MUST NOT be removed if a track was attached to the
RtpTransceiver via the addTrack method.  This is so that an
application may call addTrack, then call setRemoteDescription with an
offer, then roll back that offer, then call createOffer and have a m=
section for the added track appear in the generated offer.
Paragraph (version B):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid property MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be removed.  However, a
RtpTransceiver MUST NOT be removed if a track was attached to the
RtpTransceiver via the addTrack method.  This is so that an
application may call addTrack, then call setRemoteDescription with an
offer, then roll back that offer, then call createOffer and have a m=
section for the added track appear in the generated offer.
Paragraph (version A):
The stopped property indicates whether the transceiver has been
stopped, either by a call to stopTransceiver or by applying an answer
that rejects the associated m= section.  In either of these cases, it
is set to "true" and otherwise will be set to "false".
Paragraph (version B):
The stopped property indicates whether the transceiver has been
stopped, either by a call to stopTransceiver or by applying an answer
that rejects the associated m= section.  In either of these cases, it
is set to "true", and otherwise will be set to "false".
Paragraph (version A):
The setDirection method sets the direction of a transceiver, which
affects the direction attribute of the associated m= section on
future calls to createOffer and createAnswer.
Paragraph (version A):
Note that while setDirection sets the direction attribute of the
transceiver immediately (sec.transceiver-direction), this attribute
does not immediately affect whether the transceiver's RtpSender will
send or its RtpReceiver will receive.  The direction in effect is
represented by the currentDirection attribute, which is only updated
when an answer is applied.
Paragraph (version A):
The direction method returns the last value passed into setDirection.
If setDirection has never been called, it returns the direction the
transceiver was initialized with.
Paragraph (version A):
The currentDirection method returns the last negotiated direction for
the transceiver's associated m= section.  More specifically, it
returns the RFC3264 directional attribute of the associated m=
section in the last applied answer, with "send" and "recv" directions
reversed if it was a remote answer.  For example, if the directional
attribute for the associated m= section in a remote answer is
"recvonly", currentDirection returns "sendonly".
Paragraph (version A):
If an answer that references this transceiver has not yet been
applied, or if the transceiver is stopped, currentDirection returns
null.
Paragraph (version B):
The setDirection method sets the direction of a transceiver, which
affects the direction property of the associated m= section on future
calls to createOffer and createAnswer.
Paragraph (version B):
Note that while setDirection sets the direction property of the
transceiver immediately (sec.transceiver-direction), this property
does not immediately affect whether the transceiver's RtpSender will
send or its RtpReceiver will receive.  The direction in effect is
represented by the currentDirection property, which is only updated
when an answer is applied.
Paragraph (version B):
The direction property indicates the last value passed into
setDirection.  If setDirection has never been called, it is set to
the direction the transceiver was initialized with.
Paragraph (version B):
The currentDirection property indicates the last negotiated direction
for the transceiver's associated m= section.  More specifically, it
indicates the RFC3264 directional attribute of the associated m=
section in the last applied answer, with "send" and "recv" directions
reversed if it was a remote answer.  For example, if the directional
attribute for the associated m= section in a remote answer is
"recvonly", currentDirection is set to "sendonly".
Paragraph (version B):
If an answer that references this transceiver has not yet been
applied, or if the transceiver is stopped, currentDirection is set to
null.
Paragraph (version A):
Set the value of the RtpTransceiver's mid attribute to the
MID of the m= section.
Paragraph (version B):
Set the value of the RtpTransceiver's mid property to the
MID of the m= section.
Paragraph (version A):
Associate the found or created RtpTransceiver with the m=
section by setting the value of the RtpTransceiver's mid
attribute to the MID of the m= section.  If the m= section
does not include a MID (i.e., the remote side does not
support the MID extension), generate a value for the
RtpTransceiver mid attribute, following the guidance for
"a=mid" mentioned in sec.initial-offers.
Paragraph (version B):
Associate the found or created RtpTransceiver with the m=
section by setting the value of the RtpTransceiver's mid
property to the MID of the m= section.  If the m= section
does not include a MID (i.e., the remote side does not
support the MID extension), generate a value for the
RtpTransceiver's mid property, following the guidance for
"a=mid" mentioned in sec.initial-offers.