Change:
I just rewrote this.
Overall this LG - if you can resolve these nits tonight, great - otherwise let's land it and clean it up later
I don't think I can get to these tonight, but I may be able to get to them tomorrow AM before Cullen does.
lgtm

Discussion:
RFC4566 is the base SDP specification and MUST be implemented. <del> RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RTP profile. </del> <ins> RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RFC5764 and TCP/TLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- registration RTP profiles. </ins> RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE

remote, MUST indicate support for the following specifications.  If any of these are absent, this omission MUST be treated as an error. <del> Either the UDP/TLS/RTP/SAVP or the UDP/TLS/RTP/SAVPF RTP profile, as specified in RFC5764, MUST be used. </del> ICE, as specified in RFC5245, MUST be used.  Note that the remote endpoint may use a Lite implementation; implementations MUST properly handle remote endpoints which do ICE-Lite. DTLS-SRTP, as specified in RFC5763, MUST be used. <ins> 5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer. For data m= sections, JSEP endpoints must support both the "UDP/TLS/ SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually selecting either either UDP or TCP. Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP endpoints MUST follow the following rules when processing the media m= sections in an offer: The profile in any "m=" line in any answer MUST exactly match the profile provided in the offer. Any profile matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of the "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e. a default value of "trr- int=0".  Otherwise, assume that AVPF is being used in an AVP compatible mode and use AVP timing, i.e., "trr-int=4". For data m= sections, JSEP endpoints MUST support receiving the "UDP/ TLS/SCTP", "TCP/TLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile strings even if the initial offer/answer exchange used an (incorrect) older profile string. </ins> 5.2. When createOffer is called, a new SDP description must be created

indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1. To properly indicate use of DTLS, the <proto> field MUST be set to <del> "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8. </del> <ins> "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport. </ins> The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates have yet been

Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> and the <proto> field MUST be set to "DTLS/SCTP" [TODO: fix this in profile PR], 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 </del> <ins> and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default candidate uses UDP transport, or "TCP/TLS/SCTP" if the default candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" value MUST be set to the SCTP port number, as specified in </ins> Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs]

have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1. <del> Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF". </del> <ins> The <proto> field MUST be set to exactly match the <proto> field for the corresponding m= line in the offer. </ins> The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates have yet been

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 <del> "application" and the <proto> field MUST be set to "DTLS/SCTP" [TODO: fix this when fixing profiles], 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.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </del> <ins> "application" and the <proto> field MUST be set to exactly match the field in the offer; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and