Draft: draft-ietf-rtcweb-jsep

Commentary: Fix 
 needs rebase 
 That 's twice now . Stop moving stuff around ! , ekr wrote : 
 Parens . 
 Alright , I 've addressed all the comments so far ( except for " transceiver with inactive direction should return true for isStopped " , which I disagree with ) . Most notably , we now have the rule that the codec preferences can remove codecs at any time , but can only reorder them for the initial offer . This prevents codecs being reordered back and forth on subsequent offer / answer exchanges , and prevents having different orders in the offer and answer . 
 I looked through our mailing archives and meeting minutes to see what we 've previously decided . When this API was first discussed on the mailing list , that the preferences do affect , and no one voiced any opposition . Then a couple weeks later , we decided that the order in affects the initial offer and answer , but not subsequent offers / answers . So maybe we should just go with that ? 
 Ready for review again . Rules about codec preferences now match the decision at TPAC 2015 described above . 
 LGTM
Paragraph (version A):
For an "a=imageattr recv" attribute, only size limits are considered.
Any other values, e.g.  aspect ratio, MUST be ignored.
Paragraph (version A):
The addTrack method adds a MediaStreamTrack to the PeerConnection,
using the MediaStream argument to associate the track with other
tracks in the same MediaStream, so that they can be added to the same
"LS" group when creating an offer or answer.  addTrack attempts to
minimize the number of transceivers as follows: The track will be
attached to the first compatible transceiver (of the same media type)
which has never had a direction of "sendonly" or "sendrecv".  If no
such transceiver exists, then one will be constructed as described in
sec.addTransceiver.
Paragraph (version A):
As an answer, the generated SDP will contain a specific configuration
that specifies how the media plane should be established; for each
SDP line, the generation of the SDP must follow the process defined
for generating an answer from the document that specifies the given
SDP line.  The exact handling of answer generation is detailed in
sec.generating-an-answer.  below.
Paragraph (version B):
As an answer, the generated SDP will contain a specific configuration
that specifies how the media plane should be established; for each
SDP line, the generation of the SDP must follow the process defined
for generating an answer from the document that specifies the given
SDP line.  The exact handling of answer generation is detailed in
sec.generating-an-answer. below.
Paragraph (version A):
This API changes the local media state; among other things, it sets
up local resources for receiving and decoding media.  In order to
successfully handle scenarios where the application wants to offer to
change from one media format to a different, incompatible format, the
PeerConnection must be able to simultaneously support use of both the
current and pending local descriptions (e.g.  support codecs that
exist in both descriptions) until a final answer is received, at
which point the PeerConnection can fully adopt the pending local
description, or roll back to the current description if the remote
side denied the change.
Paragraph (version A):
For each supported codec, "a=rtpmap" and "a=fmtp" lines, as
specified in RFC4566, Section 6.  The audio and video codecs that
MUST be supported are specified in I-D.ietf-rtcweb-audio(see
Section 3) and I-D.ietf-rtcweb-video(see Section 5).
Paragraph (version A):
The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
only include codecs present in the most recent answer.
Paragraph (version A):
For each supported codec that is present in the offer, "a=rtpmap"
and "a=fmtp" lines, as specified in RFC4566, Section 6, and
RFC3264, Section 6.1.  The audio and video codecs that MUST be
supported are specified in I-D.ietf-rtcweb-audio(see Section 3)
and I-D.ietf-rtcweb-video(see Section 5).
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 discard any associated ICE components, as
described in Section 9.2.1.3 of RFC5245.