Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 LGTM with nit above 
 Justin to respond on the list and the changes to be attached to this issue . 
 Editorial changes : Section 3.2 , Paragraph 4 Should read " only after an offer " . yep Section 3.4.2 , Paragraph 1 " ... the number of media streams for which to gather candidates . " ok , not a fan of ending a sentence with a preposition , I see . I 'll go along with this one . Section 3.5 , Paragraph 1 Should say , " ... the media plane that is relevant . " yep Section 4.1.5 , Paragraph 2 and 3 Maybe I 'm alone on this but I prefer the following : " Calling this API changes the local media state . " The API does n't do anything on its own , but is a mechanism for calling some action . ( Same issue as above ) " The candidate gathering process is indirectly controlled through this API . " Will think this over . Overall , want to be consistent in how the term ' API ' is used . Section 5.2.1 , Paragraph 4 " into which it is being bundled . " ok Section 5.2.1 , Paragraph 5 Space needed after RFC reference . yep Section 5.2.1 , Paragraph 7 , bullet 6 " of " yep Section 5.2.1 , Paragraph 7 , bullet 11 " specified " yep Section 5.3.1 , Paragraph 7 " then be generated ... " yep Section 5.3.1 , Paragraph 7 , bullet 4 " ... and there is a local MediaStreamTrack that has been associated ... " indeed , not my best work Section 5.3.1 , Paragraph 7 , bullet 5 " ... Section 3 , MUST be supported . " yep Section 5.3.1 , Paragraph 7 , bullet 6 " ... the payload type of the primary ... " yep Section 5.3.1 , Paragraph 7 , bullet 11 " ... as specified in ... " yep
Paragraph (version A):
Lastly, while the exact media parameters are only known only after a
offer and an answer have been exchanged, it is possible for the
offerer to receive media after they have sent an offer and before
they have received an answer.  To properly process incoming media in
this case, the offerer's media handler must be aware of the details
of the offer before the answer arrives.
Paragraph (version B):
Lastly, while the exact media parameters are only known only after an
offer and an answer have been exchanged, it is possible for the
offerer to receive media after they have sent an offer and before
they have received an answer.  To properly process incoming media in
this case, the offerer's media handler must be aware of the details
of the offer before the answer arrives.
Paragraph (version A):
JSEP applications typically inform the browser to begin ICE gathering
via the information supplied to setLocalDescription, as this is where
the app specifies the number of media streams to gather candidates
for.  However, to accelerate cases where the browser knows the number
of media streams to use ahead of time, the application MAY ask the
browser to gather a pool of potential ICE candidates to help ensure
rapid media setup.  When setLocalDescription is eventually called,
and the browser goes 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 the ICE candidate callback.  If the pool
becomes depleted, either because a larger-than-expected number of
media streams is used, or because the pool has not had enough time to
gather candidates, the remaining candidates are gathered as usual.
Paragraph (version B):
JSEP applications typically inform the browser to begin ICE gathering
via the information supplied to setLocalDescription, as this is where
the app specifies the number of media streams for which to gather
candidates.  However, to accelerate cases where the browser knows the
number of media streams to use ahead of time, the application MAY ask
the browser to gather a pool of potential ICE candidates to help
ensure rapid media setup.  When setLocalDescription is eventually
called, and the browser goes 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 the ICE candidate callback.  If the pool
becomes depleted, either because a larger-than-expected number of
media streams is used, or because the pool has not had enough time to
gather candidates, the remaining candidates are gathered as usual.
Paragraph (version A):
Each m= section, provided it is not being bundled into another m=
section, MUST generate a unique set of ICE credentials and gather its
own unique set of ICE candidates.  Otherwise, it MUST use the same
ICE credentials and candidates that were used in the m= section that
it is being bundled into.  Note that this means that for offers, any
m= sections which are not bundle-only MUST have unique ICE
credentials and candidates, since it is possible that the answerer
will accept them without bundling them.
Paragraph (version A):
For DTLS, all m= sections MUST use the certificate for the identity
that has been specified for the PeerConnection; as a result, they
MUST all have the same RFC4572fingerprint value, or this value MUST
be a session-level attribute.
Paragraph (version B):
Each m= section, provided it is not being bundled into another m=
section, MUST generate a unique set of ICE credentials and gather its
own unique set of ICE candidates.  Otherwise, it MUST use the same
ICE credentials and candidates as the m= section into which it is
being bundled.  Note that this means that for offers, any m= sections
which are not bundle-only MUST have unique ICE credentials and
candidates, since it is possible that the answerer will accept them
without bundling them.
Paragraph (version B):
For DTLS, all m= sections MUST use the certificate for the identity
that has been specified for the PeerConnection; as a result, they
MUST all have the same RFC4572 fingerprint value, or this value MUST
be a session-level attribute.
Paragraph (version A):
For each primary codec where RTP retransmission should be used, a
corresponding "a=rtpmap" line indicating "rtx" with the clock rate
of the primary codec and an "a=fmtp" line that references the
payload type fo the primary codec, as specified in RFC4588,
Section 8.1.
Paragraph (version B):
For each primary codec where RTP retransmission should be used, a
corresponding "a=rtpmap" line indicating "rtx" with the clock rate
of the primary codec and an "a=fmtp" line that references the
payload type of the primary codec, as specified in RFC4588,
Section 8.1.
Paragraph (version A):
Depending on the directionality of the offer, the disposition of
any associated remote MediaStreamTrack, and the presence of an
associated local MediaStreamTrack, the appropriate directionality
attribute, as specified in RFC3264, Section 6.1.  If the offer was
sendrecv, and the remote MediaStreamTrack is still "live", and
there a local MediaStreamTrack has been associated, the
directionality MUST be set as sendrecv.  If the offer was
sendonly, and the remote MediaStreamTrack is still "live", the
directionality MUST be set as recvonly.  If the offer was
recvonly, and a local MediaStreamTrack has been associated, the
directionality MUST be set as sendonly.  If the offer was
inactive, the directionality MUST be set as inactive.
Paragraph (version B):
Depending on the directionality of the offer, the disposition of
any associated remote MediaStreamTrack, and the presence of an
associated local MediaStreamTrack, the appropriate directionality
attribute, as specified in RFC3264, Section 6.1.  If the offer was
sendrecv, and the remote MediaStreamTrack is still "live", and
there is a local MediaStreamTrack that has been associated, the
directionality MUST be set as sendrecv.  If the offer was
sendonly, and the remote MediaStreamTrack is still "live", the
directionality MUST be set as recvonly.  If the offer was
recvonly, and a local MediaStreamTrack has been associated, the
directionality MUST be set as sendonly.  If the offer was
inactive, the directionality MUST be set as inactive.
Paragraph (version A):
For each supported codec that is present in the offer, "a=rtpmap"
and "a=fmtp" lines, as specified in RFC4566, Section 6, and
RFC3264, Section 6.1.  For audio, the codecs specified in I-
D.ietf-rtcweb-audio, Section 3, MUST be be supported.  Note that
for simplicity, the answerer MAY use different payload types for
codecs than the offerer, as it is not prohibited by Section 6.1.
Paragraph (version A):
If "rtx" is present in the offer, for each primary codec where RTP
retransmission should be used, a corresponding "a=rtpmap" line
indicating "rtx" with the clock rate of the primary codec and an
"a=fmtp" line that references the payload type fo the primary
codec, as specified in RFC4588, Section 8.1.
Paragraph (version B):
For each supported codec that is present in the offer, "a=rtpmap"
and "a=fmtp" lines, as specified in RFC4566, Section 6, and
RFC3264, Section 6.1.  For audio, the codecs specified in I-
D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for
simplicity, the answerer MAY use different payload types for
codecs than the offerer, as it is not prohibited by Section 6.1.
Paragraph (version B):
If "rtx" is present in the offer, for each primary codec where RTP
retransmission should be used, a corresponding "a=rtpmap" line
indicating "rtx" with the clock rate of the primary codec and an
"a=fmtp" line that references the payload type of the primary
codec, as specified in RFC4588, Section 8.1.