draft-ietf-rtcweb-jsep-22.txt   draft-ietf-rtcweb-jsep-23.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: February 26, 2018 Cisco Expires: March 5, 2018 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
August 25, 2017 September 1, 2017
JavaScript Session Establishment Protocol JavaScript Session Establishment Protocol
draft-ietf-rtcweb-jsep-22 draft-ietf-rtcweb-jsep-23
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 26, 2018. This Internet-Draft will expire on March 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12
3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12
3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12
3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13
3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13 3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13
3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14
3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15
3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16
3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16
3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 17 3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 17
3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 18 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8. Interactions With Forking . . . . . . . . . . . . . . . . 20 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 20
3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20
3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22
4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 24 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24
4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 24 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 24
4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 25 4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 25
4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 25 4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 25
4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 26 4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 26
4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 27 4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 27
4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 27 4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 28
4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28 4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28
4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29 4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29
4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 30 4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 29
4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30 4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30
4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 31 4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30
4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 31 4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30
4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 31 4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 30
4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31 4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31
4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 32 4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31
4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 33 4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32
4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33
4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 34 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33
4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 34 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 33
4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34
4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 35 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 34
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 35 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 34
5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35
5.1.2. Profile Names and Interoperability . . . . . . . . . 36 5.1.2. Profile Names and Interoperability . . . . . . . . . 35
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 37 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 36
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 37 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 36
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 44 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47
5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 48 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47
5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 48 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 49 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 49 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56
5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 57 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56
5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 56
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. Parsing a Session Description . . . . . . . . . . . . . . 59 5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58
5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 59 5.8. Parsing a Session Description . . . . . . . . . . . . . . 59
5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 61 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 59
5.7.3. Semantics Verification . . . . . . . . . . . . . . . 63 5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61
5.8. Applying a Local Description . . . . . . . . . . . . . . 65 5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64
5.9. Applying a Remote Description . . . . . . . . . . . . . . 66 5.9. Applying a Local Description . . . . . . . . . . . . . . 65
5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 70 5.10. Applying a Remote Description . . . . . . . . . . . . . . 66
5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 70
6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 73 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 73
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 73 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74
7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 77 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78
7.3. Early Transport Warmup Example . . . . . . . . . . . . . 87 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88
8. Security Considerations . . . . . . . . . . . . . . . . . . . 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 95
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.1. Normative References . . . . . . . . . . . . . . . . . . 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 96
11.2. Informative References . . . . . . . . . . . . . . . . . 100 11.2. Informative References . . . . . . . . . . . . . . . . . 101
Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 102 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 103
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 103 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
1. Introduction 1. Introduction
This document describes how the W3C WEBRTC RTCPeerConnection This document describes how the W3C WEBRTC RTCPeerConnection
interface [W3C.webrtc] is used to control the setup, management and interface [W3C.webrtc] is used to control the setup, management and
teardown of a multimedia session. teardown of a multimedia session.
1.1. General Design of JSEP 1.1. General Design of JSEP
WebRTC call setup has been designed to focus on controlling the media WebRTC call setup has been designed to focus on controlling the media
skipping to change at page 14, line 30 skipping to change at page 14, line 30
The IceCandidate object also contains fields to indicate which m= The IceCandidate object also contains fields to indicate which m=
section it is associated with, which can be identified in one of two section it is associated with, which can be identified in one of two
ways, either by a m= section index, or a MID. The m= section index ways, either by a m= section index, or a MID. The m= section index
is a zero-based index, with index N referring to the N+1th m= section is a zero-based index, with index N referring to the N+1th m= section
in the session description referenced by this IceCandidate. The MID in the session description referenced by this IceCandidate. The MID
is a "media stream identification" value, as defined in [RFC5888], is a "media stream identification" value, as defined in [RFC5888],
Section 4, which provides a more robust way to identify the m= Section 4, which provides a more robust way to identify the m=
section in the session description, using the MID of the associated section in the session description, using the MID of the associated
RtpTransceiver object (which may have been locally generated by the RtpTransceiver object (which may have been locally generated by the
answerer when interacting with a non-JSEP endpoint that does not answerer when interacting with a non-JSEP endpoint that does not
support the MID attribute, as discussed in Section 5.9 below). If support the MID attribute, as discussed in Section 5.10 below). If
the MID field is present in a received IceCandidate, it MUST be used the MID field is present in a received IceCandidate, it MUST be used
for identification; otherwise, the m= section index is used instead. for identification; otherwise, the m= section index is used instead.
When creating an IceCandidate object, JSEP implementations MUST When creating an IceCandidate object, JSEP implementations MUST
populate each of the candidate, ufrag, m= section index, and MID populate each of the candidate, ufrag, m= section index, and MID
fields. Implementations MUST also be prepared to receive objects fields. Implementations MUST also be prepared to receive objects
with some fields missing, as mentioned above. with some fields missing, as mentioned above.
3.5.3. ICE Candidate Policy 3.5.3. ICE Candidate Policy
skipping to change at page 17, line 25 skipping to change at page 17, line 25
As an example, consider a system with a multiformat video decoder, As an example, consider a system with a multiformat video decoder,
which is capable of decoding any resolution from 48x48 to 720p, In which is capable of decoding any resolution from 48x48 to 720p, In
this case, the implementation would generate this attribute: this case, the implementation would generate this attribute:
a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0] a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]
This declaration indicates that the receiver is capable of decoding This declaration indicates that the receiver is capable of decoding
any image resolution from 48x48 up to 1280x720 pixels. any image resolution from 48x48 up to 1280x720 pixels.
3.6.2. Interpreting an imageattr Attribute 3.6.2. Interpreting imageattr Attributes
[RFC6236] defines "a=imageattr" to be an advisory field. This means [RFC6236] defines "a=imageattr" to be an advisory field. This means
that it does not absolutely constrain the video formats that the that it does not absolutely constrain the video formats that the
sender can use, but gives an indication of the preferred values. sender can use, but gives an indication of the preferred values.
This specification prescribes more specific behavior. When a This specification prescribes more specific behavior. When a
MediaStreamTrack, which is producing video of a certain resolution MediaStreamTrack, which is producing video of a certain resolution
(the "track resolution"), is attached to a RtpSender, which is (the "track resolution"), is attached to a RtpSender, which is
encoding the track video at the same or lower resolution(s) (the encoding the track video at the same or lower resolution(s) (the
"encoder resolutions"), and a remote description is applied that "encoder resolutions"), and a remote description is applied that
skipping to change at page 17, line 51 skipping to change at page 17, line 51
cases in which the track changes its resolution, or is replaced with cases in which the track changes its resolution, or is replaced with
a different track. a different track.
Depending on how the RtpSender is configured, it may be producing a Depending on how the RtpSender is configured, it may be producing a
single encoding at a certain resolution, or, if simulcast Section 3.7 single encoding at a certain resolution, or, if simulcast Section 3.7
has been negotiated, multiple encodings, each at their own specific has been negotiated, multiple encodings, each at their own specific
resolution. In addition, depending on the configuration, each resolution. In addition, depending on the configuration, each
encoding may have the flexibility to reduce resolution when needed, encoding may have the flexibility to reduce resolution when needed,
or may be locked to a specific output resolution. or may be locked to a specific output resolution.
For each encoding being produced by the RtpSender, the following For each encoding being produced by the RtpSender, the set of
rules are applied to determine what should be transmitted: "a=imageattr recv" attributes in the corresponding m= section of the
remote description is processed to determine what should be
transmitted. Only attributes that reference the media format
selected for the encoding are considered; each such attribute is
evaluated individually, starting with the attribute with the highest
"q=" value. If multiple attributes have the same "q=" value, they
are evaluated in the order they appear in their containing m=
section. Note that while JSEP endpoints will include at most one
"a=imageattr recv" attribute per media format, JSEP endpoints may
receive session descriptions from non-JSEP endpoints with m= sections
that contain multiple such attributes.
o First, the most suitable "a=imageattr recv" attribute is selected. For each "a=imageattr recv" attribute, the following rules are
This is performed by taking the attribute with the highest "q=" applied. If this processing is successful, the encoding is
value from the set of attributes that reference the media format transmitted accordingly, and no further attributes are considered for
that has been selected for the specified encoding. If multiple that encoding. Otherwise, the next attribute is evaluated, in the
attributes have the same "q=" value, the one that appears first in aforementioned order. If none of the supplied attributes can be
the m= section is used. Note that while JSEP endpoints will processed successfully, the encoding MUST NOT be transmitted, and an
include at most one "a=imageattr recv" attribute per media format, error SHOULD be raised to the application.
JSEP endpoints may receive session descriptions from non-JSEP
endpoints with m= sections that contain multiple such attributes.
o If there is an applicable "a=imageattr recv" attribute for the o The limits from the attribute are compared to the encoder
encoding, the limits from the attribute are then compared to the resolution. Only the specific limits mentioned below are
encoder resolution. Only the specific limits mentioned below are
considered; any other values, such as picture aspect ratio, MUST considered; any other values, such as picture aspect ratio, MUST
be ignored. When considering a MediaStreamTrack that is producing be ignored. When considering a MediaStreamTrack that is producing
rotated video, the unrotated resolution MUST be used for the rotated video, the unrotated resolution MUST be used for the
checks. This is required regardless of whether the receiver checks. This is required regardless of whether the receiver
supports performing receive-side rotation (e.g., through CVO supports performing receive-side rotation (e.g., through CVO
[TS26.114]), as it significantly simplifies the matching logic. [TS26.114]), as it significantly simplifies the matching logic.
o If the attribute includes a "sar=" (sample aspect ratio) value set o If the attribute includes a "sar=" (sample aspect ratio) value set
to something other than "1.0", indicating the receiver wants to to something other than "1.0", indicating the receiver wants to
receive non-square pixels, this cannot be satisfied and the sender receive non-square pixels, this cannot be satisfied and the
MUST NOT transmit the encoding. attribute MUST NOT be used.
o If the encoder resolution exceeds the maximum size permitted by o If the encoder resolution exceeds the maximum size permitted by
the attribute, and the encoder is allowed to adjust its the attribute, and the encoder is allowed to adjust its
resolution, the encoder SHOULD apply downscaling in order to resolution, the encoder SHOULD apply downscaling in order to
satisfy the limits, although the downscaling MUST NOT change the satisfy the limits, although the downscaling MUST NOT change the
picture aspect ratio of the encoding. For example, if the encoder picture aspect ratio of the encoding. For example, if the encoder
resolution is 1280x720, and the attribute specified a maximum of resolution is 1280x720, and the attribute specified a maximum of
640x480, the expected output resolution would be 640x360. If 640x480, the expected output resolution would be 640x360. If
downscaling cannot be applied, the encoding MUST NOT be downscaling cannot be applied, the attribute MUST NOT be used.
transmitted, and an error SHOULD be raised to the application.
o If the encoder resolution is less than the minimum size permitted o If the encoder resolution is less than the minimum size permitted
by the attribute, the encoding MUST NOT be transmitted, and an by the attribute, the attribute MUST NOT be used; the encoder MUST
error SHOULD be raised to the application; the encoder MUST NOT NOT apply upscaling. JSEP implementations SHOULD avoid this
apply upscaling. JSEP implementations SHOULD avoid this situation situation by allowing receipt of arbitrarily small resolutions,
by allowing receipt of arbitrarily small resolutions, perhaps via perhaps via fallback to a software decoder.
fallback to a software decoder.
o If the encoder resolution is within the maximum and minimum sizes,
no action is needed.
3.7. Simulcast 3.7. Simulcast
JSEP supports simulcast transmission of a MediaStreamTrack, where JSEP supports simulcast transmission of a MediaStreamTrack, where
multiple encodings of the source media can be transmitted within the multiple encodings of the source media can be transmitted within the
context of a single m= section. The current JSEP API is designed to context of a single m= section. The current JSEP API is designed to
allow applications to send simulcasted media but only to receive a allow applications to send simulcasted media but only to receive a
single encoding. This allows for multi-user scenarios where each single encoding. This allows for multi-user scenarios where each
sending client sends multiple encodings to a server, which then, for sending client sends multiple encodings to a server, which then, for
each receiving client, chooses the appropriate encoding to forward. each receiving client, chooses the appropriate encoding to forward.
skipping to change at page 28, line 48 skipping to change at page 29, line 6
In certain situations it may be desirable to "undo" a change made to In certain situations it may be desirable to "undo" a change made to
setLocalDescription or setRemoteDescription. Consider a case where a setLocalDescription or setRemoteDescription. Consider a case where a
call is ongoing, and one side wants to change some of the session call is ongoing, and one side wants to change some of the session
parameters; that side generates an updated offer and then calls parameters; that side generates an updated offer and then calls
setLocalDescription. However, the remote side, either before or setLocalDescription. However, the remote side, either before or
after setRemoteDescription, decides it does not want to accept the after setRemoteDescription, decides it does not want to accept the
new parameters, and sends a reject message back to the offerer. Now, new parameters, and sends a reject message back to the offerer. Now,
the offerer, and possibly the answerer as well, need to return to a the offerer, and possibly the answerer as well, need to return to a
stable state and the previous local/remote description. To support stable state and the previous local/remote description. To support
this, we introduce the concept of "rollback". this, we introduce the concept of "rollback", which discards any
proposed changes to the session, returning the state machine to the
A rollback discards any proposed changes to the session, returning stable state. A rollback is performed by supplying a session
the state machine to the stable state, and setting the pending local description of type "rollback" with empty contents to either
and/or remote description (see Section 4.1.12 and Section 4.1.14) to setLocalDescription or setRemoteDescription.
null. Any resources or candidates that were allocated by the
abandoned local description are discarded; any media that is received
will be processed according to the previous local and remote
descriptions. Rollback can only be used to cancel proposed changes;
there is no support for rolling back from a stable state to a
previous stable state. Note that this implies that once the answerer
has performed setLocalDescription with his answer, this cannot be
rolled back.
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see Section 5.9 and Section 5.8). 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 property MUST be set to null, and the mapping
between the transceiver and its m= section index MUST be discarded.
RtpTransceivers that were created by applying a remote offer that was
subsequently rolled back MUST be stopped and removed from the
PeerConnection. However, a RtpTransceiver MUST NOT be removed if a
track was attached to the RtpTransceiver via the addTrack method.
This is so that an application may call addTrack, then call
setRemoteDescription with an offer, then roll back that offer, then
call createOffer and have a m= section for the added track appear in
the generated offer.
A rollback is performed by supplying a session description of type
"rollback" with empty contents to either setLocalDescription or
setRemoteDescription. The effect MUST be the same regardless of
whether setLocalDescription or setRemoteDescription is called.
A rollback may be performed if the PeerConnection is in any state
except for "stable". This means that both offers and provisional
answers can be rolled back. If a rollback is attempted in the
"stable" state, processing MUST stop and an error MUST be returned.
4.1.9. setLocalDescription 4.1.9. setLocalDescription
The setLocalDescription method instructs the PeerConnection to apply The setLocalDescription method instructs the PeerConnection to apply
the supplied session description as its local configuration. The the supplied session description as its local configuration. The
type field indicates whether the description should be processed as type field indicates whether the description should be processed as
an offer, provisional answer, final answer, or rollback; offers and an offer, provisional answer, final answer, or rollback; offers and
answers are checked differently, using the various rules that exist answers are checked differently, using the various rules that exist
for each SDP line. for each SDP line.
skipping to change at page 38, line 34 skipping to change at page 38, line 4
o An "a=ice-options" line with the "trickle" option MUST be added, o An "a=ice-options" line with the "trickle" option MUST be added,
as specified in [I-D.ietf-ice-trickle], Section 4. as specified in [I-D.ietf-ice-trickle], Section 4.
o If WebRTC identity is being used, an "a=identity" line as o If WebRTC identity is being used, an "a=identity" line as
described in [I-D.ietf-rtcweb-security-arch], Section 5. described in [I-D.ietf-rtcweb-security-arch], Section 5.
The next step is to generate m= sections, as specified in [RFC4566], The next step is to generate m= sections, as specified in [RFC4566],
Section 5.14. An m= section is generated for each RtpTransceiver Section 5.14. An m= section is generated for each RtpTransceiver
that has been added to the PeerConnection, excluding any stopped that has been added to the PeerConnection, excluding any stopped
RtpTransceivers. This is done in the order the RtpTransceivers were RtpTransceivers; this is done in the order the RtpTransceivers were
added to the PeerConnection. added to the PeerConnection. If there are no such RtpTransceivers,
no m= sections are generated; more can be added later, as discussed
in [RFC3264], Section 5.
For each m= section generated for an RtpTransceiver, establish a For each m= section generated for an RtpTransceiver, establish a
mapping between the transceiver and the index of the generated m= mapping between the transceiver and the index of the generated m=
section. section.
Each m= section, provided it is not marked as bundle-only, MUST Each m= section, provided it is not marked as bundle-only, MUST
generate a unique set of ICE credentials and gather its own unique generate a unique set of ICE credentials and gather its own unique
set of ICE candidates. Bundle-only m= sections MUST NOT contain any set of ICE candidates. Bundle-only m= sections MUST NOT contain any
ICE credentials and MUST NOT gather any candidates. ICE credentials and MUST NOT gather any candidates.
skipping to change at page 51, line 21 skipping to change at page 50, line 33
a=recvonly a=recvonly
The Section 7.2 example later in this document shows a more involved The Section 7.2 example later in this document shows a more involved
case of "LS" group generation. case of "LS" group generation.
The next step is to generate m= sections for each m= section that is The next step is to generate m= sections for each m= section that is
present in the remote offer, as specified in [RFC3264], Section 6. present in the remote offer, as specified in [RFC3264], Section 6.
For the purposes of this discussion, any session-level attributes in For the purposes of this discussion, any session-level attributes in
the offer that are also valid as media-level attributes are the offer that are also valid as media-level attributes are
considered to be present in each m= section. Each offered m= section considered to be present in each m= section. Each offered m= section
will have an associated RtpTransceiver, as described in Section 5.9. will have an associated RtpTransceiver, as described in Section 5.10.
If there are more RtpTransceivers than there are m= sections, the If there are more RtpTransceivers than there are m= sections, the
unmatched RtpTransceivers will need to be associated in a subsequent unmatched RtpTransceivers will need to be associated in a subsequent
offer. offer.
For each offered m= section, if any of the following conditions are For each offered m= section, if any of the following conditions are
true, the corresponding m= section in the answer MUST be marked as true, the corresponding m= section in the answer MUST be marked as
rejected by setting the port in the m= line to zero, as indicated in rejected by setting the port in the m= line to zero, as indicated in
[RFC3264], Section 6, and further processing for this m= section can [RFC3264], Section 6, and further processing for this m= section can
be skipped: be skipped:
skipping to change at page 58, line 6 skipping to change at page 57, line 27
assume that any implementation of this specification will be able to assume that any implementation of this specification will be able to
process, as a remote offer or answer, unmodified SDP coming from any process, as a remote offer or answer, unmodified SDP coming from any
other implementation of this specification. other implementation of this specification.
5.5. Processing a Local Description 5.5. Processing a Local Description
When a SessionDescription is supplied to setLocalDescription, the When a SessionDescription is supplied to setLocalDescription, the
following steps MUST be performed: following steps MUST be performed:
o If the description is of type "rollback", follow the processing o If the description is of type "rollback", follow the processing
defined in Section 4.1.8.2 and skip the processing described in defined in Section 5.7 and skip the processing described in the
the rest of this section. rest of this section.
o Otherwise, the type of the SessionDescription is checked against o Otherwise, the type of the SessionDescription is checked against
the current state of the PeerConnection: the current state of the PeerConnection:
* If the type is "offer", the PeerConnection state MUST be either * If the type is "offer", the PeerConnection state MUST be either
"stable" or "have-local-offer". "stable" or "have-local-offer".
* If the type is "pranswer" or "answer", the PeerConnection state * If the type is "pranswer" or "answer", the PeerConnection state
MUST be either "have-remote-offer" or "have-local-pranswer". MUST be either "have-remote-offer" or "have-local-pranswer".
o If the type is not correct for the current state, processing MUST o If the type is not correct for the current state, processing MUST
stop and an error MUST be returned. stop and an error MUST be returned.
o The SessionDescription is then checked to ensure that its contents o The SessionDescription is then checked to ensure that its contents
are identical to those generated in the last call to createOffer/ are identical to those generated in the last call to createOffer/
createAnswer, and thus have not been altered, as discussed in createAnswer, and thus have not been altered, as discussed in
Section 5.4; otherwise, processing MUST stop and an error MUST be Section 5.4; otherwise, processing MUST stop and an error MUST be
returned. returned.
o Next, the SessionDescription is parsed into a data structure, as o Next, the SessionDescription is parsed into a data structure, as
described in Section 5.7 below. described in Section 5.8 below.
o Finally, the parsed SessionDescription is applied as described in o Finally, the parsed SessionDescription is applied as described in
Section 5.8 below. Section 5.9 below.
5.6. Processing a Remote Description 5.6. Processing a Remote Description
When a SessionDescription is supplied to setRemoteDescription, the When a SessionDescription is supplied to setRemoteDescription, the
following steps MUST be performed: following steps MUST be performed:
o If the description is of type "rollback", follow the processing o If the description is of type "rollback", follow the processing
defined in Section 4.1.8.2 and skip the processing described in defined in Section 5.7 and skip the processing described in the
the rest of this section. rest of this section.
o Otherwise, the type of the SessionDescription is checked against o Otherwise, the type of the SessionDescription is checked against
the current state of the PeerConnection: the current state of the PeerConnection:
* If the type is "offer", the PeerConnection state MUST be either * If the type is "offer", the PeerConnection state MUST be either
"stable" or "have-remote-offer". "stable" or "have-remote-offer".
* If the type is "pranswer" or "answer", the PeerConnection state * If the type is "pranswer" or "answer", the PeerConnection state
MUST be either "have-local-offer" or "have-remote-pranswer". MUST be either "have-local-offer" or "have-remote-pranswer".
o If the type is not correct for the current state, processing MUST o If the type is not correct for the current state, processing MUST
stop and an error MUST be returned. stop and an error MUST be returned.
o Next, the SessionDescription is parsed into a data structure, as o Next, the SessionDescription is parsed into a data structure, as
described in Section 5.7 below. If parsing fails for any reason, described in Section 5.8 below. If parsing fails for any reason,
processing MUST stop and an error MUST be returned. processing MUST stop and an error MUST be returned.
o Finally, the parsed SessionDescription is applied as described in o Finally, the parsed SessionDescription is applied as described in
Section 5.9 below. Section 5.10 below.
5.7. Parsing a Session Description 5.7. Processing a Rollback
A rollback may be performed if the PeerConnection is in any state
except for "stable". This means that both offers and provisional
answers can be rolled back. Rollback can only be used to cancel
proposed changes; there is no support for rolling back from a stable
state to a previous stable state. If a rollback is attempted in the
"stable" state, processing MUST stop and an error MUST be returned.
Note that this implies that once the answerer has performed
setLocalDescription with his answer, this cannot be rolled back.
The effect of rollback MUST be the same regardless of whether
setLocalDescription or setRemoteDescription is called.
In order to process rollback, a JSEP implementation abandons the
current offer/answer transaction, sets the signaling state to
"stable", and sets the pending local and/or remote description (see
Section 4.1.12 and Section 4.1.14) to null. Any resources or
candidates that were allocated by the abandoned local description are
discarded; any media that is received is processed according to the
previous local and remote descriptions.
A rollback disassociates any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see Section 5.10 and Section 5.9). 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 property MUST be set to null, and the mapping
between the transceiver and its m= section index MUST be discarded.
RtpTransceivers that were created by applying a remote offer that was
subsequently rolled back MUST be stopped and removed from the
PeerConnection. However, a RtpTransceiver MUST NOT be removed if a
track was attached to the RtpTransceiver via the addTrack method.
This is so that an application may call addTrack, then call
setRemoteDescription with an offer, then roll back that offer, then
call createOffer and have a m= section for the added track appear in
the generated offer.
5.8. Parsing a Session Description
The SDP contained in the session description object consists of a The SDP contained in the session description object consists of a
sequence of text lines, each containing a key-value expression, as sequence of text lines, each containing a key-value expression, as
described in [RFC4566], Section 5. The SDP is read, line-by-line, described in [RFC4566], Section 5. The SDP is read, line-by-line,
and converted to a data structure that contains the deserialized and converted to a data structure that contains the deserialized
information. However, SDP allows many types of lines, not all of information. However, SDP allows many types of lines, not all of
which are relevant to JSEP applications. For each line, the which are relevant to JSEP applications. For each line, the
implementation will first ensure it is syntactically correct implementation will first ensure it is syntactically correct
according to its defining ABNF, check that it conforms to [RFC4566] according to its defining ABNF, check that it conforms to [RFC4566]
and [RFC3264] semantics, and then either parse and store or discard and [RFC3264] semantics, and then either parse and store or discard
the provided value, as described below. the provided value, as described below.
If any line is not well-formed, or cannot be parsed as described, the If any line is not well-formed, or cannot be parsed as described, the
parser MUST stop with an error and reject the session description, parser MUST stop with an error and reject the session description,
even if the value is to be discarded. This ensures that even if the value is to be discarded. This ensures that
implementations do not accidentally misinterpret ambiguous SDP. implementations do not accidentally misinterpret ambiguous SDP.
5.7.1. Session-Level Parsing 5.8.1. Session-Level Parsing
First, the session-level lines are checked and parsed. These lines First, the session-level lines are checked and parsed. These lines
MUST occur in a specific order, and with a specific syntax, as MUST occur in a specific order, and with a specific syntax, as
defined in [RFC4566], Section 5. Note that while the specific line defined in [RFC4566], Section 5. Note that while the specific line
types (e.g. "v=", "c=") MUST occur in the defined order, lines of the types (e.g. "v=", "c=") MUST occur in the defined order, lines of the
same type (typically "a=") can occur in any order. same type (typically "a=") can occur in any order.
The following non-attribute lines are not meaningful in the JSEP The following non-attribute lines are not meaningful in the JSEP
context and MAY be discarded once they have been checked. context and MAY be discarded once they have been checked.
skipping to change at page 61, line 13 skipping to change at page 61, line 24
Section 5, and their values are stored. Section 5, and their values are stored.
Other attributes that are not relevant to JSEP may also be present, Other attributes that are not relevant to JSEP may also be present,
and implementations SHOULD process any that they recognize. As and implementations SHOULD process any that they recognize. As
required by [RFC4566], Section 5.13, unknown attribute lines MUST be required by [RFC4566], Section 5.13, unknown attribute lines MUST be
ignored. ignored.
Once all the session-level lines have been parsed, processing Once all the session-level lines have been parsed, processing
continues with the lines in m= sections. continues with the lines in m= sections.
5.7.2. Media Section Parsing 5.8.2. Media Section Parsing
Like the session-level lines, the media section lines MUST occur in Like the session-level lines, the media section lines MUST occur in
the specific order and with the specific syntax defined in [RFC4566], the specific order and with the specific syntax defined in [RFC4566],
Section 5. Section 5.
The "m=" line itself MUST be parsed as described in [RFC4566], The "m=" line itself MUST be parsed as described in [RFC4566],
Section 5.14, and the media, port, proto, and fmt values stored. Section 5.14, and the media, port, proto, and fmt values stored.
Following the "m=" line, specific processing MUST be applied for the Following the "m=" line, specific processing MUST be applied for the
following non-attribute lines: following non-attribute lines:
skipping to change at page 63, line 42 skipping to change at page 64, line 5
o If present, a single "a=max-message-size" attribute MUST be parsed o If present, a single "a=max-message-size" attribute MUST be parsed
as specified in [I-D.ietf-mmusic-sctp-sdp], Section 6, and the as specified in [I-D.ietf-mmusic-sctp-sdp], Section 6, and the
value stored. Otherwise, use the specified default. value stored. Otherwise, use the specified default.
Other attributes that are not relevant to JSEP may also be present, Other attributes that are not relevant to JSEP may also be present,
and implementations SHOULD process any that they recognize. As and implementations SHOULD process any that they recognize. As
required by [RFC4566], Section 5.13, unknown attribute lines MUST be required by [RFC4566], Section 5.13, unknown attribute lines MUST be
ignored. ignored.
5.7.3. Semantics Verification 5.8.3. Semantics Verification
Assuming parsing completes successfully, the parsed description is Assuming parsing completes successfully, the parsed description is
then evaluated to ensure internal consistency as well as proper then evaluated to ensure internal consistency as well as proper
support for mandatory features. Specifically, the following checks support for mandatory features. Specifically, the following checks
are performed: are performed:
o For each m= section, valid values for each of the mandatory-to-use o For each m= section, valid values for each of the mandatory-to-use
features enumerated in Section 5.1.1 MUST be present. These features enumerated in Section 5.1.1 MUST be present. These
values MAY either be present at the media level, or inherited from values MAY either be present at the media level, or inherited from
the session level. the session level.
skipping to change at page 65, line 5 skipping to change at page 65, line 17
m= sections MUST exactly match the number of m= sections in the m= sections MUST exactly match the number of m= sections in the
associated offer. associated offer.
o For each m= section, the media type and protocol values MUST o For each m= section, the media type and protocol values MUST
exactly match the media type and protocol values in the exactly match the media type and protocol values in the
corresponding m= section in the associated offer. corresponding m= section in the associated offer.
If any of the preceding checks failed, processing MUST stop and an If any of the preceding checks failed, processing MUST stop and an
error MUST be returned. error MUST be returned.
5.8. Applying a Local Description 5.9. Applying a Local Description
The following steps are performed at the media engine level to apply The following steps are performed at the media engine level to apply
a local description. If an error is returned, the session MUST be a local description. If an error is returned, the session MUST be
restored to the state it was in before performing these steps. restored to the state it was in before performing these steps.
First, m= sections are processed. For each m= section, the following First, m= sections are processed. For each m= section, the following
steps MUST be performed; if any parameters are out of bounds, or steps MUST be performed; if any parameters are out of bounds, or
cannot be applied, processing MUST stop and an error MUST be cannot be applied, processing MUST stop and an error MUST be
returned. returned.
skipping to change at page 66, line 22 skipping to change at page 66, line 36
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2.
* For each specified "rtx" media format, establish a mapping * For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload between the RTX payload type and its associated primary payload
type, as described in [RFC4588], Sections 8.6 and 8.7. type, as described in [RFC4588], Sections 8.6 and 8.7.
* If the directional attribute is of type "sendrecv" or * If the directional attribute is of type "sendrecv" or
"recvonly", enable receipt and decoding of media. "recvonly", enable receipt and decoding of media.
Finally, if this description is of type "pranswer" or "answer", Finally, if this description is of type "pranswer" or "answer",
follow the processing defined in Section 5.10 below. follow the processing defined in Section 5.11 below.
5.9. Applying a Remote Description 5.10. Applying a Remote Description
The following steps are performed to apply a remote description. If The following steps are performed to apply a remote description. If
an error is returned, the session MUST be restored to the state it an error is returned, the session MUST be restored to the state it
was in before performing these steps. was in before performing these steps.
If the answer contains any "a=ice-options" attributes where "trickle" If the answer contains any "a=ice-options" attributes where "trickle"
is listed as an attribute, update the PeerConnection canTrickle is listed as an attribute, update the PeerConnection canTrickle
property to be true. Otherwise, set this property to false. property to be true. Otherwise, set this property to false.
The following steps MUST be performed for attributes at the session The following steps MUST be performed for attributes at the session
skipping to change at page 70, line 13 skipping to change at page 70, line 32
If there are any supported media formats that do not have a If there are any supported media formats that do not have a
corresponding telephone-event format, disable DTMF corresponding telephone-event format, disable DTMF
transmission for those formats. transmission for those formats.
+ For any specified "ptime" value, configure the available + For any specified "ptime" value, configure the available
media formats to use the specified packet size when sending. media formats to use the specified packet size when sending.
If the specified size is not supported for a media format, If the specified size is not supported for a media format,
use the next closest value instead. use the next closest value instead.
Finally, if this description is of type "pranswer" or "answer", Finally, if this description is of type "pranswer" or "answer",
follow the processing defined in Section 5.10 below. follow the processing defined in Section 5.11 below.
5.10. Applying an Answer 5.11. Applying an Answer
In addition to the steps mentioned above for processing a local or In addition to the steps mentioned above for processing a local or
remote description, the following steps are performed when processing remote description, the following steps are performed when processing
a description of type "pranswer" or "answer". a description of type "pranswer" or "answer".
For each m= section, the following steps MUST be performed: For each m= section, the following steps MUST be performed:
o If the m= section has been rejected (i.e. port is set to zero in o If the m= section has been rejected (i.e. port is set to zero in
the answer), stop any reception or transmission of media for this the answer), stop any reception or transmission of media for this
section, and, unless a non-rejected m= section is bundled with section, and, unless a non-rejected m= section is bundled with
skipping to change at page 96, line 13 skipping to change at page 97, line 13
rid-09 (work in progress), October 2016. rid-09 (work in progress), October 2016.
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-13 (work in progress), Protocol", draft-ietf-ice-trickle-13 (work in progress),
July 2017. July 2017.
[I-D.ietf-mmusic-dtls-sdp] [I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer Holmberg, C. and R. Shpount, "Session Description Protocol
Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-28 (work (SDP) Offer/Answer Considerations for Datagram Transport
in progress), August 2017. Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-29 (work in progress), August
2017.
[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-16
(work in progress), February 2017. (work in progress), February 2017.
[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.
skipping to change at page 96, line 45 skipping to change at page 97, line 47
"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-38 (work in progress), April 2017. negotiation-39 (work in progress), August 2017.
[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-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016. (work in progress), December 2016.
[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-10 (work in progress), July 2017. mmusic-sdp-simulcast-10 (work in progress), July 2017.
skipping to change at page 97, line 31 skipping to change at page 98, line 31
[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-08 (work in progress), February 2015. ietf-rtcweb-security-08 (work in progress), February 2015.
[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-12 (work in progress), June 2016. rtcweb-security-arch-12 (work in progress), June 2016.
[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-
<http://www.rfc-editor.org/info/rfc2119>. 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, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc- DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
skipping to change at page 102, line 21 skipping to change at page 103, line 21
[W3C.webrtc] [W3C.webrtc]
Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A.,
Aboba, B., and T. Brandstetter, "WebRTC 1.0: Real-time Aboba, B., and T. Brandstetter, "WebRTC 1.0: Real-time
Communication Between Browsers", World Wide Web Consortium Communication Between Browsers", World Wide Web Consortium
WD WD-webrtc-20170515, May 2017, WD WD-webrtc-20170515, May 2017,
<https://www.w3.org/TR/2017/WD-webrtc-20170515/>. <https://www.w3.org/TR/2017/WD-webrtc-20170515/>.
Appendix A. Appendix A Appendix A. Appendix A
For the syntax validation performed in Section 5.7, the following For the syntax validation performed in Section 5.8, the following
list of ABNF definitions is used: list of ABNF definitions is used:
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
| Attribute | Reference | | Attribute | Reference |
+------------------------+------------------------------------------+ +------------------------+------------------------------------------+
| ptime | [RFC4566] Section 9 | | ptime | [RFC4566] Section 9 |
| maxptime | [RFC4566] Section 9 | | maxptime | [RFC4566] Section 9 |
| rtpmap | [RFC4566] Section 9 | | rtpmap | [RFC4566] Section 9 |
| recvonly | [RFC4566] Section 9 | | recvonly | [RFC4566] Section 9 |
| sendrecv | [RFC4566] Section 9 | | sendrecv | [RFC4566] Section 9 |
skipping to change at page 103, line 48 skipping to change at page 104, line 48
| | 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-23:
o Clarify rollback handling, and treat it similarly to other
setLocal/setRemote usages.
o Adopt a first-fit policy for handling multiple remote a=imageattr
attributes.
o Clarify that a session description with zero m= sections is legal.
Changes in draft-22: Changes in draft-22:
o Clarify currentDirection versus direction. o Clarify currentDirection versus direction.
o Correct session-id text so that it aligns with RFC 3264. o Correct session-id text so that it aligns with RFC 3264.
o Clarify that generated ICE candidate objects must have all four o Clarify that generated ICE candidate objects must have all four
fields. fields.
o Make rollback work from any state besides stable and regardless of o Make rollback work from any state besides stable and regardless of
 End of changes. 48 change blocks. 
138 lines changed or deleted 165 lines changed or added

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