Draft: draft-ietf-rtcweb-jsep

Commentary: a = simulcast , a = rid a = imageattr ( maybe ) differing codecs / preferences for either side 
 I started on this ; should be straightforward
Paragraph (version A):
The sec.normal-example example later in this document shows a more
involved case of "LS" group generation.
Paragraph (version B):
The sec.detailed-example example later in this document shows a more
involved case of "LS" group generation.
Paragraph (version A):
This section shows a very simple example that sets up a minimal audio
/ 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.
Paragraph (version A):
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.
Paragraph (version B):
This section shows a very simple example that sets up a minimal audio
/ 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.
Paragraph (version B):
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".
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
exchange can also change the preferred codecs or other information.
Paragraph (version B):
exchange can also change the preferred codecs or other session
parameters.