Draft: draft-ietf-rtcweb-jsep

Commentary: Second half of . 
 cc copying remaining comments from here . 
 see what you can do with these comments . If we ca n't address them all , we can simply mark the remainder with OPEN ISSUE markers and GH bugs . 
 I resolved everything , I think , and merge those changes into this PR ( I was n't sure how to push directly from the command line ) . 
 Overall LGTM . A few comments , plus the build is broken .
Paragraph (version A):
rollback that offer, then call createOffer and have a m= section for
the added track appear in the generated offer.
Paragraph (version B):
roll back that offer, then call createOffer and have a m= section for
the added track appear in the generated offer.
Paragraph (version B):
The next step is to generate m= sections, as specified in RFC4566
Section 5.14.  An m= section is generated for each RtpTransceiver
that has been added to the PeerConnection via the addTrack,
addTransceiver, and setRemoteDescription methods.  [[OPEN ISSUE: move
discussion of setRemoteDescription to the subsequent-offer section.]]
This is done in the order that their associated RtpTransceivers were
added to the PeerConnection and excludes RtpTranscievers that are
stopped and not associated with an m= section (either due to an m=
section being recycled or an RtpTransceiver having been stopped
before being associated with an m= section) .
Paragraph (version A):
If the RtpTransceiver's RtpSender is active, an "a=rid" line for
each encoding specified by the application in the RtpSenders's
parameters.  If no encodings have been specified, then a single
"a=rid" line is generated.  The "a=rid" line is specified in I-
D.ietf-mmusic-rid, and its direction MUST be "send".  If the
application has chosen a RID value, it MUST be used as the rid-
identifier; otherwise a RID value MUST be generated by the
implementation.  When generating RID values, it is RECOMMENDED
that the values be 3 bytes or less, to allow them to efficiently
fit into the RTP header extension defined in I-D.ietf-avtext-rid,
Section 11.
Paragraph (version B):
If the RtpTransceiver's RtpSender is active, and the application
has specified RID values or has specified more than one encoding
in the RtpSenders's parameters, an "a=rid" line for each encoding
specified.  The "a=rid" line is specified in I-D.ietf-mmusic-rid,
and its direction MUST be "send".  If the application has chosen a
RID value, it MUST be used as the rid-identifier; otherwise a RID
value MUST be generated by the implementation.  When generating
RID values, it is RECOMMENDED that the values be 3 bytes or less,
to allow them to efficiently fit into the RTP header extension
defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have
been specified, or only one encoding is specified but without a
RID value, then no "a=rid" lines are generated.
Paragraph (version B):
For RtpTransceivers that are still present, the "a=msid",
"a=ssrc", and "a=ssrc-group" lines MUST stay the same.
Paragraph (version A):
If a local MediaStreamTrack has been associated, and RTX has been
negotiated for this m= section, another "a=ssrc" line with the RTX
SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section
SSRCs.
Paragraph (version B):
For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc",
and "a=ssrc-group" lines MUST stay the same.