--- 1/draft-ietf-rtcweb-jsep-23.txt 2017-10-10 12:13:11.712959300 -0700 +++ 2/draft-ietf-rtcweb-jsep-24.txt 2017-10-10 12:13:11.932964596 -0700 @@ -1,54 +1,54 @@ Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track C. Jennings -Expires: March 5, 2018 Cisco +Expires: April 13, 2018 Cisco E. Rescorla, Ed. Mozilla - September 1, 2017 + October 10, 2017 JavaScript Session Establishment Protocol - draft-ietf-rtcweb-jsep-23 + draft-ietf-rtcweb-jsep-24 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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/. + Drafts is at https://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 5, 2018. + This Internet-Draft will expire on April 13, 2018. Copyright Notice Copyright (c) 2017 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 + (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 @@ -112,33 +112,33 @@ 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 36 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56 - 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 56 + 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57 5.5. Processing a Local Description . . . . . . . . . . . . . 57 5.6. Processing a Remote Description . . . . . . . . . . . . . 58 5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58 5.8. Parsing a Session Description . . . . . . . . . . . . . . 59 - 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 59 + 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 60 5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61 5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64 5.9. Applying a Local Description . . . . . . . . . . . . . . 65 5.10. Applying a Remote Description . . . . . . . . . . . . . . 66 5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 70 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 73 - 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 73 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 96 11.2. Informative References . . . . . . . . . . . . . . . . . 101 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 103 @@ -803,25 +803,26 @@ [TS26.114]), as it significantly simplifies the matching logic. o 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 attribute MUST NOT be used. o If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to - satisfy the limits, although the downscaling MUST NOT change the - picture aspect ratio of the encoding. For example, if the encoder - resolution is 1280x720, and the attribute specified a maximum of - 640x480, the expected output resolution would be 640x360. If - downscaling cannot be applied, the attribute MUST NOT be used. + satisfy the limits. Downscaling MUST NOT change the picture + aspect ratio of the encoding, ignoring any trivial differences due + to rounding. For example, if the encoder resolution is 1280x720, + and the attribute specified a maximum of 640x480, the expected + output resolution would be 640x360. If downscaling cannot be + applied, the attribute MUST NOT be used. o If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST NOT apply upscaling. JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. o If the encoder resolution is within the maximum and minimum sizes, no action is needed. @@ -2544,20 +2545,25 @@ need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described above. 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 Each "a=tls-id" line MUST stay the same unless the offerer's + "a=tls-id" line changed, in which case a new "a=tls-id" value MUST + be created, as described in [I-D.ietf-mmusic-dtls-sdp], + Section 5.2. + o Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer. o RTCP multiplexing must be used, and an "a=rtcp-mux" line inserted if and only if the m= section previously used RTCP multiplexing. 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. @@ -2957,25 +2963,24 @@ o For each m= section, valid values for each of the mandatory-to-use features enumerated in Section 5.1.1 MUST be present. These 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. * tls-id value, which MUST be set according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer - and the tls-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 tls-id - value, if present, MUST be the same as in the offer. + or a response to a re-offer and the tls-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. * 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 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 @@ -3273,21 +3278,27 @@ described in [RFC5245], Section 9.2.1.3. o If the remote DTLS fingerprint has been changed or the tls-id has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE - channel. + channel. Note that although JSEP requires that answerers change + the tls-id value if and only if the offerer does, non-JSEP + answerers are permitted to change the tls-id as long as the offer + contained an ICE restart. Thus, JSEP implementations which + process DTLS data prior to receiving an answer MUST be prepared to + receive either a ClientHello or data from the previous 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 m= section proto value indicates use of RTP: * If the m= section references RTCP feedback mechanisms that were not present in the corresponding m= section in the offer, this indicates a negotiation problem and MUST result in an error. @@ -3504,21 +3515,21 @@ a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:47017fee-b6c1-4162-929c-a25110252400 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 a=ice-ufrag:ETEn 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=tls-id:1 + a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=rtcp:10101 IN IP4 203.0.113.100 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10101 typ host a=end-of-candidates m=video 10102 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 203.0.113.100 a=mid:v1 @@ -3536,21 +3547,21 @@ a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:47017fee-b6c1-4162-929c-a25110252400 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 a=ice-ufrag:BGKk 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=tls-id:1 + a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=rtcp:10103 IN IP4 203.0.113.100 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host a=end-of-candidates The SDP for |answer-A1| looks like: v=0 @@ -3577,21 +3588,21 @@ a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 5a7b57b8-f043-4bd1-a45d-09d4dfa31226 a=ice-ufrag:6sFv 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=tls-id:1 + a=tls-id:eec3392ab83e11ceb6a0990c903fbb19 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=end-of-candidates m=video 10200 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 203.0.113.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 @@ -3738,21 +3749,21 @@ a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:57017fee-b6c1-4162-929c-a25110252400 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 a=ice-ufrag:ATEn a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 29: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=tls-id:1 + a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=application 0 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 a=bundle-only @@ -3804,21 +3815,21 @@ a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 6a7b57b8-f043-4bd1-a45d-09d4dfa31226 a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 7B: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=tls-id:1 + a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 @@ -3875,21 +3886,21 @@ a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 6a7b57b8-f043-4bd1-a45d-09d4dfa31226 a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 7B: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=tls-id:1 + a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx raddr 203.0.113.200 rport 10200 a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 198.51.100.200 rport 11200 a=end-of-candidates @@ -3972,21 +3983,21 @@ a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:57017fee-b6c1-4162-929c-a25110252400 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 a=ice-ufrag:ATEn a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 29: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=tls-id:1 + a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host a=candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx raddr 203.0.113.100 rport 10100 a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 198.51.100.100 rport 11100 a=end-of-candidates @@ -4150,21 +4161,21 @@ a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce e80098db-7159-3c06-229a-00df2a9b3dbc a=ice-ufrag:4ZcD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=fingerprint:sha-256 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF a=setup:actpass - a=tls-id:1 + a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=video 0 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 0.0.0.0 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 @@ -4215,21 +4226,21 @@ a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:751f239e-4ae0-c549-aa3d-890de772998b 04b5a445-82cc-c9e8-9ffe-c24d0ef4b0ff a=ice-ufrag:TpaA a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=fingerprint:sha-256 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D a=setup:active - a=tls-id:1 + a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=video 9 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 0.0.0.0 a=mid:v1 a=sendonly a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 @@ -4279,21 +4290,21 @@ a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:751f239e-4ae0-c549-aa3d-890de772998b 04b5a445-82cc-c9e8-9ffe-c24d0ef4b0ff a=ice-ufrag:TpaA a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=fingerprint:sha-256 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D a=setup:actpass - a=tls-id:1 + a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 0.0.0.0 rport 0 a=end-of-candidates m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.200 a=mid:v1 @@ -4338,21 +4349,21 @@ a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce e80098db-7159-3c06-229a-00df2a9b3dbc a=ice-ufrag:4ZcD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=fingerprint:sha-256 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF a=setup:passive - a=tls-id:1 + a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 0.0.0.0 rport 0 a=end-of-candidates m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v1 @@ -4423,28 +4434,28 @@ [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 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", draft-ietf-ice-trickle-13 (work in progress), - July 2017. + Protocol", draft-ietf-ice-trickle-14 (work in progress), + September 2017. [I-D.ietf-mmusic-dtls-sdp] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", - draft-ietf-mmusic-dtls-sdp-29 (work in progress), August + draft-ietf-mmusic-dtls-sdp-31 (work in progress), October 2017. [I-D.ietf-mmusic-msid] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", draft-ietf-mmusic-msid-16 (work in progress), February 2017. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- @@ -4494,121 +4505,121 @@ [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-08 (work in progress), February 2015. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-12 (work in progress), June 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, . + DOI 10.17487/RFC2119, March 1997, + . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, - DOI 10.17487/RFC3261, June 2002, . + DOI 10.17487/RFC3261, June 2002, + . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, - DOI 10.17487/RFC3264, June 2002, . + DOI 10.17487/RFC3264, June 2002, + . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, - DOI 10.17487/RFC3552, July 2003, . + DOI 10.17487/RFC3552, July 2003, + . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, - DOI 10.17487/RFC3605, October 2003, . + DOI 10.17487/RFC3605, October 2003, + . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, - DOI 10.17487/RFC4145, September 2005, . + DOI 10.17487/RFC4145, September 2005, + . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, - DOI 10.17487/RFC4585, July 2006, . + DOI 10.17487/RFC4585, July 2006, + . [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, - DOI 10.17487/RFC5245, April 2010, . + DOI 10.17487/RFC5245, April 2010, + . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, - DOI 10.17487/RFC5761, April 2010, . + DOI 10.17487/RFC5761, April 2010, + . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, - DOI 10.17487/RFC5888, June 2010, . + DOI 10.17487/RFC5888, June 2010, + . [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, - DOI 10.17487/RFC6904, April 2013, . + DOI 10.17487/RFC6904, April 2013, + . [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, - DOI 10.17487/RFC7160, April 2014, . + DOI 10.17487/RFC7160, April 2014, + . [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, - DOI 10.17487/RFC7587, June 2015, . + DOI 10.17487/RFC7587, June 2015, + . [RFC7742] Roach, A., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, . [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, . @@ -4617,40 +4628,40 @@ . [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, - DOI 10.17487/RFC8122, March 2017, . + DOI 10.17487/RFC8122, March 2017, + . 11.2. Informative References [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) usage for Trickle ICE", draft-ietf-mmusic-trickle-ice-sip-08 (work in progress), July 2017. [I-D.ietf-rtcweb-ip-handling] Uberti, J. and G. Shieh, "WebRTC IP Address Handling Requirements", draft-ietf-rtcweb-ip-handling-04 (work in progress), July 2017. [I-D.ietf-rtcweb-sdp] Nandakumar, S. and C. Jennings, "Annotated Example SDP for - WebRTC", draft-ietf-rtcweb-sdp-06 (work in progress), - April 2017. + WebRTC", draft-ietf-rtcweb-sdp-07 (work in progress), + October 2017. [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . @@ -4659,55 +4670,55 @@ RFC 3960, DOI 10.17487/RFC3960, December 2004, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, - DOI 10.17487/RFC4588, July 2006, . + DOI 10.17487/RFC4588, 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, . + 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, DOI 10.17487/RFC5506, April 2009, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, 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, DOI 10.17487/RFC5763, 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, - DOI 10.17487/RFC5764, May 2010, . + DOI 10.17487/RFC5764, May 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, . + DOI 10.17487/RFC6464, December 2011, + . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [TS26.114] 3GPP TS 26.114 V12.8.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia @@ -4762,20 +4773,27 @@ | | 6.1 | | tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 | +------------------------+------------------------------------------+ Table 1: SDP ABNF References Appendix B. Change log Note to RFC Editor: Please remove this section before publication. + Changes in draft-24: + + o Clarify that rounding is permitted when trying to maintain aspect + ratio. + + o Update tls-id handling to match what is specified in dtls-sdp. + Changes in draft-23: o Clarify rollback handling, and treat it similarly to other setLocal/setRemote usages. o Adopt a first-fit policy for handling multiple remote a=imageattr attributes. o Clarify that a session description with zero m= sections is legal.