Draft: draft-ietf-rtcweb-jsep

Commentary: Add intro for what RtpTransceiver , RtpSender , and RtpReceiver are createOffer , createAnswer , setLocalDescription , setRemoteDescription based on transcievers , not tracks or streams . remove OfferToReceiveAudio and OfferToReceiveVideo LS groups based on transceivers , not tracks port 0 based on a transceiver being stopped setting when they are associated with an m= section bind m= sections from remote offer to existing RtpTransceiver when appropriate . create transceivers in setRemoteDescription if necessary ( RtpReceiver is active , RtpSender is inactive ) rollback may set an or remove an RtpTransceiver 
 This has got to the point it is hard to review on what is deleted due to the diff . Perhaps rebase to master would help . I 'll did in more to review tomorrow 
  , this looks pretty good , but changes needed . 
 LGTM with comments above 
 Few comments inline but I am OK to merge this as is or with minor changes for the comments 
 Double LGTM 
 can we merge this patch ? If so , let 's do that and publish the next version of the draft
Paragraph (version B):
RtpTransceivers allow the application to control the RTP media
associated with one m= section.  Each RtpTransceiver has an RtpSender
and an RtpReceiver, which an application can use to control the
sending and receiving RTP media.  The application may also modify the
RtpTransceiver directly, for instance, by stopping it.
Paragraph (version B):
RtpTransceivers generally have a 1:1 mapping with m= sections,
however there may be more RtpTransceivers than m= sections when
RtpTransceivers are created but not yet associated with a m= section,
or if RtpTransceivers have been stopped and disassociated from m=
sections.  An RtpTransceiver is never associated with more than one
m= section, and once a session description is applied, a m= section
is always associated with exactly one RtpTransceiver.
Paragraph (version A):
To trigger an ICE restart, for the purpose of reestablishing
connectivity.
Paragraph (version B):
The createOffer method generates a blob of SDP that contains a
RFC3264 offer 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 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 media added 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):
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 MAY also 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 A):
An "a=ice-options" line with the "trickle" option MUST be added,
as specified in I-D.ietf-mmusic-trickle-ice, Section 4.
Paragraph (version B):
The next step is to generate m= sections, as specified in RFC4566
Section 5.14, for each RtpTransceiver that has been added to the
PeerConnection via the addTrack or addTransceiver methods, excluding
stopped RtpTransceivers. m= sections are generated in the order that
their associated RtpTransceivers were added to the PeerConnection.
Paragraph (version B):
The next step is to generate session-level lip sync groups as defined
in RFC5888, Section 7.  For each MediaStream referenced by more than
one RtpTransceiver, a group of type "LS" MUST be added that contains
the mid values for each RtpTransceiver.
Paragraph (version B):
If any RtpTransceiver has been added, and there exists an m=
section with a zero port in the current local description or the
current remote description, that m= section MUST be recycled by
generating an m= section for the added RtpTransceiver as if the m=
section were being added to session description, placed at the
same index as the m= section with a zero port.
Paragraph (version B):
For RtpTransceivers with an RtpSender that is still active, the
"a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same.
Paragraph (version B):
For RtpTransceivers that are still present, any "a=simulcast" line
MUST stay the same.
Paragraph (version B):
The directional attribute MAY change, depending on the active
state of the RtpSender or RtpReceiver, and MUST have the value
specified for initial offers in sec.initial-offers.
Paragraph (version A):
The first step in generating an initial answer is to generate
session-level attributes.  The process here is identical to that
indicated in the Initial Offers section above, except that the
"a=ice-options" line, with the "trickle" option as specified in I-
D.ietf-mmusic-trickle-ice, Section 4, is only included if such an
option was present in the offer.
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
SSRCs.
Paragraph (version B):
For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc",
and "a=ssrc-group" lines MUST stay the same if they are present in
the remote description.
Paragraph (version B):
Any "a=rid" lines MUST be parsed as specified in I-D.ietf-mmusic-
rid, Section 10, and their values stored.
Paragraph (version B):
If present, a single "a=simulcast" line MUST be parsed as
specified in I-D.ietf-mmusic-sdp-simulcast, and its values stored.
Paragraph (version B):
All RID values referenced in an "a=simulcast" line MUST exist as
"a=rid" lines.
Paragraph (version B):
If the m= section is sendrecv or recvonly, and there are
RtpTransceivers of the same type that were added to the
PeerConnection by addTrack and are not associated with any
m= section and are not stopped, find the first (according to
canonical order described in sec.initial-offers) such
RtpTransceiver.
Paragraph (version B):
The generated MID attribute (a=mid).