Draft: draft-ietf-rtcweb-jsep

Commentary: I 'd like to talk for a few minutes about the trickle normative or not issue but that 's not the end of the world for me either way . Other than that LGTM . 
 Happy to talk about this tomorrow , but I do n't really think that whether draft is in the Normative or Informative section that 's important here . The draft as it currently stands tells the user to do stuff that 's described in trickle ICE , so I do n't really see how it 's not normative . 
 LGTM with nits above 
 This is ready to push pending Cullen 's approval on the normative reference . 
 I am going to merge this as - is in the interest of expedience . When we fix PR we can also change the location of the reference .
Paragraph (version A):
This document describes how the W3C WEBRTC RTCPeerConnection
interfaceW3C.WD-webrtc-20111027 is used to control the setup,
management and teardown of a multimedia session.
Paragraph (version B):
This document describes how the W3C WEBRTC RTCPeerConnection
interfaceW3C.WD-webrtc-20140617 is used to control the setup,
management and teardown of a multimedia session.
Paragraph (version A):
The IceCandidate object also contains fields to indicate which m=
line it should be associated with.  The m line can be identified in
one of two ways; either by a m-line index, or a MID.  The m-line
index is a zero-based index, referring to the Nth m-line in the SDP.
The MID uses the "media stream identification", as defined in RFC5888
, to identify the m-line.  WebRTC implementations creating an ICE
Candidate object MUST populate both of these fields.  Implementations
receiving an ICE Candidate object SHOULD use the MID if they
implement that functionality, or the m-line index, if not.
Paragraph (version B):
The IceCandidate object also contains fields to indicate which m=
line it should be associated with.  The m line can be identified in
one of two ways; either by a m-line index, or a MID.  The m-line
index is a zero-based index, with index N referring to the N+1th
m-line in the SDP sent by the entity which sent the IceCandidate.
The MID uses the "media stream identification", as defined in
RFC5888, to identify the m-line.  WebRTC implementations creating an
ICE Candidate object MUST populate both of these fields.
Implementations receiving an ICE Candidate object SHOULD use the MID
if they implement that functionality, or the m-line index, if not.
Paragraph (version A):
In the parallel forking case where the Javascript application wishes
to simultaneously exchange media with multiple peers, the flow is
slightly more complex, but the Javascript application can follow the
strategy that RFC3960 describes using UPDATE.  (It is worth noting
that use cases where this is the desired behavior are very unusual.)
The UPDATE approach allows the signaling to set up a separate media
flow for each peer that it wishes to exchange media with.  In JSEP,
this offer used in the UPDATE would be formed by simply creating a
new PeerConnection and making sure that the same local media streams
have been added into this new PeerConnection.  Then the new
PeerConnection object would produce a SDP offer that could be used by
the signaling to perform the UPDATE strategy discussed in RFC3960.
Paragraph (version B):
In the parallel forking case where the Javascript application wishes
to simultaneously exchange media with multiple peers, the flow is
slightly more complex, but the Javascript application can follow the
strategy that RFC3960 describes using UPDATE.  The UPDATE approach
allows the signaling to set up a separate media flow for each peer
that it wishes to exchange media with.  In JSEP, this offer used in
the UPDATE would be formed by simply creating a new PeerConnection
and making sure that the same local media streams have been added
into this new PeerConnection.  Then the new PeerConnection object
would produce a SDP offer that could be used by the signaling to
perform the UPDATE strategy discussed in RFC3960.
Paragraph (version A):
The application will BUNDLE all media streams of the same type
together.  That is, if there are multiple audio and multiple video
MediaStreamTracks attached to a PeerConnection, all but the first
audio and video tracks will be marked as bundle-only, and
candidates will only be gathered for N media streams, where N is
the number of distinct media types.  When talking to a non-BUNDLE-
aware endpoint, only the non-bundle-only streams will be
negotiated.  This policy balances desire to multiplex with the
need to ensure basic audio and video still works in legacy cases.
Paragraph (version A):
The application will BUNDLE all of its media streams on a single
transport.  All streams other than the first will be marked as
bundle-only.  This policy aims to minimize candidate gathering and
maximize multiplexing, at the cost of less compatibility with
legacy endpoints.
Paragraph (version B):
The application will BUNDLE all media streams of the same type
together.  That is, if there are multiple audio and multiple video
MediaStreamTracks attached to a PeerConnection, all but the first
audio and video tracks will be marked as bundle-only, and
candidates will only be gathered for N media streams, where N is
the number of distinct media types.  When talking to a non-BUNDLE-
aware endpoint, only the non-bundle-only streams will be
negotiated.  This policy balances desire to multiplex with the
need to ensure basic audio and video still works in legacy cases.
Data channels will be in a separate bundle group.
Paragraph (version B):
The application will BUNDLE all of its media streams, including
data channels, on a single transport.  All streams other than the
first will be marked as bundle-only.  This policy aims to minimize
candidate gathering and maximize multiplexing, at the cost of less
compatibility with legacy endpoints.
Paragraph (version A):
The createAnswer method generates a blob of SDP that contains a
RFC3264 SDP answer with the supported configuration for the session
that is compatible with the parameters supplied in the offer.  Like
createOffer, the returned blob contains descriptions of the local
MediaStreams attached to this PeerConnection, the codec/RTP/RTCP
options negotiated for this session, and any candidates that have
been gathered by the ICE Agent.  An options parameter may be supplied
to provide additional control over the generated answer.
Paragraph (version B):
The createAnswer method generates a blob of SDP that contains a
RFC3264 SDP answer with the supported configuration for the session
that is compatible with the parameters supplied in the most recent
call to setRemoteDescription, which MUST have been called prior to
calling createAnswer.  Like createOffer, the returned blob contains
descriptions of the local MediaStreams attached to this
PeerConnection, the codec/RTP/RTCP options negotiated for this
session, and any candidates that have been gathered by the ICE Agent.
An options parameter may be supplied to provide additional control
over the generated answer.
Paragraph (version A):
answer exchange open, which means the caller cannot send an updated
offer during this time.
Paragraph (version B):
answer exchange open, which means that neither side can send an
updated offer during this time.
Paragraph (version A):
As an example, consider a typical web application that will set up a
data channel, an audio channel, and a video channel.  When an
endpoint receives an offer with these channels, it could send an
answer accepting the data channel for two-way data, and accepting the
audio and video tracks as inactive or receive-only.  It could then
ask the user to accept the call, acquire the local media streams, and
send a new offer to the remote side moving the audio and video to be
two-way media.  By the time the human has accepted the call and
triggered the new offer, it is likely that the ICE and DTLS
handshaking for all the channels will already be set up.
Paragraph (version B):
As an example, consider a typical web application that will set up a
data channel, an audio channel, and a video channel.  When an
endpoint receives an offer with these channels, it could send an
answer accepting the data channel for two-way data, and accepting the
audio and video tracks as inactive or receive-only.  It could then
ask the user to accept the call, acquire the local media streams, and
send a new offer to the remote side moving the audio and video to be
two-way media.  By the time the human has accepted the call and
triggered the new offer, it is likely that the ICE and DTLS
handshaking for all the channels will already have finished.
Paragraph (version A):
A rollback discards any proposed changes to the session, returning
the state machine to the stable state, and setting the modified local
and/or remote description back to their previous values.  Any
resources or candidates that were allocated by the abandoned local
description are discarded; any media that is received will be
processed according to the previous local and remote descriptions.
Rollback can only be used to cancel proposed changes; there is no
support for rolling back from a stable state to a previous stable
state.
Paragraph (version B):
A rollback discards any proposed changes to the session, returning
the state machine to the stable state, and setting the modified local
and/or remote description back to their previous values.  Any
resources or candidates that were allocated by the abandoned local
description are discarded; any media that is received will be
processed according to the previous local and remote descriptions.
Rollback can only be used to cancel proposed changes; there is no
support for rolling back from a stable state to a previous stable
state.  Note that this implies that once the answerer has performed
setLocalDescription with his answer, this cannot be rolled back.
Paragraph (version A):
The next step is to generate m= sections for each MediaStreamTrack
that has been added to the PeerConnection via the addStream method.
(Note that this method takes a MediaStream, which can contain
multiple MediaStreamTracks, and therefore multiple m= sections can be
generated even if addStream is only called once.) m=sections MUST be
sorted first by the order the order in which the MediaStreams were
added to the PeerConnection, and then by the alphabetical ordering of
the media type for the MediaStreamTrack.  For example, if a
MediaStream containing both an audio and a video MediaStreamTrack is
added to a PeerConnection, the resultant m=audio section will precede
the m=video section.  If a second MediaStream containing an audio
MediaStreamTrack was added, it would follow the m=video section.
Paragraph (version B):
The next step is to generate m= sections for each MediaStreamTrack
that has been added to the PeerConnection via the addStream method.
(Note that this method takes a MediaStream, which can contain
multiple MediaStreamTracks, and therefore multiple m= sections can be
generated even if addStream is only called once.) m=sections MUST be
sorted first by the order in which the MediaStreams were added to the
PeerConnection, and then by the alphabetical ordering of the media
type for the MediaStreamTrack.  For example, if a MediaStream
containing both an audio and a video MediaStreamTrack is added to a
PeerConnection, the resultant m=audio section will precede the
m=video section.  If a second MediaStream containing an audio
MediaStreamTrack was added, it would follow the m=video section.
Paragraph (version A):
Once all m= sections have been generated, a session-level "a=group"
attribute MUST be added as specified in RFC5888.  This attribute MUST
have semantics "BUNDLE", and MUST include the mid identifiers of each
m= section.
Paragraph (version B):
Once all m= sections have been generated, a session-level "a=group"
attribute MUST be added as specified in RFC5888.  This attribute MUST
have semantics "BUNDLE", and MUST include the mid identifiers of each
m= section.  The effect of this is that the browser offers all m=
sections as one BUNDLE group.  However, whether the m= sections are
bundle-only or not depends on the BUNDLE policy.
Paragraph (version A):
If any MediaStreamTracks have been added, and there exist recvonly
m= sections of the appropriate media type with no associated
MediaStreamTracks, or rejected m= sections of any media type,
those m= sections MUST be recycled, and the local
MediaStreamTracks associated with these recycled m= sections.
This includes any recvonly or rejected m= sections created by the
preceding paragraph.
Paragraph (version B):
If any MediaStreamTracks have been added, and there exist recvonly
m= sections of the appropriate media type with no associated
MediaStreamTracks, or rejected m= sections of any media type,
those m= sections MUST be recycled, and a local MediaStreamTrack
associated with these recycled m= sections until all such existing
m= sections have been used.  This includes any recvonly or
rejected m= sections created by the preceding paragraph.