idnits 2.17.1 draft-jennings-mmusic-media-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 13, 2013) is 4061 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco 4 Intended status: Informational J. Uberti 5 Expires: August 17, 2013 Google 6 E. Rescorla 7 Mozilla 8 February 13, 2013 10 Requirements from various WG for MMUSIC 11 draft-jennings-mmusic-media-req-00 13 Abstract 15 This document outlines some of the requirements driving various 16 consideration related to multiplexing in the MMUSIC working group to 17 meet the needs of WebRTC, CLUE, and other working groups. 19 This document is only meant to be used to help drive the discussion 20 of solutions and is not intended to become an RFC. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, and it may not be 27 published except as an Internet-Draft. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 17, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 4 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 For the past several meetings, there has been discussions around 73 various mechanism to reduce the number of UDP ports needed by 74 applications for RTP. This document attempts to capture some of the 75 requirements that are important in selecting the solution for how to 76 represent the SDP to negotiate the RTP media that is using reduced 77 ports. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 This document generically uses RTP to mean RTP and SRTP. 86 3. Requirements 88 This section covers the requirements from various WG for setting up 89 media. Obviously it does not try and cover all the requirements but 90 it tries to cover a set that seem relevant to decisions around 91 multiplexing onto few UDP ports. 93 High Priority Requirements: 95 1. Support many media flows but minimize the number of transport 96 flows. For instance, all media flows--or perhaps all media flows 97 of a given type--might be multiplexed over a single transport 98 flow. 100 2. Be able to successfully negotiate media with both legacy SIP 101 devices and new devices (whether SIP or RTCWEB) with a single 102 offer/answer exchange. If both endpoints support multiplexed 103 media, then multiplexing should be negotiated. Otherwise, non- 104 multiplexed media should be used. In many cases, each endpoints 105 will have no prior knowledge of capabilities of the other 106 endpoint. 108 Other Requirements: 110 1. Need a uniform way to allow specifications of new SDP parameters 111 to easily explain any implications that multiplexing has on the 112 new parameters in that specification. 114 2. Allow different sources (E.g. cameras) to use different codecs. 115 For example, if one camera had hardware encoders for VP8 while 116 another had encoders for H.264, the device may wish to negotiate 117 different codecs. 119 3. Be able to to independently set parameters such as resolution 120 bandwidth, independently for each RTCWeb Track, preferably even 121 when they are all multiplexed over the same transport flow. 123 4. Be able to identify the RTCWeb tracks with an identifier that is 124 stable over the duration of the session. More information can be 125 found in [I-D.alvestrand-mmusic-msid]. 127 4. Non-Requirements 129 Some items are not a major goal. If methods are found that work for 130 these as well, that is great, but they are not a priority item. 132 1. Working with SIP proxies or B2BUA that are not compliant with the 133 standards. The reason for this is it is just not possible to 134 design for every possible thing that does not do what the 135 standards require. 137 5. IANA Considerations 139 This document makes no request of IANA. 141 6. Security Considerations 143 These requirements have no additional security considerations other 144 than those captured in [I-D.ietf-rtcweb-security-arch]. 146 7. Acknowledgements 148 Thanks to ... 150 8. References 152 8.1. Normative References 154 [I-D.ietf-rtcweb-security-arch] 155 Rescorla, E., "RTCWEB Security Architecture", 156 draft-ietf-rtcweb-security-arch-06 (work in progress), 157 October 2012. 159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 160 Requirement Levels", BCP 14, RFC 2119, March 1997. 162 8.2. Informative References 164 [I-D.alvestrand-mmusic-msid] 165 Alvestrand, H., "Cross Session Stream Identification in 166 the Session Description Protocol", 167 draft-alvestrand-mmusic-msid-02 (work in progress), 168 December 2012. 170 Authors' Addresses 172 Cullen Jennings 173 Cisco 174 400 3rd Avenue SW, Suite 350 175 Calgary, AB T2P 4H2 176 Canada 178 Email: fluffy@iii.ca 180 Justin Uberti 181 Google 182 747 6th Ave S 183 Kirkland, WA 98033 184 USA 186 Email: justin@uberti.name 188 Eric Rescorla 189 Mozilla 191 Phone: +1 650 678 2350 192 Email: ekr@rtfm.com