Original text:
offerer to be maintained, and so the subsequent answer will contain an identical "LS" group. <del> The sec.normal-example example later in this document shows a more </del>  involved case of "LS" group generation. The next step is to generate m= sections for each m= section that is 7.1. This section shows a very simple example that sets up a minimal audio <del> / video call between two JSEP endpoints and does not use trickle ICE. The example in the following section provides a more realistic example of what would happen in a normal browser to browser connection. The flow shows Alice's endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete.  Trickle ICE is not used.  Both Alice and Bob are using the default policy of balanced. </del>  The SDP for |offer-A1| looks like: 7.2. <del> This section shows a typical example of a session between two JSEP endpoints setting up an audio channel and a data channel.  Trickle ICE is used in full trickle mode with a bundle policy of max-bundle, an RTCP mux policy of require, and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </del>  The SDP for |offer-B1| looks like: <del> The SDP for |offer-B1-candidate-1| looks like: </del>  <del> The SDP for |offer-B1-candidate-2| looks like: </del>  <del> The SDP for |offer-B1-candidate-3| looks like: </del>  The SDP for |answer-B1| looks like: <del> The SDP for |answer-B1-candidate-1| looks like: </del>  <del> The SDP for |answer-B1-candidate-2| looks like: </del>  <del> The SDP for |answer-B1-candidate-3| looks like: </del>  <del> The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate the local candidate that was selected) </del>  <del> The SDP for |answer-B2| looks like: (note the use of setup:passive to maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) </del>  8. sec.use-of-provisional-answer.  Here, Alice's endpoint sends an offer to Bob's endpoint to start an audio/video call.  Bob immediately responds with an answer that accepts the audio/video m= sections, but <del> marks them as sendonly (from its perspective), meaning that Alice </del>  will not yet send media.  This allows the JSEP implementation to start negotiating ICE and DTLS immediately.  Bob's endpoint then prompts him to answer the call, and when he does, his endpoint sends before the second offer is sent, then media can be transmitted immediately by the callee immediately upon answering the call, minimizing perceived post-dial-delay.  The second offer/answer <del> exchange can also change the preferred codecs or other information. </del>  This example also makes use of the "relay" ICE candidate policy described in sec.ice-candidate-policy to minimize the ICE gathering The SDP for |offer-C1| looks like: <del> The SDP for |offer-C1-candidate-1| looks like: </del>  The SDP for |answer-C1| looks like: <del> The SDP for |answer-C1-candidate-1| looks like: </del>  The SDP for |offer-C2| looks like:

Reviewer comments:
a=simulcast, a=rid a=imageattr (maybe) differing codecs/preferences for either side
I started on this; should be straightforward

Revised text:
offerer to be maintained, and so the subsequent answer will contain an identical "LS" group.  <ins> The sec.detailed-example example later in this document shows a more </ins> involved case of "LS" group generation. The next step is to generate m= sections for each m= section that is 7.1. This section shows a very simple example that sets up a minimal audio  <ins> / video call between two JSEP endpoints without using trickle ICE. The example in the following section provides a more detailed example of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  Both Alice and Bob are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </ins> The SDP for |offer-A1| looks like: 7.2.  <ins> This section shows a more involved example of a session between two JSEP endpoints.  Trickle ICE is used in full trickle mode, with a bundle policy of "max-bundle", an RTCP mux policy of "require", and a single TURN server.  Initially, both Alice and Bob establish an audio channel and a data channel.  Later, Bob adds two video flows, one for his video feed, and one for screensharing, both supporting FEC, and with the video feed configured for simulcast.  Alice accepts these video flows, but does not add video flows of her own, so they are handled as recvonly.  Alice also specifies a maximum video decoder resolution. </ins> The SDP for |offer-B1| looks like:  <ins> |offer-B1-candidate-1| looks like: </ins>  <ins> |offer-B1-candidate-2| looks like: </ins>  <ins> |offer-B1-candidate-3| looks like: </ins> The SDP for |answer-B1| looks like:  <ins> |answer-B1-candidate-1| looks like: </ins>  <ins> |answer-B1-candidate-2| looks like: </ins>  <ins> |answer-B1-candidate-3| looks like: </ins>  <ins> The SDP for |offer-B2| is shown below.  In addition to the new m= sections for video, both of which are offering FEC, and one of which is offering simulcast, note the increment of the version number in the o= line, changes to the c= line, indicating the local candidate that was selected, and the inclusion of gathered candidates as a=candidate lines. </ins>  <ins> The SDP for |answer-B2| is shown below.  In addition to the acceptance of the video m= sections, the use of a=recvonly to indicate one-way video, and the use of a=imageattr to limit the received resolution, note the use of setup:passive to maintain the existing DTLS roles. </ins> 8. sec.use-of-provisional-answer.  Here, Alice's endpoint sends an offer to Bob's endpoint to start an audio/video call.  Bob immediately responds with an answer that accepts the audio/video m= sections, but  <ins> marks them as sendonly (from his perspective), meaning that Alice </ins> will not yet send media.  This allows the JSEP implementation to start negotiating ICE and DTLS immediately.  Bob's endpoint then prompts him to answer the call, and when he does, his endpoint sends before the second offer is sent, then media can be transmitted immediately by the callee immediately upon answering the call, minimizing perceived post-dial-delay.  The second offer/answer  <ins> exchange can also change the preferred codecs or other session parameters. </ins> This example also makes use of the "relay" ICE candidate policy described in sec.ice-candidate-policy to minimize the ICE gathering The SDP for |offer-C1| looks like:  <ins> |offer-C1-candidate-1| looks like: </ins> The SDP for |answer-C1| looks like:  <ins> |answer-C1-candidate-1| looks like: </ins> The SDP for |offer-C2| looks like: