Change:
Editorial suggestions, if helpful use, if not just close the PR.
fine with me to merge this
LGTM

Discussion:
values. In addition, various RFCs put different conditions on the format of <del> 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. </del> <ins> offers versus answers.  For example, an 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

in response to changes in the ICE configuration. When a new gathering phase starts, the ICE Agent will notify the <del> application that gathering is occurring through a callback.  Then, when each new ICE candidate becomes available, the ICE Agent will supply it to the application via an additional callback; these candidates will also automatically be added to the local session description.  Finally, when all candidates have been gathered, a callback will be dispatched to signal that the gathering process is complete. </del> <ins> application that gathering is occurring through an event.  Then, when each new ICE candidate becomes available, the ICE Agent will supply it to the application via an additional event; these candidates will also automatically be added to the local session description. Finally, when all candidates have been gathered, an event will be dispatched to signal that the gathering process is complete. </ins> Note that gathering phases only gather the candidates needed by new/recycled/restarting m= lines; other m= lines continue to use

to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the application immediately via <del> the ICE candidate callback.  If the pool becomes depleted, either </del> <ins> the ICE candidate event.  If the pool becomes depleted, either </ins> because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the remaining candidates are gathered as usual.

5.3.3. <del> The createOffer method takes as a parameter an RTCAnswerOptions </del> <ins> The createAnswer method takes as a parameter an RTCAnswerOptions </ins> object.  Special processing is performed when generating a SDP description if the following constraints are present.

Changes MUST NOT be silently ignored. The following elements of the SDP media description MUST NOT be <del> changed between the createOffer and the setLocalDescription, since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del> <ins> changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.

The set of ICE candidates and their parameters (a=candidate). <ins> The DTLS fingerprint(s) (a=fingerprint). </ins> The following modifications, if done by the browser to a description between createOffer/createAnswer and the setLocalDescription, MUST be honored by the browser: