Draft: draft-ietf-rtcweb-jsep

Commentary: Has a similar PR been made for bundle ? 
 Yes : On We d , Nov 16 , 2016 , 4:35 PM   wrote : 
 Perhaps just wait on this for conversation on list to resolve 
 PTAL 
 PTAL 
 I think the way to handle the pending references is to do these as ordinary cross - references and Section # s and let  sort it out . 
 LGTM with one remaining nit
Paragraph (version A):
Typically, when gathering ICE candidates, the browser will gather all
possible forms of initial candidates - host, server reflexive, and
relay.  However, in certain cases, applications may want to have more
specific control over the gathering process, due to privacy or
related concerns.  For example, one may want to suppress the use of
host candidates, to avoid exposing information about the local
network, or go as far as only using relay candidates, to leak as
little location information as possible (note that these choices come
with corresponding operational costs).  To accomplish this, the
browser MUST allow the application to restrict which ICE candidates
are used in a session.  Note that this filtering is applied on top of
any restrictions the browser chooses to enforce regarding which IP
addresses are permitted for the application, as discussed in I-
D.shieh-rtcweb-ip-handling.
Paragraph (version B):
Applications request support for simulcast by configuring multiple
encodings on an RtpSender, which, upon generation of an offer or
answer, are indicated in SDP markings on the corresponding m=
section, as described below.  Receivers that understand simulcast and
are willing to receive it will also include SDP markings to indicate
their support, and JSEP endpoints will use these markings to
determine whether simulcast is permitted for a given RtpSender.  If
simulcast support is not negotiated, the RtpSender will only use the
first configured encoding.
Paragraph (version B):
JSEP currently does not provide an API to configure receipt of
simulcast.  This means that if simulcast is offered by the remote
endpoint, the answer generated by a JSEP endpoint will not indicate
support for receipt of simulcast, and as such the remote endpoint
will only send a single encoding per m= section.  In addition, when
the JSEP endpoint is the answerer, the permitted encodings for the
RtpSender must be consistent with the offer, but this information is
currently not surfaced through any API.  This means that established
simulcast streams will continue to work through a received re-offer,
but setting up initial simulcast by way of a received offer requires
out-of-band signaling or SDP inspection.  Future versions of this
specification may add additional APIs to provide this control.
Paragraph (version B):
The addTransceiver method adds a new RtpTransceiver to the
PeerConnection.  If a MediaStreamTrack argument is provided, then the
transceiver will be configured with that media type and the track
will be attached to the transceiver.  Otherwise, the application MUST
explicitly specify the type; this mode is useful for creating
recvonly transceivers as well as for creating transceivers to which a
track can be attached at some later point.
Paragraph (version A):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid attribute MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be removed.  However, a
RtpTransceiver MUST NOT be removed if the RtpTransceiver's RtpSender
was activated by the addTrack method.  This is so that an application
may call addTrack, then call setRemoteDescription with an offer, then
rollback that offer, then call createOffer and have a m= section for
the added track appear in the generated offer.
Paragraph (version B):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid property MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be stopped and removed from
the PeerConnection.  However, a RtpTransceiver MUST NOT be removed if
a track was attached to the RtpTransceiver via the addTrack method.
This is so that an application may call addTrack, then call
setRemoteDescription with an offer, then roll back that offer, then
call createOffer and have a m= section for the added track appear in
the generated offer.
Paragraph (version A):
If the RtpTransceiver's RtpSender is active, an "a=rid" line for
each encoding specified by the application in the RtpSenders's
parameters.  If no encodings have been specified, then a single
"a=rid" line is generated.  The "a=rid" line is specified in I-
D.ietf-mmusic-rid, and its direction MUST be "send".  If the
application has chosen a RID value, it MUST be used as the rid-
identifier; otherwise a RID value MUST be generated by the
implementation.  When generating RID values, it is RECOMMENDED
that the values be 3 bytes or less, to allow them to efficiently
fit into the RTP header extension defined in I-D.ietf-avtext-rid,
Section 11.
Paragraph (version B):
Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option ( sec.icerestart was specified.  If the m=
section is bundled into another m= section, it still MUST NOT
contain any ICE credentials.
Paragraph (version A):
If a local MediaStreamTrack has been associated, and RTX has been
negotiated for this m= section, another "a=ssrc" line with the RTX
SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section
4.2, with semantics set to "FID" and including the primary and RTX
SSRCs.
Paragraph (version B):
If present in the offer, an "a=rtcp-mux" line, as specified in
RFC5761, Section 5.1.3.  Otherwise, an "a=rtcp" line, as specified
in RFC3605, Section 2.1, containing the dummy value "9 IN IP4
0.0.0.0" (because no candidates have yet been gathered).
Paragraph (version B):
The payload type mapping from the remote description is used to
determine payload types for the outgoing RTP streams, including
the payload type for the send media format chosen above.  Any
RTP header extensions that were negotiated should be included
in the outgoing RTP streams, using the extension mapping from
the remote description; if the RID header extension has been
negotiated, and RID values are specified, include the RID
header extension in the outgoing RTP streams, as indicated in
I-D.ietf-mmusic-rid, Section 4.
Paragraph (version B):
If simulcast has been negotiated, send the number of Source RTP
Streams as specified in I-D.ietf-mmusic-sdp-simulcast,
Section 6.2.2.
Paragraph (version B):
If the send media format chosen above has a corresponding "rtx"
media format, or a FEC mechanism has been negotiated, establish
a Redundancy RTP Stream with a random SSRC for each Source RTP
Stream, and start or continue transmitting RTX/FEC packets as
needed.
Paragraph (version B):
If the send media format chosen above has a corresponding "red"
media format of the same clockrate, allow redundant encoding
using the specified format for resiliency purposes, as
discussed in I-D.ietf-rtcweb-fec, Section 3.2.  Note that
unlike RTX or FEC media formats, the "red" format is
transmitted on the Source RTP Stream, not the Redundancy RTP
Stream.
Paragraph (version A):
The generated MID attributes (a=mid).
Paragraph (version A):
The contents of bundle groups, bundle-only parameters, or "a=rtcp-
mux" parameters.