Draft: draft-ietf-rtcweb-jsep

Commentary: … or already fixed . Change in normative text ( previous ART AD requested it ) , please review . 
 LGTM , approved . 
 eom 
 LGTMOne minor comment .
Paragraph (version A):
JSEP's handling of session descriptions is simple and
straightforward.  Whenever an offer/answer exchange is needed, the
initiating side creates an offer by calling a createOffer API.  The
application then uses that offer to set up its local config via the
setLocalDescription API.  The offer is finally sent off to the remote
side over its preferred signaling mechanism (e.g., WebSockets); upon
receipt of that offer, the remote party installs it using the
setRemoteDescription API.
Paragraph (version B):
JSEP's handling of session descriptions is simple and
straightforward.  Whenever an offer/answer exchange is needed, the
initiating side creates an offer by calling a createOffer API.  The
application then uses that offer to set up its local configuration
via the setLocalDescription API.  The offer is finally sent off to
the remote side over its preferred signaling mechanism (e.g.,
WebSockets); upon receipt of that offer, the remote party installs it
using the setRemoteDescription API.
Paragraph (version A):
Through its abstraction of signaling, the JSEP approach does require
the application to be aware of the signaling process.  While the
application does not need to understand the contents of session
descriptions to set up a call, the application must call the right
APIs at the right times, convert the session descriptions and ICE
information into the defined messages of its chosen signaling
protocol, and perform the reverse conversion on the messages it
receives from the other side.
Paragraph (version B):
Although it abstracts signaling, the JSEP approach requires that the
application be aware of the signaling process.  While the application
does not need to understand the contents of session descriptions to
set up a call, the application must call the right APIs at the right
times, convert the session descriptions and ICE information into the
defined messages of its chosen signaling protocol, and perform the
reverse conversion on the messages it receives from the other side.
Paragraph (version A):
The IceCandidate object contains a field to indicate which ICE ufrag
it is associated with, as defined in RFC8839.  This value is used to
determine which session description (and thereby which gathering
phase) this IceCandidate belongs to, which helps resolve ambiguities
during ICE restarts.  If this field is absent in a received
IceCandidate (perhaps when communicating with a non-JSEP endpoint),
the most recently received session description is assumed.
Paragraph (version B):
The IceCandidate object contains a field to indicate which ICE
username fragment (ufrag) it is associated with, as defined in
RFC8839.  This value is used to determine which session description
(and thereby which gathering phase) this IceCandidate belongs to,
which helps resolve ambiguities during ICE restarts.  If this field
is absent in a received IceCandidate (perhaps when communicating with
a non-JSEP endpoint), the most recently received session description
is assumed.
Paragraph (version A):
The receiver will first intersect any known local limits (e.g.,
hardware decoder capabilities, local policy) to determine the
absolute minimum and maximum sizes it can receive.  If there are no
known local limits, the "a=imageattr" attribute SHOULD be omitted.
If these local limits preclude receiving any video, i.e., the
degenerate case of no permitted resolutions, the "a=imageattr"
attribute MUST be omitted, and the "m=" section MUST be marked as
sendonly/inactive, as appropriate.
Paragraph (version B):
The receiver will first combine any known local limits (e.g.,
hardware decoder capabilities or local policy) to determine the
absolute minimum and maximum sizes it can receive.  If there are no
known local limits, the "a=imageattr" attribute SHOULD be omitted.
If these local limits preclude receiving any video, i.e., the
degenerate case of no permitted resolutions, the "a=imageattr"
attribute MUST be omitted, and the "m=" section MUST be marked as
sendonly/inactive, as appropriate.
Paragraph (version A):
The createOffer method generates a blob of SDP that contains an offer
per RFC3264 with the supported configurations for the session,
including descriptions of the media added to this PeerConnection, the
codec/RTP/RTCP options supported by this implementation, and any
candidates that have been gathered by the ICE agent.  An options
parameter may be supplied to provide additional control over the
generated offer.  This options parameter allows an application to
trigger an ICE restart, for the purpose of reestablishing
connectivity.
Paragraph (version B):
The createOffer method generates a blob of SDP that contains an offer
per RFC3264 with the supported configurations for the session,
including descriptions of the media added to this PeerConnection, the
codec, RTP, and RTCP options supported by this implementation, and
any candidates that have been gathered by the ICE agent.  An options
parameter may be supplied to provide additional control over the
generated offer.  This options parameter allows an application to
trigger an ICE restart, for the purpose of reestablishing
connectivity.
Paragraph (version A):
In the initial offer, the generated SDP will contain all desired
functionality for the session (functionality that is supported but
not desired by default may be omitted); for each SDP line, the
generation of the SDP will follow the process defined for generating
an initial offer from the document that specifies the given SDP line.
The exact handling of initial offer generation is detailed in
sec.initial-offers below.
Paragraph (version B):
In the initial offer, the generated SDP will contain all desired
functionality for the session (functionality that is supported but
not desired by default may be omitted); for each SDP line, the
generation of the SDP will follow the process defined for generating
an initial offer from the specification that defines the given SDP
line.  The exact handling of initial offer generation is detailed in
sec.initial-offers below.
Paragraph (version A):
As an answer, the generated SDP will contain a specific configuration
that specifies how the media plane should be established; for each
SDP line, the generation of the SDP MUST follow the process defined
for generating an answer from the document that specifies the given
SDP line.  The exact handling of answer generation is detailed in
sec.generating-an-answer below.
Paragraph (version B):
As an answer, the generated SDP will contain a specific configuration
that specifies how the media plane should be established; for each
SDP line, the generation of the SDP MUST follow the process defined
for generating an answer from the specification that defines the
given SDP line.  The exact handling of answer generation is detailed
in sec.generating-an-answer below.