draft-ietf-rtcweb-jsep-25.txt   draft-ietf-rtcweb-jsep-26.txt 
Network Working Group J. Uberti Network Working Group J. Uberti
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: April 25, 2019 Cisco Expires: August 31, 2019 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
October 22, 2018 February 27, 2019
JavaScript Session Establishment Protocol JavaScript Session Establishment Protocol
draft-ietf-rtcweb-jsep-25 draft-ietf-rtcweb-jsep-26
Abstract Abstract
This document describes the mechanisms for allowing a JavaScript This document describes the mechanisms for allowing a JavaScript
application to control the signaling plane of a multimedia session application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API, and via the interface specified in the W3C RTCPeerConnection API, and
discusses how this relates to existing signaling protocols. discusses how this relates to existing signaling protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on August 31, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 40 skipping to change at page 3, line 40
5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57
5.5. Processing a Local Description . . . . . . . . . . . . . 57 5.5. Processing a Local Description . . . . . . . . . . . . . 57
5.6. Processing a Remote Description . . . . . . . . . . . . . 58 5.6. Processing a Remote Description . . . . . . . . . . . . . 58
5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58 5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58
5.8. Parsing a Session Description . . . . . . . . . . . . . . 59 5.8. Parsing a Session Description . . . . . . . . . . . . . . 59
5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 60 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 60
5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61 5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61
5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64 5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64
5.9. Applying a Local Description . . . . . . . . . . . . . . 65 5.9. Applying a Local Description . . . . . . . . . . . . . . 65
5.10. Applying a Remote Description . . . . . . . . . . . . . . 67 5.10. Applying a Remote Description . . . . . . . . . . . . . . 67
5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 70 5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 71
6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 73 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 74
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74
7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78
7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88
8. Security Considerations . . . . . . . . . . . . . . . . . . . 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 95
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.1. Normative References . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 96
11.2. Informative References . . . . . . . . . . . . . . . . . 100 11.2. Informative References . . . . . . . . . . . . . . . . . 100
skipping to change at page 35, line 36 skipping to change at page 35, line 36
o DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as o DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as
appropriate for the media type, as specified in appropriate for the media type, as specified in
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as
discussed in [I-D.ietf-rtcweb-security-arch]. discussed in [I-D.ietf-rtcweb-security-arch].
5.1.2. Profile Names and Interoperability 5.1.2. Profile Names and Interoperability
For media m= sections, JSEP implementations MUST support the For media m= sections, JSEP implementations MUST support the
"UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764] as well as the
this profile for each media m= line they produce in an offer. For "TCP/DTLS/RTP/SAVPF" profile specified in [RFC7850], and MUST
data m= sections, implementations MUST support the "UDP/DTLS/SCTP" indicate one of these profiles for each media m= line they produce in
profile and MUST indicate this profile for each data m= line they an offer. For data m= sections, implementations MUST support the
produce in an offer. Although these profiles are formally associated "UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile, and
with UDP, ICE can select either UDP [RFC8445] or TCP [RFC6544] MUST indicate one of these profiles for each data m= line they
transport depending on network conditions, even when advertising a produce in an offer. The exact profile to use is determined by the
UDP profile. protocol associated with the current default or selected ICE
candidate, as described in [I-D.ietf-mmusic-ice-sip-sdp],
Section 3.2.1.2.
Unfortunately, in an attempt at compatibility, some endpoints Unfortunately, in an attempt at compatibility, some endpoints
generate other profile strings even when they mean to support one of generate other profile strings even when they mean to support one of
these profiles. For instance, an endpoint might generate "RTP/AVP" these profiles. For instance, an endpoint might generate "RTP/AVP"
but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its
willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF".
In order to simplify compatibility with such endpoints, JSEP In order to simplify compatibility with such endpoints, JSEP
implementations MUST follow the following rules when processing the implementations MUST follow the following rules when processing the
media m= sections in a received offer: media m= sections in a received offer:
o Any profile in the offer matching one of the following MUST be o Any profile in the offer matching one of the following MUST be
accepted: accepted:
* "RTP/AVP" (Defined in [RFC4566], Section 8.2.2) * "RTP/AVP" (Defined in [RFC4566], Section 8.2.2)
* "RTP/AVPF" (Defined in [RFC4585], Section 9) * "RTP/AVPF" (Defined in [RFC4585], Section 9)
skipping to change at page 37, line 27 skipping to change at page 37, line 27
The first step in generating an initial offer is to generate session- The first step in generating an initial offer is to generate session-
level attributes, as specified in [RFC4566], Section 5. level attributes, as specified in [RFC4566], Section 5.
Specifically: Specifically:
o The first SDP line MUST be "v=0", as specified in [RFC4566], o The first SDP line MUST be "v=0", as specified in [RFC4566],
Section 5.1 Section 5.1
o The second SDP line MUST be an "o=" line, as specified in o The second SDP line MUST be an "o=" line, as specified in
[RFC4566], Section 5.2. The value of the <username> field SHOULD [RFC4566], Section 5.2. The value of the <username> field SHOULD
be "-". The sess-id MUST be representable by a 64-bit signed be "-". The sess-id MUST be representable by a 64-bit signed
integer, and the initial value MUST be less than (2**62)-1, as integer, and the value MUST be less than (2**63)-1. It is
required by [RFC3264]. It is RECOMMENDED that the sess-id be RECOMMENDED that the sess-id be constructed by generating a 64-bit
constructed by generating a 64-bit quantity with the two highest quantity with the highest bit set to zero and the remaining 63
bits being set to zero and the remaining 62 bits being bits being cryptographically random. The value of the <nettype>
cryptographically random. The value of the <nettype> <addrtype> <addrtype> <unicast-address> tuple SHOULD be set to a non-
<unicast-address> tuple SHOULD be set to a non-meaningful address, meaningful address, such as IN IP4 0.0.0.0, to prevent leaking a
such as IN IP4 0.0.0.0, to prevent leaking the local address in local IP address in this field; this problem is discussed in
this field. As mentioned in [RFC4566], the entire o= line needs [I-D.ietf-rtcweb-ip-handling]. As mentioned in [RFC4566], the
to be unique, but selecting a random number for <sess-id> is entire o= line needs to be unique, but selecting a random number
sufficient to accomplish this. for <sess-id> is sufficient to accomplish this.
o The third SDP line MUST be a "s=" line, as specified in [RFC4566], o The third SDP line MUST be a "s=" line, as specified in [RFC4566],
Section 5.3; to match the "o=" line, a single dash SHOULD be used Section 5.3; to match the "o=" line, a single dash SHOULD be used
as the session name, e.g. "s=-". Note that this differs from the as the session name, e.g. "s=-". Note that this differs from the
advice in [RFC4566] which proposes a single space, but as both advice in [RFC4566] which proposes a single space, but as both
"o=" and "s=" are meaningless in JSEP, having the same meaningless "o=" and "s=" are meaningless in JSEP, having the same meaningless
value seems clearer. value seems clearer.
o Session Information ("i="), URI ("u="), Email Address ("e="), o Session Information ("i="), URI ("u="), Email Address ("e="),
Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=")
skipping to change at page 44, line 45 skipping to change at page 44, line 45
above, an m= section MUST be generated for it with the port set to above, an m= section MUST be generated for it with the port set to
zero and all "a=msid" lines removed. zero and all "a=msid" lines removed.
o For RtpTransceivers that are not stopped, the "a=msid" line(s) o For RtpTransceivers that are not stopped, the "a=msid" line(s)
MUST stay the same if they are present in the current description, MUST stay the same if they are present in the current description,
regardless of changes to the transceiver's direction or track. If regardless of changes to the transceiver's direction or track. If
no "a=msid" line is present in the current description, "a=msid" no "a=msid" line is present in the current description, "a=msid"
line(s) MUST be generated according to the same rules as for an line(s) MUST be generated according to the same rules as for an
initial offer. initial offer.
o Each "m=" and c=" line MUST be filled in with the port, protocol, o Each "m=" and c=" line MUST be filled in with the port, relevant
and address of the default candidate for the m= section, as RTP profile, and address of the default candidate for the m=
described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. If section, as described in [I-D.ietf-mmusic-ice-sip-sdp],
ICE checking has already completed for one or more candidate pairs Section 3.2.1.2, and clarified in Section 5.1.2. If no RTP
and a candidate pair is in active use, then that pair MUST be candidates have yet been gathered, dummy values MUST still be
used, even if ICE has not yet completed. Note that this differs used, as described above.
from the guidance in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.3.4,
which only refers to offers created when ICE has completed. In
each case, if no RTP candidates have yet been gathered, dummy
values MUST be used, as described above.
o Each "a=mid" line MUST stay the same. o Each "a=mid" line MUST stay the same.
o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option ( Section 5.2.3.1 was specified. If the m= "IceRestart" option ( Section 5.2.3.1 was specified. If the m=
section is bundled into another m= section, it still MUST NOT section is bundled into another m= section, it still MUST NOT
contain any ICE credentials. contain any ICE credentials.
skipping to change at page 55, line 29 skipping to change at page 55, line 29
answer. answer.
If any session description was previously supplied to If any session description was previously supplied to
setLocalDescription, an answer is generated by following the steps in setLocalDescription, an answer is generated by following the steps in
the "have-remote-offer" state above, along with these exceptions: the "have-remote-offer" state above, along with these exceptions:
o The "s=" and "t=" lines MUST stay the same. o The "s=" and "t=" lines MUST stay the same.
o Each "m=" and c=" line MUST be filled in with the port and address o Each "m=" and c=" line MUST be filled in with the port and address
of the default candidate for the m= section, as described in of the default candidate for the m= section, as described in
[I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. Note, however, [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. Note that in
that the m= line protocol need not match the default candidate, certain cases, the m= line protocol may not match that of the
because this protocol value must instead match what was supplied default candidate, because the m= line protocol value MUST match
in the offer, as described above. what was supplied in the offer, as described above.
o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the m= section is restarting, in which case new ICE credentials the m= section is restarting, in which case new ICE credentials
must be created as specified in [I-D.ietf-mmusic-ice-sip-sdp], must be created as specified in [I-D.ietf-mmusic-ice-sip-sdp],
Section 3.4.1.1.1. If the m= section is bundled into another m= Section 3.4.1.1.1. If the m= section is bundled into another m=
section, it still MUST NOT contain any ICE credentials. section, it still MUST NOT contain any ICE credentials.
o Each "a=tls-id" line MUST stay the same unless the offerer's o Each "a=tls-id" line MUST stay the same unless the offerer's
"a=tls-id" line changed, in which case a new "a=tls-id" value MUST "a=tls-id" line changed, in which case a new "a=tls-id" value MUST
be created, as described in [I-D.ietf-mmusic-dtls-sdp], be created, as described in [I-D.ietf-mmusic-dtls-sdp],
skipping to change at page 63, line 42 skipping to change at page 63, line 42
o If present, a single "a=rtcp-rsize" attribute MUST be parsed as o If present, a single "a=rtcp-rsize" attribute MUST be parsed as
specified in [RFC5506], Section 5, and its presence or absence specified in [RFC5506], Section 5, and its presence or absence
flagged and stored. flagged and stored.
o If present, a single "a=rtcp" attribute MUST be parsed as o If present, a single "a=rtcp" attribute MUST be parsed as
specified in [RFC3605], Section 2.1, but its value is ignored, as specified in [RFC3605], Section 2.1, but its value is ignored, as
this information is superfluous when using ICE. this information is superfluous when using ICE.
o If present, "a=msid" attributes MUST be parsed as specified in o If present, "a=msid" attributes MUST be parsed as specified in
[I-D.ietf-mmusic-msid], Section 3.2, and their values stored, [I-D.ietf-mmusic-msid], Section 3.2, and their values stored,
ignoring any "appdata" field. ignoring any "appdata" field. If no "a=msid" attributes are
present, a random msid-id value is generated for a "default"
MediaStream for the session, if not already present, and this
value is stored.
o Any "a=imageattr" attributes MUST be parsed as specified in o Any "a=imageattr" attributes MUST be parsed as specified in
[RFC6236], Section 3, and their values stored. [RFC6236], Section 3, and their values stored.
o Any "a=rid" lines MUST be parsed as specified in o Any "a=rid" lines MUST be parsed as specified in
[I-D.ietf-mmusic-rid], Section 10, and their values stored. [I-D.ietf-mmusic-rid], Section 10, and their values stored.
o If present, a single "a=simulcast" line MUST be parsed as o If present, a single "a=simulcast" line MUST be parsed as
specified in [I-D.ietf-mmusic-sdp-simulcast], and its values specified in [I-D.ietf-mmusic-sdp-simulcast], and its values
stored. stored.
skipping to change at page 96, line 50 skipping to change at page 96, line 50
Holmberg, C. and R. Shpount, "Session Description Protocol Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-32 (work in progress), October draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017. 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen, Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in
progress), June 2018. progress), November 2018.
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "WebRTC MediaStream Identification in the Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", draft-ietf-mmusic-msid-16 Session Description Protocol", draft-ietf-mmusic-msid-17
(work in progress), February 2017. (work in progress), December 2018.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-rid] [I-D.ietf-mmusic-rid]
Roach, A., "RTP Payload Format Restrictions", draft-ietf- Roach, A., "RTP Payload Format Restrictions", draft-ietf-
mmusic-rid-15 (work in progress), May 2018. mmusic-rid-15 (work in progress), May 2018.
skipping to change at page 97, line 31 skipping to change at page 97, line 31
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
Procedures For Stream Control Transmission Protocol (SCTP) Procedures For Stream Control Transmission Protocol (SCTP)
over Datagram Transport Layer Security (DTLS) Transport.", over Datagram Transport Layer Security (DTLS) Transport.",
draft-ietf-mmusic-sctp-sdp-26 (work in progress), April draft-ietf-mmusic-sctp-sdp-26 (work in progress), April
2017. 2017.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-53 (work in progress), September 2018. negotiation-54 (work in progress), December 2018.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018. (work in progress), February 2018.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-13 (work in progress), June 2018. mmusic-sdp-simulcast-13 (work in progress), June 2018.
skipping to change at page 98, line 7 skipping to change at page 98, line 7
progress), March 2018. progress), March 2018.
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-26 (work in progress), March draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
2016. 2016.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-10 (work in progress), January 2018. ietf-rtcweb-security-11 (work in progress), February 2019.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-15 (work in progress), July 2018. rtcweb-security-arch-18 (work in progress), February 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
skipping to change at page 101, line 7 skipping to change at page 101, line 7
[I-D.ietf-mmusic-trickle-ice-sip] [I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Incremental Session Initiation Protocol (SIP) Usage for Incremental
Provisioning of Candidates for the Interactive Provisioning of Candidates for the Interactive
Connectivity Establishment (Trickle ICE)", draft-ietf- Connectivity Establishment (Trickle ICE)", draft-ietf-
mmusic-trickle-ice-sip-18 (work in progress), June 2018. mmusic-trickle-ice-sip-18 (work in progress), June 2018.
[I-D.ietf-rtcweb-ip-handling] [I-D.ietf-rtcweb-ip-handling]
Uberti, J., "WebRTC IP Address Handling Requirements", Uberti, J., "WebRTC IP Address Handling Requirements",
draft-ietf-rtcweb-ip-handling-10 (work in progress), draft-ietf-rtcweb-ip-handling-11 (work in progress),
October 2018. November 2018.
[I-D.ietf-rtcweb-sdp] [I-D.ietf-rtcweb-sdp]
Nandakumar, S. and C. Jennings, "Annotated Example SDP for Nandakumar, S. and C. Jennings, "Annotated Example SDP for
WebRTC", draft-ietf-rtcweb-sdp-11 (work in progress), WebRTC", draft-ietf-rtcweb-sdp-11 (work in progress),
October 2018. October 2018.
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,
September 2002, <https://www.rfc-editor.org/info/rfc3389>. September 2002, <https://www.rfc-editor.org/info/rfc3389>.
skipping to change at page 105, line 9 skipping to change at page 105, line 9
| | 6.1 | | | 6.1 |
| tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 | | tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 |
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
Table 1: SDP ABNF References Table 1: SDP ABNF References
Appendix B. Change log Appendix B. Change log
Note to RFC Editor: Please remove this section before publication. Note to RFC Editor: Please remove this section before publication.
Changes in draft-26:
o Update guidance on generation of the m= proto value to be
consistent with ice-sip-sdp.
Changes in draft-25: Changes in draft-25:
o Remove MSID track ID from offers and answers. o Remove MSID track ID from offers and answers.
o Add note about rejecting all m= sections in a BUNDLE group. o Add note about rejecting all m= sections in a BUNDLE group.
o Update ICE references to RFC 8445 and mention ice2. o Update ICE references to RFC 8445 and mention ice2.
Changes in draft-24: Changes in draft-24:
 End of changes. 19 change blocks. 
50 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/