Draft: draft-ietf-rtcweb-jsep

Commentary: The local description can never be wrong , because it is constructed by the browser . I also explicitly text to make clear that the mux state for any m= line can not change . 
 LGTM 
 Section 5.8 describes the behavior of an implementation processing its own unmodified SDP . It contains significant error language that should have been removed when SDP munging was removed . In particular , please remove all of the following : • " If an error is returned , the session MUST be restored to the state it was in before performing these steps . " • " If RTCP mux is not indicated , but was previously negotiated , i.e. , the RTCP ICE component no longer exists , this MUST result in an error . " • " If any indicated RTP header extension is not supported , this MUST result in an error . " • " If any indicated media format is not supported , this MUST result in an error . " • " If any referenced primary payload types are not present , this MUST result in an error . " The first bullet of section 5.8 includes : " it has been marked as bundle - only ... , " and the second includes " it has not been marked as bundle - only ... " -- in both cases , I believe the indicated behavior is supposed to happen for any bundled section ( e.g. , in a re - offer or re - answer ) , regardless of whether it is bundle - only . 
 I think  is right about this , but I wonder if this actually belongs elsewhere , so further study needed . 
 This is already duplicated . This seems to be a prohibition that is stricter than RFC 5761 , and if we remove it here we have removed it generally , unless I have missed somewhere else we say it . This is not appropriate for remote descriptions . We say this in 5.9 . The first bullet of section 5.8 includes : " it has been marked as bundle - only ... , " and the second includes " it has not been marked as bundle - only ... " -- in both cases , I believe the indicated behavior is supposed to happen for any bundled section ( e.g. , in a re - offer or re - answer ) , regardless of whether it is bundle - only . Yeah , I think  is right about this and it 's probably the result of some section refactor 
 Made some progress on it . Editor discussion on the mux piece . Once an m= line has mux or non - mux negotiated , that 's immutable . 
 LG with nits
Paragraph (version A):
The "a=rtcp-mux" line MUST NOT be added unless present in the most
recent answer.
Paragraph (version B):
The "a=rtcp-mux" line MUST be the same as that in the most recent
answer.
Paragraph (version B):
RTCP multiplexing must be used, and an "a=rtcp-mux" line inserted
if and only if the m= section previously used RTCP multiplexing.
Paragraph (version A):
If the RTP/RTCP multiplexing policy is "require", each m= section
MUST contain an "a=rtcp-mux" attribute.  If an "m=" section
contains an "a=rtcp-mux-only" attribute then that section MUST
also contain an "a=rtcp-mux" attribute.
Paragraph (version B):
If the RTP/RTCP multiplexing policy is "require", each m= section
MUST contain an "a=rtcp-mux" attribute.  If an m= section contains
an "a=rtcp-mux-only" attribute then that section MUST also contain
an "a=rtcp-mux" attribute.
Paragraph (version B):
If this m= section was present in the previous answer then the
state of RTP/RTCP multiplexing MUST match what was previously
negotiated.
Paragraph (version A):
If this m= section is new, begin gathering candidates for it, as
defined in RFC5245, Section 4.1.1, unless it has been marked as
bundle-only.
Paragraph (version A):
Or, if the ICE ufrag and password values have changed, and it has
not been marked as bundle-only, trigger the ICE agent to start an
ICE restart, and begin gathering new candidates for the m= section
as described in RFC5245, Section 9.1.1.1.  If this description is
an answer, also start checks on that media section as defined in
RFC5245, Section 9.3.1.1.
Paragraph (version B):
Or, if the ICE ufrag and password values have changed, trigger the
ICE agent to start an ICE restart, and begin gathering new
candidates for the m= section as described in RFC5245,
Section 9.1.1.1.  If this description is an answer, also start
checks on that media section as defined in RFC5245,
Section 9.3.1.1.
Paragraph (version A):
If RTCP mux is indicated, prepare to demux RTP and RTCP from
the RTP ICE component, as specified in RFC5761, Section 5.1.3.
If RTCP mux is not indicated, but was previously negotiated,
i.e., the RTCP ICE component no longer exists, this MUST result
in an error.
Paragraph (version A):
For each specified RTP header extension, establish a mapping
between the extension ID and URI, as described in section 6 of
RFC5285.  If any indicated RTP header extension is not
supported, this MUST result in an error.
Paragraph (version B):
If RTCP mux is indicated, prepare to demux RTP and RTCP from
the RTP ICE component, as specified in RFC5761, Section 5.1.3.
Paragraph (version B):
For each specified RTP header extension, establish a mapping
between the extension ID and URI, as described in RFC5285,
Section 6.
Paragraph (version A):
For each specified media format, establish a mapping between
the payload type and the actual media format, as described in
RFC3264, Section 6.1.  In addition, prepare to demux RTP
streams intended for this m= section based on the media formats
supported by this m= section, as described in I-D.ietf-mmusic-
sdp-bundle-negotiation, Section 10.2.  If any indicated media
format is not supported, this MUST result in an error.
Paragraph (version A):
For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload
type, as described in RFC4588, Sections 8.6 and 8.7.  If any
referenced primary payload types are not present, this MUST
result in an error.
Paragraph (version B):
For each specified media format, establish a mapping between
the payload type and the actual media format, as described in
RFC3264, Section 6.1.  In addition, prepare to demux RTP
streams intended for this m= section based on the media formats
supported by this m= section, as described in I-D.ietf-mmusic-
sdp-bundle-negotiation, Section 10.2.
Paragraph (version B):
For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload
type, as described in RFC4588, Sections 8.6 and 8.7.