Change:
Also, update IceCandidate section to use consistent “m= line” terminology, and also make it clearer that use of MID, if present, is a MUST.
WFM
The current example in S 3.2 refers to SDES, but that's not in JSEP any more. We need a new example.

Discussion:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the SRTP parameters RFC4568 sent to a remote party indicate what the local side will use to encrypt, and thereby what the remote party should expect to receive; the remote party will have to accept these parameters, with no option to choose a different value.  [[OPEN ISSUE: This is not correct because we removed SDES (https://github.com/rtcweb-wg/jsep/issues/10)]] </del> <ins> However, not all parameters follow this rule; for example, the DTLS- SRTP parameters RFC5763 sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive; the remote party will have to accept these parameters, with no option to choose different values. </ins> In addition, various RFCs put different conditions on the format of <del> offers versus answers.  For example, a offer may propose multiple SRTP configurations, but an answer may only contain a single SRTP configuration.  [[OPEN ISSUE: See issue 10 above.]] </del> <ins> offers versus answers.  For example, a offer may propose an arbitrary number of media streams (i.e. m= sections), but an answer must contain the exact same number as the offer. </ins> Lastly, while the exact media parameters are only known only after an offer and an answer have been exchanged, it is possible for the

"candidate-attribute" field defined for ICE.  For example: The IceCandidate object also contains fields to indicate which m= <del> line it should be associated with.  The m line can be identified in one of two ways; either by a m-line index, or a MID.  The m-line index is a zero-based index, with index N referring to the N+1th m-line in the SDP sent by the entity which sent the IceCandidate. The MID uses the "media stream identification", as defined in RFC5888, to identify the m-line.  WebRTC implementations creating an ICE Candidate object MUST populate both of these fields. Implementations receiving an ICE Candidate object SHOULD use the MID if they implement that functionality, or the m-line index, if not. </del> <ins> line it should be associated with.  The m= line can be identified in one of two ways; either by a m= line index, or a MID.  The m= line index is a zero-based index, with index N referring to the N+1th m= line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations creating an ICE Candidate object MUST populate both of these fields. Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (as it could have come from a non-JSEP endpoint). </ins> 3.4.2.

they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: <del> The number, type and port number of m-lines. </del> <ins> The number, type and port number of m= lines. </ins> The generated ICE credentials (a=ice-ufrag and a=ice-pwd).