--- 1/draft-ietf-rtcweb-jsep-11.txt 2015-10-18 23:15:07.768103360 -0700 +++ 2/draft-ietf-rtcweb-jsep-12.txt 2015-10-18 23:15:07.928107227 -0700 @@ -1,21 +1,21 @@ Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track C. Jennings -Expires: January 6, 2016 Cisco +Expires: April 20, 2016 Cisco E. Rescorla, Ed. Mozilla - July 5, 2015 + October 18, 2015 Javascript Session Establishment Protocol - draft-ietf-rtcweb-jsep-11 + draft-ietf-rtcweb-jsep-12 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,21 +25,21 @@ 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 January 6, 2016. + This Internet-Draft will expire on April 20, 2016. Copyright Notice Copyright (c) 2015 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 @@ -70,68 +70,68 @@ 3.5.2. Interpreting an imageattr Attribute . . . . . . . . . 14 3.6. Interactions With Forking . . . . . . . . . . . . . . . . 15 3.6.1. Sequential Forking . . . . . . . . . . . . . . . . . 15 3.6.2. Parallel Forking . . . . . . . . . . . . . . . . . . 16 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 17 4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 19 4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 20 4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 21 - 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 21 + 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 22 4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 22 4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 23 - 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 23 + 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 24 4.1.7. localDescription . . . . . . . . . . . . . . . . . . 24 4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 24 4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 24 4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 25 4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 26 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 26 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 26 5.1.1. Implementation Requirements . . . . . . . . . . . . . 26 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 28 5.1.3. Profile Names and Interoperability . . . . . . . . . 28 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 29 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 29 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 34 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 37 5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 37 - 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 37 + 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 38 5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 38 5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 38 - 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 38 + 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 39 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 39 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 43 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 44 - 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 44 - 5.4. Processing a Local Description . . . . . . . . . . . . . 44 + 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 45 + 5.4. Processing a Local Description . . . . . . . . . . . . . 45 5.5. Processing a Remote Description . . . . . . . . . . . . . 45 - 5.6. Parsing a Session Description . . . . . . . . . . . . . . 45 + 5.6. Parsing a Session Description . . . . . . . . . . . . . . 46 5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 46 - 5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 47 + 5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 48 5.6.3. Semantics Verification . . . . . . . . . . . . . . . 49 5.7. Applying a Local Description . . . . . . . . . . . . . . 50 - 5.8. Applying a Remote Description . . . . . . . . . . . . . . 50 - 5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 50 - 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 50 - 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 52 - 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 52 - 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 56 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 67 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 68 - 11.2. Informative References . . . . . . . . . . . . . . . . . 71 - Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 72 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 + 5.8. Applying a Remote Description . . . . . . . . . . . . . . 51 + 5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 53 + 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 54 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 56 + 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 60 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 71 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 72 + 11.2. Informative References . . . . . . . . . . . . . . . . . 75 + Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 76 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 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 @@ -641,28 +641,34 @@ that it does not absolutely constrain the video formats that the sender can use, but gives an indication of the preferred values. This specification prescribes more specific behavior. When a sender of a given MediaStreamTrack, which is producing video of a certain resolution, receives an "a=imageattr recv" attribute, it MUST first check to see if the original resolution meets the criteria specified in the attribute, and transmit it untouched if so. If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to - satisfy the criteria. In rare cases, where a receiver requires a - minimum resolution which is greater than the native resolution of the - video, the sender SHOULD apply upscaling in order to provide that - resolution. The sender SHOULD NOT apply upscaling in any other - cases. + satisfy the criteria. - If there is no appropriate scaling mechanism that allows the received - criteria to be satisfied, the sender MUST NOT transmit the track. + If the receiver requires a minimum resolution which is greater than + the native resolution of the video, upscaling is needed, but this may + not be appropriate in all cases. To address this concern, the + application can set an 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. + + If there is no appropriate and permitted scaling mechanism that + allows the received criteria to be satisfied, 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.6. Interactions With Forking Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device. For example, SIP [RFC3261] defines both a "Parallel Search" and "Sequential Search". Although these are primarily signaling level issues that are outside @@ -1295,23 +1301,23 @@ follow the following rules when processing the media m= sections in an offer: o The profile in any "m=" line in any answer MUST exactly match the profile provided in the offer. 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 the - "a=fingerprint" attribute. Note that lack of an "a=fingerprint" - attribute will lead to negotiation failure. + 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- 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. @@ -1411,34 +1417,35 @@ indicated in [I-D.ietf-mmusic-trickle-ice], 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. 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 IP6 ::", - as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. + gathered, the "c=" line must contain the "dummy" value "IN IP4 + 0.0.0.0", as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. + [[NOTE: This has not yet changed in the trickle ICE draft.]] Each m= section MUST include the following attribute lines: 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 IP6 ::", because no candidates - have yet been gathered. + containing the dummy value "9 IN IP4 0.0.0.0", because no + candidates have yet been gathered. o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2. o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1. 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). @@ -1463,23 +1470,24 @@ 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 An "a=ice-options" line, with the "trickle" option, as specified in [I-D.ietf-mmusic-trickle-ice], Section 4. - o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the - algorithm used for the fingerprint MUST match that used in the - certificate signature. + 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=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1. o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. o For each supported RTP header extension, an "a=extmap" line, as @@ -1514,30 +1522,29 @@ 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. 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 the SCTP port number, as specified in - Section 4.1. [TODO: update this to use a=sctp-port, as indicated in - the latest data channel docs] + 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- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an - "a=sctpmap" line referencing the SCTP port number and specifying the - application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. - [OPEN ISSUE: the -01 of this document is missing this information.] + "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 in [RFC5888], Section 7. For each MediaStream with more than one @@ -1588,29 +1595,34 @@ If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the PeerConnection is still in the "local-offer" state, an offer is generated by following the steps in the "stable" 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, protocol, and address of the default candidate for the m= section, as - described in [RFC5245], Section 4.3. 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. + 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. 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.3 was specified. o Within each m= section, for each candidate that has been gathered during the most recent gathering phase (see Section 3.4.1), an @@ -1846,35 +1858,35 @@ 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-mmusic-trickle-ice], Section 5.1. o The field MUST be set to exactly match the field for the corresponding m= line in the offer. 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 IP6 ::", - as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. + gathered, the "c=" line must contain the "dummy" value "IN IP4 + 0.0.0.0", as defined in [I-D.ietf-mmusic-trickle-ice], 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: o 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 IP6 ::", because no candidates - have yet been gathered. + containing the dummy value "9 IN IP4 0.0.0.0", because no + candidates have yet been gathered. o If a local MediaStreamTrack has been associated, an "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2. o Depending on the directionality of the offer, the disposition of any associated remote MediaStreamTrack, and the presence of an associated local MediaStreamTrack, the appropriate directionality attribute, as specified in [RFC3264], Section 6.1. If the offer was sendrecv, and the remote MediaStreamTrack is still "live", and there is a local MediaStreamTrack that has been associated, the @@ -1914,27 +1926,27 @@ Section 6, and specific usage for each media type is outlined in Sections 4 and 5. o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], Section 15.4. o If the "trickle" ICE option is present in the offer, an "a=ice- options" line, with the "trickle" option, as specified in [I-D.ietf-mmusic-trickle-ice], Section 4. - o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the - algorithm used for the fingerprint MUST match that used in the - certificate signature. + 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. 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-rsize" line, as specified in @@ -1968,31 +1980,29 @@ o If a local MediaStreamTrack has been associated, and 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. 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 field MUST be set to exactly match the - field in the offer; the "fmt" value MUST be set to the SCTP port - number, as specified in Section 4.1. [TODO: update this to use - a=sctp-port, as indicated in the latest data channel docs] + "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- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an - "a=sctpmap" line referencing the SCTP port number and specifying the - application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. - [OPEN ISSUE: the -01 of this document is missing this information.] + "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 @@ -2297,61 +2308,220 @@ Assuming parsing completes successfully, the parsed description is then evaluated to ensure internal consistency as well as proper support for mandatory features. Specifically, the following checks 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 + * ICE ufrag and password values, which MUST comply with the size + limits specified in [RFC5245], Section 15.4. - * DTLS fingerprint and setup values + * 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 + + * DTLS fingerprint values, where at least one fingerprint MUST be + present. + + 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. If this session description is of type "pranswer" or "answer", the following additional checks are applied: o The session description must follow the rules defined in - [RFC3264], Section 6. + [RFC3264], Section 6, including the requirement that the number of + m= sections MUST exactly match the number of m= sections in the + associated offer. - o For each m= section, the protocol value MUST exactly match the - protocol value in the corresponding m= section in the associated - offer. + o For each m= section, the media type and protocol values MUST + exactly match the media type and protocol values in the + corresponding m= section in the associated offer. 5.7. Applying a Local Description The following steps are performed at the media engine level to apply a local description. First, the parsed parameters are checked to ensure that any modifications performed fall within those explicitly permitted by Section 6; otherwise, processing MUST stop and an error MUST be returned. Next, media sections are processed. For each media section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. - o TODO + o If this media section is new, begin gathering candidates for it, + as defined in [RFC5245], Section 4.1.1, unless it has been marked + as bundle-only. + + o Or, if the ICE ufrag and password values have changed, trigger the + ICE Agent to start an ICE restart and begin gathering new + candidates for the media section, as defined in [RFC5245], + Section 9.1.1.1, unless it has been marked as bundle-only. + + o If the media section proto value indicates use of RTP: + + * If RTCP mux is indicated, prepare to demux RTP and RTCP from + the RTP ICE component, as specified in [RFC5761], + Section 5.1.1. If RTCP mux is not indicated, but was indicated + in a previous description, this MUST result in an error. + + * For each specified RTP header extension, establish a mapping + between the extension ID and URI. If any indicated RTP header + extension is unknown, this MUST result in an error. [TODO: + ref] + + * If the MID header extension is supported, prepare to demux RTP + data intended for this media section based on the MID header + extension. [TODO: ref] + + * For each specified payload type, establish a mapping between + the payload type ID and the actual media format. [TODO: ref] + If any indicated payload type is unknown, this MUST result in + an error. + + * For each specified "rtx" media format, establish a mapping + between the RTX payload type and its associated primary payload + type. [TODO: ref] If any referenced primary payload types are + not present, this MUST result in an error. + + * If the directional attribute is of type "sendrecv" or + "recvonly", enable receipt and decoding of media. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the Section 5.9 section below. 5.8. Applying a Remote Description - TODO + The following steps are performed at the media engine level to apply + a remote description. + + For each media section, the following steps MUST be performed; if any + parameters are out of bounds, or cannot be applied, processing MUST + stop and an error MUST be returned. + + o If the description is of type "offer", and the ICE ufrag or + password changed from the previous remote description, [TODO: + ref], mark that an ICE restart is needed. + + o Configure the ICE components associated with this media section to + use the supplied ICE remote ufrag and password for their + connectivity checks. + + o Pair any supplied ICE candidates with any gathered local + candidates, as described in [TODO: ref] and start connectivity + checks with the appropriate credentials. + + o If the media section proto value indicates use of RTP: + + * [TODO: header extensions] + + * For each specified payload type that is also supported by the + local implementation, establish a mapping between the payload + type ID and the actual media format. [TODO: ref] If any + indicated payload type is unknown, it MUST be ignored. [TODO: + should fail on answers] + + * For each specified "rtx" media format, establish a mapping + between the RTX payload type and its associated primary payload + type. [TODO: ref] If any referenced primary payload types are + not present, this MUST result in an error. + + * For each specified fmtp parameter that is supported by the + local implementation, enable them on the associated payload + types. + + * For each specified RTCP feedback mechanism that is supported by + the local implementation, enable them on the associated payload + types. + + * For any specified "TIAS" bandwidth value, set this value as the + maximum RTP bitrate to be used when sending media. If a "TIAS" + value is not present, but an "AS" value is, generate a TIAS a + value using this formula: [TODO: convert AS to TIAS]. + + * [TODO: handling of CN, telephone-event, "red"] + + * If the media section if of type audio: + + + For any specified "ptime" value, configure the available + payload types to use the specified packet size. If the + specified size is not supported for a payload type, use the + next closest value instead. + + Finally, if this description is of type "pranswer" or "answer", + follow the processing defined in the Section 5.9 section below. 5.9. Applying an Answer - TODO + In addition to the steps mentioned above for processing a local or + 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. [TODO: + ref] + + o If the remote DTLS fingerprint has been changed, tear down the + existing DTLS connection. + + 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 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. + + * 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 [TODO: ref] + + * If the directional attribute in the answer is of type + "sendrecv" or "sendonly", prepare to start transmitting media + using the specified primary SSRC and one of the selected + payload types, once the underlying transport layers have been + established. Otherwise, stop transmitting RTP media, although + RTCP should still be sent. [TODO: ref] + + 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. [TODO: ref] + + 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. [TODO: ref] + + If the answer contains any "a=ice-options" attributes where "trickle" + is listed as an attribute, update the PeerConnection canTrickle + property to be true. Otherwise, set this property to false. 6. Configurable SDP Parameters It is possible to change elements in the SDP returned from createOffer before passing it to setLocalDescription. When an implementation receives modified SDP it MUST either: o Accept the changes and adjust its behavior to match the SDP. o Reject the changes and return an error via the error callback. @@ -2365,20 +2535,23 @@ browser MUST NOT honor an attempt to change them: o The number, type and port number of m= lines. o The generated ICE credentials (a=ice-ufrag and a=ice-pwd). o The set of ICE candidates and their parameters (a=candidate). o The DTLS fingerprint(s) (a=fingerprint). + o The contents of BUNDLE groups, bundle-only parameters, or "a=rtcp- + mux" parameters. + The following modifications, if done by the browser to a description between createOffer/createAnswer and the setLocalDescription, MUST be honored by the browser: o Remove or reorder codecs (m=) The following parameters may be controlled by options passed into createOffer/createAnswer. As an open issue, these changes may also be be performed by manipulating the SDP returned from createOffer/ createAnswer, as indicated above, as long as the capabilities of the @@ -2719,22 +2892,22 @@ The SDP for |offer-B1| looks like: v=0 o=- 4962303333179871723 1 IN IP4 0.0.0.0 s=- t=0 0 a=msid-semantic:WMS a=group:BUNDLE a1 d1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 - c=IN IP6 :: - a=rtcp:9 IN IP6 :: + c=IN IP4 0.0.0.0 + a=rtcp:9 IN IP4 0.0.0.0 a=mid:a1 a=msid:57017fee-b6c1-4162-929c-a25110252400 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=maxptime:120 @@ -2745,21 +2918,21 @@ 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 9 UDP/DTLS/SCTP webrtc-datachannel - c=IN IP6 :: + c=IN IP4 0.0.0.0 a=mid:d1 a=fmtp:webrtc-datachannel max-message-size=65536 a=sctp-port 5000 a=ice-ufrag:ATEn1v9DoTMB9J4r a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=ice-options:trickle 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 @@ -2778,22 +2951,22 @@ The SDP for |answer-B1| looks like: v=0 o=- 7729291447651054566 1 IN IP4 0.0.0.0 s=- t=0 0 a=msid-semantic:WMS a=group:BUNDLE a1 d1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 - c=IN IP6 :: - a=rtcp:9 IN IP6 :: + c=IN IP4 0.0.0.0 + a=rtcp:9 IN IP4 0.0.0.0 a=mid:a1 a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=maxptime:120 @@ -2803,21 +2976,21 @@ 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 IP6 :: + c=IN IP4 0.0.0.0 a=mid:d1 a=fmtp:webrtc-datachannel max-message-size=65536 a=sctp-port 5000 a=ice-ufrag:7sFvz2gdLkEwjZEr a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=ice-options:trickle 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 @@ -3307,20 +3480,49 @@ 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 Note: This section will be removed by RFC Editor before publication. + Changes in draft-12: + + o Filled in sections on applying local and remote descriptions. + + o Discussed downscaling and upscaling to fulfill imageattr + requirements. + + o Updated what SDP can be modified by the application. + + o Updated to latest datachannel SDP. + + o Allowed multiple fingerprint lines. + + o Switched back to IPv4 for dummy candidates. + + o Added additional clarity on ICE default candidates. + + Changes in draft-11: + + o Clarified handling of RTP CNAMEs. + + o Updated what SDP lines should be processed or ignored. + + o Specified how a=imageattr should be used. + + Changes in draft-10: + + o TODO + Changes in draft-09: o Don't return null for {local,remote}Description after close(). o Changed TCP/TLS to UDP/DTLS in RTP profile names. o Separate out bundle and mux policy. o Added specific references to FEC mechanisms.