Draft: draft-ietf-rtcweb-jsep

Commentary: I do n't know why build of ghpages is failing travis . It works for me on my machine so going to ignore this for a bit . 
 Here is the diff of the change . 
 BLOCKER : The nits tool reports ( and a cursory hand check supports this ) that six of the references are unused , and  has been ( recently ) obsoleted . The remaining references are largely out of date by many versions , which I believe the current tools will automatically handle if version numbers are simply pulled out of the source . Finally , a large number of the referenced working group documents still use the individual name ( e.g. , draft - nandakumar - rtcweb - sdp instead of draft - ietf - rtcweb - sdp ) . 
 Need to verify section numbers when these refs change , but otherwise seems fine . 
 LGTMLG , assuming this generates the equivalent text .
Paragraph (version A):
This document describes how the W3C WEBRTC RTCPeerConnection
interface W3C.WD-webrtc-20140617 is used to control the setup,
management and teardown of a multimedia session.
Paragraph (version B):
This document describes how the W3C WEBRTC RTCPeerConnection
interface W3C.webrtc is used to control the setup, management and
teardown of a multimedia session.
Paragraph (version A):
Whether a session description applies to the local side or the remote
side affects the meaning of that description.  For example, the list
of codecs sent to a remote party indicates what the local side is
willing to receive, which, when intersected with the set of codecs
the remote side supports, specifies what the remote side should send.
However, not all parameters follow this rule; for example, the
fingerprints I-D.ietf-mmusic-4572-update sent to a remote party are
calculated based on the local certificate(s) offered; the remote
party MUST either accept these parameters or reject them altogether,
with no option to choose different values.
Paragraph (version B):
Whether a session description applies to the local side or the remote
side affects the meaning of that description.  For example, the list
of codecs sent to a remote party indicates what the local side is
willing to receive, which, when intersected with the set of codecs
the remote side supports, specifies what the remote side should send.
However, not all parameters follow this rule; for example, the
fingerprints RFC8122 sent to a remote party are calculated based on
the local certificate(s) offered; the remote party MUST either accept
these parameters or reject them altogether, with no option to choose
different values.
Paragraph (version A):
For DTLS, all m= sections MUST use all the certificate(s) that have
been specified for the PeerConnection; as a result, they MUST all
have the same I-D.ietf-mmusic-4572-update fingerprint value(s), or
these value(s) MUST be session-level attributes.
Paragraph (version B):
For DTLS, all m= sections MUST use all the certificate(s) that have
been specified for the PeerConnection; as a result, they MUST all
have the same RFC8122 fingerprint value(s), or these value(s) MUST be
session-level attributes.
Paragraph (version A):
Enable the RTCP feedback mechanisms referenced in the media
section for all Source RTP Streams using the specified media
formats.  Specifically, begin or continue sending the requested
feedback types and reacting to received feedback, as specified
in RFC4585, Section 4.2.  When sending RTCP feedback, follow
the rules and recommendations from I-D.ietf-avtcore-rtp-multi-
stream, Section 5.4.1 to select which SSRC to use.
Paragraph (version B):
Enable the RTCP feedback mechanisms referenced in the media
section for all Source RTP Streams using the specified media
formats.  Specifically, begin or continue sending the requested
feedback types and reacting to received feedback, as specified
in RFC4585, Section 4.2.  When sending RTCP feedback, follow
the rules and recommendations from RFC8108, Section 5.4.1 to
select which SSRC to use.
Paragraph (version A):
More examples of SDP for WebRTC call flows, including examples with
IPv6 addresses, can be found in I-D.nandakumar-rtcweb-sdp.
Paragraph (version B):
More examples of SDP for WebRTC call flows, including examples with
IPv6 addresses, can be found in I-D.ietf-rtcweb-sdp.