Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 PTAL 
 to polish and land . 
 is picking this one up .
Paragraph (version A):
In certain situations it may be desirable to "undo" a change made to
setLocalDescription or setRemoteDescription.  Consider a case where a
call is ongoing, and one side wants to change some of the session
parameters; that side generates an updated offer and then calls
setLocalDescription.  However, the remote side, either before or
after setRemoteDescription, decides it does not want to accept the
new parameters, and sends a reject message back to the offerer.  Now,
the offerer, and possibly the answerer as well, need to return to a
stable state and the previous local/remote description.  To support
this, we introduce the concept of "rollback".
Paragraph (version A):
A rollback discards any proposed changes to the session, returning
the state machine to the stable state, and setting the pending local
and/or remote description (see sec.pendinglocaldescription and
sec.pendingremotedescription) to null.  Any resources or candidates
that were allocated by the abandoned local description are discarded;
any media that is received will be processed according to the
previous local and remote descriptions.  Rollback can only be used to
cancel proposed changes; there is no support for rolling back from a
stable state to a previous stable state.  Note that this implies that
once the answerer has performed setLocalDescription with his answer,
this cannot be rolled back.
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 property MUST be set to
null, and the mapping between the transceiver and its m= section
index MUST be discarded.  RtpTransceivers that were created by
applying a remote offer that was subsequently rolled back MUST be
stopped and removed from the PeerConnection.  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):
A rollback is performed by supplying a session description of type
"rollback" with empty contents to either setLocalDescription or
setRemoteDescription.  The effect MUST be the same regardless of
whether setLocalDescription or setRemoteDescription is called.
Paragraph (version A):
A rollback may be performed if the PeerConnection is in any state
except for "stable".  This means that both offers and provisional
answers can be rolled back.  If a rollback is attempted in the
"stable" state, processing MUST stop and an error MUST be returned.
Paragraph (version B):
In certain situations it may be desirable to "undo" a change made to
setLocalDescription or setRemoteDescription.  Consider a case where a
call is ongoing, and one side wants to change some of the session
parameters; that side generates an updated offer and then calls
setLocalDescription.  However, the remote side, either before or
after setRemoteDescription, decides it does not want to accept the
new parameters, and sends a reject message back to the offerer.  Now,
the offerer, and possibly the answerer as well, need to return to a
stable state and the previous local/remote description.  To support
this, we introduce the concept of "rollback", which discards any
proposed changes to the session, returning the state machine to the
stable state.  A rollback is performed by supplying a session
description of type "rollback" with empty contents to either
setLocalDescription or setRemoteDescription.
Paragraph (version B):
A rollback may be performed if the PeerConnection is in any state
except for "stable".  This means that both offers and provisional
answers can be rolled back.  Rollback can only be used to cancel
proposed changes; there is no support for rolling back from a stable
state to a previous stable state.  If a rollback is attempted in the
"stable" state, processing MUST stop and an error MUST be returned.
Note that this implies that once the answerer has performed
setLocalDescription with his answer, this cannot be rolled back.
Paragraph (version B):
The effect of rollback MUST be the same regardless of whether
setLocalDescription or setRemoteDescription is called.
Paragraph (version B):
In order to process rollback, a JSEP implementation abandons the
current offer/answer transaction, sets the signaling state to
"stable", and sets the pending local and/or remote description (see
sec.pendinglocaldescription and sec.pendingremotedescription) to
null.  Any resources or candidates that were allocated by the
abandoned local description are discarded; any media that is received
is processed according to the previous local and remote descriptions.
Paragraph (version B):
A rollback disassociates 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, and the mapping between the transceiver and its m= section
index MUST be discarded.  RtpTransceivers that were created by
applying a remote offer that was subsequently rolled back MUST be
stopped and removed from the PeerConnection.  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.