Draft: draft-ietf-rtcweb-jsep

Commentary: The SDP is all wrong in this but here is the structure I am proposing for the Examples section . This does not remove the appendix but I 'd propose we remove the whole appendix if we add this . Let me know if this looks reasonable as the outline and if so we can sort out the details of the flows and fix the SDP . The current flows and SDP are based off the XMPP flow in the appendix . 
 Overall this feels like the right direction . Originally I was thinking that we would want to have a section to show the output from createOffer / Answer by itself ( i.e. what is in the current document ) , and then we could reference those SDPs from the full call flows , but after thinking about it more I think that is probably just going to be confusing . I some comments about how I think we can simplify the simple example , and some stuff we ought to show in the complex example , but overall this LGTM . 
 Yah , Justin 's comments make sense . I 'll update and we can use this as a basis . I 'm sure the sequence diagrams and SDP have some details that are wrong but we can sort theses out over time . The one thing is I am still leaning to making the simple example contains both minimal audio and video but will give some thought . Agree adding screen share to existing call to full example makes sense . 
 I suggest we get the first example clean and then move onto the second . 
 Is this ready for another look ? 
 Cullen to update this PR with a skeleton for 2 examples : a ) simple example with audio / video , no BUNDLE , no trickle b ) fancy example with audio / video / data , BUNDLE , trickle , renegotiate to add screenshare 
 This one is ready for your EKR & Justin to review . 
 OK , I think that 's all the comments for today . 
 Resolved all Justin 's comments but there is one thing that I think deserves both of you looking at . In the second example , look at where in the flow the " candidate - B2 is sent to  " section happens . Basically it is a question of when does  send the a tickle ICE candidate . This was wrong before and I think I have it right now but that is the only significant change . 
 LGTM once outstanding comments are resolved 
 LGTM once these comments are resolved as well . If we decide to do , etc . we might want to do it as a different PR . 
 LG with these minor nits . Let 's discuss and edit today and then we can land this . 
 Currently , the examples only show non - trickle cases . 
 Justin to add trickle cases , rearrange a.1 and a.2 , check in a generator tool . 
 Check out before starting on this . It does not fix the stuff but we may want to merge it first and use as starting point . 
 Fixed in -08
Paragraph (version B):
No SDP has been received from the other side, so it is not known
if it can handle trickle.  This is the initial value before
setRemoteDescription() is called.
Paragraph (version B):
SDP has been received from the other side indicating that it can
support trickle.
Paragraph (version B):
SDP has been received from the other side indicating that it
cannot support trickle.
Paragraph (version B):
As described in sec.ice-candidate-trickling, JSEP implementations
always provide candidates to the application individually, consistent
with what is needed for Trickle ICE.  However, applications can use
the canTrickle property to determine whether they can actually do
Trickle ICE, i.e. safely send an initial offer or answer followed
later by candidates as they are gathered.  As "true" is the only
value that definitively indicates remote Trickle ICE support, an
application which compares canTrickle against "true" will by default
attempt Half Trickle on initial offers and Full Trickle on subsequent
interactions with a Trickle ICE-compatible agent.
Paragraph (version A):
The port value is set to the port of the default ICE candidate for
this m= section; if this m= section is not being bundled into
another m= section, the port value MUST be unique.  If no
candidates have yet been gathered, and a 'null' port value is
being used, as indicated in I-D.ietf-mmusic-trickle-ice,
Section 5.1., this port MUST still be unique.
Paragraph (version A):
An "a=mid" line, as specified in RFC5888, Section 4.
Paragraph (version A):
For each supported RTP header extension, an "a=extmap" line, as
specified in RFC5285, Section 5.  The list of header extensions
that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-
usage, Section 5.2.  Any header extensions that require encryption
MUST be specified as indicated in RFC6904, Section 4.
Paragraph (version B):
For each supported RTP header extension, an "a=extmap" line, as
specified in RFC5285, Section 5.  The list of header extensions
that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-
usage, Section 5.2.  [TODO: ensure that urn:ietf:params:rtp-
hdrext:sdes:mid appears either there or here] Any header
extensions that require encryption MUST be specified as indicated
in RFC6904, Section 4.
Paragraph (version A):
If the BUNDLE policy for this PeerConnection is set to "max-
bundle", and this is not the first m= section, or the BUNDLE
policy is set to "default", and this is not the first m= section
for this media type, an "a=bundle-only" line.
Paragraph (version A):
Lastly, if a data channel has been created, a m= section MUST be
generated for data.  The <media> field MUST be set to "application"
and the <proto> field MUST be set to "DTLS/SCTP", as specified in I-
D.ietf-mmusic-sctp-sdp, Section 3; the "fmt" value MUST be set to the
SCTP port number, as specified in Section 4.1.
Paragraph (version B):
If the BUNDLE policy for this PeerConnection is set to "max-
bundle", and this is not the first m= section, or the BUNDLE
policy is set to "balanced", and this is not the first m= section
for this media type, an "a=bundle-only" line.
Paragraph (version A):
If the "OfferToReceiveAudio" option is specified, with an integer
value of N, the offer MUST include N non-rejected m= sections with
media type "audio", even if fewer than N audio MediaStreamTracks have
been added to the PeerConnection.  This allows the offerer to receive
audio, including multiple independent streams, even when not sending
it; accordingly, the directional attribute on the audio m= sections
without associated MediaStreamTracks MUST be set to recvonly.  If
this option is specified in the case where at least N audio
MediaStreamTracks have already been added to the PeerConnection, or N
non-rejected m= sections with media type "audio" would otherwise be
generated, it has no effect.  For backwards compatibility with pre-
standard versions of this specification, a value of "true" is
interpreted as equivalent to N=1.
Paragraph (version A):
If the "OfferToReceiveVideo" option is specified, with an integer
value of N, the offer MUST include N non-rejected m= sections with
media type "video", even if fewer than N video MediaStreamTracks have
been added to the PeerConnection.  This allows the offerer to receive
video, including multiple independent streams, even when not sending
it; accordingly, the directional attribute on the video m= sections
without associated MediaStreamTracks MUST be set to recvonly.  If
this option is specified in the case where at least N video
MediaStreamTracks have already been added to the PeerConnection, or N
non-rejected m= sections with media type "video" would otherwise be
generated, it has no effect.  For backwards compatibility with pre-
standard versions of this specification, a value of "true" is
interpreted as equivalent to N=1.
Paragraph (version A):
For each supported RTP header extension that is present in the
offer, an "a=extmap" line, as specified in RFC5285, Section 5.
The list of header extensions that SHOULD/MUST be supported is
specified in I-D.ietf-rtcweb-rtp-usage, Section 5.2.  Any header
extensions that require encryption MUST be specified as indicated
in RFC6904, Section 4.
Paragraph (version B):
For each supported RTP header extension that is present in the
offer, an "a=extmap" line, as specified in RFC5285, Section 5.
The list of header extensions that SHOULD/MUST be supported is
specified in I-D.ietf-rtcweb-rtp-usage, Section 5.2.  [TODO:
Ensure this contains MID header] Any header extensions that
require encryption MUST be specified as indicated in RFC6904,
Section 4.
Paragraph (version A):
If a data channel m= section has been offered, a m= section MUST also
be generated for data.  The <media> field MUST be set to
"application" and the <proto> field MUST be set to "DTLS/SCTP", as
specified in I-D.ietf-mmusic-sctp-sdp, Section 3; the "fmt" value
MUST be set to the SCTP port number, as specified in Section 4.1.
Paragraph (version B):
Note that this example section shows several SDP fragments.  To
format in 72 columns, some of the lines in SDP have been split into
multiple lines, where leading whitespace indicates that a line is a
continuation of the previous line.  In addition, some blank lines
have been added to improve readability but are not valid in SDP.
Paragraph (version B):
More examples of SDP for WebRTC call flows can be found in I-
D.nandakumar-rtcweb-sdp.
Paragraph (version B):
This section shows a typical example of a session between two
browsers setting up an audio channel and a data channel.  Trickle ICE
is used in full trickle mode with a policy of max-bundle-and-rtcpmux
and a single TURN server.  Later, two video flows, one for the
presenter and one for screen sharing, are added to the session.  This
example shows Alice's browser initiating the session to Bob's
browser.  The messages from Alice's JS to Bob's JS are assumed to
flow over some signaling protocol via a web server.