--- 1/draft-ietf-rtcweb-jsep-16.txt 2016-10-21 11:16:02.285236826 -0700 +++ 2/draft-ietf-rtcweb-jsep-17.txt 2016-10-21 11:16:02.461241174 -0700 @@ -1,21 +1,21 @@ Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track C. Jennings -Expires: March 24, 2017 Cisco +Expires: April 24, 2017 Cisco E. Rescorla, Ed. Mozilla - September 20, 2016 + October 21, 2016 Javascript Session Establishment Protocol - draft-ietf-rtcweb-jsep-16 + draft-ietf-rtcweb-jsep-17 Abstract This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. Status of This Memo @@ -25,40 +25,40 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6 3.2. Session Descriptions and State Machine . . . . . . . . . 7 3.3. Session Description Format . . . . . . . . . . . . . . . 10 3.4. Session Description Control . . . . . . . . . . . . . . . 10 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 10 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 11 @@ -70,78 +70,83 @@ 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 13 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 14 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 14 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 15 3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 16 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 17 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 18 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 18 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 19 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 20 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 20 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 22 4.1.3. addTransceiver . . . . . . . . . . . . . . . . . . . 22 - 4.1.4. createDataChannel . . . . . . . . . . . . . . . . . . 22 + 4.1.4. createDataChannel . . . . . . . . . . . . . . . . . . 23 4.1.5. createOffer . . . . . . . . . . . . . . . . . . . . . 23 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.2. Rollback . . . . . . . . . . . . . . . . . . . . 26 4.1.8. setLocalDescription . . . . . . . . . . . . . . . . . 27 4.1.9. setRemoteDescription . . . . . . . . . . . . . . . . 28 4.1.10. currentLocalDescription . . . . . . . . . . . . . . . 28 4.1.11. pendingLocalDescription . . . . . . . . . . . . . . . 28 4.1.12. currentRemoteDescription . . . . . . . . . . . . . . 28 4.1.13. pendingRemoteDescription . . . . . . . . . . . . . . 29 4.1.14. canTrickleIceCandidates . . . . . . . . . . . . . . . 29 - 4.1.15. setConfiguration . . . . . . . . . . . . . . . . . . 29 + 4.1.15. setConfiguration . . . . . . . . . . . . . . . . . . 30 4.1.16. addIceCandidate . . . . . . . . . . . . . . . . . . . 30 - 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 31 - 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 31 - 5.1.1. Implementation Requirements . . . . . . . . . . . . . 31 - 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 33 - 5.1.3. Profile Names and Interoperability . . . . . . . . . 33 - 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 34 - 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 34 - 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 40 - 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 43 - 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 43 - 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 44 - 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 44 - 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 44 - 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 49 - 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 50 - 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 50 - 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 50 - 5.5. Processing a Local Description . . . . . . . . . . . . . 51 - 5.6. Processing a Remote Description . . . . . . . . . . . . . 51 - 5.7. Parsing a Session Description . . . . . . . . . . . . . . 52 - 5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 53 + 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 31 + 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 31 + 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 31 + 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 31 + 4.2.4. setCodecPreferences . . . . . . . . . . . . . . . . . 32 + 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 32 + 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 32 + 5.1.1. Implementation Requirements . . . . . . . . . . . . . 33 + 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 34 + 5.1.3. Profile Names and Interoperability . . . . . . . . . 34 + 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 35 + 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 35 + 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 41 + 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 44 + 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 44 + 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 45 + 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 45 + 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 45 + 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 50 + 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 51 + 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.3. Semantics Verification . . . . . . . . . . . . . . . 57 - 5.8. Applying a Local Description . . . . . . . . . . . . . . 58 + 5.7.3. Semantics Verification . . . . . . . . . . . . . . . 58 + 5.8. Applying a Local Description . . . . . . . . . . . . . . 59 5.9. Applying a Remote Description . . . . . . . . . . . . . . 60 - 5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 63 - 6. Demux placeholder . . . . . . . . . . . . . . . . . . . . . . 64 - 7. Processing RTP packets . . . . . . . . . . . . . . . . . . . 64 - 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 66 - 8.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 66 - 8.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 70 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 81 - 12.2. Informative References . . . . . . . . . . . . . . . . . 84 - Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 85 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 + 5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 64 + 6. Processing RTP/RTCP packets . . . . . . . . . . . . . . . . . 66 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 68 + 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 68 + 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 72 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 81 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 82 + 11.2. Informative References . . . . . . . . . . . . . . . . . 85 + Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 86 + Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 87 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94 1. Introduction This document describes how the W3C WEBRTC RTCPeerConnection interface [W3C.WD-webrtc-20140617] is used to control the setup, management and teardown of a multimedia session. 1.1. General Design of JSEP The thinking behind WebRTC call setup has been to fully specify and @@ -469,30 +474,25 @@ m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds new m= sections. 3.4.2. RtpSenders 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 RtpReceivers allows the application to control how RTP media is - received. In particular, the application can control whether an - RtpReceiver is active or not, which affects the directionality - attribute of the associated m= section. + received. 3.5. ICE 3.5.1. ICE Gathering Overview JSEP gathers ICE candidates as needed by the application. Collection 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 local session description, or new ICE credentials in the description, indicating an ICE restart. Use of new ICE credentials can be @@ -644,20 +644,27 @@ 3.6. Video Size Negotiation Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute [RFC6236] to indicate what video 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 constrain what it receives due to application preferences, e.g. a 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 In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any mandatory constraints that have been applied to the associated MediaStreamTrack. If the decoder limits are unknown, e.g. when using a software decoder, the mandatory constraints are used directly. For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing createAnswer call. @@ -710,22 +717,23 @@ of a given MediaStreamTrack, which is producing video of a certain resolution, receives an "a=imageattr recv" attribute, it MUST check to see if the original resolution meets the size criteria specified in the attribute, and adapt the resolution accordingly by scaling (if appropriate). Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. - For an "a=imageattr recv" attribute, only size limits are considered. - Any other values, e.g. aspect ratio, MUST be ignored. + For the purposes of resolution negotiation, only size limits are + considered. Any other values, e.g. picture or sample aspect ratio, + MUST be ignored. When communicating with a non-JSEP endpoint, multiple relevant "a=imageattr recv" attributes may be received. If this occurs, attributes other than the one with the highest "q=" value MUST be ignored. If an "a=imageattr recv" attribute references a different video codec than what has been selected for the MediaStreamTrack, it MUST be ignored. @@ -743,20 +751,25 @@ upscaling policy for each sent track. For this case, if upscaling is permitted by policy, the sender SHOULD apply upscaling in order to provide the desired resolution. Otherwise, the sender MUST NOT apply upscaling. The sender SHOULD NOT upscale in other cases, even if the policy permits it. Upscaling MUST NOT change the track aspect ratio. If there is no appropriate and permitted scaling mechanism that allows the received size limits to be satisfied, the sender MUST NOT 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 described above, the sender MUST NOT transmit the track. 3.7. Simulcast JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding. This allows for multi-user scenarios where each sending @@ -890,21 +902,21 @@ application wants to only keep a single session, it can simply terminate the sessions that it no longer needs. 4. Interface This section details the basic operations that must be present to implement JSEP functionality. The actual API exposed in the W3C API may have somewhat different syntax, but should map easily to these concepts. -4.1. Methods +4.1. PeerConnection 4.1.1. Constructor The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates, as well as the initial ICE candidate policy and pool size, and also the bundle policy to use. If an ICE candidate policy is specified, it functions as described in @@ -992,24 +1004,25 @@ The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to set the multiplexing policy to "negotiate". 4.1.2. addTrack The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other 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 - minimize the number of transceivers as follows: The track will be - attached to the first compatible transceiver (of the same media type) - which has never had a direction of "sendonly" or "sendrecv". If no - such transceiver exists, then one will be constructed as described in + minimize the number of transceivers as follows: If the PeerConnection + is in the "have-remote-offer" state, the track will be attached to + the first compatible transceiver that was created by the most recent + call to setRemoteDescription() and does not have a local track. + Otherwise, a new transceiver will be created, as described in Section 4.1.3. 4.1.3. addTransceiver The addTransceiver method adds a new RTPTransceiver to the PeerConnection. If a MediaStreamTrack argument is provided, then the transceiver will be configured with that media type and the track will be attached to the transceiver. Otherwise, the application MUST explicitly specify the type; this mode is useful for creating recvonly transceivers as well as for creating transceivers to which a @@ -1410,20 +1423,76 @@ 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 recently applied remote description. If neither the MID nor the m= index is present, then the indication MUST be assumed to apply to all m= sections in the most recently applied remote description. 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 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 This section describes the specific procedures to be followed when creating and parsing SDP objects. 5.1. Requirements Overview JSEP implementations must comply with the specifications listed below that govern the creation and processing of offers and answers. @@ -1542,21 +1612,21 @@ o Any profile matching the following patterns MUST be accepted: "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 effect; support for DTLS-SRTP is determined by the presence of one or more "a=fingerprint" attribute. Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. 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 - 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 compatible mode and use AVP timing, i.e., "trr-int=4". o For data m= sections, JSEP endpoints MUST support receiving the "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile strings even if the initial offer/answer exchange used an (incorrect) older profile string. @@ -1641,45 +1711,55 @@ this m= section, but given that no candidates 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. o To properly indicate use of DTLS, the field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as specified in [I-D.nandakumar-mmusic-proto-iana-registration] if 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 in [RFC4566], Section 5.7. Again, as no candidates have yet been 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. - 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 generating mid values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [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 transceiver. - o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as - specified in [RFC4566], Section 6. The audio and video codecs - that MUST be supported are specified in - [I-D.ietf-rtcweb-audio](see Section 3) and - [I-D.ietf-rtcweb-video](see Section 5). + o For each media format on the m= line, "a=rtpmap" and "a=fmtp" + lines, as specified in [RFC4566], Section 6, and [RFC3264], + Section 5.1. o If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the maximum supported frame sizes out of all codecs included above, as specified in [RFC4566], Section 6. o If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in Section 3.6. @@ -1688,129 +1768,104 @@ of the primary codec and an "a=fmtp" line that references the payload type of the primary codec, as specified in [RFC4588], Section 8.1. o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6. The FEC mechanisms that MUST be supported are specified in [I-D.ietf-rtcweb-fec], Section 6, and specific usage for each media type is outlined in 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 specified in [RFC5285], Section 5. The list of header extensions that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions that require encryption MUST be specified as indicated in [RFC6904], Section 4. o For each supported RTCP feedback mechanism, an "a=rtcp-fb" mechanism, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/MUST be supported is 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- 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 for this media type, an "a=bundle-only" line. - o If the RtpSender of the RtpTransceiver associated with this - m=section is active: + o If the RtpTransceiver has a sendrecv or sendonly direction: * An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2. - * 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]. - - * 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 + o If the RtpTransceiver has a sendrecv or sendonly direction, 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 application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the implementation. When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-avtext-rid], Section 11. If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. - o If the RtpTransceiver's RtpSender is active and more than one - "a=rid" line has been generated, an "a=simulcast" line, with - direction "send", as defined in [I-D.ietf-mmusic-sdp-simulcast], - Section 6.2. The list of RIDs MUST include all of the RID - identifiers used in the "a=rid" lines for this m= section. + o If the RtpTransceiver has a sendrecv or sendonly direction and + more than one "a=rid" line has been generated, an "a=simulcast" + line, with direction "send", as defined in + [I-D.ietf-mmusic-sdp-simulcast], Section 6.2. The list of RIDs + 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 generated for data. The field MUST be set to "application" and the field MUST be set to "UDP/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" value MUST be set to "webrtc-datachannel" as specified in [I-D.ietf-mmusic-sctp-sdp], Section 4.1. 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 - above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp- - port" line referencing the SCTP port number as defined in + "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included as + mentioned above, along with an "a=fmtp:webrtc-datachannel" line and + an "a=sctp-port" line referencing the SCTP port number as defined in [I-D.ietf-mmusic-sctp-sdp], Section 4.1. Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in [RFC5888]. This attribute MUST have semantics "bundle", and MUST include the mid identifiers of each m= section. The effect of this is that the browser offers all m= sections as one bundle group. However, whether the m= sections are bundle-only or not depends on the bundle policy. The next step is to generate session-level lip sync groups as defined @@ -1823,22 +1878,22 @@ media level SHOULD generally be at the media level even if they are identical. This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], and MUST NOT be included: o "a=crypto" - o "a=key-mgmt" + o "a=key-mgmt" o "a=ice-lite" Note that when bundle is used, any additional attributes that are added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes] on how those attributes interact with bundle. Note that these requirements are in some cases stricter than those of SDP. Implementations MUST be prepared to accept compliant SDP even if it would not conform to the requirements for generating SDP in this specification. @@ -1891,74 +1946,69 @@ o If an RtpTransceiver is stopped and is not associated with an m= section, an m= section MUST NOT be generated for it. This prevents adding back RtpTransceivers whose m= sections were recycled and used for a new RtpTransceiver in a previous offer/ answer exchange, as described above. o If an RtpTransceiver has been stopped and is associated with an m= 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 - 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", - and "a=ssrc-group" lines MUST stay the same if they are present in - the current description. + o For RtpTransceivers that are not stopped, the "a=msid" line MUST + stay the same if they are present in the current description. 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 described in [RFC5245], Section 4.3. If ICE checking has already 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 yet completed. Note that this differs from the guidance in [RFC5245], Section 9.1.2.2, which only refers to offers created - when ICE has completed. 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 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. + when ICE has completed. In each case, if no RTP candidates have + yet been gathered, dummy values MUST be used, as described above. o Each "a=mid" line MUST stay the same. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option ( Section 5.2.3.1 was specified. If the m= section is bundled into another m= section, it still MUST NOT 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 candidate that has been gathered during the most recent gathering phase (see Section 3.5.1), an "a=candidate" line MUST be added, as defined in [RFC5245], Section 4.3., paragraph 3. If candidate gathering for the section has completed, an "a=end-of-candidates" 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, both "a=candidate" and "a=end-of-candidates" MUST be omitted. - o For RtpTransceivers that are still present, the "a=msid", - "a=ssrc", and "a=ssrc-group" lines MUST stay the same. + o For RtpTransceivers that are still present, the "a=msid" line MUST + stay the same. o For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. o For RtpTransceivers that are still present, any "a=simulcast" line MUST stay the same. 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 - removed. + zero and the "a=msid" line MUST be removed. o If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating a m= section for the added RtpTransceiver as if the m= section were being added to session description, except that instead of adding it, the generated m= section replaces the m= section with a zero port. If the initial offer was applied using setLocalDescription, and an @@ -1966,28 +2016,36 @@ setRemoteDescription, meaning the PeerConnection is in the "remote- pranswer" or "stable" states, an offer is generated based on the negotiated session descriptions by following the steps mentioned for the "local-offer" state above. In addition, for each non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current remote description: 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 in the most recent answer. o The RTCP feedback extensions MUST only include those that are 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 recent answer. o The "a=rtcp-mux-only" line MUST only be added if present in the most recent answer. o The "a=rtcp-rsize" line MUST only be added if present in the most recent answer. The "a=group:BUNDLE" attribute MUST include the mid identifiers @@ -2127,46 +2185,55 @@ following rules must be followed: 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 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. o The field MUST be set to exactly match the field 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 in [RFC4566], Section 5.7. Again, as no candidates have yet been 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. If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being 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 in [RFC5888], Section 9.1. The "mid" value MUST match that specified in the offer. - 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 - transceiver. + o A direction attribute, determined by applying the rules regarding + the offered direction specified in [RFC3264], Section 6.1, and + then intersecting with the direction of the associated + RtpTransceiver. For example, in the case where an m= section is + offered as "sendonly", and the local transceiver is set to + "sendrecv", the result in the answer is a "recvonly" direction. - o For each supported codec that is present in the offer, "a=rtpmap" - and "a=fmtp" lines, as specified in [RFC4566], Section 6, and - [RFC3264], Section 6.1. The audio and video codecs that MUST be - supported are specified in [I-D.ietf-rtcweb-audio](see Section 3) - and [I-D.ietf-rtcweb-video](see Section 5). + o For each media format on the m= line, "a=rtpmap" and "a=fmtp" + lines, as specified in [RFC4566], Section 6, and [RFC3264], + Section 6.1. o If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the maximum supported frame sizes out of all codecs included above, as specified in [RFC4566], Section 6. o If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in Section 3.6. @@ -2175,91 +2242,79 @@ indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the payload type of the primary codec, as specified in [RFC4588], Section 8.1. o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6. The FEC mechanisms that MUST be supported are specified in [I-D.ietf-rtcweb-fec], Section 6, and specific usage for each media type is outlined in 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 offer, an "a=extmap" line, as specified in [RFC5285], Section 5. The list of header extensions that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions that require encryption MUST be specified as indicated in [RFC6904], Section 4. o For each supported RTCP feedback mechanism that is present in the offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. - o If the RtpSender of the RtpTransceiver associated with this - m=section is active: + o If the RtpTransceiver has a sendrecv or sendonly direction: * An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2. - * 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]. + Each m= section which is not bundled into another m= section, MUST + contain the following attributes (which are of category IDENTICAL or + TRANSPORT): - * If RTX has been negotiated for this m= section, 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 "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245], + Section 15.4. - * If FEC has been negotiated for this m= section, 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 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 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 be generated for data. The field MUST be set to "application" and the and "fmt" fields MUST be set to exactly match the fields in the offer. 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 - as mentioned above, along with an "a=fmtp:webrtc-datachannel" line - and an "a=sctp-port" line referencing the SCTP port number as defined - in [I-D.ietf-mmusic-sctp-sdp], Section 4.1. + "a=candidate", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST + be included under the conditions described above, along with an + "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line + 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, corresponding session-level "a=group" attributes MUST be added as specified in [RFC5888]. These attributes MUST have semantics "BUNDLE", and MUST include the all mid identifiers from the offered 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 answer should have an "a=bundle-only" line. Attributes that are common between all m= sections MAY be moved to @@ -2288,46 +2343,49 @@ setLocalDescription, an answer is generated by following the steps in the "have-remote-offer" state above, along with these exceptions: 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 of the default candidate for the m= section, as described in [RFC5245], Section 4.3. Note, however, that the m= line protocol need not match the default candidate, because this protocol value 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. + 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 the m= section is restarting, in which case new ICE credentials 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 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 candidate that has been gathered during the most recent gathering phase (see Section 3.5.1), an "a=candidate" line MUST be added, as defined in [RFC5245], Section 4.3., paragraph 3. If candidate gathering for the section has completed, an "a=end-of-candidates" 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, both "a=candidate" and "a=end-of-candidates" MUST be omitted. - o For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", - and "a=ssrc-group" lines MUST stay the same. + o For RtpTransceivers that are not stopped, the "a=msid" line MUST + stay the same. 5.3.3. Options Handling The createAnswer method takes as a parameter an RTCAnswerOptions object. The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the IceRestart option is unnecessary, as ICE credentials will automatically be changed for all m= lines where the offerer chose to perform ICE restart. The following options are supported in RTCAnswerOptions. @@ -2427,99 +2485,65 @@ it is invalid. The exact details of this process are explained below. The SDP contained in the session description object consists of a sequence of text lines, each containing a key-value expression, as described in [RFC4566], Section 5. The SDP is read, line-by-line, and converted to a data structure that contains the deserialized information. However, SDP allows many types of lines, not all of which are relevant to JSEP applications. For each line, the implementation will first ensure it is syntactically correct - according its defining ABNF, check that it conforms to [RFC4566] and - [RFC3264] semantics, and then either parse and store or discard the - provided value, as described below. A partial list of ABNF - 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.] + according to its defining ABNF, check that it conforms to [RFC4566] + and [RFC3264] semantics, and then either parse and store or discard + the provided value, as described below. - If the line is not well-formed, or cannot be parsed as described, the - parser MUST stop with an error and reject the session description. - This ensures that implementations do not accidentally misinterpret - ambiguous SDP. + 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, + even if the value is to be discarded. This ensures that + implementations do not accidentally misinterpret ambiguous SDP. 5.7.1. Session-Level Parsing First, the session-level lines are checked and parsed. These lines MUST occur in a specific order, and with a specific syntax, as 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 same type (typically "a=") can occur in any order, and their ordering is not meaningful. - For non-attribute (non-"a=") lines, their sequencing, syntax, and - semantics, are checked, as mentioned above. The following lines are - not meaningful in the JSEP context and MAY be discarded once they - have been checked. + The following non-attribute lines are 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 used. This supersedes the guidance in [RFC5245], Section 6.1, to use "ice-mismatch" to indicate mismatches between "c=" and the candidate lines; because JSEP always uses ICE, "ice-mismatch" is not useful in this context. The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are not used by this specification; they MUST be checked for syntax 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], Section 5.1. The "o=" line MUST be parsed as specified in [RFC4566], Section 5.2. The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored. - Specific processing MUST be applied for the following session-level - attribute ("a=") lines: + Finally, the attribute lines are processed. Specific processing MUST + be applied for the following session-level attribute ("a=") lines: o Any "a=group" lines are parsed as specified in [RFC5888], 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 [RFC5245], Section 15.3, and a value indicating the presence of ice-lite is stored. o If present, a single "a=ice-ufrag" line is parsed as specified in [RFC5245], Section 15.4, and the ufrag value is stored. @@ -2531,20 +2555,24 @@ in [RFC5245], Section 15.5, and the set of specified options is stored. o Any "a=fingerprint" lines are parsed as specified in [RFC4572], Section 5, and the set of fingerprint and algorithm values is stored. o If present, a single "a=setup" line is parsed as specified in [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], Section 5, and their values are stored. Once all the session-level lines have been parsed, processing continues with the lines in media sections. 5.7.2. Media Section Parsing Like the session-level lines, the media session lines MUST occur in the specific order and with the specific syntax defined in [RFC4566], @@ -2570,27 +2598,34 @@ o If present, a single "a=ice-ufrag" line is parsed as specified in [RFC5245], Section 15.4, and the ufrag value is stored. o If present, a single "a=ice-pwd" line is parsed as specified in [RFC5245], Section 15.4, and the password value is stored. 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 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], Section 5, and the set of fingerprint and algorithm values is 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 Section 5.1.3 section above, the following attribute lines MUST be processed: o The "m=" fmt value MUST be parsed as specified in [RFC4566], Section 5.14, and the individual values stored. o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in [RFC4566], Section 6, and their values stored. @@ -2626,30 +2661,20 @@ flagged and stored. o If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored, as this information is superfluous when using ICE. 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 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 [RFC6236], Section 3, and their values stored. o Any "a=rid" lines MUST be parsed as specified in [I-D.ietf-mmusic-rid], Section 10, and their values stored. o If present, a single "a=simulcast" line MUST be parsed as specified in [I-D.ietf-mmusic-sdp-simulcast], and its values stored. @@ -2676,24 +2701,32 @@ are performed: 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 values MAY either be present at the media level, or inherited from the session level. * ICE ufrag and password values, which MUST comply with the size 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 - specified in [RFC5763], Section 5, and MUST be consistent with - the selected role of the current DTLS connection, if one - exists.[TODO: may need revision, i.e., use of actpass + specified in [RFC5763], Section 5 and MUST be consistent with + the selected role of the current DTLS connection, if one exists + and is being continued. * DTLS fingerprint values, where at least one fingerprint MUST be present. o All RID values referenced in an "a=simulcast" line MUST exist as "a=rid" lines. o Each m= section is also checked to ensure prohibited features are not used. If this is a local description, the "ice-lite" attribute MUST NOT be specified. @@ -2844,21 +2877,21 @@ following steps: + If the m= section is sendrecv or recvonly, and there are RtpTransceivers of the same type that were added to the PeerConnection by addTrack and are not associated with any m= section and are not stopped, find the first (according to the canonical order described in Section 5.2.1) such RtpTransceiver. + 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= section by setting the value of the RtpTransceiver's mid attribute to the MID of the m= section. If the m= section does not include a MID (i.e., the remote side does not support the MID extension), generate a value for the RtpTransceiver mid attribute, following the guidance for "a=mid" mentioned in Section 5.2.1. * For each specified media format that is also supported by the @@ -2908,24 +2941,36 @@ 5% to RTCP. If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". * For any "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2. * Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined. - * [TODO: handling of CN, telephone-event, "red"] - * 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 media formats to use the specified packet size. If the specified size is not supported for a media format, use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the Section 5.10 section below. 5.10. Applying an Answer @@ -2933,154 +2978,223 @@ remote description, the following steps are performed when processing a description of type "pranswer" or "answer". 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 in the answer), stop any reception or transmission of media for this section, and discard any associated ICE components, as described in Section 9.2.1.3 of [RFC5245]. - o If the remote DTLS fingerprint has been changed, tear down the - existing DTLS connection. + o If the remote DTLS fingerprint has been changed or the dtls-id has + 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 connection, using the specified roles and fingerprints, on any underlying ICE components, once they are active. o If the media section proto value indicates use of RTP: * If the media section references any media formats, RTP header extensions, or RTCP feedback mechanisms that were not present in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error. * If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in [RFC5761], Section 5.1.3. - Otherwise, transmit RTCP over the RTCP component; if no RTCP - component exists, because RTCP mux was previously enabled, this - MUST result in an error. + Otherwise, prepare to transmit RTCP over the RTCP component; if + no RTCP component exists, because RTCP mux was previously + enabled, this MUST result in an error. * If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced- size RTCP, as specified in [RFC5506]. - * [TODO: enable appropriate rtcp-fb mechanisms] * If the directional attribute in the answer is of type - "sendrecv" or "sendonly", prepare to start transmitting media - using the most preferred media format from the remote - description that is also present in the answer, as described in - [RFC3264], Sections 6.1 and 7, once the underlying transport - layers have been established. [TODO: add discusssion of - RED/FEC/RTX/CN] The payload type mapping from the remote - description is used to determine payload types for the outgoing - RTP streams. Any RTP header extensions that were negotiated - should be included in the outgoing RTP streams, using the - extension mapping from the remote description; if the RID - header extension has been 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 is negotiated, send the number of Source RTP Streams - as specified in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2.2. + "sendrecv" or "sendonly", choose the media format to send as + the most preferred media format from the remote description + that is also present in the answer, as described in [RFC3264], + Sections 6.1 and 7, and start transmitting RTP media once the + underlying transport layers have been established. If a SSRC + has not already been chosen for this outgoing RTP stream, + choose a random one. + + * The payload type mapping from the remote description is used to + determine payload types for the outgoing RTP streams, including + the payload type for the send media format chosen above. Any + RTP header extensions that were negotiated should be included + in the outgoing RTP streams, using the extension mapping from + the remote description; if the RID header extension has been + 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 - "inactive", stop transmitting RTP media, although RTCP should - still be sent, as described in [RFC3264], Section 5.1. + "inactive", stop transmitting all RTP media, but continue + sending RTCP, as described in [RFC3264], Section 5.1. o If the media section proto value indicates use of SCTP: * If no SCTP association yet exists, prepare to initiate a SCTP association over the associated ICE component and DTLS connection, using the local SCTP port value from the local description, and the remote SCTP port value from the remote description, as described in [I-D.ietf-mmusic-sctp-sdp], Section 10.2. If the answer contains valid bundle groups, discard any ICE components for the m= sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these m= sections accordingly, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. -6. Demux placeholder - - RTP demux algo goes here - -7. Processing RTP packets +6. Processing RTP/RTCP packets Note: The following algorithm does not yet have WG consensus but is included here as something concrete for the working group to discuss. When an RTP packet is received by a transport and passes SRTP authentication, that packet needs to be routed to the correct RtpReceiver. For each transport, the following steps MUST be followed to prepare to route packets: Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport. - Construct a table mapping SSRC to RtpReceiver for each RtpReceiver - configured to receive from this transport and for each SSRC that - RtpReceiver is configured to receive. Some of the SSRCs may be - presesnt in the m= section corresponding to that RtpReceiver in - the remote description. + Construct a table mapping incoming SSRC to RtpReceiver for each + RtpReceiver configured to receive from this transport and for each + SSRC that RtpReceiver is configured to receive. Some of the SSRCs + may be present in the m= section corresponding to that RtpReceiver + 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 RtpReceiver configured to receive from this transport and for each payload type that RtpReceiver is configured to receive. The payload types of a given RtpReceiver are found in the m= section corresponding to that RtpReceiver in the local description. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local 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 route the packet: If the packet has a MID and that MID is not in the table mapping MID to RtpReceiver, drop the packet and stop. 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 - mapping the packet's SSRC to the RtpReceiver. + to RtpReceiver, update the incoming SSRC mapping table to include + 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 - packet to the mapped RtpReceiver and stop. + If the packet's SSRC is in the incoming SSRC mapping table, + deliver the packet to the associated RtpReceiver and stop. If the packet's payload type is in the payload type table, update - the the SSRC mapping table to include an entry mapping the - packet's SSRC to the RtpReceiver. Deliver the packet to the - RtpReceiver and stop. + the the incoming SSRC mapping table to include an entry that maps + the packet's SSRC to the RtpReceiver for that payload type. In + addition, deliver the packet to the associated RtpReceiver and + stop. 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 the RTP packets is done at the RtpReceiver level. This includes - using [I-D.ietf-mmusic-rid] to determine which RTP streams depend on - or repair other RTP streams. - - As RtpTransceivers (and, thus, RtpReceivers) are added, removed, - stopped, or reconfigured, the tables above must also be updated. + using [I-D.ietf-mmusic-rid] to distinguish between multiple Encoded + Streams, as well as determine which Source RTP stream should be + repaired by a given Redundancy RTP stream. If the RTP packet's PT + does not match any codec in use by the RtpReceiver, the packet will + be dropped. -8. Examples +7. Examples Note that this example section shows several SDP fragments. To 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 continuation of the previous line. In addition, some blank lines have been added to improve readability but are not valid in SDP. More examples of SDP for WebRTC call flows can be found in [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 / video call between two browsers and does not use trickle ICE. The example in the following section provides a more realistic example of what would happen in a normal browser to browser connection. 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 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 @@ -3154,21 +3268,20 @@ a=ice-ufrag:ETEn1v9DoTMB9J4r a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl 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 a=setup:actpass a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 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 typ host a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501 typ host a=end-of-candidates m=video 56502 UDP/TLS/RTP/SAVPF 100 101 c=IN IP4 192.0.2.1 a=rtcp:56503 IN IP4 192.0.2.1 a=mid:v1 @@ -3175,32 +3288,29 @@ a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 rtx/90000 a=fmtp:101 apt=100 a=ice-ufrag:BGKkWnG5GmiUpdIV a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf 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 + a=setup:actpass a=rtcp-mux a=rtcp-rsize a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack 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 typ host a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503 typ host a=end-of-candidates The SDP for |answer-A1| looks like: v=0 o=- 6729291447651054566 1 IN IP4 0.0.0.0 @@ -3221,21 +3331,20 @@ a=rtpmap:98 telephone-event/48000 a=maxptime:120 a=ice-ufrag:6sFvz2gdLkEwjZEr a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 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 a=setup:active a=rtcp-mux a=rtcp-rsize 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 typ host a=end-of-candidates m=video 20000 UDP/TLS/RTP/SAVPF 100 101 c=IN IP4 192.0.2.2 a=rtcp 20001 IN IP4 192.0.2.2 a=mid:v1 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0 @@ -3244,25 +3353,22 @@ a=rtpmap:101 rtx/90000 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 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:active a=rtcp-mux a=rtcp-rsize a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack 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 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 RTCP mux policy of require, and a single TURN server. Later, two video flows, one for the presenter and one for screen sharing, are 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 JS are assumed to flow over some signaling protocol via a web server. @@ -3375,21 +3481,20 @@ a=ice-ufrag:ATEn1v9DoTMB9J4r a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 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 a=setup:actpass a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid - a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 m=application 0 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=bundle-only a=mid:d1 a=fmtp:webrtc-datachannel max-message-size=65536 a=sctp-port 5000 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 a=setup:actpass @@ -3425,21 +3531,20 @@ a=maxptime:120 a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 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 a=setup:active a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid - a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5 m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=fmtp:webrtc-datachannel max-message-size=65536 a=sctp-port 5000 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 a=setup:active @@ -3477,26 +3582,26 @@ a=maxptime:120 a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 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 a=setup:actpass a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 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:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx raddr 192.168.2.3 rport 61665 a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay raddr 55.66.77.88 rport 64532 + a=end-of-candidates m=application 64532 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 55.66.77.88 a=mid:d1 a=fmtp:webrtc-datachannel max-message-size=65536 a=sctp-port 5000 a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 @@ -3523,31 +3628,29 @@ 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 a=setup:actpass a=rtcp-mux a=rtcp-rsize a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack 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 c=IN IP4 55.66.77.88 a=bundle-only a=rtcp:64532 IN IP4 55.66.77.88 a=mid:v1 a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 + a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 rtx/90000 a=fmtp:101 apt=100 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 a=setup:actpass a=rtcp-mux a=rtcp-rsize @@ -3548,23 +3651,20 @@ 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 a=setup:actpass a=rtcp-mux a=rtcp-rsize a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack 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 maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) v=0 o=- 4962303333179871723 2 IN IP4 0.0.0.0 s=- t=0 0 a=group:BUNDLE a1 d1 v1 v2 @@ -3585,21 +3685,20 @@ a=ice-ufrag:ATEn1v9DoTMB9J4r a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 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 a=setup:passive a=rtcp-mux a=rtcp-rsize a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 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:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx raddr 192.168.1.2 rport 51556 a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay raddr 11.22.33.44 rport 52546 a=end-of-candidates m=application 52546 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 11.22.33.44 a=mid:d1 @@ -3632,29 +3731,30 @@ c=IN IP4 11.22.33.44 a=rtcp:52546 IN IP4 11.22.33.44 a=mid:v2 a=recvonly a=rtpmap:100 VP8/90000 a=rtpmap:101 rtx/90000 a=fmtp:101 apt=100 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 + a=setup:passive a=rtcp-mux a=rtcp-rsize a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli -9. Security Considerations +8. Security Considerations The IETF has published separate documents [I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing the security architecture for WebRTC as a whole. The remainder of this section describes security considerations for this document. 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 perspective of the browser. Thus, the threat model of [RFC3552] applies. In particular, JS can call the API in any order and with @@ -3669,51 +3769,56 @@ does not have complete control of browser behavior. One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those 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 your public IP address by removing server reflexive candidates. Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. -10. IANA Considerations +9. IANA Considerations This document requires no actions from IANA. -11. Acknowledgements +10. Acknowledgements Significant text incorporated in the draft as well and review was provided by Peter Thatcher, Taylor Brandstetter, Harald Alvestrand and Suhas Nandakumar. Dan Burnett, Neil Stratford, Anant Narayanan, Andrew Hutton, Richard Ejzak, Adam Bergkvist and Matthew Kaufman all provided valuable feedback on this proposal. -12. References +11. References -12.1. Normative References +11.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier (RID) Source Description (SDES)", draft-ietf- avtext-rid-00 (work in progress), February 2016. [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol". [I-D.ietf-mmusic-4572-update] Holmberg, C., "Updates to RFC 4572", draft-ietf-mmusic- 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] Alvestrand, H., "Cross Session Stream Identification in the Session Description Protocol", draft-ietf-mmusic- msid-01 (work in progress), August 2013. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-08 (work in progress), June 2016. @@ -3838,21 +3943,21 @@ Attributes in the Session Description Protocol (SDP)", RFC 6236, May 2011. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, April 2013. -12.2. Informative References +11.2. Informative References [I-D.ietf-rtcweb-ip-handling] Uberti, J. and G. Shieh, "WebRTC IP Address Handling Recommendations", draft-ietf-rtcweb-ip-handling-01 (work in progress), March 2016. [I-D.nandakumar-rtcweb-sdp] Nandakumar, S. and C. Jennings, "SDP for the WebRTC", draft-nandakumar-rtcweb-sdp-02 (work in progress), July 2013. @@ -3869,58 +3974,138 @@ RFC 3960, December 2004. [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 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, + . + [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010. [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure 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 Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . [W3C.WD-webrtc-20140617] Bergkvist, A., Burnett, D., Narayanan, A., and C. Jennings, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20140617, June 2014, . -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. + 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: o Update addIceCandidate to indicate ICE generation and allow per-m= section end-of-candidates. o Update fingerprint handling to use draft-ietf-mmusic-4572-update. o Update text around SDP processing of RTP header extensions and payload formats.