Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM and if Justin wants to tie in the stuff from my comment a bit more that is great 
 PTAL 
 seems like it 's generally right , LGTM
Paragraph (version A):
The codec preferences of an RtpTransceiver can cause codecs to be
excluded by subsequent calls to createOffer and createAnswer, in
which case the corresponding media formats in the associated m=
section will be excluded.  The codec preferences cannot add media
formats that would otherwise not be present.  This includes codecs
that were not negotiated in a previous offer/answer exchange that
included the transceiver.
Paragraph (version B):
The codec preferences of an RtpTransceiver can cause codecs to be
excluded by subsequent calls to createOffer and createAnswer, in
which case the corresponding media formats in the associated m=
section will be excluded.  The codec preferences cannot add media
formats that would otherwise not be present.
Paragraph (version A):
No supported codec is present in the offer.
Paragraph (version B):
None of the offered media formats are supported and, if
applicable, allowed by codec preferences.
Paragraph (version A):
If codec preferences have been set for the associated transceiver,
media formats MUST be generated in the corresponding order, and
MUST exclude any codecs not present in the codec preferences or
not present in the offer.  Note that non-JSEP endpoints are not
subject to this restriction, and might add media formats in the
answer that are not present in the offer, as specified in RFC3264,
Section 6.1.  Therefore, JSEP implementations MUST be prepared to
receive such answers.
Paragraph (version A):
Unless excluded by the above restrictions, the media formats MUST
include the mandatory audio/video codecs as specified in RFC7874,
Section 3, and RFC7742, Section 5.
Paragraph (version B):
If codec preferences have been set for the associated transceiver,
media formats MUST be generated in the corresponding order,
regardless of what was offered, and MUST exclude any codecs not
present in the codec preferences.
Paragraph (version B):
Otherwise, the media formats on the m= line MUST be generated in
the same order as those offered in the current remote description,
excluding any currently unsupported formats.  Any currently
available media formats that are not present in the current remote
description MUST be added after all existing formats.
Paragraph (version B):
In either case, the media formats in the answer MUST include at
least one format that is present in the offer, but MAY include
formats that are locally supported but not present in the offer,
as mentioned in RFC3264, Section 6.1.  If no common format exists,
the m= section is rejected as described above.
Paragraph (version A):
Unless codec preferences have been set for the associated
transceiver, the media formats on the m= line MUST be generated in
the same order as in the current local description.
Paragraph (version A):
If the directional attribute in the answer indicates that the
JSEP implementation should be sending media ("sendonly" for
local answers, "recvonly" for remote answers, or "sendrecv" for
either type of answer), choose the media format to send as the
most preferred media format from the remote description that is
also present in the answer, as described in RFC3264, Sections
transport layers have been established.  If an SSRC has not
already been chosen for this outgoing RTP stream, choose a
random one.  If media is already being transmitted, the same
SSRC SHOULD be used unless the clockrate of the new codec is
different, in which case a new SSRC MUST be chosen, as
specified in RFC7160, Section 3.1.
Paragraph (version B):
If the directional attribute in the answer indicates that the
JSEP implementation should be sending media ("sendonly" for
local answers, "recvonly" for remote answers, or "sendrecv" for
either type of answer), choose the media format to send as the
most preferred media format from the remote description that is
also locally supported, as discussed in RFC3264, Sections 6.1
and 7, and start transmitting RTP media using that format once
the underlying transport layers have been established.  If an
SSRC has not already been chosen for this outgoing RTP stream,
choose a random one.  If media is already being transmitted,
the same SSRC SHOULD be used unless the clockrate of the new
codec is different, in which case a new SSRC MUST be chosen, as
specified in RFC7160, Section 3.1.