draft-ietf-rtcweb-jsep-16.txt   draft-ietf-rtcweb-jsep-17.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: March 24, 2017 Cisco Expires: April 24, 2017 Cisco
E. Rescorla, Ed. E. Rescorla, Ed.
Mozilla Mozilla
September 20, 2016 October 21, 2016
Javascript Session Establishment Protocol Javascript Session Establishment Protocol
draft-ietf-rtcweb-jsep-16 draft-ietf-rtcweb-jsep-17
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 March 24, 2017. This Internet-Draft will expire on April 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4
1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6
3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6
3.2. Session Descriptions and State Machine . . . . . . . . . 7 3.2. Session Descriptions and State Machine . . . . . . . . . 7
3.3. Session Description Format . . . . . . . . . . . . . . . 10 3.3. Session Description Format . . . . . . . . . . . . . . . 10
3.4. Session Description Control . . . . . . . . . . . . . . . 10 3.4. Session Description Control . . . . . . . . . . . . . . . 10
3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 10 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 10
3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 11 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 13 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 13
3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 14 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 14
3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 14 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 14
3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 15 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 15
3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 16 3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 16
3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 17 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8. Interactions With Forking . . . . . . . . . . . . . . . . 18 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 18
3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 18 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 18
3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 19 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 19
4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 20 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 20
4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 22 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3. addTransceiver . . . . . . . . . . . . . . . . . . . 22 4.1.3. addTransceiver . . . . . . . . . . . . . . . . . . . 22
4.1.4. createDataChannel . . . . . . . . . . . . . . . . . . 22 4.1.4. createDataChannel . . . . . . . . . . . . . . . . . . 23
4.1.5. createOffer . . . . . . . . . . . . . . . . . . . . . 23 4.1.5. createOffer . . . . . . . . . . . . . . . . . . . . . 23
4.1.6. createAnswer . . . . . . . . . . . . . . . . . . . . 24 4.1.6. createAnswer . . . . . . . . . . . . . . . . . . . . 24
4.1.7. SessionDescriptionType . . . . . . . . . . . . . . . 24 4.1.7. SessionDescriptionType . . . . . . . . . . . . . . . 25
4.1.7.1. Use of Provisional Answers . . . . . . . . . . . 25 4.1.7.1. Use of Provisional Answers . . . . . . . . . . . 25
4.1.7.2. Rollback . . . . . . . . . . . . . . . . . . . . 26 4.1.7.2. Rollback . . . . . . . . . . . . . . . . . . . . 26
4.1.8. setLocalDescription . . . . . . . . . . . . . . . . . 27 4.1.8. setLocalDescription . . . . . . . . . . . . . . . . . 27
4.1.9. setRemoteDescription . . . . . . . . . . . . . . . . 28 4.1.9. setRemoteDescription . . . . . . . . . . . . . . . . 28
4.1.10. currentLocalDescription . . . . . . . . . . . . . . . 28 4.1.10. currentLocalDescription . . . . . . . . . . . . . . . 28
4.1.11. pendingLocalDescription . . . . . . . . . . . . . . . 28 4.1.11. pendingLocalDescription . . . . . . . . . . . . . . . 28
4.1.12. currentRemoteDescription . . . . . . . . . . . . . . 28 4.1.12. currentRemoteDescription . . . . . . . . . . . . . . 28
4.1.13. pendingRemoteDescription . . . . . . . . . . . . . . 29 4.1.13. pendingRemoteDescription . . . . . . . . . . . . . . 29
4.1.14. canTrickleIceCandidates . . . . . . . . . . . . . . . 29 4.1.14. canTrickleIceCandidates . . . . . . . . . . . . . . . 29
4.1.15. setConfiguration . . . . . . . . . . . . . . . . . . 29 4.1.15. setConfiguration . . . . . . . . . . . . . . . . . . 30
4.1.16. addIceCandidate . . . . . . . . . . . . . . . . . . . 30 4.1.16. addIceCandidate . . . . . . . . . . . . . . . . . . . 30
5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 31 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 31
5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 31 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Implementation Requirements . . . . . . . . . . . . . 31 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 33 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 31
5.1.3. Profile Names and Interoperability . . . . . . . . . 33 4.2.4. setCodecPreferences . . . . . . . . . . . . . . . . . 32
5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 34 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 32
5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 34 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 32
5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 40 5.1.1. Implementation Requirements . . . . . . . . . . . . . 33
5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 43 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 34
5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 43 5.1.3. Profile Names and Interoperability . . . . . . . . . 34
5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 44 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 35
5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 44 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 35
5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 44 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 41
5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 49 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 44
5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 50 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 44
5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 50 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 45
5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 50 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 45
5.5. Processing a Local Description . . . . . . . . . . . . . 51 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 45
5.6. Processing a Remote Description . . . . . . . . . . . . . 51 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 50
5.7. Parsing a Session Description . . . . . . . . . . . . . . 52 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 51
5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 53 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 51
5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 51
5.5. Processing a Local Description . . . . . . . . . . . . . 52
5.6. Processing a Remote Description . . . . . . . . . . . . . 53
5.7. Parsing a Session Description . . . . . . . . . . . . . . 53
5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 54
5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 55 5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 55
5.7.3. Semantics Verification . . . . . . . . . . . . . . . 57 5.7.3. Semantics Verification . . . . . . . . . . . . . . . 58
5.8. Applying a Local Description . . . . . . . . . . . . . . 58 5.8. Applying a Local Description . . . . . . . . . . . . . . 59
5.9. Applying a Remote Description . . . . . . . . . . . . . . 60 5.9. Applying a Remote Description . . . . . . . . . . . . . . 60
5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 63 5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 64
6. Demux placeholder . . . . . . . . . . . . . . . . . . . . . . 64 6. Processing RTP/RTCP packets . . . . . . . . . . . . . . . . . 66
7. Processing RTP packets . . . . . . . . . . . . . . . . . . . 64 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 68
8.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 66 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 72
8.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 82
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 82
12.1. Normative References . . . . . . . . . . . . . . . . . . 81 11.2. Informative References . . . . . . . . . . . . . . . . . 85
12.2. Informative References . . . . . . . . . . . . . . . . . 84 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 86
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 85 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction 1. Introduction
This document describes how the W3C WEBRTC RTCPeerConnection This document describes how the W3C WEBRTC RTCPeerConnection
interface [W3C.WD-webrtc-20140617] is used to control the setup, interface [W3C.WD-webrtc-20140617] is used to control the setup,
management and teardown of a multimedia session. management and teardown of a multimedia session.
1.1. General Design of JSEP 1.1. General Design of JSEP
The thinking behind WebRTC call setup has been to fully specify and The thinking behind WebRTC call setup has been to fully specify and
skipping to change at page 11, line 17 skipping to change at page 11, line 17
m= section, and once a session description is applied, a m= section m= section, and once a session description is applied, a m= section
is always associated with exactly one RtpTransceiver. is always associated with exactly one RtpTransceiver.
RtpTransceivers can be created explicitly by the application or RtpTransceivers can be created explicitly by the application or
implicitly by calling setRemoteDescription with an offer that adds implicitly by calling setRemoteDescription with an offer that adds
new m= sections. new m= sections.
3.4.2. RtpSenders 3.4.2. RtpSenders
RtpSenders allow the application to control how RTP media is sent. RtpSenders allow the application to control how RTP media is sent.
In particular, the application can control whether an RtpSender is
active or not, which affects the directionality attribute of the
associated m= section.
3.4.3. RtpReceivers 3.4.3. RtpReceivers
RtpReceivers allows the application to control how RTP media is RtpReceivers allows the application to control how RTP media is
received. In particular, the application can control whether an received.
RtpReceiver is active or not, which affects the directionality
attribute of the associated m= section.
3.5. ICE 3.5. ICE
3.5.1. ICE Gathering Overview 3.5.1. ICE Gathering Overview
JSEP gathers ICE candidates as needed by the application. Collection JSEP gathers ICE candidates as needed by the application. Collection
of ICE candidates is referred to as a gathering phase, and this is of ICE candidates is referred to as a gathering phase, and this is
triggered either by the addition of a new or recycled m= line to the triggered either by the addition of a new or recycled m= line to the
local session description, or new ICE credentials in the description, local session description, or new ICE credentials in the description,
indicating an ICE restart. Use of new ICE credentials can be indicating an ICE restart. Use of new ICE credentials can be
skipping to change at page 15, line 5 skipping to change at page 14, line 47
3.6. Video Size Negotiation 3.6. Video Size Negotiation
Video size negotiation is the process through which a receiver can Video size negotiation is the process through which a receiver can
use the "a=imageattr" SDP attribute [RFC6236] to indicate what video use the "a=imageattr" SDP attribute [RFC6236] to indicate what video
frame sizes it is capable of receiving. A receiver may have hard frame sizes it is capable of receiving. A receiver may have hard
limits on what its video decoder can process, or it may wish to limits on what its video decoder can process, or it may wish to
constrain what it receives due to application preferences, e.g. a constrain what it receives due to application preferences, e.g. a
specific size for the window in which the video will be displayed. specific size for the window in which the video will be displayed.
Note that certain codecs support transmission of samples with aspect
ratios other than 1.0 (i.e., non-square pixels). JSEP
implementations will not transmit non-square pixels, but SHOULD
receive and render such video with the correct aspect ratio.
However, sample aspect ratio has no impact on the size negotiation
described below; all dimensions assume square pixels.
3.6.1. Creating an imageattr Attribute 3.6.1. Creating an imageattr Attribute
In order to determine the limits on what video resolution a receiver In order to determine the limits on what video resolution a receiver
wants to receive, it will intersect its decoder hard limits with any wants to receive, it will intersect its decoder hard limits with any
mandatory constraints that have been applied to the associated mandatory constraints that have been applied to the associated
MediaStreamTrack. If the decoder limits are unknown, e.g. when using MediaStreamTrack. If the decoder limits are unknown, e.g. when using
a software decoder, the mandatory constraints are used directly. For a software decoder, the mandatory constraints are used directly. For
the answerer, these mandatory constraints can be applied to the the answerer, these mandatory constraints can be applied to the
remote MediaStreamTracks that are created by a setRemoteDescription remote MediaStreamTracks that are created by a setRemoteDescription
call, and will affect the output of the ensuing createAnswer call. call, and will affect the output of the ensuing createAnswer call.
skipping to change at page 16, line 24 skipping to change at page 16, line 24
of a given MediaStreamTrack, which is producing video of a certain of a given MediaStreamTrack, which is producing video of a certain
resolution, receives an "a=imageattr recv" attribute, it MUST check resolution, receives an "a=imageattr recv" attribute, it MUST check
to see if the original resolution meets the size criteria specified to see if the original resolution meets the size criteria specified
in the attribute, and adapt the resolution accordingly by scaling (if in the attribute, and adapt the resolution accordingly by scaling (if
appropriate). Note that when considering a MediaStreamTrack that is appropriate). Note that when considering a MediaStreamTrack that is
producing rotated video, the unrotated resolution MUST be used. This producing rotated video, the unrotated resolution MUST be used. This
is required regardless of whether the receiver supports performing is required regardless of whether the receiver supports performing
receive-side rotation (e.g., through CVO), as it significantly receive-side rotation (e.g., through CVO), as it significantly
simplifies the matching logic. simplifies the matching logic.
For an "a=imageattr recv" attribute, only size limits are considered. For the purposes of resolution negotiation, only size limits are
Any other values, e.g. aspect ratio, MUST be ignored. considered. Any other values, e.g. picture or sample aspect ratio,
MUST be ignored.
When communicating with a non-JSEP endpoint, multiple relevant When communicating with a non-JSEP endpoint, multiple relevant
"a=imageattr recv" attributes may be received. If this occurs, "a=imageattr recv" attributes may be received. If this occurs,
attributes other than the one with the highest "q=" value MUST be attributes other than the one with the highest "q=" value MUST be
ignored. ignored.
If an "a=imageattr recv" attribute references a different video codec If an "a=imageattr recv" attribute references a different video codec
than what has been selected for the MediaStreamTrack, it MUST be than what has been selected for the MediaStreamTrack, it MUST be
ignored. ignored.
skipping to change at page 17, line 9 skipping to change at page 17, line 11
upscaling policy for each sent track. For this case, if upscaling is upscaling policy for each sent track. For this case, if upscaling is
permitted by policy, the sender SHOULD apply upscaling in order to permitted by policy, the sender SHOULD apply upscaling in order to
provide the desired resolution. Otherwise, the sender MUST NOT apply provide the desired resolution. Otherwise, the sender MUST NOT apply
upscaling. The sender SHOULD NOT upscale in other cases, even if the upscaling. The sender SHOULD NOT upscale in other cases, even if the
policy permits it. Upscaling MUST NOT change the track aspect ratio. policy permits it. Upscaling MUST NOT change the track aspect ratio.
If there is no appropriate and permitted scaling mechanism that If there is no appropriate and permitted scaling mechanism that
allows the received size limits to be satisfied, the sender MUST NOT allows the received size limits to be satisfied, the sender MUST NOT
transmit the track. transmit the track.
If the attribute includes a "sar=" (sample aspect ratio) value set to
something other than "1.0", indicating the receiver wants to receive
non-square pixels, this cannot be satisfied and the sender MUST NOT
transmit the track.
In the special case of receiving a maximum resolution of [0, 0], as In the special case of receiving a maximum resolution of [0, 0], as
described above, the sender MUST NOT transmit the track. described above, the sender MUST NOT transmit the track.
3.7. Simulcast 3.7. Simulcast
JSEP supports simulcast of a MediaStreamTrack, where multiple JSEP supports simulcast of a MediaStreamTrack, where multiple
encodings of the source media can be transmitted within the context encodings of the source media can be transmitted within the context
of a single m= section. The current JSEP API is designed to allow of a single m= section. The current JSEP API is designed to allow
applications to send simulcasted media but only to receive a single applications to send simulcasted media but only to receive a single
encoding. This allows for multi-user scenarios where each sending encoding. This allows for multi-user scenarios where each sending
skipping to change at page 20, line 12 skipping to change at page 20, line 18
application wants to only keep a single session, it can simply application wants to only keep a single session, it can simply
terminate the sessions that it no longer needs. terminate the sessions that it no longer needs.
4. Interface 4. Interface
This section details the basic operations that must be present to This section details the basic operations that must be present to
implement JSEP functionality. The actual API exposed in the W3C API implement JSEP functionality. The actual API exposed in the W3C API
may have somewhat different syntax, but should map easily to these may have somewhat different syntax, but should map easily to these
concepts. concepts.
4.1. Methods 4.1. PeerConnection
4.1.1. Constructor 4.1.1. Constructor
The PeerConnection constructor allows the application to specify The PeerConnection constructor allows the application to specify
global parameters for the media session, such as the STUN/TURN global parameters for the media session, such as the STUN/TURN
servers and credentials to use when gathering candidates, as well as servers and credentials to use when gathering candidates, as well as
the initial ICE candidate policy and pool size, and also the bundle the initial ICE candidate policy and pool size, and also the bundle
policy to use. policy to use.
If an ICE candidate policy is specified, it functions as described in If an ICE candidate policy is specified, it functions as described in
skipping to change at page 22, line 23 skipping to change at page 22, line 30
The default multiplexing policy MUST be set to "require". The default multiplexing policy MUST be set to "require".
Implementations MAY choose to reject attempts by the application to Implementations MAY choose to reject attempts by the application to
set the multiplexing policy to "negotiate". set the multiplexing policy to "negotiate".
4.1.2. addTrack 4.1.2. addTrack
The addTrack method adds a MediaStreamTrack to the PeerConnection, The addTrack method adds a MediaStreamTrack to the PeerConnection,
using the MediaStream argument to associate the track with other using the MediaStream argument to associate the track with other
tracks in the same MediaStream, so that they can be added to the same tracks in the same MediaStream, so that they can be added to the same
"LS" group when creating an offer or answer. addTrack attempts to "LS" group when creating an offer or answer. addTrack attempts to
minimize the number of transceivers as follows: The track will be minimize the number of transceivers as follows: If the PeerConnection
attached to the first compatible transceiver (of the same media type) is in the "have-remote-offer" state, the track will be attached to
which has never had a direction of "sendonly" or "sendrecv". If no the first compatible transceiver that was created by the most recent
such transceiver exists, then one will be constructed as described in call to setRemoteDescription() and does not have a local track.
Otherwise, a new transceiver will be created, as described in
Section 4.1.3. Section 4.1.3.
4.1.3. addTransceiver 4.1.3. addTransceiver
The addTransceiver method adds a new RTPTransceiver to the The addTransceiver method adds a new RTPTransceiver to the
PeerConnection. If a MediaStreamTrack argument is provided, then the PeerConnection. If a MediaStreamTrack argument is provided, then the
transceiver will be configured with that media type and the track transceiver will be configured with that media type and the track
will be attached to the transceiver. Otherwise, the application MUST will be attached to the transceiver. Otherwise, the application MUST
explicitly specify the type; this mode is useful for creating explicitly specify the type; this mode is useful for creating
recvonly transceivers as well as for creating transceivers to which a recvonly transceivers as well as for creating transceivers to which a
skipping to change at page 24, line 29 skipping to change at page 24, line 36
codec/RTP/RTCP options negotiated for this session, and any codec/RTP/RTCP options negotiated for this session, and any
candidates that have been gathered by the ICE Agent. An options candidates that have been gathered by the ICE Agent. An options
parameter may be supplied to provide additional control over the parameter may be supplied to provide additional control over the
generated answer. generated answer.
As an answer, the generated SDP will contain a specific configuration As an answer, the generated SDP will contain a specific configuration
that specifies how the media plane should be established; for each that specifies how the media plane should be established; for each
SDP line, the generation of the SDP must follow the process defined SDP line, the generation of the SDP must follow the process defined
for generating an answer from the document that specifies the given for generating an answer from the document that specifies the given
SDP line. The exact handling of answer generation is detailed in SDP line. The exact handling of answer generation is detailed in
Section 5.3. below. Section 5.3. below.
Session descriptions generated by createAnswer must be immediately Session descriptions generated by createAnswer must be immediately
usable by setLocalDescription; like createOffer, the returned usable by setLocalDescription; like createOffer, the returned
description should reflect the current state of the system. Because description should reflect the current state of the system. Because
this method may need to inspect the system state to determine the this method may need to inspect the system state to determine the
currently available resources, it may need to be implemented as an currently available resources, it may need to be implemented as an
async operation. async operation.
Calling this method may do things such as generate new ICE Calling this method may do things such as generate new ICE
credentials, but does not trigger candidate gathering or change media credentials, but does not trigger candidate gathering or change media
skipping to change at page 27, line 31 skipping to change at page 27, line 41
type field indicates whether the description should be processed as type field indicates whether the description should be processed as
an offer, provisional answer, or final answer; offers and answers are an offer, provisional answer, or final answer; offers and answers are
checked differently, using the various rules that exist for each SDP checked differently, using the various rules that exist for each SDP
line. line.
This API changes the local media state; among other things, it sets This API changes the local media state; among other things, it sets
up local resources for receiving and decoding media. In order to up local resources for receiving and decoding media. In order to
successfully handle scenarios where the application wants to offer to successfully handle scenarios where the application wants to offer to
change from one media format to a different, incompatible format, the change from one media format to a different, incompatible format, the
PeerConnection must be able to simultaneously support use of both the PeerConnection must be able to simultaneously support use of both the
current and pending local descriptions (e.g. support codecs that current and pending local descriptions (e.g. support codecs that
exist in both descriptions) until a final answer is received, at exist in both descriptions) until a final answer is received, at
which point the PeerConnection can fully adopt the pending local which point the PeerConnection can fully adopt the pending local
description, or roll back to the current description if the remote description, or roll back to the current description if the remote
side denied the change. side denied the change.
This API indirectly controls the candidate gathering process. When a This API indirectly controls the candidate gathering process. When a
local description is supplied, and the number of transports currently local description is supplied, and the number of transports currently
in use does not match the number of transports needed by the local in use does not match the number of transports needed by the local
description, the PeerConnection will create transports as needed and description, the PeerConnection will create transports as needed and
begin gathering candidates for them. begin gathering candidates for them.
skipping to change at page 31, line 19 skipping to change at page 31, line 25
If the ufrag is not present, then the end-of-candidates indication If the ufrag is not present, then the end-of-candidates indication
MUST be assumed to apply to the relevant m= section in the most MUST be assumed to apply to the relevant m= section in the most
recently applied remote description. If neither the MID nor the m= recently applied remote description. If neither the MID nor the m=
index is present, then the indication MUST be assumed to apply to all index is present, then the indication MUST be assumed to apply to all
m= sections in the most recently applied remote description. m= sections in the most recently applied remote description.
This call will result in a change to the state of the ICE Agent, and This call will result in a change to the state of the ICE Agent, and
may result in a change to media state if it results in connectivity may result in a change to media state if it results in connectivity
being established. being established.
4.2. RtpTransceiver
4.2.1. stop
The stop method stops an RtpTransceiver. This will cause future
calls to createOffer to generate a zero port for the associated m=
section. See below for more details.
4.2.2. stopped
The stopped method returns "true" if the transceiver has been
stopped, either by a call to stopTransceiver or by applying an answer
that rejects the associated m= section, and "false" otherwise.
A stopped RtpTransceiver does not send any outgoing RTP or RTCP or
process any incoming RTP or RTCP. It cannot be restarted.
4.2.3. setDirection
The setDirection method sets the direction of a transceiver, which
affects the direction attribute of the associated m= section on
future calls to createOffer and createAnswer.
When creating offers, the transceiver direction is directly reflected
in the output, even for reoffers. When creating answers, the
transceiver direction is intersected with the offered direction, as
explained in the Section 5.3 section below.
4.2.4. setCodecPreferences
The setCodecPreferences method sets the codec preferences of a
transceiver, which in turn affect the presence and order of codecs of
the associated m= section on future calls to createOffer and
createAnswer. Note that setCodecPreferences does not directly affect
which codec the implemtation decides to send. It only affects which
codecs the implementation indicates that it prefers to receive, via
the offer or answer. Even when a codec is excluded by
setCodecPreferences, it still may be used to send until the next
offer/answer exchange discards it.
The codec preferences of an RtpTransceiver can cause codecs to be
excluded by subsequent calls to createOffer and createAnswer, in
which case the corresponding media formats in the associated m=
section will be excluded. The codec preferences cannot add media
formats that would otherwise not be present. This includes codecs
that were not negotiated in a previous offer/answer exchange that
included the transceiver.
The codec preferences of an RtpTransceiver can also determine the
order of codecs in subsequent calls to createOffer and createAnswer,
in which case the order of the media formats in the associated m=
section will match. However, the codec preferences cannot change the
order of the media formats after an answer containing the transceiver
has been applied. At this point, codecs can only be removed, not
reordered.
5. SDP Interaction Procedures 5. SDP Interaction Procedures
This section describes the specific procedures to be followed when This section describes the specific procedures to be followed when
creating and parsing SDP objects. creating and parsing SDP objects.
5.1. Requirements Overview 5.1. Requirements Overview
JSEP implementations must comply with the specifications listed below JSEP implementations must comply with the specifications listed below
that govern the creation and processing of offers and answers. that govern the creation and processing of offers and answers.
skipping to change at page 34, line 7 skipping to change at page 35, line 23
o Any profile matching the following patterns MUST be accepted: o Any profile matching the following patterns MUST be accepted:
"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]"
o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no
effect; support for DTLS-SRTP is determined by the presence of one effect; support for DTLS-SRTP is determined by the presence of one
or more "a=fingerprint" attribute. Note that lack of an or more "a=fingerprint" attribute. Note that lack of an
"a=fingerprint" attribute will lead to negotiation failure. "a=fingerprint" attribute will lead to negotiation failure.
o The use of AVPF or AVP simply controls the timing rules used for o 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 RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute
is present, assume AVPF timing, i.e. a default value of "trr- is present, assume AVPF timing, i.e., a default value of "trr-
int=0". Otherwise, assume that AVPF is being used in an AVP int=0". Otherwise, assume that AVPF is being used in an AVP
compatible mode and use AVP timing, i.e., "trr-int=4". compatible mode and use AVP timing, i.e., "trr-int=4".
o For data m= sections, JSEP endpoints MUST support receiving the o For data m= sections, JSEP endpoints MUST support receiving the
"UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards
compatibility) profiles. compatibility) profiles.
Note that re-offers by JSEP endpoints MUST use the correct profile Note that re-offers by JSEP endpoints MUST use the correct profile
strings even if the initial offer/answer exchange used an (incorrect) strings even if the initial offer/answer exchange used an (incorrect)
older profile string. older profile string.
skipping to change at page 36, line 11 skipping to change at page 37, line 27
this m= section, but given that no candidates have yet been this m= section, but given that no candidates have yet been
gathered, the "dummy" port value of 9 (Discard) MUST be used, as gathered, the "dummy" port value of 9 (Discard) MUST be used, as
indicated in [I-D.ietf-ice-trickle], Section 5.1. indicated in [I-D.ietf-ice-trickle], Section 5.1.
o To properly indicate use of DTLS, the <proto> field MUST be set to o To properly indicate use of DTLS, the <proto> field MUST be set to
"UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the
default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as
specified in [I-D.nandakumar-mmusic-proto-iana-registration] if specified in [I-D.nandakumar-mmusic-proto-iana-registration] if
the default candidate uses TCP transport. the default candidate uses TCP transport.
o If codec preferences have been set for the associated transceiver,
media formats MUST be generated in the corresponding order, and
MUST exclude any codecs not present in the codec preferences.
o Unless excluded by the above restrictions, the media formats MUST
include the mandatory audio/video codecs as specified in
[I-D.ietf-rtcweb-audio](see Section 3) and
[I-D.ietf-rtcweb-video](see Section 5).
The m= line MUST be followed immediately by a "c=" line, as specified 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 in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP4 gathered, the "c=" line must contain the "dummy" value "IN IP4
0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1. 0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.
Each m= section MUST include the following attribute lines: [I-D.ietf-mmusic-sdp-mux-attributes] groups SDP attributes into
different categories. To avoid unnecessary duplication when
bundling, Section 8.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation]
specifies that attributes of category IDENTICAL or TRANSPORT should
not be repeated in bundled m= sections.
The following attributes, which are of a category other than
IDENTICAL or TRANSPORT, MUST be included in each m= section:
o An "a=mid" line, as specified in [RFC5888], Section 4. When o An "a=mid" line, as specified in [RFC5888], Section 4. When
generating mid values, it is RECOMMENDED that the values be 3 generating mid values, it is RECOMMENDED that the values be 3
bytes or less, to allow them to efficiently fit into the RTP bytes or less, to allow them to efficiently fit into the RTP
header extension defined in header extension defined in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
containing the dummy value "9 IN IP4 0.0.0.0", because no
candidates have yet been gathered.
o A direction attribute which is the same as that of the associated o A direction attribute which is the same as that of the associated
transceiver. transceiver.
o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as o For each media format on the m= line, "a=rtpmap" and "a=fmtp"
specified in [RFC4566], Section 6. The audio and video codecs lines, as specified in [RFC4566], Section 6, and [RFC3264],
that MUST be supported are specified in Section 5.1.
[I-D.ietf-rtcweb-audio](see Section 3) and
[I-D.ietf-rtcweb-video](see Section 5).
o If this m= section is for media with configurable frame sizes, o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6. specified in [RFC4566], Section 6.
o If this m= section is for video media, and there are known o If this m= section is for video media, and there are known
limitations on the size of images which can be decoded, an limitations on the size of images which can be decoded, an
"a=imageattr" line, as specified in Section 3.6. "a=imageattr" line, as specified in Section 3.6.
skipping to change at page 37, line 11 skipping to change at page 38, line 36
of the primary codec and an "a=fmtp" line that references the of the primary codec and an "a=fmtp" line that references the
payload type of the primary codec, as specified in [RFC4588], payload type of the primary codec, as specified in [RFC4588],
Section 8.1. Section 8.1.
o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
as specified in [RFC4566], Section 6. The FEC mechanisms that as specified in [RFC4566], Section 6. The FEC mechanisms that
MUST be supported are specified in [I-D.ietf-rtcweb-fec], MUST be supported are specified in [I-D.ietf-rtcweb-fec],
Section 6, and specific usage for each media type is outlined in Section 6, and specific usage for each media type is outlined in
Sections 4 and 5. Sections 4 and 5.
o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
Section 15.4.
o One or more "a=fingerprint" line(s) for each of the endpoint's
certificates, as specified in [I-D.ietf-mmusic-4572-update].
o An "a=setup" line, as specified in [RFC4145], Section 4, and
clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
The role value in the offer MUST be "actpass".
o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1.
o An "a=rtcp-mux-only" line, as specified in
[I-D.ietf-mmusic-mux-exclusive] Section 4, if and only if the RTP/
RTCP multiplexing policy is "require".
o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5.
o For each supported RTP header extension, an "a=extmap" line, as o For each supported RTP header extension, an "a=extmap" line, as
specified in [RFC5285], Section 5. The list of header extensions specified in [RFC5285], Section 5. The list of header extensions
that SHOULD/MUST be supported is specified in that SHOULD/MUST be supported is specified in
[I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions
that require encryption MUST be specified as indicated in that require encryption MUST be specified as indicated in
[RFC6904], Section 4. [RFC6904], Section 4.
o For each supported RTCP feedback mechanism, an "a=rtcp-fb" o For each supported RTCP feedback mechanism, an "a=rtcp-fb"
mechanism, as specified in [RFC4585], Section 4.2. The list of mechanism, as specified in [RFC4585], Section 4.2. The list of
RTCP feedback mechanisms that SHOULD/MUST be supported is RTCP feedback mechanisms that SHOULD/MUST be supported is
specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1.
o An "a=ssrc" line, as specified in [RFC5576], Section 4.1,
indicating the SSRC to be used for sending media, along with the
mandatory "cname" source attribute, as specified in Section 6.1,
indicating the CNAME for the source. The CNAME MUST be generated
in accordance with Section 4.9 of [I-D.ietf-rtcweb-rtp-usage].
o If RTX is supported for this media type, another "a=ssrc" line
with the RTX SSRC, and an "a=ssrc-group" line, as specified in
[RFC5576], section 4.2, with semantics set to "FID" and including
the primary and RTX SSRCs.
o If FEC is supported for this media type, another "a=ssrc" line
with the FEC SSRC, and an "a=ssrc-group" line with semantics set
to "FEC-FR" and including the primary and FEC SSRCs, as specified
in [RFC5956], section 4.3. For simplicity, if both RTX and FEC
are supported, the FEC SSRC MUST be the same as the RTX SSRC.
o If the bundle policy for this PeerConnection is set to "max- o If the bundle policy for this PeerConnection is set to "max-
bundle", and this is not the first m= section, or the bundle bundle", and this is not the first m= section, or the bundle
policy is set to "balanced", and this is not the first m= section policy is set to "balanced", and this is not the first m= section
for this media type, an "a=bundle-only" line. for this media type, an "a=bundle-only" line.
o If the RtpSender of the RtpTransceiver associated with this o If the RtpTransceiver has a sendrecv or sendonly direction:
m=section is active:
* An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], * An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],
Section 2. Section 2.
* An "a=ssrc" line, as specified in [RFC5576], Section 4.1, o If the RtpTransceiver has a sendrecv or sendonly direction, and
indicating the SSRC to be used for sending media, along with the application has specified RID values or has specified more
the mandatory "cname" source attribute, as specified in than one encoding in the RtpSenders's parameters, an "a=rid" line
Section 6.1, indicating the CNAME for the source. The CNAME for each encoding specified. The "a=rid" line is specified in
MUST be generated in accordance with Section 4.9 of
[I-D.ietf-rtcweb-rtp-usage].
* If RTX is supported for this media type, another "a=ssrc" line
with the RTX SSRC, and an "a=ssrc-group" line, as specified in
[RFC5576], section 4.2, with semantics set to "FID" and
including the primary and RTX SSRCs.
* If FEC is supported for this media type, another "a=ssrc" line
with the FEC SSRC, and an "a=ssrc-group" line with semantics
set to "FEC-FR" and including the primary and FEC SSRCs, as
specified in [RFC5956], section 4.3. For simplicity, if both
RTX and FEC are supported, the FEC SSRC MUST be the same as the
RTX SSRC.
o If the RtpTransceiver's RtpSender is active, and the application
has specified RID values or has specified more than one encoding
in the RtpSenders's parameters, an "a=rid" line for each encoding
specified. The "a=rid" line is specified in
[I-D.ietf-mmusic-rid], and its direction MUST be "send". If the [I-D.ietf-mmusic-rid], and its direction MUST be "send". If the
application has chosen a RID value, it MUST be used as the rid- application has chosen a RID value, it MUST be used as the rid-
identifier; otherwise a RID value MUST be generated by the identifier; otherwise a RID value MUST be generated by the
implementation. When generating RID values, it is RECOMMENDED implementation. When generating RID values, it is RECOMMENDED
that the values be 3 bytes or less, to allow them to efficiently that the values be 3 bytes or less, to allow them to efficiently
fit into the RTP header extension defined in fit into the RTP header extension defined in
[I-D.ietf-avtext-rid], Section 11. If no encodings have been [I-D.ietf-avtext-rid], Section 11. If no encodings have been
specified, or only one encoding is specified but without a RID specified, or only one encoding is specified but without a RID
value, then no "a=rid" lines are generated. value, then no "a=rid" lines are generated.
o If the RtpTransceiver's RtpSender is active and more than one o If the RtpTransceiver has a sendrecv or sendonly direction and
"a=rid" line has been generated, an "a=simulcast" line, with more than one "a=rid" line has been generated, an "a=simulcast"
direction "send", as defined in [I-D.ietf-mmusic-sdp-simulcast], line, with direction "send", as defined in
Section 6.2. The list of RIDs MUST include all of the RID [I-D.ietf-mmusic-sdp-simulcast], Section 6.2. The list of RIDs
identifiers used in the "a=rid" lines for this m= section. MUST include all of the RID identifiers used in the "a=rid" lines
for this m= section.
The following attributes, which are of category IDENTICAL or
TRANSPORT, MUST appear only in "m=" sections which either have a
unique address or which are associated with the bundle-tag. (In
initial offers, this means those "m=" sections which do not contain
an "a=bundle-only" attribute.
o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
Section 15.4.
o An "a=fingerprint" line for each of the endpoint's certificates,
as specified in [RFC4572], Section 5; the digest algorithm used
for the fingerprint MUST match that used in the certificate
signature.
o An "a=setup" line, as specified in [RFC4145], Section 4, and
clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
The role value in the offer MUST be "actpass".
o An "a=dtls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp]
Section 5.2.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1,
containing the dummy value "9 IN IP4 0.0.0.0", because no
candidates have yet been gathered.
o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1.
o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5.
Lastly, if a data channel has been created, a m= section MUST be Lastly, if a data channel has been created, a m= section MUST be
generated for data. The <media> field MUST be set to "application" generated for data. The <media> field MUST be set to "application"
and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default
candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default
candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt" candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt"
value MUST be set to "webrtc-datachannel" as specified in value MUST be set to "webrtc-datachannel" as specified in
[I-D.ietf-mmusic-sctp-sdp], Section 4.1. [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=fingerprint", and "a=setup" lines MUST be included as mentioned "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included as
above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp- mentioned above, along with an "a=fmtp:webrtc-datachannel" line and
port" line referencing the SCTP port number as defined in an "a=sctp-port" line referencing the SCTP port number as defined in
[I-D.ietf-mmusic-sctp-sdp], Section 4.1. [I-D.ietf-mmusic-sctp-sdp], Section 4.1.
Once all m= sections have been generated, a session-level "a=group" Once all m= sections have been generated, a session-level "a=group"
attribute MUST be added as specified in [RFC5888]. This attribute attribute MUST be added as specified in [RFC5888]. This attribute
MUST have semantics "bundle", and MUST include the mid identifiers of MUST have semantics "bundle", and MUST include the mid identifiers of
each m= section. The effect of this is that the browser offers all each m= section. The effect of this is that the browser offers all
m= sections as one bundle group. However, whether the m= sections m= sections as one bundle group. However, whether the m= sections
are bundle-only or not depends on the bundle policy. are bundle-only or not depends on the bundle policy.
The next step is to generate session-level lip sync groups as defined The next step is to generate session-level lip sync groups as defined
skipping to change at page 40, line 4 skipping to change at page 40, line 51
media level SHOULD generally be at the media level even if they are media level SHOULD generally be at the media level even if they are
identical. This promotes readability, especially if one of a set of identical. This promotes readability, especially if one of a set of
initially identical attributes is subsequently changed. initially identical attributes is subsequently changed.
Attributes other than the ones specified above MAY be included, Attributes other than the ones specified above MAY be included,
except for the following attributes which are specifically except for the following attributes which are specifically
incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage],
and MUST NOT be included: and MUST NOT be included:
o "a=crypto" o "a=crypto"
o "a=key-mgmt"
o "a=key-mgmt"
o "a=ice-lite" o "a=ice-lite"
Note that when bundle is used, any additional attributes that are Note that when bundle is used, any additional attributes that are
added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes] added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes]
on how those attributes interact with bundle. on how those attributes interact with bundle.
Note that these requirements are in some cases stricter than those of Note that these requirements are in some cases stricter than those of
SDP. Implementations MUST be prepared to accept compliant SDP even SDP. Implementations MUST be prepared to accept compliant SDP even
if it would not conform to the requirements for generating SDP in if it would not conform to the requirements for generating SDP in
this specification. this specification.
skipping to change at page 41, line 25 skipping to change at page 42, line 23
o If an RtpTransceiver is stopped and is not associated with an m= o If an RtpTransceiver is stopped and is not associated with an m=
section, an m= section MUST NOT be generated for it. This section, an m= section MUST NOT be generated for it. This
prevents adding back RtpTransceivers whose m= sections were prevents adding back RtpTransceivers whose m= sections were
recycled and used for a new RtpTransceiver in a previous offer/ recycled and used for a new RtpTransceiver in a previous offer/
answer exchange, as described above. answer exchange, as described above.
o If an RtpTransceiver has been stopped and is associated with an m= o If an RtpTransceiver has been stopped and is associated with an m=
section, and the m= section is not being recycled as described section, and the m= section is not being recycled as described
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 the "a=msid", "a=ssrc", and "a=ssrc-group" lines removed. zero and the "a=msid" line removed.
o For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", o For RtpTransceivers that are not stopped, the "a=msid" line MUST
and "a=ssrc-group" lines MUST stay the same if they are present in stay the same if they are present in the current description.
the current description.
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, protocol,
and address of the default candidate for the m= section, as and address of the default candidate for the m= section, as
described in [RFC5245], Section 4.3. If ICE checking has already described in [RFC5245], Section 4.3. If ICE checking has already
completed for one or more candidate pairs and a candidate pair is completed for one or more candidate pairs and a candidate pair is
in active use, then that pair MUST be used, even if ICE has not in active use, then that pair MUST be used, even if ICE has not
yet completed. Note that this differs from the guidance in yet completed. Note that this differs from the guidance in
[RFC5245], Section 9.1.2.2, which only refers to offers created [RFC5245], Section 9.1.2.2, which only refers to offers created
when ICE has completed. Each "a=rtcp" attribute line MUST also be when ICE has completed. In each case, if no RTP candidates have
filled in with the port and address of the appropriate default yet been gathered, dummy values MUST be used, as described above.
candidate, either the default RTP or RTCP candidate, depending on
whether RTCP multiplexing is currently active or not. Note that
if RTCP multiplexing is being offered, but not yet active, the
default RTCP candidate MUST be used, as indicated in [RFC5761],
section 5.1.3. In each case, if no candidates of the desired type
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.
o If the m= section is not bundled into another m= section, an
"a=rtcp" attribute line MUST be added with of the default RTCP
candidate, as indicated in [RFC5761], section 5.1.3.
o If the m= section is not bundled into another m= section, for each o If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering candidate that has been gathered during the most recent gathering
phase (see Section 3.5.1), an "a=candidate" line MUST be added, as phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
defined in [RFC5245], Section 4.3., paragraph 3. If candidate defined in [RFC5245], Section 4.3., paragraph 3. If candidate
gathering for the section has completed, an "a=end-of-candidates" gathering for the section has completed, an "a=end-of-candidates"
attribute MUST be added, as described in [I-D.ietf-ice-trickle], attribute MUST be added, as described in [I-D.ietf-ice-trickle],
Section 9.3. If the m= section is bundled into another m= Section 9.3. If the m= section is bundled into another m=
section, both "a=candidate" and "a=end-of-candidates" MUST be section, both "a=candidate" and "a=end-of-candidates" MUST be
omitted. omitted.
o For RtpTransceivers that are still present, the "a=msid", o For RtpTransceivers that are still present, the "a=msid" line MUST
"a=ssrc", and "a=ssrc-group" lines MUST stay the same. stay the same.
o For RtpTransceivers that are still present, the "a=rid" lines MUST o For RtpTransceivers that are still present, the "a=rid" lines MUST
stay the same. stay the same.
o For RtpTransceivers that are still present, any "a=simulcast" line o For RtpTransceivers that are still present, any "a=simulcast" line
MUST stay the same. MUST stay the same.
o If any RtpTransceiver has been stopped, the port MUST be set to o If any RtpTransceiver has been stopped, the port MUST be set to
zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be zero and the "a=msid" line MUST be removed.
removed.
o If any RtpTransceiver has been added, and there exists a m= o If any RtpTransceiver has been added, and there exists a m=
section with a zero port in the current local description or the section with a zero port in the current local description or the
current remote description, that m= section MUST be recycled by current remote description, that m= section MUST be recycled by
generating a m= section for the added RtpTransceiver as if the m= generating a m= section for the added RtpTransceiver as if the m=
section were being added to session description, except that section were being added to session description, except that
instead of adding it, the generated m= section replaces the m= instead of adding it, the generated m= section replaces the m=
section with a zero port. section with a zero port.
If the initial offer was applied using setLocalDescription, and an If the initial offer was applied using setLocalDescription, and an
skipping to change at page 43, line 6 skipping to change at page 43, line 44
setRemoteDescription, meaning the PeerConnection is in the "remote- setRemoteDescription, meaning the PeerConnection is in the "remote-
pranswer" or "stable" states, an offer is generated based on the pranswer" or "stable" states, an offer is generated based on the
negotiated session descriptions by following the steps mentioned for negotiated session descriptions by following the steps mentioned for
the "local-offer" state above. the "local-offer" state above.
In addition, for each non-recycled, non-rejected m= section in the In addition, for each non-recycled, non-rejected m= section in the
new offer, the following adjustments are made based on the contents new offer, the following adjustments are made based on the contents
of the corresponding m= section in the current remote description: of the corresponding m= section in the current remote description:
o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
only include codecs present in the most recent answer. only include codecs present in the most recent answer which have
not been excluded by the codec preferences of the associated
transceiver.
o The media formats on the m= line MUST be generated in the same
order as in the current local description.
o The RTP header extensions MUST only include those that are present o The RTP header extensions MUST only include those that are present
in the most recent answer. in the most recent answer.
o The RTCP feedback extensions MUST only include those that are o The RTCP feedback extensions MUST only include those that are
present in the most recent answer. present in the most recent answer.
o The "a=rtcp" line MUST only be added if the most recent answer did
not include an "a=rtcp-mux" line.
o The "a=rtcp-mux" line MUST only be added if present in the most o The "a=rtcp-mux" line MUST only be added if present in the most
recent answer. recent answer.
o The "a=rtcp-mux-only" line MUST only be added if present in the o The "a=rtcp-mux-only" line MUST only be added if present in the
most recent answer. most recent answer.
o The "a=rtcp-rsize" line MUST only be added if present in the most o The "a=rtcp-rsize" line MUST only be added if present in the most
recent answer. recent answer.
The "a=group:BUNDLE" attribute MUST include the mid identifiers The "a=group:BUNDLE" attribute MUST include the mid identifiers
skipping to change at page 46, line 27 skipping to change at page 47, line 27
following rules must be followed: following rules must be followed:
o The port value would normally be set to the port of the default o The port value would normally be set to the port of the default
ICE candidate for this m= section, but given that no candidates ICE candidate for this m= section, but given that no candidates
have yet been gathered, the "dummy" port value of 9 (Discard) MUST have yet been gathered, the "dummy" port value of 9 (Discard) MUST
be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1.
o The <proto> field MUST be set to exactly match the <proto> field o The <proto> field MUST be set to exactly match the <proto> field
for the corresponding m= line in the offer. for the corresponding m= line in the offer.
o If codec preferences have been set for the associated transceiver,
media formats MUST be generated in the corresponding order, and
MUST exclude any codecs not present in the codec preferences or
not present in the offer.
o Unless excluded by the above restrictions, the media formats MUST
include the mandatory audio/video codecs as specified in
[I-D.ietf-rtcweb-audio](see Section 3) and
[I-D.ietf-rtcweb-video](see Section 5).
The m= line MUST be followed immediately by a "c=" line, as specified 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 in [RFC4566], Section 5.7. Again, as no candidates have yet been
gathered, the "c=" line must contain the "dummy" value "IN IP4 gathered, the "c=" line must contain the "dummy" value "IN IP4
0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1. 0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1.
If the offer supports bundle, all m= sections to be bundled must use If the offer supports bundle, all m= sections to be bundled must use
the same ICE credentials and candidates; all m= sections not being the same ICE credentials and candidates; all m= sections not being
bundled must use unique ICE credentials and candidates. Each m= bundled must use unique ICE credentials and candidates. Each m=
section MUST include the following: section MUST contain the following attributes (which are of attribute
types other than IDENTICAL and TRANSPORT):
o If and only if present in the offer, an "a=mid" line, as specified o If and only if present in the offer, an "a=mid" line, as specified
in [RFC5888], Section 9.1. The "mid" value MUST match that in [RFC5888], Section 9.1. The "mid" value MUST match that
specified in the offer. specified in the offer.
o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, o A direction attribute, determined by applying the rules regarding
containing the dummy value "9 IN IP4 0.0.0.0", because no the offered direction specified in [RFC3264], Section 6.1, and
candidates have yet been gathered. then intersecting with the direction of the associated
RtpTransceiver. For example, in the case where an m= section is
o A direction attribute which is the same as that of the associated offered as "sendonly", and the local transceiver is set to
transceiver. "sendrecv", the result in the answer is a "recvonly" direction.
o For each supported codec that is present in the offer, "a=rtpmap" o For each media format on the m= line, "a=rtpmap" and "a=fmtp"
and "a=fmtp" lines, as specified in [RFC4566], Section 6, and lines, as specified in [RFC4566], Section 6, and [RFC3264],
[RFC3264], Section 6.1. The audio and video codecs that MUST be Section 6.1.
supported are specified in [I-D.ietf-rtcweb-audio](see Section 3)
and [I-D.ietf-rtcweb-video](see Section 5).
o If this m= section is for media with configurable frame sizes, o If this m= section is for media with configurable frame sizes,
e.g. audio, an "a=maxptime" line, indicating the smallest of the e.g. audio, an "a=maxptime" line, indicating the smallest of the
maximum supported frame sizes out of all codecs included above, as maximum supported frame sizes out of all codecs included above, as
specified in [RFC4566], Section 6. specified in [RFC4566], Section 6.
o If this m= section is for video media, and there are known o If this m= section is for video media, and there are known
limitations on the size of images which can be decoded, an limitations on the size of images which can be decoded, an
"a=imageattr" line, as specified in Section 3.6. "a=imageattr" line, as specified in Section 3.6.
skipping to change at page 47, line 26 skipping to change at page 48, line 37
indicating "rtx" with the clock rate of the primary codec and an indicating "rtx" with the clock rate of the primary codec and an
"a=fmtp" line that references the payload type of the primary "a=fmtp" line that references the payload type of the primary
codec, as specified in [RFC4588], Section 8.1. codec, as specified in [RFC4588], Section 8.1.
o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines,
as specified in [RFC4566], Section 6. The FEC mechanisms that as specified in [RFC4566], Section 6. The FEC mechanisms that
MUST be supported are specified in [I-D.ietf-rtcweb-fec], MUST be supported are specified in [I-D.ietf-rtcweb-fec],
Section 6, and specific usage for each media type is outlined in Section 6, and specific usage for each media type is outlined in
Sections 4 and 5. Sections 4 and 5.
o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
Section 15.4.
o One or more "a=fingerprint" line(s) for each of the endpoint's
certificates, as specified in [I-D.ietf-mmusic-4572-update].
o An "a=setup" line, as specified in [RFC4145], Section 4, and
clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
The role value in the answer MUST be "active" or "passive"; the
"active" role is RECOMMENDED.
o If present in the offer, an "a=rtcp-mux" line, as specified in
[RFC5761], Section 5.1.1. If the "require" RTCP multiplexing
policy is set and no "a=rtcp-mux" line is present in the offer,
then the m=line MUST be marked as rejected by setting the port in
the m= line to zero, as indicated in [RFC3264], Section 6.
o If present in the offer, an "a=rtcp-mux-only" line, as specified
in [I-D.ietf-mmusic-mux-exclusive], Section 4.3.
o If present in the offer, an "a=rtcp-rsize" line, as specified in
[RFC5506], Section 5.
o For each supported RTP header extension that is present in the o For each supported RTP header extension that is present in the
offer, an "a=extmap" line, as specified in [RFC5285], Section 5. offer, an "a=extmap" line, as specified in [RFC5285], Section 5.
The list of header extensions that SHOULD/MUST be supported is The list of header extensions that SHOULD/MUST be supported is
specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header
extensions that require encryption MUST be specified as indicated extensions that require encryption MUST be specified as indicated
in [RFC6904], Section 4. in [RFC6904], Section 4.
o For each supported RTCP feedback mechanism that is present in the o For each supported RTCP feedback mechanism that is present in the
offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585],
Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ Section 4.2. The list of RTCP feedback mechanisms that SHOULD/
MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage],
Section 5.1. Section 5.1.
o If the RtpSender of the RtpTransceiver associated with this o If the RtpTransceiver has a sendrecv or sendonly direction:
m=section is active:
* An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], * An "a=msid" line, as specified in [I-D.ietf-mmusic-msid],
Section 2. Section 2.
* An "a=ssrc" line, as specified in [RFC5576], Section 4.1, Each m= section which is not bundled into another m= section, MUST
indicating the SSRC to be used for sending media, along with contain the following attributes (which are of category IDENTICAL or
the mandatory "cname" source attribute, as specified in TRANSPORT):
Section 6.1, indicating the CNAME for the source. The CNAME
MUST be generated in accordance with Section 4.9 of
[I-D.ietf-rtcweb-rtp-usage].
* If RTX has been negotiated for this m= section, another o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245],
"a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as Section 15.4.
specified in [RFC5576], section 4.2, with semantics set to
"FID" and including the primary and RTX SSRCs.
* If FEC has been negotiated for this m= section, another o An "a=fingerprint" line for each of the endpoint's certificates,
"a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line as specified in [RFC4572], Section 5; the digest algorithm used
with semantics set to "FEC-FR" and including the primary and for the fingerprint MUST match that used in the certificate
FEC SSRCs, as specified in [RFC5956], section 4.3. For signature.
simplicity, if both RTX and FEC are supported, the FEC SSRC
MUST be the same as the RTX SSRC. o An "a=setup" line, as specified in [RFC4145], Section 4, and
clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5.
The role value in the answer MUST be "active" or "passive"; the
"active" role is RECOMMENDED. The role value MUST be consistent
with the existing DTLS connection, if one exists and is being
continued.
o An "a=dtls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp]
Section 5.3.
o If present in the offer, an "a=rtcp-mux" line, as specified in
[RFC5761], Section 5.1.1. Otherwise, an "a=rtcp" line, as
specified in [RFC3605], Section 2.1, containing the dummy value "9
IN IP4 0.0.0.0" (because no candidates have yet been gathered).
o If present in the offer, an "a=rtcp-rsize" line, as specified in
[RFC5506], Section 5.
If a data channel m= section has been offered, a m= section MUST also 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 be generated for data. The <media> field MUST be set to
"application" and the <proto> and "fmt" fields MUST be set to exactly "application" and the <proto> and "fmt" fields MUST be set to exactly
match the fields in the offer. match the fields in the offer.
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=candidate", "a=fingerprint", and "a=setup" lines MUST be included "a=candidate", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST
as mentioned above, along with an "a=fmtp:webrtc-datachannel" line be included under the conditions described above, along with an
and an "a=sctp-port" line referencing the SCTP port number as defined "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line
in [I-D.ietf-mmusic-sctp-sdp], Section 4.1. referencing the SCTP port number as defined in
[I-D.ietf-mmusic-sctp-sdp], Section 4.1.
If "a=group" attributes with semantics of "BUNDLE" are offered, If "a=group" attributes with semantics of "BUNDLE" are offered,
corresponding session-level "a=group" attributes MUST be added as corresponding session-level "a=group" attributes MUST be added as
specified in [RFC5888]. These attributes MUST have semantics specified in [RFC5888]. These attributes MUST have semantics
"BUNDLE", and MUST include the all mid identifiers from the offered "BUNDLE", and MUST include the all mid identifiers from the offered
bundle groups that have not been rejected. Note that regardless of bundle groups that have not been rejected. Note that regardless of
the presence of "a=bundle-only" in the offer, no m= sections in the the presence of "a=bundle-only" in the offer, no m= sections in the
answer should have an "a=bundle-only" line. answer should have an "a=bundle-only" line.
Attributes that are common between all m= sections MAY be moved to Attributes that are common between all m= sections MAY be moved to
skipping to change at page 49, line 42 skipping to change at page 50, line 42
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
[RFC5245], Section 4.3. Note, however, that the m= line protocol [RFC5245], Section 4.3. Note, however, that the m= line protocol
need not match the default candidate, because this protocol value need not match the default candidate, because this protocol value
must instead match what was supplied in the offer, as described must instead match what was supplied in the offer, as described
above. Each "a=rtcp" attribute line MUST also be filled in with
the port and address of the appropriate default candidate, either
the default RTP or RTCP candidate, depending on whether RTCP
multiplexing is enabled in the answer. In each case, if no
candidates of the desired type have yet been gathered, dummy
values MUST be used, as described in the initial answer section
above. above.
o The media formats on the m= line MUST be generated in the same
order as in the current local description.
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 [RFC5245], Section 9.2.1.1. If must be created as specified in [RFC5245], Section 9.2.1.1. If
the m= section is bundled into another m= section, it still MUST the m= section is bundled into another m= section, it still MUST
NOT contain any ICE credentials. NOT contain any ICE credentials.
o If the m= section is not bundled into another m= section and RTCP
multiplexing is not active, an "a=rtcp" attribute line MUST be
filled in with the port and address of the default RTCP candidate.
If no RTCP candidates have yet been gathered, dummy values MUST be
used, as described in the initial answer section above.
o If the m= section is not bundled into another m= section, for each o If the m= section is not bundled into another m= section, for each
candidate that has been gathered during the most recent gathering candidate that has been gathered during the most recent gathering
phase (see Section 3.5.1), an "a=candidate" line MUST be added, as phase (see Section 3.5.1), an "a=candidate" line MUST be added, as
defined in [RFC5245], Section 4.3., paragraph 3. If candidate defined in [RFC5245], Section 4.3., paragraph 3. If candidate
gathering for the section has completed, an "a=end-of-candidates" gathering for the section has completed, an "a=end-of-candidates"
attribute MUST be added, as described in [I-D.ietf-ice-trickle], attribute MUST be added, as described in [I-D.ietf-ice-trickle],
Section 9.3. If the m= section is bundled into another m= Section 9.3. If the m= section is bundled into another m=
section, both "a=candidate" and "a=end-of-candidates" MUST be section, both "a=candidate" and "a=end-of-candidates" MUST be
omitted. omitted.
o For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", o For RtpTransceivers that are not stopped, the "a=msid" line MUST
and "a=ssrc-group" lines MUST stay the same. stay the same.
5.3.3. Options Handling 5.3.3. Options Handling
The createAnswer method takes as a parameter an RTCAnswerOptions The createAnswer method takes as a parameter an RTCAnswerOptions
object. The set of parameters for RTCAnswerOptions is different than object. The set of parameters for RTCAnswerOptions is different than
those supported in RTCOfferOptions; the IceRestart option is those supported in RTCOfferOptions; the IceRestart option is
unnecessary, as ICE credentials will automatically be changed for all unnecessary, as ICE credentials will automatically be changed for all
m= lines where the offerer chose to perform ICE restart. m= lines where the offerer chose to perform ICE restart.
The following options are supported in RTCAnswerOptions. The following options are supported in RTCAnswerOptions.
skipping to change at page 52, line 38 skipping to change at page 53, line 43
it is invalid. The exact details of this process are explained it is invalid. The exact details of this process are explained
below. below.
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 its defining ABNF, check that it conforms to [RFC4566] and according to its defining ABNF, check that it conforms to [RFC4566]
[RFC3264] semantics, and then either parse and store or discard the and [RFC3264] semantics, and then either parse and store or discard
provided value, as described below. A partial list of ABNF the provided value, as described below.
definitions for SDP attributes can found in:
+-------------------------+----------------------------------+
| Attribute | Reference |
+-------------------------+----------------------------------+
| ptime | [RFC4566] Section 9 |
| maxptime | [RFC4566] Section 9 |
| rtpmap | [RFC4566] Section 9 |
| recvonly | [RFC4566] Section 9 |
| sendrecv | [RFC4566] Section 9 |
| sendonly | [RFC4566] Section 9 |
| inactive | [RFC4566] Section 9 |
| framerate | [RFC4566] Section 9 |
| fmtp | [RFC4566] Section 9 |
| quality | [RFC4566] Section 9 |
| msid | [I-D.ietf-mmusic-msid] Section 2 |
| rtcp | [RFC3605] Section 2.1 |
| setup | [RFC4145] Section 3, 4, and 5 |
| connection | [RFC4145] Section 3, 4, and 5 |
| fingerprint | [RFC4572] Section 5 |
| rtcp-fb | [RFC4585] Section 4.2 |
| candidate | [RFC5245] Section 15 |
| extmap | [RFC5285] Section 7 |
| mid | [RFC5888] Section 4 and 5 |
| group | [RFC5888] Section 4 and 5 |
| imageattr | [RFC6236] Section 3.1 |
| extmap (encrypt option) | [RFC6904] Section 4 |
+-------------------------+----------------------------------+
Table 1: SDP ABNF References
[TODO: ensure that every line is listed below.]
If the 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,
This ensures that implementations do not accidentally misinterpret even if the value is to be discarded. This ensures that
ambiguous SDP. implementations do not accidentally misinterpret ambiguous SDP.
5.7.1. Session-Level Parsing 5.7.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, and their ordering same type (typically "a=") can occur in any order, and their ordering
is not meaningful. is not meaningful.
For non-attribute (non-"a=") lines, their sequencing, syntax, and The following non-attribute lines are not meaningful in the JSEP
semantics, are checked, as mentioned above. The following lines are context and MAY be discarded once they have been checked.
not meaningful in the JSEP context and MAY be discarded once they
have been checked.
The "c=" line MUST be checked for syntax but its value is not The "c=" line MUST be checked for syntax but its value is not
used. This supersedes the guidance in [RFC5245], Section 6.1, to used. This supersedes the guidance in [RFC5245], Section 6.1, to
use "ice-mismatch" to indicate mismatches between "c=" and the use "ice-mismatch" to indicate mismatches between "c=" and the
candidate lines; because JSEP always uses ICE, "ice-mismatch" is candidate lines; because JSEP always uses ICE, "ice-mismatch" is
not useful in this context. not useful in this context.
The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are
not used by this specification; they MUST be checked for syntax not used by this specification; they MUST be checked for syntax
but their values are not used. but their values are not used.
The remaining lines are processed as follows: The remaining non-attribute lines are processed as follows:
The "v=" line MUST have a version of 0, as specified in [RFC4566], The "v=" line MUST have a version of 0, as specified in [RFC4566],
Section 5.1. Section 5.1.
The "o=" line MUST be parsed as specified in [RFC4566], The "o=" line MUST be parsed as specified in [RFC4566],
Section 5.2. Section 5.2.
The "b=" line, if present, MUST be parsed as specified in The "b=" line, if present, MUST be parsed as specified in
[RFC4566], Section 5.8, and the bwtype and bandwidth values [RFC4566], Section 5.8, and the bwtype and bandwidth values
stored. stored.
Specific processing MUST be applied for the following session-level Finally, the attribute lines are processed. Specific processing MUST
attribute ("a=") lines: be applied for the following session-level attribute ("a=") lines:
o Any "a=group" lines are parsed as specified in [RFC5888], o Any "a=group" lines are parsed as specified in [RFC5888],
Section 5, and the group's semantics and mids are stored. Section 5, and the group's semantics and mids are stored.
o If present, a single "a=ice-lite" line is parsed as specified in o If present, a single "a=ice-lite" line is parsed as specified in
[RFC5245], Section 15.3, and a value indicating the presence of [RFC5245], Section 15.3, and a value indicating the presence of
ice-lite is stored. ice-lite is stored.
o If present, a single "a=ice-ufrag" line is parsed as specified in o If present, a single "a=ice-ufrag" line is parsed as specified in
[RFC5245], Section 15.4, and the ufrag value is stored. [RFC5245], Section 15.4, and the ufrag value is stored.
skipping to change at page 55, line 8 skipping to change at page 55, line 19
in [RFC5245], Section 15.5, and the set of specified options is in [RFC5245], Section 15.5, and the set of specified options is
stored. stored.
o Any "a=fingerprint" lines are parsed as specified in [RFC4572], o Any "a=fingerprint" lines are parsed as specified in [RFC4572],
Section 5, and the set of fingerprint and algorithm values is Section 5, and the set of fingerprint and algorithm values is
stored. stored.
o If present, a single "a=setup" line is parsed as specified in o If present, a single "a=setup" line is parsed as specified in
[RFC4145], Section 4, and the setup value is stored. [RFC4145], Section 4, and the setup value is stored.
o If present, a single "a=dtls-id" line is parsed as specified in
[I-D.ietf-mmusic-dtls-sdp] Section 5, and the dtls-id value is
stored.
o Any "a=extmap" lines are parsed as specified in [RFC5285], o Any "a=extmap" lines are parsed as specified in [RFC5285],
Section 5, and their values are stored. Section 5, and their values are stored.
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 media sections. continues with the lines in media sections.
5.7.2. Media Section Parsing 5.7.2. Media Section Parsing
Like the session-level lines, the media session lines MUST occur in Like the session-level lines, the media session 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],
skipping to change at page 55, line 47 skipping to change at page 56, line 15
o If present, a single "a=ice-ufrag" line is parsed as specified in o If present, a single "a=ice-ufrag" line is parsed as specified in
[RFC5245], Section 15.4, and the ufrag value is stored. [RFC5245], Section 15.4, and the ufrag value is stored.
o If present, a single "a=ice-pwd" line is parsed as specified in o If present, a single "a=ice-pwd" line is parsed as specified in
[RFC5245], Section 15.4, and the password value is stored. [RFC5245], Section 15.4, and the password value is stored.
o If present, a single "a=ice-options" line is parsed as specified o If present, a single "a=ice-options" line is parsed as specified
in [RFC5245], Section 15.5, and the set of specified options is in [RFC5245], Section 15.5, and the set of specified options is
stored. stored.
o Any "a=candidate" attributes MUST be parsed as specified in
[RFC5245], Section 15.1, and their values stored.
o Any "a=remote-candidates" attributes MUST be parsed as specified
in [RFC5245], Section 15.2, but their values are ignored.
o If present, a single "a=end-of-candidates" attribute MUST be
parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and
its presence or absence flagged and stored.
o Any "a=fingerprint" lines are parsed as specified in [RFC4572], o Any "a=fingerprint" lines are parsed as specified in [RFC4572],
Section 5, and the set of fingerprint and algorithm values is Section 5, and the set of fingerprint and algorithm values is
stored. stored.
o If present, a single "a=setup" line is parsed as specified in
[RFC4145], Section 4, and the setup value is stored.
If the "m=" proto value indicates use of RTP, as described in the If the "m=" proto value indicates use of RTP, as described in the
Section 5.1.3 section above, the following attribute lines MUST be Section 5.1.3 section above, the following attribute lines MUST be
processed: processed:
o The "m=" fmt value MUST be parsed as specified in [RFC4566], o The "m=" fmt value MUST be parsed as specified in [RFC4566],
Section 5.14, and the individual values stored. Section 5.14, and the individual values stored.
o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in
[RFC4566], Section 6, and their values stored. [RFC4566], Section 6, and their values stored.
o If present, a single "a=ptime" line MUST be parsed as described in o If present, a single "a=ptime" line MUST be parsed as described in
[RFC4566], Section 6, and its value stored. [RFC4566], Section 6, and its value stored.
o If present, a single "a=maxptime" line MUST be parsed as described o If present, a single "a=maxptime" line MUST be parsed as described
in [RFC4566], Section 6, and its value stored. in [RFC4566], Section 6, and its value stored.
o If present, a single direction attribute line (e.g. "a=sendrecv") o If present, a single direction attribute line (e.g. "a=sendrecv")
MUST be parsed as described in [RFC4566], Section 6, and its value MUST be parsed as described in [RFC4566], Section 6, and its value
stored. stored.
o Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as o Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as
specified in [RFC5576], Sections 4.1-4.2, and their values stored. specified in [RFC5576], Sections 4.1-4.2, and their values stored.
o Any "a=extmap" attributes MUST be parsed as specified in o Any "a=extmap" attributes MUST be parsed as specified in
[RFC5285], Section 5, and their values stored. [RFC5285], Section 5, and their values stored.
o Any "a=rtcp-fb" attributes MUST be parsed as specified in o Any "a=rtcp-fb" attributes MUST be parsed as specified in
skipping to change at page 57, line 5 skipping to change at page 57, line 31
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 single "a=msid" attribute MUST be parsed as o If present, a single "a=msid" attribute MUST be parsed as
specified in [I-D.ietf-mmusic-msid], Section 3.2, and its value specified in [I-D.ietf-mmusic-msid], Section 3.2, and its value
stored. stored.
o Any "a=candidate" attributes MUST be parsed as specified in
[RFC5245], Section 4.3, and their values stored.
o Any "a=remote-candidates" attributes MUST be parsed as specified
in [RFC5245], Section 4.3, but their values are ignored.
o If present, a single "a=end-of-candidates" attribute MUST be
parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and
its presence or absence flagged and 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 58, line 8 skipping to change at page 58, line 24
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.2 MUST be present. These features enumerated in Section 5.1.2 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.
* ICE ufrag and password values, which MUST comply with the size * ICE ufrag and password values, which MUST comply with the size
limits specified in [RFC5245], Section 15.4. limits specified in [RFC5245], Section 15.4.
* dtls-id value, which MUST be set according to
[I-D.ietf-mmusic-dtls-sdp] Section 5. If this is a re-offer
and the dtls-id value is different from that presently in use,
the DTLS connection is not being continued and the remote
description MUST be part of an ICE restart, together with new
ufrag and password values. If this is an answer, the dtls-id
value, if present, MUST be the same as in the offer.
* DTLS setup value, which MUST be set according to the rules * DTLS setup value, which MUST be set according to the rules
specified in [RFC5763], Section 5, and MUST be consistent with specified in [RFC5763], Section 5 and MUST be consistent with
the selected role of the current DTLS connection, if one the selected role of the current DTLS connection, if one exists
exists.[TODO: may need revision, i.e., use of actpass and is being continued.
* DTLS fingerprint values, where at least one fingerprint MUST be * DTLS fingerprint values, where at least one fingerprint MUST be
present. present.
o All RID values referenced in an "a=simulcast" line MUST exist as o All RID values referenced in an "a=simulcast" line MUST exist as
"a=rid" lines. "a=rid" lines.
o Each m= section is also checked to ensure prohibited features are o Each m= section is also checked to ensure prohibited features are
not used. If this is a local description, the "ice-lite" not used. If this is a local description, the "ice-lite"
attribute MUST NOT be specified. attribute MUST NOT be specified.
skipping to change at page 61, line 32 skipping to change at page 62, line 8
following steps: following steps:
+ If the m= section is sendrecv or recvonly, and there are + If the m= section is sendrecv or recvonly, and there are
RtpTransceivers of the same type that were added to the RtpTransceivers of the same type that were added to the
PeerConnection by addTrack and are not associated with any PeerConnection by addTrack and are not associated with any
m= section and are not stopped, find the first (according to m= section and are not stopped, find the first (according to
the canonical order described in Section 5.2.1) such the canonical order described in Section 5.2.1) such
RtpTransceiver. RtpTransceiver.
+ If no RtpTransceiver was found in the previous step, create + If no RtpTransceiver was found in the previous step, create
one with an inactive RtpSender and active RtpReceiver. one with a recvonly direction.
+ Associate the found or created RtpTransceiver with the m= + Associate the found or created RtpTransceiver with the m=
section by setting the value of the RtpTransceiver's mid section by setting the value of the RtpTransceiver's mid
attribute to the MID of the m= section. If the m= section attribute to the MID of the m= section. If the m= section
does not include a MID (i.e., the remote side does not does not include a MID (i.e., the remote side does not
support the MID extension), generate a value for the support the MID extension), generate a value for the
RtpTransceiver mid attribute, following the guidance for RtpTransceiver mid attribute, following the guidance for
"a=mid" mentioned in Section 5.2.1. "a=mid" mentioned in Section 5.2.1.
* For each specified media format that is also supported by the * For each specified media format that is also supported by the
skipping to change at page 62, line 49 skipping to change at page 63, line 26
5% to RTCP. If more accurate control of bandwidth is needed, 5% to RTCP. If more accurate control of bandwidth is needed,
"TIAS" should be used instead of "AS". "TIAS" should be used instead of "AS".
* For any "RR" or "RS" bandwidth values, handle as specified in * For any "RR" or "RS" bandwidth values, handle as specified in
[RFC3556], Section 2. [RFC3556], Section 2.
* Any specified "CT" bandwidth value MUST be ignored, as the * Any specified "CT" bandwidth value MUST be ignored, as the
meaning of this construct at the media level is not well meaning of this construct at the media level is not well
defined. defined.
* [TODO: handling of CN, telephone-event, "red"]
* If the media section is of type audio: * If the media section is of type audio:
+ For each specified "CN" media format, enable DTX for all
supported media formats with the same clockrate, as
described in [RFC3389], Section 5, except for formats that
have their own internal DTX mechanisms. DTX for such
formats (e.g., Opus) is controlled via fmtp parameters, as
discussed in Section 5.2.3.2.
+ For each specified "telephone-event" media format, enable
DTMF transmission for all supported media formats with the
same clockrate, as described in [RFC4733], Section 2.5.1.2.
If the application attempts to transmit DTMF when using a
media format that does not have a corresponding telephone-
event format, this MUST result in an error.
+ For any specified "ptime" value, configure the available + For any specified "ptime" value, configure the available
media formats to use the specified packet size. If the media formats to use the specified packet size. If the
specified size is not supported for a media format, use the specified size is not supported for a media format, use the
next closest value instead. 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 the Section 5.10 section below. follow the processing defined in the Section 5.10 section below.
5.10. Applying an Answer 5.10. 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 media section, the following steps MUST be performed: For each media section, the following steps MUST be performed:
o If the media section has been rejected (i.e. port is set to zero o If the media section has been rejected (i.e. port is set to zero
in the answer), stop any reception or transmission of media for in the answer), stop any reception or transmission of media for
this section, and discard any associated ICE components, as this section, and discard any associated ICE components, as
described in Section 9.2.1.3 of [RFC5245]. described in Section 9.2.1.3 of [RFC5245].
o If the remote DTLS fingerprint has been changed, tear down the o If the remote DTLS fingerprint has been changed or the dtls-id has
existing DTLS connection. changed, tear down the DTLS connection. If a DTLS connection
needs to be torn down but the answer does not indicate an ICE
restart, an error MUST be generated. If an ICE restart is
performed without a change in dtls-id or fingerprint, then the
same DTLS connection is continued over the new ICE channel.
o If no valid DTLS connection exists, prepare to start a DTLS o If no valid DTLS connection exists, prepare to start a DTLS
connection, using the specified roles and fingerprints, on any connection, using the specified roles and fingerprints, on any
underlying ICE components, once they are active. underlying ICE components, once they are active.
o If the media section proto value indicates use of RTP: o If the media section proto value indicates use of RTP:
* If the media section references any media formats, RTP header * If the media section references any media formats, RTP header
extensions, or RTCP feedback mechanisms that were not present extensions, or RTCP feedback mechanisms that were not present
in the corresponding media section in the offer, this indicates in the corresponding media section in the offer, this indicates
a negotiation problem and MUST result in an error. a negotiation problem and MUST result in an error.
* If the media section has RTCP mux enabled, discard any RTCP * If the media section has RTCP mux enabled, discard any RTCP
component, and begin or continue muxing RTCP over the RTP component, and begin or continue muxing RTCP over the RTP
component, as specified in [RFC5761], Section 5.1.3. component, as specified in [RFC5761], Section 5.1.3.
Otherwise, transmit RTCP over the RTCP component; if no RTCP Otherwise, prepare to transmit RTCP over the RTCP component; if
component exists, because RTCP mux was previously enabled, this no RTCP component exists, because RTCP mux was previously
MUST result in an error. enabled, this MUST result in an error.
* If the media section has reduced-size RTCP enabled, configure * If the media section has reduced-size RTCP enabled, configure
the RTCP transmission for this media section to use reduced- the RTCP transmission for this media section to use reduced-
size RTCP, as specified in [RFC5506]. size RTCP, as specified in [RFC5506].
* [TODO: enable appropriate rtcp-fb mechanisms]
* If the directional attribute in the answer is of type * If the directional attribute in the answer is of type
"sendrecv" or "sendonly", prepare to start transmitting media "sendrecv" or "sendonly", choose the media format to send as
using the most preferred media format from the remote the most preferred media format from the remote description
description that is also present in the answer, as described in that is also present in the answer, as described in [RFC3264],
[RFC3264], Sections 6.1 and 7, once the underlying transport Sections 6.1 and 7, and start transmitting RTP media once the
layers have been established. [TODO: add discusssion of underlying transport layers have been established. If a SSRC
RED/FEC/RTX/CN] The payload type mapping from the remote has not already been chosen for this outgoing RTP stream,
description is used to determine payload types for the outgoing choose a random one.
RTP streams. Any RTP header extensions that were negotiated
should be included in the outgoing RTP streams, using the * The payload type mapping from the remote description is used to
extension mapping from the remote description; if the RID determine payload types for the outgoing RTP streams, including
header extension has been negotiated, and RID values are the payload type for the send media format chosen above. Any
specified, include the RID header extension in the outgoing RTP RTP header extensions that were negotiated should be included
streams, as indicated in [I-D.ietf-mmusic-rid], Section 4). If in the outgoing RTP streams, using the extension mapping from
simulcast is negotiated, send the number of Source RTP Streams the remote description; if the RID header extension has been
as specified in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2.2. negotiated, and RID values are specified, include the RID
header extension in the outgoing RTP streams, as indicated in
[I-D.ietf-mmusic-rid], Section 4.
* If simulcast has been negotiated, send the number of Source RTP
Streams as specified in [I-D.ietf-mmusic-sdp-simulcast],
Section 6.2.2.
* If the send media format chosen above has a corresponding "rtx"
media format, or a FEC mechanism has been negotiated, establish
a Redundancy RTP Stream with a random SSRC for each Source RTP
Stream, and start or continue transmitting RTX/FEC packets as
needed.
* If the send media format chosen above has a corresponding "red"
media format of the same clockrate, allow redundant encoding
using the specified format for resiliency purposes, as
discussed in [I-D.ietf-rtcweb-fec], Section 3.2. Note that
unlike RTX or FEC media formats, the "red" format is
transmitted on the Source RTP Stream, not the Redundancy RTP
Stream.
* Enable the RTCP feedback mechanisms referenced in the media
section for all Source RTP Streams using the specified media
formats. Specifically, begin or continue sending the requested
feedback types and reacting to received feedback, as specified
in [RFC4585], Section 4.2. When sending RTCP feedback, use the
SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC;
if no outgoing Source RTP Stream exists, choose a random one.
* If the directional attribute is of type "recvonly" or * If the directional attribute is of type "recvonly" or
"inactive", stop transmitting RTP media, although RTCP should "inactive", stop transmitting all RTP media, but continue
still be sent, as described in [RFC3264], Section 5.1. sending RTCP, as described in [RFC3264], Section 5.1.
o If the media section proto value indicates use of SCTP: o If the media section proto value indicates use of SCTP:
* If no SCTP association yet exists, prepare to initiate a SCTP * If no SCTP association yet exists, prepare to initiate a SCTP
association over the associated ICE component and DTLS association over the associated ICE component and DTLS
connection, using the local SCTP port value from the local connection, using the local SCTP port value from the local
description, and the remote SCTP port value from the remote description, and the remote SCTP port value from the remote
description, as described in [I-D.ietf-mmusic-sctp-sdp], description, as described in [I-D.ietf-mmusic-sctp-sdp],
Section 10.2. Section 10.2.
If the answer contains valid bundle groups, discard any ICE If the answer contains valid bundle groups, discard any ICE
components for the m= sections that will be bundled onto the primary components for the m= sections that will be bundled onto the primary
ICE components in each bundle, and begin muxing these m= sections ICE components in each bundle, and begin muxing these m= sections
accordingly, as described in accordingly, as described in
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2.
6. Demux placeholder 6. Processing RTP/RTCP packets
RTP demux algo goes here
7. Processing RTP packets
Note: The following algorithm does not yet have WG consensus but is Note: The following algorithm does not yet have WG consensus but is
included here as something concrete for the working group to discuss. included here as something concrete for the working group to discuss.
When an RTP packet is received by a transport and passes SRTP When an RTP packet is received by a transport and passes SRTP
authentication, that packet needs to be routed to the correct authentication, that packet needs to be routed to the correct
RtpReceiver. For each transport, the following steps MUST be RtpReceiver. For each transport, the following steps MUST be
followed to prepare to route packets: followed to prepare to route packets:
Construct a table mapping MID to RtpReceiver for each RtpReceiver Construct a table mapping MID to RtpReceiver for each RtpReceiver
configured to receive from this transport. configured to receive from this transport.
Construct a table mapping SSRC to RtpReceiver for each RtpReceiver Construct a table mapping incoming SSRC to RtpReceiver for each
configured to receive from this transport and for each SSRC that RtpReceiver configured to receive from this transport and for each
RtpReceiver is configured to receive. Some of the SSRCs may be SSRC that RtpReceiver is configured to receive. Some of the SSRCs
presesnt in the m= section corresponding to that RtpReceiver in may be present in the m= section corresponding to that RtpReceiver
the remote description. in the remote description.
Construct a table mapping outgoing SSRC to RtpSender for each
RtpSender configured to transmit from this transport and for each
SSRC that RtpSender is configured to use when sending.
Construct a table mapping payload type to RtpReceiver for each Construct a table mapping payload type to RtpReceiver for each
RtpReceiver configured to receive from this transport and for each RtpReceiver configured to receive from this transport and for each
payload type that RtpReceiver is configured to receive. The payload type that RtpReceiver is configured to receive. The
payload types of a given RtpReceiver are found in the m= section payload types of a given RtpReceiver are found in the m= section
corresponding to that RtpReceiver in the local description. If corresponding to that RtpReceiver in the local description. If
any payload type could map to more than one RtpReceiver, map to any payload type could map to more than one RtpReceiver, map to
the RtpReceiver whose m= section appears earliest in the local the RtpReceiver whose m= section appears earliest in the local
description. description.
As RtpTransceivers (and, thus, RtpReceivers) are added, removed,
stopped, or reconfigured, the tables above must also be updated.
For each RTP packet received, the following steps MUST be followed to For each RTP packet received, the following steps MUST be followed to
route the packet: route the packet:
If the packet has a MID and that MID is not in the table mapping If the packet has a MID and that MID is not in the table mapping
MID to RtpReceiver, drop the packet and stop. MID to RtpReceiver, drop the packet and stop.
If the packet has a MID and that MID is in the table mapping MID If the packet has a MID and that MID is in the table mapping MID
to RtpReceiver, update the SSRC mapping table to include an entry to RtpReceiver, update the incoming SSRC mapping table to include
mapping the packet's SSRC to the RtpReceiver. an entry that maps the packet's SSRC to the RtpReceiver for that
MID.
If the packet's SSRC is in the SSRC mapping table, route the If the packet's SSRC is in the incoming SSRC mapping table,
packet to the mapped RtpReceiver and stop. deliver the packet to the associated RtpReceiver and stop.
If the packet's payload type is in the payload type table, update If the packet's payload type is in the payload type table, update
the the SSRC mapping table to include an entry mapping the the the incoming SSRC mapping table to include an entry that maps
packet's SSRC to the RtpReceiver. Deliver the packet to the the packet's SSRC to the RtpReceiver for that payload type. In
RtpReceiver and stop. addition, deliver the packet to the associated RtpReceiver and
stop.
Otherwise, drop the packet. Otherwise, drop the packet.
For each RTCP packet received (including each RTCP packet that is
part of a compound RTCP packet), the following type-specific handling
MUST be performed to route the packet:
If the packet is of type SR, and the sender SSRC for the packet is
found in the incoming SSRC table, deliver a copy of the packet to
the RtpReceiver associated with that SSRC. In addition, for each
report block in the report whose SSRC is found in the outgoing
SSRC table, deliver a copy of the RTCP packet to the RtpSender
associated with that SSRC.
If the packet is of type RR, for each report block in the packet
whose SSRC is found in the outgoing SSRC table, deliver a copy of
the RTCP packet to the RtpSender associated with that SSRC.
If the packet is of type SDES, and the sender SSRC for the packet
is found in the incoming SSRC table, deliver the packet to the
RtpReceiver associated with that SSRC. In addition, for each
chunk in the packet that contains a MID that is in the table
mapping MID to RtpReceiver, update the incoming SSRC mapping table
to include an entry that maps the SSRC for that chunk to the
RtpReceiver associated with that MID. (This case can occur when
RTCP for a source is received before any RTP packets.)
If the packet is of type BYE, for each SSRC indicated in the
packet that is found in the incoming SSRC table, deliver a copy of
the packet to the RtpReceiver associated with that SSRC.
If the packet is of type RTPFB or PSFB, as defined in [RFC4585],
and the media source SSRC for the packet is found in the outgoing
SSRC table, deliver the packet to the RtpSender associated with
that SSRC.
After packets are routed to the RtpReceiver, further processing of After packets are routed to the RtpReceiver, further processing of
the RTP packets is done at the RtpReceiver level. This includes the RTP packets is done at the RtpReceiver level. This includes
using [I-D.ietf-mmusic-rid] to determine which RTP streams depend on using [I-D.ietf-mmusic-rid] to distinguish between multiple Encoded
or repair other RTP streams. Streams, as well as determine which Source RTP stream should be
repaired by a given Redundancy RTP stream. If the RTP packet's PT
As RtpTransceivers (and, thus, RtpReceivers) are added, removed, does not match any codec in use by the RtpReceiver, the packet will
stopped, or reconfigured, the tables above must also be updated. be dropped.
8. Examples 7. Examples
Note that this example section shows several SDP fragments. To Note that this example section shows several SDP fragments. To
format in 72 columns, some of the lines in SDP have been split into format in 72 columns, some of the lines in SDP have been split into
multiple lines, where leading whitespace indicates that a line is a multiple lines, where leading whitespace indicates that a line is a
continuation of the previous line. In addition, some blank lines continuation of the previous line. In addition, some blank lines
have been added to improve readability but are not valid in SDP. have been added to improve readability but are not valid in SDP.
More examples of SDP for WebRTC call flows can be found in More examples of SDP for WebRTC call flows can be found in
[I-D.nandakumar-rtcweb-sdp]. [I-D.nandakumar-rtcweb-sdp].
8.1. Simple Example 7.1. Simple Example
This section shows a very simple example that sets up a minimal audio This section shows a very simple example that sets up a minimal audio
/ video call between two browsers and does not use trickle ICE. The / video call between two browsers and does not use trickle ICE. The
example in the following section provides a more realistic example of example in the following section provides a more realistic example of
what would happen in a normal browser to browser connection. what would happen in a normal browser to browser connection.
The flow shows Alice's browser initiating the session to Bob's The flow shows Alice's browser initiating the session to Bob's
browser. The messages from Alice's JS to Bob's JS are assumed to browser. The messages from Alice's JS to Bob's JS are assumed to
flow over some signaling protocol via a web server. The JS on both flow over some signaling protocol via a web server. The JS on both
Alice's side and Bob's side waits for all candidates before sending Alice's side and Bob's side waits for all candidates before sending
skipping to change at page 68, line 31 skipping to change at page 70, line 31
a=ice-ufrag:ETEn1v9DoTMB9J4r a=ice-ufrag:ETEn1v9DoTMB9J4r
a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500
typ host typ host
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501
typ host typ host
a=end-of-candidates a=end-of-candidates
m=video 56502 UDP/TLS/RTP/SAVPF 100 101 m=video 56502 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=rtcp:56503 IN IP4 192.0.2.1 a=rtcp:56503 IN IP4 192.0.2.1
a=mid:v1 a=mid:v1
skipping to change at page 69, line 4 skipping to change at page 70, line 51
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv a=sendrecv
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=ice-ufrag:BGKkWnG5GmiUpdIV a=ice-ufrag:BGKkWnG5GmiUpdIV
a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7
a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7
a=ssrc-group:FID 1366781083 1366781084
a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502
typ host typ host
a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503
typ host typ host
a=end-of-candidates a=end-of-candidates
The SDP for |answer-A1| looks like: The SDP for |answer-A1| looks like:
v=0 v=0
o=- 6729291447651054566 1 IN IP4 0.0.0.0 o=- 6729291447651054566 1 IN IP4 0.0.0.0
skipping to change at page 69, line 50 skipping to change at page 71, line 46
a=rtpmap:98 telephone-event/48000 a=rtpmap:98 telephone-event/48000
a=maxptime:120 a=maxptime:120
a=ice-ufrag:6sFvz2gdLkEwjZEr a=ice-ufrag:6sFvz2gdLkEwjZEr
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000
typ host typ host
a=end-of-candidates a=end-of-candidates
m=video 20000 UDP/TLS/RTP/SAVPF 100 101 m=video 20000 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=rtcp 20001 IN IP4 192.0.2.2 a=rtcp 20001 IN IP4 192.0.2.2
a=mid:v1 a=mid:v1
a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1
PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0
skipping to change at page 70, line 26 skipping to change at page 72, line 21
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 3229706345 3229706346
8.2. Normal Examples 7.2. Normal Examples
This section shows a typical example of a session between two This section shows a typical example of a session between two
browsers setting up an audio channel and a data channel. Trickle ICE browsers setting up an audio channel and a data channel. Trickle ICE
is used in full trickle mode with a bundle policy of max-bundle, an is used in full trickle mode with a bundle policy of max-bundle, an
RTCP mux policy of require, and a single TURN server. Later, two RTCP mux policy of require, and a single TURN server. Later, two
video flows, one for the presenter and one for screen sharing, are video flows, one for the presenter and one for screen sharing, are
added to the session. This example shows Alice's browser initiating added to the session. This example shows Alice's browser initiating
the session to Bob's browser. The messages from Alice's JS to Bob's the session to Bob's browser. The messages from Alice's JS to Bob's
JS are assumed to flow over some signaling protocol via a web server. JS are assumed to flow over some signaling protocol via a web server.
skipping to change at page 73, line 34 skipping to change at page 75, line 34
a=ice-ufrag:ATEn1v9DoTMB9J4r a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
m=application 0 UDP/DTLS/SCTP webrtc-datachannel m=application 0 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=bundle-only a=bundle-only
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 a=sctp-port 5000
a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
skipping to change at page 75, line 33 skipping to change at page 76, line 38
a=maxptime:120 a=maxptime:120
a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
m=application 9 UDP/DTLS/SCTP webrtc-datachannel m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 a=sctp-port 5000
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active a=setup:active
skipping to change at page 76, line 40 skipping to change at page 77, line 44
a=maxptime:120 a=maxptime:120
a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5
a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host
a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx
raddr 192.168.2.3 rport 61665 raddr 192.168.2.3 rport 61665
a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay
raddr 55.66.77.88 rport 64532 raddr 55.66.77.88 rport 64532
a=end-of-candidates a=end-of-candidates
m=application 64532 UDP/DTLS/SCTP webrtc-datachannel m=application 64532 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 55.66.77.88 c=IN IP4 55.66.77.88
a=mid:d1 a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536 a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000 a=sctp-port 5000
a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-ufrag:7sFvz2gdLkEwjZEr
a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35
skipping to change at page 77, line 39 skipping to change at page 78, line 45
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=ssrc:1366781083 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:1366781084 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 1366781083 1366781084
m=video 0 UDP/TLS/RTP/SAVPF 100 101 m=video 0 UDP/TLS/RTP/SAVPF 100 101
c=IN IP4 55.66.77.88 c=IN IP4 55.66.77.88
a=bundle-only a=bundle-only
a=rtcp:64532 IN IP4 55.66.77.88 a=rtcp:64532 IN IP4 55.66.77.88
a=mid:v1 a=mid:v1
a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0
a=sendrecv a=sendrecv
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
skipping to change at page 78, line 16 skipping to change at page 79, line 19
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass a=setup:actpass
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
a=ssrc:2366781083 cname:Q/NWs1ao1HmN4Xa5
a=ssrc:2366781084 cname:Q/NWs1ao1HmN4Xa5
a=ssrc-group:FID 2366781083 2366781084
The SDP for |answer-B2| looks like: (note the use of setup:passive to The SDP for |answer-B2| looks like: (note the use of setup:passive to
maintain the existing DTLS roles, and the use of a=recvonly to maintain the existing DTLS roles, and the use of a=recvonly to
indicate that the video streams are one-way) indicate that the video streams are one-way)
v=0 v=0
o=- 4962303333179871723 2 IN IP4 0.0.0.0 o=- 4962303333179871723 2 IN IP4 0.0.0.0
s=- s=-
t=0 0 t=0 0
a=group:BUNDLE a1 d1 v1 v2 a=group:BUNDLE a1 d1 v1 v2
skipping to change at page 79, line 7 skipping to change at page 80, line 6
a=ice-ufrag:ATEn1v9DoTMB9J4r a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive a=setup:passive
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host
a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx
raddr 192.168.1.2 rport 51556 raddr 192.168.1.2 rport 51556
a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay
raddr 11.22.33.44 rport 52546 raddr 11.22.33.44 rport 52546
a=end-of-candidates a=end-of-candidates
m=application 52546 UDP/DTLS/SCTP webrtc-datachannel m=application 52546 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 11.22.33.44 c=IN IP4 11.22.33.44
a=mid:d1 a=mid:d1
skipping to change at page 80, line 6 skipping to change at page 81, line 4
c=IN IP4 11.22.33.44 c=IN IP4 11.22.33.44
a=rtcp:52546 IN IP4 11.22.33.44 a=rtcp:52546 IN IP4 11.22.33.44
a=mid:v2 a=mid:v2
a=recvonly a=recvonly
a=rtpmap:100 VP8/90000 a=rtpmap:100 VP8/90000
a=rtpmap:101 rtx/90000 a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100 a=fmtp:101 apt=100
a=fingerprint:sha-256 a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive a=setup:passive
a=rtcp-mux a=rtcp-mux
a=rtcp-rsize a=rtcp-rsize
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:100 ccm fir a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli a=rtcp-fb:100 nack pli
9. Security Considerations 8. Security Considerations
The IETF has published separate documents The IETF has published separate documents
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing [I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing
the security architecture for WebRTC as a whole. The remainder of the security architecture for WebRTC as a whole. The remainder of
this section describes security considerations for this document. this section describes security considerations for this document.
While formally the JSEP interface is an API, it is better to think of While formally the JSEP interface is an API, it is better to think of
it is an Internet protocol, with the JS being untrustworthy from the it is an Internet protocol, with the JS being untrustworthy from the
perspective of the browser. Thus, the threat model of [RFC3552] perspective of the browser. Thus, the threat model of [RFC3552]
applies. In particular, JS can call the API in any order and with applies. In particular, JS can call the API in any order and with
skipping to change at page 80, line 43 skipping to change at page 81, line 42
does not have complete control of browser behavior. One case that does not have complete control of browser behavior. One case that
bears particular mention is that editing ICE candidates out of the bears particular mention is that editing ICE candidates out of the
SDP or suppressing trickled candidates does not have the expected SDP or suppressing trickled candidates does not have the expected
behavior: implementations will still perform checks from those behavior: implementations will still perform checks from those
candidates even if they are not sent to the other side. Thus, for candidates even if they are not sent to the other side. Thus, for
instance, it is not possible to prevent the remote peer from learning instance, it is not possible to prevent the remote peer from learning
your public IP address by removing server reflexive candidates. your public IP address by removing server reflexive candidates.
Applications which wish to conceal their public IP address should Applications which wish to conceal their public IP address should
instead configure the ICE agent to use only relay candidates. instead configure the ICE agent to use only relay candidates.
10. IANA Considerations 9. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
11. Acknowledgements 10. Acknowledgements
Significant text incorporated in the draft as well and review was Significant text incorporated in the draft as well and review was
provided by Peter Thatcher, Taylor Brandstetter, Harald Alvestrand provided by Peter Thatcher, Taylor Brandstetter, Harald Alvestrand
and Suhas Nandakumar. Dan Burnett, Neil Stratford, Anant Narayanan, and Suhas Nandakumar. Dan Burnett, Neil Stratford, Anant Narayanan,
Andrew Hutton, Richard Ejzak, Adam Bergkvist and Matthew Kaufman all Andrew Hutton, Richard Ejzak, Adam Bergkvist and Matthew Kaufman all
provided valuable feedback on this proposal. provided valuable feedback on this proposal.
12. References 11. References
12.1. Normative References 11.1. Normative References
[I-D.ietf-avtext-rid] [I-D.ietf-avtext-rid]
Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream
Identifier (RID) Source Description (SDES)", draft-ietf- Identifier (RID) Source Description (SDES)", draft-ietf-
avtext-rid-00 (work in progress), February 2016. avtext-rid-00 (work in progress), February 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". Protocol".
[I-D.ietf-mmusic-4572-update] [I-D.ietf-mmusic-4572-update]
Holmberg, C., "Updates to RFC 4572", draft-ietf-mmusic- Holmberg, C., "Updates to RFC 4572", draft-ietf-mmusic-
4572-update-05 (work in progress), June 2016. 4572-update-05 (work in progress), June 2016.
[I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer
Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-14 (work
in progress), July 2016.
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "Cross Session Stream Identification in Alvestrand, H., "Cross Session Stream Identification in
the Session Description Protocol", draft-ietf-mmusic- the Session Description Protocol", draft-ietf-mmusic-
msid-01 (work in progress), August 2013. msid-01 (work in progress), August 2013.
[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-08 (work in progress), June 2016. exclusive-08 (work in progress), June 2016.
skipping to change at page 84, line 30 skipping to change at page 85, line 30
Attributes in the Session Description Protocol (SDP)", Attributes in the Session Description Protocol (SDP)",
RFC 6236, May 2011. RFC 6236, May 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, April Real-time Transport Protocol (SRTP)", RFC 6904, April
2013. 2013.
12.2. Informative References 11.2. Informative References
[I-D.ietf-rtcweb-ip-handling] [I-D.ietf-rtcweb-ip-handling]
Uberti, J. and G. Shieh, "WebRTC IP Address Handling Uberti, J. and G. Shieh, "WebRTC IP Address Handling
Recommendations", draft-ietf-rtcweb-ip-handling-01 (work Recommendations", draft-ietf-rtcweb-ip-handling-01 (work
in progress), March 2016. in progress), March 2016.
[I-D.nandakumar-rtcweb-sdp] [I-D.nandakumar-rtcweb-sdp]
Nandakumar, S. and C. Jennings, "SDP for the WebRTC", Nandakumar, S. and C. Jennings, "SDP for the WebRTC",
draft-nandakumar-rtcweb-sdp-02 (work in progress), July draft-nandakumar-rtcweb-sdp-02 (work in progress), July
2013. 2013.
skipping to change at page 85, line 13 skipping to change at page 86, line 13
RFC 3960, December 2004. RFC 3960, December 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
DOI 10.17487/RFC4733, December 2006,
<http://www.rfc-editor.org/info/rfc4733>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
the Session Description Protocol", RFC 5956, September
2010.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464, Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011, DOI 10.17487/RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>. <http://www.rfc-editor.org/info/rfc6464>.
[W3C.WD-webrtc-20140617] [W3C.WD-webrtc-20140617]
Bergkvist, A., Burnett, D., Narayanan, A., and C. Bergkvist, A., Burnett, D., Narayanan, A., and C.
Jennings, "WebRTC 1.0: Real-time Communication Between Jennings, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc- Browsers", World Wide Web Consortium WD WD-webrtc-
20140617, June 2014, 20140617, June 2014,
<http://www.w3.org/TR/2011/WD-webrtc-20140617>. <http://www.w3.org/TR/2011/WD-webrtc-20140617>.
Appendix A. Change log Appendix A. Appendix A
For the syntax validation performed in Section 5.7, the following
list of ABNF definitions is used:
+-----------------------+-------------------------------------------+
| Attribute | Reference |
+-----------------------+-------------------------------------------+
| ptime | [RFC4566] Section 9 |
| maxptime | [RFC4566] Section 9 |
| rtpmap | [RFC4566] Section 9 |
| recvonly | [RFC4566] Section 9 |
| sendrecv | [RFC4566] Section 9 |
| sendonly | [RFC4566] Section 9 |
| inactive | [RFC4566] Section 9 |
| framerate | [RFC4566] Section 9 |
| fmtp | [RFC4566] Section 9 |
| quality | [RFC4566] Section 9 |
| rtcp | [RFC3605] Section 2.1 |
| setup | [RFC4145] Sections 3, 4, and 5 |
| connection | [RFC4145] Sections 3, 4, and 5 |
| fingerprint | [RFC4572] Section 5 |
| rtcp-fb | [RFC4585] Section 4.2 |
| candidate | [RFC5245] Section 15.1 |
| remote-candidates | [RFC5245] Section 15.2 |
| ice-lite | [RFC5245] Section 15.3 |
| ice-ufrag | [RFC5245] Section 15.4 |
| ice-pwd | [RFC5245] Section 15.4 |
| ice-options | [RFC5245] Section 15.5 |
| extmap | [RFC5285] Section 7 |
| mid | [RFC5888] Section 4 and 5 |
| group | [RFC5888] Section 4 and 5 |
| imageattr | [RFC6236] Section 3.1 |
| extmap (encrypt | [RFC6904] Section 4 |
| option) | |
| msid | [I-D.ietf-mmusic-msid] Section 2 |
| rid | [I-D.ietf-mmusic-rid] Section 10 |
| simulcast | [I-D.ietf-mmusic-sdp-simulcast]Section |
| | 6.1 |
| dtls-id | [I-D.ietf-mmusic-dtls-sdp]Section 4 |
+-----------------------+-------------------------------------------+
Table 1: SDP ABNF References
Appendix B. Change log
Note: This section will be removed by RFC Editor before publication. Note: This section will be removed by RFC Editor before publication.
Changes in draft-17:
o Split createOffer and createAnswer sections to clearly indicate
attributes which always appear and which only appear when not
bundled into another m= section.
o Add descriptions of RtpTransceiver methods.
o Describe how to process RTCP feedback attributes.
o Clarify transceiver directions and their interaction with 3264.
o Describe setCodecPreferences.
o Update RTP demux algorithm. Include RTCP.
o Update requirements for when a=rtcp is included, limiting to cases
where it is needed for backward compatibility.
o Clarify SAR handling.
o Updated addTrack matching algorithm.
o Remove a=ssrc requirements.
o Handle a=setup in reoffers.
o Discuss how RTX/FEC should be handled.
o Discuss how telephone-event should be handled.
o Discuss how CN/DTX should be handled.
o Add missing references to ABNF table.
Changes in draft-16: Changes in draft-16:
o Update addIceCandidate to indicate ICE generation and allow per-m= o Update addIceCandidate to indicate ICE generation and allow per-m=
section end-of-candidates. section end-of-candidates.
o Update fingerprint handling to use draft-ietf-mmusic-4572-update. o Update fingerprint handling to use draft-ietf-mmusic-4572-update.
o Update text around SDP processing of RTP header extensions and o Update text around SDP processing of RTP header extensions and
payload formats. payload formats.
 End of changes. 115 change blocks. 
370 lines changed or deleted 554 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/